From owner-freebsd-scsi Sun May 17 09:41:33 1998 Return-Path: Received: (from majordom@localhost) by hub.freebsd.org (8.8.8/8.8.8) id JAA08786 for freebsd-scsi-outgoing; Sun, 17 May 1998 09:41:33 -0700 (PDT) (envelope-from owner-freebsd-scsi@FreeBSD.ORG) Received: from pluto.plutotech.com (mail.plutotech.com [206.168.67.137]) by hub.freebsd.org (8.8.8/8.8.8) with ESMTP id JAA08751; Sun, 17 May 1998 09:41:23 -0700 (PDT) (envelope-from gibbs@plutotech.com) Received: from narnia.plutotech.com (narnia.plutotech.com [206.168.67.130]) by pluto.plutotech.com (8.8.7/8.8.5) with ESMTP id KAA29693; Sun, 17 May 1998 10:41:14 -0600 (MDT) Message-Id: <199805171641.KAA29693@pluto.plutotech.com> X-Mailer: exmh version 2.0.1 12/23/97 To: Mark Murray cc: gibbs@FreeBSD.ORG, scsi@FreeBSD.ORG Subject: Re: CAM broken with SMP/current/AHC In-reply-to: Your message of "Sun, 17 May 1998 09:58:02 +0200." <199805170758.JAA00278@greenpeace.grondar.za> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Date: Sun, 17 May 1998 10:37:02 -0600 From: "Justin T. Gibbs" Sender: owner-freebsd-scsi@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.org >Hi > >I added the latest CAM snapshot diffs to my current tree and I >get the following panic on boot: > >SMP: AP CPU#1 Launched! >panic: ahc_intr: AWAITING_MSG for an SCB that does not have a waiting message >mp_lock = 00000001; cpuid = 0; lapic.id = 00000000 >boot() called on CPU#0 > >syncing disks... done >Automatic reboot in 15 seconds - press any key on the console to abort > >Any ideas? I started hunting around for where the system launches the other CPUs, but I haven't found it yet. My guess is that just at the point of startup, these CPUs are vulnerable to receiving interrupts at the same time as CPU 0. I've done some analysis with Russell Cattelan on this, and the only way I can see for this error to occur is if one of the interrupt driver lists is corrupted by unexpected interrupt re-entrance. Why wouldn't this affect the old SCSI code? CAM continues with the boot process while still configuring the devices on the bus, but after registering the presence of the devices to the system. This allows the boot to block only during the configuration of the devices it cares about (like your root disk). But, this does open the window for I/O to occur while extra CPUs are started. >M >-- >Mark Murray >Join the anti-SPAM movement: http://www.cauce.org -- Justin To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-scsi" in the body of the message