linux-kernel - Re: [PATCH] PCI: quirks: add vendor ID for AR9462 card

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]

Date:   Mon, 07 Jan 2019 15:02:11 -0800
From:   James Prestwood <james.prestwood@...ux.intel.com>
To:     Bjorn Helgaas <helgaas@...nel.org>
Cc:     linux-pci@...r.kernel.org,
        Alex Williamson <alex.williamson@...hat.com>,
        Bharat Bhushan <bharat.bhushan@....com>,
        linux-kernel@...r.kernel.org
Subject: Re: [PATCH] PCI: quirks: add vendor ID for AR9462 card

On Mon, 2019-01-07 at 16:08 -0600, Bjorn Helgaas wrote:
> [+cc Alex, Bharat, LKML]
> 
> Hi James,
> 
> Thanks for finding this issue and for the patch.
> 
> Is there any chance you have a PCIe analyzer and could investigate
> what's going on at that level?  The bus reset should be fairly
> similar
> to what happens on a cold boot, and obviously *that* works, so I
> wonder if we can figure out what the difference here is.

I don't have a PCIe analyzer (unless thats just a piece of software I
could download). Maybe I should have included a cover letter about what
exactly is happening in my testing:

I am using PCI passthough with various wireless hardware, all of which
worked fine except this Ath9k card. If I tried to pass through this
card my host machine would completely lock up/freeze when starting the
VM, and I would have to hard reboot. I asked on the linux-wireless
mailing list (since it seemed to be specific to the Ath9k card) and it
was suggested to add that line to quirks.c, which did resolve the
issue.

Beyond that, its really all I know. I am not at all knowledgeable about
how PCI actually works :) (or really what this patch is even doing).
Since it was so simple and fixed my issue I figured I should try and
upstream it.

I wish I could be of more help hardware wise. If there is anything
software wise I could run to get more info I can do that.

Thanks,
James
> 
> If this is actually broken somehow in the hardware, can you dig up a
> hardware erratum and include a URL here?
> 
> If there's any chance we could fix or work around this in the kernel,
> I'd rather do that than extend this quirk to more devices.
> 
> FWIW, here's a similar report, which hasn't been resolved yet:
> 
https://lore.kernel.org/linux-pci/20181127083454.26560-1-Bharat.Bhushan@nxp.com
> 
> On Mon, Jan 07, 2019 at 01:32:48PM -0800, James Prestwood wrote:
> > This card has similar issues with bus reset as the others present
> > in
> > this list.
> > 
> > Signed-off-by: James Prestwood <james.prestwood@...ux.intel.com>
> > ---
> >  drivers/pci/quirks.c | 1 +
> >  1 file changed, 1 insertion(+)
> > 
> > diff --git a/drivers/pci/quirks.c b/drivers/pci/quirks.c
> > index ef7143a274e0..d9d4a95b0309 100644
> > --- a/drivers/pci/quirks.c
> > +++ b/drivers/pci/quirks.c
> > @@ -3379,6 +3379,7 @@
> > DECLARE_PCI_FIXUP_HEADER(PCI_VENDOR_ID_ATHEROS, 0x0030,
> > quirk_no_bus_reset);
> >  DECLARE_PCI_FIXUP_HEADER(PCI_VENDOR_ID_ATHEROS, 0x0032,
> > quirk_no_bus_reset);
> >  DECLARE_PCI_FIXUP_HEADER(PCI_VENDOR_ID_ATHEROS, 0x003c,
> > quirk_no_bus_reset);
> >  DECLARE_PCI_FIXUP_HEADER(PCI_VENDOR_ID_ATHEROS, 0x0033,
> > quirk_no_bus_reset);
> > +DECLARE_PCI_FIXUP_HEADER(PCI_VENDOR_ID_ATHEROS, 0x0034,
> > quirk_no_bus_reset);
> >  
> >  /*
> >   * Root port on some Cavium CN8xxx chips do not successfully
> > complete a bus
> > -- 
> > 2.17.1
> >