The Best Features Of Linux 3.16

[gilboa]

And the best feature of all: suspend to RAM regressions. In every new kernel version.

Care to share bugzilla bug reports, or are you simply trolling?

For me, the last kernel that worked ok was 3.11. After that, when the sustem tries to wake up, sometimes (very sporadic, no discernible pattern) it doesn't succeed (iirc 3.12 had hard hangs, 3.13 had a hung gpu/X, and 3.14 still has some gpu problems, no 3.15 in Debian unstable, seems like 3.16 is next). Problem with reporting it is that it takes a while for the problem to appear, so until I get the problem again there's usually a new kernel out to try which seems to work at first...

This is all nice and dandy, but unless you report it and supply the developers with the information they require, how do you expect them to fix your issue?
Heck, how do you expect them to be aware of this issue?

Could be an USB serial port used for debuging?

As far as I know, no.
You can setup netconsole over an Ethernet NIC to get access to the kernel logs.

[dragonn]

Care to share bugzilla bug reports, or are you simply trolling?




This is all nice and dandy, but unless you report it and supply the developers with the information they require, how do you expect them to fix your issue?
Heck, how do you expect them to be aware of this issue?




As far as I know, no.
You can setup netconsole over an Ethernet NIC to get access to the kernel logs.

Why no? If you build in usb support and the usb driver for serial console for example you could use cheap FT232R USB UART, when the system boots just add a parameter to the kernel cmdline console=/dev/ttyUSB0,115200 I think this should work.

[Zan Lynx]

Why no? If you build in usb support and the usb driver for serial console for example you could use cheap FT232R USB UART, when the system boots just add a parameter to the kernel cmdline console=/dev/ttyUSB0,115200 I think this should work.

USB is too complicated to rely on in a debugging situation.

Plus, my laptops at least seem to run into weird problems in the firmware. Linux doesn't set it up right or something, and on resume it either never gets even to the kernel, or it has moved hardware addresses to strange unexpected places and Linux falls over trying to write to a device that isn't there anymore.

I guess in my last post I was thinking more of these firmware problems.

[gilboa]

Why no? If you build in usb support and the usb driver for serial console for example you could use cheap FT232R USB UART, when the system boots just add a parameter to the kernel cmdline console=/dev/ttyUSB0,115200 I think this should work.

I never managed to get USB serial to reliably handle OOPs messages, especially under load.
Seems that the USB stack is far too complicated to get OOPs messages out of a crashing kernel.