[Intel-gfx] Bad flicker on skylake HQD due to code in the 4.7 merge window

[Steven Newbury]

On Fri, 2016-06-24 at 11:59 +0100, Chris Wilson wrote:
> On Thu, Jun 23, 2016 at 02:14:12PM +0100, Steven Newbury wrote:
> > On Thu, 2016-06-23 at 15:59 +0300, Jani Nikula wrote:
> > > On Thu, 23 Jun 2016, Steven Newbury 
> > > wrote:
> > > > I'm seeing this on my IvyBridge.  I'll try reverting the commit
> > > > here
> > > > too, to see if it's the same issue.
> > > 
> > > IvyBridge doesn't have low vswing for eDP. If reverting helps,
> > > it's a
> > > different failure mode.
> > > 
> > It must be something else then.  Actually, in my case linus/master
> > is
> > okay.  I saw the subject and though it must be the same issue.  I'm
> > seeing it with drm-intel nightly/next branches.  Shall I try to
> > bisect
> > it?  Symptoms are similar, although I would describe it more like
> > flashes of a different buffer across parts of the screen.
> 
> Try reverting ee042aa40b66d18d465206845b0752c6a617ba3f instead.
> -Chris
> 

Yes, thanks, that "fixed" it.  So atomic commits not working properly
on IVB?
-- next part --
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 181 bytes
Desc: This is a digitally signed message part
URL: 
<https://lists.freedesktop.org/archives/dri-devel/attachments/20160624/3537ed86/attachment.sig>

[Intel-gfx] Bad flicker on skylake HQD due to code in the 4.7 merge window

[Steven Newbury]

