Re: Different behavior in the chroot and build services
Hello, Le mardi 31 mai 2011 à 15:33 +0200, Petr Salinger a écrit : Anyway, the difference between buildd and porter machine is also CPU. On one my machine (and seems also on both GNU/kFreeBSD builld) make getarch_2nd fails. The param.h handles OPTERON, but not INTEL_UNKNOWN as generated by getarch 1: Thanks for spotting that. I think it is the issue. Could you share the output of /proc/cpuinfo ? I would like to report a bug upstream on this (looks like it does not fall-back on the generic define if it cannot detect the CPU). Since I have no way to reproduce myself the issue, would you mind to test some stuff for me ? 1) Just apply displayCpuInfo.diff (forceGeneric.diff should not be applied here) and type make getarch 2) Apply forceGeneric.diff it should fix the report issue. If you don't have time for that, no worries. many thanks, Sylvestre -- To UNSUBSCRIBE, email to debian-bsd-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/1307543129.10829.37.ca...@losinj.inria.fr
Re: Different behavior in the chroot and build services
Hi. There have been no attachements. Thanks for spotting that. I think it is the issue. Could you share the output of /proc/cpuinfo ? $ cat /proc/cpuinfo processor : 0 vendor_id : GenuineIntel cpu family : 6 model : 7 model name : QEMU Virtual CPU version 0.12.5 stepping: 3 flags : fpu de pse tsc msr pae mce cx8 apic sep mtrr pge mca cmov pat pse36 b19 mmx fxsr xmm sse2 cpu MHz : 2667.06 bogomips: 2667.06 The real one is Core2 Duo E6750, the kfreebsd-i386 runs inside kvm. Since I have no way to reproduce myself the issue, would you mind to test some stuff for me ? Well, I think you eventually could via qemu/kvm. And the # cpuid: eax ineax ebx ecx edx 0004 756e6547 6c65746e 49656e69 0001 0623 0800 80002001 078bfbfd 0002 0001 002c307d 0003 0004 0003 8000 800a 68747541 444d4163 69746e65 8001 0623 0001 2181abfd 8002 554d4551 72695620 6c617574 55504320 8003 72657620 6e6f6973 312e3020 00352e32 8004 8005 01ff01ff 01ff01ff 40020140 40020140 8006 42004200 02008140 8007 8008 3028 8009 800a 0001 0010 Vendor ID: GenuineIntel; CPUID level 4 Intel-specific functions: Version 0623: Type 0 - Original OEM Family 6 - Pentium Pro Model 2 - Stepping 3 Reserved 0 Extended brand string: QEMU Virtual CPU version 0.12.5 CLFLUSH instruction cache line size: 8 Feature flags 078bfbfd: FPUFloating Point Unit DE Debugging Extensions PSEPage Size Extensions TSCTime Stamp Counter MSRModel Specific Registers PAEPhysical Address Extension MCEMachine Check Exception CX8COMPXCHG8B Instruction APIC On-chip Advanced Programmable Interrupt Controller present and enabled SEPFast System Call MTRR Memory Type Range Registers PGEPTE Global Flag MCAMachine Check Architecture CMOV Conditional Move and Compare Instructions FGPAT Page Attribute Table PSE-36 36-bit Page Size Extension CLFSH CFLUSH instruction MMXMMX instruction set FXSR Fast FP/MMX Streaming SIMD Extensions save/restore SSEStreaming SIMD Extensions instruction set SSE2 SSE2 extensions TLB and cache info: 7d: unknown TLB/cache descriptor 30: unknown TLB/cache descriptor 2c: unknown TLB/cache descriptor Processor serial: -0623---- Petr -- To UNSUBSCRIBE, email to debian-bsd-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/alpine.lrh.2.02.1106090719490.21...@sci.felk.cvut.cz
Different behavior in the chroot and build services
Hello, I am trying to port Openblas / Gotoblas to Kfreebsd. It is building fine with asdfasdf io (chroot unstable) but it fails with the build services: https://buildd.debian.org/status/package.php?p=openblassuite=experimental Any hints ? Thanks Sylvestre PS: Please C/C me. -- To UNSUBSCRIBE, email to debian-bsd-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/1306825316.4606.62.ca...@korcula.inria.fr
Re: Different behavior in the chroot and build services
Hello, I am trying to port Openblas / Gotoblas to Kfreebsd. It is building fine with asdfasdf io (chroot unstable) but it fails with the build services: https://buildd.debian.org/status/package.php?p=openblassuite=experimental Any hints ? Some time-skew ? I guess that getarch_2nd.c should not be compiled during make clean. dh_testroot dh_clean make clean getarch_2nd.c: In function 'main': getarch_2nd.c:12:35: error: 'SGEMM_DEFAULT_UNROLL_M' undeclared (first use in this function) getarch_2nd.c:12:35: note: each undeclared identifier is reported only once for each function it appears in getarch_2nd.c:13:35: error: 'SGEMM_DEFAULT_UNROLL_N' undeclared (first use in this function) getarch_2nd.c:14:35: error: 'DGEMM_DEFAULT_UNROLL_M' undeclared (first use in this function) getarch_2nd.c:15:35: error: 'DGEMM_DEFAULT_UNROLL_N' undeclared (first use in this function) getarch_2nd.c:19:35: error: 'CGEMM_DEFAULT_UNROLL_M' undeclared (first use in this function) getarch_2nd.c:20:35: error: 'CGEMM_DEFAULT_UNROLL_N' undeclared (first use in this function) getarch_2nd.c:21:35: error: 'ZGEMM_DEFAULT_UNROLL_M' undeclared (first use in this function) getarch_2nd.c:22:35: error: 'ZGEMM_DEFAULT_UNROLL_N' undeclared (first use in this function) getarch_2nd.c:29:50: error: 'SGEMM_DEFAULT_Q' undeclared (first use in this function) getarch_2nd.c:30:50: error: 'DGEMM_DEFAULT_Q' undeclared (first use in this function) getarch_2nd.c:31:50: error: 'CGEMM_DEFAULT_Q' undeclared (first use in this function) getarch_2nd.c:32:50: error: 'ZGEMM_DEFAULT_Q' undeclared (first use in this function) make[1]: *** [getarch_2nd] Error 1 -- To UNSUBSCRIBE, email to debian-bsd-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/alpine.lrh.2.02.1105310945070.31...@sci.felk.cvut.cz
Re: Different behavior in the chroot and build services
Hello, Thanks for the quick answer. Le mardi 31 mai 2011 à 09:59 +0200, Petr Salinger a écrit : Hello, I am trying to port Openblas / Gotoblas to Kfreebsd. It is building fine with asdfasdf io (chroot unstable) but it fails with the build services: https://buildd.debian.org/status/package.php?p=openblassuite=experimental Any hints ? Some time-skew ? Pardon my ignorance but what is time-skew ? I guess that getarch_2nd.c should not be compiled during make clean. It is indeed a bug but I don't think it is related to my problem here. Sylvestre -- To UNSUBSCRIBE, email to debian-bsd-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/1306844795.4606.99.ca...@korcula.inria.fr
Re: Different behavior in the chroot and build services
Sylvestre Ledru sylves...@debian.org (31/05/2011): Pardon my ignorance but what is time-skew ? That's described a bit in that documentation: /usr/share/doc/autotools-dev/README.Debian.gz Mraw, KiBi. signature.asc Description: Digital signature
Re: Different behavior in the chroot and build services
Sylvestre Ledru sylves...@debian.org (31/05/2011): OK thanks. However, openblas is not using autotools here... The concept of having files unpacked in this or that order, leading to problems when considering whether a target is up-to-date[*], isn't specific to autotools. [*] Be it because of buggy dependencies in the makefiles, missing tools to rebuild files which might not need to be rebuilt, etc. Mraw, KiBi. signature.asc Description: Digital signature
Re: Different behavior in the chroot and build services
Le mardi 31 mai 2011 à 14:46 +0200, Cyril Brulebois a écrit : Sylvestre Ledru sylves...@debian.org (31/05/2011): Pardon my ignorance but what is time-skew ? That's described a bit in that documentation: /usr/share/doc/autotools-dev/README.Debian.gz OK thanks. However, openblas is not using autotools here... Sylvestre -- To UNSUBSCRIBE, email to debian-bsd-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/1306846129.4606.101.ca...@korcula.inria.fr
Re: Different behavior in the chroot and build services
Anyway, the difference between buildd and porter machine is also CPU. On one my machine (and seems also on both GNU/kFreeBSD builld) make getarch_2nd fails. The param.h handles OPTERON, but not INTEL_UNKNOWN as generated by getarch 1: my machine: #define INTEL_UNKNOWN #define L1_CODE_SIZE 32768 #define L1_CODE_ASSOCIATIVE 8 #define L1_CODE_LINESIZE 64 #define L1_DATA_SIZE 32768 #define L1_DATA_ASSOCIATIVE 8 #define L1_DATA_LINESIZE 64 #define L2_SIZE 524288 #define L2_ASSOCIATIVE 8 #define L2_LINESIZE 64 #define HAVE_CMOV #define HAVE_MMX #define HAVE_SSE #define HAVE_SSE2 #define HAVE_SSE3 #define HAVE_CFLUSH #define NUM_SHAREDCACHE 1 #define NUM_CORES 1 #define CORE_P6 io.debian.net: #define OPTERON #define L1_CODE_SIZE 65536 #define L1_CODE_ASSOCIATIVE 2 #define L1_CODE_LINESIZE 64 #define L1_DATA_SIZE 65536 #define L1_DATA_ASSOCIATIVE 2 #define L1_DATA_LINESIZE 64 #define L2_SIZE 131072 #define L2_ASSOCIATIVE 8 #define L2_LINESIZE 64 #define ITB_SIZE 4096 #define ITB_ASSOCIATIVE 0 #define ITB_ENTRIES 32 #define DTB_SIZE 4096 #define DTB_ASSOCIATIVE 0 #define DTB_ENTRIES 32 #define HAVE_CMOV #define HAVE_MMX #define HAVE_SSE #define HAVE_SSE2 #define HAVE_SSE3 #define HAVE_3DNOWEX #define HAVE_3DNOW #define HAVE_CFLUSH #define NUM_SHAREDCACHE 1 #define NUM_CORES 1 #define CORE_OPTERON -- To UNSUBSCRIBE, email to debian-bsd-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/alpine.lrh.2.02.1105311521010.32...@sci.felk.cvut.cz
