# usbd module autoload

## vap0rtranz

After I updated hotplug in a series of #emerge -u world, usbd fails to start with this error:

```
patrick root # /etc/init.d/usbd start

 * Starting usb daemon...

usbd v0.1 (c) 1999 by Thomas Sailer

cannot open "/proc/bus/usb/devices ": No such file or directory (2)       [ !! ]
```

Of corse the init script is right, the file does not exist ... there.  I found a .../usb/devices/ directory under /sys.  I am running udev with the devfs tarball fallback option:

```
kernel (hd0,1)/bzImage-2.6.11-gentoo-r5-acpi-noscsi udev gentoo=nodevfs root=/dev/hda5 idebus=66 
```

```
patrick root # grep RC_DEV /etc/conf.d/rc

RC_DEVICE_TARBALL="yes"

RC_DEVFSD_STARTUP="yes"
```

Hotplug is running and the kernel automatically loads usbcore:

```
patrick root # dmesg | grep -i usb

usbcore: registered new driver usbfs

usbcore: registered new driver hub
```

... but I cannot use my USB mouse  :Confused: 

----------

## keyson

Hi.

Check your kernel config that you have

USB Device Filsystem enabled under

Device Drivers ---> USB Support --->

And also that you have proc filesystem support.

----------

## vap0rtranz

I have usb built as a module:

```
bash-2.05b$ grep -i usb .config | grep -v "#"              

CONFIG_USB=m

CONFIG_USB_DEVICEFS=y

CONFIG_USB_ARCH_HAS_HCD=y

CONFIG_USB_ARCH_HAS_OHCI=y

CONFIG_USB_EHCI_HCD=m

CONFIG_USB_UHCI_HCD=m

CONFIG_USB_PRINTER=m

CONFIG_USB_STORAGE=m

CONFIG_USB_HID=m

CONFIG_USB_HIDINPUT=y

CONFIG_USB_SERIAL=m

CONFIG_USB_SERIAL_GENERIC=y

CONFIG_USB_SERIAL_VISOR=m
```

Also, I do not have issues loading these modules:

```
patrick root # modprobe usbhid

patrick root # lsmod

Module                  Size  Used by

usbhid                 25344  0  <----------+

ndiswrapper           130292  0 

fglrx                 239932  7 

intel_agp              20060  1 

agpgart                28776  2 fglrx,intel_agp

ipv6                  239040  8 

af_packet              13384  2 

snd_pcm_oss            48864  0 

snd_mixer_oss          17792  1 snd_pcm_oss

snd_seq_oss            32512  0 

snd_seq_midi_event      6144  1 snd_seq_oss

snd_seq                50064  4 snd_seq_oss,snd_seq_midi_event

snd_seq_device          6924  2 snd_seq_oss,snd_seq

snd_intel8x0           28992  8 

snd_ac97_codec         75320  1 snd_intel8x0

snd_pcm                83592  7 snd_pcm_oss,snd_intel8x0,snd_ac97_codec

snd_timer              21508  2 snd_seq,snd_pcm

snd                    46180  24 snd_pcm_oss,snd_mixer_oss,snd_seq_oss,snd_seq,s                                                                                                                   nd_seq_device,snd_intel8x0,snd_ac97_codec,snd_pcm,snd_timer

snd_page_alloc          7684  2 snd_intel8x0,snd_pcm

ide_cd                 38084  0 

cdrom                  38624  1 ide_cd

rtc                    10488  0 

usbcore               106808  3 usbhid,ndiswrapper  <----------+

cpufreq_ondemand        5340  1 

speedstep_centrino      6548  1 

freq_table              3460  1 speedstep_centrino

processor              18612  1 speedstep_centrino
```

/proc is enabled in my kernel:

```
bash-2.05b$ grep -i proc .config | grep -v "#"

...

CONFIG_REISERFS_PROC_INFO=y

CONFIG_PROC_FS=y

CONFIG_PROC_KCORE=y
```

