Re: [sparc64] mkfs.btrfs bus error / align issue?

[Patrick Baggett]

> Oh, and you will somehow need to guard this with #if BITS_PER_LONG == 64 ...
> #else ... #endif respectively since you need to use different versions
> (64 vs. 32) of get_unaligned_* depending on the size of unative_t.

Maybe a get_unaligned_unative() would be better so that preprocessor
fun is kept to a minimum. :)

--Patrick

Re: [sparc64] mkfs.btrfs bus error / align issue?

[Patrick Baggett]

On Wed, Jul 27, 2016 at 3:40 PM, John Paul Adrian Glaubitz
 wrote:
> On 07/27/2016 03:59 PM, Anatoly Pugachev wrote:
>> Program received signal SIGBUS, Bus error.
>> 0x0015e160 in write_raid56_with_parity (info=0x2b17b0,
>> eb=0x2c7fe0, multi=0x2c2870, stripe_len=65536, raid_map=0x2c2570) at
>> volumes.c:2156
>> 2156*(unsigned long *)(p_eb->data + i) ^=
>
> Well, that pretty much looks some creative pointer arithmetics that will 
> provoke
> unaligned access. Just check what the declaration of p_eb->data is. If it's
> not "unsigned long", then you know why the code breaks here.
>

Yeah, so basically, the best solution (assuming you can't change the
alignment of `data` somehow) would look something like:

Compare lower 'n' bits of `data` pointers (n=2 for ILP32, n=3 for
LP64), something like (data1 & sizeof(long)-1) == (data2 &
sizeof(long)-1). If they are equal, fast loop possible. Not equal ->
slow loop (all byte-by-byte copy).

fast loop path:
do byte-by-byte XOR until lower n bits of (data+i) are zero.

do word-by-word XOR until < 1 word

do byte-by-bye XOR until last bytes done.

This sort of processing is pretty standard for "chunking". If this was
done with some cool SIMD instruction set, it would have similar sort
of approach, I'd imagine.

Re: Please upgrade your machines to sparc64

[Patrick Baggett]

On Thu, Jun 23, 2016 at 1:42 PM, John Paul Adrian Glaubitz <
glaub...@physik.fu-berlin.de> wrote:

> On 06/23/2016 05:06 PM, David Miller wrote:
> > I think what irks people the most about what happened, is that the
> > choosen a path is not the most optimal situation for the target
> > platform.
>
> Why should it be any different for sparc64 than for ppc64el, amd64,
> arm64, mips64el and so on? Is SPARC so extremely inefficient with
> 64-bit pointers? I don't think so.
>
> > The most desirable would have been to build the bulk of userland
> > binaries as 32-bit with v8+ extensions (perhaps even with -mcpu=xxx
> > for some v9 cpu), and then for the specific packages that need it,
> > build 64-bit.
>
> I don't think it makes sense to compile things like dateutils with
> 32-bit pointers for performance reasons. Also, I would assume that
> modern compilers are able to optimize the code well enough that the
> difference between 32-bit and 64-bit pointers isn't too big that
> it justifies the effort. Some compilers like Intel's C/C++ compiler
> are actually already automatically generating 32-bit code when possible,
> the feature is called auto-ilp32 [1]. gcc could possibly adopt a similar
> feature in the future.
>
>
Just to adopt a devil's advocate approach here: I could also say that it
doesn't make sense to compile dateutils for 64-bit since extended address
space is no use. I think the point is that there are advantages both ways:
having a single set of 64-bit packages is a lot easier to maintain, but
David Miller is correct in saying that a large majority of packages do not
benefit from using 64-bit memory model, but all of them pay a "tax",
relative to the 32-bit packages in code size, cache usage, etc. Obviously,
for stuff like `ls`, I could care less if took 250usec longer due to
"64-bitness", but if somehow that caused my builds to take 5 extra minutes,
I might get annoyed.

It's interesting to see, because from a maintainer standpoint, what you are
arguing makes a lot of sense, and from David's kernel developer standpoint,
he probably dislikes what he perceives as inefficient usage of the hardware
that slows down his workflow.

I'm also pretty sure that all of the incredible work you two have been
doing to iron out SIGBUS, fix drivers, and many other unspeakable
violations of C standards will translate to better code if there ever is
more demand for 32-bit SPARC packages. Like you said, it shouldn't be a
problem to build / upload (32-bit) sparc packages, and then install them if
desired, right?

Honestly, I'm just happy to have a working kernel/userland/installer!
That's a great base to launch any further operations, so thanks to both of
you.

Re: Debian Sparc 7.10.0 Install Problems

[Patrick Baggett]

Hey Chris!

Great to hear from a long-time sparc user.

On Wed, Jun 8, 2016 at 11:56 AM, Chris  wrote:
>>
>> Try our latest sparc64 build. It still has some rough edges, but you should
>> be able to get the system installed. Has a much more recent kernel and 
>> userland:
>
>
> Adrian,
>
> Thanks for the reply. I would like to try later builds and get more
> involved with the dev process, but right now, I need to understand
> why 7.10.0 isn't working.


Just playing the devil's advocate: suppose that the regression has
been fixed in the latest sparc64 set. Do you really _need_ to
understand what combination of problems lead to a regression in 7.10.0
if it is fixed now?

Adrian and others have fixed quite an impressive list of packages and
bugs, including some compiler and kernel bugs, if I recall. It seems
like it would be more relevant if this was still a problem in the
newest images, not in a relatively dormant one.

>
> I want to start with the last stable
> release for Sparc, to establish a baseline.


I think Adrian's goal is to make sparc64 the new stable baseline, but
he's looking for people with hardware to test and report bugs so that
the community can work on fixing it.

--Patrick

Re: Bug#806208: src:gegl: FTBFS on sparc64, tools/introspect segfaults

[Patrick Baggett]

On Saturday, June 4, 2016, John Paul Adrian Glaubitz <
glaub...@physik.fu-berlin.de> wrote:

> On 06/03/2016 11:49 PM, John Paul Adrian Glaubitz wrote:
> > So, maybe we're lucky and just the above patch will be enough :).
> >
> > Will build gegl now to verify this.
>
> And, indeed, gegl now builds fine on sparc64 [1].
> Note the comments in the upstream bug tracker though [2] where it
> is suggested to use the following code instead:
>
>  dst[0] = src[0];
>  dst[1] = src[1];
>  dst[2] = src[2];
>  dst[3] = 255;
>
> I have not verified that yet, but it seems this should actually work.
>
> Yeah, the memcpy with a word will probably be wrong due to endian issues
when it is stored because dst[3] would be written in the first byte, but
they are assuming that dst[3] is the last byte, given that they do OR with
0xff << 24, i.e. filling dst[3] = 0xff.

Bonus points if you find a way to do this with VIS intrinsics! ;)



> Adrian
>
> > [1]
> https://buildd.debian.org/status/fetch.php?pkg=gegl&arch=sparc64&ver=0.3.6-4&stamp=1465032322
> > [2] https://bugzilla.gnome.org/show_bug.cgi?id=767219
>
> --
>  .''`.  John Paul Adrian Glaubitz
> : :' :  Debian Developer - glaub...@debian.org 
> `. `'   Freie Universitaet Berlin - glaub...@physik.fu-berlin.de
> 
>   `-GPG: 62FF 8A75 84E0 2956 9546  0006 7426 3B37 F5B5 F913
>
>

Re: Enable module aliases for vio on sparc/sparc64

[Patrick Baggett]

You guys are my heroes. Keep up the great work!

On Wednesday, April 13, 2016, John Paul Adrian Glaubitz <
glaub...@physik.fu-berlin.de> wrote:

> On 04/14/2016 01:01 AM, David Miller wrote:
> > Ok those are the block devices, where are the networking interfaces?
>
> Whoops, sorry:
>
> root@deb4g:/sys/devices/channel-devices# cat vdc*/mod*
> vio:Tvdc-portSunknown
> vio:Tvdc-portSunknown
> vio:Tvdc-portSunknown
> vio:Tvdc-portSunknown
> vio:Tvdc-portSunknown
> root@deb4g:/sys/devices/channel-devices#
>
> Testing a much simpler version now. Second.
>
> --
>  .''`.  John Paul Adrian Glaubitz
> : :' :  Debian Developer - glaub...@debian.org 
> `. `'   Freie Universitaet Berlin - glaub...@physik.fu-berlin.de
> 
>   `-GPG: 62FF 8A75 84E0 2956 9546  0006 7426 3B37 F5B5 F913
>
>

Re: Bug#813649: emoslib; FTBFS on sparc64, needs different -mcmodel option

[Patrick Baggett]

On Wed, Feb 3, 2016 at 4:55 PM, John Paul Adrian Glaubitz
 wrote:
> On 02/03/2016 11:48 PM, John Paul Adrian Glaubitz wrote:
>> cd /«PKGBUILDDIR»/obj-sparc64-linux-gnu/libemos-dp && /usr/bin/cc  
>> -DBUFR_TABLES_PATH=\"/usr/share/emos/bufrtables\" -DFOPEN64 -DINTEGER_IS_INT 
>> -DINTERPOL_TABLES_PATH=\"/usr/share/emos\" -DLITTLE_ENDIAN -DPOINTER_64 
>> -DREAL_8 -DREAL_BIGGER_THAN_INTEGER -D_FILE_OFFSET_BITS=64 
>> -D_LARGEFILE64_SOURCE -Dgfortran -Dlinux -I/«PKGBUILDDIR» 
>> -I/«PKGBUILDDIR»/obj-sparc64-linux-gnu -I/«PKGBUILDDIR»/interpolation 
>> -I/«PKGBUILDDIR»/bufrdc_wmo -I/usr/lib/include  -g -O2 
>> -fstack-protector-strong -Wformat -Werror=format-security -Wdate-time 
>> -D_FORTIFY_SOURCE=2  -pipe -O3 -DNDEBUG -fPIC   -fpic-o 
>> CMakeFiles/emos.dir/__/pbio/readany.c.o   -c /«PKGBUILDDIR»/pbio/readany.c

Somewhat off-topic: It's weird that -DLITTLE_ENDIAN is defined for
this build... that seems like it could cause problems.

Re: Bug#812928: udev: cdrom_id terminated by signal BUS

[Patrick Baggett]

On Wed, Jan 27, 2016 at 5:23 PM, Ben Hutchings  wrote:
> Control: tag -1 moreinfo
>
> On Wed, 2016-01-27 at 23:54 +0100, Marco d'Itri wrote:
>> Control: reassign -1 src:linux
>> Control: found -1 4.3.0-1
>> Control: retitle -1 getauxval(AT_RANDOM) broken on sparc64
>>
>> On Jan 27, Anatoly Pugachev  wrote:
>>
>> > Program terminated with signal SIGUSR1, User defined signal 1.
>> > #0  0x0101b9b8 in initialize_srand () at src/basic/random-
>> > util.c:107
>> > 107 x ^= *(unsigned*) auxv;
>> > (gdb) bt
>> Looks like getauxval(AT_RANDOM) returns garbage on sparc64:
>>
>> x = 0;
>> auxv = (void*) getauxval(AT_RANDOM);
>> if (auxv)
>> x ^= *(unsigned*) auxv;
>
> There is no documented alignment guarantee for the AT_RANDOM bytes so I
> think this caller is wrong to treat it as an array of unsigned int.

Also, you can verify that from a debugger without changing the code,
by printing the value of the pointer `auxv` and check if either of the
lower two bits are set.

> What happens if you change it to:
>
> if (auxv)
> memcpy(&x, auxv, sizeof(x));
>
> ?
>
> Ben.
>
> --
> Ben Hutchings
> 73.46% of all statistics are made up.

Re: Need help: xsltproc segfaulting on sparc64

[Patrick Baggett]

Hi Adrian,

I have the time and skills (C programming / debugging), but no longer have
sparc hardware. I've been reading the bug reports, and the stack trace that
is 5381 levels deep seems to be quite a problem. Is this the same problem
that sparc64 is having? What about the patch [1] that supposedly fixes the
issue? Or is your request to somehow modify the C code so that is supports
recursion more efficiently (tail recursion)?

Patrick

[1]
https://bugs.debian.org/cgi-bin/bugreport.cgi?filename=nonrecursive-string-subst.patch;bug=765567;msg=72;att=1

On Thu, Dec 31, 2015 at 6:25 AM, John Paul Adrian Glaubitz <
glaub...@physik.fu-berlin.de> wrote:

> Hi!
>
> We have a rather annoying issue with xsltproc on sparc64 which almost
> always segfaults when processing input files. As a result, packages
> like systemd fail to build since xsltproc is called at some point to
> generate the manpages [1]:
>
> /usr/bin/xsltproc -o man/bootup.7 --nonet --xinclude --stringparam
> man.output.quietly 1 --stringparam funcsynopsis.style ansi --stringparam
> man.authors.section.enabled 0 --stringparam
> man.copyright.section.enabled 0 --stringparam systemd.version 228 --path
> './man:../man' ../man/custom-man.xsl ../man/bootup.xml
> make[4]: *** [man/bootup.7] Segmentation fault
>
> A commenter in the upstream bug tracker suggested this might be
> an issue with older Linux kernels [2] and since all our production
> buildds still run Debian Wheezy (sparc) with a 3.2.0 kernel,
> I thought this might be correct and I therefore didn't want
> to jump too quickly to blame xsltproc before I have verified
> that.
>
> However, today I made a test build of systemd on a fully native
> sparc64 system with Linux 4.3.3 and an up-to-date Debian
> unstable on Anatoly's SPARC T5 server, with the same result [3]:
>
> /usr/bin/xsltproc -o man/bootup.7 --nonet --xinclude --stringparam
> man.output.quietly 1 --stringparam funcsynopsis.style ansi --stringparam
> man.authors.section.enabled 0 --stringparam
> man.copyright.section.enabled 0 --stringparam systemd.version 228 --path
> './man:../man' ../man/custom-man.xsl ../man/bootup.xml
> Makefile:21813: recipe for target 'man/bootup.7' failed
>
> I can _sometimes_ alleviate the problem by removing /dev/shm
> and recreating it with 777 permissions as suggested in [4], but that
> doesn't always work and it's not really a good solution in the long
> time.
>
> Since this problem affects many packages which use xsltproc
> for manpage processing, it would be quite important to have
> this issue resolved.
>
> Does anybody have the time and skills to look into this issue?
>
> Thanks,
> Adrian
>
> > [1]
>
> https://buildd.debian.org/status/fetch.php?pkg=systemd&arch=sparc64&ver=228-2%2Bb1&stamp=1451533316
> > [2] https://bugzilla.gnome.org/show_bug.cgi?id=736077#c9
> > [3]
>
> https://people.debian.org/~glaubitz/systemd_228-2_sparc64-20151231-1419.build
> > [4] https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=750593#76
>
> --
>  .''`.  John Paul Adrian Glaubitz
> : :' :  Debian Developer - glaub...@debian.org
> `. `'   Freie Universitaet Berlin - glaub...@physik.fu-berlin.de
>   `-GPG: 62FF 8A75 84E0 2956 9546  0006 7426 3B37 F5B5 F913
>
>

Re: Need help debugging silo

[Patrick Baggett]

Nice job everyone!

On Tue, Dec 29, 2015 at 6:18 AM, John Paul Adrian Glaubitz <
glaub...@physik.fu-berlin.de> wrote:

> On 12/29/2015 12:24 PM, Frans van Berckel wrote:
> >> The unsigned long probably becomes 64 bit on sparc64. I'll check
> >> whether Oracle has a patched version.
> >
> > The Oracle devtoolset sources (incl binutils) are available here ...
>
> Not necessary, thanks. The bug was in elftoaout which made bogus
> size assumptions in the a.out header.
>
> I'm already building a new set of images which should finally work,
> just waiting for my 500 MHz Sun Blade 100 to finish.
>
> Adrian
>
> --
>  .''`.  John Paul Adrian Glaubitz
> : :' :  Debian Developer - glaub...@debian.org
> `. `'   Freie Universitaet Berlin - glaub...@physik.fu-berlin.de
>   `-GPG: 62FF 8A75 84E0 2956 9546  0006 7426 3B37 F5B5 F913
>
>

Re: Bug#731806: debian-installer: FTBFS on sparc: genisoimage errors

[Patrick Baggett]

On Thu, Nov 12, 2015 at 4:35 PM, John Paul Adrian Glaubitz <
glaub...@physik.fu-berlin.de> wrote:

> On 11/12/2015 11:28 PM, Patrick Baggett wrote:
> > If the output is -1, the bug has been fixed. If the output is 0, then
> > the bug is still present. 0 indicates the two strings are equal. Clearly
> > they are not. :)
>
> Looks like it has been fixed. Anything non-zero means strcmp says the
> strings are not equal, so not just -1:
>
> Right, sorry: the return value should be a[0]-b[0], which is (1 - 0) = 1,
not -1. Anyways, yeah, bug fixed. :)



> (unstable-sparc64-sbuild)root@andi:/tmp# gcc -O0 test.c -o test64
> (unstable-sparc64-sbuild)root@andi:/tmp# ./test64
> 1
> (unstable-sparc64-sbuild)root@andi:/tmp# cat test.c
> /* test.c */
> #include 
> #include 
>
> int main() {
>   char a[2] = { 1, 0 };
>   char b[2] = { 0, 0 };
>   printf("%d\n", strcmp(a,b));
> }
> (unstable-sparc64-sbuild)root@andi:/tmp#
>
> This has been tested with gcc_5.2.1-23 and glibc_2.19-22 on sparc64.
>
> Cheers,
> Adrian
>
> --
>  .''`.  John Paul Adrian Glaubitz
> : :' :  Debian Developer - glaub...@debian.org
> `. `'   Freie Universitaet Berlin - glaub...@physik.fu-berlin.de
>   `-GPG: 62FF 8A75 84E0 2956 9546  0006 7426 3B37 F5B5 F913
>

Re: Bug#731806: debian-installer: FTBFS on sparc: genisoimage errors

[Patrick Baggett]

On Thu, Nov 12, 2015 at 4:20 PM, John Paul Adrian Glaubitz <
glaub...@physik.fu-berlin.de> wrote:

> > https://wiki.debian.org/PortsSparc
> >
> > Started a catagory of major bugs. Please place links and titles to
> > the bug report in this list so we can better track the status and
> > reference the problems quickly.
>
> The underlying upstream issue of this bug in glibc seems to have been
> fixed [1], so I assume we could actually close this bug. If someone
> has an idea how to quickly verify the fix, please let me know.
>
>
Hi Adrian,

I submitted the bug report. Reproducing (or testing it) is trivial and is
described in the report I made. Below is code that you can copy into a *.c
file, compile with gcc and run it.

---
/* test.c */
#include 
#include 

int main() {
char a[2] = { 1, 0 };
char b[2] = { 0, 0 };
printf("%d\n", strcmp(a,b));
}
---
compile as: gcc -O0 test.c

If the output is -1, the bug has been fixed. If the output is 0, then the
bug is still present. 0 indicates the two strings are equal. Clearly they
are not. :)

Patrick

> One of my major problems with helping debian and the sparc port has
> > been simply figuring out what is wrong. I have fixed a lot of
> > problems upstream with KDE and alignment issues, and even have the
> > nouveau driver working with some GeForces on sparc. It would be sad
> > to see my plucky little sparc machines no longer get updates.
>
> You might be happy to hear that we have started bringing sparc64
> back to life in debian-ports and we're making very good progress
> with almost 9000 packages being up-to-date.
>
> Currently, there are no installer images available though. Thus,
> you have to use debootstrap to install a base sparc64 system which
> you can boot later.
>
> Cheers,
> Adrian
>
> > [1] https://sourceware.org/bugzilla/show_bug.cgi?id=16885
>
> --
>  .''`.  John Paul Adrian Glaubitz
> : :' :  Debian Developer - glaub...@debian.org
> `. `'   Freie Universitaet Berlin - glaub...@physik.fu-berlin.de
>   `-GPG: 62FF 8A75 84E0 2956 9546  0006 7426 3B37 F5B5 F913
>

Re: Resurrecting Debian on SPARC

[Patrick Baggett]

On Tue, Sep 15, 2015 at 9:32 AM, John Paul Adrian Glaubitz <
glaub...@physik.fu-berlin.de> wrote:

> On 09/15/2015 04:10 PM, waz0wski wrote:
> > I would love to see Debian-on-SPARC continue on, even if not fully
> > supported, similar to how the FreeBSD project handles sparc64[1]
>
> Ok, the question is: Do we want sparc32 as well or just sparc64? As
> I mentioned already, sparc32 (32-bit userland and 64-bit kernel -
> where supported) most likely needs less porting and should be
> easier to be kept up-to-date than sparc64.
>

My two cents: if you have limited efforts, then 64-bit sparc only is the
most future proof. Ideally though, you would not use 64-bit binaries unless
it made sense, because 64-bit binaries on sparc are usually slower. There
is no magic "64-bit is faster" on sparc like there is on x86. 32-bit
binaries are not the same as supporting ancient SPARC CPUs which are 32-bit
only. All binaries should be built for SPARCv9 ISA, which is the ISA that
supports 64-bit processing. 32-bit sparc binaries using v9 ISA is more
similar to the new(ish) "x32" ISA for x86 CPUs, where pointers are mapped
<= 4GB, but registers are still 64-bits wide.


>
> However, both 32-bit and 64-bit SPARC packages can be built on
> 64-bit machines using different build chroots.
>
> > I have access to a couple of UltraSPARC T2 systems (T5220/T5440) which
> > could be made available for development and testing purposes -- ping me
> > off-list for more info.
>
> I will come back to that.
>
> Adrian
>
> --
>  .''`.  John Paul Adrian Glaubitz
> : :' :  Debian Developer - glaub...@debian.org
> `. `'   Freie Universitaet Berlin - glaub...@physik.fu-berlin.de
>   `-GPG: 62FF 8A75 84E0 2956 9546  0006 7426 3B37 F5B5 F913
>
>

Re: Debian drops support for sparc

[Patrick Baggett]

On Thu, Jul 30, 2015 at 11:48 AM, Sam Ravnborg  wrote:
>> But I think the focus should probably be on the sheer redness of the sparc
>> columns at:
>> https://release.debian.org/jessie/arch_qualify.html (current release)
>
> >From the link above:
> "
> sparc
>
> Upstream Support
>
> According to the gcc maintainer 32bit code generation as we use it is no 
> longer supported upstream and we should aim for a switch to 64bit userland 
> anytime soon.
> "
>
> Is it correct that 32bit gcc is no longer maintained?
> I have seen nothing on gcc mailaing list about this.
>

I've challenged this assertion, too. I don't see any evidence of it
being true. 32-bit userland makes sense for most RISC architectures
because the increased code/memory size for switching to 64-bit apps is
not justified in most cases. x86 is the weird case that 64-bit code
can run faster due to more registers, an efficient calling convention,
and %rip relative addressing. Even Solaris 10+ (which only supports
64-bit sparc kernels) has a 32-bit userland for this reason. I think
that, of all people, the gcc sparc maintainers, understand this.

I can only guess what "32bit code generation as we use it" means, but
I doubt that it means "32-bit code targeting sparcv9 ISA".


-- 
To UNSUBSCRIBE, email to debian-sparc-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Archive: 
https://lists.debian.org/CAEk2StkmEQw3vdBiSNDrrtyYMLphWD8tBi6k=ma8hgx_g9t...@mail.gmail.com

Re: Debian drops support for sparc

[Patrick Baggett]

On Thu, Jul 30, 2015 at 11:48 AM, Sam Ravnborg  wrote:

> > But I think the focus should probably be on the sheer redness of the
> sparc
> > columns at:
> > https://release.debian.org/jessie/arch_qualify.html (current release)
>
> >From the link above:
> "
> sparc
>
> Upstream Support
>
> According to the gcc maintainer 32bit code generation as we use it is no
> longer supported upstream and we should aim for a switch to 64bit userland
> anytime soon.
> "
>
> Is it correct that 32bit gcc is no longer maintained?
> I have seen nothing on gcc mailaing list about this.
>
> I've challenged this assertion, too. I don't see any evidence of it being
true. 32-bit userland makes sense for most RISC architectures because the
increased code/memory size for switching to 64-bit apps is not justified in
most cases. x86 is the weird case that 64-bit code can run faster due to
more registers, an efficient calling convention, and %rip relative
addressing. Even Solaris 10+ (which *only *supports 64-bit sparc *kernels*)
has a 32-bit userland for this reason. I think that, of all people, the gcc
sparc maintainers, understand this.

I can only guess what "32bit code generation as we use it" means, but I
doubt that it means "32-bit code targeting sparcv9 ISA".

Patrick

Re: Good news on Debian Sparc port stability

[Patrick Baggett]

I would ask David S. Miller about the sparc ASM stuff - he seems to be the
resident sparc genius and linux kernel maintainer.

On Fri, Jun 5, 2015 at 4:18 PM, James Y Knight  wrote:

