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