Description of problem: On an Opteron based system, the RHEL 3.0 v2.4.21-20.0.1.EL kernel panics after several hours of running raw I/O. This panic occurs both with and without PowerPath. Per the PowerPath team: One of the dd processes issues an IO and calls kiobuf_wait_for_io(), which in turn calls schedule(). In schedule(), the kernel attempts to perform a context switch, an panics because the task struct pointer passed in for the new process is NULL. This points to kernel memory corruption, more specifically corruption of CPU runqueueus. Version-Release number of selected component (if applicable): kernel-source-2.4.21-20.0.1.EL x86_64 How reproducible: Run raw I/O for serveral hours on an AMD64 Opteron-based system Steps to Reproduce: 1. 2. 3. Actual results: Expected results: Additional info:
Created attachment 108621 [details] trace of Oops without PowerPath running on the system Enclosing a trace of the Oops that occurred without PowerPath running on the system.
Created attachment 108623 [details] trace of the Oops that occurred with PowerPath Enclosing a trace of the Oops that occurred without PowerPath running on the system.
I neglected to mention that this is PowerPath v4.3.1.
Heather, please attach a trace (oops output) from a non-tainted kernel. Also, please do not attach Microsoft Word documents in the future.
I have not been able to replicate this and have not received any feedback from the PowerPath team so I am considering this issue as NOTABUG.
Created attachment 110369 [details] Oops with no PP in text format
oops - I closed the wrong Bugzilla. The Oops output is being attached in text format.
Created attachment 110370 [details] Oops with PP in text format Attaching text document of Oops with PowerPath installed.
I am seeing a very similar issue, but the system doesn't panic. What is the status of this bug?
Is this still a problem with the patest RHEL3-U6 update? The reason I ask is that several generic kernel changes and changes to the x86_64 specific code have been made to RHEL3 since 2.1.21-20. Can someone please verify that this problem still occurs with the latest kernel? Thanks, Larry Woodman
This bug is filed against RHEL 3, which is in maintenance phase. During the maintenance phase, only security errata and select mission critical bug fixes will be released for enterprise products. Since this bug does not meet that criteria, it is now being closed. For more information of the RHEL errata support policy, please visit: http://www.redhat.com/security/updates/errata/ If you feel this bug is indeed mission critical, please contact your support representative. You may be asked to provide detailed information on how this bug is affecting you.