MODE SELECT (10) Input/Output Error

vbimport

#1

Without wanting to sound like i am jumping on the bandwagon, but i’m also writting a cd-writing program for Linux. Although i am only really interested in audio.

However, I seem to be faltering quite early on. I can read commands over the generic scsi driver (using SG_IO ioctl) and can perform basic open drive and MODE SENSE(10) commands, which returns the right data. But now i’m trying to change the write paramaters page (0x05). So i read the data, change the settings i want to and write it back. Now the wierd part is that the settings are changed (verified by a re-read of the page), but my command creates an input/output error number in the sg_io_hdr sense.

Any ideas?

Andrew


#2

With MODE_SENSE(10), in your case, you get the “write parameters page (0x05)”. Then, to send the page to the drive, you have to use MODE_SELECT(10) command, sending the page as data.
I hope this helps you :S


#3

Thanks for your reply.

Yes i agree, this is what i am trying to achieve, i get the data from MODE SENSE(10), with page code 0x05, which completes successfully. I then use this data to send back using MODE SELECT(10) in the same format as i received the data, the command descriptor block i am using for the MODE SELECT(10) is:

0x55, 0, 0, 0, 0, 0, 0, 0, 50, 0;

But i have also tried 0x10 and 0x11 for the second byte as i read somewhere that the PF bit should be set and so i also tried setting the SP bit. I’ve also tried setting the 50 to 58 to include the size of the header, but i feel this is wrong and it also didn’t help.
Anyway they all have the same effect. The command makes the changes to the logical unit, but EIO is returned in the sense buffer of the sg_io_hdr struct. I will need to know that the command has completed, although i suppose i can do so by re-checking the values with a subsequent read.

Looking at the Linux docs EIO on a write is given as:
Size given as 3rd argument less than size of old
header structure (sg_header). Additionally a write()
with the old header will yield this error for most
detected malformed requests.

I don’t really understand the size issue (i’ve tried adjusting the command block size field in the header which seems to make no difference and as far as i can tell should be 0x0a) and i would have thought a malformed request would not be executed by the logical unit.

Anyone??

Andrew


#4

dxfer_direction = SG_DXFER_TO_DEV ???


#5

I have set the direction to that as well. I’m now thinking it might be a quirk of this particular drive? Its a Sony DVDRW DWU10A - although i’d be surprised. I am also using a rather old linux kernel to do the dev work at the moment. But then again i am clutching at straws!

My data packet sent with the command block descriptor above is:

0x00 0x3a 0x21 0x00 0x00 0x00 0x00 0x00 0x05 0x32 0x60 0xe7 0x0a 0x10 0x00 0x00 0x20 0x00 0x00 0x00 0x00 0x20 0x00 0x96 0x00 0x00 0x00 0x00 0x00 0x00 0x00 0x00 0x00 0x00 0x00 0x00 0x00 0x00 0x00 0x00 0x00 0x00 0x00 0x00 0x00 0x00 0x00 0x00 0x00 0x00 0x00 0x00 0x00 0x00 0x00 0x00 0x00 0x00

Which according to me has all the right bits in the right place. If anyone could see any obvious problems…?


#6

OK so doing a bit more digging i’m printing out the sense buffer (sbp), the info field is set to 0x01 - SG_INFO_CHECK which indicates something went wrong.

sbp is:

0x70 0x00 0x05 0x00 0x00 0x00 0x00 0x12 0x00 0x00 0x00 0x00 0x1a 0x00 0x00 0x00 0x00 0x00 0x00 0x00 0x00 0x00 0x00 0x00 0x00 0x00

But i’m a bit lost as to how to work out what is going wrong from these values? I was hoping to track down what the problem was but the error codes with sense keys in appendix A of “Mt. Fuji Commands for Multimedia Devices Version 6” datasheet doesn’t seem to show you. Anyone know what these codes mean?

Andrew

EDIT: I think i just got it:
sbp[2] <3:0> = Sense Key
sbp[12] = ASC
sbp[13] = ASC Q

but i still don’t know what sbp[0] or sbp[7] is for.
However this does equate to a parameter list length error, so i guess my mode page is the wrong length. How can this be if i simply return the page i read using MODE SENSE…
I realise i’m potentially writing too many posts, but i thought i’d keep the thread updated as i went along. You never know it may help someone! :slight_smile:


#7

OK so me again!

After working out that it was a parameter length error, i got fed up trying to work out how big it should be and started using incremental numbers, eventually using a parameter list length of 60 removed the error! Now i suppose i should go back and work out why that is, but i don’t understand when the entire mode page (with header) is 58 bytes and the command block is 10 - where does 60 come from! I’ll need to know for when i try to MODE SELECT other pages i guess…??

Thanks for listening anyway!


#8

If you look at MMC1, the full write parameters mode page is 56 bytes, and from SPC1, the mode parameter header is 8 bytes for the mode select/sense(10), so this makes a total of 64 bytes. This is assuming that there are no mode parameter block descriptors, i.e. 0 being used.

In the mode parameter header, there is mode data length. This may be used to calculate the data page length. Then again, there r drives which only work with specific length.