Re: [uml-devel] [PATCH] x86, hweight: Fix UML boot crash
From: Paolo Giarrusso
Date: Mon Jun 14 2010 - 06:27:03 EST
2010/6/14 Toralf FÃrster <toralf.foerster@xxxxxx>:
>
> Borislav Petkov wrote at 16:10:58
>> Did you do 'make mrproper' before rebuilding UML with it?
>
> Today I started with a clean git tree (cloned Linus tree) and got this :
>
> foerste@n22 ~ $ start_uml.sh
Can you enable frame pointers to get an accurate stack trace? x86 can
be accurate without, but I don't think this was ever implemented for
UML.
Because I'm not sure if below cfq_close_cooperator is being called
again, or if it's just garbage (as I guess). Anyway, it's still likely
that the crash is on hweight32.
Also, it'd be interesting to diff your configuration with the one used
by people the patch works for. Say,
$ grep HWEIGHT .config
(if there are any CFLAGS set in ARcH_HWEIGHT_CFLAGS, that would be a
problem as far as I see).
> EIP: 0073:[<081c4fcb>] CPU: 0 Not tainted ESP: 007b:08300b40 EFLAGS: 00010297
> Â ÂNot tainted
> EAX: 00000000 EBX: 190d2000 ECX: ffff8aea EDX: 00000000
> ESI: 191f4930 EDI: 191ef900 EBP: 191f4930 DS: 007b ES: 007b
> 08300794: Â[<0805e65f>] segv_handler+0x3f/0x60
> 083007a4: Â[<081c4fcb>] cfq_close_cooperator+0x4b/0x180
> 083007b0: Â[<0806eec5>] sig_handler_common+0x55/0xa0
> 083007f0: Â[<081c4fcb>] cfq_close_cooperator+0x4b/0x180
> 08300828: Â[<0806f063>] sig_handler+0x23/0x40
> 08300830: Â[<0806f2bd>] handle_signal+0x5d/0xa0
> 08300850: Â[<080715f7>] hard_handler+0x17/0x20
> 0830089c: Â[<081c4fcb>] cfq_close_cooperator+0x4b/0x180
> 08300a4c: Â[<0807a3eb>] T.696+0x9b/0xc0
> 08300a74: Â[<08079425>] enqueue_task+0x45/0x60
> 08300a94: Â[<0807945f>] activate_task+0x1f/0x30
> 08300aa0: Â[<080794d8>] try_to_wake_up+0x68/0xa0
> 08300acc: Â[<0809369f>] autoremove_wake_function+0x2f/0x60
> 08300ae8: Â[<0807754f>] __wake_up_common+0x4f/0x80
> 08300b18: Â[<08077837>] __wake_up+0x47/0x60
> 08300b3c: Â[<081c4fc6>] cfq_close_cooperator+0x46/0x180
> 08300b58: Â[<081c5440>] cfq_completed_request+0x2a0/0x560
> 08300b90: Â[<081b7fce>] elv_completed_request+0x7e/0xf0
> 08300ba8: Â[<081b98f6>] __blk_put_request+0x36/0xf0
> 08300bc0: Â[<081b9b26>] blk_finish_request+0x176/0x1d0
> 08300be0: Â[<081b9ea1>] blk_end_bidi_request+0x41/0x60
> 08300bf4: Â[<08068e8d>] ubd_intr+0x2d/0xf0
> 08300c14: Â[<080a6b32>] handle_IRQ_event+0x32/0xc0
> 08300c34: Â[<080a6c1b>] __do_IRQ+0x5b/0xb0
> 08300c50: Â[<0805b364>] do_IRQ+0x24/0x40
> 08300c5c: Â[<0805b59b>] sigio_handler+0x5b/0x80
> 08300c70: Â[<0806eec5>] sig_handler_common+0x55/0xa0
> 08300c80: Â[<0806efb5>] real_alarm_handler+0x35/0x40
> 08300cbc: Â[<080739f0>] __delay+0x20/0x30
> 08300ce8: Â[<0806f063>] sig_handler+0x23/0x40
> 08300cf0: Â[<0806f2bd>] handle_signal+0x5d/0xa0
> 08300d10: Â[<080715f7>] hard_handler+0x17/0x20
--
Paolo Giarrusso - Ph.D. Student
http://www.informatik.uni-marburg.de/~pgiarrusso/
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/