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. For example, I'm pretty sure there are SCSI keyboards, which would absolutely be a character device by nature, not just by driver. > That's the HID interface in the composite WD MyBook device. Yes, I know, that's the thing I don't actually give a crap about. > So both devices were registered with the SCSI core, as they would have > to be in order for both sg0 and sg1 to appear. Right, like I said, sda is working just fine. > 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. 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. 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)? 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 This is probably the second most frustrating problem I've ever had with linux. Hopefully it has a solution as simple as the last one. Should I bump this to the devel list, or give you guys more time to ponder it? ------------------------------------------------------------------------- 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
