Skip site navigation (1)Skip section navigation (2)
Date:      Thu, 09 May 2002 10:51:45 -0400 (EDT)
From:      John Baldwin <jhb@FreeBSD.org>
To:        Josef Karthauser <joe@tao.org.uk>
Cc:        cvs-all@FreeBSD.org, cvs-committers@FreeBSD.org
Subject:   Re: cvs commit: src/sys/dev/usb usb_port.h
Message-ID:  <XFMail.20020509105145.jhb@FreeBSD.org>
In-Reply-To: <20020509143357.GA428@genius.tao.org.uk>

next in thread | previous in thread | raw e-mail | index | archive | help

On 09-May-2002 Josef Karthauser wrote:
> On Thu, May 09, 2002 at 09:42:44AM -0400, John Baldwin wrote:
>> 
>> On 09-May-2002 Josef Karthauser wrote:
>> > On Thu, May 09, 2002 at 09:22:27AM -0400, John Baldwin wrote:
>> >> 
>> >> > I tested this on a 2002.04.29.17.00.00 kernel.  A kernel from today
>> >> > crashes during device probes; I've no idea why.
>> >> 
>> >> What is the crash?
>> >> 
>> > 
>> > I can't get a core because it happens during the device probe.  It
>> > looks like a memory allocator problem; something to do with freeing
>> > unallocated or unaligned memory.
>> 
>> Hmm, if you could stick ddb in and get a backtrace and the actual error
>> message that would be nice.  Easiest to do if you can get a serial console
>> setup on the box.
> 
> Two different ones for you:
> 
>     acpi0: <DELL   I 5000 > on motherboard
>     Timecounter "ACPI-safe"  frequency 3579545 Hz
>     free(9)'ing unaligned pointer 0xce4eb0d3
>     Debugger("Don't do that...")
>     Stopped at      Debugger+0x41:  xorl    %eax,%eax
>     db> reset

Please get a trace of this one next time if you can.

>     Timecounter "ACPI-safe"  frequency 3579545 Hz
>     acpi_cpu0: <CPU> on acpi0
>     acpi_tz0: <thermal zone> on acpi0
> 
> 
>     Fatal trap 12: page fault while in kernel mode
>     fault virtual address   = 0x99
>     fault code              = supervisor read, page not present
>     instruction pointer     = 0x8:0xc01e2b8f
>     stack pointer           = 0x10:0xc04eeb48
>     frame pointer           = 0x10:0xc04eeb50
>     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 (swapper)
>     kernel: type 12 trap, code=0
>     Stopped at      _mtx_lock_sleep+0x11b:  movb    0x79(%edx),%al
>     db> trace
>     _mtx_lock_sleep(c082ace4,0,c031d431,65e) at _mtx_lock_sleep+0x11b
>     _mtx_lock_flags(c082ace4,0,c031d431,65e,ce4eef6c) at _mtx_lock_flags+0x39
>     uma_zfree_arg(c082ac00,ce4eef6c,ce4eef6c) at uma_zfree_arg+0x3e
>     free(ce4eef6c,c03534c0,c04eebe4,c0498342,ce4eef6c) at free+0xa7
>     freeenv(ce4eef6c,c04eec0c,d7c3e200,1,c04eec18) at freeenv+0x1a
>     acpi_avoid(d7c113a8,34d,c04eec0c,0,d7c113a8) at acpi_avoid+0x9e

I'm guessing freeenv() is passing in a bogus address here.  Yes, it is. 
acpi_disabled() used to have the same bug but was fixed.  Try this patch:

RCS file: /usr/cvs/src/sys/dev/acpica/acpi.c,v
retrieving revision 1.61
diff -u -r1.61 acpi.c
--- acpi.c      24 Apr 2002 17:49:21 -0000      1.61
+++ acpi.c      9 May 2002 14:47:45 -0000
@@ -1556,16 +1556,17 @@
 int
 acpi_avoid(ACPI_HANDLE handle)
 {
-    char       *cp, *np;
+    char       *cp, *env, *np;
     int                len;
 
     np = acpi_name(handle);
     if (*np == '\\')
        np++;
-    if ((cp = getenv("debug.acpi.avoid")) == NULL)
+    if ((env = getenv("debug.acpi.avoid")) == NULL)
        return(0);
 
     /* scan the avoid list checking for a match */
+    cp = env;
     for (;;) {
        while ((*cp != 0) && isspace(*cp))
            cp++;
@@ -1575,12 +1576,12 @@
        while ((cp[len] != 0) && !isspace(cp[len]))
            len++;
        if (!strncmp(cp, np, len)) {
-           freeenv(cp);
+           freeenv(env);
            return(1);
        }
        cp += len;
     }
-    freeenv(cp);
+    freeenv(env);
     return(0);
 }
 

>     Fatal trap 12: page fault while in kernel mode
>     fault virtual address   = 0x0
>     fault code              = supervisor read, page not present
>     instruction pointer     = 0x8:0xc01ef5e3
>     stack pointer           = 0x10:0xc04fbd54
>     frame pointer           = 0x10:0xc04fbd5c
>     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 ()
>     kernel: type 12 trap, code=0
>     Stopped at      0xc01ef5e3:     movl    0(%eax),%ebx
>     db> trace
>     (null)(c02e50ce,0,c032aa3c,c032bb8c,c04fbd84) at 0xc01ef5e3
>     (null)(c0333380) at 0xc01ef62c
>     (null)(0,4f8c00,4f8000,0,c0128e7c) at 0xc01efb70
>     (null)() at 0xc01cf7c5
>     (null)() at 0xc0128e7c
>     db>

If you have kernel.debug lying around for this one, try using
addr2line (or gdb) to get the file and line of those addresses
in the backtrace.  Probably just the first one is needed as this
is a simple NULL pointer dereference.

> Joe

-- 

John Baldwin <jhb@FreeBSD.org>  <><  http://www.FreeBSD.org/~jhb/
"Power Users Use the Power to Serve!"  -  http://www.FreeBSD.org/

To Unsubscribe: send mail to majordomo@FreeBSD.org
with "unsubscribe cvs-all" in the body of the message




Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?XFMail.20020509105145.jhb>