Hi Linus,
Please pull from the git repository at
git://git.kernel.org/pub/scm/linux/kernel/git/rafael/linux-pm.git pm+acpi-3.11-rc4
to receive ACPI and power management fixes for v3.11-rc4 with
top-most commit 2b44c4db2e2f1765d35163a861d301038e0c8a75
freezer: set PF_SUSPEND_TASK flag on tasks that call freeze_processes
on top of commit 5ae90d8e467e625e447000cb4335c4db973b1095
Linux 3.11-rc3
These revert two cpuidle commits from 3.8 that turn out to hurt performance,
fix a recent s2disk regression related to the freezer, fix cpufreq reference
couting problem uncovered by one of the recent reverts and fix a particularly
embarrassing bug in the ACPI battery driver.
Specifics:
- Revert two cpuidle commits added during the 3.8 development cycle that
turn out to have introduced a significant performance regression as
requested by Jeremy Eder.
- The recent patches that made the freezer less heavy-weight introduced
a regression causing user-space-driven hibernation using the ioctl()
interface to block indefinitely when the hibernate process executes
try_to_freeze(). Fix from Colin Cross addresses this by adding a
process flag to mark the hibernate/suspend process to inform the
freezer that that process should be ignored.
- One of the recent cpufreq reverts uncovered a problem in the core
causing the cpufreq driver module refcount to become negative after
a system suspend-resume cycle. Fix from yours truly.
- The evaluation of the ACPI battery _BIX method has never worked
correctly, because the commit that added support for it forgot to
take the "Revision" field in the return package into account. As
a result, the reading of battery info doesn't work at all on some
systems, which is addressed by a fix from Lan Tianyu.
Thanks!
---------------
Colin Cross (1):
freezer: set PF_SUSPEND_TASK flag on tasks that call freeze_processes
Lan Tianyu (1):
ACPI / battery: Fix parsing _BIX return value
Rafael J. Wysocki (3):
Revert "cpuidle: Quickly notice prediction failure in general case"
Revert "cpuidle: Quickly notice prediction failure for repeat mode"
cpufreq: Fix cpufreq driver module refcount balance after suspend/resume
---------------
drivers/acpi/battery.c | 2 +
drivers/cpufreq/cpufreq.c | 19 +++++----
drivers/cpuidle/governors/menu.c | 106 ++--------------------------------------------
include/linux/sched.h | 1 +
include/linux/tick.h | 6 ---
kernel/freezer.c | 2 +-
kernel/power/process.c | 11 +++++
kernel/time/tick-sched.c | 9 +---
8 files changed, 31 insertions(+), 125 deletions(-)
On Fri, Aug 2, 2013 at 9:29 AM, Rafael J. Wysocki <[email protected]> wrote:
> ---------------
>
> Colin Cross (1):
> freezer: set PF_SUSPEND_TASK flag on tasks that call freeze_processes
>
> Lan Tianyu (1):
> ACPI / battery: Fix parsing _BIX return value
>
> Rafael J. Wysocki (3):
> Revert "cpuidle: Quickly notice prediction failure in general case"
> Revert "cpuidle: Quickly notice prediction failure for repeat mode"
> cpufreq: Fix cpufreq driver module refcount balance after suspend/resume
>
> ---------------
You forgot this patch:
https://git.kernel.org/cgit/linux/kernel/git/rafael/linux-pm.git/commit/?h=linux-next&id=3706231332d57072e0e2c0e59975443f3f18e673
Or do you think it's fine to boot these machines into a black screen?
--
Felipe Contreras
On Friday, August 02, 2013 02:12:49 PM Felipe Contreras wrote:
> On Fri, Aug 2, 2013 at 9:29 AM, Rafael J. Wysocki <[email protected]> wrote:
>
> > ---------------
> >
> > Colin Cross (1):
> > freezer: set PF_SUSPEND_TASK flag on tasks that call freeze_processes
> >
> > Lan Tianyu (1):
> > ACPI / battery: Fix parsing _BIX return value
> >
> > Rafael J. Wysocki (3):
> > Revert "cpuidle: Quickly notice prediction failure in general case"
> > Revert "cpuidle: Quickly notice prediction failure for repeat mode"
> > cpufreq: Fix cpufreq driver module refcount balance after suspend/resume
> >
> > ---------------
>
> You forgot this patch:
>
> https://git.kernel.org/cgit/linux/kernel/git/rafael/linux-pm.git/commit/?h=linux-next&id=3706231332d57072e0e2c0e59975443f3f18e673
>
> Or do you think it's fine to boot these machines into a black screen?
Seriously, what's wrong with you?!
I didn't forget about it, I just didn't include it into this particular
pull request.
And I'm not even sure I will push it for 3.11, because I prefer to revert
efaa14c for 3.11 if that's necessary to make your broken box work as before.
Well, perhaps I just won't push it at all so that you actually can go and
complain to Linus about that ...
On Fri, Aug 2, 2013 at 4:21 PM, Rafael J. Wysocki <[email protected]> wrote:
> On Friday, August 02, 2013 02:12:49 PM Felipe Contreras wrote:
>> You forgot this patch:
>>
>> https://git.kernel.org/cgit/linux/kernel/git/rafael/linux-pm.git/commit/?h=linux-next&id=3706231332d57072e0e2c0e59975443f3f18e673
>>
>> Or do you think it's fine to boot these machines into a black screen?
>
> Seriously, what's wrong with you?!
>
> I didn't forget about it, I just didn't include it into this particular
> pull request.
>
> And I'm not even sure I will push it for 3.11, because I prefer to revert
> efaa14c for 3.11 if that's necessary to make your broken box work as before.
The issue happens in more than just "my broken box", and yes,
reverting that patch would help (in more than just my box), in the
sense that at least Linux won't boot into a black screen.
But the backlight control still wouldn't work, as it hasn't worked
since v3.7, possibly in many ASUS laptops, for that you need more than
just reverting efaa14c.
> Well, perhaps I just won't push it at all so that you actually can go and
> complain to Linus about that ...
That is very responsible from you. Screw the users, right?
--
Felipe Contreras
On Friday, August 02, 2013 04:31:37 PM Felipe Contreras wrote:
> On Fri, Aug 2, 2013 at 4:21 PM, Rafael J. Wysocki <[email protected]> wrote:
> > On Friday, August 02, 2013 02:12:49 PM Felipe Contreras wrote:
>
> >> You forgot this patch:
> >>
> >> https://git.kernel.org/cgit/linux/kernel/git/rafael/linux-pm.git/commit/?h=linux-next&id=3706231332d57072e0e2c0e59975443f3f18e673
> >>
> >> Or do you think it's fine to boot these machines into a black screen?
> >
> > Seriously, what's wrong with you?!
> >
> > I didn't forget about it, I just didn't include it into this particular
> > pull request.
> >
> > And I'm not even sure I will push it for 3.11, because I prefer to revert
> > efaa14c for 3.11 if that's necessary to make your broken box work as before.
>
> The issue happens in more than just "my broken box", and yes,
> reverting that patch would help (in more than just my box), in the
> sense that at least Linux won't boot into a black screen.
>
> But the backlight control still wouldn't work, as it hasn't worked
> since v3.7, possibly in many ASUS laptops, for that you need more than
> just reverting efaa14c.
Yes, last time it worked in 3.6 and in particular it doesn't work in 3.10.
My current goal is bring things back to the 3.10 state first, possibly without
introducing any new problems, because we're kind of late in the cycle.
That's better done by reverting stuff known to have introduced problems in
the first place and not by doing things that may introduce more of them.
And your blacklisting patch has potential to introduce problems. Your goal is
to bring backlight control to the 3.6 state on that particular machine, but
the blacklist is done at the *system* level and very well may affect more
things than just backlight. You may not see any problems resulting from it
and you may not care even if there are some, but other users of it may use
different user space, for example, and may see problems that you're not seeing.
That's why I'd very much prefer to do the revert at this point.
> > Well, perhaps I just won't push it at all so that you actually can go and
> > complain to Linus about that ...
>
> That is very responsible from you. Screw the users, right?
No, that's not my goal, sorry for disappointing you.
The problem is that I'm not really convinced about the validity of the
blacklisting approach to begin with. As I said, the blacklisting is done
on the system level and the goal is to work around backlight control problems.
That sounds like a sledgehammer approach to me, which I don't really like.
If the blacklisting was more targeted, done at the video driver level etc.,
I wouldn't really have any concerns about it, but that's not the case.
And since people evidently could live for over 6 months with the backlight
control problems, maybe they'll survive some more time still and allow us to
find a better approach?
Rafael
--
I speak only for myself.
Rafael J. Wysocki, Intel Open Source Technology Center.
On Fri, Aug 2, 2013 at 5:21 PM, Rafael J. Wysocki <[email protected]> wrote:
> On Friday, August 02, 2013 04:31:37 PM Felipe Contreras wrote:
>> On Fri, Aug 2, 2013 at 4:21 PM, Rafael J. Wysocki <[email protected]> wrote:
>> > On Friday, August 02, 2013 02:12:49 PM Felipe Contreras wrote:
>>
>> >> You forgot this patch:
>> >>
>> >> https://git.kernel.org/cgit/linux/kernel/git/rafael/linux-pm.git/commit/?h=linux-next&id=3706231332d57072e0e2c0e59975443f3f18e673
>> >>
>> >> Or do you think it's fine to boot these machines into a black screen?
>> >
>> > Seriously, what's wrong with you?!
>> >
>> > I didn't forget about it, I just didn't include it into this particular
>> > pull request.
>> >
>> > And I'm not even sure I will push it for 3.11, because I prefer to revert
>> > efaa14c for 3.11 if that's necessary to make your broken box work as before.
>>
>> The issue happens in more than just "my broken box", and yes,
>> reverting that patch would help (in more than just my box), in the
>> sense that at least Linux won't boot into a black screen.
>>
>> But the backlight control still wouldn't work, as it hasn't worked
>> since v3.7, possibly in many ASUS laptops, for that you need more than
>> just reverting efaa14c.
>
> Yes, last time it worked in 3.6 and in particular it doesn't work in 3.10.
> My current goal is bring things back to the 3.10 state first, possibly without
> introducing any new problems, because we're kind of late in the cycle.
> That's better done by reverting stuff known to have introduced problems in
> the first place and not by doing things that may introduce more of them.
>
> And your blacklisting patch has potential to introduce problems. Your goal is
> to bring backlight control to the 3.6 state on that particular machine, but
> the blacklist is done at the *system* level and very well may affect more
> things than just backlight. You may not see any problems resulting from it
> and you may not care even if there are some, but other users of it may use
> different user space, for example, and may see problems that you're not seeing.
>
> That's why I'd very much prefer to do the revert at this point.
Yes, that's fine, either the revert, or the patch I mentioned, or
something else, but something has to be done, and it was better to do
it in v3.11-rc4 than in v3.11-rc5, because that change itself can
cause further problems.
>> > Well, perhaps I just won't push it at all so that you actually can go and
>> > complain to Linus about that ...
>>
>> That is very responsible from you. Screw the users, right?
>
> No, that's not my goal, sorry for disappointing you.
>
> The problem is that I'm not really convinced about the validity of the
> blacklisting approach to begin with. As I said, the blacklisting is done
> on the system level and the goal is to work around backlight control problems.
> That sounds like a sledgehammer approach to me, which I don't really like.
> If the blacklisting was more targeted, done at the video driver level etc.,
> I wouldn't really have any concerns about it, but that's not the case.
>
> And since people evidently could live for over 6 months with the backlight
> control problems, maybe they'll survive some more time still and allow us to
> find a better approach?
They probably can survive without Linux at all, that doesn't mean we
are doing our job.
Let's do a though experiment, let's say you are right, and they can
survive the 6 months it would take you to find the "perfect" solution,
say in v3.13. What's wrong with having a partial solution in v3.12? If
the blacklisting doesn't work properly (there's absolutely no evidence
for that), then you revert it on v3.12.1.
What's wrong with that approach?
--
Felipe Contreras
On Friday, August 02, 2013 08:48:09 PM Felipe Contreras wrote:
> On Fri, Aug 2, 2013 at 5:21 PM, Rafael J. Wysocki <[email protected]> wrote:
> > On Friday, August 02, 2013 04:31:37 PM Felipe Contreras wrote:
> >> On Fri, Aug 2, 2013 at 4:21 PM, Rafael J. Wysocki <[email protected]> wrote:
> >> > On Friday, August 02, 2013 02:12:49 PM Felipe Contreras wrote:
> >>
> >> >> You forgot this patch:
> >> >>
> >> >> https://git.kernel.org/cgit/linux/kernel/git/rafael/linux-pm.git/commit/?h=linux-next&id=3706231332d57072e0e2c0e59975443f3f18e673
> >> >>
> >> >> Or do you think it's fine to boot these machines into a black screen?
> >> >
> >> > Seriously, what's wrong with you?!
> >> >
> >> > I didn't forget about it, I just didn't include it into this particular
> >> > pull request.
> >> >
> >> > And I'm not even sure I will push it for 3.11, because I prefer to revert
> >> > efaa14c for 3.11 if that's necessary to make your broken box work as before.
> >>
> >> The issue happens in more than just "my broken box", and yes,
> >> reverting that patch would help (in more than just my box), in the
> >> sense that at least Linux won't boot into a black screen.
> >>
> >> But the backlight control still wouldn't work, as it hasn't worked
> >> since v3.7, possibly in many ASUS laptops, for that you need more than
> >> just reverting efaa14c.
> >
> > Yes, last time it worked in 3.6 and in particular it doesn't work in 3.10.
> > My current goal is bring things back to the 3.10 state first, possibly without
> > introducing any new problems, because we're kind of late in the cycle.
> > That's better done by reverting stuff known to have introduced problems in
> > the first place and not by doing things that may introduce more of them.
> >
> > And your blacklisting patch has potential to introduce problems. Your goal is
> > to bring backlight control to the 3.6 state on that particular machine, but
> > the blacklist is done at the *system* level and very well may affect more
> > things than just backlight. You may not see any problems resulting from it
> > and you may not care even if there are some, but other users of it may use
> > different user space, for example, and may see problems that you're not seeing.
> >
> > That's why I'd very much prefer to do the revert at this point.
>
> Yes, that's fine, either the revert, or the patch I mentioned, or
> something else, but something has to be done, and it was better to do
> it in v3.11-rc4 than in v3.11-rc5, because that change itself can
> cause further problems.
A revert can be done in -rc5 just fine. If we don't have a working fix this
week, I'll do the revert.
> >> > Well, perhaps I just won't push it at all so that you actually can go and
> >> > complain to Linus about that ...
> >>
> >> That is very responsible from you. Screw the users, right?
> >
> > No, that's not my goal, sorry for disappointing you.
> >
> > The problem is that I'm not really convinced about the validity of the
> > blacklisting approach to begin with. As I said, the blacklisting is done
> > on the system level and the goal is to work around backlight control problems.
> > That sounds like a sledgehammer approach to me, which I don't really like.
> > If the blacklisting was more targeted, done at the video driver level etc.,
> > I wouldn't really have any concerns about it, but that's not the case.
> >
> > And since people evidently could live for over 6 months with the backlight
> > control problems, maybe they'll survive some more time still and allow us to
> > find a better approach?
>
> They probably can survive without Linux at all, that doesn't mean we
> are doing our job.
>
> Let's do a though experiment, let's say you are right, and they can
> survive the 6 months it would take you to find the "perfect" solution,
> say in v3.13. What's wrong with having a partial solution in v3.12? If
> the blacklisting doesn't work properly (there's absolutely no evidence
> for that), then you revert it on v3.12.1.
>
> What's wrong with that approach?
If the blacklisting leads to problems, they may not be reported in the 3.12
time frame, but much later. For example because people won't realize that
the problems are caused by the blacklisting until much much later. And then
we'll be in a spot where whatever we do will break things for someone.
And we had situations like that in the past, which is the source of my concern.
You obviously don't have that experience, or you won't be so eager to inflict
the blacklisting on everyone.
Anyway, as you know, but conveniently don't mention, I asked some experienced
people for opinions about that. If they agree with you, we will add the
blacklist. If they don't, we won't add it.
Rafael
On Sat, 2013-08-03 at 13:54 +0200, Rafael J. Wysocki wrote:
> On Friday, August 02, 2013 08:48:09 PM Felipe Contreras wrote:
> > On Fri, Aug 2, 2013 at 5:21 PM, Rafael J. Wysocki <[email protected]> wrote:
> > > On Friday, August 02, 2013 04:31:37 PM Felipe Contreras wrote:
> > >> On Fri, Aug 2, 2013 at 4:21 PM, Rafael J. Wysocki <[email protected]> wrote:
> > >> > On Friday, August 02, 2013 02:12:49 PM Felipe Contreras wrote:
> > >>
> > >> >> You forgot this patch:
> > >> >>
> > >> >> https://git.kernel.org/cgit/linux/kernel/git/rafael/linux-pm.git/commit/?h=linux-next&id=3706231332d57072e0e2c0e59975443f3f18e673
> > >> >>
> > >> >> Or do you think it's fine to boot these machines into a black screen?
> > >> >
> > >> > Seriously, what's wrong with you?!
> > >> >
> > >> > I didn't forget about it, I just didn't include it into this particular
> > >> > pull request.
> > >> >
> > >> > And I'm not even sure I will push it for 3.11, because I prefer to revert
> > >> > efaa14c for 3.11 if that's necessary to make your broken box work as before.
> > >>
> > >> The issue happens in more than just "my broken box", and yes,
> > >> reverting that patch would help (in more than just my box), in the
> > >> sense that at least Linux won't boot into a black screen.
> > >>
> > >> But the backlight control still wouldn't work, as it hasn't worked
> > >> since v3.7, possibly in many ASUS laptops, for that you need more than
> > >> just reverting efaa14c.
> > >
> > > Yes, last time it worked in 3.6 and in particular it doesn't work in 3.10.
> > > My current goal is bring things back to the 3.10 state first, possibly without
> > > introducing any new problems, because we're kind of late in the cycle.
> > > That's better done by reverting stuff known to have introduced problems in
> > > the first place and not by doing things that may introduce more of them.
> > >
> > > And your blacklisting patch has potential to introduce problems. Your goal is
> > > to bring backlight control to the 3.6 state on that particular machine, but
> > > the blacklist is done at the *system* level and very well may affect more
> > > things than just backlight. You may not see any problems resulting from it
> > > and you may not care even if there are some, but other users of it may use
> > > different user space, for example, and may see problems that you're not seeing.
> > >
> > > That's why I'd very much prefer to do the revert at this point.
> >
> > Yes, that's fine, either the revert, or the patch I mentioned, or
> > something else, but something has to be done, and it was better to do
> > it in v3.11-rc4 than in v3.11-rc5, because that change itself can
> > cause further problems.
>
> A revert can be done in -rc5 just fine. If we don't have a working fix this
> week, I'll do the revert.
>
> > >> > Well, perhaps I just won't push it at all so that you actually can go and
> > >> > complain to Linus about that ...
> > >>
> > >> That is very responsible from you. Screw the users, right?
> > >
> > > No, that's not my goal, sorry for disappointing you.
> > >
> > > The problem is that I'm not really convinced about the validity of the
> > > blacklisting approach to begin with. As I said, the blacklisting is done
> > > on the system level and the goal is to work around backlight control problems.
> > > That sounds like a sledgehammer approach to me, which I don't really like.
> > > If the blacklisting was more targeted, done at the video driver level etc.,
> > > I wouldn't really have any concerns about it, but that's not the case.
> > >
> > > And since people evidently could live for over 6 months with the backlight
> > > control problems, maybe they'll survive some more time still and allow us to
> > > find a better approach?
> >
> > They probably can survive without Linux at all, that doesn't mean we
> > are doing our job.
> >
> > Let's do a though experiment, let's say you are right, and they can
> > survive the 6 months it would take you to find the "perfect" solution,
> > say in v3.13. What's wrong with having a partial solution in v3.12? If
> > the blacklisting doesn't work properly (there's absolutely no evidence
> > for that), then you revert it on v3.12.1.
> >
> > What's wrong with that approach?
>
> If the blacklisting leads to problems, they may not be reported in the 3.12
> time frame, but much later. For example because people won't realize that
> the problems are caused by the blacklisting until much much later. And then
> we'll be in a spot where whatever we do will break things for someone.
>
> And we had situations like that in the past, which is the source of my concern.
> You obviously don't have that experience, or you won't be so eager to inflict
> the blacklisting on everyone.
>
> Anyway, as you know, but conveniently don't mention, I asked some experienced
> people for opinions about that. If they agree with you, we will add the
> blacklist. If they don't, we won't add it.
>
> Rafael
>
I am opposed to this patch. On ThinkPad X230 I had problems with it.
Felipe, come over to dark side. They have cookies.
--
Igor Gnatenko
Fedora release 19 (Schrödinger’s Cat)
Linux 3.10.4-300.fc19.x86_64
On Sat, Aug 3, 2013 at 6:54 AM, Rafael J. Wysocki <[email protected]> wrote:
> On Friday, August 02, 2013 08:48:09 PM Felipe Contreras wrote:
>> Yes, that's fine, either the revert, or the patch I mentioned, or
>> something else, but something has to be done, and it was better to do
>> it in v3.11-rc4 than in v3.11-rc5, because that change itself can
>> cause further problems.
>
> A revert can be done in -rc5 just fine. If we don't have a working fix this
> week, I'll do the revert.
I think you are waiting for miracles. But whatever.
>> Let's do a though experiment, let's say you are right, and they can
>> survive the 6 months it would take you to find the "perfect" solution,
>> say in v3.13. What's wrong with having a partial solution in v3.12? If
>> the blacklisting doesn't work properly (there's absolutely no evidence
>> for that), then you revert it on v3.12.1.
>>
>> What's wrong with that approach?
>
> If the blacklisting leads to problems, they may not be reported in the 3.12
> time frame, but much later. For example because people won't realize that
> the problems are caused by the blacklisting until much much later. And then
> we'll be in a spot where whatever we do will break things for someone.
The key word is *may*, you don't *know*. Why do you insist in
committing this reification fallacy?
This threat is not real, it's theoretical.
But let's suppose you are right, and there are issues, and those don't
get reported in v3.12. That is actually GOOD, if people don't report
issues, it means the issues are not that big, or not even *there*.
And no, we won't be in a spot where whatever we do will break things,
because if the intel backlight driver works correctly, that solution
would work for everyone. And if it doesn't, we should stay with what
works best.
> And we had situations like that in the past, which is the source of my concern.
> You obviously don't have that experience, or you won't be so eager to inflict
> the blacklisting on everyone.
>
> Anyway, as you know, but conveniently don't mention, I asked some experienced
> people for opinions about that. If they agree with you, we will add the
> blacklist. If they don't, we won't add it.
Again, screw the users. We are stuck with broken backlight for several
more months to come. Great.
--
Felipe Contreras
On Sat, Aug 3, 2013 at 11:08 AM, Igor Gnatenko
<[email protected]> wrote:
> I am opposed to this patch. On ThinkPad X230 I had problems with it.
> Felipe, come over to dark side. They have cookies.
And v3.11-rc3 works's fine out-of-the box?
--
Felipe Contreras
On Saturday, August 03, 2013 03:20:22 PM Felipe Contreras wrote:
> On Sat, Aug 3, 2013 at 6:54 AM, Rafael J. Wysocki <[email protected]> wrote:
> > On Friday, August 02, 2013 08:48:09 PM Felipe Contreras wrote:
>
> >> Yes, that's fine, either the revert, or the patch I mentioned, or
> >> something else, but something has to be done, and it was better to do
> >> it in v3.11-rc4 than in v3.11-rc5, because that change itself can
> >> cause further problems.
> >
> > A revert can be done in -rc5 just fine. If we don't have a working fix this
> > week, I'll do the revert.
>
> I think you are waiting for miracles. But whatever.
>
> >> Let's do a though experiment, let's say you are right, and they can
> >> survive the 6 months it would take you to find the "perfect" solution,
> >> say in v3.13. What's wrong with having a partial solution in v3.12? If
> >> the blacklisting doesn't work properly (there's absolutely no evidence
> >> for that), then you revert it on v3.12.1.
> >>
> >> What's wrong with that approach?
> >
> > If the blacklisting leads to problems, they may not be reported in the 3.12
> > time frame, but much later. For example because people won't realize that
> > the problems are caused by the blacklisting until much much later. And then
> > we'll be in a spot where whatever we do will break things for someone.
>
> The key word is *may*, you don't *know*. Why do you insist in
> committing this reification fallacy?
>
> This threat is not real, it's theoretical.
I believe it is real. Igor has told you that already, hasn't he?
> But let's suppose you are right, and there are issues, and those don't
> get reported in v3.12. That is actually GOOD, if people don't report
> issues, it means the issues are not that big, or not even *there*.
You don't even realize how wrong you are. The issues that aren't visible
in testing from the start are often much *worse* than those we can see
immediately, because usually they are much more difficult to fix and they
cause much more pain overall as a result.
But I'm not sure why I'm still trying to explain things to you, because you
don't understand basic stuff.
> And no, we won't be in a spot where whatever we do will break things,
> because if the intel backlight driver works correctly, that solution
> would work for everyone. And if it doesn't, we should stay with what
> works best.
>
> > And we had situations like that in the past, which is the source of my concern.
> > You obviously don't have that experience, or you won't be so eager to inflict
> > the blacklisting on everyone.
> >
> > Anyway, as you know, but conveniently don't mention, I asked some experienced
> > people for opinions about that. If they agree with you, we will add the
> > blacklist. If they don't, we won't add it.
>
> Again, screw the users. We are stuck with broken backlight for several
> more months to come. Great.
Whatever you are thinking you will achieve this way, it doesn't work.
You seem to believe that the more you press people, the more they are likely
to do what you want. Maybe that belief is a result of your previous
experience, but this is not helping you here.
Decisions made under pressure usually lead to wrong choices, so I avoid that
as much as I can. As a result, the more you're pressing me, the more I'm
concerned about the drawbacks and the less convincing you are to me.
Consider this before you reply.
Rafael
--
I speak only for myself.
Rafael J. Wysocki, Intel Open Source Technology Center.
On Sat, Aug 3, 2013 at 4:59 PM, Rafael J. Wysocki <[email protected]> wrote:
> On Saturday, August 03, 2013 03:20:22 PM Felipe Contreras wrote:
>> On Sat, Aug 3, 2013 at 6:54 AM, Rafael J. Wysocki <[email protected]> wrote:
>> > On Friday, August 02, 2013 08:48:09 PM Felipe Contreras wrote:
>>
>> >> Yes, that's fine, either the revert, or the patch I mentioned, or
>> >> something else, but something has to be done, and it was better to do
>> >> it in v3.11-rc4 than in v3.11-rc5, because that change itself can
>> >> cause further problems.
>> >
>> > A revert can be done in -rc5 just fine. If we don't have a working fix this
>> > week, I'll do the revert.
>>
>> I think you are waiting for miracles. But whatever.
>>
>> >> Let's do a though experiment, let's say you are right, and they can
>> >> survive the 6 months it would take you to find the "perfect" solution,
>> >> say in v3.13. What's wrong with having a partial solution in v3.12? If
>> >> the blacklisting doesn't work properly (there's absolutely no evidence
>> >> for that), then you revert it on v3.12.1.
>> >>
>> >> What's wrong with that approach?
>> >
>> > If the blacklisting leads to problems, they may not be reported in the 3.12
>> > time frame, but much later. For example because people won't realize that
>> > the problems are caused by the blacklisting until much much later. And then
>> > we'll be in a spot where whatever we do will break things for someone.
>>
>> The key word is *may*, you don't *know*. Why do you insist in
>> committing this reification fallacy?
>>
>> This threat is not real, it's theoretical.
>
> I believe it is real.
That is called wishful thinking. Believing so doesn't make it so.
> Igor has told you that already, hasn't he?
He said he "had problems", that doesn't mean much. What kind of
problems? Did he have those problems in v3.10? Does v3.11-rc3 work
correctly? Did he boot without any boot arguments?
"I had problems" is almost meaningless.
>> But let's suppose you are right, and there are issues, and those don't
>> get reported in v3.12. That is actually GOOD, if people don't report
>> issues, it means the issues are not that big, or not even *there*.
>
> You don't even realize how wrong you are. The issues that aren't visible
> in testing from the start are often much *worse* than those we can see
> immediately, because usually they are much more difficult to fix and they
> cause much more pain overall as a result.
How convenient. In other words; there's absolutely no empirical way to
prove you wrong.
It's like trying to prove that your invisible pink unicorn doesn't exist.
If we don't find evidence of problems, that is evidence that there are
no problems. And even if there are "invisible" "worse" issues, it
doesn't matter, because you will fix them properly in six months,
right?
I'd say, fix the visible (aka. real) issues, don't worry about the
invisible (aka. imaginary) ones. Worry when they are visible.
>> And no, we won't be in a spot where whatever we do will break things,
>> because if the intel backlight driver works correctly, that solution
>> would work for everyone. And if it doesn't, we should stay with what
>> works best.
>>
>> > And we had situations like that in the past, which is the source of my concern.
>> > You obviously don't have that experience, or you won't be so eager to inflict
>> > the blacklisting on everyone.
>> >
>> > Anyway, as you know, but conveniently don't mention, I asked some experienced
>> > people for opinions about that. If they agree with you, we will add the
>> > blacklist. If they don't, we won't add it.
>>
>> Again, screw the users. We are stuck with broken backlight for several
>> more months to come. Great.
>
> Whatever you are thinking you will achieve this way, it doesn't work.
It is the reality: v3.7 is broken, v3.8 is broken, v3.9 is broken,
v3.10 is broken, v3.11 is going to be broken, v3.12 will probably be
broken too, and perhaps even v3.13.
Who benefits from this?
--
Felipe Contreras
On Saturday, August 03, 2013 05:06:10 PM Felipe Contreras wrote:
> On Sat, Aug 3, 2013 at 4:59 PM, Rafael J. Wysocki <[email protected]> wrote:
[...]
> > Whatever you are thinking you will achieve this way, it doesn't work.
>
> It is the reality: v3.7 is broken, v3.8 is broken, v3.9 is broken,
> v3.10 is broken, v3.11 is going to be broken, v3.12 will probably be
> broken too, and perhaps even v3.13.
Be precise and say "backlight control on a number of machines in broken in
those kernels". Yes, it is. It needs to be fixed. Not necessarily your way,
though.
> Who benefits from this?
Clearly, no one.
And who benefits from your "crusade"?
Again, no one.
On Sat, Aug 3, 2013 at 5:21 PM, Rafael J. Wysocki <[email protected]> wrote:
> On Saturday, August 03, 2013 05:06:10 PM Felipe Contreras wrote:
>> On Sat, Aug 3, 2013 at 4:59 PM, Rafael J. Wysocki <[email protected]> wrote:
>
> [...]
>
>> > Whatever you are thinking you will achieve this way, it doesn't work.
>>
>> It is the reality: v3.7 is broken, v3.8 is broken, v3.9 is broken,
>> v3.10 is broken, v3.11 is going to be broken, v3.12 will probably be
>> broken too, and perhaps even v3.13.
>
> Be precise and say "backlight control on a number of machines in broken in
> those kernels". Yes, it is. It needs to be fixed. Not necessarily your way,
> though.
"My" way, can be done *today*. "Your" way can be done whenever it's ready.
>> Who benefits from this?
>
> Clearly, no one.
>
> And who benefits from your "crusade"?
Who benefits from yours?
It's all very simple; we ask the owners of these machines if
acpi_osi="!Windows 2012" makes things work better, if they do, they go
into the blacklist, if not, they don't. That would fix the problems
for these machines *today*. If later it turns out there are other
issues introduced, they get removed, just like you removed the
intel_backlight switch patch. Igor Gnatenko said he had problems, but
didn't mention which problem. In bug #51231, tons of people reported
that things improved for ThinkPad X230.
And when the proper fix is done, everyone will be happy and we can
drop the blacklist.
Everybody benefits this way.
--
Felipe Contreras
On Sat, 2013-08-03 at 15:21 -0500, Felipe Contreras wrote:
> On Sat, Aug 3, 2013 at 11:08 AM, Igor Gnatenko
> <[email protected]> wrote:
>
> > I am opposed to this patch. On ThinkPad X230 I had problems with it.
> > Felipe, come over to dark side. They have cookies.
>
> And v3.11-rc3 works's fine out-of-the box?
>
rc2 work's fine. Since rc3 Rafael reverted patch and I think backlight
broken again (I don't have time to check rc3 yet).
--
Igor Gnatenko
Fedora release 19 (Schrödinger’s Cat)
Linux 3.10.4-300.fc19.x86_64
On Sat, Aug 3, 2013 at 6:27 PM, Igor Gnatenko
<[email protected]> wrote:
> On Sat, 2013-08-03 at 15:21 -0500, Felipe Contreras wrote:
>> On Sat, Aug 3, 2013 at 11:08 AM, Igor Gnatenko
>> <[email protected]> wrote:
>>
>> > I am opposed to this patch. On ThinkPad X230 I had problems with it.
>> > Felipe, come over to dark side. They have cookies.
>>
>> And v3.11-rc3 works's fine out-of-the box?
>>
>
> rc2 work's fine. Since rc3 Rafael reverted patch and I think backlight
> broken again (I don't have time to check rc3 yet).
You think?
We are talking about this patch [1]. Did you apply that patch on top
of rc3 and booted without any arguments?
If you did, what problems *exactly* did you have?
[1] https://bugzilla.kernel.org/attachment.cgi?id=107084&action=diff&context=patch&collapsed=&headers=1&format=raw
--
Felipe Contreras