On Sun, 30 Sep 2007, The Almighty Pegasus Epsilon wrote: > On 9/30/07, Alan Stern <[EMAIL PROTECTED]> wrote: > > Strictly speaking, "character" and "block" are properties of the > > driver, not of the device. It's perfectly possible to have both a > > character driver and a block driver for the same device (although they > > better not both be loaded at the same time!). > > > > Anyway, only SCSI devices get sg nodes; HID devices don't. In thie > > case sg0 refers to the mass-storage interface of the WD MyBook device, > > not the HID interface. (The HID interface corresponds to the > > /class/input/input1 device, as you can see in the log.) sg1 refers to > > the other, working USB device. But this isn't particularly helpful for > > solving your main problem. > > I was under the impression that sg meant SCSI generic, ie, any kind of > device you'd like to hook to a SCSI bus.
That's right. > For example, I'm pretty sure > there are SCSI keyboards, which would absolutely be a character device > by nature, not just by driver. True. Although if somebody wanted to, they _could_ write a block device driver for a keyboard. It wouldn't be very useful. > > But only the other device worked with the SCSI disk driver. It's > > undoubtedly because the other device (sg1) reports itself as type 0 = > > disk drive and the WD device (sg0) reports itself as type 13 = > > enclosure -- I don't know what that's supposed to mean. Whatever it > > is, the SCSI disk driver doesn't accept it. > > > > Now I don't know if this will work or if it's the right thing to do, > > but you can try it. Edit the kernel source file drivers/scsi/sd.c. > > Near the beginning is a line saying > > > > MODULE_ALIAS_SCSI_DEVICE(TYPE_DISK); > > > > You can add a line saying > > > > MODULE_ALIAS_SCSI_DEVICE(TYPE_ENCLOSURE); > > > > Also, at the start of the sd_probe() function is this line: > > > > if (sdp->type != TYPE_DISK && sdp->type != TYPE_MOD && sdp->type != > > TYPE_RBC) > > > > You should add into that an extra test: > > > > if (sdp->type != TYPE_DISK && sdp->type != TYPE_MOD && sdp->type != > > TYPE_RBC > > && sdp->type != TYPE_ENCLOSURE) > > > > That will allow the SCSI disk driver to recognize the WD device. > > Whether it will end up working correctly is a different question... > > > > Alan Stern > > An interesting idea, for the hell of it I tried it. It did not work, > it simply created a "block" device node that "cat /dev/sda" (yes, it > usurped the old sda, which is now sdb) gives no output for. Correct me > if I'm wrong, but if it were working, it should dump a terabyte of > random gibberish to my screen. Yes. Well maybe not random gibberish, but the idea is right. > If you check the output from /proc/bus/usb/devices, it very clearly > shows 1) the hub, 2) the external enclosure that works, and 3) the one > that doesn't, but the one that doesn't work has two "I" lines, while > everything else has only one: > > I:* If#= 0 Alt= 0 #EPs= 1 Cls=09(hub ) Sub=00 Prot=00 Driver=hub > > I:* If#= 0 Alt= 0 #EPs= 2 Cls=08(stor.) Sub=06 Prot=50 Driver=usb-storage > I:* If#= 1 Alt= 0 #EPs= 1 Cls=03(HID ) Sub=00 Prot=00 Driver=usbhid > > I:* If#= 0 Alt= 0 #EPs= 2 Cls=08(stor.) Sub=06 Prot=50 Driver=usb-storage > > the Sub=00 Prot=00 Driver=usbhid gets registered fine, and with the > patch, it makes a corresponding (but non-functional) block node to go > with it. but the Sub=06 Prot=50 Driver=usb-storage never makes it > through to my /dev and that's exactly the problem. No, you are confused. First, you have this hangup regarding the extra HID interface. The fact is, it doesn't affect the mass-storage aspect of the device at all. The two are quite independent. Second, the non-functional block node you saw with the patch corresponds to interface 0, the "enclosure" driven by usb-storage -- not to the HID interface. This probably would be easy to see from the dmesg log, but you failed to include it. > I think what's missing is another layer of abstraction. Are other > Enclosures properly handled by linux-usb (as opposed to the obviously > functional Direct-Access)? "Enclosure" is a SCSI concept; it has nothing to do with usb-storage. The plain truth is that usb-storage is working fine; the difficulty you are encountering lies in the SCSI stack, not in the USB stack. > Possibly of interest is the result of the patch you suggested: > > sd 0:0:0:0: [sda] READ CAPACITY failed > sd 0:0:0:0: [sda] Result: hostbyte=0x00 driverbyte=0x08 > sd 0:0:0:0: [sda] Sense Key : 0x5 [current] > sd 0:0:0:0: [sda] ASC=0x20 ASCQ=0x0 > sd 0:0:0:0: [sda] Test WP failed, assume Write Enabled > sd 0:0:0:0: [sda] Asking for cache data failed > sd 0:0:0:0: [sda] Assuming drive cache: write through > sd 0:0:0:0: [sda] Attached SCSI disk > > The old drive works the same, as far as I can tell, but other than it > being moved down to sdb: > > sd 1:0:0:0: [sdb] 156301488 512-byte hardware sectors (80026 MB) > sd 1:0:0:0: [sdb] Write Protect is off > sd 1:0:0:0: [sdb] Mode Sense: 27 00 00 00 > sd 1:0:0:0: [sdb] Assuming drive cache: write through > sd 1:0:0:0: [sdb] 156301488 512-byte hardware sectors (80026 MB) > sd 1:0:0:0: [sdb] Write Protect is off > sd 1:0:0:0: [sdb] Mode Sense: 27 00 00 00 > sd 1:0:0:0: [sdb] Assuming drive cache: write through Right. This proves that my suggestion wasn't the right thing to do. > Solved: > Turn on CONFIG_SCSI_MULTI_LUN > > Presto, works. Proving my point that this was a SCSI problem, not a USB problem. > Thanks to Matthew Dharm (the guy that maintains the usb goodness) for > helping me work it out off-list. Could you summarize your off-list discussion for the benefit of the rest of us? Alan Stern ------------------------------------------------------------------------- This SF.net email is sponsored by: Microsoft Defy all challenges. Microsoft(R) Visual Studio 2005. http://clk.atdmt.com/MRT/go/vse0120000070mrt/direct/01/ _______________________________________________ Linux-usb-users@lists.sourceforge.net To unsubscribe, use the last form field at: https://lists.sourceforge.net/lists/listinfo/linux-usb-users
