**** BEGIN LOGGING AT Mon Nov 15 02:59:58 2010 Nov 15 04:14:37 cshore * r24000 /trunk/tools/firmware-utils/src/imagetag.c: [tools] brcm63xx: imagetag: Fixed occaisonal wrong CRC in image due to using strncpy to copy the CRC into the imagetag. strncpy stops copying after a 00 byte, memcpy doesn't. Nov 15 04:50:42 cshore: you seem to be awake Nov 15 04:51:03 i've run into an odd issue Nov 15 05:07:23 what's that? Nov 15 05:28:40 never mind, solved it, but i have a new one Nov 15 05:42:35 build #24 of etrax is complete: Failure [failed compile_3] Build details are at http://tksite.gotdns.org:8010/builders/etrax/builds/24 Nov 15 05:43:36 new boot log: http://www.gimpelevich.san-francisco.ca.us/danielg4/booting.log Nov 15 05:43:50 no ethernet interfaces or wifi Nov 15 05:47:32 hello Nov 15 06:25:15 [florian]: Wipster's 973-cpmac_handle_mvswitch.c patch in ticket 3782 does NOT work, and seems to have no effect Nov 15 06:25:35 <[florian]> sn9: that's still work in progress, so if you want to help debug it, welcome Nov 15 06:25:51 well, gotta have ethernet some way... Nov 15 06:26:07 new boot log: http://www.gimpelevich.san-francisco.ca.us/danielg4/booting.log Nov 15 06:27:33 [florian]: thoughts? Nov 15 06:31:39 <[florian]> sn9: it looks like the switch driver cannot reset it, I am searching for places where it is attempting that Nov 15 06:32:40 <[florian]> sn9: can you try increasing the timeout value in mvswitch_wait_mask from mvswitch.c? Nov 15 06:33:05 <[florian]> sn9: previously, tnetd7200 was also running at 145Mhz, now that the clock has been fixed, I am not sure all timings are respected Nov 15 06:34:54 [florian]: what did you think of the X86_GENERIC patch for the L1 cache size? Nov 15 06:35:29 [florian]: what should i increase it to? Nov 15 06:38:44 <[florian]> sn9: the int it = 100; at the beginning Nov 15 06:38:58 it's already 100 Nov 15 06:39:21 <[florian]> sn9: that's what you should try to change, to 1000 for instance Nov 15 06:39:24 ok Nov 15 06:39:48 <[florian]> sn9: and put an udelay or mdelay after the check for r == val Nov 15 06:40:12 how long an mdelay? Nov 15 06:41:32 <[florian]> philipp64|laptop: looks okay Nov 15 06:41:39 <[florian]> sn9: 1 or 10 should be fine Nov 15 06:41:59 <[florian]> sn9: I will double check with nbd to see why he has not added *delay functions Nov 15 06:43:58 i'll use 1, and temporarily printk the value of i when r == val Nov 15 06:54:25 [florian]: still times out; i will try an mdelay of 10 Nov 15 06:54:53 <[florian]> sn9: it could be something else, but I doubt phy detection would have worked Nov 15 06:55:53 should i try something else? Nov 15 06:56:13 <[florian]> sn9: try to increase the timeout values and then we will think of something else Nov 15 06:56:20 <[florian]> sn9: is your switch really a marvell 88e6060? Nov 15 06:56:44 yes Nov 15 07:12:05 [florian]: still times out with an mdelay of 10 and i = 10000 Nov 15 07:12:31 that's almost two minutes, ya know Nov 15 07:13:18 <[florian]> yep, then it's something else Nov 15 07:24:32 danage: hello Nov 15 07:25:16 hi sn9 Nov 15 07:30:21 [florian]: btw, the timeout increase was with Wipster's patch. try without? Nov 15 07:41:57 <[florian]> sn9: this should not change anything, the bigger the better Nov 15 07:53:18 [florian]: I have looked further into my problem, and narrowed it down to http://git.kernel.org/?p=linux/kernel/git/torvalds/linux-2.6.git;a=commitdiff;h=24824a09e35402b8d58dcc5be803a5ad3937bdba which adds the netdevice.h include, breaking the uclibc build Nov 15 09:03:54 acoul * r24001 /trunk/target/linux/generic/ (config-2.6.36 config-2.6.37): linux/generic: add a missing symbol. (thank you kaloz) Nov 15 09:10:51 acoul * r24002 /trunk/target/linux/generic/config-2.6.37: target/linux: add some 2.6.37 missing symbols. (thank you maddes) Nov 15 09:13:09 hello Nov 15 10:35:34 jow * r24003 /branches/backfire/package/ (4 files in 4 dirs): [backfire] merge r22629 Nov 15 10:35:49 xMff: cheers Nov 15 10:59:51 <_trine> [florian], have you any idea why asterisk 14 is seg faulting now in trunk Nov 15 11:00:54 <_trine> I did a complete reload of trunk so it was perfectly clen and asterisk 14 still seg faults on my wrt160nl ar71xx Nov 15 11:01:16 <_trine> clean* Nov 15 11:03:09 _trine: as xMff suggested, have you tried downgrading uClibc to 0.9.30 ? Nov 15 11:03:37 <_trine> yes Nov 15 11:03:38 hi there Nov 15 11:03:41 <_trine> it was the same Nov 15 11:04:03 anybody played with RTL8305SB switch chips before? Nov 15 11:11:54 <_trine> stintel, do you think upgrading to uclibc 9.32 would be worth a try Nov 15 11:12:57 _trine: I actually don't think so, I'm quite sure it'll break more than it'll fix ;-) Nov 15 11:13:22 _trine: well, run asterisk through gdb or gdb-server, file a ticket and attach the backtrace Nov 15 11:13:28 and hope for the best Nov 15 11:13:47 roh: no, but i wrote a driver for RTL8306SD once, i think they're similar Nov 15 11:21:17 shouldnt this be default disabled "[*] Enable IPv6 support in packages " if no ipv6 support enabled? Nov 15 11:21:32 because of such stuff with netstat -a: netstat: /proc/net/tcp6: No such file or directory Nov 15 11:21:34 nbd nice. i was looking for some sample code which drives the smi Nov 15 11:21:46 else i will try to add a eeprom with the 'correct content' Nov 15 11:21:59 crow: that was discussed earlier, global ipv6 support should not depend on kmod-ipv6 Nov 15 11:22:06 got a nice small 5port switch which i want to do 802.1q tagging/untagging Nov 15 11:22:31 smi is really weird. looks quite different to i2c Nov 15 11:24:19 xMff ok then i will add a note to myself and local build howto :) Nov 15 11:25:03 the reasoning is that kmod-ipv6 can be installed or not but stuff like busybox not Nov 15 11:26:06 ok i get it now, well in my case i dont need ipv6 (dont have it from isp) so i will disable compile with --enable-ipv6 in packages.. Nov 15 11:27:14 roh: you have the datasheet, right? Nov 15 11:27:35 crow: why btw? I don't think it saves that much space Nov 15 11:28:01 my ISP is IPv4 only but 6to4 / 6in4 works everywhere Nov 15 11:28:08 *only too Nov 15 11:29:15 because i dont like outputs like http://openwrt.pastebin.com/6SEFxU0z Nov 15 11:29:29 k Nov 15 11:30:02 well how to use 6to4 or 6in4, any benefit if isp is only IPv4 ? Nov 15 11:31:04 well the benefit is that you have ipv6, that allows you to have public ipv6 ips for all your hosts Nov 15 11:31:28 compared to the single dynamic ipv4 you usually get Nov 15 11:31:33 acoul: ping Nov 15 11:31:46 xMff it isnt that i dont like, but actualy playing a bit in my free time with openwrt, tried 2.6.36 on asus wl500gp v1, booted fine glad i didnt tried it before because of #7693 Nov 15 11:32:23 nbd yes. Nov 15 11:32:41 pong Nov 15 11:32:44 xMff that sound for me right now as a salat, will try to read more about it, thinking that there is no much benefit in home use? Nov 15 11:32:53 nbd i guess i only was confuses because smi and i2c share the same io pins but are totally different protocols Nov 15 11:34:10 crow: depends. for home use it probably does not matter Nov 15 11:34:37 acoul: 2.6.37 seems to break uClibc compilation Nov 15 11:35:16 it might actually be a good thing to get some hands-on ipv6 experience, *before* we run out of IPv4 addresses Nov 15 11:35:23 yes I've noticed that Nov 15 11:37:34 @KanjiMonster: you can build uClibc on 2.6.36 and then switch to 2.6.37 until we get a patch for this issue Nov 15 11:39:56 acoul: hm, okay. I'll try that. I already looked at the kernel commit that broke it; If I understand C correctly, just pretending to have netdevice.h included like with the linux/types.h won't work Nov 15 11:51:58 xMff weird is that i disabled that --enable-ipv6 in packages but netstat seems still looks for that ipv6 directory/files Nov 15 11:52:35 not every package understands --ebable-ipv6 / --disable-ipv6 Nov 15 11:52:42 # Package build options ; # CONFIG_IPV6 is not set Nov 15 11:56:08 ah this is included CONFIG_BUSYBOX_CONFIG_FEATURE_IPV6=y Nov 15 11:56:17 and busybox comes with nestat if i recall Nov 15 12:15:08 nbd: you around? ticket 3782 now seems to hinge on code you wrote Nov 15 12:17:07 nbd: http://www.gimpelevich.san-francisco.ca.us/danielg4/booting.log Nov 15 12:24:10 acoul: I'll correct myself, it does work; at least it compiles now. I can't test until evening (in europe ;) whether it actually runs, but at least it compiles Nov 15 12:31:11 <_trine> trunk isnt compiling at the moment Nov 15 12:31:17 acoul * r24004 /trunk/target/linux/generic/ (6 files in 2 dirs): linux/generic: update to layer7-2.22 for kernels >=2.6.36 Nov 15 12:32:30 acoul: If you are interested, I can create a patch now, else I create one later when I have verified it works (assuming bcm63xx boots with 2.6.37-rc1 ;) Nov 15 12:32:39 <_trine> http://dpaste.com/275476/ Nov 15 12:33:28 [florian]: any more ideas while i was asleep? Nov 15 12:35:50 @KanjiMonster: sure, patches are always welcomed ;-) Nov 15 12:36:05 acoul: hm, okay, doesn't work, the same error comes up when compiling dnsmasq Nov 15 13:18:07 [florian]: i found something Nov 15 13:18:16 acoul: since some packages need to be updated, I'll wait with patches until all compile (it looks like the breakage is dnsmasq's "fault", it should break with glibc too; the rule seems to be for 2.6.37 if you include linux/rtnetlink.h, include linux/if.h and not libc's net/if.h) Nov 15 13:18:47 <[florian]> sn9: ah, tell me about it? Nov 15 13:20:32 [florian]: if you notice, the mvswitch code prefixes printk's with "eth%d" and that %d is taken care of in cpmac_probe, which is called only AFTER the mvswitch code Nov 15 13:20:56 [florian]: hopefully this is the last obstacle before I can finally compile a git kernel ;) Nov 15 13:22:41 <[florian]> sn9: that %d is because netdev_register has not been called yet, so the ethernet device has not been given an index yet Nov 15 13:22:44 so, which should be inited first? mvswitch, or cpmac? Nov 15 13:23:07 <[florian]> sn9: the probing of the mdio bus is done before cpmac_probe, which is just fine actually, because the mdio bus is in a working stage at that moment Nov 15 13:23:30 <[florian]> from a purely cosmetic point of view, you will keep seeing this %d format until it has been snprintf by the netdev core code Nov 15 13:24:05 yes, but maybe cpmac might fail to init if mvswitch attempts it first? Nov 15 13:24:45 <[florian]> that would be suprising, but you can try to make it being probed much later Nov 15 13:25:08 well, what is error -145? Nov 15 13:26:23 <[florian]> ETIMEDOUT Nov 15 13:26:34 hmm Nov 15 13:26:47 so, both time out? Nov 15 13:27:13 <[florian]> the error code from the timeout function of mvswitch up to the probing of the switch in phylib is propagated to cpmac Nov 15 13:27:19 ah Nov 15 13:28:37 iirc, on the broadcom gige switches, the eth device had to be inited before the phy Nov 15 13:31:11 <[florian]> sn9: these are quite different if I recall right Nov 15 13:31:26 <[florian]> sn9: but registering the mdio bus only when the platform device id is 0 is a sane solution too Nov 15 13:32:35 what's the simplest way to try it with mvswitch being probed only after the eth device is up? Nov 15 13:34:08 sn9: blacklist the mvswitch module, then manually load it after boot? Nov 15 13:34:27 clearly, the phy code tries to access the eth dev that isn't probed yet Nov 15 13:39:05 sn9, timeout waiting for switch to reset seems to happen randomly for me, I couldn't pinpoint. Some images it would timeout consistently then if I took out a printk I added for debug it would work again. Nov 15 13:40:37 i am rebuilding with CONFIG_PACKAGE_kmod-mvswitch=m to see what happens Nov 15 13:52:21 [florian], Wipster: something is screwy; i just set CONFIG_PACKAGE_kmod-mvswitch=m, but mvswitch was still built directly into the kernel Nov 15 13:56:44 sn9: it's probably set in your targets kernel config Nov 15 13:56:57 yes, i just saw it there Nov 15 14:31:15 florian * r24005 /trunk/target/linux/generic/patches-2.6.32/030-pci_disable_common_quirks.patch: [kernel] refresh 2.6.32 patches Nov 15 14:31:21 florian * r24006 /trunk/target/linux/rdc/patches-2.6.32/015-r6040_fix_multicast.patch: [rdc] fix r6040 multicast operations (#7848) Nov 15 14:44:37 florian * r24007 /branches/backfire/target/linux/rdc/patches-2.6.32: backport r24006 Nov 15 14:50:11 [florian], Wipster: without mvswitch, cpmac appears to load fine, but then: Nov 15 14:50:18 eth0: tx dma ring full Nov 15 14:50:45 WARNING: at net/sched/sch_generic.c:261 0x942b46a0() Nov 15 14:50:45 NETDEV WATCHDOG: eth0 (): transmit queue 2 timed out Nov 15 14:50:55 eth0: transmit timeout Nov 15 14:54:24 <[florian]> sn9: I think Wipster saw that alreayd and was trying to fix it Nov 15 14:57:01 Wipster: ? Nov 15 15:11:00 I have seen that ring full message in my travels, I think it was when I removed the driver from being compiled like you.. does the fixed phy register after it doesn't detect a phy? I think I missed the start of this conversation... Nov 15 15:18:07 Wipster: with mvswitch compiled directly into the kernel, it loads before cpmac, and both error out Nov 15 15:43:43 sn9, I have only seen that on occasion with me to be honest, I wonder.... you have an ohio and cpmac handles the disabling EPHY and playing with the MII register in its probing... after the mvswitch is called. When I have been testing I have disabling ephy and mii tweaking before the mdio bus is probed Nov 15 15:44:32 that might be it... Nov 15 15:44:36 before mdio? Nov 15 15:45:23 i'm not sure i'm understanding you right Nov 15 15:47:17 if mvswitch is directly in the kernel, the logs show that mdio is probed first, then mvswitch, then cpmac Nov 15 15:47:42 thats ok I dont myself half the time. The mdio bus is registered in cpmac init Nov 15 15:49:00 so I think the flow is cpmac inits and registers the mdio bus, mdio gets probed and returns what ever switch is there and the corresponding driver regs, then cpmac is opened and tried to register its interface Nov 15 15:49:06 is something supposed to happen before "Fixed MDIO Bus: probed" ? Nov 15 15:50:38 Wipster: this is a log with mvswitch directly in the kernel: http://www.gimpelevich.san-francisco.ca.us/danielg4/booting.log Nov 15 15:51:46 note that the error -145 when cpmac is probed happens after mvswitch, which is after mdio Nov 15 15:56:49 nbd: does mvswitch generally require the interface to be previously registered, or not registered? Nov 15 15:59:00 ok fixed mdio is probed (because you have fixed_phy) then cpmac inits and probes the real MDIO, kernel sees the switch and registers the phy driver which sets up, cpmac then opens and attempts to attach to the phy which fails because it cant reset, right? Nov 15 15:59:58 i think so Nov 15 16:00:27 how to get some extra packages from openwrt svn? like netstat-nat Nov 15 16:00:36 I think the issue lies around when cpmac opens it does the EPHY diabling and MII reg enabling to try and get the phyid, but by this time its too late and the switch hasn't started properly. Solution bring the EPHY disable and MII reg up the chain, it can be done in cpmac init or in platform, In my tests I have done it in platform and that works Nov 15 16:00:51 crow: "make package/symlinks" Nov 15 16:01:51 Wipster: ok. got a patch? Nov 15 16:02:03 sn9 yea but for that there should be package/netstat-nat which isnt... Nov 15 16:02:45 crow: yes it is Nov 15 16:02:45 got it ... blah i forgot "svn co svn://svn.openwrt.org/openwrt/packages" Nov 15 16:02:57 you don't need that Nov 15 16:03:00 sn9, yeh this is specific for ohio and will break others, one or two issues to work out before its ready Nov 15 16:03:07 just "make package/symlinks" Nov 15 16:05:04 sn9 ah well thanks i typed instead symlinks netstat-nat :((, hope that svn co wasnt to much.. Nov 15 16:11:26 WARNING: skipping netstat-nat -- package not selected <-- can i just compile package without make menuconfig? Nov 15 16:11:52 make package/netstat-nat/{clean,compile} V=99 <- but i got above warning.. Nov 15 16:12:11 you could edit .config Nov 15 16:12:16 DEVELOPER=1 Nov 15 16:12:27 ah, or that :) Nov 15 16:12:42 DEVELOPER=1 in makefile of netstat-nat ? Nov 15 16:15:23 no Nov 15 16:15:41 do this: DEVELOPER=1 make package/netstat-nat/{clean,compile} V=99 Nov 15 16:17:19 build #25 of kirkwood is complete: Failure [failed shell shell_13] Build details are at http://tksite.gotdns.org:8010/builders/kirkwood/builds/25 Nov 15 16:39:42 EqUaTe and xMff thanks that with netstat-nat worked out, now i am trying to compile openssh-sftp-server but no rule to make target.. is "make package/symlinks" needed every time before compiling package? Nov 15 16:40:12 no Nov 15 16:40:31 to get openssh-sftp-server is provided by the openssh Nov 15 16:40:35 ... source package Nov 15 16:40:43 so you need package/openssh/compile Nov 15 16:40:53 if you pass developer=1 it will compile all parts Nov 15 16:41:04 at this point enabling it in .config is more efficient Nov 15 16:41:23 ok Nov 15 17:00:03 xMff and compile everything like an image or just openssh? would like not to include it in image (selected it as M) Nov 15 17:01:05 just openssh Nov 15 17:57:34 sn9, back did it work? Nov 15 17:59:38 Wipster: see for yourself: http://www.gimpelevich.san-francisco.ca.us/danielg4/booting.log Nov 15 18:01:35 <[florian]> sn9: so far so good! Nov 15 18:01:56 <[florian]> sn9: does it ping the oustide world ;) ? Nov 15 18:02:01 oh good Nov 15 18:04:40 yeh the acid test :) Nov 15 18:18:03 acid test fails Nov 15 18:25:47 here's the quux of the matter: Nov 15 18:25:50 root@OpenWrt:/# swconfig dev eth0 show Nov 15 18:25:50 Failed to connect to the switch Nov 15 18:35:36 sn9, yeh thats the issue I am working on at the moment, if you set the lan interface to eth0.1 it stops mvswitch from eating packets, not sure why swconfig isn't playing fair though... Nov 15 18:39:42 florian * r24008 /trunk/package/ar7-atm/ (2 files in 2 dirs): [ar7] fix proc filesystem usage, patch from Wipster. Nov 15 18:40:15 setting ifname to eth0.1 populates vlan_group which the mvswitch rx mangle checks Nov 15 18:45:31 florian * r24009 /branches/backfire/tools/firmware-utils/src/imagetag.c: backport r21848 and r24000 Nov 15 19:17:47 build #27 of ubicom32 is complete: Failure [failed compile_4] Build details are at http://tksite.gotdns.org:8010/builders/ubicom32/builds/27 Nov 15 19:50:23 Wipster: no packets :( Nov 15 19:57:15 [florian]: i'm thinking there might be an off-by-one somewhere Nov 15 19:57:27 any clue where? Nov 15 19:58:17 <[florian]> sn9: off-by-one in waht sense? Nov 15 19:58:36 <[florian]> sn9: try to see if the switch driver rx and tx hooks are being called Nov 15 19:58:52 <[florian]> sn9: having tcpdump running on both sides will help Nov 15 19:59:26 i don't think any packets actually pass between machines Nov 15 19:59:34 and the led's don't blink Nov 15 20:00:24 <[florian]> try to ping the other way round and see if the request comes in at least Nov 15 20:01:25 host unreachable Nov 15 20:05:19 <[florian]> I meant, using tcpdump Nov 15 20:05:29 <[florian]> if the reply does not come back, ping believes it's unreachable Nov 15 20:07:50 it's unreachable only in one direction Nov 15 20:10:49 actually: Nov 15 20:11:12 root@OpenWrt:/# nc 192.168.1.99 55555 Nov 15 20:11:12 nc: can't connect to remote host (192.168.1.99): No route to host Nov 15 20:13:28 [florian]: cpmac can have two phy's, no? Nov 15 20:15:13 <[florian]> sn9: using the linux phylib, no, but if it found your switch, it's fine Nov 15 20:15:56 is mvswitch verified working on other targets? Nov 15 20:15:59 <[florian]> sn9: it is just that mvswitch requires some mangling of the packets Nov 15 20:16:21 <[florian]> sn9: it works on all targets where it used, atheros is its main user Nov 15 20:16:37 then cpmac is broken i guess Nov 15 20:20:34 <[florian]> certainly not Nov 15 20:20:43 <[florian]> it's the required hack to handle the mvswitch which does not work Nov 15 20:21:01 <[florian]> cpmac works fine here on "usual" switches where no mangling of the packets is required Nov 15 20:21:18 that hack is in cpmac.c, right? Nov 15 20:21:42 <[florian]> if you are using Wipser's patch, yes Nov 15 20:21:56 <[florian]> it basically needs to check if the phy device provides an rx and tx callback Nov 15 20:21:59 <[florian]> and if so, call it Nov 15 20:22:03 <[florian]> which is the case for mvswitch Nov 15 20:22:08 <[florian]> but no other phy driver Nov 15 20:22:14 oh Nov 15 20:22:48 is there an alternative to Wipster's patches? Nov 15 20:23:16 <[florian]> for mvswitch, unfortunately no Nov 15 20:24:00 hm. is there some explicit documentation about the vlan switch uci config? Nov 15 20:24:21 e.g. 'what does the * behind port 5 (internal trunk) mean?' Nov 15 20:26:44 [florian]: might CONFIG_FIXED_PHY=y be incorrect with his patches? Nov 15 20:28:37 <[florian]> sn9: I do not think so Nov 15 20:28:50 <[florian]> sn9: the fixed phy would only be registered if the switch is not detected using phylib Nov 15 20:29:43 he said that with his patches, cpmac works only with mvswitch, not without Nov 15 20:29:45 msg roh https://wiki.openwrt.org/doc/uci/network/switch - rtfm! ;) Nov 15 20:30:56 <[florian]> sn9: ok, well in your case that should not change anything, can I see the patch somewhere? Nov 15 20:31:19 [Mon 2010-11-15 08:03:15 AM PST] http://openwrt.pastebin.com/akzEhe9w http://openwrt.pastebin.com/sG5c0f12 http://openwrt.pastebin.com/STZakUdZ Nov 15 20:31:19 [Mon 2010-11-15 08:03:53 AM PST] remove 97x series and apply those, still WIP Nov 15 20:33:55 <[florian]> Wipster: are you sure that the offset for cpmac is the same for ar231x? Nov 15 20:41:47 [florian]: what determines the offset, anyway? Nov 15 20:47:45 <[florian]> sn9: that's what I am trying to check Nov 15 20:47:53 <[florian]> I am not sure this is valid for anything else but ar231x Nov 15 20:48:28 nbd has not chimed in. he might know, since mvswitch is his Nov 15 21:09:40 [florian]: did you manage to find out anything? Nov 15 21:21:44 back Nov 15 21:21:52 front Nov 15 21:21:59 true Nov 15 21:22:03 false Nov 15 21:22:24 Touché Nov 15 21:22:32 En garde Nov 15 21:22:49 riposte Nov 15 21:23:02 [Mon 2010-11-15 12:27:26 PM PST] <[florian]> Wipster: are you sure that the offset for cpmac is the same for ar231x? Nov 15 21:24:38 [florian], I assume so, its normally a 2 byte offset and mvswitch adds another two, it works for me. Nov 15 21:25:04 sn9, not seeing any packets when with those patches? did you try setting the lan ifname to eth0.1? Nov 15 21:25:34 Wipster: no packets :( Nov 15 21:27:13 interesting, can you add some printk's and see if the demangling hooks are being called and if so where they eat the packet? Nov 15 21:27:58 where exactly do you want the printk's? Nov 15 21:29:29 say at the start of mvswitch_mangle_rx then again after the togo error at the start see which one its killing Nov 15 21:29:35 goto Nov 15 21:39:35 sn9: at this point i'm considering replacing the mvswitch driver with the DSA driver for 88e6060 Nov 15 21:40:12 nbd: would that still need this sort of mangling? Nov 15 21:40:19 no Nov 15 21:40:35 with DSA, the mangling is already taken care of in the network stack Nov 15 21:40:55 what would be involved in integrating that? Nov 15 21:41:08 dunno Nov 15 21:41:12 probably not much Nov 15 21:41:33 i think the platform code needs to set up the dsa port mapping Nov 15 21:41:39 oh Nov 15 21:41:56 do we know the mappings? Nov 15 21:42:46 the mapping just assigns names to the ports Nov 15 21:42:53 oh Nov 15 21:43:17 <[florian]> sn9: have a look at how it works for ar71xx, that one supports dsa switches Nov 15 21:44:45 i think 88e6060 is probably the only switch for which DSA actually makes sense ;) Nov 15 21:45:15 juhosg wrote one for 88e6063, looks like Nov 15 21:47:32 i think for 88e6063, a non-DSA driver would be a lot better Nov 15 21:47:47 since that one can do 802.1q Nov 15 21:49:55 ping xMff Nov 15 21:50:01 pong cshore Nov 15 21:50:51 xMff: in LuCI how do you cause actions to happen when a config is changed Nov 15 21:51:14 /e/c/ucitrack for now Nov 15 21:54:00 just set Nov 15 21:54:00 config 'fs_directory' Nov 15 21:54:00 option iniit freeswitch Nov 15 21:54:00 to do /etc/init.d/freeswitch restart when /etc/config/fs_directory changes? Nov 15 21:54:14 yes Nov 15 21:54:31 shall I continue exploring cpmac with the 88e6060 or leave it if its being replaced Nov 15 21:55:01 Wipster: the received packets do not get eaten. i think it simply doesn't transmit Nov 15 21:55:12 ok, that's what I thought....must have been not been working because of a bug in the freeswitch modules config Nov 15 21:55:36 sn9, can you see them on tcpdump coming in? Nov 15 21:56:11 i don't think i included tcpdump in the image Nov 15 21:58:20 wait a sec... Nov 15 22:01:57 for eth0: Nov 15 22:02:04 RX packets:56 errors:0 dropped:0 overruns:0 frame:0 Nov 15 22:02:08 for eth0.1: Nov 15 22:02:15 RX packets:0 errors:0 dropped:0 overruns:0 frame:0 Nov 15 22:04:52 Wipster: does that tell you anything? Nov 15 22:09:35 nbd: only some ar7 devices have an 88e6060, while some might have an adm6996 or such. would can dsa and non-dsa coexist in the same platform code? Nov 15 22:12:07 sn9, hmmm cant see why I get tx and you dont... maybe usefull for someone better then me heh Nov 15 22:12:48 can you see if you can see where it fails in the tx path? Nov 15 22:13:07 what about the above rx failure? Nov 15 22:14:01 sn9: well, ar7 may need to use something like the mips machine code like on ar71xx Nov 15 22:14:11 to support different boards Nov 15 22:14:18 ugh Nov 15 22:18:03 oh sorry I saw rx packets and assumed it worked Nov 15 22:18:47 reread Nov 15 22:19:18 so things on eth0 but not eth0.1 Nov 15 22:19:22 right Nov 15 22:20:03 is whats coming on eth0 some loopback stuff? Nov 15 22:20:51 no, it increases when i send packets down the wire Nov 15 22:22:03 is the switch detecting crossover? Nov 15 22:22:32 the light comes on on the other end Nov 15 22:25:31 hmm between cpu and switch I mean, on mine the switch detects crossover mode, maybe your auto detect bit isn't set and its getting a bit confused Nov 15 22:26:04 where is that reported? Nov 15 22:27:30 in the phy registers, dumped with mii-tool. Look for register 17(decimal) and bit 6, 1 is transmit on rxp/rxn, 0 is the other way around Nov 15 22:28:22 grrrr, i didn't include mii-tool in the image Nov 15 22:28:42 reg 16(decimal) bit 5:4 control the way the switch expects, 1x is auto detect (what mine is) Nov 15 22:55:56 anything? Nov 15 22:56:28 image is larger now, so i have to adjust the pspboot env; hang on Nov 15 23:02:35 Wipster: ok, how do i dump the regs with mii-tool? Nov 15 23:03:10 mii-tool eth0 -vv if I recall Nov 15 23:03:42 registers for MII PHY 16: Nov 15 23:03:42 3000 7849 0141 0c87 01e1 0081 0004 2001 Nov 15 23:03:42 0000 0000 0000 0000 0000 0000 0000 0000 Nov 15 23:03:42 4130 0040 0000 0f80 0000 0000 4a34 03fc Nov 15 23:03:42 42bf 0000 0000 0000 0002 0000 0000 0000 Nov 15 23:08:14 so its set to auto detect too and its trasmitting on rxp/rxn. hmmm Nov 15 23:22:59 nbd: would anything special need to be done for CONFIG_FIXED_PHY to use dsa? Nov 15 23:23:10 no idea Nov 15 23:24:58 [florian]: what are your thoughts on this? Nov 15 23:28:15 well your phy interrupt register is very different to mine and the link partner ability if populated unlike mine Nov 15 23:30:21 the only interrupts I have set are energy detect and MDI/MDIX crossover changed (which you dont have on), I'm not sure if any of this is relevant though, I shall post my regs incase someone knows Nov 15 23:30:40 registers for MII PHY 16: Nov 15 23:30:40 3000 7849 0141 0c87 01e1 0000 0004 2001 Nov 15 23:30:40 0000 0000 0000 0000 0000 0000 0000 0000 Nov 15 23:30:40 4130 0050 0000 0050 0000 0000 4a34 03fc Nov 15 23:30:40 42bf 0000 0000 0000 0002 0000 0000 0000 Nov 15 23:31:28 which router have you got? Nov 15 23:32:43 this is an actiontec pk5000 Nov 15 23:32:56 32M flash, 64M ram Nov 15 23:35:11 4 eth ports Nov 15 23:35:56 ok, this is a dumb question....how do I build only the tools the $(TOPDIR)/tools directory? Nov 15 23:36:45 make tools Nov 15 23:36:58 says up-to-date but I have no binaries Nov 15 23:38:00 ok let me cook up something, bit of a long shot Nov 15 23:39:16 make tools/compile Nov 15 23:39:41 xMff: thanks...I forgot about /compile Nov 16 00:12:14 jow * r24010 /trunk/feeds.conf.default: [feeds] switch to LuCI trunk, should be stable enough for common use now Nov 16 00:20:34 Wipster: ... Nov 16 00:25:34 sn9, looking at some source now had to tidy the office. perchance you dont have a copy of the stock firmware bootlog? Nov 16 00:26:06 i did not make one, but i backed it up and can put it back on Nov 16 00:28:24 sn9, dont worry if its too much hassle, never know it might say something that needs to be done Nov 16 00:28:55 it's a 2.4 kernel, ffs Nov 16 00:57:22 Wipster: http://www.gimpelevich.san-francisco.ca.us/danielg4/pk5000.log Nov 16 01:10:36 sn9, thanks will continue to explore tomorrow Nov 16 01:11:54 xMff: for luci reload I don't seem to be seeing a call of /sbin/luci-reload (I stuck a an echo to a file in /tmp in it, and the lock file is not created either) Nov 16 01:13:35 Wipster: if i don't get this device working with openwrt by the middle of this week, i'll deploy it with the original firmware and test on a device without the mvswitch chip from that point on Nov 16 01:13:52 cshore: ucitrack okay? Nov 16 01:14:10 uci show ucitrack shows a bunch of stuff Nov 16 01:14:48 sn9, if its an urgent thing to get it working how about removing all the 97x patches altogether and sticking with fixed_phy Nov 16 01:15:20 Wipster: because ethernet does not work if i do that Nov 16 01:16:42 try just with that first ohio mii patch of that series, that might work. and disable the mvswitch in kernel make sure fixed_phy is on Nov 16 01:18:21 xMff: hmmm....dhcp doesn't do anything either...is essentials different (that's where I'm testing) Nov 16 01:18:32 xMff: and trunk Nov 16 01:22:37 I think it might be broken in trunk Nov 16 01:23:24 idk, haven't checked essentials in a long time, I'll probably remove it soon Nov 16 01:23:56 xMff: oh, ok...will there be anything like essentials? Nov 16 01:24:24 I think so Nov 16 01:25:01 but its gotten so out of sync and doing all the maintainence twice is too much effort Nov 16 01:25:17 yeah, it's kind of a pain, I had noticed Nov 16 01:26:20 the full admin now has general / advanced tabs in most pages so that one only sees the commonly used stuff by default Nov 16 01:26:30 I'll sprinkle in some assistants later Nov 16 01:26:42 after that I don't see a reason to keep essentials around Nov 16 01:27:19 sn9, this quick hack will enable the MDIX stuff on the ar7 http://openwrt.pastebin.com/0GnZ2ALU might also help if it is a crossover issue. Night Nov 16 01:27:24 makes sense Nov 16 01:28:05 having a whole separate set of development effort doesn't work the best Nov 16 01:29:11 ok, I'll switch to admin and see if that works....got to edit a few files Nov 16 01:55:39 Wipster: that worked, without the mdix patch. now, to see why wifi doesn't come up... Nov 16 01:55:43 hmmm....still not...let up update luci....I think I'm working with a pretty old version Nov 16 01:55:58 *let me Nov 16 01:58:19 Not using the 00000009 VLYNQ device's driver for VLYNQ device: 00000000 Nov 16 01:58:24 ^^^^^ **** ENDING LOGGING AT Tue Nov 16 02:59:58 2010