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
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
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
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 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 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
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
On Sun, Aug 31, 2008 at 10:42 AM, Linus Torvalds
[EMAIL PROTECTED] wrote:
On Sun, 31 Aug 2008, Rafael J. Wysocki wrote:
Works, dmesg is at:
http://www.sisk.pl/kernel/debug/mainline/2.6.27-rc5/2.6.27-rc5-test.log
That BAR is indeed locked. Now that we try to reallocate it, you get
this in
On Sun, Aug 31, 2008 at 6:09 AM, Tobias Diedrich
[EMAIL PROTECTED] wrote:
Tobias Diedrich wrote:
I got around to try kexec and found that on 2.6.27-rc5, without
Yinghai Lu's patch, when I kexec while forecdeth is loaded I get the
following when the new kernel tries to load the module (on my
On Sun, Aug 31, 2008 at 11:03 AM, Linus Torvalds
[EMAIL PROTECTED] wrote:
On Sun, 31 Aug 2008, Yinghai Lu wrote:
wonder how the probe could find out the size of is 1fff_..
Heh. That's how PCI sizing works: you write all ones to the register, and
read back the result. The low bits won't
On Sat, Aug 30, 2008 at 10:14 AM, Rafael J. Wysocki [EMAIL PROTECTED] wrote:
Could you please rebase them on top of current -git?
please check attached quilt series based on linus tree.
YH
reserve_region.tar.bz2
Description: BZip2 compressed data
On Sat, Aug 30, 2008 at 10:39 AM, Linus Torvalds
[EMAIL PROTECTED] wrote:
What _broke_ for you is that the horrible patch that got reverted said
that if we recognize this as an MCFG resource, we will _always_ try to
insert it, so it fundamentally broke the whole resource tree, because it
On Sat, Aug 30, 2008 at 10:55 AM, Yinghai Lu [EMAIL PROTECTED] wrote:
On Sat, Aug 30, 2008 at 10:14 AM, Rafael J. Wysocki [EMAIL PROTECTED] wrote:
Could you please rebase them on top of current -git?
please check attached quilt series based on linus tree.
there is some problem with fix -v4
On Sat, Aug 30, 2008 at 11:11 AM, Yinghai Lu [EMAIL PROTECTED] wrote:
On Sat, Aug 30, 2008 at 10:55 AM, Yinghai Lu [EMAIL PROTECTED] wrote:
On Sat, Aug 30, 2008 at 10:14 AM, Rafael J. Wysocki [EMAIL PROTECTED]
wrote:
Could you please rebase them on top of current -git?
please check
On Sat, Aug 30, 2008 at 11:43 AM, Linus Torvalds
[EMAIL PROTECTED] wrote:
On Sat, 30 Aug 2008, Yinghai Lu wrote:
again, should use MCFG end as the res _end
No. Again - we shouldn't DO that insane crap.
We simply shouldn't try to compare the BAR start with randomly chosen
things.
do you
On Sat, Aug 30, 2008 at 12:29 PM, Rafael J. Wysocki [EMAIL PROTECTED] wrote:
There are some at:
http://www.amd.com/us-en/Processors/TechnicalResources/0,,30_182_739_15137,00.html
Well, that's 690/SB600 only and I'm not sure how useful this is.
that is for HW guys.
YH
--
To unsubscribe from
On Sat, Aug 30, 2008 at 12:41 PM, Linus Torvalds
[EMAIL PROTECTED] wrote:
On Sat, 30 Aug 2008, Yinghai Lu wrote:
AMD CPU/NB (quad core aka fam 10h later) has MSR to state MMCONFIG, and
the ATI bridge BAR that have same address for MMCONFIG not even have
chance to decode that, because NB
On Sat, Aug 30, 2008 at 2:12 PM, Yinghai Lu [EMAIL PROTECTED] wrote:
On Sat, Aug 30, 2008 at 1:46 PM, Rafael J. Wysocki [EMAIL PROTECTED] wrote:
On Saturday, 30 of August 2008, Yinghai Lu wrote:
please check
[PATCH] x86: split e820 reserved entries record to late v4
[PATCH] x86: split e820
On Sat, Aug 30, 2008 at 2:34 PM, Rafael J. Wysocki [EMAIL PROTECTED] wrote:
On Saturday, 30 of August 2008, Yinghai Lu wrote:
On Sat, Aug 30, 2008 at 2:12 PM, Yinghai Lu [EMAIL PROTECTED] wrote:
On Sat, Aug 30, 2008 at 1:46 PM, Rafael J. Wysocki [EMAIL PROTECTED]
wrote:
On Saturday, 30
On Sat, Aug 30, 2008 at 4:28 PM, Linus Torvalds
[EMAIL PROTECTED] wrote:
On Sat, 30 Aug 2008, Yinghai Lu wrote:
wait, THAT BAR is 64BIT capable, So kernel should assign 64bit range to it...
it request_resource fails...
I don't think we've ever done new allocations in 64 bits. Although
split_e820_reserve_xx2.patch instead...
Thanks
YH
From: Yinghai Lu [EMAIL PROTECTED]
Subject: [PATCH] x86: split e820 reserved entries record to late v4 - fix v6
try to insert_resource second time, by expand the resource...
for case: e820 reserved entry is partially overlapped with bar res...
hope
On Sat, Aug 30, 2008 at 4:39 PM, Yinghai Lu [EMAIL PROTECTED] wrote:
On Sat, Aug 30, 2008 at 4:28 PM, Linus Torvalds
[EMAIL PROTECTED] wrote:
On Sat, 30 Aug 2008, Yinghai Lu wrote:
wait, THAT BAR is 64BIT capable, So kernel should assign 64bit range to
it...
it request_resource fails
On Sat, Aug 30, 2008 at 2:34 PM, Rafael J. Wysocki [EMAIL PROTECTED] wrote:
On Saturday, 30 of August 2008, Yinghai Lu wrote:
On Sat, Aug 30, 2008 at 2:12 PM, Yinghai Lu [EMAIL PROTECTED] wrote:
On Sat, Aug 30, 2008 at 1:46 PM, Rafael J. Wysocki [EMAIL PROTECTED]
wrote:
On Saturday, 30
On Sat, Aug 30, 2008 at 6:25 PM, David Witbrodt [EMAIL PROTECTED] wrote:
please use split_e820_reserve_xx2.patch instead...
OK, that produces the same result: a happy kernel!
I compared the full 'dmesg' output from the previous build and the
current build using diff: the only differences
On Sat, Aug 30, 2008 at 8:00 PM, Linus Torvalds
[EMAIL PROTECTED] wrote:
On Sat, 30 Aug 2008, Yinghai Lu wrote:
/* Don't touch classless devices or host bridges or
ioapics. */
if (class == PCI_CLASS_NOT_DEFINED ||
class
On Fri, Aug 29, 2008 at 2:13 PM, Yinghai Lu [EMAIL PROTECTED] wrote:
On Fri, Aug 29, 2008 at 12:57 PM, Rafael J. Wysocki [EMAIL PROTECTED] wrote:
On Friday, 29 of August 2008, Rafael J. Wysocki wrote:
On Friday, 29 of August 2008, Linus Torvalds wrote:
Another week (my weeks do seem
On Fri, Aug 29, 2008 at 5:08 PM, Linus Torvalds
[EMAIL PROTECTED] wrote:
On Fri, 29 Aug 2008, Yinghai Lu wrote:
http://www.sisk.pl/kernel/debug/mainline/2.6.27-rc5/broken.log
pci :00:00.0: BAR has MMCONFIG at e000-
And that seems utter crap to begin with.
PCI
On Fri, Aug 29, 2008 at 5:45 PM, Linus Torvalds
[EMAIL PROTECTED] wrote:
On Fri, 29 Aug 2008, Yinghai Lu wrote:
the BAR is from pci_read_bases..., so that chipset is broken...
they are even supposed to to hide that BAR to os.
Ok, can we please
- *do* get a quirk for known-broken
On Fri, Aug 29, 2008 at 7:16 PM, Linus Torvalds
[EMAIL PROTECTED] wrote:
On Fri, 29 Aug 2008, Yinghai Lu wrote:
Ok, can we please
- *do* get a quirk for known-broken chipsets (at a *PCI* level, this is
not an x86 issue)
the quirk work at the first point for David' system
On Fri, Aug 29, 2008 at 7:56 PM, Linus Torvalds
[EMAIL PROTECTED] wrote:
On Fri, 29 Aug 2008, Linus Torvalds wrote:
Yes. And I do think this is a workable model.
Ok, and here's the patch to do
insert_resource_expand_to_fit(root, new);
and while I still haven't actually tested it,
On Tue, Aug 26, 2008 at 12:53 AM, Ingo Molnar [EMAIL PROTECTED] wrote:
* David Miller [EMAIL PROTECTED] wrote:
From: Ingo Molnar [EMAIL PROTECTED]
Date: Tue, 26 Aug 2008 09:22:20 +0200
And i guess the next generation of 4K CPUs support should just get away
from cpumask_t-on-kernel-stack
On Tue, Aug 26, 2008 at 9:51 AM, Linus Torvalds
[EMAIL PROTECTED] wrote:
On Tue, 26 Aug 2008, Yinghai Lu wrote:
wonder if could use unsigned long * directly.
I would actually suggest something like this:
- we continue to have a magic cpumask_t.
- we do different cases for big
On Thu, Aug 21, 2008 at 11:13 AM, Jeremy Fitzhardinge [EMAIL PROTECTED] wrote:
Rafał Miłecki wrote:
I added full dmesg 5 minutes after adding grepped:
http://bugzilla.kernel.org/attachment.cgi?id=17331
OK, I think I see the problem (pasted from bugzilla comment):
Some notes as I pick
On Mon, Jul 7, 2008 at 10:28 PM, Randy Dunlap [EMAIL PROTECTED] wrote:
On Mon, 7 Jul 2008 17:24:16 -0700 Yinghai Lu wrote:
On Mon, Jul 7, 2008 at 3:40 PM, Randy Dunlap [EMAIL PROTECTED] wrote:
On Mon, 7 Jul 2008 11:39:17 -0700 Randy Dunlap wrote:
On Mon, 7 Jul 2008 08:32:18 +0200 Ingo
would be:
| commit e8ee6f0ae5cd860e8e6c02807edfa3c1fa01bcb5
| Author: Yinghai Lu [EMAIL PROTECTED]
| Date: Sun Apr 13 01:41:58 2008 -0700
|
| x86: work around io allocation overlap of HT links
but ... since CONFIG_NUMA makes it work, i'm not sure about that.
Randy, could you post
On Sun, Jul 6, 2008 at 11:42 PM, Ingo Molnar [EMAIL PROTECTED] wrote:
* Randy Dunlap [EMAIL PROTECTED] wrote:
This still happens with 2.6.26-rc9. Using CONFIG_NUMA=y boots OK.
one thing i dont see you having followed up on is whether tip/master
works fine:
.
Ok, then it wasn't the nr_zones thing.
Since it seems to be repeatable for you, can you bisect it?
one guess would be:
| commit e8ee6f0ae5cd860e8e6c02807edfa3c1fa01bcb5
| Author: Yinghai Lu [EMAIL PROTECTED]
| Date: Sun Apr 13 01:41:58 2008 -0700
|
| x86: work
38 matches
Mail list logo
