Note: This is a beta release of Red Hat Bugzilla 5.0. The data contained within is a snapshot of the live data so any changes you make will not be reflected in the production Bugzilla. Also email is disabled so feel free to test any aspect of the site that you want. File any problems you find or give feedback here.
Bug 161255 - sysfs_hash_and_remove() panic.
Summary: sysfs_hash_and_remove() panic.
Alias: None
Product: Fedora
Classification: Fedora
Component: kernel
Version: 4
Hardware: x86_64
OS: Linux
Target Milestone: ---
Assignee: Dave Jones
QA Contact: Brian Brock
Depends On:
TreeView+ depends on / blocked
Reported: 2005-06-21 19:43 UTC by Robert de Rooy
Modified: 2015-01-04 22:20 UTC (History)
3 users (show)

Fixed In Version:
Doc Type: Bug Fix
Doc Text:
Clone Of:
Last Closed: 2005-07-29 22:43:24 UTC

Attachments (Terms of Use)
panic using x86_64 version of FC4 (deleted)
2005-06-21 19:43 UTC, Robert de Rooy
no flags Details
panic using i386 version of FC4 (deleted)
2005-06-21 19:44 UTC, Robert de Rooy
no flags Details

Description Robert de Rooy 2005-06-21 19:43:04 UTC
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:


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:


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 19:43:04 UTC
Created attachment 115777 [details]
panic using x86_64 version of FC4

Comment 2 Robert de Rooy 2005-06-21 19:44:26 UTC
Created attachment 115778 [details]
panic using i386 version of FC4

Comment 3 Robert de Rooy 2005-06-22 20:07:55 UTC
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-23 00:45:45 UTC
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-23 02:15:25 UTC
there is no relation between this bug and the one mentioned by Joseph

Comment 6 Dave Jones 2005-07-15 21:05:46 UTC
[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

Thank you.

Comment 7 Robert de Rooy 2005-07-29 02:47:55 UTC
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

[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.