linux-kernel.vger.kernel.org archive mirror
 help / color / mirror / Atom feed
* [Regression: 2.6.25-rc5: Blank Screen: Intel 945]
@ 2008-03-12 19:02 Justin Madru
  2008-03-12 19:36 ` Jesse Barnes
  0 siblings, 1 reply; 25+ messages in thread
From: Justin Madru @ 2008-03-12 19:02 UTC (permalink / raw)
  To: linux-kernel

Hi,

I'm not sure, but I think I've found a regression in the latest development kernel (2.6.25-rc5).
The problems don't happen when using the distro's 2.6.22 kernel (ubuntu 7.10), or when I was testing 2.6.23 and 2.6.24.

These are the problems I've been having:

1) Blank screen: Upon entering graphical mode the screen goes blank (black). It seems to happen when X is probing for the video modes.
Pressing ctrl+alt+f1 doesn't do anything, except "refresh" a black screen. The computer still works, and I can log in from GDM,
but I just can't see anything on the screen; I have to reboot.
The work around is that when the boot splash screen (usplash) is about halfway loaded I switch to the first terminal,
and everything is fine (or maybe that's just a coincidence).

2) Wireless errors: Upon connecting to a wireless router I get a flood of kernel messages that don't stop:
"kernel: wlan0_rename: RX too short data frame payload".
I do successfully connect. No workaround to stop the messages (while still having connection).

3) Flashing Red: When I shutdown, the screen flashes red several times before the shutdown splash screen shows up.

#1 and #3 happen at random. Although, It seems to happen more on the first boot up.
#2 consistently happens when connecting to my University's wireless; rarely (if ever) on my home router.

Relevant sysinfo (Dell Inspiron E1505; Intel T2080 @ 1.73GHz):
0b:00.0 Network controller: Intel Corporation PRO/Wireless 3945ABG Network Connection (rev 02)
00:02.0 VGA compatible controller: Intel Corporation Mobile 945GM/GMS, 943/940GML Express Integrated Graphics Controller (rev 03)
00:02.1 Display controller: Intel Corporation Mobile 945GM/GMS/GME, 943/940GML Express Integrated Graphics Controller (rev 03)

Could this be a regression? What can I do to help identify the problem?
I've tried to start analyzing the blank screen problem, so let's start there because I've already created a diff log report.

For a diff of my system logs for the blank screen problem see (104.61 KB):
http://jdserver.homelinux.org/linux/blank_screen_log_diff.txt

For full details about my system see (23.14 KB):
http://jdserver.homelinux.org/linux/sysinfo-2.6.25-rc5.txt

For my config file that I used see (40.84 KB):
http://jdserver.homelinux.org/linux/config-2.6.25-rc5

Hopefully this helps and I can get my problems solved.

Thanks


^ permalink raw reply	[flat|nested] 25+ messages in thread

* Re: [Regression: 2.6.25-rc5: Blank Screen: Intel 945]
  2008-03-12 19:02 [Regression: 2.6.25-rc5: Blank Screen: Intel 945] Justin Madru
@ 2008-03-12 19:36 ` Jesse Barnes
       [not found]   ` <47D8BF6A.9020905@gawab.com>
  0 siblings, 1 reply; 25+ messages in thread
From: Jesse Barnes @ 2008-03-12 19:36 UTC (permalink / raw)
  To: Justin Madru; +Cc: linux-kernel

On Wednesday, March 12, 2008 12:02 pm Justin Madru wrote:
> Hi,
>
> I'm not sure, but I think I've found a regression in the latest development
> kernel (2.6.25-rc5). The problems don't happen when using the distro's
> 2.6.22 kernel (ubuntu 7.10), or when I was testing 2.6.23 and 2.6.24.
>
> These are the problems I've been having:
>
> 1) Blank screen: Upon entering graphical mode the screen goes blank
> (black). It seems to happen when X is probing for the video modes. Pressing
> ctrl+alt+f1 doesn't do anything, except "refresh" a black screen. The
> computer still works, and I can log in from GDM, but I just can't see
> anything on the screen; I have to reboot.
> The work around is that when the boot splash screen (usplash) is about
> halfway loaded I switch to the first terminal, and everything is fine (or
> maybe that's just a coincidence).
>
> 2) Wireless errors: Upon connecting to a wireless router I get a flood of
> kernel messages that don't stop: "kernel: wlan0_rename: RX too short data
> frame payload".
> I do successfully connect. No workaround to stop the messages (while still
> having connection).
>
> 3) Flashing Red: When I shutdown, the screen flashes red several times
> before the shutdown splash screen shows up.
>
> #1 and #3 happen at random. Although, It seems to happen more on the first
> boot up. #2 consistently happens when connecting to my University's
> wireless; rarely (if ever) on my home router.
>
> Relevant sysinfo (Dell Inspiron E1505; Intel T2080 @ 1.73GHz):
> 0b:00.0 Network controller: Intel Corporation PRO/Wireless 3945ABG Network
> Connection (rev 02) 00:02.0 VGA compatible controller: Intel Corporation
> Mobile 945GM/GMS, 943/940GML Express Integrated Graphics Controller (rev
> 03) 00:02.1 Display controller: Intel Corporation Mobile 945GM/GMS/GME,
> 943/940GML Express Integrated Graphics Controller (rev 03)
>
> Could this be a regression? What can I do to help identify the problem?
> I've tried to start analyzing the blank screen problem, so let's start
> there because I've already created a diff log report.
>
> For a diff of my system logs for the blank screen problem see (104.61 KB):
> http://jdserver.homelinux.org/linux/blank_screen_log_diff.txt

It's kind of hard to read the context diff (unified diffs are much nicer) but 
nothing jumps out at me regarding your video config.  Does the blank screen 
problem occur if you disable usplash altogether and compile out the fb 
drivers?  The intelfb driver in particular can cause problems sometimes since 
it supports so few configurations, you might try the vesafb driver too.

Jesse

^ permalink raw reply	[flat|nested] 25+ messages in thread

* Re: [Regression: 2.6.25-rc5: Blank Screen: Intel 945]
       [not found]   ` <47D8BF6A.9020905@gawab.com>
@ 2008-03-13 17:09     ` Jesse Barnes
  2008-03-14  4:22       ` Justin Madru
  0 siblings, 1 reply; 25+ messages in thread
From: Jesse Barnes @ 2008-03-13 17:09 UTC (permalink / raw)
  To: Justin Madru; +Cc: linux-kernel

On Wednesday, March 12, 2008 10:45 pm Justin Madru wrote:
> Jesse Barnes wrote:
> > It's kind of hard to read the context diff (unified diffs are much nicer)
> > but nothing jumps out at me regarding your video config.  Does the blank
> > screen problem occur if you disable usplash altogether and compile out
> > the fb drivers?  The intelfb driver in particular can cause problems
> > sometimes since it supports so few configurations, you might try the
> > vesafb driver too.
>
> Sorry about the diff. So I should always use "diff -u"?

Yeah, diff -u is easier to read IMO.

> Anyways, I removed the frame buffer (see diff below if I did it right),
> and it seems to fix the problem.
> Although, the blank screen _randomly_ happened so I'll have to test it
> out for a while.
> It seems like I only get the blank screen when I first boot the computer
> after it's been off for a while.
> I just tried to trigger the blank screen by repeatedly rebooting but I
> wasn't able except for once, the first boot. ;(
>
> Does this seem reasonable? or just a coincidence.

Well, the blank screen is probably due to a pipe programming timing problem.  
IGD devices have been getting less & less sensitive to it over time (830s 
would hang if you looked at them the wrong way) but it's still not that hard 
to mis-program them.

Can you narrow down the problem at all?  Did it occur just after a kernel 
upgrade?  Or did you also upgrade your X driver?  There haven't been any real 
changes in intelfb since Oct. when Krzysztof added interlaced mode support, 
so it's weird that you're just seeing problems now...

> By the way, what is the frame buffer for? Does it have anything to do
> with the X server?

The framebuffer drivers provide a simple interface to applications wanting to 
draw to the screen.  It's usually used in embedded devices and for boot 
splash screens.  Generally you don't want to run X through the framebuffer 
APIs though; it'll be really slow compared to a proper X 2D driver.

> For instance, keeping it removed doesn't remove anything necessary? I
> just use GNOME, programs and Compiz Fusion. And why would I start to
> have this problem with the 2.6.25 kernel and not 2.6.24? Did the intelfb
> change?

I think the only thing you'll lose is the boot splash screen.  But you could 
also try using vesafb.  It works with more hardware than intelfb (including 
laptops) and we've fixed some vesafb related bugs in the X driver recently, 
so it may work better for you.

Jesse

^ permalink raw reply	[flat|nested] 25+ messages in thread

