acx-mac80211: Git repository has moved

2010-08-14
2013-02-17
  • Oliver Winker

    Oliver Winker - 2010-08-14

    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 the 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

     
  • Hubbitus

    Hubbitus - 2010-08-17

    It leads to Kernel panic:
    #ifup wlan0
    Статус активного соединения: активация
    Путь активного соединения: /org/freedesktop/NetworkManager/ActiveConnetcion/2
    Kernel panic - not syncing stack-protector: Kernel stack is corrupted in fa0d…

    Sorry for the Russsin in message, I got it from monitor photography and hope NetworkManager massage is not related, translate it will:

    #ifup wlan0
    Status of active connection: activating
    Path of active connection: /org/freedesktop/NetworkManager/ActiveConnetcion/2
    Kernel panic - not syncing stack-protector: Kernel stack is corrupted in fa0d…

    Kernel 2.6.33.6-147.2.4.fc13.i686

     
  • Oliver Winker

    Oliver Winker - 2010-08-17

    Hello hubbitus,

    I just tried on my 2.6.33.2 kernel, which has also has CONFIG_CC_STACKPROTECTOR=y set, with WPA and AD-HOC, but no problem seen … !?

    Which network mode are you trying exactly (ad-hoc) ?

    Could you sent me by email the photo with the panic and dmesg output until before the ifup ?

    I'll see, if I can reproduce it with your precise Ubuntu kernel.

    Cheers, Ol

     
  • Hubbitus

    Hubbitus - 2010-08-18

    I confirm kernel compiled with CONFIG_CC_STACKPROTECTOR:

    $ grep 'CONFIG_CC_STACKPROTECTOR' /boot/config-`uname -r`
    CONFIG_CC_STACKPROTECTOR=y

    I use ad-hoc without any encryption.

    Photo from mobile phone: http://hosting-help.ru/_/BUGS/acx111/stack-protection-kernel-panic.jpg
    About dmesg not understand correctly. You want it before ifup? For what? As I can understand it still does not content anything relied to acx while module not loaded? Meantime, off course it is not problem, I can send it today evening (now I have only remote access to this computer, so kernel panic even don't give me ability to reboot).

    And I use Fedora kernel, not Ubuntu.

     
  • Oliver Winker

    Oliver Winker - 2010-08-18

    Hi hubbitus,

    Thanks for the photo, hmm - unfortunately no stack trace. Never saw a stack-protector panic before.

    For the dmesg: I would be interested see the beginning of the driver starting up and it could contain also other useful info. So if you could sent it (driver loaded, just until before the ifup), that would be good.

    I'll further see if I can reproduce it here - maybe I can build the Fedora 2.6.33.6-147.2.4.fc13.i686 kernel and make a Debian package of it. Installing the rpms like this is maybe not a good idea - the file layout seems different.

    Could you maybe also try on another kernel, e.g. 2.6.32, 34, 35 ?

    Cheers, Ol

     
  • Oliver Winker

    Oliver Winker - 2010-08-18

    Hi hubbitus,

    I build a kernel for debian with the precisely the Fedora kernel-2.6.33.6-147.2.4.fc13.src.rpm kernel sources. Then I tested ad-hoc and wpa with the driver on and build for this kernel, but no crash or stack-protector panic !?

    Let's see if another kernel changes maybe something on your side and let's have a look at the dmesg.

    -Ol

     
  • Hubbitus

    Hubbitus - 2010-08-23

    Sorry, but I can't reproduce it anymore.
    I don't known reason why. I have only one guess - it fixed by last glibc update happened few days ago.

    Thank you very much in any case.

     
  • Oliver Winker

    Oliver Winker - 2010-08-23

    Ok - That's good news ;)!

    Thanks for the update, Oliver

     
  • Moritz Wilhelmy

    Moritz Wilhelmy - 2011-09-02

    Hello,

    it seems I have the same problem on slackware 13.37, just that I don't even get around to set it in ad-hoc mode:

    # ifconfig -a
    eth0      Link encap:Ethernet  HWaddr 00:0F:1F:73:9A:F4  
              inet addr:192.168.1.1  Bcast:192.168.1.255  Mask:255.255.255.0
              inet6 addr: fe80::20f:1fff:fe73:9af4/64 Scope:Link
              UP BROADCAST RUNNING MULTICAST  MTU:1500  Metric:1
              RX packets:52 errors:0 dropped:0 overruns:0 frame:0
              TX packets:42 errors:0 dropped:0 overruns:0 carrier:0
              collisions:0 txqueuelen:1000 
              RX bytes:7426 (7.2 Kb)  TX bytes:6481 (6.3 Kb)
    lo        Link encap:Local Loopback  
              inet addr:127.0.0.1  Mask:255.0.0.0
              inet6 addr: ::1/128 Scope:Host
              UP LOOPBACK RUNNING  MTU:16436  Metric:1
              RX packets:0 errors:0 dropped:0 overruns:0 frame:0
              TX packets:0 errors:0 dropped:0 overruns:0 carrier:0
              collisions:0 txqueuelen:0 
              RX bytes:0 (0.0 b)  TX bytes:0 (0.0 b)
    wlan0     Link encap:Ethernet  HWaddr 00:13:46:B0:CE:14  
              BROADCAST MULTICAST  MTU:1500  Metric:1
              RX packets:0 errors:0 dropped:0 overruns:0 frame:0
              TX packets:0 errors:0 dropped:0 overruns:0 carrier:0
              collisions:0 txqueuelen:1000 
              RX bytes:0 (0.0 b)  TX bytes:0 (0.0 b)
              Interrupt:19 Base address:0xe000 
    # iwconfig
    lo0     no wireless extensions.
    eth0   no wireless extensions.
    [   42.522110] Kernel panic - not syncing: stack-protector: Kernel stack is corrupted in: c190c163
    [   42.522113]
    [   42.522355] Pid: 1602, comm: iwconfig Tainted: P             2.6.37.6-smp #2
    [   42.522453] Call Trace:
    [   42.522552]  [<c19daa01>] ? printk+0x1d/0x1f
    [   42.522650]  [<c19da8f3>] panic+0x5c/0x14d
    [   42.522749]  [<c19ab858>] ? wext_handle_ioctl+0x1a8/0x220
    [   42.522848]  [<c10427be>] __stack_chk_fail+0x1e/0x20
    [   42.522949]  [<c190c163>] ? dev_ioctl+0x2e3/0x670
    [   42.523064]  [<c190c163>] dev_ioctl+0x2e3/0x670
    [   42.523173]  [<c1064eaa>] ? up+0x2a/0x40
    [   42.523280]  [<c18f7a5b>] sock_ioctl+0x1db/0x280
    [   42.523391]  [<c18f7880>] ? sock_ioctl+0x0/0x280
    [   42.523496]  [<c11076fe>] do_vfs_ioctl+0x7e/0x5c0
    [   42.523602]  [<c155c30d>] ? tty_ldisc_deref+0x0d/0x10
    [   42.523713]  [<c1555c71>] ? tty_write+0x1b1/0x200
    [   42.523827]  [<c10f9401>] ? vfs_write+0x101/0x170
    [   42.523939]  [<c1555ac0>] ? tty_write+0x0/0x200
    [   42.524068]  [<c1107ca7>] sys_ioctl+0x67/0x80
    [   42.524179]  [<c19dd5ac>] syscall_call+0x7/0xb
    

    These four patches are applied:
    http://paste.xinu.at/YFT/plain
    http://paste.xinu.at/dJ9m/plain
    http://paste.xinu.at/wNZ/plain
    http://paste.xinu.at/YFT/plain

    (They are part of the archlinux package http://aur.archlinux.org/packages.php?ID=49708, and I'm a lazy bastard…)

    The particular card is this one:

    02:0a.0 Network controller: Texas Instruments ACX 111 54Mbps Wireless Interface
    

    Best regards,

    Moritz

     
  • Moritz Wilhelmy

    Moritz Wilhelmy - 2011-09-02

    Hello,

    git HEAD seems ok. Maybe you should release again :-)
    Given that the latest release is from 2008, I almost thought the project was dead, so I'm glad to find out it isn't!

    Sorry for posting in the wrong, dead thread.

    Best,

    Moritz

     
  • Oliver Winker

    Oliver Winker - 2011-09-03

    Hi Moritz,

    Thanks for the feedback! Indeed, the main repo right now is the git one. Maybe we should indeed make a release one time again ;). I'm just held up a bit in the moment with hx4700 things … . Let's see!

    Best Regards, Oliver  

     
  • Andreas Mohr

    Andreas Mohr - 2011-09-04

    http://sourceforge.net/projects/acx100/

    (just filled in the Features items, most importantly to make sure people
    do have a better chance to note the git tree requirement)

    Thanks a ton to Oliver for his continued heroic development efforts!

     
  • Oliver Winker

    Oliver Winker - 2011-09-06

    Hi Andreas,

    Good idea :)! Thanks a lot! Maybe we could see, how to make more regular releases. Currently I'm on vacation and depending on camping wifi APs ;).

    Greetings, Oliver

     
  • lostdistance

    lostdistance - 2012-01-04

    Hi Oliver,

    I have the acx driver working on the very latest linux-3.2-rc7 on my iPAQ hx4700. I wanted to say thank you for your continued work here.

    The source did require a few tweaks before it would compile:
    1. The conf_tx handler has acquired a new argument.
    2. common.c now seems to need <net/iw_handler.h>
    3. hx4700_acx.c now seems to need <linux/module.h>

    Index: acx_func.h

    RCS file: /home/cvsroot/software/ipaq/kernel/acx-cvs/acx_func.h,v
    retrieving revision 1.1
    retrieving revision 1.3
    diff -u -r1.1 -r1.3
    -- acx_func.h 1 Jan 2012 00:30:30 -0000 1.1
    +++ acx_func.h 1 Jan 2012 00:59:11 -0000 1.3
    @@ -376,7 +376,7 @@

    void acx_op_configure_filter(struct ieee80211_hw *hw,
    unsigned int changed_flags, unsigned int *total_flags, u64 multicast);
    -int acx_conf_tx(struct ieee80211_hw* ieee, u16 queue,
    +int acx_conf_tx(struct ieee80211_hw* ieee, struct ieee80211_vif *vif, u16 queue,
    const struct ieee80211_tx_queue_params *params);
    int acx_op_get_stats(struct ieee80211_hw *hw, struct ieee80211_low_level_stats *stats);

    Index: common.c

    RCS file: /home/cvsroot/software/ipaq/kernel/acx-cvs/common.c,v
    retrieving revision 1.1
    retrieving revision 1.3
    diff -u -r1.1 -r1.3
    -- common.c 1 Jan 2012 00:30:30 -0000 1.1
    +++ common.c 1 Jan 2012 00:54:31 -0000 1.3
    @@ -36,6 +36,7 @@
    #include <linux/ratelimit.h>
    #endif

    +#include <net/iw_handler.h>
    #include <net/mac80211.h>

    #include "acx.h"
    @@ -246,7 +247,7 @@
    void acx_op_bss_info_changed(struct ieee80211_hw *hw, struct ieee80211_vif *vif, struct ieee80211_bss_conf *info, u32 changed);
    int acx_op_set_key(struct ieee80211_hw *hw, enum set_key_cmd cmd, struct ieee80211_vif *vif, struct ieee80211_sta *sta, struct ieee80211_key_conf *key);
    void acx_op_configure_filter(struct ieee80211_hw *hw, unsigned int changed_flags, unsigned int *total_flags, u64 multicast);
    -int acx_conf_tx(struct ieee80211_hw *hw, u16 queue, const struct ieee80211_tx_queue_params *params);
    +int acx_conf_tx(struct ieee80211_hw *hw, struct ieee80211_vif *vif, u16 queue, const struct ieee80211_tx_queue_params *params);
    int acx_op_get_stats(struct ieee80211_hw *hw, struct ieee80211_low_level_stats *stats);

    #if CONFIG_ACX_MAC80211_VERSION < KERNEL_VERSION(2, 6, 34)
    @@ -6675,7 +6676,7 @@
    FN_EXIT0;
    }

    -int acx_conf_tx(struct ieee80211_hw *hw,
    +int acx_conf_tx(struct ieee80211_hw *hw, struct ieee80211_vif *vif,
    u16 queue, const struct ieee80211_tx_queue_params *params)
    {
    acx_device_t *adev = ieee2adev(hw);
    Index: hx4700_acx.c
    ===================================================================
    RCS file: /home/cvsroot/software/ipaq/kernel/acx-cvs/hx4700_acx.c,v
    retrieving revision 1.1
    retrieving revision 1.2
    diff -u -r1.1 -r1.2
    -- hx4700_acx.c 1 Jan 2012 00:30:30 -0000 1.1
    +++ hx4700_acx.c 1 Jan 2012 00:55:49 -0000 1.2
    @@ -12,6 +12,7 @@

    #include <linux/kernel.h>
    +#include <linux/module.h>
    #include <linux/platform_device.h>
    #include <linux/delay.h>
    #include <linux/leds.h>

    Regards,
    Paul

     
  • Oliver Winker

    Oliver Winker - 2012-01-04

    Hi Paul,

    Thanks a lot! ;)

    I'll include these then when 3.2 comes out (seems like next week or so). Usually I'll do the kernel version adaptation following the kernel release.

    Cheers, Oliver

     
  • lostdistance

    lostdistance - 2012-01-06

    The source requires another tweak which I've only just figured out.

    I was getting section mismatches with linux-3.2-rc7, so as a temporary hack I removed some __init/__exit attributes. Going back, I enabled CONFIG_DEBUG_SECTION_MISMATCH for detailed warnings and suggestions. One of the suggestions provided the fix: rename  acxmem_drv_id to *driver, in this case acxmem_driver. I have no idea what this is about, but it did fix the section mismatches:

    diff -ru a/mem.c b/mem.c
    -- a/mem.c 2011-12-31 21:50:23.383192226 +0000
    +++ b/mem.c 2012-01-06 18:57:59.341244030 +0000
    @@ -5338,7 +5338,7 @@
    #endif /* CONFIG_PM */

    -static struct platform_driver acxmem_drv_id = {
    +static struct platform_driver acxmem_driver = {
    .driver = {
    .name = "acx-mem",
    },
    @@ -5382,7 +5382,7 @@
    "waiting for cards to probe…\n"
    );

    - res = platform_driver_register(&acxmem_drv_id);
    + res = platform_driver_register(&acxmem_driver);
    FN_EXIT1(res);
    return res;
    }
    @@ -5397,7 +5397,7 @@
    FN_ENTER;

    printk("acxmem: cleanup_module\n");
    - platform_driver_unregister(&acxmem_drv_id);
    + platform_driver_unregister(&acxmem_driver);

    FN_EXIT0;
    }

     
  • lostdistance

    lostdistance - 2012-01-06

    It's probably better if I post the patches to Tracker/Patches!

     
  • KENDRICK CURRY

    KENDRICK CURRY - 2012-01-06

    Thanks so much for the patches "lostdistance", i've been trying to get this working on the htc universal for a while now.

     
  • lostdistance

    lostdistance - 2012-01-07

    I've actually gone a bit further. I've managed to eliminate the small hx4700_acx module completely by:

    1. Moving the hx4700 platform glue into the kernel (arch/arm/mach-pxa/hx4700.c).
    2. Removing the hx4700 module start/stop routines (hx4700_wlan_init() & hx4700_wlan_exit()), which are no longer needed.
    3. Linking the hx4700 hardware start/stop routines (hx4700_wlan_start() & hx4700_wlan_stop(), now renamed acxmem_wlan_start() & acxmem_wlan_stop()) into the MEM variant of the driver.

    I've done likewise for the rx1950 code, though I have no way of testing it.

    This means that building the MEM variant of the driver yields a single module, acx-mac80211, just like like the PCI and USB variants. All very tidy.

    It might also be the first step in merging the acx driver into the mainline kernel. I understand that legal niceties have prevented this so far. But the hx4700/rx1950 platform glue really has nothing to do with the acx and so in theory could go in now.

    If you're interested I can post more patches to Tracker/Patches.

    Regards,
    Paul

     
  • Oliver Winker

    Oliver Winker - 2012-01-07

    Hi Paul,

    Thanks for the patches in the tracker ;). I see if I find the time for 3.2 update this weekend.

    Indeed, the section mismatch was also on the list - since it didn't hurt until now, I still let it go. Another fix for this would be adding a "__refdata" attribute, so that the thing arrives in the right section. (static struct platform_driver __refdata acxmem_drv_id {). Maybe your solution is still nicer ;) (more conform). I'll see onetime how other drivers are doing this.

    Regarding moving the platform parts to hx4700.c, etc.: I see the point, that it would allow to make things a bit more tidy (one module instead of two, good). On the other hand I think it's good to keep also these parts still with the driver itself - since right now it is still an out of tree driver.

    Best Regards, Oliver

     

Log in to post a comment.

Get latest updates about Open Source Projects, Conferences and News.

Sign up for the SourceForge newsletter:





No, thanks