Mike, et al.
I had the panic too. The problem is the order of initialization. It only
happened when you compile NETGRAPH support in the kernel instead of using it
as a module. When initialize netgraph a little bit later it works fine. In
netgraph.h there is a macro called NETGRAPH_INIT. I have changed the
SI_ORDER_ANY to SI_ORDER_LAST or SI_SUB_PSEUDO to something else (I can't
remember).
I am using the module. I'll check on this today and get a proper answer.
Peter
-----Original Message-----
From: [EMAIL PROTECTED]
[mailto:[EMAIL PROTECTED]]On Behalf Of Mike Tancsa
Sent: Tuesday, August 28, 2001 22:11
To: Garrett Wollman
Cc: [EMAIL PROTECTED]
Subject: Re: Runt frames = broken VLAN ?
At 12:54 PM 8/28/01 -0400, Garrett Wollman wrote:
><<On Tue, 28 Aug 2001 01:05:32 -0400, Mike Tancsa <[EMAIL PROTECTED]> said:
>
> > Can anyone tell me why the VLAN code might be causing my switches
(ciscos)
> > to see a lot of runt frames when the interface is in 802.1q trunking
> mode ?
>
>It's possible that the Cisco is (bogusly, IMHO) trying to enforce the
>Ethernet minimum frame length on the *de*capsulated frames. If you
>send a frame that's less than 60 octets long, it gets encapsulated
>(adding another four octets) and then padded by the interface up to 64
>octets. After the encapsulation is removed by the receiver, the frame
>appears to only be 60 octets long.
>
>I'd call it a Cisco bug. The minimum frame length in Ethernet arises
>from the electrical parameters of the original CSMA/CD Ethernet
>design; what matters is the number of clocks the transmitter is
>active, not the length of the payload.
If its a Cisco bug, would it not manifest it self consistently ? On other
ports, I have a 3620 and another catalyst both in 802.1q trunking mode, but
I dont see any runt frames there.
Also, who is the VLAN maintainer these days ? I ran into a panic that I
thought was netgraph related, but Archie Cobbs thinks it might be in the
VLAN code. I filed a PR on the issue
http://www.freebsd.org/cgi/query-pr.cgi?pr=30149
I saved the debug kernel as well as the core dump in case its needed, but
the problem is easy enough to repeat.
---Mike
To Unsubscribe: send mail to [EMAIL PROTECTED]
with "unsubscribe freebsd-net" in the body of the message
To Unsubscribe: send mail to [EMAIL PROTECTED]
with "unsubscribe freebsd-net" in the body of the message
