Date: Sun, 17 May 1998 10:37:02 -0600 From: "Justin T. Gibbs" <gibbs@plutotech.com> To: Mark Murray <mark@grondar.za> Cc: gibbs@FreeBSD.ORG, scsi@FreeBSD.ORG Subject: Re: CAM broken with SMP/current/AHC Message-ID: <199805171641.KAA29693@pluto.plutotech.com> In-Reply-To: Your message of "Sun, 17 May 1998 09:58:02 %2B0200." <199805170758.JAA00278@greenpeace.grondar.za>
next in thread | previous in thread | raw e-mail | index | archive | help
>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
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?199805171641.KAA29693>