Date: Mon, 14 Jan 2002 09:23:59 +1000 (EST) From: Andrew Gordon <arg-bsd@arg1.demon.co.uk> To: Gary Jennejohn <garyj@jennejohn.org> Cc: <freebsd-isdn@freebsd.org> Subject: ifpi2 problems - partially fixed! Message-ID: <20020114090708.I29792-100000@server.arg.sj.co.uk> In-Reply-To: <200112250810.fBP8Adh52432@peedub.jennejohn.org>
next in thread | previous in thread | raw e-mail | index | archive | help
I've fixed my main problem with ifpi2 (the one where everything would
grind to a halt after short amount of heavy traffic). My guess is that
the interrupts are level-triggered internally but then become
edge-triggered on leaving the chip - so that if you exit the interrupt
handler without ever getting all the interrupt sources cleared at once,
you never get interrupted again.
With this patch, I see the printf() at about the same point where it used
to lock up previously (and it now keeps going!).
@@ -974,6 +972,8 @@
/* was there an interrupt from this card ? */
if ((stat & ASL_IRQ_Pending) == 0)
return; /* no */
+
+again:
/* interrupts are high active */
if (stat & ASL_IRQ_TIMER)
NDBGL1(L1_H_IRQ, "timer interrupt ???");
@@ -987,6 +987,14 @@
NDBGL1(L1_H_IRQ, "ISAC");
ifpi2_isacsx_intr(sc);
}
+ stat = bus_space_read_1(btag, bhandle, STAT0_OFFSET);
+ NDBGL1(L1_H_IRQ, "stat %x", stat);
+ /* Have we cleared all pending interrupts ? */
+ if ((stat & ASL_IRQ_Pending) != 0)
+ {
+ printf("Repeat IRQ!\n");
+ goto again;
+ }
}
However, there is one remaining problem - which may be a general I4B bug
rather than ifpi2 specific. If I have full debugging turned on as it
tries to make a connection (isdndebug -l1 -m), then I usually see this:
Jan 13 19:56:27 router /kernel: i4b: unit 0, assigned TEI = 116 = 0x74
i4b-L2 i4b_T200_timeout: unit 0, RC = 0
i4b-L2 i4b_rxd_ack: ((N(R)-1)=127) != (UA=0) !!!
i4b-L2 i4b_invoke_retransmission: nr = 0
i4b-L2 i4b_invoke_retransmission: nr(0) != vs(1)
i4b-L2 i4b_invoke_retransmission: ERROR, l2sc->vs = 0, l2sc->ua_num = -1
i4b-L2 i4b_i_frame_queued_up: ERROR, mbuf NULL after IF_DEQUEUE
i4b-L3 T303_timeout: SETUP not answered, cr = 98
Now, this is a slow machine (486/133), and it has a serial console at
9600bps, so maybe you don't expect it to work with full debugging on, but
I think I've seen it once without debugging. The serious issue is that
after this has happened the machine won't recover unless isdnd is
restarted:
isdnd[55]: DBG msg_dialoutnumber: dial req from rbch, unit 0
isdnd[55]: DBG setup_dialout: entry PPPout ok!
isdnd[55]: DBG find_by_device_for_dialoutnumber: found entry 1!
isdnd[55]: DBG FSM event [msg-dialout]: [idle => dialing]
isdnd[55]: DBG F_DIAL: local dial out request
isdnd[55]: DBG select_first_dialno: only one no, no = 08456609287
isdnd[55]: CHD 00002 PPPout rate 60 sec/unit (unitlen unknown)
isdnd[55]: DBG sendm_connect_req: ctrl = 0, chan = -1
isdnd[55]: DBG decr_free_channels: ctrl 0, now 1 chan free
isdnd[55]: CHD 00002 PPPout dialing out from 454560 to 08456609287
isdnd[55]: DBG msg_dialoutnumber: dial req from rbch, unit 0
... pause while things go wrong but nothing more logged by isdnd....
isdnd[55]: DBG find_by_device_for_dialoutnumber: entry 1, cdid in use
isdnd[55]: DBG msg_dialoutnumber: config entry reserved or no match
isdnd[55]: DBG msg_dialoutnumber: dial req from rbch, unit 0
Those last three lines then repeat each time ppp retries, until I restart
isdnd. I haven't yet dug into this to see what is going on.
To Unsubscribe: send mail to majordomo@FreeBSD.org
with "unsubscribe freebsd-isdn" in the body of the message
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?20020114090708.I29792-100000>