Announcement

Collapse
No announcement yet.

Feature-Rich Linux 3.10 Kernel Officially Released

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

  • #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; 01 July 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; 01 July 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.
          All opinions are my own not those of my employer if you know who they are.

          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; 04 August 2013, 06:55 AM.

                  Comment

                  Working...
                  X