I had checked these common issues before posting by searching the forums.  It's almost like usbd needs to be pointed away from the /proc filesystem because those devices are now under /sys  :Question: 

----------

## keyson

Strange!

You should have the /proc/bus/usb/devices file.

Se if someone else can spread som light over this problem.

I run a pure udev (no tar) and use coldplug to get my

printer recognised at boot.

----------

## ctt

 *keyson wrote:*   

> Strange!
> 
> You should have the /proc/bus/usb/devices file.
> 
> Se if someone else can spread som light over this problem.
> ...

 It may be that you haven't mounted the usb filesystem.  Make sure this is in your fstab...

```
none                    /proc/bus/usb   usbfs           defaults                0 0
```

----------

## keyson

Thank's ctt.

I didn't think of the that. This may be it.

----------

## vap0rtranz

 *Quote:*   

> It may be that you haven't mounted the usb filesystem

 

I didn't notice this requirement in any docs.  Is this recommended?

Regardless, I fixed the problem, although I have a question about Gentoo standards.  When I manually loaded usbhid followed by uhci-hcd my mouse returned!  :Very Happy:    My kernel is very modular, and the .../usb/devices structure is built by the uhci-hcd module.  (I observed this by watching the filesystem while removing and inserting uhci-hcd)

 :Question:   Now, my Gentoo standards question is related to how usbd failed: is the /etc/modules.d/ structure deprecated for the /etc/modules.autoload.d/kernel-* file?  I ran kernel-2.4 and -2.6.5 using files under modules.d -- none in ./modules.autoload.d/kernel-2.4 nor -2.6 -- and usbd worked just fine.

```
bash-2.05b$ ls /etc/modules.d

acpi     alsa  i386  ndiswrapper  serial     svgalib    tg3

aliases  ati   irda  ppp          speedstep  synaptics  usb
```

Now, I find the fix to usbd failing is putting the module names in ./modules.autoload.d/kernel-2.6.  From my understanding, it should not matter which file one edits because after one executes module-update, both are merged into /etc/modules.conf ...

What is the Gentoo way?

----------

## ctt

 *vap0rtranz wrote:*   

>  *Quote:*   It may be that you haven't mounted the usb filesystem 
> 
> I didn't notice this requirement in any docs.  Is this recommended?
> 
> Regardless, I fixed the problem, although I have a question about Gentoo standards.  When I manually loaded usbhid followed by uhci-hcd my mouse returned!    My kernel is very modular, and the .../usb/devices structure is built by the uhci-hcd module.  (I observed this by watching the filesystem while removing and inserting uhci-hcd)
> ...

 

Hrm.../etc/modules.d houses a list of files which (when combined) form your modules.conf(5).  /etc/modules.autoload.d has files which contain lists of modules to be autoloaded on startup.  So, /etc/modules.autoload.d/kernel-2.6 contains a list of modules to be autoloaded during startup when a 2.6.* kernel is detected.

The reason why they decided to organize things (specifically, modules.d/) this way probably relates to the ease at which package installation becomes.  If a package, say, ndiswrapper needs to set some default options for the installed kernel module, all it has to do is drop a file into the /etc/modules.d directory, name it something obvious, and ensure that modules-update is run before the module is used.  When the time comes to uninstall, this single file is removed. This is ideal as the alternative would have the ebuild manually edit /etc/modules.conf or, better yet, tell the user to do it.  During uninstall, these changes would otherwise have to be removed.

Hope this helps,

----------

## vap0rtranz

Thanks ctt.  Your explanation makes sense, but I would like to use the most efficient module loading standard.  What I mean is: why load modules that might not be used?

I would like the init.d scripts to load modules per the user's rc-update configuration.  For example: if I need to debug a conflict with usbd, I would stop the current daemon and remove the init.d/usbd script from several runlevels until I find a fix.  I believe the relevant modules should not be loaded when fixing issues just like the daemons should not be running.  

The modules.autoload.d/kernel-* structure clearly cannot suppor the situation I describe, but it sounds like modules.d/ could ...

----------

