Re: PCI resources above 4GB

[Bjorn Helgaas]

On Tue, May 29, 2012 at 5:19 PM, Bjorn Helgaas bhelg...@google.com wrote:
 On Mon, May 21, 2012 at 11:27 AM, Steven Newbury st...@snewbury.org.uk 
 wrote:
 -BEGIN PGP SIGNED MESSAGE-
 Hash: SHA1

 On 18/05/12 10:08, Yinghai Lu wrote:
 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 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 reordering patches
 applying sequence break it.

 Never mind, found the problem.

 updated for-pci-res-alloc branch. please check it.

 Tested and working fine now.

 Can you attach dmesg logs without Yinghai's patches (where I assume it
 doesn't work) and with them (where it *does* work) to the bugzilla?  I
 assume https://bugzilla.kernel.org/show_bug.cgi?id=10461 is still the
 relevant report.

 I'm confused because I thought your _CRS showed no apertures above
 4GB, and I'm trying to figure out how Yinghai's patches can help if
 that's the case.

Your _CRS *doesn't* show any apertures above 4GB, but you're booting
with pci=nocrs, so we ignore them anyway.  Doing hotplug with
pci=nocrs is not a supportable proposition.

Patches that help in the pci=nocrs case might be acceptable, but
only if there is clearly no risk to the pci=use_crs case.
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/dri-devel

PCI resources above 4GB

[Bjorn Helgaas]

On Tue, May 29, 2012 at 5:19 PM, Bjorn Helgaas  wrote:
> On Mon, May 21, 2012 at 11:27 AM, Steven Newbury  
> wrote:
>> -BEGIN PGP SIGNED MESSAGE-
>> Hash: SHA1
>>
>> On 18/05/12 10:08, Yinghai Lu wrote:
>>> 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-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 reordering patches
> applying sequence break it.

 Never mind, found the problem.
>>>
>>> updated for-pci-res-alloc branch. please check it.
>>>
>> Tested and working fine now.
>
> Can you attach dmesg logs without Yinghai's patches (where I assume it
> doesn't work) and with them (where it *does* work) to the bugzilla? ?I
> assume https://bugzilla.kernel.org/show_bug.cgi?id=10461 is still the
> relevant report.
>
> I'm confused because I thought your _CRS showed no apertures above
> 4GB, and I'm trying to figure out how Yinghai's patches can help if
> that's the case.

Your _CRS *doesn't* show any apertures above 4GB, but you're booting
with "pci=nocrs", so we ignore them anyway.  Doing hotplug with
"pci=nocrs" is not a supportable proposition.

Patches that help in the "pci=nocrs" case might be acceptable, but
only if there is clearly no risk to the "pci=use_crs" case.

Re: PCI resources above 4GB

[Bjorn Helgaas]

On Mon, May 21, 2012 at 11:27 AM, Steven Newbury st...@snewbury.org.uk wrote:
 -BEGIN PGP SIGNED MESSAGE-
 Hash: SHA1

 On 18/05/12 10:08, Yinghai Lu wrote:
 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 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 reordering patches
 applying sequence break it.

 Never mind, found the problem.

 updated for-pci-res-alloc branch. please check it.

 Tested and working fine now.

Can you attach dmesg logs without Yinghai's patches (where I assume it
doesn't work) and with them (where it *does* work) to the bugzilla?  I
assume https://bugzilla.kernel.org/show_bug.cgi?id=10461 is still the
relevant report.

I'm confused because I thought your _CRS showed no apertures above
4GB, and I'm trying to figure out how Yinghai's patches can help if
that's the case.

Bjorn
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/dri-devel

PCI resources above 4GB

[Bjorn Helgaas]

On Mon, May 21, 2012 at 11:27 AM, Steven Newbury  
wrote:
> -BEGIN PGP SIGNED MESSAGE-
> Hash: SHA1
>
> On 18/05/12 10:08, Yinghai Lu wrote:
>> 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-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 reordering patches
 applying sequence break it.
>>>
>>> Never mind, found the problem.
>>
>> updated for-pci-res-alloc branch. please check it.
>>
> Tested and working fine now.

Can you attach dmesg logs without Yinghai's patches (where I assume it
doesn't work) and with them (where it *does* work) to the bugzilla?  I
assume https://bugzilla.kernel.org/show_bug.cgi?id=10461 is still the
relevant report.

I'm confused because I thought your _CRS showed no apertures above
4GB, and I'm trying to figure out how Yinghai's patches can help if
that's the case.

Bjorn

PCI resources above 4GB

[Steven Newbury]

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1

On 18/05/12 10:08, Yinghai Lu wrote:
> 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-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 reordering patches
>>> applying sequence break it.
>> 
>> Never mind, found the problem.
> 
> updated for-pci-res-alloc branch. please check it.
> 
Tested and working fine now.  Some random update broke gnome-shell, so
couldn't test it straight away.  In the end I gave up fixing it and
reverted to an earlier system snapshot.  btrfs can be very useful! :)

There is an outstanding issue with i915 though.  With the moved BAR
the screen remains blank when i915 loads (should show fbcon) and
doesn't light up until X initialises. (X produces a modeset I assume.)
 After that everything works fine.
-BEGIN PGP SIGNATURE-
Version: GnuPG v2.0.19 (GNU/Linux)
Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/

iEYEARECAAYFAk+6eu4ACgkQGcb56gMuC61InACfa+SvYmWXxJb3x1YTXOJhQWLE
0HkAoKcKhk7elSx1LIaxVdrxiBZibzDa
=MaOP
-END PGP SIGNATURE-

Re: PCI resources above 4GB

[Steven Newbury]

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1

On 18/05/12 10:08, Yinghai Lu wrote:
 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 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 reordering patches
 applying sequence break it.
 
 Never mind, found the problem.
 
 updated for-pci-res-alloc branch. please check it.
 
Tested and working fine now.  Some random update broke gnome-shell, so
couldn't test it straight away.  In the end I gave up fixing it and
reverted to an earlier system snapshot.  btrfs can be very useful! :)

There is an outstanding issue with i915 though.  With the moved BAR
the screen remains blank when i915 loads (should show fbcon) and
doesn't light up until X initialises. (X produces a modeset I assume.)
 After that everything works fine.
-BEGIN PGP SIGNATURE-
Version: GnuPG v2.0.19 (GNU/Linux)
Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/

iEYEARECAAYFAk+6eu4ACgkQGcb56gMuC61InACfa+SvYmWXxJb3x1YTXOJhQWLE
0HkAoKcKhk7elSx1LIaxVdrxiBZibzDa
=MaOP
-END PGP SIGNATURE-
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/dri-devel

PCI resources above 4GB

[Yinghai Lu]

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-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 reordering patches applying
>> sequence break it.
>
> Never mind, found the problem.

updated for-pci-res-alloc branch. please check it.

Thanks

Yinghai

PCI resources above 4GB

[Yinghai Lu]

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 bridge is detected, not the
>> devices behind it.
>
> Can you post the boot log ? maybe recently reordering patches applying
> sequence break it.

Never mind, found the problem.

will check if i could fix it tomorrow.

Yinghai

Re: PCI resources above 4GB

[Yinghai Lu]

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 the bridge is detected, not the
 devices behind it.

 Can you post the boot log ? maybe recently reordering patches applying
 sequence break it.

Never mind, found the problem.

will check if i could fix it tomorrow.

Yinghai
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/dri-devel

Re: PCI resources above 4GB

[Yinghai Lu]

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 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 reordering patches applying
 sequence break it.

 Never mind, found the problem.

updated for-pci-res-alloc branch. please check it.

Thanks

Yinghai
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/dri-devel

PCI resources above 4GB

[Steven Newbury]

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1

On 17/05/12 13:27, Steven Newbury wrote:
> On 15/05/12 18:42, Yinghai Lu wrote:
>> On Tue, May 15, 2012 at 2:54 AM, Steven Newbury 
>>  wrote:
> 
>>> I'll get re-synced back up, and if they're still relevant give 
>>> the patches a test.  Is there an updated branch I should work 
>>> from?
> 
>> git://git.kernel.org/pub/scm/linux/kernel/git/yinghai/linux-yinghai.git
>
>> 
> 
> for-pci-res-alloc
> 
>> and attached patch.
> 
>> Thanks
> 
>> Yinghai
> 
> Hi Yinghai, I also cherry-picked the pref_bar patch and my local
> "Intel Flush Page" patch.
> 
> It boots, and the Intel GMA is allocated >4G, but the radeon
> doesn't get detected with "for-pci-res-alloc" on hotplug (needs
> busn-alloc patches),
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.

so I can't test it.  Booting docked, then undocking/docking
> does work though.
-BEGIN PGP SIGNATURE-
Version: GnuPG v2.0.19 (GNU/Linux)
Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/

iEYEARECAAYFAk+08DkACgkQGcb56gMuC62miwCgv7nU/Uf3CccBwbqFLHTQL2Zp
wygAoLsYma5GaAVHorCRxjS5v6Hw2fQx
=bGut
-END PGP SIGNATURE-

PCI resources above 4GB

[Steven Newbury]

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1

On 15/05/12 18:42, Yinghai Lu wrote:
> On Tue, May 15, 2012 at 2:54 AM, Steven Newbury
>  wrote:
> 
>> I'll get re-synced back up, and if they're still relevant give
>> the patches a test.  Is there an updated branch I should work
>> from?
> 
> git://git.kernel.org/pub/scm/linux/kernel/git/yinghai/linux-yinghai.git
>
> 
for-pci-res-alloc
> 
> and attached patch.
> 
> Thanks
> 
> Yinghai

Hi Yinghai,
I also cherry-picked the pref_bar patch and my local "Intel Flush
Page" patch.

It boots, and the Intel GMA is allocated >4G, but the radeon doesn't
get detected with "for-pci-res-alloc" on hotplug (needs busn-alloc
patches), so I can't test it.  Booting docked, then undocking/docking
does work though.
-BEGIN PGP SIGNATURE-
Version: GnuPG v2.0.19 (GNU/Linux)
Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/

iEYEARECAAYFAk+07pkACgkQGcb56gMuC634nwCfcmr5Ub8mA9HOXjsFdWmttjEb
NTAAn0ul6BEKzGz2eoobq2CvpOTzUBzf
=kq5H
-END PGP SIGNATURE-

PCI resources above 4GB

[Yinghai Lu]

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 reordering patches applying
sequence break it.

Yinghai

Re: PCI resources above 4GB

[Steven Newbury]

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1

On 15/05/12 18:42, Yinghai Lu wrote:
 On Tue, May 15, 2012 at 2:54 AM, Steven Newbury
 st...@snewbury.org.uk wrote:
 
 I'll get re-synced back up, and if they're still relevant give
 the patches a test.  Is there an updated branch I should work
 from?
 
 git://git.kernel.org/pub/scm/linux/kernel/git/yinghai/linux-yinghai.git

 
for-pci-res-alloc
 
 and attached patch.
 
 Thanks
 
 Yinghai

Hi Yinghai,
I also cherry-picked the pref_bar patch and my local Intel Flush
Page patch.

It boots, and the Intel GMA is allocated 4G, but the radeon doesn't
get detected with for-pci-res-alloc on hotplug (needs busn-alloc
patches), so I can't test it.  Booting docked, then undocking/docking
does work though.
-BEGIN PGP SIGNATURE-
Version: GnuPG v2.0.19 (GNU/Linux)
Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/

iEYEARECAAYFAk+07pkACgkQGcb56gMuC634nwCfcmr5Ub8mA9HOXjsFdWmttjEb
NTAAn0ul6BEKzGz2eoobq2CvpOTzUBzf
=kq5H
-END PGP SIGNATURE-
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/dri-devel

Re: PCI resources above 4GB

[Steven Newbury]

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1

On 17/05/12 13:27, Steven Newbury wrote:
 On 15/05/12 18:42, Yinghai Lu wrote:
 On Tue, May 15, 2012 at 2:54 AM, Steven Newbury 
 st...@snewbury.org.uk wrote:
 
 I'll get re-synced back up, and if they're still relevant give 
 the patches a test.  Is there an updated branch I should work 
 from?
 
 git://git.kernel.org/pub/scm/linux/kernel/git/yinghai/linux-yinghai.git

 
 
 for-pci-res-alloc
 
 and attached patch.
 
 Thanks
 
 Yinghai
 
 Hi Yinghai, I also cherry-picked the pref_bar patch and my local
 Intel Flush Page patch.
 
 It boots, and the Intel GMA is allocated 4G, but the radeon
 doesn't get detected with for-pci-res-alloc on hotplug (needs
 busn-alloc patches),
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.

so I can't test it.  Booting docked, then undocking/docking
 does work though.
-BEGIN PGP SIGNATURE-
Version: GnuPG v2.0.19 (GNU/Linux)
Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/

iEYEARECAAYFAk+08DkACgkQGcb56gMuC62miwCgv7nU/Uf3CccBwbqFLHTQL2Zp
wygAoLsYma5GaAVHorCRxjS5v6Hw2fQx
=bGut
-END PGP SIGNATURE-
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/dri-devel

Re: PCI resources above 4GB

[Yinghai Lu]

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 ? maybe recently reordering patches applying
sequence break it.

Yinghai
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/dri-devel

PCI resources above 4GB

[Steven Newbury]

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1

On 16/04/12 18:29, Yinghai Lu wrote:
> 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 address, then set 0x30 to that address
 then copy ROM to ram. after that, disable rom again and set
 back address to 0x10. You try to update radeon_get_bios() to
 achieve that.
>> 
>> patches for solution 3: map_rom.patch will try to borrow mem or
>> mem pref bar for ROM copying
>> 
>> and You still need to use pci=norom
> 
> map_rom.patch missed one !
> 
> Please check map_rom_v2.patch
> 
Hopefully, I'm going to have time to look into this again later today,
depending how well other tasks go...
-BEGIN PGP SIGNATURE-
Version: GnuPG v2.0.19 (GNU/Linux)
Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/

iEYEARECAAYFAk+WdwwACgkQGcb56gMuC62DgQCglk+MxOIxWxbLChNWNlAOdbSp
tysAnA83Mfa6tZ6TC97xHIqpFqtPJ5Wc
=Vd8+
-END PGP SIGNATURE-

Re: PCI resources above 4GB

[Steven Newbury]

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1

On 16/04/12 18:29, Yinghai Lu wrote:
 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, then set 0x30 to that address
 then copy ROM to ram. after that, disable rom again and set
 back address to 0x10. You try to update radeon_get_bios() to
 achieve that.
 
 patches for solution 3: map_rom.patch will try to borrow mem or
 mem pref bar for ROM copying
 
 and You still need to use pci=norom
 
 map_rom.patch missed one !
 
 Please check map_rom_v2.patch
 
Hopefully, I'm going to have time to look into this again later today,
depending how well other tasks go...
-BEGIN PGP SIGNATURE-
Version: GnuPG v2.0.19 (GNU/Linux)
Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/

iEYEARECAAYFAk+WdwwACgkQGcb56gMuC62DgQCglk+MxOIxWxbLChNWNlAOdbSp
tysAnA83Mfa6tZ6TC97xHIqpFqtPJ5Wc
=Vd8+
-END PGP SIGNATURE-
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/dri-devel

PCI resources above 4GB

[Steven Newbury]

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1

On 16/04/12 18:29, Yinghai Lu wrote:
> 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 address, then set 0x30 to that address
 then copy ROM to ram. after that, disable rom again and set
 back address to 0x10. You try to update radeon_get_bios() to
 achieve that.
>> 
>> patches for solution 3: map_rom.patch will try to borrow mem or
>> mem pref bar for ROM copying
>> 
>> and You still need to use pci=norom
> 
> map_rom.patch missed one !
> 
> Please check map_rom_v2.patch

I've been really busy, and I'm going to be mostly unavailable until
Monday.  I will get back to it as soon as I can.
-BEGIN PGP SIGNATURE-
Version: GnuPG v2.0.19 (GNU/Linux)
Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/

iEYEARECAAYFAk+Oa3AACgkQGcb56gMuC63HogCfWQTdBSlNcj9zwHy9m4duwmHI
A4YAn2bVH1M4BjPxdfzb+AdX7v3wW79Q
=mUxP
-END PGP SIGNATURE-

PCI resources above 4GB

[Yinghai Lu]

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 address,
>>> then set 0x30 to that address then copy ROM to ram.
>>> ? after that, disable rom again and set back address to 0x10.
>>> ? You try to update radeon_get_bios() to achieve that.
>
> patches for solution 3:
> map_rom.patch will try to borrow mem or mem pref bar for ROM copying
>
> and You still need to use pci=norom

map_rom.patch missed one !

Please check map_rom_v2.patch

Thanks

Yinghai
-- next part --
A non-text attachment was scrubbed...
Name: map_rom_v2.patch
Type: application/octet-stream
Size: 4307 bytes
Desc: not available
URL: 

PCI resources above 4GB

[Steven Newbury]

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1

On 16/04/12 07:54, 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 address, then set 0x30 to that address then copy
>>> ROM to ram. after that, disable rom again and set back address
>>> to 0x10. You try to update radeon_get_bios() to achieve that.
> 
> patches for solution 3: map_rom.patch will try to borrow mem or mem
> pref bar for ROM copying
> 
> and You still need to use pci=norom
> 
I've tested solution 2 so far and it works well.  I'll test your
patches for 1 and 3 later today.
-BEGIN PGP SIGNATURE-
Version: GnuPG v2.0.19 (GNU/Linux)
Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/

iEYEARECAAYFAk+Lw9oACgkQGcb56gMuC621nwCeM+6rJo8BQhKrbUNzDCJkhVsu
1sQAoJVf/8XNBsro2tyhHxj1giNrVZ6e
=w3sG
-END PGP SIGNATURE-

PCI resources above 4GB

[Yinghai Lu]

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.
>> ? after that, disable rom again and set back address to 0x10.
>> ? You try to update radeon_get_bios() to achieve that.

patches for solution 3:
map_rom.patch will try to borrow mem or mem pref bar for ROM copying

and You still need to use pci=norom

Yinghai
-- next part --
A non-text attachment was scrubbed...
Name: rom_option.patch
Type: application/octet-stream
Size: 1672 bytes
Desc: not available
URL: 

-- next part --
A non-text attachment was scrubbed...
Name: rom_option_1.patch
Type: application/octet-stream
Size: 2253 bytes
Desc: not available
URL: 

-- next part --
A non-text attachment was scrubbed...
Name: map_rom.patch
Type: application/octet-stream
Size: 4306 bytes
Desc: not available
URL: 

Re: PCI resources above 4GB

[Yinghai Lu]

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 rom again and set back address to 0x10.
   You try to update radeon_get_bios() to achieve that.

patches for solution 3:
map_rom.patch will try to borrow mem or mem pref bar for ROM copying

and You still need to use pci=norom

Yinghai


rom_option.patch
Description: Binary data


rom_option_1.patch
Description: Binary data


map_rom.patch
Description: Binary data
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/dri-devel

