Mark Kettenis <[email protected]> writes: >> Date: Wed, 17 Feb 2021 11:32:42 +0100 >> From: Stefan Sperling <[email protected]> >> >> 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.
Thanks, I'll check it. -- gjadi PGP : AF26 E9C2 A1C8 8D32 A868 4386 1373 5477 2B65 1894
