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! :-)

And another;

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.

One more;

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.