Laying To Rest That Odd Linux Kernel Regression

[phoronix]

Phoronix: Laying To Rest That Odd Linux Kernel Regression

Former Red Hat employee Dave Jones has provided some closure to that Linux 3.18 kernel bug that was initially viewed as a "worrisome regression" and turned out to be very difficult to track with no official fix within the mainline Linux kernel...

http://www.phoronix.com/vr.php?view=MTg4MzY

[rastaman]

How can one help ?

17 years applying latest kernel and this is the first time i'm stuck. I've been hit by this nasty lockup bug since 3.18.0. reproduced on 3.18.1 and 3.19-rc3. Not on any previous release. Machine freeze while using it 'normaly'. Uptime is never more than 3 hours, have to hard reset it. Tried various kernel settings (deactivating kernel preemption for instance) to no avail.
If Dave can't reproduce, my laptop (Lenovo T61) is a perfect Lab !
Let me know
Stephane (Paris)

[agd5f]

17 years applying latest kernel and this is the first time i'm stuck. I've been hit by this nasty lockup bug since 3.18.0. reproduced on 3.18.1 and 3.19-rc3. Not on any previous release. Machine freeze while using it 'normaly'. Uptime is never more than 3 hours, have to hard reset it. Tried various kernel settings (deactivating kernel preemption for instance) to no avail.
If Dave can't reproduce, my laptop (Lenovo T61) is a perfect Lab !
Let me know
Stephane (Paris)

git bisect and find out what commit caused it.

[rastersoft]

Maybe 3.16 is also afected

I'm using Ubuntu 14.10 and have that kind of bug: sometimes the system just hangs. With 14.04 it works like a charm.

[dungeon]

It is only hard to bisect, if you can't reproduce it

[carewolf]

It is only hard to bisect, if you can't reproduce it

Or you reproduce it everywhere or randomly because your hardware is getting wierd.

Edit: Actually even without hardware errors. Be wary of random issues when bisecting, you waste a lot of time bisecting if you don't check for consistency.

[Nobu]

probably unrelated, but my graphics lock up when ever I try to mine scrypt (litecoin), no matter what I try (reduce intensity, thread-concurrency...), on my APU's iGPU using OpenCL--mining bitcoins/'bfgminer --benchmark' is fine. Sometimes I'm able to recover by switching to a tty and pkilling the mining process, but it's not guaranteed. My system is overclocked pretty good, but afaik it's stable, and iirc it was doing this even before I started overclocking. scrypt mining is fine if I do it on a dGPU like my HD7770, but only if my iGPU is the primary graphics device, (again) iirc. System is rock-solid outside of scrypt mining. Kernel: 3.18.1-1-ARCH, x86_64, with mesa-git and the testing repo's enabled.

[steveriley]

Speaking of crashes and freezes, I can reliably freeze my ThinkPad T520 using a USB headset with any VoIP software (no crashes if using a headset plugged into the 1/4" jack). There is no consistent time when this happens -- could be mere seconds after the call begins to more than 20 minutes. Doesn't matter if I exercise the system or leave it completely alone. And when it freezes, it's frozen hard. Not even REISUB will recover. I'm on Kubuntu 14.10 now, with Ubuntu's mainline kernel 3.18.1. But this has been a persistent problem since 12.04 and whatever kernel it uses. And on occasion, I've had similar freezes when using USB to transfer files between the laptop and my Nexus 4. Something in the USB subsystem is wonky, and I have no clue where to even begin looking. The syslog contains nothing helpful.

[darkfires]

I've seen lots of weird kernel crashes lately since 3.12, very random... lockups and freezes on various different hardware. Linux kernel quality (more specifically, reliability) is really going down hill if you ask me. Won't even go into how Linux desktop has been going down hill since 2005...

Two machines at work both 3.12.35 were randomly crashing, the crash dumps appeared to be network related.. Swapped the hardware and also upgraded the kernel to 3.14, same issues though the crash traces were a little different. Memtest was clean on both machines.

I ended up "working around" the issue (by mistake), snmpd was logging every tcpwrapper connect to it via syslog (this by itself isn't really an issue but pointless filling of logs), and disabling that seemed to stop the kernel crashes... makes no sense to me. I did not try downgrading the kernel tho, maybe I should have..

Another system , brand new Z97 setup randomly locks up after a few days, not even a freaking message or anything.... memtest clean on this as well..... sigh.

In other news, my Windows 10 machine has a 4week uptime; works great...

I miss the days when nothing crashed Linux and it was windows puking it's guts out... funny how times change.

[GreatEmerald]

Called it! It was a hardware issue all along.

The only freezing I've ever had was due to nouveau. Also, there's nigh-infinite reasons for one to have a freeze; almost all of them do not relate to the issue discussed in the article.