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
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.
> >
> >
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
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
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
>
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
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,
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
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
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
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
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
12 matches
Mail list logo
