Date: Sat, 28 Feb 1998 23:58:34 +0100 (MET) From: Wolfgang Helbig <helbig@Informatik.BA-Stuttgart.DE> To: freebsd-isdn@FreeBSD.ORG Subject: Re: IRQ problems, please test this! Message-ID: <199802282258.XAA00387@rvc1.informatik.ba-stuttgart.de> In-Reply-To: <m0y8s2v-00024QC@bert.kts.org> from Hellmuth Michaelis at "Feb 28, 98 08:35:41 pm"
next in thread | previous in thread | raw e-mail | index | archive | help
> It would be nice if people with problems with i4b (TEI messages, etc. as > described on this list too) could try the following patch to layer1/i4b_isic.c > and report if this leads to any difference in behaviour: This was my first try to get the TELES 16.3 interrupt on the SMP system. Didn't work, because the ISR *never* got called, so this code was never executed. The SMP workaround that I suggested, does the same, but *is* called every time a layer 1 command is executed. A layer 1 command is executed if you do a TEI-ID-Request, so from there on the interrupts on the SMP worked. Just for curiosity I removed the MASK/UNMASK cycle from the ISIC interrupt service routine. Didn't make any difference on my machine (486DX4 100 MHz) or on the SMP system (two Pentium Pro @ 200 MHz), i. e. both interrupted as well as before. What I *do* get on both machines are Receive Data Overflow interrupts during ftp'ing a file bigger than one MByte from a BISDN system. They are not reported by the current code. Instead the HSCX interrupt service routine returns after an RDO indication--thereby ignoring a possible RME interrupt. This in turn results in putting two consecutive frames into the same mbuf, causing this message: i4b-L1-isic_hscx_irq: RAWHDLC rx buffer overflow in RPF, in_len=2048 The RDO indication shouldn't happen at all--I don't think our CPUs and the code is to slow per se. Instead I suppose a bug that leads to a deadlock of some kind lasting about 10 ms most the time. (The ping turnaround times are 30 ms from I4B to BISDN and 20 ms from BISDN to BISDN, at least that is/was reported.) Under certain conditions those deadlocks seem to last forever--resulting in breakage of I4B on the NetBSD machines. Right now, I try to find an explanation for those 10 ms. Sorry for speculating, but that's all I can contribute right now. Anyway, I4B stays interesting :-) Wolfgang > ISAC_WRITE(I_MASK, 0xff); > HSCX_WRITE(1, H_MASK, 0xff); > > + DELAY(100); > + > HSCX_WRITE(0, H_MASK, HSCX_A_IMASK); > ISAC_WRITE(I_MASK, ISAC_IMASK); > HSCX_WRITE(1, H_MASK, HSCX_B_IMASK); 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?199802282258.XAA00387>