From mboxrd@z Thu Jan 1 00:00:00 1970 From: Thomas Gleixner Subject: Re: traceback on 3.2.7-rt13 Date: Thu, 1 Mar 2012 16:23:30 +0100 (CET) Message-ID: References: <20120225105502.0f4553a3@gmail.com> Mime-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Cc: Steven Rostedt , RT To: Clark Williams Return-path: Received: from www.linutronix.de ([62.245.132.108]:37651 "EHLO Galois.linutronix.de" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1758608Ab2CAPXd (ORCPT ); Thu, 1 Mar 2012 10:23:33 -0500 In-Reply-To: <20120225105502.0f4553a3@gmail.com> Sender: linux-rt-users-owner@vger.kernel.org List-ID: On Sat, 25 Feb 2012, Clark Williams wrote: > Thomas, > > I just saw the following traceback on my laptop running 3.2.7-rt13: > > [32943.463901] Modules linked in: tun vfat fat usb_storage uas tcp_lp > ppdev parport_pc lp parport fuse be2iscsi iscsi_boot_sysfs bnx2i cnic > uio cxgb4i cxgb4 lockd cxgb3i libcxgbi cxgb3 mdio iscsi_tcp > libiscsi_tcp libiscsi scsi_transport_iscsi rfcomm bnep > nf_conntrack_ipv4 ip6t_REJECT nf_defrag_ipv4 nf_conntrack_ipv6 > nf_defrag_ipv6 xt_state nf_conntrack ip6table_filter ip6_tables > snd_hda_codec_hdmi arc4 snd_hda_codec_conexant iwlwifi snd_hda_intel > snd_hda_codec btusb bluetooth snd_hwdep mac80211 snd_seq uvcvideo > snd_seq_device snd_pcm thinkpad_acpi snd_timer videodev snd cfg80211 > e1000e i7core_edac media v4l2_compat_ioctl32 xhci_hcd edac_core > i2c_i801 snd_page_alloc rfkill iTCO_wdt pcspkr iTCO_vendor_support > soundcore microcode uinput sunrpc ipv6 sdhci_pci sdhci mmc_core > ehci_hcd nouveau ttm drm_kms_helper drm i2c_algo_bit i2c_core mxm_wmi > wmi video [last unloaded: scsi_wait_scan] [32943.463949] Pid: 63, comm: > irq/9-acpi Tainted: G W 3.2.7-rt13+ #40 [32943.463951] Call > Trace: [32943.463958] [] __schedule_bug+0x5e/0x62 > [32943.463963] [] __schedule+0x6ed/0x760 > [32943.463966] [] schedule+0x2e/0xa0 [32943.463970] > [] rt_spin_lock_slowlock+0x150/0x1ef [32943.463975] > [] ? check_same_owner+0x31/0x80 [32943.463978] > [] rt_spin_lock+0x26/0x30 [32943.463983] > [] kmem_cache_alloc_trace+0x6c/0x320 [32943.463987] > [] ? acpi_hw_write_port+0x43/0x98 [32943.463991] > [] ? acpi_ec_sync_query+0x102/0x102 [32943.463995] > [] __acpi_os_execute+0x35/0xc6 [32943.463998] > [] acpi_os_execute+0x10/0x12 [32943.464001] > [] acpi_ec_gpe_handler+0xad/0xb6 [32943.464004] > [] acpi_ev_gpe_dispatch+0xc5/0x13e [32943.464007] > [] acpi_ev_gpe_detect+0xb5/0x10d [32943.464012] > [] ? irq_thread_fn+0x50/0x50 [32943.464015] > [] acpi_ev_sci_xrupt_handler+0x22/0x2b > [32943.464017] [] acpi_irq+0x16/0x31 [32943.464020] > [] irq_forced_thread_fn+0x2e/0x70 [32943.464023] > [] irq_thread+0x17a/0x200 [32943.464026] > [] ? irq_finalize_oneshot+0x20/0x20 [32943.464030] > [] kthread+0x98/0xa0 [32943.464034] > [] kernel_thread_helper+0x4/0x10 [32943.464037] > [] ? __init_kthread_worker+0x70/0x70 [32943.464040] > [] ? gs_change+0x13/0x13 > > > I'll dig into it a bit more but my guess is that it was something > battery releated (I'd accidentally kicked the power cord out at a > coffee shop and noticed that I was down to 28% battery, when I then > noticed that I had a traceback). That's a known issue and has been reported over and over. That's due to making the acpi locks raw. Now I can't find any bug report which tells me WHY the heck we made those locks raw in the first place. All I can remember is that the trace back came deep from the idle code. That's why I asked to revert the acpi-make-gbl-hardware-lock-raw.patch acpi-make-ec-lock-raw-as-well.patch patches, so we can get that information. It might be a non issue on 3.2 and only a 3.0 problem, but as I can't find anything I'm going to drop those patches from the next 3.2 release and wait for proper bugreports coming again :) Thanks, tglx