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] [thread-next>] [day] [month] [year] [list]
Message-ID: <alpine.DEB.2.21.2107051246330.33206@angie.orcam.me.uk>
Date:   Mon, 5 Jul 2021 12:54:51 +0200 (CEST)
From:   "Maciej W. Rozycki" <macro@...am.me.uk>
To:     Nikolai Zhubr <zhubr.2@...il.com>
cc:     Bjorn Helgaas <bhelgaas@...gle.com>,
        Thomas Gleixner <tglx@...utronix.de>,
        Ingo Molnar <mingo@...hat.com>, Borislav Petkov <bp@...en8.de>,
        "H. Peter Anvin" <hpa@...or.com>, Arnd Bergmann <arnd@...nel.org>,
        x86@...nel.org, linux-pci@...r.kernel.org,
        linux-kernel@...r.kernel.org
Subject: Re: [PATCH RFC 0/2] x86/PCI: SiS PIRQ router updates

On Sat, 3 Jul 2021, Maciej W. Rozycki wrote:

> > >   Nikolai, can you please give it a hit with the extra debug patch as
> > > requested in my other message?
> > 
> > With
> > linux-x86-pirq-router-sis85c503.diff applied
> > linux-x86-pirq-router-sis85c497.diff applied
> > and DEBUG 1 in arch/x86/include/asm/pci_x86.h
> > here is new log:
> > 
> > https://pastebin.com/n3udQgcq
> > 
> > My feeling is that something went a bit wrong because:
> > 
> > 8139too 0000:00:0d.0: can't route interrupt
> 
>  More important is actually the previous line:
> 
> PCI: Attempting to find IRQ router for [0000:0000]
> 
> meaning that the PIRQ structure defined by the BIOS has not specified the 
> vendor:device ID pair for the router [1039:0496] which we match against.

 So it's actually both the vendor:device ID pair and the bus address that 
matter here.  I've now posted a patch I am fairly sure about that combined 
with the earlier changes it will fix your issue.  I have verified it in a 
simulated environment where the PIRQ routing table has an invalid vendor 
ID given, with correct results produced:

PCI: Attempting to find IRQ router for [0000:0000]
PCI: Trying IRQ router for [8086:1250]
PCI: Trying IRQ router for [8086:7000]
pci 0000:00:07.0: SIO/PIIX/ICH IRQ router [8086:7000]

 Please let me know of the outcome.

  Maciej

Powered by blists - more mailing lists

Powered by Openwall GNU/*/Linux Powered by OpenVZ