Announcement

Collapse
No announcement yet.

Linux 3.17-rc1 Kernel Released

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

  • Linux 3.17-rc1 Kernel Released

    Phoronix: Linux 3.17-rc1 Kernel Released

    A day shy of two weeks since the Linux 3.17 merge window opened, Linus Torvalds released the Linux 3.17-rc1 kernel...

    Phoronix, Linux Hardware Reviews, Linux hardware benchmarks, Linux server benchmarks, Linux benchmarking, Desktop Linux, Linux performance, Open Source graphics, Linux How To, Ubuntu benchmarks, Ubuntu hardware, Phoronix Test Suite

  • #2
    Tossed it on all my machines a bit ago So far, nothing appears to be broken.

    Comment


    • #3
      i have a hope

      Originally posted by Espionage724 View Post
      Tossed it on all my machines a bit ago So far, nothing appears to be broken.

      i have a hope, optimus without tearing with this kernel

      Comment


      • #4
        Anyone know if Valve's xpad driver is included in this release?

        Comment


        • #5
          Originally posted by teeedubb View Post
          Anyone know if Valve's xpad driver is included in this release?
          Ted Mielczarek (1):
          Input: xpad - add support for Xbox One controllers



          Yep, 3.17-rc1's lookin' pretty good.

          Comment


          • #6
            I haven't been able to run 3.15+ without either disabling _OSC in my BIOS, or passing radeon.runpm=0 to the kernel... and even then, 3.16 runs terribly slow. If you have been having the same problems, please add yourself to this bug report: https://bugzilla.kernel.org/show_bug.cgi?id=79701 . Apparently, this only affects AMD system that have both integrated (APU) and dedicated cards...
            Also please leave a comment if you have such a system but are NOT affected.

            Comment


            • #7
              Originally posted by asdfblah View Post
              I haven't been able to run 3.15+ without either disabling _OSC in my BIOS, or passing radeon.runpm=0 to the kernel... and even then, 3.16 runs terribly slow. If you have been having the same problems, please add yourself to this bug report: https://bugzilla.kernel.org/show_bug.cgi?id=79701 . Apparently, this only affects AMD system that have both integrated (APU) and dedicated cards...
              Also please leave a comment if you have such a system but are NOT affected.

              Actually, i've had one issue too with kernels 3.15+ which might be related? Since kernel 3.0 i've been successfully building on a customised .config file without an initrd image (initial ramdisk options disabled, debugging completely pulled out etc bare essentials) but i couldn't get 3.15+ to boot originally (because a module was being overlooked).
              When 3.14 became the new latest 'longterm' version, i stuck with it since it runs without issue, but when i came to try 3.16+, i noticed that i could only build a bootable image if i edited the Kconfig file in the arch/x86 directory and made the config IOSF_MBI entry default to n instead of m - and even then, the kernel does say it's searching for a ramdisk on startup with these later kernels, even though i've always expressly removed support for it and it's never been an issue before? This issue has been present in every kernel, rc or final since 3.15-rc1?

              (I've messed around with so much stuff over the years, this issue may very well be my own fault ), but i thought i'd bring it up on the off chance it's not and it's actually relevant. Changing the "IOSF_MBI" to default to 'y' might make a difference and include the functionality if it's suddenly become essential.

              Just looking at the Kconfig file from the 3.14 kernel, it reads:

              Code:
              config IOSF_MBI
              	bool
              	depends on PCI
              	---help---
              	  To be selected by modules requiring access to the Intel OnChip System
              	  Fabric (IOSF) Sideband MailBox Interface (MBI). For MBI platforms
              	  enumerable by PCI.
              whereas from kernel 3.15 onwards, it now reads:
              Code:
              config IOSF_MBI
              	tristate
              	default [B]m[/B]
              	depends on PCI
              I've got a Radeon HD 4200, "Turion II Dual-Core Mobile M52" CPU, no such _OSC option in my BIOS(?), and with the exception of having to make this modification to get my initrd-less kernel bootable, and it mysteriously looking for a ramdisk for a fraction of a second at startup, everything is running well.

              Comment


              • #8
                Originally posted by Espionage724 View Post
                Tossed it on all my machines a bit ago So far, nothing appears to be broken.
                Then it seems, you don't use virtualbox.

                Comment


                • #9
                  xpad driver is still a broken mess. Still doesn't contain the various fixes presented before by the Valve employee... or the various patches that still have yet to be reviewed by anyone... The Xbox 360 wireless support is the most broken... I don't really understand why this got in there before the device instancing patch (so we don't have 4 controllers present when there's really only one), the urb race condition patch (where the output urb can be called simultaneously causing a rare race condition), or the various packets that aren't used at all (specifically the one that will tell you what's connected to the Xbox Wireless receiver device!). The driver module still can't remove or insert itself properly without screwing up the LEDs on the controller.

                  Comment


                  • #10
                    Originally posted by computerquip View Post
                    xpad driver is still a broken mess. Still doesn't contain the various fixes presented before by the Valve employee... or the various patches that still have yet to be reviewed by anyone... The Xbox 360 wireless support is the most broken... I don't really understand why this got in there before the device instancing patch (so we don't have 4 controllers present when there's really only one), the urb race condition patch (where the output urb can be called simultaneously causing a rare race condition), or the various packets that aren't used at all (specifically the one that will tell you what's connected to the Xbox Wireless receiver device!). The driver module still can't remove or insert itself properly without screwing up the LEDs on the controller.
                    Yes, you're right. It needs a big cleanup, and eventually splitting between different generations of controllers. I tried once to submit a patch which fixed LEDs on the wireless controller, together with a big cleanup, but it ended up being lost in the noise. I don't think there's a maintainer who actually cares about this driver, and if there's one, I haven't heard anything from him, even when valve submitted their big patch :/

                    Comment

                    Working...
                    X