Re: use_generic and usb probing

[Andriy Gapon]

on 06/04/2011 16:28 Hans Petter Selasky said the following:
> 
> Run a kernel test compile including all modules. If that's OK it should be 
> fine.

So I am going to commit this.
If it breaks anything for anyone and the problem would not be really trivial,
the I'll just revert the change.

-- 
Andriy Gapon
___
freebsd-current@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-current
To unsubscribe, send any mail to "freebsd-current-unsubscr...@freebsd.org"

Re: proposed smp_rendezvous change

[Andriy Gapon]

on 16/05/2011 23:09 John Baldwin said the following:
> On Monday, May 16, 2011 3:27:47 pm Andriy Gapon wrote:
>> on 16/05/2011 21:21 John Baldwin said the following:
>>> How about this:
>> ...
>>>  /* 
>>>   * Shared mutex to restrict busywaits between smp_rendezvous() and
>>> @@ -311,39 +312,62 @@ restart_cpus(cpumask_t map)
>>>  void
>>>  smp_rendezvous_action(void)
>>>  {
>>> -   void* local_func_arg = smp_rv_func_arg;
>>> -   void (*local_setup_func)(void*)   = smp_rv_setup_func;
>>> -   void (*local_action_func)(void*)   = smp_rv_action_func;
>>> -   void (*local_teardown_func)(void*) = smp_rv_teardown_func;
>>> +   void *local_func_arg;
>>> +   void (*local_setup_func)(void*);
>>> +   void (*local_action_func)(void*);
>>> +   void (*local_teardown_func)(void*);
>>> +   int generation;
>>>  
>>> /* Ensure we have up-to-date values. */
>>> atomic_add_acq_int(&smp_rv_waiters[0], 1);
>>> while (smp_rv_waiters[0] < smp_rv_ncpus)
>>> cpu_spinwait();
>>>  
>>> -   /* setup function */
>>> +   /* Fetch rendezvous parameters after acquire barrier. */
>>> +   local_func_arg = smp_rv_func_arg;
>>> +   local_setup_func = smp_rv_setup_func;
>>> +   local_action_func = smp_rv_action_func;
>>> +   local_teardown_func = smp_rv_teardown_func;
>>
>> I want to ask once again - please pretty please convince me that the above
>> cpu_spinwait() loop is really needed and, by extension, that the assignments
>> should be moved behind it.
>> Please :)
> 
> Well, moving the assignments down is a style fix for one, and we can always 
> remove the first rendezvous as a follow up if desired.

OK, makes sense.

> However, suppose you have an arch where sending an IPI is not a barrier
> (this seems unlikely).  In that case, the atomic_add_acq_int() will not
> succeed (and return) until it has seen the earlier write by the CPU
> initiating the rendezvous to clear smp_rv_waiters[0] to zero.  The actual
> spin on the smp_rv_waiters[] value is not strictly necessary however and

On this below.

> is probably just cut and pasted to match the other uses of values in
> the smp_rv_waiters[] array.
> 
> (atomic_add_acq_int() could spin on architectures where it is implemented
> using compare-and-swap (e.g. sparc64) or locked-load conditional-store (e.g. 
> Alpha).)


When you say "not strictly necessary", do you mean "not necessary"?
If you do not mean that, then when could it be (non-strictly) necessary? :)

Couldn't [Shouldn't] the whole:

>>> /* Ensure we have up-to-date values. */
>>> atomic_add_acq_int(&smp_rv_waiters[0], 1);
>>> while (smp_rv_waiters[0] < smp_rv_ncpus)
>>> cpu_spinwait();

be just replaced with:

rmb();

Or a proper MI function that does just a read memory barrier, if rmb() is not 
that.

-- 
Andriy Gapon
___
freebsd-current@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-current
To unsubscribe, send any mail to "freebsd-current-unsubscr...@freebsd.org"

Re: Boot halts on Thinkpad X220 (Sandy Bridge)

[Sevan / Venture37]

Hiya
If it's any help, I tried booting OpenBSD-Current on a ThinkPad X220
yesterday & it worked just fine (I forget to take my copy of 8-STABLE
snapshot which I downloaded from the allbsd site, otherwise I would've
post that too)

dmesg:
http://www.nycbug.org/?NAV=dmesgd;f_dmesg=;f_bsd=;f_nick=;f_descr=;dmesgid=2068#2068

Pcidump -vxx output:
http://pastebin.com/KqVMcqza

acpidump & Xorg.log:
http://www.sendspace.com/file/qtmkte

Sevan / Venture37
___
freebsd-current@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-current
To unsubscribe, send any mail to "freebsd-current-unsubscr...@freebsd.org"

Re: proposed smp_rendezvous change

[John Baldwin]

On 5/17/11 4:03 AM, Andriy Gapon wrote:

on 16/05/2011 23:09 John Baldwin said the following:

is probably just cut and pasted to match the other uses of values in
the smp_rv_waiters[] array.

(atomic_add_acq_int() could spin on architectures where it is implemented
using compare-and-swap (e.g. sparc64) or locked-load conditional-store (e.g.
Alpha).)



When you say "not strictly necessary", do you mean "not necessary"?
If you do not mean that, then when could it be (non-strictly) necessary? :)

Couldn't [Shouldn't] the whole:


/* Ensure we have up-to-date values. */
atomic_add_acq_int(&smp_rv_waiters[0], 1);
while (smp_rv_waiters[0]<  smp_rv_ncpus)
cpu_spinwait();


be just replaced with:

rmb();

Or a proper MI function that does just a read memory barrier, if rmb() is not 
that.


No, you could replace it with:

atomic_add_acq_int(&smp_rv_waiters[0], 1);

The key being that atomic_add_acq_int() will block (either in hardware 
or software) until it can safely perform the atomic operation.  That 
means waiting until the write to set smp_rv_waiters[0] to 0 by the 
rendezvous initiator is visible to the current CPU.


On some platforms a write by one CPU may not post instantly to other 
CPUs (e.g. it may sit in a store buffer).  That is fine so long as an 
attempt to update that value atomically (using cas or a 
conditional-store, etc.) fails.  For those platforms, the atomic(9) API 
is required to spin until it succeeds.


This is why the mtx code spins if it can't set MTX_CONTESTED for example.

--
John Baldwin
___
freebsd-current@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-current
To unsubscribe, send any mail to "freebsd-current-unsubscr...@freebsd.org"

Re: proposed smp_rendezvous change

[John Baldwin]

On 5/16/11 6:05 PM, Max Laier wrote:

On Monday 16 May 2011 17:54:54 Attilio Rao wrote:

2011/5/16 Max Laier:

On Monday 16 May 2011 16:46:03 John Baldwin wrote:

On Monday, May 16, 2011 4:30:44 pm Max Laier wrote:

On Monday 16 May 2011 14:21:27 John Baldwin wrote:

Yes, we need to fix that.  Humm, it doesn't preempt when you do a
critical_exit() though?  Or do you use a hand-rolled critical exit
that doesn't do a deferred preemption?


Right now I just did a manual td_critnest++/--, but I guess ...


Ah, ok, so you would "lose" a preemption.  That's not really ideal.


Actually, I'm curious how the spin unlock inside the IPI could yield
the CPU.  Oh, is rmlock doing a wakeup inside the IPI handler?  I
guess that is ok as long as the critical_exit() just defers the
preemption to the end of the IPI handler.


... the earliest point where it is safe to preempt is after doing the

atomic_add_int(&smp_rv_waiters[2], 1);

so that we can start other IPIs again.  However, since we don't accept
new IPIs until we signal EOI in the MD code (on amd64), this might
still not be a good place to do the yield?!?


Hmm, yeah, you would want to do the EOI before you yield.  However, we
could actually move the EOI up before calling the MI code so long as we
leave interrupts disabled for the duration of the handler (which we do).


The spin unlock boils down to a critical_exit() and unless we did a
critical_enter() at some point during the redenvouz setup, we will
yield() if we owepreempt.  I'm not quite sure how that can happen, but
it seems like there is a path that allows the scheduler to set it from
a foreign CPU.


No, it is only set on curthread by curthread.  This is actually my main
question.  I've no idea how this could happen unless the rmlock code is
actually triggering a wakeup or sched_add() in its rendezvous handler.

I don't see anything in rm_cleanIPI() that would do that however.

I wonder if your original issue was really fixed  just by the first
patch you had which fixed the race in smp_rendezvous()?


I found the stack that lead me to this patch in the first place:

#0  sched_switch (td=0xff011a97, newtd=0xff006e6784b0,
flags=4) at src/sys/kern/sched_ule.c:1939
#1  0x80285c7f in mi_switch (flags=6, newtd=0x0) at
src/sys/kern/kern_synch.c:475
#2  0x802a2cb3 in critical_exit () at
src/sys/kern/kern_switch.c:185 #3  0x80465807 in spinlock_exit
() at
src/sys/amd64/amd64/machdep.c:1458
#4  0x8027adea in rm_cleanIPI (arg=) at
src/sys/kern/kern_rmlock.c:180
#5  0x802b9887 in smp_rendezvous_action () at
src/sys/kern/subr_smp.c:402
#6  0x8045e2a4 in Xrendezvous () at
src/sys/amd64/amd64/apic_vector.S:235
#7  0x802a2c6e in critical_exit () at
src/sys/kern/kern_switch.c:179 #8  0x804365ba in uma_zfree_arg
(zone=0xff009ff4b5a0, item=0xff000f34cd40,
udata=0xff000f34ce08) at
src/sys/vm/uma_core.c:2370
.
.
.

and now that I look at it again, it is clear that critical_exit() just
isn't interrupt safe.  I'm not sure how to fix that, yet ... but this:


