similar to: blk-mq crash under KVM in multiqueue block code (with virtio-blk and ext4)

On 09/12/2014 01:54 PM, Ming Lei wrote: > On Thu, Sep 11, 2014 at 6:26 PM, Christian Borntraeger > <borntraeger at de.ibm.com> wrote: >> Folks, >> >> we have seen the following bug with 3.16 as a KVM guest. It suspect the blk-mq rework that happened between 3.15 and 3.16, but it can be something completely different. >> > > Care to share how you reproduce

On 09/12/2014 01:54 PM, Ming Lei wrote: > On Thu, Sep 11, 2014 at 6:26 PM, Christian Borntraeger > <borntraeger at de.ibm.com> wrote: >> Folks, >> >> we have seen the following bug with 3.16 as a KVM guest. It suspect the blk-mq rework that happened between 3.15 and 3.16, but it can be something completely different. >> > > Care to share how you reproduce

On Thu, Sep 11, 2014 at 6:26 PM, Christian Borntraeger <borntraeger at de.ibm.com> wrote: > Folks, > > we have seen the following bug with 3.16 as a KVM guest. It suspect the blk-mq rework that happened between 3.15 and 3.16, but it can be something completely different. > Care to share how you reproduce the issue? > [ 65.992022] Unable to handle kernel pointer dereference

On 09/12/2014 10:09 PM, Christian Borntraeger wrote: > On 09/12/2014 01:54 PM, Ming Lei wrote: >> On Thu, Sep 11, 2014 at 6:26 PM, Christian Borntraeger >> <borntraeger at de.ibm.com> wrote: >>> Folks, >>> >>> we have seen the following bug with 3.16 as a KVM guest. It suspect the blk-mq rework that happened between 3.15 and 3.16, but it can be

> >>> Does anyone have an idea? > >>> The request itself is completely filled with cc > >> > >> That is very weird, the 'rq' is got from hctx->tags, and rq should be > >> valid, and rq->q shouldn't have been changed even though it was > >> double free or double allocation. > >> > >>> I am currently

> >>> Does anyone have an idea? > >>> The request itself is completely filled with cc > >> > >> That is very weird, the 'rq' is got from hctx->tags, and rq should be > >> valid, and rq->q shouldn't have been changed even though it was > >> double free or double allocation. > >> > >>> I am currently

Avi, this fixes a problem that was introduced by the virtio_reset patches. Can you apply that fix to kvm.git as a bugfix, as the virtio_reset infrastructure is not on Linus upstream yet? Anthony, Dor, are you ok with that change? -- With the latest virtio_reset patches I got the following oops: Unable to handle kernel pointer dereference at virtual kernel address 0000000000000000 Oops: 0004

Avi, this fixes a problem that was introduced by the virtio_reset patches. Can you apply that fix to kvm.git as a bugfix, as the virtio_reset infrastructure is not on Linus upstream yet? Anthony, Dor, are you ok with that change? -- With the latest virtio_reset patches I got the following oops: Unable to handle kernel pointer dereference at virtual kernel address 0000000000000000 Oops: 0004

