**** BEGIN LOGGING AT Mon Feb 16 02:59:58 2009 Feb 16 03:27:37 i'm trying to update to new compat-wireless, revising patches and such. Anyone know what I'm missing? Feb 16 03:27:37 make[4]: Entering directory `/home/OpenWRT/44/trunk/build_dir/linux-ar71xx/compat-wireless-2009-02-14' /home/OpenWRT/44/trunk/build_dir/linux-ar71xx/compat-wireless-2009-02-14/config.mk:56: *** "ERROR: Your >=2.6.27 kernel has CONFIG_MAC80211 disabled, you should have it CONFIG_MAC80211=m if you want to use this thing.". Stop. Feb 16 03:35:18 my knowledge of makefiles is limited, but i got past this with "make CONFIG_MAC80211=*" Feb 16 03:40:20 RoundSparrow: you probably need 'make kernel_menuconfig' and make sure MAC80211 is chosen as module? Feb 16 03:40:36 before you compile compat-wireless? Feb 16 03:41:52 apparently compat-wireless is checking kernel's configuration, as it's built outside the kernel, which is a normal procedure Feb 16 03:46:22 xxiao: but if I leave compat-wireless on 2009-02-07 it goes fine, it is with 2009-02-15 that this happens Feb 16 03:48:28 RoundSparrow: are you just grabbing the newest compat and building it against build_dir/linux, or is there some work done in openwrt for this package? i'm interested in giving it a try Feb 16 03:49:38 by the way, my ar71xx board's ath9k sta mode can never connected to n-mode router, with g-mode it goes at 1mbps, i'm not sure if n-mode every worked now Feb 16 03:49:55 s/every/ever/ Feb 16 03:50:40 some work, here it is: http://openwrt.pastebin.com/m64560e7a Feb 16 03:51:58 the patch to deal with bad mac address had to be reworked, but I did the work. also delete package/mac80211/patches/340-ath5k_txpower_2413.patch for it to compile correctly, that patch hasn't be rebased (it applies, but the compile fails) Feb 16 03:56:27 ok i will give it a shot later (need use windows for finance stuff now) Feb 16 03:58:55 RoundSparrow: have you ever tried to use Tew652's n-only-mode(stocked firmware) to see if you can connect a ath9k sta to it? mine could not Feb 16 03:59:22 yha, I got 1mb Feb 16 03:59:32 but that was driver a couple weeks ago Feb 16 03:59:45 actually I was running the DIR-615 firmware in n-only Feb 16 04:00:03 RoundSparrow: so you made sure tew652ap is n-only-mode, not mixed-mode right? just double-check Feb 16 04:00:04 make sure you don't set channel in station, it sticks to it! Wasted 30 minutes one time on that last week Feb 16 04:00:09 yes Feb 16 04:00:27 (I had assumed channel setting was ignored in station mode, mistake ;) ) Feb 16 04:01:08 I tried when set to 20/40, n-only, fixed channel (6)... was able to connect like a G Feb 16 04:01:11 without no encrypt, i believe we need not wpa_supplicant for the testing Feb 16 04:01:20 but again, this was 15 to 20 days ago. with encryption Feb 16 04:01:26 that patch I posted includes that Feb 16 04:02:04 RoundSparrow: good to know that, i can only connect my airlink usb 80211n to n-mode at tew652, not my Litestation board with 9160 minipci radio card(ath9k) Feb 16 04:02:27 g-mode is fine though, still low speed at 1mbps, i'm using trunk Feb 16 04:02:39 also make sure use only AES with N, it is required by N standard Feb 16 04:03:09 forgot to say that my minipci has no antenna yet, low speed is expect, but at least it should associate with AP (n-only) as i put them really close Feb 16 04:03:34 thanks for the AES tip Feb 16 04:03:40 juhosg says he didn't see the 1mbps rate, which I don't get, as you are the third person to confirm it. Feb 16 04:04:12 but I think if we focus on this 1mbps rate that other things will improve... as it is an obvious and basic problem Feb 16 04:04:37 if station mode isnt' working the same as it does on desktop x86 linux, then something is clearly not right Feb 16 04:06:05 Agree. The rate it reported is 1mbps, iperf showed at about 800kbps Feb 16 04:06:57 have you seen reboot issues in station mode? Feb 16 04:07:18 RoundSparrow: not yet, quite reliable since yesterday i began to try sta mode Feb 16 04:07:21 mine just reboots at times shortly after associating - especially if I leave wifi enabled and start the router (andlet it join and associate onboot) Feb 16 04:07:43 or it freezes up where the serial console stops responding Feb 16 04:07:46 again it's g-mode as n-mode never worked Feb 16 04:08:06 I encourage you to do "rmmod ath9k; insmod ath9k; wifi up" 20 times and see if you get a freeze or reboot Feb 16 04:09:11 will try that, meanwhile i never fully know how to set up ht_capab Feb 16 04:09:44 ht (high -througput?) Feb 16 04:10:18 I don't know if anyone has properly detailed and reviewed that for the specific ar9102 chip... and I don't think it impacts station mode at all. I'm not sure how you specify N vs G in station mode Feb 16 04:10:28 I don't know Feb 16 04:10:40 I know the values have to match the particular chip in use Feb 16 04:10:54 xMff: FOUND THE ISSUE Feb 16 04:11:06 RoundSparrow: hey did you tried building TrendNet firmware for your router ? Feb 16 04:11:10 LOOK Feb 16 04:11:22 If someone ever try to build a CPP app Feb 16 04:12:08 they need to make sure the makefile does not have a -nostdinc++ Feb 16 04:12:08 flag Feb 16 04:12:09 guess i need read ath9k source to get that. on sta mode, i remove "option hwmode 11g", i don't know how to set n mode. what i did is to set tew652 n-only and see if sta can associate, which it could not. but my usb-airlink-adapter can do that Feb 16 04:12:09 gramulhao - with that package, no I assumed you were getting help from xMff and went on to compat-wireless issues Feb 16 04:12:24 RoundSparrow: no wireless issues dude Feb 16 04:12:34 my issue is with dansguardian Feb 16 04:12:42 RoundSparrow: though you had wireless issues Feb 16 04:12:45 :P Feb 16 04:12:50 xxiao: gramulhao says he gets 20Mbps ... don't know how ;) Feb 16 04:12:54 RoundSparrow: I was just trying to get the latest to get faster :P Feb 16 04:12:59 RoundSparrow: I do get 20Mbits Feb 16 04:13:09 652BRP as AP and laptop as client Feb 16 04:13:10 cleartext Feb 16 04:13:18 it's 19.5Mbits Feb 16 04:13:33 tested transfering a 69MB File Feb 16 04:14:02 gramulhao: are you running openwrt on 652brp or trendnet's gpl source 2,6.15? Feb 16 04:15:17 xxiao: OpenWRT Feb 16 04:15:26 xxiao: I could not build TrendNet GPL Feb 16 04:15:33 I tried but didn't work Feb 16 04:16:16 gramulhao: that's great to hear then....but, how can you be sure it's n-mode instead of g-mode? Feb 16 04:17:11 it's g mode Feb 16 04:17:25 I saw 54Mbits Feb 16 04:17:45 iwconfig showed 54Mbits Feb 16 04:18:06 all that I did extra was getting the svn from linux-wireless Feb 16 04:18:29 but I haven't tested with the original SVN from openwrt Feb 16 04:18:34 so It may be as fast Feb 16 04:18:44 I'm going to test when I get dansguardian to work Feb 16 04:19:49 RoundSparrow: if you hear about someone building TrendNet GPL successfully please let me know Feb 16 04:20:41 gramulhao: i see, now one more reason to try linux-wireless's git head Feb 16 04:21:16 yep I did here Feb 16 04:21:19 it worked fine Feb 16 04:24:26 gramulhao: a guy on dd-wrt used trendnet to build modules for his tplink, and http://wiki.x-wrt.org/index.php/Trendnet_TEW-632BRP setup a SVN site Feb 16 04:24:45 RoundSparrow: I did got his SVN Feb 16 04:24:49 RoundSparrow: but it does not build Feb 16 04:25:25 gramulhao: another option is to seriously look over the WNR2000 firmware, as they used OpenWRT white russian as the base for the firmware, on the same 2.6.15 kernel as the trendnet... so in theory... should be able to build things for the Trendnet Feb 16 04:25:31 yha, i couldn't get his SVN to build :) Feb 16 04:27:13 I'm putting my efforts into ath9k and making lots of noise for Atheros to release the damn source code for the madwifi for the AP81 routers!! Feb 16 04:27:24 RoundSparrow: how far did you get yours to go ? Feb 16 04:27:47 I didn't go very far, I'm very early in my Linux kernel learning Feb 16 04:28:43 I get close to vmlinux Feb 16 04:30:52 jow * r14526 /trunk/package/kernel/modules/video.mk: [package] add kmod for 2.6.26+ in-kernel uvc video driver (#4637, thanks moh_de) Feb 16 04:33:26 jow * r14527 /packages/multimedia/linux-uvc/Makefile: [packages] rename external uvc driver to video-uvc-obsolete (#4637, thanks moh_de) Feb 16 04:34:29 writ the guy running the svn, he has been responsive on things Feb 16 04:39:06 I sent him an e-mail Feb 16 04:39:23 now I'm going to sleep Feb 16 04:39:26 good night guys Feb 16 04:48:09 jow * r14528 /trunk/package/dnsmasq/ (Makefile patches/101-ipv6.patch patches/102-rtnetlink.patch): [package] update dnsmasq to 2.47 (#4636, thanks florida) Feb 16 13:50:18 is the one called Bartman007 alive and present? Feb 16 13:50:46 I'm still looking for a real exiting openwrt xen solution :) Feb 16 14:58:45 phaidros: bartman007 is probably bussy with some other work Feb 16 15:04:35 blogic, ping Feb 16 15:08:39 juhosg: compat-wireless patch for ath9k MAC updated for 2009-02-15 http://openwrt.pastebin.com/m15af2936 - the ath5k patch needs a lot of rework, I just deleted it so I could build. Feb 16 16:48:31 * loswillios pokes CIA-31 Feb 16 17:18:16 compat-wireless 2009-02-16 compiles fine with the change to patch for ath9k: http://openwrt.pastebin.com/m15af2936 and the removal of the at5k TXPOWER patch (I did not port that patch, it applies but breaks compile) Feb 16 17:28:45 RoundSparrow: ? Feb 16 17:31:50 yo? Feb 16 17:37:18 johnrw: ping Feb 16 17:37:27 gramulhao: yes? Feb 16 17:37:41 RoundSparrow: hey I'm still fighting with the dansguardian here Feb 16 17:37:42 :P Feb 16 17:38:35 gramulhao: From what I read on your progress so far, I don't really think I can be much help. It seems like a general package/Openwrt issue and nothing specific to this platform. I'm trying to keep my attention focused on porting OpenWRT to the newer N devices Feb 16 17:39:14 RoundSparrow: I'm trying to learn more about debugging Feb 16 17:39:14 does dansguardian have a developer mailing list / forum - enlist help there? Try in OpenWRT x86 in a virtual machine and see if you have the same problems? Feb 16 17:39:35 RoundSparrow: looks like the issue is in it's calls to zlib Feb 16 17:40:16 gramulhao: I think it will be a case of the blind leading the blind here ;) I'm focused on learning hardware, networking and u-boot Feb 16 17:40:37 I did read all of what you were doing, I think just I'm not much use at the moment Feb 16 17:40:48 no problem Feb 16 17:40:57 I was just telling you Feb 16 17:41:21 ok, did you find a developer of that project? Feb 16 17:42:27 RoundSparrow: I did Feb 16 17:42:42 RoundSparrow: it is mostly a zlib problem Feb 16 17:42:51 something related to it Feb 16 17:43:06 the issue happens when I get gzip encoded websites Feb 16 17:43:31 at some point it worked proper in OpenWRT history? Feb 16 17:43:42 maybe review svn checkins for zlib and try older one Feb 16 18:06:58 gramulhao: just did a quick look at dnsguardian, is n't that software to be running on some high-end hardware instead of AP boxes? Feb 16 18:10:35 i still have two mac related build patches open with ticket numbers #4562 and #4571. some bored developer wants to take a look at them? Feb 16 18:11:26 xxiao: not really Feb 16 18:11:31 thx juhosg Feb 16 18:11:31 xxiao: look at packetprotector.org Feb 16 18:14:54 gramulhao: so..you want to compile it for a different hardware? Feb 16 18:15:57 xxiao: yesp Feb 16 18:16:16 xxiao: it compiles and runs on the tew-652brp Feb 16 18:16:36 gramulhao: then what's the problem you're fighting on? Feb 16 18:16:39 xxiao: but I'm having an issue website uses conten-encode gzpi Feb 16 18:16:41 gzip Feb 16 18:19:23 gramulhao: what means "issue"? they are not loading? Feb 16 18:19:49 fzwoch: it's giving ENCODE Error in the browser Feb 16 18:20:20 somehow the data is coming from the website Feb 16 18:20:31 but it's not handled properly Feb 16 18:20:38 and only 4 bytes arrive at the browser Feb 16 18:21:02 I did packet inspection and headers are sent well Feb 16 18:21:54 the sites load fine if dansguarden is disabled? Feb 16 18:21:58 yes Feb 16 18:22:26 fzwoch: the site loads fine with dansguardian when I build it for Brcm44 Feb 16 18:22:39 uh.. Feb 16 18:23:42 they are both mipsel targets aren't they? Feb 16 18:23:53 MIPSel / MIPS Feb 16 18:24:43 do you have a packet sniff available to compare the working/non-working cases? Feb 16 18:26:16 fzwoch: yes Feb 16 18:26:21 fzwoch: tcpdump ready Feb 16 18:26:46 fzwoch: the non-working case I receive for 4 bytes from dansguardian Feb 16 18:26:57 public to take a look at them? Feb 16 18:27:03 yes Feb 16 18:27:08 i assume he MTU fix option is enabled? Feb 16 18:27:11 just in case.. Feb 16 18:28:25 packet_capture is dansguardian side to the browser Feb 16 18:28:39 packet_capture_4 is server -> dansguardian Feb 16 18:29:53 fzwoch: you can see google.com works then newegg fails and then google.com again Feb 16 18:30:15 newegg.com is in the middle Feb 16 18:36:50 gramulhao: i'm not super firm with the http protocol but i think the newegg request does not come with a content-length field? Feb 16 18:37:30 fzwoch: don't think so but that is not required Feb 16 18:38:33 gramulhao: the data at least seems to be send. there are 3 packets following your HTTP OK response from newegg Feb 16 18:39:05 fzwoch: are you talking about the first or second trace ? Feb 16 18:39:23 lookign at the _4 Feb 16 18:39:47 ah.. i see.. let me take a look at th eother Feb 16 18:40:39 98 6.038773 192.168.3.135 192.168.3.140 HTTP Continuation or non-HTTP traffic Feb 16 18:41:07 fzwoch: on _4 you see the whole request that should work properly Feb 16 18:41:23 fzwoch: on the other file you see the failure Feb 16 18:41:34 98 6.038773 192.168.3.135 192.168.3.140 HTTP Continuation or non-HTTP traffic Feb 16 18:41:47 that's dansguardian replying to the browser 4 bytes empty Feb 16 18:42:19 gramulhao: yes i can see it. looks like all data got truncated. the whitespace control data is there but not conent :/ Feb 16 18:45:18 gramulhao: so it does work normally for another device but not for the other? Feb 16 18:45:28 fzwoch: exactly Feb 16 18:45:36 fzwoch: it runs fine on my asus Feb 16 18:45:56 fzwoch: I want to replace the asus to the 652brp because the BRP is 400Mhz Feb 16 18:46:02 fzwoch: the asus is 266Mhz Feb 16 18:46:26 the package versions are the same for both? Feb 16 18:46:35 fzwoch: yes Feb 16 18:46:49 I tried older too Feb 16 18:47:07 gramulhao: i think it might require debugging onto the package :/ Feb 16 18:47:21 fzwoch: I can give you access to my building environment if you have 5 minutes Feb 16 18:47:51 to look at it Feb 16 18:48:04 uhm i haven't done debbuing on openwrt directly yet :) Feb 16 18:48:19 do you wanna try ? Feb 16 18:49:08 i don't see that a debugging enviroment is installed on those systems? probablybecause of size limitations Feb 16 18:49:20 fzwoch: I have strace only Feb 16 18:50:58 i think gdb and dansguardian compiled with debug symbols would be neccessary. dunno if that is doable in a feasable fashion for openwrt. Feb 16 18:51:27 fzwoch: it's easier to modify to sources and watch what happens Feb 16 18:51:38 fzwoch: it's not that big Feb 16 18:51:50 use remote debugging Feb 16 18:52:01 remote debugging ? Feb 16 18:52:24 I use strace -f dansguardian -N |nc 192.168.1.135 1099 Feb 16 18:52:39 is that remote debugging ? Feb 16 18:52:40 hehehe Feb 16 18:52:51 yeah, you can have the symbols on the remote system Feb 16 18:52:55 I think Feb 16 18:54:47 I've only tried kgdb stuff myself, but afaik the concept is similiar Feb 16 18:55:22 see gdbserver Feb 16 18:55:59 with strace you should t least see if the zlib library could be loaded (i guess it is nt compiled statically in the application) Feb 16 18:56:20 fzwoch: it's loading fine Feb 16 18:58:19 fzwoch: maybe zlib version Feb 16 18:58:31 fzwoch: I'm reading the code to try to get the exactly call for zlb Feb 16 18:58:34 zlib Feb 16 19:00:15 perhaps zlib is working. i mean. it does send you the page that means it passes filtering? also it should then pass through the page data. or does it rencode zlib compression? Feb 16 19:04:26 fzwoch: it sends the same ENCONDED if there was no filtered data Feb 16 19:04:35 fzwoch: it sends un-encoded if there was any modification Feb 16 19:08:44 gramulhao: so there was no filtered data but it fails to pass through the data.. Feb 16 19:09:04 fzwoch: yep Feb 16 19:09:13 docbody->setDecompress(docheader->contentEncoding()); Feb 16 19:09:26 it's cpp so it's kinda weird to find the things Feb 16 19:09:31 I see that it calls that Feb 16 19:10:13 but all that it setDecompress is: void setDecompress(String d) { decompress = d; }; Feb 16 19:11:12 I cannot find a call to decompress Feb 16 19:14:15 it escapes from my logic Feb 16 19:14:31 docbody->setDecompress(docheader->contentEncoding()); Feb 16 19:15:10 for me that means CALL docbody->setDecompress ( passin as parameter "gzip" ) Feb 16 19:15:31 Good day all. If I do an svn co https://svn.openwrt.org/openwrt/branches/8.09, will that be RC2? or do I need svn co https://svn.openwrt.org/openwrt/branches/8.09_RC2 Feb 16 19:15:40 docheader->contentEncoding() has gzip I checked it Feb 16 19:15:48 but I cannot find a proper function to decompress Feb 16 19:16:01 pitbullpc: the branch is mostly rc2 but had some minor updates since then Feb 16 19:16:27 gramulhao: DataBuffer.cpp:304 looks like the line that might happen to you Feb 16 19:16:57 RoundSparrow, juhosg: How did you fix this *** "ERROR: Your >=2.6.27 kernel has CONFIG_MAC80211 disabled, you should have it CONFIG_MAC80211=m if you want to use this thing.". Stop? Feb 16 19:17:12 thanks, i'm not an svn expert yet. so the next question may be trivial. will an svn up on the 8.09 bring in those 'minor updates'? Feb 16 19:17:13 happens with the new compat-wireless juhosg just checked in Feb 16 19:17:39 fzwoch: what version of the code you are looking ? 304 here has if (!sock->writeToSocket("\r\n\r\n", 4, 0, timeout)) Feb 16 19:18:04 pitbullpc: going with branches/8.09 is a good idea if you want to be close to 8.09 Feb 16 19:18:15 gramulhao: yes, thats the data you actually receive in the pcap capture. Feb 16 19:18:22 pitbullpc: yes Feb 16 19:18:41 fzwoch: the 4 bytes you mean Feb 16 19:18:49 "\r\n\r\n" Feb 16 19:19:10 gramulhao: yep. but don't ask me why. go back from there why buffer_length might be 0 Feb 16 19:19:22 xMff: good, I'm hoping one of those minor updates addresses a missing crtsavres.o when compiling for PowerPC Feb 16 19:20:09 fzwoch: ConnectionHandler.cpp:2122 Feb 16 19:20:10 s/^/#/ in config.mk:56 fixed it :) Feb 16 19:20:24 fzwoch: that's where it plays with the compression Feb 16 19:21:11 fzwoch: docbody->setDecompress(docheader->contentEncoding()); Feb 16 19:21:21 fzwoch: 2126 Feb 16 19:22:01 pitbullpc: powerpc? is that amcc p40x? Feb 16 19:22:42 actually a Freescale MPC8313E RDB Feb 16 19:22:44 gramulhao: have you tried compiling with DGDEBUG defined? it looks like it prints out some intresting data Feb 16 19:23:00 core is an e300 Feb 16 19:23:11 ah, juhosg updated the .configs already Feb 16 19:23:18 fzwoch: I did Feb 16 19:23:41 sending cache search request: Awww.newegg.com Feb 16 19:23:41 is compressed Feb 16 19:23:41 Decompressing as we go..... Feb 16 19:23:42 gzipM Feb 16 19:23:42 -1 Feb 16 19:27:17 -1 does sound like an error doesn't it? :) Feb 16 19:27:48 fzwoch: that's why I'm trying to find the function that uncompresses Feb 16 19:28:08 hmm Feb 16 19:28:12 let me thing Feb 16 19:28:26 think Feb 16 19:28:54 gzipM <-- is this M a windows new translation error? Feb 16 19:29:26 strange Feb 16 19:29:37 some control character in my joe Feb 16 19:30:18 fzwoch: not a problem it is the \r Feb 16 19:30:31 I see the \M everywhere Feb 16 19:30:32 matein4 * r14529 /trunk/target/linux/ixp4xx/patches-2.6.28/ (185-mi424wr_support.patch 310-gtwx5717_spi_bus.patch): Switch to old SPI GPIO implementation. Feb 16 19:30:45 gramulhao: thats ok then i guess Feb 16 19:30:50 yep Feb 16 19:31:19 pitbullpc: is it in openwrt yet? i don't recall i saw anything from freescale in openwrt yet Feb 16 19:31:41 nope, i'm in the process of adding it Feb 16 19:31:52 pitbullpc: i see.. cool Feb 16 19:36:46 yay, success with p54 and AP mode :) Feb 16 19:44:15 juhosg * r14533 /trunk/package/mac80211/patches/ (6 files): [package] mac80211: reorder patches Feb 16 19:45:17 phaidros: hi. I've only used openwrt as an hvm domU, and not in any real manner, just general testing Feb 16 19:45:49 hvm? Feb 16 19:46:51 i know less about the current state of xen than about other virtualizers, but that kinda looks like a typo of "kvm" Feb 16 19:47:10 sn9: hardware virtualisation, not para Feb 16 19:47:46 sn9: ^^^^ requires Intel VT or AMD SVM on the processor, allows you to run unmodified operating systems Feb 16 19:48:00 Bartman007: too bad - we're trying to make some openwrt appliances but no luck so far with self-baked xen domu paravirt kernels, next try is to implant some distro domu-kernels we'll see how it goes Feb 16 19:48:25 PVM (or PV) Xen domains run a "Xen-aware" kernel, provides more flexibility and better performance Feb 16 19:48:46 speaking of kvm, when i tried an openwrt guest under kvm, it could not handle the virtualized cpu, but kqemu worked fine on the same machine Feb 16 19:49:24 xMff: haven't tried it with pvops, that would give you paravirt capabilites. Feb 16 19:49:55 not clear so far if it is a xen bug or the openwrt kernel :/ Feb 16 19:50:06 hi Bartman007 :) Feb 16 19:50:16 hey Feb 16 19:50:45 sn9: interesting. kvm is neat, but it doesn't appear to allow seamless virtualizatio like some of the other solutions out there Feb 16 19:50:53 RoundSparrow: hey Feb 16 19:50:58 phaidros: what are you seeing? Feb 16 19:51:03 sk Feb 16 19:51:25 define "seamless" Feb 16 19:51:53 sn9: feed it a disk image containing any OS and it "just works" Feb 16 19:52:38 it does when i do it Feb 16 19:53:00 Bartman007: I basteld to much with the config script .. cannot reproduce right now ^^ Feb 16 19:54:19 sn9: I haven't looked at KVM since 2.6.26 so things are probably better, but i had run across a guest compatibility list that noted issues with various guest operating systems Feb 16 19:54:57 could be PEBKAC, could be growing pains of a new virtualization solution. Feb 16 19:54:59 it was a work in progress Feb 16 19:55:59 last i checked, xen hvm was considerably less mature Feb 16 19:56:59 sn9: quite possibly, but like your experience with kvm, my experience with xen hvm has been successful with everthing I've tried (which hasn't been much) Feb 16 19:58:01 kvm is more efficient, but xen hvm is more versatile Feb 16 19:59:08 I'm considering switching to openvz+kvm though, openvz results in less overhead than xen or kvm which would be nice for the trun snapshot generation (which is on linux anyway) and kvm is in the mainline kernel so has a lot of eyes looking over it. Feb 16 20:01:26 Bartman007: it never actually occured to me to use a kvm guest for an openvz kernel -- what an inrteresting thought Feb 16 20:02:05 sn9: no, using openvz+kvm on the host so I can run instances under kvm or openvz Feb 16 20:03:14 kvm is just a module Feb 16 20:04:43 yeah... I'd be using kvm on an openvz kernel, maybe the term openvz+kvm is confusing but it made sense in my mind. Feb 16 20:10:15 nevertheless, openvz under kvm would solve certain inconveniences... Feb 16 20:10:49 Ok, anyone seen this before: Feb 16 20:10:49 make[4]: Entering directory `/mnt/share/work/Koos/EduRadio-WAP/OpenWRT/trunk/build_dir/linux-mpc8313erdb/madwifi-trunk-r3314' Feb 16 20:10:49 scripts/get_arch.mk:51: *** ARCH mismatch: supplied "powerpc", determined "ppc". Stop. Feb 16 20:10:49 make[4]: Leaving directory `/mnt/share/work/Koos/EduRadio-WAP/OpenWRT/trunk/build_dir/linux-mpc8313erdb/madwifi-trunk-r3314' Feb 16 20:10:50 make[3]: *** [/mnt/share/work/Koos/EduRadio-WAP/OpenWRT/trunk/build_dir/linux-mpc8313erdb/madwifi-trunk-r3314/.built] Error 2 Feb 16 20:10:53 make[3]: Leaving directory `/mnt/share/work/Koos/EduRadio-WAP/OpenWRT/trunk/package/madwifi' Feb 16 20:10:55 make[2]: *** [package/madwifi/compile] Error 2 Feb 16 20:12:06 pitbullpc: what kernel version is used? Feb 16 20:12:13 2.6.28 Feb 16 20:14:04 looked at https://svn.openwrt.org/openwrt/trunk/scripts/ i could not find "get_arch.mk", where can I have a look at it? Feb 16 20:14:20 is it from madwifi? Feb 16 20:14:27 good question. i'm looking for it now Feb 16 20:15:10 the newer kernel is powerpc only, ppc will not work anymore Feb 16 20:16:02 i'm not trying to use ppc. I specifically specify powerpc in my target/linux/mpc8313erdb/Makefile Feb 16 20:16:44 find . -name "get_arch.mk" Feb 16 20:16:59 i don't know where/how get_arch.mk is determining my arch to be ppc Feb 16 20:17:24 ./trunk/build_dir/linux-mpc8313erdb/madwifi-trunk-r3314/scripts/get_arch.mk Feb 16 20:17:38 from madwifi then Feb 16 20:18:32 http://madwifi-project.org/browser/madwifi/trunk/scripts/get_arch.mk Feb 16 20:19:50 pitbullpc: i think you need svn up your madwifi to get the fix Feb 16 20:20:08 pitbullpc: at least to 3935 svn Feb 16 20:20:24 you're using r3314 which does not work with 2.6.28 kernel Feb 16 20:24:29 svn up doesn't seem to be doing anything Feb 16 20:25:24 keeps telling me I am rev 14534, which doesn't even correspond to the madwifi rev Feb 16 20:26:36 Miko: howdy Feb 16 20:26:39 Mirko: howdy ;) Feb 16 20:29:55 pitbullpc: probably openwrt has an old madwifi svn, well try to get the newest get_arck.mk from http://madwifi-project.org/browser/madwifi/trunk/scripts/get_arch.mk and give it a shot Feb 16 20:30:09 keep the rest untouched should be fine Feb 16 20:30:54 i have three 8315 boxes here and would like to add them to openwrt when i have spare cycles Feb 16 20:30:55 pitbullpc: openwrt uses a specific version of madwifi with lots of patches added Feb 16 20:31:18 ok, i'll try that. I am wondering what would be the best path forward. Working with kamikaze and a 2.6.26 kernel or trying trunk with 2.6.28? Feb 16 20:31:25 xMff: the get_arch.mk is just a one liner change for powerpc/ppc naming, should not hurt Feb 16 20:31:34 ok Feb 16 20:31:40 xxiao: yep was about to suggest the same Feb 16 20:31:51 looks like a fallout from the ppc platform merge Feb 16 20:32:57 xMff: buildroot has 8540 support(though does not work last time i tried to build), there should be plenty 85xx network boxes, wondering why openwrt does not include that yet Feb 16 20:33:34 guess it's too expensive for the public... Feb 16 20:35:42 i saw a link on beagleboard-openwrt-git before, anyone has the link? want to see how it goes Feb 16 20:36:24 i saw nbd there, that's about one month ago Feb 16 20:53:00 Ok, a manual patch of the madwifi get_arch.mk gets me through the madwifi build Feb 16 21:31:28 yay, openwrt on xen as pvm runs :) Feb 16 21:49:23 anyone know what the root filesystem staging directory is? Feb 16 21:49:57 not without looking Feb 16 21:51:01 do you know if it gets removed during the process? Feb 16 21:56:08 Hmm, looks like if it ever existed it is gone before make finishes :( Feb 16 21:56:25 strange.. is there any known issue why the bit rate of my wlan device changes every few seconds? Feb 16 21:56:46 54, than 5.5, than 1 than 54 again Feb 16 21:57:15 its a 8.09 rc2 on bcm43 Feb 16 21:57:55 the wifi connection is damn slow, max. around 140kb/s Feb 16 21:59:43 fish_: you might wanna try trunk, which has more recent drivers Feb 16 22:00:46 pitbullpc: it gets removed during make, but stays there afterward Feb 16 22:03:48 hey guys Feb 16 22:03:57 anyone knows what -nostdinc++ does ? Feb 16 22:04:31 sn9: i don't think i follow. How does it get removed AND stay there? Feb 16 22:04:41 gramulhao: that means do not use standard c++ header files Feb 16 22:05:07 i don't understand what there is not to follow Feb 16 22:06:00 xxiao: yes but what would be the impact ? Feb 16 22:06:04 loswillios: well, maybe tomorrow with one of my other buffalos. but this one is my 'productive' one, i dont really want to use trunk on it Feb 16 22:06:05 would C++ work ? Feb 16 22:06:25 loswillios: but i just want to know if anyone already knows that Feb 16 22:06:27 or this is to replace with uclibc++ ? Feb 16 22:07:06 sn9: so, i presume that rootfs staging directory is created during the image building process. However, when the build process is over. I find no traces of the rootfs staging dir. Hence, i believe it is getting created and removed from the time make is called and when make finishes. Is this correct? Feb 16 22:07:19 gramulhao: as far as i can recall, that's meant for c++ libraries built Feb 16 22:07:30 no, it is still there when make finishes Feb 16 22:07:57 hmmm, well it if is, I sure can't locate it Feb 16 22:07:57 gramulhao: when you build c++ libraries, don't search the standard c++ header files (e.g. usr/include/c++) Feb 16 22:08:09 xxiao: nice Feb 16 22:08:12 going to keep that Feb 16 22:08:31 pitbullpc: i would need to look to find it, but it's in build_* Feb 16 22:08:56 let me try again Feb 16 22:09:27 pitbullpc: what are you trying to achieve in the end? Feb 16 22:10:40 holy cow, i found it. It was pretty deep: trunk/build_dir/linux-mpc8313erdb/base-files/ipkg/base-files-mpc8313erdb/etc Feb 16 22:10:56 anyway, i am debugging an 'init not found' right now Feb 16 22:11:20 pitbullpc: look into package/base-files/files Feb 16 22:11:34 appears that there is an init script in /, that calls /etc/preinit Feb 16 22:11:47 /etc/preinit calls /sbin/init Feb 16 22:12:01 so, i'm trying to determine why my kernel is claiming no init found? Feb 16 22:12:46 maybe init is disabled somehow in busybox? Feb 16 22:12:48 i was looking for the staging directory so i could see the layout Feb 16 22:13:10 shouldn't be. i haven't touched any busybox stuff yet Feb 16 22:13:20 so everything should be as provided **** ENDING LOGGING AT Mon Feb 16 23:03:53 2009