15.07.2014 23:26, Nikolai Zhubr:
[...]
And I've performed yet another experiment. If I insert an additional
router (running also openwrt but atheros-based) between this WL-500W and
uplink (with the idea to filter out any strange and bogus incoming
packets) and redo the same test, I get no panic b
15.07.2014 12:04, Nikolai Zhubr:
15.07.2014 1:42, Jonas Gorski:
[...]
or
bw32(bp, B44_RXMAXLEN, bp->dev->mtu + ETH_HLEN + 8) ?
This is the right one; mtu (the "payload") + ETH_HLEN (14 bytes) + 8
(4 bytes for vlan tag, probably 4 extra bytes for custom header
optionally used by broadcom switch
15.07.2014 1:42, Jonas Gorski:
[...]
or
bw32(bp, B44_RXMAXLEN, bp->dev->mtu + ETH_HLEN + 8) ?
This is the right one; mtu (the "payload") + ETH_HLEN (14 bytes) + 8
(4 bytes for vlan tag, probably 4 extra bytes for custom header
optionally used by broadcom switches)
Ok, tested this. Unfortunate
On Mon, Jul 14, 2014 at 11:35 PM, Rafał Miłecki wrote:
> On 14 July 2014 18:44, Jonas Gorski wrote:
>> On Mon, Jul 14, 2014 at 6:23 PM, Felix Fietkau wrote:
>>> It looks to me like the hardware is overwriting the skb shared info (at
>>> the end of the skb data buffer), possibly because the confi
On Mon, Jul 14, 2014 at 11:48 PM, Nikolai Zhubr wrote:
> 14.07.2014 20:44, Jonas Gorski:
> [...]
>
>>> If I were to speculate wildly, I would guess that B44_RXMAXLEN refers to
>>> the maximum frame length, not the maximum buffer length - and in the
>>> code, it's being fed with the maximum buffer
On 14 July 2014 18:44, Jonas Gorski wrote:
> On Mon, Jul 14, 2014 at 6:23 PM, Felix Fietkau wrote:
>> It looks to me like the hardware is overwriting the skb shared info (at
>> the end of the skb data buffer), possibly because the configured maximum
>> frame length may be too big for the buffer.
14.07.2014 20:44, Jonas Gorski:
[...]
If I were to speculate wildly, I would guess that B44_RXMAXLEN refers to
the maximum frame length, not the maximum buffer length - and in the
code, it's being fed with the maximum buffer length.
This would allow the hardware to receive slightly oversized fram
On Mon, Jul 14, 2014 at 6:23 PM, Felix Fietkau wrote:
> On 2014-07-14 16:42, Rafał Miłecki wrote:
>> On 21 June 2014 18:36, Nikolai Zhubr wrote:
>>> [ 637.43] [ cut here ]
>>> [ 637.44] WARNING: at net/core/dev.c:2194
>>> skb_warn_bad_offload+0xc0/0xe8()
>>> [ 6
On 2014-07-14 16:42, Rafał Miłecki wrote:
> On 21 June 2014 18:36, Nikolai Zhubr wrote:
>> [ 637.43] [ cut here ]
>> [ 637.44] WARNING: at net/core/dev.c:2194
>> skb_warn_bad_offload+0xc0/0xe8()
>> [ 637.45] b44: caps=(0x4000, 0x)
14.07.2014 18:42, Rafał Miłecki:
[...]
[ 637.56] Call Trace:
[ 637.56] [<80010bb4>] show_stack+0x48/0x70
[ 637.57] [<80019bd4>] warn_slowpath_common+0x78/0xa8
[ 637.57] [<80019c30>] warn_slowpath_fmt+0x2c/0x38
[ 637.58] [<801b27dc>] skb_warn_bad_offload+0xc0/0xe8
[ 637.5
On 21 June 2014 18:36, Nikolai Zhubr wrote:
> [ 637.43] [ cut here ]
> [ 637.44] WARNING: at net/core/dev.c:2194
> skb_warn_bad_offload+0xc0/0xe8()
> [ 637.45] b44: caps=(0x4000, 0x) len=1500
> data_len=0 gso_size=53118 gso_type=59
21.06.2014 0:23, Rafał Miłecki:
On 20 June 2014 22:12, Nikolai Zhubr wrote:
There are tons of updates in trunk, this bug can be fixed for a long
time already ;)
Unfortunately it seems no :/
Also, with trunk version, routing speed limit seems to be noticably
lower (~27 Mbit trunk compared to ~
21.06.2014 0:23, Rafał Miłecki:
[...]
This time uplink load was even no more than 20 Mbit.
Here is what I got (although it doesn't look very promising to me).
Maybe I should enable some more debugging somewhere?
[ 543.432000] Unhandled kernel unaligned access[#1]:
[ 543.432000] Cpu 0
[ 543.432
On 20 June 2014 22:12, Nikolai Zhubr wrote:
> 2. At some point I get (on a serial link):
> [ 368.948000] sched: RT throttling activated
> [ 382.688000] Unhandled kernel unaligned access[#1]:
> trim
> [ 382.932000] Kernel panic - not syncing: Fatal exception in interrupt
> [ 382.94]
Hello people,
I have asus wl-500W router (http://wiki.openwrt.org/toh/asus/wl500w). It
is also very similar to wl-500gp.
Some few months ago I updated to 12.09. I can't recall now if it was
backfire or kamikaze before, but I noticed 2 things immediately:
1. Maximum practically achievable down
15 matches
Mail list logo
