search for: blk_recount_seg

...m the > run with your patch. > > I am using libvirt (virt-manager) to configure and run the virtual > machine, but looking at the xml, I do not think it's passing > 'scsi=off' at all. > > Btw, that xfs file system is a root file system. > > > [ 3.667553] blk_recount_segments: 1-0-1 vcnt-0 segs-128 > [ 3.668692] blk_recount_segments: 1-0-1 vcnt-0 segs-128 > [ 3.669897] blk_recount_segments: 1-0-1 vcnt-0 segs-128 > [ 3.671083] blk_recount_segments: 1-0-1 vcnt-0 segs-128 Hamm, I should have used bi_phys_segments to decide if merge is needed, and at...

...m the > run with your patch. > > I am using libvirt (virt-manager) to configure and run the virtual > machine, but looking at the xml, I do not think it's passing > 'scsi=off' at all. > > Btw, that xfs file system is a root file system. > > > [ 3.667553] blk_recount_segments: 1-0-1 vcnt-0 segs-128 > [ 3.668692] blk_recount_segments: 1-0-1 vcnt-0 segs-128 > [ 3.669897] blk_recount_segments: 1-0-1 vcnt-0 segs-128 > [ 3.671083] blk_recount_segments: 1-0-1 vcnt-0 segs-128 Hamm, I should have used bi_phys_segments to decide if merge is needed, and at...

On Thu, Oct 30, 2014 at 10:38 PM, Jens Axboe <axboe at kernel.dk> wrote: > Forgot to CC you... > > > -------- Forwarded Message -------- > Subject: Re: kernel BUG at drivers/block/virtio_blk.c:172 > Date: Thu, 30 Oct 2014 08:38:08 -0600 > From: Jens Axboe <axboe at kernel.dk> > To: Luk?? Czerner <lczerner at redhat.com>, > virtualization at

On Thu, Oct 30, 2014 at 10:38 PM, Jens Axboe <axboe at kernel.dk> wrote: > Forgot to CC you... > > > -------- Forwarded Message -------- > Subject: Re: kernel BUG at drivers/block/virtio_blk.c:172 > Date: Thu, 30 Oct 2014 08:38:08 -0600 > From: Jens Axboe <axboe at kernel.dk> > To: Luk?? Czerner <lczerner at redhat.com>, > virtualization at

...bug, by coincidence, during testing other things. Try to run xfstests/generic/034. You'll see the crash immediately. Tested on a QEMU VM with kernel 3.18-rc4, virtio-blk, dm-flakey and xfs. > There is one obvious bug which should have been fixed by below > patch(0001-block-blk-merge-fix-blk_recount_segments.patch"): > > http://marc.info/?l=linux-virtualization&m=141562191719405&q=p3 This patch didn't bring anything to me, as Lukas said. > And there might be another one, I appreciate someone can post > log which is printed by patch("blk-seg.patch") in belo...

...bug, by coincidence, during testing other things. Try to run xfstests/generic/034. You'll see the crash immediately. Tested on a QEMU VM with kernel 3.18-rc4, virtio-blk, dm-flakey and xfs. > There is one obvious bug which should have been fixed by below > patch(0001-block-blk-merge-fix-blk_recount_segments.patch"): > > http://marc.info/?l=linux-virtualization&m=141562191719405&q=p3 This patch didn't bring anything to me, as Lukas said. > And there might be another one, I appreciate someone can post > log which is printed by patch("blk-seg.patch") in belo...

...; > I am using libvirt (virt-manager) to configure and run the virtual > > machine, but looking at the xml, I do not think it's passing > > 'scsi=off' at all. > > > > Btw, that xfs file system is a root file system. > > > > > > [ 3.667553] blk_recount_segments: 1-0-1 vcnt-0 segs-128 > > [ 3.668692] blk_recount_segments: 1-0-1 vcnt-0 segs-128 > > [ 3.669897] blk_recount_segments: 1-0-1 vcnt-0 segs-128 > > [ 3.671083] blk_recount_segments: 1-0-1 vcnt-0 segs-128 > > Hamm, I should have used bi_phys_segments to decide i...

