A user with an AOpen AK73Pro motherboard reported that turning off the BIOS option "Assign IRQ for USB" solved this problem for him. Another mentioned that upgrading from BIOS revision 1.16 to 1.20 fixed it (but he wasn't sure if he had an AK73 or the Pro or some other variant).
Another user had this problem with a Sharp Zaurus until he plugged in the power supply into the docking station.
Yet another user with a Sum Vision flash disk found that inserting the device slowly solved this problem. He suspects it takes it time to become active after it gets power before it can properly respond.
Another suggestion that worked for at least one person was to use either pci-noacpi or acpi=off as a boot option.
Here is an email from another user;
i have a Elite K7s5a Pro mainboard where the USB connectors were not working at all with kernel 2.4.25. No matter what device i plugged in, i always saw only "device not accepting address" in dmesg. I tried all the hints from your FAQ but nothing helped. The driver (usb-uhci) for the USB connectors shared its interrupt with three other devices. So it was very hard to say if the USB received interrupts or not. Because of some other reason i removed the Adaptec 2940 from my system, which was sharing the interrupt with the USB driver. And now the USB connectors are working! :-)
My situation is that I have a Lippert Cool Roadrunner III CPU board, which uses a VIA VT82C686B south-bridge chip to handle its USB interfaces. After a USB device has been successfully disconnected and reconnected to the USB bus a variable number of times, I start seeing the error that this FAQ question talks about, and thereafter I can no longer connect any new USB devices. According to /proc/interrupts, no interrupts arrive from the host controller either, once this happens. None of the suggestions in FAQ entry had any effect. However I then discovered that if I unload and then reload the uhci-hcd driver, whenever this happens, the USB interfaces will reliably start working again. My guess is that the uhci-hcd driver resets the host-controller in the southbridge, whenever it is loaded. Note that it isn't necessary to unload any other USB drivers before doing this. Thus the usb-core driver and any high-level USB drivers can all be left loaded while this is being done.
In my case, the messages were: usb 3-2: new full speed USB device using uhci_hcd and address 22 usb 3-2: device descriptor read/64, error -71 usb 3-2: device descriptor read/64, error -71 usb 3-2: new full speed USB device using uhci_hcd and address 23 usb 3-2: device not accepting address 23, error -71 usb 3-2: new full speed USB device using uhci_hcd and address 24 usb 3-2: device not accepting address 24, error -71 etc., ad nauseam. This occurs on day when I am playing with installing loads of new software for Palm. After xth hotsync the Palm stops accepting the USB address. What helped was a warm reset of the Palm. No idea why, but it seems to me that the problem was on Palm's side.