From owner-freebsd-isdn  Sat Feb 28 16:19:27 1998
Return-Path: <owner-freebsd-isdn@FreeBSD.ORG>
Received: (from majordom@localhost)
          by hub.freebsd.org (8.8.8/8.8.8) id QAA10176
          for freebsd-isdn-outgoing; Sat, 28 Feb 1998 16:19:27 -0800 (PST)
          (envelope-from owner-freebsd-isdn@FreeBSD.ORG)
Received: from rvc1.informatik.ba-stuttgart.de (rvc1.informatik.ba-stuttgart.de [141.31.112.22])
          by hub.freebsd.org (8.8.8/8.8.8) with ESMTP id QAA10134
          for <freebsd-isdn@FreeBSD.ORG>; Sat, 28 Feb 1998 16:19:13 -0800 (PST)
          (envelope-from helbig@Informatik.BA-Stuttgart.DE)
Received: (from helbig@localhost)
	by rvc1.informatik.ba-stuttgart.de (8.8.8/8.8.5) id BAA00211;
	Sun, 1 Mar 1998 01:18:49 +0100 (MET)
From: Wolfgang Helbig <helbig@Informatik.BA-Stuttgart.DE>
Message-Id: <199803010018.BAA00211@rvc1.informatik.ba-stuttgart.de>
Subject: Re: AVM A1 Setup bug on NetBSD?
In-Reply-To: <199802282220.OAA08206@bubba.whistle.com> from Archie Cobbs at "Feb 28, 98 02:20:48 pm"
To: archie@whistle.com (Archie Cobbs)
Date: Sun, 1 Mar 1998 01:18:49 +0100 (MET)
Cc: helbig@Informatik.BA-Stuttgart.DE, freebsd-isdn@FreeBSD.ORG
X-Mailer: ELM [version 2.4ME+ PL30 (25)]
MIME-Version: 1.0
Content-Type: text/plain; charset=US-ASCII
Content-Transfer-Encoding: 7bit
Sender: owner-freebsd-isdn@FreeBSD.ORG
Precedence: bulk
X-Loop: FreeBSD.org

> Wolfgang Helbig writes:
> > > > Feb 27 00:00:07 hal /netbsd: i4b-L2-i4b_tei_assign: tx TEI ID_Request
> > > > Feb 27 00:00:08 hal /netbsd: i4b-L2-i4b_T202_timeout: unit 0, N202 = 3
> > > > Feb 27 00:00:08 hal /netbsd: i4b-L2-i4b_tei_assign: tx TEI ID_Request
> > > > Feb 27 00:00:09 hal /netbsd: i4b-L2-i4b_T202_timeout: unit 0, N202 = 3
> > > > Feb 27 00:00:09 hal /netbsd: i4b-L2-i4b_tei_assign: tx TEI ID_Request
> > > > Feb 27 00:00:10 hal /netbsd: i4b-L2-i4b_T202_timeout: unit 0, N202 = 3
> > > 
> > > Yes - this is very much likeley due to the interrupt handler not 
> > > being called.
> > 
> > The same happened on a FreeBSD SMP system. The workaround was
> > to MASK/UNMASK the ISAC/HSCX interrupts every time an ISAC command
> > is issued (see layer1/i4b_isac.c)
> 
> Sounds like a case of the chip generating a level-sensitive interrupt
> and the board needing an edge. If a new interrupt becomes pending
          ^^^^^ and/or the PIC ?
> while you're in your interrupt routine, but before you've cleared
> the old interrupt condition, you must generate a new edge by masking
> and then unmasking all interrupts.
> 
> Just a guess..

In fact the Siemens chips (ISAC, HSCX) both generate level-sensitive
interrupts and the PIC on a PC is programmed to be edge-sensitive.
That's why we have this MASK/UNMASK dance in the ISR in the first place.
We don't know so much about the board.

But on the SMP system not even *one* interrupt is delivered, so the
very first edge seems to be lost.
On the same hardware this edge is not lost if a uniprocessor kernel
is running.

Wolfgang

To Unsubscribe: send mail to majordomo@FreeBSD.org
with "unsubscribe freebsd-isdn" in the body of the message