On Thu, 2016-06-23 at 15:59 +0300, Jani Nikula wrote:
> On Thu, 23 Jun 2016, Steven Newbury  wrote:
> > [ Unknown signature status ]
> > On Sun, 2016-06-19 at 14:53 -0700, James Bottomley wrote:
> > > On Fri, 2016-06-17 at 16:06 -0700, James Bottomley wrote:
> > > > On Fri, 2016-06-17 at 16:34 +0300, Jani Nikula wrote:
> > > > > On Fri, 17 Jun 2016, Daniel Vetter  wrote:
> > > > > > On Thu, Jun 16, 2016 at 03:42:12PM -0700, James Bottomley
> > > > > > wrote:
> > > > > > > On Thu, 2016-06-16 at 14:29 -0700, James Bottomley wrote:
> > > > > > > > On Thu, 2016-06-16 at 23:24 +0200, Daniel Vetter wrote:
> > > > > > > > > I guess we'll need the bisect on this one to make
> > > > > > > > > progress.
> > > > > > > > 
> > > > > > > > Sigh, I was afraid that might be the next step.
> > > > > > > 
> > > > > > > OK, I have a curious data point.  I assumed the problem
> > > > > > > would
> > > > > > > be
> > > > > > > somewhere in the drm update, so I started bisecting that
> > > > > > > at
> > > > > > > the
> > > > > > > top. 
> > > > > > >  However, the top most commit:
> > > > > > > 
> > > > > > > commit 1d6da87a3241deb13d073c4125d19ed0e5a0c62c
> > > > > > > Merge: 1f40c49 a39ed68
> > > > > > > Author: Linus Torvalds 
> > > > > > > Date:   Mon May 23 11:48:48 2016 -0700
> > > > > > > 
> > > > > > >     Merge branch 'drm-next' of
> > > > > > > git://people.freedesktop.org/~airlied/linux
> > > > > > > 
> > > > > > > Isn't actually bad.  There's no flicker here, so whatever
> > > > > > > caused
> > > > > > > the
> > > > > > > problem came from some update after this.
> > > > > > 
> > > > > > There was a fixes pull after this. Might be worth it to
> > > > > > restrict
> > > > > > to
> > > > > > just
> > > > > > the i915 changes, which are just
> > > > > > 5b4fd5bb1230cd037..157d2c7fad0863222
> > > > > > 
> > > > > > Looking at those nothing seems to stick out which might
> > > > > > explain
> > > > > > what's
> > > > > > happening for you.
> > > > 
> > > > OK, so just on the firmware, the system seems less flickery
> > > > with
> > > > the
> > > > new 1.4.3 UEFI, so I'm starting to think it is a Skylake
> > > > errata 
> > > > issue.  The flicker isn't gone for good, but seems to be
> > > > reboot 
> > > > dependent (it's there in some boots, but gone on a reboot).
> > > > 
> > > > > This should be easy enough to try before bisecting:
> > > > > http://patchwork.freedesktop.org/patch/msgid/1466162081-12042
> > > > > -1-g
> > > > > it
> > > > > -s
> > > > > end-email-mika.kahola at intel.com
> > > > 
> > > > Applying this didn't seem to make a difference: still there on
> > > > some 
> > > > and gone on other reboots.
> > > 
> > > OK, my candidate bad commit is this one:
> > > 
> > > commit a05628195a0d9f3173dd9aa76f482aef692e46ee
> > > Author: Ville Syrjälä 
> > > Date:   Mon Apr 11 10:23:51 2016 +0300
> > > 
> > >     drm/i915: Get panel_type from OpRegion panel details
> > > 
> > > After being more careful about waiting to identify flicker, this
> > > one
> > > seems to be the one the bisect finds.  I'm now running v4.7-rc3
> > > with
> > > this one reverted and am currently seeing no flicker
> > > problems.  It
> > > is,
> > > however, early days because the flicker can hide for long
> > > periods, so
> > > I
> > > 'll wait until Monday evening and a few reboots before declaring
> > > victory.
> > > 
> > >  
> > I'm seeing this on my IvyBridge.  I'll try reverting the commit
> > here
> > too, to see if it's the same issue.
> 
> IvyBridge doesn't have low vswing for eDP. If reverting helps, it's a
> different failure mode.
> 
It must be something else then.  Actually, in my case linus/master is
okay.  I saw the subject and though it must be the same issue.  I'm
seeing it with drm-intel nightly/next branches.  Shall I try to bisect
it?  Symptoms are similar, although I would describe it more like
flashes of a different buffer across parts of the screen.


-- next part --
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 181 bytes
Desc: This is a digitally signed message part
URL: 
<https://lists.freedesktop.org/archives/dri-devel/attachments/20160623/1f99b976/attachment.sig>

[Intel-gfx] Bad flicker on skylake HQD due to code in the 4.7 merge window

[Steven Newbury]

On Sun, 2016-06-19 at 14:53 -0700, James Bottomley wrote:
> On Fri, 2016-06-17 at 16:06 -0700, James Bottomley wrote:
> > On Fri, 2016-06-17 at 16:34 +0300, Jani Nikula wrote:
> > > On Fri, 17 Jun 2016, Daniel Vetter  wrote:
> > > > On Thu, Jun 16, 2016 at 03:42:12PM -0700, James Bottomley
> > > > wrote:
> > > > > On Thu, 2016-06-16 at 14:29 -0700, James Bottomley wrote:
> > > > > > On Thu, 2016-06-16 at 23:24 +0200, Daniel Vetter wrote:
> > > > > > > I guess we'll need the bisect on this one to make
> > > > > > > progress.
> > > > > > 
> > > > > > Sigh, I was afraid that might be the next step.
> > > > > 
> > > > > OK, I have a curious data point.  I assumed the problem would
> > > > > be
> > > > > somewhere in the drm update, so I started bisecting that at
> > > > > the
> > > > > top. 
> > > > >  However, the top most commit:
> > > > > 
> > > > > commit 1d6da87a3241deb13d073c4125d19ed0e5a0c62c
> > > > > Merge: 1f40c49 a39ed68
> > > > > Author: Linus Torvalds 
> > > > > Date:   Mon May 23 11:48:48 2016 -0700
> > > > > 
> > > > >     Merge branch 'drm-next' of
> > > > > git://people.freedesktop.org/~airlied/linux
> > > > > 
> > > > > Isn't actually bad.  There's no flicker here, so whatever
> > > > > caused
> > > > > the
> > > > > problem came from some update after this.
> > > > 
> > > > There was a fixes pull after this. Might be worth it to
> > > > restrict
> > > > to
> > > > just
> > > > the i915 changes, which are just
> > > > 5b4fd5bb1230cd037..157d2c7fad0863222
> > > > 
> > > > Looking at those nothing seems to stick out which might explain
> > > > what's
> > > > happening for you.
> > 
> > OK, so just on the firmware, the system seems less flickery with
> > the
> > new 1.4.3 UEFI, so I'm starting to think it is a Skylake errata 
> > issue.  The flicker isn't gone for good, but seems to be reboot 
> > dependent (it's there in some boots, but gone on a reboot).
> > 
> > > This should be easy enough to try before bisecting:
> > > http://patchwork.freedesktop.org/patch/msgid/1466162081-12042-1-g
> > > it
> > > -s
> > > end-email-mika.kahola at intel.com
> > 
> > Applying this didn't seem to make a difference: still there on
> > some 
> > and gone on other reboots.
> 
> OK, my candidate bad commit is this one:
> 
> commit a05628195a0d9f3173dd9aa76f482aef692e46ee
> Author: Ville Syrjälä 
> Date:   Mon Apr 11 10:23:51 2016 +0300
> 
>     drm/i915: Get panel_type from OpRegion panel details
> 
> After being more careful about waiting to identify flicker, this one
> seems to be the one the bisect finds.  I'm now running v4.7-rc3 with
> this one reverted and am currently seeing no flicker problems.  It
> is,
> however, early days because the flicker can hide for long periods, so
> I
> 'll wait until Monday evening and a few reboots before declaring
> victory.
> 
> 
I'm seeing this on my IvyBridge.  I'll try reverting the commit here
too, to see if it's the same issue.
-- next part --
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 181 bytes
Desc: This is a digitally signed message part
URL: 

drm_device from another device driver? (was: Re: block device backed by DRM buffer object)

[Steven Newbury]

On Wed, 2015-09-23 at 23:41 +0200, Lukas Wunner wrote:
> Hi,
> 
> On Wed, Sep 23, 2015 at 08:37:48PM +0000, Steven Newbury wrote:
> > I can't figure out how to get a pointer to the radeon_device struct
> > for a specific card, or the parent drm_device from an external
> > device
> > driver.
> 
> struct device -> struct drm_device: dev_get_drvdata()
> struct pci_dev -> struct drm_device: pci_get_drvdata()
> struct drm_device -> struct radeon_device: drm_device->dev_private
> 
Thanks, that's useful.

> 
> > I imagine I somehow need to take a reference to the drm class
> > kobject
> > for the card in question, and in so doing presumably I should then
> > be
> > able to discover the pointer to device.
> 
> It sounds like you want to discover the available radeon cards in the
> system? If so you could iterate over all pci devices and look for
> pci->vendor == PCI_VENDOR_ID_ATI || pci->vendor == PCI_VENDOR_ID_AMD,
> then get to the radeon_device as shown above.
> 
Yes, my plan was to eventually discover all the drm devices on the
system and make available a sysfs entry to allocate a volume from VRAM
for each capable card selecting an appropriate backend for driver.  I
was initially just going to implement it for radoen using a static
allocation from module params.

> However as Christian König pointed out, memory allocation is driver
> dependent. For an initial proof of concept it may be simplest to hack
> the radeon driver. Then you'll get an idea which parts are generic
> and
> which are driver specific and you can move the generic stuff to a
> central broker.
> 
Hacking the radeon driver was very much something I'd considered; I'd
only decided not to because I was thinking too far ahead really.  I
need to keep it simple, as you say, and only add complexity once I have
something working, and hopefully able to demonstrate its utility.

> Rather than discovering the VRAM it probably makes more sense to have
> drm devices register a set of callbacks with the central broker
> (e.g. return amount of currently free VRAM, allocate VRAM for use as
> block device, deallocate VRAM, read vector of blocks, write vector
> of blocks). The broker could then be controlled from user space via
> sysfs or ioctls or whatever.
For now I think I'll just take the approach bcache does with "thinly
provisioned volumes", and have an entry in the radeon sysfs:

/sys/class/drm/card0/device/vram_volume_create

which will attempt to allocate a given sized volume and register a
vrambd[0]. (or some better name?) Unregistering/deallocation can be
triggered from /sys/block/vramd[0]/vrambd/unregister
-- next part --
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 181 bytes
Desc: This is a digitally signed message part
URL: 
<http://lists.freedesktop.org/archives/dri-devel/attachments/20150923/7a6ab35d/attachment.sig>

drm_device from another device driver? (was: Re: block device backed by DRM buffer object)

[Steven Newbury]

I've been reading up on the device model and studying kernel sources for the 
last couple of days, but I can't figure out how to get a pointer to the 
radeon_device struct for a specific card, or the parent drm_device from an 
external device driver.

I imagine I somehow need to take a reference to the drm class kobject for the 
card in question, and in so doing presumably I should then be able to discover 
the pointer to device.

Can someone point me to an example or provide a snippet to demonstrate?

Alternatively, if I'm wandering down the wrong path, a sign to lead my way 
would be appreciated!

block device backed by DRM buffer object

[Steven Newbury]

On Mon, 2015-09-21 at 15:05 +0200, Christian König wrote:
> In general a rather interesting idea and actually shouldn't be to
> hard to implement.
> 
> The crux is that allocating memory is device driver dependent, so
> there isn't a general purpose API for doing so.
> 
> Additional to that the CPU invisible VRAM is only accessible by the
> GPU so you at least need to be able to submit DMA commands to copy
> the data back and forth.
> 
> For an experiment I suggest you do this with Radeon first and if that
> works generalize from there.
> 
Thanks for the feedback.  I've been studying the code, and it looks
like everything I need for Radeon is in radeon_test.c.  As a proof of
concept I'm going to initially hack it into an mtd device driver with
static allocation through module params.

This is pushing my knowledge quite a bit.  Just to make sure I'm on the
right track, this is what I'm attempting:

- Grab the pointer to class drm (how? I really need some help here)

- Walk the enumerated drm devices

- For the specified drm card if it's radeon:
  - use radeon_bo_create() to create a bo in RADEON_GEM_DOMAIN_VRAM of
specified size
  - create a bo in gtt for DMA to/from GPU memory

For reads/writes DMA from/to card VRAM bo and copy from/to gtt bo and
userspace


I guess it would be easier to do this as an add-on to the radeon drm
driver since it wouldn't require walking the drm devices to get the
radeon_device pointer but it makes more sense to me to just add a
reference count to the drm device as an external module.

> Regards,
> Christian.
> 
> On 21.09.2015 13:33, Steven Newbury wrote:
> > I have a mostly* headless server containing a Radeon discrete GPU.
> >  It
> > occured to me that having a GiB or two of high speed memory sitting
> > unused is pretty wasteful. Not an original thought; indeed there's
> > a
> > Gentoo wiki which describes how to map the memory as a mtd device:
> >  
> > http://www.gentoo-wiki.info/TIP_Use_memory_on_video_card_as_swap
> > 
> > There's also a driver (cudaram) written by Piotr Jaroszyński which
> > allocates memory through CUDA and maps it to a block device:
> > 
> > http://blog.piotrj.org/2011/03/cudaram-block-device-exposing-nvidia
> > .htm
> > l
> > 
> > The Gentoo method is extremely limited, and of course isn't exactly
> > safe, although using pci-stub would probably help.  There's no
> > arbitration between the DRM driver and the mtd phram driver.  Most
> > of
> > all, it can only expose the memory mapped into the PCI aperture,
> > likely
> > somewhat less than the full VMEM.
> > 
> > The second method obviously requires the proprietary NVidia driver
> > and
> > an NVidia gfx card, but it's good proof of concept at utilising a
> > driver managed buffer object as a block device.
> > 
> > I'm looking into creating a volatile block device driver which
> > allocates VMEM from DRM, what if any is the right API to use?  The
> > DRM
> > userspace API is well documented, but I'd like to make this a
> > kernel
> > module, so using a userspace API would seem inappropriate at best.
> >  Ideally I'd like to create something like the bcache
> > flash_vol_create
> > interface except expose a /sys/fs/drm-block/card0/vol_create (where
> > drm-block is a placeholder for the proposed driver name) for each
> > DRM
> > device in the system, and likewise persistence through udev.
> > 
> > So is there an API I can (mis-)use for this?  Any suggestions?
> > 
> > * There's a screen attached for maintainence, but it usually turned
> > off.
> > 
> > 
> > ___
> > dri-devel mailing list
> > dri-devel at lists.freedesktop.org
> > http://lists.freedesktop.org/mailman/listinfo/dri-devel
> ___
> dri-devel mailing list
> dri-devel at lists.freedesktop.org
> http://lists.freedesktop.org/mailman/listinfo/dri-devel
-- next part --
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 181 bytes
Desc: This is a digitally signed message part
URL: 
<http://lists.freedesktop.org/archives/dri-devel/attachments/20150922/7865cd62/attachment.sig>

block device backed by DRM buffer object

[Steven Newbury]

I have a mostly* headless server containing a Radeon discrete GPU.  It
occured to me that having a GiB or two of high speed memory sitting
unused is pretty wasteful. Not an original thought; indeed there's a
Gentoo wiki which describes how to map the memory as a mtd device:
 
http://www.gentoo-wiki.info/TIP_Use_memory_on_video_card_as_swap

There's also a driver (cudaram) written by Piotr Jaroszyński which
allocates memory through CUDA and maps it to a block device:

http://blog.piotrj.org/2011/03/cudaram-block-device-exposing-nvidia.htm
l

The Gentoo method is extremely limited, and of course isn't exactly
safe, although using pci-stub would probably help.  There's no
arbitration between the DRM driver and the mtd phram driver.  Most of
all, it can only expose the memory mapped into the PCI aperture, likely
somewhat less than the full VMEM.

The second method obviously requires the proprietary NVidia driver and
an NVidia gfx card, but it's good proof of concept at utilising a
driver managed buffer object as a block device.

I'm looking into creating a volatile block device driver which
allocates VMEM from DRM, what if any is the right API to use?  The DRM
userspace API is well documented, but I'd like to make this a kernel
module, so using a userspace API would seem inappropriate at best.
 Ideally I'd like to create something like the bcache flash_vol_create
interface except expose a /sys/fs/drm-block/card0/vol_create (where
drm-block is a placeholder for the proposed driver name) for each DRM
device in the system, and likewise persistence through udev.

So is there an API I can (mis-)use for this?  Any suggestions?

* There's a screen attached for maintainence, but it usually turned
off.
-- next part --
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 181 bytes
Desc: This is a digitally signed message part
URL: 

Wayland and GLES1 (Re: R200 DRM/KMS)

[Steven Newbury]

On Thu Jul 9 17:02:12 2015 GMT+0100, Steven Newbury wrote:
> On Thu Jul 9 16:04:35 2015 GMT+0100, Alex Deucher wrote:
> > On Thu, Jul 9, 2015 at 2:58 AM, Steven Newbury  
> > wrote:
> > >
> > >
> > > On Thu Jul 9 03:32:40 2015 GMT+0100, Michel Dänzer wrote:
> > >> On 09.07.2015 06:01, Steven Newbury wrote:
> > >> > On Wed, 2015-07-08 at 21:56 +0100, Steven Newbury wrote:
> > >> >> On Tue, 2015-07-07 at 09:18 +0300, Pekka Paalanen wrote:
> > >> >>> On Mon, 06 Jul 2015 22:50:30 +0100 Steven Newbury
> > >> >>>  wrote:
> > >> >>>
> > >> >>>> Would gles1 be sufficient to run a Wayland compositor, I'm
> > >> >>>> guessing probably not..?
> > >> >>>
> > >> >>> If you can find a Wayland compositor that is written to composite
> > >> >>>  with GLES1, that's all you need from the "Wayland side". (Yeah,
> > >> >>> this has nothing to do with Wayland per se.) Compositing in
> > >> >>> itself without any effects is very simple, as long as you get the
> > >> >>> textures up.
> > >> >>>
> > >> >>> Or, if you find a Wayland compositor written to use desktop
> > >> >>> OpenGL for compositing and does not use features your GL driver
> > >> >>> does not expose, that's good too.
> > >> >>>
> > >> >> Is desktop OpenGL accessible from "EGL_PLATFORM=drm"?
> > >> >>
> > >> > To answer my own question, it seems that is possible.  I wonder if
> > >> > it works with mutter/cogl???
> > >>
> > >> It does.
> > >>
> > >> However, your problem seems rather that gnome-shell/mutter doesn't
> > >> support R200 anymore.
> > > Yes, that's true. I wonder if I can revert the incompatible change or 
> > > better create a env variable to revert to the compatible behaviour or 
> > > something? I'll need to take a look...
> > 
> > I'm not sure how valid this is any more:
> > https://bugs.freedesktop.org/show_bug.cgi?id=51658
> > 
> > Basic issue is that r1xx/r2xx hw only has a limited number of render
> > buffer formats while they support a lot of texture formats.  Gnome
> > shell expects to be able to render to the same formats they can
> > texture from.
> > 
> It looks like a bit of a hack, it's a pity to lose valid texture formats, but 
> I've applied the patches from the bug after a little manual intervention. 
> It's building now, will take some time!  

Didn't work.  Still get the same error! :-(

On the other hand, I've got muffin to work compositor is actually okay, so 
thought I'd try cinnamon, but it's trying to use 1.5GB which isn't going to 
work! ;-)

Will probably revert to Xfce... 

-- 
Sent from my Jolla

Wayland and GLES1 (Re: R200 DRM/KMS)

[Steven Newbury]

