From owner-freebsd-bugs Mon May 20 15:20: 7 2002 Delivered-To: freebsd-bugs@hub.freebsd.org Received: from freefall.freebsd.org (freefall.FreeBSD.org [216.136.204.21]) by hub.freebsd.org (Postfix) with ESMTP id 9B68637B40C for ; Mon, 20 May 2002 15:20:03 -0700 (PDT) Received: (from gnats@localhost) by freefall.freebsd.org (8.11.6/8.11.6) id g4KMK3493108; Mon, 20 May 2002 15:20:03 -0700 (PDT) (envelope-from gnats) Date: Mon, 20 May 2002 15:20:03 -0700 (PDT) Message-Id: <200205202220.g4KMK3493108@freefall.freebsd.org> To: freebsd-bugs@FreeBSD.org Cc: From: Matthias Andree Subject: Re: kern/37060 Reply-To: Matthias Andree Sender: owner-freebsd-bugs@FreeBSD.ORG Precedence: bulk List-ID: List-Archive: (Web Archive) List-Help: (List Instructions) List-Subscribe: List-Unsubscribe: X-Loop: FreeBSD.org The following reply was made to PR kern/37060; it has been noted by GNATS. From: Matthias Andree To: Andrew Gallatin Cc: Matthias Andree , matthias.andree@web.de, freebsd-gnats-submit@freebsd.org, sos@freebsd.org Subject: Re: kern/37060 Date: Tue, 21 May 2002 00:12:02 +0200 On Mon, May 20, 2002 at 03:53:15PM -0400, Andrew Gallatin wrote: [ata-disk.c:710] > What if you protect those access with a check for a non-null driver? Didn't try yet. > Also, what happens if you comment out the call to the > ata_raiddisk_attach() in ad_attach() ? Good question: Skipping the if(ata_raiddisk_attach(adp)) call with "return" in a remote gdb on all occasions lets the machine boot up properly. One observation of the failed runs: The first raiddisk_attach (Primary Master) has a NULL table, and subsequently allocates one. The Primary Slave is skipped right away. When FreeBSD then tries to attach ad1 (ad2 with ATA_STATIC_ID, secondary master), it crashes with the known symptoms. To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-bugs" in the body of the message