On Mon, Jan 17, 2022 at 10:01:17PM +0900, SASANO Takayoshi wrote:
>
> Hi,
>
> Sometimes uchcom(4) looks Rx jammed.
> Here is the movie (at Mastodon) that the problem has occured:
> https://social.tchncs.de/@uaa/107637913051446044
>
> Receiving an exact wMaxPacketSize bytes bulk packet from
Hi,
There were some problems with ix(4) and ixl(4) hardware checksumming
for the output path on strict alignment architectures.
I have merged jan@'s diffs and added some sanity checks and
workarounds.
- If the first mbuf is not aligned or not contigous, use m_copydata()
to extract the IP,
Hi,
CC afresh1@, with whom I've discussed this a little already.
If I make a FAT32 filesystem on a thumb drive on OpenBSD (using the default
parameters) and mount it (with the default options) and proceed to make some
strategically named files:
```
# touch a B a B longlonglong
Thanks for looking into this.
On Sat, 2022-01-22 at 10:05 -0700, Theo de Raadt wrote:
> > Note that this only adds the parsing, the rest of the current behaviour
> > of stays the same. I have another diff in the pipeline for allowing the
> > hostname in the message.
>
> I object to this process.
On Tue, Jan 25, 2022 at 09:20:55PM +0100, Alexander Bluhm wrote:
> On Tue, Jan 25, 2022 at 12:05:48PM -0800, Andrew Hewus Fresh wrote:
> > On Tue, Jan 25, 2022 at 06:45:12PM +0100, Alexander Bluhm wrote:
> > > On Tue, Jan 25, 2022 at 05:13:01PM +0100, Alexander Bluhm wrote:
> > > > On Sat, Jan 22,
in4_cksum(), used to compute packet checksums for the legacy internet
protocol, has been hand-optimized for speed on most elderly platforms,
with the most recent pieces of silicon using a portable C
implementation.
Most of these implementations, in a not-so-uncommon case, need to
checksum an
On Tue, Jan 25, 2022 at 12:05:48PM -0800, Andrew Hewus Fresh wrote:
> On Tue, Jan 25, 2022 at 06:45:12PM +0100, Alexander Bluhm wrote:
> > On Tue, Jan 25, 2022 at 05:13:01PM +0100, Alexander Bluhm wrote:
> > > On Sat, Jan 22, 2022 at 02:24:51AM +0100, Marc Espie wrote:
> > > > Or we can automate
On Tue, Jan 25, 2022 at 06:45:12PM +0100, Alexander Bluhm wrote:
> On Tue, Jan 25, 2022 at 05:13:01PM +0100, Alexander Bluhm wrote:
> > On Sat, Jan 22, 2022 at 02:24:51AM +0100, Marc Espie wrote:
> > > Or we can automate this with something like this:
> > >
> Our Devel::PPPort is too old. We
> Date: Tue, 25 Jan 2022 19:44:23 +0100 (CET)
> From: Mark Kettenis
>
> > Date: Tue, 25 Jan 2022 07:01:41 +0100
> > From: Anton Lindqvist
> >
> > On Mon, Jan 24, 2022 at 08:40:36PM +0100, Mark Kettenis wrote:
> > > > Date: Mon, 24 Jan 2022 20:19:46 +0100
> > > > From: Anton Lindqvist
> > > >
> Date: Tue, 25 Jan 2022 07:01:41 +0100
> From: Anton Lindqvist
>
> On Mon, Jan 24, 2022 at 08:40:36PM +0100, Mark Kettenis wrote:
> > > Date: Mon, 24 Jan 2022 20:19:46 +0100
> > > From: Anton Lindqvist
> > >
> > > On Mon, Jan 24, 2022 at 05:31:49PM +0100, Mark Kettenis wrote:
> > > >
On Tue, Jan 25, 2022 at 05:13:01PM +0100, Alexander Bluhm wrote:
> On Sat, Jan 22, 2022 at 02:24:51AM +0100, Marc Espie wrote:
> > Or we can automate this with something like this:
> >
> > Index: perl.port.mk
> > ===
> > RCS file:
On Sat, Jan 22, 2022 at 02:24:51AM +0100, Marc Espie wrote:
> Or we can automate this with something like this:
>
> Index: perl.port.mk
> ===
> RCS file: /cvs/ports/infrastructure/mk/perl.port.mk,v
> retrieving revision 1.32
> diff
On Sat, Jan 22, 2022 at 09:25:25AM +0100, Otto Moerbeek wrote:
> On Mon, Jan 17, 2022 at 08:42:47AM +0100, Otto Moerbeek wrote:
>
> > On Sun, Jan 09, 2022 at 02:54:43PM +0100, Otto Moerbeek wrote:
> >
> > > Hi,
> > >
> > > currently malloc does cache a number of free'ed regions up to 128k in
>
> Date: Tue, 25 Jan 2022 10:00:45 +0100
> From: Stefan Sperling
>
> On Tue, Jan 25, 2022 at 09:32:21AM +0100, Mark Kettenis wrote:
> > Happened again while still on a Jan 16 snapshot kernel. So it is not
> > related to that diff.
> >
> > Here is the panic message and backtrace:
> >
> > panic:
On Tue, Jan 25, 2022 at 09:32:21AM +0100, Mark Kettenis wrote:
> Happened again while still on a Jan 16 snapshot kernel. So it is not
> related to that diff.
>
> Here is the panic message and backtrace:
>
> panic: kernel diagnostic assertion "sc->task_refs.refs == 0" failed: file
>
> Date: Fri, 21 Jan 2022 16:18:28 +0100 (CET)
> From: Mark Kettenis
>
> > Date: Fri, 21 Jan 2022 16:05:49 +0100
> > From: Stefan Sperling
> >
> > On Sun, Jan 16, 2022 at 07:38:11PM +0100, Mark Kettenis wrote:
> > > > Date: Sun, 16 Jan 2022 19:28:06 +0100
> > > > From: Stefan Sperling
> > > >
16 matches
Mail list logo
