**** BEGIN LOGGING AT Tue Apr 13 02:59:56 2010 Apr 13 06:25:32 hey guys- i was wondering if you had some recommendations regarding a 802.11N router? i'm hoping it's supported by openwrt or tomato Apr 13 08:25:51 Do I get it right that there is currently no way to boot openwrt with nfsroot without make kernel_menuconfig? Apr 13 08:28:12 <[florian]> you get it right Apr 13 08:28:32 <[florian]> enabling nfs client and ip autoconfig in the kernel is part of the things I want to do Apr 13 08:28:56 <[florian]> but which can probably be better achieved using preinit stuff and booting a ramdisk kernel which in turns mounts its nfsroot and pivot on it Apr 13 08:35:34 Nfsroot is usually used during development. Probably the sinplest way - adding an option to the menuconfig to enable nfs in the kernel, would be acceptable by most users. Apr 13 08:35:59 <[florian]> that's actually fine with me Apr 13 10:23:49 cshore * r20836 /packages/net/freeswitch/ (5 files in 3 dirs): net/freeswitch: Updated to 1.0.6 (which allowed to eliminate patches), fixed network failure on startup, fixed OOM on exit, and moved logging of fs console output to file (on /tmp) instead of to syslog Apr 13 12:32:35 hi hackers :) i successfully finished porting OpenWrt to a new hardware platform called OpenRISC/Alekto. i used the kamikaze trunk, and did the patches for kernel 2.6.32. how can i become a developer and add the code to the official svn? Apr 13 12:33:12 please submit patches to the openwrt-devel list Apr 13 12:39:14 nbd: how should i include all files and folders located in "target/linux/alekto"? should i attach them as a compressed archive (7zip)? Apr 13 12:39:34 svn add them so they'll be included in the aptch Apr 13 12:39:40 *patch Apr 13 12:40:00 <[florian]> qecko: if your target is openrisc, use target/linux/openrisc Apr 13 12:40:18 <[florian]> qecko: in order to match the kernel conventions Apr 13 12:40:36 <[florian]> qecko: one could very well use your port with the openrisc simulator Apr 13 12:41:55 florian: there are two platforms called openrisc... so there might be confusions if i name my port "openrisc" Apr 13 12:42:19 <[florian]> qecko: one is or1k, the other I do not know Apr 13 12:42:32 <[florian]> qecko: ok, then let's go for alekto, we will sort this out later Apr 13 12:43:55 jow_laptop: i have no svn account yet :( - just anonymous access Apr 13 12:44:09 qecko: svn add is a client side operation Apr 13 12:44:35 yes, but i cannot commit them Apr 13 12:44:53 therefore you should send the output of svn diff to the ml Apr 13 12:45:11 ah okay... thats what i wanted to know :) Apr 13 12:46:42 florian: this is the device i did the port for: http://www.visionsystems.de/produkte/6802.html Apr 13 12:47:02 <[florian]> qecko: to be frank, do not expect having svn account until we have a chance to review your patch, we do not give svn accounts like this Apr 13 12:48:13 florian: sure, thats really not the problem :) i just didn't know how to get all of my work the the svn now Apr 13 12:48:41 <[florian]> ok, that was just to tell you how we usually work ;) Apr 13 12:52:22 I think I have found a way of using broadcom wifi cards on the rs(pro) - but it's ugly (and I can't think of a non ugly way ;) Apr 13 12:52:33 florian: hmm there are two possible wlan-cards which i've tested... one is ralink 2561, which is not that stable but it works. this card needs binary drivers from the vendor. i do not add them now cz i'm not sure about the licensing stuff Apr 13 12:53:01 atheros card works fine (like expected) Apr 13 12:53:23 <[florian]> qecko: does not rt2x00 work with the ralink card? Apr 13 12:56:20 florian: it's rt61-pci (which also enables rt2x00)... yes it works but sometimes the reloading of the binary driver fails. and the wireless performance was better on atheros. so i'm using ath5k right now Apr 13 12:56:31 <[florian]> qecko: ok Apr 13 14:07:25 acoul * r20837 /trunk/include/ (image.mk kernel-defaults.mk): Apr 13 14:07:25 finalize lzma/jffs2 support (currently not enebled by default, for kernels >=2.6.33) based on Edgar Soldin patches: Apr 13 14:07:25 https://lists.openwrt.org/pipermail/openwrt-devel/2010-March/006550.html Apr 13 14:21:05 Can someone commit the patch in #7134. It fixes a typo in preinit / mount_root Apr 13 14:22:24 ure Apr 13 14:22:25 sure Apr 13 14:22:40 nbd: thank you Apr 13 14:25:00 nbd * r20838 /trunk/package/base-files/files/sbin/mount_root: fix jffs2 and mini_fo mount in failsafe (patch from #7134) Apr 13 14:37:07 <{Nico}> cshore: ping Apr 13 14:37:51 pong {Nico} Apr 13 14:38:58 <{Nico}> regarding your recent FS update, why do you log to /tmp ? Apr 13 14:39:52 florian: okay, i submitted my patches for OpenRISC/Alekto to the development mailling list :) thank you until now... Apr 13 14:40:09 <[florian]> qecko: thanks, will review! Apr 13 14:40:39 fine - it was a lot of work but OpenWrt really rocks :) Apr 13 14:40:44 I was finding the console logging spams the limited syslog Apr 13 14:41:13 <{Nico}> cshore: another thing: ac_cv_func_setpgrp_void="yes" in CONFIGURE_ARGS is superfluous, already defined in ./include/site/linux Apr 13 14:41:21 ok Apr 13 14:41:40 <{Nico}> cshore: sure, but now it's spamming /tmp which is in ram Apr 13 14:42:08 I realized that ... after I committed Apr 13 14:42:40 I think what I really need to do is to do some UCI option to let the user decide Apr 13 14:43:22 <{Nico}> would be great Apr 13 14:44:23 for the application I'm using it for, we will log to USB and use logrotate Apr 13 14:46:13 I noticed there were other log files going there, which is why I put the console log to /tmp, but I'll have to investigate if FS can be made to log to syslog for the non-console logs too Apr 13 15:28:22 "ifup -a" have a possible undesired behaviour. It calls "ifdown -a", then "ifup x" for each interface, which also calls "ifdown x". So we'll have two ifdown calls for each interface. Apr 13 15:30:00 That is solved by changing /sbin/ifup, placing the line "/sbin/ifdown "$@"" after the "all interfaces" block Apr 13 15:30:23 <[florian]> nunojpg: can you send a patch to the mailing-list for this? Apr 13 15:31:46 nbd: ping Apr 13 15:31:56 (I'm on the patch team, just asking if it is really a problem, or just a stupid idea) Apr 13 15:32:20 anybody have a clue to log DEBUG to /var/log/debug in openwrt so i can debug a process Apr 13 15:34:25 http://page.mi.fu-berlin.de/jgorski/openwrt/wip/trunk/0008-ar71xx-Make-Broadcom-cards-usable-on-RS-RS-Pro.patch <- request for comments ;) (this "fixes" #6801) Apr 13 15:36:46 <[florian]> KanjiMonster: it is not elegant ssb_set_arch_fallback_sprom should also do it Apr 13 15:43:58 [florian]: but from where? I would like to keep it in ssb code to not have to have all ssb code in kernel (I could do that from the main.c from ssb) Apr 13 15:44:28 <[florian]> KanjiMonster: why do not you do it "ala" brcm63xx where the fake sprom is registered by architecture code in arch/mips/bcm63xx? Apr 13 15:45:03 [florian]: you mean in in the rspro setup in mach-ubnt.c? Apr 13 15:45:15 <[florian]> KanjiMonster: yes Apr 13 15:45:49 as I said, this has the side effect that I have to include the whole ssb driver in the kernel and cannot keep it as a module anymore Apr 13 15:46:25 <[florian]> why would you keep it as a module anyway? Apr 13 15:46:50 <[florian]> but wait, broadcom cards is not the default setup right? Apr 13 15:46:55 yes Apr 13 15:47:04 the rs pro is atheros ar71xx Apr 13 15:48:02 with just mini pci slots - using broadcom cards is probably a quite unlikely cornercase anyway Apr 13 15:48:51 <[florian]> ask mb__ when he shows up about what he thinks about this solution Apr 13 15:51:24 I also have no problem if this doesn't make it into openwrt - the at most three people stumbling over this problem probably know how to patch and build an image themself ;) Apr 13 15:51:45 <[florian]> I would like to introduce as little differences with upstream as we can ;) Apr 13 15:51:56 <[florian]> especially on this field as I have seen other people adding sprom-related modifications Apr 13 15:52:34 it wouldn't be needed if reading the sprom through pci wouldn't fail Apr 13 15:52:57 <[florian]> did you find out why it failed? Apr 13 15:53:04 unfortunately no Apr 13 15:53:05 <[florian]> maybe it is not at the expected location Apr 13 15:53:15 <[florian]> do you follow linux-wireless? Apr 13 15:53:18 nope Apr 13 15:57:31 this was more a case of I had the card lying around (its from an asus wl-500gp, now with an atheros card) and wanted to play around with it Apr 13 16:56:49 anyone getting errors during luci compile/install? Apr 13 17:08:32 cshore: details? Apr 13 17:09:41 xMff: I'm doing a distclean. I think it's because I selected luci, then deselected everything, then as modules, and then selected again (by components, not meta-packages). I don't think it like that. Apr 13 17:10:13 cshore: yeah, its rebuild handling is broken, package/luci/clean should be enough though Apr 13 17:10:44 I think this might be more of a menuconfig issue Apr 13 17:11:03 it sometimes gets confused Apr 13 17:43:12 jow * r20839 /branches/backfire/package/base-files/files/sbin/mount_root: [backfire] merge r20838 Apr 13 18:01:48 nbd * r20840 /trunk/target/linux/ar71xx/image/Makefile: ar71xx: fix image builds (broken by r20834) Apr 13 18:22:53 [florian]: I just remembered, I looked at the pci code and it at least /seemed/ ok (bar0 or bar1, whichever it was, was correctly set to 0x10001000 address space, and access to it was also enabled in the pci control register of the card) Apr 13 18:55:30 cshore: can you review my /etc/init.d/rcS patch please? Apr 13 19:16:18 <[florian]> KanjiMonster: ok Apr 13 19:17:08 otoh, I really don't know pci stuff ;) Apr 13 19:17:22 trial and error ftw :P Apr 13 19:17:28 evening / timezone all Apr 13 19:17:50 all my knowledge I got from looking at the pci 2.3 specification Apr 13 19:18:44 <[florian]> is that even public? Apr 13 19:19:48 [florian]: Yep, pci express is not. Apr 13 19:20:07 Unless you know where to look. ;) Apr 13 19:20:21 <[florian]> yeah :p Apr 13 19:21:30 xMff: or if cshore can't review it... Apr 13 19:22:04 it looks good to me, but I haven't got commit access. Apr 13 19:22:23 I can do packages and brcm63xx Apr 13 19:22:52 I also would like to stash it in a build Apr 13 19:23:08 cshore: maybe just replying to the patch email saying it looks good with be enough for one of the core devs to commit it then. how big is the set of people having commit rights? Apr 13 19:23:40 There aren't very many who are around a lot Apr 13 19:24:02 <[florian]> philipp64: is the patch entitled "Option to allow boot to run to completion before starting shell" ? Apr 13 19:24:07 yes Apr 13 19:24:34 <[florian]> allright, it looks fairly obvious so I will push it with a bunch of other changes ;) Apr 13 19:24:41 <[florian]> anything else I should add? Apr 13 19:25:44 I'll be testing the kexec stuff soon....right now I'm fixing Alice Gate image creation and working on freeswitch Apr 13 19:26:53 <[florian]> ok, thanks! Apr 13 19:27:49 yes Apr 13 19:57:28 florian * r20841 /trunk/package/base-files/files/etc/init.d/rcS: (log message trimmed) Apr 13 19:57:28 [package] option to allow boot to run to completion before starting shell Apr 13 19:57:28 Setting the system variable "foreground" to yes causes the system to run Apr 13 19:57:28 the init scripts in series and wait for completion. Apr 13 19:57:28 This is useful if (a) you don't want the user getting into the console Apr 13 19:57:29 until the system is initialized, or (b) you have things going on in your Apr 13 19:57:30 scripts that require strict ordering (and no possible race conditions). Apr 13 20:11:52 acoul * r20842 /trunk/include/kernel-version.mk: update kernel checksums Apr 13 20:52:42 lars * r20843 /trunk/target/linux/mx2/ (3 files in 3 dirs): [mx2] vp6500: Add backlight device Apr 13 20:55:33 nunojpg: ping Apr 13 20:55:41 pong Apr 13 20:55:54 about the wrt160nl issues Apr 13 20:55:58 anything interesting in the kernel log? Apr 13 20:56:00 yes Apr 13 20:56:12 dmesg? I sent the full to the mailing list Apr 13 20:56:42 dmesg: http://pastebin.com/144KEgJ5 Apr 13 20:56:43 ah, missed that Apr 13 20:57:03 you missed the mailing list discussion? Apr 13 20:57:11 i overlooked the dmesg post Apr 13 20:57:24 someone suggested that is a flash issue... Apr 13 20:57:32 can you try latest? Apr 13 20:57:55 I tried this morning latest Apr 13 20:58:02 do you want now latest? Apr 13 20:58:11 no, this morning latest is enough Apr 13 20:58:21 dmesg is from this morning Apr 13 21:08:10 please compile ath9k with debug info Apr 13 21:08:20 and rmmod ath9k, then insmod ath9k debug=0xffffffff Apr 13 21:08:23 then check the kernel log Apr 13 21:15:46 please direct me:) Apr 13 21:15:59 where do I set ath9k to compile with debug? Apr 13 21:16:14 there's an option "ath9k debugging" next to the module selection in make menuconfig Apr 13 21:16:28 kernel modules? Apr 13 21:16:35 yes Apr 13 21:16:55 once you've selected that, run make package/mac80211/{clean,compile} V=99 Apr 13 21:17:04 and install the new kmod-ath_* and kmod-ath9k_* packages, then reboot Apr 13 21:17:14 after that: rmmod ath9k; insmod ath9k debug=0xffffffff Apr 13 21:17:17 I will just compile with all... Apr 13 21:17:22 *it all Apr 13 21:18:40 sure Apr 13 21:19:16 building, news in 30m Apr 13 21:34:47 [florian]: ping Apr 13 21:37:01 acoul * r20844 /trunk/ (3 files in 2 dirs): don't use lzma/jffs2 on <2.6.33, set lzma/jffs2 as default for >=2.6.33. switch verbose mode on compresor statistics. Apr 13 21:45:07 acoul * r20845 /trunk/target/linux/generic-2.6/patches-2.6.34/008-jffs2_make_lzma_available.patch: add lzma/jffs2 patches for 2.6.34 Apr 13 22:30:30 nbd: ping Apr 13 22:31:07 nunojpg: pong Apr 13 22:31:34 insmod ath9k debug=0xffffffff don't produce any special log... Apr 13 22:31:37 also on dmesg? Apr 13 22:32:06 logread? Apr 13 22:34:15 jow * r20846 /trunk/target/linux/brcm-2.4/base-files/etc/init.d/netconfig: [brcm-2.4] add Buffalo WHR-G125 specifc switch quirks to netconfig, shorten code by merging identical fixes Apr 13 22:34:21 after rmmod ath9k I notice ath9k_common and ath9k_hw are still loaded Apr 13 22:34:27 shall they be removed also? Apr 13 22:35:22 jow * r20847 /branches/backfire/target/linux/brcm-2.4/base-files/etc/init.d/netconfig: [backfire] merge r20846 Apr 13 22:35:28 ath9k is enough Apr 13 22:36:26 "failed to initialize/probe failed with error 5" Apr 13 22:36:32 dmesg output is the same as before Apr 13 22:37:13 i.e., also the same as on the begining of the log, when the debug mode is still not engaged Apr 13 22:38:01 did you reflash the whole thing? Apr 13 22:38:09 yes Apr 13 22:38:24 fresh checkout, debug enabled, flash Apr 13 22:38:25 and you had cleaned the mac80211 package before rebuilding? Apr 13 22:38:27 ah, ok Apr 13 22:38:42 can i see your .config? Apr 13 22:40:56 http://pastebin.com/7igAdGZJ Apr 13 22:41:43 (by the way, the other unit failed on flash, I will recover it later, I'm now using another unit, same problem...) Apr 13 22:41:59 oh, apparently another config option is missing: "Atheros wireless debugging" Apr 13 22:42:05 somewhere in the same area Apr 13 22:42:21 enable that, clean and rebuild the mac80211 package, reinstall only kmod-ath and kmod-ath9k Apr 13 22:42:30 no need to reflash the whole thing Apr 13 22:43:19 sorry, I had no idea... Apr 13 22:43:25 Will post the result tomorow Apr 13 22:44:14 taking the opportunity of talking to you, how is the vlan support on this thing? it works? I've seen the switch sections but couldn't use them... Apr 13 22:45:22 it does not use vlan by default Apr 13 22:45:27 but you can enable it if you want to Apr 13 22:45:36 do check if failsafe is working before trying that, though ;) Apr 13 22:46:29 ok, vlan is what I need to take one port from the switch and create a wan2? Apr 13 22:46:36 how would that be enabled? Apr 13 22:49:20 create two vlans Apr 13 22:49:27 one for the lan, one for wan2 Apr 13 22:49:31 enable vlan globally Apr 13 22:49:35 set both vlans to tagged on the cpu port Apr 13 22:49:44 replace eth0 with eth0.1 or whatever for lan Apr 13 22:49:47 etc Apr 13 22:50:08 ok, so just tweaking the network config file...I did that, but didn't work Apr 13 22:50:09 btw. could you please run another quick test with the ath9k module today? Apr 13 22:50:13 will try harder... Apr 13 22:50:15 it should only take a few minutes Apr 13 22:50:24 and i would like to push out a new patch series to linux-wireless soon Apr 13 22:50:27 ok, I will Apr 13 22:50:30 thanks Apr 13 22:50:36 give me a few minutes Apr 13 23:11:31 nbd: the patch allowing mtd to flash partitions spanning partial erease blocks was from you, right? Apr 13 23:11:40 yes Apr 13 23:12:11 nbd: does this actually work: must either start or end on erase block boundary ? Apr 13 23:12:34 nbd: or are only partitions smaller then an erease block supported? Apr 13 23:12:54 and this message simply slipped in Apr 13 23:13:15 nbd: because I get this: 0x000000008000-0x0000003f0000 : "firmware" Apr 13 23:13:16 mtd: partition "firmware" must either start or end on erase block boundary or be smaller than an erase block -- forcing read-only Apr 13 23:13:22 rtz: I'll bet only the squashfs and jffs2 have to start and end on an erase boundary Apr 13 23:13:39 erease block size is 10000 Apr 13 23:14:05 cshore: well, it's the target for sysupgrade Apr 13 23:14:46 nbd: this is a .32 kernel Apr 13 23:15:17 i think i didn't cover all cases Apr 13 23:15:25 it was mainly intended for partitions smaller than an erase block Apr 13 23:16:07 nbd: I have this stupid 32k config partition before the actual firmware partition ... Apr 13 23:16:14 nbd: I will take a look at the patch Apr 13 23:17:22 nbd: http://pastebin.com/NkB7JKjw Apr 13 23:17:58 ok, thx Apr 13 23:18:08 will look into it Apr 13 23:25:37 i have no idea why it only broke with the new rev Apr 13 23:25:45 i found a bug that looks like it was there before as well Apr 13 23:27:00 hm... or maybe not Apr 13 23:34:38 ah, found it Apr 13 23:37:51 will commit a fix in a few minutes, currently sorting out the issue with the guy that broke it ;) Apr 13 23:47:44 nico * r20848 /trunk/package/mac80211/patches/701-tracepoint_include_linux_version_h.patch: package/mac80211: add a patch to fix package/carl9170 build failure Apr 14 00:09:29 nbd * r20849 /trunk/package/mac80211/ (19 files in 2 dirs): mac80211: update to wireless-testing 2010-04-13, add some more fixes for the ar9300 patch set, fixes #7135 Apr 14 00:10:24 nunojpg: the wrt160nl bug should be fixed now Apr 14 00:33:34 nbd: you still here? Apr 14 00:33:40 yes Apr 14 00:34:42 nbd: regarding this function: https://dev.openwrt.org/browser/trunk/package/mtd/src/trx.c#L46 Apr 14 00:35:01 nbd: isn't it kinda useless? Apr 14 00:35:19 nbd: it doesn't adjust the trx length field Apr 14 00:35:53 nbd: and it's only called from jffs2 code Apr 14 00:35:54 it's not useless Apr 14 00:36:01 but you're right, adjusting the length as well would be better Apr 14 00:36:53 nbd: well, the code inside the kernel should have already adjusted the trx length to exclude the jffs2 partition Apr 14 00:37:03 nbd: or it will do so on next reboot Apr 14 00:37:23 nbd: so, when comes this function into play? Apr 14 00:37:25 this fixup was intended for sysupgrade only Apr 14 00:37:37 because sysupgrade integrates jffs2 data directly after the squashfs Apr 14 00:37:41 which affects the crc Apr 14 00:37:46 so without fixup, next reboot would be too late Apr 14 00:38:21 nbd: ahhh, right Apr 14 00:38:22 got it Apr 14 00:38:29 nbd: thanks for the explaination Apr 14 00:40:34 nbd: do you know, if sysupgrade on the wrt160nl with the new bootloader works? Apr 14 00:41:00 nbd: because for what I see, the trx crc doesn't get fixed up there Apr 14 00:41:21 no idea Apr 14 00:41:33 it probably won't work Apr 14 00:41:33 it probably doesn't Apr 14 00:41:38 :) Apr 14 00:41:50 same problem on the ar525w Apr 14 00:42:14 I see, this needs a more generic approach Apr 14 00:45:50 cshore * r20850 /trunk/target/linux/brcm63xx/files/arch/mips/include/asm/mach-bcm63xx/bcm_tag.h: tools/firmware-utils/imagetag: Fixed Pirelli Alice Gate CRC calculation in imagetag (was invalid strings in bcm_tag.h). Closes #7120 Apr 14 00:46:47 nbd: can you commit that for backfire? Apr 14 00:48:33 it's actually a couple of typos in id strings in code I wrote that prevent Alice Gate's from getting usable images Apr 14 00:50:25 nbd * r20851 /branches/backfire/target/linux/brcm63xx/files/arch/mips/include/asm/mach-bcm63xx/bcm_tag.h: [backfire] backport Pirelli Alice Gate CRC calculation fix from r20850 Apr 14 00:50:44 nbd: thanks Apr 14 01:06:12 jow_laptop: the tm2300v1 could actually have gotten removed from r20846, it's covered further down/was added later iirc on line 154 Apr 14 02:35:58 nbd * r20852 /trunk/package/mac80211/patches/300-ar9300_support.patch: ath9k: fix a crash in ath9k_hw_reset on older hw **** ENDING LOGGING AT Wed Apr 14 02:59:56 2010