From: Matthew D S. <ako...@gm...> - 2008-05-23 08:48:55
|
running sh run-tests.sh on the current cvs stops and idles (no cpu activity) with the following set of messages: WARNING: Timer #<TIMER {10039D6111}> failed to interrupt thread #<SB- THREAD:THREAD {10039D5AB1}>. WARNING: Timer #<TIMER "ticker 4" {100281E811}> failed to interrupt thread #<SB- THREAD:THREAD "scheduler 3" {1002E1B6A1}>. WARNING: Timer #<TIMER "ticker 5" {10029040A1}> failed to interrupt thread #<SB- THREAD:THREAD "scheduler 4" {100494C0B1}>. WARNING: Timer #<TIMER "ticker 6" {1002AFBA91}> failed to interrupt thread #<SB- THREAD:THREAD "scheduler 5" {1002821501}>. WARNING: Timer #<TIMER "ticker 7" {1004259A81}> failed to interrupt thread #<SB- THREAD:THREAD "scheduler 6" {1002904CB1}>. WARNING: Timer #<TIMER "ticker 8" {100243DA91}> failed to interrupt thread #<SB- THREAD:THREAD "scheduler 7" {1002B02771}>. WARNING: Timer #<TIMER "ticker 10" {1002440A91}> failed to interrupt thread #<SB-THREAD:THREAD "scheduler 9" {1002446771}>. WARNING: Timer #<TIMER "ticker 9" {10024DDA91}> failed to interrupt thread #<SB- THREAD:THREAD "scheduler 8" {100425A691}>. Removing :sb-thread support allows the test suite to finish, but with the following error: Invalid exit status: timer.impure.lisp test failed, expected 104 return code, got 1 Matt -- "You do not really understand something unless you can explain it to your grandmother." -- Albert Einstein. |
From: Vitaly M. <v.m...@gm...> - 2008-05-23 09:10:28
|
Matthew D Swank <ako...@gm...> writes: > running sh run-tests.sh on the current cvs stops and idles (no cpu > activity) with the following set of messages: It passes sometimes on linux x86-64 -- wbr, Vitaly |
From: Nikodemus S. <nik...@ra...> - 2008-05-23 14:41:06
|
On Fri, May 23, 2008 at 12:10 PM, Vitaly Mayatskikh <v.m...@gm...> wrote: > Matthew D Swank <ako...@gm...> writes: > >> running sh run-tests.sh on the current cvs stops and idles (no cpu >> activity) with the following set of messages: > > It passes sometimes on linux x86-64 Those who see this fail: what does uname -a say, and how fast is the box, approximately? Cheers, -- Nikodemus |
From: Vitaly M. <v.m...@gm...> - 2008-05-23 16:19:19
|
"Nikodemus Siivola" <nik...@ra...> writes: >> It passes sometimes on linux x86-64 > > Those who see this fail: what does uname -a say, and how fast is the > box, approximately? $ uname -a Linux gravicappa.englab.brq.redhat.com 2.6.25.3-18.fc9.x86_64 #1 SMP Tue May 13 04:54:47 EDT 2008 x86_64 x86_64 x86_64 GNU/Linux $ cat /proc/cpuinfo processor : 0 vendor_id : GenuineIntel cpu family : 6 model : 15 model name : Intel(R) Core(TM)2 Duo CPU T7500 @ 2.20GHz stepping : 11 cpu MHz : 800.000 cache size : 4096 KB physical id : 0 siblings : 2 core id : 0 cpu cores : 2 fpu : yes fpu_exception : yes cpuid level : 10 wp : yes flags : fpu vme de pse tsc msr pae mce cx8 apic sep mtrr pge mca cmov pat pse36 clflush dts acpi mmx fxsr sse sse2 ss ht tm pbe syscall nx lm constant_tsc arch_perfmon pebs bts rep_good pni monitor ds_cpl vmx est tm2 ssse3 cx16 xtpr lahf_lm ida bogomips : 4447.52 clflush size : 64 cache_alignment : 64 address sizes : 36 bits physical, 48 bits virtual power management: processor : 1 vendor_id : GenuineIntel cpu family : 6 model : 15 model name : Intel(R) Core(TM)2 Duo CPU T7500 @ 2.20GHz stepping : 11 cpu MHz : 800.000 cache size : 4096 KB physical id : 0 siblings : 2 core id : 1 cpu cores : 2 fpu : yes fpu_exception : yes cpuid level : 10 wp : yes flags : fpu vme de pse tsc msr pae mce cx8 apic sep mtrr pge mca cmov pat pse36 clflush dts acpi mmx fxsr sse sse2 ss ht tm pbe syscall nx lm constant_tsc arch_perfmon pebs bts rep_good pni monitor ds_cpl vmx est tm2 ssse3 cx16 xtpr lahf_lm ida bogomips : 4388.79 clflush size : 64 cache_alignment : 64 address sizes : 36 bits physical, 48 bits virtual power management: -- wbr, Vitaly |
From: R. S. <nab...@gm...> - 2008-05-23 18:35:50
|
On Fri, May 23, 2008 at 4:40 PM, Nikodemus Siivola <nik...@ra...> wrote: > On Fri, May 23, 2008 at 12:10 PM, Vitaly Mayatskikh > <v.m...@gm...> wrote: >> Matthew D Swank <ako...@gm...> writes: >> >>> running sh run-tests.sh on the current cvs stops and idles (no cpu >>> activity) with the following set of messages: >> >> It passes sometimes on linux x86-64 > > Those who see this fail: what does uname -a say, and how fast is the > box, approximately? > rafal@delta:~/public/sbcl-git/tests$ uname -a Linux delta 2.6.24-17-generic #1 SMP Thu May 1 13:57:17 UTC 2008 x86_64 GNU/Linux rafal@delta:~/public/sbcl-git/tests$ gcc -v Using built-in specs. Cel: x86_64-linux-gnu Opcje konfiguracji: ../src/configure -v --enable-languages=c,c++,fortran,objc,obj-c++,treelang --prefix=/usr --enable-shared --with-system-zlib --libexecdir=/usr/lib --without-included-gettext --enable-threads=posix --enable-nls --with-gxx-include-di r=/usr/include/c++/4.2 --program-suffix=-4.2 --enable-clocale=gnu --enable-libstdcxx-debug --enable-objc-gc --enable-mpfr --e nable-checking=release --build=x86_64-linux-gnu --host=x86_64-linux-gnu --target=x86_64-linux-gnu Model wątków: posix gcc wersja 4.2.3 (Ubuntu 4.2.3-2ubuntu7) rafal@delta:~/public/sbcl-git/tests$ cat /proc/cpuinfo processor : 0 vendor_id : GenuineIntel cpu family : 6 model : 15 model name : Intel(R) Core(TM)2 Duo CPU E4500 @ 2.20GHz stepping : 13 cpu MHz : 1200.000 cache size : 2048 KB physical id : 0 siblings : 2 core id : 0 cpu cores : 2 fpu : yes fpu_exception : yes cpuid level : 10 wp : yes flags : fpu vme de pse tsc msr pae mce cx8 apic sep mtrr pge mca cmov pat pse36 clflush dts acpi mmx fxsr sse sse2 ss ht tm pbe syscall lm constant_tsc arch_perfmon pebs bts rep_good pni monitor ds_cpl est tm2 ssse3 cx16 xtpr lahf_lm bogomips : 4403.08 clflush size : 64 cache_alignment : 64 address sizes : 36 bits physical, 48 bits virtual power management: processor : 1 vendor_id : GenuineIntel cpu family : 6 model : 15 model name : Intel(R) Core(TM)2 Duo CPU E4500 @ 2.20GHz stepping : 13 cpu MHz : 1200.000 cache size : 2048 KB physical id : 0 siblings : 2 core id : 1 cpu cores : 2 fpu : yes fpu_exception : yes cpuid level : 10 wp : yes flags : fpu vme de pse tsc msr pae mce cx8 apic sep mtrr pge mca cmov pat pse36 clflush dts acpi mmx fxsr sse sse2 ss ht tm pbe syscall lm constant_tsc arch_perfmon pebs bts rep_good pni monitor ds_cpl est tm2 ssse3 cx16 xtpr lahf_lm bogomips : 4399.87 clflush size : 64 cache_alignment : 64 address sizes : 36 bits physical, 48 bits virtual power management: -- Pozdrawiam, Rafal Strzalinski (nabla) http://nablaone.net |
From: Stas B. <sta...@gm...> - 2008-05-24 00:28:14
|
On 5/23/08, Nikodemus Siivola <nik...@ra...> wrote: > On Fri, May 23, 2008 at 12:10 PM, Vitaly Mayatskikh > <v.m...@gm...> wrote: > > Matthew D Swank <ako...@gm...> writes: > > > >> running sh run-tests.sh on the current cvs stops and idles (no cpu > >> activity) with the following set of messages: > > > > It passes sometimes on linux x86-64 > > > Those who see this fail: what does uname -a say, and how fast is the > box, approximately? % uname -a Linux laptop 2.6.26-rc3 #1 SMP PREEMPT Fri May 23 19:38:58 MSD 2008 x86_64 GNU/Linux % cat /proc/cpuinfo | egrep "model name|bogomips|cache size" model name : Intel(R) Core(TM)2 Duo CPU T5250 @ 1.50GHz cache size : 2048 KB bogomips : 2998.66 model name : Intel(R) Core(TM)2 Duo CPU T5250 @ 1.50GHz cache size : 2048 KB bogomips : 2993.22 -- With Best Regards, Stas. |
From: Matthew D S. <ako...@gm...> - 2008-05-23 16:29:20
|
On Fri, 23 May 2008 17:40:56 +0300, Nikodemus Siivola wrote: > On Fri, May 23, 2008 at 12:10 PM, Vitaly Mayatskikh > <v.m...@gm...> wrote: >> Matthew D Swank <ako...@gm...> writes: >> >>> running sh run-tests.sh on the current cvs stops and idles > > Those who see this fail: what does uname -a say, and how fast is the > box, approximately? > $ uname -a Linux inky 2.6.24-17-generic #1 SMP Thu May 1 13:57:17 UTC 2008 x86_64 GNU/Linux $ gcc -v Using built-in specs. Target: x86_64-linux-gnu Configured with: ../src/configure -v --enable-languages=c,c+ +,fortran,objc,obj-c++,treelang --prefix=/usr --enable-shared --with- system-zlib --libexecdir=/usr/lib --without-included-gettext --enable- threads=posix --enable-nls --with-gxx-include-dir=/usr/include/c++/4.2 -- program-suffix=-4.2 --enable-clocale=gnu --enable-libstdcxx-debug -- enable-objc-gc --enable-mpfr --enable-checking=release --build=x86_64- linux-gnu --host=x86_64-linux-gnu --target=x86_64-linux-gnu Thread model: posix gcc version 4.2.3 (Ubuntu 4.2.3-2ubuntu7) $ cat /proc/cpuinfo processor : 0 vendor_id : GenuineIntel cpu family : 6 model : 15 model name : Intel(R) Core(TM)2 Duo CPU T7500 @ 2.20GHz stepping : 11 cpu MHz : 800.000 cache size : 4096 KB physical id : 0 siblings : 2 core id : 0 cpu cores : 2 fpu : yes fpu_exception : yes cpuid level : 10 wp : yes flags : fpu vme de pse tsc msr pae mce cx8 apic sep mtrr pge mca cmov pat pse36 clflush dts acpi mmx fxsr sse sse2 ss ht tm pbe syscall nx lm constant_tsc arch_perfmon pebs bts rep_good pni monitor ds_cpl vmx est tm2 ssse3 cx16 xtpr lahf_lm ida bogomips : 4395.52 clflush size : 64 cache_alignment : 64 address sizes : 36 bits physical, 48 bits virtual power management: processor : 1 vendor_id : GenuineIntel cpu family : 6 model : 15 model name : Intel(R) Core(TM)2 Duo CPU T7500 @ 2.20GHz stepping : 11 cpu MHz : 800.000 cache size : 4096 KB physical id : 0 siblings : 2 core id : 1 cpu cores : 2 fpu : yes fpu_exception : yes cpuid level : 10 wp : yes flags : fpu vme de pse tsc msr pae mce cx8 apic sep mtrr pge mca cmov pat pse36 clflush dts acpi mmx fxsr sse sse2 ss ht tm pbe syscall nx lm constant_tsc arch_perfmon pebs bts rep_good pni monitor ds_cpl vmx est tm2 ssse3 cx16 xtpr lahf_lm ida bogomips : 4388.86 clflush size : 64 cache_alignment : 64 address sizes : 36 bits physical, 48 bits virtual power management: -- "You do not really understand something unless you can explain it to your grandmother." -- Albert Einstein. |
From: Matthew D S. <ako...@gm...> - 2008-05-23 16:35:09
|
On Fri, 23 May 2008 11:10:22 +0200, Vitaly Mayatskikh wrote: > Matthew D Swank <ako...@gm...> writes: > >> running sh run-tests.sh on the current cvs stops and idles (no cpu >> activity) with the following set of messages: > > It passes sometimes on linux x86-64 Well certainly (on my machine) the test suite is not deterministic in where it fails. My last failure stopped here: // Running /home/singollo/root/src/sbcl/sbcl-test/tests/threads.pure.lisp Matt -- "You do not really understand something unless you can explain it to your grandmother." -- Albert Einstein. |
From: Matthew D S. <ako...@gm...> - 2008-05-24 05:46:22
|
On Fri, 23 May 2008 17:40:56 +0300, Nikodemus Siivola wrote: > On Fri, May 23, 2008 at 12:10 PM, Vitaly Mayatskikh > <v.m...@gm...> wrote: >> Matthew D Swank <ako...@gm...> writes: >> >>> running sh run-tests.sh on the current cvs stops and idles (no cpu >>> activity) with the following set of messages: >> > > Those who see this fail: what does uname -a say, and how fast is the > box, approximately? > the test suite also manages to hang on a multi-threaded 32 bit build here // Running /home/singollo/root/src/sbcl/sbcl-build/tests/timer.impure.lisp . . . . WARNING: Timer #<TIMER {B9CB099}> failed to interrupt thread #<SB-THREAD:THREAD {B9C9331}>. $ uname -a Linux cecil 2.6.24-gentoo-r4 #1 PREEMPT Thu Apr 3 16:08:48 CDT 2008 i586 AMD-K6(tm)-III Processor AuthenticAMD GNU/Linux $ gcc -v Using built-in specs. Target: i586-pc-linux-gnu Configured with: /var/tmp/portage/sys-devel/gcc-4.1.2/work/gcc-4.1.2/ configure --prefix=/usr --bindir=/usr/i586-pc-linux-gnu/gcc-bin/4.1.2 -- includedir=/usr/lib/gcc/i586-pc-linux-gnu/4.1.2/include --datadir=/usr/ share/gcc-data/i586-pc-linux-gnu/4.1.2 --mandir=/usr/share/gcc-data/i586- pc-linux-gnu/4.1.2/man --infodir=/usr/share/gcc-data/i586-pc-linux- gnu/4.1.2/info --with-gxx-include-dir=/usr/lib/gcc/i586-pc-linux- gnu/4.1.2/include/g++-v4 --host=i586-pc-linux-gnu --build=i586-pc-linux- gnu --disable-altivec --enable-nls --without-included-gettext --with- system-zlib --disable-checking --disable-werror --enable-secureplt -- disable-libunwind-exceptions --disable-multilib --enable-libmudflap -- disable-libssp --disable-libgcj --enable-languages=c,c++,objc,fortran -- enable-shared --enable-threads=posix --enable-__cxa_atexit --enable- clocale=gnu Thread model: posix gcc version 4.1.2 (Gentoo 4.1.2) $ cat /proc/cpuinfo processor : 0 vendor_id : AuthenticAMD cpu family : 5 model : 13 model name : AMD-K6(tm)-III Processor stepping : 4 cpu MHz : 531.585 cache size : 128 KB fdiv_bug : no hlt_bug : no f00f_bug : no coma_bug : no fpu : yes fpu_exception : yes cpuid level : 1 wp : yes flags : fpu vme de pse tsc msr cx8 pge mmx syscall 3dnowext 3dnow k6_mtrr ts fid vid bogomips : 1064.02 clflush size : 32 Matt -- "You do not really understand something unless you can explain it to your grandmother." -- Albert Einstein. |
From: Christophe R. <cs...@ca...> - 2008-05-24 06:22:59
|
Matthew D Swank <ako...@gm...> writes: > the test suite also manages to hang on a multi-threaded 32 bit build here > // Running /home/singollo/root/src/sbcl/sbcl-build/tests/timer.impure.lisp > . > . > . > . > WARNING: > Timer #<TIMER {B9CB099}> failed to interrupt thread #<SB-THREAD:THREAD > {B9C9331}>. I saw this once, too, last night. It's not systematic on my laptop -- but even when this doesn't happen, timer.impure.lisp reports a test failure. Cheers, Christophe |
From: Nikodemus S. <nik...@ra...> - 2008-05-26 18:21:02
|
timer.impure.lisp hanging appears not to be a regression as such (but possibly recent changes have made the system more suspectible to a problem that has always existed). What happens is that when stress-testing signal handler scheduling and unscheduling two threads are trying to interrupt each other using pthread_kill: the other from gc_stop_the_world, and the other from signal_interrupt_thread, and both just keep getting EAGAIN. ...dunno yet know why for sure, but I suspect the fast timers used in that test simply end up flooding the process interrupt queue, so that nothing else gets delivered. Occasionally such a seeming hang unwedges itself after several minutes, but sometimes they seem quite permanent. Invalid exit status on the other hand is symptom of the last test being too brittle. The WARNINGs re. failed interrupts have nothing to do with each other, and are harmless. I am committing a comment regarding the first one, and a fix for the second one, but possibly we should disable the whole :schedule-stress test for now (and record this to BUGS.) Cheers, -- Nikodemus |