Re: SMP stability ? [was Re: more info from panic from running
Le Wednesday 20 November 2002 11:25, Joel M. Baldwin a écrit : > I haven't had any Hard Locks since I upgraded the BIOS on my > BP6 from LP to RU and cvsup/buildworld/installworld again. I'll upgrade my BIOS ASAP > > At the moment I'm thinking that my system is stable again, but > won't feel comfortable with that until I do some more stress > testing. I've gotten a panic, but I think its unrelated. > ( that's made this harder, multiple issues causing problems ) In the meantime, I'm also making some progresses : I've disabled ACPI from the loader (exec="unset ACPI_LOAD" in /boot/loader.conf) and so far, the machine seems to be happy making the world (and this WE, building some ports) TfH [SNIP] To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
Re: SMP stability ? [was Re: more info from panic from running
I haven't had any Hard Locks since I upgraded the BIOS on my BP6 from LP to RU and cvsup/buildworld/installworld again. At the moment I'm thinking that my system is stable again, but won't feel comfortable with that until I do some more stress testing. I've gotten a panic, but I think its unrelated. ( that's made this harder, multiple issues causing problems ) So if people are still having their BP6 do Hard Locks I would suggest they make sure they're running the RU version of the BIOS and the latest version of -current. Thanks for the tip however. If I continue to have Hard Locks I'll try slowing down the IDE drives on the system. --On Wednesday, November 20, 2002 1:10 AM +0100 Thierry Herbelot <[EMAIL PROTECTED]> wrote: Le Tuesday 19 November 2002 22:35, Nate Lawson a écrit : I have a couple BP6's running -stable and was having hard lock problems under heavy IO until I dropped back to ATA33 on the drives (I moved them to the onboard Intel controller instead of the HPT366). sos@ informed me that the HPT366 has a buggy DMA controller and that ATA66 on them wouldn't work. After moving to ATA33 in early 2001, I haven't had any more hard locks. This was under -stable, but you might want to check your ATA drive setup before proceeding. Hello, I also had a lockup this morning, with both /usr/src and /usr/obj on the local dma33 IDE disk, hooked on the BX ata canal (instead of the HPT366). the BP6 is on a serial console, but I still have to look how to get back to DDB when it is frozen (I run a plain vanilla GENERIC+SMP, so I may have to add other specific options - later) TfH To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
Re: SMP stability ? [was Re: more info from panic from running
Le Tuesday 19 November 2002 22:35, Nate Lawson a écrit : > I have a couple BP6's running -stable and was having hard lock problems > under heavy IO until I dropped back to ATA33 on the drives (I moved them > to the onboard Intel controller instead of the HPT366). sos@ informed me > that the HPT366 has a buggy DMA controller and that ATA66 on them wouldn't > work. After moving to ATA33 in early 2001, I haven't had any more hard > locks. This was under -stable, but you might want to check your ATA drive > setup before proceeding. Hello, I also had a lockup this morning, with both /usr/src and /usr/obj on the local dma33 IDE disk, hooked on the BX ata canal (instead of the HPT366). the BP6 is on a serial console, but I still have to look how to get back to DDB when it is frozen (I run a plain vanilla GENERIC+SMP, so I may have to add other specific options - later) TfH To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
Re: SMP stability ? [was Re: more info from panic from running
I have a couple BP6's running -stable and was having hard lock problems under heavy IO until I dropped back to ATA33 on the drives (I moved them to the onboard Intel controller instead of the HPT366). sos@ informed me that the HPT366 has a buggy DMA controller and that ATA66 on them wouldn't work. After moving to ATA33 in early 2001, I haven't had any more hard locks. This was under -stable, but you might want to check your ATA drive setup before proceeding. -Nate To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
Re: SMP stability ? [was Re: more info from panic from running
[EMAIL PROTECTED] wrote, On 11/17/02 18:34: > > I haven't been able to complete a full buildworld with an SMP on a > > Abit BP6 (bi-celeron) board for two weeks (the kernel config is just > > a full GENERIC with SMP and APICIO options enabled). > > I also am running a BP6. IS ANYONE successfully running an ABIT > BP6 motherboard on a SMP kernel with -current? > > What BIOS version are running? I'm one version behind I think, > so I'm going to upgrade and see if that makes any difference. Yes, I am. The BIOS is the latest -RU revision (if I remembered correctly) with custom patch (original HPT366 part of BIOS replaced by version 1.28-beta) - but I think this patch has no effecto to FreeBSD. No ACPI is enabled in BIOS configuration, KERNEL is custom. The -current environment isn't used for any work, just for periodic cvsup && makeworld installworld The SMP kernels are unable to run several weeks due a problem with Giant lock, but it is working now. The only current -current's problem known to me is that linc is broken when compilled with -O3 as some pthread stubs functions is optimized-out from resulting library (e.g. you can't sucessfully link other programs, also dynamically linked binaries doesn't load and run due unresolved symbols). > > Even make -j1 buildworld with the SMP kernel ends with a complete > > freeze of the machine (the kernel does not go to a panic where I > > could try a backtrace) > > Exactly! Hard Lock, no panic, no keyboard, no choices other than = > reset. NAK. My BP6 did it with no problem. Dan -- Dan Lukes tel: +420 2 21914205, fax: +420 2 21914206 root of FIONet, KolejNET, webmaster of www.freebsd.cz AKA: [EMAIL PROTECTED], [EMAIL PROTECTED],[EMAIL PROTECTED] To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
Re: SMP stability ? [was Re: more info from panic from running dneton SMP kernel]
On Sun, 17 Nov 2002, Robert Watson wrote: > I've seen several reports that using a serial break to get into ddb is now > quite a bit more reliable than a keyboard break. If you're not already This is a fact. In RELENG_4, the keyboard interrupt handler is a normal tty interrupt handler so it can't interrupt things blocked by spltty(), while the sio interrupt handler is a fast interrupt handler so it can interrupt almost anything (anything not blocked by disable_intr(), which should be everything except fast interrupt handlers and the entry code for normal interrupt handlers). Things are much more broken in -current: the keyboard interrupt handler is non-MPSAFE so it can't interrupt things blocked by Giant (which is most syscalls), and the sio interrupt handler is a "fast" interrupt handler so it can't interrupt things blocked by critical_enter() (which is too many things for too long, so fast interrupt handlers aren't actually fast). Bruce To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
Re: SMP stability ? [was Re: more info from panic from running dnet on SMP kernel]
Le Sunday 17 November 2002 20:46, Robert Watson a écrit : > > I've seen several reports that using a serial break to get into ddb is now > quite a bit more reliable than a keyboard break. If you're not already > using a serial console, you might want to give it a try (make sure to turn > on BREAK_TO_DEBUGGER and/or ALT_BREAK_TO_DEBUGGER). OK, I'll do so TfH PS : I think one other BP6 user is Grog To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
Re: SMP stability ? [was Re: more info from panic from running dnet on SMP kernel]
On Sun, 17 Nov 2002, Thierry Herbelot wrote: > Even make -j1 buildworld with the SMP kernel ends with a complete freeze > of the machine (the kernel does not go to a panic where I could try a > backtrace) I've seen several reports that using a serial break to get into ddb is now quite a bit more reliable than a keyboard break. If you're not already using a serial console, you might want to give it a try (make sure to turn on BREAK_TO_DEBUGGER and/or ALT_BREAK_TO_DEBUGGER). Robert N M Watson FreeBSD Core Team, TrustedBSD Projects [EMAIL PROTECTED] Network Associates Laboratories To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
SMP stability ? [was Re: more info from panic from running dnet on SMP kernel]
Le Sunday 17 November 2002 10:50, Joel M. Baldwin a écrit : > running dnet on a SMP kernel causes the kernel to panic. > > [Hijacking another thread ?] I haven't been able to complete a full buildworld with an SMP on a Abit BP6 (bi-celeron) board for two weeks (the kernel config is just a full GENERIC with SMP and APICIO options enabled). The same machine runs happily strings of make -j48 buildworld's when running with the straight GENERIC UP kernel, so I think the hardware seems to be working OK. Even make -j1 buildworld with the SMP kernel ends with a complete freeze of the machine (the kernel does not go to a panic where I could try a backtrace) The hardware config of the machine is pretty dull (see dmesg later). One point that could be better is that the sources are NFS mounted from a 4.7-Stable server, over an rl(4) board, which may be unstable (/usr/obj is local, on the Maxtor drive) TfH PS : the machine was re-installed anew from the 5.0-20021027-CURRENT snapshot, then upgraded via make buildworld/buildkernel and mergemaster PS2 : full dmesg (when running the stable, UP, GENERIC) Copyright (c) 1992-2002 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-CURRENT #17: Sat Nov 16 19:16:25 CET 2002 XXX@YYY:/usr/obj/files2/src-free/src/sys/GENERIC Preloaded elf kernel "/boot/kernel/kernel" at 0xc0662000. Timecounter "i8254" frequency 1193182 Hz Timecounter "TSC" frequency 334092192 Hz CPU: Pentium II/Pentium II Xeon/Celeron (334.09-MHz 686-class CPU) Origin = "GenuineIntel" Id = 0x665 Stepping = 5 Features=0x183fbff real memory = 536870912 (512 MB) avail memory = 514818048 (490 MB) Initializing GEOMetry subsystem Pentium Pro MTRR support enabled npx0: on motherboard npx0: INT 16 interface Using $PIR table, 8 entries at 0xc00fdef0 pcib0: at pcibus 0 on motherboard pci0: on pcib0 agp0: mem 0xe000-0xe3ff at device 0.0 on pci0 pcib1: at device 1.0 on pci0 pci1: on pcib1 isab0: at device 7.0 on pci0 isa0: on isab0 atapci0: port 0xf000-0xf00f at device 7.1 on pci0 ata0: at 0x1f0 irq 14 on atapci0 ata1: at 0x170 irq 15 on atapci0 uhci0: port 0xd000-0xd01f irq 10 at device 7.2 on pci0 usb0: on uhci0 usb0: USB revision 1.0 uhub0: Intel UHCI root hub, class 9/0, rev 1.00/1.00, addr 1 uhub0: 2 ports with 2 removable, self powered pci0: at device 7.3 (no driver attached) rl0: port 0xd400-0xd4ff mem 0xe500-0xe5ff irq 10 at device 17.0 on pci0 rl0: Realtek 8139B detected. Warning, this may be unstable in autoselect mode rl0: Ethernet address: 00:40:95:30:38:36 miibus0: on rl0 rlphy0: on miibus0 rlphy0: 10baseT, 10baseT-FDX, 100baseTX, 100baseTX-FDX, auto atapci1: port 0xe000-0xe0ff,0xdc00-0xdc03,0xd800-0xd807 irq 11 at device 19.0 on pci0 ata2: at 0xd800 on atapci1 atapci2: port 0xec00-0xecff,0xe800-0xe803,0xe400-0xe407 irq 11 at device 19.1 on pci0 ata3: at 0xe400 on atapci2 orm0: at iomem 0xc6800-0xc7fff,0xc-0xc5fff on isa0 pmtimer0 on isa0 atkbdc0: at port 0x64,0x60 on isa0 atkbd0: flags 0x1 irq 1 on atkbdc0 kbd0 at atkbd0 fdc0: at port 0x3f7,0x3f0-0x3f5 irq 6 drq 2 on isa0 fdc0: FIFO enabled, 8 bytes threshold fd0: <1440-KB 3.5" drive> on fdc0 drive 0 ppc0: at port 0x378-0x37f irq 7 on isa0 ppc0: Generic chipset (NIBBLE-only) in COMPATIBLE mode plip0: on ppbus0 lpt0: on ppbus0 lpt0: Interrupt-driven port ppi0: on ppbus0 sc0: at flags 0x100 on isa0 sc0: VGA <16 virtual consoles, flags=0x100> sio0 at port 0x3f8-0x3ff irq 4 flags 0x10 on isa0 sio0: type 16550A, console sio1 at port 0x2f8-0x2ff irq 3 on isa0 sio1: type 16550A vga0: at port 0x3c0-0x3df iomem 0xa-0xb on isa0 unknown: can't assign resources (port) unknown: can't assign resources (port) unknown: can't assign resources (port) unknown: can't assign resources (port) unknown: can't assign resources (port) unknown: can't assign resources (port) Timecounters tick every 10.000 msec ad0: 6149MB [13328/15/63] at ata0-master UDMA33 acd0: CDROM at ata1-master PIO4 Mounting root from ufs:/dev/ad0s2a To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
