mtrash_ctor panic caused by ACPI and ATAng was Re: Interrupts, ATAng, and wayward pointers, oh my!

On Thu, Feb 05, 2004 at 03:17:37PM -0800, Steve Kargl wrote:
> Ladies and Gents,
> 
> I have the following (hand transcript) panici during boot from
> a kernel built from 1 hour old sources:
> 
> ad0: 38154MB <IC25N040ATC05-0> [77520/16/63] at ata0-master UDMA100 
> ata1-slave: FAILURE - ATAPI_IDENTIFY no interrupt
> ata1-slave: FAILURE - ATAPI_IDENTIFY no interrupt
> acd0: DVDROM <HL-DT-STDVD-ROM GDR8081N> at ata1-master WDMA2
> Mounting root from ufs:/dev/ad0s3a
> Memory modified after free 0xc407a800(508) val=ff00ff00 _at_ 0xc407a800
> 
> 
> Fatal trap 12: page fault while in kernel mode
> fault virtual address   = 0xff00ff20
> fault code              = supervisor read, page not present
> instruction pointer     = 0x8:0xc05b945a
> stack pointer           = 0x10:0xd84d1984
> frame pointer           = 0x10:0xd84d19a0
> code segment            = base 0x0, limit 0xfffff, type 0x1b
>                         = DPL 0, pres 1, def32 1, gran 1
> processor eflags        = interrupt enabled, resume, IOPL = 0
> current process         = 49 (sh)
> kernel: type 12 trap, code=0
> stopped at    mtrash_ctor+0x3a:    movl  0x20(%eax),%eax
> db> trace
> mtrash_ctor(c407a800,200,0) at mtrash_ctor+0x3a
> uma_zalloc_arg(c0c45cc0,0,2) at uma_zalloc_arg+0x169
> malloc(188,c0650d00,2,3,c3fe27e0) at malloc+0xb7
> elf32_load_file(c41c2528,d4cb20f4,d84d1ab0,d84d1bd0,1000) at elf32_load_file+0x51
> exec_elf32_imgact(d84d1b94,c051fb78,c067d450,0,0) at exec_elf32_imgact+0x4c7
> kern_execve(c3fe27e0,8065098,8065084,8065094,0) at kern_execve+0x33a
> execve(c3fe27e0,d84d1d14,3,0,286) at execve+0x18
> syscall(2f,2f,2f,8065098,8065084) at syscall+0x217
> Xint0x80_syscall() at Xint80_syscall+0x1d
> --- syscall (59, FreeBSD ELF32, execve), eip = 0x2811ca6f, esp=0xbfbfec8c, ebp = 0xbfbfecb8
> db> 
> 
> I can't get a core dump.
> 

Via trial and error, I have determined that the above panic is
caused by ACPI and ATAng.  This is a Dell 4150 laptop.  I can 
build a working kernel with sources checked out via cvsup with
date=2004.01.30.19.00.00.  If I use a date of 2004.01.30.20.00.00,
I retrieve only revision 1.203 of ata-all.c and revision 1.19 of
ata-queue.h.  No other files are changed in sys/ and the resulting
kernel produces the above panic.  Finally, if I set
hint.acpi.0.disabled="1" in /boot/loader.conf.  The kernel that
previously panicked will boot fine.

PS: No, I can't get a core dump because the disk subsystem isn't
    ready for a dump when the panics occurred and I can't hook
    up a serial console.  I can panic the machine as needed.
-- 
Steve