This message contains a list of some post-2.6.36 regressions introduced before
2.6.37, for which there are no fixes in the mainline known to the tracking team.
If any of them have been fixed already, please let us know.
If you know of any other unresolved post-2.6.36 regressions, please let us know
either and we'll add them to the list. Also, please let us know if any
of the entries below are invalid.
Each entry from the list will be sent additionally in an automatic reply to
this message with CCs to the people involved in reporting and handling the
issue.
Listed regressions statistics:
Date Total Pending Unresolved
----------------------------------------
2011-02-03 118 36 31
2010-12-30 85 32 26
2010-12-19 73 28 24
2010-12-03 55 25 19
2010-11-19 39 29 25
Unresolved regressions
----------------------
Bug-Entry : http://bugzilla.kernel.org/show_bug.cgi?id=27892
Subject : SNB: GPU hang with Slip xscreensaver
Submitter : Takashi Iwai <[email protected]>
Date : 2011-01-31 12:06 (3 days old)
Bug-Entry : http://bugzilla.kernel.org/show_bug.cgi?id=27842
Subject : [regression?] hang with 2.6.37 on a BTRFS test machine
Submitter : Martin Steigerwald <[email protected]>
Date : 2011-01-23 12:06 (11 days old)
Message-ID : <[email protected]>
References : http://marc.info/?l=linux-kernel&m=129578445613283&w=2
Bug-Entry : http://bugzilla.kernel.org/show_bug.cgi?id=27642
Subject : 2.6.37 says WARNING: at arch/x86/kernel/apic/apic.c:1287 setup_local_APIC+0x18f/0x263()
Submitter : Rob Landley <[email protected]>
Date : 2011-01-18 13:11 (16 days old)
Message-ID : <[email protected]>
References : http://marc.info/?l=linux-kernel&m=129535632319892&w=2
Bug-Entry : http://bugzilla.kernel.org/show_bug.cgi?id=27532
Subject : ath9k prevents CPU from entering lower C-states
Submitter : Thomas Bächler <[email protected]>
Date : 2011-01-24 22:43 (10 days old)
Bug-Entry : http://bugzilla.kernel.org/show_bug.cgi?id=27402
Subject : Atheros adapter no longer loads firmware
Submitter : Michal Vaner <[email protected]>
Date : 2011-01-23 15:29 (11 days old)
First-Bad-Commit: http://git.kernel.org/linus/be93112accb42c5586a459683d71975cc70673ca
Bug-Entry : http://bugzilla.kernel.org/show_bug.cgi?id=27152
Subject : VGA output broken at cold boot
Submitter : Takashi Iwai <[email protected]>
Date : 2011-01-20 13:26 (14 days old)
Bug-Entry : http://bugzilla.kernel.org/show_bug.cgi?id=27132
Subject : flush-btrfs gets into an infinite loop
Submitter : Artem Anisimov <[email protected]>
Date : 2011-01-20 11:51 (14 days old)
Bug-Entry : http://bugzilla.kernel.org/show_bug.cgi?id=26942
Subject : radeon: screen distortion on resume
Submitter : Brett Witherspoon <[email protected]>
Date : 2011-01-17 13:23 (17 days old)
Bug-Entry : http://bugzilla.kernel.org/show_bug.cgi?id=26932
Subject : [SNB mobile] Oops in DRM intel driver, esp. during S3/S4 stress test
Submitter : Matthias Hopf <[email protected]>
Date : 2011-01-17 11:45 (17 days old)
Bug-Entry : http://bugzilla.kernel.org/show_bug.cgi?id=26842
Subject : [2.6.37 regression] threads with CPU affinity cannot be killed
Submitter : tim blechmann <[email protected]>
Date : 2011-01-16 13:39 (18 days old)
Bug-Entry : http://bugzilla.kernel.org/show_bug.cgi?id=26802
Subject : b43: Suspend failed
Submitter : Patrick Matthäi <[email protected]>
Date : 2011-01-15 18:56 (19 days old)
Bug-Entry : http://bugzilla.kernel.org/show_bug.cgi?id=26582
Subject : NULL pointer dereference on pipe creation
Submitter : Ferenc Wágner <[email protected]>
Date : 2011-01-12 13:30 (22 days old)
Bug-Entry : http://bugzilla.kernel.org/show_bug.cgi?id=26552
Subject : Screen flickering with 2.6.37 [ATI X1600]
Submitter : Andrea Iob <[email protected]>
Date : 2011-01-11 22:53 (23 days old)
Bug-Entry : http://bugzilla.kernel.org/show_bug.cgi?id=26212
Subject : kernel NULL pointer dereference in pxa3xx_nand_probe
Submitter : Sven Neumann <[email protected]>
Date : 2011-01-05 11:43 (29 days old)
Message-ID : <1294227801.3996.62.camel@sven>
References : http://marc.info/?l=linux-kernel&m=129422903703756&w=2
Bug-Entry : http://bugzilla.kernel.org/show_bug.cgi?id=26112
Subject : [LogFS] [2.6.37-rc8+] Kernel BUG at logfs/readwrite.c:297!
Submitter : Prasad Joshi <[email protected]>
Date : 2011-01-02 21:22 (32 days old)
Message-ID : <[email protected]>
References : http://marc.info/?l=linux-kernel&m=129400335910652&w=2
Bug-Entry : http://bugzilla.kernel.org/show_bug.cgi?id=26102
Subject : [2.6.37-rc8] BUG kmalloc-256: Poison overwritten.
Submitter : Pawel Sikora <[email protected]>
Date : 2010-12-30 15:08 (35 days old)
Message-ID : <[email protected]>
References : http://marc.info/?l=linux-kernel&m=129372388925679&w=2
Bug-Entry : http://bugzilla.kernel.org/show_bug.cgi?id=25922
Subject : IdeaPad Y530 brightness keys not functioning
Submitter : Tomasz <[email protected]>
Date : 2010-12-30 12:48 (35 days old)
Bug-Entry : http://bugzilla.kernel.org/show_bug.cgi?id=25832
Subject : kernel crashes upon resume if usb devices are removed when suspended
Submitter : rocko <[email protected]>
Date : 2010-12-29 11:47 (36 days old)
Bug-Entry : http://bugzilla.kernel.org/show_bug.cgi?id=25732
Subject : i915 turns picture green when display switched off-on
Submitter : Tõnu Raitviir <[email protected]>
Date : 2010-12-27 22:14 (38 days old)
First-Bad-Commit: http://git.kernel.org/linus/3c17fe4b8f40a112a85758a9ab2aebf772bdd647
Handled-By : Chris Wilson <[email protected]>
Bug-Entry : http://bugzilla.kernel.org/show_bug.cgi?id=25432
Subject : Alpha fails to build with gcc 4.4
Submitter : Ben Hutchings <[email protected]>
Date : 2010-12-22 01:55 (43 days old)
Bug-Entry : http://bugzilla.kernel.org/show_bug.cgi?id=25402
Subject : kernel (2.6.37-8-generic_amd64) panic on boot (with message "map_single: bounce buffer is not DMA'ble) - possible regression !!!
Submitter : carlos <[email protected]>
Date : 2010-12-21 19:58 (44 days old)
Bug-Entry : http://bugzilla.kernel.org/show_bug.cgi?id=25072
Subject : backlight level is not maintened during LID close/open
Submitter : Lukas Hejtmanek <[email protected]>
Date : 2010-12-17 11:56 (48 days old)
Bug-Entry : http://bugzilla.kernel.org/show_bug.cgi?id=24882
Subject : PM/Hibernate: Memory corruption patch introduces regression (2.6.36.2)
Submitter : <[email protected]>
Date : 2010-12-14 04:00 (51 days old)
Bug-Entry : http://bugzilla.kernel.org/show_bug.cgi?id=24822
Subject : Embedded DisplayPort is detected wrongly on HP ProBook 5320m
Submitter : Takashi Iwai <[email protected]>
Date : 2010-12-13 11:09 (52 days old)
Handled-By : Chris Wilson <[email protected]>
Bug-Entry : http://bugzilla.kernel.org/show_bug.cgi?id=24762
Subject : BUG at perf_ctx_adjust_freq (kernel/perf_event.c:1582)
Submitter : Chris Wilson <[email protected]>
Date : 2010-12-10 12:00 (55 days old)
Message-ID : <[email protected]>
References : http://marc.info/?l=linux-kernel&m=129198247531612&w=2
Bug-Entry : http://bugzilla.kernel.org/show_bug.cgi?id=24582
Subject : Kernel Oops at tty_buffer_request_room when using pppd program (2.6.37-rc4)
Submitter : baoyb <[email protected]>
Date : 2010-12-08 13:55 (57 days old)
Message-ID : <EF6DDE218DB34702B1FA84D6CD7EA771@baoyb>
References : http://marc.info/?l=linux-kernel&m=129181763525738&w=2
Bug-Entry : http://bugzilla.kernel.org/show_bug.cgi?id=22942
Subject : [2.6.37-rc1, OOM] virtblk: OOM in do_virtblk_request()
Submitter : Dave Chinner <[email protected]>
Date : 2010-11-05 1:30 (90 days old)
Message-ID : <20101105013003.GE13830@dastard>
References : http://marc.info/?l=linux-kernel&m=128892062917641&w=2
Bug-Entry : http://bugzilla.kernel.org/show_bug.cgi?id=22912
Subject : spi_lm70llp module crash on unload (2.6.37-rc1)
Submitter : Randy Dunlap <[email protected]>
Date : 2010-11-05 0:16 (90 days old)
Message-ID : <[email protected]>
References : http://marc.info/?l=linux-kernel&m=128891627913647&w=2
Bug-Entry : http://bugzilla.kernel.org/show_bug.cgi?id=22882
Subject : (2.6.37-rc1) amd64-agp module crashed on second load
Submitter : Randy Dunlap <[email protected]>
Date : 2010-11-05 0:13 (90 days old)
Message-ID : <[email protected]>
References : http://marc.info/?l=linux-kernel&m=128891605213447&w=2
Bug-Entry : http://bugzilla.kernel.org/show_bug.cgi?id=22642
Subject : 2.6.37-rc1: Disk takes 10 seconds to resume - MacBook2,1
Submitter : Tobias <[email protected]>
Date : 2010-11-10 19:33 (85 days old)
Bug-Entry : http://bugzilla.kernel.org/show_bug.cgi?id=22542
Subject : [2.6.37-rc1] drm:i195 errors
Submitter : Paul Rolland <[email protected]>
Date : 2010-11-02 14:58 (93 days old)
Message-ID : <[email protected]>
References : http://marc.info/?l=linux-kernel&m=128870991628970&w=2
Regressions with patches
------------------------
Bug-Entry : http://bugzilla.kernel.org/show_bug.cgi?id=27202
Subject : Remote control of saa7134-based tv card "ASUSTeK P7131 Hybrid" stopped working in 2.6.37
Submitter : <[email protected]>
Date : 2011-01-20 17:23 (14 days old)
First-Bad-Commit: http://git.kernel.org/linus/4651918a4afdd49bdea21d2f919b189ef17a6399
Patch : https://bugzilla.kernel.org/attachment.cgi?id=44532
Bug-Entry : http://bugzilla.kernel.org/show_bug.cgi?id=26242
Subject : BUG: unable to handle kernel NULL pointer dereference at (null)
Submitter : Steffen Michalke <[email protected]>
Date : 2011-01-06 20:59 (28 days old)
Patch : http://www.spinics.net/lists/linux-btrfs/msg08051.html
Bug-Entry : http://bugzilla.kernel.org/show_bug.cgi?id=25822
Subject : [BUG] kernel BUG at mm/truncate.c:479! on 2.6.37-rc8
Submitter : Gurudas Pai <[email protected]>
Date : 2010-12-29 6:58 (36 days old)
Message-ID : <[email protected]>
References : http://marc.info/?l=linux-kernel&m=129360511222037&w=2
Patch : https://lkml.org/lkml/2010/12/29/131
Bug-Entry : http://bugzilla.kernel.org/show_bug.cgi?id=25442
Subject : ixp4xx defines FREQ macro; conflicts with gspca/ov519 driver
Submitter : Ben Hutchings <[email protected]>
Date : 2010-12-22 02:02 (43 days old)
Handled-By : Ben Hutchings <[email protected]>
Patch : https://bugzilla.kernel.org/attachment.cgi?id=41252
Bug-Entry : http://bugzilla.kernel.org/show_bug.cgi?id=23472
Subject : 2.6.37-rc2 vs. 2.6.36 laptop backlight changes?
Submitter : Patrick Schaaf <[email protected]>
Date : 2010-11-17 13:41 (78 days old)
Message-ID : <1290001262.5727.2.camel@lat1>
References : http://marc.info/?l=linux-kernel&m=129000127920912&w=2
Handled-By : Indan Zupancic <[email protected]>
Patch : https://bugzilla.kernel.org/attachment.cgi?id=43482
For details, please visit the bug entries and follow the links given in
references.
As you can see, there is a Bugzilla entry for each of the listed regressions.
There also is a Bugzilla entry used for tracking the regressions introduced
between 2.6.36 and 2.6.37, unresolved as well as resolved, at:
http://bugzilla.kernel.org/show_bug.cgi?id=21782
Please let the tracking team know if there are any Bugzilla entries that
should be added to the list in there.
Thanks!
On Thu, Feb 3, 2011 at 5:05 PM, Keith Packard <[email protected]> wrote:
>
> The goal is to make it so that when you *do* set a mode, DPMS gets set
> to ON (as the monitor will actually be "on" at that point). Here's a
> patch which does the DPMS_ON precisely when setting a mode.
Ok, patch looks sane, but it does leave me with the "what about the
'fb_changed' case?" question. Is that case basically guaranteed to not
change any existing dpms state?
> (note, this patch compiles, but is otherwise only lightly tested).
Carlos? Takashi? Ignore my crazy patch, try this one instead. Does it
fix things for you?
Linus
On Fri, Feb 4, 2011 at 10:30 AM, Linus Torvalds
<[email protected]> wrote:
> On Thu, Feb 3, 2011 at 4:06 PM, Dave Airlie <[email protected]> wrote:
>>
>> If we are setting a mode on a connector it automatically will end up
>> in a DPMS on state,
>> so this seemed correct from what I can see.
>
> The more I look at that function, the more I disagree with you and
> with that patch.
>
> The code is just crazy.
Good point, I'm just trying to get -rc3 onto a machine where I can
reproduce this now, unfortunately that looks like the machine with the
1.8" disk, so this could take a little while.
hopefully Keith will decloak and tell us more.
Dave.
At Thu, 3 Feb 2011 17:11:14 -0800,
Linus Torvalds wrote:
>
> On Thu, Feb 3, 2011 at 5:05 PM, Keith Packard <[email protected]> wrote:
> >
> > The goal is to make it so that when you *do* set a mode, DPMS gets set
> > to ON (as the monitor will actually be "on" at that point). Here's a
> > patch which does the DPMS_ON precisely when setting a mode.
>
> Ok, patch looks sane, but it does leave me with the "what about the
> 'fb_changed' case?" question. Is that case basically guaranteed to not
> change any existing dpms state?
>
> > (note, this patch compiles, but is otherwise only lightly tested).
>
> Carlos? Takashi? Ignore my crazy patch, try this one instead. Does it
> fix things for you?
Yes, the patch fixes the issue with xrandr off and on.
However, another issue I reported in that bugzilla still remains:
namely, DPMS value returned via ioctl or obtained via sysfs is
inconsistent with the actually applied value. The reason is that
there are two places keeping the current DPMS values, in connector and
in crtc device properties. A similar fix like my patch in the
bugzilla would be still needed, I guess.
thanks,
Takashi
On Thursday, February 03, 2011, Takashi Iwai wrote:
> At Thu, 3 Feb 2011 07:42:05 -0800,
> Linus Torvalds wrote:
> >
> > On Thu, Feb 3, 2011 at 3:23 AM, Carlos R. Mafra <[email protected]> wrote:
> > > On Thu 3.Feb'11 at 1:03:41 +0100, Rafael J. Wysocki wrote:
> > >>
> > >> If you know of any other unresolved post-2.6.36 regressions, please let us know
> > >> either and we'll add them to the list. Also, please let us know if any
> > >> of the entries below are invalid.
> > >
> > > I'm sorry if I'm overlooking something, but as far as I can see the regression
> > > reported here:
> > >
> > > https://lkml.org/lkml/2011/1/24/457
> > >
> > > is not in the list (update on that report: reverting that commit on top of
> > > 2.6.37 fixes the issue).
> >
> > Ok, added Keith and Dave to the cc, since they are the signers of that commit.
> >
> > > After some time, I also ended up finding an earlier report in the kernel bugzilla
> > > which I think is the same regression (it was bisected to the same commit):
> > >
> > > https://bugzilla.kernel.org/show_bug.cgi?id=24982
> > >
> > > but I do not see it in the list either, even though it's marked as a
> > > regression in the bugzilla.
> > >
> > > The issue was also present in 2.6.38-rc2 last time I tested.
> >
> > Just to confirm, can you also check -rc3? I'm pretty sure nothing has
> > changed, but there were a few drm patches after -rc2, so it's alsways
> > good to double-check.
>
> The problem I reported in the bugzilla above is still present in
> 2.6.38-rc3. I'm pretty sure that's the same issue as Carlos' case.
I added https://bugzilla.kernel.org/show_bug.cgi?id=24982 to the list of
post-2.6.36 regressions for further tracking.
Thanks,
Rafael
On Thu, Feb 3, 2011 at 3:23 AM, Carlos R. Mafra <[email protected]> wrote:
> On Thu ?3.Feb'11 at ?1:03:41 +0100, Rafael J. Wysocki wrote:
>>
>> If you know of any other unresolved post-2.6.36 regressions, please let us know
>> either and we'll add them to the list. ?Also, please let us know if any
>> of the entries below are invalid.
>
> I'm sorry if I'm overlooking something, but as far as I can see the regression
> reported here:
>
> https://lkml.org/lkml/2011/1/24/457
>
> is not in the list (update on that report: reverting that commit on top of
> 2.6.37 fixes the issue).
Ok, added Keith and Dave to the cc, since they are the signers of that commit.
> After some time, I also ended up finding an earlier report in the kernel bugzilla
> which I think is the same regression (it was bisected to the same commit):
>
> https://bugzilla.kernel.org/show_bug.cgi?id=24982
>
> but I do not see it in the list either, even though it's marked as a
> regression in the bugzilla.
>
> The issue was also present in 2.6.38-rc2 last time I tested.
Just to confirm, can you also check -rc3? I'm pretty sure nothing has
changed, but there were a few drm patches after -rc2, so it's alsways
good to double-check.
Keithp?
Linus
On Fri, Feb 4, 2011 at 8:10 AM, Linus Torvalds
<[email protected]> wrote:
> On Thu, Feb 3, 2011 at 1:56 PM, Carlos Mafra <[email protected]> wrote:
>>>
>>> I added https://bugzilla.kernel.org/show_bug.cgi?id=24982 to the list of
>>> post-2.6.36 regressions for further tracking.
>>
>> I also tested on 2.6.38-rc3+ now and the issue is not solved,
>> just like Takashi expected.
>
> Hmm. That commit (bf9dc102e284) still reverts cleanly.
>
> Keith, Dave, should we just revert it? It's definitely a regression,
> and we do _not_ allow "fixes" to one thing that just causes a
> regression to another.
>
> Quite frankly, I think it's totally wrong to just blindly set DPMS
> status to ON like that. It's as wrong as it was to leave it off, and
> the regressions reported are basically mirror images of the exact same
> bug that that commit tried to fix.
>
> IOW, the commit message says:
>
> ? ?When setting a new crtc configuration, force the DPMS state of all
> ? ?connectors to ON. Otherwise, they'll be left at OFF and a future mode set
> ? ?that disables the specified connector will not turn the connector off.
>
> but setting it to ON doesn't actually _fix_ anything, because you just
> get the exact same issue in reverse, ie you just get
>
> ? .. and a future mode set ?that ENables the specified connector will
> ? ?not turn the connector ON.
If we are setting a mode on a connector it automatically will end up
in a DPMS on state,
so this seemed correct from what I can see.
A future mode set shouldn't ever not turn the connector on, since
modesetting is an implicit
DPMS,
It sounds like something more subtle than that, though I'm happy to
revert this for now, and let Keith
think about it a bit more.
Dave.
On Fri, Feb 4, 2011 at 11:11 AM, Linus Torvalds
<[email protected]> wrote:
> On Thu, Feb 3, 2011 at 5:05 PM, Keith Packard <[email protected]> wrote:
>>
>> The goal is to make it so that when you *do* set a mode, DPMS gets set
>> to ON (as the monitor will actually be "on" at that point). Here's a
>> patch which does the DPMS_ON precisely when setting a mode.
>
> Ok, patch looks sane, but it does leave me with the "what about the
> 'fb_changed' case?" question. Is that case basically guaranteed to not
> change any existing dpms state?
Yes its inconsistent behaviour but nothing in the fb_changed case will
affect the DPMS
state. I expect we should probably do that so all paths via that
function turn DPMS on,
and it'll be consistent, might be something for 39.
Dave.
On Thu, Feb 3, 2011 at 4:06 PM, Dave Airlie <[email protected]> wrote:
>
> If we are setting a mode on a connector it automatically will end up
> in a DPMS on state,
> so this seemed correct from what I can see.
The more I look at that function, the more I disagree with you and
with that patch.
The code is just crazy.
First off, it isn't even necessarily setting a mode to begin with,
because as far as I can tell. If the mode doesn't change, neither
mode_changed nor fb_changed will be true, afaik. There seems to be a
fair amount of code there explicitly to avoid changing modes if not
necessary.
But even _if_ we are setting a mode, if I read the code correctly, the
mode may be set to NULL - which seems to mean "turn it off". In which
case it looks to me that drm_helper_disable_unused_functions() will
actually do a
(*crtc_funcs->dpms)(crtc, DRM_MODE_DPMS_OFF);
call on the crtc in question. So then blindly just saying "it's mode
DRM_MODE_DPMS_ON" afterwards looks rather bogus to me.
_Maybe_ it would work if it was done before that whole
"disable_unused" logic. Or maybe it should just be done in
drm_crtc_helper_set_mode(), which is what actually sets the mode (but
there's the 'fb_changed' case too)
> A future mode set shouldn't ever not turn the connector on, since
> modesetting is an implicit
> DPMS,
>
> It sounds like something more subtle than that, though I'm happy to
> revert this for now, and let Keith
> think about it a bit more.
So I haven't heard anything from Keith. Keith? Just revert it? Or do
you have a patch for people to try?
Linus
On Thu, Feb 3, 2011 at 1:56 PM, Carlos Mafra <[email protected]> wrote:
>>
>> I added https://bugzilla.kernel.org/show_bug.cgi?id=24982 to the list of
>> post-2.6.36 regressions for further tracking.
>
> I also tested on 2.6.38-rc3+ now and the issue is not solved,
> just like Takashi expected.
Hmm. That commit (bf9dc102e284) still reverts cleanly.
Keith, Dave, should we just revert it? It's definitely a regression,
and we do _not_ allow "fixes" to one thing that just causes a
regression to another.
Quite frankly, I think it's totally wrong to just blindly set DPMS
status to ON like that. It's as wrong as it was to leave it off, and
the regressions reported are basically mirror images of the exact same
bug that that commit tried to fix.
IOW, the commit message says:
When setting a new crtc configuration, force the DPMS state of all
connectors to ON. Otherwise, they'll be left at OFF and a future mode set
that disables the specified connector will not turn the connector off.
but setting it to ON doesn't actually _fix_ anything, because you just
get the exact same issue in reverse, ie you just get
.. and a future mode set that ENables the specified connector will
not turn the connector ON.
instead. Which is exactly what Carlos and Takashi are reporting.
Maybe the right thing to do is to set it to 'unknown', something like this.
TOTALLY UNTESTED!
Linus
On Thu, Feb 3, 2011 at 2:10 PM, Linus Torvalds
<[email protected]> wrote:
>
> Maybe the right thing to do is to set it to 'unknown', something like this.
>
> TOTALLY UNTESTED!
Doing some grepping and "git blame", I found this: commit 032d2a0d068
("drm/i915: Prevent double dpms on") which took a very similar
approach, except it just uses "-1" directly instead of introducing
that DRM_MODE_DPMS_UNKNOWN concept.
So I suspect that my patch is going in the right direction, and
judging by the comments in that commit, we probably should do this
correctly at the dri level rather than have drivers see those stupid
"let's set dpms to the state that it was already in". But that very
much does require that kind of "UNKNOWN" state option.
So maybe we can get that patch tested (and acked if it works)? Carlos, Takashi?
Linus
On Thu 3.Feb'11 at 17:11:14 -0800, Linus Torvalds wrote:
> On Thu, Feb 3, 2011 at 5:05 PM, Keith Packard <[email protected]> wrote:
> >
> > The goal is to make it so that when you *do* set a mode, DPMS gets set
> > to ON (as the monitor will actually be "on" at that point). Here's a
> > patch which does the DPMS_ON precisely when setting a mode.
>
> Ok, patch looks sane, but it does leave me with the "what about the
> 'fb_changed' case?" question. Is that case basically guaranteed to not
> change any existing dpms state?
>
> > (note, this patch compiles, but is otherwise only lightly tested).
>
> Carlos? Takashi? Ignore my crazy patch, try this one instead. Does it
> fix things for you?
Yes! (tested on top of 2.6.38-rc3+).
Thanks to everyone involved!
At Thu, 3 Feb 2011 07:42:05 -0800,
Linus Torvalds wrote:
>
> On Thu, Feb 3, 2011 at 3:23 AM, Carlos R. Mafra <[email protected]> wrote:
> > On Thu 3.Feb'11 at 1:03:41 +0100, Rafael J. Wysocki wrote:
> >>
> >> If you know of any other unresolved post-2.6.36 regressions, please let us know
> >> either and we'll add them to the list. Also, please let us know if any
> >> of the entries below are invalid.
> >
> > I'm sorry if I'm overlooking something, but as far as I can see the regression
> > reported here:
> >
> > https://lkml.org/lkml/2011/1/24/457
> >
> > is not in the list (update on that report: reverting that commit on top of
> > 2.6.37 fixes the issue).
>
> Ok, added Keith and Dave to the cc, since they are the signers of that commit.
>
> > After some time, I also ended up finding an earlier report in the kernel bugzilla
> > which I think is the same regression (it was bisected to the same commit):
> >
> > https://bugzilla.kernel.org/show_bug.cgi?id=24982
> >
> > but I do not see it in the list either, even though it's marked as a
> > regression in the bugzilla.
> >
> > The issue was also present in 2.6.38-rc2 last time I tested.
>
> Just to confirm, can you also check -rc3? I'm pretty sure nothing has
> changed, but there were a few drm patches after -rc2, so it's alsways
> good to double-check.
The problem I reported in the bugzilla above is still present in
2.6.38-rc3. I'm pretty sure that's the same issue as Carlos' case.
thanks,
Takashi
On Thu 3.Feb'11 at 1:03:41 +0100, Rafael J. Wysocki wrote:
>
> If you know of any other unresolved post-2.6.36 regressions, please let us know
> either and we'll add them to the list. Also, please let us know if any
> of the entries below are invalid.
I'm sorry if I'm overlooking something, but as far as I can see the regression
reported here:
https://lkml.org/lkml/2011/1/24/457
is not in the list (update on that report: reverting that commit on top of
2.6.37 fixes the issue).
After some time, I also ended up finding an earlier report in the kernel bugzilla
which I think is the same regression (it was bisected to the same commit):
https://bugzilla.kernel.org/show_bug.cgi?id=24982
but I do not see it in the list either, even though it's marked as a
regression in the bugzilla.
The issue was also present in 2.6.38-rc2 last time I tested.
On Thu, Feb 3, 2011 at 8:09 PM, Rafael J. Wysocki <[email protected]> wrote:
> On Thursday, February 03, 2011, Takashi Iwai wrote:
>> At Thu, 3 Feb 2011 07:42:05 -0800,
>> Linus Torvalds wrote:
>> >
>> > On Thu, Feb 3, 2011 at 3:23 AM, Carlos R. Mafra <[email protected]> wrote:
>> > > On Thu ?3.Feb'11 at ?1:03:41 +0100, Rafael J. Wysocki wrote:
>> > Just to confirm, can you also check -rc3? I'm pretty sure nothing has
>> > changed, but there were a few drm patches after -rc2, so it's alsways
>> > good to double-check.
>>
>> The problem I reported in the bugzilla above is still present in
>> 2.6.38-rc3. ?I'm pretty sure that's the same issue as Carlos' case.
>
> I added https://bugzilla.kernel.org/show_bug.cgi?id=24982 to the list of
> post-2.6.36 regressions for further tracking.
I also tested on 2.6.38-rc3+ now and the issue is not solved,
just like Takashi expected.