On Thu Jul 9 17:02:12 2015 GMT+0100, Steven Newbury wrote:
> On Thu Jul 9 16:04:35 2015 GMT+0100, Alex Deucher wrote:
> > On Thu, Jul 9, 2015 at 2:58 AM, Steven Newbury  
> > wrote:
> > >
> > >
> > > On Thu Jul 9 03:32:40 2015 GMT+0100, Michel Dänzer wrote:
> > >> On 09.07.2015 06:01, Steven Newbury wrote:
> > >> > On Wed, 2015-07-08 at 21:56 +0100, Steven Newbury wrote:
> > >> >> On Tue, 2015-07-07 at 09:18 +0300, Pekka Paalanen wrote:
> > >> >>> On Mon, 06 Jul 2015 22:50:30 +0100 Steven Newbury
> > >> >>>  wrote:
> > >> >>>
> > >> >>>> Would gles1 be sufficient to run a Wayland compositor, I'm
> > >> >>>> guessing probably not..?
> > >> >>>
> > >> >>> If you can find a Wayland compositor that is written to composite
> > >> >>>  with GLES1, that's all you need from the "Wayland side". (Yeah,
> > >> >>> this has nothing to do with Wayland per se.) Compositing in
> > >> >>> itself without any effects is very simple, as long as you get the
> > >> >>> textures up.
> > >> >>>
> > >> >>> Or, if you find a Wayland compositor written to use desktop
> > >> >>> OpenGL for compositing and does not use features your GL driver
> > >> >>> does not expose, that's good too.
> > >> >>>
> > >> >> Is desktop OpenGL accessible from "EGL_PLATFORM=drm"?
> > >> >>
> > >> > To answer my own question, it seems that is possible.  I wonder if
> > >> > it works with mutter/cogl???
> > >>
> > >> It does.
> > >>
> > >> However, your problem seems rather that gnome-shell/mutter doesn't
> > >> support R200 anymore.
> > > Yes, that's true. I wonder if I can revert the incompatible change or 
> > > better create a env variable to revert to the compatible behaviour or 
> > > something? I'll need to take a look...
> > 
> > I'm not sure how valid this is any more:
> > https://bugs.freedesktop.org/show_bug.cgi?id=51658
> > 
> > Basic issue is that r1xx/r2xx hw only has a limited number of render
> > buffer formats while they support a lot of texture formats.  Gnome
> > shell expects to be able to render to the same formats they can
> > texture from.
> > 
> It looks like a bit of a hack, it's a pity to lose valid texture formats, but 
> I've applied the patches from the bug after a little manual intervention. 
> It's building now, will take some time!  

Didn't work.  Still get the same error! :-(

On the other hand, I've got muffin to work compositor is actually okay, so 
thought I'd try cinnamon, but it's trying to use 1.5GB which isn't going to 
work! ;-)

Will probably revert to Xfce... 

-- 
Sent from my Jolla

Wayland and GLES1 (Re: R200 DRM/KMS)

[Steven Newbury]

On Thu Jul 9 16:04:35 2015 GMT+0100, Alex Deucher wrote:
> On Thu, Jul 9, 2015 at 2:58 AM, Steven Newbury  
> wrote:
> >
> >
> > On Thu Jul 9 03:32:40 2015 GMT+0100, Michel Dänzer wrote:
> >> On 09.07.2015 06:01, Steven Newbury wrote:
> >> > On Wed, 2015-07-08 at 21:56 +0100, Steven Newbury wrote:
> >> >> On Tue, 2015-07-07 at 09:18 +0300, Pekka Paalanen wrote:
> >> >>> On Mon, 06 Jul 2015 22:50:30 +0100 Steven Newbury
> >> >>>  wrote:
> >> >>>
> >> >>>> Would gles1 be sufficient to run a Wayland compositor, I'm
> >> >>>> guessing probably not..?
> >> >>>
> >> >>> If you can find a Wayland compositor that is written to composite
> >> >>>  with GLES1, that's all you need from the "Wayland side". (Yeah,
> >> >>> this has nothing to do with Wayland per se.) Compositing in
> >> >>> itself without any effects is very simple, as long as you get the
> >> >>> textures up.
> >> >>>
> >> >>> Or, if you find a Wayland compositor written to use desktop
> >> >>> OpenGL for compositing and does not use features your GL driver
> >> >>> does not expose, that's good too.
> >> >>>
> >> >> Is desktop OpenGL accessible from "EGL_PLATFORM=drm"?
> >> >>
> >> > To answer my own question, it seems that is possible.  I wonder if
> >> > it works with mutter/cogl???
> >>
> >> It does.
> >>
> >> However, your problem seems rather that gnome-shell/mutter doesn't
> >> support R200 anymore.
> > Yes, that's true. I wonder if I can revert the incompatible change or 
> > better create a env variable to revert to the compatible behaviour or 
> > something? I'll need to take a look...
> 
> I'm not sure how valid this is any more:
> https://bugs.freedesktop.org/show_bug.cgi?id=51658
> 
> Basic issue is that r1xx/r2xx hw only has a limited number of render
> buffer formats while they support a lot of texture formats.  Gnome
> shell expects to be able to render to the same formats they can
> texture from.
> 
It looks like a bit of a hack, it's a pity to lose valid texture formats, but 
I've applied the patches from the bug after a little manual intervention. It's 
building now, will take some time!  
-- 
Sent from my Jolla

Wayland and GLES1 (Re: R200 DRM/KMS)

[Steven Newbury]

On Thu Jul 9 03:32:40 2015 GMT+0100, Michel Dänzer wrote:
> On 09.07.2015 06:01, Steven Newbury wrote:
> > On Wed, 2015-07-08 at 21:56 +0100, Steven Newbury wrote:
> >> On Tue, 2015-07-07 at 09:18 +0300, Pekka Paalanen wrote:
> >>> On Mon, 06 Jul 2015 22:50:30 +0100 Steven Newbury
> >>>  wrote:
> >>> 
> >>>> Would gles1 be sufficient to run a Wayland compositor, I'm 
> >>>> guessing probably not..?
> >>> 
> >>> If you can find a Wayland compositor that is written to composite
> >>>  with GLES1, that's all you need from the "Wayland side". (Yeah,
> >>> this has nothing to do with Wayland per se.) Compositing in
> >>> itself without any effects is very simple, as long as you get the
> >>> textures up.
> >>> 
> >>> Or, if you find a Wayland compositor written to use desktop
> >>> OpenGL for compositing and does not use features your GL driver
> >>> does not expose, that's good too.
> >>> 
> >> Is desktop OpenGL accessible from "EGL_PLATFORM=drm"?
> >> 
> > To answer my own question, it seems that is possible.  I wonder if
> > it works with mutter/cogl???
> 
> It does.
> 
> However, your problem seems rather that gnome-shell/mutter doesn't
> support R200 anymore.
Yes, that's true. I wonder if I can revert the incompatible change or better 
create a env variable to revert to the compatible behaviour or something? I'll 
need to take a look...

[I'm going to be posting a lot from my phone, my laptop power jack has just 
broken, again! :-( You'd think after 3.5 decades of making laptops we'd have 
come up with a better design!]
-- 
Sent from my Jolla

Wayland and GLES1 (Re: R200 DRM/KMS)

[Steven Newbury]

On Wed, 2015-07-08 at 21:56 +0100, Steven Newbury wrote:
> On Tue, 2015-07-07 at 09:18 +0300, Pekka Paalanen wrote:
> > On Mon, 06 Jul 2015 22:50:30 +0100
> > Steven Newbury  wrote:
> > 
> > > Would gles1 be sufficient to run a Wayland compositor, I'm
> > > guessing probably not..?
> > 
> > If you can find a Wayland compositor that is written to composite 
> > with
> > GLES1, that's all you need from the "Wayland side". (Yeah, this has
> > nothing to do with Wayland per se.) Compositing in itself without 
> > any
> > effects is very simple, as long as you get the textures up.
> > 
> > Or, if you find a Wayland compositor written to use desktop OpenGL 
> > for
> > compositing and does not use features your GL driver does not 
> > expose,
> > that's good too.
> > 
> Is desktop OpenGL accessible from "EGL_PLATFORM=drm"?
> 
To answer my own question, it seems that is possible.  I wonder if it
works with mutter/cogl???

> > Absolutely nothing about Wayland limits your choice of the GL 
> > flavour -
> > even more so as the compositor is not running *on* Wayland.
> > 
> > Also, the question of running GL apps on Wayland is a whole another
> > matter. There used to be a common misconception that Wayland had
> > something to do with only allowing GLES.
> > 
> > Finally, there is the option of software rendering for 
> > composition...
> > 
> Well, considering I was wondering about running Wayland on ancient
> hardware, perhaps software compositing wouldn't be ideal! ;-)
-- next part --
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 181 bytes
Desc: This is a digitally signed message part
URL: 
<http://lists.freedesktop.org/archives/dri-devel/attachments/20150708/0cc564ac/attachment.sig>

Wayland and GLES1 (Re: R200 DRM/KMS)

[Steven Newbury]

On Tue, 2015-07-07 at 09:18 +0300, Pekka Paalanen wrote:
> On Mon, 06 Jul 2015 22:50:30 +0100
> Steven Newbury  wrote:
> 
> > Would gles1 be sufficient to run a Wayland compositor, I'm
> > guessing probably not..?
> 
> If you can find a Wayland compositor that is written to composite 
> with
> GLES1, that's all you need from the "Wayland side". (Yeah, this has
> nothing to do with Wayland per se.) Compositing in itself without any
> effects is very simple, as long as you get the textures up.
> 
> Or, if you find a Wayland compositor written to use desktop OpenGL 
> for
> compositing and does not use features your GL driver does not expose,
> that's good too.
> 
Is desktop OpenGL accessible from "EGL_PLATFORM=drm"?

> Absolutely nothing about Wayland limits your choice of the GL 
> flavour -
> even more so as the compositor is not running *on* Wayland.
> 
> Also, the question of running GL apps on Wayland is a whole another
> matter. There used to be a common misconception that Wayland had
> something to do with only allowing GLES.
> 
> Finally, there is the option of software rendering for composition...
> 
Well, considering I was wondering about running Wayland on ancient
hardware, perhaps software compositing wouldn't be ideal! ;-)
-- next part --
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 181 bytes
Desc: This is a digitally signed message part
URL: 
<http://lists.freedesktop.org/archives/dri-devel/attachments/20150708/b74c681e/attachment.sig>

R200 DRM/KMS

[Steven Newbury]

