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 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
> > intel_dp_wait_source_oui() is called before intel_dp->last_oui_write is
> > set and this results in a 10min timeout because our jiffies are set to
> > ULONG_MAX - (10 * 60 * HZ);
>
> After talking with kettenis@ I think the following diff is better.
> Starting with 0 jiffies should fix this issue.
> Unless we want to do the linux madness and set it to
> ((unsigned long)(unsigned int) (-300*HZ))
>
> --
> :wq Claudio
>
> Index: kern_clock.c
> ===================================================================
> RCS file: /cvs/src/sys/kern/kern_clock.c,v
> retrieving revision 1.109
> diff -u -p -r1.109 kern_clock.c
> --- kern_clock.c 25 Jul 2023 18:16:19 -0000 1.109
> +++ kern_clock.c 31 Jul 2023 20:01:57 -0000
> @@ -84,7 +84,7 @@ int profhz;
> int profprocs;
> int ticks = INT_MAX - (15 * 60 * HZ);
>
> -volatile unsigned long jiffies = ULONG_MAX - (10 * 60 * HZ);
> +volatile unsigned long jiffies;
>
> /*
> * Initialize clock frequencies and start both clocks running.
>
