Markus Pfeiffer <[email protected]> wrote:
>
> > Oct 26 11:24:13 ns29 kernel: eth0: card reports no resources.
> > Oct 26 11:24:15 ns29 kernel: eth0: card reports no resources.
> > Oct 26 12:22:21 ns29 kernel: eth0: card reports no resources.
> > Oct 26 16:16:59 ns29 kernel: eth0: card reports no resources.
> > Oct 26 16:28:37 ns29 kernel: eth0: card reports no resources.
> > Oct 26 16:38:01 ns29 kernel: eth0: card reports no resources.
> >
> let me guess: intel eepro100 or similar??
> Well known problem with that one. dont know if its fully fixed ... With
Happens here too, with 2xPPro200, 2.2.18pre17, Eepro100 and light load.
The network stalls for several minutes when it happens.
> 2.4.0-test9-pre3 it doesnt happen on my machine ...
What about a fix for a 2.2.x...?
-- v --
[email protected]
Hello,
On Thu, Oct 26, 2000 at 07:35:08PM +0300, Ville Herva wrote:
> Markus Pfeiffer <[email protected]> wrote:
> >
> > > Oct 26 11:24:13 ns29 kernel: eth0: card reports no resources.
> > > Oct 26 11:24:15 ns29 kernel: eth0: card reports no resources.
> > > Oct 26 12:22:21 ns29 kernel: eth0: card reports no resources.
> > > Oct 26 16:16:59 ns29 kernel: eth0: card reports no resources.
> > > Oct 26 16:28:37 ns29 kernel: eth0: card reports no resources.
> > > Oct 26 16:38:01 ns29 kernel: eth0: card reports no resources.
> > >
> > let me guess: intel eepro100 or similar??
> > Well known problem with that one. dont know if its fully fixed ... With
>
> Happens here too, with 2xPPro200, 2.2.18pre17, Eepro100 and light load.
> The network stalls for several minutes when it happens.
>
> > 2.4.0-test9-pre3 it doesnt happen on my machine ...
>
> What about a fix for a 2.2.x...?
The exact reason for this problem is still unknown.
Best regards
Andrey V.
Savochkin
Andrey Savochkin wrote:
> > > > Oct 26 16:38:01 ns29 kernel: eth0: card reports no resources.
> > > >
> > > let me guess: intel eepro100 or similar??
> >
> > > 2.4.0-test9-pre3 it doesnt happen on my machine ...
I run 2.4.0-test10-pre5 and it still does it.
Trick : "ifconfig eth0 down" then "ifconfig eth0 up" stops the problem for me
when it occurs.
////\
(@ @)
------------oOOo-(_)-oOOo-------------
Pierre-Philippe Coupard
Software Engineer, Lineo, Inc.
Email : [email protected]
Phone : (801) 426-5001 x 208
--------------------------------------
Auribus teneo lupum.
[I hold a wolf by the ears.]
[Boy, it *sounds* good. But what does it *mean*?]
On Mon, Oct 30, 2000 at 02:23:56PM +0800, you [Andrey Savochkin] claimed:
> Hello,
>
> On Thu, Oct 26, 2000 at 07:35:08PM +0300, Ville Herva wrote:
> > Markus Pfeiffer <[email protected]> wrote:
> > >
> > > > Oct 26 11:24:13 ns29 kernel: eth0: card reports no resources.
> > > > Oct 26 11:24:15 ns29 kernel: eth0: card reports no resources.
> > > > Oct 26 12:22:21 ns29 kernel: eth0: card reports no resources.
> > > > Oct 26 16:16:59 ns29 kernel: eth0: card reports no resources.
> > > > Oct 26 16:28:37 ns29 kernel: eth0: card reports no resources.
> > > > Oct 26 16:38:01 ns29 kernel: eth0: card reports no resources.
> > > >
> > > let me guess: intel eepro100 or similar??
> > > Well known problem with that one. dont know if its fully fixed ... With
> >
> > Happens here too, with 2xPPro200, 2.2.18pre17, Eepro100 and light load.
> > The network stalls for several minutes when it happens.
> >
> > > 2.4.0-test9-pre3 it doesnt happen on my machine ...
> >
> > What about a fix for a 2.2.x...?
>
> The exact reason for this problem is still unknown.
I have to take some of what I said back. The network stalls were actually
due to a lot more stupid problem: the server went into a power saving
state and the NIC IRQ didn't wake it up (mouse did). After I disabled the
the relevant stupidnesses from the BIOS setup, it now works.
The error message, however, does appear with the 2.2.18pre17 eepro100.c,
while as the Becker's version does not show it for whatever reason.
-- v --
[email protected]
On Mon, Oct 30, 2000 at 02:23:56PM +0800, Andrey Savochkin wrote:
> > > > Oct 26 16:38:01 ns29 kernel: eth0: card reports no resources.
> > > >
> > > let me guess: intel eepro100 or similar??
> > > Well known problem with that one. dont know if its fully fixed ... With
> >
> > Happens here too, with 2xPPro200, 2.2.18pre17, Eepro100 and light load.
> > The network stalls for several minutes when it happens.
> >
> > > 2.4.0-test9-pre3 it doesnt happen on my machine ...
> >
> > What about a fix for a 2.2.x...?
>
> The exact reason for this problem is still unknown.
We were seeing this on a firewall a week or so ago -- it was actually
coming from some sort of arp flood/loop on the uplink not being caused by
us, and the speed of the incoming arp packets would cause these messages
to occur.
We tried ifconfig up/down, warm reboot, cold reboot, power cycle, card
swapping, and the messages continued. We stopped the card with a 3c905
and the messages stopped, but "ifconfig" showed Rx overruns at about the
same frequency as the messages used to occur. This is probably another
way to trigger this error than what most people are seeing.
Simon-
[ Stormix Technologies Inc. ][ NetNation Communications Inc. ]
[ [email protected] ][ [email protected] ]
[ Opinions expressed are not necessarily those of my employers. ]
I've not been paying attention to this eepro100 issue but
a coworker mentions that she saw a driver (or patch) posted
here back around 6 Sep 2000 by [email protected] with
Subject: "Re: eepro100 trouble" that might be of interest.
Also, here's a possibly useless personal note WRT the
eepro100 resource msgs, FWIW: I was recently using remote
KGDB to work on an unrelated problem on an MP Pentium
box with integrated eepro100. Whenever I'd leave one CPU
stopped in the kernel debugger for a very long time I'd
get those "no resource" messages from (I believe it was)
the Enet driver when I finally allowed that CPU to continue
running. I never noticed any other ill effects though
I wasn't looking too hard for them at the time. I don't
know what caused those resource messages but the version of
KGDB I was using was not clueful about MP issues - while
that one CPU was breakpointed the other CPU was likely
only held in check as a side-effect, probably by being
prevented from acquiring one of the IRQ-related spinlocks.
Of course, it would probably only be notable if some kind
of resource exhaustion did NOT result from such locking
misbehavior, but it seemed worth at least a mention...
Dec?a Ville Herva:
> Markus Pfeiffer <[email protected]> wrote:
> >
> > > Oct 26 11:24:13 ns29 kernel: eth0: card reports no resources.
> > > Oct 26 11:24:15 ns29 kernel: eth0: card reports no resources.
> > > Oct 26 12:22:21 ns29 kernel: eth0: card reports no resources.
> > > Oct 26 16:16:59 ns29 kernel: eth0: card reports no resources.
> > > Oct 26 16:28:37 ns29 kernel: eth0: card reports no resources.
> > > Oct 26 16:38:01 ns29 kernel: eth0: card reports no resources.
I have this problem with the integrated card in a i810E chipset. I cured
reserving the last mega of RAM of the machine ( I have see this in the Redhat
tips for 6.2).
append="mem=sizeof(mem)-1"
I don't why this work.
Saludos
Drizzt
--
... El dinero no da la felicidad, pero la imita perfectamente.
____________________________________________________________________________
Drizzt Do'Urden Three rings for the Elves Kings under the Sky
[email protected] Seven for the Dwarf_lords in their
hall of stone
Nine for the Mortal Men doomed to die
Hello,
On Tue, Oct 31, 2000 at 02:32:44PM -0500, Michael O'Donnell wrote:
[snip]
> Also, here's a possibly useless personal note WRT the
> eepro100 resource msgs, FWIW: I was recently using remote
> KGDB to work on an unrelated problem on an MP Pentium
> box with integrated eepro100. Whenever I'd leave one CPU
> stopped in the kernel debugger for a very long time I'd
> get those "no resource" messages from (I believe it was)
> the Enet driver when I finally allowed that CPU to continue
> running. I never noticed any other ill effects though
> I wasn't looking too hard for them at the time. I don't
It may be a legitimate case of "no resource" messages: the receive ring
is full because interrupts aren't served for a long time.
The problem is spurious "no resource" conditions, when there are plenty of
ready buffers.
Best regards
Andrey