Ubuntu
linux package

xgene: BUG: soft lockup - CPU#0 stuck for 23s! [halt:2059] on poweroff

Bug #1404335 reported by Craig Magina
6
This bug affects 1 person
Affects Status Importance Assigned to Milestone
linux (Ubuntu)
Confirmed
Medium
Unassigned
Trusty
Fix Released
Undecided
Unassigned

Bug Description

[Impact]
Fixes an issue where after the system halts the cpu starts to experience soft lockups.

[Test Case]
The most reliable means of reproducing this issue is to 'sudo poweroff' the system from the console.

[Regression Potential]
These patches are upstream patches that have been in the utopic kernel for quite a while and only affect the arm64 architecture.

Revision history for this message
Brad Figg (brad-figg) wrote : Missing required logs.

This bug is missing log files that will aid in diagnosing the problem. From a terminal window please run:

apport-collect 1404335

and then change the status of the bug to 'Confirmed'.

If, due to the nature of the issue you have encountered, you are unable to run this command, please add a comment stating that fact and change the bug status to 'Confirmed'.

This change has been made by an automated script, maintained by the Ubuntu Kernel Team.

Changed in linux (Ubuntu):
status: New → Incomplete
Revision history for this message
Craig Magina (craig.magina) wrote :

Here is an output from the console of a system experiencing this issue.

This bug occurs after executing "sudo poweroff" and "sudo shutdown -h now" This issue was found on trusty-updates and trusty-
proposed. It wasn't seen in the released version.

$ uname -a
Linux am5 3.13.0-37-generic #64-Ubuntu SMP Mon Sep 22 21:32:32 UTC 2014 aarch64 aarch64 aarch64 GNU/Linux

U-Boot 2013.04-mustang_sw_1.13.28-beta (Aug 25 2014 - 14:16:10)

ubuntu@am5:~$ sudo poweroff

Broadcast message from ubuntu@am5
 (/dev/ttyS0) at 17:33 ...

The system is going down for power off NOW!
ubuntwait-for-state stop/waiting
 * Stopping rsync daemon rsync [ OK ]
 * Asking all remaining processes to terminate... [ OK ]
 * All processes ended within 1 seconds... [ OK ]
 * Deactivating swap... [ OK ]
 * Unmounting local filesystems... [ OK ]
 * Will now halt
[22800.565563] reboot: System halted
[22828.004581] BUG: soft lockup - CPU#0 stuck for 23s! [halt:2059]
[22856.004581] BUG: soft lockup - CPU#0 stuck for 23s! [halt:2059]
[22884.004581] BUG: soft lockup - CPU#0 stuck for 22s! [halt:2059]
[22912.004580] BUG: soft lockup - CPU#0 stuck for 22s! [halt:2059]
[22940.004580] BUG: soft lockup - CPU#0 stuck for 22s! [halt:2059]
[22968.004580] BUG: soft lockup - CPU#0 stuck for 22s! [halt:2059]
[22996.004580] BUG: soft lockup - CPU#0 stuck for 22s! [halt:2059]
[23024.004580] BUG: soft lockup - CPU#0 stuck for 22s! [halt:2059]
[23052.004580] BUG: soft lockup - CPU#0 stuck for 22s! [halt:2059]
[23080.004580] BUG: soft lockup - CPU#0 stuck for 22s! [halt:2059]
[23108.004580] BUG: soft lockup - CPU#0 stuck for 23s! [halt:2059]
[23136.004580] BUG: soft lockup - CPU#0 stuck for 23s! [halt:2059]
[23164.004580] BUG: soft lockup - CPU#0 stuck for 23s! [halt:2059]
[23192.004580] BUG: soft lockup - CPU#0 stuck for 23s! [halt:2059]
[23220.004580] BUG: soft lockup - CPU#0 stuck for 23s! [halt:2059]
[23248.004580] BUG: soft lockup - CPU#0 stuck for 22s! [halt:2059]
[23276.004580] BUG: soft lockup - CPU#0 stuck for 22s! [halt:2059]
[23304.004580] BUG: soft lockup - CPU#0 stuck for 22s! [halt:2059]
[23332.004580] BUG: soft lockup - CPU#0 stuck for 22s! [halt:2059]
[23360.004580] BUG: soft lockup - CPU#0 stuck for 22s! [halt:2059]

Changed in linux (Ubuntu):
status: Incomplete → Confirmed
Craig Magina (craig.magina)
tags: added: hs-arm64
Joseph Salisbury (jsalisbury)
Changed in linux (Ubuntu):
importance: Undecided → Medium
Brad Figg (brad-figg)
Changed in linux (Ubuntu Trusty):
status: New → Fix Committed
Revision history for this message
Brad Figg (brad-figg) wrote :

