search for: pcieport

On Mon, Sep 07, 2020 at 09:14:03PM +0200, Karol Herbst wrote: > > - changes in the nouveau driver. Mika told me the PCIe regression > > "pcieport 0000:00:01.0: PME: Spurious native interrupt!" is supposed > > to be fixed in 5.8, but I still get a 4mn hang or so during boot and > > with 5.8, removing the USB key, didn't help make the boot faster > > that's the root port the GPU is attached to, no? I saw tha...

On Mon, Sep 7, 2020 at 10:58 PM Marc MERLIN <marc_nouveau at merlins.org> wrote: > > On Mon, Sep 07, 2020 at 09:14:03PM +0200, Karol Herbst wrote: > > > - changes in the nouveau driver. Mika told me the PCIe regression > > > "pcieport 0000:00:01.0: PME: Spurious native interrupt!" is supposed > > > to be fixed in 5.8, but I still get a 4mn hang or so during boot and > > > with 5.8, removing the USB key, didn't help make the boot faster > > > > that's the root port the GPU is attache...

...thunderbold on thinkpad P73, that seems to be triggered if I have a USB-C yubikey in the port. With 5.7, my issues went away if I removed the USB key during boot, showing an interaction between nouveau and thunderbolt - changes in the nouveau driver. Mika told me the PCIe regression "pcieport 0000:00:01.0: PME: Spurious native interrupt!" is supposed to be fixed in 5.8, but I still get a 4mn hang or so during boot and with 5.8, removing the USB key, didn't help make the boot faster I don't otherwise use the nvidia chip I so wish I didn't have, I only use intel grap...

On Tue, Sep 08, 2020 at 01:51:19AM +0200, Karol Herbst wrote: > oh, I somehow missed that "disp ctor failed" message. I think that > might explain why things are a bit hanging. From the top of my head I > am not sure if that's something known or something new. But just in > case I CCed Lyude and Ben. And I think booting with > nouveau.debug=disp=trace could already

...rnet. However, some things are also broken, most noticably the wireless driver doesn''t work, which is kind of a deal breaker on a laptop. So time to dig in the logs, to see what''s going on, here''s a part from my dmesg that hints that something is wrong: [ 3.957006] pcieport 0000:00:01.0: device [8086:0d01] has invalid IRQ; check vendor BIOS [ 3.957018] pcieport 0000:00:01.0: can''t find IRQ for PCI INT A; please try using pci=biosirq [ 3.957108] pcieport 0000:00:1c.0: device [8086:8c10] has invalid IRQ; check vendor BIOS [ 3.957120] pcieport 0000:0...

...dom crashes with i play certain (not all) games in (dual boot) windows 10, and maybe there is a connection with the error emitted by nouveau driver. Any help in understanding the meaning of logs and how to fix it would be appreciated. Pasting the logs below $ dmesg --raw | grep -P "(nouveau|pcieport)" <6>[ 1.020802] pcieport 0000:00:1c.0: AER enabled with IRQ 122 <6>[ 1.020819] pcieport 0000:00:1c.4: AER enabled with IRQ 123 <6>[ 1.020833] pcieport 0000:00:1c.5: AER enabled with IRQ 124 <6>[ 1.020852] pcieport 0000:00:1d.3: AER enabled with IRQ 126 <...

...that seems to be > triggered if I have a USB-C yubikey in the port. With 5.7, my issues > went away if I removed the USB key during boot, showing an interaction > between nouveau and thunderbolt > > - changes in the nouveau driver. Mika told me the PCIe regression > "pcieport 0000:00:01.0: PME: Spurious native interrupt!" is supposed > to be fixed in 5.8, but I still get a 4mn hang or so during boot and > with 5.8, removing the USB key, didn't help make the boot faster > that's the root port the GPU is attached to, no? I saw that message on th...

...y:da000000-da012800 To debug, on domu, #dmesg [224.516059] Pcifront pci-0: schedual aer pcifront service [224.516059] Pcifront pci-0: schedual aer pcifront service [224.516059] Pcifront pci-0: schedual aer pcifront service ... ... It continuously pops up this message. On dom0 #dmesg [ 2982.146967] pcieport 0000:00:07.0: AER driver successfully recovered [ 2985.074799] pcieport 0000:00:07.0: AER: Uncorrected (Non-Fatal) error received: id=0038 [ 2985.074848] pcieport 0000:00:07.0: PCIE Bus Error: severity=Uncorrected (Non-Fatal), type=Transaction Layer, id=0038(Requester ID) [ 2985.074855] pcieport 00...

