Re: memset.S for amd64
On 19 sep 2013, at 19:23, Brad Smith wrote: > That is in the kernel not libc. Yes, I know. Can't it be re-used instead of maintaining same file in two places? //mxb
Re: em(4): enable checksum offload
Brad Smith wrote: > > > Since I have been asked to send out these diffs again here is a diff > to enable > > > the checksum offload support for em(4). > > > > > > Looking for any testing. > > > > tx checksum offloading will not work on 75, 76, 80, i350. > > Oh yes, you're right. The same exclusion logic should have been > propagated from the HW VLAN tagging/stripping code. -snip- Works for me on 82540EM, 82574L, 82579LM, and doesn't harm the I350. If there are subtle issues, we won't find them without putting things out in -current. ok naddy@ -- Christian "naddy" Weisgerber na...@mips.inka.de
Re: fill /* TODO: 11A */ in bwi_rf_set_chan()
On Thu, Sep 19, 2013 at 4:06 PM, Martin Pieuchot wrote: > If I'm not mistaken the linux b43 driver uses another version of the > firmware (v4+). But bwi(4) is a rewrite/port of what's now the > b43legacy driver which depends on a firmware (v3) that does not > support 11A phy. > > So I'm not sure it makes sense to port code from the b43 driver. If I am not mistaken Linux only uses b43legacy for "BCM4306 Rev 2 and cards that have only 802.11b" [1]. These chips are the last ones that Linux cannot succeed to switch to the firmware v4+. All others use the b43 driver. But the drivers are very similar. b43legacy seems to not support phya and the b43 code for phyg is the same that is used for b43legacy on phyg and phyb. I was thinking that taking the phya initialization code was not risky. With these diffs I was trying to start adding each piece of code that performs phy initialization in b43 that are not present b43legacy (if these pieces don't break bwi). It should help us to switch to v4+ in the future with minimum pain. I think that with some work we could mix what is done b43 and b43legacy in bwi and load the good firmware(v3 or v4+) depending on the hardware ids. But I should probably come back with a stack of diffs when I've got some results going forward in this direction :) Cheers, [1] http://wireless.kernel.org/en/users/Drivers/b43 -- Sylvestre Gallon
Re: memset.S for amd64
On Thu, Sep 19, 2013 at 01:23:19PM -0400, Brad Smith wrote: > On 19/09/13 7:47 AM, mxb wrote: > > > >This file is already in base. > >/usr/src/sys/lib/libkern/arch/amd64/memset.S > > That is in the kernel not libc. Indeed. I recall seeing a macro called "COPY_TO_KERNEL" or something. I probably need to use that. With regards to the differences. The only difference between the in-kernel version and FreeBSD's from libc (that is not in a comment) is as follows: ---8<--- @@ -8,6 +11,7 @@ ENTRY(memset) movq%rsi,%rax + andq$0xff,%rax movq%rdx,%rcx movq%rdi,%r11 ---8<--- The FreeBSD implementation has the extra instruction. It looks like they copy the second argument (int c) from rsi and stash it it rax. Since c is going to be used as a char (and thus uses only a byte) the original author clears bits 8 through 63 with an andq. It looks like this is not strictly necessary as the lower byte of rax (aka, AL) is then copied across the other bytes of rax anyway. This allows them to copy the bytes 8 at a time by movq. Can someone check this? Is the andq unnecessary in this case? -- Best Regards Edd Barrett http://www.theunixzoo.co.uk
Re: memset.S for amd64
On 19/09/13 7:47 AM, mxb wrote: This file is already in base. /usr/src/sys/lib/libkern/arch/amd64/memset.S That is in the kernel not libc. -- This message has been scanned for viruses and dangerous content by MailScanner, and is believed to be clean.
Re: memset.S for amd64
(Pardon top-posting) I can spot few differences: http://www.openbsd.org/cgi-bin/cvsweb/src/sys/lib/libkern/arch/amd64/memset.S?rev=1.3;content-type=text%2Fplain and http://svnweb.freebsd.org/base/release/8.2.0/lib/libc/amd64/string/memset.S?revision=218742&view=markup though I am not familiar with assembly. -- Ville On 19 September 2013 14:47, mxb wrote: > > This file is already in base. > /usr/src/sys/lib/libkern/arch/amd64/memset.S > > > On 18 sep 2013, at 20:28, Edd Barrett wrote: > >> On Wed, Sep 18, 2013 at 07:08:31PM +0100, Edd Barrett wrote: >>> In short, each experiment warms up by setting and checking a load of buffers >>> before setting as many buffers as possible given a one minute timeframe. The >>> experiments were run with varying buffer sizes under both memset.S and >>> memset.c. >> >> Forgot to say, each experiment was repeated 5 times (each bufsz/ >> memset combination) and averages were taken. >> >> See the Python scripts in the repo for details. >> >> -- >> Best Regards >> Edd Barrett >> >> http://www.theunixzoo.co.uk
Re: Set of 14 potential bugs
Le 12/07/2013 20:24, Maxime Villard a écrit : > Hi, > as I did for NetBSD, here is a list of 14 potential bugs/errors > found by my code scanner in OpenBSD: > > http://M00nBSD.net/e5ab5f6e59d6a0feb7d1a518acc8233d.html > > I do not provide patches. > > May I ask what's the status of the remaining bugs?
Re: fill /* TODO: 11A */ in bwi_rf_set_chan()
On 09/09/13(Mon) 21:15, Sylvestre Gallon wrote: > Hi tech@, > > Here is a patch that implement the phy_mode == IEEE80211_MODE_11A > part of bwi_rf_set_chan(). It is based on the linux b43/phy_a.c > switch_channel code. > > It does not break my BCM4306. It would be awesome if someone could > try it with a card that have a 11A phy. > > Comments/OK/NOK ? If I'm not mistaken the linux b43 driver uses another version of the firmware (v4+). But bwi(4) is a rewrite/port of what's now the b43legacy driver which depends on a firmware (v3) that does not support 11A phy. So I'm not sure it makes sense to port code from the b43 driver. Martin
Multicast macros and global list of addresses
Diff below change the macros used to iterate over the multicast
records linked to an interface without using the global lists of
addresses.
These records are currently link to the first address descriptor,
respectively v4 and v6, even if they are per-interface. So I
changed the code to loop over the global interface list instead
of iterating over all existing addresses.
Tested here with a carp setup. Comments, ok?
Index: netinet/igmp.c
===
RCS file: /home/ncvs/src/sys/netinet/igmp.c,v
retrieving revision 1.33
diff -u -p -r1.33 igmp.c
--- netinet/igmp.c 2 May 2013 11:54:10 - 1.33
+++ netinet/igmp.c 13 Sep 2013 09:07:42 -
@@ -104,6 +104,7 @@ int igmp_timers_are_running;
static struct router_info *rti_head;
struct igmpstat igmpstat;
+void igmp_checktimer(struct ifnet *);
void igmp_sendpkt(struct in_multi *, int, in_addr_t);
int rti_fill(struct in_multi *);
struct router_info * rti_find(struct ifnet *);
@@ -193,7 +194,6 @@ igmp_input(struct mbuf *m, ...)
int igmplen;
int minlen;
struct in_multi *inm;
- struct in_multistep step;
struct router_info *rti;
struct in_ifaddr *ia;
int timer;
@@ -266,17 +266,14 @@ igmp_input(struct mbuf *m, ...)
* except those that are already running and those
* that belong to a "local" group (224.0.0.X).
*/
- IN_FIRST_MULTI(step, inm);
- while (inm != NULL) {
- if (inm->inm_ia->ia_ifp == ifp &&
- inm->inm_timer == 0 &&
+ IN_FOREACH_MULTI(ia, ifp, inm) {
+ if (inm->inm_timer == 0 &&
!IN_LOCAL_GROUP(inm->inm_addr.s_addr)) {
inm->inm_state = IGMP_DELAYING_MEMBER;
inm->inm_timer = IGMP_RANDOM_DELAY(
IGMP_MAX_HOST_REPORT_DELAY *
PR_FASTHZ);
igmp_timers_are_running = 1;
}
- IN_NEXT_MULTI(step, inm);
}
} else {
if (!IN_MULTICAST(ip->ip_dst.s_addr)) {
@@ -297,10 +294,8 @@ igmp_input(struct mbuf *m, ...)
* timers already running, check if they need to be
* reset.
*/
- IN_FIRST_MULTI(step, inm);
- while (inm != NULL) {
- if (inm->inm_ia->ia_ifp == ifp &&
- !IN_LOCAL_GROUP(inm->inm_addr.s_addr) &&
+ IN_FOREACH_MULTI(ia, ifp, inm) {
+ if (!IN_LOCAL_GROUP(inm->inm_addr.s_addr) &&
(ip->ip_dst.s_addr == INADDR_ALLHOSTS_GROUP
||
ip->ip_dst.s_addr ==
inm->inm_addr.s_addr)) {
switch (inm->inm_state) {
@@ -323,7 +318,6 @@ igmp_input(struct mbuf *m, ...)
break;
}
}
- IN_NEXT_MULTI(step, inm);
}
}
@@ -505,8 +499,7 @@ igmp_leavegroup(struct in_multi *inm)
void
igmp_fasttimo(void)
{
- struct in_multi *inm;
- struct in_multistep step;
+ struct ifnet *ifp;
int s;
/*
@@ -518,8 +511,21 @@ igmp_fasttimo(void)
s = splsoftnet();
igmp_timers_are_running = 0;
- IN_FIRST_MULTI(step, inm);
- while (inm != NULL) {
+ TAILQ_FOREACH(ifp, &ifnet, if_list)
+ igmp_checktimer(ifp);
+ splx(s);
+}
+
+
+void
+igmp_checktimer(struct ifnet *ifp)
+{
+ struct in_multi *inm;
+ struct in_ifaddr *ia;
+
+ splsoftassert(IPL_SOFTNET);
+
+ IN_FOREACH_MULTI(ia, ifp, inm) {
if (inm->inm_timer == 0) {
/* do nothing */
} else if (--inm->inm_timer == 0) {
@@ -535,9 +541,7 @@ igmp_fasttimo(void)
} else {
igmp_timers_are_running = 1;
}
- IN_NEXT_MULTI(step, inm);
}
- splx(s);
}
void
Index: netinet/in_var.h
===
RCS file: /home/ncvs/src/sys/netinet/in_var.h,v
retrieving revision 1.21
diff -u -p -r1.21 in_var.h
--- netinet/in_var.h28 Aug 2013 21:19:16 - 1.21
+++ netinet/in_var.h13 Sep 2013 09:07:42 -
@@ -147,17 +147,21 @@ struct in_multi {
#ifdef _KERNEL
/*
- * Structure used by macros below to remember position when stepping through
- * all of the in_multi re
Re: memset.S for amd64
This file is already in base. /usr/src/sys/lib/libkern/arch/amd64/memset.S On 18 sep 2013, at 20:28, Edd Barrett wrote: > On Wed, Sep 18, 2013 at 07:08:31PM +0100, Edd Barrett wrote: >> In short, each experiment warms up by setting and checking a load of buffers >> before setting as many buffers as possible given a one minute timeframe. The >> experiments were run with varying buffer sizes under both memset.S and >> memset.c. > > Forgot to say, each experiment was repeated 5 times (each bufsz/ > memset combination) and averages were taken. > > See the Python scripts in the repo for details. > > -- > Best Regards > Edd Barrett > > http://www.theunixzoo.co.uk >
Re: ntpd jump ahead
hmm, on Fri, Sep 06, 2013 at 07:42:39AM -0400, Nick Holland said that > On 09/06/13 04:50, Stuart Henderson wrote: > > On 2013/09/05 20:03, Barry Grumbine wrote: > >> Non-VM use case: The BeagleBone Black has no RTC, so -j could be > >> useful for cheap little ARM development boards. > > > > -s is fine for that (and the same for those of the alix boards with > > no rtc battery, etc). > > > > ...unless the machine isn't attached to the network when initially > powered up. > > Same goes for any machine with a dead RTC battery that may not have a > good network connection at boot, and/or you don't want to slow the boot > down by 15 seconds if there is no network connection. This shocks > people, but I often use a computer where there is no network connection. > Waiting for that 15 second boot delay is annoying. a quick and dirty solution could be rdate(8) in crontab(5) -f -- i am not a dictator. it's just i have a grumpy face.
