Date: Fri, 11 Jan 2013 09:22:37 -0800 From: matt <sendtomatt@gmail.com> To: Jason Selwitz <jselwitz@verizon.net> Cc: freebsd-acpi@freebsd.org, Ian Smith <smithi@nimnet.asn.au> Subject: Re: No keyboard after Suspend/Resume Message-ID: <50F04A5D.1060201@gmail.com> In-Reply-To: <50F03C59.3010605@verizon.net> References: <50EEECD8.30201@verizon.net> <50EF1928.5000005@verizon.net> <20130111163803.G62930@sola.nimnet.asn.au> <50F01DB8.404@verizon.net> <20130112020013.N62930@sola.nimnet.asn.au> <50F03C59.3010605@verizon.net>
next in thread | previous in thread | raw e-mail | index | archive | help
On 01/11/13 08:22, Jason Selwitz wrote: > Thought I would shoot off a quick detail of my setup, maybe this will > help shed more light on the issue.. > > firstly this system is a Laptop, in a docking station, the keyboard is > connected to the docking station via both the PS/2 port and a USB > connection, it can also be set up to use 2 USB connections (perhaps the > PS/2 connection is not coming back fully after a suspend/resume cycle). > however after a little more testing after a resume, even the laptops > built in keyboard does not respond though I am able to pull the ps2 > connection remove the adapter and connect it to a USB port and have the > keyboard work again, though if the keyboard is in a USB port during the > suspend/resume I see the system reattaching the keyboard but it does not > allow text input until it is physically unplugged then reconnected. I'll > keep trying a few things and send any interesting debug info that I come > across.. thanks again to all.. > > Jason > > > > > Just some generic hardware wrangling ideas :) Just want to check if this is in the console, X, or both...Just saw a post about "unplugging and replugging" keyboard issues with X/hal (I've had some configs that had similar issues with mice as a pebkac with hal setup). If you've only tried in X switching to a VT and trying in the console (or not starting X) and testing again may be worthwhile to rule out high level problems. You could also try putting something in rc.resume using usbconfig to reset the bus? I'm not sure if there's a way to just send reset, but you could send power_off and then power_on to the specific device/bus combo for the keyboard. Try setting hw.pci.do_power_resume=1 and hw.pci.do_power_suspend=0 in case it's a PCI D state issue. Other combos might be worthwhile, some will likely break resume or suspend however. Might as well set hw.usb.ukbd.debug=1 and check the dmesg on resume as well. Matt
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?50F04A5D.1060201>