Debian installer CD problems - Page 3

mark_k · 25 February 2013, 21:47

Don't know whether this will help at all, but here's output from executing a couple of SCSI commands (running on my laptop in Linux, passing through the Linux ATAPI-to-SCSI conversion):

This is after inserting a CD-ROM in the drive. sg_readcap issues READ CAPACITY commands. ddpt issues a single READ 10 command which fails.

Code:

# sg_readcap -vvv /dev/sg0
open /dev/sg0 with flags=0x800
    read capacity (10) cdb: 25 00 00 00 00 00 00 00 00 00 
      duration=4 ms
read capacity (10):  Fixed format, current;  Sense key: Unit Attention
 Additional sense: Not ready to ready change, medium may have changed
 Raw sense data (in hex):
        70 00 06 00 00 00 00 0a  00 00 00 10 28 00 00 00    
        00 00                                               

# sg_readcap -vvv /dev/sg0
open /dev/sg0 with flags=0x800
    read capacity (10) cdb: 25 00 00 00 00 00 00 00 00 00 
      duration=0 ms
Read Capacity results:
   Last logical block address=224024 (0x36b18), Number of blocks=224025
   Logical block length=2048 bytes
Hence:
   Device size: 458803200 bytes, 437.5 MiB, 0.46 GB

# ddpt if=/dev/sg0 of=test.bin bs=2048 bpt=10 count=10 skip=224020 verbose=3
 >> Input file type: pass-through [pt] device 
open /dev/sg0 with flags=0x802
    inquiry cdb: 12 00 00 00 24 00 
    /dev/sg0: HL-DT-ST  DVDRAM GMA-4082N  ED01  [pdt=5]
 >> Output file type: unable to 'stat' test.bin 
        create test.bin, flags=0x41
    read capacity (10) cdb: 25 00 00 00 00 00 00 00 00 00 
  /dev/sg0 [pt]: blocks=224025 [0x36b19], _bs=2048, 458 MB
skip=224020 (blocks on input), seek=0 (blocks on output)
  ibs=2048 bytes, obs=2048 bytes, OBPC=0
  initial count=10 (blocks of input), blocks_per_transfer=10
    READ cdb: 28 00 00 03 6b 14 00 00 0a 00 
READ:  Fixed format, current;  Sense key: Illegal Request
 Additional sense: Logical block address out of range
  Info fld=0x36b19 [224025] 
 Raw sense data (in hex):
        f0 00 05 00 03 6b 19 0a  28 00 00 10 21 00 00 00    
        00 00                                               
pt_read failed, at or after lba=224020 [0x36b14]
  remaining block count=10
0+0 records in
0+0 records out
time to transfer data: 0.003021 secs
Early termination, some error occurred

So attempting an out-of-range READ should return Illegal Request / Logical block address out of range.

mark_k · 26 February 2013, 11:00

Another test on Linux, this time issuing a WRITE command to a CD-ROM. This was done using an ATAPI DVD writer. Maybe some day I'll hook up a real SCSI CD-ROM drive to my laptop and do the same test with that. But in the mean time, hopefully this gives an idea of which error codes to return.

Code:

# ddpt if=/dev/zero of=/dev/sg0 bs=2048 bpt=10 seek=10 verbose=3
 >> Input file type: char device 
        open /dev/zero, flags=0x0
 >> Output file type: pass-through [pt] device 
open /dev/sg0 with flags=0x802
    inquiry cdb: 12 00 00 00 24 00 
    /dev/sg0: HL-DT-ST  DVDRAM GMA-4082N  ED01  [pdt=5]
    read capacity (10) cdb: 25 00 00 00 00 00 00 00 00 00 
  /dev/sg0 [pt]: blocks=224025 [0x36b19], _bs=2048, 458 MB
calc_count: in_num_sect=-1, out_num_sect=224025
skip=0 (blocks on input), seek=10 (blocks on output)
  ibs=2048 bytes, obs=2048 bytes, OBPC=0
  initial count=224015 (blocks of input), blocks_per_transfer=10
read(unix): requested bytes=20480, res=20480
    WRITE cdb: 2a 00 00 00 00 0a 00 00 0a 00 
WRITE:  Fixed format, current;  Sense key: Illegal Request
 Additional sense: Cannot write medium - incompatible format
 Raw sense data (in hex):
        70 00 05 00 00 00 00 0a  2a 00 00 10 30 05 00 00    
        00 00                                               
pt_write failed, seek=10
10+0 records in
0+0 records out
1 unrecovered write error
time to transfer data: 0.002224 secs at 9.21 MB/sec

Toni Wilen · 26 February 2013, 11:18

Quote:

Originally Posted by mark_k

Another test on Linux, this time issuing a WRITE command to a CD-ROM. This was done using an ATAPI DVD writer.

Same error with pressed CD and CD-R?

mark_k · 26 February 2013, 12:06

Good question. The test above was done with a pressed CD-ROM in an ATAPI DVD-multi drive. The drive is capable of writing to DVD-RAM discs which can be written using WRITE 10 commands. So the additional sense code makes sense in that case.

Here's the result of the same WRITE 10 command with an ATAPI DVD-ROM (i.e. read only) drive, connected via an IDE-to-USB bridge. The additional sense code is different here because the drive doesn't support WRITE 10 at all (I think).

Code:

# ddpt if=/dev/zero of=/dev/sg5 bs=2048 bpt=10 seek=10 verbose=3
 >> Input file type: char device 
        open /dev/zero, flags=0x0
 >> Output file type: pass-through [pt] device 
open /dev/sg5 with flags=0x802
    inquiry cdb: 12 00 00 00 24 00 
    /dev/sg5: HL-DT-ST  DVD-ROM GDR8082N  0106  [pdt=5]
    read capacity (10) cdb: 25 00 00 00 00 00 00 00 00 00 
  /dev/sg5 [pt]: blocks=224025 [0x36b19], _bs=2048, 458 MB
calc_count: in_num_sect=-1, out_num_sect=224025
skip=0 (blocks on input), seek=10 (blocks on output)
  ibs=2048 bytes, obs=2048 bytes, OBPC=0
  initial count=224015 (blocks of input), blocks_per_transfer=10
read(unix): requested bytes=20480, res=20480
    WRITE cdb: 2a 00 00 00 00 0a 00 00 0a 00 
WRITE:  Fixed format, current;  Sense key: Illegal Request
 Additional sense: Invalid command operation code
 Raw sense data (in hex):
        70 00 05 00 00 00 00 0a  00 00 00 00 20 00 00 00    
        00 00                                               
    pass-through requested 20480 bytes but got 1024 bytes
pt_write failed, seek=10
10+0 records in
0+0 records out
1 unrecovered write error
time to transfer data: 0.007894 secs at 2.59 MB/sec

For WinUAE it would make more sense to return the invalid command operation code additional sense code I think.

Here's some more test output done with the DVD-ROM drive. Starting with the drive empty, then inserting a disc and waiting as it spins up. Note the transitions:
not ready / medium not present --> not ready / logical unit in process of becoming ready --> unit attention / not ready to ready change --> after unit attention is cleared READ CAPACITY works

Code:

# sg_readcap -vvv /dev/sg5
open /dev/sg5 with flags=0x800
    read capacity (10) cdb: 25 00 00 00 00 00 00 00 00 00 
      duration=4 ms
read capacity (10):  Fixed format, current;  Sense key: Not Ready
 Additional sense: Medium not present
 Raw sense data (in hex):
        70 00 02 00 00 00 00 0a  00 00 00 00 3a 00 00 00    
        00 00                                               
    requested 8 bytes but got 0 bytes
READ CAPACITY (10) failed, device not ready