>
> On Jun 4, 2015, at 11:07 AM, James Y Knight  wrote:
> GLibc
> =
> After that, everything seemed to be going fine, except that programs like
> GCC would randomly segfault and give parse errors. This has been reported
> before, e.g. http://thread.gmane.org/gmane.linux.ports.sparc/16835, from
> 2 years ago. Things were stable enough to use interactively, if you're
> willing to keep retrying a build until it works, but not stable enough to
> use for any autobuild system.
>
> After a getting a hint from Aurelien that disabling optimized memcpy
> routines in glibc (eglibc 2.19-1, on Wed, 04 Jun 2014 20:32:06 +0200) had
> improved, but did not fix, the problem, I started looking into that
>
> ...And found that recompiling glibc, disabling the sparcv9 optimizations
> (that is: eliminating debian/patches/sparc/local-sparcv9-target.diff),
> *appears* to have completely fixed the stability issue!
>
> To try to verify that, I ran a loop building and rebuilding 'clang' (with
> full "ninja" parallelism) overnight, and it's had zero crashes in all 14
> builds of clang that it got through. Prior to fixing glibc, at least one of
> the ~2300 build steps (gcc/as/ld) was sure to crash unreproducibly.
>
> It'd be great if someone wants to try to figure out exactly /which/ of the
> asm routines in the various sysdeps/**/sparc32/sparcv9 are broken, to
> narrow down the problem better, too. I highly suspect there's just
> something wrong in one or more of the hand-written asm files, but it's
> certainly possible there's some wider problem that the sparcv9
> optimizations of glibc (but nothing else I've seen so far), just happens to
> expose.
>
> So, bad news and good news:
>
> Bad News: the above solution of simply disabling sparcv9 breaks some
> things (other than gcc). It breaks something about atomics or semaphores,
> likely due to a mismatch of expectations between libc and other things (the
> sparc32 routines, when *NOT* compiled in a shared library, dynamically
> choose between the v8 and v9 ways of doing things, so it's entirely
> reasonable to assume that doing it the v8 way cannot work right).
>
> Good News:
>
> My next attempt at a fix, is to just disable the optimized string ops:
>  rm sysdeps/sparc/sparc32/sparcv9/*mem* sysdeps/sparc/sparc32/sparcv9/*st*
> That seems to still have fixed the random gcc crashes, AND doesn't break
> other things. :)
>
>
> Looking into what the deleted routines are doing that's "interesting":
>
> * memcpy and memset:
>
> They're using LDBLOCKF STBLOCKF "block copy" instructions, which are:
> 1) Not actually part of the Sparcv9 standard instruction set, but rather
> are processor-specific (Although, these processor-specific instructions
> have been implemented since the UltraSPARC I).
> "The LDBLOCKF instruction is intended to be a processor-specific
> instruction, which may or may not be implemented in future Oracle SPARC
> Architecture implementations. Therefore, it should only be used in
> platform-specific dynamically-linked libraries or in software created by a
> runtime code generator that is aware of the specific virtual processor
> implementation on which it is executing."
>
> 2) Marked deprecated.
> "The LDBLOCKF instructions are deprecated and should not be used in
> new software. A sequence of LDDF instructions should be used instead."
>
> 3) Don't follow the normal TSO memory model ordering that everything else
> does; they require explicit MEMBARs in the right places to ensure even
> *single-thread/cpu* memory ordering correctness.
> "Block operations do not generally conform to dependence order on the
> issuing virtual processor; that is, no read-after-write or write-after-read
> checking occurs between block loads and stores. Explicit MEMBARs are
> required to enforce dependence ordering between block operations that
> reference the same address."
>
> It certainly looks like the author of those routines *tried* to do the
> right thing w.r.t. inserting membar instructions in the right place, but I
> can easily imagine it's wrong somehow. And it is entirely plausible that
> the behavior would be hardware-generation specific, since it has, by
> design, weird hardware-specific memory semantics. I'm placing my bets on
> this one being the problem.
>
> * memchr, memcmp, strcmp, strcpy, etc.
>
> These are using a nonfaulting load instruction. The nonfaulting load
> doesn't actually mean the hardware doesn't fault on loading from an
> unmapped page. Actually, unmapped pages still cause a fault, but the fault
> is supposed to be handled by the OS. It's also possible to map pages as
> "for use by nonfaulting loads only" (linux doesn't appear to do this).
>
> That's a rare instruction -- not generated by GCC I think, so I could
> imagine there being a bug in the fault handler for it. I think th

Re: Debian Jessie regression under qemu-system-sparc64

[Patrick Baggett]

>
> >
> > It looks like the regression has been introduced sometime between
> > 4th-8th November:
> >
> > - Works, boots to the Debian installer
> > http://d-i.debian.org/daily-images/sparc/20141104-00:20/mini.iso
> >
> > - Doesn't work, crashes as above
> > http://d-i.debian.org/daily-images/sparc/20141108-00:22/mini.iso
> >
> > Does any know what has changed that could have caused this regression?
>
> Panic over.
>
> It seems that the latest build has increased the memory requirement
> above QEMU's 128MB built-in default. Increasing the RAM to 256MB seems
> to get things going again:
>
> $ ./qemu-system-sparc64 -m 256 -cdrom
> /home/build/src/qemu/image/sparc64/mini.iso -boot d -nographic
>
> I guess everyone has more RAM in their SPARC hardware these days?
>

One virtue of the SPARC machines is that they have really high max RAM
capacity relative to their time. I haven't owned a SPARC machine with less
than 1GB.

Patrick

Re: Ultra-5 freezing

[Patrick Baggett]

Hi Scar,

When you say you are experiencing hard freezes, can you give a time frame?
>From you email it sounds like this:

* Installed Wheezy (works 100% perfectly?)
* Some time passes
* Now, it hard freezes (at boot? after a minute? after an hour? one week?)

I don't have problems with my Sun Ultra 80 or SB 2500 on Linux. I also
don't keep them on for weeks at a time though -- although I used to without
issues.

Patrick



On Thu, Sep 11, 2014 at 1:45 PM, scar  wrote:

> hi i have an Ultra-5 which has been housed in a datacenter for several
> years.  It used to be running SunOS 5.9 and i didn't experience any
> problems with it.  As that OS became obsolete, I installed Wheezy on the
> box not too long ago but now am experiencing hard freezes with no info
> in the system log as to what is happening.  how can i troubleshoot?  is
> it a software/OS/kernel issue?  i did a barebones installation, not
> selecting any "roles" for the computer and have installed all software
> as needed (mainly openssh server), so it is a very slim installation.
> is it a recent hardware failure?  how can i test RAM and other hardware,
> for example?
>
> i have another sun server in the same datacenter and i was looking to
> link the two boxes between their serial ports; perhaps i can see more
> info on the console when the freezes happen.  problem is i am not too
> good at figuring out how to wire such a link.  The Ultra-5 has a DB9
> port and the other server has an RJ45 port, and i have an Avocent Sun
> DB9-RJ45 adapter made to be used with their Cyclades serial port server
> which is what i used to have the Ultra-5 connected to, but the Cyclades
> is gone now so i'm trying to link it to my other server.  i started a
> discussion about this in the Avocent forums[1]
>
>  thanks
>
>
> 1.
> http://community.emerson.com/networkpower/support/avocent/f/105/t/4124.aspx
>
>
>
> --
> To UNSUBSCRIBE, email to debian-sparc-requ...@lists.debian.org
> with a subject of "unsubscribe". Trouble? Contact
> listmas...@lists.debian.org
> Archive: https://lists.debian.org/lusqjk$qkn$1...@ger.gmane.org
>
>

Re: Wanted: sparc64 porterbox

[Patrick Baggett]

I would think it should be possible, but the whole sparc/sparc64 divide is
something I don't really quite understand. I'm not sure what a "sparc64
porterbox" would look like. Are you asking for an environment where all of
the userland is 64-bit binaries? If so, I don't think debian has a true
sparc64 porterbox yet -- mostly chroots from what I understand. But from a
technical standpoint, there are a number of reasons why pure 64-bit
environments aren't desired, and why there hasn't been much of a rush to
get them.

So all of that having been said, are you trying to create a 64-bit gcc
binary in "pure" 64-bit environment? Or just a gcc that can build 64-bit
sparc programs on sparc?

- Patrick




On Mon, Aug 11, 2014 at 12:32 PM, Camm Maguire 
wrote:

> Greetings!  I've tried in the past building sparc64 on smetana with gcc
> switches and environment variables and failed.  Is this possible?
> Instructions?
>
> Take care,
>
> Patrick Baggett  writes:
>
> > Any modern SPARC kernel will run 64-bit sparc code, and the multilib gcc
> will generate both 32-code and 64-bit code. I believe that is enough, but
> > I'm not 100% sure.
> >
> > Patrick
> >
> > On Mon, Aug 11, 2014 at 9:57 AM, Camm Maguire 
> wrote:
> >
> > Greetings!  Does anyone know of an available porterbox to fix an
> > gcc-4.9-introduced gcl FTBFS on sparc64?
> >
> > Take care,
> > --
> > Camm Maguire
> c...@maguirefamily.org
> >
> ==
> > "The earth is but one country, and mankind its citizens."  --
>  Baha'u'llah
> >
> > --
> > To UNSUBSCRIBE, email to debian-sparc-requ...@lists.debian.org
> > with a subject of "unsubscribe". Trouble? Contact
> listmas...@lists.debian.org
> > Archive: https://lists.debian.org/87fvh3vztz@maguirefamily.org
> >
>
> --
> Camm Maguirec...@maguirefamily.org
> ==
> "The earth is but one country, and mankind its citizens."  --  Baha'u'llah
>

Re: Wanted: sparc64 porterbox

[Patrick Baggett]

Any modern SPARC kernel will run 64-bit sparc code, and the multilib gcc
will generate both 32-code and 64-bit code. I believe that is enough, but
I'm not 100% sure.

Patrick


On Mon, Aug 11, 2014 at 9:57 AM, Camm Maguire 
wrote:

> Greetings!  Does anyone know of an available porterbox to fix an
> gcc-4.9-introduced gcl FTBFS on sparc64?
>
> Take care,
> --
> Camm Maguirec...@maguirefamily.org
> ==
> "The earth is but one country, and mankind its citizens."  --  Baha'u'llah
>
>
> --
> To UNSUBSCRIBE, email to debian-sparc-requ...@lists.debian.org
> with a subject of "unsubscribe". Trouble? Contact
> listmas...@lists.debian.org
> Archive: https://lists.debian.org/87fvh3vztz@maguirefamily.org
>
>

Re: Problem implementing USB on Ultra 5/10

[Patrick Baggett]

On Sun, Jul 20, 2014 at 1:41 PM, Fred  wrote:

> On 07/22/2014 12:18 PM, Aaro Koskinen wrote:
>
>> Hi,
>>
>> On Sun, Jul 20, 2014 at 05:50:44AM -0700, Fred wrote:
>>
>>> A recent post mentioned having USB on a U10.  I bought a StarTech PCIUSB7
>>> card because it is said to be Linux compatible.  With the PCI USB card
>>> installed the U5 flashes the keyboard leds twice and does nothing else.
>>> Stop-a doesn't do anything.  It has debian 7.5.0 installed from the
>>> netinstall.iso.  Do USB drivers have to be manually installed?
>>>
>> I have used DeLock PCI USB/FireWire card successfully on U5/U10 to access
>> USB and FireWire disks. It works with standard EHCI/UHCI/OHCI drivers.
>> To my surprise, even the ancient firmware recognized the FireWire but I
>> have never tried to access it except from Linux.
>>
>> A.
>>
>>
>>  Hi,
>
> The StarTech USB card works perfectly in an x86 PC.  I have an 8 port PCI
> serial card that works fine on Solaris 2.6.  With this card the U5 boots
> normally so probably the PCI bus is ok.  I will try to find a DeLock USB
> card.
>
> Hi Fred,

Like I mentioned before, I found a graphics card that did not work in a U10
or a Pentium III (x86) system, but did in a newer Intel system. It likely
is just that the card itself is too new. Good luck and let us know what
works!



> Thanks for the help.
> Best regards,
> Fred
>
>
>
>
> --
> To UNSUBSCRIBE, email to debian-sparc-requ...@lists.debian.org
> with a subject of "unsubscribe". Trouble? Contact
> listmas...@lists.debian.org
> Archive: https://lists.debian.org/53cc0d41.6090...@blakemfg.com
>
>

Re: Problem implementing USB on Ultra 5/10

[Patrick Baggett]

On Tue, Jul 22, 2014 at 9:55 AM, BERTRAND Joël 
wrote:

> Fred a écrit :
>
>  Hello,
>>
>> A recent post mentioned having USB on a U10.  I bought a StarTech
>> PCIUSB7 card because it is said to be Linux compatible.  With the PCI
>> USB card installed the U5 flashes the keyboard leds twice and does
>> nothing else.  Stop-a doesn't do anything.  It has debian 7.5.0
>> installed from the netinstall.iso.  Do USB drivers have to be manually
>> installed?
>>
>
> Hello,
>
> I've never used an USB keyboard on U5 workstation. On Blade2k, I
> have installed a USB2 adapter without any trouble.
>
> But :
> - keyboard has to be plugged on an openprom compatible USB card ;
> - OpenPROM has to support USB keybord (and I'm not sure that OpenPROM 3.xx
> supports this kind of keyboard...) ;
> - your adapter has to be compatible with your PCI bus (2.2 or 2.3 for
> Blade 2k, maybe only 2.1 or 2.2 for your U5) ;
> - you have to install a linux supported USB adapter.
>
> Your keyboard led flashes without any USB communication between U5
> and keyboard. It only indicates it is powered and ready even there is no
> possible communication.
>
>
Oh dear, I didn't mean use a USB keyboard on a Sun U10 -- I just used
simple things like flash drives. I would severely doubt that a U10 would
"just work" for the reasons mentioned above.


> Best regards,
>
> JKB
>
>
>
> --
> To UNSUBSCRIBE, email to debian-sparc-requ...@lists.debian.org
> with a subject of "unsubscribe". Trouble? Contact
> listmas...@lists.debian.org
> Archive: https://lists.debian.org/53ce7b49.3090...@systella.fr
>
>

Re: Problem implementing USB on Ultra 5/10

[Patrick Baggett]

So if I'm understanding you correctly, when you don't have the card plugged
in, your system boots normally, but when you do, it doesn't even make to
the boot screen? Maybe you should check whether the card is correctly
inserted into the slot. This sounds closer to a hardware error, not driver
error. Maybe you can try a different slot as well?

I tried once to put a GeForce 9400 (PCI) in a U10 and it didn't work -- it
also didn't work in a Pentium III. There seems to be some minimum PCI spec
/ power requirement in order to boot that card. The same card in a newer
Intel system worked fine, and conversely, an older GeForce 440MX PCI worked
in the U10 (under Linux, with full OGL!)

However, I would think that a USB card wouldn't have a very high set of
requirements...



On Sun, Jul 20, 2014 at 7:50 AM, Fred  wrote:

> Hello,
>
> A recent post mentioned having USB on a U10.  I bought a StarTech PCIUSB7
> card because it is said to be Linux compatible.  With the PCI USB card
> installed the U5 flashes the keyboard leds twice and does nothing else.
>  Stop-a doesn't do anything.  It has debian 7.5.0 installed from the
> netinstall.iso.  Do USB drivers have to be manually installed?
>
> Best regards,
> Fred
>
>
> --
> To UNSUBSCRIBE, email to debian-sparc-requ...@lists.debian.org
> with a subject of "unsubscribe". Trouble? Contact
> listmas...@lists.debian.org
> Archive: https://lists.debian.org/53cbbb24.9040...@blakemfg.com
>
>

Re: problem booting Debian on X1

[Patrick Baggett]

Even though I didn't solve it, I'm glad I could point you at least nearish
to the answer :-)
On Jul 21, 2014 7:31 PM, "Jeremy Kister" 
wrote:

> On 7/21/2014 8:10 PM, Jeremy Kister wrote:
>
>> On 7/21/2014 7:48 PM, Jeremy Kister wrote:
>>
>>> I would guess it's:
>>> /mnt/sbin # silo -r /mnt -S backup1 -f
>>>
>>
>  all yield "Fast Data Access MMU Miss"
>>
>
> wow, i got it.  ends up silo needed -u -- i found that by this post:
>
> https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=570264
>
> Thanks Patrick (and anyone else) for your input.  boxes are all happy now.
>
> debian-sparc maintainers: please stop coding bugs.  (just kidding)
>
> --
>
> Jeremy Kister
> http://jeremy.kister.net./
>
>
> --
> To UNSUBSCRIBE, email to debian-sparc-requ...@lists.debian.org
> with a subject of "unsubscribe". Trouble? Contact
> listmas...@lists.debian.org
> Archive: https://lists.debian.org/53cdb0fb.5080...@jeremykister.com
>
>

Re: problem booting Debian on X1

[Patrick Baggett]

Oh, I was just reading the manual for silo. What I wrote was not entirely
correct:

   The program /sbin/silo <http://swoolley.org/man.cgi/silo> is
used to install <http://swoolley.org/man.cgi/1/install> the  first
stage  loader  by
   copying  the  right  first  stage loader into the bootblock (unless the
   correct first stage is already installed and the -f option
<http://swoolley.org/man.cgi/n/option> is not  used
   to  force it), writes the block number
<http://swoolley.org/man.cgi/6/number> of the first block of the
second
   stage loader (usually /boot
<http://swoolley.org/man.cgi/7/boot>/second.b) into it and into the
second stage
   loader  it  records  all the block numbers of second.b and the name and
   location of the configuration file. The configuration  file
<http://swoolley.org/man.cgi/file>  itself  is
   parsed by the boot <http://swoolley.org/man.cgi/7/boot> loader
at <http://swoolley.org/man.cgi/1/at> boot
<http://swoolley.org/man.cgi/7/boot> time. See silo.conf
<http://swoolley.org/man.cgi/5/silo>(5) for
<http://swoolley.org/man.cgi/n/for> details.

   This  means that the /sbin/silo
<http://swoolley.org/man.cgi/silo> program must be run only if
<http://swoolley.org/man.cgi/if> you install
<http://swoolley.org/man.cgi/1/install>
   a new version <http://swoolley.org/man.cgi/version> of SILO
<http://swoolley.org/man.cgi/8/silo> or if
<http://swoolley.org/man.cgi/if> you move
<http://swoolley.org/man.cgi/move> the second  stage  loader  on  the
   disk.  Unlike the LILO bootloader on the Intel platform, you don't have
   to rerun it every time <http://swoolley.org/man.cgi/time> you
make <http://swoolley.org/man.cgi/1/make> a change into
/etc/silo.conf <http://swoolley.org/man.cgi/5/silo>  or  when
   you install <http://swoolley.org/man.cgi/1/install> new kernels.

   [...]

   (if <http://swoolley.org/man.cgi/if>  the  second
   stage  loader is moved away or is crippled it might actually
print less <http://swoolley.org/man.cgi/less>
   letters  from  that  string
<http://swoolley.org/man.cgi/string>  and  die).
<http://swoolley.org/man.cgi/1/builtins>


If you recently modified the layout of the disks, perhaps you need to
just run 'silo' again to make sure that 'second.b' can be found?



On Mon, Jul 21, 2014 at 4:26 PM, Jeremy Kister <
debian-sp...@jeremykister.com> wrote:

> On 7/21/2014 4:59 PM, Patrick Baggett wrote:
>
>> please correct me if I am mistaken!] In that case, perhaps you could
>> backup the old `silo` binary and replace it with the newest one? I would
>> think that if you had a USB port you could do this pretty easily using a
>> flash drive (perhaps PCI USB card + flash drive, like I had in my Ultra
>> 10), but if not, you might be able to utilize tftp and pull it from a
>> server using BusyBox.
>>
>
> Worth a shot.  I don't have local access to the machine at the moment
> (just network+console).  it does have network, though.  do you happen to
> know where the newest silo binary is?  i'm searching now.
>
>
> --
>
> Jeremy Kister
> http://jeremy.kister.net./
>
>

Re: problem booting Debian on X1

[Patrick Baggett]

If you're running Debian 6.x, then you might be able to get one from wheezy
to work (libc version seems to match).

https://packages.debian.org/wheezy/silo and
https://packages.debian.org/wheezy/sparc/silo/download



On Mon, Jul 21, 2014 at 4:26 PM, Jeremy Kister <
debian-sp...@jeremykister.com> wrote:

> On 7/21/2014 4:59 PM, Patrick Baggett wrote:
>
>> please correct me if I am mistaken!] In that case, perhaps you could
>> backup the old `silo` binary and replace it with the newest one? I would
>> think that if you had a USB port you could do this pretty easily using a
>> flash drive (perhaps PCI USB card + flash drive, like I had in my Ultra
>> 10), but if not, you might be able to utilize tftp and pull it from a
>> server using BusyBox.
>>
>
> Worth a shot.  I don't have local access to the machine at the moment
> (just network+console).  it does have network, though.  do you happen to
> know where the newest silo binary is?  i'm searching now.
>
>
> --
>
> Jeremy Kister
> http://jeremy.kister.net./
>
>

Re: problem booting Debian on X1

[Patrick Baggett]

Ah yeah, I forgot that after 1.4.14, the version number hasn't really
increased (despite development). Can you figure out which Debian package
you are using?


On Mon, Jul 21, 2014 at 4:14 PM, Jeremy Kister <
debian-sp...@jeremykister.com> wrote:

> On 7/21/2014 5:09 PM, Patrick Baggett wrote:
>
>> If you can get to a shell, can you tell us what version of `silo` you
>> are running?
>>
>
> /mnt/sbin # ./silo -v
> IEEE 1275
> /mnt/sbin # ./silo -V
> SILO version 1.4.14
> /mnt/sbin #
>
>
>
>
> thanks for your reply,
>
>
> --
>
> Jeremy Kister
> http://jeremy.kister.net./
>
>
>
> --
> To UNSUBSCRIBE, email to debian-sparc-requ...@lists.debian.org
> with a subject of "unsubscribe". Trouble? Contact
> listmas...@lists.debian.org
> Archive: https://lists.debian.org/53cd82a2.5070...@jeremykister.com
>
>

Re: problem booting Debian on X1

[Patrick Baggett]

If you can get to a shell, can you tell us what version of `silo` you are
running?


On Mon, Jul 21, 2014 at 4:05 PM, Jeremy Kister <
debian-sp...@jeremykister.com> wrote:

> On 7/21/2014 4:49 PM, Jeremy Kister wrote:
>
>> Since I don't really know what else to do, I want to reinstall SILO.
>> Can someone point me how to do that from a network boot shell?  BusyBox
>> ash loads, but I have no idea how I can use to to reinstall SILO.
>>
>
> I do have /dev/sda1 (/boot) mounted on /mnt/boot.  /mnt/silo.conf shows:
> # cat silo.conf
> root=/dev/md0
> partition=1
> default=Linux
> read-only
> timeout=100
>
> image=/vmlinuz
> label=Linux
> initrd=/initrd.img
>
> i do have all of the rest of the partitions mounted on /mnt, fyi.
>
>
>
> --
> To UNSUBSCRIBE, email to debian-sparc-requ...@lists.debian.org
> with a subject of "unsubscribe". Trouble? Contact
> listmas...@lists.debian.org
> Archive: https://lists.debian.org/53cd809c.8010...@jeremykister.com
>
>

Re: problem booting Debian on X1

[Patrick Baggett]

I forget the details of SILO, but the first stage (512-byte program) simply
loads stage 2, which is just the program 'silo' itself, I thought. That
probably doesn't change much version-to-version. [Others: please correct me
if I am mistaken!] In that case, perhaps you could backup the old `silo`
binary and replace it with the newest one? I would think that if you had a
USB port you could do this pretty easily using a flash drive (perhaps PCI
USB card + flash drive, like I had in my Ultra 10), but if not, you might
be able to utilize tftp and pull it from a server using BusyBox.



Patrick


On Mon, Jul 21, 2014 at 3:49 PM, Jeremy Kister <
debian-sp...@jeremykister.com> wrote:

> On 6/27/2014 10:50 PM, Jeremy Kister wrote:
>
>> Recently, we rebooted the server (was healthy afaict) and it won't come
>> back.  When it tries to boot, it prints "SI" (where it would normally
>> say SILO and continue booting) and then just gets stuck.
>>
>
> I've got another two systems (Sparc/X1) that are exhibiting the same
> behavior.  After about 10 or so minutes of waiting near "SI" the console
> prints "Program Terminated"
>
> I have configured a netboot server and when using 'boot net' at the ok
> prompt, it starts the install process.  If I break out of the install
> process and try 'Install the SILO boot loader on a hard disk', the
> partitioner starts up and I get scared to go anywhere (I dont want to lose
> any data here!)
>
> Since I don't really know what else to do, I want to reinstall SILO. Can
> someone point me how to do that from a network boot shell?  BusyBox ash
> loads, but I have no idea how I can use to to reinstall SILO.
>
> .. Or, if anyone has other ideas, i'm desperate.
>
> thanks,
>
> --
>
> Jeremy Kister
> http://jeremy.kister.net./
>
>
> --
> To UNSUBSCRIBE, email to debian-sparc-requ...@lists.debian.org
> with a subject of "unsubscribe". Trouble? Contact
> listmas...@lists.debian.org
> Archive: https://lists.debian.org/53cd7cd8.8020...@jeremykister.com
>
>

Re: preparing for GCC 4.9

[Patrick Baggett]

Hi Matthias et al,

I'd like to try to do some of this using my sparc box and see how far I
get. Is there a link that explains how to set up these steps? Others seem
to "just know" what to do, but I haven't the slightest idea of where to
begin. I have a box with gcc-4.9, plenty of disk space, and electricity to
burn. Where do I start?

Patrick


On Thu, May 8, 2014 at 10:25 AM, Matthias Klose  wrote:

> With gcc-4.9 now available in testing, it is time to prepare for the
> change of
> the default to 4.9, for a subset of architectures or for all (release)
> architectures.  The defaults for the gdc, gccgo, gcj and gnat frontends
> already
> point to 4.9 and are used on all architectures.  Issue #746805 tracks the
> gfortran default change, including the change of the Fortran 90 module
> version
> change.
>
> The Debian archive was rebuilt twice on amd64, once in February, resulting
> in
> bug submissions for GCC and feedback for the porting guide [1], a second
> time in
> March to file issues for packages failing to build with GCC 4.9 [2].
>  Another
> test rebuild for Ubuntu on amd64, i386, armhf, ppc64el didn't show any
> other
> compiler regressions on these architectures.
>
> I would like to see some partial test rebuilds (like buildd or minimal
> chroot
> packages) for other architectures. Any possibility to setup such a test
> rebuild
> for some architectures by the porters? Afaics the results for the GCC
> testsuite
> look okish for every architecture.
>
> I'll work on fixing the build failures in [2], help is of course
> appreciated.
> Almost all build failures are analyzed and should be easy to fix
> (exceptions
> e.g. #746883).  Patches for the ones not caused by the Debian packaging
> may be
> found in distributions already using GCC 4.9 as the default compiler (e.g.
> Fedora 21).
>
> If anything goes well, and a large amount of build failures are fixed, I
> plan to
> make GCC 4.9 the default for the C/C++/ObjC/Obj-C++ frontends at the end
> of May,
> beginning of June.
>
> Bugs reports for packages building with a legacy version of GCC (4.6, 4.7,
> 4.8)
> will be filed.
>
>   Matthias
>
> [1] http://gcc.gnu.org/gcc-4.9/porting_to.html
> [2]
>
> https://bugs.debian.org/cgi-bin/pkgreport.cgi?tag=ftbfs-gcc-4.9;users=debian-...@lists.debian.org
>
>
> --
> To UNSUBSCRIBE, email to debian-ia64-requ...@lists.debian.org
> with a subject of "unsubscribe". Trouble? Contact
> listmas...@lists.debian.org
> Archive: https://lists.debian.org/536ba1ce.9070...@debian.org
>
>

Re: the future of sparc in unstable

[Patrick Baggett]

I have SILO v1.4.14, but it has the git [1] patches from 2012-08-19, which
includes quite a few fixes from the 2008-06-12 release. Particularly, it
includes a number of ext2/ext4 boot fixes and some sun4v and sun4u boot
fixes. The remaining patches after that are for "tilo" which is some kind
of TFTP loader.

TL;DR - though it isn't the newest, it should be more or less up to date
for bug fixes.

[1] http://git.kernel.org/cgit/linux/kernel/git/davem/silo.git/log/



On Thu, May 1, 2014 at 6:10 PM, Kieron Gillespie  wrote:

> Well it is a good start. =D
>
> There are still complaints, though haven't seen the bug reports, that
> modern kernel's are unstable on certain peices of hardware. Personally I
> can't reproduce any of these issues, I have rolled out the latest kernel
> for a while now on some of my sparc systems, my T2000 has an uptime of
> about 80days and it's running wheezy but using a vanilla 3.13.9 build.
> There is also some problems with the kernel hanging in the early stages of
> the boot process, though once again I have not seen this. What the sparc
> port needs are a couple of people to become familiar with the Debian
> build process and to find major bugs report and fix them.
>
> I haven't checked but I think that SILO is currently a version or two
> ahead of what debian is using for it's installs. That might be the issue.
>
> Wish I had more time to invest in this.
>
> -Kieron
>
>
> On Thu, May 1, 2014 at 6:21 PM, Patrick Baggett  > wrote:
>
>> BTW, the sparc buildd looks like gcc 4-8.2-21 is successful and so is
>> gcc-4.9.0-1. I've installed them from sid. Crisis averted?
>>
>> Patrick
>>
>>
>> On Wed, Apr 30, 2014 at 4:04 PM, Sébastien Bernard wrote:
>>
>>>  Le 30/04/2014 20:36, Patrick Baggett a écrit :
>>>
>>>
>>>
>>>
>>> On Wed, Apr 30, 2014 at 1:13 PM, Ivo De Decker wrote:
>>>
>>>> Hi,
>>>>
>>>> On Wed, Apr 30, 2014 at 03:42:39PM +0200, Sébastien Bernard wrote:
>>>> > Indeed, the last good build seems to be gcc-4.8-4.8.2-19.
>>>> > Look at the changelog for the -20 they seems to have done something
>>>> on the sparc
>>>> > that blocks the generation of the libraries.
>>>>
>>>>  A number of binaries are now built by gcc-4.9 instead of gcc-4.8. As
>>>> there is
>>>> no build of gcc-4.9 on sparc, these binaries are missing.
>>>>
>>>> https://buildd.debian.org/status/logs.php?pkg=gcc-4.9&arch=sparc
>>>>
>>>> So if you want to fix the sparc issue, you probably need to get gcc-4.9
>>>> to
>>>> build there. When doing that, you need to start from a gcc-4.8 version
>>>> from
>>>> before the change, as newer version are not functional without the
>>>> packages
>>>> from gcc-4.9.
>>>>
>>>>  ???
>>> I thought jessie was using gcc-4.8 and not gcc-4.9
>>>
>>>  OK, so we additionally need to look into why gcc-4.9 is not
>>> installable?
>>>
>>>  Patrick
>>>
>>>
>>> No, we don't. Period.
>>>
>>> I built the gcc-4.8-4.8-19, and all the binaries are there.
>>> I'm going to involve the gcc maintainer cause what they did broke
>>> completely the build be it jessie or sid.
>>>
>>> We have libgcc1, lib64gcc1, libstdc++6,  and libstdc++6 available from
>>> the repositories in version 4.8.2-19.
>>> But, the new builds -20 and -21 have overriden all the other packages
>>> from -19 since they have been build ok.
>>> So, now, we have nothing to install because gcc-base-4.8_4.8.2-20
>>> depends on libgcc1-4.8.2_4.8.2-20 which isn't build (this is the message
>>> from apt-get).
>>>
>>> And this is not solvable, we're halfway through, with partial -19
>>> packages and missing packages -20.
>>>
>>> And if you think it has zero impact, think twice. The debootstrap is not
>>> able to build a sid install because of this.
>>> So, meanwhile, I'll setup a mini directory with the packages availables
>>> (I need to remember how to setup a debian repository again).
>>>
>>> All in all, this broken package has blocked the complete buildd, since
>>> there is no more libgcc1 and no more libstdc++ installable.
>>>
>>> Did I say there is no gcc-4.9 ?
>>>
>>> Here is the recipe for disaster for sparc.
>>>
>>> Seb
>>>
>>
>>
>

Re: the future of sparc in unstable

[Patrick Baggett]

BTW, the sparc buildd looks like gcc 4-8.2-21 is successful and so is
gcc-4.9.0-1. I've installed them from sid. Crisis averted?

Patrick


On Wed, Apr 30, 2014 at 4:04 PM, Sébastien Bernard wrote:

>  Le 30/04/2014 20:36, Patrick Baggett a écrit :
>
>
>
>
> On Wed, Apr 30, 2014 at 1:13 PM, Ivo De Decker wrote:
>
>> Hi,
>>
>> On Wed, Apr 30, 2014 at 03:42:39PM +0200, Sébastien Bernard wrote:
>> > Indeed, the last good build seems to be gcc-4.8-4.8.2-19.
>> > Look at the changelog for the -20 they seems to have done something on
>> the sparc
>> > that blocks the generation of the libraries.
>>
>>  A number of binaries are now built by gcc-4.9 instead of gcc-4.8. As
>> there is
>> no build of gcc-4.9 on sparc, these binaries are missing.
>>
>> https://buildd.debian.org/status/logs.php?pkg=gcc-4.9&arch=sparc
>>
>> So if you want to fix the sparc issue, you probably need to get gcc-4.9 to
>> build there. When doing that, you need to start from a gcc-4.8 version
>> from
>> before the change, as newer version are not functional without the
>> packages
>> from gcc-4.9.
>>
>>  ???
> I thought jessie was using gcc-4.8 and not gcc-4.9
>
>  OK, so we additionally need to look into why gcc-4.9 is not installable?
>
>  Patrick
>
>
> No, we don't. Period.
>
> I built the gcc-4.8-4.8-19, and all the binaries are there.
> I'm going to involve the gcc maintainer cause what they did broke
> completely the build be it jessie or sid.
>
> We have libgcc1, lib64gcc1, libstdc++6,  and libstdc++6 available from the
> repositories in version 4.8.2-19.
> But, the new builds -20 and -21 have overriden all the other packages from
> -19 since they have been build ok.
> So, now, we have nothing to install because gcc-base-4.8_4.8.2-20 depends
> on libgcc1-4.8.2_4.8.2-20 which isn't build (this is the message from
> apt-get).
>
> And this is not solvable, we're halfway through, with partial -19 packages
> and missing packages -20.
>
> And if you think it has zero impact, think twice. The debootstrap is not
> able to build a sid install because of this.
> So, meanwhile, I'll setup a mini directory with the packages availables (I
> need to remember how to setup a debian repository again).
>
> All in all, this broken package has blocked the complete buildd, since
> there is no more libgcc1 and no more libstdc++ installable.
>
> Did I say there is no gcc-4.9 ?
>
> Here is the recipe for disaster for sparc.
>
> Seb
>

Re: Bug#746310: Acknowledgement (libc6: strcmp returns false equality between two strings)

[Patrick Baggett]

This has been fixed upstream by David Miller and applied to all branches
from glibc-2.15 all the way to master. It should be backported to wheezy
and and definitely sid.

Patrick


On Tue, Apr 29, 2014 at 2:57 PM, Sébastien Bernard wrote:

>
> Here's the bug filed against debian.
>
> Cheers.
>
> Seb
>
>  Message original   Sujet: Bug#746310: Acknowledgement
> (libc6: strcmp returns false equality between two strings)  Date : Mon,
> 28 Apr 2014 21:21:06 +  De : ow...@bugs.debian.org (Debian Bug
> Tracking System)  Répondre à : 746...@bugs.debian.org  Pour : Sebastien
> Bernard  
>
> Thank you for filing a new Bug report with Debian.
>
> This is an automatically generated reply to let you know your message
> has been received.
>
> Your message is being forwarded to the package maintainers and other
> interested parties for their attention; they will reply in due course.
>
> Your message has been sent to the package maintainer(s):
>  GNU Libc Maintainers  
> 
>
> If you wish to submit further information on this problem, please
> send it to 746...@bugs.debian.org.
>
> Please do not send mail to ow...@bugs.debian.org unless you wish
> to report a problem with the Bug-tracking system.
>
> --
> 746310: http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=746310
> Debian Bug Tracking System
> Contact ow...@bugs.debian.org with problems
>
>
>
>

Re: the future of sparc in unstable

[Patrick Baggett]

On Wed, Apr 30, 2014 at 1:13 PM, Ivo De Decker wrote:

> Hi,
>
> On Wed, Apr 30, 2014 at 03:42:39PM +0200, Sébastien Bernard wrote:
> > Indeed, the last good build seems to be gcc-4.8-4.8.2-19.
> > Look at the changelog for the -20 they seems to have done something on
> the sparc
> > that blocks the generation of the libraries.
>
> A number of binaries are now built by gcc-4.9 instead of gcc-4.8. As there
> is
> no build of gcc-4.9 on sparc, these binaries are missing.
>
> https://buildd.debian.org/status/logs.php?pkg=gcc-4.9&arch=sparc
>
> So if you want to fix the sparc issue, you probably need to get gcc-4.9 to
> build there. When doing that, you need to start from a gcc-4.8 version from
> before the change, as newer version are not functional without the packages
> from gcc-4.9.
>
> ???
I thought jessie was using gcc-4.8 and not gcc-4.9

OK, so we additionally need to look into why gcc-4.9 is not installable?

Patrick

Re: the future of sparc in unstable

[Patrick Baggett]

On Wed, Apr 30, 2014 at 8:42 AM, Sébastien Bernard wrote:

>  Le 30/04/2014 15:39, Patrick Baggett a écrit :
>
>
>>>  I tried to build the gcc-4.8-4.8.2-20 and the build is broken.
>> libstdc++ and lib64stdc++ are not build, neither are build libgcc1.
>> The last good build (with the missing libraries) is 4.8.2-16.
>> Something broken on -20 and -21.
>>
>>
>  Oh, I see what you're saying. I get lib64stdc++-dev / libstdc++-dev, but
> not the base lib64stdc++/libstdc++
>
>  And yeah, libgcc1 just isn't built, which is a major problem. Maybe we
> need to look at diffs in the "debian" directory.
>
>  Patrick
>
> Indeed, the last good build seems to be gcc-4.8-4.8.2-19.
> Look at the changelog for the -20 they seems to have done something on the
> sparc that blocks the generation of the libraries.
>

Is there a direct way to view the changelog and/or diff from the web?

Patrick

Re: the future of sparc in unstable

[Patrick Baggett]

>
>
>>  I tried to build the gcc-4.8-4.8.2-20 and the build is broken. libstdc++
> and lib64stdc++ are not build, neither are build libgcc1.
> The last good build (with the missing libraries) is 4.8.2-16.
> Something broken on -20 and -21.
>
>
Oh, I see what you're saying. I get lib64stdc++-dev / libstdc++-dev, but
not the base lib64stdc++/libstdc++

And yeah, libgcc1 just isn't built, which is a major problem. Maybe we need
to look at diffs in the "debian" directory.

Patrick

Re: the future of sparc in unstable

[Patrick Baggett]

I kicked off a gcc build (gcc-4.8_4.8.2-21) last night. It didn't have an
errors for me. I now have a bunch of *.deb files:

figgles@ghost:~/src$ ls -1 *.deb
cpp-4.8_4.8.2-21_sparc.deb
g++-4.8-multilib_4.8.2-21_sparc.deb
g++-4.8_4.8.2-21_sparc.deb
gcc-4.8-base_4.8.2-21_sparc.deb
gcc-4.8-locales_4.8.2-21_all.deb
gcc-4.8-multilib_4.8.2-21_sparc.deb
gcc-4.8-plugin-dev_4.8.2-21_sparc.deb
gcc-4.8-source_4.8.2-21_all.deb
gcc-4.8_4.8.2-21_sparc.deb
gcj-4.8-jdk_4.8.2-21_sparc.deb
gcj-4.8-jre-headless_4.8.2-21_sparc.deb
gcj-4.8-jre-lib_4.8.2-21_all.deb
gcj-4.8-jre_4.8.2-21_sparc.deb
gcj-4.8-source_4.8.2-21_all.deb
gcj-4.8_4.8.2-21_sparc.deb
gdc-4.8_4.8.2-21_sparc.deb
gfortran-4.8-multilib_4.8.2-21_sparc.deb
gfortran-4.8_4.8.2-21_sparc.deb
gobjc++-4.8-multilib_4.8.2-21_sparc.deb
gobjc++-4.8_4.8.2-21_sparc.deb
gobjc-4.8-multilib_4.8.2-21_sparc.deb
gobjc-4.8_4.8.2-21_sparc.deb
lib64asan0-dbg_4.8.2-21_sparc.deb
lib64asan0_4.8.2-21_sparc.deb
lib64gcc-4.8-dev_4.8.2-21_sparc.deb
lib64gfortran-4.8-dev_4.8.2-21_sparc.deb
lib64objc-4.8-dev_4.8.2-21_sparc.deb
lib64stdc++-4.8-dev_4.8.2-21_sparc.deb
lib64stdc++6-4.8-dbg_4.8.2-21_sparc.deb
libasan0-dbg_4.8.2-21_sparc.deb
libasan0_4.8.2-21_sparc.deb
libgcc-4.8-dev_4.8.2-21_sparc.deb
libgcj14-awt_4.8.2-21_sparc.deb
libgcj14-dbg_4.8.2-21_sparc.deb
libgcj14-dev_4.8.2-21_sparc.deb
libgcj14_4.8.2-21_sparc.deb
libgfortran-4.8-dev_4.8.2-21_sparc.deb
libobjc-4.8-dev_4.8.2-21_sparc.deb
libstdc++-4.8-dev_4.8.2-21_sparc.deb
libstdc++-4.8-doc_4.8.2-21_all.deb
libstdc++-4.8-pic_4.8.2-21_sparc.deb
libstdc++6-4.8-dbg_4.8.2-21_sparc.deb




On Tue, Apr 29, 2014 at 3:12 PM, Sébastien Bernard wrote:

> Le 26/04/2014 21:33, Ralf Treinen a écrit :
>
>  Hello,
>>
>> we currently have in unstable/main/sparc precisely 35491 packages, of
>> a total of 40634 available packages, that cannot be installed in the
>> current version of unstable:
>>
>> % dose-debcheck --fg Packages --deb-ignore-essential
>> background-packages: 0
>> foreground-packages: 40634
>> total-packages: 40634
>> broken-packages: 35491
>>
>> The most common cause seems to be that libgcc1 1:4.8.2-19 depends on
>> gcc-4.8-base (= 4.8.2-19), and version 4.8.2-20 is in the archive. I just
>> found this when I investigated why the daily run of my dose-debcheck
>> script
>> explodes the last 3 days.
>>
>> -Ralf.
>>
>>
>>  I tried to build the gcc-4.8-4.8.2-20 and the build is broken. libstdc++
> and lib64stdc++ are not build, neither are build libgcc1.
> The last good build (with the missing libraries) is 4.8.2-16.
> Something broken on -20 and -21.
>
> My .002 contribution.
>
> Seb
>
>
>
> --
> To UNSUBSCRIBE, email to debian-sparc-requ...@lists.debian.org
> with a subject of "unsubscribe". Trouble? Contact
> listmas...@lists.debian.org
> Archive: https://lists.debian.org/53600797.2010...@nerim.net
>
>

Re: Bug#731806: debian-installer: FTBFS on sparc: genisoimage errors

[Patrick Baggett]

On Tue, Apr 29, 2014 at 2:35 PM, Patrick Baggett
wrote:

> Yes, that's the one. Interestingly, in glibc-2.19, this change is
> reverted. It is present in glibc-2.17 & glibc-2.18 as released by GNU.
> Oddly, in glibc git, the buggy version appears.
>
>
>
I've filed a bug with glibc [1] and let the author know that there is a
problem. In the meantime, I'll try to figure out what the problem is. I
think we may need to file a debian bug though since it will require a glibc
update. Sebastien, can you handle that?

Patrick

[1] https://sourceware.org/bugzilla/show_bug.cgi?id=16885

Re: Bug#731806: debian-installer: FTBFS on sparc: genisoimage errors

[Patrick Baggett]

Yes, that's the one. Interestingly, in glibc-2.19, this change is reverted.
It is present in glibc-2.17 & glibc-2.18 as released by GNU. Oddly, in
glibc git, the buggy version appears.


On Tue, Apr 29, 2014 at 2:25 PM, Lennart Sorensen <
lsore...@csclub.uwaterloo.ca> wrote:

> On Tue, Apr 29, 2014 at 06:01:00PM +0200, Sébastien Bernard wrote:
> > Le 29/04/2014 16:50, Kieron Gillespie a écrit :
> > >I'll rebuild one of my SunBlade 2500 latter with sid and see if I
> > >get the same result. If it doesn't show the symptom I will rebuild
> > >my T2000 and see if it is something specific to the Niagara T1.
> > >
> > >-Kieron
> > >
> > >
> > >On Tue, Apr 29, 2014 at 10:45 AM, Sébastien Bernard
> > >mailto:sbern...@nerim.net>> wrote:
> > >
> > >Le 29/04/2014 16:34, Kieron Gillespie a écrit :
> > >
> > >I am currently investigating this unusual behavior with
> > >strcmp, and I am unable to reproduce the problem using the
> > >test_strcmp example provided.
> > >
> > >It returns the correct output of,
> > >
> > >result from strcmp('\','\0001' is -1)
> > >
> > >This was built on Debian Wheezy with a T2000 SPARC processor
> > >using GCC 4.6.3-14 from Debian Wheezy Repo.
> > >
> > >Cheers,
> > >Kieron
> > >
> > >Hum, I tried with a T5220 with debian 7.5 /wheezy.
> > >Same result, the strcmp is ok.
> > >Could you try with unstable ?
> > >
> > >Cheers.
> > >
> > >
> > Tested on niagara T5220:
> >  with wheezy 2.13 glibc:
> > root@skynet:~# ./test_strcmp
> > result from strcmp('\','\0001' is -1)
> > result from memcmp('\','\0001' is -1)
> >
> > Tested from debootstrap sid on the same niagara :
> > root@skynet:/# ./test_strcmp
> > result from strcmp('\','\0001' is 0)
> > result from memcmp('\','\0001' is -1)
> >
> >
> > So, glibc-2.18 is broken on sparc.
>
> So does that mean this commit broke it:
>
> commit ad69cc2652c0422ebac3296d914c25e470498ce1
> Author: David S. Miller 
> Date:   Wed Aug 24 01:32:24 2011 -0700
>
> Rewritten v9/64-bit sparc strcmp.
>
> diff --git a/ChangeLog b/ChangeLog
> index 4fde8c2..ab754e5 100644
> --- a/ChangeLog
> +++ b/ChangeLog
> @@ -1,3 +1,7 @@
> +2011-08-24  David S. Miller  
> +
> +   * sysdeps/sparc/sparc64/strcmp.S: Rewrite.
> +
>  2011-08-24  Andreas Schwab  
>
> * elf/Makefile: Add rules to build and run unload8 test.
> ...etc...
>
> --
> Len Sorensen
>

Re: Bug#745938: decide on the future of sparc in unstable

[Patrick Baggett]

On Tue, Apr 29, 2014 at 1:29 PM, Steven Chamberlain wrote:

> On Tue, 29 Apr 2014 13:36:31 +0200, Joël BERTRAND wrote:
> >   sun4u : kernel is stable until 2.6.32. [...]
> >
> >   sun4v : I have several T1000 for a long time. I haven't seen any
> stable
> > kernel on these servers.
>
> Maybe someone could think about a k*bsd-sparc port ;)
>
> Generally speaking, I think if you're just going for NTP server, this is
fine.

However, I like pushing the hardware combinations to weird extremes. I like
putting hardware into non-x86 machines and seeing where the drivers succeed
and fail. My favorite example is getting Mesa3D to function. This is
basically a no-go on most of the *BSDs because they just don't have the
driver support. If someone can demonstrate a *BSD/sparc running X and
accelerated OpenGL using any non-Sun GPU made from 2000 forward, I might
consider using a *BSD kernel, but so far, it seems all the development for
FOSS GPU drivers is on Linux.

Re: State of Haskell on sparc?

[Patrick Baggett]

On Tue, Apr 29, 2014 at 1:19 PM, Richard Mortimer wrote:

> Hi,
>
>
> On 29/04/2014 17:26, Colin Watson wrote:
>
>  Program received signal SIGBUS, Bus error.
>> 0x003d8c2c in md5_do_chunk ()
>> (gdb) bt
>> #0  0x003d8c2c in md5_do_chunk ()
>> #1  0x003d9a10 in md5_update ()
>> #2  0x003d2070 in saqF_ret ()
>> #3  0x00da1e48 in StgRun ()
>> #4  0x00d9f65c in scheduleWaitThread ()
>> #5  0x00d9c774 in real_main ()
>> #6  0x00d9c8c8 in hs_main ()
>> #7  0x0003b624 in main ()
>> (gdb) disas /rm
>> Dump of assembler code for function md5_do_chunk:
>> 0x003d8c18 <+0>: 9d e3 bf 20 save  %sp, -224, %sp
>> 0x003d8c1c <+4>: b6 07 bf c0 add  %fp, -64, %i3
>> 0x003d8c20 <+8>: 07 00 00 3f sethi  %hi(0xfc00), %g3
>> 0x003d8c24 <+12>:82 10 20 00 clr  %g1
>> 0x003d8c28 <+16>:86 10 e3 00 or  %g3, 0x300, %g3
>> => 0x003d8c2c <+20>:c4 06 40 01 ld  [ %i1 + %g1 ], %g2
>>
> That is loading the 2nd parameter to md5_do_chunk. I think that is defined
> as uint32_t *buf
> (source http://hackage.haskell.org/package/cryptohash-0.4/src/cbits/md5.c)
>
> The register dump below shows that %i1 is not 4 byte aligned.
>
> That would correspond to the force cast of ctx->buf to a uint32_t *
> in md5_update in the same file.
>

As I've mentioned, I've already reported the issue to upstream [1].
 Additionally, now I have provided a pull request [2] to resolve the issue.

[1] https://github.com/vincenthz/hs-cryptohash/issues/24
[2] https://github.com/vincenthz/hs-cryptohash/pull/25

Re: Bug#731806: debian-installer: FTBFS on sparc: genisoimage errors

[Patrick Baggett]

On Tue, Apr 29, 2014 at 10:01 AM, Kieron Gillespie <
ciaran.gilles...@gmail.com> wrote:

>
> On Tue, Apr 29, 2014 at 10:47 AM, Patrick Baggett <
> baggett.patr...@gmail.com> wrote:
>
>>
>>
>> On Tue, Apr 29, 2014 at 9:34 AM, Kieron Gillespie <
>> ciaran.gilles...@gmail.com> wrote:
>>
>>> I am currently investigating this unusual behavior with strcmp, and I am
>>> unable to reproduce the problem using the test_strcmp example provided.
>>>
>>> It returns the correct output of,
>>>
>>>
>>> result from strcmp('\','\0001' is -1)
>>>
>>> This was built on Debian Wheezy with a T2000 SPARC processor using GCC
>>> 4.6.3-14 from Debian Wheezy Repo.
>>>
>>>
>> Can you set a breakpoint in strcmp and tell me what the file path is?
>> Perhaps there is a sun4v specific function (optimized version) that does
>> not have a bug?
>>
>> Patrick
>>
>>
>
> Here is the information from strcmp breakpoint
>
> ---CUT---
> Breakpoint 1, 0xf7ebd300 in strcmp () from /lib/sparc-linux-gnu/libc.so.6
> (gdb) disas strcmp
> Dump of assembler code for function strcmp:
> => 0xf7ebd300 <+0>: sethi  %hi(0x101), %g1
>0xf7ebd304 <+4>: btst  7, %o0
>0xf7ebd308 <+8>: bne,pn   %icc, 0xf7ebd4a0 
>0xf7ebd30c <+12>:or  %g1, 0x101, %g1
>0xf7ebd310 <+16>:andcc  %o1, 7, %g3
>0xf7ebd314 <+20>:bne,pn   %icc, 0xf7ebd4e4 
>0xf7ebd318 <+24>:sllx  %g1, 0x20, %g2
>0xf7ebd31c <+28>:ldx  [ %o0 ], %o2
> ---CUT---
>
> They aren't the same implementation. Look:

or  rSTR2, rSTR1, rTMP1
sethi   %hi(0x80808080), r8080
andcc   rTMP1, 0x7, %g0
bne,pn  %icc, .Lmaybe_barrel_shift
 or r8080, %lo(0x80808080), r8080
ldx [rSTR1], rWORD1
sub rSTR2, rSTR1, rSTR2
sllxr8080, 32, rTMP1
ldx [rSTR1 + rSTR2], rWORD2
or  r8080, rTMP1, r8080


Side by side, the instructions aren't even the same:

Failing   | Working
--+
or| sethi 0x1010
sethi 8080| btst
btst* | bne
bne   | or 0x101
or 808| andcc ... %g3
ldx   | bne
sub   | sllx
sllx  | ldx
 ...

*btst  rA, rB -> andcc rA, rB, %g0



As far as I can tell from stepping through this it seems like a correctly
> implementation of strcmp.
>
> ---CUT---
> (gdb) info reg
> g0 0x0  0
> g1 0x20754  132948
> g2 0x33dfaf454393588
> g3 0x3dfaf4 4061940
> g4 0xf869cbac   -127284308
> g5 0x28 40
> g6 0xfeff   65279
> g7 0xf7ff66d0   -134256944
> o0 0xdc48   -9144
> o1 0xdc50   -9136
> o2 0xdd34   -8908
> ---CUT---
>
> You can see that o0 and o1 are holding the pointers for the strings
> correctly and examining the value of memory at those location appears to be
> correct.
>
> With -O3 the call is the same. So I am not sure what is going on, would
> like to see an "info reg" at the breakpoint of strcmp on the affected
> systems. Also an examiniation of the memory that o0 and o1 are pointing too.
>
> -Kieron
>
>

Re: Bug#745938: FWIW -- I consider sparc useful, pity if its support ends completely

[Patrick Baggett]

On Tue, Apr 29, 2014 at 8:43 AM, Mark Morgan Lloyd <
markmll.debian-sp...@telemetry.co.uk> wrote:

> Joël BERTRAND wrote:
>
>  sun4u : kernel is stable until 2.6.32. All kernels since 2.6.33 hang
>> with a deadlock or similar issue (UP and SMP) on U1E, U2, U5, U60, U80,
>> U420, Blade2000. I have done some bug reports to David Miller some time ago.
>>
>
> I've got 3.2.35 running to fairly good effect on multiple systems (E4500,
> U60 etc.) with an uptime of at least weeks. 3.2.0 from Wheezy fails when
> running a heavy mix on a V880.
>
>
We need to start consolidating these issues into one place so that
interested parties can look into them. I care about sun4u working and will
attempt to fix kernel issues. Let's create a new thread / bug report for
that. Is there some kind of wiki space for debian-sparc?

-- 
> 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 debian-sparc-requ...@lists.debian.org
> with a subject of "unsubscribe". Trouble? Contact
> listmas...@lists.debian.org
> Archive: https://lists.debian.org/ljoa99$l6f$1...@pye-srv-01.telemetry.co.uk
>
>

Re: Bug#731806: debian-installer: FTBFS on sparc: genisoimage errors

[Patrick Baggett]

On Tue, Apr 29, 2014 at 9:34 AM, Kieron Gillespie <
ciaran.gilles...@gmail.com> wrote:

> I am currently investigating this unusual behavior with strcmp, and I am
> unable to reproduce the problem using the test_strcmp example provided.
>
> It returns the correct output of,
>
>
> result from strcmp('\','\0001' is -1)
>
> This was built on Debian Wheezy with a T2000 SPARC processor using GCC
> 4.6.3-14 from Debian Wheezy Repo.
>
>
Can you set a breakpoint in strcmp and tell me what the file path is?
Perhaps there is a sun4v specific function (optimized version) that does
not have a bug?

Patrick

Re: State of Haskell on sparc?

[Patrick Baggett]

On Tue, Apr 29, 2014 at 9:27 AM, Joachim Breitner wrote:

> Hi everyone,
>
> one of the current Haskell release transitions blocker is the removal of
> some obsolete Haskell libraries, in particular haskell-tls-extra
> (https://bugs.debian.org/741230).
>
> According to "dak rm -R -n haskell-tls-extra" this blocked by left over
> packages depending on it on sparc. The root of the cause is a failure of
> haskell-tls to build on sparc:
> https://buildd.debian.org/status/logs.php?pkg=haskell-tls&arch=sparc
>
>
Hi Joachim,

I'd like to look into the TLS failures. Bus errors usually mean "misaligned
data" which aren't very difficult to fix once you see the source code. Is
there a bug report for the SPARC failure? Help me reproduce it on my local
machine and I think I should be able to fix it soon!

Patrick

Re: sparc has been pulled from jessie

[Patrick Baggett]

On Mon, Apr 28, 2014 at 3:40 PM, Sébastien Bernard wrote:

> Well, folks,
> I think this is one step closer to the end.
> The sparc has been removed from the jessie archive.
> That's a shame cause the problem with the generation of the
> debian-installer is about to be fixed.
> There was no final notice, or maybe I missed it.
> I don't think they will reconsider.
> Maybe some debian developper can argue for our case.
>
> Bah. I don't even know what the requirements for staying in the cool kids
club are or how close/far sparc is from meeting them. I was hearing "gcc
4.8" noise, but I've had gcc-4.8 installed on my machine for a long time
and never had a problem with it. Not really sure what needs to be done for
debian version N+1 to get sparc back in.



> Anyway, I'll try keep it alive as hard as I'm able to.
>
> Yeah, same. Too much sparc HW to quit. :)

Patrick

Re: Bug#731806: debian-installer: FTBFS on sparc: genisoimage errors

[Patrick Baggett]

On Mon, Apr 28, 2014 at 1:20 PM, Thomas Schmitt  wrote:

> Hi,
>
> > I really need a disassembly and to be able to probe the runtime
> It's the job of a C union to provide a common hull around objects
> of different size. One may dispute whether using union is a good
> idea (like overloading in the OO paradigm). But unions are part of C
> since K&R and they are supposed to be safe.
>
> http://www.gnu.org/software/gnu-c-manual/gnu-c-manual.html#Size-of-Unions


No, it's plain wrong. Unions are fine, if used properly. You aren't using
them properly. Let me show you how by a more extreme example:

#include 

struct small {
   int a;
};

struct big {
   int b[1024*1024];
};

union both {
   struct small imSmall;
   struct big imBig;
};


void copy(union both* b, void* data) {

*b = *(union both*)data; //copies 4MB of data.
}

void main() {
struct small smallThing;
union both* bothThings = malloc(sizeof(union both));
copy(bothThings, &smallThing); // NOT OK. struct small cannot NOT be
converted to union both.
}

figgles@ghost:~$ ./big
Segmentation fault

The problem is that union can convert to a member (by accessing the field),
but a member CANNOT convert to a union. add_worker() takes a member and
tries to convert it to a union. This is WRONG. Period.

Re: Bug#731806: debian-installer: FTBFS on sparc: genisoimage errors

[Patrick Baggett]

Seb,

Yes, I can reproduce this issue.

{ 1, 0 }
{ 1, 1 }

returns 0, when it should return -1.


Interestingly, if you use:
{ 1, 1, 1, 1, 0 }  //i.e. 5 bytes
{ 1, 1, 1, 1, 1 }  //i.e. 5 bytes

as the strings, it returns -1. So it clearly has a problem if the string is
exceptionally short. That got me thinking. How short?

{ 1, 1, 1, 0 }  //i.e. 4 bytes, returns -1
{ 1, 1, 1, 1 }

{ 1, 1, 0 }  //i.e. 3 bytes, returns -1
{ 1, 1, 1 }

{ 1, 0 }  //i.e. 2 bytes, return -1
{ 1, 1 }

{ 0 }  //i.e. 1 byte, returns -1 : HOLD ON, WHAT?
{ 1 }


So the 1-bye case succeeded, but why? The only difference between that and
the failing case was two null bytes which shouldn't even be examined.


{ 0, 0 }  //i.e. original test case. Fails, returns 0
{ 1, 0 }

{ 1, 0, 0 } //fails, returns 0.
{ 1, 1, 0 }

{ 1, 1, 0, 0 } //fails, returns 0.
{ 1, 1, 1, 0 }

{ 1, 1, 1, 0, 0 } //fails, returns 0.
{ 1, 1, 1, 1, 0 }

{ 1, 1, 1, 1, 0, 0 } //fails, returns 0.
{ 1, 1, 1, 1, 1, 0 }

... ok ... ?

So apparently, ending with a null character that shouldn't even be examined
messes things up? Let's try something radically different:

{ 1, 1, 1, 1, 0, 0xaa } //returns -1, OK
{ 1, 1, 1, 1, 1, 0 }

{ 1, 1, 1, 1, 0, 0 } //returns -1, OK
{ 1, 1, 1, 1, 1, 0xaa }

{ 1, 1, 1, 1, 0, 0xaa} //returns -1, OK
{ 1, 1, 1, 1, 1, 0xbb }





On Mon, Apr 28, 2014 at 6:35 AM, Sébastien Bernard wrote:

> Le 28/04/2014 13:20, Thomas Schmitt a écrit :
>
>
>>  [genisoimage]
>>> (gdb) x rpnt
>>> 0x1ea7f9:0x
>>> (gdb) x lpnt
>>> 0x1e9dc1:0x0100
>>> (gdb) n
>>> 659if (strcmp(rpnt, lpnt) == 0) {
>>>
>> Both values match the prescribed names for "." and ".." in ECMA-119
>> (aka ISO 9660), 6.8.2.2 Identification of directories:
>> Single byte 0x00 is ".", single byte 0x01 is "..".
>>
> Ok, I got the bug nailed.
> Here's a sample session from my sparc:
> --
> cat  test_strcmp.c< #include 
> #include 
>
> void main(void) {
>   char stra[2];
>   char strb[2];
>   int result = 0;
>
>   stra[0] = 0;
>   stra[1] = 0;
>   strb[0] = 1;
>   strb[1] = 0;
>
>   result = strcmp(stra,strb);
>
>   printf("result from strcmp('\\','\\0001' is %d)\n",result);
>   exit(0);
> }
> EOF
> gcc -o test_strcmp test_strcmp.c
> ./test_strcmp
> result from strcmp('\','\0001' is 0)
> --
>
> Here's the same sample from my intel workstation:
> --
> gcc -o test_strcmp test_strcmp.c
> ./test_strcmp
> result from strcmp('\','\0001' is -1)
> --
>
> Typicaly, an endianness error.
>
> If I apply this patch on cdrkit:
> --- genisoimage/write.c2014-04-28 13:31:28.103571175 +0200
> +++ genisoimage/write.c.new2014-04-28 13:31:07.255433923 +0200
> @@ -656,7 +656,7 @@
>  #endif/* APPLE_HYB */
>
>  /* If the entries are the same, this is an error. */
>
> -if (strcmp(rpnt, lpnt) == 0) {
> +if (strcmp(rpnt, lpnt) == 0 && rpnt[0] == lpnt[0]) {
>  #ifdefUSE_LIBSCHILY
>  errmsgno(EX_BAD,
>  "Error: '%s' and '%s' have the same ISO9660 name '%s'.\n",
>
> Then the iso is correctly generated.
>
> I'll file a bug with cdrkit. I think that genisoimage with that test is
> unable to generated any iso at all on big endian machines.
>
>  So, strcmp shouldn't have yielded 0 when comparing the strings.
>>>
>> Can this be caused by alignment problems ?
>>
> Nope.
>
>
>>
>>  Hum, unfortunately, valgrind is not available for sparc.
>>>
>> Then gdb will have to do.
>>
>>
>>  xorriso is the one compiled from isoburn. I tried with the one from the
>>> archive, and the one rebuild from source with a debbuild.
>>> Same problem on both.
>>>
>> If you also built libisofs and libburn from source, then this burries
>> my theory of a binary incompatibility between two SPARC machines.
>>
>>  I'm compiling at this moment the vanilla xorriso from gnu.
>>> Let's see what it yields.
>>>
>> It has the same source as the three library tarballs used as input
>> for Debian's xorriso. Only difference is that GNU xorriso brings
>> own copies of the library source code and links it statically with
>> the xorriso main program.
>> So it can be easily tested without interfering with installations
>> of the libraries. (And with no need for superuser privileges.)
>>
> I filed a bug with xorriso. Waiting for the number to show up.
>
>
>>
>> Have a nice day :)
>>
>> Thomas
>>
>>
>>  You too ; ).
>
> Seb
>
>
>
> --
> To UNSUBSCRIBE, email to debian-sparc-requ...@lists.debian.org
> with a subject of "unsubscribe". Trouble? Contact
> listmas...@lists.debian.org
> Archive: https://lists.debian.org/535e3cf6.3080...@nerim.net
>
>

Re: Bug#731806: debian-installer: FTBFS on sparc: genisoimage errors

[Patrick Baggett]

On Mon, Apr 28, 2014 at 12:25 PM, Thomas Schmitt  wrote:

> Hi,
>
> Patrick Baggett:
> > Could you explain the context around this code? Perhaps the source is
> > not really "alignment safe" and could use some patching upstream? I'd
> > be happy to provide advice or code samples.
>
> The context was misposted to bug report 731806 as message #87:
>   https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=731806#87
> (but not with Cc to debian-sparc list).
>
> Upstream is myself. :))
> The code in question is by my unreachable libburn predecessors, though.
>
> It belongs to the preparation of a thread start for one of five
> occasions in libburn. SIGBUS happens at
>   http://libburnia-project.org/browser/libburn/trunk/libburn/async.c#L149
>
> The caller has a local struct (i.e. on stack) like (#L592, #L692):
>
>struct write_opts write;
>...
>add_worker(Burnworker_type_writE, d,
>(WorkerFunc) write_disc_worker_func, &o);
>
> The called function gets its address as parameter "data" (#L135):
>
>   static void add_worker(int w_type, struct burn_drive *d,
>  WorkerFunc f, void *data)
>
> has a struct on heap (#L102, #L138, #L146):
>
>struct w_list{
>...
>union w_list_data
>{
>...
>struct write_opts write;
>...
>} u;
>}
>...
>struct w_list *a;
>...
>a = calloc(1, sizeof(struct w_list));
>
> The gesture which causes the SIGBUS is (#L149)
>
>a->u = *(union w_list_data *)data;
>
> which is not what i personally would use, but should be fully legal
> nevertheless.
>
>
I'm not sure what the problem is exactly here. 64-bit SPARC will use ldx to
load 64-bit quantities, which can cause problems if the source data is only
4-byte aligned, but that doesn't seem to be the case here. I really need a
disassembly and to be able to probe the runtime stack a bit, so that really
means that I need to build the code. :)

I think as a more meta-problem is this: the code's logic for "how much" to
copy is wrong. It copies too many bytes on many cases and violates the C
contract that you'll only copy like objects using "=".

Imagine:

sizeof(struct erase_ops) == 8 (32-bit ABI)
sizeof(w_list_data) == at least 12 (32-bit ABI).

Suppose: data = &some_erase_ops

a->u = *(union w_list_data *)data; // copies 12 bytes from 8 byte area, can
cause crashes if the last 4 bytes are into an unmapped page.


The correct way to do this would be to have add_worker() pass a const
w_list_data* with the appropriate field(s) in '.u' filled out. Otherwise,
you're copying unlike objects *of different sizes* and that's never safe.

---

Patrick




> The SIGBUS vanishes if i compile without gcc -O2, or if i replace
> the "a->u =" gesture by
>
>memcpy(&(a->u), data, sizeof(union w_list_data));
>
> which i deem equivalent (and more my personal style).
>
>
> Have a nice day :)
>
> Thomas
>
>

Re: Bug#731806: debian-installer: FTBFS on sparc: genisoimage errors

[Patrick Baggett]

On Mon, Apr 28, 2014 at 11:39 AM, Thomas Schmitt  wrote:

> Hi,
>
> sorry for mis-posting the first reply for bug 746254 to this bug 731806.
>
> Meanwhile it turned out that the SIGBUS vanishes if i do not
> compile with -O2 or if i replace "a->u =" by memcpy().
>
> Could you explain the context around this code? Perhaps the source is not
really "alignment safe" and could use some patching upstream? I'd be happy
to provide advice or code samples.



> So it seems worth to check whether genisoimage resp. strcmp() work
> properly if not compiled with -O2.
>
> 
>
> A test with Sebastiens genisoimage options succeeded without error.
>
>   /home/thomas/xorriso-1.3.7/xorriso/xorriso -as mkisofs \
>   -r -J -o test.iso -G ~/boot/isofs.b -B ... tmp-iso/miniiso/cd_tree
>
> It looks ok, SPARC-boot-wise.
>
>   SUN SPARC disklabel: CD-ROM Disc with Sun sparc boot created by libisofs
>   SUN SPARC secs/head: 640
>   SUN SPARC heads/cyl: 1
>   SUN SPARC partmap  : N   IdTag   PermsStartCyl   NumBlocks
>   SUN SPARC partition: 1  0x0004  0x0010   0   16940
>   SUN SPARC partition: 2  0x0002  0x0010   0   16940
>   ...
>   SUN SPARC partition: 8  0x0002  0x0010   0   16940
>
> An additional option --md5 enabled confirmation that the ISO stream
> of libisofs was written flawlessly by libburn into the file test.iso.
>
>   /home/thomas/xorriso-1.3.7/xorriso/xorriso \
>   -for_backup -indev test.iso -check_media --
>
> xorriso is willing to load the ISO metadata and to compare it with
> the hard disk tree.
>
>   /home/thomas/xorriso-1.3.7/xorriso/xorriso \
>   -indev test.iso -compare_r tmp-iso/miniiso/cd_tree /
>
> It only detects the consequences of option -r with directories
> (see man genisoimage / mkisofs):
> Permissions are set to "r-xr-xr-x", owned by 0, group is 0.
>
> 
>
> Have a nice day :)
>
> Thomas
>
>
> --
> To UNSUBSCRIBE, email to debian-sparc-requ...@lists.debian.org
> with a subject of "unsubscribe". Trouble? Contact
> listmas...@lists.debian.org
> Archive:
> https://lists.debian.org/18128670805771551...@scdbackup.webframe.org
>
>

Re: Sparc status ?

[Patrick Baggett]

>
>
> No, that is not accurate.  The main reason is that there are a number of
> issues with the sparc port currently that are not being addressed
> because apparently nobody is interested enough in the sparc port to fix
> the issues.
>
>
OK, what are the major issues and the bug # assigned to them? I'd like to
keep sparc alive, I have working hardware, and I am very knowledgeable in
C/C++ and to a lesser extent SPARC assembly.



> >
> The debian.org sparc machines do not work reliably with recent kernels.
> That is not sustainable.
>
> That sounds bad. Suppose I have a kernel that I believe will resolve the
issue. What is the process to test and verify that it's OK?




> Cheers,
> Julien
>

Re: Bug#731806: debian-installer: FTBFS on sparc: genisoimage errors

[Patrick Baggett]

On Mon, Apr 28, 2014 at 11:25 AM, Sébastien Bernard wrote:

>  Le 28/04/2014 16:05, Patrick Baggett a écrit :
>
>  strcmp() may well be implemented by word comparisons. But then it
>
>>  is the duty of the implementation to properly handle the ends of
>>> the strings even if those are not word aligned.
>>>
>>  Indeed, the correct fix is using strcmp. Meanwhile, the package is
>> broken.
>>
>>
>  Wow, that's pretty bad. How did that slip? Also, are you building 64-bit
> or 32-bit code, and what CPU architecture (perhaps some per-CPU
> implementation is buggy but not others?) This information will help when
> tracking down the issue.
>
>   I think this happens in this particular case comparing \000x and \.
> I had a look at my test_case, the build is 32bit and the called function
> is dynamic in the glibc.
> I tried a 64bit build, it's the same problem.
> I tried various optimization flags and using __builtin_strcmp withtout any
> change.
>
> Could you check this little program test against one of your machine ?
> Just to be sure ?
>
> Yeah sure, no problem -- I'll check it out soon. I'm somewhat comfortable
with SPARC assembly, so I'll see if I can dig a little deeper into why it
is failing.

Re: Sparc status ?

[Patrick Baggett]

>
>
>>  The main problem is that the 2 new buildd are Niagara machines which are
> not really stable. It left only 2 buildd which seems to be quit old and
> slow.
>
> On my V240, the 3.13 kernel seems to be rock solid (I've been rebuilding
> the gcc package 3 times - 8hours build - without any issue).
> Maybe what's missing is a couple of stable buildd to match the workload.
>

Interesting. I have a SB 2500 (2xUltraSPARC III) and I faced some
instability when using 'git clone' on a kernel I compiled, but stock debian
was OK. I wrote it off since I changed the default memory allocator and
enabled a few experimental features, but maybe there is something more to
this. Perhaps we should compare some kernel configurations and see where
the source of instability might be.

Patrick

Re: Bug#731806: debian-installer: FTBFS on sparc: genisoimage errors

[Patrick Baggett]

On Mon, Apr 28, 2014 at 8:17 AM, Sébastien Bernard wrote:

> Le 28/04/2014 14:15, Thomas Schmitt a écrit :
>
>  Hi,
>>
>> Sébastien Bernard:
>>
>>> result from strcmp('\','\0001' is 0)
>>> result from strcmp('\','\0001' is -1)
>>> Typicaly, an endianness error.
>>>
>> But one in strcmp(), not in your code or the one of genisoimage.
>> You compare an empty string with a string that contains one
>> character 0x01.
>> This is under no endianness allowed to strcmp() == 0.
>>
> Ok, you are correct.
> strcmp yields a bad result. I wasn't sure strcmp was doing byte
> comparaison.
> However, memcmp function is ok.
>
>
>
>  -if (strcmp(rpnt, lpnt) == 0) {
>>> +if (strcmp(rpnt, lpnt) == 0 && rpnt[0] == lpnt[0]) {
>>>
>> Are you sure that it does not miscompare other strings too ?
>>
> Basically, the fix is just to check, in case of strcmp() == 0 that the
> first byte of each string is the same.
> It's should be redundant operation if strcmp == 0 but not in the case of
> strcmp is misbehaving.
> It's just a workaround. The correct fix is, of course, to fix the strcmp.
> Another workaround would be to use :
>
>
> -if (strcmp(rpnt, lpnt) == 0) {
> +if (memcmp(rpnt, lpnt,MAX_ISONAME+1) == 0) {
>
>
>
>
>>
>>  I think that genisoimage with that test is
>>> unable to generated any iso at all on big endian machines.
>>>
>> I cannot agree with this diagnosis.
>> Not having a big-endian machine at hand now, i can confirm from
>> my old SunOS-4-on-SPARC days that strcmp() is supposed to yield
>> a non-zero result with your example char arrays.
>>
>> strcmp() may well be implemented by word comparisons. But then it
>> is the duty of the implementation to properly handle the ends of
>> the strings even if those are not word aligned.
>>
> Indeed, the correct fix is using strcmp. Meanwhile, the package is broken.
>
>
Wow, that's pretty bad. How did that slip? Also, are you building 64-bit or
32-bit code, and what CPU architecture (perhaps some per-CPU implementation
is buggy but not others?) This information will help when tracking down the
issue.


>
>
>>
>>  I filed a bug with xorriso. Waiting for the number to show up.
>>>
>> I will hopefully get a notification via the pkg-libburnia-devel
>> list. Else i will bother you.
>>
>
> Hum, still no answer. I'm going to fill it again.
>
>
>
>>
>> Steve McIntyre:
>>
>>> We build all the release images on an amd64 machine, pettersson.d.o
>>>
>> Ok. That explains why there are sparc-bootable ISOs from xorriso.
>>
> I didn't imagine it could be doable.
>
>
>>
>>
>> Have a nice day :)
>>
>> Thomas
>>
>>
>>  Thanks for your time and dedication.
>
> Seb
>
>
>
> --
> To UNSUBSCRIBE, email to debian-sparc-requ...@lists.debian.org
> with a subject of "unsubscribe". Trouble? Contact
> listmas...@lists.debian.org
> Archive: https://lists.debian.org/535e54ee.6050...@nerim.net
>
>

Re: Bug#745938: decide on the future of sparc in unstable

[Patrick Baggett]

I still run Debian on three SPARC machines, so I am definitely interested.

Patrick


On Sat, Apr 26, 2014 at 12:16 PM, Ansgar Burchardt wrote:

> Hi,
>
> Philipp Kern  writes:
> > now that sparc has been dropped from testing, please decide on the fate
> > of sparc in unstable.
>
> Are there still people interested in the current sparc port?
>
> I don't remember seeing any replies to the release team's concers
> regarding sparc, so my first impression is that people are no longer
> working on it... In that case I don't think we should keep it in the
> archive much longer.
>
> Ansgar
>
>
> --
> To UNSUBSCRIBE, email to debian-sparc-requ...@lists.debian.org
> with a subject of "unsubscribe". Trouble? Contact
> listmas...@lists.debian.org
> Archive: https://lists.debian.org/87d2g4royr@deep-thought.43-1.org
>
>

Re: Sparc status ?

[Patrick Baggett]

>
>
> Because GCC maintainers have been saying for years, that they are
> unwilling to support the weird use case of Debian sparc port, which has
> 64-bit kernel but 32-bit userspace. I can find discussions about it going
> back as far as 2009:
>
>
Also, a lot of the messages about "removing v8 support" or "upstream
dropping sparc32" is confusing. SPARCv8, sometimes called "sparc32" (more
specifically, 32-bit SPARCv8 ISA that predates the 64-bit ISA, SPARCv9) is
used by just *one* CPU that is modern -- "Leon". The remaining CPUs are all
64-bit since 1997. However, a 32-bit *ABI* (note ABI, NOT ISA) used on a v9
platform seems like a sane idea, and that is the current case of Debian and
Solaris. This is because it's absolutely a terrible idea to remove a 32-bit
ABI for v9 CPUs. This ABI is called "v8+", which incidentally is a terrible
name.

I don't care if Debian or other upstream packages drops "sparc32" aka "v8"
support, because the current kernel will only boot on SPARCv9 CPUs, so it
doesn't make any sense to add a constraint that "binaries must run on v8
CPUs". And I mostly don't care if GCC removes the ability to generate
"sparc32" aka "SPARCv8" code. What I *do* care about it the removal of the
ability to build 32-bit binaries on SPARCv9, because 64-bit only binaries
is a ridiculous idea.

So Jurij, I don't see any reason to believe that "upstream support is
disappearing". None of the messages are from GCC maintainers directly, and
nothing on GCC's website about 4.7 / 4.8 states this to be the case.

Patrick

Re: Sparc status ?

[Patrick Baggett]

>
>
> Because GCC maintainers have been saying for years, that they are
> unwilling to support the weird use case of Debian sparc port, which has
> 64-bit kernel but 32-bit userspace. I can find discussions about it going
> back as far as 2009:
>
> https://lists.debian.org/debian-sparc/2009/08/msg00010.html
>
>
This is a weak case. I have 64-bit MIPS hardware running debian and it
doesn't seem to matter to anyone that the userspace is 32-bit, though the
kernel is 64-bit and I can also run 64-bit MIPS binaries on it.

GCC is also used on Solaris/SPARC which has a 64-bit kernel and 32-bit
userland.

I just don't buy the "debian sparc is a [uniquely] weird use case". It's
not even unique to Debian, and it's not even unique to SPARC.

Patrick

Re: Sparc status ?

[Patrick Baggett]

>
>
> I don't understand, there is no warning of abi or architecture deprecation
> in the release notes of gcc, neither 4.7 nor 4.8.
> Maybe they have information I don't, but I doubt it. I'll dig in the gcc
> mailing list to see if I can find something related.
>
> Sébastien
>

Doh, beat me to it by a minute. Yeah, you see what I mean. :)

It would be platform suicide to drop 32-bit code generation. Like many RISC
architectures, switching to 64-bit is only done for apps that need it,
because it is not free and will not, in general, make apps faster. Anyone
who has worked on PPC, MIPS, SPARC, etc will be able to confirm this in a
heartbeat, and no doubt gcc-sparc maintainers are aware of this as well.

Patrick

Re: Sparc status ?

[Patrick Baggett]

Yeah, I understand why you would believe that. I'm not blaming you, I just
want to let everyone know the sentence "32-bit code generation as we use it
is no longer supported upstream" is incorrect. You can see on the GCC 4.7
[1] and 4.8 [2] changes list that removing any SPARC code generation
features is NOT mentioned. In fact, the only SPARC related change was GCC
4.7 dropping Solaris 8, which has been EOL for a long time.

There is no need to switch to a 64-bit userland. I can already build both
32-bit and 64-bit apps on my system, right now.

[1] http://gcc.gnu.org/gcc-4.7/changes.html
[2] http://gcc.gnu.org/gcc-4.8/changes.html


On Fri, Apr 18, 2014 at 11:35 AM, Sébastien Bernard wrote:

>  Le 18/04/2014 14:16, Patrick Baggett a écrit :
>
> I really don't understand why this "32-bit gone" myth is happening. It was
> poor wording at least. Debian doesn't even support the ancient 32-bit sparc
> CPUs. Modern SPARC ABIs (post 1997) require 64-bit CPUs even when running
> in 32-bit code, it's like x32 ABI in x86 land.
>
>  SPARCv7, SPARCv8 = old 32-bit CPUs, Linux kernel barely supports them now
> SPARCv9 = modern (post 1997) 64-bit CPUs, Linux and GCC supports them just
> fine.
>
>  And just so we can finally kill this rumor dead:
>
>
> http://gcc.gnu.org/onlinedocs/gcc-4.8.2/gcc/SPARC-Options.html#SPARC-Options
>
>  GCC still supports the 32-bit ABI:
>
>  With -mv8plus, GCC generates code for the SPARC-V8+ ABI. The difference
> from the V8 ABI is that the global and out registers are considered 64 bits
> wide. This is enabled by default on Solaris in 32-bit mode for all SPARC-V9
> processors.
>
>
> So no, you don't need to rebuild everything as 64-bit binaries, or should
> I say, rebuild under LP64 model. That wouldn't even make sense and would
> hurt performance. Please refer anyone who believes this to this message.
>
>  Patrick
>
>>
>>   So, if I have understood correctly, the main problem is that 32bit
>> compilation is not supported in the current releases of gcc ?
>> Going to 64bit userland is a huge leap forward.
>> For the second one, I wonder. I've been able to run 3.13 kernel on my
>> V240 hardware and I thing it's recent enough.
>> I have no clue why is it marked oldkernel something related to the buildd
>> ?
>>
>> Seb
>>
>>
>>
>> --
>> To UNSUBSCRIBE, email to debian-sparc-requ...@lists.debian.org
>> with a subject of "unsubscribe". Trouble? Contact
>> listmas...@lists.debian.org
>>  Archive: https://lists.debian.org/5350e5e0.1090...@nerim.net
>>
>>
>  Maybe it was poor understanding by my side. I read the
> https://release.debian.org/jessie/arch_qualify.html and at the bottom
> line, there is this mention of this :
> > sparc > Upstream Support
>
> > According to the gcc maintainer 32bit code generation as we use it is no
> longer supported upstream and we should aim for > a switch to 64bit
> userland anytime soon.
> This is quite clear, and maybe plain wrong according to you.
> This seems to prevent switch from gcc 4.6 to gcc 4.8.
>
> Seb
>
>

Re: Sparc status ?

[Patrick Baggett]

I really don't understand why this "32-bit gone" myth is happening. It was
poor wording at least. Debian doesn't even support the ancient 32-bit sparc
CPUs. Modern SPARC ABIs (post 1997) require 64-bit CPUs even when running
in 32-bit code, it's like x32 ABI in x86 land.

SPARCv7, SPARCv8 = old 32-bit CPUs, Linux kernel barely supports them now
SPARCv9 = modern (post 1997) 64-bit CPUs, Linux and GCC supports them just
fine.

And just so we can finally kill this rumor dead:

http://gcc.gnu.org/onlinedocs/gcc-4.8.2/gcc/SPARC-Options.html#SPARC-Options

GCC still supports the 32-bit ABI:

With -mv8plus, GCC generates code for the SPARC-V8+ ABI. The difference
from the V8 ABI is that the global and out registers are considered 64 bits
wide. This is enabled by default on Solaris in 32-bit mode for all SPARC-V9
processors.


So no, you don't need to rebuild everything as 64-bit binaries, or should I
say, rebuild under LP64 model. That wouldn't even make sense and would hurt
performance. Please refer anyone who believes this to this message.

Patrick


On Fri, Apr 18, 2014 at 3:44 AM, Sébastien Bernard wrote:

> Le 18/04/2014 06:56, Joost van Baal-Ilić a écrit :
>
>  I'd guess skilled hacker time is more needed than hardware. Reading
>> https://release.debian.org/jessie/arch_qualify.html , it seems major
>> blocking issues are: "Using gcc-4.6 as default compiler" and "Have to run
>> oldstable kernels". Related to this: only 1 porter, only partial upstream
>> support. Bye, Joost - who'd _love_ to have a fully supported Debian on
>> sparc
>>
> So, if I have understood correctly, the main problem is that 32bit
> compilation is not supported in the current releases of gcc ?
> Going to 64bit userland is a huge leap forward.
> For the second one, I wonder. I've been able to run 3.13 kernel on my V240
> hardware and I thing it's recent enough.
> I have no clue why is it marked oldkernel something related to the buildd ?
>
> Seb
>
>
>
> --
> To UNSUBSCRIBE, email to debian-sparc-requ...@lists.debian.org
> with a subject of "unsubscribe". Trouble? Contact
> listmas...@lists.debian.org
> Archive: https://lists.debian.org/5350e5e0.1090...@nerim.net
>
>

Re: Problem with sunvdc driver in Solaris 11 LDOM installation

[Patrick Baggett]

Hi Claas,

Welcome to the Debian SPARC mailing list! I think LDOMs are poorly
supported by Debian and perhaps Linux in general. If you search "debian
sparc ldom" in Google, there are a hits about various problems, but one
statement [1] in particular sums up what I thought: "current state of linux
in LDOMs currently is unusable." I'm actually surprised that you managed to
get it installed at all. That's cool.

I'm not 100% sure where you should raise a bug, but Linux sparc kernel
mailing list might be a better place for a driver issue. As a different
question, if you have Solaris installed into an LDOM, does it report the
correct size for the same disk? That is -- is there a problem with the LDOM
software and ISO images, or is there a problem with the Linux driver --
being certain of that would also be really helpful for the kernel
developers.

Patrick

[1] https://lists.debian.org/debian-sparc/2013/12/msg00015.html





On Tue, Apr 8, 2014 at 8:02 AM,  wrote:

> Hi everyone,
>
> this is my first post to this list so please be kind with me... :-)
>
> I tried to install Debian sparc 7.4.0 in a Solaris LDOM.
> Because i am behind a corporate firewall the network install was no option.
>
> When i tried to mount the cdrom after modprobing sunvdc i recognize in
> dmesg
> that all the iso-images Solaris exports as virtualized CD/DVD drives are
> _exactly_
> 640MB even if its a DVD.iso. With the hard disk images exported as
> virtualized
> HDDs this is not the case.
>
> So my workaround was to copy all the iso image contents on a HDD image and
> install from there.
>
> 1. Can anybody confirm this (or is this even a known bug? i didnt find
> anything on Google though).
> 2. If it is a Bug, where is the appropriate location to raise it?
>
> Thanks in advance,
>
> Claas Ziemke
>
> p.s. i can post dmesg output etc. of-course, just didnt want to spam the
> list with my first post :-)
>
> --
>
> ESA - European Space Agency
>
> Claas Ziemke
> Young Graduate Trainee
> Software Systems Division | TEC-SWG
>
> ESTEC
> Keplerlaan 1, PO Box 299
> NL-2200 AG Noordwijk, The Netherlands
> Room Ef232
> claas.zie...@esa.int | www.esa.int
> T +31 71 565 8759
>
> This message and any attachments are intended for the use of the addressee or 
> addressees only.
> The unauthorised disclosure, use, dissemination or copying (either in whole 
> or in part) of its
> content is not permitted.
> If you received this message in error, please notify the sender and delete it 
> from your system.
> Emails can be altered and their integrity cannot be guaranteed by the sender.
>
> Please consider the environment before printing this email.
>
>

Re: lnav/0.7.0-2: FTBFS on mips, powerpc, s390x and sparc

[Patrick Baggett]

Seems like a tiny fix, as mentioned by the owner "tstack" in
"line_buffer.cc(185)". Upstream should be able to do this easily.

this->lb_file_time = *((int32_t *)&gz_id[4]);

should be something to the effect of:

this->lb_file_time = (gz_id[4]) | (gz_id[5] << 8) | (gz_id[6] << 16) | (
gz_id[7] << 24);

to reassemble the 32-bit value regardless of native byte order. Also, it
will removing the warning from type-punning that happens when you
do *((int32_t *)&something);


On Wed, Apr 2, 2014 at 2:53 PM, Salvatore Bonaccorso wrote:

> Dear mips, powerpc, s390x and sparc porters
>
> (Please CC me on replies as I'm not subscribed to the port
> mailinglist).
>
> I'm contancting your porter lists as I have a FTBFS which seems
> specific to the big endian architecture.
>
>  [1] https://buildd.debian.org/status/package.php?p=lnav
>
> Upstream has pointed me in his comment in [2] in some direction to be
> investigated.
>
>  [2] https://github.com/tstack/lnav/issues/93
>
> Can some of you help me with this issue? Thanks in advance already.
>
> Regards,
> Salvatore
>
>
> --
> To UNSUBSCRIBE, email to debian-sparc-requ...@lists.debian.org
> with a subject of "unsubscribe". Trouble? Contact
> listmas...@lists.debian.org
> Archive: https://lists.debian.org/20140402195325.GA30197@eldamar.local
>
>

Re: MySQL on T2000

[Patrick Baggett]

I think you misunderstand the compiler option, which is fine, because it
applies to Solaris. Because accessing unaligned memory raises a hardware
error which forces a kernel context switch, you can mitigate the risk of
this by assuming that any k-aligned object is actually only j-aligned, j <
k, and perform k / j loads instead. This reduces performance compared to a
full k-sized load, but it's better than nothing. You correctly understood
this part -- HOWEVER, if you STILL get an unaligned load error, the kernel
can transparently handle this for you if you opt-in. Most likely if you're
developing new code, you will opt-out, because it's better to find
performance issues like this while still developing, but if you inherit x86
code that does terrible things, then it may save developer time to just
save "whatever, just emulate it". In such a case, you will generate a
hardware trap, but the process will not get a SIGBUS -- the difference is
subtle but important. Again, this is a feature of Solaris/SPARC -- using
-xmemalign[n]i

The point of my previous post was to show that the default Linux behavior
(for me) was (in kernel mode) to simple emulate the load with multiple
smaller loads. I wouldn't be surprised if there was a way to enable
unaligned load fixups automatically in Linux -- probably a kernel option or
runtime configuration. Short version -> Not getting SIGBUS is NOT proof
that unaligned loads are not happening.

Patrick


On Fri, Jan 31, 2014 at 3:59 PM, brian m. carlson <
sand...@crustytoothpaste.net> wrote:

> On Fri, Jan 31, 2014 at 03:50:37PM -0600, Patrick Baggett wrote:
> > Yes, it does [1], and so does Solaris using SunPro CC using -xmemalign
> [2]
>
> Okay, what's happening here is that someone is forcing the compiler to
> generate multiple aligned loads for pointers that are not properly
> aligned, so that an unaligned load doesn't happen.  In the first case,
> that's because the kernel has functions to mark where unaligned accesses
> would otherwise occur.
>
> Regardless, if userland tries to perform an unaligned load, the process
> will get a SIGBUS.
>
> --
> brian m. carlson / brian with sandals: Houston, Texas, US
> +1 832 623 2791 | http://www.crustytoothpaste.net/~bmc | My opinion only
> OpenPGP: RSA v4 4096b: 88AC E9B2 9196 305B A994 7552 F1BA 225C 0223 B187
>

Re: MySQL on T2000

[Patrick Baggett]

Yes, it does [1], and so does Solaris using SunPro CC using -xmemalign [2]



[1] http://lists.freedesktop.org/archives/nouveau/2013-March/012435.html
[2] https://blogs.oracle.com/d/entry/the_meaning_of_xmemalign


On Fri, Jan 31, 2014 at 3:39 PM, brian m. carlson <
sand...@crustytoothpaste.net> wrote:

> On Thu, Jan 30, 2014 at 10:24:13PM +1100, Stewart Smith wrote:
> > What doesn't help is that unaligned memory accesses abound in the MySQL
> > server (I once switched the GCC flags for generating code to handle
> > unaligned access... urgh)
>
> It isn't clear to me what you mean by "handle unaligned access", since
> unaligned access always causes a SIGBUS on SPARC.  To my knowledge,
> there is no option to fix up unaligned accesses in the kernel like there
> is on Alpha and ARM, so they're always fatal.  I'm pretty sure that
> Oracle would have noticed if MySQL died frequently on SPARC.
>
> --
> brian m. carlson / brian with sandals: Houston, Texas, US
> +1 832 623 2791 | http://www.crustytoothpaste.net/~bmc | My opinion only
> OpenPGP: RSA v4 4096b: 88AC E9B2 9196 305B A994 7552 F1BA 225C 0223 B187
>

Re: MySQL on T2000

[Patrick Baggett]

Well, if you get time (and have a recentish version of gcc), try:

CFLAGS = "-O2 -mcpu=niagra -mtune=niagra -flto"
CXXFLAGS = CFLAGS
LDFLAGS = "-flto"

I would try with gcc-4.8 or something.

You can always test to see if your CFLAGS are being completely ignored by
adding "--break-my-build" or something that causes gcc to error out. Of
course, this won't help if the command line looks like "-O2 -mcpu=niagra
-mtune=niagra -flto -O0 -g", i.e. someone appends their own options that
override yours. A lot of older benchmarks suggest that Sun/Oracle's C/C++
compiler produces the best code, but that may be moot now-a-days.

Patrick


On Tue, Jan 28, 2014 at 11:04 AM, Chris Lawrence  wrote:

> The only CFLAGS set are '-mtune=niagara' (though I did make an attempt
> adding -O3 just to see if a difference, there was not).  Appears to
> not be any LDFLAGS set either (CXXFLAGS is null as well).
>
> I am only 60-70% sure I am gathering that information correctly
> however (looking in the CMakeCache.txt file, and looking at
> environment variables), I generally don't do a lot of compiling, at
> least not in the past 8-10 years so I'm a bit rusty.
>
> On Tue, Jan 28, 2014 at 10:58 AM, Patrick Baggett
>  wrote:
> > Chris, would you mind posting your C/CXXFLAGS and LDFLAGS?
> >
> > Patrick
> >
> >
> > On Tue, Jan 28, 2014 at 10:55 AM, Chris Lawrence 
> wrote:
> >>
> >> Greetings:
> >>
> >> Based on some of the discussion so far in this thread
> >> (which thank you all by the way for your input!) has led me down some
> >> holes I was afraid to go down (building from source).  I'm not averse
> >> to it for technical reasons, just.. its a time consumer. :)  In any case
> >> I did run some tests on the box, building MySQL from source with a
> >> variety of -mtune attempts (niagara, niagara2/3, etc), and
> >> interestingly enough all of those attempts yielded a system that
> >> actually was _slower_ than the 'stock' binaries distributed with
> >> Debian SPARC (Wheezy).
> >>
> >> I am currently attempting a MariaDB build on the machine, but have
> >> been running into some compile-time errors (I'm not very experienced
> >> in porting to different architectures), as I was unable to find any
> >> binaries of MariaDB (hoping its claims of faster/better would apply
> >> here).
> >>
> >> I'll drop a reply if I ever get Maria built and see a difference.
> >> Thanks again for all the input, much appreciated!
> >>
> >> Regards,
> >>
> >> Chris
> >>
> >> On Tue, Jan 28, 2014 at 4:19 AM, Rainer Herbst
> >>  wrote:
> >> > Single thread performance of the T2000 is definatly lower than of x86
> >> > hardware, but a factor of 30 is to high. I would have expected factor
> >> > 3-4,
> >> > maybe 10.
> >> >
> >> > We use a T2000 for LDAP and MySQL server in Solaris 10 LDOMs, and the
> >> > system
> >> > perform reasonably well.
> >> >
> >> >
> >> >
> >> > Mit freundlichen Grüßen,
> >> >
> >> > Rainer Herbst
> >> > Zentrale Einrichtung für Informations-
> >> > verarbeitung und Kommunikation (ZEIK)
> >> > Universität Potsdam
> >> > Am Neuen Palais 10, Haus 8, Zimmer 0.70a
> >> > 14469 Potsdam
> >> > Tel. 0331 - 977 1039
> >> >
> >> >
> >> > Quoting Patrick Baggett :
> >> >
> >> >> Just from reading others' questions and answers over the web, I
> >> >> wouldn't
> >> >> be
> >> >> surprised if that was the case, especially if you are doing anything
> >> >> that
> >> >> needs an FPU in there. Also IIRC, they are in-order CPUs, which means
> >> >> having proper compiler flags will make a difference. Stock MySQL from
> >> >> Debian probably doesn't have any special flags applied, whereas you'd
> >> >> probably want "-mtune=niagara".
> >> >>
> >> >> I'm interested in finding out the answer as well -- I've considering
> >> >> picking up a used T2-based, which has similar characteristics, since
> >> >> they
> >> >> are down to a few hundred dollars.
> >> >>
> >> >> Patrick
> >> >>
> >> >>
> >> >>
> >> >>
> >> >>

Re: MySQL on T2000

[Patrick Baggett]

Chris, would you mind posting your C/CXXFLAGS and LDFLAGS?

Patrick


On Tue, Jan 28, 2014 at 10:55 AM, Chris Lawrence  wrote:

> Greetings:
>
> Based on some of the discussion so far in this thread
> (which thank you all by the way for your input!) has led me down some
> holes I was afraid to go down (building from source).  I'm not averse
> to it for technical reasons, just.. its a time consumer. :)  In any case
> I did run some tests on the box, building MySQL from source with a
> variety of -mtune attempts (niagara, niagara2/3, etc), and
> interestingly enough all of those attempts yielded a system that
> actually was _slower_ than the 'stock' binaries distributed with
> Debian SPARC (Wheezy).
>
> I am currently attempting a MariaDB build on the machine, but have
> been running into some compile-time errors (I'm not very experienced
> in porting to different architectures), as I was unable to find any
> binaries of MariaDB (hoping its claims of faster/better would apply
> here).
>
> I'll drop a reply if I ever get Maria built and see a difference.
> Thanks again for all the input, much appreciated!
>
> Regards,
>
> Chris
>
> On Tue, Jan 28, 2014 at 4:19 AM, Rainer Herbst
>  wrote:
> > Single thread performance of the T2000 is definatly lower than of x86
> > hardware, but a factor of 30 is to high. I would have expected factor
> 3-4,
> > maybe 10.
> >
> > We use a T2000 for LDAP and MySQL server in Solaris 10 LDOMs, and the
> system
> > perform reasonably well.
> >
> >
> >
> > Mit freundlichen Grüßen,
> >
> > Rainer Herbst
> > Zentrale Einrichtung für Informations-
> > verarbeitung und Kommunikation (ZEIK)
> > Universität Potsdam
> > Am Neuen Palais 10, Haus 8, Zimmer 0.70a
> > 14469 Potsdam
> > Tel. 0331 - 977 1039
> >
> >
> > Quoting Patrick Baggett :
> >
> >> Just from reading others' questions and answers over the web, I wouldn't
> >> be
> >> surprised if that was the case, especially if you are doing anything
> that
> >> needs an FPU in there. Also IIRC, they are in-order CPUs, which means
> >> having proper compiler flags will make a difference. Stock MySQL from
> >> Debian probably doesn't have any special flags applied, whereas you'd
> >> probably want "-mtune=niagara".
> >>
> >> I'm interested in finding out the answer as well -- I've considering
> >> picking up a used T2-based, which has similar characteristics, since
> they
> >> are down to a few hundred dollars.
> >>
> >> Patrick
> >>
> >>
> >>
> >>
> >> On Mon, Jan 27, 2014 at 1:35 PM, Chris Lawrence 
> wrote:
> >>
> >>> Greetings:
> >>>
> >>> I have been gifted a Sun T2000 from my employer as a hand-me-down
> >>> piece of hardware.  I have had plenty of experience using it as a
> >>> Solaris 10 box, and we generally ran Oracle and our in-house products
> >>> on the hardware with good results.
> >>>
> >>> After getting the hardware, without a Sun contract I went with Debian,
> >>> which was fine as my expertise/background is more heavily Linux than
> >>> Solaris anyways.
> >>>
> >>> After a lot of tinkering I got the system as I liked it, prepared to
> >>> host several LXC containers, separated as database and web servers for
> >>> a project for my friend's gaming website.  All went well, until I
> >>> started working with MySQL.  I started noticing significant
> >>> differences in performance, and, I went down the rabbit hole to find
> >>> plenty of articles talking about how MySQL doesn't run well on The
> >>> T2000's due to single threadedness sort of reasons.
> >>>
> >>> I've done a good amount of fine tuning of the database, but I'm
> >>> finding any query of complexity taking sometimes as much as 30x longer
> >>> to execute than on same-era x86 hardware running Debian.
> >>>
> >>> I am really just trying to figure out if I'm wasting my time by trying
> >>> to 'fix' this, or if its a reality of the hardware platform.  Even
> >>> simple 'select BENCHMARK' queries are returning back after 25-30
> >>> seconds, whereas on the x86 box it comes back in 1-2 seconds.
> >>>
> >>> Is MySQL on this hardware platform a lost cause, or am I missing
> >>> something obvious?
> >>>
> >>> Thanks in advance!
> >>>
> >>> Regards,
> >>>
> >>> Chris
> >>>
> >>>
> >>> --
> >>> To UNSUBSCRIBE, email to debian-sparc-requ...@lists.debian.org
> >>> with a subject of "unsubscribe". Trouble? Contact
> >>> listmas...@lists.debian.org
> >>> Archive:
> >>>
> >>>
> http://lists.debian.org/caouezgjvmyjpmpowtpjvafmpy0uneext3pctwxypanapdlv...@mail.gmail.com
> >>>
> >>>
> >>
> >
> >
>
>
> --
> To UNSUBSCRIBE, email to debian-sparc-requ...@lists.debian.org
> with a subject of "unsubscribe". Trouble? Contact
> listmas...@lists.debian.org
> Archive:
> http://lists.debian.org/caouezgkkvfeo_6wocjhmtwt0nots3hhq-bpjkdzmvfmvqtg...@mail.gmail.com
>
>

