On Thu, 2007-12-20 at 22:50 +0300, Ivan Kokshaysky wrote:
> Use type 1 just for the first 64 bytes and tg3 will be happy. All we need
> is to avoid touching BARs with mmconfig.
>
> Ivan.
I've tried Ivan's suggestion, and it works.
The patch is appended below.
My question is, do we want to in
Loic Prylli wrote:
I just realized one thing: the bar sizing code in pci_read_bases() (that
writes 0x in the bars) does not seem to disable the
PCI_COMMAND_MEM/PCI_COMMAND_IO bits in the cmd register before
manipulating the BARs. And it seems nobody else ensures they are
disabled at this
On Thu, Dec 20, 2007 at 02:40:06PM -0800, Greg KH wrote:
> Sure, I realize this, but it solves the problem in one way for broken
> hardware, such that it at least allows it to work, right? It also
> provides a better incentive for the manufacturer to fix their bios,
> which as you are on-site at H
On Sun, Dec 23, 2007 at 03:16:24PM -0500, Loic Prylli wrote:
...
> I just realized one thing: the bar sizing code in pci_read_bases() (that
> writes 0x in the bars) does not seem to disable the
> PCI_COMMAND_MEM/PCI_COMMAND_IO bits in the cmd register before
> manipulating the BARs. And it
On 12/23/2007 3:55 PM, Matthew Wilcox wrote:
> On Sun, Dec 23, 2007 at 03:16:24PM -0500, Loic Prylli wrote:
>
>> I just realized one thing: the bar sizing code in pci_read_bases() (that
>> writes 0x in the bars) does not seem to disable the
>> PCI_COMMAND_MEM/PCI_COMMAND_IO bits in the c
On Sun, Dec 23, 2007 at 03:16:24PM -0500, Loic Prylli wrote:
> I just realized one thing: the bar sizing code in pci_read_bases() (that
> writes 0x in the bars) does not seem to disable the
> PCI_COMMAND_MEM/PCI_COMMAND_IO bits in the cmd register before
> manipulating the BARs. And it seem
On 12/20/2007 1:16 PM, Matthew Wilcox wrote:
> Oh, that's the same bug others (including me) have been complaining
> about.
>
> http://marc.info/?l=linux-kernel&m=118809338631160&w=2
>
>
>> It hangs in exactly the same place every time.
>>
>> I am surmising that the write to that BAR is causin
Loic Prylli wrote:
On 12/20/2007 6:21 PM, Tony Camuso wrote:
And the MMCONFIG problem with enterprise systems and workstations, where
we do control the BIOS (for the most part), is due to known bugs in
certain versions of certain chipsets, HT1000, AMD8132, among them, not
the BIOS.
The lack
Tony Camuso wrote:
Robert Hancock wrote:
First off, I would like to see confirmation from the horses's mouths
here (namely AMD, ServerWorks/Broadcom, and whoever else) that there
is no other way to get around this problem than disabling MMCONFIG
for accesses behind those chips.
And here
Robert Hancock <[EMAIL PROTECTED]> writes:
> First off, I would like to see confirmation from the horses's mouths
> here (namely AMD,
AMD publicly releases errata sheets/data sheets for their PCI bridges
(check their website). I haven't checked the 8132 errata for this
though. Not sure it implem
Loic Prylli wrote:
Just curious, do you know of any system where that recommendation was
not followed? On all motherboards where I have seen a AMD-8131 or a
AMD-8132, they were alone on their hypertransport link, and other
"northbridges" (more precisely hypertransport to pci-express or
pci-whate
On 12/20/2007 9:15 PM, Robert Hancock wrote:
>>
>> Suggested Workaround
>>
>> It is strongly recommended that system designers do not connect the
>> AMD-8132 and devices that use extended
>> configuration space MMIO BARs (ex: HyperTransport-to-PCI Express®
>> bridges) to the same processor
>> Hyper
Robert Hancock wrote:
I have to wonder why certain system
designers then didn't follow their strong recommendation..
I don't think I want to go there.
I used to be a hardware/firmware guy.
:D :D
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a messa
Tony Camuso wrote:
Robert Hancock wrote:
First off, I would like to see confirmation from the horses's mouths
here (namely AMD, ServerWorks/Broadcom, and whoever else) that there
is no other way to get around this problem than disabling MMCONFIG for
accesses behind those chips.
I happen t
Robert Hancock wrote:
The case of the device built into the K8 northbridge that's unreachable
by MMCONFIG kind of makes sense, since the northbridge is what's
translating the MMCONFIG memory access into config accesses. It seems
bizarre to me that a bridge chip could possibly have such a probl
On 12/20/2007 6:21 PM, Tony Camuso wrote:
>
> And the MMCONFIG problem with enterprise systems and workstations, where
> we do control the BIOS (for the most part), is due to known bugs in
> certain versions of certain chipsets, HT1000, AMD8132, among them, not
> the BIOS.
The lack of MMCONFIG
Robert Hancock wrote:
First off, I would like to see confirmation from the horses's mouths
here (namely AMD, ServerWorks/Broadcom, and whoever else) that there
is no other way to get around this problem than disabling MMCONFIG for
accesses behind those chips.
And here are the excerpts fro
Robert Hancock wrote:
First off, I would like to see confirmation from the horses's mouths
here (namely AMD, ServerWorks/Broadcom, and whoever else) that there is
no other way to get around this problem than disabling MMCONFIG for
accesses behind those chips.
I happen to have this one stor
Tony Camuso wrote:
Greg KH wrote:
Sure, I realize this, but it solves the problem in one way for broken
hardware, such that it at least allows it to work, right? It also
provides a better incentive for the manufacturer to fix their bios,
which as you are on-site at HP, it would seem odd that t
Greg KH wrote:
Sure, I realize this, but it solves the problem in one way for broken
hardware, such that it at least allows it to work, right? It also
provides a better incentive for the manufacturer to fix their bios,
which as you are on-site at HP, it would seem odd that they would just
not d
On Thu, Dec 20, 2007 at 05:36:43PM -0500, Tony Camuso wrote:
> Greg KH wrote:
>> On Thu, Dec 20, 2007 at 01:25:57PM -0500, Tony Camuso wrote:
>> Any reason why these changes were never submitted to the upstream kernel
>> versions? Or do you all just want to keep patching your newer releases
>> wit
Greg KH wrote:
On Thu, Dec 20, 2007 at 01:25:57PM -0500, Tony Camuso wrote:
Any reason why these changes were never submitted to the upstream kernel
versions? Or do you all just want to keep patching your newer releases
with this information forever? :)
I really don't know why these changes
On Thu, Dec 20, 2007 at 01:25:57PM -0500, Tony Camuso wrote:
> Appended below is a code snippet embedded in the RHEL version of
> mmconfig.c,
> for both i386 and x86_64. It does not encompass all the systems that have
> (or will have) problems with mmconf. Only HP platforms are listed, but I
> bel
On 12/20/2007 4:00 PM, Matthew Wilcox wrote:
> On Thu, Dec 20, 2007 at 03:56:29PM -0500, Loic Prylli wrote:
>
>> I know the final device is not aware on how the config request was
>> originated. I am just saying platforms built around the Intel 82801
>> chipset (ICH2) don't support mmconfig at a
On Thu, Dec 20, 2007 at 03:56:29PM -0500, Loic Prylli wrote:
> I know the final device is not aware on how the config request was
> originated. I am just saying platforms built around the Intel 82801
> chipset (ICH2) don't support mmconfig at all. I would also not be
> surprised if the platforms wh
On 12/20/2007 3:15 PM, Matthew Wilcox wrote:
> On Thu, Dec 20, 2007 at 03:05:52PM -0500, Loic Prylli wrote:
>
>> I am not familiar with the tg3 driver, just trying to give a 5 minutes
>> look, it seems the typical cases where the pci-conf-space is used
>> intensively are with some rev in combina
Ivan Kokshaysky wrote:
Use type 1 just for the first 64 bytes and tg3 will be happy. All we need
is to avoid touching BARs with mmconfig.
Ivan.
Re-thinking this ...
The problem I see with this approach is that it does not help devices
that are mmconfig-unfriendly and will not work above the
Ivan Kokshaysky wrote:
On Thu, Dec 20, 2007 at 12:08:33PM -0700, Matthew Wilcox wrote:
On Thu, Dec 20, 2007 at 02:04:31PM -0500, Tony Camuso wrote:
Does anybody see a down side to this?
It'll be slower than it would be if we used mmconfig directly. Now yes,
nobody should be using pci config s
Matthew Wilcox wrote:
Here's how BARs work ... when you write 0x to the BAR, it
ignores all the set bits that are less than the size of the BAR. So,
assuming this is a 256MB BAR (like my G33 is), what ends up written to
this BAR is 0xf000. Now, because this is graphics, apparently
On Thu, Dec 20, 2007 at 03:05:52PM -0500, Loic Prylli wrote:
> I am not familiar with the tg3 driver, just trying to give a 5 minutes
> look, it seems the typical cases where the pci-conf-space is used
> intensively are with some rev in combination with the 82801
> (TG3_FLG2_ICH_WORKAROUND) which I
On 12/20/2007 2:08 PM, Matthew Wilcox wrote:
> On Thu, Dec 20, 2007 at 02:04:31PM -0500, Tony Camuso wrote:
>
>> Also, this solution also would allow us to remove the unreachable_devices()
>> routine and bitmap.
>>
>
> Not really ... we probe reading address 0x100 to see if the device
> sup
On Thu, Dec 20, 2007 at 02:37:49PM -0500, Tony Camuso wrote:
> Matthew Wilcox wrote:
>
> >Bad deduction. What's happening is that the write to the BAR is causing
> >it to overlap the decode for mmconfig space. So the mmconfig write to
> >set the BAR back never gets through.
> >
> >I have a diffe
On Thu, Dec 20, 2007 at 12:08:33PM -0700, Matthew Wilcox wrote:
> On Thu, Dec 20, 2007 at 02:04:31PM -0500, Tony Camuso wrote:
> > Does anybody see a down side to this?
>
> It'll be slower than it would be if we used mmconfig directly. Now yes,
> nobody should be using pci config space in perform
Matthew Wilcox wrote:
Bad deduction. What's happening is that the write to the BAR is causing
it to overlap the decode for mmconfig space. So the mmconfig write to
set the BAR back never gets through.
I have a different idea to fix this problem. Instead of writing
0x, we could look f
On Thu, Dec 20, 2007 at 02:04:31PM -0500, Tony Camuso wrote:
> Also, this solution also would allow us to remove the unreachable_devices()
> routine and bitmap.
Not really ... we probe reading address 0x100 to see if the device
supports extended config space or not. So we need to make that fail
g
Loic Prylli wrote:
Always using type 1 for accesses below 256 bytes looks like a very very
attractive solution
I know we had a lot of older kernels over the last two years that we
patched like that (we needed MMCONFIG for our own device development
purposes, but we also needed our machines to b
On 12/20/2007 1:16 PM, Matthew Wilcox wrote:
>
> Bad deduction. What's happening is that the write to the BAR is causing
> it to overlap the decode for mmconfig space. So the mmconfig write to
> set the BAR back never gets through.
>
> I have a different idea to fix this problem. Instead of wri
On Thu, Dec 20, 2007 at 01:30:16PM -0500, Tony Camuso wrote:
> Matthew Wilcox wrote:
>
> >Bad deduction. What's happening is that the write to the BAR is causing
> >it to overlap the decode for mmconfig space. So the mmconfig write to
> >set the BAR back never gets through.
> >
> >I have a diffe
Matthew Wilcox wrote:
Bad deduction. What's happening is that the write to the BAR is causing
it to overlap the decode for mmconfig space. So the mmconfig write to
set the BAR back never gets through.
I have a different idea to fix this problem. Instead of writing
0x, we could look f
Greg KH wrote:
Why haven't we gotten reports about this before if this is a common
problem?
And why hasn't the vendor fixed the bios on these to work properly?
I can't really answer either of these questions. All I know is the
problem exists, and we need to deal with it.
That's why the unrea
On Thu, Dec 20, 2007 at 01:04:09PM -0500, Tony Camuso wrote:
> Sorry, that was the 82Q963/Q965 graphics controller, PCI ID 2992.
>
> I can't remember why I thought PCI ID 2992 maps to 830M/MG. I think
> it was in some intel doc about the ICH8 or ICH9.
>
> Nevertheless, I have an hp dc5700 microto
Matthew Wilcox wrote:
On Thu, Dec 20, 2007 at 09:22:05AM -0800, Greg KH wrote:
I can't imagine there are too many machines with MMCONFIG and an i830
chipset. The laptop I'm currently typing on is an i830 ... and its
BIOS is from 2002, well predating the specification of MMCONFIG. If I
didn't kn
On Thu, Dec 20, 2007 at 09:22:05AM -0800, Greg KH wrote:
> > The one device we know about that throws exceptions is the 830M/MG
> > graphics chip. This chip passes the read-compare test, so the code
> > merrily advances to bus sizing. When the bus sizing code writes the
> > BAR at offset 0x18 in th
On Thu, Dec 20, 2007 at 07:28:00AM -0500, Tony Camuso wrote:
>
>
> Original Message
> Subject: Re: [PATCH 0/5]PCI: x86 MMCONFIG
> Date: Wed, 19 Dec 2007 19:33:45 -0500
> From: Tony Camuso <[EMAIL PROTECTED]>
> Reply-To: [EMAIL PROTECTED]
> To: Greg KH <[EMAIL PROTECTED]>
> Referen
Original Message
Subject: Re: [PATCH 0/5]PCI: x86 MMCONFIG
Date: Wed, 19 Dec 2007 19:33:45 -0500
From: Tony Camuso <[EMAIL PROTECTED]>
Reply-To: [EMAIL PROTECTED]
To: Greg KH <[EMAIL PROTECTED]>
References:
<[EMAIL PROTECTED]>
<[EMAIL PROTECTED]>
Greg KH wrote:
On Wed, Dec
Original Message
Subject: Re: [PATCH 0/5]PCI: x86 MMCONFIG
Date: Wed, 19 Dec 2007 19:44:13 -0500
From: Tony Camuso <[EMAIL PROTECTED]>
Reply-To: [EMAIL PROTECTED]
To: Robert Hancock <[EMAIL PROTECTED]>
References: <[EMAIL PROTECTED]>
<[EMAIL PROTECTED]> <[EMAIL PROTECTED]>
R
46 matches
Mail list logo
