[Date Prev][Date Next] [Thread Prev][Thread Next] [Date Index] [Thread Index]

Re: USB hubs and storage no go on 2.6.17-2



On Wed, Dec 13, 2006 at 12:17:32AM -0500, Jim Crilly wrote:
> On 12/12/06 10:45:45AM -0800, Andrew Sharp wrote:
> > Howdy listers,
> > 
> > I'm running etch with a custom compiled 2.6.19 and it sure seems to work
> > brilliantly better that the Debian 2.6.17 kernel package when it comes
> > to USB storage and USB hubs.  In other words, those didn't work at all
> > on the 2.6.17-? kernel package.
> > 
> > It seems that those don't work unless you choose 'desktop environment'
> > in tasksel, which I don't do because I like to keep 1GB of disk space
> > free of Gbloatware.
> > 
> 
> That makes no sense. Are you saying that your USB hub and storage stuff
> wasn't working with the Debian 2.6.17 kernels unless you had the full
> desktop environment installed? If so, I can't say I share that experience,
> a few weeks ago I reloaded a box with etch without any X or desktop
> packages (but now running sid) and USB storage works just fine with it.

You're right, it doesn't make any sense, but there it is.  The exact
same kernel package, except on i386 and with all the Gnobe dependencies
installed, worked for the same USB disk.  But plugging the disk into my
amd64 system did not work.  It didn't even load the usbstorage module.
If I then loaded usbstorage by hand, the usb<->scsi-disk connection
wasn't made at all (I'm running SATA disks, so sd_mod and friends were
already loaded).  Furthermore, the hub on my Dell 2407WFP was completely
non-functional -- it didn't even show up in usbview.

I built a 2.6.18.3 kernel from stable-git, and bingo all was working.
My guess as to why it works is that scsi and scsi disk support aren't
modules in my custom kernel.  I figured with sd_mod and scsi_mod being,
well, modules, in the Debian kernel, something like hald or some other
obnoxious daemon I don't want was "helping" the scsi subsystem rescan
or whatever.

Cheers,

a



Reply to: