Summary: | uvesafb blanks the screen when changing terminals if scrolling text is occuring | ||
---|---|---|---|
Product: | Gentoo Linux | Reporter: | Dave N <avebelial> |
Component: | Current packages | Assignee: | Michal Januszewski (RETIRED) <spock> |
Status: | RESOLVED UPSTREAM | ||
Severity: | major | CC: | steven |
Priority: | High | ||
Version: | unspecified | ||
Hardware: | x86 | ||
OS: | Linux | ||
Whiteboard: | |||
Package list: | Runtime testing required: | --- | |
Attachments: |
Kernel Config
lspci output |
Description
Dave N
2008-08-24 11:39:13 UTC
Created attachment 163702 [details]
Kernel Config
Created attachment 163704 [details]
lspci output
As lspci doesn't state it clearly, the graphics card being used is an Nvidia 8600M GS v86d is at version 0.1.6 with no use flags set Unlike the other bugs the system is still usable. Output of dmesg | grep vesafb dave@sophie:~$ dmesg | grep vesafb Kernel command line: root=/dev/sda3 resume=/dev/sdb2 video=uvesafb:mtrr:1,ywrap,1440x900-16@60 uvesafb: NVIDIA Corporation, G86 Board - e416h01c, Chip Rev , OEM: NVIDIA, VBE v3.0 uvesafb: protected mode interface info at c000:b7b0 uvesafb: pmi: set display start = c00cb813, set palette = c00cb86e uvesafb: pmi: ports = 3b4 3b5 3ba 3c0 3c1 3c4 3c5 3c6 3c7 3c8 3c9 3cc 3ce 3cf 3d0 3d1 3d2 3d3 3d4 3d5 3da uvesafb: VBIOS/hardware doesn't support DDC transfers uvesafb: no monitor limits have been set, default refresh rate will be used uvesafb: scrolling: ywrap using protected mode interface, yres_virtual=7200 uvesafb: framebuffer at 0xc5000000, mapped to 0xf8880000, using 10125k, total 14336k After it happening again, Ive found this in dmesg uvesafb: mode switch failed (eax=0x182b, err=0) uvesafb: VBE state restore call failed (eax=0x1c04, err=0) uvesafb: mode switch failed (eax=0xff04, err=0) uvesafb: mode switch failed (eax=0xff04, err=0) uvesafb: VBE get state call failed (eax=0x0, err=0) uvesafb: mode switch failed (eax=0x2105, err=0) uvesafb: mode switch failed (eax=0xff04, err=0) uvesafb: VBE state restore call failed (eax=0x1c04, err=0) uvesafb: mode switch failed (eax=0x2104, err=0) uvesafb: mode switch failed (eax=0xff04, err=0) uvesafb: mode switch failed (eax=0x0, err=0) uvesafb: VBE state restore call failed (eax=0x2104, err=0) uvesafb: mode switch failed (eax=0x82b, err=0) (This was after watching a video on tty1 with mplayer through the framebuffer) Could you please try to build v86d with the x86emu USE flag and see whether this changes anything? Same problem with the x86emu use flag set, with this in dmesg uvesafb: VBE get state call failed (eax=0x2a, err=0) uvesafb: mode switch failed (eax=0x873, err=0) uvesafb: mode switch failed (eax=0xff04, err=0) uvesafb: mode switch failed (eax=0xff04, err=0) after trying to change terminals while gcc was spewing output Could you please try rebuilding your kernel with CONFIG_SCHED_HRTICK=n and see whether this changes anything? There is a known problem with this option in 2.6.26, which could be causing this kind of errors. I'm having the same problem with kernel v2.6.26 vanilla. I tried with CONFIG_SCHED_HRTICK off and with 'nocrtc' on the boot line and am encountering the same issue, but with some more strange eax values than Dave N: [ 73.740827] uvesafb: mode switch failed (eax=0xeb, err=0) [ 74.381207] uvesafb: mode switch failed (eax=0x1121104, err=0) [ 76.065148] uvesafb: mode switch failed (eax=0x1121105, err=0) [ 78.133360] uvesafb: mode switch failed (eax=0x1120000, err=0) [ 78.857236] uvesafb: mode switch failed (eax=0x20100100, err=0) And looking at the code for uvesafb.c, I can't see anything that jumps out at me as to why this is occurring. Ideas? I can't reproduce this bug on 2.6.27-rc5-tip. I will check 2.6.27-rc6 from Linus pristine branch in a while. Apparently the bug will be resolved in the 2.6.27 release, because 2.6.27-rc6 does not suffer the same symptoms. Unfortunately, the latest stable (2.6.26.5) still shows the symptoms. OK, closing as 'upstream' then. If any of you really need to get it working correctly in 2.6.26*, then I'm afraid you'll need to do a git bisect between the broken version and the working one and try to identify the commit which fixes the problem. Even then we can't really guarantee it will be backportable to 2.6.26. Thanks for your work in tracking the bug. |