Re: SAS HBA LSI 9200-8e supported under 8.2?
hi, Am Dienstag, den 22.03.2011, 02:10 +0300 schrieb Dmitry Morozovsky: > and about to out it into day-to-day use 8.2-stable system, working as > big-just-in-case archive with sources from Mar1 based on SuperMicro > case/mobo > with LSI SAS2008 + LSI expander + 24 SATA RE4 disk bays. exactly the same to us: LSI SAS Expander switch, with 4 x LSI JBOD630J with 12 x 2TB SAS disks. The internal SATA disks are only for BSD, nothing more :-) So i try to get it working now. cu denny signature.asc Description: This is a digitally signed message part
Re: Firefox startup impacted by distributed.net client
Original message, from ten months ago: http://lists.freebsd.org/pipermail/freebsd-hackers/2010-May/031915.html Briefly, running the distributed.net client on my FreeBSD 8.0 box made Firefox take forever to start up (90 seconds vs. 2 seconds). The distributed.net client is essentially 100% CPU bound, with occasional file I/O and even more occasional socket I/O, running at nice 20. The problem has persisted since then. So I finally compiled up a kernel using SCHED_4BSD instead of SCHED_ULE. Problem fixed. It still doesn't give me a warm, fuzzy feeling about FreeBSD 8.0, since I still have the awful NFS client performance problem (though not as bad as before the Rick Macklem patch).-- George Mitchell ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to "freebsd-stable-unsubscr...@freebsd.org"
Re: Firefox startup impacted by distributed.net client
Have you tried 8 stable? On 23 Mar 2011 22:12, "George Mitchell" wrote: > Original message, from ten months ago: > > http://lists.freebsd.org/pipermail/freebsd-hackers/2010-May/031915.html > > Briefly, running the distributed.net client on my FreeBSD 8.0 box > made Firefox take forever to start up (90 seconds vs. 2 seconds). > The distributed.net client is essentially 100% CPU bound, with > occasional file I/O and even more occasional socket I/O, running > at nice 20. The problem has persisted since then. > > So I finally compiled up a kernel using SCHED_4BSD instead of > SCHED_ULE. Problem fixed. > > It still doesn't give me a warm, fuzzy feeling about FreeBSD 8.0, > since I still have the awful NFS client performance problem (though > not as bad as before the Rick Macklem patch). -- George Mitchell > ___ > freebsd-stable@freebsd.org mailing list > http://lists.freebsd.org/mailman/listinfo/freebsd-stable > To unsubscribe, send any mail to "freebsd-stable-unsubscr...@freebsd.org" ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to "freebsd-stable-unsubscr...@freebsd.org"
Re: Firefox startup impacted by distributed.net client
On 03/23/11 17:57, Matthias Gamsjager wrote: Have you tried 8 stable? The box I tried SCHED_4BSD on was running 8.2_PRERELEASE, which still had the problem described. Has the scheduler changed significantly between 8.2_PRERELEASE and stable? -- George Mitchell On 23 Mar 2011 22:12, "George Mitchell" wrote: Original message, from ten months ago: http://lists.freebsd.org/pipermail/freebsd-hackers/2010-May/031915.html Briefly, running the distributed.net client on my FreeBSD 8.0 box made Firefox take forever to start up (90 seconds vs. 2 seconds). The distributed.net client is essentially 100% CPU bound, with occasional file I/O and even more occasional socket I/O, running at nice 20. The problem has persisted since then. So I finally compiled up a kernel using SCHED_4BSD instead of SCHED_ULE. Problem fixed. It still doesn't give me a warm, fuzzy feeling about FreeBSD 8.0, since I still have the awful NFS client performance problem (though not as bad as before the Rick Macklem patch). -- George Mitchell ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to "freebsd-stable-unsubscr...@freebsd.org" ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to "freebsd-stable-unsubscr...@freebsd.org" ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to "freebsd-stable-unsubscr...@freebsd.org"
Re: Firefox startup impacted by distributed.net client
On Wed, Mar 23, 2011 at 06:24:05PM -0400, George Mitchell wrote: > On 03/23/11 17:57, Matthias Gamsjager wrote: > >Have you tried 8 stable? > > The box I tried SCHED_4BSD on was running 8.2_PRERELEASE, which still > had the problem described. Has the scheduler changed significantly > between 8.2_PRERELEASE and stable? -- George Mitchell > > >On 23 Mar 2011 22:12, "George Mitchell" wrote: > >>Original message, from ten months ago: > >> > >>http://lists.freebsd.org/pipermail/freebsd-hackers/2010-May/031915.html > >> > >>Briefly, running the distributed.net client on my FreeBSD 8.0 box > >>made Firefox take forever to start up (90 seconds vs. 2 seconds). > >>The distributed.net client is essentially 100% CPU bound, with > >>occasional file I/O and even more occasional socket I/O, running > >>at nice 20. The problem has persisted since then. > >> > >>So I finally compiled up a kernel using SCHED_4BSD instead of > >>SCHED_ULE. Problem fixed. > >> > >>It still doesn't give me a warm, fuzzy feeling about FreeBSD 8.0, > >>since I still have the awful NFS client performance problem (though > >>not as bad as before the Rick Macklem patch). -- George Mitchell No, it hasn't. You didn't provide any hardware details of your system in the link you referenced (post to -hackers). It matters. dmesg output (regardless of what scheduler you're using in the kernel) would be useful. Output from the command "sysctl kern.sched.topology_spec" might also help. So would your kernel configuration file. :-) Focusing solely on the first/main paragraph of your linked post (CPU usage and system responsiveness, not memory usage): There have been discussions in the past of SCHED_ULE not performing well on single-core systems, and lots of discussions of "unfriendly behaviour" caused on multi-core systems (where X is running and audio skips when doing things like moving a window, etc.). I believe one of the workarounds people recommended was to adjust the below sysctl, increasing it from 64 (default) to 224: kern.sched.preempt_thresh=224 I would recommend trying this if possible. It would at least rule out one thing for troubleshooting. The brief discussion (you might have to read/dig around the thread a bit) in question that I remember: http://unix.derkeiler.com/Mailing-Lists/FreeBSD/stable/2010-09/msg00155.html http://unix.derkeiler.com/Mailing-Lists/FreeBSD/stable/2010-09/msg00157.html As for the next paragraph of your linked post (memory usage and firefox-bin): I can't explain what "ucond" represents in top. That is to say: I know what the STATE field is about, but I can't tell you code-wise what "ucond" represents functionally; my guess is some condition relating to a kernel mutex (thread lock). The relevant code bits in src/sys/kern/kern_umtx.c are over my head. I'm sure a kernel hacker can explain this, but it probably isn't relevant to your problem. -- | Jeremy Chadwick j...@parodius.com | | Parodius Networking http://www.parodius.com/ | | UNIX Systems Administrator Mountain View, CA, USA | | Making life hard for others since 1977. PGP 4BD6C0CB | ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to "freebsd-stable-unsubscr...@freebsd.org"
Re: Firefox startup impacted by distributed.net client
On 03/23/11 18:52, Jeremy Chadwick wrote: On Wed, Mar 23, 2011 at 06:24:05PM -0400, George Mitchell wrote: On 03/23/11 17:57, Matthias Gamsjager wrote: Have you tried 8 stable? The box I tried SCHED_4BSD on was running 8.2_PRERELEASE, which still had the problem described. Has the scheduler changed significantly between 8.2_PRERELEASE and stable? -- George Mitchell On 23 Mar 2011 22:12, "George Mitchell" wrote: Original message, from ten months ago: http://lists.freebsd.org/pipermail/freebsd-hackers/2010-May/031915.html Briefly, running the distributed.net client on my FreeBSD 8.0 box made Firefox take forever to start up (90 seconds vs. 2 seconds). The distributed.net client is essentially 100% CPU bound, with occasional file I/O and even more occasional socket I/O, running at nice 20. The problem has persisted since then. So I finally compiled up a kernel using SCHED_4BSD instead of SCHED_ULE. Problem fixed. It still doesn't give me a warm, fuzzy feeling about FreeBSD 8.0, since I still have the awful NFS client performance problem (though not as bad as before the Rick Macklem patch). -- George Mitchell No, it hasn't. You didn't provide any hardware details of your system in the link you referenced (post to -hackers). It matters. dmesg output (regardless of what scheduler you're using in the kernel) would be useful. Copyright (c) 1992-2011 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 8.2-PRERELEASE #0: Mon Mar 21 16:03:28 EDT 2011 geo...@scollay.m5p.com:/usr/obj/usr/src/sys/SCOLLAY amd64 Timecounter "i8254" frequency 1193182 Hz quality 0 CPU: AMD Sempron(tm) 140 Processor (2712.36-MHz K8-class CPU) Origin = "AuthenticAMD" Id = 0x100f62 Family = 10 Model = 6 Stepping = 2 Features=0x78bfbff Features2=0x802009 AMD Features=0xee500800 AMD Features2=0x37fd TSC: P-state invariant real memory = 2147483648 (2048 MB) avail memory = 1792958464 (1709 MB) ACPI APIC Table: <012810 APIC1758> ioapic0 irqs 0-23 on motherboard kbd1 at kbdmux0 acpi0: <012810 RSDT1758> on motherboard acpi0: [ITHREAD] acpi0: Power Button (fixed) acpi0: reservation of 0, a (3) failed acpi0: reservation of 10, 6ff0 (3) failed Timecounter "ACPI-fast" frequency 3579545 Hz quality 1000 acpi_timer0: <24-bit timer at 3.579545MHz> port 0x508-0x50b on acpi0 cpu0: on acpi0 pcib0: port 0xcf8-0xcff on acpi0 pci0: on pcib0 pci0: at device 0.0 (no driver attached) isab0: port 0x900-0x9ff at device 1.0 on pci0 isa0: on isab0 pci0: at device 1.1 (no driver attached) pci0: at device 1.2 (no driver attached) ohci0: mem 0xdfffb000-0xdfffbfff irq 21 at device 2.0 on pci0 ohci0: [ITHREAD] usbus0: on ohci0 ehci0: mem 0xdfffac00-0xdfffacff irq 22 at device 2.1 on pci0 ehci0: [ITHREAD] usbus1: EHCI version 1.0 usbus1: on ehci0 pcib1: at device 4.0 on pci0 pci1: on pcib1 hdac0: mem 0xdfff4000-0xdfff7fff irq 23 at device 5.0 on pci0 hdac0: HDA Driver Revision: 20100226_0142 hdac0: [ITHREAD] atapci0: port 0x1f0-0x1f7,0x3f6,0x170-0x177,0x376,0xffa0-0xffaf at device 6.0 on pci0 ata0: on atapci0 ata0: [ITHREAD] ata1: on atapci0 ata1: [ITHREAD] nfe0: port 0xe480-0xe487 mem 0xdfff9000-0xdfff9fff irq 20 at device 7.0 on pci0 miibus0: on nfe0 rgephy0: PHY 3 on miibus0 rgephy0: 10baseT, 10baseT-FDX, 10baseT-FDX-flow, 100baseTX, 100baseTX-FDX, 100baseTX-FDX-flow, 1000baseT, 1000baseT-master, 1000baseT-FDX, 1000baseT-FDX-master, 1000baseT-FDX-flow, 1000baseT-FDX-flow-master, auto, auto-flow nfe0: Ethernet address: 48:5b:39:07:a8:78 nfe0: [FILTER] nfe0: [FILTER] nfe0: [FILTER] nfe0: [FILTER] nfe0: [FILTER] nfe0: [FILTER] nfe0: [FILTER] nfe0: [FILTER] atapci1: port 0xe400-0xe407,0xe080-0xe083,0xe000-0xe007,0xdc00-0xdc03,0xd880-0xd88f mem 0xdfff8000-0xdfff8fff irq 21 at device 8.0 on pci0 atapci1: [ITHREAD] ata2: on atapci1 ata2: [ITHREAD] ata3: on atapci1 ata3: [ITHREAD] atapci2: port 0xd800-0xd807,0xd480-0xd483,0xd400-0xd407,0xd080-0xd083,0xd000-0xd00f mem 0xdffef000-0xdffe irq 22 at device 8.1 on pci0 atapci2: [ITHREAD] ata4: on atapci2 ata4: [ITHREAD] ata5: on atapci2 ata5: [ITHREAD] pcib2: at device 9.0 on pci0 pci2: on pcib2 pcib3: at device 11.0 on pci0 pci3: on pcib3 pcib4: at device 12.0 on pci0 pci4: on pcib4 vgapci0: mem 0xde00-0xdeff,0xc000-0xcfff,0xdd00-0xddff irq 23 at device 13.0 on pci0 acpi_button0: on acpi0 atrtc0: port 0x70-0x71 irq 8 on acpi0 ppc0: port 0x378-0x37f irq 7 on acpi0 ppc0: Generic chipset (NIBBLE-only) in COMPATIBLE mode ppc0: [ITHREAD] ppbus0: on ppc0 ppi0: on ppbus0 plip0: on ppbus0 plip0: [ITHREAD] lpt0: on ppbus0 lpt0: [ITHREAD] lpt0: Interrupt-driven port acpi_hpet0: iomem 0xfed0-0xfed00fff on acpi0 Timecounter "HPET" frequency 2500 Hz quality 900 atkbdc0: port 0x60,0x64 irq
Re: Firefox startup impacted by distributed.net client
On Wed, Mar 23, 2011 at 07:09:11PM -0400, George Mitchell wrote: > On 03/23/11 18:52, Jeremy Chadwick wrote: > >On Wed, Mar 23, 2011 at 06:24:05PM -0400, George Mitchell wrote: > >>On 03/23/11 17:57, Matthias Gamsjager wrote: > >>>Have you tried 8 stable? > >> > >>The box I tried SCHED_4BSD on was running 8.2_PRERELEASE, which still > >>had the problem described. Has the scheduler changed significantly > >>between 8.2_PRERELEASE and stable? -- George Mitchell > >> > >>>On 23 Mar 2011 22:12, "George Mitchell" wrote: > Original message, from ten months ago: > > http://lists.freebsd.org/pipermail/freebsd-hackers/2010-May/031915.html > > Briefly, running the distributed.net client on my FreeBSD 8.0 box > made Firefox take forever to start up (90 seconds vs. 2 seconds). > The distributed.net client is essentially 100% CPU bound, with > occasional file I/O and even more occasional socket I/O, running > at nice 20. The problem has persisted since then. > > So I finally compiled up a kernel using SCHED_4BSD instead of > SCHED_ULE. Problem fixed. > > It still doesn't give me a warm, fuzzy feeling about FreeBSD 8.0, > since I still have the awful NFS client performance problem (though > not as bad as before the Rick Macklem patch). -- George Mitchell > > > >No, it hasn't. > > > >You didn't provide any hardware details of your system in the link you > >referenced (post to -hackers). It matters. dmesg output (regardless of > >what scheduler you're using in the kernel) would be useful. > > Copyright (c) 1992-2011 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 8.2-PRERELEASE #0: Mon Mar 21 16:03:28 EDT 2011 > geo...@scollay.m5p.com:/usr/obj/usr/src/sys/SCOLLAY amd64 > Timecounter "i8254" frequency 1193182 Hz quality 0 > CPU: AMD Sempron(tm) 140 Processor (2712.36-MHz K8-class CPU) > Origin = "AuthenticAMD" Id = 0x100f62 Family = 10 Model = 6 > Stepping = 2 > > Features=0x78bfbff > Features2=0x802009 > AMD > Features=0xee500800 > AMD > Features2=0x37fd > TSC: P-state invariant > real memory = 2147483648 (2048 MB) > avail memory = 1792958464 (1709 MB) > ACPI APIC Table: <012810 APIC1758> > ioapic0 irqs 0-23 on motherboard > kbd1 at kbdmux0 > acpi0: <012810 RSDT1758> on motherboard > acpi0: [ITHREAD] > acpi0: Power Button (fixed) > acpi0: reservation of 0, a (3) failed > acpi0: reservation of 10, 6ff0 (3) failed > Timecounter "ACPI-fast" frequency 3579545 Hz quality 1000 > acpi_timer0: <24-bit timer at 3.579545MHz> port 0x508-0x50b on acpi0 > cpu0: on acpi0 > pcib0: port 0xcf8-0xcff on acpi0 > pci0: on pcib0 > pci0: at device 0.0 (no driver attached) > isab0: port 0x900-0x9ff at device 1.0 on pci0 > isa0: on isab0 > pci0: at device 1.1 (no driver attached) > pci0: at device 1.2 (no driver attached) > ohci0: mem > 0xdfffb000-0xdfffbfff irq 21 at device 2.0 on pci0 > ohci0: [ITHREAD] > usbus0: on ohci0 > ehci0: mem > 0xdfffac00-0xdfffacff irq 22 at device 2.1 on pci0 > ehci0: [ITHREAD] > usbus1: EHCI version 1.0 > usbus1: on ehci0 > pcib1: at device 4.0 on pci0 > pci1: on pcib1 > hdac0: mem > 0xdfff4000-0xdfff7fff irq 23 at device 5.0 on pci0 > hdac0: HDA Driver Revision: 20100226_0142 > hdac0: [ITHREAD] > atapci0: port > 0x1f0-0x1f7,0x3f6,0x170-0x177,0x376,0xffa0-0xffaf at device 6.0 on > pci0 > ata0: on atapci0 > ata0: [ITHREAD] > ata1: on atapci0 > ata1: [ITHREAD] > nfe0: port 0xe480-0xe487 > mem 0xdfff9000-0xdfff9fff irq 20 at device 7.0 on pci0 > miibus0: on nfe0 > rgephy0: PHY 3 on miibus0 > rgephy0: 10baseT, 10baseT-FDX, 10baseT-FDX-flow, 100baseTX, > 100baseTX-FDX, 100baseTX-FDX-flow, 1000baseT, 1000baseT-master, > 1000baseT-FDX, 1000baseT-FDX-master, 1000baseT-FDX-flow, > 1000baseT-FDX-flow-master, auto, auto-flow > nfe0: Ethernet address: 48:5b:39:07:a8:78 > nfe0: [FILTER] > nfe0: [FILTER] > nfe0: [FILTER] > nfe0: [FILTER] > nfe0: [FILTER] > nfe0: [FILTER] > nfe0: [FILTER] > nfe0: [FILTER] > atapci1: port > 0xe400-0xe407,0xe080-0xe083,0xe000-0xe007,0xdc00-0xdc03,0xd880-0xd88f > mem 0xdfff8000-0xdfff8fff irq 21 at device 8.0 on pci0 > atapci1: [ITHREAD] > ata2: on atapci1 > ata2: [ITHREAD] > ata3: on atapci1 > ata3: [ITHREAD] > atapci2: port > 0xd800-0xd807,0xd480-0xd483,0xd400-0xd407,0xd080-0xd083,0xd000-0xd00f > mem 0xdffef000-0xdffe irq 22 at device 8.1 on pci0 > atapci2: [ITHREAD] > ata4: on atapci2 > ata4: [ITHREAD] > ata5: on atapci2 > ata5: [ITHREAD] > pcib2: at device 9.0 on pci0 > pci2: on pcib2 > pcib3: at device 11.0 on pci0 > pci3: on pcib3 > pcib4: at device 12.0 on pci0 > pci4: on pcib4 > vgapci0: mem > 0xde00-0xdeff,0xc000-0xcfff,0xdd00-0xddff > irq 23 at device 13.0 on pci0 > acpi_button0: on acpi0 > atrtc0: port 0x70-0x7
Re: Firefox startup impacted by distributed.net client
On Wed, 23 Mar 2011 19:21, freebsd@ wrote: On Wed, Mar 23, 2011 at 07:09:11PM -0400, George Mitchell wrote: On 03/23/11 18:52, Jeremy Chadwick wrote: On Wed, Mar 23, 2011 at 06:24:05PM -0400, George Mitchell wrote: On 03/23/11 17:57, Matthias Gamsjager wrote: Have you tried 8 stable? The box I tried SCHED_4BSD on was running 8.2_PRERELEASE, which still had the problem described. Has the scheduler changed significantly between 8.2_PRERELEASE and stable? -- George Mitchell On 23 Mar 2011 22:12, "George Mitchell" wrote: Original message, from ten months ago: http://lists.freebsd.org/pipermail/freebsd-hackers/2010-May/031915.html Briefly, running the distributed.net client on my FreeBSD 8.0 box made Firefox take forever to start up (90 seconds vs. 2 seconds). The distributed.net client is essentially 100% CPU bound, with occasional file I/O and even more occasional socket I/O, running at nice 20. The problem has persisted since then. So I finally compiled up a kernel using SCHED_4BSD instead of SCHED_ULE. Problem fixed. It still doesn't give me a warm, fuzzy feeling about FreeBSD 8.0, since I still have the awful NFS client performance problem (though not as bad as before the Rick Macklem patch). -- George Mitchell No, it hasn't. You didn't provide any hardware details of your system in the link you referenced (post to -hackers). It matters. dmesg output (regardless of what scheduler you're using in the kernel) would be useful. Copyright (c) 1992-2011 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 8.2-PRERELEASE #0: Mon Mar 21 16:03:28 EDT 2011 geo...@scollay.m5p.com:/usr/obj/usr/src/sys/SCOLLAY amd64 Timecounter "i8254" frequency 1193182 Hz quality 0 CPU: AMD Sempron(tm) 140 Processor (2712.36-MHz K8-class CPU) Origin = "AuthenticAMD" Id = 0x100f62 Family = 10 Model = 6 Stepping = 2 Features=0x78bfbff Features2=0x802009 AMD Features=0xee500800 AMD Features2=0x37fd TSC: P-state invariant real memory = 2147483648 (2048 MB) avail memory = 1792958464 (1709 MB) ACPI APIC Table: <012810 APIC1758> ioapic0 irqs 0-23 on motherboard kbd1 at kbdmux0 acpi0: <012810 RSDT1758> on motherboard acpi0: [ITHREAD] acpi0: Power Button (fixed) acpi0: reservation of 0, a (3) failed acpi0: reservation of 10, 6ff0 (3) failed Timecounter "ACPI-fast" frequency 3579545 Hz quality 1000 acpi_timer0: <24-bit timer at 3.579545MHz> port 0x508-0x50b on acpi0 cpu0: on acpi0 pcib0: port 0xcf8-0xcff on acpi0 pci0: on pcib0 pci0: at device 0.0 (no driver attached) isab0: port 0x900-0x9ff at device 1.0 on pci0 isa0: on isab0 pci0: at device 1.1 (no driver attached) pci0: at device 1.2 (no driver attached) ohci0: mem 0xdfffb000-0xdfffbfff irq 21 at device 2.0 on pci0 ohci0: [ITHREAD] usbus0: on ohci0 ehci0: mem 0xdfffac00-0xdfffacff irq 22 at device 2.1 on pci0 ehci0: [ITHREAD] usbus1: EHCI version 1.0 usbus1: on ehci0 pcib1: at device 4.0 on pci0 pci1: on pcib1 hdac0: mem 0xdfff4000-0xdfff7fff irq 23 at device 5.0 on pci0 hdac0: HDA Driver Revision: 20100226_0142 hdac0: [ITHREAD] atapci0: port 0x1f0-0x1f7,0x3f6,0x170-0x177,0x376,0xffa0-0xffaf at device 6.0 on pci0 ata0: on atapci0 ata0: [ITHREAD] ata1: on atapci0 ata1: [ITHREAD] nfe0: port 0xe480-0xe487 mem 0xdfff9000-0xdfff9fff irq 20 at device 7.0 on pci0 miibus0: on nfe0 rgephy0: PHY 3 on miibus0 rgephy0: 10baseT, 10baseT-FDX, 10baseT-FDX-flow, 100baseTX, 100baseTX-FDX, 100baseTX-FDX-flow, 1000baseT, 1000baseT-master, 1000baseT-FDX, 1000baseT-FDX-master, 1000baseT-FDX-flow, 1000baseT-FDX-flow-master, auto, auto-flow nfe0: Ethernet address: 48:5b:39:07:a8:78 nfe0: [FILTER] nfe0: [FILTER] nfe0: [FILTER] nfe0: [FILTER] nfe0: [FILTER] nfe0: [FILTER] nfe0: [FILTER] nfe0: [FILTER] atapci1: port 0xe400-0xe407,0xe080-0xe083,0xe000-0xe007,0xdc00-0xdc03,0xd880-0xd88f mem 0xdfff8000-0xdfff8fff irq 21 at device 8.0 on pci0 atapci1: [ITHREAD] ata2: on atapci1 ata2: [ITHREAD] ata3: on atapci1 ata3: [ITHREAD] atapci2: port 0xd800-0xd807,0xd480-0xd483,0xd400-0xd407,0xd080-0xd083,0xd000-0xd00f mem 0xdffef000-0xdffe irq 22 at device 8.1 on pci0 atapci2: [ITHREAD] ata4: on atapci2 ata4: [ITHREAD] ata5: on atapci2 ata5: [ITHREAD] pcib2: at device 9.0 on pci0 pci2: on pcib2 pcib3: at device 11.0 on pci0 pci3: on pcib3 pcib4: at device 12.0 on pci0 pci4: on pcib4 vgapci0: mem 0xde00-0xdeff,0xc000-0xcfff,0xdd00-0xddff irq 23 at device 13.0 on pci0 acpi_button0: on acpi0 atrtc0: port 0x70-0x71 irq 8 on acpi0 ppc0: port 0x378-0x37f irq 7 on acpi0 ppc0: Generic chipset (NIBBLE-only) in COMPATIBLE mode ppc0: [ITHREAD] ppbus0: on ppc0 ppi0: on ppbus0 plip0: on ppbus0 plip0: [ITHREAD] lpt0: on ppbus0 lpt0: [ITHREAD] lpt0: Interrupt-driven port acpi_hpet0: iomem 0xfed0-0xfed00fff on acpi0
