**** BEGIN LOGGING AT Wed Oct 20 02:59:56 2010
Oct 20 06:48:23 <builder> build #10 of ps3 is complete: Failure [failed compile_6]  Build details are at http://tksite.gotdns.org:8010/builders/ps3/builds/10
Oct 20 07:46:28 <Alicemirror1> hi... How can I set configuration to install PHY device in openwrt toolchain ?
Oct 20 08:06:20 <Alicemirror1> to be correct I think that I need PHY enabled.
Oct 20 08:59:55 <acoul> hello
Oct 20 09:01:56 <builder> build #9 of xburst is complete: Failure [failed compile_4]  Build details are at http://tksite.gotdns.org:8010/builders/xburst/builds/9
Oct 20 09:42:54 <stintel> nbd: fyi, with r23543 iw list looks again a bit different, but not entirely ok yet. http://openwrt.pastebin.com/D3Nf2Rni
Oct 20 09:43:10 <stintel> I'll test tonight with only the sr71-a in the rspro
Oct 20 09:43:31 <stintel> or I can test here at work with only an r52n
Oct 20 10:03:55 <stintel> nbd: r23543 with r52n only http://openwrt.pastebin.com/PD3t9H0B
Oct 20 11:30:48 <CIA-39> acoul * r23544 /trunk/target/linux/generic/patches-2.6.36/ (2 files): linux/generic: sync to todays yaffs tree
Oct 20 11:36:02 <CIA-39> acoul * r23545 /trunk/target/linux/generic/patches-2.6.36/511-yaffs-git-2010-10-20.patch: target/linux: refresh previous patch
Oct 20 11:37:09 <loswillios> xeros: Where would I write -std=c99 or -std=gnu99 in a Makefile?
Oct 20 11:37:39 <xMff> TARGET_CFLAGS += -std=gnu99
Oct 20 11:37:47 <loswillios> thanks
Oct 20 11:38:40 <CIA-39> tripolar * r23546 /packages/net/openssh/files/sshd.init:
Oct 20 11:38:40 <CIA-39> use kill $(cat /var/run/sshd.pid) instead of killall sshd to
Oct 20 11:38:40 <CIA-39> avoid that the init script and all sshd instances are killed
Oct 20 11:38:40 <CIA-39> when sshd is restarted
Oct 20 11:38:40 <CIA-39> thanks matt
Oct 20 11:39:14 <xMff> meh, another badly implemented kill
Oct 20 11:55:17 <CIA-39> tripolar * r23547 /packages/net/openssh/Makefile: PKG_RELEASE++
Oct 20 12:59:59 <OutBackDingo> nbd: http://openwrt.pastebin.com/faTHMkwf i would concur, it now seems we have gone from 20bm to 16db
Oct 20 13:00:12 <OutBackDingo> stintel: anything working for you
Oct 20 13:05:14 <nbd> OutBackDingo: the 20 dBm value wasn't real anyway
Oct 20 13:05:36 <nbd> that was just the hardcoded driver default
Oct 20 13:05:38 <OutBackDingo> so the radios are actually running at 16dbm ?
Oct 20 13:05:42 <nbd> yes
Oct 20 13:05:51 <OutBackDingo> how can i get them to 27
Oct 20 13:06:05 <nbd> what hw?
Oct 20 13:06:16 <OutBackDingo> picostation M2HP
Oct 20 13:06:28 <nbd> i wouldn't be surprised if that thing has a power offset
Oct 20 13:07:01 <OutBackDingo> whats the best way to measure real power then ?
Oct 20 13:07:11 <OutBackDingo> prolly some high end gear
Oct 20 13:07:54 <OutBackDingo> i mean iwconfig wlan2 txpower does nothing
Oct 20 13:08:05 <jow_laptop> OutBackDingo: I think there's no real way on the software side to check the effective power. I once examined the dd-wrt to learn how it doeals with madwifi
Oct 20 13:08:15 <jow_laptop> ... and they had hughe tables with pci ids and txpower info
Oct 20 13:08:23 <jow_laptop> whether it has offset, if yes how much etc.
Oct 20 13:08:47 <jow_laptop> if you get the latest iw (.21) you'll have txpower controls there
Oct 20 13:09:32 <OutBackDingo> iw --version
Oct 20 13:09:32 <OutBackDingo> iw version 0.9.21
Oct 20 13:09:40 <OutBackDingo> this is on trunk
Oct 20 13:10:48 <jow_laptop> you should be able to set it via some phy operation then
Oct 20 13:13:15 <OutBackDingo> iw wlan0 set txpower 8
Oct 20 13:13:23 <OutBackDingo> Invalid parameter: 8
Oct 20 13:13:28 <OutBackDingo> hrmmm
Oct 20 13:13:44 <loswillios> jow_laptop: is there a target to rebuild uclibc? toolchain/uClibc/{clean,prepare} QUILT=1 does something but didn't apply the patches from toolchain/uClibc/patches-0.9.32/
Oct 20 13:13:50 <OutBackDingo> jow_laptop: itll take iw wlan0 set txpower auto
Oct 20 13:15:17 <jow_laptop> loswillios: thats normal for QUILT=1
Oct 20 13:15:26 <jow_laptop> loswillios: you have to cd in there and run quilt push -a
Oct 20 13:15:46 <loswillios> ah, right
Oct 20 13:17:13 <loswillios> is there an easy way to refresh patches? some apply only with an offset, would be nice to automatically correct them
Oct 20 13:17:38 <jow_laptop> quilt pop -a
Oct 20 13:17:51 <jow_laptop> quilt push; quilt refresh; quilt push; quilt refresh; ...
Oct 20 13:17:58 <jow_laptop> finally
Oct 20 13:18:09 <jow_laptop> make toolchain/uClibc/update
Oct 20 13:18:47 <jow_laptop> there is a .../refresh target which does prepare, push, refresh, ..., update but it does not seem to impemented for toolchain or tools targets
Oct 20 13:18:56 <jow_laptop> only for packages
Oct 20 13:19:45 <loswillios> great, thanks
Oct 20 13:20:14 <acoul> I copied that to my internal wiki too ;-)
Oct 20 13:22:03 <OutBackDingo> jow_laptop: so iw should be iw wlan0 set txpower ????
Oct 20 13:22:37 <jow_laptop> OutBackDingo: I think so, yes
Oct 20 13:22:58 <OutBackDingo> iw wlan0 set txpower 8 dont work
Oct 20 13:23:15 <jow_laptop> well try 8dbm
Oct 20 13:23:19 <jow_laptop> like with iwconfig
Oct 20 13:24:14 <OutBackDingo> iw wlan0 set txpower 8dbm
Oct 20 13:24:14 <OutBackDingo> Invalid parameter: 8dbm
Oct 20 13:24:16 <OutBackDingo> nope
Oct 20 13:24:24 <OutBackDingo> phy <phyname> set txpower <auto|fixed|limit> [<tx power in mBm>]
Oct 20 13:24:26 <OutBackDingo> hrmmm
Oct 20 13:24:38 <nbd> iw wlan0 set txpower 800
Oct 20 13:24:48 <nbd> notice the mBm instead of dBm?
Oct 20 13:24:59 <jow_laptop> iw phy0 set txpower fixed 123
Oct 20 13:25:05 <jow_laptop> iw phy0 set txpower limit 123
Oct 20 13:25:08 <jow_laptop> iw phy0 set txpower auto
Oct 20 13:25:12 <nbd> yes, was missing the fixed/limit
Oct 20 13:26:01 <nbd> iw wlan0 set txpower limit 800 works
Oct 20 13:26:29 <OutBackDingo> iw phy0 set txpower fixed 1600
Oct 20 13:26:33 <OutBackDingo> ok yeah
Oct 20 13:26:42 <OutBackDingo> but it wount let me go over 1600
Oct 20 13:26:49 <OutBackDingo> sooo possibly offset
Oct 20 13:27:41 <nbd> if the phy info shows 16 at startup, then that's the limit
Oct 20 13:28:01 <OutBackDingo> nbd: though ubiquiti claims its a 1watt radio
Oct 20 13:28:14 <nbd> yes
Oct 20 13:28:16 <nbd> offset...
Oct 20 13:28:38 <stintel> this is getting confusing
Oct 20 13:28:41 <OutBackDingo> With up to 1000mW of output power, the PicoStation
Oct 20 13:28:52 <stintel> dBm, mBm, mW, offsets
Oct 20 13:28:57 <stintel> sigh
Oct 20 13:28:58 <OutBackDingo> quite curious
Oct 20 13:30:41 <OutBackDingo> wonder if changing the country code will allow for higher
Oct 20 13:33:48 <jow_laptop> nbd: can the offset be determined from eeprom or is that a radio hw thing the driver does not know about?
Oct 20 13:34:03 <nbd> the driver does not know about it
Oct 20 13:34:06 <jow_laptop> ok
Oct 20 13:34:08 <nbd> that was in fact the whole point of the offset
Oct 20 13:34:16 <nbd> so that the regdomain code doesn't get in the way
Oct 20 13:34:21 <jow_laptop> I see
Oct 20 13:36:02 <DonDiego> jow_laptop: any comments on my zoneinfo patch?
Oct 20 13:36:29 <jow_laptop> DonDiego: no, not yet - sorry. Honestly I forgot about last evening
Oct 20 13:36:48 <DonDiego> np
Oct 20 13:37:09 <DonDiego> jow_laptop: you mentioned that the serial console baudrate is set flexibly depending on model for x86
Oct 20 13:37:33 <DonDiego> jow_laptop: could you point me at where this is done so i can try to copy that code for mips?
Oct 20 13:45:41 <jow_laptop> DonDiego: target/linux/x86/image/Config.in iirc
Oct 20 13:45:47 <jow_laptop> its set with the first menuconfig run
Oct 20 13:45:59 <DonDiego> thanks, i'll have a look
Oct 20 13:51:17 <CIA-39> acoul * r23548 /trunk/target/linux/adm5120/patches-2.6.36/930-2_6_36_ports.patch: target/linux: adm5120/2.6.36 patches, fix a missing 0 (thank you florian)
Oct 20 14:05:11 <CIA-39> nbd * r23549 /trunk/package/mac80211/patches/540-ath9k_fix_survey_crash.patch: ath9k: fix a crash that happens when survey stats are accessed before the interface is brought up for the first time
Oct 20 14:10:21 <__lore__> ping nbd
Oct 20 14:11:25 <nbd> pong
Oct 20 14:12:22 <__lore__> hi
Oct 20 14:12:52 <nbd> hi
Oct 20 14:12:56 <__lore__> I saw your latest patch (https://dev.openwrt.org/browser/trunk/package/mac80211/patches/530-ath9k_locking_fix.patch)
Oct 20 14:12:59 <neutronscott> anyone have experience with rt61pci on a router? my first use of the rt2x00 are in openwrt trunk, and it totally blows chunks (and eats cpu). wondering if it always did.
Oct 20 14:13:10 <__lore__> I am facing a similar issue
Oct 20 14:13:23 <nbd> patch was done by luis
Oct 20 14:13:32 <nbd> there's a long thread about the rx memory clobber issue
Oct 20 14:13:32 <__lore__> could you descrive me the problem?
Oct 20 14:13:33 <nbd> on linux-wireless
Oct 20 14:13:40 <nbd> i've never seen the issue myself
Oct 20 14:13:48 <__lore__> ok
Oct 20 14:14:08 <__lore__> because I observed some random crash and reboot
Oct 20 14:14:26 <nbd> got an example?
Oct 20 14:14:32 <__lore__> like init and sleep crash the kernel
Oct 20 14:14:58 <nbd> did you test with the 530-* patch yet?
Oct 20 14:15:06 <__lore__> not yet
Oct 20 14:15:15 <nbd> ok
Oct 20 14:17:17 <__lore__> http://pastebin.ca/1968055
Oct 20 14:25:41 <__lore__> this is the stack trace of my device
Oct 20 14:38:55 <loswillios> mh, uClibc-git from today doesn't boot
Oct 20 16:23:39 <CIA-39> acoul * r23550 /packages/net/click/ (Makefile patches/110-multithread_fix.patch): net/click: update to today's git, add a fix patch.
Oct 20 17:13:22 <Alicemirror> Hi to all. I need to add a new filesystem (exactly wbfs) in my target tree.
Oct 20 17:13:23 <Alicemirror> The tree of the target is target/lpc313x/... under this level there is files/arch/... files/drivers/... include/... image/... patches/...
Oct 20 17:13:23 <Alicemirror> the directory fs/wbfs where must be? This directory contains source, kconfig file and makefile.
Oct 20 17:13:40 <Alicemirror> can I put under target/lpc313x/fs/wbfs ???
Oct 20 17:40:50 <xMff> Alicemirror: this filesystem is outside the official kernel?
Oct 20 17:42:59 <Alicemirror> yes. It's a new target that support its own filesystem. A previous programmer (that I hate a lot) created a target for openwrt 9 and kernel 2.6.29 but don't left the sources, only the directory in build_dir. Now I ported this target for owrt10 kernel 2.6.32 but something like this filesystem must already be set.
Oct 20 17:43:46 <Alicemirror> it's a target for a new board that should be relleased shortly next month.
Oct 20 17:44:11 <Alicemirror> with an openwrt open version. But I should have everything that works fine befor.
Oct 20 17:44:13 <Alicemirror> e
Oct 20 17:44:30 <xMff> ok
Oct 20 17:44:51 <xMff> you should put the sources of your filesystem int...
Oct 20 17:52:06 <xMff> philipp64|laptop: we have to rework the pppoa stuff a bit
Oct 20 17:53:20 <xMff> philipp64|laptop: "device" is overwritten with the resulting pppX iface internally so we have to use something else
Oct 20 17:53:25 <xMff> what about "atmdev" ?
Oct 20 17:54:26 <xMff> the same br2684ctl used "atmdev" too so I think it is okay
Oct 20 17:54:35 <_trine> xMff, if you have time can you check that iptables-mod-conntrack-extra is pulled in correctly by the other modules; in my case today I had to load it separately
Oct 20 17:57:27 <philipp64|laptop> I would not... it just confused people to overload names with different meanings. also noticed that pppoe seems to not support using PPPoE over a DSL NIC.
Oct 20 17:57:45 <philipp64|laptop> where does the br2684ctl stuff get configured?
Oct 20 17:58:12 <xMff> well I would neither but doing it the right way involves fixing 5 different packages and breaking config in an incompatble way
Oct 20 17:58:36 <xMff> so I'll change it to atmdev which is used by br2684 as well
Oct 20 17:59:48 <CIA-39> jow * r23551 /trunk/package/ppp/ (Makefile files/pppoa.sh): [package] pppd: use "atmdev" option to select the DSL adapter, this aligns it with br2684ctl and solves #8108
Oct 20 18:01:15 <philipp64|laptop> xMff: I think you misunderstood me.
Oct 20 18:01:43 <philipp64|laptop> it's possible to have multiple NICs (on the Geos) *and* have PVCs in use at the same time.
Oct 20 18:02:04 <philipp64|laptop> so any way you slice it, you need two distinct parameters.
Oct 20 18:02:07 <xMff> thats no problem, the br2684 is configured elsewhere (yet)
Oct 20 18:02:13 <xMff> https://dev.openwrt.org/browser/trunk/target/linux/ar7/base-files/etc/config/network#L20
Oct 20 18:02:23 <xMff> it resides in a config atm-bridge section
Oct 20 18:02:31 <xMff> so equally named atmdev will not clash
Oct 20 18:03:27 <philipp64|laptop> did the wiki get changed recently?  because it shows "unit" being used for that purpose... though the comment makes no sense.
Oct 20 18:03:42 <xMff> unit specifies the X in nasX
Oct 20 18:03:57 <xMff> atmdev is the thing added before vpi and vci
Oct 20 18:04:18 <philipp64|laptop> right.  and nasX gets created by br2684ctl, which only gets used in pppoe, not pppoa.
Oct 20 18:04:22 <xMff> so: $atmdev.$vpi.$vci -> nas$unit
Oct 20 18:04:57 <philipp64|laptop> then the text "ATM PVC number " needs to go away.
Oct 20 18:05:50 <philipp64|laptop> for that matter, "unit", "vpi", "vci", and "atmdev" are all optional parameters for pppoe over DSL.
Oct 20 18:06:08 <xMff> yes and all optional parameters for pppoa
Oct 20 18:06:13 <philipp64|laptop> "unit" is unused for pppoa.
Oct 20 18:06:19 <xMff> right
Oct 20 18:06:53 <philipp64|laptop> oh, plus "encaps". "payload" is only used for pppoe.
Oct 20 18:06:59 <xMff> why is "ATM PVC number" wrong?
Oct 20 18:07:14 <xMff> its called this way in the br2684 manpage
Oct 20 18:07:38 <philipp64|laptop> because on a Solos PCI card, I can have up to 4 DSL NIC's.
Oct 20 18:07:46 <xMff> and?
Oct 20 18:08:10 <philipp64|laptop> on each NIC, I can have multiple PPP connections, each one running over a vpi/vci pair, or a pvc.
Oct 20 18:08:47 <xMff> and whats wrong with that?
Oct 20 18:08:51 <xMff> don't get it
Oct 20 18:09:29 <philipp64|laptop> you're using "atmdev" to select that actual NIC (0-3). but the comment says you're using it for the PVC.
Oct 20 18:09:52 <philipp64|laptop> How do I describe PVC #67 running on NIC 3?
Oct 20 18:12:21 <philipp64|laptop> similarly, with br2684ctl, I can create many nasX interfaces, one for each vpi/vci or pvc.
Oct 20 18:12:39 <philipp64|laptop> and each of those can be on any of teh available hardware NICs.
Oct 20 18:14:06 <philipp64|laptop> the argument N.P.C that gets passed to pppoatm.so plugin means "card N", vpi/vci P/C.
Oct 20 18:14:29 <philipp64|laptop> (N defaults to 0 when omitted)
Oct 20 18:14:39 <xMff> same for br2684ctl, yet they call it "ATM PVC Number"
Oct 20 18:15:05 <xMff> -a [itf].vpi.vci    ATM PVC number, VPI and VCI. (Required)
Oct 20 18:15:19 <xMff> thats where I took it from
Oct 20 18:16:53 <xMff> but anway, can change it
Oct 20 18:16:54 <Alicemirror> xMff: My adsl today is wrong. I'm reconnected now.
Oct 20 18:17:25 <xMff> I just wonder how br2684 selects the card then if "[tif]" is an arbritary PVC number instead
Oct 20 18:18:03 <xMff> Alicemirror: new source that must go into the kernel tree should go into target/linux/$arch/files[-version]
Oct 20 18:18:18 <Alicemirror> ok, thank you. I try now :)
Oct 20 18:18:50 <philipp64|laptop> ah, I understand your confusion.
Oct 20 18:19:44 <philipp64|laptop> it's "itf" AND (PVC number OR VPI, VCI tuple).
Oct 20 18:20:15 <xMff> Alicemirror: usually file additions (like your fs sources) go into files/ and then the Kconfig integration in the form of a patch into target/linux/$arch/patches-version
Oct 20 18:20:38 <philipp64|laptop> a switched VPI/VCI is written vpi.vci, but so is a PVC # potentially. they just have different significance.
Oct 20 18:21:01 <Alicemirror> Yes, I supposed this. I think that the previous worker do this bad trouble to avoid to do a new patch.
Oct 20 18:21:59 <Alicemirror> I'm not able to create a patch too, but I'm documenting to know how to do.
Oct 20 18:22:12 <xMff> philipp64|laptop: so  cardID.VPI.VC  or  cardID.PVC  ?
Oct 20 18:24:29 <xMff> ah ATM PVC = VPI.VC ?
Oct 20 18:25:12 <xMff> ok so atmdev is right nonetheless and the documentation of it is wrong
Oct 20 18:25:41 <xMff> I'll descripe it as "DSL adapter number (starting with 0)" then
Oct 20 18:27:10 <philipp64|laptop> xMff: not exactly.  vpi/vci pairs are switched and temporary.  but if you use PNNI, the network will map your PVC onto a VPI/VCI pair for you.
Oct 20 18:27:57 <philipp64|laptop> VPI/VCI pairs are also per-hop, whereas PVC's are end-to-end.
Oct 20 18:28:00 <xMff> ok, gory details. but after rereading the man page I think atmdev is the adpater index/unit for both br...ctl and pppoatm.so
Oct 20 18:28:22 <xMff> the first number in the triple specifying the ... device
Oct 20 18:28:52 <philipp64|laptop> yes.
Oct 20 18:29:29 <xMff> while you're around
Oct 20 18:29:31 <philipp64|laptop> pppoatm runs over that triple. pppoe runs over nasX, where X is "unit".
Oct 20 18:29:48 <xMff> in one sentence, whats the diff between pppoa and br...ctl + pppoe?
Oct 20 18:29:56 <xMff> The latter is ip encapsulated additionally?
Oct 20 18:30:38 <philipp64|laptop> I've been trying to get Karl to map the pppoatm circuit to a pseudo interface like br2684ctl does (just so we can use it for tcpdump and snmp more easily), but he doesn't want to.
Oct 20 18:31:14 <xMff> :P
Oct 20 18:31:28 <philipp64|laptop> no.  pppoe uses AAL5 + a SNAP header to signify PPP.
Oct 20 18:32:13 <philipp64|laptop> In pppoatm, the VC is configured to ONLY carry one type of frame: PPP.  the VC # implicitly states the payload.
Oct 20 18:32:29 <xMff> ok so br....ctl + pppoe is ppp over ethernet over $atmstuff  while pppoa is ppp over $atmstuff ?
Oct 20 18:32:36 <builder> build #13 of brcm63xx is complete: Success [build successful]  Build details are at http://tksite.gotdns.org:8010/builders/brcm63xx/builds/13
Oct 20 18:33:10 <philipp64|laptop> yes. this is why you can have arbirtraily large MTU's over PPPoA but not over PPPoE.
Oct 20 18:34:10 <philipp64|laptop> In this case, $atmstuff is AAL4.
Oct 20 18:34:33 <philipp64|laptop>  http://en.wikipedia.org/wiki/Pppoa
Oct 20 18:34:43 <xMff> I changed the wiki documentation
Oct 20 18:35:04 <philipp64|laptop> AAL5.. sorry, typo.
Oct 20 18:35:49 <philipp64|laptop> and PPPoE almost always uses LLC, whereas PPPoA almost always uses VC.
Oct 20 18:36:28 <philipp64|laptop> you can also do raw IP over AAL5+LLC. this was the old RFC1483/ROUTED configuration.
Oct 20 18:37:13 <philipp64|laptop> the problem was, routing means a lot more intelligence in the DSLAM than simply backhauling a VC into an aggregating router like a C7200.
Oct 20 18:37:34 <philipp64|laptop> so telcos killed RFC1483/ROUTED.
Oct 20 18:37:42 <philipp64|laptop> too bad.
Oct 20 18:39:29 <loswillios> "In phase one of their trials they are relying on the tunneling mechanisms 6to4 and more recently 6RD (Rapid Deployment). Comcast has 'open sourced' its solution based on OpenWRT if you happen to have a router supported by OpenWRT"
Oct 20 18:39:34 <loswillios> nice
Oct 20 18:40:44 <philipp64|laptop> "unit" doesn't apply for PPPoA, just PPPoE.
Oct 20 18:41:01 <xMff> I'am still rewriting it
Oct 20 18:41:14 <philipp64|laptop> ah, ok. thought you were done.
Oct 20 18:50:01 <xMff> ok, done
Oct 20 18:50:09 <xMff> should be clearer now
Oct 20 19:09:16 <philipp64|laptop> actually PPPoA should have an encaps that defaults to VC.
Oct 20 19:09:47 <philipp64|laptop> not changing the PPPoE section just now I guess.
Oct 20 19:11:43 <philipp64|laptop> bbl.
Oct 20 19:37:11 <KanjiMonster> cshore: ping
Oct 20 20:01:01 <EqUaTe> evening KanjiMonster
Oct 20 20:01:19 <KanjiMonster> evening EqUaTe
Oct 20 20:01:28 <EqUaTe> barely afternoon here :P
Oct 20 20:05:08 <EqUaTe> how's it going?
Oct 20 20:13:39 <CIA-39> jow * r23552 /trunk/package/br2684ctl/ (Makefile files/br2684ctl):
Oct 20 20:13:39 <CIA-39> [package] br2684ctl: rework init script
Oct 20 20:13:40 <CIA-39> - use common defaults for unit and atmdev
Oct 20 20:13:40 <CIA-39> - add a more reliable stop routine
Oct 20 20:13:40 <CIA-39> - localize variables
Oct 20 21:05:11 <CIA-39> nbd * r23553 /trunk/package/mac80211/patches/550-ath9k_xretry_fix.patch: ath9k: fix a small bug in the handling of a few tx descriptor flags
Oct 20 21:05:11 <CIA-39> nbd * r23554 /trunk/package/mac80211/patches/560-minstrel_ht_performance.patch: mac80211: improve minstrel_ht performance by ensuring that rates get sampled fast enough
Oct 20 21:41:52 <CIA-39> nbd * r23555 /trunk/package/mac80211/patches/ (2 files): mac80211: decrease the minstrel_ht sampling interval for faster rate adaption
Oct 20 23:10:58 <CIA-39> mb * r23556 /trunk/include/kernel-version.mk: Add md5sum for linux-2.6.36
Oct 20 23:16:21 <CIA-39> mb * r23557 /trunk/target/linux/omap24xx/Makefile: omap24xx: Update to 2.6.36
Oct 20 23:38:34 <builder> build #14 of atheros is complete: Success [build successful]  Build details are at http://tksite.gotdns.org:8010/builders/atheros/builds/14
Oct 21 00:36:22 <CIA-39> nbd * r23558 /trunk/package/mac80211/patches/ (5 files): ath9k: fix sampling frame handling wrt. aggregation, replace minstrel_ht performance fixes for better performance
Oct 21 01:57:45 <philipp64|laptop> xMff: ping
Oct 21 01:58:00 <xMff> pong
Oct 21 01:58:33 <philipp64|laptop> asked James upstream about tweaking the Makefiles for PPP, but haven't heard back.
Oct 21 01:59:04 <philipp64|laptop> btw: my 2.6.35.7 configs for x86 seem stalled... what do I need to do to carry it over the finish line?
Oct 21 01:59:40 <xMff> someone will take care of it sooner or later
Oct 21 02:00:18 <philipp64|laptop> I hope so. I have a patch to enable LEDs on the net5501, but it's only available in 2.6.35.
Oct 21 02:15:43 <philipp64|laptop> I had to back burner that until my 2.6.35 patch gets committed.
**** ENDING LOGGING AT Thu Oct 21 02:59:57 2010