On Wed, 2015-07-08 at 17:10 +0100, Emil Velikov wrote:
> On 8 July 2015 at 14:55, Alex Deucher  wrote:
> > On Wed, Jul 8, 2015 at 9:53 AM, Steven Newbury <
> > steve at snewbury.org.uk> wrote:
> > > 
> > > 
> > > On Wed Jul 8 14:20:28 2015 GMT+0100, Alex Deucher wrote:
> > > > On Wed, Jul 8, 2015 at 8:58 AM, Steven Newbury <
> > > > steve at snewbury.org.uk> wrote:
> > > > > 
> > > > > 
> > > > > On Tue Jul 7 15:12:28 2015 GMT+0100, Alex Deucher wrote:
> > > > > > On Tue, Jul 7, 2015 at 9:46 AM, Steven Newbury <
> > > > > > steve at snewbury.org.uk> wrote:
> > > > > > > 
> > > > > > > I've tried an xserver-1.16, and ddx, libdrm without LTO 
> > > > > > > and with
> > > > > > > gcc4.9.  Exactly the same thing.  I wondered whether the 
> > > > > > > unused i810
> > > > > > > could be interfering but triggering a device "remove" 
> > > > > > > before starting
> > > > > > > X made no difference.
> > > > > > > 
> > > > > > > I'm a bit of a loss.  I suppose I could try writing a 
> > > > > > > simple test for
> > > > > > > drmSetInterfaceVersion().  At least that should 
> > > > > > > determine whether the
> > > > > > > xserver/ddx is in the clear.
> > > > > > > 
> > > > > > > Any other ideas?
> > > > > > > 
> > > > > > 
> > > > > > Can you start a non-X runlevel and start X manually as 
> > > > > > root (assuming
> > > > > > you are using a login manager now)?
> > > > > > 
> > > > > My test program worked fine. I considerably improved it over 
> > > > > the version I posted. I'll send it to the list when I get 
> > > > > back.
> > > > > 
> > > > > I removed the drmSetInterfaceVersion() from radeon_kms.c and 
> > > > > it got much further.  Starting Xserver as root  apparently 
> > > > > started normally, according to the log, although  there was 
> > > > > a permission denied error on mode set during init. I don't 
> > > > > know whether it was related or not, but the display then 
> > > > > hung with a non-blinking cursor. Strange to get a permission 
> > > > > denied as root!
> > > > > 
> > > > > Starting GNOME via gdm gives a working slow X session but 
> > > > > for some reason only uses sw dri even though the Xorg log 
> > > > > shows r200 DRI2 as initialized. Perhaps it's a config error 
> > > > > somewhere.. ?
> > > > > 
> > > > > startx as a regular user just works!
> > > > > 
> > > > > But mutter doesn't, perhaps that's
> > > > > why a gnome session isn't working. It just gives the 
> > > > > following error:
> > > > > Cogl-ERROR **: Failed to create texture 2d due to 
> > > > > size/format constraints
> > > > > 
> > > > > Mutter is supposed to work on r200, right?
> > > > 
> > > > IIRC it tries to use a render buffer format that's not 
> > > > supported by the hw.
> > > Is there anything to be done about it? Have to use a different 
> > > wm/compositor?
> > > 
> > 
> > Another wm or compositor may help.
> > 
> > > Any idea why removing the call from radeon_kms.c worked?
> > 
> > No idea.
> > 
> From a quick look at the actual implementation drmSetInterfaceVersion
> is not something that we want/need to use with KMS drivers.
> 
> In general the original issue sound like the drm driver is not 
> (fully)
> loaded before the xserver/ddx kicks in. Additionally it may be a race
> condition if something else (plymouth) is using the device. In the
> latter case DRM_MASTER might still be held by $(other_app), thus
> attempting to either SetInterfaceVersion or do any modeset operation
> will fail.
> 
> 
Sitting on a KMS console, "systemctl start gdm", no plymouth
installed.  It's just during Xserver initialisation that
drmSetInterfaceVersion() fails.  AFAIK Xserver startup is entirely
single process, single thread.  I've written a little test utility
which works fine on the system in question.

Compile attached file with:
gcc -O2 -o test-drm test-drm.c $(pkg-config --cflags libdrm) $(pkg
-config --libs libdrm)


> Personally I would add a healthy amount of printk/printf though the
> kernel drm + radeon and the ddx.

I guess it doesn't really matter since patching out the code "fixes"
it...
-- next part --
A non-text attachment was scrubbed...
Name: test-drm.c
Type: text/x-csrc
Size: 1783 bytes
Desc: not available
URL: 
<http://lists.freedesktop.org/archives/dri-devel/attachments/20150708/f4f234fa/attachment-0001.c>
-- next part --
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 181 bytes
Desc: This is a digitally signed message part
URL: 
<http://lists.freedesktop.org/archives/dri-devel/attachments/20150708/f4f234fa/attachment-0001.sig>

R200 DRM/KMS

[Steven Newbury]

On Wed Jul 8 14:20:28 2015 GMT+0100, Alex Deucher wrote:
> On Wed, Jul 8, 2015 at 8:58 AM, Steven Newbury  
> wrote:
> >
> >
> > On Tue Jul 7 15:12:28 2015 GMT+0100, Alex Deucher wrote:
> >> On Tue, Jul 7, 2015 at 9:46 AM, Steven Newbury  
> >> wrote:
> >> >
> >> > I've tried an xserver-1.16, and ddx, libdrm without LTO and with
> >> > gcc4.9.  Exactly the same thing.  I wondered whether the unused i810
> >> > could be interfering but triggering a device "remove" before starting
> >> > X made no difference.
> >> >
> >> > I'm a bit of a loss.  I suppose I could try writing a simple test for
> >> > drmSetInterfaceVersion().  At least that should determine whether the
> >> > xserver/ddx is in the clear.
> >> >
> >> > Any other ideas?
> >> >
> >>
> >> Can you start a non-X runlevel and start X manually as root (assuming
> >> you are using a login manager now)?
> >>
> > My test program worked fine. I considerably improved it over the version I 
> > posted. I'll send it to the list when I get back.
> >
> > I removed the drmSetInterfaceVersion() from radeon_kms.c and it got much 
> > further.  Starting Xserver as root  apparently started normally, according 
> > to the log, although  there was a permission denied error on mode set 
> > during init. I don't know whether it was related or not, but the display 
> > then hung with a non-blinking cursor. Strange to get a permission denied as 
> > root!
> >
> > Starting GNOME via gdm gives a working slow X session but for some reason 
> > only uses sw dri even though the Xorg log shows r200 DRI2 as initialized. 
> > Perhaps it's a config error somewhere.. ?
> >
> > startx as a regular user just works!
> >
> > But mutter doesn't, perhaps that's
> > why a gnome session isn't working. It just gives the following error:
> > Cogl-ERROR **: Failed to create texture 2d due to size/format constraints
> >
> > Mutter is supposed to work on r200, right?
> 
> IIRC it tries to use a render buffer format that's not supported by the hw.
Is there anything to be done about it? Have to use a different wm/compositor? 

Any idea why removing the call from radeon_kms.c worked?

-- 
Sent from my Jolla

R200 DRM/KMS

[Steven Newbury]

On Tue Jul 7 15:12:28 2015 GMT+0100, Alex Deucher wrote:
> On Tue, Jul 7, 2015 at 9:46 AM, Steven Newbury  
> wrote:
> >
> > I've tried an xserver-1.16, and ddx, libdrm without LTO and with
> > gcc4.9.  Exactly the same thing.  I wondered whether the unused i810
> > could be interfering but triggering a device "remove" before starting
> > X made no difference.
> >
> > I'm a bit of a loss.  I suppose I could try writing a simple test for
> > drmSetInterfaceVersion().  At least that should determine whether the
> > xserver/ddx is in the clear.
> >
> > Any other ideas?
> >
> 
> Can you start a non-X runlevel and start X manually as root (assuming
> you are using a login manager now)?
> 
My test program worked fine. I considerably improved it over the version I 
posted. I'll send it to the list when I get back.

I removed the drmSetInterfaceVersion() from radeon_kms.c and it got much 
further.  Starting Xserver as root  apparently started normally, according to 
the log, although  there was a permission denied error on mode set during init. 
I don't know whether it was related or not, but the display then hung with a 
non-blinking cursor. Strange to get a permission denied as root!

Starting GNOME via gdm gives a working slow X session but for some reason only 
uses sw dri even though the Xorg log shows r200 DRI2 as initialized. Perhaps 
it's a config error somewhere.. ?

startx as a regular user just works! 

But mutter doesn't, perhaps that's 
why a gnome session isn't working. It just gives the following error:
Cogl-ERROR **: Failed to create texture 2d due to size/format constraints

Mutter is supposed to work on r200, right?


-- 
Sent from my Jolla

R200 DRM/KMS

[Steven Newbury]

On Tue, 2015-07-07 at 10:12 -0400, Alex Deucher wrote:
> On Tue, Jul 7, 2015 at 9:46 AM, Steven Newbury  > wrote:
> > 
> > I've tried an xserver-1.16, and ddx, libdrm without LTO and with
> > gcc4.9.  Exactly the same thing.  I wondered whether the unused 
> > i810
> > could be interfering but triggering a device "remove" before 
> > starting
> > X made no difference.
> > 
> > I'm a bit of a loss.  I suppose I could try writing a simple test 
> > for
> > drmSetInterfaceVersion().  At least that should determine whether 
> > the
> > xserver/ddx is in the clear.
> > 
> > Any other ideas?
> > 
> 
> Can you start a non-X runlevel and start X manually as root (assuming
> you are using a login manager now)?

I've written a simple test based on the code from radeon_kms.c

I just need to try it on the actual hw now... :-)
-- next part --
A non-text attachment was scrubbed...
Name: test-drm.c
Type: text/x-csrc
Size: 735 bytes
Desc: not available
URL: 
<http://lists.freedesktop.org/archives/dri-devel/attachments/20150707/648c0a9f/attachment.c>
-- next part --
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 181 bytes
Desc: This is a digitally signed message part
URL: 
<http://lists.freedesktop.org/archives/dri-devel/attachments/20150707/648c0a9f/attachment.sig>

R200 DRM/KMS

[Steven Newbury]

