On 10/1/07, Matthew Dharm <[EMAIL PROTECTED]> wrote: > For the sake of the list archives, could you provide the device/model > number (i.e. how is it marked on the box) for this thing? > > I've not seen very many RAID-enabled dual-HD enclosures for USB. > > Matt
Done, see below. On 10/1/07, Alan Stern <[EMAIL PROTECTED]> wrote: > Could you summarize your off-list discussion for the benefit of the > rest of us? > > Alan Stern Hopefully Matt will not object to having his emails pasted... This is a simplified log of the conversation between Matt Dharm and I about the Western Digital "My Book Dual-drive Storage System with RAID and Backup Software", order WDG2T10000N/model WD10000C033-001. I had been digging through the kernel code, looking into TYPE_ENCLOSURE more, and had found essentially no real code dealing with it. It *looks* like a stub framework for later implementation, so I ask... me: Is this USB device type (TYPE_ENCLOSURE) supported at all, or is it just a skeletal framework so far? him: TYPE_ENCLOSURE is a SCSI device type reserved for (usually large) HD enclosures. Things like 19" rack-mount multi-drive bays. While the transport to and from these devices is supported (as with all SCSI devices), there is no linux support for these devices that I am aware of. I've been following your thread on the mailing list. I'm pretty sure your device is just reporting the wrong type code. Nobody sane makes a USB enclosure that returns TYPE_ENCLOSURE. me: No offense, but I'm less concerned with it being sanely designed and/or correct, and far more concerned with it working. Correct me if I'm wrong, but wouldn't something so simple as it just returning the wrong type, just be a matter of the patch which was submitted, no matter how incorrectly, making TYPE_ENCLOSURE essentially an alias for TYPE_DISK? Please note that that did not work. Also noteworthy is that there are two 500GB drives in the "enclosure" with RAID striping handled internally. So technically, it is a large multi-drive enclosure. him: Now that's interesting information. me: Isn't it, though? I have a knack at finding odd glitches in things, with or without odd hardware. I don't suppose you've got any idea where I would drop in a small patch to simply make the USB subsystem essentially ignore the first "I" line, and go for the second one instead? because really, that's the main problem, as far as i can tell. It's going for the HID and ignoring the mass storage, and I need it to do vice versa. Protocol and standards be damned. him: First of all, nothing is getting ignored. Your data shows that usb-storage is binding to every interface which is available to it. USB supports binding multiple drivers to the same device via multiple "Interfaces" -- that's what the "I" stands for. My best guess at this point is that the enclosure is actually a multi-LUN device and you're kernel is only probing the first LUN. The second LUN is probably the RAID controller. Do you have CONFIG_SCSI_MULTI_LUN turned on? me: I did test that, and got no results, but now that I think about it, i was having other issues at the same time, so lemme give it another shot and see what happens. --- ...and thus the problem was solved. If anyone's wondering, I'm pretty sure the HID device is used to reconfigure the device from a 1TB stripe to a 500GB mirrored set "for data protection". Also noteworthy, the issues I stated I was having before arose from GREP_OPTIONS having --color=always in it. Modules won't install with that, it just says "MODPOST 0 Modules" and runs depmod like a friggin genius. "unset GREP_OPTIONS; export GREP_OPTIONS; make modules modules_install" ftw. So end result/summary: none of this would have happened at all, if I had rememebered to try the solution I'd tried before I noticed I had a completely unrelated problem that was preventing module installation in the first place. Thanks again to Matt -- pegasus ------------------------------------------------------------------------- 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
