All of lore.kernel.org
 help / color / mirror / Atom feed
* traceback on 3.2.7-rt13
@ 2012-02-25 16:55 Clark Williams
  2012-03-01 15:23 ` Thomas Gleixner
  0 siblings, 1 reply; 5+ messages in thread
From: Clark Williams @ 2012-02-25 16:55 UTC (permalink / raw)
  To: Thomas Gleixner; +Cc: Steven Rostedt, RT

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

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]  [<ffffffff815ca1b8>] __schedule_bug+0x5e/0x62
[32943.463963]  [<ffffffff815dedcd>] __schedule+0x6ed/0x760
[32943.463966]  [<ffffffff815df27e>] schedule+0x2e/0xa0 [32943.463970]
[<ffffffff815e0951>] rt_spin_lock_slowlock+0x150/0x1ef [32943.463975]
[<ffffffff81056d01>] ? check_same_owner+0x31/0x80 [32943.463978]
[<ffffffff815e0ee6>] rt_spin_lock+0x26/0x30 [32943.463983]
[<ffffffff81160cdc>] kmem_cache_alloc_trace+0x6c/0x320 [32943.463987]
[<ffffffff8135a307>] ? acpi_hw_write_port+0x43/0x98 [32943.463991]
[<ffffffff81346714>] ? acpi_ec_sync_query+0x102/0x102 [32943.463995]
[<ffffffff81340fcd>] __acpi_os_execute+0x35/0xc6 [32943.463998]
[<ffffffff8134106e>] acpi_os_execute+0x10/0x12 [32943.464001]
[<ffffffff81346e1f>] acpi_ec_gpe_handler+0xad/0xb6 [32943.464004]
[<ffffffff81351baa>] acpi_ev_gpe_dispatch+0xc5/0x13e [32943.464007]
[<ffffffff81351cd8>] acpi_ev_gpe_detect+0xb5/0x10d [32943.464012]
[<ffffffff810d7560>] ? irq_thread_fn+0x50/0x50 [32943.464015]
[<ffffffff813502a6>] acpi_ev_sci_xrupt_handler+0x22/0x2b
[32943.464017]  [<ffffffff81341086>] acpi_irq+0x16/0x31 [32943.464020]
[<ffffffff810d758e>] irq_forced_thread_fn+0x2e/0x70 [32943.464023]
[<ffffffff810d748a>] irq_thread+0x17a/0x200 [32943.464026]
[<ffffffff810d7310>] ? irq_finalize_oneshot+0x20/0x20 [32943.464030]
[<ffffffff81094578>] kthread+0x98/0xa0 [32943.464034]
[<ffffffff815e9d74>] kernel_thread_helper+0x4/0x10 [32943.464037]
[<ffffffff810944e0>] ? __init_kthread_worker+0x70/0x70 [32943.464040]
[<ffffffff815e9d70>] ? 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). 

Clark

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

^ permalink raw reply	[flat|nested] 5+ messages in thread

* Re: traceback on 3.2.7-rt13
  2012-02-25 16:55 traceback on 3.2.7-rt13 Clark Williams
@ 2012-03-01 15:23 ` Thomas Gleixner
  2012-03-01 19:14   ` John Kacur
  0 siblings, 1 reply; 5+ messages in thread
From: Thomas Gleixner @ 2012-03-01 15:23 UTC (permalink / raw)
  To: Clark Williams; +Cc: Steven Rostedt, RT

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]  [<ffffffff815ca1b8>] __schedule_bug+0x5e/0x62
> [32943.463963]  [<ffffffff815dedcd>] __schedule+0x6ed/0x760
> [32943.463966]  [<ffffffff815df27e>] schedule+0x2e/0xa0 [32943.463970]
> [<ffffffff815e0951>] rt_spin_lock_slowlock+0x150/0x1ef [32943.463975]
> [<ffffffff81056d01>] ? check_same_owner+0x31/0x80 [32943.463978]
> [<ffffffff815e0ee6>] rt_spin_lock+0x26/0x30 [32943.463983]
> [<ffffffff81160cdc>] kmem_cache_alloc_trace+0x6c/0x320 [32943.463987]
> [<ffffffff8135a307>] ? acpi_hw_write_port+0x43/0x98 [32943.463991]
> [<ffffffff81346714>] ? acpi_ec_sync_query+0x102/0x102 [32943.463995]
> [<ffffffff81340fcd>] __acpi_os_execute+0x35/0xc6 [32943.463998]
> [<ffffffff8134106e>] acpi_os_execute+0x10/0x12 [32943.464001]
> [<ffffffff81346e1f>] acpi_ec_gpe_handler+0xad/0xb6 [32943.464004]
> [<ffffffff81351baa>] acpi_ev_gpe_dispatch+0xc5/0x13e [32943.464007]
> [<ffffffff81351cd8>] acpi_ev_gpe_detect+0xb5/0x10d [32943.464012]
> [<ffffffff810d7560>] ? irq_thread_fn+0x50/0x50 [32943.464015]
> [<ffffffff813502a6>] acpi_ev_sci_xrupt_handler+0x22/0x2b
> [32943.464017]  [<ffffffff81341086>] acpi_irq+0x16/0x31 [32943.464020]
> [<ffffffff810d758e>] irq_forced_thread_fn+0x2e/0x70 [32943.464023]
> [<ffffffff810d748a>] irq_thread+0x17a/0x200 [32943.464026]
> [<ffffffff810d7310>] ? irq_finalize_oneshot+0x20/0x20 [32943.464030]
> [<ffffffff81094578>] kthread+0x98/0xa0 [32943.464034]
> [<ffffffff815e9d74>] kernel_thread_helper+0x4/0x10 [32943.464037]
> [<ffffffff810944e0>] ? __init_kthread_worker+0x70/0x70 [32943.464040]
> [<ffffffff815e9d70>] ? 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


^ permalink raw reply	[flat|nested] 5+ messages in thread

* Re: traceback on 3.2.7-rt13
  2012-03-01 15:23 ` Thomas Gleixner
