Bug 28139
Summary: | Pump taking kernel panic on TR interface at bootup | ||
---|---|---|---|
Product: | [Retired] Red Hat Linux | Reporter: | Bill Stephens <bill.stephens> |
Component: | kernel | Assignee: | Michael K. Johnson <johnsonm> |
Status: | CLOSED CURRENTRELEASE | QA Contact: | David Lawrence <dkl> |
Severity: | high | Docs Contact: | |
Priority: | medium | ||
Version: | 7.1 | CC: | alan |
Target Milestone: | --- | ||
Target Release: | --- | ||
Hardware: | i386 | ||
OS: | Linux | ||
Whiteboard: | |||
Fixed In Version: | Doc Type: | Bug Fix | |
Doc Text: | Story Points: | --- | |
Clone Of: | Environment: | ||
Last Closed: | 2003-06-09 15:01:07 UTC | Type: | --- |
Regression: | --- | Mount Type: | --- |
Documentation: | --- | CRM: | |
Verified Versions: | Category: | --- | |
oVirt Team: | --- | RHEL 7.3 requirements from Atomic Host: | |
Cloudforms Team: | --- | Target Upstream Version: | |
Embargoed: |
Description
Bill Stephens
2001-02-17 14:40:56 UTC
I'm beginning to suspect either the olympic driver, or the way the kernel handles PCI on this box. I'm not sure which at this point. Here is some of the register information, hopefully that'll help someone figure out what's wrong: *pde = 0728d001 *pte = 00000000 Ooops:0000 CPU: 1 EIP:0010:[<00000000>] eflags: 000010246 eax: 00000000 ebx: c5f15900 ecx:0000000 edx:c494f750 esi: c494f6e0 edi:c42d2a00 ebp:c5f15900 esp: c728fc40 Process pump (pid838, stackpage=c728f000) Stack and call trace stuff........ Code: Bad EIP value Kernel panic: Aiee, killing interrupt handler In interrupt handler - not syncing If you need the stack or call trace, let me know, and I'll add that. I'm running the 2.4.0 kernel from rawhide, and it doesn't seem to have helped a great deal. Will you be upgrading to Linus' 2.4.2 kernel on rawhide? The stack and call trace would be useful, yes, but only after being run through the ksymoops program to decode them into symbolic names. We don't have a position relative to 2.4.2 yet. Alan Cox reports this as a known bug in the 2.4.x stream at this time. Makes ksymoops output even more potentially useful now that I know it hasn't been fixed yet in a more recent kernel... This is kinda embarrassing, but I've never done a ksymoops before. Can you walk me through what I need to do? Recreating the problem isn't an issue, it happens everytime the module is loaded and pump tries to start using it. if your kernel has survived, "dmesg | ksymoops" will do the right thing usually. if your system completely locks up, this gets a lot harder. Looks like this'll be a hard one. The system locks up hard. No capslock, scroll lock no nothing. *** Bug 30406 has been marked as a duplicate of this bug. *** Resolved in later tr drivers in 2.4 |