Groups | Search | Server Info | Keyboard shortcuts | Login | Register [http] [https] [nntp] [nntps]

Groups > linux.kernel > #1214498 > unrolled thread

Re: Lockups with 4.2-rc kernels and qemu

Back to article view | Back to linux.kernel

This discussion starts older than the indexed window; earlier articles aren't shown. The article labeled Started by below is the oldest one visible, not the original post.

Contents

  Re: Lockups with 4.2-rc kernels and qemu Ken Moffat <zarniwhoop@ntlworld.com> - 2015-08-27 14:10 +0200
    Re: Lockups with 4.2-rc kernels and qemu Ken Moffat <zarniwhoop@ntlworld.com> - 2015-08-27 19:00 +0200
      Re: Lockups with 4.2-rc kernels and qemu Ken Moffat <zarniwhoop@ntlworld.com> - 2015-08-28 05:10 +0200

#1214498 — Re: Lockups with 4.2-rc kernels and qemu

On Tue, Aug 25, 2015 at 12:40:15AM +0100, Ken Moffat wrote:
> (Cc'ing qemu-devel, please keep me in the Cc).
> 
> TL;DR - qemu locks up my machine when I use 4.2-rc kernels.
> 
Previous mail, or at least the copy to qemu, archived at
https://lists.gnu.org/archive/html/qemu-devel/2015-08/msg02784.html

I started bisecting, but it is going to be a slow business - kernels
which seem to be ok after e.g. 3 hours can still lock the box.  I
left it running overnight, and this morning it was still up - but
firefox could no longer connect externally.  I eventually tracked
that to my logs taking the space.  But one reason the logs had
become so big was the following (found from this morning's restart):

Aug 27 09:50:28 ac4tv kernel: [  124.279813] BUG: scheduling while
atomic: qemu-system-x86/1789/0x00000002
Aug 27 09:50:28 ac4tv kernel: [  124.279819] Modules linked in:
psmouse i2c_piix4 asus_atk0110 microcode k10temp
Aug 27 09:50:28 ac4tv kernel: [  124.279828] Preemption disabled
at:[<ffffffff8100787c>] kvm_vcpu_ioctl+0x7c/0x580
Aug 27 09:50:28 ac4tv kernel: [  124.279839] 
Aug 27 09:50:28 ac4tv kernel: [  124.279842] CPU: 2 PID: 1789 Comm:
qemu-system-x86 Not tainted 4.1.0-10762-g8c7febe #4
Aug 27 09:50:28 ac4tv kernel: [  124.279843] Hardware name: System
manufacturer System Product Name/M5A78L-M LX V2, BIOS 0601
11/30/2011
Aug 27 09:50:28 ac4tv kernel: [  124.279845]  ffff88021fd14880
ffff88020718fc38 ffffffff8178316e 0000000080000002
Aug 27 09:50:28 ac4tv kernel: [  124.279847]  0000000000014880
ffff88020718fc48 ffffffff810b93d7 ffff88020718fca8
Aug 27 09:50:28 ac4tv kernel: [  124.279849]  ffffffff8178607c
ffff88021fc14880 ffff880215ebc100 ffff88020718fc78
Aug 27 09:50:28 ac4tv kernel: [  124.279851] Call Trace:
Aug 27 09:50:28 ac4tv kernel: [  124.279855]  [<ffffffff8178316e>]
dump_stack+0x4f/0x7b
Aug 27 09:50:28 ac4tv kernel: [  124.279859]  [<ffffffff810b93d7>]
__schedule_bug+0x57/0xa0
Aug 27 09:50:28 ac4tv kernel: [  124.279861]  [<ffffffff8178607c>]
__schedule+0x67c/0x9d0
Aug 27 09:50:28 ac4tv kernel: [  124.279864]  [<ffffffff8178b008>] ?
_raw_write_unlock_irqrestore+0x18/0x40
Aug 27 09:50:28 ac4tv kernel: [  124.279865]  [<ffffffff817864b1>]
schedule+0x41/0x90
Aug 27 09:50:28 ac4tv kernel: [  124.279867]  [<ffffffff81786888>]
schedule_preempt_disabled+0x18/0x30
Aug 27 09:50:28 ac4tv kernel: [  124.279869]  [<ffffffff81788f9d>]
__mutex_lock_slowpath+0x10d/0x340
Aug 27 09:50:28 ac4tv kernel: [  124.279871]  [<ffffffff817891e6>]
mutex_lock+0x16/0x30
Aug 27 09:50:28 ac4tv kernel: [  124.279874]  [<ffffffff8115c4c2>]
static_key_slow_inc+0x42/0xc0
Aug 27 09:50:28 ac4tv kernel: [  124.279875]  [<ffffffff810b92dd>]
preempt_notifier_register+0x1d/0x60
Aug 27 09:50:28 ac4tv kernel: [  124.279881]  [<ffffffff8100774d>]
vcpu_load+0x4d/0x90
Aug 27 09:50:28 ac4tv kernel: [  124.279887]  [<ffffffff8100787c>]
kvm_vcpu_ioctl+0x7c/0x580
Aug 27 09:50:28 ac4tv kernel: [  124.279892]  [<ffffffff8178af77>] ?
_raw_write_unlock_irq+0x17/0x40
Aug 27 09:50:28 ac4tv kernel: [  124.279898]  [<ffffffff811bb445>]
do_vfs_ioctl+0x295/0x480
Aug 27 09:50:28 ac4tv kernel: [  124.279905]  [<ffffffff811c5189>] ?
__fget+0x79/0xb0
Aug 27 09:50:28 ac4tv kernel: [  124.279910]  [<ffffffff811bb67c>]
SyS_ioctl+0x4c/0x90
Aug 27 09:50:28 ac4tv kernel: [  124.279914]  [<ffffffff8115cf23>] ?
context_tracking_user_enter+0x13/0x20
Aug 27 09:50:28 ac4tv kernel: [  124.279917]  [<ffffffff8105c055>] ?
syscall_trace_leave+0xa5/0x140
Aug 27 09:50:28 ac4tv kernel: [  124.279919]  [<ffffffff8178b657>]
entry_SYSCALL_64_fastpath+0x12/0x6a
Aug 27 09:50:28 ac4tv kernel: [  124.477786] kvm: zapping shadow
pages for mmio generation wraparound
Aug 27 09:50:31 ac4tv kernel: [  127.177303] BUG: scheduling while
atomic: qemu-system-x86/1788/0x00000002
Aug 27 09:50:31 ac4tv kernel: [  127.177309] Modules linked in:
Aug 27 09:50:31 ac4tv kernel: [  127.177317] BUG: scheduling while
atomic: qemu-system-x86/1790/0x00000002
Aug 27 09:50:31 ac4tv kernel: [  127.177318]  psmouse i2c_piix4
asus_atk0110 microcode k10temp
Aug 27 09:50:31 ac4tv kernel: [  127.177332] Preemption disabled at:
Aug 27 09:50:31 ac4tv kernel: [  127.177334] Modules linked in:
psmouse i2c_piix4 asus_atk0110 microcode k10temp
Aug 27 09:50:31 ac4tv kernel: [  127.177341] Preemption disabled
at:[<ffffffff8100787c>] kvm_vcpu_ioctl+0x7c/0x580
 etc, etc.

I have not _noticed_ these messages on -rc8, but for the moment I am
inclined to treat them as another sign of the same problem.  Which
means a fresh bisection.  <sigh/>

ĸen
-- 
This one goes up to eleven: but only on a clear day, with the wind in
the right direction.
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

[toc] | [next] | [standalone]

#1214708

On Thu, Aug 27, 2015 at 12:59:14PM +0100, Ken Moffat wrote:
> On Tue, Aug 25, 2015 at 12:40:15AM +0100, Ken Moffat wrote:
> > (Cc'ing qemu-devel, please keep me in the Cc).
> > 
> > TL;DR - qemu locks up my machine when I use 4.2-rc kernels.
> > 
> Previous mail, or at least the copy to qemu, archived at
> https://lists.gnu.org/archive/html/qemu-devel/2015-08/msg02784.html
> 
> I started bisecting, but it is going to be a slow business - kernels
> which seem to be ok after e.g. 3 hours can still lock the box.  I
> left it running overnight, and this morning it was still up - but
> firefox could no longer connect externally.  I eventually tracked
> that to my logs taking the space.  But one reason the logs had
> become so big was the following (found from this morning's restart):
> 
> Aug 27 09:50:28 ac4tv kernel: [  124.279813] BUG: scheduling while
> atomic: qemu-system-x86/1789/0x00000002
> Aug 27 09:50:28 ac4tv kernel: [  124.279819] Modules linked in:
> psmouse i2c_piix4 asus_atk0110 microcode k10temp
> Aug 27 09:50:28 ac4tv kernel: [  124.279828] Preemption disabled
> at:[<ffffffff8100787c>] kvm_vcpu_ioctl+0x7c/0x580

This is definitely a *different* bug - I just tried the next kernel,
and started to get these messages (almost 100,000 lines of them in
the next 4 minutes) : if that had been happening a couple of weeks
ago, I would have noticed ;-)

But, the end result is that I cannot attempt to bisect the lockups,
this scheduling while atomic business is preventing me looking for a
good kernel.

Has anybody had success qith qemu on an x86_64 host running a 4.2-rc
kernel ?  Looks as if I'll have to give up, and hope that the main
problem doe not spread to 4.1.

ĸen
-- 
This one goes up to eleven: but only on a clear day, with the wind in
the right direction.
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

[toc] | [prev] | [next] | [standalone]

#1215073

On Thu, Aug 27, 2015 at 05:52:58PM +0100, Ken Moffat wrote:
> On Thu, Aug 27, 2015 at 12:59:14PM +0100, Ken Moffat wrote:
> > On Tue, Aug 25, 2015 at 12:40:15AM +0100, Ken Moffat wrote:
> > > (Cc'ing qemu-devel, please keep me in the Cc).
> > > 
> > > TL;DR - qemu locks up my machine when I use 4.2-rc kernels.
> > > 
> > Previous mail, or at least the copy to qemu, archived at
> > https://lists.gnu.org/archive/html/qemu-devel/2015-08/msg02784.html
> > 
> > I started bisecting, but it is going to be a slow business - kernels
> > which seem to be ok after e.g. 3 hours can still lock the box.  I
> > left it running overnight, and this morning it was still up - but
> > firefox could no longer connect externally.  I eventually tracked
> > that to my logs taking the space.  But one reason the logs had
> > become so big was the following (found from this morning's restart):
> > 
> > Aug 27 09:50:28 ac4tv kernel: [  124.279813] BUG: scheduling while
> > atomic: qemu-system-x86/1789/0x00000002
> > Aug 27 09:50:28 ac4tv kernel: [  124.279819] Modules linked in:
> > psmouse i2c_piix4 asus_atk0110 microcode k10temp
> > Aug 27 09:50:28 ac4tv kernel: [  124.279828] Preemption disabled
> > at:[<ffffffff8100787c>] kvm_vcpu_ioctl+0x7c/0x580
> 
> This is definitely a *different* bug - I just tried the next kernel,
> and started to get these messages (almost 100,000 lines of them in
> the next 4 minutes) : if that had been happening a couple of weeks
> ago, I would have noticed ;-)
> 
> But, the end result is that I cannot attempt to bisect the lockups,
> this scheduling while atomic business is preventing me looking for a
> good kernel.
> 
> Has anybody had success qith qemu on an x86_64 host running a 4.2-rc
> kernel ?  Looks as if I'll have to give up, and hope that the main
> problem doe not spread to 4.1.
> 
What will (hopefully) be my last comment on this - I went back to
4.1.3 on the host, and after a couple of hours it locked up.  Maybe
in the past I have jsut been lucky.  I think in future I'll probably
stick to native builds., it seems to be less painful.

ĸen
-- 
Il Porcupino Nil Sodomy Est! (if you will excuse my latatian)
  aka "The hedgehog song"
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

[toc] | [prev] | [standalone]

Back to top | Article view | linux.kernel

csiph-web