* Re: [Regression: 2.6.25-rc5: Blank Screen: Intel 945]
  2008-03-13 17:09     ` Jesse Barnes
@ 2008-03-14  4:22       ` Justin Madru
  2008-03-14 17:29         ` Jesse Barnes
  0 siblings, 1 reply; 25+ messages in thread
From: Justin Madru @ 2008-03-14  4:22 UTC (permalink / raw)
  To: Jesse Barnes; +Cc: lkml

Jesse Barnes wrote:
> Well, the blank screen is probably due to a pipe programming timing problem.  
> IGD devices have been getting less & less sensitive to it over time (830s 
> would hang if you looked at them the wrong way) but it's still not that hard 
> to mis-program them.
>
> Can you narrow down the problem at all?  Did it occur just after a kernel 
> upgrade?  Or did you also upgrade your X driver?  There haven't been any real 
> changes in intelfb since Oct. when Krzysztof added interlaced mode support, 
> so it's weird that you're just seeing problems now...
>   
Not that I can think of. Other than a custom kernel I use standard 
Ubuntu 7.10. I was testing out the kernel starting with 2.6.23-rc4 and 
I've tested each rc, recompiling when a new one came out (except for rc1 
and rc2, they didn't compile). So, when 2.6.25-rc3 came out I recompiled 
and came across this error.

I've removed all fb devices and the blank screen _almost_ never happens 
(also, I _don't_ have to disable the splash screen). There is one 
_big_exception_ the problem still happens when I'm at my University (and 
_very_ consistently). There, I have to disable the splash screen, and 
that ~mostly~ fixes the problem.

I can't believe it could be related, but when I boot the computer at the 
Univ. I get a flood of kernel messages  related to the wireless all the 
time, but still connect:

 > kernel: wlan0_rename: RX too short data frame payload

_Could_ a wireless problem be related to a graphics's problem? I 
wouldn't think so? But, it would explain why I get the blank screen 
mostly when I get the wireless problem. But, then again it could be 
another problem altogether.
> I think the only thing you'll lose is the boot splash screen.
I did disable fb correctly right? Because I still have a boot splash screen.
> But you could also try using vesafb. It works with more hardware than intelfb (including laptops) and we've fixed some vesafb related bugs in the X driver recently, so it may work better for you.
Well, if the fb is not necessary, then I think I'll just leave it out. 
Unless you think using the vesafb would help. But, I thought that the X 
server doesn't interact with the fb driver.

Maybe it's not related to the fb but the other intel driver:

CONFIG_AGP=y
CONFIG_AGP_INTEL=y
CONFIG_DRM=y
CONFIG_DRM_I915=m


I've updated my config if you need to see the newest version:
http://jdserver.homelinux.org/linux/config-2.6.25-rc5

Justin


^ permalink raw reply	[flat|nested] 25+ messages in thread

* Re: [Regression: 2.6.25-rc5: Blank Screen: Intel 945]
  2008-03-14  4:22       ` Justin Madru
@ 2008-03-14 17:29         ` Jesse Barnes
  2008-03-15  3:48           ` Justin Madru
  0 siblings, 1 reply; 25+ messages in thread
From: Jesse Barnes @ 2008-03-14 17:29 UTC (permalink / raw)
  To: Justin Madru; +Cc: lkml

On Thursday, March 13, 2008 9:22 pm Justin Madru wrote:
> Jesse Barnes wrote:
> > Well, the blank screen is probably due to a pipe programming timing
> > problem. IGD devices have been getting less & less sensitive to it over
> > time (830s would hang if you looked at them the wrong way) but it's still
> > not that hard to mis-program them.
> >
> > Can you narrow down the problem at all?  Did it occur just after a kernel
> > upgrade?  Or did you also upgrade your X driver?  There haven't been any
> > real changes in intelfb since Oct. when Krzysztof added interlaced mode
> > support, so it's weird that you're just seeing problems now...
>
> Not that I can think of. Other than a custom kernel I use standard
> Ubuntu 7.10. I was testing out the kernel starting with 2.6.23-rc4 and
> I've tested each rc, recompiling when a new one came out (except for rc1
> and rc2, they didn't compile). So, when 2.6.25-rc3 came out I recompiled
> and came across this error.

It would be interesting if you could get register dumps at a couple of 
different points, using the intel_reg_dumper tool in 
git://git.freedesktop.org/git/xorg/driver/xf86-video-intel (in 
src/reg_dumper).  You'll probably have to modify your boot scripts though.  
It would be good to get them:
  - at startup time before the splash screen
  - sometime while the splash screen is running
  - after X starts and you see the blank screen

Since I think this is actually an X driver bug, can you file a bug at 
freedesktop.org and attach the register dumps there?

>
> I've removed all fb devices and the blank screen _almost_ never happens
> (also, I _don't_ have to disable the splash screen). There is one
> _big_exception_ the problem still happens when I'm at my University (and
> _very_ consistently). There, I have to disable the splash screen, and
> that ~mostly~ fixes the problem.

What's different between your Uni. environment and your home environment?

> I can't believe it could be related, but when I boot the computer at the
> Univ. I get a flood of kernel messages  related to the wireless all the
>
> time, but still connect:
>  > kernel: wlan0_rename: RX too short data frame payload
>
> _Could_ a wireless problem be related to a graphics's problem? I
> wouldn't think so? But, it would explain why I get the blank screen
> mostly when I get the wireless problem. But, then again it could be
> another problem altogether.

Well, it's possible that the wireless issue is affecting the pipe programming 
timing enough to expose the bug (stuff like this is usually a problem with 
either not waiting for a register program to take effect and/or programming 
the regs in the wrong order).

> > I think the only thing you'll lose is the boot splash screen.
>
> I did disable fb correctly right? Because I still have a boot splash
> screen.

Yeah, looks like it's off.  Ubuntu may be falling back to using the X vesa 
driver or something though...

Jesse

^ permalink raw reply	[flat|nested] 25+ messages in thread

* Re: [Regression: 2.6.25-rc5: Blank Screen: Intel 945]
  2008-03-14 17:29         ` Jesse Barnes
@ 2008-03-15  3:48           ` Justin Madru
  2008-03-15 17:35             ` Jesse Barnes
  0 siblings, 1 reply; 25+ messages in thread
From: Justin Madru @ 2008-03-15  3:48 UTC (permalink / raw)
  To: Jesse Barnes; +Cc: lkml

Jesse Barnes wrote:

> It would be interesting if you could get register dumps at a couple of 
> different points, using the intel_reg_dumper tool in 
> git://git.freedesktop.org/git/xorg/driver/xf86-video-intel (in 
> src/reg_dumper).
>   
I couldn't get it to compile. What am I suppose to do? I ran autogen.sh 
in the top level dir and it gave the error message:

./configure: line 20486: syntax error near unexpected token `XINERMA,'
./configure: line 20486: `XORG_DRIVER_CHECK_EXT(XINERMA, xineramaproto)'

Then I also tried to run make and make -f Makefile.in (in the reg_dumper 
dir and top level dir), and it said:

Makefile.in:15 *** missing separator. Stop.

That part of Makefile.in contains:
@SET_MAKE@
VPATH = @srcdir@

What am I doing wrong? You'll have to forgive me, I'm not that 
experienced with the cmd line and compiling - I'm trying though.

> You'll probably have to modify your boot scripts though.  
> It would be good to get them:
>   - at startup time before the splash screen
>   - sometime while the splash screen is running
>   - after X starts and you see the blank screen
>   
How exactly would I do that? I would think I could just add command at 
the end of 3 files in /etc/init.d. Would that work? It should run my 
command when it starts that script and gets to the end. Or do boot 
scripts exit in the middle of the script, which would prevent my command 
from running?
> What's different between your Uni. environment and your home environment?
I'm not sure. I just have a home wireless router (Hawking HWR54G). I 
have no idea what the Uni. router is.
On both, I connect to an unencrypted network, but at the Uni. it 
redirects to a login page where I have to log on before I can actually 
use the Internet. Is there anyway I could get more information about the 
Uni. router?

Justin

^ permalink raw reply	[flat|nested] 25+ messages in thread

* Re: [Regression: 2.6.25-rc5: Blank Screen: Intel 945]
  2008-03-15  3:48           ` Justin Madru
