Re: [9fans] xen progress ...

["Ronald G. Minnich" <rminnich@lanl.gov>]

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