Re: kern/126874: [vlan]: Zebra problem if ifconfig vlanX destroy
Old Synopsis: Zebra problem if ifconfig vlanX destroy New Synopsis: [vlan]: Zebra problem if ifconfig vlanX destroy Responsible-Changed-From-To: freebsd-i386->freebsd-net Responsible-Changed-By: remko Responsible-Changed-When: Wed Aug 27 06:31:52 UTC 2008 Responsible-Changed-Why: Move to the -net list. http://www.freebsd.org/cgi/query-pr.cgi?pr=126874 ___ freebsd-net@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-net To unsubscribe, send any mail to "[EMAIL PROTECTED]"
Re: kern/77913: commit references a PR
The following reply was made to PR kern/77913; it has been noted by GNATS. From: [EMAIL PROTECTED] (dfilter service) To: [EMAIL PROTECTED] Cc: Subject: Re: kern/77913: commit references a PR Date: Wed, 27 Aug 2008 04:56:01 + (UTC) imp 2008-08-27 04:55:37 UTC FreeBSD src repository Modified files: share/man/man4 wi.4 Log: SVN rev 182238 on 2008-08-27 04:55:37Z by imp Add recent ELSA additions to wi(4), plus make sure the list matches the driver for ELSA. PR: 77913 Submitted by: Daan Vreeken MFC after: 3 days Revision ChangesPath 1.79 +3 -0 src/share/man/man4/wi.4 ___ [EMAIL PROTECTED] mailing list http://lists.freebsd.org/mailman/listinfo/cvs-all To unsubscribe, send any mail to "[EMAIL PROTECTED]" ___ freebsd-net@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-net To unsubscribe, send any mail to "[EMAIL PROTECTED]"
Re: kern/77913: commit references a PR
The following reply was made to PR kern/77913; it has been noted by GNATS. From: [EMAIL PROTECTED] (dfilter service) To: [EMAIL PROTECTED] Cc: Subject: Re: kern/77913: commit references a PR Date: Wed, 27 Aug 2008 04:53:30 + (UTC) imp 2008-08-27 04:52:27 UTC FreeBSD src repository Modified files: sys/dev/pccard pccarddevs sys/dev/wi if_wi_pccard.c Log: SVN rev 182236 on 2008-08-27 04:52:27Z by imp The APDL-325 is a Wireless LAN pcmcia adapter that sits inside some Billion Access Points. Fix wi(4) to recognise the adapter. PR: 77913 Submitted by: Daan Vreeken [PA4DAN] MFC after: 3 days Revision ChangesPath 1.135 +1 -0 src/sys/dev/pccard/pccarddevs 1.62 +1 -0 src/sys/dev/wi/if_wi_pccard.c ___ [EMAIL PROTECTED] mailing list http://lists.freebsd.org/mailman/listinfo/cvs-all To unsubscribe, send any mail to "[EMAIL PROTECTED]" ___ freebsd-net@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-net To unsubscribe, send any mail to "[EMAIL PROTECTED]"
Re: kern/77913: [wi] [patch] Add the APDL-325 WLAN pccard to wi(4)
Synopsis: [wi] [patch] Add the APDL-325 WLAN pccard to wi(4) State-Changed-From-To: open->patched State-Changed-By: imp State-Changed-When: Tue Aug 26 22:52:32 MDT 2008 State-Changed-Why: Committed to head. http://www.freebsd.org/cgi/query-pr.cgi?pr=77913 ___ freebsd-net@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-net To unsubscribe, send any mail to "[EMAIL PROTECTED]"
Re: Small patch to multicast code...
At Tue, 26 Aug 2008 17:56:13 -0700,
Sam Leffler wrote:
>
> [EMAIL PROTECTED] wrote:
> > At Tue, 26 Aug 2008 14:50:33 + (UTC),
> > Bjoern A. Zeeb wrote:
> >
> >> On Tue, 26 Aug 2008, George V. Neville-Neil wrote:
> >>
> >> Hi,
> >>
> >>
> >>> At Mon, 25 Aug 2008 21:40:38 +0200,
> >>> John Hay wrote:
> >>>
> I have tried it and it does fix my problem. RIP2 over multicast works
> again. :-)
>
> >>> Good to hear. I'm waiting on a bit more feedback but I think I'll be
> >>> checking this in soon, with a big comment talking about the
> >>> performance implications etc.
> >>>
> >> So wait a second; what was the m_pullup vs. m_dup thing? Has anyone
> >> actually tried that? I mean using a sledgehammer if a mitten would be
> >> enough is kind of .. uhm. You get it.
> >>
> >
> > Perhaps I'm confused, I've been off dealing with other issues for a
> > few days, but m_pullup doesn't make a copy of the packet or its
> > fields, only makes sure that it's contiguous in memory. Am I wrong in that?
> >
> > Since the bug is that two pieces of code modify the same data, in ways
> > that interfere, I'm not sure how we can avoid making a copy. It might
> > be nice to limit the copy, but we'd still need two copies, one for the
> > loopback device and one for the real device.
> >
> >
> pull the headers up. copy just the headers. no deep copy.
>
I'm confused, if it's these lines that are screwed up:
/* If needed, compute the checksum and mark it as valid. */
if (copym->m_pkthdr.csum_flags & CSUM_DELAY_DATA) {
in_delayed_cksum(copym);
copym->m_pkthdr.csum_flags &= ~CSUM_DELAY_DATA;
copym->m_pkthdr.csum_flags |=
CSUM_DATA_VALID | CSUM_PSEUDO_HDR;
copym->m_pkthdr.csum_data = 0x;
in particular that last line, then how does pulling up the header
help? That's not part of the packet, that's the checksum data in the
pkthdr itself.
Best,
George
___
freebsd-net@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-net
To unsubscribe, send any mail to "[EMAIL PROTECTED]"
Re: Small patch to multicast code...
[EMAIL PROTECTED] wrote: At Tue, 26 Aug 2008 14:50:33 + (UTC), Bjoern A. Zeeb wrote: On Tue, 26 Aug 2008, George V. Neville-Neil wrote: Hi, At Mon, 25 Aug 2008 21:40:38 +0200, John Hay wrote: I have tried it and it does fix my problem. RIP2 over multicast works again. :-) Good to hear. I'm waiting on a bit more feedback but I think I'll be checking this in soon, with a big comment talking about the performance implications etc. So wait a second; what was the m_pullup vs. m_dup thing? Has anyone actually tried that? I mean using a sledgehammer if a mitten would be enough is kind of .. uhm. You get it. Perhaps I'm confused, I've been off dealing with other issues for a few days, but m_pullup doesn't make a copy of the packet or its fields, only makes sure that it's contiguous in memory. Am I wrong in that? Since the bug is that two pieces of code modify the same data, in ways that interfere, I'm not sure how we can avoid making a copy. It might be nice to limit the copy, but we'd still need two copies, one for the loopback device and one for the real device. pull the headers up. copy just the headers. no deep copy. Sam ___ freebsd-net@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-net To unsubscribe, send any mail to "[EMAIL PROTECTED]"
Re: Small patch to multicast code...
At Tue, 26 Aug 2008 14:50:33 + (UTC), Bjoern A. Zeeb wrote: > > On Tue, 26 Aug 2008, George V. Neville-Neil wrote: > > Hi, > > > At Mon, 25 Aug 2008 21:40:38 +0200, > > John Hay wrote: > >> > >> I have tried it and it does fix my problem. RIP2 over multicast works > >> again. :-) > > > > Good to hear. I'm waiting on a bit more feedback but I think I'll be > > checking this in soon, with a big comment talking about the > > performance implications etc. > > So wait a second; what was the m_pullup vs. m_dup thing? Has anyone > actually tried that? I mean using a sledgehammer if a mitten would be > enough is kind of .. uhm. You get it. Perhaps I'm confused, I've been off dealing with other issues for a few days, but m_pullup doesn't make a copy of the packet or its fields, only makes sure that it's contiguous in memory. Am I wrong in that? Since the bug is that two pieces of code modify the same data, in ways that interfere, I'm not sure how we can avoid making a copy. It might be nice to limit the copy, but we'd still need two copies, one for the loopback device and one for the real device. Best, George ___ freebsd-net@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-net To unsubscribe, send any mail to "[EMAIL PROTECTED]"
Re: Code review
On Tuesday 26 August 2008 03:23:57 am M. Warner Losh wrote: > In message: <[EMAIL PROTECTED]> > John Baldwin <[EMAIL PROTECTED]> writes: > : On Monday 25 August 2008 02:23:16 am M. Warner Losh wrote: > : > I did this a few years ago when trying to track down a problem with > : > some realtek network chips that I was having problems with at Timing > : > Solutions. I'd like to get this into the tree, since it was helpful > : > then. > : > > : > Comments? > : > : When you are running a faster tick I think want to only call the mii and > : watchdog stuff once a second still. I know this will break the tx watchdog > : for example. Since it's kind of tricky to manage that I think you should > : just use a separate timer for the twister stuff. > > Is this in general, or do you have a specific problem in mind with the > rl change? In general, we're not transmitting during this exercise > and it happens only once... Is it worth the extra hair? Worried more about the general case. Is mii_tick() going to be ok with being invoked more often? Also, if you are only doing this during attach or interface up, it might be simpler to have a private timer (shoot, if it's during attach the 'struct callout' can be on the stack) just for this bit. -- John Baldwin ___ freebsd-net@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-net To unsubscribe, send any mail to "[EMAIL PROTECTED]"
Re: Small patch to multicast code...
On Tue, 26 Aug 2008, George V. Neville-Neil wrote: Hi, At Mon, 25 Aug 2008 21:40:38 +0200, John Hay wrote: I have tried it and it does fix my problem. RIP2 over multicast works again. :-) Good to hear. I'm waiting on a bit more feedback but I think I'll be checking this in soon, with a big comment talking about the performance implications etc. So wait a second; what was the m_pullup vs. m_dup thing? Has anyone actually tried that? I mean using a sledgehammer if a mitten would be enough is kind of .. uhm. You get it. /bz -- Bjoern A. Zeeb Stop bit received. Insert coin for new game. ___ freebsd-net@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-net To unsubscribe, send any mail to "[EMAIL PROTECTED]"
Re: Small patch to multicast code...
At Mon, 25 Aug 2008 21:40:38 +0200, John Hay wrote: > > I have tried it and it does fix my problem. RIP2 over multicast works > again. :-) Good to hear. I'm waiting on a bit more feedback but I think I'll be checking this in soon, with a big comment talking about the performance implications etc. Best, George ___ freebsd-net@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-net To unsubscribe, send any mail to "[EMAIL PROTECTED]"
Re: Small patch to multicast code...
Greetings, [EMAIL PROTECTED] wrote: At Fri, 22 Aug 2008 21:42:00 +0200, Luigi Rizzo wrote: On Fri, Aug 22, 2008 at 07:43:03PM +0100, Bruce M. Simpson wrote: [EMAIL PROTECTED] wrote: I gather you mean that a fast link on which also we're looping back the packet will be an issue? Since this packet is only going into the simloop() routine. We end up calling if_simloop() from a few "interesting" places, in particular the kernel PIM packet handler. In this particular case we're going to take a full mbuf chain copy every time we send a packet which needs to be looped back to userland. ... In the case of ip_mloopback(), somehow we are stomping on a read-only copy of an mbuf chain. The use of m_copy() with m_pullup() there is fine according to the documented uses of mbuf(9), although as Luigi pointed out, most likely we need to look at the upper-layer protocol too, e.g. where UDP checksums are also being offloaded. in fact, george, if you have an easy way to reproduce the error, could you see if reverting your change and instead adding sizeof(struct udphdr) to the length argument in the call to m_pullup() fixes the problem ? I don't have sample code I can give but it's simple to set up and test. On machine A set up a sender and a listener for the same multicast group/port. On machine B set up a listener. Send from A with the listener on. B should see nothing and its "bad checksums" counter should increase. Turn off listener on A. Send again, B should get the packet. Hm this looks very much like the showstopper when trying to use jboss in cluster environment. The nodes are replicating their data using multicast udp. I'll try this patch to see will the cluster work now under FreeBSD. If you listen to the traffic with tcpdump on a 3rd machine you'll see that the checksum is constant, even if the data in the packet, like the ports, is not. Your ethernet cards have to have hardware checksum offloading. I'm using em/igb in 7-STABLE. em cards and here. Jboss in cluster creates lot of traffic when under pressure, so I wander how this patch will affect performance. Best, George ___ freebsd-net@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-net To unsubscribe, send any mail to "[EMAIL PROTECTED]" -- Best Wishes, Stefan Lambrev ICQ# 24134177 ___ freebsd-net@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-net To unsubscribe, send any mail to "[EMAIL PROTECTED]"
Re: Code review
In message: <[EMAIL PROTECTED]> John Baldwin <[EMAIL PROTECTED]> writes: : On Monday 25 August 2008 02:23:16 am M. Warner Losh wrote: : > I did this a few years ago when trying to track down a problem with : > some realtek network chips that I was having problems with at Timing : > Solutions. I'd like to get this into the tree, since it was helpful : > then. : > : > Comments? : : When you are running a faster tick I think want to only call the mii and : watchdog stuff once a second still. I know this will break the tx watchdog : for example. Since it's kind of tricky to manage that I think you should : just use a separate timer for the twister stuff. Is this in general, or do you have a specific problem in mind with the rl change? In general, we're not transmitting during this exercise and it happens only once... Is it worth the extra hair? Warner ___ freebsd-net@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-net To unsubscribe, send any mail to "[EMAIL PROTECTED]"
