Hi Oliver and everybody reading this message.
So V3 of this patch fixed the issue I reported recently.
I wasn't properly accounting for the NDP size when writing new packets to the
SKB: so i ended up writing past the end of SKB buffer.
Thank you for your patience and help.
Enrico
--
To unsubsc
So, here is what I tried so far:
1 - Check if the pointer gets corrupted somehow (address change): it seems this
doesn't happen at all.
2 - Size problems: I tried setting higher values of the size just in case, with
absolutely no changei n behaviour.
The code that assigns the pointer the addre
Hi Oliver, hello to who is reading this message.
i was re-reading the code and the oops, without understanding what's the
problem. Still: what impressed me is the fact that at some point you see NULL
ptr dereference in unrelated code (fbcon). Is it possible that at some point
the memory portio
Just to be clear - this happens on the real machine as well, but here the trace
is difficult to extract, because even with the help of someone seeing the
screen, I noticed the screen doesn't get updated. I am using vesa right now.
--
To unsubscribe from this list: send the line "unsubscribe netd
Sure Oliver!
Here it is.
And - I tried with various approach. I tired also kzallocating the needed
memory inside the tx_fixup function using the GFP_ATOMIC flag due to the fact I
am in an interrupt handler.
At some point, the problem started manifesting in a memset call that whasn't in
my patc
On Sun, 2015-07-05 at 12:21 +0200, Enrico Mioso wrote:
> When sending lots of small packets, this patch will generate an "Unable to
> handle kernel paging request" in the memset call:
> ndp16 = memset(ctx->delayed_ndp16, 0, ctx->max_ndp_size);
> And I don't know why.
> Any comment or suggestion wo
When sending lots of small packets, this patch will generate an "Unable to
handle kernel paging request" in the memset call:
ndp16 = memset(ctx->delayed_ndp16, 0, ctx->max_ndp_size);
And I don't know why.
Any comment or suggestion would be greatly apreciated.
This has been reproduced in a QEMU X8
NCM specs are not actually mandating a specific position in the frame for
the NDP (Network Datagram Pointer). However, some Huawei devices will
ignore our aggregates if it is not placed after the datagrams it points
to. Add support for doing just this, in a per-device configurable way.
While at it,
