Thread: Emulation error
View Single Post
Old 03 February 2014, 03:47   #11
Oh, her, from BIX.

Join Date: Feb 2014
Location: Southern California, USA
Posts: 10
Originally Posted by Toni Wilen View Post
It has to be caused by something else because FSSM device name is uaehf.device, even Scout Amiga system utility shows uaehf.device if hardfile and uae.device if directory filesystem.
OK, I looked closer at the tools output. The ordering of the output confused me last night. I'm sorry about that. I'm attaching some utilities that are interesting and the output of some of them. Good luck making DiskEd work. It says it cannot find the device. WinUAE is not doing what I thought it was doing. Let's see what happens when I try other ways to access the disk. I'll spend more time diagnosing it.

RDPrepX issue: (I did find the problem - noted below.)
Meanwhile here's rdprepx to play with. Suppose you simply want a list of drives rdprepx can work with the command is "rdprepx -d uaehf.device". That simply stops after the first SCSI id is accessed as it moves on to the second LUN. That's what the single dot means. It should show a dot for every board, LUN, and ID. (note: unit 123 would be board 1 (the second board), LUN 2, and SCSI ID 3.)

For reading out the RDBs on unit 2, SCSI ID 2, you'd use this command: "rdprepx -d uaehf.device -u 2 -t -s 002.list" The "002.list" name is simply a convention I have here to keep mountlist copies nicely named. "ml" would work just as well. The "-t" keeps rdprepx from searching for all disks before grabbing the mountlist data out of the rdbs and saving it. If you take -t out rdprepx quietly fails again after printing out one dot.

The testing loop prints a dot. Then it goes off to a testing routine. It opens the device. If that fails it exits. Otherwise it performs up to three TestUnitReady commands. (Some drives responded slowly.) Then it performs a SCSI Inquiry. Again it tries twice due to some funkity drives. It then performs a raw read. If the -n option was entered it perfoms another SCSI Inquiry and prints the returned name for each drive found. It tests with an outer loop of board, middle loop of LUN, and inner loop of SCSI ID. So it appears I was wrong on the LUN issue. The failure comes within the test for a SCSI ID that's not present.

And with some comparison with the hdwrench.library output I note that your device driver has the same problem as the ApolloSCSI - it reported HFERR_NoBoard rather than TDERR_BadUnitNum when testing unit 0. That kills the loop. I've fixed rdprepx to include the ApolloSCSI exception I placed in hdwrench.library. So that's sort of fixed for me. You might want to be nice and change the error report to BadUnitNum if there are other valid units on the selected board ID. (I suspect two ApolloSCSI boards would fail out the second board if the first SCSI ID was not zero. But who, other than me, had more than one board in a box?)

DISKED item:
Note that disked apparently has some other form of problem. "DiskEd WB_2.x" and "DiskEd SFS.1" both fail.

NOTE: I am adding a fixed rdprepx, called rdprepz for convenience. It has considerable debug output to play with, particularly with a "-q 0" option.


Originally Posted by Toni Wilen View Post
Worked for me with 2G RDB hardfile with single partition. Guru is division by zero which usually points to some unsupported geometry value or something.
The error he saw was probably because "rdprep" did not know to use uaehf.device and fed rdprepx bad values. I always use rdprepx as a CLI tool and avoid one potential set of problems.

Attached Files
File Type: zip (68.6 KB, 58 views)

Last edited by TCD; 03 February 2014 at 07:46. Reason: Back-to-back posts merged
jdow is offline  
Page generated in 0.11333 seconds with 10 queries