You can subscribe to this list here.
2003 |
Jan
|
Feb
|
Mar
(14) |
Apr
(20) |
May
(72) |
Jun
(45) |
Jul
(125) |
Aug
(112) |
Sep
(84) |
Oct
(77) |
Nov
(92) |
Dec
(77) |
---|---|---|---|---|---|---|---|---|---|---|---|---|
2004 |
Jan
(66) |
Feb
(50) |
Mar
(58) |
Apr
(40) |
May
(39) |
Jun
(44) |
Jul
(82) |
Aug
(134) |
Sep
(48) |
Oct
(42) |
Nov
(69) |
Dec
(39) |
2005 |
Jan
(36) |
Feb
(36) |
Mar
(33) |
Apr
(18) |
May
(107) |
Jun
(70) |
Jul
(44) |
Aug
(57) |
Sep
(119) |
Oct
(161) |
Nov
(37) |
Dec
(88) |
2006 |
Jan
(119) |
Feb
(51) |
Mar
(57) |
Apr
(8) |
May
(21) |
Jun
(15) |
Jul
(13) |
Aug
(1) |
Sep
(12) |
Oct
(7) |
Nov
(8) |
Dec
(6) |
2007 |
Jan
(10) |
Feb
|
Mar
|
Apr
|
May
|
Jun
|
Jul
(1) |
Aug
|
Sep
|
Oct
(6) |
Nov
(5) |
Dec
|
2008 |
Jan
(1) |
Feb
(2) |
Mar
|
Apr
(1) |
May
(6) |
Jun
(1) |
Jul
(7) |
Aug
|
Sep
|
Oct
(1) |
Nov
|
Dec
|
2009 |
Jan
|
Feb
(1) |
Mar
|
Apr
|
May
|
Jun
|
Jul
|
Aug
|
Sep
|
Oct
(2) |
Nov
|
Dec
|
2010 |
Jan
(4) |
Feb
|
Mar
|
Apr
|
May
(6) |
Jun
(19) |
Jul
|
Aug
(1) |
Sep
(7) |
Oct
|
Nov
|
Dec
(1) |
2011 |
Jan
(13) |
Feb
|
Mar
|
Apr
|
May
|
Jun
|
Jul
|
Aug
(3) |
Sep
|
Oct
|
Nov
|
Dec
(3) |
2012 |
Jan
|
Feb
|
Mar
|
Apr
(3) |
May
|
Jun
(4) |
Jul
|
Aug
|
Sep
|
Oct
(3) |
Nov
|
Dec
|
2013 |
Jan
|
Feb
(1) |
Mar
|
Apr
|
May
|
Jun
|
Jul
|
Aug
|
Sep
(2) |
Oct
|
Nov
|
Dec
|
2014 |
Jan
|
Feb
|
Mar
|
Apr
|
May
|
Jun
|
Jul
|
Aug
|
Sep
|
Oct
(1) |
Nov
|
Dec
|
From: James Le C. <ch...@au...> - 2011-01-13 18:19:12
|
On Thu, 13 Jan 2011 19:04:57 +0100 Oliver Winker <oli...@ol...> wrote: > This is the sequence I use on the DG834Gv2. Should be the same IP, > since it's the same patched ADAM2 version: Yep but I went and changed the default IP, didn't I? ;) I'll try and give it another shot with the old machine tonight. James |
From: Oliver W. <oli...@ol...> - 2011-01-13 18:05:05
|
Hi James, This is the sequence I use on the DG834Gv2. Should be the same IP, since it's the same patched ADAM2 version: --- - Before on host-machine: echo 0 >/proc/sys/net/ipv4/tcp_frto - Power up, wait 2sec (+-, since I use the serial to stop ADAM) ftp 192.168.0.1 - User/PW: adam2/adam2 quote "SETENV mtd5,0x90020000,0x903e0000" quote "MEDIA FLSH" bin put "openwrt-ar7-squashfs.bin" "fs mtd5" quote REBOOT --- I used OpenWRT trunk rev 24894, but I had to take out following patch, otherwise the ethernet wouldn't probe. Just deleting the patch and rebuilding the image worked: --- target/linux/ar7/patches-2.6.32/972-cpmac_multi_probe.patch make target/linux/clean (I think !?) make --- For the wireless, deactivate or build without the acx module, but with the acx-mac80211 module. Then put into "/etc/config/wireless" in the "config wifi-device" section the *macaddr* (wlan0, phy0, etc. didn't do it) of the wifi device: --- config wifi-device wlan0 option type mac80211 option macaddr 00:e0:98:cd:f5:c8 option hwmode 11g # REMOVE THIS LINE TO ENABLE WIFI: #option disabled 1 [... rest of wireless config ...] --- G+, Oliver On 01/13/2011 01:18 AM, James Le Cuirot wrote: > I built it a couple of days ago and finally found the time to try it > out tonight but I'm having trouble accessing ADAM2. I'm not 100% sure > what I set the IP for it to and I don't know of any way to check. Do > you? I suspect I'm guessing correctly but I'm also using a different > machine to upload the firmware image now. I know it doesn't work with > all NICs so I may have to dig out the machine I used before. I'll let > you know. |
From: Michael W. <esi...@gm...> - 2011-01-13 06:01:45
|
On 13 January 2011 02:18, James Le Cuirot <ch...@au...> wrote: > On Sat, 08 Jan 2011 19:15:45 +0100 > Oliver Winker <oli...@ol...> wrote: > >> Hi Alexey, James, >> >> If you like you can try the latest commit 'f49457d9', it contains >> sensitivity and recalibration setting changes. > > I built it a couple of days ago and finally found the time to try it > out tonight but I'm having trouble accessing ADAM2. I'm not 100% sure > what I set the IP for it to and I don't know of any way to check. Do > you? I suspect I'm guessing correctly but I'm also using a different > machine to upload the firmware image now. I know it doesn't work with > all NICs so I may have to dig out the machine I used before. I'll let > you know. A serial console is probably the easiest, I think, if you have access to one. -- Michael Wood <esi...@gm...> |
From: James Le C. <ch...@au...> - 2011-01-13 00:18:29
|
On Sat, 08 Jan 2011 19:15:45 +0100 Oliver Winker <oli...@ol...> wrote: > Hi Alexey, James, > > If you like you can try the latest commit 'f49457d9', it contains > sensitivity and recalibration setting changes. I built it a couple of days ago and finally found the time to try it out tonight but I'm having trouble accessing ADAM2. I'm not 100% sure what I set the IP for it to and I don't know of any way to check. Do you? I suspect I'm guessing correctly but I'm also using a different machine to upload the firmware image now. I know it doesn't work with all NICs so I may have to dig out the machine I used before. I'll let you know. James |
From: Oliver W. <oli...@ol...> - 2011-01-08 18:15:54
|
Hi Alexey, James, If you like you can try the latest commit 'f49457d9', it contains sensitivity and recalibration setting changes. I run them here on a wag54gv2 (also tested dg834dv2 and different other cards) and it's working quite good. Rx/Tx perf still depends a bit on radio conditions, I have the impression. Wpa2 perf is cpu bound on the wag54gv2. In terms of tx-power, I think we are still on a relatively defensive level - at least that's what my ath5k card is measuring. Just researching a bit how to push this up. Alexey, your endian fixes are in as well. Cheers, Oliver On 01/02/2011 08:28 PM, James Le Cuirot wrote: > On Sun, 02 Jan 2011 18:42:30 +0100 > Oliver Winker <oli...@ol...> wrote: > >>> acx: acx_after_interrupt_recalib: phy0: less than 5 minutes since >>> last radio recalibration, not recalibrating (maybe the card is too >>> hot?) >> >> Last week there was quite some progress on this part. I think it's >> solved for the acx111. I'm just still doing some more detailed long >> duration tests to confirm and need to do the final implementation. >> Just let me know if you want a improvised, preliminary patch. > > It's been a long time since I've fetched a new copy of the driver. > Sounds like I should do that very soon! It would be great to have this > fixed once and for all. > > James > > ------------------------------------------------------------------------------ > Learn how Oracle Real Application Clusters (RAC) One Node allows customers > to consolidate database storage, standardize their database environment, and, > should the need arise, upgrade to a full multi-node Oracle RAC database > without downtime or disruption > http://p.sf.net/sfu/oracle-sfdevnl > _______________________________________________ > Acx100-users mailing list > Acx...@li... > https://lists.sourceforge.net/lists/listinfo/acx100-users > |
From: James Le C. <ch...@au...> - 2011-01-02 19:46:28
|
On Sun, 02 Jan 2011 18:42:30 +0100 Oliver Winker <oli...@ol...> wrote: > > acx: acx_after_interrupt_recalib: phy0: less than 5 minutes since > > last radio recalibration, not recalibrating (maybe the card is too > > hot?) > > Last week there was quite some progress on this part. I think it's > solved for the acx111. I'm just still doing some more detailed long > duration tests to confirm and need to do the final implementation. > Just let me know if you want a improvised, preliminary patch. It's been a long time since I've fetched a new copy of the driver. Sounds like I should do that very soon! It would be great to have this fixed once and for all. James |
From: Oliver W. <oli...@ol...> - 2011-01-02 18:41:38
|
Hi Alexey, Great! Thanks a lot, I'll check this patch. Maybe this also fixes the G624t problem reported by Enrico before. I'm expecting such an device next week, so I can actually check this. On 01/02/2011 02:45 PM, Alexey Torkhov wrote: > With patch and firmware it seems to work correctly, just throws this > messages to log, hope they are not harmful: > > acx: acx_after_interrupt_recalib: phy0: less than 5 minutes since last > radio recalibration, not recalibrating (maybe the card is too hot?) Last week there was quite some progress on this part. I think it's solved for the acx111. I'm just still doing some more detailed long duration tests to confirm and need to do the final implementation. Just let me know if you want a improvised, preliminary patch. Cheers and Thanks for the patch! Oliver |
From: Alexey T. <ato...@gm...> - 2011-01-02 13:45:30
|
Hi. I've managed to run acx-mac80211 driver on big-endian zyxel p-334wt board with openwrt. It needed firmware from http://acx100.erley.org/fw/acx111_1.2.1.34 and the following patch to correctly load firmware. Without patch it was giving error: acx_pci: probe of 0000:00:02.0 failed with error -5 With patch and firmware it seems to work correctly, just throws this messages to log, hope they are not harmful: acx: acx_after_interrupt_recalib: phy0: less than 5 minutes since last radio recalibration, not recalibrating (maybe the card is too hot?) So, here is the patch: Signed-off-by: Alexey Torkhov <ato...@gm...> diff --git a/pci.c b/pci.c index 4f5c0a7..160f3e0 100644 --- a/pci.c +++ b/pci.c @@ -273,10 +273,10 @@ static void acxpci_log_txbuffer(acx_device_t * adev) */ /* OS I/O routines *always* be endianness-clean but having them doesn't hurt */ -#define acx_readl(v) le32_to_cpu(readl((v))) -#define acx_readw(v) le16_to_cpu(readw((v))) -#define acx_writew(v,r) writew(le16_to_cpu((v)), r) -#define acx_writel(v,r) writel(le32_to_cpu((v)), r) +#define acx_readl(v) readl((v)) +#define acx_readw(v) readw((v)) +#define acx_writew(v,r) writew((v), r) +#define acx_writel(v,r) writel((v), r) INLINE_IO u32 read_reg32(acx_device_t * adev, unsigned int offset) { |
From: Dropbox <no-...@dr...> - 2010-12-31 09:41:13
|
Davide Imbeni wants you to use Dropbox to sync and share files online and across computers. Get started here: http://www.dropbox.com/link/20.dmGbsAQK8n/NjU1ODgzMDQ4Nw?src=referrals_bulk0 - The Dropbox Team ____________________________________________________ To stop receiving invites from Dropbox, please go to http://www.dropbox.com/bl/e6841acb254c/acx100-users%40lists.sourceforge.net |
From: Oliver W. <oli...@ol...> - 2010-09-25 07:34:47
|
On 09/23/2010 08:37 PM, Enrico Lorenzoni wrote: > 2010/9/23 Oliver Winker <oli...@ol...> > >> Hello Enrico, >> >> >> Just for my info: >> >> - Could you before loading the module do an "dmesg" and "lspci -v" and >> sent the output ? >> >> > here is my dmesg. I don't have lspci and I can't find the package to install > it. > Ok, Thanks already. Let's see then, how we can approach this. Cheers, Ol |
From: Enrico L. <re...@gm...> - 2010-09-23 18:37:45
|
2010/9/23 Oliver Winker <oli...@ol...> > Hello Enrico, > > > Just for my info: > > - Could you before loading the module do an "dmesg" and "lspci -v" and > sent the output ? > > here is my dmesg. I don't have lspci and I can't find the package to install it. Linux version 2.6.32.16 (openwrt@ampere) (gcc version 4.3.3 (GCC) ) #1 Wed Aug 25 15:20:15 PDT 2010 prom: fw_arg0=00000002, fw_arg1=80050028, fw_arg2=80050000, fw_arg3=00000001 MyLoader: sysp=00000000, boardp=00000000, parts=ace50014 bootconsole [early0] enabled CPU revision is: 00019374 (MIPS 24Kc) Atheros AR7161 rev 2, CPU:720.000 MHz, AHB:180.000 MHz, DDR:360.000 MHz Determined physical RAM map: memory: 08000000 @ 00000000 (usable) Initrd not found or empty - disabling initrd Zone PFN ranges: Normal 0x00000000 -> 0x00008000 Movable zone start PFN for each node early_node_map[1] active PFN ranges 0: 0x00000000 -> 0x00008000 On node 0 totalpages: 32768 free_area_init_node: node 0, pgdat 802d25a0, node_mem_map 81000000 Normal zone: 256 pages used for memmap Normal zone: 0 pages reserved Normal zone: 32512 pages, LIFO batch:7 Built 1 zonelists in Zone order, mobility grouping on. Total pages: 32512 Kernel command line: rootfstype=squashfs,yaffs,jffs2 noinitrd console=ttyS0,115200 board=UBNT-RSPRO board=RouterStation PRO ethaddr=00.15.6d.xx.xx.xx PID hash table entries: 512 (order: -1, 2048 bytes) Dentry cache hash table entries: 16384 (order: 4, 65536 bytes) Inode-cache hash table entries: 8192 (order: 3, 32768 bytes) Primary instruction cache 64kB, VIPT, 4-way, linesize 32 bytes. Primary data cache 32kB, 4-way, VIPT, cache aliases, linesize 32 bytes Writing ErrCtl register=000786f2 Readback ErrCtl register=000786f2 Memory: 126604k/131072k available (2109k kernel code, 4304k reserved, 398k data, 152k init, 0k highmem) SLUB: Genslabs=7, HWalign=32, Order=0-3, MinObjects=0, CPUs=1, Nodes=1 Hierarchical RCU implementation. NR_IRQS:56 Calibrating delay loop... 478.41 BogoMIPS (lpj=2392064) Mount-cache hash table entries: 512 NET: Registered protocol family 16 MIPS: machine is Ubiquiti RouterStation Pro registering PCI controller with io_map_base unset bio: create slab <bio-0> at 0 pci 0000:00:00.0: reg 10 32bit mmio pref: [0x000000-0xfffffff] pci 0000:00:00.0: reg 14 io port: [0x00-0xff] pci 0000:00:00.0: supports D1 D2 pci 0000:00:00.0: PME# supported from D0 D1 D2 D3hot pci 0000:00:00.0: PME# disabled pci 0000:00:11.0: reg 10 32bit mmio: [0x000000-0x00ffff] pci 0000:00:12.0: reg 10 32bit mmio: [0x000000-0x001fff] pci 0000:00:12.0: reg 14 32bit mmio: [0x000000-0x01ffff] pci 0000:00:12.0: supports D1 D2 pci 0000:00:12.0: PME# supported from D0 D1 D2 D3hot pci 0000:00:12.0: PME# disabled PCI: mapping irq 48 to pin1@0000:00:11.0 PCI: mapping irq 49 to pin1@0000:00:12.0 Switching to clocksource MIPS NET: Registered protocol family 2 IP route cache hash table entries: 1024 (order: 0, 4096 bytes) TCP established hash table entries: 4096 (order: 3, 32768 bytes) TCP bind hash table entries: 4096 (order: 2, 16384 bytes) TCP: Hash tables configured (established 4096 bind 4096) TCP reno registered NET: Registered protocol family 1 squashfs: version 4.0 (2009/01/31) Phillip Lougher Registering mini_fo version $Id$ JFFS2 version 2.2. (NAND) (SUMMARY) © 2001-2006 Red Hat, Inc. yaffs Aug 25 2010 15:11:02 Installing. msgmni has been set to 247 io scheduler noop registered io scheduler deadline registered (default) Serial: 8250/16550 driver, 1 ports, IRQ sharing disabled serial8250.0: ttyS0 at MMIO 0x18020000 (irq = 11) is a 16550A console [ttyS0] enabled, bootconsole disabled Atheros AR71xx SPI Controller driver version 0.2.4 m25p80 spi0.0: mx25l12805d (16384 Kbytes) spi0.0: searching for MyLoader partition table at offset 0x10000 spi0.0: searching for MyLoader partition table at offset 0x20000 spi0.0: searching for MyLoader partition table at offset 0x30000 spi0.0: searching for MyLoader partition table at offset 0x40000 spi0.0: no MyLoader partition table found Searching for RedBoot partition table in spi0.0 at offset 0xfe0000 Searching for RedBoot partition table in spi0.0 at offset 0xff0000 5 RedBoot partitions found on MTD device spi0.0 Creating 5 MTD partitions on "spi0.0": 0x000000000000-0x000000030000 : "RedBoot" 0x000000030000-0x000000110000 : "kernel" 0x000000110000-0x000000ff0000 : "rootfs" mtd: partition "rootfs" set to be root filesystem mtd: partition "rootfs_data" created automatically, ofs=320000, len=CD0000 0x000000320000-0x000000ff0000 : "rootfs_data" 0x000000ff0000-0x000000fff000 : "FIS directory" 0x000000fff000-0x000001000000 : "RedBoot config" ag71xx_mdio: probed eth0: Atheros AG71xx at 0xb9000000, irq 4 eth0: connected to PHY at ag71xx-mdio:04 [uid=004dd041, driver=Atheros AR8216/AR8316] eth1: Atheros AG71xx at 0xba000000, irq 5 eth1: AR8316 switch driver attached. eth1: connected to PHY at ag71xx-mdio:00 [uid=004dd041, driver=Atheros AR8216/AR8316] Atheros AR71xx hardware watchdog driver version 0.1.0 ar71xx-wdt: timeout=15 secs (max=23) TCP westwood registered NET: Registered protocol family 17 802.1Q VLAN Support v1.8 Ben Greear <gr...@ca...> All bugs added by David S. Miller <da...@re...> VFS: Mounted root (squashfs filesystem) readonly on device 31:2. Freeing unused kernel memory: 152k freed Please be patient, while OpenWrt loads ... gpio-buttons driver version 0.1.2 input: gpio-buttons as /devices/platform/gpio-buttons/input/input0 Button Hotplug driver version 0.3.1 Registered led device: ubnt:green:rf mini_fo: using base directory: / mini_fo: using storage directory: /overlay device eth1 entered promiscuous mode Compat-wireless backport release: compat-wireless-2010-07-13-4-g04898a5 Backport based on wireless-2.6.git v2.6.35-rc6-48432-gdce358e cfg80211: Calling CRDA to update world regulatory domain ar71xx: pll_reg 0xb8050014: 0x110000 eth1: link up (1000Mbps/Full duplex) br-lan: port 1(eth1) entering forwarding state SCSI subsystem initialized cfg80211: World regulatory domain updated: (start_freq - end_freq @ bandwidth), (max_antenna_gain, max_eirp) (2402000 KHz - 2472000 KHz @ 40000 KHz), (300 mBi, 2000 mBm) (2457000 KHz - 2482000 KHz @ 20000 KHz), (300 mBi, 2000 mBm) (2474000 KHz - 2494000 KHz @ 20000 KHz), (300 mBi, 2000 mBm) (5170000 KHz - 5250000 KHz @ 40000 KHz), (300 mBi, 2000 mBm) (5735000 KHz - 5835000 KHz @ 40000 KHz), (300 mBi, 2000 mBm) usbcore: registered new interface driver usbfs usbcore: registered new interface driver hub usbcore: registered new device driver usb PCI: Enabling device 0000:00:11.0 (0000 -> 0002) ath5k 0000:00:11.0: registered as 'phy0' ath: EEPROM regdomain: 0x0 ath: EEPROM indicates default country code should be used ath: doing EEPROM country->regdmn map search ath: country maps to regdmn code: 0x3a ath: Country alpha2 being used: US ath: Regpair used: 0x3a phy0: Selected rate control algorithm 'minstrel' ath5k phy0: Atheros AR5414 chip found (MAC: 0xa5, PHY: 0x61) cfg80211: Calling CRDA for country: US cfg80211: Regulatory domain changed to country: US (start_freq - end_freq @ bandwidth), (max_antenna_gain, max_eirp) (2402000 KHz - 2472000 KHz @ 40000 KHz), (300 mBi, 2700 mBm) (5170000 KHz - 5250000 KHz @ 40000 KHz), (300 mBi, 1700 mBm) (5250000 KHz - 5330000 KHz @ 40000 KHz), (300 mBi, 2000 mBm) (5490000 KHz - 5600000 KHz @ 40000 KHz), (300 mBi, 2000 mBm) (5650000 KHz - 5710000 KHz @ 40000 KHz), (300 mBi, 2000 mBm) (5735000 KHz - 5835000 KHz @ 40000 KHz), (300 mBi, 3000 mBm) usbcore: registered new interface driver rtl8187 PPP generic driver version 2.4.2 ip_tables: (C) 2000-2006 Netfilter Core Team NET: Registered protocol family 24 ehci_hcd: USB 2.0 'Enhanced' Host Controller (EHCI) Driver ar71xx-ehci ar71xx-ehci: Atheros AR71xx built-in EHCI controller ar71xx-ehci ar71xx-ehci: new USB bus registered, assigned bus number 1 ar71xx-ehci ar71xx-ehci: irq 3, io mem 0x1b000000 ar71xx-ehci ar71xx-ehci: USB 2.0 started, EHCI 1.00 usb usb1: configuration #1 chosen from 1 choice hub 1-0:1.0: USB hub found hub 1-0:1.0: 2 ports detected nf_conntrack version 0.5.0 (1983 buckets, 7932 max) CONFIG_NF_CT_ACCT is deprecated and will be removed soon. Please use nf_conntrack.acct=1 kernel parameter, acct=1 nf_conntrack module option or sysctl net.netfilter.nf_conntrack_acct=1 to enable it. usb 1-2: new high speed USB device using ar71xx-ehci and address 2 usb 1-2: configuration #1 chosen from 1 choice acx: this driver is still EXPERIMENTAL acx: reading README file and/or Craig's HOWTO is recommended, visit http://acx100.sf.net in case of further questions/discussion acx: compiled to use 32bit I/O access. I/O timing issues might occur, such as non-working firmware upload. Report them acx: running on a BIG-ENDIAN CPU acx: PCI/VLYNQ module v0.3.37 initialized, waiting for cards to probe... PCI: Enabling device 0000:00:12.0 (0000 -> 0002) PCI: Setting latency timer of device 0000:00:12.0 to 64 acx: found ACX111-based wireless network card at 0000:00:12.0, irq:49, phymem1:0x10030000, phymem2:0x10000000, mem1:0xb0030000, mem1_size:8192, mem2:0xb00000$ initial debug setting is 0x000A using IRQ 49 acx: eCPU is already running. reset_dev() FAILED acx_pci: probe of 0000:00:12.0 failed with error -5 ath_hal: module license 'Proprietary' taints kernel. Disabling lock debugging due to kernel taint ath_hal: 2009-05-08 (AR5210, AR5211, AR5212, AR5416, RF5111, RF5112, RF2413, RF5413, RF2133, RF2425, REGOPS_FUNC, XR) ath_pci: trunk wlan: trunk wlan: mac acl policy registered ath_rate_minstrel: Minstrel automatic rate control algorithm 1.2 (trunk) ath_rate_minstrel: look around rate set to 10% ath_rate_minstrel: EWMA rolloff level set to 75% ath_rate_minstrel: max segment size in the mrr set to 6000 us ohci_hcd: USB 1.1 'Open' Host Controller (OHCI) Driver ar71xx-ohci ar71xx-ohci: Atheros AR71xx built-in OHCI controller ar71xx-ohci ar71xx-ohci: new USB bus registered, assigned bus number 2 ar71xx-ohci ar71xx-ohci: irq 14, io mem 0x1c000000 usb usb2: configuration #1 chosen from 1 choice hub 2-0:1.0: USB hub found hub 2-0:1.0: 2 ports detected i2c /dev entries driver usbcore: registered new interface driver usbserial USB Serial support registered for generic usbcore: registered new interface driver usbserial_generic usbserial: USB Serial Driver core Initializing USB Mass Storage driver... scsi0 : SCSI emulation for USB Mass Storage devices usbcore: registered new interface driver usb-storage USB Mass Storage support registered. usb-storage: device found at 2 usb-storage: waiting for device to settle before scanning Linux video capture interface: v2.00 USB Serial support registered for FTDI USB Serial Device usbcore: registered new interface driver ftdi_sio ftdi_sio: v1.5.0:USB FTDI Serial Converters Driver USB Serial support registered for pl2303 usbcore: registered new interface driver pl2303 pl2303: Prolific PL2303 USB to serial adaptor driver gspca: main v2.7.0 registered usbcore: registered new interface driver zc3xx zc3xx: registered Bluetooth: Core ver 2.15 NET: Registered protocol family 31 Bluetooth: HCI device and connection manager initialized Bluetooth: HCI socket layer initialized Bluetooth: L2CAP ver 2.14 Bluetooth: L2CAP socket layer initialized Bluetooth: SCO (Voice Link) ver 0.6 Bluetooth: SCO socket layer initialized Bluetooth: RFCOMM TTY layer initialized Bluetooth: RFCOMM socket layer initialized Bluetooth: RFCOMM ver 1.11 Bluetooth: BNEP (Ethernet Emulation) ver 1.3 Bluetooth: BNEP filters: protocol multicast Bluetooth: HIDP (Human Interface Emulation) ver 1.2 Bluetooth: HCI UART driver ver 2.2 Bluetooth: HCI H4 protocol initialized Bluetooth: HCI BCSP protocol initialized Bluetooth: Generic Bluetooth USB driver ver 0.6 usbcore: registered new interface driver btusb usbip_common_mod: usbip common driver1.0 vhci_hcd: vhci_hcd, 1.0 usbip: proving... vhci_hcd vhci_hcd: USB/IP Virtual Host Contoroller vhci_hcd vhci_hcd: new USB bus registered, assigned bus number 3 usb usb3: configuration #1 chosen from 1 choice hub 3-0:1.0: USB hub found hub 3-0:1.0: 8 ports detected usbcore: registered new interface driver usbip usbip:Stub Driver for USB/IP:1.0 scsi 0:0:0:0: Direct-Access Generic STORAGE DEVICE 9451 PQ: 0 ANSI: 0 usb-storage: device scan complete sd 0:0:0:0: [sda] Attached SCSI removable disk ar71xx-wdt: enabling watchdog timer > - Which version of OpenWRT are you using ? Could you do an "svn info" > > I'm using exactly this image: http://downloads.openwrt.org/backfire/10.03.1-rc3/ar71xx/openwrt-ar71xx-ubnt-rspro-squashfs-sysupgrade.bin thank you. |
From: Oliver W. <oli...@ol...> - 2010-09-23 17:45:13
|
Hello Enrico, On 09/22/2010 11:36 PM, Enrico Lorenzoni wrote: >> Maybe trying the acx-mac80211 version could also still be interesting >> (via the Advance Configuration Options in the OpenWRT menu config). The >> problem should probably still remain though, since the init-code is not >> very much different. >> >> > Yes, I'm using 20080210 version. > Just for my info: - Could you before loading the module do an "dmesg" and "lspci -v" and sent the output ? - Which version of OpenWRT are you using ? Could you do an "svn info" During the weekend I'll anyway wanted to have a closer look at the updated OpenWRT tree, also to merge Florian patches. Let's see then, what we could do to debug your problem a bit more. Cheers, Ol |
From: Enrico L. <re...@gm...> - 2010-09-22 21:36:07
|
2010/9/22 Oliver Winker <oli...@ol...> > Hi, > > >> acx: reading README file and/or Craig's HOWTO is > > This seems to be the acx-20080210 version of the acx in OpenWRT. > > The "acx: eCPU is already running." log suggest, that it seems to go out > quite in the beginning of acxpci_s_reset_dev(). > > What still puzzles me a bit, although not essential, is that I can't > find the "acx_pci: probe of 0000:00:11.0 failed with error -5" log in > the 20080210 version !? > > Maybe trying the acx-mac80211 version could also still be interesting > (via the Advance Configuration Options in the OpenWRT menu config). The > problem should probably still remain though, since the init-code is not > very much different. > > Yes, I'm using 20080210 version. I tried both acx and acx-mac80211, the error is the same. Thank you. |
From: Oliver W. <oli...@ol...> - 2010-09-22 21:30:10
|
Hi, >> acx: reading README file and/or Craig's HOWTO is This seems to be the acx-20080210 version of the acx in OpenWRT. The "acx: eCPU is already running." log suggest, that it seems to go out quite in the beginning of acxpci_s_reset_dev(). What still puzzles me a bit, although not essential, is that I can't find the "acx_pci: probe of 0000:00:11.0 failed with error -5" log in the 20080210 version !? Maybe trying the acx-mac80211 version could also still be interesting (via the Advance Configuration Options in the OpenWRT menu config). The problem should probably still remain though, since the init-code is not very much different. I didn't observe this error myself yet, but it isn't the same hw neither. Cheers, Ol On 09/22/2010 10:37 AM, Andreas Mohr wrote: > Hi, > > On Tue, Sep 21, 2010 at 08:16:46PM +0200, Enrico Lorenzoni wrote: >> acx: running on a BIG-ENDIAN CPU > > Oh, no mipsel? > >> acx: PCI/VLYNQ module v0.3.37 initialized, waiting for cards to probe... >> >> acx: found ACX111-based wireless network card at 0000:00:11.0, irq:48, >> phymem1:0x10020000, phymem2:0x10000000, mem1:0xb0020000, mem1_size:8192, >> mem2:0xb0000000, mem2_size:131072 >> >> initial debug setting is 0x000A >> >> using IRQ 48 >> >> acx: eCPU is already running. reset_dev() FAILED >> >> acx_pci: probe of 0000:00:11.0 failed with error -5 > > This message has been reported more often in recent times, > thus it appears to be a visible issue. > > I'm afraid that I might have bungled this some years ago. > I did some eCPU init delay changes which might affect this > (stupidly reduced a delay, IIRC). > Fetch a VERY old acx driver and update eCPU init to do it that way, > hopefully that would work. > >> here is my Linux version >> >> Linux OpenWrt 2.6.32.20 #1 Tue Sep 21 18:06:43 CEST 2010 mips GNU/Linux > > # uname -a > Linux XXXXX 2.6.34.5 #2 Fri Sep 17 01:28:35 CEST 2010 mips GNU/Linux > > ;-) > > (WL-500gPv2, Debian extroot, newly upgraded) > > Hrmm, I should probably hook up one more of my DWL-120+ cards to that > USB box, especially since I'm currently trying to make it work as my main > router, but b43 seems to still be problematic, thus acx100 could be > a better choice... > > Andreas Mohr > > ------------------------------------------------------------------------------ > Start uncovering the many advantages of virtual appliances > and start using them to simplify application deployment and > accelerate your shift to cloud computing. > http://p.sf.net/sfu/novell-sfdev2dev > _______________________________________________ > Acx100-users mailing list > Acx...@li... > https://lists.sourceforge.net/lists/listinfo/acx100-users > |
From: Andreas M. <an...@us...> - 2010-09-22 08:52:20
|
Hi, On Tue, Sep 21, 2010 at 08:16:46PM +0200, Enrico Lorenzoni wrote: > acx: running on a BIG-ENDIAN CPU Oh, no mipsel? > acx: PCI/VLYNQ module v0.3.37 initialized, waiting for cards to probe... > > acx: found ACX111-based wireless network card at 0000:00:11.0, irq:48, > phymem1:0x10020000, phymem2:0x10000000, mem1:0xb0020000, mem1_size:8192, > mem2:0xb0000000, mem2_size:131072 > > initial debug setting is 0x000A > > using IRQ 48 > > acx: eCPU is already running. reset_dev() FAILED > > acx_pci: probe of 0000:00:11.0 failed with error -5 This message has been reported more often in recent times, thus it appears to be a visible issue. I'm afraid that I might have bungled this some years ago. I did some eCPU init delay changes which might affect this (stupidly reduced a delay, IIRC). Fetch a VERY old acx driver and update eCPU init to do it that way, hopefully that would work. > here is my Linux version > > Linux OpenWrt 2.6.32.20 #1 Tue Sep 21 18:06:43 CEST 2010 mips GNU/Linux # uname -a Linux XXXXX 2.6.34.5 #2 Fri Sep 17 01:28:35 CEST 2010 mips GNU/Linux ;-) (WL-500gPv2, Debian extroot, newly upgraded) Hrmm, I should probably hook up one more of my DWL-120+ cards to that USB box, especially since I'm currently trying to make it work as my main router, but b43 seems to still be problematic, thus acx100 could be a better choice... Andreas Mohr |
From: Enrico L. <re...@gm...> - 2010-09-21 18:16:53
|
Hi, I own a routerstation pro and a TI card from a g624t. Here is debug when trying to load acx drivers: root@OpenWrt:/# insmod acx acx: this driver is still EXPERIMENTAL acx: reading README file and/or Craig's HOWTO is recommended, visit http://acx100.sf.net in case of further questions/discussion acx: compiled to use 32bit I/O access. I/O timing issues might occur, such as non-working firmware upload. Report them acx: running on a BIG-ENDIAN CPU acx: PCI/VLYNQ module v0.3.37 initialized, waiting for cards to probe... acx: found ACX111-based wireless network card at 0000:00:11.0, irq:48, phymem1:0x10020000, phymem2:0x10000000, mem1:0xb0020000, mem1_size:8192, mem2:0xb0000000, mem2_size:131072 initial debug setting is 0x000A using IRQ 48 acx: eCPU is already running. reset_dev() FAILED acx_pci: probe of 0000:00:11.0 failed with error -5 root@OpenWrt:/# here is my Linux version Linux OpenWrt 2.6.32.20 #1 Tue Sep 21 18:06:43 CEST 2010 mips GNU/Linux thank you. |
From: Oliver W. <oli...@ol...> - 2010-08-14 06:50:25
|
Hello, The acx-mac80211 git repository has moved. The new repository is now located at sourceforge: git://acx100.git.sourceforge.net/gitroot/acx100/acx-mac80211 http://acx100.git.sourceforge.net/git/gitweb.cgi?p=acx100/acx-mac80211;a=summary It replaces the current mac80211-mem branch of oli1417 gitorious clone. To checkout out and build, simply do: git clone git://acx100.git.sourceforge.net/gitroot/acx100/acx-mac80211 (this will bring you directly on the master branch) cd acx-mac80211 make The build and install documentation was updated, and also explains e.g. dkms use. Cheers, Oliver |
From: Oliver W. <oli...@ol...> - 2010-06-20 20:25:50
|
On 06/20/2010 09:26 PM, James Le Cuirot wrote: > From: Oliver Winker <oli...@ol...> > >> I'll have a look at these elements and also at the test setup James > suggested. Need to overlook my network topology at bit for that ;). > > If it's easier, just test to/from the router itself because that exhibits the problem too. Yepp, just figured out how easily the wlan0 can actually be melt into the eth0 bridge of the router using brctl ;). So now the nw path is: ath0_STA -wifi-> acx_AP -eth-> Laptop ... and I can use iperf to measure throughput. It's around 7Mbit/s, which also corresponds to the final results of some subsequent scp tests, which was around 1MB/s (I know, was just to verify ;). That's already a much better test setup than before. So now we can research how to bring it up to the 3.5MB/s. Cheers, Ol --- gamix:~# iperf -c 192.168.11.6 ------------------------------------------------------------ Client connecting to 192.168.11.6, TCP port 5001 TCP window size: 16.0 KByte (default) ------------------------------------------------------------ [ 3] local 192.168.11.4 port 36035 connected with 192.168.11.6 port 5001 [ ID] Interval Transfer Bandwidth [ 3] 0.0-10.0 sec 9.12 MBytes 7.65 Mbits/sec --- lapix:~# iperf -c 192.168.11.4 ------------------------------------------------------------ Client connecting to 192.168.11.4, TCP port 5001 TCP window size: 16.0 KByte (default) ------------------------------------------------------------ [ 3] local 192.168.11.6 port 57387 connected with 192.168.11.4 port 5001 [ ID] Interval Transfer Bandwidth [ 3] 0.0-10.0 sec 8.48 MBytes 7.12 Mbits/sec --- |
From: J. Le C. <ch...@au...> - 2010-06-20 19:27:17
|
From: Oliver Winker <oli...@ol...> > I'll have a look at these elements and also at the test setup James suggested. Need to overlook my network topology at bit for that ;). If it's easier, just test to/from the router itself because that exhibits the problem too. |
From: Oliver W. <oli...@ol...> - 2010-06-20 13:54:35
|
On 06/20/2010 03:36 PM, Andreas Mohr wrote: >> Indeed, that is strange. Because the 0x20 is actually happening right >> from my start on my pcmcia DWL-G650+, and I don't think the card is >> especially warm !? > > Hurmps. IIRC error 0x20 gets signalled in case the card doesn't > successfully receive an ACK frame from peer or some such. This might be > the real thing to investigate. Actually on the acx111, I observed even error==0 frames, but which had several ack_failures ... and one effect was, that my scp test transfers got stalled. So I took ack_failures and rts_failures into account for tx reporting to mac80211, with a 'gut feeling limit' of <2. That did solve the stalled scp. --- if (!(txstatus->flags & IEEE80211_TX_CTL_NO_ACK) && (error == 0) && // OW 20100619 We also take ack and rts failuers into account. // Without this I observed connection stall during scp tests. (ack_failures < 2) && (rts_failures <2) ) txstatus->flags |= IEEE80211_TX_STAT_ACK; --- Well, somehow we'll figure that out. Since the rates were already achieved, all required elements should be somewhere. Target is to get effective 3.5MB/s via 54M on the air without coughing or hicups ;)! > Yup, I made sure to implement extra verbose state debugging. > > Not sure whether debugfs is such a good idea, since it's > developers-only (needs support, extra mounting, and such). > Perhaps move the more specific parts to debugfs and keep "mainstream" > info at /proc? ... or we can also just leave it in proc then. I only thought proc is a bit depreciated, but it's true, debug fs needs to be mounted etc. The only thing to fix then is multiple device support. There the multiple proc dirs collide currently. Cheers, Ol |
From: Andreas M. <an...@us...> - 2010-06-20 13:44:32
|
On Sun, Jun 20, 2010 at 03:08:13PM +0200, Oliver Winker wrote: > Yupp, I see. Actually I thought to use the foreseen > ACX1xx_IE_DOT11_TX_POWER_LEVEL configuration command. Then it should be > under firmware control. Yup, that might even be the only thing that the firmware offers here. > > And I wasn't talking about Tx power stuff, I was talking about radio > > calibration things. But even for those it might be worthwhile to > > completely alter some things there and watch what happens (i.e. whether > > Tx error 0x20 phenomenon then is different in an interesting way). > > The radio calibration for the acx111 is currently done just with a > ACX111_CMD_RADIOCALIB command. I think no further settings are involved > (there three recalib options for the cmd I think, and we take the > automatic option). Yes. I've tried some variations there, but that didn't help a lot, IIRC even in the case of my (locally!) more thermally induced 0x20 issue. > Indeed, that is strange. Because the 0x20 is actually happening right > from my start on my pcmcia DWL-G650+, and I don't think the card is > especially warm !? Hurmps. IIRC error 0x20 gets signalled in case the card doesn't successfully receive an ACK frame from peer or some such. This might be the real thing to investigate. > > Possibly a matter of adding more debugging infrastructure (debugfs > > etc.), to be able to do even more snapshotting of descriptor status, > > flags etc. > > Ok, via proc acx_diag we already have a quite good view on the > descriptors (I planned to move the proc things to debugfs one moment). Yup, I made sure to implement extra verbose state debugging. Not sure whether debugfs is such a good idea, since it's developers-only (needs support, extra mounting, and such). Perhaps move the more specific parts to debugfs and keep "mainstream" info at /proc? Andreas |
From: Oliver W. <oli...@ol...> - 2010-06-20 13:08:24
|
On 06/20/2010 12:17 PM, Andreas Mohr wrote: > Well, even 20080201 might be much too new (read: "broken") ;) Ok, I'll keep that in mind. > Screwing with low-level Tx power settings probably isn't a good idea, > so one might want to (temporarily?) disable them. > Simply use the tools that the firmware provides (or not even those, > i.e. use firmware default). > That way you have a "default" situation regarding the Tx error issue. Yupp, I see. Actually I thought to use the foreseen ACX1xx_IE_DOT11_TX_POWER_LEVEL configuration command. Then it should be under firmware control. > And I wasn't talking about Tx power stuff, I was talking about radio > calibration things. But even for those it might be worthwhile to > completely alter some things there and watch what happens (i.e. whether > Tx error 0x20 phenomenon then is different in an interesting way). The radio calibration for the acx111 is currently done just with a ACX111_CMD_RADIOCALIB command. I think no further settings are involved (there three recalib options for the cmd I think, and we take the automatic option). > Also, Tx error 0x20 pretty much means that the card simply isn't able to > send the frame, _for whatever reason_. See also doc/TODO in old driver, > some comments there. > We "simply" need to figure out the remaining most annoying reason why > the frames cannot be sent... > (_sometimes_ it's overheating... but in several other cases the reason(s!?) > must be something different) Indeed, that is strange. Because the 0x20 is actually happening right from my start on my pcmcia DWL-G650+, and I don't think the card is especially warm !? > Possibly a matter of adding more debugging infrastructure (debugfs > etc.), to be able to do even more snapshotting of descriptor status, > flags etc. Ok, via proc acx_diag we already have a quite good view on the descriptors (I planned to move the proc things to debugfs one moment). I'll have a look at these elements and also at the test setup James suggested. Need to overlook my network topology at bit for that ;). Cheers, Oliver |
From: Andreas M. <an...@us...> - 2010-06-20 10:17:21
|
Hi, On Sun, Jun 20, 2010 at 11:08:56AM +0200, Oliver Winker wrote: > Hi Andreas, > > On 06/20/2010 10:28 AM, Andreas Mohr wrote: > > Since you say "stock" it's likely to be an original vendor image using > > a TI driver. Very interesting data point. That would suggest (but it's > > not definite, might be some hardware variation such as only specific > > radio types!) that it's us that must be doing something "wrong" > > to cause all those Tx error 0x20. > > Normally, the low level tx and rx descriptor processing itself should be > pretty much the same as the previous driver (I'm often taking the > previous 20080201 driver as reference to check). The descriptors are > prepared, now we also specify the rate bits, and then we ask the acx to > send out the frame in monitor mode. Well, even 20080201 might be much too new (read: "broken") ;) > I'll see for the tx power setting. Maybe that brings already some new > findings. Screwing with low-level Tx power settings probably isn't a good idea, so one might want to (temporarily?) disable them. Simply use the tools that the firmware provides (or not even those, i.e. use firmware default). That way you have a "default" situation regarding the Tx error issue. And I wasn't talking about Tx power stuff, I was talking about radio calibration things. But even for those it might be worthwhile to completely alter some things there and watch what happens (i.e. whether Tx error 0x20 phenomenon then is different in an interesting way). Also, Tx error 0x20 pretty much means that the card simply isn't able to send the frame, _for whatever reason_. See also doc/TODO in old driver, some comments there. We "simply" need to figure out the remaining most annoying reason why the frames cannot be sent... (_sometimes_ it's overheating... but in several other cases the reason(s!?) must be something different) Possibly a matter of adding more debugging infrastructure (debugfs etc.), to be able to do even more snapshotting of descriptor status, flags etc. Andreas Mohr |
From: Oliver W. <oli...@ol...> - 2010-06-20 09:09:06
|
Hi Andreas, On 06/20/2010 10:28 AM, Andreas Mohr wrote: > Since you say "stock" it's likely to be an original vendor image using > a TI driver. Very interesting data point. That would suggest (but it's > not definite, might be some hardware variation such as only specific > radio types!) that it's us that must be doing something "wrong" > to cause all those Tx error 0x20. Normally, the low level tx and rx descriptor processing itself should be pretty much the same as the previous driver (I'm often taking the previous 20080201 driver as reference to check). The descriptors are prepared, now we also specify the rate bits, and then we ask the acx to send out the frame in monitor mode. The irq handling and tx_queue loading changed a bit. There I took some inspirations from other drivers, and basically it also works quite well. Maybe there is some rx/tx processing latency, but I think, that wouldn't actually influence transmission and/or the tx-error itself (well ... just according to my understanding ;), who knows). But it's already good to know: so the .11g target is 3.5MB/s. Ok :) I'll see for the tx power setting. Maybe that brings already some new findings. Cheers, Oliver |
From: Oliver W. <oli...@ol...> - 2010-06-20 08:43:21
|
Hi James, On 06/20/2010 09:11 AM, James Le Cuirot wrote: > > I've been testing with scp too but never trust those reported speeds! > scp is known to get these totally wrong. I don't know why it's never > been fixed. It usually starts out very high, and then gradually drops > towards the real speed but hits 100% before it gets there. It then sits > there with the same output for ages while it actually finishes the > transfer before finally exiting. I've seen this on several systems. > Instead, I'm getting the speeds from gkrellm on my desktop, which I > know to be reliable. Ok - Thanks for the info. Indeed, I observe the same phenomena with scp. Good to know, that this actually not very reliable. gkrellm is running on my desktop too. Until now more for decorative reasons, but if it works well for measuring, then that's even better ;). > In terms of what to expect, I tested sending a randomised file to the > router itself, a wired client connected to the router and a wireless > client connected directly to my desktop. The latter transfer was at > least 10x faster than the other two, around 1.2MB/s (bytes not bits!). > I could only get around 100KB/s with the others. Ok, that's a good idea. I'll also see to connect a wired client to the WAG router (good idea, actually; didn't thought about this before ;)!? ). > As I said before, going in the other direction is much worse. I suspect > that receiving actually works okay but you need a little transmitting > bandwidth in order to receive so if transmitting is badly broken, maybe > it's hampering receiving as well. Alright, so I though the next best reasonable action for this could indeed be, to finally fix the tx power setting. Probably that's not so complicated. Mid term the rx and tx paths inside the driver could maybe also be speed-up still a bit (irq iteration to avoid work queue scheduling latency), but let's see the tx power maybe first. I'll see to have a look at this soon as well. There are just several items currently active, so I'll see how to combine this (some code re-orga and cleanup (helps for maintenance); problem with scanning during connection on the hx; tx power; reliable, wl12xx-like if up/down). > I'm going away for a couple of days so catch you then. Ok, see you then. Let you know, when there is something new. Cheers, Ol |