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
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
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
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
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
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
[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
[email protected] with the problem.
Thanks,
Jesse
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
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
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
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
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?
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
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
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
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
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
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
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
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
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