Red Hat Bugzilla – Bug 577463
b44 module fails to load with 184.108.40.206-19.fc13.i686.PAE, doesn't boot
Last modified: 2010-04-08 07:06:26 EDT
Description of problem:
While booting system with 220.127.116.11-19.fc13.i686.PAE kernel and b44 ethernet card (HP Compaq nx7400 (EY505ES#AKB) laptop), the system produces stacktrace of b44 module, modprobe fails and it hangs after "setting hostname" message, thus failing to boot. I could boot it only after removing b44 module.
Version-Release number of selected component (if applicable):
BUG: unable to handle kernel NULL pointer dereference at 00000010
IP: [<f9116b23>] ssb_is_sprom_available+0xe/0x7c [ssb]
*pdpt = 0000000032274001 *pde = 0000000000000000
Oops: 0000 [#1] SMP
last sysfs file: /sys/module/rfkill/initstate
Modules linked in: b44(+) ppdev ssb snd_timer parport_pc iTCO_wdt snd hp_wmi microcode par
port serio_raw mii soundcore iTCO_vendor_support joydev btusb mmc_core bluetooth snd_page_
alloc wmi rfkill dm_multipath firewire_ohci yenta_socket rsrc_nonstatic firewire_core crc_
itu_t i915 drm_kms_helper drm i2c_algo_bit i2c_core video output [last unloaded: scsi_wait
Pid: 635, comm: modprobe Not tainted 18.104.22.168-19.fc13.i686.PAE #1 30A2/HP Compaq nx7400 (EY505ES#AKB)
EIP: 0060:[<f9116b23>] EFLAGS: 00010296 CPU: 0
EIP is at ssb_is_sprom_available+0xe/0x7c [ssb]
EAX: f23694f0 EBX: f23694f0 ECX: 00000000 EDX: 00000000
ESI: ffffffed EDI: f2301e4c EBP: f2301da4 ESP: f2301da4
DS: 007b ES: 007b FS: 00d8 GS: 00e0 SS: 0068
Process modprobe (pid: 635, ti=f2300000 task=f21ad680 task.ti=f2300000)
f2301dc4 f91173b5 00000000 f23694f0 f2301dcc f23694f0 f9117397 f2301e4c
<0> f2301e58 f9115bf3 00000000 00000000 00000000 00000000 00000000 00000000
<0> 00000000 00000000 00000000 00000000 00000000 00000000 00000000 00000000
[<f91173b5>] ? ssb_pci_get_invariants+0x1e/0x4fb [ssb]
[<f9117397>] ? ssb_pci_get_invariants+0x0/0x4fb [ssb]
[<f9115bf3>] ? ssb_fetch_invariants+0x27/0x68 [ssb]
[<f9116390>] ? ssb_bus_register+0xd0/0x161 [ssb]
[<f9117397>] ? ssb_pci_get_invariants+0x0/0x4fb [ssb]
[<f9116519>] ? ssb_bus_pcibus_register+0x29/0x48 [ssb]
[<f9117f25>] ? ssb_pcihost_probe+0xa2/0xd5 [ssb]
[<c05dd264>] ? local_pci_probe+0x13/0x15
[<c05ddcee>] ? pci_device_probe+0x48/0x6b
[<c06741a3>] ? driver_probe_device+0xca/0x1d2
[<c06742f3>] ? __driver_attach+0x48/0x64
[<c067378a>] ? bus_for_each_dev+0x42/0x6c
[<c0673f91>] ? driver_attach+0x19/0x1b
[<c06742ab>] ? __driver_attach+0x0/0x64
[<c0673a19>] ? bus_add_driver+0x101/0x24a
[<c067455e>] ? driver_register+0x81/0xe8
[<c05cfbb6>] ? __raw_spin_lock_init+0x28/0x4e
[<c05dded1>] ? __pci_register_driver+0x51/0xae
[<c045d436>] ? up_read+0x1b/0x31
[<f918b000>] ? b44_init+0x0/0x58 [b44]
[<f9117dbb>] ? ssb_pcihost_register+0x33/0x35 [ssb]
[<f918b02e>] ? b44_init+0x2e/0x58 [b44]
[<c040306c>] ? do_one_initcall+0x62/0x170
[<c04753e1>] ? sys_init_module+0xae/0x1e9
[<c0408bdf>] ? sysenter_do_call+0x12/0x38
Code: ff ff 75 08 89 15 fc ca 11 f9 31 c0 5d c3 55 89 e5 0f 1f 44 00 00 a1 fc ca 11 f9 5d c3 55 89 e5 0f 1f 44 00 00 8b 90 a0 02 00 00 <8a> 4a 10 80 f9 0a 76 62 8b 90 90 00 00 00 66 81 fa 22 43 74 1f
EIP: [<f9116b23>] ssb_is_sprom_available+0xe/0x7c [ssb] SS:ESP 0068:f2301da4
---[ end trace 77dedb5755bdea58 ]---
I have this problem on Acer TravelMate 660 with Fedora 12 i686.
With kernels 22.214.171.124-90 and 126.96.36.199-92.
Kernel 188.8.131.52-83 boots O.K.
*** Bug 577311 has been marked as a duplicate of this bug. ***
bool ssb_is_sprom_available(struct ssb_bus *bus)
/* status register only exists on chipcomon rev >= 11 */
if (bus->chipco.dev->id.revision < 11)
bus->chipco.dev is NULL
Crud...let me review the calling sequence...
Created attachment 403536 [details]
Can you confirm that this fixes the problem?
Everything looks OK with the patch. b44 loaded, ethernet presumably works (can't try right now), boots as expected.
Excellent...thanks for the report (and sorry for the problem)!
Confirmed fixed here as well..
Can you please push kernel-184.108.40.206-94.fc12 (http://koji.fedoraproject.org/koji/buildinfo?buildID=164636) for Fedora 12 as well ASAP? It fixes a very similar problem for me (bug 578217).
Confirming this bug for kernel 220.127.116.11-90 and 18.104.22.168-92 on a Dell Inspiron 8600.
Kernel will not boot.
Confirming that kernel-22.214.171.124-94.fc12 from Koji fixes the issue. Hoping to see it soon on updates-testing.
The following bugs seem to be duplicates but haven't been marked as such yet:
I confirm that I have the same boot problem for Fedora 13 Rawhide and that the new kernel fixes it.
I'm setting this to block the Beta. F13 kernels since -24 fix this issue, but Beta RC4 has -19 :(
Fedora Bugzappers volunteer triage team
we're fairly sure about this, but can someone with an affected system please try booting some F13 Beta RC4 image - http://serverbeach1.fedoraproject.org/pub/alt/stage/13-Beta.RC4/ , any of them should be okay for testing, the netinst ISO would be the smallest to download - and confirm that it fails? Just to make sure we're not on a false trail here.
For the record, I checked with John Linville, and he confirms that the first fix for the initial issue (which is https://bugzilla.redhat.com/show_bug.cgi?id=533746 ) went into kernel -19 for F13, and kernel -90 for F12. That fix caused this regression for most (or possibly all) systems with Broadcom wired ethernet adapters supported by the b44 driver (there are many many such systems). We had multiple reports from F12 testers that F12 kernel -90 fails to boot; we've no reason to assume that F13 kernel -19 would behave any different. A fix for the regressions was added to F12 kernel -94 and F13 kernel -24, which multiple testers confirm resolves the regressions. That's why we should take that kernel (at least) into Beta.
(In reply to comment #14)
> we've no reason to assume that F13 kernel -19 would behave any different
This kernel is busted on Dell Inspiron 6400 (which has b44), just like -90 and -92. No boot.
Whatever you do, don't take -19 to beta.
Confirming that F13 Beta RC4 fails to boot on a Dell Inspiron 8600 with the same error.
FYI All nightly composes since 20100324 to present day contain the kernel with offending patch ( kernel-126.96.36.199-19.fc13 ). So we have been composing images with this broken patch for a long time. Just compose image with kernel 33.1-24 or newer where this has been fixed or rename a compose that pre-dates the previous mentioned date to Beta RC4.
Just for the record, anything older than -19 will crash on some number of b43-equipped devices, particularly newer netbooks. So my money would be on moving forward to -24...
Is there anything standing in the way of going all the way to 2-35?
We might as well expose the latest build to reporters since it serves no purpose exposing a kernel to the reporter that gets replaced as soon as he runs update which he does right after install..
No objection either way from me, but -24 is somewhat closer to what has been getting tested so far.
Johann: it does serve a purpose. If you have kernel -24 and then get -35 as an update, and -35 doesn't work, you can still boot -24. If we ship the beta with -35 and it turns out to be bad, there's no such option.
We're following the principle of taking the smallest possible change that includes the fix we need.
Thanks for the info, reporters. We spun Beta RC5 with kernel -24. If no problems emerge in that build, it will likely be shipped as Beta. You can test that to make sure it boots, if you like...thanks.
kernel-188.8.131.52-24.fc13 has been submitted as an update for Fedora 13.
kernel-184.108.40.206-24.fc13 has been pushed to the Fedora 13 stable repository. If problems still persist, please make note of it in this bug report.
This issue is also in kernel-PAE-220.127.116.11-90.fc12.i686 which is in F12 updates and kernel-PAE-18.104.22.168-92.fc12.i686 which is in F12 updates-testing.
Please push 22.214.171.124-94 or later to F12.
(In reply to comment #24)
> Please push 126.96.36.199-94 or later to F12.
You can vote here:
(In reply to comment #25)
> You can vote here:
Thanks, sorry - now 3 days after the build it wasn't in updates-testing, so I assumed it wasn't pushed to bodhi.