Bug 161255 - sysfs_hash_and_remove() panic.
sysfs_hash_and_remove() panic.
Status: CLOSED ERRATA
Product: Fedora
Classification: Fedora
Component: kernel (Show other bugs)
4
x86_64 Linux
medium Severity high
: ---
: ---
Assigned To: Dave Jones
Brian Brock
:
Depends On:
Blocks:
  Show dependency treegraph
 
Reported: 2005-06-21 15:43 EDT by Robert de Rooy
Modified: 2015-01-04 17:20 EST (History)
3 users (show)

See Also:
Fixed In Version:
Doc Type: Bug Fix
Doc Text:
Story Points: ---
Clone Of:
Environment:
Last Closed: 2005-07-29 18:43:24 EDT
Type: ---
Regression: ---
Mount Type: ---
Documentation: ---
CRM:
Verified Versions:
Category: ---
oVirt Team: ---
RHEL 7.3 requirements from Atomic Host:
Cloudforms Team: ---


Attachments (Terms of Use)
panic using x86_64 version of FC4 (10.78 KB, text/plain)
2005-06-21 15:43 EDT, Robert de Rooy
no flags Details
panic using i386 version of FC4 (8.81 KB, text/plain)
2005-06-21 15:44 EDT, Robert de Rooy
no flags Details

  None (edit)
Description Robert de Rooy 2005-06-21 15:43:04 EDT
Description of problem:

PXE network install of FC4 x86_64 *or* FC4 i386 on IBM BladeCenter HS20 (8843)
blade results in a kernel panic

Version-Release number of selected component (if applicable):

kernel 2.6.11-1.1369_FC4

How reproducible:

always

Steps to Reproduce:
1. setup a PXE install server
2. boot FC4 (x86_64 or i386) on an HS20 8843 blade
3. panic!
  
Actual results:

panic

Expected results:

no panic

Additional info:

This is the IBM HS20 blade with the Intel Nocona (EM64T) processors.
KVM or MT (MediaTray) ownership is irrelevant, I tried it with both cases and
got the same panic.
Comment 1 Robert de Rooy 2005-06-21 15:43:04 EDT
Created attachment 115777 [details]
panic using x86_64 version of FC4
Comment 2 Robert de Rooy 2005-06-21 15:44:26 EDT
Created attachment 115778 [details]
panic using i386 version of FC4
Comment 3 Robert de Rooy 2005-06-22 16:07:55 EDT
after some more investigation:

passing acpi=noirq gives the same panic, but passing acpi=off allows the install
to succeed, but when the system reboots and loads the SMP kernel it ends up with
a kernel panic again.

But booting the UNI kernel after install works.
Both the SMP and UNI kernel have acpi=off

The same applies to both the i386 and x86_64 version of FC4
Comment 4 Joseph Teichman 2005-06-22 20:45:45 EDT
Check if this relates to the bug that I had here with a deficient initial root
disk image , Bug # 161406
Comment 5 Robert de Rooy 2005-06-22 22:15:25 EDT
there is no relation between this bug and the one mentioned by Joseph
Comment 6 Dave Jones 2005-07-15 17:05:46 EDT
[This comment has been added as a mass update for all FC4 kernel bugs.
 If you have migrated this bug from an FC3 bug today, ignore this comment.]

Please retest your problem with todays 2.6.12-1.1398_FC4 update.

If your problem involved being unable to boot, or some hardware not being
detected correctly, please make sure your /etc/modprobe.conf is correct *BEFORE*
installing any kernel updates.
If in doubt, you can recreate this file using..

mv /etc/sysconfig/hwconf /etc/sysconfig/hwconf.bak
mv /etc/modprobe.conf /etc/modprobe.conf.bak
kudzu


Thank you.
Comment 7 Robert de Rooy 2005-07-28 22:47:55 EDT
I installed 2.6.12-1.1398_FC4 x86_64 SMP kernel, and removed acpi=off from
grub.conf and rebooted.

I got one strange error on boot:

PCI: Cannot allocate resource region 1 of device 0000:00:00.0

Other then that the system booted fine, so the original issue appears to be
resolved.

[root@blade006 ~]# lspci -s 00:00.0 -vv -x
00:00.0 Host bridge: Intel Corporation E7520 Memory Controller Hub (rev 0c)
        Subsystem: IBM: Unknown device 02dd
        Control: I/O- Mem+ BusMaster+ SpecCycle- MemWINV- VGASnoop- ParErr+
Stepping- SERR+ FastB2B-
        Status: Cap+ 66Mhz- UDF- FastB2B+ ParErr- DEVSEL=fast >TAbort- <TAbort-
<MAbort- >SERR- <PERR-
        Latency: 0
        Region 1: Memory at <ignored> (32-bit, non-prefetchable)
        Capabilities: [40] Vendor Specific Information
00: 86 80 90 35 46 01 90 00 0c 00 00 06 00 00 80 00
10: 00 00 00 00 00 00 00 ff 00 00 00 00 00 00 00 00
20: 00 00 00 00 00 00 00 00 00 00 00 00 14 10 dd 02
30: 00 00 00 00 40 00 00 00 00 00 00 00 00 00 00 00
40: 09 00 05 41

Note You need to log in before you can comment on or make changes to this bug.