On Mon, Apr 29, 2002 at 11:47:12AM -0700, Haefliger, Juerg wrote: > I tried to implement Matt's suggestions but I'm having problems. > When an invalid logical unit is selected, i.e., there is no memory card > in that particular slot, the driver terminates any command except > REQUEST SENSE with CHECK CONDITION and returns NOT READY / MEDIUM NOT > PRESENT in response to a REQUEST SENSE command. The kernel however > doesn't seem to understand this and keeps trying to read the capacity of > the 'non-present' logical unit, so I must do something wrong (see kernel > output below). > > 1) I get '-- unexpectedly short transfer' when terminating a command > with CHECK CONDITION. what does that mean, what am I doing wrong?
Looks like your transport driver is indicating a US_BULK_TRANSFER_SHORT in srb->result. Without looking at your code, it's difficult to say why that is. My guess is that you're not setting the return code properly. You should be putting US_BULK_TRANSFER_GOOD (i.e. 0x0) into that slot. Yes, this is ugly -- it's on the list of things to change for 2.5.x > 2) The kernel still tries to read the logical unit's capacity although > it signaled earlier (as a response to TEST_UNIT_READY) that there is no > medium present. I think I read somewhere that this is a particular Linux > feature. Correct? Anyway, this shouldn't be a problem if my driver would > respond correctly which it obviously doesn't :-) Linux will try to read the capacity if it's just "not ready". If it's non-existant, then it won't. Remeber, to the kernel someone could insert media at any time -- heck, the media could be there and just not spinning yet. > 3) The SCSI spec says that in response to the selection of a logical > unit that is not valid because 'the target supports the logical unit, > but the peripheral device is currently not attached to the target' the > target should return ILLEGAL REQUEST / LOGICAL UNIT NOT SUPPORTED. Now > I'm confused whether to return NOT READY / MEDIUM NOT PRESENT or ILLEGAL > REQUEST / LOGICAL UNIT NOT SUPPORTED. Where is the difference? The difference is whether the unit is there or not. Note that LUNs are only probed the first time the device is attached (per reboot, that is). So you want the kernel to think the slot is there even if empty, because someone could detach the unit, add a card, and re-attach the unit. If you return LUN Not Supported, the user will have to reboot (or unload the usb-storage module and reload it) to get the other slot recognized. Matt > > thanks > ...juerg > > kernel: usb-storage: Command TEST_UNIT_READY (6 bytes) > kernel: usb-storage: 00 20 00 00 00 00 00 00 00 00 01 00 > kernel: usb-storage: ipaq_transport: TEST_UNIT_READY -> lun = 1 > kernel: usb-storage: ipaq_rcvinfo: no MMC in slot 1 > kernel: usb-storage: -- unexpectedly short transfer > kernel: usb-storage: Issuing auto-REQUEST_SENSE > kernel: usb-storage: ipaq_transport: REQUEST_SENSE -> lun = 1 > kernel: usb-storage: -- Result from auto-sense is 0 > kernel: usb-storage: -- code: 0xf0, key: 0x2, ASC: 0x3a, ASCQ: 0x0 > kernel: usb-storage: Not Ready: (unknown ASC/ASCQ) > kernel: usb-storage: scsi cmd done, result=0x2 > kernel: usb-storage: *** thread sleeping. > kernel: usb-storage: queuecommand() called > kernel: usb-storage: *** thread awakened. > kernel: usb-storage: Command READ_CAPACITY (10 bytes) > kernel: usb-storage: 25 20 00 00 00 00 00 00 00 00 01 00 > kernel: usb-storage: ipaq_transport: READ_CAPACITY -> lun = 1 > kernel: usb-storage: -- unexpectedly short transfer > kernel: usb-storage: Issuing auto-REQUEST_SENSE > kernel: usb-storage: ipaq_transport: REQUEST_SENSE -> lun = 1 > kernel: usb-storage: -- Result from auto-sense is 0 > kernel: usb-storage: -- code: 0xf0, key: 0x2, ASC: 0x3a, ASCQ: 0x0 > kernel: usb-storage: Not Ready: (unknown ASC/ASCQ) > kernel: usb-storage: scsi cmd done, result=0x2 > kernel: usb-storage: *** thread sleeping. > kernel: usb-storage: queuecommand() called > kernel: usb-storage: *** thread awakened. > kernel: usb-storage: Command READ_CAPACITY (10 bytes) > kernel: usb-storage: 25 20 00 00 00 00 00 00 00 00 01 00 > kernel: usb-storage: ipaq_transport: READ_CAPACITY -> lun = 1 > kernel: usb-storage: -- unexpectedly short transfer > kernel: usb-storage: Issuing auto-REQUEST_SENSE > kernel: usb-storage: ipaq_transport: REQUEST_SENSE -> lun = 1 > kernel: usb-storage: -- Result from auto-sense is 0 > kernel: usb-storage: -- code: 0xf0, key: 0x2, ASC: 0x3a, ASCQ: 0x0 > kernel: usb-storage: Not Ready: (unknown ASC/ASCQ) > kernel: usb-storage: scsi cmd done, result=0x2 > kernel: usb-storage: *** thread sleeping. > kernel: usb-storage: queuecommand() called > kernel: usb-storage: *** thread awakened. > kernel: usb-storage: Command READ_CAPACITY (10 bytes) > kernel: usb-storage: 25 20 00 00 00 00 00 00 00 00 01 00 > kernel: usb-storage: ipaq_transport: READ_CAPACITY -> lun = 1 > kernel: usb-storage: -- unexpectedly short transfer > kernel: usb-storage: Issuing auto-REQUEST_SENSE > kernel: usb-storage: ipaq_transport: REQUEST_SENSE -> lun = 1 > kernel: usb-storage: -- Result from auto-sense is 0 > kernel: usb-storage: -- code: 0xf0, key: 0x2, ASC: 0x3a, ASCQ: 0x0 > kernel: usb-storage: Not Ready: (unknown ASC/ASCQ) > kernel: usb-storage: scsi cmd done, result=0x2 > kernel: usb-storage: *** thread sleeping. > kernel: sdc : READ CAPACITY failed. > kernel: sdc : status = 1, message = 00, host = 0, driver = 08 > kernel: Info fld=0x0, Current sd00:00: sense key Not Ready > kernel: Additional sense indicates Medium not present > kernel: sdc : block size assumed to be 512 bytes, disk size 1GB. > kernel: sdc: I/O error: dev 08:20, sector 0 > kernel: I/O error: dev 08:20, sector 0 > kernel: unable to read partition table > > > -----Original Message----- > From: Matthew Dharm [mailto:[EMAIL PROTECTED]] > Sent: Monday, April 22, 2002 2:33 PM > To: Haefliger, Juerg > Cc: [EMAIL PROTECTED] > Subject: Re: [linux-usb-devel] Question on mass storage and LUN > > > Return MEDIUM_NOT_PRESENT on any condition which requires media access. > That is, INQUIRY should always work. > > Also, remember to return "not ready to ready transition" on the first > media > access command, so the host knows that the device was just > (re-)attached, > and thus we have to throw away all previous info about the media. > > The upper SCSI layer will take care of media change detection if you do > it > right. > > Matt > > On Mon, Apr 22, 2002 at 12:25:04PM -0700, Haefliger, Juerg wrote: > > Hello, > > > > I'm currently writting a driver for the Compaq PA-2 MP3 player. This > device can hold up to 2 memory cards and I'm implementing the driver > such that is treats the PA-2 as dual-LUN device. > > The question now is how/when to I report to the upper layer if there > is no memory card in one (or both) of the slots? Should I report that > the target is not capable of supporting the LUN on an 'INQUIRY' command, > or should I return 'MEDIUM NOT PRESENT' on a 'TEST UNIT READY' command, > or any other method? > > And what happens if the device is reattached with a different memory > configuration? I noticed, that none of the INQUIRY/TEST UNIT READY > commands are executed in this case. What is the correct way to reset the > device configuration? > > > > thanks > > ...juerg > > > > _______________________________________________ > > [EMAIL PROTECTED] > > To unsubscribe, use the last form field at: > > https://lists.sourceforge.net/lists/listinfo/linux-usb-devel > > -- > Matthew Dharm Home: > [EMAIL PROTECTED] > Maintainer, Linux USB Mass Storage Driver > > Why am I talking to a toilet brush? > -- CEO > User Friendly, 4/30/1998 -- Matthew Dharm Home: [EMAIL PROTECTED] Maintainer, Linux USB Mass Storage Driver IT KEEPS ASKING ME WHERE I WANT TO GO TODAY! I DONT WANT TO GO ANYWHERE! -- Greg User Friendly, 11/28/97
msg06149/pgp00000.pgp
Description: PGP signature
