Re: Upgrade from 8.2-STABLE to 9.0-RELEASE wedges on SuperMicro H8DGiF-based system
Freddie Cash fjwc...@gmail.com wrote: On Mon, Jan 9, 2012 at 9:50 AM, John Nielsen li...@jnielsen.net wrote: From what you've said I strongly suspect that you have some kind of hardware issue. Dodgy RAM is my first guess ... That's what we're leaning toward as well. We're planning on doing a BIOS upgrade (betadrive is running v2.00 and alphadrive is v1.00), then a memtest86+ run, then check firmware on the SATA controllers. I'd suggest doing the memtest86+ run first, rather than risk doing a BIOS upgrade with bad RAM (which could brick the machine). ___ 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
Odd zpool problem - always one disc offline, maybe controller related ?
I upgraded my system to -stable on January 6th, and since then I have noticed a very odd problem. I have a zpool with 4 drives in it, and one of them is always 'OFFLINE' - if I put it online and it styarts resolvering then another one immediately goes offline. It's the same two drives alternating as well - very perplexing. I have checked all the cabling (they are eSATA drives), and it is all pushed home solid. It looks from dmesg like the drive is disconnecting and reconnecting briefly, but thats triggering it being dropped out of the zpool. I must admit that though I noticed thos on the 6th, I cant tell you whhether it was working on the version I was runnign previously, as I dont check the zpool on that machine as ofetn as I shiuld. Am recompiling an earlier version now though to see. Details of what happens are below: -pete. -- [pete@skerry ~]$ zpool status pool: cube state: DEGRADED status: One or more devices has been removed by the administrator. Sufficient replicas exist for the pool to continue functioning in a degraded state. action: Online the device using 'zpool online' or replace the device with 'zpool replace'. scan: resilvered 6.41G in 2h27m with 0 errors on Mon Jan 9 23:23:27 2012 config: NAME STATE READ WRITE CKSUM cube DEGRADED 0 0 0 mirror-0 ONLINE 0 0 0 ada2 ONLINE 0 0 0 ada3 ONLINE 0 0 0 mirror-1 DEGRADED 0 0 0 ada1 ONLINE 0 0 0 8890308235385361660 REMOVED 0 0 0 was /dev/ada0 errors: No known data errors [pete@skerry ~]$ su Password: skerry# zpool online ada0 missing device name usage: online [-e] pool device ... skerry# zpool online cube ada0 skerry# zpool status pool: cube state: DEGRADED status: One or more devices is currently being resilvered. The pool will continue to function, possibly in a degraded state. action: Wait for the resilver to complete. scan: resilver in progress since Tue Jan 10 09:03:58 2012 1.02G scanned out of 1.42T at 80.6M/s, 5h8m to go 492M resilvered, 0.07% done config: NAME STATE READ WRITE CKSUM cube DEGRADED 0 0 0 mirror-0 DEGRADED 0 0 0 ada2 ONLINE 0 0 0 6739201713000599902 REMOVED 0 0 0 was /dev/ada3 mirror-1 ONLINE 0 0 0 ada1 ONLINE 0 0 0 ada0 ONLINE 0 0 0 (resilvering) errors: No known data errors skerry# ...and from dmesg at the point I did that: (ada3:siisch3:0:0:0): lost device (ada3:siisch3:0:0:0): removing device entry ada3 at siisch3 bus 0 scbus3 target 0 lun 0 ada3: WDC WD1002FBYS-02A6B0 03.00C06 ATA-8 SATA 2.x device ada3: 300.000MB/s transfers (SATA 2.x, UDMA6, PIO 8192bytes) ada3: Command Queueing enabled ada3: 953869MB (1953525168 512 byte sectors: 16H 63S/T 16383C) here is the boot dmesg: Copyright (c) 1992-2012 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-STABLE #0: Fri Jan 6 12:41:32 GMT 2012 pete@skerry.drayhouse:/usr/obj/usr/src/sys/GENERIC amd64 Timecounter i8254 frequency 1193182 Hz quality 0 CPU: Intel(R) Core(TM)2 Duo CPU E8400 @ 3.00GHz (2992.52-MHz K8-class CPU) Origin = GenuineIntel Id = 0x10676 Family = 6 Model = 17 Stepping = 6 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=0x8e3fdSSE3,DTES64,MON,DS_CPL,VMX,SMX,EST,TM2,SSSE3,CX16,xTPR,PDCM,SSE4.1 AMD Features=0x20100800SYSCALL,NX,LM AMD Features2=0x1LAHF TSC: P-state invariant real memory = 4299161600 (4100 MB) avail memory = 4024582144 (3838 MB) ACPI APIC Table: COMPAQ BEARLAKE FreeBSD/SMP: Multiprocessor System Detected: 2 CPUs FreeBSD/SMP: 1 package(s) x 2 core(s) cpu0 (BSP): APIC ID: 0 cpu1 (AP): APIC ID: 1 ioapic0: Changing APIC ID to 1 ioapic0 Version 2.0 irqs 0-23 on motherboard kbd1 at kbdmux0 acpi0: HPQOEM SLIC-BPC on motherboard acpi0: [ITHREAD] acpi0: Power Button (fixed) acpi0: reservation of 0, a (3) failed acpi0: reservation of 10, dff0 (3) failed Timecounter ACPI-fast frequency 3579545 Hz quality 1000 acpi_timer0: 24-bit timer at 3.579545MHz port 0xf808-0xf80b on acpi0 cpu0: ACPI CPU on acpi0 cpu1: ACPI CPU on acpi0 acpi_hpet0: High Precision Event Timer iomem 0xfed0-0xfed003ff on acpi0 Timecounter HPET frequency 14318180 Hz quality 900 pcib0: ACPI
Re: Upgrade from 8.2-STABLE to 9.0-RELEASE wedges on SuperMicro H8DGiF-based system
On Mon, Jan 9, 2012 at 11:25 AM, Freddie Cash fjwc...@gmail.com wrote: I've upgraded the BIOS to v2.00 same as betadrive. However, using the exact same BIOS settings as betadrive causes the SATA controllers and onboard igb(4) interfaces to not be detected. At all. Nothing in dmesg or pciconf. Resetting BIOS settings to Failsafe settings shows the SATA controllers and onboard NICs. Now the fun begins to figure out which setting in the BIOS is causing this. Looks like the BIOS upgrade to v2.00a solved the stability issues with FreeBSD 9.0. The box has been up for over 24 hours now, finished a backups run overnight, ran multiple concurrent find processes on the ZFS pool, without any hiccups or issues. There's still something wonky with this BIOS and FreeBSD 9.0 and the older AOC-USAS-L8i SATA controllers, as I had to resort to the Failsafe Settings. Using the exact same BIOS settings as the other box causes all PCIe devices to disappear. Since the box is working correctly now, as far as we can see, we'll be leaving it like this until the summer when we have more downtime available for testing. Thanks for listening everyone, and offering advice. For now, we'll consider this issue solved. :) -- Freddie Cash fjwc...@gmail.com ___ 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
minor typo in the file /etc/default/rc.conf in freebsd 7-STABLE bug?
http://svnweb.freebsd.org/base/stable/7/etc/defaults/rc.conf?revision=223553view=markup in line #create_arg_vlan0=vlan 102 # vlan tag for vlan0 device correctly create_args_vlan0 in 8-STABLE fixed http://svnweb.freebsd.org/base/stable/8/etc/defaults/rc.conf?r1=208094r2=212080 thnx -- --- e-mail: hi...@vyborg.ru jabber id: hi...@vyborg.ru ___ 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
libutempter
I recently csup'd 9-STABLE and was able to get it working along with my custom kernel. I'm now in the process of rebuilding all my ports, and I've come across something when running 'portmaster -af' that I can't seem to find any information on. === Launching child to reinstall libutempter-1.1.5_1 === Port directory: /usr/ports/sysutils/libutempter === This port is marked IGNORE === is now contained in the base system === If you are sure you can build it, remove the IGNORE line in the Makefile and try again. === Update for libutempter-1.1.5_1 failed === Aborting update Terminated I figure, ok I'll just delete the package and move on. However, there are many packages I have installed that depend on libutemper. I would still just proceed with the removal given that the functionality is provided in base now, however I don't want to break all these ports and have to deal with the mess when I portmaster -af again. What is the recommended action here? Should I just force exclude that port from the upgrade? That's probably the easiest way but I'd have to deal with this at some point. Thanks in advance for any advice -- Andre Goree andre@drenetinfo ___ 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: libutempter
-- Forwarded message --
From: Andre Goree an...@drenet.info
Date: Wed, Jan 11, 2012 at 12:15 AM
Subject: Re: libutempter
To: Dewayne Geraghty dewayne.gerag...@heuristicsystems.com.au
On Tue, Jan 10, 2012 at 11:04 PM, Dewayne Geraghty
dewayne.gerag...@heuristicsystems.com.au wrote:
I just checked the makefile and libutempter is in the base system, per
.if ${OSVERSION} = 94
IGNORE= is now contained in the base system
I hope this helps.
Regards, Dewayne
I would still just proceed with the removal given that the functionality
is provided in base now, however I don't want to break [dependencies on]
all these ports
Mentioned that I was aware that it was in ports in my original post, sorry
if I was confusing.
What I've done in the meantime is just exclude that package for now.
Perhaps after rebuilding the ports that currently depend on the libutempter
port, the issue will resolve itself. These ports where built on the system
when world was 8.2-STABLE, so I'm hoping a rebuild will sort it out.
___
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
Anyone is currently using the rc_fast_and_loose rc.conf variable?
Good day. Sorry for cross-posting, but this question is really belongs to all three lists. Crawling over the rc.d scripts I had found the rc_fast_and_loose variable that affects the way rc.d scripts are processed inside /etc/rc script. There are some problems with certain rc.d script and this variable: they are described in my post to freebsd-rc@, http://lists.freebsd.org/pipermail/freebsd-rc/2011-December/002617.html The question is: does anyone uses rc_fast_and_loose? It seems to be undocumented and not referenced in any scripts and/or manuals. There are at least two ways of proceeding: fix rc.d scripts to work with fast_and_loose and just to eliminate it from rc.subr, so it will be good to know if the second way won't hurt anyone. Thanks. -- Eygene Ryabinkin,,,^..^,,, [ Life's unfair - but root password helps! | codelabs.ru ] [ 82FE 06BC D497 C0DE 49EC 4FF0 16AF 9EAE 8152 ECFB | freebsd.org ] pgpjZM5sPBzYB.pgp Description: PGP signature