Re: PCI resources above 4GB

[Yinghai Lu]

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,
 then set 0x30 to that address then copy ROM to ram.
   after that, disable rom again and set back address to 0x10.
   You try to update radeon_get_bios() to achieve that.

 patches for solution 3:
 map_rom.patch will try to borrow mem or mem pref bar for ROM copying

 and You still need to use pci=norom

map_rom.patch missed one !

Please check map_rom_v2.patch

Thanks

Yinghai


map_rom_v2.patch
Description: Binary data
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/dri-devel

PCI resources above 4GB

[Steven Newbury]

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1

On 15/04/12 18:25, Steven Newbury wrote:
> On 15/04/12 12:37, Steven Newbury wrote:
>> On 15/04/12 11:20, Steven Newbury wrote:
>>> On 14/04/12 21:48, Yinghai Lu wrote:
> 
> [snip]
> 
 On Sat, Apr 14, 2012 at 12:21 PM, Steven Newbury
> 
>> 
>> 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 without the ROM! :-P
>> Can the ROM resource be mapped above 4G?
> I didn't really think that through, obviously it can't because
> it's not on a 64-bit capable bridge.  I wonder though, could it be
> shadowed then disabled early before the IOMEM?
I see there's "#if 0"'d helper functions for exactly that in rom.c.
They've been disabled since 2007!
-BEGIN PGP SIGNATURE-
Version: GnuPG v2.0.19 (GNU/Linux)
Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/

iEYEARECAAYFAk+LBgkACgkQGcb56gMuC61NGgCeJoZY9iUXeM6GuhDAntEjVrAu
rsUAoIROJFA5xBrZ9qzYQTGSf7lTJUTA
=lofL
-END PGP SIGNATURE-

PCI resources above 4GB

[Steven Newbury]

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1

On 15/04/12 12:37, Steven Newbury wrote:
> On 15/04/12 11:20, Steven Newbury wrote:
>> On 14/04/12 21:48, Yinghai Lu wrote:

[snip]

>>> On Sat, Apr 14, 2012 at 12:21 PM, Steven Newbury

> 
> 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 without the ROM! :-P
> Can the ROM resource be mapped above 4G?
I didn't really think that through, obviously it can't because it's
not on a 64-bit capable bridge.  I wonder though, could it be shadowed
then disabled early before the IOMEM?
-BEGIN PGP SIGNATURE-
Version: GnuPG v2.0.19 (GNU/Linux)
Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/

iEYEARECAAYFAk+LBKQACgkQGcb56gMuC61OjQCeNPLWh+k03+gvjvWtpG6B4gW0
US0AoJpCmnNrxWtScyOdvX3sP62KPGUX
=Sl0p
-END PGP SIGNATURE-

PCI resources above 4GB

[Yinghai Lu]

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)
>>> 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 without the ROM! :-P
 Can the ROM resource be mapped above 4G?
>>> I didn't really think that through, obviously it can't because
>>> it's not on a 64-bit capable bridge. ?I wonder though, could it be
>>> shadowed then disabled early before the IOMEM?
>> I see there's "#if 0"'d helper functions for exactly that in rom.c.
>> They've been disabled since 2007!
>
> solution could be one of three:
> 1. when bridge support 64bit pref, will not allocate rom bar in bridge
> pref resource.
> > patch: rom_pref.patch
>
> 2. unconditionally to make rom bar allocation in bridge non-pref range.
> > patch: rom_no_pref.patch

missed attach rom_no_pref.patch

> Looks like BIOS and at least one of other OSes is doing that.
>
> I can not find the the history why ROM res is with PREFETCH bit set.
> Maybe Linus has some idea about that.
>
> 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 rom again and set back address to 0x10.
> ? You try to update radeon_get_bios() to achieve that.
>
> ? ? ?Yinghai
-- next part --
A non-text attachment was scrubbed...
Name: rom_no_pref.patch
Type: application/octet-stream
Size: 839 bytes
Desc: not available
URL: 

PCI resources above 4GB

[Yinghai Lu]

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 driver can't POST the
 ?card without the ROM! :-P
>>> Can the ROM resource be mapped above 4G?
>> I didn't really think that through, obviously it can't because
>> it's not on a 64-bit capable bridge. ?I wonder though, could it be
>> shadowed then disabled early before the IOMEM?
> I see there's "#if 0"'d helper functions for exactly that in rom.c.
> They've been disabled since 2007!

solution could be one of three:
1. when bridge support 64bit pref, will not allocate rom bar in bridge
pref resource.
> patch: rom_pref.patch

2. unconditionally to make rom bar allocation in bridge non-pref range.
> patch: rom_no_pref.patch
Looks like BIOS and at least one of other OSes is doing that.

I can not find the the history why ROM res is with PREFETCH bit set.
Maybe Linus has some idea about that.

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 rom again and set back address to 0x10.
   You try to update radeon_get_bios() to achieve that.

  Yinghai
-- next part --
A non-text attachment was scrubbed...
Name: rom_pref.patch
Type: application/octet-stream
Size: 1101 bytes
Desc: not available
URL: 

PCI resources above 4GB

[Steven Newbury]

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1

On 15/04/12 11:20, Steven Newbury wrote:
> On 14/04/12 21:48, Yinghai Lu wrote:
>> On Sat, Apr 14, 2012 at 12:21 PM, Steven Newbury 
>>  wrote:
>>> -BEGIN PGP SIGNED MESSAGE- Hash: SHA1
>>> 
>>> On 14/04/12 20:08, Steven Newbury wrote:
 On 14/04/12 19:42, Steven Newbury wrote:
> On 14/04/12 19:05, Steven Newbury wrote:
>> 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 
>  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 conflict is detected and 
>> it's relallocated to 0x1200.
>> 
>> I've attempted to modify probe.c to disable
>> 64-bit BARs not allocated above 4G so they get 
>> reallocated above when possible later.  It seemed
>>  to work, but again broke GMA despite the BAR 
>> originally containing an invalid address as 
>> mentioned above, it seems for some reason 
>> something is different when the conflict is 
>> detected and rellocated, compared to disabling
>> it early then allocating a valid value..?
>> 
>>> 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!
 
 
>> Hopefully this should fix "Intel Flush Page"
> Need to export pci_bus_alloc_resource_fit for intel-gtt.
 Nearly worked... Or at least it should have worked, but for 
 some reason the allocator failed to utilise 
 0xe000-0xefff for 04:00.0 BAR0..?
 
 
 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 without the ROM! :-P
Can the ROM resource be mapped above 4G?
-BEGIN PGP SIGNATURE-
Version: GnuPG v2.0.19 (GNU/Linux)
Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/

iEYEARECAAYFAk+KsxIACgkQGcb56gMuC63JTQCeOK9EGuyoWPe8lsSS5Y6QcfPi
9HQAniZQP84biGVRM4bP8R6/ulGjuRWV
=i8py
-END PGP SIGNATURE-

PCI resources above 4GB

[Steven Newbury]

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1

On 15/04/12 04:21, Yinghai Lu wrote:
> 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 can be more aggressive with pci=pref_bar to reassign all
> pref mem.
> 
> Please check attached patch.
Had the same effect as my patch in allocating the 256MB GMA BAR high.

- : reserved
0001-0009efff : System RAM
0009f000-0009 : reserved
000c-000c7fff : Video ROM
000cf000-000c : Adapter ROM
000f-000f : System ROM
0010-df65a7ff : System RAM
  0100-0136df3d : Kernel code
  0136df3e-0169127f : Kernel data
  0172f000-01809fff : Kernel bss
df65a800-dfff : reserved
  df65a800-df6f : pnp 00:0d
  df70-df7f : pnp 00:0d
f690-f69f : PCI Bus :09
  f69f-f69f : :09:00.0
f69f-f69f : tg3
f6a0-f6bf : PCI Bus :0d
f6c0-f6cf : PCI Bus :0c
  f6cfe000-f6cf : :0c:00.0
f6cfe000-f6cf : iwl4965
f6dfb700-f6dfb7ff : :00:1f.3
f6dfb800-f6dfbfff : :00:1f.2
  f6dfb800-f6dfbfff : ahci
f6dfc000-f6df : :00:1b.0
  f6dfc000-f6df : ICH HD audio
f6e0-f6ef : :00:02.0
f6f0-f6ff : :00:02.1
f800-fbff : PCI MMCONFIG  [bus 00-3f]
  f800-fbff : reserved
f800-fbff : pnp 00:0d
fec0-fec0 : reserved
  fec0-fec003ff : IOAPIC 0
fed0-fed003ff : HPET 0
  fed0-fed003ff : pnp 00:08
fed18000-fed1bfff : reserved
  fed18000-fed1bfff : pnp 00:0d
fed1c000-fed1c3ff : :00:1d.7
  fed1c000-fed1c3ff : ehci_hcd
fed1c400-fed1c7ff : :00:1a.7
  fed1c400-fed1c7ff : ehci_hcd
fed1d000-fed1dfff : Intel Flush Page
fed2-fed8 : reserved
  fed2-fed3 : pnp 00:0d
  fed4-fed44fff : pnp 00:0a
  fed45000-fed8 : pnp 00:0d
feda-feda5fff : reserved
  feda-feda3fff : pnp 00:0d
  feda4000-feda4fff : pnp 00:0d
  feda5000-feda5fff : pnp 00:0d
feda6000-feda6fff : pnp 00:0d
fee0-fee0 : reserved
  fee0-fee0 : pnp 00:0d
fee0-fee00fff : Local APIC
fef0-feff : PCI Bus :04
  fefbc000-fefb : :04:00.1
fefbc000-fefb : ICH HD audio
  fefc-fefd : :04:00.0
  fefe-feff : :04:00.0
ffa0-ffbf : pnp 00:0d
ffc0-ffdf : PCI Bus :0b
ffe0- : reserved
  ffe0- : pnp 00:0d
1-11fff : System RAM
fef80-fef9f : PCI Bus :09
fefa0-fefbf : PCI Bus :0d
fefc0-fefdf : PCI Bus :0c
fefe0-fefff : PCI Bus :0b
ff000-f : :00:02.0
-BEGIN PGP SIGNATURE-
Version: GnuPG v2.0.19 (GNU/Linux)
Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/

iEYEARECAAYFAk+KsYMACgkQGcb56gMuC62iIQCfWJ7oLOrcL/88YzalEzIrWY/a
LbgAnjzqkflQKzJVDhs0qQ/gxQ1a9FXH
=/ae3
-END PGP SIGNATURE-

PCI resources above 4GB

[Steven Newbury]

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1

On 14/04/12 21:48, Yinghai Lu wrote:
> On Sat, Apr 14, 2012 at 12:21 PM, Steven Newbury 
>  wrote:
>> -BEGIN PGP SIGNED MESSAGE- Hash: SHA1
>> 
>> On 14/04/12 20:08, Steven Newbury wrote:
>>> On 14/04/12 19:42, Steven Newbury wrote:
 On 14/04/12 19:05, Steven Newbury wrote:
> 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 
  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 conflict is detected and
> it's relallocated to 0x1200.
> 
> I've attempted to modify probe.c to disable 64-bit
>  BARs not allocated above 4G so they get 
> reallocated above when possible later.  It seemed 
> to work, but again broke GMA despite the BAR 
> originally containing an invalid address as 
> mentioned above, it seems for some reason
> something is different when the conflict is
> detected and rellocated, compared to disabling it
> early then allocating a valid value..?
> 
>> 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!
>>> 
>>> 
> Hopefully this should fix "Intel Flush Page"
 Need to export pci_bus_alloc_resource_fit for intel-gtt.
>>> Nearly worked... Or at least it should have worked, but for 
>>> some reason the allocator failed to utilise 
>>> 0xe000-0xefff for 04:00.0 BAR0..?
>>> 
>>> 
>>> 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
without the ROM! :-P

-BEGIN PGP SIGNATURE-
Version: GnuPG v2.0.19 (GNU/Linux)
Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/

iEYEARECAAYFAk+KoNwACgkQGcb56gMuC62uAACfdaoIb/NT7+7xGIa4G+Wtw0K0
/IsAoL8NIg6g4q3qoTJuQpp6WyqDYUfu
=OzC5
-END PGP SIGNATURE-

PCI resources above 4GB

[Steven Newbury]

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1

On 14/04/12 21:48, Yinghai Lu wrote:
> On Sat, Apr 14, 2012 at 12:21 PM, Steven Newbury
>  wrote:
>> -BEGIN PGP SIGNED MESSAGE- Hash: SHA1
>> 
>> On 14/04/12 20:08, Steven Newbury wrote:
>>> On 14/04/12 19:42, Steven Newbury wrote:
 On 14/04/12 19:05, Steven Newbury wrote:
> 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 
  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 conflict is detected and it's 
> relallocated to 0x1200.
> 
> I've attempted to modify probe.c to disable 64-bit 
> BARs not allocated above 4G so they get
> reallocated above when possible later.  It seemed
> to work, but again broke GMA despite the BAR
> originally containing an invalid address as
> mentioned above, it seems for some reason something
> is different when the conflict is detected and
> rellocated, compared to disabling it early then
> allocating a valid value..?
> 
>> 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!
>>> 
>>> 
> Hopefully this should fix "Intel Flush Page"
 Need to export pci_bus_alloc_resource_fit for intel-gtt.
>>> Nearly worked... Or at least it should have worked, but for
>>> some reason the allocator failed to utilise
>>> 0xe000-0xefff for 04:00.0 BAR0..?
>>> 
>>> 
>>> 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
without the ROM! ;)

-BEGIN PGP SIGNATURE-
Version: GnuPG v2.0.19 (GNU/Linux)
Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/

iEYEARECAAYFAk+KoMgACgkQGcb56gMuC62ZrACfcMJDlIVy8EfpwQyyAL91OH/d
uEIAoMK2L1LEmy8OZIvaGRqt7UjxlYRM
=v+/Q
-END PGP SIGNATURE-

PCI resources above 4GB

[Steven Newbury]

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1

On 15/04/12 04:21, Yinghai Lu wrote:
> 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 can be more aggressive with pci=pref_bar to reassign all
> pref mem.
> 
> Please check attached patch.

I'll give it a go, but not sure if it will work if it causes the GMA
1Mb MEMIO above 4G.  From my testing the i915 driver isn't happy with
that.  Lower part of the framebuffer is corrupted (overlapping
something?), and the Xorg driver fails to initialise (just garbage on
the screen).  Not sure what's happing there, I tried to duplicate your
gma_addr patch for the other 64-bit registers read into gtt_addr and
reg_addr.
-BEGIN PGP SIGNATURE-
Version: GnuPG v2.0.19 (GNU/Linux)
Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/

iEYEARECAAYFAk+KoJMACgkQGcb56gMuC6056gCcCLtdrliMEudCY32F5Vobz9+I
vc0AnRX0vy6vI9EBtSqxI6KpkHIMQ0o4
=teYN
-END PGP SIGNATURE-

Re: PCI resources above 4GB

[Steven Newbury]

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1

On 15/04/12 04:21, Yinghai Lu wrote:
 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 @0xe000!
 
 Maybe we can be more aggressive with pci=pref_bar to reassign all
 pref mem.
 
 Please check attached patch.

I'll give it a go, but not sure if it will work if it causes the GMA
1Mb MEMIO above 4G.  From my testing the i915 driver isn't happy with
that.  Lower part of the framebuffer is corrupted (overlapping
something?), and the Xorg driver fails to initialise (just garbage on
the screen).  Not sure what's happing there, I tried to duplicate your
gma_addr patch for the other 64-bit registers read into gtt_addr and
reg_addr.
-BEGIN PGP SIGNATURE-
Version: GnuPG v2.0.19 (GNU/Linux)
Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/

iEYEARECAAYFAk+KoJMACgkQGcb56gMuC6056gCcCLtdrliMEudCY32F5Vobz9+I
vc0AnRX0vy6vI9EBtSqxI6KpkHIMQ0o4
=teYN
-END PGP SIGNATURE-
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/dri-devel

Re: PCI resources above 4GB

[Steven Newbury]

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1

On 14/04/12 21:48, Yinghai Lu wrote:
 On Sat, Apr 14, 2012 at 12:21 PM, Steven Newbury
 st...@snewbury.org.uk wrote:
 -BEGIN PGP SIGNED MESSAGE- Hash: SHA1
 
 On 14/04/12 20:08, Steven Newbury wrote:
 On 14/04/12 19:42, Steven Newbury wrote:
 On 14/04/12 19:05, Steven Newbury wrote:
 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 
 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!
 
 In the working case, initially the BIOS has set GMA
 to within the low system DRAM 0xC000 obviously 
 invalid. This conflict is detected and it's 
 relallocated to 0x1200.
 
 I've attempted to modify probe.c to disable 64-bit 
 BARs not allocated above 4G so they get
 reallocated above when possible later.  It seemed
 to work, but again broke GMA despite the BAR
 originally containing an invalid address as
 mentioned above, it seems for some reason something
 is different when the conflict is detected and
 rellocated, compared to disabling it early then
 allocating a valid value..?
 
 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!
 
 
 Hopefully this should fix Intel Flush Page
 Need to export pci_bus_alloc_resource_fit for intel-gtt.
 Nearly worked... Or at least it should have worked, but for
 some reason the allocator failed to utilise
 0xe000-0xefff for 04:00.0 BAR0..?
 
 
 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
without the ROM! ;)

-BEGIN PGP SIGNATURE-
Version: GnuPG v2.0.19 (GNU/Linux)
Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/

iEYEARECAAYFAk+KoMgACgkQGcb56gMuC62ZrACfcMJDlIVy8EfpwQyyAL91OH/d
uEIAoMK2L1LEmy8OZIvaGRqt7UjxlYRM
=v+/Q
-END PGP SIGNATURE-
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/dri-devel

Re: PCI resources above 4GB

[Steven Newbury]

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1

On 14/04/12 21:48, Yinghai Lu wrote:
 On Sat, Apr 14, 2012 at 12:21 PM, Steven Newbury 
 st...@snewbury.org.uk wrote:
 -BEGIN PGP SIGNED MESSAGE- Hash: SHA1
 
 On 14/04/12 20:08, Steven Newbury wrote:
 On 14/04/12 19:42, Steven Newbury wrote:
 On 14/04/12 19:05, Steven Newbury wrote:
 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 
 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!
 
 In the working case, initially the BIOS has set
 GMA to within the low system DRAM 0xC000
 obviously invalid. This conflict is detected and
 it's relallocated to 0x1200.
 
 I've attempted to modify probe.c to disable 64-bit
  BARs not allocated above 4G so they get 
 reallocated above when possible later.  It seemed 
 to work, but again broke GMA despite the BAR 
 originally containing an invalid address as 
 mentioned above, it seems for some reason
 something is different when the conflict is
 detected and rellocated, compared to disabling it
 early then allocating a valid value..?
 
 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!
 
 
 Hopefully this should fix Intel Flush Page
 Need to export pci_bus_alloc_resource_fit for intel-gtt.
 Nearly worked... Or at least it should have worked, but for 
 some reason the allocator failed to utilise 
 0xe000-0xefff for 04:00.0 BAR0..?
 
 
 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
