[00:58] <CIA-18> nbd * r3938 /branches/buildroot-ng/openwrt/target/linux/image/aruba/Makefile: fix aruba ramdisk check for the image building
[00:59] <CIA-18> nbd * r3939 /branches/buildroot-ng/openwrt/target/linux/aruba-2.6/Config.in: remove aruba specific ramdisk option
[01:05] <CIA-18> nbd * r3940 /branches/buildroot-ng/openwrt/target/linux/image/aruba/Makefile: update aruba image building makefile for latest image.mk changes
[01:19] <CIA-18> mbm * r3941 /branches/buildroot-ng/openwrt/target/linux/image/aruba/Makefile: fix annoying make parse error
[01:25] <CIA-18> nbd * r3942 /branches/buildroot-ng/openwrt/target/linux/image/aruba/Makefile: hopefully the last fix for the aruba image stuff
[01:33] <CIA-18> nbd * r3943 /branches/buildroot-ng/openwrt/ (5 files in 5 dirs): remove libgcc hack
[01:42] <h3sp4wn> nbd: http://pastebin.com/707616 (It doesn't seem to be working properly - thats part of the output from dmesg that concerns the usb)
[01:42] <nbd> hmm
[01:42] <nbd> thanks
[01:42] <nbd> i'll check the code
[01:53] <nbd> h3sp4wn: can you try without ehci?
[01:54] <h3sp4wn> If I remove the symlink from /etc/modules.d/60-usb2 and reboot then that should be ok ?
[01:55] <nbd> yes
[01:55] <h3sp4wn> I will give you the results in about 5 mins
[01:55] <nbd> thx
[02:12] <h3sp4wn> nbd: SQUASHFS error: Can't find a SQUASHFS superblock on sd(8,1) is the only error I get now but it seems to be working
[02:12] <nbd> o
[02:12] <nbd> ok
[02:12] <nbd> then
[02:12] <h3sp4wn> Should I have only being loading the usb2 modules and not the usb1 ones as well
[02:12] <nbd> argh... stupid keyboard
[02:13] <nbd> i will make a fixed usb2 module
[02:14] <h3sp4wn> find . doesn't seem to crash it (but it never did with usb 1)
[02:16] <nbd> building a new usb2 module now
[02:19] <h3sp4wn> Will I need to reinstall all the usb-modules or just the kernel module in question - should I have 60-usb-uhci removed from /etc/modprobe.d if I am trying to use usb2 ?
[02:19] <nbd> no
[02:19] <nbd> just install the new package
[02:20] <nbd> if you have enough flash space
[02:20] <nbd> just usb2
[02:20] <h3sp4wn> I do (now removed some of the junk I never use)
[02:20] <nbd> http://downloads.openwrt.org/people/nbd//whiterussian/packages/kmod-usb2_2.4.30-brcm-3_mipsel.ipk
[02:26] <h3sp4wn> nbd: http://pastebin.com/707661 - still looks like the same problem
[02:32] <nbd> can you try the old usb2 module package?
[02:32] <nbd> (leaving the other ones at the new version)
[02:34] <h3sp4wn> Get that from the normal download site ?
[02:34] <nbd> yes
[02:34] <nbd> i need some sleep now
[02:34] <nbd> will try to fix the rest tomorrow
[02:35] <h3sp4wn> http://downloads.openwrt.org/whiterussian/rc5/packages/kmod-usb2_2.4.30-brcm-3_mipsel.ipk
[02:35] <nbd> yes
[02:35] <nbd> that's the one
[02:37] <h3sp4wn> Would I need to reboot for it to take effect I just insmod'ed it and got http://pastebin.com/707679
[02:42] <nbd> was that after the previous oops?
[02:43] <h3sp4wn> That was after rebooting with just usb1 and then insmoding the usb2 module
[02:43] <nbd> hmm
[02:44] <nbd> ok. i give up for today
[02:44] <nbd> i will do some experiments on my own tomorrow
[06:52] <neilwpuls> I have a question
[07:21] <[mbm]> ...
[07:21] <[mbm]> if you have a question ask it
[07:21] <[mbm]> don't annonce you have a question and then leave
[07:23] <z3ro> [mbm]: yeah, that annoys me too.
[07:25] <[mbm]> some people just don't grasp the true nature of irc
[07:26] <[mbm]> yes it's an instant message medium, but no that doesn't mean that my replies are going to be less than 30 seconds
[07:26] <[mbm]> nor does the fact I'm online mean I'm actually around
[07:26] <[mbm]> I'm online 24x7
[07:27] <z3ro> yeah. I always leave irssi running, even when I'm not watching it.
[07:28] <z3ro> although I'm probably online less than 24/7, because of my unreliable dsl. :p
[07:29] <[mbm]> heh, I cheat, I use a screen session
[07:29] <[mbm]> so I'm logged in from my shell on openwrt.org and then I just ssh/screen from any computer I happen to be at
[07:30] <z3ro> I'd get too slow speeds if I did that. I use screen locally, though.
[07:31] <[mbm]> I do fine unless the site is being hammered by a spider or I'm downloading stuff off bit torrent
[07:31] <[mbm]> so if things ever start to lag while I'm online, I'll know about the problem immediately
[07:32] <z3ro> haha. good problem detection system. ;p
[07:33] <[mbm]> the even better thing is that if the site goes down, I'll be off irc and won't have to deal with the "is the site down?" questions ;)
[07:33] <z3ro> hehe
[10:11] <nbd> [mbm]: about the devfs/udev debate: maybe it would make sense for us to strip down devfs to the essential stuff and then use a stripped down udev on it
[10:23] <Kaloz> nbd: udev needs /dev/null, /dev/zero and /dev/console at all iirc
[11:28] <malbon> kaloz: that root didn't like the consolidated board format. :( I didn't see any eth devices at all.
[13:07] <malbon> RoDent: did you sort your multi-ssid problem?
[18:27] <[mbm]> http://kerneltrap.org/node/6723
[18:43] <nbd> i think we should have window scaling enabled
[18:44] <[mbm]> iirc it was enabled by default; the thread is about the new window scaling calculations that set the window size too large for some hosts
[18:45] <[mbm]> net.ipv4.tcp_window_scaling = 1
[18:46] <[mbm]> yep, already on
[18:51] <[mbm]> btw, thinking of changing the io scheduler to deadline on all boards
[18:55] <nbd> makes sense
[20:27] <nbd> xrg_: ping
[20:27] <xrg_> pong!
[20:28] <nbd> i fixed the resource allocation bug on the rb532
[20:28] <xrg_> really?
[20:28] <nbd> http://downloads.openwrt.org/people/nbd/tmp/res_fix.patch
[20:28] <xrg_> :)
[20:28] <nbd> turns out that the pci bridge only allows an address room of 0x1000 for the io ports
[20:29] <nbd> but there's a workaround in the kernel that aligns all the ioport resources to 0x400 to fix some weird vga ioport issue on some devices
[20:30] <xrg_> I'll apply that in blind!
[20:30] <nbd> wait
[20:30] <nbd> sebastian just said it doesn't fix the issue for him
[20:30] <nbd> need to do some more testing to see if one of my older hacks had an impact as well
[20:30] <nbd> or if it's just a crapout in his build system (again)
[20:31] <xrg_> so, is that patch needed?
[20:31] <nbd> definitely
[20:32] <xrg_> Then, it is clear enough to be applied as is.
[20:41] <xrg_> Applied.
[20:41] <nbd> that patch is definitely enough to fix the issue
[20:41] <nbd> i just recompiled with a clean kernel tree and this small patch
[20:42] <xrg_> You see, I may not have any time at all to work for rb532 (I make no money out of it), but such patches are no problem. I just apply them in 2min..
[20:43] <xrg_> And then we all keep in sync with our code.
[21:25] <nbd> xrg_: i'll give you my current patchset in a minute
[21:25] <nbd> it contains lots of changes
[21:25] <nbd> but now the patches are all broken out
[21:26] <nbd> [mbm]: btw. the initcall1 fix that we keep duplicating... does it break any non-mips arch?
[21:29] <crazy_imp> nbd: mips or mipsel? (i updated my kamikaze buildroot for ~1h i think and building atm for mipsel)
[21:31] <nbd> crazy_imp: mips or mipsel what?
[21:33] <crazy_imp> nbd: "the initcall1fix" from your last message
[21:33] <nbd> well, to the kernel mips and mipsel is the same
[21:34] <crazy_imp> hm, i thought i couldn't run mips progs onto a mipsel, so the mips understand mipsel?
[21:35] <florian__> crazy_imp: mips processors usually can run in big/little endian modes
[21:35] <florian__> depending on the value of the endiannes register
[21:36] <crazy_imp> ok, thx :)
[21:37] <florian__> but once the processor is running in a little/big endian mode, it cannot execute big (respectively little) endian code
[21:38] <nbd> xrg_: here they are ... http://downloads.openwrt.org/people/nbd/rb532/
[21:41] <xrg_> ack.
[21:42] <nbd> the code seems to be very solid now
[21:42] <nbd> and it has been cleaned up a lot
[22:03] <[mbm]> nbd: re. what initcall1 patch? you mean the j entrypoint?
[22:07] <nbd> typo, i meant early_initcall
[22:07] <nbd> +#define early_initcall(fn) __define_initcall(".early1",fn)
[22:09] <[mbm]> I don't think we're using that patch anymore
[22:10] <[mbm]> artifact of a kernel transition
[22:11] <nbd> ah, ok
[22:11] <nbd> i'll try removing it from the routerboard patches
[22:11] <[mbm]> I can't seem to find any code referencing "early_initcall" or "early1"
[22:11] <nbd> ok
[22:12] <xrg_> yeah, I didn't use it either.
[22:12] <[mbm]> but basically there were a few elf section headers that the kernel would look for
[22:12] <[mbm]> and it would execute those
[22:12] <[mbm]> so you could easily hook into early kenrel initializations
[22:12] <nbd> yeah
[22:13] <[mbm]> if you tried to use it now all you'd get is an extra elf header
[22:13] <[mbm]> so while I don't question that it should be removed, it also isn't adding much overhead
[22:14] <[mbm]> something else to consider is changing the initrd stuff back to ramdisk images
[22:15] <nbd> yeah
[22:15] <[mbm]> and have lzma actually pass the initrd location to the kernel
[22:15] <nbd> is it possible to set up a ram disk from a fixed memory location and with a fixed memory size?
[22:16] <[mbm]> should be
[22:16] <[mbm]> I'd just be tempted to compile the ramdisk image into the lzma loader, uncompressed
[22:16] <[mbm]> and then pass that address to the kernel
[22:17] <nbd> how should we pass it to the kernel?
[22:17] <[mbm]> the kernel is responsible for relocating the ramdisk image
[22:17] Action: xrg_ is back
[22:17] Action: xrg_ is away: working
[22:17] Action: [mbm] doesn't care about xrg
[22:17] <nbd> autoaway messages always make me feel like kicking someone
[22:17] <[mbm]> nbd: happens in pretty much the same way that kernel commandlines get passed
[22:18] <[mbm]> (feel free to kick)
[22:18] <nbd> nah
[22:18] <nbd> not the first time
[22:18] <nbd> xrg_: when you're back, turn that autoaway thingie off :)
[22:21] <macsat> Do any of you guys know whatever linksysinfo.org refers to when writing this about the new Sveasoft Talisman ".....apparently Sveasoft has found a more open driver courtesy of Asus to help get these working..." ?
[22:21] <[mbm]> I don't put much trust in what linksysinfo says
[22:23] <macsat> :-)
[22:23] Action: xrg_ is back
[22:23] <xrg_> ok, sorry, won't use it again..
[22:23] <macsat> So you dont believe that the "he" have multiple SSID's running for real ?
[22:24] <[mbm]> xrg: rule of thumb is that if you haven't said anything in the last 5 minutes we really don't care if you're here or not
[22:24] <[mbm]> macsat: no, I didn't say that; I know that multiple ssids can be done
[22:24] <macsat> ok - I just had the impression that it couldnt using the binaries currently in use :)
[22:25] <[mbm]> what I'm saying is that linksysinfo lacks any sort of journalistic integrity
[22:25] <CIA-18> nbd * r3944 /branches/buildroot-ng/openwrt/target/linux/ (2 files in 2 dirs): remove early_initcall hacks
[22:25] <macsat> yeah....you dont have to tell me m8
[22:26] <[mbm]> so while sveasoft may have just perfected cold fusion, I won't believe it until I see actual implementation details
[22:26] <nbd> i know that they have somewhat working code using it
[22:26] <nbd> sveasoft still claims they can do 16 essids
[22:26] <nbd> but i know for sure that the driver is limited to 4
[22:26] <macsat> I've had a few ..hmm.....experiences......with James.
[22:26] <nbd> me too :)
[22:27] <[mbm]> most people do
[22:27] <macsat> :-)
[22:27] <[mbm]> and I have yet to hear anything plesent about them
[22:28] <macsat> If I you really WANT to find something positive to say, then it is nice that someone tried to make a real business from OpenSource / GPL - just a shame he has such a hard time "undestanding" the licence....
[22:28] <[mbm]> at any rate, he's running it like a buisness, overhyping the buzzwords while keeping the actual details a trade secret
[22:29] <macsat> I wonder how long its gonna take before "Freeman 1.2" is out....would be nice to give it a test-run to see if it really does handle 16 SSIDS :)
[22:29] <nbd> and he always hypes himself by acting like he wrote all the code himself
[22:29] <[mbm]> well, for some people gpl/oss just means cheap labor
[22:29] <macsat> yeah nbd...and mbm...such a shame it is...
[22:30] <nbd> macsat: well, i don't really care. just ignore him
[22:30] <macsat> I really dont appriciate people that dosnt give ppl that worked hard their due credits...
[22:30] <[mbm]> I make a living off of writing opensource code, but not directly
[22:30] <macsat> I do ignore him m8 - my incidents where a couple of years back.
[22:31] <macsat> nice mbm....I have some income doing OpenSource stuff as well - but not my main source of income.
[22:38] <malbon> TheRoDent: ping
[22:57] <TheRoDent> No joy yet.
[23:04] <malbon> TheRoDent: hmm, shame.
[23:13] <CIA-18> mbm * r3945 /branches/buildroot-ng/openwrt/target/linux/ (5 files in 5 dirs): switch io schedular to deadline
[23:15] <crazy_imp> nbd: the ticket 272 says that dma support is broken, so does it choose the pio mode itself or does the hdd doesn't working in the wl-hdd(2.5) with kamikaze?
[23:16] <nbd> i haven't tried it with kamikaze, but with whiterussian it just crashes as soon as you try to enable it with hdparm
[23:16] <nbd> regular operation works
[23:18] <crazy_imp> hm, if i remember myself right mine was using dma, 6mbyte/s copy files internal on the disk. but now i kamikaze i only habe an empty ide folder with no device but the modules are loaded
[23:19] <crazy_imp> in / under kamikaze
[23:19] <[mbm]> the last person complaining of an empty folder on a usb disk had formatted his disk as ext2 and then had corrupted it by several unclean mounts
[23:21] <crazy_imp> mbm: i doesn't get the device, i was thinking about /dev/ide/ <- its empty
[23:45] <nbd> [mbm]: btw. i have an idea on how to make the jffs2 root thing easier
[23:45] <[mbm]> ok, btw I just spotted a bug with the switch /proc handling
[23:46] <nbd> [mbm]: what if we changed the jffs2 driver to detect an appended 'magic value' that tells it that the filesystem is fresh
[23:46] <nbd> [mbm]: then jffs2 can just take care of erasing all the old blocks
[23:46] <nbd> [mbm]: and it'll make things a lot easier on non-broadcom platforms
[23:46] <[mbm]> I'm not following
[23:47] <nbd> what if we just appended 0xdeadbeef to the jffs2 image
[23:47] <nbd> after flashing, jffs2 goes through all the blocks
[23:47] Action: [mbm] points at http://pastebin.com/709507 .. note the switch bug
[23:47] <nbd> and if it detects the 'poison' it erases it and all following blocks
[23:49] <nbd> i'll have a look at that bug later
[23:49] <nbd> looks trivial
[23:49] <[mbm]> yeah it does .. bad pointer or a missing nul
[23:49] <nbd> do you see what i mean with the jffs2 stuff?
[23:50] <crazy_imp> hm, i can't load the pdc202xx_old module, it says no such device (i think it's the last missing module to get it working or?)
[23:50] <[mbm]> still don't see where you're going with this jffs2 stuff -- what problem are you trying to solve?
[23:51] <nbd> when we're flashing a jffs2 root filesystem, we either need to manually make sure that all old blocks are erased
[23:51] <nbd> or we need a way of detecting the reflash so that scripts can take care of it
[23:51] <nbd> on the broadcom stuff we detect it through some properties of the trx header
[23:51] <nbd> and on other platforms we have to erase the old blocks manually
[23:52] <nbd> i think we should have a solution that works on all platforms
[23:52] <nbd> and that's what i'm suggesting here
[23:52] <[mbm]> well, we do that to avoid corruption of a truncated jffs2 partition
[23:52] <nbd> exactly
[23:52] <nbd> and my solution would avoid this corruption in a platform independent way
[23:52] <nbd> if we mark the end of the filesystem, the kernel knows what to erase
[23:52] <[mbm]> but I don't see how adding header to signal 'valid jffs2 node' is supposed to help
[23:52] <nbd> not a header
[23:52] <nbd> a trailer for the filesystem
[23:53] <nbd> that effectively says 'no valid jffs2 blocks after this point'
[23:54] <[mbm]> ok, and you want to stuff that into the firmware image so that it gets written to the start of the jffs2 partition?
[23:54] <nbd> it doesn't matter how we organize the firmware image
[23:54] <nbd> as long as this data gets appended to the regular jffs2 data
[23:55] Action: [mbm] gets lost in the abstraction and generalizations
[23:55] <nbd> the kernel just sets up the jffs2 partition as it normally would
[23:55] <nbd> i'll try to explain differently
[23:55] <nbd> when jffs2 starts mounting the filesystem
[23:56] <nbd> it goes through all the blocks until it either hits the end of the partition or our 'filesystem end' marker
[23:56] <nbd> if it finds that this arbitrary sequence of bytes to mark the end of the filesystem is present
[23:56] <nbd> it assumes that the jffs2 has just been reflashed and that there are no valid jffs2 nodes after this byte sequence
[23:57] <nbd> so it erases everything after that
[23:57] <[mbm]> wait, would the end of the partition be where jffs2 hits nvram?
[23:57] <nbd> the end of the partition is already correctly marked by the mtd subsystem
[23:57] <nbd> so there's no way it'll hit nvram
[23:57] <[mbm]> right
[23:57] <nbd> my change is local to the jffs2 filesystem
[23:57] <[mbm]> but still
[23:58] <nbd> jffs2 does this can anyway
[23:58] <nbd> this scan
[23:58] <nbd> so we can just hook into it and tell it to ignore all junk blocks
[23:59] <[mbm]> also, if I understand correctly jffs2 doesn't have any superblock structure, each erase block is basically a filesystem fragment with no start or end to the filesystem
[23:59] <nbd> yes
[00:00] --- Thu Jun 15 2006
[00:59] <CIA-18> nbd * r3939 /branches/buildroot-ng/openwrt/target/linux/aruba-2.6/Config.in: remove aruba specific ramdisk option
[01:05] <CIA-18> nbd * r3940 /branches/buildroot-ng/openwrt/target/linux/image/aruba/Makefile: update aruba image building makefile for latest image.mk changes
[01:19] <CIA-18> mbm * r3941 /branches/buildroot-ng/openwrt/target/linux/image/aruba/Makefile: fix annoying make parse error
[01:25] <CIA-18> nbd * r3942 /branches/buildroot-ng/openwrt/target/linux/image/aruba/Makefile: hopefully the last fix for the aruba image stuff
[01:33] <CIA-18> nbd * r3943 /branches/buildroot-ng/openwrt/ (5 files in 5 dirs): remove libgcc hack
[01:42] <h3sp4wn> nbd: http://pastebin.com/707616 (It doesn't seem to be working properly - thats part of the output from dmesg that concerns the usb)
[01:42] <nbd> hmm
[01:42] <nbd> thanks
[01:42] <nbd> i'll check the code
[01:53] <nbd> h3sp4wn: can you try without ehci?
[01:54] <h3sp4wn> If I remove the symlink from /etc/modules.d/60-usb2 and reboot then that should be ok ?
[01:55] <nbd> yes
[01:55] <h3sp4wn> I will give you the results in about 5 mins
[01:55] <nbd> thx
[02:12] <h3sp4wn> nbd: SQUASHFS error: Can't find a SQUASHFS superblock on sd(8,1) is the only error I get now but it seems to be working
[02:12] <nbd> o
[02:12] <nbd> ok
[02:12] <nbd> then
[02:12] <h3sp4wn> Should I have only being loading the usb2 modules and not the usb1 ones as well
[02:12] <nbd> argh... stupid keyboard
[02:13] <nbd> i will make a fixed usb2 module
[02:14] <h3sp4wn> find . doesn't seem to crash it (but it never did with usb 1)
[02:16] <nbd> building a new usb2 module now
[02:19] <h3sp4wn> Will I need to reinstall all the usb-modules or just the kernel module in question - should I have 60-usb-uhci removed from /etc/modprobe.d if I am trying to use usb2 ?
[02:19] <nbd> no
[02:19] <nbd> just install the new package
[02:20] <nbd> if you have enough flash space
[02:20] <nbd> just usb2
[02:20] <h3sp4wn> I do (now removed some of the junk I never use)
[02:20] <nbd> http://downloads.openwrt.org/people/nbd//whiterussian/packages/kmod-usb2_2.4.30-brcm-3_mipsel.ipk
[02:26] <h3sp4wn> nbd: http://pastebin.com/707661 - still looks like the same problem
[02:32] <nbd> can you try the old usb2 module package?
[02:32] <nbd> (leaving the other ones at the new version)
[02:34] <h3sp4wn> Get that from the normal download site ?
[02:34] <nbd> yes
[02:34] <nbd> i need some sleep now
[02:34] <nbd> will try to fix the rest tomorrow
[02:35] <h3sp4wn> http://downloads.openwrt.org/whiterussian/rc5/packages/kmod-usb2_2.4.30-brcm-3_mipsel.ipk
[02:35] <nbd> yes
[02:35] <nbd> that's the one
[02:37] <h3sp4wn> Would I need to reboot for it to take effect I just insmod'ed it and got http://pastebin.com/707679
[02:42] <nbd> was that after the previous oops?
[02:43] <h3sp4wn> That was after rebooting with just usb1 and then insmoding the usb2 module
[02:43] <nbd> hmm
[02:44] <nbd> ok. i give up for today
[02:44] <nbd> i will do some experiments on my own tomorrow
[06:52] <neilwpuls> I have a question
[07:21] <[mbm]> ...
[07:21] <[mbm]> if you have a question ask it
[07:21] <[mbm]> don't annonce you have a question and then leave
[07:23] <z3ro> [mbm]: yeah, that annoys me too.
[07:25] <[mbm]> some people just don't grasp the true nature of irc
[07:26] <[mbm]> yes it's an instant message medium, but no that doesn't mean that my replies are going to be less than 30 seconds
[07:26] <[mbm]> nor does the fact I'm online mean I'm actually around
[07:26] <[mbm]> I'm online 24x7
[07:27] <z3ro> yeah. I always leave irssi running, even when I'm not watching it.
[07:28] <z3ro> although I'm probably online less than 24/7, because of my unreliable dsl. :p
[07:29] <[mbm]> heh, I cheat, I use a screen session
[07:29] <[mbm]> so I'm logged in from my shell on openwrt.org and then I just ssh/screen from any computer I happen to be at
[07:30] <z3ro> I'd get too slow speeds if I did that. I use screen locally, though.
[07:31] <[mbm]> I do fine unless the site is being hammered by a spider or I'm downloading stuff off bit torrent
[07:31] <[mbm]> so if things ever start to lag while I'm online, I'll know about the problem immediately
[07:32] <z3ro> haha. good problem detection system. ;p
[07:33] <[mbm]> the even better thing is that if the site goes down, I'll be off irc and won't have to deal with the "is the site down?" questions ;)
[07:33] <z3ro> hehe
[10:11] <nbd> [mbm]: about the devfs/udev debate: maybe it would make sense for us to strip down devfs to the essential stuff and then use a stripped down udev on it
[10:23] <Kaloz> nbd: udev needs /dev/null, /dev/zero and /dev/console at all iirc
[11:28] <malbon> kaloz: that root didn't like the consolidated board format. :( I didn't see any eth devices at all.
[13:07] <malbon> RoDent: did you sort your multi-ssid problem?
[18:27] <[mbm]> http://kerneltrap.org/node/6723
[18:43] <nbd> i think we should have window scaling enabled
[18:44] <[mbm]> iirc it was enabled by default; the thread is about the new window scaling calculations that set the window size too large for some hosts
[18:45] <[mbm]> net.ipv4.tcp_window_scaling = 1
[18:46] <[mbm]> yep, already on
[18:51] <[mbm]> btw, thinking of changing the io scheduler to deadline on all boards
[18:55] <nbd> makes sense
[20:27] <nbd> xrg_: ping
[20:27] <xrg_> pong!
[20:28] <nbd> i fixed the resource allocation bug on the rb532
[20:28] <xrg_> really?
[20:28] <nbd> http://downloads.openwrt.org/people/nbd/tmp/res_fix.patch
[20:28] <xrg_> :)
[20:28] <nbd> turns out that the pci bridge only allows an address room of 0x1000 for the io ports
[20:29] <nbd> but there's a workaround in the kernel that aligns all the ioport resources to 0x400 to fix some weird vga ioport issue on some devices
[20:30] <xrg_> I'll apply that in blind!
[20:30] <nbd> wait
[20:30] <nbd> sebastian just said it doesn't fix the issue for him
[20:30] <nbd> need to do some more testing to see if one of my older hacks had an impact as well
[20:30] <nbd> or if it's just a crapout in his build system (again)
[20:31] <xrg_> so, is that patch needed?
[20:31] <nbd> definitely
[20:32] <xrg_> Then, it is clear enough to be applied as is.
[20:41] <xrg_> Applied.
[20:41] <nbd> that patch is definitely enough to fix the issue
[20:41] <nbd> i just recompiled with a clean kernel tree and this small patch
[20:42] <xrg_> You see, I may not have any time at all to work for rb532 (I make no money out of it), but such patches are no problem. I just apply them in 2min..
[20:43] <xrg_> And then we all keep in sync with our code.
[21:25] <nbd> xrg_: i'll give you my current patchset in a minute
[21:25] <nbd> it contains lots of changes
[21:25] <nbd> but now the patches are all broken out
[21:26] <nbd> [mbm]: btw. the initcall1 fix that we keep duplicating... does it break any non-mips arch?
[21:29] <crazy_imp> nbd: mips or mipsel? (i updated my kamikaze buildroot for ~1h i think and building atm for mipsel)
[21:31] <nbd> crazy_imp: mips or mipsel what?
[21:33] <crazy_imp> nbd: "the initcall1fix" from your last message
[21:33] <nbd> well, to the kernel mips and mipsel is the same
[21:34] <crazy_imp> hm, i thought i couldn't run mips progs onto a mipsel, so the mips understand mipsel?
[21:35] <florian__> crazy_imp: mips processors usually can run in big/little endian modes
[21:35] <florian__> depending on the value of the endiannes register
[21:36] <crazy_imp> ok, thx :)
[21:37] <florian__> but once the processor is running in a little/big endian mode, it cannot execute big (respectively little) endian code
[21:38] <nbd> xrg_: here they are ... http://downloads.openwrt.org/people/nbd/rb532/
[21:41] <xrg_> ack.
[21:42] <nbd> the code seems to be very solid now
[21:42] <nbd> and it has been cleaned up a lot
[22:03] <[mbm]> nbd: re. what initcall1 patch? you mean the j entrypoint?
[22:07] <nbd> typo, i meant early_initcall
[22:07] <nbd> +#define early_initcall(fn) __define_initcall(".early1",fn)
[22:09] <[mbm]> I don't think we're using that patch anymore
[22:10] <[mbm]> artifact of a kernel transition
[22:11] <nbd> ah, ok
[22:11] <nbd> i'll try removing it from the routerboard patches
[22:11] <[mbm]> I can't seem to find any code referencing "early_initcall" or "early1"
[22:11] <nbd> ok
[22:12] <xrg_> yeah, I didn't use it either.
[22:12] <[mbm]> but basically there were a few elf section headers that the kernel would look for
[22:12] <[mbm]> and it would execute those
[22:12] <[mbm]> so you could easily hook into early kenrel initializations
[22:12] <nbd> yeah
[22:13] <[mbm]> if you tried to use it now all you'd get is an extra elf header
[22:13] <[mbm]> so while I don't question that it should be removed, it also isn't adding much overhead
[22:14] <[mbm]> something else to consider is changing the initrd stuff back to ramdisk images
[22:15] <nbd> yeah
[22:15] <[mbm]> and have lzma actually pass the initrd location to the kernel
[22:15] <nbd> is it possible to set up a ram disk from a fixed memory location and with a fixed memory size?
[22:16] <[mbm]> should be
[22:16] <[mbm]> I'd just be tempted to compile the ramdisk image into the lzma loader, uncompressed
[22:16] <[mbm]> and then pass that address to the kernel
[22:17] <nbd> how should we pass it to the kernel?
[22:17] <[mbm]> the kernel is responsible for relocating the ramdisk image
[22:17] Action: xrg_ is back
[22:17] Action: xrg_ is away: working
[22:17] Action: [mbm] doesn't care about xrg
[22:17] <nbd> autoaway messages always make me feel like kicking someone
[22:17] <[mbm]> nbd: happens in pretty much the same way that kernel commandlines get passed
[22:18] <[mbm]> (feel free to kick)
[22:18] <nbd> nah
[22:18] <nbd> not the first time
[22:18] <nbd> xrg_: when you're back, turn that autoaway thingie off :)
[22:21] <macsat> Do any of you guys know whatever linksysinfo.org refers to when writing this about the new Sveasoft Talisman ".....apparently Sveasoft has found a more open driver courtesy of Asus to help get these working..." ?
[22:21] <[mbm]> I don't put much trust in what linksysinfo says
[22:23] <macsat> :-)
[22:23] Action: xrg_ is back
[22:23] <xrg_> ok, sorry, won't use it again..
[22:23] <macsat> So you dont believe that the "he" have multiple SSID's running for real ?
[22:24] <[mbm]> xrg: rule of thumb is that if you haven't said anything in the last 5 minutes we really don't care if you're here or not
[22:24] <[mbm]> macsat: no, I didn't say that; I know that multiple ssids can be done
[22:24] <macsat> ok - I just had the impression that it couldnt using the binaries currently in use :)
[22:25] <[mbm]> what I'm saying is that linksysinfo lacks any sort of journalistic integrity
[22:25] <CIA-18> nbd * r3944 /branches/buildroot-ng/openwrt/target/linux/ (2 files in 2 dirs): remove early_initcall hacks
[22:25] <macsat> yeah....you dont have to tell me m8
[22:26] <[mbm]> so while sveasoft may have just perfected cold fusion, I won't believe it until I see actual implementation details
[22:26] <nbd> i know that they have somewhat working code using it
[22:26] <nbd> sveasoft still claims they can do 16 essids
[22:26] <nbd> but i know for sure that the driver is limited to 4
[22:26] <macsat> I've had a few ..hmm.....experiences......with James.
[22:26] <nbd> me too :)
[22:27] <[mbm]> most people do
[22:27] <macsat> :-)
[22:27] <[mbm]> and I have yet to hear anything plesent about them
[22:28] <macsat> If I you really WANT to find something positive to say, then it is nice that someone tried to make a real business from OpenSource / GPL - just a shame he has such a hard time "undestanding" the licence....
[22:28] <[mbm]> at any rate, he's running it like a buisness, overhyping the buzzwords while keeping the actual details a trade secret
[22:29] <macsat> I wonder how long its gonna take before "Freeman 1.2" is out....would be nice to give it a test-run to see if it really does handle 16 SSIDS :)
[22:29] <nbd> and he always hypes himself by acting like he wrote all the code himself
[22:29] <[mbm]> well, for some people gpl/oss just means cheap labor
[22:29] <macsat> yeah nbd...and mbm...such a shame it is...
[22:30] <nbd> macsat: well, i don't really care. just ignore him
[22:30] <macsat> I really dont appriciate people that dosnt give ppl that worked hard their due credits...
[22:30] <[mbm]> I make a living off of writing opensource code, but not directly
[22:30] <macsat> I do ignore him m8 - my incidents where a couple of years back.
[22:31] <macsat> nice mbm....I have some income doing OpenSource stuff as well - but not my main source of income.
[22:38] <malbon> TheRoDent: ping
[22:57] <TheRoDent> No joy yet.
[23:04] <malbon> TheRoDent: hmm, shame.
[23:13] <CIA-18> mbm * r3945 /branches/buildroot-ng/openwrt/target/linux/ (5 files in 5 dirs): switch io schedular to deadline
[23:15] <crazy_imp> nbd: the ticket 272 says that dma support is broken, so does it choose the pio mode itself or does the hdd doesn't working in the wl-hdd(2.5) with kamikaze?
[23:16] <nbd> i haven't tried it with kamikaze, but with whiterussian it just crashes as soon as you try to enable it with hdparm
[23:16] <nbd> regular operation works
[23:18] <crazy_imp> hm, if i remember myself right mine was using dma, 6mbyte/s copy files internal on the disk. but now i kamikaze i only habe an empty ide folder with no device but the modules are loaded
[23:19] <crazy_imp> in / under kamikaze
[23:19] <[mbm]> the last person complaining of an empty folder on a usb disk had formatted his disk as ext2 and then had corrupted it by several unclean mounts
[23:21] <crazy_imp> mbm: i doesn't get the device, i was thinking about /dev/ide/ <- its empty
[23:45] <nbd> [mbm]: btw. i have an idea on how to make the jffs2 root thing easier
[23:45] <[mbm]> ok, btw I just spotted a bug with the switch /proc handling
[23:46] <nbd> [mbm]: what if we changed the jffs2 driver to detect an appended 'magic value' that tells it that the filesystem is fresh
[23:46] <nbd> [mbm]: then jffs2 can just take care of erasing all the old blocks
[23:46] <nbd> [mbm]: and it'll make things a lot easier on non-broadcom platforms
[23:46] <[mbm]> I'm not following
[23:47] <nbd> what if we just appended 0xdeadbeef to the jffs2 image
[23:47] <nbd> after flashing, jffs2 goes through all the blocks
[23:47] Action: [mbm] points at http://pastebin.com/709507 .. note the switch bug
[23:47] <nbd> and if it detects the 'poison' it erases it and all following blocks
[23:49] <nbd> i'll have a look at that bug later
[23:49] <nbd> looks trivial
[23:49] <[mbm]> yeah it does .. bad pointer or a missing nul
[23:49] <nbd> do you see what i mean with the jffs2 stuff?
[23:50] <crazy_imp> hm, i can't load the pdc202xx_old module, it says no such device (i think it's the last missing module to get it working or?)
[23:50] <[mbm]> still don't see where you're going with this jffs2 stuff -- what problem are you trying to solve?
[23:51] <nbd> when we're flashing a jffs2 root filesystem, we either need to manually make sure that all old blocks are erased
[23:51] <nbd> or we need a way of detecting the reflash so that scripts can take care of it
[23:51] <nbd> on the broadcom stuff we detect it through some properties of the trx header
[23:51] <nbd> and on other platforms we have to erase the old blocks manually
[23:52] <nbd> i think we should have a solution that works on all platforms
[23:52] <nbd> and that's what i'm suggesting here
[23:52] <[mbm]> well, we do that to avoid corruption of a truncated jffs2 partition
[23:52] <nbd> exactly
[23:52] <nbd> and my solution would avoid this corruption in a platform independent way
[23:52] <nbd> if we mark the end of the filesystem, the kernel knows what to erase
[23:52] <[mbm]> but I don't see how adding header to signal 'valid jffs2 node' is supposed to help
[23:52] <nbd> not a header
[23:52] <nbd> a trailer for the filesystem
[23:53] <nbd> that effectively says 'no valid jffs2 blocks after this point'
[23:54] <[mbm]> ok, and you want to stuff that into the firmware image so that it gets written to the start of the jffs2 partition?
[23:54] <nbd> it doesn't matter how we organize the firmware image
[23:54] <nbd> as long as this data gets appended to the regular jffs2 data
[23:55] Action: [mbm] gets lost in the abstraction and generalizations
[23:55] <nbd> the kernel just sets up the jffs2 partition as it normally would
[23:55] <nbd> i'll try to explain differently
[23:55] <nbd> when jffs2 starts mounting the filesystem
[23:56] <nbd> it goes through all the blocks until it either hits the end of the partition or our 'filesystem end' marker
[23:56] <nbd> if it finds that this arbitrary sequence of bytes to mark the end of the filesystem is present
[23:56] <nbd> it assumes that the jffs2 has just been reflashed and that there are no valid jffs2 nodes after this byte sequence
[23:57] <nbd> so it erases everything after that
[23:57] <[mbm]> wait, would the end of the partition be where jffs2 hits nvram?
[23:57] <nbd> the end of the partition is already correctly marked by the mtd subsystem
[23:57] <nbd> so there's no way it'll hit nvram
[23:57] <[mbm]> right
[23:57] <nbd> my change is local to the jffs2 filesystem
[23:57] <[mbm]> but still
[23:58] <nbd> jffs2 does this can anyway
[23:58] <nbd> this scan
[23:58] <nbd> so we can just hook into it and tell it to ignore all junk blocks
[23:59] <[mbm]> also, if I understand correctly jffs2 doesn't have any superblock structure, each erase block is basically a filesystem fragment with no start or end to the filesystem
[23:59] <nbd> yes
[00:00] --- Thu Jun 15 2006