lkml.org 
[lkml]   [2008]   [Mar]   [11]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
 
Messages in this thread
/
From
SubjectRe: endless loop in native_flush_tlb_others in smp_64.c
Date
On Tuesday 11 March 2008 12:09:24 you wrote:
> On Tue, 11 Mar 2008, Jike Song wrote:
>
> Any chance that you can capture SYSRQ-T output via serial or
> netconsole, so we can see the stacktrace and what the other CPUs are
> doing, if they are doing anything.

this time with a 2.6.25-rc4-wl: (unfortunatly tainted again)
the serial console seems to work: GFPs all over the place...
take a look here:
http://www.pastebin.ca/938757

Since I get so many different Oopses. I'm beginning to suspect my
fancy JFS/ReiserFS/Ext3:DM-Crypt:LVM2:MD(Raid1) combo causes
memory corruptions/leaks/voodoo...

like this other tragic incident:
loop0 D ffff810079331bd0 0 15716 2
ffff810079331b40 0000000000000046 ffff810062295c90 ffffffff804028e0
ffff810069608800 ffff810079331af0 ffffc20010af7040 ffffffff805f6700
ffffffff805f6700 ffffffff805f2f50 ffffffff805f6700 ffff81007a7df830
Call Trace:
[<ffffffff804028e0>] __split_bio+0x367/0x378
[<ffffffff8033e442>] generic_unplug_device+0x18/0x24
[<ffffffff804040b5>] dm_table_unplug_all+0x2a/0x3d
[<ffffffff802930c5>] sync_buffer+0x0/0x3f
[<ffffffff8048476d>] io_schedule+0x28/0x34
[<ffffffff80293100>] sync_buffer+0x3b/0x3f
[<ffffffff8048499e>] __wait_on_bit+0x40/0x6e
[<ffffffff802930c5>] sync_buffer+0x0/0x3f
[<ffffffff80484a38>] out_of_line_wait_on_bit+0x6c/0x78
[<ffffffff8023eb3d>] wake_bit_function+0x0/0x23
[<ffffffff802932b7>] ll_rw_block+0x8c/0xaf
[<ffffffff8029385b>] __block_prepare_write+0x366/0x3b9
[<ffffffff802e2a1c>] ext3_get_block+0x0/0xf9
[<ffffffff8029394b>] block_write_begin+0x78/0xc9
[<ffffffff802e3f1f>] ext3_write_begin+0xeb/0x1aa
[<ffffffff802e2a1c>] ext3_get_block+0x0/0xf9
[<ffffffff803b5928>] do_lo_send_aops+0x9f/0x177
[<ffffffff803b5889>] do_lo_send_aops+0x0/0x177
[<ffffffff803b5732>] loop_thread+0x2ce/0x425
[<ffffffff803b5464>] loop_thread+0x0/0x425
[<ffffffff8023e9ed>] kthread+0x47/0x76
[<ffffffff80229404>] schedule_tail+0x28/0x5c
[<ffffffff8020be68>] child_rip+0xa/0x12
[<ffffffff8023e9a6>] kthread+0x0/0x76
[<ffffffff8020be5e>] child_rip+0x0/0x12

situation: the system died after writing >2 Gb from /dev/zero
(gosh, about only 1Mb/s-500kb/s!!) into a file in a _mounted_
loopdevice of a old-hdd-image-file on a jfs/dm-crypt/lvm2 combo.

BTW: bisect is still running... the regression seems to have sneaked in
between 2.6.24 and 2.6.25-rc1 however 4000 diffs will take a while...

(it takes so long since the raid has to resync each reboot...
Thank *** that this is just a stress-testing system that can take some
beating without _failing_ apart. ;-) )

Regards,
Chr


\
 
 \ /
  Last update: 2008-03-11 22:45    [W:0.050 / U:1.004 seconds]
©2003-2020 Jasper Spaans|hosted at Digital Ocean and TransIP|Read the blog|Advertise on this site