Announcement

Collapse
No announcement yet.

Intel Provides Temporary e1000e Fix

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

  • Intel Provides Temporary e1000e Fix

    Phoronix: Intel Provides Temporary e1000e Fix

    In the Linux 2.6.27 kernel code was a rather serious regression where a faulty driver is killing Intel network hardware. Specifically the e1000 and e1000e network adapters were getting their EEPROM corrupted by the driver, which renders the network interface permanently inoperable unless that non-volatile memory can be restored...

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

  • #2
    Well it seems the patch only enables write protection but it does not really fix the root cause of the problem. Also it does not enable already defect chips to be recognized again.

    http://git.kernel.org/?p=linux/kerne...c6ebbee3f9b3a7

    Comment


    • #3
      good idea by the kernel developers!
      they should start to randomly insert drivers that brick you hardware so the companies suddenly raise the funds to fix drivers... maybe that will help with the opensource ati driver development
      Last edited by Pfanne; 10-02-2008, 11:26 AM.

      Comment


      • #4
        Sad part is, if this had been a Mac or a AMD product the tech sites would have made this a world headline, but because it's a intel it's a mere footnote elsewhere.

        Comment


        • #5
          Honestly, I don't understand why this bug made it past the very early stages of the release cycle. It seems like a bug of this severity should trigger a rollback to earlier code as soon as it is discovered. Something like this should never make it into a Linux kernel RC.

          Comment


          • #6
            Originally posted by deanjo View Post
            Sad part is, if this had been a Mac or a AMD product the tech sites would have made this a world headline, but because it's a intel it's a mere footnote elsewhere.

            I can see it now: "AMD deliberately sabotages kernel project"

            Comment


            • #7
              Originally posted by TechMage89 View Post
              Honestly, I don't understand why this bug made it past the very early stages of the release cycle. It seems like a bug of this severity should trigger a rollback to earlier code as soon as it is discovered. Something like this should never make it into a Linux kernel RC.
              well.. its very hard to reproduce, it simply did not get hit that early in the cycle.

              If you want better rc's, you must too help test hardware..

              Comment


              • #8
                SO now that this bug came to light and is being investigated...that's a good thing, but who should be using RC kernels anyway?

                Comment


                • #9
                  Originally posted by DeepDayze View Post
                  SO now that this bug came to light and is being investigated...that's a good thing, but who should be using RC kernels anyway?
                  If nobody used RC kernels there would be a massive increase in breakage. Developers depend on user feedback to isolate and fix bugs as they can't have every combination of software and hardware installed on systems available at their finger tips.

                  Comment

                  Working...
                  X