Prev: Considerations on sched APIs under RT patch
Next: [PATCH 2/2] ehea: fix possible DLPAR/mem deadlock
From: Frans Pop on 19 Apr 2010 08:10
On Sunday 18 April 2010, you wrote:
> On Sat, 2010-04-17 at 17:18 +0200, Frans Pop wrote:
> > Initially all messages from init scripts are displayed correctly, but
> > after the init script to set up the VT1-VT6 is run, messages from init
> > scripts are no longer displayed. Instead the display is blank with
> > only a cursor.
> >
> > However, if I switch back to VT1 from X.Org after the boot has
> > completed, the missing messages are visible.
> >
> > System is x86_64 running Debian stable ("Lenny"). I'm using VESAFB
> > (vga=791) and no KMS.
> >
> > I've bisected this to the following commit:
> > commit 477346ff74f4c2aed50e8a0db96a61069f3e5b80
> > Author: Dave Airlie <airlied(a)redhat.com>
> > Date: Thu Jan 7 17:04:54 2010 +1000
> > x86-64: Allow fbdev primary video code
>
> Can you diff dmesg with/without this?

There is no relevant difference between the dmesg for 477346ff ("bisect-5":
bad) and its predecessor b0483e78 ("bisect-6": good). See attachment.

> It shouldn't do anything unless you have multiple framebuffer drivers.

Unfortunately "shouldn't" isn't always the same as "doesn't" :-)

$ cat /proc/fb
0 VESA VGA

00:02.0 VGA compatible controller [0300]: Intel Corporation Mobile
GM965/GL960 Integrated Graphics Controller [8086:2a02] (rev 0c)
00:02.1 Display controller [0380]: Intel Corporation Mobile
GM965/GL960 Integrated Graphics Controller [8086:2a03] (rev 0c)

Cheers,
FJP

From: Frans Pop on 19 Apr 2010 09:00
On Monday 19 April 2010, Frans Pop wrote:
> On Sunday 18 April 2010, Dave Airlie wrote:
> > On Sat, 2010-04-17 at 17:18 +0200, Frans Pop wrote:
> > > I've bisected this to the following commit:
> > > commit 477346ff74f4c2aed50e8a0db96a61069f3e5b80
> > > Author: Dave Airlie <airlied(a)redhat.com>
> > > Date: Thu Jan 7 17:04:54 2010 +1000
> > > x86-64: Allow fbdev primary video code

Hmm. A straight revert of that commit on top of -rc4 does not fix the
problem. I'll investigate a bit more.
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo(a)vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
From: Frans Pop on 30 Apr 2010 14:50
On Thursday 29 April 2010, Frans Pop wrote:
> * commit eec9fe7d1ab4a0dfac4cb43047a7657fffd0002f
> Author: Ari Entlich <atrigent(a)ccs.neu.edu>
> tty: Add a new VT mode which is like VT_PROCESS but doesn't
> require a VT_RELDISP
>
> The last one is probably the most likely as the issue occurs after an
> init script loops over all VTs to run 'consolechars' and/or 'charset'.

I just see this patch has already been reverted, so that can't be it.
I'm still seeing the problem with v2.6.34-rc5-270-gbc113f1.
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo(a)vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
 | 
Pages: 1
Prev: Considerations on sched APIs under RT patch
Next: [PATCH 2/2] ehea: fix possible DLPAR/mem deadlock