On Sat, Jul 29, 2023 at 03:00:59PM +0300, Vitaliy Makkoveev wrote:
> On Sat, Jul 29, 2023 at 11:16:14AM +0200, Claudio Jeker wrote:
> > proc0 aka the swapper does not do anything. So there is no need to wake it
> > up. Now the problem is that last time this was tried some inteldrm systems
> > did
On Mon, Jul 31, 2023 at 09:49:30PM +0200, Claudio Jeker wrote:
> On Mon, Jul 31, 2023 at 08:03:41PM +0300, Vitaliy Makkoveev wrote:
> > This is the culprit:
> >
> > schedule_timeout_uninterruptible(long timeout)
> > {
> > tsleep(curproc, PWAIT, "schtou", timeout);
> > return 0;
>
Hello,
the issue has been reported by Gianni Kapetanakis month ago [1]. It took
several emails to figure out relayd(8) exists after hosts got disabled
by 'relayctl host dis ...'
The thing is that relayd(8) relies on pf(4) to create persistent
tables (PFR_TFLAG_PERSIST) as relayd requests that:
On Mon, Jul 31, 2023 at 10:04:44PM +0200, Claudio Jeker wrote:
> On Mon, Jul 31, 2023 at 09:49:30PM +0200, Claudio Jeker wrote:
> > On Mon, Jul 31, 2023 at 08:03:41PM +0300, Vitaliy Makkoveev wrote:
> > > This is the culprit:
> > >
> > > schedule_timeout_uninterruptible(long timeout)
> > > {
> >
On Mon, Jul 31, 2023 at 08:03:41PM +0300, Vitaliy Makkoveev wrote:
> This is the culprit:
>
> schedule_timeout_uninterruptible(long timeout)
> {
> tsleep(curproc, PWAIT, "schtou", timeout);
> return 0;
> }
>
Please give this a try. I think on initialization
On Sun, 30 Jul 2023 20:20:31 -0500, Scott Cheloha wrote:
> This patch drags ualarm.3 over to where alarm.3 is. I think it reads
> better and the wording is truer to what the function actually does.
> In particular, ualarm(3) does not block or "wait": the alarm is
> scheduled for asynchronous
This is the culprit:
schedule_timeout_uninterruptible(long timeout)
{
tsleep(curproc, PWAIT, "schtou", timeout);
return 0;
}
On Mon, Jul 31, 2023 at 08:03:41PM +0300, Vitaliy Makkoveev wrote:
> This is the culprit:
>
> schedule_timeout_uninterruptible(long timeout)
> {
> tsleep(curproc, PWAIT, "schtou", timeout);
> return 0;
> }
Not really. The problem is lower in intel_dp_wait_source_oui().
Which
On Mon, Jul 31, 2023 at 10:04:44PM +0200, Claudio Jeker wrote:
> On Mon, Jul 31, 2023 at 09:49:30PM +0200, Claudio Jeker wrote:
> > On Mon, Jul 31, 2023 at 08:03:41PM +0300, Vitaliy Makkoveev wrote:
> > > This is the culprit:
> > >
> > > schedule_timeout_uninterruptible(long timeout)
> > > {
> >
On Mon, Jul 31, 2023 at 09:49:30PM +0200, Claudio Jeker wrote:
> On Mon, Jul 31, 2023 at 08:03:41PM +0300, Vitaliy Makkoveev wrote:
> > This is the culprit:
> >
> > schedule_timeout_uninterruptible(long timeout)
> > {
> > tsleep(curproc, PWAIT, "schtou", timeout);
> > return 0;
>
The jiffies patch plus the patch in uvm_meter worked for me. It even booted a
little faster than normal.
On Mon, Jul 31, 2023 at 10:04:44PM +0200, Claudio Jeker wrote:
> On Mon, Jul 31, 2023 at 09:49:30PM +0200, Claudio Jeker wrote:
> > On Mon, Jul 31, 2023 at 08:03:41PM +0300, Vitaliy Makkoveev
On Mon, Jul 31, 2023 at 10:04:44PM +0200, Claudio Jeker wrote:
> On Mon, Jul 31, 2023 at 09:49:30PM +0200, Claudio Jeker wrote:
> > On Mon, Jul 31, 2023 at 08:03:41PM +0300, Vitaliy Makkoveev wrote:
> > > This is the culprit:
> > >
> > > schedule_timeout_uninterruptible(long timeout)
> > > {
> >
Now that we have accessors for the SignedData and SignerInfo version
in libcrypto, let's put them to their intended use. For portable I have
made a PR to provide compat shims.
Index: cms.c
===
RCS file:
> Date: Mon, 31 Jul 2023 22:12:35 +0900
> From: SASANO Takayoshi
>
> Hi,
>
> Mango Pi MQ-Quad and OrangePi Zero3 has X-Power AXP313A PMIC.
>
> Here is a diff, but AXP313A's dcdc1 is not fully supported.
>
> dcdc1 has three voltage ranges:
> 0.5-1.2V, 10mV/step (71 steps)
>
On Sat, Jul 29, 2023 at 11:16:14AM +0200, Claudio Jeker wrote:
> proc0 aka the swapper does not do anything. So there is no need to wake it
> up. Now the problem is that last time this was tried some inteldrm systems
> did hang during bootup because the drm code unexpectedly depended on this
>
On Fri, Jul 28, 2023 at 07:36:41PM -0500, Scott Cheloha wrote:
> claudio@ notes that uvm_loadav() pointlessly walks the allproc list to
> recompute schedstate_percpu.spn_nrun for each CPU.
>
> We can just use the value instead of recomputing it.
Whoops, off-by-one. The current load averaging
Hi,
Mango Pi MQ-Quad and OrangePi Zero3 has X-Power AXP313A PMIC.
Here is a diff, but AXP313A's dcdc1 is not fully supported.
dcdc1 has three voltage ranges:
0.5-1.2V, 10mV/step (71 steps)
1.22-1.54V 20mV/step (17 steps)
1.6-3.4V 100mV/step (19 steps) *not supported this
17 matches
Mail list logo
