> > However, this just revealed an underlying problem. The block numbers were
> > ridiculous, but the buffer size was just 512 bytes. There is probably
> > an overflow in there somewhere for the "blk * DEV_BSIZE" offset passed
> > to vn_rdwr.
> > 
> > 4294967296 is 2^32, so DEV_BSIZE * blk = 2^9 * 2^32 = 2^41, which should
> > still fit.
> 
> Jachym,
> 
> Do you still want the requested output, with Frank fix removed, to
> track the underlying problem ?

The relevant part of the output is (reformatted for readability):

======
vn_rdwr: len 512 offset 2199023255552
spec_read: bn 4294967296 bsize 2048
bio_doread: blkno 4294967296 size 2048
sdstrategy: blk 4294967296 bcount 2048
scsipi_execute_xs: xs(0xffff80000f124000):
	xs_control(0x00021009)
	xs_status(0x00000000)
	periph(0xffff80001144d300)
	retr(0x4)
	timo(0xea60)
	cmd(0xffff80000f1240c4)
	len(0x10)
	data(0xffff80001ce80000)
	len(0x1773aa00)
	res(0x1773aa00)
	err(0x0)
	bp(0xffff80000f12a170)
sd0(mpt1:0:1:0):  command: 0x88,0x0,0x0,0x0,0x0,0x1,0x0,0x0,0x0,0x0,0x0,0xb,0xb9,0xd5,0x0,0x0-[393456128 bytes]
------------------------------
000: ef be ad de 00 00 00 00 00 08 e8 1c 00 80 ff ff 
016: 88 20 d1 0e 00 80 ff ff 00 00 00 00 00 00 00 00 
032: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 
048: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 
------------------------------
======

It seems like (long)b_bcount got screwed when passed to scsipi_make_xs()
as (int) (implicit cast). I don't understand if this can really be a
problem though.

Hopefully, someone with more clue about amd64 can make sense from this...

	Regards,
		-- Jachym Holecek