Re: MySQL on T2000

[Patrick Baggett]

Just from reading others' questions and answers over the web, I wouldn't be
surprised if that was the case, especially if you are doing anything that
needs an FPU in there. Also IIRC, they are in-order CPUs, which means
having proper compiler flags will make a difference. Stock MySQL from
Debian probably doesn't have any special flags applied, whereas you'd
probably want "-mtune=niagara".

I'm interested in finding out the answer as well -- I've considering
picking up a used T2-based, which has similar characteristics, since they
are down to a few hundred dollars.

Patrick




On Mon, Jan 27, 2014 at 1:35 PM, Chris Lawrence  wrote:

> Greetings:
>
> I have been gifted a Sun T2000 from my employer as a hand-me-down
> piece of hardware.  I have had plenty of experience using it as a
> Solaris 10 box, and we generally ran Oracle and our in-house products
> on the hardware with good results.
>
> After getting the hardware, without a Sun contract I went with Debian,
> which was fine as my expertise/background is more heavily Linux than
> Solaris anyways.
>
> After a lot of tinkering I got the system as I liked it, prepared to
> host several LXC containers, separated as database and web servers for
> a project for my friend's gaming website.  All went well, until I
> started working with MySQL.  I started noticing significant
> differences in performance, and, I went down the rabbit hole to find
> plenty of articles talking about how MySQL doesn't run well on The
> T2000's due to single threadedness sort of reasons.
>
> I've done a good amount of fine tuning of the database, but I'm
> finding any query of complexity taking sometimes as much as 30x longer
> to execute than on same-era x86 hardware running Debian.
>
> I am really just trying to figure out if I'm wasting my time by trying
> to 'fix' this, or if its a reality of the hardware platform.  Even
> simple 'select BENCHMARK' queries are returning back after 25-30
> seconds, whereas on the x86 box it comes back in 1-2 seconds.
>
> Is MySQL on this hardware platform a lost cause, or am I missing
> something obvious?
>
> Thanks in advance!
>
> Regards,
>
> Chris
>
>
> --
> To UNSUBSCRIBE, email to debian-sparc-requ...@lists.debian.org
> with a subject of "unsubscribe". Trouble? Contact
> listmas...@lists.debian.org
> Archive:
> http://lists.debian.org/caouezgjvmyjpmpowtpjvafmpy0uneext3pctwxypanapdlv...@mail.gmail.com
>
>