without the ROM! :-P

-BEGIN PGP SIGNATURE-
Version: GnuPG v2.0.19 (GNU/Linux)
Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/

iEYEARECAAYFAk+KoNwACgkQGcb56gMuC62uAACfdaoIb/NT7+7xGIa4G+Wtw0K0
/IsAoL8NIg6g4q3qoTJuQpp6WyqDYUfu
=OzC5
-END PGP SIGNATURE-
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/dri-devel

Re: PCI resources above 4GB

[Steven Newbury]

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1

On 15/04/12 04:21, Yinghai Lu wrote:
 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 @0xe000!
 
 Maybe we can be more aggressive with pci=pref_bar to reassign all
 pref mem.
 
 Please check attached patch.
Had the same effect as my patch in allocating the 256MB GMA BAR high.

- : reserved
0001-0009efff : System RAM
0009f000-0009 : reserved
000c-000c7fff : Video ROM
000cf000-000c : Adapter ROM
000f-000f : System ROM
0010-df65a7ff : System RAM
  0100-0136df3d : Kernel code
  0136df3e-0169127f : Kernel data
  0172f000-01809fff : Kernel bss
df65a800-dfff : reserved
  df65a800-df6f : pnp 00:0d
  df70-df7f : pnp 00:0d
f690-f69f : PCI Bus :09
  f69f-f69f : :09:00.0
f69f-f69f : tg3
f6a0-f6bf : PCI Bus :0d
f6c0-f6cf : PCI Bus :0c
  f6cfe000-f6cf : :0c:00.0
f6cfe000-f6cf : iwl4965
f6dfb700-f6dfb7ff : :00:1f.3
f6dfb800-f6dfbfff : :00:1f.2
  f6dfb800-f6dfbfff : ahci
f6dfc000-f6df : :00:1b.0
  f6dfc000-f6df : ICH HD audio
f6e0-f6ef : :00:02.0
f6f0-f6ff : :00:02.1
f800-fbff : PCI MMCONFIG  [bus 00-3f]
  f800-fbff : reserved
f800-fbff : pnp 00:0d
fec0-fec0 : reserved
  fec0-fec003ff : IOAPIC 0
fed0-fed003ff : HPET 0
  fed0-fed003ff : pnp 00:08
fed18000-fed1bfff : reserved
  fed18000-fed1bfff : pnp 00:0d
fed1c000-fed1c3ff : :00:1d.7
  fed1c000-fed1c3ff : ehci_hcd
fed1c400-fed1c7ff : :00:1a.7
  fed1c400-fed1c7ff : ehci_hcd
fed1d000-fed1dfff : Intel Flush Page
fed2-fed8 : reserved
  fed2-fed3 : pnp 00:0d
  fed4-fed44fff : pnp 00:0a
  fed45000-fed8 : pnp 00:0d
feda-feda5fff : reserved
  feda-feda3fff : pnp 00:0d
  feda4000-feda4fff : pnp 00:0d
  feda5000-feda5fff : pnp 00:0d
feda6000-feda6fff : pnp 00:0d
fee0-fee0 : reserved
  fee0-fee0 : pnp 00:0d
fee0-fee00fff : Local APIC
fef0-feff : PCI Bus :04
  fefbc000-fefb : :04:00.1
fefbc000-fefb : ICH HD audio
  fefc-fefd : :04:00.0
  fefe-feff : :04:00.0
ffa0-ffbf : pnp 00:0d
ffc0-ffdf : PCI Bus :0b
ffe0- : reserved
  ffe0- : pnp 00:0d
1-11fff : System RAM
fef80-fef9f : PCI Bus :09
fefa0-fefbf : PCI Bus :0d
fefc0-fefdf : PCI Bus :0c
fefe0-fefff : PCI Bus :0b
ff000-f : :00:02.0
-BEGIN PGP SIGNATURE-
Version: GnuPG v2.0.19 (GNU/Linux)
Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/

iEYEARECAAYFAk+KsYMACgkQGcb56gMuC62iIQCfWJ7oLOrcL/88YzalEzIrWY/a
LbgAnjzqkflQKzJVDhs0qQ/gxQ1a9FXH
=/ae3
-END PGP SIGNATURE-
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/dri-devel

Re: PCI resources above 4GB

[Steven Newbury]

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1

On 15/04/12 11:20, Steven Newbury wrote:
 On 14/04/12 21:48, Yinghai Lu wrote:
 On Sat, Apr 14, 2012 at 12:21 PM, Steven Newbury 
 st...@snewbury.org.uk wrote:
 -BEGIN PGP SIGNED MESSAGE- Hash: SHA1
 
 On 14/04/12 20:08, Steven Newbury wrote:
 On 14/04/12 19:42, Steven Newbury wrote:
 On 14/04/12 19:05, Steven Newbury wrote:
 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 
 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!
 
 In the working case, initially the BIOS has set 
 GMA to within the low system DRAM 0xC000 
 obviously invalid. This conflict is detected and 
 it's relallocated to 0x1200.
 
 I've attempted to modify probe.c to disable
 64-bit BARs not allocated above 4G so they get 
 reallocated above when possible later.  It seemed
  to work, but again broke GMA despite the BAR 
 originally containing an invalid address as 
 mentioned above, it seems for some reason 
 something is different when the conflict is 
 detected and rellocated, compared to disabling
 it early then allocating a valid value..?
 
 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!
 
 
 Hopefully this should fix Intel Flush Page
 Need to export pci_bus_alloc_resource_fit for intel-gtt.
 Nearly worked... Or at least it should have worked, but for 
 some reason the allocator failed to utilise 
 0xe000-0xefff for 04:00.0 BAR0..?
 
 
 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 without the ROM! :-P
Can the ROM resource be mapped above 4G?
-BEGIN PGP SIGNATURE-
Version: GnuPG v2.0.19 (GNU/Linux)
Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/

iEYEARECAAYFAk+KsxIACgkQGcb56gMuC63JTQCeOK9EGuyoWPe8lsSS5Y6QcfPi
9HQAniZQP84biGVRM4bP8R6/ulGjuRWV
=i8py
-END PGP SIGNATURE-
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/dri-devel

Re: PCI resources above 4GB

[Yinghai Lu]

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 without the ROM! :-P
 Can the ROM resource be mapped above 4G?
 I didn't really think that through, obviously it can't because
 it's not on a 64-bit capable bridge.  I wonder though, could it be
 shadowed then disabled early before the IOMEM?
 I see there's #if 0'd helper functions for exactly that in rom.c.
 They've been disabled since 2007!

solution could be one of three:
1. when bridge support 64bit pref, will not allocate rom bar in bridge
pref resource.
 patch: rom_pref.patch

2. unconditionally to make rom bar allocation in bridge non-pref range.
 patch: rom_no_pref.patch
Looks like BIOS and at least one of other OSes is doing that.

I can not find the the history why ROM res is with PREFETCH bit set.
Maybe Linus has some idea about that.

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 rom again and set back address to 0x10.
   You try to update radeon_get_bios() to achieve that.

  Yinghai


rom_pref.patch
Description: Binary data
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/dri-devel

Re: PCI resources above 4GB

[Yinghai Lu]

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 ...

 That worked.  Except of course the radeon driver can't POST the
  card without the ROM! :-P
 Can the ROM resource be mapped above 4G?
 I didn't really think that through, obviously it can't because
 it's not on a 64-bit capable bridge.  I wonder though, could it be
 shadowed then disabled early before the IOMEM?
 I see there's #if 0'd helper functions for exactly that in rom.c.
 They've been disabled since 2007!

 solution could be one of three:
 1. when bridge support 64bit pref, will not allocate rom bar in bridge
 pref resource.
  patch: rom_pref.patch

 2. unconditionally to make rom bar allocation in bridge non-pref range.
  patch: rom_no_pref.patch

missed attach rom_no_pref.patch

 Looks like BIOS and at least one of other OSes is doing that.

 I can not find the the history why ROM res is with PREFETCH bit set.
 Maybe Linus has some idea about that.

 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 rom again and set back address to 0x10.
   You try to update radeon_get_bios() to achieve that.

      Yinghai


rom_no_pref.patch
Description: Binary data
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/dri-devel

PCI resources above 4GB

[Yinghai Lu]

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 can be more aggressive with pci=pref_bar to reassign all pref mem.

Please check attached patch.

Yinghai
-- next part --
A non-text attachment was scrubbed...
Name: pci_assign_pref.patch
Type: application/octet-stream
Size: 2357 bytes
Desc: not available
URL: 

PCI resources above 4GB

[Steven Newbury]

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1

On 14/04/12 20:08, Steven Newbury wrote:
> On 14/04/12 19:42, Steven Newbury wrote:
>> On 14/04/12 19:05, Steven Newbury wrote:
>>> 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 
>>  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 conflict is detected and it's
>>> relallocated to 0x1200.
>>> 
>>> I've attempted to modify probe.c to disable 64-bit
>>> BARs not allocated above 4G so they get reallocated
>>> above when possible later.  It seemed to work, but
>>> again broke GMA despite the BAR originally containing
>>> an invalid address as mentioned above, it seems for
>>> some reason something is different when the conflict is
>>> detected and rellocated, compared to disabling it early
>>> then allocating a valid value..?
>>> 
 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!