@ 2008-03-15 17:35             ` Jesse Barnes
  2008-03-15 18:16               ` Bryce Harrington
  2008-03-17  1:28               ` Justin Madru
  0 siblings, 2 replies; 25+ messages in thread
From: Jesse Barnes @ 2008-03-15 17:35 UTC (permalink / raw)
  To: Justin Madru; +Cc: lkml, Bryce Harrington

[Adding Bryce to cc list, he may have a copy of intel_reg_dumper already built 
for Ubuntu.  Bryce, please see below for a few more questions, thanks.]

On Friday, March 14, 2008 8:48 pm Justin Madru wrote:
> Jesse Barnes wrote:
> > It would be interesting if you could get register dumps at a couple of
> > different points, using the intel_reg_dumper tool in
> > git://git.freedesktop.org/git/xorg/driver/xf86-video-intel (in
> > src/reg_dumper).
>
> I couldn't get it to compile. What am I suppose to do? I ran autogen.sh
> in the top level dir and it gave the error message:
>
> ./configure: line 20486: syntax error near unexpected token `XINERMA,'
> ./configure: line 20486: `XORG_DRIVER_CHECK_EXT(XINERMA, xineramaproto)'

This usually means you don't have the xorg autoconf macros installed.  Your 
distro probably has some sort of xserver-devel package that may include it.

> Then I also tried to run make and make -f Makefile.in (in the reg_dumper
> dir and top level dir), and it said:
>
> Makefile.in:15 *** missing separator. Stop.
>
> That part of Makefile.in contains:
> @SET_MAKE@
> VPATH = @srcdir@
>
> What am I doing wrong? You'll have to forgive me, I'm not that
> experienced with the cmd line and compiling - I'm trying though.

No problem, building X still isn't quite as easy as it should be, but it's 
only slightly more complicated than the typical './configure;make;make 
install' due to the dependencies between packages.  You can check out the X 
wiki (wiki.x.org), there are some hints on building things there.

> > You'll probably have to modify your boot scripts though.
> > It would be good to get them:
> >   - at startup time before the splash screen
> >   - sometime while the splash screen is running
> >   - after X starts and you see the blank screen
>
> How exactly would I do that? I would think I could just add command at
> the end of 3 files in /etc/init.d. Would that work? It should run my
> command when it starts that script and gets to the end. Or do boot
> scripts exit in the middle of the script, which would prevent my command
> from running?

Hm, I haven't looked at the Ubuntu scripts before.  I know they're using 
upstart, but if they haven't divered too much from the old style init, you 
may be able to modify rc.sysinit to get the boot time register dump.

For the splash screen dump, you'd just have to add the intel_reg_dumper 
command to one of the other init scripts that runs while the splash screen is 
up (maybe the HAL daemon script or something).

Once your screen is blank, it's probably easiest to ssh into your machine and 
capture the dump that way.

Hope that helps, maybe Bryce can give you some more hints on Ubuntu specifics.

> > What's different between your Uni. environment and your home environment?
>
> I'm not sure. I just have a home wireless router (Hawking HWR54G). I
> have no idea what the Uni. router is.
> On both, I connect to an unencrypted network, but at the Uni. it
> redirects to a login page where I have to log on before I can actually
> use the Internet. Is there anyway I could get more information about the
> Uni. router?

Probably, though the messages in your log from your Univ. connection may be 
enough for the networking guys to figure things out.  It's probably best to 
track the wireless thing as a separate issue though, I'd recommend mailing 
linux-wireless@vger.kernel.org with the problem.

Thanks,
Jesse



^ permalink raw reply	[flat|nested] 25+ messages in thread

* Re: [Regression: 2.6.25-rc5: Blank Screen: Intel 945]
  2008-03-15 17:35             ` Jesse Barnes
@ 2008-03-15 18:16               ` Bryce Harrington
  2008-03-17  1:28               ` Justin Madru
  1 sibling, 0 replies; 25+ messages in thread
From: Bryce Harrington @ 2008-03-15 18:16 UTC (permalink / raw)
  To: Jesse Barnes; +Cc: Justin Madru, lkml

On Sat, Mar 15, 2008 at 10:35:23AM -0700, Jesse Barnes wrote:
> [Adding Bryce to cc list, he may have a copy of intel_reg_dumper already built 
> for Ubuntu.  Bryce, please see below for a few more questions, thanks.]
> 
> On Friday, March 14, 2008 8:48 pm Justin Madru wrote:
> > Jesse Barnes wrote:
> > > It would be interesting if you could get register dumps at a couple of
> > > different points, using the intel_reg_dumper tool in
> > > git://git.freedesktop.org/git/xorg/driver/xf86-video-intel (in
> > > src/reg_dumper).
> >
> > I couldn't get it to compile. What am I suppose to do? I ran autogen.sh
> > in the top level dir and it gave the error message:
> >
> > ./configure: line 20486: syntax error near unexpected token `XINERMA,'
> > ./configure: line 20486: `XORG_DRIVER_CHECK_EXT(XINERMA, xineramaproto)'
> 
> This usually means you don't have the xorg autoconf macros installed.  Your 
> distro probably has some sort of xserver-devel package that may include it.

The following command will pull in all the dependencies you need for
building -intel:

 sudo apt-get build-dep xserver-xorg-video-intel
 
> > Then I also tried to run make and make -f Makefile.in (in the reg_dumper
> > dir and top level dir), and it said:
> >
> > Makefile.in:15 *** missing separator. Stop.
> >
> > That part of Makefile.in contains:
> > @SET_MAKE@
> > VPATH = @srcdir@
> >
> > What am I doing wrong? You'll have to forgive me, I'm not that
> > experienced with the cmd line and compiling - I'm trying though.
> 
> No problem, building X still isn't quite as easy as it should be, but it's 
> only slightly more complicated than the typical './configure;make;make 
> install' due to the dependencies between packages.  You can check out the X 
> wiki (wiki.x.org), there are some hints on building things there.
> 
> > > You'll probably have to modify your boot scripts though.
> > > It would be good to get them:
> > >   - at startup time before the splash screen
> > >   - sometime while the splash screen is running
> > >   - after X starts and you see the blank screen
>
> > How exactly would I do that? I would think I could just add command at
> > the end of 3 files in /etc/init.d. Would that work? It should run my
> > command when it starts that script and gets to the end. Or do boot
> > scripts exit in the middle of the script, which would prevent my command
> > from running?
> 
> Hm, I haven't looked at the Ubuntu scripts before.  I know they're using 
> upstart, but if they haven't divered too much from the old style init, you 
> may be able to modify rc.sysinit to get the boot time register dump.
> 
> For the splash screen dump, you'd just have to add the intel_reg_dumper 
> command to one of the other init scripts that runs while the splash screen is 
> up (maybe the HAL daemon script or something).
> 
> Once your screen is blank, it's probably easiest to ssh into your machine and 
> capture the dump that way.
> 
> Hope that helps, maybe Bryce can give you some more hints on Ubuntu specifics.

If you're having troubles while the splash screen is displayed, you may
want to look at / fiddle with the settings in /etc/gdm/gdm.conf.

Also have a look in /etc/gdm/, where the Init, PreSession, and
PostSession scripts are located.  Those are additional places where
scripts can be tied in during this early startup phase.  (I don't know
if that would actually be of use here though.)

Bryce

^ permalink raw reply	[flat|nested] 25+ messages in thread

* Re: [Regression: 2.6.25-rc5: Blank Screen: Intel 945]
  2008-03-15 17:35             ` Jesse Barnes
  2008-03-15 18:16               ` Bryce Harrington
@ 2008-03-17  1:28               ` Justin Madru
  2008-03-18 19:07                 ` Bryce Harrington
  1 sibling, 1 reply; 25+ messages in thread
From: Justin Madru @ 2008-03-17  1:28 UTC (permalink / raw)
  To: Jesse Barnes, Bryce Harrington; +Cc: lkml

Jesse Barnes wrote:
> No problem, building X still isn't quite as easy as it should be, but it's 
> only slightly more complicated than the typical './configure;make;make 
> install' due to the dependencies between packages.  You can check out the X 
> wiki (wiki.x.org), there are some hints on building things there.
>   

I'm just compiling the intel_reg_dumper right? I don't have to recompile 
all of X to use it?

Bryce Harrington wrote:
> The following command will pull in all the dependencies you need for
> building -intel:
>
>  sudo apt-get build-dep xserver-xorg-video-intel

Ok, got that. I tried to compile and I found out I also had to install 
libpciaccess-dev, that's probably because I'm using the git tree and not 
the one that Ubuntu 7.10 uses. But I still can't compile the 
intel_reg_dumper I get the following error:

intel-driver/src/reg_dumper$ make
gcc -DHAVE_CONFIG_H -I. -I../.. -Wall -Wpointer-arith 
-Wstrict-prototypes -Wmissing-prototypes -Wmissing-declarations 
-Wnested-externs -fno-strict-aliasing -I./.. -DREG_DUMPER -g -O2 -MT 
main.o -MD -MP -MF .deps/main.Tpo -c -o main.o main.c
main.c: In function ‘main’:
main.c:72: warning: implicit declaration of function ‘pci_device_map_range’
main.c:72: warning: nested extern declaration of ‘pci_device_map_range’
main.c:75: error: ‘PCI_DEV_MAP_FLAG_WRITABLE’ undeclared (first use in 
this function)
main.c:75: error: (Each undeclared identifier is reported only once
main.c:75: error: for each function it appears in.)
make: *** [main.o] Error 1

