--BOKacYhQ+x31HxR3
Content-Type: text/plain; charset=us-ascii
Content-Disposition: inline
On Fri, Feb 08, 2002 at 03:56:21PM -0800, Julian Elischer wrote:
>
> In your case we need totrace proc 1 I think..
>
I got the `reboot' process at this session, so I traced that process.
Before I had use
yes,, this exactly fits the symptoms!
I've committed it.
(it's definitly wrong)
assume this will solv ethe problem.
now why doesn't MINE fail?
On Sat, 9 Feb 2002 [EMAIL PROTECTED] wrote:
> > h so what is the difference between your kernel and mine that works?
> >
> > just out of curiosity
I'm not particularly good at reading the lock-related output, but it
doesn't have other lines than the one that says about the Giant lock, so
it seems there isn't any other locks being held by anyone.
Eugene
On Fri, Feb 08, 2002 at 04:55:42PM -0800, Julian Elischer wrote:
>
>
> I tlooks as if
On 09-Feb-02 Julian Elischer wrote:
> yes,, this exactly fits the symptoms!
>
> I've committed it.
> (it's definitly wrong)
> assume this will solv ethe problem.
> now why doesn't MINE fail?
Probably cause you are running your other tree that makes mi_switch() auto do
the setrunqueue? :)
--
>Date: Fri, 8 Feb 2002 17:34:45 -0800 (PST)
>From: Julian Elischer <[EMAIL PROTECTED]>
>Thats it for sure!
>committing now..
>On Sat, 9 Feb 2002 [EMAIL PROTECTED] wrote:
>> It looks like a call to setrunqueue() was incorrectly dropped in
>> the latest version of kern_shutdown.c.
Applying tha
No, I just never went into that particular clause of code
But is has made me rethink the whole issue.
On Fri, 8 Feb 2002, John Baldwin wrote:
>
> On 09-Feb-02 Julian Elischer wrote:
> > yes,, this exactly fits the symptoms!
> >
> > I've committed it.
> > (it's definitly wrong)
> > assume thi
It's an UP kernel running on an UP box.
Eugene
On Fri, Feb 08, 2002 at 04:53:28PM -0800, Julian Elischer wrote:
>
>
> yes but is it a SMP or UP kernel? (SMP kernel can run on some UP h/w)
>
> thanks!
>
>
> On Fri, 8 Feb 2002, Eugene M. Kim wrote:
>
> > On Fri, Feb 08, 2002 at 03:56:21PM -0
can you try a kernel from JUST BEFORE I did the KSE commit yesterday?
I heard someone else complain of thisyesterday afternoon. At that time I
wascertain it was too soon after my commit for him to already have got it,
but it would be nice tio know if I screwed something...
On Fri, 8 Feb 2002, D
On 09-Feb-02 Eugene M. Kim wrote:
> I'm not particularly good at reading the lock-related output, but it
> doesn't have other lines than the one that says about the Giant lock, so
> it seems there isn't any other locks being held by anyone.
show locks only shows the locks held by a single threa
In your case we need totrace proc 1 I think..
On Fri, 8 Feb 2002, Eugene M. Kim wrote:
> Attached is the requested DDB log (I guessed pid 7 `syncer' is the
> process doing the sync; if this is wrong let me know).
>
> Eugene
>
> PS. I used the serial console, so don't feel sorry to ask. =)
>
>
> Eh; I suspect that's showing the entry to ddb.
>
> Hmmm... gow about:
>
> db> show witness
> Sleep locks:
> 0 Giant -- last acquired @ /usr/src/sys/kern/kern_intr.c:532
> 1 eventhandler -- last acquired @ /usr/src/sys/kern/subr_eventhandler.c:162
> 3lockmgr -- last acquired @ /usr/sr
david,
On Fri, 8 Feb 2002, Julian Elischer wrote:
> cool..
> ok, how about adding "show witness"
[...]
can you do a cvs diff -D{time1] -D[time2] /sys
where time2 is the earliest kernel that has the problem and time1 is the
last kernel that doesn't?
there may be some other diffs in there I'm n
>Date: Fri, 8 Feb 2002 10:54:55 -0800 (PST)
>From: Julian Elischer <[EMAIL PROTECTED]>
>can you try a kernel from JUST BEFORE I did the KSE commit yesterday?
OK; results below
>I heard someone else complain of thisyesterday afternoon. At that time I
>wascertain it was too soon after my comm
cool..
ok, how about adding "show witness"
(we need to figure out which process SHOULD be doing the reboot, but it's
not obvious from this ps, which one we should be looking at.)
if you have it compiled in, show ktr (a couple of pages of it anyhow)
MIGHT show something.
On Fri, 8 Feb 2002, Euge
--2oS5YaxWCcQjTEyO
Content-Type: text/plain; charset=us-ascii
Content-Disposition: inline
Attached is the requested DDB log (I guessed pid 7 `syncer' is the
process doing the sync; if this is wrong let me know).
Eugene
PS. I used the serial console, so don't feel sorry to ask. =)
On Fri, Feb
On Fri, 8 Feb 2002, Eugene M. Kim wrote:
> On Fri, Feb 08, 2002 at 01:43:54PM -0800, Julian Elischer wrote:
> >
> > On Fri, 8 Feb 2002, David Wolfskill wrote:
> > >
> > > Waiting (max 60 seconds) for system process `vnlru' to stop...stopped
> > > Waiting (max 60 seconds) for system process `b
No, I just never went into that particular clause of code
But is has made me rethink the whole issue.
On Fri, 8 Feb 2002, John Baldwin wrote:
>
> On 09-Feb-02 Julian Elischer wrote:
> > yes,, this exactly fits the symptoms!
> >
> > I've committed it.
> > (it's definitly wrong)
> > assume thi
On 09-Feb-02 Eugene M. Kim wrote:
> I'm not particularly good at reading the lock-related output, but it
> doesn't have other lines than the one that says about the Giant lock, so
> it seems there isn't any other locks being held by anyone.
show locks only shows the locks held by a single threa
On 09-Feb-02 Julian Elischer wrote:
> yes,, this exactly fits the symptoms!
>
> I've committed it.
> (it's definitly wrong)
> assume this will solv ethe problem.
> now why doesn't MINE fail?
Probably cause you are running your other tree that makes mi_switch() auto do
the setrunqueue? :)
--
>Date: Fri, 8 Feb 2002 17:34:45 -0800 (PST)
>From: Julian Elischer <[EMAIL PROTECTED]>
>Thats it for sure!
>committing now..
>On Sat, 9 Feb 2002 [EMAIL PROTECTED] wrote:
>> It looks like a call to setrunqueue() was incorrectly dropped in
>> the latest version of kern_shutdown.c.
Applying tha
Julian Elischer wrote:
> h so what is the difference between your kernel and mine that works?
For the love of God, please do not post your kernels
to the list next. Much of the data transfer of the
dumps should probably have been off list already.
Please, please do not post your kernels.
yes,, this exactly fits the symptoms!
I've committed it.
(it's definitly wrong)
assume this will solv ethe problem.
now why doesn't MINE fail?
On Sat, 9 Feb 2002 [EMAIL PROTECTED] wrote:
> > h so what is the difference between your kernel and mine that works?
> >
> > just out of curiosity
Thats it for sure!
committing now..
On Sat, 9 Feb 2002 [EMAIL PROTECTED] wrote:
> > h so what is the difference between your kernel and mine that works?
> >
> > just out of curiosity, have you tried a very latest -current?
> > do you have your own config? how does GENERIC behave?
> > (wh
On Fri, Feb 08, 2002 at 05:09:31PM -0800, Julian Elischer wrote:
>
>
> h so what is the difference between your kernel and mine that works?
/me scratches his head
>
> just out of curiosity, have you tried a very latest -current?
Not the very latest; this source is about a day old.
> d
> h so what is the difference between your kernel and mine that works?
>
> just out of curiosity, have you tried a very latest -current?
> do you have your own config? how does GENERIC behave?
> (what kind of disks do you have?)
It looks like a call to setrunqueue() was incorrectly dropped
h so what is the difference between your kernel and mine that works?
just out of curiosity, have you tried a very latest -current?
do you have your own config? how does GENERIC behave?
(what kind of disks do you have?)
Julian
On Fri, 8 Feb 2002, Eugene M. Kim wrote:
> It's an UP kernel
I'm not particularly good at reading the lock-related output, but it
doesn't have other lines than the one that says about the Giant lock, so
it seems there isn't any other locks being held by anyone.
Eugene
On Fri, Feb 08, 2002 at 04:55:42PM -0800, Julian Elischer wrote:
>
>
> I tlooks as if
It's an UP kernel running on an UP box.
Eugene
On Fri, Feb 08, 2002 at 04:53:28PM -0800, Julian Elischer wrote:
>
>
> yes but is it a SMP or UP kernel? (SMP kernel can run on some UP h/w)
>
> thanks!
>
>
> On Fri, 8 Feb 2002, Eugene M. Kim wrote:
>
> > On Fri, Feb 08, 2002 at 03:56:21PM -0
I tlooks as if "show locks" would not show any locks held by anyone..
is this true?
On Fri, 8 Feb 2002, Eugene M. Kim wrote:
> On Fri, Feb 08, 2002 at 03:56:21PM -0800, Julian Elischer wrote:
> >
> > In your case we need totrace proc 1 I think..
> >
>
> I got the `reboot' process at this ses
yes but is it a SMP or UP kernel? (SMP kernel can run on some UP h/w)
thanks!
On Fri, 8 Feb 2002, Eugene M. Kim wrote:
> On Fri, Feb 08, 2002 at 03:56:21PM -0800, Julian Elischer wrote:
> >
> > In your case we need totrace proc 1 I think..
> >
>
> I got the `reboot' process at this session,
On Fri, Feb 08, 2002 at 03:56:21PM -0800, Julian Elischer wrote:
>
> In your case we need totrace proc 1 I think..
>
I got the `reboot' process at this session, so I traced that process.
Before I had used `shutdown -r', which probably SIGINT'ed the init
process so it's init (pid 1) calling rebo
In your case we need totrace proc 1 I think..
On Fri, 8 Feb 2002, Eugene M. Kim wrote:
> Attached is the requested DDB log (I guessed pid 7 `syncer' is the
> process doing the sync; if this is wrong let me know).
>
> Eugene
>
> PS. I used the serial console, so don't feel sorry to ask. =)
>
>
> Eh; I suspect that's showing the entry to ddb.
>
> Hmmm... gow about:
>
> db> show witness
> Sleep locks:
> 0 Giant -- last acquired @ /usr/src/sys/kern/kern_intr.c:532
> 1 eventhandler -- last acquired @ /usr/src/sys/kern/subr_eventhandler.c:162
> 3lockmgr -- last acquired @ /usr/sr
david,
On Fri, 8 Feb 2002, Julian Elischer wrote:
> cool..
> ok, how about adding "show witness"
[...]
can you do a cvs diff -D{time1] -D[time2] /sys
where time2 is the earliest kernel that has the problem and time1 is the
last kernel that doesn't?
there may be some other diffs in there I'm n
cool..
ok, how about adding "show witness"
(we need to figure out which process SHOULD be doing the reboot, but it's
not obvious from this ps, which one we should be looking at.)
if you have it compiled in, show ktr (a couple of pages of it anyhow)
MIGHT show something.
On Fri, 8 Feb 2002, Euge
Attached is the requested DDB log (I guessed pid 7 `syncer' is the
process doing the sync; if this is wrong let me know).
Eugene
PS. I used the serial console, so don't feel sorry to ask. =)
On Fri, Feb 08, 2002 at 02:41:30PM -0800, Julian Elischer wrote:
>
>
>
>
> On Fri, 8 Feb 2002, Eugen
On Fri, 8 Feb 2002, Eugene M. Kim wrote:
> On Fri, Feb 08, 2002 at 01:43:54PM -0800, Julian Elischer wrote:
> >
> > On Fri, 8 Feb 2002, David Wolfskill wrote:
> > >
> > > Waiting (max 60 seconds) for system process `vnlru' to stop...stopped
> > > Waiting (max 60 seconds) for system process `b
On Fri, Feb 08, 2002 at 01:43:54PM -0800, Julian Elischer wrote:
>
> On Fri, 8 Feb 2002, David Wolfskill wrote:
> >
> > Waiting (max 60 seconds) for system process `vnlru' to stop...stopped
> > Waiting (max 60 seconds) for system process `bufdaemon' to stop...stopped
> > Waiting (max 60 seconds)
On Fri, 8 Feb 2002, David Wolfskill wrote:
>
> FreeBSD/i386 (freebeast.catwhisker.org) (cuaa0)
>
> login: boot() called on cpu#0
> Waiting (max 60 seconds) for system process `vnlru' to stop...stopped
> Waiting (max 60 seconds) for system process `bufdaemon' to
> stop...stopped
> Waiting (max
>Date: Fri, 8 Feb 2002 10:54:55 -0800 (PST)
>From: Julian Elischer <[EMAIL PROTECTED]>
>can you try a kernel from JUST BEFORE I did the KSE commit yesterday?
OK; results below
>I heard someone else complain of thisyesterday afternoon. At that time I
>wascertain it was too soon after my comm
can you try a kernel from JUST BEFORE I did the KSE commit yesterday?
I heard someone else complain of thisyesterday afternoon. At that time I
wascertain it was too soon after my commit for him to already have got it,
but it would be nice tio know if I screwed something...
On Fri, 8 Feb 2002, D
41 matches
Mail list logo
