Page 2 of 2 FirstFirst 12
Results 11 to 15 of 15

Thread: The Best Features Of Linux 3.16

  1. #11
    Join Date
    Jul 2013
    Posts
    49

    Default

    Quote Originally Posted by Zan Lynx View Post
    I almost always have those weird regressions with suspend too. In fact, it happens with Windows too. Windows 7 could suspend my desktop to RAM but Windows 8.1 randomly fails to wake up the disks.

    With Linux on laptops getting suspend regressions fixed is horrible. The way to debug it used to be a serial port. What laptop has a serial port anymore?

    You're almost completely limited to using custom kernel builds and git bisect. Which only works if the problem can be reliably reproduced. If the problem is unpredictable, well, good luck!

    It isn't like the problem is easier to debug for developers either. The only people that can really do it are the laptop builders. You need a bare laptop motherboard with probes hooked up so you can read the ISA debug output ports. That, or special debugging hardware cards. And if the laptop is an Ultrabook type with no expansion slot you'd need an open case with a custom added slot to install one.
    Could be an USB serial port used for debuging? I am sure this could work. Second, what about kdump, newer used it but I know it is useful for debugging when you don't have access to the kernel log directly .

  2. #12
    Join Date
    Oct 2006
    Location
    Israel
    Posts
    600

    Default

    Quote Originally Posted by tigrang View Post
    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?


    Quote Originally Posted by AnonymousCoward View Post
    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?


    Quote Originally Posted by dragonn View Post
    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.
    Last edited by gilboa; 08-05-2014 at 03:27 AM.
    DEV: Intel S2600C0, 2xE52658V2, 32GB, 4x2TB, GTX780, F20/x86_64, Dell U2711.
    SRV: Intel S5520SC, 2xX5680, 36GB, 4x2TB, GTX550, F20/x86_64, Dell U2412..
    BACK: Tyan Tempest i5400XT, 2xE5335, 8GB, 3x1.5TB, 9800GTX, F20/x86-64.
    LAP: ASUS N56VJ, i7-3630QM, 16GB, 1TB, 635M, F20/x86_64.

  3. #13
    Join Date
    Jul 2013
    Posts
    49

    Default

    Quote Originally Posted by gilboa View Post
    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.

  4. #14
    Join Date
    Jan 2012
    Posts
    65

    Default

    Quote Originally Posted by dragonn View Post
    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.

  5. #15
    Join Date
    Oct 2006
    Location
    Israel
    Posts
    600

    Default

    Quote Originally Posted by dragonn View Post
    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.
    DEV: Intel S2600C0, 2xE52658V2, 32GB, 4x2TB, GTX780, F20/x86_64, Dell U2711.
    SRV: Intel S5520SC, 2xX5680, 36GB, 4x2TB, GTX550, F20/x86_64, Dell U2412..
    BACK: Tyan Tempest i5400XT, 2xE5335, 8GB, 3x1.5TB, 9800GTX, F20/x86-64.
    LAP: ASUS N56VJ, i7-3630QM, 16GB, 1TB, 635M, F20/x86_64.

Posting Permissions

  • You may not post new threads
  • You may not post replies
  • You may not post attachments
  • You may not edit your posts
  •