> Date: Wed, 17 Feb 2021 11:32:42 +0100
> From: Stefan Sperling <s...@stsp.name>
>
> On Tue, Feb 16, 2021 at 11:24:31PM +0100, Grégoire Jadi wrote:
> > Hi,
> >
> > Here is another uvm_fault related to iwn, but this time *not* when
> > unhibernating. I just "grabbed" my laptop that was playing music.
> >
> > uvm_fault(0xffffffff82169730, 0xffff800000020738, 0, 2) -> e
> > kernel: page fault trap, code=0
> > Stopped at idt_vec_free+0x28: movq $0,0x8(%rax,%rdx,1)
> > ddb{2}> idt_vec_free(73) at idt_vec_free+0x28
> > intr_disestablish(ffff8000000ffe80) at intr_disestablish+0xff
> > iwn_detach(ffff800000137000,1) at iwn_detach+0x53
> > config_detach(ffff800000137000,1) at config_detach+0x142
> > config_detach_children(ffff800000120100,1) at config_detach_children+0x61
> > pci_detach_devices(ffff800000120100,1) at pci_detach_devices+0x24
> > ppb_hotplug_remove(ffff80000011fc00) at ppb_hotplug_remove+0x32
> > taskq_thread(ffffffff820fcd60) at taskq_thread+0x81
> > end trace frame: 0x0, count: -8
> >
> > Tell me if there is more information that I can provide when this occur
> > and I drop into ddb (a `show what` command?).
>
> This device *should* not actually ever detach. The suspend/resume path
> for this device assumes that the device is powered down but will remain
> attached on the PCI bus.
>
> If the device is detaching unexpectedly then the underlying reason may
> well be hardware-related.
>
> Else I am not sure whether this problem would need a fix in iwn or in
> the PCI bus code. Perhaps the iwn detach code is broken but that's because
> virtually nobody is able to actually test it. I don't think iwn hardware
> exists in hot-pluggable configurations.
This could be related to ASPM. So it might be worth trying to turn
that off. There are a few PCI drivers in the tree that do this. It
may also be possible to turn ASPM off in the BIOS.
