Sbus graphic cards, resolutions, monitors
Trying to run an IBM TFT 15 monitor with [EMAIL PROTECTED] with my Ultra-2 and SBus graphic cards GX or TXplus, I learned the following: GX, GXplus with Bt458 DAC only support the following resolutions: 1152 x 900 @ 66 Hz 1152 x 900 @ 76 Hz 1024 x 800 (!) @ 84 Hz (!) The last value is something, most TFTs cannot support, be it with the No. of lines (800) or more often, the high refresh frequency of 84 Hz. :-( Most native resolution of TFT monitors is 1024 x 768 @ 60 Hz. With the TGX+ SBus card (Bt 467 DAC), the choice of resolutions and/or refresh rates rises: 1152 x 900 @ 66 Hz 1152 x 900 @ 76 Hz 1024 x 800 (!) @ 84 Hz (!) 1024 x 768 @ 60 Hz (here it is!) 1024 x 768 @ 70 Hz 1024 x 768 @ 76 Hz (works well with most IBM TFTs) 1280 x 1024 @ 67 Hz 1280 x 1024 @ 76 Hz (should work with 19 TFTs) 1600 x 1280 @ 76 Hz 1920 x 1080 @ 72 Hz So, if you have a TGX+ card available, you should be able to find the matching resolution and refresh rate for the most common monitors, be it CRTs or TFTs. The setting is easily done inside the Open Boot PROM (OBP): setenv output-device screen:r1152x900x76 for example. My debian 2.6.18-6-sparc64-smp runs the correct settings of OBP, but screen resolution shows always the right chosen resolution with a very wrong refresh rate of 30915 Hz (ooops!). BTW: this link from Brian brought me on the right track: More info can be found here: http://mediacast.sun.com/users/Barton808/media/Sbus_cgsix_graphics_cards800-5114-10.pdf (read only pages 1-10, 1-11 for sense pin, 9-7 for GX cards, 9-22 for TGX+ cards) :-) I hope this will help others with their monitor settings. Regards, Norbert -- IBG Ingenieurbüro Gerhards Dipl.-Ing. Norbert Gerhards Laurentiusstr. 16 - 20 52072 Aachen Tel. 0241-705 08-14 Fax 0241-705 08-99 mobil 0172-240 66 36 email [EMAIL PROTECTED] URL www.ib-gerhards.de -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: Sbus graphic cards, resolutions, monitors
Norbert Gerhards wrote: The setting is easily done inside the Open Boot PROM (OBP): setenv output-device screen:r1152x900x76 for example. It gets a bit more complex if you're having to do that sort of thing for two screens (Xinerama or whatever), I ended up having to use two separate OP settings hence /proc/openprom/options$ cat output-device screen:r1280x1024x76 /proc/openprom/options$ cat boot-command /SUNW,[EMAIL PROTECTED],0:r1280x1024x76 select-dev boot Unfortunately this only works properly on a cold boot. I've carefully stuck to NEC Multisyncs here since experience shows them to be good with Sun-style sync. -- Mark Morgan Lloyd markMLl .AT. telemetry.co .DOT. uk [Opinions above are the author's, not those of his employers or colleagues] -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: Bug#501825: libjson-xs-perl_2.23-1(sparc/unstable): FTBFS on sparc, fails in tests
On Fri, Oct 10, 2008 at 09:00:21PM +0200, Martin Zobel-Helas wrote:
Package: libjson-xs-perl
Version: 2.23-1
Severity: serious
There was an error while trying to autobuild your package:
Automatic build of libjson-xs-perl_2.23-1 on schroeder by sbuild/sparc 99.99
Build started at 20081010-1421
t/19_incr...dubious
Test returned status 0 (wstat 10, 0xa)
DIED. FAILED test 697
Failed 1/697 tests, 99.86% okay
This is reproducible on sperger.d.o.
It's an alignment problem that only shows up with an optimization level
of at least -O2.
Program received signal SIGBUS, Bus error.
0xf7ec1134 in decode_json (string=0x192280, json=0x39f18,
offset_return=0xff85b96c) at XS.xs:1443
1443 SvGROW (string, SvCUR (string) + 1); // should basically be a NOP
(gdb) bt
#0 0xf7ec1134 in decode_json (string=0x192280, json=0x39f18,
offset_return=0xff85b96c) at XS.xs:1443
#1 0xf7ec2444 in XS_JSON__XS_incr_parse (my_perl=0x22008, cv=0x126d58) at
XS.xs:1828
#2 0xf7dfab48 in Perl_pp_entersub () from /usr/lib/libperl.so.5.10
#3 0xf7df8f9c in Perl_runops_standard () from /usr/lib/libperl.so.5.10
#4 0xf7df4298 in perl_run () from /usr/lib/libperl.so.5.10
#5 0x00010b88 in main ()
The instruction that causes the bus error is a double-word load (ldd):
0xf7ec1130 decode_json+132: ld [ %l1 ], %g1
0xf7ec1134 decode_json+136: ldd [ %g1 + 8 ], %g2
0xf7ec1138 decode_json+140: inc %g2
0xf7ec113c decode_json+144: cmp %g3, %g2
The preprocessor output for the above SvGROW() macro invocation is
(((XPV*) (string)-sv_any)-xpv_len (((XPV*) (string)-sv_any)-xpv_cur +
1) ? Perl_sv_grow(((PerlInterpreter
*)pthread_getspecific((*Perl_Gthr_key_ptr(((void *)0), string,((XPV*)
(string)-sv_any)-xpv_cur + 1) : ((string)-sv_u.svu_pv));
and the above assembly is the compiled form of the first comparison
at -O2. The compiler is using a double-word instruction to load both
xpv_cur and xpv_len in one go.
Now, this apparently requires that ((XPV*) (string)-sv_any)-xpv_cur
is aligned on a double-word (64-bit) boundary, which fails here:
$1 = {sv_any = 0x25714, sv_refcnt = 1, sv_flags = 536888326, sv_u = {svu_iv =
1662248, svu_uv = 1662248,
svu_rv = 0x195d28, svu_pv = 0x195d28 [42], svu_array = 0x195d28, svu_hash
= 0x195d28,
svu_gp = 0x195d28}}
(gdb) print ((XPV*) (string)-sv_any)-xpv_cur
$2 = (STRLEN *) 0x2571c
(gdb) print ((XPV*) (string)-sv_any)-xpv_len
$3 = (STRLEN *) 0x25720
(Delving somewhat further, I see the 64-bit alignment of string-sv_any
is lost in libperl's sv_chop(), invoked from incr_skip() at XS.xs:1855
or so.)
This suggests to me that gcc is being too aggressive on optimizing here.
I don't see how it can consider the double word instruction safe.
Cc'ing the sparc porters list in the hope that somebody gets interested
in this.
I suppose a workaround is to use -O1 on sparc.
--
Niko Tyni [EMAIL PROTECTED]
--
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: Bug#501825: libjson-xs-perl_2.23-1(sparc/unstable): FTBFS on sparc, fails in tests
On Wed, Oct 15, 2008 at 23:39:52 +0300, Niko Tyni wrote: This is reproducible on sperger.d.o. It's an alignment problem that only shows up with an optimization level of at least -O2. Program received signal SIGBUS, Bus error. 0xf7ec1134 in decode_json (string=0x192280, json=0x39f18, offset_return=0xff85b96c) at XS.xs:1443 1443 SvGROW (string, SvCUR (string) + 1); // should basically be a NOP (gdb) bt #0 0xf7ec1134 in decode_json (string=0x192280, json=0x39f18, offset_return=0xff85b96c) at XS.xs:1443 #1 0xf7ec2444 in XS_JSON__XS_incr_parse (my_perl=0x22008, cv=0x126d58) at XS.xs:1828 #2 0xf7dfab48 in Perl_pp_entersub () from /usr/lib/libperl.so.5.10 #3 0xf7df8f9c in Perl_runops_standard () from /usr/lib/libperl.so.5.10 #4 0xf7df4298 in perl_run () from /usr/lib/libperl.so.5.10 #5 0x00010b88 in main () The instruction that causes the bus error is a double-word load (ldd): 0xf7ec1130 decode_json+132: ld [ %l1 ], %g1 0xf7ec1134 decode_json+136: ldd [ %g1 + 8 ], %g2 0xf7ec1138 decode_json+140: inc %g2 0xf7ec113c decode_json+144: cmp %g3, %g2 The preprocessor output for the above SvGROW() macro invocation is (((XPV*) (string)-sv_any)-xpv_len (((XPV*) (string)-sv_any)-xpv_cur + 1) ? Perl_sv_grow(((PerlInterpreter *)pthread_getspecific((*Perl_Gthr_key_ptr(((void *)0), string,((XPV*) (string)-sv_any)-xpv_cur + 1) : ((string)-sv_u.svu_pv)); and the above assembly is the compiled form of the first comparison at -O2. The compiler is using a double-word instruction to load both xpv_cur and xpv_len in one go. Now, this apparently requires that ((XPV*) (string)-sv_any)-xpv_cur is aligned on a double-word (64-bit) boundary, which fails here: [...] This suggests to me that gcc is being too aggressive on optimizing here. I don't see how it can consider the double word instruction safe. __alignof__(XPV) is 8, so gcc is allowed to assume that any XPV is 64-bit aligned, as far as I can tell. xpv_cur's offset is 8, so it should also be 64-bit aligned. Cheers, Julien -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
