Subject: devel-digest V2 #204
From: [email-masked] (devel-digest)
To: [email-masked]

devel-digest          Tuesday, June 22 1999          Volume 02 : Number 204

In this issue:

    Re: video capture
    Re: video capture
    Re: Back to the floating point library optimisations...
    Re: Unable to access Serial Interface
    'marginal timeout'
    Re: Back to the floating point library optimisations...
    Bit length of double on ARM
    Re: Bit length of double on ARM
    Re: Bit length of double on ARM
    Re: Bit length of double on ARM
    Re: Back to the floating point library optimisations...
    Re: video capture
    DHCP claims failure, yet ping et al work ok?
    eth1 usage troubles
    Re: video capture
    Re: eth1 usage troubles

See the end of this digest for information about devel-digest.

----------------------------------------------------------------------

Date: Mon, 21 Jun 1999 01:38:38 -0400
From: Matthew Keller <[email-masked]>
Subject: Re: video capture

This is a cryptographically signed message in MIME format.

- --------------ms7E40739A301D4DF294387F2E
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit

Steve Schwartz wrote:
> 
> thanks for the help so far with the video capture.  Tell me something, has
> anyone tried to get full motion capture?  I'd like to have it record a few
> minutes of continuous video.

	Yup you can do it. I don't have the code, however, as my NW recently
