🚀 go-pugleaf

In article <2ggh1q$c5@starbug.apana.org.au>, mike@starbug.apana.org.au (Mike Battersby) writes:
>    When running slip, I get kernel panics whenever I try to use a
>largish sized mtu.  I'm running a vanilla pl14, net2d code, on a
>386-40 with 4mb of RAM. The default mtu size for the link I'm running
>(dynamically allocated, I use dip to dial) seems to be 296, but when
>I try to increase this (to, say 1500) I get kernel panics. This happens
>whether or not the link is started with the larger mtu size (at the
>inital ifconfig) or if it is changed later. The kernel message
>tells me that the swapper has been killed, and then panics, with the
>EIP pointing into the do_timer() routine. 
>
>   Anyone have any ideas??
>
>Mike

Is it possible to specify *any* MTU value when initiating a connection,
or must the MTU value match the server's MTU value?

Mike
xxmcleis@indsvax1.indstate.edu

xxmcleis@indsvax1.indstate.edu writes:
>mike@starbug.apana.org.au (Mike Battersby) writes:
>>    When running slip, I get kernel panics whenever I try to use a
>>largish sized mtu.  I'm running a vanilla pl14, net2d code, on a
>>386-40 with 4mb of RAM. The default mtu size for the link I'm running
>>(dynamically allocated, I use dip to dial) seems to be 296, but when
>>I try to increase this (to, say 1500) I get kernel panics. This happens
>>whether or not the link is started with the larger mtu size (at the
>>inital ifconfig) or if it is changed later. The kernel message
>>tells me that the swapper has been killed, and then panics, with the
>>EIP pointing into the do_timer() routine. 
>
>Is it possible to specify *any* MTU value when initiating a connection,
>or must the MTU value match the server's MTU value?

I was (and still am) under the impression that you can specify any MTU
value you like.. If its smaller than the other ends (at least with pl14+)
packets will just get fragmented and then put back together, and if its
bigger than the other ends, they'll just come in okay..

As an update to my problem, I'm now getting intermittent kernel panics
when using SLIP, whether I change the mtu or not. Changing the mtu does
it every time, within about 30 seconds of any data transfer, and I've
had a couple when trying to read faulty disks (but only whilst SLIP'ing),
and once when trying to telnet in.  The kernel panics I get look like

Unable to handle kernel paging request at address c0400000
Oops: 0000
EIP: 0010:0012fda3			( raw_rcv() )
EFLAGS: 00010286
eax: 00000000  ebx: f25e12af  ecx: fff78505  edx: 00000000
esi: 00400000  edi: 001e1414  ebp: 001e1428
ds: 0018  es: 0018  fs: 002b  gs: 0002b
Pid 0, proces nr 0
ad 11 c3 e2 fb 83 d3 00 89 d8
task[0] (swapper) killed: unable to recover
kernel panic: Trying to free up swapper memory space
In swapper task - not syncing


The mtu problem only seems to happen at 14

mike@starbug.apana.org.au (Mike Battersby) writes:

>I was (and still am) under the impression that you can specify any MTU
>value you like.. If its smaller than the other ends (at least with pl14+)
>packets will just get fragmented and then put back together, and if its
>bigger than the other ends, they'll just come in okay..

It is pretty hard to see how you can get a panic by having the MTU too large.
But the MTUs should be the same at the 2 ends. For example if you say
the MTU is 1500 and the other end thinks it is 1006 then you might
send a 1200 byte packet: the other end will then probably throw the
packet away but if it is buggy it might crash. [If it is friendly it
might accept the big packet and only use the MTU to decide what size
packets to send but I wouldn't count on that.]

Bob Smart

xxmcleis@indsvax1.indstate.edu wrote:
: In article <2ggh1q$c5@starbug.apana.org.au>, mike@starbug.apana.org.au (Mike Battersby) writes:
: >    When running slip, I get kernel panics whenever I try to use a
: >largish sized mtu.  I'm running a vanilla pl14, net2d code, on a

: Is it possible to specify *any* MTU value when initiating a connection,
: or must the MTU value match the server's MTU value?

  Yes using dip. The command is get $mtu XXXX (for dip 3.3.2 and above).
  It is advisable to have MTU smaller or the same with ther server's MTU, this
  is to avoid fragmentation. Eventhough pl14 do support fragmentation/re-
  assembly, it is not good enough and you might get kernel panic.

  Hamid
  hamid@mhmsys.pc.my