irclog2html for uclibc on 2002.09.03

04:52:48andersee was last seen on #tuxscreen 7 hours, 4 minutes and 7 seconds ago, saying: ibot: BZFlag? [Mon Sep  2 22:48:41 2002]
04:52:48fontenotibot: seen andersee
04:54:11fontenotwow, that card sounds cool
04:55:19fontenottho it's probably not *that* configurable - usually a radio device is optimized for a small frequency range for cost/size/efficiency reasons
04:55:51fontenotbut maybe those of us with amatuer radio licenses could have some legal fun with it :-D
05:10:40anderseefontenot: hey
05:10:48anderseefontenot: You looking for me?
05:17:56fontenotandersee: yeah - I saw a post of yours somewhere about the VIA C3 proc and I was wondering if you ever found out more about optimized gcc options for it
05:23:06anderseefontenot: Hmm
05:23:30anderseefontenot: I've never actually owned one of those I'm sorry to say
05:24:03anderseefontenot: But it should be essentially equal to an Intel Pentium
05:28:09andersee was last seen on #uclibc 4 minutes and 6 seconds ago, saying: fontenot: But it should be essentially equal to an Intel Pentium [Tue Sep  3 06:24:03 2002]
05:28:09fontenot_ibot: seen andersee
05:28:30fontenot_andersee: whatever you said to me I missed - my stupid dsl went down again
05:29:22anderseeI just said the VIA C3 should be essentially the same as an Intel Pentium
05:29:43anderseenever owned one myself though
05:32:37fontenot_andersee: hmm in your post you said it was like an i686 with just the CMOV instruction missing
05:33:04fontenot_well I have been building gentoo with -i586 -m3dnow
05:33:12fontenot_i guess that's as good as I can get :-\
05:34:26fontenot_heh but I guess this post was in february ?  long time since then
05:38:00anderseeevening BZFlag
05:38:19anderseeBZFlag: evening All sold out of tuxscreens I see...
05:38:28anderseefontenot_: Hmm.  I don
05:38:36anderseefontenot_: Hmm.  I dont recall such a post...
05:38:47anderseefontenot_: But then, I write a lot of email
05:38:52fontenot_andersee: checking...
05:43:40fontenot_andersee: I cant find it now  :-\
05:43:49fontenot_google found it before but now it's not
05:44:06anderseeAhh well
05:51:34BZFlagandersee: yepper. all gone. well, ok one order is pending payment, but all the rest are gone. You would think I'd have a lot of free time now huh? but no. ;-)
05:52:50fontenothi BZFlag :-)
06:03:12BZFlaghey, checking email after being gone for the weekend.
06:16:49anderseeheh
06:17:30anderseeBZFlag: Manuel recently got a Zaurus -- was asking about Pierre...
06:17:56anderseeBZFlag: I guess the Zaurus Xserver is a Pierre special?
06:18:10anderseeBZFlag: Is he back in France now?
06:18:49BZFlagandersee: have not heard from ppc.
06:19:44BZFlaghe did the initial X server for the Z yeah. He posted source someplace. I have not tried to reproduce it. I think that OpenZaurus either has it working or is close. They build from source.
06:21:11anderseeHmm.  Manuel was looking for the source -- couldn't find it.
06:21:39anderseeHe assumed it was closed source...
06:24:47BZFlagsource should be around someplace. have hime talk to kergoth on here to see if OZ has it working yet.
06:25:24anderseeBZFlag: ok, will do.
07:41:19aaronlandersee: hmmm
07:41:22aaronlLinux vitelus.com 2.4.20-pre5 #1 Mon Sep 2 14:41:17 PDT 2002 i686 unknown unknown GNU/Linux
07:41:37aaronlthis seems SO much faster than 2.4.19-pre5-ac3
07:41:39aaronlmaybe i'm wrong
07:41:56aaronlbut it feels like reading of cached files is extremely fast
07:44:10fontenotthe result of the IDE changes ?
07:44:34aaronlpossibly
07:44:35fontenoti know my 2.4.19-rc3 gets extremely unresponsive with heavy IDE activity
07:45:08aaronlsetting unmaskirq with hdparm might help
07:45:38fontenothow does emerge decide which packages to build with -j2 ?
07:45:54fontenotoops wrong channel
07:46:37aaronli'm having some problems with ext3 though
07:46:43aaronli think they're related to fragmentation
07:46:44aaronl[aaronl@vitelus:~]$ time cat mail/debian-legal > /dev/null
07:46:44aaronlcat mail/debian-legal > /dev/null  0.00s user 0.02s system 0% cpu 5.565 total
07:46:44aaronl[aaronl@vitelus:~]$ ls -l mail/debian-legal
07:46:44aaronl-rw-------    1 aaronl   mail      7893525 Sep  3 00:42 mail/debian-legal
07:46:44aaronl[aaronl@vitelus:~]$ time cat /usr/src/linux-2.4.18.tar.bz2 > /dev/null
07:46:45aaronlcat /usr/src/linux-2.4.18.tar.bz2 > /dev/null  0.00s user 0.10s system 16% cpu 0.616 total
07:46:47aaronl[aaronl@vitelus:~]$ ls -l /usr/src/linux-2.4.18.tar.bz2
07:46:49aaronl-rw-r--r--    1 aaronl   aaronl   24161675 Apr 14 11:53 /usr/src/linux-2.4.18.tar.bz2
07:47:05aaronl(both files were AFAIK not in cache)
07:48:21anderseeaaronl: Thats my experience as well -- some vm tweek or other.  Feels nice.
07:48:52aaronllook at what i just flooded - isn't that whacky?
07:49:25aaronlboth files are on the same partition...
07:49:27anderseeHmm
07:49:56anderseeCould be one was already cached...
07:50:02aaronli doubt it
07:50:08anderseeTry first running blockdev --flushbufs
07:50:23aaronllast time i touched the linux tarball when when i compiled the kernel
07:50:25anderseei.e. between each run
07:50:29aaronland that was several reboots ago
07:50:45aaronldebian-legal could be cached, but the timings sure make it seem like it isnt ;)
07:51:00anderseesparse files?
07:52:03anderseeLots and lots of files in your mail dir?
07:52:03aaronlexplain? ;)
07:52:17aaronl /exec -o ls mail | wc -l
07:52:19aaronl     37
07:54:30aaronlmbox does 11mb in .8 secs, which isnt nearly as bad, but still not as good a rate as the linux tarball by far. this fits perfectly with my fragmentation theory - i copied my mbox from another drive a few months ago, so most of it is unfragmented
07:56:06aaronlis there a way i can see how fragmented a particular inode is?
07:56:18aaronli suspect that mail/debian-legal is extremely fragmented
07:58:27aaronlandersee: do you think i should send my data to lkml? or am i being stupid?...
07:59:46aaronlandrew morton would probably help me out
07:59:52anderseeIt actually sounds like a very interesting thing to post.
08:00:38anderseeTry for fun doing a 'cp -a' on the dir and then testing the file in the newly created dir.
08:01:44aaronli would do that, but i'm afraid that cache would interfere with the results
08:02:34anderseeblockdev --flushbufs /dev/<where the filesystem is>
08:04:55aaronldebian-legal takes approximately 1 second to cat from the new dir
08:07:09anderseesounds like a strong indication for fragmentation...
08:10:47aaronlthat blockdev --flushbufs command doesn't seem to do anything here btw
08:13:13anderseeHmm.  I suppose it may not when the fs is mounted.
14:37:13sjhillmjn3: around?
14:46:04mjn3sjhill: hey
14:49:02sjhilli think i found it, never mind :)
14:49:28mjn3ah.. ok.
18:46:46BZFlaglocale support does not include iconv stuff right?
19:31:47sjhillandersee: howdy
19:42:31anderseesjhill: morning
19:42:37anderseesjhill: or something
19:42:38andersee:)
19:43:33sjhillhehe
19:43:51sjhillis making lots of progress on LTP/uClibc
19:45:04anderseeIs it proving to be a useful test?
19:45:19sjhillandersee: dunno', i haven't got the whole suite to compile yet :)
19:45:38sjhillalthough from looking at the tests, yes, it tests a lot of stuff
20:05:13sjhillandersee: got a minute?
20:06:07anderseesjhill: sure
20:07:23sjhillandersee: 'include/sys/statvfs.h'
20:07:50anderseesjhill: yup.  I'm familiar with that one
20:08:16sjhillwhen LFS is turned on, 'fstatvfs' doesn't exist, only 'fstatvfs64' does
20:09:07anderseeThat should only happen with you have defined _FILE_OFFSET_BITS=64
20:09:55sjhilli didn't define it on purpose :)
20:11:14anderseeIf you want large file support, just define _LARGEFILE_SOURCE or _LARGEFILE64_SOURCE
20:11:43sjhillwhich is activated by 'DOLFS'
20:11:44anderseeIf you want things transparently remapped from non-64 bit to 64 bit, then use _FILE_OFFSET_BITS=64
20:12:07anderseeThat one is indended to be sneaky...
20:12:17sjhillhmm
20:12:25anderseeIt tried to change existing apps to be 64bit, w/o their noticing
20:12:41andersees/tries to/changes/
20:12:49sjhill#define _LARGEFILE_SOURCE       1
20:12:49sjhill#define _LARGEFILE64_SOURCE     1
20:12:49sjhill#define __USE_LARGEFILE         1
20:12:49sjhill#define __USE_LARGEFILE64       1
20:12:56sjhillhappen when 'DOLFS' is enabled
20:13:23sjhillit looks like __REDIRECT isn't working
20:13:43sjhillor '#  define statvfs statvfs64' doesn't work right
20:14:19sjhillso how can i get 'DOLFS' to also give me 'fstatvfs'?
20:16:46anderseeCan you show me a sample of what is going wrong?
20:17:17anderseestruct statfs s; if (statfs(MOUNT_POINT_DST "/", &s) != 0) {
20:17:30anderseeThat type of thing?
20:17:32sjhillsure...
20:17:33sjhill/tmp/ccHn7gy1.o: In function `setup':
20:17:33sjhill/tmp/ccHn7gy1.o(.text+0x42f): undefined reference to `fstatvfs'
20:17:35sjhill:)
20:18:21anderseeUmm.  thanks...
20:18:36anderseeAnd the code in 'setup'?
20:18:45sjhillseriously, i did a 'nm' on the libraries and 'fstatvfs' is not in there anywhere
20:20:13sjhill        if (fstatvfs(fd, &stat_buf) != 0) {
20:20:14sjhill                tst_brkm(TBROK, cleanup, "Can't get the information about the "
20:20:14sjhill                         "file system");
20:20:14sjhill        }
20:20:26sjhillit's including the header also
20:21:11sjhillnm ./libc/misc/statfs/fstatvfs.o
20:21:14anderseeHmm.  As I think about it, I've not been using statvfs() at all -- I use statfs()...
20:21:21sjhill00000000 r .LC0
20:21:21sjhill00000002 r .LC1
20:21:21sjhill0000003c r .LC10
20:21:21sjhill00000044 r .LC11
20:21:21sjhill0000000f r .LC2
20:21:22sjhill00000019 r .LC3
20:21:24sjhill0000001b r .LC4
20:21:26sjhill0000001e r .LC5
20:21:28sjhill00000025 r .LC6
20:21:30sjhill0000002c r .LC7
20:21:32sjhill00000032 r .LC8
20:21:34sjhill00000037 r .LC9
20:21:36sjhill         U _GLOBAL_OFFSET_TABLE_
20:21:38sjhill         U __errno_location
20:21:40sjhill         U endmntent
20:21:42sjhill         U fstat64
20:21:44sjhill         U fstatfs64
20:21:46sjhill00000000 T fstatvfs64
20:21:50sjhill         U getmntent_r
20:21:52sjhill         U memset
20:21:54sjhill         U setmntent
20:21:56sjhill         U stat64
20:21:58sjhill         U strcmp
20:22:00sjhill         U strsep
20:22:59anderseeBut statvfs() is in SuSv3, so I guess I'd better make it work
20:49:46anderseesjhill: ok, found it.
20:50:07anderseesjhill: I broke statvfs and statfs back in February
20:58:00anderseesjhill: care to do a 'cvs up' and try again?

Generated by irclog2html.pl by Jeff Waugh - find it at freshmeat.net! Modified by Tim Riker to work with infobot logs, split per channel and by date, etc.