similar to: [Bug 1048] xt_bpf completely broken with kernel 4.3

https://bugzilla.netfilter.org/show_bug.cgi?id=1048 --- Comment #3 from Daniel Borkmann <daniel at iogearbox.net> --- (In reply to blaffablaffa from comment #2) > It turns out that the problem is indeed the different 0 offset that xt_bpf > and tcpdump use. In particular, it appears that offset 0 in tcpdump is at > the very beginning of the packet (ethernet header included) whereas

https://bugzilla.netfilter.org/show_bug.cgi?id=1048 --- Comment #2 from blaffablaffa at gmail.com --- It turns out that the problem is indeed the different 0 offset that xt_bpf and tcpdump use. In particular, it appears that offset 0 in tcpdump is at the very beginning of the packet (ethernet header included) whereas xt_bpf uses the beginning of the IP header. I've spoken with the author of

https://bugzilla.netfilter.org/show_bug.cgi?id=1048 blaffablaffa at gmail.com changed: What |Removed |Added ---------------------------------------------------------------------------- Status|NEW |RESOLVED Resolution|--- |FIXED --- Comment #4 from blaffablaffa at gmail.com --- Closing the

We tends to batch submitting packets during XDP_TX. This requires to kick virtqueue after a batch, we tried to do it through xdp_do_flush_map() which only makes sense for devmap not XDP_TX. So explicitly kick the virtqueue in this case. Reported-by: Kimitoshi Takahashi <ktaka at nii.ac.jp> Tested-by: Kimitoshi Takahashi <ktaka at nii.ac.jp> Cc: Daniel Borkmann <daniel at

Pulling header files directly out of the kernel sources for inclusion in userspace programs is highly error prone, not least because it bypasses the kbuild infrastructure entirely and so may end up referencing other header files that have not been generated. Subsequent patches will cause compiler.h to pull in the ungenerated asm/rwonce.h file via filter.h, breaking the build for tools/bpf: | $

Pulling header files directly out of the kernel sources for inclusion in userspace programs is highly error prone, not least because it bypasses the kbuild infrastructure entirely and so may end up referencing other header files that have not been generated. Subsequent patches will cause compiler.h to pull in the ungenerated asm/rwonce.h file via filter.h, breaking the build for tools/bpf: | $

Hi! The Netfilter project proudly presents: iptables 1.4.19 This release includes support for the new connlabel and bpf matches available in Linux 3.9, several fixes and manpage updates. See ChangeLog that comes attached to this email for more details. You can download it from: http://www.netfilter.org/projects/iptables/downloads.html ftp://ftp.netfilter.org/pub/iptables/ Have fun!

On 2016?12?24? 03:31, Daniel Borkmann wrote: > Hi Jason, > > On 12/23/2016 03:37 PM, Jason Wang wrote: >> Since we use EWMA to estimate the size of rx buffer. When rx buffer >> size is underestimated, it's usual to have a packet with more than one >> buffers. Consider this is not a bug, remove the warning and correct >> the comment before XDP linearizing.

On Wed, Sep 20, 2017 at 12:20:40AM +0100, Jiong Wang via iovisor-dev wrote: > On 18/09/2017 22:29, Daniel Borkmann wrote: > > On 09/18/2017 10:47 PM, Jiong Wang wrote: > > > Hi, > > > > > >    Currently, LLVM eBPF backend always generate code in 64-bit mode, > > > this may > > > cause troubles when JITing to 32-bit targets. > > >

Hi! The Netfilter project proudly presents: iptables 1.8.3 iptables is the userspace command line program used to configure the Linux 2.4.x and later packet filtering ruleset. It is targeted towards system administrators. See ChangeLog that comes attached to this email for more details. You can download it from: http://www.netfilter.org/projects/iptables/downloads.html

