**** BEGIN LOGGING AT Wed Jan 23 02:59:57 2008 Jan 23 04:51:39 03bzhou * r7642 10optware/trunk/ (4 files in 2 dirs): cdrtools: added a few more config.cache Jan 23 05:14:18 03bzhou * r7643 10optware/trunk/make/wput.mk: wput: 0.6 -> 0.6.1 Jan 23 05:14:48 03bzhou * r7644 10optware/trunk/make/sudo.mk: sudo: 1.6.9p11 -> 1.6.9p12 Jan 23 05:18:35 03bzhou * r7645 10optware/trunk/make/man-pages.mk: man-pages: 2.33 -> 2.76 Jan 23 14:02:08 03osas * r7646 10optware/trunk/make/ (4 files): asterisk14-core-sounds-en: 1.4.7 -> 1.4.8 Jan 23 14:24:50 03osas * r7647 10optware/trunk/make/ (4 files): asterisk14-extra-sounds-en: 1.4.6 -> 1.4.7 Jan 23 17:03:47 03bzhou * r7648 10optware/trunk/platforms/toolchain-slugosbe.mk: toolchain-slugosbe: switch to 4.8beta release toolchain settings Jan 23 18:08:27 03bzhou * r7649 10optware/trunk/platforms/packages-slugosbe.mk: slugosbe: demoted a couple of packages after switching to 4.8b toolchain Jan 23 19:18:04 03bzhou * r7650 10optware/trunk/ (3 files in 2 dirs): ftpd-topfield: no usb_io.patch if slugos Jan 23 21:22:39 so has anyone done a kernel patch to configure the memory controller for more memory? I know that the kernel can be told how much memory it has, but the memory controller has to be set up first. Why not do that from within the kernel? Jan 23 21:23:16 Annirak, yes, all the way to 256MB Jan 23 21:23:34 but there are issues with dma-bounce in configurations above 64MB. Jan 23 21:24:36 I have my slug modified to 256 MB. What kind of problems am I going to see? Jan 23 21:25:06 my understanding is crashes Jan 23 21:25:41 Are there any workarounds other than dropping to 64MB? Jan 23 21:25:50 I would configure it for 64MB currently and when the kernel bug gets fixed (soon I hope) then change to the full 256MB. Jan 23 21:25:59 Annirak, not that I know of. Jan 23 21:26:06 its a bug in the IXP4XX Jan 23 21:26:29 Ah... Well, there's not much I can do about that. Jan 23 21:30:07 Hmm, this is interesting: under update at: http://www.nslu2-linux.org/wiki/HowTo/ModifyMemorySize , sdm485 says that his 2.6.18 kernel doesn't report any DMA errors Jan 23 21:30:24 Perhaps he's refering to 64MB Jan 23 21:31:09 ya Jan 23 21:31:10 probably Jan 23 21:31:40 sdm485 was here yesterday..next time I see him I'll ask him. Jan 23 21:40:51 03rwhitby * r988 10kernel/trunk/patches/2.6.24/ (dsmg600-auto-power-on.patch nas100d-auto-power-on.patch): Updated auto-power-on patches prior to upstream submission Jan 23 21:42:09 Annirak: I have a 256MB slug. There are a number of kernel problems preventing > 64MB operation. blogic from openwrt is working on them. Jan 23 21:42:44 rwhitby: thanks. Jan 23 21:57:46 I think MontaVista linux may have a patch Jan 23 21:58:30 ah, nevermind Jan 23 21:58:59 I found a manufacturer of an IXP425 based system with Linux preinstalled Jan 23 22:04:34 03rwhitby * r989 10kernel/trunk/patches/2.6.23/ (dsmg600-auto-power-on.patch nas100d-auto-power-on.patch): Updated auto-power-on patches prior to upstream submission Jan 23 22:33:11 Anyone know where I can track the status of the work blogic is doing on the 64MB memory limitation? Jan 23 22:34:34 Annirak, I suspect that when he puts out alpha code we will get it in our kernel svn. Jan 23 22:35:40 ka6sox-laptop: I'm just wondering where to look to so I can find out when the code makes it in Jan 23 22:40:22 you might look at the openWRT bug tracking system Jan 23 22:42:00 I did look at that. I couldn't find the bug in question Jan 23 22:49:22 Hello everyone. I have been testing a 256M fatslug and I think I am seeing a kernel problem. When I try do a make setup using the master Makefile, the system hangs during the gunzip. Sometimes the drivelight is stuck on, and sometimes not but ssh is hung. Any ideas? Jan 23 22:49:27 hey, sdm485 I noticed that you have a note on nslu2-linux.org that you have no problems with DMA bounce. Is that referring to a 64MB configuration? Or larger? Jan 23 22:49:41 ahaha Jan 23 22:50:06 sdm485: There's a hardware bug with memory sizes over 64MB. Jan 23 22:50:49 I think I misread my symptoms on that. My 128M fatslug seems very reliable. I should try the same test with it. Jan 23 22:51:41 I just built my first fatslug, not realizing that there was that 64MB limitation. I could have saved myself a lot of trouble had I known :( Jan 23 22:52:13 Annirak, I really expect this to be fixed ASAP. Jan 23 22:52:23 there is a kernel type guy working on it. Jan 23 22:52:34 before there wasn't anybody working on it. Jan 23 22:53:45 ka6sox-laptop: That's good to know. I sorta wondered because I set up to do this project over a year ago, but it got suspended for various reasons. I had planned, way back then to follow the fatslug mod instructions. Jan 23 22:53:58 So I know that people had done fatslugs over a year ago Jan 23 22:54:06 yep Jan 23 22:54:19 but I hadn't seen anything about a memory limitation back then Jan 23 22:55:01 its been there but in the background. Jan 23 22:55:02 :( Jan 23 22:56:10 Well, I hope you're right about the timeline. In the mean time, I need to get a 64MB kernel onto my fatslug. That's my project tonight, I guess Jan 23 22:57:28 I have been running a 128M on current kernels for a while now. No special setup. The big thing is to fix apex to scan for the memory on boot. beta-4.9 Jan 23 22:59:43 Current kernels meaning 2.6.22? Jan 23 23:00:04 The 256M is running 2.6.23.14 Jan 23 23:00:05 I saw that debian has an IXP4xx build of 2.6.22-3 Jan 23 23:00:39 so is the 128M job Jan 23 23:00:57 (I'm intending to run debian, so this is relevant to me) Jan 23 23:02:24 The real issue configuring the SDRAM controller and passing the memory size to the kernel. Unless you can pass the info, it will default to 32M. I suggested a patch a few days ago and use it myself to remove that problem Jan 23 23:03:28 So the bootloader for Debian can be an issue. I don't use it and have not looked so I am just pointing it out. Jan 23 23:06:14 I was planning to recompile my kernel for that Jan 23 23:07:31 in fact, I have been debating building my entire system on my ubuntu box, then dumping it onto my USB drive for the system, as that will be *far* faster than doing the same work on a 266MHz ARM Jan 23 23:07:55 Maybe I should build a gentoo box and use distcc Jan 23 23:08:12 gentoo slug* Jan 23 23:08:15 I have used openslug/slugosbe pretty much the whole time. Jan 23 23:08:58 I was figuring on using debian because debian/ubuntu is the distro I have the most experience with. Jan 23 23:12:05 But I'm willing to try other options. Jan 23 23:12:55 Well, my 128M slug successfully unzipped the nslu2-linux.mtn and is plugging away at the updates. I think there is a runaway swap problem (if I was to guess) Jan 23 23:14:15 That's using openslug? Jan 23 23:15:03 I don't think there is a hardware problem beyond 64M. I think we have been seeing solder joint problems and such. The 128M job had problems with bad solder joints early on and it would boot and run but crash when you did something that actually accessed upper memory. Jan 23 23:15:47 Yes, it is using 2.6.23.14, the latest slugosbe built from the makefile. Jan 23 23:16:53 Did you have to mod redboot or add apex to make the extra memory work? Jan 23 23:16:54 I have tested the 128M job running memtester 110M and compiling a kernel at the same time repeatedly with no problems. Swapping a lot though ..:) Jan 23 23:17:49 (I don't want to use apex because of the serial port requirement) Jan 23 23:18:31 In the most recent beta (4.9), redboot boots into apex which boots into linux. Apex can be used to reconfigure memory. With the patch I suggested, you don;t need a serial port. Jan 23 23:18:34 I have several slugs with apex and no serial port Jan 23 23:19:12 Is this info in the wiki? Jan 23 23:20:06 probably. Jan 23 23:20:19 most things are there. Jan 23 23:20:21 what is needed is a change in the startup string. Check out ModifyMemorySize in the howtos at the bottom Jan 23 23:20:29 the bug is a kernel thing though Jan 23 23:21:15 From what I am seeing, it is after 128M that it shows up. Jan 23 23:21:40 but that's with a 2.6.23 kernel Jan 23 23:21:55 I'm wondering if some of the patching is already in Jan 23 23:22:19 Good point. I should go back to 2.6.21.7 which was considered pretty good IIRC Jan 23 23:23:39 If I did that, I would need to add a serial port to the 256M slug Jan 23 23:24:24 Annirak: there is no hardware bug related to >64MB - it's a kernel problem, not a hardware bug. Jan 23 23:25:28 rwhitby: Thanks. I assumed it was hardware, as linux kernels have supported over 64MB for quite some time now. Jan 23 23:25:31 sorry. Jan 23 23:25:55 sdm485: even without serial, you can change the apex environment using the apex-env tool. Jan 23 23:26:43 Annirak: it's an arm/ixp4xx kernel code problem. Jan 23 23:27:08 rwhitby: Oh. That is great. Thanks :) I will add that to the wiki too. Jan 23 23:27:21 sdm485: so whilst changing the default startup command will be a convenience, it is not a necessity to getting things working. Jan 23 23:28:23 Annirak: you could also re-assemble the debian 8MB image with a new version of apex built from our kernel svn repo, and then use apex-env to change the startup commands on that version to recognise the larger memory Jan 23 23:29:06 rwhitby: Sorry, which problem would that solve? Jan 23 23:30:54 you said you wanted to run debian with >32MB Jan 23 23:31:06 rwhitby: That's correct. Jan 23 23:31:32 you can do that by replacing the old version on apex which gets installed in the debian image with a new version which supports larger memory. Jan 23 23:31:51 rwhitby: Is there a reason for not using the sdram-init and memscan commands by default? Jan 23 23:32:13 So apex is installed while di is running? Jan 23 23:32:25 sdm485: no technical reason, just haven't got to it yet. Jan 23 23:32:30 Annirak: yes Jan 23 23:32:40 apex is part of the 8MB di image you flash Jan 23 23:32:57 OK Jan 23 23:33:01 it's there from the start, and not modified by the installer execution Jan 23 23:33:05 And how would I go about replacing it? I'm a slug newbie. Jan 23 23:33:22 you would use the slugimage tool to unpack an existing image, and then repack with an updated apex Jan 23 23:33:32 ok, that much I get Jan 23 23:33:46 good enough Jan 23 23:33:46 if you want to do fatslug stuff, you've got a learning curve you're going to need to climb ... Jan 23 23:34:10 I've been noticing that. Jan 23 23:34:16 I'm happy to help anyone who documents that help in real time on the wiki. Jan 23 23:34:42 I was going to say that I'd be interested in doing a wiki update from notes as I go Jan 23 23:36:19 I'm not sure I can get started on this today, but if I can, I'll be on here. Jan 23 23:37:00 our kernel repo is at http://svn.nslu2-linux.org/svnroot/kernel/trunk/ Jan 23 23:37:07 the Makefile there can build apex for Debian. Jan 23 23:37:28 slugimage is at http://svn.nslu2-linux.org/svnroot/slugimage/trunk/ Jan 23 23:37:32 (it's just a perl script) Jan 23 23:37:53 get familiar with unpacking and repacking images, making sure you can replicate the original image exactly Jan 23 23:38:04 rwhitby:I last question. could the apex-env live in the sysconf partition? That way it would not get overwritten by a new image. Jan 23 23:38:22 sdm485: it's intentionally not like that Jan 23 23:38:54 since an incorrect apex environment could then cause a slug which cannot be reflashed easily (normal reflashing does not change the sysconf) Jan 23 23:39:09 I'm running XP + Cygwin right now (being at work, and all). So I'm going to have to either wait until my coworker with the linux box goes home, or I go home before I can do anything on this. Jan 23 23:39:20 I see. just curious Jan 23 23:39:31 if you're expert enough to change the apex environment, then you're expert enough to redo the apex environment, or to build your own apex with your desired settings :-) Jan 23 23:39:51 Annirak: I use vmware on XP, running Ubuntu 7.10 in the VMWare session. Jan 23 23:40:06 forget about using Cygwin for linux kernel development. Jan 23 23:40:40 rwhitby: I'd go for that except that I'm running an Athlon XP 2500+ with 512MB of ram. It's painful even running one OS. Jan 23 23:41:12 nod Jan 23 23:41:36 you could dual-boot a ubuntu live cd ... Jan 23 23:41:55 now, that has much more potential. I think I'll bring one in tomorrow Jan 23 23:48:30 03rwhitby * r990 10kernel/trunk/patches/ (4 files in 2 dirs): Add missing bitops patches Jan 23 23:59:45 Is there any particular wiki 'etiquette' regarding removing outdated info? Jan 24 00:01:09 like what? Jan 24 00:02:23 just take it out. If there's a problem, changes can be reverted Jan 24 00:03:31 There is a lot of old info in ModifyMemorySize that is either not necessary or not correct. If you use recent software, a lot of it is irrelevant. Jan 24 00:04:11 then I would categorize it into the different software revisions, with the newest at the top Jan 24 00:05:03 good idea. thanks Jan 24 00:13:07 np Jan 24 00:18:36 rwhitby: is releases/slugos-4.8-beta/nslu2le.tmp/cross/arm-linux/lib supposed be used for staging libraries ? Jan 24 00:19:16 or releases/slugos-4.8-beta/nslu2be.tmp/cross/armeb-linux/lib Jan 24 00:20:10 it is causing problem with optware/slugos{be,le} Jan 24 00:26:47 ah, nslu2be.tmp/cross/armeb-linux/lib is symlinked to nslu2be.tmp/staging/armeb-linux/lib Jan 24 00:27:42 that makes the toolchain lib directory not deterministic Jan 24 00:29:04 ideally toolchain/lib should just contain toolchain libs, like libm, libstdc++, libdl, but no more Jan 24 00:42:06 Just powered up my fatslug for the first test after adding the ram. So far, so good. Jan 24 00:42:19 excellent! Jan 24 00:42:47 memtester is a good way to check it all out. Jan 24 00:43:11 yeah, but first, I need an OS installed Jan 24 00:43:27 and a bootloader that can handle it without a serial port Jan 24 00:43:39 Oh..:) Jan 24 00:43:51 I'll do that this evening once I get home. Jan 24 00:45:51 bye Jan 24 00:47:10 Annirak, what TZ are you in? Jan 24 00:48:57 PST Jan 24 00:49:15 GMT-8 if you prefer Jan 24 00:51:10 I'll be home in ~1h. I'm going to try to wiki the process that it takes me to get my fatslug up in debian. Jan 24 00:54:20 back in about 60 minx Jan 24 00:54:24 -x+s **** BEGIN LOGGING AT Thu Jan 24 01:05:20 2008 **** ENDING LOGGING AT Thu Jan 24 02:59:57 2008