Re: 2D acceleration for Nvidia
On Sun, Dec 13, 2015 at 06:14:20PM +0100, Matthieu Herrb wrote: > On Sun, Dec 13, 2015 at 12:09:48PM +0100, Matthieu Herrb wrote: > > My traditionnal benchmark (/usr/bin/time cat /etc/xtermcap in a 80x35 > > xterm with DejaVu Sans Mono 8 anti-aliased font), takes 534s with EXA > > vs 42s with shadowfb. (it's less than 1s on my X240 with intel) > > > > Hmm sorry. I had a OpenGL compositing enabled in my window manager > while running those tests. This makes no sens. > > With fvwm (but still Xft fonts in xterm, since this is what most other > apps will be using) > > NoAccel + ShadowFB : 6.7s > EXA :8.5s > > Those numbers are reproducable. Landry, are you running with > hw.perfpolicy=auto ? Hmm this patch seems to have been forgotten. Even if with modern CPUs on x86 hw it doesn't provide an improvement, if it helps macppc with nvidia, I think it should be aded to our tree. It's possible to only enable EXA on macppc for instance (or let the users enable it via xorg.conf). Thoughts? (Note that we're getting out of time for 5.9, so it may not make it into the release) -- Matthieu Herrb signature.asc Description: PGP signature
Re: iwn firmware error
Stefan Sperling wrote: > On Fri, Feb 05, 2016 at 01:23:18AM -0500, Michael McConville wrote: > > When forcing my laptop to swap, I almost immediately got the following > > firmware error. I'm not sure whether this is expected. Restarting the > > interface brought things back to normal. > > > > dmesg follows. > > Looks like the firmware crashed because an interrupt could not be > serviced by the host on time, perhaps? I suspect this was the case. My machine was almost completely non-responsive. > > Feb 5 01:19:04 thinkpad /bsd: iwn0: fatal firmware error > > Feb 5 01:19:04 thinkpad /bsd: firmware error log: > > Feb 5 01:19:04 thinkpad /bsd: error type = "NMI_INTERRUPT_WDG" > > (0x0004) > > Feb 5 01:19:04 thinkpad /bsd: program counter = 0x06B4 > > Feb 5 01:19:04 thinkpad /bsd: source line = 0xD3EA > > Feb 5 01:19:04 thinkpad /bsd: error data = 0x00020263 > > Feb 5 01:19:04 thinkpad /bsd: branch link = 0x067A071A > > Feb 5 01:19:04 thinkpad /bsd: interrupt link = 0x1532E762 > > Feb 5 01:19:04 thinkpad /bsd: time= 1346051188 > > Feb 5 01:19:04 thinkpad /bsd: driver status: > > Feb 5 01:19:04 thinkpad /bsd: tx ring 0: qid=0 cur=188 queued=135 > > Feb 5 01:19:04 thinkpad /bsd: tx ring 1: qid=1 cur=0 queued=0 > > Feb 5 01:19:04 thinkpad /bsd: tx ring 2: qid=2 cur=0 queued=0 > > Feb 5 01:19:04 thinkpad /bsd: tx ring 3: qid=3 cur=0 queued=0 > > Feb 5 01:19:04 thinkpad /bsd: tx ring 4: qid=4 cur=135 queued=0 > > Feb 5 01:19:04 thinkpad /bsd: tx ring 5: qid=5 cur=0 queued=0 > > Feb 5 01:19:04 thinkpad /bsd: tx ring 6: qid=6 cur=0 queued=0 > > Feb 5 01:19:04 thinkpad /bsd: tx ring 7: qid=7 cur=0 queued=0 > > Feb 5 01:19:04 thinkpad /bsd: tx ring 8: qid=8 cur=0 queued=0 > > Feb 5 01:19:04 thinkpad /bsd: tx ring 9: qid=9 cur=0 queued=0 > > Feb 5 01:19:04 thinkpad /bsd: tx ring 10: qid=10 cur=0 queued=0 > > Feb 5 01:19:04 thinkpad /bsd: tx ring 11: qid=11 cur=0 queued=0 > > Feb 5 01:19:04 thinkpad /bsd: tx ring 12: qid=12 cur=0 queued=0 > > Feb 5 01:19:04 thinkpad /bsd: tx ring 13: qid=13 cur=0 queued=0 > > Feb 5 01:19:04 thinkpad /bsd: tx ring 14: qid=14 cur=0 queued=0 > > Feb 5 01:19:04 thinkpad /bsd: tx ring 15: qid=15 cur=0 queued=0 > > Feb 5 01:19:04 thinkpad /bsd: tx ring 16: qid=16 cur=0 queued=0 > > Feb 5 01:19:05 thinkpad /bsd: tx ring 17: qid=17 cur=0 queued=0 > > Feb 5 01:19:06 thinkpad /bsd: tx ring 18: qid=18 cur=0 queued=0 > > Feb 5 01:19:06 thinkpad /bsd: tx ring 19: qid=19 cur=0 queued=0 > > Feb 5 01:19:06 thinkpad /bsd: rx ring: cur=47 > > Feb 5 01:19:06 thinkpad /bsd: 802.11 state 4
Re: multicast, ETOOMANYREFS and intro(2)
On Fri, 05 Feb 2016 17:17:30 +0100, Martin Pieuchot wrote: > > > We could also return ENOBUFS in this case instead. That would > > > correspond to the errors described in ip(4) (sadly setsockopt(2) is not > > > really reflecting the code). > > > > > > Jérémie what other OSes report as errors for IP_ADD_MEMBERSHIP? > > > > I only looked at loonix-4.5-rc2 so far: ENOBUFS in this error case. > > Then I think it's the way to go. Works for me. - todd
Ntpd log message readably tweak.
Hello tech@,
https://marc.info/?l=openbsd-misc=145479483809799=2
> ntpd[9279]: adjusting local clock by 9.096751s
> ntpd[9279]: adjusting local clock by 7.971861s
> ntpd[9279]: adjusting local clock by 6.838999s
> I don't think that clock is adjusted "by" that values.
> If that would be the case, I guess clock would be far faster synced.
Wording of the logged messages seems to imply that \
the clock has been adjusted by the displayed number of \
seconds each time the message is printed.
What I beleive is trying to be conveyed to the "sysadmin" \
is, the current offset of the local clock \
relative to the time server.
This is the output with the included patch applied.
ntpd[17167]: adjusting local clock (offset -15.877748s)
ntpd[17167]: adjusting local clock (offset -14.532992s)
ntpd[17167]: adjusting local clock (offset -14.216236s)
The patch takes cues from code else where in ntpd.c
strftime(buf, sizeof(buf), "%a %b %e %H:%M:%S %Z %Y",
localtime());
log_info("set local clock to %s (offset %fs)", buf, d);
This is the output of that existing code.
ntpd[20576]: set local clock to Sun Feb 7 01:38:35 UTC 2016 (offset
-0.262911s)
Regards,
Gerald Hanuer
Index: ntpd.c
===
RCS file: /cvs/src/usr.sbin/ntpd/ntpd.c,v
retrieving revision 1.106
diff -u -p -r1.106 ntpd.c
--- ntpd.c 2 Feb 2016 17:51:11 - 1.106
+++ ntpd.c 7 Feb 2016 08:52:34 -
@@ -443,9 +443,9 @@ ntpd_adjtime(double d)
d += getoffset();
if (d >= (double)LOG_NEGLIGIBLE_ADJTIME / 1000 ||
d <= -1 * (double)LOG_NEGLIGIBLE_ADJTIME / 1000)
- log_info("adjusting local clock by %fs", d);
+ log_info("adjusting local clock (offset %fs)", d);
else
- log_debug("adjusting local clock by %fs", d);
+ log_debug("adjusting local clock (offset %fs)", d);
d_to_tv(d, );
if (adjtime(, ) == -1)
log_warn("adjtime failed");
Re: Fix IWM_MAX_CMD_PAYLOAD_SIZE in iwm(4)
On Thu, Jan 14, 2016 at 10:33:53PM +0100, Imre Vadasz wrote:
> In iwm(4), IWM_MAX_PAYLOAD_SIZE needs to be at least one byte smaller.
>
> "IWM_MAX_CMD_PAYLOAD_SIZE + sizeof(struct iwm_cmdheader)" must be smaller
> than 4096, otherwise the payload length could get truncated to 0 in this
> assignment from iwm_send_cmd(), because 4096 doesn't fit into 12 bits:
>
> desc->tbs[0].hi_n_len = htole16(iwm_get_dma_hi_addr(paddr)
> | ((sizeof(cmd->hdr) + paylen) << 4));
>
>
> Also, in Linux's iwlwifi in iwl-fh.h (at the "struct iwl_tfd" declaration),
> there is a comment that
> "Each buffer has max size of (4K - 4)."
> So it seems logical to make IWM_MAX_CMD_PAYLOAD_SIZE 4 bytes smaller:
Committed, thanks! (and sorry for the delay)
> Index: sys/dev/pci/if_iwmreg.h
> ===
> RCS file: /cvs/src/sys/dev/pci/if_iwmreg.h,v
> retrieving revision 1.9
> diff -u -r1.9 if_iwmreg.h
> --- sys/dev/pci/if_iwmreg.h 14 Dec 2015 08:34:56 - 1.9
> +++ sys/dev/pci/if_iwmreg.h 14 Jan 2016 21:14:13 -
> @@ -5231,7 +5231,7 @@
> };
>
> #define IWM_DEF_CMD_PAYLOAD_SIZE 320
> -#define IWM_MAX_CMD_PAYLOAD_SIZE (4096 - sizeof(struct iwm_cmd_header))
> +#define IWM_MAX_CMD_PAYLOAD_SIZE ((4096 - 4) - sizeof(struct iwm_cmd_header))
> #define IWM_CMD_FAILED_MSK 0x40
>
> struct iwm_device_cmd {
>
Re: mbtowc(3) errno for incomplete character
Ingo Schwarze: > But given that naddy@ already declared ports slowdown: Do you ports > people agree with my suspicion that this is unlikely to be responsible > for major issues in current ports, but that it carries a certain risk > of regressions in poorly written software? Do you agree that it > should wait until after unlock, or do you want it right now? It should wait. -- Christian "naddy" Weisgerber na...@mips.inka.de
ufs/ffs/ext2fs uiomove() conversion
Below the conversion to uiomovei() for ufs. While there I changed all
instances of 'blkoffset', 'size' and 'xfersize' that where declared as
long integers to be plain integers instead for consistency with the
surrounding code. These variables are limited by fs_bsize and e2fs_bsize
respectively, which are int32_t. So, no overflow should be introduced bu
that change. Also, 'size' is passed to bread(), which expects an integer
parameter.
Index: ufs/ext2fs/ext2fs_lookup.c
===
RCS file: /cvs/src/sys/ufs/ext2fs/ext2fs_lookup.c,v
retrieving revision 1.39
diff -u -p -u -r1.39 ext2fs_lookup.c
--- ufs/ext2fs/ext2fs_lookup.c 14 Mar 2015 03:38:52 - 1.39
+++ ufs/ext2fs/ext2fs_lookup.c 7 Feb 2016 17:48:03 -
@@ -177,7 +177,7 @@ ext2fs_readdir(void *v)
break;
}
dstd.d_off = off + e2d_reclen;
- if ((error = uiomovei((caddr_t), dstd.d_reclen,
uio)) != 0) {
+ if ((error = uiomove((caddr_t), dstd.d_reclen,
uio)) != 0) {
break;
}
off = off + e2d_reclen;
Index: ufs/ext2fs/ext2fs_readwrite.c
===
RCS file: /cvs/src/sys/ufs/ext2fs/ext2fs_readwrite.c,v
retrieving revision 1.36
diff -u -p -u -r1.36 ext2fs_readwrite.c
--- ufs/ext2fs/ext2fs_readwrite.c 12 Jan 2016 11:44:21 - 1.36
+++ ufs/ext2fs/ext2fs_readwrite.c 7 Feb 2016 17:48:03 -
@@ -87,7 +87,7 @@ ext2_ind_read(struct vnode *vp, struct i
struct buf *bp;
daddr_t lbn, nextlbn;
off_t bytesinfile;
- long size, xfersize, blkoffset;
+ int size, xfersize, blkoffset;
int error;
#ifdef DIAGNOSTIC
@@ -145,7 +145,7 @@ ext2_ind_read(struct vnode *vp, struct i
break;
xfersize = size;
}
- error = uiomovei((char *)bp->b_data + blkoffset, xfersize, uio);
+ error = uiomove((char *)bp->b_data + blkoffset, xfersize, uio);
if (error)
break;
brelse(bp);
@@ -168,7 +168,7 @@ ext4_ext_read(struct vnode *vp, struct i
size_t orig_resid;
daddr_t lbn, pos;
off_t bytesinfile;
- long size, xfersize, blkoffset;
+ int size, xfersize, blkoffset;
int error, cache_type;
memset(, 0, sizeof path);
@@ -225,7 +225,7 @@ ext4_ext_read(struct vnode *vp, struct i
}
xfersize = size;
}
- error = uiomovei(bp->b_data + blkoffset, xfersize, uio);
+ error = uiomove(bp->b_data + blkoffset, xfersize, uio);
brelse(bp);
if (error)
return (error);
@@ -248,7 +248,8 @@ ext2fs_write(void *v)
int32_t lbn;
off_t osize;
int blkoffset, error, flags, ioflag, size, xfersize;
- ssize_t resid, overrun;
+ size_t resid;
+ ssize_t overrun;
ioflag = ap->a_ioflag;
uio = ap->a_uio;
@@ -324,8 +325,7 @@ ext2fs_write(void *v)
if (size < xfersize)
xfersize = size;
- error =
- uiomovei((char *)bp->b_data + blkoffset, (int)xfersize,
uio);
+ error = uiomove((char *)bp->b_data + blkoffset, xfersize, uio);
#if 0
if (ioflag & IO_NOCACHE)
bp->b_flags |= B_NOCACHE;
Index: ufs/ext2fs/ext2fs_vnops.c
===
RCS file: /cvs/src/sys/ufs/ext2fs/ext2fs_vnops.c,v
retrieving revision 1.73
diff -u -p -u -r1.73 ext2fs_vnops.c
--- ufs/ext2fs/ext2fs_vnops.c 17 Apr 2015 04:43:21 - 1.73
+++ ufs/ext2fs/ext2fs_vnops.c 7 Feb 2016 17:48:04 -
@@ -1116,12 +1116,12 @@ ext2fs_readlink(void *v)
struct vop_readlink_args *ap = v;
struct vnode *vp = ap->a_vp;
struct inode *ip = VTOI(vp);
- int isize;
+ u_int64_t isize;
isize = ext2fs_size(ip);
if (isize < vp->v_mount->mnt_maxsymlinklen ||
(vp->v_mount->mnt_maxsymlinklen == 0 && ip->i_e2fs_nblock == 0)) {
- return (uiomovei((char *)ip->i_e2din->e2di_shortlink, isize,
+ return (uiomove((char *)ip->i_e2din->e2di_shortlink, isize,
ap->a_uio));
}
return (VOP_READ(vp, ap->a_uio, 0, ap->a_cred));
Index: ufs/ffs/ffs_vnops.c
===
RCS file: /cvs/src/sys/ufs/ffs/ffs_vnops.c,v
retrieving revision 1.81
diff -u -p -u -r1.81 ffs_vnops.c
--- ufs/ffs/ffs_vnops.c 12 Jan 2016 11:41:00 - 1.81
+++ ufs/ffs/ffs_vnops.c 7 Feb 2016 17:48:04 -
@@ -193,7 +193,7 @@ ffs_read(void *v)
struct buf *bp;
daddr_t lbn,
Re: pkg_add.1
joshua stein wrote: > We don't recommend FTP mirrors anymore, installing a package via a > pipe doesn't seem to work anymore, and packages have to be signed to > be installed so the advice about miscreants is not very relevant. Good catch with the FTP link. I think it's still worth mentioning that you put trust in the packages you install. Although the package tarballs themselves are now signed (by default), the porter or software author could still try to slip something in. > Index: pkg_add.1 > === > RCS file: /var/cvsync/src/usr.sbin/pkg_add/pkg_add.1,v > retrieving revision 1.134 > diff -u -p -u -p -r1.134 pkg_add.1 > --- pkg_add.1 4 Nov 2015 16:59:58 - 1.134 > +++ pkg_add.1 20 Jan 2016 21:06:53 - > @@ -198,41 +198,6 @@ dependencies with the list of packages l > user's opinion in interactive mode, > then install default packages that satisfy the dependencies. > .Pp > -Alternatively, it is possible to add packages interactively from within the > -.Xr ftp 1 > -client, > -in which case setting > -.Ev PKG_PATH > -correctly will be necessary for any dependency to be found out and retrieved > -the same way. > -For example, the following works: > -.Bd -literal -offset indent > -$ ftp ftp://ftp.openbsd.org/pub/OpenBSD/2.7/packages/i386/ > -250 CWD command successful > -ftp> ls m* > -227 Entering Passive Mode (129,128,5,191,164,73) > -150 Opening ASCII mode data connection for m*. > -m4-1.4.tgz > -metamail-2.7.tgz > -mh-6.8.4.tgz > -mm-1.0.12.tgz > -mpeg_lib-1.2.1.tgz > -mpeg_play-2.4.tgz > -mpg123-0.59q.tgz > -mutt-0.95.7i.tgz > -226 Transfer complete. > -ftp> get m4-1.4.tgz "|pkg_add -v -" > -.Ed > -.Pp > -.Sy Warning: > -Since the > -.Nm > -command may execute scripts or programs contained within a package file, > -your system may be susceptible to > -.Dq trojan horses > -or other subtle attacks from miscreants who create dangerous packages. > -Be sure the specified package(s) are from trusted sources. > -.Pp > The options are as follows: > .Bl -tag -width keyword > .It Fl A Ar arch >
11n: keep BlockAck window in check
There are buggy APs which emit sequence numbers like 1889, 2501, 1890,
1891, 1892, ... A jump like this causes the blockack code to move the
expected sequence number window forward to 2501 and drop all incoming
frames between 1889 and 2501. Eventually the numbers wrap and traffic
starts flowing again until the next fluke frame comes in.
The following diffsadds a heuristic which detects this problem.
It cannot be perfect since it's a heuristic. I've tried guessing
reasonable values to guide it. Does this look reasonable?
Tested by myself and krw@ who owns one such problematic AP and was
suffering the consequences while wifi just worked for everyone else...
Index: ieee80211_input.c
===
RCS file: /cvs/src/sys/net80211/ieee80211_input.c,v
retrieving revision 1.158
diff -u -p -r1.158 ieee80211_input.c
--- ieee80211_input.c 5 Feb 2016 19:42:04 - 1.158
+++ ieee80211_input.c 7 Feb 2016 23:31:08 -
@@ -712,6 +712,37 @@ ieee80211_input_ba(struct ieee80211com *
return;
}
if (SEQ_LT(ba->ba_winend, sn)) {/* WinEndB < SN */
+ /*
+* If this frame would move the window outside the range of
+* winend + winsize, drop it. This is likely a fluke and the
+* next frame will fit into the window again. Allowing the
+* window to be moved too far ahead makes us drop frames
+* until their sequence numbers catch up with the new window.
+*
+* However, if the window really did move arbitrarily, we must
+* allow it to move forward. We try to detect this condition
+* by counting missed consecutive frames.
+*
+* Works around buggy behaviour observed with Broadcom-based
+* APs, which emit "sequence" numbers such as 1888, 1889, 2501,
+* 1890, 1891, ... all for the same TID.
+*/
+ if (((sn - ba->ba_winend) & 0xfff) > IEEE80211_BA_MAX_WINSZ) {
+ if (ba->ba_winmiss < IEEE80211_BA_MAX_WINMISS) {
+ if (ba->ba_missedsn == sn - 1)
+ ba->ba_winmiss++;
+ else
+ ba->ba_winmiss = 0;
+ ba->ba_missedsn = sn;
+ ifp->if_ierrors++;
+ m_freem(m); /* discard the MPDU */
+ return;
+ }
+
+ /* It appears the window has moved for real. */
+ ba->ba_winmiss = 0;
+ ba->ba_missedsn = 0;
+ }
count = (sn - ba->ba_winend) & 0xfff;
if (count > ba->ba_winsize) /* no overlap */
count = ba->ba_winsize;
Index: ieee80211_node.h
===
RCS file: /cvs/src/sys/net80211/ieee80211_node.h,v
retrieving revision 1.56
diff -u -p -r1.56 ieee80211_node.h
--- ieee80211_node.h5 Feb 2016 16:07:57 - 1.56
+++ ieee80211_node.h7 Feb 2016 23:29:47 -
@@ -150,6 +150,12 @@ struct ieee80211_rx_ba {
u_int16_t ba_head;
struct timeout ba_gap_to;
#define IEEE80211_BA_GAP_TIMEOUT 500 /* msec */
+ /* Counter for consecutive frames which missed the BA window. */
+ int ba_winmiss;
+ /* Sequence number of previous frame which missed the BA window. */
+ uint16_tba_missedsn;
+ /* Window moves forward after this many frames have missed it. */
+#define IEEE80211_BA_MAX_WINMISS 8
};
/*
iwn/iwm: fix ht params passed to firmware
The AP HT parameters we provide to the firmware are still a bit messed up.
They are supposed to reflect the AP's capabilities, not our own.
So use params from "ni" instead of "ic".
In most case we just get lucky and things work regardless, it seems.
Add SMPS (MIMO powersave) parameters, too, so the firmware knows the
AP's settings in this regard. These probably don't really matter until
we add MIMO, but this matches what Linux is doing and doesn't seem
to cause harm in my testing, so why not.
Also adds some missing HT flag defines for iwn.
Index: if_iwm.c
===
RCS file: /cvs/src/sys/dev/pci/if_iwm.c,v
retrieving revision 1.77
diff -u -p -r1.77 if_iwm.c
--- if_iwm.c5 Feb 2016 16:08:44 - 1.77
+++ if_iwm.c8 Feb 2016 00:25:02 -
@@ -4466,7 +4466,7 @@ iwm_mvm_sta_send_to_fw(struct iwm_softc
struct iwm_mvm_add_sta_cmd_v6 add_sta_cmd;
int ret;
uint32_t status;
- struct ieee80211com *ic = >sc_ic;
+ struct ieee80211_node *ni = >in_ni;
memset(_sta_cmd, 0, sizeof(add_sta_cmd));
@@ -4475,20 +4475,22 @@ iwm_mvm_sta_send_to_fw(struct iwm_softc
= htole32(IWM_FW_CMD_ID_AND_COLOR(in->in_id, in->in_color));
if (!update) {
add_sta_cmd.tfd_queue_msk = htole32(0xf);
- IEEE80211_ADDR_COPY(_sta_cmd.addr, in->in_ni.ni_bssid);
+ IEEE80211_ADDR_COPY(_sta_cmd.addr, ni->ni_bssid);
}
add_sta_cmd.add_modify = update ? 1 : 0;
- add_sta_cmd.station_flags_msk
- |= htole32(IWM_STA_FLG_FAT_EN_MSK | IWM_STA_FLG_MIMO_EN_MSK);
- if (in->in_ni.ni_flags & IEEE80211_NODE_HT) {
- add_sta_cmd.station_flags_msk
- |= htole32(IWM_STA_FLG_MAX_AGG_SIZE_MSK |
- IWM_STA_FLG_AGG_MPDU_DENS_MSK);
+ if (ni->ni_flags & IEEE80211_NODE_HT) {
+ add_sta_cmd.station_flags_msk |=
+ htole32(IWM_STA_FLG_RTS_MIMO_PROT |
+ IWM_STA_FLG_MIMO_EN_SISO |
+ IWM_STA_FLG_MAX_AGG_SIZE_MSK |
+ IWM_STA_FLG_MIMO_EN_MSK |
+ IWM_STA_FLG_AGG_MPDU_DENS_MSK |
+ IWM_STA_FLG_FAT_EN_MSK);
add_sta_cmd.station_flags
|= htole32(IWM_STA_FLG_MAX_AGG_SIZE_64K);
- switch (ic->ic_ampdu_params & IEEE80211_AMPDU_PARAM_SS) {
+ switch (ni->ni_ampdu_param & IEEE80211_AMPDU_PARAM_SS) {
case IEEE80211_AMPDU_PARAM_SS_2:
add_sta_cmd.station_flags
|= htole32(IWM_STA_FLG_AGG_MPDU_DENS_2US);
@@ -4508,6 +4510,18 @@ iwm_mvm_sta_send_to_fw(struct iwm_softc
default:
break;
}
+
+ switch ((ni->ni_htcaps & IEEE80211_HTCAP_SMPS_MASK) >>
+ IEEE80211_HTCAP_SMPS_SHIFT) {
+ case IEEE80211_HTCAP_SMPS_STA:
+ add_sta_cmd.station_flags |= IWM_STA_FLG_MIMO_EN_SISO;
+ break;
+ case IEEE80211_HTCAP_SMPS_DYN:
+ add_sta_cmd.station_flags |= IWM_STA_FLG_RTS_MIMO_PROT;
+ break;
+ default:
+ break;
+ }
}
status = IWM_ADD_STA_SUCCESS;
@@ -6840,7 +6854,7 @@ iwm_attach(struct device *parent, struct
IEEE80211_C_SHPREAMBLE; /* short preamble supported */
/* No optional HT features supported for now, */
- ic->ic_htcaps = 0;
+ ic->ic_htcaps = IEEE80211_HTCAP_SMPS_DIS;
ic->ic_htxcaps = 0;
ic->ic_txbfcaps = 0;
ic->ic_aselcaps = 0;
Index: if_iwn.c
===
RCS file: /cvs/src/sys/dev/pci/if_iwn.c,v
retrieving revision 1.163
diff -u -p -r1.163 if_iwn.c
--- if_iwn.c7 Feb 2016 23:56:19 - 1.163
+++ if_iwn.c8 Feb 2016 00:33:48 -
@@ -456,7 +456,7 @@ iwn_attach(struct device *parent, struct
IEEE80211_C_PMGT; /* power saving supported */
/* No optional HT features supported for now, */
- ic->ic_htcaps = 0;
+ ic->ic_htcaps = IEEE80211_HTCAP_SMPS_DIS;
ic->ic_htxcaps = 0;
ic->ic_txbfcaps = 0;
ic->ic_aselcaps = 0;
@@ -4942,13 +4942,29 @@ iwn_run(struct iwn_softc *sc)
IEEE80211_ADDR_COPY(node.macaddr, ni->ni_macaddr);
node.id = IWN_ID_BSS;
if (ni->ni_flags & IEEE80211_NODE_HT) {
- node.htmask = (IWN_AMDPU_SIZE_FACTOR_MASK |
- IWN_AMDPU_DENSITY_MASK);
+ node.htmask = (IWN_HTF_RTS_MIMO_PROT |
+ IWN_HTF_AMDPU_SIZE_FACTOR_MASK |
+ IWN_HTF_AMDPU_DENSITY_MASK |
+ IWN_HTF_HT40_EN |
+ IWN_HTF_MIMO_DIS);
+
node.htflags = htole32(
- IWN_AMDPU_SIZE_FACTOR(
-
KASSERT() @ pf_test() is back
Hello,
I don't expect to see O.K. to patch below.
The patch is the part of the change, which has been backed out last weekend.
Too many things were wrong so I'm trying to untangle the code a bit.
Patch below is for brave hearts, who don't mind to see KASSERT() to fire:
Index: net/pf.c
===
RCS file: /cvs/src/sys/net/pf.c,v
retrieving revision 1.965
diff -u -p -r1.965 pf.c
--- net/pf.c31 Jan 2016 00:18:07 - 1.965
+++ net/pf.c7 Feb 2016 23:38:16 -
@@ -6534,6 +6534,12 @@ done:
if (action == PF_PASS && qid)
pd.m->m_pkthdr.pf.qid = qid;
if (pd.dir == PF_IN && s && s->key[PF_SK_STACK]) {
+ /*
+* ASSERT() below fires whenever caller forgets to call
+* pf_pkt_addr_changed(). This might happen when we deal with
+* IP tunnels.
+*/
+ KASSERT(pd.m->m_pkthdr.pf.statekey == NULL);
pd.m->m_pkthdr.pf.statekey = s->key[PF_SK_STACK];
}
if (pd.dir == PF_OUT &&
before we get any further with unlocking PF, we need to be sure how packet
handling looks like at 'global level'. Besides the change, which re-introduces
the KASSERT(), I'm adding few more changes, where .pf.statekey should be
removed from mbuf, so KASSERT() won't fire.
My plan is to commit patch as soon as CVS will be unlocked. The change won't
appear in 5.9. I hope to see some KASSERT() panic stories now.
thanks a lot
regards
sasha
8<---8<---8<--8<
Index: net/if_etherip.c
===
RCS file: /cvs/src/sys/net/if_etherip.c,v
retrieving revision 1.5
diff -u -p -r1.5 if_etherip.c
--- net/if_etherip.c25 Jan 2016 05:12:34 - 1.5
+++ net/if_etherip.c7 Feb 2016 23:38:09 -
@@ -499,6 +499,10 @@ ip_etherip_input(struct mbuf *m, ...)
}
m->m_flags &= ~(M_BCAST|M_MCAST);
+#if NPF > 0
+ pf_pkt_addr_changed(m);
+#endif
+
ml_enqueue(, m);
if_input(ifp, );
}
@@ -641,6 +645,10 @@ ip6_etherip_input(struct mbuf **mp, int
}
m->m_flags &= ~(M_BCAST|M_MCAST);
+
+#if NPF > 0
+ pf_pkt_addr_changed(m);
+#endif
ml_enqueue(, m);
if_input(ifp, );
Index: net/pf.c
===
RCS file: /cvs/src/sys/net/pf.c,v
retrieving revision 1.965
diff -u -p -r1.965 pf.c
--- net/pf.c31 Jan 2016 00:18:07 - 1.965
+++ net/pf.c7 Feb 2016 23:38:16 -
@@ -6534,6 +6534,12 @@ done:
if (action == PF_PASS && qid)
pd.m->m_pkthdr.pf.qid = qid;
if (pd.dir == PF_IN && s && s->key[PF_SK_STACK]) {
+ /*
+* ASSERT() below fires whenever caller forgets to call
+* pf_pkt_addr_changed(). This might happen when we deal with
+* IP tunnels.
+*/
+ KASSERT(pd.m->m_pkthdr.pf.statekey == NULL);
pd.m->m_pkthdr.pf.statekey = s->key[PF_SK_STACK];
}
if (pd.dir == PF_OUT &&
Index: net/pipex.c
===
RCS file: /cvs/src/sys/net/pipex.c,v
retrieving revision 1.84
diff -u -p -r1.84 pipex.c
--- net/pipex.c 3 Nov 2015 21:33:56 - 1.84
+++ net/pipex.c 7 Feb 2016 23:38:18 -
@@ -1139,6 +1139,10 @@ pipex_ip_input(struct mbuf *m0, struct p
goto drop;
}
+#if NPF > 0
+ pf_pkt_addr_changed(m0);
+#endif
+
len = m0->m_pkthdr.len;
#if NBPFILTER > 0
Index: netinet/ip_gre.c
===
RCS file: /cvs/src/sys/netinet/ip_gre.c,v
retrieving revision 1.58
diff -u -p -r1.58 ip_gre.c
--- netinet/ip_gre.c2 Dec 2015 08:47:00 - 1.58
+++ netinet/ip_gre.c7 Feb 2016 23:38:20 -
@@ -337,6 +337,10 @@ gre_mobile_input(struct mbuf *m, ...)
bpf_mtap_af(sc->sc_if.if_bpf, AF_INET, m, BPF_DIRECTION_IN);
#endif
+#if NPF > 0
+ pf_pkt_addr_changed(m);
+#endif
+
niq_enqueue(, m);
}
Re: bktr uiomove() conversion
Martin Natano wrote:
> Below the conversion from uiomovei() to uiomove() for bktr. The patch
> also replaces two occurrences of uio->uio_iov->iov_len with
> uio->uio_resid. I don't see a reason why bktr should inspect iov_len
> directly.
Looks good. As for computing count, we have 0 <= bktr->rows <= 0x7fe,
0 <= bktr->cols <= 0x3fe and pixfmt_table[bktr->pixfmt[.public.Bpp is 4
at most. So count is always positive even with an int and changing
it to size_t and calling uiomove keeps the same behavior as today.
Checking uio_resid and using ulmin also makes sense. bktr->vbisize is
bounded by VBI_BUFFER_SIZE and uio_resid is expected to be the sum
of the iov_len when video_read or vbi_read is called.
> Index: dev/pci/bktr/bktr_core.c
> ===
> RCS file: /cvs/src/sys/dev/pci/bktr/bktr_core.c,v
> retrieving revision 1.36
> diff -u -p -u -r1.36 bktr_core.c
> --- dev/pci/bktr/bktr_core.c 14 Mar 2015 03:38:49 - 1.36
> +++ dev/pci/bktr/bktr_core.c 24 Jan 2016 11:25:49 -
> @@ -993,7 +993,7 @@ int
> video_read(bktr_ptr_t bktr, int unit, dev_t dev, struct uio *uio)
> {
> int status;
> -int count;
> +size_t count;
>
>
> if (bktr->bigbuf == 0) /* no frame buffer allocated (ioctl failed) */
> @@ -1008,7 +1008,7 @@ video_read(bktr_ptr_t bktr, int unit, de
> count = bktr->rows * bktr->cols *
> pixfmt_table[ bktr->pixfmt ].public.Bpp;
>
> - if ((int) uio->uio_iov->iov_len < count)
> + if (uio->uio_resid < count)
> return( EINVAL );
>
> bktr->flags &= ~(METEOR_CAP_MASK | METEOR_WANT_MASK);
> @@ -1027,7 +1027,7 @@ video_read(bktr_ptr_t bktr, int unit, de
>
> status = tsleep(BKTR_SLEEP, BKTRPRI, "captur", 0);
> if (!status)/* successful capture */
> - status = uiomovei((caddr_t)bktr->bigbuf, count, uio);
> + status = uiomove((caddr_t)bktr->bigbuf, count, uio);
> else
> printf ("%s: read: tsleep error %d\n",
> bktr_name(bktr), status);
> @@ -1047,7 +1047,7 @@ video_read(bktr_ptr_t bktr, int unit, de
> int
> vbi_read(bktr_ptr_t bktr, struct uio *uio, int ioflag)
> {
> - int readsize, readsize2;
> + size_t readsize, readsize2;
> int status;
>
>
> @@ -1067,22 +1067,20 @@ vbi_read(bktr_ptr_t bktr, struct uio *ui
> /* We cannot read more bytes than there are in
>* the circular buffer
>*/
> - readsize = (int)uio->uio_iov->iov_len;
> -
> - if (readsize > bktr->vbisize) readsize = bktr->vbisize;
> + readsize = ulmin(uio->uio_resid, bktr->vbisize);
>
> /* Check if we can read this number of bytes without having
>* to wrap around the circular buffer */
> - if((bktr->vbistart + readsize) >= VBI_BUFFER_SIZE) {
> + if (readsize >= VBI_BUFFER_SIZE - bktr->vbistart) {
> /* We need to wrap around */
>
> readsize2 = VBI_BUFFER_SIZE - bktr->vbistart;
> - status = uiomovei((caddr_t)bktr->vbibuffer + bktr->vbistart,
> readsize2, uio);
> + status = uiomove((caddr_t)bktr->vbibuffer + bktr->vbistart,
> readsize2, uio);
> if (status == 0)
> - status = uiomovei((caddr_t)bktr->vbibuffer, (readsize -
> readsize2), uio);
> + status = uiomove((caddr_t)bktr->vbibuffer, (readsize -
> readsize2), uio);
> } else {
> /* We do not need to wrap around */
> - status = uiomovei((caddr_t)bktr->vbibuffer + bktr->vbistart,
> readsize, uio);
> + status = uiomove((caddr_t)bktr->vbibuffer + bktr->vbistart,
> readsize, uio);
> }
>
> /* Update the number of bytes left to read */
>
> cheers,
> natano
>