Justin

^ permalink raw reply	[flat|nested] 25+ messages in thread

* Re: [Regression: 2.6.25-rc5: Blank Screen: Intel 945]
  2008-03-17  1:28               ` Justin Madru
@ 2008-03-18 19:07                 ` Bryce Harrington
  2008-03-18 20:00                   ` Jesse Barnes
  0 siblings, 1 reply; 25+ messages in thread
From: Bryce Harrington @ 2008-03-18 19:07 UTC (permalink / raw)
  To: Justin Madru; +Cc: Jesse Barnes, lkml

On Sun, Mar 16, 2008 at 06:28:10PM -0700, Justin Madru wrote:
> Jesse Barnes wrote:
>> No problem, building X still isn't quite as easy as it should be, but it's 
>> only slightly more complicated than the typical './configure;make;make 
>> install' due to the dependencies between packages.  You can check out the 
>> X wiki (wiki.x.org), there are some hints on building things there.
>>   
>
<jbarnes> bryce: would it be possible for you to include
  intel_reg_dumper in your intel driver pkg?

jesse - I looked into this, and in fact debian has already enabled this
in the 2.2.1 driver, which we are carrying in Hardy.  Timo had to
disable it though since we currently carry libpciaccess in universe, not
main.

However, I note that even after installing libpciaccess, it still fails
to compile (see below):

>
> I'm just compiling the intel_reg_dumper right? I don't have to recompile 
> all of X to use it?
>
> Bryce Harrington wrote:
>> The following command will pull in all the dependencies you need for
>> building -intel:
>>
>>  sudo apt-get build-dep xserver-xorg-video-intel
>
> Ok, got that. I tried to compile and I found out I also had to install 
> libpciaccess-dev, that's probably because I'm using the git tree and not 
> the one that Ubuntu 7.10 uses. But I still can't compile the 
> intel_reg_dumper I get the following error:
>
> intel-driver/src/reg_dumper$ make
> gcc -DHAVE_CONFIG_H -I. -I../.. -Wall -Wpointer-arith -Wstrict-prototypes 
> -Wmissing-prototypes -Wmissing-declarations -Wnested-externs 
> -fno-strict-aliasing -I./.. -DREG_DUMPER -g -O2 -MT main.o -MD -MP -MF 
> .deps/main.Tpo -c -o main.o main.c
> main.c: In function ‘main’:
> main.c:72: warning: implicit declaration of function 
> ‘pci_device_map_range’
> main.c:72: warning: nested extern declaration of ‘pci_device_map_range’
> main.c:75: error: ‘PCI_DEV_MAP_FLAG_WRITABLE’ undeclared (first use in 
> this function)
> main.c:75: error: (Each undeclared identifier is reported only once
> main.c:75: error: for each function it appears in.)
> make: *** [main.o] Error 1
>
> Justin

Yes, the same error occurs with the 2.2.1 driver we have in Hardy right now:

bryce@chideok:~/src/xserver-xorg-video-intel/xserver-xorg-video-intel-2.2.1-build/src/reg_dumper$ make
gcc -DHAVE_CONFIG_H -I. -I../..     -Wall -Wpointer-arith -Wstrict-prototypes   -Wmissing-prototypes -Wmissing-declarations     -Wnested-externs -fno-strict-aliasing -I./.. -DREG_DUMPER -g -O2 -MT intel_reg_dumper-main.o -MD -MP -MF .deps/intel_reg_dumper-main.Tpo -c -o intel_reg_dumper-main.o `test -f 'main.c' || echo './'`main.c
main.c: In function 'main':
main.c:72: warning: implicit declaration of function 'pci_device_map_range'
main.c:72: warning: nested extern declaration of 'pci_device_map_range'
main.c:75: error: 'PCI_DEV_MAP_FLAG_WRITABLE' undeclared (first use in this function)
main.c:75: error: (Each undeclared identifier is reported only once
main.c:75: error: for each function it appears in.)
make: *** [intel_reg_dumper-main.o] Error 1

I could get it to build by ifdefing out th pci_device_map_range call,
and then adding -lpciaccess to the linker, however it segfaults without
that call.

Does LIBPCIACCESS require xserver 1.4?  (We have 1.3 in Hardy).

Bryce

^ permalink raw reply	[flat|nested] 25+ messages in thread

* Re: [Regression: 2.6.25-rc5: Blank Screen: Intel 945]
  2008-03-18 19:07                 ` Bryce Harrington
@ 2008-03-18 20:00                   ` Jesse Barnes
  2008-03-18 20:53                     ` Bryce Harrington
  2008-03-18 21:14                     ` Bryce Harrington
  0 siblings, 2 replies; 25+ messages in thread
From: Jesse Barnes @ 2008-03-18 20:00 UTC (permalink / raw)
  To: Bryce Harrington; +Cc: Justin Madru, lkml

On Tuesday, March 18, 2008 12:07 pm Bryce Harrington wrote:
> On Sun, Mar 16, 2008 at 06:28:10PM -0700, Justin Madru wrote:
> > Jesse Barnes wrote:
> >> No problem, building X still isn't quite as easy as it should be, but
> >> it's only slightly more complicated than the typical
> >> './configure;make;make install' due to the dependencies between
> >> packages.  You can check out the X wiki (wiki.x.org), there are some
> >> hints on building things there.
>
> <jbarnes> bryce: would it be possible for you to include
>   intel_reg_dumper in your intel driver pkg?
>
> jesse - I looked into this, and in fact debian has already enabled this
> in the 2.2.1 driver, which we are carrying in Hardy.  Timo had to
> disable it though since we currently carry libpciaccess in universe, not
> main.
>
> However, I note that even after installing libpciaccess, it still fails

Ok, thanks for checking.

> to compile (see below):
> > I'm just compiling the intel_reg_dumper right? I don't have to recompile
> > all of X to use it?
> >
> > Bryce Harrington wrote:
> >> The following command will pull in all the dependencies you need for
> >> building -intel:
> >>
> >>  sudo apt-get build-dep xserver-xorg-video-intel
> >
> > Ok, got that. I tried to compile and I found out I also had to install
> > libpciaccess-dev, that's probably because I'm using the git tree and not
> > the one that Ubuntu 7.10 uses. But I still can't compile the
> > intel_reg_dumper I get the following error:
> >
> > intel-driver/src/reg_dumper$ make
> > gcc -DHAVE_CONFIG_H -I. -I../.. -Wall -Wpointer-arith -Wstrict-prototypes
> > -Wmissing-prototypes -Wmissing-declarations -Wnested-externs
> > -fno-strict-aliasing -I./.. -DREG_DUMPER -g -O2 -MT main.o -MD -MP -MF
> > .deps/main.Tpo -c -o main.o main.c
> > main.c: In function ‘main’:
> > main.c:72: warning: implicit declaration of function
> > ‘pci_device_map_range’
> > main.c:72: warning: nested extern declaration of ‘pci_device_map_range’
> > main.c:75: error: ‘PCI_DEV_MAP_FLAG_WRITABLE’ undeclared (first use in
> > this function)
> > main.c:75: error: (Each undeclared identifier is reported only once
> > main.c:75: error: for each function it appears in.)
> > make: *** [main.o] Error 1
> >
> > Justin
>
> Yes, the same error occurs with the 2.2.1 driver we have in Hardy right
> now:
>
> bryce@chideok:~/src/xserver-xorg-video-intel/xserver-xorg-video-intel-2.2.1
>-build/src/reg_dumper$ make gcc -DHAVE_CONFIG_H -I. -I../..     -Wall
> -Wpointer-arith -Wstrict-prototypes   -Wmissing-prototypes
> -Wmissing-declarations     -Wnested-externs -fno-strict-aliasing -I./..
> -DREG_DUMPER -g -O2 -MT intel_reg_dumper-main.o -MD -MP -MF
> .deps/intel_reg_dumper-main.Tpo -c -o intel_reg_dumper-main.o `test -f
> 'main.c' || echo './'`main.c main.c: In function 'main':
> main.c:72: warning: implicit declaration of function 'pci_device_map_range'
> main.c:72: warning: nested extern declaration of 'pci_device_map_range'
> main.c:75: error: 'PCI_DEV_MAP_FLAG_WRITABLE' undeclared (first use in this
> function) main.c:75: error: (Each undeclared identifier is reported only
> once main.c:75: error: for each function it appears in.)
> make: *** [intel_reg_dumper-main.o] Error 1
>
> I could get it to build by ifdefing out th pci_device_map_range call,
> and then adding -lpciaccess to the linker, however it segfaults without
> that call.
>
> Does LIBPCIACCESS require xserver 1.4?  (We have 1.3 in Hardy).

No, libpciaccess should be standalone, but the Intel driver requires 0.10 or 
better... Which version are you building against?


^ permalink raw reply	[flat|nested] 25+ messages in thread

* Re: [Regression: 2.6.25-rc5: Blank Screen: Intel 945]
  2008-03-18 20:00                   ` Jesse Barnes
