LWN: Comments on "kerneloops.org records its 100,000th oops"

kerneloops.org records its 100,000th oops

Janne — Tue, 25 Nov 2008 13:49:34 +0000

Instead of tossing it away, how about giving/selling it to someone who could use it?

Debian Etch does not support kerneloops.org collection utility?

arjan — Thu, 20 Nov 2008 03:00:18 +0000

using the client is obviously the easiest way
but kerneloops.org also gets the oopses from LKML or from bugzilla.kernel.org......

Debian Etch does not support kerneloops.org collection utility?

cpeterso — Wed, 19 Nov 2008 19:38:42 +0000

Debian Etch's apt-get repository does not include kerneloops.org's kernel oops collection utility. But Debian Lenny and Sid do: kerneloops packages

Is there another easy way to report kernel oopses if I'm using Etch?

kerneloops.org records its 100,000th oops

jwb — Wed, 19 Nov 2008 17:14:01 +0000

I've heard plenty of stupid proposals in my time, but keeping unworking peripherals in my laptop due to environmental concerns is in the 99th percentile of stupid.

kerneloops.org records its 100,000th oops

Janne — Wed, 19 Nov 2008 12:22:21 +0000

The environment thanks you. We could always use some more e-waste!

kerneloops.org records its 100,000th oops

pabs — Wed, 19 Nov 2008 08:50:27 +0000

I'm considering going the other way, iwl3945 -> atheros, simply because Intel requires non-free binary-blob firmware.

kerneloops.org records its 100,000th oops

harinath — Wed, 19 Nov 2008 07:52:19 +0000

Maybe because the 100,000th report got posted by _not_ tickling the same bug that caused the oops -- it's in a network transmit routine, afterall. (Assuming, of course, that the oops was reported by the same kernel :-)

kerneloops.org records its 100,000th oops

jwb — Tue, 18 Nov 2008 18:29:03 +0000

Well it wasn't stable enough to make it into Ubuntu 8.10, so I tossed the hardware.

kerneloops.org records its 100,000th oops

mb — Tue, 18 Nov 2008 17:58:54 +0000

I want to note that the ssb_tmslow_reject_bitmask WARN_ONs in drivers/ssb/main.c are nothing we can really avoid before they hit users.
Broadcom keeps silently changing the hardware bits and we can only fix this _after_ we got the WARN_ON "bugreports". So let's hope they stopped changing the crap now, so the warning will disappear from the top 10.

kerneloops.org records its 100,000th oops

bkoz — Tue, 18 Nov 2008 17:32:14 +0000

ditto, times two.

kerneloops.org records its 100,000th oops

kirkengaard — Tue, 18 Nov 2008 17:26:42 +0000

Quite right. ath5k and the new ath9k are where the real action is, and they have been done in order that the binary-only HAL might be avoided. In fact, madwifi project is involved in all three, though the serious effort is apparently going into the in-tree drivers. They were just stuck with Atheros' decision about the proprietary HAL because of radio regulations, and the madwifi code was designed to work with the Atheros HAL. They're a good example, I think, of how solutions can be found to proprietary binary sections (as opposed to certain other binary-only "benefactors" of the community).

kerneloops.org records its 100,000th oops

nowster — Tue, 18 Nov 2008 14:29:07 +0000

There wasn't much need to do that. The in-tree ath5k driver is now proving to be stable.

kerneloops.org records its 100,000th oops

biehl — Tue, 18 Nov 2008 08:01:10 +0000

Because it is an Intel-bug?

http://intellinuxwireless.org/?p=iwlwifi

kerneloops.org records its 100,000th oops

xoddam — Tue, 18 Nov 2008 05:38:15 +0000

Could you maybe also explain why Arjan thinks it's ironic that this particular oops marked the move into six digits?

kerneloops.org records its 100,000th oops

jwb — Tue, 18 Nov 2008 04:07:19 +0000

This makes me feel a lot better about having removed the Atheros wifi from my ThinkPad and replacing it with iwl3945. The statistics remind me of the crash stats from the Mozilla project, which are dominated by Adobe Flash, Google Desktop, and various Windows antivirus systems. It's quite difficult to look through Mozilla crash stats to find something =not= caused by proprietary crapware.

kerneloops.org records its 100,000th oops

johill — Tue, 18 Nov 2008 01:43:22 +0000

Incidentally, I think I may just have found the cause for that #100,000. Anyone affected look here: http://marc.info/?l=linux-wireless&m=122696931311854&...

oops logging during module load/unload

arjan — Tue, 18 Nov 2008 00:12:03 +0000

if it's still in dmesg, then the kerneloops client will still pick it up.
The database has quite a few examples of these already.

kerneloops.org records its 100,000th oops

kirkengaard — Mon, 17 Nov 2008 23:20:48 +0000

No, three of the five top *locations* for issues are off-the-tree/binary drivers, and two of those are madwifi. More specifically, two of those are in the binary part of the madwifi atheros driver. That driver seems responsible for three of the top ten oopses, one for initializing the binary-only HAL and one each for the dynamic and static sysctl registration methods, which together account for 10,259 separate reports. Which is what you get when legal issues bind coding issues and you're stuck navigating around a blob with the software you can see.

kerneloops.org records its 100,000th oops

zdzichu — Mon, 17 Nov 2008 21:51:04 +0000

So 3 of 5 top issues are caused by off-the-tree/binary drivers?

oops logging during module load/unload

abatters — Mon, 17 Nov 2008 21:39:35 +0000

I just noticed today that oopses that happen during insmod/rmmod/modprobe are printed to the console but not logged by syslogd/klogd. I wonder how many oopses have been missed because of this.