On Tue, Feb 02, 2010 at 09:42:58PM +0100, Rafael J. Wysocki wrote:
On Monday 01 February 2010, Yinghai Lu wrote:
On 01/31/2010 04:22 PM, Rafael J. Wysocki wrote:
This message has been generated automatically as a part of a report
of recent regressions.
The following bug entry is on
On Tuesday 02 February 2010 01:42:58 pm Rafael J. Wysocki wrote:
On Monday 01 February 2010, Yinghai Lu wrote:
On 01/31/2010 04:22 PM, Rafael J. Wysocki wrote:
This message has been generated automatically as a part of a report
of recent regressions.
The following bug entry is on
This message has been generated automatically as a part of a report
of recent regressions.
The following bug entry is on the current list of known regressions
from 2.6.32. Please verify if it still should be listed and let me know
(either way).
Bug-Entry :
On Wed, Jan 27, 2010 at 09:26:02PM -0700, Bjorn Helgaas wrote:
When ACPI is disabled, I think we just have to accept that we lose some
functionality. I don't see the need for alternate ways to accomplish
everything that ACPI does. It's becoming less and less useful to
disable ACPI; I think
On Thursday 28 January 2010, Yinghai Lu wrote:
On 01/27/2010 08:26 PM, Bjorn Helgaas wrote:
On Wed, 2010-01-27 at 15:34 -0800, Yinghai Lu wrote:
On 01/27/2010 01:03 PM, Bjorn Helgaas wrote:
On Wednesday 27 January 2010 01:50:12 pm Linus Torvalds wrote:
On Wed, 27 Jan 2010, Bjorn Helgaas
On Wed, 27 Jan 2010 22:02:26 -0600
j...@jgarrett.org (Jeff Garrett) wrote:
On Wed, Jan 27, 2010 at 07:24:09PM -0800, Jesse Barnes wrote:
On Wed, 27 Jan 2010 17:50:17 -0800 (PST)
Linus Torvalds torva...@linux-foundation.org wrote:
On Tue, 26 Jan 2010, Yinghai Lu wrote:
[PATCH]
On 01/28/2010 08:09 AM, Bjorn Helgaas wrote:
On Wednesday 27 January 2010 10:53:51 pm Yinghai Lu wrote:
On 01/27/2010 08:26 PM, Bjorn Helgaas wrote:
On Wed, 2010-01-27 at 15:34 -0800, Yinghai Lu wrote:
2. how about when apci is disabled?
When ACPI is disabled, I think we just have to
On Thu, 28 Jan 2010 10:20:04 -0800
Yinghai Lu ying...@kernel.org wrote:
On 01/28/2010 08:09 AM, Bjorn Helgaas wrote:
On Wednesday 27 January 2010 10:53:51 pm Yinghai Lu wrote:
On 01/27/2010 08:26 PM, Bjorn Helgaas wrote:
On Wed, 2010-01-27 at 15:34 -0800, Yinghai Lu wrote:
2. how
On Thursday 28 January 2010 11:20:04 am Yinghai Lu wrote:
On 01/28/2010 08:09 AM, Bjorn Helgaas wrote:
On Wednesday 27 January 2010 10:53:51 pm Yinghai Lu wrote:
On 01/27/2010 08:26 PM, Bjorn Helgaas wrote:
On Wed, 2010-01-27 at 15:34 -0800, Yinghai Lu wrote:
2. how about when apci is
On Thursday 28 January 2010, Jesse Barnes wrote:
On Thu, 28 Jan 2010 10:20:04 -0800
Yinghai Lu ying...@kernel.org wrote:
On 01/28/2010 08:09 AM, Bjorn Helgaas wrote:
On Wednesday 27 January 2010 10:53:51 pm Yinghai Lu wrote:
On 01/27/2010 08:26 PM, Bjorn Helgaas wrote:
On Wed,
On Thursday 28 January 2010 11:20:04 am Yinghai Lu wrote:
On 01/28/2010 08:09 AM, Bjorn Helgaas wrote:
On Wednesday 27 January 2010 10:53:51 pm Yinghai Lu wrote:
We should fix that problem rather than just covering it up by
disabling ACPI. Can you provide any details?
that is not covering
On Wed, 27 Jan 2010, Bjorn Helgaas wrote:
Without intel_bus.c, we essentially assume config 1 all the time.
If we keep intel_bus.c and this patch for .33, things should work
for configs 1 and 4. Adding support for config 4 is good.
Quite frankly, is there any major downside to just
On Wed, 27 Jan 2010 12:50:12 -0800 (PST)
Linus Torvalds torva...@linux-foundation.org wrote:
On Wed, 27 Jan 2010, Bjorn Helgaas wrote:
Without intel_bus.c, we essentially assume config 1 all the time.
If we keep intel_bus.c and this patch for .33, things should work
for configs 1
On Wed, 27 Jan 2010 12:59:05 -0800
Jesse Barnes jbar...@virtuousgeek.org wrote:
On Wed, 27 Jan 2010 12:50:12 -0800 (PST)
Linus Torvalds torva...@linux-foundation.org wrote:
On Wed, 27 Jan 2010, Bjorn Helgaas wrote:
Without intel_bus.c, we essentially assume config 1 all the
On Wednesday 27 January 2010 01:50:12 pm Linus Torvalds wrote:
On Wed, 27 Jan 2010, Bjorn Helgaas wrote:
Without intel_bus.c, we essentially assume config 1 all the time.
If we keep intel_bus.c and this patch for .33, things should work
for configs 1 and 4. Adding support for config 4
On 01/27/2010 01:03 PM, Bjorn Helgaas wrote:
On Wednesday 27 January 2010 01:50:12 pm Linus Torvalds wrote:
On Wed, 27 Jan 2010, Bjorn Helgaas wrote:
Without intel_bus.c, we essentially assume config 1 all the time.
If we keep intel_bus.c and this patch for .33, things should work
for
On 01/27/2010 01:02 PM, Jesse Barnes wrote:
On Wed, 27 Jan 2010 12:59:05 -0800
Jesse Barnes jbar...@virtuousgeek.org wrote:
On Wed, 27 Jan 2010 12:50:12 -0800 (PST)
Linus Torvalds torva...@linux-foundation.org wrote:
On Wed, 27 Jan 2010, Bjorn Helgaas wrote:
Without intel_bus.c, we
On Tue, 26 Jan 2010, Yinghai Lu wrote:
[PATCH] x86/pci: don't use ioh resource if only have one ioh
Please, no.
This patch is too ugly to live.
And it's totally unacceptable to probe every single possible PCI device
for something like this.
If we don't know enough about the hardware
On Wed, 27 Jan 2010 17:50:17 -0800 (PST)
Linus Torvalds torva...@linux-foundation.org wrote:
On Tue, 26 Jan 2010, Yinghai Lu wrote:
[PATCH] x86/pci: don't use ioh resource if only have one ioh
Please, no.
This patch is too ugly to live.
And it's totally unacceptable to probe
On Wed, Jan 27, 2010 at 05:35:50PM -0800, Jesse Barnes wrote:
On Tue, 26 Jan 2010 14:57:31 -0800
Yinghai Lu ying...@kernel.org wrote:
On 01/26/2010 10:17 AM, Jesse Barnes wrote:
For 2.6.33 I'd like a minimal fix though, can you disable it for all
but the multi-IOH case perhaps?
On 01/27/2010 08:26 PM, Bjorn Helgaas wrote:
On Wed, 2010-01-27 at 15:34 -0800, Yinghai Lu wrote:
On 01/27/2010 01:03 PM, Bjorn Helgaas wrote:
On Wednesday 27 January 2010 01:50:12 pm Linus Torvalds wrote:
On Wed, 27 Jan 2010, Bjorn Helgaas wrote:
Without intel_bus.c, we essentially assume
On Tuesday 26 January 2010, Jeff Garrett wrote:
On Sun, Jan 24, 2010 at 11:04:38PM +0100, Rafael J. Wysocki wrote:
This message has been generated automatically as a part of a report
of recent regressions.
The following bug entry is on the current list of known regressions
from 2.6.32.
On Tuesday 26 January 2010 05:48:59 am Rafael J. Wysocki wrote:
On Tuesday 26 January 2010, Jeff Garrett wrote:
On Sun, Jan 24, 2010 at 11:04:38PM +0100, Rafael J. Wysocki wrote:
The following bug entry is on the current list of known regressions
from 2.6.32. Please verify if it still
On Tuesday 26 January 2010, Bjorn Helgaas wrote:
On Tuesday 26 January 2010 05:48:59 am Rafael J. Wysocki wrote:
On Tuesday 26 January 2010, Jeff Garrett wrote:
On Sun, Jan 24, 2010 at 11:04:38PM +0100, Rafael J. Wysocki wrote:
The following bug entry is on the current list of known
On Tue, 26 Jan 2010, Bjorn Helgaas wrote:
which IS big enough, and we know the bridge is in fact forwarding the
[mem 0xd000-0xdfff 64bit pref] region, because the Radeon works
when Jeff boots with pci=use_crs.
I bet it's a subtractive decode thing. Sure, it could be just another
On Tue, 26 Jan 2010 19:02:13 +0100
Rafael J. Wysocki r...@sisk.pl wrote:
I'm quite concerned about this for .33 because I don't think Jeff's
configuration (Dell desktop with Intel x58 and large graphics device)
is unusual.
The benefit of intel_bus.c is on machines with multiple IOHs,
On 01/26/2010 10:16 AM, Linus Torvalds wrote:
On Tue, 26 Jan 2010, Bjorn Helgaas wrote:
which IS big enough, and we know the bridge is in fact forwarding the
[mem 0xd000-0xdfff 64bit pref] region, because the Radeon works
when Jeff boots with pci=use_crs.
I bet it's a
On Tue, 26 Jan 2010, Rafael J. Wysocki wrote:
Perhaps it would be sufficient to make pci=use_crs the default and leave the
option to use intel_bus.c for whoever needs that?
Well, 'use_crs' broke other machines. See:
http://lkml.org/lkml/2009/6/23/715
but maybe that is all fixed..
On Tue, 26 Jan 2010 10:21:29 -0800
Yinghai Lu ying...@kernel.org wrote:
On 01/26/2010 10:16 AM, Linus Torvalds wrote:
On Tue, 26 Jan 2010, Bjorn Helgaas wrote:
which IS big enough, and we know the bridge is in fact forwarding the
[mem 0xd000-0xdfff 64bit pref] region,
On 01/26/2010 10:17 AM, Jesse Barnes wrote:
For 2.6.33 I'd like a minimal fix though, can you disable it for all
but the multi-IOH case perhaps?
please check,
[PATCH] x86/pci: don't use ioh resource if only have one ioh
some system could use reosurce out of IOH resources when only one ioh
30 matches
Mail list logo
