On Mon, 2008-08-25 at 12:35 -0700, Jeremy Fitzhardinge wrote:
quoted text
> I haven't see this oops before, but I think the code in question
> correlates to:
>=20
> 	bret =3D RING_GET_RESPONSE(&info->ring, i);
> 	id   =3D bret->id;
> 	req  =3D (struct request *)info->shadow[id].request;
>=20
> which suggests the backend driver is passing back a bogus request ID.
>=20
> What's your host environment?

I believe it's a 64 bit Etch kernel running on a Lenny domain 0. I
wonder if that kernel doesn't write the protocol field in xenstore so
the 64 bit backend Sally-Anne is using cannot talk to the 32 bit
frontend correctly.

Sally, can you run xenstore-ls on the domain's path
(/local/domain/<domid>). Is there a protocol field in the vbd entry?
If not can you try starting the domain in the paused state (xm create
-p) and use xenstore-write to fill in the protocol node in the frontend
to "x86_32-abi". e.g.
        xenstore write /local/domain/<domid>/device/vbd/<nr>/protocol x86_3=
2-abi
before unpausing.

I thought the tools did this (so expected the Lenny tools to be correct)
but looking at the code it seems it is the domain 0 kernel which does
it.

Ian.

--=20
Ian Campbell

Success is getting what you want; happiness is wanting what you get.