"Theo de Raadt" <dera...@openbsd.org> writes:

> Mark Kettenis <mark.kette...@xs4all.nl> wrote:
>
>> > 0(ffffd85fe50a7e0,2,35d87c,4505,ffff80000025c000,fffffd85fe50a7e0) at 0
>> > scsi_done(fffffd85fe50a7e0) at scsi_done+0x31
>> > nvme_q_complete(ffff800000255000, ffff800002c79a80) at 
>> > nume_q_complete+0x134
>> > nume_intr(ffff800000255000) at nume_intr+0x2b
>> > intr_handler(ffff800049e24990, ffff800000254200) at intr_handler+0x91
>> > Xintr_ioapic_edge28_untramp() at Xintr_ioapic_edge28_untramp+0x18f
>> > acpicpu_idle() at acpicpu_idle+0x131
>> > sched_idle(ffffffff82770ff0) at sched_idle+0x298
>> > 
>> > end trace frame: 0x0, count: 8
>> 
>> I think this is a bug in nvme(4).  For some reason it gets a
>> (spurious?)  interrupt while in the suspended state with stuff torn
>> down and dereferences a stale pointer.  We probably need to do a
>> better job quiescing the thing when we suspend.
>
> No kidding.
>
> dv, did you get anywhere with your various diffs?  Greg, can you try
> out the various diffs he sent?  It's a mishmash of solutions not yet
> entirely decided.

I tried "Re: stop powering off ppb(4) if not hotplug (fixes Go3 S0)"
and I still got a prompt crash in sd_buf_done.

I also tried "Re: panic resuming from S0 on Go3"
index fe8764b0323..314f1ae4413 100644
and it still crashed but much more slowly, probably similar
to dv@'s observations of 15s delays.

I tested both on top of "Revert the knote_processexit() bits of the diff."

If there are other patches I can try, it's only a quick recompile and
reboot away.

Thanks
Greg

Reply via email to