Re: [PATCH v4] pci: Limit VPD length for megaraid_sas adapter
Hi Bjorn, Checking again.
How about adding some messages in the logs to let user know that vpd has been
disabled on this device in case if there is an attempt to access vpd.
What do you think?. Thanks
Babu
On 12/7/2015 5:07 PM, Babu Moger wrote:
> Hi Bjorn,
> My old logs were lost. So, I had to recreate the issue again. So it took
> sometime.
>
> On 12/7/2015 11:29 AM, Bjorn Helgaas wrote:
>> Hi Babu,
>>
>> On Thu, Dec 03, 2015 at 12:25:19PM -0800, 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
>>
>> What sort of panic is this?
>
> Actual panic stack showed total different area. It looked like this.
>
> TSTATE: 80e01601 TPC: 007945c8 TNPC: 007945cc Y:
> Not tainted
> TPC:
> g0: 4000 g1: 084001604020 g2: 084001604024 g3:
> 0acb
> g4: 800fe42d0340 g5: 8000291ce000 g6: 800fe42f4000 g7:
> 03114000
> o0: 800fe085d99c o1: 800fe42f4008 o2: 4000 o3:
> 0001
> o4: o5: 0012 sp: 80002047b2b1 ret_pc:
> 00794540
> RPC:
> l0: 800fe085d980 l1: c001 l2: 000b l3:
> 008e7058
> l4: 00bd19a8 l5: 00bd6a88 l6: l7:
>
> i0: 800fe085d800 i1: 0016 i2: 800c20c007c3 i3:
> f0265f78
> i4: feff4748 i5: feff2ff8 i6: 80002047b3d1 i7:
> 0077adf0
> I7:
> Call Trace:
> [0077adf0] usb_hcd_irq+0x38/0xa0
> [004d122c] handle_irq_event_percpu+0x8c/0x204
> [004d13d8] handle_irq_event+0x34/0x60
> [004d3998] handle_fasteoi_irq+0xdc/0x164
> [004d1178] generic_handle_irq+0x24/0x38
> [008dce68] handler_irq+0xb8/0xec
> [004208b4] tl0_irq5+0x14/0x20
> [0042cfac] cpu_idle+0x9c/0x18c
> [008d2ad0] after_lock_tlb+0x1b4/0x1cc
> [] (null)
>
>
> While analyzing it from kdump, I saw it stuck in here below.
>
> PID: 5274 TASK: 800fe1198680 CPU: 0 COMMAND: "cat"
> #0 [800fe25f6f81] switch_to_pc at 8d725c
> #1 [800fe25f70e1] pci_user_read_config_word at 6c4698
> #2 [800fe25f71a1] pci_vpd_pci22_wait at 6c4710
> #3 [800fe25f7261] pci_vpd_pci22_read at 6c4994
> #4 [800fe25f7321] pci_read_vpd at 6c3e90
> #5 [800fe25f73d1] read_vpd_attr at 6ccc78
> #6 [800fe25f7481] read at 5be478
> #7 [800fe25f7531] vfs_read at 54fdb0
> #8 [800fe25f75e1] sys_read at 54ff10
> #9 [800fe25f76a1] linux_sparc_syscall at 4060f4
> TSTATE=0x8082000223 TT=0x16d TPC=0xfc0100295e28 TNPC=0xfc0100295e2c
> r0=0x r1=0x0003 r2=0x0020aec0
> r3=0x0020aec4 r4=0x0b00 r5=0x033f
> r6=0x0001 r7=0xfc0106f0 r24=0x0003
> r25=0x0020e000 r26=0x8000 r27=0x
> r28=0x r29=0x r30=0x07feffb468d1
> r31=0x00105d94
>
>
>
>>
>> This seems like a defect in the megaraid hardware or firmware. If the
>> VPD ROM contains junk, there's no hope that software can read the data
>> and figure out how much is safe to read.
>
> Yes this looks like problem with megaraid hardware.
>
> Other day, Myron stowe(myron.st...@gmail.com) reported similar problem with
> his setup.
>
> $ lspci -vvv -s 02:00.0
> 02:00.0 RAID bus controller: LSI Logic / Symbios Logic MegaRAID SAS 2208
> [Thunderbolt] (rev 05)
> Capabilities: [d0] Vital Product Data
> Unknown small resource type 00, will not decode more.
>
> $ cat /sys/devices/pci:00/:00:02.2/:02:00.0/vpd |
> od -A x -t x1z -v
> 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 ><
> *
> 007ff0 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 ><
> 008000
>
>
>>
>> I assume VPD is useful for somebody, and I hate to silently disable
>> the whole thing. We might want to at least log a note about what
>> we're doing.
>
> Sure. Let me know what you think.
>
>
>>
>> Bjorn
>>
>>> 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 iss
Re: [PATCH v4] pci: Limit VPD length for megaraid_sas adapter
On Mon, Dec 7, 2015 at 4:07 PM, Babu Moger wrote:
> Hi Bjorn,
> My old logs were lost. So, I had to recreate the issue again. So it took
> sometime.
>
> On 12/7/2015 11:29 AM, Bjorn Helgaas wrote:
>> Hi Babu,
>>
>> On Thu, Dec 03, 2015 at 12:25:19PM -0800, 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
>>
>> What sort of panic is this?
>
> Actual panic stack showed total different area. It looked like this.
>
> TSTATE: 80e01601 TPC: 007945c8 TNPC: 007945cc Y:
> Not tainted
> TPC:
> g0: 4000 g1: 084001604020 g2: 084001604024 g3:
> 0acb
> g4: 800fe42d0340 g5: 8000291ce000 g6: 800fe42f4000 g7:
> 03114000
> o0: 800fe085d99c o1: 800fe42f4008 o2: 4000 o3:
> 0001
> o4: o5: 0012 sp: 80002047b2b1 ret_pc:
> 00794540
> RPC:
> l0: 800fe085d980 l1: c001 l2: 000b l3:
> 008e7058
> l4: 00bd19a8 l5: 00bd6a88 l6: l7:
>
> i0: 800fe085d800 i1: 0016 i2: 800c20c007c3 i3:
> f0265f78
> i4: feff4748 i5: feff2ff8 i6: 80002047b3d1 i7:
> 0077adf0
> I7:
> Call Trace:
> [0077adf0] usb_hcd_irq+0x38/0xa0
> [004d122c] handle_irq_event_percpu+0x8c/0x204
> [004d13d8] handle_irq_event+0x34/0x60
> [004d3998] handle_fasteoi_irq+0xdc/0x164
> [004d1178] generic_handle_irq+0x24/0x38
> [008dce68] handler_irq+0xb8/0xec
> [004208b4] tl0_irq5+0x14/0x20
> [0042cfac] cpu_idle+0x9c/0x18c
> [008d2ad0] after_lock_tlb+0x1b4/0x1cc
> [] (null)
>
>
> While analyzing it from kdump, I saw it stuck in here below.
>
> PID: 5274 TASK: 800fe1198680 CPU: 0 COMMAND: "cat"
> #0 [800fe25f6f81] switch_to_pc at 8d725c
> #1 [800fe25f70e1] pci_user_read_config_word at 6c4698
> #2 [800fe25f71a1] pci_vpd_pci22_wait at 6c4710
> #3 [800fe25f7261] pci_vpd_pci22_read at 6c4994
> #4 [800fe25f7321] pci_read_vpd at 6c3e90
> #5 [800fe25f73d1] read_vpd_attr at 6ccc78
> #6 [800fe25f7481] read at 5be478
> #7 [800fe25f7531] vfs_read at 54fdb0
> #8 [800fe25f75e1] sys_read at 54ff10
> #9 [800fe25f76a1] linux_sparc_syscall at 4060f4
> TSTATE=0x8082000223 TT=0x16d TPC=0xfc0100295e28 TNPC=0xfc0100295e2c
> r0=0x r1=0x0003 r2=0x0020aec0
> r3=0x0020aec4 r4=0x0b00 r5=0x033f
> r6=0x0001 r7=0xfc0106f0 r24=0x0003
> r25=0x0020e000 r26=0x8000 r27=0x
> r28=0x r29=0x r30=0x07feffb468d1
> r31=0x00105d94
>
>
>
>>
>> This seems like a defect in the megaraid hardware or firmware. If the
>> VPD ROM contains junk, there's no hope that software can read the data
>> and figure out how much is safe to read.
>
> Yes this looks like problem with megaraid hardware.
Agreed, it is a defect in the megaraid hardware/firmware. I've seen
another vendor's device return all 0xff's for the entire VPD area.
>
> Other day, Myron stowe(myron.st...@gmail.com) reported similar problem with
> his setup.
>
> $ lspci -vvv -s 02:00.0
> 02:00.0 RAID bus controller: LSI Logic / Symbios Logic MegaRAID SAS 2208
> [Thunderbolt] (rev 05)
> Capabilities: [d0] Vital Product Data
> Unknown small resource type 00, will not decode more.
>
> $ cat /sys/devices/pci:00/:00:02.2/:02:00.0/vpd |
> od -A x -t x1z -v
> 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 ><
> *
> 007ff0 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 ><
> 008000
>
>
>>
>> I assume VPD is useful for somebody, and I hate to silently disable
>> the whole thing. We might want to at least log a note about what
>> we're doing.
>
> Sure. Let me know what you think.
>
>
>>
>> Bjorn
>>
>>> 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.
As I understand the specification, VPD's
Re: [PATCH v4] pci: Limit VPD length for megaraid_sas adapter
Hi Bjorn,
My old logs were lost. So, I had to recreate the issue again. So it took
sometime.
On 12/7/2015 11:29 AM, Bjorn Helgaas wrote:
> Hi Babu,
>
> On Thu, Dec 03, 2015 at 12:25:19PM -0800, 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
>
> What sort of panic is this?
Actual panic stack showed total different area. It looked like this.
TSTATE: 80e01601 TPC: 007945c8 TNPC: 007945cc Y:
Not tainted
TPC:
g0: 4000 g1: 084001604020 g2: 084001604024 g3:
0acb
g4: 800fe42d0340 g5: 8000291ce000 g6: 800fe42f4000 g7:
03114000
o0: 800fe085d99c o1: 800fe42f4008 o2: 4000 o3:
0001
o4: o5: 0012 sp: 80002047b2b1 ret_pc:
00794540
RPC:
l0: 800fe085d980 l1: c001 l2: 000b l3:
008e7058
l4: 00bd19a8 l5: 00bd6a88 l6: l7:
i0: 800fe085d800 i1: 0016 i2: 800c20c007c3 i3:
f0265f78
i4: feff4748 i5: feff2ff8 i6: 80002047b3d1 i7:
0077adf0
I7:
Call Trace:
[0077adf0] usb_hcd_irq+0x38/0xa0
[004d122c] handle_irq_event_percpu+0x8c/0x204
[004d13d8] handle_irq_event+0x34/0x60
[004d3998] handle_fasteoi_irq+0xdc/0x164
[004d1178] generic_handle_irq+0x24/0x38
[008dce68] handler_irq+0xb8/0xec
[004208b4] tl0_irq5+0x14/0x20
[0042cfac] cpu_idle+0x9c/0x18c
[008d2ad0] after_lock_tlb+0x1b4/0x1cc
[] (null)
While analyzing it from kdump, I saw it stuck in here below.
PID: 5274 TASK: 800fe1198680 CPU: 0 COMMAND: "cat"
#0 [800fe25f6f81] switch_to_pc at 8d725c
#1 [800fe25f70e1] pci_user_read_config_word at 6c4698
#2 [800fe25f71a1] pci_vpd_pci22_wait at 6c4710
#3 [800fe25f7261] pci_vpd_pci22_read at 6c4994
#4 [800fe25f7321] pci_read_vpd at 6c3e90
#5 [800fe25f73d1] read_vpd_attr at 6ccc78
#6 [800fe25f7481] read at 5be478
#7 [800fe25f7531] vfs_read at 54fdb0
#8 [800fe25f75e1] sys_read at 54ff10
#9 [800fe25f76a1] linux_sparc_syscall at 4060f4
TSTATE=0x8082000223 TT=0x16d TPC=0xfc0100295e28 TNPC=0xfc0100295e2c
r0=0x r1=0x0003 r2=0x0020aec0
r3=0x0020aec4 r4=0x0b00 r5=0x033f
r6=0x0001 r7=0xfc0106f0 r24=0x0003
r25=0x0020e000 r26=0x8000 r27=0x
r28=0x r29=0x r30=0x07feffb468d1
r31=0x00105d94
>
> This seems like a defect in the megaraid hardware or firmware. If the
> VPD ROM contains junk, there's no hope that software can read the data
> and figure out how much is safe to read.
Yes this looks like problem with megaraid hardware.
Other day, Myron stowe(myron.st...@gmail.com) reported similar problem with
his setup.
$ lspci -vvv -s 02:00.0
02:00.0 RAID bus controller: LSI Logic / Symbios Logic MegaRAID SAS 2208
[Thunderbolt] (rev 05)
Capabilities: [d0] Vital Product Data
Unknown small resource type 00, will not decode more.
$ cat /sys/devices/pci:00/:00:02.2/:02:00.0/vpd |
od -A x -t x1z -v
00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 ><
*
007ff0 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 ><
008000
>
> I assume VPD is useful for somebody, and I hate to silently disable
> the whole thing. We might want to at least log a note about what
> we're doing.
Sure. Let me know what you think.
>
> Bjorn
>
>> 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.
>>
>> Signed-off-by: Babu Moger
>> Reviewed-by: Khalid Aziz
>> Tested-by: Dmitry Klochkov
>>
>> Orabug: 22104511
>>
>> Changes since v3 -> v4
>> We found some options of the lspci does not work very well if
>> it cannot find the valid vpd tag(Example command "lspci -s 10:00.0 -vv").
>> It displays the error message and exits right away. Setting the length
>> back to 0 fixes the problem.
>>
>> Changes since v
Re: [PATCH v4] pci: Limit VPD length for megaraid_sas adapter
Hi Babu,
On Thu, Dec 03, 2015 at 12:25:19PM -0800, 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
What sort of panic is this?
This seems like a defect in the megaraid hardware or firmware. If the
VPD ROM contains junk, there's no hope that software can read the data
and figure out how much is safe to read.
I assume VPD is useful for somebody, and I hate to silently disable
the whole thing. We might want to at least log a note about what
we're doing.
Bjorn
> 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.
>
> Signed-off-by: Babu Moger
> Reviewed-by: Khalid Aziz
> Tested-by: Dmitry Klochkov
>
> Orabug: 22104511
>
> Changes since v3 -> v4
> We found some options of the lspci does not work very well if
> it cannot find the valid vpd tag(Example command "lspci -s 10:00.0 -vv").
> It displays the error message and exits right away. Setting the length
> back to 0 fixes the problem.
>
> Changes since v2 -> v3
> Changed the vpd length from 0 to 0x80 which leaves the
> option open for someone to read first few bytes.
>
> Changes since v1 -> v2
> Removed the changes in pci_id.h. Kept all the vendor
> ids in quirks.c
> ---
> drivers/pci/quirks.c | 38 ++
> 1 files changed, 38 insertions(+), 0 deletions(-)
>
> diff --git a/drivers/pci/quirks.c b/drivers/pci/quirks.c
> index b03373f..f739e47 100644
> --- a/drivers/pci/quirks.c
> +++ b/drivers/pci/quirks.c
> @@ -2123,6 +2123,44 @@ 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//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.
> + * Also I dont believe vendors have implemented this VPD headers properly.
> + * Atleast I dont see it in following megaraid sas controller.
> + * That is why adding the quirk here.
> + */
> +static void quirk_megaraid_sas_limit_vpd(struct pci_dev *dev)
> +{
> + if (dev->vpd)
> + dev->vpd->len = 0;
> +}
> +
> +DECLARE_PCI_FIXUP_FINAL(PCI_VENDOR_ID_LSI_LOGIC, 0x0060,
> + quirk_megaraid_sas_limit_vpd);
> +DECLARE_PCI_FIXUP_FINAL(PCI_VENDOR_ID_LSI_LOGIC, 0x007c,
> + quirk_megaraid_sas_limit_vpd);
> +DECLARE_PCI_FIXUP_FINAL(PCI_VENDOR_ID_LSI_LOGIC, 0x0413,
> + quirk_megaraid_sas_limit_vpd);
> +DECLARE_PCI_FIXUP_FINAL(PCI_VENDOR_ID_LSI_LOGIC, 0x0078,
> + quirk_megaraid_sas_limit_vpd);
> +DECLARE_PCI_FIXUP_FINAL(PCI_VENDOR_ID_LSI_LOGIC, 0x0079,
> + quirk_megaraid_sas_limit_vpd);
> +DECLARE_PCI_FIXUP_FINAL(PCI_VENDOR_ID_LSI_LOGIC, 0x0073,
> + quirk_megaraid_sas_limit_vpd);
> +DECLARE_PCI_FIXUP_FINAL(PCI_VENDOR_ID_LSI_LOGIC, 0x0071,
> + quirk_megaraid_sas_limit_vpd);
> +DECLARE_PCI_FIXUP_FINAL(PCI_VENDOR_ID_LSI_LOGIC, 0x005b,
> + quirk_megaraid_sas_limit_vpd);
> +DECLARE_PCI_FIXUP_FINAL(PCI_VENDOR_ID_LSI_LOGIC, 0x002f,
> + quirk_megaraid_sas_limit_vpd);
> +DECLARE_PCI_FIXUP_FINAL(PCI_VENDOR_ID_LSI_LOGIC, 0x005d,
> + quirk_megaraid_sas_limit_vpd);
> +DECLARE_PCI_FIXUP_FINAL(PCI_VENDOR_ID_LSI_LOGIC, 0x005f,
> + quirk_megaraid_sas_limit_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
>
> --
> To unsubscribe from this list: send the line "unsubscribe linux-pci" in
> the body of a message to majord...@vger.kernel.org
> More majordomo info at http://vger.kernel.org/majordomo-info.html
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
[PATCH v4] pci: Limit VPD length for megaraid_sas adapter
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.
Signed-off-by: Babu Moger
Reviewed-by: Khalid Aziz
Tested-by: Dmitry Klochkov
Orabug: 22104511
Changes since v3 -> v4
We found some options of the lspci does not work very well if
it cannot find the valid vpd tag(Example command "lspci -s 10:00.0 -vv").
It displays the error message and exits right away. Setting the length
back to 0 fixes the problem.
Changes since v2 -> v3
Changed the vpd length from 0 to 0x80 which leaves the
option open for someone to read first few bytes.
Changes since v1 -> v2
Removed the changes in pci_id.h. Kept all the vendor
ids in quirks.c
---
drivers/pci/quirks.c | 38 ++
1 files changed, 38 insertions(+), 0 deletions(-)
diff --git a/drivers/pci/quirks.c b/drivers/pci/quirks.c
index b03373f..f739e47 100644
--- a/drivers/pci/quirks.c
+++ b/drivers/pci/quirks.c
@@ -2123,6 +2123,44 @@ 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//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.
+ * Also I dont believe vendors have implemented this VPD headers properly.
+ * Atleast I dont see it in following megaraid sas controller.
+ * That is why adding the quirk here.
+ */
+static void quirk_megaraid_sas_limit_vpd(struct pci_dev *dev)
+{
+ if (dev->vpd)
+ dev->vpd->len = 0;
+}
+
+DECLARE_PCI_FIXUP_FINAL(PCI_VENDOR_ID_LSI_LOGIC, 0x0060,
+ quirk_megaraid_sas_limit_vpd);
+DECLARE_PCI_FIXUP_FINAL(PCI_VENDOR_ID_LSI_LOGIC, 0x007c,
+ quirk_megaraid_sas_limit_vpd);
+DECLARE_PCI_FIXUP_FINAL(PCI_VENDOR_ID_LSI_LOGIC, 0x0413,
+ quirk_megaraid_sas_limit_vpd);
+DECLARE_PCI_FIXUP_FINAL(PCI_VENDOR_ID_LSI_LOGIC, 0x0078,
+ quirk_megaraid_sas_limit_vpd);
+DECLARE_PCI_FIXUP_FINAL(PCI_VENDOR_ID_LSI_LOGIC, 0x0079,
+ quirk_megaraid_sas_limit_vpd);
+DECLARE_PCI_FIXUP_FINAL(PCI_VENDOR_ID_LSI_LOGIC, 0x0073,
+ quirk_megaraid_sas_limit_vpd);
+DECLARE_PCI_FIXUP_FINAL(PCI_VENDOR_ID_LSI_LOGIC, 0x0071,
+ quirk_megaraid_sas_limit_vpd);
+DECLARE_PCI_FIXUP_FINAL(PCI_VENDOR_ID_LSI_LOGIC, 0x005b,
+ quirk_megaraid_sas_limit_vpd);
+DECLARE_PCI_FIXUP_FINAL(PCI_VENDOR_ID_LSI_LOGIC, 0x002f,
+ quirk_megaraid_sas_limit_vpd);
+DECLARE_PCI_FIXUP_FINAL(PCI_VENDOR_ID_LSI_LOGIC, 0x005d,
+ quirk_megaraid_sas_limit_vpd);
+DECLARE_PCI_FIXUP_FINAL(PCI_VENDOR_ID_LSI_LOGIC, 0x005f,
+ quirk_megaraid_sas_limit_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
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
