**** BEGIN LOGGING AT Sun Nov 27 02:59:57 2011
Nov 27 04:32:58 <CIA-77> nbd * r29338 /trunk/package/mac80211/patches/543-ath9k_enable_ar9100_ani.patch: ath9k: enable ANI on ar913x, should noticeably improve stability in noisy environments
Nov 27 04:35:45 <roh> well.. the 741v1 image works fine when flashed via tftp and serial.
Nov 27 04:35:59 <roh> too bad ive got no clue why it doesnt work in the oem web ui. *sigh*
Nov 27 04:38:17 <CIA-77> nbd * r29339 /branches/backfire/package/mac80211/patches/543-ath9k_enable_ar9100_ani.patch: ath9k: enable ANI on ar913x, should noticeably improve stability in noisy environments (backport of r29338)
Nov 27 05:33:29 <CIA-77> nbd * r29340 /trunk/package/dropbear/patches/200-lcrypt_bsdfix.patch: dropbear: fix build breakage
Nov 27 06:32:00 <CIA-77> nbd * r29341 /trunk/package/mac80211/patches/544-ath9k_fix_sleep_mode_reg.patch: ath9k: fix a regression in touching power mode related registers
Nov 27 06:33:07 <CIA-77> nbd * r29342 /branches/backfire/package/mac80211/patches/544-ath9k_fix_sleep_mode_reg.patch: ath9k: fix a regression in touching power mode related registers (backport of r29341)
Nov 27 09:30:22 <dape-at-home> roh use IE9 instead of.. any other browser?
Nov 27 09:30:30 <dape-at-home> IE8 i think works too
Nov 27 13:07:26 <acw_> Hello, anyone have experience compiling ruby with extensions?
Nov 27 13:15:39 <acw_> Or compiling ruby extensions rather
Nov 27 13:55:49 <builder_> build #90 of avr32 is complete: Failure [failed compile_4]  Build details are at http://buildbot.openwrt.org:8010/builders/avr32/builds/90
Nov 27 14:42:26 <slonopotamus_> mb__: ping
Nov 27 14:44:54 <slonopotamus_> mb__: target/linux/omap24xx/patches-3.1/210-omap2-kexec-rewrite.patch + binutils-2.21.1 = Error: .size expression for cpu_resume_turn_mmu_on does not evaluate to a constant
Nov 27 14:57:46 <mb__> is that latest binutils?
Nov 27 15:42:51 <slonopotamus_> dunno. that's what gone stable in gentoo this week.
Nov 27 15:43:00 <slonopotamus_> oh, you're here
Nov 27 15:43:26 <slonopotamus_> mb__: https://github.com/slonopotamus/n8x0-overlay/tree/master/sys-kernel/n8x0-sources/files/3.1.1/gentoo-patches n800 led driver
Nov 27 15:44:47 <mb__> slonopotamus_: Yeah I saw those
Nov 27 15:46:41 <slonopotamus_> mb__: first part is taken as-is from linux-omap, board file is heavily tweaked to apply on top of openwrt series
Nov 27 15:47:22 <mb__> Does this also work on n810?
Nov 27 15:48:24 <mb__> One thing that bothers me is that you use retu_write_reg on a non-retu device.
Nov 27 15:48:32 <mb__> How does that possibly work?
Nov 27 15:48:42 <mb__> I think it only works by accident through the parent pointer
Nov 27 15:49:05 <mb__> I think you have to allocate two devices
Nov 27 15:49:11 <mb__> One "omap_pwm_led" and one retu device
Nov 27 15:49:52 <mb__> omap_pwm_led can be a child of the retu child then
Nov 27 15:53:27 <slonopotamus_> mb__: n810 doesn't have this device
Nov 27 15:53:38 <slonopotamus_> mb__: led is declared as a child of retu device
Nov 27 15:53:50 <slonopotamus_> mb__: and retu_write_reg expects pointer to child
Nov 27 15:54:15 <slonopotamus_> mb__: n800_keypad_led_device.dev.parent is retu.
Nov 27 15:56:10 <mb__> Yeah but that isn't how the device subsystem works
Nov 27 15:56:16 <mb__> This only works by accident
Nov 27 15:56:26 <mb__> You need to allocate a retu device
Nov 27 15:56:56 <slonopotamus_> mb__: wrt binutils issue. googling reveals several similar errors and they all end up being invalid assembly that was accepted by earlier binutils but no longer accepted by newer ones
Nov 27 15:57:07 <slonopotamus_> mb__: i think i don't understand what you mean
Nov 27 15:57:37 <mb__> slonopotamus_: Well, are you familar with the linux device driver model?
Nov 27 15:58:03 <slonopotamus_> of course no :)
Nov 27 15:58:17 <slonopotamus_> well, i thought i understoo it but you say i'm wrong
Nov 27 15:58:18 <mb__> There always is only one driver per device
Nov 27 15:58:27 <mb__> you're hacking two drivers per LED device
Nov 27 15:58:50 <mb__> retu is a driver and the new LED driver you introduce is a driver
Nov 27 15:59:05 <mb__> You need to allocate a device per driver
Nov 27 15:59:35 <mb__> retu devices are allocated in retu.c, for convenience
Nov 27 16:08:58 <slonopotamus_> i don't see how that's convenient if they're device-specific
Nov 27 16:09:10 <slonopotamus_> i mean, board-specific
Nov 27 16:10:14 <slonopotamus_> actually i don't want any retu-specific for led. i just need to call retu_write_reg (which doesn't care of my device). can i call retu_write_reg on retu device itself?
Nov 27 16:12:12 <slonopotamus_> and if i do a separate device in retu.c as you suggest, how i connect it to led device currently declared for led?
Nov 27 16:12:39 <mb__> This is how the linux device driver model works. There's no way around that.
Nov 27 16:12:51 <slonopotamus_> mb__: so you want me led <- dumb <- retu instead of led <- retu?
Nov 27 16:13:11 <mb__> o.O
Nov 27 16:13:55 <mb__> I think you should get some driver book or something.
Nov 27 16:14:03 <mb__> I won't explain the whole stuff here
Nov 27 16:14:08 <slonopotamus_> meh... let's try again. what does "device A is parent of device B" mean?
Nov 27 16:14:44 <slonopotamus_> mb__: like this one? http://lwn.net/Kernel/LDD3/
Nov 27 16:14:46 <mb__> Well it means that a is lower (as in closer to the root) in the device hierarchy
Nov 27 16:14:58 <mb__> Yeah that's pretty good
Nov 27 16:15:33 <mb__> You could make the omap_pwm_led device a child of the retu-led device. Or something like that
Nov 27 16:15:45 <mb__> Or you could even make them unrelated. Doesn't really matter
Nov 27 16:15:52 <mb__> But it has to be two devices
Nov 27 16:16:11 <slonopotamus_> well, it does because i don't want led device to be inited before retu device
Nov 27 16:16:13 <mb__> making it a child probably is more ideomatic
Nov 27 16:16:37 <mb__> Linux takes care of that
Nov 27 16:16:54 <mb__> If you don't abuse the device model (which you currently do)
Nov 27 16:44:31 <builder_> build #91 of sibyte is complete: Exception [exception interrupted]  Build details are at http://buildbot.openwrt.org:8010/builders/sibyte/builds/91
Nov 27 16:44:31 <builder_> build #90 of xburst is complete: Exception [exception interrupted]  Build details are at http://buildbot.openwrt.org:8010/builders/xburst/builds/90
Nov 27 16:44:33 <builder_> build #83 of iop32x is complete: Exception [exception interrupted]  Build details are at http://buildbot.openwrt.org:8010/builders/iop32x/builds/83
Nov 27 16:44:35 <builder_> build #102 of ps3 is complete: Exception [exception interrupted]  Build details are at http://buildbot.openwrt.org:8010/builders/ps3/builds/102
Nov 27 17:17:39 <slonopotamus_> mb__: if i passed retu device itself to retu_write_reg (and you do that in charger thingie, it would still be wrong?
Nov 27 17:19:56 <roh> dape-at-home: huh? nobody has anything which could use ie around here for years
Nov 27 17:25:55 <mb__> slonopotamus_: No I don't do that in charger
Nov 27 17:26:00 <mb__> and it would crash
Nov 27 17:26:24 <mb__> n810bm allocates a new retu child device
Nov 27 17:26:26 <mb__> (and tahvo)
Nov 27 17:49:40 <slonopotamus_> mb__: hmm... okay, let's suppose i create a "retu-led" child in retu.c. but how i get a reference to it when declaring a led-class device in board file?
Nov 27 17:50:45 <mb__> slonopotamus_: you need to register a platform driver for it
Nov 27 17:50:57 <mb__> Just like all other retu drivers do
Nov 27 17:51:15 <mb__> pwrbutton, n810bm and whatever others there are
Nov 27 18:07:29 <slonopotamus_> mb__: you don't currently pass any board info to retu children and don't init them depending on machine so i can't do "just like all other retu drivers"
Nov 27 18:08:25 <mb__> Just register the platform driver only on n800.
Nov 27 18:08:49 <mb__> Or check the platform when registering the retu device
Nov 27 18:10:12 <slonopotamus_> meh... and all that just because for some stupid reason retu_write_reg wants a pointer to child device (instead of retu device itself) though the first thing it does is takes dev->parent and forgets about dev immediately.
Nov 27 18:10:59 <mb__> It probably is 5 lines of additional code
Nov 27 18:11:40 <mb__> This is how stuff works. I'm not going to merge stuff that just works by accident, because then I'll have to fix it up later by myself when it blows up.
Nov 27 18:16:10 <slonopotamus_> how stuff works <-- that's why i wrote code this way. i opened retu_write_reg. its documentation (and source) told me to pass a child device. i passed it a child device. of course it works because it takes parent and parent _is_ retu. i think you have some secret knowledge (not expressed in code) that lets you say my code is architecturally wrong.
Nov 27 18:17:38 <mb__> If it wants "a child device" it wants "a child device of retu", of course. And not "any random child device"
Nov 27 18:18:03 <slonopotamus_> my device has retu as a parent. whence, it is retu child. no?
Nov 27 18:18:27 <mb__> no. You just papered over the pointer
Nov 27 18:18:37 <mb__> That doesn't make it a child.
Nov 27 18:20:08 <slonopotamus_> really? that's _exactly_ what retu_allocate_child does (just sets parent pointer)
Nov 27 18:21:31 <mb__> yeah. And it does other things, too. Which retu might depend on (it _currently_ doesn't)
Nov 27 18:25:25 <slonopotamus_> so... 1. i make a retu-led driver 2. i pass it a platform data. 3. when retu-led probe func is called, it creates a led device itself and passes it over platform data. correct?
Nov 27 18:25:54 <slonopotamus_> 4. in board file i say than n800 has a new device with retu-led driver
Nov 27 18:27:16 <mb__> Yeah something like that
Nov 27 18:27:56 <slonopotamus_> and i don't specify any parent in board file? just call platform_device_register
Nov 27 18:31:38 <CIA-77> jow * r29343 /packages/net/samba3/ (12 files in 3 dirs): (log message trimmed)
Nov 27 18:31:38 <CIA-77> [PATCH-v6] samba 3.0.37 update
Nov 27 18:31:38 <CIA-77> Samba3 patch is updated again so it applies after the new serive function
Nov 27 18:31:38 <CIA-77> update (#29075).
Nov 27 18:31:38 <CIA-77> I just tested it on my router and everything (still) seems to work.
Nov 27 18:31:38 <CIA-77> So please commit it.
Nov 27 18:31:39 <CIA-77> Through all versions these things are added to the original package in the
Nov 27 18:31:52 <mb__> Well the parent for the led driver doesn't really matter. But you might want to specify the retu-led device.
Nov 27 18:32:08 <mb__> gives a cleaner sysfs layout
Nov 27 18:32:25 <slonopotamus_> how? if it will only start to exist when retu_child_alloc is called? i don't have a pointer to it
Nov 27 18:33:10 <slonopotamus_> err, no, wait. i talk about .dev.parent in board file, not about parent that i specify in retu-led probe.
Nov 27 18:33:53 <CIA-77> jow * r29344 /packages/net/samba3/patches/ (140-no_mmap.patch 180-fix_duplicate_define.patch): [packages] samba3: remove now empty patches
Nov 27 18:34:12 <mb__> it can be assigned when it's registered
Nov 27 18:34:20 <mb__> then you have a dev pointer
Nov 27 18:48:13 <slonopotamus_> meh... no, i fail to understand this
Nov 27 18:53:19 <CIA-77> jow * r29345 /packages/net/xtables-addons/Makefile: [packages] xtables-addons: package ip6table_rawpost
Nov 27 19:33:41 <Delboy_> nbd: ping
Nov 27 20:33:27 <solca> jow_laptop: the new service functions can be backported to backfire?
Nov 27 20:33:35 <solca> many packages don't run now
Nov 27 21:00:24 <loswillios> backfire has it's own branch
Nov 27 21:13:16 <jow_laptop> for exactly that reason
Nov 27 21:30:33 <dape-at-home> well, im eager to see 3.x.x kernel for ar71xx , will it be tonight, tomorrow or next week?
Nov 27 21:31:25 <_trine> is anyone interested in fixing this ticket? https://dev.openwrt.org/ticket/9980
Nov 27 21:35:22 * jow_laptop is eager to see a new kernel that does not increase size and cause regressions
Nov 27 21:35:23 <loswillios> dape-at-home: you can get the patch from the mailinglist
Nov 27 21:36:32 <dape-at-home> jow_laptop its not really a fetish but between 2.6.39 and 3.1.x i think there's gotta be some improvements
Nov 27 21:36:49 <jow_laptop> like broken t-proxy, broken l2tpv3, broken ipset?
Nov 27 21:37:08 <jow_laptop> definitely an improvement, less features to care about :)
Nov 27 21:37:11 <dape-at-home> loswillios im not in a rush, i just asked for a timeline, also im perfectly fine waiting for it in normal trunk
Nov 27 21:37:18 <dape-at-home> jow_laptop meh, i dont use those
Nov 27 21:37:32 <jow_laptop> neither do the people that bump the kernels
Nov 27 21:37:51 <dape-at-home> alright then, so we can only wait
Nov 27 21:38:33 <jow_laptop> or a new killer feature, broken igmp snooping
Nov 27 21:38:41 <dape-at-home> hehe
Nov 27 21:38:43 <jow_laptop> in contrast to none at all
Nov 27 21:39:00 <loswillios> ;)
Nov 27 21:39:05 <jow_laptop> it usually takes weeks after a kernel jump to sort all this out
Nov 27 21:39:11 <dape-at-home> great !
Nov 27 21:39:17 <roh> hrhr.
Nov 27 21:39:22 <jow_laptop> thats why I am getting annoyed by this updating for the sake of the shiny numbers
Nov 27 21:39:37 <jow_laptop> I do understand that there are possible benefits
Nov 27 21:39:40 <roh> anybody interrested in helping me sorting out the tplink oem fw upgrade issue?
Nov 27 21:39:51 <dape-at-home> okay jow_laptop thanks for the insight
Nov 27 21:41:07 <jow_laptop> but on the other hand I do not touch kernel stuf so I won't complain. its trunk after all, meant to be developed
Nov 27 21:42:38 <dape-at-home> all i can do (and probably many others) is test whatever you guys give us and provide fast feedback
Nov 27 21:43:36 <jow_laptop> roh: did you compare the vendor image headers with the openwrt ones? Its often only an embedded version number that makes the difference
Nov 27 21:44:28 <jow_laptop> a vbindiff over the first KB of each would be helpful
Nov 27 22:14:02 <roh> jow_laptop: i did, and they all match up
Nov 27 22:14:27 <roh> jow_laptop: the v2 is labeled as v1 everywhere
Nov 27 22:16:03 <roh> jow_laptop: as far as i can see the only 'odd' things standing out are that openwrt images dont have the second md5sum
Nov 27 22:16:26 <jow_laptop> hm
Nov 27 22:16:40 <roh> and a revision instead of a version
Nov 27 22:18:58 <roh> http://pastebin.com/Z3d1h9mK
Nov 27 22:19:14 <roh> the first image is a web download from tplink which the device 'liked' afaik
Nov 27 22:19:28 <roh> the latter was one of the images i downloaded which it did not like
Nov 27 22:20:16 <roh> it works fine with the v1 image when using tftp
Nov 27 22:20:39 <roh> does the tplink thing check something like the entry offsets of the kernelimage?
Nov 27 23:28:52 <swalker> updated openwrt/upstream, https://home.comcast.net/~sdwalker/uscan/index.html
Nov 28 00:48:38 <dape-at-home> hey, there is something wrong with latest build but i cant figure it out
Nov 28 00:49:26 <dape-at-home> seems like after flashing dlink dir825 with r29341 some websites wont load
Nov 28 00:49:43 <dape-at-home> traceroute seems fine, http not, tried different mtus, still they hang
Nov 28 00:58:41 <dape-at-home> r29266 worked fine..
Nov 28 01:05:36 <jow_laptop> the mtu_fix changed
Nov 28 01:05:43 <jow_laptop> are you on pppoe?
Nov 28 01:06:22 <jow_laptop> nvm
Nov 28 01:06:25 <dape-home> yes jow, (i was just reflashing, hence disconnecting)
Nov 28 01:06:35 <dape-home> uhm, what should i do?
Nov 28 01:06:44 <jow_laptop> r29266 was already past this change
Nov 28 01:06:51 <jow_laptop> don't know, tcpdump?
Nov 28 01:08:46 <dape-home> cant really test much since this dir825 is the main router here :P im gonna flash 29266 and test the other tplinks these days to check whats the problem
Nov 28 01:29:36 <dape-at-home> hmm, seems like checksums are incorrect (im tcpdumping the wget to www.linux-usb.org/usb.ids which hangs)
Nov 28 01:33:51 <dape-at-home> hmm, set mtu_fix 0 restarted firewall, nothing. put back mtu_fix 1 , restarted firewall and now it works
Nov 28 01:34:21 <dape-at-home> absolutelu everything works now
Nov 28 01:49:02 <dape-home> jow_laptop i think i isolated the problem, so flashed brand new r29341 , setup lan and wan pppoe credentials, started www.facebook.com in firefox, hang.
Nov 28 01:49:53 <dape-home> restarted firewall with /etc/init.d/firewall restart without modifying mtu_fix in /etc/config/firewall and the facebook page works great
**** ENDING LOGGING AT Mon Nov 28 02:59:56 2011