> From: Greg Steuck
> Date: Mon, 05 Aug 2024 22:55:03 -0700
>
> With all the great work happening around the different flavors of zzz I
> thought I'd try to test some of this on my desktop. This machine wakes up
> reliably from suspend in Linux. Some days it even wakes up in OpenBSD,
> but mostly
> From: Stefano Dalla Valentina
> Date: Tue, 6 Aug 2024 07:43:40 +0200
>
> During the boot process with xenodm disabled even if inteldrm0 has
> resolution of 1440x900 and wsdisplay0: screen 1-5 was created the screen is
> black. If I login and rcctl -f start xenodm with the screen black xenodm
>
> Date: Mon, 5 Aug 2024 22:23:17 +0200
> From: Matthias Schmidt
Hi Matthias,
Can you try to narrow this down a bit further?
You can either bisect by building kernels from intermediate dates
yourself or use kernels from the snapshot archive at:
https://ftp.hostserver.de/archive/
Thanks,
Mar
On Tue, Aug 06, 2024 at 11:20:02AM +0200, Mark Kettenis wrote:
> > From: Matthias Schmidt
>
> Hi Matthias,
>
> Can you try to narrow this down a bit further?
>
> You can either bisect by building kernels from intermediate dates
> yourself or use kernels from the snapshot archive at:
>
> http
Mark Kettenis wrote:
> > 0(d85fe50a7e0,2,35d87c,4505,8025c000,fd85fe50a7e0) at 0
> > scsi_done(fd85fe50a7e0) at scsi_done+0x31
> > nvme_q_complete(80255000, 82c79a80) at nume_q_complete+0x134
> > nume_intr(80255000) at nume_intr+0x2b
> > intr_handler(ff
I think this nvme thing is possibly related to a whole bunch of hidden
resume failures.
>Synopsis: kernel fails to boot after Jul 14 (bisected) snapshot
>Category: kernel
>Environment:
System : OpenBSD 7.5
Details : OpenBSD 7.5-current (GENERIC.MP) #189: Sun Jul 14
06:08:28 MDT 2024
dera...@amd64.openbsd.org:/usr/src/sys/ar
"Theo de Raadt" writes:
> Mark Kettenis wrote:
>
>> > 0(d85fe50a7e0,2,35d87c,4505,8025c000,fd85fe50a7e0) at 0
>> > scsi_done(fd85fe50a7e0) at scsi_done+0x31
>> > nvme_q_complete(80255000, 82c79a80) at
>> > nume_q_complete+0x134
>> > nume_intr(80255000
No the problem will be in nvme_intr(), it should not be reaching
nvme_q_complete(), let alone finding something in the queue to hand
off to scsi_done().
I suspect it has gotten confused by an index that has been reset, and
is replying an operation it finds in the memory.
nvme resume is really crazy, since it does not believe the device is
stopped, tries to use high-level operations to stop it and then restart
it, but it ends up reusing queue structures from before.
dv spent time in here, and I tried to figure it out also. The code
is highly suspect since it isn't
10 matches
Mail list logo