# sg_readcap -vvv /dev/sg5
open /dev/sg5 with flags=0x800
    read capacity (10) cdb: 25 00 00 00 00 00 00 00 00 00 
      duration=4 ms
read capacity (10):  Fixed format, current;  Sense key: Not Ready
 Additional sense: Medium not present
 Raw sense data (in hex):
        70 00 02 00 00 00 00 0a  00 00 00 00 3a 00 00 00    
        00 00                                               
    requested 8 bytes but got 0 bytes
READ CAPACITY (10) failed, device not ready

# sg_readcap -vvv /dev/sg5
open /dev/sg5 with flags=0x800
    read capacity (10) cdb: 25 00 00 00 00 00 00 00 00 00 
      duration=4 ms
read capacity (10):  Fixed format, current;  Sense key: Not Ready
 Additional sense: Logical unit is in process of becoming ready
 Raw sense data (in hex):
        70 00 02 00 00 00 00 0a  00 00 00 00 04 01 00 00    
        00 00                                               
    requested 8 bytes but got 0 bytes
READ CAPACITY (10) failed, device not ready

# sg_readcap -vvv /dev/sg5
open /dev/sg5 with flags=0x800
    read capacity (10) cdb: 25 00 00 00 00 00 00 00 00 00 
      duration=4 ms
read capacity (10):  Fixed format, current;  Sense key: Not Ready
 Additional sense: Logical unit is in process of becoming ready
 Raw sense data (in hex):
        70 00 02 00 00 00 00 0a  00 00 00 00 04 01 00 00    
        00 00                                               
    requested 8 bytes but got 0 bytes
READ CAPACITY (10) failed, device not ready

# sg_readcap -vvv /dev/sg5
open /dev/sg5 with flags=0x800
    read capacity (10) cdb: 25 00 00 00 00 00 00 00 00 00 
      duration=12 ms
read capacity (10):  Fixed format, current;  Sense key: Unit Attention
 Additional sense: Not ready to ready change, medium may have changed
 Raw sense data (in hex):
        70 00 06 00 00 00 00 0a  00 00 00 00 28 00 00 00    
        00 00                                               
    requested 8 bytes but got 0 bytes

# sg_readcap -vvv /dev/sg5
open /dev/sg5 with flags=0x800
    read capacity (10) cdb: 25 00 00 00 00 00 00 00 00 00 
      duration=4 ms
Read Capacity results:
   Last logical block address=224024 (0x36b18), Number of blocks=224025
   Logical block length=2048 bytes
Hence:
   Device size: 458803200 bytes, 437.5 MiB, 0.46 GB

mark_k · 26 February 2013, 15:33

Quote:

Originally Posted by Toni Wilen

btw, do you have very old SCSI CD documentation? For example SCSIQuery seems to use fields that are "reserved" in newer specs ("Audio playback rate is invalid", weird output from unused output ports, "Length in the middle of the medium in blocks" uses READ CAPACITY with reserved fields set etc..)

I've been having a look. So far I've found a Toshiba SCSI CD-ROM manual, and manuals for certain Toshiba (SCSI and ATAPI) and Panasonic/Matushita SCSI CD writers. Also the Hitachi GF-1050 DVD-RAM drive SCSI manual. I'll upload them shortly. In the mean time you can download the Pioneer CD-ROM SCSI-2 Command Set Reference Manual.

Edit: I have uploaded some archives to The Zone for you.

Toni Wilen · 28 February 2013, 17:25

Quote:

Originally Posted by mark_k

Sometimes if you press F12 while SCSI I/O is in progress, then Cancel to return to emulation, that causes a problem. For example see screenshot of reading a CD to an image file using dd in NetBSD. The Check Condition error message appeared after cancelling the settings window.

After that, repeating the command gives the same Not Ready/Medium Not Present error. The problem also seems to happen if you press F12 and cancel when the CD drive is idle. Do you generate unit attention / not ready to ready / medium changed status when a CD is inserted? The problem might be more likely to happen if you load a config which has no CD image inserted, then select a CD image before starting emulation.

