[9fans] xen progress ...

[9fans] xen progress ...

[Ronald G. Minnich]

ok, I resolved my odd problem with srvold9p. It makes no sense however. 

You can see the problem below. 

srvold9p:->Rwrite tag 10 count 29
srvold9p:<-Twrite tag 10 fid 298 offset 52 count 5 'cpu% '
srvold9p:=>old Twrite tag 10 fid 298 offset 52 count 5 'cpu% '
srvold9p:->Rwrite tag 10 count 5
srvold9p:<-Tread tag 10 fid 296 offset 5 count 512
srvold9p:=>old Tread tag 10 fid 296 offset 5 count 512
srvold9p:->Rread tag 10 count 3 'ps
'
srvold9p:<-Twrite tag 8 fid 298 offset 57 count 3667 'bootes            1    0:01   0:04      88K Await    init
bootes'
srvold9p:=>old Twrite tag 8 fid 298 offset 57 count 3667 'bootes            1    0:01   0:04      88K Await    init
bootes'
srvold9p: (pid 101, errstr read or write too large) wrote -1 to old system; should be 3683

So srvold9p goes to write to the old9p fd and gets an error that makes no
sense on a tcp socket. I'm still trying to find the source of the error in
the kernel (I modified fatal() in srvold9p to use %r, hence the errstr ...
part of that message).

If I change srvold9p to respond to Tversion with an Rversion that says it 
only supports up to 1024 byte messages, then everything is fine. The 
reason is that no 9p2000 messages come in to srvold9p larger than 1024 
bytes, so srvold9p can only send 1024 byte messages on the 9p1 channel, 
and the failure won't occur. 

Has anyone modified tcp in the kernel to try to preserve message 
boundaries? This problem is really weird. You shouldn't get an error like 
this on a tcp socket, I would think.

Is there a 9p2000 drawterm? 

I can now run clock in the drawterm window. Anything that uses a font gets 
this error:

getsubfont: can't read /lib/font/bit/whatever/whatever: bad count in \
bufimage


any place I should start looking? 

thanks

ron

Re: [9fans] xen progress ...

[andrey mirtchovski]

> Is there a 9p2000 drawterm? 
> 

here's something old you can use:

	http://pages.cpsc.ucalgary.ca/~mirtchov/p9/dt2k.tgz

it compiles somewhat cleanly and works on linux (i'm typing this
message using it) it has a few bugs with alpha blending and is
somewhat slower than the old drawterm.

andrey

Re: [9fans] xen progress ...

[Skip Tavakkolian]

>> Is there a 9p2000 drawterm? 
>> 
> 
> here's something old you can use:
> 
> 	http://pages.cpsc.ucalgary.ca/~mirtchov/p9/dt2k.tgz
> 
> it compiles somewhat cleanly and works on linux (i'm typing this
> message using it) it has a few bugs with alpha blending and is
> somewhat slower than the old drawterm.

I have a port of it to win32, and I think the changes were sent back.
Are they there?

Re: [9fans] xen progress ...

[andrey mirtchovski]

> I have a port of it to win32, and I think the changes were sent back.
> Are they there?

no, i think that was the version i sent to you last (with minor
changes to compile under linux cleanly).  haven't seen any other
patches.  i don't even know who's the maintainer -- this one just sat
in my home directory waiting for someone to need it :)

Re: [9fans] xen progress ...

[David Leimbach]

On Tue, 23 Nov 2004 13:04:38 -0700, andrey mirtchovski
<mirtchov@cpsc.ucalgary.ca> wrote:
> 
> > I have a port of it to win32, and I think the changes were sent back.
> > Are they there?
> 
> no, i think that was the version i sent to you last (with minor
> changes to compile under linux cleanly).  haven't seen any other
> patches.  i don't even know who's the maintainer -- this one just sat
> in my home directory waiting for someone to need it :)
> 
> 
Just tried to compile this on my Mac and gcc got an ICE :).

Dave

Re: [9fans] xen progress ...

[David Leimbach]

On Tue, 23 Nov 2004 15:16:23 -0800, David Leimbach <leimy2k@gmail.com> wrote:
> On Tue, 23 Nov 2004 13:04:38 -0700, andrey mirtchovski
> 
> 
> <mirtchov@cpsc.ucalgary.ca> wrote:
> >
> > > I have a port of it to win32, and I think the changes were sent back.
> > > Are they there?
> >
> > no, i think that was the version i sent to you last (with minor
> > changes to compile under linux cleanly).  haven't seen any other
> > patches.  i don't even know who's the maintainer -- this one just sat
> > in my home directory waiting for someone to need it :)
> >
> > 
> Just tried to compile this on my Mac and gcc got an ICE :).
> 
> Dave
> 
OOps... I fixed that... It was just getting the wrong subdir...