...g testing other things. > > Try to run xfstests/generic/034. You'll see the crash immediately. > Tested on a QEMU VM with kernel 3.18-rc4, virtio-blk, dm-flakey and xfs. > >> There is one obvious bug which should have been fixed by below >> patch(0001-block-blk-merge-fix-blk_recount_segments.patch"): >> >> http://marc.info/?l=linux-virtualization&m=141562191719405&q=p3 > > This patch didn't bring anything to me, as Lukas said. > >> And there might be another one, I appreciate someone can post >> log which is printed by patch("...

On 2014-11-10 02:59, Rusty Russell wrote: > Jeff Layton <jlayton at poochiereds.net> writes: > >> In the latest Fedora rawhide kernel in the repos, I'm seeing the >> following oops when mounting xfs. rc2-ish kernels seem to be fine: >> >> [ 64.669633] ------------[ cut here ]------------ >> [ 64.670008] kernel BUG at drivers/block/virtio_blk.c:172!

On 2014-11-10 02:59, Rusty Russell wrote: > Jeff Layton <jlayton at poochiereds.net> writes: > >> In the latest Fedora rawhide kernel in the repos, I'm seeing the >> following oops when mounting xfs. rc2-ish kernels seem to be fine: >> >> [ 64.669633] ------------[ cut here ]------------ >> [ 64.670008] kernel BUG at drivers/block/virtio_blk.c:172!

...red it again on 3.17.0-rc4. This output is from the run with your patch. I am using libvirt (virt-manager) to configure and run the virtual machine, but looking at the xml, I do not think it's passing 'scsi=off' at all. Btw, that xfs file system is a root file system. [ 3.667553] blk_recount_segments: 1-0-1 vcnt-0 segs-128 [ 3.668692] blk_recount_segments: 1-0-1 vcnt-0 segs-128 [ 3.669897] blk_recount_segments: 1-0-1 vcnt-0 segs-128 [ 3.671083] blk_recount_segments: 1-0-1 vcnt-0 segs-128 [ 3.672476] ------------[ cut here ]------------ [ 3.673439] kernel BUG at drivers/block...

Hi, I've just hit this BUG at drivers/block/virtio_blk.c when updated to the kernel from the top of the Linus git tree. commit a7ca10f263d7e673c74d8e0946d6b9993405cc9c This is my virtual machine running on RHEL7 guest qemu-kvm-1.5.3-60.el7.x86_64 The last upstream kernel (3.17.0-rc4) worked well. I'll try to bisect, but meanwhile this is a backtrace I got very early in the boot. The

Hi, I've just hit this BUG at drivers/block/virtio_blk.c when updated to the kernel from the top of the Linus git tree. commit a7ca10f263d7e673c74d8e0946d6b9993405cc9c This is my virtual machine running on RHEL7 guest qemu-kvm-1.5.3-60.el7.x86_64 The last upstream kernel (3.17.0-rc4) worked well. I'll try to bisect, but meanwhile this is a backtrace I got very early in the boot. The

...e can handle whatever the host told us to handle. */ >> blk_queue_max_segments(q, vblk->sg_elems-2); >> >> Jens? > > > Known, I'm afraid, Ming is looking into it. There is one obvious bug which should have been fixed by below patch(0001-block-blk-merge-fix-blk_recount_segments.patch"): http://marc.info/?l=linux-virtualization&m=141562191719405&q=p3 And there might be another one, I appreciate someone can post log which is printed by patch("blk-seg.patch") in below link if the bug still can be triggered even with above fix: http://marc.info/...

On 11/11/2014 09:42 AM, Ming Lei wrote: > The attached patch should fix the problem, and hope it is the last one, :-) Dongsu and Jeff, any of you test this variant? I think this is the last one, at least I hope so as well... -- Jens Axboe

On 11/11/2014 09:42 AM, Ming Lei wrote: > The attached patch should fix the problem, and hope it is the last one, :-) Dongsu and Jeff, any of you test this variant? I think this is the last one, at least I hope so as well... -- Jens Axboe

With the ATI bug I was hitting earlier fixed, only my btrfs partition continues to show high cpu usage for some operations. Rsync, git pull, git checkout and svn up are typicall operations which trigger the high cpu usage. As an example, this perf report is from using git checkout to change to a new branch; the change needed to checkout 208 files out of about 1600 total files. du(1) reports

...ze; return nr_phys_segs; } void blk_recalc_rq_segments(struct request *rq) { - rq->nr_phys_segments = __blk_recalc_rq_segments(rq->q, rq->bio); + struct request_queue *q = rq->queue_ctx->queue; + + rq->nr_phys_segments = __blk_recalc_rq_segments(q, rq->bio); } void blk_recount_segments(struct request_queue *q, struct bio *bio) { struct bio *nxt = bio->bi_next; bio->bi_next = NULL; bio->bi_phys_segments = __blk_recalc_rq_segments(q, bio); bio->bi_next = nxt; @@ -108,21 +110,21 @@ static int blk_phys_contig_segment(struct request_queue *q, struct bio *bi...

...ze; return nr_phys_segs; } void blk_recalc_rq_segments(struct request *rq) { - rq->nr_phys_segments = __blk_recalc_rq_segments(rq->q, rq->bio); + struct request_queue *q = rq->queue_ctx->queue; + + rq->nr_phys_segments = __blk_recalc_rq_segments(q, rq->bio); } void blk_recount_segments(struct request_queue *q, struct bio *bio) { struct bio *nxt = bio->bi_next; bio->bi_next = NULL; bio->bi_phys_segments = __blk_recalc_rq_segments(q, bio); bio->bi_next = nxt; @@ -108,21 +110,21 @@ static int blk_phys_contig_segment(struct request_queue *q, struct bio *bi...