Re: [OpenWrt-Devel] [PATCH] 802.1Q VLAN support for Infineon ADM6996 switch chip
On 11/01/11 14:30, David Goodenough wrote: OK, so does your code check to see if this is an M, or do we need to add that? Do you think we should have two different drivers, one for the M the other for the F and L, or can we interweave the code? The detection and initialization part of the driver was already written, by Felix Fietkau. Since the M is a completely different chip than the F and L models, it only detects the M model, using the Chip Identification registers. I don't see any reason to interweave code for the M and the F. I see plenty of reason not to. They are wholly different. They deserve spearate drivers. Like I said, seems pretty much the only thing they have in common is part of the name of the chip. Peter. -- I use the GNU Privacy Guard (GnuPG) in combination with Enigmail. You can send me encrypted mail if you want some privacy. My key is available at http://wwwhome.cs.utwente.nl/~lebbing/pubkey.txt (new, larger key created on Nov 12, 2009) ___ openwrt-devel mailing list openwrt-devel@lists.openwrt.org https://lists.openwrt.org/mailman/listinfo/openwrt-devel
Re: [OpenWrt-Devel] [PATCH] 802.1Q VLAN support for Infineon ADM6996 switch chip
On Wednesday 12 January 2011, Peter Lebbing wrote: On 11/01/11 14:30, David Goodenough wrote: OK, so does your code check to see if this is an M, or do we need to add that? Do you think we should have two different drivers, one for the M the other for the F and L, or can we interweave the code? The detection and initialization part of the driver was already written, by Felix Fietkau. Since the M is a completely different chip than the F and L models, it only detects the M model, using the Chip Identification registers. I don't see any reason to interweave code for the M and the F. I see plenty of reason not to. They are wholly different. They deserve spearate drivers. Like I said, seems pretty much the only thing they have in common is part of the name of the chip. Peter. The odd thing is that the current code (before your patch) detects my ADM6996FC. It does not do much with it, but it detects it. Given that they are do different, perhaps your driver should be named as the adm6996m.c rather than just adm6996.c, and then we can have an adm6996fl.c for the F, FC and L versions. David ___ openwrt-devel mailing list openwrt-devel@lists.openwrt.org https://lists.openwrt.org/mailman/listinfo/openwrt-devel
Re: [OpenWrt-Devel] [PATCH] 802.1Q VLAN support for Infineon ADM6996 switch chip
On 12/01/11 13:19, David Goodenough wrote: The odd thing is that the current code (before your patch) detects my ADM6996FC. It does not do much with it, but it detects it. That is very odd indeed. I did not change the detection. Are you sure it is my patch that changes the behaviour, and not some other change? For instance, with backfire 10.03, the MAC driver used by the D-Link DSL-G624T, cpmac.c, would not detect the switch chip at all. In backfire SVN, this has changed; it is now detected correctly. So I basically have it the other way round if I don't patch anything but go from stable to backfire SVN. Given that they are do different, perhaps your driver should be named as the adm6996m.c rather than just adm6996.c, and then we can have an adm6996fl.c for the F, FC and L versions. I agree. But the detection code of adm6996.c (named as such) looks for Chip Identification registers that *are* mentioned in the datasheet for the M model, and very much *are not* in the datasheet for the F and L models. And I didn't write the detection nor name the file. Are you sure it is adm6996.c that detects your FC? It seems so odd to me, looking at the datasheets. Perhaps you could add some debug print statements to adm6996.c in the chip detection code to see what it reads and writes from the chip. Peter. -- I use the GNU Privacy Guard (GnuPG) in combination with Enigmail. You can send me encrypted mail if you want some privacy. My key is available at http://wwwhome.cs.utwente.nl/~lebbing/pubkey.txt (new, larger key created on Nov 12, 2009) ___ openwrt-devel mailing list openwrt-devel@lists.openwrt.org https://lists.openwrt.org/mailman/listinfo/openwrt-devel
[OpenWrt-Devel] [PATCH] hostapd: Create one control interface per virtual bssid
Previously hostapd created one control interface /var/run/hostapd-phyX
which only contained the first virtual bssid (for example wlan0). In
order to access the other virtual bssids with hostapd_cli add all
virtual bssids to /var/run/hostapd-phyX by specifying the ctrl_interface
parameter per bssid.
Previously the control interface looked like:
/var/run/hostapd-phyX/wlan0
Now, the control interface looks like this:
/var/run/hostapd-phyX/wlan0
/var/run/hostapd-phyX/wlan1
...
Signed-off-by: Helmut Schaa helmut.sc...@googlemail.com
---
package/hostapd/files/hostapd.sh |4 +++-
1 files changed, 3 insertions(+), 1 deletions(-)
diff --git a/package/hostapd/files/hostapd.sh b/package/hostapd/files/hostapd.sh
index 7d110db..9e98a1b 100644
--- a/package/hostapd/files/hostapd.sh
+++ b/package/hostapd/files/hostapd.sh
@@ -9,6 +9,9 @@ hostapd_set_bss_options() {
config_get device $vif device
config_get hwmode $device hwmode
+ config_get phy $device phy
+
+ append $var ctrl_interface=/var/run/hostapd-$phy $N
if [ $ap_isolate -gt 0 ]; then
append $var ap_isolate=$ap_isolate $N
@@ -184,7 +187,6 @@ hostapd_setup_vif() {
[ $channel = auto ] channel=
[ -n $channel -a -z $hwmode ] wifi_fixup_hwmode $device
cat /var/run/hostapd-$ifname.conf EOF
-ctrl_interface=/var/run/hostapd-$ifname
driver=$driver
interface=$ifname
${hwmode:+hw_mode=${hwmode#11}}
--
1.7.1
___
openwrt-devel mailing list
openwrt-devel@lists.openwrt.org
https://lists.openwrt.org/mailman/listinfo/openwrt-devel
Re: [OpenWrt-Devel] [PATCH] 802.1Q VLAN support for Infineon ADM6996 switch chip
On Wednesday 12 January 2011, Peter Lebbing wrote: On 12/01/11 13:19, David Goodenough wrote: The odd thing is that the current code (before your patch) detects my ADM6996FC. It does not do much with it, but it detects it. That is very odd indeed. I did not change the detection. Are you sure it is my patch that changes the behaviour, and not some other change? No, my point was that the code always has detected my FC, your code does not change that. For instance, with backfire 10.03, the MAC driver used by the D-Link DSL-G624T, cpmac.c, would not detect the switch chip at all. In backfire SVN, this has changed; it is now detected correctly. So I basically have it the other way round if I don't patch anything but go from stable to backfire SVN. Given that they are do different, perhaps your driver should be named as the adm6996m.c rather than just adm6996.c, and then we can have an adm6996fl.c for the F, FC and L versions. I agree. But the detection code of adm6996.c (named as such) looks for Chip Identification registers that *are* mentioned in the datasheet for the M model, and very much *are not* in the datasheet for the F and L models. And I didn't write the detection nor name the file. Are you sure it is adm6996.c that detects your FC? It seems so odd to me, looking at the datasheets. Perhaps you could add some debug print statements to adm6996.c in the chip detection code to see what it reads and writes from the chip. Well adm6996.c is the only code that I could find that puts out a syslog entry saying it has found an ADM6996 PHY. I am in the middle of another project at the moment, so it will be a few days before I can do any experiments, but I will try over the weekend. David Peter. ___ openwrt-devel mailing list openwrt-devel@lists.openwrt.org https://lists.openwrt.org/mailman/listinfo/openwrt-devel
Re: [OpenWrt-Devel] [PATCH] 802.1Q VLAN support for Infineon ADM6996 switch chip
On 12/01/11 13:43, David Goodenough wrote: On Wednesday 12 January 2011, Peter Lebbing wrote: On 12/01/11 13:19, David Goodenough wrote: Given that they are do different, perhaps your driver should be named as the adm6996m.c rather than just adm6996.c, and then we can have an adm6996fl.c for the F, FC and L versions. I agree. But the detection code of adm6996.c (named as such) looks for Chip Identification registers that *are* mentioned in the datasheet for the M model, and very much *are not* in the datasheet for the F and L models. And I didn't write the detection nor name the file. Are you sure it is adm6996.c that detects your FC? It seems so odd to me, looking at the datasheets. Perhaps you could add some debug print statements to adm6996.c in the chip detection code to see what it reads and writes from the chip. Well adm6996.c is the only code that I could find that puts out a syslog entry saying it has found an ADM6996 PHY. Yeah, and I see the Kconfig says: config ADM6996_PHY tristate Driver for ADM6996 switches ---help--- Currently supports the ADM6996F switch I'm thinking there's something odd going on here with regard to datasheets. I added Felix Fietkau to the recipients of this message, since he wrote the detection code in adm6996.c. Felix, if I look at the datasheet for the ADM6996F [1], in particular the register descriptions, I don't see the code in adm6996_fixup() matching on that chip. Instead, it matches the datasheet for the ADM6996M/MX [2], with the Chip ID registers at register addresses 0xA0 and 0xA1. I used [2] to implement the VLAN stuff and it works on the ADM6996M. I don't have an F model. Still, the Kconfig says adm6996.c works for the F model. I'm thinking I have the wrong datasheet for the F model. Could you give a pointer to the documentation you used, or possibly help out otherwise in this confusion? Peter. [1] http://www.datasheetcatalog.org/datasheets2/21/2150254_1.pdf [2] http://media.digikey.com/PDF/Data%20Sheets/Infineon%20PDFs/Samurai%206M,MX,%20ADM6996M,MX.pdf -- I use the GNU Privacy Guard (GnuPG) in combination with Enigmail. You can send me encrypted mail if you want some privacy. My key is available at http://wwwhome.cs.utwente.nl/~lebbing/pubkey.txt (new, larger key created on Nov 12, 2009) ___ openwrt-devel mailing list openwrt-devel@lists.openwrt.org https://lists.openwrt.org/mailman/listinfo/openwrt-devel
Re: [OpenWrt-Devel] r24920 and others: ath9k: DMA failed to stop in 10 ms
Roback, Joe schrieb: I would agree, lately, I am seeing a bunch of these in my logs: ath: Failed to stop TX DMA in 100 msec after killing last frame but my 802.11n 40MHz performance has been the best its been in 6 months ;-) On Tue, 11 Jan 2011 16:35:10 -0600, J. Ryan Earl o...@jryanearl.us wrote: What's the exact error? I've see something similar in my dmesg: ath: Failed to stop TX DMA in 100 msec after killing last frame However, I get great performance regardless. Able to pull 150 mbit/s actual in a 2x2 MIMO configuration. Are you two using 'station' mode and associating with a OpenWRT AP. Because I'm getting abysmal performance. Running iPerf in UDP mode, frequently gives 10% packet loss at 10 mbs... Theplatform I'm using is pretty close to the Atheros AP83 reference design. I also have tested with a non-OpenWRT station, and get much better performance. John Clark. ___ openwrt-devel mailing list openwrt-devel@lists.openwrt.org https://lists.openwrt.org/mailman/listinfo/openwrt-devel
Re: [OpenWrt-Devel] r24920 and others: ath9k: DMA failed to stop in 10 ms
On Wed, Jan 12, 2011 at 11:54 AM, John Clark jcl...@metricsystems.comwrote: Roback, Joe schrieb: I would agree, lately, I am seeing a bunch of these in my logs: ath: Failed to stop TX DMA in 100 msec after killing last frame but my 802.11n 40MHz performance has been the best its been in 6 months ;-) On Tue, 11 Jan 2011 16:35:10 -0600, J. Ryan Earl o...@jryanearl.us wrote: What's the exact error? I've see something similar in my dmesg: ath: Failed to stop TX DMA in 100 msec after killing last frame However, I get great performance regardless. Able to pull 150 mbit/s actual in a 2x2 MIMO configuration. Are you two using 'station' mode and associating with a OpenWRT AP. Because I'm getting abysmal performance. Running iPerf in UDP mode, frequently gives 10% packet loss at 10 mbs... Theplatform I'm using is pretty close to the Atheros AP83 reference design. I also have tested with a non-OpenWRT station, and get much better performance. It is in Access Point mode. I measured throughput not with iperf, but by transferring data from a server on the LAN-side to an associated wireless device (a laptop in my case with a Intel 5100 AGN card) and inspecting the network traffic on both ends of the transport. I would suggest generating the traffic outside of OpenWRT so as to not impose any additional overhead that could affect your performance results. -JR ___ openwrt-devel mailing list openwrt-devel@lists.openwrt.org https://lists.openwrt.org/mailman/listinfo/openwrt-devel
Re: [OpenWrt-Devel] [package] [mpd] remove duplicate configure of aac
Applied. Thanks! signature.asc Description: This is a digitally signed message part. ___ openwrt-devel mailing list openwrt-devel@lists.openwrt.org https://lists.openwrt.org/mailman/listinfo/openwrt-devel
Re: [OpenWrt-Devel] automated testing brainstorming
Nice! Thank you Bastian! Please be aware that * I haven't tested the USB-to-serial HW that I had suggested with Linux. I do not own one of those, but I believe they work out of the box. * As you may know I am no frequent committer to OpenWRT nor lurker on the ML, you probably know better than me if the thing with the text link works out. But I think it should :) I am not aware of the trust relationships within the OpenWRT project, but I am sure you will find a way to also give devs shell access in case stuff breaks on one of the routers. Which would of course be super awesome. I see it in my minds eye or whatever: Spam from the buildbot, my last commit (hah! as if I ever had committed anything here! or as if s/o would be stupid enough to give me commit rights...) broke something on the 1043ND. I quickly flip my keyboard to read my SSH private key passphrase, SSH into your computer, and remote-gdb the sucker just for a couple of uber-frustrating hours before finally giving up! I LOVE open source :D On 09/01/11 18:34, Bastian Bittorf wrote: but I've recently came across a usb2-to-four-times-serial for 39 euros [1] Good idea. @work we have enough space/power to make this. So i will setup: 1 x Computer 4 x Router (Linksys WRT54GL, TP-Link 1043ND, DIR-300, RouterStation Pro) 4 x Serial soldered to routers 1 x Internet 1 x Ethernet-Power-Socket (4x) If we are ready, i will give out SSH access to someone who has time to script some scripts - ok? bye, Bastian ___ openwrt-devel mailing list openwrt-devel@lists.openwrt.org https://lists.openwrt.org/mailman/listinfo/openwrt-devel ___ openwrt-devel mailing list openwrt-devel@lists.openwrt.org https://lists.openwrt.org/mailman/listinfo/openwrt-devel
Re: [OpenWrt-Devel] automated testing brainstorming
The plastic router cloud! Way awesome! I know building stuff is big fun, but before anyone gets her/his soldier iron out, this could maybe be tried with an emulator? Shouldn't there be a gazillion emulators out there for the obscurest architectures? I recall having seen ARM ones even in the debian apt tree. What do you think of the idea of staging the process: 1.) compile, if not w0rk - spam spam spam! 2.) distribute to emulators, if not work, spam spam spam! 3.) distribute to plastic routers, if not work, spam spam spam! and get someone to de-brick the device. Greetings, Flo On 10/01/11 05:24, rellis wrote: (I guess I should learn to proofread my outgoing mail before I work on testing :( ) ___ openwrt-devel mailing list openwrt-devel@lists.openwrt.org https://lists.openwrt.org/mailman/listinfo/openwrt-devel ___ openwrt-devel mailing list openwrt-devel@lists.openwrt.org https://lists.openwrt.org/mailman/listinfo/openwrt-devel
Re: [OpenWrt-Devel] automated testing brainstorming
Hi! On 10/01/11 05:22, rellis wrote: If you google for 'linux wireless automated testbed' you'll find a plethora of entries. It seems to be a research topic at a number of universities. Yes, but I highly doubt any of these can be talked into giving their stuff away to something that does not produce papers. I.e. with testbed I believe they mean testbed for wicked mad professor routing schemes to write brilliant papers about not compile stuff over and over and over again and automatedly run automated test scripts before rebooting. What's more, we would probably need only one or maybe a couple of identical devices, while those testbeds usually have many devices that are exactly the same. ___ openwrt-devel mailing list openwrt-devel@lists.openwrt.org https://lists.openwrt.org/mailman/listinfo/openwrt-devel
