lkml.org 
[lkml]   [2008]   [Sep]   [26]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
 
Messages in this thread
    /
    Date
    From
    SubjectRe: e1000e NVM corruption issue status
    Jesse Barnes wrote:
    > On Friday, September 26, 2008 10:52 am Jesse Barnes wrote:
    >> On Friday, September 26, 2008 4:49 am Arjan van de Ven wrote:
    >>> Jiri Kosina wrote:
    >>>> On Thu, 25 Sep 2008, Brandeburg, Jesse wrote:
    >>>>> this is the current set of patches that I have to help us debug
    >>>>> and/or fix e1000e issues found during this debug effort for
    >>>>> the corrupt NVM. the "drop stats lock" - "reset swflag" patches allow
    >>>>> Thomas' patch for a mutex in the SWFLAG acquire function to run
    >>>>> without any errors.
    >>>> Thanks. Also Jesse Barnes' patch shouldn't be forgotten, could you
    >>>> please add it to that lineup?
    >>>>
    >>>> http://marc.info/?l=linux-kernel&m=122237193628087&w=2
    >>> can we (for now) also stick a WARN_ON() into that failure path? that way
    >>> we can at least catch if/when this happens more visibly..... if it
    >>> happens consistently in say the new distros we can be more confident that
    >>> we're down the right path in diagnosing the issue.
    >> I'm spinning a new one now with some debug output, stay tuned (just gotta
    >> boot my test box).
    >
    > Ok here's an updated one. Jesse (Br) can you add it to your list? If the X
    > driver really is mapping too much this should catch it, as long as it goes
    > through sysfs.
    >
    > Thanks,
    > Jesse
    >

    I've been experimenting with unmapping flash space until its actually
    needed, e.g., in the functions that use the E1000_READ_FLASH and
    E1000_WRITE_FLASH macros. Along the way I looked at how flash write
    cycles are initiated because I was having a hard time believing that
    having flash space mapped was part of the root cause. However, it looks
    like its pretty simple to initiate a write or erase cycle. All of the
    required action bits in ICH_FLASH_HSFSTS and ICH_FLASH_HSFCTL must be 1,
    and these 2 register are in the correct order if X was writing 0xff in
    ascending order.

    Just a thought.

    rtg
    --
    Tim Gardner timg@tpi.com www.tpi.com
    OR 503-601-0234 x102 MT 406-443-5357


    \
     
     \ /
      Last update: 2008-09-26 21:17    [W:3.362 / U:0.388 seconds]
    ©2003-2020 Jasper Spaans|hosted at Digital Ocean and TransIP|Read the blog|Advertise on this site