[prev in list] [next in list] [prev in thread] [next in thread] 

List:       linux-atm
Subject:    RE: Weird Lane Thing (cont)
From:       "Joseph Gooch" <mrwizard () psu ! edu>
Date:       2000-04-26 16:29:33
[Download RAW message or body]



> -----Original Message-----
> From: Werner Almesberger [mailto:almesber@lrc.epfl.ch]
> Sent: Wednesday, April 26, 2000 12:02 PM
> To: Joseph Gooch
> Cc: linux-atm@lrc.di.epfl.ch
> Subject: Re: Weird Lane Thing (cont)
>
>
> Joseph Gooch wrote:
> > Great, that works fine.  Now one of the ignored hosts.  It
> looks like the
> > call is rejected, but I can't figure out why.
>
> Didn't spot anything obvious either. Which NIC was it again ?
> Maybe adding a printk near net/atm/svc.c:svc_accept:313 could help:
>
> 		if (error) {
> +			printk(KERN_ERR "REJECTED: %d\n",error);
> 			sigd_enq(NULL,as_reject,old_vcc,NULL,NULL);
> 				/* @@@ should include the reason */
>
> Three guesses:
>  - you may already have a VC with that VCI open for some reason.
>    (Might happen if you're mixing PVCs with SVCs. Should't in any
>    other case.)

No PVC's here, good guess tho.

>  - your NIC may try to shape even though the rate is set to full OC3
>    speed and run out of shapers

Well, it's a 25mb nicstar (Forerunner LE) so I question that i see incoming
rates set to OC3 speed.  I had to hardcode atmsigd to the 25mb cell rate.
It should bump down the rate if it is not available though.

>  - you may simply be running out of VCs (buffers, VCIs, etc.)

Possible.  I only have 70 simultaneous VC's, so I donno.  Adding the error
line will probably help narrow it down.

As a side note, this used to be much more of a problem.  Ever since i've
applied Rui's SMP patch for the nicstar, this problem appears right after i
reboot the machine.  After a while it clears up and behaves normally.  So
i'm wondering if perhaps the kernel is having a problem creating 70 some
VC's at pretty much the same time. (i'm using fping to monitor these hosts,
so pings are sent out in huge bursts)  Later after the VC hasn't been used
for awhile, it might be easier for it to create the VC's it couldn't before.
This is of course pure speculation.  Also note before the SMP patch, this
problem was always there, regardless of uptime.

> If the NIC driver supports a debugging /proc/net/atm entry,
> its content
> near the time of the failure may be useful too, e.g.
> /proc/net/atm/eni:0

Pool   count    min   init    max
Small     32      8     32     64
Large     24      8     24     48
Huge       8      6      8     10
Iovec     48      8     48     80
Interrupt counter: 1088376

Just looks like buffering information to me.

I'll put that printk in and reboot and see what happens.

Thanks!
Joseph Gooch
Carbon Lehigh Intermediate Unit

[prev in list] [next in list] [prev in thread] [next in thread]