Bug #6778 “atlas3: FTBFS on more than one architecture” : Bugs : atlas3 package : Ubuntu

Revision history for this message

In Debian Bug tracker #243447, Camm Maguire (camm) wrote on 2004-04-14: Re: Bug#243447: atlas3: FTBFS on more than one architecture

#1

Greetings! Just a quick inquiry -- you are not directly
build-depending on atlas3, are you? You can build-depend on either
refblas3-dev/lapack3-dev or libblas-3.so/liblapack-3.so and still get
the automatic benefit of atlas speedups where available and defaulting
to the reference versions elsewhere. Getting atlas to compile is a
lot of work, all of which I will not have any time soon, alas. Would
be happy to help interested porters accomplish same.

Take care,

Matthias Klose <email address hidden> writes:

> Package: atlas3
> Version: 3.6.0-4
> Severity: serious
>
> Fails on hppa, sparc, m68k, s390, arm, powerpc, ia64, succeeded on
> mips, mipsel, alpha.
>
>
>
>
>

--
Camm Maguire <email address hidden>
==========================================================================
"The earth is but one country, and mankind its citizens." -- Baha'u'llah

Revision history for this message

In Debian Bug tracker #243447, Camm Maguire (camm) wrote on 2004-06-07: Re: [Math-atlas-devel] segfault in sparc in ATL_zupKBmm8_8_1_bX.c:467 (xzl3blastst, TRSM)

#2

Download full text (3.8 KiB)

Greetings!

<email address hidden> (R Clint Whaley) writes:

> Camm,
>
> >Greetings! The suggested fix has gotten me past the error, and likely
> >will get me through the complete test suite, which is still in
> >progress, otherwise I'll let you know. Thanks again!
>
> I just noticed you are not signed up for the error list. I sent out a message
> about that error on the list when the error was found. You probably want to
> sign up. I send out a message for every major ATLAS error (i.e., any error
> that will produce a wrong answer or fault on a successfully installed stable)
> on that list. See:
> http://math-atlas.sourceforge.net/faq.html#lists
> It's very low traffic.
>

OK, will subscribe.

> >My understanding is that the only subarch specific codes in 3.6.0 which
> >will not run (however non-optimally) on at least some machines of the
> >given general cpu architecture fall into one of the following
> >categories:
> >
> >sse1
> >sse2
> >3dnow
> >altivec
> >ultrasparc
> >alpha ev6
> >
> >Please correct me if wrong. Specifically, if one has gnu tools only
> >(no icc, etc.), is there a difference between Itan and Itan2? Is
> >either build not executable on the other cpu? I'm supposing if not,
> >the Itan2 is the better default for Debian ia64.
>
> I believe this is true. However, the Itan2 may run very slow on an Itan1.
> The difference in their kernels, as I recall, is the number of registers
> used. I was unable to get access to a Itan1, so I was never sure if the
> extra registers were due to better register handling in gcc, or due to
> architectural differences. If gcc is the culprit, Itan2 defaults should
> be great for Itan1. If the difference is not gcc, Itan2 defaults may
> cause register spills within the kernel's innermost loop, which could be
> disastrous.
>
> I suppose another approach would be to install an older gcc on an Itanium2,
> and see if the present kernel blows. From the old dev2stable page, it looks
> like gcc 3.0 was used on the last Itanium1 I had access to.
>

Thanks! Since Itan2 is the future, and since I'm not really sure how
many users in ia64 land we have, I think we should go with Itan2 as
the default for now and see if anyone complains :-). I just wanted to
make sure there would be no SIGILL on Itan1...

We've got the following builds and their 'build records' well in hand:
(To refresh your memory, I've put in a little facility for replaying a
successful build without any timing on a machine which possibly does
not support the isa extensions compiled into the lib -- these are
'build records')

i386:
        base
        3dnow
        sse
        sse2

powerpc:
base
altivec

sparc:
base
v9

alpha:
base
ev5

ia64,s390,mips,mipsel,amd64,hppa:
base

I'm down to two platforms on which completing a build is proving
difficult:

1) arm: Why would one want to do this one asks? Good question, but
   in principle there may be some benefit to users of embedded devices
   and pdas, where this chip is quite popular. First, there is some
   instability in the cpu timer for which I need to file a bug with
   the kernel or libc maintainer, but ha...

Greetings!

rwhaley@cs.utk.edu (R Clint Whaley) writes:

