From owner-freebsd-current@FreeBSD.ORG Wed Nov 5 00:17:46 2003 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 3EB6616A4CE; Wed, 5 Nov 2003 00:17:46 -0800 (PST) Received: from mailman.zeta.org.au (mailman.zeta.org.au [203.26.10.16]) by mx1.FreeBSD.org (Postfix) with ESMTP id 6486143FBF; Wed, 5 Nov 2003 00:17:44 -0800 (PST) (envelope-from bde@zeta.org.au) Received: from gamplex.bde.org (katana.zip.com.au [61.8.7.246]) by mailman.zeta.org.au (8.9.3p2/8.8.7) with ESMTP id TAA04738; Wed, 5 Nov 2003 19:17:40 +1100 Date: Wed, 5 Nov 2003 19:17:39 +1100 (EST) From: Bruce Evans X-X-Sender: bde@gamplex.bde.org To: John Baldwin In-Reply-To: Message-ID: <20031105181249.C1025@gamplex.bde.org> References: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII cc: current@freebsd.org cc: Lukas Ertl Subject: Re: new interrupt code: panic when going multiuser X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.1 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 05 Nov 2003 08:17:46 -0000 On Tue, 4 Nov 2003, John Baldwin wrote: > On 04-Nov-2003 Bruce Evans wrote: > >> > - on a BP6, UP kernels without apic work except for cyintr(), but SMP > >> > kernels have problems with missing interrupts for ata devices and hang > >> > at boot time. > >> > >> Is this related to the ata-lowlevel commit you mentioned above? > > > > No. It looks like the interrupt is really going missing for some > > reason. This is without any acpica. > > What if you try a UP kernel with 'device apic' (i.e. no options SMP), > do you still have ata problems? Is this on an SMP machine btw? Yes, 'device apic' breaks the UP case in the same way that the new interrupt code breaks the SMP case. BP6's are SMP and mine used to mostly work, though not well enough to actually be worth using in SMP mode (it works faster in UP mode with its slowest CPU overclocked 42%; mismatched CPUs and thermal problems prevent significant overclocking in SMP mode). Other bugs in the new interrupt code that I've noticed so far: - lots of pessimizations. The main one is that the PIC is now masked and unmasked for fast interrupt handlers. The masking should be done at a higher level for all interrupt handlers so that it doesn't need to be undone in some cases, and neither masking not unmasking should be done for fast interrupt handlers. This pessimization and other makes fast interrupt handlers more non-fast than before. They are now slower than normal interrupt handlers in FreeBSD-[1-4]. They still have lower latency that normal interrupt handlers in FreeBSD-[1-4], but not as low as actual fast interrupt handlers. Bruce