Fwd: Kernel panic on 7.2-RC1 when booting with ACPI enabled
kernel.
Magnus Kling
klingfon at gmail.com
Fri May 15 06:48:05 UTC 2009
2009/5/11 John Baldwin <jhb at freebsd.org>
> On Friday 01 May 2009 3:30:28 pm Magnus Kling wrote:
> > 2009/5/1 John Baldwin <jhb at freebsd.org>
> >
> > > On Friday 01 May 2009 2:30:28 pm Magnus Kling wrote:
> > > > 2009/4/30 John Baldwin <jhb at freebsd.org>
> > > >
> > > > > On Saturday 25 April 2009 6:27:23 am Magnus Kling wrote:
> > > > > > 2009/4/24 John Baldwin <jhb at freebsd.org>
> > > > > > > Can you do 'frame 10' followed by 'p *(struct acpi_pci_devinfo
> > > > > > > *)child->ivars'
> > > > > > >
> > > > > > > --
> > > > > > > John Baldwin
> > > > > >
> > > > > >
> > > > > > Sure, no problem. This is a none critical server so I can do alot
> of
> > > > > > debugging and testing if that is needed.
> > > > > >
> > > > > >
> > > > > > (kgdb) frame 10
> > > > > > #10 0xc0db4ca8 in acpi_pci_child_location_str_method
> > > (cbdev=0xc2212680,
> > > > > > child=0xc2243400, buf=0xc22c2400 "slot=0 function=0 handle=",
> > > > > > buflen=1024)
> > > > > > at
> > > /usr/src/sys/modules/acpi/acpi/../../../dev/acpica/acpi_pci.c:150
> > > > > > 150 strlcat(buf, acpi_name(dinfo->ap_handle),
> buflen);
> > > > > >
> > > > > > (kgdb) p *(struct acpi_pci_devinfo *)child->ivars
> > > > > > $1 = {ap_dinfo = {pci_links = {stqe_next = 0xc0b00f8c}, resources
> = {
> > > > > > stqh_first = 0xc0b00f8c, stqh_last = 0x1030000}, cfg = {dev
> =
> > > 0x0,
> > > > > > bar = {4, 0, 0, 3257136600, 0, 0}, bios = 0, subvendor = 0,
> > > > > > subdevice = 0, vendor = 0, device = 0, cmdreg = 0, statreg
> = 0,
> > > > > > baseclass = 0 '\0', subclass = 0 '\0', progif = 0 '\0',
> revid =
> > > 0
> > > > >
> > > > > Hmm, this is all completely wrong and trashed. What if you do 'p
> > > *child'?
> > > > >
> > > > > --
> > > > > John Baldwin
> > > > >
> > > > (kgdb) p *child
> > > > $2 = {ops = 0xc2161800, link = {tqe_next = 0xc2243380, tqe_prev =
> > > > 0xc2243484}, devlink = {tqe_next = 0xc2243380, tqe_prev =
> 0xc224348c},
> > > > parent = 0xc2212680, children = {tqh_first = 0xc2262880, tqh_last =
> > > > 0xc2262704}, driver = 0xc0b7066c, devclass = 0xc211e240, unit = 0,
> > > > nameunit = 0xc2241640 "atapci0", desc = 0xc223f900 "Promise
> PDC20621
> > > > UDMA100 controller", busy = 0, state = DS_ATTACHED, devflags = 0,
> > > > flags = 13, order = 0 '\0', pad = 0 '\0', ivars = 0xc223f5c0, softc
> =
> > > > 0xc2244800, sysctl_ctx = {tqh_first = 0xc2264380, tqh_last =
> 0xc2241594},
> > > > sysctl_tree = 0xc223f840}
> > > > (kgdb)
> > >
> > > Maybe try adding KTR traces for all calls to device_set_ivars(). I
> wonder
> > > if
> > > something is trashing this device's ivars.
> > >
> > > Oh, dear. The ata(4) driver overwrites the ivars of some PCI devices
> it
> > > attaches to. This is very, very wrong. Which ATA controller do you
> have?
> > >
> > > --
> > > John Baldwin
> > >
> >
> > Aha, I´m using a Promise Fasttrack SX4000 for a RAID1 setup. And the one
> > included on the motherboard for the OS.
> > And yes, I can confirm that without the Fasttrack SX4000 the system boots
> up
> > correctly. (Pulled out the card and edited fstab.)
> > So you are right regarding that the ata driver messes something up. Do
> you
> > contact someone that is responsible for ata driver?
> >
> > Thank you for taking the time to "correct" this,
>
> Can you please try this patch?
>
> --- //depot/vendor/freebsd/src/sys/dev/ata/ata-pci.h 2009/03/30 22:20:14
> +++ //depot/user/jhb/acpipci/dev/ata/ata-pci.h 2009/05/08 20:27:43
> @@ -66,6 +66,7 @@
> void (*function)(void *);
> void *argument;
> } interrupt[8]; /* XXX SOS max ch# for now */
> + void *chipset_data;
> };
>
> /* defines for known chipset PCI id's */
> --- //depot/vendor/freebsd/src/sys/dev/ata/chipsets/ata-acard.c 2009/02/19
> 00:35:16
> +++ //depot/user/jhb/acpipci/dev/ata/chipsets/ata-acard.c 2009/05/08
> 20:27:43
> @@ -51,6 +51,12 @@
> #include <dev/ata/ata-pci.h>
> #include <ata_if.h>
>
> +struct ata_serialize {
> + struct mtx locked_mtx;
> + int locked_ch;
> + int restart_ch;
> +};
> +
> /* local prototypes */
> static int ata_acard_chipinit(device_t dev);
> static int ata_acard_ch_attach(device_t dev);
> @@ -58,6 +64,7 @@
> static void ata_acard_850_setmode(device_t dev, int mode);
> static void ata_acard_86X_setmode(device_t dev, int mode);
> static int ata_serialize(device_t dev, int flags);
> +static void ata_serialize_init(struct ata_serialize *serial);
>
> /* misc defines */
> #define ATP_OLD 1
> @@ -93,6 +100,7 @@
> ata_acard_chipinit(device_t dev)
> {
> struct ata_pci_controller *ctlr = device_get_softc(dev);
> + struct ata_serialize *serial;
>
> if (ata_setup_interrupt(dev, ata_generic_intr))
> return ENXIO;
> @@ -100,8 +108,12 @@
> ctlr->ch_attach = ata_acard_ch_attach;
> ctlr->ch_detach = ata_pci_ch_detach;
> if (ctlr->chip->cfg1 == ATP_OLD) {
> - ctlr->setmode = ata_acard_850_setmode;
> + ctlr->setmode = ata_acard_850_setmode;
> ctlr->locking = ata_serialize;
> + serial = malloc(sizeof(struct ata_serialize),
> + M_TEMP, M_WAITOK | M_ZERO);
> + ata_serialize_init(serial);
> + ctlr->chipset_data = serial;
> }
> else
> ctlr->setmode = ata_acard_86X_setmode;
> @@ -225,11 +237,14 @@
> /* we could set PIO mode timings, but we assume the BIOS did that */
> }
>
> -struct ata_serialize {
> - struct mtx locked_mtx;
> - int locked_ch;
> - int restart_ch;
> -};
> +static void
> +ata_serialize_init(struct ata_serialize *serial)
> +{
> +
> + mtx_init(&serial->locked_mtx, "ATA serialize lock", NULL, MTX_DEF);
> + serial->locked_ch = -1;
> + serial->restart_ch = -1;
> +}
>
> static int
> ata_serialize(device_t dev, int flags)
> @@ -237,20 +252,9 @@
> struct ata_pci_controller *ctlr =
> device_get_softc(device_get_parent(dev));
> struct ata_channel *ch = device_get_softc(dev);
> struct ata_serialize *serial;
> - static int inited = 0;
> int res;
>
> - if (!inited) {
> - serial = malloc(sizeof(struct ata_serialize),
> - M_TEMP, M_NOWAIT | M_ZERO);
> - mtx_init(&serial->locked_mtx, "ATA serialize lock", NULL, MTX_DEF);
> - serial->locked_ch = -1;
> - serial->restart_ch = -1;
> - device_set_ivars(ctlr->dev, serial);
> - inited = 1;
> - }
> - else
> - serial = device_get_ivars(ctlr->dev);
> + serial = ctlr->chipset_data;
>
> mtx_lock(&serial->locked_mtx);
> switch (flags) {
> --- //depot/vendor/freebsd/src/sys/dev/ata/chipsets/ata-promise.c
> 2009/03/30 22:20:14
> +++ //depot/user/jhb/acpipci/dev/ata/chipsets/ata-promise.c 2009/05/08
> 20:27:43
> @@ -283,7 +283,7 @@
> mtx_init(&hpkt->mtx, "ATA promise HPKT lock", NULL, MTX_DEF);
> TAILQ_INIT(&hpkt->queue);
> hpkt->busy = 0;
> - device_set_ivars(dev, hpkt);
> + ctlr->chipset_data = hpkt;
> ctlr->ch_attach = ata_promise_mio_ch_attach;
> ctlr->ch_detach = ata_promise_mio_ch_detach;
> ctlr->reset = ata_promise_mio_reset;
> @@ -730,7 +730,7 @@
> case PR_SX4X:
>
> /* softreset channel ATA module */
> - hpktp = device_get_ivars(ctlr->dev);
> + hpktp = ctlr->chipset_data;
> ATA_OUTL(ctlr->r_res2, 0xc0260 + (ch->unit << 7), ch->unit + 1);
> ata_udelay(1000);
> ATA_OUTL(ctlr->r_res2, 0xc0260 + (ch->unit << 7),
> @@ -1208,7 +1208,7 @@
> static void
> ata_promise_queue_hpkt(struct ata_pci_controller *ctlr, u_int32_t hpkt)
> {
> - struct ata_promise_sx4 *hpktp = device_get_ivars(ctlr->dev);
> + struct ata_promise_sx4 *hpktp = ctlr->chipset_data;
>
> mtx_lock(&hpktp->mtx);
> if (hpktp->busy) {
> @@ -1227,7 +1227,7 @@
> static void
> ata_promise_next_hpkt(struct ata_pci_controller *ctlr)
> {
> - struct ata_promise_sx4 *hpktp = device_get_ivars(ctlr->dev);
> + struct ata_promise_sx4 *hpktp = ctlr->chipset_data;
> struct host_packet *hp;
>
> mtx_lock(&hpktp->mtx);
>
> --
> John Baldwin
>
This is only a response to everyone that is following this thread and have
had the same errors as I have... and are looking for a solution.
The patch will NOT work for FreeBSD 7.0 or 7.1.
This patch www.freebsd.org/~jhb/patches/ata_ivars_7.patch<http://www.freebsd.org/%7Ejhb/patches/ata_ivars_7.patch>.
will WORK for FreeBSD 7. I have tried it with 7.1-RC2 and it works.
John Baldwin will commit the bits to source at a later stage. (Said in an
non-list email).
/Magnus
More information about the freebsd-acpi
mailing list