My apologies if this is not really a kernel issue, but
I've recently upgraded to SUSE9.1, and now I am having trouble with
automatically hotplugging my USB2 harddisk. This is because the
userspace hotplug magic runs a prog called hwscan. If I disable the
userspace stuff, everything works fine. Also my USB1 pendrive works fine
with the userspace hotplug.
The problem is that both hwscan and usb-storage get stuck in the 'D"
state until I unplug the harddisk.
A strace of hwscan shows:
21141 open("/dev/sda", O_RDONLY|O_NONBLOCK) = 3
21141 ioctl(3, 0x301, 0xbfffeba0) = 0
21141 ioctl(3, BLKSSZGET, 0xbfffeb9c) = 0
21141 ioctl(3, 0x80041272, 0xbfffeb90) = 0
21141 ioctl(3, FIBMAP, 0xbfffec40) = 0 <--- hwscan gets stuck here
The last ioctl corresponds to this bit of code in
hwinfo-8.38/src/hd/block.c:
#ifndef SCSI_IOCTL_SEND_COMMAND
#define SCSI_IOCTL_SEND_COMMAND 1
#endif
...
memset(scsi_cmd_buf, 0, sizeof scsi_cmd_buf);
// ###### FIXME: smaller!
*((unsigned *) (scsi_cmd_buf + 4)) = sizeof scsi_cmd_buf - 0x100;
scsi_cmd_buf[8 + 0] = 0x12;
scsi_cmd_buf[8 + 1] = 0x01;
scsi_cmd_buf[8 + 2] = 0x80;
scsi_cmd_buf[8 + 4] = 0xff;
k = ioctl(fd, SCSI_IOCTL_SEND_COMMAND, scsi_cmd_buf);
So it appears that the driver hangs because of a SCSI command. Is this
kernel bug, and if so, where do I fix it?
TIA,
Bart
--
Bart Hartgers - TUE Eindhoven
http://plasimo.phys.tue.nl/bart/contact.html
Sorry, I forgot to mention that the problem remains under 2.6.7.
--
Bart Hartgers - TUE Eindhoven
http://plasimo.phys.tue.nl/bart/contact.html
Hi Bart,
On Tue, Jun 29, 2004 at 11:37:36AM +0200, Bart Hartgers wrote:
> The problem is that both hwscan and usb-storage get stuck in the 'D"
> state until I unplug the harddisk.
>
> A strace of hwscan shows:
>
> 21141 open("/dev/sda", O_RDONLY|O_NONBLOCK) = 3
> 21141 ioctl(3, 0x301, 0xbfffeba0) = 0
> 21141 ioctl(3, BLKSSZGET, 0xbfffeb9c) = 0
> 21141 ioctl(3, 0x80041272, 0xbfffeb90) = 0
> 21141 ioctl(3, FIBMAP, 0xbfffec40) = 0 <--- hwscan gets stuck here
>
> The last ioctl corresponds to this bit of code in
> hwinfo-8.38/src/hd/block.c:
>
> #ifndef SCSI_IOCTL_SEND_COMMAND
> #define SCSI_IOCTL_SEND_COMMAND 1
> #endif
>
> ...
>
> memset(scsi_cmd_buf, 0, sizeof scsi_cmd_buf);
> // ###### FIXME: smaller!
> *((unsigned *) (scsi_cmd_buf + 4)) = sizeof scsi_cmd_buf - 0x100;
> scsi_cmd_buf[8 + 0] = 0x12;
> scsi_cmd_buf[8 + 1] = 0x01;
> scsi_cmd_buf[8 + 2] = 0x80;
> scsi_cmd_buf[8 + 4] = 0xff;
>
> k = ioctl(fd, SCSI_IOCTL_SEND_COMMAND, scsi_cmd_buf);
>
> So it appears that the driver hangs because of a SCSI command. Is this
> kernel bug, and if so, where do I fix it?
To me it looks like a bug in the USB stick.
It probably locks up when you ask for VPD page 0x80 (serial number)
of the device with INQUIRY.
Some shitty USB devices lock up when you ask for more than 36 bytes
with INQUIRY. See code in scsi_scan.c and the BLIST_INQUIRY_36 and
_58 flags.
Your device may even do so when you don't ask for standard INQUIRY
data but for EVPD page 0x80 :-(
Does it work if you send the INQUIRY with 36 bytes allocation length?
scsi_cmd_buf[8 + 4] = 0x26;
--
Kurt Garloff <[email protected]> Cologne, DE
SUSE LINUX AG / Novell, Nuernberg, DE Director SUSE Labs
Hi,
On Tue, 29 Jun 2004, Kurt Garloff wrote:
> On Tue, Jun 29, 2004 at 11:37:36AM +0200, Bart Hartgers wrote:
> > The problem is that both hwscan and usb-storage get stuck in the 'D"
> > state until I unplug the harddisk.
> >
> > A strace of hwscan shows:
> >
> > 21141 open("/dev/sda", O_RDONLY|O_NONBLOCK) = 3
> > 21141 ioctl(3, 0x301, 0xbfffeba0) = 0
> > 21141 ioctl(3, BLKSSZGET, 0xbfffeb9c) = 0
> > 21141 ioctl(3, 0x80041272, 0xbfffeb90) = 0
> > 21141 ioctl(3, FIBMAP, 0xbfffec40) = 0 <--- hwscan gets stuck here
[...]
> Does it work if you send the INQUIRY with 36 bytes allocation length?
> scsi_cmd_buf[8 + 4] = 0x26;
It's indeed the inquiry size, sticking to the minium 36 bytes helps.
That's fixed in sles9. Update for 9.1 planned.
Steffen
On Tue, Jun 29, 2004 at 11:45:57AM +0200, Kurt Garloff wrote:
> Does it work if you send the INQUIRY with 36 bytes allocation length?
> scsi_cmd_buf[8 + 4] = 0x26;
I mean 0x24 of course ...
--
Kurt Garloff <[email protected]> Cologne, DE
SUSE LINUX AG / Novell, Nuernberg, DE Director SUSE Labs
Kurt,
I tried both 0x26 and 0x24, but the problem persists. Guess I bought
crappy hardware (again). For now, I've removed the offending ioctl, and
everything sort of works.
Thanks,
Bart
On 29 Jun, Kurt Garloff wrote:
> Hi Bart,
>
> On Tue, Jun 29, 2004 at 11:37:36AM +0200, Bart Hartgers wrote:
>> The problem is that both hwscan and usb-storage get stuck in the 'D"
>> state until I unplug the harddisk.
>>
>> A strace of hwscan shows:
>>
>> 21141 open("/dev/sda", O_RDONLY|O_NONBLOCK) = 3
>> 21141 ioctl(3, 0x301, 0xbfffeba0) = 0
>> 21141 ioctl(3, BLKSSZGET, 0xbfffeb9c) = 0
>> 21141 ioctl(3, 0x80041272, 0xbfffeb90) = 0
>> 21141 ioctl(3, FIBMAP, 0xbfffec40) = 0 <--- hwscan gets stuck
>> here
>>
>> The last ioctl corresponds to this bit of code in
>> hwinfo-8.38/src/hd/block.c:
>>
>> #ifndef SCSI_IOCTL_SEND_COMMAND
>> #define SCSI_IOCTL_SEND_COMMAND 1
>> #endif
>>
>> ...
>>
>> memset(scsi_cmd_buf, 0, sizeof scsi_cmd_buf);
>> // ###### FIXME: smaller!
>> *((unsigned *) (scsi_cmd_buf + 4)) = sizeof scsi_cmd_buf - 0x100;
>> scsi_cmd_buf[8 + 0] = 0x12;
>> scsi_cmd_buf[8 + 1] = 0x01;
>> scsi_cmd_buf[8 + 2] = 0x80;
>> scsi_cmd_buf[8 + 4] = 0xff;
>>
>> k = ioctl(fd, SCSI_IOCTL_SEND_COMMAND, scsi_cmd_buf);
>>
>> So it appears that the driver hangs because of a SCSI command. Is
>> this kernel bug, and if so, where do I fix it?
>
> To me it looks like a bug in the USB stick.
> It probably locks up when you ask for VPD page 0x80 (serial number)
> of the device with INQUIRY.
> Some shitty USB devices lock up when you ask for more than 36 bytes
> with INQUIRY. See code in scsi_scan.c and the BLIST_INQUIRY_36 and
> _58 flags.
> Your device may even do so when you don't ask for standard INQUIRY
> data but for EVPD page 0x80 :-(
>
> Does it work if you send the INQUIRY with 36 bytes allocation length?
> scsi_cmd_buf[8 + 4] = 0x26;