On Mon, 2015-07-06 at 23:26 +0200, Daniel Vetter wrote:
> On Mon, Jul 06, 2015 at 09:06:28PM +0100, Steven Newbury wrote:
> > On Mon, 2015-07-06 at 15:42 -0400, Alex Deucher wrote:
> > > On Mon, Jul 6, 2015 at 2:40 PM, Steven Newbury <
> > > steve at snewbury.org.uk
> > > > wrote:
> > > > On Mon, 2015-07-06 at 12:25 -0400, Alex Deucher wrote:
> > > > > On Mon, Jul 6, 2015 at 9:39 AM, Steven Newbury <
> > > > > steve at snewbury.org.uk
> > > > > > wrote:
> > > > > > Hi,
> > > > > > I've been trying to get DRM/KMS working with the current 
> > > > > > graphics
> > > > > > stack (xf86-video-ati 7.5, xserver-1.17) on a R200 series 
> > > > > > card.  I
> > > > > > assumed this should be working since KMS was implemented 
> > > > > > for 
> > > > > > it a
> > > > > > while back, and it has been working with xf86-video-ati
> > > > > > -6.x.
> > > > > > 
> > > > > > Unfortunately, it doesn't seem to work.
> > > > > > 
> > > > > > I've narrowed it down to drmSetInterfaceVersion() failing 
> > > > > > when
> > > > > > called
> > > > > > from the ATI driver (in radeon_kms.c).  This is a bit 
> > > > > > strange
> > > > > > since,
> > > > > > /sys/class/drm/version correctly reports 1.1.0 20060810. 
> > > > > >  Presuably
> > > > > > it's getting the correct fd for the DRM master otherwise 
> > > > > > it 
> > > > > > should
> > > > > > bail earlier?
> > > > > > 
> > > > > > 
> > > > > > Googling confirms others have had the same issue, and 
> > > > > > generally the
> > > > > > resolution has been to stick with the old driver.
> > > > > > 
> > > > > > Should this be working?  Is it known to be broken?
> > > > > 
> > > > > It should be working.  Make sure the kernel driver has kms 
> > > > > enabled,
> > > > > firmware available, and that the kernel driver is loaded 
> > > > > before
> > > > > starting X.  If the kernel driver is not loaded before X 
> > > > > starts 
> > > > > you
> > > > > can get a version mis-match error.
> > > > 
> > > > Yes, using Gentoos 4.1.1 kernel, driver is definitely loaded, 
> > > > with
> > > > modeset=1, which is working, all sysfs entries are there.  gdm 
> > > > manages
> > > > to fall back to starting up an X session without using DRM 
> > > > swrast
> > > > -only, not something you want to experience on such a weak CPU!
> > > > 
> > > 
> > > If the kernel driver loads properly and you get a kms console you
> > > should be good to go.
> > > 
> > > > Manually starting X fails with the "[drm] failed to set drm 
> > > > interface
> > > > version." error.
> > > > 
> > > 
> > > Maybe the ddx with that old system was build without KMS support?
> > Everything is freshly compiled.  The error itself is coming from
> > radeon_kms.c:651 in the ddx.
> 
> Do you have latest libdrm? We might have accidentally broken this 
> for very
> old versions of libdrm (although surprising this would compile with
> everything else).
> -Daniel
> > 
> > > 
> > > Alex
> > > 
> > > > It's a very old system, PCI-only(!) Coppermine-128, belonging 
> > > > to a
> > > > friend.  The system previously was (very slowly) running 
> > > > Ubuntu 10
> > > > LTS, I think.  It's not my machine so I'm not able to have 
> > > > continuous
> > > > access, but R200 DRM/KMS was working.  Apparently, Ubuntu no 
> > > > longer
> > > > support R200, so no further updates were possible.
> > > > 
> > > > My friend can't afford a new machine at the moment; and since 
> > > > I'm a
> > > > long time Gentoo dev I took it upon myself to build him a 
> > > > optimized
> > > > desktop with gcc-5, where possible LTO, -Os, -march=pentium3 
> > > > with 
> > > > the
> > > > system L1 and L2 cache size information.  It's quite possible 
> > &

R200 DRM/KMS

[Steven Newbury]

On Mon Jul 6 22:26:25 2015 GMT+0100, Daniel Vetter wrote:
> On Mon, Jul 06, 2015 at 09:06:28PM +0100, Steven Newbury wrote:
> > On Mon, 2015-07-06 at 15:42 -0400, Alex Deucher wrote:
> > > On Mon, Jul 6, 2015 at 2:40 PM, Steven Newbury  > > > wrote:
> > > > On Mon, 2015-07-06 at 12:25 -0400, Alex Deucher wrote:
> > > > > On Mon, Jul 6, 2015 at 9:39 AM, Steven Newbury <
> > > > > steve at snewbury.org.uk
> > > > > > wrote:
> > > > > > Hi,
> > > > > > I've been trying to get DRM/KMS working with the current 
> > > > > > graphics
> > > > > > stack (xf86-video-ati 7.5, xserver-1.17) on a R200 series 
> > > > > > card.  I
> > > > > > assumed this should be working since KMS was implemented for 
> > > > > > it a
> > > > > > while back, and it has been working with xf86-video-ati-6.x.
> > > > > > 
> > > > > > Unfortunately, it doesn't seem to work.
> > > > > > 
> > > > > > I've narrowed it down to drmSetInterfaceVersion() failing when
> > > > > > called
> > > > > > from the ATI driver (in radeon_kms.c).  This is a bit strange
> > > > > > since,
> > > > > > /sys/class/drm/version correctly reports 1.1.0 20060810. 
> > > > > >  Presuably
> > > > > > it's getting the correct fd for the DRM master otherwise it 
> > > > > > should
> > > > > > bail earlier?
> > > > > > 
> > > > > > 
> > > > > > Googling confirms others have had the same issue, and 
> > > > > > generally the
> > > > > > resolution has been to stick with the old driver.
> > > > > > 
> > > > > > Should this be working?  Is it known to be broken?
> > > > > 
> > > > > It should be working.  Make sure the kernel driver has kms 
> > > > > enabled,
> > > > > firmware available, and that the kernel driver is loaded before
> > > > > starting X.  If the kernel driver is not loaded before X starts 
> > > > > you
> > > > > can get a version mis-match error.
> > > > 
> > > > Yes, using Gentoos 4.1.1 kernel, driver is definitely loaded, with
> > > > modeset=1, which is working, all sysfs entries are there.  gdm 
> > > > manages
> > > > to fall back to starting up an X session without using DRM swrast
> > > > -only, not something you want to experience on such a weak CPU!
> > > > 
> > > 
> > > If the kernel driver loads properly and you get a kms console you
> > > should be good to go.
> > > 
> > > > Manually starting X fails with the "[drm] failed to set drm 
> > > > interface
> > > > version." error.
> > > > 
> > > 
> > > Maybe the ddx with that old system was build without KMS support?
> > Everything is freshly compiled.  The error itself is coming from
> > radeon_kms.c:651 in the ddx.
> 
> Do you have latest libdrm? We might have accidentally broken this for very
> old versions of libdrm (although surprising this would compile with
> everything else).
> -Daniel
> > 
> > > 
> > > Alex
> > > 
> > > > It's a very old system, PCI-only(!) Coppermine-128, belonging to a
> > > > friend.  The system previously was (very slowly) running Ubuntu 10
> > > > LTS, I think.  It's not my machine so I'm not able to have 
> > > > continuous
> > > > access, but R200 DRM/KMS was working.  Apparently, Ubuntu no longer
> > > > support R200, so no further updates were possible.
> > > > 
> > > > My friend can't afford a new machine at the moment; and since I'm a
> > > > long time Gentoo dev I took it upon myself to build him a optimized
> > > > desktop with gcc-5, where possible LTO, -Os, -march=pentium3 with 
> > > > the
> > > > system L1 and L2 cache size information.  It's quite possible some
> > > > part of the gfx stack is miscompiled, I tested it pretty throughly
> > > > under qemu (with qxl) before deployment, but that of course didn't
> > > > exercise the R200 driver.  FWIW, other than the failing DRI,
> > > > performance is surprisingly OK, not super fast obviously, but a 
> > > > *lot*
> > > > better than under Ubuntu! (start-up time is alot quicker, by an 
> > > > order
> > > > of magnitude!)
> > > > 
> > > > I'm attempting to downgrade the xserver and drivers (on the live
> > > > system) to see if that works, you can imagine that takes a little
> > > > while on a Coppermine-128!  I'll find out tomorrow.  Otherwise, I
> > > > guess I'm recompiling the stack with gcc-4.9 and no-LTO...
> 
> 
> 
> > ___
> > dri-devel mailing list
> > dri-devel at lists.freedesktop.org
> > http://lists.freedesktop.org/mailman/listinfo/dri-devel
> 
> 
> -- 
> Daniel Vetter
> Software Engineer, Intel Corporation
> http://blog.ffwll.ch
>

-- 
Sent from my Jolla

R200 DRM/KMS

[Steven Newbury]

On Mon, 2015-07-06 at 23:26 +0200, Daniel Vetter wrote:
> On Mon, Jul 06, 2015 at 09:06:28PM +0100, Steven Newbury wrote:
> > On Mon, 2015-07-06 at 15:42 -0400, Alex Deucher wrote:
> > > On Mon, Jul 6, 2015 at 2:40 PM, Steven Newbury <
> > > steve at snewbury.org.uk
> > > > wrote:
> > > > On Mon, 2015-07-06 at 12:25 -0400, Alex Deucher wrote:
> > > > > On Mon, Jul 6, 2015 at 9:39 AM, Steven Newbury <
> > > > > steve at snewbury.org.uk
> > > > > > wrote:
> > > > > > Hi,
> > > > > > I've been trying to get DRM/KMS working with the current 
> > > > > > graphics
> > > > > > stack (xf86-video-ati 7.5, xserver-1.17) on a R200 series 
> > > > > > card.  I
> > > > > > assumed this should be working since KMS was implemented 
> > > > > > for 
> > > > > > it a
> > > > > > while back, and it has been working with xf86-video-ati
> > > > > > -6.x.
> > > > > > 
> > > > > > Unfortunately, it doesn't seem to work.
> > > > > > 
> > > > > > I've narrowed it down to drmSetInterfaceVersion() failing 
> > > > > > when
> > > > > > called
> > > > > > from the ATI driver (in radeon_kms.c).  This is a bit 
> > > > > > strange
> > > > > > since,
> > > > > > /sys/class/drm/version correctly reports 1.1.0 20060810. 
> > > > > >  Presuably
> > > > > > it's getting the correct fd for the DRM master otherwise 
> > > > > > it 
> > > > > > should
> > > > > > bail earlier?
> > > > > > 
> > > > > > 
> > > > > > Googling confirms others have had the same issue, and 
> > > > > > generally the
> > > > > > resolution has been to stick with the old driver.
> > > > > > 
> > > > > > Should this be working?  Is it known to be broken?
> > > > > 
> > > > > It should be working.  Make sure the kernel driver has kms 
> > > > > enabled,
> > > > > firmware available, and that the kernel driver is loaded 
> > > > > before
> > > > > starting X.  If the kernel driver is not loaded before X 
> > > > > starts 
> > > > > you
> > > > > can get a version mis-match error.
> > > > 
> > > > Yes, using Gentoos 4.1.1 kernel, driver is definitely loaded, 
> > > > with
> > > > modeset=1, which is working, all sysfs entries are there.  gdm 
> > > > manages
> > > > to fall back to starting up an X session without using DRM 
> > > > swrast
> > > > -only, not something you want to experience on such a weak CPU!
> > > > 
> > > 
> > > If the kernel driver loads properly and you get a kms console you
> > > should be good to go.
> > > 
> > > > Manually starting X fails with the "[drm] failed to set drm 
> > > > interface
> > > > version." error.
> > > > 
> > > 
> > > Maybe the ddx with that old system was build without KMS support?
> > Everything is freshly compiled.  The error itself is coming from
> > radeon_kms.c:651 in the ddx.
> 
> Do you have latest libdrm? We might have accidentally broken this 
> for very
> old versions of libdrm (although surprising this would compile with
> everything else).
> -Daniel

It's the latest in portage:


x11-libs/libdrm-2.4.62::gentoo  USE="libkms -static-libs 
-valgrind"VIDEO_CARDS="radeon (-exynos) (-freedreno) -intel -nouveau (-omap) 
(-tegra) -vmware"

I'll know tomorrow whether downgrading works, if not, I'm suspecting it's a 
compiler bug.  I have wondered though how much testing R200 could be getting 
with the latest stack.


If it is a mis-compile, I guess it must be either in libdrm or the ddx
- hopefully, at least that shouldn't mean too much compiling!