Dave

Re: [9fans] xen progress ...

[Russ Cox]

> You can see the problem below.

Where are the old R messages below?

> srvold9p:->Rwrite tag 10 count 29
> srvold9p:<-Twrite tag 10 fid 298 offset 52 count 5 'cpu% '
> srvold9p:=>old Twrite tag 10 fid 298 offset 52 count 5 'cpu% '
> srvold9p:->Rwrite tag 10 count 5
> srvold9p:<-Tread tag 10 fid 296 offset 5 count 512
> srvold9p:=>old Tread tag 10 fid 296 offset 5 count 512
> srvold9p:->Rread tag 10 count 3 'ps
> '
> srvold9p:<-Twrite tag 8 fid 298 offset 57 count 3667 'bootes            1    0:01   0:04      88K Await    init
> bootes'
> srvold9p:=>old Twrite tag 8 fid 298 offset 57 count 3667 'bootes            1    0:01   0:04      88K Await    init
> bootes'
> srvold9p: (pid 101, errstr read or write too large) wrote -1 to old system; should be 3683
> 
> So srvold9p goes to write to the old9p fd and gets an error that makes no
> sense on a tcp socket. I'm still trying to find the source of the error in
> the kernel (I modified fatal() in srvold9p to use %r, hence the errstr ...
> part of that message).

I think that what is happening is your old 9P server (drawterm?)
is responding with an old Rwrite with a -1 length, but that's not
acceptable (it should respond with an Rerror
instead), and the srvold9p code treats the number as
unsigned and complains that it is too big (as too big
as it could possibly be!).

This is probably just a drawterm bug.  Try using cpu -O instead.

Russ

Re: [9fans] xen progress ...

[Ronald G. Minnich]

It turned out to be a misunderstanding in Xen about how to handle writes 
to virtual devices. Long story. Fixed. I'm running acme in a drawterm 
window to Xen under Plan 9.

rio is next.

oh wait, rio works. and acme in a rio window works. 

well, well, well. Now I gotta make it go fast. 

ron

Re: [9fans] xen progress ...

[David Leimbach]

Ron, Great news!

Any word on when/if we can see the source? :)

Dave


On Wed, 24 Nov 2004 09:07:12 -0700 (MST), Ronald G. Minnich
<rminnich@lanl.gov> wrote:
> It turned out to be a misunderstanding in Xen about how to handle writes
> to virtual devices. Long story. Fixed. I'm running acme in a drawterm
> window to Xen under Plan 9.
> 
> rio is next.
> 
> oh wait, rio works. and acme in a rio window works.
> 
> well, well, well. Now I gotta make it go fast.
> 
> ron
>

Re: [9fans] xen progress ...

[Ronald G. Minnich]

On Wed, 24 Nov 2004, David Leimbach wrote:

> Any word on when/if we can see the source? :)

I had to do some forms yesterday and did not get them done. I will try to
get them done monday. Approval is about 2 days. Dave, my plan is to try to
recreate the build process with you in the role of Victim, and me in the
role of Bad Cop (no Good Cop with this type of work, Sorry). So what I
will try to send you is "how to"  for rebuilding my setup, and you can
then apply to your updated Xen, and we can try to catch problems that way.
I hope that is ok.

ron

Re: [9fans] xen progress ...

[David Leimbach]

On Wed, 24 Nov 2004 09:22:16 -0700 (MST), Ronald G. Minnich
<rminnich@lanl.gov> wrote:
> 
> 
> On Wed, 24 Nov 2004, David Leimbach wrote:
> 
> > Any word on when/if we can see the source? :)
> 
> I had to do some forms yesterday and did not get them done. I will try to
> get them done monday. Approval is about 2 days. Dave, my plan is to try to
> recreate the build process with you in the role of Victim, and me in the
> role of Bad Cop (no Good Cop with this type of work, Sorry). So what I
> will try to send you is "how to"  for rebuilding my setup, and you can
> then apply to your updated Xen, and we can try to catch problems that way.
> I hope that is ok.
> 
> ron
> 