Include log (with -scsiemulog enabled) that shows exactly what happens.

Quote:

Here's some more test output done with the DVD-ROM drive. Starting with the drive empty, then inserting a disc and waiting as it spins up. Note the transitions:

Not interested in emulating this, no program cares.

write now returns unknown command, read out of bounds check added.

mark_k · 28 February 2013, 18:47

Quote:

Originally Posted by Toni Wilen

Not interested in emulating this, no program cares.

You probably should emulate at least the unit attention / not ready to ready change condition, since that's how an operating system would typically detect that the disc has been changed.

I tried the latest winuae.exe with NetBSD, using the command dd if=/dev/cd0c of=out.bin bs=2048 to try to read the CD. The specific ISO image I used was debian-31r8-m68k-businesscard.iso (though that shouldn't make a difference). See the screenshot. The first error message was

Code:

Check Condition on CDB: 0x08 00 00 01 01 00
SENSE KEY:  Illegal Request
 ASC/ASCQ:  Logical Block Address Out of Range

After opening and closing the settings window, the error reported on doing the same dd command was:

Code:

Check Condition on CDB: 0x00 00 00 00 00 00
SENSE KEY:  Not Ready
 ASC/ASCQ:  Medium Not Present

Log output was:

Code:

SCSIEMU 0: 1E.00.00.00.01.00.00.00.00.00.00.00 CMDLEN=6 DATA=35F8C744 LEN=6
-> DATAOUT=0 ST=0 SENSELEN=0
SCSIEMU 0: 25.00.00.00.00.00.00.00.00.00.00.00 CMDLEN=10 DATA=35F8C744 LEN=10
-> DATAOUT=8 ST=0 SENSELEN=0
SCSIEMU 0: 51.00.00.00.00.00.00.00.22.00.00.00 CMDLEN=10 DATA=35F8C744 LEN=10
-> DATAOUT=34 ST=0 SENSELEN=0
SCSIEMU 0: 52.01.00.00.00.01.00.00.24.00.00.00 CMDLEN=10 DATA=35F8C744 LEN=10
-> DATAOUT=28 ST=0 SENSELEN=0
SCSIEMU 0: 43.00.00.00.00.00.00.00.0C.40.00.00 CMDLEN=10 DATA=35F8C744 LEN=10
-> DATAOUT=12 ST=0 SENSELEN=0
SCSIEMU 0: 08.00.00.00.01.00.00.00.0C.40.00.00 CMDLEN=6 DATA=35F8C744 LEN=6
-> DATAOUT=2048 ST=0 SENSELEN=0
SCSIEMU 0: 08.00.00.01.01.00.00.00.0C.40.00.00 CMDLEN=6 DATA=35F8C744 LEN=6
-> DATAOUT=-1 ST=2 SENSELEN=18
SCSIEMU 0: 43.00.00.00.00.00.00.00.0C.40.00.00 CMDLEN=10 DATA=35F8C744 LEN=10
-> DATAOUT=12 ST=0 SENSELEN=0
SCSIEMU 0: 08.00.00.00.01.00.00.00.0C.40.00.00 CMDLEN=6 DArTA=35F8C744 LEN=6
-> DATAOUT=2048 ST=0 SENSELEN=0
SCSIEMU 0: 08.00.00.01.01.00.00.00.0C.40.00.00 CMDLEN=6 DATA=35F8C744 LEN=6
-> DATAOUT=-1 ST=2 SENSELEN=18
SCSIEMU 0: 35.00.00.00.00.00.00.00.00.00.00.00 CMDLEN=10 DATA=35F8C744 LEN=10
-> DATAOUT=0 ST=0 SENSELEN=0
SCSIEMU 0: 1E.00.00.00.00.00.00.00.00.00.00.00 CMDLEN=6 DATA=35F8C744 LEN=6
-> DATAOUT=0 ST=0 SENSELEN=0
setmouseactive 1->0 showcursor=1 focus=1 recap=0
releasecapture
setmouseactive 0->0 showcursor=0 focus=1 recap=0
GUIBase 803x544 (6x12)
Requested GUI size = 709x737 (768x869)
winuae_inactive(0)
setmouseactive 0->0 showcursor=0 focus=0 recap=0
hfd attempting to open: 'Z:\NetBSD_test\NetBSD_4GB_HD.bin'
HDF 'Z:\NetBSD_test\NetBSD_4GB_HD.bin' failed to open. error = 32
Got GUI size = 708x727
winuae_active(0)
winuae_inactive(0)
setmouseactive 0->0 showcursor=0 focus=0 recap=0
POS (0 0 768 869) - (-8 -191 760 678)[768,869] (0 0)
winuae_active(0)
setmouseactive 0->-1 showcursor=0 focus=1 recap=0
GetWindowRect 907x29 1675x898 0
CLIP 907x29 1675x898 0
setmouseactive 1->1 showcursor=1 focus=1 recap=0
GetWindowRect 907x29 1675x515 0
window already open (907x29 768x486)
CLIP 907x29 1675x515 0
Allocated draw temp buffer (1600*1280*32) = 363A0020
Device name: 'NVIDIA GeForce Go 7300' 7000f000c1a02.0
D3D9Ex: 00000056 ALPHA DYNAMIC 
D3D9Ex: PS=2.0 VS=2.0 768*486*0p VS=0 B=0I 32-bit 0
Disabling D3D9Ex
Device name: 'NVIDIA GeForce Go 7300' 7000f000c1a02.0
D3D9: 00000056 ALPHA DYNAMIC 
D3D9: PS=2.0 VS=2.0 768*486*0p VS=0 B=0I 32-bit 0
Using non-shader version
GetWindowRect 907x29 1675x515 0
Buffer size (752*486) Native
D3D9: working texture allocated pre 752*486, post 768*486, bits per pixel 32
D3D9: 752*486 texture allocated, bits per pixel 32
NTSC mode lace V=60.0534Hz H=15734.2637Hz (227x262+0) IDX=11 (NTSC) D=0 RTG=0
P96FREQ: 262*60.0534 = 15734.0000 / 60.1 = 262
POS (0 0 768 486) - (-8 0 760 486)[768,486] (0 0)
setmouseactive 1->0 showcursor=1 focus=1 recap=0
releasecapture
setmouseactive 0->1 showcursor=0 focus=1 recap=0
GetWindowRect 907x29 1675x515 0
CLIP 907x29 1675x515 0
setmouseactive 1->0 showcursor=1 focus=1 recap=0
releasecapture
setmouseactive 0->0 showcursor=0 focus=1 recap=0
GUIBase 803x544 (6x12)
Requested GUI size = 709x737 (768x486)
winuae_inactive(0)
setmouseactive 0->0 showcursor=0 focus=0 recap=0
Got GUI size = 708x727

Edit to add: earlier in the log output was this:

Code:

hfd attempting to open: 'Z:\NetBSD_test\NetBSD_4GB_HD.bin'
HDF 'Z:\NetBSD_test\NetBSD_4GB_HD.bin' 35FCC760 opened, size=3906250K mode=1 empty=0
BUG unit 0 close: opencnt=0!
CD: plain CD image mounted!
 1:       0 00:02:00 DATA     4          0   39028736 
 - Z:\Debian_test\debian-31r8-m68k-businesscard.iso
      19057 04:16:07

Notice that NetBSD is using READ (6) commands.

Toni Wilen · 28 February 2013, 19:43

GUI removing built-in CD mounter image fixed. (Stupid bug, CD info shown in harddrive panel was queried from inserted image and it incorrectly checked if unit was already open..)

Quote:

You probably should emulate at least the unit attention / not ready to ready change condition, since that's how an operating system would typically detect that the disc has been changed.

Perhaps but I still don't think it is really needed.

mark_k · 28 February 2013, 22:16

There could in theory be problems if the OS cached some sectors of the current disc and the user changes the disc. If the OS can't detect the change, it could return stale data corresponding to the cached sectors.

I tested the latest winuae.exe with NetBSD and using dd to read the disc works now, though the off-by-one problem is still there, e.g. dd only reads 19056 sectors' worth of data instead of 19057. Could there be some other off-by-one error which was previously cancelled out by the READ CAPACITY off-by-one you fixed recently?

Or maybe not. Testing with the Debian HDF, that doesn't have the same off-by-one problem, the image file created is 19057 sectors. So:
NetBSD 6.0.1, SCSI or ATAPI CD drive: off-by-one, dd reads one too few sectors.
Debian, SCSI or ATAPI CD drive: dd reads the correct number of sectors.

At this point it may be more likely to be a regression in NetBSD rather than a WinUAE bug.

Edit to add: Both NetBSD 1.6.2 and 2.1 seem okay. They don't have the dd-reads-one-too-few-sectors issue.
Edit to add: NetBSD 3.1 also doesn't have the problem. NetBSD 4.0.1 and 5.2 do have the problem.

Toni Wilen · 01 March 2013, 16:52

Quote:

Originally Posted by mark_k

There could in theory be problems if the OS cached some sectors of the current disc and the user changes the disc. If the OS can't detect the change, it could return stale data corresponding to the cached sectors.

Ok, good enough reason. Done

mark_k · 21 March 2013, 12:19

It turns out that the off-by-one problem with NetBSD was definitely a NetBSD bug. I filed a bug report at netbsd.org, see that for details if interested.

28 February 2013, 22:16	#49
mark_k Registered User Join Date: Aug 2004 Location: Posts: 3,349	There could in theory be problems if the OS cached some sectors of the current disc and the user changes the disc. If the OS can't detect the change, it could return stale data corresponding to the cached sectors. I tested the latest winuae.exe with NetBSD and using dd to read the disc works now, though the off-by-one problem is still there, e.g. dd only reads 19056 sectors' worth of data instead of 19057. Could there be some other off-by-one error which was previously cancelled out by the READ CAPACITY off-by-one you fixed recently? Or maybe not. Testing with the Debian HDF, that doesn't have the same off-by-one problem, the image file created is 19057 sectors. So: NetBSD 6.0.1, SCSI or ATAPI CD drive: off-by-one, dd reads one too few sectors. Debian, SCSI or ATAPI CD drive: dd reads the correct number of sectors. At this point it may be more likely to be a regression in NetBSD rather than a WinUAE bug. Edit to add: Both NetBSD 1.6.2 and 2.1 seem okay. They don't have the dd-reads-one-too-few-sectors issue. Edit to add: NetBSD 3.1 also doesn't have the problem. NetBSD 4.0.1 and 5.2 do have the problem. Last edited by mark_k; 03 March 2013 at 22:10.

Similar Threads
Thread	Thread Starter	Forum	Replies	Last Post
Does Debian work on PPC boards?	wXR	Amiga scene	2	16 February 2013 02:35
Debian Linux boot regression	mark_k	support.WinUAE	15	28 January 2013 18:07
Guru when starting Debian 3.1 for Amiga	The Rom Alien	support.WinUAE	7	08 June 2005 17:11
MechForce & UAE (Debian) problems	l8gravely	support.Games	0	01 May 2005 05:40
Looking for Miggy emu to run under debian on A1	Severin	New to Emulation or Amiga scene	17	14 July 2003 13:42

21 March 2013, 12:19	#51
mark_k Registered User Join Date: Aug 2004 Location: Posts: 3,349	It turns out that the off-by-one problem with NetBSD was definitely a NetBSD bug. I filed a bug report at netbsd.org, see that for details if interested.

Currently Active Users Viewing This Thread: 1 (0 members and 1 guests)