Re: ahci panics when detaching...

From: John-Mark Gurney <jmg_at_funkthat.com>
Date: Mon, 23 Jun 2014 07:14:18 -0700
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."
Received on Mon Jun 23 2014 - 12:14:20 UTC

This archive was generated by hypermail 2.4.0 : Wed May 19 2021 - 11:40:50 UTC