USB device not accepting new address error 71

[pauldmis]

There seems to be a problem loading usb drivers and confirmed by others:

hub.c: new USB device 00:02.1-1, assigned address 2 usb.c: USB device not accepting new address=2 (error=-71) hub.c: new USB device 00:02.1-1, assigned address 3 usb.c: USB device not accepting new address=3 (error=-71)

Some notes in the forum how to work around it partially: http://www.dd-wrt.com/phpBB2/viewtopic.php?t=24947&postdays=0&postorder=asc&start=315 http://www.dd-wrt.com/phpBB2/viewtopic.php?t=24947&postdays=0&postorder=asc&start=330

[teddy_bear]

I believe that the USB drivers are loaded too early during the startup process.

I'm using a hub with printer and USB flash drive connected to it. If USB drive is plugged in, the router fails to recognize USB devices at all on 9 reboots out of 10. But if I disconnect the hub and reconnect it again after router if up and running, then the router immediately sees printer and the USB drive, and the drive can be mounted. This behaviour is testes on Asus WL-520GU, DD-WRT mini_usb builds 10700, 10737 and 10776. By the way, printer alone works fine.

To work around the problem, I disabled USB support in the web GUI, and manually load all USB drivers in one of my .startup scripts in /jffs/etc/config folder:

#.....................
# Load USB storage support modules 
sleep 1 
insmod usbcore 
insmod usb-ohci  # USB 1.1 OHCI 
insmod ehci-hcd  # USB 2.0 
insmod scsi_mod 
insmod usb-storage 
insmod printer 
insmod sd_mod 
# EXT3 support 
insmod jbd 
insmod ext3 
sleep 1 
# now mount the drive and start printer server
#.....................

With this setup everything works perfectly. Both - the printer and the flash drive - are recognized on every reboot without reconnecting them (I'm not sure if sleep commands are needed at all - just did not even try without them).

When USB support is enabled in GUI, USB drivers are loaded before network initialization. Disabling USB support in the GUI, and loading drivers in .startup script instead moved the drivers loading to the very end of the bootup process. Maybe all that needs to be done to fix the issue for everybody is to change the order of loading USB modules.

[newgel]

I found this IBM link where they describe this problem in more details. It is a kernel 2.4.X timming bug. Maybe you can fix it by just including a sleep somewhere into the usb module? Or maybe there is already a kernel patch? Please look into it. Seems we can finally fix this problem! Tks

​http://www-304.ibm.com/systems/support/supportsite.wss/docdisplay?lndocid=MIGR-62059&brandind=5000020

[snake98]

fixed by eko