**** BEGIN LOGGING AT Wed Jul 02 02:59:56 2008 Jul 02 05:36:47 03bzhou * r8643 10optware/trunk/make/tshark.mk: tshark: 1.0.0 -> 1.0.1 Jul 02 07:21:26 03rwhitby * r1079 10kernel/trunk/scripts/: Removed the empty scripts directory Jul 02 07:29:09 03rwhitby * r1080 10kernel/trunk/README: Updated the stable and development information. Jul 02 09:12:38 I've forgotten my SSL-password for NSLU2, and I cannot access neither web interface or telnet. Is reflash the way to go? I'm using Unslung. Jul 02 09:26:27 <[1]Woppe> I've forgotten my SSL-password for NSLU2, and I cannot access neither web interface or telnet. Is reflash the way to go? I'm using Unslung. Jul 02 11:14:54 Woppe: power down, unplug the disk, power up. You should have the default unslung password. telnet in. attach the disk. edit the password files on the disk (there's a few of them, so look for them all), reboot. Jul 02 11:15:20 Woppe: and if that all works, then write a wiki page for the next person and add it to the FAQ Jul 02 16:17:36 03bzhou * r8644 10optware/trunk/make/mlocate.mk: mlocate: 0.20 -> 0.21 for glibc platforms Jul 02 16:17:56 03bzhou * r8645 10optware/trunk/make/finch.mk: finch: 2.4.2 -> 2.4.3 Jul 02 16:37:56 03bzhou * r8646 10optware/trunk/make/luarocks.mk: luarocks: 0.5.2 -> 0.6.0.2 Jul 02 17:25:17 03bzhou * r8647 10optware/trunk/platforms/toolchain-openwrt-ixp4xx.mk: toolchain-openwrt-ixp4xx: native build should have GNU_HOST_NAME matching GNU_TARGET_NAME Jul 02 17:28:29 03bzhou * r8648 10optware/trunk/make/rsync.mk: rsync: 3.0.2 -> 3.0.3 Jul 02 18:46:07 hopsnbarley? Jul 02 21:01:17 03bzhou * r8649 10optware/trunk/make/patchutils.mk: patchutils: 0.2.31 -> 0.3.0 Jul 02 21:13:11 03bzhou * r8650 10optware/trunk/make/msort.mk: msort: 8.46 -> 8.47 Jul 02 23:21:23 03bzhou * r8651 10optware/trunk/ (3 files in 2 dirs): cs05q3armel: added native toolchain to cs05q3armel feed Jul 03 00:35:56 rwhitby: Hi. With CONFIG_DMABOUNCE_DEBUG enabled, messages are printed whenever the driveis accessed. The requested buffer size varies between 2000h and 10000h but the offered buffer sizes are always small=800h and large=1000h. does this make sense? Jul 03 00:37:42 yes, that's the root of the problem. Jul 03 00:38:15 the usb storage driver requests buffers that are too large for what dmabounce normally gives Jul 03 00:41:14 OK. It must be making different requests until it succeeds because the system does work. I wonder what the algorithm is.. Jul 03 00:47:11 Also, the 4.10-alpha build automounts ext3 partitions with sync. If I understand correctly, this is not particularily fast or helpful. When I have been testing, I have been remounting without sync and this may be causing the difference in the errors Jul 03 00:47:20 sdm485: hi, were you able to reproduce problem with EXT2? Jul 03 00:49:24 RobNC: Hi: No and (yes). Between the thunderstorms and trashed filesystems, things have become a bit confused. But it just completed 14GB transfer again when mounted ext2. It failed ext3 with and without sync Jul 03 00:50:03 Ok, that makes sense, I noticed OOM condition almost always when trying to rsync ~200GB of data. Jul 03 00:51:11 so I presume that at some point there's more data to sync than can be processed. Someone pointed to swap=on or swap=off but I was able to reproduce it with no swap. Jul 03 00:51:20 That is a lot of data... Jul 03 00:51:38 I don't think swap has anything directly to do with it. Jul 03 00:51:38 backups are a good thing :-) Jul 03 00:51:58 I agree, swap might induce the problem but it's not related to swap IMHO Jul 03 00:53:21 Should I try 4.10-alpha with ext2? Jul 03 00:54:50 That is what I am testing with and I have no idea of the state of changes. It would help if we worked with similar rigs. Jul 03 00:55:31 ok, mine has 256MB. Did you add the suggestion for common-pci.c workaround in the bug post 7760? Jul 03 00:56:32 I am testing 256M as well but did not do that suggestion. I will look into it. So how long does it take to initially rsync 200G? Jul 03 00:57:32 hmm, actually about 24 hrs if I recall correctly. Usually I rsync it via USB 2.0 to dedicated linux server then do incremental rsyncs with NSLU2 Jul 03 00:58:23 That is surely a thorough test! :) Jul 03 00:58:36 heh indeed... stability is quite important with servers :-) Jul 03 01:00:20 It would be nice to change the dma bounce pool to provide 64k buffers to see what that does. Have to figure that out. Jul 03 01:01:03 It would also make the best use of scatter/gather if I understand the process (probably don't) Jul 03 01:01:10 I was wondering also if this only happens under root, perhaps mortal users can't access so much memory? Jul 03 01:05:21 That is a good point. I often have three ssh terminals to the slug at the same time and when running as root, memtester 243M will kill one of the other windows. How is that possible? Jul 03 01:06:29 yes I saw something similar... interesting thing is that when the slug hangs, the other subsystems are fine that have already been started (i.e., pinging NSLU2) but you can't login due to needing memory for shell, etc. Jul 03 01:07:48 Yes, rwhitby explained that the usb subsystem is dead bit the kernel is actually still alive. One test to do it to put rsync in internal flash and see if there is enough sanity when it dies to diagnose the problems Jul 03 01:08:01 In the final test I did, memtester worked, but then I got it to crash by trying to access the man page. So perhaps the memory manager is not aggressive enough in flushing the unused memory for other programs Jul 03 01:08:45 yeah, I suspect everything needed to debug should be in flash as well (i.e., "less", "sh", etc.) Jul 03 01:09:11 It seems to me that something is very wrong when one user process can make another fail. Jul 03 01:09:34 I have an obeseslug so shouldn't be a problem - only issue would be in trying to work around the scripts put in by turnup. Jul 03 01:11:15 Indeed I agree regarding one process killing another. That's a fundamental problem it seems. Unfortunately, the arm kernel folks have seemingly given up on that aspect, and even RMK has said that the memory manager folks should look into it. Jul 03 01:11:50 I think I will do that test setup next. There is also a lot of debug code in dmabounce.c that can be activated with the DEBUG flag (maybe too much) Jul 03 01:12:15 But finding one of those MM folks is difficult. Jul 03 01:12:35 Yes... Jul 03 01:12:44 ok, thanks for helping. There are probably 20 people with FatSlugs but we could all benefit I suspect. Jul 03 01:13:53 Thanks for the feedback and conversation. Jul 03 01:14:37 no problem, any questions or suggestions feel free to email me - my email is in the bugzilla mentioned in 7760 Jul 03 01:14:47 OK Jul 03 01:15:26 * RobNC waves - other duties are calling me... Jul 03 01:16:29 sdm485: I'll try ext2 after I re-build slugosbe-4.10 (with new apex) Jul 03 01:17:43 OK, I will check that suggestion about common.pci.c. Jul 03 01:18:43 thanks, let us know. It seemed to make it more stable but I could still get it to crash. Jul 03 01:19:45 ok, take care and thanks again for your help sdm485 Jul 03 01:19:55 OK, bye **** ENDING LOGGING AT Thu Jul 03 02:59:57 2008