impossible packet length ...

[Eric Anderson]

On Feb 8, 2009, at 3:31 AM, Danny Braniss wrote:

>>
>> --jI8keyz6grp/JLjh
>> Content-Type: text/plain; charset=us-ascii
>> Content-Disposition: inline
>> Content-Transfer-Encoding: quoted-printable
>>
>> On 2009-Feb-08 10:45:13 +0200, Danny Braniss <danny at cs.huji.ac.il>  
>> wrote:
>>> Feb  6 18:00:13 warhol-00.cs.huji.ac.il kernel: bce0: discard  
>>> frame w/o=20
>>> leading ethernet header (len 0 pkt len 0)
>> =2E..
>>> Feb  6 19:00:00 warhol-00.cs.huji.ac.il amd[715]: Unknown $  
>>> sequence in=20
>>> "rhost:=3D${RHOST};type:=3Dnfsl;fs:=3D${FS};rfs:=3D$huldig<C0>#^ZM- 
>>> ^KoM- a=
>> base"
>>> Feb  6 19:00:00 warhol-00.cs.huji.ac.il kernel: impossible packet  
>>> length=
>> =20
>>> (2068989523) from nfs server sunfire:/dist
>>>
>>> which seems to point fingers at bce...
>>
>> It does rather suggest that bce is not behaving.  What happens if you
>> turn off checksum off-loading?  This should make the kernel drop the
>> corrupt packets instead of trying to process them.  If practical, you
>> could also try (temporarily) plugging in a different NIC.
>>
> I have, and now it's a matter of waiting...
> Q: with rxcsum on, and a bad checksum packet is received, is it
>   dropped by the NIC? if not, then it somewhat explains the behaviour
>
> changing the nic is tough, but if needed will be done.
> 	danny
>
>> Peter Jeremy


We were hitting this quite a bit (also bce), and updated to a recent 7- 
branch and it seems to be behaving better for now.  Running 12 days so  
far (which is better than what we had been seeing).

Eric