Re: [Stretch] Status for architecture qualification
Hi Alex! On 06/09/2016 06:44 AM, Alex McWhirter wrote: > If it helps i have access to a decent amount of gear. E6K, V210, V215, > M4000, T1000, T5120, Netra X1, Blade 150, and a V890. Thanks for the offer. We don't actually lack any hardware, but what we need is new off-the-shelf hardware that would be used to set up the infrastructure for the sparc64 when it becomes an officially supported port in Debian, a so-called release architecture. The Debian System Adminstrators (DSA) have the requirement that the hardware they set up for the official buildds and porterboxes is new and not used, old hardware which might fall apart while being used for critical infrastructure. Debian's release architectures come with active security support and for that, the buildds infrastructure needs to be there with high availability to be able to build updated packages with security patches the moment they become available. > I've been working on the sparc64 port of Gentoo for quite a while. If > there are issues that need addressed for Debian i'm willing to help out > with the effort. Some unresolved sparc64-related bugs can be found here: > https://bugs.debian.org/cgi-bin/pkgreport.cgi?tag=sparc64;users=debian-sparc@lists.debian.org You can find more issues if you look at the list of packages with state "Build Attempted" in the buildd database: > https://buildd.debian.org/status/architecture.php?a=sparc64&suite=sid Oh, and btw, please upstream any changes you have made in Gentoo to fix bugs on sparc64. Do you have patches available for the problems with the testsuites of pulseaudio, util-linux and glibc. Or did you skip the testsuites for these packages? > Seems like most of the issues are either bad coding practices or little > mistakes. True. Another example for that is kdevelop-php: > https://buildd.debian.org/status/package.php?p=kdevelop-php&suite=sid As you can see, the build fails due to unaligned access: [ 1%] Generating phptokentype.h, phpdebugvisitor.h, phptokentext.h, phpast.h, phpparser.h, phpparser.cpp, phpvisitor.h, phpvisitor.cpp, phpdefaultvisitor.h, phpdefaultvisitor.cpp cd /<>/obj-sparc64-linux-gnu/parser && /usr/bin/kdev-pg-qt --output=php --namespace=Php --debug-visitor /<>/parser/php.g Bus error parser/CMakeFiles/kdev4phpparser.dir/build.make:66: recipe for target 'parser/phptokentype.h' failed make[3]: *** [parser/phptokentype.h] Error 138 which is usually easy to track down with gdb. Thanks for your help! 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 Sparc 7.10.0 Install Problems
Hello Chris! On 06/08/2016 06:56 PM, Chris wrote: > 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. Debian Wheezy is already no longer supported, except for the LTS branch which deals with i386 and amd64 architectures only. Thus, any issues you may have that are related to bugs will never be fixed. Plus, since Debian Wheezy, we have fixed a large number of bugs which affect both sparc and sparc64. In particular, kernel development has been very active in the past 12 months since Oracle decided to release their own distribution called "Linux for SPARC". > It would be interesting to get a build > environment running, but are there any resources out there to > get started ?. There must be an overall dev process involved which > I need to understand before contributing anything. That depends on what you want to do. Whether it's kernel development, Debian packaging or improving other upstream projects such as GNOME or KDE. You need to be more specific. > Apart from the usual 32 bit Sparcstation class machines, > have an Ultra 1, several Ultra II and V240, V215/245, T2000 and > T5220. Could set any of those up to provide ssh / ftp login, > whatever, if that would be useful to the group... 32-bit SPARC hardware is completely unsupported these days. I think support for that was even dropped in the Linux kernel. You are welcome to perform test installations on your hardware with the ISO I have provided and report back any feedback. But we don't need any additional old hardware. What we need to make "sparc64" an official supported port in Debian is actual new hardware. This is one of the requirements by the Debian System Administrators (DSA) as they don't want to deal with old hardware breaking apart when building packages for a release architecture. 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: [Stretch] Status for architecture qualification
If it helps i have access to a decent amount of gear. E6K, V210, V215, M4000, T1000, T5120, Netra X1, Blade 150, and a V890. I've been working on the sparc64 port of Gentoo for quite a while. If there are issues that need addressed for Debian i'm willing to help out with the effort. Seems like most of the issues are either bad coding practices or little mistakes.
Re: [sparc] niagara2 cpu, opcodes not available message?
From: Anatoly Pugachev Date: Wed, 8 Jun 2016 20:30:40 +0300 > Can someone please tell, why do we get a bunch of the following > messages on niagara2 cpu hardware (SPARC Enterprise T5120, T5220, > T5140, and T5240 servers) > > Asking, because I see the following lines on kernel boot (removing > first field boot time stamp in cut): > > mator@nvg5120:~/linux-sparc-boot-logs/t5120$ grep opcode > dmesg-4.7.0-rc2+.log | cut -f2- -d' ' | sort | uniq -c > 4 aes_sparc64: sparc64 aes opcodes not available. > 7 camellia_sparc64: sparc64 camellia opcodes not available. > 37 crc32c_sparc64: sparc64 crc32c opcode not available. > 5 des_sparc64: sparc64 des opcodes not available. > 4 md5_sparc64: sparc64 md5 opcode not available. > 1 sha1_sparc64: sparc64 sha1 opcode not available. > 2 sha256_sparc64: sparc64 sha256 opcode not available. > 3 sha512_sparc64: sparc64 sha512 opcode not available. Because the drivers unconditionally try to load, check the CPU capabilites and emit the log message if the cpu caps aren't present. I don't see what the problem is, everying is working as designed.
Re: [sparc] niagara2 cpu, opcodes not available message?
On Wed, Jun 8, 2016 at 8:30 PM, Anatoly Pugachev wrote: > Hello! > > Can someone please tell, why do we get a bunch of the following > messages on niagara2 cpu hardware (SPARC Enterprise T5120, T5220, > T5140, and T5240 servers) > > Asking, because I see the following lines on kernel boot (removing > first field boot time stamp in cut): > > mator@nvg5120:~/linux-sparc-boot-logs/t5120$ grep opcode > dmesg-4.7.0-rc2+.log | cut -f2- -d' ' | sort | uniq -c > 4 aes_sparc64: sparc64 aes opcodes not available. > 7 camellia_sparc64: sparc64 camellia opcodes not available. > 37 crc32c_sparc64: sparc64 crc32c opcode not available. > 5 des_sparc64: sparc64 des opcodes not available. > 4 md5_sparc64: sparc64 md5 opcode not available. > 1 sha1_sparc64: sparc64 sha1 opcode not available. > 2 sha256_sparc64: sparc64 sha256 opcode not available. > 3 sha512_sparc64: sparc64 sha512 opcode not available. > > Can we probably remove this functionality/messages from niagara2 cpus, > if it does not support it anyway? Wasn't clear at all, I mean can we please change pr_info in arch/sparc/crypto/ to pr_debug in xx_sparc64_mod_init() functions? Thanks.
Re: Debian Sparc 7.10.0 Install Problems
> on a V210, with gui which is stable. Problem is that none of the > repositories for Squeeze work any more and it's not clear if they > are available somewhere else, or have just been deleted ?. Squeeze has been moved to the debian archive. This sources.list snippet should work: deb http://archive.debian.org/debian-archive/debian squeeze main contrib non-free deb-src http://archive.debian.org/debian-archive/debian squeeze main contrib non-free Best regards, Tom
Re: [sparc] niagara2 cpu, opcodes not available message?
On Jun 8, 2016 8:30 PM, "Anatoly Pugachev" wrote: > > Hello! > > Can someone please tell, why do we get a bunch of the following > messages on niagara2 cpu hardware (SPARC Enterprise T5120, T5220, > T5140, and T5240 servers) > > Asking, because I see the following lines on kernel boot (removing > first field boot time stamp in cut): > > mator@nvg5120:~/linux-sparc-boot-logs/t5120$ grep opcode > dmesg-4.7.0-rc2+.log | cut -f2- -d' ' | sort | uniq -c > 4 aes_sparc64: sparc64 aes opcodes not available. > 7 camellia_sparc64: sparc64 camellia opcodes not available. > 37 crc32c_sparc64: sparc64 crc32c opcode not available. > 5 des_sparc64: sparc64 des opcodes not available. > 4 md5_sparc64: sparc64 md5 opcode not available. > 1 sha1_sparc64: sparc64 sha1 opcode not available. > 2 sha256_sparc64: sparc64 sha256 opcode not available. > 3 sha512_sparc64: sparc64 sha512 opcode not available. > > Can we probably remove this functionality/messages from niagara2 cpus, > if it does not support it anyway? Wasn't clear at all, I mean can we please change pr_info in arch/sparc/crypto/ to pr_debug in xx_sparc64_mod_init() functions?
[sparc] niagara2 cpu, opcodes not available message?
Hello! Can someone please tell, why do we get a bunch of the following messages on niagara2 cpu hardware (SPARC Enterprise T5120, T5220, T5140, and T5240 servers) Asking, because I see the following lines on kernel boot (removing first field boot time stamp in cut): mator@nvg5120:~/linux-sparc-boot-logs/t5120$ grep opcode dmesg-4.7.0-rc2+.log | cut -f2- -d' ' | sort | uniq -c 4 aes_sparc64: sparc64 aes opcodes not available. 7 camellia_sparc64: sparc64 camellia opcodes not available. 37 crc32c_sparc64: sparc64 crc32c opcode not available. 5 des_sparc64: sparc64 des opcodes not available. 4 md5_sparc64: sparc64 md5 opcode not available. 1 sha1_sparc64: sparc64 sha1 opcode not available. 2 sha256_sparc64: sparc64 sha256 opcode not available. 3 sha512_sparc64: sparc64 sha512 opcode not available. But linux kernel sources ( linux-2.6/arch/sparc/kernel/setup_64.c ) define crypto_hwcaps only for CPUs with the following capabilities: static const char *crypto_hwcaps[] = { "aes", "des", "kasumi", "camellia", "md5", "sha1", "sha256", "sha512", "mpmul", "montmul", "montsqr", "crc32c", }; and we don't have them in niagara2 cpu CAPS: mator@nvg5120:~/linux-sparc-boot-logs/t5120$ grep CAPS dmesg-4.7.0-rc2+.log [0.00] CPU CAPS: [flush,stbar,swap,muldiv,v9,blkinit,n2,mul32] [0.00] CPU CAPS: [div32,v8plus,popc,vis,vis2,ASIBlkInit] mator@nvg5120:~/linux-sparc-boot-logs/t5120$ egrep '^cpu|pmu' /proc/cpuinfo cpu : UltraSparc T2 (Niagara2) pmu : niagara2 cpucaps : flush,stbar,swap,muldiv,v9,blkinit,n2,mul32,div32,v8plus,popc,vis,vis2,ASIBlkInit compare, for example, with sparc CPU which support crypto (T5 cpu, landau is machine name): mator@landau:~$ grep CAPS dmesg-4.6.1.txt [0.00] CPU CAPS: [flush,stbar,swap,muldiv,v9,blkinit,n2,mul32] [0.00] CPU CAPS: [div32,v8plus,popc,vis,vis2,ASIBlkInit,fmaf,vis3] [0.00] CPU CAPS: [hpc,ima,pause,cbcond,aes,des,kasumi,camellia] [0.00] CPU CAPS: [md5,sha1,sha256,sha512,mpmul,montmul,montsqr,crc32c] mator@landau:~$ egrep '^cpu|pmu' /proc/cpuinfo cpu : UltraSparc T5 (Niagara5) pmu : niagara5 cpucaps : flush,stbar,swap,muldiv,v9,blkinit,n2,mul32,div32,v8plus,popc,vis,vis2,ASIBlkInit,fmaf,vis3,hpc,ima,pause,cbcond,aes,des,kasumi,camellia,md5,sha1,sha256,sha512,mpmul,montmul,montsqr,crc32c mator@landau:~$ grep opcode dmesg-4.6.1.txt [8537574.887049] aes_sparc64: Using sparc64 aes opcodes optimized AES implementation [8537574.887611] crc32c_sparc64: Using sparc64 crc32c opcode optimized CRC32C implementation [8537576.577455] sha1_sparc64: Using sparc64 sha1 opcode optimized SHA-1 implementation [8537576.578928] sha256_sparc64: Using sparc64 sha256 opcode optimized SHA-256/SHA-224 implementation [8537576.580908] sha512_sparc64: Using sparc64 sha512 opcode optimized SHA-512/SHA-384 implementation [8537576.582964] md5_sparc64: Using sparc64 md5 opcode optimized MD5 implementation [8537576.596984] des_sparc64: Using sparc64 des opcodes optimized DES implementation [8537576.600503] camellia_sparc64: Using sparc64 camellia opcodes optimized CAMELLIA implementation I don't understand why niagara2 cpu getting HWCAP_SPARC_CRYPTO flag if it does not support it. Can we probably remove this functionality/messages from niagara2 cpus, if it does not support it anyway? mator@nvg5120:~$ lsmod | grep -c sparc64 0 mator@landau:~$ lsmod | grep -c sparc64 9 Thanks.
Re: Debian Sparc 7.10.0 Install Problems
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: Debian Sparc 7.10.0 Install Problems
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. I want to start with the last stable release for Sparc, to establish a baseline. I have Squeeze running on a V210, with gui which is stable. Problem is that none of the repositories for Squeeze work any more and it's not clear if they are available somewhere else, or have just been deleted ?. A bit of background: Have been using Sun since Sun 3, the first serious unix machine. Do electronics / embedded sw here, but have never done any Linux dev, submitted patches, done system builds etc. Have done kernel rebuilds on Sun 3 years ago and on Vax 730 BSD 4.3 which took over 3 days to complete :-). It would be interesting to get a build environment running, but are there any resources out there to get started ?. There must be an overall dev process involved which I need to understand before contributing anything. Apart from the usual 32 bit Sparcstation class machines, have an Ultra 1, several Ultra II and V240, V215/245, T2000 and T5220. Could set any of those up to provide ssh / ftp login, whatever, if that would be useful to the group... Regards, Chris
Re: Debian Sparc 7.10.0 Install Problems
On 06/08/2016 05:02 PM, Chris wrote: > I've been trying to get Debian Sparc 7.10.0 installed on a Sun > V215 with an XVR300 graphics card with little success. Wanted > to try 7.10.0, as it seemsto be the last supported Debian for > Sparc. I installed Squeeze onto a V210 with XVR100 a few years > ago and apart from a few config issues, it installed out of the > box and is stable. 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: > https://people.debian.org/~glaubitz/debian-cd/2016-05-04/debian-9.0-sparc64-NETINST-1.iso At the "boot:" prompt, append the following line: preseed/url=https://people.debian.org/~glaubitz/preseed-sparc64.cfg And when installing, please use a minimal setup since the installer has some quirks still and the more packages you are trying to install during installation, the more likely you will run into issues. Just install the bare minimum, then reboot and install the rest over the net. 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
Debian Sparc 7.10.0 Install Problems
I've been trying to get Debian Sparc 7.10.0 installed on a Sun V215 with an XVR300 graphics card with little success. Wanted to try 7.10.0, as it seemsto be the last supported Debian for Sparc. I installed Squeeze onto a V210 with XVR100 a few years ago and apart from a few config issues, it installed out of the box and is stable. 7.10.0 is different. To start, the system won't install at all if a graphics card is in the machine and just hangs during the boot process. No Linux expert, but fwics, the system switches from obp -> boot -> kernel and it looks like at the switch to kernel that the machine hangs with the following: 0.00] Console: colour dummy device 80x25 0.00] Console (tty0) enabled, bootconsole disabled Just not seeing the frame buffer ? Tried a pci XVR100 and a stock pcie ati 2250 with same results. Ok, take the graphics card out and run a text install, which works as expected. Can login, network working etc. Text install allows login with no issues afaics, but as soon as a graphics card is fitted, the sytems again hangs. For reference, reinstalled Squeeze on the same machine with framebuffer fitted, which works as expected. Are there any command line switches to force framebuffer use ?. Have looked at the Lilo page and tried: append "debain-installer/framebuffer=true", as per the Linux Sparc install docs with no success. Must be missing something here, or is it just broken and if so, what is the fix ?. No Linux expert, but the goal is to use Linux or FreeBSD Sparc for embedded development work. Already have a basic cross gcc tool chain built and working on Solaris 10 Sparc, but want to evaluate other OS options as well. As mentioned, no kernel hacker, but have a few older Sun machines that could be contributed to the project foc if that would be any help. Mainly V240 series, but maybe a couple of others as well. In Oxford, Uk... Regards, Chris