Date: Mon, 13 Mar 2006 09:01:35 -0800 From: Nate Lawson <nate@root.org> To: jmg@freebsd.org, current@freebsd.org Subject: Re: defaults/rc.conf v1.272 Message-ID: <4415A56F.4080207@root.org> In-Reply-To: <20060312235642.GM840@funkthat.com> References: <20060312235642.GM840@funkthat.com>
next in thread | previous in thread | raw e-mail | index | archive | help
John-Mark Gurney wrote: > Well, with this change, my machine starts to boot, but then stops > part way through... It gets to ntpdate and then stops.. I didn't > let it run very long, but it apparently was running VERY slowly.. > > After I set the cx_lowest back to HIGH, the machine booted perfectly > fine (less than a minute from kernel load to login prompt).. Could > this be a problem of not starting powerd or something that makes sure > we don't go into a low power state when running? Power savings are > good, but making FreeBSD not bootable isn't... I waited over five > minutes.. It's almost like interrupts stop working... I don't get > link state changed to UP (from ethernet) till I hit ctrl-t on the > serial console port, and after a few times, the machine appears to be > wedged, and the last messages are: > load: 0.86 not a controlling terminal > lo > > This last boot stopped after Starting syslogd. The other couple times > the last message got a bit farther... There is code in acpi_cpu.c to detect the case where we are looping too fast and disable that Cx state automatically. Can you boot with cx_lowest set to C1 and then change the value with sysctl? Perhaps put in some printfs to see if the loop is being detected? One easy debugging option would be to put a tsleep(1) at the end of acpi_cpu_idle() so that we always give other code a chance to run. The problem we're trying to debug is that the read from the register appears to return very quickly (instead of sleeping for the next interrupt), so the idle loop runs constantly. Also, please send a link to your asl (acpidump -t -d > jmg.asl) The linux code disables C2-C3 for this system: "IBM ThinkPad R40e", DMI_BIOS_VENDOR, "IBM"), DMI_BIOS_VERSION, "1SET60WW")}, It disables just C3 for these: "Medion 41700" DMI_MATCH(DMI_BIOS_VENDOR, "Phoenix Technologies LTD"), DMI_MATCH(DMI_BIOS_VERSION, "R01-A1J") "Clevo 5600D" DMI_MATCH(DMI_BIOS_VENDOR, "Phoenix Technologies LTD"), DMI_MATCH(DMI_BIOS_VERSION, "SHE845M0.86C.0013.D.0302131307")}, I don't think any of those are your system. And they seem to be total hangs anyway, not heavy kernel cpu usage. If we can't identify and isolate the problem enough to fix it, the commit to rc.conf can be reverted. However, I'd really like to find out more about which systems have this problem so we can fix it, not just paper over it. -- Nate
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?4415A56F.4080207>