> Camm,
> 
> >Greetings!  The suggested fix has gotten me past the error, and likely
> >will get me through the complete test suite, which is still in
> >progress, otherwise I'll let you know.  Thanks again!
> 
> I just noticed you are not signed up for the error list.  I sent out a message
> about that error on the list when the error was found.  You probably want to
> sign up.  I send out a message for every major ATLAS error (i.e., any error
> that will produce a wrong answer or fault on a successfully installed stable)
> on that list.  See:
>    http://math-atlas.sourceforge.net/faq.html#lists
> It's very low traffic.
>

OK, will subscribe.

> >My understanding is that the only subarch specific codes in 3.6.0 which
> >will not run (however non-optimally) on at least some machines of the
> >given general cpu architecture fall into one of the following
> >categories:
> >
> >sse1 
> >sse2
> >3dnow
> >altivec
> >ultrasparc
> >alpha ev6
> >
> >Please correct me if wrong.  Specifically, if one has gnu tools only
> >(no icc, etc.), is there a difference between Itan and Itan2?  Is
> >either build not executable on the other cpu?  I'm supposing if not,
> >the Itan2 is the better default for Debian ia64.
> 
> I believe this is true.  However, the Itan2 may run very slow on an Itan1.
> The difference in their kernels, as I recall, is the number of registers
> used.  I was unable to get access to a Itan1, so I was never sure if the
> extra registers were due to better register handling in gcc, or due to
> architectural differences.  If gcc is the culprit, Itan2 defaults should
> be great for Itan1.  If the difference is not gcc, Itan2 defaults may
> cause register spills within the kernel's innermost loop, which could be
> disastrous.
> 
> I suppose another approach would be to install an older gcc on an Itanium2,
> and see if the present kernel blows.  From the old dev2stable page, it looks
> like gcc 3.0 was used on the last Itanium1 I had access to.
>

Thanks!  Since Itan2 is the future, and since I'm not really sure how
many users in ia64 land we have, I think we should go with Itan2 as
the default for now and see if anyone complains :-).  I just wanted to
make sure there would be no SIGILL on Itan1...

We've got the following builds and their 'build records' well in hand:
(To refresh your memory, I've put in a little facility for replaying a
successful build without any timing on a machine which possibly does
not support the isa extensions compiled into the lib -- these are
'build records')

i386:
        base
        3dnow
        sse
        sse2

powerpc:
        base
        altivec

sparc:
        base
        v9

alpha:
        base
        ev5

ia64,s390,mips,mipsel,amd64,hppa:
        base

I'm down to two platforms on which completing a build is proving
difficult:

1) arm:  Why would one want to do this one asks?  Good question, but
   in principle there may be some benefit to users of embedded devices
   and pdas, where this chip is quite popular.  First, there is some
   instability in the cpu timer for which I need to file a bug with
   the kernel or libc maintainer, but haven't yet.  Am defaulting to
   -DWALL right now and am getting further, but as I don't have
   control of these machines and their load, I need higher reps
   apparently.  If you could look at

http://buildd.debian.org/fetch.php?&pkg=atlas3&ver=3.6.0-12&arch=arm&stamp=1086618196&file=log&as=raw

and comment if you have a moment I'd be grateful.

2) m68k:  This appears to merely require a longer 'inactivity'
   timeout.  The killer step is the final 'ar' (!)

Take care,

> Cheers,
> Clint
> 
> 
>

-- 
Camm Maguire			     			camm@enhanced.com
==========================================================================
"The earth is but one country, and mankind its citizens."  --  Baha'u'llah

Revision history for this message

Debian Bug Importer (debzilla) wrote on 2004-06-25:

#3

Automatically imported from Debian bug report #243447
http://bugs.debian.org/243447

Revision history for this message

Debian Bug Importer (debzilla) wrote on 2004-06-25:

#4

Message-ID: <email address hidden>
Date: Tue, 13 Apr 2004 06:58:55 +0200
From: Matthias Klose <email address hidden>
To: <email address hidden>
Subject: atlas3: FTBFS on more than one architecture

Package: atlas3
Version: 3.6.0-4
Severity: serious

Fails on hppa, sparc, m68k, s390, arm, powerpc, ia64, succeeded on
mips, mipsel, alpha.

Revision history for this message

Debian Bug Importer (debzilla) wrote on 2004-06-25:

#5

Message-ID: <email address hidden>
Date: 14 Apr 2004 15:48:44 -0400
From: Camm Maguire <email address hidden>
To: Matthias Klose <email address hidden>
Cc: <email address hidden>, <email address hidden>,
<email address hidden>, <email address hidden>,
<email address hidden>, <email address hidden>,
<email address hidden>, <email address hidden>
Subject: Re: Bug#243447: atlas3: FTBFS on more than one architecture

