I suppose it is the same problem I had with iptables (reported on 06 Oct
2010).
When I rename /usr/libgcc_s.so.1 to something else, the samba3 package
compiles without problems!
I suppose something is wrong with the cross compiler as it tries to link
using my native/host libraries instead of the
bjorn.smed...@venatech.se:
> Wouldn't it make more sense to configure beacon interval per
> wifi-iface? This is how mac80211 does it and there is at least talk
> about supporting different beacon intervals for different ap vifs with
> ath9k.
It’s configured via hostapd, which only supports the bea
On Wed, Mar 2, 2011 at 9:45 PM, Mark Mentovai wrote:
> This introduces beacon_int and basic_rate (per wifi-device), and
> dtim_period and max_listen_int (per wifi-iface) for mac80211. These
> configure the beacon interval, basic rate specification, DTIM period
> (one DTIM per this many beacon fram
On 2011-03-02 9:45 PM, Mark Mentovai wrote:
> This introduces beacon_int and basic_rate (per wifi-device), and
> dtim_period and max_listen_int (per wifi-iface) for mac80211. These
> configure the beacon interval, basic rate specification, DTIM period
> (one DTIM per this many beacon frames), and m
I received a request for more information, so in case anyone else is
interested, here’s what was happening.
The problem occurs in hostapd src/ap/ieee802_11.c’s send_assoc_resp.
The C statement that triggers the compiler bug is
reply->u.assoc_resp.aid = host_to_le16((sta ? sta->aid : 0)
This introduces beacon_int and basic_rate (per wifi-device), and
dtim_period and max_listen_int (per wifi-iface) for mac80211. These
configure the beacon interval, basic rate specification, DTIM period
(one DTIM per this many beacon frames), and maximum listen interval
that a STA will be permitted
On Thu, Mar 3, 2011 at 5:27 AM, Mark Mentovai wrote:
> Felix Fietkau wrote:
>> Actually, it emits -16384 in both the working and non-working case,
>> I think what makes the difference of working vs non-working is this:
>>
>> Broken: (0xc000 is in v0)
>> - e8: 00021a02 srl v1
ZioPRoTo (Saverio Proto) wrote:
>> The source tree is tagged. LuCI is tagged. But "packages" apparently isn't.
>
> this thing of having packages feed tagged comes back from time to time.
>
> in my opinion is that the developers community of OpenWRT has no
> interest in keeping a tagged packages t
Jo-Philipp Wich wrote:
> -src-svn packages svn://svn.openwrt.org/openwrt/packages
> +src-svn packages svn://svn.openwrt.org/openwrt/packages@20732
>
> Revision taken from https://dev.openwrt.org/milestone/Backfire%2010.03
Thank you so much! Would you mind tagging it? Also, it would be nice to hav
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
On 01.03.2011 22:47, Daniel A. Nagy wrote:
> Hello,
>
> I am wondering how to make sure that a re-compilation of a released (tagged)
> OpenWrt distribution from svn would result in compiling the same packages that
> come from feeds, as feeds.conf.defa
> The source tree is tagged. LuCI is tagged. But "packages" apparently isn't.
this thing of having packages feed tagged comes back from time to time.
in my opinion is that the developers community of OpenWRT has no
interest in keeping a tagged packages tree.
Saverio
_
On 3/1/11 7:44 PM, Daniel A. Nagy wrote:
Hello,
On 03/02/2011 04:36 AM, devendra.aaru wrote:
hello,
you can do this by
touch package/your-package-name/Makefile
and compile openwrt which ensures that your-package-name compiles.
or you can delete whole build
Felix Fietkau wrote:
> Actually, it emits -16384 in both the working and non-working case,
> I think what makes the difference of working vs non-working is this:
>
> Broken: (0xc000 is in v0)
> - e8:00021a02srl v1,v0,0x8
> - ec:00021200sll v0,v0,0x8
>
On 2011-03-02 4:25 PM, Mark Mentovai wrote:
> Felix Fietkau wrote:
>> Scratch that, got confused by the delay slot for a second there :)
>> I see the code that adds the wrong bits now, I wonder if there's
>> something wrong with signed vs unsigned type propagation...
>> I'll let you know when I fin
Felix Fietkau wrote:
> Scratch that, got confused by the delay slot for a second there :)
> I see the code that adds the wrong bits now, I wonder if there's
> something wrong with signed vs unsigned type propagation...
> I'll let you know when I find out more about this.
I agree that signed/unsign
Hello,
I have sent you two patches for opencdk in quick succession on January 17, and
only one of them has been applied. Just so that you don't need to delve into the
archive, here is the other patch again. It is for handling DOS-style line
endings (/r/n) correctly.
Thanks in advance!
Signed-off
On 2011-03-02 2:38 PM, Felix Fietkau wrote:
> Hi Mark,
>
> good catch! I'm currently comparing assembly trying to figure out what
> triggers the miscompilation. I'm reluctant to commit this patch, as it
> its quite possible that this compiler issue may be causing more bugs
> that we just haven't f
On 2011-03-02 6:14 AM, Mark Mentovai wrote:
> mips-openwrt-linux-uclibc-gcc 4.5.2 (Linaro GCC 4.5-2011.02-0), the
> default compiler for MIPS since r25708, miscompiles send_assoc_resp in
> hostapd's src/ap/ieee802_11.c. Specifically, the association ID (AID)
> field in the association response fram
For the 2.6.37 kernel another config option must be enabled:
CONFIG_NET_IPGRE_DEMUX the gre demuxer before the IP transport
can be chosen. The kmod-gre package was not build.
This package fixes that, but it contains 2(!) modules: gre.ko and
ip_gre.ko . So anybody insmodding ip_gre.ko must now also
19 matches
Mail list logo
