**** BEGIN LOGGING AT Thu Jun 26 02:59:57 2008 Jun 26 04:36:01 03bzhou * r8603 10optware/trunk/make/py-docutils.mk: py-docutils: 0.4 -> 0.5 Jun 26 13:32:45 RobNC: Hi. Are you working with 256M fatslugs? Jun 26 13:33:51 sdm485: he made one for me a while back Jun 26 13:34:55 rwhitby: OK. Just wasn't sure if he was the person looking into the memory problems on >64M units Jun 26 13:35:16 he is Jun 26 13:39:03 I have been looking into this again and find that 4.10-alpha is handling memtester without hanging. some of his posts mention memtester hanging the system if you ask for too much. Not sure if it is a fix to mlock or memtester Jun 26 13:40:05 interesting Jun 26 13:46:12 Also, I built a version with dmabounce disabled and it works fine until you request an unreasonable amount of memory and then it hangs. So it suggests that dmabounce is required and that it helps the system gracefully handle mlock requests that are not possible. The point of this ramble is that I am still surprised that the system can hang when an mlock request is too large when running as root. Jun 26 13:47:11 My questions about the need for dmabounce at all is that my reading of the ixp4xx manual says that the DMA controllers can address all available memory. I must be mistaken though Jun 26 13:58:26 ixp4xx can only access 64MB DMA Jun 26 13:58:53 dmabounce is required, for example, for the usb-storage driver stack which requests large blocks Jun 26 14:01:19 OK, Thanks. I will thrash this around a bit and see if I find anything useful. Jun 26 14:08:22 rwhitby: Is it possible that the system fails because it is making a a buffer allocation request to a subsystem that has to be satisfied. How does a system that has a rootfs on PATA deal with lack of buffer space? Does it block? It seems to me that the usb subsystem must block to make sure that the request is handled or it must never be allowed to get into a situation where the request could fail. If this last bit is true then the Jun 26 14:08:22 problem could be that the usb subsystem cannot flush buffers to disk fast enough to keep from eventually running out of buffers. Jun 26 14:10:55 I think I mean that the problem is that the swap is on the usb subsystem. Jun 26 14:11:24 yeah, that's likely part of the cause Jun 26 14:15:40 That is a problem... Is it possible to put swap on a network drive? It could help test the theory. Jun 26 14:17:37 oops, I found it myself. I will test it out. Bye Jun 26 14:17:37 sure, you should be able to swap over nfs Jun 26 14:17:45 or AoE Jun 26 14:18:13 eventually swap over nfs seems to jam up if you use it real hard. Jun 26 14:18:43 Thanks. Better run (and this will keep me busy) Jun 26 18:16:18 hi, i have some questions about fatslugs and slugosbe... after my slug is made fat, do I need a new redboot or apex loader if using slugos 4.8? 4.9? i think a wikipage says slugos 4.9 works with fatslugs as is Jun 26 18:22:19 scant: 4.9 and 4.10 both automatically determine the memory size and use it. You just put the slug into upgrade mode and uses upslug2 to flash the image. Jun 26 18:25:32 rwhitby: I setup a usb1.1 memory device as swap and opened up three ssh terminals to the fatslug. I launched 'memtester 230M' in terminal 1. I then launched 'memtester 40M' in terminal 2. It killed terminal 1 which seems odd. mlock again IMHO Jun 26 18:26:53 sdm485: SlugOS/BE v4.10? There's a v4.10 when v4.9 is still in beta? Jun 26 18:28:02 scant: I know; it is a bit strange. If you build the latest using the Makefile, it reports as 4.10-alpha. Jun 26 18:29:18 oh, ok, it's alpha Jun 26 18:29:31 I hope 4.9 becomes stable soon then Jun 26 18:29:39 I don't want to have to compile it Jun 26 18:36:52 It may not. It is pretty amazing to watch the build system work and quite simple to get up and running. Jun 26 18:39:58 scant, you see the reported problems with more than 64MB? Jun 26 18:45:05 rwhitby: When running as root, mlock seems to ignore memory already allocated and will cause other running processes to fail. The thing I don't get is it does not refuse to lock memory when running as root. Jun 26 18:53:33 Sinclair73de: there are problems running more than 64MB RAM with stock amount of FlashROM with SlugOS v4.9 beta? Jun 26 18:55:33 scant, all versions i have tested have this problems Jun 26 18:56:22 my last image is build from mastermake last month Jun 26 18:56:54 i have 128MB (2 Chips) Jun 26 19:04:36 Sinclair73de: I am troubleshooting that problem a bit. Can you tell me the problems you have had? Jun 26 19:05:30 Sinclair73de: where can I find out more about the reported issues with >64MB Jun 26 19:05:42 one moment... Jun 26 19:06:57 http://bugzilla.kernel.org/show_bug.cgi?id=7760 Jun 26 19:07:49 there's a few ideas to solve the problem at the end of the bug report. You can try this... Jun 26 19:12:22 I am aware of those but they are all work arounds IMO as they attempt to make sure that there are always free buffers for usb Jun 26 19:12:59 I have never heard of any problem related to the amount of FlashROM however. Jun 26 19:16:50 Most of those memtester invoking oom-killer problems are related to asking memtester to something that cannot be done. You cannot swap the kernel to disk, you cannot swap the device drivers to disk and you surely cannot swap the buffers to do swapping with to disk. It must fail under these conditions. Jun 26 19:18:05 i have not done big memtester checks... only transfered big data from disc to disc or lan to disc Jun 26 19:19:05 Ahh. That is something I need to do then. Thanks Jun 26 19:39:10 I don't understand, haven't fatslugs been around for a long long time Jun 26 19:39:16 how come this is only coming up now? Jun 26 19:41:14 Yes, they have and I have been using them for quite a while. I have one running 24/7 as a utility server. But it appears I don;t ask it to do things that cause problems. So I am trying to figure out the problem. Jun 26 19:43:08 sdm485: yeah, but I guess what I'm wondering is why all the others who've had their fatslugs for all thistime also haven't found this bug Jun 26 19:43:16 not anyone in specific Jun 26 19:43:27 is this bug not present in earlier versions of SlugOS? Jun 26 19:43:54 IMO it is coming up now because the NSLU2 is the only device I know that uses a usb drive as both its' rootfs and swap. That coupled with the extra memory can create the situation. Jun 26 19:44:27 i still don't understand, but i'll drop it Jun 26 19:45:08 i think the problem is comming from the arm-cpu that cannot do dma to memory addresses > 64MB Jun 26 19:46:38 a memtest is all that is needed to produce this bug? Jun 26 19:46:46 so it starts copy blocks between lower 64MB and upper. This happens very often with usb-storage (swap, hdd, stick) Jun 26 19:47:30 The kernel contains the code dmabounce for just these situations. This is not the only processor with limited DMA Jun 26 19:47:49 yes, but that seems not very stable Jun 26 19:48:52 Sinclair73de: was that yes directed to me or sdm485? Jun 26 19:50:31 in the first version on my fatslug i have many debug-messages on serial console, to see the problem comes from dmabounce Jun 26 19:50:41 yes -> sdm485 Jun 26 19:52:37 Yes, I remember those. Jun 26 22:15:45 scant, see my pn? Jun 26 22:29:50 I don't understand, could someone explain, i'm sorry i keep on asking, but if people want a fatslug, it's to use more physical RAM, but using that RAM makes slugs unreliable, so what's the point? Jun 26 22:31:54 scant: The extra RAM makes it swap to disk less when it is doing a lot of things at once. However, normally it doesn't do a lot anyway so I agree, what is the point. Jun 26 22:32:23 Usually, "because i can" Jun 26 22:32:43 I made my first one to see if I could and it has worked fine. I made the second on just to have the extra memory. Jun 26 22:33:55 I agree with Reedy; it is mostly that. My main unit has 32M and runs vsftpd,apache and oww with lots left over for compiling things now and then. It runs just fine. Jun 26 22:34:14 I still don't get it, swapping causes the bug, so if you install more ram to swap less, you're using up more ram, which causes the bug Jun 26 22:34:38 Its only over a certain amount of ram usage isnt it? Jun 26 22:34:47 ie theres a max amount of ram that works fine Jun 26 22:35:10 so, the extra 32MB of RAM is really worth it? Jun 26 22:35:18 its PoV Jun 26 22:35:22 PoV? Jun 26 22:35:26 point of view Jun 26 22:35:38 perhaps, but I still don't get it =( Jun 26 22:35:39 in my case, my slug suffices as stock (ok, its de-underclocked) Jun 26 22:35:47 scant, why did they go to the moon? Jun 26 22:35:48 i mean I understand the neato factor and the i can do it factor Jun 26 22:35:52 because they can Jun 26 22:35:55 sigh Jun 26 22:36:10 lol Jun 26 22:36:10 cmon, I'm not trying to have an extensive debate and more ram and moon are totally different domains Jun 26 22:36:11 cmon Jun 26 22:36:21 sheesh Jun 26 22:36:23 but is the same principle in general Jun 26 22:36:31 no, not really Jun 26 22:37:04 I'm trying to find out, what are the advantages adding 32MB of RAM, the reason I say 32MB, is because >64MB causes the crash, right? Jun 26 22:37:29 i think, but dont quote me on it Jun 26 22:38:13 I am not even convinced there is a problem. As we speak, my 256M unit is rsyncing my home directory while compiling monotone and it just works Jun 26 22:38:27 * Reedy shrugs Jun 26 22:39:06 sigh, I thought it was established that over 64MB causes the crash when using almost all the ram and accessing a USB hd Jun 26 22:39:26 whats the wiki say? Jun 26 22:39:40 I have seen all that too but I can't duplicate it. Jun 26 22:40:13 sdm485: have you ever duplicated the bug? Jun 26 22:40:32 "slugos-beta-4.9 Jun 26 22:40:33 This version uses the 2.6.23.14 kernel. At the moment, there is a problem with ARM kernels and more than 64M of RAM. You might want to configure for 64M until it is fixed. Maybe 'memscan -u 0x0+64M' but I haven't tried Jun 26 22:40:33 " Jun 26 22:40:34 http://www.nslu2-linux.org/wiki/HowTo/ModifyMemorySize Jun 26 22:41:14 Yes, I had problems about a year ago (that was my comment at the wiki...I was just towing the line) Jun 26 22:41:23 ah Jun 26 22:42:51 I could create situations where it would hang. What I did was start 2 separate kernel compiles and then start memtester 200M. That forced the kernel to do a massive swap. But since 4.9 and 4.10, I can't make it happen. Jun 26 22:44:15 sdm485: hmmm, have you wrote that in the wiki? Jun 26 22:44:52 I guess I should. If this current test works, I will. Jun 26 22:46:25 so, I wrote a post to the nslu2-linux yahoo mailing list group asking if anyone in the USA could fatten my slug, but no one in the USA has replied Jun 26 22:47:05 cause I'm not like Reedy, I can't do it =( Jun 26 22:47:22 Mines still as stock Jun 26 22:47:28 oh Jun 26 22:48:22 other than the de-underclock, no hardware mods Jun 26 22:49:17 I really want to fatten my slug, but I don't have the ability to Jun 26 22:49:40 wasnt there someone in canada offering? Jun 26 22:49:44 hmm. I offered to do the labour for up to 10 units as a contribution to the list yesterday. 2 people are interested. Jun 26 22:49:53 :) Jun 26 22:50:01 oh, you? :P Jun 26 22:50:02 sdm485: oh, so I was talking to you? Jun 26 22:50:07 haha Jun 26 22:50:09 sdm485: about Provantage? Jun 26 22:50:21 Right, that's me. Jun 26 22:50:24 sdm485: oh Jun 26 22:50:28 sdm485: coolio Jun 26 22:50:49 sdm485: I really want one..... Jun 26 22:50:54 mail slug, send monies, your laughing ;) Jun 26 22:51:03 my laughing? Jun 26 22:51:11 I came up with a simpler and safer method and thought why not Jun 26 22:51:28 simpler and safer method? Jun 26 22:51:28 your laughing means all is good Jun 26 22:52:10 The logistics are difficult though... I kind of like the idea of just making one and selling it and then making another. But the chips are pretty expensive Jun 26 22:53:38 The original way removed the existing chips and that is where things can get destroyed. I just leave them there but disabled. Jun 26 22:54:24 If they are never selected, they will never be used and will happily sit there in low power mode tristated off the buses Jun 26 22:54:56 sdm485: did you miss my PM again ;-) Jun 26 22:55:07 and if things go very bad, the board is undamaged and 1 wire link returns it 32M. Jun 26 23:48:01 morning Jun 27 00:02:00 hi rwhitby **** ENDING LOGGING AT Fri Jun 27 02:59:56 2008