* [PATCH] Limit VPD length on Atheros wifi cards @ 2015-12-29 22:19 Jordan Hargrave 2016-01-09 0:57 ` Bjorn Helgaas 0 siblings, 1 reply; 10+ messages in thread From: Jordan Hargrave @ 2015-12-29 22:19 UTC (permalink / raw) To: bhelgaas, Jordan_Hargrave Cc: linux-pci, linux-kernel, helgaas, alexander.duyck, Jordan Hargrave Attempt to read VPD on these cards causes kernel hang or delay Signed-off-by: Jordan Hargrave <Jordan_Hargrave@dell.com> --- drivers/pci/quirks.c | 10 ++++++++++ 1 files changed, 10 insertions(+), 0 deletions(-) diff --git a/drivers/pci/quirks.c b/drivers/pci/quirks.c index e6376f6..a72667f 100644 --- a/drivers/pci/quirks.c +++ b/drivers/pci/quirks.c @@ -2161,6 +2161,16 @@ static void quirk_brcm_570x_limit_vpd(struct pci_dev *dev) } } +static void quirk_atheros_vpd(struct pci_dev *dev) +{ + /* Atheros WiFi cards hang when reading VPD */ + if (dev->vpd) + dev->vpd->len = 0; +} + +DECLARE_PCI_FIXUP_FINAL(PCI_VENDOR_ID_ATHEROS, PCI_ANY_ID, quirk_atheros_vpd); +DECLARE_PCI_FIXUP_FINAL(PCI_VENDOR_ID_ATTANSIC, PCI_ANY_ID, quirk_atheros_vpd); + DECLARE_PCI_FIXUP_FINAL(PCI_VENDOR_ID_BROADCOM, PCI_DEVICE_ID_NX2_5706, quirk_brcm_570x_limit_vpd); -- 1.7.1 ^ permalink raw reply related [flat|nested] 10+ messages in thread
* Re: [PATCH] Limit VPD length on Atheros wifi cards 2015-12-29 22:19 [PATCH] Limit VPD length on Atheros wifi cards Jordan Hargrave @ 2016-01-09 0:57 ` Bjorn Helgaas 2016-01-09 1:05 ` Bjorn Helgaas 0 siblings, 1 reply; 10+ messages in thread From: Bjorn Helgaas @ 2016-01-09 0:57 UTC (permalink / raw) To: Jordan Hargrave Cc: bhelgaas, linux-pci, linux-kernel, alexander.duyck, Babu Moger [+cc Babu] Hi Jordan, Babu, et al, On Tue, Dec 29, 2015 at 04:19:02PM -0600, Jordan Hargrave wrote: > Attempt to read VPD on these cards causes kernel hang or delay > > Signed-off-by: Jordan Hargrave <Jordan_Hargrave@dell.com> > --- > drivers/pci/quirks.c | 10 ++++++++++ > 1 files changed, 10 insertions(+), 0 deletions(-) > > diff --git a/drivers/pci/quirks.c b/drivers/pci/quirks.c > index e6376f6..a72667f 100644 > --- a/drivers/pci/quirks.c > +++ b/drivers/pci/quirks.c > @@ -2161,6 +2161,16 @@ static void quirk_brcm_570x_limit_vpd(struct pci_dev *dev) > } > } > > +static void quirk_atheros_vpd(struct pci_dev *dev) > +{ > + /* Atheros WiFi cards hang when reading VPD */ > + if (dev->vpd) > + dev->vpd->len = 0; > +} > + > +DECLARE_PCI_FIXUP_FINAL(PCI_VENDOR_ID_ATHEROS, PCI_ANY_ID, quirk_atheros_vpd); > +DECLARE_PCI_FIXUP_FINAL(PCI_VENDOR_ID_ATTANSIC, PCI_ANY_ID, quirk_atheros_vpd); We're accumulating several quirks like this, and they don't do anything device-specific, so we could probably use a single quirk for all of them, i.e., Babu's quirk_megaraid_sas_limit_vpd() and your quirk_atheros_vpd() are needlessly duplicated. I'd really like to have more details about what the "kernel hang or delay" that happens when we try to read VPD. Looking at pci_vpd_pci22_read(), it basically just does config accesses, so I only see two ways things could go wrong: 1) If the device responds with data, but the PCI_VPD_ADDR_F flag isn't set, we should be able to timeout gracefully. 2) If the device doesn't respond at all, we could see machine checks, master aborts, processor read timeouts, or similar hardware problems. If there are other failure modes, I'd like to learn what they are. If we're seeing problems like (1), there must be something we can improve in the way we handle timeouts. If we're seeing failures like (2), they're probably caused by a hardware or firmware problem on the device, and there's not much we can do in the kernel, so disabling VPD access completely is probably all we can do. So if/when we add quirks like this, I'm looking for bugzilla entries that clearly show that the problem is (2). I'd also like to log something in dmesg as a clue about why lspci or other utilities don't find any VPD data. Bjorn > DECLARE_PCI_FIXUP_FINAL(PCI_VENDOR_ID_BROADCOM, > PCI_DEVICE_ID_NX2_5706, > quirk_brcm_570x_limit_vpd); > -- > 1.7.1 > > -- > To unsubscribe from this list: send the line "unsubscribe linux-pci" in > the body of a message to majordomo@vger.kernel.org > More majordomo info at http://vger.kernel.org/majordomo-info.html ^ permalink raw reply [flat|nested] 10+ messages in thread
* Re: [PATCH] Limit VPD length on Atheros wifi cards 2016-01-09 0:57 ` Bjorn Helgaas @ 2016-01-09 1:05 ` Bjorn Helgaas 2016-01-09 23:15 ` Babu Moger 2016-01-11 21:13 ` [PATCH RFC] pci: Blacklist vpd access for buggy devices Babu Moger 0 siblings, 2 replies; 10+ messages in thread From: Bjorn Helgaas @ 2016-01-09 1:05 UTC (permalink / raw) To: Jordan Hargrave Cc: bhelgaas, linux-pci, linux-kernel, alexander.duyck, Babu Moger, Hannes Reinecke, Michal Kubecek, Shane M. Seymour, Myron Stowe, Venkat Duvvuru [+cc Hannes, Michal, Shane, Myron, Venkat; sorry I missed you guys the first time around] On Fri, Jan 08, 2016 at 06:57:36PM -0600, Bjorn Helgaas wrote: > [+cc Babu] > > Hi Jordan, Babu, et al, > > On Tue, Dec 29, 2015 at 04:19:02PM -0600, Jordan Hargrave wrote: > > Attempt to read VPD on these cards causes kernel hang or delay > > > > Signed-off-by: Jordan Hargrave <Jordan_Hargrave@dell.com> > > --- > > drivers/pci/quirks.c | 10 ++++++++++ > > 1 files changed, 10 insertions(+), 0 deletions(-) > > > > diff --git a/drivers/pci/quirks.c b/drivers/pci/quirks.c > > index e6376f6..a72667f 100644 > > --- a/drivers/pci/quirks.c > > +++ b/drivers/pci/quirks.c > > @@ -2161,6 +2161,16 @@ static void quirk_brcm_570x_limit_vpd(struct pci_dev *dev) > > } > > } > > > > +static void quirk_atheros_vpd(struct pci_dev *dev) > > +{ > > + /* Atheros WiFi cards hang when reading VPD */ > > + if (dev->vpd) > > + dev->vpd->len = 0; > > +} > > + > > +DECLARE_PCI_FIXUP_FINAL(PCI_VENDOR_ID_ATHEROS, PCI_ANY_ID, quirk_atheros_vpd); > > +DECLARE_PCI_FIXUP_FINAL(PCI_VENDOR_ID_ATTANSIC, PCI_ANY_ID, quirk_atheros_vpd); > > We're accumulating several quirks like this, and they don't do > anything device-specific, so we could probably use a single quirk for > all of them, i.e., Babu's quirk_megaraid_sas_limit_vpd() and your > quirk_atheros_vpd() are needlessly duplicated. > > I'd really like to have more details about what the "kernel hang or > delay" that happens when we try to read VPD. > > Looking at pci_vpd_pci22_read(), it basically just does config > accesses, so I only see two ways things could go wrong: > > 1) If the device responds with data, but the PCI_VPD_ADDR_F flag > isn't set, we should be able to timeout gracefully. > > 2) If the device doesn't respond at all, we could see machine > checks, master aborts, processor read timeouts, or similar hardware > problems. > > If there are other failure modes, I'd like to learn what they are. > > If we're seeing problems like (1), there must be something we can > improve in the way we handle timeouts. > > If we're seeing failures like (2), they're probably caused by a > hardware or firmware problem on the device, and there's not much we > can do in the kernel, so disabling VPD access completely is probably > all we can do. > > So if/when we add quirks like this, I'm looking for bugzilla entries > that clearly show that the problem is (2). I'd also like to log > something in dmesg as a clue about why lspci or other utilities don't > find any VPD data. > > Bjorn > > > DECLARE_PCI_FIXUP_FINAL(PCI_VENDOR_ID_BROADCOM, > > PCI_DEVICE_ID_NX2_5706, > > quirk_brcm_570x_limit_vpd); ^ permalink raw reply [flat|nested] 10+ messages in thread
* Re: [PATCH] Limit VPD length on Atheros wifi cards 2016-01-09 1:05 ` Bjorn Helgaas @ 2016-01-09 23:15 ` Babu Moger 2016-01-11 21:13 ` [PATCH RFC] pci: Blacklist vpd access for buggy devices Babu Moger 1 sibling, 0 replies; 10+ messages in thread From: Babu Moger @ 2016-01-09 23:15 UTC (permalink / raw) To: Bjorn Helgaas, Jordan Hargrave Cc: bhelgaas, linux-pci, linux-kernel, alexander.duyck, Hannes Reinecke, Michal Kubecek, Shane M. Seymour, Myron Stowe, Venkat Duvvuru Thanks for bringing this topic up. On 1/8/2016 7:05 PM, Bjorn Helgaas wrote: > [+cc Hannes, Michal, Shane, Myron, Venkat; sorry I missed you guys the > first time around] > > On Fri, Jan 08, 2016 at 06:57:36PM -0600, Bjorn Helgaas wrote: >> [+cc Babu] >> >> Hi Jordan, Babu, et al, >> >> On Tue, Dec 29, 2015 at 04:19:02PM -0600, Jordan Hargrave wrote: >>> Attempt to read VPD on these cards causes kernel hang or delay >>> >>> Signed-off-by: Jordan Hargrave <Jordan_Hargrave@dell.com> >>> --- >>> drivers/pci/quirks.c | 10 ++++++++++ >>> 1 files changed, 10 insertions(+), 0 deletions(-) >>> >>> diff --git a/drivers/pci/quirks.c b/drivers/pci/quirks.c >>> index e6376f6..a72667f 100644 >>> --- a/drivers/pci/quirks.c >>> +++ b/drivers/pci/quirks.c >>> @@ -2161,6 +2161,16 @@ static void quirk_brcm_570x_limit_vpd(struct pci_dev *dev) >>> } >>> } >>> >>> +static void quirk_atheros_vpd(struct pci_dev *dev) >>> +{ >>> + /* Atheros WiFi cards hang when reading VPD */ >>> + if (dev->vpd) >>> + dev->vpd->len = 0; >>> +} >>> + >>> +DECLARE_PCI_FIXUP_FINAL(PCI_VENDOR_ID_ATHEROS, PCI_ANY_ID, quirk_atheros_vpd); >>> +DECLARE_PCI_FIXUP_FINAL(PCI_VENDOR_ID_ATTANSIC, PCI_ANY_ID, quirk_atheros_vpd); >> >> We're accumulating several quirks like this, and they don't do >> anything device-specific, so we could probably use a single quirk for >> all of them, i.e., Babu's quirk_megaraid_sas_limit_vpd() and your >> quirk_atheros_vpd() are needlessly duplicated. >> >> I'd really like to have more details about what the "kernel hang or >> delay" that happens when we try to read VPD. >> >> Looking at pci_vpd_pci22_read(), it basically just does config >> accesses, so I only see two ways things could go wrong: >> >> 1) If the device responds with data, but the PCI_VPD_ADDR_F flag >> isn't set, we should be able to timeout gracefully. >> >> 2) If the device doesn't respond at all, we could see machine >> checks, master aborts, processor read timeouts, or similar hardware >> problems. I think I saw the the second problem. It appears to respond ok when the length is smaller(i tried 0x80). Problem with that is, lspci reports error when it cannot find start/end tags. I saw all the data as 00. I think Myron saw everything 00 and 0xFF sometimes. When I increase the length, kernel hangs and panics at some unknown location. Looking at the crash I saw this stack(it did not panic at this location though) PID: 5274 TASK: ffff800fe1198680 CPU: 0 COMMAND: "cat" #0 [ffff800fe25f6f81] switch_to_pc at 8d725c #1 [ffff800fe25f70e1] pci_user_read_config_word at 6c4698 #2 [ffff800fe25f71a1] pci_vpd_pci22_wait at 6c4710 #3 [ffff800fe25f7261] pci_vpd_pci22_read at 6c4994 #4 [ffff800fe25f7321] pci_read_vpd at 6c3e90 #5 [ffff800fe25f73d1] read_vpd_attr at 6ccc78 #6 [ffff800fe25f7481] read at 5be478 #7 [ffff800fe25f7531] vfs_read at 54fdb0 #8 [ffff800fe25f75e1] sys_read at 54ff10 #9 [ffff800fe25f76a1] linux_sparc_syscall at 4060f4 TSTATE=0x8082000223 TT=0x16d TPC=0xfffffc0100295e28 TNPC=0xfffffc0100295e2c r0=0x0000000000000000 r1=0x0000000000000003 r2=0x000000000020aec0 r3=0x000000000020aec4 r4=0x000000000b000000 r5=0x00000000033fffff r6=0x0000000000000001 r7=0xfffffc01000006f0 r24=0x0000000000000003 r25=0x000000000020e000 r26=0x0000000000008000 r27=0x0000000000000000 r28=0x0000000000000000 r29=0x0000000000000000 r30=0x000007feffb468d1 >> >> If there are other failure modes, I'd like to learn what they are. >> >> If we're seeing problems like (1), there must be something we can >> improve in the way we handle timeouts. >> >> If we're seeing failures like (2), they're probably caused by a >> hardware or firmware problem on the device, and there's not much we >> can do in the kernel, so disabling VPD access completely is probably >> all we can do. >> >> So if/when we add quirks like this, I'm looking for bugzilla entries >> that clearly show that the problem is (2). I'd also like to log >> something in dmesg as a clue about why lspci or other utilities don't >> find any VPD data. Sure. I can open a bugzilla on Monday with more details. I like the idea of having a one solution to cover all these cases. I can post a RFC patch with one function to cover all these buggy adapters. Please let me know. >> >> Bjorn >> >>> DECLARE_PCI_FIXUP_FINAL(PCI_VENDOR_ID_BROADCOM, >>> PCI_DEVICE_ID_NX2_5706, >>> quirk_brcm_570x_limit_vpd); ^ permalink raw reply [flat|nested] 10+ messages in thread
* [PATCH RFC] pci: Blacklist vpd access for buggy devices 2016-01-09 1:05 ` Bjorn Helgaas 2016-01-09 23:15 ` Babu Moger @ 2016-01-11 21:13 ` Babu Moger 2016-01-11 22:49 ` Babu Moger 1 sibling, 1 reply; 10+ messages in thread From: Babu Moger @ 2016-01-11 21:13 UTC (permalink / raw) To: bhelgaas Cc: linux-pci, linux-kernel, alexander.duyck, babu.moger, hare, mkubecek, shane.seymour, myron.stowe, VenkatKumar.Duvvuru Reading or Writing of PCI VPD data causes system panic. We saw this problem by running "lspci -vvv" in the beginning. However this can be easily reproduced by running cat /sys/bus/devices/XX../vpd VPD length has been set as 32768 by default. Accessing vpd will trigger read/write of 32k. This causes problem as we could read data beyond the VPD end tag. Behaviour is un- predictable when this happens. I see some other adapter doing similar quirks(commit bffadffd43d4 ("PCI: fix VPD limit quirk for Broadcom 5708S")) I see there is an attempt to fix this right way. https://patchwork.ozlabs.org/patch/534843/ or https://lkml.org/lkml/2015/10/23/97 Tried to fix it this way, but problem is I dont see the proper start/end TAGs(at least for this adapter) at all. The data is mostly junk or zeros. This patch fixes the issue by setting the vpd length to 0x80. Also look at the threds https://lkml.org/lkml/2015/11/10/557 https://lkml.org/lkml/2015/12/29/315 Signed-off-by: Babu Moger <babu.moger@oracle.com> --- NOTE: Jordan, Are you sure all the devices in PCI_VENDOR_ID_ATHEROS and PCI_VENDOR_ID_ATTANSIC have this problem. You have used PCI_ANY_ID. I felt it is too broad. Can you please check. drivers/pci/quirks.c | 41 +++++++++++++++++++++++++++++++++++++++++ 1 files changed, 41 insertions(+), 0 deletions(-) diff --git a/drivers/pci/quirks.c b/drivers/pci/quirks.c index b03373f..8abcee5 100644 --- a/drivers/pci/quirks.c +++ b/drivers/pci/quirks.c @@ -2123,6 +2123,47 @@ static void quirk_via_cx700_pci_parking_caching(struct pci_dev *dev) DECLARE_PCI_FIXUP_FINAL(PCI_VENDOR_ID_VIA, 0x324e, quirk_via_cx700_pci_parking_caching); /* + * A read/write to sysfs entry ('/sys/bus/pci/devices/<id>/vpd') + * will dump 32k of data. The default length is set as 32768. + * Reading a full 32k will cause an access beyond the VPD end tag. + * The system behaviour at that point is mostly unpredictable. + * Apparently, some vendors have not implemented this VPD headers properly. + * Adding a generic function disable vpd data for these buggy adapters + * Add the DECLARE_PCI_FIXUP_FINAL line below with the specific with + * vendor and device of interest to use this quirk. + */ +static void quirk_blacklist_vpd(struct pci_dev *dev) +{ + if (dev->vpd) { + dev->vpd->len = 0; + dev_warn(&dev->dev, "PCI vpd access has been disabled due to firmware bug\n"); + } +} + +DECLARE_PCI_FIXUP_FINAL(PCI_VENDOR_ID_LSI_LOGIC, 0x0060, + quirk_blacklist_vpd); +DECLARE_PCI_FIXUP_FINAL(PCI_VENDOR_ID_LSI_LOGIC, 0x007c, + quirk_blacklist_vpd); +DECLARE_PCI_FIXUP_FINAL(PCI_VENDOR_ID_LSI_LOGIC, 0x0413, + quirk_blacklist_vpd); +DECLARE_PCI_FIXUP_FINAL(PCI_VENDOR_ID_LSI_LOGIC, 0x0078, + quirk_blacklist_vpd); +DECLARE_PCI_FIXUP_FINAL(PCI_VENDOR_ID_LSI_LOGIC, 0x0079, + quirk_blacklist_vpd); +DECLARE_PCI_FIXUP_FINAL(PCI_VENDOR_ID_LSI_LOGIC, 0x0073, + quirk_blacklist_vpd); +DECLARE_PCI_FIXUP_FINAL(PCI_VENDOR_ID_LSI_LOGIC, 0x0071, + quirk_blacklist_vpd); +DECLARE_PCI_FIXUP_FINAL(PCI_VENDOR_ID_LSI_LOGIC, 0x005b, + quirk_blacklist_vpd); +DECLARE_PCI_FIXUP_FINAL(PCI_VENDOR_ID_LSI_LOGIC, 0x002f, + quirk_blacklist_vpd); +DECLARE_PCI_FIXUP_FINAL(PCI_VENDOR_ID_LSI_LOGIC, 0x005d, + quirk_blacklist_vpd); +DECLARE_PCI_FIXUP_FINAL(PCI_VENDOR_ID_LSI_LOGIC, 0x005f, + quirk_blacklist_vpd); + +/* * For Broadcom 5706, 5708, 5709 rev. A nics, any read beyond the * VPD end tag will hang the device. This problem was initially * observed when a vpd entry was created in sysfs -- 1.7.1 ^ permalink raw reply related [flat|nested] 10+ messages in thread
* Re: [PATCH RFC] pci: Blacklist vpd access for buggy devices 2016-01-11 21:13 ` [PATCH RFC] pci: Blacklist vpd access for buggy devices Babu Moger @ 2016-01-11 22:49 ` Babu Moger 2016-01-19 15:22 ` Jordan_Hargrave 0 siblings, 1 reply; 10+ messages in thread From: Babu Moger @ 2016-01-11 22:49 UTC (permalink / raw) To: bhelgaas Cc: linux-pci, linux-kernel, alexander.duyck, hare, mkubecek, shane.seymour, myron.stowe, VenkatKumar.Duvvuru, Jordan Hargrave Sorry. Missed Jordan. On 1/11/2016 3:13 PM, Babu Moger wrote: > Reading or Writing of PCI VPD data causes system panic. > We saw this problem by running "lspci -vvv" in the beginning. > However this can be easily reproduced by running > cat /sys/bus/devices/XX../vpd > > VPD length has been set as 32768 by default. Accessing vpd > will trigger read/write of 32k. This causes problem as we > could read data beyond the VPD end tag. Behaviour is un- > predictable when this happens. I see some other adapter doing > similar quirks(commit bffadffd43d4 ("PCI: fix VPD limit quirk > for Broadcom 5708S")) > > I see there is an attempt to fix this right way. > https://patchwork.ozlabs.org/patch/534843/ or > https://lkml.org/lkml/2015/10/23/97 > > Tried to fix it this way, but problem is I dont see the proper > start/end TAGs(at least for this adapter) at all. The data is > mostly junk or zeros. This patch fixes the issue by setting the > vpd length to 0x80. > > Also look at the threds > > https://lkml.org/lkml/2015/11/10/557 > https://lkml.org/lkml/2015/12/29/315 > > Signed-off-by: Babu Moger <babu.moger@oracle.com> > --- > > NOTE: > Jordan, Are you sure all the devices in PCI_VENDOR_ID_ATHEROS and > PCI_VENDOR_ID_ATTANSIC have this problem. You have used PCI_ANY_ID. > I felt it is too broad. Can you please check. > > > drivers/pci/quirks.c | 41 +++++++++++++++++++++++++++++++++++++++++ > 1 files changed, 41 insertions(+), 0 deletions(-) > > diff --git a/drivers/pci/quirks.c b/drivers/pci/quirks.c > index b03373f..8abcee5 100644 > --- a/drivers/pci/quirks.c > +++ b/drivers/pci/quirks.c > @@ -2123,6 +2123,47 @@ static void quirk_via_cx700_pci_parking_caching(struct pci_dev *dev) > DECLARE_PCI_FIXUP_FINAL(PCI_VENDOR_ID_VIA, 0x324e, quirk_via_cx700_pci_parking_caching); > > /* > + * A read/write to sysfs entry ('/sys/bus/pci/devices/<id>/vpd') > + * will dump 32k of data. The default length is set as 32768. > + * Reading a full 32k will cause an access beyond the VPD end tag. > + * The system behaviour at that point is mostly unpredictable. > + * Apparently, some vendors have not implemented this VPD headers properly. > + * Adding a generic function disable vpd data for these buggy adapters > + * Add the DECLARE_PCI_FIXUP_FINAL line below with the specific with > + * vendor and device of interest to use this quirk. > + */ > +static void quirk_blacklist_vpd(struct pci_dev *dev) > +{ > + if (dev->vpd) { > + dev->vpd->len = 0; > + dev_warn(&dev->dev, "PCI vpd access has been disabled due to firmware bug\n"); > + } > +} > + > +DECLARE_PCI_FIXUP_FINAL(PCI_VENDOR_ID_LSI_LOGIC, 0x0060, > + quirk_blacklist_vpd); > +DECLARE_PCI_FIXUP_FINAL(PCI_VENDOR_ID_LSI_LOGIC, 0x007c, > + quirk_blacklist_vpd); > +DECLARE_PCI_FIXUP_FINAL(PCI_VENDOR_ID_LSI_LOGIC, 0x0413, > + quirk_blacklist_vpd); > +DECLARE_PCI_FIXUP_FINAL(PCI_VENDOR_ID_LSI_LOGIC, 0x0078, > + quirk_blacklist_vpd); > +DECLARE_PCI_FIXUP_FINAL(PCI_VENDOR_ID_LSI_LOGIC, 0x0079, > + quirk_blacklist_vpd); > +DECLARE_PCI_FIXUP_FINAL(PCI_VENDOR_ID_LSI_LOGIC, 0x0073, > + quirk_blacklist_vpd); > +DECLARE_PCI_FIXUP_FINAL(PCI_VENDOR_ID_LSI_LOGIC, 0x0071, > + quirk_blacklist_vpd); > +DECLARE_PCI_FIXUP_FINAL(PCI_VENDOR_ID_LSI_LOGIC, 0x005b, > + quirk_blacklist_vpd); > +DECLARE_PCI_FIXUP_FINAL(PCI_VENDOR_ID_LSI_LOGIC, 0x002f, > + quirk_blacklist_vpd); > +DECLARE_PCI_FIXUP_FINAL(PCI_VENDOR_ID_LSI_LOGIC, 0x005d, > + quirk_blacklist_vpd); > +DECLARE_PCI_FIXUP_FINAL(PCI_VENDOR_ID_LSI_LOGIC, 0x005f, > + quirk_blacklist_vpd); > + > +/* > * For Broadcom 5706, 5708, 5709 rev. A nics, any read beyond the > * VPD end tag will hang the device. This problem was initially > * observed when a vpd entry was created in sysfs > ^ permalink raw reply [flat|nested] 10+ messages in thread
* RE: [PATCH RFC] pci: Blacklist vpd access for buggy devices 2016-01-11 22:49 ` Babu Moger @ 2016-01-19 15:22 ` Jordan_Hargrave 2016-01-19 20:39 ` Babu Moger 0 siblings, 1 reply; 10+ messages in thread From: Jordan_Hargrave @ 2016-01-19 15:22 UTC (permalink / raw) To: babu.moger, bhelgaas Cc: linux-pci, linux-kernel, alexander.duyck, hare, mkubecek, shane.seymour, myron.stowe, VenkatKumar.Duvvuru From: Babu Moger [babu.moger@oracle.com] Sent: Monday, January 11, 2016 4:49 PM To: bhelgaas@google.com Cc: linux-pci@vger.kernel.org; linux-kernel@vger.kernel.org; alexander.duyck@gmail.com; hare@suse.de; mkubecek@suse.com; shane.seymour@hpe.com; myron.stowe@gmail.com; VenkatKumar.Duvvuru@avago.com; Hargrave, Jordan Subject: Re: [PATCH RFC] pci: Blacklist vpd access for buggy devices Sorry. Missed Jordan. On 1/11/2016 3:13 PM, Babu Moger wrote: > Reading or Writing of PCI VPD data causes system panic. > We saw this problem by running "lspci -vvv" in the beginning. > However this can be easily reproduced by running > cat /sys/bus/devices/XX../vpd > > VPD length has been set as 32768 by default. Accessing vpd > will trigger read/write of 32k. This causes problem as we > could read data beyond the VPD end tag. Behaviour is un- > predictable when this happens. I see some other adapter doing > similar quirks(commit bffadffd43d4 ("PCI: fix VPD limit quirk > for Broadcom 5708S")) > > I see there is an attempt to fix this right way. > https://patchwork.ozlabs.org/patch/534843/ or > https://lkml.org/lkml/2015/10/23/97 > > Tried to fix it this way, but problem is I dont see the proper > start/end TAGs(at least for this adapter) at all. The data is > mostly junk or zeros. This patch fixes the issue by setting the > vpd length to 0x80. > > Also look at the threds > > https://lkml.org/lkml/2015/11/10/557 > https://lkml.org/lkml/2015/12/29/315 > > Signed-off-by: Babu Moger <babu.moger@oracle.com> > --- > > NOTE: > Jordan, Are you sure all the devices in PCI_VENDOR_ID_ATHEROS and > PCI_VENDOR_ID_ATTANSIC have this problem. You have used PCI_ANY_ID. > I felt it is too broad. Can you please check. > I don't actually have that hardware, it was a bugfix for biosdevname for RedHat. We were getting 'BUG: soft lockup - CPU#0 stuck for 23s!' when attempting to read the vpd area. Certainly 0x1969:0x1026 experienced this. 09:00.0 Ethernet controller: Atheros Communications AR8121/AR8113/AR8114 Gigabit or Fast Ethernet (rev b0) Subsystem: Atheros Communications AR8121/AR8113/AR8114 Gigabit or Fast Ethernet Control: I/O+ Mem+ BusMaster+ SpecCycle- MemWINV- VGASnoop- ParErr- Stepping- SERR- FastB2B- DisINTx+ Status: Cap+ 66MHz- UDF- FastB2B- ParErr- DEVSEL=fast >TAbort- <TAbort- <MAbort- >SERR- <PERR- INTx- Latency: 0, Cache Line Size: 64 bytes Interrupt: pin A routed to IRQ 46 Region 0: Memory at c0300000 (64-bit, non-prefetchable) [size=256K] Region 2: I/O ports at 3000 [size=128] Capabilities: [40] Power Management version 2 Flags: PMEClk- DSI- D1- D2- AuxCurrent=0mA PME(D0-,D1-,D2-,D3hot+,D3cold+) Status: D0 NoSoftRst- PME-Enable- DSel=0 DScale=0 PME- Capabilities: [48] MSI: Enable+ Count=1/1 Maskable- 64bit+ Address: 00000000fee0300c Data: 41a1 Capabilities: [58] Express (v1) Endpoint, MSI 00 DevCap: MaxPayload 4096 bytes, PhantFunc 0, Latency L0s <4us, L1 unlimited ExtTag- AttnBtn+ AttnInd+ PwrInd+ RBE- FLReset- DevCtl: Report errors: Correctable- Non-Fatal- Fatal- Unsupported- RlxdOrd- ExtTag- PhantFunc- AuxPwr- NoSnoop- MaxPayload 128 bytes, MaxReadReq 512 bytes DevSta: CorrErr- UncorrErr+ FatalErr- UnsuppReq+ AuxPwr+ TransPend- LnkCap: Port #0, Speed 2.5GT/s, Width x1, ASPM L0s, Latency L0 unlimited, L1 unlimited ClockPM- Surprise- LLActRep- BwNot- LnkCtl: ASPM Disabled; RCB 64 bytes Disabled- Retrain- CommClk+ ExtSynch- ClockPM- AutWidDis- BWInt- AutBWInt- LnkSta: Speed 2.5GT/s, Width x1, TrErr- Train- SlotClk+ DLActive- BWMgmt- ABWMgmt- Capabilities: [6c] Vital Product Data Unknown small resource type 0b, will not decode more. Capabilities: [100 v1] Advanced Error Reporting UESta: DLP- SDES- TLP- FCP- CmpltTO- CmpltAbrt- UnxCmplt- RxOF- MalfTLP- ECRC- UnsupReq+ ACSViol- UEMsk: DLP- SDES- TLP- FCP- CmpltTO- CmpltAbrt- UnxCmplt- RxOF- MalfTLP- ECRC- UnsupReq- ACSViol- UESvrt: DLP+ SDES- TLP- FCP+ CmpltTO- CmpltAbrt- UnxCmplt- RxOF+ MalfTLP+ ECRC- UnsupReq- ACSViol- CESta: RxErr- BadTLP- BadDLLP- Rollover- Timeout- NonFatalErr- CEMsk: RxErr- BadTLP- BadDLLP- Rollover- Timeout- NonFatalErr- AERCap: First Error Pointer: 14, GenCap+ CGenEn- ChkCap+ ChkEn- Capabilities: [180 v1] Device Serial Number ff-2e-05-c3-00-23-8b-ff Kernel driver in use: ATL1E 00: 69 19 26 10 07 04 10 00 b0 00 00 02 10 00 00 00 10: 04 00 30 c0 00 00 00 00 01 30 00 00 00 00 00 00 20: 00 00 00 00 00 00 00 00 00 00 00 00 69 19 26 10 30: 00 00 00 00 40 00 00 00 00 00 00 00 0a 01 00 00 40: 01 48 02 c0 00 00 00 00 05 58 81 00 0c 30 e0 fe 50: 00 00 00 00 a1 41 00 00 10 6c 01 00 85 7f 04 05 60: 00 20 1a 00 11 f4 03 00 40 00 11 10 03 00 00 80 70: 5a ff 88 14 00 00 00 00 00 00 00 00 00 00 00 00 80: 00 00 00 00 69 19 26 10 00 00 00 00 00 00 00 00 90: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 a0: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 b0: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 c0: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 d0: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 e0: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 f0: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 > drivers/pci/quirks.c | 41 +++++++++++++++++++++++++++++++++++++++++ > 1 files changed, 41 insertions(+), 0 deletions(-) > > diff --git a/drivers/pci/quirks.c b/drivers/pci/quirks.c > index b03373f..8abcee5 100644 > --- a/drivers/pci/quirks.c > +++ b/drivers/pci/quirks.c > @@ -2123,6 +2123,47 @@ static void quirk_via_cx700_pci_parking_caching(struct pci_dev *dev) > DECLARE_PCI_FIXUP_FINAL(PCI_VENDOR_ID_VIA, 0x324e, quirk_via_cx700_pci_parking_caching); > > /* > + * A read/write to sysfs entry ('/sys/bus/pci/devices/<id>/vpd') > + * will dump 32k of data. The default length is set as 32768. > + * Reading a full 32k will cause an access beyond the VPD end tag. > + * The system behaviour at that point is mostly unpredictable. > + * Apparently, some vendors have not implemented this VPD headers properly. > + * Adding a generic function disable vpd data for these buggy adapters > + * Add the DECLARE_PCI_FIXUP_FINAL line below with the specific with > + * vendor and device of interest to use this quirk. > + */ > +static void quirk_blacklist_vpd(struct pci_dev *dev) > +{ > + if (dev->vpd) { > + dev->vpd->len = 0; > + dev_warn(&dev->dev, "PCI vpd access has been disabled due to firmware bug\n"); > + } > +} > + > +DECLARE_PCI_FIXUP_FINAL(PCI_VENDOR_ID_LSI_LOGIC, 0x0060, > + quirk_blacklist_vpd); > +DECLARE_PCI_FIXUP_FINAL(PCI_VENDOR_ID_LSI_LOGIC, 0x007c, > + quirk_blacklist_vpd); > +DECLARE_PCI_FIXUP_FINAL(PCI_VENDOR_ID_LSI_LOGIC, 0x0413, > + quirk_blacklist_vpd); > +DECLARE_PCI_FIXUP_FINAL(PCI_VENDOR_ID_LSI_LOGIC, 0x0078, > + quirk_blacklist_vpd); > +DECLARE_PCI_FIXUP_FINAL(PCI_VENDOR_ID_LSI_LOGIC, 0x0079, > + quirk_blacklist_vpd); > +DECLARE_PCI_FIXUP_FINAL(PCI_VENDOR_ID_LSI_LOGIC, 0x0073, > + quirk_blacklist_vpd); > +DECLARE_PCI_FIXUP_FINAL(PCI_VENDOR_ID_LSI_LOGIC, 0x0071, > + quirk_blacklist_vpd); > +DECLARE_PCI_FIXUP_FINAL(PCI_VENDOR_ID_LSI_LOGIC, 0x005b, > + quirk_blacklist_vpd); > +DECLARE_PCI_FIXUP_FINAL(PCI_VENDOR_ID_LSI_LOGIC, 0x002f, > + quirk_blacklist_vpd); > +DECLARE_PCI_FIXUP_FINAL(PCI_VENDOR_ID_LSI_LOGIC, 0x005d, > + quirk_blacklist_vpd); > +DECLARE_PCI_FIXUP_FINAL(PCI_VENDOR_ID_LSI_LOGIC, 0x005f, > + quirk_blacklist_vpd); > + > +/* > * For Broadcom 5706, 5708, 5709 rev. A nics, any read beyond the > * VPD end tag will hang the device. This problem was initially > * observed when a vpd entry was created in sysfs > ^ permalink raw reply [flat|nested] 10+ messages in thread
* Re: [PATCH RFC] pci: Blacklist vpd access for buggy devices 2016-01-19 15:22 ` Jordan_Hargrave @ 2016-01-19 20:39 ` Babu Moger 2016-01-21 15:47 ` Jordan_Hargrave 0 siblings, 1 reply; 10+ messages in thread From: Babu Moger @ 2016-01-19 20:39 UTC (permalink / raw) To: Jordan_Hargrave, bhelgaas Cc: linux-pci, linux-kernel, alexander.duyck, hare, mkubecek, shane.seymour, myron.stowe Hi Jordan, On 1/19/2016 9:22 AM, Jordan_Hargrave@dell.com wrote: > From: Babu Moger [babu.moger@oracle.com] > Sent: Monday, January 11, 2016 4:49 PM > To: bhelgaas@google.com > Cc: linux-pci@vger.kernel.org; linux-kernel@vger.kernel.org; alexander.duyck@gmail.com; hare@suse.de; mkubecek@suse.com; shane.seymour@hpe.com; myron.stowe@gmail.com; VenkatKumar.Duvvuru@avago.com; Hargrave, Jordan > Subject: Re: [PATCH RFC] pci: Blacklist vpd access for buggy devices > > Sorry. Missed Jordan. > > On 1/11/2016 3:13 PM, Babu Moger wrote: >> Reading or Writing of PCI VPD data causes system panic. >> We saw this problem by running "lspci -vvv" in the beginning. >> However this can be easily reproduced by running >> cat /sys/bus/devices/XX../vpd >> >> VPD length has been set as 32768 by default. Accessing vpd >> will trigger read/write of 32k. This causes problem as we >> could read data beyond the VPD end tag. Behaviour is un- >> predictable when this happens. I see some other adapter doing >> similar quirks(commit bffadffd43d4 ("PCI: fix VPD limit quirk >> for Broadcom 5708S")) >> >> I see there is an attempt to fix this right way. >> https://patchwork.ozlabs.org/patch/534843/ or >> https://lkml.org/lkml/2015/10/23/97 >> >> Tried to fix it this way, but problem is I dont see the proper >> start/end TAGs(at least for this adapter) at all. The data is >> mostly junk or zeros. This patch fixes the issue by setting the >> vpd length to 0x80. >> >> Also look at the threds >> >> https://lkml.org/lkml/2015/11/10/557 >> https://lkml.org/lkml/2015/12/29/315 >> >> Signed-off-by: Babu Moger <babu.moger@oracle.com> >> --- >> >> NOTE: >> Jordan, Are you sure all the devices in PCI_VENDOR_ID_ATHEROS and >> PCI_VENDOR_ID_ATTANSIC have this problem. You have used PCI_ANY_ID. >> I felt it is too broad. Can you please check. >> > > I don't actually have that hardware, it was a bugfix for biosdevname for RedHat. We were getting > 'BUG: soft lockup - CPU#0 stuck for 23s!' when attempting to read the vpd area. > > Certainly 0x1969:0x1026 experienced this. Ok. Thanks. I will update the patch 4/4. > > 09:00.0 Ethernet controller: Atheros Communications AR8121/AR8113/AR8114 Gigabit or Fast Ethernet (rev b0) > Subsystem: Atheros Communications AR8121/AR8113/AR8114 Gigabit or Fast Ethernet > Control: I/O+ Mem+ BusMaster+ SpecCycle- MemWINV- VGASnoop- ParErr- Stepping- SERR- FastB2B- DisINTx+ > Status: Cap+ 66MHz- UDF- FastB2B- ParErr- DEVSEL=fast >TAbort- <TAbort- <MAbort- >SERR- <PERR- INTx- > Latency: 0, Cache Line Size: 64 bytes > Interrupt: pin A routed to IRQ 46 > Region 0: Memory at c0300000 (64-bit, non-prefetchable) [size=256K] > Region 2: I/O ports at 3000 [size=128] > Capabilities: [40] Power Management version 2 > Flags: PMEClk- DSI- D1- D2- AuxCurrent=0mA PME(D0-,D1-,D2-,D3hot+,D3cold+) > Status: D0 NoSoftRst- PME-Enable- DSel=0 DScale=0 PME- > Capabilities: [48] MSI: Enable+ Count=1/1 Maskable- 64bit+ > Address: 00000000fee0300c Data: 41a1 > Capabilities: [58] Express (v1) Endpoint, MSI 00 > DevCap: MaxPayload 4096 bytes, PhantFunc 0, Latency L0s <4us, L1 unlimited > ExtTag- AttnBtn+ AttnInd+ PwrInd+ RBE- FLReset- > DevCtl: Report errors: Correctable- Non-Fatal- Fatal- Unsupported- > RlxdOrd- ExtTag- PhantFunc- AuxPwr- NoSnoop- > MaxPayload 128 bytes, MaxReadReq 512 bytes > DevSta: CorrErr- UncorrErr+ FatalErr- UnsuppReq+ AuxPwr+ TransPend- > LnkCap: Port #0, Speed 2.5GT/s, Width x1, ASPM L0s, Latency L0 unlimited, L1 unlimited > ClockPM- Surprise- LLActRep- BwNot- > LnkCtl: ASPM Disabled; RCB 64 bytes Disabled- Retrain- CommClk+ > ExtSynch- ClockPM- AutWidDis- BWInt- AutBWInt- > LnkSta: Speed 2.5GT/s, Width x1, TrErr- Train- SlotClk+ DLActive- BWMgmt- ABWMgmt- > Capabilities: [6c] Vital Product Data > Unknown small resource type 0b, will not decode more. > Capabilities: [100 v1] Advanced Error Reporting > UESta: DLP- SDES- TLP- FCP- CmpltTO- CmpltAbrt- UnxCmplt- RxOF- MalfTLP- ECRC- UnsupReq+ ACSViol- > UEMsk: DLP- SDES- TLP- FCP- CmpltTO- CmpltAbrt- UnxCmplt- RxOF- MalfTLP- ECRC- UnsupReq- ACSViol- > UESvrt: DLP+ SDES- TLP- FCP+ CmpltTO- CmpltAbrt- UnxCmplt- RxOF+ MalfTLP+ ECRC- UnsupReq- ACSViol- > CESta: RxErr- BadTLP- BadDLLP- Rollover- Timeout- NonFatalErr- > CEMsk: RxErr- BadTLP- BadDLLP- Rollover- Timeout- NonFatalErr- > AERCap: First Error Pointer: 14, GenCap+ CGenEn- ChkCap+ ChkEn- > Capabilities: [180 v1] Device Serial Number ff-2e-05-c3-00-23-8b-ff > Kernel driver in use: ATL1E > 00: 69 19 26 10 07 04 10 00 b0 00 00 02 10 00 00 00 > 10: 04 00 30 c0 00 00 00 00 01 30 00 00 00 00 00 00 > 20: 00 00 00 00 00 00 00 00 00 00 00 00 69 19 26 10 > 30: 00 00 00 00 40 00 00 00 00 00 00 00 0a 01 00 00 > 40: 01 48 02 c0 00 00 00 00 05 58 81 00 0c 30 e0 fe > 50: 00 00 00 00 a1 41 00 00 10 6c 01 00 85 7f 04 05 > 60: 00 20 1a 00 11 f4 03 00 40 00 11 10 03 00 00 80 > 70: 5a ff 88 14 00 00 00 00 00 00 00 00 00 00 00 00 > 80: 00 00 00 00 69 19 26 10 00 00 00 00 00 00 00 00 > 90: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 > a0: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 > b0: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 > c0: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 > d0: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 > e0: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 > f0: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 > >> drivers/pci/quirks.c | 41 +++++++++++++++++++++++++++++++++++++++++ >> 1 files changed, 41 insertions(+), 0 deletions(-) >> >> diff --git a/drivers/pci/quirks.c b/drivers/pci/quirks.c >> index b03373f..8abcee5 100644 >> --- a/drivers/pci/quirks.c >> +++ b/drivers/pci/quirks.c >> @@ -2123,6 +2123,47 @@ static void quirk_via_cx700_pci_parking_caching(struct pci_dev *dev) >> DECLARE_PCI_FIXUP_FINAL(PCI_VENDOR_ID_VIA, 0x324e, quirk_via_cx700_pci_parking_caching); >> >> /* >> + * A read/write to sysfs entry ('/sys/bus/pci/devices/<id>/vpd') >> + * will dump 32k of data. The default length is set as 32768. >> + * Reading a full 32k will cause an access beyond the VPD end tag. >> + * The system behaviour at that point is mostly unpredictable. >> + * Apparently, some vendors have not implemented this VPD headers properly. >> + * Adding a generic function disable vpd data for these buggy adapters >> + * Add the DECLARE_PCI_FIXUP_FINAL line below with the specific with >> + * vendor and device of interest to use this quirk. >> + */ >> +static void quirk_blacklist_vpd(struct pci_dev *dev) >> +{ >> + if (dev->vpd) { >> + dev->vpd->len = 0; >> + dev_warn(&dev->dev, "PCI vpd access has been disabled due to firmware bug\n"); >> + } >> +} >> + >> +DECLARE_PCI_FIXUP_FINAL(PCI_VENDOR_ID_LSI_LOGIC, 0x0060, >> + quirk_blacklist_vpd); >> +DECLARE_PCI_FIXUP_FINAL(PCI_VENDOR_ID_LSI_LOGIC, 0x007c, >> + quirk_blacklist_vpd); >> +DECLARE_PCI_FIXUP_FINAL(PCI_VENDOR_ID_LSI_LOGIC, 0x0413, >> + quirk_blacklist_vpd); >> +DECLARE_PCI_FIXUP_FINAL(PCI_VENDOR_ID_LSI_LOGIC, 0x0078, >> + quirk_blacklist_vpd); >> +DECLARE_PCI_FIXUP_FINAL(PCI_VENDOR_ID_LSI_LOGIC, 0x0079, >> + quirk_blacklist_vpd); >> +DECLARE_PCI_FIXUP_FINAL(PCI_VENDOR_ID_LSI_LOGIC, 0x0073, >> + quirk_blacklist_vpd); >> +DECLARE_PCI_FIXUP_FINAL(PCI_VENDOR_ID_LSI_LOGIC, 0x0071, >> + quirk_blacklist_vpd); >> +DECLARE_PCI_FIXUP_FINAL(PCI_VENDOR_ID_LSI_LOGIC, 0x005b, >> + quirk_blacklist_vpd); >> +DECLARE_PCI_FIXUP_FINAL(PCI_VENDOR_ID_LSI_LOGIC, 0x002f, >> + quirk_blacklist_vpd); >> +DECLARE_PCI_FIXUP_FINAL(PCI_VENDOR_ID_LSI_LOGIC, 0x005d, >> + quirk_blacklist_vpd); >> +DECLARE_PCI_FIXUP_FINAL(PCI_VENDOR_ID_LSI_LOGIC, 0x005f, >> + quirk_blacklist_vpd); >> + >> +/* >> * For Broadcom 5706, 5708, 5709 rev. A nics, any read beyond the >> * VPD end tag will hang the device. This problem was initially >> * observed when a vpd entry was created in sysfs >> ^ permalink raw reply [flat|nested] 10+ messages in thread
* RE: [PATCH RFC] pci: Blacklist vpd access for buggy devices 2016-01-19 20:39 ` Babu Moger @ 2016-01-21 15:47 ` Jordan_Hargrave 2016-01-21 17:10 ` Babu Moger 0 siblings, 1 reply; 10+ messages in thread From: Jordan_Hargrave @ 2016-01-21 15:47 UTC (permalink / raw) To: babu.moger, bhelgaas Cc: linux-pci, linux-kernel, alexander.duyck, hare, mkubecek, shane.seymour, myron.stowe >From: Babu Moger [babu.moger@oracle.com] >Sent: Tuesday, January 19, 2016 2:39 PM >To: Hargrave, Jordan; bhelgaas@google.com >Cc: linux-pci@vger.kernel.org; linux-kernel@vger.kernel.org; alexander.duyck@gmail.com; hare@suse.de; mkubecek@suse.com; shane.seymour@hpe.com; myron.stowe@gmail.com >Subject: Re: [PATCH RFC] pci: Blacklist vpd access for buggy devices > >Hi Jordan, > >On 1/19/2016 9:22 AM, Jordan_Hargrave@dell.com wrote: >> From: Babu Moger [babu.moger@oracle.com] >> Sent: Monday, January 11, 2016 4:49 PM >> To: bhelgaas@google.com >> Cc: linux-pci@vger.kernel.org; linux-kernel@vger.kernel.org; alexander.duyck@gmail.com; hare@suse.de; mkubecek@suse.com; shane.seymour@hpe.com; myron.stowe@gmail.com; VenkatKumar.Duvvuru@avago.com; Hargrave, Jordan >> Subject: Re: [PATCH RFC] pci: Blacklist vpd access for buggy devices >> >> Sorry. Missed Jordan. >> >> On 1/11/2016 3:13 PM, Babu Moger wrote: >>> Reading or Writing of PCI VPD data causes system panic. >>> We saw this problem by running "lspci -vvv" in the beginning. >>> However this can be easily reproduced by running >>> cat /sys/bus/devices/XX../vpd >>> >>> VPD length has been set as 32768 by default. Accessing vpd >>> will trigger read/write of 32k. This causes problem as we >>> could read data beyond the VPD end tag. Behaviour is un- >>> predictable when this happens. I see some other adapter doing >>> similar quirks(commit bffadffd43d4 ("PCI: fix VPD limit quirk >>> for Broadcom 5708S")) >>> >>> I see there is an attempt to fix this right way. >>> https://patchwork.ozlabs.org/patch/534843/ or >>> https://lkml.org/lkml/2015/10/23/97 >>> >>> Tried to fix it this way, but problem is I dont see the proper >>> start/end TAGs(at least for this adapter) at all. The data is >>> mostly junk or zeros. This patch fixes the issue by setting the >>> vpd length to 0x80. >>> >>> Also look at the threds >>> >>> https://lkml.org/lkml/2015/11/10/557 >>> https://lkml.org/lkml/2015/12/29/315 >>> >>> Signed-off-by: Babu Moger <babu.moger@oracle.com> >>> --- >>> >>> NOTE: >>> Jordan, Are you sure all the devices in PCI_VENDOR_ID_ATHEROS and >>> PCI_VENDOR_ID_ATTANSIC have this problem. You have used PCI_ANY_ID. >>> I felt it is too broad. Can you please check. >>> >> >> I don't actually have that hardware, it was a bugfix for biosdevname for RedHat. We were getting >> 'BUG: soft lockup - CPU#0 stuck for 23s!' when attempting to read the vpd area. >> >> Certainly 0x1969:0x1026 experienced this. > >Ok. Thanks. I will update the patch 4/4. > Thanks! I also found 1969:2062. Maybe best to just block everything in drivers/net/ethernet/atheros/xxxx atl1c: static const struct pci_device_id atl1c_pci_tbl[] = { {PCI_DEVICE(PCI_VENDOR_ID_ATTANSIC, PCI_DEVICE_ID_ATTANSIC_L1C)}, {PCI_DEVICE(PCI_VENDOR_ID_ATTANSIC, PCI_DEVICE_ID_ATTANSIC_L2C)}, {PCI_DEVICE(PCI_VENDOR_ID_ATTANSIC, PCI_DEVICE_ID_ATHEROS_L2C_B)}, {PCI_DEVICE(PCI_VENDOR_ID_ATTANSIC, PCI_DEVICE_ID_ATHEROS_L2C_B2)}, {PCI_DEVICE(PCI_VENDOR_ID_ATTANSIC, PCI_DEVICE_ID_ATHEROS_L1D)}, {PCI_DEVICE(PCI_VENDOR_ID_ATTANSIC, PCI_DEVICE_ID_ATHEROS_L1D_2_0)}, /* required last entry */ { 0 } }; atl1e static const struct pci_device_id atl1e_pci_tbl[] = { {PCI_DEVICE(PCI_VENDOR_ID_ATTANSIC, PCI_DEVICE_ID_ATTANSIC_L1E)}, {PCI_DEVICE(PCI_VENDOR_ID_ATTANSIC, 0x1066)}, /* required last entry */ { 0 } }; >> >> 09:00.0 Ethernet controller: Atheros Communications AR8121/AR8113/AR8114 Gigabit or Fast Ethernet (rev b0) >> Subsystem: Atheros Communications AR8121/AR8113/AR8114 Gigabit or Fast Ethernet >> Control: I/O+ Mem+ BusMaster+ SpecCycle- MemWINV- VGASnoop- ParErr- Stepping- SERR- FastB2B- DisINTx+ >> Status: Cap+ 66MHz- UDF- FastB2B- ParErr- DEVSEL=fast >TAbort- <TAbort- <MAbort- >SERR- <PERR- INTx- >> Latency: 0, Cache Line Size: 64 bytes >> Interrupt: pin A routed to IRQ 46 >> Region 0: Memory at c0300000 (64-bit, non-prefetchable) [size=256K] >> Region 2: I/O ports at 3000 [size=128] >> Capabilities: [40] Power Management version 2 >> Flags: PMEClk- DSI- D1- D2- AuxCurrent=0mA PME(D0-,D1-,D2-,D3hot+,D3cold+) >> Status: D0 NoSoftRst- PME-Enable- DSel=0 DScale=0 PME- >> Capabilities: [48] MSI: Enable+ Count=1/1 Maskable- 64bit+ >> Address: 00000000fee0300c Data: 41a1 >> Capabilities: [58] Express (v1) Endpoint, MSI 00 >> DevCap: MaxPayload 4096 bytes, PhantFunc 0, Latency L0s <4us, L1 unlimited >> ExtTag- AttnBtn+ AttnInd+ PwrInd+ RBE- FLReset- >> DevCtl: Report errors: Correctable- Non-Fatal- Fatal- Unsupported- >> RlxdOrd- ExtTag- PhantFunc- AuxPwr- NoSnoop- >> MaxPayload 128 bytes, MaxReadReq 512 bytes >> DevSta: CorrErr- UncorrErr+ FatalErr- UnsuppReq+ AuxPwr+ TransPend- >> LnkCap: Port #0, Speed 2.5GT/s, Width x1, ASPM L0s, Latency L0 unlimited, L1 unlimited >> ClockPM- Surprise- LLActRep- BwNot- >> LnkCtl: ASPM Disabled; RCB 64 bytes Disabled- Retrain- CommClk+ >> ExtSynch- ClockPM- AutWidDis- BWInt- AutBWInt- >> LnkSta: Speed 2.5GT/s, Width x1, TrErr- Train- SlotClk+ DLActive- BWMgmt- ABWMgmt- >> Capabilities: [6c] Vital Product Data >> Unknown small resource type 0b, will not decode more. >> Capabilities: [100 v1] Advanced Error Reporting >> UESta: DLP- SDES- TLP- FCP- CmpltTO- CmpltAbrt- UnxCmplt- RxOF- MalfTLP- ECRC- UnsupReq+ ACSViol- >> UEMsk: DLP- SDES- TLP- FCP- CmpltTO- CmpltAbrt- UnxCmplt- RxOF- MalfTLP- ECRC- UnsupReq- ACSViol- >> UESvrt: DLP+ SDES- TLP- FCP+ CmpltTO- CmpltAbrt- UnxCmplt- RxOF+ MalfTLP+ ECRC- UnsupReq- ACSViol- >> CESta: RxErr- BadTLP- BadDLLP- Rollover- Timeout- NonFatalErr- >> CEMsk: RxErr- BadTLP- BadDLLP- Rollover- Timeout- NonFatalErr- >> AERCap: First Error Pointer: 14, GenCap+ CGenEn- ChkCap+ ChkEn- >> Capabilities: [180 v1] Device Serial Number ff-2e-05-c3-00-23-8b-ff >> Kernel driver in use: ATL1E >> 00: 69 19 26 10 07 04 10 00 b0 00 00 02 10 00 00 00 >> 10: 04 00 30 c0 00 00 00 00 01 30 00 00 00 00 00 00 >> 20: 00 00 00 00 00 00 00 00 00 00 00 00 69 19 26 10 >> 30: 00 00 00 00 40 00 00 00 00 00 00 00 0a 01 00 00 >> 40: 01 48 02 c0 00 00 00 00 05 58 81 00 0c 30 e0 fe >> 50: 00 00 00 00 a1 41 00 00 10 6c 01 00 85 7f 04 05 >> 60: 00 20 1a 00 11 f4 03 00 40 00 11 10 03 00 00 80 >> 70: 5a ff 88 14 00 00 00 00 00 00 00 00 00 00 00 00 >> 80: 00 00 00 00 69 19 26 10 00 00 00 00 00 00 00 00 >> 90: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 >> a0: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 >> b0: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 >> c0: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 >> d0: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 >> e0: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 >> f0: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 >> >>> drivers/pci/quirks.c | 41 +++++++++++++++++++++++++++++++++++++++++ >>> 1 files changed, 41 insertions(+), 0 deletions(-) >>> >>> diff --git a/drivers/pci/quirks.c b/drivers/pci/quirks.c >>> index b03373f..8abcee5 100644 >>> --- a/drivers/pci/quirks.c >>> +++ b/drivers/pci/quirks.c >>> @@ -2123,6 +2123,47 @@ static void quirk_via_cx700_pci_parking_caching(struct pci_dev *dev) >>> DECLARE_PCI_FIXUP_FINAL(PCI_VENDOR_ID_VIA, 0x324e, quirk_via_cx700_pci_parking_caching); >>> >>> /* >>> + * A read/write to sysfs entry ('/sys/bus/pci/devices/<id>/vpd') >>> + * will dump 32k of data. The default length is set as 32768. >>> + * Reading a full 32k will cause an access beyond the VPD end tag. >>> + * The system behaviour at that point is mostly unpredictable. >>> + * Apparently, some vendors have not implemented this VPD headers properly. >>> + * Adding a generic function disable vpd data for these buggy adapters >>> + * Add the DECLARE_PCI_FIXUP_FINAL line below with the specific with >>> + * vendor and device of interest to use this quirk. >>> + */ >>> +static void quirk_blacklist_vpd(struct pci_dev *dev) >>> +{ >>> + if (dev->vpd) { >>> + dev->vpd->len = 0; >>> + dev_warn(&dev->dev, "PCI vpd access has been disabled due to firmware bug\n"); >>> + } >>> +} >>> + >>> +DECLARE_PCI_FIXUP_FINAL(PCI_VENDOR_ID_LSI_LOGIC, 0x0060, >>> + quirk_blacklist_vpd); >>> +DECLARE_PCI_FIXUP_FINAL(PCI_VENDOR_ID_LSI_LOGIC, 0x007c, >>> + quirk_blacklist_vpd); >>> +DECLARE_PCI_FIXUP_FINAL(PCI_VENDOR_ID_LSI_LOGIC, 0x0413, >>> + quirk_blacklist_vpd); >>> +DECLARE_PCI_FIXUP_FINAL(PCI_VENDOR_ID_LSI_LOGIC, 0x0078, >>> + quirk_blacklist_vpd); >>> +DECLARE_PCI_FIXUP_FINAL(PCI_VENDOR_ID_LSI_LOGIC, 0x0079, >>> + quirk_blacklist_vpd); >>> +DECLARE_PCI_FIXUP_FINAL(PCI_VENDOR_ID_LSI_LOGIC, 0x0073, >>> + quirk_blacklist_vpd); >>> +DECLARE_PCI_FIXUP_FINAL(PCI_VENDOR_ID_LSI_LOGIC, 0x0071, >>> + quirk_blacklist_vpd); >>> +DECLARE_PCI_FIXUP_FINAL(PCI_VENDOR_ID_LSI_LOGIC, 0x005b, >>> + quirk_blacklist_vpd); >>> +DECLARE_PCI_FIXUP_FINAL(PCI_VENDOR_ID_LSI_LOGIC, 0x002f, >>> + quirk_blacklist_vpd); >>> +DECLARE_PCI_FIXUP_FINAL(PCI_VENDOR_ID_LSI_LOGIC, 0x005d, >>> + quirk_blacklist_vpd); >>> +DECLARE_PCI_FIXUP_FINAL(PCI_VENDOR_ID_LSI_LOGIC, 0x005f, >>> + quirk_blacklist_vpd); >>> + >>> +/* >>> * For Broadcom 5706, 5708, 5709 rev. A nics, any read beyond the >>> * VPD end tag will hang the device. This problem was initially >>> * observed when a vpd entry was created in sysfs >>> > ^ permalink raw reply [flat|nested] 10+ messages in thread
* Re: [PATCH RFC] pci: Blacklist vpd access for buggy devices 2016-01-21 15:47 ` Jordan_Hargrave @ 2016-01-21 17:10 ` Babu Moger 0 siblings, 0 replies; 10+ messages in thread From: Babu Moger @ 2016-01-21 17:10 UTC (permalink / raw) To: Jordan_Hargrave, bhelgaas Cc: linux-pci, linux-kernel, alexander.duyck, hare, mkubecek, shane.seymour, myron.stowe On 1/21/2016 9:47 AM, Jordan_Hargrave@dell.com wrote: >> From: Babu Moger [babu.moger@oracle.com] >> Sent: Tuesday, January 19, 2016 2:39 PM >> To: Hargrave, Jordan; bhelgaas@google.com >> Cc: linux-pci@vger.kernel.org; linux-kernel@vger.kernel.org; alexander.duyck@gmail.com; hare@suse.de; mkubecek@suse.com; shane.seymour@hpe.com; myron.stowe@gmail.com >> Subject: Re: [PATCH RFC] pci: Blacklist vpd access for buggy devices >> >> Hi Jordan, >> >> On 1/19/2016 9:22 AM, Jordan_Hargrave@dell.com wrote: >>> From: Babu Moger [babu.moger@oracle.com] >>> Sent: Monday, January 11, 2016 4:49 PM >>> To: bhelgaas@google.com >>> Cc: linux-pci@vger.kernel.org; linux-kernel@vger.kernel.org; alexander.duyck@gmail.com; hare@suse.de; mkubecek@suse.com; shane.seymour@hpe.com; myron.stowe@gmail.com; VenkatKumar.Duvvuru@avago.com; Hargrave, Jordan >>> Subject: Re: [PATCH RFC] pci: Blacklist vpd access for buggy devices >>> >>> Sorry. Missed Jordan. >>> >>> On 1/11/2016 3:13 PM, Babu Moger wrote: >>>> Reading or Writing of PCI VPD data causes system panic. >>>> We saw this problem by running "lspci -vvv" in the beginning. >>>> However this can be easily reproduced by running >>>> cat /sys/bus/devices/XX../vpd >>>> >>>> VPD length has been set as 32768 by default. Accessing vpd >>>> will trigger read/write of 32k. This causes problem as we >>>> could read data beyond the VPD end tag. Behaviour is un- >>>> predictable when this happens. I see some other adapter doing >>>> similar quirks(commit bffadffd43d4 ("PCI: fix VPD limit quirk >>>> for Broadcom 5708S")) >>>> >>>> I see there is an attempt to fix this right way. >>>> https://patchwork.ozlabs.org/patch/534843/ or >>>> https://lkml.org/lkml/2015/10/23/97 >>>> >>>> Tried to fix it this way, but problem is I dont see the proper >>>> start/end TAGs(at least for this adapter) at all. The data is >>>> mostly junk or zeros. This patch fixes the issue by setting the >>>> vpd length to 0x80. >>>> >>>> Also look at the threds >>>> >>>> https://lkml.org/lkml/2015/11/10/557 >>>> https://lkml.org/lkml/2015/12/29/315 >>>> >>>> Signed-off-by: Babu Moger <babu.moger@oracle.com> >>>> --- >>>> >>>> NOTE: >>>> Jordan, Are you sure all the devices in PCI_VENDOR_ID_ATHEROS and >>>> PCI_VENDOR_ID_ATTANSIC have this problem. You have used PCI_ANY_ID. >>>> I felt it is too broad. Can you please check. >>>> >>> >>> I don't actually have that hardware, it was a bugfix for biosdevname for RedHat. We were getting >>> 'BUG: soft lockup - CPU#0 stuck for 23s!' when attempting to read the vpd area. >>> >>> Certainly 0x1969:0x1026 experienced this. >> >> Ok. Thanks. I will update the patch 4/4. >> > > Thanks! I also found 1969:2062. Maybe best to just block everything in drivers/net/ethernet/atheros/xxxx Ok. I will update the patch.. > > atl1c: > static const struct pci_device_id atl1c_pci_tbl[] = { > {PCI_DEVICE(PCI_VENDOR_ID_ATTANSIC, PCI_DEVICE_ID_ATTANSIC_L1C)}, > {PCI_DEVICE(PCI_VENDOR_ID_ATTANSIC, PCI_DEVICE_ID_ATTANSIC_L2C)}, > {PCI_DEVICE(PCI_VENDOR_ID_ATTANSIC, PCI_DEVICE_ID_ATHEROS_L2C_B)}, > {PCI_DEVICE(PCI_VENDOR_ID_ATTANSIC, PCI_DEVICE_ID_ATHEROS_L2C_B2)}, > {PCI_DEVICE(PCI_VENDOR_ID_ATTANSIC, PCI_DEVICE_ID_ATHEROS_L1D)}, > {PCI_DEVICE(PCI_VENDOR_ID_ATTANSIC, PCI_DEVICE_ID_ATHEROS_L1D_2_0)}, > /* required last entry */ > { 0 } > }; > > atl1e > static const struct pci_device_id atl1e_pci_tbl[] = { > {PCI_DEVICE(PCI_VENDOR_ID_ATTANSIC, PCI_DEVICE_ID_ATTANSIC_L1E)}, > {PCI_DEVICE(PCI_VENDOR_ID_ATTANSIC, 0x1066)}, > /* required last entry */ > { 0 } > }; > >>> >>> 09:00.0 Ethernet controller: Atheros Communications AR8121/AR8113/AR8114 Gigabit or Fast Ethernet (rev b0) >>> Subsystem: Atheros Communications AR8121/AR8113/AR8114 Gigabit or Fast Ethernet >>> Control: I/O+ Mem+ BusMaster+ SpecCycle- MemWINV- VGASnoop- ParErr- Stepping- SERR- FastB2B- DisINTx+ >>> Status: Cap+ 66MHz- UDF- FastB2B- ParErr- DEVSEL=fast >TAbort- <TAbort- <MAbort- >SERR- <PERR- INTx- >>> Latency: 0, Cache Line Size: 64 bytes >>> Interrupt: pin A routed to IRQ 46 >>> Region 0: Memory at c0300000 (64-bit, non-prefetchable) [size=256K] >>> Region 2: I/O ports at 3000 [size=128] >>> Capabilities: [40] Power Management version 2 >>> Flags: PMEClk- DSI- D1- D2- AuxCurrent=0mA PME(D0-,D1-,D2-,D3hot+,D3cold+) >>> Status: D0 NoSoftRst- PME-Enable- DSel=0 DScale=0 PME- >>> Capabilities: [48] MSI: Enable+ Count=1/1 Maskable- 64bit+ >>> Address: 00000000fee0300c Data: 41a1 >>> Capabilities: [58] Express (v1) Endpoint, MSI 00 >>> DevCap: MaxPayload 4096 bytes, PhantFunc 0, Latency L0s <4us, L1 unlimited >>> ExtTag- AttnBtn+ AttnInd+ PwrInd+ RBE- FLReset- >>> DevCtl: Report errors: Correctable- Non-Fatal- Fatal- Unsupported- >>> RlxdOrd- ExtTag- PhantFunc- AuxPwr- NoSnoop- >>> MaxPayload 128 bytes, MaxReadReq 512 bytes >>> DevSta: CorrErr- UncorrErr+ FatalErr- UnsuppReq+ AuxPwr+ TransPend- >>> LnkCap: Port #0, Speed 2.5GT/s, Width x1, ASPM L0s, Latency L0 unlimited, L1 unlimited >>> ClockPM- Surprise- LLActRep- BwNot- >>> LnkCtl: ASPM Disabled; RCB 64 bytes Disabled- Retrain- CommClk+ >>> ExtSynch- ClockPM- AutWidDis- BWInt- AutBWInt- >>> LnkSta: Speed 2.5GT/s, Width x1, TrErr- Train- SlotClk+ DLActive- BWMgmt- ABWMgmt- >>> Capabilities: [6c] Vital Product Data >>> Unknown small resource type 0b, will not decode more. >>> Capabilities: [100 v1] Advanced Error Reporting >>> UESta: DLP- SDES- TLP- FCP- CmpltTO- CmpltAbrt- UnxCmplt- RxOF- MalfTLP- ECRC- UnsupReq+ ACSViol- >>> UEMsk: DLP- SDES- TLP- FCP- CmpltTO- CmpltAbrt- UnxCmplt- RxOF- MalfTLP- ECRC- UnsupReq- ACSViol- >>> UESvrt: DLP+ SDES- TLP- FCP+ CmpltTO- CmpltAbrt- UnxCmplt- RxOF+ MalfTLP+ ECRC- UnsupReq- ACSViol- >>> CESta: RxErr- BadTLP- BadDLLP- Rollover- Timeout- NonFatalErr- >>> CEMsk: RxErr- BadTLP- BadDLLP- Rollover- Timeout- NonFatalErr- >>> AERCap: First Error Pointer: 14, GenCap+ CGenEn- ChkCap+ ChkEn- >>> Capabilities: [180 v1] Device Serial Number ff-2e-05-c3-00-23-8b-ff >>> Kernel driver in use: ATL1E >>> 00: 69 19 26 10 07 04 10 00 b0 00 00 02 10 00 00 00 >>> 10: 04 00 30 c0 00 00 00 00 01 30 00 00 00 00 00 00 >>> 20: 00 00 00 00 00 00 00 00 00 00 00 00 69 19 26 10 >>> 30: 00 00 00 00 40 00 00 00 00 00 00 00 0a 01 00 00 >>> 40: 01 48 02 c0 00 00 00 00 05 58 81 00 0c 30 e0 fe >>> 50: 00 00 00 00 a1 41 00 00 10 6c 01 00 85 7f 04 05 >>> 60: 00 20 1a 00 11 f4 03 00 40 00 11 10 03 00 00 80 >>> 70: 5a ff 88 14 00 00 00 00 00 00 00 00 00 00 00 00 >>> 80: 00 00 00 00 69 19 26 10 00 00 00 00 00 00 00 00 >>> 90: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 >>> a0: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 >>> b0: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 >>> c0: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 >>> d0: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 >>> e0: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 >>> f0: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 >>> >>>> drivers/pci/quirks.c | 41 +++++++++++++++++++++++++++++++++++++++++ >>>> 1 files changed, 41 insertions(+), 0 deletions(-) >>>> >>>> diff --git a/drivers/pci/quirks.c b/drivers/pci/quirks.c >>>> index b03373f..8abcee5 100644 >>>> --- a/drivers/pci/quirks.c >>>> +++ b/drivers/pci/quirks.c >>>> @@ -2123,6 +2123,47 @@ static void quirk_via_cx700_pci_parking_caching(struct pci_dev *dev) >>>> DECLARE_PCI_FIXUP_FINAL(PCI_VENDOR_ID_VIA, 0x324e, quirk_via_cx700_pci_parking_caching); >>>> >>>> /* >>>> + * A read/write to sysfs entry ('/sys/bus/pci/devices/<id>/vpd') >>>> + * will dump 32k of data. The default length is set as 32768. >>>> + * Reading a full 32k will cause an access beyond the VPD end tag. >>>> + * The system behaviour at that point is mostly unpredictable. >>>> + * Apparently, some vendors have not implemented this VPD headers properly. >>>> + * Adding a generic function disable vpd data for these buggy adapters >>>> + * Add the DECLARE_PCI_FIXUP_FINAL line below with the specific with >>>> + * vendor and device of interest to use this quirk. >>>> + */ >>>> +static void quirk_blacklist_vpd(struct pci_dev *dev) >>>> +{ >>>> + if (dev->vpd) { >>>> + dev->vpd->len = 0; >>>> + dev_warn(&dev->dev, "PCI vpd access has been disabled due to firmware bug\n"); >>>> + } >>>> +} >>>> + >>>> +DECLARE_PCI_FIXUP_FINAL(PCI_VENDOR_ID_LSI_LOGIC, 0x0060, >>>> + quirk_blacklist_vpd); >>>> +DECLARE_PCI_FIXUP_FINAL(PCI_VENDOR_ID_LSI_LOGIC, 0x007c, >>>> + quirk_blacklist_vpd); >>>> +DECLARE_PCI_FIXUP_FINAL(PCI_VENDOR_ID_LSI_LOGIC, 0x0413, >>>> + quirk_blacklist_vpd); >>>> +DECLARE_PCI_FIXUP_FINAL(PCI_VENDOR_ID_LSI_LOGIC, 0x0078, >>>> + quirk_blacklist_vpd); >>>> +DECLARE_PCI_FIXUP_FINAL(PCI_VENDOR_ID_LSI_LOGIC, 0x0079, >>>> + quirk_blacklist_vpd); >>>> +DECLARE_PCI_FIXUP_FINAL(PCI_VENDOR_ID_LSI_LOGIC, 0x0073, >>>> + quirk_blacklist_vpd); >>>> +DECLARE_PCI_FIXUP_FINAL(PCI_VENDOR_ID_LSI_LOGIC, 0x0071, >>>> + quirk_blacklist_vpd); >>>> +DECLARE_PCI_FIXUP_FINAL(PCI_VENDOR_ID_LSI_LOGIC, 0x005b, >>>> + quirk_blacklist_vpd); >>>> +DECLARE_PCI_FIXUP_FINAL(PCI_VENDOR_ID_LSI_LOGIC, 0x002f, >>>> + quirk_blacklist_vpd); >>>> +DECLARE_PCI_FIXUP_FINAL(PCI_VENDOR_ID_LSI_LOGIC, 0x005d, >>>> + quirk_blacklist_vpd); >>>> +DECLARE_PCI_FIXUP_FINAL(PCI_VENDOR_ID_LSI_LOGIC, 0x005f, >>>> + quirk_blacklist_vpd); >>>> + >>>> +/* >>>> * For Broadcom 5706, 5708, 5709 rev. A nics, any read beyond the >>>> * VPD end tag will hang the device. This problem was initially >>>> * observed when a vpd entry was created in sysfs >>>> >> > ^ permalink raw reply [flat|nested] 10+ messages in thread
end of thread, other threads:[~2016-01-21 17:10 UTC | newest] Thread overview: 10+ messages (download: mbox.gz / follow: Atom feed) -- links below jump to the message on this page -- 2015-12-29 22:19 [PATCH] Limit VPD length on Atheros wifi cards Jordan Hargrave 2016-01-09 0:57 ` Bjorn Helgaas 2016-01-09 1:05 ` Bjorn Helgaas 2016-01-09 23:15 ` Babu Moger 2016-01-11 21:13 ` [PATCH RFC] pci: Blacklist vpd access for buggy devices Babu Moger 2016-01-11 22:49 ` Babu Moger 2016-01-19 15:22 ` Jordan_Hargrave 2016-01-19 20:39 ` Babu Moger 2016-01-21 15:47 ` Jordan_Hargrave 2016-01-21 17:10 ` Babu Moger
This is an external index of several public inboxes, see mirroring instructions on how to clone and mirror all data and code used by this external index.