Displaying 20 results from an estimated 400 matches similar to: "blk-mq crash under KVM in multiqueue block code (with virtio-blk and ext4)"
2014 Sep 12
3
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
2014 Sep 12
3
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
2014 Sep 12
0
blk-mq crash under KVM in multiqueue block code (with virtio-blk and ext4)
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
2014 Sep 17
0
blk-mq crash under KVM in multiqueue block code (with virtio-blk and ext4)
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
2014 Sep 17
3
blk-mq crash under KVM in multiqueue block code (with virtio-blk and ext4)
> >>> 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
2014 Sep 17
3
blk-mq crash under KVM in multiqueue block code (with virtio-blk and ext4)
> >>> 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
2008 Feb 11
1
[PATCH] virtio_net: Fix oops on early interrupts - introduced by virtio reset code
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
2008 Feb 11
1
[PATCH] virtio_net: Fix oops on early interrupts - introduced by virtio reset code
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
2007 Dec 14
3
virtio_net and SMP guests
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
2007 Dec 14
3
virtio_net and SMP guests
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
2014 Sep 17
2
blk-mq crash under KVM in multiqueue block code (with virtio-blk and ext4)
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
2014 Sep 17
2
blk-mq crash under KVM in multiqueue block code (with virtio-blk and ext4)
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
2014 Sep 17
2
blk-mq crash under KVM in multiqueue block code (with virtio-blk and ext4)
> 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
2014 Sep 17
2
blk-mq crash under KVM in multiqueue block code (with virtio-blk and ext4)
> 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
2015 Feb 25
7
virtio balloon: do not call blocking ops when !TASK_RUNNING
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]
2015 Feb 25
7
virtio balloon: do not call blocking ops when !TASK_RUNNING
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]
2013 Nov 25
1
Lots of DMA messages on FreeBSD 10
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
2008 Mar 14
1
[PATCH] virtio_net/virtio_ring: fix race in enable_cb
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
2008 Mar 14
1
[PATCH] virtio_net/virtio_ring: fix race in enable_cb
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
2009 Feb 26
2
BUG: Mount/Unmount Loop
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