lkml.org 
[lkml]   [2007]   [Dec]   [27]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
 
Messages in this thread
/
Date
From
SubjectRe: [Patch v2] Make PCI extended config space (MMCONFIG) a driver opt-in
On 12/27/2007 1:58 PM, Linus Torvalds wrote:
>
> There was a thread called "PCI vendor id == 1 regression?" (Kai Ruhnau was
> the main reporter for that one). But looking back, it seems that one
> didn't hit the kernel mailing list, so I guess google cannot pick it up. I
> can forward all the emails if you want, but quite frankly, you don't
> really want to. It boils down to:
>
> Stephen Hemminger:
> "There have been two reports with different hardware of the PCI vendor
> id of 0001 showing up. I got a report on sky2, and Francois saw similar
> problem on r8169.
> In one case, it happened only with 2.6.23 kernel, the correct id was
> returned by older kernels.
>
> This is a heads up, there may be a PCI problem. Or just
> some users smoking strange fall leaves."
>
> And then one of the reporters:
>
> "Good kernel:
>
> 02:00.0 Ethernet controller: Marvell Technology Group Ltd. 88E8056 PCI-E Gigabit Ethernet Controller (rev 12)
> 00: ab 11 64 43 07 00 10 00 12 00 00 02 01 00 00 00
>
> Bad kernel:
>
> 02:00.0 Ethernet controller: Unknown device 0001:4364 (rev 12)
> 00: 01 00 64 43 07 00 10 00 12 00 00 02 01 00 00 00"
>





The root pcie port implementation is obviously buggy. But did we confirm
whether that hardware bug might be partly related to
"configuration-retry-status" pcie-root handling as introduced/described in:



http://marc.info/?l=linux-kernel&m=110541914926842&w=2


Does the 0001 vendor-id still shows up if pci_enable_crs() has never
been called?


Does anybody knows what was the original rational to call
pci_enable_crs() by default?


Loic



\
 
 \ /
  Last update: 2007-12-27 22:15    [W:0.090 / U:1.084 seconds]
©2003-2020 Jasper Spaans|hosted at Digital Ocean and TransIP|Read the blog|Advertise on this site