Date: Mon, 23 Jun 2014 07:14:18 -0700 From: John-Mark Gurney <jmg@funkthat.com> To: Eric van Gyzen <eric@vangyzen.net> Cc: current@freebsd.org Subject: Re: ahci panics when detaching... Message-ID: <20140623141418.GF31367@funkthat.com> In-Reply-To: <53A83253.1090303@vangyzen.net> References: <20140623134407.GD31367@funkthat.com> <53A83253.1090303@vangyzen.net>
next in thread | previous in thread | raw e-mail | index | archive | help
Eric van Gyzen wrote this message on Mon, Jun 23, 2014 at 08:57 -0500:
> On 06/23/2014 08:44, John-Mark Gurney wrote:
> > So, when I try to eject a ESATA card, the machine panics... I am able
> > to successfully eject other cards, an ethernet (re) and a serial card
> > (uart), and both handle the removal of their device w/o issue and with
> > out crashes...
> >
> > When I try w/ ahci, I get a panic... The panic backtrace is:
> > #8 0xffffffff80ced4e2 in calltrap () at ../../../amd64/amd64/exception.S:231
> > #9 0xffffffff8093d037 in rman_get_rid (r=0xfffff800064c9380)
> > at ../../../kern/subr_rman.c:979
> > #10 0xffffffff8092b888 in resource_list_release_active (rl=0xfffff80006d39c08,
> > bus=0xfffff80002cd9000, child=0xfffff80006b6d700, type=3)
> > at ../../../kern/subr_bus.c:3419
> > #11 0xffffffff8065d7a1 in pci_child_detached (dev=0xfffff80002cd9000,
> > child=0xfffff80006b6d700) at ../../../dev/pci/pci.c:4133
> > ---Type <return> to continue, or q <return> to quit---
> > #12 0xffffffff80929708 in device_detach (dev=0xfffff80006b6d700)
> > at bus_if.h:181
> > #13 0xffffffff8065f9f7 in pci_delete_child (dev=0xfffff80002cd9000,
> > child=0xfffff80006b6d700) at ../../../dev/pci/pci.c:4710
> >
> > In frame 9:
> > (kgdb) fr 9
> > #9 0xffffffff8093d037 in rman_get_rid (r=0xfffff800064c9380)
> > at ../../../kern/subr_rman.c:979
> > 979 return (r->__r_i->r_rid);
> > (kgdb) print r
> > $1 = (struct resource *) 0xfffff800064c9380
> > (kgdb) print/x *r
> > $4 = {__r_i = 0xdeadc0dedeadc0de, r_bustag = 0xdeadc0dedeadc0de,
> > r_bushandle = 0xdeadc0dedeadc0de}
> >
> > So, looks like something is corrupted the resource data...
>
> The resource data has been freed.
Well, that is a type of corruption.. :) If we free it, why wasn't
it removed from the list? or properly NULL'd out?
> > Attach dmesg:
> > atapci0: <JMicron JMB363 UDMA133 controller> at device 0.0 on pci2
> > ahci1: <JMicron JMB363 AHCI SATA controller> at channel -1 on atapci0
> > ahci1: AHCI v1.00 with 2 3Gbps ports, Port Multiplier supported
> > ahci1: quirks=0x1<NOFORCE>
> > ahcich6: <AHCI channel> at channel 0 on ahci1
> > ahcich7: <AHCI channel> at channel 1 on ahci1
> > ata2: <ATA channel> at channel 0 on atapci0
> > [eject card]
> > ahcich6: stopping AHCI engine failed
> > ahcich6: stopping AHCI FR engine failed
> > ahcich6: detached
> > ahcich7: stopping AHCI engine failed
> > ahcich7: stopping AHCI FR engine failed
> > ahcich7: detached
> > ahci1: detached
> > ata2: detached
> > atapci0: detached
> >
> >
> > Fatal trap 9: general protection fault while in kernel mode
> >
> > Also, has anyone thought about adding a case in your trap
> > handler that when we hit the deadc0de address, to print up a
> > special message or something? At least flag it, or do we not get
> > the faulting address?
> >
> > This is HEAD as of r266429.
> >
> > Let me know if there is anything else you need to know.
>
> The full stack trace might be useful.
I could give it to you, but it contains code I can't release (at
least not yet)... It's basicly an interrupt that calls
pci_delete_child, so there isn't anymore useful information there..
I'm just puzzled why uart and re don't have this same problem..
--
John-Mark Gurney Voice: +1 415 225 5579
"All that I will do, has been done, All that I have, has not."
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?20140623141418.GF31367>