lists.openwall.net   lists  /  announce  owl-users  owl-dev  john-users  john-dev  passwdqc-users  yescrypt  popa3d-users  /  oss-security  kernel-hardening  musl  sabotage  tlsify  passwords  /  crypt-dev  xvendor  /  Bugtraq  Full-Disclosure  linux-kernel  linux-netdev  linux-ext4  linux-hardening  linux-cve-announce  PHC 
Open Source and information security mailing list archives
 
Hash Suite: Windows password security audit tool. GUI, reports in PDF.
[<prev] [next>] [<thread-prev] [day] [month] [year] [list]
Message-ID: <alpine.DEB.2.21.2511290428340.36486@angie.orcam.me.uk>
Date: Sat, 29 Nov 2025 06:04:24 +0000 (GMT)
From: "Maciej W. Rozycki" <macro@...am.me.uk>
To: Krishna Chaitanya Chundru <krishna.chundru@....qualcomm.com>
cc: Manivannan Sadhasivam <mani@...nel.org>, Jingoo Han <jingoohan1@...il.com>, 
    Lorenzo Pieralisi <lpieralisi@...nel.org>, 
    Krzysztof WilczyƄski <kwilczynski@...nel.org>, 
    Rob Herring <robh@...nel.org>, Bjorn Helgaas <bhelgaas@...gle.com>, 
    Krzysztof Kozlowski <krzk@...nel.org>, 
    Alim Akhtar <alim.akhtar@...sung.com>, 
    Jonathan Chocron <jonnyc@...zon.com>, linux-pci@...r.kernel.org, 
    linux-arm-kernel@...ts.infradead.org, linux-samsung-soc@...r.kernel.org, 
    linux-kernel@...r.kernel.org, linux-arm-msm@...r.kernel.org
Subject: Re: [PATCH v9 4/4] PCI: dwc: Support ECAM mechanism by enabling iATU
 'CFG Shift Feature'

On Sat, 29 Nov 2025, Krishna Chaitanya Chundru wrote:

> > > Hi Maciej, Can you try attached patch and let me know if that is helping
> > > you
> > > or not. - Krishna Chaitanya.
> >   No change, it's still broken, sorry.
> HI Maciej,
> For the previous patch can you apply this diff and share me dmesg o/p

 Your patch came though garbled, likely due to:

Content-Type: text/plain; charset=UTF-8; format=flowed

Please refer Documentation/process/email-clients.rst and reconfigure your 
e-mail client if possible.

 Regardless, I've fixed it up by hand and the only difference in the log, 
except for usual noise which I removed, is this:

--- dmesg-bad.log	2025-11-28 03:47:29.582049781 +0100
+++ dmesg-debug.log	2025-11-29 05:41:23.384645926 +0100
@@ -164,6 +164,8 @@
 fu740-pcie e00000000.pcie: ECAM at [mem 0xdf0000000-0xdffffffff] for [bus 00-ff]
 fu740-pcie e00000000.pcie: Using 256 MSI vectors
 fu740-pcie e00000000.pcie: iATU: unroll T, 8 ob, 8 ib, align 4K, limit 4096G
+fu740-pcie e00000000.pcie: Current iATU OB index 2
+fu740-pcie e00000000.pcie: Current iATU OB index 4
 fu740-pcie e00000000.pcie: cap_exp at 70
 fu740-pcie e00000000.pcie: PCIe Gen.1 x8 link up
 fu740-pcie e00000000.pcie: changing speed back to original

I've attached a full copy of the debug log too.  I hope this helps you 
narrow the issue down or otherwise let me know what to try next.

 NB I note that code you've been poking at only refers resources of the 
IORESOURCE_MEM type.  What about IORESOURCE_IO, which seems more relevant 
here?

 Also as a quick check I've now reconfigured the defxx driver for PCI port 
I/O (which is a one-liner; the mapping used to be selectable by hand, but 
distributions got it wrong for systems w/o PCI port I/O, so I switched the 
driver to an automatic choice a few years ago, but the logic remains):

# cat /proc/ioports
00000000-0000ffff : pcie@...000000
  00001000-00002fff : PCI Bus 0000:01
    00001000-00002fff : PCI Bus 0000:02
      00001000-00002fff : PCI Bus 0000:05
        00001000-00002fff : PCI Bus 0000:06
          00001000-00001fff : PCI Bus 0000:07
          00001000-00001007 : 0000:07:00.0
          00001000-00001002 : parport0
          00001003-00001007 : parport0
          00001008-0000100b : 0000:07:00.0
          00001008-0000100a : parport0
          00002000-00002fff : PCI Bus 0000:08
          00002000-00002fff : PCI Bus 0000:09
          00002000-000020ff : 0000:09:01.0
          00002100-0000217f : 0000:09:02.0
          00002100-0000217f : defxx
# 

and:

defxx 0000:09:02.0: assign IRQ: got 40
defxx: v1.12 2021/03/10  Lawrence V. Stefani and others
defxx 0000:09:02.0: enabling device (0000 -> 0003)
defxx 0000:09:02.0: enabling bus mastering
0000:09:02.0: DEFPA at I/O addr = 0x2100, IRQ = 40, Hardware addr = 00-60-6d-xx-xx-xx
0000:09:02.0: registered as fddi0

(as at commit 4660e50cf818) and likewise it has stopped working here from 
commit 0da48c5b2fa7 onwards:

defxx 0000:09:02.0: assign IRQ: got 40
defxx: v1.12 2021/03/10  Lawrence V. Stefani and others
defxx 0000:09:02.0: enabling device (0000 -> 0003)
defxx 0000:09:02.0: enabling bus mastering
0000:09:02.0: Could not read adapter factory MAC address!

So it's definitely nothing specific to the parport driver, but rather a 
general issue with PCI/e port I/O not working anymore.  I do hope these 
observations will let you address the issue now.  You might be able to 
reproduce it with hardware you have available even.

  Maciej
Download attachment "dmesg-debug.log.xz" of type "application/x-xz" (8572 bytes)

Powered by blists - more mailing lists

Powered by Openwall GNU/*/Linux Powered by OpenVZ