On Tue, Feb 20, 2001 at 05:18:37PM +0900, Augustin Vidovic wrote:
> 00:0c.0 Ethernet controller: Intel Corporation 82557 (rev 08)
> 00:0d.0 Ethernet controller: Intel Corporation 82557 (rev 08)
It's i82559.
It can't have that original bug which is checked by those EEPROM bits and
workaround for w
On Mon, Feb 19, 2001 at 11:21:36PM -0800, Andrey Savochkin wrote:
> On Tue, Feb 20, 2001 at 03:30:48PM +0900, Augustin Vidovic wrote:
> > On Mon, Feb 12, 2001 at 01:00:34AM -0800, Ion Badulescu wrote:
> > > > Augustin, could you send the output of `lspci' and `eepro100-diag -ee', please?
> > > > (
On Tue, Feb 20, 2001 at 03:30:48PM +0900, Augustin Vidovic wrote:
> On Mon, Feb 12, 2001 at 01:00:34AM -0800, Ion Badulescu wrote:
> > > Augustin, could you send the output of `lspci' and `eepro100-diag -ee', please?
> > > (The latter may be taken from ftp://scyld.com/pub/diag/)
> >
> > I'd be cu
On Mon, Feb 12, 2001 at 01:00:34AM -0800, Ion Badulescu wrote:
> > Augustin, could you send the output of `lspci' and `eepro100-diag -ee', please?
> > (The latter may be taken from ftp://scyld.com/pub/diag/)
>
> I'd be curious to see them too.
Ok, here is the output (the status are displayed onl
On Mon, 12 Feb 2001, Andrey Savochkin wrote:
> I've just checked: "Sending a multicast list set command" is printed only on
> high debug levels, so Augustin might not see them.
I could have sworn that I saw the message being printed unconditionally.
But you're right, so we're back to square one
Ion,
On Thu, Feb 08, 2001 at 03:26:51AM -0800, Ion Badulescu wrote:
> On Thu, 8 Feb 2001 20:15:39 +0900, Augustin Vidovic <[EMAIL PROTECTED]> wrote:
>
> >> eth0: Sending a multicast list set command from a timer routine."
> >>
> >> If you find such messages, the work-around really did s
Alan Cox, Thu Feb 08 2001 - 02:42:52 EST:
> > It's the printk that gets it wrong, although that's harmless.
> > Intel's documentation states that the bug does NOT exist if the
> > bits 0 and 1 in eeprom[3] are 1. Thus, the workaround is correct,
> > the printk is wrong.
>
> So why does it fi
On Thu, Feb 08, 2001 at 03:53:10AM -0800, Ion Badulescu wrote:
> Still, there should be something before these suppressed messages started.
No, sorry, but absolutely nothing since the boot.
> It goes like this:
>
> bit0 = 1 means the workaround may be omitted when operating at 10 Mbit
> bit1 =
On Thu, 8 Feb 2001, Augustin Vidovic wrote:
> This suppression of thousands of lines was described as a DOS-protection
> in the docs I read.
Still, there should be something before these suppressed messages started.
> With my patch, the test becomes (eeprom[3] & 0x03), which is not null
> for e
On Thu, Feb 08, 2001 at 03:26:51AM -0800, Ion Badulescu wrote:
> syslogd does not suppress messages, it suppresses *identical* messages.
> So what was the *first* message logged by syslogd, the one followed by
> "last message repeated XXX times"?
It's not "last message repeatead XXX times", it's
On Thu, 8 Feb 2001 20:15:39 +0900, Augustin Vidovic <[EMAIL PROTECTED]> wrote:
>> So what _were_ those messages? Can you post them?
>
> No I can't because they were suppressed by the syslogd (DOS protection), only
> their number being reported (several thousands every few seconds).
syslogd does
On Thu, Feb 08, 2001 at 03:00:10AM -0800, Ion Badulescu wrote:
> > At the same time, the /var/log/messages receives thousands of messages from the
> > NET: subsystem.
>
> So what _were_ those messages? Can you post them?
No I can't because they were suppressed by the syslogd (DOS protection), on
On Thu, 8 Feb 2001 19:41:56 +0900, Augustin Vidovic <[EMAIL PROTECTED]> wrote:
> You can see a kind of sudden blackout which lasts about 3 hours, and then the
> situation resumes to normality.
>
> At the same time, the /var/log/messages receives thousands of messages from the
> NET: subsystem.
On Wed, Feb 07, 2001 at 11:59:05PM -0800, Ion Badulescu wrote:
> I don't think it fixes *this* bug. However, the bug workaround effectively
> reinitializes the chip, so it might serve as a generic 'reset and try
> again' kind of workaround. In that case, we might as well enable it
> unconditionall
On Thu, 8 Feb 2001, Alan Cox wrote:
> > It's the printk that gets it wrong, although that's harmless.
> > Intel's documentation states that the bug does NOT exist if the
> > bits 0 and 1 in eeprom[3] are 1. Thus, the workaround is correct,
> > the printk is wrong.
>
> So why does it fix the prob
On Thu, Feb 08, 2001 at 02:42:52AM -0500, Alan Cox wrote:
> > It's the printk that gets it wrong, although that's harmless.
> > Intel's documentation states that the bug does NOT exist if the
> > bits 0 and 1 in eeprom[3] are 1. Thus, the workaround is correct,
> > the printk is wrong.
>
> So why
> It's the printk that gets it wrong, although that's harmless.
> Intel's documentation states that the bug does NOT exist if the
> bits 0 and 1 in eeprom[3] are 1. Thus, the workaround is correct,
> the printk is wrong.
So why does it fix the problem for him. His report and your reply don't
make
On Wed, Feb 07, 2001 at 11:23:01PM -0800, Ion Badulescu wrote:
> Intel's documentation states that the bug does NOT exist if the
> bits 0 and 1 in eeprom[3] are 1. Thus, the workaround is correct,
> the printk is wrong.
I wonder if it's not Intel's documentation which is wrong : it seems
that the
On Thu, 8 Feb 2001 14:53:55 +0900, Augustin Vidovic <[EMAIL PROTECTED]> wrote:
> --- linux-2.4.1/drivers/net/eepro100.c Sun Jan 28 03:40:14 2001
> +++ linux-2.4.1-vido1/drivers/net/eepro100.cThu Feb 8 14:08:49 2001
> @@ -815,7 +815,7 @@
>
> sp->phy[0] = eeprom[6];
> sp->ph
Patch for drivers/net/eepro100.c in kernel 2.4.1 (and before).
For some of the bugged Intel EtherExpress Pro 100 network cards,
although the driver diagnoses the receiver lock-up bug, the workaround
is not enabled. It appears that the test for the diagnostic and the test
for the workaround activat
20 matches
Mail list logo