Re: [Need HELP!] Please help to test kernel patch (sparc64, NUMA)

[Patrick Baggett]

Kirill,

I copied the contents of your email into a patch file, and when I did git
apply --check, it didn't really work:

figgles@ghost:~/sparc-numa/sparc$ git apply --check numa.patch
error: patch failed: arch/sparc/include/asm/trap_block.h:138
error: arch/sparc/include/asm/trap_block.h: patch does not apply
error: patch failed: arch/sparc/kernel/smp_64.c:285
error: arch/sparc/kernel/smp_64.c: patch does not apply
error: patch failed: arch/sparc/kernel/trampoline_64.S:117
error: arch/sparc/kernel/trampoline_64.S: patch does not apply
error: patch failed: arch/sparc/mm/init_64.c:591
error: arch/sparc/mm/init_64.c: patch does not apply

I'm probably doing something dumb, so let me know what I need to change. ;)

Patrick



On Wed, Dec 4, 2013 at 3:56 AM, Kirill Tkhai  wrote:

> Hi,
>
> I'm looking for a person who has sparc64 machine with NUMA. The patch
> below adds
> NUMA kernel text replication support. This should improve sparc64 kernel
> performance
> a little bit.
>
> I tested it on my machines, and it looks working for me. But they are not
> standard
> sun v9. So person with standard vanila-supported machine is seeked!
>
> Is anybody able to help me?
>
> It's necessary to 1)clone David Miller's git tree:
>
> git clone --depth=1 git://
> git.kernel.org/pub/scm/linux/kernel/git/davem/sparc.git
>
> 2)apply the patch and 3)do not forget to enable CONFIG_NUMA in
> xconfig/menuconfig.
>
> The following actions is to do a boot test. If everything is OK, I'll be
> very thankful
> if you're able to execute any short performance test: before patch and
> with it.
>
> Thanks!
>
> Signed-off-by: Kirill Tkhai 
> ---
>  arch/sparc/include/asm/page_64.h|3 +
>  arch/sparc/include/asm/pgtable_64.h |6 ++
>  arch/sparc/include/asm/trap_block.h |   17 ++
>  arch/sparc/kernel/smp_64.c  |8 ++-
>  arch/sparc/kernel/trampoline_64.S   |   46 ++---
>  arch/sparc/mm/init_64.c |   94
> ++-
>  arch/sparc/mm/init_64.h |2 +-
>  7 files changed, 163 insertions(+), 13 deletions(-)
> diff --git a/arch/sparc/include/asm/page_64.h
> b/arch/sparc/include/asm/page_64.h
> index aac53fc..5a85352 100644
> --- a/arch/sparc/include/asm/page_64.h
> +++ b/arch/sparc/include/asm/page_64.h
> @@ -8,6 +8,9 @@
>  #define PAGE_SIZE(_AC(1,UL) << PAGE_SHIFT)
>  #define PAGE_MASK(~(PAGE_SIZE-1))
>
> +#define PAGE4MB_SHIFT  22
> +#define PAGE4MB_SIZE   (_AC(1,UL) << PAGE4MB_SHIFT)
> +
>  /* Flushing for D-cache alias handling is only needed if
>   * the page size is smaller than 16K.
>   */
> diff --git a/arch/sparc/include/asm/pgtable_64.h
> b/arch/sparc/include/asm/pgtable_64.h
> index 8358dc1..0b0495f 100644
> --- a/arch/sparc/include/asm/pgtable_64.h
> +++ b/arch/sparc/include/asm/pgtable_64.h
> @@ -884,6 +884,12 @@ extern pmd_t swapper_low_pmd_dir[PTRS_PER_PMD];
>  extern void paging_init(void);
>  extern unsigned long find_ecache_flush_span(unsigned long size);
>
> +#ifdef CONFIG_NUMA
> +extern void numa_copy_kernel_text(void);
> +#else
> +static inline void numa_copy_kernel_text(void) {}
> +#endif
> +
>  struct seq_file;
>  extern void mmu_info(struct seq_file *);
>
> diff --git a/arch/sparc/include/asm/trap_block.h
> b/arch/sparc/include/asm/trap_block.h
> index 7e26b2d..a2f0990 100644
> --- a/arch/sparc/include/asm/trap_block.h
> +++ b/arch/sparc/include/asm/trap_block.h
> @@ -138,6 +138,23 @@ extern struct sun4v_2insn_patch_entry
> __sun4v_2insn_patch,
> nop;\
> .previous;
>
> +#ifdef CONFIG_NUMA
> +
> +#define __GET_NODEID(REG, TMP) \
> +   __GET_CPUID(REG)\
> +   sethi   %hi(numa_cpu_lookup_table), TMP;\
> +   or  TMP, %lo(numa_cpu_lookup_table), TMP;   \
> +   sllxREG, 2, REG;\
> +   add TMP, REG, TMP;  \
> +   lduw[TMP], REG;
> +
> +#else /* !CONFIG_NUMA */
> +
> +#define __GET_NODEID(REG, TMP) \
> +   clr REG
> +
> +#endif /* !CONFIG_NUMA */
> +
>  #ifdef CONFIG_SMP
>
>  #define TRAP_LOAD_TRAP_BLOCK(DEST, TMP)\
> diff --git a/arch/sparc/kernel/smp_64.c b/arch/sparc/kernel/smp_64.c
> index b66a533..554a0c5 100644
> --- a/arch/sparc/kernel/smp_64.c
> +++ b/arch/sparc/kernel/smp_64.c
> @@ -285,7 +285,7 @@ static void ldom_startcpu_cpuid(unsigned int cpu,
> unsigned long thread_reg,
> void **descrp)
>  {
> extern unsigned long sparc64_ttable_tl0;
> -   extern unsigned long kern_locked_tte_data;
> +   extern unsigned long kern_locked_tte_data[MAX_NUMNODES];
> struct hvtramp_descr *hdesc;
> unsigned long trampoline_ra;
> struct trap_per_cpu *tb;
> @@ -315,7 +315,7 @@ static void ldom_startcpu_cpuid(unsigned int cpu,
> unsigned long thread_reg,
> hdesc->thread_reg = thread_reg;
>
>   

Re: [Need HELP!] Please help to test kernel patch (sparc64, NUMA)

[Patrick Baggett]

OK, I have a Sun Blade 2500 (2x UltraSPARC III) I can use to test. I'll try
to get to this this weekend.

Patrick


On Wed, Dec 4, 2013 at 3:56 AM, Kirill Tkhai  wrote:

> Hi,
>
> I'm looking for a person who has sparc64 machine with NUMA. The patch
> below adds
> NUMA kernel text replication support. This should improve sparc64 kernel
> performance
> a little bit.
>
> I tested it on my machines, and it looks working for me. But they are not
> standard
> sun v9. So person with standard vanila-supported machine is seeked!
>
> Is anybody able to help me?
>
> It's necessary to 1)clone David Miller's git tree:
>
> git clone --depth=1 git://
> git.kernel.org/pub/scm/linux/kernel/git/davem/sparc.git
>
> 2)apply the patch and 3)do not forget to enable CONFIG_NUMA in
> xconfig/menuconfig.
>
> The following actions is to do a boot test. If everything is OK, I'll be
> very thankful
> if you're able to execute any short performance test: before patch and
> with it.
>
> Thanks!
>
> Signed-off-by: Kirill Tkhai 
> ---
>  arch/sparc/include/asm/page_64.h|3 +
>  arch/sparc/include/asm/pgtable_64.h |6 ++
>  arch/sparc/include/asm/trap_block.h |   17 ++
>  arch/sparc/kernel/smp_64.c  |8 ++-
>  arch/sparc/kernel/trampoline_64.S   |   46 ++---
>  arch/sparc/mm/init_64.c |   94
> ++-
>  arch/sparc/mm/init_64.h |2 +-
>  7 files changed, 163 insertions(+), 13 deletions(-)
> diff --git a/arch/sparc/include/asm/page_64.h
> b/arch/sparc/include/asm/page_64.h
> index aac53fc..5a85352 100644
> --- a/arch/sparc/include/asm/page_64.h
> +++ b/arch/sparc/include/asm/page_64.h
> @@ -8,6 +8,9 @@
>  #define PAGE_SIZE(_AC(1,UL) << PAGE_SHIFT)
>  #define PAGE_MASK(~(PAGE_SIZE-1))
>
> +#define PAGE4MB_SHIFT  22
> +#define PAGE4MB_SIZE   (_AC(1,UL) << PAGE4MB_SHIFT)
> +
>  /* Flushing for D-cache alias handling is only needed if
>   * the page size is smaller than 16K.
>   */
> diff --git a/arch/sparc/include/asm/pgtable_64.h
> b/arch/sparc/include/asm/pgtable_64.h
> index 8358dc1..0b0495f 100644
> --- a/arch/sparc/include/asm/pgtable_64.h
> +++ b/arch/sparc/include/asm/pgtable_64.h
> @@ -884,6 +884,12 @@ extern pmd_t swapper_low_pmd_dir[PTRS_PER_PMD];
>  extern void paging_init(void);
>  extern unsigned long find_ecache_flush_span(unsigned long size);
>
> +#ifdef CONFIG_NUMA
> +extern void numa_copy_kernel_text(void);
> +#else
> +static inline void numa_copy_kernel_text(void) {}
> +#endif
> +
>  struct seq_file;
>  extern void mmu_info(struct seq_file *);
>
> diff --git a/arch/sparc/include/asm/trap_block.h
> b/arch/sparc/include/asm/trap_block.h
> index 7e26b2d..a2f0990 100644
> --- a/arch/sparc/include/asm/trap_block.h
> +++ b/arch/sparc/include/asm/trap_block.h
> @@ -138,6 +138,23 @@ extern struct sun4v_2insn_patch_entry
> __sun4v_2insn_patch,
> nop;\
> .previous;
>
> +#ifdef CONFIG_NUMA
> +
> +#define __GET_NODEID(REG, TMP) \
> +   __GET_CPUID(REG)\
> +   sethi   %hi(numa_cpu_lookup_table), TMP;\
> +   or  TMP, %lo(numa_cpu_lookup_table), TMP;   \
> +   sllxREG, 2, REG;\
> +   add TMP, REG, TMP;  \
> +   lduw[TMP], REG;
> +
> +#else /* !CONFIG_NUMA */
> +
> +#define __GET_NODEID(REG, TMP) \
> +   clr REG
> +
> +#endif /* !CONFIG_NUMA */
> +
>  #ifdef CONFIG_SMP
>
>  #define TRAP_LOAD_TRAP_BLOCK(DEST, TMP)\
> diff --git a/arch/sparc/kernel/smp_64.c b/arch/sparc/kernel/smp_64.c
> index b66a533..554a0c5 100644
> --- a/arch/sparc/kernel/smp_64.c
> +++ b/arch/sparc/kernel/smp_64.c
> @@ -285,7 +285,7 @@ static void ldom_startcpu_cpuid(unsigned int cpu,
> unsigned long thread_reg,
> void **descrp)
>  {
> extern unsigned long sparc64_ttable_tl0;
> -   extern unsigned long kern_locked_tte_data;
> +   extern unsigned long kern_locked_tte_data[MAX_NUMNODES];
> struct hvtramp_descr *hdesc;
> unsigned long trampoline_ra;
> struct trap_per_cpu *tb;
> @@ -315,7 +315,7 @@ static void ldom_startcpu_cpuid(unsigned int cpu,
> unsigned long thread_reg,
> hdesc->thread_reg = thread_reg;
>
> tte_vaddr = (unsigned long) KERNBASE;
> -   tte_data = kern_locked_tte_data;
> +   tte_data = kern_locked_tte_data[0];
>
> for (i = 0; i < hdesc->num_mappings; i++) {
> hdesc->maps[i].vaddr = tte_vaddr;
> @@ -1214,6 +1214,10 @@ int setup_profiling_timer(unsigned int multiplier)
>
>  void __init smp_prepare_cpus(unsigned int max_cpus)
>  {
> +   /* Dublicate kernel on every node. Do this after
> +* all kernel patches are applied.
> +*/
> +   numa_copy_kernel_text();
>  }
>
>  void smp_prepare_boot_cpu(void)
> diff --git a/arch/sparc/kernel/trampoline_64

Re: sparc64 buildd gcc SIGSEGV/SIGBUS?

[Patrick Baggett]

Ah, OK.

So we're talking about a 64-bit `gcc` binary (sparc64 bootstrapped this,
yes?) while I'm running a 32-bit `gcc` that can produce 32/64-bit code.
Since these binaries are fundamentally different, perhaps there is some
weirdness with how gcc works then? Honestly, the whole "sparc64" vs "sparc"
thing is a bit strange to me -- a 64-bit `gcc` will likely run slower than
a 32-bit `gcc`, but that is a bit off-topic (although, I guess 64-bit `gcc`
can help for truly massive projects).

It appears I can't help you if you're testing a 64-bit `gcc` binary. Since
you're not hitting the issue, can you verify that:

1) sompek has a 64-bit gcc
2) you have a 64-bit gcc

