Subject: Networking strangeness, osi_enet badness ? plus adb_key() operation
From: Charles McLachlan (cim@uk.research.att.com)
Date: Mon May 08 2000 - 03:31:49 MDT
Before I start moaning I'd just like say a massive thank you to the writers
of this fine piece of software. Every time I use it I am gobsmacked by how
wonderful it is.
But...
Situation: B&W MacG3 running a hacked version of Mol-0.9.41 on a precompiled
kernel I got from Rob Shaw's site (2.2.10 #1 Sat Oct 30 17:55:06 EDT
1999 ppc unknown)
I tried running Mol using the x display driver with my DISPLAY
set to point at my Intel machine, which is running a little endian,
RGB565 X server. Currently the x driver doesn't byte swap so I got funny
colours. Also my keyboard didn't work properly (pressing a button didn't
produce the right keypress)
Problem: as well as the colour problem, networking only worked intermittently
with lots of "<*> Can't allocate packet datas (143)" messages.
I had a bit of a go at patching the X driver, but then I thought, "X really
isn't the right protocol for this. What you really want is a nice simple
protocol designed from the ground up for remotely displaying things quickly and
efficiently. Something like VNC in fact"
http://www.uk.research.att.com/vnc
Once I'd got the vnc server working (just about) I tried turning on
networking (disable_osi_enet: no)
Problem: The "<*> Can't allocate packet datas (143)" appeared with even more
frequency than when running the X version and seemed correlated with mouse
waggling.
Guess: sheep_net is grabbing the interface (eth0) in it's entirety and
upsetting other threads that try to use it. Is this a feature? I can quite
imagine that MOL *needs* to grab the interface in order to properly fool MacOS,
but I hope that there's some sort of work around.
Also, I grepped for "Can't allocate" in the source distribution but could only
find it in pci_roms/osi_enet.pcirom and pci_roms/osi_enet.nw, not in any of the
source files. Where is the source for these roms?
I've looked at the sheep_net source (sheep.c) and have found that
sheep_net_write will return -ENOBUFS if dev_alloc_skb fails. Is this where the
"Can't allocate datas" are coming from? What does dev_alloc_skb do exactly? How
can I stop it failing? Have I got any of this right?
I'm also seeing a slight problem with keypresses. (This may well be my fault
and might be related to VNC sequencing issues but thought I raise the matter
just in case anyone else had seen such behaviour)
When I get an VNC keypress I do adb_key(code & ~0x80). On release I do
adb_key(code & 0x80), exactly as the X driver does. But, Mol doesn't seem to
act on the key press until another one is made. i.e. after typing "lard" into
simpletext, "lar" is displayed. Pressing another key ("c" for instance)
results in the "d" appearing. It's as if Mol is waiting for the next key down
before acting on the first one.
What is going on?
-- -=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-= Charlie McLachlan AT&T Research Lab. Cambridge. -=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=
This archive was generated by hypermail 2a24 : Mon May 08 2000 - 05:11:22 MDT