Linux 2.6.23-rc2

Linux 2.6.23-rc2

[Linus Torvalds]

So I tried to hold people to the merge window, and said no to a few pull 
requests, but this whole "-rc2 is the new -rc1" thing is a disease, and 
not only is -rc2 late, it's bigger than it should be. Oh, well.

A lot of the changes are small, and a lot of them really are fixes, but 
there's a MIPS merge in there too, and some absolutely _huge_ diffs due to 
some drivers undergoing Lindent cleanups (28 _thousand_ lines changes in 
advansys.c, and the PNP files got Lindented too, although those weren't 
nearly as big).

But if you ignore the Lindent changes, the MIPS merge, the lguest 
documentation updates, and the MPT fusion driver changes, and the 
removal of the broken arm26 support, the rest of the changes really aren't 
that big.

But there's still a lot of those mostly small things all over. And the 
ShortLog is too large to post. But the full log along with the customary 
tar-balls and patches are out there on kernel.org. And as usual, the git 
tree gives you the goods if you just do

	git shortlog v2.6.23-rc1..

(the most interesting statistic from there is that we apparently had more 
than 250 people involved in just the -rc1 to -rc2 timeframe. Impressively 
spread out, in other words)

			Linus

Re: Linux 2.6.23-rc2

[david]

On Fri, 3 Aug 2007, Linus Torvalds wrote:

> So I tried to hold people to the merge window, and said no to a few pull
> requests, but this whole "-rc2 is the new -rc1" thing is a disease, and
> not only is -rc2 late, it's bigger than it should be. Oh, well.

I don't think this is new, -rc1 has always been a mid-merge sync point as 
much as (or more then) a release candidate. I can't think of any -rc2s 
that haven't included fairly significant merges since -rc1. now some of 
the -rc1s have been more useable then others, and this series does look 
like it's going to be rougher and longer then most (due in large part to 
the scheduler changes), but it's more a difference in degree then in type.

David Lang

Re: Linux 2.6.23-rc2

[Jeff Chua]

On 8/4/07, Linus Torvalds <torvalds@linux-foundation.org> wrote:

> A lot of the changes are small, and a lot of them really are fixes, but
> there's a MIPS merge in there too, and some absolutely _huge_ diffs due to
> some drivers undergoing Lindent cleanups (28 _thousand_ lines changes in
> advansys.c, and the PNP files got Lindented too, although those weren't
> nearly as big).

After resume from s2ram or switching to console from X, my console is
messed up on rc1 and rc2. Is there a fix for this?

Thanks,
Jeff.

Re: Linux 2.6.23-rc2

[Jeff Chua]

On 8/4/07, Jeff Chua <jeff.chua.linux@gmail.com> wrote:
> On 8/4/07, Linus Torvalds <torvalds@linux-foundation.org> wrote:

> After resume from s2ram or switching to console from X, my console is
> messed up on rc1 and rc2. Is there a fix for this?

This is on IBM X60. i915 chipset. No problem on 2.6.22. If this is a
known problem, than I don't need to bisect all over again.

Thanks,
Jeff.

Re: Linux 2.6.23-rc2

[Jeff Chua]

On 8/4/07, Jeff Chua <jeff.chua.linux@gmail.com> wrote:

> > After resume from s2ram or switching to console from X, my console is
> > messed up on rc1 and rc2. Is there a fix for this?
>
> This is on IBM X60. i915 chipset. No problem on 2.6.22. If this is a
> known problem, than I don't need to bisect all over again.

I managed to bisect down to this commit. Without this, console screen
can resume without video mess.

Thanks,
Jeff.

4fd06960f120e02e9abc802a09f9511c400042a5 is first bad commit
commit 4fd06960f120e02e9abc802a09f9511c400042a5
Author: H. Peter Anvin <hpa@zytor.com>
Date:   Wed Jul 11 12:18:56 2007 -0700

    Use the new x86 setup code for i386

    This patch hooks the new x86 setup code into the Makefile machinery.  It
    also adapts boot/tools/build.c to a two-file (as opposed to three-file)
    universe, and simplifies it substantially.

    Signed-off-by: H. Peter Anvin <hpa@zytor.com>
    Signed-off-by: Linus Torvalds <torvalds@linux-foundation.org>

:040000 040000 6560eb5b7e40d93813276544bced8c478f9067f5
fe5f90d9ca08e526559815789175602ba2c51743 M      arch

Re: Linux 2.6.23-rc2

[Linus Torvalds]

