Re: Panic in fork()
On Sat, Feb 08, 2003 at 02:04:56PM -0800, Kris Kennaway wrote: OK, I suspected that. tjr was looking into this last night and proposed the following patch: http://people.freebsd.org/~tjr/kf.diff OK, I got another panic with this patch in place, so I guess that's not enough. Maybe I should try Alfred's suggestion of changing the locks to exclusive locks. Fatal trap 12: page fault while in kernel mode cpuid = 1; lapic.id = fault virtual address = 0x14 fault code = supervisor read, page not present instruction pointer = 0x8:0xc01a1e2d stack pointer = 0x10:0xe3639c74 frame pointer = 0x10:0xe3639cbc code segment= base 0x0, limit 0xf, type 0x1b = DPL 0, pres 1, def32 1, gran 1 processor eflags= interrupt enabled, resume, IOPL = 0 current process = 97943 (sh) kernel: type 12 trap, code=0 Stopped at fork1+0x3fd:cmpl%ebx,0x14(%eax) db trace fork1(ca1458c0,14,0,e3639cd4,ca179068) at fork1+0x3fd fork(ca1458c0,e3639d10,c03445dc,407,0) at fork+0x52 syscall(2f,2f,2f,0,80fe000) at syscall+0x28e Xint0x80_syscall() at Xint0x80_syscall+0x1d --- syscall (2, FreeBSD ELF32, fork), eip = 0x807bd63, esp = 0xbfbff9fc, ebp = 0xbfbffa28 --- db Kris msg52354/pgp0.pgp Description: PGP signature
Re: Panic in fork()
* Kris Kennaway [EMAIL PROTECTED] [030214 13:19] wrote: On Sat, Feb 08, 2003 at 02:04:56PM -0800, Kris Kennaway wrote: OK, I suspected that. tjr was looking into this last night and proposed the following patch: http://people.freebsd.org/~tjr/kf.diff OK, I got another panic with this patch in place, so I guess that's not enough. Maybe I should try Alfred's suggestion of changing the locks to exclusive locks. Actually that was a mistake on my part. I don't think the locks should be exclusive actually... Anyhow, i'll look at it some more, now that crashdumps work again, any chance for a nice gdb session transcript? -Alfred To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-current in the body of the message
Re: Panic in fork()
On Fri, Feb 14, 2003 at 02:05:11PM -0800, Alfred Perlstein wrote: * Kris Kennaway [EMAIL PROTECTED] [030214 13:19] wrote: On Sat, Feb 08, 2003 at 02:04:56PM -0800, Kris Kennaway wrote: OK, I suspected that. tjr was looking into this last night and proposed the following patch: http://people.freebsd.org/~tjr/kf.diff OK, I got another panic with this patch in place, so I guess that's not enough. Maybe I should try Alfred's suggestion of changing the locks to exclusive locks. Actually that was a mistake on my part. I don't think the locks should be exclusive actually... Anyhow, i'll look at it some more, now that crashdumps work again, any chance for a nice gdb session transcript? I've just updated bento to include your crashdump fix, so I'll have one for you next time it occurs. Kris msg52358/pgp0.pgp Description: PGP signature
Re: Panic in fork()
On Sun, 2003/02/09 at 14:39:36 +1100, Tim Robbins wrote:
On Sat, Feb 08, 2003 at 02:04:56PM -0800, Kris Kennaway wrote:
On Sat, Feb 08, 2003 at 04:12:26PM +0100, Thomas Moestl wrote:
addr2line will usually point to the first line of a statement if it
spans multiple lines; in this case, the full guard is:
while (p2-p_pid == trypid ||
p2-p_pgrp-pg_id == trypid ||
p2-p_session-s_sid == trypid) {
OK, I suspected that.
tjr was looking into this last night and proposed the following patch:
Alfred was the one who pointed out that holding proctree was probably
necessary, though :-)
I don't really get why this is required - the pg_session pointer in
struct pgrp is constant over the pgrp's lifetime, so for it to be
invalid the wrong struct pgrp must be referenced; the p_pgrp pointer
is protected by the process lock however, which is held for this check.
- Thomas
--
Thomas Moestl [EMAIL PROTECTED] http://www.tu-bs.de/~y0015675/
[EMAIL PROTECTED] http://people.FreeBSD.org/~tmm/
PGP fingerprint: 1C97 A604 2BD0 E492 51D0 9C0F 1FE6 4F1D 419C 776C
To Unsubscribe: send mail to [EMAIL PROTECTED]
with unsubscribe freebsd-current in the body of the message
Panic in fork()
Fatal trap 12: page fault while in kernel mode cpuid = 0; lapic.id = 0100 fault virtual address = 0x14 fault code = supervisor read, page not present instruction pointer = 0x8:0xc01a1e2d stack pointer = 0x10:0xe4146c74 frame pointer = 0x10:0xe4146cbc code segment= base 0x0, limit 0xf, type 0x1b = DPL 0, pres 1, def32 1, gran 1 processor eflags= interrupt enabled, resume, IOPL = 0 current process = 2 (sh) kernel: type 12 trap, code=0 Stopped at fork1+0x3fd:cmpl%ebx,0x14(%eax) db trace fork1(c6ee5000,14,0,e4146cd4,c6c04788) at fork1+0x3fd fork(c6ee5000,e4146d10,c03445dc,407,0) at fork+0x52 syscall(2f,2f,2f,80f9cb4,80fe000) at syscall+0x28e Xint0x80_syscall() at Xint0x80_syscall+0x1d --- syscall (2, FreeBSD ELF32, fork), eip = 0x807bd63, esp = 0xbfbff69c, ebp = 0xbfbff6c8 --- db Kris To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-current in the body of the message
Re: Panic in fork()
On Sat, Feb 08, 2003 at 01:24:06AM -0800, Kris Kennaway wrote: Fatal trap 12: page fault while in kernel mode cpuid = 0; lapic.id = 0100 fault virtual address = 0x14 fault code = supervisor read, page not present instruction pointer = 0x8:0xc01a1e2d stack pointer = 0x10:0xe4146c74 frame pointer = 0x10:0xe4146cbc code segment= base 0x0, limit 0xf, type 0x1b = DPL 0, pres 1, def32 1, gran 1 processor eflags= interrupt enabled, resume, IOPL = 0 current process = 2 (sh) kernel: type 12 trap, code=0 Stopped at fork1+0x3fd:cmpl%ebx,0x14(%eax) db trace fork1(c6ee5000,14,0,e4146cd4,c6c04788) at fork1+0x3fd fork(c6ee5000,e4146d10,c03445dc,407,0) at fork+0x52 syscall(2f,2f,2f,80f9cb4,80fe000) at syscall+0x28e Xint0x80_syscall() at Xint0x80_syscall+0x1d --- syscall (2, FreeBSD ELF32, fork), eip = 0x807bd63, esp = 0xbfbff69c, ebp = 0xbfbff6c8 --- db Is this anything like the one I experienced in late January? http://www.freebsd.org/cgi/getmsg.cgi?fetch=1447263+1454677+/usr/local/www/db/text/2003/freebsd-current/20030126.freebsd-current -- Morten Rodal msg51985/pgp0.pgp Description: PGP signature
Re: Panic in fork()
On Sat, Feb 08, 2003 at 01:24:06AM -0800, Kris Kennaway wrote:
Fatal trap 12: page fault while in kernel mode
cpuid = 0; lapic.id = 0100
fault virtual address = 0x14
fault code = supervisor read, page not present
instruction pointer = 0x8:0xc01a1e2d
stack pointer = 0x10:0xe4146c74
frame pointer = 0x10:0xe4146cbc
code segment= base 0x0, limit 0xf, type 0x1b
= DPL 0, pres 1, def32 1, gran 1
processor eflags= interrupt enabled, resume, IOPL = 0
current process = 2 (sh)
kernel: type 12 trap, code=0
Stopped at fork1+0x3fd:cmpl%ebx,0x14(%eax)
db trace
fork1(c6ee5000,14,0,e4146cd4,c6c04788) at fork1+0x3fd
fork(c6ee5000,e4146d10,c03445dc,407,0) at fork+0x52
syscall(2f,2f,2f,80f9cb4,80fe000) at syscall+0x28e
Xint0x80_syscall() at Xint0x80_syscall+0x1d
--- syscall (2, FreeBSD ELF32, fork), eip = 0x807bd63, esp = 0xbfbff69c, ebp =
0xbfbff6c8 ---
db
bento# addr2line -e kernel.debug 0xc01a1e2d
../../../kern/kern_fork.c:388
for (; p2 != NULL; p2 = LIST_NEXT(p2, p_list)) {
PROC_LOCK(p2);
388 -- while (p2-p_pid == trypid ||
Kris
msg51986/pgp0.pgp
Description: PGP signature
Re: Panic in fork()
On Sat, Feb 08, 2003 at 03:05:12AM -0800, Kris Kennaway wrote:
bento# addr2line -e kernel.debug 0xc01a1e2d
../../../kern/kern_fork.c:388
for (; p2 != NULL; p2 = LIST_NEXT(p2, p_list)) {
PROC_LOCK(p2);
388 -- while (p2-p_pid == trypid ||
That is the exact same spot I saw my computer (old smp machine) crash.
I think someone mentioned that it would be more or less impossible to
crash there since one would not enter the for loop when p2 is NULL.
Could it be that PROC_LOCK tampers with p2?
Also see my other post to your original message.
--
Morten Rodal
msg51994/pgp0.pgp
Description: PGP signature
Re: Panic in fork()
On Sat, Feb 08, 2003 at 04:12:26PM +0100, Thomas Moestl wrote:
addr2line will usually point to the first line of a statement if it
spans multiple lines; in this case, the full guard is:
while (p2-p_pid == trypid ||
p2-p_pgrp-pg_id == trypid ||
p2-p_session-s_sid == trypid) {
OK, I suspected that.
tjr was looking into this last night and proposed the following patch:
http://people.freebsd.org/~tjr/kf.diff
Kris
Index: kern_fork.c
===
RCS file: /x/freebsd/src/sys/kern/kern_fork.c,v
retrieving revision 1.181
diff -u -r1.181 kern_fork.c
--- kern_fork.c 1 Feb 2003 12:17:07 - 1.181
+++ kern_fork.c 8 Feb 2003 11:32:18 -
@@ -318,6 +318,7 @@
* exceed the limit. The variable nprocs is the current number of
* processes, maxproc is the limit.
*/
+ sx_slock(proctree_lock);
sx_xlock(allproc_lock);
uid = td-td_ucred-cr_ruid;
if ((nprocs = maxproc - 10 uid != 0) || nprocs = maxproc) {
@@ -425,6 +426,7 @@
LIST_INSERT_HEAD(allproc, p2, p_list);
LIST_INSERT_HEAD(PIDHASH(p2-p_pid), p2, p_hash);
sx_xunlock(allproc_lock);
+ sx_sunlock(proctree_lock);
/*
* Malloc things while we don't hold any locks.
@@ -759,6 +761,7 @@
return (0);
fail:
sx_xunlock(allproc_lock);
+ sx_sunlock(proctree_lock);
uma_zfree(proc_zone, newproc);
if (p1-p_flag P_KSES) {
PROC_LOCK(p1);
msg52016/pgp0.pgp
Description: PGP signature
Re: Panic in fork()
On Sat, Feb 08, 2003 at 02:04:56PM -0800, Kris Kennaway wrote:
On Sat, Feb 08, 2003 at 04:12:26PM +0100, Thomas Moestl wrote:
addr2line will usually point to the first line of a statement if it
spans multiple lines; in this case, the full guard is:
while (p2-p_pid == trypid ||
p2-p_pgrp-pg_id == trypid ||
p2-p_session-s_sid == trypid) {
OK, I suspected that.
tjr was looking into this last night and proposed the following patch:
Alfred was the one who pointed out that holding proctree was probably
necessary, though :-)
Tim
To Unsubscribe: send mail to [EMAIL PROTECTED]
with unsubscribe freebsd-current in the body of the message
Re: panic in fork() on SMP 5.0-RELEASE
On 25-Jan-2003 Nate Lawson wrote: On Sat, 25 Jan 2003, Morten Rodal wrote: The system is running 5.0-RELEASE with a pretty standard kernel (just removed all the drivers I don't use and added SMP support). I think the load of the system might have been high at the moment as I had just started cd /usr/ports make -j8 clean The problem is uap is invalid in this frame: #15 0xc01bd2f0 in fork (td=0xc5144000, uap=0xe3ac4d10) at /usr/src/sys/kern/kern_fork.c:124 The question is, why? I suspect something to do with memory due to the second two bytes being a valid kernel address. How about a dmesg? Eh? 0xefoo is a valid address, it's just not text, it's a stack address. Also, the last two bytes are '4d10' which would be the start of a user address. The 'c' is the low nibble in the 'ac' byte. -- John Baldwin [EMAIL PROTECTED]http://www.FreeBSD.org/~jhb/ Power Users Use the Power to Serve! - http://www.FreeBSD.org/ To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-current in the body of the message
RE: panic in fork() on SMP 5.0-RELEASE
On 25-Jan-2003 Morten Rodal wrote: Is this a known panic? I tried to search the mailinglist archives to see if somebody had posted something similar, but I couldn't find anything. The system is running 5.0-RELEASE with a pretty standard kernel (just removed all the drivers I don't use and added SMP support). I think the load of the system might have been high at the moment as I had just started cd /usr/ports make -j8 clean before I went to eat dinner. When I came back a few hours later it at rebooted, with this panic. I have attached the backtrace of this (dual?) panic. I have never poked in the kernel source code before, so if there is anything else you need to know just ask and I'll see what I can do. Do you still have the kernel.debug from this kernel lying around? Can you pop gdb up on it and do 'l *0xc01bdb48' please? That is the instruction pointer from the fault and will give the line that the actual panic occurred at. -- John Baldwin [EMAIL PROTECTED]http://www.FreeBSD.org/~jhb/ Power Users Use the Power to Serve! - http://www.FreeBSD.org/ To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-current in the body of the message
Re: panic in fork() on SMP 5.0-RELEASE
On Mon, Jan 27, 2003 at 03:27:00PM -0500, John Baldwin wrote:
Do you still have the kernel.debug from this kernel lying around?
Can you pop gdb up on it and do 'l *0xc01bdb48' please? That is
the instruction pointer from the fault and will give the line that
the actual panic occurred at.
(kgdb) l *0xc01bdb48
0xc01bdb48 is in fork1 (/usr/src/sys/kern/kern_fork.c:388).
383 */
384 p2 = LIST_FIRST(allproc);
385 again:
386 for (; p2 != NULL; p2 = LIST_NEXT(p2, p_list)) {
387 PROC_LOCK(p2);
388 while (p2-p_pid == trypid ||
389 p2-p_pgrp-pg_id == trypid ||
390 p2-p_session-s_sid == trypid) {
391 trypid++;
392 if (trypid = pidchecked) {
--
Morten Rodal
msg51029/pgp0.pgp
Description: PGP signature
Re: panic in fork() on SMP 5.0-RELEASE
On 27-Jan-2003 Morten Rodal wrote:
On Mon, Jan 27, 2003 at 03:27:00PM -0500, John Baldwin wrote:
Do you still have the kernel.debug from this kernel lying around?
Can you pop gdb up on it and do 'l *0xc01bdb48' please? That is
the instruction pointer from the fault and will give the line that
the actual panic occurred at.
(kgdb) l *0xc01bdb48
0xc01bdb48 is in fork1 (/usr/src/sys/kern/kern_fork.c:388).
383 */
384 p2 = LIST_FIRST(allproc);
385 again:
386 for (; p2 != NULL; p2 = LIST_NEXT(p2, p_list)) {
387 PROC_LOCK(p2);
388 while (p2-p_pid == trypid ||
389 p2-p_pgrp-pg_id == trypid ||
390 p2-p_session-s_sid == trypid) {
391 trypid++;
392 if (trypid = pidchecked) {
Well, that's gross. I have no idea how that could happen. Somehow
p2 is NULL. But we shouldn't even be in the loop if p2 is NULL.
--
John Baldwin [EMAIL PROTECTED]http://www.FreeBSD.org/~jhb/
Power Users Use the Power to Serve! - http://www.FreeBSD.org/
To Unsubscribe: send mail to [EMAIL PROTECTED]
with unsubscribe freebsd-current in the body of the message
panic in fork() on SMP 5.0-RELEASE
Is this a known panic? I tried to search the mailinglist archives to
see if somebody had posted something similar, but I couldn't find
anything.
The system is running 5.0-RELEASE with a pretty standard kernel (just
removed all the drivers I don't use and added SMP support). I think
the load of the system might have been high at the moment as I had
just started
cd /usr/ports make -j8 clean
before I went to eat dinner. When I came back a few hours later it at
rebooted, with this panic.
I have attached the backtrace of this (dual?) panic. I have never
poked in the kernel source code before, so if there is anything else
you need to know just ask and I'll see what I can do.
--
Morten Rodal
Script started on Sat Jan 25 21:17:42 2003
slurp# gdb -k kernel.0 vmcore.0
GNU gdb 5.2.1 (FreeBSD)
Copyright 2002 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-undermydesk-freebsd...
panic: bwrite: buffer is not busy???
panic messages:
---
Fatal trap 12: page fault while in kernel mode
cpuid = 0; lapic.id = 0100
fault virtual address = 0x14
fault code = supervisor read, page not present
instruction pointer = 0x8:0xc01bdb48
stack pointer = 0x10:0xe3ac4c04
frame pointer = 0x10:0xe3ac4cac
code segment= base 0x0, limit 0xf, type 0x1b
= DPL 0, pres 1, def32 1, gran 1
processor eflags= interrupt enabled, resume, IOPL = 0
current process = 580 (sh)
trap number = 12
panic: page fault
cpuid = 0; lapic.id = 0100
boot() called on cpu#0
syncing disks, buffers remaining... panic: bwrite: buffer is not busy???
cpuid = 0; lapic.id = 0100
boot() called on cpu#0
Uptime: 5d18h59m34s
Dumping 447 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
---
#0 doadump () at /usr/src/sys/kern/kern_shutdown.c:232
232 dumping++;
(kgdb) bt
#0 doadump () at /usr/src/sys/kern/kern_shutdown.c:232
#1 0xc01d4bea in boot (howto=260) at /usr/src/sys/kern/kern_shutdown.c:364
#2 0xc01d4ea7 in panic () at /usr/src/sys/kern/kern_shutdown.c:517
#3 0xc021a852 in bwrite (bp=0xcca8c150) at /usr/src/sys/kern/vfs_bio.c:796
#4 0xc021bf46 in vfs_bio_awrite (bp=0xcca8c150) at /usr/src/sys/kern/vfs_bio.c:1643
#5 0xc019e203 in spec_fsync (ap=0xe3ac49f4) at
/usr/src/sys/fs/specfs/spec_vnops.c:462
#6 0xc019d558 in spec_vnoperate (ap=0x0) at /usr/src/sys/fs/specfs/spec_vnops.c:126
#7 0xc02a9c62 in ffs_sync (mp=0xc3a37000, waitfor=2, cred=0xc1376e80, td=0xc035e900)
at vnode_if.h:612
#8 0xc022fb9b in sync (td=0xc035e900, uap=0x0) at
/usr/src/sys/kern/vfs_syscalls.c:138
#9 0xc01d47cb in boot (howto=256) at /usr/src/sys/kern/kern_shutdown.c:273
#10 0xc01d4ea7 in panic () at /usr/src/sys/kern/kern_shutdown.c:517
#11 0xc030b662 in trap_fatal (frame=0xe3ac4bc4, eva=0) at
/usr/src/sys/i386/i386/trap.c:844
#12 0xc030b312 in trap_pfault (frame=0xe3ac4bc4, usermode=0, eva=20) at
/usr/src/sys/i386/i386/trap.c:758
#13 0xc030ae02 in trap (frame=
{tf_fs = -475267048, tf_es = -1070792688, tf_ds = -988741616, tf_edi =
-1070209248, tf_esi = -988528640, tf_ebp = -475247444, tf_isp = -475247632, tf_ebx =
582, tf_edx = -989019040, tf_ecx = -988528640, tf_eax = 0, tf_trapno = 12, tf_err = 0,
tf_eip = -1071916216, tf_cs = 8, tf_eflags = 66195, tf_esp = -1053458112, tf_ss = 1})
at /usr/src/sys/i386/i386/trap.c:445
#14 0xc02f3918 in calltrap () at {standard input}:99
#15 0xc01bd2f0 in fork (td=0xc5144000, uap=0xe3ac4d10) at
/usr/src/sys/kern/kern_fork.c:124
#16 0xc030b9bc in syscall (frame=
{tf_fs = 47, tf_es = 47, tf_ds = 47, tf_edi = -1, tf_esi = 135258112, tf_ebp =
-1077938280, tf_isp = -475247244, tf_ebx = 135236344, tf_edx = 135236332, tf_ecx =
-1077938240, tf_eax = 2, tf_trapno = 12, tf_err = 2, tf_eip = 134723859, tf_cs = 31,
tf_eflags = 514, tf_esp = -1077938324, tf_ss = 47}) at
/usr/src/sys/i386/i386/trap.c:1033
#17 0xc02f396d in Xint0x80_syscall () at {standard input}:141
---Can't read userspace from dump, or kernel process---
(kgdb) slurp# ^Dexit
Script done on Sat Jan 25 21:18:04 2003
msg50908/pgp0.pgp
Description: PGP signature
Re: panic in fork() on SMP 5.0-RELEASE
On Sat, 25 Jan 2003, Morten Rodal wrote: The system is running 5.0-RELEASE with a pretty standard kernel (just removed all the drivers I don't use and added SMP support). I think the load of the system might have been high at the moment as I had just started cd /usr/ports make -j8 clean The problem is uap is invalid in this frame: #15 0xc01bd2f0 in fork (td=0xc5144000, uap=0xe3ac4d10) at /usr/src/sys/kern/kern_fork.c:124 The question is, why? I suspect something to do with memory due to the second two bytes being a valid kernel address. How about a dmesg? -Nate To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-current in the body of the message
Re: panic in fork() on SMP 5.0-RELEASE
On Sat, Jan 25, 2003 at 12:38:28PM -0800, Nate Lawson wrote: The question is, why? I suspect something to do with memory due to the second two bytes being a valid kernel address. How about a dmesg? [forgot to cc: [EMAIL PROTECTED]] Are you suspecting faulty memory? See attached dmesg.boot. -- Morten Rodal Copyright (c) 1992-2003 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.0-RELEASE #0: Sun Jan 19 17:03:57 CET 2003 [EMAIL PROTECTED]:/usr/obj/usr/src/sys/slurp Preloaded elf kernel /boot/kernel/kernel at 0xc05e2000. Preloaded elf module /boot/kernel/linux.ko at 0xc05e20b4. Preloaded elf module /boot/kernel/snd_sb16.ko at 0xc05e2160. Preloaded elf module /boot/kernel/snd_sbc.ko at 0xc05e2210. Preloaded elf module /boot/kernel/snd_pcm.ko at 0xc05e22bc. Preloaded elf module /boot/kernel/nvidia.ko at 0xc05e2368. Preloaded elf module /boot/kernel/acpi.ko at 0xc05e2414. Timecounter i8254 frequency 1193182 Hz CPU: Pentium II/Pentium II Xeon/Celeron (300.68-MHz 686-class CPU) Origin = GenuineIntel Id = 0x634 Stepping = 4 Features=0x80fbffFPU,VME,DE,PSE,TSC,MSR,PAE,MCE,CX8,APIC,SEP,MTRR,PGE,MCA,CMOV,MMX real memory = 469749760 (447 MB) avail memory = 449974272 (429 MB) Programming 24 pins in IOAPIC #0 IOAPIC #0 intpin 2 - irq 0 FreeBSD/SMP: Multiprocessor System Detected: 2 CPUs cpu0 (BSP): apic id: 1, version: 0x00040011, at 0xfee0 cpu1 (AP): apic id: 0, version: 0x00040011, at 0xfee0 io0 (APIC): apic id: 2, version: 0x00170011, at 0xfec0 Initializing GEOMetry subsystem Pentium Pro MTRR support enabled npx0: math processor on motherboard npx0: INT 16 interface acpi0: ASUS P2L97-DS on motherboard ACPI-0625: *** Info: GPE Block0 defined as GPE0 to GPE15 Using $PIR table, 7 entries at 0xc00f0d20 acpi0: power button is handled as a fixed feature programming model. Timecounter ACPI-safe frequency 3579545 Hz acpi_timer0: 24-bit timer at 3.579545MHz port 0xe408-0xe40b on acpi0 acpi_cpu0: CPU on acpi0 acpi_cpu1: CPU on acpi0 acpi_button0: Power Button on acpi0 pcib0: ACPI Host-PCI bridge port 0xcf8-0xcff on acpi0 pci0: ACPI PCI bus on pcib0 IOAPIC #0 intpin 19 - irq 2 IOAPIC #0 intpin 18 - irq 7 agp0: Intel 82443LX (440 LX) host to PCI bridge mem 0xe400-0xe7ff at device 0.0 on pci0 pcib1: PCIBIOS PCI-PCI bridge at device 1.0 on pci0 pci1: PCI bus on pcib1 IOAPIC #0 intpin 16 - irq 11 nvidia0: GeForce2 GTS mem 0xd800-0xdfff,0xd600-0xd6ff irq 11 at device 0.0 on pci1 isab0: PCI-ISA bridge at device 4.0 on pci0 isa0: ISA bus on isab0 atapci0: Intel PIIX4 ATA33 controller port 0xd800-0xd80f at device 4.1 on pci0 ata0: at 0x1f0 irq 14 on atapci0 ata1: at 0x170 irq 15 on atapci0 uhci0: Intel 82371AB/EB (PIIX4) USB controller port 0xd400-0xd41f irq 2 at device 4.2 on pci0 usb0: Intel 82371AB/EB (PIIX4) USB controller 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: Microsoft Microsoft IntelliMouse\M-. Explorer, rev 1.10/1.03, addr 2, iclass 3/1 ums0: 5 buttons and Z dir. Timecounter PIIX frequency 3579545 Hz pci0: bridge, PCI-unknown at device 4.3 (no driver attached) ahc0: Adaptec aic7880 Ultra SCSI adapter port 0xd000-0xd0ff mem 0xd580-0xd5800fff irq 2 at device 6.0 on pci0 aic7880: Ultra Wide Channel A, SCSI Id=7, 16/253 SCBs xl0: 3Com 3c905-TX Fast Etherlink XL port 0xb800-0xb83f irq 7 at device 10.0 on pci0 xl0: Ethernet address: 00:10:4b:3e:23:58 miibus0: MII bus on xl0 nsphy0: DP83840 10/100 media interface on miibus0 nsphy0: 10baseT, 10baseT-FDX, 100baseTX, 100baseTX-FDX, auto sio0 port 0x3f8-0x3ff irq 4 on acpi0 sio0: type 16550A, console sio1 port 0x2f8-0x2ff irq 3 on acpi0 sio1: type 16550A atkbdc0: Keyboard controller (i8042) port 0x64,0x60 irq 1 on acpi0 atkbd0: AT Keyboard flags 0x1 irq 1 on atkbdc0 kbd0 at atkbd0 orm0: Option ROMs at iomem 0xcc000-0xd0fff,0xc-0xcb7ff on isa0 pmtimer0 on isa0 sc0: System console at flags 0x100 on isa0 sc0: VGA 16 virtual consoles, flags=0x300 vga0: Generic ISA VGA at port 0x3c0-0x3df iomem 0xa-0xb on isa0 sbc0: Creative SB AWE64 Gold at port 0x388-0x38b,0x330-0x331,0x220-0x22f irq 5 drq 5,1 on isa0 pcm0: SB16 DSP 4.16 on sbc0 APIC_IO: Testing 8254 interrupt delivery APIC_IO: routing 8254 via IOAPIC #0 intpin 2 Timecounters tick every 10.000 msec ad0: 16479MB Maxtor 91728D8 [33483/16/63] at ata0-master UDMA33 ad2: 43979MB IBM-DTLA-307045 [89355/16/63] at ata1-master UDMA33 acd0: DVD-ROM CREATIVEDVD-ROM DVD2240E 12/24/97 at ata0-slave PIO4 Waiting 15 seconds for SCSI devices to settle cd0 at ahc0 bus 0 target 4 lun 0 cd0: PLEXTOR CD-R PX-R820T 1.03 Removable CD-ROM SCSI-2 device cd0: 5.000MB/s transfers (5.000MHz, offset 8) cd0: cd present [327986 x 2048 byte records] da0 at ahc0 bus 0 target 6 lun 0 da0: QUANTUM FIREBALL SE8.4S PJ09 Fixed Direct Access SCSI-2
