Re: Heavy I/O blocks FreeBSD box for several seconds

2011-07-31 Thread Andriy Gapon
on 31/07/2011 01:55 Rick Macklem said the following: Andriv Gapon wrote: on 26/07/2011 00:44 Rick Macklem said the following: hrs sent me this panic. I'm wondering if it might be relevant to this? To 'this' what? Well, my thinking was (and it is quite likely completely incorrect) is

weekly_catman not generating the right result?

2011-07-31 Thread Xin LI
-BEGIN PGP SIGNED MESSAGE- Hash: SHA256 Hi, I just noticed that weekly_catman is not generating the right result, e.g. instead of a highlight NAME, it gives 1mNAME0m (looks like the escape character is missing here). Is this a known issue? Cheers, - -- Xin LI delp...@delphij.net

breakage caused by changes to mount structure

2011-07-31 Thread KiT Sin
as of r224290, the mnt_flag in the mount structure was changed from 32 to 64 bits. should __FreeBSD_version be bumped to reflect breakage introduced by this change? fusefs-kmod broke after the kernel was upgraded, and the ports failed to build due to inconsistent data type as it is expecting

Re: weekly_catman not generating the right result?

2011-07-31 Thread Ulrich Spörlein
On Sun, 2011-07-31 at 01:22:36 -0700, Xin LI wrote: Hi, I just noticed that weekly_catman is not generating the right result, e.g. instead of a highlight NAME, it gives 1mNAME0m (looks like the escape character is missing here). Is this a known issue? Now it is :) This is due to the

Re: weekly_catman not generating the right result?

2011-07-31 Thread Xin LI
-BEGIN PGP SIGNED MESSAGE- Hash: SHA256 On 07/31/11 05:17, Ulrich Spörlein wrote: On Sun, 2011-07-31 at 01:22:36 -0700, Xin LI wrote: Hi, I just noticed that weekly_catman is not generating the right result, e.g. instead of a highlight NAME, it gives 1mNAME0m (looks like the escape

Re: weekly_catman not generating the right result?

2011-07-31 Thread Ulrich Spörlein
On Sun, 2011-07-31 at 05:43:39 -0700, Xin LI wrote: On 07/31/11 05:17, Ulrich Spörlein wrote: On Sun, 2011-07-31 at 01:22:36 -0700, Xin LI wrote: Hi, I just noticed that weekly_catman is not generating the right result, e.g. instead of a highlight NAME, it gives 1mNAME0m (looks like

print_INTEL_info/print_INTEL_TLB

2011-07-31 Thread Andriy Gapon
Just an observation: - print_INTEL_info and print_INTEL_TLB are missing from amd64 identcpu.c - print_INTEL_TLB doesn't cover all the codes defined by Intel specs - not sure; perhaps print_INTEL_info should use deterministic cache parameters as provided by CPUID 0x4 for a more complete

libc build broken with clang ?

2011-07-31 Thread Alex Kuster
Hi! I'm writing because I'm having some issues with -CURRENT and clang in amd64. I first compiled latest revision at this date and everything went ok: [0][root@Symphony ~]# uname -a FreeBSD Symphony.Gl 9.0-CURRENT FreeBSD 9.0-CURRENT #4: Sun Jul 10 10:38:28 ART 2011

Re: Heavy I/O blocks FreeBSD box for several seconds

2011-07-31 Thread Rick Macklem
Andriy Gapon wrote: on 31/07/2011 01:55 Rick Macklem said the following: Andriv Gapon wrote: on 26/07/2011 00:44 Rick Macklem said the following: hrs sent me this panic. I'm wondering if it might be relevant to this? To 'this' what? Well, my thinking was (and it is quite likely

Re: Heavy I/O blocks FreeBSD box for several seconds

2011-07-31 Thread Andriy Gapon
on 31/07/2011 22:03 Rick Macklem said the following: Ok, so if the scheduler spin lock is being held too long, what could cause this, if it isn't a scheduler bug? I can't think of how NFS would affect this beyond causing a heavy I/O load, but if there is some way it does, I suppose I need to

Re: [PATCH] updated /etc/rc.d/jail and added ZFS support

2011-07-31 Thread Martin Matuska
Dňa 30. 7. 2011 17:29, Alexander Leidinger wrote / napísal(a): On Thu, 28 Jul 2011 16:11:37 +0200 Martin Matuska m...@freebsd.org wrote: The attached patch allows better fine-tuning of jails started via /etc/rc.d, uses the new jail(8) flags (-c -m), the persist parameter and adds ZFS

Re: Heavy I/O blocks FreeBSD box for several seconds

2011-07-31 Thread Rick Macklem
Abdriy Gapon wrote: on 31/07/2011 22:03 Rick Macklem said the following: Ok, so if the scheduler spin lock is being held too long, what could cause this, if it isn't a scheduler bug? I can't think of how NFS would affect this beyond causing a heavy I/O load, but if there is some way

FreeBSD9 ifnet + Member Function void (*if_watchdog)(struct ifnet *ifp)

2011-07-31 Thread Olli Hauer
Hi, I just tried to build VMware modules for FreeBSD9-BETA1 and noticed the ifnet Member Function void (*if_watchdog)(struct ifnet *ifp) was removed from net/if_var.h. Is there a suggested replacement? PS: The man page for ifnet(9) does not reflect the remove of this (now missing) Member