Re: [Xen-users] GPLPV under NetBSD dom0

[Dustin Marquess <dmarquess@xxxxxxxxx>]

On Thu, Oct 29, 2009 at 10:10 PM, James Harper
<james.harper@xxxxxxxxxxxxxxxx> wrote:
>> > Just as a test, and you'll have to be fast, as soon as you see
> 'Still
>> > waiting for 2 (currently 4)', manually set the backend state to 2,
> and
>> > then back to 4, eg:
>> >
>> > xenstore-write /local/domain/0/backend/vbd/<domid>/768 2
>> > xenstore-write /local/domain/0/backend/vbd/<domid>/768 4
>> >
>> > GPLPV expects to see the backend state go to 2 and then to 4, not
> direct
>> > to 4. I need to investigate that a bit more as it has caused
> problems
>> > before with other backends (tap:aio etc) before.
>> >
>> > If that works let me know and I'll see what I can do.
>>
>> I tried this a few times and ended up pulling my hair.  After some
>> poking around, I realized I needed to add "/state" to the path.
>
> Oops. Sorry :(

No biggie.  Gave me a chance to dig more into Xen :).

>> Once
>> I did that, surprise surprise... it worked!
>
>>
>> On an unrelated note... WinDbg is getting spammed with:
>>
>> XenNet     Error: rxrsp offset 16, size -1
>> XenNet     Error: rxrsp offset 16, size -1
>> XenNet     Error: rxrsp offset 16, size -1
>> XenNet     Error: rxrsp offset 16, size -1
>>
>> And my dom0 dmesg is getting spammed with:
>>
>> xvif18.1: req_prod 713 req_cons 466 rsp_prod 465 rsp_prod_pvt 465 i 1
>> xvif18.1 GNTTABOP_transfer[0] -1
>> xvif18.1: req_prod 713 req_cons 467 rsp_prod 466 rsp_prod_pvt 466 i 1
>> xvif18.1 GNTTABOP_transfer[0] -1
>> xvif18.1: req_prod 713 req_cons 468 rsp_prod 467 rsp_prod_pvt 467 i 1
>> xvif18.1 GNTTABOP_transfer[0] -1
>> xvif18.1: req_prod 713 req_cons 469 rsp_prod 468 rsp_prod_pvt 468 i 1
>>
>> So I assume there's a problem with the network driver.  However at
>> least it's booting at not BSOD'ing, so it's a step in the right
>> direction!
>>
>
> Can you turn off scatter gather under the driver properties in Windows?
> I remember that Solaris Dom0 had that problem, but thought I had made
> GPLPV automatically disable SG if it wasn't explicitly marked as
> supported in the Dom0 backend.

I think I remember a message about SG being set to 0, but my memory is
shot.  I'll try this as soon as I get home and VPN in, as my work
machine is x64, and HWVSP doesn't work w/ x64.

I did realize that I forgot to set my vif to a null array, as per the
install instructions.  I had:

vif = [ 'mac=00:16:3e:50:02:f4, bridge=bridge0, type=ioemu,
model=e1000', 'mac=00:16:3e:50:02:f5, bridge=bridge1, type=ioemu,
model=e1000', 'mac=00:16:3e:50:02:f6, bridge=bridge2,
 type=ioemu, model=e1000' ]

Would that cause it?  If so... how would I setup the mac/bridge
information w/ a null array?

Thanks again!
-Dustin

_______________________________________________
Xen-users mailing list
Xen-users@xxxxxxxxxxxxxxxxxxx
http://lists.xensource.com/xen-users