Hello,
I tried to install stable flavor from USB on the MBP 13-inch 2019, with
no luck, and the following issues:
1. Booting kernel messages
Centered on the screen, with a very small size, not working well for
reading.
2. After booting, keyboard not working
I had to connect an USB KB.
I spotted this while working on iwx(4).
Setting up ic_myaddr when we're about to scan for APs is rather late in
the game. All these drivers are already setting up ic_myaddr during the
device initialization phase, long before they get here.
This seems to be a copy-paste error in iwn(4)
> Date: Thu, 11 Jun 2020 10:48:09 +0200
> From: Stefan Sperling
>
> I spotted this while working on iwx(4).
>
> Setting up ic_myaddr when we're about to scan for APs is rather late in
> the game. All these drivers are already setting up ic_myaddr during the
> device initialization phase, long
On 2020-06-11 03:42, Theo de Raadt wrote:
Christian Weisgerber wrote:
Paul Irofti:
This iteration of the diff adds bounds checking for tk_user and moves
the usertc.c stub to every arch in libc as recommanded by deraadt@.
It also fixes a gettimeofday issue reported by cheloha@ and tb@.
On Thu, Jun 11, 2020 at 11:00:30AM +0200, Mark Kettenis wrote:
> > Date: Thu, 11 Jun 2020 10:48:09 +0200
> > From: Stefan Sperling
> >
> > I spotted this while working on iwx(4).
> >
> > Setting up ic_myaddr when we're about to scan for APs is rather late in
> > the game. All these drivers are
On 2020-06-11 02:46, Christian Weisgerber wrote:
Paul Irofti:
This iteration of the diff adds bounds checking for tk_user and moves
the usertc.c stub to every arch in libc as recommanded by deraadt@.
It also fixes a gettimeofday issue reported by cheloha@ and tb@.
Additionally, it changes
On 2020-06-11 01:16, Christian Weisgerber wrote:
Paul Irofti:
This iteration of the diff adds bounds checking for tk_user and moves
the usertc.c stub to every arch in libc as recommanded by deraadt@.
It also fixes a gettimeofday issue reported by cheloha@ and tb@.
Forgot to add armv7
> Date: Thu, 11 Jun 2020 11:42:23 +0200
> From: Stefan Sperling
>
> On Thu, Jun 11, 2020 at 11:00:30AM +0200, Mark Kettenis wrote:
> > > Date: Thu, 11 Jun 2020 10:48:09 +0200
> > > From: Stefan Sperling
> > >
> > > I spotted this while working on iwx(4).
> > >
> > > Setting up ic_myaddr when
> Date: Thu, 11 Jun 2020 14:49:54 +0200
> From: Marc Espie
>
> On Thu, Jun 11, 2020 at 03:42:27PM +0300, Paul Irofti wrote:
> > On Thu, Jun 11, 2020 at 02:05:44PM +0200, Marc Espie wrote:
> > > On Thu, Jun 11, 2020 at 01:13:07PM +0300, Paul Irofti wrote:
> > > > On 2020-06-11 02:46, Christian
On Thu, Jun 11, 2020 at 02:49:54PM +0200, Marc Espie wrote:
> On Thu, Jun 11, 2020 at 03:42:27PM +0300, Paul Irofti wrote:
> > On Thu, Jun 11, 2020 at 02:05:44PM +0200, Marc Espie wrote:
> > > On Thu, Jun 11, 2020 at 01:13:07PM +0300, Paul Irofti wrote:
> > > > On 2020-06-11 02:46, Christian
Fix a horribly mangled sentence. Would "may" be more appropriate
than "can"?
Also, in the list of usages: for serverAuth and clientAuth, shouldn't
the word "web" be elided?
Ross
Index: x509v3.cnf.5
===
RCS file:
On Thu, Jun 11, 2020 at 01:13:07PM +0300, Paul Irofti wrote:
> On 2020-06-11 02:46, Christian Weisgerber wrote:
> > Paul Irofti:
> >
> > > This iteration of the diff adds bounds checking for tk_user and moves
> > > the usertc.c stub to every arch in libc as recommanded by deraadt@.
> > > It also
On Thu, Jun 11, 2020 at 02:05:44PM +0200, Marc Espie wrote:
> On Thu, Jun 11, 2020 at 01:13:07PM +0300, Paul Irofti wrote:
> > On 2020-06-11 02:46, Christian Weisgerber wrote:
> > > Paul Irofti:
> > >
> > > > This iteration of the diff adds bounds checking for tk_user and moves
> > > > the
Christian Weisgerber:
> Should we already bump major while the diff matures?
Oh, we can't quite bump yet. tk_major und tk_minor are only set
in exec_timekeep_map(), but aren't checked anywhere.
+ timekeep->tk_major = 0;
+ timekeep->tk_minor = 0;
Those shouldn't be
On Thu, Jun 11, 2020 at 03:42:27PM +0300, Paul Irofti wrote:
> On Thu, Jun 11, 2020 at 02:05:44PM +0200, Marc Espie wrote:
> > On Thu, Jun 11, 2020 at 01:13:07PM +0300, Paul Irofti wrote:
> > > On 2020-06-11 02:46, Christian Weisgerber wrote:
> > > > Paul Irofti:
> > > >
> > > > > This iteration
On Thu, 11 Jun 2020 at 08:29:12 +0200, Romero Pérez, Abel wrote:
> Hello,
>
> I tried to install stable flavor from USB on the MBP 13-inch 2019, with no
> luck, and the following issues:
>
> 1. Booting kernel messages
>
> Centered on the screen, with a very small size, not working well for
>
Intel has moved Tx rate selection code from the Linux iwlwifi driver into
ax200 device firmware. There is code in iwlwifi/mvm/rs.c which should more
or less match what the firmware is doing, given how the firmware API works.
Equivalent functionality is offered by AMRR/MiRA in our kernel.
During
I think this conversation about major numbers, and now minor numbers,
is incredibly silly.
Do we have a major number on the open(2) system call? No, and the main
reason is because the code isn't a draft, it was completed.
This needs to support as many architectures as possible, then it goes
in.
> Date: Thu, 11 Jun 2020 16:27:03 +0300
> From: Paul Irofti
>
> On Thu, Jun 11, 2020 at 02:49:54PM +0200, Marc Espie wrote:
> > On Thu, Jun 11, 2020 at 03:42:27PM +0300, Paul Irofti wrote:
> > > On Thu, Jun 11, 2020 at 02:05:44PM +0200, Marc Espie wrote:
> > > > On Thu, Jun 11, 2020 at
POSIX doesn't permit an unescaped '/' in an extended regular expression.
Unlike upstream awk, ours has historically allowed unescaped '/'
inside a bracket expression for compatibility with other awk
implementations but the check was too simple-minded. This improves
the matching to allow things
Paul Irofti:
> > Additionally, it changes struct timekeep in an incompatible way. ;-)
> > A userland built before the addition of tk_nclocks is very unhappy
> > with a kernel built afterwards.
>
> I have not seen this problem and have not built a snapshot to update or go
> back. What do you mean
On Thu, Jun 11, 2020 at 07:55:44AM -0600, Theo de Raadt wrote:
> I think this conversation about major numbers, and now minor numbers,
> is incredibly silly.
>
> Do we have a major number on the open(2) system call? No, and the main
> reason is because the code isn't a draft, it was completed.
>
Paul Irofti wrote:
> > I want to see this diff support 3-4 architectures before commit.
>
> Sure. Whenever you feel confident. As I said numerous times now here,
> nobody is pressuring this with a commit.
>
> I think we support already 3 architectures: amd64, macppc, sparc64
> (kettenis?).
I
Paul Irofti:
> > Paul, that tk_nclocks addition isn't useful. You need to do the
> > bounds checking against the number of clocks you have implemented in
> > libc. How many clocks the kernel has implemented doesn't matter.
>
> What you are saying is that we could be in a situation where the
On 2020-06-11 16:54, Mark Kettenis wrote:
Date: Thu, 11 Jun 2020 16:27:03 +0300
From: Paul Irofti
On Thu, Jun 11, 2020 at 02:49:54PM +0200, Marc Espie wrote:
On Thu, Jun 11, 2020 at 03:42:27PM +0300, Paul Irofti wrote:
On Thu, Jun 11, 2020 at 02:05:44PM +0200, Marc Espie wrote:
On Thu, Jun
Paul Irofti:
[lib/libc/arch/*/gen/usertc.c]
> +int (*const _tc_get_timecount)(struct timekeep *, uint64_t *) = NULL;
[lib/libc/sys/microtime.c]
> +static inline int
> +tc_delta(struct timekeep *tk, u_int *delta)
> +{
> + uint64_t tc;
> + if (delta == NULL || _tc_get_timecount(tk, ))
Paul Irofti wrote:
> On Thu, Jun 11, 2020 at 02:05:44PM +0200, Marc Espie wrote:
> > On Thu, Jun 11, 2020 at 01:13:07PM +0300, Paul Irofti wrote:
> > > On 2020-06-11 02:46, Christian Weisgerber wrote:
> > > > Paul Irofti:
> > > >
> > > > > This iteration of the diff adds bounds checking for
> Date: Thu, 11 Jun 2020 17:29:44 +0200
> From: Christian Weisgerber
>
> Paul Irofti:
>
> > > Paul, that tk_nclocks addition isn't useful. You need to do the
> > > bounds checking against the number of clocks you have implemented in
> > > libc. How many clocks the kernel has implemented
Mark Kettenis wrote:
> > Date: Thu, 11 Jun 2020 17:29:44 +0200
> > From: Christian Weisgerber
> >
> > Paul Irofti:
> >
> > > > Paul, that tk_nclocks addition isn't useful. You need to do the
> > > > bounds checking against the number of clocks you have implemented in
> > > > libc. How many
On Thu, Jun 11, 2020 at 09:55:50PM +1000, Ross L Richardson wrote:
>
> Fix a horribly mangled sentence. Would "may" be more appropriate
> than "can"?
>
hi.
i think the rewording is fine. i don;t think we should change "may" to
"can" though.
> Also, in the list of usages: for serverAuth and
Hello Joshua,
thanks by your answer.
I just was sending a feedback and pretending to develop it alone. But
actually I have not so much time, so I'm going to take it easy.
On 2020-06-11 13:43, joshua stein wrote:
On Thu, 11 Jun 2020 at 08:29:12 +0200, Romero Pérez, Abel wrote:
Hello,
I
> Date: Thu, 11 Jun 2020 19:38:48 +0200
> From: Christian Weisgerber
>
> Theo de Raadt:
>
> > The diff is growing complexity to support a future which wouldn't
> > exist if attempts at *supporting all* architectures received priority.
>
> Adding support for more archs is very simple, since you
Theo de Raadt:
> The diff is growing complexity to support a future which wouldn't
> exist if attempts at *supporting all* architectures received priority.
Adding support for more archs is very simple, since you just need
to copy the corresponding get_timecounter function from the kernel.
On Thu, Jun 11, 2020 at 05:38:32PM +0100, Jason McIntyre wrote:
> On Thu, Jun 11, 2020 at 09:55:50PM +1000, Ross L Richardson wrote:
> >
> > Fix a horribly mangled sentence. Would "may" be more appropriate
> > than "can"?
> >
>
> hi.
>
> i think the rewording is fine. i don;t think we should
On Thu, Jun 11, 2020 at 07:13:52PM +0200, Theo Buehler wrote:
> On Thu, Jun 11, 2020 at 05:38:32PM +0100, Jason McIntyre wrote:
> > On Thu, Jun 11, 2020 at 09:55:50PM +1000, Ross L Richardson wrote:
> > >
> > > Fix a horribly mangled sentence. Would "may" be more appropriate
> > > than "can"?
>
Hello Ingo,
Thanks for looking into this.
On Sun, 2020-05-31 at 16:32 +0200, Ingo Schwarze wrote:
> Hi Martijn,
>
> Martijn van Duren wrote on Tue, May 19, 2020 at 10:25:37PM +0200:
>
> > So according to RFC2579 an octetstring can contain UTF-8 characters if
> > so described in the
On Wed, Jun 10, 2020 at 11:47:49PM +0200, Sebastian Benoit wrote:
> Remi Locherer(remi.loche...@relo.ch) on 2020.06.10 22:16:36 +0200:
> > On Tue, Jun 09, 2020 at 10:02:06AM +0200, Remi Locherer wrote:
> > > On Tue, Jun 09, 2020 at 09:17:31AM +0200, Claudio Jeker wrote:
> > > > On Tue, Jun 09,
Mark Kettenis wrote:
> suggestion to have an MD header file actually helps. With that file
> we can easily avoid the function pointer and it becomes easier adding
> new timecounters in the kernel (which happens from time to time).
When does this happen?
If it happens, what's the fuss? The
On Wed, Jun 10, 2020 at 11:44:17PM +0100, Stuart Henderson wrote:
> It's useful information, I like it. (I preferred it with the route
> count, but I agree, it's hard on the system if there's a full DFZ
> table).
>
> One thing though -
>
> > twister ..in/netstat$ obj/netstat -R
> > Rdomain 0
>
39 matches
Mail list logo
