Bug 252443

Please chkconfig cpuspeed off, boot the system with 'cpufreq.debug=7' added to
the kernel boot params, and then try manually modprobing acpi-cpufreq. The
feedback from the modprobe, plus the tail end of dmesg output (dmesg | tail -20)
will hopefully give us some additional clues as to what's going on.

Also, if we have a system in the building that I can reproduce this on, I could
spend a bit of time poking at this myself... (Geoff, I don't suppose you know of
one I could use?)

Brian Stein's team controls about 17 of them... I think some were supposed to go
to others but didn't. I do have one in my cube, but I'd go to the gold mine
first. :)

I've been able to reproduce the bug on a weybridge here in Westford:

[root@avocado ~]# uname -r
2.6.23-0.110.rc3.git1.fc8
[root@avocado ~]# modprobe acpi-cpufreq
Segmentation fault
[root@avocado ~]# 
Message from syslogd@ at Fri Aug 17 07:54:05 2007 ...
avocado kernel: general protection fault: 0000 [1] SMP 

set status page addr 0x00033000
acpi-cpufreq: acpi_cpufreq_init
acpi-cpufreq: acpi_cpufreq_early_init
general protection fault: 0000 [1] SMP 
CPU 1 
Modules linked in: acpi_cpufreq i915 drm ipt_MASQUERADE iptable_nat nf_nat
bridge autofs4 hidp rfcomm l2cap bluetoo
th sunrpc ipv6 nf_conntrack_netbios_ns nf_conntrack_ipv4 xt_state nf_conntrack
nfnetlink xt_tcpudp ipt_REJECT iptab
le_filter ip_tables x_tables video output sbs dock battery ac lp loop kvm_intel
kvm snd_hda_intel snd_seq_dummy snd
_seq_oss snd_seq_midi_event snd_seq snd_seq_device snd_pcm_oss snd_mixer_oss
snd_pcm snd_timer 3c59x snd parport_pc
 sr_mod button soundcore mii e1000e parport floppy rtc_cmos cdrom i2c_i801
snd_page_alloc serio_raw i2c_core sg dm_
snapshot dm_zero dm_mirror dm_mod ata_generic ata_piix libata sd_mod scsi_mod
ext3 jbd mbcache ehci_hcd ohci_hcd uh
ci_hcd
Pid: 3574, comm: modprobe Not tainted 2.6.23-0.110.rc3.git1.fc8 #1
RIP: 0010:[<ffffffff8115c56f>]  [<ffffffff8115c56f>]
acpi_ns_get_parent_node+0x7/0x15
RSP: 0018:ffff810059acbcd0  EFLAGS: 00010282
RAX: 0000000000000000 RBX: 0000000000000005 RCX: ffff810059acbd58
RDX: ffff81007d1a5ee0 RSI: ffff810059acbd00 RDI: a56b6b6b6b6b6b6b
RBP: 0000000000000000 R08: ffff81007d1a5ee0 R09: ffff81007d0a3098
R10: 0000000000000287 R11: ffff81007d0a3098 R12: ffff81007d1a5ee0
R13: ffff810059acbd58 R14: ffffffff81163b22 R15: ffff810059acbdf8
FS:  00002aaaab0166f0(0000) GS:ffff810037c4d578(0000) knlGS:0000000000000000
CS:  0010 DS: 0000 ES: 0000 CR0: 000000008005003b
CR2: 000000000062600f CR3: 00000000795b9000 CR4: 00000000000026e0
DR0: 0000000000000000 DR1: 0000000000000000 DR2: 0000000000000000
DR3: 0000000000000000 DR6: 00000000ffff0ff0 DR7: 0000000000000400
Process modprobe (pid: 3574, threadinfo ffff810059aca000, task ffff8100598b6000)
Stack:  ffffffff8115c2d2 ffff810059acbd00 ffffffff81163a5a ffff810059acbd58
 ffffffff81163b4d ffff81007d0a3000 0000000000000018 ffff81007d0a3098
 ffffffff8116271c 0000000000000000 ffff81007d0a3000 ffff810059acbd98
Call Trace:
 [<ffffffff8115c2d2>] acpi_ns_get_pathname_length+0xa/0x31
 [<ffffffff81163a5a>] acpi_ut_get_simple_object_size+0x77/0xd9
 [<ffffffff81163b4d>] acpi_ut_get_element_length+0x2b/0x4f
 [<ffffffff8116271c>] acpi_ut_walk_package_tree+0x5b/0xd5
 [<ffffffff81163af6>] acpi_ut_get_object_size+0x3a/0x66
 [<ffffffff8115bea9>] acpi_evaluate_object+0x17a/0x1e5
 [<ffffffff8116d102>] acpi_processor_preregister_performance+0xce/0x41c
 [<ffffffff88118062>] :acpi_cpufreq:acpi_cpufreq_init+0x62/0x92
 [<ffffffff8105cfa8>] sys_init_module+0x15d5/0x173a
 [<ffffffff8100be55>] tracesys+0xdc/0xe1


