search for: blk_queue_max_segments

...ernel.dk> > Date: Fri Nov 1 10:52:52 2013 -0600 > > virtio_blk: blk-mq support > > > BUG_ON(req->nr_phys_segments + 2 > vblk->sg_elems); > > > On probe, we do > /* We can handle whatever the host told us to handle. */ > blk_queue_max_segments(q, vblk->sg_elems-2); > > > To debug this, > maybe you can print out sg_elems at init time and when this fails, > to make sure some kind of memory corruption > does not change sg_elems after initialization? > > > Jens, how may we get more segments than blk_queue_ma...

...ernel.dk> > Date: Fri Nov 1 10:52:52 2013 -0600 > > virtio_blk: blk-mq support > > > BUG_ON(req->nr_phys_segments + 2 > vblk->sg_elems); > > > On probe, we do > /* We can handle whatever the host told us to handle. */ > blk_queue_max_segments(q, vblk->sg_elems-2); > > > To debug this, > maybe you can print out sg_elems at init time and when this fails, > to make sure some kind of memory corruption > does not change sg_elems after initialization? > > > Jens, how may we get more segments than blk_queue_ma...

...kernel.dk> > Date: Fri Nov 1 10:52:52 2013 -0600 > > virtio_blk: blk-mq support > > > BUG_ON(req->nr_phys_segments + 2 > vblk->sg_elems); > > > On probe, we do > /* We can handle whatever the host told us to handle. */ > blk_queue_max_segments(q, vblk->sg_elems-2); > > > To debug this, > maybe you can print out sg_elems at init time and when this fails, > to make sure some kind of memory corruption > does not change sg_elems after initialization? > > > Jens, how may we get more segments than blk_queue_max_se...

...kernel.dk> > Date: Fri Nov 1 10:52:52 2013 -0600 > > virtio_blk: blk-mq support > > > BUG_ON(req->nr_phys_segments + 2 > vblk->sg_elems); > > > On probe, we do > /* We can handle whatever the host told us to handle. */ > blk_queue_max_segments(q, vblk->sg_elems-2); > > > To debug this, > maybe you can print out sg_elems at init time and when this fails, > to make sure some kind of memory corruption > does not change sg_elems after initialization? > > > Jens, how may we get more segments than blk_queue_max_se...

...t;vring.num); > + BUG_ON(total_sg > vq->vring.num && !vq->indirect); > > Shall I submit the patch or is a more elaborate fix required? This is wrong. It looks like the block layer is spending down more sg elements than we have ring entries, yet we tell it not to: blk_queue_max_segments(q, vblk->sg_elems-2); If you apply this patch, what happens? Here it prints: [ 0.616564] virtqueue elements = 128, max_segments = 126 (1 queues) [ 0.621244] vda: vda1 vda2 < vda5 > [ 0.632290] virtqueue elements = 128, max_segments = 126 (1 queues) [ 0.683526] vdb: vdb1 vd...

...52:52 2013 -0600 >> >> virtio_blk: blk-mq support >> >> >> BUG_ON(req->nr_phys_segments + 2 > vblk->sg_elems); >> >> >> On probe, we do >> /* We can handle whatever the host told us to handle. */ >> blk_queue_max_segments(q, vblk->sg_elems-2); >> >> >> To debug this, >> maybe you can print out sg_elems at init time and when this fails, >> to make sure some kind of memory corruption >> does not change sg_elems after initialization? >> >> >> Jens, how may we get...

Hi, I'm hitting this bug with both ext4 and btrfs. Here's an example of the backtrace: https://gist.github.com/vzctl/e888a821333979120932 I tried raising this BUG only for direct ring and it solved the problem: - BUG_ON(total_sg > vq->vring.num); + BUG_ON(total_sg > vq->vring.num && !vq->indirect); Shall I submit the patch or is a more elaborate fix

Hi, I'm hitting this bug with both ext4 and btrfs. Here's an example of the backtrace: https://gist.github.com/vzctl/e888a821333979120932 I tried raising this BUG only for direct ring and it solved the problem: - BUG_ON(total_sg > vq->vring.num); + BUG_ON(total_sg > vq->vring.num && !vq->indirect); Shall I submit the patch or is a more elaborate fix

...-------- >> [ 64.670008] kernel BUG at drivers/block/virtio_blk.c:172! > > Hmm, that's: > > BUG_ON(req->nr_phys_segments + 2 > vblk->sg_elems); > > But during our probe routine we said: > > /* We 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. -- Jens Axboe

...-------- >> [ 64.670008] kernel BUG at drivers/block/virtio_blk.c:172! > > Hmm, that's: > > BUG_ON(req->nr_phys_segments + 2 > vblk->sg_elems); > > But during our probe routine we said: > > /* We 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. -- Jens Axboe

...big, truncate with warning. */ - if ((sector_t)cap != cap) { - dev_warn(&vdev->dev, "Capacity %llu too large: truncating\n", - (unsigned long long)cap); - cap = (sector_t)-1; - } - set_capacity(vblk->disk, cap); - /* We can handle whatever the host told us to handle. */ blk_queue_max_segments(q, vblk->sg_elems-2); @@ -780,6 +777,7 @@ static int virtblk_probe(struct virtio_device *vdev) if (!err && opt_io_size) blk_queue_io_opt(q, blk_size * opt_io_size); + virtblk_update_capacity(vblk, false); virtio_device_ready(vdev); device_add_disk(&vdev->dev, vblk-&...

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! [ 64.670008] invalid opcode: 0000 [#1] SMP [ 64.670008] Modules linked in: xfs libcrc32c snd_hda_codec_generic snd_hda_intel snd_hda_controller

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! [ 64.670008] invalid opcode: 0000 [#1] SMP [ 64.670008] Modules linked in: xfs libcrc32c snd_hda_codec_generic snd_hda_intel snd_hda_controller

Hi, For virtio block device, actually there is no a hard limit for max request size, and virtio_blk driver set -1 to blk_queue_max_hw_sectors(q, -1U);. But it doesn't work, because there is a default upper limitation BLK_DEF_MAX_SECTORS (1280 sectors). So this series want to add a new helper blk_queue_max_hw_sectors_no_limit to set a proper max reqeust size. Weiping Zhang (2): blk-setting:

Hi, For virtio block device, actually there is no a hard limit for max request size, and virtio_blk driver set -1 to blk_queue_max_hw_sectors(q, -1U);. But it doesn't work, because there is a default upper limitation BLK_DEF_MAX_SECTORS (1280 sectors). So this series want to add a new helper blk_queue_max_hw_sectors_no_limit to set a proper max reqeust size. Weiping Zhang (2): blk-setting:

...ge_kb) + return -EINVAL; + + return param_set_uint(val, kp); +} + static inline blk_status_t virtblk_result(struct virtblk_req *vbr) { switch (vbr->status) { @@ -730,8 +758,8 @@ static int virtblk_probe(struct virtio_device *vdev) /* We can handle whatever the host told us to handle. */ blk_queue_max_segments(q, vblk->sg_elems-2); - /* No real sector limit. */ - blk_queue_max_hw_sectors(q, -1U); + /* No real sector limit, use 512b (max_request_size << 10) >> 9 */ + blk_queue_max_hw_sectors_no_limit(q, max_request_size << 1); /* Host can optionally specify maximum segment size...

...o_blk.c:172! >> >> >> Hmm, that's: >> >> BUG_ON(req->nr_phys_segments + 2 > vblk->sg_elems); >> >> But during our probe routine we said: >> >> /* We 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=141562191...

...; [ 64.669633] ------------[ cut here ]------------ > [ 64.670008] kernel BUG at drivers/block/virtio_blk.c:172! Hmm, that's: BUG_ON(req->nr_phys_segments + 2 > vblk->sg_elems); But during our probe routine we said: /* We can handle whatever the host told us to handle. */ blk_queue_max_segments(q, vblk->sg_elems-2); Jens? Thanks, Rusty. > [ 64.670008] invalid opcode: 0000 [#1] SMP > [ 64.670008] Modules linked in: xfs libcrc32c snd_hda_codec_generic snd_hda_intel snd_hda_controller snd_hda_codec snd_hwdep snd_seq snd_seq_device snd_pcm ppdev snd_timer snd virtio_net virti...

Hi, I have a virtual machine which fails to boot linux-4.1.8 while mounting file systems: > * Mounting local filesystem ... > ------------[ cut here ]------------ > kernel BUG at drivers/block/virtio_blk.c:172! > invalid opcode: 000 [#1] SMP > Modules linked in: pcspkr psmouse dm_log_userspace virtio_net e1000 fuse nfs lockd grace sunrpc fscache dm_snapshot dm_bufio dm_mirror

Hi, I have a virtual machine which fails to boot linux-4.1.8 while mounting file systems: > * Mounting local filesystem ... > ------------[ cut here ]------------ > kernel BUG at drivers/block/virtio_blk.c:172! > invalid opcode: 000 [#1] SMP > Modules linked in: pcspkr psmouse dm_log_userspace virtio_net e1000 fuse nfs lockd grace sunrpc fscache dm_snapshot dm_bufio dm_mirror