Re: all processes waiting in TASK_UNINTERRUPTIBLE state
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 it's just a matter of time... -- Daniel - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: all processes waiting in TASK_UNINTERRUPTIBLE state
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: ftp://ftp.us.kernel.org/pub/linux/kernel/people/andrea/kernels/v2.4/2.4.6pre5aa1/30_tux/* Andrea - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: all processes waiting in TASK_UNINTERRUPTIBLE state
>> 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 can trigger the bug only when running TUX 2.0-B6 which runs on 2.4.5-ac4. /bulent - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: all processes waiting in TASK_UNINTERRUPTIBLE state
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 game you can't win; However, without VM there's truly nothing to lose... http://www.surriel.com/ http://distro.conectiva.com/ Send all your spam to [EMAIL PROTECTED] (spam digging piggy) - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: all processes waiting in TASK_UNINTERRUPTIBLE state
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
> > screen updates, keyboard etc. Can ping and sysrq key works. I
> > traced the tasks through sysrq-t key. The processors are in the idle
> > state. Tasks all seem to get stuck in the __wait_on_page or
> > __lock_page.
>
> 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).
>
> I've done some poking at the problem, but haven't really learned anything
> except that something is locking pages and not unlocking them. Figuring out
> who that is was going to be my next step.
Could it be smbfs? The following piece of code from smb_writepage
looks like it could return with the page locked:
static int
smb_writepage(struct page *page)
{
/* */
/* easy case */
if (page->index < end_index)
goto do_it;
/* things got complicated... */
offset = inode->i_size & (PAGE_CACHE_SIZE-1);
/* OK, are we completely out? */
if (page->index >= end_index+1 || !offset)
return -EIO; <= This looks bad!
do_it:
get_page(page);
err = smb_writepage_sync(inode, page, 0, offset);
SetPageUptodate(page);
UnlockPage(page);
put_page(page);
return err;
}
regards Christian
--
THAT'S ALL FOLKS!
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Re: all processes waiting in TASK_UNINTERRUPTIBLE state
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
/home/mistral/dev/kernel/linux-2.4.5-um9/include/linux/locks.h:20
#3 0x1002eb4b in sys_read (fd=3, buf=0x80c00f0 "¤\201", count=8192)
at read_write.c:133
#4 0x100fb807 in execute_syscall (regs={regs = {3, 135004400, 8192,
1283476480, 0, 3212835652, 4294967258, 43, 43, 0, 0, 3,
1074582884, 35, 582, 3212835588, 43}}) at syscall_kern.c:332
#5 0x100fb926 in syscall_handler (unused=0x0) at
syscall_user.c:80
this should still be on #umldebug on irc.openproject.net
for the next few ours if anybodys intresting at taking a look though
gdb via a bot.
James
--
-
Web: http://www.stev.org
Mobile: +44 07779080838
E-Mail: [EMAIL PROTECTED]
8:30pm up 2 days, 42 min, 4 users, load average: 1.00, 0.94, 0.64
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Re: all processes waiting in TASK_UNINTERRUPTIBLE state
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, 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 > > screen updates, keyboard etc. Can ping and sysrq key works. I > > traced the tasks through sysrq-t key. The processors are in the idle > > state. Tasks all seem to get stuck in the __wait_on_page or > > __lock_page. i also seem to get ut ub __wait_on_buffer and ___wait_on_page James -- - Web: http://www.stev.org Mobile: +44 07779080838 E-Mail: [EMAIL PROTECTED] 8:00pm up 2 days, 12 min, 4 users, load average: 1.41, 0.38, 0.40 - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: all processes waiting in TASK_UNINTERRUPTIBLE state
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 aic7xxx in my case. > > Rik would be the one to tell you whether there was an aic7xxx driver > on the physical box. There obviously isn't one on UML, so if we're > looking at the same bug, it's in the generic code. The box has as AIC-7880U controller. OTOH, my dual P5 also has an AIC7xxx controller and I've never seen the problem there... On our quad Xeon this problem really seems to be phase-of-moon related; it hasn't shown up in the last 5 days or so under heavy stress testing, but when the kernel is compiled just a little bit different it doesn't happen. ;) regards, Rik -- Virtual memory is like a game you can't win; However, without VM there's truly nothing to lose... http://www.surriel.com/ http://distro.conectiva.com/ Send all your spam to [EMAIL PROTECTED] (spam digging piggy) - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: all processes waiting in TASK_UNINTERRUPTIBLE state
>[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. I >> traced the tasks through sysrq-t key. The processors are in the idle >> state. Tasks all seem to get stuck in the __wait_on_page or >> __lock_page. > >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). 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 aic7xxx in my case. Thanks. /bulent - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
