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... 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. Thanks. -- 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 - 11:44:09 UTC
This archive was generated by hypermail 2.4.0 : Wed May 19 2021 - 11:40:50 UTC