Re: cardbus panic: end address is not aligned

2011-07-11 Thread Doug Barton
On 07/08/2011 06:19, John Baldwin wrote: > Hmm, well that's odd. It didn't grow it enough it seems. > >>> Also, can you boot your machine, then do 'sysctl debug.bootverbose=1', >>> insert >>> the card and record the messages in dmesg when it does? (You can likely >>> get >>> those out of kg

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

2011-07-11 Thread Rick Macklem
m...@freebsd.org wrote: > On Mon, Jul 11, 2011 at 4:00 PM, Ali Mashtizadeh > wrote: > > Maybe someone can setup something like reviewboard [1] for > > developers > > to use. This may also help folks who want to keep abreast of the > > current work in a particular subsystem or get involved into the

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

2011-07-11 Thread mdf
On Mon, Jul 11, 2011 at 4:00 PM, Ali Mashtizadeh wrote: > Maybe someone can setup something like reviewboard [1] for developers > to use. This may also help folks who want to keep abreast of the > current work in a particular subsystem or get involved into the > development process more. At my com

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

2011-07-11 Thread Ali Mashtizadeh
Maybe someone can setup something like reviewboard [1] for developers to use. This may also help folks who want to keep abreast of the current work in a particular subsystem or get involved into the development process more. At my company we use reviews and it seems to help the catch some bugs and

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

2011-07-11 Thread Steve Kargl
On Mon, Jul 11, 2011 at 05:50:44PM -0400, Arnaud Lacombe wrote: > > On Mon, Jul 11, 2011 at 5:38 PM, Arnaud Lacombe wrote: > > Hi, > > > > On Mon, Jul 11, 2011 at 4:40 PM, Steve Kargl > > wrote: > >> On Mon, Jul 11, 2011 at 04:33:44PM -0400, Arnaud Lacombe wrote: > >>> > >>> For the record, I wo

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

2011-07-11 Thread Arnaud Lacombe
Hi, [re-sent publicly, I did not "Replied-to-all":)] On Mon, Jul 11, 2011 at 5:38 PM, Arnaud Lacombe wrote: > Hi, > > On Mon, Jul 11, 2011 at 4:40 PM, Steve Kargl > wrote: >> On Mon, Jul 11, 2011 at 04:33:44PM -0400, Arnaud Lacombe wrote: >>> >>> For the record, I would like to see enforced pub

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

2011-07-11 Thread Arnaud Lacombe
Hi, On Mon, Jul 11, 2011 at 5:14 PM, Andriy Gapon wrote: > on 11/07/2011 23:33 Arnaud Lacombe said the following: >> For the record, I would like to see enforced public review for _every_ >> patch *before* it is checked in, as a strong rule. gcc system is >> particularly interesting. But it is no

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

2011-07-11 Thread Arnaud Lacombe
Hi, On Mon, Jul 11, 2011 at 4:40 PM, Steve Kargl wrote: > On Mon, Jul 11, 2011 at 04:33:44PM -0400, Arnaud Lacombe wrote: >> >> For the record, I would like to see enforced public review for _every_ >> patch *before* it is checked in, as a strong rule. gcc system is >> particularly interesting. B

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

2011-07-11 Thread Andriy Gapon
on 11/07/2011 23:33 Arnaud Lacombe said the following: > For the record, I would like to see enforced public review for _every_ > patch *before* it is checked in, as a strong rule. gcc system is > particularly interesting. But it is not likely to happen in FreeBSD > where FreeBSD committers are cle

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

2011-07-11 Thread Steve Kargl
On Mon, Jul 11, 2011 at 04:33:44PM -0400, Arnaud Lacombe wrote: > > For the record, I would like to see enforced public review for _every_ > patch *before* it is checked in, as a strong rule. gcc system is > particularly interesting. But it is not likely to happen in FreeBSD > where FreeBSD commit

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

