LinuxQuestions.org - usb-serial adapter not recognized after hibernation in gentoo

- Linux - Hardware (https://www.linuxquestions.org/questions/linux-hardware-18/)

- - usb-serial adapter not recognized after hibernation in gentoo (https://www.linuxquestions.org/questions/linux-hardware-18/usb-serial-adapter-not-recognized-after-hibernation-in-gentoo-690541/)

usb-serial adapter not recognized after hibernation in gentoo

Hope this is in the right place.. I wasn't sure whether to put this in hardware or software. My gps receiver uses a pl2303 usb-to-serial adapter. On a fresh gentoo install, the pl2303 is recognized correctly and assigned to /dev/ttyUSB0.

I'm using a tuxonice patched kernel (2.6.26-tuxonice) to suspend my system to disk. It seems to suspend okay, but upon resuming I get the following errors in kern.log and dmesg:

Code:

usb 3-1: new full speed USB device using uhci_hcd and address 2

usb 3-1: device descriptor read/64, error -71

usb 3-1: device descriptor read/64, error -71

usb 3-1: new full speed USB device using uhci_hcd and address 3

usb 3-1: device descriptor read/64, error -71

usb 3-1: device descriptor read/64, error -71

usb 3-1: new full speed USB device using uhci_hcd and address 4

usb 3-1: device not accepting address 4, error -71

usb 3-1: new full speed USB device using uhci_hcd and address 5

usb 3-1: device not accepting address 5, error -71

hub 3-0:1.0: unable to enumerate USB device on port 1

lsusb shows my other USB devices as connected, but does not show the pl2303.

The most frustrating thing, is that even after doing a complete reboot (without hibernation) the error still occurs. The only way I have been able to work around it is to completely reinstall gentoo. Of course as soon as I hibernate, the error returns.

Any ideas?

P.S. here is my lspci:

Quote:

00:00.0 Host bridge: Intel Corporation Mobile Memory Controller Hub (rev 03)
00:02.0 VGA compatible controller: Intel Corporation Mobile Integrated Graphics
Controller (rev 03)
00:02.1 Display controller: Intel Corporation Mobile Integrated Graphics Control
ler (rev 03)
00:19.0 Ethernet controller: Intel Corporation 82566DC Gigabit Network Connectio
n (rev 03)
00:1b.0 Audio device: Intel Corporation 82801H (ICH8 Family) HD Audio Controller
(rev 03)
00:1c.0 PCI bridge: Intel Corporation 82801H (ICH8 Family) PCI Express Port 1 (r
ev 03)
00:1c.1 PCI bridge: Intel Corporation 82801H (ICH8 Family) PCI Express Port 2 (r
ev 03)
00:1d.0 USB Controller: Intel Corporation 82801H (ICH8 Family) USB UHCI Controll
er #1 (rev 03)
00:1d.1 USB Controller: Intel Corporation 82801H (ICH8 Family) USB UHCI Controll
er #2 (rev 03)
00:1d.2 USB Controller: Intel Corporation 82801H (ICH8 Family) USB UHCI Controll
er #3 (rev 03)
00:1d.3 USB Controller: Intel Corporation Device 2833 (rev 03)
00:1d.7 USB Controller: Intel Corporation 82801H (ICH8 Family) USB2 EHCI Control
ler #1 (rev 03)
00:1e.0 PCI bridge: Intel Corporation 82801 Mobile PCI Bridge (rev f3)
00:1f.0 ISA bridge: Intel Corporation Mobile LPC Interface Controller (rev 03)
00:1f.1 IDE interface: Intel Corporation Mobile IDE Controller (rev 03)
00:1f.2 IDE interface: Intel Corporation Mobile SATA IDE Controller (rev 03)
00:1f.3 SMBus: Intel Corporation 82801H (ICH8 Family) SMBus Controller (rev 03)
02:00.0 Ethernet controller: Intel Corporation 82573L Gigabit Ethernet Controlle
r
03:00.0 Network controller: RaLink Device 0781

hmm... I'm afraid my pl2303 is hosed. I've disconnected it and plugged it into a windows PC (completely separate computer) and it gives me a "hardware malfunction" error. I managed to dig up more information, and it does not look promising.

https://kerneltrap.org/mailarchive/l.../410714/thread

Quote:

A hibernate (or a suspend that causes the USB subsystem to lose power)
has issues. If you have the tty open when you hibernate, a new tty will
be created when the device re-enumerates during resume. Closing the old
tty will cause the serial driver's shutdown function to be called on a
device that doesn't exist anymore. Fortunately, that doesn't seem to
have any adverse effects on the functionality of the new tty.

I've tried adding a tty hangup to the suspend function, but that doesn't
seem to have any effect on minicom. I'm not sure whether minicom
ignores hangups, or if it never gets the hangup. The tty layer
schedules the hangup; it isn't synchronous.

This seems to be the only issue with adding autosuspend code to the
pl2303. A hibernate with the tty open didn't work before, so I'm
inclined to send an updated patch later today.

Also, I found out the hard way that some types of pl2303 chips don't
handle suspend correctly. The HX chip can handle suspend gracefully,
but the type_1 can't. When it resumes, the host controller detects it
as a low speed device; since it's actually a high speed device, this
fails. The initialization for the two chips are different (see the
FISH/SOUP mess in pl2303.c), but I haven't experimented to see if
different initialization would help.

I'm taking a wild guess that I have a type_1 chip. Although this issue was discussed a year ago, I'm not sure if the problem was fixed (I'm guessing not). There may be something I could have done with the hibernation script to prevent this from happening, but I don't think I'll ever find out. In the mean time, I took some spare parts and soldered together a cable to connect the gps receiver directly to a serial port on the computer, and it is working fine.

If the pl2303 was mistakenly being recognized as a low speed device, could that have scrambled the eeprom, resulting in the hardware malfunction errors?