Re: i386 vs amd64 - benchmark results
On Wed, Jul 27, 2005 at 11:52:30AM -0400 I heard the voice of Vivek Khera, and lo! it spake thus: > > The amd64 memory architecture is NUMA -- that is, depending on how > your RAM is layed out, some of it is faster to access for each > processor. Accessing RAM "local" to the other processor(s) is > slower. On the other hand, I've heard from various sources (this is all pure hearsay, so trust it as much as it deserves) that in practice NUMAization in this case isn't really a gain. It's non-uniform, but it's not nearly as non-uniform as a lot of applications of the term, and the performance penalty is so small in absolute terms that the added complexity that comes with NUMA awareness can actually be enough to make it a net loss. But then, I usually don't know what I'm talking about8-} -- Matthew Fuller (MF4839) | [EMAIL PROTECTED] Systems/Network Administrator | http://www.over-yonder.net/~fullermd/ On the Internet, nobody can hear you scream. ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to "[EMAIL PROTECTED]"
Re: New question - hot plug support on TWE driver / 3ware board
Karl Denninger schrieb: On Thu, Jul 28, 2005 at 04:31:40PM -0400, Mike Tancsa wrote: At 04:19 PM 28/07/2005, Karl Denninger wrote: Is there a control program for the "twe" driver devices, and/or an option somewhere I'm missing? I've looked around and in the man pages, and found nothing thus far. Or is hot plug/unplug simply not supported with this board/driver set? Yes, look at the cli tools for adding and removing drives. Also download the 3dm2 for monitoring. The web site says for "9000 only" but is misleading as the 3dmd2 daemon works on 7xxx, 8xxx and 9xxx cards. But to remove and add drives, use the cli tool. Another common "gotcha" people run into when trying to access the web daemon, make sure you speak SSL to it. ie. https://127.0.0.1:888 NOT http://127.0.0.1:888 ---Mike Ok, will grab that and check it out. cd /usr/ports/sysutils/3dm/ && make install clean Regards, Thomas. ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to "[EMAIL PROTECTED]"
Re: Quality of FreeBSD
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Hello, Bruce A. Mah wrote: >> I know the developers don't hear it often enough, but thanks for all you=20 >> do. I'm not a programmer, and I currently don't have the funds to=20 >> donate to the project, but you do have my heartfelt thanks for still=20 >> turning out my favorite OS. > You're welcome, and I'm sure I speak for at least a few other developers > when I say that you'd be surprised how valuable a "donation" of a few > kind words can be. I'm following this thread from the start on. To add a "few kind words" I may report that I have three FreeBSD-5 servers (COMPAQ/HP ProLiant) up'n running for quite some time now (starting with 5.2.1!) and they act very well!! Mainly NFS and Samba servers, so their focus lies on filesystem space. To be honest, I was a bit astonished how many people obviously use ATA-Disks in a fileserver environment. I just read an article in the german iX-Magazine where the author emphasizes (once again!) that ATA disks are *not* designed for 24*7 use (with the exception of WDs Raptor). Considered the weak definitions in the so called "ATA- standard", I can't imagine for me personal to use ATA-disks for more than more or less temporary storage. Especially if I earn money with the server in question I always heard the urgent recommendation to use SCSI-disk. If I compare the value of the data with the cost of a SCSI subsystem, there are no questions any more... Some special kind words go to Soren Schmidt here. I never understood how one person could voluntary dive into this "shark basin" of ATA. There are no merits to earn and there seem to be always many "special" combinations of hardware, which don't work. A well thought out standard should avoid exactly that! So "Hats off" to Soren for his work and his boundless ability to suffer with the many complaints. So I stay with the old FreeBSD behaviour to use proven technology[TM] and let the cheap toys for the Linux-kiddies. It remains true: You get what you pay for! - -- Ciao/BSD - Matthias Matthias Schuendehuette, Berlin (Germany) PGP-Key at and ID: 0xDDFB0A5F -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.1 (Darwin) iD8DBQFC6zSnf1BNcN37Cl8RAnd0AJ9enOmZ1VcCLNG3CqTuwE5iHtSnJwCcCEAQ 5d1lAHQdhkMxyCDzj8E8xv4= =arDg -END PGP SIGNATURE- ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to "[EMAIL PROTECTED]"
Panic in 6-BETA1 during mount
Hi,
I gave 6-BETA1 a try on just another machine and got the following panic
during mount of an UFS1 filesystem with extended attributes. The
machine runs fine with 5.4-STABLE.
If you need 'dmesg' and kernel-config, let me know. I included
# Add support for Extended Attributes and Access Control Lists
#
options UFS_EXTATTR
options UFS_EXTATTR_AUTOSTART
options UFS_ACL
in my kernel config.
Output of dumpfs(8):
[EMAIL PROTECTED] - ~
503 # dumpfs /disk
magic 11954 (UFS1)timeSat Jul 30 16:38:30 2005
id [ 3fc09aad 28e883c3 ]
ncg 52 size4718592 blocks 4644951
bsize 16384 shift 14 mask0xc000
fsize 2048shift 11 mask0xf800
frag8 shift 3 fsbtodb 2
minfree 8% optim timesymlinklen 60
maxbpg 4096maxcontig 7 contigsumsize 7
nbfree 462756 ndir58 nifree 1164394 nffree 252
cpg 89 bpg 11392 fpg 91136 ipg 22400
nindir 4096inopb 128 nspf4 maxfilesize
1126174852055039
sbsize 2048cgsize 16384 cgoffset 1024 cgmask 0x
csaddr 1424cssize 2048
rotdelay 0msrps 60 trackskew 0 interleave 1
nsect 4096npsect 4096spc 4096
sblkno 8 cblkno 16 iblkno 24 dblkno 1424
cgrotor 36 fmod0 ronly 0 clean 0
avgfpdir 64 avgfilesize 16384
flags soft-updates
fsmnt /disk
volname swuid 0
cs[].cs_(nbfree,ndir,nifree,nffree):
(2991,3,22392,27) (7117,0,22400,0) (7117,1,22399,7)
(7117,1,22399,7)
(11215,0,22400,0) (7118,0,22400,0) (11215,0,22400,0)
(11215,0,22400,0)
(7118,0,22400,0) (7118,0,22400,0) (4068,5,22252,114)
(7118,0,22400,0)
(7118,0,22400,0) (7118,0,22400,0) (7118,0,22400,0)
(7118,0,22400,0)
(7118,0,22400,0) (4577,0,22400,0) (7117,0,22400,0)
(7118,0,22400,0)
(7118,0,22400,0) (7118,0,22400,0) (7118,0,22400,0)
(7118,0,22400,0)
(7118,0,22400,0) (7118,0,22400,0) (7118,0,22400,0)
(7118,0,22400,0)
(6916,1,22398,7) (11215,0,22400,0) (11215,0,22400,0)
(11214,1,22399,7)
(11215,0,22400,0) (10736,1,22395,12) (11215,0,22400,0)
(11215,0,22400,0)
(10392,0,22400,0) (11215,0,22400,0) (11215,0,22400,0)
(11215,0,22400,0)
(11215,0,22400,0) (11215,0,22400,0) (11215,0,22400,0)
(11101,42,22163,66)
(11214,3,22397,5) (11215,0,22400,0) (11215,0,22400,0)
(11215,0,22400,0)
(11215,0,22400,0) (11215,0,22400,0) (11215,0,22400,0)
(8655,0,22400,0)
cylinders in last group 69
blocks in last group 8832
/var/crash/info.205:
Dump header from device /dev/da0s1b
Architecture: i386
Architecture Version: 33554432
Dump Length: 267980800B (255 MB)
Blocksize: 512
Dumptime: Sat Jul 30 17:38:32 2005
Hostname:
Magic: FreeBSD Kernel Dump
Version String: FreeBSD 6.0-BETA1 #0: Fri Jul 29 21:17:52 CEST 2005
[EMAIL PROTECTED]:/usr/obj/usr/src/sys/STABLE
Panic String: lockmgr: unknown locktype request 0
Dump Parity: 2781107745
Bounds: 205
Dump Status: good
Backtrace with kgdb and kernel.debug:
#23 0xc054b91c in panic (fmt=0xc0729f42 "lockmgr: unknown locktype
request %d")
at /usr/src/sys/kern/kern_shutdown.c:537
#24 0xc053cad1 in lockmgr (lkp=0xc1746c08, flags=0, interlkp=0xc07875f8,
td=0xc1717e10) at /usr/src/sys/kern/kern_lock.c:423
#25 0xc05ab9a6 in vfs_hash_insert (vp=0xc1746bb0, hash=215, flags=0,
td=0xc1717e10, vpp=0xd13a3760, fn=0, arg=0x0)
at /usr/src/sys/kern/vfs_hash.c:112
#26 0xc067bf27 in ffs_vget (mp=0xc16b6000, ino=215, flags=0,
vpp=0xd13a3760)
at pcpu.h:162
#27 0xc068831e in ufs_lookup (ap=0xd13a3838)
at /usr/src/sys/ufs/ufs/ufs_lookup.c:571
#28 0xc0685f34 in ufs_extattr_lookup (start_dvp=0xc1746cc0,
lockparent=2,
dirname=0x0, vp=0x0, td=0xc1717e10)
at /usr/src/sys/ufs/ufs/ufs_extattr.c:273
#29 0xc0686623 in ufs_extattr_autostart (mp=0xc16b6000, td=0xc1717e10)
at /usr/src/sys/ufs/ufs/ufs_extattr.c:462
#30 0xc067e35a in ffs_mount (mp=0xc16b6000, td=0xc1717e10)
at /usr/src/sys/ufs/ffs/ffs_vfsops.c:780
#31 0xc05ae9d9 in vfs_donmount (td=0xc1717e10, fsflags=32776,
fsoptions=0xd13a3be8) at /usr/src/sys/kern/vfs_mount.c:739
#32 0xc05b09cd in kernel_mount (ma=0xc16c6450, flags=0) at pcpu.h:162
#33 0xc067b778 in ffs_cmount (ma=0xc16c6450, data=0x0, flags=0,
td=0xc1717e10)
at /usr/src/sys/ufs/ffs/ffs_vfsops.c:384
#34 0xc05b0707 in mount (td=0xc1717e10, uap=0xd13a3d04)
at /usr/src/sys/kern/vfs_mount.c:566
#35 0xc06f1be0 in syscall (frame=
{tf_fs = 59, tf_es = 59, tf_ds = 59, tf_edi = -1077943940, tf_esi
= -1077941228, tf_ebp = -1077943800, tf_isp = -784712348, tf_ebx =
-1077943760, tf_edx = 0, tf_ecx = 1, tf_eax = 21, tf_trapno = 12,
tf_err = 2, tf_eip = 671916271, tf_cs = 51, tf_eflags = 582, tf_esp =
-1077943972, tf_ss = 59})
at /usr/src/sys/i386/i386/trap.c:986
#36 0xc06e236f in Xint0x80_syscall ()
at /usr/src/sys/i386/i386/exception.s:200
If you need add
RELENG_5 ATA patches mk III
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Ran into a small problem with this patch-kit on RELENG_5 .. Jul 29 21:01:06 mail kernel: FAILURE - out of memory in ata_raid_init_request ~ .. after which the box promptly rebooted (no console, sorry). The box is most definitely "memory constrained" (as in snippets of dmesg below) but not so much that I would expect this. In the RELENG_5 code, memory allocation in the driver is done slightly differently .. #define ata_alloc_request() uma_zalloc(ata_zone, M_NOWAIT | M_ZERO) ~ .. versus .. buf1 = malloc(sizeof(struct ar_buf), M_AR, M_NOWAIT | M_ZERO); /* XXX */ ~ .. in their respective 'strategy' functions. Did the shift to 'uma_zalloc' break my machine? ;-) Michael Jul 29 21:03:39 mail kernel: CPU: Pentium II/Pentium II Xeon/Celeron (348.49-MHz 686-class CPU) Jul 29 21:03:39 mail kernel: Origin = "GenuineIntel" Id = 0x651 Stepping = 1 Jul 29 21:03:39 mail kernel: Features=0x183f9ff Jul 29 21:03:39 mail kernel: real memory = 402653184 (384 MB) Jul 29 21:03:39 mail kernel: avail memory = 388505600 (370 MB) ~ [ .. ] Jul 29 21:03:39 mail kernel: atapci1: port 0x1400-0x14ff,0x1010-0x1013,0x1018-0x101f,0x1014-0 x1017,0x1040-0x1047 irq 11 at device 13.0 on pci0 Jul 29 21:03:39 mail kernel: ata2: on atapci1 Jul 29 21:03:39 mail kernel: ata3: on atapci1 Jul 29 21:03:39 mail kernel: ahc0: port 0x1800-0x18ff mem 0xd000-0xdfff irq 10 at device 14.0 on pci0 Jul 29 21:03:39 mail kernel: aic7860: Ultra Single Channel A, SCSI Id=7, 3/253 SCBs ~ [ .. ] Jul 29 21:03:39 mail kernel: atapicam0: on ata0 Jul 29 21:03:39 mail kernel: atapicam1: on ata1 Jul 29 21:03:39 mail kernel: acd0: CDROM at ata1-master UDMA33 Jul 29 21:03:39 mail kernel: atapicam2: on ata2 Jul 29 21:03:39 mail kernel: ad4: 152627MB at ata2-master UDMA133 Jul 29 21:03:39 mail kernel: ad5: 152627MB at ata2-slave UDMA133 Jul 29 21:03:39 mail kernel: atapicam3: on ata3 Jul 29 21:03:39 mail kernel: ad6: 152627MB at ata3-master UDMA133 Jul 29 21:03:39 mail kernel: ad7: 152627MB at ata3-slave UDMA133 Jul 29 21:03:39 mail kernel: sa0 at ahc0 bus 0 target 0 lun 0 Jul 29 21:03:39 mail kernel: sa0: Removable Sequential Access SCSI-2 device Jul 29 21:03:39 mail kernel: sa0: 10.000MB/s transfers (10.000MHz, offset 15) Jul 29 21:03:39 mail kernel: pass1 at ata1 bus 0 target 0 lun 0 Jul 29 21:03:39 mail kernel: pass1: Removable CD-ROM SCSI-0 device Jul 29 21:03:39 mail kernel: pass1: 33.000MB/s transfers Jul 29 21:03:39 mail kernel: ATA PseudoRAID loaded Jul 29 21:03:39 mail kernel: ar0: 305255MB status: READY Jul 29 21:03:39 mail kernel: ar0: disk0 READY (master) using ad4 at ata2-master Jul 29 21:03:39 mail kernel: ar0: disk1 READY (master) using ad5 at ata2-slave Jul 29 21:03:39 mail kernel: ar0: disk2 READY (mirror) using ad6 at ata3-master Jul 29 21:03:39 mail kernel: ar0: disk3 READY (mirror) using ad7 at ata3-slave -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.0 (MingW32) iD8DBQFC7AO6iJykeV6HPMURAs06AJ9IkIuV1g6+McqIP8CUseJcvk1X2QCg/q6v qPLAWwnjU5j4MbEgetCCKjA= =DXcF -END PGP SIGNATURE- ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to "[EMAIL PROTECTED]"