On Sat, 4 Aug 2007, Jeff Chua wrote:
>
> On 8/4/07, Jeff Chua <jeff.chua.linux@gmail.com> wrote:
> > 
> > > After resume from s2ram or switching to console from X, my console is
> > > messed up on rc1 and rc2. Is there a fix for this?
> >
> > This is on IBM X60. i915 chipset. No problem on 2.6.22. If this is a
> > known problem, than I don't need to bisect all over again.
> 
> I managed to bisect down to this commit. Without this, console screen
> can resume without video mess.

[ The commit being 4fd06960f120e02e9abc802a09f9511c400042a5: "Use the new 
  x86 setup code for i386" ]

Very interesting. 

Jeff - do I understand correctly that the "or" means that even *without* a 
suspend-to-ram sequence, and just by going into X and then going back to 
text-mode, the screen is corrupt?

I just want to make sure that there is no suspend-related activity 
required for this at all, and the only common issue is probably just that 
suspend ends up *also* triggering the X mode-setting at resume..

If so, the most likely thing is that we use a different video mode at 
boot, and while it may look similar, it's enough to confuse X. Not 
entirely surprising: X tends to be easily confused, and some VGA registers 
are write-only, so restoring modes can be surprisingly hard.

The other possibility is that the new code sets the same mode, but doesn't 
set some memory value or other that the kernel used to see, and that X 
queried to figure out the mode (ie likely some EDD info-block or other). I 
thought that the X server did all that on its own these days, but that may 
be just the newer "intel" driver, not the older "i810" driver that you 
probably use.

(Side note: if you have a modern distro, you might try to change the line 
that says

	Driver "i810"

in the /etc/X11/xorg.conf to say

	Driver "intel"

instead - just to check. However, the bug that triggered this 
obviously needs to be fixed regardless).

Peter, any ideas?

		Linus

Re: Linux 2.6.23-rc2

[H. Peter Anvin]

Linus Torvalds wrote:
> 
> On Sat, 4 Aug 2007, Jeff Chua wrote:
>> On 8/4/07, Jeff Chua <jeff.chua.linux@gmail.com> wrote:
>>>> After resume from s2ram or switching to console from X, my console is
>>>> messed up on rc1 and rc2. Is there a fix for this?
>>> This is on IBM X60. i915 chipset. No problem on 2.6.22. If this is a
>>> known problem, than I don't need to bisect all over again.
>> I managed to bisect down to this commit. Without this, console screen
>> can resume without video mess.
> 
> [ The commit being 4fd06960f120e02e9abc802a09f9511c400042a5: "Use the new 
>   x86 setup code for i386" ]
> 
> Very interesting. 
> 
> Jeff - do I understand correctly that the "or" means that even *without* a 
> suspend-to-ram sequence, and just by going into X and then going back to 
> text-mode, the screen is corrupt?

Also, can you please describe "messed up" in more detail?  We had one
report of "screen messed up" already that did get fixed
(CONFIG_FIRMWARE_EDID not working.)

Are you using the VGA console or a framebuffer console?

Also, please submit your .config and kernel command line.

	-=hpa

Re: Linux 2.6.23-rc2

[Antonino A. Daplas]

On Sat, 2007-08-04 at 11:06 -0700, H. Peter Anvin wrote:
> Linus Torvalds wrote:
> > 
> > On Sat, 4 Aug 2007, Jeff Chua wrote:
> >> On 8/4/07, Jeff Chua <jeff.chua.linux@gmail.com> wrote:
> >>>> After resume from s2ram or switching to console from X, my console is
> >>>> messed up on rc1 and rc2. Is there a fix for this?
> >>> This is on IBM X60. i915 chipset. No problem on 2.6.22. If this is a
> >>> known problem, than I don't need to bisect all over again.
> >> I managed to bisect down to this commit. Without this, console screen
> >> can resume without video mess.
> > 
> > [ The commit being 4fd06960f120e02e9abc802a09f9511c400042a5: "Use the new 
> >   x86 setup code for i386" ]
> > 
> > Very interesting. 
> > 
> > Jeff - do I understand correctly that the "or" means that even *without* a 
> > suspend-to-ram sequence, and just by going into X and then going back to 
> > text-mode, the screen is corrupt?
> 
> Also, can you please describe "messed up" in more detail?  We had one
> report of "screen messed up" already that did get fixed
> (CONFIG_FIRMWARE_EDID not working.)

I believe this is the case where VBE DDC reading is non-contributory.

> 
> Are you using the VGA console or a framebuffer console?
> 
> Also, please submit your .config and kernel command line.

The dmesg output, the X logs and the s2ram options will also be useful.

Tony

Re: Linux 2.6.23-rc2

[Jeff Chua]

On 8/5/07, H. Peter Anvin <hpa@zytor.com> wrote:

> Also, can you please describe "messed up" in more detail?

The screen went into some graphic mode that can't be reset no matter
what I tried (stty reset). I see all kinds of ramdom pattern/color
everywhere. Then typing "startx" would get in X just fine. But trying
to get back to console (ALT F1) or (Ctrl ALT BackSpace) would still
end up with the messed-up console.

> We had one report of "screen messed up" already that did get fixed
> (CONFIG_FIRMWARE_EDID not working.)

How can I try this?

> Are you using the VGA console or a framebuffer console?

VGA console.

> Also, please submit your .config and kernel command line.

I'll get this to you later today. Don't have my PC with me now.

Thanks,
Jeff.

Re: Linux 2.6.23-rc2

[H. Peter Anvin]

Jeff Chua wrote:
> On 8/5/07, H. Peter Anvin <hpa@zytor.com> wrote:
> 
>> Also, can you please describe "messed up" in more detail?
> 
> The screen went into some graphic mode that can't be reset no matter
> what I tried (stty reset). I see all kinds of ramdom pattern/color
> everywhere. Then typing "startx" would get in X just fine. But trying
> to get back to console (ALT F1) or (Ctrl ALT BackSpace) would still
> end up with the messed-up console.
> 

>> Are you using the VGA console or a framebuffer console?
>
> VGA console.

Okay, since you're using VGA console this means suspend-to-ram isn't
restoring the mode.

Does it matter if you suspend from inside X or not?

>> We had one report of "screen messed up" already that did get fixed
>> (CONFIG_FIRMWARE_EDID not working.)
> 
> How can I try this?

The patch for this is in -rc2.

	-hpa

Re: Linux 2.6.23-rc2

[Jeff Chua]

On 8/5/07, H. Peter Anvin <hpa@zytor.com> wrote:

> Okay, since you're using VGA console this means suspend-to-ram isn't
> restoring the mode.
> Does it matter if you suspend from inside X or not?

Just tested it. It doesn't matter... text console still messed up. X
is ok after resume.


Thanks,
Jeff.

Re: Linux 2.6.23-rc2

[David Weinehall]

On Sun, Aug 05, 2007 at 07:52:07PM +0800, Jeff Chua wrote:
> On 8/5/07, H. Peter Anvin <hpa@zytor.com> wrote:
> 
> > Okay, since you're using VGA console this means suspend-to-ram isn't
> > restoring the mode.
> > Does it matter if you suspend from inside X or not?
> 
> Just tested it. It doesn't matter... text console still messed up. X
> is ok after resume.

Try adding acpi_sleep=s3_bios to your kernel boot options and see if it
helps.


Regards: David
-- 
 /) David Weinehall <tao@acc.umu.se> /) Northern lights wander      (\
//  Maintainer of the v2.0 kernel   //  Dance across the winter sky //
\)  http://www.acc.umu.se/~tao/    (/   Full colour fire           (/

Re: Linux 2.6.23-rc2

[Jeff Chua]

On 8/8/07, David Weinehall <tao@kernel.org> wrote:

> Try adding acpi_sleep=s3_bios to your kernel boot options and see if it
> helps.

I tried, but that didn't help.

Thanks,
Jeff.

Re: Linux 2.6.23-rc2

[Jeff Chua]

On 8/5/07, Linus Torvalds <torvalds@linux-foundation.org> wrote:

> Jeff - do I understand correctly that the "or" means that even *without* a
> suspend-to-ram sequence, and just by going into X and then going back to
> text-mode, the screen is corrupt?

I've done more tests. It seems that "suspend-to-ram" sequence is the
culprit. After resume, the text console is messed up. Not switching
X/console.

Boot up. Console -> X ok -> Console ok -> s2ram -> console bad -> X ok
-> console bad -> X ok.

> I just want to make sure that there is no suspend-related activity
> required for this at all, and the only common issue is probably just that
> suspend ends up *also* triggering the X mode-setting at resume..

It's suspend as indicated above.


> (Side note: if you have a modern distro, you might try to change the line
> that says
>         Driver "i810"
> in the /etc/X11/xorg.conf to say
>         Driver "intel"

I'll test this and get back.

Thanks,
Jeff.

Re: Linux 2.6.23-rc2

[Jeff Chua]

On 8/5/07, Linus Torvalds <torvalds@linux-foundation.org> wrote:

> I thought that the X server did all that on its own these days, but that may
> be just the newer "intel" driver, not the older "i810" driver that you
> probably use.

I've just checked. Upon boot-up into text-console (even without
starting X), suspend-to-ram and resume will still corrupt the display.

> (Side note: if you have a modern distro, you might try to change the line
> that says
>         Driver "i810"

I've try changing to "intel" and both still doesn't restore the
text-console. "X" restored ok. On my Xorg build, i810_drv.so is linked
to intel_drv.so.

I tried to "revert" the commit, but it doesn't look like it can be
done easily as there're changes after the commit that affected those 2
files.

If there's anything I can help to debug, please let me know.

Thanks,
Jeff.

Re: Linux 2.6.23-rc2

[Rafael J. Wysocki]

On Saturday, 4 August 2007 05:50, Linus Torvalds wrote:
> 
> So I tried to hold people to the merge window, and said no to a few pull 
> requests, but this whole "-rc2 is the new -rc1" thing is a disease, and 
> not only is -rc2 late, it's bigger than it should be. Oh, well.

Suspend and hibernation are busted on SMP x86_64, AFAICS.  My test boxes
don't resume.

2.6.23-rc1 and 2.6.23-rc1-mm2 both work just fine on the same machines, so
this has to be due to a recent change.  I'll bisect later today.

Greetings,
Rafael


-- 
"Premature optimization is the root of all evil." - Donald Knuth

Re: Linux 2.6.23-rc2

[Rafael J. Wysocki]

On Saturday, 4 August 2007 12:30, Rafael J. Wysocki wrote:
> On Saturday, 4 August 2007 05:50, Linus Torvalds wrote:
> > 
> > So I tried to hold people to the merge window, and said no to a few pull 
> > requests, but this whole "-rc2 is the new -rc1" thing is a disease, and 
> > not only is -rc2 late, it's bigger than it should be. Oh, well.
> 
> Suspend and hibernation are busted on SMP x86_64, AFAICS.  My test boxes
> don't resume.
> 
> 2.6.23-rc1 and 2.6.23-rc1-mm2 both work just fine on the same machines, so
> this has to be due to a recent change.  I'll bisect later today.

Well, fortunately there's nothing wrong with 2.6.23-rc2 in this respect and it
was my own patch that busted suspend and hibernation for me.  Specifically,
this one: http://lkml.org/lkml/2007/8/4/29 .

Greetings,
Rafael


-- 
"Premature optimization is the root of all evil." - Donald Knuth

"Badness at kernel/irq/resend.c:70" on boot - via-pmu?

[Paul Collins]

Hi Linus,

I got the message below on boot with 2.6.23-rc2 on my PowerBook.

I've Cc'd some powerpc folks because via_pmu_interrupt is in the
Macintosh PMU driver.

Hmm, I just looked back in my logs and I also got that message with
commit 7a883eaf62f4b943ebec738ce3b0796c67ef5d32.  Before that I used
6c8dca5d53f95009d4fff00195bf38f277dc4366 and there was no badness
message logged by that one.  There's only about 480 commits between
those two, so I can bisect it if necessary.

The call traces differ, so here are both messages.

v2.6.23-rc2:

    ------------[ cut here ]------------
    Badness at kernel/irq/resend.c:70
    NIP: c0054ca4 LR: c0054c78 CTR: c00162b0
    REGS: c0473d80 TRAP: 0700   Not tainted  (2.6.23-rc2-g036acf4f)
    MSR: 00021032 <ME,IR,DR>  CR: 42000024  XER: 00000000
    TASK = c04451e0[0] 'swapper' THREAD: c0472000
    GPR00: 00000001 c0473e30 c04451e0 00000178 0000002f 00600000 c0480000 0000002f 
    GPR08: 000186a0 c0480000 0048002f 00000400 00000000 00000000 00000000 00000000 
    GPR16: 00000000 00000000 00000000 00000000 00000000 40900000 00d3bbc0 00000000 
    GPR24: c0444000 c0480000 c0480000 c043b81c 00000001 0000002f 00024408 c044b1bc 
    NIP [c0054ca4] check_irq_resend+0x5c/0xc0
    LR [c0054c78] check_irq_resend+0x30/0xc0
    Call Trace:
    [c0473e30] [c0054c78] check_irq_resend+0x30/0xc0 (unreliable)
    [c0473e50] [c00547d0] enable_irq+0x84/0xa8
    [c0473e60] [c0220fec] via_pmu_interrupt+0x3d8/0xac0
    [c0473e90] [c0053dfc] handle_IRQ_event+0x4c/0xa0
    [c0473eb0] [c0055250] handle_fasteoi_irq+0xac/0x100
    [c0473ec0] [c0006528] do_IRQ+0x68/0xa8
    [c0473ed0] [c000ffe8] ret_from_except+0x0/0x14
    --- Exception: 501 at cpu_idle+0x88/0xd0
        LR = cpu_idle+0x88/0xd0
    [c0473f90] [c00090bc] cpu_idle+0xcc/0xd0 (unreliable)
    [c0473fa0] [c0351f9c] rest_init+0x58/0x68
    [c0473fb0] [c04189a0] start_kernel+0x260/0x274
    [c0473ff0] [00003860] 0x3860
    Instruction dump:
    4e800421 801f0000 3d20c005 57cb052a 39295030 2f0b0400 7f804800 419e0030 
    3d20c048 800994e4 7c000034 5400d97e <0f000000> 2f800000 41be0048 38000001 


7a883eaf62f4b943ebec738ce3b0796c67ef5d32:

    ------------[ cut here ]------------
    Badness at kernel/irq/resend.c:70
    NIP: c0054bfc LR: c0054bd0 CTR: c00162b0
    REGS: effc3e60 TRAP: 0700   Not tainted  (2.6.23-rc1-g6cc0258f)
    MSR: 00021032 <ME,IR,DR>  CR: 48000084  XER: 20000000
    TASK = effc17f0[1] 'swapper' THREAD: effc2000
    GPR00: 00000001 effc3f10 effc17f0 00000178 0000002f 00000000 c0470000 0000002f 
    GPR08: 000186a0 c0470000 0048002f 00000000 82000022 00000000 00000000 00000000 
    GPR16: 00000000 00000000 00000000 00000000 00000000 40900000 00d3ad48 00000000 
    GPR24: c0443000 c0470000 effc2000 c043ef4c 00000001 0000002f 00024008 c044a1bc 
    NIP [c0054bfc] check_irq_resend+0x5c/0xc0
    LR [c0054bd0] check_irq_resend+0x30/0xc0
    Call Trace:
    [effc3f10] [c0054bd0] check_irq_resend+0x30/0xc0 (unreliable)
    [effc3f30] [c0054728] enable_irq+0x84/0xa8
    [effc3f40] [c0220e74] via_pmu_interrupt+0x3d8/0xac0
    [effc3f70] [c0430f28] via_pmu_start+0x168/0x190
    [effc3f80] [c04171e4] kernel_init+0xc8/0x284
    [effc3ff0] [c0010800] kernel_thread+0x44/0x60
    Instruction dump:
    4e800421 801f0000 3d20c005 57cb052a 39294f88 2f0b0400 7f804800 419e0030 
    3d20c047 800974e4 7c000034 5400d97e <0f000000> 2f800000 41be0048 38000001 


-- 
Paul Collins
Wellington, New Zealand

Dag vijandelijk luchtschip de huismeester is dood

Re: "Badness at kernel/irq/resend.c:70" on boot - via-pmu?

[Linus Torvalds]

On Sun, 5 Aug 2007, Paul Collins wrote:
> 
> I got the message below on boot with 2.6.23-rc2 on my PowerBook.

It's a debug message, I think we need to remove it. It's trying to figure 
out what goes wrong with one particular machine, and I probably shouldn't 
have merged it for mainline.

Ignore it, it will be gone soon enough, and it should happen just once per 
boot.

		Linus

Re: "Badness at kernel/irq/resend.c:70" on boot - via-pmu?

[Benjamin Herrenschmidt]

On Sat, 2007-08-04 at 21:41 -0700, Linus Torvalds wrote:
> 
> On Sun, 5 Aug 2007, Paul Collins wrote:
> > 
> > I got the message below on boot with 2.6.23-rc2 on my PowerBook.
> 
> It's a debug message, I think we need to remove it. It's trying to figure 
> out what goes wrong with one particular machine, and I probably shouldn't 
> have merged it for mainline.
> 
> Ignore it, it will be gone soon enough, and it should happen just once per 
> boot.

Actually, it's interesting as that irq shouldn't hit that path :-) Not
critical (won't break anything), but still something I'll look into just
in case it hides something bad.

Cheers,
Ben.