@ 2008-03-18 20:53                     ` Bryce Harrington
  2008-03-18 21:14                     ` Bryce Harrington
  1 sibling, 0 replies; 25+ messages in thread
From: Bryce Harrington @ 2008-03-18 20:53 UTC (permalink / raw)
  To: Jesse Barnes; +Cc: Justin Madru, lkml

On Tue, Mar 18, 2008 at 01:00:39PM -0700, Jesse Barnes wrote:
> > I could get it to build by ifdefing out th pci_device_map_range call,
> > and then adding -lpciaccess to the linker, however it segfaults without
> > that call.
> >
> > Does LIBPCIACCESS require xserver 1.4?  (We have 1.3 in Hardy).
> 
> No, libpciaccess should be standalone, but the Intel driver requires 0.10 or 
> better... Which version are you building against?

Looks like we still are on 0.8.  I can check into upping us to 0.10 this
afternoon or tomorrow - even though it's still in universe and we can't
include it yet by default for -intel, that'll make it simpler for users
that need to build it.  Stay tuned.

Bryce


^ permalink raw reply	[flat|nested] 25+ messages in thread

* Re: [Regression: 2.6.25-rc5: Blank Screen: Intel 945]
  2008-03-18 20:00                   ` Jesse Barnes
  2008-03-18 20:53                     ` Bryce Harrington
@ 2008-03-18 21:14                     ` Bryce Harrington
  2008-03-18 21:17                       ` Jesse Barnes
  1 sibling, 1 reply; 25+ messages in thread
From: Bryce Harrington @ 2008-03-18 21:14 UTC (permalink / raw)
  To: Jesse Barnes; +Cc: Justin Madru, lkml

On Tue, Mar 18, 2008 at 01:00:39PM -0700, Jesse Barnes wrote:
> > I could get it to build by ifdefing out th pci_device_map_range call,
> > and then adding -lpciaccess to the linker, however it segfaults without
> > that call.
> >
> > Does LIBPCIACCESS require xserver 1.4?  (We have 1.3 in Hardy).
(Obviously I meant 1.5 / 1.4 above.  Dah.)

> No, libpciaccess should be standalone, but the Intel driver requires 0.10 or 
> better... Which version are you building against?

I've put in a sync request for this to get updated for hardy.  (It still
will only be in universe, so won't be built automatically with -intel,
but at least users will be able to more easily compile it by hand.)

Meanwhile, here is a Ubuntu Hardy build of Debian's package:

  http://people.ubuntu.com/~bryce/Testing/libpciaccess/libpciaccess-dev_0.10-1_i386.deb
  http://people.ubuntu.com/~bryce/Testing/libpciaccess/libpciaccess0_0.10-1_i386.deb

Bryce


^ permalink raw reply	[flat|nested] 25+ messages in thread

* Re: [Regression: 2.6.25-rc5: Blank Screen: Intel 945]
  2008-03-18 21:14                     ` Bryce Harrington
@ 2008-03-18 21:17                       ` Jesse Barnes
  2008-03-19 23:38                         ` Justin Madru
  0 siblings, 1 reply; 25+ messages in thread
From: Jesse Barnes @ 2008-03-18 21:17 UTC (permalink / raw)
  To: Bryce Harrington; +Cc: Justin Madru, lkml

On Tuesday, March 18, 2008 2:14 pm Bryce Harrington wrote:
> On Tue, Mar 18, 2008 at 01:00:39PM -0700, Jesse Barnes wrote:
> > > I could get it to build by ifdefing out th pci_device_map_range call,
> > > and then adding -lpciaccess to the linker, however it segfaults without
> > > that call.
> > >
> > > Does LIBPCIACCESS require xserver 1.4?  (We have 1.3 in Hardy).
>
> (Obviously I meant 1.5 / 1.4 above.  Dah.)
>
> > No, libpciaccess should be standalone, but the Intel driver requires 0.10
> > or better... Which version are you building against?
>
> I've put in a sync request for this to get updated for hardy.  (It still
> will only be in universe, so won't be built automatically with -intel,
> but at least users will be able to more easily compile it by hand.)
>
> Meanwhile, here is a Ubuntu Hardy build of Debian's package:
>
>  
> http://people.ubuntu.com/~bryce/Testing/libpciaccess/libpciaccess-dev_0.10-
>1_i386.deb
> http://people.ubuntu.com/~bryce/Testing/libpciaccess/libpciaccess0_0.10-1_i
>386.deb

Thanks a lot Bryce, hopefully this will help Justin build the register dumper 
so we can track down his problem...

Jesse

^ permalink raw reply	[flat|nested] 25+ messages in thread

* Re: [Regression: 2.6.25-rc5: Blank Screen: Intel 945]
  2008-03-18 21:17                       ` Jesse Barnes
@ 2008-03-19 23:38                         ` Justin Madru
  2008-03-19 23:48                           ` Jesse Barnes
  0 siblings, 1 reply; 25+ messages in thread
From: Justin Madru @ 2008-03-19 23:38 UTC (permalink / raw)
  To: Jesse Barnes; +Cc: lkml, Bryce Harrington

Jesse Barnes wrote:
>> I've put in a sync request for this to get updated for hardy.  (It still
>> will only be in universe, so won't be built automatically with -intel,
>> but at least users will be able to more easily compile it by hand.)
>>
>> Meanwhile, here is a Ubuntu Hardy build of Debian's package:
>>  
>> http://people.ubuntu.com/~bryce/Testing/libpciaccess/libpciaccess-dev_0.10-1_i386.deb
>> http://people.ubuntu.com/~bryce/Testing/libpciaccess/libpciaccess0_0.10-1_i386.deb
>>     
>
> Thanks a lot Bryce, hopefully this will help Justin build the register dumper 
> so we can track down his problem...
>
> Jesse
>   
Thanks for all your help so far! Well I tried to install the deb files 
that Bryce created, unfortunately they're dependent on a newer version 
of libc6. I think (_hope_) this is the one in Hardy _because_ that's 
what I'm doing right now; I've decided to upgrade to Hardy. (so sad 
because I have to download _1.5GB_)

Jesse, do you still think it's a bug in the X server driver instead of 
the kernel driver (dri I guess)? Because I can trigger the blank screen 
before the X server even starts. If I press ctr+alt+f1 at the _right_ 
time when the kernel is booting (or I guess when the boot splash is 
showing) it will instantly blank out. That doesn't seem like something 
related to X.

Anyways maybe it's multiple things, and by upgrading to Hardy it might 
fix it (which would prove that it's not a kernel bug, but some software 
version dependency bug - which would still be good to know).

Justin

^ permalink raw reply	[flat|nested] 25+ messages in thread

* Re: [Regression: 2.6.25-rc5: Blank Screen: Intel 945]
  2008-03-19 23:38                         ` Justin Madru
@ 2008-03-19 23:48                           ` Jesse Barnes
  2008-03-20  2:00                             ` Bryce Harrington
  2008-03-25  3:07                             ` Justin Madru
  0 siblings, 2 replies; 25+ messages in thread
From: Jesse Barnes @ 2008-03-19 23:48 UTC (permalink / raw)
  To: Justin Madru; +Cc: lkml, Bryce Harrington

On Wednesday, March 19, 2008 4:38 pm Justin Madru wrote:
> Jesse Barnes wrote:
> >> I've put in a sync request for this to get updated for hardy.  (It still
> >> will only be in universe, so won't be built automatically with -intel,
> >> but at least users will be able to more easily compile it by hand.)
> >>
> >> Meanwhile, here is a Ubuntu Hardy build of Debian's package:
> >>
> >> http://people.ubuntu.com/~bryce/Testing/libpciaccess/libpciaccess-dev_0.
> >>10-1_i386.deb
> >> http://people.ubuntu.com/~bryce/Testing/libpciaccess/libpciaccess0_0.10-
> >>1_i386.deb
> >
> > Thanks a lot Bryce, hopefully this will help Justin build the register
> > dumper so we can track down his problem...
> >
> > Jesse
>
> Thanks for all your help so far! Well I tried to install the deb files
> that Bryce created, unfortunately they're dependent on a newer version
> of libc6. I think (_hope_) this is the one in Hardy _because_ that's
> what I'm doing right now; I've decided to upgrade to Hardy. (so sad
> because I have to download _1.5GB_)
>
> Jesse, do you still think it's a bug in the X server driver instead of
> the kernel driver (dri I guess)? Because I can trigger the blank screen
> before the X server even starts. If I press ctr+alt+f1 at the _right_
> time when the kernel is booting (or I guess when the boot splash is
> showing) it will instantly blank out. That doesn't seem like something
> related to X.

