Jonathan Gray wrote:
> On Fri, Aug 26, 2022 at 10:21:32PM -0500, Scott Cheloha wrote:
> > I noticed that on non-LAPIC systems we program channel 0 in periodic
> > mode with an initial count of 11932 to effect a 100hz clock interrupt.
> > And then we also use that same channel to count time, but
On Fri, Aug 26, 2022 at 10:21:32PM -0500, Scott Cheloha wrote:
> I noticed that on non-LAPIC systems we program channel 0 in periodic
> mode with an initial count of 11932 to effect a 100hz clock interrupt.
> And then we also use that same channel to count time, but because we
> aren't using the
On Sat, Aug 27, 2022 at 11:33:58AM +1000, Jonathan Gray wrote:
> On Fri, Aug 26, 2022 at 11:09:19AM -0500, Scott Cheloha wrote:
> > Hi,
> >
> > TLDR:
> >
> > 1. When did PCs stop using ISA Timer 1 to trigger DRAM refresh?
> >
> > 2. Are any PCs that rely on ISA Timer 1 for DRAM refresh capable
Jonathan Gray wrote:
>> What difference does it make? We don't use counter 1.
>
> The PCH datasheets from 100 series and later only document counter 0
> and counter 2.
>
> 9 series and earlier datasheet has
> "The PCH contains three counters that have fixed uses."
> 100 series and later
>
On Fri, Aug 26, 2022 at 11:09:19AM -0500, Scott Cheloha wrote:
> Hi,
>
> TLDR:
>
> 1. When did PCs stop using ISA Timer 1 to trigger DRAM refresh?
>
> 2. Are any PCs that rely on ISA Timer 1 for DRAM refresh capable of
>running OpenBSD as it exists today?
>
> Long version:
>
> I have a
The former PRU_SEND error path of gre_usrreq() had `control' mbuf(9)
leak. It was fixed in new gre_send().
The former pfkeyv2_send() was renamed to pfkeyv2_dosend().
Index: sys/kern/uipc_usrreq.c
===
RCS file:
Naming the list like the struct itself makes for awful grepping.
Distinguish the list name; no functional change.
Builds/runs fine on and64 and sparc64.
Feedback? Objection? OK?
Naming bikeshed (ifnet_tailq, ifnet_list)?
diff --git a/sys/arch/amd64/amd64/autoconf.c
On Fri, Aug 26, 2022 at 06:15:50PM +0100, Stuart Henderson wrote:
> On 2022/08/26 16:50, Klemens Nanni wrote:
> > Running the packages.txt files through 'sort -u' and 'comm -12' and
> > filtering for ports we actually have leaves us with
> >
> > aircrack-ng
> > firefox
> > firefox-esr
On 2022/08/26 16:50, Klemens Nanni wrote:
> Running the packages.txt files through 'sort -u' and 'comm -12' and
> filtering for ports we actually have leaves us with
>
> aircrack-ng
> firefox
> firefox-esr
> gst-plugins-bad1.0
> gst-plugins-bad1.0-contrib
>
On Fri, Aug 26, 2022 at 04:08:34PM +, Klemens Nanni wrote:
> On Fri, Aug 26, 2022 at 09:53:35AM -0600, Theo de Raadt wrote:
> > Klemens Nanni wrote:
> >
> > > On Fri, Aug 26, 2022 at 04:15:43PM +0100, Stuart Henderson wrote:
> > > > On 2022/08/26 09:49, Klemens Nanni wrote:
> > > > > grep
On Wed, Aug 24, 2022 at 03:03:01PM +0100, Stuart Henderson wrote:
Anyone want to test this?
Any OKs?
Hello,
Seemed to patch OK and built OK with a -current made yesterday, on aarch64.
I'm a newbie at building/patching openbsd, so if there's anything you
can suggest I test, I'll test.
Mark Kettenis wrote:
> > From: "Theo de Raadt"
> > Date: Fri, 26 Aug 2022 09:53:35 -0600
> >
> > Klemens Nanni wrote:
> >
> > > On Fri, Aug 26, 2022 at 04:15:43PM +0100, Stuart Henderson wrote:
> > > > On 2022/08/26 09:49, Klemens Nanni wrote:
> > > > > grep and CVS agree that this is a
> From: "Theo de Raadt"
> Date: Fri, 26 Aug 2022 09:53:35 -0600
>
> Klemens Nanni wrote:
>
> > On Fri, Aug 26, 2022 at 04:15:43PM +0100, Stuart Henderson wrote:
> > > On 2022/08/26 09:49, Klemens Nanni wrote:
> > > > grep and CVS agree that this is a switch(4) left-over.
> > > >
> > > > OK?
>
Hi,
TLDR:
1. When did PCs stop using ISA Timer 1 to trigger DRAM refresh?
2. Are any PCs that rely on ISA Timer 1 for DRAM refresh capable of
running OpenBSD as it exists today?
Long version:
I have a history question for the list. Maybe one of you hardware
jocks or history buffs can help
On Fri, Aug 26, 2022 at 09:53:35AM -0600, Theo de Raadt wrote:
> Klemens Nanni wrote:
>
> > On Fri, Aug 26, 2022 at 04:15:43PM +0100, Stuart Henderson wrote:
> > > On 2022/08/26 09:49, Klemens Nanni wrote:
> > > > grep and CVS agree that this is a switch(4) left-over.
> > > >
> > > > OK?
> > >
Hi Matthieu,
I'd be inclined to go with a return in the middle and avoid some extra
variables, what do you think about the following (entirely eye-ball tested)?
char*pass;
/* buffer can be in the form style:pass */
if ((pass = strchr(buffer, ':')) != NULL) {
Klemens Nanni wrote:
> On Fri, Aug 26, 2022 at 04:15:43PM +0100, Stuart Henderson wrote:
> > On 2022/08/26 09:49, Klemens Nanni wrote:
> > > grep and CVS agree that this is a switch(4) left-over.
> > >
> > > OK?
> >
> > This is exported to userland isn't it?
>
> No, everything is under
On Fri, Aug 26, 2022 at 04:15:43PM +0100, Stuart Henderson wrote:
> On 2022/08/26 09:49, Klemens Nanni wrote:
> > grep and CVS agree that this is a switch(4) left-over.
> >
> > OK?
>
> This is exported to userland isn't it?
No, everything is under _KERNEL.
ok ?
(although I didn't get an answer from Jean-Michel yet, I'm quite sure
the issue is real and the fix correct).
- Forwarded message from Matthieu Herrb -
Date: Tue, 23 Aug 2022 11:08:28 +0200
From: Matthieu Herrb
To: BESSOT Jean-Michel
Cc: b...@openbsd.org
Subject: Re: xlock don't
On Fri, Aug 26, 2022 at 05:27:08PM +0200, Claudio Jeker wrote:
> On Fri, Aug 26, 2022 at 04:15:43PM +0100, Stuart Henderson wrote:
> > On 2022/08/26 09:49, Klemens Nanni wrote:
> > > grep and CVS agree that this is a switch(4) left-over.
> > >
> > > OK?
> >
> > This is exported to userland isn't
On Fri, Aug 26, 2022 at 04:15:43PM +0100, Stuart Henderson wrote:
> On 2022/08/26 09:49, Klemens Nanni wrote:
> > grep and CVS agree that this is a switch(4) left-over.
> >
> > OK?
>
> This is exported to userland isn't it?
I seariously hope not. All those caddr_t are kernel pointers.
In
On 2022/08/26 09:49, Klemens Nanni wrote:
> grep and CVS agree that this is a switch(4) left-over.
>
> OK?
This is exported to userland isn't it?
If so, I think all ports using it will need a bump.
> Index: if_var.h
> ===
> RCS
On Fri, Aug 26, 2022 at 01:48:55PM +0200, Theo Buehler wrote:
> It occurred to me right after committing the previous change that it is
> doing the same thing as valid_uri(). Calling it is simpler and the
> additional "/." check won't hurt.
This is indeed OK. What worries me a bit is that the
On Fri, Aug 26, 2022 at 01:42:15PM +0200, Theo Buehler wrote:
> On Fri, Aug 26, 2022 at 10:58:38AM +0200, Claudio Jeker wrote:
> > Noticed on a route collector with >100 full feeds and well 80Mio prefixes.
> > On startup the RDE slurps in a lot of messages and then slowly processes
> > them. Those
It occurred to me right after committing the previous change that it is
doing the same thing as valid_uri(). Calling it is simpler and the
additional "/." check won't hurt.
Index: main.c
===
RCS file:
On Fri, Aug 26, 2022 at 10:58:38AM +0200, Claudio Jeker wrote:
> Noticed on a route collector with >100 full feeds and well 80Mio prefixes.
> On startup the RDE slurps in a lot of messages and then slowly processes
> them. Those are mostly IMSG_UDPATE but the current code also queues
>
grep and CVS agree that this is a switch(4) left-over.
OK?
Index: if_var.h
===
RCS file: /cvs/src/sys/net/if_var.h,v
retrieving revision 1.114
diff -u -p -r1.114 if_var.h
--- if_var.h20 Feb 2021 04:55:52 - 1.114
+++
installboot(8) runs newfs_msdos(8) via system(3) but only checks failures
of the function itself, always returning zero no matter what newfs_msdos
returned.
This is bad for regress tests relying on correct return codes.
create_filesystem() itself must not exit as write_filesystem() calls it and
Noticed on a route collector with >100 full feeds and well 80Mio prefixes.
On startup the RDE slurps in a lot of messages and then slowly processes
them. Those are mostly IMSG_UDPATE but the current code also queues
IMSG_SESSION_DOWN, IMSG_SESSION_UP and the graceful restart imsgs.
It does not
yep, ok.
jmc
On 26 August 2022 09:33:00 BST, Klemens Nanni wrote:
>On Fri, Aug 26, 2022 at 06:25:56AM +0100, Jason McIntyre wrote:
>> On Thu, Aug 25, 2022 at 09:19:09PM +, Klemens Nanni wrote:
>> > -l takes chunks as per the manual, not specials.
>> >
>> > I also think that comma separated
On Fri, Aug 26, 2022 at 06:25:56AM +0100, Jason McIntyre wrote:
> On Thu, Aug 25, 2022 at 09:19:09PM +, Klemens Nanni wrote:
> > -l takes chunks as per the manual, not specials.
> >
> > I also think that comma separated lists are marked up overly
> > confusing, so reduce it by one level, i.e.
On Fri, Aug 26, 2022 at 09:57:19AM +0200, Theo Buehler wrote:
> First, if there's an issue opening the default skip list file other than
> its absence (most likely bad permissions), we should not silently ignore
> it. Also, let's display the error, so use err().
>
> Second, linelen, the return
First, if there's an issue opening the default skip list file other than
its absence (most likely bad permissions), we should not silently ignore
it. Also, let's display the error, so use err().
Second, linelen, the return value of getline() is not currently used.
Since strcspn() already computes
On Thu, Aug 25, 2022 at 09:19:09PM +, Klemens Nanni wrote:
> -l takes chunks as per the manual, not specials.
>
> I also think that comma separated lists are marked up overly
> confusing, so reduce it by one level, i.e. turn
> -l chunk[,chunk[,...]]]
> into
> -l chunk[,...]]
>
>
34 matches
Mail list logo