Date: Fri, 21 Jun 2013 22:48:07 +1000 (EST) From: Ian Smith <smithi@nimnet.asn.au> To: Adrian Chadd <adrian@freebsd.org> Cc: freebsd-acpi@freebsd.org, freebsd-stable@freebsd.org, freebsd-usb@freebsd.org Subject: Re: USB ports on Lenovo T400 do not work after a suspend/resume Message-ID: <20130621220013.X55167@sola.nimnet.asn.au> In-Reply-To: <CAJ-Vmomg2j-nJi%2BqFr3CpCjHKjHEiLE=xyNyx1VGRL5U-r8gzQ@mail.gmail.com> References: <CAJ-Vmomg2j-nJi%2BqFr3CpCjHKjHEiLE=xyNyx1VGRL5U-r8gzQ@mail.gmail.com>
next in thread | previous in thread | raw e-mail | index | archive | help
On Thu, 20 Jun 2013 14:19:21 -0700, Adrian Chadd wrote: > Hi, > > FreeBSD-9 works fine on this Lenovo T400 - except that suspending with > no USB devices plugged in result in no ports working after resume. > > If I have a device plugged in during suspend - on any port - then all > the ports work fine after resume. > > I've attached usbconfig and acpidump output. No acpidump output on -stable or -acpi anyway .. likely best as an URL, if it comes down to ACPI. So the fingerprint reader, camera and bluetooth shown in your usbconfig don't serve as 'USB devices plugged in' in this regard? Do they work ok after resume, or not? > here's what is logged in the kernel buffer during suspend and resume: > > > Her'es the suspend: With all but the USB-related stuff dropped, I assume? > Jun 20 14:03:34 lucy acpi: suspend at 20130620 14:03:34 > Jun 20 14:03:38 lucy kernel: [100031] uhub0: at usbus0, port 1, addr 1 > (disconnected) > Jun 20 14:03:38 lucy kernel: [100036] uhub1: at usbus1, port 1, addr 1 > (disconnected) > Jun 20 14:03:38 lucy kernel: ugen1.2: <vendor 0x08ff> at usbus1 (disconnected) > Jun 20 14:03:38 lucy kernel: ugen1.3: <Lenovo Computer Corp> at usbus1 > (disconnected) > Jun 20 14:03:38 lucy kernel: [100036] ubt0: at uhub1, port 2, addr 3 > (disconnected) > Jun 20 14:03:47 lucy kernel: [100041] uhub2: at usbus2, port 1, addr 1 > (disconnected) > Jun 20 14:03:47 lucy kernel: [100046] uhub3: at usbus3, port 1, addr 1 > (disconnected) > Jun 20 14:03:47 lucy kernel: ugen3.2: <Kingston> at usbus3 (disconnected) > Jun 20 14:03:47 lucy kernel: [100046] umass0: at uhub3, port 1, addr 2 > (disconnected) > Jun 20 14:03:47 lucy kernel: (da0:umass-sim0:0:0:0): lost device - 0 > outstanding, 1 refs > Jun 20 14:03:47 lucy kernel: (da0:umass-sim0:0:0:0): removing device entry > Jun 20 14:03:47 lucy kernel: ugen3.3: <Chicony Electronics Co., Ltd.> > at usbus3 (disconnected) > Jun 20 14:03:47 lucy kernel: uhci_interrupt: resume detect The last message is news to me. > Jun 20 14:03:47 lucy kernel: [100052] uhub4: at usbus4, port 1, addr 1 > (disconnected) > Jun 20 14:03:47 lucy kernel: [100057] uhub5: at usbus5, port 1, addr 1 > (disconnected) > Jun 20 14:03:47 lucy kernel: [100062] uhub6: at usbus6, port 1, addr 1 > (disconnected) > Jun 20 14:03:47 lucy kernel: [100067] uhub7: at usbus7, port 1, addr 1 > (disconnected) > > ..and resume: I wonder what these devices are? > > Jun 20 14:03:47 lucy kernel: [100095] pci21: failed to set ACPI power > state D2 on \_SB_.PCI0.PCI1.CDBS: AE_BAD_PARAMETER > Jun 20 14:03:47 lucy kernel: [100095] pci0: failed to set ACPI power > state D2 on \_SB_.PCI0.EXP0: AE_BAD_PARAMETER > Jun 20 14:03:47 lucy kernel: [100095] pci0: failed to set ACPI power > state D2 on \_SB_.PCI0.EXP1: AE_BAD_PARAMETER > Jun 20 14:03:47 lucy kernel: [100095] pci0: failed to set ACPI power > state D2 on \_SB_.PCI0.EXP3: AE_BAD_PARAMETER > Jun 20 14:03:47 lucy kernel: [100095] pci0: failed to set ACPI power > state D2 on \_SB_.PCI0.EXP4: AE_BAD_PARAMETER No, the above are still on the suspend path, but logged on resume. I don't know what CDBS or EXP0,1,3,4 are. You've left out something like 'pci0:X:Y:0 Transition from D0 to D2' (or D3) before these ones, right? On 9(.1-R so far) I always get the same sort of messages for the cardbus slots on my T23, eg pci2: failed to set ACPI power state D2 on \_SB_.PCI0.PCI1.CBS0: AE_BAD_PARAMETER, also for CBS1. I've supposed it meant there was no D2 setting for these and they seem to resume alright, later on: pci2: set ACPI power state D0 on \_SB_.PCI0.PCI1.CBS0 (& CBS1) I suppose you'd have lines setting state back to D0 on these, later on? > Jun 20 14:03:47 lucy kernel: [100095] acpi0: cleared fixed power button status > Jun 20 14:03:47 lucy kernel: uhci_interrupt: resume detect > Jun 20 14:03:47 lucy kernel: wakeup from sleeping state (slept 00:00:06) I hope 'slept' message is still in 10, I've seen a few listed without, and they're very handy if there's any resume delay, as I had up to 8.2 (plus exactly 60 seconds) unless I unloaded (in particular) UHCI and reloaded it on resume, needing a kernel w/out uhci, ohci and ehci, loading on boot and unload/reload in rc.suspend/resume. This however was fixed by 9.1 for me, the first release where suspend/resume works flawlessly on the T23. I haven't tried a recent 9-STABLE though. > Jun 20 14:03:47 lucy kernel: [100067] uhub0: <Intel EHCI root HUB, > class 9/0, rev 2.00/1.00, addr 1> on usbus7 > Jun 20 14:03:47 lucy kernel: [100046] uhub1: <Intel EHCI root HUB, > class 9/0, rev 2.00/1.00, addr 1> on usbus3 > Jun 20 14:03:47 lucy kernel: [100031] uhub2: <Intel UHCI root HUB, > class 9/0, rev 1.00/1.00, addr 1> on usbus0 > Jun 20 14:03:47 lucy kernel: [100036] uhub3: <Intel UHCI root HUB, > class 9/0, rev 1.00/1.00, addr 1> on usbus1 > Jun 20 14:03:47 lucy kernel: [100057] uhub4: <Intel UHCI root HUB, > class 9/0, rev 1.00/1.00, addr 1> on usbus5 > Jun 20 14:03:47 lucy kernel: [100052] uhub5: <Intel UHCI root HUB, > class 9/0, rev 1.00/1.00, addr 1> on usbus4 > Jun 20 14:03:47 lucy kernel: [100062] uhub6: <Intel UHCI root HUB, > class 9/0, rev 1.00/1.00, addr 1> on usbus6 > Jun 20 14:03:47 lucy kernel: [100041] uhub7: <Intel UHCI root HUB, > class 9/0, rev 1.00/1.00, addr 1> on usbus2 > > .. local APIC error? No idea. > Jun 20 14:03:47 lucy kernel: CPU0: local APIC error 0x40 > Jun 20 14:03:47 lucy acpi: resumed at 20130620 14:03:47 > > It probes the hubs fine though. But you get nothing at all if you plug something in? No messages? Well, the earlier resume issues on UHCI might still not be fixed? You could try a kernel without UHCI, with the unload/reload dance .. cheers, Ian
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?20130621220013.X55167>