From owner-freebsd-current@FreeBSD.ORG Fri Jan 13 06:55:09 2006 Return-Path: X-Original-To: current@freebsd.org Delivered-To: freebsd-current@FreeBSD.ORG Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id BBEEA16A41F for ; Fri, 13 Jan 2006 06:55:09 +0000 (GMT) (envelope-from huang@gddsn.org.cn) Received: from gddsn.org.cn (gddsn.org.cn [218.19.164.145]) by mx1.FreeBSD.org (Postfix) with ESMTP id 1A06343D48 for ; Fri, 13 Jan 2006 06:55:08 +0000 (GMT) (envelope-from huang@gddsn.org.cn) Received: from [192.168.168.71] (unknown [218.19.164.157]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by gddsn.org.cn (Postfix) with ESMTP id 3C40F38CB65; Fri, 13 Jan 2006 14:55:02 +0800 (CST) Message-ID: <43C74EC4.70808@gddsn.org.cn> Date: Fri, 13 Jan 2006 14:55:00 +0800 From: Huang wen hui User-Agent: Mozilla Thunderbird 1.0.7 (X11/20051212) X-Accept-Language: zh-cn,zh MIME-Version: 1.0 To: Scott Long References: <43C712A7.1050805@gddsn.org.cn> <43C718EF.9050301@elischer.org> <43C71BFC.5090104@gddsn.org.cn> <43C730EC.7070104@samsco.org> In-Reply-To: <43C730EC.7070104@samsco.org> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Cc: Julian Elischer , current@freebsd.org Subject: Re: if_em panic X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 13 Jan 2006 06:55:09 -0000 Scott Long wrote: > Huang wen hui wrote: > >> Julian Elischer wrote: >> >>> Huang wen hui wrote: >>> >>> >>> >>>> hi, >>>> when I load if_em on TP42P got this panic: >>>> >>>> >>>> >>> >>> >>> >>> looks like the first interrupt occurs before the driver has finished >>> setting itself up.. >>> (just a first impression). >>> Scott'll probably nail it. >>> >>> I'm guessing it works fine if compiled in.. >>> >>> >> no, that why I use kldload. Sometimes can kldload successfully in >> single-user mode. >> > > I never encountered this with kldload, but I understand what is wrong. > I'll fix it shortly. now got this when if_em compile in kernel: Fatal trap 12: page fault while in kernel mode fault virtual address = 0x4 fault code = supervisor read, page not present instruction pointer = 0x20:0xc05469d3 stack pointer = 0x28:0xc0c20a24 frame pointer = 0x28:0xc0c20a24 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) [thread pid 0 tid 0 ] Stopped at em_disable_intr+0x37: movl 0x4(%eax),%edx db> bt Tracing pid 0 tid 0 td 0xc099c980 em_disable_intr(c4b7a800,c4bd2280,c4bd2280,0,c4b7a800) at em_disable_intr+0x37 em_allocate_pci_resources(c4b7a800) at em_allocate_pci_resources+0x1fa em_attach(c4bd2280) at em_attach+0x31d device_attach(c4bd2280,c4bd2100,c4bd2280,c4bb8d00,0) at device_attach+0x58 device_probe_and_attach(c4bd2280) at device_probe_and_attach+0xc4 bus_generic_attach(c4bb8d00,6,c4b2d920,1,c0af2a9c) at bus_generic_attach+0x16 acpi_pci_attach(c4bb8d00) at acpi_pci_attach+0xd0 device_attach(c4bb8d00,c4bb1a00,c4bb8d00,0,c4bb7400) at device_attach+0x58 device_probe_and_attach(c4bb8d00) at device_probe_and_attach+0xc4 bus_generic_attach(c4bb7400,c4bb7400,c4baa680,c4b2d920,c4bd6cc0) at bus_generic_attach+0x16 acpi_pcib_attach(c4bb7400,c4bd6cf0,1,c4b2d920,c4bb7400) at acpi_pcib_attach+0x12f acpi_pcib_pci_attach(c4bb7400) at acpi_pcib_pci_attach+0x7c device_attach(c4bb7400,c4b90000,c4bb7400,c4baa680,0) at device_attach+0x58 device_probe_and_attach(c4bb7400) at device_probe_and_attach+0xc4 bus_generic_attach(c4baa680,6,c4b90000,1,c0af2a9c) at bus_generic_attach+0x16 acpi_pci_attach(c4baa680) at acpi_pci_attach+0xd0 device_attach(c4baa680,c4b89b80,c4baa680,0,c4adf580) at device_attach+0x58 device_probe_and_attach(c4baa680) at device_probe_and_attach+0xc4 bus_generic_attach(c4adf580,c4adf580,c4adf580,c4b90000,c4b93a80) at bus_generic_attach+0x16 acpi_pcib_attach(c4adf580,c4b93a94,0,c0c20c58,c06b534c) at acpi_pcib_attach+0x12f acpi_pcib_acpi_attach(c4adf580) at acpi_pcib_acpi_attach+0xcf device_attach(c4adf580,c4adf700,c4adf580,c4baaa00,c4b8d200) at device_attach+0x58 device_probe_and_attach(c4adf580) at device_probe_and_attach+0xc4 bus_generic_attach(c4b8d200,8ff,860,c4b97968,4) at bus_generic_attach+0x16 acpi_attach(c4b8d200) at acpi_attach+0x631 device_attach(c4b8d200,0,c4b8d200,c4a9a780,0) at device_attach+0x58 device_probe_and_attach(c4b8d200) at device_probe_and_attach+0xc4 bus_generic_attach(c4a9a780,c4a9a780,c4a9a780,c0c20d40,c06b1500) at bus_generic_attach+0x16 nexus_attach(c4a9a780) at nexus_attach+0x13 device_attach(c4a9a780,c0690e67,c4a9a780,c096dbf0,c25000) at device_attach+0x58 device_probe_and_attach(c4a9a780) at device_probe_and_attach+0xc4 root_bus_configure(c0c20d88,c066ce82,0,c1ec00,c1e000) at root_bus_configure+0x16 configure(0,c1ec00,c1e000,0,c044f865) at configure+0x9 mi_startup() at mi_startup+0x96 begin() at begin+0x2c > > Scott