@ 2012-03-01 19:14   ` John Kacur
  2012-03-02 10:41     ` Thomas Gleixner
  0 siblings, 1 reply; 5+ messages in thread
From: John Kacur @ 2012-03-01 19:14 UTC (permalink / raw)
  To: Thomas Gleixner; +Cc: Clark Williams, Steven Rostedt, RT

On Thu, Mar 1, 2012 at 4:23 PM, Thomas Gleixner <tglx@linutronix.de> wrote:
> 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]  [<ffffffff815ca1b8>] __schedule_bug+0x5e/0x62
>> [32943.463963]  [<ffffffff815dedcd>] __schedule+0x6ed/0x760
>> [32943.463966]  [<ffffffff815df27e>] schedule+0x2e/0xa0 [32943.463970]
>> [<ffffffff815e0951>] rt_spin_lock_slowlock+0x150/0x1ef [32943.463975]
>> [<ffffffff81056d01>] ? check_same_owner+0x31/0x80 [32943.463978]
>> [<ffffffff815e0ee6>] rt_spin_lock+0x26/0x30 [32943.463983]
>> [<ffffffff81160cdc>] kmem_cache_alloc_trace+0x6c/0x320 [32943.463987]
>> [<ffffffff8135a307>] ? acpi_hw_write_port+0x43/0x98 [32943.463991]
>> [<ffffffff81346714>] ? acpi_ec_sync_query+0x102/0x102 [32943.463995]
>> [<ffffffff81340fcd>] __acpi_os_execute+0x35/0xc6 [32943.463998]
>> [<ffffffff8134106e>] acpi_os_execute+0x10/0x12 [32943.464001]
>> [<ffffffff81346e1f>] acpi_ec_gpe_handler+0xad/0xb6 [32943.464004]
>> [<ffffffff81351baa>] acpi_ev_gpe_dispatch+0xc5/0x13e [32943.464007]
>> [<ffffffff81351cd8>] acpi_ev_gpe_detect+0xb5/0x10d [32943.464012]
>> [<ffffffff810d7560>] ? irq_thread_fn+0x50/0x50 [32943.464015]
>> [<ffffffff813502a6>] acpi_ev_sci_xrupt_handler+0x22/0x2b
>> [32943.464017]  [<ffffffff81341086>] acpi_irq+0x16/0x31 [32943.464020]
>> [<ffffffff810d758e>] irq_forced_thread_fn+0x2e/0x70 [32943.464023]
>> [<ffffffff810d748a>] irq_thread+0x17a/0x200 [32943.464026]
>> [<ffffffff810d7310>] ? irq_finalize_oneshot+0x20/0x20 [32943.464030]
>> [<ffffffff81094578>] kthread+0x98/0xa0 [32943.464034]
>> [<ffffffff815e9d74>] kernel_thread_helper+0x4/0x10 [32943.464037]
>> [<ffffffff810944e0>] ? __init_kthread_worker+0x70/0x70 [32943.464040]
>> [<ffffffff815e9d70>] ? 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 :)
>