Depends on the boot splash program.  I think in some configurations it'll be X 
based, but again Bryce probably knows more here as the Ubuntu X guy. :)

> Anyways maybe it's multiple things, and by upgrading to Hardy it might
> fix it (which would prove that it's not a kernel bug, but some software
> version dependency bug - which would still be good to know).

Good luck with the upgrade...

Jesse

^ permalink raw reply	[flat|nested] 25+ messages in thread

* Re: [Regression: 2.6.25-rc5: Blank Screen: Intel 945]
  2008-03-19 23:48                           ` Jesse Barnes
@ 2008-03-20  2:00                             ` Bryce Harrington
  2008-03-25  3:07                             ` Justin Madru
  1 sibling, 0 replies; 25+ messages in thread
From: Bryce Harrington @ 2008-03-20  2:00 UTC (permalink / raw)
  To: Jesse Barnes; +Cc: Justin Madru, lkml

On Wed, Mar 19, 2008 at 04:48:59PM -0700, Jesse Barnes wrote:
> On Wednesday, March 19, 2008 4:38 pm Justin Madru wrote:
> > Jesse, do you still think it's a bug in the X server driver instead of
> > the kernel driver (dri I guess)? Because I can trigger the blank screen
> > before the X server even starts. If I press ctr+alt+f1 at the _right_
> > time when the kernel is booting (or I guess when the boot splash is
> > showing) it will instantly blank out. That doesn't seem like something
> > related to X.
>
> Depends on the boot splash program.  I think in some configurations it'll be X
> based, but again Bryce probably knows more here as the Ubuntu X guy. :)

Mmm, well indeed that may be the kernel framebuffer.

Justin, one thing you could try is to set your system to boot up without
starting gdm.  Either do this via /etc/X11/default-display-manager
(comment it out, or set to xdm or something) or bypass it entirely by 
mv /etc/rc3.d/{S30,K30}gdm, and then append '3' to the end of the boot line
in grub.  (Maybe there's a better way to achieve this with upstart, but
my upstart-fu is limited.)

Bryce

^ permalink raw reply	[flat|nested] 25+ messages in thread

* Re: [Regression: 2.6.25-rc5: Blank Screen: Intel 945]
  2008-03-19 23:48                           ` Jesse Barnes
  2008-03-20  2:00                             ` Bryce Harrington
@ 2008-03-25  3:07                             ` Justin Madru
  2008-03-25 20:08                               ` Jesse Barnes
  1 sibling, 1 reply; 25+ messages in thread
From: Justin Madru @ 2008-03-25  3:07 UTC (permalink / raw)
  To: Jesse Barnes; +Cc: lkml

Jesse Barnes wrote:
> Good luck with the upgrade...

Well, the upgrade went ok, and compiling the reg_dumper using the libpciaccess .deb from Bryce worked.
Then I tried to add to the boot scripts a call to reg_dumper...
...To make a long story short...
I somehow killed my boot scripts! Anyways, I did a fresh reinstall of Ubuntu 8.4 Beta.

I'm still getting the blank screen problem with the 2.6.25-rc6 kernel,
so I guess it wasn't a Ubuntu software problem (or I hope not, because that could be really hard to find).

What I did was created a script that took a reg_dump every 6 secs for 1 min.
I made that as rc2.d/S01regdump so it should've been the very first thing called.
So, I hope there's enough "data points" to see what's happening.

Reg Dump Information
	http://jdserver.homelinux.org/linux/reg_dump.tar.bz2
Detailed System Information
	http://jdserver.homelinux.org/linux/sysinfo-2.6.25-rc6
Kernel Config
	http://jdserver.homelinux.org/linux/config-2.6.25-rc6

Hope that can help find the problem. If you need me to test anything else I'll try.

Justin


^ permalink raw reply	[flat|nested] 25+ messages in thread

* Re: [Regression: 2.6.25-rc5: Blank Screen: Intel 945]
  2008-03-25  3:07                             ` Justin Madru
@ 2008-03-25 20:08                               ` Jesse Barnes
  2008-03-26 18:32                                 ` Justin Madru
  2008-03-31 19:24                                 ` Justin Madru
  0 siblings, 2 replies; 25+ messages in thread
From: Jesse Barnes @ 2008-03-25 20:08 UTC (permalink / raw)
  To: Justin Madru; +Cc: lkml, linux-fbdev-devel

On Monday, March 24, 2008 8:07 pm Justin Madru wrote:
> Jesse Barnes wrote:
> > Good luck with the upgrade...
>
> Well, the upgrade went ok, and compiling the reg_dumper using the
> libpciaccess .deb from Bryce worked. Then I tried to add to the boot
> scripts a call to reg_dumper...
> ...To make a long story short...
> I somehow killed my boot scripts! Anyways, I did a fresh reinstall of
> Ubuntu 8.4 Beta.
>
> I'm still getting the blank screen problem with the 2.6.25-rc6 kernel,
> so I guess it wasn't a Ubuntu software problem (or I hope not, because that
> could be really hard to find).
>
> What I did was created a script that took a reg_dump every 6 secs for 1
> min. I made that as rc2.d/S01regdump so it should've been the very first
> thing called. So, I hope there's enough "data points" to see what's
> happening.
>
> Reg Dump Information
> 	http://jdserver.homelinux.org/linux/reg_dump.tar.bz2

Wow, that's a lot of dump files. :)

I was worried that in the "blank" case we may see the same register dump
as in the working case, but thankfully they're different.  In fact, in all
the dumps after 0 in the 2.6.25-blank case, both pipes are disabled and
the LCD itself is disabled.

The important bits:

@@ -24,7 +24,7 @@
 (II):          DVOB_SRCDIM: 0x00000000
 (II):          DVOC_SRCDIM: 0x00000000
 (II):           PP_CONTROL: 0x00000001 (power target: on)
-(II):            PP_STATUS: 0xc0000008 (on, ready, sequencing idle)
+(II):            PP_STATUS: 0x0000000a (off, not ready, sequencing idle)
 (II):         PFIT_CONTROL: 0x80002668
 (II):      PFIT_PGM_RATIOS: 0x00000000
 (II):      PORT_HOTPLUG_EN: 0x00000020
@@ -36,7 +36,7 @@
 (II):             DSPABASE: 0x00000000
 (II):             DSPASURF: 0x00000000
 (II):          DSPATILEOFF: 0x00000000
-(II):            PIPEACONF: 0x00000000 (disabled, single-wide)
+(II):            PIPEACONF: 0x000c0000 (disabled, single-wide)
 (II):             PIPEASRC: 0x027f01df (640, 480)
 (II):            PIPEASTAT: 0x80000203 (status: FIFO_UNDERRUN VSYNC_INT_STATUS VBLANK_INT_STATUS OREG_UPDATE_STATUS)
 (II):         FBC_CFB_BASE: 0x00000000
@@ -59,16 +59,16 @@
 (II):              VSYNC_A: 0x01eb01e9 (490 start, 492 end)
 (II):            BCLRPAT_A: 0x00000000
 (II):         VSYNCSHIFT_A: 0x00000000
-(II):             DSPBCNTR: 0x95000000 (enabled, pipe B)
+(II):             DSPBCNTR: 0x15000000 (disabled, pipe B)
 (II):           DSPBSTRIDE: 0x00000500 (1280 bytes)
 (II):              DSPBPOS: 0x00000000 (0, 0)
 (II):             DSPBSIZE: 0x01df027f (640, 480)
 (II):             DSPBBASE: 0x00000000
 (II):             DSPBSURF: 0x00000000
 (II):          DSPBTILEOFF: 0x00000000
-(II):            PIPEBCONF: 0x80000000 (enabled, single-wide)
+(II):            PIPEBCONF: 0x000c0000 (disabled, single-wide)
 (II):             PIPEBSRC: 0x027f01df (640, 480)
-(II):            PIPEBSTAT: 0x00000202 (status: VSYNC_INT_STATUS VBLANK_INT_STATUS)
+(II):            PIPEBSTAT: 0x00000242 (status: VSYNC_INT_STATUS LBLC_EVENT_STATUS VBLANK_INT_STATUS)
 (II):                 FPB0: 0x00031107 (n = 3, m1 = 17, m2 = 7)
 (II):                 FPB1: 0x00031108 (n = 3, m1 = 17, m2 = 8)
 (II):               DPLL_B: 0x98026003 (enabled, non-dvo, spread spectrum clock, LVDS mode, p1 = 2, p2 = 14, SDVO mult 1)

So somehow both pipes are getting disabled, and your LCD is getting turned
off and things never get re-enabled.  The X driver should have turned things
back on though, after detecting what's available.  Do you have your X logs
from the working & broken cases?  Also, did you try reproducing the blank
screen problem w/o gdm enabled as Bryce suggested?  That could help narrow
down if it's just an intelfb problem vs. a new intelfb/X driver interaction
bug.

I still don't know why this behavior would have changed between 2.6.24 and
2.6.25-rc though... maybe the fb guys have some clue about other fb changes
that may have affected things.

Thanks a lot for your hard work so far in debugging this...

Thanks,
Jesse

^ permalink raw reply	[flat|nested] 25+ messages in thread

* Re: [Regression: 2.6.25-rc5: Blank Screen: Intel 945]
  2008-03-25 20:08                               ` Jesse Barnes
