Re: [2.6.14-rc1/sparc54]: BUG: soft lockup detected on CPU#0!
Tomasz Kłoczko <[email protected]> Sat, 17 Sep 2005 17:22:45 +0200 (CEST)
| Newsgroups | gmane.linux.aurora.devel,gmane.linux.ports.sparc,gmane.linux.kernel |
|---|---|
| Message-ID | <[email protected]> |
On Fri, 16 Sep 2005, David S. Miller wrote: > From: Tomasz Kłoczko <[email protected]> > Date: Fri, 16 Sep 2005 14:42:56 +0200 (CEST) > >> On Thu, 15 Sep 2005, David S. Miller wrote: >> >>> I wonder if the NFS daemon code needs to have some limits put on >>> how much cpu it consumes handling requests before it gives up the >>> cpu. Perhaps, it has such throttling already, I don't know. >> >> But this not case NFS server but NSF client. During this lookups I observe >> rpciod takes 90-99% time of single processor. Load is between 10 and 20. > > After studying some code yesterday, NFS client has the same > exact problem as NFS daemon, namely that if you give it enough > work it will never give up the cpu so that other tasks can > be scheduled. > > This is a serious bug, and can easily trigger those soft lockup > messages. Based upon some other reports seen on linux-kernel > and elsewhere, things like the raid1 kernel daemon have a similar > issue as well. > > I think you can help things _enormusly_ by turning off SLAB > poisioning, as I said that debugging feature is _VERY_ expensive. I'll try. Now I have next call trace catched during reboot system after perform full backup on NFS volume (during this as previouse was tons of lookups). This case was during umounting NFS volumes (on system shutdown). Below call trace may have some typos because I read tem from screen and write on paper: Badness in interruptible_sleep_on_timeout at kernel/shed.c: 3403 (Not tainted) Call trace: [00000000021c3cf8] nfs_kill_super+0x8c/0xbc [nfs] [00000000004962d4] deactivate_super+0x58/0x7c [00000000004ac5cc] sys_umount+0x2f8/0x308 [0000000000410fd4] linux_sparc_syscall32_0x34/0x40 [0000000000011ebc] 0x11ebc Above may be is some resoult corrupting something during soft lookupus but if not probably may be usefull on finding bugs. kloczek -- ----------------------------------------------------------- *Ludzie nie mają problemów, tylko sobie sami je stwarzają* ----------------------------------------------------------- Tomasz Kłoczko, sys adm @zie.pg.gda.pl|*e-mail: [email protected]* _______________________________________________ Aurora-sparc-devel mailing list [email protected] http://lists.auroralinux.org/mailman/listinfo/aurora-sparc-devel Aurora FAQ: http://www.ecs.soton.ac.uk/~mas01r/aurorafaq.html