Greetings! Just a quick inquiry -- you are not directly
build-depending on atlas3, are you? You can build-depend on either
refblas3-dev/lapack3-dev or libblas-3.so/liblapack-3.so and still get
the automatic benefit of atlas speedups where available and defaulting
to the reference versions elsewhere. Getting atlas to compile is a
lot of work, all of which I will not have any time soon, alas. Would
be happy to help interested porters accomplish same.

Take care,

Matthias Klose <email address hidden> writes:

> Package: atlas3
> Version: 3.6.0-4
> Severity: serious
>
> Fails on hppa, sparc, m68k, s390, arm, powerpc, ia64, succeeded on
> mips, mipsel, alpha.
>
>
>
>
>

--
Camm Maguire <email address hidden>
==========================================================================
"The earth is but one country, and mankind its citizens." -- Baha'u'llah

Revision history for this message

Debian Bug Importer (debzilla) wrote on 2004-06-25:

#6

Download full text (4.2 KiB)

Message-ID: <email address hidden>
Date: 07 Jun 2004 14:00:40 -0400
From: Camm Maguire <email address hidden>
To: <email address hidden> (R Clint Whaley)
Cc: <email address hidden>, <email address hidden>,
<email address hidden>
Subject: Re: [Math-atlas-devel] segfault in sparc in ATL_zupKBmm8_8_1_bX.c:467
(xzl3blastst, TRSM)

Greetings!

<email address hidden> (R Clint Whaley) writes:

> Camm,
>
> >Greetings! The suggested fix has gotten me past the error, and likely
> >will get me through the complete test suite, which is still in
> >progress, otherwise I'll let you know. Thanks again!
>
> I just noticed you are not signed up for the error list. I sent out a message
> about that error on the list when the error was found. You probably want to
> sign up. I send out a message for every major ATLAS error (i.e., any error
> that will produce a wrong answer or fault on a successfully installed stable)
> on that list. See:
> http://math-atlas.sourceforge.net/faq.html#lists
> It's very low traffic.
>

OK, will subscribe.

> >My understanding is that the only subarch specific codes in 3.6.0 which
> >will not run (however non-optimally) on at least some machines of the
> >given general cpu architecture fall into one of the following
> >categories:
> >
> >sse1
> >sse2
> >3dnow
> >altivec
> >ultrasparc
> >alpha ev6
> >
> >Please correct me if wrong. Specifically, if one has gnu tools only
> >(no icc, etc.), is there a difference between Itan and Itan2? Is
> >either build not executable on the other cpu? I'm supposing if not,
> >the Itan2 is the better default for Debian ia64.
>
> I believe this is true. However, the Itan2 may run very slow on an Itan1.
> The difference in their kernels, as I recall, is the number of registers
> used. I was unable to get access to a Itan1, so I was never sure if the
> extra registers were due to better register handling in gcc, or due to
> architectural differences. If gcc is the culprit, Itan2 defaults should
> be great for Itan1. If the difference is not gcc, Itan2 defaults may
> cause register spills within the kernel's innermost loop, which could be
> disastrous.
>
> I suppose another approach would be to install an older gcc on an Itanium2,
> and see if the present kernel blows. From the old dev2stable page, it looks
> like gcc 3.0 was used on the last Itanium1 I had access to.
>

Thanks! Since Itan2 is the future, and since I'm not really sure how
many users in ia64 land we have, I think we should go with Itan2 as
the default for now and see if anyone complains :-). I just wanted to
make sure there would be no SIGILL on Itan1...

We've got the following builds and their 'build records' well in hand:
(To refresh your memory, I've put in a little facility for replaying a
successful build without any timing on a machine which possibly does
not support the isa extensions compiled into the lib -- these are
'build records')

i386:
        base
        3dnow
        sse
        sse2

powerpc:
base
altivec

sparc:
base
v9

alpha:
base
ev5

ia64,s390,mips,mipsel,amd64,hppa:
base

I'm down to two platforms on...

Message-ID: <54zn7ffdtj.fsf@intech19.enhanced.com>
Date: 07 Jun 2004 14:00:40 -0400
From: Camm Maguire <camm@enhanced.com>
To: rwhaley@cs.utk.edu (R Clint Whaley)
Cc: math-atlas-devel@lists.sourceforge.net, 243447@bugs.debian.org,
	243447-submitter@bugs.debian.org
Subject: Re: [Math-atlas-devel] segfault in sparc in ATL_zupKBmm8_8_1_bX.c:467
	(xzl3blastst, TRSM)

