Re: [Bug #15124] PCI host bridge windows ignored (works with pci=use_crs)

2010-01-28 Thread Rafael J. Wysocki 
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 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 disabling/removing 
  intel_bus.c for 2.6.33? If we're not planning on having it in the long 
  run 
  anyway - or even if we are, but we can't be really happy about the state 
  of it as it would be in 2.6.33, not using it at all seems to be the 
  smaller headache.
 
  The machines that it helps are also the machines where you can fix 
  things 
  up with 'use_csr', no? And they are pretty rare, and they didn't use to 
  work without that use_csr in 2.6.32 either, so it's not even a 
  regression.
 
  Am I missing something?
 
  Only that when we added intel_bus.c, Yinghai reported that the reason
  was because a machine had a broken _CRS, so pci=use_crs wouldn't help.
 
  At the time, Windows hadn't been brought up on that box.  My
  speculation is that by now, they've done that bringup and probably
  fixed the _CRS issue, so it might work now.
 
  If that's the case, we could drop intel_bus.c from .33 and just use
  pci=use_crs on those boxes until we can figure out how to turn it
  on automatically.
 
  BIOS fixed that problem already. but
  1. how to turn that pci=use_crs for that box automatically ?
  how about our other kind of boxes?
  
  Yes, we need a way to turn on pci=use_crs automatically.  My first
  thought is to turn it on for all BIOSes with dates of 2010 or later, and
  in addition, have a whitelist of the pre-2010 machines that require it.
  
  2. how about when apci is disabled?
  
  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 it's only interesting as a debugging tool, and
  even then it's a sledgehammer.
 
 some systems when acpi is enabled could have interrupt storm. 
 and have to disable acpi.

Blacklist them?

Rafael
--
To unsubscribe from this list: send the line unsubscribe kernel-testers in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: [Bug #15124] PCI host bridge windows ignored (works with pci=use_crs)

2010-01-28 Thread Jesse Barnes 
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] 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 workings of those Intel 
   bridges 
   to know when they are active and how they decode things, then please 
   let's 
   just disable intel_bus.c entirely.
   
   There's no excuse for hacky tests like this.
  
  Ok, we'll just kill it entirely then.  I'll send a patch tomorrow
  unless Yinghai beats me to it.
 
 What about something like this (works for me, without pci=use_crs)?
 
 ---
 Remove intel_bus.c Intel-specific PCI/IOH logic
 
 Signed-off-by: Jeff Garrett j...@jgarrett.org

Yeah, looks good.  I'll push to Linus today.

Thanks,
Jesse

-- 
Jesse Barnes, Intel Open Source Technology Center
--
To unsubscribe from this list: send the line unsubscribe kernel-testers in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: [Bug #15124] PCI host bridge windows ignored (works with pci=use_crs)

2010-01-28 Thread Yinghai Lu 
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 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 it's only interesting as a debugging tool, and
 even then it's a sledgehammer.

 some systems when acpi is enabled could have interrupt storm. 
 and have to disable acpi.
 
 We should fix that problem rather than just covering it up by
 disabling ACPI.  Can you provide any details?
that is not covering problem. acpi just cause too many problems.

systems using acpi hotplug support, and use acpi aml code to monitor the 
hotplug status instead of HW
and after one or two days will have interrupt storm with sci/acpi interrupt aka 
9.
 
 I think it's crazy to add code to work around Problem B that only
 occurs because we disabled ACPI to work around Problem A.  We should
 just fix Problem A instead.

that is not point. fix BIOS or HW or OS?

check many systems have broken acpi?
some system acpi code even clear pci bar when just enable acpi at the first 
point.

YH
--
To unsubscribe from this list: send the line unsubscribe kernel-testers in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

[PATCH] x86/pci: print ioh resources only

2010-01-28 Thread Yinghai Lu 

don't use them for peer pci root bus resource yet.
so could cross check _CRS results

Signed-off-by: Yinghai Lu ying...@kernel.org

---
 arch/x86/pci/intel_bus.c |   24 
 1 file changed, 8 insertions(+), 16 deletions(-)

Index: linux-2.6/arch/x86/pci/intel_bus.c
===
--- linux-2.6.orig/arch/x86/pci/intel_bus.c
+++ linux-2.6/arch/x86/pci/intel_bus.c
@@ -43,7 +43,7 @@ static void __devinit pci_root_bus_res(s
 {
u16 word;
u32 dword;
-   struct pci_root_info *info;
+   struct pci_root_info info;
u16 io_base, io_end;
u32 mmiol_base, mmiol_end;
u64 mmioh_base, mmioh_end;
@@ -53,30 +53,22 @@ static void __devinit pci_root_bus_res(s
if (dev-cfg_size  0x120)
return;
 
-   if (pci_root_num = PCI_ROOT_NR) {
-   printk(KERN_DEBUG intel_bus.c: PCI_ROOT_NR is too small\n);
-   return;
-   }
-
-   info = pci_root_info[pci_root_num];
-   pci_root_num++;
-
pci_read_config_word(dev, IOH_LCFGBUS, word);
bus_base = (word  0xff);
bus_end = (word  0xff00)  8;
-   sprintf(info-name, PCI Bus #%02x, bus_base);
-   info-bus_min = bus_base;
-   info-bus_max = bus_end;
+   sprintf(info.name, PCI Bus #%02x, bus_base);
+   info.bus_min = bus_base;
+   info.bus_max = bus_end;
 
pci_read_config_word(dev, IOH_LIO, word);
io_base = (word  0xf0)  (12 - 4);
io_end = (word  0xf000) | 0xfff;
-   update_res(info, io_base, io_end, IORESOURCE_IO, 0);
+   update_res(info, io_base, io_end, IORESOURCE_IO, 0);
 
pci_read_config_dword(dev, IOH_LMMIOL, dword);
mmiol_base = (dword  0xff00)  (24 - 8);
mmiol_end = (dword  0xff00) | 0xff;
-   update_res(info, mmiol_base, mmiol_end, IORESOURCE_MEM, 0);
+   update_res(info, mmiol_base, mmiol_end, IORESOURCE_MEM, 0);
 
pci_read_config_dword(dev, IOH_LMMIOH, dword);
mmioh_base = ((u64)(dword  0xfc00))  (26 - 10);
@@ -85,9 +77,9 @@ static void __devinit pci_root_bus_res(s
mmioh_base |= ((u64)(dword  0x7))  32;
pci_read_config_dword(dev, IOH_LMMIOH_LIMITU, dword);
mmioh_end |= ((u64)(dword  0x7))  32;
-   update_res(info, mmioh_base, mmioh_end, IORESOURCE_MEM, 0);
+   update_res(info, mmioh_base, mmioh_end, IORESOURCE_MEM, 0);
 
-   print_ioh_resources(info);
+   print_ioh_resources(info);
 }
 
 /* intel IOH */
--
To unsubscribe from this list: send the line unsubscribe kernel-testers in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: [PATCH] x86/pci: print ioh resources only

2010-01-28 Thread Linus Torvalds 


On Thu, 28 Jan 2010, Yinghai Lu wrote:
 @@ -43,7 +43,7 @@ static void __devinit pci_root_bus_res(s
  {
   u16 word;
   u32 dword;
 - struct pci_root_info *info;
 + struct pci_root_info info;

That structure is something like a kilobyte in size, please don't put 
those things on the stack (sixteen struct resource entries).

Linus
--
To unsubscribe from this list: send the line unsubscribe kernel-testers in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: [Bug #15124] PCI host bridge windows ignored (works with pci=use_crs)

2010-01-28 Thread Jesse Barnes 
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 about when apci is disabled?
 
  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 it's only interesting as a
  debugging tool, and even then it's a sledgehammer.
 
  some systems when acpi is enabled could have interrupt storm. 
  and have to disable acpi.
  
  We should fix that problem rather than just covering it up by
  disabling ACPI.  Can you provide any details?
 that is not covering problem. acpi just cause too many problems.
 
 systems using acpi hotplug support, and use acpi aml code to monitor
 the hotplug status instead of HW and after one or two days will have
 interrupt storm with sci/acpi interrupt aka 9.


But disabling it gets us into trouble too.  When platforms are designed
for Linux, they may be designed to have ACPI disabled (though this is
probably rare for general purpose PCs and servers).  However when
they're designed for Windows, they're generally designed to use ACPI,
so if we disable it we run the risk of hitting all sorts of bugs since
we're running in an untested configuration.

So fixing the issues with ACPI enabled seems like a better idea; after
all, presumably Windows works on this platform with ACPI enabled, why
shouldn't we?

But I'm speaking in general here; we'd have to dig into the details of
the particular problem you mention to figure out the best course of
action (but I'm still pretty sure it's not disable ACPI).

-- 
Jesse Barnes, Intel Open Source Technology Center
--
To unsubscribe from this list: send the line unsubscribe kernel-testers in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

[PATCH -v2] x86/pci: print ioh resources only

2010-01-28 Thread Yinghai Lu 

don't use them for peer pci root bus resource yet.
so could cross check _CRS results

-v2: dont put info struct in stack according to Linus.
 because that is kbytes big

Signed-off-by: Yinghai Lu ying...@kernel.org

---
 arch/x86/pci/intel_bus.c |8 ++--
 1 file changed, 2 insertions(+), 6 deletions(-)

Index: linux-2.6/arch/x86/pci/intel_bus.c
===
--- linux-2.6.orig/arch/x86/pci/intel_bus.c
+++ linux-2.6/arch/x86/pci/intel_bus.c
@@ -53,13 +53,9 @@ static void __devinit pci_root_bus_res(s
if (dev-cfg_size  0x120)
return;
 
-   if (pci_root_num = PCI_ROOT_NR) {
-   printk(KERN_DEBUG intel_bus.c: PCI_ROOT_NR is too small\n);
+   info = kmalloc(sizeof(struct pci_root_info), GFP_KERNEL);
+   if (!info)
return;
-   }
-
-   info = pci_root_info[pci_root_num];
-   pci_root_num++;
 
pci_read_config_word(dev, IOH_LCFGBUS, word);
bus_base = (word  0xff);
--
To unsubscribe from this list: send the line unsubscribe kernel-testers in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: [PATCH -v2] x86/pci: print ioh resources only

2010-01-28 Thread Olivier Galibert 
On Thu, Jan 28, 2010 at 11:10:14AM -0800, Yinghai Lu wrote:
 
 don't use them for peer pci root bus resource yet.
 so could cross check _CRS results
 
 -v2: dont put info struct in stack according to Linus.
  because that is kbytes big

No kfree?

  OG.
--
To unsubscribe from this list: send the line unsubscribe kernel-testers in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: [Bug #15124] PCI host bridge windows ignored (works with pci=use_crs)

2010-01-28 Thread Bjorn Helgaas 
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 disabled?
 
  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 it's only interesting as a debugging tool, and
  even then it's a sledgehammer.
 
  some systems when acpi is enabled could have interrupt storm. 
  and have to disable acpi.
  
  We should fix that problem rather than just covering it up by
  disabling ACPI.  Can you provide any details?
 that is not covering problem. acpi just cause too many problems.
 
 systems using acpi hotplug support, and use acpi aml code to monitor the 
 hotplug status instead of HW
 and after one or two days will have interrupt storm with sci/acpi interrupt 
 aka 9.

If you just want to whine about problems without helping us figure
them out and fix them, I think there's another mailing list for that.

I really don't have time to deal with unsubstantiated rumor-mongering
like this.

Bjorn
--
To unsubscribe from this list: send the line unsubscribe kernel-testers in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: [Bug #15124] PCI host bridge windows ignored (works with pci=use_crs)

2010-01-28 Thread Rafael J. Wysocki 
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, 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 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 it's only interesting as a
   debugging tool, and even then it's a sledgehammer.
  
   some systems when acpi is enabled could have interrupt storm. 
   and have to disable acpi.
   
   We should fix that problem rather than just covering it up by
   disabling ACPI.  Can you provide any details?
  that is not covering problem. acpi just cause too many problems.
  
  systems using acpi hotplug support, and use acpi aml code to monitor
  the hotplug status instead of HW and after one or two days will have
  interrupt storm with sci/acpi interrupt aka 9.
 
 
 But disabling it gets us into trouble too.  When platforms are designed
 for Linux, they may be designed to have ACPI disabled (though this is
 probably rare for general purpose PCs and servers).

Well, not quite.  On recent SMP systems it's next to impossible to get all of
the necessary system configuration information without ACPI, since it only is
provided by the ACPI tables (the configuration of APICs, interrupt routing,
CPU C states, other stuff).

[BTW, I think it's better to CC linux-acpi and Len at this point.]

 However when they're designed for Windows, they're generally designed to use
 ACPI, so if we disable it we run the risk of hitting all sorts of bugs since
 we're running in an untested configuration.

I guess without ACPI we're guaranteed to run into troubles on many modern
hardware configurations.

 So fixing the issues with ACPI enabled seems like a better idea; after
 all, presumably Windows works on this platform with ACPI enabled, why
 shouldn't we?
 
 But I'm speaking in general here; we'd have to dig into the details of
 the particular problem you mention to figure out the best course of
 action (but I'm still pretty sure it's not disable ACPI).

Agreed.

Rafael
--
To unsubscribe from this list: send the line unsubscribe kernel-testers in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: [Bug #15124] PCI host bridge windows ignored (works with pci=use_crs)

2010-01-28 Thread Bjorn Helgaas 
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 problem. acpi just cause too many problems.
 
 systems using acpi hotplug support, and use acpi aml code to monitor the 
 hotplug status instead of HW
 and after one or two days will have interrupt storm with sci/acpi interrupt 
 aka 9.
 ...
 check many systems have broken acpi?
 some system acpi code even clear pci bar when just enable acpi at the first 
 point.

Sorry, let me try to be more constructive.  You mention some things
above that might be issues with Linux.  I am eager to help fix them.

However, to make progress, I need information, not just rumors.  Can
you point me to bug reports?  Bugzillas?  Ways to reproduce the
problems?

Bjorn
--
To unsubscribe from this list: send the line unsubscribe kernel-testers in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html