FWIW
I believe the latter comes from here: https://lkml.org/lkml/2011/12/3/53

Thanks
John
--
To unsubscribe from this list: send the line "unsubscribe linux-rt-users" in
the body of a message to majordomo@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

^ permalink raw reply	[flat|nested] 5+ messages in thread

* Re: traceback on 3.2.7-rt13
  2012-03-01 19:14   ` John Kacur
@ 2012-03-02 10:41     ` Thomas Gleixner
  2012-03-02 11:29       ` John Kacur
  0 siblings, 1 reply; 5+ messages in thread
From: Thomas Gleixner @ 2012-03-02 10:41 UTC (permalink / raw)
  To: John Kacur; +Cc: Clark Williams, Steven Rostedt, RT

[-- Attachment #1: Type: TEXT/PLAIN, Size: 792 bytes --]

On Thu, 1 Mar 2012, John Kacur wrote:
> On Thu, Mar 1, 2012 at 4:23 PM, Thomas Gleixner <tglx@linutronix.de> wrote:
> > 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 :)
> >
> 
> FWIW
> I believe the latter comes from here: https://lkml.org/lkml/2011/12/3/53

And how does that help? I know that the ec lock conversion was a
follow up to the gbl hardware lock conversion, but I need to see the
backtrace again which made us convert gbl lock.

Thanks,

	tglx

^ permalink raw reply	[flat|nested] 5+ messages in thread

* Re: traceback on 3.2.7-rt13
  2012-03-02 10:41     ` Thomas Gleixner
@ 2012-03-02 11:29       ` John Kacur
  0 siblings, 0 replies; 5+ messages in thread
From: John Kacur @ 2012-03-02 11:29 UTC (permalink / raw)
  To: Thomas Gleixner; +Cc: Clark Williams, Steven Rostedt, RT

On Fri, Mar 2, 2012 at 11:41 AM, Thomas Gleixner <tglx@linutronix.de> wrote:
> On Thu, 1 Mar 2012, John Kacur wrote:
>> On Thu, Mar 1, 2012 at 4:23 PM, Thomas Gleixner <tglx@linutronix.de> wrote:
>> > 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 :)
>> >
>>
>> FWIW
>> I believe the latter comes from here: https://lkml.org/lkml/2011/12/3/53
>
> And how does that help? I know that the ec lock conversion was a
> follow up to the gbl hardware lock conversion, but I need to see the
> backtrace again which made us convert gbl lock.
>

So, if I can read between the lines here, you're saying the posted
traceback in the ml link wouldn't occur without the the gbl lock?
Unfortunately I don't think the original backtrace was posted on the
ml, otherwise somebody could have hunted it down. Ok, FWIW turned out
to be not much.

John
--
To unsubscribe from this list: send the line "unsubscribe linux-rt-users" in
the body of a message to majordomo@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

^ permalink raw reply	[flat|nested] 5+ messages in thread

end of thread, other threads:[~2012-03-02 11:29 UTC | newest]

Thread overview: 5+ messages (download: mbox.gz / follow: Atom feed)
-- links below jump to the message on this page --
2012-02-25 16:55 traceback on 3.2.7-rt13 Clark Williams
2012-03-01 15:23 ` Thomas Gleixner
2012-03-01 19:14   ` John Kacur
2012-03-02 10:41     ` Thomas Gleixner
2012-03-02 11:29       ` John Kacur

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.