Re: Resume broken in 8.3-PRERELEASE
On Tue, Aug 28, 2012 at 11:56:56AM +0300, Konstantin Belousov wrote: > On Tue, Aug 28, 2012 at 09:07:51AM +0700, Alexey Dokuchaev wrote: > > Before zzz'ing: > > > > db> show intrcnt > > irq1: atkbd0168 > > irq9: acpi0 8300 > > irc12: psm0 2 > > irq14: ata0 6301 > > irq16: bge0 uhci3 13 > > irq23: uhci0 ehci0 2 > > cpu0: timer 7306385 > > irq256: hdac0 30 > > > > After (within a minute after botched resume) > > > > db> show intrcnt > > irq1: atkbd0479 > > irq9: cdpi0 8379 > > Was the output pasted verbatim ? I am curious about the irq9 name mangling > in the second paste. Sorry, just rerun the test, no mangling, it was a typo on my behalf due to copying by hand. ./danfe ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to "freebsd-stable-unsubscr...@freebsd.org"
Re: Resume broken in 8.3-PRERELEASE
On Tue, Aug 28, 2012 at 09:07:51AM +0700, Alexey Dokuchaev wrote: > On Mon, Aug 27, 2012 at 05:34:54PM +0200, Hans Petter Selasky wrote: > > If the USB HC is feeding too many such IRQ's it will be stuck. However, > > if you see that "uhub_read_port_status()" is called, the kernel is at least > > running, though it might be that some IRQ is stuck, hence the 100% CPU > > usage. Could you try to get some IRQ stats? > > Before zzz'ing: > > db> show intrcnt > irq1: atkbd0 168 > irq9: acpi0 8300 > irc12: psm0 2 > irq14: ata0 6301 > irq16: bge0 uhci3 13 > irq23: uhci0 ehci02 > cpu0: timer 7306385 > irq256: hdac0 30 > > After (within a minute after botched resume) > > db> show intrcnt > irq1: atkbd0 479 > irq9: cdpi0 8379 Was the output pasted verbatim ? I am curious about the irq9 name mangling in the second paste. > irc12: psm0 2 > irq14: ata0 6377 > irq16: bge0 uhci3 26 > irq23: uhci0 ehci05 > cpu0: timer 7731880 > irq256: hdac0 34 > > Not too much difference. Anything else I might get from DDB? Unfortunately, > I am yet unable to save crashdump for later gdb analysis. > > ./danfe > ___ > freebsd-stable@freebsd.org mailing list > http://lists.freebsd.org/mailman/listinfo/freebsd-stable > To unsubscribe, send any mail to "freebsd-stable-unsubscr...@freebsd.org" pgpC7oJin9wVZ.pgp Description: PGP signature
Re: Resume broken in 8.3-PRERELEASE
On Mon, Aug 27, 2012 at 05:34:54PM +0200, Hans Petter Selasky wrote: > If the USB HC is feeding too many such IRQ's it will be stuck. However, > if you see that "uhub_read_port_status()" is called, the kernel is at least > running, though it might be that some IRQ is stuck, hence the 100% CPU > usage. Could you try to get some IRQ stats? Before zzz'ing: db> show intrcnt irq1: atkbd0168 irq9: acpi0 8300 irc12: psm0 2 irq14: ata0 6301 irq16: bge0 uhci3 13 irq23: uhci0 ehci0 2 cpu0: timer 7306385 irq256: hdac0 30 After (within a minute after botched resume) db> show intrcnt irq1: atkbd0479 irq9: cdpi0 8379 irc12: psm0 2 irq14: ata0 6377 irq16: bge0 uhci3 26 irq23: uhci0 ehci0 5 cpu0: timer 7731880 irq256: hdac0 34 Not too much difference. Anything else I might get from DDB? Unfortunately, I am yet unable to save crashdump for later gdb analysis. ./danfe ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to "freebsd-stable-unsubscr...@freebsd.org"
Re: Resume broken in 8.3-PRERELEASE
On Monday 27 August 2012 14:59:43 Alexey Dokuchaev wrote: > On Mon, Mar 05, 2012 at 07:10:22AM +0100, Hans Petter Selasky wrote: > > On Monday 05 March 2012 05:17:59 Alexey Dokuchaev wrote: > > > On Sat, Mar 03, 2012 at 09:11:29AM +0100, Hans Petter Selasky wrote: > > > > On Friday 02 March 2012 20:25:32 Jung-uk Kim wrote: > > > > > Try the attached patch. At least, it fixed my problem. > > > > > > > > I've committed your patch with some minor modifications. > > > > > > > > http://svn.freebsd.org/changeset/base/232448 > > > > > > Unfortunately, it does not fix resume for me; and > > > hw.usb.no_shutdown_wait flipping did not make any difference either. > > > Any other ideas? Particularly, I'm curious why disabling all USB > > > modules still does not allow this laptop to resume. What are USB > > > debugging techniques? > > > > USB debugging: > > > > Have "options USB_DEBUG" in kernel config. Then set xxx.debug = 15 under > > hw.usb, typically hw.usb.uhub.debug=15 > > Today I've csupped to latest RELENG_8 (hoping that maybe the problem was > fixed during last few months), rebuilt the kernel with USB_DEBUG option. > > After fresh reboot, the following snippet releately pop up on the console > (hand-copied): > > usb_needs_explore: > usb_bus_powerd: bus=0xc55cccf0 <-- bus= number changes > usb_bus_powerd: Recomputing power masks > uhub_explore: udev=0xc5647400 addr=1<-- udev= number changes > uhub_read_port_status: port 1, wPortStatus=0x0100, wPortChange=0x, > err=USB_ERR_NORMAL_COMPLETION uhub_read_port_status: port 2, > wPortStatus=0x0100, wPortChange=0x, err=USB_ERR_NORMAL_COMPLETION > > (USB<->CRC32 has plugged in, no other USB devices) > > Aroung zzz(8) time (keyboard die upon wake-up as described earlier with > 100% CPU load -- fans are at full burst) debug mode yielded these: > > uhub_child_pnpinfo_string: device not on bub > uhub_child_location_string: device not on bub > uhub_child_pnpinfo_string: device not on bub > usb_bus_powerd: bus=0xc55e2c78 > usb_bus_powerd: Recomputing power masks > uhub_read_port_status: port 1, wPortStatus=0x0500, wPortChange=0x, > err=USB uhub_read_port_status: port 2, wPortStatus=0x0500, > wPortChange=0x, err=USB ... up to port 8 ... > uhub_read_port_status: port 8, wPortStatus=0x0500, wPortChange=0x, > err=USB << usual "(disconnected)" messages >> > usb_buf_port_set_device: bus 0xc55cccf0 devices[2] = 0 > usb_needs_explore: > usb_needs_explore: > usb_needs_explore: > usb_needs_explore: > usb_needs_explore: > uhub0: on usbus4 > uhub0: on usbus1 > ... UHCI also found on usbus 2, 3, 0 (in that order) > uhub_attach: depth=0 selfpowered=1, parent=0, parent->selfpowered=0 > uhub_attach: Getting HUB descriptior > uhub_attach: turn on port 1 power > uhub_attach: turn on port 1 power > uhub_attach: turn on port 1 power > uhub_attach: turn on port 1 power > uhub_attach: turn on port 1 power > uhub_attach: turn on port 2 power > uhub_attach: turn on port 2 power > uhub_attach: turn on port 2 power > uhub_attach: turn on port 2 power > uhub1: 2 ports with 2 removable, self powered > ... usb_needs_explore: loop quoted above repeats; system unusable > > Any ideas? > > ./danfe If the USB HC is feeding too many such IRQ's it will be stuck. However, if you see that "uhub_read_port_status()" is called, the kernel is at least running, though it might be that some IRQ is stuck, hence the 100% CPU usage. Could you try to get some IRQ stats? --HPS ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to "freebsd-stable-unsubscr...@freebsd.org"
Re: Resume broken in 8.3-PRERELEASE
On Mon, Mar 05, 2012 at 07:10:22AM +0100, Hans Petter Selasky wrote: > On Monday 05 March 2012 05:17:59 Alexey Dokuchaev wrote: > > On Sat, Mar 03, 2012 at 09:11:29AM +0100, Hans Petter Selasky wrote: > > > On Friday 02 March 2012 20:25:32 Jung-uk Kim wrote: > > > > Try the attached patch. At least, it fixed my problem. > > > > > > I've committed your patch with some minor modifications. > > > > > > http://svn.freebsd.org/changeset/base/232448 > > > > Unfortunately, it does not fix resume for me; and hw.usb.no_shutdown_wait > > flipping did not make any difference either. Any other ideas? > > Particularly, I'm curious why disabling all USB modules still does not > > allow this laptop to resume. What are USB debugging techniques? > > USB debugging: > > Have "options USB_DEBUG" in kernel config. Then set xxx.debug = 15 under > hw.usb, typically hw.usb.uhub.debug=15 Today I've csupped to latest RELENG_8 (hoping that maybe the problem was fixed during last few months), rebuilt the kernel with USB_DEBUG option. After fresh reboot, the following snippet releately pop up on the console (hand-copied): usb_needs_explore: usb_bus_powerd: bus=0xc55cccf0<-- bus= number changes usb_bus_powerd: Recomputing power masks uhub_explore: udev=0xc5647400 addr=1 <-- udev= number changes uhub_read_port_status: port 1, wPortStatus=0x0100, wPortChange=0x, err=USB_ERR_NORMAL_COMPLETION uhub_read_port_status: port 2, wPortStatus=0x0100, wPortChange=0x, err=USB_ERR_NORMAL_COMPLETION (USB<->CRC32 has plugged in, no other USB devices) Aroung zzz(8) time (keyboard die upon wake-up as described earlier with 100% CPU load -- fans are at full burst) debug mode yielded these: uhub_child_pnpinfo_string: device not on bub uhub_child_location_string: device not on bub uhub_child_pnpinfo_string: device not on bub usb_bus_powerd: bus=0xc55e2c78 usb_bus_powerd: Recomputing power masks uhub_read_port_status: port 1, wPortStatus=0x0500, wPortChange=0x, err=USB uhub_read_port_status: port 2, wPortStatus=0x0500, wPortChange=0x, err=USB ... up to port 8 ... uhub_read_port_status: port 8, wPortStatus=0x0500, wPortChange=0x, err=USB << usual "(disconnected)" messages >> usb_buf_port_set_device: bus 0xc55cccf0 devices[2] = 0 usb_needs_explore: usb_needs_explore: usb_needs_explore: usb_needs_explore: usb_needs_explore: uhub0: on usbus4 uhub0: on usbus1 ... UHCI also found on usbus 2, 3, 0 (in that order) uhub_attach: depth=0 selfpowered=1, parent=0, parent->selfpowered=0 uhub_attach: Getting HUB descriptior uhub_attach: turn on port 1 power uhub_attach: turn on port 1 power uhub_attach: turn on port 1 power uhub_attach: turn on port 1 power uhub_attach: turn on port 1 power uhub_attach: turn on port 2 power uhub_attach: turn on port 2 power uhub_attach: turn on port 2 power uhub_attach: turn on port 2 power uhub1: 2 ports with 2 removable, self powered ... usb_needs_explore: loop quoted above repeats; system unusable Any ideas? ./danfe ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to "freebsd-stable-unsubscr...@freebsd.org"
Re: Resume broken in 8.3-PRERELEASE
On Monday 05 March 2012 05:17:59 Alexey Dokuchaev wrote: > On Sat, Mar 03, 2012 at 09:11:29AM +0100, Hans Petter Selasky wrote: > > On Friday 02 March 2012 20:25:32 Jung-uk Kim wrote: > > > Try the attached patch. At least, it fixed my problem. > > > > I've committed your patch with some minor modifications. > > > > http://svn.freebsd.org/changeset/base/232448 > > Unfortunately, it does not fix resume for me; and hw.usb.no_shutdown_wait > flipping did not make any difference either. Any other ideas? > Particularly, I'm curious why disabling all USB modules still does not > allow this laptop to resume. What are USB debugging techniques? USB debugging: Have "options USB_DEBUG" in kernel config. Then set xxx.debug = 15 under hw.usb, typically hw.usb.uhub.debug=15 --HPS ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to "freebsd-stable-unsubscr...@freebsd.org"
Re: Resume broken in 8.3-PRERELEASE
On Sat, Mar 03, 2012 at 09:11:29AM +0100, Hans Petter Selasky wrote: > On Friday 02 March 2012 20:25:32 Jung-uk Kim wrote: > > Try the attached patch. At least, it fixed my problem. > > I've committed your patch with some minor modifications. > > http://svn.freebsd.org/changeset/base/232448 Unfortunately, it does not fix resume for me; and hw.usb.no_shutdown_wait flipping did not make any difference either. Any other ideas? Particularly, I'm curious why disabling all USB modules still does not allow this laptop to resume. What are USB debugging techniques? ./danfe ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to "freebsd-stable-unsubscr...@freebsd.org"
Re: Resume broken in 8.3-PRERELEASE
On Friday 02 March 2012 20:25:32 Jung-uk Kim wrote: > On Friday 02 March 2012 03:50 am, Alexey Dokuchaev wrote: > > On Thu, Mar 01, 2012 at 04:55:03PM -0500, Jung-uk Kim wrote: > > > It does not make a difference for me (i.e., usb suspend/resume > > > still broken) but I think I found a typo: > > > > > > --- sys/dev/usb/controller/usb_controller.c (revision 232365) > > > +++ sys/dev/usb/controller/usb_controller.c (working copy) > > > @@ -407,7 +407,7 @@ usb_bus_suspend(struct usb_proc_msg *pm) > > > > > > USB_BUS_UNLOCK(bus); > > > > > > - bus_generic_shutdown(bus->bdev); > > > + bus_generic_suspend(bus->bdev); > > > > > > usbd_enum_lock(udev); > > > > Same thing here, does not seem to improve anything. It might > > suspend, resume (with keyboard working), then die on next suspend > > completely. Or it may die on the first suspend (without suspending > > -- fans are spinning, screen is black and no response to anything > > except hard power-off), this actually happens more often. > > Try the attached patch. At least, it fixed my problem. Hi, I've committed your patch with some minor modifications. http://svn.freebsd.org/changeset/base/232448 Will you take care of the MFC to 8.3-RC + 8-stable? --HPS ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to "freebsd-stable-unsubscr...@freebsd.org"
Re: Resume broken in 8.3-PRERELEASE
On Friday 02 March 2012 03:50 am, Alexey Dokuchaev wrote:
> On Thu, Mar 01, 2012 at 04:55:03PM -0500, Jung-uk Kim wrote:
> > It does not make a difference for me (i.e., usb suspend/resume
> > still broken) but I think I found a typo:
> >
> > --- sys/dev/usb/controller/usb_controller.c (revision 232365)
> > +++ sys/dev/usb/controller/usb_controller.c (working copy)
> > @@ -407,7 +407,7 @@ usb_bus_suspend(struct usb_proc_msg *pm)
> >
> > USB_BUS_UNLOCK(bus);
> >
> > - bus_generic_shutdown(bus->bdev);
> > + bus_generic_suspend(bus->bdev);
> >
> > usbd_enum_lock(udev);
>
> Same thing here, does not seem to improve anything. It might
> suspend, resume (with keyboard working), then die on next suspend
> completely. Or it may die on the first suspend (without suspending
> -- fans are spinning, screen is black and no response to anything
> except hard power-off), this actually happens more often.
Try the attached patch. At least, it fixed my problem.
> ./danfe
>
> P.S. Also, doing "ps" in debugger shows that acpiconf(8) is
> running in the userland upon resume (and hang). Not sure if it
> helps or not though.
It usually means a device driver couldn't resume (and hang).
Jung-uk Kim
Index: sys/dev/usb/controller/usb_controller.c
===
--- sys/dev/usb/controller/usb_controller.c (revision 232401)
+++ sys/dev/usb/controller/usb_controller.c (working copy)
@@ -89,10 +89,15 @@ TUNABLE_INT("hw.usb.no_boot_wait", &usb_no_boot_wa
SYSCTL_INT(_hw_usb, OID_AUTO, no_boot_wait, CTLFLAG_RDTUN, &usb_no_boot_wait,
0,
"No USB device enumerate waiting at boot.");
+static int usb_no_suspend_wait = 0;
+TUNABLE_INT("hw.usb.no_suspend_wait", &usb_no_suspend_wait);
+SYSCTL_INT(_hw_usb, OID_AUTO, no_suspend_wait, CTLFLAG_RW|CTLFLAG_TUN,
+&usb_no_suspend_wait, 0, "No USB device waiting at system suspend.");
+
static int usb_no_shutdown_wait = 0;
TUNABLE_INT("hw.usb.no_shutdown_wait", &usb_no_shutdown_wait);
-SYSCTL_INT(_hw_usb, OID_AUTO, no_shutdown_wait, CTLFLAG_RW|CTLFLAG_TUN,
&usb_no_shutdown_wait, 0,
-"No USB device waiting at system shutdown.");
+SYSCTL_INT(_hw_usb, OID_AUTO, no_shutdown_wait, CTLFLAG_RW|CTLFLAG_TUN,
+&usb_no_shutdown_wait, 0, "No USB device waiting at system shutdown.");
static devclass_t usb_devclass;
@@ -240,6 +245,11 @@ usb_suspend(device_t dev)
USB_BUS_LOCK(bus);
usb_proc_msignal(&bus->explore_proc,
&bus->suspend_msg[0], &bus->suspend_msg[1]);
+ if (usb_no_suspend_wait == 0) {
+ /* wait for suspend callback to be executed */
+ usb_proc_mwait(&bus->explore_proc,
+ &bus->suspend_msg[0], &bus->suspend_msg[1]);
+ }
USB_BUS_UNLOCK(bus);
return (0);
@@ -407,7 +417,7 @@ usb_bus_suspend(struct usb_proc_msg *pm)
USB_BUS_UNLOCK(bus);
- bus_generic_shutdown(bus->bdev);
+ bus_generic_suspend(bus->bdev);
usbd_enum_lock(udev);
___
freebsd-stable@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-stable
To unsubscribe, send any mail to "freebsd-stable-unsubscr...@freebsd.org"
Re: Resume broken in 8.3-PRERELEASE
On Fri, Mar 02, 2012 at 04:14:08PM +0100, Hans Petter Selasky wrote: > On Friday 02 March 2012 09:57:03 Alexey Dokuchaev wrote: > > On Fri, Mar 02, 2012 at 08:48:13AM +0100, Hans Petter Selasky wrote: > > > If the reset doesn't work, then try to enable hw.usb.uhub.debug=15 and > > > see what port change events are coming. > > > > I don't see such oid hw.usb.uhub.debug. Perhaps it should be hw.usb.debug? What about this? I've did hw.usb.debug=15, but didn't see anything new on the console. > > > If cfg=255 in usbconfig, then something is wrong. > > > > It seems they are all zeros, per the output I've sent earlier. > > If they are all zeros, then everything is working like it should. If you can > dump the device and configuration descriptors, then there is no USB problem. I can only dump this information *before* suspend, after "resume" I cannot do almost anything except breaking into debugger (but not being able to "call doadump"). I had to revert to earlier revision to call usbconfig(8) after resume. > I'm thinking it might be some MICROCODE issue that causes the problem. Maybe > we shouldn't reset the OHCI and EHCI and UHCI and XHCI before handing over to > the MICROCODE suspend handler? > > Have a look in /sys/dev/usb/controller/xhci/ehci/ohci/uhci and search for > suspend. OK, I will try and report back, thanks. ./danfe ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to "freebsd-stable-unsubscr...@freebsd.org"
Re: Resume broken in 8.3-PRERELEASE
On Friday 02 March 2012 09:57:03 Alexey Dokuchaev wrote: > On Fri, Mar 02, 2012 at 08:48:13AM +0100, Hans Petter Selasky wrote: > > If the reset doesn't work, then try to enable hw.usb.uhub.debug=15 and > > see what port change events are coming. > > I don't see such oid hw.usb.uhub.debug. Perhaps it should be hw.usb.debug? > > > If cfg=255 in usbconfig, then something is wrong. > > It seems they are all zeros, per the output I've sent earlier. If they are all zeros, then everything is working like it should. If you can dump the device and configuration descriptors, then there is no USB problem. I'm thinking it might be some MICROCODE issue that causes the problem. Maybe we shouldn't reset the OHCI and EHCI and UHCI and XHCI before handing over to the MICROCODE suspend handler? Have a look in /sys/dev/usb/controller/xhci/ehci/ohci/uhci and search for suspend. --HPS ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to "freebsd-stable-unsubscr...@freebsd.org"
Re: Resume broken in 8.3-PRERELEASE
On Fri, Mar 02, 2012 at 08:48:13AM +0100, Hans Petter Selasky wrote: > If the reset doesn't work, then try to enable hw.usb.uhub.debug=15 and see > what port change events are coming. I don't see such oid hw.usb.uhub.debug. Perhaps it should be hw.usb.debug? > If cfg=255 in usbconfig, then something is wrong. It seems they are all zeros, per the output I've sent earlier. ./danfe ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to "freebsd-stable-unsubscr...@freebsd.org"
Re: Resume broken in 8.3-PRERELEASE
On Thu, Mar 01, 2012 at 04:55:03PM -0500, Jung-uk Kim wrote: > On Thursday 01 March 2012 01:53 pm, Hans Petter Selasky wrote: > > What is output from usbconfig as root, before and after > > suspend/resume ? Before suspend (just after reboot, this output is identical to pre/post SVN r229370): ugen0.1: at usbus0, cfg=0 md=HOST spd=FULL (12Mbps) pwr=SAVE ugen1.1: at usbus1, cfg=0 md=HOST spd=FULL (12Mbps) pwr=SAVE ugen2.1: at usbus2, cfg=0 md=HOST spd=FULL (12Mbps) pwr=SAVE ugen3.1: at usbus3, cfg=0 md=HOST spd=FULL (12Mbps) pwr=SAVE ugen4.1: at usbus4, cfg=0 md=HOST spd=HIGH (480Mbps) pwr=SAVE ugen0.2: at usbus0, cfg=0 md=HOST spd=FULL (12Mbps) pwr=ON ugen3.2: at usbus3, cfg=0 md=HOST spd=FULL (12Mbps) pwr=ON After resume (kernel from Jan 1): all lines are the same, except that last two lines are swapped (ugen3.2 is listed before ugen0.2). Presence of US232B does not affect behavior; ugen3.2 is built-in finger print scanner, and since in USB2 there is no separate ugen(4), I don't know how to selectively disable it. Man page for ugen(4) however exists. :-) > It does not make a difference for me (i.e., usb suspend/resume still > broken) but I think I found a typo: > > --- sys/dev/usb/controller/usb_controller.c (revision 232365) > +++ sys/dev/usb/controller/usb_controller.c (working copy) > @@ -407,7 +407,7 @@ usb_bus_suspend(struct usb_proc_msg *pm) > > USB_BUS_UNLOCK(bus); > > - bus_generic_shutdown(bus->bdev); > + bus_generic_suspend(bus->bdev); > > usbd_enum_lock(udev); Same thing here, does not seem to improve anything. It might suspend, resume (with keyboard working), then die on next suspend completely. Or it may die on the first suspend (without suspending -- fans are spinning, screen is black and no response to anything except hard power-off), this actually happens more often. ./danfe P.S. Also, doing "ps" in debugger shows that acpiconf(8) is running in the userland upon resume (and hang). Not sure if it helps or not though. ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to "freebsd-stable-unsubscr...@freebsd.org"
Re: Resume broken in 8.3-PRERELEASE
On Thursday 01 March 2012 22:55:03 Jung-uk Kim wrote: > On Thursday 01 March 2012 01:53 pm, Hans Petter Selasky wrote: > > On Thursday 01 March 2012 18:11:25 Alexey Dokuchaev wrote: > > > On Mon, Feb 27, 2012 at 10:22:38PM +0700, Alexey Dokuchaev wrote: > > > > On Mon, Feb 27, 2012 at 09:28:15PM +0700, Alexey Dokuchaev > > wrote: > > > > > I was mistaken, the latest kernel with working resume is from > > > > > Jan 4 00:00 UTC, kernel from Jan 4 01:00 UTC does not allow > > > > > my laptop to come back from zzz(8) successfully. It seems > > > > > that offending change is rev. 1.9.2.5 of > > > > > sys/nfsclient/nfs_krpc.c by rmacklem@ (SVN rev 229450). > > > > > > I've redone my bisecting, now suspending/resuming around at least > > > ten times in console with zzz(8). I must apologize to rmacklem@, > > > his commit has nothing to do with it. Apparently, the culprit is > > > SVN rev 229370 on 2012-01-03 09:15:54Z by hselasky@, which > > > (ironically enough) supposed to bring better support for USB > > > controller suspend and resume. Kernel csuped and built before > > > this date resumes just fine for me. However, the problem might > > > lay deeper: disabling all USB modules (I traditionally run slim > > > kernels with everything down to io/mem offloaded into modules) > > > does not fix the hang, see below. Selectively disabling UHCI or > > > EHCI does not make any difference either. > > > > > > Debugging of this issue is, however, complicated by the fact that > > > doing "call doadump" results in "Dumping 68M:" message (similar > > > problem was reported[1] by glebius@ back in 2004), and then > > > nothing happens except for IDE led light-up and frozen debugger, > > > which makes post-mortem analysis with kgdb(1) impossible. > > > Setting up serial console (since it's a laptop, the only > > > possibility for me right now is to use some noname USB adapter > > > via uftdi(4)) works, but kernel GDB does not like it. Perhaps > > > I'm just not passing 0x80 flag correctly, but > > > hint.uftdi.0.flags="0x80" does not work. Is GDB backend > > > impossible with USB serial adapters, or I am just doing it wrong? > > > > > > What strikes me most is that even with plain kbdmux(4) or > > > atkdb(4) I still cannot resume, even on previous (before r229370) > > > kernels (the earliest I've tried is from Jan 1 00:00 UTC). Any > > > debugging hints or patches to try are highly appreciated. > > > > > > Thus far, the latest kernel where resume works (with USB stuff > > > enabled) is from Jan 3 19:15 UTC. Hans Petter, do you have any > > > ideas about it? > > > > Hi, > > > > The USB controllers should be reset after resume. > > > > Suspend is currently ASYNC. This might be one problem. > > > > Resume is also ASYNC, because we cannot block in the > > device_resume() callback. > > > > Make sure no serial port adapters have open devices and are > > blocking suspend and resume. > > > > What is output from usbconfig as root, before and after > > suspend/resume ? > > It does not make a difference for me (i.e., usb suspend/resume still > broken) but I think I found a typo: > > Index: sys/dev/usb/controller/usb_controller.c > === > --- sys/dev/usb/controller/usb_controller.c (revision 232365) > +++ sys/dev/usb/controller/usb_controller.c (working copy) > @@ -407,7 +407,7 @@ usb_bus_suspend(struct usb_proc_msg *pm) > > USB_BUS_UNLOCK(bus); > > - bus_generic_shutdown(bus->bdev); > + bus_generic_suspend(bus->bdev); > > usbd_enum_lock(udev); > > Jung-uk Kim Hi, It should be shutdown, because suspend in this case is something else. USB suspend resume works like this: At suspend we reset and stop all controllers. At resume we reset and start all controllers again. If the reset doesn't work, then try to enable hw.usb.uhub.debug=15 and see what port change events are coming. If cfg=255 in usbconfig, then something is wrong. Currently suspend and resume is ASYNC, so that means we are not waiting for the actual HC reset to complete. --HPS ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to "freebsd-stable-unsubscr...@freebsd.org"
Re: Resume broken in 8.3-PRERELEASE
On Thursday 01 March 2012 01:53 pm, Hans Petter Selasky wrote: > On Thursday 01 March 2012 18:11:25 Alexey Dokuchaev wrote: > > On Mon, Feb 27, 2012 at 10:22:38PM +0700, Alexey Dokuchaev wrote: > > > On Mon, Feb 27, 2012 at 09:28:15PM +0700, Alexey Dokuchaev wrote: > > > > I was mistaken, the latest kernel with working resume is from > > > > Jan 4 00:00 UTC, kernel from Jan 4 01:00 UTC does not allow > > > > my laptop to come back from zzz(8) successfully. It seems > > > > that offending change is rev. 1.9.2.5 of > > > > sys/nfsclient/nfs_krpc.c by rmacklem@ (SVN rev 229450). > > > > I've redone my bisecting, now suspending/resuming around at least > > ten times in console with zzz(8). I must apologize to rmacklem@, > > his commit has nothing to do with it. Apparently, the culprit is > > SVN rev 229370 on 2012-01-03 09:15:54Z by hselasky@, which > > (ironically enough) supposed to bring better support for USB > > controller suspend and resume. Kernel csuped and built before > > this date resumes just fine for me. However, the problem might > > lay deeper: disabling all USB modules (I traditionally run slim > > kernels with everything down to io/mem offloaded into modules) > > does not fix the hang, see below. Selectively disabling UHCI or > > EHCI does not make any difference either. > > > > Debugging of this issue is, however, complicated by the fact that > > doing "call doadump" results in "Dumping 68M:" message (similar > > problem was reported[1] by glebius@ back in 2004), and then > > nothing happens except for IDE led light-up and frozen debugger, > > which makes post-mortem analysis with kgdb(1) impossible. > > Setting up serial console (since it's a laptop, the only > > possibility for me right now is to use some noname USB adapter > > via uftdi(4)) works, but kernel GDB does not like it. Perhaps > > I'm just not passing 0x80 flag correctly, but > > hint.uftdi.0.flags="0x80" does not work. Is GDB backend > > impossible with USB serial adapters, or I am just doing it wrong? > > > > What strikes me most is that even with plain kbdmux(4) or > > atkdb(4) I still cannot resume, even on previous (before r229370) > > kernels (the earliest I've tried is from Jan 1 00:00 UTC). Any > > debugging hints or patches to try are highly appreciated. > > > > Thus far, the latest kernel where resume works (with USB stuff > > enabled) is from Jan 3 19:15 UTC. Hans Petter, do you have any > > ideas about it? > > Hi, > > The USB controllers should be reset after resume. > > Suspend is currently ASYNC. This might be one problem. > > Resume is also ASYNC, because we cannot block in the > device_resume() callback. > > Make sure no serial port adapters have open devices and are > blocking suspend and resume. > > What is output from usbconfig as root, before and after > suspend/resume ? It does not make a difference for me (i.e., usb suspend/resume still broken) but I think I found a typo: Index: sys/dev/usb/controller/usb_controller.c === --- sys/dev/usb/controller/usb_controller.c (revision 232365) +++ sys/dev/usb/controller/usb_controller.c (working copy) @@ -407,7 +407,7 @@ usb_bus_suspend(struct usb_proc_msg *pm) USB_BUS_UNLOCK(bus); - bus_generic_shutdown(bus->bdev); + bus_generic_suspend(bus->bdev); usbd_enum_lock(udev); Jung-uk Kim ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to "freebsd-stable-unsubscr...@freebsd.org"
Re: Resume broken in 8.3-PRERELEASE
On Thursday 01 March 2012 18:11:25 Alexey Dokuchaev wrote: > On Mon, Feb 27, 2012 at 10:22:38PM +0700, Alexey Dokuchaev wrote: > > On Mon, Feb 27, 2012 at 09:28:15PM +0700, Alexey Dokuchaev wrote: > > > I was mistaken, the latest kernel with working resume is from Jan 4 > > > 00:00 UTC, kernel from Jan 4 01:00 UTC does not allow my laptop to > > > come back from zzz(8) successfully. It seems that offending change is > > > rev. 1.9.2.5 of sys/nfsclient/nfs_krpc.c by rmacklem@ (SVN rev > > > 229450). > > I've redone my bisecting, now suspending/resuming around at least ten > times in console with zzz(8). I must apologize to rmacklem@, his commit > has nothing to do with it. Apparently, the culprit is SVN rev 229370 on > 2012-01-03 09:15:54Z by hselasky@, which (ironically enough) supposed to > bring better support for USB controller suspend and resume. Kernel csuped > and built before this date resumes just fine for me. However, the problem > might lay deeper: disabling all USB modules (I traditionally run slim > kernels with everything down to io/mem offloaded into modules) does not fix > the hang, see below. Selectively disabling UHCI or EHCI does not make any > difference either. > > Debugging of this issue is, however, complicated by the fact that doing > "call doadump" results in "Dumping 68M:" message (similar problem was > reported[1] by glebius@ back in 2004), and then nothing happens except for > IDE led light-up and frozen debugger, which makes post-mortem analysis > with kgdb(1) impossible. Setting up serial console (since it's a laptop, > the only possibility for me right now is to use some noname USB adapter > via uftdi(4)) works, but kernel GDB does not like it. Perhaps I'm just > not passing 0x80 flag correctly, but hint.uftdi.0.flags="0x80" does not > work. Is GDB backend impossible with USB serial adapters, or I am just > doing it wrong? > > What strikes me most is that even with plain kbdmux(4) or atkdb(4) I still > cannot resume, even on previous (before r229370) kernels (the earliest > I've tried is from Jan 1 00:00 UTC). Any debugging hints or patches to > try are highly appreciated. > > Thus far, the latest kernel where resume works (with USB stuff enabled) is > from Jan 3 19:15 UTC. Hans Petter, do you have any ideas about it? > Hi, The USB controllers should be reset after resume. Suspend is currently ASYNC. This might be one problem. Resume is also ASYNC, because we cannot block in the device_resume() callback. Make sure no serial port adapters have open devices and are blocking suspend and resume. What is output from usbconfig as root, before and after suspend/resume ? --HPS ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to "freebsd-stable-unsubscr...@freebsd.org"
Re: Resume broken in 8.3-PRERELEASE
On Mon, Feb 27, 2012 at 10:22:38PM +0700, Alexey Dokuchaev wrote: > On Mon, Feb 27, 2012 at 09:28:15PM +0700, Alexey Dokuchaev wrote: > > I was mistaken, the latest kernel with working resume is from Jan 4 00:00 > > UTC, kernel from Jan 4 01:00 UTC does not allow my laptop to come back > > from zzz(8) successfully. It seems that offending change is rev. 1.9.2.5 > > of sys/nfsclient/nfs_krpc.c by rmacklem@ (SVN rev 229450). I've redone my bisecting, now suspending/resuming around at least ten times in console with zzz(8). I must apologize to rmacklem@, his commit has nothing to do with it. Apparently, the culprit is SVN rev 229370 on 2012-01-03 09:15:54Z by hselasky@, which (ironically enough) supposed to bring better support for USB controller suspend and resume. Kernel csuped and built before this date resumes just fine for me. However, the problem might lay deeper: disabling all USB modules (I traditionally run slim kernels with everything down to io/mem offloaded into modules) does not fix the hang, see below. Selectively disabling UHCI or EHCI does not make any difference either. Debugging of this issue is, however, complicated by the fact that doing "call doadump" results in "Dumping 68M:" message (similar problem was reported[1] by glebius@ back in 2004), and then nothing happens except for IDE led light-up and frozen debugger, which makes post-mortem analysis with kgdb(1) impossible. Setting up serial console (since it's a laptop, the only possibility for me right now is to use some noname USB adapter via uftdi(4)) works, but kernel GDB does not like it. Perhaps I'm just not passing 0x80 flag correctly, but hint.uftdi.0.flags="0x80" does not work. Is GDB backend impossible with USB serial adapters, or I am just doing it wrong? What strikes me most is that even with plain kbdmux(4) or atkdb(4) I still cannot resume, even on previous (before r229370) kernels (the earliest I've tried is from Jan 1 00:00 UTC). Any debugging hints or patches to try are highly appreciated. Thus far, the latest kernel where resume works (with USB stuff enabled) is from Jan 3 19:15 UTC. Hans Petter, do you have any ideas about it? ./danfe [1] http://lists.freebsd.org/pipermail/freebsd-current/2004-May/027732.html ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to "freebsd-stable-unsubscr...@freebsd.org"
Re: Resume broken in 8.3-PRERELEASE
On Mon, Feb 27, 2012 at 12:46:07PM -0500, Jung-uk Kim wrote: > Can you please try head and/or stable/9? FYI, Linux people found that > some BIOSes can corrupt low 64KB between suspend/resume, which may > cause strangeness like this. I worked around it in head (r231781) > and stable/9 (r232088). Frankly speaking, last time I tried next stable to my running branch (not to mention head) I've gained more problems than solutions. :-) For example, when this laptop of mine was running stable/7 suspend/resume was working for months. I only (reluctantly) switched to stable/8 as I've noticed it's getting more attention that 7.x series, and annoying people with "please MFC it to 7.x!" calls does not look particularly nice. I remember that commit of your, though. I will try to backport at and report of the results, thanks! ./danfe ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to "freebsd-stable-unsubscr...@freebsd.org"
Re: Resume broken in 8.3-PRERELEASE
On Monday 27 February 2012 11:47 am, Alexey Dokuchaev wrote: > On Mon, Feb 27, 2012 at 10:47:49AM -0500, Rick Macklem wrote: > > Yes, I can't think of how r229450 would affect "resume". All it > > does is clear the high order bit in an error reply from an NFS > > server, since that bit should never be set in an NFS error reply > > and, if set, it results in an mbuf list being free'd twice. > > True, although even if it helps triggering the real underlying bug, > it's still weird. > > > The bit is erroneously set by "amd" sometimes. If you are using > > "amd", that might be related to the resume problem? > > No, I don't; I've deliberately disabled almost everything. > > > ps: I suspect you saw it, but there was a recent thread related > > to known suspend/resume issues and discussed how they might be > > fixed in the future. Sorry, I don't remember which list or the > > exact subject line. > > Yes, I know what are you talking about. However, I don't recall if > any one was experiencing the same symptoms as I do. Can you please try head and/or stable/9? FYI, Linux people found that some BIOSes can corrupt low 64KB between suspend/resume, which may cause strangeness like this. I worked around it in head (r231781) and stable/9 (r232088). Thanks, Jung-uk Kim ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to "freebsd-stable-unsubscr...@freebsd.org"
Re: Resume broken in 8.3-PRERELEASE
On Mon, Feb 27, 2012 at 10:47:49AM -0500, Rick Macklem wrote: > Yes, I can't think of how r229450 would affect "resume". All it does is > clear the high order bit in an error reply from an NFS server, since that > bit should never be set in an NFS error reply and, if set, it results in > an mbuf list being free'd twice. True, although even if it helps triggering the real underlying bug, it's still weird. > The bit is erroneously set by "amd" sometimes. If you are using "amd", > that might be related to the resume problem? No, I don't; I've deliberately disabled almost everything. > ps: I suspect you saw it, but there was a recent thread related to known > suspend/resume issues and discussed how they might be fixed in the > future. Sorry, I don't remember which list or the exact subject line. Yes, I know what are you talking about. However, I don't recall if any one was experiencing the same symptoms as I do. ./danfe ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to "freebsd-stable-unsubscr...@freebsd.org"
Re: Resume broken in 8.3-PRERELEASE
Alexey Dokuchaev wrote: > On Mon, Feb 27, 2012 at 09:28:15PM +0700, Alexey Dokuchaev wrote: > > I was mistaken, the latest kernel with working resume is from Jan 4 > > 00:00 > > UTC, kernel from Jan 4 01:00 UTC does not allow my laptop to come > > back from > > zzz(8) successfully. It seems that offending change is rev. 1.9.2.5 > > of > > sys/nfsclient/nfs_krpc.c by rmacklem@ (SVN rev 229450). To be sure, > > I've > > reverted just this change in the latest RELENG_8 sources -- and the > > problem > > goes away. > > Hmm, apparently the problem lies deeply/earlier. Backing out SVN rev > 229450 allows me to resume twice, but third time it fails with the > same > symptoms as before (no keyboard while VTY switching works and > screensaver > fires, no network but ping(8) works, fans are bursting up). Stay tuned > while I investigate more... > Yes, I can't think of how r229450 would affect "resume". All it does is clear the high order bit in an error reply from an NFS server, since that bit should never be set in an NFS error reply and, if set, it results in an mbuf list being free'd twice. The bit is erroneously set by "amd" sometimes. If you are using "amd", that might be related to the resume problem? rick ps: I suspect you saw it, but there was a recent thread related to known suspend/resume issues and discussed how they might be fixed in the future. Sorry, I don't remember which list or the exact subject line. > ./danfe > ___ > freebsd-stable@freebsd.org mailing list > http://lists.freebsd.org/mailman/listinfo/freebsd-stable > To unsubscribe, send any mail to > "freebsd-stable-unsubscr...@freebsd.org" ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to "freebsd-stable-unsubscr...@freebsd.org"
Re: Resume broken in 8.3-PRERELEASE
On Mon, Feb 27, 2012 at 09:28:15PM +0700, Alexey Dokuchaev wrote: > I was mistaken, the latest kernel with working resume is from Jan 4 00:00 > UTC, kernel from Jan 4 01:00 UTC does not allow my laptop to come back from > zzz(8) successfully. It seems that offending change is rev. 1.9.2.5 of > sys/nfsclient/nfs_krpc.c by rmacklem@ (SVN rev 229450). To be sure, I've > reverted just this change in the latest RELENG_8 sources -- and the problem > goes away. Hmm, apparently the problem lies deeply/earlier. Backing out SVN rev 229450 allows me to resume twice, but third time it fails with the same symptoms as before (no keyboard while VTY switching works and screensaver fires, no network but ping(8) works, fans are bursting up). Stay tuned while I investigate more... ./danfe ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to "freebsd-stable-unsubscr...@freebsd.org"
Re: Resume broken in 8.3-PRERELEASE
On Thu, Feb 23, 2012 at 09:57:14AM +0700, Alexey Dokuchaev wrote: > Yesterday I've updated my laptop to the latest RELENG_8, it booted just > fine, however, after coming out of suspend, keyboard does not work (well, > almost: I can switch between consoles, Caps Lock works, but I cannot type > anything, login, etc., break into debugger with Ctrl-Alt-Esc). Network > does not work as well, and since fans are going up very fast, CPU > consumption must be around 100%. Kernel from Jan 17th does not exhibit > this problem. This is plain console, no X11. I was mistaken, the latest kernel with working resume is from Jan 4 00:00 UTC, kernel from Jan 4 01:00 UTC does not allow my laptop to come back from zzz(8) successfully. It seems that offending change is rev. 1.9.2.5 of sys/nfsclient/nfs_krpc.c by rmacklem@ (SVN rev 229450). To be sure, I've reverted just this change in the latest RELENG_8 sources -- and the problem goes away. Rick, how can I help you to debug this issue? I must admit I am confused how can NFS-related change break power-saving code path (suspend/resume). ./danfe ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to "freebsd-stable-unsubscr...@freebsd.org"
Resume broken in 8.3-PRERELEASE
Hi, Yesterday I've updated my laptop to the latest RELENG_8, it booted just fine, however, after coming out of suspend, keyboard does not work (well, almost: I can switch between consoles, Caps Lock works, but I cannot type anything, login, etc., break into debugger with Ctrl-Alt-Esc). Network does not work as well, and since fans are going up very fast, CPU consumption must be around 100%. Kernel from Jan 17th does not exhibit this problem. Plain console, no X11. Before I start to review all the changes in this period, perhaps someone can give me a hint which commit(s) might have caused it? Thanks, ./danfe ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to "freebsd-stable-unsubscr...@freebsd.org"