if (td->td_critnest == 1) {
td->td_critnest = 0;
if (td->td_owepreempt) {
td->td_critnest = 1;

clearly doesn't work.


I'm sorry if I didn't reply to the whole rendezvous thread, but as
long as there is so many people taking care of it, I'll stay hidden in
my corner.

I just wanted to tell that I think you are misunderstanding what
critical section is supposed to do.

When an interrupt fires, it goes on the old "interrupt/kernel context"
which means it has not a context of his own. That is the reason why we
disable interrupts on spinlocks (or similar workaround for !x86
architectures) and this is why spinlocks are the only protection
usable in code that runs in interrupt context.

Preempting just means another thread will be scheduler in the middle
of another thread execution path.

This code is perfectly fine if you consider curthread won't be
descheduled while it is executing.


Well, no - it is not.  With this you can end up with a curthread that has
td_critnest=0 and td_owepreempt=1 in interrupt context.  If you use a spinlock
on such a thread, it will do the preemption at the point where you drop the
spinlock, this is bad in some circumstances.  One example is the smp_rendevous
case we are discussing here.


Yes, the 'owepreempt' flag can leak because we allow it to be set while 
td_critnest is 0.  That is the problem, and I think we added this as an 
optimization in the last round of changes to this routine to avoid 
excessive context switches.  However, I think we will just have to 
revert that optimization and prevent that state from occurring.


Hmm, the log message for the change said it was to avoid races.

http://svnweb.freebsd.org/base?view=revision&revision=144777

That is what introduced the bug of mixing those two states.  Hmmm, the 
reason for moving the td_critnest == 0 up according to my old e-mails 

Re: pcib allocation failure

[John Baldwin]

On Saturday, May 14, 2011 12:27:59 pm deeptec...@gmail.com wrote:
> pcib1:  at device 1.0 on pci0
> pcib1: failed to allocate initial prefetch window: 0xd000-0xfaff
> 
> the console output is cut shortly after those 2 lines (but the machine
> seems to continue booting, as i have reset'd the machine, after which
> "/" was found to be improperly dismounted).

So it actually boots fine, but video output breaks during the boot?  Does it 
ever come back or it is permanently broken until reboot?

Your BIOS is actually violating the PCI spec by assigning the same resource 
ranges to two devices on the same PCI bus (the hostb device and the AGP bridge 
device).  It's also doing so unnecessarily.

-- 
John Baldwin
___
freebsd-current@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-current
To unsubscribe, send any mail to "freebsd-current-unsubscr...@freebsd.org"

Re: proposed smp_rendezvous change

[Andriy Gapon]

on 17/05/2011 14:56 John Baldwin said the following:
> On 5/17/11 4:03 AM, Andriy Gapon wrote:
>> Couldn't [Shouldn't] the whole:
>>
>   /* Ensure we have up-to-date values. */
>   atomic_add_acq_int(&smp_rv_waiters[0], 1);
>   while (smp_rv_waiters[0]<  smp_rv_ncpus)
>   cpu_spinwait();
>>
>> be just replaced with:
>>
>> rmb();
>>
>> Or a proper MI function that does just a read memory barrier, if rmb() is 
>> not that.
> 
> No, you could replace it with:
> 
> atomic_add_acq_int(&smp_rv_waiters[0], 1);

What about
(void)atomic_load_acq(&smp_rv_waiters[0]);

In my opinion that should ensure that the hardware must post the latest value 
from
a master CPU to memory of smp_rv_waiters[0] and a slave CPU gets it from there.
And also, because of memory barriers inserted by store_rel on the master CPU and
load_acq on the slave CPU, the latest values of all other smp_rv_* fields should
become visible to the slave CPU.

> The key being that atomic_add_acq_int() will block (either in hardware or
> software) until it can safely perform the atomic operation.  That means 
> waiting
> until the write to set smp_rv_waiters[0] to 0 by the rendezvous initiator is
> visible to the current CPU.
> 
> On some platforms a write by one CPU may not post instantly to other CPUs 
> (e.g. it
> may sit in a store buffer).  That is fine so long as an attempt to update that
> value atomically (using cas or a conditional-store, etc.) fails.  For those
> platforms, the atomic(9) API is required to spin until it succeeds.
> 
> This is why the mtx code spins if it can't set MTX_CONTESTED for example.
> 

Thank you for the great explanation!
Taking sparc64 as an example, I think that atomic_load_acq uses a degenerate cas
call, which should take care of hardware synchronization.

-- 
Andriy Gapon
___
freebsd-current@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-current
To unsubscribe, send any mail to "freebsd-current-unsubscr...@freebsd.org"

Re: proposed smp_rendezvous change

[John Baldwin]

On Tuesday, May 17, 2011 9:46:34 am Andriy Gapon wrote:
> on 17/05/2011 14:56 John Baldwin said the following:
> > On 5/17/11 4:03 AM, Andriy Gapon wrote:
> >> Couldn't [Shouldn't] the whole:
> >>
> >   /* Ensure we have up-to-date values. */
> >   atomic_add_acq_int(&smp_rv_waiters[0], 1);
> >   while (smp_rv_waiters[0]<  smp_rv_ncpus)
> >   cpu_spinwait();
> >>
> >> be just replaced with:
> >>
> >> rmb();
> >>
> >> Or a proper MI function that does just a read memory barrier, if rmb() is 
> >> not that.
> > 
> > No, you could replace it with:
> > 
> > atomic_add_acq_int(&smp_rv_waiters[0], 1);
> 
> What about
> (void)atomic_load_acq(&smp_rv_waiters[0]);
> 
> In my opinion that should ensure that the hardware must post the latest value 
> from
> a master CPU to memory of smp_rv_waiters[0] and a slave CPU gets it from 
> there.
> And also, because of memory barriers inserted by store_rel on the master CPU 
> and
> load_acq on the slave CPU, the latest values of all other smp_rv_* fields 
> should
> become visible to the slave CPU.

No, it doesn't quite work that way.  It wouldn't work on Alpha for example.

All load_acq is a load with a memory barrier to order other loads after it.
It is still free to load stale data.  Only a read-modify-write operation
would actually block until it could access an up-to-date value.

> 
> > The key being that atomic_add_acq_int() will block (either in hardware or
> > software) until it can safely perform the atomic operation.  That means 
> > waiting
> > until the write to set smp_rv_waiters[0] to 0 by the rendezvous initiator is
> > visible to the current CPU.
> > 
> > On some platforms a write by one CPU may not post instantly to other CPUs 
> > (e.g. it
> > may sit in a store buffer).  That is fine so long as an attempt to update 
> > that
> > value atomically (using cas or a conditional-store, etc.) fails.  For those
> > platforms, the atomic(9) API is required to spin until it succeeds.
> > 
> > This is why the mtx code spins if it can't set MTX_CONTESTED for example.
> > 
> 
> Thank you for the great explanation!
> Taking sparc64 as an example, I think that atomic_load_acq uses a degenerate 
> cas
> call, which should take care of hardware synchronization.

sparc64's load_acq() is stronger than the MI effect of load_acq().  On ia64
which uses ld.acq or Alpha (originally) which uses a membar and simple load,
the guarantees are only what I stated above (and would not be sufficient).

Note that Alpha borrowed heavily from MIPS, and the MIPS atomic implementation
is mostly identical to the old Alpha one (using conditional stores, etc.).

The MIPS atomic_load_acq():

#define ATOMIC_STORE_LOAD(WIDTH)\
static __inline  uint##WIDTH##_t\
atomic_load_acq_##WIDTH(__volatile uint##WIDTH##_t *p)  \
{   \
uint##WIDTH##_t v;  \
\
v = *p; \
mips_sync();\
return (v); \
}   \


-- 
John Baldwin
___
freebsd-current@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-current
To unsubscribe, send any mail to "freebsd-current-unsubscr...@freebsd.org"

Re: proposed smp_rendezvous change

[Andriy Gapon]

on 17/05/2011 16:58 John Baldwin said the following:
> No, it doesn't quite work that way.  It wouldn't work on Alpha for example.
> 
> All load_acq is a load with a memory barrier to order other loads after it.
> It is still free to load stale data.  Only a read-modify-write operation
> would actually block until it could access an up-to-date value.

Hmm, ok.
How about atomic_add_acq_int(&smp_rv_waiters[0], 0) ? :-)
Or an equivalent MI action that doesn't actually change smp_rv_waiters[0] value,
if there could be any.
Maybe explicit atomic_cmpset_acq_int(&smp_rv_waiters[0], 0, 0) ?

You see at what I am getting?

>>> The key being that atomic_add_acq_int() will block (either in hardware or
>>> software) until it can safely perform the atomic operation.  That means 
>>> waiting
>>> until the write to set smp_rv_waiters[0] to 0 by the rendezvous initiator is
>>> visible to the current CPU.
>>>
>>> On some platforms a write by one CPU may not post instantly to other CPUs 
>>> (e.g. it
>>> may sit in a store buffer).  That is fine so long as an attempt to update 
>>> that
>>> value atomically (using cas or a conditional-store, etc.) fails.  For those
>>> platforms, the atomic(9) API is required to spin until it succeeds.
>>>
>>> This is why the mtx code spins if it can't set MTX_CONTESTED for example.
>>>
>>
>> Thank you for the great explanation!
>> Taking sparc64 as an example, I think that atomic_load_acq uses a degenerate 
>> cas
>> call, which should take care of hardware synchronization.
> 
> sparc64's load_acq() is stronger than the MI effect of load_acq().  On ia64

Oh, well, my expectation was that MI effect of atomic_load (emphasis on atomic_)
was to get a non-stale value.

> which uses ld.acq or Alpha (originally) which uses a membar and simple load,
> the guarantees are only what I stated above (and would not be sufficient).
> 
> Note that Alpha borrowed heavily from MIPS, and the MIPS atomic implementation
> is mostly identical to the old Alpha one (using conditional stores, etc.).
> 
> The MIPS atomic_load_acq():
> 
> #define ATOMIC_STORE_LOAD(WIDTH)\
> static __inline  uint##WIDTH##_t\
> atomic_load_acq_##WIDTH(__volatile uint##WIDTH##_t *p)  \
> {   \
> uint##WIDTH##_t v;  \
> \
> v = *p; \
> mips_sync();\
> return (v); \
> }   \

I should have checked this myself.
Thank you for patiently explaining these things to me.

-- 
Andriy Gapon
___
freebsd-current@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-current
To unsubscribe, send any mail to "freebsd-current-unsubscr...@freebsd.org"

[head tinderbox] failure on arm/arm

[FreeBSD Tinderbox]