I just want to rule out that "64-bitness" matters, since it appears that
you both have identical versions of `gcc`.

Patrick




On Tue, Oct 15, 2013 at 6:12 PM, Steven Gawroriski <
ste...@multiphasicapps.net> wrote:

> On Tue, 15 Oct 2013 12:40:47 -0500
> Patrick Baggett  wrote:
>
> > So this is the "sparc64" version of debian, not "sparc"?
> >
> > The reason I ask is because (IIRC) the default mode in "sparc" is to
> > output 32-bit SPARC code but utilizing the SPARCv9 instructions (i.e.
> > not able to be run on pre-UltraSPARC machines) -- this was done
> > because the "sparc32", i.e. pre-UltraSPARC CPUs, aren't able to run
> > Debian (I think the Linux kernel has fallen into bitrot w.r.t. them)
> > -- while "sparc64" gcc -- I'm not sure what it does. Despite being
> > just "sparc", I can build 64-bit SPARC binaries and execute them
> > (because we're all running 64-bit kernels), but I typically don't
> > have a need to. So with that all mentioned, is the end goal to
> > produce a 64-bit binary or 32-bit binary?
> >
> > Patrick
> >
> >
> > On Tue, Oct 15, 2013 at 12:33 PM, Steven Gawroriski <
> > ste...@multiphasicapps.net> wrote:
> >
> > > On Tue, 15 Oct 2013 11:41:35 -0500
> > > Patrick Baggett  wrote:
> > >
> > > > I can't say that I track failing packages (how does one do this?)
> > > > but stupid question -- are the versions of gcc on your machine and
> > > > sompek(2) identical? What about kernel version (it probably
> > > > doesn't matter, but you never know on some of these RISC ports).
> > > > Also, I'll try to reproduce it locally if you can point me in the
> > > > right direction.
> > > >
> > > > Patrick
> > > >
> > > >
> > > > On Tue, Oct 15, 2013 at 11:23 AM, Steven Gawroriski <
> > > > ste...@multiphasicapps.net> wrote:
> > > >
> > > > > Hello, has anyone else been able to reproduce the SIGSEGV/SIGBUS
> > > > > crashes seen on the sompek/sompek2 buildd servers? When
> > > > > ... Trimmed ...
> > >
> > > Hello,
> > >
> > > ... Trimmed ...
> > >
> > > My Kernel: Linux sparc64-a 3.11.4 #1 SMP Thu Oct 10 11:07:55 EDT
> > > 2013 sparc64 GNU/Linux
> > > My GCC: gcc (Debian 4.8.1-9) 4.8.1
> > >
> > > Do not know the kernel that is on sompek (not my machine), however
> > > the GCC it uses is 4.8.1-9, which is the same as mine (it downloads
> > > it before every build). Quite possible the kernel might be a
> > > Debian kernel.
> > >
> > > You can choose a random package and search the log for "internal
> > > compiler error" which would either be the result of a SIGSEGV or
> > > SIGBUS.
> > >
> > >
>
> Hello,
>
> Yes, this is for sparc64 and not sparc.
>
> The goal is for complete 64-bit userspace, where gcc compiles 64-bit
> code by default, rather than 32-bit. Right now sparc would be similar
> to running i386 Debian on an amd64 kernel, you can use lib64 but
> virtually everything defaults to 32-bit. Whereas on an amd64 Debian
> everything defaults to 64-bit, while you can still run 32-bit code.
>
> The build problems on sompek with gcc are either two things:
>
> 1) A problem with GCC
> 2) A problem with the hardware
>
> Without access to the hardware to run extended tests to rule that
> possibility out, the only option left is to test GCC. If GCC is the
> problem, then it would fix everything, everywhere. I only have access
> to a Sun Fire V210 which does not exhibit any problems so far. If a
> system were to be found which has a similar problem with GCC, the best
> action would be to create a shell script to invoke gcc under gdb (with
> automatic run along with exiting if a crash did not occur, however with
> parallel builds one could do some trickery to spawn gdb under screen
> but have gcc output to both screen and stdout/stderr). The build
> process would be frozen until someone checked out the debugging
> session, a core dump would be easy to generate but hard to parse
> (since you'd need the system's debuggable gcc).
>