Greetings!

rwhaley@cs.utk.edu (R Clint Whaley) writes:

> Camm,
> 
> >Greetings!  The suggested fix has gotten me past the error, and likely
> >will get me through the complete test suite, which is still in
> >progress, otherwise I'll let you know.  Thanks again!
> 
> I just noticed you are not signed up for the error list.  I sent out a message
> about that error on the list when the error was found.  You probably want to
> sign up.  I send out a message for every major ATLAS error (i.e., any error
> that will produce a wrong answer or fault on a successfully installed stable)
> on that list.  See:
>    http://math-atlas.sourceforge.net/faq.html#lists
> It's very low traffic.
>

OK, will subscribe.

> >My understanding is that the only subarch specific codes in 3.6.0 which
> >will not run (however non-optimally) on at least some machines of the
> >given general cpu architecture fall into one of the following
> >categories:
> >
> >sse1 
> >sse2
> >3dnow
> >altivec
> >ultrasparc
> >alpha ev6
> >
> >Please correct me if wrong.  Specifically, if one has gnu tools only
> >(no icc, etc.), is there a difference between Itan and Itan2?  Is
> >either build not executable on the other cpu?  I'm supposing if not,
> >the Itan2 is the better default for Debian ia64.
> 
> I believe this is true.  However, the Itan2 may run very slow on an Itan1.
> The difference in their kernels, as I recall, is the number of registers
> used.  I was unable to get access to a Itan1, so I was never sure if the
> extra registers were due to better register handling in gcc, or due to
> architectural differences.  If gcc is the culprit, Itan2 defaults should
> be great for Itan1.  If the difference is not gcc, Itan2 defaults may
> cause register spills within the kernel's innermost loop, which could be
> disastrous.
> 
> I suppose another approach would be to install an older gcc on an Itanium2,
> and see if the present kernel blows.  From the old dev2stable page, it looks
> like gcc 3.0 was used on the last Itanium1 I had access to.
>

Thanks!  Since Itan2 is the future, and since I'm not really sure how
many users in ia64 land we have, I think we should go with Itan2 as
the default for now and see if anyone complains :-).  I just wanted to
make sure there would be no SIGILL on Itan1...

We've got the following builds and their 'build records' well in hand:
(To refresh your memory, I've put in a little facility for replaying a
successful build without any timing on a machine which possibly does
not support the isa extensions compiled into the lib -- these are
'build records')

i386:
        base
        3dnow
        sse
        sse2

powerpc:
        base
        altivec

sparc:
        base
        v9

alpha:
        base
        ev5

ia64,s390,mips,mipsel,amd64,hppa:
        base

I'm down to two platforms on which completing a build is proving
difficult:

1) arm:  Why would one want to do this one asks?  Good question, but
   in principle there may be some benefit to users of embedded devices
   and pdas, where this chip is quite popular.  First, there is some
   instability in the cpu timer for which I need to file a bug with
   the kernel or libc maintainer, but haven't yet.  Am defaulting to
   -DWALL right now and am getting further, but as I don't have
   control of these machines and their load, I need higher reps
   apparently.  If you could look at

http://buildd.debian.org/fetch.php?&pkg=atlas3&ver=3.6.0-12&arch=arm&stamp=1086618196&file=log&as=raw

and comment if you have a moment I'd be grateful.

2) m68k:  This appears to merely require a longer 'inactivity'
   timeout.  The killer step is the final 'ar' (!)

Take care,

> Cheers,
> Clint
> 
> 
>

-- 
Camm Maguire			     			camm@enhanced.com
==========================================================================
"The earth is but one country, and mankind its citizens."  --  Baha'u'llah

Revision history for this message

Matt Zimmerman (mdz) wrote on 2004-07-06:

#8

Remove myself from all these CCs now that we have the warty-bugs mailing list

Revision history for this message

Matt Zimmerman (mdz) wrote on 2004-07-06:

#9

atlas3 has been removed from Warty, hence this bug is NOTWARTY

Revision history for this message

In Debian Bug tracker #243447, Steve Langasek (vorlon) wrote on 2004-07-11:

#10

severity 243447 important
thanks

As the most recent version of atlas3 has been autobuild on all
architectures for which it has previously built (save alpha, which
currently has autobuilder problems), I don't see any reason to justify an
RC severity for this bug.

Thanks,
--
Steve Langasek
postmodern programmer

Revision history for this message

Debian Bug Importer (debzilla) wrote on 2004-07-11:

#11

