Michael: Apologies if it looks like I just 'guessed' at the cause, but I assure you I did the basic 'diff' checks I do for all kernel issues. The git-log seemed pretty clear - the only change was the 'b43' patch and when I saw it was a bluetooth/WiFi interaction patch I didn't think I needed to dig much further. At the time it happened, knowing I was being a guinea-pig for hardy-proposed, I was more interested in simply reporting the experience to prevent it getting promoted to hardy-updates if there was a problem.
I'm in the Kernel ACPI Team and I've spent most of my time recently building a semi-automated testing system (using DKMS instead of SystemTap) for easier (remote) investigation of this kind of issue (ACPI is plagued by them) and experience there is look to the basics (all recent changes are prime suspects unless proved otherwise!). Yes, b43 apparently not even being used is perplexing me. I was fully aware the module wasn't in use but unless the ABI bump is somehow causing an issue with something in user-space I couldn't see how it could be anything other than some weird side effect. I've now scheduled some time to do a git-bisect, just to try without the ABI bumps since they are now suspect. The PC checks out in every other way (memory passes tests, no other kernel module differences or configuration between the two kernels, (I checked the initrd image just in case), etc.). Testing is slightly hampered by the fact the OOPS is relatively rare, and random, and when it happens the only solution is a reboot. SysReq+S will sometimes sync the disks so the log should be saved, fortunately. I've had the PC running with v2.6.24-20-generic for a while now and no sign of the OOPS or any other instability. The only thing I've done relating in any way to the on-board radios was (about 1 week before the hardy-proposed v2.6.24-21-generic update) install Alexander Sack's NetworkManager v0.7 PPA builds to test the 3G and OpenVPN connections functionality. There is/was no problem with that with kernel 2.6.24-20-generic. The common thing in all the OOPS back-traces is the Bluetooth module trying to add or del[ete] a connection (for the mouse). It seems to be trying to double-add or double-free too, which would explain the "sysfs: duplicate filename" or "NULL pointer deference" if it was destroyed on the first, for the second attempts. This functionality was introduced with commit 47b66fe95afa8400cefaea06263ab8948d8465ba Author: Dave Young <[EMAIL PROTECTED]> Date: Fri Feb 15 01:34:03 2008 -0800 BLUETOOTH: Add conn add/del workqueues to avoid connection fail. $ git-describe --contains 47b66fe v2.6.24.3~17 I'm dropping some debug code in a build of v2.6.24-21 for the calls in hci_conn_add_conn() and hci_conn_del_conn() in net/bluetooth/hci_sysfs.c, and drivers/base/core.c device_add() and device_del(). These functions schedule and execute the workqueue activity that is seen in the back-traces. I'm also going to monitor the user-space hal responses to the uvents. ** Changed in: linux (Ubuntu) Assignee: (unassigned) => TJ (intuitivenipple) -- OOPS: "Unable to handle kernel NULL pointer dereference" https://bugs.launchpad.net/bugs/258450 You received this bug notification because you are a member of Ubuntu Bugs, which is subscribed to Ubuntu. -- ubuntu-bugs mailing list ubuntu-bugs@lists.ubuntu.com https://lists.ubuntu.com/mailman/listinfo/ubuntu-bugs