Rusty, Anthony, Dor, I need your brain power :-) On smp guests I have seen a problem with virtio (the version in curent Avi's git) which do not occur on single processor guests: kernel BUG at /space/kvm/drivers/virtio/virtio_ring.c:228! illegal operation: 0001 [#1] Modules linked in: ipv6 CPU: 2 Not tainted Process swapper (pid: 0, task: 000000000f83e038, ksp: 000000000f877d70) Krnl

Rusty, Anthony, Dor, I need your brain power :-) On smp guests I have seen a problem with virtio (the version in curent Avi's git) which do not occur on single processor guests: kernel BUG at /space/kvm/drivers/virtio/virtio_ring.c:228! illegal operation: 0001 [#1] Modules linked in: ipv6 CPU: 2 Not tainted Process swapper (pid: 0, task: 000000000f83e038, ksp: 000000000f877d70) Krnl

On 2014-09-17 07:52, Ming Lei wrote: > On Wed, 17 Sep 2014 14:00:34 +0200 > David Hildenbrand <dahi at linux.vnet.ibm.com> wrote: > >>>>>> Does anyone have an idea? >>>>>> The request itself is completely filled with cc >>>>> >>>>> That is very weird, the 'rq' is got from hctx->tags, and rq should be

On 2014-09-17 07:52, Ming Lei wrote: > On Wed, 17 Sep 2014 14:00:34 +0200 > David Hildenbrand <dahi at linux.vnet.ibm.com> wrote: > >>>>>> Does anyone have an idea? >>>>>> The request itself is completely filled with cc >>>>> >>>>> That is very weird, the 'rq' is got from hctx->tags, and rq should be

> On Wed, Sep 17, 2014 at 10:22 PM, Jens Axboe <axboe at kernel.dk> wrote: > > > > Another way would be to ensure that the timeout handler doesn't touch hw_ctx > > or tag_sets that aren't fully initialized yet. But I think this is > > safer/cleaner. > > That may not be easy or enough to check if hw_ctx/tag_sets are > fully initialized if you mean

> On Wed, Sep 17, 2014 at 10:22 PM, Jens Axboe <axboe at kernel.dk> wrote: > > > > Another way would be to ensure that the timeout handler doesn't touch hw_ctx > > or tag_sets that aren't fully initialized yet. But I think this is > > safer/cleaner. > > That may not be easy or enough to check if hw_ctx/tag_sets are > fully initialized if you mean

Hi all, with the recent kernel 3.19, I get a kernel warning when I start my KVM guest on s390 with virtio balloon enabled: [ 0.839687] do not call blocking ops when !TASK_RUNNING; state=1 set at [<0000000000174a1e>] prepare_to_wait_event+0x7e/0x108 [ 0.839694] ------------[ cut here ]------------ [ 0.839697] WARNING: at kernel/sched/core.c:7326 [ 0.839698]

Hi all, with the recent kernel 3.19, I get a kernel warning when I start my KVM guest on s390 with virtio balloon enabled: [ 0.839687] do not call blocking ops when !TASK_RUNNING; state=1 set at [<0000000000174a1e>] prepare_to_wait_event+0x7e/0x108 [ 0.839694] ------------[ cut here ]------------ [ 0.839697] WARNING: at kernel/sched/core.c:7326 [ 0.839698]

Hello all. I just updated my machine from 9-STABLE to 10-Stable today. beasty ~ # uname -a FreeBSD beasty.schavemaker2.local 10.0-BETA3 FreeBSD 10.0-BETA3 #0 r258543: Mon Nov 25 13:23:31 CET 2013 root at beasty.schavemaker2.local:/usr/obj/usr/src/sys/KRNL amd64 After a reboot, the console gets cluttered with a lot of messages. ata2: FAILURE - zero length DMA transfer attempted ata2: setting

There is a race in virtio_net, dealing with disabling/enabling the callback. I saw the following oops: kernel BUG at /space/kvm/drivers/virtio/virtio_ring.c:218! illegal operation: 0001 [#1] SMP Modules linked in: sunrpc dm_mod CPU: 2 Not tainted 2.6.25-rc1zlive-host-10623-gd358142-dirty #99 Process swapper (pid: 0, task: 000000000f85a610, ksp: 000000000f873c60) Krnl PSW : 0404300180000000

There is a race in virtio_net, dealing with disabling/enabling the callback. I saw the following oops: kernel BUG at /space/kvm/drivers/virtio/virtio_ring.c:218! illegal operation: 0001 [#1] SMP Modules linked in: sunrpc dm_mod CPU: 2 Not tainted 2.6.25-rc1zlive-host-10623-gd358142-dirty #99 Process swapper (pid: 0, task: 000000000f85a610, ksp: 000000000f873c60) Krnl PSW : 0404300180000000

Hello Developers, it seems that i discovered a bug in btrfs while testing it on a zSeries mainframe :-) ## Test environment: - IBM System z900 Mainframe - Debian SID with 64 Bit Kernel - GIT Sources from git://git.kernel.org/pub/scm/linux/kernel/git/mason/btrfs-unstable.git - System runs as z/VM guest - 3 Virtual CPUs - 1 GB RAM Storage ## Initial Test Setup - Setup a Debian SID System with