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? 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 :-) 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? 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 _______________________________________________ [EMAIL PROTECTED] To unsubscribe, use the last form field at: https://lists.sourceforge.net/lists/listinfo/linux-usb-devel
