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
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
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
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 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 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 HP,
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 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
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/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=118809338631160=2
>
>
>> It hangs in exactly the same place every time.
>>
>> I am surmising that the write to that BAR is causing a
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-kernelm=118809338631160w=2
It hangs in exactly the same place every time.
I am surmising that the write to that BAR is causing a MCE.
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 seems
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 cmd
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
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
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
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
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
>>
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
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
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
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
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
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
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
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
>>
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
>
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
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
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
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
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
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
>
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
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
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
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
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
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
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
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
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
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
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
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
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]>
>
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,
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]>
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 19,
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]
Robert
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]
References:
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 this
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
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 microtower
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
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
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 different idea
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 writing
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
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
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
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 performance
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 different idea
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
supports
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
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
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
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 combination
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 where
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 all. I
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
believe
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 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
with this
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
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
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
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
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:
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
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
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
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
HyperTransport link.
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
92 matches
Mail list logo