Message-ID: <email address hidden>
Date: Sat, 10 Jul 2004 23:42:17 -0500
From: Steve Langasek <email address hidden>
To: <email address hidden>
Subject: Re: atlas3: FTBFS on more than one architecture

severity 243447 important
thanks

As the most recent version of atlas3 has been autobuild on all
architectures for which it has previously built (save alpha, which
currently has autobuilder problems), I don't see any reason to justify an
RC severity for this bug.

Thanks,
--
Steve Langasek
postmodern programmer

Revision history for this message

In Debian Bug tracker #243447, Frank Lichtenheld (djpig) wrote on 2004-09-21: severity of 272665 is important, merging 272665 243447

#12

# Automatically generated email from bts, devscripts version 2.8.4
# never build before on these arches
severity 272665 important
merge 272665 243447

Revision history for this message

Debian Bug Importer (debzilla) wrote on 2004-09-22:

#13

Message-Id: <email address hidden>
Date: Wed, 22 Sep 2004 01:42:24 +0200
From: Frank Lichtenheld <email address hidden>
To: <email address hidden>
Subject: severity of 272665 is important, merging 272665 243447

# Automatically generated email from bts, devscripts version 2.8.4
# never build before on these arches
severity 272665 important
merge 272665 243447

Revision history for this message

In Debian Bug tracker #243447, Nelson A. de Oliveira (naoliv) wrote on 2006-12-16: Only FTBFS on arm

#14

retitle 243447 FTBFS on arm
thanks

atlas3 version 3.6.0-20.2 has only failed on arm [1]. All other archs
seem to build atlas3 successfully [2]

[1]http://buildd.debian.org/fetch.cgi?&pkg=atlas3&ver=3.6.0-20.2&arch=arm&stamp=1164057762&file=log
[2]http://people.debian.org/~igloo/status.php?packages=atlas3

Best regards,
Nelson

Revision history for this message

In Debian Bug tracker #243447, Marco Rodrigues (gothicx-sapo) wrote on 2008-04-21: atlas3 has been removed from Debian, closing #243447

#15

Version: 3.6.0-20.6

The atlas3 package has been removed from Debian testing, unstable and
experimental, so I am now closing the bugs that were still opened
against it.

For more information about this package's removal, read
http://bugs.debian.org/473440 . That bug might give the reasons why
this package was removed, and suggestions of possible replacements.

Don't hesitate to reply to this mail if you have any question.

Thank you for your contribution to Debian.

--
Marco Rodrigues

http://Marco.Tondela.org

Revision history for this message

In Debian Bug tracker #243447, Marco Rodrigues (gothicx-sapo) wrote on 2008-04-22: reopening 243447

#16

# Automatically generated email from bts, devscripts version 2.10.11ubuntu5
reopen 243447

Revision history for this message

In Debian Bug tracker #243447, Marco Rodrigues (gothicx-sapo) wrote on 2008-04-22: notfixed 243447 in 3.6.0-20.6

#17

# Automatically generated email from bts, devscripts version 2.10.11ubuntu5
notfixed 243447 3.6.0-20.6

Revision history for this message

In Debian Bug tracker #243447, Marco Rodrigues (gothicx-sapo) wrote on 2008-04-22: reassign 243447 to atlas

#18

# Automatically generated email from bts, devscripts version 2.10.11ubuntu5
reassign 243447 atlas

Revision history for this message

In Debian Bug tracker #243447, Marco Rodrigues (gothicx-sapo) wrote on 2008-04-22: notfixed 272665 in 3.6.0-20.6

#19

# Automatically generated email from bts, devscripts version 2.10.11ubuntu5
notfixed 272665 3.6.0-20.6

Revision history for this message

In Debian Bug tracker #243447, Marco Rodrigues (gothicx-sapo) wrote on 2008-04-22: reassign 272665 to atlas

#20

# Automatically generated email from bts, devscripts version 2.10.11ubuntu5
reassign 272665 atlas

Bug Watch Updater (bug-watch-updater) on 2010-04-30

Changed in atlas3 (Debian):
status:	New → Fix Released

Affects		Status	Importance	Assigned to	Milestone
	atlas3 (Debian)	Fix Released	Unknown	debbugs #243447
	atlas3 (Ubuntu)	Invalid	Medium	Unassigned

Ubuntu
atlas3 package

atlas3: FTBFS on more than one architecture

Bug Description

Other bug subscribers

Remote bug watches

Ubuntuatlas3 package

atlas3: FTBFS on more than one architecture

Bug Description

Other bug subscribers

Remote bug watches

Ubuntu
atlas3 package