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 an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.