Menu
▾
▴
linux-fbdev-devel
|
From: Antonino A. D. <ad...@ho...> - 2005-03-15 23:49:27
|
On Wednesday 16 March 2005 07:20, Luigi Gangitano wrote: > Il giorno mer, 16-03-2005 alle 04:39 +0800, Antonino A. Daplas ha > > scritto: > > working: > > atyfb: 3D RAGE (XL) [0x4752 rev 0x27] 8M SDRAM, 29.498928 MHz XTAL, 230 > > MHz PLL, 100 Mhz MCLK > > > > not working: > > atyfb: 3D RAGE XL (Mach64 GR, PCI-33MHz) [0x4752 rev 0x27] > > atyfb: 8M SDRAM (1:1), 29.498928 MHz XTAL, 230 MHz PLL, 83 Mhz MCLK, 63 > > MHz XCLK > > > > The MCLK value is different. Can you try booting with > > > > video=atyfb:mclk:100 > > > > You can also experiment with xclk: > > > > video=atyfb:mclk:100,xclk:63 > > No luck, with neither option. Hmmn, let's just wait for the other developers to respond. Tony |
|
From: Alexander K. <ale...@gm...> - 2005-03-19 16:18:22
|
Am Mittwoch, 16. M=E4rz 2005 00:49 schrieb Antonino A. Daplas: > On Wednesday 16 March 2005 07:20, Luigi Gangitano wrote: > > Il giorno mer, 16-03-2005 alle 04:39 +0800, Antonino A. Daplas ha > > > > scritto: > > > working: > > > atyfb: 3D RAGE (XL) [0x4752 rev 0x27] 8M SDRAM, 29.498928 MHz XTAL, 2= 30 > > > MHz PLL, 100 Mhz MCLK > > > > > > not working: > > > atyfb: 3D RAGE XL (Mach64 GR, PCI-33MHz) [0x4752 rev 0x27] > > > atyfb: 8M SDRAM (1:1), 29.498928 MHz XTAL, 230 MHz PLL, 83 Mhz MCLK, = 63 > > > MHz XCLK > > > > > > The MCLK value is different. Can you try booting with > > > > > > video=3Datyfb:mclk:100 > > > > > > You can also experiment with xclk: > > > > > > video=3Datyfb:mclk:100,xclk:63 > > > > No luck, with neither option. > > Hmmn, let's just wait for the other developers to respond. > > Tony Copyed from oldest mail...=20 > (as known) with 2.6.10. Latest 2.6.10 source in > debian adds the fix that > was integrated in 2.6.11, from >=20 > =A0 > http://lists.debian.org/debian-sparc/2005/02/msg00063.html It's mean you run 2.6.10 + "always hsync on SPARC" patch ? And if you try any fixes from Tony, you see mclk 100 xclk 100 in your dmesg= ,=20 bur screen is steel garbage? Regards Alex |
|
From: Luigi G. <lu...@de...> - 2005-03-22 20:06:31
|
Il giorno sab, 19-03-2005 alle 16:15 +0100, Alexander Kern ha scritto: > Copyed from oldest mail...=20 >=20 > > (as known) with 2.6.10. Latest 2.6.10 source in > > debian adds the fix that > > was integrated in 2.6.11, from > >=20 > > =20 > > http://lists.debian.org/debian-sparc/2005/02/msg00063.html >=20 > It's mean you run 2.6.10 + "always hsync on SPARC" patch ? Right. Same behaviour with 2.6.11, however. > And if you try any fixes from Tony, you see mclk 100 xclk 100 in your dme= sg,=20 > bur screen is steel garbage? Yes. dmesg reports the setting passed on cmdline and screen is still garbled. Setting xclk to 100 makes things worse. Regards, --=20 Luigi Gangitano -- <lu...@de...> -- <gan...@lu...> GPG: 1024D/924C0C26: 12F8 9C03 89D3 DB4A 9972 C24A F19B A618 924C 0C26 |
|
From: Alexander K. <ale...@gm...> - 2005-03-23 21:36:17
Attachments:
atyfb_xl_gr_try.diff
|
Am Dienstag, 22. M=C3=A4rz 2005 21:06 schrieb Luigi Gangitano: > Il giorno sab, 19-03-2005 alle 16:15 +0100, Alexander Kern ha scritto: > > Copyed from oldest mail... > > > > > (as known) with 2.6.10. Latest 2.6.10 source in > > > debian adds the fix that > > > was integrated in 2.6.11, from > > > > > > > > > http://lists.debian.org/debian-sparc/2005/02/msg00063.html > > > > It's mean you run 2.6.10 + "always hsync on SPARC" patch ? > > Right. Same behaviour with 2.6.11, however. > > > And if you try any fixes from Tony, you see mclk 100 xclk 100 in your > > dmesg, bur screen is steel garbage? > > Yes. dmesg reports the setting passed on cmdline and screen is still > garbled. Setting xclk to 100 makes things worse. > > Regards, Ok, try this patch... or in combination with setting mclk and xclk to 100 Regards Alex |
|
From: Luigi G. <lu...@de...> - 2005-03-24 16:07:09
Attachments:
2.6.10-patched-dmesg
2.6.10-patched-fbset
|
Il giorno mer, 23-03-2005 alle 22:35 +0100, Alexander Kern ha scritto: > > > And if you try any fixes from Tony, you see mclk 100 xclk 100 in your > > > dmesg, bur screen is steel garbage? > > > > Yes. dmesg reports the setting passed on cmdline and screen is still > > garbled. Setting xclk to 100 makes things worse. > > > > Regards, > Ok, try this patch... > > or in combination with setting mclk and xclk to 100 Great. This patch mostly solved the problem. Now I have all the columns right and the screen shows no corruption. I still get some minor corruption during screen redrawing (each time a line is added), small white dots vertically aligned. When redrawing is finished the screen is ok. Using X this corruption is more frequent and constantly visible. Setting mclk and xclk to 100 doesn't make any visible difference. Attached you can find the last dmesg and fbset -i output. Still the difference with the original 2.6.8 output is 'hsync high' missing. Don't know if this makes sense to you. Thank you very much. You help has been great! Regards, -- Luigi Gangitano -- <lu...@de...> -- <gan...@lu...> GPG: 1024D/924C0C26: 12F8 9C03 89D3 DB4A 9972 C24A F19B A618 924C 0C26 |
|
From: Jesse B. <jb...@vi...> - 2008-04-01 20:23:38
|
On Monday, March 31, 2008 12:24 pm Justin Madru wrote: > Well, I disabled gdm and tryed to trigger the blank screen. I did about ~16 > reboots and it blanked out on me only 2 times. I was using a script to > reboot and/or startx. One time I'm not exactly sure if X was started, so it > might have blanked out on a "startx". The other time I'm fairly sure X > wasn't started, so it blanked out on a terminal login. Ok, so that might indicate something in the fb layer is killing it... > Both of the blank outs were different than the ones with gdm started. > Pressing ctrl+alt+f# changed nothing on the screen; the screen seemed > almost completely off (no or little backlight). A few seconds after > pressing the power button the shutdown splash screen would show, but this > time it was _very_ faint. > > Usually, when gdm is enabled, pressing ctrl+alt+f# would "refresh" (or > mode/resolution change) the screen, but it would still be blank. Also the > backlight still seamed to be on and at full brightness (although, still > displaying black). > > Well, I don't know what to say, it's the strangest of problems. Yeah, seems pretty weird. Given that you see it w/o the fb stuff loaded as well and we still have a few open bugs against the intel X driver regarding VT switch & mode programming, I don't think this is a real kernel regression. It's more likely that some timing or memory layout changed subtly and is causing to to hit one of our existing bugs more frequently that you did before. Can you file a bug against the intel X driver at bugs.freedesktop.org so we can track it there? Unless we can find a way to reproduce it reliably it'll probably take a long time to fix, but we don't want to lose it either... Thanks, Jesse |
|
From: Krzysztof H. <krz...@po...> - 2008-06-10 20:15:12
Attachments:
nv.dmesg
|
On Tue, 10 Jun 2008 07:27:30 +0500 "Аширапов Д." <ash...@ma...> wrote: > Hello Krzysztof Helt, > > > > >Can you email me the .config file from the 2.6.25 kernel you use to trigger the bug? > > Config of the 2.6.25 kernel in attached file. > > Hi Denis, I have not good news. I have finally borrowed the card designed as GF4MX440-8X (Geforce MX 440 AGP 8X), but I could not reproduce the bug. I used the config file you sent me. I tried also on the Nvidia TNT card and S3 Savage4 card (Number9 SR9). The vesafb worked for both. The dmesg from my computer with Geforce MX 440 card is attached. The interesting part is: pci 0000:01:00.0: Boot video device pci 0000:02:02.0: Firmware left e100 interrupts enabled; disabling pci_hotplug: PCI Hot Plug PCI Core version: 0.5 vesafb: framebuffer at 0xf0000000, mapped to 0xe0a80000, using 3072k, total 65536k vesafb: mode is 1024x768x16, linelength=2048, pages=1 vesafb: protected mode interface info at c000:ef40 vesafb: pmi: set display start = c00cef76, set palette = c00cefe0 vesafb: pmi: ports = 3b4 3b5 3ba 3c0 3c1 3c4 3c5 3c6 3c7 3c8 3c9 3cc 3ce 3cf 3d0 3d1 3d2 3d3 3d4 3d5 3da vesafb: scrolling: redraw vesafb: Truecolor: size=0:5:6:5, shift=0:11:5:0 Console: switching to colour frame buffer device 128x48 fb0: VESA VGA frame buffer device As I am not able to reproduce the bug, please test if you can connect to the computer with black screen (e.g. from another one through ssh). I used the 791 constant. Can you dump the dmesg with disabled screen and to me? Regards, Krzysztof ---------------------------------------------------------------------- Tania telefonia internetowa! Sprawdz >>> http://link.interia.pl/f1e2e |
Thanks for helping keep SourceForge clean.
X