Code: f6 47 0a 01 48 8b 7f 18 74 f6 48 89 f8 c3 31 c0 f6 47 0a 01 
RIP  [<ffffffff8115c56f>] acpi_ns_get_parent_node+0x7/0x15
 RSP <ffff810059acbcd0>


For the record, on the same system, running kernel-2.6.21-1.3228.fc7,
acpi-cpufreq loads just fine, and cpu frequency scaling works as expected.

The latest rawhide kernels have ACPI debugging enabled; acpi.debug_level and
acpi.debug_layer kernel options should give some additional information.

ffffffff8115c568 <acpi_ns_get_parent_node>:
/usr/src/debug/kernel-2.6.22/linux-2.6.22.x86_64/drivers/acpi/namespace/nsutils.c:905
ffffffff8115c56f:       f6 47 0a 01             testb  $0x1,0xa(%rdi)
ffffffff8115c573:       48 8b 7f 18             mov    0x18(%rdi),%rdi
ffffffff8115c577:       74 f6                   je     ffffffff8115c56f 

But RDI == a56b6b6b6b6b6b6b

So it is using freed memory as a pointer to something.

The testing platform:intel Weybridge.
The testing OS: fedora f8test2 i686 live CD.

This bug was recurring on Fedora f8test2 i686 live CD.

Does this happen on vanilla kernels as well? Test kernel:

http://people.redhat.com/cebbert/kernels/F8/x86_64/kernel-vanilla-2.6.23-0.185.rc6.git7.V.x86_64.rpm

The bug also recurred on kernel-vanilla-2.6.23-0.185.rc6.git7.V.x86_64.rpm

*** Bug 349941 has been marked as a duplicate of this bug. ***

(In reply to comment #7)
> Does this happen on vanilla kernels as well? Test kernel:
> 
>
http://people.redhat.com/cebbert/kernels/F8/x86_64/kernel-vanilla-2.6.23-0.185.rc6.git7.V.x86_64.rpm
> 

I didn't have any problems with vanilla 2.6.23 from kernel.org. At the moment
I'm running 2.6.23.1-cfs-v22.1 and it works fine also. So did 2.6.23.rc{2,4,8}.

Kernel 2.6.23.1-35.fc8 boots on my machine.

(In reply to comment #8)
> The bug also recurred on kernel-vanilla-2.6.23-0.185.rc6.git7.V.x86_64.rpm
> 
> 

Was this fixed for you in the latest Fedora 8 kernels?

kernel 2.6.23-0.214.rc8-git2 boots well on my machine also.

This bug still can be reproduced in "weybridge" platform under 2.6.23-
0.214.rc8-git2.fc8 (Fedora test 3 for x86-64.) The above comments from bibo is 
for "Montevina" platform. 

On weybridge, please give 2.6.23.1-37.fc8 or later a try -- I believe that's what Chuck was asking about.

I just try it in F8 test 3. Can you give me a hint on where can I get 2.6.23.1-
37.fc8 or later version? I didn't find it in 
http://people.redhat.com/cebbert/kernels/F8 and fedoraproject.org.
BTW, the F8 will use 2.6.23.1-xxx for final release?

I just try it in F8 test 3. Can you give me a hint on where can I get 2.6.23.1-
37.fc8 or later version? I didn't find it in 
http://people.redhat.com/cebbert/kernels/F8 and fedoraproject.org.
BTW, the F8 will use 2.6.23.1-xxx for final release?

Latest working is kernel-2.6.23.1-41.fc8:
http://koji.fedoraproject.org/koji/buildinfo?buildID=22818

Yes, I just tried the kernel-2.6.23.1-41.fc8 from charlesr, it was fixed. 

Hi guys,
    I am new to this forum. I have a greencity board and just tried booting Redhat Enterprise Linux 2.6.28.6 on this board and i see the same error reported in this bug.

/etc/rc5.d/S06cpuspeed: line 111: 7089 Segmentation Fault /sbin/modprobe acpi-cpufreq 2 > /dev/NULL

   The system stops booting after getting this error.

   Could you please let me know what the fix is for this error?

   Appreciate your response.

Thanks,
Aru

(In reply to comment #20)
> Hi guys,
>     I am new to this forum. I have a greencity board and just tried booting
> Redhat Enterprise Linux 2.6.28.6 on this board and i see the same error
> reported in this bug.
> 
> /etc/rc5.d/S06cpuspeed: line 111: 7089 Segmentation Fault /sbin/modprobe
> acpi-cpufreq 2 > /dev/NULL
> 
>    The system stops booting after getting this error.
> 
>    Could you please let me know what the fix is for this error?


That's a different board and a different kernel. Could be a similar bug, but the one in this report is already fixed, so please open a new bug. When you do, please provide the console log from booting with the kernel parameters 'rhgb quiet' removed, and the additional kernel paramaters 'debug cpufreq.debug=7'.