Hello guys!

Here is an update for the issue. We have found out that 7.4.27 is working and 
7.4.35 is not. We have also identified the piece of code that causes
the problem it was introduced in 7.4.35. here are the details:
In e1000_configure_rx() there is a place stating:
        /* disable receives while setting up the descriptors */
        rctl = E1000_READ_REG(hw, E1000_RCTL);
        E1000_WRITE_REG(hw, E1000_RCTL, rctl & ~E1000_RCTL_EN);
This is how it used to look in 7.4.27. In 7.4.35 two lines were added here:
        E1000_WRITE_FLUSH(hw);
        mdelay(10);
At the end of the function we have:
        /* Enable Receives */
        E1000_WRITE_REG(hw, E1000_RCTL, rctl);
We tried to add here:
        E1000_WRITE_FLUSH(hw);
        mdelay(10);
So that enabling receives is also flushed, but this didn't help. So we removed 
flush/delay sequence in first place (since
it was working like that in previous release) and this turned out to solve the 
problem. Removing those flush/delay calls
in 7.6.15.5 also makes the things work. Maybe someone can comment on what side 
effects this may cause?

 On Fri 23/05/08  7:37 PM , "Tantilov, Emil S"  sent:
> Thanks for the info. I will try to reproduce here in the lab. 
> 
> 
> 
> You mentioned that the distribution you use is SLES10 - can you provide
> 
> the exact kernel version (uname -a)?
> 
> 
> 
> Thanks,
> 
> Emil 
> 
> 
> 
> -----Original Message-----
> 
> From: [EMAIL PROTECTED] [EMAIL PROTECTED] 
> Sent: Thursday, May 22, 2008 12:14 AM
> 
> To: Ronciak, John; Tantilov, Emil S
> 
> Cc: e1000-devel@lists.sourceforge.net
> Subject: Re: RE: [E1000-devel] e1000 freezing during boot
> 
> 
> 
> Yes it is reproducible (though unfortunately not very reliable) on
> 
> multiple systems, with three types of hardware in them.
> 
> First type has two interfaces with ethernet pro 100 cards and one
> 
> 82540EM based
> 
> Second type has three interfaces all 82546GB based
> 
> Third type with three 82571EB interfaces
> 
> 
> 
> 1. yes
> 
> 2. yes
> 
> 3. yes (it is always after a reboot, card never enters this state during
> 
> runtime - as far as we have seen)
> 
> 
> 
> On Thu 22/05/08  2:01 AM , "Tantilov, Emil S"  sent:
> 
> > [EMAIL PROTECTED]
> > wrote:
> 
> > > Hello,
> 
> > 
> 
> > >  This may sound doubtful, but this is not happening
> on
> > one box, or
> 
> > > only in one network environment, and is reproducible 
> 
> > 
> 
> > > though not really reliable, but 5-6 reboots bring NIC
> 
> > into this state
> 
> > 
> 
> > 
> 
> > OK - so from your description it seems that the issue
> is reproducible
> on
> 
> > 
> 
> > multiple (different?) systems - is this correct?
> 
> > 
> 
> > 
> 
> > 
> 
> > If we can get some more details about the failure it
> will at least
> point
> 
> > 
> 
> > to whether this is system or NIC specific. Please reply
> with yes or
> no:
> 
> > 
> 
> > 
> 
> > 
> 
> > 1. Are you seeing the issue on multiple systems
> (preferably not of the
> > 
> 
> > same type).?
> 
> > 
> 
> > 
> 
> > 
> 
> > 2. Are you seeing this with different NICs or just the
> one you
> reported
> 
> > 
> 
> > in the initial email?
> 
> > 
> 
> > 
> 
> > 
> 
> > 3. Can you provide simple steps to reproduce? You
> mentioned reboots -
> is
> 
> > 
> 
> > it fair to say that you see the issue after several
> reboots?
> > 
> 
> > 
> 
> > 
> 
> > > when we first get rx_no_buffer_count in -S then after
> 
> > some 
> 
> > > point it stops and starts counting rx_missed packets.
> 
> > This has been
> 
> > > seen on 8 boxes so far, probably more, but only 8
> 
> > reported. And the
> 
> > > problem started to show itself after update from
> 7.0.33
> > to 7.6.15.5.
> 
> > 
> 
> > 
> 
> > 7.0.33 to 7.6.15.5 is a big leap, if you can maybe
> narrow the gap a
> bit
> 
> > 
> 
> > more by testing versions in betweeen that would
> certainly help.
> > 
> 
> > 
> 
> > 
> 
> > Thanks,
> 
> > 
> 
> > Emil
> 
> > 
> 
> > 
> 
> > 
> 
> > 
> 
> ---- Msg sent via email.ru
> 
> 
> 
> 
---- Msg sent via email.ru

-------------------------------------------------------------------------
Check out the new SourceForge.net Marketplace.
It's the best place to buy or sell services for
just about anything Open Source.
http://sourceforge.net/services/buy/index.php
_______________________________________________
E1000-devel mailing list
E1000-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/e1000-devel

Reply via email to