Bug 169757 - kernel-2.6.13-1.1526_FC4 crashes at "Initializing hardware..."
kernel-2.6.13-1.1526_FC4 crashes at "Initializing hardware..."
Status: CLOSED DUPLICATE of bug 169674
Product: Fedora
Classification: Fedora
Component: kernel (Show other bugs)
4
i386 Linux
medium Severity high
: ---
: ---
Assigned To: Kernel Maintainer List
Brian Brock
:
Depends On:
Blocks:
  Show dependency treegraph
 
Reported: 2005-10-03 04:16 EDT by Mary Ellen Foster
Modified: 2007-11-30 17:11 EST (History)
1 user (show)

See Also:
Fixed In Version:
Doc Type: Bug Fix
Doc Text:
Story Points: ---
Clone Of:
Environment:
Last Closed: 2005-10-03 12:27:12 EDT
Type: ---
Regression: ---
Mount Type: ---
Documentation: ---
CRM:
Verified Versions:
Category: ---
oVirt Team: ---
RHEL 7.3 requirements from Atomic Host:


Attachments (Terms of Use)

  None (edit)
Description Mary Ellen Foster 2005-10-03 04:16:50 EDT
From Bugzilla Helper:
User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.8b4) Gecko/20050908 Firefox/1.4

Description of problem:
[ I'm posting this on behalf of someone else without Bugzilla access; he's CC'd on the bug and will see any comments ]

The new kernel from update-released crashes on boot on an Acer Travelmate 8103WLMi. Here is the trace (retyped by hand):

------ begin ------
...
Red Hat nash version 4.2.15 starting
...
Starting udev:
Initializing hardware...  storage network audioUnable to handle kernel NULL
pointer dereference at virtual address 0000004f printing eip:
*pde = 1e570067
Oops: 0000 [#1]
Modules linked in: yenta_socket rsrc_nonstatic pcmcia_core uhci_hcd
ehci_hcd i2c_i801 i2c_core snd_hda_intel snd_hda_codec snd_seq_dummy
snd_seq_oss snd_seq_midi_event snd_seq snd_seq_device snd_pcm_oss
snd_mixer_oss snd_pcm snd_timer snd soundcore snd_page_alloc ipw2200
ieee80211 ieee80211_crypt tg3 joydev ext3 jbd ata_piix libata sd_mod
scsi_mod
CPU:    0
EIP:    0060:[<e0b68451>]    Not tainted VLI
EFLAGS: 00010282   (2.6.13-1526_FC4)
EIP is at yenta_config_init+0x9d/0x110 [yenta_socket]
eax: dfdef7c0   ebx: dfddb400   ecx: 00000049   edx: 00000049
esi: 00000000   edi: df533000   ebp: dfddb400   esp: df5dded0
ds: 007b   es: 007b   ss: 0068
Process modprobe (pid: 1181, threadinfo=df5dd000 task=dfb30aa0)
Stack: 000000a8 c0128eab fffffff4 df533000 df533320 e0b685cd e0b68d98 dfddb538
       00001025 00000070 e0b6b8d8 dfddb400 e0b6b940 dfddb444 c0464f20 c0268616
       e0b6b940 dfddb400 c0268640 dfddb444 e0b6b96c c02e83ad 00000246 e0b6b998
Call Trace:
[<c0128eab>] printk+0x1b/0x1f
[<e0b685cd>] yenta_probe+0x109/0x23f [yenta_socket]
[<c0268616>] __pci_device_probe+0x30/0x3c
[<c0268640>] pci_device_probe+0x1e/0x35
[<c02e83ad>] driver_probe_device+0x35/0x9e
[<c02e84d2>] __driver_attach+0x4a/0x4c
[<c02e7c66>] bus_for_each_dev+0x3c/0x5a
[<c02e84ea>] driver_attach+0x16/0x1a
[<c02e8488>] __driver_attach+0x0/0x4c
[<c02e802f>] bus_add_driver+0x66/0xaf
[<c0268824>] pci_register_driver+0x97/0xb7
[<c015c407>] sys_init_module+0xd4/0x1d8
[<c0104465>] syscall_call+0x7/0xb
Code: 00 00 e8 11 a8 6f df 8b 50 20 8b 40 10 c7 04 24 a8 00 00 00 b9 0d 00 00 00 e8 f8 a7 6f
 df 8b 73 14 8b 07 8b 50 20 8b 40 10 <0f> b6 5e 4f c1 e3 10 0f b6 4e 4e c1 e1 08 09 cb 0f b6
 4e 4d 09
 /etc/rc.d/rc.sysinit: line 165:  1181 Segmentation fault      modprobe $1 > /dev/null 2>&1
<6>Bluetooth: Core ver 2.7
NET: Registered protocol family 31
Bluetooth: HCI device and connection manager initialized
Bluetooth: HCI socket layer initialized
Bluetooth: HCI USB driver ver 2.8
usbcore: registered new driver hci_usb
ieee1394: Initialized config rom entry `ip1394'
ohci1394: $Rev: 1299 $ Ben Collins <bcollins@debian.org>
ohci1394: fw-host0: OHCI-1394 1.1 (PCI): IRQ=[11]  MMIO=[c8215000-c82157ff]  Max Packet=[2048]
ieee1394: Host added: ID:BUS[0-00:1023]  GUID[00c09f0000536052]
------ end ------


A bit of searching indicated that this might be related to the issues described in this mailing-list post:
http://seclists.org/lists/linux-kernel/2005/Sep/0701.html

When the kernel is rebuilt without "32-bit Cardbus support", it boots successfully, although a number of devices (including the Centrino wireless card) are not available. Here are the messages from booting the rebuilt kernel:

------ begin ------
Uncompressing Linux... Ok, booting the kernel.
PCI: Cannot allocate resource region 7 of bridge 0000:00:1c.0
PCI: Cannot allocate resource region 8 of bridge 0000:00:1c.0
PCI: Cannot allocate resource region 9 of bridge 0000:00:1c.0
PCI: Cannot allocate resource region 7 of bridge 0000:00:1c.1
PCI: Cannot allocate resource region 8 of bridge 0000:00:1c.1
PCI: Cannot allocate resource region 9 of bridge 0000:00:1c.1
PCI: Cannot allocate resource region 7 of bridge 0000:00:1c.2
PCI: Cannot allocate resource region 8 of bridge 0000:00:1c.2
PCI: Cannot allocate resource region 9 of bridge 0000:00:1c.2
PCI: Device 0000:00:1c.0 not available because of resource collisions
PCI: Device 0000:00:1c.1 not available because of resource collisions
PCI: Device 0000:00:1c.2 not available because of resource collisions
PCI: Device 0000:00:1c.0 not available because of resource collisions
PCI: Device 0000:00:1c.1 not available because of resource collisions
PCI: Device 0000:00:1c.2 not available because of resource collisions
Red Hat nash version 4.2.15 starting
...
------ end ------

Version-Release number of selected component (if applicable):
kernel-2.6.13-1.1526_FC4

How reproducible:
Always

Steps to Reproduce:
1. Boot new kernel

Actual Results:  Crashes (see above)

Expected Results:  Not crashing

Additional info:
Comment 1 Mary Ellen Foster 2005-10-03 04:20:06 EDT
Okay, so it turns out you can't add people without bugzilla accounts to the CC
lists ... but I'll pass along any comments or suggestions to the person whose
computer this is.
Comment 2 Mary Ellen Foster 2005-10-03 04:27:47 EDT
p.s. -- This is possibly related to
https://bugzilla.redhat.com/bugzilla/show_bug.cgi?id=169674

We'll try with yenta_socket in the hotplug blacklist and see if that allows it
to boot.
Comment 3 Mary Ellen Foster 2005-10-03 12:27:12 EDT
Report: We tried booting with yenta_socket in /etc/hotplug/blacklist, and the
original kernel boots without error. Looks like this is indeed the same issue as
bug 169674, so I'll close it as a duplicate.

*** This bug has been marked as a duplicate of 169674 ***

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