Announcement

Collapse
No announcement yet.

Feature-Rich Linux 3.10 Kernel Officially Released

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

  • #16
    Originally posted by duby229 View Post
    I can induce a kernel panic by plugging in a thumb drive and rebooting... For some reason that seems retarded to me, USB drives get detected before SATA drives, so the drive assignments for the root filesystem gets changed and the kernel responds by panicking. So every time I boot I have to make sure no drive is plugged into USB. it can be annoying.
    Correct me if I'm wrong on this, but I wonder if your root filesystem mount point in /etc/fstab is referenced via the block device directly (like /dev/sda1) instead of the filesystem UUID. If so, then it would be worth changing your mount point to use the UUID reference instead of the block device name, to see if that helps fix the panic.

    Comment


    • #17
      Originally posted by Andrecorreia View Post
      brightness control not working for me with this kernel.

      is a problem with RC version and this final too, too bad same error who was reported and not resolved

      I also have brightness control problems on my laptop. I think it was broken in 3.8 and has is due to devices in /sys/class/firmware

      Comment


      • #18
        Originally posted by rafirafi View Post
        OSX si the baseline only for Apple manufactured machines, this doesn't make a lot.
        xnu is really superior to linux for power management
        It hardcodes every Mac model it supports. Sure, that's superior power management, but also would never be accepted in linux.

        if (macbook_2008_later)
        this();
        else if (air_2012)

        Comment


        • #19
          Originally posted by johnc View Post
          Linux is basically done. There's nothing more to do.
          There is still some de-blobbing to do. Now with Fedora and Debian opting for no-blobs-by-default there is definitely a need to get stuff working (again).

          Comment


          • #20
            Originally posted by Ericg View Post
            See if you can re-create the SMP kernel errors on upstream kernels? o.O I've used Linux for 5 years, on a large variety of hardware, and i've never seen ONE kernel panic for ANY reason.
            My last real kernel panic is years ago. Now talk to me about lock-ups. :-(

            Comment


            • #21
              Originally posted by Wilfred View Post
              My last real kernel panic is years ago. Now talk to me about lock-ups. :-(
              I get occasional kernel panics when booting, and often when I use 100% of my CPU since I built my PC (the RAM is fine, I tested at least two RAM kits, and the 1600 MHz one was also tested at 1333 MHz)... Xubuntu 13.04, so 3.8.0.

              Is this a known problem, and will updating the kernel (sudo apt-get upgrade) fix this?
              Last edited by Calinou; 07-01-2013, 10:32 AM.

              Comment


              • #22
                The only times i have managed to get kernel panics was when i used fedora 15 beta and flashplayer

                3.10 seems like a solid release based on my very limited testing.
                Last edited by varikonniemi; 07-01-2013, 10:53 AM.

                Comment


                • #23
                  Originally posted by Ericg View Post
                  See if you can re-create the SMP kernel errors on upstream kernels? o.O I've used Linux for 5 years, on a large variety of hardware, and i've never seen ONE kernel panic for ANY reason.
                  Usually kernel panics come about from hardware issues much of the time, as BSOD's on Windows also stem from the same thing. If you are using fully supported hardware with properly installed kernel and drivers kernel panics should be very rare to none

                  Comment


                  • #24
                    Originally posted by BO$$ View Post
                    So did you report it to kernel devs? This sounds like an extremely stupid bug. How can these things still be in there? Are they not testing anything? The Linux world would really benefit from more QA.
                    Its a known issue that hardware detection is fully asynchronous-- great for speeds but bad because things are done in random orders. The above poster's fstab MUST be using /dev/sda as the reference point, rather than LABEL= or UUID= because both would take care of the USB being marked as /dev/sda and causing a panic because root doesn't exist supposedly.

                    It creates more problems on servers because ethernet cards are done randomly as well unless you explicitly change them to something static-- so any firewall rules based off of /dev/eth0 or /dev/eth1 can become broken by an unlucky reboot.

                    Comment


                    • #25
                      Originally posted by Ericg View Post
                      Its a known issue that hardware detection is fully asynchronous-- great for speeds but bad because things are done in random orders. The above poster's fstab MUST be using /dev/sda as the reference point, rather than LABEL= or UUID= because both would take care of the USB being marked as /dev/sda and causing a panic because root doesn't exist supposedly.

                      It creates more problems on servers because ethernet cards are done randomly as well unless you explicitly change them to something static-- so any firewall rules based off of /dev/eth0 or /dev/eth1 can become broken by an unlucky reboot.
                      Your right, That is exactly it. I reread the gentoo handbook and now they are recommending UUID. I just havent read it in a long time and have been using the same install for years.

                      Comment


                      • #26
                        Originally posted by Ericg View Post
                        It creates more problems on servers because ethernet cards are done randomly as well unless you explicitly change them to something static-- so any firewall rules based off of /dev/eth0 or /dev/eth1 can become broken by an unlucky reboot.
                        I think that's fixed by systemd 197, and seems to be fixable without systemd too http://www.freedesktop.org/wiki/Soft...nterfaceNames/

                        Comment


                        • #27
                          Originally posted by Ericg View Post
                          It creates more problems on servers because ethernet cards are done randomly as well unless you explicitly change them to something static-- so any firewall rules based off of /dev/eth0 or /dev/eth1 can become broken by an unlucky reboot.
                          I think that's fixed in systemd 197. It also seems fixable without using systemd: http://www.freedesktop.org/wiki/Soft...nterfaceNames/

                          Comment


                          • #28
                            Radeon HD 4770 driver broken in Linux 3.10

                            The driver for Radeon HD 4770 in Linux 3.10 seems to be currently broken, see https://bugzilla.kernel.org/show_bug.cgi?id=60674 and https://bbs.archlinux.org/viewtopic.php?pid=1307650

                            So it's not recommended for Radeon HD 4770 users (like me) to switch to the latest kernel until this is fixed. Graphical environments are unusable.
                            Last edited by Nuc!eoN; 08-04-2013, 06:55 AM.

                            Comment

                            Working...
                            X