On Fri, 16 Feb 2007 00:35:51 +0200, Luigi Rizzo <[EMAIL PROTECTED]> wrote:
> will have a look at this.
> Which version of if_iwi.c are you using ?
Thanks.
$ grep -i __FBSDID /usr/src/sys/dev/iwi/if_iwi.c
__FBSDID("$FreeBSD: src/sys/dev/iwi/if_iwi.c,v 1.8.2.12 2007/01/23 22:17:48 jhb
Exp $");
It
jkim/bpf_feedback.diff
>
> I have received some positive feedbacks and comments. So, I made some
> adjustments/corrections to reflect them:
>
> http://people.freebsd.org/~jkim/bpf_feedback-20070215.diff
Hmmm. Those would be interesting thin
Yar Tikhiy wrote:
Do you have any architectural reservations about nested VLANs in
the main network stack? Presently, a one-line patch can allow a
vlan(4) to attach to another vlan(4), but I haven't heard about the
behaviour of the resulting setup yet.
After looking around it seems there is d
[This is a summary of something i have already discussed with other
people with no solution so far. I have some more data points if that
may help/ring any bell]
Since an upgrade of if_iwi.c to 1.8.2.10 (before i have been
running a prerelease of 1.8.2.7 which worked pretty reliably) I
have been e
On Thu, 15 Feb 2007, Sam Leffler wrote:
John Polstra wrote:
I have a Dell SC1435 server running an i386 -current system from
around the end of December, with a few selected updates applied. It
had been running reliably until early this morning, when the
following sequence of events happened.
On 15-Feb-2007 Kip Macy wrote:
> I mean a bug in if_bge.c - there are a lot of ways that this could
> happen - not calling M_GETHDR, mis-calling m_pullup etc.
There's no obvious bug in that part of the driver, but I'm going to
instrument it on the offending system to try to find out just what's
go
will have a look at this.
Which version of if_iwi.c are you using ?
cheers
luigi
On Thu, Feb 15, 2007 at 11:34:48PM +0200, V.Chukharev wrote:
> Hi,
>
> It seems that iwi driver cannot survive more than just a few cycles of
> switching down/up.
> In a place with a bad wireless co
Hi,
It seems that iwi driver cannot survive more than just a few cycles of
switching down/up.
In a place with a bad wireless connection I needed to do that quite a number of
times
(that was the simplest way to restore connectivity I knew), and after 5-10
cycles I needed
to reboot my notebook to
reflect them:
http://people.freebsd.org/~jkim/bpf_feedback-20070215.diff
Thanks,
Jung-uk Kim
___
freebsd-net@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-net
To unsubscribe, send any mail to "[EMAIL PROTECTED]"
On Thursday 15 February 2007 04:17 am, Yar Tikhiy wrote:
> On Wed, Feb 14, 2007 at 06:05:15PM -0500, Jung-uk Kim wrote:
> > I was playing with some BPF ideas for few days and I added two
> > new features. SEESENT flag is extended to see only outgoing
> > packets, which is analogous to libpcap's PC
> Either way it sounds like someone has discovered a DOS in bge.
No, it just about has to be a bug -- either in the mbuf allocator, the
driver, or the NIC hardware. M_PKTHDR is a flag in the mbuf header,
an area that isn't touched by packet data. The driver allocates
all of its receive mbufs wi
On 15-Feb-2007 Kip Macy wrote:
>>
>> The "discard frame w/o packet header" message comes from ether_input()
>> if it gets an mbuf that doesn't have the M_PKTHDR flag set. That
>> can't happen unless something is very wrong with the system. I'd like
>> to make it a panic. At least then the machin
John Polstra wrote:
> I have a Dell SC1435 server running an i386 -current system from
> around the end of December, with a few selected updates applied. It
> had been running reliably until early this morning, when the
> following sequence of events happened. First, this message was
> logged:
>
On 2/15/07, Kip Macy <[EMAIL PROTECTED]> wrote:
>
> The "discard frame w/o packet header" message comes from ether_input()
> if it gets an mbuf that doesn't have the M_PKTHDR flag set. That
> can't happen unless something is very wrong with the system. I'd like
> to make it a panic. At least t
The "discard frame w/o packet header" message comes from ether_input()
if it gets an mbuf that doesn't have the M_PKTHDR flag set. That
can't happen unless something is very wrong with the system. I'd like
to make it a panic. At least then the machine would reboot instead of
just becoming unre
I have a Dell SC1435 server running an i386 -current system from
around the end of December, with a few selected updates applied. It
had been running reliably until early this morning, when the
following sequence of events happened. First, this message was
logged:
Feb 15 07:14:29 rock kernel:
Andrew Thompson wrote:
On Wed, Feb 14, 2007 at 10:18:49PM +, Bruce M Simpson wrote:
Hi,
I have tested my 802.1p input patch with vlans configured. So far so good.
It is now available from:
http://people.FreeBSD.org/~bms/dump/latest-8021p.diff
/*
* If the device did not perfor
On Wed, Feb 14, 2007 at 10:18:49PM +, Bruce M Simpson wrote:
> Hi,
>
> I have tested my 802.1p input patch with vlans configured. So far so good.
>
> It is now available from:
> http://people.FreeBSD.org/~bms/dump/latest-8021p.diff
>
/*
* If the device did not perform decapsulatio
On Wed, Feb 14, 2007 at 06:05:15PM -0500, Jung-uk Kim wrote:
> I was playing with some BPF ideas for few days and I added two new
> features. SEESENT flag is extended to see only outgoing packets,
> which is analogous to libpcap's PCAP_D_OUT direction. Thus SEESENT
> is now called DIRECTION.
On Wed, Feb 14, 2007 at 10:18:49PM +, Bruce M Simpson wrote:
>
> What has not been tested or considered is the situation where we have
> nested VLANs. At least one individual has asked about this feature. At
> the moment, I'd suggest that only Netgraph potentially deals with this
> rather than
20 matches
Mail list logo
