Date: Tue, 09 Nov 2004 15:07:56 -0800 From: Nate Lawson <nate@root.org> To: Adam K Kirchhoff <adamk@voicenet.com> Cc: freebsd-acpi@freebsd.org Subject: Re: Laptop troubles... Message-ID: <41914DCC.8000100@root.org> In-Reply-To: <419145A7.3000406@voicenet.com> References: <41910F00.3070402@voicenet.com> <419113BA.9000806@root.org> <41911D01.1090303@voicenet.com> <4191201A.4080406@root.org> <4191330A.7040707@voicenet.com> <41913F15.9060701@root.org> <419145A7.3000406@voicenet.com>
next in thread | previous in thread | raw e-mail | index | archive | help
Adam K Kirchhoff wrote: > Nate Lawson wrote: > >> Adam K Kirchhoff wrote: >> >>>> The -v is just to get more info from right before the hang. Try >>>> doing things like sysctl -a, kldload linux, or whatever to see if >>>> you can isolate what's triggering this. >>>> >>> >>> Woohoo... It's /etc/rc.d/devd: >>> # ./cron start >>> Starting cron. >>> # ./devd start >>> Starting devd. >>> hw.acpi.cpu.cx_lowest: C1 -> C3 >>> hw.acpi.cpu.throttle_state: 8 -> 8 >>> >>> And then, immediately, the lockup. Want me to try adding the >>> BREAK_TO_DEBUGGER option in the kernel and see if I can get a backtrace? >> >> Ok, this is helpful. That's actually /etc/rc.d/power_profile >> switching based on input from devd as to the AC line state. Try >> manually running the sysctls: >> >> sysctl hw.acpi.cpu.cx_lowest=C3 > > This one would appear to be the culprit. When I tried it, it locked up > immediately. I rebooted, tried the throttle_state one, waited a few > minutes, and all was fine. Tried the cx_lowest one, and it locked up > again within a few seconds. > >> sysctl hw.acpi.cpu.throttle_state=8 >> >> ...waiting after each one for a minute to see if there's a hang. >> Getting a backtrace would help, yes. >> > > Unfortunately, that's proving difficult. Even with the "option > BREAK_TO_DEBUGGER" line in the kernel config, ctrl-alt-backspace isn't > dropping me to the debugger. That's fine, try cx_lowest=C2. If that works, a workaround is to set cx_performance_state=C2 and cx_economy_state=C2 in /etc/rc.conf (or something like that, see /etc/defaults/rc.conf for the right variable names). Please send me the output of acpidump -t -d > adam.asl separately as an attachment. I think I will have enough with that to debug why C3 is hanging your system. I'm pretty sure the problem area of the commit is in enabling C3 for systems that don't have bus master control. -- Nate
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?41914DCC.8000100>