| Summary: | Uvesafb fails on 2.6.32-gentoo | ||
|---|---|---|---|
| Product: | Gentoo Linux | Reporter: | haarp <main.haarp> |
| Component: | [OLD] Unspecified | Assignee: | Michal Januszewski (RETIRED) <spock> |
| Status: | RESOLVED FIXED | ||
| Severity: | normal | CC: | broken.zhou, gdibble, gentoo, jackdachef, jmbsvicetto, joshua.rich, juggernautfin, nitro, public, serkan |
| Priority: | High | ||
| Version: | unspecified | ||
| Hardware: | AMD64 | ||
| OS: | Linux | ||
| Whiteboard: | |||
| Package list: | Runtime testing required: | --- | |
| Attachments: |
emerge --info
A patch to fix uvesafb after the change in the definition of abs() A new patch to test whether the problem is in uvesafb.c A patch to restore the old abs() in uvesafb.c and modedb.c Explicitly cast abs values to u32 in modedb.c A patch to fix the problem. include-linux-kernelh-abs-fix-handling-of-32-bit-unsigneds-on-64-bit.patch |
||
|
Description
haarp
2009-12-11 17:23:05 UTC
Please try booting without the uvesafb mtrr parameter, and please provide the output of fbset -i. $ fbset -i
mode "320x200-60"
# D: 4.240 MHz, H: 12.471 kHz, V: 59.955 Hz
geometry 320 200 320 200 32
timings 235849 10 -17 4 1 27 3
vsync high
rgba 8/16,8/8,8/0,8/24
endmode
Frame buffer device information:
Name : VESA VGA
Address : 0xf9000000
Size : 10485760
Type : PACKED PIXELS
Visual : TRUECOLOR
XPanStep : 0
YPanStep : 0
YWrapStep : 0
LineLength : 1280
Accelerator : No
Did you try booting without the mtrr parameter? Did it change anything? Could you please paste the contents of /sys/class/graphics/fb0/device/vbe_modes? Yes, I just tried that. Command line: root=/dev/sda1 video=uvesafb:1920x1200-32@60,ywrap fbcon=scrollback:1024K acpi_enforce_resources=lax dmesg: uvesafb: NVIDIA Corporation, G80 Board - p355h00 , Chip Rev , OEM: NVIDIA, VBE v3.0 uvesafb: VBIOS/hardware doesn't support DDC transfers uvesafb: no monitor limits have been set, default refresh rate will be used uvesafb: scrolling: redraw Console: switching to colour frame buffer device 40x25 uvesafb: framebuffer at 0xf9000000, mapped to 0xffffc90008100000, using 10240k, total 14336k fb0: VESA VGA frame buffer device $ cat /sys/class/graphics/fb0/device/vbe_modes 640x400-8, 0x0100 640x480-8, 0x0101 800x600-8, 0x0103 1024x768-8, 0x0105 1280x1024-8, 0x0107 320x200-16, 0x010e 320x200-32, 0x010f 640x480-16, 0x0111 640x480-32, 0x0112 800x600-16, 0x0114 800x600-32, 0x0115 1024x768-16, 0x0117 1024x768-32, 0x0118 1280x1024-16, 0x011a 1280x1024-32, 0x011b 320x200-8, 0x0130 320x400-8, 0x0131 320x400-16, 0x0132 320x400-32, 0x0133 320x240-8, 0x0134 320x240-16, 0x0135 320x240-32, 0x0136 640x400-16, 0x013d 640x400-32, 0x013e OK, please try setting a higher resolution after boot using: fbset -xres 1280 -yres 1024 -depth 32 Thanks so far! I tried that. Now I get no signal on the console, and v86d is munching 100% CPU on one core ;) $ fbset -xres 1280 -yres 1024 -depth 32 ioctl FBIOPUT_VSCREENINFO: Invalid argument $ dmesg | tail uvesafb: mode switch failed (eax=0x4f02, err=1) detected fb_set_par error, error code: -22 uvesafb: mode switch failed (eax=0x4f02, err=1) detected fb_set_par error, error code: -22 uvesafb: mode switch failed (eax=0x4f02, err=1) detected fb_set_par error, error code: -22 uvesafb: mode switch failed (eax=0x4f02, err=1) detected fb_set_par error, error code: -22 What is the latest kernel version for which uvesafb works correctly for you? 2.6.30-gentoo (I skipped 2.6.31) But even on 2.6.30 and older, I only ever managed to get 1280x1024 on my Geforce 8800GTX. The 8600GT that I used before had no problems with 1920x1200. (In reply to comment #9) > 2.6.30-gentoo (I skipped 2.6.31) OK. I'm afraid the only reasonable way to find the source of this problem is to find the commit that broke uvesafb using git bisect. Basically, you'd have to get a git clone of the mainline kernel tree from http://git.kernel.org/?p=linux/kernel/git/torvalds/linux-2.6.git;a=summary, and then run git bisect repeatedly to find the problem. git-bisect is nicely described in [1]. > But even on 2.6.30 and older, I only ever managed to get 1280x1024 on my > Geforce 8800GTX. The 8600GT that I used before had no problems with 1920x1200. That might be perfectly normal, see [2] for an explanation. [1] http://www.kernel.org/pub/software/scm/git/docs/git-bisect.html [2] http://dev.gentoo.org/~spock/projects/uvesafb/faq.php Ok, 2.6.31-gentoo still works aswell. It broke between .31 and .32 I only see one revision in uvesafb.c between .31 and .32. You probably want me to bisect other components aswell, I assume? Which ones could be relevant here? Bisecting every file system driver, sound card and scheduler there is would take quite a while, and is probably not needed, is it? ;) (In reply to comment #7) > $ fbset -xres 1280 -yres 1024 -depth 32 > ioctl FBIOPUT_VSCREENINFO: Invalid argument Did you try the command from x11 or from a framebuffer console ? I launched it first from an xterm but had the same error message than you. As far as I remember, I tried that on the console. I made an interesting discovery though: This bug does not appear on a Geforce 9300GE. Only on my 8800GTX. (In reply to comment #11) > Ok, 2.6.31-gentoo still works aswell. It broke between .31 and .32 > > I only see one revision in uvesafb.c between .31 and .32. You probably want me > to bisect other components aswell, I assume? Which ones could be relevant here? > Bisecting every file system driver, sound card and scheduler there is would > take quite a while, and is probably not needed, is it? ;) Sorry for the late reply, I somehow missed this comment. The unfortunate answer to your question is that you need to bisect through pretty much everything. Whatever broke uvesafb is not in the driver itself (as you noted, there are rarely any changes and if there are, they are mostly cosmetic ones). I'd suspect something from the arch/x86, but that's just a guess. You could try skipping changes in drivers, subsystems and architectures that you do not use, but I'm not sure if this is worth the effort of looking through the change logs. Since the number of bisections is a logarithm of the number of changesets, one can easily cover thousands of them in 10+ bisections. Output from git bisect: a49c59c042c63b432307c1bbf7dac5a104c786e6 is the first bad commit commit a49c59c042c63b432307c1bbf7dac5a104c786e6 Author: Rolf Eike Beer <eike-kernel@sf-tec.de> Date: Tue Sep 22 16:44:03 2009 -0700 Make sure the value in abs() does not get truncated if it is greater than 2^32 abs() will truncate the input if is it outside the 2^32 range. Fix that by assuming `long' input. This might generate worse code in the common case. Signed-off-by: Rolf Eike Beer <eike-kernel@sf-tec.de> Signed-off-by: Andrew Morton <akpm@linux-foundation.org> Signed-off-by: Linus Torvalds <torvalds@linux-foundation.org> :040000 040000 9e6dcbf3d7a65e5e66d2df110a064454e512ef39 80f39a85fb54f272b81f00e93b7da4eda93aee67 M include (In reply to comment #15) Thanks for identifying the commit! Can you confirm that reverting it makes uvesafb work with the latest kernel? You can revert it by running: git show a49c59c042c63b432307c1bbf7dac5a104c786e6 | patch -R -p1 in your kernel git checkout. (In reply to comment #16) I grabbed the latest git kernel and then reverted the one commit. uvesafb now works as intended. $ uname -a Linux ... 2.6.34-rc3-00299-g0fdf867-dirty ... THANK YOU to everyone who has done the hard work so far. [v86d not working with gentoo-sources above 2.6.31-r10 - thus 2.6.32 through 2.6.33-r1 boot at very low resolution.] personally confirmed on k8/ati but also seen on other platforms. look forward to using v86d with new [33] kernel :) I've been having this problem as well since upgrading to 2.6.32. Finally got around to investigating. Any news on whether or not this is supposed to be fixed in later kernel versions (or maybe v86d itself)? I've seen a fair amount of discussion about the problem, but nothing regarding a solution. Thanks. Created attachment 232545 [details]
emerge --info
Comment on attachment 232545 [details] emerge --info HP TouchSmart tx2z 1300 ATI Tech RS780M/RS780MN [Radeon HD 3200 Graphics] grub.conf kernel conf: video=uvesafb:1280x800-32,mtrr:3,ywrap 2.6.31-r10 - thus 2.6.34 http://bugs.gentoo.org/attachment.cgi?id=232545 [Learning git and revert process to test suggestions below. Would like to help if I can. Thank you guys; much appreciated.] Today I compiled 2.6.34 and the problem still exists. Does upstream know about this bug? Will this ever be solved? Or do I have to buy a new laptop;-) Created attachment 240249 [details, diff]
A patch to fix uvesafb after the change in the definition of abs()
I'm sorry it took so long for me to react to this. Let's get this fixed once and for all :) Could somebody please confirm whether the attached patch fixes the problem for them?
(In reply to comment #23) > Could somebody please confirm whether the attached patch fixes > the problem for them? > I applied the patch, recompiled the kernel and booted it, but the patch had no effect. # grep -C 5 "unsigned int h = 0, d = UINT_MAX" ./drivers/video/uvesafb.c static int uvesafb_vbe_find_mode(struct uvesafb_par *par, int xres, int yres, int depth, unsigned char flags) { int i, match = -1; unsigned int h = 0, d = UINT_MAX; for (i = 0; i < par->vbe_modes_cnt; i++) { h = abs(par->vbe_modes[i].x_res - xres) + abs(par->vbe_modes[i].y_res - yres) + abs(depth - par->vbe_modes[i].depth); lars_laptop linux # pwd /usr/src/linux lars_laptop linux # Created attachment 240313 [details, diff]
A new patch to test whether the problem is in uvesafb.c
Thanks for testing. Could you please remove the previous patch and apply the one that I'm attaching? If it doesn't work with this new patch, we will know that the problem is outside of uvesafb.c (probably somewhere in the framebuffer layer code).
(In reply to comment #25) > Could you please remove the previous patch and apply the > one that I'm attaching? I did - no effect. Created attachment 240365 [details, diff]
A patch to restore the old abs() in uvesafb.c and modedb.c
OK, thanks for testing. It looks like the problem might be coming out of modedb.c then. Could you please remove the previous patch and apply the new one?
(In reply to comment #27) > Could you please remove the previous patch and apply the new > one? Done. This one worked. Is this the fix or just for the localization of the problem? Created attachment 240379 [details, diff]
Explicitly cast abs values to u32 in modedb.c
The previous patches were just to pin down the location of the bug (seems to be modedb.c). Could you please check it with this new patch? (it is to verify that I correctly guessed the exact location of the bug and that a cast to u32 fixes it)
Could you also please let me know which gcc version you're using to compile the kernel, and whether your system is 32-bit or 64-bit? I've been having this problem as well. I tried your latest modedb.patch, but that didn't seem to have any effect at all. Using this boot parameter: video=uvesafb:1440x900-16,mtrr:3,ywrap I got 320x200 video, same as before. I then reverted to the previous patch, uvesafb-modedb-absint.patch, and that worked a little better. Using the same parameter above, I now get 1024x768. Still not my native resolution, but far, far better than 320x200. :-) (In reply to comment #30) > Could you also please let me know which gcc version you're using to compile the > kernel, and whether your system is 32-bit or 64-bit? $ gcc --version gcc (Gentoo 4.4.3-r2 p1.2) 4.4.3 $ uname -m x86_64 And btw my boot parameters: video=uvesafb:1680x1050-32,mtrr:3,ywrap,splash=verbose,theme:natural_gentoo,fbcon=scrollback:256K,init=/sbin/bootchartd (In reply to comment #29) > Could you please check it with this new patch? I reverted the previous patch and applied the new one. The resolution is 40x16 chars again. Created attachment 240409 [details, diff]
A patch to fix the problem.
Thanks for testing the previous patches and providing the info I asked for. I was able to reproduce the problem, and subsequently fix it with the attached patch. Please confirm that it fixes this issue for you as well.
(In reply to comment #33) > Please confirm that it fixes this issue for you as well. Confirmed. Congratulations and thanks for the fix and for the development in the first place! (In reply to comment #34) > Confirmed. Congratulations and thanks for the fix and for the development in > the first place! Thanks for the confirmation! I'm working on getting a fix for this into the mainline kernel. Before that happens, a simple workaround is to specify on the kernel command line one of the resolutions supported by the VBE (see /sys/class/graphics/fb0/device/vbe_modes for a list). Thank you for all of your hard work to patch and push the fix :) It is greatly appreciated! (In reply to comment #35) > I'm working on getting a fix for this into the > mainline kernel. Is there any progress? Today I compiled 2.6.36 and this bug still exists? (In reply to comment #37) > (In reply to comment #35) > > I'm working on getting a fix for this into the > > mainline kernel. > Is there any progress? Today I compiled 2.6.36 and this bug still exists? There is a patch for that in Andrew Morton's patchset. Since the patch touches a core piece of kernel code, it might take a while until it is moved into the mainline kernel. If you're interested, the name of the patch is include-linux-kernelh-abs-fix-handling-of-32-bit-unsigneds-on-64-bit.patch (In reply to comment #38) > (In reply to comment #37) > > (In reply to comment #35) > > > I'm working on getting a fix for this into the > > > mainline kernel. > > Is there any progress? Today I compiled 2.6.36 and this bug still exists? > > There is a patch for that in Andrew Morton's patchset. Since the patch touches > a core piece of kernel code, it might take a while until it is moved into the > mainline kernel. If you're interested, the name of the patch is > include-linux-kernelh-abs-fix-handling-of-32-bit-unsigneds-on-64-bit.patch > Just for those who do not know how to patch their kernel: cd /usr/src/linux wget http://userweb.kernel.org/~akpm/mmotm/broken-out/include-linux-kernelh-abs-fix-handling-of-32-bit-unsigneds-on-64-bit.patch patch -p1 < include-linux-kernelh-abs-fix-handling-of-32-bit-unsigneds-on-64-bit.patch The url of "include-linux-kernelh-abs-fix-handling-of-32-bit-unsigneds-on-64-bit.patch" is broken and the uvesafb_fix.patch can't apply to kernel 2.6.37. Created attachment 263871 [details, diff] include-linux-kernelh-abs-fix-handling-of-32-bit-unsigneds-on-64-bit.patch (In reply to comment #40) > The url of > "include-linux-kernelh-abs-fix-handling-of-32-bit-unsigneds-on-64-bit.patch" is > broken and the uvesafb_fix.patch can't apply to kernel 2.6.37. I'm attaching the mentioned patch. It applies to .37 as well. Seems to me that this is fixed in 2.6.38 and should probably be closed. Thank you so much for fixing this. Apologies for the late response as I was having trouble for some time signing into bugziller. I wanted to post my successful follow-up in response to my posts above. I was able to test Serkan Kaba's `include-linux-kernelh-abs-fix-handling-of-32-bit-unsigneds-on-64-bit.patch' and confirm that it did indeed fix the issue on x86_64. My test succeeded well before the release of kernel v2.6.38 which M.Conway most recently reports as now fixed inline. In my case I am no longer using this system but still extremely grateful for all the hard work done by everyone here. Thank you kindly! My best regards >>> Closing as suggested in comment #42. |
