Dell gx280 and acpi problems
Danny Braniss
danny at cs.huji.ac.il
Mon Sep 27 01:34:21 PDT 2004
for the short verions goto the end.
> On Thursday 23 September 2004 04:29 am, Danny Braniss wrote:
> > > On Wednesday 22 September 2004 04:58 am, Danny Braniss wrote:
> > > > could some acpi expert shed some light?
> > > >
> > > > -current panics on boot with BIOS default settings (Suspend Mode is S3)
> > > > fix: set Power Management/Suspend Mode to S1 in BIOS
> > > >
> > > > disabling ACPI on boot is not good, since this box has no PS/2, and the
> > > > USB keyboard/mouse don't work with ACPI off.
> > > >
> > > > the acpi dumps are available from:
> > > > ftp://ftp.cs.huji.ac.il/users/danny/freebsd/gx280
> > > >
> > > > this is the panic:
> > > >
> > > >
> > > > KDB: debugger backends: ddb
> > > > KDB: current backend: ddb
> > > > Copyright (c) 1992-2004 The FreeBSD Project.
> > > > Copyright (c) 1979, 1980, 1983, 1986, 1988, 1989, 1991, 1992, 1993,
> > > > 1994 The Regents of the University of California. All rights reserved.
> > > > FreeBSD 5.3-BETA5 #14: Tue Sep 21 13:44:32 IDT 2004
> > > > danny at new-dev:/r+d/obj/new-dev/r+d/5.3/src/sys/HUJI
> > > > Timecounter "i8254" frequency 1193182 Hz quality 0
> > > > CPU: Intel(R) Pentium(R) 4 CPU 3.00GHz (2992.52-MHz 686-class CPU)
> > > > Origin = "GenuineIntel" Id = 0xf34 Stepping = 4
> > > >
> > > > Features=0xbfebfbff<FPU,VME,DE,PSE,TSC,MSR,PAE,MCE,CX8,APIC,SEP,MTRR,PG
> > > >E,MC A, CMOV,PAT,PSE36,CLFLUSH,DTS,ACPI,MMX,FXSR,SSE,SSE2,SS,HTT,TM,PBE>
> > > > Hyperthreading: 2 logical CPUs
> > > > real memory = 1063813120 (1014 MB)
> > > > avail memory = 1031565312 (983 MB)
> > > > kernel trap 12 with interrupts disabled
> > > >
> > > >
> > > > Fatal trap 12: page fault while in kernel mode
> > > > cpuid = 0; apic id = 00
> > > > fault virtual address = 0x1c
> > > > fault code = supervisor write, page not present
> > > > instruction pointer = 0x8:0xc075dab5
> > > > stack pointer = 0x10:0xc0c21be0
> > > > frame pointer = 0x10:0xc0c21cac
> > > > 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 = 0 ()
> > > > [thread 0]
> > > > Stopped at vm_fault+0x1b1: lock cmpxchgl %ecx,0x1c(%edx)
> > > > db> trace
> > > > vm_fault(c103a000,c1004000,1,0,c08e36c0) at vm_fault+0x1b1
> > > > trap_pfault(c0c21d14,0,c1004c29) at trap_pfault+0x184
> > > > trap(fffd0018,c1000010,c0c20010,c1004bfd,7) at trap+0x2f1
> > > > calltrap() at calltrap+0x5
> > > > --- trap 0xc, eip = 0xc0a18574, esp = 0xc0c21d54, ebp = 0xc0c21d74 ---
> > > > madt_probe(c22264f0,c08bb1f0,c0c21d98,c05e8302,0) at madt_probe+0x174
> > > > apic_init(0,c1ec00,c1e000,0,c0441225) at apic_init+0x47
> > > > mi_startup() at mi_startup+0x96
> > > > begin() at begin+0x2c
> > >
> > > Can you do a 'gdb kernel.debug' and then do 'l madt_probe+0x174' and
> > > e-mail the results?
> >
> > I think i'm doing something wrong :-), tip -38400 com1 works fine,
> > Type '?' for a list of commands, 'help' for more detailed help.
> > OK boot -d
> > /boot/kernel/acpi.ko text=0x3fa30 data=0x1be4+0x110c
> > syms=[0x4+0x72a0+0x4+0x9743]
> > GDB: debug ports: sio
> > GDB: current port: sio
> > KDB: debugger backends: ddb gdb
> > KDB: current backend: ddb
> > KDB: enter: Boot flags requested debugger
> > [thread 0]
> > Stopped at kdb_enter+0x2b: nop
> > db> gdb
> > Step to enter the remote GDB backend.
> >
> > backing out of tip via ~.
> >
> >
> > shuttle-2# gdb -b 38400 kernel.debug
> > GNU gdb 6.1.1 [FreeBSD]
> > Copyright 2004 Free Software Foundation, Inc.
> > GDB is free software, covered by the GNU General Public License, and you
> > are welcome to change it and/or distribute copies of it under certain
> > conditions. Type "show copying" to see the conditions.
> > There is absolutely no warranty for GDB. Type "show warranty" for details.
> > This GDB was configured as "i386-marcel-freebsd"...
> > Ready to go. Enter 'tr' to connect to the remote target
> > with /dev/cuaa0, 'tr /dev/cuaa1' to connect to a different port
> > or 'trf portno' to connect to the remote target with the firewire
> > interface. portno defaults to 5556.
> >
> > Type 'getsyms' after connection to load kld symbols.
> >
> > If you're debugging a local system, you can use 'kldsyms' instead
> > to load the kld symbols. That's a less obnoxious interface.
> > (gdb) tr /dev/cuaa0
> > Ignoring packet error, continuing...
> > Ignoring packet error, continuing...
> > Ignoring packet error, continuing...
> > Couldn't establish connection to remote target
> > Malformed response to offset query, timeout
> > (gdb)
>
> You don't have to do the gdb during the panic. You just need access to the
> kernel.debug corresponding to the kernel you are booting. Is this a custom
> kernel on the box or are you doing an install? If you are doing an install,
> try disabling apic support by entering 'set hint.apic.0.disabled=1' at the
> loader prompt and install that way. Then, once the box is running, build a
> debug kernel, reproduce the panic, get the instruction pointer address, and
> then fire up gdb on the kernel.debug file and do 'l *<value of instruction
> pointer>'.
to get gdb talking i had to:
db> gdb
db> step
Fatal trap 12: page fault while in kernel mode
cpuid = 0; apic id = 00
fault virtual address = 0x1c
fault code = supervisor write, page not present
instruction pointer = 0x8:0xc07673b1
stack pointer = 0x10:0xc0c21be0
frame pointer = 0x10:0xc0c21cac
code segment = base 0x0, limit 0xfffff, type 0x1b
= DPL 0, pres 1, def32 1, gran 1
processor eflags = trace trap, interrupt enabled, resume, IOPL = 0
current process = 0 ()
$T0b8:b17376c0;thread:0;#ad~
^
|--- i typed to get out of db
then
(not clear from docs, maybe common sense, but you better be in boot/kernel)
gdb kernel.debug
(gdb) l madt_probe+0x174
Junk at end of line specification.
so not giving up, and using my 'skills' with gdb
(gdb) bt
#0 vm_fault (map=0xc103a000, vaddr=0xc1004000, fault_type=0x1,
fault_flags=0x0) at atomic.h:154
During symbol reading, Incomplete CFI data; unspecified registers at
0xc07673d5.
#1 0xc07ce128 in trap_pfault (frame=0xc0c21d14, usermode=0x0, eva=0xc1004c29)
at /r+d/5.3/src/sys/i386/i3
86/trap.c:716
#2 0xc07cdd91 in trap (frame=
{tf_fs = 0xfffd0018, tf_es = 0xc1000010, tf_ds = 0xc0c20010, tf_edi =
0xc1004bfd, tf_esi = 0x7, tf_e
bp = 0xc0c21d74, tf_isp = 0xc0c21d40, tf_ebx = 0x2, tf_edx = 0x12, tf_ecx =
0x4, tf_eax = 0x0, tf_trapno =
0xc, tf_err = 0x0, tf_eip = 0xc0a24574, tf_cs = 0x8, tf_eflags = 0x90093,
tf_esp = 0xc00fec00, tf_ss = 0x
1})
at /r+d/5.3/src/sys/i386/i386/trap.c:417
#3 0xc07bc7aa in calltrap () at /r+d/5.3/src/sys/i386/i386/exception.s:140
#4 0xfffd0018 in ?? ()
#5 0xc1000010 in ?? ()
#6 0xc0c20010 in ?? ()
#7 0xc1004bfd in ?? ()
#8 0x00000007 in ?? ()
#9 0xc0c21d74 in ?? ()
#10 0xc0c21d40 in ?? ()
#11 0x00000002 in ?? ()
#12 0x00000012 in ?? ()
#13 0x00000004 in ?? ()
#14 0x00000000 in ?? ()
#15 0x0000000c in ?? ()
#16 0x00000000 in ?? ()
#17 0xc0a24574 in madt_probe () at /r+d/5.3/src/sys/modules/acpi/acpi/../../../
i386/acpica/madt.c:258
#18 0xc07c2757 in apic_init (dummy=0x0) at /r+d/5.3/src/sys/i386/i386/local_api
c.c:564
#19 0xc05f1bfe in mi_startup () at /r+d/5.3/src/sys/kern/init_main.c:210
#20 0xc0441225 in begin () at /r+d/5.3/src/sys/i386/i386/locore.s:348
(gdb) frame 17
#17 0xc0a24574 in madt_probe () at /r+d/5.3/src/sys/modules/acpi/acpi/../../../
i386/acpica/madt.c:258
258 for (i = 0; i < count; i++)
(gdb) l
253 printf("MADT: Failed to map RSDT\n");
254 return (ENXIO);
255 }
256 count = (rsdt->Length - sizeof(ACPI_TABLE_HEADER)) /
257 sizeof(UINT32);
258 for (i = 0; i < count; i++)
259 if (madt_probe_table(rsdt->
TableOffsetEntry[i]))
260 break;
261 madt_unmap_table(rsdt);
262 }
the suspicious part:
(gdb) p *rsdp
$5 = {
Signature = "RSD PTR ",
Checksum = 0xa9,
OemId = "DELL ",
Revision = 0x0,
RsdtPhysicalAddress = 0xfcbfd,
Length = 0xffffffff,
XsdtPhysicalAddress = 0xffffffffffffffff,
ExtendedChecksum = 0xff,
Reserved = "ÿÿÿ"
}
(gdb) p rsdt->Length
Cannot access memory at address 0xc1004c01
(gdb) p rsdp->RsdtPhysicalAddress
$6 = 0xfcbfd
rsdp seems to point to valid data, p->RsdtPhysicalAddress also, but
rsdt->Length gives an gdb error, and in any case seems wrong (0xffffffff).
so i hope all this helps someone,
danny
PS: i think i should change the subject to: 'debugging on the Bleeding Edge'
More information about the freebsd-hackers
mailing list