From owner-freebsd-current@FreeBSD.ORG Sun Jun 13 03:42:06 2004 Return-Path: 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 D1E4916A4CE for ; Sun, 13 Jun 2004 03:42:06 +0000 (GMT) Received: from dan.emsphone.com (dan.emsphone.com [199.67.51.101]) by mx1.FreeBSD.org (Postfix) with ESMTP id 6958043D1F for ; Sun, 13 Jun 2004 03:42:06 +0000 (GMT) (envelope-from dan@dan.emsphone.com) Received: (from dan@localhost) by dan.emsphone.com (8.12.10/8.12.10) id i5D3fcNk074582; Sat, 12 Jun 2004 22:41:38 -0500 (CDT) (envelope-from dan) Date: Sat, 12 Jun 2004 22:41:38 -0500 From: Dan Nelson To: Doug White Message-ID: <20040613034137.GC94119@dan.emsphone.com> References: <40CAD634.8060808@anduin.net> <20040612142543.H74026@carver.gumbysoft.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20040612142543.H74026@carver.gumbysoft.com> X-OS: FreeBSD 5.2-CURRENT X-message-flag: Outlook Error User-Agent: Mutt/1.5.6i cc: Eirik Oeverby cc: current@freebsd.org Subject: Re: Serial console - how to reboot? X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.1 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: Sun, 13 Jun 2004 03:42:06 -0000 In the last episode (Jun 12), Doug White said: > If you built the kernel with 'options BREAK_TO_DEBUGGER', then a > serial break will drop to ddb. From there you could do 'call boot(0)' > to attempt and orderly shutdown, or 'reset' to, well, reset :) > There's also an 'ALT_BREAK_TO_DEBUGGER' option that emulates the sun > alt-break -- [cr] ~ ^B. btw - DDB in 5.* has a "reset" command so you don't have to remember "call boot(0)". It runs "cpu_reset" to immediately reset the system. Calling "boot(0)" has a better chance of doing a clean reboot but if you're already locked up it may hang as well. -- Dan Nelson dnelson@allantgroup.com From owner-freebsd-current@FreeBSD.ORG Sun Jun 13 04:04:54 2004 Return-Path: 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 0D92516A4D3; Sun, 13 Jun 2004 04:04:52 +0000 (GMT) Received: from smtp01.syd.iprimus.net.au (smtp01.syd.iprimus.net.au [210.50.30.52]) by mx1.FreeBSD.org (Postfix) with ESMTP id D144843D31; Sun, 13 Jun 2004 04:04:51 +0000 (GMT) (envelope-from tim@robbins.dropbear.id.au) Received: from robbins.dropbear.id.au (210.50.40.74) by smtp01.syd.iprimus.net.au (7.0.024) id 40B7A0DA00452181; Sun, 13 Jun 2004 14:04:50 +1000 Received: by robbins.dropbear.id.au (Postfix, from userid 1000) id 74DF841F5; Sun, 13 Jun 2004 14:06:46 +1000 (EST) Date: Sun, 13 Jun 2004 14:06:46 +1000 From: Tim Robbins To: Robert Watson Message-ID: <20040613040646.GB28627@cat.robbins.dropbear.id.au> References: <20040612140758.GA44899@peter.osted.lan> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: User-Agent: Mutt/1.4.1i cc: current@freebsd.org Subject: Re: Fatal trap 12 in kern/kern_descrip.c:2346 X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.1 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: Sun, 13 Jun 2004 04:04:55 -0000 On Sat, Jun 12, 2004 at 11:30:28AM -0400, Robert Watson wrote: > > On Sat, 12 Jun 2004, Peter Holm wrote: > > > Fatal trap 12: page fault while in kernel mode > > cpuid = 0; apic id = 00 > > fault virtual address = 0x4 > > fault code = supervisor read, page not present > > instruction pointer = 0x8:0xc062ec65 > > stack pointer = 0x10:0xd126ab88 > > frame pointer = 0x10:0xd126abc8 > > 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 = 28142 (sysctl) > > kernel: type 12 trap, code=0 > > Stopped at sysctl_kern_file+0x105: movl 0x4(%eax),%eax > > db> t > > sysctl_kern_file(c08d9320,0,0,d126ac10,d126ac10) at sysctl_kern_file+0x105 > > sysctl_root(0,d126ac7c,2,d126ac10,c1a252c0) at sysctl_root+0x156 > > userland_sysctl(c1a252c0,d126ac7c,2,bfbf26c0,bfbfe338) at userland_sysctl+0x12c > > __sysctl(c1a252c0,d126ad14,18,434,6) at __sysctl+0xb3 > > syscall(2f,2f,2f,2,bfbf26c0) at syscall+0x2a0 > > Xint0x80_syscall() at Xint0x80_syscall+0x1f > > --- syscall (202, FreeBSD ELF32, __sysctl), eip = 0x280bb05b, esp = 0xbfbf265c > > Well, this is certainly a NULL pointer dereference in the sysctl code > exporting file descriptor information to user space (perhaps for fstat?). > The question is what is NULL. It looks like you have a dump -- could you > convert sysctl_kern_file+0x105 to a line number? It's likely that it is > line 2346 of kern_descrip.c, which follows the process pointer to its > ucred. If so, could you use gdb on the dump to inspect *p? ISTR he included the output of "print *p" on his web page. I think the problem here is that we put processes onto the allproc list in fork1() before they're properly initialised (or we unlock the allproc sx too early.) Tim From owner-freebsd-current@FreeBSD.ORG Sun Jun 13 04:45:28 2004 Return-Path: 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 1AF8616A4CE; Sun, 13 Jun 2004 04:45:28 +0000 (GMT) Received: from fledge.watson.org (fledge.watson.org [204.156.12.50]) by mx1.FreeBSD.org (Postfix) with ESMTP id A9E2043D2F; Sun, 13 Jun 2004 04:45:27 +0000 (GMT) (envelope-from robert@fledge.watson.org) Received: from fledge.watson.org (localhost [127.0.0.1]) by fledge.watson.org (8.12.11/8.12.11) with ESMTP id i5D4gS0w001677; Sun, 13 Jun 2004 00:42:28 -0400 (EDT) (envelope-from robert@fledge.watson.org) Received: from localhost (robert@localhost)i5D4gSJM001674; Sun, 13 Jun 2004 00:42:28 -0400 (EDT) (envelope-from robert@fledge.watson.org) Date: Sun, 13 Jun 2004 00:42:27 -0400 (EDT) From: Robert Watson X-Sender: robert@fledge.watson.org To: Tim Robbins In-Reply-To: <20040613040646.GB28627@cat.robbins.dropbear.id.au> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII cc: current@freebsd.org Subject: Re: Fatal trap 12 in kern/kern_descrip.c:2346 X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.1 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: Sun, 13 Jun 2004 04:45:28 -0000 On Sun, 13 Jun 2004, Tim Robbins wrote: > > Well, this is certainly a NULL pointer dereference in the sysctl code > > exporting file descriptor information to user space (perhaps for fstat?). > > The question is what is NULL. It looks like you have a dump -- could you > > convert sysctl_kern_file+0x105 to a line number? It's likely that it is > > line 2346 of kern_descrip.c, which follows the process pointer to its > > ucred. If so, could you use gdb on the dump to inspect *p? > > ISTR he included the output of "print *p" on his web page. > > I think the problem here is that we put processes onto the allproc list > in fork1() before they're properly initialised (or we unlock the allproc > sx too early.) Hmm. I noticed, though, that p_flag is set to P_CONTROLT and P_WEXIT, so my initial suspicion was actually exit1(). Robert N M Watson FreeBSD Core Team, TrustedBSD Projects robert@fledge.watson.org Senior Research Scientist, McAfee Research From owner-freebsd-current@FreeBSD.ORG Sun Jun 13 05:03:33 2004 Return-Path: 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 9D9E116A4CE for ; Sun, 13 Jun 2004 05:03:33 +0000 (GMT) Received: from mail.sandvine.com (sandvine.com [199.243.201.138]) by mx1.FreeBSD.org (Postfix) with ESMTP id 7D25543D45 for ; Sun, 13 Jun 2004 05:03:32 +0000 (GMT) (envelope-from don@sandvine.com) Received: by mail.sandvine.com with Internet Mail Service (5.5.2657.72) id ; Sun, 13 Jun 2004 00:45:49 -0400 Message-ID: From: Don Bowman To: 'Bruce Evans' , Don Bowman Date: Sun, 13 Jun 2004 00:45:42 -0400 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2657.72) Content-Type: text/plain; charset="iso-8859-1" cc: "'current@freebsd.org'" Subject: RE: kernel trap 19 with interrupts disabled: system hang X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.1 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: Sun, 13 Jun 2004 05:03:33 -0000 From: Bruce Evans [mailto:bde@zeta.org.au] > > On Wed, 9 Jun 2004, Don Bowman wrote: > > > I have a machine which is completely locking > > up solid every day or so. Its been doing this > > for a couple of months on current. It is running > > cvs current from ~2weeks ago. > > > > This time, i tried shorting the NMI out, and I > > got this message to the serial console: > > > > kernel trap 19 with interrupts disabled > > NMI ... going to debugger > > > > ... but I still can't get into the debugger > > with the key sequence, and no additional > > output came out. > > > > Can I assume from the 'with interrupts disabled' > > that it means that all interrupts are locked off? > > or that 'sti' is set? Its a MP system, a dual > > xeon (P4). > ... OK, this did the trick, i got into db. I managed to get a vmcore, and there is a kernel.debug avail. I included below the output of some commands i ran in db, can someone suggest what else i might run next time? Is anyone interested in having access to this vmcore & kernel.debug? Or can suggest where i might look in it to find this lockup? The system was locked up, so when i pressed the key sequence to enter the debugger, it timed out stopping the other cpus. Everybody is in sched_switch and idle??? Script started on Sun Jun 13 00:26:51 2004 Trying 192.168.1.8... Connected to dc-ts.sandvine.com. Escape character is '^]'. siointr1(c554d800) at siointr1+0xd0 db> t 0 sched_switch(c074bfa0) at sched_switch+0x60 mi_switch(1,0,1,c0c21d2c,c0562ba4) at mi_switch+0x1a0 sleepq_switch(c074bde0,0,c0c21d54,c054dd12,c074bde0) at sleepq_switch+0x135 sleepq_timedwait(c074bde0,0,23,0,0) at sleepq_timedwait+0xc msleep(c074bde0,0,44,c06ecd01,2710) at msleep+0x40a scheduler(0,c1ec00,c1e000,0,c0436065) at scheduler+0x167 mi_startup() at mi_startup+0x96 begin() at begin+0x2c db> t 1 sched_switch(c53e0540) at sched_switch+0x60 mi_switch(1,0,0,ed097c18,c0562b60) at mi_switch+0x1a0 sleepq_switch(c53dfdc0,0,ed097c3c,c054dd2a,c53dfdc0) at sleepq_switch+0x135 sleepq_wait_sig(c53dfdc0,c074fed0,100,0,c53dfe2c) at sleepq_wait_sig+0xc msleep(c53dfdc0,c53dfe2c,15c,c06dde84,0) at msleep+0x422 kern_wait(c53e0540,ffffffff,ed097c94,0,ed097c98) at kern_wait+0x7b5 wait4(c53e0540,ed097d14,4,7,286) at wait4+0x1f syscall(2f,2f,2f,bfbfeef8,bfbfeef8) at syscall+0x283 Xint0x80_syscall() at Xint0x80_syscall+0x1f --- syscall (7, FreeBSD ELF32, wait4), eip = 0x80518cb, esp = 0xbfbfeddc, ebp = 0xbfbfedf8 --- db> t 2 sched_switch(c54ab7e0) at sched_switch+0x60 mi_switch(1,0,0,eec7accc,c0562ba4) at mi_switch+0x1a0 sleepq_switch(c074bce4,0,eec7acf4,c054dd12,c074bce4) at sleepq_switch+0x135 sleepq_timedwait(c074bce4,0,0,0,0) at sleepq_timedwait+0xc msleep(c074bce4,0,4c,c06c7155,64) at msleep+0x40a g_event_procbody(0,eec7ad48) at g_event_procbody+0x52 fork_exit(c05156dc,0,eec7ad48) at fork_exit+0x71 fork_trampoline() at fork_trampoline+0x8 --- trap 0x1, eip = 0, esp = 0xeec7ad7c, ebp = 0 --- db> t 3 sched_switch(c54ab930) at sched_switch+0x60 mi_switch(1,0,0,eec7dc94,c0562ba4) at mi_switch+0x1a0 sleepq_switch(c074bcec,0,eec7dcbc,c054dd12,c074bcec) at sleepq_switch+0x135 sleepq_timedwait(c074bcec,0,23,0,0) at sleepq_timedwait+0xc msleep(c074bcec,c074bc08,24c,c06c7155,64) at msleep+0x40a g_io_schedule_up(c54ab930) at g_io_schedule_up+0x140 g_up_procbody(0,eec7dd48) at g_up_procbody+0x1a fork_exit(c051569c,0,eec7dd48) at fork_exit+0x71 fork_trampoline() at fork_trampoline+0x8 --- trap 0x1, eip = 0, esp = 0xeec7dd7c, ebp = 0 --- db> p ticks c074c4b4 db> p *ticks 33f08b0 db> p/i ticks db> x ticks ticks: 33f08b0 db> x softticks softticks: 328c76a db> help print p examine x search set write w delete d break dwatch watch dhwatch hwatch step s continue c until next match trace where call show ps gdb reset kill watchdog panic ahd_set_unitahd_pause ahd_unpause ahd_in ahd_out db> show all registers breaks thread watches pciregs intrcnt pgrpdump pcpu msgbuf cbstat buffer disk lockedvnods map procvm vmochk object vmopag page pageq cyrixreg irqs idt rtc db> show all procs pid proc uarea uid ppid pgrp flag stat wmesg wchan cmd 7664 c6661dc0 f5427000 12848 2546 2546 0004100 [SLPQ select 0xc07569e4][SLP] smtp 7663 c63d4000 f52e9000 12848 2546 2546 0004100 [SLPQ select 0xc07569e4][SLP] trivial-rewrite 6853 c5a41370 f5023000 12848 2546 2546 0004100 [SLPQ select 0xc07569e4][SLP] pickup 21566 c5d6dc08 f519a000 11114 21565 21566 0004002 [SLPQ ttyin 0xc5a60610][SLP] bash 21565 c63d3a50 f52e6000 11114 21563 21563 0000100 [SLPQ select 0xc07569e4][SLP] sshd 21563 c5a3edc0 f5020000 0 2453 21563 0000100 [SLPQ sbwait 0xc5fb9810][SLP] sshd 2620 c611e898 f52a1000 0 2619 2620 0004002 [SLPQ ttyin 0xc59f5410][SLP] bash 2619 c5abfc08 f5149000 0 1 2619 0004102 [SLPQ wait 0xc5abfc08][SLP] login 2618 c5f5b370 f51f6000 0 1 2618 0004002 [SLPQ ttyin 0xc5597a10][SLP] getty 2617 c665ba50 f53e6000 0 1 2617 0004002 [SLPQ ttyin 0xc5597c10][SLP] getty 2616 c5f5d528 f5224000 0 1 2616 0004002 [SLPQ ttyin 0xc5597e10][SLP] getty 2615 c63d31b8 f52e1000 0 1 2615 0004002 [SLPQ ttyin 0xc55d2010][SLP] getty 2614 c5a9a898 f50c5000 0 1 2614 0004002 [SLPQ ttyin 0xc55d2210][SLP] getty 2613 c665b6e0 f53e4000 0 1 2613 0004002 [SLPQ ttyin 0xc55d2410][SLP] getty 2612 c63d6dc0 f531e000 0 1 2612 0004002 [SLPQ ttyin 0xc55d2610][SLP] getty 2611 c5abfa50 f5148000 0 1 2611 0004002 [SLPQ ttyin 0xc55d2a10][SLP] getty 2575 c5ac86e0 f514f000 0 1 2574 0000000 [SLPQ select 0xc07569e4][SLP] snmpd 2563 c5a37c08 f5016000 0 1 2563 0000000 [SLPQ msgwait 0xc55ac000][SLP] pamsmbd 2556 c5f5b898 f521d000 70 2555 2551 0000000 [SLPQ select 0xc07569e4][SLP] postgres --More-- 2555 c5aa3a50 f50cf000 70 2551 2551 0000000 [SLPQ select 0xc07569e4][SLP] postgres 2551 c611e528 f529f000 70 1 2551 0000000 [SLPQ select 0xc07569e4][SLP] postgres 2550 c5aa3528 f50cc000 12848 2546 2546 0004100 [SLPQ select 0xc07569e4][SLP] qmgr 2546 c5aa3370 f50cb000 0 1 2546 0004100 [CPU 1] master 2477 c648fc08 f5391000 0 1 2477 0000000 [SLPQ nanslp 0xc07515bc][SLP] cron 2453 c5f5b000 f51f4000 0 1 2453 0000100 [SLPQ select 0xc07569e4][SLP] sshd 2432 c665f000 f53f2000 0 1 2432 0000000 [SLPQ select 0xc07569e4][SLP] ntpd 2400 c5f5b6e0 f51f8000 0 1 2400 0000000 [SLPQ select 0xc07569e4][SLP] usbd 2377 c5ac81b8 f514c000 0 2373 2373 0000000 [SLPQ - 0xc5a60e00][SLP] nfsd 2376 c665f1b8 f53f3000 0 2373 2373 0000000 [SLPQ - 0xc59d0c00][SLP] nfsd 2375 c5a37a50 f5015000 0 2373 2373 0000000 [SLPQ - 0xc6198600][SLP] nfsd 2374 c611f370 f52cb000 0 2373 2373 0000000 [SLPQ - 0xc59d0200][SLP] nfsd 2373 c5f5bdc0 f5220000 0 1 2373 0000000 [SLPQ select 0xc07569e4][SLP] nfsd 2358 c611fc08 f52d0000 0 1 2358 0000000 [SLPQ select 0xc07569e4][SLP] mountd 2340 c5f5b1b8 f51f5000 0 1 2340 0000000 [SLPQ select 0xc07569e4][SLP] amd 2298 c602a1b8 f5242000 0 1 2298 0000000 [SLPQ select 0xc07569e4][SLP] rpcbind 2238 c648f6e0 f538e000 0 1 2238 0000000 [SLPQ select 0xc07569e4][SLP] syslogd 2141 c5a376e0 f5013000 0 1 2141 0000000 [SLPQ pause 0xc5a37718][SLP] adjkerntz 159 c59d9898 f2db2000 0 0 0 0000204 [SLPQ - 0xeed04d18][SLP] schedcpu 158 c59d9a50 f2db3000 0 0 0 0000204 [SLPQ - 0xc075e36c][SLP] nfsiod 3 --More-- 157 c59d9c08 f2db4000 0 0 0 0000204 [SLPQ - 0xc075e368][SLP] nfsiod 2 156 c59d9dc0 f2db5000 0 0 0 0000204 [SLPQ - 0xc075e364][SLP] nfsiod 1 155 c54d86e0 eecf2000 0 0 0 0000204 [SLPQ - 0xc075e360][SLP] nfsiod 0 154 c54d8898 eecf3000 0 0 0 0000204 [SLPQ vlruwt 0xc54d8898][SLP] vnlru 153 c54d8a50 eecf4000 0 0 0 0000204 [SLPQ syncer 0xc0751344][SLP] syncer 152 c54d8c08 eecf5000 0 0 0 0000204 [SLPQ psleep 0xc0756f30][SLP] bufdaemon 151 c54d8dc0 eecf6000 0 0 0 000020c [SLPQ pgzero 0xc0764b28][SLP] pagezero 150 c5553000 eecf7000 0 0 0 0000204 [SLPQ psleep 0xc0764b80][SLP] vmdaemon 149 c55531b8 eecf8000 0 0 0 0000204 [SLPQ psleep 0xc0764b6c][SLP] pagedaemon 148 c5553370 eecf9000 0 0 0 0000204 [IWAIT] swi0: tty:sio 147 c5553528 eecfa000 0 0 0 0000204 [SLPQ usbevt 0xc55a8210][SLP] usb2 146 c55536e0 eecfb000 0 0 0 0000204 [SLPQ usbevt 0xc556d210][SLP] usb1 145 c5553898 eecfc000 0 0 0 0000204 [SLPQ usbtsk 0xc07496ac][SLP] usbtask 144 c5553a50 eecfd000 0 0 0 0000204 [SLPQ usbevt 0xc557a210][SLP] usb0 9 c5553c08 eecfe000 0 0 0 0000204 [SLPQ aifthd 0xc5553c08][SLP] aac0aif 8 c5553dc0 eecff000 0 0 0 0000204 [SLPQ actask 0xc085a4cc][SLP] acpi_task2 7 c5554000 eed00000 0 0 0 0000204 [SLPQ actask 0xc085a4cc][SLP] acpi_task1 6 c55541b8 eed01000 0 0 0 0000204 [SLPQ actask 0xc085a4cc][SLP] acpi_task0 143 c54bea50 eecbe000 0 0 0 0000204 [IWAIT] swi3: cambio 142 c54bec08 eecbf000 0 0 0 0000204 [IWAIT] swi2: camnet --More-- 141 c54bedc0 eecc0000 0 0 0 0000204 [IWAIT] swi5:+ 140 c54d6000 eecc1000 0 0 0 0000204 [IWAIT] swi7: acpitaskq 5 c54d61b8 eecc2000 0 0 0 0000204 [SLPQ - 0xc552f240][SLP] taskqueue 139 c54d6370 eecc3000 0 0 0 0000204 [IWAIT] swi6:+ 138 c54d6528 eecc4000 0 0 0 0000204 [IWAIT] swi7: task queue 137 c54d66e0 eecc5000 0 0 0 0000204 [SLPQ - 0xc0747560][SLP] yarrow 4 c54d6898 eecc6000 0 0 0 0000204 [SLPQ - 0xc074bcf0][SLP] g_down 3 c54d6a50 eecc7000 0 0 0 0000204 [SLPQ - 0xc074bcec][SLP] g_up 2 c54d6c08 eecc8000 0 0 0 0000204 [SLPQ - 0xc074bce4][SLP] g_event 136 c54d6dc0 eecc9000 0 0 0 0000204 [IWAIT] swi4: vm 135 c54d8000 eecca000 0 0 0 000020c [LOCK Giant c5ac26c0] swi8: tty:sio clock 134 c54d81b8 eeccb000 0 0 0 0000204 [IWAIT] swi1: net 133 c54d8370 eeccc000 0 0 0 0000204 [IWAIT] irq0: clk 132 c54d8528 eeccd000 0 0 0 0000204 [IWAIT] irq119: 131 c54a8dc0 eec8a000 0 0 0 0000204 [IWAIT] irq118: 130 c54bd000 eec8b000 0 0 0 0000204 [IWAIT] irq117: 129 c54bd1b8 eec8c000 0 0 0 0000204 [IWAIT] irq116: 128 c54bd370 eec8d000 0 0 0 0000204 [IWAIT] irq115: 127 c54bd528 eec8e000 0 0 0 0000204 [IWAIT] irq114: 126 c54bd6e0 eec8f000 0 0 0 0000204 [IWAIT] irq113: --More-- 125 c54bd898 eec90000 0 0 0 0000204 [IWAIT] irq112: 124 c54bda50 eec91000 0 0 0 0000204 [IWAIT] irq111: 123 c54bdc08 eec92000 0 0 0 0000204 [IWAIT] irq110: 122 c54bddc0 eec93000 0 0 0 0000204 [IWAIT] irq109: 121 c54be000 eec94000 0 0 0 0000204 [IWAIT] irq108: 120 c54be1b8 eec95000 0 0 0 0000204 [IWAIT] irq107: 119 c54be370 eec96000 0 0 0 0000204 [IWAIT] irq106: 118 c54be528 eec97000 0 0 0 0000204 [IWAIT] irq105: 117 c54be6e0 eec98000 0 0 0 0000204 [IWAIT] irq104: 116 c54be898 eec99000 0 0 0 0000204 [IWAIT] irq103: 115 c54931b8 eec32000 0 0 0 0000204 [IWAIT] irq102: 114 c5493370 eec33000 0 0 0 0000204 [IWAIT] irq101: 113 c5493528 eec34000 0 0 0 0000204 [IWAIT] irq100: 112 c54936e0 eec35000 0 0 0 0000204 [IWAIT] irq99: 111 c5493898 eec36000 0 0 0 0000204 [IWAIT] irq98: 110 c5493a50 eec37000 0 0 0 0000204 [IWAIT] irq97: 109 c5493c08 eec38000 0 0 0 0000204 [IWAIT] irq96: aac0 108 c5493dc0 eec39000 0 0 0 0000204 [IWAIT] irq95: 107 c54a8000 eec3a000 0 0 0 0000204 [IWAIT] irq94: 106 c54a81b8 eec3b000 0 0 0 0000204 [IWAIT] irq93: --More-- 105 c54a8370 eec3c000 0 0 0 0000204 [IWAIT] irq92: 104 c54a8528 eec3d000 0 0 0 0000204 [IWAIT] irq91: 103 c54a86e0 eec3e000 0 0 0 0000204 [IWAIT] irq90: 102 c54a8898 eec3f000 0 0 0 0000204 [IWAIT] irq89: 101 c54a8a50 eec40000 0 0 0 0000204 [IWAIT] irq88: 100 c54a8c08 eec41000 0 0 0 0000204 [IWAIT] irq87: 99 c5477528 eebfe000 0 0 0 0000204 [IWAIT] irq86: 98 c54776e0 eebff000 0 0 0 0000204 [IWAIT] irq85: 97 c5477898 eec00000 0 0 0 0000204 [IWAIT] irq84: 96 c5477a50 eec01000 0 0 0 0000204 [IWAIT] irq83: 95 c5477c08 eec02000 0 0 0 0000204 [IWAIT] irq82: 94 c5477dc0 eec03000 0 0 0 0000204 [IWAIT] irq81: 93 c5492000 eec04000 0 0 0 0000204 [IWAIT] irq80: 92 c54921b8 eec05000 0 0 0 0000204 [IWAIT] irq79: 91 c5492370 eec06000 0 0 0 0000204 [IWAIT] irq78: 90 c5492528 eec07000 0 0 0 0000204 [IWAIT] irq77: 89 c54926e0 eec08000 0 0 0 0000204 [IWAIT] irq76: 88 c5492898 eec09000 0 0 0 0000204 [IWAIT] irq75: 87 c5492a50 eec0a000 0 0 0 0000204 [IWAIT] irq74: 86 c5492c08 eec0b000 0 0 0 0000204 [IWAIT] irq73: --More-- 85 c5492dc0 eec0c000 0 0 0 0000204 [IWAIT] irq72: 84 c5493000 eec0d000 0 0 0 0000204 [IWAIT] irq71: 83 c5465a50 eebcb000 0 0 0 0000204 [IWAIT] irq70: 82 c5465c08 eebcc000 0 0 0 0000204 [IWAIT] irq69: 81 c5465dc0 eebcd000 0 0 0 0000204 [IWAIT] irq68: 80 c5475000 eebce000 0 0 0 0000204 [IWAIT] irq67: 79 c54751b8 eebcf000 0 0 0 0000204 [IWAIT] irq66: 78 c5475370 eebd0000 0 0 0 0000204 [IWAIT] irq65: 77 c5475528 eebd1000 0 0 0 0000204 [IWAIT] irq64: 76 c54756e0 eebd2000 0 0 0 0000204 [IWAIT] irq63: 75 c5475898 eebd3000 0 0 0 0000204 [IWAIT] irq62: 74 c5475a50 eebd4000 0 0 0 0000204 [IWAIT] irq61: 73 c5475c08 eebd5000 0 0 0 0000204 [IWAIT] irq60: 72 c5475dc0 eebd6000 0 0 0 0000204 [IWAIT] irq59: 71 c5477000 eebd7000 0 0 0 0000204 [IWAIT] irq58: 70 c54771b8 eebd8000 0 0 0 0000204 [IWAIT] irq57: 69 c5477370 eebd9000 0 0 0 0000204 [IWAIT] irq56: 68 c54571b8 eeb75000 0 0 0 0000204 [IWAIT] irq55: 67 c5457370 eeb76000 0 0 0 0000204 [IWAIT] irq54: 66 c5457528 eeb77000 0 0 0 0000204 [IWAIT] irq53: --More-- 65 c54576e0 eeb78000 0 0 0 0000204 [IWAIT] irq52: 64 c5457898 eeb79000 0 0 0 0000204 [IWAIT] irq51: 63 c5457a50 eeb7a000 0 0 0 0000204 [IWAIT] irq50: 62 c5457c08 eeb7b000 0 0 0 0000204 [IWAIT] irq49: 61 c5457dc0 eeb7c000 0 0 0 0000204 [IWAIT] irq48: 60 c5465000 eeb7d000 0 0 0 0000204 [IWAIT] irq47: 59 c54651b8 eeb7e000 0 0 0 0000204 [IWAIT] irq46: 58 c5465370 eeb7f000 0 0 0 0000204 [IWAIT] irq45: 57 c5465528 eeb80000 0 0 0 0000204 [IWAIT] irq44: 56 c54656e0 eeb81000 0 0 0 0000204 [IWAIT] irq43: 55 c5465898 eebca000 0 0 0 0000204 [IWAIT] irq42: 54 c5441a50 eeb44000 0 0 0 0000204 [IWAIT] irq41: 53 c5441c08 eeb45000 0 0 0 0000204 [IWAIT] irq40: 52 c5441dc0 eeb46000 0 0 0 0000204 [IWAIT] irq39: 51 c5455000 eeb47000 0 0 0 0000204 [IWAIT] irq38: 50 c54551b8 eeb48000 0 0 0 0000204 [IWAIT] irq37: 49 c5455370 eeb49000 0 0 0 0000204 [IWAIT] irq36: 48 c5455528 eeb4a000 0 0 0 0000204 [IWAIT] irq35: 47 c54556e0 eeb4b000 0 0 0 0000204 [IWAIT] irq34: 46 c5455898 eeb4c000 0 0 0 0000204 [IWAIT] irq33: --More-- 45 c5455a50 eeb4d000 0 0 0 0000204 [IWAIT] irq32: 44 c5455c08 eeb72000 0 0 0 0000204 [IWAIT] irq31: 43 c5455dc0 eeb73000 0 0 0 0000204 [IWAIT] irq30: 42 c5457000 eeb74000 0 0 0 0000204 [LOCK Giant c5ac26c0] irq29: em1 41 c5438528 eeb14000 0 0 0 0000204 [LOCK Giant c5ac26c0] irq28: em0 40 c54386e0 eeb15000 0 0 0 0000204 [IWAIT] irq27: 39 c5438898 eeb16000 0 0 0 0000204 [IWAIT] irq26: 38 c5438a50 eeb17000 0 0 0 0000204 [IWAIT] irq25: 37 c5438c08 eeb18000 0 0 0 0000204 [IWAIT] irq24: 36 c5438dc0 eeb19000 0 0 0 0000204 [IWAIT] irq23: 35 c5441000 eeb1a000 0 0 0 0000204 [IWAIT] irq22: 34 c54411b8 eeb3f000 0 0 0 0000204 [IWAIT] irq21: 33 c5441370 eeb40000 0 0 0 0000204 [IWAIT] irq20: 32 c5441528 eeb41000 0 0 0 0000204 [IWAIT] irq19: uhci1 31 c54416e0 eeb42000 0 0 0 0000204 [IWAIT] irq18: uhci2 30 c5441898 eeb43000 0 0 0 0000204 [IWAIT] irq17: ichsmb0 29 c53e61b8 ed0da000 0 0 0 0000204 [IWAIT] irq16: uhci0 28 c53e6370 ed0db000 0 0 0 0000204 [IWAIT] irq15: ata1 27 c53e6528 ed0dc000 0 0 0 0000204 [IWAIT] irq14: ata0 26 c53e66e0 ed0dd000 0 0 0 0000204 [IWAIT] irq13: --More-- 25 c53e6898 ed102000 0 0 0 0000204 [IWAIT] irq12: 24 c53e6a50 ed103000 0 0 0 0000204 [IWAIT] irq11: 23 c53e6c08 ed104000 0 0 0 0000204 [IWAIT] irq10: 22 c53e6dc0 ed105000 0 0 0 0000204 [IWAIT] irq9: acpi0 21 c5438000 eeb11000 0 0 0 0000204 [IWAIT] irq8: rtc 20 c54381b8 eeb12000 0 0 0 0000204 [IWAIT] irq7: 19 c5438370 eeb13000 0 0 0 0000204 [IWAIT] irq6: fdc0 18 c53df000 ed088000 0 0 0 0000204 [IWAIT] irq5: 17 c53df1b8 ed0d1000 0 0 0 0000204 [IWAIT] irq4: sio0 16 c53df370 ed0d2000 0 0 0 0000204 [IWAIT] irq3: sio1 15 c53df528 ed0d3000 0 0 0 0000204 [IWAIT] irq1: atkbd0 14 c53df6e0 ed0d4000 0 0 0 000020c [CPU 0] idle: cpu0 13 c53df898 ed0d5000 0 0 0 000020c [Can run] idle: cpu1 12 c53dfa50 ed0d6000 0 0 0 000020c [CPU 2] idle: cpu2 11 c53dfc08 ed0d7000 0 0 0 000020c [CPU 3] idle: cpu3 1 c53dfdc0 ed0d8000 0 0 1 0004200 [SLPQ wait 0xc53dfdc0][SLP] init 10 c53e6000 ed0d9000 0 0 0 0000204 [SLPQ ktrace 0xc074f558][SLP] ktrace 0 c074bde0 c0c1f000 0 0 0 0000200 [SLPQ sched 0xc074bde0][SLP] swapper oops, ran out of processes early! db> show all registers breaks thread watches pciregs intrcnt pgrpdump pcpu msgbuf cbstat buffer disk lockedvnods map procvm vmochk object vmopag page pageq cyrixreg irqs idt rtc db> show pcpu 0 cpuid = 0 curthread = 0xc53e0a80: pid 14 "idle: cpu0" curpcb = 0xed0a3da0 fpcurthread = none idlethread = 0xc53e0a80: pid 14 "idle: cpu0" APIC ID = 0 currentldt = 0x28 db> show pcpu 1 cpuid = 1 curthread = 0xc5aa0000: pid 2546 "master" curpcb = 0xf509fda0 fpcurthread = none idlethread = 0xc53e0930: pid 13 "idle: cpu1" APIC ID = 1 currentldt = 0x28 db> show pcpu 2 cpuid = 2 curthread = 0xc53e07e0: pid 12 "idle: cpu2" curpcb = 0xed09dda0 fpcurthread = none idlethread = 0xc53e07e0: pid 12 "idle: cpu2" APIC ID = 6 currentldt = 0x28 db> show pcpu 3 cpuid = 3 curthread = 0xc53e0690: pid 11 "idle: cpu3" curpcb = 0xed09ada0 fpcurthread = none idlethread = 0xc53e0690: pid 11 "idle: cpu3" APIC ID = 7 currentldt = 0x28 db> show all registers breaks thread watches pciregs intrcnt pgrpdump pcpu msgbuf cbstat buffer disk lockedvnods map procvm vmochk object vmopag page pageq cyrixreg irqs idt rtc db> show lockedvnoe des No such command db> chow lockedvnods No such command db> show lockedvnods Locked vnodes db> show rtc 04/06/13 00:29:11, A = 29, B = 42, C = d0 db> show rtc 04/06/13 00:29:14, A = 29, B = 42, C = d0 db> show registers cs 0x8 ds 0xed0a0010 es 0x10 fs 0x18 ss 0xc5540010 eax 0x1 ecx 0xc554d9c8 edx 0x2 ebx 0xc555a303 esp 0xed0a3c48 ebp 0xed0a3c58 esi 0xc554d800 edi 0x61 eip 0xc06716d8 siointr1+0xd0 efl 0x2 dr0 0 dr1 0 dr2 0 dr3 0 dr4 0xffff0ff0 dr5 0x400 dr6 0xffff0ff0 dr7 0x400 siointr1+0xd0: movl %edi,%edx db> show all registers breaks thread watches pciregs intrcnt pgrpdump pcpu msgbuf cbstat buffer disk lockedvnods map procvm vmochk object vmopag page pageq cyrixreg irqs idt rtc db> show thread Proc 0xc53df6e0 [CPU 0] idle: cpu0 siointr1(c554d800) at siointr1+0xd0 siointr(c554d800) at siointr+0x62 intr_execute_handlers(c53d9490,ed0a3ca4,4,ed0a3ce8,c0683ed3) at intr_execute_handlers+0x85 lapic_handle_intr(34) at lapic_handle_intr+0x2e Xapic_isr1() at Xapic_isr1+0x33 --- interrupt, eip = 0xc084cc49, esp = 0xed0a3ce8, ebp = 0xed0a3ce8 --- acpi_cpu_c1(0,0,1,4,c53e0a80) at acpi_cpu_c1+0x5 acpi_cpu_idle(ed0a3d20,c0531d05,c53df6e0,c0531cec,ed0a3d34) at acpi_cpu_idle+0xc1 cpu_idle(c53df6e0,c0531cec,ed0a3d34,c0531a7d,0) at cpu_idle+0x28 idle_proc(0,ed0a3d48) at idle_proc+0x19 fork_exit(c0531cec,0,ed0a3d48) at fork_exit+0x71 fork_trampoline() at fork_trampoline+0x8 --- trap 0x1, eip = 0, esp = 0xed0a3d7c, ebp = 0 --- db> show thread 1 bad thread addressdb> Proc 0xc53df6e0 [CPU 0] idle: cpu0 siointr1(c554d800) at siointr1+0xd0 db> ? Bad character ? db> show all registers breaks thread watches pciregs intrcnt pgrpdump pcpu msgbuf cbstat buffer disk lockedvnods map procvm vmochk object vmopag page pageq cyrixreg irqs idt rtc db> show disk usage: show disk/devicename db> show d aacd0s1a No such command db> show disk aacd0s1a Symbol not found db> show disk/aacd0s1a dev_t = 0xc5980c00 db> show map Fatal trap 12: page fault while in kernel mode cpuid = 0; apic id = 00 fault virtual address = 0x8d fault code = supervisor read, page not present instruction pointer = 0x8:0xc065671c stack pointer = 0x10:0xed0a3aa8 frame pointer = 0x10:0xed0a3ab4 code segment = base 0x0, limit 0xfffff, type 0x1b = DPL 0, pres 1, def32 1, gran 1 processor eflags = resume, IOPL = 0 current process = 14 (idle: cpu0) timeout stopping cpus kernel: type 12 trap, code=0 Stopped at siointr1+0xd0: movl %edi,%edx db> Task map 0xc06716d8: pmap=0x1d886ff, nentries=905904234, version=3960514536 Fatal trap 12: page fault while in kernel mode cpuid = 0; apic id = 00 fault virtual address = 0x741ca8d6 fault code = supervisor read, page not present instruction pointer = 0x8:0xc0656768 stack pointer = 0x10:0xed0a3aa8 frame pointer = 0x10:0xed0a3ab4 code segment = base 0x0, limit 0xfffff, type 0x1b = DPL 0, pres 1, def32 1, gran 1 processor eflags = resume, IOPL = 0 current process = 14 (idle: cpu0) timeout stopping cpus kernel: type 12 trap, code=0 Stopped at siointr1+0xd0: movl %edi,%edx db> Task map 0xc06716d8: pmap=0x1d886ff, nentries=905904234, version=3960514536 db> ~ Bad character ? db> Task map 0xc06716d8: pmap=0x1d886ff, nentries=905904234, version=3960514536 db> ~?~ Bad character ? db> s help print p examine x search set write w delete d break dwatch watch dhwatch hwatch step s continue c until next match trace where call show ps gdb reset kill watchdog panic ahd_set_unitahd_pause ahd_unpause ahd_in ahd_out db> call doadump Dumping 3839 MB 16 32 48 64 80 96 112 128 144 160 176 192 208 224 240 256 272 288 304 320 336 352 368 384 400 416 432 448 464 480 496 512 528 544 560 576 592 608 624 640 656 672 688 704 720 736 752 768 784 800 816 832 848 864 880 896 912 928 944 960 976 992 1008 1024 1040 1056 1072 1088 1104 1120 1136 1152 1168 1184 1200 1216 1232 1248 1264 1280 1296 1312 1328 1344 1360 1376 1392 1408 1424 1440 1456 1472 1488 1504 1520 1536 1552 1568 1584 1600 1616 1632 1648 1664 1680 1696 1712 1728 1744 1760 1776 1792 1808 1824 1840 1856 1872 1888 1904 1920 1936 1952 1968 1984 2000 2016 2032 2048 2064 2080 2096 2112 2128 2144 2160 2176 2192 2208 2224 2240 2256 2272 2288 2304 2320 2336 2352 2368 2384 2400 2416 2432 2448 2464 2480 2496 2512 2528 2544 2560 2576 2592 2608 2624 2640 2656 2672 2688 2704 2720 2736 2752 2768 2784 2800 2816 2832 2848 2864 2880 2896 2912 2928 2944 2960 2976 2992 3008 3024 3040 3056 3072 3088 3104 3120 3136 3152 3168 3184 3200 3216 3232 3248 3264 3280 3296 3312 3328 3344 3360 3376 3392 3408 3424 3440 3456 3472 3488 3504 3520 3536 3552 3568 3584 3600 3616 3632 3648 3664 3680 3696 3712 3728 3744 3760 3776 3792 3808 3824 Dump complete 0xf db> x ticks ticks: 33f08b0 db> c whoa, other_cpus: 0x0000000e, stopped_cpus: 0x00000004 timeout stopping cpus Stopped at siointr1+0xd0: movl %edi,%edx db> x ticks ticks: 33f162a db> x softticks softticks: 328c76a db> call cpu_reset cpu_reset called on cpu#0 cpu_reset: Stopping other CPUs telnet> quit Connection closed. Script done on Sun Jun 13 00:34:44 2004 From owner-freebsd-current@FreeBSD.ORG Sun Jun 13 06:47:15 2004 Return-Path: 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 E343716A4CE; Sun, 13 Jun 2004 06:47:15 +0000 (GMT) Received: from gw.catspoiler.org (217-ip-163.nccn.net [209.79.217.163]) by mx1.FreeBSD.org (Postfix) with ESMTP id 7AB0A43D46; Sun, 13 Jun 2004 06:47:15 +0000 (GMT) (envelope-from truckman@FreeBSD.org) Received: from FreeBSD.org (mousie.catspoiler.org [192.168.101.2]) by gw.catspoiler.org (8.12.11/8.12.11) with ESMTP id i5D6jF7q026079; Sat, 12 Jun 2004 23:45:19 -0700 (PDT) (envelope-from truckman@FreeBSD.org) Message-Id: <200406130645.i5D6jF7q026079@gw.catspoiler.org> Date: Sat, 12 Jun 2004 23:45:14 -0700 (PDT) From: Don Lewis To: rwatson@FreeBSD.org In-Reply-To: MIME-Version: 1.0 Content-Type: TEXT/plain; charset=us-ascii cc: current@FreeBSD.org cc: tjr@FreeBSD.org Subject: Re: Fatal trap 12 in kern/kern_descrip.c:2346 X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.1 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: Sun, 13 Jun 2004 06:47:16 -0000 On 13 Jun, Robert Watson wrote: > > On Sun, 13 Jun 2004, Tim Robbins wrote: > >> > Well, this is certainly a NULL pointer dereference in the sysctl code >> > exporting file descriptor information to user space (perhaps for fstat?). >> > The question is what is NULL. It looks like you have a dump -- could you >> > convert sysctl_kern_file+0x105 to a line number? It's likely that it is >> > line 2346 of kern_descrip.c, which follows the process pointer to its >> > ucred. If so, could you use gdb on the dump to inspect *p? >> >> ISTR he included the output of "print *p" on his web page. >> >> I think the problem here is that we put processes onto the allproc list >> in fork1() before they're properly initialised (or we unlock the allproc >> sx too early.) > > Hmm. I noticed, though, that p_flag is set to P_CONTROLT and P_WEXIT, so > my initial suspicion was actually exit1(). My initial suspicion was the kern_wait() code that sets p_ucred to NULL, but the process has been removed from allproc by that point. It also looks to me like fork1() is the culprit. The new process is put on allproc at line 410, allproc_lock is dropped at line 412, the process is locked at line 474, p_flag is cleared at line 509, and p_ucred is set at line 521. Another clue is the p_state is PRS_NEW. Based on this, I'd guess that sysctl_kern_file() is stumbling across this process while fork1() is somewhere between lines 412 and 474. I think the bzero()/bcopy() stuff has to happen before the new process is added to allproc and p_ucred is set, otherwise there is the possibility of an information leak between jails (p_comm[], etc.). Why is sched_fork() called so early? From owner-freebsd-current@FreeBSD.ORG Sun Jun 13 07:43:42 2004 Return-Path: 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 729C416A4CE for ; Sun, 13 Jun 2004 07:43:42 +0000 (GMT) Received: from tt.home.takagikun.org (d229183.ppp.asahi-net.or.jp [210.253.229.183]) by mx1.FreeBSD.org (Postfix) with SMTP id 4861D43D2F for ; Sun, 13 Jun 2004 07:43:36 +0000 (GMT) (envelope-from takagi@lai.kyutech.ac.jp) Received: (qmail 34715 invoked from network); 13 Jun 2004 07:41:37 -0000 Received: from a3.home.takagikun.org (HELO localhost) (192.168.0.103) by tt.home.takagikun.org with SMTP; 13 Jun 2004 07:41:37 -0000 Date: Sun, 13 Jun 2004 16:41:35 +0900 (JST) Message-Id: <20040613.164135.71090668.kazu@takagikun.org> To: freebsd-current@freebsd.org From: Kazu TAKAGI X-Face: /':hS/(KOw@c>{z~_2=|&8f):=gQ0%t@8L'[vRlNZFx+}P.R$oyjH!x#.]V)]=`L[&qq0A\ Qi>0sr87$pX_S/&&k)zpOe>uLF!&R!G'0WE?l_{}TC0N75S$'!y\:We<"'5aSFm/P1nyR}}Wx]\CPd nVOng7G;Dbi(Q7NjPtgsU$/`./h4<4-bKE+Ay9GbjX4RLdtP]2IuF.YF; ,to]Ajz%vw/YcaV2PGJ>q Nv8)& X-cite-me: kazu X-Mailer: Mew version 3.3 on Emacs 21.3 / Mule 5.0 =?iso-2022-jp?B?KBskQjgtTFobKEIp?= Mime-Version: 1.0 Content-Type: Text/Plain; charset=us-ascii Content-Transfer-Encoding: 7bit Subject: SiI3512 status? X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.1 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: Sun, 13 Jun 2004 07:43:42 -0000 Dear Sirs: MB: Gigabyte GA-7N400 Pro2 ATA-controller: Silicon Image Sil3512 HDD: Seagate ST3200822AS x2 RAID: RAID0 FreeBSD version: 5.2-CURRENT #0: Sun Jun 13 00:25:11 JST 2004 dmesg: atapci1: port 0xdc00-0xdc0f,0xd800-0xd803,0xd400-0xd407,0xd000-0xd003,0xcc00-0xcc07mem 0xea024000-0xea0241ff irq 10 at device 13.0 on pci1 ar0: 381564MB [48642/255/63] status: READY subdisks: disk0 READY on ad8 at ata4-master disk1 READY on ad10 at ata5-master above is my environment. Disk access like newfs often causes RAID breakage or system freeze with the following messages: WARNING - WRITE_DMA UDMA ICRC error (retrying request) LBA=29936146 TIMEOUT - WRITE_DMA retrying (2 retries left) LBA=16128 Any help or any suggestion? Thanks. Kazu TAKAGI From owner-freebsd-current@FreeBSD.ORG Sun Jun 13 08:40:56 2004 Return-Path: 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 5DACF16A4CE for ; Sun, 13 Jun 2004 08:40:56 +0000 (GMT) Received: from hellhound.ceribus.net (c-24-21-92-61.client.comcast.net [24.21.92.61]) by mx1.FreeBSD.org (Postfix) with ESMTP id CDB1143D39 for ; Sun, 13 Jun 2004 08:40:55 +0000 (GMT) (envelope-from grover@ceribus.net) Received: (qmail 37580 invoked by uid 1003); 13 Jun 2004 08:38:52 -0000 Received: from grover@ceribus.net by hellhound.ceribus.net by uid 89 with qmail-scanner-1.22 (clamscan: 0.72. spamassassin: 2.63. Clear:RC:1(192.168.200.200):. Processed in 1.41014 secs); 13 Jun 2004 08:38:52 -0000 Received: from unknown (HELO purgatory) (192.168.200.200) by 192.168.200.225 with SMTP; 13 Jun 2004 08:38:50 -0000 From: "Grover Lines" To: Date: Sun, 13 Jun 2004 01:38:45 -0700 MIME-Version: 1.0 Content-Type: text/plain; charset="US-ASCII" Content-Transfer-Encoding: 7bit X-Mailer: Microsoft Office Outlook, Build 11.0.5510 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2800.1409 Thread-Index: AcRRIdaTPBsrtcLwQlePoDBr6Q0Pwg== X-Qmail-Scanner-Message-ID: <108711593067237574@hellhound.ceribus.net> Message-Id: <20040613084055.CDB1143D39@mx1.FreeBSD.org> Subject: Interupt storms while printing X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.1 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: Sun, 13 Jun 2004 08:40:56 -0000 I'm using a duron 1200, and every time I try to print, I get Interrupt storm detected on "irq7: lpt0"; throttling interrupt source I've also tried every variation of lptcontrol(8) with no luck Any ideas? hellhound# vmstat -i interrupt total rate irq0: clk 578131 99 irq1: atkbd0 4 0 irq7: lpt0 83291 14 stray irq7 1 0 irq8: rtc 739979 127 irq10: sis0 166862 28 irq13: npx0 1 0 irq14: ata0 69784 12 irq15: ata1 3438 0 Total 1641491 283 From owner-freebsd-current@FreeBSD.ORG Sun Jun 13 08:56:32 2004 Return-Path: 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 9819916A4CE for ; Sun, 13 Jun 2004 08:56:32 +0000 (GMT) Received: from cell.sick.ru (cell.sick.ru [217.72.144.68]) by mx1.FreeBSD.org (Postfix) with ESMTP id 9F54343D1F for ; Sun, 13 Jun 2004 08:56:31 +0000 (GMT) (envelope-from glebius@cell.sick.ru) Received: from cell.sick.ru (glebius@localhost [127.0.0.1]) by cell.sick.ru (8.12.9/8.12.8) with ESMTP id i5D8tQu1011610 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO) for ; Sun, 13 Jun 2004 12:55:27 +0400 (MSD) (envelope-from glebius@cell.sick.ru) Received: (from glebius@localhost) by cell.sick.ru (8.12.9/8.12.6/Submit) id i5D8tQhR011609 for current@freebsd.org; Sun, 13 Jun 2004 12:55:26 +0400 (MSD) Date: Sun, 13 Jun 2004 12:55:26 +0400 From: Gleb Smirnoff To: current@freebsd.org Message-ID: <20040613085526.GA11577@cell.sick.ru> Mime-Version: 1.0 Content-Type: text/plain; charset=koi8-r Content-Disposition: inline User-Agent: Mutt/1.5.6i Subject: panic: kmem_malloc(4096) on an SMP box X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.1 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: Sun, 13 Jun 2004 08:56:32 -0000 Today we have evidenced a panic on a DELL PowerEdge 1400 with two processors on board: panic: kmem_malloc(4096): kmem_map too small: 209715200 total allocated cpuid = 0; I have dump saved, so I'll be glad to feed anyone with information to help fix this issue. backtrace: (kgdb) bt #0 doadump () at /usr/src/sys/kern/kern_shutdown.c:236 #1 0xc0446a05 in db_fncall (dummy1=0, dummy2=0, dummy3=0, dummy4=0xdbd1a67c "") at /usr/src/sys/ddb/db_command.c:551 #2 0xc0446752 in db_command (last_cmdp=0xc06a3ea0, cmd_table=0x0, aux_cmd_tablep=0xc0674b88, aux_cmd_tablep_end=0xc0674b8c) at /usr/src/sys/ddb/db_command.c:348 #3 0xc0446895 in db_command_loop () at /usr/src/sys/ddb/db_command.c:475 #4 0xc04499f5 in db_trap (type=3, code=0) at /usr/src/sys/ddb/db_trap.c:73 #5 0xc060e8cc in kdb_trap (type=3, code=0, regs=0xdbd1a7d0) at /usr/src/sys/i386/i386/db_interface.c:159 #6 0xc0623e28 in trap (frame= {tf_fs = -1068498920, tf_es = -1067057136, tf_ds = -1067122672, tf_edi = -1067022542, tf_esi = 1, tf_ebp = -607016932, tf_isp = -607016964, tf_ebx = 0, tf_edx = 0, tf_ecx = -1061076992, tf_eax = 18, tf_trapno = 3, tf_err = 0, tf_eip = -1067389995, tf_cs = 8, tf_eflags = 658, tf_esp = -1067002619, tf_ss = -1067087802}) at /usr/src/sys/i386/i386/trap.c:579 #7 0xc060ebd5 in Debugger (msg=0x0) at machine/cpufunc.h:56 #8 0xc04e34b6 in panic ( fmt=0xc0668732 "kmem_malloc(%ld): kmem_map too small: %ld total allocated") at /usr/src/sys/kern/kern_shutdown.c:532 #9 0xc05d2cbb in kmem_malloc (map=0xc0c3a0a0, size=4096, flags=258) at /usr/src/sys/vm/vm_kern.c:324 #10 0xc05e4367 in page_alloc (zone=0xc1ee9580, bytes=0, pflag=0x0, wait=0) at /usr/src/sys/vm/uma_core.c:892 #11 0xc05e3ffd in slab_zalloc (zone=0xc1ee9580, wait=258) at /usr/src/sys/vm/uma_core.c:789 #12 0xc05e570a in uma_zone_slab (zone=0xc1ee9580, flags=2) at /usr/src/sys/vm/uma_core.c:1772 #13 0xc05e594f in uma_zalloc_bucket (zone=0xc1ee9580, flags=2) at /usr/src/sys/vm/uma_core.c:1875 #14 0xc05e55ad in uma_zalloc_arg (zone=0xc1ee9580, udata=0x0, flags=2) at /usr/src/sys/vm/uma_core.c:1699 #15 0xc05bae4c in ffs_vget (mp=0xc1dfcc00, ino=3111815, flags=2, vpp=0xdbd1aa4c) at /usr/src/sys/vm/uma.h:270 #16 0xc05c2bb2 in ufs_lookup (ap=0xdbd1ab10) at /usr/src/sys/ufs/ufs/ufs_lookup.c:599 #17 0xc05c9d98 in ufs_vnoperate (ap=0x0) at /usr/src/sys/ufs/ufs/ufs_vnops.c:2819 #18 0xc0535191 in vfs_cache_lookup (ap=0x0) at vnode_if.h:82 #19 0xc05c9d98 in ufs_vnoperate (ap=0x0) at /usr/src/sys/ufs/ufs/ufs_vnops.c:2819 #20 0xc053a292 in lookup (ndp=0xdbd1ac28) at vnode_if.h:52 #21 0xc0539c7e in namei (ndp=0xdbd1ac28) at /usr/src/sys/kern/vfs_lookup.c:179 #22 0xc0546bd2 in lstat (td=0xc1d08840, uap=0xdbd1ad14) at /usr/src/sys/kern/vfs_syscalls.c:2059 #23 0xc06247b0 in syscall (frame= {tf_fs = 134545455, tf_es = 134545455, tf_ds = -1078001617, tf_edi = 134570496, tf_esi = 134570568, tf_ebp = -1077941080, tf_isp = -607015564, tf_ebx = 672438156, tf_edx = 134561792, tf_ecx = 134561792, tf_eax = 190, tf_trapno = 0, tf_err = 2, tf_eip = 671910239, tf_cs = 31, tf_eflags = 582, tf_esp = -1077941236, tf_ss = 47}) at /usr/src/sys/i386/i386/trap.c:1004 #24 0x280c895f in ?? () ---Can't read userspace from dump, or kernel process--- -- Totus tuus, Glebius. GLEBIUS-RIPN GLEB-RIPE From owner-freebsd-current@FreeBSD.ORG Sun Jun 13 11:26:15 2004 Return-Path: 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 6D8DB16A4CE; Sun, 13 Jun 2004 11:26:15 +0000 (GMT) Received: from moutng.kundenserver.de (moutng.kundenserver.de [212.227.126.171]) by mx1.FreeBSD.org (Postfix) with ESMTP id D964043D39; Sun, 13 Jun 2004 11:26:14 +0000 (GMT) (envelope-from max@love2party.net) Received: from [212.227.126.209] (helo=mrelayng.kundenserver.de) by moutng.kundenserver.de with esmtp (Exim 3.35 #1) id 1BZMz4-00022G-00; Sun, 13 Jun 2004 06:52:42 +0200 Received: from [80.131.157.223] (helo=donor.laier.local) by mrelayng.kundenserver.de with asmtp (TLSv1:RC4-MD5:128) (Exim 3.35 #1) id 1BZMz3-0004FE-00; Sun, 13 Jun 2004 06:52:42 +0200 From: Max Laier To: current@freebsd.org Date: Sun, 13 Jun 2004 06:53:30 +0200 User-Agent: KMail/1.6.2 MIME-Version: 1.0 Content-Type: multipart/signed; protocol="application/pgp-signature"; micalg=pgp-sha1; boundary="Boundary-02=_T39yA0DijV64XFm"; charset="us-ascii" Content-Transfer-Encoding: 7bit Message-Id: <200406130653.39527.max@love2party.net> X-Provags-ID: kundenserver.de abuse@kundenserver.de auth:e28873fbe4dbe612ce62ab869898ff08 cc: pf4freebsd@freelists.org cc: net@freebsd.org Subject: HEADSUP: About to link ALTQ to the build (ABI break) X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.1 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: Sun, 13 Jun 2004 11:26:15 -0000 --Boundary-02=_T39yA0DijV64XFm Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Content-Disposition: inline All, as some might know, I recently imported the ALTQ framework with the=20 perspective to replace the existing queueing with this advanced system. Whi= le=20 ALTQ is designed in a fashion to be API compatible with the old "struct=20 ifqueue" it does break the ABI by chaning the size of ifnet.if_snd! I am now ready to commit this change. During the first commit I will not=20 change the queueing at all. It will only change the if_snd member of struct= =20 ifnet and bring in new macros and some build glue. In a next step I will convert the various if_output routines (in if_*subr.c= )=20 to use the new ENQUEUE/HANDOFF operations. The final step then is to convert the network drivers to use the new DEQUEU= E=20 operations and to flip the per-driver flag that indicates that the driver i= s=20 ready for ATLQ. The new DEQUEUE operation also bring along some extra candy in terms of=20 reducing locking overhead: It will now be possible to do "bulk dequeues" i.= e.=20 transfering more than one packet from the system to the driver with only on= e=20 lock operation. The amount of packets transfered at once is tuneable.=20 Enabling ALTQ on a device will disable bulk dequeue to avoid irritations wi= th=20 the timing, though. The patch is at: http://people.freebsd.org/~mlaier/altq.patch I plan to commit this Sunday night(CEST) provided that no problems occure w= ith=20 the newly merged socket locking et al. =2D-=20 Best regards, | mlaier@freebsd.org Max Laier | ICQ #67774661 http://pf4freebsd.love2party.net/ | mlaier@EFnet --Boundary-02=_T39yA0DijV64XFm Content-Type: application/pgp-signature Content-Description: signature -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.2.4 (FreeBSD) iD8DBQBAy93TXyyEoT62BG0RAmc1AJ4uAFXap5L+YQRT837vwz09jwyL5wCdEs/I QIpAkX/2yjEiexOQELuVHSE= =C+rD -----END PGP SIGNATURE----- --Boundary-02=_T39yA0DijV64XFm-- From owner-freebsd-current@FreeBSD.ORG Sat Jun 12 21:52:48 2004 Return-Path: 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 9D0FF16A4CE for ; Sat, 12 Jun 2004 21:52:48 +0000 (GMT) Received: from web41107.mail.yahoo.com (web41107.mail.yahoo.com [66.218.93.23]) by mx1.FreeBSD.org (Postfix) with SMTP id 8066143D4C for ; Sat, 12 Jun 2004 21:52:48 +0000 (GMT) (envelope-from jmkatcher@yahoo.com) Message-ID: <20040612215146.75313.qmail@web41107.mail.yahoo.com> Received: from [24.18.54.216] by web41107.mail.yahoo.com via HTTP; Sat, 12 Jun 2004 14:51:46 PDT Date: Sat, 12 Jun 2004 14:51:46 -0700 (PDT) From: Jeffrey Katcher To: Eric Anholt In-Reply-To: <1087061950.81204.52.camel@leguin> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii X-Mailman-Approved-At: Sun, 13 Jun 2004 11:40:38 +0000 cc: freebsd-current@freebsd.org Subject: Re: Possible Weirdness with new DRI import? X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.1 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: Sat, 12 Jun 2004 21:52:48 -0000 > Is the DRI still working? > > http://dri.sourceforge.net/cgi-bin/moin.cgi/DriTroubleshooting > Yes, and I get all the right messages including: (II) RADEON(0): Direct rendering enabled It's just a third the speed it used to be... Jeff __________________________________ Do you Yahoo!? Friends. Fun. Try the all-new Yahoo! Messenger. http://messenger.yahoo.com/ From owner-freebsd-current@FreeBSD.ORG Sat Jun 12 22:13:23 2004 Return-Path: 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 8097016A4CE for ; Sat, 12 Jun 2004 22:13:23 +0000 (GMT) Received: from mail.geek.sh (decoder.geek.sh [196.36.198.81]) by mx1.FreeBSD.org (Postfix) with ESMTP id D33C443D54 for ; Sat, 12 Jun 2004 22:13:22 +0000 (GMT) (envelope-from aragon@geek.sh) Received: by mail.geek.sh (Postfix, from userid 1000) id A97FE24D14; Sun, 13 Jun 2004 00:12:31 +0200 (SAST) Date: Sun, 13 Jun 2004 00:12:31 +0200 From: Aragon Gouveia To: Doug White Message-ID: <20040612221231.GA50196@phat.za.net> References: <20040611152223.GA81299@phat.za.net> <20040612133330.Y74026@carver.gumbysoft.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20040612133330.Y74026@carver.gumbysoft.com> User-Agent: Mutt/1.4i X-Operating-System: FreeBSD 4.8-RELEASE-p1 i386 X-Mailman-Approved-At: Sun, 13 Jun 2004 11:40:38 +0000 cc: current@freebsd.org Subject: Re: kernel compile error, 5.2.1-RELEASE X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.1 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: Sat, 12 Jun 2004 22:13:23 -0000 | By Doug White | [ 2004-06-12 22:58 +0200 ] > On Fri, 11 Jun 2004, Aragon Gouveia wrote: > > > Just trying to get a kernel built on a 5.2.1-RELEASE box. Am encountering > > this error: > > > > cc -c -O -pipe -march=pentiumpro -Wall -Wredundant-decls -Wnested-externs -Wstrict-prototypes -Wmissing-prototypes -Wpointer-arith -Winline -Wcast-qual -fformat-extensions -std=c99 -nostdinc -I- -I. -I/usr/src/sys -I/usr/src/sys/contrib/dev/acpica -I/usr/src/sys/contrib/ipfilter -I/usr/src/sys/contrib/dev/ath -I/usr/src/sys/contrib/dev/ath/freebsd -I/usr/src/sys/contrib/ngatm -D_KERNEL -include opt_global.h -fno-common -finline-limit=15000 -fno-strict-aliasing -mno-align-long-strings -mpreferred-stack-boundary=2 -ffreestanding -Werror /usr/src/sys/dev/fb/vga.c > > /usr/src/sys/dev/fb/vga.c:1346: warning: `filll_io' defined but not used > > /usr/src/sys/dev/fb/vga.c:1336: warning: `fill' defined but not used > > Do you have 'options VGA_NO_MODE_CHANGE' in your kernel config? If so, > then I see that there are a couple of function defs in sys/dev/fb/vga.c > that aren't removed by that option. Yes. I tried recompiling now without the option and it completed. Will keep it without the option for now. Thanks in advance for patching! :) Regards, Aragon From owner-freebsd-current@FreeBSD.ORG Sat Jun 12 22:21:21 2004 Return-Path: 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 4CE2216A4CE for ; Sat, 12 Jun 2004 22:21:21 +0000 (GMT) Received: from mail.geek.sh (decoder.geek.sh [196.36.198.81]) by mx1.FreeBSD.org (Postfix) with ESMTP id D7B3B43D2F for ; Sat, 12 Jun 2004 22:21:20 +0000 (GMT) (envelope-from aragon@geek.sh) Received: by mail.geek.sh (Postfix, from userid 1000) id CAE0624D13; Sun, 13 Jun 2004 00:21:10 +0200 (SAST) Date: Sun, 13 Jun 2004 00:21:10 +0200 From: Aragon Gouveia To: Doug White Message-ID: <20040612222110.GB50196@phat.za.net> References: <20040611152223.GA81299@phat.za.net> <20040612133330.Y74026@carver.gumbysoft.com> <20040612150955.O74026@carver.gumbysoft.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20040612150955.O74026@carver.gumbysoft.com> User-Agent: Mutt/1.4i X-Operating-System: FreeBSD 4.8-RELEASE-p1 i386 X-Mailman-Approved-At: Sun, 13 Jun 2004 11:40:38 +0000 cc: current@freebsd.org Subject: Re: kernel compile error, 5.2.1-RELEASE X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.1 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: Sat, 12 Jun 2004 22:21:21 -0000 | By Doug White | [ 2004-06-13 00:10 +0200 ] > Please try the attached patch and see if that makes the warning go away. I'm getting the following output when patching: --- Hmm... Looks like a unified diff to me... The text leading up to this was: -------------------------- |--- vga.c.orig Sat Jun 12 13:51:48 2004 |+++ vga.c Sat Jun 12 14:18:28 2004 -------------------------- Patching file vga.c using Plan A... Hunk #1 succeeded at 471. Hunk #2 succeeded at 500 with fuzz 2. Hunk #3 failed at 1330. Hunk #4 succeeded at 1350 with fuzz 1. 1 out of 4 hunks failed--saving rejects to vga.c.rej done --- Contents of vga.c.rej: --- *************** *** 1330,1335 **** return 0; } #if defined(__i386__) || defined(__amd64__) /* XXX */ static void fill(int val, void *d, size_t size) --- 1330,1336 ---- return 0; } + #ifndef VGA_NO_MODE_CHANGE #if defined(__i386__) || defined(__amd64__) /* XXX */ static void fill(int val, void *d, size_t size) --- Regards, Aragon From owner-freebsd-current@FreeBSD.ORG Sat Jun 12 22:35:09 2004 Return-Path: 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 9CE0916A4D2 for ; Sat, 12 Jun 2004 22:35:09 +0000 (GMT) Received: from mail.geek.sh (decoder.geek.sh [196.36.198.81]) by mx1.FreeBSD.org (Postfix) with ESMTP id B6EC343D31 for ; Sat, 12 Jun 2004 22:35:04 +0000 (GMT) (envelope-from aragon@geek.sh) Received: by mail.geek.sh (Postfix, from userid 1000) id 9949A24D13; Sun, 13 Jun 2004 00:34:43 +0200 (SAST) Date: Sun, 13 Jun 2004 00:34:43 +0200 From: Aragon Gouveia To: Doug White Message-ID: <20040612223443.GC50196@phat.za.net> References: <20040611152223.GA81299@phat.za.net> <20040612133330.Y74026@carver.gumbysoft.com> <20040612150955.O74026@carver.gumbysoft.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20040612150955.O74026@carver.gumbysoft.com> User-Agent: Mutt/1.4i X-Operating-System: FreeBSD 4.8-RELEASE-p1 i386 X-Mailman-Approved-At: Sun, 13 Jun 2004 11:40:38 +0000 cc: current@freebsd.org Subject: Re: kernel compile error, 5.2.1-RELEASE X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.1 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: Sat, 12 Jun 2004 22:35:09 -0000 Disregard my last reply please. I fried the diff by copy/pasting instead of saving/scping. Kernel is compiling with 'options VGA_NO_MODE_CHANGE' without error. Thank you :) Regards, Aragon | By Doug White | [ 2004-06-13 00:10 +0200 ] > Please try the attached patch and see if that makes the warning go away. > From owner-freebsd-current@FreeBSD.ORG Sun Jun 13 13:19:58 2004 Return-Path: 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 AA46816A4CE for ; Sun, 13 Jun 2004 13:19:58 +0000 (GMT) Received: from chello080110061116.502.15.vie.surfer.at (chello080110061116.502.15.vie.surfer.at [80.110.61.116]) by mx1.FreeBSD.org (Postfix) with SMTP id 1E89143D41 for ; Sun, 13 Jun 2004 13:19:55 +0000 (GMT) (envelope-from 4711@chello.at) Received: (qmail 41216 invoked from network); 13 Jun 2004 13:19:12 -0000 Received: from matrix010.matrix.net (192.168.123.10) by ns.matrix.net with SMTP; 13 Jun 2004 13:19:12 -0000 From: Christian Hiris <4711@chello.at> To: freebsd-current@freebsd.org Date: Sun, 13 Jun 2004 15:18:59 +0200 User-Agent: KMail/1.6.2 References: <20040612232725.N35614@leelou.in.tern> In-Reply-To: <20040612232725.N35614@leelou.in.tern> MIME-Version: 1.0 Content-Type: multipart/signed; protocol="application/pgp-signature"; micalg=pgp-sha1; boundary="Boundary-02=_PRFzAzb88+iyri2"; charset="iso-8859-1" Content-Transfer-Encoding: 7bit Message-Id: <200406131519.11988.4711@chello.at> cc: Lukas Ertl Subject: Re: HEADSUP: geom_vinum committed [Fatal trap 12 (g_event)] X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.1 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: Sun, 13 Jun 2004 13:19:59 -0000 --Boundary-02=_PRFzAzb88+iyri2 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Content-Disposition: inline On Saturday 12 June 2004 23:28, Lukas Ertl wrote: > Dear hackers, > > I've just committed a first geomified version of vinum, surprisingly > called geom_vinum. > > Bug reports, suggestions, critics and flames are happily awaited, even > more so when they have patches attached. :-) > > Thanks, > le =46irst - many, many thanks for such a nice surprise :-)) and your work! I really must gave our brand new geomified gvinum module a first try on a t= est=20 machine. This machine holds on an existing vinum striped volume, which was= =20 created by old, ungeomfied vinum. =46irst fsck and mounting the filesystem went fine and I could read data fr= om=20 the vinum volume's ufs2 filesystem. Unmounting the filesystem then panics the machine. I rebooted, did a 'fsck = =2Dt=20 ufs /dev/gvinum/vinum0', which results in a Fatal trap 12. So next I=20 recompiled kernel with the geom_subr.c.diff patch and debugging symbols.=20 After installing the new kernels I tried fscking again: Sometimes fsck on t= he=20 gvinum volume's filesystem works and i can mount the filesystem, but mostly= =20 I'm lost in the fatal trap before fsck could issue any of it's messages. Th= e=20 old vinum kld still works fine, even after the panics of the geomified kld. Some of the output and config data: =20 Vinum config: matrix020# cat /etc/vinum.config # Vinum configuration of matrix020.matrix.net, saved at Sat May 29 22:46:40= =20 2004 drive vinumdrive1 device /dev/da1s1h drive vinumdrive0 device /dev/da0s1h volume vinum0 plex name vinum0.p0 org striped 558s vol vinum0 sd name vinum0.p0.s0 drive vinumdrive0 plex vinum0.p0 len 35840340s=20 driveoffset 265s plexoffset 0s sd name vinum0.p0.s1 drive vinumdrive1 plex vinum0.p0 len 35840340s=20 driveoffset 265s plexoffset 558s Console Output: =20 Sun Jun 13 13:20:36 CEST 2004 =46OO: sd vinum0.p0.s1 is up =46OO: sd vinum0.p0.s0 is up (from 'gvinum start') =46OO: sd vinum0.p0.s1 is up =46OO: plex vinum0.p0 is up =46OO: sd vinum0.p0.s0 is up =46OO: plex vinum0.p0 is up (from 'fsck -t ufs /dev/gvinum/vinum0') ddb output: =46atal trap 12: page fault while in kernel mode cpuid =3D 0; apic id =3D 00 fault virtual address =3D 0xe fault code =3D supervisor read, page not present instruction pointer =3D 0x8:0xc051bafc stack pointer =3D 0x10:0xd7e65c7c frame pointer =3D 0x10:0xd7e65c88 code segment =3D base 0x0, limit 0xfffff, type 0x1b =3D DPL 0, pres 1, def32 1, gran 1 processor eflags =3D interrupt enabled, resume, IOPL =3D 0 current process =3D 2 (g_event) kernel: type 12 trap, code=3D0 Stopped at redo_rank+0x70: cmpl $0,0xc(%edx) db> trace redo_rank(c2398e80,c1e63d80,d7e65cb0,c051b783,c1e63d80) at redo_rank+0x70 g_detach(c1e63d80,c2398e80,4,0,d7e65cd8) at g_detach+0x67 g_wither_geom(c2398e80,6,c20fc660,1,c06eb40d) at g_wither_geom+0xab g_slice_spoiled(c1e63d80) at g_slice_spoiled+0x30 g_spoil_event(c1e09400,0) at g_spoil_event+0x30 one_event(d7e65d20,c051a58d,4b0,320,c1bf1898) at one_event+0x192 g_run_events(4b0,320,c1bf1898,c051a56c,d7e65d34) at g_run_events+0x9 g_event_procbody(0,d7e65d48) at g_event_procbody+0x21 fork_exit(c051a56c,0,d7e65d48) at fork_exit+0x71 fork_trampoline() at fork_trampoline+0x8 =2D-- trap 0x1, eip =3D 0, esp =3D 0xd7e65d7c, ebp =3D 0 --- db> show registers cs 0x8 ds 0xd7e60010 es 0x10 fs 0xd7e60018 ss 0x10 eax 0xc22fac18 ecx 0xc22fcd00 edx 0x2 ebx 0x1 esp 0xd7e65c7c ebp 0xd7e65c88 esi 0xc22fcd00 edi 0xc2398e80 eip 0xc051bafc redo_rank+0x70 efl 0x10202 dr0 0 dr1 0 dr2 0 dr3 0 dr4 0xffff0ff0 dr5 0x400 dr6 0xffff0ff0 dr7 0x400 redo_rank+0x70: cmpl $0,0xc(%edx) db> ps pid proc uarea uid ppid pgrp flag stat wmesg wchan cmd 699 c22d7000 df092000 0 679 699 0004002 [SLPQ g_waitidle 0xc0764ec= 0] [SLP] fsck_ffs 679 c20856e0 df036000 0 663 679 0004002 [SLPQ pause 0xc2085718][SL= P]=20 csh 678 c2085898 df037000 92 604 678 0004000 [SLPQ select 0xc0774584][S= LP]=20 gdmgreeter 670 c22d76e0 df096000 0 1 670 0004002 [SLPQ ttyin 0xc1cb5c10][SL= P]=20 getty 669 c22d7898 df097000 0 1 669 0004002 [SLPQ ttyin 0xc1cb5e10][SL= P]=20 getty 668 c22d7a50 df098000 0 1 668 0004002 [SLPQ ttyin 0xc1ced010][SL= P]=20 getty 667 c22d7c08 df099000 0 1 667 0004002 [SLPQ ttyin 0xc1ced210][SL= P]=20 getty 666 c22d7dc0 df09a000 0 1 666 0004002 [SLPQ ttyin 0xc1ced410][SL= P]=20 getty 665 c22d9000 df09b000 0 1 665 0004002 [SLPQ ttyin 0xc1ced610][SL= P]=20 getty 664 c2082dc0 df031000 0 1 664 0004002 [SLPQ ttyin 0xc1ced810][SL= P]=20 getty 663 c1e761b8 dd9ca000 0 1 663 0004102 [SLPQ wait 0xc1e761b8][SLP= ]=20 login 653 c2085000 df032000 0 1 653 0000000 [SLPQ select 0xc0774584][S= LP]=20 inetd 626 c1e76c08 dd9d0000 0 1 626 0000000 [SLPQ select 0xc0774584][S= LP]=20 moused 609 c2082c08 df00f000 0 604 609 0004000 [SLPQ select 0xc0774584][S= LP]=20 XFree86 604 c2082a50 df00e000 0 601 604 0000100 [SLPQ piperd 0xc1eac2f0][S= LP]=20 gdm-binary 601 c1e76dc0 dd9d1000 0 1 601 0000100 [SLPQ select 0xc0774584][S= LP]=20 gdm-binary 600 c1e76a50 dd9cf000 80 540 540 0000100 [SLPQ accept 0xc1f59c92][S= LP]=20 httpd 599 c20821b8 df009000 80 540 540 0000100 [SLPQ accept 0xc1f59c92][S= LP]=20 httpd 598 c2085370 df034000 80 540 540 0000100 [SLPQ accept 0xc1f59c92][S= LP]=20 httpd 597 c1c8ac08 d9487000 80 540 540 0000100 [SLPQ accept 0xc1f59c92][S= LP]=20 httpd 596 c2082000 df008000 80 540 540 0000100 [SLPQ accept 0xc1f59c92][S= LP]=20 httpd 589 c2082898 df00d000 88 551 51 000c102 (threaded) mysqld thread 0xc1e78840 ksegrp 0xc1bf2e80 [SLPQ kserel 0xc1bf2edc][SLP] thread 0xc20ff2c0 ksegrp 0xc1bf2680 [SLPQ kserel 0xc1bf26dc][SLP] thread 0xc20fb2c0 ksegrp 0xc1bf2e80 [SLPQ select 0xc0774584][SLP] thread 0xc20fbc60 ksegrp 0xc1bf2700 [SLPQ sigwait 0xdf05cc2c][SLP] thread 0xc1e789a0 ksegrp 0xc1bf2780 [SLPQ ksesigwait 0xc2082998][SLP] 551 c2082528 df00b000 0 1 51 0004002 [SLPQ wait 0xc2082528][SLP= ]=20 sh 540 c20826e0 df00c000 0 1 540 0000000 [SLPQ select 0xc0774584][S= LP]=20 httpd 534 c20851b8 df033000 80 1 533 000c002 (threaded) java thread 0xc22db160 ksegrp 0xc1bf2c00 [RUNQ][kse 0xc1ba5480] thread 0xc22db2c0 ksegrp 0xc1bf2c00 [SLPQ accept 0xc202cdce][SLP] thread 0xc22db420 ksegrp 0xc1bf2c00 [SLPQ accept 0xc235203a][SLP] thread 0xc20fb420 ksegrp 0xc1bf2c00 [SLPQ accept 0xc23523ee][SLP] thread 0xc1e78b00 ksegrp 0xc1bf2800 [SLPQ ksesigwait 0xc20852b8][SLP] 507 c1c8a1b8 d9481000 0 1 507 0000000 [SLPQ nanslp 0xc076a91c][S= LP]=20 cron 487 c1c8a6e0 d9484000 0 1 487 0000100 [SLPQ select 0xc0774584][S= LP]=20 sshd 337 c1c8a898 d9485000 0 1 337 0000000 [SLPQ select 0xc0774584][S= LP]=20 rpcbind 322 c1c8aa50 d9486000 0 1 322 0000000 [RUNQ] syslogd 199 c1e76000 dd987000 0 1 199 0000000 [SLPQ pause 0xc1e76038][SL= P]=20 adjkerntz 50 c1e76370 dd9cb000 0 0 0 0000204 [SLPQ - 0xc077c00c][SLP]=20 nfsiod 3 49 c1e76528 dd9cc000 0 0 0 0000204 [SLPQ - 0xc077c008][SLP]=20 nfsiod 2 48 c1e766e0 dd9cd000 0 0 0 0000204 [SLPQ - 0xc077c004][SLP]=20 nfsiod 1 47 c1e76898 dd9ce000 0 0 0 0000204 [SLPQ - 0xc077c000][SLP]=20 nfsiod 0 46 c1bf1a50 d944f000 0 0 0 0000204 [SLPQ syncer 0xc076a6a4][S= LP]=20 syncer 45 c1bf1c08 d9450000 0 0 0 0000204 [SLPQ vlruwt 0xc1bf1c08][S= LP]=20 vnlru 44 c1bf1dc0 d9451000 0 0 0 0000204 [SLPQ psleep 0xc0774b70][S= LP]=20 bufdaemon 43 c1c87000 d9456000 0 0 0 000020c [SLPQ pgzero 0xc07827e8][S= LP]=20 pagezero 42 c1c871b8 d9457000 0 0 0 0000204 [SLPQ psleep 0xc0782840][S= LP]=20 vmdaemon 41 c1c87370 d9458000 0 0 0 0000204 [SLPQ psleep 0xc078282c][S= LP]=20 pagedaemon 40 c1c87528 d9459000 0 0 0 0000204 [IWAIT] swi0: tty:sio 39 c1c876e0 d947b000 0 0 0 0000204 [SLPQ idle 0xc1c69c00][SLP= ]=20 aic_recovery0 9 c1c87898 d947c000 0 0 0 0000204 [SLPQ idle 0xc1c69c00][SLP= ]=20 aic_recovery0 38 c1c87a50 d947d000 0 0 0 0000204 [SLPQ usbtsk 0xc076292c][S= LP]=20 usbtask 37 c1c87c08 d947e000 0 0 0 0000204 [SLPQ usbevt 0xc1c9f210][S= LP]=20 usb0 8 c1c87dc0 d947f000 0 0 0 0000204 [SLPQ actask 0xc088c4cc][S= LP]=20 acpi_task2 7 c1c8a000 d9480000 0 0 0 0000204 [SLPQ actask 0xc088c4cc][S= LP]=20 acpi_task1 6 c1be6528 d9422000 0 0 0 0000204 [SLPQ actask 0xc088c4cc][S= LP]=20 acpi_task0 36 c1be66e0 d9423000 0 0 0 0000204 [IWAIT] swi5:+ 5 c1be6898 d9424000 0 0 0 0000204 [SLPQ - 0xc1c45180][SLP]=20 taskqueue 35 c1be6a50 d9425000 0 0 0 0000204 [IWAIT] swi7: acpitaskq 34 c1be6c08 d9426000 0 0 0 0000204 [IWAIT] swi6:+ 33 c1be6dc0 d9448000 0 0 0 0000204 [IWAIT] swi7: task queue 32 c1bf1000 d9449000 0 0 0 0000204 [IWAIT] swi3: cambio 31 c1bf11b8 d944a000 0 0 0 0000204 [IWAIT] swi2: camnet 30 c1bf1370 d944b000 0 0 0 0000204 [RUNQ] yarrow 4 c1bf1528 d944c000 0 0 0 0000204 [SLPQ - 0xc0765050][SLP]=20 g_down 3 c1bf16e0 d944d000 0 0 0 0000204 [SLPQ - 0xc076504c][SLP] g= _up 2 c1bf1898 d944e000 0 0 0 0000204 [CPU 0] g_event 29 c1ba81b8 d7e45000 0 0 0 0000204 [IWAIT] swi4: vm 28 c1ba8370 d7e46000 0 0 0 000020c [RUNQ] swi8: tty:sio clock 27 c1ba8528 d7e47000 0 0 0 0000204 [IWAIT] swi1: net 26 c1ba86e0 d7e69000 0 0 0 0000204 [IWAIT] irq15: ata1 25 c1ba8898 d7e6a000 0 0 0 0000204 [IWAIT] irq14: ata0 24 c1ba8a50 d7e6b000 0 0 0 0000204 [IWAIT] irq13: 23 c1ba8c08 d7e6c000 0 0 0 0000204 [IWAIT] irq12: 22 c1ba8dc0 d7e6d000 0 0 0 0000204 [IWAIT] irq11: 21 c1be6000 d941f000 0 0 0 0000204 [IWAIT] irq10: pcm0 20 c1be61b8 d9420000 0 0 0 0000204 [IWAIT] irq9: ahc0 bktr0++ 19 c1be6370 d9421000 0 0 0 0000204 [IWAIT] irq8: rtc 18 c1b9f000 d7df9000 0 0 0 0000204 [IWAIT] irq7: ppc0 17 c1b9f1b8 d7e3c000 0 0 0 0000204 [IWAIT] irq6: 16 c1b9f370 d7e3d000 0 0 0 0000204 [IWAIT] irq5: xl0 uhci0+ 15 c1b9f528 d7e3e000 0 0 0 0000204 [IWAIT] irq4: sio0 14 c1b9f6e0 d7e3f000 0 0 0 0000204 [IWAIT] irq3: sio1 13 c1b9f898 d7e40000 0 0 0 0000204 [IWAIT] irq1: atkbd0 12 c1b9fa50 d7e41000 0 0 0 0000204 [IWAIT] irq0: clk 11 c1b9fc08 d7e42000 0 0 0 000020c [Can run] idle: cpu0 1 c1b9fdc0 d7e43000 0 0 1 0004200 [SLPQ wait 0xc1b9fdc0][SLP= ]=20 init 10 c1ba8000 d7e44000 0 0 0 0000204 [SLPQ ktrace 0xc07688b8][S= LP]=20 ktrace 0 c0765140 c0c1f000 0 0 0 0000200 [SLPQ sched 0xc0765140][SL= P]=20 swapper db> panic panic: from debugger cpuid =3D 0; Debugger("panic") =46atal trap 3: breakpoint instruction fault while in kernel mode cpuid =3D 0; apic id =3D 00 instruction pointer =3D 0x8:0xc06983a2 stack pointer =3D 0x10:0xd7e65a64 frame pointer =3D 0x10:0xd7e65a68 code segment =3D base 0x0, limit 0xfffff, type 0x1b =3D DPL 0, pres 1, def32 1, gran 1 processor eflags =3D IOPL =3D 0 current process =3D 2 (g_event) Stopped at redo_rank+0x70: cmpl $0,0xc(%edx) db> panic panic: from debugger cpuid =3D 0; Uptime: 4m24s Hardware: The vinum striped volume resides on da0 and da1. They are connected to =20 ahc0, an Adaptec 2940 Ultra2 SCSI adapter. Type '?' for a list of commands, 'help' for more detailed help. OK boot /boot/kernel/kernel.debug /boot/kernel/kernel.debug text=3D0x309d24 data=3D0x528ac+0x3f930=20 syms=3D[0x4+0x503a0+0 x4+0x6259c] /boot/kernel/acpi.ko text=3D0x39d0c data=3D0x19e4+0x116c=20 syms=3D[0x4+0x6810+0x4+0x8a33 ] 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. =46reeBSD 5.2-CURRENT #2: Sun Jun 13 12:08:06 CEST 2004 pfnu@matrix010.matrix.net:/usr/obj/usr/src/sys/MATRIX020 Preloaded elf kernel "/boot/kernel/kernel.debug" at 0xc089d000. Preloaded elf module "/boot/kernel/acpi.ko" at 0xc089d1fc. Timecounter "i8254" frequency 1193182 Hz quality 0 CPU: Intel Pentium III (851.94-MHz 686-class CPU) Origin =3D "GenuineIntel" Id =3D 0x683 Stepping =3D 3 Features=3D0x383f9ff real memory =3D 671072256 (639 MB) avail memory =3D 647147520 (617 MB) random: Pentium Pro MTRR support enabled npx0: [FAST] npx0: on motherboard npx0: INT 16 interface acpi0: on motherboard acpi0: [GIANT-LOCKED] pcibios: BIOS version 2.10 acpi0: Power Button (fixed) Timecounter "ACPI-safe" frequency 3579545 Hz quality 1000 acpi_timer0: <24-bit timer at 3.579545MHz> port 0xe408-0xe40b on acpi0 cpu0: on acpi0 acpi_button0: on acpi0 pcib0: port 0xcf8-0xcff on acpi0 pci0: on pcib0 pcib0: slot 4 INTD is routed to irq 5 pcib0: slot 9 INTA is routed to irq 5 pcib0: slot 10 INTA is routed to irq 9 agp0: mem 0xe4000000-0xe7ffffff= at=20 d evice 0.0 on pci0 pcib1: at device 1.0 on pci0 pci1: on pcib1 pcib0: slot 1 INTA is routed to irq 11 pcib1: slot 0 INTA is routed to irq 11 pci1: at device 0.0 (no driver attached) isab0: at device 4.0 on pci0 isa0: on isab0 atapci0: port=20 0xd800-0xd80f,0x376,0x170-0x177,0x 3f6,0x1f0-0x1f7 at device 4.1 on pci0 ata0: at 0x1f0 irq 14 on atapci0 ata1: at 0x170 irq 15 on atapci0 uhci0: port 0xd400-0xd41f irq 5 a= t=20 dev ice 4.2 on pci0 uhci0: [GIANT-LOCKED] usb0: on uhci0 usb0: USB revision 1.0 uhub0: Intel UHCI root hub, class 9/0, rev 1.00/1.00, addr 1 uhub0: 2 ports with 2 removable, self powered ums0: IBM Corporation product 0x310b, rev 2.00/1.60, addr 2, iclass 3/1 ums0: 3 buttons and Z dir. intpm0: port 0xe800-0xe80f irq = 9=20 at device 4.3 on pci0 intpm0: I/O mapped e800 intpm0: intr IRQ 9 enabled revision 0 intpm0: [GIANT-LOCKED] intsmb0: on intpm0 smbus0: on intsmb0 intpm0: PM I/O mapped e400 atapci1: port=20 0xa800-0xa80f,0xb000-0xb003,0xb400-0 xb407,0xb800-0xb803,0xd000-0xd007 mem 0xde800000-0xde8000ff irq 5 at device= =20 9.0 on pci0 ata2: at 0xde800000 on atapci1 ata3: at 0xde800000 on atapci1 ahc0: port 0xa400-0xa4ff mem=20 0xde000000-0xde0 00fff irq 9 at device 10.0 on pci0 ahc0: [GIANT-LOCKED] aic7890/91: Ultra2 Wide Channel A, SCSI Id=3D7, 32/253 SCBs pcm0: port 0xa000-0xa03f at device 11.0 on pci0 pcm0: pcib0: slot 11 INTA is routed to irq 10 pcm0: [GIANT-LOCKED] xl0: <3Com 3c980C Fast Etherlink XL> port 0x9800-0x987f mem=20 0xdd800000-0xdd80007 f at device 13.0 on pci0 pcib0: slot 13 INTA is routed to irq 5 miibus0: on xl0 xlphy0: <3c905C 10/100 internal PHY> on miibus0 xlphy0: 10baseT, 10baseT-FDX, 100baseTX, 100baseTX-FDX, auto xl0: Ethernet address: 00:04:75:ec:d2:89 xl0: [GIANT-LOCKED] bktr0: mem 0xe1000000-0xe1000fff at device 14.0 on pci0 pcib0: slot 14 INTA is routed to irq 9 bktr0: [GIANT-LOCKED] bktr0: Hauppauge Model 61334 B2 bktr0: Detected a MSP3410D-B4 at 0x80 bktr0: Hauppauge WinCast/TV, Philips FR1216 PAL FM tuner, msp3400c stereo. pci0: at device 14.1 (no driver attached) ppc0 port 0x778-0x77b,0x378-0x37f irq 7 drq 3 on acpi0 ppc0: SMC-like chipset (ECP/EPP/PS2/NIBBLE) in COMPATIBLE mode ppc0: FIFO with 16/16/9 bytes threshold ppbus0: on ppc0 plip0: on ppbus0 lpt0: on ppbus0 lpt0: Interrupt-driven port ppi0: on ppbus0 sio0 port 0x3f8-0x3ff irq 4 on acpi0 sio0: type 16550A, console sio1 port 0x2f8-0x2ff irq 3 on acpi0 sio1: type 16550A atkbdc0: port 0x64,0x60 irq 1 on acpi0 atkbd0: irq 1 on atkbdc0 kbd0 at atkbd0 atkbd0: [GIANT-LOCKED] orm0: