From: OGAWA Hirofumi <hirofumi@mail.parknet.co.jp>
To: "Randy.Dunlap" <rddunlap@osdl.org>
Cc: elgaard@agol.dk, linux-kernel@vger.kernel.org
Subject: Re: Problem loopmounting CD on 2.6.0
Date: Mon, 22 Dec 2003 23:27:09 +0900 [thread overview]
Message-ID: <873cbdrkqq.fsf@devron.myhome.or.jp> (raw)
In-Reply-To: <20031219140029.346f2523.rddunlap@osdl.org>
"Randy.Dunlap" <rddunlap@osdl.org> writes:
> On Fri, 19 Dec 2003 14:10:44 +0100 Niels Elgaard Larsen <elgaard@agol.dk> wrote:
>
> | A similar (probably the same) problem have been reported for cryptoloop.
> | With a ISO9660 CD (actually Knoppix) in drive /dev/hdc, no SCSI emulation:
> |
> | amigos20:/mnt# losetup /dev/loop5 /dev/hdc
> | amigos20:/mnt# mount -r /dev/loop5 /mnt/foo
> |
> | Gives kernel output:
> |
> | ===
> | hdc: cdrom_read_intr: data underrun (2 blocks)
> | end_request: I/O error, dev hdc, sector 64
> | isofs_fill_super: bread failed, dev=loop5, iso_blknum=16, block=32
> | ===
> |
> | It works in 2.4.20
> |
> | Also
> |
> | dd if=/dev/hdc of=/tmp/foo
> | losetup /dev/loop5 /tmp/foo
> | mount -r /dev/loop5 /mnt/foo
> |
> | works
>
> I see differing sector size and block size reports by blockdev
> as follows. Is this OK/expected or does it hint at a problem?
Probably we need to set the hardsect_size of real device to loop.
At least, it seems this problem was fixed.
What do you think of the following patch?
drivers/block/loop.c | 1 +
1 files changed, 1 insertion(+)
diff -puN drivers/block/loop.c~loop-fix-hardsect_size drivers/block/loop.c
--- linux-2.6.0/drivers/block/loop.c~loop-fix-hardsect_size 2003-12-22 22:36:50.000000000 +0900
+++ linux-2.6.0-hirofumi/drivers/block/loop.c 2003-12-22 22:37:19.000000000 +0900
@@ -752,6 +752,7 @@ static int loop_set_fd(struct loop_devic
blk_queue_max_sectors(lo->lo_queue, q->max_sectors);
blk_queue_max_phys_segments(lo->lo_queue,q->max_phys_segments);
blk_queue_max_hw_segments(lo->lo_queue, q->max_hw_segments);
+ blk_queue_hardsect_size(lo->lo_queue, queue_hardsect_size(q));
blk_queue_max_segment_size(lo->lo_queue, q->max_segment_size);
blk_queue_segment_boundary(lo->lo_queue, q->seg_boundary_mask);
blk_queue_merge_bvec(lo->lo_queue, q->merge_bvec_fn);
_
--
OGAWA Hirofumi <hirofumi@mail.parknet.co.jp>
prev parent reply other threads:[~2003-12-22 14:28 UTC|newest]
Thread overview: 3+ messages / expand[flat|nested] mbox.gz Atom feed top
2003-12-19 13:10 Problem loopmounting CD on 2.6.0 Niels Elgaard Larsen
2003-12-19 22:00 ` Randy.Dunlap
2003-12-22 14:27 ` OGAWA Hirofumi [this message]
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=873cbdrkqq.fsf@devron.myhome.or.jp \
--to=hirofumi@mail.parknet.co.jp \
--cc=elgaard@agol.dk \
--cc=linux-kernel@vger.kernel.org \
--cc=rddunlap@osdl.org \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.