bit it, and was reimaged. I based my code on the FMV from new_test.c
(I'm pretty sure). I wrote a neat perl interface too... Oh well. 
- -- 

             -> Matthew Keller <-
            Distributed Computing
             Windows/UNIX Support
              and Host Services
                 Kellas Hall
   State University of New York at Potsdam	
         http://mattwork.potsdam.edu/
- -
     They wouldn't give you the time of day.
     They said you weren't a player.
     They wouldn't accept your calls.
     They are holding on line three.
- -
 PGP Keys -
    http://mattwork.potsdam.edu/crypto/
- --------------ms7E40739A301D4DF294387F2E
Content-Type: application/x-pkcs7-signature; name="smime.p7s"
Content-Transfer-Encoding: base64
Content-Disposition: attachment; filename="smime.p7s"
Content-Description: S/MIME Cryptographic Signature

- --------------ms7E40739A301D4DF294387F2E--

- ---
This message processed by the Netwinder.Org news2mail gateway.

- --
This list is run automagically by Majordomo 1.94.4
Please send email questions to [email-masked]
To UNSUBSCRIBE: email [email-masked] with
"unsubscribe devel" as the body of your message.

------------------------------

Date: Mon, 21 Jun 1999 01:58:14 -0400
From: "Steve Schwartz" <[email-masked]>
Subject: Re: video capture

If you should have the urge to try it again, please let me know

Anybody else got one?  I don't know enough about that stuff to try and
program one.

- -Steve

Matthew Keller <[email-masked]> wrote in message
news:[email-masked]...
> Steve Schwartz wrote:
> >
> > thanks for the help so far with the video capture.  Tell me something,
has
> > anyone tried to get full motion capture?  I'd like to have it record a
few
> > minutes of continuous video.
>
> Yup you can do it. I don't have the code, however, as my NW recently
> bit it, and was reimaged. I based my code on the FMV from new_test.c
> (I'm pretty sure). I wrote a neat perl interface too... Oh well.
> --
>
>              -> Matthew Keller <-
>             Distributed Computing
>              Windows/UNIX Support
>               and Host Services
>                  Kellas Hall
>    State University of New York at Potsdam
>          http://mattwork.potsdam.edu/
> -
>      They wouldn't give you the time of day.
>      They said you weren't a player.
>      They wouldn't accept your calls.
>      They are holding on line three.
> -
>  PGP Keys -
>     http://mattwork.potsdam.edu/crypto/

- ---
This message processed by the Netwinder.Org news2mail gateway.

- --
This list is run automagically by Majordomo 1.94.4
Please send email questions to [email-masked]
To UNSUBSCRIBE: email [email-masked] with
"unsubscribe devel" as the body of your message.

------------------------------

Date: Mon, 21 Jun 1999 10:12:57 +0200
From: Jan Rinze <[email-masked]>
Subject: Re: Back to the floating point library optimisations...

Andrew Coles wrote:

> OK, I've been looking at the floating point stuff that people have
> provided, plus the egcs float library.
>
> After thought and poking around I have decided to optimise the egcs float
> library code (fp-bit.c, floatlib.c) as that is what is used on my platform
> (NetBSD/arm32), and ARM Linux can benefit from it using a the -msoft-float
> compile-time flag. I know the Netwinder emulates the arm FPU to provide
> floating point support, but I wouldn't be able to test any work I did on
> the FP emulator since I don't run ARM Linux.
>
> Any comments greatly appreciated - to the group, or mail me, your choice.
> Thanks to all the people who have answered questions, provided code and so
> on.
>
> One more maths-related note - I have found a 3-instruction / bit assembler
> integer square-root function by Wilco Dijkstra. If this would benefit the
> Netwinder maths code then I'll post it to the group / whoever wants it.
>
> Regards
>
> Andrew
> ------

Wilco has much more on these issues and works currently at ARM ltd.
If needed I can pass any questions on to him.

I colaborated with him on a 3d project as well as a TTF renderer quit some
time ago.

Much of the stuff is optimised for ARM 3 but for SA we can optimise further.

Maybe I can persuade him to comment on some issues in this news group.
He does follow the ARM news group though.

Jan Rinze.

- ---
This message processed by the Netwinder.Org news2mail gateway.

- --
This list is run automagically by Majordomo 1.94.4
Please send email questions to [email-masked]
To UNSUBSCRIBE: email [email-masked] with
"unsubscribe devel" as the body of your message.

------------------------------

Date: Mon, 21 Jun 1999 08:25:17 -0700
From: Steven Ng <[email-masked]>
Subject: Re: Unable to access Serial Interface

That fixed it.  Thank you.

Steven

Philipp Grau wrote:

> On Fri, 18 Jun 1999 18:14:11 -0700, Steven Ng wrote:
> >I have been trying to configure my serial interface /dev/cua0 using
> >setserial.  setserial statserial both return operation not supported by
> >device.  I also attempted to do this to dev/cua1-3 also.  Is there something
> >I need to do to get the serial interface up and running before I can access
> >it with setserial, or do I have a potential hardware problem?
>
> Try:
>
> insmod serial
>
> It loos like you are missing serial support in the kernel,
> so load the apropiate module.
>
> \bye
> Philipp
>
> --
>  Philipp Grau               | Freie Universitaet Berlin
>  [email-masked]  | Zentraleinrichtung fuer Datenverarbeitung
>                             |
>     We had joy, we had fun, | we had Pacman on the sun...

- ---
This message processed by the Netwinder.Org news2mail gateway.

- --
This list is run automagically by Majordomo 1.94.4
Please send email questions to [email-masked]
To UNSUBSCRIBE: email [email-masked] with
"unsubscribe devel" as the body of your message.

------------------------------

Date: Mon, 21 Jun 1999 11:48:36 -0500
From: "B. Darryl DeGraff" <[email-masked]>
Subject: 'marginal timeout'

We have a new NetWinder and are perparing to configure it to our
specifications.  Twice we got this message, once when changing settings
in NeTTrom, once when entering a command at the command line:
    hda: marginal timeout

Any ideas?

darryl (li-cor)

- ---
This message processed by the Netwinder.Org news2mail gateway.

- --
This list is run automagically by Majordomo 1.94.4
Please send email questions to [email-masked]
To UNSUBSCRIBE: email [email-masked] with
"unsubscribe devel" as the body of your message.

------------------------------

Date: Mon, 21 Jun 1999 13:23:55 -0400
From: [email-masked]
Subject: Re: Back to the floating point library optimisations...

Andrew Coles wrote:
> 
> OK, I've been looking at the floating point stuff that people have
> provided, plus the egcs float library.

<snip>

> One more maths-related note - I have found a 3-instruction / bit assembler
> integer square-root function by Wilco Dijkstra. If this would benefit the
> Netwinder maths code then I'll post it to the group / whoever wants it.

Whenever I get my butt in gear for the fixed-point lib for SA-110 I'd
write someday,
this could be *very* useful.  Post away. 
 
> Regards
> 
> Andrew
> ------

- -- 
"We're only in it for the volume."
            -- Black Sabbath

- ---
This message processed by the Netwinder.Org news2mail gateway.

- --
This list is run automagically by Majordomo 1.94.4
Please send email questions to [email-masked]
To UNSUBSCRIBE: email [email-masked] with
"unsubscribe devel" as the body of your message.

------------------------------

Date: Mon, 21 Jun 1999 13:31:29 -0400
From: [email-masked]
Subject: Bit length of double on ARM

(Lessee if I can get the hang of this thing called Usenet...)

sizeof(double) returns 8 but whenever I do:

inline double raw2ARMdouble(int foo){
  double bar;
  bar = (rawmsg.message[foo] | rawmsg.message[foo+1]<<8 |
rawmsg.message[foo+2]<<16 | rawmsg.message[foo+3]<<24)<<32 |
(rawmsg.message[foo+4] | rawmsg.message[foo+5]<<8 |
rawmsg.message[foo+6]<<16 | rawmsg.message[foo+7]<<24); 
  return bar;
}
(Where rawmsg.message[foo] is an unsigned char)

I get:

cd ~/NTH/GPS/
gcc gpsparser.c -o gpsparser -D_BSD_SOURCES -fsigned-chars
gpsparser.c: In function `raw2ARMdouble':
gpsparser.c:225: warning: left shift count >= width of type

and it's the "<<32" that causes it even though a double is 64 bits.
Where am I going wrong?

- -- 
"We're only in it for the volume."
            -- Black Sabbath

- ---
This message processed by the Netwinder.Org news2mail gateway.

- --
This list is run automagically by Majordomo 1.94.4
Please send email questions to [email-masked]
To UNSUBSCRIBE: email [email-masked] with
"unsubscribe devel" as the body of your message.

------------------------------

Date: Mon, 21 Jun 1999 14:09:30 -0400
From: "Andrew E. Mileski" <[email-masked]>
Subject: Re: Bit length of double on ARM

[email-masked] wrote:
> inline double raw2ARMdouble(int foo){
>   double bar;
>   bar = (rawmsg.message[foo] | rawmsg.message[foo+1]<<8 |
> 
> gpsparser.c: In function `raw2ARMdouble':
> gpsparser.c:225: warning: left shift count >= width of type
> 
> and it's the "<<32" that causes it even though a double is 64 bits.
> Where am I going wrong?

You are shifting a char, not a double.

- --
Andrew E. Mileski - Software Engineer
Rebel.com  http://www.rebel.com/

- ---
This message processed by the Netwinder.Org news2mail gateway.

- --
This list is run automagically by Majordomo 1.94.4
Please send email questions to [email-masked]
To UNSUBSCRIBE: email [email-masked] with
"unsubscribe devel" as the body of your message.

------------------------------

Date: Mon, 21 Jun 1999 14:51:54 -0400
From: [email-masked]
Subject: Re: Bit length of double on ARM

"Andrew E. Mileski" wrote:
> 
> [email-masked] wrote:
> > inline double raw2ARMdouble(int foo){
> >   double bar;
> >   bar = (rawmsg.message[foo] | rawmsg.message[foo+1]<<8 |
> >
> > gpsparser.c: In function `raw2ARMdouble':
> > gpsparser.c:225: warning: left shift count >= width of type
> >
> > and it's the "<<32" that causes it even though a double is 64 bits.
> > Where am I going wrong?
> 
> You are shifting a char, not a double.

Okay, then this seems to imply that the compiler promotes the chars to
int
before shifting because this line compiles silently:

msg48.msgtyp132 = rawmsg.message[2] | rawmsg.message[3]<<8 |
rawmsg.message[4]<<16 | rawmsg.message[5]<<24;

If so, I suppose I could do (long long)foo to get 64-bit ints, but that
is a gcc-ism.
 
> --
> Andrew E. Mileski - Software Engineer
> Rebel.com  http://www.rebel.com/

- -- 
"We're only in it for the volume."
            -- Black Sabbath

- ---
This message processed by the Netwinder.Org news2mail gateway.

- --
This list is run automagically by Majordomo 1.94.4
Please send email questions to [email-masked]
To UNSUBSCRIBE: email [email-masked] with
"unsubscribe devel" as the body of your message.

------------------------------

Date: Mon, 21 Jun 1999 15:25:53 -0400
From: "Andrew E. Mileski" <[email-masked]>
Subject: Re: Bit length of double on ARM

[email-masked] wrote:
> > You are shifting a char, not a double.
> 
> Okay, then this seems to imply that the compiler promotes the chars to
> int
> before shifting because this line compiles silently:
> 
> msg48.msgtyp132 = rawmsg.message[2] | rawmsg.message[3]<<8 |
> rawmsg.message[4]<<16 | rawmsg.message[5]<<24;

Silent promotion to int is quite common.

> If so, I suppose I could do (long long)foo to get 64-bit ints, but that
> is a gcc-ism.

True, but it works.  Could also use int64_t or off64_t or whatever
the headers define (stdint.h sys/types.h ... )

- --
Andrew E. Mileski - Software Engineer
Rebel.com  http://www.rebel.com/

- ---
This message processed by the Netwinder.Org news2mail gateway.

- --
This list is run automagically by Majordomo 1.94.4
Please send email questions to [email-masked]
To UNSUBSCRIBE: email [email-masked] with
"unsubscribe devel" as the body of your message.

------------------------------

Date: 21 Jun 1999 20:38:05 GMT
From: "Andrew Coles" <[email-masked]>
Subject: Re: Back to the floating point library optimisations...

As requested - the document detailing the 3 cycle / bit SQRT routine is
attached to the bottom of this mail - it's a HTML document so cut & paste
it and load it into a browser.

I notice you're doing fixed point arithmetic as well - I've got some 32.32
routines I've written to use a in a few programs, I'll mail them to you if
you want a look.

HTH

Andrew

- -----

<HTML><BODY>
<a href="mailto:[email-masked]">Wilco Dijkstra</a> provided
the following ARM code routine which takes 3 cycles per bit with a 3
cycle overhead for a total of 51 cycles. He even showed how he derived
it. Everything from here till the heading at the start of the next section
is taken from the original article which was posted on the 20th of June
1996.

<DL>
<DT>Goal
<DD>Calculate root = INT (SQRT (N)), for N = 0 .. 2^32 -1
<DT>Idea
<DD> Successive approximation of the equation (root + delta) ^ 2 = N until
      delta &lt; 1. If delta &lt; 1 we have the integer part of SQRT (N).
      Use delta = 2^i for i = 15 .. 0.
<DT>Init
<DD>Start with root = 0 and delta = 2^15.
<DT>Step
<DD>
<LISTING>
If (root + delta) ^ 2 &lt;= N then
  root += delta
endif
delta = delta / 2
</LISTING>
This step is repeated until delta = 0. Now root = INT (SQRT (N)).
<DT>Idea
<DD> (root + delta) ^ 2 = root^2 + 2 * root * delta + delta^2 = root^2 +
     delta * (2 * root + delta)<BR>
      Now take M = N - root^2, and update M in each step of the algorithm:
<DT>Init
<DD>M = N, delta = 2^15
<DT> Step
<DD>
<LISTING>
if delta * (2 * root + delta) &lt;= M then
  M -= delta * (2 * root + delta)
  root += delta
endif
delta = delta / 2
</LISTING>
      We need to calculate delta * (2 * root + delta) fast, without any
      multiplications. This is possible because delta is a power of 2. 
      In ARM code we might optimize a bit by taking root' = root *2, and
      using loop unrolling for delta = 2^i.
<LISTING>
   MOV   M, N
[ unroll for i = 15 .. 0
   ADD   t, root, #1 &lt;&lt; i    ; t = 2 * root + delta
   CMP   M, t, LSL #i        ; if t * delta &lt;= M then
   SUBHS M, M, t, LSL #i     ;   M -= t * delta
   ADDHS root, root, #2 &lt;&lt; i ;   root += delta
]
   MOV   root, root, LSR #1  
</LISTING>
</DL>

OK, now we have a 4-cycle per bit routine. For 3-cycle per bit we have to
leave one instruction out... The idea is to calculate 2 * root + delta 
successively (so we don't need the ADD t, root, #1 &lt;&lt; i instruction).
In binary the value 2 * root + delta looks like this:
<PRE>
  xxxx01  ; the xxxx bits are the value of root, the zero is from 2 * root,

            and the 1 is the delta bit.
</PRE>
Now look at successive values of 2 * root + delta:
<PRE>
  xxxx010000   
  xxxxa01000  ; a is the new bit of root (from root += delta)
  xxxxab0100  ; b new bit of root
  xxxxabc010 
</PRE>
It can be seen that the new bit of the new approximation of root is put on
the zero bit of the previous approximation, while the delta bit shifts one
position. We want to calculate this new approximation in only ONE
instruction!
If you forget about the delta bit, and shift root to the right, you would
get:
<PRE>
   xxxx
  xxxxa
 xxxxab
</PRE>
This is an ADC root, root, root instruction. Now, we use a rotate right,
instead of a shift right:
<PRE>
010000xxxx
01000xxxxa
0100xxxxab
</PRE>
This can be done with an ADC root, offset, root, LSL #1 instruction. 
Take offset = 3^30:
<PRE>
010000xxxx  ; original root
10000xxxx0  ; root LSL #1
10000xxxxa  ; root LSL #1 + carry bit
01000xxxxa  ; ADC root, offset, root, LSL #1
</PRE>
Et voila! Now we have the following ARM routine:

<P><LISTING><PRE>
<BR>; IN :  n 32 bit unsigned integer
<BR>; OUT:  root = INT (SQRT (n))
<BR>; TMP:  offset

<BR>MOV    offset, #3 &lt;&lt; 30
<BR>MOV    root, #1 &lt;&lt; 30
<BR>[ unroll for i = 0 .. 15
<BR>CMP    n, root, ROR #2 * i
<BR>SUBHS  n, n, root, ROR #2 * i
<BR>ADC    root, offset, root, LSL #1
<BR>]
<BR>BIC    root, root, #3 &lt;&lt; 30  ; for rounding add: CMP n, root  ADC
root, #1
</LISTING></PRE><P>
This routine takes 3 * 16 + 3 = 51 cycles for a root of a 32 bit integer.  
Of course, there are many other possibilities. The routine can be used with
some extra code which uses early termination if n is less than 32 bit. Also
fixed point versions are possible, or roots of 64 bit numbers. Even looped
versions are no problem: Shift in 8 or 16 bits at a time,
so you need only to unroll 4 or 8 times (overhead 6 cycles).

</BODY></HTML>

- ---
This message processed by the Netwinder.Org news2mail gateway.

- --
This list is run automagically by Majordomo 1.94.4
Please send email questions to [email-masked]
To UNSUBSCRIBE: email [email-masked] with
"unsubscribe devel" as the body of your message.

------------------------------

Date: Mon, 21 Jun 1999 18:26:01 -0400
From: Tim Rowledge <[email-masked]>
Subject: Re: video capture

Matthew Keller <[email-masked]> wrote:

>	Yup you can do it. I don't have the code, however, as my NW recently
>bit it, and was reimaged. I based my code on the FMV from new_test.c
>(I'm pretty sure). I wrote a neat perl interface too... Oh well. 
If you have really done this and can provide some recollection of how, or even
the code, I would be very interested. We recently had a thread about memory
bandwidth problems to/from the video system after I tried to do full speed video
capture and found it possible to get only ~10fps.
I need to get 30fps (NYSC source) into the machine , spend ~100mips on
compressing it and then get the compressed stream out via the eth1 port.

tim

- ---
This message processed by the Netwinder.Org news2mail gateway.

- --
This list is run automagically by Majordomo 1.94.4
Please send email questions to [email-masked]
To UNSUBSCRIBE: email [email-masked] with
"unsubscribe devel" as the body of your message.

------------------------------

Date: Mon, 21 Jun 1999 18:30:22 -0400
From: Tim Rowledge <[email-masked]>
Subject: DHCP claims failure, yet ping et al work ok?

I've just started using my number2 NW and set it up for DHCP on eth1. During
boting, it claims dhcp failed, and yet ping, telnet etc seem to work just fine.
Telnet'ing  to another machine and using 'who am i' reports a sensible IP
number that I could then telnet _to_  and it even got the NW's name correct.

I'm a little puzzled since I naively expected none of the net stuff to work if
it can't get an IP number sorted out. Have I missed something, or has the dhcp
code that claims failure failed? 

ti

- ---
This message processed by the Netwinder.Org news2mail gateway.

- --
This list is run automagically by Majordomo 1.94.4
Please send email questions to [email-masked]
To UNSUBSCRIBE: email [email-masked] with
"unsubscribe devel" as the body of your message.

------------------------------

Date: Mon, 21 Jun 1999 18:36:54 -0400
From: Tim Rowledge <[email-masked]>
Subject: eth1 usage troubles

On my number 1 NW, I am unable to persuade the eth1 port to work acceptably. It
usually fails dhcp, and if I try a static IP number it fails ping about 40% of
the time. I have connected to both a known working 10BaseT wire and a known
working 100B - number two is happily using the 100B wire. The eth0 port seems
to be fine.

I have even gone so far as to reload the dm12 disk image on this machine in
case I had messed up something in my early thrashing around. I _have_ run
'insmod tulip_upgd' - something I forgot to do on my number two machine - the
one that is happy!

Is there any diagnostic or check I can run that might provide further clues?
Any physical checkout possible? Can I remove the tulip_upgd ?
I really need to get 100B runing on both the machines since I have to make the
talk to each other via it!

tim

- ---
This message processed by the Netwinder.Org news2mail gateway.

- --
This list is run automagically by Majordomo 1.94.4
Please send email questions to [email-masked]
To UNSUBSCRIBE: email [email-masked] with
"unsubscribe devel" as the body of your message.

------------------------------

Date: Mon, 21 Jun 1999 18:08:03 -0400
From: Matthew Keller <[email-masked]>
Subject: Re: video capture

This is a cryptographically signed message in MIME format.

- --------------msF44B109490928D64E98F8C42
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit

Tim Rowledge wrote:
> 
> Matthew Keller <[email-masked]> wrote:
> 
> >       Yup you can do it. I don't have the code, however, as my NW recently
> >bit it, and was reimaged. I based my code on the FMV from new_test.c
> >(I'm pretty sure). I wrote a neat perl interface too... Oh well.
> If you have really done this and can provide some recollection of how, or even
> the code, I would be very interested. We recently had a thread about memory
> bandwidth problems to/from the video system after I tried to do full speed video
> capture and found it possible to get only ~10fps.
> I need to get 30fps (NYSC source) into the machine , spend ~100mips on
> compressing it and then get the compressed stream out via the eth1 port.
	
	I got no better than 10fps... It wasn't anything too much different
than the new_test.c routine for 'super hi res' or whatever it was
called, other than piping the incoming from raw (YUV I believe, but
perhaps it was something else)->mpg frame routine. I used a proprietary
MPG interface to write/compress the data.

- -- 

             -> Matthew Keller <-
            Distributed Computing
             Windows/UNIX Support
              and Host Services
                 Kellas Hall
   State University of New York at Potsdam	
         http://mattwork.potsdam.edu/
- -
     They wouldn't give you the time of day.
     They said you weren't a player.
     They wouldn't accept your calls.
     They are holding on line three.
- -
 PGP Keys -
    http://mattwork.potsdam.edu/crypto/
- --------------msF44B109490928D64E98F8C42
Content-Type: application/x-pkcs7-signature; name="smime.p7s"
Content-Transfer-Encoding: base64
Content-Disposition: attachment; filename="smime.p7s"
Content-Description: S/MIME Cryptographic Signature

- --------------msF44B109490928D64E98F8C42--

- ---
This message processed by the Netwinder.Org news2mail gateway.

- --
This list is run automagically by Majordomo 1.94.4
Please send email questions to [email-masked]
To UNSUBSCRIBE: email [email-masked] with
"unsubscribe devel" as the body of your message.

------------------------------

Date: 22 Jun 1999 00:26:34 GMT
From: "Rod m. Stewart" <[email-masked]>
Subject: Re: eth1 usage troubles

Tim Rowledge <[email-masked]> wrote:
> On my number 1 NW, I am unable to persuade the eth1 port to work acceptably. It
> usually fails dhcp, and if I try a static IP number it fails ping about 40% of
> the time. I have connected to both a known working 10BaseT wire and a known
> working 100B - number two is happily using the 100B wire. The eth0 port seems
> to be fine.

[...]

> I really need to get 100B runing on both the machines since I have to make the
> talk to each other via it!

What kernel are you running?  I've never been able to run a NetWinder at 
100MB reliably with a 2.2 kernel (don't know about 2.0.X, I have enough
trouble booting into it, the odd time I need to test the old Acorn with the
current one... :-) )

The current consensus seems to be that there is a buffer overflow in 
the Tulip driver that only shows up under a high load (ie. 100 MB).
I've heard it might work at 100MB on a cross over cable, but I've not
tried it.

Probably not what you wanted to hear, but it is all I have a present..

- -Rms

- ---
This message processed by the Netwinder.Org news2mail gateway.

- --
This list is run automagically by Majordomo 1.94.4
Please send email questions to [email-masked]
To UNSUBSCRIBE: email [email-masked] with
"unsubscribe devel" as the body of your message.

------------------------------

End of devel-digest V2 #204
***************************

--
This list is run automagically by Majordomo 1.94.4
Please send email questions to [email-masked]
To UNSUBSCRIBE: email [email-masked] with
"unsubscribe devel-digest" as the body of your message.