December 14, 200916 yr I have been getting lines in my syslog like the following: Dec 14 00:06:06 Tower kernel: usb 2-2: reset high speed USB device using ehci_hcd and address 3 I tried to get rid of them by disabling USB 2.0 in the BIOS of my mother board but that did not seem to help in the slightest, and I think I even read that is the USB 2.0 driver is loaded by the computer OS then the BIOS setting will be overridden. So, I have been searching for other ways to force USB 1.0 speeds and perhaps get rid of this annoying little message. I found this topic which talks about removing EHCI and then USB 1.0 will be forced and everything should go fine. I am just wondering if there is a better wa to do this and what the linux command might be. Any help is appreciated!!
December 14, 200916 yr The USB error handlers do not report all of the error information that the hard drive exception handlers do, which would be very helpful here. At least it logs the resets, but not the reasons why it thinks a reset is necessary. The first thing we eliminate with the hard drive errors is communication issues, and that is what to me is the starting point here too, especially since dropping the speed to a slower protocol is often successful. That really looks like a communications problem. If there is an extension cable used to the flash, I would replace it with a better one, or a shorter one, or eliminate it if possible. Then I would try connecting to different USB ports, especially ones connected to different USB controllers. If connected up front, then switch to a port in back, or vice versa. Last of all would be to revert to USB 1.1, by removing the EHCI module. Communications issues could be from either the connecting cables and wires, either of the connectors, the flash drive itself, or a faulty USB port or controller. I don't know, but there may be a boot parameter that would force USB 1.1 speed on just this drive, and therefore keep USB 2.0 modules for any other attached USB devices.
December 14, 200916 yr Author The USB error handlers do not report all of the error information that the hard drive exception handlers do, which would be very helpful here. At least it logs the resets, but not the reasons why it thinks a reset is necessary. The first thing we eliminate with the hard drive errors is communication issues, and that is what to me is the starting point here too, especially since dropping the speed to a slower protocol is often successful. That really looks like a communications problem. If there is an extension cable used to the flash, I would replace it with a better one, or a shorter one, or eliminate it if possible. Then I would try connecting to different USB ports, especially ones connected to different USB controllers. If connected up front, then switch to a port in back, or vice versa. Last of all would be to revert to USB 1.1, by removing the EHCI module. Communications issues could be from either the connecting cables and wires, either of the connectors, the flash drive itself, or a faulty USB port or controller. I don't know, but there may be a boot parameter that would force USB 1.1 speed on just this drive, and therefore keep USB 2.0 modules for any other attached USB devices. I forgot to mention that I have tried all of the USB ports on the motherboard (Abit AB9 Pro) with no luck in getting this to go away. I have used the ones on the back of the mahcine, the ones in the front, and even all the USB headers on the motherboard. I don't know if it is the flash drive or not but it seems to happen on any of the USB port on the computer.
December 14, 200916 yr You might try something like this: http://www.linuxquestions.org/questions/slackware-14/usb-external-hd-issue-reset-high-speed-usb-device-using-ehcihcd-545519/#post2714080 (using, of course, the correct device for your USB drive.) Another post I found googling suggested a sector size of 128. The max "writable" size seems to be dependent on the flash drive itself, so try 64 first. Same issue reported here: http://forums.fedoraforum.org/showthread.php?t=155595 Joe L.
December 16, 200916 yr Author You might try something like this: http://www.linuxquestions.org/questions/slackware-14/usb-external-hd-issue-reset-high-speed-usb-device-using-ehcihcd-545519/#post2714080 (using, of course, the correct device for your USB drive.) Another post I found googling suggested a sector size of 128. The max "writable" size seems to be dependent on the flash drive itself, so try 64 first. Same issue reported here: http://forums.fedoraforum.org/showthread.php?t=155595 Joe L. I had found those links also when I was doing my searching. Just a quick question... Will setting those "hurt" the flash drive in any way? and what is the expected output if any?
December 16, 200916 yr You might try something like this: http://www.linuxquestions.org/questions/slackware-14/usb-external-hd-issue-reset-high-speed-usb-device-using-ehcihcd-545519/#post2714080 (using, of course, the correct device for your USB drive.) Another post I found googling suggested a sector size of 128. The max "writable" size seems to be dependent on the flash drive itself, so try 64 first. Same issue reported here: http://forums.fedoraforum.org/showthread.php?t=155595 Joe L. I had found those links also when I was doing my searching. Just a quick question... Will setting those "hurt" the flash drive in any way? and what is the expected output if any? There is no output. You will just get back the prompt. They will not hurt the drive, they will just write to it in smaller "chunks" Joe L.
December 20, 200916 yr Author OK, well I have been messing with different settings for the last little while now. It turns out that the resetting of the USB is not causing the other disks to spin up, it is one of my Seagate drives (a 1.5TB) that is timing out and then causing the others to reset. BUT the resets of the USB were happening, so I have used the echo 64 >/sys/block/sdX/device/max_sectors to set the max_sectors of the USB device and it seems to help quite a bit. The USB dvice is being reset far far less often.
Archived
This topic is now archived and is closed to further replies.