Distribution: Debian Sarge Hardware Environment: P4,1GB RAM,Intel D865GBF Desktop Board, only integrated graphics card Software Environment: X-server4.3.0 Problem Description: i can't load intelfb module Steps to reproduce: rmmod intelfb - if module loaded modprobe intelfb // module i830 is loaded
Created attachment 5152 [details] error message from modprobe action
Created attachment 5153 [details] lspci -vvv
Created attachment 5154 [details] lspci -n
Created attachment 5155 [details] kernel config
This bug is caused by ioremapping a huge amount of address space. It fails because ioremap is limited to 128 MB - 4096. The maintainer of the driver already added a kernel boot option "vram" to limit this amount. Try to boot with video=intelfb:vram:64. I'll close this bug, but reopen it if it does not work
>Try to boot with video=intelfb:vram:64. Sorry for late answer. I test boot with this option. module intelfb not loaded. Aug 10 01:31:33 prog3 kernel: Kernel command line: BOOT_IMAGE=2.6.13-rc6 ro root=302 video=intelfb:vram:64
Sorry, I misinterpreted the 'vram' option. intelfb is still trying to remap the entire aperture which is not entirely correct. vram is for the GATT. I'll try to make a patch for you and I'll also forward this to the intelfb maintainer. Tony
Created attachment 5568 [details] Do not ioremap the entire graphics aperture Try this patch. Then load intelfb even without options. Let me know of the results including the output of dmesg and fbset -i. Thanks
The same result. No info in log. I retest this once time in this evening (+16 hours). possible tip: integrated graphics card has no indentification in kernel source (pci_ids). may be usefull. 0000:00:00.0 0600: 8086:2570 (rev 02) 0000:00:01.0 0604: 8086:2571 (rev 02) ^^^^^^ This same problem has i830 driver (dri). Module loaded, but has zero value. prog3:/home/goldenfish# lsmod | grep -a 'intelfb\|i830\|mga' i830 28928 0 ^^^ intelfb 40096 0 cfbcopyarea 4224 2 matroxfb_accel,intelfb cfbimgblt 3200 2 matroxfb_accel,intelfb cfbfillrect 4224 2 matroxfb_accel,intelfb softcursor 2304 2 matroxfb_accel,intelfb mga 60288 1 ^^^^^
It loaded successfully if your lsmod showed something. Do a 'cat /proc/fb'. If you see an entry there for intelfb, then it was successfully loaded. What you want is probably the framebuffer console. Checking your kernel config, I see that CONFIG_FRAMEBUFFER_CONSOLE=m. Meaning, you have to do a modprobe fbcon after doing a modprobe intelfb. (Why not set CONFIG_FRAMEBUFFER_CONSOLE=y? This way you automatically get a console after modprobe intelfb). Note: You have 2 drivers loaded, matroxfb and intelfb. The first entry in /proc/fb is the one that will be used by fbcon. To be sure rmmod the other driver first before modprobing fbcon.
There is full report: status: intel framebuffer working. kernel config: CONFIG_FRAMEBUFFER_CONSOLE=y CONFIG_FB_INTEL=y 1 option) agp - no card (was MGA 550), i865 integrated Working. I see tux logo. working also with dri i830 module(module i830 additionally after testing intelfb module loaded. one problem: If i switch fbset -a -depth 800x600-100 console change resolution. If i switch to another console or switch to X and return back, resolution is default 1024x768 from kernel source. I don't know, that is error or feature. Working succesfully with vram 64 or 128MB . 2 option) apg - MGA550 ,i865 integrated graphics card. I see only signal from AGP adapter(MGA550). If i change in BIOS primary display adapter (AGP/PCI) - no change - only see signal from AGP display adapter(MGA550). module intelfb possible to load, but no info from fbset -i -fb fb[01] about intel865 integrated graphics card. From cat /proc/fb 0 MATROX in the .bz2 attachment: - aktual kernel config - kernel.log - /var/log/messages - fbset about intelfb thanks for your time goldenfish
Created attachment 5591 [details] messages,kernel.log,fbset-i There is attachment. /var/log/kernel.log, /var/log/messages, fbset -i -fb /dev/fb0, aktual kernel config
1. Can you also try if it works with the "Do not ioremap the entire graphics aperture" patch? You're happen to work because your chipset only has a 128MB aperture. 2. The resolution 800x600 should persist with the particular tty. So if you switch back to it and it comes back at 1024x768, then it's a bug. Can you do it again? Set the resolution to fbset 800x600-100, switch to another console then back again. Then, post the dmesg starting when you see this line: intelfb: intelfb_set_par (800x600-32) 3. I believe that Intel integrated chipsets don't want to coexist with other add-on cards in the pci or agp slot. You can try to initialize the intel chipset first by launching X (using i810 as the driver). If X loads successfully, exit X, then modprobe intelfb.
Hi, there is report. 1)........ the "Do not ioremap the entire graphics aperture" patch? it was tested only with this patch. 2) changing resolution - in the attachment are information. process: console;fbset 800x600-100,next console switching, previous console switching. This seems to be bug in all framebuffer or fbset. Similar problem i have with matrox. option: matrox module compiled in kernel. boot with video=matroxfb:vesa:0x115,depth=32. ==> after booting 800x600-60@32bpp in console i run fbset -a -depth 32 800x600-100. i changing only frequency in one console. not in all console. if matroxfb as module and if i load matrox module, changing in all console resolution and frequency with no problem. fbset --version Linux Frame Buffer Device Configuration Version 2.1 (23/06/1999) (C) Copyright 1995-1999 by Geert Uytterhoeven fbset - version from debian testing distribution. 3) this is propably intel feature. a) AGP card working, integrated card no signal to monitor. bios setting do not help this. b) no AGP card in slot. integrated card give signal to monitor. bios setting from testing: -->Video settings - AGP Aperature Size - 128MB /other values in bios 4,8,16,32,64,128,256, not tested today with this values - Primary Video Adapter - AGP - Framebuffer Size - 16MB / other values 1,8,16 other information in attachment. sorry for my bad english.
Created attachment 5610 [details] dmesg, console swithing testing
1. Maybe you can try the patch "Do not ioremap the entire graphics aperture" using an AGP aperture size of 256. That is where intelfb will fail. 2. I would like to clarify the intelfb bug. You said that you changed the resolution of tty1 to 800x600, then you switch to tty2, then you switch back to tty1. But tty1, instead of having a resolution of 800x600 is set at 1024x768? I looked at dmesg_swith_console_back.txt. First, I see a switch to 800x600 (that's probably the one when you did fbset 800x600-100). This is followed by a switch to 1024x768 which I presume is when you switched to another console. Then that's it. I was expecting a switch back to 800x600-100, but I don't see any. Is this particular bug present with matroxfb? 3. The "fbset -a" changing only 1 console is a known bug but this is already fixed in the mm tree. You can try this patch: http://kernel.org/pub/linux/kernel/people/akpm/patches/2.6/2.6.13-rc4/2.6.13-rc4-mm1/broken-out/fbdev-add-fbset-a-support.patch
2. >I would like to clarify the intelfb bug. You said that you changed the >resolution of tty1 to 800x600, then you switch to tty2, then you switch back to >tty1. > But tty1, instead of having a resolution of 800x600 is set at 1024x768? Yes. > I looked at dmesg_swith_console_back.txt. First, I see a switch to 800x600 >(that's >probably the one when you did fbset 800x600-100). This is followed by a switch >to 1024x768 which I presume is when you switched to another console. Then >that's it. I was expecting a switch back to 800x600-100, but I don't see any. Order of debug files: initial options: tty1,tty2 - 1024x768-60 1) tty1 - fbset after booting (1024x768-60) file: fbset_def_1.txt ( _def as default) 2) tty1 - fbset 800x600-100 file: fbset_800x600-100_1 tty1: 800x600-100 3) swith to tty2, swith to tty1 file: fbset_800x600-100_after_swith_and_back_1 tty1: 1024x768-60 (the same as default from kernel booting) >Is this particular bug present with matroxfb? No, matroxfb worked fine. No problem with this. 3) i retest this patch in next days
>Order of debug files: >initial options: tty1,tty2 - 1024x768-60 >1) tty1 - fbset after booting (1024x768-60) >file: fbset_def_1.txt ( _def as default) >2) tty1 - fbset 800x600-100 >file: fbset_800x600-100_1 >tty1: 800x600-100 >3) swith to tty2, swith to tty1 >file: fbset_800x600-100_after_swith_and_back_1 >tty1: 1024x768-60 (the same as default from kernel booting) Okay. But what I'm most interested in is the dmesg when you switch from tty2 to tty1 (#3). I can't infer it from the attachment. What I would like to see in dmesg is something like this: intelfb: intelfb_set_par (800x600-8) /* fbset 800x600-100 */ ... intelfb: intelfb_set_par (1024x768-32) /* switch to tty2 */ ... intelfb: intelfb_set_par (800x600-8) /* switch back to tty1 */ (ie: start all tty's att 1024x768; then in tty1, fbset 800x600-100; switch to tty2; switch to tty1; dmesg > dmesg.log; submit dmesg.log) >>Is this particular bug present with matroxfb? >No, matroxfb worked fine. No problem with this. Ok. So it is an intelfb-specific bug then. Maybe we should close this bug as you can use intelfb already and just open another bugzilla entry for this specific bug?
>(ie: start all tty's att 1024x768; then in tty1, fbset 800x600-100; switch to >tty2; switch to tty1; dmesg > dmesg.log; submit dmesg.log) Ok, i will be send this information in this night with new bugzilla entry. >>Is this particular bug present with matroxfb? >No, matroxfb worked fine. No problem with this. > >Ok. So it is an intelfb-specific bug then. >Maybe we should close this bug as you can use intelfb already and just open >another bugzilla entry for this specific bug? Yes. Close this bug, please. I create new bugzilla entry this night. thanks pavel
>3. The "fbset -a" changing only 1 console is a known bug but this is already >fixed in the mm tree. You can try this patch: >http://kernel.org/pub/linux/kernel/people/akpm/patches/2.6/2.6.13-rc4/2.6.13-rc4-mm1/broken-out/fbdev-add-fbset-a-support.patch I test this patch with intelfb driver. command: fbset -a -depth 32 800x600-100 There is small problem. Resolution and color depth changed correcty. In next consoles i see only black screen and cursor. If i write letter, i see this letter. If i write command clear in console(redraw screen), problem solved.
Yep, know bug, that's why it's still in the mm tree. In my system, at least, I think it works okay if: a: going from low-res to high-res; or b. you're already logged in It does not work if: a. going from high-res to low-res; b. you are not logged-in yet I'm still trying to look for the problem, so it might take some time as there are more critical bugs I have to entertain. (Of course, this is a different bug and probably deserves a new entry)
Created attachment 5640 [details] Fix buffer copy on vc resize Okay, I think I know what caused the blank screen when going from a high res mode to a low-res mode on an fbset -a. This is because only the contents at the bottom of the buffer will be copied to the new one. And if the contents of the old buffer are predominantly located at the top, they will be missed by the copy. So, this patch changes the behavior by basing it on the current cursor position. If the cursor is near the top, it will copy the contents from the top to the bottom, and if near the bottom, it will copy the contents from the bottom to the top. This should fix the blank screen and should result in better behavior as the "active" region of the screen will always be copied. You will still need to apply the patch in the mm tree (addition of fbset -a support) to see it's full effect (You already applied it).
Hi, i tested patch "Fix buffer copy on vc resize". Tested complete on intelfb. On MGA550 in next 2 days. tested command: fbset -a resolution-frequency -depth color_depth console: text color - white, background: black. intelfb: redrawing works OK in all cases. problems: switch to bpp 32 - OK switch to bpp 8 - i don't see cursor, blinking letter: white<-> black switch to bpp 16 - cursor blinking green, blinking letter: white<-> green Problems with cursor not depended to switching resolution (smaller or larger). matrox seems to be ok. I retest this. monitor - CRT Mitshubishi Diamond Pro 2045u - 22'
>Hi, > >i tested patch "Fix buffer copy on vc resize". > >Tested complete on intelfb. On MGA550 in next 2 days. > >tested command: fbset -a resolution-frequency -depth color_depth >console: text color - white, background: black. > >intelfb: redrawing works OK in all cases. Thanks for testing. >problems: >switch to bpp 32 - OK >switch to bpp 8 - i don't see cursor, blinking letter: white<-> black >switch to bpp 16 - cursor blinking green, blinking letter: white<-> green > >Problems with cursor not depended to switching resolution (smaller or larger). I think it's a known bug that intelfb's hardware cursor may not work for all kinds of chipsets. Boot with video=intelfb:hwcursor:0 to turn off hardware cursor. Sylvain, If intel's cursor is problematic, why not disable hwcursor as default?
I tested patch "Fix buffer copy on vc resize" on MGA550. Works fine.