Re: sparc64 buildd gcc SIGSEGV/SIGBUS?

[Patrick Baggett]

So this is the "sparc64" version of debian, not "sparc"?

The reason I ask is because (IIRC) the default mode in "sparc" is to output
32-bit SPARC code but utilizing the SPARCv9 instructions (i.e. not able to
be run on pre-UltraSPARC machines) -- this was done because the "sparc32",
i.e. pre-UltraSPARC CPUs, aren't able to run Debian (I think the Linux
kernel has fallen into bitrot w.r.t. them) -- while "sparc64" gcc -- I'm
not sure what it does. Despite being just "sparc", I can build 64-bit SPARC
binaries and execute them (because we're all running 64-bit kernels), but I
typically don't have a need to. So with that all mentioned, is the end goal
to produce a 64-bit binary or 32-bit binary?

Patrick


On Tue, Oct 15, 2013 at 12:33 PM, Steven Gawroriski <
ste...@multiphasicapps.net> wrote:

> On Tue, 15 Oct 2013 11:41:35 -0500
> Patrick Baggett  wrote:
>
> > I can't say that I track failing packages (how does one do this?) but
> > stupid question -- are the versions of gcc on your machine and
> > sompek(2) identical? What about kernel version (it probably doesn't
> > matter, but you never know on some of these RISC ports). Also, I'll
> > try to reproduce it locally if you can point me in the right
> > direction.
> >
> > Patrick
> >
> >
> > On Tue, Oct 15, 2013 at 11:23 AM, Steven Gawroriski <
> > ste...@multiphasicapps.net> wrote:
> >
> > > Hello, has anyone else been able to reproduce the SIGSEGV/SIGBUS
> > > crashes seen on the sompek/sompek2 buildd servers? When creating the
> > > packages locally with dpkg-buildpackage I have never encountered a
> > > crash from gcc. I have even built the same failed packages multiple
> > > times, but have not found any crashes.
> > >
> > > This is on a Sun Fire V210, 1.34GHz w/ 8GiB.
> > >
>
> Hello,
>
> You can look at the list on
> http://buildd.debian-ports.org/status/architecture.php?a=sparc64&suite=sid
> under "Build-Attempted". You can choose the package by name, then it
> should show build results in a table. On the row with sparc64 you
> select "all logs", then the result would say "Maybe Failed". You can
> select that, you are then shown the build log, which you can look at the
> reason why it failed. There are no notifications that I know of (and if
> there were, you would get spammed endlessly).
>
> My Kernel: Linux sparc64-a 3.11.4 #1 SMP Thu Oct 10 11:07:55 EDT
> 2013 sparc64 GNU/Linux
> My GCC: gcc (Debian 4.8.1-9) 4.8.1
>
> Do not know the kernel that is on sompek (not my machine), however the
> GCC it uses is 4.8.1-9, which is the same as mine (it downloads it
> before every build). Quite possible the kernel might be a
> Debian kernel.
>
> You can choose a random package and search the log for "internal
> compiler error" which would either be the result of a SIGSEGV or SIGBUS.
>
>

Re: sparc64 buildd gcc SIGSEGV/SIGBUS?

[Patrick Baggett]

I can't say that I track failing packages (how does one do this?) but
stupid question -- are the versions of gcc on your machine and sompek(2)
identical? What about kernel version (it probably doesn't matter, but you
never know on some of these RISC ports). Also, I'll try to reproduce it
locally if you can point me in the right direction.

Patrick


On Tue, Oct 15, 2013 at 11:23 AM, Steven Gawroriski <
ste...@multiphasicapps.net> wrote:

> Hello, has anyone else been able to reproduce the SIGSEGV/SIGBUS
> crashes seen on the sompek/sompek2 buildd servers? When creating the
> packages locally with dpkg-buildpackage I have never encountered a
> crash from gcc. I have even built the same failed packages multiple
> times, but have not found any crashes.
>
> This is on a Sun Fire V210, 1.34GHz w/ 8GiB.
>
>
> --
> To UNSUBSCRIBE, email to debian-sparc-requ...@lists.debian.org
> with a subject of "unsubscribe". Trouble? Contact
> listmas...@lists.debian.org
> Archive:
> http://lists.debian.org/20131015122355.3ccd2cab.ste...@multiphasicapps.net
>
>

Re: Seems I have bad timing with Debian on SPARC.

[Patrick Baggett]

On Wed, Oct 2, 2013 at 4:36 PM, u60 spitfire  wrote:

> Just signed up for this mailing list; had spent a good amount of time
> over the last week getting my Ultra 60 up and running again.  It's
> mostly OK...heh...execpt the part about having to reprogram the darn
> NVRAM every time I turn it on.
>
> I got jessie installed (Didn't get far in the stable release; first
> thing I did was try to open iceweasel and it hit a bus error --
> unaligned mem access maybe).  Working on getting the framebuffer going
> and whatnot now, went to the Debian forums and figured I'd try this
> mailing list after no responses there.
>
> After checking the posts for the last few months (only a handful!),
> they seem all about "Helloanybody out there using/maintaining
> this?"  or "Hey if anyone's using driver X y'all need to maintain it
> yourself 'cause you're the only one using it", heh.
>
>
Linux on SPARC is very niche. Think of yourself as...frontiersmen. Consider
the cases though: you go to Oracle.com and cheap server is $20K. So you can
either use:

a) 100% supported Solaris 11.1, 24x7 phone support, deep virtual machine
support, apps/libraries optimized for the HW, etc.
b) Linux, which may or may not recognize your disk controller and may panic
while booting the kernel on really new machines.


> So, realistically*, what's the deal?  Any point in trying to get this
> to work or should I cut my losses now and move to some other
> distribution or OS?  I had thought that maybe there was some interest
> in the architecture since OpenSPARC was published/available for some
> time.  Anyhow.
>

I think Debian/sparc is probably one of the better distributions for SPARC,
but it can be quite rough, yeah. I run it and I don't have too many
problems. I run it on an Ultra 80, E420R (Ultra 80 but with diff case IIRC)
and a Blade 2500. Neither gives me problems, but running Sun-branded
components is really hard -- Sun was never very forthcoming with HW specs
and even if they had now, there would be little interest in pre-2000 HW to
actually fix the drivers. You can try Solaris 10 if you have a lot of
memory, but you're going to need to customize it, because for playing
around, you probably don't need all of the stuff it installed.

I personally enjoy Linux on SPARC more than Solaris on SPARC because I can
mix cheap PC components in the PCI slots to get some flexibility, so long
as it isn't critical for booting the system [e.g. disk controllers]. I ran
an Ultra 10 with an NV GeForce4 for example and was able to play Quake III.
Not all drivers work that well though, and I've filed a few bugs and other
times just written off the driver as "meh" (for example, some SPARC sound
drivers -- why bother if you can replace with $10 PCI sound card?)

So I guess, I'd say stick with Debian. I think your experience with the
Ultra 60 should be pretty decent overall, though if you need a new NVRAM
battery, yeah, going to suck a bit. :)

If you're having some issues, posted here, and I missed it, I'm sorry. I
try to help when I can. Please let us know what they are and let's see if
we can't work them out.

Patrick


> Advice appreciated in advance.
>
> thanks
>
>
>
> *Yes, I'm not being terribly realistic running anything on this box to
> begin with.
>
>
> --
> To UNSUBSCRIBE, email to debian-sparc-requ...@lists.debian.org
> with a subject of "unsubscribe". Trouble? Contact
> listmas...@lists.debian.org
> Archive:
> http://lists.debian.org/CAN-w9fwQ7=FhaE3R=o7Ehx7ckMm=cfxuyiixinjcchmttbc...@mail.gmail.com
>
>

Re: Results of the porter roll call (Was: Roll call for porters of architectures in sid and testing)

[Patrick Baggett]

I'm interesting in helping on ia64. I'm not fluent in ia64 assembly, but I
can get around pretty well. I'm very experienced in C/C++/Java and
debugging. I've got a fully functional system running Xorg/Mesa3D/sound, so
I can reproduce, test, and fix issues as time permits.

Patrick Baggett


On Wed, Oct 2, 2013 at 2:45 AM, Niels Thykier  wrote:

> Hi,
>
> The final results are in:
>
> Summary table:
> Arch   || DDs || NMs/DMs || Other || Total
> ---++-++-++---++--
> armel  ||  3  ||   0 || 1 ||4
> armhf  ||  3  ||   1 || 2 ||6
> hurd-i386  ||  5  ||   0 || 3 ||8
> ia64   || *0* ||   0 || 3 ||3
> kfreebsd-amd64 ||  4  ||   0 || 2 ||6
> kfreebsd-i386  ||  4  ||   0 || 2 ||6
> mips   ||  1  ||   0 || 1 ||2
> mipsel ||  1  ||   0 || 1 ||2
> powerpc[1] || (1) ||   0 || 2 ||   2.5?
> s390x  || *0* ||   0 || 0 ||   *0*
> sparc[2]   ||  1  ||   0 || 0 ||1
>
> [1] The (1) and .5 is from a "I am not primarily a porter [...]"-remark,
> so I wasn't sure how to count it.
>
> [2] By the looks of it, if sparc was replaced by sparc64, we could be
> looking at 3 in the "Other"-column rather than 0.
>
> NMs/DMs include DMs and people currently in NM process.  The "Other"
> column may include people who said they would like to become porters
> (but would need to be introduced to the job) and thus may imply some
> active recruiting from the current porters.  This is at least true for
> hurd-i386.
>
>
>
> The current policy says that we require "5 developers" (i.e. DDs) for
> release architectures[AP], so based on that only amd64, i386 and
> hurd-i386 would pass this requirement.  It is quite possible we need to
> revise that requirement, but most of the architectures would (still) do
> well to attract a few more (DD) porters.
>   I have attached a file with my notes of who are behind those numbers.
>  If your name is missing or you believe I have miscounted something[CD]
> for an architecture listed in the table above, please reply to this
> email *promptly* (CC'ing me explicitly is fine) with your concerns or
> corrections.
>
> At this time, I have *not* updated the arch qualification table yet.  I
> will do that in a couple of days.  We will also follow up on this in the
> next bits from the release team.
>
> ~Niels
>
> [AP] http://release.debian.org/jessie/arch_policy.html
>
> [CD] I may (or may not) have been caffeine-deprived when I did the
> counting.  You are free to make assumptions about whether that has
> affected my ability to do addic^Htion or parsing your email(s) properly.
>
>

Re: Removing old unmaintained X drivers

[Patrick Baggett]

Off the top of my head, my Sun E3500 (8x 64-bit SPARC CPUs) has an SBUS
graphics adapter that is one of those cg{N} adapters, but honestly, Linux
support for E3500 is shoddy at best, so it's fine by me.

Patrick


On Sat, Sep 28, 2013 at 8:29 AM, Jurij Smakov  wrote:

> On Thu, Sep 26, 2013 at 10:26 PM, Julien Cristau wrote:
>
>> Hi,
>>
>> we (the debian X Strike Force) are thinking of removing the following
>> packages from the archive, unless somebody steps up (soon) to take care
>> of them.  The reason is they see 0 testing, nobody maintains them
>> upstream, if you're lucky people keep some of them building when APIs
>> change, if you're very lucky they get a release with all the build fixes
>> once in a while, and it's likely most of them don't have any users
>> anymore.  While it would probably be easy to get them to stop FTBFS
>> right now, it doesn't seem worth it to keep all of those drivers around
>> with the maintenance overhead that comes with that if nobody's going to
>> notice anyway.  So please speak up if you want to see one of these in
>> jessie.
>>
>> xserver-xorg-video-apm
>> xserver-xorg-video-ark
>> xserver-xorg-video-chips
>> xserver-xorg-video-glint
>> xserver-xorg-video-i128
>> xserver-xorg-video-i740
>> xserver-xorg-video-newport
>> xserver-xorg-video-rendition
>> xserver-xorg-video-s3
>> xserver-xorg-video-s3virge
>> xserver-xorg-video-sis
>> xserver-xorg-video-suncg14
>> xserver-xorg-video-suncg3
>> xserver-xorg-video-suncg6
>> xserver-xorg-video-sunleo
>> xserver-xorg-video-suntcx
>>
>
> Adding debian-sparc to discuss these 5. I think all of them are only
> available in sparc32 machines, but I might be wrong.
> --
> Jurij Smakov | ju...@wooyd.org | Key IDs: 43C30A7D/C99E03CC
>

Re: Compiling vanilla kernel issues.

[Patrick Baggett]

;> > > >
>> > > > -Kieron
>> > > >
>> > > > On Sat, Sep 21, 2013 at 3:11 AM, Hartwig Atrops
>> > >
>> > > wrote:
>> > > > > Hi.
>> > > > >
>> > > > > Last night, I've built a kernel 3.11.1 from kernel.org the
>> Debian way
>> > >
>> > > (as
>> > >
>> > > > > described in "Debian Linux Kernel Handbook") - without any
>> problems.
>> > > > >
>> > > > > My test environment: a fresh installation of Wheezy (7.0.1) on a
>> Sun
>> > > > > Ultra 60,
>> > > > > i.e. a SCSI machine.
>> > > > >
>> > > > > I'm going to do a test with an ATAPi/IDE Blade 100 as well, but I
>> > > > > have
>> > >
>> > > to
>> > >
>> > > > > set
>> > > > > up this machine first - that will take a while.
>> > > > >
>> > > > > Regards,
>> > > > >
>> > > > >Hartwig
>> > > > >
>> > > > > On Friday 20 September 2013 03:37:30 Kieron Gillespie wrote:
>> > > > > > So current when I build the vanilla kernel using the typical
>> Debian
>> > > > >
>> > > > > method
>> > > > >
>> > > > > > with make deb-pkg I end up with a kernel that panic's on boot.
>> > > > > >
>> > > > > > It says,
>> > > > > > --CUT--
>> > > > > > Kernel panic - not syncing: VFS: Unable to mount root fs on
>> > > > > > unknown-block(0,0)
>> > > > > >
>> > > > > > CPU: 0 PID: 1 Comm: swapper/1 Not tainted 3.12.0-rc #1
>> > > > > > Call Trace:
>> > > > > > --END CUT--
>> > > > > >
>> > > > > > Any ideas? If someone has instructions on how they typically
>> build
>> > > > > > there kernel for SPARC system I would like to know. Though this
>> is
>> > >
>> > > how
>> > >
>> > > > > > I always have done it in the past it just recently stop working
>> > > > > > after 3.8.x
>> > > > >
>> > > > > series.
>> > > > >
>> > > > > > On Thu, Sep 19, 2013 at 9:14 AM, Patrick Baggett
>> > > > > >
>> > > > > > wrote:
>> > > > > > > I didn't have any problems, but I'm not using initramfs. To
>> build
>> > > > > > > a kernel 'the debian way', you might need to find a guide or
>> > > > > > > maybe
>> > > > >
>> > > > > someone
>> > > > >
>> > > > > > > else can chime in?
>> > > > > > > On Sep 18, 2013 10:05 PM, "Kieron Gillespie" <
>> > > > >
>> > > > > ciaran.gilles...@gmail.com>
>> > > > >
>> > > > > > > wrote:
>> > > > > > >> Hello everyone,
>> > > > > > >>
>> > > > > > >> Was wondering if anyone had any success compiling any of the
>> > >
>> > > vanilla
>> > >
>> > > > > > >> Linux kernel's on their SPARC wheezy systems with anything
>> after
>> > > > >
>> > > > > version
>> > > > >
>> > > > > > >> 3.8.x.
>> > > > > > >>
>> > > > > > >> Every time I try to build myself a new kernel I seem to end
>> up
>> > >
>> > > with
>> > >
>> > > > > > >> a kernel that is unable to boot complaining about not being
>> able
>> > >
>> > > to
>> > >
>> > > > > > >> find the root file system. I was wondering if anyone has any
>> > > > > > >> information on how I can configure and build the Linux kernel
>> > > > > > >> for
>> > >
>> > > my
>> > >
>> > > > > > >> various SPARC systems.
>> > > > > > >>
>> > > > > > >> -Kieron
>> > > > >
>> > > > > --
>> > > > > To UNSUBSCRIBE, email to debian-sparc-requ...@lists.debian.org
>> > > > > with a subject of "unsubscribe". Trouble? Contact
>> > > > > listmas...@lists.debian.org
>> > > > > Archive:
>> > > > >
>> http://lists.debian.org/201309210911.41123.hartwig.atr...@arcor.de
>> > >
>> > > --
>> > > To UNSUBSCRIBE, email to debian-sparc-requ...@lists.debian.org
>> > > with a subject of "unsubscribe". Trouble? Contact
>> > > listmas...@lists.debian.org
>> > > Archive:
>> > > http://lists.debian.org/201309212153.31868.hartwig.atr...@arcor.de
>>
>>
>>
>> --
>> To UNSUBSCRIBE, email to debian-sparc-requ...@lists.debian.org
>> with a subject of "unsubscribe". Trouble? Contact
>> listmas...@lists.debian.org
>> Archive:
>> http://lists.debian.org/201309231640.57438.hartwig.atr...@arcor.de
>>
>>
>

Re: Compiling vanilla kernel issues.

[Patrick Baggett]

That's right. It sounds like your initramfs is missing drivers for the
IDE/SATA/SAS system. In other words, your kernel loads, but without the
drivers either a) built-in to the kernel or b) present in the initramfs, it
has no way of detecting and subsequently mounting your disks which contain
the root partition "/".

I would do `lspci` to find out what chipset the SPARC system uses, then see
if you find which of the drivers that `lsmod` shows is responsible for
that. You may be able to use `dmesg | more` to see what driver detects the
disks as well -- pretty much every driver prints debug messages about the
disks it finds. Alternatively, if you know the model of the system (e.g.
Sun Ultra 80), then you can look up the hardware / drivers using your
favorite search engine or see if anyone knows off hand on the list.

Good luck!

Patrick Baggett


On Thu, Sep 19, 2013 at 8:37 PM, Kieron Gillespie <
ciaran.gilles...@gmail.com> wrote:

> So current when I build the vanilla kernel using the typical Debian method
> with make deb-pkg I end up with a kernel that panic's on boot.
>
> It says,
> --CUT--
> Kernel panic - not syncing: VFS: Unable to mount root fs on
> unknown-block(0,0)
>
> CPU: 0 PID: 1 Comm: swapper/1 Not tainted 3.12.0-rc #1
> Call Trace:
> --END CUT--
>
> Any ideas? If someone has instructions on how they typically build there
> kernel for SPARC system I would like to know. Though this is how I always
> have done it in the past it just recently stop working after 3.8.x series.
>
>
> On Thu, Sep 19, 2013 at 9:14 AM, Patrick Baggett <
> baggett.patr...@gmail.com> wrote:
>
>> I didn't have any problems, but I'm not using initramfs. To build a
>> kernel 'the debian way', you might need to find a guide or maybe someone
>> else can chime in?
>>  On Sep 18, 2013 10:05 PM, "Kieron Gillespie" 
>> wrote:
>>
>>> Hello everyone,
>>>
>>> Was wondering if anyone had any success compiling any of the vanilla
>>> Linux kernel's on their SPARC wheezy systems with anything after version
>>> 3.8.x.
>>>
>>> Every time I try to build myself a new kernel I seem to end up with a
>>> kernel that is unable to boot complaining about not being able to find the
>>> root file system. I was wondering if anyone has any information on how I
>>> can configure and build the Linux kernel for my various SPARC systems.
>>>
>>> -Kieron
>>>
>>
>

Re: Compiling vanilla kernel issues.

[Patrick Baggett]

I didn't have any problems, but I'm not using initramfs. To build a kernel
'the debian way', you might need to find a guide or maybe someone else can
chime in?
On Sep 18, 2013 10:05 PM, "Kieron Gillespie" 
wrote:

> Hello everyone,
>
> Was wondering if anyone had any success compiling any of the vanilla Linux
> kernel's on their SPARC wheezy systems with anything after version 3.8.x.
>
> Every time I try to build myself a new kernel I seem to end up with a
> kernel that is unable to boot complaining about not being able to find the
> root file system. I was wondering if anyone has any information on how I
> can configure and build the Linux kernel for my various SPARC systems.
>
> -Kieron
>

Re: SIGBUS in elfutils

[Patrick Baggett]

Short version: likely looks like a bug in the *.c code, should use memcpy()
instead of type-punning when the alignment is unknown.

Long version:
The 'ldd' instruction is *l*oa*d* *d*ouble word, i.e. load 64-bit
value. 0xf7d182fc
is 4-byte aligned, but not 8-byte aligned, so 'ldd' faults and raises
SIGBUS. The part where the value is stored in "*dst" isn't even reached (it
is the 'std' after it), so whether "dst" is aligned or not is not in
question here.

It's suspicious to cast from some type to `GElf_auxv_t*` (64-bit type) and
then dereference it:

 *dst = ((GElf_auxv_t *) data_scn->d.d_buf)[ndx];

If d.d_buf[] is not 8-byte aligned (which it may not be unless is an
address returned from malloc() or a points to a naturally 8-byte aligned
type allocated on stack -- i.e. char[] is NOT sufficient), then this should
be done with memcpy() instead.




On Sat, Aug 24, 2013 at 5:44 PM, Kurt Roeckx  wrote:

> Hi,
>
> I'm seeing a SIGBUS in elfutils, and I'm not sure why I'm getting
> this.
> LD_LIBRARY_PATH=libdw:libelf:backends/ gdb ./src/readelf
> [...]
> (gdb) set args -n tests/testfile67
> (gdb) run
> Starting program: /home/kroeckx/elfutils-0.156/src/readelf -n
> tests/testfile67
>
> Note segment of 1044 bytes at offset 0xe8:
>   Owner  Data size  Type
>   CORE 336  PRSTATUS
> info.si_signo: 4, info.si_code: 0, info.si_errno: 0, cursig: 4
> sigpend: <>
> sighold: <>
> pid: 805, ppid: 804, pgrp: 804, sid: 699
> utime: 0.42, stime: 0.000103, cutime: 0.00, cstime: 0.00
> orig_r2: 2571552016, fpvalid: 1
> pswm:   0x0705c0018000  pswa:   0x80d6
> r0: 4393751543808  r1: 4398002544388
> r2:11  r3:2571578208
> r4:2571702016  r5: 4398003235624
> r6:2571580768  r7:2571702016
> r8:2571578208  r9:2571552016
> r10:   2571552016  r11:0
> r12:4398003499008  r13:   2148274656
> r14:0  r15:4398040761216
> a0:   0x03ff  a1:   0xfd54a6f0  a2:   0x  a3:   0x
> a4:   0x  a5:   0x  a6:   0x  a7:   0x
> a8:   0x  a9:   0x  a10:  0x  a11:  0x
> a12:  0x  a13:  0x  a14:  0x  a15:  0x
>   CORE 136  PRPSINFO
> state: 0, sname: R, zomb: 0, nice: 0, flag: 0x00400400
> uid: 0, gid: 0, pid: 805, ppid: 804, pgrp: 804, sid: 699
> fname: 1, psargs: ./1
>   CORE 304  AUXV
>
> Program received signal SIGBUS, Bus error.
> 0xf7f673f4 in gelf_getauxv (data=data@entry=0x4c8f8, ndx=ndx@entry=0,
> dst=dst@entry=0xd070) at gelf_getauxv.c:100
> 100   *dst = ((GElf_auxv_t *) data_scn->d.d_buf)[ndx];
> (gdb) p ((GElf_auxv_t *) data_scn->d.d_buf)
> $1 = (GElf_auxv_t *) 0xf7d182fc
> (gdb) disass
> Dump of assembler code for function gelf_getauxv:
>0xf7f673a0 <+0>: save  %sp, -96, %sp
>0xf7f673a4 <+4>: mov  %i0, %g1
>0xf7f673a8 <+8>: cmp  %g1, 0
>0xf7f673ac <+12>:be,pn   %icc, 0xf7f6744c 
>0xf7f673b0 <+16>:clr  %i0
>0xf7f673b4 <+20>:ld  [ %g1 + 4 ], %g2
>0xf7f673b8 <+24>:cmp  %g2, 0x18
>0xf7f673bc <+28>:bne,pn   %icc, 0xf7f67444 
>0xf7f673c0 <+32>:inc  %i1
>0xf7f673c4 <+36>:ld  [ %g1 + 0x20 ], %g2
>0xf7f673c8 <+40>:ld  [ %g2 + 0x6c ], %g2
>0xf7f673cc <+44>:ld  [ %g2 + 0x14 ], %g2
>0xf7f673d0 <+48>:cmp  %g2, 1
>0xf7f673d4 <+52>:be,pn   %icc, 0xf7f6740c 
>0xf7f673d8 <+56>:ld  [ %g1 + 0xc ], %g2
>0xf7f673dc <+60>:sll  %i1, 4, %i1
>0xf7f673e0 <+64>:cmp  %i1, %g2
>0xf7f673e4 <+68>:bgu,pn   %icc, 0xf7f67458 
>0xf7f673e8 <+72>:mov  0x15, %o0
>0xf7f673ec <+76>:ld  [ %g1 ], %g1
>0xf7f673f0 <+80>:add  %g1, %i1, %i1
> => 0xf7f673f4 <+84>:ldd  [ %i1 + -16 ], %g2
>0xf7f673f8 <+88>:std  %g2, [ %i2 ]
>0xf7f673fc <+92>:ldd  [ %i1 + -8 ], %g2
>0xf7f67400 <+96>:std  %g2, [ %i2 + 8 ]
>0xf7f67404 <+100>:   rett  %i7 + 8
>0xf7f67408 <+104>:   mov  %o2, %o0
>0xf7f6740c <+108>:   sll  %i1, 3, %i1
>0xf7f67410 <+112>:   cmp  %i1, %g2
>0xf7f67414 <+116>:   bgu,pn   %icc, 0xf7f67454 
>0xf7f67418 <+120>:   add  %i1, -8, %i1
>0xf7f6741c <+124>:   ld  [ %g1 ], %g1
>0xf7f67420 <+128>:   ld  [ %g1 + %i1 ], %g2
>0xf7f67424 <+132>:   add  %g1, %i1, %i1
>0xf7f67428 <+136>:   clr  [ %i2 ]
>0xf7f6742c <+140>:   st  %g2, [ %i2 + 4 ]
>0xf7f67430 <+144>:   ld  [ %i1 + 4 ], %g1
>0xf7f67434 <+148>:   clr  [ %i2 + 8 ]
>0xf7f67438 <+152>:   st  %g1, [ %i2 + 0xc ]
>0xf7f6743c <+156>:   rett  %i7 + 8
>0xf7f67440 <+160>:   mov  %o2, %o0
>0xf7f67444 <+164>:   call  0xf7f56940 <__libelf_seterrno>
>0xf7f67448 <+168>:   mov  4, %o0
>0xf7f6744c <+172>:

Re: SIGBUS libcrypto in Wheezy/Sparc

[Patrick Baggett]

Hmm, I think I can debug this if you can give me steps to reproduce it. Is
it just when you start up the program?

Patrick


On Fri, Aug 9, 2013 at 2:33 AM, Jersey Man  wrote:

> Unaligned access? Get this when running 'sipp' or 'freeswitch' when
> compiled with SSL support.
>
>
>
> [Thread debugging using libthread_db enabled]
> Using host libthread_db library "/lib/sparc-linux-gnu/libthread_db.so.1".
>
> Program received signal SIGBUS, Bus error.
> 0xf7e34f4c in ?? () from /usr/lib/sparc-linux-gnu/libcrypto.so.1.0.0
> (gdb) bt
> #0  0xf7e34f4c in ?? () from /usr/lib/sparc-linux-gnu/libcrypto.so.1.0.0
> #1  0xf7e34c78 in OPENSSL_cpuid_setup ()
>from /usr/lib/sparc-linux-gnu/libcrypto.so.1.0.0
> #2  0xf7e30458 in ?? () from /usr/lib/sparc-linux-gnu/libcrypto.so.1.0.0
> #3  0xf7e30458 in ?? () from /usr/lib/sparc-linux-gnu/libcrypto.so.1.0.0
> Backtrace stopped: previous frame identical to this frame (corrupt stack?)
> (gdb)
>

Re: Sparc avaiable

[Patrick Baggett]

I think you guys should say where you are located. I might be, but not if
it is across the ocean. :-)
On Jun 23, 2013 6:10 PM, "M. Dietrich"  wrote:

> Hi all,
>
>
> i have a spare sun sparc laying around collecting dust in my wardrobe.
> anyone
> interested in it for porting and the like?
>
>
> best regards,
> michael
>
> --
> M. Dietrich
>
>
> --
> To UNSUBSCRIBE, email to debian-sparc-requ...@lists.debian.org
> with a subject of "unsubscribe". Trouble? Contact
> listmas...@lists.debian.org
> Archive: http://lists.debian.org/20130623230031.ga2...@emdete.de
>
>

Re: qemu FTBFS on sparc: conflicting types of tcflag_t?

[Patrick Baggett]

Hi Michael,

If the problem is definitively a system header problem, can you create a
mostly-empty *.c file that has the two includes to demonstrate the problem?
I can try to reproduce it on my machine at home. Also, if you have the
time, can you check the headers themselves for #ifdefs or something (not
sure how proficient you are with C and C preprocessor) that might guard
double inclusion? Check if other architectures use similar definitions?

/usr/include/sparc-linux-gnu/asm/termbits.h:12:25
/usr/include/sparc-linux-gnu/bits/termios.h:25:22

On the system that builds OK, can you copy those two files and compare it
to the system that doesn't work? Also, checking the gcc predefined macros (gcc
-dM -E - < /dev/null) for each environment may help, especially if the
tcflag_t type is selected based on something like the "bitness" (32 / 64)
of the target. Finally, if it isn't just your system, a bug report would be
really helpful with as much information and detective work as possible.


Patrick


On Tue, Jun 4, 2013 at 11:50 PM, Michael Tokarev  wrote:

> 01.06.2013 14:44, Michael Tokarev пишет:
> > 28.05.2013 19:02, Michael Tokarev wrote:
> >> Hello.
> >>
> >> One of our packages started to FTBFS on Sparc, here's the first
> >> build log that shows the issue:
> >>
> >>
> https://buildd.debian.org/status/fetch.php?pkg=qemu&arch=sparc&ver=1.5.0%2Bdfsg-1&stamp=1369117249
> >>
> >> The relevant portion:
> >>
> >>   CCi386-linux-user/linux-user/syscall.o
> >> In file included from /usr/include/sparc-linux-gnu/asm/termios.h:5:0,
> >>  from /usr/include/linux/termios.h:5,
> >>  from
> /build/buildd-qemu_1.5.0+dfsg-1-sparc-34y5XW/qemu-1.5.0+dfsg/linux-user/syscall.c:92:
> >> /usr/include/sparc-linux-gnu/asm/termbits.h:12:25: error: conflicting
> types for 'tcflag_t'
> >> /usr/include/sparc-linux-gnu/bits/termios.h:25:22: note: previous
> declaration of 'tcflag_t' was here
> >> make[2]: *** [linux-user/syscall.o] Error 1
>
> Last version of qemu which was built successfully on sparc was
> 1.5.0~rc0 (according to the build logs).  The interesting
> difference between 1.5.0~rc0 and current 1.5.0 is that now,
> qemu has another #include in common headers, namely, it
> added
>
>   #include 
>
> before this place which includes .
>  includes .  And it looks like on
> sparc,  conflicts with 
> somehow.
>
> I dunno why it only happens on sparc (the build is done
> with -m32 fwiw), and whenever this makes sense, and
> especially why I can't reproduce it on smetana.d.o.
>
> But it looks like I'm talking to myself here.
>
> Thanks,
>
> /mjt
>
>
> --
> To UNSUBSCRIBE, email to debian-sparc-requ...@lists.debian.org
> with a subject of "unsubscribe". Trouble? Contact
> listmas...@lists.debian.org
> Archive: http://lists.debian.org/51aec398.40...@msgid.tls.msk.ru
>
>

Re: sparc / Problems with 3.2-kernel

[Patrick Baggett]

I have a dual US-III in a Sun Blade 2500 running 3.9 and it's stable for
me, but I don't recall having any problems with 3.2 either.

Patrick


On Sun, Jun 2, 2013 at 4:38 PM, BERTRAND Joël wrote:

> Andreas Barth a écrit :
>
>  Hi,
>>
>> today I tried to resurrect our buildd on schroeder (which is from
>> architecture sparc). While trying to do so, I had a couple of strange
>> behaviours like vi freezing after 20-30 seconds, or I couldn't about
>> tail with ctrl+c or suspend with ctrl+z.  This didn't change after a
>> reboot. Machine was running our official 3.2-kernel.
>>
>> After Martin rebooted the machine into oldstables 2.6.32 kernel,
>> things are working as they should, and the buildd is up again.
>>
>> Question: Is this a known issue? How can we get a fix for that?  (I
>> would assume DSA will consider it a non-option to not be able to
>> upgrade to our default kernels.)
>>
>
> Hello,
>
> I have seen same freezes on Blade 2000 (2 * US III+/900 Cu), on U5
> (US IIi/440), but not on a server that run with four US IIIi and not on a
> T1000 (sun4v/US T1). I have tested 3.2 debian kernels and official ones and
> both hang. I suppose there is another strange bug with special MMU. 2.6.32
> is stable but on sparc64, 3.2 is not. I have not tested newer kernels.
>
> Regards,
>
> JKB
>
>
>
> --
> To UNSUBSCRIBE, email to 
> debian-sparc-REQUEST@lists.**debian.org
> with a subject of "unsubscribe". Trouble? Contact
> listmas...@lists.debian.org
> Archive: 
> http://lists.debian.org/**51abbb4f.5010...@systella.fr
>
>

Re: Help with Wheezy CD testing on Saturday

[Patrick Baggett]

It is an HP zx6000, an Itanium (ia64) machine. Please ignore; it was
probably CCd to the wrong lists.

Patrick


On Fri, May 24, 2013 at 4:32 AM, Mark Morgan Lloyd <
markmll.debian-sp...@telemetry.co.uk> wrote:

> Peter Chubb wrote:
>
>> "Émeric" == Émeric Maschino  writes:
>>>
>>
>>
>> Émeric> Just to let you know that I've successfully installed Wheezy
>> Émeric> using the netinst CD on a spare HDD, using default parameters
>> Émeric> (using entire HDD and one single partition as partition
>> Émeric> scheme) except for localization of course.
>>
>>
>> I've been trying to install using the XFCE CD on a zx6000.  The boot
>> rom doesn't recognise the CD as being bootable.The netinst CD does
>> work.
>>
>>
>> --
>> Dr Peter Chubb  peter.chubb AT
>> nicta.com.au
>> http://www.ssrg.nicta.com.au  Software Systems Research
>> Group/NICTA
>>
>
> What is this zx6000 of which you speak, and why is it spam^H^Hlattered
> over a significant number of irrelevant mailing lists?
>
> --
> 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 
> debian-sparc-REQUEST@lists.**debian.org
>
> with a subject of "unsubscribe". Trouble? Contact
> listmas...@lists.debian.org
> Archive: 
> http://lists.debian.org/**519f33ca.3090...@telemetry.co.**uk
>
>

Re: Multiscreen systems

[Patrick Baggett]

Hi Mark,

I've not tried that combination. I do have to ask though, why so old
versions? Etch is 4.0, and Lenny is 5.0. I think we're closer to 7.0 right
now (wheezy), with 6.0 being the current stable version. I'd imagine that
there are a number of bug fixes in between that might help your situation.

Patrick



On Tue, Mar 19, 2013 at 3:26 AM, Mark Morgan Lloyd <
markmll.debian-sp...@telemetry.co.uk> wrote:

> Has anybody tested Xinerama and xdmx on SPARC recently, using e.g. 2x
> Creator 3Ds in a U60?
>
> I tried upgrading a must-work system from Etch to Lenny over the weekend,
> and found that mouse handling was broken on Xinerama: KDE and twm together
> with some apps behaved as though an unspecified meta key was pressed. Also
> xdmx was unable to handle a Sun-style mouse.
>
> --
> 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 
> debian-sparc-REQUEST@lists.**debian.org
> with a subject of "unsubscribe". Trouble? Contact
> listmas...@lists.debian.org
> Archive: http://lists.debian.org/**ki97fg$u62$1@pye-srv-01.**
> telemetry.co.uk
>
>

Re: liburcu sparc support, build failure on buildd

[Patrick Baggett]

On Fri, Feb 22, 2013 at 8:15 AM, Mathieu Desnoyers <
mathieu.desnoy...@efficios.com> wrote:

> Hi,
>
> I notice the following build failure here
>
> https://buildd.debian.org/status/package.php?p=liburcu
>
> Tail of log for liburcu on sparc:
>
> urcu/static/wfqueue.h:84:2: warning: implicit declaration of function
> 'CMM_STORE_SHARED' [-Wimplicit-function-declaration]
> urcu/static/wfqueue.h: In function '___cds_wfq_node_sync_next':
> urcu/static/wfqueue.h:99:2: warning: implicit declaration of function
> 'CMM_LOAD_SHARED' [-Wimplicit-function-declaration]
> urcu/static/wfqueue.h:99:15: warning: assignment makes pointer from
> integer without a cast [enabled by default]
> urcu/static/wfqueue.h:104:4: warning: implicit declaration of function
> 'caa_cpu_relax' [-Wimplicit-function-declaration]
> urcu/static/wfqueue.h: In function '___cds_wfq_dequeue_blocking':
> urcu/static/wfqueue.h:126:55: warning: comparison between pointer and
> integer [enabled by default]
> make[3]: *** [wfqueue.lo] Error 1
> make[3]: Leaving directory
> `/build/buildd-liburcu_0.7.6-1-sparc-GySyug/liburcu-0.7.6'
> make[2]: *** [all-recursive] Error 1
> make[2]: Leaving directory
> `/build/buildd-liburcu_0.7.6-1-sparc-GySyug/liburcu-0.7.6'
> make[1]: *** [all] Error 2
> make[1]: Leaving directory
> `/build/buildd-liburcu_0.7.6-1-sparc-GySyug/liburcu-0.7.6'
> dh_auto_build: make -j1 returned exit code 2
> make: *** [build-arch] Error 2
>
> One main question I have: what sparc architectures are supported by
> Debian's "sparc" architecture ? Userspace RCU only supports Sparcv9 and
> onward, because it requires some atomic instructions.
>
>
Debian definitely only supports[1] SPARCv9 compatible CPUs (sun4u, sun4v).
I've heard that Linux on 32-bit SPARC (i.e. sparc <= v8) is shoddy now, but
I certainly haven't tried it.

[1] http://www.debian.org/ports/sparc/

As documented in the urcu README file, building a package that includes
> sparcv9 isntructions for 32-bit sparc can be done with:
>
> CFLAGS="-m32 -Wa,-Av9a -g -O2" ./configure
>

"v9a" includes VIS instruction set, which is an extension of SPARCv9. I
think only some early Fujitsu SPARC CPUs (pre 2000) are missing it -- the
original UltraSPARC from Sun does include it. Probably safe to turn on, but
technically extends requirements to use the program.


>
> But if Debian sparc needs to support pre-v9 sparcs, then I guess it
> would not be appropriate to use v9 instructions for urcu sparc build.
>
> Thoughts ?
>
> Thanks,
>
> Mathieu
>
> --
> Mathieu Desnoyers
> EfficiOS Inc.
> http://www.efficios.com
>
>
> --
> To UNSUBSCRIBE, email to debian-sparc-requ...@lists.debian.org
> with a subject of "unsubscribe". Trouble? Contact
> listmas...@lists.debian.org
> Archive: http://lists.debian.org/20130222141551.GB22156@Krystal
>
>

Re: Call for iceweasel testing

[Patrick Baggett]

Jurij,

The backtrace for Hartwig is in some kind of SPARC JIT compiler for
JavaScript. Notice the *.S files dealing with SPARC assembly. Your
backtrace showed a completely separate area -- perhaps dealing with
bytecode it appears? If there is some option to enable/disable SPARC JIT
for JavaScript, you might look into it as a possible cause.

Patrick

On Fri, Feb 15, 2013 at 2:04 PM, Jurij Smakov  wrote:

> On Fri, Feb 15, 2013 at 12:17:00PM +0100, Hartwig Atrops wrote:
> > Hello.
> >
> > On Friday 15 February 2013 10:24:27 Jurij Smakov wrote:
> > > On Thu, Feb 14, 2013 at 10:27:32PM +0100, Hartwig Atrops wrote:
> > > > Hello.
> > > >
> > > > This evening, I tested the packages from wooyd.org on my Blade 100 -
> > > > still nok :-(
> > > >
> > > > I used the latest Wheezy version (apt-get update / apt-get upgrade)
> and
> > > > deinstalled iceweasel, xulrunner and libmozjs (apt-get purge), then
> > > > installed the new packages form HD (gdebi).
> > > >
> > > > Regards,
> > > >
> > > >Hartwig
> > > >
> > > > Backtrace:
> > > >
> > > > GNU gdb (GDB) 7.4.1-debian
> > > > Copyright (C) 2012 Free Software Foundation, Inc.
> > > > License GPLv3+: GNU GPL version 3 or later
> > > >  This is free software: you are
> free to
> > > > change and redistribute it. There is NO WARRANTY, to the extent
> permitted
> > > > by law.  Type "show copying" and "show warranty" for details.
> > > > This GDB was configured as "sparc-linux-gnu".
> > > > For bug reporting instructions, please see:
> > > > ...
> > > > Reading symbols from /usr/lib/iceweasel/firefox-bin...(no debugging
> > > > symbols found)...done.
> > > > [New LWP 7756]
> > > > [New LWP 7761]
> > > > [New LWP 7762]
> > > > [New LWP 7763]
> > > > [New LWP 7764]
> > > > [New LWP 7765]
> > > > [New LWP 7766]
> > > > [New LWP 7767]
> > > > [New LWP 7768]
> > > > [New LWP 7769]
> > > > [New LWP 7770]
> > > > [New LWP 7771]
> > > > [New LWP 7772]
> > > > [New LWP 7773]
> > > > [New LWP 7774]
> > > > [New LWP 7775]
> > > > [New LWP 7776]
> > > > [New LWP ]
> > > > [New LWP 7778]
> > > > [New LWP 7779]
> > > > [Thread debugging using libthread_db enabled]
> > > > Using host libthread_db library
> "/lib/sparc-linux-gnu/libthread_db.so.1".
> > > > Core was generated by `/usr/lib/iceweasel/firefox-bin'.
> > > > Program terminated with signal 10, Bus error.
> > > > #0  0xf770f0c4 in relinkJump (
> > > > to= > > > 0xc407bad6>, from=0x362) at
> > > > ../../../js/src/assembler/assembler/SparcAssembler.h:1090 (gdb) bt
> > > > #0  0xf770f0c4 in relinkJump (
> > > > to= > > > 0xc407bad6>, from=0x362) at
> > > > ../../../js/src/assembler/assembler/SparcAssembler.h:1090 #1
>  linkJump
> > > > (from=...,
> > > > to= > > > 0xc407bad6>, code=0x400) at
> > > > ../../../js/src/assembler/assembler/SparcAssembler.h:1113 #2
>  linkJump (
> > > > target= > > > 0xc407bad6>, jump=..., code=0x400)
> > > > at
> ../../../js/src/assembler/assembler/AbstractMacroAssembler.h:590
> > > > #3  link (label=..., jump=..., this=0xffe95188)
> > > > at ../../../js/src/assembler/assembler/LinkBuffer.h:116
> > > > #4  CallCompiler::generateStubForClosures (this=0xf770f020,
> > > > from=, obj=)
> > > >
> > > > at
> > > >
> /home/jurij/iceweasel/iceweasel-10.0.12esr/js/src/methodjit/MonoIC.cpp:89
> > > >0 #5  0xf768b880 in js::mjit::EnterMethodJIT (cx=0xeef2bb80,
> > > > fp=0xf0d00448, code=0xe5b3c02c, stackLimit=0xf10e, partial=true)
> > > >
> > > > at
> > > >
> /home/jurij/iceweasel/iceweasel-10.0.12esr/js/src/methodjit/MethodJIT.cpp
> > > >:1064 #6  0xf768bcbc in CheckStackAndEnterMethodJIT (partial=true,
> > > > code=0xe5b3c02c, fp=0xf0d00448, cx=0xeef2bb80)
> > > >
> > > > at
> > > >
> /home/jurij/iceweasel/iceweasel-10.0.12esr/js/src/methodjit/MethodJIT.cpp
> > > >:1125 #7  js::mjit::JaegerShotAtSafePoint (cx=0xeef2bb80,
> > > > safePoint=0xe5b3c02c, partial=true)
> > > >
> > > > at
> > > >
> /home/jurij/iceweasel/iceweasel-10.0.12esr/js/src/methodjit/MethodJIT.cpp
> > > >:1152 #8  0xf75632ec in js::Interpret (cx=0xeef2bb80,
> > > > entryFrame=0xf0d003f0, interpMode=js::JSINTERP_NORMAL)
> > > > at
> > > > /home/jurij/iceweasel/iceweasel-10.0.12esr/js/src/jsinterp.cpp:2125
> #9
> > > > 0xf77244a8 in UncachedInlineCall (f=..., initial=,
> > > > pret=0xffe95c10, unjittable=, argc=)
> > > >
> > > > at
> > > >
> /home/jurij/iceweasel/iceweasel-10.0.12esr/js/src/methodjit/InvokeHelpers
> > > >.cpp:392 #10 0xf77266c8 in js::mjit::stubs::UncachedCallHelper (f=...,
> > > > argc=2, lowered=false, ucr=0xffe95c08)
> > > >
> > > > at
> > > >
> /home/jurij/iceweasel/iceweasel-10.0.12esr/js/src/methodjit/InvokeHelpers
> > > >.cpp:479 #11 0xf770ac58 in update (this=0xffe95bf8)
> > > >
> > > > at
> > > >
> /home/jurij/iceweasel/iceweasel-10.0.12esr/js/src/methodjit/MonoIC.cpp:11
> > > >00 #12 js::mjit::ic::Call (f=..., ic=0xe3a81aa0)
> > > >
> > > > at
> > > >
> /home/jurij/iceweasel/iceweasel-10.0.12esr/js/s

