--On 13 February 2009 20:08 +0100 Max Laier <m...@love2party.net> wrote:
Can you maybe try to take the nVidia RAID out of the equation? I figure
the "professional" version of the chip is not that common so maybe the
corruption stems from the disk controller.
Hi,
I've tested with both Marvell (PCI-X), and Promise (PCI 32 Bit) SATA
controllers now - it makes no difference.
I upgraded the BIOS on the machine, and did a CMOS reset, then load factory
defaults.
I also then slowly upped the hw.physmem setting to see what would happen.
I can now get this running at 8Gb [I've changed the email subject
accordingly].
Any attempt to go over that (or remove the line from loader.conf
completely) and it ends in the previous random crashes, compiler errors
(e.g. warnings of internal bugs in gcc) - and occasional sig11's... e.g.
From compiling the kernel one time I got:
"
mkdep -f .depend -a -nostdinc -D_KERNEL -DKLD_MODULE
-DHAVE_KERNEL_OPTION_HEADERS -I. -I@ -I@/contrib/altq
-I/usr/src/sys/amd64/compile/GENERIC
/usr/src/sys/modules/uslcom/../../dev/usb/uslcom.c
===> utopia (depend)
@ -> /usr/src/sys
/libexec/ld-elf.so.1: /lib/libc.so.7: Unsupported relocation type 88 in
non-PLT relocations
"
I could probably live with only 8Gb in the machine, but it's going to be
running some large ZFS pools (and a number of other tasks) - I'd like to
have all 10Gb usable (especially if I move to 8.x eventually - and
obviously, as it's physically in there, it'd be good to 'use it')
Can anyone think of anything that is likely to break if you go >8Gb? [up
from 4Gb since the BIOS was reflashed/reset & factory defaulted].
-Kp
_______________________________________________
freebsd-hackers@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-hackers
To unsubscribe, send any mail to "freebsd-hackers-unsubscr...@freebsd.org"
