Hide Forgot
Description of problem: A bug fix (3.4.3) for Octave was released on October 11, 2011. Current on Fedora is 3.4.2, and should be updated. Version-Release number of selected component (if applicable): octave-3.4.2-2.fc15.i686 How reproducible: Always reproducible on 3.4.2. Works fine on 3.4.3 compiled from source. Steps to Reproduce: 1. size(A) = [881,301] % A not attached, size xz-compressed about 1.5 MB. 2. A\zeros(881,1) 3. Actual results: octave:149> A\zeros(881,1) ** On entry to DLASCL parameter number 4 had an illegal value error: exception encountered in Fortran subroutine dgelsd_ Expected results: Should return a vector with size 301x1 and filled with zeros. Additional info: http://www.gnu.org/software/octave/NEWS-3.4.html says ** Octave 3.4.3 is a bug fixing release.
octave-3.4.3-1.fc15 has been submitted as an update for Fedora 15. https://admin.fedoraproject.org/updates/octave-3.4.3-1.fc15
octave-3.4.3-1.fc16 has been submitted as an update for Fedora 16. https://admin.fedoraproject.org/updates/octave-3.4.3-1.fc16
Package octave-3.4.3-1.fc15: * should fix your issue, * was pushed to the Fedora 15 testing repository, * should be available at your local mirror within two days. Update it with: # su -c 'yum update --enablerepo=updates-testing octave-3.4.3-1.fc15' as soon as you are able to. Please go to the following url: https://admin.fedoraproject.org/updates/FEDORA-2011-15244 then log in and leave karma (feedback).
octave-3.4.3-1.fc15 has been pushed to the Fedora 15 stable repository. If problems still persist, please make note of it in this bug report.
octave-3.4.3-1.fc16 has been pushed to the Fedora 16 stable repository. If problems still persist, please make note of it in this bug report.
Works now fine with octave-3.4.3-1.fc16.i686, but with a twist. I had installed atlas-3.8.4-1.fc16.i686, and then I got the aforementioned error. After removal of atlas, it works. atlas-sse and atlas-sse2 seem to be ok. Might have been that octave compiled from source was linked to lapack-3.3.1-1.fc15.rpm. Also, if matrix A was saved to file in ascii presentation using save debug.mat A then it worked, but binary presentation save -binary debug.mat A was able to reproduce the error. Summary: works without the atlas-3.8.4-1.fc16.i686 . If the bug is transfeered to atlas component, I can attach the test case, if someone wants to dig into it.
Jaakko: Please attach the contents of /proc/cpuinfo. This sounds like the default version of ATLAS assumes too much from the processor (SSE3 support comes to mind).
# cat /proc/cpuinfo processor : 0 vendor_id : GenuineIntel cpu family : 6 model : 13 model name : Intel(R) Pentium(R) M processor 1.73GHz stepping : 8 cpu MHz : 800.000 cache size : 2048 KB fdiv_bug : no hlt_bug : no f00f_bug : no coma_bug : no fpu : yes fpu_exception : yes cpuid level : 2 wp : yes flags : fpu vme de pse tsc msr pae mce cx8 apic mtrr pge mca cmov clflush dts acpi mmx fxsr sse sse2 ss tm pbe nx up bts est tm2 bogomips : 1596.27 clflush size : 64 cache_alignment : 64 address sizes : 32 bits physical, 32 bits virtual power management: case FAIL: $ rpm -qa| grep atlas atlas-sse-3.8.4-1.fc16.i686 atlas-sse3-3.8.4-1.fc16.i686 atlas-sse2-3.8.4-1.fc16.i686 atlas-3.8.4-1.fc16.i686 $ ldd /usr/bin/octave| grep lapack liblapack.so.3 => /usr/lib/atlas/liblapack.so.3 (0x00ef4000) case OK: $ rpm -qa| grep atlas atlas-sse-3.8.4-1.fc16.i686 atlas-sse3-3.8.4-1.fc16.i686 atlas-sse2-3.8.4-1.fc16.i686 $ ldd /usr/bin/octave| grep lapack liblapack.so.3 => /usr/lib/atlas-sse2/liblapack.so.3 (0x00f69000)
Created attachment 535132 [details] octave testcase for dgelsd-function from lapack octave commands to reproduce the bug with octave linked to /usr/lib/atlas/liblapack.so.3 with the attached file containing the matrix A load debug_A.mat A\zeros(881,1);
Exactly. The ATLAS build log at http://kojipkgs.fedoraproject.org/packages/atlas/3.8.4/1.fc16/data/logs/i686/build.log reveals that the base package is compiled with SSE3, which is not supported by your processor. Please file a bug against ATLAS - the base package should not assume the SSE3 instruction set to be present.
*** This bug has been marked as a duplicate of bug 756121 ***