Re: 2.6.15-1-sparc64 issues on blade 100
Luis F. Ortiz [EMAIL PROTECTED] writes: So I took a peek at the reference clock chip (X7) and it is a 29.4 Mhz clock. The same with mine, I think, though it's rather indistinct. -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: 2.6.15-1-sparc64 issues on blade 100
On Feb 14, 2006, at 11:42 AM, Dave Love wrote: My XF86Config-4 does still have the old Option reference_clock 28.636 Mhz though. Presumably that should be irrelevant now, should it? Dave: I've been dragging that line around in my X config file for quite awhile. So I decided to run an experiment this morning and see what happened if I deleted it. Lo and behold, I got diagonal stripes moving up (or down) quickly, as if the VHOLD and HSYNC on an old TV got played with by a 4 year old nephew. Buried in the X log was the following line: (--) ATI(0): Reference clock 14.318 MHz. Now this number was familiar; I had just seen it on web page describing the options for the ATI driver for Xfree: http://www.xfree86.org/~dawes/4.3.0/ati5.html#26 But the number 28.636 still seemed funny, it was mentioned in the web page as a typical value, but when I took the cover off of my Blade 100 to check on the clock frequency that the kernel ATY FB driver needed, I did not recall seeing that clock frequency there. So I took a peek at the reference clock chip (X7) and it is a 29.4 Mhz clock. So I would say: 1) An 'Option reference_clock XXX Mhz' line is needed as the X driver sets the reference clock to a default value when a PC BIOS is not present. The default is wrong for my machine and is likely wrong for all Blade 100's. 2) At least some SPARC Blade 100's have a 29.4 Mhz reference clock. 3) The difference between 28.636 and 29.4 Mhz is small enough to be ignored for large divisors, but could present a problem for small divisors. 4) It could be that no Blade 100 uses a 28.636 Mhz reference clock and that someone tried the next typical value on the list and stopped experimenting since it worked and never took the lid off to see if the value reflected what the hardware was doing. Can any other owners of SPARC Blade 100's out there pop the lid off their machines and look at numbers printed on the two clock crystals near the RageXL chip? On my machine, the crystal is labeled X7. -- Luis PS: If you need a picture, I have one I can send you if you need it. -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: 2.6.15-1-sparc64 issues on blade 100
Dear Luis, On Mon, Feb 13, 2006 at 07:18:02PM -0500, Luis F. Ortiz wrote: I'm running OBP 4.5.9 (2002/02/07), which I think is the latest that can run on a Sparc Blade 100. I have just upgraded to OBP 4.17.1 2005/04/11 14:31. This solved the issue of 'flickering' and red dots in Xorg. However, Xorg is still running at 1400x1050 @ 60Hz, while with kernel 2.6.9 Xorg used to do 1400x1050 @ 85Hz. It appears that 1152x864 can be done at 85Hz, but 1280x960 and above are just 60 Hz. Is there anyone on this list who can confirm this? (Or anyone who has 1280x960 at a higher refresh rate than 60 Hz?) I also note some flickering when I move a window in Xorg; the corruption is gone if I stop moving. Finally, it appears that my current kernel (2.6.16-rc2-sparc64 from Jurij) is not very stable. If I play some music with quod libet and try to play/pause/next a few times, I see this in /var/log/kern.log: Feb 15 12:35:50 zonne kernel: Bad page state in process 'python' Feb 15 12:35:50 zonne kernel: page:f86a2b78 flags:0x0414 mapping: mapcount:0 count:0 Feb 15 12:35:50 zonne kernel: Trying to fix it up, but a reboot is needed Feb 15 12:35:50 zonne kernel: Backtrace: Feb 15 12:35:50 zonne kernel: Call Trace: Feb 15 12:35:50 zonne kernel: [00460e1c] unmap_vmas+0x338/0x5e8 Feb 15 12:35:50 zonne kernel: [004641f4] unmap_region+0x84/0x11c Feb 15 12:35:50 zonne kernel: [00464884] do_munmap+0x194/0x228 Feb 15 12:35:50 zonne kernel: [00464934] sys_munmap+0x1c/0x38 Feb 15 12:35:50 zonne kernel: [00407214] linux_sparc_syscall32+0x34/0x40 Feb 15 12:35:50 zonne kernel: [722ed1f4] 0x722ed1f4 Feb 15 12:35:51 zonne kernel: Bad page state in process 'python' Feb 15 12:35:51 zonne kernel: page:f86a2bb0 flags:0x0414 mapping: mapcount:0 count:0 Feb 15 12:35:51 zonne kernel: Trying to fix it up, but a reboot is needed I've noticed this also with 2.6.15. Can anyone confirm this, or is there perhaps something wrong with my hardware? Best regards, Admar -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: 2.6.15-1-sparc64 issues on blade 100
Luis F. Ortiz [EMAIL PROTECTED] writes: I'm running OBP 4.5.9 (2002/02/07), which I think is the latest that can run on a Sparc Blade 100. Mine has cpu : TI UltraSparc IIe (Hummingbird) fpu : UltraSparc IIe integrated FPU promlib : Version 3 Revision 15 prom: 4.15.7 It's running OK on 2.6.15-4 (specifically the graphics) except that the RTC has problems (as with previous kernels). I don't know whether the RTC has a hardware problem, but NTP keeps dragging it back by about a second. My XF86Config-4 does still have the old Option reference_clock 28.636 Mhz though. Presumably that should be irrelevant now, should it? -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: 2.6.15-1-sparc64 issues on blade 100
On Feb 12, 2006, at 1:40 PM, Admar Schoonen wrote: ... Louis: which open boot firmware are you using? According to /proc/openprom/openprom/version, I'm still at OBP 4.0.45 2001/02/08 14:33, could this be an issue for the framebuffer code? If not, then is it possible that my Ati chip is a slightly different revision than yours? Admar: I'm running OBP 4.5.9 (2002/02/07), which I think is the latest that can run on a Sparc Blade 100. Let's take this off the list and start swapping information until we get down to the bottom of this and then update folks when we are done. To start with, send me results of running prtconf -p -v to dump the Sparc OpenPROM tree and we can first see if there is a difference as far as the PROM's view of our hardware. Also, send me a copy of your XF86Config file and XFree86.#.log or Xorg.#.log so I can compare it with mine. -- Luis -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: 2.6.15-1-sparc64 issues on blade 100
On Fri, Feb 10, 2006 at 08:46:40PM -0800, Jurij Smakov wrote: On Wed, 8 Feb 2006, Luis F. Ortiz wrote: With regard to the video problems, you are welcome to try my fix to the problem. There were two problems I found, a missing flag (M64F_SDRAM_MAGIC_PLL) and a bad clock rate (230 instead of 235). Try applying some variation of the following patch. This fix went to 2.6.16-rc1, but was partially overwritten by a subsequent patch. Hopefully the full fix will reappear shortly, and then the debian folks will pick it up. If it does not fix your problem let me know; it means there is likely something wrong with my setup as well, and I just don't know it. If it does help, let me know so I can try harder to get it in for 2.6.16 final. Right, I've just checked and the code in 2.6.16-rc2 has the correct flags, but frequency is still set to 230 instead of correct 235 (*sigh*). I'll get a patch into svn. Updated kernels should be available from my site tomorrow. I just tried http://www.wooyd.org/debian/kernels/linux-image-2.6.16-rc2-sparc64_2.6.15+2.6.16-rc2-0experimental.1_sparc.deb (time stamp is 11 Feb 2006, 09:17), and there is still some flickering in the console when text is scrolling by, and there are still red dots in X (and X still uses a 60 Hz refresh rate while it should use 85). I'm not sure if Louis' fix is in this kernel, but if it is, then apparently, there is still something wrong. Louis: which open boot firmware are you using? According to /proc/openprom/openprom/version, I'm still at OBP 4.0.45 2001/02/08 14:33, could this be an issue for the framebuffer code? If not, then is it possible that my Ati chip is a slightly different revision than yours? I haven't tested this kernel long enough to see if it is as unstable as my custom 2.6.15. I will now try to build a custom 2.6.16-rc2 (I want to try some bluetooth stuff, but apparently, 2.6.16-rc2-sparc64 has bluetooth disabled), and I want to make sure Louis' fix is in there. Best regards, Admar -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: 2.6.15-1-sparc64 issues on blade 100
On Sun, 12 Feb 2006, Admar Schoonen wrote:
I just tried
http://www.wooyd.org/debian/kernels/linux-image-2.6.16-rc2-sparc64_2.6.15+2.6.16-rc2-0experimental.1_sparc.deb
(time stamp is 11 Feb 2006, 09:17), and there is still some flickering in the
console when text is scrolling by, and there are still red dots in X (and X
still uses a 60 Hz refresh rate while it should use 85).
I'm not sure if Louis' fix is in this kernel, but if it is, then apparently,
there is still something wrong. Louis: which open boot firmware are you using?
According to /proc/openprom/openprom/version, I'm still at OBP 4.0.45 2001/02/08
14:33, could this be an issue for the framebuffer code? If not, then is it
possible that my Ati chip is a slightly different revision than yours?
Yes, Louis' fix should be in this kernel. The actual patch (against
2.6.16-rc2) I've pushed into svn:
--- a/drivers/video/aty/atyfb_base.c2006-02-03 05:23:59.0 -0800
+++ b/drivers/video/aty/atyfb_base.c2006-02-09 21:25:53.163445232 -0800
@@ -415,7 +415,7 @@
{ PCI_CHIP_MACH64GN, 3D RAGE XC (Mach64 GN, AGP 2x), 230, 83, 63,
135, ATI_CHIP_264XL },
{ PCI_CHIP_MACH64GO, 3D RAGE XL (Mach64 GO, PCI-66), 230, 83, 63,
135, ATI_CHIP_264XL },
{ PCI_CHIP_MACH64GL, 3D RAGE XC (Mach64 GL, PCI-66), 230, 83, 63,
135, ATI_CHIP_264XL },
- { PCI_CHIP_MACH64GR, 3D RAGE XL (Mach64 GR, PCI-33), 230, 83, 63,
135, ATI_CHIP_264XL | M64F_SDRAM_MAGIC_PLL },
+ { PCI_CHIP_MACH64GR, 3D RAGE XL (Mach64 GR, PCI-33), 235, 83, 63,
135, ATI_CHIP_264XL | M64F_SDRAM_MAGIC_PLL },
{ PCI_CHIP_MACH64GS, 3D RAGE XC (Mach64 GS, PCI-33), 230, 83, 63,
135, ATI_CHIP_264XL },
{ PCI_CHIP_MACH64LM, 3D RAGE Mobility P/M (Mach64 LM, AGP 2x), 230,
83, 125, 135, ATI_CHIP_MOBILITY },
I've just checked that it is applied to the actual build tree, so I'm
pretty sure it made it in.
I will now try to build a custom 2.6.16-rc2 (I want to try some bluetooth stuff,
but apparently, 2.6.16-rc2-sparc64 has bluetooth disabled), and I want to make
sure Louis' fix is in there.
Please let us know how it goes. By the way, if you want something enabled
in official kernels, and it's not experimental, just let me know.
Best regards,
Jurij Smakov[EMAIL PROTECTED]
Key: http://www.wooyd.org/pgpkey/ KeyID: C99E03CC
--
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: 2.6.15-1-sparc64 issues on blade 100
On Wed, 8 Feb 2006, Luis F. Ortiz wrote: With regard to the video problems, you are welcome to try my fix to the problem. There were two problems I found, a missing flag (M64F_SDRAM_MAGIC_PLL) and a bad clock rate (230 instead of 235). Try applying some variation of the following patch. This fix went to 2.6.16-rc1, but was partially overwritten by a subsequent patch. Hopefully the full fix will reappear shortly, and then the debian folks will pick it up. If it does not fix your problem let me know; it means there is likely something wrong with my setup as well, and I just don't know it. If it does help, let me know so I can try harder to get it in for 2.6.16 final. -- Luis, who likes his SB100 Right, I've just checked and the code in 2.6.16-rc2 has the correct flags, but frequency is still set to 230 instead of correct 235 (*sigh*). I'll get a patch into svn. Updated kernels should be available from my site tomorrow. Best regards, Jurij Smakov[EMAIL PROTECTED] Key: http://www.wooyd.org/pgpkey/ KeyID: C99E03CC -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: 2.6.15-1-sparc64 issues on blade 100
Dear Luis Ortiz and Jurij Smakov, On Wed, Feb 08, 2006 at 08:02:54AM -0500, Luis F. Ortiz wrote: With regard to the video problems, you are welcome to try my fix to the problem. Thanks Luis! I will try your patch next weekend. In mean time, Jurij posted new kernel images at http://www.wooyd.org/debian/kernels/. Is this fix already in there? And is bluetooth enabled in those kernels? I have had some troubles compiling kernels (both 2.6.9 and 2.6.15) recently, on my custom 2.6.9 kernel. I haven't been able to find the exact cause, as sometimes, it completes the build, but at other times, either gcc or as fails, and always seems to fail at some random point in the build process. I suspect it could be a bug that only occurs if the load is high, since all other applications work fine, or perhaps a hardware error. Furthermore, I had lots of stability issues with 2.6.15 on this machine (sun blade 100). I would like to know if 2.6.15 is stable on other people's blade 100, and if it is stable, I would like to try their kernel image (to find out if my stability problems are hardware related or not). Best regards, Admar -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: 2.6.15-1-sparc64 issues on blade 100
On Feb 2, 2006, at 6:37 PM, Admar Schoonen wrote:
Dear Debian people,
I recently tried linux-image-2.6.15-1-sparc64 with an up to date
unstable on my
blade 100. I noticed a few issues:
1. Framebuffer is still a bit distorted. This is (or at least was)
a known
issue for recent kernels (bug id 317756). However, this bug is
closed, but
the problem still exists (at least on my blade 100). The
symptoms are that
some 'snow' or flickering occurs on the console when text is
scrolling and
Xorg will only start in 'low' refresh rates. The refresh rate
for 1400x1050
is 60 Hz, while for 2.6.9 kernels, I can run 1400x1050 @ 85 Hz.
Only at
1152x864 and lower, I can get 85 Hz refresh rates. Furthermore,
in all those
resolutions, some red dots appear, most notably when moving
windows.
A work around is to specify 'video=atyfb:off vga=normal', but
then the
console is slow, has no virtual consoles and my second mach64
card will not
be initialized (leaving me with just single head Xorg)
Am I the only one who still experiences this bug (ie:
flickering on console
and/or red dots in Xorg)?
Admar:
With regard to the video problems, you are welcome to try my fix to
the problem.
There were two problems I found, a missing flag
(M64F_SDRAM_MAGIC_PLL) and a bad clock rate
(230 instead of 235). Try applying some variation of the following
patch. This fix went to
2.6.16-rc1, but was partially overwritten by a subsequent patch.
Hopefully the full fix will
reappear shortly, and then the debian folks will pick it up.
If it does not fix your problem let me know; it means there is
likely something
wrong with my setup as well, and I just don't know it. If it does
help, let me know
so I can try harder to get it in for 2.6.16 final.
-- Luis, who likes his SB100
diff --git a/drivers/video/aty/atyfb_base.c b/drivers/video/aty/atyfb_base.c
index 485be38..3cd8d08 100644
--- a/drivers/video/aty/atyfb_base.c
+++ b/drivers/video/aty/atyfb_base.c
@@ -415,7 +415,7 @@ static struct {
{ PCI_CHIP_MACH64GN, 3D RAGE XC (Mach64 GN, AGP 2x), 230, 83, 63,
135, ATI_CHIP_264XL },
{ PCI_CHIP_MACH64GO, 3D RAGE XL (Mach64 GO, PCI-66), 230, 83, 63,
135, ATI_CHIP_264XL },
{ PCI_CHIP_MACH64GL, 3D RAGE XC (Mach64 GL, PCI-66), 230, 83, 63,
135, ATI_CHIP_264XL },
- { PCI_CHIP_MACH64GR, 3D RAGE XL (Mach64 GR, PCI-33), 230, 83, 63,
135, ATI_CHIP_264XL | M64F_SDRAM_MAGIC_PLL },
+ { PCI_CHIP_MACH64GR, 3D RAGE XL (Mach64 GR, PCI-33), 235, 83, 63,
135, ATI_CHIP_264XL | M64F_SDRAM_MAGIC_PLL },
{ PCI_CHIP_MACH64GS, 3D RAGE XC (Mach64 GS, PCI-33), 230, 83, 63,
135, ATI_CHIP_264XL },
{ PCI_CHIP_MACH64LM, 3D RAGE Mobility P/M (Mach64 LM, AGP 2x), 230,
83, 125, 135, ATI_CHIP_MOBILITY },
2.6.15-1-sparc64 issues on blade 100
Dear Debian people, I recently tried linux-image-2.6.15-1-sparc64 with an up to date unstable on my blade 100. I noticed a few issues: 1. Framebuffer is still a bit distorted. This is (or at least was) a known issue for recent kernels (bug id 317756). However, this bug is closed, but the problem still exists (at least on my blade 100). The symptoms are that some 'snow' or flickering occurs on the console when text is scrolling and Xorg will only start in 'low' refresh rates. The refresh rate for 1400x1050 is 60 Hz, while for 2.6.9 kernels, I can run 1400x1050 @ 85 Hz. Only at 1152x864 and lower, I can get 85 Hz refresh rates. Furthermore, in all those resolutions, some red dots appear, most notably when moving windows. A work around is to specify 'video=atyfb:off vga=normal', but then the console is slow, has no virtual consoles and my second mach64 card will not be initialized (leaving me with just single head Xorg) Am I the only one who still experiences this bug (ie: flickering on console and/or red dots in Xorg)? 2. Bluetooth is unavailable. Is that on purpose? If not, should I file a wishlist bug against linux-image-2.6.15-1-sparc64 to include bluetooth? 3. 2.6.15-1-sparc64 is very unstable. I get lots and lots of messages like this in /var/log/kern.log: Feb 2 23:50:32 zonne kernel: Bad page state at free_hot_cold_page (in process 'rhythmbox', page f86b4f10) Feb 2 23:50:32 zonne kernel: flags:0x0414 mapping: mapcount:0 count:0 Feb 2 23:50:38 zonne kernel: Backtrace: Feb 2 23:50:38 zonne kernel: Call Trace: Feb 2 23:50:38 zonne kernel: [004681c4] unmap_vmas+0x338/0x5e8 Feb 2 23:50:38 zonne kernel: [0046b160] exit_mmap+0x78/0x13c Feb 2 23:50:38 zonne kernel: [0043c284] mmput+0x24/0xa4 Feb 2 23:50:38 zonne kernel: [0043faec] do_exit+0x1c4/0xb74 Feb 2 23:50:38 zonne kernel: [00440520] do_group_exit+0x84/0x90 Feb 2 23:50:38 zonne kernel: [00449d70] get_signal_to_deliver+0x3c8/0x3e4 Feb 2 23:50:38 zonne kernel: [00425dfc] do_signal32+0x1c/0x115c Feb 2 23:50:38 zonne kernel: [0041625c] do_signal+0x2c/0x528 Feb 2 23:50:38 zonne kernel: [00405888] __handle_signal+0x14/0x4c Feb 2 23:50:38 zonne kernel: [71637654] 0x71637654 Feb 2 23:50:38 zonne kernel: Trying to fix it up, but a reboot is needed It is most notably for applications like rhythmbox or quod libet. Is there anyone else experiencing this behaviour? Or is it most probably some hardware issue in my machine? For now, I'll switch back to my custom built 2.6.9, as especially issue 3 prevents me from using 2.6.15. Best regards, Admar -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