Sounds great in a sort of techno-sado-masochistic way.  I think I am
going to be in town all next week but I do have to be away the
following week for a few days.

I'll wait to hear from you then instead of bugging you again here :).

Dave

Re: [9fans] xen progress ...

[Ronald G. Minnich]

On Tue, 23 Nov 2004, Russ Cox wrote:

> > You can see the problem below.
> 
> Where are the old R messages below?
> 
> > srvold9p:->Rwrite tag 10 count 29
> > srvold9p:<-Twrite tag 10 fid 298 offset 52 count 5 'cpu% '
> > srvold9p:=>old Twrite tag 10 fid 298 offset 52 count 5 'cpu% '
> > srvold9p:->Rwrite tag 10 count 5
> > srvold9p:<-Tread tag 10 fid 296 offset 5 count 512
> > srvold9p:=>old Tread tag 10 fid 296 offset 5 count 512
> > srvold9p:->Rread tag 10 count 3 'ps
> > '
> > srvold9p:<-Twrite tag 8 fid 298 offset 57 count 3667 'bootes            1    0:01   0:04      88K Await    init
> > bootes'
> > srvold9p:=>old Twrite tag 8 fid 298 offset 57 count 3667 'bootes            1    0:01   0:04      88K Await    init
> > bootes'
> > srvold9p: (pid 101, errstr read or write too large) wrote -1 to old system; should be 3683

it's a peculiarity of srvold9p that it seems not to log old R messages. 
Not sure why, I'm about to turn this logging off anyways ... 

> I think that what is happening is your old 9P server (drawterm?)
> is responding with an old Rwrite with a -1 length, but that's not
> acceptable (it should respond with an Rerror
> instead), and the srvold9p code treats the number as
> unsigned and complains that it is too big (as too big
> as it could possibly be!).

it was worse. Xen was silently dropping MAXMTU transmit packets from Plan
9 as they come across with a size of 1516, not 1514 bytes. You would see
1516 on a MAXMTU "DMA" to Xen because I carelessly copied some code from
other plan 9 drivers that did a ROUNDUP of packet size to 4 byte
boundaries -- this is ok with real ethernet hardware, it just ignores the
last two bytes, but Xen was a little too smart for its own good. A fix of
ROUNDUP to 2 byte boundaries fixed things.


ron

Re: [9fans] xen progress ...

[Fco. J. Ballesteros]

> 1516, not 1514 bytes. You would see
> 1516 on a MAXMTU "DMA" to Xen because I carelessly copied some code from
> other plan 9 drivers that did a ROUNDUP of packet size to 4 byte
> boundaries -- this is ok with real ethernet hardware

Hmmm, perhaps that's what makes some adsl routers in spain
to cause problems to 9p connections. We had to lower the mtu `by hand'
to fix this. Don't have time now, but I'll take a look at it now that I have a clue.

Re: [9fans] xen progress ...

[Skip Tavakkolian]

[-- Attachment #1: Type: text/plain, Size: 1095 bytes --]

>> > You can see the problem below.
>> 
>> Where are the old R messages below?
>> 
>> > srvold9p:->Rwrite tag 10 count 29
>> > srvold9p:<-Twrite tag 10 fid 298 offset 52 count 5 'cpu% '
>> > srvold9p:=>old Twrite tag 10 fid 298 offset 52 count 5 'cpu% '
>> > srvold9p:->Rwrite tag 10 count 5
>> > srvold9p:<-Tread tag 10 fid 296 offset 5 count 512
>> > srvold9p:=>old Tread tag 10 fid 296 offset 5 count 512
>> > srvold9p:->Rread tag 10 count 3 'ps
>> > '
>> > srvold9p:<-Twrite tag 8 fid 298 offset 57 count 3667 'bootes            1    0:01   0:04      88K Await    init
>> > bootes'
>> > srvold9p:=>old Twrite tag 8 fid 298 offset 57 count 3667 'bootes            1    0:01   0:04      88K Await    init
>> > bootes'
>> > srvold9p: (pid 101, errstr read or write too large) wrote -1 to old system; should be 3683
> 
> it's a peculiarity of srvold9p that it seems not to log old R messages. 
> Not sure why, I'm about to turn this logging off anyways ... 

i'm not sure if the attached pic would explain it. i did a while
back while i was trying to understand srvold9p.

[-- Attachment #2: srvold9p.dvi --]
[-- Type: application/x-dvi, Size: 6044 bytes --]