...the systems will remain stable for days or weeks, then suddenly encounter one of these issues. I have yet to tie the error to any specific action on the systems and can't reproduce it reliably. - Supermicro X8DT3, Dual Xeon E5620, 2x 82575EB NICs, 2x 82576 NICs Kernel messages upon failure: pcieport 0000:00:03.0: AER: Multiple Corrected error received: id=0018 pcieport 0000:00:03.0: PCIe Bus Error: severity=Corrected, type=Transaction Layer, id=0018(Receiver ID) pcieport 0000:00:03.0: device [8086:340a] error status/mask=00002000/00001001 pcieport 0000:00:03.0: [13] Advisory Non-Fatal pci...

...lpss 0000:00:15.1: power state changed by ACPI to D3cold snd_hda_intel 0000:00:1f.3: PME# enabled intel-lpss 0000:00:1e.0: power state changed by ACPI to D3cold snd_hda_intel 0000:00:1f.3: power state changed by ACPI to D3hot xhci_hcd 0000:01:00.2: PME# enabled nvidia-gpu 0000:01:00.3: PME# enabled pcieport 0000:05:00.0: PME# enabled xhci_hcd 0000:2c:00.0: PME# enabled pcieport 0000:05:02.0: PME# enabled pcieport 0000:04:00.0: PME# enabled pcieport 0000:00:1c.0: PME# enabled pcieport 0000:00:1c.0: power state changed by ACPI to D3cold nouveau 0000:01:00.0: power state changed by ACPI to D3cold pciepor...

...s/xen/blkback/cdrom.c, line=108) nodename:backend/vbd/2/768 > Mar 10 02:57:05 SunBlade2 kernel: [ 1495.751327] (cdrom_is_type() > file=/usr/src/packages/BUILD/kernel-xen-2.6.32.12/linux-2.6.32/drivers/xen/blkback/cdrom.c, line=95) type:0 > Mar 10 02:57:05 SunBlade2 kernel: [ 1495.936015] pcieport > 0000:00:05.0: AER: Uncorrected (Non-Fatal) error received: id=0028 > Mar 10 02:57:05 SunBlade2 kernel: [ 1496.023732] pcieport > 0000:00:05.0: PCIE Bus Error: severity=Uncorrected (Non-Fatal), > type=Transaction Layer, id=0028(Requester ID) > Mar 10 02:57:05 SunBlade2 kernel: [ 1...

...list irq from dmesg (with NIC detected) and dmesg.old (NIS is not tedected) grep irq dmesg [??? 0.000000] ACPI: INT_SRC_OVR (bus 0 bus_irq 0 global_irq 2 dfl dfl) [??? 0.000000] ACPI: INT_SRC_OVR (bus 0 bus_irq 9 global_irq 9 high level) [??? 0.000000] NR_IRQS:327936 nr_irqs:1024 0 [??? 0.531915] pcieport 0000:00:01.0: irq 120 for MSI/MSI-X [??? 0.532038] pcieport 0000:00:1b.0: irq 121 for MSI/MSI-X [??? 0.532309] pcieport 0000:00:1c.5: irq 122 for MSI/MSI-X [??? 0.532534] pcieport 0000:00:1d.0: irq 123 for MSI/MSI-X [??? 0.604204] 00:05: ttyS0 at I/O 0x3f8 (irq = 4) is a 16550A [??? 0.625761] 00:06...

On Mon, May 30, 2016 at 06:13:51PM +0200, Peter Wu wrote: > Do you have any suggestions for the case where the pcieport driver > refuses to put the bridge in D3 (because the BIOS is too old)? In that > case the nouveau driver needs to fallback to the DSM method (but not > when runtime PM is deliberately disabled by writing control=on). Do you know what Windows does then? I think we should do the same if po...

On Mon, Sep 07, 2020 at 05:29:35PM -0700, Marc MERLIN wrote: > On Tue, Sep 08, 2020 at 01:51:19AM +0200, Karol Herbst wrote: > > oh, I somehow missed that "disp ctor failed" message. I think that > > might explain why things are a bit hanging. From the top of my head I > > am not sure if that's something known or something new. But just in > > case I CCed

...changed by ACPI to D3cold > snd_hda_intel 0000:00:1f.3: PME# enabled > intel-lpss 0000:00:1e.0: power state changed by ACPI to D3cold > snd_hda_intel 0000:00:1f.3: power state changed by ACPI to D3hot > xhci_hcd 0000:01:00.2: PME# enabled > nvidia-gpu 0000:01:00.3: PME# enabled > pcieport 0000:05:00.0: PME# enabled > xhci_hcd 0000:2c:00.0: PME# enabled > pcieport 0000:05:02.0: PME# enabled > pcieport 0000:04:00.0: PME# enabled > pcieport 0000:00:1c.0: PME# enabled > pcieport 0000:00:1c.0: power state changed by ACPI to D3cold > nouveau 0000:01:00.0: power state cha...

...C detected) and dmesg.old (NIS is not > tedected) > grep irq dmesg > [ 0.000000] ACPI: INT_SRC_OVR (bus 0 bus_irq 0 global_irq 2 dfl dfl) > [ 0.000000] ACPI: INT_SRC_OVR (bus 0 bus_irq 9 global_irq 9 high level) > [ 0.000000] NR_IRQS:327936 nr_irqs:1024 0 > [ 0.531915] pcieport 0000:00:01.0: irq 120 for MSI/MSI-X > [ 0.532038] pcieport 0000:00:1b.0: irq 121 for MSI/MSI-X > [ 0.532309] pcieport 0000:00:1c.5: irq 122 for MSI/MSI-X > [ 0.532534] pcieport 0000:00:1d.0: irq 123 for MSI/MSI-X > [ 0.604204] 00:05: ttyS0 at I/O 0x3f8 (irq = 4) is a 16550A...

