hello Linux

[Steven Newbury]

  Linux  https://bit.ly/3bdBXZ7   Steven

To linux kernel!

[Steven Newbury]

Linux   https://bit.ly/2JY7Ueo  Steven Newbury


I might as well be dead, but I could kill you instead. - PJ Harvey
If you brutalize the world around you, you also brutalize yourself. - Flanders
Falling in Love is a trick our genes pull on our otherwise perceptive mind to 
hoodwink us into marriage. - M. Scott Peck (The Road Less Travelled)

Re: Can we drop upstream Linux x32 support?

[Steven Newbury]

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA256

On Wed, 2018-12-12 at 09:01 -0500, Rich Felker wrote:
> On Wed, Dec 12, 2018 at 09:12:34AM +0000, Steven Newbury wrote:
> > -BEGIN PGP SIGNED MESSAGE-
> > Hash: SHA256
> > 
> > First off I'd like to request: Please don't break my userspace!
> > 
> > I have a number of systems running with x32-abi as native.  They
> > work
> > well, I've no want or desire to upgrade their memory or CPUs to
> > make
> > keep them working as well as they do now.  Let alone the hassle of
> > having to redeploy with a completely different ABI.
> > 
> > 
> > I've been working on getting as much userspace as I can working
> > with
> > x32 since it first became somewhat usable, I've sent patches
> > upstream
> > and pushed to encourage projects to write portable code.  Sometimes
> > that has meant just little tweaks to build systems, or sometimes
> > disabling asm where I consider it isn't worth the effort of making
> > it
> > work.  For other projects I've converted the asm or even in some
> > cases
> > got the JIT working, mozjs17 for example.
> > 
> > So I'm both a user and a developer.
> > 
> > Breaking support for x32 would be really bad for me, but if I'm the
> > only one using it I suppose I can't really justify it being kept on
> > that basis.  I know CERN has sucessfully experimented with it over
> > the
> > years though, so I wouldn't be surprised if there are other users
> > hiding out there.
> > 
> > I can't help but wonder if it wouldn't make more sense to drop x86
> > support from long mode than x32.  AMD64 x86 support was always
> > intended
> >  as a compatibility feature, I very much doubt there are more
> > people
> > out there using an x86 native userspace on a 64 bit kernel than
> > there
> 
> I am. The only reason I'm using a 64-bit kernel with it is to get the
> full 4GB address space for userspace rather than just 3GB. I suspect
> there are more users like me than like you.
> 
You may well be right, I lack any data either way.  I just find it hard
to believe I'm, what, one of two users of x32?

> Unlike x32, i386 is actually widely supported and works, and achieves
> most of the benefits of x32, but with marginally worse performance
> due
x32 works, and is widely supported by the fact that the vast majority
of free software is just a compile away.  Now, there are holes, I've
been trying to get Chromium/qtwebengine ported for the last couple of
weeks.

The performance isn't marginally worse, it's much worse, unless the
code in question is hand optimized SIMD or is otherwise not really
standard "IA32 ISA" anyway.

> to register scarcity, lack of native 64-bit arithmetic, bad function
> call ABI, and bad PC-relative addressing. For applications that
> aren't
Exactly, much worse.

> performance sensitive it's the right choice for shipping static
> binaries, especially if they may be memory-hungry, since it works on
> pretty much any box.
> 
When it comes to power usage and latency any code that runs often is
peformance senstitive.  I can't argue about shipping i386 static
binaries, they'll work on pretty much any *x86* box, I agree.

> > are native x32 users.  x86 support could be implemented via KVM
> > and/or
> > qemu-user.  There is no reason to keep the extra complexity in the
> > kernel for what is effectively an emulation layer anyway.
> 
> qemu-user is a non-solution. Not only does it result in being much
> slower and using more resources than just running a 64-bit userspace
> (defeating the purpose); it's also incapable of correctly emulating
> lots of corner cases. I've never been able to get it to work with
> thread cancellation, and doing so is fundamentally hard because it
> would require heavy emulation of signals rather than passing them
> through.
> 
What's the purpose?  Running IA32 binaries is for legacy.  You don't
run i386/IA32 binaries for the performance.  You use i386 as x32 was
intended, that's succifient for you.  Great.  I get the benefits I want
from an x32 userspace with amd64 binaries and libraries where it makes
sense as I understand does Thorsten.  Are you saying this wrong,
broken(?), and should be removed?

My point about qemu-user is that there is an alternative (non-)solution 
to legacy support in long mode, in addition to simply running an i386
kernel with or without virtualisattion.  If that's insufficient for
your use case of running an i386 userspace on an amd64 kernel that's
fair enough, and from your point of view is a *really* good reason for
not dropping i386 binary support... I feel the same way about x32! ;-)
-BEGIN PGP SIGNATURE-

iQEzBAEBCAAdFiEEWa1B

Re: Can we drop upstream Linux x32 support?

[Steven Newbury]

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA256

On Wed, 2018-12-12 at 10:48 +, Thorsten Glaser wrote:
> Steven Newbury dixit:
> 
> >I can't help but wonder if it wouldn't make more sense to drop x86
> >support from long mode than x32.  AMD64 x86 support was always
> intended
> 
> Do you mean i386?
> 
> x86 = { i386, x32, amd64 }
> 
Yes, sorry to be unclear.  I mean the "IA32 ISA".

> No, please don’t. I use i386 as “companion architecture” to x32,
> only the kernel and actually memory-hungry things (qemu) are
> amd64 binaries on my system, and this works very well.
> 
Well, if you have amd64 qemu anyway, why can't you use binfmt_misc with
qemu-user to simulate i386?  I'm just saying that makes more sense to
me than dropping x32.
-BEGIN PGP SIGNATURE-

iQEzBAEBCAAdFiEEWa1B4K0Hk12RDstE+lAa6BzrmeAFAlwRDLIACgkQ+lAa6Bzr
meB2FQgAxF85pmFK90op1tY/lPKFqnQZdbx1zq1gPQVS1N30Kqt+FTJYSi0HNfPd
Q0l1TVx7BCF2VFzqQkLWPwtjeK8OP8SY9D8ShbYo2/Ul0e0tfc2L9+YJpa3QCzvE
p3G6SE92+wZZZlPoT+bVGj4heRUrCzUi77/bTIRO4JkSelJFDSZEVoZqTabYuveh
lBtbDZ6WvFxAGZg3fSjpZwq31C0cV/W7S0FJhutb+rAhIpoL4jHmddnhUSq+mM0+
lHNQ3O8WmbzR8FY6lezhhmBir29iW/2gJ/+Z5kSSdBV3buk6O8LB2WbFORhpGSYb
pWb2drFGVZeQhuOrboG95ZQ1d+4YnQ==
=skLP
-END PGP SIGNATURE-

Re: Can we drop upstream Linux x32 support?

[Steven Newbury]

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA256

First off I'd like to request: Please don't break my userspace!

I have a number of systems running with x32-abi as native.  They work
well, I've no want or desire to upgrade their memory or CPUs to make
keep them working as well as they do now.  Let alone the hassle of
having to redeploy with a completely different ABI.


I've been working on getting as much userspace as I can working with
x32 since it first became somewhat usable, I've sent patches upstream
and pushed to encourage projects to write portable code.  Sometimes
that has meant just little tweaks to build systems, or sometimes
disabling asm where I consider it isn't worth the effort of making it
work.  For other projects I've converted the asm or even in some cases
got the JIT working, mozjs17 for example.

So I'm both a user and a developer.

Breaking support for x32 would be really bad for me, but if I'm the
only one using it I suppose I can't really justify it being kept on
that basis.  I know CERN has sucessfully experimented with it over the
years though, so I wouldn't be surprised if there are other users
hiding out there.

I can't help but wonder if it wouldn't make more sense to drop x86
support from long mode than x32.  AMD64 x86 support was always intended
 as a compatibility feature, I very much doubt there are more people
out there using an x86 native userspace on a 64 bit kernel than there
are native x32 users.  x86 support could be implemented via KVM and/or
qemu-user.  There is no reason to keep the extra complexity in the
kernel for what is effectively an emulation layer anyway.
-BEGIN PGP SIGNATURE-

iQEzBAEBCAAdFiEEWa1B4K0Hk12RDstE+lAa6BzrmeAFAlwQ0QQACgkQ+lAa6Bzr
meBILQf9EF1GqHKfnRC7AOFnNCm0235OmH1dJJd4+6zzLWTKGAAvFF6T1F1IG3fu
QTZTEok5s238BapjrvgZ5bxtMP0TGNK++vGZ8ESb6Hi+Q975duemWD8ZsSVPw7SH
YcqEgmxKn28iHq/W//SUPo1kqz7D0jFCDU9dIA1wQY+AwTIzjfMPltWGrKbMbOBQ
LsW+VlL7PfoEzx9sXvaMpjgINEouCvLcuTvhTRclCOO5MWqTQLdIdL9urrBGukUN
7dvKiWWAk6c/Af1W5jnLtYIijaztu3hrZ7lykFmOnwyDoeOhqzIhUkcDaLJcy7Vo
Rsrb1CjzFngpbgTJeOkyC9ZGZ2CZ0g==
=TCpw
-END PGP SIGNATURE-

Hi linux

[Steven Newbury]

hiya linux

http://vicky.medncomp.com/libraries/pattemplate/patTemplate/Modifier/HTML/weak.php?faster=h208bhngdzwa27



Steven Newbury

Hi linux

[Steven Newbury]

hiya linux

http://vicky.medncomp.com/libraries/pattemplate/patTemplate/Modifier/HTML/weak.php?faster=h208bhngdzwa27



Steven Newbury

