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.
