Description of problem: The tscsync variable is declared as __initdata but is accessed post-init. This causes a panic. Version-Release number of selected component (if applicable): 2.6.9-42.38.EL How reproducible: Some systems never, other systems 100%. (HP xw9400 reproduces this 100% of the time) Steps to Reproduce: 1. load powernow-k8 module 2. attempt to change the cpu frequency Actual results: powernow-k8: ph2 null fid transition 0x12 powernow-k8: ph2 null fid transition 0x12 Unable to handle kernel paging request at virtual address f89a02fc printing eip: f8bed14d *pde = 00000000 Oops: 0000 [#1] SMP Modules linked in: powernow_k8(U) md5(U) ipv6(U) parport_pc(U) lp(U) parport(U)) CPU: 1 EIP: 0060:[<f8bed14d>] Not tainted VLI EFLAGS: 00010202 (2.6.9-prep) EIP is at write_new_fid+0x41/0x172 [powernow_k8] eax: 00000000 ebx: c2258580 ecx: 00000012 edx: 00000000 esi: 00010910 edi: 0000000e ebp: c2258580 esp: f5918e7c ds: 007b es: 007b ss: 0068 Process testpowernow (pid: 4602, threadinfo=f5918000 task=f7a44970) Stack: 01c65f60 00000000 00000009 00000010 c2258580 00000012 0000000e 0000000e f8bed50c 00000009 c2258580 0000000c 0000000e 0000000c f8bed38c c2258580 0000000e 00000020 f8bee007 c2258580 00000001 0027ac40 002191c0 00000000 Call Trace: [<f8bed50c>] core_frequency_transition+0x99/0x104 [powernow_k8] [<f8bed38c>] transition_fid_vid+0x22/0x83 [powernow_k8] [<f8bee007>] transition_frequency_fidvid+0xf1/0x1ee [powernow_k8] [<f8bee400>] powernowk8_target+0x1c3/0x242 [powernow_k8] [<c0275886>] __cpufreq_driver_target+0x28/0x2f [<c027615d>] cpufreq_set+0x6d/0x85 [<c02761eb>] store_speed+0x32/0x3a [<c02761b9>] store_speed+0x0/0x3a [<c02752a9>] store+0x31/0x41 [<c018ea8f>] flush_write_buffer+0x20/0x25 [<c018eaeb>] sysfs_write_file+0x57/0x7c [<c015b1df>] vfs_write+0xb6/0xe2 [<c015b2a9>] sys_write+0x3c/0x62 [<c02d5a3f>] syscall_call+0x7/0xb Code: 04 00 00 00 00 89 44 24 08 75 05 83 e0 c0 74 0a 68 f2 e5 be f8 e9 2d 01 0 <0>Fatal exception: panic in 5 seconds Kernel panic - not syncing: Fatal exception Expected results: No panic should occur. Additional info: This doesn't appear to happen on RHEL4.4 even though the tscsync variable is declared __initdata. As with all improper declarations of this type, the memory usage and layout can cause a bug to occur/not occur. Since this doesn't happen in 4.4, I'm marking this as a regression.
Created attachment 145161 [details] Patch to remove __initdata from tscsync variable
patch posted 1/9/07.
This request was evaluated by Red Hat Product Management for inclusion in a Red Hat Enterprise Linux maintenance release. Product Management has requested further review of this request by Red Hat Engineering, for potential inclusion in a Red Hat Enterprise Linux Update release for currently deployed products. This request is not yet committed for inclusion in an Update release.
committed in stream U5 build 42.40. A test kernel with this patch is available from http://people.redhat.com/~jbaron/rhel4/
QE ack for RHEL4.5.
Similar issue in RHEL5 Beta. See BZ#224116.
I've confirmed the patch is in the -52 kernel, unfortunately the AMD test system I have has never reproduced the problem.
(In reply to comment #8) > I've confirmed the patch is in the -52 kernel, unfortunately the AMD test system > I have has never reproduced the problem. Mike, IIRC the HP xw9400 (AMD based system) reproduces this issue 100% of the time. P.
An advisory has been issued which should help the problem described in this bug report. This report is therefore being closed with a resolution of ERRATA. For more information on the solution and/or where to find the updated files, please follow the link below. You may reopen this bug report if the solution does not work for you. http://rhn.redhat.com/errata/RHBA-2007-0304.html