> > Like this:
> > 
> > 	printf("datalen %d mapsize %llu first page at %llx\n",
> > 	    xs->datalen, (unsigned long long)req->dmap->dm_mapsize,
> > 	    vtophys(xs->data));
> > 
> > ..and see what that says? If the datalen is <= the mapsize, then there
> > might be something wrong with the bounce code. Also, the first physical
> > address of the data might tell us if it is a problem with the bounce
> > code or not.
> 
> Here are the first 2 values :
> 
> datalen 393456128 mapsize 0
> mpt1: error 22 loading DMA map
> sd0(mpt1:0:1:0): generic HBA error
> findroot: unable to read block 4294967296
> 
> For the first page adress, i'm getting a warning i 'm unable to fix :-(

The error seems to be coming from SCISIPI layer or above (ie. the mpt(4)
driver is probably not the culprit) -- kernel with:

	options SCSIPI_DEBUG

could give more info. Unfortunately, I don't have an mpt device to try
myself... Additionally, if you have another NetBSD machine to play with,
the following patch should help you track who is enqueing the oversized
transfer (in sys/dev/scsipi/):

--- scsipi_base.c       7 Dec 2004 23:14:03 -0000       1.123
+++ scsipi_base.c       4 Feb 2005 18:25:05 -0000
@@ -1720,6 +1720,9 @@
 
	s = splbio();
	  
+	if (xs->datalen > MAXPHYS)
+		panic("scsipi: suspicious xfer length");
+
	/*
	 * If the xfer is to be polled, and there are already jobs on
	 * the queue, we can't proceed.

If you are going to try this, make sure you are running a kernel with ddb
enabled and when the panic gets hit, please copy the backtrace ("db> bt")
and send it here (ok, it clearly falls off in findroot(), but seeing the
intermediate calls might be of use).

	Hope this helps,
		-- Jachym Holecek