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
> 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
12 matches
Mail list logo
