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.
--
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 @@
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:
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.
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 Laierm...@love2party.net:
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
On Saturday, May 14, 2011 12:27:59 pm deeptec...@gmail.com wrote:
pcib1: ACPI PCI-PCI bridge 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
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();
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);
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
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 -
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 -
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 -
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 -
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;
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 -
(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
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
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
On Tue, May 17, 2011 at 3:44 PM, John Baldwin j...@freebsd.org wrote:
On Saturday, May 14, 2011 12:27:59 pm deeptec...@gmail.com wrote:
pcib1: ACPI PCI-PCI bridge at device 1.0 on pci0
pcib1: failed to allocate initial prefetch window: 0xd000-0xfaff
the console output is cut shortly
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)
+++
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:
http://www.magehandbook.com/dmesg.txt
Note that this is with
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
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
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
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 -
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
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 -
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
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.
29 matches
Mail list logo
