On Mon, Jul 31, 2023 at 08:31:41PM -0500, Scott Cheloha wrote:
> 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:
>
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 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 w
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;
> >
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_o
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 eithe
This is the culprit:
schedule_timeout_uninterruptible(long timeout)
{
tsleep(curproc, PWAIT, "schtou", timeout);
return 0;
}
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 h
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
> wake
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
> wake
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
> wake
14 matches
Mail list logo
