On Friday 29 June 2001 22:40, Jeff Dike wrote:
> The bug was UML-specific and specific in such a way that I don't think it's
> possible to find the bug in the native kernel by making analogies from the
> UML bug.
Heh, too bad, there goes that chance to show uml bagging a major kernel bug.
But
On Friday 29 June 2001 22:40, Jeff Dike wrote:
The bug was UML-specific and specific in such a way that I don't think it's
possible to find the bug in the native kernel by making analogies from the
UML bug.
Heh, too bad, there goes that chance to show uml bagging a major kernel bug.
But
On Tue, Jun 26, 2001 at 10:47:12AM -0400, Bulent Abali wrote:
> Andrea,
> I would like try your patch but so far I can trigger the bug only when
> running TUX 2.0-B6 which runs on 2.4.5-ac4. /bulent
>
to run tux you can apply those patches in `ls` order to 2.4.6pre5aa1:
>> I am running in to a problem, seemingly a deadlock situation, where
almost
>> all the processes end up in the TASK_UNINTERRUPTIBLE state. All the
>
>could you try to reproduce with this patch applied on top of
>2.4.6pre5aa1 or 2.4.6pre5 vanilla?
Andrea,
I would like try your patch but so
On Tue, 26 Jun 2001, Christian Ehrhardt wrote:
> > I've seen this under UML, Rik van Riel has seen it on a physical box, and we
> > suspect that they're the same problem (i.e. mine isn't a UML-specific bug).
>
> Could it be smbfs?
No. I've seen the hang on pure ex2.
Rik
--
Virtual memory is
On Mon, Jun 25, 2001 at 12:05:14PM -0500, Jeff Dike wrote:
> [EMAIL PROTECTED] said:
> > I am running in to a problem, seemingly a deadlock situation, where
> > almost all the processes end up in the TASK_UNINTERRUPTIBLE state.
> > All the process eventually stop responding, including login
On Mon, Jun 25, 2001 at 12:05:14PM -0500, Jeff Dike wrote:
[EMAIL PROTECTED] said:
I am running in to a problem, seemingly a deadlock situation, where
almost all the processes end up in the TASK_UNINTERRUPTIBLE state.
All the process eventually stop responding, including login shell, no
On Tue, 26 Jun 2001, Christian Ehrhardt wrote:
I've seen this under UML, Rik van Riel has seen it on a physical box, and we
suspect that they're the same problem (i.e. mine isn't a UML-specific bug).
Could it be smbfs?
No. I've seen the hang on pure ex2.
Rik
--
Virtual memory is like a
I am running in to a problem, seemingly a deadlock situation, where
almost
all the processes end up in the TASK_UNINTERRUPTIBLE state. All the
could you try to reproduce with this patch applied on top of
2.4.6pre5aa1 or 2.4.6pre5 vanilla?
Andrea,
I would like try your patch but so far I
On Tue, Jun 26, 2001 at 10:47:12AM -0400, Bulent Abali wrote:
Andrea,
I would like try your patch but so far I can trigger the bug only when
running TUX 2.0-B6 which runs on 2.4.5-ac4. /bulent
to run tux you can apply those patches in `ls` order to 2.4.6pre5aa1:
Hi again
i have a stack now an
#0 schedule () at sched.c:536
#1 0x1002f932 in __wait_on_buffer (bh=0x50eb16e4) at buffer.c:157
#2 0x10036f46 in block_read (filp=0x5009787c, buf=0x80c08f0
"¤\201", count=8192, ppos=0x5009789c) at
Hi
i have been looking at it a lot over the past few days i seem to be the
person who can trigger it easyest.
over the past couple of days i have been running with the
#define WAITQUEUE_DEBUG 1
no problems seem to have appeared there though and the bug still triggers.
On Mon, 25 Jun 2001,
On Mon, 25 Jun 2001, Jeff Dike wrote:
> [EMAIL PROTECTED] said:
> > Can you give more details? Was there an aic7xxx scsi driver on the
> > box? run_task_queue(_disk) should eventually unlock those pages but
> > they remain locked. I am trying to narrow it down to fs/buffer code
> > or the SCSI
>[EMAIL PROTECTED] said:
>> I am running in to a problem, seemingly a deadlock situation, where
>> almost all the processes end up in the TASK_UNINTERRUPTIBLE state.
>> All the process eventually stop responding, including login shell, no
>> screen updates, keyboard etc. Can ping and sysrq key
keywords: tux, aic7xxx, 2.4.5-ac4, specweb99, __wait_on_page, __lock_page
Greetings,
I am running in to a problem, seemingly a deadlock situation, where almost
all the processes end up in the TASK_UNINTERRUPTIBLE state. All the
process eventually stop responding, including login shell, no
keywords: tux, aic7xxx, 2.4.5-ac4, specweb99, __wait_on_page, __lock_page
Greetings,
I am running in to a problem, seemingly a deadlock situation, where almost
all the processes end up in the TASK_UNINTERRUPTIBLE state. All the
process eventually stop responding, including login shell, no
[EMAIL PROTECTED] said:
I am running in to a problem, seemingly a deadlock situation, where
almost all the processes end up in the TASK_UNINTERRUPTIBLE state.
All the process eventually stop responding, including login shell, no
screen updates, keyboard etc. Can ping and sysrq key works.
On Mon, 25 Jun 2001, Jeff Dike wrote:
[EMAIL PROTECTED] said:
Can you give more details? Was there an aic7xxx scsi driver on the
box? run_task_queue(tq_disk) should eventually unlock those pages but
they remain locked. I am trying to narrow it down to fs/buffer code
or the SCSI driver
Hi
i have been looking at it a lot over the past few days i seem to be the
person who can trigger it easyest.
over the past couple of days i have been running with the
#define WAITQUEUE_DEBUG 1
no problems seem to have appeared there though and the bug still triggers.
On Mon, 25 Jun 2001,
Hi again
i have a stack now an
#0 schedule () at sched.c:536
#1 0x1002f932 in __wait_on_buffer (bh=0x50eb16e4) at buffer.c:157
#2 0x10036f46 in block_read (filp=0x5009787c, buf=0x80c08f0
¤\201, count=8192, ppos=0x5009789c) at
20 matches
Mail list logo
