Bug 77861
Summary: | Kernel lockup in qlogicfc0 driver | ||||||
---|---|---|---|---|---|---|---|
Product: | [Retired] Red Hat Linux | Reporter: | Hrunting Johnson <hrunting> | ||||
Component: | kernel | Assignee: | Dave Jones <davej> | ||||
Status: | CLOSED ERRATA | QA Contact: | Brian Brock <bbrock> | ||||
Severity: | high | Docs Contact: | |||||
Priority: | medium | ||||||
Version: | 7.2 | CC: | pfrields, sct | ||||
Target Milestone: | --- | ||||||
Target Release: | --- | ||||||
Hardware: | i686 | ||||||
OS: | Linux | ||||||
Whiteboard: | |||||||
Fixed In Version: | Doc Type: | Bug Fix | |||||
Doc Text: | Story Points: | --- | |||||
Clone Of: | Environment: | ||||||
Last Closed: | 2003-12-17 13:26:22 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: | |||||||
Bug Depends On: | |||||||
Bug Blocks: | 77803 | ||||||
Attachments: |
|
Description
Hrunting Johnson
2002-11-14 15:10:28 UTC
please use the qla2200 driver instead; that one is actually supported Will do. Under 2.4.9-31, I was using the qla2x00 without incident, but that disappeared in the new release. The qla2200 driver under that kernel never worked for us, so I didn't bother to try it again. Okay, switching to the supported qla2200 driver appears to fix the problems with the machine lockup (and another bug, 77803, which I have no idea why or how), but the kjournald thread for the ext3 partition that is on the RAID accessed through that card is taking up around 11% of the total CPU on the box, whereas before it took up around 2%. Why the increase? Is that qla2200 driver that poor? Under 2.4.9-31 and the qla2x00 driver, we didn't have that much journal activity, but we were also running under a different VM. Under the qlogicfc0 driver and the new VM, we had basically the same system usage as the qla2x00 driver. The 77803 bug is likely due to dropped interrupts if a driver change fixes it. As for the kjournald overhead, that could be a number of things, including bounce buffer overhead. We'd need to see a kernel profile to have any hope of diagnosing it. (Boot with the kernel parameters "profile=2"; man readprofile to see how to extract info.) At the risk of being taken for an idiot, when I enable profiling (with profile=2), no matter what, I always get: # readprofile -m /boot/System.map-2.4.18-18.7.xbigmem 4 _stext 0.0500 4 total 0.0000 No matter what. Do I need to do something else to enable accurate profiling on this machine? The system is under heavy load. The /proc/profile file is constantly being updated (according to its timestamp), but it's always the same size, and it always contains that same data (in -v, everything is set to 0). This is with 2.4.18-18.7.xbigmem. you need to ALSO specify nmi_watchdog=1 in addition to profile= Created attachment 86072 [details]
output from readprofile -v
Fixed in the 2.4.20-20 erratas ? Yes. |