FreeBSD 13 Beta2 very slow boot
Hey. Was the 13 beta 2 AMD64 image compiled and released with debug settings active ? EFI portion of the boot is an order of magnitude at least slower than Beta 1. ___ freebsd-current@freebsd.org mailing list https://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to "freebsd-current-unsubscr...@freebsd.org"
Re: Slow boot with 256GB of RAM?
On 16 November 2013 17:49, Eitan Adler li...@eitanadler.com wrote: On Sat, Nov 16, 2013 at 4:12 PM, Zach Crum crum.z...@gmail.com wrote: This setting is not listed in /boot/defaults/loader.conf. Is it supposed to be singular or plural? Plural. I will commit the patch. The FAQ update patch looks fine. Does any know of cases where this memory test actually catches errors? How important is it? The boot time test is primarily of historical significance, and doesn't really provide value on contemporary systems. It's mainly a workaround for ancient broken BIOSes that might return bogus memory map data. I intend to commit the patch below that disables it by default. The variable name is hw.memtest.tests as it's intended to be extended to a bitmap of tests to run at boot, with other bits representing more comprehensive tests. -Ed commit 58f501f70427ce2aeb9c8b18d2b7bec543818dae Author: Ed Maste ema...@freebsd.org Date: Thu Nov 21 12:31:06 2013 -0500 Disable amd64 boot time memory test by default The page presence memory test takes a long time on large memory systems and has little value on contemporary amd64 hardware. diff --git a/sys/amd64/amd64/machdep.c b/sys/amd64/amd64/machdep.c index 7f05d58..df03e55 100644 --- a/sys/amd64/amd64/machdep.c +++ b/sys/amd64/amd64/machdep.c @@ -1476,13 +1476,15 @@ getmemsize(caddr_t kmdp, u_int64_t first) Maxmem = atop(physmem_tunable); /* -* By default enable the memory test on real hardware, and disable -* it if we appear to be running in a VM. This avoids touching all -* pages unnecessarily, which doesn't matter on real hardware but is -* bad for shared VM hosts. Use a general name so that -* one could eventually do more with the code than just disable it. +* The boot memory test is disabled by default, as it takes a +* significant amount of time on large-memory systems, and is +* unfriendly to virtual machines as it unnecessarily touches all +* pages. +* +* A general name is used as the code may be extended to support +* additional tests beyond the current page present test. */ - memtest = (vm_guest VM_GUEST_NO) ? 0 : 1; + memtest = 0; TUNABLE_ULONG_FETCH(hw.memtest.tests, memtest); /* ___ freebsd-current@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to freebsd-current-unsubscr...@freebsd.org
Re: Slow boot with 256GB of RAM?
On Thu, Nov 21, 2013 at 12:42 PM, Ed Maste ema...@freebsd.org wrote: The variable name is hw.memtest.tests as it's intended to be extended to a bitmap of tests to run at boot, with other bits representing more comprehensive tests. -Ed commit 58f501f70427ce2aeb9c8b18d2b7bec543818dae Author: Ed Maste ema...@freebsd.org Date: Thu Nov 21 12:31:06 2013 -0500 Disable amd64 boot time memory test by default The page presence memory test takes a long time on large memory systems and has little value on contemporary amd64 hardware. This patch looks good to me. Please commit it. :) ___ freebsd-current@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to freebsd-current-unsubscr...@freebsd.org
Re: Slow boot with 256GB of RAM?
At the risk of facetiousness, the nice thing about FreeBSD is that you have to deal with this problem only a few times per year. ;) ___ freebsd-current@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to freebsd-current-unsubscr...@freebsd.org
Re: Slow boot with 256GB of RAM?
On 2013-11-16 00:48, Matthias Petermann wrote: Hello James, Am 16.11.2013 05:37, schrieb James R. Van Artsdalen: Asus Z9PA-U8 motherboard, 256GB of RAM, 2.4 GHz Xeon E5-2695 v2, FreeBSD 11.0-CURRENT r258092 There is a two minute pause when booting, after the loader's SMAP display and the initial kernel output, Does anyone know what's going on here? Even that much RAM shouldn't take that much time to clear. in an earlier discussion at FreeBSD Forums[1] it looks like this is related to some early stage memory test which is performed. It can be disabled by adding hw.memtest.tests=0 to /boot/loader.conf. For my 32GB machine this helped. Best regards, Matthias [1] http://forums.freebsd.org/showthread.php?t=12705 I see this was in the release notes for 9.0 and 8.3, but other than that, I don't see how anyone was supposed to find out about this Maybe it would make sense to print 'Starting memory test, set hw.memtest.test=0 to disable' before that starts, so anyone stuck waiting will have a hint about what to do. -- Allan Jude signature.asc Description: OpenPGP digital signature
Re: Slow boot with 256GB of RAM?
On 11/16/2013 8:52 AM, Allan Jude wrote: I see this was in the release notes for 9.0 and 8.3, but other than that, I don't see how anyone was supposed to find out about this. Maybe it would make sense to print 'Starting memory test, set hw.memtest.test=0 to disable' before that starts, so anyone stuck waiting will have a hint about what to do. It takes less effort to speed it up than to document that it is slow.. For now, in my sources, I've lengthened the testing stride to 64KB. A better fix would leave the cache on (don't fight the cache in a memory test - it is your friend! :-) and to group all writes and reads together in a larger chunk - say 16MB - so as to take advantage of write combining and cache line fetching. And add writes of address-specific values so address space aliasing can be detected. ___ freebsd-current@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to freebsd-current-unsubscr...@freebsd.org
Re: Slow boot with 256GB of RAM?
On 2013-11-16 13:36, James R. Van Artsdalen wrote: On 11/16/2013 8:52 AM, Allan Jude wrote: I see this was in the release notes for 9.0 and 8.3, but other than that, I don't see how anyone was supposed to find out about this. Maybe it would make sense to print 'Starting memory test, set hw.memtest.test=0 to disable' before that starts, so anyone stuck waiting will have a hint about what to do. A patch for the FAQ to add an entry about the hw.memtest.test=0 to speed up boot on machines with a lot of ram -- Allan Jude Index: en_US.ISO8859-1/books/faq/book.xml === --- en_US.ISO8859-1/books/faq/book.xml (revision 43198) +++ en_US.ISO8859-1/books/faq/book.xml (working copy) @@ -3669,6 +3669,26 @@ in man.tunefs.8;./para /answer /qandaentry + + qandaentry + question xml:id=slow-boot-memtest + paraWhy does os; pause for a long time at boot when the + system has large amounts of ram?/para + /question + + answer + paraos; does a short memory test early in the boot + process. This test usually only takes several seconds, + however if the system has many 10s or 100s of gigabytes + of memory it can take up to a few minutes. This test + can be disabled by setting the + literalhw.memtest.tests/literal to + literal0/literal in + filename/boot/loader.conf/filename/para + + paraFor more details, see man.loader.conf.5;./para + /answer + /qandaentry /qandaset sect1 xml:id=all-about-zfs signature.asc Description: OpenPGP digital signature
Re: Slow boot with 256GB of RAM?
On Sat, Nov 16, 2013 at 4:12 PM, Zach Crum crum.z...@gmail.com wrote: This setting is not listed in /boot/defaults/loader.conf. Is it supposed to be singular or plural? Plural. I will commit the patch. Does any know of cases where this memory test actually catches errors? How important is it? -- Eitan Adler ___ freebsd-current@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to freebsd-current-unsubscr...@freebsd.org
Slow boot with 256GB of RAM?
Asus Z9PA-U8 motherboard, 256GB of RAM, 2.4 GHz Xeon E5-2695 v2, FreeBSD 11.0-CURRENT r258092 There is a two minute pause when booting, after the loader's SMAP display and the initial kernel output, Does anyone know what's going on here? Even that much RAM shouldn't take that much time to clear. ___ freebsd-current@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to freebsd-current-unsubscr...@freebsd.org
Re: Slow boot with 256GB of RAM?
On 2013-11-15 23:37, James R. Van Artsdalen wrote: Asus Z9PA-U8 motherboard, 256GB of RAM, 2.4 GHz Xeon E5-2695 v2, FreeBSD 11.0-CURRENT r258092 There is a two minute pause when booting, after the loader's SMAP display and the initial kernel output, Does anyone know what's going on here? Even that much RAM shouldn't take that much time to clear. ___ freebsd-current@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to freebsd-current-unsubscr...@freebsd.org It is a known issue (I have a few E5-2620s with 96 and 144gb of ram) There was talk at MeetBSD last year about making at least output a dot for each 1 or 8gb of something so you knew it was at least doing something, not sure whatever happened to that. It would be nice if it didn't that that long -- Allan Jude signature.asc Description: OpenPGP digital signature
Re: Slow boot with 256GB of RAM?
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Hello James, Am 16.11.2013 05:37, schrieb James R. Van Artsdalen: Asus Z9PA-U8 motherboard, 256GB of RAM, 2.4 GHz Xeon E5-2695 v2, FreeBSD 11.0-CURRENT r258092 There is a two minute pause when booting, after the loader's SMAP display and the initial kernel output, Does anyone know what's going on here? Even that much RAM shouldn't take that much time to clear. in an earlier discussion at FreeBSD Forums[1] it looks like this is related to some early stage memory test which is performed. It can be disabled by adding hw.memtest.tests=0 to /boot/loader.conf. For my 32GB machine this helped. Best regards, Matthias [1] http://forums.freebsd.org/showthread.php?t=12705 - -- Matthias Petermann matth...@petermann-it.de | www.petermann-it.de GnuPG: 0x5C3E6D75 | 5930 86EF 7965 2BBA 6572 C3D7 7B1D A3C3 5C3E 6D75 -BEGIN PGP SIGNATURE- Version: GnuPG v2.0.22 (FreeBSD) Comment: Using GnuPG with Thunderbird - http://www.enigmail.net/ iQIcBAEBAgAGBQJShwcbAAoJEHsdo8NcPm11kTMQAI3sxsltJ7Se/CaZ7QsMmkFy THULbdDLEAIJYBhfgfMh+wsK4DNu5uj+u8uL52hP2MjbV7MPOWX27xUYrGjbC1HZ /QIcz+sAXvxV3eclLhlLuNtdZIh8U2ORQ20VleT/wsoAw0UuP4Bu/+akiVRWiEyF /FfGfFolczMrcNQpt4Y3XbTaADTRVsx9ZmU7ZRDg+KKt+oRPGsngo75GwkCiiwVg Ew+nSjlUB4pXiPW5teaG6asg2tLIgArVilJE7PP8mPGsz0rBf/gArGCyw3OweYzv gmJ13nfVrOWAlz9ZYL8KFg1eON4qb2G3Trjl3g4rr/7vYoi2XXz19zevkxv/kDKi xJCtHzVGFW0Dh6QN0M8tHc5aqb3+kLsulxEbDPDcmWGw7DPeFfRXYx8VNXLGphJC +f1Br/WUa0K6BiRgn+yKHS9IX6P5s4aY2xyCMmcRoH7Q5YjCdKHOrdtqKwjMIPRm BL0n+Viwwcu2qWmpTYNfQpcIRhAhc3F1v6RPxa8t3WYopBopkllFb/z8AbtWr8fF kuCcEmw0PdKxSQgHHdTmy5UW2f+pDvCX3h5qX9inks8PMq1JWYwNz+7WTfDb4Bvn pHWLE3RM78DpTDGXRuyoiwZEqh/KzHbwIw7pqWApjgINc7nifaNCRoYbxKSYVJ2s TfnjxAn2tXfe5nLqA00E =ePIV -END PGP SIGNATURE- ___ freebsd-current@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to freebsd-current-unsubscr...@freebsd.org
Re: Slow boot with 256GB of RAM?
On Sat, 16 Nov 2013 06:48:11 +0100 Matthias Petermann matth...@petermann-it.de wrote: -BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Hello James, Am 16.11.2013 05:37, schrieb James R. Van Artsdalen: Asus Z9PA-U8 motherboard, 256GB of RAM, 2.4 GHz Xeon E5-2695 v2, FreeBSD 11.0-CURRENT r258092 There is a two minute pause when booting, after the loader's SMAP display and the initial kernel output, Does anyone know what's going on here? Even that much RAM shouldn't take that much time to clear. in an earlier discussion at FreeBSD Forums[1] it looks like this is related to some early stage memory test which is performed. It can be disabled by adding hw.memtest.tests=0 to /boot/loader.conf. For my 32GB machine this helped. +1. (box with 128GB ram) Best regards, Matthias [1] http://forums.freebsd.org/showthread.php?t=12705 - -- Matthias Petermann matth...@petermann-it.de | www.petermann-it.de GnuPG: 0x5C3E6D75 | 5930 86EF 7965 2BBA 6572 C3D7 7B1D A3C3 5C3E 6D75 -BEGIN PGP SIGNATURE- Version: GnuPG v2.0.22 (FreeBSD) Comment: Using GnuPG with Thunderbird - http://www.enigmail.net/ iQIcBAEBAgAGBQJShwcbAAoJEHsdo8NcPm11kTMQAI3sxsltJ7Se/CaZ7QsMmkFy THULbdDLEAIJYBhfgfMh+wsK4DNu5uj+u8uL52hP2MjbV7MPOWX27xUYrGjbC1HZ /QIcz+sAXvxV3eclLhlLuNtdZIh8U2ORQ20VleT/wsoAw0UuP4Bu/+akiVRWiEyF /FfGfFolczMrcNQpt4Y3XbTaADTRVsx9ZmU7ZRDg+KKt+oRPGsngo75GwkCiiwVg Ew+nSjlUB4pXiPW5teaG6asg2tLIgArVilJE7PP8mPGsz0rBf/gArGCyw3OweYzv gmJ13nfVrOWAlz9ZYL8KFg1eON4qb2G3Trjl3g4rr/7vYoi2XXz19zevkxv/kDKi xJCtHzVGFW0Dh6QN0M8tHc5aqb3+kLsulxEbDPDcmWGw7DPeFfRXYx8VNXLGphJC +f1Br/WUa0K6BiRgn+yKHS9IX6P5s4aY2xyCMmcRoH7Q5YjCdKHOrdtqKwjMIPRm BL0n+Viwwcu2qWmpTYNfQpcIRhAhc3F1v6RPxa8t3WYopBopkllFb/z8AbtWr8fF kuCcEmw0PdKxSQgHHdTmy5UW2f+pDvCX3h5qX9inks8PMq1JWYwNz+7WTfDb4Bvn pHWLE3RM78DpTDGXRuyoiwZEqh/KzHbwIw7pqWApjgINc7nifaNCRoYbxKSYVJ2s TfnjxAn2tXfe5nLqA00E =ePIV -END PGP SIGNATURE- ___ freebsd-current@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to freebsd-current-unsubscr...@freebsd.org -- wbr, tiger ___ freebsd-current@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to freebsd-current-unsubscr...@freebsd.org
Re: Slow Boot
What does pciconf -vl show on the affected machine(s)? Andre Guibert de Bruet | Enterprise Software Consultant Silicon Landmark, LLC. | http://siliconlandmark.com/ On Sun, 17 Aug 2003, Bill Moran wrote: Mike Atamas wrote: When my system boots it seems to stall when it gets here: xa807,0xa400-0xa403,0xa000-0xa007 mem 0xe100-0xe10001ff irq 11 at device 11. 0 on pci1 ata2: at 0xe100 on atapci0 ata3: at 0xe100 on atapci0 It stalls for about 20-30 seconds and then continues booting. I can not figure out what the problem is or how to solve it. Has anyone had similar issues. I've seen this on various hardware. I actually have a 200mhz machine sitting here that has always done this. I've never seen it cause any problems, and I've never had any suggestions on how to stop it either. My best guess is that the chipset responds slowly to probes, thus it takes a while to get the list of devices from it. However, I've never looked into it any more than that. ___ [EMAIL PROTECTED] mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: Slow Boot
Bill Moran wrote: It stalls for about 20-30 seconds and then continues booting. I can not figure out what the problem is or how to solve it. Has anyone had similar issues. I've seen this on various hardware. I actually have a 200mhz machine sitting here that has always done this. I've never seen it cause any problems, and I've never had any suggestions on how to stop it either. In init_main.c, verify that the current value for the thing being initialized is greater than SI_SUB_CONSOLE. If it is, then print out the name of the thing being initialized before you make the call. Whatever prints before a long delay is your culprit. -- Terry ___ [EMAIL PROTECTED] mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: Slow Boot
Matthew D. Fuller wrote: On Sun, Aug 17, 2003 at 02:55:46PM -0400 I heard the voice of Bill Moran, and lo! it spake thus: My best guess is that the chipset responds slowly to probes, thus it takes a while to get the list of devices from it. However, I've never looked into it any more than that. I've always presumed it to be a question of timing out probes to the drives; it only ever happens on IDE controllers with no devices attached to 'em. I habitually just disable the controller channels that are empty (or, in the case of my SCSI systems, just yank ATA support altogether). Could be. This machine is pretty bare-bones. Single ATA HDD and nothing on the secondary controller. I never really considered that, but it makes sense that probes on the secondary controller would take the full timeout value if there was nothing to respond. -- Bill Moran Potential Technologies http://www.potentialtech.com ___ [EMAIL PROTECTED] mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: Slow Boot
Andre Guibert de Bruet wrote: What does pciconf -vl show on the affected machine(s)? [EMAIL PROTECTED]:0:0: class=0x06 card=0x chip=0x12378086 rev=0x02 hdr=0x00 vendor = 'Intel Corporation' device = '82440/1FX 440FX (Natoma) System Controller' class= bridge subclass = HOST-PCI [EMAIL PROTECTED]:1:0: class=0x060100 card=0x chip=0x70008086 rev=0x01 hdr=0x00 vendor = 'Intel Corporation' device = '82371SB PIIX3 PCI-to-ISA Bridge (Triton II)' class= bridge subclass = PCI-ISA [EMAIL PROTECTED]:1:1: class=0x010180 card=0x chip=0x70108086 rev=0x00 hdr=0x00 vendor = 'Intel Corporation' device = '82371SB PIIX3 IDE Interface (Triton II)' class= mass storage subclass = ATA [EMAIL PROTECTED]:1:2: class=0x0c0300 card=0x chip=0x70208086 rev=0x01 hdr=0x00 vendor = 'Intel Corporation' device = '82371SB PIIX3 USB Host Controller (Triton II)' class= serial bus subclass = USB [EMAIL PROTECTED]:10:0: class=0x02 card=0x100010b7 chip=0x920010b7 rev=0x74 hdr=0x00 vendor = '3COM Corp, Networking Division' device = '3C905C-TX Fast EtherLink for PC Management NIC' class= network subclass = ethernet [EMAIL PROTECTED]:11:0: class=0x02 card=0x813910ec chip=0x813910ec rev=0x10 hdr=0x00 vendor = 'Realtek Semiconductor' device = 'RT8139 (A/B/C/8130) Fast Ethernet Adapter' class= network subclass = ethernet [EMAIL PROTECTED]:12:0: class=0x03 card=0x47501002 chip=0x47501002 rev=0x5c hdr=0x00 vendor = 'ATI Technologies' device = 'Rage 3D Pro PCI Graphics Accelerator' class= display subclass = VGA e fu Andre Guibert de Bruet | Enterprise Software Consultant Silicon Landmark, LLC. | http://siliconlandmark.com/ On Sun, 17 Aug 2003, Bill Moran wrote: Mike Atamas wrote: When my system boots it seems to stall when it gets here: xa807,0xa400-0xa403,0xa000-0xa007 mem 0xe100-0xe10001ff irq 11 at device 11. 0 on pci1 ata2: at 0xe100 on atapci0 ata3: at 0xe100 on atapci0 It stalls for about 20-30 seconds and then continues booting. I can not figure out what the problem is or how to solve it. Has anyone had similar issues. I've seen this on various hardware. I actually have a 200mhz machine sitting here that has always done this. I've never seen it cause any problems, and I've never had any suggestions on how to stop it either. My best guess is that the chipset responds slowly to probes, thus it takes a while to get the list of devices from it. However, I've never looked into it any more than that. -- Bill Moran Potential Technologies http://www.potentialtech.com ___ [EMAIL PROTECTED] mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: Slow Boot
Date: Mon, 18 Aug 2003 08:45:36 -0400 From: Bill Moran [EMAIL PROTECTED] Sender: [EMAIL PROTECTED] Matthew D. Fuller wrote: On Sun, Aug 17, 2003 at 02:55:46PM -0400 I heard the voice of Bill Moran, and lo! it spake thus: My best guess is that the chipset responds slowly to probes, thus it takes a while to get the list of devices from it. However, I've never looked into it any more than that. I've always presumed it to be a question of timing out probes to the drives; it only ever happens on IDE controllers with no devices attached to 'em. I habitually just disable the controller channels that are empty (or, in the case of my SCSI systems, just yank ATA support altogether). Could be. This machine is pretty bare-bones. Single ATA HDD and nothing on the secondary controller. I never really considered that, but it makes sense that probes on the secondary controller would take the full timeout value if there was nothing to respond. Nope. My system has disks on both ATA controllers with hard drives as the master for each channel. One channel also has the CD drive as the slave. -- R. Kevin Oberman, Network Engineer Energy Sciences Network (ESnet) Ernest O. Lawrence Berkeley National Laboratory (Berkeley Lab) E-mail: [EMAIL PROTECTED] Phone: +1 510 486-8634 ___ [EMAIL PROTECTED] mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: Slow Boot
Andre Guibert de Bruet wrote: What does pciconf -vl show on the affected machine(s)? [EMAIL PROTECTED]:0:0: class=0x06 card=0x154110b9 chip=0x154110b9 rev=0x04 hdr=0x00vendor = 'Acer Labs Incorporated (ALi)' device = 'ALI M1541 Aladdin V/V+ AGP System Controller' class= bridge subclass = HOST-PCI [EMAIL PROTECTED]:1:0: class=0x060400 card=0x00e0 chip=0x524310b9 rev=0x04 hdr=0x01vendor = 'Acer Labs Incorporated (ALi)' device = 'ALI M1541 PCI to AGP Bridge' class= bridge subclass = PCI-PCI [EMAIL PROTECTED]:3:0: class=0x068000 card=0x710110b9 chip=0x710110b9 rev=0x00 hdr=0x00vendor = 'Acer Labs Incorporated (ALi)' device = 'ALI M7101 Power Management Controller' class= bridge subclass = PCI-unknown [EMAIL PROTECTED]:7:0: class=0x060100 card=0x chip=0x153310b9 rev=0xc3 hdr=0x00vendor = 'Acer Labs Incorporated (ALi)' device = 'ALI M1533 Aladdin IV ISA Bridge' class= bridge subclass = PCI-ISA [EMAIL PROTECTED]:9:0: class=0x040100 card=0x13711274 chip=0x13711274 rev=0x08 hdr=0x00vendor = 'Creative (Was: Ensoniq)' device = 'ES1371, ES1373 AudioPCI' class= multimedia subclass = audio [EMAIL PROTECTED]:11:0: class=0x02 card=0x905510b7 chip=0x905510b7 rev=0x30 hdr=0x00vendor = '3COM Corp, Networking Division' device = '3C905B-TX Fast Etherlink 10/100 PCI TX NIC' class= network subclass = ethernet [EMAIL PROTECTED]:15:0: class=0x01018a card=0x chip=0x522910b9 rev=0xc1 hdr=0x00 vendor = 'Acer Labs Incorporated (ALi)' device = 'M1543 Southbridge EIDE Controller' class= mass storage subclass = ATA [EMAIL PROTECTED]:0:0: class=0x03 card=0x0338102b chip=0x0525102b rev=0x04 hdr=0x00vendor = 'Matrox Graphics Inc' device = 'MGA-G400/450 Chipset' class= display subclass = VGA -- R. Kevin Oberman, Network Engineer Energy Sciences Network (ESnet) Ernest O. Lawrence Berkeley National Laboratory (Berkeley Lab) E-mail: [EMAIL PROTECTED] Phone: +1 510 486-8634 ___ [EMAIL PROTECTED] mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: Slow Boot
[CC list trimed] On Mon, 18 Aug 2003, Kevin Oberman wrote: From: Bill Moran [EMAIL PROTECTED] Matthew D. Fuller wrote: On Sun, Aug 17, 2003 at 02:55:46PM -0400 I heard the voice of Bill Moran, and lo! it spake thus: My best guess is that the chipset responds slowly to probes, thus it takes a while to get the list of devices from it. However, I've never looked into it any more than that. I've always presumed it to be a question of timing out probes to the drives; it only ever happens on IDE controllers with no devices attached to 'em. I habitually just disable the controller channels that are empty (or, in the case of my SCSI systems, just yank ATA support altogether). Could be. This machine is pretty bare-bones. Single ATA HDD and nothing on the secondary controller. I never really considered that, but it makes sense that probes on the secondary controller would take the full timeout value if there was nothing to respond. Nope. My system has disks on both ATA controllers with hard drives as the master for each channel. One channel also has the CD drive as the slave. Does the hard drive that's on it's own have a Single jumper configuration option available? Andre Guibert de Bruet | Enterprise Software Consultant Silicon Landmark, LLC. | http://siliconlandmark.com/ ___ [EMAIL PROTECTED] mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: Slow Boot
Date: Mon, 18 Aug 2003 11:09:05 -0400 (EDT) From: Andre Guibert de Bruet [EMAIL PROTECTED] [CC list trimed] On Mon, 18 Aug 2003, Kevin Oberman wrote: From: Bill Moran [EMAIL PROTECTED] Matthew D. Fuller wrote: On Sun, Aug 17, 2003 at 02:55:46PM -0400 I heard the voice of Bill Moran, and lo! it spake thus: My best guess is that the chipset responds slowly to probes, thus it takes a while to get the list of devices from it. However, I've never looked into it any more than that. I've always presumed it to be a question of timing out probes to the drives; it only ever happens on IDE controllers with no devices attached to 'em. I habitually just disable the controller channels that are empty (or, in the case of my SCSI systems, just yank ATA support altogether). Could be. This machine is pretty bare-bones. Single ATA HDD and nothing on the secondary controller. I never really considered that, but it makes sense that probes on the secondary controller would take the full timeout value if there was nothing to respond. Nope. My system has disks on both ATA controllers with hard drives as the master for each channel. One channel also has the CD drive as the slave. Does the hard drive that's on it's own have a Single jumper configuration option available? I'm not sure what a Single jumper is, but the drive is jumpered as master. The only options are master, slave, and Cable Select. -- R. Kevin Oberman, Network Engineer Energy Sciences Network (ESnet) Ernest O. Lawrence Berkeley National Laboratory (Berkeley Lab) E-mail: [EMAIL PROTECTED] Phone: +1 510 486-8634 ___ [EMAIL PROTECTED] mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: Slow Boot
On Mon, 18 Aug 2003, Kevin Oberman wrote: Date: Mon, 18 Aug 2003 11:09:05 -0400 (EDT) From: Andre Guibert de Bruet [EMAIL PROTECTED] On Mon, 18 Aug 2003, Kevin Oberman wrote: From: Bill Moran [EMAIL PROTECTED] Matthew D. Fuller wrote: On Sun, Aug 17, 2003 at 02:55:46PM -0400 I heard the voice of Bill Moran, and lo! it spake thus: My best guess is that the chipset responds slowly to probes, thus it takes a while to get the list of devices from it. However, I've never looked into it any more than that. I've always presumed it to be a question of timing out probes to the drives; it only ever happens on IDE controllers with no devices attached to 'em. I habitually just disable the controller channels that are empty (or, in the case of my SCSI systems, just yank ATA support altogether). Could be. This machine is pretty bare-bones. Single ATA HDD and nothing on the secondary controller. I never really considered that, but it makes sense that probes on the secondary controller would take the full timeout value if there was nothing to respond. Nope. My system has disks on both ATA controllers with hard drives as the master for each channel. One channel also has the CD drive as the slave. Does the hard drive that's on it's own have a Single jumper configuration option available? I'm not sure what a Single jumper is, but the drive is jumpered as master. The only options are master, slave, and Cable Select. It's a jumper configuration that's commonly found on Western Digital IDE drives. It might also be labelled Master w/o slave. Weirdness occurs (I've seen write errors and timeouts) when these drives sit on an otherwise empty IDE channel while they are set as 'master'. Andre Guibert de Bruet | Enterprise Software Consultant Silicon Landmark, LLC. | http://siliconlandmark.com/ ___ [EMAIL PROTECTED] mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to [EMAIL PROTECTED]
Slow Boot
When my system boots it seems to stall when it gets here: xa807,0xa400-0xa403,0xa000-0xa007 mem 0xe100-0xe10001ff irq 11 at device 11. 0 on pci1 ata2: at 0xe100 on atapci0 ata3: at 0xe100 on atapci0 It stalls for about 20-30 seconds and then continues booting. I can not figure out what the problem is or how to solve it. Has anyone had similar issues. Mike Atamas [EMAIL PROTECTED] ___ [EMAIL PROTECTED] mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: Slow Boot
Mike Atamas wrote: When my system boots it seems to stall when it gets here: xa807,0xa400-0xa403,0xa000-0xa007 mem 0xe100-0xe10001ff irq 11 at device 11. 0 on pci1 ata2: at 0xe100 on atapci0 ata3: at 0xe100 on atapci0 It stalls for about 20-30 seconds and then continues booting. I can not figure out what the problem is or how to solve it. Has anyone had similar issues. I've seen this on various hardware. I actually have a 200mhz machine sitting here that has always done this. I've never seen it cause any problems, and I've never had any suggestions on how to stop it either. My best guess is that the chipset responds slowly to probes, thus it takes a while to get the list of devices from it. However, I've never looked into it any more than that. -- Bill Moran Potential Technologies http://www.potentialtech.com ___ [EMAIL PROTECTED] mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: Slow Boot
I have been seeing this for some time ( 2 years) on my ASUS P5A based K6 system. I have no idea why it's doing it, but I re-boot so infrequently that I just have not worried about it. It does seem that it is less likely to happen after a true cold boot. (Cut main power.) I was seeing this with V4 and I'm seeing it with V5. I don't think I ever saw it back on V3, but that was a LONG time ago. It may have started when some change was made to the ATA driver, but I really can't say since it's been doing it for so long. -- R. Kevin Oberman, Network Engineer Energy Sciences Network (ESnet) Ernest O. Lawrence Berkeley National Laboratory (Berkeley Lab) E-mail: [EMAIL PROTECTED] Phone: +1 510 486-8634 ___ [EMAIL PROTECTED] mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: Slow Boot
On Sun, Aug 17, 2003 at 02:55:46PM -0400 I heard the voice of Bill Moran, and lo! it spake thus: My best guess is that the chipset responds slowly to probes, thus it takes a while to get the list of devices from it. However, I've never looked into it any more than that. I've always presumed it to be a question of timing out probes to the drives; it only ever happens on IDE controllers with no devices attached to 'em. I habitually just disable the controller channels that are empty (or, in the case of my SCSI systems, just yank ATA support altogether). -- Matthew Fuller (MF4839) | [EMAIL PROTECTED] Systems/Network Administrator | http://www.over-yonder.net/~fullermd/ The only reason I'm burning my candle at both ends, is because I haven't figured out how to light the middle yet ___ [EMAIL PROTECTED] mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: Slow Boot
On Sun, 17 Aug 2003 22:35:14 -0400 (EDT) Andre Guibert de Bruet [EMAIL PROTECTED] wrote: pciconf -vl Here is the output that it gave. I included everything because nothing particular struck me as relavent. [EMAIL PROTECTED]:0:0: class=0x06 card=0x80ac1043 chip=0x01e010de rev=0xc1 hdr=0x00 vendor = 'NVIDIA Corporation' device = 'nForce2 AGP Controller' class= bridge subclass = HOST-PCI [EMAIL PROTECTED]:0:1: class=0x05 card=0x0c1710de chip=0x01eb10de rev=0xc1 hdr=0x00 vendor = 'NVIDIA Corporation' device = 'nForce2 Memory Controller 1' class= memory subclass = RAM [EMAIL PROTECTED]:0:2: class=0x05 card=0x0c1710de chip=0x01ee10de rev=0xc1 hdr=0x00 vendor = 'NVIDIA Corporation' device = 'nForce2 Memory Controller 4' class= memory subclass = RAM [EMAIL PROTECTED]:0:3: class=0x05 card=0x0c1710de chip=0x01ed10de rev=0xc1 hdr=0x00 vendor = 'NVIDIA Corporation' device = 'nForce2 Memory Controller 3' class= memory subclass = RAM [EMAIL PROTECTED]:0:4: class=0x05 card=0x0c1710de chip=0x01ec10de rev=0xc1 hdr=0x00 vendor = 'NVIDIA Corporation' device = 'nForce2 Memory Controller 2' class= memory subclass = RAM [EMAIL PROTECTED]:0:5: class=0x05 card=0x0c1710de chip=0x01ef10de rev=0xc1 hdr=0x00 vendor = 'NVIDIA Corporation' device = 'nForce2 Memory Controller 5' class= memory subclass = RAM [EMAIL PROTECTED]:1:0: class=0x060100 card=0x80ad1043 chip=0x006010de rev=0xa4 hdr=0x00 vendor = 'NVIDIA Corporation' device = 'nForce MCP2 ISA Bridge' class= bridge subclass = PCI-ISA [EMAIL PROTECTED]:1:1: class=0x0c0500 card=0x0c111043 chip=0x006410de rev=0xa2 hdr=0x00 vendor = 'NVIDIA Corporation' device = 'nForce MCP-T? SMBus Controller' class= serial bus subclass = SMBus [EMAIL PROTECTED]:2:0: class=0x0c0310 card=0x0c111043 chip=0x006710de rev=0xa4 hdr=0x00 vendor = 'NVIDIA Corporation' device = 'nForce MCP2 OpenHCI USB Controller' class= serial bus subclass = USB [EMAIL PROTECTED]:2:1: class=0x0c0310 card=0x0c111043 chip=0x006710de rev=0xa4 hdr=0x00 vendor = 'NVIDIA Corporation' device = 'nForce MCP2 OpenHCI USB Controller' class= serial bus subclass = USB [EMAIL PROTECTED]:2:2: class=0x0c0320 card=0x0c111043 chip=0x006810de rev=0xa4 hdr=0x00 vendor = 'NVIDIA Corporation' device = 'nForce MCP2 EHCI USB 2.0 Controller' class= serial bus subclass = USB [EMAIL PROTECTED]:4:0: class=0x02 card=0x80a71043 chip=0x006610de rev=0xa1 hdr=0x00 vendor = 'NVIDIA Corporation' device = 'nForce MCP2 Networking Adapter' class= network subclass = ethernet [EMAIL PROTECTED]:5:0: class=0x040100 card=0x0c111043 chip=0x006b10de rev=0xa2 hdr=0x00 vendor = 'NVIDIA Corporation' device = 'nForce MCP-T? Audio Processing Unit (Dolby Digital)' class= multimedia subclass = audio [EMAIL PROTECTED]:6:0: class=0x040100 card=0x80951043 chip=0x006a10de rev=0xa1 hdr=0x00 vendor = 'NVIDIA Corporation' device = 'nForce MCP2 Audio Codec Interface' class= multimedia subclass = audio [EMAIL PROTECTED]:8:0: class=0x060400 card=0x chip=0x006c10de rev=0xa3 hdr=0x01 vendor = 'NVIDIA Corporation' device = 'nForce PCI to PCI Bridge' class= bridge subclass = PCI-PCI [EMAIL PROTECTED]:9:0: class=0x01018a card=0x0c111043 chip=0x006510de rev=0xa2 hdr=0x00 vendor = 'NVIDIA Corporation' device = 'nForce MCP2 EIDE Controller' class= mass storage subclass = ATA [EMAIL PROTECTED]:12:0: class=0x060400 card=0x chip=0x006d10de rev=0xa3 hdr=0x01 vendor = 'NVIDIA Corporation' class= bridge subclass = PCI-PCI [EMAIL PROTECTED]:13:0: class=0x0c0010 card=0x809a1043 chip=0x006e10de rev=0xa3 hdr=0x00 vendor = 'NVIDIA Corporation' device = 'nForce MCP2 OHCI Compliant IEEE 1394 Controller' class= serial bus subclass = FireWire [EMAIL PROTECTED]:30:0: class=0x060400 card=0x chip=0x01e810de rev=0xc1 hdr=0x01 vendor = 'NVIDIA Corporation' device = 'nForce2 AGP Host to PCI Bridge' class= bridge subclass = PCI-PCI [EMAIL PROTECTED]:11:0: class=0x010400 card=0x61121095 chip=0x31121095 rev=0x02 hdr=0x00 vendor = 'Silicon Image Inc (Was: CMD Technology Inc)' device = 'SiI 3112 SATARaid Controller' class= mass storage subclass = RAID [EMAIL PROTECTED]:1:0: class=0x02 card=0x80ab1043 chip=0x920110b7 rev=0x40 hdr=0x00 vendor = '3COM Corp, Networking Division' class= network subclass = ethernet [EMAIL PROTECTED]:0:0: class=0x03 card=0x40081043 chip=0x010010de rev=0x10 hdr=0x00 vendor = 'NVIDIA Corporation' device = 'GeForce 256 [NV10]' class= display subclass = VGA
Extremely slow boot?
Hi, I've been running FreeBSD since 3.4. I had built a machine to replace my old fileserver, but decided to hold off on switching them around and use the machine to test out 5.0 on. The machine itself is a Tyan Tiger LE (S2515, ServerWorks ServerSet III-LE chipset), dual PIII/733EB, 512M RAM, DPT PM2865U3 64-bit, dual-channel, U160 SCSI RAID controller, on-board Intel Pro/100 ethernet and on-board ATi Rage video. I'm running a bunch of Seagate 9.1G drives in RAID 1/0, an IDE CD-ROM at ata0-master and an IDE CD-RW at ata1-master. The machine worked perfectly with everything before 5.0. I tried to install DP2, but the hardware detection during boot seemed to hang after detecting vga0. I thought that the problem would have been found already and decided to try a later -CURRENT. I downloaded some boot floppies for the latest -CURRENT (20021208) from current.freebsd.org and tried the install again, with the same luck. It appeared to hang after detecting vga0. Booting with -v, I would see a message about isa_probe_children, and that's when the machine hung. Oddly enough, after letting the machine sit in the hung state for a while, the boot process continued and I was able to install, but every time since the long boot times continue. After searching around, I discovered the device hint 'hint.acpi.0.disable=1' and added it to my /boot/device.hints, but the problem still persists. I then set acpi_load=NO in /boot/loader.conf, but with no luck. The machine boots, just boots extremely slow. Any ideas? I'm happy to post any information that's requested (once the machine boots...). Thanks, Josh Tolbert To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-current in the body of the message
