Date: Mon, 20 May 2002 13:00:08 -0700 (PDT) From: Andrew Gallatin <gallatin@cs.duke.edu> To: freebsd-bugs@FreeBSD.org Subject: Re: kern/37060 Message-ID: <200205202000.g4KK08k67608@freefall.freebsd.org>
next in thread | raw e-mail | index | archive | help
The following reply was made to PR kern/37060; it has been noted by GNATS. From: Andrew Gallatin <gallatin@cs.duke.edu> To: Matthias Andree <matthias.andree@stud.uni-dortmund.de> Cc: matthias.andree@web.de, freebsd-gnats-submit@freebsd.org, sos@freebsd.org Subject: Re: kern/37060 Date: Mon, 20 May 2002 15:53:15 -0400 (EDT) Matthias Andree writes: > On Mon, 20 May 2002, Andrew Gallatin wrote: > > > >It would be helpful to know which pointer was null. There > > >are many of them on line 710 of ata-disk.c > > Ok, it looks as though bad things happen when the non-existant primary > slave is probed. I used boot -dg, set a breakpoint at ad_service and > after successfully detecting the first drive, I got some info. > > The most important lines from below, consistent with the trap > (ATA_DEV(ATA_SLAVE) == 1): > > (kgdb) print ((struct ad_softc *)(adp->device->channel->device[1].driver)) > $9 = (struct ad_softc *) 0x0 > > So the problem happens probably at line #713 when dereferencing > ->flags. What if you protect those access with a check for a non-null driver? Also, what happens if you comment out the call to the ata_raiddisk_attach() in ad_attach() ? Drew To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-bugs" in the body of the message
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?200205202000.g4KK08k67608>