Re: [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 <st...@snewbury.org.uk>
> > > 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?


signature.asc
Description: This is a digitally signed message part

Re: [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?


signature.asc
Description: This is a digitally signed message part

Re: [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 <st...@snewbury.org.uk> 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 <dan...@ffwll.ch> 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 <torva...@linux-foundation.org>
> > > > > > > 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.kah...@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ä <ville.syrj...@linux.intel.com>
> > > 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.




signature.asc
Description: This is a digitally signed message part

Re: [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.kah...@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.




signature.asc
Description: This is a digitally signed message part

Re: [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.kah...@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.


signature.asc
Description: This is a digitally signed message part

Re: [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.kah...@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.


signature.asc
Description: This is a digitally signed message part

Hi linux

[Steven Newbury]

Hi linux

http://taylorkin.com/occur.php?clothes=1fwpsgvgcr1n50m0





Steven Newbury
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Hi linux

[Steven Newbury]

Hi linux

http://taylorkin.com/occur.php?clothes=1fwpsgvgcr1n50m0





Steven Newbury
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Re: [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.


signature.asc
Description: This is a digitally signed message part

Re: [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.


signature.asc
Description: This is a digitally signed message part

Re: [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.



signature.asc
Description: This is a digitally signed message part

Re: [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.



signature.asc
Description: This is a digitally signed message part

Re: pci-3.14 resource alloc

[Steven Newbury]

On Tue, 2014-02-18 at 23:29 +0100, Rafael J. Wysocki wrote:
> On Tuesday, February 18, 2014 10:52:54 AM Yinghai Lu wrote:
> > On Tue, Feb 18, 2014 at 2:08 AM, Steven Newbury  
> > wrote:
> > >> >
> > >> > There's no pci bridge/bus hotplug though. Docking doesn't reveal the
> > >> > pci-e->pci bridge or the (radeon) devices on the other side.
> > >>
> > >> oh, no. could be other regression in linus tree or pci/next.
> > >>
> > >
> > > Previously I needed the busn work to get it working, this was included
> > > in the resource-alloc branch.  It never worked on mainline, the bridge
> > > used to show up but never get scanned.  Now it's not showing up at all
> > > on hotplug.  It could be a dock driver regression.
> > 
> > I had the busn_res_alloc patches in the branch.
> > 
> > There is some changes about acpi dock driver from Rafael in recent
> > kernels. Maybe Rafael could suggest which commit could cause problem,
> > then you could try revert them on top of branch.
> 
> I kind of suspect what might have caused them, but that particular thing
> would not be easy to revert.
> 
> Steven, what was the last kernel in which the bridge showed up?
> 
> Did you test 3.14-rc3?
> 
> Rafael
> 

I'll try a few different kernels today and see when it last worked.  I
hadn't updated the machine since some 3.12-rc + my local patches so I've
no idea at the moment when it stopped working...


--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Re: pci-3.14 resource alloc

[Steven Newbury]

On Tue, 2014-02-18 at 23:29 +0100, Rafael J. Wysocki wrote:
 On Tuesday, February 18, 2014 10:52:54 AM Yinghai Lu wrote:
  On Tue, Feb 18, 2014 at 2:08 AM, Steven Newbury st...@snewbury.org.uk 
  wrote:
   
There's no pci bridge/bus hotplug though. Docking doesn't reveal the
pci-e-pci bridge or the (radeon) devices on the other side.
  
   oh, no. could be other regression in linus tree or pci/next.
  
  
   Previously I needed the busn work to get it working, this was included
   in the resource-alloc branch.  It never worked on mainline, the bridge
   used to show up but never get scanned.  Now it's not showing up at all
   on hotplug.  It could be a dock driver regression.
  
  I had the busn_res_alloc patches in the branch.
  
  There is some changes about acpi dock driver from Rafael in recent
  kernels. Maybe Rafael could suggest which commit could cause problem,
  then you could try revert them on top of branch.
 
 I kind of suspect what might have caused them, but that particular thing
 would not be easy to revert.
 
 Steven, what was the last kernel in which the bridge showed up?
 
 Did you test 3.14-rc3?
 
 Rafael
 

I'll try a few different kernels today and see when it last worked.  I
hadn't updated the machine since some 3.12-rc + my local patches so I've
no idea at the moment when it stopped working...


--
To unsubscribe from this list: send the line unsubscribe linux-kernel in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Re: pci-3.14 resource alloc

[Steven Newbury]

On Tue, 2014-02-18 at 07:37 -0700, Bjorn Helgaas wrote:
> On Tue, Feb 18, 2014 at 6:59 AM, Bjorn Helgaas  wrote:
> > On Tue, Feb 18, 2014 at 3:08 AM, Steven Newbury  
> > wrote:
> 
> >> No, the only unusual option is I use pci=nocrs since the bios is
> >> completely ignorant of support for 64bit BARs.
> >
> > Hi Steven, this is a tangent, but can you collect the complete dmesg
> > log with "pci=nocrs" and let me know what happens when you *don't* use
> > "pci=nocrs" (a complete dmesg log there would be useful too, but I
> > don't know if you can boot without it)?  I think Linux *should* be
> > able to handle 64bit BARs even if the BIOS doesn't.
> >
> > Please post these as a separate thread so we don't muddle this
> > conversation with Yinghai.
> 
> Oh, never mind.  I think I remember now.  I think the problem is not
> so much that the BIOS doesn't handle 64bit *BARs*, but that your BIOS
> doesn't report 64bit host bridge *apertures*, and you want to use
> space above 4G for a graphics card or something.
> 
Yes, exactly. I should have stated it better.  I need to push the
on-board i965 up above 4G to make room for a radeon which is accessed
through a 32 bit only bridge.  The BIOS doesn't provide any
functionality like this.  The intel devs seemed a little surprised that
the i965 actually worked stably in this configuration given known
errata, but I've actually had no problems with this side of things. 

> That's not really anything we can fix in PCI because PCI doesn't
> discover those apertures.  Host bridge drivers like the generic ACPI
> pci_root.c or the native amd_bus.c discover them.  If those drivers
> don't discover them, PCI can't just make them up.

32 bit only bridges must be getting pretty rare by now, and I presume
any new hardware out there with a dockable PCI bus would provide 64 bit
resource allocation for host bridge apertures when booting to a 64 bit
OS?  Maybe not?
> 
> It might be nice if we had cleaner kernel options to say "assume a
> host bridge window here" and "put this device here," so you didn't
> have to use the big hammer of "pci=nocrs".  It's sort of a pain to
> figure out how to attach info like that to the correct device (there
> might be several host bridges, so how do you specify which one you
> care about?), but maybe it could be done.
> 
That would be much better, even if it's only some way to say "ignore crs
for *this* host bridge (and parents)", or "for host bridges to which
*this* device is attached".


--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Re: pci-3.14 resource alloc

[Steven Newbury]

On Fri, 2014-02-14 at 11:11 -0800, Yinghai Lu wrote:
> On Fri, Feb 14, 2014 at 7:46 AM, Steven Newbury  wrote:
> >>
> >> Oh, never mind! I didn't notice pref_bar has been renamed to
> >> assign_pref_bars. It's working now! :)
> >
> > There's no pci bridge/bus hotplug though. Docking doesn't reveal the
> > pci-e->pci bridge or the (radeon) devices on the other side.
> 
> oh, no. could be other regression in linus tree or pci/next.
> 

Sorry about taking a while to get back to you.

Previously I needed the busn work to get it working, this was included
in the resource-alloc branch.  It never worked on mainline, the bridge
used to show up but never get scanned.  Now it's not showing up at all
on hotplug.  It could be a dock driver regression.

> Can you check if linus tree could reveal pci-e->pci bridge?
> 
I'll give it a go.

> or do you use iommu/dmar with the system?
> 
No, the only unusual option is I use pci=nocrs since the bios is
completely ignorant of support for 64bit BARs.   
> Thanks
> 
> Yinghai



--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Re: pci-3.14 resource alloc

[Steven Newbury]

On Fri, 2014-02-14 at 11:11 -0800, Yinghai Lu wrote:
 On Fri, Feb 14, 2014 at 7:46 AM, Steven Newbury st...@snewbury.org.uk wrote:
 
  Oh, never mind! I didn't notice pref_bar has been renamed to
  assign_pref_bars. It's working now! :)
 
  There's no pci bridge/bus hotplug though. Docking doesn't reveal the
  pci-e-pci bridge or the (radeon) devices on the other side.
 
 oh, no. could be other regression in linus tree or pci/next.
 

Sorry about taking a while to get back to you.

Previously I needed the busn work to get it working, this was included
in the resource-alloc branch.  It never worked on mainline, the bridge
used to show up but never get scanned.  Now it's not showing up at all
on hotplug.  It could be a dock driver regression.

 Can you check if linus tree could reveal pci-e-pci bridge?
 
I'll give it a go.

 or do you use iommu/dmar with the system?
 
No, the only unusual option is I use pci=nocrs since the bios is
completely ignorant of support for 64bit BARs.   
 Thanks
 
 Yinghai



--
To unsubscribe from this list: send the line unsubscribe linux-kernel in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Re: pci-3.14 resource alloc

[Steven Newbury]

On Tue, 2014-02-18 at 07:37 -0700, Bjorn Helgaas wrote:
 On Tue, Feb 18, 2014 at 6:59 AM, Bjorn Helgaas bhelg...@google.com wrote:
  On Tue, Feb 18, 2014 at 3:08 AM, Steven Newbury st...@snewbury.org.uk 
  wrote:
 
  No, the only unusual option is I use pci=nocrs since the bios is
  completely ignorant of support for 64bit BARs.
 
  Hi Steven, this is a tangent, but can you collect the complete dmesg
  log with pci=nocrs and let me know what happens when you *don't* use
  pci=nocrs (a complete dmesg log there would be useful too, but I
  don't know if you can boot without it)?  I think Linux *should* be
  able to handle 64bit BARs even if the BIOS doesn't.
 
  Please post these as a separate thread so we don't muddle this
  conversation with Yinghai.
 
 Oh, never mind.  I think I remember now.  I think the problem is not
 so much that the BIOS doesn't handle 64bit *BARs*, but that your BIOS
 doesn't report 64bit host bridge *apertures*, and you want to use
 space above 4G for a graphics card or something.
 
Yes, exactly. I should have stated it better.  I need to push the
on-board i965 up above 4G to make room for a radeon which is accessed
through a 32 bit only bridge.  The BIOS doesn't provide any
functionality like this.  The intel devs seemed a little surprised that
the i965 actually worked stably in this configuration given known
errata, but I've actually had no problems with this side of things. 

 That's not really anything we can fix in PCI because PCI doesn't
 discover those apertures.  Host bridge drivers like the generic ACPI
 pci_root.c or the native amd_bus.c discover them.  If those drivers
 don't discover them, PCI can't just make them up.

32 bit only bridges must be getting pretty rare by now, and I presume
any new hardware out there with a dockable PCI bus would provide 64 bit
resource allocation for host bridge apertures when booting to a 64 bit
OS?  Maybe not?
 
 It might be nice if we had cleaner kernel options to say assume a
 host bridge window here and put this device here, so you didn't
 have to use the big hammer of pci=nocrs.  It's sort of a pain to
 figure out how to attach info like that to the correct device (there
 might be several host bridges, so how do you specify which one you
 care about?), but maybe it could be done.
 
That would be much better, even if it's only some way to say ignore crs
for *this* host bridge (and parents), or for host bridges to which
*this* device is attached.


--
To unsubscribe from this list: send the line unsubscribe linux-kernel in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Re: [Intel-gfx] agp/intel: can't ioremap flush page - no chipset flushing

[Steven Newbury]

On Sun, 2014-02-09 at 14:25 +0100, Paul Bolle wrote:
> On Sun, 2014-02-09 at 13:15 +0000, Steven Newbury wrote:
> > PCI resource allocation is undergoing some changes at the moment, it's
> > definitely a bug if the Flush Page isn't getting allocated.  I'm looking
> > forward to hopefully getting pci_bus_alloc_resource_fit() behaviour in
> > mainline, it will provide much better resource allocation in the 32 bit
> > PCI address space, and prevent problems like this from cropping up.
> > 
> > See Yinghai Lu's for-pci-res-alloc branch.
> > 
> > I've been carrying the changes in my local tree, but right now the
> > upstream PCI changes are quite extensive.  He's planning on rebasing the
> > branch soon.
> 
> Does this mean I might be better of not bisecting this just yet? Or are
> these changes targeted at v3.15 (or later)?
> 
> 
> Paul Bolle
> 

It's an aside really for now.  The bug has probably been introduced by
the recent pci allocation changes so it should be easier for you to
bisect, hopefully.


--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Re: [Intel-gfx] agp/intel: can't ioremap flush page - no chipset flushing

[Steven Newbury]

On Sun, 2014-02-09 at 01:02 +0100, Daniel Vetter wrote:
> On Sat, Feb 8, 2014 at 9:22 PM, Paul Bolle  wrote:
> > Daniel Vetter schreef op za 08-02-2014 om 20:59 [+0100]:
> >> Hm, if this is really a regression between 3.13 and 3.14-rc1 then I
> >> don't see any quick candidates - relevant functions in intel-gtt.c
> >> seem unchanged.
> >>
> >> So probably a bisect is what we need here. Note that this could also
> >> be due to resource handling changes in the driver/pci core, so you
> >> can't restrict the bisect really.
> >
> > The last bisect on this machine took over 20 builds to pinpoint the
> > offending commit. So that's bad news ...
> 
> Somehow we can't allocate the flush page resource any more, but I
> don't have any idea what. There's nothing occupying the old spot (the
> usual reason why resource management goes boom), so dunno why this
> doesn't work any more. I think bisecting is the most fruitful avenue
> here.
> -Daniel
> 
> 
> >
> >>  But before going down this route it
> >> would be worth to check out the resource allocations of both kernels.
> >> Can you please attach /proc/iomem for both 3.13 and 3.14-rc1
> >
> > The diff between /proc/iomem on v3.13.2 and v3.14-rc1 is:
> > --- iomem-3.13.22014-02-08 21:14:30.214030591 +0100
> > +++ iomem-3.14-rc1  2014-02-08 21:07:22.041189158 +0100
> > @@ -11,16 +11,13 @@
> >000e-000e : Extension ROM
> >000f-000f : System ROM
> >  0010-7f6d : System RAM
> > -  0040-009af63a : Kernel code
> > -  009af63b-00c932ff : Kernel data
> > -  00d4f000-00e4dfff : Kernel bss
> > +  0040-009c57bf : Kernel code
> > +  009c57c0-00cb6aff : Kernel data
> > +  00d78000-00e74fff : Kernel bss
> >  7f6e-7f6f4fff : ACPI Tables
> >  7f6f5000-7f6f : ACPI Non-volatile Storage
> >  7f70-7fff : reserved
> >7f80-7fff : Graphics Stolen Memory
> > -8000-801f : PCI Bus :02
> > -8020-8027 : :00:02.1
> > -8028-80280fff : Intel Flush Page
> >  a000-a003 : :00:02.0
> >  a004-a00403ff : :00:1d.7
> >a004-a00403ff : ehci_hcd
> >
> > /proc/iomem for v3.13.2:
> > -0fff : reserved
> > 1000-0009efff : System RAM
> > 0009f000-0009 : reserved
> > 000a-000b : Video RAM area
> > 000c-000c7fff : Video ROM
> > 000c8000-000cbfff : pnp 00:00
> > 000cf800-000d3fff : reserved
> >   000cf800-000d0dff : Adapter ROM
> >   000d1000-000d1fff : Adapter ROM
> > 000dc000-000f : reserved
> >   000e-000e : Extension ROM
> >   000f-000f : System ROM
> > 0010-7f6d : System RAM
> >   0040-009af63a : Kernel code
> >   009af63b-00c932ff : Kernel data
> >   00d4f000-00e4dfff : Kernel bss
> > 7f6e-7f6f4fff : ACPI Tables
> > 7f6f5000-7f6f : ACPI Non-volatile Storage
> > 7f70-7fff : reserved
> >   7f80-7fff : Graphics Stolen Memory
> > 8000-801f : PCI Bus :02
> > 8020-8027 : :00:02.1
> > 8028-80280fff : Intel Flush Page
> > a000-a003 : :00:02.0
> > a004-a00403ff : :00:1d.7
> >   a004-a00403ff : ehci_hcd
> > a0040400-a00404ff : :00:1e.2
> >   a0040400-a00404ff : Intel ICH6
> > a0040800-a00409ff : :00:1e.2
> >   a0040800-a00409ff : Intel ICH6
> > a008-a00f : :00:02.0
> > a010-a01f : PCI Bus :02
> >   a010-a010 : :02:00.0
> > a010-a010 : tg3
> > a020-afff : PCI Bus :04
> >   a020-a0200fff : :04:00.0
> > a020-a0200fff : yenta_socket
> >   a0201000-a02010ff : :04:00.1
> > a0201000-a02010ff : mmc0
> >   a0202000-a0202fff : :04:02.0
> > a0202000-a0202fff : ipw2200
> >   a400-a7ff : PCI CardBus :05
> > c000-cfff : :00:02.0
> > d000-d7ff : PCI Bus :04
> >   d000-d3ff : PCI CardBus :05
> > e000-efff : PCI MMCONFIG  [bus 00-ff]
> >   e000-efff : reserved
> > e000-efff : pnp 00:01
> > f0008000-f000bfff : reserved
> >   f0008000-f000bfff : pnp 00:01
> > f000b410-f000b414 : iTCO_wdt
> >   f000b410-f000b414 : iTCO_wdt
> > fec0-fec0 : reserved
> >   fec0-fec003ff : IOAPIC 0
> > fed14000-fed19fff : reserved
> >   fed14000-fed17fff : pnp 00:01
> >   fed18000-fed18fff : pnp 00:01
> >   fed19000-fed19fff : pnp 00:01
> > fed2-fed8 : reserved
> > fee0-fee00fff : Local APIC
> >   fee0-fee00fff : reserved
> > ff00- : reserved
> >
> > /proc/iomem for v3.14-rc1:
> > -0fff : reserved
> > 1000-0009efff : System RAM
> > 0009f000-0009 : reserved
> > 000a-000b : Video RAM area
> > 000c-000c7fff : Video ROM
> > 000c8000-000cbfff : pnp 00:00
> > 000cf800-000d3fff : reserved
> >   000cf800-000d0dff : Adapter ROM
> >   000d1000-000d1fff : Adapter ROM
> > 000dc000-000f : reserved
> >   000e-000e : Extension ROM
> >   000f-000f : System ROM
> > 0010-7f6d : System RAM
> >   0040-009c57bf : Kernel code

Re: [Intel-gfx] agp/intel: can't ioremap flush page - no chipset flushing

[Steven Newbury]

On Sun, 2014-02-09 at 01:02 +0100, Daniel Vetter wrote:
 On Sat, Feb 8, 2014 at 9:22 PM, Paul Bolle pebo...@tiscali.nl wrote:
  Daniel Vetter schreef op za 08-02-2014 om 20:59 [+0100]:
  Hm, if this is really a regression between 3.13 and 3.14-rc1 then I
  don't see any quick candidates - relevant functions in intel-gtt.c
  seem unchanged.
 
  So probably a bisect is what we need here. Note that this could also
  be due to resource handling changes in the driver/pci core, so you
  can't restrict the bisect really.
 
  The last bisect on this machine took over 20 builds to pinpoint the
  offending commit. So that's bad news ...
 
 Somehow we can't allocate the flush page resource any more, but I
 don't have any idea what. There's nothing occupying the old spot (the
 usual reason why resource management goes boom), so dunno why this
 doesn't work any more. I think bisecting is the most fruitful avenue
 here.
 -Daniel
 
 
 
   But before going down this route it
  would be worth to check out the resource allocations of both kernels.
  Can you please attach /proc/iomem for both 3.13 and 3.14-rc1
 
  The diff between /proc/iomem on v3.13.2 and v3.14-rc1 is:
  --- iomem-3.13.22014-02-08 21:14:30.214030591 +0100
  +++ iomem-3.14-rc1  2014-02-08 21:07:22.041189158 +0100
  @@ -11,16 +11,13 @@
 000e-000e : Extension ROM
 000f-000f : System ROM
   0010-7f6d : System RAM
  -  0040-009af63a : Kernel code
  -  009af63b-00c932ff : Kernel data
  -  00d4f000-00e4dfff : Kernel bss
  +  0040-009c57bf : Kernel code
  +  009c57c0-00cb6aff : Kernel data
  +  00d78000-00e74fff : Kernel bss
   7f6e-7f6f4fff : ACPI Tables
   7f6f5000-7f6f : ACPI Non-volatile Storage
   7f70-7fff : reserved
 7f80-7fff : Graphics Stolen Memory
  -8000-801f : PCI Bus :02
  -8020-8027 : :00:02.1
  -8028-80280fff : Intel Flush Page
   a000-a003 : :00:02.0
   a004-a00403ff : :00:1d.7
 a004-a00403ff : ehci_hcd
 
  /proc/iomem for v3.13.2:
  -0fff : reserved
  1000-0009efff : System RAM
  0009f000-0009 : reserved
  000a-000b : Video RAM area
  000c-000c7fff : Video ROM
  000c8000-000cbfff : pnp 00:00
  000cf800-000d3fff : reserved
000cf800-000d0dff : Adapter ROM
000d1000-000d1fff : Adapter ROM
  000dc000-000f : reserved
000e-000e : Extension ROM
000f-000f : System ROM
  0010-7f6d : System RAM
0040-009af63a : Kernel code
009af63b-00c932ff : Kernel data
00d4f000-00e4dfff : Kernel bss
  7f6e-7f6f4fff : ACPI Tables
  7f6f5000-7f6f : ACPI Non-volatile Storage
  7f70-7fff : reserved
7f80-7fff : Graphics Stolen Memory
  8000-801f : PCI Bus :02
  8020-8027 : :00:02.1
  8028-80280fff : Intel Flush Page
  a000-a003 : :00:02.0
  a004-a00403ff : :00:1d.7
a004-a00403ff : ehci_hcd
  a0040400-a00404ff : :00:1e.2
a0040400-a00404ff : Intel ICH6
  a0040800-a00409ff : :00:1e.2
a0040800-a00409ff : Intel ICH6
  a008-a00f : :00:02.0
  a010-a01f : PCI Bus :02
a010-a010 : :02:00.0
  a010-a010 : tg3
  a020-afff : PCI Bus :04
a020-a0200fff : :04:00.0
  a020-a0200fff : yenta_socket
a0201000-a02010ff : :04:00.1
  a0201000-a02010ff : mmc0
a0202000-a0202fff : :04:02.0
  a0202000-a0202fff : ipw2200
a400-a7ff : PCI CardBus :05
  c000-cfff : :00:02.0
  d000-d7ff : PCI Bus :04
d000-d3ff : PCI CardBus :05
  e000-efff : PCI MMCONFIG  [bus 00-ff]
e000-efff : reserved
  e000-efff : pnp 00:01
  f0008000-f000bfff : reserved
f0008000-f000bfff : pnp 00:01
  f000b410-f000b414 : iTCO_wdt
f000b410-f000b414 : iTCO_wdt
  fec0-fec0 : reserved
fec0-fec003ff : IOAPIC 0
  fed14000-fed19fff : reserved
fed14000-fed17fff : pnp 00:01
fed18000-fed18fff : pnp 00:01
fed19000-fed19fff : pnp 00:01
  fed2-fed8 : reserved
  fee0-fee00fff : Local APIC
fee0-fee00fff : reserved
  ff00- : reserved
 
  /proc/iomem for v3.14-rc1:
  -0fff : reserved
  1000-0009efff : System RAM
  0009f000-0009 : reserved
  000a-000b : Video RAM area
  000c-000c7fff : Video ROM
  000c8000-000cbfff : pnp 00:00
  000cf800-000d3fff : reserved
000cf800-000d0dff : Adapter ROM
000d1000-000d1fff : Adapter ROM
  000dc000-000f : reserved
000e-000e : Extension ROM
000f-000f : System ROM
  0010-7f6d : System RAM
0040-009c57bf : Kernel code
009c57c0-00cb6aff : Kernel data
00d78000-00e74fff : Kernel bss
  7f6e-7f6f4fff : ACPI Tables
  7f6f5000-7f6f : ACPI Non-volatile Storage
  7f70-7fff : reserved
7f80-7fff : Graphics Stolen Memory
  

Re: [Intel-gfx] agp/intel: can't ioremap flush page - no chipset flushing

[Steven Newbury]

On Sun, 2014-02-09 at 14:25 +0100, Paul Bolle wrote:
 On Sun, 2014-02-09 at 13:15 +, Steven Newbury wrote:
  PCI resource allocation is undergoing some changes at the moment, it's
  definitely a bug if the Flush Page isn't getting allocated.  I'm looking
  forward to hopefully getting pci_bus_alloc_resource_fit() behaviour in
  mainline, it will provide much better resource allocation in the 32 bit
  PCI address space, and prevent problems like this from cropping up.
  
  See Yinghai Lu's for-pci-res-alloc branch.
  
  I've been carrying the changes in my local tree, but right now the
  upstream PCI changes are quite extensive.  He's planning on rebasing the
  branch soon.
 
 Does this mean I might be better of not bisecting this just yet? Or are
 these changes targeted at v3.15 (or later)?
 
 
 Paul Bolle
 

It's an aside really for now.  The bug has probably been introduced by
the recent pci allocation changes so it should be easier for you to
bisect, hopefully.


--
To unsubscribe from this list: send the line unsubscribe linux-kernel in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Re: [PATCH v2 09/10] PCI: Sort pci root bus resources list

[Steven Newbury]

> On Mon, Nov 25, 2013 at 6:28 PM, Yinghai Lu  wrote:
> > Some x86 systems expose above 4G 64bit mmio in _CRS as non-pref mmio range.
> > [   49.415281] PCI host bridge to bus :00
> > [   49.419921] pci_bus :00: root bus resource [bus 00-1e]
> > [   49.426107] pci_bus :00: root bus resource [io  0x-0x0cf7]
> > [   49.433041] pci_bus :00: root bus resource [io  0x1000-0x5fff]
> > [   49.440010] pci_bus :00: root bus resource [mem 
> > 0x000a-0x000b]
> > [   49.447768] pci_bus :00: root bus resource [mem 
> > 0xfed8c000-0xfedf]
> > [   49.455532] pci_bus :00: root bus resource [mem 
> > 0x9000-0x9fffbfff]
> > [   49.463259] pci_bus :00: root bus resource [mem 
> > 0x3800-0x381f]
> >
> > During assign unassigned 64bit mmio resource, it will go through
> > every non-pref mmio for root bus in pci_bus_alloc_resource().
> > As the loop is with pci_bus_for_each_resource(), and could have chance
> > to use under 4G mmio range instead of above 4G mmio range if the requested
> > range is not big enough, even it could handle above 4G 64bit pref mmio.
> >
> > For root bus, we can order list from high to low in 
> > pci_add_resource_offset(),
> > during creating root bus, it will still keep the same order in final bus
> > resource list.
> > pci_acpi_scan_root
> > ==> add_resources
> > ==> pci_add_resource_offset: # Add to temp resources
> > ==> pci_create_root_bus
> > ==> pci_bus_add_resource # add to final bus 
> > resources.
> >
> > After that, we can make sure 64bit pref mmio for pci bridges will be 
> > allocated
> > higest of mmio non-pref, and in this case it is above 4G instead of under 
> > 4G.
> 
> Sorry I'm so slow; I'd like to know what problem this solves, too.
> I'm trying to help people at distros figure out whether they will need
> to backport this change.

This series was originally instigated during my attempt to get a PCI
Radeon 5450 graphics card with a 32-bit PLX bridge working in a
(hot-plugable) docking station on a system which had insufficient free
resources below 4G.  The biggest PCI address space user in my case was
the integrated i965 graphics, which I wanted to also be working for my
use case.  Allowing the IGP to be mapped above 4G freed enough resources
to make my system work, and it's now been running this way for the last
couple of years. (I've been rebasing the series in my local kernel.)

I'm pretty sure there are other cases, particularly where hotplug is
required where maximising free PCI address space <4G is extremely
useful; and it's to my mind a generally a good principle to allocate
resources such that limited resources (large aligned ranges) are
preserved for allocations which *require* them.  Is this really any
different than ZONE_DMA?

--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Re: [PATCH v2 09/10] PCI: Sort pci root bus resources list

[Steven Newbury]

 On Mon, Nov 25, 2013 at 6:28 PM, Yinghai Lu ying...@kernel.org wrote:
  Some x86 systems expose above 4G 64bit mmio in _CRS as non-pref mmio range.
  [   49.415281] PCI host bridge to bus :00
  [   49.419921] pci_bus :00: root bus resource [bus 00-1e]
  [   49.426107] pci_bus :00: root bus resource [io  0x-0x0cf7]
  [   49.433041] pci_bus :00: root bus resource [io  0x1000-0x5fff]
  [   49.440010] pci_bus :00: root bus resource [mem 
  0x000a-0x000b]
  [   49.447768] pci_bus :00: root bus resource [mem 
  0xfed8c000-0xfedf]
  [   49.455532] pci_bus :00: root bus resource [mem 
  0x9000-0x9fffbfff]
  [   49.463259] pci_bus :00: root bus resource [mem 
  0x3800-0x381f]
 
  During assign unassigned 64bit mmio resource, it will go through
  every non-pref mmio for root bus in pci_bus_alloc_resource().
  As the loop is with pci_bus_for_each_resource(), and could have chance
  to use under 4G mmio range instead of above 4G mmio range if the requested
  range is not big enough, even it could handle above 4G 64bit pref mmio.
 
  For root bus, we can order list from high to low in 
  pci_add_resource_offset(),
  during creating root bus, it will still keep the same order in final bus
  resource list.
  pci_acpi_scan_root
  == add_resources
  == pci_add_resource_offset: # Add to temp resources
  == pci_create_root_bus
  == pci_bus_add_resource # add to final bus 
  resources.
 
  After that, we can make sure 64bit pref mmio for pci bridges will be 
  allocated
  higest of mmio non-pref, and in this case it is above 4G instead of under 
  4G.
 
 Sorry I'm so slow; I'd like to know what problem this solves, too.
 I'm trying to help people at distros figure out whether they will need
 to backport this change.

This series was originally instigated during my attempt to get a PCI
Radeon 5450 graphics card with a 32-bit PLX bridge working in a
(hot-plugable) docking station on a system which had insufficient free
resources below 4G.  The biggest PCI address space user in my case was
the integrated i965 graphics, which I wanted to also be working for my
use case.  Allowing the IGP to be mapped above 4G freed enough resources
to make my system work, and it's now been running this way for the last
couple of years. (I've been rebasing the series in my local kernel.)

I'm pretty sure there are other cases, particularly where hotplug is
required where maximising free PCI address space 4G is extremely
useful; and it's to my mind a generally a good principle to allocate
resources such that limited resources (large aligned ranges) are
preserved for allocations which *require* them.  Is this really any
different than ZONE_DMA?

--
To unsubscribe from this list: send the line unsubscribe linux-kernel in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Re: [PATCH] staging: Merge Crystal HD driver with linuxtv.org

[Steven Newbury]

On Tue, 2013-10-29 at 12:54 +, Steven Newbury wrote:
> Hi Greg,
> I'm making good progress.  My plan is to break/clean up the patch
> logically:
> 
> patch1: Clean up debug/error messages  DONE - (this has actually
> resulted in some bug fixes)
> 
<- patch1b: Clean up typedefs (missed this in my list, but it's what I'm
working on right now) WIP

> patch2: Remove commented out/unused code  TODO
> 
> patch3: Power management support  TODO
> 
> patch4: other misc fixes/changes (may be more than one patch) with
> details in log message
> 
> patch5: Rename driver to crystalhd (instead of bcm70012) DONE
> 
> patch6: Restructure driver to prepare for BCM70015 support by splitting
> out (BCM70012) hw specific parts.  DONE
> 
> patch7: Add BCM70015 support  MOSTLY DONE - some clean up needed
> 
> 
> To me this makes more sense than trying to apply the patches as applied
> to the linuxtv.org git repo since there's a lot of irrelevant code churn
> and changes in commits which are undocumented in the log message along
> with the fact they won't apply cleanly on top of the existing staging
> driver anyway.



--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Re: [PATCH] staging: Merge Crystal HD driver with linuxtv.org

[Steven Newbury]

Hi Greg,
I'm making good progress.  My plan is to break/clean up the patch
logically:

patch1: Clean up debug/error messages  DONE - (this has actually
resulted in some bug fixes)

patch2: Remove commented out/unused code  TODO

patch3: Power management support  TODO

patch4: other misc fixes/changes (may be more than one patch) with
details in log message

patch5: Rename driver to crystalhd (instead of bcm70012) DONE

patch6: Restructure driver to prepare for BCM70015 support by splitting
out (BCM70012) hw specific parts.  DONE

patch7: Add BCM70015 support  MOSTLY DONE - some clean up needed


To me this makes more sense than trying to apply the patches as applied
to the linuxtv.org git repo since there's a lot of irrelevant code churn
and changes in commits which are undocumented in the log message along
with the fact they won't apply cleanly on top of the existing staging
driver anyway.

--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Re: [PATCH] staging: Merge Crystal HD driver with linuxtv.org

[Steven Newbury]

Hi Greg,
I'm making good progress.  My plan is to break/clean up the patch
logically:

patch1: Clean up debug/error messages  DONE - (this has actually
resulted in some bug fixes)

patch2: Remove commented out/unused code  TODO

patch3: Power management support  TODO

patch4: other misc fixes/changes (may be more than one patch) with
details in log message

patch5: Rename driver to crystalhd (instead of bcm70012) DONE

patch6: Restructure driver to prepare for BCM70015 support by splitting
out (BCM70012) hw specific parts.  DONE

patch7: Add BCM70015 support  MOSTLY DONE - some clean up needed


To me this makes more sense than trying to apply the patches as applied
to the linuxtv.org git repo since there's a lot of irrelevant code churn
and changes in commits which are undocumented in the log message along
with the fact they won't apply cleanly on top of the existing staging
driver anyway.

--
To unsubscribe from this list: send the line unsubscribe linux-kernel in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Re: [PATCH] staging: Merge Crystal HD driver with linuxtv.org

[Steven Newbury]

On Tue, 2013-10-29 at 12:54 +, Steven Newbury wrote:
 Hi Greg,
 I'm making good progress.  My plan is to break/clean up the patch
 logically:
 
 patch1: Clean up debug/error messages  DONE - (this has actually
 resulted in some bug fixes)
 
- patch1b: Clean up typedefs (missed this in my list, but it's what I'm
working on right now) WIP

 patch2: Remove commented out/unused code  TODO
 
 patch3: Power management support  TODO
 
 patch4: other misc fixes/changes (may be more than one patch) with
 details in log message
 
 patch5: Rename driver to crystalhd (instead of bcm70012) DONE
 
 patch6: Restructure driver to prepare for BCM70015 support by splitting
 out (BCM70012) hw specific parts.  DONE
 
 patch7: Add BCM70015 support  MOSTLY DONE - some clean up needed
 
 
 To me this makes more sense than trying to apply the patches as applied
 to the linuxtv.org git repo since there's a lot of irrelevant code churn
 and changes in commits which are undocumented in the log message along
 with the fact they won't apply cleanly on top of the existing staging
 driver anyway.



--
To unsubscribe from this list: send the line unsubscribe linux-kernel in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Re: [PATCH] staging: Merge Crystal HD driver with linuxtv.org

[Steven Newbury]

On Sun, 2013-10-27 at 09:26 -0700, Greg KH wrote:
> On Sun, Oct 27, 2013 at 05:12:18PM +0000, Steven Newbury wrote:
> > > And these patches do a lot of new work to the driver, I'd rather see it
> > > get fixed up properly and moved out of staging first, before adding new
> > > support to it, otherwise why is it in staging at all?
> > 
> > That last part it a good question, it's been sitting there for 3 years,
> > I assume there are specific things that need improving to get it out of
> > staging?  Would the changes in this patch, without the support for new
> > hw support be sufficient to get that to happen?  I can't test it without
> > that support though...
> 
> See the TODO file for a list of things that need to be resolved.


> - Testing
I can do this for BCM70015 only, hopefully somebody else can test with other
hardware.

> - Cleanup return codes
Specifics?

> - Cleanup typedefs
For the existing staging driver, this one appears done to me.  For the new
code, I notice I've allowed a few to slip back in, I'll fix this.

> - Allocate an Accelerator device class specific Major number,
>   since we don't have any other open sourced accelerators, it is the only
>   one in that category for now.
>   A somewhat similar device is the DXR2/3
Is there a reason this hasn't happened?  (staging drivers don't get new major
numbers allocated?) Did nobody actually request a new class, or has there 
been no agreement on how to proceed?


> 
> I've been remiss in deleting some of the staging drivers lately, and
> this one was on my shortlist for removal, but if you have hardware for
> it, and want to adopt it, I'll gladly take the patches for getting your
> stuff to work if you are going to work toward getting it out of staging.
> 
I'll get it fixed up, I've an incentive to keep it working to keep my
wife happy! ;-) (It enables the network media box in our bedroom to work
with HD content without the fan screaming!)


--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Re: [PATCH] staging: Merge Crystal HD driver with linuxtv.org

[Steven Newbury]

On Sun, 2013-10-27 at 08:54 -0700, Greg KH wrote:
> On Sun, Oct 27, 2013 at 04:27:23PM +0000, Steven Newbury wrote:
> > The in-kernel staging version and upstream diverged in Jan 2010,
> > whilst the in-kernel version has been kept up to date with kernel
> > changes, both have recieved some clean ups and bug fixes, upstream
> > has also added support for new cards, particularly BCM70015 which
> > is now a much more common device than the original BCM70012 and
> > is currently available for purchase.
> > 
> > In addition to the changes below, I've applied all the relevant
> > modifications applied to the in-kernel version to the new code
> > introduced from upstream, in particular the removal of typedefs and
> > unified header handling.
> > 
> > Quite a lot of the code churn relates to upstream commit
> > 317dbd6dda65b4177627d6417b762c287cefa0e7 (crystalhd: nuke BCMLOG
> > macros, use std dev_foo ones), I considered stripping these changes
> > out and making them a separate patch but decided to stay as close as
> > possible to the state of the current linuxtv.org codebase.
> > 
> > Unfortunately, AFAIK, it's not possible to simply merge the upstream
> > git history since the upstream code isn't in a kernel tree structure,
> > and isn't even in a simple directory, but includes a script to
> > convert the external module into a staging tree driver which I used
> > to create a reference tree.  I had to then manually merge both
> > versions and fix code conflicts.
> > 
> > It does now successfully detect and initialise a BCM70015 bought
> > last week from Amazon.  It is currently untested on the original
> > BCM70012.
> > 
> > Signed-off-by: Steven Newbury 
> 
> Any reason why you didn't send this to me, the staging tree maintainer?
> 
My apologies, that was remiss of me.
> And I can't take a giant patch like this, it's a mess.  Why not send me
> a series of patches that sync things up, like you detail in the odd
> changelog entries you show below?
TBH, I just hoped I'd get away with fixing the thing up and posting it.
I bought the hardware last week assuming it would work since the driver
has been hanging around in the kernel for years, only to realise that
there is *no* working driver for the current cards on the market, at
least with recent kernel releases.  (The linuxtv.org driver seems to
have stopped being updated.) 

So I spent the weekend getting it working for me, and rather than leave
it sitting in my local machine with far too many other patches for way
too many projects, I sent it here. :-)  

But, you're right, I've only done half the job, and I knew it as I wrote
the email. :-/  I'll start breaking it up into separate patches.

> 
> And these patches do a lot of new work to the driver, I'd rather see it
> get fixed up properly and moved out of staging first, before adding new
> support to it, otherwise why is it in staging at all?

That last part it a good question, it's been sitting there for 3 years,
I assume there are specific things that need improving to get it out of
staging?  Would the changes in this patch, without the support for new
hw support be sufficient to get that to happen?  I can't test it without
that support though...




--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Re: [PATCH] staging: Merge Crystal HD driver with linuxtv.org

[Steven Newbury]

On Sun, 2013-10-27 at 08:54 -0700, Greg KH wrote:
 On Sun, Oct 27, 2013 at 04:27:23PM +, Steven Newbury wrote:
  The in-kernel staging version and upstream diverged in Jan 2010,
  whilst the in-kernel version has been kept up to date with kernel
  changes, both have recieved some clean ups and bug fixes, upstream
  has also added support for new cards, particularly BCM70015 which
  is now a much more common device than the original BCM70012 and
  is currently available for purchase.
  
  In addition to the changes below, I've applied all the relevant
  modifications applied to the in-kernel version to the new code
  introduced from upstream, in particular the removal of typedefs and
  unified header handling.
  
  Quite a lot of the code churn relates to upstream commit
  317dbd6dda65b4177627d6417b762c287cefa0e7 (crystalhd: nuke BCMLOG
  macros, use std dev_foo ones), I considered stripping these changes
  out and making them a separate patch but decided to stay as close as
  possible to the state of the current linuxtv.org codebase.
  
  Unfortunately, AFAIK, it's not possible to simply merge the upstream
  git history since the upstream code isn't in a kernel tree structure,
  and isn't even in a simple directory, but includes a script to
  convert the external module into a staging tree driver which I used
  to create a reference tree.  I had to then manually merge both
  versions and fix code conflicts.
  
  It does now successfully detect and initialise a BCM70015 bought
  last week from Amazon.  It is currently untested on the original
  BCM70012.
  
  Signed-off-by: Steven Newbury st...@snewbury.org.uk
 
 Any reason why you didn't send this to me, the staging tree maintainer?
 
My apologies, that was remiss of me.
 And I can't take a giant patch like this, it's a mess.  Why not send me
 a series of patches that sync things up, like you detail in the odd
 changelog entries you show below?
TBH, I just hoped I'd get away with fixing the thing up and posting it.
I bought the hardware last week assuming it would work since the driver
has been hanging around in the kernel for years, only to realise that
there is *no* working driver for the current cards on the market, at
least with recent kernel releases.  (The linuxtv.org driver seems to
have stopped being updated.) 

So I spent the weekend getting it working for me, and rather than leave
it sitting in my local machine with far too many other patches for way
too many projects, I sent it here. :-)  

But, you're right, I've only done half the job, and I knew it as I wrote
the email. :-/  I'll start breaking it up into separate patches.

 
 And these patches do a lot of new work to the driver, I'd rather see it
 get fixed up properly and moved out of staging first, before adding new
 support to it, otherwise why is it in staging at all?

That last part it a good question, it's been sitting there for 3 years,
I assume there are specific things that need improving to get it out of
staging?  Would the changes in this patch, without the support for new
hw support be sufficient to get that to happen?  I can't test it without
that support though...




--
To unsubscribe from this list: send the line unsubscribe linux-kernel in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Re: [PATCH] staging: Merge Crystal HD driver with linuxtv.org

[Steven Newbury]

On Sun, 2013-10-27 at 09:26 -0700, Greg KH wrote:
 On Sun, Oct 27, 2013 at 05:12:18PM +, Steven Newbury wrote:
   And these patches do a lot of new work to the driver, I'd rather see it
   get fixed up properly and moved out of staging first, before adding new
   support to it, otherwise why is it in staging at all?
  
  That last part it a good question, it's been sitting there for 3 years,
  I assume there are specific things that need improving to get it out of
  staging?  Would the changes in this patch, without the support for new
  hw support be sufficient to get that to happen?  I can't test it without
  that support though...
 
 See the TODO file for a list of things that need to be resolved.


 - Testing
I can do this for BCM70015 only, hopefully somebody else can test with other
hardware.

 - Cleanup return codes
Specifics?

 - Cleanup typedefs
For the existing staging driver, this one appears done to me.  For the new
code, I notice I've allowed a few to slip back in, I'll fix this.

 - Allocate an Accelerator device class specific Major number,
   since we don't have any other open sourced accelerators, it is the only
   one in that category for now.
   A somewhat similar device is the DXR2/3
Is there a reason this hasn't happened?  (staging drivers don't get new major
numbers allocated?) Did nobody actually request a new class, or has there 
been no agreement on how to proceed?


 
 I've been remiss in deleting some of the staging drivers lately, and
 this one was on my shortlist for removal, but if you have hardware for
 it, and want to adopt it, I'll gladly take the patches for getting your
 stuff to work if you are going to work toward getting it out of staging.
 
I'll get it fixed up, I've an incentive to keep it working to keep my
wife happy! ;-) (It enables the network media box in our bedroom to work
with HD content without the fan screaming!)


--
To unsubscribe from this list: send the line unsubscribe linux-kernel in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Re: Linux 3.11-rc2 (acpi backlight, revert)

[Steven Newbury]

On Thu, 2013-07-25 at 15:00 +0200, Rafael J. Wysocki wrote:
> On Monday, July 22, 2013 09:54:21 PM Rafael J. Wysocki wrote:
> > On Monday, July 22, 2013 11:11:54 AM Linus Torvalds wrote:
> > > On Mon, Jul 22, 2013 at 6:02 AM, Rafael J. Wysocki  wrote:
> > > >
> > > > Linus, do you want me to send a pull request reverting 8c5bd7a and 
> > > > efaa14c?
> > > 
> > > Yes, but let's wait a while. Not because I think we'll fix the problem
> > > (hey, miracles might happen), but because I think it would be useful
> > > to couple the reverts with information about the particular machines
> > > that broke (and the people who reported it). So that when we
> > > inevitably try again, we can perhaps get some testing effort with
> > > those machines/people.
> > > 
> > > It doesn't seem to be a show-stopped for a large number of people, so
> > > there's no huge hurry. I'd suggest doing the revert just in time for
> > > rc3, but waiting until then to gather info about people who see
> > > breakage.
> > > 
> > > Sound like a plan?
> > 
> > Yes, it does.
> 
> OK, time to revert I guess.
> 
> James, Kamal, Steven, Jörg, Martin, Kalle, please check if the apppended patch
> fixes the backlight for you.
> 
> Aaron, please double check if acpi_video_backlight_quirks() will still work as
> needed.
> 
> Thanks,
> Rafael
> 
> 
> ---
> From: Rafael J. Wysocki 
> Subject: Revert "ACPI / video / i915: No ACPI backlight if firmware expects 
> Windows 8"
> 
> We attempted to address a regression introduced by commit a57f7f9
> (ACPICA: Add Windows8/Server2012 string for _OSI method.) after which
> ACPI video backlight support doesn't work on a number of systems,
> because the relevant AML methods in the ACPI tables in their BIOSes
> become useless after the BIOS has been told that the OS is compatible
> with Windows 8.  That problem is tracked by the bug entry at:
> 
> https://bugzilla.kernel.org/show_bug.cgi?id=51231
> 
> Commit 8c5bd7a (ACPI / video / i915: No ACPI backlight if firmware
> expects Windows 8) introduced for this purpose essentially prevented
> the ACPI backlight support from being used if the BIOS had been told
> that the OS was compatible with Windows 8 and the i915 driver was
> loaded, in which case the backlight would always be handled by i915.
> Unfortunately, however, that turned out to cause problems with
> backlight to appear on multiple systems with symptoms indicating that
> i915 was unable to control the backlight on those systems as
> expected.
> 
> For this reason, revert commit 8c5bd7a, but leave the function
> acpi_video_backlight_quirks() introduced by it, because another
> commit on top of it uses that function.
> 
Works fine for me.

Tested-by: Steven Newbury 

By the way, I'm willing to test any i915 backlight patches if it helps.

--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Re: Linux 3.11-rc2 (acpi backlight, revert)

[Steven Newbury]

On Thu, 2013-07-25 at 15:00 +0200, Rafael J. Wysocki wrote:
 On Monday, July 22, 2013 09:54:21 PM Rafael J. Wysocki wrote:
  On Monday, July 22, 2013 11:11:54 AM Linus Torvalds wrote:
   On Mon, Jul 22, 2013 at 6:02 AM, Rafael J. Wysocki r...@sisk.pl wrote:
   
Linus, do you want me to send a pull request reverting 8c5bd7a and 
efaa14c?
   
   Yes, but let's wait a while. Not because I think we'll fix the problem
   (hey, miracles might happen), but because I think it would be useful
   to couple the reverts with information about the particular machines
   that broke (and the people who reported it). So that when we
   inevitably try again, we can perhaps get some testing effort with
   those machines/people.
   
   It doesn't seem to be a show-stopped for a large number of people, so
   there's no huge hurry. I'd suggest doing the revert just in time for
   rc3, but waiting until then to gather info about people who see
   breakage.
   
   Sound like a plan?
  
  Yes, it does.
 
 OK, time to revert I guess.
 
 James, Kamal, Steven, Jörg, Martin, Kalle, please check if the apppended patch
 fixes the backlight for you.
 
 Aaron, please double check if acpi_video_backlight_quirks() will still work as
 needed.
 
 Thanks,
 Rafael
 
 
 ---
 From: Rafael J. Wysocki rafael.j.wyso...@intel.com
 Subject: Revert ACPI / video / i915: No ACPI backlight if firmware expects 
 Windows 8
 
 We attempted to address a regression introduced by commit a57f7f9
 (ACPICA: Add Windows8/Server2012 string for _OSI method.) after which
 ACPI video backlight support doesn't work on a number of systems,
 because the relevant AML methods in the ACPI tables in their BIOSes
 become useless after the BIOS has been told that the OS is compatible
 with Windows 8.  That problem is tracked by the bug entry at:
 
 https://bugzilla.kernel.org/show_bug.cgi?id=51231
 
 Commit 8c5bd7a (ACPI / video / i915: No ACPI backlight if firmware
 expects Windows 8) introduced for this purpose essentially prevented
 the ACPI backlight support from being used if the BIOS had been told
 that the OS was compatible with Windows 8 and the i915 driver was
 loaded, in which case the backlight would always be handled by i915.
 Unfortunately, however, that turned out to cause problems with
 backlight to appear on multiple systems with symptoms indicating that
 i915 was unable to control the backlight on those systems as
 expected.
 
 For this reason, revert commit 8c5bd7a, but leave the function
 acpi_video_backlight_quirks() introduced by it, because another
 commit on top of it uses that function.
 
Works fine for me.

Tested-by: Steven Newbury st...@snewbury.org.uk

By the way, I'm willing to test any i915 backlight patches if it helps.

--
To unsubscribe from this list: send the line unsubscribe linux-kernel in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Re: Linux 3.11-rc2 (acpi backlight)

[Steven Newbury]

On Wed, 2013-07-24 at 02:05 +0200, Rafael J. Wysocki wrote:
> On Tuesday, July 23, 2013 11:46:29 AM Kamal Mostafa wrote:
> > On Mon, 2013-07-22 at 21:54 +0200, Rafael J. Wysocki wrote:
> > > On Monday, July 22, 2013 11:11:54 AM Linus Torvalds wrote:
> > > > On Mon, Jul 22, 2013 at 6:02 AM, Rafael J. Wysocki  wrote:
> > > > >
> > > > > Linus, do you want me to send a pull request reverting 8c5bd7a and 
> > > > > efaa14c?
> > > > 
> > > > Yes, but [...] I'd suggest doing the revert just in time for
> > > > rc3, but waiting until then to gather info about people who see
> > > > breakage.
> > > > 
> > > > Sound like a plan?
> > > 
> > > Yes, it does.
> > > 
> > > Rafael
> > 
> > 
> > Hi Rafael-
> > 
> > For your reference...
> > 
> > As James Hogan reported, those ACPI changes break backlight control on
> > the "Dell XPS13" Ivy Bridge models (the Sandy Bridge XPS13 model is not
> > affected).
> > 
> > I confirm that reverting 8c5bd7a and efaa14c fixes it again.
> 
> Thanks!
> 
> I'd like to collect some information on the systems having problems with those
> two commits (to see if they are similar somehow).
> 
> It seems that one common symptom is that brightness cannot be controlled
> through function keys.  Is that correct for all of you?  If so, did you try
> any other way to control brightness, like a GUI-based?
> 
> Also, can you all please send me (a) the output of dmidecode and (b) the
> contents of /proc/cpuinfo from your systems?
> 
> Rafael
> 
> 

Attached.

processor   : 0
vendor_id   : GenuineIntel
cpu family  : 6
model   : 58
model name  : Intel(R) Core(TM) i7-3840QM CPU @ 2.80GHz
stepping: 9
microcode   : 0x15
cpu MHz : 2212.000
cache size  : 8192 KB
physical id : 0
siblings: 8
core id : 0
cpu cores   : 4
apicid  : 0
initial apicid  : 0
fpu : yes
fpu_exception   : yes
cpuid level : 13
wp  : yes
flags   : fpu vme de pse tsc msr pae mce cx8 apic sep mtrr pge mca cmov 
pat pse36 clflush dts acpi mmx fxsr sse sse2 ss ht tm pbe syscall nx rdtscp lm 
constant_tsc arch_perfmon pebs bts rep_good nopl xtopology nonstop_tsc 
aperfmperf eagerfpu pni pclmulqdq dtes64 monitor ds_cpl vmx smx est tm2 ssse3 
cx16 xtpr pdcm pcid sse4_1 sse4_2 x2apic popcnt tsc_deadline_timer aes xsave 
avx f16c rdrand lahf_lm ida arat epb xsaveopt pln pts dtherm tpr_shadow vnmi 
flexpriority ept vpid fsgsbase smep erms
bogomips: 5587.12
clflush size: 64
cache_alignment : 64
address sizes   : 36 bits physical, 48 bits virtual
power management:

processor   : 1
vendor_id   : GenuineIntel
cpu family  : 6
model   : 58
model name  : Intel(R) Core(TM) i7-3840QM CPU @ 2.80GHz
stepping: 9
microcode   : 0x15
cpu MHz : 1960.000
cache size  : 8192 KB
physical id : 0
siblings: 8
core id : 1
cpu cores   : 4
apicid  : 2
initial apicid  : 2
fpu : yes
fpu_exception   : yes
cpuid level : 13
wp  : yes
flags   : fpu vme de pse tsc msr pae mce cx8 apic sep mtrr pge mca cmov 
pat pse36 clflush dts acpi mmx fxsr sse sse2 ss ht tm pbe syscall nx rdtscp lm 
constant_tsc arch_perfmon pebs bts rep_good nopl xtopology nonstop_tsc 
aperfmperf eagerfpu pni pclmulqdq dtes64 monitor ds_cpl vmx smx est tm2 ssse3 
cx16 xtpr pdcm pcid sse4_1 sse4_2 x2apic popcnt tsc_deadline_timer aes xsave 
avx f16c rdrand lahf_lm ida arat epb xsaveopt pln pts dtherm tpr_shadow vnmi 
flexpriority ept vpid fsgsbase smep erms
bogomips: 5587.12
clflush size: 64
cache_alignment : 64
address sizes   : 36 bits physical, 48 bits virtual
power management:

processor   : 2
vendor_id   : GenuineIntel
cpu family  : 6
model   : 58
model name  : Intel(R) Core(TM) i7-3840QM CPU @ 2.80GHz
stepping: 9
microcode   : 0x15
cpu MHz : 2716.000
cache size  : 8192 KB
physical id : 0
siblings: 8
core id : 2
cpu cores   : 4
apicid  : 4
initial apicid  : 4
fpu : yes
fpu_exception   : yes
cpuid level : 13
wp  : yes
flags   : fpu vme de pse tsc msr pae mce cx8 apic sep mtrr pge mca cmov 
pat pse36 clflush dts acpi mmx fxsr sse sse2 ss ht tm pbe syscall nx rdtscp lm 
constant_tsc arch_perfmon pebs bts rep_good nopl xtopology nonstop_tsc 
aperfmperf eagerfpu pni pclmulqdq dtes64 monitor ds_cpl vmx smx est tm2 ssse3 
cx16 xtpr pdcm pcid sse4_1 sse4_2 x2apic popcnt tsc_deadline_timer aes xsave 
avx f16c rdrand lahf_lm ida arat epb xsaveopt pln pts dtherm tpr_shadow vnmi 
flexpriority ept vpid fsgsbase smep erms
bogomips: 5587.12
clflush size: 64
cache_alignment : 64
address sizes   : 36 bits physical, 48 bits virtual
power management:

processor   : 3
vendor_id   : GenuineIntel
cpu family  : 6
model   : 58
model name  : Intel(R) Core(TM) i7-3840QM CPU @ 2.80GHz
stepping: 9
microcode   : 0x15
cpu 

Re: Linux 3.11-rc2

[Steven Newbury]

On Tue, 2013-07-23 at 23:24 +0200, Rafael J. Wysocki wrote:
> On Tuesday, July 23, 2013 06:47:55 PM Steven Newbury wrote:
> > On Mon, 2013-07-22 at 21:56 +0200, Rafael J. Wysocki wrote:
> > > On Monday, July 22, 2013 06:16:20 PM Matthew Garrett wrote:
> > > > On Mon, 2013-07-22 at 15:02 +0200, Rafael J. Wysocki wrote:
> > > > 
> > > > > In the meantime I received a report from Steven Newbury that these 
> > > > > changes
> > > > > broke things for him too, so we need to revert commits 8c5bd7a and 
> > > > > efaa14c.
> > > > > The other two commits in the series should be benign.
> > > > 
> > > > Could you let me know the details of this problem?
> > > 
> > > Steven, can you please describe the problem you're seeing to Matthew and
> > > the other people on the list?
> > > 
> > > Rafael
> > > 
> > 
> > Before the changes backlight was working fine using the ACPI method: 
> > /sys/class/backlight/acpi_video0/ is present and the keyboard function keys
> > control brightness with notifications working in GNOME.
> > 
> > In the code as was present in the linux-pm/bleeding-edge tree I would
> > encounter a hard lockup on keyboard brightness trigger.  This also occurred 
> > with
> > the code as it initially hit mainline, but a later commit fixed the crash*, 
> > but
> > resulted in no backlight controls being available at all.
> > /sys/class/backlight  is empty.
> > 
> > *not actually sure if /sys/class/backlight contained anything before this
> 
> Hmm.  Which commit fixed the crash for you?
> 
> Rafael
> 

I'll see if I can build a broken kernel tomorrow, after backing up! ;-)

--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Re: Linux 3.11-rc2

[Steven Newbury]

On Tue, 2013-07-23 at 19:51 +, Matthew Garrett wrote:
> On Tue, 2013-07-23 at 18:47 +0100, Steven Newbury wrote:
> 
> > In the code as was present in the linux-pm/bleeding-edge tree I would
> > encounter a hard lockup on keyboard brightness trigger.  This also occurred 
> > with
> > the code as it initially hit mainline, but a later commit fixed the crash*, 
> > but
> > resulted in no backlight controls being available at all.
> > /sys/class/backlight  is empty.
> 
> This is an Intel system using the i915 driver?
> 

Yes, IVB i7-3840QM.  CLEVO W270EUQ.

--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Re: Linux 3.11-rc2

[Steven Newbury]

On Mon, 2013-07-22 at 21:56 +0200, Rafael J. Wysocki wrote:
> On Monday, July 22, 2013 06:16:20 PM Matthew Garrett wrote:
> > On Mon, 2013-07-22 at 15:02 +0200, Rafael J. Wysocki wrote:
> > 
> > > In the meantime I received a report from Steven Newbury that these changes
> > > broke things for him too, so we need to revert commits 8c5bd7a and 
> > > efaa14c.
> > > The other two commits in the series should be benign.
> > 
> > Could you let me know the details of this problem?
> 
> Steven, can you please describe the problem you're seeing to Matthew and
> the other people on the list?
> 
> Rafael
> 

Before the changes backlight was working fine using the ACPI method: 
/sys/class/backlight/acpi_video0/ is present and the keyboard function keys
control brightness with notifications working in GNOME.

In the code as was present in the linux-pm/bleeding-edge tree I would
encounter a hard lockup on keyboard brightness trigger.  This also occurred with
the code as it initially hit mainline, but a later commit fixed the crash*, but
resulted in no backlight controls being available at all.
/sys/class/backlight  is empty.

*not actually sure if /sys/class/backlight contained anything before this


--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Re: Linux 3.11-rc2

[Steven Newbury]

On Mon, 2013-07-22 at 21:56 +0200, Rafael J. Wysocki wrote:
 On Monday, July 22, 2013 06:16:20 PM Matthew Garrett wrote:
  On Mon, 2013-07-22 at 15:02 +0200, Rafael J. Wysocki wrote:
  
   In the meantime I received a report from Steven Newbury that these changes
   broke things for him too, so we need to revert commits 8c5bd7a and 
   efaa14c.
   The other two commits in the series should be benign.
  
  Could you let me know the details of this problem?
 
 Steven, can you please describe the problem you're seeing to Matthew and
 the other people on the list?
 
 Rafael
 

Before the changes backlight was working fine using the ACPI method: 
/sys/class/backlight/acpi_video0/ is present and the keyboard function keys
control brightness with notifications working in GNOME.

In the code as was present in the linux-pm/bleeding-edge tree I would
encounter a hard lockup on keyboard brightness trigger.  This also occurred with
the code as it initially hit mainline, but a later commit fixed the crash*, but
resulted in no backlight controls being available at all.
/sys/class/backlight  is empty.

*not actually sure if /sys/class/backlight contained anything before this


--
To unsubscribe from this list: send the line unsubscribe linux-kernel in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Re: Linux 3.11-rc2

[Steven Newbury]

On Tue, 2013-07-23 at 19:51 +, Matthew Garrett wrote:
 On Tue, 2013-07-23 at 18:47 +0100, Steven Newbury wrote:
 
  In the code as was present in the linux-pm/bleeding-edge tree I would
  encounter a hard lockup on keyboard brightness trigger.  This also occurred 
  with
  the code as it initially hit mainline, but a later commit fixed the crash*, 
  but
  resulted in no backlight controls being available at all.
  /sys/class/backlight  is empty.
 
 This is an Intel system using the i915 driver?
 

Yes, IVB i7-3840QM.  CLEVO W270EUQ.

--
To unsubscribe from this list: send the line unsubscribe linux-kernel in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Re: Linux 3.11-rc2

[Steven Newbury]

On Tue, 2013-07-23 at 23:24 +0200, Rafael J. Wysocki wrote:
 On Tuesday, July 23, 2013 06:47:55 PM Steven Newbury wrote:
  On Mon, 2013-07-22 at 21:56 +0200, Rafael J. Wysocki wrote:
   On Monday, July 22, 2013 06:16:20 PM Matthew Garrett wrote:
On Mon, 2013-07-22 at 15:02 +0200, Rafael J. Wysocki wrote:

 In the meantime I received a report from Steven Newbury that these 
 changes
 broke things for him too, so we need to revert commits 8c5bd7a and 
 efaa14c.
 The other two commits in the series should be benign.

Could you let me know the details of this problem?
   
   Steven, can you please describe the problem you're seeing to Matthew and
   the other people on the list?
   
   Rafael
   
  
  Before the changes backlight was working fine using the ACPI method: 
  /sys/class/backlight/acpi_video0/ is present and the keyboard function keys
  control brightness with notifications working in GNOME.
  
  In the code as was present in the linux-pm/bleeding-edge tree I would
  encounter a hard lockup on keyboard brightness trigger.  This also occurred 
  with
  the code as it initially hit mainline, but a later commit fixed the crash*, 
  but
  resulted in no backlight controls being available at all.
  /sys/class/backlight  is empty.
  
  *not actually sure if /sys/class/backlight contained anything before this
 
 Hmm.  Which commit fixed the crash for you?
 
 Rafael
 

I'll see if I can build a broken kernel tomorrow, after backing up! ;-)

--
To unsubscribe from this list: send the line unsubscribe linux-kernel in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Re: Linux 3.11-rc2 (acpi backlight)

[Steven Newbury]

On Wed, 2013-07-24 at 02:05 +0200, Rafael J. Wysocki wrote:
 On Tuesday, July 23, 2013 11:46:29 AM Kamal Mostafa wrote:
  On Mon, 2013-07-22 at 21:54 +0200, Rafael J. Wysocki wrote:
   On Monday, July 22, 2013 11:11:54 AM Linus Torvalds wrote:
On Mon, Jul 22, 2013 at 6:02 AM, Rafael J. Wysocki r...@sisk.pl wrote:

 Linus, do you want me to send a pull request reverting 8c5bd7a and 
 efaa14c?

Yes, but [...] I'd suggest doing the revert just in time for
rc3, but waiting until then to gather info about people who see
breakage.

Sound like a plan?
   
   Yes, it does.
   
   Rafael
  
  
  Hi Rafael-
  
  For your reference...
  
  As James Hogan reported, those ACPI changes break backlight control on
  the Dell XPS13 Ivy Bridge models (the Sandy Bridge XPS13 model is not
  affected).
  
  I confirm that reverting 8c5bd7a and efaa14c fixes it again.
 
 Thanks!
 
 I'd like to collect some information on the systems having problems with those
 two commits (to see if they are similar somehow).
 
 It seems that one common symptom is that brightness cannot be controlled
 through function keys.  Is that correct for all of you?  If so, did you try
 any other way to control brightness, like a GUI-based?
 
 Also, can you all please send me (a) the output of dmidecode and (b) the
 contents of /proc/cpuinfo from your systems?
 
 Rafael
 
 

Attached.

processor   : 0
vendor_id   : GenuineIntel
cpu family  : 6
model   : 58
model name  : Intel(R) Core(TM) i7-3840QM CPU @ 2.80GHz
stepping: 9
microcode   : 0x15
cpu MHz : 2212.000
cache size  : 8192 KB
physical id : 0
siblings: 8
core id : 0
cpu cores   : 4
apicid  : 0
initial apicid  : 0
fpu : yes
fpu_exception   : yes
cpuid level : 13
wp  : yes
flags   : fpu vme de pse tsc msr pae mce cx8 apic sep mtrr pge mca cmov 
pat pse36 clflush dts acpi mmx fxsr sse sse2 ss ht tm pbe syscall nx rdtscp lm 
constant_tsc arch_perfmon pebs bts rep_good nopl xtopology nonstop_tsc 
aperfmperf eagerfpu pni pclmulqdq dtes64 monitor ds_cpl vmx smx est tm2 ssse3 
cx16 xtpr pdcm pcid sse4_1 sse4_2 x2apic popcnt tsc_deadline_timer aes xsave 
avx f16c rdrand lahf_lm ida arat epb xsaveopt pln pts dtherm tpr_shadow vnmi 
flexpriority ept vpid fsgsbase smep erms
bogomips: 5587.12
clflush size: 64
cache_alignment : 64
address sizes   : 36 bits physical, 48 bits virtual
power management:

processor   : 1
vendor_id   : GenuineIntel
cpu family  : 6
model   : 58
model name  : Intel(R) Core(TM) i7-3840QM CPU @ 2.80GHz
stepping: 9
microcode   : 0x15
cpu MHz : 1960.000
cache size  : 8192 KB
physical id : 0
siblings: 8
core id : 1
cpu cores   : 4
apicid  : 2
initial apicid  : 2
fpu : yes
fpu_exception   : yes
cpuid level : 13
wp  : yes
flags   : fpu vme de pse tsc msr pae mce cx8 apic sep mtrr pge mca cmov 
pat pse36 clflush dts acpi mmx fxsr sse sse2 ss ht tm pbe syscall nx rdtscp lm 
constant_tsc arch_perfmon pebs bts rep_good nopl xtopology nonstop_tsc 
aperfmperf eagerfpu pni pclmulqdq dtes64 monitor ds_cpl vmx smx est tm2 ssse3 
cx16 xtpr pdcm pcid sse4_1 sse4_2 x2apic popcnt tsc_deadline_timer aes xsave 
avx f16c rdrand lahf_lm ida arat epb xsaveopt pln pts dtherm tpr_shadow vnmi 
flexpriority ept vpid fsgsbase smep erms
bogomips: 5587.12
clflush size: 64
cache_alignment : 64
address sizes   : 36 bits physical, 48 bits virtual
power management:

processor   : 2
vendor_id   : GenuineIntel
cpu family  : 6
model   : 58
model name  : Intel(R) Core(TM) i7-3840QM CPU @ 2.80GHz
stepping: 9
microcode   : 0x15
cpu MHz : 2716.000
cache size  : 8192 KB
physical id : 0
siblings: 8
core id : 2
cpu cores   : 4
apicid  : 4
initial apicid  : 4
fpu : yes
fpu_exception   : yes
cpuid level : 13
wp  : yes
flags   : fpu vme de pse tsc msr pae mce cx8 apic sep mtrr pge mca cmov 
pat pse36 clflush dts acpi mmx fxsr sse sse2 ss ht tm pbe syscall nx rdtscp lm 
constant_tsc arch_perfmon pebs bts rep_good nopl xtopology nonstop_tsc 
aperfmperf eagerfpu pni pclmulqdq dtes64 monitor ds_cpl vmx smx est tm2 ssse3 
cx16 xtpr pdcm pcid sse4_1 sse4_2 x2apic popcnt tsc_deadline_timer aes xsave 
avx f16c rdrand lahf_lm ida arat epb xsaveopt pln pts dtherm tpr_shadow vnmi 
flexpriority ept vpid fsgsbase smep erms
bogomips: 5587.12
clflush size: 64
cache_alignment : 64
address sizes   : 36 bits physical, 48 bits virtual
power management:

processor   : 3
vendor_id   : GenuineIntel
cpu family  : 6
model   : 58
model name  : Intel(R) Core(TM) i7-3840QM CPU @ 2.80GHz
stepping: 9
microcode   : 0x15
cpu MHz : 2072.000
cache size  : 8192 KB
physical id : 0
siblings: 8

Re: [PATCH 1/2] ACPI / scan: Make namespace scanning and trimming mutually exclusive

[Steven Newbury]

On Sat, 2013-02-02 at 23:27 +0100, Rafael J. Wysocki wrote:
> On Saturday, February 02, 2013 08:28:01 PM Steven Newbury wrote:
> > > > Tried merging with linux-pm/bleeding-edge, same behaviour:
> > > > 
> > > > [ 3589.013578] ACPI: \_SB_.PCI0.PCIE.GDCK: undocking
> > > > [ 3589.585356] vgaarb: device changed decodes:
> > > > PCI::00:02.0,olddecodes=none,decodes=io+mem:owns=none [
> > > > 3589.585422] ACPI: Delete PCI Interrupt Routing Table for :04 [
> > > > 3589.585426] pci :03:08.0: Oops, 'acpi_handle' corrupt [
> > > > 3589.585446] pci_bus :04: busn_res: [bus 04] is released
> > > > 
> > > > 03:08.0 PCI bridge: PLX Technology, Inc. PEX8112 x1 Lane PCI
> > > > Express-to-PCI Bridge (rev aa)
> > > > 04:00.0 VGA compatible controller: Advanced Micro Devices [AMD] nee ATI
> > > > Manhattan [Mobility Radeon HD 5430 Series]
> > > > 04:00.1 Audio device: Advanced Micro Devices [AMD] nee ATI Cedar HDMI
> > > > Audio [Radeon HD 5400/6300 Series]
> > > 
> > > That's because of a bug in the dock code I believe.
> > > 
> > > If you're willing to test patches, I can try to cook up something to
> > > debug/fix this.
> > Sure, I'm always willing to test patches.
> 
> Can you please test this one in addition to the $subject one:
> 
> https://patchwork.kernel.org/patch/2068621/
> 
> and see if that helps?
No change wrt the "Oops, 'acpi_handle' corrupt".

Just to be clear, this happens during the logical undock phase after
writing to "/sys/devices/platform/dock.0/undock".

Right now I manually tear down the seat associated with the dock gfx
card (waiting for the X server to terminate and requiring SIGSTOPing the
gdm process to stop it respawning!) then attempt radeon module unload,
if it succeeds I write to the undock file, otherwise I fail the undock;
I saw there is intention to put it infrastructure to have drivers
prepare themselves for removal on 'eject' request, that would be really
helpful.

A couple of other things regarding the dock system:

Making an undock/eject request with the dock eject button results in an
ACPI 'undock' event, same ACPI event happens when the
electrical/physical undock occurs.

The IDE docks seem not to be working; maybe I need to turn on some
debugging.  This used to work at some point.

Feb  2 23:51:28 infinity kernel: ACPI: \_SB_.PCI0.IDE1.PRI_.MAST:
docking
Feb  2 23:51:28 infinity kernel: ACPI: \_SB_.PCI0.IDE1.PRI_.MAST: Unable
to dock!


--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Re: [PATCH 1/2] ACPI / scan: Make namespace scanning and trimming mutually exclusive

[Steven Newbury]

On Sat, 2013-02-02 at 23:27 +0100, Rafael J. Wysocki wrote:
 On Saturday, February 02, 2013 08:28:01 PM Steven Newbury wrote:
Tried merging with linux-pm/bleeding-edge, same behaviour:

[ 3589.013578] ACPI: \_SB_.PCI0.PCIE.GDCK: undocking
[ 3589.585356] vgaarb: device changed decodes:
PCI::00:02.0,olddecodes=none,decodes=io+mem:owns=none [
3589.585422] ACPI: Delete PCI Interrupt Routing Table for :04 [
3589.585426] pci :03:08.0: Oops, 'acpi_handle' corrupt [
3589.585446] pci_bus :04: busn_res: [bus 04] is released

03:08.0 PCI bridge: PLX Technology, Inc. PEX8112 x1 Lane PCI
Express-to-PCI Bridge (rev aa)
04:00.0 VGA compatible controller: Advanced Micro Devices [AMD] nee ATI
Manhattan [Mobility Radeon HD 5430 Series]
04:00.1 Audio device: Advanced Micro Devices [AMD] nee ATI Cedar HDMI
Audio [Radeon HD 5400/6300 Series]
   
   That's because of a bug in the dock code I believe.
   
   If you're willing to test patches, I can try to cook up something to
   debug/fix this.
  Sure, I'm always willing to test patches.
 
 Can you please test this one in addition to the $subject one:
 
 https://patchwork.kernel.org/patch/2068621/
 
 and see if that helps?
No change wrt the Oops, 'acpi_handle' corrupt.

Just to be clear, this happens during the logical undock phase after
writing to /sys/devices/platform/dock.0/undock.

Right now I manually tear down the seat associated with the dock gfx
card (waiting for the X server to terminate and requiring SIGSTOPing the
gdm process to stop it respawning!) then attempt radeon module unload,
if it succeeds I write to the undock file, otherwise I fail the undock;
I saw there is intention to put it infrastructure to have drivers
prepare themselves for removal on 'eject' request, that would be really
helpful.

A couple of other things regarding the dock system:

Making an undock/eject request with the dock eject button results in an
ACPI 'undock' event, same ACPI event happens when the
electrical/physical undock occurs.

The IDE docks seem not to be working; maybe I need to turn on some
debugging.  This used to work at some point.

Feb  2 23:51:28 infinity kernel: ACPI: \_SB_.PCI0.IDE1.PRI_.MAST:
docking
Feb  2 23:51:28 infinity kernel: ACPI: \_SB_.PCI0.IDE1.PRI_.MAST: Unable
to dock!


--
To unsubscribe from this list: send the line unsubscribe linux-kernel in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Re: [PATCH 1/2] ACPI / scan: Make namespace scanning and trimming mutually exclusive

[Steven Newbury]

On Sat,   2 Feb 2013, 20:18:28 GMT, Rafael J. Wysocki  wrote:

> On Saturday, February 02, 2013 11:58:41 AM Steven Newbury wrote:
> > On Sat, 2013-01-26 at 15:19 -0800, Yinghai Lu wrote:
> > > On Sat, Jan 26, 2013 at 2:41 PM, Rafael J. Wysocki 
> > > wrote:
> > > > From: Rafael J. Wysocki 
> > > > 
> > > > There is no guarantee that acpi_bus_scan() and acpi_bus_trim() will
> > > > not be run in parallel for the same scope of the ACPI namespace,
> > > > which may lead to a great deal of confusion, so introduce a new
> > > > mutex to prevent that from happening.
> > > > 
> > > > Signed-off-by: Rafael J. Wysocki 
> > > 
> > > Acked-by: Yinghai Lu 
> > > 
> > > Steven,
> > > 
> > > Can you apply this one to for-pci-res-alloc to check if racing with
> > > docking hotplug/eject
> > > still happen?
> > > or wait one or two days after i rebase that branch.
> > 
> > Tried merging with linux-pm/bleeding-edge, same behaviour:
> > 
> > [ 3589.013578] ACPI: \_SB_.PCI0.PCIE.GDCK: undocking
> > [ 3589.585356] vgaarb: device changed decodes:
> > PCI::00:02.0,olddecodes=none,decodes=io+mem:owns=none [
> > 3589.585422] ACPI: Delete PCI Interrupt Routing Table for :04 [
> > 3589.585426] pci :03:08.0: Oops, 'acpi_handle' corrupt [
> > 3589.585446] pci_bus :04: busn_res: [bus 04] is released
> > 
> > 03:08.0 PCI bridge: PLX Technology, Inc. PEX8112 x1 Lane PCI
> > Express-to-PCI Bridge (rev aa)
> > 04:00.0 VGA compatible controller: Advanced Micro Devices [AMD] nee ATI
> > Manhattan [Mobility Radeon HD 5430 Series]
> > 04:00.1 Audio device: Advanced Micro Devices [AMD] nee ATI Cedar HDMI
> > Audio [Radeon HD 5400/6300 Series]
> 
> That's because of a bug in the dock code I believe.
> 
> If you're willing to test patches, I can try to cook up something to
> debug/fix this.
Sure, I'm always willing to test patches.
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Re: [PATCH 1/2] ACPI / scan: Make namespace scanning and trimming mutually exclusive

[Steven Newbury]

On Sat, 2013-01-26 at 15:19 -0800, Yinghai Lu wrote:
> On Sat, Jan 26, 2013 at 2:41 PM, Rafael J. Wysocki  wrote:
> > From: Rafael J. Wysocki 
> >
> > There is no guarantee that acpi_bus_scan() and acpi_bus_trim() will
> > not be run in parallel for the same scope of the ACPI namespace,
> > which may lead to a great deal of confusion, so introduce a new mutex
> > to prevent that from happening.
> >
> > Signed-off-by: Rafael J. Wysocki 
> 
> Acked-by: Yinghai Lu 
> 
> Steven,
> 
> Can you apply this one to for-pci-res-alloc to check if racing with
> docking hotplug/eject
> still happen?
> or wait one or two days after i rebase that branch.

Tried merging with linux-pm/bleeding-edge, same behaviour:

[ 3589.013578] ACPI: \_SB_.PCI0.PCIE.GDCK: undocking
[ 3589.585356] vgaarb: device changed decodes: 
PCI::00:02.0,olddecodes=none,decodes=io+mem:owns=none
[ 3589.585422] ACPI: Delete PCI Interrupt Routing Table for :04
[ 3589.585426] pci :03:08.0: Oops, 'acpi_handle' corrupt
[ 3589.585446] pci_bus :04: busn_res: [bus 04] is released

03:08.0 PCI bridge: PLX Technology, Inc. PEX8112 x1 Lane PCI
Express-to-PCI Bridge (rev aa)
04:00.0 VGA compatible controller: Advanced Micro Devices [AMD] nee ATI
Manhattan [Mobility Radeon HD 5430 Series]
04:00.1 Audio device: Advanced Micro Devices [AMD] nee ATI Cedar HDMI
Audio [Radeon HD 5400/6300 Series]


> > ---
> >  drivers/acpi/scan.c |   16 
> >  1 file changed, 12 insertions(+), 4 deletions(-)
> >
> > Index: linux-pm/drivers/acpi/scan.c
> > ===
> > --- linux-pm.orig/drivers/acpi/scan.c
> > +++ linux-pm/drivers/acpi/scan.c
> > @@ -52,6 +52,7 @@ static const struct acpi_device_id acpi_
> >
> >  static LIST_HEAD(acpi_device_list);
> >  static LIST_HEAD(acpi_bus_id_list);
> > +static DEFINE_MUTEX(acpi_scan_lock);
> >  DEFINE_MUTEX(acpi_device_lock);
> >  LIST_HEAD(acpi_wakeup_device_list);
> >
> > @@ -1612,19 +1613,22 @@ static acpi_status acpi_bus_device_attac
> >  int acpi_bus_scan(acpi_handle handle)
> >  {
> > void *device = NULL;
> > +   int error = 0;
> > +
> > +   mutex_lock(_scan_lock);
> >
> > if (ACPI_SUCCESS(acpi_bus_check_add(handle, 0, NULL, )))
> > acpi_walk_namespace(ACPI_TYPE_ANY, handle, ACPI_UINT32_MAX,
> > acpi_bus_check_add, NULL, NULL, 
> > );
> >
> > if (!device)
> > -   return -ENODEV;
> > -
> > -   if (ACPI_SUCCESS(acpi_bus_device_attach(handle, 0, NULL, NULL)))
> > +   error = -ENODEV;
> > +   else if (ACPI_SUCCESS(acpi_bus_device_attach(handle, 0, NULL, 
> > NULL)))
> > acpi_walk_namespace(ACPI_TYPE_ANY, handle, ACPI_UINT32_MAX,
> > acpi_bus_device_attach, NULL, NULL, 
> > NULL);
> >
> > -   return 0;
> > +   mutex_unlock(_scan_lock);
> > +   return error;
> >  }
> >  EXPORT_SYMBOL(acpi_bus_scan);
> >
> > @@ -1653,6 +1657,8 @@ static acpi_status acpi_bus_remove(acpi_
> >
> >  void acpi_bus_trim(struct acpi_device *start)
> >  {
> > +   mutex_lock(_scan_lock);
> > +
> > /*
> >  * Execute acpi_bus_device_detach() as a post-order callback to 
> > detach
> >  * all ACPI drivers from the device nodes being removed.
> > @@ -1667,6 +1673,8 @@ void acpi_bus_trim(struct acpi_device *s
> > acpi_walk_namespace(ACPI_TYPE_ANY, start->handle, ACPI_UINT32_MAX, 
> > NULL,
> > acpi_bus_remove, NULL, NULL);
> > acpi_bus_remove(start->handle, 0, NULL, NULL);
> > +
> > +   mutex_unlock(_scan_lock);
> >  }
> >  EXPORT_SYMBOL_GPL(acpi_bus_trim);
> >
> >


--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Re: [PATCH 1/2] ACPI / scan: Make namespace scanning and trimming mutually exclusive

[Steven Newbury]

On Sat, 2013-01-26 at 15:19 -0800, Yinghai Lu wrote:
 On Sat, Jan 26, 2013 at 2:41 PM, Rafael J. Wysocki r...@sisk.pl wrote:
  From: Rafael J. Wysocki rafael.j.wyso...@intel.com
 
  There is no guarantee that acpi_bus_scan() and acpi_bus_trim() will
  not be run in parallel for the same scope of the ACPI namespace,
  which may lead to a great deal of confusion, so introduce a new mutex
  to prevent that from happening.
 
  Signed-off-by: Rafael J. Wysocki rafael.j.wyso...@intel.com
 
 Acked-by: Yinghai Lu ying...@kernel.org
 
 Steven,
 
 Can you apply this one to for-pci-res-alloc to check if racing with
 docking hotplug/eject
 still happen?
 or wait one or two days after i rebase that branch.

Tried merging with linux-pm/bleeding-edge, same behaviour:

[ 3589.013578] ACPI: \_SB_.PCI0.PCIE.GDCK: undocking
[ 3589.585356] vgaarb: device changed decodes: 
PCI::00:02.0,olddecodes=none,decodes=io+mem:owns=none
[ 3589.585422] ACPI: Delete PCI Interrupt Routing Table for :04
[ 3589.585426] pci :03:08.0: Oops, 'acpi_handle' corrupt
[ 3589.585446] pci_bus :04: busn_res: [bus 04] is released

03:08.0 PCI bridge: PLX Technology, Inc. PEX8112 x1 Lane PCI
Express-to-PCI Bridge (rev aa)
04:00.0 VGA compatible controller: Advanced Micro Devices [AMD] nee ATI
Manhattan [Mobility Radeon HD 5430 Series]
04:00.1 Audio device: Advanced Micro Devices [AMD] nee ATI Cedar HDMI
Audio [Radeon HD 5400/6300 Series]


  ---
   drivers/acpi/scan.c |   16 
   1 file changed, 12 insertions(+), 4 deletions(-)
 
  Index: linux-pm/drivers/acpi/scan.c
  ===
  --- linux-pm.orig/drivers/acpi/scan.c
  +++ linux-pm/drivers/acpi/scan.c
  @@ -52,6 +52,7 @@ static const struct acpi_device_id acpi_
 
   static LIST_HEAD(acpi_device_list);
   static LIST_HEAD(acpi_bus_id_list);
  +static DEFINE_MUTEX(acpi_scan_lock);
   DEFINE_MUTEX(acpi_device_lock);
   LIST_HEAD(acpi_wakeup_device_list);
 
  @@ -1612,19 +1613,22 @@ static acpi_status acpi_bus_device_attac
   int acpi_bus_scan(acpi_handle handle)
   {
  void *device = NULL;
  +   int error = 0;
  +
  +   mutex_lock(acpi_scan_lock);
 
  if (ACPI_SUCCESS(acpi_bus_check_add(handle, 0, NULL, device)))
  acpi_walk_namespace(ACPI_TYPE_ANY, handle, ACPI_UINT32_MAX,
  acpi_bus_check_add, NULL, NULL, 
  device);
 
  if (!device)
  -   return -ENODEV;
  -
  -   if (ACPI_SUCCESS(acpi_bus_device_attach(handle, 0, NULL, NULL)))
  +   error = -ENODEV;
  +   else if (ACPI_SUCCESS(acpi_bus_device_attach(handle, 0, NULL, 
  NULL)))
  acpi_walk_namespace(ACPI_TYPE_ANY, handle, ACPI_UINT32_MAX,
  acpi_bus_device_attach, NULL, NULL, 
  NULL);
 
  -   return 0;
  +   mutex_unlock(acpi_scan_lock);
  +   return error;
   }
   EXPORT_SYMBOL(acpi_bus_scan);
 
  @@ -1653,6 +1657,8 @@ static acpi_status acpi_bus_remove(acpi_
 
   void acpi_bus_trim(struct acpi_device *start)
   {
  +   mutex_lock(acpi_scan_lock);
  +
  /*
   * Execute acpi_bus_device_detach() as a post-order callback to 
  detach
   * all ACPI drivers from the device nodes being removed.
  @@ -1667,6 +1673,8 @@ void acpi_bus_trim(struct acpi_device *s
  acpi_walk_namespace(ACPI_TYPE_ANY, start-handle, ACPI_UINT32_MAX, 
  NULL,
  acpi_bus_remove, NULL, NULL);
  acpi_bus_remove(start-handle, 0, NULL, NULL);
  +
  +   mutex_unlock(acpi_scan_lock);
   }
   EXPORT_SYMBOL_GPL(acpi_bus_trim);
 
 


--
To unsubscribe from this list: send the line unsubscribe linux-kernel in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Re: [PATCH 1/2] ACPI / scan: Make namespace scanning and trimming mutually exclusive

[Steven Newbury]

On Sat,   2 Feb 2013, 20:18:28 GMT, Rafael J. Wysocki r...@sisk.pl wrote:

 On Saturday, February 02, 2013 11:58:41 AM Steven Newbury wrote:
  On Sat, 2013-01-26 at 15:19 -0800, Yinghai Lu wrote:
   On Sat, Jan 26, 2013 at 2:41 PM, Rafael J. Wysocki r...@sisk.pl
   wrote:
From: Rafael J. Wysocki rafael.j.wyso...@intel.com

There is no guarantee that acpi_bus_scan() and acpi_bus_trim() will
not be run in parallel for the same scope of the ACPI namespace,
which may lead to a great deal of confusion, so introduce a new
mutex to prevent that from happening.

Signed-off-by: Rafael J. Wysocki rafael.j.wyso...@intel.com
   
   Acked-by: Yinghai Lu ying...@kernel.org
   
   Steven,
   
   Can you apply this one to for-pci-res-alloc to check if racing with
   docking hotplug/eject
   still happen?
   or wait one or two days after i rebase that branch.
  
  Tried merging with linux-pm/bleeding-edge, same behaviour:
  
  [ 3589.013578] ACPI: \_SB_.PCI0.PCIE.GDCK: undocking
  [ 3589.585356] vgaarb: device changed decodes:
  PCI::00:02.0,olddecodes=none,decodes=io+mem:owns=none [
  3589.585422] ACPI: Delete PCI Interrupt Routing Table for :04 [
  3589.585426] pci :03:08.0: Oops, 'acpi_handle' corrupt [
  3589.585446] pci_bus :04: busn_res: [bus 04] is released
  
  03:08.0 PCI bridge: PLX Technology, Inc. PEX8112 x1 Lane PCI
  Express-to-PCI Bridge (rev aa)
  04:00.0 VGA compatible controller: Advanced Micro Devices [AMD] nee ATI
  Manhattan [Mobility Radeon HD 5430 Series]
  04:00.1 Audio device: Advanced Micro Devices [AMD] nee ATI Cedar HDMI
  Audio [Radeon HD 5400/6300 Series]
 
 That's because of a bug in the dock code I believe.
 
 If you're willing to test patches, I can try to cook up something to
 debug/fix this.
Sure, I'm always willing to test patches.
--
To unsubscribe from this list: send the line unsubscribe linux-kernel in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Re: [PATCH 1/2] ACPI / scan: Make namespace scanning and trimming mutually exclusive

[Steven Newbury]

On Sat, 2013-01-26 at 15:19 -0800, Yinghai Lu wrote:
> On Sat, Jan 26, 2013 at 2:41 PM, Rafael J. Wysocki  wrote:
> > From: Rafael J. Wysocki 
> >
> > There is no guarantee that acpi_bus_scan() and acpi_bus_trim() will
> > not be run in parallel for the same scope of the ACPI namespace,
> > which may lead to a great deal of confusion, so introduce a new mutex
> > to prevent that from happening.
> >
> > Signed-off-by: Rafael J. Wysocki 
> 
> Acked-by: Yinghai Lu 
> 
> Steven,
> 
> Can you apply this one to for-pci-res-alloc to check if racing with
> docking hotplug/eject
> still happen?
> or wait one or two days after i rebase that branch.
> 
Still get the corrupt acpi_handle.

> Thanks
> 
> Yinghai
> 
> > ---
> >  drivers/acpi/scan.c |   16 
> >  1 file changed, 12 insertions(+), 4 deletions(-)
> >
> > Index: linux-pm/drivers/acpi/scan.c
> > ===
> > --- linux-pm.orig/drivers/acpi/scan.c
> > +++ linux-pm/drivers/acpi/scan.c
> > @@ -52,6 +52,7 @@ static const struct acpi_device_id acpi_
> >
> >  static LIST_HEAD(acpi_device_list);
> >  static LIST_HEAD(acpi_bus_id_list);
> > +static DEFINE_MUTEX(acpi_scan_lock);
> >  DEFINE_MUTEX(acpi_device_lock);
> >  LIST_HEAD(acpi_wakeup_device_list);
> >
> > @@ -1612,19 +1613,22 @@ static acpi_status acpi_bus_device_attac
> >  int acpi_bus_scan(acpi_handle handle)
> >  {
> > void *device = NULL;
> > +   int error = 0;
> > +
> > +   mutex_lock(_scan_lock);
> >
> > if (ACPI_SUCCESS(acpi_bus_check_add(handle, 0, NULL, )))
> > acpi_walk_namespace(ACPI_TYPE_ANY, handle, ACPI_UINT32_MAX,
> > acpi_bus_check_add, NULL, NULL, 
> > );
> >
> > if (!device)
> > -   return -ENODEV;
> > -
> > -   if (ACPI_SUCCESS(acpi_bus_device_attach(handle, 0, NULL, NULL)))
> > +   error = -ENODEV;
> > +   else if (ACPI_SUCCESS(acpi_bus_device_attach(handle, 0, NULL, 
> > NULL)))
> > acpi_walk_namespace(ACPI_TYPE_ANY, handle, ACPI_UINT32_MAX,
> > acpi_bus_device_attach, NULL, NULL, 
> > NULL);
> >
> > -   return 0;
> > +   mutex_unlock(_scan_lock);
> > +   return error;
> >  }
> >  EXPORT_SYMBOL(acpi_bus_scan);
> >
> > @@ -1653,6 +1657,8 @@ static acpi_status acpi_bus_remove(acpi_
> >
> >  void acpi_bus_trim(struct acpi_device *start)
> >  {
> > +   mutex_lock(_scan_lock);
> > +
> > /*
> >  * Execute acpi_bus_device_detach() as a post-order callback to 
> > detach
> >  * all ACPI drivers from the device nodes being removed.
> > @@ -1667,6 +1673,8 @@ void acpi_bus_trim(struct acpi_device *s
> > acpi_walk_namespace(ACPI_TYPE_ANY, start->handle, ACPI_UINT32_MAX, 
> > NULL,
> > acpi_bus_remove, NULL, NULL);
> > acpi_bus_remove(start->handle, 0, NULL, NULL);
> > +
> > +   mutex_unlock(_scan_lock);
> >  }
> >  EXPORT_SYMBOL_GPL(acpi_bus_trim);
> >
> >


--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Re: [PATCH 1/2] ACPI / scan: Make namespace scanning and trimming mutually exclusive

[Steven Newbury]

On Sat, 2013-01-26 at 15:19 -0800, Yinghai Lu wrote:
 On Sat, Jan 26, 2013 at 2:41 PM, Rafael J. Wysocki r...@sisk.pl wrote:
  From: Rafael J. Wysocki rafael.j.wyso...@intel.com
 
  There is no guarantee that acpi_bus_scan() and acpi_bus_trim() will
  not be run in parallel for the same scope of the ACPI namespace,
  which may lead to a great deal of confusion, so introduce a new mutex
  to prevent that from happening.
 
  Signed-off-by: Rafael J. Wysocki rafael.j.wyso...@intel.com
 
 Acked-by: Yinghai Lu ying...@kernel.org
 
 Steven,
 
 Can you apply this one to for-pci-res-alloc to check if racing with
 docking hotplug/eject
 still happen?
 or wait one or two days after i rebase that branch.
 
Still get the corrupt acpi_handle.

 Thanks
 
 Yinghai
 
  ---
   drivers/acpi/scan.c |   16 
   1 file changed, 12 insertions(+), 4 deletions(-)
 
  Index: linux-pm/drivers/acpi/scan.c
  ===
  --- linux-pm.orig/drivers/acpi/scan.c
  +++ linux-pm/drivers/acpi/scan.c
  @@ -52,6 +52,7 @@ static const struct acpi_device_id acpi_
 
   static LIST_HEAD(acpi_device_list);
   static LIST_HEAD(acpi_bus_id_list);
  +static DEFINE_MUTEX(acpi_scan_lock);
   DEFINE_MUTEX(acpi_device_lock);
   LIST_HEAD(acpi_wakeup_device_list);
 
  @@ -1612,19 +1613,22 @@ static acpi_status acpi_bus_device_attac
   int acpi_bus_scan(acpi_handle handle)
   {
  void *device = NULL;
  +   int error = 0;
  +
  +   mutex_lock(acpi_scan_lock);
 
  if (ACPI_SUCCESS(acpi_bus_check_add(handle, 0, NULL, device)))
  acpi_walk_namespace(ACPI_TYPE_ANY, handle, ACPI_UINT32_MAX,
  acpi_bus_check_add, NULL, NULL, 
  device);
 
  if (!device)
  -   return -ENODEV;
  -
  -   if (ACPI_SUCCESS(acpi_bus_device_attach(handle, 0, NULL, NULL)))
  +   error = -ENODEV;
  +   else if (ACPI_SUCCESS(acpi_bus_device_attach(handle, 0, NULL, 
  NULL)))
  acpi_walk_namespace(ACPI_TYPE_ANY, handle, ACPI_UINT32_MAX,
  acpi_bus_device_attach, NULL, NULL, 
  NULL);
 
  -   return 0;
  +   mutex_unlock(acpi_scan_lock);
  +   return error;
   }
   EXPORT_SYMBOL(acpi_bus_scan);
 
  @@ -1653,6 +1657,8 @@ static acpi_status acpi_bus_remove(acpi_
 
   void acpi_bus_trim(struct acpi_device *start)
   {
  +   mutex_lock(acpi_scan_lock);
  +
  /*
   * Execute acpi_bus_device_detach() as a post-order callback to 
  detach
   * all ACPI drivers from the device nodes being removed.
  @@ -1667,6 +1673,8 @@ void acpi_bus_trim(struct acpi_device *s
  acpi_walk_namespace(ACPI_TYPE_ANY, start-handle, ACPI_UINT32_MAX, 
  NULL,
  acpi_bus_remove, NULL, NULL);
  acpi_bus_remove(start-handle, 0, NULL, NULL);
  +
  +   mutex_unlock(acpi_scan_lock);
   }
   EXPORT_SYMBOL_GPL(acpi_bus_trim);
 
 


--
To unsubscribe from this list: send the line unsubscribe linux-kernel in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Re: [PATCH] pxa2xx PCMCIA timing issue on iPAQ H5550

[Steven Newbury]

--- Milan Plzik <[EMAIL PROTECTED]> wrote:

> On Å t, 2007-08-09 at 16:06 +0100, Steven Newbury wrote:
> > --- Milan Plzik <[EMAIL PROTECTED]> wrote:
> > 
> > >   Good day,
> > > 
> > >   recently I've been trying to get working PCMCIA interface on H5000
> > > ipaq series, using dual PCMCIA sleeve. So far things work correctly, but
> > > I had to do one modification to drivers/pcmcia/pxa2xx_base.c to get the
> > > interface working with orinoco gold PCMCIA card (wired pcnet_cs ethernet
> > > card worked even without this modification). Patch attached.
> > > 
> > >   The issue has something to do with assert time on PCMCIA bus, but I'm
> > > not really sure what -- I found the working value just by trial
> > > approach. I'm not sure how is the assert value in pxa2xx_mcxx_asst
> > > calculated (I know, simple formula, but the reason why is it calculated
> > > that way is not obvious for me), neither that my modification is
> > > correct. It just works with iPAQ. 
> > > 
> > I posted a patch to linux-arm-kernel which reworked the timing code.  The
> > existing is/was IMHO wrong and this showed up for me with frequency scaling
> > where the code would not keep the PCMCIA timings constant with changes to
> the
> > core frequency.  Here it is:
> > http://marc.info/?l=linux-arm-kernel=116861295404294=2
> 
>   I found out that drivers/pcmcia/pxa2xx_base.c from handhelds.org tree
> was a bit modified. I tried both vanilla kernel tree and vanilla+this
> patch -- both worked with pcnet_cs, and neither one with orinoco card.
> As far as I understand, handhelds.org modification makes use of memory
> clock instead of cpu clock for calculations. But even when using old
> handhelds.org driver with modified formulas, orinoco card won't
> initialize.
> 
What actually happens?  I'm using a spectrum24 and it works fine on my Zaurus
SL-C3100.  Is it trying to load the firmware?  I'm still using 2.6.20, so if
something has broken since I don't know about it.

>   I'm not really sure how things should be calculated, I'll try ask
> folks who modified the hh.org driverto see what could cause the
> problems.
> 
It is all detailed in the PXA2xx manuals.  I did try to enough details in my
comments to make sense of the calculation.  As was commented on when I posted
it, it isn't ideal since it uses divides which are relatively slow on ARMs.


Steve


  ___ 
Want ideas for reducing your carbon footprint? Visit Yahoo! For Good  
http://uk.promotions.yahoo.com/forgood/environment.html
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Re: [PATCH] pxa2xx PCMCIA timing issue on iPAQ H5550

[Steven Newbury]

--- Milan Plzik [EMAIL PROTECTED] wrote:

 On Å t, 2007-08-09 at 16:06 +0100, Steven Newbury wrote:
  --- Milan Plzik [EMAIL PROTECTED] wrote:
  
 Good day,
   
 recently I've been trying to get working PCMCIA interface on H5000
   ipaq series, using dual PCMCIA sleeve. So far things work correctly, but
   I had to do one modification to drivers/pcmcia/pxa2xx_base.c to get the
   interface working with orinoco gold PCMCIA card (wired pcnet_cs ethernet
   card worked even without this modification). Patch attached.
   
 The issue has something to do with assert time on PCMCIA bus, but I'm
   not really sure what -- I found the working value just by trialerror
   approach. I'm not sure how is the assert value in pxa2xx_mcxx_asst
   calculated (I know, simple formula, but the reason why is it calculated
   that way is not obvious for me), neither that my modification is
   correct. It just works with iPAQ. 
   
  I posted a patch to linux-arm-kernel which reworked the timing code.  The
  existing is/was IMHO wrong and this showed up for me with frequency scaling
  where the code would not keep the PCMCIA timings constant with changes to
 the
  core frequency.  Here it is:
  http://marc.info/?l=linux-arm-kernelm=116861295404294w=2
 
   I found out that drivers/pcmcia/pxa2xx_base.c from handhelds.org tree
 was a bit modified. I tried both vanilla kernel tree and vanilla+this
 patch -- both worked with pcnet_cs, and neither one with orinoco card.
 As far as I understand, handhelds.org modification makes use of memory
 clock instead of cpu clock for calculations. But even when using old
 handhelds.org driver with modified formulas, orinoco card won't
 initialize.
 
What actually happens?  I'm using a spectrum24 and it works fine on my Zaurus
SL-C3100.  Is it trying to load the firmware?  I'm still using 2.6.20, so if
something has broken since I don't know about it.

   I'm not really sure how things should be calculated, I'll try ask
 folks who modified the hh.org driverto see what could cause the
 problems.
 
It is all detailed in the PXA2xx manuals.  I did try to enough details in my
comments to make sense of the calculation.  As was commented on when I posted
it, it isn't ideal since it uses divides which are relatively slow on ARMs.


Steve


  ___ 
Want ideas for reducing your carbon footprint? Visit Yahoo! For Good  
http://uk.promotions.yahoo.com/forgood/environment.html
-
To unsubscribe from this list: send the line unsubscribe linux-kernel in
the body of a message to [EMAIL PROTECTED]
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Re: [PATCH] pxa2xx PCMCIA timing issue on iPAQ H5550

[Steven Newbury]

--- Milan Plzik <[EMAIL PROTECTED]> wrote:

>   Good day,
> 
>   recently I've been trying to get working PCMCIA interface on H5000
> ipaq series, using dual PCMCIA sleeve. So far things work correctly, but
> I had to do one modification to drivers/pcmcia/pxa2xx_base.c to get the
> interface working with orinoco gold PCMCIA card (wired pcnet_cs ethernet
> card worked even without this modification). Patch attached.
> 
>   The issue has something to do with assert time on PCMCIA bus, but I'm
> not really sure what -- I found the working value just by trial
> approach. I'm not sure how is the assert value in pxa2xx_mcxx_asst
> calculated (I know, simple formula, but the reason why is it calculated
> that way is not obvious for me), neither that my modification is
> correct. It just works with iPAQ. 
> 
I posted a patch to linux-arm-kernel which reworked the timing code.  The
existing is/was IMHO wrong and this showed up for me with frequency scaling
where the code would not keep the PCMCIA timings constant with changes to the
core frequency.  Here it is:
http://marc.info/?l=linux-arm-kernel=116861295404294=2


Steve


  ___
For email that puts you in control, choose Yahoo! Mail.
http://uk.docs.yahoo.com/mail/addressguard2.html
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Re: [PATCH] pxa2xx PCMCIA timing issue on iPAQ H5550

[Steven Newbury]

--- Milan Plzik [EMAIL PROTECTED] wrote:

   Good day,
 
   recently I've been trying to get working PCMCIA interface on H5000
 ipaq series, using dual PCMCIA sleeve. So far things work correctly, but
 I had to do one modification to drivers/pcmcia/pxa2xx_base.c to get the
 interface working with orinoco gold PCMCIA card (wired pcnet_cs ethernet
 card worked even without this modification). Patch attached.
 
   The issue has something to do with assert time on PCMCIA bus, but I'm
 not really sure what -- I found the working value just by trialerror
 approach. I'm not sure how is the assert value in pxa2xx_mcxx_asst
 calculated (I know, simple formula, but the reason why is it calculated
 that way is not obvious for me), neither that my modification is
 correct. It just works with iPAQ. 
 
I posted a patch to linux-arm-kernel which reworked the timing code.  The
existing is/was IMHO wrong and this showed up for me with frequency scaling
where the code would not keep the PCMCIA timings constant with changes to the
core frequency.  Here it is:
http://marc.info/?l=linux-arm-kernelm=116861295404294w=2


Steve


  ___
For email that puts you in control, choose Yahoo! Mail.
http://uk.docs.yahoo.com/mail/addressguard2.html
-
To unsubscribe from this list: send the line unsubscribe linux-kernel in
the body of a message to [EMAIL PROTECTED]
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Re: cache coherecy when working with cpu dcache write allocate

[Steven Newbury]

--- saeed bishara <[EMAIL PROTECTED]> wrote:

> Hi,
> I came across data corruption problem when using xfs, my system is
> arm 926, the data cache is virtually tagged and virtually indexed and
> with no hw cache coherency. my CPU features the data cache write
> allocate-> when doing store, the cache line of the destination address
> is loaded to data cache.
>   when enabling the write allocate, I got data corruption with the
> xfs. the scenario is that the xfs allocates large buffer (for reading
> the log records) using vmalloc, and the low level driver (raid) copies
> the data to the bio vectors using the linear address, since the write
> allocate is enabled,  the correct data remains on the data cache with
> the linear address tag, when the IO completes, the xfs access the data
> with using the vmalloc virtual address, which is different than the
> kernel linear address, thus it will get a stale data!.
> 
> how should I fix this problem? I thought that only the
> copy/clean_user_pages() functions should be aware to the write
> allocate.
I wonder if I'm seeing this with reiser4 on pxa27x as well???

Steve



___ 
Now you can have your favourite RSS headlines come to you with the all new 
Yahoo! Mail. http://uk.docs.yahoo.com/nowyoucan.html
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Re: cache coherecy when working with cpu dcache write allocate

[Steven Newbury]

--- saeed bishara [EMAIL PROTECTED] wrote:

 Hi,
 I came across data corruption problem when using xfs, my system is
 arm 926, the data cache is virtually tagged and virtually indexed and
 with no hw cache coherency. my CPU features the data cache write
 allocate- when doing store, the cache line of the destination address
 is loaded to data cache.
   when enabling the write allocate, I got data corruption with the
 xfs. the scenario is that the xfs allocates large buffer (for reading
 the log records) using vmalloc, and the low level driver (raid) copies
 the data to the bio vectors using the linear address, since the write
 allocate is enabled,  the correct data remains on the data cache with
 the linear address tag, when the IO completes, the xfs access the data
 with using the vmalloc virtual address, which is different than the
 kernel linear address, thus it will get a stale data!.
 
 how should I fix this problem? I thought that only the
 copy/clean_user_pages() functions should be aware to the write
 allocate.
I wonder if I'm seeing this with reiser4 on pxa27x as well???

Steve



___ 
Now you can have your favourite RSS headlines come to you with the all new 
Yahoo! Mail. http://uk.docs.yahoo.com/nowyoucan.html
-
To unsubscribe from this list: send the line unsubscribe linux-kernel in
the body of a message to [EMAIL PROTECTED]
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/