Re: USB controller error logged when resuming after suspend
On Sat, 27 Nov 2010 18:46:22 -0600 Brandon Gooch jamesbrandongo...@gmail.com wrote: Do you mean USB subsystem infrastructure, or something more far-reaching? It seems to me that it's SO close to being functional; in fact, I've taken to not loading any USB drivers at all on my notebook, which seems to be the only reliable way of using suspend/resume -- that's not to say that it's perfect, but Pretty Good(TM). Also, If we could round-up the various sysctl settings and document them in one place([1] or [2]), I imagine many users would have suspend/resume as a workable feature, at least on amd64... It appears very close on some machines, but far away on others. For example my laptop suspends/resumes with VGA once if the nvidia driver is running, but panics when shutting down after that, and attempting to suspend another time results in a reboot. Other people say that suspending doesn't work at all. I think there's a lot of work other than in the USB stack that needs done before it's going to be reliable for everyone. I believe there's a wiki page being created with a list of issues that need resolved. -- Bruce Cran ___ 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 controller error logged when resuming after suspend
On Fri, Nov 26, 2010 at 1:49 AM, Bruce Cran br...@cran.org.uk wrote: On Thu, 25 Nov 2010 20:46:42 -0600 Brandon Gooch jamesbrandongo...@gmail.com wrote: It's becoming more well known that the USB stack isn't suspend/resume safe at this point. Have you tried building your USB systems as kernel modules and unloading/loading them via /etc/rs.suspend|resume? I used to have luck doing that here, but recently that has broken as well (running HEAD). I'm not so interested in using suspend/resume as a real feature, but more as a developer to report issues so that in the future we can perhaps have it working for end-users. Apparently there's lots of infrastructure work that still needs to be done before it's going to be reliable unfortunately. Do you mean USB subsystem infrastructure, or something more far-reaching? It seems to me that it's SO close to being functional; in fact, I've taken to not loading any USB drivers at all on my notebook, which seems to be the only reliable way of using suspend/resume -- that's not to say that it's perfect, but Pretty Good(TM). Also, If we could round-up the various sysctl settings and document them in one place([1] or [2]), I imagine many users would have suspend/resume as a workable feature, at least on amd64... -Brandon [1] http://www.freebsd.org/doc/en_US.ISO8859-1/books/handbook/acpi-debug.html [2] http://www.freebsd.org/doc/en/articles/laptop/article.html or ___ 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 controller error logged when resuming after suspend
On Sun, Nov 14, 2010 at 3:36 PM, Bruce Cran br...@cran.org.uk wrote: I've been trying to get my laptop working with suspend/resume. It comes back, but USB seems rather unhappy about something for a while. Despite this, plugging a flash drive in does attach to the EHCI controller at usbus6. You have better luck than me! On my system, port 2 reset fails, port is disabled, an none of my external ports work at all, like this: [SNIP] uhub_reattach_port: port 2 reset failed, error=USB_ERR_TIMEOUT uhub_reattach_port: device problem (USB_ERR_TIMEOUT), disabling port 2 [SNIP] It's becoming more well known that the USB stack isn't suspend/resume safe at this point. Have you tried building your USB systems as kernel modules and unloading/loading them via /etc/rs.suspend|resume? I used to have luck doing that here, but recently that has broken as well (running HEAD). Also, it's been my experience that multiple suspend/resume cycles can permanently shut down your ports... -Brandon ___ 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 controller error logged when resuming after suspend
On Thu, 25 Nov 2010 20:46:42 -0600 Brandon Gooch jamesbrandongo...@gmail.com wrote: It's becoming more well known that the USB stack isn't suspend/resume safe at this point. Have you tried building your USB systems as kernel modules and unloading/loading them via /etc/rs.suspend|resume? I used to have luck doing that here, but recently that has broken as well (running HEAD). I'm not so interested in using suspend/resume as a real feature, but more as a developer to report issues so that in the future we can perhaps have it working for end-users. Apparently there's lots of infrastructure work that still needs to be done before it's going to be reliable unfortunately. -- Bruce Cran ___ 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
USB controller error logged when resuming after suspend
I've been trying to get my laptop working with suspend/resume. It comes back, but USB seems rather unhappy about something for a while. Despite this, plugging a flash drive in does attach to the EHCI controller at usbus6. uhci2: wake_prep disabled wake for \\_SB_.PCI0.USB1 (S3) uhci3: wake_prep disabled wake for \\_SB_.PCI0.USB2 (S3) uhci4: wake_prep disabled wake for \\_SB_.PCI0.USB3 (S3) uhci0: wake_prep disabled wake for \\_SB_.PCI0.USB4 (S3) uhci1: wake_prep disabled wake for \\_SB_.PCI0.USB5 (S3) ehci0: wake_prep disabled wake for \\_SB_.PCI0.EHC2 (S3) ehci1: wake_prep disabled wake for \\_SB_.PCI0.EHCI (S3) acpi_lid0: wake_prep enabled for \\_SB_.LID_ (S3) acpi_button0: wake_prep enabled for \\_SB_.PBTN (S3) vga0: saving 68 bytes of video state vga0: saving color palette pci0:1:0:0: Transition from D0 to D3 pci0:0:1:0: Transition from D0 to D3 uhci_interrupt: resume detect pci0:9:0:0: Transition from D0 to D3 pci0:0:28:0: Transition from D0 to D3 pci0:0:28:1: Transition from D0 to D3 pci0:12:0:0: Transition from D0 to D3 pci0:0:28:4: Transition from D0 to D3 pci0:0:26:7: Transition from D0 to D3 pci0:0:29:7: Transition from D0 to D3 ehci_interrupt: unrecoverable error, controller halted cmd=0x EHCI_CMD_ITC_1 EHCI_CMD_ITC_2 EHCI_CMD_ITC_4 EHCI_CMD_ITC_8 EHCI_CMD_ITC_16 EHCI_CMD_ITC_32 EHCI_CMD_ITC_64 EHCI_CMD_ASPME EHCI_CMD_ASPMC EHCI_CMD_LHCR EHCI_CMD_IAAD EHCI_CMD_ASE EHCI_CMD_PSE EHCI_CMD_FLS_M EHCI_CMD_HCRESET EHCI_CMD_RS sts=0x EHCI_STS_ASS EHCI_STS_PSS EHCI_STS_REC EHCI_STS_HCH EHCI_STS_IAA EHCI_STS_HSE EHCI_STS_FLR EHCI_STS_PCD EHCI_STS_ERRINT EHCI_STS_INT ien=0x frindex=0x ctrdsegm=0x periodic=0x async=0x port 1 status=0x port 2 status=0x port 3 status=0x port 4 status=0x port 5 status=0x port 6 status=0x ehci_dump_isoc: isochronous dump from frame 0x07f: ITD(0xff81248e3000) at 0x054b5000 next=0x05535004 status[0]=0x; status[1]=0x; status[2]=0x; status[3]=0x; status[4]=0x; status[5]=0x; status[6]=0x; status[7]=0x; bp[0]=0x addr=0x00; endpt=0x0 bp[1]=0x dir=out; mpl=0x00 bp[2..6]=0x,0x,0x,0x,0x bp_hi=0x,0x,0x,0x, 0x,0x,0x SITD(0xff8124963000) at 0x05535000 next=0x053f5002 portaddr=0x dir=out addr=0 endpt=0x0 port=0x0 huba=0x0 mask=0x status=0x len=0x0 back=0x0001, bp=0x,0x,0x,0x ehci_interrupt: blocking interrupts 0x10 pci0:0:31:2: Transition from D0 to D3 usbus6: port reset timeout uhub_reattach_port: port 1 reset failed, error=USB_ERR_TIMEOUT uhub_reattach_port: device problem (USB_ERR_TIMEOUT), disabling port 1 ct_to_ts([2010-11-14 21:30:44]) = 1289770244.0 acpi_lid0: run_prep cleaned up for \\_SB_.LID_ acpi_button0: run_prep cleaned up for \\_SB_.PBTN ugen2.2: OmniVision Technologies, Inc. -2640-08.05.12.1 at usbus2 (disconnected) uhci_interrupt: resume detect uhci_interrupt: host system error uhci_interrupt: host controller process error pci0: set ACPI power state D0 on \\_SB_.PCI0.AGP_ uhci_interrupt: resume detect uhci_interrupt: host system error uhci_interrupt: host controller process error pci0: set ACPI power state D0 on \\_SB_.PCI0.USB4 pci0: set ACPI power state D0 on \\_SB_.PCI0.USB5 pci0: set ACPI power state D0 on \\_SB_.PCI0.EHC2 uhci_interrupt: resume detect uhci_interrupt: host system error uhci_interrupt: host controller process error pci0: set ACPI power state D0 on \\_SB_.PCI0.RP01 pci0: set ACPI power state D0 on \\_SB_.PCI0.RP02 uhci_interrupt: resume detect uhci_interrupt: host system error uhci_interrupt: host controller process error pci0: set ACPI power state D0 on \\_SB_.PCI0.RP05 pci0: set ACPI power state D0 on \\_SB_.PCI0.USB1 pci0: set ACPI power state D0 on \\_SB_.PCI0.USB2 uhci_interrupt: resume detect uhci_interrupt: host system error uhci_interrupt: host controller process error pci0: set ACPI power state D0 on \\_SB_.PCI0.USB3 pci0: set ACPI power state D0 on \\_SB_.PCI0.EHCI uhci_interrupt: resume detect uhci_interrupt: host system error uhci_interrupt: host controller process error pci0: set ACPI power state D0 on \\_SB_.PCI0.PCIE uhci_interrupt: resume detect uhci_interrupt: host system error uhci_interrupt: host controller process error pci0: set ACPI power state D0 on \\_SB_.PCI0.ISAB pci0: set ACPI power state D0 on \\_SB_.PCI0.IDE1uhci_interrupt: resume detect uhci_interrupt: host system error uhci_interrupt: host controller process error pci0: set ACPI power state D0 on \\_SB_.PCI0.IDE0 pci0: set ACPI power state D0 on \\_SB_.PCI0.AGP_ uhci_interrupt: resume detect pci1: set ACPI power state D0 on \\_SB_.PCI0.AGP_.VID_ usbus2: port reset timeout uhub_reattach_port: port 1 reset failed, error=USB_ERR_TIMEOUT uhub_reattach_port:
