Xen users - Nov 2008 - Another GPLPV pre-release 0.9.11-pre20

I''ve run the xennet driver through Microsoft''s ndistest
application,
which is part of the WHQL testing suite, and it picked up a heap of
errors, which are now fixed. This update should be a lot more reliable
in terms of ''large send'' and checksum offloads working as they
should,
and crash dumps now working as they should (sometimes the crash dump
would hang before or just after starting, which may have been causing
filesystem corruption).

Please test and let me know how it goes. If there are no reports of
errors I''ll call this one 0.9.11 proper.

http://www.meadowcourt.org/downloads

James

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

James Harper wrote:
> Please test and let me know how it goes. If there are no reports of
> errors I''ll call this one 0.9.11 proper.
>   
Hi James,

During upgrading from previouse -pre versions, should I boot with or
without /gplpv?

Regards,

Fajar


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

xen-users-bounces@lists.xensource.com wrote on 05.11.2008 08:06:47:
> "James Harper" <james.harper@bendigoit.com.au> 
> Sent by: xen-users-bounces@lists.xensource.com
> 
> 05.11.2008 08:08
> 
> To
> 
> <xen-users@lists.xensource.com>,
<xen-devel@lists.xensource.com>
> 
> cc
> 
> Subject
> 
> [Xen-users] Another GPLPV pre-release 0.9.11-pre20
> 
> I''ve run the xennet driver through Microsoft''s ndistest
application,
> which is part of the WHQL testing suite, and it picked up a heap of
> errors, which are now fixed. This update should be a lot more reliable
> in terms of ''large send'' and checksum offloads working as
they should,
> and crash dumps now working as they should (sometimes the crash dump
> would hang before or just after starting, which may have been causing
> filesystem corruption).
> 
> Please test and let me know how it goes. If there are no reports of
> errors I''ll call this one 0.9.11 proper.
> 
> http://www.meadowcourt.org/downloads
> 
> James
Great, no BSOD yet, but still i cant use Checksum offloading or Large send 
Offload.

I still see atleast some incorrect tcp chksums if Checksum Offloading is 
enabled. 

Large Send Offload is also makeing Bacula to have very slow to transfer 
speeds, if Large Send offload is enabled Bacula transfer speed is 
something like 30kB/sec, if i disable Large Send Offload it will go to 
about 70-80Mbit/sec. 

Any ideas?


Terveisin/Regards,
   Pekka Panula, Net Servant Oy


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

> James Harper wrote:
> > Please test and let me know how it goes. If there are no reports of
> > errors I''ll call this one 0.9.11 proper.
> >
> Hi James,
> 
> During upgrading from previouse -pre versions, should I boot with or
> without /gplpv?
> 
Please boot with /gplpv. While the problem should be fixed in this
version, it''s the previous version drivers that get shut down during
upgrade, so you may still get a crash. When you boot with /gplpv the
drivers don''t get shutdown as they are in use, so the crash
doesn''t
occur.

James

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

> 
> Great, no BSOD yet,
That''s good.
> but still i cant use Checksum offloading or Large send
> Offload.
That''s not so good...
> 
> I still see atleast some incorrect tcp chksums if Checksum Offloading
is
> enabled.
> 
Where are you seeing these? If you are seeing them at any point before
the packet has passed through a physical network card then they will
indeed have an incorrect checksum. The checksum calculation should be
deferred until the latest possible time.
> Large Send Offload is also makeing Bacula to have very slow to
transfer
> speeds, if Large Send offload is enabled Bacula transfer speed is
> something like 30kB/sec, if i disable Large Send Offload it will go to
> about 70-80Mbit/sec.
Do you have a Linux PV DomU with lso enabled on that you can test also?

Can you describe (again, if you have done so previously) precisely your
network layout? Eg what vif is bridged to what physical adapter, and
where abouts on the network you are sending packets to and from.

Also, what is the output of ''cat
/proc/sys/net/bridge/bridge-nf-call-iptables''. If it''s not 0,
then
please try ''echo 0 >
/proc/sys/net/bridge/bridge-nf-call-iptables''. This
will stop bridge packets being touched by iptables, which may be the
cause of the problems you are seeing. If the Dom0 actually routes the
packets instead of bridging them (eg if the packet needs to go out a
Dom0 interface that is not on the same bridge) then iptables may become
involved, but by then hopefully it''s okay.

Otherwise, based on your network layout I''ll give you some places to
take some packet captures from and some other testing to do.

James


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

"James Harper" <james.harper@bendigoit.com.au> wrote on
05.11.2008
10:49:52:
> > I still see atleast some incorrect tcp chksums if Checksum Offloading
> is enabled.
> > 
> 
> Where are you seeing these? If you are seeing them at any point before
> the packet has passed through a physical network card then they will
> indeed have an incorrect checksum. The checksum calculation should be
> deferred until the latest possible time.
I am using tcpdump in my Dom0, eg. tcpdump -vv -i br13. 

Here is one example:
10:22:23.172581 IP (tos 0x0, ttl 128, id 18177, offset 0, flags [DF], 
proto: TCP (6), length: 74) 213.250.XX.XX.ms-wbt-server > 
213.250.XX.XX.41635: P, cksum 0x6884 (incorrect (-> 0xc813), 39:61(22) ack 
1 win 64620 <nop,nop,timestamp 46147 22223084>

I am bridging VLAN interfaces to Xen DomUs

eg. 
vconfig add peth0 13
brctl addbr br13
brctl addif br13 peth0.13
ifconfig br13 up

and DomU configuration vif -line:
vif = [ ''mac=00:16:3e:1b:c1:4a,type=ioemu, bridge=br13'' ]
> > Large Send Offload is also makeing Bacula to have very slow to
> transfer
> > speeds, if Large Send offload is enabled Bacula transfer speed is
> > something like 30kB/sec, if i disable Large Send Offload it will go to
> > about 70-80Mbit/sec.
> 
> Do you have a Linux PV DomU with lso enabled on that you can test also?
Not at the moment on my test server, i might install one to test. 
But i have couple PV Linux DomUs in production and Bacula is working fine 
there.
> Can you describe (again, if you have done so previously) precisely your
> network layout? Eg what vif is bridged to what physical adapter, and
> where abouts on the network you are sending packets to and from.
I got BladeCenter where my Xen servers are running. I got many networks 
(usually 1 per customer) which i do bring to DomUs as bridged vlan. My 
Bacula is not on BladeCenter, it''s a dedicated server and theres one 
switch between BladeCenter and Bacula, link is 1 Gbit/sec (copper).

If i now use brctl show it gives:
br13            8000.001a645c97e4       no              vif65.0
                                                        tap4
                                                       
peth0.13
> Also, what is the output of ''cat
> /proc/sys/net/bridge/bridge-nf-call-iptables''. If it''s
not 0, then
> please try ''echo 0 >
/proc/sys/net/bridge/bridge-nf-call-iptables''. This
> will stop bridge packets being touched by iptables, which may be the
> cause of the problems you are seeing. If the Dom0 actually routes the
> packets instead of bridging them (eg if the packet needs to go out a
> Dom0 interface that is not on the same bridge) then iptables may become
> involved, but by then hopefully it''s okay.
Did test with 0 to bridge-nf-call-iptables, also did set 
/proc/sys/net/bridge/bridge-nf-filter-vlan-tagged as 0 but nothing 
changes, speed is still extreme slow betweeen DomU and Bacula. 

Terveisin/Regards,
   Pekka Panula, Net Servant Oy


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

James Harper wrote:
>> During upgrading from previouse -pre versions, should I boot with or
>> without /gplpv?
>>
>>     
>
> Please boot with /gplpv.
Thanks.
I find it a little odd though, 0.9.11-pre20 reports driver version
0.9.10.19 instead of 0.9.10.20.

One more question. Is there a plan to support opensolaris dom0?

Regards,

Fajar


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

> > Where are you seeing these? If you are seeing them at any point
before
> > the packet has passed through a physical network card then they will
> > indeed have an incorrect checksum. The checksum calculation should
be
> > deferred until the latest possible time.
> 
> I am using tcpdump in my Dom0, eg. tcpdump -vv -i br13.
> 
> Here is one example:
> 10:22:23.172581 IP (tos 0x0, ttl 128, id 18177, offset 0, flags [DF],
> proto: TCP (6), length: 74) 213.250.XX.XX.ms-wbt-server >
> 213.250.XX.XX.41635: P, cksum 0x6884 (incorrect (-> 0xc813), 39:61(22)
ack
> 1 win 64620 <nop,nop,timestamp 46147 22223084>
Yes, I would expect to see that. The checksum calculation is deferred as
late as possible. If the packet goes from DomU to DomU and both support
rx+tx offloading, then it won''t be done at all - the tx side will
''offload'' the calculation to it''s virtual card, Dom0
will record the
fact that the data is correct, and will tell the receiving DomU that the
checksum has been verified and is good (even though it is incorrect).
That''s one less pass of the data to be done, and if you are
transferring
gigabits/second, thats gigabits of data per second that don''t have to
be
added up.

Sort of the same with large send offload.
> 
> I am bridging VLAN interfaces to Xen DomUs
> 
> eg.
> vconfig add peth0 13
> brctl addbr br13
> brctl addif br13 peth0.13
> ifconfig br13 up
> 
If you can get iperf on your windows machine, Dom0 machine, and Bacula
machine, it will make things much easier to test. In your domU, run
''iperf -s -w1M'' (run as server with 1Mbyte window). In Dom0
and Bacula,
run ''iperf -c name_of_DomU_windows_machine -w1M''. What is
performance
like:

Dom0<->WinDomU
Bacula<->WinDomU

With and without offload enabled?

Based on that, I''ll get you to try some tcpdumps with offload enabled.
If you want to do them straight away, we are looking for:

Dom0<->WinDomU - incorrect checksums
Bacula<->WinDomU - outgoing packets from each machine have bad checksum,
incoming packets have good checksum

In Dom0 I really need to see tcpdump''s of the vif interface, the bridge
interface, and the peth0.13 interface.

Also, at Dom0 you should see packets much larger than MTU appearing from
WinDomU, and the same packets but split up into MTU sized chunks
appearing on the Bacula machine. I suspect that you won''t see these
packets though...

Is there a way you can check this without vlan''s being involved? If
there are bugs in the Linux side of things, combining all that
offloading stuff with vlan might just be too much for it...

James

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

> > Please boot with /gplpv.
> 
> Thanks.
> I find it a little odd though, 0.9.11-pre20 reports driver version
> 0.9.10.19 instead of 0.9.10.20.
Just the way it is :) the whole -preXX thing was just until I could get
a couple of bugs out but it turned out to be a whole lot harder than I
thought. 0.9.11 will appear shortly unless I hear of any major problems,
but it will just be a renumbering of 0.9.11-pre20.
> 
> One more question. Is there a plan to support opensolaris dom0?
> 
I don''t have any OpenSolaris boxes to test. What is different about
OpenSolaris Dom0 vs Linux Dom0 anyway? I wouldn''t have been surprised
if
it ''just worked''.

If it''s a small amount of work to get it working then I can probably
work with you or someone else to do testing etc to find out where it is
wrong. If it''s a big job then I''d probably need a donation of
funds to
motivate me sufficiently :)

Do Linux PV domains work under OpenSolaris Dom0? If so, then I suspect
that the effort required to get GPLPV working should be pretty small.
Have you tried it? What happened when you did?

James


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

"James Harper" <james.harper@bendigoit.com.au> wrote on
05.11.2008
11:49:18:
> > Here is one example:
> > 10:22:23.172581 IP (tos 0x0, ttl 128, id 18177, offset 0, flags [DF],
> > proto: TCP (6), length: 74) 213.250.XX.XX.ms-wbt-server >
> > 213.250.XX.XX.41635: P, cksum 0x6884 (incorrect (-> 0xc813),
39:61(22)
> ack
> > 1 win 64620 <nop,nop,timestamp 46147 22223084>
> 
> Yes, I would expect to see that. The checksum calculation is deferred as
> late as possible. If the packet goes from DomU to DomU and both support
> rx+tx offloading, then it won''t be done at all - the tx side will
> ''offload'' the calculation to it''s virtual card,
Dom0 will record the
> fact that the data is correct, and will tell the receiving DomU that the
> checksum has been verified and is good (even though it is incorrect).
> That''s one less pass of the data to be done, and if you are
transferring
> gigabits/second, thats gigabits of data per second that don''t have
to be
> added up.
But those packets are going out to network? In that example it was packet 
between DomU and my Ubuntu workstation''s rdesktop.
Previously with old GPLPV drivers if both DomU Windows servers did run 
GPLPV drivers with checksum offloading enabled then eg remote desktop 
connection did not opened at all between them also windows network did not 
worked correctly between DomUs. tcpdump showed then that DomU with GPLPV 
drivers did have almost all packets marked as incorrect tcp cksum, but if 
checksum offloading was disabled then tcpdump showed all correct cksums 
and there was no problems communicating between DomUs. Also checksum was 
invalid to packets going off the Dom0 to network, eg. remote desktop 
connections when tcpdumped between my workstation and DomU there was lots 
of incorrect cksums if Checksum offload was enabled, but if disabled all 
chksums showed correct value. 
> Sort of the same with large send offload.
> 
> > 
> > I am bridging VLAN interfaces to Xen DomUs
> > 
> > eg.
> > vconfig add peth0 13
> > brctl addbr br13
> > brctl addif br13 peth0.13
> > ifconfig br13 up
> > 
> 
> If you can get iperf on your windows machine, Dom0 machine, and Bacula
> machine, it will make things much easier to test. In your domU, run
> ''iperf -s -w1M'' (run as server with 1Mbyte window). In
Dom0 and Bacula,
> run ''iperf -c name_of_DomU_windows_machine -w1M''. What is
performance
> like:
> 
> Dom0<->WinDomU
> Bacula<->WinDomU
> 
> With and without offload enabled?
Large Send Offload enabled, checksum offload disabled:
C:\TEMP>iperf -s -w1M
------------------------------------------------------------
Server listening on TCP port 5001
TCP window size: 1.00 MByte
------------------------------------------------------------
This is Dom0<->WinDomU:
[1872] local 213.250.XX.XX port 5001 connected with 213.250.DOM.0 port 
36739
[ ID] Interval       Transfer     Bandwidth
[1872]  0.0-10.0 sec  1.85 GBytes  1.59 Gbits/sec
This is Bacula<->WinDomU:
[1860] local 213.250.XX.XX port 5001 connected with 213.250.BA.CU port 
44458
[ ID] Interval       Transfer     Bandwidth
[1860]  0.0-10.0 sec  1.09 GBytes   935 Mbits/sec

Large Send Offload disabled, checksum offload disabled:
C:\TEMP>iperf -s -w1M
------------------------------------------------------------
Server listening on TCP port 5001
TCP window size: 1.00 MByte
------------------------------------------------------------
This is Dom0<->WinDomU:
[1872] local 213.250.XX.XX port 5001 connected with 213.250.DOM.0 port 
32779
[ ID] Interval       Transfer     Bandwidth
[1872]  0.0-10.0 sec  1.84 GBytes  1.58 Gbits/sec
This is Bacula<->WinDomU:
[1860] local 213.250.XX.XX port 5001 connected with 213.250.BA.CU port 
53880
[ ID] Interval       Transfer     Bandwidth
[1860]  0.0-10.0 sec  1.09 GBytes   936 Mbits/sec

It seems same results with large send offload enabled and disabled.
> Based on that, I''ll get you to try some tcpdumps with offload
enabled.
I will try to get some tcpdumps.
> Is there a way you can check this without vlan''s being involved?
If
> there are bugs in the Linux side of things, combining all that
> offloading stuff with vlan might just be too much for it...
Hmm, only if i use eth0/peth0, thats not an vlan bridge. 

Terveisin/Regards,
   Pekka Panula, Net Servant Oy


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

"James Harper" <james.harper@bendigoit.com.au> wrote on
05.11.2008
11:49:18:
> Based on that, I''ll get you to try some tcpdumps with offload
enabled.
> If you want to do them straight away, we are looking for:
> 
> Dom0<->WinDomU - incorrect checksums
> Bacula<->WinDomU - outgoing packets from each machine have bad
checksum,
> incoming packets have good checksum
> 
> In Dom0 I really need to see tcpdump''s of the vif interface, the
bridge
> interface, and the peth0.13 interface.
I tcpdumped my remote desktop connection (checksum offload enabled, large 
send offload enabled):
Showed incorrect cksums on vif65.0 and br13 interfaces, but no incorrect 
cksums on peth0.13 i quess you are right, Linux does calculate correct tcp 
chsums when it send them off to the wire...?

Also when i did iperf between dom0 <-> winDomU with large send offload 
enabled and checksum offload enabled i get this:
C:\TEMP>iperf -s -w1M
------------------------------------------------------------
Server listening on TCP port 5001
TCP window size: 1.00 MByte
------------------------------------------------------------
[1872] local 213.250.XX.XX port 5001 connected with 213.250.DOM.0 port 
43323
[ ID] Interval       Transfer     Bandwidth
[1872]  0.0-10.0 sec  1.06 GBytes   912 Mbits/sec

I retested that couple times and allways about 910-920 Mbit/sec, so when i 
enable checksum offload it goes from 1.59 Gbits/sec -> 912Mbit.

   Phone: GSM: +358 50 384 3232
   Net Servant Service desk: 010 470 7900 

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

James Harper wrote:
>   
>> One more question. Is there a plan to support opensolaris dom0?
>>
>>     
>
> I don''t have any OpenSolaris boxes to test. What is different
about
> OpenSolaris Dom0 vs Linux Dom0 anyway? I wouldn''t have been
surprised if
> it ''just worked''.
>
>   
Apparently it doesn''t :-D
> If it''s a small amount of work to get it working then I can
probably
> work with you or someone else to do testing etc to find out where it is
> wrong. If it''s a big job then I''d probably need a
donation of funds to
> motivate me sufficiently :)
>   
It''d be really great if you can get it to work. Sun released their own
PV driver (still in alpha, I think), but it''s not as widely-tested as
yours.
> Do Linux PV domains work under OpenSolaris Dom0? 
Yes. RHEL5 PV domU (both 32 and 64bit, using Redhat''s kernel-xen) runs
on opensolaris dom0.
> If so, then I suspect
> that the effort required to get GPLPV working should be pretty small.
> Have you tried it? What happened when you did?
>
>   
Let''s see. A long time ago I tried XP with 0.9.11-pre4, BSOD with
0.9.11-pre4.
Installation completed, but booting with /gplpv gets me that.

I just tried W2k3 SP1, -pre20, and now during installation of xennet it
BSOD 0x7E (0xC0000005, 0xF635BDF7, 0xF78EA3EC, 0xF78EA0E8)

xennet.sys - Address F635BDF7 base at F635000, DateStamp 491128dd.

Regards,

Fajar



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

> 
> Let''s see. A long time ago I tried XP with 0.9.11-pre4, BSOD with
> 0.9.11-pre4.
> Installation completed, but booting with /gplpv gets me that.
> 
> I just tried W2k3 SP1, -pre20, and now during installation of xennet
it
> BSOD 0x7E (0xC0000005, 0xF635BDF7, 0xF78EA3EC, 0xF78EA0E8)
> 
> xennet.sys - Address F635BDF7 base at F635000, DateStamp 491128dd.
> 
Did you get a crash dump out of it?

If so, please try again after starting DebugView from sysinternals.com
(need to make sure ''Capture Kernel'' is ticked), and after the
crash dump
has completed, reboot, start DebugView again, and ''Process Crash
Dump''
(crash dump file should be C:\Windows\Memory.DMP). Send me the
DbgView.log file (assuming there is something in it).

If that doesn''t tell me anything useful, you will then need to zip up
the crash dump file and make it available for me to download. Make sure
your system is set to ''Kernel memory dump'' only, not
''Complete memory
dump'', or it could be huge. I can then run the debugger against it to
find out exactly where it broke.

Then it''s a matter of me making changes and you doing the above again
until we get it working...

James


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

Resending, as my last email seems to never make it to the list.

Fajar A. Nugraha wrote:
> James Harper wrote:
>   
>>   
>>     
>>> One more question. Is there a plan to support opensolaris dom0?
>>>
>>>     
>>>       
>> I don''t have any OpenSolaris boxes to test. What is different
about
>> OpenSolaris Dom0 vs Linux Dom0 anyway? I wouldn''t have been
surprised if
>> it ''just worked''.
>>
>>   
>>     
>
> Apparently it doesn''t :-D
>
>   
>> If it''s a small amount of work to get it working then I can
probably
>> work with you or someone else to do testing etc to find out where it is
>> wrong. If it''s a big job then I''d probably need a
donation of funds to
>> motivate me sufficiently :)
>>   
>>     
>
> It''d be really great if you can get it to work. Sun released their
own
> PV driver (still in alpha, I think), but it''s not as widely-tested
as yours.
>
>   
>> Do Linux PV domains work under OpenSolaris Dom0? 
>>     
>
> Yes. RHEL5 PV domU (both 32 and 64bit, using Redhat''s kernel-xen)
runs
> on opensolaris dom0.
>
>   
>> If so, then I suspect
>> that the effort required to get GPLPV working should be pretty small.
>> Have you tried it? What happened when you did?
>>
>>   
>>     
>
> Let''s see. A long time ago I tried XP with 0.9.11-pre4, BSOD with
> 0.9.11-pre4.
> Installation completed, but booting with /gplpv gets me that.
>
> I just tried W2k3 SP1, -pre20, and now during installation of xennet it
> BSOD 0x7E (0xC0000005, 0xF635BDF7, 0xF78EA3EC, 0xF78EA0E8)
>
> xennet.sys - Address F635BDF7 base at F635000, DateStamp 491128dd.
>
> Regards,
>
> Fajar
>
>   


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

Hi James,

Fajar A. Nugraha wrote:
> Resending, as my last email seems to never make it to the list.
>   
Weird. Looking at list archive I found my original email and your reply.
I guess there must be something wrong with my server this morning.
> Did you get a crash dump out of it?
Yes.
>If so, please try again after starting DebugView from sysinternals.com
>Send me the
>DbgView.log file (assuming there is something in it).
It''s a little complicated.
Driver installation installs xenblk succesfully, but when it installs
xennet it BSOD, writes a crash dump. Rstart the server, now it BSOD with
0x7E. I assume xenblk did that, which is weird because I''m booting
WITHOUT /gplpv.

So I restart again, press F8, select Last known good configuration, run
debugview again. Dbgview.log attached (gz-compressed).

Regards,

Fajar




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

> Hi James,
> 
> > Did you get a crash dump out of it?
> 
> Yes.
> 
> >If so, please try again after starting DebugView from sysinternals.com
> >Send me the
> >DbgView.log file (assuming there is something in it).
> 
> It''s a little complicated.
> Driver installation installs xenblk succesfully, but when it installs
> xennet it BSOD, writes a crash dump. Rstart the server, now it BSOD with
> 0x7E. I assume xenblk did that, which is weird because I''m booting
> WITHOUT /gplpv.
> 
> So I restart again, press F8, select Last known good configuration, run
> debugview again. Dbgview.log attached (gz-compressed).
> 
Thanks for that. There are two problems I can see. The first is that gplpv
fails to connect the backend for each device. The second is that in xennet,
I don''t check the return code so when it fails you get a crash.

Without /GPLPV in the boot.ini, xennet still runs but tells windows that the
cable is disconnected, so that the network adapter can still be set up
before booting with /GPLPV. That is why you still got the crash.

I have just uploaded a file called xennet.sys.solaristest to
http://www.meadowcourt.org/downloads. What I think you will need to do is to
run the 0.9.11 installer, but untick ''install drivers''. Once
that is
complete, copy the updated xennet.sys to C:\Program Files\Xen PV
Drivers\drivers\i386 (or amd64, I don''t know if you told me what arch
you
are using). Then you will need to manually install the drivers from
C:\Program Files\Xen PV Drivers\drivers, one at a time, starting with the
PCI device. If you can''t make that work then let me know and
I''ll build
another release.

Once you have done that, the drivers still won''t work, so
don''t bother with
/GPLPV in your boot menu, but we can start looking further.

When you do the install, with debugview running, you will see a message like
''XenPCI     Still waiting for 4 (currently 2)...'' repeat once
a second for
about 20 seconds. As soon as that starts, please do a ''xenstore-ls
/local/domain'' in your Dom0 and send me the results. You will need to
have a
Linux (or other) PV domain running for this to be useful. Let me know the ID
of both the Windows DomU you are testing, and the existing Linux PV DomU. I
suspect that maybe I''ve been a bit sloppy with something I am writing
into
xenstore, and that the Linux Dom0 is less sensitive to it than Solaris is...

Thanks

James



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

Before you get to any of the stuff I wrote below, can you please check
every logfile you can in Solaris for any useful messages?

I''ve just had a (very brief) look through the OpenSolaris sources and
it
does appear to log a bit of stuff, so you might get something helpful in
a logfile somewhere...

Thanks

James
> > Hi James,
> >
> > > Did you get a crash dump out of it?
> >
> > Yes.
> >
> > >If so, please try again after starting DebugView from
sysinternals.com
> > >Send me the
> > >DbgView.log file (assuming there is something in it).
> >
> > It''s a little complicated.
> > Driver installation installs xenblk succesfully, but when it
installs
> > xennet it BSOD, writes a crash dump. Rstart the server, now it BSOD
with
> > 0x7E. I assume xenblk did that, which is weird because I''m
booting
> > WITHOUT /gplpv.
> >
> > So I restart again, press F8, select Last known good configuration,
run
> > debugview again. Dbgview.log attached (gz-compressed).
> >
> 
> Thanks for that. There are two problems I can see. The first is that
gplpv
> fails to connect the backend for each device. The second is that in
> xennet,
> I don''t check the return code so when it fails you get a crash.
> 
> Without /GPLPV in the boot.ini, xennet still runs but tells windows
that
> the
> cable is disconnected, so that the network adapter can still be set up
> before booting with /GPLPV. That is why you still got the crash.
> 
> I have just uploaded a file called xennet.sys.solaristest to
> http://www.meadowcourt.org/downloads. What I think you will need to do
is
> to
> run the 0.9.11 installer, but untick ''install drivers''.
Once that is
> complete, copy the updated xennet.sys to C:\Program Files\Xen PV
> Drivers\drivers\i386 (or amd64, I don''t know if you told me what
arch
you
> are using). Then you will need to manually install the drivers from
> C:\Program Files\Xen PV Drivers\drivers, one at a time, starting with
the
> PCI device. If you can''t make that work then let me know and
I''ll
build
> another release.
> 
> Once you have done that, the drivers still won''t work, so
don''t bother
> with
> /GPLPV in your boot menu, but we can start looking further.
> 
> When you do the install, with debugview running, you will see a
message
> like
> ''XenPCI     Still waiting for 4 (currently 2)...'' repeat
once a second
for
> about 20 seconds. As soon as that starts, please do a ''xenstore-ls
> /local/domain'' in your Dom0 and send me the results. You will need
to
have
> a
> Linux (or other) PV domain running for this to be useful. Let me know
the
> ID
> of both the Windows DomU you are testing, and the existing Linux PV
DomU.
> I
> suspect that maybe I''ve been a bit sloppy with something I am
writing
into
> xenstore, and that the Linux Dom0 is less sensitive to it than Solaris
> is...
> 
> Thanks
> 
> James

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

James Harper wrote:
> What I think you will need to do is to
> run the 0.9.11 installer, but untick ''install drivers''.
Once that is
> complete, copy the updated xennet.sys to C:\Program Files\Xen PV
> Drivers\drivers\i386 (or amd64, I don''t know if you told me what
arch you
> are using). Then you will need to manually install the drivers from
> C:\Program Files\Xen PV Drivers\drivers, one at a time, starting with the
> PCI device. If you can''t make that work then let me know and
I''ll build
> another release.
>
>   
This might take some, so I''ll have to get back to you later. To
clarify,
I''ll be installing everything manually, including the updated
xennet.sys, but NOT xenblk, right?
I mentioned that after reboot it BSOD with 0x7E, so if I install xenblk
I''d probably still get that.

The system is opensolaris snv98 dom0 x86_64 running W2k3 SP1 HVM i386.

Regards,

Fajar


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

> 
> This might take some, so I''ll have to get back to you later. To
clarify,
> I''ll be installing everything manually, including the updated
> xennet.sys, but NOT xenblk, right?
> I mentioned that after reboot it BSOD with 0x7E, so if I install
xenblk
> I''d probably still get that.
> 
> The system is opensolaris snv98 dom0 x86_64 running W2k3 SP1 HVM i386.
> 
I''ll put up a full installer for you.

James


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

James Harper wrote:
> Before you get to any of the stuff I wrote below, can you please check
> every logfile you can in Solaris for any useful messages?
>
>   
Some partial suspicious log

This is on /var/adm/messages
===========================Nov  7 15:49:20 opensolaris xdb: [ID 945258
kern.notice] NOTICE:
xdb@9,768: unexpected otherend state change to 4!, when status is 0
Nov  7 15:49:50 opensolaris xdb: [ID 945258 kern.notice] NOTICE:
xdb@9,5632: unexpected otherend state change to 4!, when status is 0

This is on /var/log/xen/qemu-dm.1689.log
===========================Register xen platform.
Done register platform.
register acpi io
I/O request not ready: 0, ptr: 0, port: 0, data: 0, count: 0, size: 0
Triggered log-dirty buffer switch

This is on /var/log/xen/xend-debug.log
===========================Failed allocation for dom 8: 1 extents of order 9
ERROR Internal error: Cannot allocate more 2M pages for HVM guest.
 (16 = Device busy)
<< repeated several times >>
Failed allocation for dom 9: 1 extents of order 9
ERROR Internal error: Cannot allocate more 2M pages for HVM guest.
 (16 = Device busy)
<< repeated several times >>
Failed allocation for dom 10: 1 extents of order 9
ERROR Internal error: Cannot allocate more 2M pages for HVM guest.
 (16 = Device busy)

dom 8 is dom id when xennet crashed during install, 9 is when it reboots
and BSOD with 0x7E, 10 is current running domain which I''m collecting
dbgview.log from.

Everything seems normal on /var/log/xen/xpvd-event.log and xend.log

Regards,

Fajar


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

Please try 0.9.12-pre1 that I''ve just uploaded.

Networking won''t work, but disk might this time when you boot with
/GPLPV. You shouldn''t get a crash now anyway.

James
> -----Original Message-----
> From: xen-users-bounces@lists.xensource.com [mailto:xen-users-
> bounces@lists.xensource.com] On Behalf Of Fajar A. Nugraha
> Sent: Friday, 7 November 2008 21:35
> To: James Harper
> Cc: xen-users@lists.xensource.com
> Subject: Re: [Xen-users] Another GPLPV pre-release 0.9.11-pre20
> 
> James Harper wrote:
> > Before you get to any of the stuff I wrote below, can you please
check
> > every logfile you can in Solaris for any useful messages?
> >
> >
> Some partial suspicious log
> 
> This is on /var/adm/messages
> ===========================> Nov  7 15:49:20 opensolaris xdb: [ID 945258
kern.notice] NOTICE:
> xdb@9,768: unexpected otherend state change to 4!, when status is 0
> Nov  7 15:49:50 opensolaris xdb: [ID 945258 kern.notice] NOTICE:
> xdb@9,5632: unexpected otherend state change to 4!, when status is 0
> 
> This is on /var/log/xen/qemu-dm.1689.log
> ===========================> Register xen platform.
> Done register platform.
> register acpi io
> I/O request not ready: 0, ptr: 0, port: 0, data: 0, count: 0, size: 0
> Triggered log-dirty buffer switch
> 
> This is on /var/log/xen/xend-debug.log
> ===========================> Failed allocation for dom 8: 1 extents of
order 9
> ERROR Internal error: Cannot allocate more 2M pages for HVM guest.
>  (16 = Device busy)
> << repeated several times >>
> Failed allocation for dom 9: 1 extents of order 9
> ERROR Internal error: Cannot allocate more 2M pages for HVM guest.
>  (16 = Device busy)
> << repeated several times >>
> Failed allocation for dom 10: 1 extents of order 9
> ERROR Internal error: Cannot allocate more 2M pages for HVM guest.
>  (16 = Device busy)
> 
> dom 8 is dom id when xennet crashed during install, 9 is when it
reboots
> and BSOD with 0x7E, 10 is current running domain which I''m
collecting
> dbgview.log from.
> 
> Everything seems normal on /var/log/xen/xpvd-event.log and xend.log
> 
> Regards,
> 
> Fajar
_______________________________________________
Xen-users mailing list
Xen-users@lists.xensource.com
http://lists.xensource.com/xen-users

I''m seeing the same 0x7E BSOD after upgrading 0.9.11-pre13 to 0.9.11.
Happens
with or without /GPLPV.

Keith

Fajar A. Nugraha-3 wrote:
> 
> Hi James,
> 
> Fajar A. Nugraha wrote:
>> Resending, as my last email seems to never make it to the list.
>>   
> 
> Weird. Looking at list archive I found my original email and your reply.
> I guess there must be something wrong with my server this morning.
> 
>> Did you get a crash dump out of it?
> 
> Yes.
> 
>>If so, please try again after starting DebugView from sysinternals.com
>>Send me the
>>DbgView.log file (assuming there is something in it).
> 
> It''s a little complicated.
> Driver installation installs xenblk succesfully, but when it installs
> xennet it BSOD, writes a crash dump. Rstart the server, now it BSOD with
> 0x7E. I assume xenblk did that, which is weird because I''m booting
> WITHOUT /gplpv.
> 
> So I restart again, press F8, select Last known good configuration, run
> debugview again. Dbgview.log attached (gz-compressed).
> 
> Regards,
> 
> Fajar
> 
> 
>  
>  
> _______________________________________________
> Xen-users mailing list
> Xen-users@lists.xensource.com
> http://lists.xensource.com/xen-users
> 
-- 
View this message in context:
http://www.nabble.com/Another-GPLPV-pre-release-0.9.11-pre20-tp20336594p20393057.html
Sent from the Xen - User mailing list archive at Nabble.com.


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

It works on OS (snv_98 i86pc i386 i86xpv Solaris), Windows 2003r2 sp2 +
updates (32bit).No BSoD and no network :)
What now?! How to get network back on?

Regards
Andrej Javorsek

On Fri, Nov 7, 2008 at 12:40 PM, James Harper
<james.harper@bendigoit.com.au
> wrote:
> Please try 0.9.12-pre1 that I''ve just uploaded.
>
> Networking won''t work, but disk might this time when you boot with
> /GPLPV. You shouldn''t get a crash now anyway.
>
> James
>
> > -----Original Message-----
> > From: xen-users-bounces@lists.xensource.com [mailto:xen-users-
> > bounces@lists.xensource.com] On Behalf Of Fajar A. Nugraha
> > Sent: Friday, 7 November 2008 21:35
> > To: James Harper
> > Cc: xen-users@lists.xensource.com
> > Subject: Re: [Xen-users] Another GPLPV pre-release 0.9.11-pre20
> >
> > James Harper wrote:
> > > Before you get to any of the stuff I wrote below, can you please
> check
> > > every logfile you can in Solaris for any useful messages?
> > >
> > >
> > Some partial suspicious log
> >
> > This is on /var/adm/messages
> > ===========================> > Nov  7 15:49:20 opensolaris xdb:
[ID 945258 kern.notice] NOTICE:
> > xdb@9,768: unexpected otherend state change to 4!, when status is 0
> > Nov  7 15:49:50 opensolaris xdb: [ID 945258 kern.notice] NOTICE:
> > xdb@9,5632: unexpected otherend state change to 4!, when status is 0
> >
> > This is on /var/log/xen/qemu-dm.1689.log
> > ===========================> > Register xen platform.
> > Done register platform.
> > register acpi io
> > I/O request not ready: 0, ptr: 0, port: 0, data: 0, count: 0, size: 0
> > Triggered log-dirty buffer switch
> >
> > This is on /var/log/xen/xend-debug.log
> > ===========================> > Failed allocation for dom 8: 1
extents of order 9
> > ERROR Internal error: Cannot allocate more 2M pages for HVM guest.
> >  (16 = Device busy)
> > << repeated several times >>
> > Failed allocation for dom 9: 1 extents of order 9
> > ERROR Internal error: Cannot allocate more 2M pages for HVM guest.
> >  (16 = Device busy)
> > << repeated several times >>
> > Failed allocation for dom 10: 1 extents of order 9
> > ERROR Internal error: Cannot allocate more 2M pages for HVM guest.
> >  (16 = Device busy)
> >
> > dom 8 is dom id when xennet crashed during install, 9 is when it
> reboots
> > and BSOD with 0x7E, 10 is current running domain which I''m
collecting
> > dbgview.log from.
> >
> > Everything seems normal on /var/log/xen/xpvd-event.log and xend.log
> >
> > Regards,
> >
> > Fajar
>
> _______________________________________________
> Xen-users mailing list
> Xen-users@lists.xensource.com
> http://lists.xensource.com/xen-users
>

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

Forgot to mention. I''m using 0.9.12-pre2.

On Fri, Nov 7, 2008 at 12:40 PM, James Harper
<james.harper@bendigoit.com.au
> wrote:
> Please try 0.9.12-pre1 that I''ve just uploaded.
>
> Networking won''t work, but disk might this time when you boot with
> /GPLPV. You shouldn''t get a crash now anyway.
>
> James
>
> > -----Original Message-----
> > From: xen-users-bounces@lists.xensource.com [mailto:xen-users-
> > bounces@lists.xensource.com] On Behalf Of Fajar A. Nugraha
> > Sent: Friday, 7 November 2008 21:35
> > To: James Harper
> > Cc: xen-users@lists.xensource.com
> > Subject: Re: [Xen-users] Another GPLPV pre-release 0.9.11-pre20
> >
> > James Harper wrote:
> > > Before you get to any of the stuff I wrote below, can you please
> check
> > > every logfile you can in Solaris for any useful messages?
> > >
> > >
> > Some partial suspicious log
> >
> > This is on /var/adm/messages
> > ===========================> > Nov  7 15:49:20 opensolaris xdb:
[ID 945258 kern.notice] NOTICE:
> > xdb@9,768: unexpected otherend state change to 4!, when status is 0
> > Nov  7 15:49:50 opensolaris xdb: [ID 945258 kern.notice] NOTICE:
> > xdb@9,5632: unexpected otherend state change to 4!, when status is 0
> >
> > This is on /var/log/xen/qemu-dm.1689.log
> > ===========================> > Register xen platform.
> > Done register platform.
> > register acpi io
> > I/O request not ready: 0, ptr: 0, port: 0, data: 0, count: 0, size: 0
> > Triggered log-dirty buffer switch
> >
> > This is on /var/log/xen/xend-debug.log
> > ===========================> > Failed allocation for dom 8: 1
extents of order 9
> > ERROR Internal error: Cannot allocate more 2M pages for HVM guest.
> >  (16 = Device busy)
> > << repeated several times >>
> > Failed allocation for dom 9: 1 extents of order 9
> > ERROR Internal error: Cannot allocate more 2M pages for HVM guest.
> >  (16 = Device busy)
> > << repeated several times >>
> > Failed allocation for dom 10: 1 extents of order 9
> > ERROR Internal error: Cannot allocate more 2M pages for HVM guest.
> >  (16 = Device busy)
> >
> > dom 8 is dom id when xennet crashed during install, 9 is when it
> reboots
> > and BSOD with 0x7E, 10 is current running domain which I''m
collecting
> > dbgview.log from.
> >
> > Everything seems normal on /var/log/xen/xpvd-event.log and xend.log
> >
> > Regards,
> >
> > Fajar
>
> _______________________________________________
> Xen-users mailing list
> Xen-users@lists.xensource.com
> http://lists.xensource.com/xen-users
>

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

> 
> It works on OS (snv_98 i86pc i386 i86xpv Solaris), Windows 2003r2 sp2 +
> updates (32bit).
> No BSoD and no network :)
> What now?! How to get network back on?
> 
So are you saying that with /GPLPV in boot.ini you get disk connectivity?

James

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

Yes, with /GPLPV I get working system with XEN PV DISK..., Xen Net.., Xen
Block device driver...,but without network connectivity.

On Sun, Nov 9, 2008 at 12:53 AM, James Harper
<james.harper@bendigoit.com.au
> wrote:
> >
> > It works on OS (snv_98 i86pc i386 i86xpv Solaris), Windows 2003r2 sp2
+
> > updates (32bit).
> > No BSoD and no network :)
> > What now?! How to get network back on?
> >
>
> So are you saying that with /GPLPV in boot.ini you get disk connectivity?
>
> James
>

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

> 
> Yes, with /GPLPV I get working system with XEN PV DISK..., Xen Net.., Xen
> Block device driver...,
> but without network connectivity.
> 
Well that''s good news.

Can you attach the debugger and send me the output of the boot?

Failing that:
1. Disable the network devices in ''Device Manager''
2. Reboot
3. Start DebugView from sysinternals.com with ''Kernel Capture''
enabled
4. Enable the device devices
5. Cut and paste the output of DebugView into an email and send it to me

Thanks

James

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

> Well that''s good news.
> 
> Can you attach the debugger and send me the output of the boot?
> 
> Failing that:
> 1. Disable the network devices in ''Device Manager''
> 2. Reboot
> 3. Start DebugView from sysinternals.com with ''Kernel
Capture'' enabled
> 4. Enable the device devices
                ^^^^^^ I mean network devices here of course :)
> 5. Cut and paste the output of DebugView into an email and send it to me
> 
James

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

On Sun, Nov 9, 2008 at 4:20 PM, James Harper
<james.harper@bendigoit.com.au> wrote:
>> Well that''s good news.
My result is slightly different though. Install drivers succeeded, and
it asks for reboot. Since it hasn''t installed shutdownmon or copy
config yet, I choose restart later. No progress.

So I edit boot.ini to add /gplpv, then I try to shutdown the server.
It seems to be waiting for something (doesn''t shutdown).

Then I force shutdown the server (xm destroy). Start it again with
/gplpv. It keeps on displaying the splash screen. So I "xm destroy"
and start again, finally I was able to log in :D

>>
>> Can you attach the debugger and send me the output of the boot?
>>
>> Failing that:
>> 1. Disable the network devices in ''Device Manager''
>> 2. Reboot
>> 3. Start DebugView from sysinternals.com with ''Kernel
Capture'' enabled
>> 4. Enable the device devices
>
>                ^^^^^^ I mean network devices here of course :)
>
Xen net started disabled after driver installation. After booting with
/gplpv, it stays disabled. Enabling it manually doesn''t work (it says
"enabled", but still disabled).
>> 5. Cut and paste the output of DebugView into an email and send it to
me
>>
>
attached. I tried enabling xennet twice while DebugView running.


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