Re: USB ports on Lenovo T400 do not work after a suspend/resume
On Sun, 7 Jul 2013 03:26:24 -0700, Jeremy Chadwick wrote: On Sun, Jul 07, 2013 at 03:51:12PM +1000, Ian Smith wrote: On Sun, 30 Jun 2013 15:02:57 -0700, Adrian Chadd wrote: On 30 June 2013 07:22, Ian Smith smi...@nimnet.asn.au wrote: [..] Nothing of note that I can see, if that usb hub-to-bus remapping is normal. As you said, 'CPU0: local APIC error 0x40' looks maybe sus. Maybe someone who knows might comment on that? Does noone know what that signifies? Maybe it's not relevant to this. It's too vague to know. The error comes from lapic_handle_error(), which is a generic/small routine which pulls the local APIC error status register. (Note I'm saying APIC, not ACPI -- two different things) Indeed; I've been familiar with PICs since c.'79. Googling to check what the 'A' stood for I found this .. from '97 but usefully descriptive perhaps: http://people.freebsd.org/~fsmp/SMP/papers/apicsubsystem.txt I also found this from March 2011 involving Mike Tancsa, you and jhb@ :) http://freebsd.1045724.n5.nabble.com/CPU0-local-APIC-error-0x40-CPU1-local-APIC-error-0x40-td3961805.html apic_vector.S sets this up/makes use of this function, and its done as an interrupt handler. Whether an (unserviced?) interrupt error is related to Adrian's symptom - apparent total failure of USB reinitialisation on resume, but only if no USB devices exist in the external slots - remains to be seen. hps@ has just confirmed that it should work the same as on boot, but then this error was flagged on boot - perhaps it also manifests on resume? I think this is one of those situations where you have to know *what* is being set up/done at that moment in time for the error code to mean something. Maybe booting verbose would give more information as to what was being done that lead up to the line. I've CC'd John Baldwin who might have some ideas. Thanks. We have verbose dmesg already. Thread starts (in -stable) at http://lists.freebsd.org/pipermail/freebsd-stable/2013-June/073917.html and amidst some wild goose chases, pointer to verbose dmesg etc is at http://lists.freebsd.org/pipermail/freebsd-stable/2013-June/074018.html cheers, Ian ___ freebsd-usb@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-usb To unsubscribe, send any mail to freebsd-usb-unsubscr...@freebsd.org
Re: USB ports on Lenovo T400 do not work after a suspend/resume
On Sun, 30 Jun 2013 15:02:57 -0700, Adrian Chadd wrote: On 30 June 2013 07:22, Ian Smith smi...@nimnet.asn.au wrote: [..] Nothing of note that I can see, if that usb hub-to-bus remapping is normal. As you said, 'CPU0: local APIC error 0x40' looks maybe sus. Maybe someone who knows might comment on that? Does noone know what that signifies? Maybe it's not relevant to this. Just checking: you've tried other USB devices apart from uftdi0? Yup, there's no 5v on the port. I was rather taken aback to hear this. Would not this indicate a failure to reinitialise the basic underlying USB hardware on resume? More than a bit bemused, Ian ___ freebsd-usb@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-usb To unsubscribe, send any mail to freebsd-usb-unsubscr...@freebsd.org
Re: USB ports on Lenovo T400 do not work after a suspend/resume
On Sat, 29 Jun 2013, Adrian Chadd wrote: On 27 June 2013 04:58, Ian Smith smi...@nimnet.asn.au wrote: We don't yet know if this is a bus, ACPI /or USB issue. Home yet? :) Yup: http://people.freebsd.org/~adrian/usb/ dmesg.boot = dmesg at startup 1 - after powerup, usb device in 2 - after acpiconf -s3 suspend/resume, w/ a USB device plugged in 3 - after acpiconf -s3 suspend/resume, with a USB device removed before suspend/resume After removing [numbers] (for WITNESS?), diff started making sense. The below is between the first and second suspend/resume cycles in dmesg-3.txt, encompassing the others. Nothing of note that I can see, if that usb hub-to-bus remapping is normal. As you said, 'CPU0: local APIC error 0x40' looks maybe sus. Maybe someone who knows might comment on that? Just checking: you've tried other USB devices apart from uftdi0? Out of ideas, and my depth, Ian === --- dm3.a 2013-06-30 21:49:48.0 +1000 +++ dm3.b 2013-06-30 21:50:30.0 +1000 @@ -1,23 +1,21 @@ -ugen3.2: FTDI at usbus3 -[] uftdi0: FT232R USB UART on usbus3 +ugen3.2: FTDI at usbus3 (disconnected) +[] uftdi0: at uhub4, port 2, addr 2 (disconnected) (ada0:ahcich0:0:0:0): spin-down [] acpi_lid0: wake_prep enabled for \134_SB_.LID_ (S3) [] acpi_button0: wake_prep enabled for \134_SB_.SLPB (S3) -[] uhub0: at usbus0, port 1, addr 1 (disconnected) -[] uhub1: at usbus1, port 1, addr 1 (disconnected) +[] uhub2: at usbus0, port 1, addr 1 (disconnected) +[] uhub0: at usbus1, port 1, addr 1 (disconnected) ugen1.2: vendor 0x08ff at usbus1 (disconnected) ugen1.3: Lenovo Computer Corp at usbus1 (disconnected) -[] ubt0: at uhub1, port 2, addr 3 (disconnected) -[] uhub2: at usbus2, port 1, addr 1 (disconnected) +[] ubt0: at uhub0, port 2, addr 3 (disconnected) +[] uhub1: at usbus2, port 1, addr 1 (disconnected) ugen2.2: Chicony Electronics Co., Ltd. at usbus2 (disconnected) pci0:0:28:0: Transition from D0 to D3 pci0:0:28:1: Transition from D0 to D3 pci0:0:28:3: Transition from D0 to D3 pci0:0:28:4: Transition from D0 to D3 -[] uhub3: at usbus3, port 1, addr 1 (disconnected) -ugen3.2: FTDI at usbus3 (disconnected) -[] uftdi0: at uhub3, port 2, addr 2 (disconnected) -[] uhub4: at usbus4, port 1, addr 1 (disconnected) +[] uhub4: at usbus3, port 1, addr 1 (disconnected) +[] uhub3: at usbus4, port 1, addr 1 (disconnected) [] uhub5: at usbus5, port 1, addr 1 (disconnected) pci0:21:0:0: Transition from D0 to D2 [] pci21: failed to set ACPI power state D2 on \134_SB_.PCI0.PCI1.CDBS: AE_BAD_PARAMETER @@ -73,12 +71,12 @@ kbdc: RESET_AUX ID: [] battery0: battery initialization start [] ahcich0: AHCI reset: device ready after 100ms -[] uhub0: Intel UHCI root HUB, class 9/0, rev 1.00/1.00, addr 1 on usbus1 -[] uhub1: Intel UHCI root HUB, class 9/0, rev 1.00/1.00, addr 1 on usbus2 -[] uhub2: Intel UHCI root HUB, class 9/0, rev 1.00/1.00, addr 1 on usbus0 -[] uhub3: Intel UHCI root HUB, class 9/0, rev 1.00/1.00, addr 1 on usbus4 -[] uhub4: Intel UHCI root HUB, class 9/0, rev 1.00/1.00, addr 1 on usbus3 -[] uhub5: Intel UHCI root HUB, class 9/0, rev 1.00/1.00, addr 1 on usbus5 +[] uhub0: Intel UHCI root HUB, class 9/0, rev 1.00/1.00, addr 1 on usbus0 +[] uhub1: Intel UHCI root HUB, class 9/0, rev 1.00/1.00, addr 1 on usbus1 +[] uhub2: Intel UHCI root HUB, class 9/0, rev 1.00/1.00, addr 1 on usbus3 +[] uhub3: Intel UHCI root HUB, class 9/0, rev 1.00/1.00, addr 1 on usbus2 +[] uhub4: Intel UHCI root HUB, class 9/0, rev 1.00/1.00, addr 1 on usbus5 +[] uhub5: Intel UHCI root HUB, class 9/0, rev 1.00/1.00, addr 1 on usbus4 CPU0: local APIC error 0x40 [] battery0: battery initialization done, tried 1 times (ada0:ahcich0:0:0:0): resume @@ -92,15 +90,13 @@ intpin=a, irq=16 powerspec 2 supports D0 D3 current D0 [] cardbus0: network at device 0.0 (no driver attached) -[] uhub0: 2 ports with 2 removable, self powered [] uhub1: 2 ports with 2 removable, self powered [] uhub2: 2 ports with 2 removable, self powered +[] uhub0: 2 ports with 2 removable, self powered [] uhub3: 2 ports with 2 removable, self powered -[] uhub5: 2 ports with 2 removable, self powered [] uhub4: 2 ports with 2 removable, self powered +[] uhub5: 2 ports with 2 removable, self powered ugen1.2: vendor 0x08ff at usbus1 -ugen3.2: FTDI at usbus3 -[] uftdi0: FT232R USB UART on usbus3 ugen2.2: Chicony Electronics Co., Ltd. at usbus2 ugen1.3: Lenovo Computer Corp at usbus1 [] ubt0: Lenovo Computer Corp ThinkPad Bluetooth with Enhanced Data Rate II, class 224/1, rev 2.00/3.99, addr 3 on usbus1 === ___ freebsd-usb@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-usb To unsubscribe, send any mail to freebsd-usb-unsubscr...@freebsd.org
Re: USB ports on Lenovo T400 do not work after a suspend/resume
On Wed, 26 Jun 2013 12:53:43 -0700, Adrian Chadd wrote: On 26 June 2013 12:51, Lars Engels lars.eng...@0x20.net wrote: On Tue, Jun 25, 2013 at 11:09:20PM -0700, Adrian Chadd wrote: [snip] ok, I'll do a boot -v tonight when I get home and log things. Thanks! Please also try a recent CURRENT. I was having the same issues with dead USB ports on my X200, but IIRC it suddenly worked a few weeks ago. Unfotunately with the new X.org resuming doesn't work for me, so I can't try it now. .. having resume not work with xorg is a big, big red flag. I'm happy to boot a -head snapshot on this thing, but I can't really migrate to running -head if resume doesn't work. :( Well if there's a functional change in head that fixes this on Lars' and yours, getting it into stable shouldn't be so hard I expect. However if there's a fix (or some Lenovo workaround) for yours on 9 it'd be useful to hunt it down, no? I utterly depend on 100% working resume too. We don't yet know if this is a bus, ACPI /or USB issue. Home yet? :) cheers, Ian ___ freebsd-usb@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-usb To unsubscribe, send any mail to freebsd-usb-unsubscr...@freebsd.org
Re: USB ports on Lenovo T400 do not work after a suspend/resume
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
Re: suspend/resume and the freebsd usb stack
On Fri, 30 Jul 2010, Hans Petter Selasky wrote:
On Friday 30 July 2010 16:53:22 b. f. wrote:
Are these criticisms of suspend/resume for the usb stack justified?:
http://lists.freebsd.org/pipermail/svn-src-head/2010-July/018974.html
If so, are there any plans to fix the problem(s)?
Regards,
b.
Hi,
Suspend and resume has not been too much tested! Some part is done in the
BIOS, the other part is done in the OS. You can try doing a detach instead
of
a suspend, and an attach instead of a resume.
Do you mean doing what you often used to have to do with the old usb
stack, at least on some laptops, that is kldunload usb before suspend
and kldload usb after resume, in /etc/rc.{suspend,resume} respectively?
If so, how would that go if (eg) you had a USB stick or external drive
mounted? And with usb in kernel, I guess you can't unload it anyway?
I know doing that used to cause panics, but admit not having tried it
more recently, except one suspend/resume (default rc.{suspend,resume})
from the Fixit shell booted from the 8.1-RELEASE-i386-memstick.img the
other night, where I got I/O read errors on commands, that ceased after
removing/reinserting the mounted stick (which WAS quite encouraging :)
If not, what/how do you mean by detach and attach here?
Patches are welcome!
First don't we need to describe just what the problems really are?
cheers, Ian
___
freebsd-usb@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-usb
To unsubscribe, send any mail to freebsd-usb-unsubscr...@freebsd.org
