On Thu, Apr 4, 2013 at 10:36 AM, Tejun Heo wrote:
> Hello,
>
> On Sat, Mar 09, 2013 at 10:44:30PM -0800, Yinghai Lu wrote:
>> Now we have arch_pfn_mapped array, and max_low_pfn_mapped should not
>> be used anymore.
>>
>> User should use arch_pfn_mapped or
On Thu, Apr 4, 2013 at 10:36 AM, Tejun Heo wrote:
> Hello,
>
> On Sat, Mar 09, 2013 at 10:44:30PM -0800, Yinghai Lu wrote:
>> Now we have arch_pfn_mapped array, and max_low_pfn_mapped should not
>> be used anymore.
>>
>> User should use arch_pfn_mapped or
On Tue, Mar 19, 2013 at 9:54 AM, Daniel Vetter wrote:
> I guess I should have phrased it more precisely, but that's exactly
> what I expect is happening on my machine: I don't have anything on
> irq16 (i.e. in non-msi mode the gfx interrupt isn't shared) and hence
> the irq is completely disabled
On Tue, Mar 19, 2013 at 9:54 AM, Daniel Vetter
wrote:
> I guess I should have phrased it more precisely, but that's exactly
> what I expect is happening on my machine: I don't have anything on
> irq16 (i.e. in non-msi mode the gfx interrupt isn't shared) and hence
> the irq is completely disable
On Mon, Mar 18, 2013 at 3:05 PM, Jiri Kosina wrote:
> On Mon, 18 Mar 2013, Yinghai Lu wrote:
>
>> > Yes, switching from MSI to IO-APIC-fasteoi makes the report about lost
>> > interrupts go away.
>> >
>> > My understanding from the other mail is that D
On Mon, Mar 18, 2013 at 3:05 PM, Jiri Kosina wrote:
> On Mon, 18 Mar 2013, Yinghai Lu wrote:
>
>> > Yes, switching from MSI to IO-APIC-fasteoi makes the report about lost
>> > interrupts go away.
>> >
>> > My understanding from the other mail is that D
On Mon, Mar 18, 2013 at 2:12 AM, Jiri Kosina wrote:
> On Fri, 15 Mar 2013, Yinghai Lu wrote:
>
>> > Just a datapoint -- I have put a trivial debugging patch in place, and it
>> > reveals that "nobody cared" for irq 16 happens long after last
>> >
>
On Mon, Mar 18, 2013 at 2:12 AM, Jiri Kosina wrote:
> On Fri, 15 Mar 2013, Yinghai Lu wrote:
>
>> > Just a datapoint -- I have put a trivial debugging patch in place, and it
>> > reveals that "nobody cared" for irq 16 happens long after last
>> >
>
On Fri, Mar 15, 2013 at 8:14 AM, Jiri Kosina wrote:
> Just a datapoint -- I have put a trivial debugging patch in place, and it
> reveals that "nobody cared" for irq 16 happens long after last
>
> I915_WRITE(GMBUS4 + reg_offset, 0);
>
> has been performed in gmbus_wait_hw_status(). On the
On Fri, Mar 15, 2013 at 8:14 AM, Jiri Kosina wrote:
> Just a datapoint -- I have put a trivial debugging patch in place, and it
> reveals that "nobody cared" for irq 16 happens long after last
>
> I915_WRITE(GMBUS4 + reg_offset, 0);
>
> has been performed in gmbus_wait_hw_status(). On the
below
and then 4G above.
-v2: Leave alone max_low_pfn_mapped in i915 code according to tj.
Suggested-by: H. Peter Anvin
Signed-off-by: Yinghai Lu
Cc: "Rafael J. Wysocki"
Cc: Daniel Vetter
Cc: David Airlie
Cc: Jacob Shin
Cc: linux-a...@vger.kernel.org
Cc: dri-devel@lists.freedeskt
below
and then 4G above.
-v2: Leave alone max_low_pfn_mapped in i915 code according to tj.
Suggested-by: H. Peter Anvin
Signed-off-by: Yinghai Lu
Cc: "Rafael J. Wysocki"
Cc: Daniel Vetter
Cc: David Airlie
Cc: Jacob Shin
Cc: linux-acpi at vger.kernel.org
Cc: dri-devel at lists
On Thu, Mar 7, 2013 at 9:25 PM, Tejun Heo wrote:
> On Thu, Mar 7, 2013 at 9:22 PM, Yinghai Lu wrote:
>> On Thu, Mar 7, 2013 at 9:10 PM, Tejun Heo wrote:
>>> On Thu, Mar 07, 2013 at 08:58:27PM -0800, Yinghai Lu wrote:
>>>> diff --git a/drivers/gpu/drm/i915/i915_ge
On Thu, Mar 7, 2013 at 9:25 PM, Tejun Heo wrote:
> On Thu, Mar 7, 2013 at 9:22 PM, Yinghai Lu wrote:
>> On Thu, Mar 7, 2013 at 9:10 PM, Tejun Heo wrote:
>>> On Thu, Mar 07, 2013 at 08:58:27PM -0800, Yinghai Lu wrote:
>>>> diff --git a/drivers/gpu/drm/i915/i915_ge
On Thu, Mar 7, 2013 at 9:10 PM, Tejun Heo wrote:
> On Thu, Mar 07, 2013 at 08:58:27PM -0800, Yinghai Lu wrote:
>> diff --git a/drivers/gpu/drm/i915/i915_gem_stolen.c
>> b/drivers/gpu/drm/i915/i915_gem_stolen.c
>> index 69d97cb..7f9380b 100644
>> --- a/drivers/gpu
On Thu, Mar 7, 2013 at 9:10 PM, Tejun Heo wrote:
> On Thu, Mar 07, 2013 at 08:58:27PM -0800, Yinghai Lu wrote:
>> diff --git a/drivers/gpu/drm/i915/i915_gem_stolen.c
>> b/drivers/gpu/drm/i915/i915_gem_stolen.c
>> index 69d97cb..7f9380b 100644
>> --- a/drivers/gpu
arch_pfn_mapped or just 1<<(32-PAGE_SHIFT) instead.
Suggested-by: H. Peter Anvin
Signed-off-by: Yinghai Lu
Cc: Thomas Renninger
Cc: "Rafael J. Wysocki"
Cc: Daniel Vetter
Cc: David Airlie
Cc: Jacob Shin
Cc: linux-a...@vger.kernel.org
Cc: dri-devel@lists.freedesktop.org
---
arch
arch_pfn_mapped or just 1<<(32-PAGE_SHIFT) instead.
Suggested-by: H. Peter Anvin
Signed-off-by: Yinghai Lu
Cc: Thomas Renninger
Cc: "Rafael J. Wysocki"
Cc: Daniel Vetter
Cc: David Airlie
Cc: Jacob Shin
Cc: linux-acpi at vger.kernel.org
Cc: dri-devel at lists.freedesktop.org
---
No user now, remove it.
That name is misleading as it only for root buses.
Signed-off-by: Yinghai Lu
Cc: Mauro Carvalho Chehab
Cc: Doug Thompson
Cc: linux-e...@vger.kernel.org
Cc: x...@kernel.org
Cc: David Airlie
Cc: dri-devel@lists.freedesktop.org
Cc: "David S. Miller"
C
No user now, remove it.
Signed-off-by: Yinghai Lu
Cc: Mauro Carvalho Chehab
Cc: Doug Thompson
Cc: linux-e...@vger.kernel.org
Cc: x...@kernel.org
Cc: David Airlie
Cc: dri-devel@lists.freedesktop.org
Cc: "David S. Miller"
Cc: sparcli...@vger.kernel.org
Cc: Tony Luck
Cc: Fenghua Yu
s
Cc: Michal Simek
Cc: microblaze-ucli...@itee.uq.edu.au
Cc: Koichi Yasutake
Cc: linux-am33-l...@redhat.com
Cc: Benjamin Herrenschmidt
Cc: Paul Mackerras
Cc: linuxppc-...@lists.ozlabs.org
Yinghai Lu (22):
PCI: Rename pci_release_bus_bridge_dev to pci_release_host_bridge_dev
PCI: Add dummy
the loop.
After those replacing, we even could kill pci_root_buses list.
-v2: fixes compiling error when CONFIG_PCI is not defined that Fengguang Wu
found.
Signed-off-by: Yinghai Lu
Cc: Mauro Carvalho Chehab
Cc: Doug Thompson
Cc: linux-e...@vger.kernel.org
Cc: x...@kernel.org
Cc: David Airlie
Need to use it for looping registered host_bridge, and kill
pci_root_buses list.
Signed-off-by: Yinghai Lu
Cc: Mauro Carvalho Chehab
Cc: Doug Thompson
Cc: linux-e...@vger.kernel.org
Cc: x...@kernel.org
Cc: David Airlie
Cc: dri-devel@lists.freedesktop.org
Cc: "David S. Miller"
C
On Sun, Jan 27, 2013 at 7:21 PM, Yijing Wang wrote:
> On 2013/1/28 3:23, Yinghai Lu wrote:
>> Replace that with hotplug-safe version.
>>
>> Signed-off-by: Yinghai Lu
>> Cc: David Airlie
>> Cc: dri-devel@lists.freedesktop.org
>> ---
>> drivers/gp
On Sun, Jan 27, 2013 at 7:21 PM, Yijing Wang wrote:
> On 2013/1/28 3:23, Yinghai Lu wrote:
>> Replace that with hotplug-safe version.
>>
>> Signed-off-by: Yinghai Lu
>> Cc: David Airlie
>> Cc: dri-devel at lists.freedesktop.org
>> ---
>> drivers/gp
Replace that with hotplug-safe version.
Signed-off-by: Yinghai Lu
Cc: David Airlie
Cc: dri-devel@lists.freedesktop.org
---
drivers/gpu/drm/drm_fops.c | 10 +++---
1 file changed, 7 insertions(+), 3 deletions(-)
diff --git a/drivers/gpu/drm/drm_fops.c b/drivers/gpu/drm/drm_fops.c
index
No user now, remove it.
Signed-off-by: Yinghai Lu
Cc: Mauro Carvalho Chehab
Cc: Doug Thompson
Cc: linux-edac at vger.kernel.org
Cc: x86 at kernel.org
Cc: David Airlie
Cc: dri-devel at lists.freedesktop.org
Cc: "David S. Miller"
Cc: sparclinux at vger.kernel.org
Cc: Tony Luck
Cc:
No user now, remove it.
That name is misleading as it only for root buses.
Signed-off-by: Yinghai Lu
Cc: Mauro Carvalho Chehab
Cc: Doug Thompson
Cc: linux-edac at vger.kernel.org
Cc: x86 at kernel.org
Cc: David Airlie
Cc: dri-devel at lists.freedesktop.org
Cc: "David S. Miller
Replace that with hotplug-safe version.
Signed-off-by: Yinghai Lu
Cc: David Airlie
Cc: dri-devel at lists.freedesktop.org
---
drivers/gpu/drm/drm_fops.c | 10 +++---
1 file changed, 7 insertions(+), 3 deletions(-)
diff --git a/drivers/gpu/drm/drm_fops.c b/drivers/gpu/drm/drm_fops.c
the loop.
After those replacing, we even could kill pci_root_buses list.
-v2: fixes compiling error when CONFIG_PCI is not defined that Fengguang Wu
found.
Signed-off-by: Yinghai Lu
Cc: Mauro Carvalho Chehab
Cc: Doug Thompson
Cc: linux-edac at vger.kernel.org
Cc: x86 at kernel.org
Cc: David
Need to use it for looping registered host_bridge, and kill
pci_root_buses list.
Signed-off-by: Yinghai Lu
Cc: Mauro Carvalho Chehab
Cc: Doug Thompson
Cc: linux-edac at vger.kernel.org
Cc: x86 at kernel.org
Cc: David Airlie
Cc: dri-devel at lists.freedesktop.org
Cc: "David S. Miller
radead.org
Cc: David Howells
Cc: Michal Simek
Cc: microblaze-uclinux at itee.uq.edu.au
Cc: Koichi Yasutake
Cc: linux-am33-list at redhat.com
Cc: Benjamin Herrenschmidt
Cc: Paul Mackerras
Cc: linuxppc-dev at lists.ozlabs.org
Yinghai Lu (22):
PCI: Rename pci_release_bus_
Signed-off-by: Yinghai Lu
Cc: David Airlie
Cc: dri-devel@lists.freedesktop.org
---
drivers/gpu/drm/drm_fops.c | 10 +++---
1 file changed, 7 insertions(+), 3 deletions(-)
diff --git a/drivers/gpu/drm/drm_fops.c b/drivers/gpu/drm/drm_fops.c
index 133b413..b92a9cc 100644
--- a/drivers/gpu
Signed-off-by: Yinghai Lu
Cc: David Airlie
Cc: dri-devel at lists.freedesktop.org
---
drivers/gpu/drm/drm_fops.c | 10 +++---
1 file changed, 7 insertions(+), 3 deletions(-)
diff --git a/drivers/gpu/drm/drm_fops.c b/drivers/gpu/drm/drm_fops.c
index 133b413..b92a9cc 100644
--- a/drivers
Signed-off-by: Yinghai Lu
Cc: David Airlie
Cc: dri-devel@lists.freedesktop.org
---
drivers/gpu/drm/drm_fops.c | 10 +++---
1 files changed, 7 insertions(+), 3 deletions(-)
diff --git a/drivers/gpu/drm/drm_fops.c b/drivers/gpu/drm/drm_fops.c
index 5062eec..ff4cdf3 100644
--- a/drivers/gpu
Signed-off-by: Yinghai Lu
Cc: David Airlie
Cc: dri-devel at lists.freedesktop.org
---
drivers/gpu/drm/drm_fops.c | 10 +++---
1 files changed, 7 insertions(+), 3 deletions(-)
diff --git a/drivers/gpu/drm/drm_fops.c b/drivers/gpu/drm/drm_fops.c
index 5062eec..ff4cdf3 100644
--- a/drivers
On Fri, May 18, 2012 at 12:45 AM, Yinghai Lu wrote:
> On Thu, May 17, 2012 at 9:36 AM, Yinghai Lu wrote:
>> On Thu, May 17, 2012 at 5:34 AM, Steven Newbury
>> wrote:
>>> -BEGIN PGP SIGNED MESSAGE-
>>> Strange, the busn branch is merged with for-pci-res-
On Fri, May 18, 2012 at 12:45 AM, Yinghai Lu wrote:
> On Thu, May 17, 2012 at 9:36 AM, Yinghai Lu wrote:
>> On Thu, May 17, 2012 at 5:34 AM, Steven Newbury
>> wrote:
>>> -BEGIN PGP SIGNED MESSAGE-
>>> Strange, the busn branch is merged with for-pci-res-
On Thu, May 17, 2012 at 9:36 AM, Yinghai Lu wrote:
> On Thu, May 17, 2012 at 5:34 AM, Steven Newbury wrote:
>> -BEGIN PGP SIGNED MESSAGE-
>> Strange, the busn branch is merged with for-pci-res-alloc, but for
>> some reason it isn't working. Only the b
On Thu, May 17, 2012 at 9:36 AM, Yinghai Lu wrote:
> On Thu, May 17, 2012 at 5:34 AM, Steven Newbury
> wrote:
>> -BEGIN PGP SIGNED MESSAGE-
>> Strange, the busn branch is merged with for-pci-res-alloc, but for
>> some reason it isn't working. ?Only th
On Thu, May 17, 2012 at 5:34 AM, Steven Newbury wrote:
> -BEGIN PGP SIGNED MESSAGE-
> Strange, the busn branch is merged with for-pci-res-alloc, but for
> some reason it isn't working. Only the bridge is detected, not the
> devices behind it.
Can you post the boot log ? maybe recently re
On Thu, May 17, 2012 at 5:34 AM, Steven Newbury
wrote:
> -BEGIN PGP SIGNED MESSAGE-
> Strange, the busn branch is merged with for-pci-res-alloc, but for
> some reason it isn't working. ?Only the bridge is detected, not the
> devices behind it.
Can you post the boot log ? maybe recently r
On Sun, Apr 15, 2012 at 11:54 PM, Yinghai Lu wrote:
> On Sun, Apr 15, 2012 at 1:06 PM, Yinghai Lu wrote:
>>> 3. use pci_bus_allocate_resource in drm/radeon driver ... ===> but
>>> that could fail.
>>> so could hack it like a. disable bar 0x10 and steal BAR a
On Sun, Apr 15, 2012 at 11:54 PM, Yinghai Lu wrote:
> On Sun, Apr 15, 2012 at 1:06 PM, Yinghai Lu wrote:
>>> 3. use pci_bus_allocate_resource in drm/radeon driver ... ===> but
>>> that could fail.
>>> ? so could hack it like a. disable bar 0x10 and steal BAR a
On Sun, Apr 15, 2012 at 1:06 PM, Yinghai Lu wrote:
>> 3. use pci_bus_allocate_resource in drm/radeon driver ... ===> but
>> that could fail.
>> so could hack it like a. disable bar 0x10 and steal BAR address,
>> then set 0x30 to that address then copy ROM to ram.
&
On Sun, Apr 15, 2012 at 1:06 PM, Yinghai Lu wrote:
>> 3. use pci_bus_allocate_resource in drm/radeon driver ... ===> but
>> that could fail.
>> ? so could hack it like a. disable bar 0x10 and steal BAR address,
>> then set 0x30 to that address then copy ROM to ram.
&
On Sun, Apr 15, 2012 at 1:05 PM, Yinghai Lu wrote:
> On Sun, Apr 15, 2012 at 10:31 AM, Steven Newbury
> wrote:
>>>>>>>>
>>>>>>>> pci :03:08.0: BAR 15: can't assign mem pref (size
>>>>>>>> 0x1800)
>>
On Sun, Apr 15, 2012 at 1:05 PM, Yinghai Lu wrote:
> On Sun, Apr 15, 2012 at 10:31 AM, Steven Newbury
> wrote:
>>>>>>>>
>>>>>>>> pci :03:08.0: BAR 15: can't assign mem pref (size
>>>>>>>> 0x1800)
>>
On Sun, Apr 15, 2012 at 10:31 AM, Steven Newbury wrote:
>>>
>>> pci :03:08.0: BAR 15: can't assign mem pref (size
>>> 0x1800)
>> Ah! Not enough space for the bridge window!:(
>>
>>
> please append pci=norom ...
>>
That worked. Except of course the radeon drive
On Sun, Apr 15, 2012 at 10:31 AM, Steven Newbury
wrote:
>>>
>>> pci :03:08.0: BAR 15: can't assign mem pref (size
>>> 0x1800)
>> Ah! Not enough space for the bridge window!:(
>>
>>
> please append pci=norom ...
>>
That worked. ?Except of course the radeon driv
On Sat, Apr 14, 2012 at 10:37 AM, Steven Newbury wrote:
> I've created a new quirk utilising an extra PCI resource flag to force
> reallocation of the resource. It's the first approach I've had any
> success at. It does work. Only "Intel Page Flush" now gets allocated
> @0xe000!
Maybe we c
On Sat, Apr 14, 2012 at 10:37 AM, Steven Newbury
wrote:
> I've created a new quirk utilising an extra PCI resource flag to force
> reallocation of the resource. ?It's the first approach I've had any
> success at. ?It does work. ?Only "Intel Page Flush" now gets allocated
> @0xe000!
Maybe we
8:37, Steven Newbury wrote:
>>>>> On 12/04/12 17:40, Steven Newbury wrote:
>>>>>> On Thu, 12 Apr 2012, 17:07:33 BST, Yinghai Lu
>>>>>> wrote:
>>
>>>>>>> On Thu, Apr 12, 2012 at 4:22 AM, Steven Newbury
>>>>
2 18:37, Steven Newbury wrote:
>>>>> On 12/04/12 17:40, Steven Newbury wrote:
>>>>>> On Thu, 12 Apr 2012, 17:07:33 BST, Yinghai Lu
>>>>>> wrote:
>>
>>>>>>> On Thu, Apr 12, 2012 at 4:22 AM, Steven Newbury
>>>>
>> Looks like either a btrfs regression or bad interaction with
>> for-pci-res-alloc. Oops attached.
> Just hit the same oops on the rc1+for-pci-res-alloc kernel I tried
> earlier so it's not definitely something new in the btrfs code. Seems
> like it's a 64/32bit pointer issue??
for-pci-res-all
>> Looks like either a btrfs regression or bad interaction with
>> for-pci-res-alloc. ?Oops attached.
> Just hit the same oops on the rc1+for-pci-res-alloc kernel I tried
> earlier so it's not definitely something new in the btrfs code. ?Seems
> like it's a 64/32bit pointer issue??
for-pci-res-all
On Thu, Apr 12, 2012 at 9:40 AM, Steven Newbury wrote:
>> >
>> > It would be useful to preserve as much low PCI memory address space as
>> > possible for hotplug devices (like my Radeon), but the other problem
>> > is small regions get allocated at the bottom, resulting in the
>> > inability to fi
On Thu, Apr 12, 2012 at 9:40 AM, Steven Newbury
wrote:
>> >
>> > It would be useful to preserve as much low PCI memory address space as
>> > possible for hotplug devices (like my Radeon), but the other problem
>> > is small regions get allocated at the bottom, resulting in the
>> > inability to f
On Thu, Apr 12, 2012 at 4:22 AM, Steven Newbury wrote:
> Thanks, that fixed it! :) I had a similar patch I've been working on but I
> had my fix in the wrong place!
>
> In the working case, initially the BIOS has set GMA to within the low system
> DRAM 0xC000 obviously invalid. This conflic
On Thu, Apr 12, 2012 at 4:22 AM, Steven Newbury
wrote:
> Thanks, that fixed it! :) I had a similar patch I've been working on but I
> had my fix in the wrong place!
>
> In the working case, initially the BIOS has set GMA to within the low system
> DRAM 0xC000 obviously invalid. ?This confli
On Tue, Apr 10, 2012 at 2:19 PM, Steven Newbury wrote:
> Another thought, normally the integrated graphics has an "AGP"
> aperture of 256M @0xe000, which is detected by agpgart-intel, this
> will need to be moved up above 4G to free up 0xe000 for the
> radeon, assuming the "agp_bridge" has
On Tue, Apr 10, 2012 at 2:19 PM, Steven Newbury
wrote:
> Another thought, normally the integrated graphics has an "AGP"
> aperture of 256M @0xe000, which is detected by agpgart-intel, this
> will need to be moved up above 4G to free up 0xe000 for the
> radeon, assuming the "agp_bridge" ha
On 04/15/2011 12:06 PM, Ingo Molnar wrote:
>
> Joerg, mind submitting it with a changelog that includes everything we
> learned
> about this bug and all the Tested-by's in place?
>
> Is anyone of the opinion that we should try to revert the allocation
> order/alignment changes in addition to
On 04/15/2011 12:06 PM, Ingo Molnar wrote:
>
> Joerg, mind submitting it with a changelog that includes everything we
> learned
> about this bug and all the Tested-by's in place?
>
> Is anyone of the opinion that we should try to revert the allocation
> order/alignment changes in addition to
On 04/13/2011 04:39 PM, Linus Torvalds wrote:
> On Wed, Apr 13, 2011 at 2:23 PM, Yinghai Lu wrote:
>>>
>>> What are all the magic numbers, and why would 0x8000 be special?
>>
>> that is the old value when kernel was doing bottom-up bootmem allocation.
>
On 04/13/2011 04:39 PM, Linus Torvalds wrote:
> On Wed, Apr 13, 2011 at 2:23 PM, Yinghai Lu wrote:
>>>
>>> What are all the magic numbers, and why would 0x8000 be special?
>>
>> that is the old value when kernel was doing bottom-up bootmem allocation.
>
On 04/13/2011 02:50 PM, Joerg Roedel wrote:
> On Wed, Apr 13, 2011 at 01:48:48PM -0700, Yinghai Lu wrote:
>> -addr = memblock_find_in_range(0, 1ULL<<32, aper_size, 512ULL<<20);
>> +addr = memblock_find_in_range(0, 1ULL<<32, aper_size, 512ULL<<21);
On 04/13/2011 02:50 PM, Joerg Roedel wrote:
> On Wed, Apr 13, 2011 at 01:48:48PM -0700, Yinghai Lu wrote:
>> -addr = memblock_find_in_range(0, 1ULL<<32, aper_size, 512ULL<<20);
>> +addr = memblock_find_in_range(0, 1ULL<<32, aper_size, 512ULL<<21);
On 04/13/2011 01:54 PM, Linus Torvalds wrote:
> On Wed, Apr 13, 2011 at 1:48 PM, Yinghai Lu wrote:
>>
>> can you try following change ? it will push gart to 0x8000
>>
>> diff --git a/arch/x86/kernel/aperture_64.c b/arch/x86/kernel/aperture_64.c
>> index 86d1
On 04/13/2011 01:54 PM, Linus Torvalds wrote:
> On Wed, Apr 13, 2011 at 1:48 PM, Yinghai Lu wrote:
>>
>> can you try following change ? it will push gart to 0x8000
>>
>> diff --git a/arch/x86/kernel/aperture_64.c b/arch/x86/kernel/aperture_64.c
>> index 86d1
On 04/13/2011 12:34 PM, Joerg Roedel wrote:
> On Wed, Apr 13, 2011 at 12:14:55PM -0700, Yinghai Lu wrote:
>> thanks for the bisecting...
>>
>> so those two patches uncover some problems.
>>
>> [0.00] Checking aperture...
>> [0.00] No AG
On 04/13/2011 12:34 PM, Joerg Roedel wrote:
> On Wed, Apr 13, 2011 at 12:14:55PM -0700, Yinghai Lu wrote:
>> thanks for the bisecting...
>>
>> so those two patches uncover some problems.
>>
>> [0.00] Checking aperture...
>> [0.00] No AG
0afdcf000 - afecf000 (ACPI NVS)
[0.00] BIOS-e820: afecf000 - afeff000 (ACPI data)
[0.00] BIOS-e820: 0000afeff000 - aff0 (usable)
so looks bios program wrong address to the radon card?
Thanks
Yinghai Lu
___
0afdcf000 - afecf000 (ACPI NVS)
[0.00] BIOS-e820: afecf000 - afeff000 (ACPI data)
[0.00] BIOS-e820: 0000afeff000 - aff0 (usable)
so looks bios program wrong address to the radon card?
Thanks
Yinghai Lu
74 matches
Mail list logo