> 
> 
>>> Hopefully this should fix "Intel Flush Page"
>> Need to export pci_bus_alloc_resource_fit for intel-gtt.
> Nearly worked... Or at least it should have worked, but for some 
> reason the allocator failed to utilise 0xe000-0xefff for 
> 04:00.0 BAR0..?
> 
> 
> pci :03:08.0: BAR 15: can't assign mem pref (size 0x1800)
Ah! Not enough space for the bridge window!:(

> pci :03:08.0: BAR 14: assigned [mem 0xfef0-0xfeff] pci
> :03:08.0: BAR 13: assigned [io  0x4000-0x4fff] pci
> :04:00.0: BAR 0: can't assign mem pref (size 0x1000) pci
> :04:00.0: BAR 2: assigned [mem 0xfefe-0xfeff 64bit] pci
> :04:00.0: BAR 2: set to [mem 0xfefe-0xfeff 64bit] (PCI 
> address [0xfefe-0xfeff]) pci :04:00.0: BAR 6: assigned
> [mem 0xfefc-0xfefd pref] pci :04:00.1: BAR 0: assigned
> [mem 0xfefbc000-0xfefb 64bit] pci :04:00.1: BAR 0: set to
> [mem 0xfefbc000-0xfefb 64bit] (PCI address
> [0xfefbc000-0xfefb]) pci :04:00.0: BAR 4: assigned [io
> 0x4000-0x40ff] pci :04:00.0: BAR 4: set to [io  0x4000-0x40ff]
> (PCI address [0x4000-0x40ff])

-BEGIN PGP SIGNATURE-
Version: GnuPG v2.0.19 (GNU/Linux)
Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/

iEYEARECAAYFAk+JzkIACgkQGcb56gMuC63MmQCfSvoLv0y+/sbW2HJKM02QfpLN
ld8AoLivGvEaB8ZSlzVcfVi8lJBQDzLS
=5T9j
-END PGP SIGNATURE-

PCI resources above 4GB

[Steven Newbury]

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1

On 14/04/12 19:42, Steven Newbury wrote:
> On 14/04/12 19:05, Steven Newbury wrote:
>> 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 
>  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 conflict is detected and it's relallocated to 
>> 0x1200.
>> 
>> I've attempted to modify probe.c to disable 64-bit BARs
>> not allocated above 4G so they get reallocated above when
>>  possible later.  It seemed to work, but again broke GMA
>>  despite the BAR originally containing an invalid
>> address as mentioned above, it seems for some reason
>> something is different when the conflict is detected and
>> rellocated, compared to disabling it early then
>> allocating a valid value..?
>> 
>>> 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!
> 
> 
>> Hopefully this should fix "Intel Flush Page"
> Need to export pci_bus_alloc_resource_fit for intel-gtt.
Nearly worked... Or at least it should have worked, but for some
reason the allocator failed to utilise 0xe000-0xefff for
04:00.0 BAR0..?


- : reserved
0001-0009efff : System RAM
0009f000-0009 : reserved
000c-000c7fff : Video ROM
000cf000-000c : Adapter ROM
000f-000f : System ROM
0010-df65a7ff : System RAM
  0100-0136defd : Kernel code
  0136defe-0169127f : Kernel data
  0172f000-01809fff : Kernel bss
df65a800-dfff : reserved
  df65a800-df6f : pnp 00:0d
  df70-df7f : pnp 00:0d
f000-f01f : PCI Bus :0d
f690-f69f : PCI Bus :09
  f69f-f69f : :09:00.0
f69f-f69f : tg3
f6a0-f6bf : PCI Bus :0d
f6c0-f6cf : PCI Bus :0c
  f6cfe000-f6cf : :0c:00.0
f6cfe000-f6cf : iwl4965
f6dfb700-f6dfb7ff : :00:1f.3
f6dfb800-f6dfbfff : :00:1f.2
  f6dfb800-f6dfbfff : ahci
f6dfc000-f6df : :00:1b.0
  f6dfc000-f6df : ICH HD audio
f6e0-f6ef : :00:02.0
f6f0-f6ff : :00:02.1
f800-fbff : PCI MMCONFIG  [bus 00-3f]
  f800-fbff : reserved
f800-fbff : pnp 00:0d
fec0-fec0 : reserved
  fec0-fec003ff : IOAPIC 0
fed0-fed003ff : HPET 0
  fed0-fed003ff : pnp 00:08
fed18000-fed1bfff : reserved
  fed18000-fed1bfff : pnp 00:0d
fed1c000-fed1c3ff : :00:1d.7
  fed1c000-fed1c3ff : ehci_hcd
fed1c400-fed1c7ff : :00:1a.7
  fed1c400-fed1c7ff : ehci_hcd
fed1d000-fed1dfff : Intel Flush Page
fed2-fed8 : reserved
  fed2-fed3 : pnp 00:0d
  fed4-fed44fff : pnp 00:0a
  fed45000-fed8 : pnp 00:0d
feda-feda5fff : reserved
  feda-feda3fff : pnp 00:0d
  feda4000-feda4fff : pnp 00:0d
  feda5000-feda5fff : pnp 00:0d
feda6000-feda6fff : pnp 00:0d
fee0-fee0 : reserved
  fee0-fee0 : pnp 00:0d
fee0-fee00fff : Local APIC
fef0-feff : PCI Bus :04
  fefbc000-fefb : :04:00.1
fefbc000-fefb : ICH HD audio
  fefc-fefd : :04:00.0
  fefe-feff : :04:00.0
ffa0-ffbf : pnp 00:0d
ffc0-ffdf : PCI Bus :0b
ffe0- : reserved
  ffe0- : pnp 00:0d
1-11fff : System RAM
fefa0-fefbf : PCI Bus :09
fefc0-fefdf : PCI Bus :0c
fefe0-fefff : PCI Bus :0b
ff000-f : :00:02.0


dmesg after docking:

ACPI: \_SB_.PCI0.PCIE.GDCK - docking
usb 3-3: new high-speed USB device number 3 using ehci_hcd
usb 3-3: New USB device found, idVendor=413c, idProduct=0058
usb 3-3: New USB device strings: Mfr=0, Product=0, SerialNumber=0
hub 3-3:1.0: USB hub found
hub 3-3:1.0: 4 ports detected
ACPI Error: Method parse/execution failed [\SMI_] (Node
88011b031550), AE_AML_INFINITE_LOOP (20120320/psparse-536)
ACPI Error: Method parse/execution failed [\_SB_.PCI0.PCIE.GDCK._DCK]
(Node 88011b038528), AE_AML_INFINITE_LOOP (20120320/psparse-536)
ACPI Exception: AE_AML_INFINITE_LOOP, \_SB_.PCI0.PCIE.GDCK - failed to
execute _DCK
 (20120320/dock-478)
usb 3-3.2: new high-speed USB device number 4 using ehci_hcd
usb 3-3.2: New USB device found, idVendor=413c, idProduct=0058
usb 3-3.2: New USB device strings: Mfr=0, Product=0, SerialNumber=0
hub 3-3.2:1.0: USB hub found
hub 3-3.2:1.0: 4 ports detected
pci :03:08.0: [10b5:8112] type 01 class 0x060400
pci :03:08.0: supports D1
pci :03:08.0: PME# supported from D0 D1 D3hot
pci :03:08.0: PME# disabled
pci 

PCI resources above 4GB

[Steven Newbury]

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1

On 14/04/12 19:05, Steven Newbury wrote:
> 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 
  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 conflict is detected and it's relallocated to 
> 0x1200.
> 
> I've attempted to modify probe.c to disable 64-bit BARs not
>  allocated above 4G so they get reallocated above when 
> possible later.  It seemed to work, but again broke GMA 
> despite the BAR originally containing an invalid address
> as mentioned above, it seems for some reason something is 
> different when the conflict is detected and rellocated, 
> compared to disabling it early then allocating a valid 
> value..?
> 
>> 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!
> 
> 
> Hopefully this should fix "Intel Flush Page"
Need to export pci_bus_alloc_resource_fit for intel-gtt.
-BEGIN PGP SIGNATURE-
Version: GnuPG v2.0.19 (GNU/Linux)
Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/

iEYEARECAAYFAk+JxRMACgkQGcb56gMuC61LegCcCuANujog4iiIziKwFtcCla1s
7BEAoLfLEEXKT1WhboX/m8bMBP90QCgb
=zwK6
-END PGP SIGNATURE-
-- next part --
A non-text attachment was scrubbed...
Name: export-resource_fit.diff
Type: text/x-patch
Size: 639 bytes
Desc: not available
URL: 

PCI resources above 4GB

[Steven Newbury]

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1

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 
>>>  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 conflict is detected and it's relallocated to
 0x1200.
 
 I've attempted to modify probe.c to disable 64-bit BARs not 
 allocated above 4G so they get reallocated above when
 possible later.  It seemed to work, but again broke GMA
 despite the BAR originally containing an invalid address as
 mentioned above, it seems for some reason something is
 different when the conflict is detected and rellocated,
 compared to disabling it early then allocating a valid
 value..?
 
> 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!
> 
> 
Hopefully this should fix "Intel Flush Page"
-BEGIN PGP SIGNATURE-
Version: GnuPG v2.0.19 (GNU/Linux)
Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/

iEYEARECAAYFAk+JvIQACgkQGcb56gMuC63G3ACgma4pUxuwjAAJ0ACS5A32xFwa
k1MAn21y2w6m+Ar+3DwH4Swy1IlicHmN
=nBpy
-END PGP SIGNATURE-
-- next part --
A non-text attachment was scrubbed...
Name: intel-flush-page-fit.diff
Type: text/x-patch
Size: 943 bytes
Desc: not available
URL: 

PCI resources above 4GB

[Steven Newbury]

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1

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
>>  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
>>> conflict is detected and it's relallocated to 0x1200.
>>> 
>>> I've attempted to modify probe.c to disable 64-bit BARs not
>>> allocated above 4G so they get reallocated above when possible
>>> later.  It seemed to work, but again broke GMA despite the BAR
>>> originally containing an invalid address as mentioned above, it
>>> seems for some reason something is different when the conflict
>>> is detected and rellocated, compared to disabling it early then
>>> allocating a valid value..?
>>> 
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!


- : reserved
0001-0009efff : System RAM
0009f000-0009 : reserved
000c-000c7fff : Video ROM
000cf000-000c : Adapter ROM
000f-000f : System ROM
0010-df65a7ff : System RAM
  0100-0136defd : Kernel code
  0136defe-0169127f : Kernel data
  0172f000-01809fff : Kernel bss
df65a800-dfff : reserved
  df65a800-df6f : pnp 00:0d
  df70-df7f : pnp 00:0d
e000-efff : Intel Flush Page
f000-f01f : PCI Bus :0d
f690-f69f : PCI Bus :09
  f69f-f69f : :09:00.0
f69f-f69f : tg3
f6a0-f6bf : PCI Bus :0d
f6c0-f6cf : PCI Bus :0c
  f6cfe000-f6cf : :0c:00.0
f6cfe000-f6cf : iwl4965
f6dfb700-f6dfb7ff : :00:1f.3
f6dfb800-f6dfbfff : :00:1f.2
  f6dfb800-f6dfbfff : ahci
f6dfc000-f6df : :00:1b.0
  f6dfc000-f6df : ICH HD audio
f6e0-f6ef : :00:02.0
f6f0-f6ff : :00:02.1
f800-fbff : PCI MMCONFIG  [bus 00-3f]
  f800-fbff : reserved
f800-fbff : pnp 00:0d
fec0-fec0 : reserved
  fec0-fec003ff : IOAPIC 0
fed0-fed003ff : HPET 0
  fed0-fed003ff : pnp 00:08
fed18000-fed1bfff : reserved
  fed18000-fed1bfff : pnp 00:0d
fed1c000-fed1c3ff : :00:1d.7
  fed1c000-fed1c3ff : ehci_hcd
fed1c400-fed1c7ff : :00:1a.7
  fed1c400-fed1c7ff : ehci_hcd
fed2-fed8 : reserved
  fed2-fed3 : pnp 00:0d
  fed4-fed44fff : pnp 00:0a
  fed45000-fed8 : pnp 00:0d
feda-feda5fff : reserved
  feda-feda3fff : pnp 00:0d
  feda4000-feda4fff : pnp 00:0d
  feda5000-feda5fff : pnp 00:0d
feda6000-feda6fff : pnp 00:0d
fee0-fee0 : reserved
  fee0-fee0 : pnp 00:0d
fee0-fee00fff : Local APIC
ffa0-ffbf : pnp 00:0d
ffc0-ffdf : PCI Bus :0b
ffe0- : reserved
  ffe0- : pnp 00:0d
1-11fff : System RAM
fefa0-fefbf : PCI Bus :09
fefc0-fefdf : PCI Bus :0c
fefe0-fefff : PCI Bus :0b
ff000-f : :00:02.0

-BEGIN PGP SIGNATURE-
Version: GnuPG v2.0.19 (GNU/Linux)
Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/

iEYEARECAAYFAk+JtegACgkQGcb56gMuC61LDgCeO1gr1XT4iL4FK6QXrUq4E4SV
LgwAnR4zdEVkVcfJ2nebHc2++tfi8UsK
=QJc+
-END PGP SIGNATURE-
-- next part --
A non-text attachment was scrubbed...
Name: hack_to_force_realloc.diff
Type: text/x-patch
Size: 2629 bytes
Desc: not available
URL: 

PCI resources above 4GB

[Yinghai Lu]

On Sat, Apr 14, 2012 at 12:21 PM, Steven Newbury  
wrote:
> -BEGIN PGP SIGNED MESSAGE-
> Hash: SHA1
>
> On 14/04/12 20:08, Steven Newbury wrote:
>> On 14/04/12 19:42, Steven Newbury wrote:
>>> On 14/04/12 19:05, Steven Newbury wrote:
 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
>>>  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 conflict is detected and it's
 relallocated to 0x1200.

 I've attempted to modify probe.c to disable 64-bit
 BARs not allocated above 4G so they get reallocated
 above when possible later. ?It seemed to work, but
 again broke GMA despite the BAR originally containing
 an invalid address as mentioned above, it seems for
 some reason something is different when the conflict is
 detected and rellocated, compared to disabling it early
 then allocating a valid value..?

> 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!
>>
>>
 Hopefully this should fix "Intel Flush Page"
>>> Need to export pci_bus_alloc_resource_fit for intel-gtt.
>> Nearly worked... Or at least it should have worked, but for some
>> reason the allocator failed to utilise 0xe000-0xefff for
>> 04:00.0 BAR0..?
>>
>>
>> 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 ...

Yinghai

Re: PCI resources above 4GB

[Steven Newbury]

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1

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!
 
 In the working case, initially the BIOS has set GMA to within
 the low system DRAM 0xC000 obviously invalid.  This
 conflict is detected and it's relallocated to 0x1200.
 
 I've attempted to modify probe.c to disable 64-bit BARs not
 allocated above 4G so they get reallocated above when possible
 later.  It seemed to work, but again broke GMA despite the BAR
 originally containing an invalid address as mentioned above, it
 seems for some reason something is different when the conflict
 is detected and rellocated, compared to disabling it early then
 allocating a valid value..?
 
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!


- : reserved
0001-0009efff : System RAM
0009f000-0009 : reserved
000c-000c7fff : Video ROM
000cf000-000c : Adapter ROM
000f-000f : System ROM
0010-df65a7ff : System RAM
  0100-0136defd : Kernel code
  0136defe-0169127f : Kernel data
  0172f000-01809fff : Kernel bss
df65a800-dfff : reserved
  df65a800-df6f : pnp 00:0d
  df70-df7f : pnp 00:0d
e000-efff : Intel Flush Page
f000-f01f : PCI Bus :0d
f690-f69f : PCI Bus :09
  f69f-f69f : :09:00.0
f69f-f69f : tg3
f6a0-f6bf : PCI Bus :0d
f6c0-f6cf : PCI Bus :0c
  f6cfe000-f6cf : :0c:00.0
f6cfe000-f6cf : iwl4965
f6dfb700-f6dfb7ff : :00:1f.3
f6dfb800-f6dfbfff : :00:1f.2
  f6dfb800-f6dfbfff : ahci
f6dfc000-f6df : :00:1b.0
  f6dfc000-f6df : ICH HD audio
f6e0-f6ef : :00:02.0
f6f0-f6ff : :00:02.1
f800-fbff : PCI MMCONFIG  [bus 00-3f]
  f800-fbff : reserved
f800-fbff : pnp 00:0d
fec0-fec0 : reserved
  fec0-fec003ff : IOAPIC 0
fed0-fed003ff : HPET 0
  fed0-fed003ff : pnp 00:08
fed18000-fed1bfff : reserved
  fed18000-fed1bfff : pnp 00:0d
fed1c000-fed1c3ff : :00:1d.7
  fed1c000-fed1c3ff : ehci_hcd
fed1c400-fed1c7ff : :00:1a.7
  fed1c400-fed1c7ff : ehci_hcd
fed2-fed8 : reserved
  fed2-fed3 : pnp 00:0d
  fed4-fed44fff : pnp 00:0a
  fed45000-fed8 : pnp 00:0d
feda-feda5fff : reserved
  feda-feda3fff : pnp 00:0d
  feda4000-feda4fff : pnp 00:0d
  feda5000-feda5fff : pnp 00:0d
feda6000-feda6fff : pnp 00:0d
fee0-fee0 : reserved
  fee0-fee0 : pnp 00:0d
fee0-fee00fff : Local APIC
ffa0-ffbf : pnp 00:0d
ffc0-ffdf : PCI Bus :0b
ffe0- : reserved
  ffe0- : pnp 00:0d
1-11fff : System RAM
fefa0-fefbf : PCI Bus :09
fefc0-fefdf : PCI Bus :0c
fefe0-fefff : PCI Bus :0b
ff000-f : :00:02.0

-BEGIN PGP SIGNATURE-
Version: GnuPG v2.0.19 (GNU/Linux)
Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/

iEYEARECAAYFAk+JtegACgkQGcb56gMuC61LDgCeO1gr1XT4iL4FK6QXrUq4E4SV
LgwAnR4zdEVkVcfJ2nebHc2++tfi8UsK
=QJc+
-END PGP SIGNATURE-
commit 7063b1e2145bca02bbdd807d3c2ca97748deb73a
Author: Steven Newbury st...@snewbury.org.uk
Date:   Sat Apr 14 13:25:14 2012 +0100

Add a new PCI resource flag to force a conflict for a given resource,
use this new flag with a quirk to trigger reallocation over 4G.

diff --git a/drivers/pci/quirks.c b/drivers/pci/quirks.c
index a24d473..820dc1e 100644
--- a/drivers/pci/quirks.c
+++ b/drivers/pci/quirks.c
@@ -32,6 +32,20 @@
 #include pci.h
 
 /*
+ * Force reallocation 4G (if available) for intel GMA
+ */
+static void __devinit quirk_intel_gma_realloc(struct pci_dev * dev)
+{
+if (sizeof(resource_size_t) == 8) {
+struct resource *r = dev-resource [2];
+if (r-start  0x1) {
+	r-flags |= IORESOURCE_MEM_FORCEREALLOC;
+}
+}
+}
+DECLARE_PCI_FIXUP_HEADER(PCI_VENDOR_ID_INTEL, 0x2a02, quirk_intel_gma_realloc);
+
+/*
  * Decoding should be disabled for a PCI device during BAR sizing to avoid
  * conflict. But doing so may cause problems on host bridge and perhaps other
  * key system devices. For devices that need to have mmio decoding always-on,
diff --git a/drivers/pci/setup-res.c b/drivers/pci/setup-res.c
index ea96ced..aad43c3 100644
--- a/drivers/pci/setup-res.c
+++ b/drivers/pci/setup-res.c
@@ -116,6 +116,8 @@ int pci_claim_resource(struct pci_dev *dev, int resource)
 
 	conflict = request_resource_conflict(root, res);
 	if (conflict) {
+	if (res-flags  IORESOURCE_MEM_FORCEREALLOC)
+	

Re: PCI resources above 4GB

[Steven Newbury]

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1

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
 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!
 
 In the working case, initially the BIOS has set GMA to
 within the low system DRAM 0xC000 obviously invalid.
 This conflict is detected and it's relallocated to
 0x1200.
 
 I've attempted to modify probe.c to disable 64-bit BARs not 
 allocated above 4G so they get reallocated above when
 possible later.  It seemed to work, but again broke GMA
 despite the BAR originally containing an invalid address as
 mentioned above, it seems for some reason something is
 different when the conflict is detected and rellocated,
 compared to disabling it early then allocating a valid
 value..?
 
 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!
 
 
Hopefully this should fix Intel Flush Page
-BEGIN PGP SIGNATURE-
Version: GnuPG v2.0.19 (GNU/Linux)
Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/

iEYEARECAAYFAk+JvIQACgkQGcb56gMuC63G3ACgma4pUxuwjAAJ0ACS5A32xFwa
k1MAn21y2w6m+Ar+3DwH4Swy1IlicHmN
=nBpy
-END PGP SIGNATURE-
commit ccc1099a1474815f4094e8689ca0b518de464230
Author: Steven Newbury st...@snewbury.org.uk
Date:   Sat Apr 14 19:02:47 2012 +0100

intel-gtt: Use pci_bus_alloc_resource_fit() to allocate Intel Flush Page.

diff --git a/drivers/char/agp/intel-gtt.c b/drivers/char/agp/intel-gtt.c
index 77e150e..30b1ea2 100644
--- a/drivers/char/agp/intel-gtt.c
+++ b/drivers/char/agp/intel-gtt.c
@@ -1036,9 +1036,9 @@ static struct agp_memory *intel_fake_agp_alloc_by_type(size_t pg_count,
 static int intel_alloc_chipset_flush_resource(void)
 {
 	int ret;
-	ret = pci_bus_alloc_resource(intel_private.bridge_dev-bus, intel_private.ifp_resource, PAGE_SIZE,
+	ret = pci_bus_alloc_resource_fit(intel_private.bridge_dev-bus, intel_private.ifp_resource, PAGE_SIZE,
  PAGE_SIZE, PCIBIOS_MIN_MEM, 0,
- pcibios_align_resource, intel_private.bridge_dev);
+ pcibios_align_resource, intel_private.bridge_dev, 1);
 
 	return ret;
 }
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/dri-devel

Re: PCI resources above 4GB

[Steven Newbury]

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1

On 14/04/12 19:05, Steven Newbury wrote:
 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 
 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!
 
 In the working case, initially the BIOS has set GMA to 
 within the low system DRAM 0xC000 obviously invalid. 
 This conflict is detected and it's relallocated to 
 0x1200.
 
 I've attempted to modify probe.c to disable 64-bit BARs not
  allocated above 4G so they get reallocated above when 
 possible later.  It seemed to work, but again broke GMA 
 despite the BAR originally containing an invalid address
 as mentioned above, it seems for some reason something is 
 different when the conflict is detected and rellocated, 
 compared to disabling it early then allocating a valid 
 value..?
 
 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!
 
 
 Hopefully this should fix Intel Flush Page
Need to export pci_bus_alloc_resource_fit for intel-gtt.
-BEGIN PGP SIGNATURE-
Version: GnuPG v2.0.19 (GNU/Linux)
Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/

iEYEARECAAYFAk+JxRMACgkQGcb56gMuC61LegCcCuANujog4iiIziKwFtcCla1s
7BEAoLfLEEXKT1WhboX/m8bMBP90QCgb
=zwK6
-END PGP SIGNATURE-
commit fe2ccc15c3cd75af2a582dc6e2b4deb544aca307
Author: Steven Newbury st...@snewbury.org.uk
Date:   Sat Apr 14 19:37:32 2012 +0100

PCI: Export pci_bus_alloc_resource_fit()

diff --git a/drivers/pci/bus.c b/drivers/pci/bus.c
index 6d2b073..acb51bd 100644
--- a/drivers/pci/bus.c
+++ b/drivers/pci/bus.c
@@ -391,6 +391,7 @@ void pci_walk_bus(struct pci_bus *top, int (*cb)(struct pci_dev *, void *),
 EXPORT_SYMBOL_GPL(pci_walk_bus);
 
 EXPORT_SYMBOL(pci_bus_alloc_resource);
+EXPORT_SYMBOL(pci_bus_alloc_resource_fit);
 EXPORT_SYMBOL_GPL(pci_bus_add_device);
 EXPORT_SYMBOL(pci_bus_add_devices);
 EXPORT_SYMBOL(pci_enable_bridges);
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/dri-devel

Re: PCI resources above 4GB

[Steven Newbury]

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1

On 14/04/12 19:42, Steven Newbury wrote:
 On 14/04/12 19:05, Steven Newbury wrote:
 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 
 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!
 
 In the working case, initially the BIOS has set GMA to 
 within the low system DRAM 0xC000 obviously invalid.
  This conflict is detected and it's relallocated to 
 0x1200.
 
 I've attempted to modify probe.c to disable 64-bit BARs
 not allocated above 4G so they get reallocated above when
  possible later.  It seemed to work, but again broke GMA
  despite the BAR originally containing an invalid
 address as mentioned above, it seems for some reason
 something is different when the conflict is detected and
 rellocated, compared to disabling it early then
 allocating a valid value..?
 
 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!
 
 
 Hopefully this should fix Intel Flush Page
 Need to export pci_bus_alloc_resource_fit for intel-gtt.
Nearly worked... Or at least it should have worked, but for some
reason the allocator failed to utilise 0xe000-0xefff for
04:00.0 BAR0..?


- : reserved
0001-0009efff : System RAM
0009f000-0009 : reserved
000c-000c7fff : Video ROM
000cf000-000c : Adapter ROM
000f-000f : System ROM
0010-df65a7ff : System RAM
  0100-0136defd : Kernel code
  0136defe-0169127f : Kernel data
  0172f000-01809fff : Kernel bss
df65a800-dfff : reserved
  df65a800-df6f : pnp 00:0d
  df70-df7f : pnp 00:0d
f000-f01f : PCI Bus :0d
f690-f69f : PCI Bus :09
  f69f-f69f : :09:00.0
f69f-f69f : tg3
f6a0-f6bf : PCI Bus :0d
f6c0-f6cf : PCI Bus :0c
  f6cfe000-f6cf : :0c:00.0
f6cfe000-f6cf : iwl4965
f6dfb700-f6dfb7ff : :00:1f.3
f6dfb800-f6dfbfff : :00:1f.2
  f6dfb800-f6dfbfff : ahci
f6dfc000-f6df : :00:1b.0
  f6dfc000-f6df : ICH HD audio
f6e0-f6ef : :00:02.0
f6f0-f6ff : :00:02.1
f800-fbff : PCI MMCONFIG  [bus 00-3f]
  f800-fbff : reserved
f800-fbff : pnp 00:0d
fec0-fec0 : reserved
  fec0-fec003ff : IOAPIC 0
fed0-fed003ff : HPET 0
  fed0-fed003ff : pnp 00:08
fed18000-fed1bfff : reserved
  fed18000-fed1bfff : pnp 00:0d
fed1c000-fed1c3ff : :00:1d.7
  fed1c000-fed1c3ff : ehci_hcd
fed1c400-fed1c7ff : :00:1a.7
  fed1c400-fed1c7ff : ehci_hcd
fed1d000-fed1dfff : Intel Flush Page
fed2-fed8 : reserved
  fed2-fed3 : pnp 00:0d
  fed4-fed44fff : pnp 00:0a
  fed45000-fed8 : pnp 00:0d
feda-feda5fff : reserved
  feda-feda3fff : pnp 00:0d
  feda4000-feda4fff : pnp 00:0d
  feda5000-feda5fff : pnp 00:0d
feda6000-feda6fff : pnp 00:0d
fee0-fee0 : reserved
  fee0-fee0 : pnp 00:0d
fee0-fee00fff : Local APIC
fef0-feff : PCI Bus :04
  fefbc000-fefb : :04:00.1
fefbc000-fefb : ICH HD audio
  fefc-fefd : :04:00.0
  fefe-feff : :04:00.0
ffa0-ffbf : pnp 00:0d
ffc0-ffdf : PCI Bus :0b
ffe0- : reserved
  ffe0- : pnp 00:0d
1-11fff : System RAM
fefa0-fefbf : PCI Bus :09
fefc0-fefdf : PCI Bus :0c
fefe0-fefff : PCI Bus :0b
ff000-f : :00:02.0


dmesg after docking:

ACPI: \_SB_.PCI0.PCIE.GDCK - docking
usb 3-3: new high-speed USB device number 3 using ehci_hcd
usb 3-3: New USB device found, idVendor=413c, idProduct=0058
usb 3-3: New USB device strings: Mfr=0, Product=0, SerialNumber=0
hub 3-3:1.0: USB hub found
hub 3-3:1.0: 4 ports detected
ACPI Error: Method parse/execution failed [\SMI_] (Node
88011b031550), AE_AML_INFINITE_LOOP (20120320/psparse-536)
ACPI Error: Method parse/execution failed [\_SB_.PCI0.PCIE.GDCK._DCK]
(Node 88011b038528), AE_AML_INFINITE_LOOP (20120320/psparse-536)
ACPI Exception: AE_AML_INFINITE_LOOP, \_SB_.PCI0.PCIE.GDCK - failed to
execute _DCK
 (20120320/dock-478)
usb 3-3.2: new high-speed USB device number 4 using ehci_hcd
usb 3-3.2: New USB device found, idVendor=413c, idProduct=0058
usb 3-3.2: New USB device strings: Mfr=0, Product=0, SerialNumber=0
hub 3-3.2:1.0: USB hub found
hub 3-3.2:1.0: 4 ports detected
pci :03:08.0: [10b5:8112] type 01 class 0x060400
pci :03:08.0: supports D1
pci :03:08.0: PME# supported from D0 D1 D3hot
pci :03:08.0: PME# disabled
pci :03:08.0: scanning [bus 00-00] behind bridge, pass 0
pci :03:08.0: bus configuration invalid, reconfiguring

Re: PCI resources above 4GB

[Steven Newbury]

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1

On 14/04/12 20:08, Steven Newbury wrote:
 On 14/04/12 19:42, Steven Newbury wrote:
 On 14/04/12 19:05, Steven Newbury wrote:
 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 
 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!
 
 In the working case, initially the BIOS has set GMA to
  within the low system DRAM 0xC000 obviously
 invalid. This conflict is detected and it's
 relallocated to 0x1200.
 
 I've attempted to modify probe.c to disable 64-bit
 BARs not allocated above 4G so they get reallocated
 above when possible later.  It seemed to work, but
 again broke GMA despite the BAR originally containing
 an invalid address as mentioned above, it seems for
 some reason something is different when the conflict is
 detected and rellocated, compared to disabling it early
 then allocating a valid value..?
 
 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!
 
 
 Hopefully this should fix Intel Flush Page
 Need to export pci_bus_alloc_resource_fit for intel-gtt.
 Nearly worked... Or at least it should have worked, but for some 
 reason the allocator failed to utilise 0xe000-0xefff for 
 04:00.0 BAR0..?
 
 
 pci :03:08.0: BAR 15: can't assign mem pref (size 0x1800)
Ah! Not enough space for the bridge window!:(

 pci :03:08.0: BAR 14: assigned [mem 0xfef0-0xfeff] pci
 :03:08.0: BAR 13: assigned [io  0x4000-0x4fff] pci
 :04:00.0: BAR 0: can't assign mem pref (size 0x1000) pci
 :04:00.0: BAR 2: assigned [mem 0xfefe-0xfeff 64bit] pci
 :04:00.0: BAR 2: set to [mem 0xfefe-0xfeff 64bit] (PCI 
 address [0xfefe-0xfeff]) pci :04:00.0: BAR 6: assigned
 [mem 0xfefc-0xfefd pref] pci :04:00.1: BAR 0: assigned
 [mem 0xfefbc000-0xfefb 64bit] pci :04:00.1: BAR 0: set to
 [mem 0xfefbc000-0xfefb 64bit] (PCI address
 [0xfefbc000-0xfefb]) pci :04:00.0: BAR 4: assigned [io
 0x4000-0x40ff] pci :04:00.0: BAR 4: set to [io  0x4000-0x40ff]
 (PCI address [0x4000-0x40ff])

-BEGIN PGP SIGNATURE-
Version: GnuPG v2.0.19 (GNU/Linux)
Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/

iEYEARECAAYFAk+JzkIACgkQGcb56gMuC63MmQCfSvoLv0y+/sbW2HJKM02QfpLN
ld8AoLivGvEaB8ZSlzVcfVi8lJBQDzLS
=5T9j
-END PGP SIGNATURE-
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/dri-devel

Re: PCI resources above 4GB

[Yinghai Lu]

On Sat, Apr 14, 2012 at 12:21 PM, Steven Newbury st...@snewbury.org.uk wrote:
 -BEGIN PGP SIGNED MESSAGE-
 Hash: SHA1

 On 14/04/12 20:08, Steven Newbury wrote:
 On 14/04/12 19:42, Steven Newbury wrote:
 On 14/04/12 19:05, Steven Newbury wrote:
 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
 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!

 In the working case, initially the BIOS has set GMA to
  within the low system DRAM 0xC000 obviously
 invalid. This conflict is detected and it's
 relallocated to 0x1200.

 I've attempted to modify probe.c to disable 64-bit
 BARs not allocated above 4G so they get reallocated
 above when possible later.  It seemed to work, but
 again broke GMA despite the BAR originally containing
 an invalid address as mentioned above, it seems for
 some reason something is different when the conflict is
 detected and rellocated, compared to disabling it early
 then allocating a valid value..?

 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!


 Hopefully this should fix Intel Flush Page
 Need to export pci_bus_alloc_resource_fit for intel-gtt.
 Nearly worked... Or at least it should have worked, but for some
 reason the allocator failed to utilise 0xe000-0xefff for
 04:00.0 BAR0..?


 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 ...

Yinghai
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/dri-devel

Re: PCI resources above 4GB

[Yinghai Lu]

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
 @0xe000!

Maybe we can be more aggressive with pci=pref_bar to reassign all pref mem.

Please check attached patch.

Yinghai


pci_assign_pref.patch
Description: Binary data
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/dri-devel

Btrfs corruption Oops ( was: Re: PCI resources above 4GB)

[Steven Newbury]

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1

On 13/04/12 19:12, Steven Newbury wrote:
> On 13/04/12 18:38, Steven Newbury wrote:
>> On 13/04/12 17:17, Yinghai Lu wrote:
> 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 include
> 
>>> for-pci-hostbridge-cleanup for-pci-busn-alloc 
>>> for-pci-root-bus-hotplug for-pci-for-each-res-addon at plus 7 
>>> patches.
> 
>>> maybe there is some problem with for-pci-for-each-res-addon.
> 
>>> just rebase for-pci-res-alloc to for-pci-root-bus-hotplug.
>>> Please check if the problem still there.
> 
>> Still Oopses.  I'm going to try linus/master.  Perhaps it's a 
>> filesystem corruption triggering it?  I do find it a little 
>> suspicious that it occurs in "btrfs:find_workspace" though, code 
>> which deals with memory allocations...
> Damn. It still oopses with my linus tracking branch!  I'm going to 
> restore from backup and see if it still happens.
It was filesystem corruption.  Running rsync triggered it on a couple
of files.  Strangely btrfs scrub found no errors.  I'll forward the
oops to the btrfs list.
-BEGIN PGP SIGNATURE-
Version: GnuPG v2.0.19 (GNU/Linux)
Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/

iEYEARECAAYFAk+In/EACgkQGcb56gMuC60OdwCfTxJXzutYj6MGO7itU7ZSi5et
lvgAoKBfJk3Z3Kn4UJBq5Zlg2PvqM6Oi
=1Rqu
-END PGP SIGNATURE-

drm-next i915 regression? ( was: Re: PCI resources above 4GB)

[Steven Newbury]

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1

On 13/04/12 18:38, Steven Newbury wrote:
> On 13/04/12 17:17, Yinghai Lu wrote:
 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 include
> 
>> for-pci-hostbridge-cleanup for-pci-busn-alloc 
>> for-pci-root-bus-hotplug for-pci-for-each-res-addon at plus 7 
>> patches.
> 
>> maybe there is some problem with for-pci-for-each-res-addon.
> 
>> just rebase for-pci-res-alloc to for-pci-root-bus-hotplug. Please
>>  check if the problem still there.
> 
> Still Oopses.  I'm going to try linus/master.  Perhaps it's a 
> filesystem corruption triggering it?  I do find it a little
> suspicious that it occurs in "btrfs:find_workspace" though, code
> which deals with memory allocations...
Damn. It still oopses with my linus tracking branch!  I'm going to
restore from backup and see if it still happens.
-BEGIN PGP SIGNATURE-
Version: GnuPG v2.0.19 (GNU/Linux)
Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/

iEYEARECAAYFAk+IbJ8ACgkQGcb56gMuC60bVQCfbIQEd+kpJBrXdeiz/sfJOCC2
f9oAnA4DYSOD1ApvbMl937dxG2i6SYDv
=uZ3A
-END PGP SIGNATURE-

drm-next i915 regression? ( was: Re: PCI resources above 4GB)

[Steven Newbury]

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1

On 13/04/12 17:17, Yinghai Lu wrote:
>>> 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 include
> 
> for-pci-hostbridge-cleanup for-pci-busn-alloc 
> for-pci-root-bus-hotplug for-pci-for-each-res-addon at plus 7
> patches.
> 
> maybe there is some problem with for-pci-for-each-res-addon.
> 
> just rebase for-pci-res-alloc to for-pci-root-bus-hotplug. Please 
> check if the problem still there.
> 
Still Oopses.  I'm going to try linus/master.  Perhaps it's a
filesystem corruption triggering it?  I do find it a little suspicious
that it occurs in "btrfs:find_workspace" though, code which deals with
memory allocations...
-BEGIN PGP SIGNATURE-
Version: GnuPG v2.0.19 (GNU/Linux)
Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/

iEYEARECAAYFAk+IZHsACgkQGcb56gMuC62WhQCgkVBccCKKLqjL1S7f+4wzXnT7
DbsAn2wQNiQLGo95Q3W9bWu6n5Q3xqr8
=Rtn+
-END PGP SIGNATURE-

btrfs oops [was Re: drm-next i915 regression? ( was: Re: PCI resources above 4GB)]

[Steven Newbury]

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1

On 13/04/12 17:17, Yinghai Lu wrote:
>>> 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 include
> 
> for-pci-hostbridge-cleanup for-pci-busn-alloc 
> for-pci-root-bus-hotplug for-pci-for-each-res-addon at plus 7
> patches.
> 
> maybe there is some problem with for-pci-for-each-res-addon.
> 
> just rebase for-pci-res-alloc to for-pci-root-bus-hotplug. Please 
> check if the problem still there.
> 
> Thanks
> 
> Yinghai

BTW, previously, I was based on your for-pci-busn-alloc branch, didn't
see any problems there.

Recompiling now with a clean merge of updated for-pci-res-alloc on top
of my linus tracking branch...
-BEGIN PGP SIGNATURE-
Version: GnuPG v2.0.19 (GNU/Linux)
Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/

iEYEARECAAYFAk+IXpEACgkQGcb56gMuC63ubwCgkyr2d4Xp/4OpLo4ehIYrabtO
/SgAoKDaYPOxX9qRznUjUIoYAmPF3thA
=s+mx
-END PGP SIGNATURE-

drm-next i915 regression? ( was: Re: PCI resources above 4GB)

[Steven Newbury]

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1

On 13/04/12 16:23, Steven Newbury wrote:
> On 13/04/12 15:19, Steven Newbury wrote:
>> On 13/04/12 15:13, Daniel Vetter wrote:
>>> On Fri, Apr 13, 2012 at 03:08:36PM +0100, Steven Newbury
>>> wrote:
 -BEGIN PGP SIGNED MESSAGE- Hash: SHA1
 
 On 13/04/12 14:52, Steven Newbury wrote:
> On Fri, 13 Apr 2012, 14:26:19 BST, Steven Newbury 
>  wrote:
> 
>> -BEGIN PGP SIGNED MESSAGE- Hash: SHA1
>> 
>> On 13/04/12 13:49, Steven Newbury wrote:
>>> On 13/04/12 12:58, Steven Newbury wrote:
>>> 
> It's not stable, crashes soon after GMA comes up. 
> (Could be unrelated breakage in linus/master? 
> Probably not but I will verify.)   I noticed the 
> high allocations are occuring from the top of
> 64-bit address-space, whilst /proc/cpuinfo shows
> only 48 bits of virtual addressing.   Could that be
> why..?
 To reply to myself again, I should have said crashes
  shortly after Xorg initialises using the intel
 driver, in both cases! I'm building a kernel now
 without the patch set to see if it's unrelated.   If
 it still dies I'll try applying your patch set to a
 branch without the changes from linus/master...
 (should have done that anyway...)
>>> 
>>> Okay, I instead created a branch from an older 3.4-rc1+
>>>  kernel tree, running it now, and it seems to be
>>> stable. Something perhaps in the newer tree not playing
>>> nicely. I'll see if I can bisect it, or at least base
>>> of rc2 if that works... (I'm a little wary of crashing
>>> the system too much and losing my btrfs filesystem...)
>> rc2 is fine as well.   Not sure what happened there, I 
>> need to be more careful about keeping a clean tree to
>> work from.
> I'm pretty sure the crash was a from a drm-next regression.
>  I'll try bisecting it
 Sorry, posted too soon!  Almost as I clicked on send it froze
  again (using rc2 + for-pci-res-alloc ).  I had problems with
  the earlier patches re. X/i915 stability.  Strange.  I'll
 see if I can track it down.
> 
>>> Please upgrade to the latest version of Linus' upstream git. A
>>>  few fixes for regressions in drm/i915 just landed there for
>>> -rc3. -Daniel
> 
>> Okay.  I'll try clean latest linus + for-pci-res-alloc.  Will 
>> report back.
> 
> 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??
-BEGIN PGP SIGNATURE-
Version: GnuPG v2.0.19 (GNU/Linux)
Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/

iEYEARECAAYFAk+ISyEACgkQGcb56gMuC63uRwCcCLm8yx1YVnTBSvT/9jx/IqEb
WcYAoJh5iceqZvDDGdJHV88YwEyEnM32
=jfup
-END PGP SIGNATURE-

drm-next i915 regression? ( was: Re: PCI resources above 4GB)

[Steven Newbury]

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1

On 13/04/12 15:19, Steven Newbury wrote:
> On 13/04/12 15:13, Daniel Vetter wrote:
>> On Fri, Apr 13, 2012 at 03:08:36PM +0100, Steven Newbury wrote:
>>> -BEGIN PGP SIGNED MESSAGE- Hash: SHA1
>>> 
>>> On 13/04/12 14:52, Steven Newbury wrote:
 On Fri, 13 Apr 2012, 14:26:19 BST, Steven Newbury 
  wrote:
 
> -BEGIN PGP SIGNED MESSAGE- Hash: SHA1
> 
> On 13/04/12 13:49, Steven Newbury wrote:
>> On 13/04/12 12:58, Steven Newbury wrote:
>> 
 It's not stable, crashes soon after GMA comes up. 
 (Could be unrelated breakage in linus/master? 
 Probably not but I will verify.)   I noticed the
 high allocations are occuring from the top of 64-bit
  address-space, whilst /proc/cpuinfo shows only 48 
 bits of virtual addressing.   Could that be why..?
>>> To reply to myself again, I should have said crashes 
>>> shortly after Xorg initialises using the intel driver,
>>>  in both cases! I'm building a kernel now without the 
>>> patch set to see if it's unrelated.   If it still dies
>>>  I'll try applying your patch set to a branch without 
>>> the changes from linus/master... (should have done that
>>> anyway...)
>> 
>> Okay, I instead created a branch from an older 3.4-rc1+ 
>> kernel tree, running it now, and it seems to be stable. 
>> Something perhaps in the newer tree not playing nicely. 
>> I'll see if I can bisect it, or at least base of rc2 if 
>> that works... (I'm a little wary of crashing the system 
>> too much and losing my btrfs filesystem...)
> rc2 is fine as well.   Not sure what happened there, I
> need to be more careful about keeping a clean tree to work
>  from.
 I'm pretty sure the crash was a from a drm-next regression. 
 I'll try bisecting it
>>> Sorry, posted too soon!  Almost as I clicked on send it froze 
>>> again (using rc2 + for-pci-res-alloc ).  I had problems with 
>>> the earlier patches re. X/i915 stability.  Strange.  I'll see 
>>> if I can track it down.
> 
>> Please upgrade to the latest version of Linus' upstream git. A 
>> few fixes for regressions in drm/i915 just landed there for -rc3.
>> -Daniel
> 
> Okay.  I'll try clean latest linus + for-pci-res-alloc.  Will 
> report back.
> 
Looks like either a btrfs regression or bad interaction with
for-pci-res-alloc.  Oops attached.
-BEGIN PGP SIGNATURE-
Version: GnuPG v2.0.19 (GNU/Linux)
Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/

iEYEARECAAYFAk+IROAACgkQGcb56gMuC63hFQCguhdhV6AUoNKHnasgD0zjqJXt
AwkAoKh8Rdrj3PqzuYUXpUkvyw3TujZV
=XiAW
-END PGP SIGNATURE-
-- next part --
Apr 13 15:10:02 infinity kernel: BUG: unable to handle kernel NULL pointer 
dereference at   (null)
Apr 13 15:10:02 infinity kernel: IP: [] 
find_workspace+0x92/0x190 [btrfs]
Apr 13 15:10:02 infinity kernel: PGD 7bfb2067 PUD d8978067 PMD 0 
Apr 13 15:10:02 infinity kernel: Oops:  [#1] SMP 
Apr 13 15:10:02 infinity kernel: CPU 1 
Apr 13 15:10:02 infinity kernel: Modules linked in: cryptd aes_x86_64 
aes_generic fuse fbcon bitblit fbcon_rotate fbcon_ccw fbcon_ud fbcon_cw 
softcursor font tileblit joydev arc4 dell_wmi sparse_keymap 8250_pnp 
dell_laptop dcdbas btusb bluetooth snd_hda_codec_idt crc16 microcode psmouse 
pcspkr iwl4965 iwlegacy snd_hda_intel mac80211 snd_hda_codec snd_hwdep tg3 
snd_pcm cfg80211 snd_page_alloc snd_timer snd soundcore wmi 8250 serial_core 
evdev smsc47m192 hwmon_vid tpm_tis tpm tpm_bios rfkill loop nfs nfs_acl 
auth_rpcgss fscache lockd sunrpc phc_intel mperf coretemp hwmon autofs4 
usb_storage usb_libusual uas btrfs zlib_deflate sd_mod pata_acpi ahci libahci 
ata_piix libata scsi_mod ehci_hcd uhci_hcd usbcore usb_common i915 video 
intel_agp intel_gtt cfbfillrect cfbimgblt cfbcopyarea i2c_algo_bit backlight 
drm_kms_helper drm agpgart
Apr 13 15:10:02 infinity kernel: 
Apr 13 15:10:02 infinity kernel: Pid: 2591, comm: btrfs-endio-2 Not tainted 
3.4.0-rc2-wl-00669-g502ad46 #110 Dell Inc. Latitude D830   
/0HN341
Apr 13 15:10:02 infinity kernel: RIP: 0010:[]  
[] find_workspace+0x92/0x190 [btrfs]
Apr 13 15:10:02 infinity kernel: RSP: 0018:880078e7fcc0  EFLAGS: 00010207
Apr 13 15:10:02 infinity kernel: RAX:  RBX: 0003 
RCX: 88007bde9000
Apr 13 15:10:02 infinity kernel: RDX: a029d500 RSI: dead00200200 
RDI: a029d4f6
Apr 13 15:10:02 infinity kernel: RBP: 880078e7fd50 R08: 0008 
R09: 4000
Apr 13 15:10:02 infinity kernel: R10: 0200 R11: 0200 
R12: 880078e7fcf8
Apr 13 15:10:02 infinity kernel: R13: a029d504 R14: a029d4f6 
R15: 880078e7fd10
Apr 13 15:10:02 infinity kernel: FS:  () 
GS:88011fd0() knlGS:
Apr 13 15:10:02 infinity kernel: CS:  0010 DS:  ES:  CR0: 

drm-next i915 regression? ( was: Re: PCI resources above 4GB)

[Daniel Vetter]

On Fri, Apr 13, 2012 at 03:08:36PM +0100, Steven Newbury wrote:
> -BEGIN PGP SIGNED MESSAGE-
> Hash: SHA1
> 
> On 13/04/12 14:52, Steven Newbury wrote:
> > On Fri, 13 Apr 2012, 14:26:19 BST, Steven Newbury
> >  wrote:
> > 
> >> -BEGIN PGP SIGNED MESSAGE- Hash: SHA1
> >> 
> >> On 13/04/12 13:49, Steven Newbury wrote:
> >>> On 13/04/12 12:58, Steven Newbury wrote:
> >>> 
> > It's not stable, crashes soon after GMA comes up. (Could be
> >  unrelated breakage in linus/master? Probably not but I
> > will verify.)   I noticed the high allocations are occuring
> > from the top of 64-bit address-space, whilst /proc/cpuinfo
> > shows only 48 bits of virtual addressing.   Could that be
> > why..?
>  To reply to myself again, I should have said crashes shortly 
>  after Xorg initialises using the intel driver, in both
>  cases! I'm building a kernel now without the patch set to see
>  if it's unrelated.   If it still dies I'll try applying your
>  patch set to a branch without the changes from
>  linus/master... (should have done that anyway...)
> >>> 
> >>> Okay, I instead created a branch from an older 3.4-rc1+ kernel 
> >>> tree, running it now, and it seems to be stable.   Something
> >>> perhaps in the newer tree not playing nicely.   I'll see if I
> >>> can bisect it, or at least base of rc2 if that works... (I'm a
> >>> little wary of crashing the system too much and losing my btrfs
> >>> filesystem...)
> >> rc2 is fine as well.   Not sure what happened there, I need to be
> >> more careful about keeping a clean tree to work from.
> > I'm pretty sure the crash was a from a drm-next regression. I'll
> > try bisecting it
> Sorry, posted too soon!  Almost as I clicked on send it froze again
> (using rc2 + for-pci-res-alloc ).  I had problems with the earlier
> patches re. X/i915 stability.  Strange.  I'll see if I can track it down.

Please upgrade to the latest version of Linus' upstream git. A few fixes
for regressions in drm/i915 just landed there for -rc3.
-Daniel
-- 
Daniel Vetter
Mail: daniel at ffwll.ch
Mobile: +41 (0)79 365 57 48

drm-next i915 regression? ( was: Re: PCI resources above 4GB)

[Steven Newbury]

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1

On 13/04/12 15:13, Daniel Vetter wrote:
> On Fri, Apr 13, 2012 at 03:08:36PM +0100, Steven Newbury wrote:
>> -BEGIN PGP SIGNED MESSAGE- Hash: SHA1
>> 
>> On 13/04/12 14:52, Steven Newbury wrote:
>>> On Fri, 13 Apr 2012, 14:26:19 BST, Steven Newbury 
>>>  wrote:
>>> 
 -BEGIN PGP SIGNED MESSAGE- Hash: SHA1
 
 On 13/04/12 13:49, Steven Newbury wrote:
> On 13/04/12 12:58, Steven Newbury wrote:
> 
>>> It's not stable, crashes soon after GMA comes up.
>>> (Could be unrelated breakage in linus/master? Probably
>>> not but I will verify.)   I noticed the high
>>> allocations are occuring from the top of 64-bit
>>> address-space, whilst /proc/cpuinfo shows only 48 bits
>>> of virtual addressing.   Could that be why..?
>> To reply to myself again, I should have said crashes
>> shortly after Xorg initialises using the intel driver, in
>> both cases! I'm building a kernel now without the patch
>> set to see if it's unrelated.   If it still dies I'll try
>> applying your patch set to a branch without the changes
>> from linus/master... (should have done that anyway...)
> 
> Okay, I instead created a branch from an older 3.4-rc1+
> kernel tree, running it now, and it seems to be stable.
> Something perhaps in the newer tree not playing nicely.
> I'll see if I can bisect it, or at least base of rc2 if
> that works... (I'm a little wary of crashing the system too
> much and losing my btrfs filesystem...)
 rc2 is fine as well.   Not sure what happened there, I need
 to be more careful about keeping a clean tree to work from.
>>> I'm pretty sure the crash was a from a drm-next regression.
>>> I'll try bisecting it
>> Sorry, posted too soon!  Almost as I clicked on send it froze
>> again (using rc2 + for-pci-res-alloc ).  I had problems with the
>> earlier patches re. X/i915 stability.  Strange.  I'll see if I
>> can track it down.
> 
> Please upgrade to the latest version of Linus' upstream git. A few
> fixes for regressions in drm/i915 just landed there for -rc3. 
> -Daniel

Okay.  I'll try clean latest linus + for-pci-res-alloc.  Will report back.

-BEGIN PGP SIGNATURE-
Version: GnuPG v2.0.19 (GNU/Linux)
Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/

iEYEARECAAYFAk+INg4ACgkQGcb56gMuC60pJgCfS/g2k3mzIqU34de/Y4wTvfCP
+hwAmQEEdgQ/y0QvDbPffNZ6izqs2Dce
=EGwB
-END PGP SIGNATURE-

drm-next i915 regression? ( was: Re: PCI resources above 4GB)

[Steven Newbury]

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1

On 13/04/12 14:52, Steven Newbury wrote:
> On Fri, 13 Apr 2012, 14:26:19 BST, Steven Newbury
>  wrote:
> 
>> -BEGIN PGP SIGNED MESSAGE- Hash: SHA1
>> 
>> On 13/04/12 13:49, Steven Newbury wrote:
>>> On 13/04/12 12:58, Steven Newbury wrote:
>>> 
> It's not stable, crashes soon after GMA comes up. (Could be
>  unrelated breakage in linus/master? Probably not but I
> will verify.)   I noticed the high allocations are occuring
> from the top of 64-bit address-space, whilst /proc/cpuinfo
> shows only 48 bits of virtual addressing.   Could that be
> why..?
 To reply to myself again, I should have said crashes shortly 
 after Xorg initialises using the intel driver, in both
 cases! I'm building a kernel now without the patch set to see
 if it's unrelated.   If it still dies I'll try applying your
 patch set to a branch without the changes from
 linus/master... (should have done that anyway...)
>>> 
>>> Okay, I instead created a branch from an older 3.4-rc1+ kernel 
>>> tree, running it now, and it seems to be stable.   Something
>>> perhaps in the newer tree not playing nicely.   I'll see if I
>>> can bisect it, or at least base of rc2 if that works... (I'm a
>>> little wary of crashing the system too much and losing my btrfs
>>> filesystem...)
>> rc2 is fine as well.   Not sure what happened there, I need to be
>> more careful about keeping a clean tree to work from.
> I'm pretty sure the crash was a from a drm-next regression. I'll
> try bisecting it
Sorry, posted too soon!  Almost as I clicked on send it froze again
(using rc2 + for-pci-res-alloc ).  I had problems with the earlier
patches re. X/i915 stability.  Strange.  I'll see if I can track it down.
-BEGIN PGP SIGNATURE-
Version: GnuPG v2.0.19 (GNU/Linux)
Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/

iEYEARECAAYFAk+IM2QACgkQGcb56gMuC63IqACgpvN/bOqt/DWR45Kq00D4T2m0
tGoAn0cSN1eNxiHSF1eIRJgkGT/VmJy4
=/wQF
-END PGP SIGNATURE-

drm-next i915 regression? ( was: Re: PCI resources above 4GB)

[Steven Newbury]

On Fri, 13 Apr 2012, 14:26:19 BST, Steven Newbury  
wrote:

> -BEGIN PGP SIGNED MESSAGE-
> Hash: SHA1
> 
> On 13/04/12 13:49, Steven Newbury wrote:
> > On 13/04/12 12:58, Steven Newbury wrote:
> > 
> > > > It's not stable, crashes soon after GMA comes up. (Could be 
> > > > unrelated breakage in linus/master? Probably not but I will 
> > > > verify.)?  I noticed the high allocations are occuring from the 
> > > > top of 64-bit address-space, whilst /proc/cpuinfo shows only
> > > > 48 bits of virtual addressing.?  Could that be why..?
> > > To reply to myself again, I should have said crashes shortly
> > > after Xorg initialises using the intel driver, in both cases!
> > > I'm building a kernel now without the patch set to see if it's 
> > > unrelated.?  If it still dies I'll try applying your patch set to
> > > a branch without the changes from linus/master... (should have
> > > done that anyway...)
> > 
> > Okay, I instead created a branch from an older 3.4-rc1+ kernel
> > tree, running it now, and it seems to be stable.?  Something perhaps
> > in the newer tree not playing nicely.?  I'll see if I can bisect it,
> > or at least base of rc2 if that works... (I'm a little wary of
> > crashing the system too much and losing my btrfs filesystem...)
> rc2 is fine as well.?  Not sure what happened there, I need to be more
> careful about keeping a clean tree to work from.
I'm pretty sure the crash was a from a drm-next regression. I'll try bisecting 
it

PCI resources above 4GB

[Steven Newbury]

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1

On 13/04/12 13:49, Steven Newbury wrote:
> On 13/04/12 12:58, Steven Newbury wrote:
> 
>>> It's not stable, crashes soon after GMA comes up. (Could be 
>>> unrelated breakage in linus/master? Probably not but I will 
>>> verify.)  I noticed the high allocations are occuring from the 
>>> top of 64-bit address-space, whilst /proc/cpuinfo shows only
>>> 48 bits of virtual addressing.  Could that be why..?
>> To reply to myself again, I should have said crashes shortly
>> after Xorg initialises using the intel driver, in both cases!
>> I'm building a kernel now without the patch set to see if it's 
>> unrelated.  If it still dies I'll try applying your patch set to
>> a branch without the changes from linus/master... (should have
>> done that anyway...)
> 
> Okay, I instead created a branch from an older 3.4-rc1+ kernel
> tree, running it now, and it seems to be stable.  Something perhaps
> in the newer tree not playing nicely.  I'll see if I can bisect it,
> or at least base of rc2 if that works... (I'm a little wary of
> crashing the system too much and losing my btrfs filesystem...)
rc2 is fine as well.  Not sure what happened there, I need to be more
careful about keeping a clean tree to work from.

Any idea about how to force the GMA >4G when the BIOS hasn't put it
into the middle of SystemRAM? (as it does when docked)
-BEGIN PGP SIGNATURE-
Version: GnuPG v2.0.19 (GNU/Linux)
Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/

iEYEARECAAYFAk+IKXsACgkQGcb56gMuC62+gACeLDg30iJiukq1pSfu2M1GJzZj
xGQAn0DekMqnLcrKXXn7rMwGFgRzJrsC
=k+WB
-END PGP SIGNATURE-

PCI resources above 4GB

[Steven Newbury]

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1

On 13/04/12 12:58, Steven Newbury wrote:

>> It's not stable, crashes soon after GMA comes up. (Could be 
>> unrelated breakage in linus/master? Probably not but I will 
>> verify.)  I noticed the high allocations are occuring from the
>> top of 64-bit address-space, whilst /proc/cpuinfo shows only 48
>> bits of virtual addressing.  Could that be why..?
> To reply to myself again, I should have said crashes shortly after 
> Xorg initialises using the intel driver, in both cases!  I'm
> building a kernel now without the patch set to see if it's
> unrelated.  If it still dies I'll try applying your patch set to a
> branch without the changes from linus/master... (should have done
> that anyway...)
> 
Okay, I instead created a branch from an older 3.4-rc1+ kernel tree,
running it now, and it seems to be stable.  Something perhaps in the
newer tree not playing nicely.  I'll see if I can bisect it, or at
least base of rc2 if that works... (I'm a little wary of crashing the
system too much and losing my btrfs filesystem...)
-BEGIN PGP SIGNATURE-
Version: GnuPG v2.0.19 (GNU/Linux)
Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/

iEYEARECAAYFAk+IIPAACgkQGcb56gMuC62tVQCgmCXiVuGmHa5wNbWHA6FRG8Sy
AJEAn3n+92rMqzSINTh8b4AWnpDSGYew
=opYH
-END PGP SIGNATURE-

PCI resources above 4GB

[Steven Newbury]

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1

On 13/04/12 12:45, Steven Newbury wrote:
> On Fri, 13 Apr 2012, 09:26:55 BST, Yinghai Lu 
> wrote:
> 
>> 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 find
> large aligned regions later on. I see code to default to
> top-down allocation was reverted, I guess I'm going to have
> to dig into the archive to find out why...
>> 
>> Please check attached patches that will find_resource with fit.
>> It may leave space for your hotplug devices.
>> 
>> PCI: Should add children device res to fail list PCI: Try to
>> allocate mem64 above 4G at first intel-gtt: Read 64bit for
>> gmar_bus_addr PCI: Make sure assign same align with large size
>> resource at first resource: make find_resource could return just
>> fit resource PCI: Don't allocate small resource in big empty
>> space. resource: only return range with needed align
>> 
>> You can get them from
>> 
>> 
>> git://git.kernel.org/pub/scm/linux/kernel/git/yinghai/linux-yinghai.git
>>
>> 
for-pci-res-alloc
> 
> I pulled this in on top of a branch with any of the prior PCI
> patches since they conflict anyway.
> 
> It's not stable, crashes soon after GMA comes up. (Could be
> unrelated breakage in linus/master? Probably not but I will
> verify.)  I noticed the high allocations are occuring from the top
> of 64-bit address-space, whilst /proc/cpuinfo shows only 48 bits of
> virtual addressing.  Could that be why..?
To reply to myself again, I should have said crashes shortly after
Xorg initialises using the intel driver, in both cases!  I'm building
a kernel now without the patch set to see if it's unrelated.  If it
still dies I'll try applying your patch set to a branch without the
changes from linus/master... (should have done that anyway...)

> 
> Also, when not docked GMA still isn't mapped high so there's no
> room for the 256M radeon pref mem.
> 
> Attached /proc/iomem output for docked and undocked.

-BEGIN PGP SIGNATURE-
Version: GnuPG v2.0.19 (GNU/Linux)
Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/

iEYEARECAAYFAk+IFPcACgkQGcb56gMuC61f9ACfQc9AqY5YVMEDAvdufMkSpg9b
cbsAnRm6sA7VGfmzTyOldSJfV6Qt6ea8
=RGn5
-END PGP SIGNATURE-

PCI resources above 4GB

[Steven Newbury]

On Fri, 13 Apr 2012, 09:26:55 BST, Yinghai Lu  wrote:

> 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 find large aligned regions later on.
> > > > ?I see code to default to top-down allocation was reverted, I
> > > > guess I'm going to have to dig into the archive to find out why...
> 
> Please check attached patches that will find_resource with fit. It may
> leave space for your hotplug devices.
> 
>? ?  PCI: Should add children device res to fail list
>? ?  PCI: Try to allocate mem64 above 4G at first
>? ?  intel-gtt: Read 64bit for gmar_bus_addr
>? ?  PCI: Make sure assign same align with large size resource at first
>? ?  resource: make find_resource could return just fit resource
>? ?  PCI: Don't allocate small resource in big empty space.
>? ?  resource: only return range with needed align
> 
> You can get them from
> 
>? ? ? ? ? ?  
> git://git.kernel.org/pub/scm/linux/kernel/git/yinghai/linux-yinghai.git
> for-pci-res-alloc

I pulled this in on top of a branch with any of the prior PCI patches since 
they conflict anyway.

It's not stable, crashes soon after GMA comes up. (Could be unrelated breakage 
in linus/master? Probably not but I will verify.)  I noticed the high 
allocations are occuring from the top of 64-bit address-space, whilst 
/proc/cpuinfo shows only 48 bits of virtual addressing.  Could that be why..?

Also, when not docked GMA still isn't mapped high so there's no room for the 
256M radeon pref mem.

Attached /proc/iomem output for docked and undocked.
-- next part --
An embedded and charset-unspecified text was scrubbed...
Name: iomem.undocked
URL: 

-- next part --
An embedded and charset-unspecified text was scrubbed...
Name: iomem.test
URL: 

PCI resources above 4GB

[Steven Newbury]

On Fri, 13 Apr 2012, 09:26:55 BST, Yinghai Lu  wrote:

> 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 find large aligned regions later on.
> > > > ?I see code to default to top-down allocation was reverted, I
> > > > guess I'm going to have to dig into the archive to find out why...
> 
> Please check attached patches that will find_resource with fit. It may
> leave space for your hotplug devices.
> 
>? ?  PCI: Should add children device res to fail list
>? ?  PCI: Try to allocate mem64 above 4G at first
>? ?  intel-gtt: Read 64bit for gmar_bus_addr
>? ?  PCI: Make sure assign same align with large size resource at first
>? ?  resource: make find_resource could return just fit resource
>? ?  PCI: Don't allocate small resource in big empty space.
>? ?  resource: only return range with needed align
> 
> You can get them from
> 
>? ? ? ? ? ?  
> git://git.kernel.org/pub/scm/linux/kernel/git/yinghai/linux-yinghai.git
> for-pci-res-alloc
> 
Thanks Yinghai, I'll give it a spin.

drm-next i915 regression? ( was: Re: PCI resources above 4GB)

[Yinghai Lu]

>> 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 include

for-pci-hostbridge-cleanup
for-pci-busn-alloc
for-pci-root-bus-hotplug
for-pci-for-each-res-addon
at plus 7 patches.

maybe there is some problem with for-pci-for-each-res-addon.

just rebase for-pci-res-alloc to for-pci-root-bus-hotplug. Please
check if the problem still there.

Thanks

Yinghai

PCI resources above 4GB

[Yinghai Lu]

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 find large aligned regions later on. ?I see code to
>> > default to top-down allocation was reverted, I guess I'm going to have
>> > to dig into the archive to find out why...

Please check attached patches that will find_resource with fit. It may
leave space for your hotplug devices.

  PCI: Should add children device res to fail list
  PCI: Try to allocate mem64 above 4G at first
  intel-gtt: Read 64bit for gmar_bus_addr
  PCI: Make sure assign same align with large size resource at first
  resource: make find_resource could return just fit resource
  PCI: Don't allocate small resource in big empty space.
  resource: only return range with needed align

You can get them from

   git://git.kernel.org/pub/scm/linux/kernel/git/yinghai/linux-yinghai.git
for-pci-res-alloc

Thanks

Yinghai
-- next part --
A non-text attachment was scrubbed...
Name: assign_sorting.patch
Type: application/octet-stream
Size: 1259 bytes
Desc: not available
URL: 

-- next part --
A non-text attachment was scrubbed...
Name: find_one_just_fit_1.patch
Type: application/octet-stream
Size: 2803 bytes
Desc: not available
URL: 

-- next part --
A non-text attachment was scrubbed...
Name: find_one_just_fit_2.patch
Type: application/octet-stream
Size: 11856 bytes
Desc: not available
URL: 

-- next part --
A non-text attachment was scrubbed...
Name: save_big_align.patch
Type: application/octet-stream
Size: 1096 bytes
Desc: not available
URL: 

Re: PCI resources above 4GB

[Steven Newbury]

On Fri, 13 Apr 2012, 09:26:55 BST, Yinghai Lu ying...@kernel.org wrote:

 On Thu, Apr 12, 2012 at 9:40 AM, Steven Newbury st...@snewbury.org.uk
 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 find large aligned regions later on.
 I see code to default to top-down allocation was reverted, I
guess I'm going to have to dig into the archive to find out why...
 
 Please check attached patches that will find_resource with fit. It may
 leave space for your hotplug devices.
 
     PCI: Should add children device res to fail list
     PCI: Try to allocate mem64 above 4G at first
     intel-gtt: Read 64bit for gmar_bus_addr
     PCI: Make sure assign same align with large size resource at first
     resource: make find_resource could return just fit resource
     PCI: Don't allocate small resource in big empty space.
     resource: only return range with needed align
 
 You can get them from
 
             
 git://git.kernel.org/pub/scm/linux/kernel/git/yinghai/linux-yinghai.git
 for-pci-res-alloc
 
Thanks Yinghai, I'll give it a spin.

___
dri-devel mailing list
dri-devel@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/dri-devel

Re: PCI resources above 4GB

[Steven Newbury]

On Fri, 13 Apr 2012, 09:26:55 BST, Yinghai Lu ying...@kernel.org wrote:

 On Thu, Apr 12, 2012 at 9:40 AM, Steven Newbury st...@snewbury.org.uk
 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 find large aligned regions later on.
 I see code to default to top-down allocation was reverted, I
guess I'm going to have to dig into the archive to find out why...
 
 Please check attached patches that will find_resource with fit. It may
 leave space for your hotplug devices.
 
     PCI: Should add children device res to fail list
     PCI: Try to allocate mem64 above 4G at first
     intel-gtt: Read 64bit for gmar_bus_addr
     PCI: Make sure assign same align with large size resource at first
     resource: make find_resource could return just fit resource
     PCI: Don't allocate small resource in big empty space.
     resource: only return range with needed align
 
 You can get them from
 
             
 git://git.kernel.org/pub/scm/linux/kernel/git/yinghai/linux-yinghai.git
 for-pci-res-alloc

I pulled this in on top of a branch with any of the prior PCI patches since 
they conflict anyway.

It's not stable, crashes soon after GMA comes up. (Could be unrelated breakage 
in linus/master? Probably not but I will verify.)  I noticed the high 
allocations are occuring from the top of 64-bit address-space, whilst 
/proc/cpuinfo shows only 48 bits of virtual addressing.  Could that be why..?

Also, when not docked GMA still isn't mapped high so there's no room for the 
256M radeon pref mem.

Attached /proc/iomem output for docked and undocked.- : reserved
0001-0009efff : System RAM
0009f000-0009 : reserved
000c-000c7fff : Video ROM
000cf000-000c : Adapter ROM
000f-000f : System ROM
0010-df65a7ff : System RAM
  0100-0136ddbd : Kernel code
  0136ddbe-0169127f : Kernel data
  0172f000-01809fff : Kernel bss
df65a800-dfff : reserved
  df65a800-df6f : pnp 00:0d
  df70-df7f : pnp 00:0d
e000-efff : :00:02.0
f000-f01f : PCI Bus :0d
f020-f0200fff : Intel Flush Page
f690-f69f : PCI Bus :09
  f69f-f69f : :09:00.0
f69f-f69f : tg3
f6a0-f6bf : PCI Bus :0d
f6c0-f6cf : PCI Bus :0c
  f6cfe000-f6cf : :0c:00.0
f6cfe000-f6cf : iwl4965
f6dfb700-f6dfb7ff : :00:1f.3
f6dfb800-f6dfbfff : :00:1f.2
  f6dfb800-f6dfbfff : ahci
f6dfc000-f6df : :00:1b.0
  f6dfc000-f6df : ICH HD audio
f6e0-f6ef : :00:02.0
f6f0-f6ff : :00:02.1
f800-fbff : PCI MMCONFIG  [bus 00-3f]
  f800-fbff : reserved
f800-fbff : pnp 00:0d
fec0-fec0 : reserved
  fec0-fec003ff : IOAPIC 0
fed0-fed003ff : HPET 0
  fed0-fed003ff : pnp 00:08
fed18000-fed1bfff : reserved
  fed18000-fed1bfff : pnp 00:0d
fed1c000-fed1c3ff : :00:1d.7
  fed1c000-fed1c3ff : ehci_hcd
fed1c400-fed1c7ff : :00:1a.7
  fed1c400-fed1c7ff : ehci_hcd
fed2-fed8 : reserved
  fed2-fed3 : pnp 00:0d
  fed4-fed44fff : pnp 00:0a
  fed45000-fed8 : pnp 00:0d
feda-feda5fff : reserved
  feda-feda3fff : pnp 00:0d
  feda4000-feda4fff : pnp 00:0d
  feda5000-feda5fff : pnp 00:0d
feda6000-feda6fff : pnp 00:0d
fee0-fee0 : reserved
  fee0-fee0 : pnp 00:0d
fee0-fee00fff : Local APIC
ffa0-ffbf : pnp 00:0d
ffc0-ffdf : PCI Bus :0b
ffe0- : reserved
  ffe0- : pnp 00:0d
1-11fff : System RAM
fffa0-fffbf : PCI Bus :09
fffc0-fffdf : PCI Bus :0c
fffe0-f : PCI Bus :0b
- : reserved
0001-0009efff : System RAM
0009f000-0009 : reserved
000c-000c7fff : Video ROM
000cf000-000c : Adapter ROM
000f-000f : System ROM
0010-df65a7ff : System RAM
  0100-0136ddbd : Kernel code
  0136ddbe-0169127f : Kernel data
  0172f000-01809fff : Kernel bss
df65a800-dfff : reserved
  df65a800-df6f : pnp 00:0e
  df70-df7f : pnp 00:0e
e000-efff : PCI Bus :03
  e000-efff : PCI Bus :04
e000-efff : :04:00.0
f000-ffff : Intel Flush Page
f670-f68f : PCI Bus :03
  f670-f68f : PCI Bus :04
f67dc000-f67d : :04:00.1
  f67dc000-f67d : ICH HD audio
f67e-f67f : :04:00.0
f680-f681 : :04:00.0
f690-f69f : PCI Bus :09
  f69f-f69f : :09:00.0
f69f-f69f : tg3
f6a0-f6bf : PCI Bus :0d
f6c0-f6cf : PCI Bus :0c
  f6cfe000-f6cf : :0c:00.0
f6cfe000-f6cf : iwl4965
f6dfb700-f6dfb7ff : :00:1f.3
f6dfb800-f6dfbfff : :00:1f.2
  f6dfb800-f6dfbfff : ahci
f6dfc000-f6df : :00:1b.0
  f6dfc000-f6df : ICH HD audio

Re: PCI resources above 4GB

[Steven Newbury]

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1

On 13/04/12 12:45, Steven Newbury wrote:
 On Fri, 13 Apr 2012, 09:26:55 BST, Yinghai Lu ying...@kernel.org
 wrote:
 
 On Thu, Apr 12, 2012 at 9:40 AM, Steven Newbury
 st...@snewbury.org.uk 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 find
 large aligned regions later on. I see code to default to
 top-down allocation was reverted, I guess I'm going to have
 to dig into the archive to find out why...
 
 Please check attached patches that will find_resource with fit.
 It may leave space for your hotplug devices.
 
 PCI: Should add children device res to fail list PCI: Try to
 allocate mem64 above 4G at first intel-gtt: Read 64bit for
 gmar_bus_addr PCI: Make sure assign same align with large size
 resource at first resource: make find_resource could return just
 fit resource PCI: Don't allocate small resource in big empty
 space. resource: only return range with needed align
 
 You can get them from
 
 
 git://git.kernel.org/pub/scm/linux/kernel/git/yinghai/linux-yinghai.git

 
for-pci-res-alloc
 
 I pulled this in on top of a branch with any of the prior PCI
 patches since they conflict anyway.
 
 It's not stable, crashes soon after GMA comes up. (Could be
 unrelated breakage in linus/master? Probably not but I will
 verify.)  I noticed the high allocations are occuring from the top
 of 64-bit address-space, whilst /proc/cpuinfo shows only 48 bits of
 virtual addressing.  Could that be why..?
To reply to myself again, I should have said crashes shortly after
Xorg initialises using the intel driver, in both cases!  I'm building
a kernel now without the patch set to see if it's unrelated.  If it
still dies I'll try applying your patch set to a branch without the
changes from linus/master... (should have done that anyway...)

 
 Also, when not docked GMA still isn't mapped high so there's no
 room for the 256M radeon pref mem.
 
 Attached /proc/iomem output for docked and undocked.

-BEGIN PGP SIGNATURE-
Version: GnuPG v2.0.19 (GNU/Linux)
Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/

iEYEARECAAYFAk+IFPcACgkQGcb56gMuC61f9ACfQc9AqY5YVMEDAvdufMkSpg9b
cbsAnRm6sA7VGfmzTyOldSJfV6Qt6ea8
=RGn5
-END PGP SIGNATURE-
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/dri-devel

drm-next i915 regression? ( was: Re: PCI resources above 4GB)

[Steven Newbury]

On Fri, 13 Apr 2012, 14:26:19 BST, Steven Newbury st...@snewbury.org.uk wrote:

 -BEGIN PGP SIGNED MESSAGE-
 Hash: SHA1
 
 On 13/04/12 13:49, Steven Newbury wrote:
  On 13/04/12 12:58, Steven Newbury wrote:
  
It's not stable, crashes soon after GMA comes up. (Could be 
unrelated breakage in linus/master? Probably not but I will 
verify.)   I noticed the high allocations are occuring from the 
top of 64-bit address-space, whilst /proc/cpuinfo shows only
48 bits of virtual addressing.   Could that be why..?
   To reply to myself again, I should have said crashes shortly
   after Xorg initialises using the intel driver, in both cases!
   I'm building a kernel now without the patch set to see if it's 
   unrelated.   If it still dies I'll try applying your patch set to
   a branch without the changes from linus/master... (should have
   done that anyway...)
  
  Okay, I instead created a branch from an older 3.4-rc1+ kernel
  tree, running it now, and it seems to be stable.   Something perhaps
  in the newer tree not playing nicely.   I'll see if I can bisect it,
  or at least base of rc2 if that works... (I'm a little wary of
  crashing the system too much and losing my btrfs filesystem...)
 rc2 is fine as well.   Not sure what happened there, I need to be more
 careful about keeping a clean tree to work from.
I'm pretty sure the crash was a from a drm-next regression. I'll try bisecting 
it
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/dri-devel

Re: drm-next i915 regression? ( was: Re: PCI resources above 4GB)

[Steven Newbury]

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1

On 13/04/12 15:13, Daniel Vetter wrote:
 On Fri, Apr 13, 2012 at 03:08:36PM +0100, Steven Newbury wrote:
 -BEGIN PGP SIGNED MESSAGE- Hash: SHA1
 
 On 13/04/12 14:52, Steven Newbury wrote:
 On Fri, 13 Apr 2012, 14:26:19 BST, Steven Newbury 
 st...@snewbury.org.uk wrote:
 
 -BEGIN PGP SIGNED MESSAGE- Hash: SHA1
 
 On 13/04/12 13:49, Steven Newbury wrote:
 On 13/04/12 12:58, Steven Newbury wrote:
 
 It's not stable, crashes soon after GMA comes up.
 (Could be unrelated breakage in linus/master? Probably
 not but I will verify.)   I noticed the high
 allocations are occuring from the top of 64-bit
 address-space, whilst /proc/cpuinfo shows only 48 bits
 of virtual addressing.   Could that be why..?
 To reply to myself again, I should have said crashes
 shortly after Xorg initialises using the intel driver, in
 both cases! I'm building a kernel now without the patch
 set to see if it's unrelated.   If it still dies I'll try
 applying your patch set to a branch without the changes
 from linus/master... (should have done that anyway...)
 
 Okay, I instead created a branch from an older 3.4-rc1+
 kernel tree, running it now, and it seems to be stable.
 Something perhaps in the newer tree not playing nicely.
 I'll see if I can bisect it, or at least base of rc2 if
 that works... (I'm a little wary of crashing the system too
 much and losing my btrfs filesystem...)
 rc2 is fine as well.   Not sure what happened there, I need
 to be more careful about keeping a clean tree to work from.
 I'm pretty sure the crash was a from a drm-next regression.
 I'll try bisecting it
 Sorry, posted too soon!  Almost as I clicked on send it froze
 again (using rc2 + for-pci-res-alloc ).  I had problems with the
 earlier patches re. X/i915 stability.  Strange.  I'll see if I
 can track it down.
 
 Please upgrade to the latest version of Linus' upstream git. A few
 fixes for regressions in drm/i915 just landed there for -rc3. 
 -Daniel

Okay.  I'll try clean latest linus + for-pci-res-alloc.  Will report back.

-BEGIN PGP SIGNATURE-
Version: GnuPG v2.0.19 (GNU/Linux)
Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/

iEYEARECAAYFAk+INg4ACgkQGcb56gMuC60pJgCfS/g2k3mzIqU34de/Y4wTvfCP
+hwAmQEEdgQ/y0QvDbPffNZ6izqs2Dce
=EGwB
-END PGP SIGNATURE-
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/dri-devel

Re: drm-next i915 regression? ( was: Re: PCI resources above 4GB)

[Steven Newbury]

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1

On 13/04/12 15:19, Steven Newbury wrote:
 On 13/04/12 15:13, Daniel Vetter wrote:
 On Fri, Apr 13, 2012 at 03:08:36PM +0100, Steven Newbury wrote:
 -BEGIN PGP SIGNED MESSAGE- Hash: SHA1
 
 On 13/04/12 14:52, Steven Newbury wrote:
 On Fri, 13 Apr 2012, 14:26:19 BST, Steven Newbury 
 st...@snewbury.org.uk wrote:
 
 -BEGIN PGP SIGNED MESSAGE- Hash: SHA1
 
 On 13/04/12 13:49, Steven Newbury wrote:
 On 13/04/12 12:58, Steven Newbury wrote:
 
 It's not stable, crashes soon after GMA comes up. 
 (Could be unrelated breakage in linus/master? 
 Probably not but I will verify.)   I noticed the
 high allocations are occuring from the top of 64-bit
  address-space, whilst /proc/cpuinfo shows only 48 
 bits of virtual addressing.   Could that be why..?
 To reply to myself again, I should have said crashes 
 shortly after Xorg initialises using the intel driver,
  in both cases! I'm building a kernel now without the 
 patch set to see if it's unrelated.   If it still dies
  I'll try applying your patch set to a branch without 
 the changes from linus/master... (should have done that
 anyway...)
 
 Okay, I instead created a branch from an older 3.4-rc1+ 
 kernel tree, running it now, and it seems to be stable. 
 Something perhaps in the newer tree not playing nicely. 
 I'll see if I can bisect it, or at least base of rc2 if 
 that works... (I'm a little wary of crashing the system 
 too much and losing my btrfs filesystem...)
 rc2 is fine as well.   Not sure what happened there, I
 need to be more careful about keeping a clean tree to work
  from.
 I'm pretty sure the crash was a from a drm-next regression. 
 I'll try bisecting it
 Sorry, posted too soon!  Almost as I clicked on send it froze 
 again (using rc2 + for-pci-res-alloc ).  I had problems with 
 the earlier patches re. X/i915 stability.  Strange.  I'll see 
 if I can track it down.
 
 Please upgrade to the latest version of Linus' upstream git. A 
 few fixes for regressions in drm/i915 just landed there for -rc3.
 -Daniel
 
 Okay.  I'll try clean latest linus + for-pci-res-alloc.  Will 
 report back.
 
Looks like either a btrfs regression or bad interaction with
for-pci-res-alloc.  Oops attached.
-BEGIN PGP SIGNATURE-
Version: GnuPG v2.0.19 (GNU/Linux)
Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/

iEYEARECAAYFAk+IROAACgkQGcb56gMuC63hFQCguhdhV6AUoNKHnasgD0zjqJXt
AwkAoKh8Rdrj3PqzuYUXpUkvyw3TujZV
=XiAW
-END PGP SIGNATURE-
Apr 13 15:10:02 infinity kernel: BUG: unable to handle kernel NULL pointer 
dereference at   (null)
Apr 13 15:10:02 infinity kernel: IP: [a02778d0] 
find_workspace+0x92/0x190 [btrfs]
Apr 13 15:10:02 infinity kernel: PGD 7bfb2067 PUD d8978067 PMD 0 
Apr 13 15:10:02 infinity kernel: Oops:  [#1] SMP 
Apr 13 15:10:02 infinity kernel: CPU 1 
Apr 13 15:10:02 infinity kernel: Modules linked in: cryptd aes_x86_64 
aes_generic fuse fbcon bitblit fbcon_rotate fbcon_ccw fbcon_ud fbcon_cw 
softcursor font tileblit joydev arc4 dell_wmi sparse_keymap 8250_pnp 
dell_laptop dcdbas btusb bluetooth snd_hda_codec_idt crc16 microcode psmouse 
pcspkr iwl4965 iwlegacy snd_hda_intel mac80211 snd_hda_codec snd_hwdep tg3 
snd_pcm cfg80211 snd_page_alloc snd_timer snd soundcore wmi 8250 serial_core 
evdev smsc47m192 hwmon_vid tpm_tis tpm tpm_bios rfkill loop nfs nfs_acl 
auth_rpcgss fscache lockd sunrpc phc_intel mperf coretemp hwmon autofs4 
usb_storage usb_libusual uas btrfs zlib_deflate sd_mod pata_acpi ahci libahci 
ata_piix libata scsi_mod ehci_hcd uhci_hcd usbcore usb_common i915 video 
intel_agp intel_gtt cfbfillrect cfbimgblt cfbcopyarea i2c_algo_bit backlight 
drm_kms_helper drm agpgart
Apr 13 15:10:02 infinity kernel: 
Apr 13 15:10:02 infinity kernel: Pid: 2591, comm: btrfs-endio-2 Not tainted 
3.4.0-rc2-wl-00669-g502ad46 #110 Dell Inc. Latitude D830   
/0HN341
Apr 13 15:10:02 infinity kernel: RIP: 0010:[a02778d0]  
[a02778d0] find_workspace+0x92/0x190 [btrfs]
Apr 13 15:10:02 infinity kernel: RSP: 0018:880078e7fcc0  EFLAGS: 00010207
Apr 13 15:10:02 infinity kernel: RAX:  RBX: 0003 
RCX: 88007bde9000
Apr 13 15:10:02 infinity kernel: RDX: a029d500 RSI: dead00200200 
RDI: a029d4f6
Apr 13 15:10:02 infinity kernel: RBP: 880078e7fd50 R08: 0008 
R09: 4000
Apr 13 15:10:02 infinity kernel: R10: 0200 R11: 0200 
R12: 880078e7fcf8
Apr 13 15:10:02 infinity kernel: R13: a029d504 R14: a029d4f6 
R15: 880078e7fd10
Apr 13 15:10:02 infinity kernel: FS:  () 
GS:88011fd0() knlGS:
Apr 13 15:10:02 infinity kernel: CS:  0010 DS:  ES:  CR0: 
8005003b
Apr 13 15:10:02 infinity kernel: CR2:  CR3: 7bfe6000 
CR4: 07e0
Apr 13 15:10:02 infinity kernel: DR0:  DR1:  
DR2: 

Re: drm-next i915 regression? ( was: Re: PCI resources above 4GB)

[Steven Newbury]

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1

On 13/04/12 16:23, Steven Newbury wrote:
 On 13/04/12 15:19, Steven Newbury wrote:
 On 13/04/12 15:13, Daniel Vetter wrote:
 On Fri, Apr 13, 2012 at 03:08:36PM +0100, Steven Newbury
 wrote:
 -BEGIN PGP SIGNED MESSAGE- Hash: SHA1
 
 On 13/04/12 14:52, Steven Newbury wrote:
 On Fri, 13 Apr 2012, 14:26:19 BST, Steven Newbury 
 st...@snewbury.org.uk wrote:
 
 -BEGIN PGP SIGNED MESSAGE- Hash: SHA1
 
 On 13/04/12 13:49, Steven Newbury wrote:
 On 13/04/12 12:58, Steven Newbury wrote:
 
 It's not stable, crashes soon after GMA comes up. 
 (Could be unrelated breakage in linus/master? 
 Probably not but I will verify.)   I noticed the 
 high allocations are occuring from the top of
 64-bit address-space, whilst /proc/cpuinfo shows
 only 48 bits of virtual addressing.   Could that be
 why..?
 To reply to myself again, I should have said crashes
  shortly after Xorg initialises using the intel
 driver, in both cases! I'm building a kernel now
 without the patch set to see if it's unrelated.   If
 it still dies I'll try applying your patch set to a
 branch without the changes from linus/master...
 (should have done that anyway...)
 
 Okay, I instead created a branch from an older 3.4-rc1+
  kernel tree, running it now, and it seems to be
 stable. Something perhaps in the newer tree not playing
 nicely. I'll see if I can bisect it, or at least base
 of rc2 if that works... (I'm a little wary of crashing
 the system too much and losing my btrfs filesystem...)
 rc2 is fine as well.   Not sure what happened there, I 
 need to be more careful about keeping a clean tree to
 work from.
 I'm pretty sure the crash was a from a drm-next regression.
  I'll try bisecting it
 Sorry, posted too soon!  Almost as I clicked on send it froze
  again (using rc2 + for-pci-res-alloc ).  I had problems with
  the earlier patches re. X/i915 stability.  Strange.  I'll
 see if I can track it down.
 
 Please upgrade to the latest version of Linus' upstream git. A
  few fixes for regressions in drm/i915 just landed there for
 -rc3. -Daniel
 
 Okay.  I'll try clean latest linus + for-pci-res-alloc.  Will 
 report back.
 
 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??
-BEGIN PGP SIGNATURE-
Version: GnuPG v2.0.19 (GNU/Linux)
Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/

iEYEARECAAYFAk+ISyEACgkQGcb56gMuC63uRwCcCLm8yx1YVnTBSvT/9jx/IqEb
WcYAoJh5iceqZvDDGdJHV88YwEyEnM32
=jfup
-END PGP SIGNATURE-
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/dri-devel

Re: drm-next i915 regression? ( was: Re: PCI resources above 4GB)

[Yinghai Lu]

 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 include

for-pci-hostbridge-cleanup
for-pci-busn-alloc
for-pci-root-bus-hotplug
for-pci-for-each-res-addon
at plus 7 patches.

maybe there is some problem with for-pci-for-each-res-addon.

just rebase for-pci-res-alloc to for-pci-root-bus-hotplug. Please
check if the problem still there.

Thanks

Yinghai
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/dri-devel

btrfs oops [was Re: drm-next i915 regression? ( was: Re: PCI resources above 4GB)]

[Steven Newbury]

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1

On 13/04/12 17:17, Yinghai Lu wrote:
 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 include
 
 for-pci-hostbridge-cleanup for-pci-busn-alloc 
 for-pci-root-bus-hotplug for-pci-for-each-res-addon at plus 7
 patches.
 
 maybe there is some problem with for-pci-for-each-res-addon.
 
 just rebase for-pci-res-alloc to for-pci-root-bus-hotplug. Please 
 check if the problem still there.
 
 Thanks
 
 Yinghai

BTW, previously, I was based on your for-pci-busn-alloc branch, didn't
see any problems there.

Recompiling now with a clean merge of updated for-pci-res-alloc on top
of my linus tracking branch...
-BEGIN PGP SIGNATURE-
Version: GnuPG v2.0.19 (GNU/Linux)
Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/

iEYEARECAAYFAk+IXpEACgkQGcb56gMuC63ubwCgkyr2d4Xp/4OpLo4ehIYrabtO
/SgAoKDaYPOxX9qRznUjUIoYAmPF3thA
=s+mx
-END PGP SIGNATURE-
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/dri-devel

Re: drm-next i915 regression? ( was: Re: PCI resources above 4GB)

[Steven Newbury]

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1

On 13/04/12 17:17, Yinghai Lu wrote:
 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 include
 
 for-pci-hostbridge-cleanup for-pci-busn-alloc 
 for-pci-root-bus-hotplug for-pci-for-each-res-addon at plus 7
 patches.
 
 maybe there is some problem with for-pci-for-each-res-addon.
 
 just rebase for-pci-res-alloc to for-pci-root-bus-hotplug. Please 
 check if the problem still there.
 
Still Oopses.  I'm going to try linus/master.  Perhaps it's a
filesystem corruption triggering it?  I do find it a little suspicious
that it occurs in btrfs:find_workspace though, code which deals with
memory allocations...
-BEGIN PGP SIGNATURE-
Version: GnuPG v2.0.19 (GNU/Linux)
Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/

iEYEARECAAYFAk+IZHsACgkQGcb56gMuC62WhQCgkVBccCKKLqjL1S7f+4wzXnT7
DbsAn2wQNiQLGo95Q3W9bWu6n5Q3xqr8
=Rtn+
-END PGP SIGNATURE-
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/dri-devel

Re: drm-next i915 regression? ( was: Re: PCI resources above 4GB)

[Steven Newbury]

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1

On 13/04/12 18:38, Steven Newbury wrote:
 On 13/04/12 17:17, Yinghai Lu wrote:
 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 include
 
 for-pci-hostbridge-cleanup for-pci-busn-alloc 
 for-pci-root-bus-hotplug for-pci-for-each-res-addon at plus 7 
 patches.
 
 maybe there is some problem with for-pci-for-each-res-addon.
 
 just rebase for-pci-res-alloc to for-pci-root-bus-hotplug. Please
  check if the problem still there.
 
 Still Oopses.  I'm going to try linus/master.  Perhaps it's a 
 filesystem corruption triggering it?  I do find it a little
 suspicious that it occurs in btrfs:find_workspace though, code
 which deals with memory allocations...
Damn. It still oopses with my linus tracking branch!  I'm going to
restore from backup and see if it still happens.
-BEGIN PGP SIGNATURE-
Version: GnuPG v2.0.19 (GNU/Linux)
Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/

iEYEARECAAYFAk+IbJ8ACgkQGcb56gMuC60bVQCfbIQEd+kpJBrXdeiz/sfJOCC2
f9oAnA4DYSOD1ApvbMl937dxG2i6SYDv
=uZ3A
-END PGP SIGNATURE-
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/dri-devel

Btrfs corruption Oops ( was: Re: PCI resources above 4GB)

[Steven Newbury]

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1

On 13/04/12 19:12, Steven Newbury wrote:
 On 13/04/12 18:38, Steven Newbury wrote:
 On 13/04/12 17:17, Yinghai Lu wrote:
 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 include
 
 for-pci-hostbridge-cleanup for-pci-busn-alloc 
 for-pci-root-bus-hotplug for-pci-for-each-res-addon at plus 7 
 patches.
 
 maybe there is some problem with for-pci-for-each-res-addon.
 
 just rebase for-pci-res-alloc to for-pci-root-bus-hotplug.
 Please check if the problem still there.
 
 Still Oopses.  I'm going to try linus/master.  Perhaps it's a 
 filesystem corruption triggering it?  I do find it a little 
 suspicious that it occurs in btrfs:find_workspace though, code 
 which deals with memory allocations...
 Damn. It still oopses with my linus tracking branch!  I'm going to 
 restore from backup and see if it still happens.
It was filesystem corruption.  Running rsync triggered it on a couple
of files.  Strangely btrfs scrub found no errors.  I'll forward the
oops to the btrfs list.
-BEGIN PGP SIGNATURE-
Version: GnuPG v2.0.19 (GNU/Linux)
Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/

iEYEARECAAYFAk+In/EACgkQGcb56gMuC60OdwCfTxJXzutYj6MGO7itU7ZSi5et
lvgAoKBfJk3Z3Kn4UJBq5Zlg2PvqM6Oi
=1Rqu
-END PGP SIGNATURE-
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/dri-devel

PCI resources above 4GB

[Steven Newbury]

On Thu, 12 Apr 2012, 17:07:33 BST, Yinghai Lu  wrote:

> 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 conflict is detected
> > and it's relallocated to 0x1200.
> > 
> > I've attempted to modify probe.c to disable 64-bit BARs not allocated
> > above 4G so they get reallocated above when possible later. ?It seemed
> > to work, but again broke GMA despite the BAR originally containing an
> > invalid address as mentioned above, it seems for some reason something
> > is different when the conflict is detected and rellocated, compared to
> > disabling it early then allocating a valid value..?
> > 
> > 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 find large aligned regions later on. ?I see code to
> > default to top-down allocation was reverted, I guess I'm going to have
> > to dig into the archive to find out why...
> 
> for hotplug case, You can work around like:
> after hotplug add,
> 1. use lspci and /proc/iomem to find out offending device and bridge.
> 2. use /sys/.../unbind etc to stop driver for those devices.
> 3. use setpci to clear related BAR
> 4. use /sys/devices/pci000/remove to remove those devices
> 5. echo 1 > /sys/bus/pci/rescan
> 
> then it should work...
> 
Good idea, I can easily hook that up into the dock event. Is it possible to 
disable the auto bus scan on hotplug, then trigger it manually as above? But it 
still leaves me needing to have at least the Intel GMA cleanly reallocated high 
from boot.

PCI resources above 4GB

[Steven Newbury]

On Thu, 12 Apr 2012, 12:22:34 BST, Steven Newbury  
wrote:
> I've attempted to modify probe.c to disable 64-bit BARs not allocated
> above 4G so they get reallocated above when possible later.?  It seemed
> to work, but again broke GMA despite the BAR originally containing an
> invalid address as mentioned above, it seems for some reason something
> is different when the conflict is detected and rellocated, compared to
> disabling it early then allocating a valid value..?
I understand now why it didn't work.  Memory decoding was enabled in the GMA 
device.  When it's detected as in conflict with system RAM it gets reallocated 
cleanly, but setting the BAR to 0 prevents that from happening.  Somehow I need 
to get the resources I want moved onto a realloc list, but I can't work out 
where or how...

PCI resources above 4GB

[Steven Newbury]

On Thu, 12 Apr 2012, 01:57:17 BST, Yinghai Lu  wrote:

> 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 a 64bit base register... ?I
> > noticed in my docked dmesg, "AGP aperture is 256M @ 0x2000", but
> > the PCI base: "12000-12fff : :00:02.0" so only 32bits have
> > been set in agpgart-intel. ?Explains why i915 wasn't initialised.
> 
> Attached patch should fix that high 32bit missing problem.

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 conflict is detected and it's 
relallocated to 0x1200.

I've attempted to modify probe.c to disable 64-bit BARs not allocated above 4G 
so they get reallocated above when possible later.  It seemed to work, but 
again broke GMA despite the BAR originally containing an invalid address as 
mentioned above, it seems for some reason something is different when the 
conflict is detected and rellocated, compared to disabling it early then 
allocating a valid value..?

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 find large aligned 
regions later on.  I see code to default to top-down allocation was reverted, I 
guess I'm going to have to dig into the archive to find out why...

Thanks for all your help so far, I've been learning a lot over the last few 
days.

PCI resources above 4GB

[Yinghai Lu]

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 conflict is detected and it's 
> relallocated to 0x1200.
>
> I've attempted to modify probe.c to disable 64-bit BARs not allocated above 
> 4G so they get reallocated above when possible later. ?It seemed to work, but 
> again broke GMA despite the BAR originally containing an invalid address as 
> mentioned above, it seems for some reason something is different when the 
> conflict is detected and rellocated, compared to disabling it early then 
> allocating a valid value..?
>
> 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 find large 
> aligned regions later on. ?I see code to default to top-down allocation was 
> reverted, I guess I'm going to have to dig into the archive to find out why...

for hotplug case, You can work around like:
after hotplug add,
1. use lspci and /proc/iomem to find out offending device and bridge.
2. use /sys/.../unbind etc to stop driver for those devices.
3. use setpci to clear related BAR
4. use /sys/devices/pci000/remove to remove those devices
5. echo 1 > /sys/bus/pci/rescan

then it should work...

Yinghai

Re: PCI resources above 4GB

[Steven Newbury]

On Thu, 12 Apr 2012, 01:57:17 BST, Yinghai Lu ying...@kernel.org wrote:

 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 agp_bridge has a 64bit base register...  I
  noticed in my docked dmesg, AGP aperture is 256M @ 0x2000, but
  the PCI base: 12000-12fff : :00:02.0 so only 32bits have
  been set in agpgart-intel.  Explains why i915 wasn't initialised.
 
 Attached patch should fix that high 32bit missing problem.

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 conflict is detected and it's 
relallocated to 0x1200.

I've attempted to modify probe.c to disable 64-bit BARs not allocated above 4G 
so they get reallocated above when possible later.  It seemed to work, but 
again broke GMA despite the BAR originally containing an invalid address as 
mentioned above, it seems for some reason something is different when the 
conflict is detected and rellocated, compared to disabling it early then 
allocating a valid value..?

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 find large aligned 
regions later on.  I see code to default to top-down allocation was reverted, I 
guess I'm going to have to dig into the archive to find out why...

Thanks for all your help so far, I've been learning a lot over the last few 
days.
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/dri-devel

Re: PCI resources above 4GB

[Yinghai Lu]

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 invalid.  This conflict is detected and it's 
 relallocated to 0x1200.

 I've attempted to modify probe.c to disable 64-bit BARs not allocated above 
 4G so they get reallocated above when possible later.  It seemed to work, but 
 again broke GMA despite the BAR originally containing an invalid address as 
 mentioned above, it seems for some reason something is different when the 
 conflict is detected and rellocated, compared to disabling it early then 
 allocating a valid value..?

 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 find large 
 aligned regions later on.  I see code to default to top-down allocation was 
 reverted, I guess I'm going to have to dig into the archive to find out why...

for hotplug case, You can work around like:
after hotplug add,
1. use lspci and /proc/iomem to find out offending device and bridge.
2. use /sys/.../unbind etc to stop driver for those devices.
3. use setpci to clear related BAR
4. use /sys/devices/pci000/remove to remove those devices
5. echo 1  /sys/bus/pci/rescan

then it should work...

Yinghai
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/dri-devel

Re: PCI resources above 4GB

[Steven Newbury]

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!
  
  In the working case, initially the BIOS has set GMA to within the low
  system DRAM 0xC000 obviously invalid.  This conflict is detected
  and it's relallocated to 0x1200.
  
  I've attempted to modify probe.c to disable 64-bit BARs not allocated
  above 4G so they get reallocated above when possible later.  It seemed
  to work, but again broke GMA despite the BAR originally containing an
  invalid address as mentioned above, it seems for some reason something
  is different when the conflict is detected and rellocated, compared to
  disabling it early then allocating a valid value..?
  
  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 find large aligned regions later on.  I see code to
  default to top-down allocation was reverted, I guess I'm going to have
  to dig into the archive to find out why...
 
 for hotplug case, You can work around like:
 after hotplug add,
 1. use lspci and /proc/iomem to find out offending device and bridge.
 2. use /sys/.../unbind etc to stop driver for those devices.
 3. use setpci to clear related BAR
 4. use /sys/devices/pci000/remove to remove those devices
 5. echo 1  /sys/bus/pci/rescan
 
 then it should work...
 
Good idea, I can easily hook that up into the dock event. Is it possible to 
disable the auto bus scan on hotplug, then trigger it manually as above? But it 
still leaves me needing to have at least the Intel GMA cleanly reallocated high 
from boot.
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/dri-devel

PCI resources above 4GB

[Yinghai Lu]

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 a 64bit base register... ?I
> noticed in my docked dmesg, "AGP aperture is 256M @ 0x2000", but
> the PCI base: "12000-12fff : :00:02.0" so only 32bits have
> been set in agpgart-intel. ?Explains why i915 wasn't initialised.

Attached patch should fix that high 32bit missing problem.

Yinghai
-- next part --
A non-text attachment was scrubbed...
Name: fix_i915_gma_bus_addr.patch
Type: application/octet-stream
Size: 1216 bytes
Desc: not available
URL: 

Re: PCI resources above 4GB

[Yinghai Lu]

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 agp_bridge has a 64bit base register...  I
 noticed in my docked dmesg, AGP aperture is 256M @ 0x2000, but
 the PCI base: 12000-12fff : :00:02.0 so only 32bits have
 been set in agpgart-intel.  Explains why i915 wasn't initialised.

Attached patch should fix that high 32bit missing problem.

Yinghai


fix_i915_gma_bus_addr.patch
Description: Binary data
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/dri-devel