Re: warning - receiver ring buffer overrun

[Nick Holland <nick@holland-consulting.net>]

Chris Zakelj wrote:
> 
> Nick Holland wrote:
> 
> >  well, no dmesg or anything else about your system...or what speed
> >  your link is or or or...
> 
> Sorry, Nick.  My bad on that.  The link is a residential ADSL, 1.5M/384k.
> dmesg...

Fast enough that a lot of tiny packets could cause problems, perhaps. 
Still...doesn't seem THAT unreasonably fast.

...
> we0: changing IRQ 9 to 3
> we0 at isa0 port 0x280/32 iomem 0xd0000/16384 irq 3: WD8013EPC (16-bit)
> we0: address 00:00:c0:93:8d:b3
> we0: changing IRQ 10 to 11

I never really did much with 8013s, but they are the older Western
Digital card, before SMC bought WD's networking stuff.  I don't think
the buffer is as big as some of the later cards.

> we1 at isa0 port 0x300/32 iomem 0xcc000/8192 irq 11: SMC8416T (16-bit)
> we1: address 00:e0:29:16:31:93

8416 is the newest of the we(4) cards.  A lot nicer to work with than
the earlier ones, no shared memory by default...but yours is using
shared memory.  Well, that probably gets you the performance of the
8216 on a slower processor.  (I had benchmarked the 8216 vs the 8416
in a Netware server many years ago...the 8216 was a small amount
faster, why, not sure.  Applicable to OpenBSD?  Wouldn't bet on it.  

Uh...  look at those IRQs!
The first card is jumping from 9 to 3 to 10 to 11.  It doesn't look
really happy.  Now note also that your we1 card is at IRQ 11, too.  
 
The we driver can do that jump settings around a bit.  It has its
default setting:
> we0     at isa? port 0x280 iomem 0xd0000 irq 9  # WD/SMC 80x3 ethernet
> we1     at isa? port 0x300 iomem 0xcc000 irq 10 #
but if you point it at the NIC's IO port, it can pick out the IRQ and
memory address.  How well it does so, I'm not sure, I tend to be
paranoid and set the card to the GENERIC defaults.  You appear to have
both cards at IRQ 11, which, if real, I'm amazed it works at all, and
if not real, it might explain some difficulty.

You might want to try setting your NICs "properly", it *might* resolve
your ring buffer overrun errors.

...
> 
> >  Does the ring buffer overrun error even cause you problems? A lot of
> >  OpenBSD driver messages are more informative than serious distress.
> >  Packets get lost in networks -- the entire system is designed to
> >  tolerate it and deal with it. If they are not causing actual
> >  problems, just turn off the monitor, problem solved. 8)
> 
> I'm honestly not sure...  I do know, however, that I've been getting an
> awful lot of time-out and "document contains no data" errors, as well as
> non-functional javascripts while browsing, that magically "go away" when
> i connect the system directly with the USB port.  I've also been unable
> to get rid of that annoying 'arplookup' error, which I think is an
> artifact of how the DSL modem tries to handle DMZ stuff :(  For what
> it's worth, I did a "pass in quick all"/"pass out quick all" on my
> /etc/pf.conf just to make sure I hadn't screwed something up there.

I'd imagine a IRQ conflict like we appear to have here causing a much
larger version of this problem: basicly, nothing coming through ever. 
However, if things got really lucky, it might just work sometimes, and
the result might be the issues you are seeing (well, probably not the
arplookup issue).


Oh, uh...another issue that I have tripped across a few times lately. 
Most DSL systems use a smaller-than-standard-Ethernet MTU, and under
some circumstances, OpenBSD doesn't seem to handle this well at all
(case in point: OpenBSD attached to a SpeedStream ADSL router, someone
gets VERY unhappy here and all kinds of problems happen).  Solution:
reduce the MTU of your outbound interface (to 1492 worked in my cases,
your service might vary).  Symtoms could match what you describe as
your problems, though doesn't change the "Ring buffer overrun"
situation...or probably doesn't...

Nick.
-- 
http://www.holland-consulting.net