Slightly off topic, I'm curious whether R200 could be used with
Wayland.  How difficult/possible would it be to get R200 working with
gles1? Obviously, gles2 would be a non-starter given it's OpenGL1.3
hardware.  Would gles1 be sufficient to run a Wayland compositor, I'm
guessing probably not..?
-- next part --
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 181 bytes
Desc: This is a digitally signed message part
URL: 
<http://lists.freedesktop.org/archives/dri-devel/attachments/20150706/06a7112f/attachment.sig>

R200 DRM/KMS

[Steven Newbury]

On Mon, 2015-07-06 at 15:42 -0400, Alex Deucher wrote:
> On Mon, Jul 6, 2015 at 2:40 PM, Steven Newbury  > wrote:
> > On Mon, 2015-07-06 at 12:25 -0400, Alex Deucher wrote:
> > > On Mon, Jul 6, 2015 at 9:39 AM, Steven Newbury <
> > > steve at snewbury.org.uk
> > > > wrote:
> > > > Hi,
> > > > I've been trying to get DRM/KMS working with the current 
> > > > graphics
> > > > stack (xf86-video-ati 7.5, xserver-1.17) on a R200 series 
> > > > card.  I
> > > > assumed this should be working since KMS was implemented for 
> > > > it a
> > > > while back, and it has been working with xf86-video-ati-6.x.
> > > > 
> > > > Unfortunately, it doesn't seem to work.
> > > > 
> > > > I've narrowed it down to drmSetInterfaceVersion() failing when
> > > > called
> > > > from the ATI driver (in radeon_kms.c).  This is a bit strange
> > > > since,
> > > > /sys/class/drm/version correctly reports 1.1.0 20060810. 
> > > >  Presuably
> > > > it's getting the correct fd for the DRM master otherwise it 
> > > > should
> > > > bail earlier?
> > > > 
> > > > 
> > > > Googling confirms others have had the same issue, and 
> > > > generally the
> > > > resolution has been to stick with the old driver.
> > > > 
> > > > Should this be working?  Is it known to be broken?
> > > 
> > > It should be working.  Make sure the kernel driver has kms 
> > > enabled,
> > > firmware available, and that the kernel driver is loaded before
> > > starting X.  If the kernel driver is not loaded before X starts 
> > > you
> > > can get a version mis-match error.
> > 
> > Yes, using Gentoos 4.1.1 kernel, driver is definitely loaded, with
> > modeset=1, which is working, all sysfs entries are there.  gdm 
> > manages
> > to fall back to starting up an X session without using DRM swrast
> > -only, not something you want to experience on such a weak CPU!
> > 
> 
> If the kernel driver loads properly and you get a kms console you
> should be good to go.
> 
> > Manually starting X fails with the "[drm] failed to set drm 
> > interface
> > version." error.
> > 
> 
> Maybe the ddx with that old system was build without KMS support?
Everything is freshly compiled.  The error itself is coming from
radeon_kms.c:651 in the ddx.

> 
> Alex
> 
> > It's a very old system, PCI-only(!) Coppermine-128, belonging to a
> > friend.  The system previously was (very slowly) running Ubuntu 10
> > LTS, I think.  It's not my machine so I'm not able to have 
> > continuous
> > access, but R200 DRM/KMS was working.  Apparently, Ubuntu no longer
> > support R200, so no further updates were possible.
> > 
> > My friend can't afford a new machine at the moment; and since I'm a
> > long time Gentoo dev I took it upon myself to build him a optimized
> > desktop with gcc-5, where possible LTO, -Os, -march=pentium3 with 
> > the
> > system L1 and L2 cache size information.  It's quite possible some
> > part of the gfx stack is miscompiled, I tested it pretty throughly
> > under qemu (with qxl) before deployment, but that of course didn't
> > exercise the R200 driver.  FWIW, other than the failing DRI,
> > performance is surprisingly OK, not super fast obviously, but a 
> > *lot*
> > better than under Ubuntu! (start-up time is alot quicker, by an 
> > order
> > of magnitude!)
> > 
> > I'm attempting to downgrade the xserver and drivers (on the live
> > system) to see if that works, you can imagine that takes a little
> > while on a Coppermine-128!  I'll find out tomorrow.  Otherwise, I
> > guess I'm recompiling the stack with gcc-4.9 and no-LTO...
-- next part --
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 181 bytes
Desc: This is a digitally signed message part
URL: 
<http://lists.freedesktop.org/archives/dri-devel/attachments/20150706/4a535280/attachment.sig>

R200 DRM/KMS

[Steven Newbury]

On Mon, 2015-07-06 at 12:25 -0400, Alex Deucher wrote:
> On Mon, Jul 6, 2015 at 9:39 AM, Steven Newbury  > wrote:
> > Hi,
> > I've been trying to get DRM/KMS working with the current graphics
> > stack (xf86-video-ati 7.5, xserver-1.17) on a R200 series card.  I
> > assumed this should be working since KMS was implemented for it a
> > while back, and it has been working with xf86-video-ati-6.x.
> > 
> > Unfortunately, it doesn't seem to work.
> > 
> > I've narrowed it down to drmSetInterfaceVersion() failing when 
> > called
> > from the ATI driver (in radeon_kms.c).  This is a bit strange 
> > since,
> > /sys/class/drm/version correctly reports 1.1.0 20060810.  Presuably
> > it's getting the correct fd for the DRM master otherwise it should
> > bail earlier?
> > 
> > 
> > Googling confirms others have had the same issue, and generally the
> > resolution has been to stick with the old driver.
> > 
> > Should this be working?  Is it known to be broken?
> 
> It should be working.  Make sure the kernel driver has kms enabled,
> firmware available, and that the kernel driver is loaded before
> starting X.  If the kernel driver is not loaded before X starts you
> can get a version mis-match error.

Yes, using Gentoos 4.1.1 kernel, driver is definitely loaded, with
modeset=1, which is working, all sysfs entries are there.  gdm manages
to fall back to starting up an X session without using DRM swrast
-only, not something you want to experience on such a weak CPU!

Manually starting X fails with the "[drm] failed to set drm interface
version." error.

It's a very old system, PCI-only(!) Coppermine-128, belonging to a
friend.  The system previously was (very slowly) running Ubuntu 10
LTS, I think.  It's not my machine so I'm not able to have continuous
access, but R200 DRM/KMS was working.  Apparently, Ubuntu no longer
support R200, so no further updates were possible. 

My friend can't afford a new machine at the moment; and since I'm a
long time Gentoo dev I took it upon myself to build him a optimized
desktop with gcc-5, where possible LTO, -Os, -march=pentium3 with the
system L1 and L2 cache size information.  It's quite possible some
part of the gfx stack is miscompiled, I tested it pretty throughly
under qemu (with qxl) before deployment, but that of course didn't
exercise the R200 driver.  FWIW, other than the failing DRI,
performance is surprisingly OK, not super fast obviously, but a *lot*
better than under Ubuntu! (start-up time is alot quicker, by an order
of magnitude!)

I'm attempting to downgrade the xserver and drivers (on the live
system) to see if that works, you can imagine that takes a little
while on a Coppermine-128!  I'll find out tomorrow.  Otherwise, I
guess I'm recompiling the stack with gcc-4.9 and no-LTO...
-- next part --
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 181 bytes
Desc: This is a digitally signed message part
URL: 
<http://lists.freedesktop.org/archives/dri-devel/attachments/20150706/cfb0bc02/attachment-0001.sig>

R200 DRM/KMS

[Steven Newbury]

Hi,
I've been trying to get DRM/KMS working with the current graphics
stack (xf86-video-ati 7.5, xserver-1.17) on a R200 series card.  I
assumed this should be working since KMS was implemented for it a
while back, and it has been working with xf86-video-ati-6.x.

Unfortunately, it doesn't seem to work.

I've narrowed it down to drmSetInterfaceVersion() failing when called
from the ATI driver (in radeon_kms.c).  This is a bit strange since,
/sys/class/drm/version correctly reports 1.1.0 20060810.  Presuably
it's getting the correct fd for the DRM master otherwise it should
bail earlier?


Googling confirms others have had the same issue, and generally the
resolution has been to stick with the old driver.

Should this be working?  Is it known to be broken?
-- next part --
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 181 bytes
Desc: This is a digitally signed message part
URL: 

[PATCH v9 1/3] drm: rockchip: Add basic drm driver

[Steven Newbury]

On Wed, 2014-10-08 at 09:17 +0800, Mark yao wrote:
> Hi Steven
>  I'm glad to see you to discuss about rk29xx.
> 
> On 2014?10?08? 06:26, Steven Newbury wrote:
> > I've just been discussing how this relates to rk29xx on #etnaviv.  
> > I
> > looked through the patch and it's good to see it's not limited to
> > supporting Mali GPUs.  I see no reason this wouldn't be compatible
> > with etna_viv for rk29xx (or future Rockchip designs with 
> > alternative
> > GPUs) as long as the rest of the infrastructure to support rk29 is 
> > in
> > place iommu (ARM SMMU?) driver, for example.
> Now the drm driver only test on rk3288, and future when we add
> compatible for rk29xx, we
> would consider to add a non-iommu path for it.
That's great! I'm working on trying to update the rk29 driver support. 
 Getting it supported where possible with the new drivers would make 
it much easier, hopefully such that simply creating a new dts file 
would produce a working kernel for any useful hardware out there.

> > IMHO it's vital to keep a logical separation between the video 
> > display
> > hardware and the graphics processor on SoCs.
> Sure, the graphics processor maybe change in different solutions,
> logical separation is that we
> try to keep.
-- next part --
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 181 bytes
Desc: This is a digitally signed message part
URL: 
<http://lists.freedesktop.org/archives/dri-devel/attachments/20141008/1304570f/attachment.sig>

[PATCH v9 1/3] drm: rockchip: Add basic drm driver

[Steven Newbury]

I've just been discussing how this relates to rk29xx on #etnaviv.  I 
looked through the patch and it's good to see it's not limited to 
supporting Mali GPUs.  I see no reason this wouldn't be compatible 
with etna_viv for rk29xx (or future Rockchip designs with alternative 
GPUs) as long as the rest of the infrastructure to support rk29 is in 
place iommu (ARM SMMU?) driver, for example.

IMHO it's vital to keep a logical separation between the video display 
hardware and the graphics processor on SoCs.

-- next part --
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 181 bytes
Desc: This is a digitally signed message part
URL: 

VDPAU tries to open wrong DRM device

[Steven Newbury]

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1

I have two DRM devices, i965 onboard, and a Radeon in a docking station.

Both devices are enabled in my Xorg server layout Screen0 is the i965,
and Screen1, the Radeon.

When I run vdpauinfo or try using mplayer -vo vdpau on the Radeon, I
get the error:

do_winsys_init: DRM version is 1.6.0 but this driver is only
compatible with 2.3.x (kernel 2.6.34) or later.

This is the version of the intel DRM driver!

The i965 obviously doesn't do VDPAU, since it's a "classic" driver,
it's DRI card0.  DRI card1, the radeon, seems to be properly
configured.  DRI works fine.

