10.0: nfsd deadlocks kernel
G'd day everyone, Just found interesting bug from 10.0. Don't know yet why, but seems that on this system kernel nfsd deadlocks kernel right after system has been booted. Latest thing seen in syslog from nfsd: kernel: NFSD: Using /var/lib/nfs/v4recovery as the NFSv4 state recovery directory kernel: NFSD: recovery directory /var/lib/nfs/v4recovery doesn't exist kernel: NFSD: starting 90-second grace period WTF? Was this defaulting to highly broken NFSv4? Well that most certainly would explain it. There was nothing on console about this and once the system locks up, it does not even respond to sysRq. So not even interrupts are running anymore. Deadlocking from atomic context? -- // Janne
Am Dienstag 01 November 2005 19:45 schrieb Janne Karhunen <Janne.Karhunen@gmail.com>:
Just found interesting bug from 10.0. Don't know yet why, but seems that on this system kernel nfsd deadlocks kernel right after system has been booted.
Latest thing seen in syslog from nfsd: kernel: NFSD: Using /var/lib/nfs/v4recovery as the NFSv4 state recovery directory kernel: NFSD: recovery directory /var/lib/nfs/v4recovery doesn't exist kernel: NFSD: starting 90-second grace period
Hi Janne, worked for me. I created the missing directory by hand. No deadlock here. -- mdc
Am Mittwoch 02 November 2005 15:15 schrieb Janne Karhunen <janne.karhunen@gmail.com>:
worked for me. I created the missing directory by hand. No deadlock here. Did work about a month for me as well. It seems to be a timing issue, as if nfsd is started manually after the system has booted it works OK. However, if init starts it during boot, I get a hang.
Hi Janne, try to disable any firewall, maybe the rpcinfo-call is blocked? -- mdc
Am Dienstag, 1. November 2005 19:45 schrieb Janne Karhunen: [...]
There was nothing on console about this and once the system locks up, it does not even respond to sysRq. So not even interrupts are running anymore. Deadlocking from atomic context?
Same here, when using sk98lin for the Marvell Gigabit Lan chip. My solution: use skge instead of sk98lin. Burkhard
On Thursday 03 November 2005 10:14, Burkhard Carstens wrote:
There was nothing on console about this and once the system locks up, it does not even respond to sysRq. So not even interrupts are running anymore. Deadlocking from atomic context?
Same here, when using sk98lin for the Marvell Gigabit Lan chip. My solution: use skge instead of sk98lin.
Thanks! Damn, I should have thought of that as it's deadlocking from do_IRQ.. -- // Janne
participants (4)
-
Burkhard Carstens -
Janne Karhunen -
Janne Karhunen
-
meister＠netz00.com