Re: [Bug #15124] PCI host bridge windows ignored (works with pci=use_crs)
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 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 : http://bugzilla.kernel.org/show_bug.cgi?id=15124 Subject : PCI host bridge windows ignored (works with pci=use_crs) Submitter : Jeff Garrett j...@jgarrett.org Date : 2010-01-13 5:37 (19 days old) References: http://marc.info/?l=linux-kernelm=126336296600307w=4 Handled-By: Yinghai Lu ying...@kernel.org Bjorn Helgaas bjorn.helg...@hp.com should be closed. Is there a fix in the Linus' tree? Rafael Yes, it is fixed by commit e8e06eae4ffd683931b928f460c11c40cd3f7fd8 -Jeff -- 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)
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 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 : http://bugzilla.kernel.org/show_bug.cgi?id=15124 Subject : PCI host bridge windows ignored (works with pci=use_crs) Submitter : Jeff Garrett j...@jgarrett.org Date : 2010-01-13 5:37 (19 days old) References: http://marc.info/?l=linux-kernelm=126336296600307w=4 Handled-By: Yinghai Lu ying...@kernel.org Bjorn Helgaas bjorn.helg...@hp.com should be closed. Is there a fix in the Linus' tree? Yes. The regression was caused by the addition of arch/x86/pci/intel_bus.c. Jeff's patch: http://lkml.org/lkml/2010/1/27/449 is in Linus' tree as commit e8e06eae4ffd68, and Jeff confirmed that it works for him. 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
[Bug #15124] PCI host bridge windows ignored (works with pci=use_crs)
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 : http://bugzilla.kernel.org/show_bug.cgi?id=15124 Subject : PCI host bridge windows ignored (works with pci=use_crs) Submitter : Jeff Garrett j...@jgarrett.org Date: 2010-01-13 5:37 (19 days old) References : http://marc.info/?l=linux-kernelm=126336296600307w=4 Handled-By : Yinghai Lu ying...@kernel.org Bjorn Helgaas bjorn.helg...@hp.com -- 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)
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 it's only interesting as a debugging tool, and even then it's a sledgehammer. I'd agree with this. The days where it was plausibly practical to boot non-ACPI operating systems on hardware are clearly gone, and people who are actually disabling ACPI in the field seem to be doing so in order to avoid other bugs - and we're failing to fix those bugs as a result. -- Matthew Garrett | mj...@srcf.ucam.org -- 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)
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)
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)
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
Re: [Bug #15124] PCI host bridge windows ignored (works with pci=use_crs)
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
Re: [Bug #15124] PCI host bridge windows ignored (works with pci=use_crs)
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)
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)
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
Re: [Bug #15124] PCI host bridge windows ignored (works with pci=use_crs)
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? 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)
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 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? No that's the plan. intel_bus.c was a good effort, but it's just too different from what Windows does, and it'll always be behind. We'll disable it for 2.6.33 and try again to move to _CRS in 2.6.34 (but fixing the problem with large numbers of _CRS resources this time). -- 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)
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 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? No that's the plan. intel_bus.c was a good effort, but it's just too different from what Windows does, and it'll always be behind. We'll disable it for 2.6.33 and try again to move to _CRS in 2.6.34 (but fixing the problem with large numbers of _CRS resources this time). Should say disable it for 2.6.33 for all but multi-IOH configs, which seem to be fairly rare anyway, and were what intel_bus.c was designed to accommodate. On the one machine that motivated it, use_crs was broken (though it likely isn't now), so it seems the safest route. -- 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)
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. 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)
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? 2. how about when apci is disabled? let's apply that patch at first, and wait for intel give us info about which bit is used to enable routing set up. 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
Re: [Bug #15124] PCI host bridge windows ignored (works with pci=use_crs)
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 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? No that's the plan. intel_bus.c was a good effort, but it's just too different from what Windows does, and it'll always be behind. We'll disable it for 2.6.33 and try again to move to _CRS in 2.6.34 (but fixing the problem with large numbers of _CRS resources this time). Should say disable it for 2.6.33 for all but multi-IOH configs, which seem to be fairly rare anyway, and were what intel_bus.c was designed to accommodate. On the one machine that motivated it, use_crs was broken (though it likely isn't now), so it seems the safest route. will try to produce one patch to handle subtract decoding for legacy IOH aka the one with ESI. the structure could be something like amd_bus.c, need to do it early, but it need after pci_arch_init to get mmconf. 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
Re: [Bug #15124] PCI host bridge windows ignored (works with pci=use_crs)
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. 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)
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. -- 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)
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? 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 is there. could be BIOS have wrong IOH resources and not enable them. Signed-off-by: Yinghai Lu ying...@kernel.org I applied this one to my for-linus branch. Jeff can you confirm it works for you? I'd like to push it to Linus tomorrow. Thanks, FWIW, works... -- 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)
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. 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
Re: [Bug #15124] PCI host bridge windows ignored (works with pci=use_crs)
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. Please verify if it still should be listed and let me know (either way). Bug-Entry : http://bugzilla.kernel.org/show_bug.cgi?id=15124 Subject : PCI host bridge windows ignored (works with pci=use_crs) Submitter : Jeff Garrett j...@jgarrett.org Date: 2010-01-13 5:37 (12 days old) References : http://marc.info/?l=linux-kernelm=126336296600307w=4 Handled-By : Yinghai Lu ying...@kernel.org Bjorn Helgaas bjorn.helg...@hp.com This regression should still be listed. No patch to test yet. Thanks for the update. IIRC, we already know how to fix this ... 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)
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 should be listed and let me know (either way). Bug-Entry : http://bugzilla.kernel.org/show_bug.cgi?id=15124 Subject : PCI host bridge windows ignored (works with pci=use_crs) Submitter : Jeff Garrett j...@jgarrett.org Date : 2010-01-13 5:37 (12 days old) References: http://marc.info/?l=linux-kernelm=126336296600307w=4 Handled-By: Yinghai Lu ying...@kernel.org Bjorn Helgaas bjorn.helg...@hp.com This regression should still be listed. No patch to test yet. ... IIRC, we already know how to fix this ... As far as I know, we do NOT know how to fix this. This regression occurred when we added intel_bus.c because it's not yet smart enough to determine the correct host bridge apertures. Here's what it thinks the bridge aperture is and the Radeon BAR: IOH bus: 00 index 1 mmio: [e000, fdff] pci :04:00.0: reg 10: [mem 0xd000-0xdfff 64bit pref] The IOH aperture is obviously not big enough to cover the Radeon BAR. But the host bridge _CRS tells us this: pci_root PNP0A08:00: host bridge window [mem 0xc000-0xdfff] pci_root PNP0A08:00: host bridge window [mem 0xf000-0xfed8] 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'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, where we need to figure out which address ranges go to which IOHs so we can program downstream devices correctly. But even there, _CRS should give us the information we need, so pci=use_crs should make these machines work. I think we should remove intel_bus.c before .33. It's breaking boxes and we don't know how to fix it. Even if we do find out how to fix it, I think we should move toward using _CRS instead, because that's what Windows uses and it's an easy way for the firmware to tell us about platform quirks. 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)
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 regressions from 2.6.32. Please verify if it still should be listed and let me know (either way). Bug-Entry : http://bugzilla.kernel.org/show_bug.cgi?id=15124 Subject : PCI host bridge windows ignored (works with pci=use_crs) Submitter : Jeff Garrett j...@jgarrett.org Date: 2010-01-13 5:37 (12 days old) References : http://marc.info/?l=linux-kernelm=126336296600307w=4 Handled-By : Yinghai Lu ying...@kernel.org Bjorn Helgaas bjorn.helg...@hp.com This regression should still be listed. No patch to test yet. ... IIRC, we already know how to fix this ... As far as I know, we do NOT know how to fix this. This regression occurred when we added intel_bus.c because it's not yet smart enough to determine the correct host bridge apertures. Here's what it thinks the bridge aperture is and the Radeon BAR: IOH bus: 00 index 1 mmio: [e000, fdff] pci :04:00.0: reg 10: [mem 0xd000-0xdfff 64bit pref] The IOH aperture is obviously not big enough to cover the Radeon BAR. But the host bridge _CRS tells us this: pci_root PNP0A08:00: host bridge window [mem 0xc000-0xdfff] pci_root PNP0A08:00: host bridge window [mem 0xf000-0xfed8] 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'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, where we need to figure out which address ranges go to which IOHs so we can program downstream devices correctly. But even there, _CRS should give us the information we need, so pci=use_crs should make these machines work. I think we should remove intel_bus.c before .33. It's breaking boxes and we don't know how to fix it. Even if we do find out how to fix it, I think we should move toward using _CRS instead, because that's what Windows uses and it's an easy way for the firmware to tell us about platform quirks. 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? 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)
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 undocumented range register (does anybody have the datasheet for that thing?) but Intel tends to often have subtractive decode. That system in question has three PCI express root ports, but two of them have IO and memory disabled according to the lspci info. So maybe it's as simple as that I/O Hub PCI Express Root Port 7 just catching anything that nobody else does, and the single IOH host chip doing the same? I think we should remove intel_bus.c before .33. It's breaking boxes and we don't know how to fix it. Even if we do find out how to fix it, I think we should move toward using _CRS instead, because that's what Windows uses and it's an easy way for the firmware to tell us about platform quirks. I suspect that for 33 it is indeed best to just revert. But somebody is bound to have information on how the actual hardware works. Yinghai? 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)
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, where we need to figure out which address ranges go to which IOHs so we can program downstream devices correctly. But even there, _CRS should give us the information we need, so pci=use_crs should make these machines work. I think we should remove intel_bus.c before .33. It's breaking boxes and we don't know how to fix it. Even if we do find out how to fix it, I think we should move toward using _CRS instead, because that's what Windows uses and it's an easy way for the firmware to tell us about platform quirks. 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? We can't make use_crs the default w/o some more _CRS handling fixes (some firmwares have large lists we need to handle). We can disable intel_bus.c though. Yinghai, I'm inclined against the intel_bus.c approach at this point. It seems unlikely we'll ever keep it up to date with new bridges, since its approach differs so much from how things are done in the Windows world, where the firmware provides a list of resources. We'll always be playing catch up, and will probably be behind the firmware most of the time since the docs with the necessary info likely won't be public most of the time. For 2.6.33 I'd like a minimal fix though, can you disable it for all but the multi-IOH case perhaps? -- 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)
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 subtractive decode thing. Sure, it could be just another undocumented range register (does anybody have the datasheet for that thing?) but Intel tends to often have subtractive decode. That system in question has three PCI express root ports, but two of them have IO and memory disabled according to the lspci info. So maybe it's as simple as that I/O Hub PCI Express Root Port 7 just catching anything that nobody else does, and the single IOH host chip doing the same? I think we should remove intel_bus.c before .33. It's breaking boxes and we don't know how to fix it. Even if we do find out how to fix it, I think we should move toward using _CRS instead, because that's what Windows uses and it's an easy way for the firmware to tell us about platform quirks. I suspect that for 33 it is indeed best to just revert. But somebody is bound to have information on how the actual hardware works. Yinghai? I have asked intel if there is any bit that could be enabled the routing. there is no info about for their documentations. Yinghai -- 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)
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.. 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)
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, 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 undocumented range register (does anybody have the datasheet for that thing?) but Intel tends to often have subtractive decode. That system in question has three PCI express root ports, but two of them have IO and memory disabled according to the lspci info. So maybe it's as simple as that I/O Hub PCI Express Root Port 7 just catching anything that nobody else does, and the single IOH host chip doing the same? I think we should remove intel_bus.c before .33. It's breaking boxes and we don't know how to fix it. Even if we do find out how to fix it, I think we should move toward using _CRS instead, because that's what Windows uses and it's an easy way for the firmware to tell us about platform quirks. I suspect that for 33 it is indeed best to just revert. But somebody is bound to have information on how the actual hardware works. Yinghai? I have asked intel if there is any bit that could be enabled the routing. there is no info about for their documentations. I could probably dig something up in our confidential database, but this is the main problem with intel_bus.c. It'll always be behind with _CRS provides. Sure _CRS may be wrong sometimes, but it'll always work well enough to bring Windows up, so we ought not to ignore it. The underlying problems with our _CRS support still aren't fixed though, so switching that on for 2.6.33 isn't an option. -- 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)
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 is there.
could be BIOS have wrong IOH resources and not enable them.
Signed-off-by: Yinghai Lu ying...@kernel.org
---
arch/x86/pci/intel_bus.c | 86 +++
1 file changed, 86 insertions(+)
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
@@ -7,9 +7,11 @@
#include linux/pci.h
#include linux/init.h
#include asm/pci_x86.h
+#include asm/pci-direct.h
#include bus_numa.h
+static int nr_ioh;
static inline void print_ioh_resources(struct pci_root_info *info)
{
int res_num;
@@ -49,6 +51,9 @@ static void __devinit pci_root_bus_res(s
u64 mmioh_base, mmioh_end;
int bus_base, bus_end;
+ if (nr_ioh 2)
+ return;
+
/* some sys doesn't get mmconf enabled */
if (dev-cfg_size 0x120)
return;
@@ -92,3 +97,84 @@ static void __devinit pci_root_bus_res(s
/* intel IOH */
DECLARE_PCI_FIXUP_EARLY(PCI_VENDOR_ID_INTEL, 0x342e, pci_root_bus_res);
+
+static void __init count_ioh(int num, int slot, int func)
+{
+ nr_ioh++;
+}
+
+struct pci_check_probe {
+ u32 vendor;
+ u32 device;
+ void (*f)(int num, int slot, int func);
+};
+
+static struct pci_check_probe early_qrk[] __initdata = {
+ { PCI_VENDOR_ID_INTEL, 0x342e, count_ioh },
+ {}
+};
+
+static void __init early_check_pci_dev(int num, int slot, int func)
+{
+ u16 vendor;
+ u16 device;
+ int i;
+
+ vendor = read_pci_config_16(num, slot, func, PCI_VENDOR_ID);
+ device = read_pci_config_16(num, slot, func, PCI_DEVICE_ID);
+
+ for (i = 0; early_qrk[i].f != NULL; i++) {
+ if (((early_qrk[i].vendor == PCI_ANY_ID) ||
+ (early_qrk[i].vendor == vendor))
+ ((early_qrk[i].device == PCI_ANY_ID) ||
+ (early_qrk[i].device == device)))
+ early_qrk[i].f(num, slot, func);
+ }
+}
+
+static void __init early_check_pci_devs(void)
+{
+ unsigned bus, slot, func;
+
+ if (!early_pci_allowed())
+ return;
+
+ for (bus = 0; bus 256; bus++) {
+ for (slot = 0; slot 32; slot++) {
+ for (func = 0; func 8; func++) {
+ u32 class;
+ u8 type;
+
+ class = read_pci_config(bus, slot, func,
+ PCI_CLASS_REVISION);
+ if (class == 0x)
+ continue;
+
+ early_check_pci_dev(bus, slot, func);
+
+ if (func == 0) {
+ type = read_pci_config_byte(bus, slot,
+ func,
+ PCI_HEADER_TYPE);
+ if (!(type 0x80))
+ break;
+ }
+ }
+ }
+ }
+}
+
+static int __init intel_postcore_init(void)
+{
+ if (boot_cpu_data.x86_vendor != X86_VENDOR_INTEL)
+ return 0;
+
+ early_check_pci_devs();
+
+ if (nr_ioh)
+ printk(KERN_DEBUG pci: found %d IOH\n, nr_ioh);
+
+ return 0;
+}
+postcore_initcall(intel_postcore_init);
+
--
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
