Hello
Would there be a way to propagate the device name back from the scsi
system to the usb so it can name the device which is disconnected in
the output? This saves needing to go hunting to find what the
disconnected device was.
I'll be happy to donate to Linux Foundation if they need some cash to
cover the time to do this.
I'm not on the mailing list, so please include my email address in any replies.
Regards, Jon
Apr 5 18:56:33 data-laptop kernel: [65426.948048] usb 5-1: new high
speed USB device using ehci_hcd and address 6
Apr 5 18:56:33 data-laptop kernel: [65427.132049] usb 5-1:
configuration #1 chosen from 1 choice
Apr 5 18:56:33 data-laptop kernel: [65427.152066] scsi4 : SCSI
emulation for USB Mass Storage devices
Apr 5 18:56:38 data-laptop kernel: [65432.153182] scsi 4:0:0:0:
Direct-Access Samsung Mighty Drive PMAP PQ: 0 ANSI: 0 CCS
Apr 5 18:56:38 data-laptop kernel: [65432.454122] sd 4:0:0:0: [sdc]
2014208 512-byte hardware sectors (1031 MB)
Apr 5 18:56:38 data-laptop kernel: [65432.454867] sd 4:0:0:0: [sdc]
Write Protect is off
Apr 5 18:56:38 data-laptop kernel: [65432.458744] sd 4:0:0:0: [sdc]
2014208 512-byte hardware sectors (1031 MB)
Apr 5 18:56:38 data-laptop kernel: [65432.459866] sd 4:0:0:0: [sdc]
Write Protect is off
Apr 5 18:56:38 data-laptop kernel: [65432.461202] sdc: sdc1
Apr 5 18:56:38 data-laptop kernel: [65432.462224] sd 4:0:0:0: [sdc]
Attached SCSI removable disk
Apr 5 18:56:38 data-laptop kernel: [65432.462547] sd 4:0:0:0:
Attached scsi generic sg2 type 0
Apr 5 18:56:58 data-laptop kernel: [65451.669308] usb 5-1: USB
disconnect, address 6
On Sun, Apr 05, 2009 at 07:04:45PM +0100, Jon Grant wrote:
> Hello
>
> Would there be a way to propagate the device name back from the scsi
> system to the usb so it can name the device which is disconnected in
> the output? This saves needing to go hunting to find what the
> disconnected device was.
What do you mean, all the info needed is already in the messages below,
what more do you need?
> Apr 5 18:56:33 data-laptop kernel: [65426.948048] usb 5-1: new high speed USB device using ehci_hcd and address 6
> Apr 5 18:56:33 data-laptop kernel: [65427.132049] usb 5-1: configuration #1 chosen from 1 choice
> Apr 5 18:56:33 data-laptop kernel: [65427.152066] scsi4 : SCSI emulation for USB Mass Storage devices
> Apr 5 18:56:38 data-laptop kernel: [65432.153182] scsi 4:0:0:0: Direct-Access Samsung Mighty Drive PMAP PQ: 0 ANSI: 0 CCS
> Apr 5 18:56:38 data-laptop kernel: [65432.454122] sd 4:0:0:0: [sdc] 2014208 512-byte hardware sectors (1031 MB)
> Apr 5 18:56:38 data-laptop kernel: [65432.454867] sd 4:0:0:0: [sdc] Write Protect is off
> Apr 5 18:56:38 data-laptop kernel: [65432.458744] sd 4:0:0:0: [sdc] 2014208 512-byte hardware sectors (1031 MB)
> Apr 5 18:56:38 data-laptop kernel: [65432.459866] sd 4:0:0:0: [sdc] Write Protect is off
> Apr 5 18:56:38 data-laptop kernel: [65432.461202] sdc: sdc1
> Apr 5 18:56:38 data-laptop kernel: [65432.462224] sd 4:0:0:0: [sdc] Attached SCSI removable disk
> Apr 5 18:56:38 data-laptop kernel: [65432.462547] sd 4:0:0:0: Attached scsi generic sg2 type 0
> Apr 5 18:56:58 data-laptop kernel: [65451.669308] usb 5-1: USB disconnect, address 6
confused,
greg k-h
Hello
2009/4/6 Greg KH <[email protected]>:
> On Sun, Apr 05, 2009 at 07:04:45PM +0100, Jon Grant wrote:
>> Hello
>>
>> Would there be a way to propagate the device name back from the scsi
>> system to the usb so it can name the device which is disconnected in
>> the output? This saves needing to go hunting to find what the
>> disconnected device was.
>
> What do you mean, all the info needed is already in the messages below,
> what more do you need?
The idea was that the disconnect could give more information.
Otherwise it's necessary to go hunting back up the log to track down
which USB device was the one disconnected (which works fine, but isn't
ideal for time consumed doing this regularly).
[...]
>> Apr 5 18:56:58 data-laptop kernel: [65451.669308] usb 5-1: USB disconnect, address 6
>
>
> confused,
If it said instead:
Apr 5 18:56:58 data-laptop kernel: usb 5-1: USB disconnect, address 6
(Samsung Mighty Drive)
Would this not be clearer?
Please include my email address in any replies.
Regards, Jon
On Mon, Apr 06, 2009 at 11:11:55AM +0200, Jon Grant wrote:
> Hello
>
> 2009/4/6 Greg KH <[email protected]>:
> > On Sun, Apr 05, 2009 at 07:04:45PM +0100, Jon Grant wrote:
> >> Hello
> >>
> >> Would there be a way to propagate the device name back from the scsi
> >> system to the usb so it can name the device which is disconnected in
> >> the output? This saves needing to go hunting to find what the
> >> disconnected device was.
> >
> > What do you mean, all the info needed is already in the messages below,
> > what more do you need?
>
> The idea was that the disconnect could give more information.
> Otherwise it's necessary to go hunting back up the log to track down
> which USB device was the one disconnected (which works fine, but isn't
> ideal for time consumed doing this regularly).
As you yanked the device out, don't you know which one it was?
> [...]
> >> Apr ?5 18:56:58 data-laptop kernel: [65451.669308] usb 5-1: USB disconnect, address 6
> >
> >
> > confused,
>
> If it said instead:
>
> Apr 5 18:56:58 data-laptop kernel: usb 5-1: USB disconnect, address 6
> (Samsung Mighty Drive)
>
> Would this not be clearer?
That might be nice, but note that the kernel doesn't even know the
strings after a device is gone, as it had to read them from the device
:)
Also, lots of devices don't have strings describing them, and some of
them are just flat out wrong. And, if you have multiple devices of the
same type, it wouldn't really help out any either.
So it would be a bit difficult to do this, sorry.
thanks,
greg k-h
Hi
2009/4/6 Greg KH <[email protected]>:
> On Mon, Apr 06, 2009 at 11:11:55AM +0200, Jon Grant wrote:
[..]
>> The idea was that the disconnect could give more information.
>> Otherwise it's necessary to go hunting back up the log to track down
>> which USB device was the one disconnected (which works fine, but isn't
>> ideal for time consumed doing this regularly).
>
> As you yanked the device out, don't you know which one it was?
I do get devices disappear without me disconnecting them, various
different PCs, and laptops.
[..]
>> Apr 5 18:56:58 data-laptop kernel: usb 5-1: USB disconnect, address 6
>> (Samsung Mighty Drive)
>>
>> Would this not be clearer?
>
> That might be nice, but note that the kernel doesn't even know the
> strings after a device is gone, as it had to read them from the device
> :)
Yeah, would need to cache the names, perhaps you don't want to bloat
the kernel that way.
> Also, lots of devices don't have strings describing them, and some of
> them are just flat out wrong. And, if you have multiple devices of the
> same type, it wouldn't really help out any either.
Well personally I would rather at least know the class of the device
which went, and would put up with incorrect info in preference to no
info.
> So it would be a bit difficult to do this, sorry.
Thanks anyway for considering it.
Best regards, Jon
On Mon, Apr 6, 2009 at 3:33 PM, Jon Grant <[email protected]> wrote:
> Hi
>
> 2009/4/6 Greg KH <[email protected]>:
>> On Mon, Apr 06, 2009 at 11:11:55AM +0200, Jon Grant wrote:
> [..]
>>> The idea was that the disconnect could give more information.
>>> Otherwise it's necessary to go hunting back up the log to track down
>>> which USB device was the one disconnected (which works fine, but isn't
>>> ideal for time consumed doing this regularly).
>>
>> As you yanked the device out, don't you know which one it was?
>
> I do get devices disappear without me disconnecting them, various
> different PCs, and laptops.
>
> [..]
>>> Apr ?5 18:56:58 data-laptop kernel: usb 5-1: USB disconnect, address 6
>>> (Samsung ?Mighty Drive)
>>>
>>> Would this not be clearer?
>>
>> That might be nice, but note that the kernel doesn't even know the
>> strings after a device is gone, as it had to read them from the device
>> :)
>
> Yeah, would need to cache the names, perhaps you don't want to bloat
> the kernel that way.
>
>> Also, lots of devices don't have strings describing them, and some of
>> them are just flat out wrong. ?And, if you have multiple devices of the
>> same type, it wouldn't really help out any either.
>
> Well personally I would rather at least know the class of the device
> which went, and would put up with incorrect info in preference to no
> info.
You could perhaps write a script that could look through the logs and
infer which device it was without touching the kernel at all.
>
>> So it would be a bit difficult to do this, sorry.
>
> Thanks anyway for considering it.
>
> Best regards, Jon
> --
> To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
> the body of a message to [email protected]
> More majordomo info at ?http://vger.kernel.org/majordomo-info.html
> Please read the FAQ at ?http://www.tux.org/lkml/
>
Jon Grant wrote:
> 2009/4/6 Greg KH <[email protected]>:
>> On Mon, Apr 06, 2009 at 11:11:55AM +0200, Jon Grant wrote:
> [..]
>>> The idea was that the disconnect could give more information.
>>> Otherwise it's necessary to go hunting back up the log to track down
>>> which USB device was the one disconnected (which works fine, but isn't
>>> ideal for time consumed doing this regularly).
>>
>> As you yanked the device out, don't you know which one it was?
>
> I do get devices disappear without me disconnecting them, various
> different PCs, and laptops.
Try FireWire then. ;-)
> [..]
>>> Apr 5 18:56:58 data-laptop kernel: usb 5-1: USB disconnect, address 6
>>> (Samsung Mighty Drive)
>>>
>>> Would this not be clearer?
>>
>> That might be nice, but note that the kernel doesn't even know the
>> strings after a device is gone, as it had to read them from the device
>> :)
>
> Yeah, would need to cache the names, perhaps you don't want to bloat
> the kernel that way.
"Samsung Mighty Drives" is some information which the Linux SCSI layer
obtained from the device's response to the SCSI INQUIRY command. The
USB layer sits beneath the SCSI layer and passes SCSI commands and
responses through without looking at them... most of the time, at least.
I haven't checked whether usb-storage examines SCSI inquiry buffers
these days. Typically we don't want to duplicate high-level
functionality into lower layers, hence knowledge of SCSI commands and
responses is mostly kept out of Linux' SCSI transports layer (e.g.
usb-storage).
The INQUIRY reposne however /is/ already cached by Linux. It's in
<scsi/scsi_device.h>'s struct scsi_device { .inquiry_len; .inquiry; }.
Furthermore, .vendor; .model; .rev; point into respective byte fields in
the inquiry response buffer. Here is the code line which produces the
initial dmesg line with the vendor/model/rev strings:
http://lxr.linux.no/linux+v2.6.29/drivers/scsi/scsi_scan.c#L847
However, it would be slightly difficult for the USB stack to access this
information. It's in a (grand-grand-?)child of the actual USB device
representations with which the USB stack deals directly. To implement
what you want, the USB stack would have to check whether
(grand-grand-?)children of type scsi_device were ever created, then peek
into its device data (with some SCSI-specific knowledge). Or the
usb-storage driver would have to watch for scsi_device creations by the
upper layers (i.e. by layers outside of the USB stack) and copy their
data into whichever USB parent device for possible later use.
Not quite cleanly doable.
Plus, Greg was right when he said that the strings in these INQUIRY
responses are generally not unique and sometimes pure garbage.
--
Stefan Richter
-=====-==--= -=-- --===
http://arcgraph.de/sr/