**** BEGIN LOGGING AT Sun Apr 15 02:59:56 2007 Apr 15 02:59:57 yeah, but isn't it more correct to patch the source files? Apr 15 03:00:00 ah Apr 15 03:00:03 I see Apr 15 03:00:33 yes, patching configure.in is more correct Apr 15 03:45:34 jacques: true if PL2303 detected, just gotta check pinouts of chip and figure out which pins go to TX/RX of cable (assuming you cut off the phone cable connector) Apr 15 03:46:33 RobNC, yep Apr 15 03:46:56 RobNC: hi Apr 15 03:47:28 hi rwhitby - was away - doing work laptop backup (can't trust IT guys to do it right) Apr 15 03:48:14 heh Apr 15 03:49:28 this week has been horrible in getting microscope time, unfortunately. I can do the mods in about 2 hours, if uninterrupted and people don't come by and ask "hey what (work) board is that?" Apr 15 03:51:08 lol Apr 15 03:51:37 exactly, then "why do you need to modify the memory", or "why don't you just Apr 15 03:52:07 (insert any of a dozen or so answers from engineers who are naturally curious) Apr 15 03:52:27 ot would be exactly the same where I work Apr 15 03:52:29 it Apr 15 03:52:54 I'm still trying to figure out how to get one of the techs to do my mods for me Apr 15 03:54:05 we have some good techs, but the one for my group, often times, I can do it quicker myself, without having to explain in great detail how to do it. It's hard to find someone content with being a technician and no desire to "reach higher" in skills. Apr 15 03:56:19 But at least all the interruptions are nothing compared to me bringing my son to the lab :-) Apr 15 03:58:08 rwhitby: I was thinking - is there some way that ppl could provide downloadable images (other than the slugimage site) via setting up some kind of wrapper from the Intel licensing page to the actual location? Apr 15 03:58:58 I have often seen people offer to make images, etc. and the licensing thing is a pain (not that I don't disagree with it). Certainly better than some companies. Apr 15 03:59:36 (oh BTW I updated the wiki's again - to add more accurate info to FatSlug and etc.) Apr 15 04:00:34 RobNC, I heard you booted a 256MB slug, congrats! Apr 15 04:00:39 any issues? Apr 15 04:02:21 jacques: yeah thanks. It would have worked sooner, if it wasn't for the ' character messing up the parameters. Grr... Only problem so far is a couple of times I had rsync hang on me, I think it was related to a problem that wasn't found on fsck (when I forced a reboot by poweroff). I have a cronjob run every 2 hours and so far it seems to be running fine Apr 15 04:02:59 RobNC: _CoreDump|home has a snapshot site Apr 15 04:03:06 RobNC, nice! Apr 15 04:03:19 wonder if I need more bulk decoupling for the SDRAM tho. Apr 15 04:04:38 huh? Apr 15 04:05:17 oops I just noticed that it was hung. no heartbeat. WHOOPS. Apr 15 04:05:59 Could also be that, before running this, I had both HDDs separated by the NSLU2 enclosure. Now they're stacked (and too hot). Apr 15 04:08:07 one bug that is really irritating on both NSLU2 and CentOS so far. If the DHCP server doesn't respond (let's say DHCP router is hosed), it never re-tries to get an anddress. Apr 15 04:08:32 yes, my wrt did that to me just the other day Apr 15 04:08:45 RobNC: yeah, we're trying to fix that in slugos udhcpd. Apr 15 04:09:06 also fix it with CentOS while you're at it *big grin* :-) Apr 15 04:09:33 It's kinda embarrassing that MS-Windows does this but yet linux cannot (or by default). Apr 15 04:11:48 For at least debian, it seems that there is /etc/dhcp3/dhclient.conf parameters "timeout", "retry", etc. Apr 15 04:12:50 RobNC: I'm going to be away on holidays from 17th to 27th, but just email my personal account if you need anything. Apr 15 04:13:50 ok thanks, I'll be out of town for a few days the end of month (work-related); not sure when yet (MoCA) Apr 15 04:14:04 how long does shipping USPS take? Apr 15 04:14:37 * mwester dimly recalls patching busybox to fix the DHCP problem. Apr 15 04:14:39 * rwhitby assumes MoCA stands for multimedia over coax rather than museum of contempory art ... Apr 15 04:14:55 haha true. I'm no museum piece :-) Apr 15 04:15:25 i think the shipping takes about a week. I'd be happier for you to do more testing there before sending it ... Apr 15 04:15:30 mwester: hey thanks I was just kidding... I could hack it myself but better that the upstream be patched, if possible. Apr 15 04:16:05 rwhitby: ok that would be even better. It looks like my SLUG hung during the last rsync. I have it log to /var/log/xx file Apr 15 04:16:40 RobNC: yeah, don't ship until you're rock solid confident. Apr 15 04:16:42 I don't think it was memory related but dunno yet. This setup worked for at least 4 months at 32MB config Apr 15 04:17:15 anyone have any suggestions or ideas for USB2,3,4 wiring suggestions? Apr 15 04:18:21 I think NAiL wired them up once. Apr 15 04:18:44 jacques: yes mine too (Buffalo WHR-HP-G54) - same hardware as linksys Apr 15 04:18:44 I remember someone taking a usb flash key apart, and wiring it up directly. Apr 15 04:19:40 rwhitby: yeah that's a bit too drastic for me. I would like to add some more USB ports but do it more cleanly. I might just use some dead motherboard USB port (double-decker). Apr 15 04:20:09 jacques: but now running Tomato - it has some kind of watchdog timer so router resets if it crashes. Apr 15 04:21:26 I might use some motherboard header-to-PC case slot connector for that. I Apr 15 04:22:49 I am more worried about where to wire some kind of stress/strain relief. There are no holes that can go from back to front, that I know of. Not sure if there is clearance between case and pcboard slots for USB cable. Apr 15 04:25:17 there's clearance under the power socket for a mini-USB socket at least Apr 15 04:25:54 weird... NSLU2 just hung again but not like what you might think. I had a shell prompt on it and could continue to hit "return" to get a new line, but "ls" just hung. Seems like some kind of problem with fs, not memory, right? Apr 15 04:26:34 yeah Apr 15 04:27:17 Was that DMA problem ever identified or resolved? Apr 15 04:27:37 dunno Apr 15 04:28:17 rwhitby: good thought but they may be hard to get hold of. I might just have some kind of dangling cable from NSLU2 Apr 15 04:28:27 DMA problem? Apr 15 04:28:35 dmabounce Apr 15 04:29:22 If I can help let me know.. Apr 15 04:30:18 http://bugzilla.kernel.org/show_bug.cgi?id=7760 Apr 15 04:31:07 you might want to contact Stephan (http://thread.gmane.org/gmane.comp.misc.nslu2.devel/1486/focus=1488) to see if he is still having problems with 128MB Apr 15 04:32:10 lemme look at my log files - see if I have similar problems Apr 15 04:32:44 http://purl.rikers.org/%23openslug/20070105.html.gz Apr 15 04:33:53 that sounds scarily just like my problem. I.e., it looks like the PCI=> USB bridge died Apr 15 04:34:35 g2 memtions memory test - how to run that? Apr 15 04:35:02 ah nm I saw it Apr 15 04:36:25 ah I was afraid of that Apr 15 04:36:47 it is called "memtester" Apr 15 04:36:56 apt-get install memtester Apr 15 04:37:03 as soon as it tries to DMA to above 64MB badness happens (IIRC) Apr 15 04:37:42 well it seems to work okay at least partially... during multiple rsync's, I saw "free" using almost all the 256MB Apr 15 04:38:16 I was never sure whether people were getting confused between memory space and PCI IO space Apr 15 04:38:34 heh yeah PCI also uses memory space Apr 15 04:38:37 (and I didn't understand enough about it myself to judge) Apr 15 04:38:56 I might have to bone up on it now if I'm getting a fatslug myself ... Apr 15 04:40:01 heh maybe. PCI does use memory; look on your PC - all PCI devices have to use memory space. I have a friend at work whose nearly an expert at PCI, I'll have to ask him if you want. Apr 15 04:41:16 whoops! Just saw it go south. Apr 15 04:42:04 did "memtest 256M 1" (one time) Apr 15 04:42:39 oops - echi_hcd unable to mape unsafe buffer Apr 15 04:42:51 could not allocate dma memory Apr 15 04:43:06 lemme get this into a pastebin - gimme a few mins Apr 15 04:45:53 too bad I couldn't get something like "knoppix" equivalent for NSLU2, for testing with removable USB device (and w/o having to reinstall) Apr 15 04:48:31 (grr gotta reboot work PC b/c critical update - reboot Wednesday) Apr 15 04:49:43 brb Apr 15 04:53:47 hmm, upgrading from 2.6.17 to 2.6.20 - *lots* of stuff changed :-\ Apr 15 04:54:24 hmm, really... I saw that my latest build did 2.6.20 Apr 15 04:55:58 2.6.20 must not be part of the debian arm mainstream yet Apr 15 04:58:48 I have a feeling I'm going to have to go through a few iterations before 2.6.20 is right on my laptop Apr 15 04:59:59 This is true... rwhitby didnt you say that debian le is no longer part of the nslu2-linux distribution (?) build process? Apr 15 05:00:08 hmm, I think this is the kernel which changed the way pata devices are handled Apr 15 05:01:23 doing memtest of 128M seems a lot cleaner than 256M Apr 15 05:01:47 pretty impressive routine Apr 15 05:01:50 I love this: Apr 15 05:01:51 Intel PIIX/ICH SATA support Apr 15 05:01:59 heh on SLUG? Apr 15 05:02:01 This option enables support for ICH5/6/7/8 Serial ATA Apr 15 05:02:01 and support for PATA on the Intel PIIX3/PIIX4/ICH series Apr 15 05:02:01 PATA host controllers. Apr 15 05:02:17 it's *called* SATA, but it's now for SATA and PATA Apr 15 05:02:26 talk about confusing Apr 15 05:02:53 yeah that is wild.. I saw that recently.. indeed confusing!! what is it now - /dev/hda or /dev/sda or /dev/sga etc Apr 15 05:06:02 so far seems 128M test is passing. Apr 15 05:06:04 it will probably be /dev/sda (used to be /dev/hda) Apr 15 05:06:20 but I haven't built it yet, still configuring Apr 15 05:06:24 how confusing... yeah, sdx = is it SATA or PATA? Apr 15 05:07:10 I hear that Debian (kernel) will soon (if not already) support mounting partitions based on label, versus device. That's prolly only work-around Apr 15 05:07:51 RobNC: debian kernels are built by debian, not by nslu2-linux Apr 15 05:08:06 slugosle is still supported (LE SlugOS, compatible toolchain with Debian) Apr 15 05:08:16 rwhitby: gotcha, that was the recent change. Apr 15 05:10:54 NSLU2 dma problem: probably should have done "memtest all" but it's also good to know what works (reliably) first I guess. Apr 15 05:11:31 So rwhitby if a DMA problem exists, I presume that it would exist in both slugosXe and debianXe (X=l/b) Apr 15 05:11:59 yep, the kernels should be the same in that area. Apr 15 05:12:15 jacques; that reminds me I saw that with latest Knoppix. it's all sda (for hda) now. Apr 15 05:12:57 at least "hdparm" doesn't only look for /dev/hd* for devices now Apr 15 05:17:18 RobNC: do you have a pastebin of the kernel messages on error? Apr 15 05:18:44 not yet. I'm still running "memtest 128M 1" (1 try). It is passing so far. After that, I'll do the "memtest all 1" or the command that crashed the OS: "memtest 256m 1". Note: if I don't specify "1", it defaults to 2^32-1. That'd take years with the slug Apr 15 05:22:46 (work laptop hung with TeraTerm - tried to save buffer to disk but wifi over VPN crapped out and killed EXPLORER.EXE) Apr 15 05:24:32 can anyone tell me how many "tests" are part of memtest? It says "Test 11: Block Sequential" and 112... (number keeps incrementing). I thought it was a percentage but dunno what it is now that it's >100 Apr 15 05:26:09 dunno - never run it before. Apr 15 05:26:24 I'll tell you - after it's done :-) Apr 15 05:34:58 another dma bounce thread: http://lists.arm.linux.org.uk/pipermail/linux-arm-kernel/2007-January/037844.html Apr 15 05:36:08 dammit does this mean I have to change my fstab? Apr 15 05:36:34 jacques: ? Apr 15 05:37:13 thks rwhitby - documenting this Apr 15 05:37:28 rwhitby, the change to 2.6.20 on my laptop Apr 15 05:37:31 jacques: prolly if need /dev/sda1 instead of /dev/hda1 Apr 15 05:37:41 I think my /dev/hda? will become /dev/sda? Apr 15 05:37:50 why the fsck did they do this Apr 15 05:37:52 problem: you'll have to change it on the old kernel, then save and boot into new kernel Apr 15 05:38:10 means can't boot back and forth between kernel versions Apr 15 05:38:15 yep. heh I love your fsck Apr 15 05:38:21 yes exactly! Apr 15 05:38:29 that's why it's better to use labels if possible Apr 15 05:38:45 i.e., in fstab, LABEL=root Apr 15 05:38:47 or whatever Apr 15 05:38:50 I don't trust labels. they have bitten me plenty of times Apr 15 05:39:07 like when you have two hard drives Apr 15 05:39:14 if the kernel, etc. supports it. are you using grub too? Apr 15 05:39:16 and both have a partition called root Apr 15 05:39:29 yes, grub Apr 15 05:39:40 yeah but both hdd's in theory shouldn't have identical labels, unless they're like ghost backups or something Apr 15 05:39:45 oh that stinks! Apr 15 05:40:08 yeah you're fscked alright Apr 15 05:41:07 with debslug I named the partitions "root" and "rootbak", for / on /dev/sda1 and / on /dev/sdb1 Apr 15 05:42:04 ok, going to reboot. will have to build ati drivers so will be a bit before I get back (even if everything goes fine) Apr 15 05:42:12 rwhitby: memtest went to 255 then back to 0. Test 12 right now. No idea how many total test numbers Apr 15 05:42:22 jacques: ok cool u hope Apr 15 05:42:56 Test 12: Checkerboard: Setting... 25 Apr 15 05:43:12 that number "25" above keeps incrementing (sorry for being confusing) Apr 15 05:45:53 this looks like the origin of the dmabounce code for arm: http://lists.arm.linux.org.uk/pipermail/linux-arm-kernel/2004-March/020737.html Apr 15 05:46:54 that is quite old! Apr 15 05:47:13 maybe that is why linksys didn't make them with 128MiB :-) Apr 15 05:48:30 more background dma reading: http://lists.arm.linux.org.uk/pipermail/linux-arm-kernel/2003-June/015758.html Apr 15 05:51:51 indeed. very detailed Apr 15 05:53:46 more: http://lists.arm.linux.org.uk/pipermail/linux-arm-kernel/2005-January/026346.html Apr 15 05:55:06 (firefox is running out of tabs) :-) Apr 15 05:57:08 Is it even possible to access more than 64MiB through the PCI bus? I don't see how this would ever happen, unless it's because of buffers being allocated (as a PCI address) but then never being recycled (i.e., like a memory leak) Apr 15 05:58:14 s/recycled/flushed/ - I think that's the right term Apr 15 06:00:41 more: http://lists.arm.linux.org.uk/pipermail/linux-arm-kernel/2006-June/034900.html Apr 15 06:04:01 see this : The VM decided you were out of 16K pages in the DMA zone and refused to allocate you the page. Apr 15 06:04:31 yeah Apr 15 06:04:37 "This is one of the hazards of using the DMA bounce code - if you have large allocations, the VM can choose to refuse to allocate you memory, especially when you ask for it in atomic contexts." Apr 15 06:04:41 is that what you are seeig? Apr 15 06:04:51 seeing Apr 15 06:05:06 "You're probably seeing this because 128MB could be sufficiently large that you're starting to use the bounce buffers; since I don't know NSLU2 hardware (or even IXP hardware) I couldn't say for certain though." Apr 15 06:06:05 Yeah I think it had to be but I couldn't capture it. It never got this far with memtest 256M. But, now testing with memtest 128M seems to run clean. Maybe it's something related to the end of memory or something (which explains why 64M on 128M platform works clean) Apr 15 06:08:14 currently in test 14 of X where X >=14. Apr 15 06:09:08 RobNC: does the debian kernel set CONFIG_IXP4XX_INDIRECT_PCI? Apr 15 06:10:05 I didn't build the debian I'm running right now. It's the stock (D-I RC2 = v4.0). Apr 15 06:11:00 will look in my source files Apr 15 06:12:19 so it didn't change my hard drive device names Apr 15 06:12:38 looks like it's not set in any of slugos, debian, or upstream ixp4xx configs. Apr 15 06:12:45 that's always good. never know the order of these. Just like having 2 NICs, which is eth1/eth0 Apr 15 06:12:45 so at least that is consistent Apr 15 06:13:26 too bad there isn't some sort of config you can use the HDD serial number or something, for guaranteed correct enumeration Apr 15 06:13:26 I'm trying something new - setting HZ to 300 Apr 15 06:13:29 ok, I've exhausted my deductive powers now ... Apr 15 06:13:37 RobNC: uuid - slugos uses it. Apr 15 06:14:10 rwhitby: ah UUID is effectively the same thing? Apr 15 06:15:02 btw I grep'ed my debian source for CONFIG_IXP4XX_INDIRECT and didn't see anything Apr 15 06:18:19 now doing grep CONFIG_IXPXX Apr 15 06:22:03 I think the INDIRECT_PCI config setting is where people got mixed up between pci memory space and kernel memory space. Apr 15 06:22:06 rwhitby: seems that the page you pointed to bugzilla shows something very similar to what I saw (but couldn't capture to a file). Too bad the poster didn't post a dmesg or something to know what the actual address ranges were during boot. I.e., is the DMA routine trying to map to memory outside physical? Apr 15 06:22:43 some people said that INDIRECT_PCI should be set cause we have memory > 64MB, but they didn't realise the difference between PCI memory and kernel memory. Apr 15 06:23:35 is there a difference - guess it could be mapped with addr acting like CS if necessary. This seems to indicate it's the same http://www.nslu2-linux.org/wiki/Info/MemoryMap Apr 15 06:24:33 I think PCI memory should be fixed, since it doesn't vary based on RAM, right? Apr 15 06:24:53 right Apr 15 06:24:59 I.e., PCI address should be independent (but not overlapping) RAM space Apr 15 06:25:04 what physical address will the top of 256MB be? Apr 15 06:25:34 i.e. are we running out of room in that memory map? Apr 15 06:26:11 (looking at dmesg) Apr 15 06:27:22 nothing useful there. seems cat /proc/meminfo also doesn't show actual memory locations used Apr 15 06:28:03 ah here we go Apr 15 06:28:13 it's in /proc/iomem Apr 15 06:28:15 nope, 256MB fits in that first line of the table up to 0x10000000 Apr 15 06:28:29 System RAM: 0x00000000-0x0fffffff Apr 15 06:28:48 PCI space: 0x48000000-0x4bffffff Apr 15 06:30:08 I'm out of ideas ... Apr 15 06:30:30 ohci_hcd (USB) is using 0x48000000 0x48000fff Apr 15 06:30:54 for first HDD, then 2nd is using 1000-1fff (0x48...) offset Apr 15 06:31:41 true. Test 16 now... walking zeros. This thing is taking forever but I am developing a higher appreciation of my soldering skills (no mem problems so far but only testing lower bank) Apr 15 06:32:32 I see your point, that the mem table says 32M but actually refers to 256MB window (wiki) Apr 15 06:36:55 Lemme do the test of 256MB, when that crashes I'll do a pastebin. I'll also try with 192M (to on purpose NOT hit the upper mem limit) Apr 15 06:38:18 1 runs completed. 0 errors detected. Total runtime: 5838 seconds. Apr 15 06:38:22 thanks for being patient Apr 15 06:40:41 program died but I got a crashdump to the screen. Dunno if PCI could be dead b/c I can still get a prompt by hitting return. Haven't tried seeing if USB is crashed. Apr 15 06:40:49 network processor is off PCI right? Apr 15 06:41:01 I mean the PHY is off the PCI bus? Apr 15 06:42:41 dunno Apr 15 06:43:33 weird... memtest crashed but I still can access USB filesys Apr 15 06:43:47 maybe try it again dunno either Apr 15 06:45:10 ok now I think I killed it - got the "unable to map unsafe buffer" msgs Apr 15 06:45:31 that is for ehci_hcd (USB controller) Apr 15 06:46:01 ok it crashed. Gonna pastebin now Apr 15 06:50:48 here tis: http://wwww.pastebin.ca/440708 Apr 15 06:51:21 here tis: http://www.pastebin.ca/440708 Apr 15 06:59:20 RobNC: can you post that to linux-arm-kernel? Apr 15 07:00:12 sure, what list? (is that the spambot list - heh) Apr 15 07:03:01 think I found it... Apr 15 07:07:37 RobNC: make sure you mention the previous discussion, and the kernel bugzilla entry, and that you're willing to help debug the problem ... Apr 15 07:08:13 try and get RMK interested enough to help solve it ... Apr 15 07:08:27 thanks, trying to wade through the fluff to figure out how to subscribe. (true Apr 15 07:08:58 keep things general (it's an XScale ARM with 256Mb of memory and usb on PCI, versus saying first up that it's an NSLU2) Apr 15 07:09:55 maybe even reply to RMK Apr 15 07:10:07 's thread specifically at http://lists.arm.linux.org.uk/pipermail/linux-arm-kernel/2007-January/037853.html Apr 15 07:10:39 (then you can CC him and just say it was an accidental "reply all" instead of a blatant attempt to get his attention) Apr 15 07:10:47 bbiab Apr 15 07:10:49 how ironic - the arm listinfo doesn't tell you how to subscribe. it's the uk one.. Apr 15 07:10:52 ok np... Apr 15 07:28:39 back Apr 15 07:28:53 RobNC: I'm happy to proofread anything if you like. Apr 15 07:29:11 ok, still waiting for the invitation request. It's slow. Apr 15 07:33:13 (getting email message organized and concise) Apr 15 07:35:22 One link you sent said "IXP425 IDE DMA" but that is inaccurate. The IXP425 doesn't have IDE controller :-) Apr 15 07:37:48 ah, but the nas100d for instance has ide on pci on ixp425 Apr 15 07:38:06 Oh so there is a controller off PCI bus? Apr 15 07:38:15 yep Apr 15 07:38:49 ok, that makes sense. Should say "IXP425 PCI =>IDE DMA" Apr 15 07:39:36 yeah, you will want to make sure everything is precise so that no-one has an opportunity to deflect the real issue ... Apr 15 07:40:34 nas100d has pata_artop, ath_pci and usb on pci Apr 15 07:40:50 (64MB ram) Apr 15 07:41:03 I see. gotta narrow in quickly at the problem Apr 15 07:43:14 this kinda bothers me: Apr 15 07:43:29 Free swap = 5596kB Apr 15 07:43:30 Total swap = 257024kB Apr 15 07:43:55 BTW, I've compared the ixdp425 board config with nslu2 as far as pci config goes, and can't see any differences. Apr 15 07:45:02 yes, the IXP425 includes AES and DES (used for MoCA) Apr 15 07:51:51 I was surprised to see those IX425's in MoCA CPEs (it is not required but it makes for a cheap modem). It must be doing DMA transfers, as it's able to do 100Mbps transfers to/from MoCA. Makes me wonder why NSLU2 is so slow (30-40Mbps), perhaps because it is processor-bound and uses the USB bridge in PIO-mode? Apr 15 07:55:12 dunno Apr 15 07:57:44 almost done with email Apr 15 07:58:56 ok, I'll chase the kids around the back yard for a while and then come back and read it. Apr 15 07:59:17 ok, I'll prolly be zzz as its nearly 4AM here (yikes!) Apr 15 08:12:34 just pastebin it Apr 15 08:13:14 ok Apr 15 08:13:52 haven't done the test of 192M - gonna do that next Apr 15 08:14:04 http://www.pastebin.ca/440751 Apr 15 08:15:30 RobNC: it would be much better if we could reproduce this with vanilla kernel, rather than saying you're running Debian Apr 15 08:15:46 (and be able to reproduce with 2.6.21 for instance) Apr 15 08:16:01 when you say vanilla kernel you mean one that I compiled, etc? Apr 15 08:16:27 like in /home/slug/kernel - if you say Debian, they will use that to confuse the issue Apr 15 08:16:32 ok we can do that. I already have the 8MB flash backed up. Apr 15 08:16:48 ah gotcha... "debian issue - submit to debian list" etc. but really a kernel issue Apr 15 08:16:52 memtester is in slugos packages Apr 15 08:17:15 what's smallest flash USB I can install slugos? Apr 15 08:17:21 you could probably run it all from flash too Apr 15 08:17:32 you can install slugos with no external storage Apr 15 08:18:14 gotcha... ok then do some disk access commands and then see the problem. With slugos, is /tmp etc. in ramdisk or flash? Apr 15 08:18:49 /tmp and /var are in ramdisk for stock slugos that hasn't been turned up to disk Apr 15 08:19:08 ok, think the problem will still happen w/o disk? Apr 15 08:19:20 that would be an interesting data point, right? Apr 15 08:19:25 true... Apr 15 08:19:43 but if DMA process is different, it may not help. Apr 15 08:19:47 OE has http://pyropus.ca/software/memtester/ available Apr 15 08:19:55 but it couldn't hurt! Apr 15 08:20:01 what is the memtest package from debian? Apr 15 08:20:44 but the first thing l-a-k will ask you to do is reproduce with latest kernel anyway Apr 15 08:21:44 it's called memtester for DI too Apr 15 08:23:05 is 2.6.21 avail - latest I saw was 20. Apr 15 08:23:33 getting latest ... via monotone Apr 15 08:26:13 RobNC: /home/slug/kernel has 2.6.21 - OE only has .20 Apr 15 08:26:26 RobNC: don't refer to all the messages in the past - just the one from RMK. Apr 15 08:26:38 (or put the other messages right at the end if you want to refer to them) Apr 15 08:27:38 ah ok - modding... Apr 15 08:27:52 Put the lines from the error message which show RMK that it's the same problem he saw before up near the top of the message, so he recognises it immediately. Imagine that he will only scan the first 30 lines or so. Apr 15 08:32:00 yeah this is true... was considering that. Apr 15 08:50:41 http://pastebin.ca/440775 Apr 15 09:10:24 kernel 2.6.18, no -4 - also say that you are prepared to reproduce with 2.6.21 if necessary. Apr 15 09:10:55 ok, was gonna try that anyway. List moderator approval required first (got confirmation email) Apr 15 09:11:53 ", after this occurs" - what does that refer to? Apr 15 09:13:48 technically I didn't get the same msg as rmk but I would, if I was using more memory, and did something that required even more memory. Apr 15 09:14:28 (I am guessing that the error might be different for 2.6.18 than for rmk bug msg) Apr 15 09:16:42 any problems aborting a kernel build in process? I did "make openslug" but then I realized it was OE (older version as you said) Apr 15 09:22:18 RobNC: shouldn't be Apr 15 09:25:25 k, gonna try make slugosle. seems svn co is all that is needed to upgrade kernel right (svn co ... all the other parameters) Apr 15 09:26:50 forgot u gotta make clobber first to get new kernel compiled Apr 15 09:44:25 rwhitby: is there enough free space to ipkg memtester with slugosle? Apr 15 09:44:34 (without HDD attached) Apr 15 09:48:39 ttyl gotta zz Apr 15 09:50:37 RobNC: should be Apr 15 15:48:40 <[g2]> RobNC, around ? Apr 15 16:11:04 Hi, g2 sorry I am here a little Apr 15 16:21:47 [g2] I am back for a bit Apr 15 16:32:38 <[g2]> RobNC, I heard you had some questions about fatslulg ? Apr 15 16:33:17 hi, [g2]. yeah got some DMA problems with fatslug. ever heard of this? Apr 15 16:34:36 seems like the USB bridge dies when memory usage goes above a certain amount. Gonna post msg to linux-arm-kernel but gotta get approval for list first Apr 15 16:35:05 when memory passes 128mb, perhaps? Apr 15 16:35:10 rwhitby pointed me to a lot of posts, going all the way back to 2002, when this problem was first found. (possibly) Apr 15 16:35:30 NAiL: yes this seems to b e. I did "memtest 128m 1" in debian, and it passed. Apr 15 16:36:08 even did "memtest 192m 1" and that passed just fine. Trying "memtest 250m 1" failed immediately. Apr 15 16:36:21 ah, ok Apr 15 16:36:52 seems like when you get too close to the upper memory limit. One post said (he had 128M) that his failed when exceeding 64MB. Apr 15 16:38:22 hmm, ok Apr 15 16:38:37 does it make a difference if you change INDIRECT_PCI? Apr 15 16:39:09 gonna try slugosle next, with 2.6.21. Currently running 2.6.18 debian kernel (but that has same lower-level code as other distributions) Apr 15 16:39:36 that'll require kernel recompile I take it (not sure where that is but I can build my own kernel) Apr 15 16:39:51 Yeah, you'll need to recompile Apr 15 16:40:24 recompile is not an issue, but I'm not 100% familiar with all the ins/outs/caveats just yet. Apr 15 16:41:17 If I did "make sluglosle", will that use apex as 2nd stage bootloader, or does it boot right from redboot? Apr 15 16:41:55 or will I have to "make apex" in the kernel directory? Apr 15 16:42:14 I don't think it'll build apex, no Apr 15 16:42:16 I have compiled Apex 1.4.17 and it successfully finds and uses 256MB Apr 15 16:42:38 ok, figured as much (so if virgin RedBoot it won't use >32M) Apr 15 16:42:40 but you don't need to reflash apex, just flasha new kernel ;) Apr 15 16:43:16 <[g2]> RobNC, I'm guessing you've got apex or Redboot setting up the memory properly Apr 15 16:43:33 <[g2]> RobNC, I'll bbiab lunch Apr 15 16:43:37 gotcha, will use slugimage to extract/etc. [g2] yes newer apex Apr 15 16:43:44 ok [g2] tt in a few Apr 15 16:46:55 NAiL: ok gonna see if I can get the params right first... can I just upload the kernel to RAM, then copy to flash, from RedBoot? Apr 15 16:48:10 you can use upslug to flash a new kernel, or reflash Apr 15 16:48:13 that's easier ;) Apr 15 16:49:05 I'm more comfortable using TFTP and redboot. I know most ppl use the upslug but perhaps I am more hands-on :-) Apr 15 16:49:13 ok Apr 15 16:49:28 oh wait, you mean u can use upslug to only replace the kernel? is this from redboot upgrade mode right? Apr 15 16:49:35 yup Apr 15 16:50:26 ok, that sounds safer. I've already backed up 8MB (working debian) so no worries, and I have JTAG (due to PEBKAC). Apr 15 16:52:06 NAiL: ok gimme few mins to read wiki, try, etc. before I need help :-) Apr 15 16:54:43 NAiL: it appears to me that you still need 8MB image to use upslug. I don't want to re-make an 8MB image (with new Apex) - just want to upload and re-flash the linux kernel with slugosle. Apr 15 17:05:18 hmm? I thought upslug2 could reflash only kernel, only fs, or both Apr 15 17:07:29 not that I saw, unless it wasn't in the wiki Apr 15 17:07:56 I've already slugimage'ed both images (slugosle with new kernel, and working debian with new apex). Apr 15 17:08:08 nah, I think you'll have to do upslug --help to see the usage Apr 15 17:08:22 I see there's an upslug2 Apr 15 17:08:30 yeah Apr 15 17:11:21 it's not a big deal either way... really dumb question but I have to ask - is there a difference in vmlinuz whether used from redboot or 2nd stage from apex? Apr 15 17:12:49 from slugimage (perl), extraction shows these: Apr 15 17:13:16 debian w/apex: RedBoot, SysConf, apex.bin, vmlinuz, ramdisk.gz, Trailer Apr 15 17:13:53 slugosle (w/o apex): RedBoot, SysConf, vmlinuz, ramdisk.gz, Flashdisk, NPE-B, Trailer Apr 15 17:18:11 I'm just wondering, b/c slugosle vmlinuz size is 0x000FE100 but from Debian (apex 2nd stage) shows vmlinuz size 0x00121B38 (greater than 1MB). I thought there was some kernel limit whereby kernel can't be >1MB Apr 15 17:18:42 yeah, that's a redboot limit Apr 15 17:19:21 ok, so if I put the smaller image (from slugosle) into debian (2nd stage) it won't be a problem? Apr 15 17:19:40 ah nm it's moot anyway since not using redboot to boot kernel Apr 15 17:26:22 NAiL: you're right - upslug2 (following wiki) does support just the kernel upgrade. I wonder if it is smart enough to realize where to put it (i.e., don't overwrite apex 2nd stage where normally that is where the kernel resides) Apr 15 17:28:51 I don't know ;) Apr 15 17:29:20 yeah, reading the parameters while being interrupted by my son asking questions :-) Apr 15 17:29:20 rod should know though Apr 15 17:29:52 I think zImage and vmlinuz are synonymous Apr 15 17:30:13 (from days I recompiled linux years back) Apr 15 17:30:25 I dunno if the debian kernel has the same header as the slugos one Apr 15 17:30:29 the shim, that is Apr 15 17:31:37 yeah, that is true... that's why I'm a little tempted to use slugimage to have it create it for me (from the pieces). I think Rod wrote that. Apr 15 17:32:04 <[g2]> RobNC, which bootloader are you using now ? Apr 15 17:32:25 I think jbowler wrote upslug, but rwhitby did the last modifications, IIRC Apr 15 17:32:38 [g2]: redboot-> apex -> debian 2.6.18. Gonna try 2.6.21 Apr 15 17:32:47 (I meant rwhitby wrote slugimage I think) Apr 15 17:33:38 <[g2]> RobNC, I'm not sure how well the memory init would work from APEX Apr 15 17:34:52 [g2] it works great - I'm using new apex 1.4.18 (has working "sdram-init" and "memscan") Apr 15 17:35:04 that's how the 256MiB is detected successfuly via kernel Apr 15 17:35:49 <[g2]> RobNC, it's probably changing the memory controller information, but I don't know how well that'll really work on a live system Apr 15 17:36:33 <[g2]> redboot is loading APEX in memory at some address and executing the code there Apr 15 17:37:08 <[g2]> so it'd be interesting to look at the sdram-init code and see what it's doing Apr 15 17:37:11 [g2] it seems to work well. i.e., same as having apex as 1st stage boot loader. Ppl with DMA problems with PCI bus are having it with apex w/1st stage. Apex turns off cache and is able to successfully set sdram parameters. Apr 15 17:37:28 http://wiki.buici.com/wiki/Apex_Bootloader Apr 15 17:38:04 <[g2]> RobNC, I was one of the first guys to run APEX on the slug Apr 15 17:38:12 ah ok! :-) Apr 15 17:39:40 [g2] do you suspect the memory controller is not being configured properly? Apr 15 17:41:34 <[g2]> RobNC, I'm wondering about the effects of reconfiguring the memory controller while executing from memory Apr 15 17:41:51 <[g2]> and possible cache flushing issues Apr 15 17:42:09 <[g2]> You've got JTAG right ? Apr 15 17:42:12 [g2] according to wiki, "sdram-init function uses the cache to store part of APEX while the SDRAM controller is being reprogrammed." Apr 15 17:42:16 [g2] affirmative Apr 15 17:42:48 so that means it's reprogramming sdram controller while running from cache. Apr 15 17:42:49 <[g2]> it's possibly that he copies the code to cache and is executing out of cache while the controller is reset Apr 15 17:43:11 so no issue of running in sdram while changing config reg (that would be a nasty race condition) Apr 15 17:43:34 yes indeed it seems he is doing as you say Apr 15 17:44:30 <[g2]> well there's lots of stuff like resetting the pci bus that should probably be done Apr 15 17:44:58 <[g2]> as the pci controller may have some stale pointers / config Apr 15 17:45:29 <[g2]> I'd just stick APEX in the 1st flash sector and boot from APEX Apr 15 17:45:40 <[g2]> you've got serial right ? Apr 15 17:46:02 <[g2]> If you enable stuff in the kernel, you can replace the bootloader by a simple "dd" Apr 15 17:46:31 <[g2]> When I was testing with bewoolie I probably did that like 50-100 times Apr 15 17:46:44 <[g2]> switching between APEX and the RedBoot Apr 15 17:47:00 eno: where can I take a look at your lighty config patch? Did you check it in? I may take a crack at porting it over to the OE lighty build Apr 15 17:47:30 yeah I thought of that but then that pretty much means reflashing via xmodem (slow) or JTAG (very very slow) Apr 15 17:47:45 <[g2]> RobNC, you can reflash from linux Apr 15 17:48:11 <[g2]> RobNC, you're running the debian kernel ? Apr 15 17:48:27 I saw some wikis about FatSlug before Apex supported changing sdram-init, and even then they had problems with >64MB. Apr 15 17:48:37 that was with apex as 1st stage BL. Apr 15 17:49:00 <[g2]> I'm running 128MB on several of my units Apr 15 17:49:19 <[g2]> I've had some issue with 256MB, but I've never taken the time to see if it's hw or sw Apr 15 17:49:21 hmm, ever run "memtest 128m 1"? Apr 15 17:49:33 <[g2]> my 128MB units are fine Apr 15 17:49:36 It worked fine with my 256MiB slug Apr 15 17:49:54 <[g2]> I've been using one as my internet gateway for like 8 months Apr 15 17:49:56 I even tried 192m and that worked fine too (so 2nd bangk is fine) Apr 15 17:50:15 <[g2]> so 192 works ? Apr 15 17:50:26 yes Apr 15 17:50:32 I tried 250MB and that fails Apr 15 17:51:01 don't quite know the sweet spot as it takes nearly 2 hrs to run the memtest Apr 15 17:51:02 <[g2]> right that's because you are running from memory and overwrite yourself Apr 15 17:51:40 it shouldn't do that as malloc would complain right? Apr 15 17:52:06 <[g2]> malloc is virtual memory right ? Apr 15 17:52:19 <[g2]> you're trying to test the physical memory I hope :) Apr 15 17:52:58 yes, true... no good way to do a memtest from a boot loader. Was gonna try (per rwhitby suggestion) slugosle running from flash, then do ipkg install memtester Apr 15 17:53:44 <[g2]> I think memtest from APEX (or Redboot) are different Apr 15 17:53:59 there isn't a memtest from those boot loaders, right? Apr 15 17:55:01 <[g2]> I haven't played with boot loaders for a long time Apr 15 17:55:22 <[g2]> I think the memtest code is really small and could be compiled as a ECOS app Apr 15 17:55:31 <[g2]> and just loaded via redboot Apr 15 17:55:42 <[g2]> or as a straight elf file Apr 15 17:55:57 <[g2]> RobNC, you near Raleigh right ? Apr 15 17:56:03 <[g2]> you are Apr 15 17:56:03 really? how would the parameters be sent? Apr 15 17:56:13 [g2] affirmative Apr 15 17:56:51 <[g2]> what are you using for your JTAG device ? Apr 15 17:57:29 I mean, memtest takes some parameters, first being mem size, 2nd being number of iterations. default is 2^32-1 so that would take, hmm, LONG time w/o the trailing "1" :-) Apr 15 17:57:46 [g2] using parallel-port with openwince tools Apr 15 17:59:43 have done a recover of bad flash with JTAG so I know it works ;-) Apr 15 18:02:04 <[g2]> RobNC, did you do the soldering of the ram on the board ? Apr 15 18:03:56 [g2] yep, with microscope and metcal. no solder bridges :-) Apr 15 18:05:19 <[g2]> RobNC, do you do much smt stuff ? Apr 15 18:06:10 yeah, more than I want. been soldering since I was like 7 or 8. Apr 15 18:06:50 <[g2]> well that could be like 8-10 years :) Apr 15 18:06:56 <[g2]> or like 40 :) Apr 15 18:08:09 hahaha!! yeah true... but there isn't a solder problem, or I would see all kinds of problems when using rsync. Apr 15 18:08:34 <[g2]> RobNC, so what do you want to use the fatslug for ? Apr 15 18:08:53 I only have problems when it reaches the limit in resident RAM. I have a log file I'm gonna post to linux-arm-kernel when I get approval Apr 15 18:09:19 for me, just NFS backup from linux server. rsync is a memory hog so 32M not enuf Apr 15 18:10:05 <[g2]> well hope about a deal :) Apr 15 18:10:14 <[g2]> well how about a deal :) Apr 15 18:11:13 <[g2]> I've got a 256MB Loft that I think boots and runs fine @128MB Apr 15 18:11:43 heh I also replaced flash (put 8M back)... I have a few 16m flashes but they're hard to get nowadays b/c $work uses 256Mib now Apr 15 18:11:52 <[g2]> it's a 533Mhz IXP425 with USB 2.0, dual ethernets, JTAG, Serial, POE, GPIOs temp/voltage sensor and 3 minipci slots Apr 15 18:12:09 <[g2]> oh CF and 16MB NOR flash Apr 15 18:12:48 wow thats cool. seems like it has stuff that nslu2 didn't wire out (i.e., dual eth and extra GPIO) Apr 15 18:13:01 RobNC: got flash samples from spansion btw. Unfortunately, they sent me the wrong kind. 64-pin BGA, which is completely useless for me ::P Apr 15 18:13:05 IXP425 has AES, but not sure if kernel uses it Apr 15 18:13:05 <[g2]> yeah I had custom hardware built :) Apr 15 18:13:15 <[g2]> It's been run Apr 15 18:13:24 <[g2]> I think dwery has played with it Apr 15 18:13:29 <[g2]> he's got a unit too Apr 15 18:13:47 <[g2]> that's how most of the kernel drivers stuff went upstream Apr 15 18:13:55 <[g2]> and I think nearly everything is upstream now Apr 15 18:14:03 <[g2]> as of .21 Apr 15 18:14:05 spansion... the ones I replaced with NSLU2 were identical intel versions Apr 15 18:14:10 wow that is cool! Apr 15 18:14:25 similar hardware structure to NSLU2 luckily? Apr 15 18:14:34 RobNC: For my bricked turbostation, not for the nslu2 ;) Apr 15 18:14:57 <[g2]> RobNC, you can load kernels from the CF Apr 15 18:15:14 <[g2]> load -r -v -b 0x... -m disk hda1:/zImage Apr 15 18:15:21 <[g2]> or hda1:/boot/zImage Apr 15 18:15:26 NAiL: oh that stinks. BGA flash is commonplace these days for high-density Apr 15 18:15:41 <[g2]> where that's a symlink in a ext3 fs on flash Apr 15 18:15:45 [g2] that makes it significantly easier, but I thought CF has to have IDE interface Apr 15 18:15:54 <[g2]> it reads ext2 and fat Apr 15 18:16:05 <[g2]> it is an IDE interface :) Apr 15 18:16:21 RobNC: looks like it. The norwegian distributor doesn't have the kind of flash that I need, and distributors in other countries just point me toward the norwegian one. Apr 15 18:16:27 <[g2]> anyway I'll trade you a unit for a some soldering work :) Apr 15 18:16:32 [g2] so there must be some kind of shim that loads memory<=> ide i/f Apr 15 18:16:46 um, sure! good deal! Apr 15 18:16:59 <[g2]> RobNC, no the CF is in IDE mode on the expansion bus Apr 15 18:17:12 NAiL: too bad u can't get samples from Intel :-) Apr 15 18:17:15 <[g2]> it has interrupts, but no DMA Apr 15 18:17:42 <[g2]> RobNC, I've all the RedBoot source and have built/flashed Redboot for the box Apr 15 18:17:44 [g2] oh okay so PIO only. Do you know if NSLU2 uses PIO for USB-PCI bridge? Apr 15 18:17:48 RobNC: Any idea where it would be possible to get compatible samples? Apr 15 18:18:12 that would explain why IXP420 is so slow (and why "usb-storage" peaks when I do rsync) Apr 15 18:18:21 <[g2]> RobNC, it's got USB 2.0 via a Philips chips the NSLU2 has a NEC chip Apr 15 18:18:32 <[g2]> it does about 14MBs to disk Apr 15 18:18:38 NAiL: you could also try STMicro - they sell flash I think and might be able to get you samples. Apr 15 18:18:40 <[g2]> and you can run dual ethers Apr 15 18:19:01 [g2] that's MByte/sec - faster than ethernet! sweet... Apr 15 18:19:09 I mean 100Mbps Apr 15 18:19:19 <[g2]> RobNC, right that tops out at 11MBs ish Apr 15 18:19:55 <[g2]> are you super far from South Point mall ? Apr 15 18:19:56 [g2] yes exactly... about 96Mbps line rate. Apr 15 18:20:15 <[g2]> well there's ethernet and tcp/ip overhead and interframe gaps etc.... Apr 15 18:20:26 <[g2]> reallly 11.1/11.2 is about tops Apr 15 18:20:50 <[g2]> you can scp to the box at around 2.0MBs Apr 15 18:20:53 [g2] prolly best to go off-record for that info Apr 15 18:21:02 <[g2]> sure Apr 15 18:21:22 [g2] seems that rsync over ssh is always slower than NFS. Apr 15 18:21:50 <[g2]> yeah that's do to the CPU issue with the computations Apr 15 18:22:20 <[g2]> it'd be mildly interesting to see what aes encryption enabled in the kernel would do to change that Apr 15 18:22:49 [g2] true - since it's encrypted tunnel. from 2GHz laptop to 2GHz P4, I only get about 3-4MB/sec max. Apr 15 18:23:25 <[g2]> you're laptop isn't setup right Apr 15 18:23:40 you can get slightly better speen by using less intensive cipher Apr 15 18:23:43 <[g2]> My 1.6G cererly get 10MBs Apr 15 18:24:08 <[g2]> on my GigE network I often do 25-30MBs between boxes Apr 15 18:24:17 hmm Apr 15 18:24:20 I dunno how Apr 15 18:24:43 <[g2]> scp Apr 15 18:24:45 I can barely do 14MB/s between pentium-M 1.7 and core duo 2.0 Apr 15 18:24:48 jacques: yeah that is true; I'm using 1024-bit 10min regen. so I'm sure that's something of the reason Apr 15 18:25:45 <[g2]> I don't know what the default scp algo is Apr 15 18:26:10 jacques: or for my uses, I just use NFS and be done :-) Apr 15 18:26:36 only ssh via WAN anyway, so LAN is fine. Apr 15 18:26:40 sam as ssh Apr 15 18:26:41 <[g2]> NFS is a lot faster for me Apr 15 18:26:55 <[g2]> I get near disk rates over nfs Apr 15 18:27:17 <[g2]> I can xfer a 1GB in around 30secs Apr 15 18:27:29 [g2] exactly... nfs seems a lot quicker. Only thing that is quicker is ssh if you're going to do "rsync -c" for crc-generation Apr 15 18:27:43 and there aren't many file diffs Apr 15 18:28:03 otherwise, nfs has to generate crc over network (slower than generating it locally) Apr 15 18:28:05 <[g2]> RobNC, I'm guessing you've got a usb disk hanging off the slugs for backup Apr 15 18:28:43 yep, pair of them; rsync to main, then every other hour rsync between the disks Apr 15 18:28:54 poor-man's raid Apr 15 18:28:54 <[g2]> the ixp425 has md5 and sha1 in hw too :) Apr 15 18:29:04 <[g2]> actually, I think that's the way to go Apr 15 18:29:58 g2 oh cool so 425 would be faster for CRC/MD5/etc/ Apr 15 18:30:59 RobNC: hmm... I don't think I can find an identical part at st Apr 15 18:31:45 <[g2]> RobNC, exactly I think if the hw was used, you might wind up being disk bound Apr 15 18:33:12 g2 that would always be better to be disk bound. Only thing is when I do rsync, it seems that rsync gets about 60% CPU, and 20-30% goes to usb-storage, so must be because PIO mode to PCI=>USB bridge Apr 15 18:33:34 NAiL: oh that stinks. Do you need 64Mb part? Apr 15 18:33:52 128mbit Apr 15 18:33:54 16mb Apr 15 18:35:01 NAiL: oh for FatFlash SLUG :-) Apr 15 18:35:17 no, for repairing the turbostation ;) Apr 15 18:35:39 NAiL: oh! gotcha... Apr 15 18:37:00 is it 56-pin TSOP, intel flash? Apr 15 18:37:24 http://www.spansion.com/products/S29GL128N.html Apr 15 18:37:30 56-pin TSOP alright Apr 15 18:37:53 <[g2]> RobNC, are you sending something to rwhitby ? Apr 15 18:39:01 [g2] not yet, gotta get it modified. sitting at work awaiting 1) ppl not bugging me at work, 2) free time from my normal job (which is already at 190%). :-) Apr 15 18:40:06 NAiL: do you work for a company that uses those flash parts, you might be able to weasel your way into getting samples for a "work project" :-) Apr 15 18:40:41 unfortunately, no. Not even close Apr 15 18:41:19 maybe you could convince them you're doing it for a school project? Apr 15 18:44:01 is an intel part compatible? does it use AMD or Intel style? Apr 15 18:44:15 (meant to preface NAiL) Apr 15 18:45:56 Bank # 1: CFI conformant FLASH (8 x 8) Size: 16 MB in 128 Sectors AMD Standard command set, Manufacturer ID: 0x01, Device ID: 0x7E2101 Apr 15 18:47:02 NAiL: do you have an AMD compatible part number? Apr 15 18:48:12 Uhm, dunno? Apr 15 18:48:22 Spansion S29GL128N11TF101; 0508ABA H Apr 15 19:14:19 NAiL: now with the fixed libtool, the existing OE lighttpd package works properly on 3.10-beta Apr 15 19:14:58 it wouldn't suprise me if a lot of the OE packages that were previously messed up on 3.10-beta will now work properly Apr 15 19:15:49 hey guys so with slugimage I can replace kernel, etc. but why is debian (with apex) ramdisk.gz so much larger than with slugosle? Apr 15 19:15:57 of couree it depends on libpcre which also works properly Apr 15 19:42:38 for build meisters - what would be the process to build apex with slugosle? i.e., "make APEX-CONFIG=slugosle apex"? Apr 15 20:21:51 anyone know what iWMMXt is and if IXP420 supports it? Apr 15 20:31:42 bash-3.2# ipkg -force-downgrade install dovecot_1.0.0-12_armeb.ipk Apr 15 20:31:42 Installing dovecot (1.0.rc15-10) to root... Apr 15 20:32:03 Why doesn't he install the requested version? Apr 15 20:44:01 03marceln * r5936 10optware/trunk/ (make/dovecot.mk sources/dovecot/configure.in.patch): Dovecot: Upstream update to 1.0.0 Apr 15 20:45:00 mwester: Do you know how to handle ipkg versions? Apr 15 20:47:34 anyone know where NEC USB driver is located in "USB support" part of make menuconfig? Apr 15 20:52:57 03marceln * r5937 10optware/trunk/make/dovecot.mk: dovecot: Correction build wl500g Apr 15 21:15:23 RobNC: ramdisk.gz on SlugOS is a dummy 128Kb partition to get around a redboot requirement Apr 15 21:15:58 apex for slugosle - just use slugos config (default) and ENDIAN=l (default too) Apr 15 21:18:59 rwhitby: thanks... trying compile of kernel right now, with (forget the parameter but it is what you recommended earlier in regards to PCI transactions). Apr 15 21:19:13 RobNC: upslug2 can't flash just the kernel when you're using apex as second stage. it will overwrite apex thinking that's where the kernel is. slugimage is the way to go with apex as second stage. Apr 15 21:19:57 shoot... kernel too big. looks like I need a default .config for NSLU2 to start out with (versus one for ARM which mostly might not apply) Apr 15 21:20:27 rwhitby: I *thought* upslug2 couldn't do it, because it doesn't know about apex being in the place of the kernel Apr 15 21:20:28 also, you use the ixp4xxle kernel you build, not the nslu2le one (cause that one has the arm-kernel-shim which will override your atags from apex like mem size) Apr 15 21:21:00 apex has support for loading kernels > 1MiB Apr 15 21:21:06 gotcha, good info - need to document that! Apr 15 21:21:29 debian kernel doesn't need the shim, cause it uses apex as second stage Apr 15 21:23:02 I am trying to do the 2.6.21 kernel build. Got my working (but crashes) fatslug build. Can I replace vmlinuz from slugosle to my (debian) fatslug image w/o also replacing ramdisk.gz? I suspect it's not that easy. Apr 15 21:23:59 (I mean for, like, using slugimage) Apr 15 21:26:40 RobNC: use our svn kernel repo for the kernel build Apr 15 21:27:21 (the same one you are using to build apex) Apr 15 21:27:48 BTW, I don't recommend INDIRECT_PCI - I don't think we have a kernel config problem. Apr 15 21:28:04 you should reproduce it with our default kernel config in the svn kernel repo Apr 15 21:28:18 rwhitby: yes that was what I was trying to get compiled. - indirect PCI Apr 15 21:28:42 indirect PCI is a red herring I think Apr 15 21:29:06 this is true... seems like a DMA problem not a PCI problem Apr 15 21:29:08 (i.e. I wouldn't report to l-a-k with that set) Apr 15 21:29:37 it might be worth a try with it set, just for laughs, but don't expect it to do anything, and don't send in a problem report mentioning it. Apr 15 21:30:07 ok, still haven't gotten subscription email yet anyway (so can't post anything anyway) Apr 15 21:30:42 ok, no hurry - the problem has been there for a number of years it seems, so one more day won't hurt :-) Apr 15 21:30:53 once I've svn co Apr 15 21:31:07 once I've svn co 'ed the kernel, what next :-) Apr 15 21:31:39 I thought I would "make slugosle" but that doesn't use apex as 2nd stage. need to compile image that uses slugosle and apex Apr 15 21:32:10 rwhitby: Do you know how to handle ipkg versions? Apr 15 21:32:34 marceln: Quite possibly broken ipkg Apr 15 21:32:43 what version of ipkg are you using? Apr 15 21:32:46 marceln: I believe downgrade is completely broken and I have no way to fix it other than remove your feeds before doing a local install Apr 15 21:32:57 ipkg version 0.99.154 Apr 15 21:33:16 I don't want to downgrade!! Apr 15 21:33:38 what is the problem then? Apr 15 21:33:49 I installed version 1.0.0-12 which should be higher as 1.0.rc15-10 Apr 15 21:33:57 aha Apr 15 21:34:24 But it refused to install the local 1.0.0-12 and choose to install the 1.0.rc15-10 from the repository. Apr 15 21:34:44 quite probably because rc15 > 0 Apr 15 21:34:49 I have uploaded the files for 1.0.0-12 but probably we get the same problems there. Apr 15 21:35:02 that isn't in itself an ipkg problem Apr 15 21:35:13 Not really. Apr 15 21:35:27 Just broken version numbers. Apr 15 21:35:31 yeah Apr 15 21:36:34 And the package version is less important as the version of the source. Apr 15 21:37:49 But on the other side it's normal to have a version postfix with rc. Apr 15 21:38:19 A "rc" version should be lower than any other version with the same version number. Apr 15 21:38:20 RobNC: svn up in /home/slug/kernel Apr 15 21:38:27 rwhitby: I can't simply replace vmlinuz from custom slugosle into 8MB debianimage b/c rootfs is not in flash, right? Want to test apex-1.4.18 but using slugosle so I can do tests w/o USBHDD's attached and fsck'ed. Apr 15 21:38:32 RobNC: then "make kernel" will build the latest kernel Apr 15 21:38:34 rwhitby: did that. Apr 15 21:39:05 actually, it's probably easiest just to build slugosle from the master makefile and reproduce with that. Apr 15 21:39:22 don't I need to "cd ~/kernel; make APEX_CONFIG=slugosle kernel" or equivalent? Apr 15 21:39:24 (i.e. use 2.6.20 from OE, not from kernel svn) Apr 15 21:39:33 no, apex_config is only for apex Apr 15 21:39:56 ok, so oe is BE then, but hopefully memtester avail via ipkg Apr 15 21:39:57 if you want to use 2.6.21-rcX, you'll also need to get the corresponding kernel modules into the rootfs somehow Apr 15 21:40:08 ah yes that was my issue! Apr 15 21:40:08 OE can build slugosbe and slugosle Apr 15 21:40:37 bbiab Apr 15 21:40:55 ok, thanks, building Apr 15 21:42:34 marceln: It would quite probably work if it was called 1.0.0-rc15-10, Apr 15 21:42:54 build slugosle, then unpack the resulting image, and put apex back in as loader. you don't use the dummy ramdisk.gz if using apex as second stage loader Apr 15 21:43:35 NAiL: the approved versioning scheme is 0.9+1.0.0-rc15 Apr 15 21:43:46 (or whatever the previous version was first) Apr 15 21:44:23 NAiL: The version name is a upstream convention. Apr 15 21:44:52 I can't help that they choose 1.0.rc15 Apr 15 21:44:55 marceln: yes, but you need to put the stuff before the + so that versioning works. Apr 15 21:45:33 OK: It's a lesson for next time. Apr 15 21:45:33 part of packaging is fixing upstream version non-monotonicly-increasing. Apr 15 21:45:52 How do we fix it? Apr 15 21:47:14 you can change the version number in the optware .mk file Apr 15 21:48:32 rwhitby: ok thanks. ramdisk.gz is 3M from DebianSlug 8M image, whereas its only 131k from "make slugosle". Does that mean the 3MB file (ramdisk) from DebianSlugImage (D-I), which uses Apex, is just junk? (I'm confused!) Apr 15 21:48:47 RobNC: no Apr 15 21:49:07 RedBoot requires a header field at the normal Linksys ramdisk location in flash. Apr 15 21:49:17 Apex knows about that (now) and works around it. Apr 15 21:49:46 when using RedBoot, you need to have the header field in the right place. that means a dummy ramdisk.gz, since you can't put a header field at the start of a jffs2 partition. Apr 15 21:50:12 (this is what the apex skip region stuff is for) Apr 15 21:50:50 ok, thanks. it'll sink in eventually! :-) Apr 15 21:51:34 it's all crap we need to do to work around the linksys/sercomm redboot hacks Apr 15 21:52:22 RobNC: BTW, didn't we do this before (get slugos booting on your fatslug with apex as second stage)? Apr 15 21:52:33 you downloaded a snapshot from hentges.net Apr 15 21:54:52 (sorry had network hiccup) Apr 15 21:54:57 RobNC: I can get you a slugosle image quickly now if you like ... Apr 15 21:56:09 yes, we did that before, but it didn't boot anything b/c it couldn't find rootfs Apr 15 21:58:45 I.e., I didn't have a live linux filesystem from which to ipkg "memtester", or run "memtest" Apr 15 21:59:35 RobNC: try the one I just /msg'd you Apr 15 22:00:11 you don't need to swap the kernel - just unpack and put in apex Apr 15 22:00:51 ok, that has the 2.6.20 from OE? Apr 15 22:01:24 yes Apr 15 22:01:47 ok thanks, brb gonna slugimage Apr 15 22:02:03 I'll do it at the same time to replicate results. Apr 15 22:02:37 great! Apr 15 22:04:38 slugimage -u -i slugosle-4.4-beta-nslu2.bin Apr 15 22:04:54 slugimage -p -o slugos-apex.bin -L apex-slugos-nslu2-arm-1.4.18.bin -k vmlinuz -r Flashdisk:Flashdisk Apr 15 22:05:34 I'm flashing that now Apr 15 22:05:50 gotta see how much space is left. Apr 15 22:06:08 oh, hang on, need to use the ixp4xxle kernel for that too. Apr 15 22:06:44 RobNC: do you still have a vmlinuz-ixp4xx-2.6.20-arm kernel around? Apr 15 22:07:16 if not, change PATCHVER to 2.6.20 in /home/slug/kernel/Makefile and build it. Apr 15 22:07:56 ah, no, that won't work. Apr 15 22:08:03 you need to get the ixp4xx kernel from OE Apr 15 22:08:08 rwhitby: checking.... I think I did a clean of the entire slugosle but looks like I have Apr 15 22:08:28 no looks like I need to build that too Apr 15 22:08:36 I can upload one, hang on. Apr 15 22:09:05 whew thanks... amateur at work here! Apr 15 22:09:30 same site as before, but filename zImage-ixp4xxle Apr 15 22:10:46 then use that instead of vmlinuz in the command above Apr 15 22:11:35 ok trying now Apr 15 22:11:38 flashing that now Apr 15 22:12:13 the original nslu2 kernel in the 8MB image would have ignored your atags from apex Apr 15 22:12:23 (since it uses the shim to be able to work with redboot) Apr 15 22:12:59 ah that makes sense, since it's made to be run from redboot not apex Apr 15 22:17:28 rwhitby: doing "make APEX_CONFIG=slugos apex" - I blew it away to have a clean env Apr 15 22:17:32 done Apr 15 22:17:50 the repacked image booted, and has 1692 blocks free Apr 15 22:17:57 installing memtester now Apr 15 22:18:01 ok cool, I'll be there soon Apr 15 22:18:23 still 1692 blocks free after installing memtester :-) Apr 15 22:19:00 memtester runs Apr 15 22:19:22 I'll have breakfast while you catch up Apr 15 22:19:34 heh while I have dinner :-) Apr 15 22:30:49 RobNC: where you up to? Apr 15 22:31:10 ipkg update; ipkg install memtester Apr 15 22:31:11 just completed Apr 15 22:32:03 this memtester looks and acts different than the debian version Apr 15 22:32:04 ok, do you know how to turnup when you want to test with rootfs on disk? Apr 15 22:32:25 oh, so it's a different memtester? Apr 15 22:32:51 wow same thing happened - nothing attached to USB... memtester 256m crashed Apr 15 22:33:18 turnup - it has been a very long time (prolly 6 months or so). Apr 15 22:33:24 oh, memtester 32MB crashed here too Apr 15 22:33:47 oom-killer Apr 15 22:33:47 yes, for debian, I "apt-get install memtester" but the program was called memtest Apr 15 22:33:54 and had different arguments. Apr 15 22:34:21 ah shoot I gotta change apex boot params. free only shows 30MB Apr 15 22:34:31 nod Apr 15 22:38:26 RobNC: slugos seems to have the latest memtester from http://pyropus.ca/software/memtester/ Apr 15 22:38:36 what version was the debian one? Apr 15 22:38:43 grr seems to not recognize mem. Apr 15 22:39:23 lemme see Apr 15 22:39:43 memtest v. 2.93.1 Apr 15 22:39:53 aha, a different package altogether Apr 15 22:40:00 (C) 2000 Charles Cazabon Apr 15 22:40:01 Original v.1 (C) 1999 Simon Kirby Apr 15 22:40:54 I guess one is as good as the other for our purposes ... Apr 15 22:41:06 ok, gotta get ready for work now - back in about an hour. Apr 15 22:41:19 you're good to go from here, right? Apr 15 22:41:20 kernel isn't getting the mem from apex Apr 15 22:41:50 ok yeah it's okay - do what we can. thanks! (gotta do some family stuff) Apr 15 22:42:35 RobNC: you used the zImage-ixp4xxle kernel I pointed you to? Apr 15 22:42:48 yep. lemme check Apr 15 22:43:18 DOH sorry my bad... I'm losing it. Lemme re-try doing this correctly this ime. Apr 15 22:43:43 kernel should report rwhitby@take is the builder if it's the correct one Apr 15 22:43:55 ok thanks! Apr 15 22:43:58 slug@nudi is the OE one Apr 15 22:56:32 rwhitby: dang, same thing - mem not detected even after "sdram-init; memscan 0+256m; " prepended to startup env var. Apr 15 22:59:09 bbiab (35 mins) Apr 15 22:59:16 ok thks Apr 15 23:02:24 hillct: I forgot to close the bug? Apr 15 23:02:46 so it would seem Apr 15 23:02:49 "setenv cmdline root=/dev/mtdblock4; rootfstype=jffs2 console=ttyS0,115200 mem=256M@0x0" from Apex makes it detect 256MiB (slugosle). Apr 15 23:03:11 then again, I never assigned it to you so it would have been easy to miss Apr 15 23:04:30 NAiL: incidently, the fix to libtool last week has made it possible to build the OE packages of libpcre and lighttpd on 3.10-beta Apr 15 23:04:43 I've been testing it all day and they look solid Apr 15 23:05:54 not crazy about the nonstandard positioning of log files and the document root but I'm sure the person who created the initial package had a good reason. perhaps it's required for a different platform Apr 15 23:06:08 ok, I'll commit them to packages when I get a devbox up again Apr 15 23:06:34 up again? what happened? your box blew up? Apr 15 23:06:40 almost :P Apr 15 23:06:50 my watercooled devbox sprung a leak Apr 15 23:07:09 it works and stuff, but I need to get a replacement fan and fastening stuff Apr 15 23:07:14 You haven't lived until a power supply catches fire in the bottom 3Us of a cabinet Apr 15 23:07:32 uuuuh, I don't think I want to live :P Apr 15 23:07:55 what's what I said when I got the phone call from the security staff Apr 15 23:12:02 nice Apr 15 23:12:10 I'm off then. Nite all Apr 15 23:29:55 RobNC: so you have slugosle memtester running in 256MiB ? Apr 15 23:37:23 a while back there was discussion of getting slugos going inside quemu. Did anyone ever get that going? Apr 15 23:47:47 rwhitby: I just use 256MB as the parameter and then it tells you "requesting XXX memory, testing with YYY memory" Apr 15 23:48:11 how much does it get? Apr 15 23:48:19 hillct: not that I know of Apr 15 23:49:08 preparing a pastebin - gimme a sec Apr 15 23:51:18 (sorry had phone call - work-related) Apr 15 23:52:08 np Apr 15 23:52:24 http://pastebin,ca/442020 Apr 15 23:53:20 memtest 240M seemed to start fine. Then I tried memtest 245M - it said "want 245MB, got 244MB" Apr 15 23:53:39 the our favorite "oom-killer" after "mlock" Apr 15 23:59:26 rwhitby: apex param change - needed appendage to cmdline of " mem=256M@0x0" - to have the 256MB be passed to linux kernel. Apr 15 23:59:53 hmm - weird. Apr 16 00:00:33 is apex passing the correct atags? Apr 16 00:00:38 (it prints them out) Apr 16 00:01:07 yeah but network is still working.. I can ping, etc and things still work. Now, to turnup, get USB drive, etc. and verify that after that "crash", the USB dev on PCI is no longer accessible. Apr 16 00:01:37 ok, I'll be busy for a while now (at work) - keep me informed here and I'll look between meetings. Apr 16 00:01:47 ok, thanks! have fun :-) Apr 16 00:03:46 RobNC: don't you need to run memlimit to set the atags properly? Apr 16 00:03:54 the atags being passed in your pastebin are only for 32mb Apr 16 00:04:02 you shouldn't need the mem= on the cmdline Apr 16 00:04:29 rwhitby: with D-I, I didn't see that it make a difference. I'll try it though. Apr 16 00:05:22 unless you run memlimit in apex, I don't think it will change the atags from 32mb Apr 16 00:05:38 I don't think memscan does what you think it does Apr 16 00:05:53 you should run sdram-init, then memlimit Apr 16 00:06:08 memscan just looks for aliases, it doesn't change the boot params. Apr 16 00:06:08 no need for memscan? Apr 16 00:06:18 I don't think so. Apr 16 00:06:20 ok gotcha. Apr 16 00:06:26 will try and let you know. Apr 16 00:06:34 ok, bbiab Apr 16 00:21:40 fyi, rwhitby, 256MB only detected if cmdline parameter appended. "memscan" didn't do it (I had right params). Apr 16 01:19:57 hmm Apr 16 01:21:08 note that same params for Apex ->debian image didn't work (using just sdram-init and memscan, without memlimit). *dumb looks* Apr 16 01:21:31 what atags are passed when you use memlimit? Apr 16 01:22:43 lemme look - will have to reboot Apr 16 01:26:57 u mean ATAT_MEM I presume - it is "ATAG_MEM: start 0x00000000 size 0x02000000" Apr 16 01:27:36 that is with "sdram-init; memlimit 256m; etc.. " other startup params Apr 16 01:28:57 weird, seems that is the same as when 256MB is detected?! Apr 16 01:29:26 so it seems that kernel ignores ATAG_MEM and only looks at ATAG_CMDLINE for "mem=256MB@0x0" Apr 16 01:30:48 ATAG_MEM 2000000 is only 32MB, right? Apr 16 01:31:08 you need to get apex to send 0x10000000 for 256MB, no? Apr 16 01:31:09 yep. 256MB would be 0x10000000 Apr 16 01:31:42 bbiab Apr 16 01:32:08 ok thks Apr 16 01:32:40 just work out which apex commands get the atags right, and then the kernel should see it Apr 16 01:46:27 gonna re-flash old debian image to compare atags Apr 16 01:51:14 AH I think I see the problem. need "memscan -u 0+256m" -> -u passes to kernel Apr 16 01:56:16 yup that was it. memscan -u 0+256m => no need to meminit Apr 16 01:59:36 ATAG_MEM shows 0x10000000 Apr 16 02:18:28 rwhitby: ok reproduced problem via rsync of >200GB data - USB mounts die and aren't accessible, but kernel doesn't die (i.e., ramfs still functional). **** ENDING LOGGING AT Mon Apr 16 02:59:57 2007