Using underlying adX devices as well as ar0?
Hi, I posted this question in -Questions about a week ago, and didn't get any replies :( I'm just trying to check - we have a number of 8.2-STABLE amd64 systems where the onboard RAID shows up as '/dev/ar0' (which we use for filesystems, i.e. /dev/ar0s1d et'al), and the underlying devices for that RAID1 array show up as '/dev/ad12', '/dev/ad14'. Is it OK to run smartmontools / smartd / smartctl against the underlying adX devices, whilst ar0 is in use? I can't see anywhere that seems to indicate it's bad - and I can't seem to find anywhere that seems to say it's Ok... Thanks, -Karl ___ 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
Re: Using underlying adX devices as well as ar0?
On Thu, 01 Sep 2011 07:28:37 -0500, Karl Pielorz kpielorz_...@tdx.co.uk wrote: Is it OK to run smartmontools / smartd / smartctl against the underlying adX devices, whilst ar0 is in use? Yes. :-) ___ 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
8.2R i386 bassed md root, doesn't like all machines
Works excellent! I boot it from USB stick. Now I added ~150 MB of ports to it. From that point on, it doesn't boot on all machines. Booting 2 times in a row on laptop with 4 gb ram: http://www.starforce.biz/md_root_1.jpg http://www.starforce.biz/md_root_2.jpg Without ports, it did booted fine! Then I plug it in desktop with 2 GB of ram and booted it and it works! I've did it again, just to be sure. Back to my laptop and same fail again. Domagoj Smolčić ___ 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
Re: Large machine test ideas
2011/8/31 Sean Bruno sean...@yahoo-inc.com: On Tue, 2011-08-30 at 17:11 -0700, Ivan Voras wrote: On 29.8.2011. 20:15, John Baldwin wrote: However, the SRAT code just ignores the table when it encounters an issue like this, it doesn't hang. Something else later in the boot must have hung. Anyway... that machine can in its maximal configuration be populated with eight 10-core CPUs, i.e. 80 physical / 160 logical, so here's a vote from me to bump the shiny new cpuset infrastructure maximum CPU count to 256 before 9.0. http://www.supermicro.com/products/system/5U/5086/SYS-5086B-TRF.cfm Doesn't that (MAXCPU) seriously impact VM usage, lock contention etc ... ? I mean, if we have 2 cpus in a machine, but MAXCPU is set to 256, there is a bunch of lost memory and higher levels of lock contention? I thought that attilio was taking a stab at enhancing this, but at the current time anything more than a value of 64 for MAXCPU is kind of a caveat emptor area of FreeBSD. With newest current you can redefine MAXCPU in your kernel config, so you don't need to bump the default value. I think 64 as default value is good enough. Removing MAXCPU dependency from the KBI is an important project someone should adopt and bring to conclusion. Thanks, Attilio -- Peace can only be achieved by understanding - A. Einstein ___ 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
Re: 8.2R i386 bassed md root, doesn't like all machines
On 9/1/2011 8:17 AM, rank1see...@gmail.com wrote: Works excellent! I boot it from USB stick. Now I added ~150 MB of ports to it. From that point on, it doesn't boot on all machines. Booting 2 times in a row on laptop with 4 gb ram: http://www.starforce.biz/md_root_1.jpg http://www.starforce.biz/md_root_2.jpg Without ports, it did booted fine! Then I plug it in desktop with 2 GB of ram and booted it and it works! I've did it again, just to be sure. Back to my laptop and same fail again. Domagoj Smolčić ___ 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 This must be a 32 bit i386 kernel. From the vm_thread_new() error messages, your kernel virtual memory map is depleted. The OS uses KVA for a physical page attribute table. Therefore the 4GB machine will use more KVA than a 2GB. Apparently this difference is a enough to cause you problems. Either increase your KVA (KVA_PAGES setting in your kernel configuration file; see sys/i386/include/pmap.h look for values) or decrease your KVA use (memory drive?). --Mark ___ 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
Re: Using underlying adX devices as well as ar0?
--On 01 September 2011 07:45 -0500 Mark Felder f...@feld.me wrote: Is it OK to run smartmontools / smartd / smartctl against the underlying adX devices, whilst ar0 is in use? Yes. :-) Thanks :-) I'll look for other reasons why one of the machines mysteriously locked up with everything hung in 'ufs' [you can see why I asked now! :)] -Karl ___ 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
Re: Large machine test ideas
On 1 September 2011 16:11, Attilio Rao atti...@freebsd.org wrote: I mean, if we have 2 cpus in a machine, but MAXCPU is set to 256, there is a bunch of lost memory and higher levels of lock contention? I thought that attilio was taking a stab at enhancing this, but at the current time anything more than a value of 64 for MAXCPU is kind of a caveat emptor area of FreeBSD. With newest current you can redefine MAXCPU in your kernel config, so you don't need to bump the default value. I think 64 as default value is good enough. Removing MAXCPU dependency from the KBI is an important project someone should adopt and bring to conclusion. That's certainly one half of it and thanks for the work, but the real question in this thread is what Sean asked: what are the negative side-effects of simply bumping MAXCPU to 256 by default? AFAIK, there are not that many structures which are statically sized by MAXCMPU and most use the runtime-detected smp_cpus? ___ 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
Re: BUG: Entries in fstab with 'late' option, require order, with ntfs and ufs
- Original Message -
From: John Baldwin j...@freebsd.org
To: freebsd-hackers@freebsd.org
Cc: rank1see...@gmail.com, Craig Rodrigues rodr...@freebsd.org
Date: Tue, 30 Aug 2011 08:24:01 -0400
Subject: Re: BUG: Entries in fstab with 'late' option, require order, with ntfs
and ufs
On Monday, August 29, 2011 2:08:46 pm rank1see...@gmail.com wrote:
This yields successfull boot
--
/dev/ufsid/4e5bbdf76b8b4567/usr/DOCufsrw,late 0 0
/dev/ufsid/4e5bbe036b8b4567/usr/SRCufsro,late,noatime
0
0
# This are WinXP drives:
/dev/ada0s1 /mnt/win_c ntfs
rw,mountprog=/usr/local/bin/ntfs-3g,late 0 0
/dev/ada0s5 /mnt/win_d ntfs
rw,mountprog=/usr/local/bin/ntfs-3g,late 0 0
/dev/ada0s6 /mnt/win_e ntfs
rw,mountprog=/usr/local/bin/ntfs-3g,late 0 0
--
This yields kick, in a single user mode
--
# This are WinXP drives:
/dev/ada0s1 /mnt/win_c ntfs
rw,mountprog=/usr/local/bin/ntfs-3g,late 0 0
/dev/ada0s5 /mnt/win_d ntfs
rw,mountprog=/usr/local/bin/ntfs-3g,late 0 0
/dev/ada0s6 /mnt/win_e ntfs
rw,mountprog=/usr/local/bin/ntfs-3g,late 0 0
/dev/ufsid/4e5bbdf76b8b4567/usr/DOCufsrw,late 0 0
/dev/ufsid/4e5bbe036b8b4567/usr/SRCufsro,late,noatime
0
0
--
dmesg part:
--
Mounting late file systems:NTFS signature is missing.
Failed to mount '/dev/ufsid/4e5bbdf76b8b4567': Invalid argument
The device '/dev/ufsid/4e5bbdf76b8b4567' doesn't seem to have a valid NTFS.
Maybe the wrong device is used? Or the whole disk instead of a
partition (e.g. /dev/sda, not /dev/sda1)? Or the other way around?
NTFS signature is missing.
Failed to mount '/dev/ufsid/4e5bbe036b8b4567': Invalid argument
The device '/dev/ufsid/4e5bbe036b8b4567' doesn't seem to have a valid NTFS.
Maybe the wrong device is used? Or the whole disk instead of a
partition (e.g. /dev/sda, not /dev/sda1)? Or the other way around?
.
Mounting /etc/fstab filesystems failed, startup aborted
ERROR: ABORTING BOOT (sending SIGTERM to parent)!
Aug 29 20:02:31 blackhole init: /bin/sh on /etc/rc terminated abnormally,
going
to single user mode
Enter full pathname of shell or RETURN for /bin/sh:
Hmm, seems like mountprog isn't being cleared. Try this patch to
sbin/mount:
Index: mount.c
===
--- mount.c (revision 225077)
+++ mount.c (working copy)
@@ -589,6 +589,9 @@ mountfs(const char *vfstype, const char *spec, con
for (i = 1; i mnt_argv.c; i++)
(void)printf( %s, mnt_argv.a[i]);
(void)printf(\n);
+ free(optbuf);
+ free(mountprog);
+ mountprog = NULL;
return (0);
}
@@ -599,6 +602,8 @@ mountfs(const char *vfstype, const char *spec, con
}
free(optbuf);
+ free(mountprog);
+ mountprog = NULL;
if (verbose) {
if (statfs(name, sf) 0) {
John Baldwin
I failed to apply your patch on 8.2 RELEASE i386
--
cd /usr/src/sbin/mount
patch ~/mount_patch.diff
--
Patch complained about line 6
Anyway, I've patched it manually and it works now!
Good job John ...
;)
Domagoj Smolčić
___
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
kldload dtraceall exec format error
Okay, I'll grant this is probably a horrid noob question, but then on the Free kernel I'm a horrid noob so I guess it makes sense. This is for FreeBSD FreeBSD psmdev1 8.1-RELEASE-p2 FreeBSD 8.1-RELEASE-p2 per uname -a. We have a FreeBSD based product on the AMD64 architecture; I'm trying to enable DTrace. The file amd64/conf/GENERIC with which the kernel was compiled has the required lines options KDTRACE_FRAME# Ensure frames are compiled in options KDTRACE_HOOKS# Kernel DTrace hooks options DDB_CTF # for DTrace but when I try kldload dtraceall I get kldload: can't load dtraceall: Exec format error From Google I get that this probably means some mismatch in compiles, but I'm unclear what to look for. Also, another big part of the product, compiled from the same master Makefile, *does* have dtrace enabled successfully. Hints, suggestions, and pointers to documentation gleefully accepted. -- Charles R. (Charlie) Martin Senior Software Engineer SGI logo 1900 Pike Road Longmont, CO 80501 Phone: 303-532-0209 E-Mail: crmar...@sgi.com mailto:crmar...@sgi.com Website: www.sgi.com http://www.sgi.com ___ 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
Re: Large machine test ideas
2011/9/1 Ivan Voras ivo...@freebsd.org: On 1 September 2011 16:11, Attilio Rao atti...@freebsd.org wrote: I mean, if we have 2 cpus in a machine, but MAXCPU is set to 256, there is a bunch of lost memory and higher levels of lock contention? I thought that attilio was taking a stab at enhancing this, but at the current time anything more than a value of 64 for MAXCPU is kind of a caveat emptor area of FreeBSD. With newest current you can redefine MAXCPU in your kernel config, so you don't need to bump the default value. I think 64 as default value is good enough. Removing MAXCPU dependency from the KBI is an important project someone should adopt and bring to conclusion. That's certainly one half of it and thanks for the work, but the real question in this thread is what Sean asked: what are the negative side-effects of simply bumping MAXCPU to 256 by default? AFAIK, there are not that many structures which are statically sized by MAXCMPU and most use the runtime-detected smp_cpus? Well, there are quite a few statically allocated, but as I said, making the kernel MAXCPU-agnostic (or sort of agnostic) is a goal and a good project. Thanks, Attilio -- Peace can only be achieved by understanding - A. Einstein ___ 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
Re: kldload dtraceall exec format error
On Thu, Sep 1, 2011 at 9:56 AM, Charlie Martin crmar...@sgi.com wrote: Okay, I'll grant this is probably a horrid noob question, but then on the Free kernel I'm a horrid noob so I guess it makes sense. This is for FreeBSD FreeBSD psmdev1 8.1-RELEASE-p2 FreeBSD 8.1-RELEASE-p2 per uname -a. We have a FreeBSD based product on the AMD64 architecture; I'm trying to enable DTrace. The file amd64/conf/GENERIC with which the kernel was compiled has the required lines options KDTRACE_FRAME # Ensure frames are compiled in options KDTRACE_HOOKS # Kernel DTrace hooks options DDB_CTF # for DTrace but when I try kldload dtraceall I get kldload: can't load dtraceall: Exec format error From Google I get that this probably means some mismatch in compiles, but I'm unclear what to look for. Also, another big part of the product, compiled from the same master Makefile, *does* have dtrace enabled successfully. Hints, suggestions, and pointers to documentation gleefully accepted. What does dmesg say? Thanks, -Garrett ___ 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
Re: kldload dtraceall exec format error
On 2011-09-01 11:23, Garrett Cooper wrote: On Thu, Sep 1, 2011 at 9:56 AM, Charlie Martincrmar...@sgi.com wrote: Okay, I'll grant this is probably a horrid noob question, but then on the Free kernel I'm a horrid noob so I guess it makes sense. This is for FreeBSD FreeBSD psmdev1 8.1-RELEASE-p2 FreeBSD 8.1-RELEASE-p2 per uname -a. We have a FreeBSD based product on the AMD64 architecture; I'm trying to enable DTrace. The file amd64/conf/GENERIC with which the kernel was compiled has the required lines options KDTRACE_FRAME# Ensure frames are compiled in options KDTRACE_HOOKS# Kernel DTrace hooks options DDB_CTF # for DTrace but when I try kldload dtraceall I get kldload: can't load dtraceall: Exec format error From Google I get that this probably means some mismatch in compiles, but I'm unclear what to look for. Also, another big part of the product, compiled from the same master Makefile, *does* have dtrace enabled successfully. Hints, suggestions, and pointers to documentation gleefully accepted. What does dmesg say? Thanks, -Garrett link_elf_obj: symbol lapic_cyclic_clock_func undefined linker_load_file: Unsupported file type KLD profile.ko: depends on cyclic - not available or version mismatch linker_load_file: Unsupported file type KLD dtraceall.ko: depends on profile - not available or version mismatch linker_load_file: Unsupported file type link_elf_obj: symbol lapic_cyclic_clock_func undefined linker_load_file: Unsupported file type KLD profile.ko: depends on cyclic - not available or version mismatch linker_load_file: Unsupported file type KLD dtraceall.ko: depends on profile - not available or version mismatch linker_load_file: Unsupported file type Aha, dmesg. Thanks. -- Charles R. (Charlie) Martin Senior Software Engineer SGI logo 1900 Pike Road Longmont, CO 80501 Phone: 303-532-0209 E-Mail: crmar...@sgi.com mailto:crmar...@sgi.com Website: www.sgi.com http://www.sgi.com ___ 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
Re: kldload dtraceall exec format error
okay, dmesg begins to give a clue. Here's a question: if this FreeBSD 8 is being built on a FreeBSD 7 machine, would that account for it? On 2011-09-01 11:23, Garrett Cooper wrote: On Thu, Sep 1, 2011 at 9:56 AM, Charlie Martincrmar...@sgi.com wrote: Okay, I'll grant this is probably a horrid noob question, but then on the Free kernel I'm a horrid noob so I guess it makes sense. This is for FreeBSD FreeBSD psmdev1 8.1-RELEASE-p2 FreeBSD 8.1-RELEASE-p2 per uname -a. We have a FreeBSD based product on the AMD64 architecture; I'm trying to enable DTrace. The file amd64/conf/GENERIC with which the kernel was compiled has the required lines options KDTRACE_FRAME# Ensure frames are compiled in options KDTRACE_HOOKS# Kernel DTrace hooks options DDB_CTF # for DTrace but when I try kldload dtraceall I get kldload: can't load dtraceall: Exec format error From Google I get that this probably means some mismatch in compiles, but I'm unclear what to look for. Also, another big part of the product, compiled from the same master Makefile, *does* have dtrace enabled successfully. Hints, suggestions, and pointers to documentation gleefully accepted. What does dmesg say? Thanks, -Garrett -- Charles R. (Charlie) Martin Senior Software Engineer SGI logo 1900 Pike Road Longmont, CO 80501 Phone: 303-532-0209 E-Mail: crmar...@sgi.com mailto:crmar...@sgi.com Website: www.sgi.com http://www.sgi.com ___ 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
Re: kldload dtraceall exec format error
On Thu, Sep 1, 2011 at 1:09 PM, Charlie Martin crmar...@sgi.com wrote: okay, dmesg begins to give a clue. Here's a question: if this FreeBSD 8 is being built on a FreeBSD 7 machine, would that account for it? The problem is that you only have built some -- not all -- of the modules required for dtraceall. HTH, -Garrett ___ 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
Re: kldload dtraceall exec format error
On Thu, Sep 1, 2011 at 12:27 PM, Charlie Martin crmar...@sgi.com wrote: On 2011-09-01 11:23, Garrett Cooper wrote: On Thu, Sep 1, 2011 at 9:56 AM, Charlie Martincrmar...@sgi.com wrote: Okay, I'll grant this is probably a horrid noob question, but then on the Free kernel I'm a horrid noob so I guess it makes sense. This is for FreeBSD FreeBSD psmdev1 8.1-RELEASE-p2 FreeBSD 8.1-RELEASE-p2 per uname -a. We have a FreeBSD based product on the AMD64 architecture; I'm trying to enable DTrace. The file amd64/conf/GENERIC with which the kernel was compiled has the required lines options KDTRACE_FRAME # Ensure frames are compiled in options KDTRACE_HOOKS # Kernel DTrace hooks options DDB_CTF # for DTrace but when I try kldload dtraceall I get kldload: can't load dtraceall: Exec format error From Google I get that this probably means some mismatch in compiles, but I'm unclear what to look for. Also, another big part of the product, compiled from the same master Makefile, *does* have dtrace enabled successfully. Hints, suggestions, and pointers to documentation gleefully accepted. What does dmesg say? Thanks, -Garrett link_elf_obj: symbol lapic_cyclic_clock_func undefined linker_load_file: Unsupported file type KLD profile.ko: depends on cyclic - not available or version mismatch linker_load_file: Unsupported file type KLD dtraceall.ko: depends on profile - not available or version mismatch linker_load_file: Unsupported file type link_elf_obj: symbol lapic_cyclic_clock_func undefined linker_load_file: Unsupported file type KLD profile.ko: depends on cyclic - not available or version mismatch linker_load_file: Unsupported file type KLD dtraceall.ko: depends on profile - not available or version mismatch linker_load_file: Unsupported file type Aha, dmesg. Thanks. I'm guessing you've read this: http://wiki.freebsd.org/DTrace Make certain you've configure your kernel correctly, and that you've rebuilt your kernel and modules... -Brandon ___ 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