On Sat, Sep 23, 2017 at 1:41 AM, Jakub Kicinski via iovisor-dev <iovisor-dev at lists.iovisor.org> wrote: > On Fri, 22 Sep 2017 22:03:47 -0700, Yonghong Song wrote: >> On 9/22/17 9:24 AM, Jakub Kicinski wrote: >> > On Thu, 21 Sep 2017 11:56:55 -0700, Alexei Starovoitov wrote: >> >> On Wed, Sep 20, 2017 at 12:20:40AM +0100, Jiong Wang via iovisor-dev wrote:

doing the same on the bridge controller with my workarounds applied: please note some differences: LnkSta: Speed 8GT/s (ok) vs Speed 2.5GT/s (downgraded) SltSta: PresDet+ vs PresDet- LnkSta2: Equalization stuff Virtual channel: NegoPending- vs NegoPending+ both times I executed lspci while the GPU was still suspended. 00:01.0 PCI bridge: Intel Corporation Xeon E3-1200 v5/E3-1500 v5/6th Gen Core

On Mon, Jun 03, 2019 at 03:18:56PM +0200, Karol Herbst wrote: > @bjorn: any further ideas? Otherwise I'd like to just go ahead and fix > this issue inside Nouveau and leave it there until we have a better > understanding or non Nouveau cases of this issue. Nope, I have no more ideas. > On Tue, May 21, 2019 at 7:48 PM Karol Herbst <kherbst at redhat.com> wrote: > >

flight 21641 linux-3.10 real [real] http://www.chiark.greenend.org.uk/~xensrcts/logs/21641/ Regressions :-( Tests which did not succeed and are blocking, including tests which could not be run: test-amd64-i386-pv 18 leak-check/check fail REGR. vs. 21026 test-amd64-i386-qemut-rhel6hvm-intel 11 leak-check/check fail REGR. vs. 21026 test-amd64-i386-qemuu-rhel6hvm-intel 11

ohh nvm. It was a mistake on my end. Sorry for the noise On Wed, Jun 19, 2019 at 2:07 PM Karol Herbst <kherbst at redhat.com> wrote: > > Hi Bjorn, > > I was playing around with some older information again (write into the > PCI config to put the card into d3 state). And there is something > which made me very curious: > If I put the card manually into any other state

@bjorn: any further ideas? Otherwise I'd like to just go ahead and fix this issue inside Nouveau and leave it there until we have a better understanding or non Nouveau cases of this issue. On Tue, May 21, 2019 at 7:48 PM Karol Herbst <kherbst at redhat.com> wrote: > > doing the same on the bridge controller with my workarounds applied: > > please note some differences: >

On 06/16/2016 06:57 PM, Richard Henderson via iovisor-dev wrote: > On 06/15/2016 10:14 PM, Alexei Starovoitov wrote: >> On Wed, Jun 15, 2016 at 2:37 PM, Richard Henderson via iovisor-dev >> <iovisor-dev at lists.iovisor.org> wrote: >>> This same value for EM_BPF is being propagated to glibc, >>> elfutils, and binutils. >> >> great! >> Can

Hi Bjorn, I was playing around with some older information again (write into the PCI config to put the card into d3 state). And there is something which made me very curious: If I put the card manually into any other state besides D0 via the 0x64 pci config register, the card just dies and pci core seems to expect this to not happen. pci_raw_set_power_state has this

Hi, Is there any way to detect which virtual registers are assigned to physical registers and which ones are assigned to memory slots? BR Laura -------------- next part -------------- An HTML attachment was scrubbed... URL: <http://lists.llvm.org/pipermail/llvm-dev/attachments/20160218/fb9b7659/attachment.html>

Ack! This slipped through my email. I am terribly sorry. Thank you so much for responding. On 04/06/2014 08:43 PM, Ilia Mirkin wrote: > On Sun, Apr 6, 2014 at 7:16 PM, ~Stack~ <i.am.stack at gmail.com> wrote: >> Greetings, [snip] >> My working kernel is: 2.6.32-358.23.2.el6.x86_64 (and anything before). >> >> The problem kernel is: 2.6.32-431.1.2.el6.x86_64 and