I would open a bug, but I'm not sure *where* the problem is...
-BEGIN PGP SIGNATURE-
Version: GnuPG v2.0.19 (GNU/Linux)
Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/

iEYEARECAAYFAk/IlKkACgkQGcb56gMuC62jPACgkQE0G037ZVB3Da46QkA7Ytv+
1voAni7GbMTkcdhutMAnXoI/bapxtvha
=mmHS
-END PGP SIGNATURE-

VDPAU tries to open wrong DRM device

[Steven Newbury]

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1

I have two DRM devices, i965 onboard, and a Radeon in a docking station.

Both devices are enabled in my Xorg server layout Screen0 is the i965,
and Screen1, the Radeon.

When I run vdpauinfo or try using mplayer -vo vdpau on the Radeon, I
get the error:

do_winsys_init: DRM version is 1.6.0 but this driver is only
compatible with 2.3.x (kernel 2.6.34) or later.

This is the version of the intel DRM driver!

The i965 obviously doesn't do VDPAU, since it's a classic driver,
it's DRI card0.  DRI card1, the radeon, seems to be properly
configured.  DRI works fine.

I would open a bug, but I'm not sure *where* the problem is...
-BEGIN PGP SIGNATURE-
Version: GnuPG v2.0.19 (GNU/Linux)
Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/

iEYEARECAAYFAk/IlKkACgkQGcb56gMuC62jPACgkQE0G037ZVB3Da46QkA7Ytv+
1voAni7GbMTkcdhutMAnXoI/bapxtvha
=mmHS
-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 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

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

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

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

