**** BEGIN LOGGING AT Sat Oct 31 02:59:57 2009 Oct 31 06:26:44 [florian]: revised patch: http://openwrt.pastebin.com/f3512ef23 Oct 31 09:12:45 sn9: did you get it working? Oct 31 11:03:15 <[florian]> sn9: could you please update that for .30? Oct 31 11:05:56 [florian]: does .30 work? Oct 31 11:06:12 <[florian]> sn9: that's what I am going to test Oct 31 11:06:25 <[florian]> got to first find the device in my mess :) Oct 31 11:07:54 i should add that ethernet no longer works AT ALL Oct 31 11:11:06 <[florian]> which device are you running it on? Oct 31 11:11:12 <[florian]> it works for me on ar525w Oct 31 11:12:38 anas350 Oct 31 11:13:05 <[florian]> that one only has one mac/phy ? Oct 31 11:13:11 yes Oct 31 11:13:38 <[florian]> does the device registration bail out due to not being able to read phy registers? Oct 31 11:13:57 hang on Oct 31 11:14:45 usbcore: registered new interface driver btusb Oct 31 11:14:46 <6>r6040: RDC R6040 NAPI net driver,version 0.22 (25Mar2009) Oct 31 11:14:46 r6040: MAC address not initialized, generating random Oct 31 11:14:46 <6>r6040: RDC R6040 NAPI net driver,version 0.22 (25Mar2009) Oct 31 11:14:46 eth0: link up, 100Mbps, full-duplex, lpa 0xC5E1 Oct 31 11:14:47 r6040 no second PHY attached Oct 31 11:14:48 r6040 no second PHY attached Oct 31 11:14:50 device eth1 entered promiscuous mode Oct 31 11:14:52 r6040 no second PHY attached Oct 31 11:15:30 <[florian]> this sounds like the expected behavior Oct 31 11:15:44 <[florian]> then does the first one work though? Oct 31 11:15:52 no Oct 31 11:16:22 it just keeps giving the link up msg over and over Oct 31 11:16:30 <[florian]> humm Oct 31 11:18:20 btw, on the ar525w, has it gone back to eth1 being lan and eth0 being wan? Oct 31 11:18:30 <[florian]> I do not think so Oct 31 11:19:17 i remember putting the option into the driver to reverse them, which is now gone Oct 31 11:19:57 <[florian]> that was a hack and was not required at all Oct 31 11:20:14 there was a good reason for it Oct 31 11:20:39 see, on some devices, they are reversed, but on others, they are not Oct 31 11:21:10 <[florian]> then let's provide detection just like on the wrt54g-like devices and set the config appropriately Oct 31 11:21:28 the preinit.arch determined whether or not they should be reversed Oct 31 11:23:17 also, the option to specify mac address through insmod really should not have been removed, IMHO Oct 31 11:24:33 <[florian]> like I already mentionned that should be solved differently Oct 31 11:24:43 <[florian]> either by directly reading the wlan's eeprom when present Oct 31 11:24:46 <[florian]> or hacking it in userspace Oct 31 11:24:56 <[florian]> specifying the parent device to read it sounds awful Oct 31 11:25:54 the anas350 has no wlan Oct 31 11:26:06 no parent device Oct 31 11:26:25 <[florian]> then the address can be specified on ifconfig up Oct 31 11:26:44 on the ar360w3g and the g570-s, the wlan address is unrelated Oct 31 11:27:20 the factory firmwares for those actually change the wlan address to the eth one, rather than the other way Oct 31 11:27:37 or one off, actually Oct 31 11:29:26 in all cases, factory firmwares set the eth address to whatever it should be from userspace on boot Oct 31 11:35:35 but this is all academic when eth is completely nonfunctional anyway Oct 31 11:37:52 but before we tackle that, check to see whether http://openwrt.pastebin.com/f3512ef23 breaks anything on the ar525w Oct 31 11:38:27 and the r8610 ref board, which you now apparently also have **** ENDING LOGGING AT Sat Oct 31 11:39:06 2009 **** BEGIN LOGGING AT Sat Oct 31 11:39:30 2009 Oct 31 12:06:01 [florian]: any objection to the patch as is? Oct 31 12:06:19 <[florian]> sn9: I see nothing potentially breaking it Oct 31 12:06:38 do you have the ref board? Oct 31 12:06:42 <[florian]> not right now Oct 31 12:06:49 <[florian]> neither have I an ar525w in near Oct 31 12:06:57 <[florian]> I will get them later in the afternoon Oct 31 12:07:10 does the ref board still require parallel-only jtag? Oct 31 12:07:39 <[florian]> I think it does Oct 31 12:07:54 <[florian]> even though I did not play wiht jtag on that board actuall Oct 31 12:07:56 <[florian]> +y Oct 31 12:08:24 does rdc really expect devs to still have a parport? Oct 31 12:09:16 <[florian]> apparently they do Oct 31 12:09:48 <[florian]> their SoC are also pretty old fashioned compared to what exists now with intel Oct 31 12:10:07 <[florian]> and so does the associated development kit & preriquisites Oct 31 12:10:22 are there any parport data sniffers for windows? maybe then their jtag stuff could be ported onto urjtag Oct 31 12:10:57 <[florian]> I do not know of any but you could probably use a virtual machine solution to sniff data Oct 31 12:11:39 i do not know of any that pass parallel Oct 31 12:11:48 <[florian]> vmware does Oct 31 12:12:03 in a sniffable way? Oct 31 12:12:18 <[florian]> it uses ppdev, so I would say yes Oct 31 12:14:24 <[florian]> should be relatively easy to hack ppdev to make it output the data being sent in&out Oct 31 12:14:29 hmm Oct 31 12:14:39 <[florian]> with some chance it might not change the timings too much Oct 31 12:25:21 did you get the ref board directly from rdc, or does someone sell them? Oct 31 12:25:33 <[florian]> rdc sent it to me Oct 31 12:25:40 <[florian]> do you want one? Oct 31 12:26:29 what's on it's flash oob? Oct 31 12:26:35 *itd Oct 31 12:26:37 *its Oct 31 12:26:55 <[florian]> a custom distribution, redhat-based I think Oct 31 12:27:10 and the bootloader? Oct 31 12:27:16 <[florian]> it's redboot Oct 31 12:27:55 is it a 4/16 device? Oct 31 12:28:22 <[florian]> can't exactly remember the exact amount of ram, but 4MB nor flash for sure Oct 31 12:28:56 florian * r18244 /trunk/package/mac80211/Makefile: [package] kmod-libertas needs kmod-lib80211 to load Oct 31 12:29:16 florian * r18245 /trunk/target/linux/olpc/Makefile: [olpc] alway include kmod-libertas by default Oct 31 12:32:07 i think the primary use of the ref board would be to reverse the jtag protocol Oct 31 12:41:00 florian * r18246 /packages/net/tinc/Makefile: [package] update tinc to 1.0.10 (#6045) Oct 31 12:47:05 florian * r18247 /packages/net/aircrack-ng/Makefile: [package] update to aircrack-ng 1.0 (#6047) Oct 31 12:48:48 florian * r18248 /packages/net/mdk3/Makefile: [package] update mdk3 to v6 (#6048) Oct 31 12:52:23 florian * r18249 /packages/net/vsftpd/Makefile: [package] update vsftpd to 2.2.1 (#6055) Oct 31 13:04:56 <_trine> why doesn't luci when you choose it in make menuconfig include a theme even the default one Oct 31 13:05:16 <_trine> is it any use without a theme Oct 31 13:12:14 [florian]: in your most recent tests on the ar525w, did gpio work? Oct 31 13:12:29 e.g. the dmz light Oct 31 13:16:32 <[florian]> sn9: no because mainline maintainers dropped gpio support and I did not take the time to add it back Oct 31 13:16:39 <[florian]> got to run now see you later Oct 31 13:16:50 well, this patch tries that Oct 31 13:17:00 florian * r18250 /packages/net/transmission/Makefile: [package] update transmission to 1.71 (#6056) Oct 31 13:17:23 i think it may be viable to commit it now and deal with fallout later Oct 31 13:18:10 [florian]: ok? Oct 31 16:07:57 <_trine> swapping between luci and webif when compiling trunk does not seem to clear whatever you first compiled Oct 31 16:40:37 mb__: fwiw, it turned out to be exclusively the switch code at fault; your tg3 changes are fine Oct 31 16:41:07 r18214 fixed everything Oct 31 16:54:36 sn9: you got it running? Oct 31 16:54:38 sn9: Awesome, thanks a lot. Oct 31 16:54:54 danage: the wrt350n? yes Oct 31 16:54:55 sn9: Are you interested in preparing the tg3 changes for upstream submission? Oct 31 16:55:11 danage: the anas350? not so much Oct 31 16:55:22 sn9: The corresponding ssb stuff already is upstream Oct 31 16:55:25 mb__: i think they are too kludgey Oct 31 16:55:35 sn9: yeah they need some work Oct 31 16:55:47 so does libphy Oct 31 16:57:38 some of the work needed would require info and/or hardware that i simply don't have access to Oct 31 16:58:52 danage: something [florian] did to the r6040 driver broke ethernet altogether on the anas350 and possibly other devices Oct 31 16:59:10 :) Oct 31 17:00:28 sn9: I don't think the patch is that bad, actually. There's a FIXME, AFAIR. Oct 31 17:00:41 mb__: more than one Oct 31 17:01:02 sn9: The ssb-gige stuff is already upstream Oct 31 17:01:26 sn9: Ok, I can look into it later, but don't hold your breath Oct 31 17:01:37 but isn't the point that the upstream version doesn't work? Oct 31 17:02:16 hm? Oct 31 17:02:25 the point of your patch Oct 31 17:02:41 I think the patch just adapts tg3 to ssb-gige. Oct 31 17:02:54 ssb-gige is more or less a frontent to tg3 Oct 31 17:02:57 but ssb-gige requires tg3 Oct 31 17:03:04 no it's the other way around Oct 31 17:03:20 tg3 works fine on pci without ssb Oct 31 17:03:34 ssb-gige is a ssb->PCI bridge for poor people Oct 31 17:04:09 then what is the bridge for b43? Oct 31 17:04:12 yeah tg3 is a PCI device. ssb-gige is the bridge for connecting it to ssb Oct 31 17:04:23 nothing, b43 is a native ssb device Oct 31 17:04:48 the one in the wrt350n sure looks cardbus to me Oct 31 17:04:59 Yeah you have two ssb busses there. Oct 31 17:05:08 One on the system and one on the wireless card Oct 31 17:05:19 Those are interconnected via PCI. Oct 31 17:05:30 That's a completely different thing (yeah, it's weird ;P ) Oct 31 17:05:59 so, no temporarily swapping wifi cards... Oct 31 17:06:09 sure you can do that Oct 31 17:06:17 The cardbus is a real cardbus. Oct 31 17:06:44 but didn't b43 need ssb mods? Oct 31 17:06:53 ssb (system) -> carbus bridge -> ssb (on wifi card) -> b43 core Oct 31 17:07:06 oh Oct 31 17:07:10 ssb (system) -> ssb-gige -> tg3 Oct 31 17:08:01 so, presumably: ssb (system) -> cardbus bridge -> some other cardbus card Oct 31 17:08:20 yeah that works, too. Although I didn't try it, there's no reason it should not work. Oct 31 17:08:32 In fact the german wrt350n is sold with atheros. Oct 31 17:08:55 the reason is that getting a real cardbus card in there would be quite a physical feat Oct 31 17:09:31 the "german wrt350n" is the v2, which isn't broadcom at all Oct 31 17:09:56 oh it doesn't have a broadcom core? Well I dunno. Oct 31 17:10:09 In any way, the cardbus should be pretty standard. Oct 31 17:10:13 v1 is brcm47xx; v2 is orion Oct 31 17:10:18 ok Oct 31 17:14:11 The reason we need to patch tg3 at all is that the used tg3 version is a stripped down one. It doesn't have a PROM, firmware, etc... It doesn't even store the MAC address in a PROM, so we need to fetch it from elsewhere. Oct 31 17:14:38 yes Oct 31 17:14:43 The mainline tg3 does expect that the device has firmware, PROM, etc... Oct 31 17:15:26 So the patch basically just removes those assumptions depending on whether we're running on a ssb-gige bridge. Oct 31 17:15:52 and puts in assumptions of its own Oct 31 17:16:30 yeah they fucked up the pci posting, so there are a few workarounds added Oct 31 17:17:40 the mdi sense is sledgehammered, too Oct 31 17:18:10 yeah I think there were a few FIXMEs :) Oct 31 17:20:55 all i did in r18214 was port missing code to the 2.6 base that i saw in the 2.4, and it worked automagically; i did it blind, without any clue as to what any of the regs really do Oct 31 17:21:23 cool :) Oct 31 17:22:29 but i left out a bit of code for the 5398 switch, since i have no way to test it with only a 5397 Oct 31 17:23:46 that's why i want bootlogs of r18214 or later from any devices with a broadcom switch, gige or not Oct 31 18:22:10 hm. should installing opkgs work when there is space on /jffs? Oct 31 18:22:51 isn't that the idea? Oct 31 18:23:16 thought so too. Oct 31 18:23:21 details? Oct 31 18:23:33 also -force_space doesnt seem to have affect Oct 31 18:24:00 that's a bug that i fixed a while ago. the fix is not in 8.09.1 yet, but in later versions of the 8.09 branch and trunk Oct 31 18:24:13 its a openwrt8.09 which had RC1 package sources in the opkg config till now Oct 31 18:24:18 changed that to 8.09 Oct 31 18:24:30 classic blue/black wrt54g Oct 31 18:24:56 8.09.2 will be released soon Oct 31 18:25:01 good question.. can i fix it without reflashing the whole? Oct 31 18:25:10 i doubt it Oct 31 18:25:18 *sigh* Oct 31 18:25:24 but you can try sysupgrade Oct 31 18:25:24 as a temporary solution, unpack the .ipk manually Oct 31 18:25:41 it's a .tar.gz that contains another .tar.gz with the package contents Oct 31 18:25:47 need to replace that thingie anyways i guess... the adsl2 caps at ~12mbit Oct 31 18:26:23 if you use trunk with 2.6 on it, you should get much better performance, though wifi still might be a bit flakey Oct 31 18:26:34 are the 8.09 series all binary-compat? Oct 31 18:26:35 nbd: really? Oct 31 18:26:36 dunno how well b43 is working on these things at the moment Oct 31 18:26:49 nbd need solid wifi. with wpa2. thus the old 2.4 kernel Oct 31 18:26:50 better performance? Oct 31 18:27:18 i did quite a few performance optimizations on our 2.6 patch tree Oct 31 18:27:19 without wifi i could use the wl500g should be faster also Oct 31 18:27:37 but those are only in trunk, not in 8.09 Oct 31 18:27:48 roh: the 2.4 wifi driver has its own flakiness, so it's worth a try Oct 31 18:28:16 what brings me to another question.. which wifi-driver do you think is most solid atm for 'host' with wpa2 ? Oct 31 18:28:40 as i just said, you should compare them both Oct 31 18:28:41 madwifi and ath9k should both be working well in trunk Oct 31 18:28:42 sn9 does b43 do wpa2 now? Oct 31 18:28:50 yes Oct 31 18:28:51 imho yes Oct 31 18:29:13 last time i checked my fonera was 'taub' on some channels and also flakey (guess its hw) Oct 31 18:29:22 nbd: discussion is of broadcom hardware atm Oct 31 18:29:28 brmc ive never seen as stable so far Oct 31 18:29:30 *sigh* Oct 31 18:29:50 brcm hw sucks anyway, not just because of the drivers's state Oct 31 18:30:01 which fonera is it? 2100? Oct 31 18:30:05 whats the state with intel wifi? Oct 31 18:30:15 not suitable for access points Oct 31 18:30:25 there are no devices that have intel wifi anyway Oct 31 18:30:30 nbd why now? missing docs? Oct 31 18:30:41 missing docs, braindead firmware Oct 31 18:31:03 there is work on master mode for intel under way, though Oct 31 18:31:06 i thought the fw problem was solved in recent iwl trees Oct 31 18:31:21 what fw problem do you mean? Oct 31 18:31:23 atleast its working much better in client mode now. Oct 31 18:31:47 yeah, but the firmware does way too much, that makes the driver more complicated Oct 31 18:32:01 and it makes adding ap mode support nontrivial Oct 31 18:32:50 roh: which fonera do you have? Oct 31 18:32:51 note that i haven't actually looked at the fw, this is just the impression that i get from reading discussion among linux wireless hackers Oct 31 18:32:59 sn9 oldest one, with a cooler Oct 31 18:33:04 passive Oct 31 18:33:17 have you tried a recent version of openwrt on it Oct 31 18:33:18 roh: is it running openwrt? Oct 31 18:33:29 nbd not in a test long enough Oct 31 18:33:43 last time was around 8.09 release Oct 31 18:33:45 try current trunk on it Oct 31 18:33:47 ok, because the wifi drivers have improved a lot compared since 8.09 Oct 31 18:34:03 try with both madwifi and ath5k, and compare Oct 31 18:34:05 still madwifi or ar9k? Oct 31 18:34:12 ath5k doesn't work on soc yet Oct 31 18:34:23 i've been working on patches for that Oct 31 18:34:26 ah.. so only madwifi there Oct 31 18:34:29 for now Oct 31 18:34:30 they're 80% complete, but not functional yet Oct 31 18:34:34 i don't think it's a 9k device; is it? Oct 31 18:34:39 no, it's not Oct 31 18:34:45 madwifi, then Oct 31 18:36:28 hm. did that get better (stability)? Oct 31 18:36:40 in openwrt, yes Oct 31 18:36:44 should have Oct 31 18:36:51 the openwrt madwifi has diverged a lot from madwifi trunk Oct 31 18:36:57 i see Oct 31 18:37:34 btw, i notice that dd-wrt now apparently fully supports the ramips SoC's that juhosg has been working on Oct 31 18:38:09 sn9: their port is based on the old ralink sources, though, not on openwrt code Oct 31 18:38:25 so, they use 2.4? Oct 31 18:39:04 no Oct 31 18:39:05 2.6 Oct 31 18:39:11 ralink has 2.6 sources Oct 31 18:43:41 sn9: speaking of iwlagn, you have intel 5300 card too, don't you? i seem to be having problems with 802.11n Oct 31 18:44:13 the intel card simply doesn't go above 54mbit with my fritzbox (atheros wifi) Oct 31 18:45:14 it seems to be a cfg80211 issue, wrong regdomain (it shows none in dmesg), can you point me towards a solution? Oct 31 18:47:07 danage: works for me, but then, i have the default regdomain Oct 31 18:47:19 my card is the 5350 Oct 31 18:59:02 sn9: which wifi chipset is your ap? Oct 31 18:59:21 the one i am using atm has rt61 Oct 31 18:59:42 but i have used the card elsewhere Oct 31 18:59:45 with n Oct 31 19:00:06 dang Oct 31 19:00:31 i should try whether the windows driver behaves differently before i start poking Oct 31 19:01:08 the windows driver seems more limited to me Oct 31 19:02:32 can i change the regdomain at runtime? is re-association sufficient then? Oct 31 19:03:59 dunno; never tried Oct 31 19:14:06 hm.. any comments on this?: http://lists.qi-hardware.com/pipermail/developer/2009-October/000907.html Oct 31 19:14:15 ever seen renesas wifi? Oct 31 19:15:49 never seen it anywhere Oct 31 19:19:13 well.. needs to get into openwrt anyways now it seems ;) Oct 31 19:19:35 the driver looks like it could easily be beaten into shape Oct 31 19:20:01 on a first glance it doesn't look as bad as most other vendor drivers Oct 31 19:25:54 jap Oct 31 19:30:05 looks like something generally worth supporting, since they're competing with huge vendors Oct 31 19:30:40 agreed. especially since there are so few embedded chipsets (low power) Oct 31 19:46:13 are they a/b/g/n? what? Oct 31 19:46:24 it doesn't seem to say Oct 31 19:56:42 i guess bg only Oct 31 19:57:18 static const long frequency_list[] = { 2412, 2417, 2422, 2427, 2432, 2437, 2442, Oct 31 19:57:33 2447, 2452, 2457, 2462, 2467, 2472, 2484 }; Oct 31 19:59:33 n could also operate with 2.4-only Oct 31 20:03:05 yes. but needs multiple antennas and a shitload of power. Oct 31 20:03:33 such cards are for devices with <1W total power draw. stuff used in routers uses >1W wifi alone Oct 31 20:10:32 juhosg * r18251 /trunk/target/linux/ixp4xx/ (8 files in 2 dirs): ixp4xx: remove bogus 'eth%d: MII PHY x on NPE-x' messages Oct 31 20:10:35 juhosg * r18252 /trunk/target/linux/ixp4xx/ (4 files in 2 dirs): ixp4xx: the missing phy_disconnect call has been added in upstream, remove that patch Oct 31 20:45:19 larsc: ERROR: please fix package/feeds/packages/xorg-kdrive/Makefile Oct 31 20:45:32 that's you, right? Oct 31 20:53:03 i guess Oct 31 21:31:57 who can commit this? http://openwrt.pastebin.com/f18ab0e4 Oct 31 23:01:42 [florian]: are you back+ Oct 31 23:01:45 ? Nov 01 00:09:15 nbd: this fixes a failsafe issue on vanilla wrt54gl's: http://openwrt.pastebin.com/f18ab0e4 Nov 01 00:12:07 nbd: commit? Nov 01 00:14:12 corrects a miscalculation i made in r18214 Nov 01 00:17:35 will take care of it in a minute Nov 01 00:53:47 sn9: nope, no wrt350n here Nov 01 00:55:59 Bartman007: i forgot why i asked Nov 01 01:03:23 Bartman007: since nbd doesn't seem to be committing that patch, and you're back... Nov 01 01:03:56 fixes a failsafe issue on vanilla wrt54gl's: http://openwrt.pastebin.com/f18ab0e4 Nov 01 01:04:00 corrects a miscalculation i made in r18214 Nov 01 01:09:58 agb * r18253 /trunk/target/linux/brcm-2.4/base-files/etc/preinit.arch: [brcm-2.4] fix failsafe, was accidentally broken by r18214. Thanks Daniel Gimpelevich Nov 01 01:12:48 that just leaves http://openwrt.pastebin.com/f3512ef23 Nov 01 01:12:55 for now Nov 01 01:16:27 Bartman007: if i understand [florian] correctly, that which this patch could possibly break is already broken anyway Nov 01 01:19:05 namely, gpio support Nov 01 02:04:32 sn9: so that patch readds support for AMIT and ZyXEL devices, and attempts to fix gpio (but you aren't sure if that works?) Nov 01 02:04:50 right Nov 01 02:06:00 it definitely allows the Airlink101 ANAS350 (same board as the AMIT MGB111) to boot Nov 01 02:06:48 would you mind splitting the patch into seperate device support and gpio patches? Nov 01 02:08:28 device support and gpio patch require each other to compile Nov 01 02:10:26 besides, [florian] wants to move to a newer kernel anyway; this patch is but an intermediate step Nov 01 02:10:32 ok. is there any significant barrier to testing the functionality of gpio then? Nov 01 02:11:22 grrr Nov 01 02:11:24 the only model where gpio was fully implemented was the ar525w, so that's what it needs to be tested on Nov 01 02:11:26 3am already Nov 01 02:12:06 blogic: move over here to "the land of the free," it's only 7pm Nov 01 02:13:35 Bartman007: i thought you were in the us :) Nov 01 02:13:42 blogic: zing. Nov 01 02:14:15 is germany really any better? Nov 01 02:14:20 no Nov 01 02:14:29 i never claimed to be in a free country Nov 01 02:14:56 i have some free drivers though :D Nov 01 02:15:18 for ar7? Nov 01 02:15:26 I wouldn't trust someone to drive my limo for free Nov 01 02:15:52 sn9: ifxmips Nov 01 02:17:06 also good Nov 01 02:17:36 sn9: yes Nov 01 02:19:39 this patch should also be tested on the rdc dev board **** ENDING LOGGING AT Sun Nov 01 02:59:56 2009