@ 2008-03-26 18:32                                 ` Justin Madru
  2008-03-31 19:24                                 ` Justin Madru
  1 sibling, 0 replies; 25+ messages in thread
From: Justin Madru @ 2008-03-26 18:32 UTC (permalink / raw)
  To: Jesse Barnes; +Cc: lkml

Jesse Barnes wrote:
> So somehow both pipes are getting disabled, and your LCD is getting turned
> off and things never get re-enabled.  The X driver should have turned things
> back on though, after detecting what's available.  Do you have your X logs
> from the working & broken cases?  Also, did you try reproducing the blank
> screen problem w/o gdm enabled as Bryce suggested?  That could help narrow
> down if it's just an intelfb problem vs. a new intelfb/X driver interaction
> bug.
>
> I still don't know why this behavior would have changed between 2.6.24 and
> 2.6.25-rc though... maybe the fb guys have some clue about other fb changes
> that may have affected things.

Ok, I have the X logs:
http://jdserver.homelinux.org/linux/Xorg.0.log-blank
http://jdserver.homelinux.org/linux/Xorg.0.log-good

Below is just a portion of the diff of those files.

--- Xorg.0.log-blank    2008-03-26 11:14:12.000000000 -0700
+++ Xorg.0.log-good    2008-03-26 11:14:35.000000000 -0700
@@ -20,7 +20,7 @@
 Markers: (--) probed, (**) from config file, (==) default setting,
     (++) from command line, (!!) notice, (II) informational,
     (WW) warning, (EE) error, (NI) not implemented, (??) unknown.
-(==) Log file: "/var/log/Xorg.0.log", Time: Wed Mar 26 09:59:56 2008
+(==) Log file: "/var/log/Xorg.0.log", Time: Wed Mar 26 10:02:12 2008
 (==) Using config file: "/etc/X11/xorg.conf"
 (==) ServerLayout "Default Layout"
 (**) |-->Screen "Default Screen" (0)
@@ -470,9 +470,9 @@
 (WW) intel(0): Register 0x61200 (PP_STATUS) changed from 0xc0000008 to 
0xd0000009
 (WW) intel(0): PP_STATUS before: on, ready, sequencing idle
 (WW) intel(0): PP_STATUS after: on, ready, sequencing on
-(WW) intel(0): Register 0x71024 (PIPEBSTAT) changed from 0x00000202 to 
0x00000242
-(WW) intel(0): PIPEBSTAT before: status: VSYNC_INT_STATUS VBLANK_INT_STATUS
-(WW) intel(0): PIPEBSTAT after: status: VSYNC_INT_STATUS 
LBLC_EVENT_STATUS VBLANK_INT_STATUS
+(WW) intel(0): Register 0x71024 (PIPEBSTAT) changed from 0x80000202 to 
0x80000242
+(WW) intel(0): PIPEBSTAT before: status: FIFO_UNDERRUN VSYNC_INT_STATUS 
VBLANK_INT_STATUS
+(WW) intel(0): PIPEBSTAT after: status: FIFO_UNDERRUN VSYNC_INT_STATUS 
LBLC_EVENT_STATUS VBLANK_INT_STATUS
 (WW) intel(0): Register 0x68000 (TV_CTL) changed from 0x10000000 to 
0x000c0000
 (WW) intel(0): Register 0x68010 (TV_CSC_Y) changed from 0x00000000 to 
0x0332012d
 (WW) intel(0): Register 0x68014 (TV_CSC_Y2) changed from 0x00000000 to 
0x07d30104
@@ -735,11 +735,73 @@
 (II) intel(0): fbc disabled on plane a
 (II) intel(0): fbc disabled on plane a
 (II) intel(0): fbc disabled on plane a
-(II) intel(0): xf86UnbindGARTMemory: unbind key 0
-(II) intel(0): xf86UnbindGARTMemory: unbind key 1
-(II) intel(0): xf86UnbindGARTMemory: unbind key 2
-(II) intel(0): xf86UnbindGARTMemory: unbind key 3
-(II) intel(0): xf86UnbindGARTMemory: unbind key 4
-(II) intel(0): [drm] removed 1 reserved context for kernel
-(II) intel(0): [drm] unmapping 8192 bytes of SAREA 0xf89e9000 at 0xb7ba4000
-(II) intel(0): [drm] Closed DRM master.
+(II) intel(0): fbc disabled on plane a
+(II) intel(0): fbc disabled on plane a
+(II) intel(0): fbc disabled on plane a
+(II) intel(0): fbc disabled on plane a

What's interesting is that:

-Register 0x71024 (PIPEBSTAT) changed from 0x00000202 to 0x00000242
+Register 0x71024 (PIPEBSTAT) changed from 0x80000202 to 0x80000242

-PIPEBSTAT before: status: VSYNC_INT_STATUS VBLANK_INT_STATUS
+PIPEBSTAT before: status: FIFO_UNDERRUN VSYNC_INT_STATUS VBLANK_INT_STATUS

-PIPEBSTAT after: status: VSYNC_INT_STATUS LBLC_EVENT_STATUS 
VBLANK_INT_STATUS
+PIPEBSTAT after: status: FIFO_UNDERRUN VSYNC_INT_STATUS LBLC_EVENT_STATUS

Also the blank X log file ends with:

(II) intel(0): xf86UnbindGARTMemory: unbind key 0
(II) intel(0): xf86UnbindGARTMemory: unbind key 1
(II) intel(0): xf86UnbindGARTMemory: unbind key 2
(II) intel(0): xf86UnbindGARTMemory: unbind key 3
(II) intel(0): xf86UnbindGARTMemory: unbind key 4
(II) intel(0): [drm] removed 1 reserved context for kernel
(II) intel(0): [drm] unmapping 8192 bytes of SAREA 0xf89e9000 at 0xb7ba4000
(II) intel(0): [drm] Closed DRM master.

It seems like a problem with the intel drm/dri kernel modules (not the 
fb, I guess).
I didn't try disabling gdm yet (currently _busy_ with midterms, until 
after Thursday).

Justin

^ permalink raw reply	[flat|nested] 25+ messages in thread

* Re: [Regression: 2.6.25-rc5: Blank Screen: Intel 945]
  2008-03-25 20:08                               ` Jesse Barnes
  2008-03-26 18:32                                 ` Justin Madru
@ 2008-03-31 19:24                                 ` Justin Madru
  2008-04-01 20:22                                   ` Jesse Barnes
  1 sibling, 1 reply; 25+ messages in thread
From: Justin Madru @ 2008-03-31 19:24 UTC (permalink / raw)
  To: Jesse Barnes; +Cc: lkml

Jesse Barnes wrote:
> So somehow both pipes are getting disabled, and your LCD is getting turned
> off and things never get re-enabled.  The X driver should have turned things
> back on though, after detecting what's available.  Do you have your X logs
> from the working & broken cases?  Also, did you try reproducing the blank
> screen problem w/o gdm enabled as Bryce suggested?  That could help narrow
> down if it's just an intelfb problem vs. a new intelfb/X driver interaction
> bug.

Well, I disabled gdm and tryed to trigger the blank screen. I did about ~16 reboots and it blanked out on me only 2 times.
I was using a script to reboot and/or startx. One time I'm not exactly sure if X was started, so it might have blanked out on a "startx".
The other time I'm fairly sure X wasn't started, so it blanked out on a terminal login.

Both of the blank outs were different than the ones with gdm started. Pressing ctrl+alt+f# changed nothing on the screen;
the screen seemed almost completely off (no or little backlight). A few seconds after pressing the power button the shutdown splash screen would show, but this time it was _very_ faint.

Usually, when gdm is enabled, pressing ctrl+alt+f# would "refresh" (or mode/resolution change) the screen, but it would still be blank.
Also the backlight still seamed to be on and at full brightness (although, still displaying black).

Well, I don't know what to say, it's the strangest of problems.

Justin


^ permalink raw reply	[flat|nested] 25+ messages in thread