2011-07-11 Thread Arnaud Lacombe
Hi, On Thu, Jul 7, 2011 at 7:45 PM, Adrian Chadd wrote: > (OT, yes, but I'd like to take a stab at explaining "why" these things > fall to the wayside..) > > On 7 July 2011 12:08, Arnaud Lacombe wrote: > >> What would be the point to even start looking at an issue? You guys >> (by "you", I mean

Re: [PATCH] Make top -P an interactive toggle

2011-07-11 Thread Alexander Best
On Mon Jul 11 11, John Baldwin wrote: > On Saturday, July 09, 2011 5:44:16 am Alexander Best wrote: > > On Sat Jul 9 11, Alexander Best wrote: > > > On Fri Jul 8 11, Alexander Best wrote: > > > > On Fri Jul 8 11, John Baldwin wrote: > > > > > This patch lets you use 'P' while top is running to t

Re: [PATCH] Improve LinuxThreads compatibility in rfork()

2011-07-11 Thread Kostik Belousov
On Mon, Jul 11, 2011 at 08:05:56PM +0200, Petr Salinger wrote: > >>Should the bit slice be 7 or 8 bits ? > > >I propose to go 8 bits, and add the check to be future-proof. > > >It seems that we already parse GNU/kFreeBSD brandnote. I think this > >could be used to distinguish between old behaviou

Re: [PATCH] Improve LinuxThreads compatibility in rfork()

2011-07-11 Thread Petr Salinger
Should the bit slice be 7 or 8 bits ? I propose to go 8 bits, and add the check to be future-proof. It seems that we already parse GNU/kFreeBSD brandnote. I think this could be used to distinguish between old behaviour, that is currently used by your libc, and proposed new interface, if __Fr

Re: [PATCH] Improve LinuxThreads compatibility in rfork()

2011-07-11 Thread Kostik Belousov
On Mon, Jul 11, 2011 at 06:12:15PM +0200, Petr Salinger wrote: > >I would instead use a new flag to specify a signal sent on the child > >death. Like RFTSIGZMB. If flag is not set, SIGCHLD is used. If it is > >set, the bit slice is used as signal number, 0 means do not send any > >signal. > > > >Pl

Re: [PATCH] Make top -P an interactive toggle

2011-07-11 Thread John Baldwin
On Saturday, July 09, 2011 5:44:16 am Alexander Best wrote: > On Sat Jul 9 11, Alexander Best wrote: > > On Fri Jul 8 11, Alexander Best wrote: > > > On Fri Jul 8 11, John Baldwin wrote: > > > > This patch lets you use 'P' while top is running to toggle between > > > > per-CPU and > > > > globa

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

2011-07-11 Thread Ivan Voras
On 11 July 2011 17:07, Andriy Gapon wrote: > Yeah, but what problem is demonstrated here? > Are we confident that non-even workload is inherently bad? > E.g.: > 79.39 + .. + 77.59 < 5 * 80 = 400 > 100.00 + ... + 55.18 ~~ 402 which is more than theoretically possible :-) > So it would _appear_ tha

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

2011-07-11 Thread Steve Kargl
On Mon, Jul 11, 2011 at 11:42:02PM +0800, Adrian Chadd wrote: > That top output is averaged and slow to adjust. > Using "top" as an indication as to what's really going on is likely > not a good idea. > Restoring top output here: > PID USERNAME THR PRI NICE SIZERES STATE C TIMEC

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

2011-07-11 Thread Steve Kargl
On Mon, Jul 11, 2011 at 06:07:04PM +0300, Andriy Gapon wrote: > on 11/07/2011 17:41 Ivan Voras said the following: > > On 07/07/2011 22:08, Steve Kargl wrote: > > > >> 4BSD kernel gives for N = Ncpu + 1. > >> > >> 34 processes: 6 running, 28 sleeping > >> > >>PID USERNAME THR PRI NICE SIZE

Re: [PATCH] Improve LinuxThreads compatibility in rfork()

2011-07-11 Thread Petr Salinger
I would instead use a new flag to specify a signal sent on the child death. Like RFTSIGZMB. If flag is not set, SIGCHLD is used. If it is set, the bit slice is used as signal number, 0 means do not send any signal. Please note that the signal should be checked for validity, it must be <= _SIG_MAX

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

2011-07-11 Thread Adrian Chadd
That top output is averaged and slow to adjust. Using "top" as an indication as to what's really going on is likely not a good idea. 2c, Adrian ___ freebsd-current@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To un

Re: [PATCH] Improve LinuxThreads compatibility in rfork()

2011-07-11 Thread Kostik Belousov
On Mon, Jul 11, 2011 at 05:43:23PM +0200, Petr Salinger wrote: > >>The 1st patch satisfies this. I agree that SIGCHLD part > >>is not easily readable. > >The SIGCHLD part is ugly. This is why I am asking about possible ways > >to overcome this. > > We need a way to specify "no signal". > It can be

Re: [PATCH] Improve LinuxThreads compatibility in rfork()

