Displaying 20 results from an estimated 400 matches similar to: "4.20-rc6: WARNING: CPU: 30 PID: 197360 at net/core/flow_dissector.c:764 __skb_flow_dissect"
2018 Dec 21
0
4.20-rc6: WARNING: CPU: 30 PID: 197360 at net/core/flow_dissector.c:764 __skb_flow_dissect
On 20.12.2018 18:23, Willem de Bruijn wrote:
> On Thu, Dec 20, 2018 at 11:17 AM Ido Schimmel <idosch at idosch.org> wrote:
>>
>> On Thu, Dec 20, 2018 at 03:09:22PM +0100, Christian Borntraeger wrote:
>>> On 20.12.2018 10:12, Ido Schimmel wrote:
>>>> +Willem
>>>>
>>>> On Thu, Dec 20, 2018 at 08:45:40AM +0100, Christian Borntraeger
2018 Dec 20
1
4.20-rc6: WARNING: CPU: 30 PID: 197360 at net/core/flow_dissector.c:764 __skb_flow_dissect
On Thu, Dec 20, 2018 at 9:16 AM Ido Schimmel <idosch at idosch.org> wrote:
>
> On Thu, Dec 20, 2018 at 09:04:25AM -0500, Willem de Bruijn wrote:
> > On Thu, Dec 20, 2018 at 6:15 AM Ido Schimmel <idosch at idosch.org> wrote:
> > >
> > > +Willem
> > >
> > > On Thu, Dec 20, 2018 at 08:45:40AM +0100, Christian Borntraeger wrote:
> >
2018 Dec 20
0
4.20-rc6: WARNING: CPU: 30 PID: 197360 at net/core/flow_dissector.c:764 __skb_flow_dissect
On Thu, Dec 20, 2018 at 6:15 AM Ido Schimmel <idosch at idosch.org> wrote:
>
> +Willem
>
> On Thu, Dec 20, 2018 at 08:45:40AM +0100, Christian Borntraeger wrote:
> > Folks,
> >
> > I got this warning today. I cant tell when and why this happened, so I do not know yet how to reproduce.
> > Maybe someone has a quick idea.
> >
> > [85109.572032]
2018 Dec 20
0
4.20-rc6: WARNING: CPU: 30 PID: 197360 at net/core/flow_dissector.c:764 __skb_flow_dissect
On 20.12.2018 10:12, Ido Schimmel wrote:
> +Willem
>
> On Thu, Dec 20, 2018 at 08:45:40AM +0100, Christian Borntraeger wrote:
>> Folks,
>>
>> I got this warning today. I cant tell when and why this happened, so I do not know yet how to reproduce.
>> Maybe someone has a quick idea.
>>
>> [85109.572032] WARNING: CPU: 30 PID: 197360 at
2018 Dec 20
0
4.20-rc6: WARNING: CPU: 30 PID: 197360 at net/core/flow_dissector.c:764 __skb_flow_dissect
Folks,
I got this warning today. I cant tell when and why this happened, so I do not know yet how to reproduce.
Maybe someone has a quick idea.
[85109.572032] WARNING: CPU: 30 PID: 197360 at net/core/flow_dissector.c:764 __skb_flow_dissect+0x1f0/0x1318
[85109.572036] Modules linked in: vhost_net vhost macvtap macvlan tap vfio_ap vfio_mdev mdev vfio_iommu_type1 vfio kvm xt_CHECKSUM ipt_MASQUERADE
2023 May 23
3
[Bridge] [PATCH net-next 1/5] skbuff: bridge: Add layer 2 miss indication
On Fri, May 19, 2023 at 02:52:18PM -0700, Jakub Kicinski wrote:
> On Fri, 19 May 2023 16:51:48 +0300 Ido Schimmel wrote:
> > diff --git a/net/bridge/br_input.c b/net/bridge/br_input.c
> > index fc17b9fd93e6..274e55455b15 100644
> > --- a/net/bridge/br_input.c
> > +++ b/net/bridge/br_input.c
> > @@ -46,6 +46,8 @@ static int br_pass_frame_up(struct sk_buff *skb)
>
2023 May 18
5
[Bridge] [PATCH net-next 0/5] Add layer 2 miss indication and filtering
tl;dr
=====
This patchset adds a single bit to the skb to indicate that a packet
encountered a layer 2 miss in the bridge and extends flower to match on
this metadata. This is required for non-DF (Designated Forwarder)
filtering in EVPN multi-homing which prevents decapsulated BUM packets
from being forwarded multiple times to the same multi-homed host.
Background
==========
In a typical EVPN
2023 May 09
5
[Bridge] [RFC PATCH net-next 0/5] Add layer 2 miss indication and filtering
tl;dr
=====
This patchset adds a single bit to the skb to indicate that a packet
encountered a layer 2 miss in the bridge and extends flower to match on
this metadata. This is required for non-DF (Designated Forwarder)
filtering in EVPN multi-homing which prevents decapsulated BUM packets
from being forwarded multiple times to the same multi-homed host.
Background
==========
In a typical EVPN
2023 May 19
1
[Bridge] [PATCH net-next 1/5] skbuff: bridge: Add layer 2 miss indication
On Fri, 19 May 2023 16:51:48 +0300 Ido Schimmel wrote:
> diff --git a/net/bridge/br_input.c b/net/bridge/br_input.c
> index fc17b9fd93e6..274e55455b15 100644
> --- a/net/bridge/br_input.c
> +++ b/net/bridge/br_input.c
> @@ -46,6 +46,8 @@ static int br_pass_frame_up(struct sk_buff *skb)
> */
> br_switchdev_frame_unmark(skb);
>
> + skb->l2_miss
2018 Dec 10
2
TK1: DRM, Nouveau and VIC
On Mon, Dec 10, 2018 at 11:21:47AM +0100, Thierry Reding wrote:
> On Sat, Dec 08, 2018 at 02:54:45PM +0000, Marcel Ziswiler wrote:
> > Hi Thierry et al.
> >
> > I noticed that since commit 3dde5a2342cd ("ARM: tegra: Add VIC on
> > Tegra124") graphics on Apalis TK1 is broken. During boot it fails
> > loading the vic firmware:
> >
> > [
2008 Jun 12
1
Nut-snmp 0.42 vs 0.41
I am using nut-snmp driver on ubuntu 8.04 to query a Powerware
ConnectUPS Web/SNMP Card V4.20.
With 0.41 I used to be able to query these field that are now gone with
0.42:
input.frequency
input.voltage
output.voltage
ups.load
Any idea how I can get ups.load back ?
-------------- next part --------------
An HTML attachment was scrubbed...
URL:
2018 Sep 27
2
[PATCH v3] PCI: Reprogram bridge prefetch registers on resume
[+cc LKML]
On Tue, Sep 18, 2018 at 04:32:44PM -0500, Bjorn Helgaas wrote:
> On Thu, Sep 13, 2018 at 11:37:45AM +0800, Daniel Drake wrote:
> > On 38+ Intel-based Asus products, the nvidia GPU becomes unusable
> > after S3 suspend/resume. The affected products include multiple
> > generations of nvidia GPUs and Intel SoCs. After resume, nouveau logs
> > many errors such
2018 Dec 17
3
[PATCH v3 00/12] x86, kbuild: revert macrofying inline assembly code
This series reverts the in-kernel workarounds for inlining issues.
The commit description of 77b0bf55bc67 mentioned
"We also hope that GCC will eventually get fixed,..."
Now, GCC provides a solution.
https://gcc.gnu.org/onlinedocs/gcc/Extended-Asm.html
explains the new "asm inline" syntax.
The performance issue will be eventually solved.
[About Code cleanups]
I know Nadam
2018 Dec 17
3
[PATCH v3 00/12] x86, kbuild: revert macrofying inline assembly code
This series reverts the in-kernel workarounds for inlining issues.
The commit description of 77b0bf55bc67 mentioned
"We also hope that GCC will eventually get fixed,..."
Now, GCC provides a solution.
https://gcc.gnu.org/onlinedocs/gcc/Extended-Asm.html
explains the new "asm inline" syntax.
The performance issue will be eventually solved.
[About Code cleanups]
I know Nadam
2023 Mar 28
2
[Bridge] [PATCH v2 net-next 6/6] selftests: forwarding: add dynamic FDB test
On Sun, Mar 26, 2023 at 05:41:06PM +0200, Hans Schultz wrote:
> On Mon, Mar 20, 2023 at 10:44, Ido Schimmel <idosch at nvidia.com> wrote:
> >> + $MZ $swp1 -c 1 -p 128 -t udp "sp=54321,dp=12345" \
> >> + -a $mac -b `mac_get $h2` -A 192.0.2.1 -B 192.0.2.2 -q
> >> + tc_check_packets "dev $swp2 egress" 1 1
> >> + check_fail $?
2023 Mar 28
1
[Bridge] [PATCH v2 net-next 6/6] selftests: forwarding: add dynamic FDB test
On Tue, Mar 28, 2023 at 19:40, Ido Schimmel <idosch at nvidia.com> wrote:
> On Sun, Mar 26, 2023 at 05:41:06PM +0200, Hans Schultz wrote:
>> On Mon, Mar 20, 2023 at 10:44, Ido Schimmel <idosch at nvidia.com> wrote:
>> >> + $MZ $swp1 -c 1 -p 128 -t udp "sp=54321,dp=12345" \
>> >> + -a $mac -b `mac_get $h2` -A 192.0.2.1 -B 192.0.2.2 -q
>>
2023 May 09
1
[Bridge] [RFC PATCH net-next 3/5] flow_offload: Reject matching on layer 2 miss
Adjust drivers that support the 'FLOW_DISSECTOR_KEY_META' key to reject
filters that try to match on the newly added layer 2 miss option. Add an
extack message to clearly communicate the failure reason to user space.
Example:
# tc filter add dev swp1 egress pref 1 proto all flower skip_sw l2_miss true action drop
Error: mlxsw_spectrum: Can't match on "l2_miss".
We have
2018 Dec 19
0
[PATCH v3 00/12] x86, kbuild: revert macrofying inline assembly code
On Wed, Dec 19, 2018 at 5:26 AM Nadav Amit <namit at vmware.com> wrote:
>
> > On Dec 17, 2018, at 8:03 AM, Masahiro Yamada <yamada.masahiro at socionext.com> wrote:
> >
> > This series reverts the in-kernel workarounds for inlining issues.
> >
> > The commit description of 77b0bf55bc67 mentioned
> > "We also hope that GCC will eventually get
2016 Jun 15
2
PXELINUX 6.03 / vesamenu.c32 hang
Hello,
I'm experiencing an issue where if I use vesamenu.c32 with PXELINUX 6.03 when network booting a virtual machine hosted on VMware ESXi 6.0, it hangs (the version message is printed and then nothing - the VM has to be powered off and back on again).
This happens no matter if I choose the E1000 network interface or the VMXNET3 network interface when creating the VM.
The same problem
2018 Dec 08
4
TK1: DRM, Nouveau and VIC
Hi Thierry et al.
I noticed that since commit 3dde5a2342cd ("ARM: tegra: Add VIC on
Tegra124") graphics on Apalis TK1 is broken. During boot it fails
loading the vic firmware:
[ 1.595824] tegra-vic 54340000.vic: Direct firmware load for
nvidia/tegra124/vic03_ucode.bin failed with error -2
[ 1.606140] tegra-vic: probe of 54340000.vic failed with error -2
Subsequently Tegra HDMI