[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

[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

[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

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 _DC

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: 
<http://lists.freedesktop.org/archives/dri-devel/attachments/20120414/a9f9efa9/attachment.bin>

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: 
<http://lists.freedesktop.org/archives/dri-devel/attachments/20120414/dfc8bd62/attachment.bin>

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: 
<http://lists.freedesktop.org/archives/dri-devel/attachments/20120414/f8d1b6b7/attachment-0001.bin>

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)
+	res

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

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:ff

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: 
<http://lists.freedesktop.org/archives/dri-devel/attachments/20120413/312977dd/attachment.ksh>
-- next part --
An embedded and charset-unspecified text was scrubbed...
Name: iomem.test
URL: 
<http://lists.freedesktop.org/archives/dri-devel/attachments/20120413/312977dd/attachment.asc>

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.

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

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.

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

[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

[Intel-gfx] [PATCH] drm, drm/i915/lvds: Honour video= parameter to override LVDS fixed mode

[Steven Newbury]

> > > > > > On Tue, Mar 29, 2011 at 5:49 PM, Dave Airlie
> > > > > >  wrote:
> > > > > > > can you guys ask someone internally about it also, there is a
> > > > > > > driver somewhere in Google also for driving the LVDS->HDMI
> > > > > > > adapter but I'm not sure what i2c bus its hanging off.
> > > > > > > 
> > > > > > > Dave.
> > > > > > 
> > > > > > 
> > > > > > http://git.chromium.org/gitweb/?p=chrontel.git;a=tree
> > > > > > 
> > > > > > may or may not be the thing.
> > > > > > 
> > > > > > Dave.
> > > > > I'll see if it works...
> > > > Is there a public clone URI for that repo? I dont want to have to
> > > > download the full ChromiumOS...
> > > Okay, I guessed it right: http://git.chromium.org/git/chrontel.git
> > Simply running the resulting executables didn't work, it fails to
> > detect the chip, the code also references accesses through GPIO and
> > seems it wants an nm10_gpio driver which isn't in my kernel tree. My
> > board is an NM10 chipset system, as is the target "Cr48 Chrome
> > Notebook" so it could well be the same hardware.
> 
> I cherry-picked the nm10_gpio driver from the ChromeOS kernel, but while
> it worked fine the chrontel driver still couldn't detect the chip:
> 
> XAUTHORITY=//home/mythtv/.Xauthority ./ch7036_monitor -v -p? ? ? ?  
> ./ch7036_monitor: starts
> Found device ID 0xff
> ./ch7036_monitor: Fatal: Device ID 0xff not the expected 0x56
> 
> So either it isn't a ch7036 or I'm still not doing everything necessary
> to expose it.
> 

Absolutely no help from Zotac :-

Unfortunately we only provide support for Windows XP, Vista, and 7 operating 
systems.

I can suggest searching through different forums on the web for any support 
regarding you situation

We apologize for the inconvenience

Please let us know if you have any other questions

...

You wouldn't think it too much to ask for a hardware company to support it's 
hardware and leave Windows support to Microsoft. :-(

Re: [Intel-gfx] [PATCH] drm, drm/i915/lvds: Honour video= parameter to override LVDS fixed mode

[Steven Newbury]

  On Tue, Mar 29, 2011 at 5:49 PM, Dave Airlie
  airl...@gmail.com wrote:
   can you guys ask someone internally about it also, there is a
   driver somewhere in Google also for driving the LVDS-HDMI
   adapter but I'm not sure what i2c bus its hanging off.
   
   Dave.
  
  
  http://git.chromium.org/gitweb/?p=chrontel.git;a=tree
  
  may or may not be the thing.
  
  Dave.
 I'll see if it works...
Is there a public clone URI for that repo? I dont want to have to
download the full ChromiumOS...
   Okay, I guessed it right: http://git.chromium.org/git/chrontel.git
  Simply running the resulting executables didn't work, it fails to
  detect the chip, the code also references accesses through GPIO and
  seems it wants an nm10_gpio driver which isn't in my kernel tree. My
  board is an NM10 chipset system, as is the target Cr48 Chrome
  Notebook so it could well be the same hardware.
 
 I cherry-picked the nm10_gpio driver from the ChromeOS kernel, but while
 it worked fine the chrontel driver still couldn't detect the chip:
 
 XAUTHORITY=//home/mythtv/.Xauthority ./ch7036_monitor -v -p         
 ./ch7036_monitor: starts
 Found device ID 0xff
 ./ch7036_monitor: Fatal: Device ID 0xff not the expected 0x56
 
 So either it isn't a ch7036 or I'm still not doing everything necessary
 to expose it.
 

Absolutely no help from Zotac :-

Unfortunately we only provide support for Windows XP, Vista, and 7 operating 
systems.

I can suggest searching through different forums on the web for any support 
regarding you situation

We apologize for the inconvenience

Please let us know if you have any other questions

...

You wouldn't think it too much to ask for a hardware company to support it's 
hardware and leave Windows support to Microsoft. :-(

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

[Intel-gfx] [PATCH] drm, drm/i915/lvds: Honour video= parameter to override LVDS fixed mode

[Steven Newbury]

> > > > > On Tue, Mar 29, 2011 at 5:49 PM, Dave Airlie 
> > > > > wrote:
> > > > > > can you guys ask someone internally about it also, there is a
> > > > > > driver somewhere in Google also for driving the LVDS->HDMI
> > > > > > adapter but I'm not sure what i2c bus its hanging off.
> > > > > > 
> > > > > > Dave.
> > > > > 
> > > > > 
> > > > > http://git.chromium.org/gitweb/?p=chrontel.git;a=tree
> > > > > 
> > > > > may or may not be the thing.
> > > > > 
> > > > > Dave.
> > > > I'll see if it works...
> > > Is there a public clone URI for that repo? I dont want to have to
> > > download the full ChromiumOS...
> > Okay, I guessed it right: http://git.chromium.org/git/chrontel.git
> Simply running the resulting executables didn't work, it fails to detect
> the chip, the code also references accesses through GPIO and seems it
> wants an nm10_gpio driver which isn't in my kernel tree. My board is an
> NM10 chipset system, as is the target "Cr48 Chrome Notebook" so it could
> well be the same hardware.

I cherry-picked the nm10_gpio driver from the ChromeOS kernel, but while it 
worked fine the chrontel driver still couldn't detect the chip:

XAUTHORITY=//home/mythtv/.Xauthority ./ch7036_monitor -v -p 
./ch7036_monitor: starts
Found device ID 0xff
./ch7036_monitor: Fatal: Device ID 0xff not the expected 0x56

So either it isn't a ch7036 or I'm still not doing everything necessary to 
expose it.

[Intel-gfx] [PATCH] drm, drm/i915/lvds: Honour video= parameter to override LVDS fixed mode

[Steven Newbury]

- Original message -
> 
> - Original message -
> > - Original message -
> > > - Original message -
> > > > On Tue, Mar 29, 2011 at 5:49 PM, Dave Airlie 
> > > > wrote:
> > > > > can you guys ask someone internally about it also, there is a
> > > > > driver somewhere in Google also for driving the LVDS->HDMI
> > > > > adapter but I'm not sure what i2c bus its hanging off.
> > > > > 
> > > > > Dave.
> > > > 
> > > > 
> > > > http://git.chromium.org/gitweb/?p=chrontel.git;a=tree
> > > > 
> > > > may or may not be the thing.
> > > > 
> > > > Dave.
> > > I'll see if it works...
> > Is there a public clone URI for that repo? I dont want to have to
> > download the full ChromiumOS...
> Okay, I guessed it right: http://git.chromium.org/git/chrontel.git
Simply running the resulting executables didn't work, it fails to detect the 
chip, the code also references accesses through GPIO and seems it wants an 
nm10_gpio driver which isn't in my kernel tree. My board is an NM10 chipset 
system, as is the target "Cr48 Chrome Notebook" so it could well be the same 
hardware.

[Intel-gfx] [PATCH] drm, drm/i915/lvds: Honour video= parameter to override LVDS fixed mode

[Steven Newbury]

- Original message -
> - Original message -
> > - Original message -
> > > On Tue, Mar 29, 2011 at 5:49 PM, Dave Airlie 
> > > wrote:
> > > > On Tue, Mar 29, 2011 at 5:29 PM, Chris Wilson
> > > >  wrote:
> > > > > On Mon, 28 Mar 2011 22:46:55 +0100, Steven Newbury
> > > > >  wrote:
> > > > > > Hi Chris, have you updated this patch? I have an Intel D525
> > > > > > (Pineview) system with HDMI port connected through an LVDS
> > > > > > converter. ?The "panel timings" are the HDMI output mode, and
> > > > > > it gets set through a BIOS option making it impossible to use
> > > > > > the native resolution on the HDTV display.
> > > > > 
> > > > > Can you please attach the EDID for the connection and let's see
> > > > > if there is any tell-tale?
> > > > 
> > > > can you guys ask someone internally about it also, there is a
> > > > driver somewhere in Google also for driving the LVDS->HDMI adapter
> > > > but I'm not sure what i2c bus its hanging off.
> > > > 
> > > > Dave.
> > > 
> > > 
> > > http://git.chromium.org/gitweb/?p=chrontel.git;a=tree
> > > 
> > > may or may not be the thing.
> > > 
> > > Dave.
> > I'll see if it works...
> Is there a public clone URI for that repo? I dont want to have to
> download the full ChromiumOS...
Okay, I guessed it right: http://git.chromium.org/git/chrontel.git

[Intel-gfx] [PATCH] drm, drm/i915/lvds: Honour video= parameter to override LVDS fixed mode

[Steven Newbury]

- Original message -
> - Original message -
> > On Tue, Mar 29, 2011 at 5:49 PM, Dave Airlie  wrote:
> > > On Tue, Mar 29, 2011 at 5:29 PM, Chris Wilson
> > >  wrote:
> > > > On Mon, 28 Mar 2011 22:46:55 +0100, Steven Newbury
> > > >  wrote:
> > > > > Hi Chris, have you updated this patch? I have an Intel D525
> > > > > (Pineview) system with HDMI port connected through an LVDS
> > > > > converter. ?The "panel timings" are the HDMI output mode, and it
> > > > > gets set through a BIOS option making it impossible to use the
> > > > > native resolution on the HDTV display.
> > > > 
> > > > Can you please attach the EDID for the connection and let's see if
> > > > there is any tell-tale?
> > > 
> > > can you guys ask someone internally about it also, there is a driver
> > > somewhere in Google also for driving the LVDS->HDMI adapter but I'm
> > > not sure what i2c bus its hanging off.
> > > 
> > > Dave.
> > 
> > 
> > http://git.chromium.org/gitweb/?p=chrontel.git;a=tree
> > 
> > may or may not be the thing.
> > 
> > Dave.
> I'll see if it works...
Is there a public clone URI for that repo? I dont want to have to download the 
full ChromiumOS...

[PATCH] drm, drm/i915/lvds: Honour video= parameter to override LVDS fixed mode

[Steven Newbury]

- Original message -
> On Tue, Mar 29, 2011 at 5:49 PM, Dave Airlie  wrote:
> > On Tue, Mar 29, 2011 at 5:29 PM, Chris Wilson
> >  wrote:
> > > On Mon, 28 Mar 2011 22:46:55 +0100, Steven Newbury
> > >  wrote:
> > > > Hi Chris, have you updated this patch? I have an Intel D525
> > > > (Pineview) system with HDMI port connected through an LVDS
> > > > converter. ?The "panel timings" are the HDMI output mode, and it
> > > > gets set through a BIOS option making it impossible to use the
> > > > native resolution on the HDTV display.
> > > 
> > > Can you please attach the EDID for the connection and let's see if
> > > there is any tell-tale?
> > 
> > can you guys ask someone internally about it also, there is a driver
> > somewhere in Google also for driving the LVDS->HDMI adapter but I'm
> > not sure what i2c bus its hanging off.
> > 
> > Dave.
> 
> 
> http://git.chromium.org/gitweb/?p=chrontel.git;a=tree
> 
> may or may not be the thing.
> 
> Dave.
I'll see if it works...

[PATCH] drm, drm/i915/lvds: Honour video= parameter to override LVDS fixed mode

[Steven Newbury]

- Original message -
> On Mon, 28 Mar 2011 22:46:55 +0100, Steven Newbury
>  wrote:
> > Hi Chris, have you updated this patch? I have an Intel D525 (Pineview)
> > system with HDMI port connected through an LVDS converter.?  The "panel
> > timings" are the HDMI output mode, and it gets set through a BIOS
> > option making it impossible to use the native resolution on the HDTV
> > display.
> 
> Can you please attach the EDID for the connection and let's see if there
> is any tell-tale?

Unfortunately EDID doesn't seem to be making it through. 
/sys/devices/pci:00/:00:02.0/drm/card0/card0-LVDS-1/edid is empty so I 
tried read-edid, but it reported "Monitor and video card combination does not 
support DDC1/2 transfers".  EDID was present using VGA-DVI so the TV does 
support EDID. (Although it didn't actually support the modes it claimed to when 
it determined it was connected to a PC!)

I've attached dmidecode output in case it helps.
-- next part --
An embedded and charset-unspecified text was scrubbed...
Name: dmi-decoded
URL: 
<http://lists.freedesktop.org/archives/dri-devel/attachments/20110329/1e814552/attachment.asc>

Re: [PATCH] drm, drm/i915/lvds: Honour video= parameter to override LVDS fixed mode

[Steven Newbury]

- Original message -
 On Mon, 28 Mar 2011 22:46:55 +0100, Steven Newbury
 st...@snewbury.org.uk wrote:
  Hi Chris, have you updated this patch? I have an Intel D525 (Pineview)
  system with HDMI port connected through an LVDS converter.   The panel
  timings are the HDMI output mode, and it gets set through a BIOS
  option making it impossible to use the native resolution on the HDTV
  display.
 
 Can you please attach the EDID for the connection and let's see if there
 is any tell-tale?

Unfortunately EDID doesn't seem to be making it through. 
/sys/devices/pci:00/:00:02.0/drm/card0/card0-LVDS-1/edid is empty so I 
tried read-edid, but it reported Monitor and video card combination does not 
support DDC1/2 transfers.  EDID was present using VGA-DVI so the TV does 
support EDID. (Although it didn't actually support the modes it claimed to when 
it determined it was connected to a PC!)

I've attached dmidecode output in case it helps.# dmidecode 2.11
SMBIOS 2.6 present.
22 structures occupying 1254 bytes.
Table at 0x000FB9F0.

Handle 0x, DMI type 0, 24 bytes
BIOS Information
Vendor: American Megatrends Inc.
Version: 080016 
Release Date: 12/01/2010
Address: 0xF
Runtime Size: 64 kB
ROM Size: 1024 kB
Characteristics:
ISA is supported
PCI is supported
PNP is supported
BIOS is upgradeable
BIOS shadowing is allowed
ESCD support is available
Boot from CD is supported
Selectable boot is supported
BIOS ROM is socketed
EDD is supported
5.25/1.2 MB floppy services are supported (int 13h)
3.5/720 kB floppy services are supported (int 13h)
3.5/2.88 MB floppy services are supported (int 13h)
Print screen service is supported (int 5h)
8042 keyboard services are supported (int 9h)
Serial services are supported (int 14h)
Printer services are supported (int 17h)
CGA/mono video services are supported (int 10h)
ACPI is supported
USB legacy is supported
LS-120 boot is supported
ATAPI Zip drive boot is supported
BIOS boot specification is supported
Targeted content distribution is supported
BIOS Revision: 8.16

Handle 0x0001, DMI type 1, 27 bytes
System Information
Manufacturer: To Be Filled By O.E.M.
Product Name: To Be Filled By O.E.M.
Version: To Be Filled By O.E.M.
Serial Number: To Be Filled By O.E.M.
UUID: 03000200-0400-0500-0006-000700080009
Wake-up Type: Power Switch
SKU Number: To Be Filled By O.E.M.
Family: To Be Filled By O.E.M.

Handle 0x0002, DMI type 2, 15 bytes
Base Board Information
Manufacturer: To be filled by O.E.M.
Product Name: To be filled by O.E.M.
Version: To be filled by O.E.M.
Serial Number: To be filled by O.E.M.
Asset Tag: To Be Filled By O.E.M.
Features:
Board is a hosting board
Board is replaceable
Location In Chassis: To Be Filled By O.E.M.
Chassis Handle: 0x0003
Type: Motherboard
Contained Object Handles: 0

Handle 0x0003, DMI type 3, 21 bytes
Chassis Information
Manufacturer: To Be Filled By O.E.M.
Type: Desktop
Lock: Not Present
Version: To Be Filled By O.E.M.
Serial Number: To Be Filled By O.E.M.
Asset Tag: To Be Filled By O.E.M.
Boot-up State: Safe
Power Supply State: Safe
Thermal State: Safe
Security Status: None
OEM Information: 0x
Height: Unspecified
Number Of Power Cords: 1
Contained Elements: 0

Handle 0x0004, DMI type 4, 42 bytes
Processor Information
Socket Designation: CPU 1
Type: Central Processor
Family: Atom
Manufacturer: Intel
ID: CA 06 01 00 FF FB EB BF
Signature: Type 0, Family 6, Model 28, Stepping 10
Flags:
FPU (Floating-point unit on-chip)
VME (Virtual mode extension)
DE (Debugging extension)
PSE (Page size extension)
TSC (Time stamp counter)
MSR (Model specific registers)
PAE (Physical address extension)
MCE (Machine check exception)
CX8 (CMPXCHG8 instruction supported)
APIC (On-chip APIC hardware supported)
SEP (Fast system call)
MTRR (Memory type range registers)
PGE (Page global enable)
MCA (Machine check architecture)
CMOV (Conditional move instruction supported)
PAT (Page attribute table

Re: [PATCH] drm, drm/i915/lvds: Honour video= parameter to override LVDS fixed mode

[Steven Newbury]

- Original message -
 On Tue, Mar 29, 2011 at 5:49 PM, Dave Airlie airl...@gmail.com wrote:
  On Tue, Mar 29, 2011 at 5:29 PM, Chris Wilson
  ch...@chris-wilson.co.uk wrote:
   On Mon, 28 Mar 2011 22:46:55 +0100, Steven Newbury
   st...@snewbury.org.uk wrote:
Hi Chris, have you updated this patch? I have an Intel D525
(Pineview) system with HDMI port connected through an LVDS
converter.  The panel timings are the HDMI output mode, and it
gets set through a BIOS option making it impossible to use the
native resolution on the HDTV display.
   
   Can you please attach the EDID for the connection and let's see if
   there is any tell-tale?
  
  can you guys ask someone internally about it also, there is a driver
  somewhere in Google also for driving the LVDS-HDMI adapter but I'm
  not sure what i2c bus its hanging off.
  
  Dave.
 
 
 http://git.chromium.org/gitweb/?p=chrontel.git;a=tree
 
 may or may not be the thing.
 
 Dave.
I'll see if it works...
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/dri-devel

Re: [Intel-gfx] [PATCH] drm, drm/i915/lvds: Honour video= parameter to override LVDS fixed mode

[Steven Newbury]

- Original message -
 - Original message -
  On Tue, Mar 29, 2011 at 5:49 PM, Dave Airlie airl...@gmail.com wrote:
   On Tue, Mar 29, 2011 at 5:29 PM, Chris Wilson
   ch...@chris-wilson.co.uk wrote:
On Mon, 28 Mar 2011 22:46:55 +0100, Steven Newbury
st...@snewbury.org.uk wrote:
 Hi Chris, have you updated this patch? I have an Intel D525
 (Pineview) system with HDMI port connected through an LVDS
 converter.  The panel timings are the HDMI output mode, and it
 gets set through a BIOS option making it impossible to use the
 native resolution on the HDTV display.

Can you please attach the EDID for the connection and let's see if
there is any tell-tale?
   
   can you guys ask someone internally about it also, there is a driver
   somewhere in Google also for driving the LVDS-HDMI adapter but I'm
   not sure what i2c bus its hanging off.
   
   Dave.
  
  
  http://git.chromium.org/gitweb/?p=chrontel.git;a=tree
  
  may or may not be the thing.
  
  Dave.
 I'll see if it works...
Is there a public clone URI for that repo? I dont want to have to download the 
full ChromiumOS...
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/dri-devel