Most recent kernel where this bug did not occur: Distribution: ALT Linux Hardware Environment: Notebook Clevo N55J, nVidia MCP51 Steps to reproduce: Random lockups in console mode without X (init 3). No OPS message.
Created attachment 7853 [details] /proc/cpuinfo
Created attachment 7854 [details] /proc/iomem
Created attachment 7855 [details] /proc/ioports
Created attachment 7856 [details] lspci
Created attachment 7857 [details] /proc/modules
Created attachment 7858 [details] /proc/scsi/scsi
Additional notes: Computer works fine if module powernow-k8 is not loaded. # modprobe -r powernow-k8 Without this module, notebook works fine and no more any lockups.
System freeze with powersaved running.
Created attachment 7859 [details] dmesg
what cpufreq governor are you using? Depending on the powersave configuration it might be userspace or ondemand. See /sys/devices/system/cpu/cpu0/cpufreq/scaling_governor. also, a "grep -r . /sys/devices/system/cpu/" will give a quick overview of the used configuration.
Created attachment 7860 [details] CPU freq configuration details
First of all: This bug does not depend from sata_nv (computer lockups without any ATA driver) Steps to reproduce lockups: 1. (optional) boot to init level 1 2. modprobe cpufreq_userspace modprobe powernow_k8 3. cd /sys/devices/system/cpu/cpu0/cpufreq 3. echo userspace > scaling_governor 4. while true; do echo 800000 > scaling_setspeed; sleep 4; echo 1800000 > scaling_setspeed; sleep 4; done Notebook will be hang in any way after few changes of frequency. Bug is at: powernow-k8.c -> Phase 3 (function core_voltage_post_transition) -> function write_new_vid -> wrmsr(MSR_FIDVID_CTL, lo, STOP_GRANT_5NS); Switching from 800000 kHz to 1800000 kHz all time goes fine! But in same cases switching from 1800000 kHz to 800000 kHz bring to compleate hang. Also I mentioned strange behaviour: If put printk("..."); right after wrmsr() no more lockups. (say: dmesg -n 9 on console). And last: If define STOP_GRANT_5NS as 50000 (10 msec on 500 MHz bus) computer will be locked at first switching from 1800000 kHz to 800000 kHz.
Hi both: I think I have the same problem on an AMD 64 with Debian Testing, kernel 2.6.21-2-amd64 #1 SMP. It is a desktop PC. I'm just adding myself to the CC list of this bug to get notifications of what's going on. If I can be of any help, please let me know. I'm now testing "modprobe -r powernow_k8" and it's been working for two hours without hang. Before it hung in less than an hour (about 10 times since yesterday). You can also find more people with similar problems here: https://bugs.launchpad.net/tuxlab/+source/linux-source-2.6.17/+bug/85370
Has anyone tried recent kernel? the power management has been greatly improved, the bug might has been fixed.
Hi Natalie: I have tried with kernel 2.6.24 and it still hangs. I think this bug is related (if not the same) to 8547 and 8264. I propose to follow this problem in bug 8264 to centralize all comments (mark 8547 and 6382 as duplicats of 8264) What do you think? Can anyone confirm if those three are the same bug? Thanks. Ivan
I just add here some links for - bug #8264 (powernow-k8 module gets stuck switching powerlevels on dualcore AMD64) and - bug #8547 ("Hardware error - pending bit very stuck" on Mobile AMD Sempron) for easier reference.
no update in 2 years please re-open if this is still a problem with current linux.