--WIyZ46R2i8wDzkSu
Content-Type: text/plain; charset=us-ascii
Content-Disposition: inline
Content-Transfer-Encoding: quoted-printable

On Sat, Feb 24, 2007 at 10:10:10PM +0100, Manuel Bouyer wrote:
> OK, I found some time to look at this again. After several unsucessfull
> experiements I ended up looking at the xen sources, and found that the
> minimum allowed "address_bits" is hardcoded to 31 (2GB). So with a stock
> Xen kernel it's not possible to get bce working reliably under Xen :(
> (This value seems to come from a restriction on aac devices, from what I
> found in comments).

huh.  wow.  Thanks for the effort.  I'm confused why it works with
dom0_mem=3D256m, then - especially as (the way I understand it) dom0
starts at the top of physical ram, out of the way of all these
allocations.

> I you want to run Xen on this system I should be able to build a xen kern=
el
> which allows "address_bits" to be 30 instead of 31.=20

That would be great; if it's not too hacky is this something worth
feeding back to the xen folks?  iiuc, bce(4) is not the only device
with the 1gb dma limit; i think there's at least some wireless device
with the same limit.

It also sounds like there's an error reporting problem, in that
requests below this cap are silently treated as if they were for 31,
rather than failing or generating some kind of warning.  Perhaps Xen
ought to fix at least that.

> It's not possible to fix it to allow any value for address_bits
> without rewriting the Xen memory allocator :(

well, if it works for 30, we can defer worrying about other values
until we ever find an even lamer device than bce.

--
Dan.
--WIyZ46R2i8wDzkSu
Content-Type: application/pgp-signature
Content-Disposition: inline

-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.6 (NetBSD)

iD8DBQFF40sgEAVxvV4N66cRAob9AKCPiHMxPLMtq8dEz3/X8U5B4gF1CwCfRONJ
uumpvkCxvYSrqyAyU36j6YY=
=zY/+
-----END PGP SIGNATURE-----

--WIyZ46R2i8wDzkSu--