Re: [ANNOUNCE] 2.6.31-rc4-rt1

Clark Williams
2009-07-31T14:20:32Z

[-- Attachment #1: Type: text/plain, Size: 4713 bytes --]

On Thu, 30 Jul 2009 16:20:26 -0700
Darren Hart <dvhltc@us.ibm.com> wrote:

> Thomas Gleixner wrote:
> > We are pleased to announce the next update to our new preempt-rt
> > series.
> >
> > - update to 2.6.31-rc4
> >
> > This is a major rework of the rt patch series. Thanks to Clark
> > Williams and John Kacur for providing the merge to 2.6.30 while I was
> > stabilizing .29-rt. While the 30-rt series looked quite stable, we
> > decided to skip 30-rt entirely to keep track with the ongoing mainline
> > development for various reaons. The .31-rt series is planned to be
> > stabilized as we have done with .29-rt.
>
> I hit this on boot on an IBM Thinkpad T60p (Intel Core Duo). Haven't
> had a chance to dig in yet, but wanted to post sooner rather than later.
>
> [ 4.764702] Freeing unused kernel memory: 552k freed
> [ 4.765205] Write protecting the kernel text: 4552k
> [ 4.765389] Write protecting the kernel read-only data: 1776k
> [ 4.766458] BUG: sleeping function called from invalid context at
> kernel/rtmutex.c:684
> [ 4.766596] in_atomic(): 1, irqs_disabled(): 0, pid: 103, name: init
> [ 4.766723] Pid: 103, comm: init Not tainted 2.6.31-rc4-rt1-dvh01 #1
> [ 4.766848] Call Trace:
> [ 4.766973] [<c012d881>] __might_sleep+0xe1/0x100
> [ 4.767099] [<c056ccba>] rt_spin_lock+0x2a/0x70
> [ 4.767224] [<c018243a>] res_counter_uncharge+0x2a/0x50
> [ 4.767350] [<c01e6e23>] __mem_cgroup_uncharge_common+0x93/0x190
> [ 4.767477] [<c01e6fb8>] mem_cgroup_uncharge_page+0x28/0x30
> [ 4.767604] [<c01d6b87>] page_remove_rmap+0x47/0x50
> [ 4.767728] [<c01cf2d9>] unmap_vmas+0x349/0x6b0
> [ 4.767852] [<c01d45e5>] exit_mmap+0xc5/0x1c0
> [ 4.767977] [<c037d634>] ? get_random_int+0xb4/0xe0
> [ 4.768114] [<c0140481>] mmput+0x51/0xc0
> [ 4.768237] [<c01ef651>] flush_old_exec+0x381/0x6c0
> [ 4.768361] [<c01ea0c6>] ? vfs_read+0x126/0x190
> [ 4.768484] [<c01eea3f>] ? kernel_read+0x3f/0x60
> [ 4.768609] [<c02228cb>] load_elf_binary+0x33b/0x18c0
> [ 4.768734] [<c012f06f>] ? __wake_up+0x3f/0x50
> [ 4.768859] [<c01ccfee>] ? kunmap_high+0x7e/0xb0
> [ 4.768983] [<c01ccede>] ? page_address+0x8e/0x90
> [ 4.769125] [<c01cd15b>] ? kmap_high+0x13b/0x4c0
> [ 4.769248] [<c01d1752>] ? __get_user_pages+0x112/0x3d0
> [ 4.769374] [<c012f06f>] ? __wake_up+0x3f/0x50
> [ 4.769498] [<c056cd9a>] ? __rt_spin_lock+0x2a/0x70
> [ 4.769623] [<c0222590>] ? load_elf_binary+0x0/0x18c0
> [ 4.769747] [<c01eedbd>] search_binary_handler+0xfd/0x300
> [ 4.769872] [<c01f0568>] do_execve+0x228/0x300
> [ 4.769996] [<c0319626>] ? strncpy_from_user+0x46/0x70
> [ 4.770121] [<c0101b16>] sys_execve+0x36/0x60
> [ 4.770244] [<c0103025>] syscall_call+0x7/0xb
>

Ok, here's a traceback I got running 2.6.31-rc4-rt1 on a Lenovo T60 that
had been running for a while:

BUG: scheduling while atomic: gkrellm/0x00000001/2483, CPU#0
Modules linked in: ati_remote pl2303 usbserial fuse i915 drm i2c_algo_bit sunrpc ipv6 cpufreq_ondemand acpi_cpufreq freq_table loop dm_multipath scsi_dh kvm_intel kvm uinput arc4 ecb iwl3945 btusb iwlcore snd_hda_codec_analog bluetooth snd_hda_intel snd_hda_codec snd_hwdep mac80211 snd_pcm thinkpad_acpi snd_timer hwmon snd cfg80211 soundcore video rfkill iTCO_wdt iTCO_vendor_support sr_mod joydev cdrom ata_generic yenta_socket snd_page_alloc pcspkr i2c_i801 i2c_core output e1000e ata_piix rsrc_nonstatic sg ahci libata sd_mod scsi_mod dm_snapshot dm_zero dm_mirror dm_region_hash dm_log dm_mod uhci_hcd ohci_hcd ssb [last unloaded: microcode]
Pid: 2483, comm: gkrellm Not tainted 2.6.31-rc4-rt1 #31
Call Trace:
[<ffffffff8105742b>] __schedule_bug+0x97/0x9c
[<ffffffff8153856b>] __schedule+0xc7/0x112c
[<ffffffff8153c8c6>] ? _atomic_spin_unlock+0x46/0x62
[<ffffffff81539ad5>] schedule+0x1f/0x70
[<ffffffff8153b163>] rt_spin_lock_slowlock+0x313/0x475
[<ffffffff8153c1ed>] rt_spin_lock+0xd4/0xd9
[<ffffffff810c5d6b>] res_counter_uncharge+0x2e/0x53
[<ffffffff8115b1f5>] __mem_cgroup_uncharge_common+0x24e/0x376
[<ffffffff8115b3f7>] mem_cgroup_uncharge_page+0x52/0x54
[<ffffffff8113e9ca>] page_remove_rmap+0x5a/0x7d
[<ffffffff8112eb62>] unmap_vmas+0xb0b/0x111b
[<ffffffff81112ec0>] ? __alloc_pages_nodemask+0x1ea/0xa16
[<ffffffff81137f16>] unmap_region+0x148/0x294
[<ffffffff81139940>] do_munmap+0x35d/0x3e5
[<ffffffff81139a0e>] sys_munmap+0x46/0x5d
[<ffffffff8100cf72>] system_call_fastpath+0x16/0x1b

Steven seemed to think that we have a mismatched preempt_disable() and
preempt_enable() but I haven't had enough coffee to actually try
debugging it.

Clark

[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 198 bytes --]