2011-07-11 Thread Petr Salinger
The 1st patch satisfies this. I agree that SIGCHLD part is not easily readable. The SIGCHLD part is ugly. This is why I am asking about possible ways to overcome this. We need a way to specify "no signal". It can be "new flag" or "ugly SIGCHLD". new flag: pros: cleaner design cons: one bit

Re: [PATCH] Improve LinuxThreads compatibility in rfork()

2011-07-11 Thread Petr Salinger
Can you, please, describe the reasoning behind the + if (sig == SIGCHLD) sig = 0; line ? The main reason is backward compatibility. The original FreeBSD code allows only to select between SIGUSR1 or SIGCHLD signals. The our extension changes meaning of RFLINUXTHPN to select sign

Re: [PATCH] Improve LinuxThreads compatibility in rfork()

2011-07-11 Thread Petr Salinger
RFLINUXPTH was used by the linuxthreads port, that was popular in the time of FreeBSD 4.x and may be 5.x to run mysql. I will object against this breakage. Do I understand correctly that API/ABI backward compatibility with previous FreeBSD releases w.r.t RFLINUXPTH is needed ? The 1st patch s

Re: [PATCH] Improve LinuxThreads compatibility in rfork()

2011-07-11 Thread Robert Millan
2011/7/11 Kostik Belousov : > I shall state that the sig == SIGCHLD case is ugly. Having the separate > flag "do not send signal to the parent" would be much less clumsy. > What are the requirements for the ABI stability for Debian/kFreeBSD ? > Can this be fixed now, or is it too late ? Perhaps we

Re: ZFS boot fails with two pools

2011-07-11 Thread Matt Burke
On 07/06/11 16:44, Berczi Gabor wrote: > For some reason FreeBSD can't boot automatically: ... > I have two pools, pool2 which is a mirrored zpool, and data being a > raid-z pool. Note how the default should be "pool2:/boot/zfsloader". How > can I fix this? The following applies to 8-STABLE from 2

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

2011-07-11 Thread Andriy Gapon
on 11/07/2011 17:41 Ivan Voras said the following: > On 07/07/2011 22:08, Steve Kargl wrote: > >> 4BSD kernel gives for N = Ncpu + 1. >> >> 34 processes: 6 running, 28 sleeping >> >>PID USERNAME THR PRI NICE SIZERES STATE C TIMECPU COMMAND >> 1417 kargl 1 710 370

Re: [PATCH] Improve LinuxThreads compatibility in rfork()

2011-07-11 Thread Kostik Belousov
On Mon, Jul 11, 2011 at 04:50:44PM +0200, Petr Salinger wrote: > >RFLINUXPTH was used by the linuxthreads port, that was popular in the > >time of FreeBSD 4.x and may be 5.x to run mysql. I will object against > >this breakage. > > Do I understand correctly that API/ABI backward compatibility with

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

2011-07-11 Thread Ivan Voras
On 07/07/2011 22:08, Steve Kargl wrote: 4BSD kernel gives for N = Ncpu + 1. 34 processes: 6 running, 28 sleeping PID USERNAME THR PRI NICE SIZERES STATE C TIMECPU COMMAND 1417 kargl 1 710 370M 294M RUN 0 1:30 79.39% sasmp 1416 kargl 1 710

Re: [PATCH] Improve LinuxThreads compatibility in rfork()

2011-07-11 Thread Kostik Belousov
On Mon, Jul 11, 2011 at 04:23:36PM +0200, Petr Salinger wrote: > >>>Can you, please, describe the reasoning behind the > + if (sig == SIGCHLD) sig = 0; > >>>line ? > >> > >>The main reason is backward compatibility. > >>The original FreeBSD code allows only to select between > >>SIGUSR1

Re: [PATCH] Improve LinuxThreads compatibility in rfork()

2011-07-11 Thread Kostik Belousov
On Mon, Jul 11, 2011 at 03:27:56PM +0200, Petr Salinger wrote: > >>This patch made by Petr Salinger improves compatibility with > >>LinuxThreads in rfork() syscall. The Linux clone() implementation > >>allows specifying the signal sent to parent when child terminates > >>(instead of SIGCHLD). > >>

Re: named crashes on assertion in rbtdb.c on sparc64/SMP

2011-07-11 Thread KOT MATPOCKuH
2011/7/8 Marius Strobl : > In order to have a result which can be compared with the base BIND. > Whether bind98 works or works without the ISC atomic operations says > nothing about the bind96 port or the base version. Okey... > Oops, sorry, I forgot to revert the previous patch when test-compili