Re: freebsd panic on HP Proliant DL360
On Thu, Oct 12, 2006 at 11:56:21AM -0400, Ernest Natiello wrote:
E here we go:
E
E (kgdb) frame 7
E #7 0xc072191d in ip_ctloutput (so=0x1, sopt=0xe9226c90)
E at /usr/src/sys/netinet/ip_output.c:1184
E 1184INP_LOCK(inp);
E (kgdb) p *sopt
E $1 = {sopt_dir = SOPT_SET, sopt_level = 0, sopt_name = 1, sopt_val =
E 0x0,
E sopt_valsize = 0, sopt_td = 0xc73add80}
Not clear to me what IP option is it trying to set... sopt_valsize is 0.
Which port/package/software does tcpserver program belong to?
--
Totus tuus, Glebius.
GLEBIUS-RIPN GLEB-RIPE
___
freebsd-stable@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-stable
To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: freebsd panic on HP Proliant DL360
On Fri, 13 Oct 2006, 12:22+0400, Gleb Smirnoff wrote:
On Thu, Oct 12, 2006 at 11:56:21AM -0400, Ernest Natiello wrote:
E here we go:
E
E (kgdb) frame 7
E #7 0xc072191d in ip_ctloutput (so=0x1, sopt=0xe9226c90)
E at /usr/src/sys/netinet/ip_output.c:1184
E 1184INP_LOCK(inp);
E (kgdb) p *sopt
E $1 = {sopt_dir = SOPT_SET, sopt_level = 0, sopt_name = 1, sopt_val =
E 0x0,
E sopt_valsize = 0, sopt_td = 0xc73add80}
Not clear to me what IP option is it trying to set... sopt_valsize is 0.
Which port/package/software does tcpserver program belong to?
Gentlemen, sorry I interrupt you. What version of FreeBSD is that?
If it something RELENG_6 you should consider to upgrade to it. I
believe this panic was fixed by rwatson.
tcpserver comes from qmail I believe.
--
Maxim Konovalov
___
freebsd-stable@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-stable
To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: freebsd panic on HP Proliant DL360
On Fri, 2006-10-13 at 12:22 +0400, Gleb Smirnoff wrote: Which port/package/software does tcpserver program belong to? We do not use a FreeBSD package for tcpserver, compiled locally. It is used with qmail. ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: freebsd panic on HP Proliant DL360
On Fri, 2006-10-13 at 14:25 +0400, Maxim Konovalov wrote: Gentlemen, sorry I interrupt you. What version of FreeBSD is that? If it something RELENG_6 you should consider to upgrade to it. I believe this panic was fixed by rwatson. Do you have a date as to when this was patch was committed? One of the boxes undergoing the issue was cvsup'd and build as of Oct 4th. FreeBSD unix35 6.2-PRERELEASE FreeBSD 6.2-PRERELEASE #3: Wed Oct 4 11:11:37 EDT 2006 [EMAIL PROTECTED]:/usr/obj/usr/src/sys/UNIX35 i386 ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: freebsd panic on HP Proliant DL360
On Fri, Oct 13, 2006 at 10:50:43AM -0400, Ernest Natiello wrote: E On Fri, 2006-10-13 at 14:25 +0400, Maxim Konovalov wrote: E Gentlemen, sorry I interrupt you. What version of FreeBSD is that? E If it something RELENG_6 you should consider to upgrade to it. I E believe this panic was fixed by rwatson. E E Do you have a date as to when this was patch was committed? One of the E boxes undergoing the issue was cvsup'd and build as of Oct 4th. AFAIK, Robert made this panic less probable to happen in RELENG_6, but didn't eliminated it completely. -- Totus tuus, Glebius. GLEBIUS-RIPN GLEB-RIPE ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: freebsd panic on HP Proliant DL360
On Fri, 13 Oct 2006, 10:50-0400, Ernest Natiello wrote: On Fri, 2006-10-13 at 14:25 +0400, Maxim Konovalov wrote: Gentlemen, sorry I interrupt you. What version of FreeBSD is that? If it something RELENG_6 you should consider to upgrade to it. I believe this panic was fixed by rwatson. Do you have a date as to when this was patch was committed? One of the boxes undergoing the issue was cvsup'd and build as of Oct 4th. FreeBSD unix35 6.2-PRERELEASE FreeBSD 6.2-PRERELEASE #3: Wed Oct 4 11:11:37 EDT 2006 [EMAIL PROTECTED]:/usr/obj/usr/src/sys/UNIX35 i386 This is a different issue then. -- Maxim Konovalov ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: freebsd panic on HP Proliant DL360
On Wed, Oct 11, 2006 at 03:43:07PM -0400, Ernest Natiello wrote:
E Hello,
E I have 4 HP Proliant DL360's (1u) which panic/reboot often (minimum
E 1x month), but in a seemingly inconsistent manner. As per other
E suggestions, ipf was replaced with pf, an Intel pro 100 was added, the
E BGE device was disabled in the BIOS and the BGE driver was removed from
E the kernel. Also, Lights Out Management was disabled.
E None of the suggestions have cleared up the issue, so the BGE
E driver was added back to the kernel after reading the most recent
E developments in the posting:
This is a known problem. It is fixed in HEAD, but unfortunately it
isn't mergeable to RELENG_6. The problem isn't related to either pf,
ipf or NIC drivers.
What I'd suggest you to do is to workaround the problem removing
the problematic syscall from the userland program, that causes kernel
to trap.
I guess it is setsockopt(sock, IPPROTO_IP, ...). In some cases, for
example IP_TOS setting the syscall can be safely removed from the source code,
w/o affecting operability of the software.
Let's look what is the socket option, in gdb:
frame 7
p *sopt
And let's look the name of the process:
frame 11
p td-td_proc-p_comm
E -begin crash dump-
E (kgdb) where
E #0 doadump () at pcpu.h:165
E #1 0xc0682aaa in boot (howto=260)
E at /usr/src/sys/kern/kern_shutdown.c:409
E #2 0xc0682dd1 in panic (fmt=0xc088273f %s)
E at /usr/src/sys/kern/kern_shutdown.c:565
E #3 0xc0837de0 in trap_fatal (frame=0xe9226ab0, eva=260)
E at /usr/src/sys/i386/i386/trap.c:837
E #4 0xc0837596 in trap (frame=
E {tf_fs = -858718200, tf_es = 463994920, tf_ds = -383647704, tf_edi
E = -952443520, tf_esi = 4, tf_ebp = -383620356, tf_isp = -383620388,
E tf_ebx = -927947756, tf_edx = 6, tf_ecx = 0, tf_eax = 1, tf_trapno = 12,
E tf_err = 0, tf_eip = -1066951471, tf_cs = 32, tf_eflags = 65538, tf_esp
E = -383619952, tf_ss = -927947900}) at /usr/src/sys/i386/i386/trap.c:270
E #5 0xc08242ea in calltrap () at /usr/src/sys/i386/i386/exception.s:139
E #6 0xc0679cd1 in _mtx_lock_sleep (m=0xc8b0a414, tid=3342523776, opts=0,
E file=0x0, line=0) at /usr/src/sys/kern/kern_mutex.c:546
E #7 0xc072191d in ip_ctloutput (so=0x1, sopt=0xe9226c90)
E at /usr/src/sys/netinet/ip_output.c:1184
E #8 0xc072fe07 in tcp_ctloutput (so=0xc797b858, sopt=0xe9226c90)
E at /usr/src/sys/netinet/tcp_usrreq.c:1038
E #9 0xc06bea50 in sosetopt (so=0xc797b858, sopt=0xe9226c90)
E at /usr/src/sys/kern/uipc_socket.c:1563
E #10 0xc06c3dc5 in kern_setsockopt (td=0xc73add80, s=0, level=1, name=1,
E val=0x0, valseg=UIO_USERSPACE, valsize=6)
E at /usr/src/sys/kern/uipc_syscalls.c:1351
E #11 0xc06c3ce6 in setsockopt (td=0xc73add80, uap=0x1)
E at /usr/src/sys/kern/uipc_syscalls.c:1307
E #12 0xc0838127 in syscall (frame=
E {tf_fs = -65477, tf_es = 65595, tf_ds = -1078001605, tf_edi = 1,
E tf_esi = 0, tf_ebp = -1077941176, tf_isp = -383619740, tf_ebx = 0,
E tf_edx = 0, tf_ecx = 0, tf_eax = 105, tf_trapno = 12, tf_err = 2, tf_eip
E = 672093283, tf_cs = 51, tf_eflags = 642, tf_esp = -1077941220, tf_ss =
E 59})
E at /usr/src/sys/i386/i386/trap.c:983
E #13 0xc082433f in Xint0x80_syscall ()
E at /usr/src/sys/i386/i386/exception.s:200
E #14 0x0033 in ?? ()
E Previous frame inner to this frame (corrupt stack?)
E (kgdb)
E #0 doadump () at pcpu.h:165
E #1 0xc0682aaa in boot (howto=260)
E at /usr/src/sys/kern/kern_shutdown.c:409
E #2 0xc0682dd1 in panic (fmt=0xc088273f %s)
E at /usr/src/sys/kern/kern_shutdown.c:565
E #3 0xc0837de0 in trap_fatal (frame=0xe9226ab0, eva=260)
E at /usr/src/sys/i386/i386/trap.c:837
E #4 0xc0837596 in trap (frame=
E {tf_fs = -858718200, tf_es = 463994920, tf_ds = -383647704, tf_edi
E = -952443520, tf_esi = 4, tf_ebp = -383620356, tf_isp = -383620388,
E tf_ebx = -927947756, tf_edx = 6, tf_ecx = 0, tf_eax = 1, tf_trapno = 12,
E tf_err = 0, tf_eip = -1066951471, tf_cs = 32, tf_eflags = 65538, tf_esp
E = -383619952, tf_ss = -927947900}) at /usr/src/sys/i386/i386/trap.c:270
E #5 0xc08242ea in calltrap () at /usr/src/sys/i386/i386/exception.s:139
E #6 0xc0679cd1 in _mtx_lock_sleep (m=0xc8b0a414, tid=3342523776, opts=0,
E file=0x0, line=0) at /usr/src/sys/kern/kern_mutex.c:546
E #7 0xc072191d in ip_ctloutput (so=0x1, sopt=0xe9226c90)
E at /usr/src/sys/netinet/ip_output.c:1184
E #8 0xc072fe07 in tcp_ctloutput (so=0xc797b858, sopt=0xe9226c90)
E at /usr/src/sys/netinet/tcp_usrreq.c:1038
E #9 0xc06bea50 in sosetopt (so=0xc797b858, sopt=0xe9226c90)
E at /usr/src/sys/kern/uipc_socket.c:1563
E #10 0xc06c3dc5 in kern_setsockopt (td=0xc73add80, s=0, level=1, name=1,
E val=0x0, valseg=UIO_USERSPACE, valsize=6)
E at /usr/src/sys/kern/uipc_syscalls.c:1351
E #11 0xc06c3ce6 in setsockopt (td=0xc73add80, uap=0x1)
E at /usr/src/sys/kern/uipc_syscalls.c:1307
E #12 0xc0838127 in syscall (frame=
E {tf_fs = -65477, tf_es = 65595, tf_ds = -1078001605, tf_edi = 1,
E tf_esi = 0, tf_ebp = -1077941176,
Re: freebsd panic on HP Proliant DL360
This is a known problem. It is fixed in HEAD, but unfortunately it isn't mergeable to RELENG_6. The problem isn't related to either pf, ipf or NIC drivers. This is a little alarming - because what you seem to be saying is that if you have DL360's then you need to either run current, or accept that they will panic every so often for as long as you are running RELENG_6. We are looking to change our hardware soon, and DL360's were top of the list for replacements! Is there a PR reference for this describing the solution to the problem in HEAD somewhere that I could take a look at ? -pete. ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: freebsd panic on HP Proliant DL360
On Thu, Oct 12, 2006 at 11:03:36AM +0100, Pete French wrote: P This is a known problem. It is fixed in HEAD, but unfortunately it P isn't mergeable to RELENG_6. The problem isn't related to either pf, P ipf or NIC drivers. P P This is a little alarming - because what you seem to be saying is that P if you have DL360's then you need to either run current, or accept that P they will panic every so often for as long as you are running RELENG_6. P We are looking to change our hardware soon, and DL360's were top of the P list for replacements! Again, this has nothing to do with hardware. It is general problem in RELENG_6. P Is there a PR reference for this describing the solution to the problem P in HEAD somewhere that I could take a look at ? The problem wasn't fixed with a single commit. Maybe Robert, who is carbon copied, can provide more details. -- Totus tuus, Glebius. GLEBIUS-RIPN GLEB-RIPE ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: freebsd panic on HP Proliant DL360
Hello, Thank you very much for all of the help. I am trying to understand this issue, as it has been plaguing me for quite some time. So, extrapolating from the below kgdb output, am I to assume that the process causing the error is tcpserver? And should I further infer that tcpserver would cause this issue on all instances of FreeBSD RELENG_6, regardless of hardware? I have three other servers HP Proliant DL380s (2u) which are operating in a _similar_ capacity, (incoming vs. outgoing mailservers) running the exact same software, which have never had a problem. These three servers are running: FreeBSD unix29 6.1-PRERELEASE FreeBSD 6.1-PRERELEASE #0: Mon Mar 27 10:42:56 EST 2006 [EMAIL PROTECTED]:/usr/obj/usr/src/sys/UNIX34 i386 The operating system on this machine was rsync'd from one of the servers that is having the panic issue, yet it continues to operate flawlessly. I guess I could try swapping the services between two of the servers and see if the behavior follows the move. Does that sound viable? Thank you very much, Ernest Fatal trap 12: page fault while in kernel mode cpuid = 0; apic id = 00 fault virtual address = 0x104 fault code = supervisor read, page not present instruction pointer = 0x20:0xc0679cd1 stack pointer = 0x28:0xe9226af0 frame pointer = 0x28:0xe9226afc code segment= base 0x0, limit 0xf, type 0x1b = DPL 0, pres 1, def32 1, gran 1 processor eflags= resume, IOPL = 0 current process = 71782 (tcpserver) trap number = 12 panic: page fault cpuid = 0 Uptime: 1d7h12m9s Dumping 2047 MB (2 chunks) chunk 0: 1MB (159 pages) ... ok chunk 1: 2047MB (524026 pages) 2032 2016 2000 1984 1968 1952 1936 1920 1904 1888 1872 1856 1840 1824 1808 1792 1776 1760 1744 1728 1712 1696 1680 1664 1648 1632 1616 1600 1584 1568 1552 1536 1520 1504 1488 1472 1456 1440 1424 1408 1392 1376 1360 1344 1328 1312 1296 1280 1264 1248 1232 1216 1200 1184 1168 1152 1136 1120 1104 1088 1072 1056 1040 1024 1008 992 976 960 944 928 912 896 880 864 848 832 816 800 784 768 752 736 720 704 688 672 656 640 624 608 592 576 560 544 528 512 496 480 464 448 432 416 400 384 368 352 336 320 304 288 272 256 240 224 208 192 176 160 144 128 112 96 80 64 48 32 16 #0 doadump () at pcpu.h:165 165 __asm __volatile(movl %%fs:0,%0 : =r (td)); On Thu, 2006-10-12 at 14:15 +0400, Gleb Smirnoff wrote: On Thu, Oct 12, 2006 at 11:03:36AM +0100, Pete French wrote: P This is a known problem. It is fixed in HEAD, but unfortunately it P isn't mergeable to RELENG_6. The problem isn't related to either pf, P ipf or NIC drivers. P P This is a little alarming - because what you seem to be saying is that P if you have DL360's then you need to either run current, or accept that P they will panic every so often for as long as you are running RELENG_6. P We are looking to change our hardware soon, and DL360's were top of the P list for replacements! Again, this has nothing to do with hardware. It is general problem in RELENG_6. P Is there a PR reference for this describing the solution to the problem P in HEAD somewhere that I could take a look at ? The problem wasn't fixed with a single commit. Maybe Robert, who is carbon copied, can provide more details. ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: freebsd panic on HP Proliant DL360
On Thu, Oct 12, 2006 at 11:18:03AM -0400, Ernest Natiello wrote: E Hello, E Thank you very much for all of the help. I am trying to understand E this issue, as it has been plaguing me for quite some time. E So, extrapolating from the below kgdb output, am I to assume that E the process causing the error is tcpserver? Probably it is. However, can you run the gdb commands I mentioned in previous post, to make us sure. E And should I further infer E that tcpserver would cause this issue on all instances of FreeBSD E RELENG_6, regardless of hardware? I think so. A tcpserver(8) in given configuration. E I have three other servers HP Proliant DL380s (2u) which are E operating in a _similar_ capacity, (incoming vs. outgoing mailservers) E running the exact same software, which have never had a problem. E These three servers are running: FreeBSD unix29 6.1-PRERELEASE E FreeBSD 6.1-PRERELEASE #0: Mon Mar 27 10:42:56 EST 2006 E [EMAIL PROTECTED]:/usr/obj/usr/src/sys/UNIX34 i386 E The operating system on this machine was rsync'd from one of the E servers that is having the panic issue, yet it continues to operate E flawlessly. The discussed problem is a race between remote client closing TCP connection (may be resetting?), and local software performing setsockopt() system call on the same socket. It may happen that this particulat server has to deal with clients that drop the connection randomly, and other servers don't. That's why other servers are stable. E I guess I could try swapping the services between two of the E servers and see if the behavior follows the move. Does that sound E viable? You can try it. And don't forget to run gdb commands, and see what is the actual socket option that causes the problem. -- Totus tuus, Glebius. GLEBIUS-RIPN GLEB-RIPE ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: freebsd panic on HP Proliant DL360
here we go:
(kgdb) frame 7
#7 0xc072191d in ip_ctloutput (so=0x1, sopt=0xe9226c90)
at /usr/src/sys/netinet/ip_output.c:1184
1184INP_LOCK(inp);
(kgdb) p *sopt
$1 = {sopt_dir = SOPT_SET, sopt_level = 0, sopt_name = 1, sopt_val =
0x0,
sopt_valsize = 0, sopt_td = 0xc73add80}
(kgdb) frame 11
#11 0xc06c3ce6 in setsockopt (td=0xc73add80, uap=0x1)
at /usr/src/sys/kern/uipc_syscalls.c:1307
1307return (kern_setsockopt(td, uap-s, uap-level,
uap-name,
(kgdb) p td-td_proc-p_comm
$2 = tcpserver\000\000\000\000\000\000\000\000\000\000
(kgdb)
On Thu, 2006-10-12 at 19:48 +0400, Gleb Smirnoff wrote:
On Thu, Oct 12, 2006 at 11:18:03AM -0400, Ernest Natiello wrote:
E Hello,
E Thank you very much for all of the help. I am trying to understand
E this issue, as it has been plaguing me for quite some time.
E So, extrapolating from the below kgdb output, am I to assume that
E the process causing the error is tcpserver?
Probably it is. However, can you run the gdb commands I mentioned
in previous post, to make us sure.
E And should I further infer
E that tcpserver would cause this issue on all instances of FreeBSD
E RELENG_6, regardless of hardware?
I think so. A tcpserver(8) in given configuration.
E I have three other servers HP Proliant DL380s (2u) which are
E operating in a _similar_ capacity, (incoming vs. outgoing mailservers)
E running the exact same software, which have never had a problem.
E These three servers are running: FreeBSD unix29 6.1-PRERELEASE
E FreeBSD 6.1-PRERELEASE #0: Mon Mar 27 10:42:56 EST 2006
E [EMAIL PROTECTED]:/usr/obj/usr/src/sys/UNIX34 i386
E The operating system on this machine was rsync'd from one of the
E servers that is having the panic issue, yet it continues to operate
E flawlessly.
The discussed problem is a race between remote client closing TCP
connection (may be resetting?), and local software performing
setsockopt() system call on the same socket.
It may happen that this particulat server has to deal with clients
that drop the connection randomly, and other servers don't. That's
why other servers are stable.
E I guess I could try swapping the services between two of the
E servers and see if the behavior follows the move. Does that sound
E viable?
You can try it.
And don't forget to run gdb commands, and see what is the actual
socket option that causes the problem.
___
freebsd-stable@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-stable
To unsubscribe, send any mail to [EMAIL PROTECTED]
freebsd panic on HP Proliant DL360
Hello, I have 4 HP Proliant DL360's (1u) which panic/reboot often (minimum 1x month), but in a seemingly inconsistent manner. As per other suggestions, ipf was replaced with pf, an Intel pro 100 was added, the BGE device was disabled in the BIOS and the BGE driver was removed from the kernel. Also, Lights Out Management was disabled. None of the suggestions have cleared up the issue, so the BGE driver was added back to the kernel after reading the most recent developments in the posting: http://www.freebsd.org/cgi/query-pr.cgi?pr=96806 however the BGE device still remains disabled in the BIOS. One of the 4 servers is running: FreeBSD unix35 6.2-PRERELEASE FreeBSD 6.2-PRERELEASE #3: Wed Oct 4 11:11:37 EDT 2006 The other three are: FreeBSD unix34 6.1-STABLE FreeBSD 6.1-STABLE #0: Fri Jun 30 09:44:43 EDT 2006 They are running a custom kernel, adding SMP, pf and ALTQ options. INET6 was removed. I have added a dmesg, kernel config and kgdb where below. Any help would be appreciated. TIA, Ernest -begin dmesg- Copyright (c) 1992-2006 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 is a registered trademark of The FreeBSD Foundation. FreeBSD 6.2-PRERELEASE #3: Wed Oct 4 11:11:37 EDT 2006 [EMAIL PROTECTED]:/usr/obj/usr/src/sys/UNIX35 Timecounter i8254 frequency 1193182 Hz quality 0 CPU: Intel(R) Xeon(TM) CPU 2.80GHz (2799.22-MHz 686-class CPU) Origin = GenuineIntel Id = 0xf29 Stepping = 9 Features=0xbfebfbffFPU,VME,DE,PSE,TSC,MSR,PAE,MCE,CX8,APIC,SEP,MTRR,PGE,MCA,CMOV,PAT,PSE36,CLFLUSH,DTS,ACPI,MMX,FXSR,SSE,SSE2,SS,HTT,TM,PBE Features2=0x4400CNTX-ID,b14 Logical CPUs per core: 2 real memory = 2147459072 (2047 MB) avail memory = 2096345088 (1999 MB) ACPI APIC Table: COMPAQ 0083 FreeBSD/SMP: Multiprocessor System Detected: 4 CPUs cpu0 (BSP): APIC ID: 0 cpu1 (AP): APIC ID: 1 cpu2 (AP): APIC ID: 6 cpu3 (AP): APIC ID: 7 MADT: Forcing active-low polarity and level trigger for SCI ioapic0 Version 1.1 irqs 0-15 on motherboard ioapic1 Version 1.1 irqs 16-31 on motherboard ioapic2 Version 1.1 irqs 32-47 on motherboard ioapic3 Version 1.1 irqs 48-63 on motherboard acpi0: COMPAQ P31 on motherboard acpi0: Power Button (fixed) Timecounter ACPI-safe frequency 3579545 Hz quality 1000 acpi_timer0: 32-bit timer at 3.579545MHz port 0x920-0x923 on acpi0 cpu0: ACPI CPU on acpi0 cpu1: ACPI CPU on acpi0 cpu2: ACPI CPU on acpi0 cpu3: ACPI CPU on acpi0 pcib0: ACPI Host-PCI bridge on acpi0 pci0: ACPI PCI bus on pcib0 pci0: display, VGA at device 3.0 (no driver attached) ciss0: Compaq Smart Array 5i port 0x2800-0x28ff mem 0xf5f8-0xf5fb,0xf5df-0xf5df3fff irq 31 at device 4.0 on pci0 ciss0: [GIANT-LOCKED] pci0: base peripheral at device 5.0 (no driver attached) pci0: base peripheral at device 5.2 (no driver attached) isab0: PCI-ISA bridge at device 15.0 on pci0 isa0: ISA bus on isab0 atapci0: ServerWorks CSB5 UDMA100 controller port 0x1f0-0x1f7,0x3f6,0x170-0x177,0x376,0x2000-0x200f at device 15.1 on pci0 ata0: ATA channel 0 on atapci0 ata1: ATA channel 1 on atapci0 ohci0: OHCI (generic) USB controller mem 0xf5e7-0xf5e70fff irq 10 at device 15.2 on pci0 ohci0: [GIANT-LOCKED] usb0: OHCI version 1.0, legacy support usb0: SMM does not respond, resetting usb0: OHCI (generic) USB controller on ohci0 usb0: USB revision 1.0 uhub0: (0x1166) OHCI root hub, class 9/0, rev 1.00/1.00, addr 1 uhub0: 4 ports with 4 removable, self powered pcib1: ACPI Host-PCI bridge on acpi0 pci1: ACPI PCI bus on pcib1 pcib2: PCI-PCI bridge at device 1.0 on pci1 pci2: PCI bus on pcib2 fxp0: Intel 82551 Pro/100 Ethernet port 0x3000-0x303f mem 0xf7ff-0xf7ff0fff,0xf7fc-0xf7fd irq 28 at device 12.0 on pci2 miibus0: MII bus on fxp0 inphy0: i82555 10/100 media interface on miibus0 inphy0: 10baseT, 10baseT-FDX, 100baseTX, 100baseTX-FDX, auto fxp0: Ethernet address: 00:90:fb:01:f3:34 fxp1: Intel 82551 Pro/100 Ethernet port 0x3040-0x307f mem 0xf7fb-0xf7fb0fff,0xf7f8-0xf7f9 irq 27 at device 13.0 on pci2 miibus1: MII bus on fxp1 inphy1: i82555 10/100 media interface on miibus1 inphy1: 10baseT, 10baseT-FDX, 100baseTX, 100baseTX-FDX, auto fxp1: Ethernet address: 00:90:fb:01:f3:35 pcib3: ACPI Host-PCI bridge on acpi0 pci4: ACPI PCI bus on pcib3 acpi_tz0: Thermal Zone on acpi0 atkbdc0: Keyboard controller (i8042) port 0x60,0x64 irq 1 on acpi0 atkbd0: AT Keyboard irq 1 on atkbdc0 kbd0 at atkbd0 atkbd0: [GIANT-LOCKED] sio0: Standard PC COM port port 0x3f8-0x3ff irq 4 flags 0x10 on acpi0 sio0: type 16550A fdc0: floppy drive controller (FDE) port 0x3f2-0x3f5 irq 6 drq 2 on acpi0 fdc0: [FAST] fd0: 1440-KB 3.5 drive on fdc0 drive 0 pmtimer0 on isa0 orm0: ISA Option ROMs at iomem 0xc-0xc7fff,0xc8000-0xcbfff,0xee000-0xe on isa0 ppc0: parallel port not found. sc0: System console at flags 0x100 on isa0 sc0: VGA 16 virtual consoles, flags=0x300 sio1: configured irq
