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 t...@kernel.org 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 just 1UL(32-PAGE_SHIFT) instead
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
On Tue, Mar 19, 2013 at 9:54 AM, Daniel Vetter daniel.vet...@ffwll.ch 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
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 jkos...@suse.cz 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
I915_WRITE(GMBUS4 + reg_offset, 0
On Mon, Mar 18, 2013 at 3:05 PM, Jiri Kosina jkos...@suse.cz 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 DAniel Vetter already has an
idea what
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
On Fri, Mar 15, 2013 at 8:14 AM, Jiri Kosina jkos...@suse.cz 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
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
and then 4G above.
-v2: Leave alone max_low_pfn_mapped in i915 code according to tj.
Suggested-by: H. Peter Anvin h...@zytor.com
Signed-off-by: Yinghai Lu ying...@kernel.org
Cc: Rafael J. Wysocki r...@sisk.pl
Cc: Daniel Vetter daniel.vet...@ffwll.ch
Cc: David Airlie airl...@linux.ie
Cc: Jacob Shin
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
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
---
arch_pfn_mapped or just 1(32-PAGE_SHIFT) instead.
Suggested-by: H. Peter Anvin h...@linux.intel.com
Signed-off-by: Yinghai Lu ying...@kernel.org
Cc: Thomas Renninger tr...@suse.de
Cc: Rafael J. Wysocki r...@sisk.pl
Cc: Daniel Vetter daniel.vet...@ffwll.ch
Cc: David Airlie airl...@linux.ie
Cc: Jacob
On Thu, Mar 7, 2013 at 9:10 PM, Tejun Heo t...@kernel.org 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/drm/i915/i915_gem_stolen.c
On Thu, Mar 7, 2013 at 9:25 PM, Tejun Heo t...@kernel.org wrote:
On Thu, Mar 7, 2013 at 9:22 PM, Yinghai Lu ying...@kernel.org wrote:
On Thu, Mar 7, 2013 at 9:10 PM, Tejun Heo t...@kernel.org wrote:
On Thu, Mar 07, 2013 at 08:58:27PM -0800, Yinghai Lu wrote:
diff --git a/drivers/gpu/drm/i915
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
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_b
Replace that with hotplug-safe version.
Signed-off-by: Yinghai Lu ying...@kernel.org
Cc: David Airlie airl...@linux.ie
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
On Sun, Jan 27, 2013 at 7:21 PM, Yijing Wang wangyij...@huawei.com wrote:
On 2013/1/28 3:23, Yinghai Lu wrote:
Replace that with hotplug-safe version.
Signed-off-by: Yinghai Lu ying...@kernel.org
Cc: David Airlie airl...@linux.ie
Cc: dri-devel@lists.freedesktop.org
---
drivers/gpu/drm
Need to use it for looping registered host_bridge, and kill
pci_root_buses list.
Signed-off-by: Yinghai Lu ying...@kernel.org
Cc: Mauro Carvalho Chehab mche...@redhat.com
Cc: Doug Thompson dougthomp...@xmission.com
Cc: linux-e...@vger.kernel.org
Cc: x...@kernel.org
Cc: David Airlie airl
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 ying...@kernel.org
Cc: Mauro Carvalho Chehab mche...@redhat.com
Cc: Doug Thompson dougthomp...@xmission.com
Cc
yasutake.koi...@jp.panasonic.com
Cc: linux-am33-l...@redhat.com
Cc: Benjamin Herrenschmidt b...@kernel.crashing.org
Cc: Paul Mackerras pau...@samba.org
Cc: linuxppc-...@lists.ozlabs.org
Yinghai Lu (22):
PCI: Rename pci_release_bus_bridge_dev to pci_release_host_bridge_dev
PCI: Add dummy bus_type
No user now, remove it.
Signed-off-by: Yinghai Lu ying...@kernel.org
Cc: Mauro Carvalho Chehab mche...@redhat.com
Cc: Doug Thompson dougthomp...@xmission.com
Cc: linux-e...@vger.kernel.org
Cc: x...@kernel.org
Cc: David Airlie airl...@linux.ie
Cc: dri-devel@lists.freedesktop.org
Cc: David S
No user now, remove it.
That name is misleading as it only for root buses.
Signed-off-by: Yinghai Lu ying...@kernel.org
Cc: Mauro Carvalho Chehab mche...@redhat.com
Cc: Doug Thompson dougthomp...@xmission.com
Cc: linux-e...@vger.kernel.org
Cc: x...@kernel.org
Cc: David Airlie airl...@linux.ie
Cc
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 ying...@kernel.org
Cc: David Airlie airl...@linux.ie
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
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
Signed-off-by: Yinghai Lu ying...@kernel.org
Cc: David Airlie airl...@linux.ie
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
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-r
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. ?Onl
On Thu, May 17, 2012 at 9:36 AM, Yinghai Lu ying...@kernel.org wrote:
On Thu, May 17, 2012 at 5:34 AM, Steven Newbury st...@snewbury.org.uk 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
On Fri, May 18, 2012 at 12:45 AM, Yinghai Lu ying...@kernel.org wrote:
On Thu, May 17, 2012 at 9:36 AM, Yinghai Lu ying...@kernel.org wrote:
On Thu, May 17, 2012 at 5:34 AM, Steven Newbury st...@snewbury.org.uk
wrote:
-BEGIN PGP SIGNED MESSAGE-
Strange, the busn branch is merged
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
On Thu, May 17, 2012 at 5:34 AM, Steven Newbury st...@snewbury.org.uk 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 ?
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 ste
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 ying...@kernel.org 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.
after that, disable
On Sun, Apr 15, 2012 at 11:54 PM, Yinghai Lu ying...@kernel.org wrote:
On Sun, Apr 15, 2012 at 1:06 PM, Yinghai Lu ying...@kernel.org 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
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
On Sun, Apr 15, 2012 at 10:31 AM, Steven Newbury st...@snewbury.org.uk 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 driver can't POST the
card
On Sun, Apr 15, 2012 at 1:05 PM, Yinghai Lu ying...@kernel.org wrote:
On Sun, Apr 15, 2012 at 10:31 AM, Steven Newbury st...@snewbury.org.uk
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
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
On 14/04/12 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
>>>>
:
On 12/04/12 17:40, Steven Newbury wrote:
On Thu, 12 Apr 2012, 17:07:33 BST, Yinghai Lu
ying...@kernel.org wrote:
On Thu, Apr 12, 2012 at 4:22 AM, Steven Newbury
st...@snewbury.org.uk wrote:
Thanks, that fixed it! :) I had a similar patch I've
been working on but I had my fix in the wrong place
On Sat, Apr 14, 2012 at 10:37 AM, Steven Newbury st...@snewbury.org.uk 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
>> 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??
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
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-alloc
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
On Thu, Apr 12, 2012 at 4:22 AM, Steven Newbury st...@snewbury.org.uk 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
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"
On Tue, Apr 10, 2012 at 2:19 PM, Steven Newbury st...@snewbury.org.uk 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
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 this
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 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
000 - afecf000 (ACPI NVS)
[0.00] BIOS-e820: afecf000 - afeff000 (ACPI data)
[0.00] BIOS-e820: afeff000 - aff0 (usable)
so looks bios program wrong address to the radon card?
Thanks
Yinghai Lu
: afeff000 - aff0 (usable)
so looks bios program wrong address to the radon card?
Thanks
Yinghai Lu
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/dri-devel
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 AGP bridge found
[0.00] Node 0: aperture @ a000
On 04/13/2011 01:54 PM, Linus Torvalds wrote:
On Wed, Apr 13, 2011 at 1:48 PM, Yinghai Lu ying...@kernel.org 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 86d1ad4..3b6a9d5 100644
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, 1ULL32, aper_size, 512ULL20);
+addr = memblock_find_in_range(0, 1ULL32, aper_size, 512ULL21);
Btw, while looking at this code I wondered why
On 04/13/2011 04:39 PM, Linus Torvalds wrote:
On Wed, Apr 13, 2011 at 2:23 PM, Yinghai Lu ying...@kernel.org 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.
I understand, BUT THAT IS STILL
73 matches
Mail list logo
