You can subscribe to this list here.
| 2002 |
Jan
|
Feb
|
Mar
|
Apr
|
May
|
Jun
|
Jul
|
Aug
|
Sep
(1) |
Oct
(122) |
Nov
(152) |
Dec
(69) |
|---|---|---|---|---|---|---|---|---|---|---|---|---|
| 2003 |
Jan
(6) |
Feb
(25) |
Mar
(73) |
Apr
(82) |
May
(24) |
Jun
(25) |
Jul
(10) |
Aug
(11) |
Sep
(10) |
Oct
(54) |
Nov
(203) |
Dec
(182) |
| 2004 |
Jan
(307) |
Feb
(305) |
Mar
(430) |
Apr
(312) |
May
(187) |
Jun
(342) |
Jul
(487) |
Aug
(637) |
Sep
(336) |
Oct
(373) |
Nov
(441) |
Dec
(210) |
| 2005 |
Jan
(385) |
Feb
(480) |
Mar
(636) |
Apr
(544) |
May
(679) |
Jun
(625) |
Jul
(810) |
Aug
(838) |
Sep
(634) |
Oct
(521) |
Nov
(965) |
Dec
(543) |
| 2006 |
Jan
(494) |
Feb
(431) |
Mar
(546) |
Apr
(411) |
May
(406) |
Jun
(322) |
Jul
(256) |
Aug
(401) |
Sep
(345) |
Oct
(542) |
Nov
(308) |
Dec
(481) |
| 2007 |
Jan
(427) |
Feb
(326) |
Mar
(367) |
Apr
(255) |
May
(244) |
Jun
(204) |
Jul
(223) |
Aug
(231) |
Sep
(354) |
Oct
(374) |
Nov
(497) |
Dec
(362) |
| 2008 |
Jan
(322) |
Feb
(482) |
Mar
(658) |
Apr
(422) |
May
(476) |
Jun
(396) |
Jul
(455) |
Aug
(267) |
Sep
(280) |
Oct
(253) |
Nov
(232) |
Dec
(304) |
| 2009 |
Jan
(486) |
Feb
(470) |
Mar
(458) |
Apr
(423) |
May
(696) |
Jun
(461) |
Jul
(551) |
Aug
(575) |
Sep
(134) |
Oct
(110) |
Nov
(157) |
Dec
(102) |
| 2010 |
Jan
(226) |
Feb
(86) |
Mar
(147) |
Apr
(117) |
May
(107) |
Jun
(203) |
Jul
(193) |
Aug
(238) |
Sep
(300) |
Oct
(246) |
Nov
(23) |
Dec
(75) |
| 2011 |
Jan
(133) |
Feb
(195) |
Mar
(315) |
Apr
(200) |
May
(267) |
Jun
(293) |
Jul
(353) |
Aug
(237) |
Sep
(278) |
Oct
(611) |
Nov
(274) |
Dec
(260) |
| 2012 |
Jan
(303) |
Feb
(391) |
Mar
(417) |
Apr
(441) |
May
(488) |
Jun
(655) |
Jul
(590) |
Aug
(610) |
Sep
(526) |
Oct
(478) |
Nov
(359) |
Dec
(372) |
| 2013 |
Jan
(467) |
Feb
(226) |
Mar
(391) |
Apr
(281) |
May
(299) |
Jun
(252) |
Jul
(311) |
Aug
(352) |
Sep
(481) |
Oct
(571) |
Nov
(222) |
Dec
(231) |
| 2014 |
Jan
(185) |
Feb
(329) |
Mar
(245) |
Apr
(238) |
May
(281) |
Jun
(399) |
Jul
(382) |
Aug
(500) |
Sep
(579) |
Oct
(435) |
Nov
(487) |
Dec
(256) |
| 2015 |
Jan
(338) |
Feb
(357) |
Mar
(330) |
Apr
(294) |
May
(191) |
Jun
(108) |
Jul
(142) |
Aug
(261) |
Sep
(190) |
Oct
(54) |
Nov
(83) |
Dec
(22) |
| 2016 |
Jan
(49) |
Feb
(89) |
Mar
(33) |
Apr
(50) |
May
(27) |
Jun
(34) |
Jul
(53) |
Aug
(53) |
Sep
(98) |
Oct
(206) |
Nov
(93) |
Dec
(53) |
| 2017 |
Jan
(65) |
Feb
(82) |
Mar
(102) |
Apr
(86) |
May
(187) |
Jun
(67) |
Jul
(23) |
Aug
(93) |
Sep
(65) |
Oct
(45) |
Nov
(35) |
Dec
(17) |
| 2018 |
Jan
(26) |
Feb
(35) |
Mar
(38) |
Apr
(32) |
May
(8) |
Jun
(43) |
Jul
(27) |
Aug
(30) |
Sep
(43) |
Oct
(42) |
Nov
(38) |
Dec
(67) |
| 2019 |
Jan
(32) |
Feb
(37) |
Mar
(53) |
Apr
(64) |
May
(49) |
Jun
(18) |
Jul
(14) |
Aug
(53) |
Sep
(25) |
Oct
(30) |
Nov
(49) |
Dec
(31) |
| 2020 |
Jan
(87) |
Feb
(45) |
Mar
(37) |
Apr
(51) |
May
(99) |
Jun
(36) |
Jul
(11) |
Aug
(14) |
Sep
(20) |
Oct
(24) |
Nov
(40) |
Dec
(23) |
| 2021 |
Jan
(14) |
Feb
(53) |
Mar
(85) |
Apr
(15) |
May
(19) |
Jun
(3) |
Jul
(14) |
Aug
(1) |
Sep
(57) |
Oct
(73) |
Nov
(56) |
Dec
(22) |
| 2022 |
Jan
(3) |
Feb
(22) |
Mar
(6) |
Apr
(55) |
May
(46) |
Jun
(39) |
Jul
(15) |
Aug
(9) |
Sep
(11) |
Oct
(34) |
Nov
(20) |
Dec
(36) |
| 2023 |
Jan
(79) |
Feb
(41) |
Mar
(99) |
Apr
(169) |
May
(48) |
Jun
(16) |
Jul
(16) |
Aug
(57) |
Sep
(19) |
Oct
|
Nov
|
Dec
|
| S | M | T | W | T | F | S |
|---|---|---|---|---|---|---|
|
|
|
|
|
|
|
1
(4) |
|
2
(5) |
3
(3) |
4
(3) |
5
(7) |
6
(7) |
7
(9) |
8
(10) |
|
9
(12) |
10
(26) |
11
(9) |
12
(6) |
13
(7) |
14
(15) |
15
(25) |
|
16
(20) |
17
(32) |
18
(11) |
19
(19) |
20
(22) |
21
(6) |
22
(8) |
|
23
(16) |
24
(25) |
25
(11) |
26
(16) |
27
(12) |
28
(15) |
29
(11) |
|
30
(5) |
31
(8) |
|
|
|
|
|
|
From: Jeremy F. <je...@go...> - 2005-01-23 23:24:45
|
On Sun, 2005-01-23 at 23:34 +1100, Eyal Lebedinsky wrote: > Please do not ignore the original report, the problem is still > there. > > Attached is a program that shows how the backtrace is displayed > when in main but is missing from a thread. Valgrind has to guess where the thread's stack is, because it isn't explicitly told. It assumes that the limits of the stack is between the initial stack pointer and the base of that memory mapping; this may not be a good assumption. In coregrind/x86-linux/syscalls.c:do_clone(), could you set "debug" to True and tell me what the guessed stack range is for the thread which is reporting bad stack backtraces? Also, the contents of /proc/<pid>/maps for that process. J |
|
From: Tom H. <th...@cy...> - 2005-01-23 17:10:05
|
CVS commit by thughes:
Link in libarch.a and use VG_(cpuid) for x86 CPU feature tests rather
than trying to use our own inline version which has a habit of failing
to compile on some versions of gcc due to register starvation.
BUG: 96321
M +2 -1 Makefile.am 1.38
M +9 -8 cputest.c 1.7
--- valgrind/tests/Makefile.am #1.37:1.38
@@ -23,5 +23,6 @@
cputest_SOURCES = cputest.c
cputest_CFLAGS = $(AM_CFLAGS) -D__$(VG_ARCH)__
+cputest_DEPENDENCIES = ../coregrind/${VG_ARCH}/libarch.a
+cputest_LDADD = ../coregrind/${VG_ARCH}/libarch.a
toobig_allocs_SOURCES = toobig-allocs.c
true_SOURCES = true.c
-
--- valgrind/tests/cputest.c #1.6:1.7
@@ -23,13 +23,14 @@ char* all_archs[] = {
#ifdef __x86__
-static __inline__ void cpuid(unsigned int n,
+extern void vgPlain_cpuid(unsigned int n,
+ unsigned int *a, unsigned int *b,
+ unsigned int *c, unsigned int *d);
+
+static inline void cpuid(unsigned int n,
unsigned int *a, unsigned int *b,
unsigned int *c, unsigned int *d)
{
- __asm__ __volatile__ (
- "cpuid"
- : "=a" (*a), "=b" (*b), "=c" (*c), "=d" (*d) /* output */
- : "0" (n) /* input */
- );
+ vgPlain_cpuid(n, a, b, c, d);
+ return;
}
|
|
From: Tom H. <th...@cy...> - 2005-01-23 16:51:13
|
CVS commit by thughes:
Don't die if we find a type of size zero. It isn't clear how to create
such a type but it has apparently been seend to happen.
MERGE TO STABLE
M +1 -1 vg_symtypes.c 1.7.2.1
--- valgrind/coregrind/vg_symtypes.c #1.7:1.7.2.1
@@ -873,5 +873,5 @@ Char *VG_(describe_addr)(ThreadId tid, A
VG_(printf)(" non-followable array (sz=%d): checking addr %p in range %p-%p\n",
sz, addr, var->valuep, (var->valuep + sz));
- if (addr >= var->valuep && addr <= (var->valuep + sz))
+ if (ty->size > 0 && addr >= var->valuep && addr <= (var->valuep + sz))
min = max = (addr - var->valuep) / ty->size;
else
|
|
From: Tom H. <th...@cy...> - 2005-01-23 16:50:20
|
CVS commit by thughes:
Don't die if we find a type of size zero. It isn't clear how to create
such a type but it has apparently been seend to happen.
BUG: 96923
M +1 -1 vg_symtypes.c 1.13
--- valgrind/coregrind/vg_symtypes.c #1.12:1.13
@@ -873,5 +873,5 @@ Char *VG_(describe_addr)(ThreadId tid, A
VG_(printf)(" non-followable array (sz=%d): checking addr %p in range %p-%p\n",
sz, addr, var->valuep, (var->valuep + sz));
- if (addr >= var->valuep && addr <= (var->valuep + sz))
+ if (ty->size > 0 && addr >= var->valuep && addr <= (var->valuep + sz))
min = max = (addr - var->valuep) / ty->size;
else
|
|
From: Eyal L. <ey...@ey...> - 2005-01-23 12:34:30
|
Please do not ignore the original report, the problem is still there. Attached is a program that shows how the backtrace is displayed when in main but is missing from a thread. ==19059== Memcheck, a memory error detector for x86-linux. ==19059== Copyright (C) 2002-2004, and GNU GPL'd, by Julian Seward et al. ==19059== Using valgrind-2.3.0.CVS, a program supervision framework for x86-linux. ==19059== Copyright (C) 2000-2004, and GNU GPL'd, by Julian Seward et al. ==19059== For more details, rerun with: -v ==19059== /home/eyal/zz/zz36.c(75) testing in main ==19059== Conditional jump or move depends on uninitialised value(s) ==19059== at 0x1B905D32: memcmp (mac_replace_strmem.c:325) <<<<< good stack ***** ==19059== by 0x8048636: func (zz36.c:23) ==19059== by 0x8048831: main (zz36.c:77) 0 /home/eyal/zz/zz36.c(80) testing in thread /home/eyal/zz/zz36.c(38) will pthread_attr_init /home/eyal/zz/zz36.c(41) pthread_attr_init=0 ==19059== ==19059== Thread 2: ==19059== Conditional jump or move depends on uninitialised value(s) ==19059== at 0x1B905D32: memcmp (mac_replace_strmem.c:325) <<<<<< missing stack ***** 0 /home/eyal/zz/zz36.c(60) joined /home/eyal/zz/zz36.c(65) pthread_attr_destroy=0 /home/eyal/zz/zz36.c(85) test done ==19059== ==19059== ERROR SUMMARY: 2 errors from 2 contexts (suppressed: 13 from 1) ==19059== malloc/free: in use at exit: 68 bytes in 1 blocks. ==19059== malloc/free: 3 allocs, 2 frees, 70 bytes allocated. ==19059== For counts of detected errors, rerun with: -v ==19059== searching for pointers to 1 not-freed blocks. ==19059== checked 9860212 bytes. ==19059== ==19059== ==19059== 68 bytes in 1 blocks are possibly lost in loss record 1 of 1 ==19059== at 0x1B904FE5: calloc (vg_replace_malloc.c:175) ==19059== by 0x1B8F25A8: (within /lib/ld-2.3.2.so) ==19059== by 0x1B8F287B: _dl_allocate_tls (in /lib/ld-2.3.2.so) ==19059== by 0x1B92424A: allocate_stack (in /lib/tls/libpthread-0.60.so) ==19059== by 0x1B923C54: pthread_create@@GLIBC_2.1 (in /lib/tls/libpthread-0.60.so) ==19059== by 0x80486DF: test (zz36.c:43) ==19059== by 0x8048868: main (zz36.c:82) ==19059== ==19059== LEAK SUMMARY: ==19059== definitely lost: 0 bytes in 0 blocks. ==19059== possibly lost: 68 bytes in 1 blocks. ==19059== still reachable: 0 bytes in 0 blocks. ==19059== suppressed: 0 bytes in 0 blocks. ==19059== Reachable blocks (those to which a pointer was found) are not shown. ==19059== To see them, rerun with: --show-reachable=yes -- Eyal Lebedinsky (ey...@ey...) <http://samba.org/eyal/> attach .zip as .dat |
|
From: Eyal L. <ey...@ey...> - 2005-01-23 06:10:44
|
Jeremy Fitzhardinge wrote: [trimmed] > What does your test suite do? How much can you simplify it and > get the same result? > > J I have tried it before and failed. If you still want me to try (after you finish your investigation) then i will give it another go. -- Eyal Lebedinsky (ey...@ey...) <http://samba.org/eyal/> attach .zip as .dat |
|
From: Eyal L. <ey...@ey...> - 2005-01-23 06:09:02
|
Jeremy Fitzhardinge wrote: > On Sun, 2005-01-23 at 11:53 +1100, Eyal Lebedinsky wrote: > >>Was this reported to linux-kernel? Who is handling it there? I am >>ready to do testing/investigation as I can reproduce it consistently. >> >>I cannot report it myself as I do not know enough about the nature >>of the problem (or what faultstatus does). However, if this test >>program is a simple one that should always work but sometimes does >>not (and can be built stand-alone) then it may be enough for a >>report. > > > Hm, I've worked out what it is, and it probably is a Valgrind bug. > There's a system-wide limit to the number of queued signals; if that > limit gets hit, then signals are delivered without extra info. I can > reproduce it easily if I change faultstatus to send itself a lot of > blocked signals before doing the main part of the test. > > Does your test do a lot of thread exits? Probably. My testsuit is running clients against servers and each client session gets a thread, and a typical test will have no more than 10 threads at a time active on the server. I have seen the failure after 11 tests or it managed up to 25. > J > -- Eyal Lebedinsky (ey...@ey...) <http://samba.org/eyal/> attach .zip as .dat |
|
From: <js...@ac...> - 2005-01-23 03:56:40
|
Nightly build on phoenix ( SuSE 9.1 ) started at 2005-01-23 03:50:00 GMT Checking out source tree ... done Configuring ... done Building ... done Running regression tests ... done Last 20 lines of log.verbose follow -- Finished tests in none/tests ---------------------------------------- == 193 tests, 15 stderr failures, 0 stdout failures ================= corecheck/tests/as_mmap (stderr) corecheck/tests/fdleak_fcntl (stderr) helgrind/tests/allok (stderr) helgrind/tests/deadlock (stderr) helgrind/tests/inherit (stderr) helgrind/tests/race (stderr) helgrind/tests/race2 (stderr) helgrind/tests/readshared (stderr) massif/tests/toobig-allocs (stderr) massif/tests/true_html (stderr) massif/tests/true_text (stderr) memcheck/tests/pth_once (stderr) memcheck/tests/scalar (stderr) memcheck/tests/threadederrno (stderr) memcheck/tests/writev (stderr) make: *** [regtest] Error 1 |
|
From: Tom H. <to...@co...> - 2005-01-23 03:25:26
|
Nightly build on dunsmere ( Fedora Core 3 ) started at 2005-01-23 03:20:04 GMT Checking out source tree ... done Configuring ... done Building ... done Running regression tests ... done Last 20 lines of log.verbose follow seg_override: valgrind --num-callers=4 ./seg_override -- Finished tests in none/tests/x86 ------------------------------------ yield: valgrind --num-callers=4 ./yield -- Finished tests in none/tests ---------------------------------------- == 200 tests, 12 stderr failures, 0 stdout failures ================= helgrind/tests/allok (stderr) helgrind/tests/deadlock (stderr) helgrind/tests/inherit (stderr) helgrind/tests/race (stderr) helgrind/tests/race2 (stderr) helgrind/tests/readshared (stderr) massif/tests/toobig-allocs (stderr) massif/tests/true_html (stderr) massif/tests/true_text (stderr) memcheck/tests/scalar (stderr) memcheck/tests/scalar_supp (stderr) memcheck/tests/vgtest_ume (stderr) make: *** [regtest] Error 1 |
|
From: Tom H. <th...@cy...> - 2005-01-23 03:22:48
|
Nightly build on audi ( Red Hat 9 ) started at 2005-01-23 03:15:13 GMT Checking out source tree ... done Configuring ... done Building ... done Running regression tests ... done Last 20 lines of log.verbose follow helgrind/tests/allok (stderr) helgrind/tests/deadlock (stderr) helgrind/tests/inherit (stderr) helgrind/tests/race (stderr) helgrind/tests/race2 (stderr) helgrind/tests/readshared (stderr) massif/tests/toobig-allocs (stderr) massif/tests/true_html (stderr) massif/tests/true_text (stderr) memcheck/tests/badpoll (stderr) memcheck/tests/buflen_check (stderr) memcheck/tests/execve (stderr) memcheck/tests/execve2 (stderr) memcheck/tests/scalar (stderr) memcheck/tests/scalar_exit_group (stderr) memcheck/tests/scalar_supp (stderr) memcheck/tests/writev (stderr) none/tests/tls (stdout) make: *** [regtest] Error 1 |
|
From: Tom H. <th...@cy...> - 2005-01-23 03:16:27
|
Nightly build on ginetta ( Red Hat 8.0 ) started at 2005-01-23 03:10:17 GMT Checking out source tree ... done Configuring ... done Building ... done Running regression tests ... done Last 20 lines of log.verbose follow seg_override: valgrind --num-callers=4 ./seg_override -- Finished tests in none/tests/x86 ------------------------------------ yield: valgrind --num-callers=4 ./yield -- Finished tests in none/tests ---------------------------------------- == 198 tests, 12 stderr failures, 0 stdout failures ================= helgrind/tests/allok (stderr) helgrind/tests/deadlock (stderr) helgrind/tests/inherit (stderr) helgrind/tests/race (stderr) helgrind/tests/race2 (stderr) helgrind/tests/readshared (stderr) massif/tests/toobig-allocs (stderr) massif/tests/true_html (stderr) massif/tests/true_text (stderr) memcheck/tests/pth_once (stderr) memcheck/tests/scalar (stderr) memcheck/tests/threadederrno (stderr) make: *** [regtest] Error 1 |
|
From: Tom H. <th...@cy...> - 2005-01-23 03:10:47
|
Nightly build on alvis ( Red Hat 7.3 ) started at 2005-01-23 03:05:12 GMT Checking out source tree ... done Configuring ... done Building ... done Running regression tests ... done Last 20 lines of log.verbose follow yield: valgrind --num-callers=4 ./yield -- Finished tests in none/tests ---------------------------------------- == 198 tests, 14 stderr failures, 0 stdout failures ================= helgrind/tests/allok (stderr) helgrind/tests/deadlock (stderr) helgrind/tests/inherit (stderr) helgrind/tests/race (stderr) helgrind/tests/race2 (stderr) helgrind/tests/readshared (stderr) massif/tests/toobig-allocs (stderr) massif/tests/true_html (stderr) massif/tests/true_text (stderr) memcheck/tests/post-syscall (stderr) memcheck/tests/pth_once (stderr) memcheck/tests/scalar (stderr) memcheck/tests/threadederrno (stderr) memcheck/tests/vgtest_ume (stderr) make: *** [regtest] Error 1 |
|
From: Tom H. <th...@cy...> - 2005-01-23 03:06:08
|
Nightly build on standard ( Red Hat 7.2 ) started at 2005-01-23 03:00:14 GMT Checking out source tree ... done Configuring ... done Building ... done Running regression tests ... done Last 20 lines of log.verbose follow -- Finished tests in none/tests/x86 ------------------------------------ yield: valgrind --num-callers=4 ./yield -- Finished tests in none/tests ---------------------------------------- == 198 tests, 13 stderr failures, 0 stdout failures ================= helgrind/tests/allok (stderr) helgrind/tests/deadlock (stderr) helgrind/tests/inherit (stderr) helgrind/tests/race (stderr) helgrind/tests/race2 (stderr) helgrind/tests/readshared (stderr) massif/tests/toobig-allocs (stderr) massif/tests/true_html (stderr) massif/tests/true_text (stderr) memcheck/tests/pth_once (stderr) memcheck/tests/scalar (stderr) memcheck/tests/threadederrno (stderr) memcheck/tests/vgtest_ume (stderr) make: *** [regtest] Error 1 |
|
From: Jeremy F. <je...@go...> - 2005-01-23 02:32:07
|
On Sun, 2005-01-23 at 11:53 +1100, Eyal Lebedinsky wrote: > Was this reported to linux-kernel? Who is handling it there? I am > ready to do testing/investigation as I can reproduce it consistently. > > I cannot report it myself as I do not know enough about the nature > of the problem (or what faultstatus does). However, if this test > program is a simple one that should always work but sometimes does > not (and can be built stand-alone) then it may be enough for a > report. Hm, I've worked out what it is, and it probably is a Valgrind bug. There's a system-wide limit to the number of queued signals; if that limit gets hit, then signals are delivered without extra info. I can reproduce it easily if I change faultstatus to send itself a lot of blocked signals before doing the main part of the test. Does your test do a lot of thread exits? J |
|
From: Jeremy F. <je...@go...> - 2005-01-23 01:54:33
|
On Sun, 2005-01-23 at 11:53 +1100, Eyal Lebedinsky wrote: > However, running as non-root it does fail 'in that state': > > eyal@e7:~$ /data2/valgrind/valgrind/none/tests/faultstatus > Test 0: FAIL: expected si_code==1, not 0 > Test 1: FAIL: expected si_code==2, not 0 > Test 2: FAIL: expected si_code==2, not 0 > Test 3: FAIL: expected si_code==2, not 0 > Test 4: FAIL: expected si_code==1, not 0 > > My application runs non-root. > > 'killall' makes it work instantly. > > This is on vanilla 2.6.11-rc2. OK, definitely a kernel problem. faultstatus shouldn't depend on UID at all. > Was this reported to linux-kernel? Who is handling it there? I am > ready to do testing/investigation as I can reproduce it consistently. I haven't seen it reported against a stock kernel, so I haven't reported it to linux-kernel. > I cannot report it myself as I do not know enough about the nature > of the problem (or what faultstatus does). However, if this test > program is a simple one that should always work but sometimes does > not (and can be built stand-alone) then it may be enough for a > report. Yes. What does your test suite do? How much can you simplify it and get the same result? J |
|
From: Eyal L. <ey...@ey...> - 2005-01-23 00:53:39
|
Jeremy Fitzhardinge wrote: > When it is in this state, before you killall -9 valgrind, please run > none/tests/faultstatus (natively, not under Valgrind). If this fails, > it is definitely a kernel bug. > > J Done this, and faultstatus is not failing 'in that state': root@e7:/data2/valgrind/valgrind/none/tests# ./faultstatus Test 0: PASS 1 Test 1: PASS 2 Test 2: PASS 3 Test 3: PASS 4 Test 4: PASS 5 However, running as non-root it does fail 'in that state': eyal@e7:~$ /data2/valgrind/valgrind/none/tests/faultstatus Test 0: FAIL: expected si_code==1, not 0 Test 1: FAIL: expected si_code==2, not 0 Test 2: FAIL: expected si_code==2, not 0 Test 3: FAIL: expected si_code==2, not 0 Test 4: FAIL: expected si_code==1, not 0 My application runs non-root. 'killall' makes it work instantly. This is on vanilla 2.6.11-rc2. Was this reported to linux-kernel? Who is handling it there? I am ready to do testing/investigation as I can reproduce it consistently. I cannot report it myself as I do not know enough about the nature of the problem (or what faultstatus does). However, if this test program is a simple one that should always work but sometimes does not (and can be built stand-alone) then it may be enough for a report. -- Eyal Lebedinsky (ey...@ey...) <http://samba.org/eyal/> attach .zip as .dat |