* Re: [Regression: 2.6.25-rc5: Blank Screen: Intel 945]
  2008-03-31 19:24                                 ` Justin Madru
@ 2008-04-01 20:22                                   ` Jesse Barnes
  2008-04-09  4:56                                     ` Justin Madru
  0 siblings, 1 reply; 25+ messages in thread
From: Jesse Barnes @ 2008-04-01 20:22 UTC (permalink / raw)
  To: Justin Madru; +Cc: lkml, linux-fbdev-devel

On Monday, March 31, 2008 12:24 pm Justin Madru wrote:
> Well, I disabled gdm and tryed to trigger the blank screen. I did about ~16
> reboots and it blanked out on me only 2 times. I was using a script to
> reboot and/or startx. One time I'm not exactly sure if X was started, so it
> might have blanked out on a "startx". The other time I'm fairly sure X
> wasn't started, so it blanked out on a terminal login.

Ok, so that might indicate something in the fb layer is killing it...

> Both of the blank outs were different than the ones with gdm started.
> Pressing ctrl+alt+f# changed nothing on the screen; the screen seemed
> almost completely off (no or little backlight). A few seconds after
> pressing the power button the shutdown splash screen would show, but this
> time it was _very_ faint.
>
> Usually, when gdm is enabled, pressing ctrl+alt+f# would "refresh" (or
> mode/resolution change) the screen, but it would still be blank. Also the
> backlight still seamed to be on and at full brightness (although, still
> displaying black).
>
> Well, I don't know what to say, it's the strangest of problems.

Yeah, seems pretty weird.  Given that you see it w/o the fb stuff loaded as 
well and we still have a few open bugs against the intel X driver regarding 
VT switch & mode programming, I don't think this is a real kernel regression.  
It's more likely that some timing or memory layout changed subtly and is 
causing to to hit one of our existing bugs more frequently that you did 
before.  Can you file a bug against the intel X driver at 
bugs.freedesktop.org so we can track it there?  Unless we can find a way to 
reproduce it reliably it'll probably take a long time to fix, but we don't 
want to lose it either...

Thanks,
Jesse

^ permalink raw reply	[flat|nested] 25+ messages in thread

* Re: [Regression: 2.6.25-rc5: Blank Screen: Intel 945]
  2008-04-01 20:22                                   ` Jesse Barnes
@ 2008-04-09  4:56                                     ` Justin Madru
  2008-04-09 15:24                                       ` Jesse Barnes
  0 siblings, 1 reply; 25+ messages in thread
From: Justin Madru @ 2008-04-09  4:56 UTC (permalink / raw)
  To: Jesse Barnes; +Cc: lkml

Jesse Barnes wrote:
> Yeah, seems pretty weird.  Given that you see it w/o the fb stuff loaded as 
> well and we still have a few open bugs against the intel X driver regarding 
> VT switch & mode programming, I don't think this is a real kernel regression.  
> It's more likely that some timing or memory layout changed subtly and is 
> causing to to hit one of our existing bugs more frequently that you did 
> before.  Can you file a bug against the intel X driver at 
> bugs.freedesktop.org so we can track it there?  Unless we can find a way to 
> reproduce it reliably it'll probably take a long time to fix, but we don't 
> want to lose it either...

Well, I'll file a bug on bugs.freedesktop.org, but if you don't think 
it's a kernel regression then I'll wait until the final release of 
2.6.25 comes out (unless you _really_ need me to file it sooner).

I still think it's somehow related to something that changed in the 
kernel from v24 to v25 because I've never had it happen with a kernel 
version less that 2.6.25. You say it's a timing issue; I've searched and 
found two things that have changed in v25: Preemptive RCU and I/O Port 
Delay.

I've enabled both preemptive RCU and no I/O port delay. I've recompiled 
with both disabled and found that the blank screen _still_ happens. So, 
I'm figuring that _maybe_ by adding these options the kernel developers 
needed to change something that exposes something related to the intel 
X.org driver that's no longer necessarily true
(or something like that - do you get what I'm trying to say).

This is what I have in my config:
> CONFIG_PREEMPT_RCU=y
> CONFIG_IO_DELAY_NONE=y

By the way is the intel driver that you work on the same that's enabled by:
> CONFIG_AGP_INTEL=m
> CONFIG_DRM_I915=m

Or is there another X.org intel driver? And if so how are they 
(agp/drm/X.org) related?

Justin

^ permalink raw reply	[flat|nested] 25+ messages in thread

* Re: [Regression: 2.6.25-rc5: Blank Screen: Intel 945]
  2008-04-09  4:56                                     ` Justin Madru
@ 2008-04-09 15:24                                       ` Jesse Barnes
  2008-04-14  3:46                                         ` Justin Madru
  0 siblings, 1 reply; 25+ messages in thread
From: Jesse Barnes @ 2008-04-09 15:24 UTC (permalink / raw)
  To: Justin Madru; +Cc: lkml

On Tuesday, April 08, 2008 9:56 pm Justin Madru wrote:
> Jesse Barnes wrote:
> > Yeah, seems pretty weird.  Given that you see it w/o the fb stuff loaded
> > as well and we still have a few open bugs against the intel X driver
> > regarding VT switch & mode programming, I don't think this is a real
> > kernel regression. It's more likely that some timing or memory layout
> > changed subtly and is causing to to hit one of our existing bugs more
> > frequently that you did before.  Can you file a bug against the intel X
> > driver at
> > bugs.freedesktop.org so we can track it there?  Unless we can find a way
> > to reproduce it reliably it'll probably take a long time to fix, but we
> > don't want to lose it either...
>
> Well, I'll file a bug on bugs.freedesktop.org, but if you don't think
> it's a kernel regression then I'll wait until the final release of
> 2.6.25 comes out (unless you _really_ need me to file it sooner).

Well, given what we've tested so far, it really doesn't seem like a 
framebuffer layer regression nor a DRM regression... I suppose you could try 
bisecting, but given that the problem doesn't happen everytime that might 
take awhile...

> This is what I have in my config:
> > CONFIG_PREEMPT_RCU=y
> > CONFIG_IO_DELAY_NONE=y
>
> By the way is the intel driver that you work on the same that's enabled by:
> > CONFIG_AGP_INTEL=m
> > CONFIG_DRM_I915=m
>
> Or is there another X.org intel driver? And if so how are they
> (agp/drm/X.org) related?

You could try using the X vesa driver instead of the intel driver...

Jesse

^ permalink raw reply	[flat|nested] 25+ messages in thread

* Re: [Regression: 2.6.25-rc5: Blank Screen: Intel 945]
  2008-04-09 15:24                                       ` Jesse Barnes
@ 2008-04-14  3:46                                         ` Justin Madru
  0 siblings, 0 replies; 25+ messages in thread
From: Justin Madru @ 2008-04-14  3:46 UTC (permalink / raw)
  To: Jesse Barnes; +Cc: Rafael J. Wysocki, lkml

Jesse Barnes wrote:
> You could try using the X vesa driver instead of the intel driver...

Ok, so I tried with the vesa X.org driver and it never had the blank screen problem (so far).
There were some screen distortions on mode change but no blank screen.
I noticed that when using the vesa X.org driver the i915 kernel module didn't load.

I think we're getting closer! It seems like it's not a kernel regression but a bug in the intel Xorg driver.
Or maybe an interaction between the i915 DRM kernel module (>=2.6.25) and the intel X.org driver,
because it only happens with the 2.6.25 kernel, and I'd think if it was only an X driver bug,
then it should've happened on other kernel versions.

Justin


^ permalink raw reply	[flat|nested] 25+ messages in thread

end of thread, other threads:[~2008-04-14  3:46 UTC | newest]

Thread overview: 25+ messages (download: mbox.gz / follow: Atom feed)
-- links below jump to the message on this page --
2008-03-12 19:02 [Regression: 2.6.25-rc5: Blank Screen: Intel 945] Justin Madru
2008-03-12 19:36 ` Jesse Barnes
     [not found]   ` <47D8BF6A.9020905@gawab.com>
2008-03-13 17:09     ` Jesse Barnes
2008-03-14  4:22       ` Justin Madru
2008-03-14 17:29         ` Jesse Barnes
2008-03-15  3:48           ` Justin Madru
2008-03-15 17:35             ` Jesse Barnes
2008-03-15 18:16               ` Bryce Harrington
2008-03-17  1:28               ` Justin Madru
2008-03-18 19:07                 ` Bryce Harrington
2008-03-18 20:00                   ` Jesse Barnes
2008-03-18 20:53                     ` Bryce Harrington
2008-03-18 21:14                     ` Bryce Harrington
2008-03-18 21:17                       ` Jesse Barnes
2008-03-19 23:38                         ` Justin Madru
2008-03-19 23:48                           ` Jesse Barnes
2008-03-20  2:00                             ` Bryce Harrington
2008-03-25  3:07                             ` Justin Madru
2008-03-25 20:08                               ` Jesse Barnes
2008-03-26 18:32                                 ` Justin Madru
2008-03-31 19:24                                 ` Justin Madru
2008-04-01 20:22                                   ` Jesse Barnes
2008-04-09  4:56                                     ` Justin Madru
2008-04-09 15:24                                       ` Jesse Barnes
2008-04-14  3:46                                         ` Justin Madru

This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).