* xfs_repair xfsprogs version > 2.8.11 @ 2006-12-24 11:27 Ying-Hung Chen 2006-12-25 9:59 ` Ying-Hung Chen 0 siblings, 1 reply; 4+ messages in thread From: Ying-Hung Chen @ 2006-12-24 11:27 UTC (permalink / raw) To: linux-xfs Hi there, I found that xfs_repair always returns the following message with the xfsprogs version > 2.8.11 [root@yroro i586]# xfs_repair /dev/hdb1 fatal error -- status from pthread_attr_setstacksize: 22 from the ChangeLog, seems like there is some internal changes with threads starting 2.8.11 .. the xfs_repair works for me up to 2.8.11, it fails to work on 2.8.16 and 2.8.18, how do I work around this problem? Thanks, -Ying ^ permalink raw reply [flat|nested] 4+ messages in thread
* Re: xfs_repair xfsprogs version > 2.8.11 2006-12-24 11:27 xfs_repair xfsprogs version > 2.8.11 Ying-Hung Chen @ 2006-12-25 9:59 ` Ying-Hung Chen 2006-12-28 10:21 ` David Chatterton 0 siblings, 1 reply; 4+ messages in thread From: Ying-Hung Chen @ 2006-12-25 9:59 UTC (permalink / raw) To: linux-xfs; +Cc: Ying-Hung Chen Hi there, actually, i have trace the code in to xfs_repair/threads.c (taken from 2.8.18) void thread_init(void) { .... if ((status = pthread_attr_getstacksize(&attr, &stacksize)) != 0) do_error(_("status from pthread_attr_getstacksize: %d"), status); stacksize *= 4; if ((status = pthread_attr_setstacksize(&attr, stacksize)) != 0) do_error(_("status from pthread_attr_setstacksize: %d"), status); .... } the repair program dies in pthread_attr_setstacksize(&attr, stacksize)). is there any reason why the program is trying to set the stacksize into 4 times the current size? just for testing purposes, I remove the stacksize *= 4; the xfs_repair seems to 'work', at least from user's point of view. I have tested with x86 32bits machines with 2.4 and 2.6 kernels, they both yield with the same results, Thanks, -Ying Ying-Hung Chen wrote: > Hi there, > > I found that xfs_repair always returns the following message with the > xfsprogs version > 2.8.11 > > [root@yroro i586]# xfs_repair /dev/hdb1 > > fatal error -- status from pthread_attr_setstacksize: 22 > > from the ChangeLog, seems like there is some internal changes with > threads starting 2.8.11 .. the xfs_repair works for me up to 2.8.11, it > fails to work on 2.8.16 and 2.8.18, > > how do I work around this problem? > > Thanks, > > -Ying > ^ permalink raw reply [flat|nested] 4+ messages in thread
* Re: xfs_repair xfsprogs version > 2.8.11 2006-12-25 9:59 ` Ying-Hung Chen @ 2006-12-28 10:21 ` David Chatterton 2006-12-29 1:51 ` Ying-Hung Chen 0 siblings, 1 reply; 4+ messages in thread From: David Chatterton @ 2006-12-28 10:21 UTC (permalink / raw) To: Ying-Hung Chen; +Cc: linux-xfs Ying-Hung, Can you please provide some info on your configuration? Obviously we are not seeing this problem in our own tests and reproducing this will help to resolve it. Thanks, David Ying-Hung Chen wrote: > Hi there, > > actually, i have trace the code in to xfs_repair/threads.c (taken from > 2.8.18) > > void > thread_init(void) > { > .... > if ((status = pthread_attr_getstacksize(&attr, &stacksize)) != 0) > do_error(_("status from pthread_attr_getstacksize: %d"), > status); > > stacksize *= 4; > > if ((status = pthread_attr_setstacksize(&attr, stacksize)) != 0) > do_error(_("status from pthread_attr_setstacksize: %d"), > status); > .... > } > > the repair program dies in pthread_attr_setstacksize(&attr, stacksize)). > is there any reason why the program is trying to set the stacksize into > 4 times the current size? > > just for testing purposes, I remove the stacksize *= 4; the xfs_repair > seems to 'work', at least from user's point of view. > > I have tested with x86 32bits machines with 2.4 and 2.6 kernels, they > both yield with the same results, > > Thanks, > > -Ying > > Ying-Hung Chen wrote: >> Hi there, >> >> I found that xfs_repair always returns the following message with the >> xfsprogs version > 2.8.11 >> >> [root@yroro i586]# xfs_repair /dev/hdb1 >> >> fatal error -- status from pthread_attr_setstacksize: 22 >> >> from the ChangeLog, seems like there is some internal changes with >> threads starting 2.8.11 .. the xfs_repair works for me up to 2.8.11, it >> fails to work on 2.8.16 and 2.8.18, >> >> how do I work around this problem? >> >> Thanks, >> >> -Ying >> > -- David Chatterton XFS Engineering Manager SGI Australia ^ permalink raw reply [flat|nested] 4+ messages in thread
* Re: xfs_repair xfsprogs version > 2.8.11 2006-12-28 10:21 ` David Chatterton @ 2006-12-29 1:51 ` Ying-Hung Chen 0 siblings, 0 replies; 4+ messages in thread From: Ying-Hung Chen @ 2006-12-29 1:51 UTC (permalink / raw) To: chatz; +Cc: linux-xfs Hi David, on 2.4 side, I am running the kernel based on 2.4.33, using gcc 3.4.4, glibc-2.3.5, ulimit yields core file size (blocks, -c) 0 data seg size (kbytes, -d) 60144 file size (blocks, -f) unlimited max locked memory (kbytes, -l) unlimited max memory size (kbytes, -m) unlimited open files (-n) 256 pipe size (512 bytes, -p) 8 stack size (kbytes, -s) 8192 cpu time (seconds, -t) unlimited max user processes (-u) 100 virtual memory (kbytes, -v) unlimited on 2.6 side, I have kernel based on 2.6.16.32, using gcc 4.1.1 and glibc-2.3.6, ulimit yields core file size (blocks, -c) 0 data seg size (kbytes, -d) 12288 file size (blocks, -f) unlimited pending signals (-i) 1535 max locked memory (kbytes, -l) 32 max memory size (kbytes, -m) unlimited open files (-n) 256 pipe size (512 bytes, -p) 8 POSIX message queues (bytes, -q) 819200 stack size (kbytes, -s) 8192 cpu time (seconds, -t) unlimited max user processes (-u) 100 virtual memory (kbytes, -v) unlimited file locks (-x) unlimited anything that you need for better pin point the problem? also, is the stacksize resizing really necessary as showed in ... stacksize *= 4; ... Thanks -Ying David Chatterton wrote: > Ying-Hung, > > Can you please provide some info on your configuration? Obviously we are > not seeing this problem in our own tests and reproducing this will help > to resolve it. > > Thanks, > > David > > > Ying-Hung Chen wrote: >> Hi there, >> >> actually, i have trace the code in to xfs_repair/threads.c (taken from >> 2.8.18) >> >> void >> thread_init(void) >> { >> .... >> if ((status = pthread_attr_getstacksize(&attr, &stacksize)) != 0) >> do_error(_("status from pthread_attr_getstacksize: %d"), >> status); >> >> stacksize *= 4; >> >> if ((status = pthread_attr_setstacksize(&attr, stacksize)) != 0) >> do_error(_("status from pthread_attr_setstacksize: %d"), >> status); >> .... >> } >> >> the repair program dies in pthread_attr_setstacksize(&attr, stacksize)). >> is there any reason why the program is trying to set the stacksize into >> 4 times the current size? >> >> just for testing purposes, I remove the stacksize *= 4; the xfs_repair >> seems to 'work', at least from user's point of view. >> >> I have tested with x86 32bits machines with 2.4 and 2.6 kernels, they >> both yield with the same results, >> >> Thanks, >> >> -Ying >> >> Ying-Hung Chen wrote: >>> Hi there, >>> >>> I found that xfs_repair always returns the following message with the >>> xfsprogs version > 2.8.11 >>> >>> [root@yroro i586]# xfs_repair /dev/hdb1 >>> >>> fatal error -- status from pthread_attr_setstacksize: 22 >>> >>> from the ChangeLog, seems like there is some internal changes with >>> threads starting 2.8.11 .. the xfs_repair works for me up to 2.8.11, it >>> fails to work on 2.8.16 and 2.8.18, >>> >>> how do I work around this problem? >>> >>> Thanks, >>> >>> -Ying >>> > ^ permalink raw reply [flat|nested] 4+ messages in thread
end of thread, other threads:[~2006-12-29 1:52 UTC | newest] Thread overview: 4+ messages (download: mbox.gz follow: Atom feed -- links below jump to the message on this page -- 2006-12-24 11:27 xfs_repair xfsprogs version > 2.8.11 Ying-Hung Chen 2006-12-25 9:59 ` Ying-Hung Chen 2006-12-28 10:21 ` David Chatterton 2006-12-29 1:51 ` Ying-Hung Chen
This is a public inbox, see mirroring instructions for how to clone and mirror all data and code used for this inbox