**** BEGIN LOGGING AT Fri May 12 09:59:56 2006 May 12 14:39:30 03bzhou * 10unslung/make/py-mercurial.mk: mercurial: upstream upgrade to 0.9 May 12 14:40:18 03bzhou * 10unslung/make/py-lxml.mk: py-lxml: upstream upgrade to 0.9.2 May 12 14:41:56 03bzhou * 10unslung/make/eaccelerator.mk: eaccelerator: upgrade to 0.9.5-beta2 to match PHP 5.1 May 12 14:43:00 03bzhou * 10unslung/ (make/py-htconsole.mk Makefile): added py-htconsole May 12 14:51:18 03bzhou * 10unslung/ (make/nvi.mk Makefile): added nvi, the original berkerly vi May 12 19:03:35 03bzhou * 10unslung/ (10 files in 2 dirs): added python2.5 (beta), need to figure out a transition plan May 12 20:26:00 mwester? May 12 20:43:30 Good morning marceln! May 12 20:43:47 Hi. May 12 20:43:54 I just had a hang on ntfs May 12 20:44:12 I thought you would be interrested to know May 12 20:44:28 yes I am! May 12 20:45:09 At first i noticed that all the io to the filesystem hung May 12 20:45:24 After some time i couldn't do anything May 12 20:45:39 I have just reflashed my development slug, and I'll be attaching a small NTFS disk (if it works, I fished it out of my junk box this morning)... so any steps to reproduce or anything you've observed would be helpful. May 12 20:46:09 I have reboted the system and doing some new test to see if i can reproduce it. May 12 20:46:23 But i guess there are some memory leaks May 12 20:46:24 How long from the I/O stop to the full hang? Long enough for a "ps" command or some other debugging commands? May 12 20:46:36 Yeah, memory leaks was what I was thinking as well! May 12 20:47:03 I could log in to the system for a half hour after the disk hang. May 12 20:47:24 If I got a reproducable event, I was going to reflash the R63, and check there. Then mess with the mount options to see if those features might trigger it... May 12 20:48:00 half hour? Wow. That's a fair amount of time, so it was pretty limited in terms of what locked up... May 12 20:48:22 It was only the small ntfs filesystem which was locked. May 12 20:48:35 I used an other disk as unslung root with swap. May 12 20:48:40 * mwester wonders if a umount and an rmmod command might be possible if it locks up... May 12 20:49:59 Well "df" locked so probably any command that uses sync will lock. May 12 20:50:19 Ah. Ok. May 12 20:50:33 That doesn't leave too much. May 12 20:51:01 What would habben if you run without swap? May 12 20:51:15 Probably that would have serve impact as well. May 12 20:51:51 worth a try, though. Might have to kill off the GUI httpd and some other stuff. May 12 20:52:31 So people with flash disks without swap and a ntfs disk could see the problems a lot earlier. May 12 20:53:50 Yep. Another thing to try would be to see if it can be reproduced by "dd"ing sufficient blocks of nothing -- i.e. only using the disk, not the network or other drive. May 12 20:53:57 running from flash, I mean. May 12 20:54:26 The first try was through smbfs. May 12 20:54:42 Now i am running local scripts and see the same problems May 12 20:54:47 BTW, this is via a "write" operation, not a "read" operation? May 12 20:54:48 The memory stats: May 12 20:55:42 Mem: 30524k total, 29752k used, 772k free, 2464k buffers May 12 20:55:42 Swap: 63484k total, 9752k used, 53732k free, 1556k cached May 12 20:56:23 buffers went very fast down from 16 m to 2.5m May 12 21:10:18 It's dead again. May 12 21:10:29 This time on local operations only!! May 12 21:10:50 The last top: May 12 21:11:02 top - 22:08:41 up 35 min, 3 users, load average: 5.45, 5.31, 4.03 May 12 21:11:02 Tasks: 66 total, 8 running, 58 sleeping, 0 stopped, 0 zombie May 12 21:11:02 Cpu(s): 24.2% user, 75.8% system, 0.0% nice, 0.0% idle May 12 21:11:02 Mem: 30524k total, 29904k used, 620k free, 17624k buffers May 12 21:11:03 Swap: 63484k total, 10020k used, 53464k free, 1456k cached May 12 21:11:05 PID USER PR NI VIRT RES SHR S %CPU %MEM TIME+ COMMAND May 12 21:11:07 18737 marceln 20 0 428 312 304 R 30.8 1.0 2:29.21 dd May 12 21:11:09 643 root 19 0 440 400 392 S 9.6 1.3 2:29.80 sh May 12 21:11:11 590 marceln 17 0 796 744 724 R 3.7 2.4 1:16.16 top May 12 21:11:13 6 root 9 0 0 0 0 S 0.8 0.0 0:09.94 kupdated May 12 21:11:15 24846 root 20 0 376 376 316 R 0.6 1.2 0:00.02 mkdir May 12 21:11:17 603 root 9 0 0 0 0 S 0.3 0.0 0:32.99 usb-storage-1 May 12 21:11:19 1 root 8 0 376 312 312 S 0.0 1.0 0:09.52 init May 12 21:11:21 2 root 9 0 0 0 0 S 0.0 0.0 0:00.04 keventd May 12 21:11:23 3 root 19 19 0 0 0 R 0.0 0.0 0:09.83 ksoftirqd_CPU0 May 12 21:16:36 I'm wondering abou that "mkdir May 12 21:16:48 s/abou/about May 12 21:18:36 I had two scripts running. May 12 21:19:10 One: dd if=/dev/zero of=test bs=64k count=16000 May 12 21:21:17 Two: for i in ....;do for j in ...;do mkdir -p $i/$j/$k/$l/$m;for x in ...;for y in ...;date > $i/$j/$k/$l/$m/$x$y;done;done;... May 12 21:22:04 A combination of large io and deep directory and file creation operations. May 12 21:23:12 Ok. So it might be related to contention or locking as well... May 13 05:16:20 03bzhou * 10unslung/make/py-setuptools.mk: py-setuptools: upstream upgrade to 0.6b1 **** ENDING LOGGING AT Sat May 13 09:59:56 2006