**** BEGIN LOGGING AT Fri Oct 19 03:00:01 2012
Oct 19 03:29:11 <Weedy_lappy> nbd: I get this constantly cp: cannot overwrite non-directory '/home/weedy/projects/openwrt/staging_dir/toolchain-mips_r2_gcc-4.6-linaro_uClibc-0.9.33.2/./mips-openwrt-linux-uclibc/lib' with directory '/home/weedy/projects/openwrt/staging_dir/toolchain-mips_r2_gcc-4.6-linaro_uClibc-0.9.33.2/initial/./mips-openwrt-linux-uclibc/lib'
Oct 19 03:29:59 <Weedy_lappy> nbd: but then I can nuke staging_dir/toolchain-<whatever arch> and it will build fine
Oct 19 03:30:28 <Weedy_lappy> seems to happen more with -jsomething
Oct 19 05:28:31 <dangole> Weedy_lappy: ack. I also run into this lately
Oct 19 09:52:34 <rkreis> se
Oct 19 09:52:49 <rkreis> oops (and a curse at pidgin for stealing focus)
Oct 19 10:18:09 <KanjiMonster> rkreis: at least it wasn't a password ;)
Oct 19 10:19:09 <rkreis> are you sure? :)
Oct 19 10:21:47 <KanjiMonster> (and yes, death to the inventor of focus stealing)
Oct 19 10:22:30 <jow_laptop> swalker: thanks
Oct 19 10:23:11 <rkreis> that reminds me of that one time... when i still used internet explorer, and had pretty good reflexes to close popups as soon as they appear
Oct 19 10:23:37 <RealOpty> LOL :)
Oct 19 10:24:07 <rkreis> it was a big download (100M? took an hour at least), and when it was finally done, ie opened a dialog showing the download being copied from a temp folder to the actual destination folder
Oct 19 10:24:14 <rkreis> it is the same one used in the file manager
Oct 19 10:24:23 <rkreis> now... i clicked the X without really seeing what it was
Oct 19 10:24:41 <rkreis> and for some reason, there was no confirmation or anything, and the download was nowhere to be found
Oct 19 10:24:44 <rkreis> good times
Oct 19 10:25:07 <RealOpty> hehe sounds like windows 98 ol times
Oct 19 10:25:30 <rkreis> must have been
Oct 19 10:32:19 <KanjiMonster> I liked that you could disable focus stealing in earlier windows version (pre vista) through the powertools stuff; unfortunately that won't work anymore in 7 :-/
Oct 19 11:26:06 <nbd> Weedy_lappy: that toolchain error happens occasionally when stuff in toolchain/ changes and only parts of the toolchain are rebuilt
Oct 19 11:26:12 <nbd> Weedy_lappy: i don't think it has anything to do with parallel builds
Oct 19 11:59:29 <vanDrunen> I get a compile error on libgl-mesa, missing dependency for library ibpthread.so.0
Oct 19 12:00:20 <vanDrunen> while libpthread is enabled as module in menuconfig under Base system
Oct 19 12:00:41 <vanDrunen> could this be a problem with the order in which modules are compiled? Or what am I missing?
Oct 19 12:08:38 <RealOpty> vanDrunen: I dont think the repo for that stuff is 'maintained'
Oct 19 12:09:03 <vanDrunen> I am compiling some packages from the Xorg feed
Oct 19 12:09:23 <RealOpty> I know :)
Oct 19 12:09:53 <RealOpty> Its not commonly used, so i dont think anyone updates the packages
Oct 19 12:10:06 <vanDrunen> the problem also occurred on other packages before
Oct 19 12:10:13 <vanDrunen> but I don't know where to look to fix it
Oct 19 12:10:48 <RealOpty> vanDrunen: that in my opinion looks like a typo in the makefile
Oct 19 12:11:31 <vanDrunen> the makefile from libgl-mesa
Oct 19 12:11:35 <RealOpty> libpthread not ibpth...
Oct 19 12:12:24 <vanDrunen> that was my type
Oct 19 12:12:28 <vanDrunen> *typo
Oct 19 12:13:05 <vanDrunen> libgl-mesa is complaining about missing libpthread.so.0, while this package was selected in base system as module
Oct 19 12:13:18 <RealOpty> You sure? i thought i seen something like that before when i was tryin to do that xorg stuff lol
Oct 19 12:14:55 <vanDrunen> literally: "Package libgl-mesa is missing dependencies for the following libraries: libpthread.so.0"
Oct 19 12:15:17 <vanDrunen> this means it can not find libpthread.so.0 which should mean it wasn't compiled yet, right?
Oct 19 12:15:47 <RealOpty> Well in this case, no :/
Oct 19 12:15:56 <vanDrunen> please explain
Oct 19 12:16:17 <RealOpty> Im gonna attempt to. :)
Oct 19 12:16:25 <RealOpty> Are you using trunk?>
Oct 19 12:16:34 <RealOpty> I assume you are
Oct 19 12:16:45 <vanDrunen> attitude_adjustment
Oct 19 12:16:58 <vanDrunen> latest updates though
Oct 19 12:16:59 <RealOpty> Close enough heheh
Oct 19 12:17:02 <vanDrunen> yeah
Oct 19 12:20:36 <vanDrunen> hah…. also the help page of libpthread in menuconfig doesn't show anything… goes back to the console, untill I press enter… must be something wrong in the config
Oct 19 12:20:52 <vanDrunen> and I have no idea from where this option is added
Oct 19 12:22:15 <RealOpty> nope
Oct 19 12:22:28 <RealOpty> mmm gimme a sec
Oct 19 12:23:34 <RealOpty> can u post a build log?
Oct 19 12:23:41 <RealOpty> in pastebin **
Oct 19 12:23:48 <vanDrunen> yeah… one sec.
Oct 19 12:26:21 <RealOpty> vanDrunen: more importantly why are you doing this lol?>
Oct 19 12:27:07 <RealOpty> I can tell you now, there noting exciting in the xorg feed lol
Oct 19 12:27:28 <vanDrunen> pastebin.com/3dkjnLtb
Oct 19 12:28:10 <vanDrunen> I got framebuffer running on a displaylink device and now I need Xorg… it's for a project
Oct 19 12:28:19 <vanDrunen> I am migrating from Voyage to OpenWRT
Oct 19 12:31:28 <vanDrunen> but I have to go now… :-(
Oct 19 12:31:38 <vanDrunen> I'll get back on this tonight
Oct 19 12:32:20 <RealOpty> vanDrunen: k are you following some kinda guide?
Oct 19 12:32:28 <vanDrunen> nope...
Oct 19 12:32:34 <RealOpty> vanDrunen: i dont think its possible unless you can code :/
Oct 19 12:32:41 <vanDrunen> I can code
Oct 19 12:32:49 <vanDrunen> I am new to the buildroot environment
Oct 19 12:32:51 <vanDrunen> that's all
Oct 19 12:33:01 <RealOpty> vanDrunen: all the xorg stuff is outta date.
Oct 19 12:33:02 <RealOpty> https://dev.openwrt.org/browser/feeds/xorg/lib/mesa/Makefile
Oct 19 12:33:12 <RealOpty> hasnt been updated in 3 years bro
Oct 19 12:33:15 <vanDrunen> ok… then I'll have to update it!
Oct 19 12:33:26 <vanDrunen> more work for me… yay!
Oct 19 12:33:33 <vanDrunen> it's ok… gotta run
Oct 19 12:33:36 <vanDrunen> bye
Oct 19 12:33:39 <RealOpty> peace
Oct 19 14:09:24 <DonkeyHotei> ping nbd
Oct 19 14:09:31 <nbd> DonkeyHotei: pong
Oct 19 14:09:42 <DonkeyHotei> nbd: http://paste.openwrt.org/10404
Oct 19 14:11:58 <nbd> that doesn't make sense to me
Oct 19 14:12:42 <DonkeyHotei> there is nothing in the netifd code to signal to the outside world that inits are complete and the uloop has begun
Oct 19 14:12:46 <nbd> what do you mean by "/sbin/wifi is executed before uci knows anything about any interfaces"
Oct 19 14:13:26 <DonkeyHotei> look at /etc/init.d/network
Oct 19 14:14:19 <nbd> ah, ok. so probably something that triggers firmware load makes netifd block for a while
Oct 19 14:14:55 <DonkeyHotei> not sure what that would be, but it shouldn't matter
Oct 19 14:15:46 <DonkeyHotei> the sleep should be replaced with a poll
Oct 19 14:16:15 <DonkeyHotei> problem is, there's nothing to poll
Oct 19 14:16:15 <nbd> i think i have a better idea
Oct 19 14:16:34 <DonkeyHotei> oh?
Oct 19 14:16:37 <jow_laptop> yeah, rewrite the wifi setup ;)
Oct 19 14:16:45 <nbd> change the order of bringup to ensure netifd makes all interfaces appear in ubus before it starts any of them
Oct 19 14:17:22 <DonkeyHotei> that's not a solution
Oct 19 14:17:33 <DonkeyHotei> it's just wishful thinking
Oct 19 14:17:55 <nbd> ?
Oct 19 14:18:46 <DonkeyHotei> it still relies on mere hope that interfaces appear in ubus/uci before the sleep finishes
Oct 19 14:19:00 <DonkeyHotei> no direct trigger
Oct 19 14:19:06 <DonkeyHotei> there needs to be a poll
Oct 19 14:20:18 <DonkeyHotei> to continue the script without blocking is just wrong
Oct 19 14:23:42 <DonkeyHotei> the way wifi is currently initialized simply isn't asynchronous, so the effectively asynchronous inits in netifd are a very creepy crawly bug
Oct 19 14:23:44 <nbd> eventually the wifi shell scripts will go away anyway
Oct 19 14:24:17 <nbd> if the startup order is changed, netifd should be so fast that it should only take a fraction of a second for it to register with ubus
Oct 19 14:24:47 <DonkeyHotei> key word being "should"
Oct 19 14:26:00 <DonkeyHotei> this device takes forever to finish booting, and it doesn't even boot successfully at all unless the wan cable is disconnected beforehand and plugged in after boot is complete
Oct 19 14:26:19 <nbd> and why is that?
Oct 19 14:26:50 <DonkeyHotei> it runs out of ram and oom-killer starts nuking boot processes
Oct 19 14:27:05 <nbd> how much ram does it have?
Oct 19 14:27:10 <DonkeyHotei> 16
Oct 19 14:27:34 <nbd> and what are you doing that eats up so much of it that it runs into OOM?
Oct 19 14:28:02 <DonkeyHotei> no idea, but after a successful boot, there is maybe half a meg free ram
Oct 19 14:28:21 <nbd> show me /proc/meminfo
Oct 19 14:35:40 <DonkeyHotei> nbd: http://paste.openwrt.org/10407
Oct 19 14:36:38 <nbd> 4.8M slab usage is a lot
Oct 19 14:37:19 <DonkeyHotei> that's just after boot finishes, with no wan defined and wifi only half-inited because hostapd wouldn't start due to the netifd race condition
Oct 19 14:41:51 <DonkeyHotei> nbd: this is with wifi disabled: http://paste.openwrt.org/10409
Oct 19 14:47:50 <nbd> is acx-mac80211 loaded?
Oct 19 14:48:06 <DonkeyHotei> in lsmod, you mean?
Oct 19 14:48:11 <nbd> yes
Oct 19 14:48:16 <nbd> if so, try to unload it
Oct 19 14:48:20 <nbd> see how much slab is used then
Oct 19 14:52:06 <DonkeyHotei> before i do that, here is lsmod: http://paste.openwrt.org/10410
Oct 19 14:52:44 <DonkeyHotei> Slab:               4796 kB
Oct 19 14:53:03 <DonkeyHotei> that's after rmmod acx_mac80211
Oct 19 14:53:38 <DonkeyHotei> nbd: ^
Oct 19 14:54:25 <nbd> ok
Oct 19 14:56:51 <nbd> hm, slab usage probably includes all those loaded modules
Oct 19 14:59:02 <nbd> ok, given the amount of stuff you put on this router, i'm really not surprised you're running out of memory
Oct 19 15:00:11 <DonkeyHotei> it's pretty much basics plus ipv6
Oct 19 15:00:52 <nbd> yeah, ipv6 eats quite a bit of memory too
Oct 19 15:00:59 <DonkeyHotei> :(
Oct 19 15:01:56 <DonkeyHotei> i guess i won't be able to use it as my production router after all
Oct 19 15:02:30 <DonkeyHotei> but i can't use the pk5000 either, because we have no driver for the wifi in it
Oct 19 15:02:33 <nbd> are you using the crappy wifi on this thing?
Oct 19 15:02:58 <DonkeyHotei> i am mostly testing at this stage
Oct 19 15:03:19 <nbd> if you leave out wifi from the firmware, that'll save quite a bit of memory
Oct 19 15:03:30 <nbd> acx wifi is crap anyway
Oct 19 15:03:41 <nbd> wouldn't recommend it for a production router
Oct 19 15:03:44 <DonkeyHotei> [florian] just committed a ton of ar7 fixes from me and a couple of his own (which still do not work)
Oct 19 15:04:33 <DonkeyHotei> i'm looking at this router _because_ it has wifi
Oct 19 15:05:08 <DonkeyHotei> otherwise, i'd use the pk5000 with its 32 flash and 64 ram
Oct 19 15:05:57 <nbd> why not just get a tl-mr3020 for wifi or something
Oct 19 15:06:05 <DonkeyHotei> but the pk5000 has the later acx chipset for wifi, for which we have no driver
Oct 19 15:08:35 <DonkeyHotei> how much flash and ram does the tl-mr3020 have?
Oct 19 15:08:54 <nbd> 4M flash, 32M RAM
Oct 19 15:09:45 <DonkeyHotei> which target?
Oct 19 15:09:59 <nbd> ar71xx
Oct 19 15:10:13 <nbd> ar9331 wisoc
Oct 19 15:10:20 <nbd> small device with only one ethernet port
Oct 19 15:11:09 <DonkeyHotei> so the only wan is usb?
Oct 19 15:12:00 <nbd> i meant using it in combination with one of your existing ar7 routers
Oct 19 15:12:28 <DonkeyHotei> as a wifi bridge?
Oct 19 15:12:33 <nbd> yes
Oct 19 15:13:01 <DonkeyHotei> that was what i did with the pk5000 before, using a very awful d-link
Oct 19 15:13:17 <[florian]> DonkeyHotei: do you mind telling me what does not work with the patches that I committed?
Oct 19 15:13:37 <DonkeyHotei> dwl-730ap i think was the model
Oct 19 15:14:19 <DonkeyHotei> [florian]: no fixed phy is registered on the linksys
Oct 19 15:14:43 <[florian]> DonkeyHotei: ok, well I'd appreciate if you provide me with some bootlog so we can debug this
Oct 19 15:14:50 <DonkeyHotei> sorry, it was dwl-g730ap
Oct 19 15:15:33 <DonkeyHotei> [florian]: what happens is that it still puts both cpmac's on mdio
Oct 19 15:15:50 <[florian]> DonkeyHotei: please provide a bootlog
Oct 19 15:38:49 <DonkeyHotei> [florian]: http://paste.openwrt.org/10416
Oct 19 15:41:06 <[florian]> DonkeyHotei: ok so what's actually wrong with this?
Oct 19 15:41:55 <DonkeyHotei> there is no fixed phy, so ethernet doesn't work, since we have no driver for the ADM6996L
Oct 19 15:42:37 <[florian]> not, that's orthogonal
Oct 19 15:42:43 <[florian]> you can have working ethernet without a switch driver
Oct 19 15:42:57 <[florian]> but you can't have cpmac send packets to the oustide world it if "sees" no link
Oct 19 15:43:18 <[florian]> which is the purpose of the fixed phy driver, to fake the link so that the cpmac driver and networking stack will still send packets and receive them
Oct 19 15:43:18 <DonkeyHotei> it worked back when there was only fixed phy
Oct 19 15:43:31 <[florian]> ok, then it's the same issue that I am chasing
Oct 19 15:43:43 <[florian]> I got a device out there having such a switch, but it does not get picked up by the driver
Oct 19 15:44:03 <[florian]> chaing ADM_SIG0 to be 0x1022 makes it pick up the ADM6996 phy driver
Oct 19 15:44:31 <DonkeyHotei> but that's the ADM6996M, not ADM6996L
Oct 19 15:44:44 <[florian]> oh, well, then we must use a fixed phy
Oct 19 15:44:53 <[florian]> and use kmod-switch with the proper gpio binding
Oct 19 15:45:20 <[florian]> my linksys wag54g2 has this configuration and works ok with trunk
Oct 19 15:45:27 <[florian]> that's actually the reason for my patch in the first place
Oct 19 15:45:44 <DonkeyHotei> on your wag54g, it does not see a phy
Oct 19 15:45:51 <DonkeyHotei> on mine, it does
Oct 19 15:46:29 <[florian]> ok, the do two things, first make the cpmac driver print the actual phy driver it picked up
Oct 19 15:46:42 <DonkeyHotei> it can't know that
Oct 19 15:46:57 <[florian]> it does know, because it is bound to a specific PHY driver
Oct 19 15:47:09 <DonkeyHotei> the phy driver is picked up by mdio
Oct 19 15:47:55 <[florian]> make it print phy->drv->name
Oct 19 15:48:06 <[florian]> that's the driver name, right after the call to phy_connect()
Oct 19 15:54:55 <DonkeyHotei> it says Generic PHY
Oct 19 16:07:42 <DonkeyHotei> [florian]: and second?
Oct 19 16:32:34 <DonkeyHotei> nbd: anyway, how soon can the netifd startup order be changed?
Oct 19 16:37:46 <[florian]> DonkeyHotei: second thing you can check, is what is the reported adm6996 signature
Oct 19 16:38:33 <DonkeyHotei> reported where?
Oct 19 16:38:53 <DonkeyHotei> it's not on the mdio bus at all
Oct 19 16:39:40 <DonkeyHotei> iirc it's zero or something
Oct 19 16:46:45 <[florian]> on my board the adm6996 signature is off-by-one (0x1022) instead of 0x1023
Oct 19 16:48:04 <DonkeyHotei> but that's the ADM6996M, not ADM6996L
Oct 19 17:08:47 <DonkeyHotei> [florian]: ideas?
Oct 19 17:13:22 <[florian]> DonkeyHotei: no idea about the L variant, you could still try to make it print its signature and see why it is not being matched
Oct 19 17:13:37 <DonkeyHotei> signature is zero iirc
Oct 19 17:13:47 <nunojpg> is gabor taking care of GPIO/leds on ar7xx?
Oct 19 17:14:02 <DonkeyHotei> i made it print it before
Oct 19 17:14:19 <DonkeyHotei> it's like there is nothing on the mdio bus at all
Oct 19 17:14:36 <nunojpg> with timer as trigger for a led, if you set delay_on to the same value it already has, it stops blinking
Oct 19 17:15:00 <nunojpg> echo timer > trigger (starts blinking)
Oct 19 17:15:16 <[florian]> DonkeyHotei: the read callback for the mdio bus returns 0' or f'?
Oct 19 17:15:19 <nunojpg> echo 500 > delay_on (stops blinking, assuming the default 500)
Oct 19 17:15:35 <DonkeyHotei> what read callback?
Oct 19 17:16:03 <[florian]> cpmac_mdio_read
Oct 19 17:18:25 <DonkeyHotei> idk, but the matching function sees the phy_id's signature the same as the ones where there is no phy
Oct 19 17:19:13 <[florian]> you should also check what's in the fixup callback of the specific phy driver
Oct 19 17:19:37 <[florian]> because the idea to to have a match mask which is very permissible, and then use the fixup to actually know whether we can bind this phy driver
Oct 19 17:20:06 <DonkeyHotei> the only thing that can match is Generic PHY
Oct 19 17:20:41 <DonkeyHotei> any mask even slightly less permissive won't match
Oct 19 17:20:44 <[florian]> what's in the phy id1 and id2 registers?
Oct 19 17:20:59 <DonkeyHotei> what are those?
Oct 19 17:21:48 <DonkeyHotei> you said yourself the L variant is gpio-only, not mdio
Oct 19 17:22:29 <[florian]> I don't understand how it can appear no your mdio bus then
Oct 19 17:22:56 <[florian]> *on
Oct 19 17:25:02 <[florian]> do you have the gpio switch mapping for your device?
Oct 19 17:25:24 <DonkeyHotei> no
Oct 19 17:26:03 <[florian]> you could probably try the one that I pasted to you privately a couple of days ago
Oct 19 17:30:25 <DonkeyHotei> what is cpmac_mii->phy_map?
Oct 19 17:31:12 <[florian]> an array of struct phy_device indexed by the phy address
Oct 19 17:31:29 <DonkeyHotei> initialized by what?
Oct 19 17:31:58 <[florian]> by mdiobus_register
Oct 19 17:40:13 <DonkeyHotei> it does not appear to be
Oct 19 17:59:03 <DonkeyHotei> [florian]: phy address zero registers a phy with phy id zero
Oct 19 17:59:14 <DonkeyHotei> and its signature is zero
Oct 19 17:59:25 <[florian]> ok, then it's definitively not on the mdio bus
Oct 19 17:59:41 <[florian]> but if the generic phy driver sees a link, well good for us
Oct 19 18:00:12 <DonkeyHotei> the generic phy driver sees a link on cpmac low instead of high
Oct 19 18:00:38 <DonkeyHotei> so, bad
Oct 19 18:00:59 <[florian]> what a crappy design
Oct 19 18:01:53 <DonkeyHotei> wtf is actually going on?
Oct 19 18:02:19 <[florian]> I do not know how the cpmac mdio hardware decides whether there is actually something "alive" on the bus or not
Oct 19 18:18:33 <russell--> nbd: i'm looking at commit b85cea321924691b1520333f2fa60994d83dc294 ... looking to extend that to detect more boards ... not sure the /proc/bus/pci/devices line count is necessarily the best way, it seems to be mostly for the purpose of determining how many ethernet interfaces there are in order to come up with a reasonable default /etc/config/network
Oct 19 18:19:33 <russell--> r25102 in svn speak
Oct 19 18:20:17 <nbd> i don't know anything about these devices, i just applied the patch
Oct 19 18:21:19 <russell--> grep -c natsemi /proc/bus/pci/devices might be a better way to choose
Oct 19 18:21:36 <russell--> yeah, okay, /me might ping the patch writer
Oct 19 18:22:34 * russell-- still looking into net45xx failures, it looks like vanilla builds are working, select-all-packages builds and panic'ing on boot
Oct 19 18:22:46 <russell--> weirdness
Oct 19 18:23:20 <russell--> ... are* panic'ing on boot
Oct 19 18:46:10 <roh> hm. i am still seeing these weird atheros/hostapd bug
Oct 19 18:46:48 <nbd> roh: what kind of bug?
Oct 19 18:50:41 <roh> users can't connect and somehow it needs a restart of hostapd
Oct 19 18:51:09 <roh> the inactive time is running extremely high for stations which arent even there anymore
Oct 19 18:51:17 <roh> like 10digits or more
Oct 19 18:53:52 <roh> nbd: i am seeing this on our tplink 741 every few days... not sure what triggers it
Oct 19 18:54:09 <nbd> which rev?
Oct 19 18:54:33 <roh> i had trunk, and flashed stable some time ago. lemme check
Oct 19 18:54:36 <nbd> if it's older than 33635, you should upgrade
Oct 19 18:54:42 <roh>  ATTITUDE ADJUSTMENT (12.09-beta, r33312)
Oct 19 18:54:51 <roh> ah. ok
Oct 19 18:54:55 <nbd> yeah, that one doesn't have the fixes for this specific problem yet
Oct 19 18:56:34 <roh> :) good to hear its fixed.
Oct 19 19:11:09 <roh> hm. there re no builds of it on downloads.?
Oct 19 19:23:43 <nbd> not yet
Oct 19 20:02:55 <DonkeyHotei> [florian]: i can't even force it to use fixed phy and have it work
Oct 19 20:09:42 <[florian]> DonkeyHotei: I guess your switch really needs some kind of programming to work correctly
Oct 19 20:16:07 <DonkeyHotei> it used to work back when cpmac was fixed-only
Oct 19 20:16:45 <[florian]> which cpmac is actually the one connected to the switch?
Oct 19 20:26:58 <DonkeyHotei> [florian]: i don't remember. i could try to check a bootlog from stock firmware
Oct 19 20:53:24 <DonkeyHotei> bootlog has these two interesting lines:
Oct 19 20:53:27 <DonkeyHotei> Loading ADM6996I/M device driver...
Oct 19 20:53:28 <DonkeyHotei> ((((((reset_adm6996L))))))
Oct 19 21:11:42 <DonkeyHotei> [florian]: based on the irq reported in the stock firmware, it seems to be cpmac high
Oct 19 21:29:00 <olmari> current trunk for x86 doens't compile..
Oct 19 21:29:13 <olmari> scripts/kconfig/conf --silentoldconfig Kconfig *snip* MSI Laptop Extras (MSI_LAPTOP) [N/m/?] (NEW) aborted! *snip* Console input/output is redirected. Run 'make oldconfig' to update configuration. --> make error
Oct 19 21:52:25 <russell--> olmari: yeah
Oct 19 21:53:42 * russell-- sent a patch to openwrt-devel a few days ago, currently trying to figure out larger problems with net45xx
Oct 19 21:55:07 <russell--> olmari: http://patchwork.openwrt.org/patch/2786/
Oct 19 21:59:42 <olmari> mm well AFAIK I didn't even choose psspkr
Oct 19 22:02:28 <olmari> ag I see
Oct 19 22:05:56 <DonkeyHotei> nbd mentioned the tl-mr3020, but i'm curious: is the tl-mr3040 different in any way at all hardwarewise besides the battery?
Oct 19 22:08:37 <roh> i think they are very much alike. only differ in gpio mappings and port assignments
Oct 19 22:09:26 <roh> i mean all the tplink micro-routers
Oct 19 22:14:54 <blogic> roh: i think so yes
Oct 19 22:15:14 <blogic> the SoC is ultra low cost and there is not much to do really
Oct 19 22:15:29 <blogic> its more a uC on steroid and with mmu than a small SoC
Oct 19 22:16:05 <DonkeyHotei> he said it was ar71xx
Oct 19 22:17:35 <russell--> olmari: if you compile a vanilla configuration it does build, so i'm guessing there is some kmod-* that's messing things up if selected
Oct 19 22:18:15 * russell-- currently bisecting ... r33504 is bad in that way
Oct 19 22:19:33 <olmari> well openwrt-devel answered with oatch already... and I don't think even valilal does it? I mean I have no addede kernel packages etc.. but this gixes it apparently (haven't yet tested, just fot the info) http://patchwork.openwrt.org/patch/2786/
Oct 19 22:21:11 <olmari> besides, older trunbk did compile, then newwer does not with same config, so I don't think it's directly related to mine settings anyhow :)
Oct 19 22:29:57 <olmari> LOL I AM on openwrt-devel..
Oct 19 22:30:13 <olmari> sorry =)
Oct 19 22:30:55 <olmari> russell--: anyways... I dunno how much more vanilla I could get... got package here and there chosen, not much really
Oct 19 22:31:07 <olmari> and as said, very same config in earlier trunks did work
Oct 19 22:31:41 <blogic> olmari: easy and dirty hack is to call make kernel_oldconfig and simple answer the question with N
Oct 19 22:32:40 <olmari> blogic: well it didn't ask it
Oct 19 22:32:44 <olmari> jsut ran it
Oct 19 22:33:02 <olmari> nor make oldconfig
Oct 19 22:45:44 * russell-- retracts libelous slander against r33504 pending a retest
**** ENDING LOGGING AT Sat Oct 20 03:00:02 2012