From: "Toralf Förster" <toralf.foerster@gmx.de>
To: Richard Weinberger <richard@nod.at>
Cc: UML devel <user-mode-linux-devel@lists.sourceforge.net>
Subject: Re: [uml-devel] does 3.12.2 breaks UML with "con=xterm" ?
Date: Sun, 01 Dec 2013 18:07:05 +0100 [thread overview]
Message-ID: <529B6CB9.4060602@gmx.de> (raw)
In-Reply-To: <1423288.L1vGMMJNcF@sandpuppy>
On 12/01/2013 11:20 AM, Richard Weinberger wrote:
> Am Sonntag, 1. Dezember 2013, 11:17:31 schrieb Toralf Förster:
>> On 12/01/2013 12:19 AM, Richard Weinberger wrote:
>>>>> after another minute now all xterms are away ....
>>>
>>> So, it does not crash immediately.
>>
>> Right, to be precise, just 1 sub-process crashes immediately
>>
>>> Please do not use xterm for con0. Such that we can see the kernel output
>>> after a crash.
>>> Maybe there are some error message before...
>>
>> Without xterm I do not see any errors except the "winch_thread ..." - line.
>
> I meant xterm for all consoles but con0...
> Such that you can trigger the crash but are still able to see the output.
>
Still trying to get info, no luck till now.
And these syslog messages from the 32bit uml guest (3.12-rc2-g...) are just a fallout from a cored process IMO:
Dec 1 17:59:30 trinity kernel: =============================================================================
Dec 1 17:59:30 trinity kernel: BUG kmalloc-64 (Not tainted): Poison overwritten
Dec 1 17:59:30 trinity kernel: -----------------------------------------------------------------------------
Dec 1 17:59:30 trinity kernel:
Dec 1 17:59:30 trinity kernel: Disabling lock debugging due to kernel taint
Dec 1 17:59:30 trinity kernel: INFO: 0x48b59da5-0x48b59dac. First byte 0xff instead of 0x6b
Dec 1 17:59:30 trinity kernel: INFO: Allocated in ext4_htree_store_dirent+0x2e/0x120 age=817 cpu=0 pid=1076
Dec 1 17:59:30 trinity kernel: INFO: Freed in free_rb_tree_fname+0x3b/0xa0 age=817 cpu=0 pid=1076
Dec 1 17:59:30 trinity kernel: INFO: Slab 0x0a83f220 objects=36 used=36 fp=0x (null) flags=0x0080
Dec 1 17:59:30 trinity kernel: INFO: Object 0x48b59d90 @offset=3472 fp=0x48b59620
Dec 1 17:59:30 trinity kernel:
Dec 1 17:59:30 trinity kernel: Bytes b4 48b59d80: cc 03 00 00 07 98 ff ff 5a 5a 5a 5a 5a 5a 5a 5a ........ZZZZZZZZ
Dec 1 17:59:30 trinity kernel: Object 48b59d90: 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b kkkkkkkkkkkkkkkk
Dec 1 17:59:30 trinity kernel: Object 48b59da0: 6b 6b 6b 6b 6b ff fe fb 77 fe ff ff ff 6b 6b 6b kkkkk...w....kkk
Dec 1 17:59:30 trinity kernel: Object 48b59db0: 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b kkkkkkkkkkkkkkkk
Dec 1 17:59:30 trinity kernel: Object 48b59dc0: 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b a5 kkkkkkkkkkkkkkk.
Dec 1 17:59:30 trinity kernel: Redzone 48b59dd0: bb bb bb bb ....
Dec 1 17:59:30 trinity kernel: Padding 48b59df8: 5a 5a 5a 5a 5a 5a 5a 5a ZZZZZZZZ
Dec 1 17:59:30 trinity kernel: CPU: 0 PID: 1147 Comm: haveged Tainted: G B 3.13.0-rc2-00001-gaf91706 #3
Dec 1 17:59:30 trinity kernel: Stack:
Dec 1 17:59:30 trinity kernel: 084bf793 084bf793 481e7b70 00000004 085d0547 48849d80 48b59d90 0a83f220
Dec 1 17:59:30 trinity kernel: 481e7b80 084247eb 00000000 00000000 481e7bb0 080fbed8 084d0168 48b59d90
Dec 1 17:59:30 trinity kernel: 00000d90 48b59620 00000000 00000080 48b59000 48b59da5 0a83f220 48849d80
Dec 1 17:59:30 trinity kernel: Call Trace:
Dec 1 17:59:30 trinity kernel: [<084247eb>] dump_stack+0x26/0x28
Dec 1 17:59:30 trinity kernel: [<080fbed8>] print_trailer+0x118/0x120
Dec 1 17:59:30 trinity kernel: [<080fc292>] check_bytes_and_report+0xb2/0x110
Dec 1 17:59:30 trinity kernel: [<080fc40d>] check_object+0x11d/0x220
Dec 1 17:59:30 trinity kernel: [<080fd0c9>] ? check_slab+0xb9/0xd0
Dec 1 17:59:30 trinity kernel: [<084231f9>] alloc_debug_processing+0x130/0x141
Dec 1 17:59:30 trinity kernel: [<08423705>] __slab_alloc.constprop.75+0x305/0x319
Dec 1 17:59:30 trinity kernel: [<081800de>] ? ext4_htree_store_dirent+0x2e/0x120
Dec 1 17:59:30 trinity kernel: [<081800de>] ? ext4_htree_store_dirent+0x2e/0x120
Dec 1 17:59:30 trinity kernel: [<080fdaeb>] __kmalloc+0x7b/0x140
Dec 1 17:59:30 trinity kernel: [<0819b350>] ? str2hashbuf_signed+0x0/0xb0
Dec 1 17:59:30 trinity kernel: [<081800de>] ? ext4_htree_store_dirent+0x2e/0x120
Dec 1 17:59:30 trinity kernel: [<081800de>] ext4_htree_store_dirent+0x2e/0x120
Dec 1 17:59:30 trinity kernel: [<0818f420>] htree_dirblock_to_tree+0x110/0x160
Dec 1 17:59:30 trinity kernel: [<0818fc30>] ext4_htree_fill_tree+0xd0/0x270
Dec 1 17:59:30 trinity kernel: [<08423397>] ? free_debug_processing+0x18d/0x1f6
Dec 1 17:59:30 trinity kernel: [<0810c6d1>] ? final_putname+0x41/0x50
Dec 1 17:59:30 trinity kernel: [<0817f835>] ? ext4_readdir+0x55/0x890
Dec 1 17:59:30 trinity kernel: [<084238a7>] ? __slab_free+0x18e/0x1f9
Dec 1 17:59:30 trinity kernel: [<0817f9ac>] ext4_readdir+0x1cc/0x890
Dec 1 17:59:30 trinity kernel: [<08110e7c>] ? do_filp_open+0x2c/0x80
Dec 1 17:59:30 trinity kernel: [<080fda08>] ? kmem_cache_free+0xd8/0x110
Dec 1 17:59:30 trinity kernel: [<0810c6d1>] ? final_putname+0x41/0x50
Dec 1 17:59:30 trinity kernel: [<0810c6d1>] ? final_putname+0x41/0x50
Dec 1 17:59:30 trinity kernel: [<08115285>] iterate_dir+0x55/0xb0
Dec 1 17:59:30 trinity kernel: [<0811541f>] SyS_getdents+0xaf/0x150
Dec 1 17:59:30 trinity kernel: [<08114f30>] ? filldir+0x0/0x190
Dec 1 17:59:30 trinity kernel: [<080693b0>] ? mconsole_halt+0x20/0x30
Dec 1 17:59:30 trinity kernel: [<080693b0>] ? mconsole_halt+0x20/0x30
Dec 1 17:59:30 trinity kernel: [<08062a94>] handle_syscall+0x64/0x80
Dec 1 17:59:30 trinity kernel: [<080693b0>] ? mconsole_halt+0x20/0x30
Dec 1 17:59:30 trinity kernel: [<08069398>] ? mconsole_halt+0x8/0x30
Dec 1 17:59:30 trinity kernel: [<080693b0>] ? mconsole_halt+0x20/0x30
Dec 1 17:59:30 trinity kernel: [<083d70c1>] ? ptrace+0x31/0x80
Dec 1 17:59:30 trinity kernel: [<08079fb2>] ? get_fp_registers+0x22/0x40
Dec 1 17:59:30 trinity kernel: [<08075085>] userspace+0x475/0x5f0
Dec 1 17:59:30 trinity kernel: [<083d70c1>] ? ptrace+0x31/0x80
Dec 1 17:59:30 trinity kernel: [<0807a516>] ? os_set_thread_area+0x26/0x40
Dec 1 17:59:30 trinity kernel: [<08079510>] ? do_set_thread_area+0x20/0x50
Dec 1 17:59:30 trinity kernel: [<08079688>] ? arch_switch_tls+0xb8/0x100
Dec 1 17:59:30 trinity kernel: [<0805f750>] fork_handler+0x60/0x70
Dec 1 17:59:30 trinity kernel:
Dec 1 17:59:30 trinity kernel: FIX kmalloc-64: Restoring 0x48b59da5-0x48b59dac=0x6b
Dec 1 17:59:30 trinity kernel:
Dec 1 17:59:30 trinity kernel: FIX kmalloc-64: Marking all objects used
>>
>> BTW wrt the radix-tree-issue seems that fedora has now a similar bug
>> open : https://bugzilla.redhat.com/show_bug.cgi?id=1015028
>
> Thanks for the info!
>
> Thanks,
> //richard
>
--
MfG/Sincerely
Toralf Förster
pgp finger print: 7B1A 07F4 EC82 0F90 D4C2 8936 872A E508 7DB6 9DA3
------------------------------------------------------------------------------
Rapidly troubleshoot problems before they affect your business. Most IT
organizations don't have a clear picture of how application performance
affects their revenue. With AppDynamics, you get 100% visibility into your
Java,.NET, & PHP application. Start your 15-day FREE TRIAL of AppDynamics Pro!
http://pubads.g.doubleclick.net/gampad/clk?id=84349351&iu=/4140/ostg.clktrk
_______________________________________________
User-mode-linux-devel mailing list
User-mode-linux-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/user-mode-linux-devel
next prev parent reply other threads:[~2013-12-01 17:07 UTC|newest]
Thread overview: 20+ messages / expand[flat|nested] mbox.gz Atom feed top
2013-11-30 14:37 [uml-devel] does 3.12.2 breaks UML with "con=xterm" ? Toralf Förster
2013-11-30 14:43 ` Toralf Förster
2013-11-30 14:51 ` Richard Weinberger
2013-11-30 15:56 ` Toralf Förster
2013-11-30 16:28 ` Toralf Förster
2013-11-30 16:36 ` Richard Weinberger
2013-11-30 17:26 ` Toralf Förster
2013-11-30 17:35 ` Richard Weinberger
2013-11-30 18:19 ` Toralf Förster
2013-11-30 18:23 ` Richard Weinberger
2013-11-30 18:43 ` Toralf Förster
2013-11-30 23:19 ` Richard Weinberger
2013-12-01 10:17 ` Toralf Förster
2013-12-01 10:20 ` Richard Weinberger
2013-12-01 17:07 ` Toralf Förster [this message]
2013-12-01 19:05 ` Toralf Förster
2013-12-02 16:42 ` Boaz Harrosh
2013-12-02 21:21 ` Richard Weinberger
2013-12-02 21:32 ` Toralf Förster
2013-12-02 21:59 ` Richard Weinberger
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=529B6CB9.4060602@gmx.de \
--to=toralf.foerster@gmx.de \
--cc=richard@nod.at \
--cc=user-mode-linux-devel@lists.sourceforge.net \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox