|
Bugzilla – Full Text Bug Listing |
| Summary: | acpi-cpufreq kills Medion MD 8386 during boot | ||
|---|---|---|---|
| Product: | [openSUSE] SUSE LINUX 10.0 | Reporter: | Michael Calmer <mc> |
| Component: | Kernel | Assignee: | Thomas Renninger <trenn> |
| Status: | RESOLVED DUPLICATE | QA Contact: | E-mail List <qa-bugs> |
| Severity: | Normal | ||
| Priority: | P5 - None | CC: | trenn |
| Version: | Beta 3 | ||
| Target Milestone: | --- | ||
| Hardware: | Other | ||
| OS: | All | ||
| Whiteboard: | |||
| Found By: | Other | Services Priority: | |
| Business Priority: | Blocker: | --- | |
| Marketing QA Status: | --- | IT Deployment: | --- |
| Attachments: |
messages, boot.omsg, hwinfo
/var/log/messages with debug=7 and acpi debug 0xfffff |
||
|
Description
Michael Calmer
2005-08-26 07:00:37 UTC
Created attachment 47705 [details]
messages, boot.omsg, hwinfo
See Bug #73696 seems that trenn is on vacation. => assign to hmacht Are you sure it only happens when powersaved is started? The two lines from powersaved in messages.bak are really unimportant and got removed for beta4. Aug 25 19:37:44 linux [powersave]: WARNING (filter_function:250) Received message from invalid interface Aug 25 19:37:44 linux [powersave]: WARNING (filter_function:250) Received message from invalid interface The rest really looks more like a kernel issue. Mainly from messages.bak2: Aug 26 08:36:13 Vigor10 kernel: CPU: 0 Aug 26 08:36:13 Vigor10 kernel: EIP: 0060:[<c01b306f>] Tainted: G U VLI Aug 26 08:36:13 Vigor10 kernel: EFLAGS: 00010246 (2.6.13-rc6-git13-4-smp) Aug 26 08:36:13 Vigor10 kernel: EIP is at create_dir+0x2f/0x190 Aug 26 08:36:13 Vigor10 kernel: eax: 00000000 ebx: f6f69800 ecx: ffffffff edx: dffc85c0 Aug 26 08:36:13 Vigor10 kernel: esi: 00000001 edi: 00000001 ebp: dfe10e88 esp: f61a5e34 Aug 26 08:36:13 Vigor10 kernel: ds: 007b es: 007b ss: 0068 Aug 26 08:36:13 Vigor10 kernel: Process modprobe (pid: 5669, threadinfo=f61a4000 task=f751a020) Aug 26 08:36:13 Vigor10 kernel: Stack: 00000001 00027100 00000000 f6f69800 00000000 c0474174 00000001 c01b321a Aug 26 08:36:13 Vigor10 kernel: f61a5e58 00000000 f6f69800 c021c0ab f6f69800 fffffffe c021c301 f6f69800 Aug 26 08:36:13 Vigor10 kernel: ffffffea c03d3c8c c021c382 f61a5e60 f6f69780 f6f69844 f6f69780 f6f69844 Aug 26 08:36:13 Vigor10 kernel: Call Trace: Aug 26 08:36:13 Vigor10 kernel: [<c01b321a>] sysfs_create_dir+0x2a/0x70 Aug 26 08:36:13 Vigor10 rcpowersaved: enter 'CPUFREQD_MODULE=off' in /etc/sysconfig/powersave/cpufreq to avoid this warning. Aug 26 08:36:13 Vigor10 kernel: [<c021c0ab>] create_dir+0x1b/0x60 Aug 26 08:36:13 Vigor10 kernel: [<c021c301>] kobject_add+0x71/0xd0 Aug 26 08:36:13 Vigor10 kernel: [<c021c382>] kobject_register+0x22/0x70 Aug 26 08:36:13 Vigor10 kernel: [<c02cc619>] cpufreq_add_dev+0x1b9/0x3c0 Aug 26 08:36:13 Vigor10 kernel: [<c029adfa>] sysdev_driver_register+0x5a/0xa0 Aug 26 08:36:13 Vigor10 kernel: [<c02cd456>] cpufreq_register_driver+0x66/0x110 Aug 26 08:36:13 Vigor10 kernel: [<c01438ec>] sys_init_module+0xcc/0x1e0 Aug 26 08:36:13 Vigor10 kernel: [<c01042ab>] sysenter_past_esp+0x54/0x79 Aug 26 08:36:13 Vigor10 rcpowersaved: powersave cpufreq governor could not be loaded It seems it crashes while modprobe the powernow-k7 module. Why does it try to load the powernow module for a pentium 4 cpu? The following looks fishy too: dswload-0304: *** Error: Looking up [_PPC] in namespace, AE_ALREADY_EXISTS psparse-0622 [19] ps_parse_loop : During name lookup/catalog, AE_ALREADY_EXISTS psparse-1172: *** Error: Method execution failed [\_PR_.CPU1._PDC] (Node dffd2be8), AE_ALREADY_EXISTS powernow: This module only works with AMD K7 CPUs acpi-cpufreq: CPU0 - ACPI performance management activated. dswload-0304: *** Error: Looking up [_PPC] in namespace, AE_ALREADY_EXISTS psparse-0622 [19] ps_parse_loop : During name lookup/catalog, AE_ALREADY_EXISTS psparse-1172: *** Error: Method execution failed [\_PR_.CPU1._PDC] (Node dffd2be8), AE_ALREADY_EXISTS acpi-cpufreq: CPU1 - ACPI performance management activated. Can you load the cpufreq module with "debug=255" please? It is my home PC. I will try it this evening Olaf: yes, ACPI complains like that, pretty much all the time :-(. Thats what you get with broken ACPI bioses.. Also try simply removing powernow-k7 from your system... I tried (trenn@suse.de told me this the last time): - booting runlevel 1 with parameter cpufreq.debug=7 (and 255 no different) - start syslog - echo "0xFFFFF" > /proc/acpi/debug_level - modprobe acpi-cpufreq I attche the resulting /var/log/messages . After the modprobe the system was unusable. Every command segfaults. (see messages "Unable to load interpreter /lib/ld-linux.so.2" Please have a look at the boot.msg file I attached before. It seems that starting the powersave daemon also throws some error messages: /etc/init.d/powersaved: line 143: 5659 Killed $LOGGER "this will speed up starting powersaved and avo id unnecessary warnings in syslog." /etc/init.d/powersaved: line 108: 5662 Killed modprobe -q cpufreq_powersave >/dev/null 2>&1 /etc/init.d/powersaved: line 108: 5663 Killed $LOGGER powersave cpufreq governor could not be loaded /etc/init.d/powersaved: line 124: 5664 Killed modprobe -q cpufreq_userspace >/dev/null 2>&1 /etc/init.d/powersaved: line 124: 5665 Killed $LOGGER userspace cpufreq governor could not be loaded Starting powersaved (accessing ACPI events over acpid) <notice>startproc: execve (/usr/sbin/powersaved) [ /usr/sbin/powers aved -d -f -v 3 ], [ CONSOLE=/dev/console TERM=linux SHELL=/bin/sh ROOTFS_FSCK=0 INIT_VERSION=sysvinit-2.85 REDIRECT=/dev/t ty1 PATH=/sbin:/usr/sbin:/bin:/usr/bin:/lib/klibc/bin vga=0x317 RUNLEVEL=3 PWD=/ SPLASHCFG=/etc/bootsplash/themes/SuSE/conf ig/bootsplash-1024x768.cfg PREVLEVEL=N LINES=44 HOME=/ SHLVL=2 splash=verbose ROOTFS_BLKDEV=/dev/sda8 _=/sbin/startprocdone Created attachment 47861 [details]
/var/log/messages with debug=7 and acpi debug 0xfffff
Pavel: removing powernow-k7 does not help. So... it is not powernow-k7 that kills your machine, it is acpi-cpufreq that does the killing? How many errors are there in the DSDT? [HOWTOs are all over the web] Can you try commenting out all the code in arch/i386/kernel/cpu/cpufreq/acpi-cpufreq: acpi_cpufreq_target() . This one is known. The SSDT table is loaded twice. I can submit a patch that will go mainline, give me some time to read the mails of the last half week ... I will send olh a patch for it and tell you as soon as there is something to test. The patch has been commited to Len Browns acpi tree for inclusion to 2.6.14. Unfortunately it is inside a ACPICA patch that also inlcudes lindentation of all ACPI files (what means that the patch touches more than 20 files). After asking two times on the ACPI list I asked the ACPI maintainers directly for a separate patch. If I don't get it in a few hours I'll try to separate the patch or just come up with a similar one... Could I access the machine for testing then? *** This bug has been marked as a duplicate of 75808 *** |