On Fri, Aug 19, 2011 at 05:18:41PM -0500, Jonathan Nieder wrote: > Hi Yann, > > Yann Dirson wrote: > > > Got it again, when upgrading to 1.99-9, running under a 2.6.38.4 > > kernel. kern.log reads the following, maybe it will give more ideas > > about what's going on ? Concurency issue in kernel space ? > > Yeah, looks like it. Next time you get a chance in this state, could > you try something like the following? > > echo d >/proc/sysrq-trigger; # list all locks held > # or: > echo w >/proc/sysrq-trigger; # list all blocked tasks > > Also, is it reproducible (e.g., with "dpkg-reconfigure grub-pc")? > If so, trying a more recent kernel to compare results would be > interesting, too.
Unfortunately, not completely. OTOH, I get more reproducible problems when attempting to use the PATA cdrom. > Trace left unsnipped for the kernel team's benefit. Well, that kernel does not come from the package, it's a vanilla one with some changes - the VIA VT6415 chipset on my motherboard prevents the system to boot when a HD is connected to it, with the libata driver, so I'm using the old one. Maybe there was a regression in via82cxxx I did not notice before. Will dig. > Jonathan > > > INFO: task grub-mkdevicema:24535 blocked for more than 120 seconds. > > "echo 0 > /proc/sys/kernel/hung_task_timeout_secs" disables this message. > > grub-mkdevicema D 00000001034e66cc 0 24535 24534 0x00000000 > > ffff88008e95db28 0000000000000082 ffff880000000000 00000000000134c0 > > 00000000000134c0 00000000000134c0 00000000000134c0 ffff880001ad5100 > > 00000000000134c0 ffff88008e95dfd8 ffff88008e95dfd8 00000000000134c0 > > Call Trace: > > [<ffffffff8132e6ff>] __mutex_lock_common.clone.5+0x131/0x198 > > [<ffffffff811928a0>] ? exact_match+0x0/0xa > > [<ffffffff8132e774>] __mutex_lock_slowpath+0xe/0x10 > > [<ffffffff8132e5b4>] mutex_lock+0x1e/0x38 > > [<ffffffff8112764c>] __blkdev_get+0x71/0x339 > > [<ffffffff81127ba3>] ? blkdev_open+0x0/0x6b > > [<ffffffff81127ac8>] blkdev_get+0x1b4/0x28f > > [<ffffffff81127ba3>] ? blkdev_open+0x0/0x6b > > [<ffffffff81127c0a>] blkdev_open+0x67/0x6b > > [<ffffffff810fddae>] __dentry_open+0x15e/0x278 > > [<ffffffff8132f14c>] ? _raw_spin_lock+0x9/0xb > > [<ffffffff81115b82>] ? mntget+0x1b/0x21 > > [<ffffffff810feb2c>] nameidata_to_filp+0x5b/0x62 > > [<ffffffff8110a68d>] finish_open+0x9c/0x15a > > [<ffffffff8110982a>] ? do_path_lookup+0xe8/0x113 > > [<ffffffff8110abb4>] do_filp_open+0x184/0x696 > > [<ffffffff810dd1a1>] ? handle_mm_fault+0x131/0x146 > > [<ffffffff811a5f39>] ? might_fault+0x9/0xb > > [<ffffffff811a6025>] ? __strncpy_from_user+0x1a/0x49 > > [<ffffffff8111488a>] ? alloc_fd+0x6f/0x11a > > [<ffffffff810feb8e>] do_sys_open+0x5b/0xed > > [<ffffffff810fec3b>] sys_open+0x1b/0x1d > > [<ffffffff81009992>] system_call_fastpath+0x16/0x1b -- To UNSUBSCRIBE, email to debian-bugs-rc-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org