Announcement

Collapse
No announcement yet.

The Best Features Of Linux 3.16

Collapse
X
  • Filter
  • Time
  • Show
Clear All
new posts

  • The Best Features Of Linux 3.16

    Phoronix: The Best Features Of Linux 3.16

    The Linux 3.16 kernel could be released as soon as today with its development having calmed down but if you've refrained from reading up on this new kernel, here's the rundown on the new features and capabilities of this 2014 late-summer kernel debut...

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

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

    Comment


    • #3
      Originally posted by tigrang View Post
      And the best feature of all: suspend to RAM regressions. In every new kernel version.
      Your links to those regressions?

      stupid troll and ten character limit.

      Comment


      • #4
        Another nice feature is that colors are better displayed on certain screens with radeon. Used to have massive color banding on my laptop prior to 3.16 (fglrx had no such issue).

        Comment


        • #5
          Originally posted by Pawlerson View Post
          Your links to those regressions?
          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...

          Comment


          • #6
            Outside of 3rd party vendor specific device driver performance integration and/or enhancements, not really a whole lot new.

            Features should be agnostic and thus make the Kernel more impressive if you want to discuss new features.

            Otherwise, it's just vendor add-in stuff.

            Comment


            • #7
              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...
              What is your hardware? For my when I bought my laptop suspend to ram didn't work on kernel 2.6.35 but some version newer it started working and now it works perfectly. Maybe you should submit a bug? Started with kernel 3.10 I had a bug with random kernel panics so I need to disable some interrupts in acpi, I submitted this on kernel bugtracker with all logs, in 3.13 my bug was fixed .

              Comment


              • #8
                So would this be the first kernel that boots on odroids out of the box? What would it need beside generic kernel? Uboot?

                Comment


                • #9
                  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...
                  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.

                  Comment


                  • #10
                    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 .

                    Comment


                    • #11
                      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?


                      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?


                      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, 03:27 AM.
                      DEV: Intel S2600C0, 2xE52658V2, 32GB, 4x2TB + 2x3TB, GTX780, F21/x86_64, Dell U2711.
                      SRV: Intel S5520SC, 2xX5680, 36GB, 4x2TB, GTX550, F21/x86_64, Dell U2412..
                      BACK: Tyan Tempest i5400XT, 2xE5335, 8GB, 3x1.5TB, 9800GTX, F21/x86-64.
                      LAP: ASUS N56VJ, i7-3630QM, 16GB, 1TB, 635M, F21/x86_64.

                      Comment


                      • #12
                        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.

                        Comment


                        • #13
                          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.

                          Comment


                          • #14
                            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 + 2x3TB, GTX780, F21/x86_64, Dell U2711.
                            SRV: Intel S5520SC, 2xX5680, 36GB, 4x2TB, GTX550, F21/x86_64, Dell U2412..
                            BACK: Tyan Tempest i5400XT, 2xE5335, 8GB, 3x1.5TB, 9800GTX, F21/x86-64.
                            LAP: ASUS N56VJ, i7-3630QM, 16GB, 1TB, 635M, F21/x86_64.

                            Comment

                            Working...
                            X