after suffering through the i915 "black screen" issue for a while, it was a relief that it finally seemed to be resolved with 2.6.37 or something in tha vicinity. but i just built and booted a 2.6.38-rc2+ kernel on my ubuntu 10.10 system and it once again boots to a black screen.
is this a new known issue? has anyone else seen this?
rday
On Wed, 26 Jan 2011 06:37:20 -0500 (EST), "Robert P. J. Day" rpjday@crashcourse.ca wrote:
after suffering through the i915 "black screen" issue for a while, it was a relief that it finally seemed to be resolved with 2.6.37 or something in tha vicinity. but i just built and booted a 2.6.38-rc2+ kernel on my ubuntu 10.10 system and it once again boots to a black screen.
is this a new known issue? has anyone else seen this?
It all depends. There is a new ACPI backlight issue causing grief, aside from that and lingering issues with the legacy backlight combination mode, I don't think there was a new i915 KMS regression. (We had regressions elsewhere and finally fixed up a few old regressions for UMS and DRI1 and various other OOPS-on-boot. And suspend is a bit hit and miss.)
For extra fun, it appears that sched_autocgroup can trigger a leak of pinned bo eventually hitting a BUG. That's one I'm keen to reproduce.
Without knowing your chipset and seeing a dmesg, I can only guess which problem you are most likely to have hit. -Chris
On Thu, 27 Jan 2011, Chris Wilson wrote:
On Wed, 26 Jan 2011 06:37:20 -0500 (EST), "Robert P. J. Day" rpjday@crashcourse.ca wrote:
after suffering through the i915 "black screen" issue for a while, it was a relief that it finally seemed to be resolved with 2.6.37 or something in tha vicinity. but i just built and booted a 2.6.38-rc2+ kernel on my ubuntu 10.10 system and it once again boots to a black screen.
is this a new known issue? has anyone else seen this?
It all depends. There is a new ACPI backlight issue causing grief, aside from that and lingering issues with the legacy backlight combination mode, I don't think there was a new i915 KMS regression. (We had regressions elsewhere and finally fixed up a few old regressions for UMS and DRI1 and various other OOPS-on-boot. And suspend is a bit hit and miss.)
For extra fun, it appears that sched_autocgroup can trigger a leak of pinned bo eventually hitting a BUG. That's one I'm keen to reproduce.
Without knowing your chipset and seeing a dmesg, I can only guess which problem you are most likely to have hit.
if i have time today, i'll try to bisect. i've built a 2.6.38-rc2 kernel and that seems to work fine. more in a bit while i track this down.
rday
On Thu, 27 Jan 2011, Chris Wilson wrote:
On Wed, 26 Jan 2011 06:37:20 -0500 (EST), "Robert P. J. Day" rpjday@crashcourse.ca wrote:
after suffering through the i915 "black screen" issue for a while, it was a relief that it finally seemed to be resolved with 2.6.37 or something in tha vicinity. but i just built and booted a 2.6.38-rc2+ kernel on my ubuntu 10.10 system and it once again boots to a black screen.
is this a new known issue? has anyone else seen this?
It all depends. There is a new ACPI backlight issue causing grief, aside from that and lingering issues with the legacy backlight combination mode, I don't think there was a new i915 KMS regression. (We had regressions elsewhere and finally fixed up a few old regressions for UMS and DRI1 and various other OOPS-on-boot. And suspend is a bit hit and miss.)
For extra fun, it appears that sched_autocgroup can trigger a leak of pinned bo eventually hitting a BUG. That's one I'm keen to reproduce.
Without knowing your chipset and seeing a dmesg, I can only guess which problem you are most likely to have hit.
here's a little more info if it's helpful. from "lspci -v":
00:02.0 VGA compatible controller: Intel Corporation Core Processor Integrated Graphics Controller (rev 12) (prog-if 00 [VGA controller]) Subsystem: Acer Incorporated [ALI] Device 031c Flags: bus master, fast devsel, latency 0, IRQ 41 Memory at d0000000 (64-bit, non-prefetchable) [size=4M] Memory at c0000000 (64-bit, prefetchable) [size=256M] I/O ports at 3050 [size=8] Expansion ROM at <unassigned> [disabled] Capabilities: <access denied> Kernel driver in use: i915 Kernel modules: i915
also, i just verified that i have a properly booting kernel based on this commit:
commit 58bbf018a70c562437eeae121a5d021ba7fe56a5 Author: Alex Deucher alexdeucher@gmail.com Date: Mon Jan 24 17:14:26 2011 -0500
drm/radeon/kms: add new radeon_info ioctl query for clock crystal freq
Needed for timer queries in the 3D driver.
Signed-off-by: Alex Deucher alexdeucher@gmail.com Signed-off-by: Dave Airlie airlied@gmail.com
i chose that commit since, right after that, there are a couple commits that are heavily i915-related:
abb72c828878a2c69b2cfb33ac30007c8ecd735e 5e82ea99827f6aa122fbb08f8659e76226ce107b
and those would be the next things i check. is there any other info you'd like to see?
rday
On Thu, 27 Jan 2011 06:47:23 -0500 (EST), "Robert P. J. Day" rpjday@crashcourse.ca wrote:
also, i just verified that i have a properly booting kernel based on this commit:
commit 58bbf018a70c562437eeae121a5d021ba7fe56a5 Author: Alex Deucher alexdeucher@gmail.com Date: Mon Jan 24 17:14:26 2011 -0500
drm/radeon/kms: add new radeon_info ioctl query for clock crystal freq Needed for timer queries in the 3D driver. Signed-off-by: Alex Deucher <alexdeucher@gmail.com> Signed-off-by: Dave Airlie <airlied@gmail.com>i chose that commit since, right after that, there are a couple commits that are heavily i915-related:
abb72c828878a2c69b2cfb33ac30007c8ecd735e 5e82ea99827f6aa122fbb08f8659e76226ce107b
and those would be the next things i check. is there any other info you'd like to see?
The only missing detail is what connector is used for the display. Xorg.log or xrandr --verbose are the easiest.
That's a little scary. I'm certainly unaware of a regression post-58bbf018a70c (especially in those recent fixes) and would appreciate a bisect. Thanks! -Chris
On Thu, 27 Jan 2011, Chris Wilson wrote:
On Thu, 27 Jan 2011 06:47:23 -0500 (EST), "Robert P. J. Day" rpjday@crashcourse.ca wrote:
also, i just verified that i have a properly booting kernel based on this commit:
commit 58bbf018a70c562437eeae121a5d021ba7fe56a5 Author: Alex Deucher alexdeucher@gmail.com Date: Mon Jan 24 17:14:26 2011 -0500
drm/radeon/kms: add new radeon_info ioctl query for clock crystal freq Needed for timer queries in the 3D driver. Signed-off-by: Alex Deucher <alexdeucher@gmail.com> Signed-off-by: Dave Airlie <airlied@gmail.com>i chose that commit since, right after that, there are a couple commits that are heavily i915-related:
abb72c828878a2c69b2cfb33ac30007c8ecd735e 5e82ea99827f6aa122fbb08f8659e76226ce107b
and those would be the next things i check. is there any other info you'd like to see?
The only missing detail is what connector is used for the display. Xorg.log or xrandr --verbose are the easiest.
i can supply those for the currently *successful* boot, is that what you're asking? because once we're into black screen territory, there's not a whole lot i can tell you.
rday
On Thu, 27 Jan 2011 07:12:03 -0500 (EST), "Robert P. J. Day" rpjday@crashcourse.ca wrote:
On Thu, 27 Jan 2011, Chris Wilson wrote:
The only missing detail is what connector is used for the display. Xorg.log or xrandr --verbose are the easiest.
i can supply those for the currently *successful* boot, is that what you're asking? because once we're into black screen territory, there's not a whole lot i can tell you.
Indeed. Fortunately the integrated hardware is unlikely to change between boots. But more interesting is if you can pin down the regressing commit. -Chris
On Thu, 27 Jan 2011, Chris Wilson wrote:
On Thu, 27 Jan 2011 07:12:03 -0500 (EST), "Robert P. J. Day" rpjday@crashcourse.ca wrote:
On Thu, 27 Jan 2011, Chris Wilson wrote:
The only missing detail is what connector is used for the display. Xorg.log or xrandr --verbose are the easiest.
i can supply those for the currently *successful* boot, is that what you're asking? because once we're into black screen territory, there's not a whole lot i can tell you.
Indeed. Fortunately the integrated hardware is unlikely to change between boots.
that was sarcasm, wasn't it? :-)
But more interesting is if you can pin down the regressing commit.
working on that now. here's Xorg.0.log for the current system:
[ 40.877] X.Org X Server 1.9.0 Release Date: 2010-08-20 [ 40.877] X Protocol Version 11, Revision 0 [ 40.877] Build Operating System: Linux 2.6.24-28-server x86_64 Ubuntu [ 40.877] Current Operating System: Linux lynx 2.6.38-rc2+ #15 SMP Thu Jan 27 06:24:55 EST 2011 x86_64 [ 40.877] Kernel command line: BOOT_IMAGE=/vmlinuz-2.6.38-rc2+ root=/dev/mapper/lynx-root ro quiet splash [ 40.877] Build Date: 09 January 2011 12:14:27PM [ 40.877] xorg-server 2:1.9.0-0ubuntu7.3 (For technical support please see http://www.ubuntu.com/support) [ 40.877] Current version of pixman: 0.18.4 [ 40.877] Before reporting problems, check http://wiki.x.org to make sure that you have the latest version. [ 40.877] Markers: (--) probed, (**) from config file, (==) default setting, (++) from command line, (!!) notice, (II) informational, (WW) warning, (EE) error, (NI) not implemented, (??) unknown. [ 40.877] (==) Log file: "/var/log/Xorg.0.log", Time: Thu Jan 27 06:39:06 2011 [ 40.955] (==) Using system config directory "/usr/share/X11/xorg.conf.d" [ 41.012] (==) No Layout section. Using the first Screen section. [ 41.013] (==) No screen section available. Using defaults. [ 41.013] (**) |-->Screen "Default Screen Section" (0) [ 41.013] (**) | |-->Monitor "<default monitor>" [ 41.013] (==) No monitor specified for screen "Default Screen Section". Using a default monitor configuration. [ 41.013] (==) Automatically adding devices [ 41.013] (==) Automatically enabling devices [ 41.039] (WW) The directory "/usr/share/fonts/X11/cyrillic" does not exist. [ 41.039] Entry deleted from font path. [ 41.086] (==) FontPath set to: /usr/share/fonts/X11/misc, /usr/share/fonts/X11/100dpi/:unscaled, /usr/share/fonts/X11/75dpi/:unscaled, /usr/share/fonts/X11/Type1, /usr/share/fonts/X11/100dpi, /usr/share/fonts/X11/75dpi, /var/lib/defoma/x-ttcidfont-conf.d/dirs/TrueType, built-ins [ 41.086] (==) ModulePath set to "/usr/lib/xorg/extra-modules,/usr/lib/xorg/modules" [ 41.086] (II) The server relies on udev to provide the list of input devices. If no devices become available, reconfigure udev or disable AutoAddDevices. [ 41.086] (II) Loader magic: 0x7d17a0 [ 41.086] (II) Module ABI versions: [ 41.086] X.Org ANSI C Emulation: 0.4 [ 41.086] X.Org Video Driver: 8.0 [ 41.086] X.Org XInput driver : 11.0 [ 41.086] X.Org Server Extension : 4.0 [ 41.087] (--) PCI:*(0:0:2:0) 8086:0046:1025:031c rev 18, Mem @ 0xd0000000/4194304, 0xc0000000/268435456, I/O @ 0x00003050/8 [ 41.087] (WW) Open ACPI failed (/var/run/acpid.socket) (No such file or directory) [ 41.087] (II) LoadModule: "extmod" [ 41.160] (II) Loading /usr/lib/xorg/modules/extensions/libextmod.so [ 41.167] (II) Module extmod: vendor="X.Org Foundation" [ 41.167] compiled for 1.9.0, module version = 1.0.0 [ 41.167] Module class: X.Org Server Extension [ 41.167] ABI class: X.Org Server Extension, version 4.0 [ 41.167] (II) Loading extension MIT-SCREEN-SAVER [ 41.167] (II) Loading extension XFree86-VidModeExtension [ 41.167] (II) Loading extension XFree86-DGA [ 41.167] (II) Loading extension DPMS [ 41.167] (II) Loading extension XVideo [ 41.167] (II) Loading extension XVideo-MotionCompensation [ 41.167] (II) Loading extension X-Resource [ 41.167] (II) LoadModule: "dbe" [ 41.168] (II) Loading /usr/lib/xorg/modules/extensions/libdbe.so [ 41.173] (II) Module dbe: vendor="X.Org Foundation" [ 41.173] compiled for 1.9.0, module version = 1.0.0 [ 41.174] Module class: X.Org Server Extension [ 41.174] ABI class: X.Org Server Extension, version 4.0 [ 41.174] (II) Loading extension DOUBLE-BUFFER [ 41.174] (II) LoadModule: "glx" [ 41.174] (II) Loading /usr/lib/xorg/modules/extensions/libglx.so [ 41.190] (II) Module glx: vendor="X.Org Foundation" [ 41.190] compiled for 1.9.0, module version = 1.0.0 [ 41.190] ABI class: X.Org Server Extension, version 4.0 [ 41.190] (==) AIGLX enabled [ 41.190] (II) Loading extension GLX [ 41.191] (II) LoadModule: "record" [ 41.191] (II) Loading /usr/lib/xorg/modules/extensions/librecord.so [ 41.202] (II) Module record: vendor="X.Org Foundation" [ 41.202] compiled for 1.9.0, module version = 1.13.0 [ 41.202] Module class: X.Org Server Extension [ 41.203] ABI class: X.Org Server Extension, version 4.0 [ 41.203] (II) Loading extension RECORD [ 41.203] (II) LoadModule: "dri" [ 41.203] (II) Loading /usr/lib/xorg/modules/extensions/libdri.so [ 41.215] (II) Module dri: vendor="X.Org Foundation" [ 41.215] compiled for 1.9.0, module version = 1.0.0 [ 41.215] ABI class: X.Org Server Extension, version 4.0 [ 41.215] (II) Loading extension XFree86-DRI [ 41.215] (II) LoadModule: "dri2" [ 41.215] (II) Loading /usr/lib/xorg/modules/extensions/libdri2.so [ 41.216] (II) Module dri2: vendor="X.Org Foundation" [ 41.216] compiled for 1.9.0, module version = 1.2.0 [ 41.216] ABI class: X.Org Server Extension, version 4.0 [ 41.216] (II) Loading extension DRI2 [ 41.216] (==) Matched intel as autoconfigured driver 0 [ 41.216] (==) Matched vesa as autoconfigured driver 1 [ 41.216] (==) Matched fbdev as autoconfigured driver 2 [ 41.216] (==) Assigned the driver to the xf86ConfigLayout [ 41.216] (II) LoadModule: "intel" [ 41.223] (II) Loading /usr/lib/xorg/modules/drivers/intel_drv.so [ 41.241] (II) Module intel: vendor="X.Org Foundation" [ 41.241] compiled for 1.9.0, module version = 2.12.0 [ 41.241] Module class: X.Org Video Driver [ 41.241] ABI class: X.Org Video Driver, version 8.0 [ 41.241] (II) LoadModule: "vesa" [ 41.242] (II) Loading /usr/lib/xorg/modules/drivers/vesa_drv.so [ 41.256] (II) Module vesa: vendor="X.Org Foundation" [ 41.256] compiled for 1.8.99.905, module version = 2.3.0 [ 41.256] Module class: X.Org Video Driver [ 41.256] ABI class: X.Org Video Driver, version 8.0 [ 41.256] (II) LoadModule: "fbdev" [ 41.256] (II) Loading /usr/lib/xorg/modules/drivers/fbdev_drv.so [ 41.264] (II) Module fbdev: vendor="X.Org Foundation" [ 41.264] compiled for 1.8.99.905, module version = 0.4.2 [ 41.264] ABI class: X.Org Video Driver, version 8.0 [ 41.264] (II) intel: Driver for Intel Integrated Graphics Chipsets: i810, i810-dc100, i810e, i815, i830M, 845G, 852GM/855GM, 865G, 915G, E7221 (i915), 915GM, 945G, 945GM, 945GME, Pineview GM, Pineview G, 965G, G35, 965Q, 946GZ, 965GM, 965GME/GLE, G33, Q35, Q33, GM45, 4 Series, G45/G43, Q45/Q43, G41, B43, B43, Clarkdale, Arrandale, Sandybridge, Sandybridge, Sandybridge, Sandybridge, Sandybridge, Sandybridge, Sandybridge [ 41.265] (II) VESA: driver for VESA chipsets: vesa [ 41.265] (II) FBDEV: driver for framebuffer: fbdev [ 41.265] (++) using VT number 7
[ 41.265] (WW) Falling back to old probe method for vesa [ 41.265] (WW) Falling back to old probe method for fbdev [ 41.265] (II) Loading sub module "fbdevhw" [ 41.265] (II) LoadModule: "fbdevhw" [ 41.266] (II) Loading /usr/lib/xorg/modules/libfbdevhw.so [ 41.278] (II) Module fbdevhw: vendor="X.Org Foundation" [ 41.278] compiled for 1.9.0, module version = 0.0.2 [ 41.278] ABI class: X.Org Video Driver, version 8.0 [ 41.280] drmOpenDevice: node name is /dev/dri/card0 [ 41.280] drmOpenDevice: open result is 8, (OK) [ 41.280] drmOpenByBusid: Searching for BusID pci:0000:00:02.0 [ 41.280] drmOpenDevice: node name is /dev/dri/card0 [ 41.280] drmOpenDevice: open result is 8, (OK) [ 41.280] drmOpenByBusid: drmOpenMinor returns 8 [ 41.280] drmOpenByBusid: drmGetBusid reports pci:0000:00:02.0 [ 41.280] (II) intel(0): Creating default Display subsection in Screen section "Default Screen Section" for depth/fbbpp 24/32 [ 41.280] (==) intel(0): Depth 24, (--) framebuffer bpp 32 [ 41.280] (==) intel(0): RGB weight 888 [ 41.280] (==) intel(0): Default visual is TrueColor [ 41.280] (II) intel(0): Integrated Graphics Chipset: Intel(R) Arrandale [ 41.280] (--) intel(0): Chipset: "Arrandale" [ 41.280] (==) intel(0): video overlay key set to 0x101fe [ 41.281] (II) intel(0): Output LVDS1 has no monitor section [ 41.281] (II) intel(0): found backlight control interface /sys/class/backlight/acpi_video1 [ 41.380] (II) intel(0): Output VGA1 has no monitor section [ 41.384] (II) intel(0): Output HDMI1 has no monitor section [ 41.385] (II) intel(0): Output DP1 has no monitor section [ 41.386] (II) intel(0): EDID for output LVDS1 [ 41.386] (II) intel(0): Manufacturer: SEC Model: 3051 Serial#: 0 [ 41.386] (II) intel(0): Year: 2008 Week: 0 [ 41.386] (II) intel(0): EDID Version: 1.3 [ 41.386] (II) intel(0): Digital Display Input [ 41.386] (II) intel(0): Max Image Size [cm]: horiz.: 39 vert.: 23 [ 41.386] (II) intel(0): Gamma: 2.20 [ 41.386] (II) intel(0): No DPMS capabilities specified [ 41.386] (II) intel(0): Supported color encodings: RGB 4:4:4 YCrCb 4:4:4 [ 41.386] (II) intel(0): First detailed timing is preferred mode [ 41.386] (II) intel(0): redX: 0.600 redY: 0.340 greenX: 0.310 greenY: 0.560 [ 41.386] (II) intel(0): blueX: 0.150 blueY: 0.130 whiteX: 0.313 whiteY: 0.329 [ 41.386] (II) intel(0): Manufacturer's mask: 0 [ 41.386] (II) intel(0): Supported detailed timing: [ 41.386] (II) intel(0): clock: 107.8 MHz Image Size: 398 x 232 mm [ 41.386] (II) intel(0): h_active: 1600 h_sync: 1648 h_sync_end 1680 h_blank_end 1892 h_border: 0 [ 41.386] (II) intel(0): v_active: 900 v_sync: 902 v_sync_end 908 v_blanking: 950 v_border: 0 [ 41.386] (II) intel(0): Unknown vendor-specific block f [ 41.386] (II) intel(0): SAMSUNG [ 41.386] (II) intel(0): 173KT01-A01 [ 41.386] (II) intel(0): EDID (in hex): [ 41.386] (II) intel(0): 00ffffffffffff004ca3513000000000 [ 41.386] (II) intel(0): 00120103802717780a859599574f8f26 [ 41.386] (II) intel(0): 21505400000001010101010101010101 [ 41.386] (II) intel(0): 010101010101202a4024618432303020 [ 41.386] (II) intel(0): 26008ee8100000190000000f00000000 [ 41.386] (II) intel(0): 00000000001eb4027400000000fe0053 [ 41.386] (II) intel(0): 414d53554e470a2020202020000000fe [ 41.386] (II) intel(0): 003137334b5430312d4130310a2000a4 [ 41.386] (II) intel(0): EDID vendor "SEC", prod id 12369 [ 41.386] (II) intel(0): Printing DDC gathered Modelines: [ 41.386] (II) intel(0): Modeline "1600x900"x0.0 107.84 1600 1648 1680 1892 900 902 908 950 -hsync -vsync (57.0 kHz) [ 41.386] (II) intel(0): Not using default mode "320x240" (doublescan mode not supported) [ 41.386] (II) intel(0): Not using default mode "400x300" (doublescan mode not supported) [ 41.386] (II) intel(0): Not using default mode "400x300" (doublescan mode not supported) [ 41.386] (II) intel(0): Not using default mode "512x384" (doublescan mode not supported) [ 41.386] (II) intel(0): Not using default mode "640x480" (doublescan mode not supported) [ 41.386] (II) intel(0): Not using default mode "640x512" (doublescan mode not supported) [ 41.386] (II) intel(0): Not using default mode "800x600" (doublescan mode not supported) [ 41.386] (II) intel(0): Not using default mode "896x672" (doublescan mode not supported) [ 41.386] (II) intel(0): Not using default mode "928x696" (doublescan mode not supported) [ 41.386] (II) intel(0): Not using default mode "960x720" (doublescan mode not supported) [ 41.386] (II) intel(0): Not using default mode "576x432" (doublescan mode not supported) [ 41.386] (II) intel(0): Not using default mode "680x384" (doublescan mode not supported) [ 41.386] (II) intel(0): Not using default mode "680x384" (doublescan mode not supported) [ 41.386] (II) intel(0): Not using default mode "700x525" (doublescan mode not supported) [ 41.386] (II) intel(0): Not using default mode "720x450" (doublescan mode not supported) [ 41.386] (II) intel(0): Not using default mode "800x512" (doublescan mode not supported) [ 41.387] (II) intel(0): Not using default mode "840x525" (doublescan mode not supported) [ 41.387] (II) intel(0): Not using default mode "840x525" (doublescan mode not supported) [ 41.387] (II) intel(0): Not using default mode "960x540" (doublescan mode not supported) [ 41.387] (II) intel(0): Not using default mode "960x600" (doublescan mode not supported) [ 41.387] (II) intel(0): Not using default mode "1024x768" (doublescan mode not supported) [ 41.387] (II) intel(0): Printing probed modes for output LVDS1 [ 41.387] (II) intel(0): Modeline "1600x900"x60.0 107.84 1600 1648 1680 1892 900 902 908 950 -hsync -vsync (57.0 kHz) [ 41.387] (II) intel(0): Modeline "1440x900"x59.9 106.50 1440 1520 1672 1904 900 903 909 934 -hsync +vsync (55.9 kHz) [ 41.387] (II) intel(0): Modeline "1360x768"x59.8 84.75 1360 1432 1568 1776 768 771 781 798 -hsync +vsync (47.7 kHz) [ 41.387] (II) intel(0): Modeline "1360x768"x60.0 72.00 1360 1408 1440 1520 768 771 781 790 +hsync -vsync (47.4 kHz) [ 41.387] (II) intel(0): Modeline "1152x864"x60.0 81.62 1152 1216 1336 1520 864 865 868 895 -hsync +vsync (53.7 kHz) [ 41.387] (II) intel(0): Modeline "1024x768"x60.0 65.00 1024 1048 1184 1344 768 771 777 806 -hsync -vsync (48.4 kHz) [ 41.387] (II) intel(0): Modeline "800x600"x60.3 40.00 800 840 968 1056 600 601 605 628 +hsync +vsync (37.9 kHz) [ 41.387] (II) intel(0): Modeline "800x600"x56.2 36.00 800 824 896 1024 600 601 603 625 +hsync +vsync (35.2 kHz) [ 41.387] (II) intel(0): Modeline "640x480"x59.9 25.18 640 656 752 800 480 490 492 525 -hsync -vsync (31.5 kHz) [ 41.387] (II) intel(0): EDID for output VGA1 [ 41.391] (II) intel(0): EDID for output HDMI1 [ 41.393] (II) intel(0): EDID for output DP1 [ 41.393] (II) intel(0): Output LVDS1 connected [ 41.393] (II) intel(0): Output VGA1 disconnected [ 41.393] (II) intel(0): Output HDMI1 disconnected [ 41.393] (II) intel(0): Output DP1 disconnected [ 41.393] (II) intel(0): Using exact sizes for initial modes [ 41.393] (II) intel(0): Output LVDS1 using initial mode 1600x900 [ 41.393] (II) intel(0): Using default gamma of (1.0, 1.0, 1.0) unless otherwise stated. [ 41.393] (II) intel(0): Kernel page flipping support detected, but forcibly disabled. [ 41.393] (**) intel(0): Display dimensions: (390, 230) mm [ 41.393] (**) intel(0): DPI set to (104, 99) [ 41.393] (II) Loading sub module "fb" [ 41.393] (II) LoadModule: "fb" [ 41.393] (II) Loading /usr/lib/xorg/modules/libfb.so [ 41.400] (II) Module fb: vendor="X.Org Foundation" [ 41.400] compiled for 1.9.0, module version = 1.0.0 [ 41.400] ABI class: X.Org ANSI C Emulation, version 0.4 [ 41.400] (II) UnloadModule: "vesa" [ 41.400] (II) Unloading /usr/lib/xorg/modules/drivers/vesa_drv.so [ 41.400] (II) UnloadModule: "fbdev" [ 41.400] (II) Unloading /usr/lib/xorg/modules/drivers/fbdev_drv.so [ 41.400] (II) UnloadModule: "fbdevhw" [ 41.400] (II) Unloading /usr/lib/xorg/modules/libfbdevhw.so [ 41.400] (==) Depth 24 pixmap format is 32 bpp [ 41.400] (II) intel(0): [DRI2] Setup complete [ 41.400] (II) intel(0): [DRI2] DRI driver: i965 [ 41.400] (**) intel(0): Tiling enabled [ 41.400] (**) intel(0): SwapBuffers wait enabled [ 41.400] (==) intel(0): VideoRam: 262144 KB [ 41.400] (II) intel(0): Allocated new frame buffer 1600x900 stride 6656, tiled [ 41.441] (II) UXA(0): Driver registered support for the following operations: [ 41.442] (II) solid [ 41.442] (II) copy [ 41.442] (II) composite (RENDER acceleration) [ 41.442] (II) put_image [ 41.442] (II) get_image [ 41.442] (==) intel(0): Backing store disabled [ 41.442] (==) intel(0): Silken mouse enabled [ 41.442] (II) intel(0): Initializing HW Cursor [ 41.510] (II) intel(0): RandR 1.2 enabled, ignore the following RandR disabled message. [ 41.511] (==) intel(0): DPMS enabled [ 41.511] (==) intel(0): Intel XvMC decoder enabled [ 41.511] (II) intel(0): Set up textured video [ 41.511] (II) intel(0): [XvMC] xvmc_vld driver initialized. [ 41.511] (II) intel(0): direct rendering: DRI2 Enabled [ 41.511] (--) RandR disabled [ 41.511] (II) Initializing built-in extension Generic Event Extension [ 41.511] (II) Initializing built-in extension SHAPE [ 41.511] (II) Initializing built-in extension MIT-SHM [ 41.511] (II) Initializing built-in extension XInputExtension [ 41.511] (II) Initializing built-in extension XTEST [ 41.511] (II) Initializing built-in extension BIG-REQUESTS [ 41.511] (II) Initializing built-in extension SYNC [ 41.511] (II) Initializing built-in extension XKEYBOARD [ 41.511] (II) Initializing built-in extension XC-MISC [ 41.511] (II) Initializing built-in extension SECURITY [ 41.511] (II) Initializing built-in extension XINERAMA [ 41.511] (II) Initializing built-in extension XFIXES [ 41.511] (II) Initializing built-in extension RENDER [ 41.511] (II) Initializing built-in extension RANDR [ 41.511] (II) Initializing built-in extension COMPOSITE [ 41.511] (II) Initializing built-in extension DAMAGE [ 41.511] (II) Initializing built-in extension GESTURE [ 41.633] (II) AIGLX: enabled GLX_MESA_copy_sub_buffer [ 41.633] (II) AIGLX: enabled GLX_INTEL_swap_event [ 41.633] (II) AIGLX: enabled GLX_SGI_swap_control and GLX_MESA_swap_control [ 41.633] (II) AIGLX: enabled GLX_SGI_make_current_read [ 41.633] (II) AIGLX: GLX_EXT_texture_from_pixmap backed by buffer objects [ 41.633] (II) AIGLX: Loaded and initialized /usr/lib/dri/i965_dri.so [ 41.633] (II) GLX: Initialized DRI2 GL provider for screen 0 [ 41.634] (II) intel(0): Setting screen physical size to 423 x 238 [ 41.840] (II) XKB: reuse xkmfile /var/lib/xkb/server-B20D7FC79C7F597315E3E501AEF10E0D866E8E92.xkm [ 41.856] (II) config/udev: Adding input device Power Button (/dev/input/event3) [ 41.856] (**) Power Button: Applying InputClass "evdev keyboard catchall" [ 41.856] (II) LoadModule: "evdev" [ 41.856] (II) Loading /usr/lib/xorg/modules/input/evdev_drv.so [ 41.889] (II) Module evdev: vendor="X.Org Foundation" [ 41.889] compiled for 1.9.0, module version = 2.3.2 [ 41.889] Module class: X.Org XInput Driver [ 41.889] ABI class: X.Org XInput driver, version 11.0 [ 41.889] (**) Power Button: always reports core events [ 41.889] (**) Power Button: Device: "/dev/input/event3" [ 42.000] (II) Power Button: Found keys [ 42.000] (II) Power Button: Configuring as keyboard [ 42.000] (II) XINPUT: Adding extended input device "Power Button" (type: KEYBOARD) [ 42.000] (**) Option "xkb_rules" "evdev" [ 42.000] (**) Option "xkb_model" "pc105" [ 42.000] (**) Option "xkb_layout" "us" [ 42.000] (**) Option "xkb_options" "lv3:ralt_switch" [ 42.003] (II) XKB: reuse xkmfile /var/lib/xkb/server-0C76CA335E924C2441A31FBFED02D59A89874CA6.xkm [ 42.004] (II) config/udev: Adding input device Video Bus (/dev/input/event7) [ 42.005] (**) Video Bus: Applying InputClass "evdev keyboard catchall" [ 42.005] (**) Video Bus: always reports core events [ 42.005] (**) Video Bus: Device: "/dev/input/event7" [ 42.070] (II) Video Bus: Found keys [ 42.070] (II) Video Bus: Configuring as keyboard [ 42.070] (II) XINPUT: Adding extended input device "Video Bus" (type: KEYBOARD) [ 42.070] (**) Option "xkb_rules" "evdev" [ 42.070] (**) Option "xkb_model" "pc105" [ 42.070] (**) Option "xkb_layout" "us" [ 42.070] (**) Option "xkb_options" "lv3:ralt_switch" [ 42.071] (II) config/udev: Adding input device Power Button (/dev/input/event0) [ 42.071] (**) Power Button: Applying InputClass "evdev keyboard catchall" [ 42.071] (**) Power Button: always reports core events [ 42.071] (**) Power Button: Device: "/dev/input/event0" [ 42.160] (II) Power Button: Found keys [ 42.160] (II) Power Button: Configuring as keyboard [ 42.160] (II) XINPUT: Adding extended input device "Power Button" (type: KEYBOARD) [ 42.160] (**) Option "xkb_rules" "evdev" [ 42.160] (**) Option "xkb_model" "pc105" [ 42.160] (**) Option "xkb_layout" "us" [ 42.160] (**) Option "xkb_options" "lv3:ralt_switch" [ 42.160] (II) config/udev: Adding input device Lid Switch (/dev/input/event1) [ 42.160] (II) No input driver/identifier specified (ignoring) [ 42.161] (II) config/udev: Adding input device Sleep Button (/dev/input/event2) [ 42.161] (**) Sleep Button: Applying InputClass "evdev keyboard catchall" [ 42.161] (**) Sleep Button: always reports core events [ 42.161] (**) Sleep Button: Device: "/dev/input/event2" [ 42.250] (II) Sleep Button: Found keys [ 42.250] (II) Sleep Button: Configuring as keyboard [ 42.250] (II) XINPUT: Adding extended input device "Sleep Button" (type: KEYBOARD) [ 42.250] (**) Option "xkb_rules" "evdev" [ 42.250] (**) Option "xkb_model" "pc105" [ 42.250] (**) Option "xkb_layout" "us" [ 42.250] (**) Option "xkb_options" "lv3:ralt_switch" [ 42.253] (II) config/udev: Adding input device Video WebCam (/dev/input/event5) [ 42.253] (**) Video WebCam: Applying InputClass "evdev keyboard catchall" [ 42.253] (**) Video WebCam: always reports core events [ 42.253] (**) Video WebCam: Device: "/dev/input/event5" [ 42.340] (II) Video WebCam: Found keys [ 42.340] (II) Video WebCam: Configuring as keyboard [ 42.340] (II) XINPUT: Adding extended input device "Video WebCam" (type: KEYBOARD) [ 42.340] (**) Option "xkb_rules" "evdev" [ 42.340] (**) Option "xkb_model" "pc105" [ 42.340] (**) Option "xkb_layout" "us" [ 42.340] (**) Option "xkb_options" "lv3:ralt_switch" [ 42.341] (II) config/udev: Adding input device HDA Intel Headphone (/dev/input/event8) [ 42.341] (II) No input driver/identifier specified (ignoring) [ 42.345] (II) config/udev: Adding input device AT Translated Set 2 keyboard (/dev/input/event4) [ 42.345] (**) AT Translated Set 2 keyboard: Applying InputClass "evdev keyboard catchall" [ 42.345] (**) AT Translated Set 2 keyboard: always reports core events [ 42.345] (**) AT Translated Set 2 keyboard: Device: "/dev/input/event4" [ 42.430] (II) AT Translated Set 2 keyboard: Found keys [ 42.430] (II) AT Translated Set 2 keyboard: Configuring as keyboard [ 42.430] (II) XINPUT: Adding extended input device "AT Translated Set 2 keyboard" (type: KEYBOARD) [ 42.430] (**) Option "xkb_rules" "evdev" [ 42.430] (**) Option "xkb_model" "pc105" [ 42.430] (**) Option "xkb_layout" "us" [ 42.430] (**) Option "xkb_options" "lv3:ralt_switch" [ 42.430] (II) config/udev: Adding input device SynPS/2 Synaptics TouchPad (/dev/input/event6) [ 42.430] (**) SynPS/2 Synaptics TouchPad: Applying InputClass "evdev touchpad catchall" [ 42.430] (**) SynPS/2 Synaptics TouchPad: Applying InputClass "touchpad catchall" [ 42.430] (II) LoadModule: "synaptics" [ 42.431] (II) Loading /usr/lib/xorg/modules/input/synaptics_drv.so [ 42.457] (II) Module synaptics: vendor="X.Org Foundation" [ 42.457] compiled for 1.9.0, module version = 1.2.2 [ 42.457] Module class: X.Org XInput Driver [ 42.457] ABI class: X.Org XInput driver, version 11.0 [ 42.457] (II) Synaptics touchpad driver version 1.2.2 [ 42.457] (**) Option "Device" "/dev/input/event6" [ 42.830] (II) SynPS/2 Synaptics TouchPad: x-axis range 1472 - 5584 [ 42.830] (II) SynPS/2 Synaptics TouchPad: y-axis range 1408 - 4434 [ 42.830] (II) SynPS/2 Synaptics TouchPad: pressure range 0 - 255 [ 42.830] (II) SynPS/2 Synaptics TouchPad: finger width range 0 - 15 [ 42.830] (II) SynPS/2 Synaptics TouchPad: buttons: left right double triple [ 43.100] (--) SynPS/2 Synaptics TouchPad: touchpad found [ 43.100] (**) SynPS/2 Synaptics TouchPad: always reports core events [ 43.260] (II) XINPUT: Adding extended input device "SynPS/2 Synaptics TouchPad" (type: TOUCHPAD) [ 43.260] (**) SynPS/2 Synaptics TouchPad: (accel) keeping acceleration scheme 1 [ 43.260] (**) SynPS/2 Synaptics TouchPad: (accel) acceleration profile 0 [ 43.260] (**) SynPS/2 Synaptics TouchPad: (accel) acceleration factor: 2.000 [ 43.260] (**) SynPS/2 Synaptics TouchPad: (accel) acceleration threshold: 4 [ 43.430] (--) SynPS/2 Synaptics TouchPad: touchpad found [ 43.430] (II) config/udev: Adding input device SynPS/2 Synaptics TouchPad (/dev/input/mouse0) [ 43.430] (II) No input driver/identifier specified (ignoring) [ 55.589] (II) intel(0): EDID vendor "SEC", prod id 12369 [ 55.589] (II) intel(0): Printing DDC gathered Modelines: [ 55.589] (II) intel(0): Modeline "1600x900"x0.0 107.84 1600 1648 1680 1892 900 902 908 950 -hsync -vsync (57.0 kHz) [ 55.596] (II) intel(0): EDID vendor "SEC", prod id 12369 [ 55.596] (II) intel(0): Printing DDC gathered Modelines: [ 55.596] (II) intel(0): Modeline "1600x900"x0.0 107.84 1600 1648 1680 1892 900 902 908 950 -hsync -vsync (57.0 kHz) [ 55.648] (II) intel(0): EDID vendor "SEC", prod id 12369 [ 55.648] (II) intel(0): Printing DDC gathered Modelines: [ 55.648] (II) intel(0): Modeline "1600x900"x0.0 107.84 1600 1648 1680 1892 900 902 908 950 -hsync -vsync (57.0 kHz) [ 55.655] (II) intel(0): EDID vendor "SEC", prod id 12369 [ 55.655] (II) intel(0): Printing DDC gathered Modelines: [ 55.655] (II) intel(0): Modeline "1600x900"x0.0 107.84 1600 1648 1680 1892 900 902 908 950 -hsync -vsync (57.0 kHz) [ 87.420] (II) intel(0): EDID vendor "SEC", prod id 12369 [ 87.420] (II) intel(0): Printing DDC gathered Modelines: [ 87.420] (II) intel(0): Modeline "1600x900"x0.0 107.84 1600 1648 1680 1892 900 902 908 950 -hsync -vsync (57.0 kHz) [ 87.710] (II) intel(0): EDID vendor "SEC", prod id 12369 [ 87.710] (II) intel(0): Printing DDC gathered Modelines: [ 87.710] (II) intel(0): Modeline "1600x900"x0.0 107.84 1600 1648 1680 1892 900 902 908 950 -hsync -vsync (57.0 kHz) [ 87.717] (II) intel(0): EDID vendor "SEC", prod id 12369 [ 87.717] (II) intel(0): Printing DDC gathered Modelines: [ 87.717] (II) intel(0): Modeline "1600x900"x0.0 107.84 1600 1648 1680 1892 900 902 908 950 -hsync -vsync (57.0 kHz) [ 87.723] (II) intel(0): EDID vendor "SEC", prod id 12369 [ 87.723] (II) intel(0): Printing DDC gathered Modelines: [ 87.723] (II) intel(0): Modeline "1600x900"x0.0 107.84 1600 1648 1680 1892 900 902 908 950 -hsync -vsync (57.0 kHz) [ 109.175] (II) intel(0): EDID vendor "SEC", prod id 12369 [ 109.175] (II) intel(0): Printing DDC gathered Modelines: [ 109.175] (II) intel(0): Modeline "1600x900"x0.0 107.84 1600 1648 1680 1892 900 902 908 950 -hsync -vsync (57.0 kHz) [ 1075.332] (II) intel(0): EDID vendor "SEC", prod id 12369 [ 1075.332] (II) intel(0): Printing DDC gathered Modelines: [ 1075.333] (II) intel(0): Modeline "1600x900"x0.0 107.84 1600 1648 1680 1892 900 902 908 950 -hsync -vsync (57.0 kHz) [ 1599.782] (II) config/udev: Adding input device USB OpticalWheel Mouse (/dev/input/event9) [ 1599.782] (**) USB OpticalWheel Mouse: Applying InputClass "evdev pointer catchall" [ 1599.782] (**) USB OpticalWheel Mouse: always reports core events [ 1599.782] (**) USB OpticalWheel Mouse: Device: "/dev/input/event9" [ 1599.840] (II) USB OpticalWheel Mouse: Found 3 mouse buttons [ 1599.840] (II) USB OpticalWheel Mouse: Found scroll wheel(s) [ 1599.840] (II) USB OpticalWheel Mouse: Found relative axes [ 1599.840] (II) USB OpticalWheel Mouse: Found x and y relative axes [ 1599.840] (II) USB OpticalWheel Mouse: Configuring as mouse [ 1599.840] (**) USB OpticalWheel Mouse: YAxisMapping: buttons 4 and 5 [ 1599.840] (**) USB OpticalWheel Mouse: EmulateWheelButton: 4, EmulateWheelInertia: 10, EmulateWheelTimeout: 200 [ 1599.840] (II) XINPUT: Adding extended input device "USB OpticalWheel Mouse" (type: MOUSE) [ 1599.840] (II) USB OpticalWheel Mouse: initialized for relative axes. [ 1599.841] (II) config/udev: Adding input device USB OpticalWheel Mouse (/dev/input/mouse1) [ 1599.841] (II) No input driver/identifier specified (ignoring) [ 1894.896] (II) intel(0): EDID vendor "SEC", prod id 12369 [ 1894.896] (II) intel(0): Printing DDC gathered Modelines: [ 1894.896] (II) intel(0): Modeline "1600x900"x0.0 107.84 1600 1648 1680 1892 900 902 908 950 -hsync -vsync (57.0 kHz) [ 1899.953] (II) intel(0): EDID vendor "SEC", prod id 12369 [ 1899.953] (II) intel(0): Printing DDC gathered Modelines: [ 1899.953] (II) intel(0): Modeline "1600x900"x0.0 107.84 1600 1648 1680 1892 900 902 908 950 -hsync -vsync (57.0 kHz) [ 2782.099] (II) intel(0): EDID vendor "SEC", prod id 12369 [ 2782.137] (II) intel(0): Printing DDC gathered Modelines: [ 2782.137] (II) intel(0): Modeline "1600x900"x0.0 107.84 1600 1648 1680 1892 900 902 908 950 -hsync -vsync (57.0 kHz)
and here's "xrandr --verbose"
Screen 0: minimum 320 x 200, current 1600 x 900, maximum 8192 x 8192 LVDS1 connected 1600x900+0+0 (0x45) normal (normal left inverted right x axis y axis) 398mm x 232mm Identifier: 0x41 Timestamp: 40839 Subpixel: horizontal rgb Gamma: 1.0:1.0:1.0 Brightness: 1.0 Clones: CRTC: 0 CRTCs: 0 1 Transform: 1.000000 0.000000 0.000000 0.000000 1.000000 0.000000 0.000000 0.000000 1.000000 filter: EDID: 00ffffffffffff004ca3513000000000 00120103802717780a859599574f8f26 21505400000001010101010101010101 010101010101202a4024618432303020 26008ee8100000190000000f00000000 00000000001eb4027400000000fe0053 414d53554e470a2020202020000000fe 003137334b5430312d4130310a2000a4 BACKLIGHT: 1 (0x00000001) range: (0,9) Backlight: 1 (0x00000001) range: (0,9) scaling mode: Full aspect supported: None Full Center Full aspect 1600x900 (0x45) 107.8MHz -HSync -VSync *current +preferred h: width 1600 start 1648 end 1680 total 1892 skew 0 clock 57.0KHz v: height 900 start 902 end 908 total 950 clock 60.0Hz 1440x900 (0x46) 106.5MHz -HSync +VSync h: width 1440 start 1520 end 1672 total 1904 skew 0 clock 55.9KHz v: height 900 start 903 end 909 total 934 clock 59.9Hz 1360x768 (0x47) 84.8MHz -HSync +VSync h: width 1360 start 1432 end 1568 total 1776 skew 0 clock 47.7KHz v: height 768 start 771 end 781 total 798 clock 59.8Hz 1360x768 (0x48) 72.0MHz +HSync -VSync h: width 1360 start 1408 end 1440 total 1520 skew 0 clock 47.4KHz v: height 768 start 771 end 781 total 790 clock 60.0Hz 1152x864 (0x49) 81.6MHz -HSync +VSync h: width 1152 start 1216 end 1336 total 1520 skew 0 clock 53.7KHz v: height 864 start 865 end 868 total 895 clock 60.0Hz 1024x768 (0x4a) 65.0MHz -HSync -VSync h: width 1024 start 1048 end 1184 total 1344 skew 0 clock 48.4KHz v: height 768 start 771 end 777 total 806 clock 60.0Hz 800x600 (0x4b) 40.0MHz +HSync +VSync h: width 800 start 840 end 968 total 1056 skew 0 clock 37.9KHz v: height 600 start 601 end 605 total 628 clock 60.3Hz 800x600 (0x4c) 36.0MHz +HSync +VSync h: width 800 start 824 end 896 total 1024 skew 0 clock 35.2KHz v: height 600 start 601 end 603 total 625 clock 56.2Hz 640x480 (0x4d) 25.2MHz -HSync -VSync h: width 640 start 656 end 752 total 800 skew 0 clock 31.5KHz v: height 480 start 490 end 492 total 525 clock 59.9Hz VGA1 disconnected (normal left inverted right x axis y axis) Identifier: 0x42 Timestamp: 40839 Subpixel: unknown Clones: CRTCs: 0 1 Transform: 1.000000 0.000000 0.000000 0.000000 1.000000 0.000000 0.000000 0.000000 1.000000 filter: HDMI1 disconnected (normal left inverted right x axis y axis) Identifier: 0x43 Timestamp: 40839 Subpixel: unknown Clones: CRTCs: 0 1 Transform: 1.000000 0.000000 0.000000 0.000000 1.000000 0.000000 0.000000 0.000000 1.000000 filter: force_audio: 0 (0x00000000) range: (-1,1) DP1 disconnected (normal left inverted right x axis y axis) Identifier: 0x44 Timestamp: 40839 Subpixel: unknown Clones: CRTCs: 0 1 Transform: 1.000000 0.000000 0.000000 0.000000 1.000000 0.000000 0.000000 0.000000 1.000000 filter: force_audio: 0 (0x00000000) range: (-1,1)
rday
On Thu, 27 Jan 2011, Chris Wilson wrote:
On Thu, 27 Jan 2011 07:12:03 -0500 (EST), "Robert P. J. Day" rpjday@crashcourse.ca wrote:
On Thu, 27 Jan 2011, Chris Wilson wrote:
The only missing detail is what connector is used for the display. Xorg.log or xrandr --verbose are the easiest.
i can supply those for the currently *successful* boot, is that what you're asking? because once we're into black screen territory, there's not a whole lot i can tell you.
Indeed. Fortunately the integrated hardware is unlikely to change between boots. But more interesting is if you can pin down the regressing commit.
this commit seems to be fine:
commit abb72c828878a2c69b2cfb33ac30007c8ecd735e Merge: 58bbf01 8e934db Author: Dave Airlie airlied@gmail.com Date: Tue Jan 25 08:41:58 2011 +1000
Merge branch 'drm-intel-fixes-2' of ssh://master.kernel.org/pub/scm/linux/ke
* 'drm-intel-fixes-2' of ssh://master.kernel.org/pub/scm/linux/kernel/git/ic drm/i915: Prevent uninitialised reads during error state capture drm/i915: Use consistent mappings for OpRegion between ACPI and i915 drm/i915: Handle the no-interrupts case for UMS by polling drm/i915: Disable high-precision vblank timestamping for UMS drm/i915: Increase the amount of defense before computing vblank timestamp drm/i915,agp/intel: Do not clear stolen entries Remove MAYBE_BUILD_BUG_ON BUILD_BUG_ON: make it handle more cases module: fix missing semicolons in MODULE macro usage param: add null statement to compiled-in module params module: fix linker error for MODULE_VERSION when !MODULE and CONFIG_SYSFS= module: show version information for built-in modules in sysfs selinux: return -ENOMEM when memory allocation fails tpm: fix panic caused by "tpm: Autodetect itpm devices" TPM: Long default timeout fix trusted keys: Fix a memory leak in trusted_update(). keys: add trusted and encrypted maintainers encrypted-keys: rename encrypted_defined files to encrypted trusted-keys: rename trusted_defined files to trusted drm/i915: Recognise non-VGA display devices ...
so moving on to the very next one, which logic suggests would be the culprit. back shortly if time permits.
rday
On Thu, 27 Jan 2011, Chris Wilson wrote:
On Thu, 27 Jan 2011 07:12:03 -0500 (EST), "Robert P. J. Day" rpjday@crashcourse.ca wrote:
On Thu, 27 Jan 2011, Chris Wilson wrote:
The only missing detail is what connector is used for the display. Xorg.log or xrandr --verbose are the easiest.
i can supply those for the currently *successful* boot, is that what you're asking? because once we're into black screen territory, there's not a whole lot i can tell you.
Indeed. Fortunately the integrated hardware is unlikely to change between boots. But more interesting is if you can pin down the regressing commit.
for me, this appears to be the offending commit:
commit 5e82ea99827f6aa122fbb08f8659e76226ce107b (now testing) Merge: ec30f34 abb72c8 Author: Linus Torvalds torvalds@linux-foundation.org Date: Tue Jan 25 10:46:14 2011 +1000
Merge branch 'drm-fixes' of git://git.kernel.org/pub/scm/linux/kernel/git/ai
* 'drm-fixes' of git://git.kernel.org/pub/scm/linux/kernel/git/airlied/drm-2 drm/radeon/kms: add new radeon_info ioctl query for clock crystal freq drm/i915: Prevent uninitialised reads during error state capture drm/i915: Use consistent mappings for OpRegion between ACPI and i915 drm/i915: Handle the no-interrupts case for UMS by polling drm/i915: Disable high-precision vblank timestamping for UMS drm/i915: Increase the amount of defense before computing vblank timestamp drm/i915,agp/intel: Do not clear stolen entries drm/radeon/kms: simplify atom adjust pll setup drm/radeon/kms: match r6xx/r7xx/evergreen asic_reset with previous asics drm/radeon/kms: make the mac rv630 quirk generic drm/radeon/kms: fix a spelling error in an error message drm/radeon/kms: Initialize pageflip spinlocks. drm/i915: Recognise non-VGA display devices drm/i915: Fix use of invalid array size for ring->sync_seqno drm/i915/ringbuffer: Fix use of stale HEAD position whilst polling for spa drm/i915: Don't kick-off hangcheck after a DRI interrupt drm/i915: Add dependency on CONFIG_TMPFS drm/i915: Initialise ring vfuncs for old DRI paths drm/i915: make the blitter report buffer modifications to the FBC unit drm/i915: set more FBC chicken bits
anything you want me to try?
rday
On Thu, 27 Jan 2011 08:42:19 -0500 (EST), "Robert P. J. Day" rpjday@crashcourse.ca wrote:
for me, this appears to be the offending commit:
commit 5e82ea99827f6aa122fbb08f8659e76226ce107b (now testing) Merge: ec30f34 abb72c8 Author: Linus Torvalds torvalds@linux-foundation.org Date: Tue Jan 25 10:46:14 2011 +1000
Merge branch 'drm-fixes' of git://git.kernel.org/pub/scm/linux/kernel/git/ai
Let's just test the other parent ec30f343d to be sure it came in with the drm merge. -Chris
On Thu, 27 Jan 2011, Chris Wilson wrote:
On Thu, 27 Jan 2011 08:42:19 -0500 (EST), "Robert P. J. Day" rpjday@crashcourse.ca wrote:
for me, this appears to be the offending commit:
commit 5e82ea99827f6aa122fbb08f8659e76226ce107b (now testing) Merge: ec30f34 abb72c8 Author: Linus Torvalds torvalds@linux-foundation.org Date: Tue Jan 25 10:46:14 2011 +1000
Merge branch 'drm-fixes' of git://git.kernel.org/pub/scm/linux/kernel/git/aiLet's just test the other parent ec30f343d to be sure it came in with the drm merge.
so that's something you want me to test? checking out that commit ec30f343d and trying it?
rday
On Thu, 27 Jan 2011 08:55:24 -0500 (EST), "Robert P. J. Day" rpjday@crashcourse.ca wrote:
On Thu, 27 Jan 2011, Chris Wilson wrote:
On Thu, 27 Jan 2011 08:42:19 -0500 (EST), "Robert P. J. Day" rpjday@crashcourse.ca wrote:
for me, this appears to be the offending commit:
commit 5e82ea99827f6aa122fbb08f8659e76226ce107b (now testing) Merge: ec30f34 abb72c8 Author: Linus Torvalds torvalds@linux-foundation.org Date: Tue Jan 25 10:46:14 2011 +1000
Merge branch 'drm-fixes' of git://git.kernel.org/pub/scm/linux/kernel/git/aiLet's just test the other parent ec30f343d to be sure it came in with the drm merge.
so that's something you want me to test? checking out that commit ec30f343d and trying it?
Yes. If abb72c8 works and 5e82ea9 does not, then ec30f34 must be at fault (since the merge looks clean), verifying that the bug was introduced between abb72c828 and ec30f34. -Chris
On Thu, 27 Jan 2011, Chris Wilson wrote:
On Thu, 27 Jan 2011 08:55:24 -0500 (EST), "Robert P. J. Day" rpjday@crashcourse.ca wrote:
On Thu, 27 Jan 2011, Chris Wilson wrote:
On Thu, 27 Jan 2011 08:42:19 -0500 (EST), "Robert P. J. Day" rpjday@crashcourse.ca wrote:
for me, this appears to be the offending commit:
commit 5e82ea99827f6aa122fbb08f8659e76226ce107b (now testing) Merge: ec30f34 abb72c8 Author: Linus Torvalds torvalds@linux-foundation.org Date: Tue Jan 25 10:46:14 2011 +1000
Merge branch 'drm-fixes' of git://git.kernel.org/pub/scm/linux/kernel/git/aiLet's just test the other parent ec30f343d to be sure it came in with the drm merge.
so that's something you want me to test? checking out that commit ec30f343d and trying it?
Yes. If abb72c8 works and 5e82ea9 does not, then ec30f34 must be at fault (since the merge looks clean), verifying that the bug was introduced between abb72c828 and ec30f34.
ok, i'll try to get to that ASAP. so what i'm *expecting* is for ec30f34 to fail, then. i'll keep you posted.
rday
On Thu, 27 Jan 2011, Chris Wilson wrote:
On Thu, 27 Jan 2011 08:55:24 -0500 (EST), "Robert P. J. Day" rpjday@crashcourse.ca wrote:
On Thu, 27 Jan 2011, Chris Wilson wrote:
On Thu, 27 Jan 2011 08:42:19 -0500 (EST), "Robert P. J. Day" rpjday@crashcourse.ca wrote:
for me, this appears to be the offending commit:
commit 5e82ea99827f6aa122fbb08f8659e76226ce107b (now testing) Merge: ec30f34 abb72c8 Author: Linus Torvalds torvalds@linux-foundation.org Date: Tue Jan 25 10:46:14 2011 +1000
Merge branch 'drm-fixes' of git://git.kernel.org/pub/scm/linux/kernel/git/aiLet's just test the other parent ec30f343d to be sure it came in with the drm merge.
so that's something you want me to test? checking out that commit ec30f343d and trying it?
Yes. If abb72c8 works and 5e82ea9 does not, then ec30f34 must be at fault (since the merge looks clean), verifying that the bug was introduced between abb72c828 and ec30f34.
well, now i'm confused since it *appears* that, when i went to double-check the results, the earlier commit abb72c8 *doesn't* work, and i could swear that it did. so i'll just redo *all* of the relevant commits and report back. grrrrrr ...
rday
On Thu, 27 Jan 2011, Chris Wilson wrote:
On Thu, 27 Jan 2011 08:55:24 -0500 (EST), "Robert P. J. Day" rpjday@crashcourse.ca wrote:
On Thu, 27 Jan 2011, Chris Wilson wrote:
On Thu, 27 Jan 2011 08:42:19 -0500 (EST), "Robert P. J. Day" rpjday@crashcourse.ca wrote:
for me, this appears to be the offending commit:
commit 5e82ea99827f6aa122fbb08f8659e76226ce107b (now testing) Merge: ec30f34 abb72c8 Author: Linus Torvalds torvalds@linux-foundation.org Date: Tue Jan 25 10:46:14 2011 +1000
Merge branch 'drm-fixes' of git://git.kernel.org/pub/scm/linux/kernel/git/aiLet's just test the other parent ec30f343d to be sure it came in with the drm merge.
so that's something you want me to test? checking out that commit ec30f343d and trying it?
Yes. If abb72c8 works and 5e82ea9 does not, then ec30f34 must be at fault (since the merge looks clean), verifying that the bug was introduced between abb72c828 and ec30f34.
ok, i'm getting different results from this morning, not sure why, but i'm fairly confident i've isolated it to this extent. here's the salient part of the git log i'm looking at:
===== git log =====
commit abb72c828878a2c69b2cfb33ac30007c8ecd735e Merge: 58bbf01 8e934db Author: Dave Airlie airlied@gmail.com Date: Tue Jan 25 08:41:58 2011 +1000
Merge branch 'drm-intel-fixes-2' of ssh://master.kernel.org/pub/scm/linux/kernel/g
* 'drm-intel-fixes-2' of ssh://master.kernel.org/pub/scm/linux/kernel/git/ickle/dr drm/i915: Prevent uninitialised reads during error state capture drm/i915: Use consistent mappings for OpRegion between ACPI and i915 drm/i915: Handle the no-interrupts case for UMS by polling drm/i915: Disable high-precision vblank timestamping for UMS drm/i915: Increase the amount of defense before computing vblank timestamps drm/i915,agp/intel: Do not clear stolen entries Remove MAYBE_BUILD_BUG_ON BUILD_BUG_ON: make it handle more cases module: fix missing semicolons in MODULE macro usage param: add null statement to compiled-in module params module: fix linker error for MODULE_VERSION when !MODULE and CONFIG_SYSFS=n module: show version information for built-in modules in sysfs selinux: return -ENOMEM when memory allocation fails tpm: fix panic caused by "tpm: Autodetect itpm devices" TPM: Long default timeout fix trusted keys: Fix a memory leak in trusted_update(). keys: add trusted and encrypted maintainers encrypted-keys: rename encrypted_defined files to encrypted trusted-keys: rename trusted_defined files to trusted drm/i915: Recognise non-VGA display devices ...
commit 58bbf018a70c562437eeae121a5d021ba7fe56a5 Author: Alex Deucher alexdeucher@gmail.com Date: Mon Jan 24 17:14:26 2011 -0500
drm/radeon/kms: add new radeon_info ioctl query for clock crystal freq
Needed for timer queries in the 3D driver.
Signed-off-by: Alex Deucher alexdeucher@gmail.com Signed-off-by: Dave Airlie airlied@gmail.com
===== git log =====
now:
* commit 58bbf018 appears to be fine, boots reliably * commit 8e934dbf causes black screen issue
as you can see, rather than test the *merge* above, i decided to back up one level and test the commit that was part of that merge, and it failed. is this helpful? here's the log entry:
commit 8e934dbf264418afe4d1dff34ce074ecc14280db Author: Chris Wilson chris@chris-wilson.co.uk Date: Mon Jan 24 12:34:00 2011 +0000
drm/i915: Prevent uninitialised reads during error state capture
error_bo and pinned_bo could be used uninitialised if there were no active buffers.
Caught by kmemcheck.
Signed-off-by: Chris Wilson chris@chris-wilson.co.uk
i'm going to go on and test the merge itself, abb72c82, since i thought that was working fine earlier today. but you can see which commit now seems to fail. does this make any sense?
rday
one more observation which should nail things down:
On Thu, 27 Jan 2011, Robert P. J. Day wrote:
ok, i'm getting different results from this morning, not sure why, but i'm fairly confident i've isolated it to this extent. here's the salient part of the git log i'm looking at:
===== git log =====
commit abb72c828878a2c69b2cfb33ac30007c8ecd735e Merge: 58bbf01 8e934db Author: Dave Airlie airlied@gmail.com Date: Tue Jan 25 08:41:58 2011 +1000
Merge branch 'drm-intel-fixes-2' of ssh://master.kernel.org/pub/scm/linux/kernel/g * 'drm-intel-fixes-2' of ssh://master.kernel.org/pub/scm/linux/kernel/git/ickle/dr drm/i915: Prevent uninitialised reads during error state capture drm/i915: Use consistent mappings for OpRegion between ACPI and i915 drm/i915: Handle the no-interrupts case for UMS by polling drm/i915: Disable high-precision vblank timestamping for UMS drm/i915: Increase the amount of defense before computing vblank timestamps drm/i915,agp/intel: Do not clear stolen entries Remove MAYBE_BUILD_BUG_ON BUILD_BUG_ON: make it handle more cases module: fix missing semicolons in MODULE macro usage param: add null statement to compiled-in module params module: fix linker error for MODULE_VERSION when !MODULE and CONFIG_SYSFS=n module: show version information for built-in modules in sysfs selinux: return -ENOMEM when memory allocation fails tpm: fix panic caused by "tpm: Autodetect itpm devices" TPM: Long default timeout fix trusted keys: Fix a memory leak in trusted_update(). keys: add trusted and encrypted maintainers encrypted-keys: rename encrypted_defined files to encrypted trusted-keys: rename trusted_defined files to trusted drm/i915: Recognise non-VGA display devices ...commit 58bbf018a70c562437eeae121a5d021ba7fe56a5 Author: Alex Deucher alexdeucher@gmail.com Date: Mon Jan 24 17:14:26 2011 -0500
drm/radeon/kms: add new radeon_info ioctl query for clock crystal freq Needed for timer queries in the 3D driver. Signed-off-by: Alex Deucher <alexdeucher@gmail.com> Signed-off-by: Dave Airlie <airlied@gmail.com>===== git log =====
now:
- commit 58bbf018 appears to be fine, boots reliably
- commit 8e934dbf causes black screen issue
as you can see, rather than test the *merge* above, i decided to back up one level and test the commit that was part of that merge, and it failed. is this helpful? here's the log entry:
commit 8e934dbf264418afe4d1dff34ce074ecc14280db Author: Chris Wilson chris@chris-wilson.co.uk Date: Mon Jan 24 12:34:00 2011 +0000
drm/i915: Prevent uninitialised reads during error state capture error_bo and pinned_bo could be used uninitialised if there were no active buffers. Caught by kmemcheck. Signed-off-by: Chris Wilson <chris@chris-wilson.co.uk>i'm going to go on and test the merge itself, abb72c82, since i thought that was working fine earlier today. but you can see which commit now seems to fail. does this make any sense?
i did indeed test commit abb72c82 (the merge of the above), and it failed. not sure why i posted earlier today that it worked, i must have built something incorrectly. so, in conclusion:
* commit 58bbf018 appears to be fine, boots reliably * commit 8e934dbf causes black screen issue * commit abb72c82 also causes black screen issue
and on that note, signing off for the evening.
rday
On Thu, 27 Jan 2011 17:33:04 -0500 (EST), "Robert P. J. Day" rpjday@crashcourse.ca wrote:
one more observation which should nail things down:
On Thu, 27 Jan 2011, Robert P. J. Day wrote:
ok, i'm getting different results from this morning, not sure why, but i'm fairly confident i've isolated it to this extent. here's the salient part of the git log i'm looking at:
===== git log =====
commit abb72c828878a2c69b2cfb33ac30007c8ecd735e Merge: 58bbf01 8e934db Author: Dave Airlie airlied@gmail.com Date: Tue Jan 25 08:41:58 2011 +1000
Merge branch 'drm-intel-fixes-2' of ssh://master.kernel.org/pub/scm/linux/kernel/g * 'drm-intel-fixes-2' of ssh://master.kernel.org/pub/scm/linux/kernel/git/ickle/dr drm/i915: Prevent uninitialised reads during error state capture drm/i915: Use consistent mappings for OpRegion between ACPI and i915 drm/i915: Handle the no-interrupts case for UMS by polling drm/i915: Disable high-precision vblank timestamping for UMS drm/i915: Increase the amount of defense before computing vblank timestamps drm/i915,agp/intel: Do not clear stolen entries Remove MAYBE_BUILD_BUG_ON BUILD_BUG_ON: make it handle more cases module: fix missing semicolons in MODULE macro usage param: add null statement to compiled-in module params module: fix linker error for MODULE_VERSION when !MODULE and CONFIG_SYSFS=n module: show version information for built-in modules in sysfs selinux: return -ENOMEM when memory allocation fails tpm: fix panic caused by "tpm: Autodetect itpm devices" TPM: Long default timeout fix trusted keys: Fix a memory leak in trusted_update(). keys: add trusted and encrypted maintainers encrypted-keys: rename encrypted_defined files to encrypted trusted-keys: rename trusted_defined files to trusted drm/i915: Recognise non-VGA display devices ...commit 58bbf018a70c562437eeae121a5d021ba7fe56a5 Author: Alex Deucher alexdeucher@gmail.com Date: Mon Jan 24 17:14:26 2011 -0500
drm/radeon/kms: add new radeon_info ioctl query for clock crystal freq Needed for timer queries in the 3D driver. Signed-off-by: Alex Deucher <alexdeucher@gmail.com> Signed-off-by: Dave Airlie <airlied@gmail.com>===== git log =====
now:
- commit 58bbf018 appears to be fine, boots reliably
- commit 8e934dbf causes black screen issue
as you can see, rather than test the *merge* above, i decided to back up one level and test the commit that was part of that merge, and it failed. is this helpful? here's the log entry:
commit 8e934dbf264418afe4d1dff34ce074ecc14280db Author: Chris Wilson chris@chris-wilson.co.uk Date: Mon Jan 24 12:34:00 2011 +0000
drm/i915: Prevent uninitialised reads during error state capture error_bo and pinned_bo could be used uninitialised if there were no active buffers. Caught by kmemcheck. Signed-off-by: Chris Wilson <chris@chris-wilson.co.uk>i'm going to go on and test the merge itself, abb72c82, since i thought that was working fine earlier today. but you can see which commit now seems to fail. does this make any sense?
i did indeed test commit abb72c82 (the merge of the above), and it failed. not sure why i posted earlier today that it worked, i must have built something incorrectly. so, in conclusion:
- commit 58bbf018 appears to be fine, boots reliably
- commit 8e934dbf causes black screen issue
- commit abb72c82 also causes black screen issue
and on that note, signing off for the evening.
rday
--
======================================================================== Robert P. J. Day Waterloo, Ontario, CANADA http://crashcourse.ca
Twitter: http://twitter.com/rpjday LinkedIn: http://ca.linkedin.com/in/rpjday ========================================================================
From: Chris Wilson chris@chris-wilson.co.uk Subject: Re: has the i915 "black screen" boot issue returned? To: "Robert P. J. Day" rpjday@crashcourse.ca Cc: dri-devel@lists.freedesktop.org Bcc: chris@chris-wilson.co.uk In-Reply-To: alpine.DEB.2.00.1101271634260.2761@localhost6.localdomain6 References: alpine.DEB.2.00.1101260634300.10774@localhost6.localdomain6 b9dded$hp9kfu@orsmga002.jf.intel.com alpine.DEB.2.00.1101270641490.2923@localhost6.localdomain6 b9dded$hpa5rf@orsmga002.jf.intel.com alpine.DEB.2.00.1101270710510.17636@localhost6.localdomain6 1bdc18$jdgfni@fmsmga002.fm.intel.com alpine.DEB.2.00.1101270840380.2736@localhost6.localdomain6 0d30dc$ksovh8@orsmga001.jf.intel.com alpine.DEB.2.00.1101270854420.4898@localhost6.localdomain6 b7da2f$q8lpcn@fmsmga001.fm.intel.com alpine.DEB.2.00.1101271634260.2761@localhost6.localdomain6
On Thu, 27 Jan 2011 16:39:20 -0500 (EST), "Robert P. J. Day" rpjday@crashcourse.ca wrote:
ok, i'm getting different results from this morning, not sure why, but i'm fairly confident i've isolated it to this extent. here's the salient part of the git log i'm looking at:
Well, we have two endpoints, so let git attack:
$ git bisect start $ git bisect good 58bbf018a70c562437eeae121a5d021ba7fe56a5 $ git bisect bad abb72c828878a2c69b2cfb33ac30007c8ecd735e
That shouldn't take more than a few recompiles to identify the troublemaker. -Chris
On Fri, 28 Jan 2011, Chris Wilson wrote:
Well, we have two endpoints, so let git attack:
$ git bisect start $ git bisect good 58bbf018a70c562437eeae121a5d021ba7fe56a5 $ git bisect bad abb72c828878a2c69b2cfb33ac30007c8ecd735e
That shouldn't take more than a few recompiles to identify the troublemaker.
ok, i can get to that in a bit. might take a while since this system is not exactly a screamer but i'm curious -- have you heard no other reports of people running into this issue? i'm going to be embarrassed if it turns out it's something *i've* done but, at this point, it seems fairly reproducible.
are there any kernel command-line parms i might try that would be informative? anything involving modesetting?
rday
On Fri, 28 Jan 2011 04:24:17 -0500 (EST), "Robert P. J. Day" rpjday@crashcourse.ca wrote:
On Fri, 28 Jan 2011, Chris Wilson wrote:
Well, we have two endpoints, so let git attack:
$ git bisect start $ git bisect good 58bbf018a70c562437eeae121a5d021ba7fe56a5 $ git bisect bad abb72c828878a2c69b2cfb33ac30007c8ecd735e
That shouldn't take more than a few recompiles to identify the troublemaker.
ok, i can get to that in a bit. might take a while since this system is not exactly a screamer but i'm curious -- have you heard no other reports of people running into this issue? i'm going to be embarrassed if it turns out it's something *i've* done but, at this point, it seems fairly reproducible.
This is the first I'm aware of. It could just be the tip of the iceberg...
are there any kernel command-line parms i might try that would be informative? anything involving modesetting?
Sure: add drm.debug=0xe to your boot parameters (or to your modprobe conf). -Chris
On Fri, 28 Jan 2011, Chris Wilson wrote:
On Fri, 28 Jan 2011 04:24:17 -0500 (EST), "Robert P. J. Day" rpjday@crashcourse.ca wrote:
On Fri, 28 Jan 2011, Chris Wilson wrote:
Well, we have two endpoints, so let git attack:
$ git bisect start $ git bisect good 58bbf018a70c562437eeae121a5d021ba7fe56a5 $ git bisect bad abb72c828878a2c69b2cfb33ac30007c8ecd735e
That shouldn't take more than a few recompiles to identify the troublemaker.
ok, i can get to that in a bit. might take a while since this system is not exactly a screamer but i'm curious -- have you heard no other reports of people running into this issue? i'm going to be embarrassed if it turns out it's something *i've* done but, at this point, it seems fairly reproducible.
This is the first I'm aware of. It could just be the tip of the iceberg...
the git bisection finally resolved to:
BAD: b705120e GOOD: 8a327f23
so the culprit appears to be:
b705120e4198315f4ae043de06c62f65e0851fd3 is the first bad commit commit b705120e4198315f4ae043de06c62f65e0851fd3 Author: Michael Karcher kernel@mkarcher.dialup.fu-berlin.de Date: Sun Jan 23 18:17:17 2011 +0000
drm/i915: Use consistent mappings for OpRegion between ACPI and i915
The opregion is a shared memory region between ACPI and the graphics driver. As the ACPI mapping has been changed to cachable in commit 6d5bbf00d251cc73223a71422d69e069dc2e0b8d, mapping the intel opregion non-cachable now fails. As no bus-master hardware is involved in the opregion, cachable map should do no harm.
Tested on a Fujitsu Lifebook P8010.
Signed-off-by: Michael Karcher kernel@mkarcher.dialup.fu-berlin.de [ickle: convert to acpi_os_ioremap for consistency] Signed-off-by: Chris Wilson chris@chris-wilson.co.uk
thoughts? once again, the salient output from "lspci -v":
00:02.0 VGA compatible controller: Intel Corporation Core Processor Integrated Graphics Controller (rev 12) (prog-if 00 [VGA controller]) Subsystem: Acer Incorporated [ALI] Device 031c Flags: bus master, fast devsel, latency 0, IRQ 41 Memory at d0000000 (64-bit, non-prefetchable) [size=4M] Memory at c0000000 (64-bit, prefetchable) [size=256M] I/O ports at 3050 [size=8] Expansion ROM at <unassigned> [disabled] Capabilities: <access denied> Kernel driver in use: i915 Kernel modules: i915
rday
On Fri, 28 Jan 2011 08:53:59 -0500 (EST), "Robert P. J. Day" rpjday@crashcourse.ca wrote:
so the culprit appears to be:
b705120e4198315f4ae043de06c62f65e0851fd3 is the first bad commit commit b705120e4198315f4ae043de06c62f65e0851fd3 Author: Michael Karcher kernel@mkarcher.dialup.fu-berlin.de Date: Sun Jan 23 18:17:17 2011 +0000
drm/i915: Use consistent mappings for OpRegion between ACPI and i915 The opregion is a shared memory region between ACPI and the graphics driver. As the ACPI mapping has been changed to cachable in commit 6d5bbf00d251cc73223a71422d69e069dc2e0b8d, mapping the intel opregion non-cachable now fails. As no bus-master hardware is involved in the opregion, cachable map should do no harm. Tested on a Fujitsu Lifebook P8010. Signed-off-by: Michael Karcher <kernel@mkarcher.dialup.fu-berlin.de> [ickle: convert to acpi_os_ioremap for consistency] Signed-off-by: Chris Wilson <chris@chris-wilson.co.uk>thoughts? once again, the salient output from "lspci -v":
Indeed looks like using ioremap_cache is not as safe as was assumed. Does
diff --git a/include/linux/acpi_io.h b/include/linux/acpi_io.h index 7180013..42108ab 100644 --- a/include/linux/acpi_io.h +++ b/include/linux/acpi_io.h @@ -7,7 +7,7 @@ static inline void __iomem *acpi_os_ioremap(acpi_physical_address phys, acpi_size size) { - return ioremap_cache(phys, size); + return ioremap_wc(phys, size); }
int acpi_os_map_generic_address(struct acpi_generic_address *addr);
fix your boot issue or do we need to go back to using uncached:
+ return ioremap(phys, size);
On Fri, 28 Jan 2011, Chris Wilson wrote:
On Fri, 28 Jan 2011 08:53:59 -0500 (EST), "Robert P. J. Day" rpjday@crashcourse.ca wrote:
so the culprit appears to be:
b705120e4198315f4ae043de06c62f65e0851fd3 is the first bad commit commit b705120e4198315f4ae043de06c62f65e0851fd3 Author: Michael Karcher kernel@mkarcher.dialup.fu-berlin.de Date: Sun Jan 23 18:17:17 2011 +0000
drm/i915: Use consistent mappings for OpRegion between ACPI and i915 The opregion is a shared memory region between ACPI and the graphics driver. As the ACPI mapping has been changed to cachable in commit 6d5bbf00d251cc73223a71422d69e069dc2e0b8d, mapping the intel opregion non-cachable now fails. As no bus-master hardware is involved in the opregion, cachable map should do no harm. Tested on a Fujitsu Lifebook P8010. Signed-off-by: Michael Karcher <kernel@mkarcher.dialup.fu-berlin.de> [ickle: convert to acpi_os_ioremap for consistency] Signed-off-by: Chris Wilson <chris@chris-wilson.co.uk>thoughts? once again, the salient output from "lspci -v":
Indeed looks like using ioremap_cache is not as safe as was assumed. Does
*sigh*. there was, in fact, an "ioremap_error" message displayed *very* early in the boot sequence, but it was generated even for successful boots so i never paid it any mind. in hindsight, might have been useful to have mentioned it.
diff --git a/include/linux/acpi_io.h b/include/linux/acpi_io.h index 7180013..42108ab 100644 --- a/include/linux/acpi_io.h +++ b/include/linux/acpi_io.h @@ -7,7 +7,7 @@ static inline void __iomem *acpi_os_ioremap(acpi_physical_address phys, acpi_size size) {
return ioremap_cache(phys, size);
return ioremap_wc(phys, size);}
int acpi_os_map_generic_address(struct acpi_generic_address *addr);
ok, i'll make this single change and report back shortly.
rday
On Fri, 28 Jan 2011, Chris Wilson wrote:
On Fri, 28 Jan 2011 08:53:59 -0500 (EST), "Robert P. J. Day" rpjday@crashcourse.ca wrote:
so the culprit appears to be:
b705120e4198315f4ae043de06c62f65e0851fd3 is the first bad commit commit b705120e4198315f4ae043de06c62f65e0851fd3 Author: Michael Karcher kernel@mkarcher.dialup.fu-berlin.de Date: Sun Jan 23 18:17:17 2011 +0000
drm/i915: Use consistent mappings for OpRegion between ACPI and i915 The opregion is a shared memory region between ACPI and the graphics driver. As the ACPI mapping has been changed to cachable in commit 6d5bbf00d251cc73223a71422d69e069dc2e0b8d, mapping the intel opregion non-cachable now fails. As no bus-master hardware is involved in the opregion, cachable map should do no harm. Tested on a Fujitsu Lifebook P8010. Signed-off-by: Michael Karcher <kernel@mkarcher.dialup.fu-berlin.de> [ickle: convert to acpi_os_ioremap for consistency] Signed-off-by: Chris Wilson <chris@chris-wilson.co.uk>thoughts? once again, the salient output from "lspci -v":
Indeed looks like using ioremap_cache is not as safe as was assumed. Does
diff --git a/include/linux/acpi_io.h b/include/linux/acpi_io.h index 7180013..42108ab 100644 --- a/include/linux/acpi_io.h +++ b/include/linux/acpi_io.h @@ -7,7 +7,7 @@ static inline void __iomem *acpi_os_ioremap(acpi_physical_address phys, acpi_size size) {
return ioremap_cache(phys, size);
return ioremap_wc(phys, size);}
int acpi_os_map_generic_address(struct acpi_generic_address *addr);
that didn't appear to make a difference. same black screen issue. BTW, here's an excerpt from /var/log/dmesg for a *successful* boot (i just rebooted to 8a327f23):
... [ 24.037114] intel ips 0000:00:1f.6: failed to get i915 symbols, graphics turbo disabled ... [ 27.155660] i915 0000:00:02.0: PCI INT A -> GSI 16 (level, low) -> IRQ 16 [ 27.155665] i915 0000:00:02.0: setting latency timer to 64 [ 27.217407] mtrr: no more MTRRs available [ 27.217411] [drm] MTRR allocation failed. Graphics performance may suffer. [ 27.217848] ioremap error for 0xb3752000-0xb3755000, requested 0x10, got 0x0 [ 27.217933] i915 0000:00:02.0: irq 42 for MSI/MSI-X [ 27.217938] [drm] Supports vblank timestamp caching Rev 1 (10.10.2010). [ 27.217940] [drm] Driver supports precise vblank timestamp query. ...
if any of that is of any use.
fix your boot issue or do we need to go back to using uncached:
return ioremap(phys, size);
is that the next change you want me to try?
rday
On Fri, 28 Jan 2011 09:32:04 -0500 (EST), "Robert P. J. Day" rpjday@crashcourse.ca wrote:
fix your boot issue or do we need to go back to using uncached:
return ioremap(phys, size);is that the next change you want me to try?
Yes. (Replacing the current return ioremap_*(phys, size).) -Chris
On Fri, 28 Jan 2011, Chris Wilson wrote:
On Fri, 28 Jan 2011 09:32:04 -0500 (EST), "Robert P. J. Day" rpjday@crashcourse.ca wrote:
fix your boot issue or do we need to go back to using uncached:
return ioremap(phys, size);is that the next change you want me to try?
Yes. (Replacing the current return ioremap_*(phys, size).)
sadly, no change -- still black screen. again, rebooted successfully under commit 8a327f23. just to be clear, here's "git diff":
$ git diff diff --git a/include/linux/acpi_io.h b/include/linux/acpi_io.h index 7180013..e035f3c 100644 --- a/include/linux/acpi_io.h +++ b/include/linux/acpi_io.h @@ -7,7 +7,7 @@ static inline void __iomem *acpi_os_ioremap(acpi_physical_address phys, acpi_size size) { - return ioremap_cache(phys, size); + return ioremap(phys, size); }
int acpi_os_map_generic_address(struct acpi_generic_address *addr);
rday
On Fri, 28 Jan 2011 09:51:01 -0500 (EST), "Robert P. J. Day" rpjday@crashcourse.ca wrote:
sadly, no change -- still black screen. again, rebooted successfully under commit 8a327f23. just to be clear, here's "git diff":
$ git diff diff --git a/include/linux/acpi_io.h b/include/linux/acpi_io.h index 7180013..e035f3c 100644 --- a/include/linux/acpi_io.h +++ b/include/linux/acpi_io.h @@ -7,7 +7,7 @@ static inline void __iomem *acpi_os_ioremap(acpi_physical_address phys, acpi_size size) {
return ioremap_cache(phys, size);
return ioremap(phys, size);}
Ok, that implies the new mapping is fine and not the cause of the issue.
Instead you have some OpRegion related regression hidden until till now because the conflicting mapping disabled it for i915.
That would be easy to test by returning early in intel_opregion_setup():
diff --git a/drivers/gpu/drm/i915/intel_opregion.c b/drivers/gpu/drm/i915/intel_ index 9efccb9..8c93201 100644 --- a/drivers/gpu/drm/i915/intel_opregion.c +++ b/drivers/gpu/drm/i915/intel_opregion.c @@ -470,6 +470,8 @@ int intel_opregion_setup(struct drm_device *dev) u32 asls, mboxes; int err = 0;
+ return -ENOTSUPP; +
pci_read_config_dword(dev->pdev, PCI_ASLS, &asls); DRM_DEBUG_DRIVER("graphic opregion physical addr: 0x%x\n", asls); if (asls == 0) {
On Fri, 28 Jan 2011, Chris Wilson wrote:
On Fri, 28 Jan 2011 09:51:01 -0500 (EST), "Robert P. J. Day" rpjday@crashcourse.ca wrote:
sadly, no change -- still black screen. again, rebooted successfully under commit 8a327f23. just to be clear, here's "git diff":
$ git diff diff --git a/include/linux/acpi_io.h b/include/linux/acpi_io.h index 7180013..e035f3c 100644 --- a/include/linux/acpi_io.h +++ b/include/linux/acpi_io.h @@ -7,7 +7,7 @@ static inline void __iomem *acpi_os_ioremap(acpi_physical_address phys, acpi_size size) {
return ioremap_cache(phys, size);
return ioremap(phys, size);}
Ok, that implies the new mapping is fine and not the cause of the issue.
Instead you have some OpRegion related regression hidden until till now because the conflicting mapping disabled it for i915.
That would be easy to test by returning early in intel_opregion_setup():
diff --git a/drivers/gpu/drm/i915/intel_opregion.c b/drivers/gpu/drm/i915/intel_ index 9efccb9..8c93201 100644 --- a/drivers/gpu/drm/i915/intel_opregion.c +++ b/drivers/gpu/drm/i915/intel_opregion.c @@ -470,6 +470,8 @@ int intel_opregion_setup(struct drm_device *dev) u32 asls, mboxes; int err = 0;
return -ENOTSUPP;pci_read_config_dword(dev->pdev, PCI_ASLS, &asls); DRM_DEBUG_DRIVER("graphic opregion physical addr: 0x%x\n", asls); if (asls == 0) {
so you want me to revert to a stock b705120e before doing the above?
rday
On Fri, 28 Jan 2011 10:08:07 -0500 (EST), "Robert P. J. Day" rpjday@crashcourse.ca wrote:
That would be easy to test by returning early in intel_opregion_setup():
diff --git a/drivers/gpu/drm/i915/intel_opregion.c b/drivers/gpu/drm/i915/intel_ index 9efccb9..8c93201 100644 --- a/drivers/gpu/drm/i915/intel_opregion.c +++ b/drivers/gpu/drm/i915/intel_opregion.c @@ -470,6 +470,8 @@ int intel_opregion_setup(struct drm_device *dev) u32 asls, mboxes; int err = 0;
return -ENOTSUPP;pci_read_config_dword(dev->pdev, PCI_ASLS, &asls); DRM_DEBUG_DRIVER("graphic opregion physical addr: 0x%x\n", asls); if (asls == 0) {so you want me to revert to a stock b705120e before doing the above?
Yes. (Or latter, at this point we have lots of fun ahead.) -Chris
On Fri, 28 Jan 2011, Chris Wilson wrote:
On Fri, 28 Jan 2011 10:08:07 -0500 (EST), "Robert P. J. Day" rpjday@crashcourse.ca wrote:
That would be easy to test by returning early in intel_opregion_setup():
diff --git a/drivers/gpu/drm/i915/intel_opregion.c b/drivers/gpu/drm/i915/intel_ index 9efccb9..8c93201 100644 --- a/drivers/gpu/drm/i915/intel_opregion.c +++ b/drivers/gpu/drm/i915/intel_opregion.c @@ -470,6 +470,8 @@ int intel_opregion_setup(struct drm_device *dev) u32 asls, mboxes; int err = 0;
return -ENOTSUPP;pci_read_config_dword(dev->pdev, PCI_ASLS, &asls); DRM_DEBUG_DRIVER("graphic opregion physical addr: 0x%x\n", asls); if (asls == 0) {so you want me to revert to a stock b705120e before doing the above?
Yes. (Or latter, at this point we have lots of fun ahead.)
victory is mine! ok, that premature return seems to have solved it, i'm up and running under this new kernel. are we getting close?
rday
On Fri, 28 Jan 2011 10:27:09 -0500 (EST), "Robert P. J. Day" rpjday@crashcourse.ca wrote:
victory is mine! ok, that premature return seems to have solved it, i'm up and running under this new kernel. are we getting close?
Not even close. We just disabled functionality that was working in 2.6.37; the interaction between ACPI and gfx. What a shame.
Instead of return -ENOTSUPP at the start, you can return 0 before each of the if (mboxes & MBOX_*) to narrow down which function regressed. -Chris
On Fri, 28 Jan 2011, Chris Wilson wrote:
On Fri, 28 Jan 2011 10:27:09 -0500 (EST), "Robert P. J. Day" rpjday@crashcourse.ca wrote:
victory is mine! ok, that premature return seems to have solved it, i'm up and running under this new kernel. are we getting close?
Not even close. We just disabled functionality that was working in 2.6.37; the interaction between ACPI and gfx. What a shame.
Instead of return -ENOTSUPP at the start, you can return 0 before each of the if (mboxes & MBOX_*) to narrow down which function regressed.
ok, i'll see how much of that i can get to today. but at this point, are we fairly convinced that there *is* a problem? i'd hate to go through all this, only to learn at the end that it's something stupid i did. it seems odd that no one else has mentioned running into this -- have you heard no other reports?
so, before i launch into this, is there anything else i might report about my system and its current setup that someone might want to know?
rday
On Fri, 28 Jan 2011 10:54:20 -0500 (EST), "Robert P. J. Day" rpjday@crashcourse.ca wrote:
On Fri, 28 Jan 2011, Chris Wilson wrote:
On Fri, 28 Jan 2011 10:27:09 -0500 (EST), "Robert P. J. Day" rpjday@crashcourse.ca wrote:
victory is mine! ok, that premature return seems to have solved it, i'm up and running under this new kernel. are we getting close?
Not even close. We just disabled functionality that was working in 2.6.37; the interaction between ACPI and gfx. What a shame.
Instead of return -ENOTSUPP at the start, you can return 0 before each of the if (mboxes & MBOX_*) to narrow down which function regressed.
ok, i'll see how much of that i can get to today. but at this point, are we fairly convinced that there *is* a problem? i'd hate to go through all this, only to learn at the end that it's something stupid i did. it seems odd that no one else has mentioned running into this -- have you heard no other reports?
We're starting to get into ACPI backlight breakage territory... We have identified that the regression was much earlier, just masked by other breakage.
Let's clarify the symptoms: black panel, no backlight, no output at all (not even at shallow angles), but the machine is alive? Can you remotely access the machine and grab debug logs from when it is broken?
so, before i launch into this, is there anything else i might report about my system and its current setup that someone might want to know?
We're now just looking for telltale signs of an error. -Chris
On Fri, 28 Jan 2011, Chris Wilson wrote:
We're starting to get into ACPI backlight breakage territory... We have identified that the regression was much earlier, just masked by other breakage.
as additional info, i went through this for a while during the 2.6.37-rc* progression. it came, it went, it came back again. then everything was fine with both 2.6.38-rc1 and 2.6.38-rc2, and then this. this is on a gateway NV79 laptop running a fully-updated ubuntu 10.10.
Let's clarify the symptoms: black panel, no backlight, no output at all (not even at shallow angles), but the machine is alive?
exactly, same as it's always been when things fail. that the machine is still booting is obvious from lots of disk activity, culminating in the little ubuntu drum roll at the login screen. and, as i mentioned before, i do get a couple early kernel messages (/dev/pts, ureadahead), and that's where it goes black. for a *good* boot, what i would see at that point is the font size getting much smaller and the boot continuing.
Can you remotely access the machine and grab debug logs from when it is broken?
i'd love to, but can't at the moment. i'll see if i can scare up a second machine later and try it. if i can, what *precisely* would you like me to post? i'm guessing dmesg, Xorg.0.log, that sort of thing.
so, before i launch into this, is there anything else i might report about my system and its current setup that someone might want to know?
We're now just looking for telltale signs of an error.
all right. and since we're beyond git bisection, can you post a list of say 2 or 3 tests you want me to try in order? as you're the expert here, it would make more sense for you to try to optimize the search pattern here.
rday
On Fri, 28 Jan 2011 11:23:08 -0500 (EST), "Robert P. J. Day" rpjday@crashcourse.ca wrote:
all right. and since we're beyond git bisection, can you post a list of say 2 or 3 tests you want me to try in order? as you're the expert here, it would make more sense for you to try to optimize the search pattern here.
If the machine is booting (just with a blank screen), then enable drm.debug=0xe, and check that it is being written to the system log files. Then boot into the broken setup, reboot and grab the debug messages saved from the previous (broken) boot.
Otherwise we shall just wait for the opportunity to log in with a second machine and look for telltales before beginning exploratory surgery. -Chris
On Fri, 28 Jan 2011, Chris Wilson wrote:
On Fri, 28 Jan 2011 11:23:08 -0500 (EST), "Robert P. J. Day" rpjday@crashcourse.ca wrote:
all right. and since we're beyond git bisection, can you post a list of say 2 or 3 tests you want me to try in order? as you're the expert here, it would make more sense for you to try to optimize the search pattern here.
If the machine is booting (just with a blank screen), then enable drm.debug=0xe, and check that it is being written to the system log files. Then boot into the broken setup, reboot and grab the debug messages saved from the previous (broken) boot.
Otherwise we shall just wait for the opportunity to log in with a second machine and look for telltales before beginning exploratory surgery.
ok, this is what works:
==========
$ git diff diff --git a/drivers/gpu/drm/i915/intel_opregion.c b/drivers/gpu/drm/i915/intel_opregion. index 64fd644..645581f 100644 --- a/drivers/gpu/drm/i915/intel_opregion.c +++ b/drivers/gpu/drm/i915/intel_opregion.c @@ -495,10 +495,15 @@ int intel_opregion_setup(struct drm_device *dev) opregion->acpi = base + OPREGION_ACPI_OFFSET; }
+return 0; // rday + if (mboxes & MBOX_SWSCI) { DRM_DEBUG_DRIVER("SWSCI supported\n"); opregion->swsci = base + OPREGION_SWSCI_OFFSET; } + +return 0; // rday + if (mboxes & MBOX_ASLE) { DRM_DEBUG_DRIVER("ASLE supported\n"); opregion->asle = base + OPREGION_ASLE_OFFSET;
==========
*first*, i added the *later* "return 0", and still got the black screen. i then added the one *above* that, and got a good boot, so one therefore concludes that it's the "SWSCI" processing that's causing the problem. of course, that says nothing about whether or not the later "ASLE" check could be re-enabled, or does that even make any sense?
in any event, what's above works. next?
rday
i realize i already posted this to the LKML and CCed it here but, just to summarize, i have a current "git pull" kernel booting fine, with the following patch applied:
diff --git a/drivers/gpu/drm/i915/intel_opregion.c b/drivers/gpu/drm/i915/intel_opregion.c index 64fd644..28adc6d 100644 --- a/drivers/gpu/drm/i915/intel_opregion.c +++ b/drivers/gpu/drm/i915/intel_opregion.c @@ -495,6 +495,8 @@ int intel_opregion_setup(struct drm_device *dev) opregion->acpi = base + OPREGION_ACPI_OFFSET; }
+return 0; // rday + if (mboxes & MBOX_SWSCI) { DRM_DEBUG_DRIVER("SWSCI supported\n"); opregion->swsci = base + OPREGION_SWSCI_OFFSET;
feel free to suggest more testing.
rday
any new developments on this issue? the current kernel is working just fine with the addition of that trivial hack in drivers/gpu/drm/i915/intel_opregion.c:
@@ -495,6 +495,8 @@ int intel_opregion_setup(struct drm_device *dev) opregion->acpi = base + OPREGION_ACPI_OFFSET; }
+return 0; // rday + if (mboxes & MBOX_SWSCI) { DRM_DEBUG_DRIVER("SWSCI supported\n"); opregion->swsci = base + OPREGION_SWSCI_OFFSET;
but i'm obviously still interested in the proper resolution. let me know if you want me to do any more testing.
rday
On Tue, 1 Feb 2011 07:05:16 -0500 (EST), "Robert P. J. Day" rpjday@crashcourse.ca wrote:
any new developments on this issue?
Not really, the only thing left to confirm is whereabouts it goes wrong.
About the only routine of significance is alse_set_backlight().
Does a 'return ASLE_BACKLIGHT_FAILED;' as the first line of that function have a similar effect to the current hack? -Chris
On Tue, 1 Feb 2011, Chris Wilson wrote:
On Tue, 1 Feb 2011 07:05:16 -0500 (EST), "Robert P. J. Day" rpjday@crashcourse.ca wrote:
any new developments on this issue?
Not really, the only thing left to confirm is whereabouts it goes wrong.
About the only routine of significance is alse_set_backlight().
Does a 'return ASLE_BACKLIGHT_FAILED;' as the first line of that function have a similar effect to the current hack?
apparently, it does:
@@ -150,6 +150,8 @@ static u32 asle_set_backlight(struct drm_device *dev, u32 bclp) struct opregion_asle *asle = dev_priv->opregion.asle; u32 max;
+return ASLE_BACKLIGHT_FAILED; // rday + if (!(bclp & ASLE_BCLP_VALID)) return ASLE_BACKLIGHT_FAILED;
gives me a good boot. this is the diff with relation to the recently tagged 2.6.38-rc3. anything else you want me to test?
rday
On Fri, 28 Jan 2011, Chris Wilson wrote:
On Fri, 28 Jan 2011 10:27:09 -0500 (EST), "Robert P. J. Day" rpjday@crashcourse.ca wrote:
victory is mine! ok, that premature return seems to have solved it, i'm up and running under this new kernel. are we getting close?
Not even close. We just disabled functionality that was working in 2.6.37; the interaction between ACPI and gfx. What a shame.
Instead of return -ENOTSUPP at the start, you can return 0 before each of the if (mboxes & MBOX_*) to narrow down which function regressed.
are there any kernel config options i should be looking at? for better or worse, i've attached my .config file.
and i'm sequentially returning 0 before each of those tests starting with the last and working my way back unless you want to prioritize which tests i should deactivate.
rday
On Friday, January 28, 2011, Robert P. J. Day wrote:
On Fri, 28 Jan 2011, Chris Wilson wrote:
On Fri, 28 Jan 2011 09:51:01 -0500 (EST), "Robert P. J. Day" rpjday@crashcourse.ca wrote:
sadly, no change -- still black screen. again, rebooted successfully under commit 8a327f23. just to be clear, here's "git diff":
$ git diff diff --git a/include/linux/acpi_io.h b/include/linux/acpi_io.h index 7180013..e035f3c 100644 --- a/include/linux/acpi_io.h +++ b/include/linux/acpi_io.h @@ -7,7 +7,7 @@ static inline void __iomem *acpi_os_ioremap(acpi_physical_address phys, acpi_size size) {
return ioremap_cache(phys, size);
return ioremap(phys, size);}
Ok, that implies the new mapping is fine and not the cause of the issue.
Instead you have some OpRegion related regression hidden until till now because the conflicting mapping disabled it for i915.
That would be easy to test by returning early in intel_opregion_setup():
diff --git a/drivers/gpu/drm/i915/intel_opregion.c b/drivers/gpu/drm/i915/intel_ index 9efccb9..8c93201 100644 --- a/drivers/gpu/drm/i915/intel_opregion.c +++ b/drivers/gpu/drm/i915/intel_opregion.c @@ -470,6 +470,8 @@ int intel_opregion_setup(struct drm_device *dev) u32 asls, mboxes; int err = 0;
return -ENOTSUPP;pci_read_config_dword(dev->pdev, PCI_ASLS, &asls); DRM_DEBUG_DRIVER("graphic opregion physical addr: 0x%x\n", asls); if (asls == 0) {so you want me to revert to a stock b705120e before doing the above?
Alternatively, you could take the vanilla Linus' tree and replace ioremap_cache() with ioremap() in include/linux/acpi_io.h . Please try that and see if it makes a difference.
Thanks, Rafael
On Fri, 28 Jan 2011, Rafael J. Wysocki wrote:
On Friday, January 28, 2011, Robert P. J. Day wrote:
On Fri, 28 Jan 2011, Chris Wilson wrote:
On Fri, 28 Jan 2011 09:51:01 -0500 (EST), "Robert P. J. Day" rpjday@crashcourse.ca wrote:
sadly, no change -- still black screen. again, rebooted successfully under commit 8a327f23. just to be clear, here's "git diff":
$ git diff diff --git a/include/linux/acpi_io.h b/include/linux/acpi_io.h index 7180013..e035f3c 100644 --- a/include/linux/acpi_io.h +++ b/include/linux/acpi_io.h @@ -7,7 +7,7 @@ static inline void __iomem *acpi_os_ioremap(acpi_physical_address phys, acpi_size size) {
return ioremap_cache(phys, size);
return ioremap(phys, size);}
Ok, that implies the new mapping is fine and not the cause of the issue.
Instead you have some OpRegion related regression hidden until till now because the conflicting mapping disabled it for i915.
That would be easy to test by returning early in intel_opregion_setup():
diff --git a/drivers/gpu/drm/i915/intel_opregion.c b/drivers/gpu/drm/i915/intel_ index 9efccb9..8c93201 100644 --- a/drivers/gpu/drm/i915/intel_opregion.c +++ b/drivers/gpu/drm/i915/intel_opregion.c @@ -470,6 +470,8 @@ int intel_opregion_setup(struct drm_device *dev) u32 asls, mboxes; int err = 0;
return -ENOTSUPP;pci_read_config_dword(dev->pdev, PCI_ASLS, &asls); DRM_DEBUG_DRIVER("graphic opregion physical addr: 0x%x\n", asls); if (asls == 0) {so you want me to revert to a stock b705120e before doing the above?
Alternatively, you could take the vanilla Linus' tree and replace ioremap_cache() with ioremap() in include/linux/acpi_io.h . Please try that and see if it makes a difference.
been there, done that, that's all so ... this morning. i continued bisecting and playing and eventually verified the following workaround for an earlier working version of the kernel:
$ git diff diff --git a/drivers/gpu/drm/i915/intel_opregion.c b/drivers/gpu/drm/i915/intel_opregion.c index 64fd644..28adc6d 100644 --- a/drivers/gpu/drm/i915/intel_opregion.c +++ b/drivers/gpu/drm/i915/intel_opregion.c @@ -495,6 +495,8 @@ int intel_opregion_setup(struct drm_device *dev) opregion->acpi = base + OPREGION_ACPI_OFFSET; }
+return 0; // rday + if (mboxes & MBOX_SWSCI) { DRM_DEBUG_DRIVER("SWSCI supported\n"); opregion->swsci = base + OPREGION_SWSCI_OFFSET;
this was based on a suggestion by chris wilson to deactivate the "mboxes" tests in that single source file and see what happened. adding the "return 0" above suddenly gave me a properly booting kernel. i applied the same diff to the current kernel and it's building as we speak.
rday
p.s. having that "return 0" *after* that test but before the next one still gave me a black screen.
On Fri, 28 Jan 2011, Rafael J. Wysocki wrote:
Alternatively, you could take the vanilla Linus' tree and replace ioremap_cache() with ioremap() in include/linux/acpi_io.h . Please try that and see if it makes a difference.
as a quick followup, i applied the following simple patch:
$ git diff diff --git a/drivers/gpu/drm/i915/intel_opregion.c b/drivers/gpu/drm/i915/intel_opregion.c index 64fd644..28adc6d 100644 --- a/drivers/gpu/drm/i915/intel_opregion.c +++ b/drivers/gpu/drm/i915/intel_opregion.c @@ -495,6 +495,8 @@ int intel_opregion_setup(struct drm_device *dev) opregion->acpi = base + OPREGION_ACPI_OFFSET; }
+return 0; // rday + if (mboxes & MBOX_SWSCI) { DRM_DEBUG_DRIVER("SWSCI supported\n"); opregion->swsci = base + OPREGION_SWSCI_OFFSET;
to the latest tree, and it gave me a booting kernel, no black screen issue. i will not pretend to understand why that fixes the problem but it does.
rday
On Fri, 28 Jan 2011, Chris Wilson wrote:
Well, we have two endpoints, so let git attack:
$ git bisect start $ git bisect good 58bbf018a70c562437eeae121a5d021ba7fe56a5 $ git bisect bad abb72c828878a2c69b2cfb33ac30007c8ecd735e
That shouldn't take more than a few recompiles to identify the troublemaker.
it appears i have one bisection left to make but, just a bit of info, the black screen issue kicks in when the kernel tries to change the font size of the early kernel messages to a much smaller font (or at least it happens around that time).
typically, regardless of the kernel, i get a couple of large font messages (/dev/pts and one other, memory fails me), at which point a good kernel will switch to a much smaller font and continue. with a "bad" kernel, the display on my laptop goes black and stays that way, despite the fact that the boot is obviously still progressing.
you can decide if that is at all helpful. back to bisecting. should be getting close.
rday
dri-devel@lists.freedesktop.org
-
Chris Wilson -
Rafael J. Wysocki -
Robert P. J. Day