This bug is awaiting verification that the kernel in -proposed solves the problem. Please test the kernel and update this bug with the results. If the problem is solved, change the tag 'verification-needed-trusty' to 'verification-done-trusty'.

If verification is not done by 5 working days from today, this fix will be dropped from the source code, and this bug will be closed.

See https://wiki.ubuntu.com/Testing/EnableProposed for documentation how to enable and use -proposed. Thank you!

tags: added: verification-needed-trusty
Craig Magina (craig.magina)
tags: added: verification-done-trusty
removed: verification-needed-trusty
Revision history for this message
Launchpad Janitor (janitor) wrote :
Download full text (9.0 KiB)

This bug was fixed in the package linux - 3.13.0-45.74

---------------
linux (3.13.0-45.74) trusty; urgency=low

  [ Seth Forshee ]

  * Release Tracking Bug
    - LP: #1410384

  [ Jesse Barnes ]

  * SAUCE: drm/i915/vlv: assert and de-assert sideband reset at boot and
    resume v3
    - LP: #1401963

  [ K. Y. Srinivasan ]

  * SAUCE: storvsc: force SPC-3 compliance on win8 and win8 r2 hosts
    - LP: #1406867

  [ Timo Aaltonen ]

  * SAUCE: Switch VLV/BYT to use i915_bdw.
    - LP: #1401963

  [ Upstream Kernel Changes ]

  * Revert "xhci: clear root port wake on bits if controller isn't wake-up
    capable"
    - LP: #1408779
  * KVM: PPC: BOOK3S: HV: CMA: Reserve cma region only in hypervisor mode
    - LP: #1400209
  * e1000e: Fix no connectivity when driver loaded with cable out
    - LP: #1400365
  * net/mlx4_core: Enable CQE/EQE stride support
    - LP: #1400127
  * net/mlx4_core: Cache line EQE size support
    - LP: #1400127
  * net/mlx4_en: Add mlx4_en_get_cqe helper
    - LP: #1400127
  * net/mlx4_core: Introduce mlx4_get_module_info for cable module info
    reading
    - LP: #1400127
  * ethtool, net/mlx4_en: Cable info, get_module_info/eeprom ethtool
    support
    - LP: #1400127
  * net/mlx4_core: Introduce ACCESS_REG CMD and eth_prot_ctrl dev cap
    - LP: #1400127
  * net/mlx4_core: Add ethernet backplane autoneg device capability
    - LP: #1400127
  * ethtool, net/mlx4_en: Add 100M, 20G, 56G speeds ethtool reporting
    support
    - LP: #1400127
  * net/mlx4_en: Use PTYS register to query ethtool settings
    - LP: #1400127
  * net/mlx4_en: Use PTYS register to set ethtool settings (Speed)
    - LP: #1400127
  * net/mlx4_en: Add support for setting rxvlan offload OFF/ON
    - LP: #1400127
  * net/mlx4_en: Add ethtool support for [rx|tx]vlan offload set to OFF/ON
    - LP: #1400127
  * net/mlx4_core: Prevent VF from changing port configuration
    - LP: #1400127
  * net/mlx4_en: mlx4_en_set_settings() always fails when autoneg is set
    - LP: #1400127
  * ipv4: fix nexthop attlen check in fib_nh_match
    - LP: #1408779
  * vxlan: fix a use after free in vxlan_encap_bypass
    - LP: #1408779
  * vxlan: using pskb_may_pull as early as possible
    - LP: #1408779
  * vxlan: fix a free after use
    - LP: #1408779
  * ipv4: fix a potential use after free in ip_tunnel_core.c
    - LP: #1408779
  * ax88179_178a: fix bonding failure
    - LP: #1408779
  * tcp: md5: do not use alloc_percpu()
    - LP: #1408779
  * ipv4: dst_entry leak in ip_send_unicast_reply()
    - LP: #1408779
  * drivers/net, ipv6: Select IPv6 fragment idents for virtio UFO packets
    - LP: #1408779
  * drivers/net: macvtap and tun depend on INET
    - LP: #1408779
  * ip6_tunnel: Use ip6_tnl_dev_init as the ndo_init function.
    - LP: #1408779
  * vti6: Use vti6_dev_init as the ndo_init function.
    - LP: #1408779
  * sit: Use ipip6_tunnel_init as the ndo_init function.
    - LP: #1408779
  * gre6: Move the setting of dev->iflink into the ndo_init functions.
    - LP: #1408779
  * vxlan: Do not reuse sockets for a different address family
    - LP: #1408779
  * net: sctp: fix memory leak in auth key management
    - LP: #1408779
  * smsc911x: power-...

Read more...

Changed in linux (Ubuntu Trusty):
status: Fix Committed → Fix Released
To post a comment you must log in.
This report contains Public information  
Everyone can see this information.
Subscribing...

Other bug subscribers

Remote bug watches

Bug watches keep track of this bug in other bug trackers.