TB --- 2011-05-17 13:50:00 - tinderbox 2.7 running on freebsd-current.sentex.ca
TB --- 2011-05-17 13:50:00 - starting HEAD tinderbox run for arm/arm
TB --- 2011-05-17 13:50:00 - cleaning the object tree
TB --- 2011-05-17 13:50:16 - cvsupping the source tree
TB --- 2011-05-17 13:50:16 - /usr/bin/csup -z -r 3 -g -L 1 -h cvsup.sentex.ca 
/tinderbox/HEAD/arm/arm/supfile
TB --- 2011-05-17 13:51:03 - building world
TB --- 2011-05-17 13:51:03 - MAKEOBJDIRPREFIX=/obj
TB --- 2011-05-17 13:51:03 - PATH=/usr/bin:/usr/sbin:/bin:/sbin
TB --- 2011-05-17 13:51:03 - TARGET=arm
TB --- 2011-05-17 13:51:03 - TARGET_ARCH=arm
TB --- 2011-05-17 13:51:03 - TZ=UTC
TB --- 2011-05-17 13:51:03 - __MAKE_CONF=/dev/null
TB --- 2011-05-17 13:51:03 - cd /src
TB --- 2011-05-17 13:51:03 - /usr/bin/make -B buildworld
>>> World build started on Tue May 17 13:51:03 UTC 2011
>>> Rebuilding the temporary build tree
>>> stage 1.1: legacy release compatibility shims
>>> stage 1.2: bootstrap tools
>>> stage 2.1: cleaning up the object tree
>>> stage 2.2: rebuilding the object tree
>>> stage 2.3: build tools
>>> stage 3: cross tools
>>> stage 4.1: building includes
>>> stage 4.2: building libraries
>>> stage 4.3: make dependencies
>>> stage 4.4: building everything
>>> World build completed on Tue May 17 14:43:07 UTC 2011
TB --- 2011-05-17 14:43:07 - WARNING: no kernel config for LINT
TB --- 2011-05-17 14:43:07 - cd /src/sys/arm/conf
TB --- 2011-05-17 14:43:07 - /usr/sbin/config -m AVILA
TB --- 2011-05-17 14:43:07 - building AVILA kernel
TB --- 2011-05-17 14:43:07 - MAKEOBJDIRPREFIX=/obj
TB --- 2011-05-17 14:43:07 - PATH=/usr/bin:/usr/sbin:/bin:/sbin
TB --- 2011-05-17 14:43:07 - TARGET=arm
TB --- 2011-05-17 14:43:07 - TARGET_ARCH=arm
TB --- 2011-05-17 14:43:07 - TZ=UTC
TB --- 2011-05-17 14:43:07 - __MAKE_CONF=/dev/null
TB --- 2011-05-17 14:43:07 - cd /src
TB --- 2011-05-17 14:43:07 - /usr/bin/make -B buildkernel KERNCONF=AVILA
>>> Kernel build for AVILA started on Tue May 17 14:43:07 UTC 2011
>>> stage 1: configuring the kernel
>>> stage 2.1: cleaning up the object tree
>>> stage 2.2: rebuilding the object tree
>>> stage 2.3: build tools
>>> stage 3.1: making dependencies
>>> stage 3.2: building everything
[...]
cc -mbig-endian -c -O -pipe  -std=c99 -g -Wall -Wredundant-decls 
-Wnested-externs -Wstrict-prototypes  -Wmissing-prototypes -Wpointer-arith 
-Winline -Wcast-qual  -Wundef -Wno-pointer-sign -fformat-extensions  
-Wmissing-include-dirs -nostdinc  -I. -I/src/sys -I/src/sys/contrib/altq 
-I/src/sys/contrib/libfdt -D_KERNEL -DHAVE_KERNEL_OPTION_HEADERS -include 
opt_global.h -fno-common -finline-limit=8000 --param inline-unit-growth=100 
--param large-function-growth=1000 -mcpu=xscale -ffreestanding -Werror  
/src/sys/dev/ath/ath_hal/ar5212/ar5212_gpio.c -I/src/sys/dev/ath 
-I/src/sys/dev/ath/ath_hal
cc -mbig-endian -c -O -pipe  -std=c99 -g -Wall -Wredundant-decls 
-Wnested-externs -Wstrict-prototypes  -Wmissing-prototypes -Wpointer-arith 
-Winline -Wcast-qual  -Wundef -Wno-pointer-sign -fformat-extensions  
-Wmissing-include-dirs -nostdinc  -I. -I/src/sys -I/src/sys/contrib/altq 
-I/src/sys/contrib/libfdt -D_KERNEL -DHAVE_KERNEL_OPTION_HEADERS -include 
opt_global.h -fno-common -finline-limit=8000 --param inline-unit-growth=100 
--param large-function-growth=1000 -mcpu=xscale -ffreestanding -Werror  
/src/sys/dev/ath/ath_hal/ar5212/ar5212_interrupts.c -I/src/sys/dev/ath 
-I/src/sys/dev/ath/ath_hal
cc -mbig-endian -c -O -pipe  -std=c99 -g -Wall -Wredundant-decls 
-Wnested-externs -Wstrict-prototypes  -Wmissing-prototypes -Wpointer-arith 
-Winline -Wcast-qual  -Wundef -Wno-pointer-sign -fformat-extensions  
-Wmissing-include-dirs -nostdinc  -I. -I/src/sys -I/src/sys/contrib/altq 
-I/src/sys/contrib/libfdt -D_KERNEL -DHAVE_KERNEL_OPTION_HEADERS -include 
opt_global.h -fno-common -finline-limit=8000 --param inline-unit-growth=100 
--param large-function-growth=1000 -mcpu=xscale -ffreestanding -Werror  
/src/sys/dev/ath/ath_hal/ar5212/ar5212_keycache.c -I/src/sys/dev/ath 
-I/src/sys/dev/ath/ath_hal
cc -mbig-endian -c -O -pipe  -std=c99 -g -Wall -Wredundant-decls 
-Wnested-externs -Wstrict-prototypes  -Wmissing-prototypes -Wpointer-arith 
-Winline -Wcast-qual  -Wundef -Wno-pointer-sign -fformat-extensions  
-Wmissing-include-dirs -nostdinc  -I. -I/src/sys -I/src/sys/contrib/altq 
-I/src/sys/contrib/libfdt -D_KERNEL -DHAVE_KERNEL_OPTION_HEADERS -include 
opt_global.h -fno-common -finline-limit=8000 --param inline-unit-growth=100 
--param large-function-growth=1000 -mcpu=xscale -ffreestanding -Werror  
/src/sys/dev/ath/ath_hal/ar5212/ar5212_misc.c -I/src/sys/dev/ath 
-I/src/sys/dev/ath/ath_hal
/src/sys/dev/ath/ath_hal/ar5212/ar5212_misc.c: In function 
'ar5212GetCapability':
/src/sys/dev/ath/ath_hal/ar5212/ar5212_misc.c:860: error: 'pcap' undeclared 
(first use in this function)
/src/sys/dev/ath/ath_hal/ar5212/ar5212_misc.c:860: error: (Each undeclared 
identifier is reported only once
/src/sys/dev/ath/ath_hal/ar5212/ar5212_misc.c:860: error: for each

[head tinderbox] failure on i386/pc98

[FreeBSD Tinderbox]

TB --- 2011-05-17 13:50:00 - tinderbox 2.7 running on freebsd-current.sentex.ca
TB --- 2011-05-17 13:50:00 - starting HEAD tinderbox run for i386/pc98
TB --- 2011-05-17 13:50:00 - cleaning the object tree
TB --- 2011-05-17 13:50:18 - cvsupping the source tree
TB --- 2011-05-17 13:50:18 - /usr/bin/csup -z -r 3 -g -L 1 -h cvsup.sentex.ca 
/tinderbox/HEAD/i386/pc98/supfile
TB --- 2011-05-17 13:51:03 - building world
TB --- 2011-05-17 13:51:03 - MAKEOBJDIRPREFIX=/obj
TB --- 2011-05-17 13:51:03 - PATH=/usr/bin:/usr/sbin:/bin:/sbin
TB --- 2011-05-17 13:51:03 - TARGET=pc98
TB --- 2011-05-17 13:51:03 - TARGET_ARCH=i386
TB --- 2011-05-17 13:51:03 - TZ=UTC
TB --- 2011-05-17 13:51:03 - __MAKE_CONF=/dev/null
TB --- 2011-05-17 13:51:03 - cd /src
TB --- 2011-05-17 13:51:03 - /usr/bin/make -B buildworld
>>> World build started on Tue May 17 13:51:03 UTC 2011
>>> Rebuilding the temporary build tree
>>> stage 1.1: legacy release compatibility shims
>>> stage 1.2: bootstrap tools
>>> stage 2.1: cleaning up the object tree
>>> stage 2.2: rebuilding the object tree
>>> stage 2.3: build tools
>>> stage 3: cross tools
>>> stage 4.1: building includes
>>> stage 4.2: building libraries
>>> stage 4.3: make dependencies
>>> stage 4.4: building everything
>>> World build completed on Tue May 17 15:46:50 UTC 2011
TB --- 2011-05-17 15:46:51 - generating LINT kernel config
TB --- 2011-05-17 15:46:51 - cd /src/sys/pc98/conf
TB --- 2011-05-17 15:46:51 - /usr/bin/make -B LINT
TB --- 2011-05-17 15:46:51 - building LINT kernel
TB --- 2011-05-17 15:46:51 - MAKEOBJDIRPREFIX=/obj
TB --- 2011-05-17 15:46:51 - PATH=/usr/bin:/usr/sbin:/bin:/sbin
TB --- 2011-05-17 15:46:51 - TARGET=pc98
TB --- 2011-05-17 15:46:51 - TARGET_ARCH=i386
TB --- 2011-05-17 15:46:51 - TZ=UTC
TB --- 2011-05-17 15:46:51 - __MAKE_CONF=/dev/null
TB --- 2011-05-17 15:46:51 - cd /src
TB --- 2011-05-17 15:46:51 - /usr/bin/make -B buildkernel KERNCONF=LINT
>>> Kernel build for LINT started on Tue May 17 15:46:51 UTC 2011
>>> stage 1: configuring the kernel
>>> stage 2.1: cleaning up the object tree
>>> stage 2.2: rebuilding the object tree
>>> stage 2.3: build tools
>>> stage 3.1: making dependencies
>>> stage 3.2: building everything
[...]
cc -c -O2 -pipe -fno-strict-aliasing  -std=c99  -Wall -Wredundant-decls 
-Wnested-externs -Wstrict-prototypes  -Wmissing-prototypes -Wpointer-arith 
-Winline -Wcast-qual  -Wundef -Wno-pointer-sign -fformat-extensions  
-Wmissing-include-dirs -nostdinc  -I. -I/src/sys -I/src/sys/contrib/altq 
-D_KERNEL -DHAVE_KERNEL_OPTION_HEADERS -include opt_global.h -fno-common 
-finline-limit=8000 --param inline-unit-growth=100 --param 
large-function-growth=1000 -DGPROF -falign-functions=16 -DGPROF4 -DGUPROF 
-fno-builtin -mno-align-long-strings -mpreferred-stack-boundary=2 -mno-sse 
-mno-mmx -msoft-float -ffreestanding -fstack-protector -Werror -pg 
-mprofiler-epilogue /src/sys/dev/ath/ath_hal/ar5212/ar5212_gpio.c 
-I/src/sys/dev/ath -I/src/sys/dev/ath/ath_hal
cc -c -O2 -pipe -fno-strict-aliasing  -std=c99  -Wall -Wredundant-decls 
-Wnested-externs -Wstrict-prototypes  -Wmissing-prototypes -Wpointer-arith 
-Winline -Wcast-qual  -Wundef -Wno-pointer-sign -fformat-extensions  
-Wmissing-include-dirs -nostdinc  -I. -I/src/sys -I/src/sys/contrib/altq 
-D_KERNEL -DHAVE_KERNEL_OPTION_HEADERS -include opt_global.h -fno-common 
-finline-limit=8000 --param inline-unit-growth=100 --param 
large-function-growth=1000 -DGPROF -falign-functions=16 -DGPROF4 -DGUPROF 
-fno-builtin -mno-align-long-strings -mpreferred-stack-boundary=2 -mno-sse 
-mno-mmx -msoft-float -ffreestanding -fstack-protector -Werror -pg 
-mprofiler-epilogue /src/sys/dev/ath/ath_hal/ar5212/ar5212_interrupts.c 
-I/src/sys/dev/ath -I/src/sys/dev/ath/ath_hal
cc -c -O2 -pipe -fno-strict-aliasing  -std=c99  -Wall -Wredundant-decls 
-Wnested-externs -Wstrict-prototypes  -Wmissing-prototypes -Wpointer-arith 
-Winline -Wcast-qual  -Wundef -Wno-pointer-sign -fformat-extensions  
-Wmissing-include-dirs -nostdinc  -I. -I/src/sys -I/src/sys/contrib/altq 
-D_KERNEL -DHAVE_KERNEL_OPTION_HEADERS -include opt_global.h -fno-common 
-finline-limit=8000 --param inline-unit-growth=100 --param 
large-function-growth=1000 -DGPROF -falign-functions=16 -DGPROF4 -DGUPROF 
-fno-builtin -mno-align-long-strings -mpreferred-stack-boundary=2 -mno-sse 
-mno-mmx -msoft-float -ffreestanding -fstack-protector -Werror -pg 
-mprofiler-epilogue /src/sys/dev/ath/ath_hal/ar5212/ar5212_keycache.c 
-I/src/sys/dev/ath -I/src/sys/dev/ath/ath_hal
cc -c -O2 -pipe -fno-strict-aliasing  -std=c99  -Wall -Wredundant-decls 
-Wnested-externs -Wstrict-prototypes  -Wmissing-prototypes -Wpointer-arith 
-Winline -Wcast-qual  -Wundef -Wno-pointer-sign -fformat-extensions  
-Wmissing-include-dirs -nostdinc  -I. -I/src/sys -I/src/sys/contrib/altq 
-D_KERNEL -DHAVE_KERNEL_OPTION_HEADERS -include opt_global.h -fno-common 
-finline-limit=8000 --param inline-unit-growth=100 --param 
large-function-growth=1000 -DGPROF -falign-functions=16 -DGPROF4 -DGUPROF 
-fno

[head tinderbox] failure on i386/i386

[FreeBSD Tinderbox]

TB --- 2011-05-17 13:50:00 - tinderbox 2.7 running on freebsd-current.sentex.ca
TB --- 2011-05-17 13:50:00 - starting HEAD tinderbox run for i386/i386
TB --- 2011-05-17 13:50:00 - cleaning the object tree
TB --- 2011-05-17 13:50:25 - cvsupping the source tree
TB --- 2011-05-17 13:50:25 - /usr/bin/csup -z -r 3 -g -L 1 -h cvsup.sentex.ca 
/tinderbox/HEAD/i386/i386/supfile
TB --- 2011-05-17 13:55:49 - building world
TB --- 2011-05-17 13:55:49 - MAKEOBJDIRPREFIX=/obj
TB --- 2011-05-17 13:55:49 - PATH=/usr/bin:/usr/sbin:/bin:/sbin
TB --- 2011-05-17 13:55:49 - TARGET=i386
TB --- 2011-05-17 13:55:49 - TARGET_ARCH=i386
TB --- 2011-05-17 13:55:49 - TZ=UTC
TB --- 2011-05-17 13:55:49 - __MAKE_CONF=/dev/null
TB --- 2011-05-17 13:55:49 - cd /src
TB --- 2011-05-17 13:55:49 - /usr/bin/make -B buildworld
>>> World build started on Tue May 17 13:55:50 UTC 2011
>>> Rebuilding the temporary build tree
>>> stage 1.1: legacy release compatibility shims
>>> stage 1.2: bootstrap tools
>>> stage 2.1: cleaning up the object tree
>>> stage 2.2: rebuilding the object tree
>>> stage 2.3: build tools
>>> stage 3: cross tools
>>> stage 4.1: building includes
>>> stage 4.2: building libraries
>>> stage 4.3: make dependencies
>>> stage 4.4: building everything
>>> World build completed on Tue May 17 15:52:35 UTC 2011
TB --- 2011-05-17 15:52:35 - generating LINT kernel config
TB --- 2011-05-17 15:52:35 - cd /src/sys/i386/conf
TB --- 2011-05-17 15:52:35 - /usr/bin/make -B LINT
TB --- 2011-05-17 15:52:36 - building LINT kernel
TB --- 2011-05-17 15:52:36 - MAKEOBJDIRPREFIX=/obj
TB --- 2011-05-17 15:52:36 - PATH=/usr/bin:/usr/sbin:/bin:/sbin
TB --- 2011-05-17 15:52:36 - TARGET=i386
TB --- 2011-05-17 15:52:36 - TARGET_ARCH=i386
TB --- 2011-05-17 15:52:36 - TZ=UTC
TB --- 2011-05-17 15:52:36 - __MAKE_CONF=/dev/null
TB --- 2011-05-17 15:52:36 - cd /src
TB --- 2011-05-17 15:52:36 - /usr/bin/make -B buildkernel KERNCONF=LINT
>>> Kernel build for LINT started on Tue May 17 15:52:36 UTC 2011
>>> stage 1: configuring the kernel
>>> stage 2.1: cleaning up the object tree
>>> stage 2.2: rebuilding the object tree
>>> stage 2.3: build tools
>>> stage 3.1: making dependencies
>>> stage 3.2: building everything
[...]
cc -c -O2 -pipe -fno-strict-aliasing  -std=c99  -Wall -Wredundant-decls 
-Wnested-externs -Wstrict-prototypes  -Wmissing-prototypes -Wpointer-arith 
-Winline -Wcast-qual  -Wundef -Wno-pointer-sign -fformat-extensions  
-Wmissing-include-dirs -nostdinc  -I. -I/src/sys -I/src/sys/contrib/altq 
-D_KERNEL -DHAVE_KERNEL_OPTION_HEADERS -include opt_global.h -fno-common 
-finline-limit=8000 --param inline-unit-growth=100 --param 
large-function-growth=1000 -DGPROF -falign-functions=16 -DGPROF4 -DGUPROF 
-fno-builtin -mno-align-long-strings -mpreferred-stack-boundary=2 -mno-sse 
-mno-mmx -msoft-float -ffreestanding -fstack-protector -Werror -pg 
-mprofiler-epilogue /src/sys/dev/ath/ath_hal/ar5212/ar5212_gpio.c 
-I/src/sys/dev/ath -I/src/sys/dev/ath/ath_hal
cc -c -O2 -pipe -fno-strict-aliasing  -std=c99  -Wall -Wredundant-decls 
-Wnested-externs -Wstrict-prototypes  -Wmissing-prototypes -Wpointer-arith 
-Winline -Wcast-qual  -Wundef -Wno-pointer-sign -fformat-extensions  
-Wmissing-include-dirs -nostdinc  -I. -I/src/sys -I/src/sys/contrib/altq 
-D_KERNEL -DHAVE_KERNEL_OPTION_HEADERS -include opt_global.h -fno-common 
-finline-limit=8000 --param inline-unit-growth=100 --param 
large-function-growth=1000 -DGPROF -falign-functions=16 -DGPROF4 -DGUPROF 
-fno-builtin -mno-align-long-strings -mpreferred-stack-boundary=2 -mno-sse 
-mno-mmx -msoft-float -ffreestanding -fstack-protector -Werror -pg 
-mprofiler-epilogue /src/sys/dev/ath/ath_hal/ar5212/ar5212_interrupts.c 
-I/src/sys/dev/ath -I/src/sys/dev/ath/ath_hal
cc -c -O2 -pipe -fno-strict-aliasing  -std=c99  -Wall -Wredundant-decls 
-Wnested-externs -Wstrict-prototypes  -Wmissing-prototypes -Wpointer-arith 
-Winline -Wcast-qual  -Wundef -Wno-pointer-sign -fformat-extensions  
-Wmissing-include-dirs -nostdinc  -I. -I/src/sys -I/src/sys/contrib/altq 
-D_KERNEL -DHAVE_KERNEL_OPTION_HEADERS -include opt_global.h -fno-common 
-finline-limit=8000 --param inline-unit-growth=100 --param 
large-function-growth=1000 -DGPROF -falign-functions=16 -DGPROF4 -DGUPROF 
-fno-builtin -mno-align-long-strings -mpreferred-stack-boundary=2 -mno-sse 
-mno-mmx -msoft-float -ffreestanding -fstack-protector -Werror -pg 
-mprofiler-epilogue /src/sys/dev/ath/ath_hal/ar5212/ar5212_keycache.c 
-I/src/sys/dev/ath -I/src/sys/dev/ath/ath_hal
cc -c -O2 -pipe -fno-strict-aliasing  -std=c99  -Wall -Wredundant-decls 
-Wnested-externs -Wstrict-prototypes  -Wmissing-prototypes -Wpointer-arith 
-Winline -Wcast-qual  -Wundef -Wno-pointer-sign -fformat-extensions  
-Wmissing-include-dirs -nostdinc  -I. -I/src/sys -I/src/sys/contrib/altq 
-D_KERNEL -DHAVE_KERNEL_OPTION_HEADERS -include opt_global.h -fno-common 
-finline-limit=8000 --param inline-unit-growth=100 --param 
large-function-growth=1000 -DGPROF -falign-functions=16 -DGPROF4 -DGUPROF 
-fno

[head tinderbox] failure on ia64/ia64

[FreeBSD Tinderbox]

TB --- 2011-05-17 14:43:45 - tinderbox 2.7 running on freebsd-current.sentex.ca
TB --- 2011-05-17 14:43:45 - starting HEAD tinderbox run for ia64/ia64
TB --- 2011-05-17 14:43:45 - cleaning the object tree
TB --- 2011-05-17 14:43:56 - cvsupping the source tree
TB --- 2011-05-17 14:43:56 - /usr/bin/csup -z -r 3 -g -L 1 -h cvsup.sentex.ca 
/tinderbox/HEAD/ia64/ia64/supfile
TB --- 2011-05-17 14:44:08 - building world
TB --- 2011-05-17 14:44:08 - MAKEOBJDIRPREFIX=/obj
TB --- 2011-05-17 14:44:08 - PATH=/usr/bin:/usr/sbin:/bin:/sbin
TB --- 2011-05-17 14:44:08 - TARGET=ia64
TB --- 2011-05-17 14:44:08 - TARGET_ARCH=ia64
TB --- 2011-05-17 14:44:08 - TZ=UTC
TB --- 2011-05-17 14:44:08 - __MAKE_CONF=/dev/null
TB --- 2011-05-17 14:44:08 - cd /src
TB --- 2011-05-17 14:44:08 - /usr/bin/make -B buildworld
>>> World build started on Tue May 17 14:44:09 UTC 2011
>>> Rebuilding the temporary build tree
>>> stage 1.1: legacy release compatibility shims
>>> stage 1.2: bootstrap tools
>>> stage 2.1: cleaning up the object tree
>>> stage 2.2: rebuilding the object tree
>>> stage 2.3: build tools
>>> stage 3: cross tools
>>> stage 4.1: building includes
>>> stage 4.2: building libraries
>>> stage 4.3: make dependencies
>>> stage 4.4: building everything
>>> World build completed on Tue May 17 16:09:24 UTC 2011
TB --- 2011-05-17 16:09:24 - generating LINT kernel config
TB --- 2011-05-17 16:09:24 - cd /src/sys/ia64/conf
TB --- 2011-05-17 16:09:24 - /usr/bin/make -B LINT
TB --- 2011-05-17 16:09:24 - building LINT kernel
TB --- 2011-05-17 16:09:24 - MAKEOBJDIRPREFIX=/obj
TB --- 2011-05-17 16:09:24 - PATH=/usr/bin:/usr/sbin:/bin:/sbin
TB --- 2011-05-17 16:09:24 - TARGET=ia64
TB --- 2011-05-17 16:09:24 - TARGET_ARCH=ia64
TB --- 2011-05-17 16:09:24 - TZ=UTC
TB --- 2011-05-17 16:09:24 - __MAKE_CONF=/dev/null
TB --- 2011-05-17 16:09:24 - cd /src
TB --- 2011-05-17 16:09:24 - /usr/bin/make -B buildkernel KERNCONF=LINT
>>> Kernel build for LINT started on Tue May 17 16:09:24 UTC 2011
>>> stage 1: configuring the kernel
>>> stage 2.1: cleaning up the object tree
>>> stage 2.2: rebuilding the object tree
>>> stage 2.3: build tools
>>> stage 3.1: making dependencies
>>> stage 3.2: building everything
[...]
cc -c -O2 -pipe -fno-strict-aliasing  -std=c99  -Wall -Wredundant-decls 
-Wnested-externs -Wstrict-prototypes  -Wmissing-prototypes -Wpointer-arith 
-Winline -Wcast-qual  -Wundef -Wno-pointer-sign -fformat-extensions  
-Wmissing-include-dirs -nostdinc  -I. -I/src/sys -I/src/sys/contrib/altq 
-I/src/sys/contrib/ia64/libuwx/src -D_KERNEL -DHAVE_KERNEL_OPTION_HEADERS 
-include opt_global.h -fno-common -finline-limit=15000 --param 
inline-unit-growth=100 --param large-function-growth=1000 -fno-builtin 
-mconstant-gp -ffixed-r13 -mfixed-range=f32-f127 -fpic -ffreestanding -Werror  
/src/sys/dev/ath/ath_hal/ar5212/ar5212_gpio.c -I/src/sys/dev/ath 
-I/src/sys/dev/ath/ath_hal
cc -c -O2 -pipe -fno-strict-aliasing  -std=c99  -Wall -Wredundant-decls 
-Wnested-externs -Wstrict-prototypes  -Wmissing-prototypes -Wpointer-arith 
-Winline -Wcast-qual  -Wundef -Wno-pointer-sign -fformat-extensions  
-Wmissing-include-dirs -nostdinc  -I. -I/src/sys -I/src/sys/contrib/altq 
-I/src/sys/contrib/ia64/libuwx/src -D_KERNEL -DHAVE_KERNEL_OPTION_HEADERS 
-include opt_global.h -fno-common -finline-limit=15000 --param 
inline-unit-growth=100 --param large-function-growth=1000 -fno-builtin 
-mconstant-gp -ffixed-r13 -mfixed-range=f32-f127 -fpic -ffreestanding -Werror  
/src/sys/dev/ath/ath_hal/ar5212/ar5212_interrupts.c -I/src/sys/dev/ath 
-I/src/sys/dev/ath/ath_hal
cc -c -O2 -pipe -fno-strict-aliasing  -std=c99  -Wall -Wredundant-decls 
-Wnested-externs -Wstrict-prototypes  -Wmissing-prototypes -Wpointer-arith 
-Winline -Wcast-qual  -Wundef -Wno-pointer-sign -fformat-extensions  
-Wmissing-include-dirs -nostdinc  -I. -I/src/sys -I/src/sys/contrib/altq 
-I/src/sys/contrib/ia64/libuwx/src -D_KERNEL -DHAVE_KERNEL_OPTION_HEADERS 
-include opt_global.h -fno-common -finline-limit=15000 --param 
inline-unit-growth=100 --param large-function-growth=1000 -fno-builtin 
-mconstant-gp -ffixed-r13 -mfixed-range=f32-f127 -fpic -ffreestanding -Werror  
/src/sys/dev/ath/ath_hal/ar5212/ar5212_keycache.c -I/src/sys/dev/ath 
-I/src/sys/dev/ath/ath_hal
cc -c -O2 -pipe -fno-strict-aliasing  -std=c99  -Wall -Wredundant-decls 
-Wnested-externs -Wstrict-prototypes  -Wmissing-prototypes -Wpointer-arith 
-Winline -Wcast-qual  -Wundef -Wno-pointer-sign -fformat-extensions  
-Wmissing-include-dirs -nostdinc  -I. -I/src/sys -I/src/sys/contrib/altq 
-I/src/sys/contrib/ia64/libuwx/src -D_KERNEL -DHAVE_KERNEL_OPTION_HEADERS 
-include opt_global.h -fno-common -finline-limit=15000 --param 
inline-unit-growth=100 --param large-function-growth=1000 -fno-builtin 
-mconstant-gp -ffixed-r13 -mfixed-range=f32-f127 -fpic -ffreestanding -Werror  
/src/sys/dev/ath/ath_hal/ar5212/ar5212_misc.c -I/src/sys/dev/ath 
-I/src/sys/dev/ath/ath_hal
/src/sys/dev/ath/ath_hal/ar5212/ar5212_misc.c: In function 
'ar5212GetCapab

Re: proposed smp_rendezvous change

[Max Laier]

On 05/17/2011 05:16 AM, John Baldwin wrote:
...

Index: kern/kern_switch.c
===
--- kern/kern_switch.c (revision 221536)
+++ kern/kern_switch.c (working copy)
@@ -192,15 +192,22 @@
critical_exit(void)
{
struct thread *td;
- int flags;
+ int flags, owepreempt;

td = curthread;
KASSERT(td->td_critnest != 0,
("critical_exit: td_critnest == 0"));

if (td->td_critnest == 1) {
+ owepreempt = td->td_owepreempt;
+ td->td_owepreempt = 0;
+ /*
+ * XXX: Should move compiler_memory_barrier() from
+ * rmlock to a header.
+ */


XXX: If we get an interrupt at this point and td_owepreempt was zero, 
the new interrupt will re-set it, because td_critnest is still non-zero.


So we still end up with a thread that is leaking an owepreempt *and* 
lose a preemption.


We really need an atomic_readandclear() which gives us a local copy of 
td_owepreempt *and* clears critnest in the same operation.  Sadly, that 
is rather expensive.  It is possible to implement with a flag for 
owepreempt, but that means that all writes to critnest must then be 
atomic.  Either because we know we have interrupts disabled (i.e. 
setting owepreempt can be a RMW), or with a proper atomic_add/set/...


I'm not sure what the performance impact of this will be.  One would 
hope that atomic_add without a memory barrier isn't much more expensive 
than a compiler generated read-modify-write, tho.  Especially, since 
this cacheline should be local and exclusive to us, anyway.



+ __asm __volatile("":::"memory");
td->td_critnest = 0;
- if (td->td_owepreempt) {
+ if (owepreempt) {
td->td_critnest = 1;
thread_lock(td);
td->td_critnest--;

___
freebsd-current@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-current
To unsubscribe, send any mail to "freebsd-current-unsubscr...@freebsd.org"

[head tinderbox] failure on amd64/amd64

[FreeBSD Tinderbox]

TB --- 2011-05-17 13:50:00 - tinderbox 2.7 running on freebsd-current.sentex.ca
TB --- 2011-05-17 13:50:00 - starting HEAD tinderbox run for amd64/amd64
TB --- 2011-05-17 13:50:00 - cleaning the object tree
TB --- 2011-05-17 13:50:25 - cvsupping the source tree
TB --- 2011-05-17 13:50:25 - /usr/bin/csup -z -r 3 -g -L 1 -h cvsup.sentex.ca 
/tinderbox/HEAD/amd64/amd64/supfile
TB --- 2011-05-17 13:51:03 - building world
TB --- 2011-05-17 13:51:03 - MAKEOBJDIRPREFIX=/obj
TB --- 2011-05-17 13:51:03 - PATH=/usr/bin:/usr/sbin:/bin:/sbin
TB --- 2011-05-17 13:51:03 - TARGET=amd64
TB --- 2011-05-17 13:51:03 - TARGET_ARCH=amd64
TB --- 2011-05-17 13:51:03 - TZ=UTC
TB --- 2011-05-17 13:51:03 - __MAKE_CONF=/dev/null
TB --- 2011-05-17 13:51:03 - cd /src
TB --- 2011-05-17 13:51:03 - /usr/bin/make -B buildworld
>>> World build started on Tue May 17 13:51:03 UTC 2011
>>> Rebuilding the temporary build tree
>>> stage 1.1: legacy release compatibility shims
>>> stage 1.2: bootstrap tools
>>> stage 2.1: cleaning up the object tree
>>> stage 2.2: rebuilding the object tree
>>> stage 2.3: build tools
>>> stage 3: cross tools
>>> stage 4.1: building includes
>>> stage 4.2: building libraries
>>> stage 4.3: make dependencies
>>> stage 4.4: building everything
>>> stage 5.1: building 32 bit shim libraries
>>> World build completed on Tue May 17 16:16:41 UTC 2011
TB --- 2011-05-17 16:16:41 - generating LINT kernel config
TB --- 2011-05-17 16:16:41 - cd /src/sys/amd64/conf
TB --- 2011-05-17 16:16:41 - /usr/bin/make -B LINT
TB --- 2011-05-17 16:16:41 - building LINT kernel
TB --- 2011-05-17 16:16:41 - MAKEOBJDIRPREFIX=/obj
TB --- 2011-05-17 16:16:41 - PATH=/usr/bin:/usr/sbin:/bin:/sbin
TB --- 2011-05-17 16:16:41 - TARGET=amd64
TB --- 2011-05-17 16:16:41 - TARGET_ARCH=amd64
TB --- 2011-05-17 16:16:41 - TZ=UTC
TB --- 2011-05-17 16:16:41 - __MAKE_CONF=/dev/null
TB --- 2011-05-17 16:16:41 - cd /src
TB --- 2011-05-17 16:16:41 - /usr/bin/make -B buildkernel KERNCONF=LINT
>>> Kernel build for LINT started on Tue May 17 16:16:41 UTC 2011
>>> stage 1: configuring the kernel
>>> stage 2.1: cleaning up the object tree
>>> stage 2.2: rebuilding the object tree
>>> stage 2.3: build tools
>>> stage 3.1: making dependencies
>>> stage 3.2: building everything
[...]
cc -c -O2 -frename-registers -pipe -fno-strict-aliasing  -std=c99  -Wall 
-Wredundant-decls -Wnested-externs -Wstrict-prototypes  -Wmissing-prototypes 
-Wpointer-arith -Winline -Wcast-qual  -Wundef -Wno-pointer-sign 
-fformat-extensions  -Wmissing-include-dirs -nostdinc  -I. -I/src/sys 
-I/src/sys/contrib/altq -D_KERNEL -DHAVE_KERNEL_OPTION_HEADERS -include 
opt_global.h -fno-common -finline-limit=8000 --param inline-unit-growth=100 
--param large-function-growth=1000 -DGPROF -falign-functions=16 -DGPROF4 
-DGUPROF -fno-builtin -fno-omit-frame-pointer -mno-sse -mcmodel=kernel 
-mno-red-zone -mno-mmx -msoft-float  -fno-asynchronous-unwind-tables 
-ffreestanding -fstack-protector -Werror -pg -mprofiler-epilogue 
/src/sys/dev/ath/ath_hal/ar5212/ar5212_gpio.c -I/src/sys/dev/ath 
-I/src/sys/dev/ath/ath_hal
cc -c -O2 -frename-registers -pipe -fno-strict-aliasing  -std=c99  -Wall 
-Wredundant-decls -Wnested-externs -Wstrict-prototypes  -Wmissing-prototypes 
-Wpointer-arith -Winline -Wcast-qual  -Wundef -Wno-pointer-sign 
-fformat-extensions  -Wmissing-include-dirs -nostdinc  -I. -I/src/sys 
-I/src/sys/contrib/altq -D_KERNEL -DHAVE_KERNEL_OPTION_HEADERS -include 
opt_global.h -fno-common -finline-limit=8000 --param inline-unit-growth=100 
--param large-function-growth=1000 -DGPROF -falign-functions=16 -DGPROF4 
-DGUPROF -fno-builtin -fno-omit-frame-pointer -mno-sse -mcmodel=kernel 
-mno-red-zone -mno-mmx -msoft-float  -fno-asynchronous-unwind-tables 
-ffreestanding -fstack-protector -Werror -pg -mprofiler-epilogue 
/src/sys/dev/ath/ath_hal/ar5212/ar5212_interrupts.c -I/src/sys/dev/ath 
-I/src/sys/dev/ath/ath_hal
cc -c -O2 -frename-registers -pipe -fno-strict-aliasing  -std=c99  -Wall 
-Wredundant-decls -Wnested-externs -Wstrict-prototypes  -Wmissing-prototypes 
-Wpointer-arith -Winline -Wcast-qual  -Wundef -Wno-pointer-sign 
-fformat-extensions  -Wmissing-include-dirs -nostdinc  -I. -I/src/sys 
-I/src/sys/contrib/altq -D_KERNEL -DHAVE_KERNEL_OPTION_HEADERS -include 
opt_global.h -fno-common -finline-limit=8000 --param inline-unit-growth=100 
--param large-function-growth=1000 -DGPROF -falign-functions=16 -DGPROF4 
-DGUPROF -fno-builtin -fno-omit-frame-pointer -mno-sse -mcmodel=kernel 
-mno-red-zone -mno-mmx -msoft-float  -fno-asynchronous-unwind-tables 
-ffreestanding -fstack-protector -Werror -pg -mprofiler-epilogue 
/src/sys/dev/ath/ath_hal/ar5212/ar5212_keycache.c -I/src/sys/dev/ath 
-I/src/sys/dev/ath/ath_hal
cc -c -O2 -frename-registers -pipe -fno-strict-aliasing  -std=c99  -Wall 
-Wredundant-decls -Wnested-externs -Wstrict-prototypes  -Wmissing-prototypes 
-Wpointer-arith -Winline -Wcast-qual  -Wundef -Wno-pointer-sign 
-fformat-extensions  -Wmissing-include-dirs -nostdinc  -I. -I/src/sys 
-

Re: Boot halts on Thinkpad X220 (Sandy Bridge)

[Daniel Staal]

(Sorry I can't reply to anyone, I just joined the list.  I saw this 
discussion in the archives and thought I should join in.)


I've managed to boot a X220i using -CURRENT as of last night.  I got some 
help on -questions to get it done though.  From a blank machine, you'll 
need either a non-USB boot device with FreeBSD media (untested) or a USB 
keyboard.  If you are using a USB keyboard


set hint.atkbd.0.disabled=1

to install, and use the USB keyboard during installation.  Then on the 
first reboot in the BIOS set 'USB UEFI BIOS' to disabled.  (This means you 
can't boot from a USB device.)


At that point, the machine will boot fine.  I've tried 8.2-RELEASE, the 
last amd64 -CURRENT I could find on the FreeBSD website, and -CURRENT as of 
2011-05-16.


I'm building a couple of ports at the moment, and want to reboot with a 
couple of config changes in the loader to see if I can get the WiFi 
recognized.  As soon as I do that I can post my dmesg someplace.


Daniel T. Staal

---
This email copyright the author.  Unless otherwise noted, you
are expressly allowed to retransmit, quote, or otherwise use
the contents for non-commercial purposes.  This copyright will
expire 5 years after the author's death, or in 30 years,
whichever is longer, unless such a period is in excess of
local copyright law.
---
___
freebsd-current@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-current
To unsubscribe, send any mail to "freebsd-current-unsubscr...@freebsd.org"

Re: proposed smp_rendezvous change

[John Baldwin]

On Tuesday, May 17, 2011 10:34:41 am Andriy Gapon wrote:
> on 17/05/2011 16:58 John Baldwin said the following:
> > No, it doesn't quite work that way.  It wouldn't work on Alpha for example.
> > 
> > All load_acq is a load with a memory barrier to order other loads after it.
> > It is still free to load stale data.  Only a read-modify-write operation
> > would actually block until it could access an up-to-date value.
> 
> Hmm, ok.
> How about atomic_add_acq_int(&smp_rv_waiters[0], 0) ? :-)
> Or an equivalent MI action that doesn't actually change smp_rv_waiters[0] 
> value,
> if there could be any.
> Maybe explicit atomic_cmpset_acq_int(&smp_rv_waiters[0], 0, 0) ?
> 
> You see at what I am getting?

Yeah, either of those would work.  At this point just leaving the
atomic_add_int() as-is would be the smallest diff. :)

-- 
John Baldwin
___
freebsd-current@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-current
To unsubscribe, send any mail to "freebsd-current-unsubscr...@freebsd.org"

Re: proposed smp_rendezvous change

[John Baldwin]

On Tuesday, May 17, 2011 12:20:40 pm Max Laier wrote:
> On 05/17/2011 05:16 AM, John Baldwin wrote:
> ...
> > Index: kern/kern_switch.c
> > ===
> > --- kern/kern_switch.c (revision 221536)
> > +++ kern/kern_switch.c (working copy)
> > @@ -192,15 +192,22 @@
> > critical_exit(void)
> > {
> > struct thread *td;
> > - int flags;
> > + int flags, owepreempt;
> >
> > td = curthread;
> > KASSERT(td->td_critnest != 0,
> > ("critical_exit: td_critnest == 0"));
> >
> > if (td->td_critnest == 1) {
> > + owepreempt = td->td_owepreempt;
> > + td->td_owepreempt = 0;
> > + /*
> > + * XXX: Should move compiler_memory_barrier() from
> > + * rmlock to a header.
> > + */
> 
> XXX: If we get an interrupt at this point and td_owepreempt was zero, 
> the new interrupt will re-set it, because td_critnest is still non-zero.
> 
> So we still end up with a thread that is leaking an owepreempt *and* 
> lose a preemption.

I don't see how this can still leak owepreempt.  The nested interrupt should 
do nothing (except for possibly set owepreempt) until td_critnest is 0.

However, we can certainly lose preemptions.

I wonder if we can abuse the high bit of td_critnest for the owepreempt flag 
so it is all stored in one cookie.  We only set owepreempt while holding 
thread_lock() (so interrupts are disabled), so I think we would be ok and not 
need atomic ops.

Hmm, actually, the top-half code would have to use atomic ops.  Nuts.  Let me 
think some more.

-- 
John Baldwin
___
freebsd-current@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-current
To unsubscribe, send any mail to "freebsd-current-unsubscr...@freebsd.org"

Re: pcib allocation failure

[deeptec...@gmail.com]

On Tue, May 17, 2011 at 3:44 PM, John Baldwin  wrote:
> On Saturday, May 14, 2011 12:27:59 pm deeptec...@gmail.com wrote:
>> pcib1:  at device 1.0 on pci0
>> pcib1: failed to allocate initial prefetch window: 0xd000-0xfaff
>>
>> the console output is cut shortly after those 2 lines (but the machine
>> seems to continue booting, as i have reset'd the machine, after which
>> "/" was found to be improperly dismounted).
>
> So it actually boots fine, but video output breaks during the boot?  Does it
> ever come back or it is permanently broken until reboot?

the video output is permanently broken until reboot (i was able to
gather logs by using delayed rc.d scripts).

> Your BIOS is actually violating the PCI spec by assigning the same resource
> ranges to two devices on the same PCI bus (the hostb device and the AGP bridge
> device).  It's also doing so unnecessarily.

ok, i've tried changing random BIOS settings, and found that changing
"AGP Aperture Size" from 128M to 64M solved the problem with the new
PCI bus driver. (i have a computer with 512MiB of RAM and an AGP video
card with 128MiB of RAM.) weird. any comments on that?
___
freebsd-current@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-current
To unsubscribe, send any mail to "freebsd-current-unsubscr...@freebsd.org"

Re: proposed smp_rendezvous change

[Max Laier]

On 05/17/2011 09:56 AM, John Baldwin wrote:

On Tuesday, May 17, 2011 12:20:40 pm Max Laier wrote:

On 05/17/2011 05:16 AM, John Baldwin wrote:
...

Index: kern/kern_switch.c
===
--- kern/kern_switch.c (revision 221536)
+++ kern/kern_switch.c (working copy)
@@ -192,15 +192,22 @@
critical_exit(void)
{
struct thread *td;
- int flags;
+ int flags, owepreempt;

td = curthread;
KASSERT(td->td_critnest != 0,
("critical_exit: td_critnest == 0"));

if (td->td_critnest == 1) {
+ owepreempt = td->td_owepreempt;
+ td->td_owepreempt = 0;
+ /*
+ * XXX: Should move compiler_memory_barrier() from
+ * rmlock to a header.
+ */


XXX: If we get an interrupt at this point and td_owepreempt was zero,
the new interrupt will re-set it, because td_critnest is still non-zero.

So we still end up with a thread that is leaking an owepreempt *and*
lose a preemption.


I don't see how this can still leak owepreempt.  The nested interrupt should
do nothing (except for possibly set owepreempt) until td_critnest is 0.


Exactly.  The interrupt sets owepreempt and after we return here, we set 
td_critnest to 0 and exit without clearing owepreempt.  Hence we leak 
the owepreempt.



However, we can certainly lose preemptions.

I wonder if we can abuse the high bit of td_critnest for the owepreempt flag
so it is all stored in one cookie.  We only set owepreempt while holding
thread_lock() (so interrupts are disabled), so I think we would be ok and not
need atomic ops.

Hmm, actually, the top-half code would have to use atomic ops.  Nuts.  Let me
think some more.


I think these two really belong into one single variable.  Setting the 
owepreempt flag can be a normal RMW.  Increasing and decreasing critnest 
must be atomic (otherwise we could lose the flag) and dropping the final 
reference would work like this:


  if ((curthread->td_critnest & TD_CRITNEST_MASK) == 1) {
unsigned int owe;
owe = atomic_readandclear(&curthread->td_critnest);
if (owe & TD_OWEPREEMPT_FLAG) {
  /* do the switch */
  }

That should do it ... I can put that into a patch, if we agree that's 
the right thing to do.


Thanks,
  Max






___
freebsd-current@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-current
To unsubscribe, send any mail to "freebsd-current-unsubscr...@freebsd.org"

Re: Boot halts on Thinkpad X220 (Sandy Bridge)

[Daniel Staal]

I'm building a couple of ports at the moment, and want to reboot with a
couple of config changes in the loader to see if I can get the WiFi
recognized.  As soon as I do that I can post my dmesg someplace.


And my promised dmesg:


Note that this is with 'USB UEFI BIOS' _off._

Daniel T. Staal

---
This email copyright the author.  Unless otherwise noted, you
are expressly allowed to retransmit, quote, or otherwise use
the contents for non-commercial purposes.  This copyright will
expire 5 years after the author's death, or in 30 years,
whichever is longer, unless such a period is in excess of
local copyright law.
---
___
freebsd-current@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-current
To unsubscribe, send any mail to "freebsd-current-unsubscr...@freebsd.org"

Re: proposed smp_rendezvous change

[Andriy Gapon]

on 17/05/2011 18:51 John Baldwin said the following:
> On Tuesday, May 17, 2011 10:34:41 am Andriy Gapon wrote:
>> on 17/05/2011 16:58 John Baldwin said the following:
>>> No, it doesn't quite work that way.  It wouldn't work on Alpha for example.
>>>
>>> All load_acq is a load with a memory barrier to order other loads after it.
>>> It is still free to load stale data.  Only a read-modify-write operation
>>> would actually block until it could access an up-to-date value.
>>
>> Hmm, ok.
>> How about atomic_add_acq_int(&smp_rv_waiters[0], 0) ? :-)
>> Or an equivalent MI action that doesn't actually change smp_rv_waiters[0] 
>> value,
>> if there could be any.
>> Maybe explicit atomic_cmpset_acq_int(&smp_rv_waiters[0], 0, 0) ?
>>
>> You see at what I am getting?
> 
> Yeah, either of those would work.  At this point just leaving the
> atomic_add_int() as-is would be the smallest diff. :)

Yes, I agree about the smallest diff.
But if we are going to remove that first spin-loop, then we would effectively be
wasting one volatile variable.  Only a tiny waste, but it could be confusing.

Whatever we decide, this was very educational for me.
-- 
Andriy Gapon
___
freebsd-current@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-current
To unsubscribe, send any mail to "freebsd-current-unsubscr...@freebsd.org"

Randomization in hastd(8) synchronization thread

[Maxim Sobolev]

Hi Pawel,

I am trying to use hastd(8) over slow links and one problem is apparent 
right now - current approach with synchronizing content sequentially is 
not working in this case. What happens is that hastd hits the first 
frequently updated block and cannot make any progress anymore. In my 
case I have 30GB of dirty space to be synchronized over just 1mbps uplink.


The quick fix that I've applied is randomization in the block selection 
code. This way  eventually all least used blocks will be synchronized, 
leaving only hot ones dirty. More effective approach would be to use 
some kind of LRU selection algorithm, but statistical approach would 
work just as good in this case.


Please review the patch below:

http://sobomax.sippysoft.com/activemap.c.diff

The next thing to make it usable is to make "async" mode working. I 
think simple support for that mode can be easily implemented by not 
sending write request to the remote note at all, but instead just doing 
it locally and kicking the synchronization thread to do it's magic in 
the background. I hope to follow up with the patch soon.


-Maxim
___
freebsd-current@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-current
To unsubscribe, send any mail to "freebsd-current-unsubscr...@freebsd.org"

Re: proposed smp_rendezvous change

[John Baldwin]

On Tuesday, May 17, 2011 3:16:45 pm Max Laier wrote:
> On 05/17/2011 09:56 AM, John Baldwin wrote:
> > On Tuesday, May 17, 2011 12:20:40 pm Max Laier wrote:
> >> On 05/17/2011 05:16 AM, John Baldwin wrote:
> >> ...
> >>> Index: kern/kern_switch.c
> >>> ===
> >>> --- kern/kern_switch.c (revision 221536)
> >>> +++ kern/kern_switch.c (working copy)
> >>> @@ -192,15 +192,22 @@
> >>> critical_exit(void)
> >>> {
> >>> struct thread *td;
> >>> - int flags;
> >>> + int flags, owepreempt;
> >>>
> >>> td = curthread;
> >>> KASSERT(td->td_critnest != 0,
> >>> ("critical_exit: td_critnest == 0"));
> >>>
> >>> if (td->td_critnest == 1) {
> >>> + owepreempt = td->td_owepreempt;
> >>> + td->td_owepreempt = 0;
> >>> + /*
> >>> + * XXX: Should move compiler_memory_barrier() from
> >>> + * rmlock to a header.
> >>> + */
> >>
> >> XXX: If we get an interrupt at this point and td_owepreempt was zero,
> >> the new interrupt will re-set it, because td_critnest is still non-zero.
> >>
> >> So we still end up with a thread that is leaking an owepreempt *and*
> >> lose a preemption.
> >
> > I don't see how this can still leak owepreempt.  The nested interrupt 
should
> > do nothing (except for possibly set owepreempt) until td_critnest is 0.
> 
> Exactly.  The interrupt sets owepreempt and after we return here, we set 
> td_critnest to 0 and exit without clearing owepreempt.  Hence we leak 
> the owepreempt.
> 
> > However, we can certainly lose preemptions.
> >
> > I wonder if we can abuse the high bit of td_critnest for the owepreempt 
flag
> > so it is all stored in one cookie.  We only set owepreempt while holding
> > thread_lock() (so interrupts are disabled), so I think we would be ok and 
not
> > need atomic ops.
> >
> > Hmm, actually, the top-half code would have to use atomic ops.  Nuts.  Let 
me
> > think some more.
> 
> I think these two really belong into one single variable.  Setting the 
> owepreempt flag can be a normal RMW.  Increasing and decreasing critnest 
> must be atomic (otherwise we could lose the flag) and dropping the final 
> reference would work like this:
> 
>if ((curthread->td_critnest & TD_CRITNEST_MASK) == 1) {
>  unsigned int owe;
>  owe = atomic_readandclear(&curthread->td_critnest);
>  if (owe & TD_OWEPREEMPT_FLAG) {
>/* do the switch */
>}
> 
> That should do it ... I can put that into a patch, if we agree that's 
> the right thing to do.

Yeah, I already have a patch to do that, but hadn't added atomic ops to 
critical_enter() and critical_exit().  But it also wasn't as fancy in the 
critical_exit() case.  Here is what I have and I think it might actually
be ok (it doesn't use an atomic read and clear, but I think it is safe).
Hmm, actually, it will need to use the read and clear:

Index: kern/sched_ule.c
===
--- kern/sched_ule.c(revision 222024)
+++ kern/sched_ule.c(working copy)
@@ -1785,7 +1785,6 @@
td->td_oncpu = NOCPU;
if (!(flags & SW_PREEMPT))
td->td_flags &= ~TDF_NEEDRESCHED;
-   td->td_owepreempt = 0;
tdq->tdq_switchcnt++;
/*
 * The lock pointer in an idle thread should never change.  Reset it
@@ -2066,7 +2065,7 @@
 
flags = SW_INVOL | SW_PREEMPT;
if (td->td_critnest > 1)
-   td->td_owepreempt = 1;
+   td->td_critnest |= TD_OWEPREEMPT;
else if (TD_IS_IDLETHREAD(td))
mi_switch(flags | SWT_REMOTEWAKEIDLE, NULL);
else
@@ -2261,7 +2260,7 @@
return;
if (!sched_shouldpreempt(pri, cpri, 0))
return;
-   ctd->td_owepreempt = 1;
+   ctd->td_critnest |= TD_OWEPREEMPT;
 }
 
 /*
Index: kern/kern_switch.c
===
--- kern/kern_switch.c  (revision 222024)
+++ kern/kern_switch.c  (working copy)
@@ -183,7 +183,7 @@
struct thread *td;
 
td = curthread;
-   td->td_critnest++;
+   atomic_add_int(&td->td_critnest, 1);
CTR4(KTR_CRITICAL, "critical_enter by thread %p (%ld, %s) to %d", td,
(long)td->td_proc->p_pid, td->td_name, td->td_critnest);
 }
@@ -192,18 +192,16 @@
 critical_exit(void)
 {
struct thread *td;
-   int flags;
+   int flags, owepreempt;
 
td = curthread;
KASSERT(td->td_critnest != 0,
("critical_exit: td_critnest == 0"));
 
-   if (td->td_critnest == 1) {
-   td->td_critnest = 0;
-   if (td->td_owepreempt) {
-   td->td_critnest = 1;
+   if (td->td_critnest && ~TD_OWEPREEMPT == 1) {
+   owepreempt = atomic_readandclear_int(&td->td_owepreempt);
+   if (owepreempt & TD_OWEPREEMPT) {
thread_lock(td);
-   td->td_critnest--;
   

[head tinderbox] failure on ia64/ia64

[FreeBSD Tinderbox]

TB --- 2011-05-17 20:17:07 - tinderbox 2.7 running on freebsd-current.sentex.ca
TB --- 2011-05-17 20:17:07 - starting HEAD tinderbox run for ia64/ia64
TB --- 2011-05-17 20:17:07 - cleaning the object tree
TB --- 2011-05-17 20:17:15 - cvsupping the source tree
TB --- 2011-05-17 20:17:15 - /usr/bin/csup -z -r 3 -g -L 1 -h cvsup.sentex.ca 
/tinderbox/HEAD/ia64/ia64/supfile
TB --- 2011-05-17 20:17:31 - building world
TB --- 2011-05-17 20:17:31 - MAKEOBJDIRPREFIX=/obj
TB --- 2011-05-17 20:17:31 - PATH=/usr/bin:/usr/sbin:/bin:/sbin
TB --- 2011-05-17 20:17:31 - TARGET=ia64
TB --- 2011-05-17 20:17:31 - TARGET_ARCH=ia64
TB --- 2011-05-17 20:17:31 - TZ=UTC
TB --- 2011-05-17 20:17:31 - __MAKE_CONF=/dev/null
TB --- 2011-05-17 20:17:31 - cd /src
TB --- 2011-05-17 20:17:31 - /usr/bin/make -B buildworld
>>> World build started on Tue May 17 20:17:32 UTC 2011
>>> Rebuilding the temporary build tree
>>> stage 1.1: legacy release compatibility shims
>>> stage 1.2: bootstrap tools
>>> stage 2.1: cleaning up the object tree
>>> stage 2.2: rebuilding the object tree
>>> stage 2.3: build tools
>>> stage 3: cross tools
>>> stage 4.1: building includes
>>> stage 4.2: building libraries
[...]
cc -O2 -pipe  -std=gnu99 -Wsystem-headers -Werror -Wall -Wno-format-y2k -W 
-Wno-unused-parameter -Wstrict-prototypes -Wmissing-prototypes -Wpointer-arith 
-Wreturn-type -Wcast-qual -Wwrite-strings -Wswitch -Wshadow -Wunused-parameter 
-Wcast-align -Wchar-subscripts -Winline -Wnested-externs -Wredundant-decls 
-Wold-style-definition -Wno-pointer-sign -c 
/src/lib/libsbuf/../../sys/kern/subr_sbuf.c
building static sbuf library
ranlib libsbuf.a
cat /src/lib/libsbuf/Symbol.map | cpp - -  | awk -v 
vfile=/src/lib/libsbuf/Version.def -f /src/share/mk/version_gen.awk > 
Version.map
File /src/lib/libsbuf/Version.def: Unknown directive: `/*'.
File /src/lib/libsbuf/Version.def: Unknown directive: `* $FreeBSD: 
src/lib/libsbuf/Version.def,v 1.1 2011/05/17 17:37:58 phk Exp $'.
File /src/lib/libsbuf/Version.def: Unknown directive: `*/'.
3 error(s) total.
*** Error code 1

Stop in /src/lib/libsbuf.
*** Error code 1

Stop in /src.
*** Error code 1

Stop in /src.
*** Error code 1

Stop in /src.
*** Error code 1

Stop in /src.
TB --- 2011-05-17 20:39:58 - WARNING: /usr/bin/make returned exit code  1 
TB --- 2011-05-17 20:39:58 - ERROR: failed to build world
TB --- 2011-05-17 20:39:59 - 1046.34 user 236.60 system 1371.80 real


http://tinderbox.freebsd.org/tinderbox-head-HEAD-ia64-ia64.full
___
freebsd-current@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-current
To unsubscribe, send any mail to "freebsd-current-unsubscr...@freebsd.org"

Making hastd working over WAN links (was: Randomization in hastd(8) synchronization thread)

[Maxim Sobolev]

On 5/17/2011 1:28 PM, Maxim Sobolev wrote:

The next thing to make it usable is to make "async" mode working. I
think simple support for that mode can be easily implemented by not
sending write request to the remote note at all, but instead just doing
it locally and kicking the synchronization thread to do it's magic in
the background. I hope to follow up with the patch soon.


Here is a proof of concept path, which simply fails any 
non-synchronization requests in the send thread when in the async mode. 
This is non-optimal, as it would cause additional latency in the write 
path when the send thread is busy with synchronization requests. But it 
works for me, making it possible to use my virtual machine while 
synchronizing the disk image.


http://sobomax.sippysoft.com/primary.c.diff

-Maxim
___
freebsd-current@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-current
To unsubscribe, send any mail to "freebsd-current-unsubscr...@freebsd.org"

[head tinderbox] failure on mips/mips

[FreeBSD Tinderbox]

TB --- 2011-05-17 20:39:59 - tinderbox 2.7 running on freebsd-current.sentex.ca
TB --- 2011-05-17 20:39:59 - starting HEAD tinderbox run for mips/mips
TB --- 2011-05-17 20:39:59 - cleaning the object tree
TB --- 2011-05-17 20:40:06 - cvsupping the source tree
TB --- 2011-05-17 20:40:06 - /usr/bin/csup -z -r 3 -g -L 1 -h cvsup.sentex.ca 
/tinderbox/HEAD/mips/mips/supfile
TB --- 2011-05-17 20:40:19 - building world
TB --- 2011-05-17 20:40:19 - MAKEOBJDIRPREFIX=/obj
TB --- 2011-05-17 20:40:19 - PATH=/usr/bin:/usr/sbin:/bin:/sbin
TB --- 2011-05-17 20:40:19 - TARGET=mips
TB --- 2011-05-17 20:40:19 - TARGET_ARCH=mips
TB --- 2011-05-17 20:40:19 - TZ=UTC
TB --- 2011-05-17 20:40:19 - __MAKE_CONF=/dev/null
TB --- 2011-05-17 20:40:19 - cd /src
TB --- 2011-05-17 20:40:19 - /usr/bin/make -B buildworld
>>> World build started on Tue May 17 20:40:19 UTC 2011
>>> Rebuilding the temporary build tree
>>> stage 1.1: legacy release compatibility shims
>>> stage 1.2: bootstrap tools
>>> stage 2.1: cleaning up the object tree
>>> stage 2.2: rebuilding the object tree
>>> stage 2.3: build tools
>>> stage 3: cross tools
>>> stage 4.1: building includes
>>> stage 4.2: building libraries
[...]
cc -O -pipe -G0  -std=gnu99 -Wsystem-headers -Werror -Wall -Wno-format-y2k -W 
-Wno-unused-parameter -Wstrict-prototypes -Wmissing-prototypes -Wpointer-arith 
-Wreturn-type -Wcast-qual -Wwrite-strings -Wswitch -Wshadow -Wunused-parameter 
-Wcast-align -Wchar-subscripts -Winline -Wnested-externs -Wredundant-decls 
-Wold-style-definition -Wno-pointer-sign -c 
/src/lib/libsbuf/../../sys/kern/subr_sbuf.c
building static sbuf library
ranlib libsbuf.a
cat /src/lib/libsbuf/Symbol.map | cpp - -  | awk -v 
vfile=/src/lib/libsbuf/Version.def -f /src/share/mk/version_gen.awk > 
Version.map
File /src/lib/libsbuf/Version.def: Unknown directive: `/*'.
File /src/lib/libsbuf/Version.def: Unknown directive: `* $FreeBSD: 
src/lib/libsbuf/Version.def,v 1.1 2011/05/17 17:37:58 phk Exp $'.
File /src/lib/libsbuf/Version.def: Unknown directive: `*/'.
3 error(s) total.
*** Error code 1

Stop in /src/lib/libsbuf.
*** Error code 1

Stop in /src.
*** Error code 1

Stop in /src.
*** Error code 1

Stop in /src.
*** Error code 1

Stop in /src.
TB --- 2011-05-17 20:59:52 - WARNING: /usr/bin/make returned exit code  1 
TB --- 2011-05-17 20:59:52 - ERROR: failed to build world
TB --- 2011-05-17 20:59:52 - 840.77 user 218.09 system 1192.66 real


http://tinderbox.freebsd.org/tinderbox-head-HEAD-mips-mips.full
___
freebsd-current@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-current
To unsubscribe, send any mail to "freebsd-current-unsubscr...@freebsd.org"

Randomization in hastd(8) synchronization thread

[Maxim Sobolev]

Hi Pawel,

I am trying to use hastd(8) over slow links and one problem is apparent 
right now - current approach with synchronizing content sequentially is 
not working in this case. What happens is that hastd hits the first 
frequently updated block and cannot make any progress anymore. In my 
case I have 30GB of dirty space to be synchronized over just 1mbps uplink.


The quick fix that I've applied is randomization in the block selection 
code. This way  eventually all least used blocks will be synchronized, 
leaving only hot ones dirty. More effective approach would be to use 
some kind of LRU selection algorithm, but statistical approach would 
work just as good in this case.


Please review the patch below:

http://sobomax.sippysoft.com/activemap.c.diff

The next thing to make it usable is to make "async" mode working. I 
think simple support for that mode can be easily implemented by not 
sending write request to the remote note at all, but instead just doing 
it locally and kicking the synchronization thread to do it's magic in 
the background. I hope to follow up with the patch soon.


Regards,
--
Maksym Sobolyev
Sippy Software, Inc.
Internet Telephony (VoIP) Experts
Tel: +1-646-651-1110
Fax: +1-866-857-6942
Web: http://www.sippysoft.com
MSN: sa...@sippysoft.com
Skype: SippySoft
___
freebsd-current@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-current
To unsubscribe, send any mail to "freebsd-current-unsubscr...@freebsd.org"

Re: Boot halts on Thinkpad X220 (Sandy Bridge)

[Johannes Dieterich]

On 05/17/2011 06:31 PM, Daniel Staal wrote:
> 
> (Sorry I can't reply to anyone, I just joined the list.  I saw this
> discussion in the archives and thought I should join in.)
> 
> I've managed to boot a X220i using -CURRENT as of last night.  I got
> some help on -questions to get it done though.  From a blank machine,
> you'll need either a non-USB boot device with FreeBSD media (untested)
> or a USB keyboard.  If you are using a USB keyboard
> 
> set hint.atkbd.0.disabled=1
> 
> to install, and use the USB keyboard during installation.  Then on the
> first reboot in the BIOS set 'USB UEFI BIOS' to disabled.  (This means
> you can't boot from a USB device.)
> 
> At that point, the machine will boot fine.  I've tried 8.2-RELEASE, the
> last amd64 -CURRENT I could find on the FreeBSD website, and -CURRENT as
> of 2011-05-16.
> 
> I'm building a couple of ports at the moment, and want to reboot with a
> couple of config changes in the loader to see if I can get the WiFi
> recognized.  As soon as I do that I can post my dmesg someplace.
Thanks a lot for the very valuable hint! :-) Booting the amd64
installation medium works now, I will report after the install whether
the second part also works for me (but I am pretty sure of it).

Thanks a lot again! :-)

Johannes Dieterich
___
freebsd-current@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-current
To unsubscribe, send any mail to "freebsd-current-unsubscr...@freebsd.org"

Re: Boot halts on Thinkpad X220 (Sandy Bridge)

[Matt]

On 05/17/11 16:50, Johannes Dieterich wrote:

On 05/17/2011 06:31 PM, Daniel Staal wrote:

(Sorry I can't reply to anyone, I just joined the list.  I saw this
discussion in the archives and thought I should join in.)

I've managed to boot a X220i using -CURRENT as of last night.  I got
some help on -questions to get it done though.  From a blank machine,
you'll need either a non-USB boot device with FreeBSD media (untested)
or a USB keyboard.  If you are using a USB keyboard

set hint.atkbd.0.disabled=1

to install, and use the USB keyboard during installation.  Then on the
first reboot in the BIOS set 'USB UEFI BIOS' to disabled.  (This means
you can't boot from a USB device.)

At that point, the machine will boot fine.  I've tried 8.2-RELEASE, the
last amd64 -CURRENT I could find on the FreeBSD website, and -CURRENT as
of 2011-05-16.

I'm building a couple of ports at the moment, and want to reboot with a
couple of config changes in the loader to see if I can get the WiFi
recognized.  As soon as I do that I can post my dmesg someplace.

Thanks a lot for the very valuable hint! :-) Booting the amd64
installation medium works now, I will report after the install whether
the second part also works for me (but I am pretty sure of it).

Thanks a lot again! :-)

Johannes Dieterich
___
freebsd-current@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-current
To unsubscribe, send any mail to "freebsd-current-unsubscr...@freebsd.org"

I'm not on a sandy bridge, but a core2 based lenovo thinkpad (SL410, I 
seem to have this thing fully supported finally...f-keys, sd card etc!). 
I've noticed that BTX halts about 60% of the time for me via DVD. My 
keyboard also does not work at login prompt or elsewhere (during 
fsck...faster!) until after about 2-3 keypresses, after which it's fine. 
BTX via CD/DVD actually seems to work better if i start impatiently 
hitting the keyboard when "-" appears.


I'm not sure if this is a related issue. I also had amd64 btx problems 
on a Dell desktop, so it might be a SATA/scsi/cam timeout thing. Never 
had a problem on server hardware, although most of those boxes were 
Opterons (and thus associated chipsets).


I've come to view FreeBSD dvd boots as a form of gambling.

Matt
___
freebsd-current@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-current
To unsubscribe, send any mail to "freebsd-current-unsubscr...@freebsd.org"