...tried to load nouveau again? (IRC conversation this week.) Ensure that the pci/pm patches are applied, then: 0. Unload nouveau (I have blacklisted it for testing). 1. Enable rpm for the root port and children (control = auto). 2. Verify in the kernel logs that the devices are sleeping: pcieport 0000:00:01.0: power state changed by ACPI to D3cold 3. (Optional, to rule out issues with delays:) Disable rpm for the Nvidia device (control = on). 4. modprobe nouveau. The above test with v4.6 + 4 pci/pm patches (8b71f565) gives: 50.245795 MXM: GUID detected in BIOS 50.245948 n...

...the systems will remain stable for days or weeks, then suddenly encounter one of these issues. I have yet to tie the error to any specific action on the systems and can't reproduce it reliably. - Supermicro X8DT3, Dual Xeon E5620, 2x 82575EB NICs, 2x 82576 NICs Kernel messages upon failure: pcieport 0000:00:03.0: AER: Multiple Corrected error received: id=0018 pcieport 0000:00:03.0: PCIe Bus Error: severity=Corrected, type=Transaction Layer, id=0018(Receiver ID) pcieport 0000:00:03.0: device [8086:340a] error status/mask=00002000/00001001 pcieport 0000:00:03.0: [13] Advisory Non-Fatal pci...

...or weeks, then suddenly > encounter one of these issues. I have yet to tie the error to any > specific action on the systems and can't reproduce it reliably. > > - Supermicro X8DT3, Dual Xeon E5620, 2x 82575EB NICs, 2x 82576 NICs > > Kernel messages upon failure: > > pcieport 0000:00:03.0: AER: Multiple Corrected error received: id=0018 > pcieport 0000:00:03.0: PCIe Bus Error: severity=Corrected, > type=Transaction Layer, id=0018(Receiver ID) > pcieport 0000:00:03.0: device [8086:340a] error > status/mask=00002000/00001001 > pcieport 0000:00:03.0: [1...

On Tue, May 31, 2016 at 01:02:31PM +0200, Peter Wu wrote: > On Tue, May 31, 2016 at 11:43:56AM +0300, Mika Westerberg wrote: > > On Mon, May 30, 2016 at 06:13:51PM +0200, Peter Wu wrote: > > > Do you have any suggestions for the case where the pcieport driver > > > refuses to put the bridge in D3 (because the BIOS is too old)? In that > > > case the nouveau driver needs to fallback to the DSM method (but not > > > when runtime PM is deliberately disabled by writing control=on). > > > > Do you know what Wind...