On 19-Jan-01 Bruce Evans wrote:
> On Fri, 19 Jan 2001, John Baldwin wrote:
>
>> rummage together a vinum stripe to build on or some such. However, after
>> thinking some more, even in a preemptive kernel, Giant will protect against
>> the
>> *strategy() race you brought up, because we won't get
On Fri, 19 Jan 2001, John Baldwin wrote:
> rummage together a vinum stripe to build on or some such. However, after
> thinking some more, even in a preemptive kernel, Giant will protect against the
> *strategy() race you brought up, because we won't get a context switch in
> kernel mode that rel
It seems John Baldwin wrote:
>
> Can you post a dmesg of your box?
Sure, attached the dmesg from the system that is worst affected:
Copyright (c) 1992-2001 The FreeBSD Project.
Copyright (c) 1979, 1980, 1983, 1986, 1988, 1989, 1991, 1992, 1993, 1994
The Regents of the University of Cal
It seems Poul-Henning Kamp wrote:
> In message <[EMAIL PROTECTED]>, John Baldwin writes:
> >
> >This is _not_ true. My quad xeon test box runs a pure source tree, and has not
> >had a single problem building many worlds and releases since the fix to
> >atomic_store_rel_ptr().
>
> How many disks
In message <[EMAIL PROTECTED]>, John Baldwin writes:
>>
>> How many disks are active when you build world on that box ?
>
>Just one. [...]
>Details like this would be helpful though.
They have never been secret, and I voiced this issue early on.
> However, after
>thinking some more, even in a pr
On 19-Jan-01 Poul-Henning Kamp wrote:
> In message <[EMAIL PROTECTED]>, John Baldwin writes:
>>
>>This is _not_ true. My quad xeon test box runs a pure source tree, and has
>>not
>>had a single problem building many worlds and releases since the fix to
>>atomic_store_rel_ptr().
>
> How many di
In message <[EMAIL PROTECTED]>, John Baldwin writes:
>
>This is _not_ true. My quad xeon test box runs a pure source tree, and has not
>had a single problem building many worlds and releases since the fix to
>atomic_store_rel_ptr().
How many disks are active when you build world on that box ?
On 19-Jan-01 Soren Schmidt wrote:
> It seems Peter Wemm wrote:
>> Soren Schmidt wrote:
>> > It seems Peter Wemm wrote:
>> > >
>> > > Soren, can you retest a buildworld with the currently committed kernel
>> > > with no other changes? Let us see if the forward_signal() stuff is the
>> > > culpri
Soren Schmidt wrote:
> It seems Peter Wemm wrote:
> > This is bad news.. This means we have races somewhere, or some other badne
ss.
>
> That is what I've been harping about for months...
>
> What strikes me here as a very serious problem is that the SMPng developers
> has told me over and
It seems Peter Wemm wrote:
> Soren Schmidt wrote:
> > It seems Peter Wemm wrote:
> > >
> > > Soren, can you retest a buildworld with the currently committed kernel
> > > with no other changes? Let us see if the forward_signal() stuff is the
> > > culprit, and if not, try adding just the i386/i38
Soren Schmidt wrote:
> It seems Peter Wemm wrote:
> >
> > Soren, can you retest a buildworld with the currently committed kernel
> > with no other changes? Let us see if the forward_signal() stuff is the
> > culprit, and if not, try adding just the i386/i386/machdep.c patch to HLT
> > the idle C
On 18-Jan-01 Julian Elischer wrote:
> Soren Schmidt wrote:
>>
>> It seems Peter Wemm wrote:
>> >
>> > Soren, can you retest a buildworld with the currently committed kernel
>> > with no other changes? Let us see if the forward_signal() stuff is the
>> > culprit, and if not, try adding just the
Soren Schmidt wrote:
>
> It seems Peter Wemm wrote:
> >
> > Soren, can you retest a buildworld with the currently committed kernel
> > with no other changes? Let us see if the forward_signal() stuff is the
> > culprit, and if not, try adding just the i386/i386/machdep.c patch to HLT
> > the idle
On 18-Jan-01 Soren Schmidt wrote:
> It seems Peter Wemm wrote:
>> > I'll try adding the forward_signal stuff see if that helps...
>>
>> But John committed that! it should be in the fresh checkout you tried
>> above Of course, that is assuming you cvsup'ed very recently..
>
> Sorry that was
On 18-Jan-01 Soren Schmidt wrote:
> It seems Soren Schmidt wrote:
>> > I actually used this:
>> >
>> > CFLAGS ?= -O -pipe -mcpu=i686 -march=i686
>> > COPTFLAGS ?= -O -pipe -mcpu=i686 -march=i686
>> >
>> > All the diffs in sys/ on the box I built this kernel on are at
>> > http://w
> cool.
> What are the instructions for using this?
> should something have sio1 open?
I use conserver
conserver conserver hostnull-modem serial cables test machine
label
testport AA - sio0 serial console
testnmi port BB
[EMAIL PROTECTED] wrote:
>
> > Again I'll offer to run any and all code or patches to -current you
> > guys can come up with, but I simply dont have the time to sit down
> > and analyze into details what you have been doing...
>
> The enclosed patch implements a virtual NMI pushbutton by program
It seems Peter Wemm wrote:
>
> Soren, can you retest a buildworld with the currently committed kernel
> with no other changes? Let us see if the forward_signal() stuff is the
> culprit, and if not, try adding just the i386/i386/machdep.c patch to HLT
> the idle CPU. (if *that* makes a differenc
It seems Peter Wemm wrote:
> > I'll try adding the forward_signal stuff see if that helps...
>
> But John committed that! it should be in the fresh checkout you tried
> above Of course, that is assuming you cvsup'ed very recently..
Sorry that was not what I meant, I meant this patch to mach
Soren Schmidt wrote:
> It seems Peter Wemm wrote:
> >
> > Hmm. with the mp_machdep.c fix committed, that leaves the only other
> > significant difference being the re-enable of HLT when a cpu goes idle
> > in i386/i386/machdep.c.
>
> That still lockups, tried a freshly checked out sys...
>
> >
It seems Peter Wemm wrote:
>
> Hmm. with the mp_machdep.c fix committed, that leaves the only other
> significant difference being the re-enable of HLT when a cpu goes idle
> in i386/i386/machdep.c.
That still lockups, tried a freshly checked out sys...
> The refcount.[ch] stuff is not relevan
Soren Schmidt wrote:
> It seems Soren Schmidt wrote:
> > > I actually used this:
> > >
> > > CFLAGS ?= -O -pipe -mcpu=i686 -march=i686
> > > COPTFLAGS ?= -O -pipe -mcpu=i686 -march=i686
> > >
> > > All the diffs in sys/ on the box I built this kernel on are at
> > > http://www.Free
It seems Soren Schmidt wrote:
> > I actually used this:
> >
> > CFLAGS ?= -O -pipe -mcpu=i686 -march=i686
> > COPTFLAGS ?= -O -pipe -mcpu=i686 -march=i686
> >
> > All the diffs in sys/ on the box I built this kernel on are at
> > http://www.FreeBSD.org/~jhb/patches/sys-mutex.patch.
[EMAIL PROTECTED] wrote:
>
> The enclosed patch implements a virtual NMI pushbutton by programming
> the IOAPIC to deliver an NMI when sio1 generates an interrupt.
This would be a nice kernel option... :-)
--
Daniel C. Sobral(8-DCS)
[EMAIL PROTECTED]
[EMAIL PROTECTED]
[
It seems John Baldwin wrote:
> >>
> >> So the only thing I can think of is that you guys have something in
> >> your src trees that cvs & I dont...
> >>
> >> Now what ?
> >
> > What are the compile flags you are using?
>
> I actually used this:
>
> CFLAGS ?= -O -pipe -mcpu=i686 -marc
On 18-Jan-01 Alfred Perlstein wrote:
> * Soren Schmidt <[EMAIL PROTECTED]> [010118 00:03] wrote:
>> It seems John Baldwin wrote:
>> > > Anyhow, I have asked before to have you guys supply me with
>> > > a kernel that has been compiled "the right way" and I'll test
>> > > it out here just to make
It seems Alfred Perlstein wrote:
> > Now this is "interesting", I booted on your kernel, and it has run
> > through make world 4 times in a row...
> >
> > So I felt lucky, checked out a new fresh src/sys tree, and made a new
> > kernel from the config file you used, reboot, starts test, and *HANG
* Soren Schmidt <[EMAIL PROTECTED]> [010118 00:03] wrote:
> It seems John Baldwin wrote:
> > > Anyhow, I have asked before to have you guys supply me with
> > > a kernel that has been compiled "the right way" and I'll test
> > > it out here just to make sure I dont do anything stupid..
> > >
> >
It seems John Baldwin wrote:
> > Anyhow, I have asked before to have you guys supply me with
> > a kernel that has been compiled "the right way" and I'll test
> > it out here just to make sure I dont do anything stupid..
> >
> > Just a bare bones kernel, fxp & ata drivers will do nicely for the
>
> Again I'll offer to run any and all code or patches to -current you
> guys can come up with, but I simply dont have the time to sit down
> and analyze into details what you have been doing...
The enclosed patch implements a virtual NMI pushbutton by programming
the IOAPIC to deliver an NMI when
On Wed, 17 Jan 2001, Alfred Perlstein wrote:
> I have a patch here that removes await/asleep from the kernel API.
>
> http://people.freebsd.org/~alfred/noasleep.diff
>
> Matt Dillon implemented alseep/await quite some time ago and the
> only thing that's using it is ata. In order to clean up s
:I did some research on this and am convinced that at least some video cards
:would work as memory buffers for KTR logs. Specifically, someone mentioned
:to me yesterday that their Matrox Millennium II flashes the X desktop
:during startup from a previous invocation across warm boots. (I pursued
* Bosko Milekic <[EMAIL PROTECTED]> [010117 14:35] wrote:
>
> Alfred Perlstein wrote:
>
> > Which means we don't have to drop the lock over the socket unless
> > we'd block on allocation.
>
> No. You'd still have to drop it for now. Remember? (Last commit to
> uipc_mbuf.c). You have to drop
Alfred Perlstein wrote:
> * Alfred Perlstein <[EMAIL PROTECTED]> [010117 09:24] wrote:
> >
> > I'm not going to axe it for a few days, this is a really amazing
> > API that Matt added, the problem is utility and useage over code
> > complexity.
> >
> > It's just a proposal.
>
> I found several p
On 17-Jan-01 Dag-Erling Smorgrav wrote:
> Poul-Henning Kamp <[EMAIL PROTECTED]> writes:
>> It might be nice with a "How to provide useful info on SMPng
>> problems." FAQ somewhere.
>
> I'd also like a "KTR for fun and profit" FAQ...
ktr.9 is next on my todo list of manpages to write. I have se
Poul-Henning Kamp <[EMAIL PROTECTED]> writes:
> It might be nice with a "How to provide useful info on SMPng
> problems." FAQ somewhere.
I'd also like a "KTR for fun and profit" FAQ...
> I have no idea which of all the WITNESS and other options
> do what and when they are useful...
WITNESS, at
On 17-Jan-01 Poul-Henning Kamp wrote:
>
> John,
>
> It might be nice with a "How to provide useful info on SMPng
> problems." FAQ somewhere.
>
> I have no idea which of all the WITNESS and other options
> do what and when they are useful...
Fair enough. One thing on my todo list is a ktr.9 m
It seems John Baldwin wrote:
> > Anyhow, I have asked before to have you guys supply me with
> > a kernel that has been compiled "the right way" and I'll test
> > it out here just to make sure I dont do anything stupid..
> >
> > Just a bare bones kernel, fxp & ata drivers will do nicely for the
>
John,
It might be nice with a "How to provide useful info on SMPng
problems." FAQ somewhere.
I have no idea which of all the WITNESS and other options
do what and when they are useful...
--
Poul-Henning Kamp | UNIX since Zilog Zeus 3.20
[EMAIL PROTECTED] | TCP/IP since RFC 956
Fr
:>:...
:>:
:>:The lock must be unwound becasue we're calling MGETHDR with M_TRYWAIT.
:>:If wae used M_TRY'A'WAIT the code would probably look something like
:>:this:
:>
:> The basic premis of using asleep()/await() is to allow you to
:> propogate a 'blocking condition' back up to a highe
In message <[EMAIL PROTECTED]>, John Baldwin writes:
>
>On 17-Jan-01 Poul-Henning Kamp wrote:
>>
>>>Perhaps you can explain how you're able to trigger this instability
>>>with a test script? Poul-Henning told me he just needed to do a
>>>make -j256 world, I did 10 of them without a problem...
>>
In message <[EMAIL PROTECTED]>, Alfred Perlstein writes:
>> > There has to be a way for you guys to get us some reasonable
>> > tracebacks or diagnostics instead of just saying "it's broke".
>>
>> Its close to impossible, the two symptoms I see here are either
>> spontanous reboots, or solid han
On 17-Jan-01 Soren Schmidt wrote:
> It seems John Baldwin wrote:
>>
>> On 17-Jan-01 Soren Schmidt wrote:
>> > Nothing special, GENERIC kernel with SMP defined will do nicely, running
>> > without SMP improves matters but on the fastet machine I'm still getting
>> > lockups, but they are rare...
In message <[EMAIL PROTECTED]>, Alfred Perlstein writes:
>* Poul-Henning Kamp <[EMAIL PROTECTED]> [010117 10:25] wrote:
>>
>> >Perhaps you can explain how you're able to trigger this instability
>> >with a test script? Poul-Henning told me he just needed to do a
>> >make -j256 world, I did 10 of
It seems Jason Evans wrote:
> On Wed, Jan 17, 2001 at 07:42:26PM +0100, Soren Schmidt wrote:
> > > Basically if you're expecting me or the SMP team to figure out
> > > what's going on without more info, you're pretty much out of luck.
> >
> > See above, not really possible, we have been trying to
On 17-Jan-01 Soren Schmidt wrote:
> It seems John Baldwin wrote:
>>
>> On 17-Jan-01 Soren Schmidt wrote:
>> > Nothing special, GENERIC kernel with SMP defined will do nicely, running
>> > without SMP improves matters but on the fastet machine I'm still getting
>> > lockups, but they are rare...
On 17-Jan-01 Matt Dillon wrote:
>:* Alfred Perlstein <[EMAIL PROTECTED]> [010117 09:24] wrote:
>:>
>:> I'm not going to axe it for a few days, this is a really amazing
>:> API that Matt added, the problem is utility and useage over code
>:> complexity.
>:>
>:> It's just a proposal.
>:
>:I found
On Wed, Jan 17, 2001 at 07:42:26PM +0100, Soren Schmidt wrote:
> > Basically if you're expecting me or the SMP team to figure out
> > what's going on without more info, you're pretty much out of luck.
>
> See above, not really possible, we have been trying to find some
> (affordable) HW that coul
It seems John Baldwin wrote:
>
> On 17-Jan-01 Soren Schmidt wrote:
> > Nothing special, GENERIC kernel with SMP defined will do nicely, running
> > without SMP improves matters but on the fastet machine I'm still getting
> > lockups, but they are rare...
>
> AHA! Useful info!! GENERIC is quite
:* Alfred Perlstein <[EMAIL PROTECTED]> [010117 09:24] wrote:
:>
:> I'm not going to axe it for a few days, this is a really amazing
:> API that Matt added, the problem is utility and useage over code
:> complexity.
:>
:> It's just a proposal.
:
:I found several places where it may be useful, bu
It seems Alfred Perlstein wrote:
> > >
> > > You and Poul-Henning have to figure out what's going on, no one
> > > else is able to reproduce this instability you're talking about.
> >
> > Oohh you dont read the mailing lists then, there has been plenty
> > of reports of hanging -current boxen si
On 17-Jan-01 Poul-Henning Kamp wrote:
>
>>Perhaps you can explain how you're able to trigger this instability
>>with a test script? Poul-Henning told me he just needed to do a
>>make -j256 world, I did 10 of them without a problem...
>
> Then you misunderstood me, I don't have anything in the
On 17-Jan-01 Soren Schmidt wrote:
> Nothing special, GENERIC kernel with SMP defined will do nicely, running
> without SMP improves matters but on the fastet machine I'm still getting
> lockups, but they are rare...
AHA! Useful info!! GENERIC is quite close to bloated, so the fact that it is
G
* Soren Schmidt <[EMAIL PROTECTED]> [010117 10:43] wrote:
> It seems Alfred Perlstein wrote:
> > >
> > > I suggest creative manpower is used to stabilize -current, instead
> > > of fine trimming which API's should stay or not...
> >
> > I started a loop of make -j128 buildworld and buildkernel l
* Poul-Henning Kamp <[EMAIL PROTECTED]> [010117 10:25] wrote:
>
> >Perhaps you can explain how you're able to trigger this instability
> >with a test script? Poul-Henning told me he just needed to do a
> >make -j256 world, I did 10 of them without a problem...
>
> Then you misunderstood me, I d
It seems Alfred Perlstein wrote:
> >
> > I suggest creative manpower is used to stabilize -current, instead
> > of fine trimming which API's should stay or not...
>
> I started a loop of make -j128 buildworld and buildkernel last
> night, I still haven't seen anything odd happen on my hardware.
>Perhaps you can explain how you're able to trigger this instability
>with a test script? Poul-Henning told me he just needed to do a
>make -j256 world, I did 10 of them without a problem...
Then you misunderstood me, I don't have anything in the dept
of SMP hw which can trigger it.
--
Poul-He
* Soren Schmidt <[EMAIL PROTECTED]> [010117 10:02] wrote:
> It seems Alfred Perlstein wrote:
> > > >> Peter Wemm and I suspect that ata doesn't need it. Right now I'm
> > > >> running several make -j128 buildworlds and buildkernels with this
> > > >> patch to catch any ata problems.
> > >
> > >
* Alfred Perlstein <[EMAIL PROTECTED]> [010117 09:24] wrote:
>
> I'm not going to axe it for a few days, this is a really amazing
> API that Matt added, the problem is utility and useage over code
> complexity.
>
> It's just a proposal.
I found several places where it may be useful, but I'm not
It seems Alfred Perlstein wrote:
> > >> Peter Wemm and I suspect that ata doesn't need it. Right now I'm
> > >> running several make -j128 buildworlds and buildkernels with this
> > >> patch to catch any ata problems.
> >
> > U...
> >
> > It seems to me from reading the man
* Randell Jesup <[EMAIL PROTECTED]> [010117 08:14] wrote:
> >It seems Alfred Perlstein wrote:
> >> I have a patch here that removes await/asleep from the kernel API.
> >>
> >> http://people.freebsd.org/~alfred/noasleep.diff
> >>
> >> Matt Dillon implemented alseep/await quite some time ago and t
>It seems Alfred Perlstein wrote:
>> I have a patch here that removes await/asleep from the kernel API.
>>
>> http://people.freebsd.org/~alfred/noasleep.diff
>>
>> Matt Dillon implemented alseep/await quite some time ago and the
>> only thing that's using it is ata. In order to clean up some of
It seems Alfred Perlstein wrote:
> Please trim cc's as appropriate.
>
> I have a patch here that removes await/asleep from the kernel API.
>
> http://people.freebsd.org/~alfred/noasleep.diff
>
> Matt Dillon implemented alseep/await quite some time ago and the
> only thing that's using it is ata
Please trim cc's as appropriate.
I have a patch here that removes await/asleep from the kernel API.
http://people.freebsd.org/~alfred/noasleep.diff
Matt Dillon implemented alseep/await quite some time ago and the
only thing that's using it is ata. In order to clean up some of
the schduler and
64 matches
Mail list logo