Re: Call for iceweasel testing

[Patrick Baggett]

The backtrace seems to very different. That is in the JIT compiler, while
the bug report seems to be in perhaps a general interpreter?

Patrick

On Thu, Feb 14, 2013 at 3:27 PM, Hartwig Atrops wrote:

> Hello.
>
> This evening, I tested the packages from wooyd.org on my Blade 100 - still
> nok :-(
>
> I used the latest Wheezy version (apt-get update / apt-get upgrade) and
> deinstalled iceweasel, xulrunner and libmozjs (apt-get purge), then
> installed
> the new packages form HD (gdebi).
>
> Regards,
>
>Hartwig
>
> Backtrace:
>
> GNU gdb (GDB) 7.4.1-debian
> Copyright (C) 2012 Free Software Foundation, Inc.
> License GPLv3+: GNU GPL version 3 or later <
> http://gnu.org/licenses/gpl.html>
> This is free software: you are free to change and redistribute it.
> There is NO WARRANTY, to the extent permitted by law.  Type "show copying"
> and "show warranty" for details.
> This GDB was configured as "sparc-linux-gnu".
> For bug reporting instructions, please see:
> ...
> Reading symbols from /usr/lib/iceweasel/firefox-bin...(no debugging symbols
> found)...done.
> [New LWP 7756]
> [New LWP 7761]
> [New LWP 7762]
> [New LWP 7763]
> [New LWP 7764]
> [New LWP 7765]
> [New LWP 7766]
> [New LWP 7767]
> [New LWP 7768]
> [New LWP 7769]
> [New LWP 7770]
> [New LWP 7771]
> [New LWP 7772]
> [New LWP 7773]
> [New LWP 7774]
> [New LWP 7775]
> [New LWP 7776]
> [New LWP ]
> [New LWP 7778]
> [New LWP 7779]
> [Thread debugging using libthread_db enabled]
> Using host libthread_db library "/lib/sparc-linux-gnu/libthread_db.so.1".
> Core was generated by `/usr/lib/iceweasel/firefox-bin'.
> Program terminated with signal 10, Bus error.
> #0  0xf770f0c4 in relinkJump (
> to= 0xc407bad6>,
> from=0x362) at
> ../../../js/src/assembler/assembler/SparcAssembler.h:1090
> (gdb) bt
> #0  0xf770f0c4 in relinkJump (
> to= 0xc407bad6>,
> from=0x362) at
> ../../../js/src/assembler/assembler/SparcAssembler.h:1090
> #1  linkJump (from=...,
> to= 0xc407bad6>,
> code=0x400) at
> ../../../js/src/assembler/assembler/SparcAssembler.h:1113
> #2  linkJump (
> target= 0xc407bad6>, jump=..., code=0x400)
> at ../../../js/src/assembler/assembler/AbstractMacroAssembler.h:590
> #3  link (label=..., jump=..., this=0xffe95188)
> at ../../../js/src/assembler/assembler/LinkBuffer.h:116
> #4  CallCompiler::generateStubForClosures (this=0xf770f020,
> from=, obj=)
>
> at
> /home/jurij/iceweasel/iceweasel-10.0.12esr/js/src/methodjit/MonoIC.cpp:890
> #5  0xf768b880 in js::mjit::EnterMethodJIT (cx=0xeef2bb80, fp=0xf0d00448,
> code=0xe5b3c02c, stackLimit=0xf10e, partial=true)
>
> at
> /home/jurij/iceweasel/iceweasel-10.0.12esr/js/src/methodjit/MethodJIT.cpp:1064
> #6  0xf768bcbc in CheckStackAndEnterMethodJIT (partial=true,
> code=0xe5b3c02c,
> fp=0xf0d00448, cx=0xeef2bb80)
>
> at
> /home/jurij/iceweasel/iceweasel-10.0.12esr/js/src/methodjit/MethodJIT.cpp:1125
> #7  js::mjit::JaegerShotAtSafePoint (cx=0xeef2bb80, safePoint=0xe5b3c02c,
> partial=true)
>
> at
> /home/jurij/iceweasel/iceweasel-10.0.12esr/js/src/methodjit/MethodJIT.cpp:1152
> #8  0xf75632ec in js::Interpret (cx=0xeef2bb80, entryFrame=0xf0d003f0,
> interpMode=js::JSINTERP_NORMAL)
> at /home/jurij/iceweasel/iceweasel-10.0.12esr/js/src/jsinterp.cpp:2125
> #9  0xf77244a8 in UncachedInlineCall (f=..., initial=,
> pret=0xffe95c10, unjittable=, argc=)
>
> at
> /home/jurij/iceweasel/iceweasel-10.0.12esr/js/src/methodjit/InvokeHelpers.cpp:392
> #10 0xf77266c8 in js::mjit::stubs::UncachedCallHelper (f=..., argc=2,
> lowered=false, ucr=0xffe95c08)
>
> at
> /home/jurij/iceweasel/iceweasel-10.0.12esr/js/src/methodjit/InvokeHelpers.cpp:479
> #11 0xf770ac58 in update (this=0xffe95bf8)
>
> at
> /home/jurij/iceweasel/iceweasel-10.0.12esr/js/src/methodjit/MonoIC.cpp:1100
> #12 js::mjit::ic::Call (f=..., ic=0xe3a81aa0)
>
> at
> /home/jurij/iceweasel/iceweasel-10.0.12esr/js/src/methodjit/MonoIC.cpp:1160
> #13 0xf776dc54 in JaegerStubVeneer ()
>
> at
> /home/jurij/iceweasel/iceweasel-10.0.12esr/js/src/methodjit/TrampolineSparc.s:164
> #14 0xf776dc54 in JaegerStubVeneer ()
>
> at
> /home/jurij/iceweasel/iceweasel-10.0.12esr/js/src/methodjit/TrampolineSparc.s:164
> Backtrace stopped: previous frame identical to this frame (corrupt stack?)
> (gdb) q
>
>
> --
> To UNSUBSCRIBE, email to debian-sparc-requ...@lists.debian.org
> with a subject of "unsubscribe". Trouble? Contact
> listmas...@lists.debian.org
> Archive:
> http://lists.debian.org/201302142227.33033.hartwig.atr...@arcor.de
>
>

Re: QLogic PTI firmware

[Patrick Baggett]

It appears to be part of the Linux kernel source too.

linux-2.6/firmware/qlogic/isp1000.bin.hex

It may be the same firmware and may not be the problem.

Patrick

On Mon, Jan 21, 2013 at 3:45 AM, Mark Morgan Lloyd <
markmll.debian-sp...@telemetry.co.uk> wrote:

> What's the recommended way to get the isp1000.bin file required by the
> qlogicpti module? I can't find it on Debian and in the end converted the
> one at http://fxr.watson.org/fxr/**source/firmware/qlogic/**
> isp1000.bin.ihexwhich
>  looks at though it's from one of the BSDs.
>
> I've got a (non-critical) E4500 here with a D1000 JBOD, I appear to be
> able to crash 3.2.35 if the controller's stressed by e.g. 12x jobs each
> running dd to wipe a disc.
>
> --
> 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 
> debian-sparc-REQUEST@lists.**debian.org
> with a subject of "unsubscribe". Trouble? Contact
> listmas...@lists.debian.org
> Archive: http://lists.debian.org/**kdj2oj$ih4$1@pye-srv-01.**
> telemetry.co.uk
>
>

Re: problem with lesstif2 installation

[Patrick Baggett]

OK, so you have both libraries meaning then at least it appears you should
be able to run an application based on lesstif2, right?

Also, 620414 / 1024 is ~ 605.87, which could be rounded to 606KB. I
download one via HTTP. I see a size of 623092, which is 608.48, rounds down
to 608KB.


 I'm not sure what apt-get does to verify, but it probably does *some* kind
of verification. You can check the MD5 sum easily though:

$ md5sum file.deb

I've never used "wc -c" to list a file size; I'm not sure if it has other
semantics. It's coming up close what you're expecting, so maybe it does
something like skip certain bytes in the file? 'ls -l' will display the
file size for sure.

Patrick

On Mon, Jan 14, 2013 at 1:59 PM, Fred  wrote:

> Hi Patrick,
> I have both library files.
> I don't know how to check the MD5 sum.  I assume apt-get would do that
> before install.
> The .deb file I downloaded by ftp has a size of 620414  (using wc -c).
> The file at your link 
> http://packages.debian.org/**squeeze/sparc/lesstif2<http://packages.debian.org/squeeze/sparc/lesstif2>has
>  a size of 608.5 kB.
> The package at the Debian ftp site which is where apt-get got what it
> installed is listed as 606kB.
> So, I don't really know what size it actually is!
> Best regards,
> Fred
>
>
>
> On 01/14/2013 12:19 PM, Patrick Baggett wrote:
>
>> http://packages.debian.org/**squeeze/sparc/lesstif2/**filelist<http://packages.debian.org/squeeze/sparc/lesstif2/filelist>
>>
>> (From 
>> http://packages.debian.org/**squeeze/sparc/lesstif2<http://packages.debian.org/squeeze/sparc/lesstif2>
>> )
>>
>> It looks like it has *.so files in the package. I just downloaded it and
>> the size of the *.deb matches the site.
>>
>> Maybe you can do some checking?
>> 1) Do you not have /usr/lib/libXm.so.2 or libMrm.so.2?
>> 2) Does your *.deb package match the expected file size?
>> 3) If you download the package directly from the site, does the MD5 sum
>> match the package you have locally?
>>
>> If all else fails, you can open a bug for it or email the maintainer to
>> see if there are any sparc-specific changes that might have results in a
>> bad package.
>>
>> Patrick
>>
>> On Mon, Jan 14, 2013 at 10:52 AM, Fred > f...@blakemfg.com>> wrote:
>>
>> Hello,
>>
>> I am working with Debian Squeeze on a Sun Ultra 5 and am having
>> trouble installing lesstif2-0.95.2-1.1.  The package appears to
>> install ok but no files are actually written.  I have an x86 PC
>> also with Debian 6.0 and lesstif2 installed so I can see what
>> files are involved and where they should be.  None of them exists
>> on the Sun.  I had the same problem installing the previous
>> version of lesstif2 (without the -1) from a DVD set.  What to do?
>>
>> Best regards,
>> Fred
>>
>>
>> -- To UNSUBSCRIBE, email to debian-sparc-REQUEST@lists.**
>> debian.org 
>> 
>> <mailto:debian-sparc-REQUEST@**lists.debian.org
>> >
>>
>> with a subject of "unsubscribe". Trouble? Contact
>> listmas...@lists.debian.org 
>> <mailto:listmaster@lists.**debian.org
>> >
>> Archive: 
>> http://lists.debian.org/**50f437bd.6080...@blakemfg.com<http://lists.debian.org/50f437bd.6080...@blakemfg.com>
>>
>>
>>
>

Re: problem with lesstif2 installation

[Patrick Baggett]

http://packages.debian.org/squeeze/sparc/lesstif2/filelist

(From http://packages.debian.org/squeeze/sparc/lesstif2)

It looks like it has *.so files in the package. I just downloaded it and
the size of the *.deb matches the site.

Maybe you can do some checking?
1) Do you not have /usr/lib/libXm.so.2 or libMrm.so.2?
2) Does your *.deb package match the expected file size?
3) If you download the package directly from the site, does the MD5 sum
match the package you have locally?

If all else fails, you can open a bug for it or email the maintainer to see
if there are any sparc-specific changes that might have results in a bad
package.

Patrick

On Mon, Jan 14, 2013 at 10:52 AM, Fred  wrote:

> Hello,
>
> I am working with Debian Squeeze on a Sun Ultra 5 and am having trouble
> installing lesstif2-0.95.2-1.1.  The package appears to install ok but no
> files are actually written.  I have an x86 PC also with Debian 6.0 and
> lesstif2 installed so I can see what files are involved and where they
> should be.  None of them exists on the Sun.  I had the same problem
> installing the previous version of lesstif2 (without the -1) from a DVD
> set.  What to do?
>
> Best regards,
> Fred
>
>
> --
> To UNSUBSCRIBE, email to 
> debian-sparc-REQUEST@lists.**debian.org
> with a subject of "unsubscribe". Trouble? Contact
> listmas...@lists.debian.org
> Archive: 
> http://lists.debian.org/**50f437bd.6080...@blakemfg.com
>
>

Re: Install Linux on Ultra Sparc 10

[Patrick Baggett]

I had this issue when I used a UPA (read: unsupported) graphics board. When
I used the built in PGX64 (mach64) board, I got VGA out. It's not to say
that with a UPA board it doesn't work, just that Linux doesn't detect it as
a framebuffer, and so it outputs to the serial console. I didn't have a
DB-25, so I just removed the UPA board all was good.

Patrick

On Wed, Dec 19, 2012 at 4:44 PM, Amy Tran  wrote:

>  Hello there, 
>
> ** **
>
> I tried to install Debian version 6.0.6 sparc on sparc ultra machine and
> got an error:
>
> Console: color dummy device 80x25
>
> Console [tty0] enable, bootable disable
>
> And the system was hang, no keyboard response.
>
> ** **
>
> Any idea?
>
> Thanks,
>
> Amy
>
> ** **
>

Re: Sun Fire V210 NIC's don't work

[Patrick Baggett]

Right, no problems except for this:

http://www.oracle.com/technetwork/licenses/solaris-cluster-express-license-167852.html

That's right, the EULA. You probably haven't read it, but I have, and in
particular, this clause is more problematic than the GPL, FSF, or BSD
license ever will be:

"Except for any included software package or file that is licensed to you
by Oracle under different license terms, we grant you a perpetual (unless
terminated as provided in this agreement), nonexclusive, nontransferable,
limited License to use the Programs *only for the purpose of developing,
testing, prototyping and demonstrating your applications, and not for any
other purpose.*"

So in other words, useless for hosting your home website, useless for
running any kind of in-house service, and prohibited from doing any real
work. Please, continue about how Solaris 10 empowers this machine to be
useful.

Patrick

On Mon, Nov 19, 2012 at 2:04 PM, Anonymous  wrote:

> SOLARIS 10 SPARC!!!
>
> You KNOW you want it! ;-)
>
> No Linux, no FSF, no problem!
>
>
> --
> To UNSUBSCRIBE, email to debian-sparc-requ...@lists.debian.org
> with a subject of "unsubscribe". Trouble? Contact
> listmas...@lists.debian.org
> Archive:
> http://lists.debian.org/7987e47f0532f145633ef5d380e0c...@mail.hoi-polloi.org
>
>

Re: Sun Fire V210 NIC's don't work

[Patrick Baggett]

So you did apt-get install firmware-linux-nonfree and still no go? I didn't
seem to have any problems with this, though it was on an ia64 machine.

Patrick

On Tue, Nov 13, 2012 at 6:13 PM, Kaya Saman  wrote:

> Hi,
>
> I attempted to configure a second nic on my server and added the new
> config to the /etc/network/interfaces file however I am left with dmesg
> errors:
>
> [   44.418128] tg3 0003:00:02.0: eth1: Tigon3 [partno(none) rev 2100]
> (PCI:66MHz:64-bit) MAC address 00:14:4f:5d:1e:80
> [   44.555470] tg3 0003:00:02.0: eth1: attached PHY is 5704
> (10/100/1000Base-T Ethernet) (WireSpeed[1])
> [   44.675644] tg3 0003:00:02.0: eth1: RXcsums[1] LinkChgREG[0] MIirq[0]
> ASF[0] TSOcap[1]
> [   44.779719] tg3 0003:00:02.0: eth1: dma_rwctrl[763f]
> dma_mask[32-bit]
> [   91.472697] tg3 0003:00:02.0: eth1: Failed to load firmware
> "tigon/tg3_tso.bin"
> [   91.568824] tg3 0003:00:02.0: eth1: TSO capability disabled
> [   92.927145] tg3 0003:00:02.0: eth1: No firmware running
> [   93.034647] ADDRCONF(NETDEV_UP): eth1: link is not ready
> [31557.037820] tg3 0003:00:02.0: eth1: Failed to load firmware
> "tigon/tg3_tso.bin"
> [31557.134305] tg3 0003:00:02.0: eth1: TSO capability disabled
> [31558.558344] ADDRCONF(NETDEV_UP): eth1: link is not ready
> [31734.774354] tg3 0003:00:02.0: eth1: Failed to load firmware
> "tigon/tg3_tso.bin"
> [31734.870823] tg3 0003:00:02.0: eth1: TSO capability disabled
> [31736.351600] ADDRCONF(NETDEV_UP): eth1: link is not ready
>
>
>
> The switch which the port is connected to shows physical link and is
> provisioned properly for the correct vlan, the first NIC eth0 is also
> connected to the same switch and is working fine but still producing errors:
>
> [   42.672840] tg3 :00:02.0: eth0: Tigon3 [partno(none) rev 2100]
> (PCI:66MHz:64-bit) MAC address 00:14:4f:5d:1e:7e
> [   42.810136] tg3 :00:02.0: eth0: attached PHY is 5704
> (10/100/1000Base-T Ethernet) (WireSpeed[1])
> [   42.930317] tg3 :00:02.0: eth0: RXcsums[1] LinkChgREG[0] MIirq[0]
> ASF[0] TSOcap[1]
> [   43.034393] tg3 :00:02.0: eth0: dma_rwctrl[763f]
> dma_mask[32-bit]
> [   81.804867] tg3 :00:02.0: eth0: Failed to load firmware
> "tigon/tg3_tso.bin"
> [   81.901028] tg3 :00:02.0: eth0: TSO capability disabled
> [   83.261266] tg3 :00:02.0: eth0: No firmware running
> [   84.321904] ADDRCONF(NETDEV_UP): eth0: link is not ready
> [   84.921250] tg3 :00:02.0: eth0: Link is up at 100 Mbps, full duplex
> [   85.008173] tg3 :00:02.0: eth0: Flow control is off for TX and off
> for RX
> [   85.103732] ADDRCONF(NETDEV_CHANGE): eth0: link becomes ready
>
>
> I have tried loading the firmware from:
>
> http://wiki.debian.org/**Firmware 
>
> and putting it into /lib/firmware/tigon however then both NICs fail??
>
>
> Could anyone suggest anything? With any other OS the system is fine so I'm
> guessing it's a kernel bug or so.
>
>
>
> Regards,
>
>
> Kaya
>
>
> --
> To UNSUBSCRIBE, email to 
> debian-sparc-REQUEST@lists.**debian.org
> with a subject of "unsubscribe". Trouble? Contact
> listmas...@lists.debian.org
> Archive: 
> http://lists.debian.org/**50a2e22b.1050...@gmail.com
>
>

Re: Oracle Sun T5120 support getting better in debian 6.0.5 ?

[Patrick Baggett]

I'm about 99% sure that Debian has run 64-bit SPARC kernels for a while
now, just that few packages are compiled for it. Unlike x86, most binaries
are faster as 32-bit code unless they make use of >= 3GB RAM and/or 64-bit
integer calculations. As a result, only stuff like databases, webservers,
or heavy large integer usage (RSA encryption, e.g.) would really benefit
much. Finding a binary that is faster when compiled as 64-bit code is an
exception to the rule. However, using SPARCv9 instructions (which require a
64-bit CPU) in 32-bit binary can improve performance.

Patrick


> And they even did build a 64 bit kernel as well. A how-to bootstrapping
> it for SPARC64 can be found in this wiki.
>
> http://wiki.debian.org/Sparc64
>
> Thanks,
>
>
> Frans van Berckel
>
>
> --
> To UNSUBSCRIBE, email to debian-sparc-requ...@lists.debian.org
> with a subject of "unsubscribe". Trouble? Contact
> listmas...@lists.debian.org
> Archive: http://lists.debian.org/1342187832.6087.6.ca...@deblnxsrv224.lan
>
>

Re: sparc qualification for Wheezy

[Patrick Baggett]

On Wed, May 30, 2012 at 3:16 PM, Martin Zobel-Helas wrote:

> Hi,
>
> On Wed May 16, 2012 at 13:19:48 +0100, Adam D. Barratt wrote:
> > Hi,
> >
> > With the sound of the ever approaching freeze ringing loudly in our ears,
> > we're (somewhat belatedly) looking at finalising the list of release
> > architectures for the Wheezy release.
> >
> > Comments on / additions and corrections to the content of
> > http://release.debian.org/wheezy/arch_qualify.html would be appreciated,
> > as would any other information you think is relevant to helping us
> > determine sparc's status for the release.
>
> with my DSA hat on:
>
> We no longer have an UltraSparc II porterbox, and we are considering
> decommissioning our single remaining UltraSparc II buildd machine.
>
> That's probably not the worst idea -- there are faster sparc boxes to
build on.



> Maybe it would be a good idea to officially drop US II support from
> wheezy since we won't have hardware to test issues on.
>
>
I don't understand the implications here. Wheezy works great on two US-II
machines that I know of. Does "dropping support" mean ignoring bug reports
if the CPU == US-II? Does it mean rendering the kernel unbootable on US-II
machines? Does it mean building code with US-III extensions at all times?
Why would this be necessary? I run Debian on a Pentium II since it is a
686-class CPU, but I wouldn't build the universe on it. Does build hardware
== only means of support? If so, I'm sure I have an 8-CPU US-II system that
can have a home anywhere that it is useful at, and it should be relatively
competitive with a dual US-III as far as build speed.

Patrick

Re: sparc qualification for Wheezy

[Patrick Baggett]

On Wed, May 23, 2012 at 2:08 PM, Adam D. Barratt
wrote:

> On Wed, 2012-05-23 at 13:44 -0500, Patrick Baggett wrote:
> > I didn't see where GCC was dropping 32-bit sparc upstream in the
> > changelogs. This seems inaccurate since a 64-bit userland has negative
> > performance implications, and this is true for both Solaris and Linux
> > and not recommended by anyone. A 64-bit userland is barely available
> > for Linux -- just a few C libraries like pthreads, libc, and zlib. Are
> > you sure this is correct?
>
> If you check http://release.debian.org/squeeze/arch_qualify.html ,
> you'll see that the comment on 32-bit code generation was added the last
> time we went through this exercise, a release cycle ago.  Also note the
> careful phrasing of the note - "32 bit code generation _as we use it_".
>
> My memory (backed up somewhat by having found the notes from the
> relevant IRC meeting) is that this was related to the use of -mcpu=v9 on
> 32-bit in a way that was very Debian-specific rather than being fully
> supported upstream.
>
> I'm not sure how much all of that still applies, but if it's wrong then
> hopefully someone from the porters can correct it.  That's rather why I
> requested comments...
>
> Regards,
>
> Adam
>
>
Hmm. That does seem odd too. "-mcpu=v9" means "use SPARCv9 instructions and
extensions from SPARCv8". Any CPU > 1996 can use these, and it's the
default on Solaris. I build a lot of 32-bit sparc code on both Solaris and
Linux (same code base) and use this flag without issues. I can't imagine
what the alternative might be. I would like to hear about this from any
porters as well. It seems critical that some method for using v9 extensions
in 32-bit code be maintained.

Patrick

Re: sparc qualification for Wheezy

[Patrick Baggett]

Adam,

I didn't see where GCC was dropping 32-bit sparc upstream in the
changelogs. This seems inaccurate since a 64-bit userland has negative
performance implications, and this is true for both Solaris and Linux and
not recommended by anyone. A 64-bit userland is barely available for Linux
-- just a few C libraries like pthreads, libc, and zlib. Are you sure this
is correct?

http://gcc.gnu.org/gcc-4.7/changes.html

On Wed, May 16, 2012 at 7:19 AM, Adam D. Barratt
wrote:

> Hi,
>
> With the sound of the ever approaching freeze ringing loudly in our ears,
> we're (somewhat belatedly) looking at finalising the list of release
> architectures for the Wheezy release.
>
> Comments on / additions and corrections to the content of
> http://release.debian.org/wheezy/arch_qualify.html would be appreciated,
> as would any other information you think is relevant to helping us
> determine sparc's status for the release.
>
> Regards,
>
> Adam
> pp the Release Team
>
>
> --
> To UNSUBSCRIBE, email to debian-sparc-requ...@lists.debian.org
> with a subject of "unsubscribe". Trouble? Contact
> listmas...@lists.debian.org
> Archive:
> http://lists.debian.org/e1sudcm-00058v...@kaa.jungle.funky-badger.org
>
>

Re: *May I submit you for this high focus, high paying CIRRUS LOGIC position?*

[Patrick Baggett]

On Thu, May 3, 2012 at 10:33 AM,  wrote:

> Hello!
>
> *May I submit you for this high focus, high paying Cirrus Logic position?*
>
> No, I don't think this is what the mailing list is for.

Re: http://developer.gaisler.net/debian/ sparc32 wheezy repostitory

[Patrick Baggett]

Packages are one thing but...Didn't the linux kernel drop SPARCv7/8
support? I remember reading their atomic ops and they uses 'cas' and 'casx'
which are very clearly sparcv9 instructions. It might have been a
conditional code path

On Wed, Apr 18, 2012 at 4:38 PM, Alexander Feld
wrote:

> Hi,
> > Just want to make public:
> > I've put some effort into a sparc32 repository
> > containing wheezy packages:
> > http://developer.gaisler.net/debian/
> > Most of the packages are cross-compiled, more
> > natively compiled will follow...
> > There is also a 64-bit sparc-32 cross compiler
> > with many dev-packages preinstalled:
> >
> http://developer.gaisler.net/debian/cross-compiler/sparc-linux-gnu-cross_1.0.0-1_amd64.deb
> Cool thing! Did you try to build mre packages like a kernel as well? I
> would really love to have a Wheezy system on my Sparcstation 20
>
> --
> Alexander Feld 
>
>
> --
> To UNSUBSCRIBE, email to debian-sparc-requ...@lists.debian.org
> with a subject of "unsubscribe". Trouble? Contact
> listmas...@lists.debian.org
> Archive:
> http://lists.debian.org/20120418233837.21b63a14e5bc44dbbbd41...@googlemail.com
>
>