[Touch-packages] [Bug 2021523] [NEW] totem displays "Unable to play the file" dialog for a video it can play

Public bug reported: I have an MP4 video file from a GoPro camera, and when I try to play it with totem, it displays a "Unable to play the file" dialog complaining about missing gstreamer elements (see attachment); totem prints the following on stderr: ** Message: 11:46:33.328: Missing plugin:

[Desktop-packages] [Bug 2021523] [NEW] totem displays "Unable to play the file" dialog for a video it can play

Public bug reported: I have an MP4 video file from a GoPro camera, and when I try to play it with totem, it displays a "Unable to play the file" dialog complaining about missing gstreamer elements (see attachment); totem prints the following on stderr: ** Message: 11:46:33.328: Missing plugin:

[Kernel-packages] [Bug 1959728] Re: trackpad doesn't work on Lenovo X1 Yoga Titanium after suspend/resume

I don't see Linux versions of the touchpad firmware? -- You received this bug notification because you are a member of Kernel Packages, which is subscribed to linux in Ubuntu. https://bugs.launchpad.net/bugs/1959728 Title: trackpad doesn't work on Lenovo X1 Yoga Titanium after suspend/resume

[Kernel-packages] [Bug 1959728] Re: trackpad doesn't work on Lenovo X1 Yoga Titanium after suspend/resume

Is there any way to perform these updates without Windows? I overwrote the whole drive when I obtained Ubuntu. I have performed a few BIOS / EC updates via fwupdmgr, but the system shows as up-to-date now. -- You received this bug notification because you are a member of Kernel Packages, which

[Bug 1959728] [NEW] trackpad doesn't work on Lenovo X1 Yoga Titanium after suspend/resume

Public bug reported: On my X1 Yoga Titanium (which has a fancy new "Sensel" trackpad with haptic response to clicks), the trackpad stops working after a suspend/resume cycle, although the red trackpoint continues to work fine for controlling the pointer. I believe this system is using S0i3 for

[Kernel-packages] [Bug 1959728] [NEW] trackpad doesn't work on Lenovo X1 Yoga Titanium after suspend/resume

Public bug reported: On my X1 Yoga Titanium (which has a fancy new "Sensel" trackpad with haptic response to clicks), the trackpad stops working after a suspend/resume cycle, although the red trackpoint continues to work fine for controlling the pointer. I believe this system is using S0i3 for

[Bug 1930433] [NEW] UEFI doesn't load fwupd on Lenovo X1 Carbon 7th

Public bug reported: I have a 7th gen Lenovo X1 Carbon with Ubuntu up-to-date on 21.04, and fwupdmgr shows: $ fwupdmgr update Devices with no available firmware updates: • UEFI Device Firmware • UEFI Device Firmware • UEFI Device Firmware • UEFI dbx Devices with the latest available

Re: [PATCH 22/22] iommu/vt-d: Add a quirk flag for scope mismatched devices

> Are you willing to add your reviewed-by for Jim's v2 patch? I will > queue it for v5.6 if you both agree. Sure: Reviewed-by: Roland Dreier ___ iommu mailing list iommu@lists.linux-foundation.org https://lists.linuxfoundation.org/mailman/li

Re: [PATCH 22/22] iommu/vt-d: Add a quirk flag for scope mismatched devices

> Jim proposed another solution. > > https://lkml.org/lkml/2019/12/23/653 > > Does this work for you? Yes, that's OK for the cases I've seen too. All the NTB devices I've seen are PCI_CLASS_BRIDGE_OTHER with type 0 headers, so this patch would not break anything. And I think the idea of

Re: [PATCH 22/22] iommu/vt-d: Add a quirk flag for scope mismatched devices

> We saw more devices with the same mismatch quirk. So maintaining them in > a quirk table will make it more readable and maintainable. I guess I disagree about the maintainable part, given that this patch already regresses Broadwell NTB. I'm not even sure what the DMAR table says about NTB on

Re: [PATCH 22/22] iommu/vt-d: Add a quirk flag for scope mismatched devices

> +DECLARE_PCI_FIXUP_HEADER(PCI_VENDOR_ID_INTEL, 0x2f0d, /* NTB devices */ > +quirk_dmar_scope_mismatch); > +DECLARE_PCI_FIXUP_HEADER(PCI_VENDOR_ID_INTEL, 0x2020, /* NVME host */ > +quirk_dmar_scope_mismatch); what's the motivation for changing

[Bug 1825395] Re: thunderbolt / PCIe hotplug gets confused after a few cycles on X1 Yoga 2nd gen

I've come up with a theory that I think matches what I observe. It seems that my laptop gets into the bad state if I suspend too quickly after hot unplug from thunderbolt. If I wait long enough after hot unplug that all the thunderbolt devices are fully removed, then the system remains fine. If

[Kernel-packages] [Bug 1825395] Re: thunderbolt / PCIe hotplug gets confused after a few cycles on X1 Yoga 2nd gen

I've come up with a theory that I think matches what I observe. It seems that my laptop gets into the bad state if I suspend too quickly after hot unplug from thunderbolt. If I wait long enough after hot unplug that all the thunderbolt devices are fully removed, then the system remains fine. If

[Kernel-packages] [Bug 1825395] Re: thunderbolt / PCIe hotplug gets confused after a few cycles on X1 Yoga 2nd gen

No BIOS options changed. I am on X1 Yoga 2nd gen - the BIOS exposes S3 by default. X1 Yoga 3rd gen is the first Lenovo generation that defaults to S0i3 for suspend. -- You received this bug notification because you are a member of Kernel Packages, which is subscribed to linux in Ubuntu.

[Bug 1825395] Re: thunderbolt / PCIe hotplug gets confused after a few cycles on X1 Yoga 2nd gen

No BIOS options changed. I am on X1 Yoga 2nd gen - the BIOS exposes S3 by default. X1 Yoga 3rd gen is the first Lenovo generation that defaults to S0i3 for suspend. -- You received this bug notification because you are a member of Ubuntu Bugs, which is subscribed to Ubuntu.

[Kernel-packages] [Bug 1825395] Re: thunderbolt / PCIe hotplug gets confused after a few cycles on X1 Yoga 2nd gen

I see from https://pcsupport.lenovo.com/us/en/downloads/DS506115 that there is a firmware update available for my dock. I am going to try and borrow a windows system and perform that update. -- You received this bug notification because you are a member of Kernel Packages, which is subscribed

[Bug 1825395] Re: thunderbolt / PCIe hotplug gets confused after a few cycles on X1 Yoga 2nd gen

I see from https://pcsupport.lenovo.com/us/en/downloads/DS506115 that there is a firmware update available for my dock. I am going to try and borrow a windows system and perform that update. -- You received this bug notification because you are a member of Ubuntu Bugs, which is subscribed to

[Bug 1825395] Re: thunderbolt / PCIe hotplug gets confused after a few cycles on X1 Yoga 2nd gen

No, unfortunately I am on the latest BIOS. dmidecode reports BIOS Information Vendor: LENOVO Version: N1NET45W (1.32 ) Release Date: 03/11/2019 and https://pcsupport.lenovo.com/us/en/products/laptops-and-

[Kernel-packages] [Bug 1825395] Re: thunderbolt / PCIe hotplug gets confused after a few cycles on X1 Yoga 2nd gen

No, unfortunately I am on the latest BIOS. dmidecode reports BIOS Information Vendor: LENOVO Version: N1NET45W (1.32 ) Release Date: 03/11/2019 and https://pcsupport.lenovo.com/us/en/products/laptops-and-

[Bug 1825395] Re: thunderbolt / PCIe hotplug gets confused after a few cycles on X1 Yoga 2nd gen

** Attachment added: "lspci after reconnection to thunderbolt dock - non-working" https://bugs.launchpad.net/ubuntu/+source/linux/+bug/1825395/+attachment/5258316/+files/post-replug-lspci.txt -- You received this bug notification because you are a member of Ubuntu Bugs, which is subscribed

[Kernel-packages] [Bug 1825395] Re: thunderbolt / PCIe hotplug gets confused after a few cycles on X1 Yoga 2nd gen

** Attachment added: "lspci while connected to working thunderbolt dock" https://bugs.launchpad.net/ubuntu/+source/linux/+bug/1825395/+attachment/5258314/+files/post-suspend-lspci.txt -- You received this bug notification because you are a member of Kernel Packages, which is subscribed to

[Kernel-packages] [Bug 1825395] Re: thunderbolt / PCIe hotplug gets confused after a few cycles on X1 Yoga 2nd gen

I can boot either connected or not, and the first connection will usually work. I'd say my more common workflow is to boot away from my dock, use my laptop for a bit, suspend, and go to my desk and resume while docked. That usually works, but if I then undock, use my laptop for a bit, suspend,

[Bug 1825395] Re: thunderbolt / PCIe hotplug gets confused after a few cycles on X1 Yoga 2nd gen

I can boot either connected or not, and the first connection will usually work. I'd say my more common workflow is to boot away from my dock, use my laptop for a bit, suspend, and go to my desk and resume while docked. That usually works, but if I then undock, use my laptop for a bit, suspend,

[Bug 1825395] Re: thunderbolt / PCIe hotplug gets confused after a few cycles on X1 Yoga 2nd gen

** Attachment added: "dmesg from boot to reproduction of the thunderbolt issue" https://bugs.launchpad.net/ubuntu/+source/linux/+bug/1825395/+attachment/5258312/+files/post-replug-dmesg.txt -- You received this bug notification because you are a member of Ubuntu Bugs, which is subscribed to

[Bug 1825395] Re: thunderbolt / PCIe hotplug gets confused after a few cycles on X1 Yoga 2nd gen

** Attachment added: "lspci after unplug from thunderbolt dock" https://bugs.launchpad.net/ubuntu/+source/linux/+bug/1825395/+attachment/5258315/+files/post-unplug-lspci.txt -- You received this bug notification because you are a member of Ubuntu Bugs, which is subscribed to Ubuntu.

[Bug 1825395] Re: thunderbolt / PCIe hotplug gets confused after a few cycles on X1 Yoga 2nd gen

** Attachment added: "lspci while connected to working thunderbolt dock" https://bugs.launchpad.net/ubuntu/+source/linux/+bug/1825395/+attachment/5258314/+files/post-suspend-lspci.txt -- You received this bug notification because you are a member of Ubuntu Bugs, which is subscribed to

[Kernel-packages] [Bug 1825395] Re: thunderbolt / PCIe hotplug gets confused after a few cycles on X1 Yoga 2nd gen

** Attachment added: "lspci before laptop is docked" https://bugs.launchpad.net/ubuntu/+source/linux/+bug/1825395/+attachment/5258313/+files/pre-suspend-lspci.txt -- You received this bug notification because you are a member of Kernel Packages, which is subscribed to linux in Ubuntu.

[Kernel-packages] [Bug 1825395] Re: thunderbolt / PCIe hotplug gets confused after a few cycles on X1 Yoga 2nd gen

** Attachment added: "lspci after reconnection to thunderbolt dock - non-working" https://bugs.launchpad.net/ubuntu/+source/linux/+bug/1825395/+attachment/5258316/+files/post-replug-lspci.txt -- You received this bug notification because you are a member of Kernel Packages, which is

[Bug 1825395] Re: thunderbolt / PCIe hotplug gets confused after a few cycles on X1 Yoga 2nd gen

** Attachment added: "lspci before laptop is docked" https://bugs.launchpad.net/ubuntu/+source/linux/+bug/1825395/+attachment/5258313/+files/pre-suspend-lspci.txt -- You received this bug notification because you are a member of Ubuntu Bugs, which is subscribed to Ubuntu.

[Kernel-packages] [Bug 1825395] Re: thunderbolt / PCIe hotplug gets confused after a few cycles on X1 Yoga 2nd gen

** Attachment added: "lspci after unplug from thunderbolt dock" https://bugs.launchpad.net/ubuntu/+source/linux/+bug/1825395/+attachment/5258315/+files/post-unplug-lspci.txt -- You received this bug notification because you are a member of Kernel Packages, which is subscribed to linux in

[Kernel-packages] [Bug 1825395] Re: thunderbolt / PCIe hotplug gets confused after a few cycles on X1 Yoga 2nd gen

** Attachment added: "dmesg from boot to reproduction of the thunderbolt issue" https://bugs.launchpad.net/ubuntu/+source/linux/+bug/1825395/+attachment/5258312/+files/post-replug-dmesg.txt -- You received this bug notification because you are a member of Kernel Packages, which is subscribed

[Bug 1825395] Re: thunderbolt / PCIe hotplug gets confused after a few cycles on X1 Yoga 2nd gen

Attaching dmesg showing failed thunderbolt attachment. There is a good hotplug starting with [35304.659358] thunderbolt 0-1: new device found, vendor=0x108 device=0x1630 [35304.659361] thunderbolt 0-1: Lenovo ThinkPad Thunderbolt 3 Dock for example, you can see that the system discovers the

[Kernel-packages] [Bug 1825395] Re: thunderbolt / PCIe hotplug gets confused after a few cycles on X1 Yoga 2nd gen

Attaching dmesg showing failed thunderbolt attachment. There is a good hotplug starting with [35304.659358] thunderbolt 0-1: new device found, vendor=0x108 device=0x1630 [35304.659361] thunderbolt 0-1: Lenovo ThinkPad Thunderbolt 3 Dock for example, you can see that the system discovers the

[Kernel-packages] [Bug 1825395] Re: thunderbolt / PCIe hotplug gets confused after a few cycles on X1 Yoga 2nd gen

So I can confirm that this bug happens with upstream build 5.1.0-050100rc5-generic. Will attach full dmesg. -- You received this bug notification because you are a member of Kernel Packages, which is subscribed to linux in Ubuntu. https://bugs.launchpad.net/bugs/1825395 Title: thunderbolt /

[Bug 1825395] Re: thunderbolt / PCIe hotplug gets confused after a few cycles on X1 Yoga 2nd gen

So I can confirm that this bug happens with upstream build 5.1.0-050100rc5-generic. Will attach full dmesg. -- You received this bug notification because you are a member of Ubuntu Bugs, which is subscribed to Ubuntu. https://bugs.launchpad.net/bugs/1825395 Title: thunderbolt / PCIe hotplug

[Kernel-packages] [Bug 1825395] Re: thunderbolt / PCIe hotplug gets confused after a few cycles on X1 Yoga 2nd gen

I will try the upstream kernel, although it will be a few days before I can confidently report if the issue is not present. -- You received this bug notification because you are a member of Kernel Packages, which is subscribed to linux in Ubuntu. https://bugs.launchpad.net/bugs/1825395 Title:

[Bug 1825395] Re: thunderbolt / PCIe hotplug gets confused after a few cycles on X1 Yoga 2nd gen

I will try the upstream kernel, although it will be a few days before I can confidently report if the issue is not present. -- You received this bug notification because you are a member of Ubuntu Bugs, which is subscribed to Ubuntu. https://bugs.launchpad.net/bugs/1825395 Title: thunderbolt

[Kernel-packages] [Bug 1825395] [NEW] thunderbolt / PCIe hotplug gets confused after a few cycles on X1 Yoga 2nd gen

Public bug reported: I have a Lenovo X1 Yoga 2nd gen along with the Lenovo thunderbolt docking station. Initial connection to the dock works great, but after a few plug/unplug and suspend/resume cycles, the system gets in a state where a reboot is needed to make the dock work. The displayport

[Bug 1825395] [NEW] thunderbolt / PCIe hotplug gets confused after a few cycles on X1 Yoga 2nd gen

Public bug reported: I have a Lenovo X1 Yoga 2nd gen along with the Lenovo thunderbolt docking station. Initial connection to the dock works great, but after a few plug/unplug and suspend/resume cycles, the system gets in a state where a reboot is needed to make the dock work. The displayport

Re: [PATCH] clocksource: Add heuristics to avoid switching away from TSC due to timer delay

> /* > * Proper multiline comments look like this not like > * the above. > */ Got it, will fix next time around. > That aside. Why are you trying to do heuristics on the delta? > > We have way better information than that.

Re: [PATCH] clocksource: Add heuristics to avoid switching away from TSC due to timer delay

> /* > * Proper multiline comments look like this not like > * the above. > */ Got it, will fix next time around. > That aside. Why are you trying to do heuristics on the delta? > > We have way better information than that.

[tip:x86/timers] x86/hpet: Remove unused FSEC_PER_NSEC define

Commit-ID: d999c0ec2498e54b9328db6b2c1037710025add1 Gitweb: https://git.kernel.org/tip/d999c0ec2498e54b9328db6b2c1037710025add1 Author: Roland Dreier AuthorDate: Fri, 30 Nov 2018 13:14:50 -0800 Committer: Borislav Petkov CommitDate: Tue, 4 Dec 2018 12:17:21 +0100 x86/hpet: Remove

[tip:x86/timers] x86/hpet: Remove unused FSEC_PER_NSEC define

Commit-ID: d999c0ec2498e54b9328db6b2c1037710025add1 Gitweb: https://git.kernel.org/tip/d999c0ec2498e54b9328db6b2c1037710025add1 Author: Roland Dreier AuthorDate: Fri, 30 Nov 2018 13:14:50 -0800 Committer: Borislav Petkov CommitDate: Tue, 4 Dec 2018 12:17:21 +0100 x86/hpet: Remove

[PATCH] x86/hpet: Remove unused FSEC_PER_NSEC define

The FSEC_PER_NSEC macro has had zero users since commit ab0e08f15d23 ("x86: hpet: Cleanup the clockevents init and register code"). Signed-off-by: Roland Dreier --- arch/x86/kernel/hpet.c | 4 1 file changed, 4 deletions(-) diff --git a/arch/x86/kernel/hpet.c b/arch/x86/ker

[PATCH] x86/hpet: Remove unused FSEC_PER_NSEC define

The FSEC_PER_NSEC macro has had zero users since commit ab0e08f15d23 ("x86: hpet: Cleanup the clockevents init and register code"). Signed-off-by: Roland Dreier --- arch/x86/kernel/hpet.c | 4 1 file changed, 4 deletions(-) diff --git a/arch/x86/kernel/hpet.c b/arch/x86/ker

[PATCH] clocksource: Add heuristics to avoid switching away from TSC due to timer delay

detection of true instability very likely within a few clocksource watchdog iterations. Signed-off-by: Roland Dreier --- kernel/time/clocksource.c | 35 +++ 1 file changed, 35 insertions(+) diff --git a/kernel/time/clocksource.c b/kernel/time/clocksource.c index

[PATCH] clocksource: Add heuristics to avoid switching away from TSC due to timer delay

detection of true instability very likely within a few clocksource watchdog iterations. Signed-off-by: Roland Dreier --- kernel/time/clocksource.c | 35 +++ 1 file changed, 35 insertions(+) diff --git a/kernel/time/clocksource.c b/kernel/time/clocksource.c index

[PATCH] x86/hpet: Remove unused FSEC_PER_NSEC define

The FSEC_PER_NSEC macro has had zero users since commit ab0e08f15d23 ("x86: hpet: Cleanup the clockevents init and register code"). Signed-off-by: Roland Dreier --- arch/x86/kernel/hpet.c | 4 1 file changed, 4 deletions(-) diff --git a/arch/x86/kernel/hpet.c b/arch/x86/ker

[PATCH] x86/hpet: Remove unused FSEC_PER_NSEC define

The FSEC_PER_NSEC macro has had zero users since commit ab0e08f15d23 ("x86: hpet: Cleanup the clockevents init and register code"). Signed-off-by: Roland Dreier --- arch/x86/kernel/hpet.c | 4 1 file changed, 4 deletions(-) diff --git a/arch/x86/kernel/hpet.c b/arch/x86/ker

Re: [PATCH 4.4 103/105] Revert "x86/mm/pat: Ensure cpa->pfn only contains page frame numbers"

> > Perhaps just the patch that Andi posted to the stable list helps out > > here? > > > > For reference: > > https://www.spinics.net/lists/stable/msg253357.html > > That would be the most straightforward and simple fix, so I would prefer > to go with it if it works. Sorry for being slow, it

[Kernel-packages] [Bug 1789465] [NEW] BUG: scheduling while atomic: irq/142-iwlwifi/383/0x7ffffc00

Public bug reported: Not doing anything in particular other than using wifi on my laptop. ProblemType: KernelOops DistroRelease: Ubuntu 18.10 Package: linux-image-4.17.0-7-generic 4.17.0-7.8 ProcVersionSignature: Ubuntu 4.17.0-7.8-generic 4.17.12 Uname: Linux 4.17.0-7-generic x86_64 Annotation:

[Bug 1789465] [NEW] BUG: scheduling while atomic: irq/142-iwlwifi/383/0x7ffffc00

Public bug reported: Not doing anything in particular other than using wifi on my laptop. ProblemType: KernelOops DistroRelease: Ubuntu 18.10 Package: linux-image-4.17.0-7-generic 4.17.0-7.8 ProcVersionSignature: Ubuntu 4.17.0-7.8-generic 4.17.12 Uname: Linux 4.17.0-7-generic x86_64 Annotation:

Re: [PATCH 4.4 103/105] Revert "x86/mm/pat: Ensure cpa->pfn only contains page frame numbers"

> Sounds great. I'll hold off with sending my RFT series and wait for your > test results. I think we'll also need d367cef0a7f0c6 ("x86/mm/pat: Fix > boot crash when 1GB pages are not supported by the CPU"). Sure, makes sense - I don't have any EFI systems with CPUs old enough not to support 1G

Re: [PATCH 4.4 103/105] Revert "x86/mm/pat: Ensure cpa->pfn only contains page frame numbers"

> Ok, so what patch should be reverted? I'm seeing other reports of > problems all around this same area, but I can't figure out exactly what > to do. Are any of those reports public? If so can you point me at them, I'm curious if the symptoms match up. I don't think we want to revert

Re: [PATCH 4.4 103/105] Revert "x86/mm/pat: Ensure cpa->pfn only contains page frame numbers"

> See > . Thanks! I'm not using SGI UV and I'm not using kexec, so I guess I sidestepped most of those issues. Greg, I think we need to unrevert the cpa->pfn change (otherwise the L1TF fix probably gets pretty messy)

Re: [PATCH 4.4 103/105] Revert "x86/mm/pat: Ensure cpa->pfn only contains page frame numbers"

> > This is bad enough that 4.4.148 and all newer 4.4.y crash early in > > boot on some EFI systems that I have. > > Ugh, not good. > > > For now I am re-applying the "ensure cpa->pfn only contains page frame > > numbers" patch, ported on top of 4.4.151. > > I can try to add it back and see what

Re: [PATCH 4.4 103/105] Revert "x86/mm/pat: Ensure cpa->pfn only contains page frame numbers"

On Fri, Dec 15, 2017 at 2:20 AM Greg Kroah-Hartman wrote: > This reverts commit 87e2bd898d3a79a8c609f183180adac47879a2a4 which is > commit edc3b9129cecd0f0857112136f5b8b1bc1d45918 upstream. > > Turns there was too many other issues with this patch to make it viable > for the stable tree. This

Re: [PATCH 0/3] Provide more fine grained control over multipathing

> The sensible thing to do in nvme is to use different paths for > different queues. That is e.g. in the RDMA case use the HCA closer > to a given CPU by default. We might allow to override this for > cases where the is a good reason, but what I really don't want is > configurability for

Re: [PATCH 0/3] Provide more fine grained control over multipathing

> The sensible thing to do in nvme is to use different paths for > different queues. That is e.g. in the RDMA case use the HCA closer > to a given CPU by default. We might allow to override this for > cases where the is a good reason, but what I really don't want is > configurability for

Re: [PATCH 0/3] Provide more fine grained control over multipathing

> Moreover, I also wanted to point out that fabrics array vendors are > building products that rely on standard nvme multipathing (and probably > multipathing over dispersed namespaces as well), and keeping a knob that > will keep nvme users with dm-multipath will probably not help them > educate

Re: [PATCH 0/3] Provide more fine grained control over multipathing

> Moreover, I also wanted to point out that fabrics array vendors are > building products that rely on standard nvme multipathing (and probably > multipathing over dispersed namespaces as well), and keeping a knob that > will keep nvme users with dm-multipath will probably not help them > educate

Re: KASAN: use-after-free Read in __list_add_valid (5)

> Still reproducible on Linus' tree (commit 66e1c94db3cd4e) and on linux-next > (next-20180511). Here's a simplified reproducer: Thanks! That's a fantastic test case. The issue is a race where rdma_listen() sees invalid state in the middle of an rdma_bind_addr() call that will ultimately fail.

Re: KASAN: use-after-free Read in __list_add_valid (5)

> Still reproducible on Linus' tree (commit 66e1c94db3cd4e) and on linux-next > (next-20180511). Here's a simplified reproducer: Thanks! That's a fantastic test case. The issue is a race where rdma_listen() sees invalid state in the middle of an rdma_bind_addr() call that will ultimately fail.

[PATCH] qed: Fix potential use-after-free in qed_spq_post()

From: Roland Dreier <rol...@purestorage.com> We need to check if p_ent->comp_mode is QED_SPQ_MODE_EBLOCK before calling qed_spq_add_entry(). The test is fine is the mode is EBLOCK, but if it isn't then qed_spq_add_entry() might kfree(p_ent). Signed-off-by: Roland Dreier <rol...@pur

[Bug 1727566] [NEW] extra left-behind domains break domain name rsolution

Public bug reported: This seems related to LP: #1717995 but that is marked fixed. I used my laptop at work, where I have a docking station with USB ethernet included (interface enx0050b6cf4d4a). The dhcp on the wired ethernet includes my work domain, purestorage.com. I undocked, suspended, and

[Touch-packages] [Bug 1727566] [NEW] extra left-behind domains break domain name rsolution

Public bug reported: This seems related to LP: #1717995 but that is marked fixed. I used my laptop at work, where I have a docking station with USB ethernet included (interface enx0050b6cf4d4a). The dhcp on the wired ethernet includes my work domain, purestorage.com. I undocked, suspended, and

[Bug 1727566] [NEW] extra left-behind domains break domain name rsolution

Public bug reported: This seems related to LP: #1717995 but that is marked fixed. I used my laptop at work, where I have a docking station with USB ethernet included (interface enx0050b6cf4d4a). The dhcp on the wired ethernet includes my work domain, purestorage.com. I undocked, suspended, and

[Bug 1717995] Re: extra domains not removed from resolv.conf when VPN disconnects

Great, let me know if you want me to try anything out. -- You received this bug notification because you are a member of Ubuntu Bugs, which is subscribed to Ubuntu. https://bugs.launchpad.net/bugs/1717995 Title: extra domains not removed from resolv.conf when VPN disconnects To manage

[Touch-packages] [Bug 1717995] Re: extra domains not removed from resolv.conf when VPN disconnects

Great, let me know if you want me to try anything out. -- You received this bug notification because you are a member of Ubuntu Touch seeded packages, which is subscribed to systemd in Ubuntu. https://bugs.launchpad.net/bugs/1717995 Title: extra domains not removed from resolv.conf when VPN

[Bug 1717995] Re: extra domains not removed from resolv.conf when VPN disconnects

$ systemd-resolve webvpn.purestorage.com webvpn.purestorage.com: resolve call failed: No appropriate name servers or networks for name found $ systemd-resolve --status Global DNS Domain: home.digitalvampire.org purestorage.com

[Touch-packages] [Bug 1717995] Re: extra domains not removed from resolv.conf when VPN disconnects

I wonder if the issue has anything to do with the fact that the VPN creates a new network link that disappears when the VPN goes down - note that the purestorage.com domains are listed for tun0 when the VPN is up. When I turn off the VPN, tun0 disappears but the purestorage.com domains stay in the

[Bug 1717995] Re: extra domains not removed from resolv.conf when VPN disconnects

I wonder if the issue has anything to do with the fact that the VPN creates a new network link that disappears when the VPN goes down - note that the purestorage.com domains are listed for tun0 when the VPN is up. When I turn off the VPN, tun0 disappears but the purestorage.com domains stay in the

[Touch-packages] [Bug 1717995] Re: extra domains not removed from resolv.conf when VPN disconnects

$ systemd-resolve webvpn.purestorage.com webvpn.purestorage.com: resolve call failed: No appropriate name servers or networks for name found $ systemd-resolve --status Global DNS Domain: home.digitalvampire.org purestorage.com

[Touch-packages] [Bug 1717995] [NEW] extra domains not removed from resolv.conf when VPN disconnects

Public bug reported: I use a VPN (network manager "vpnc" config) to connect to my work network. The gateway is "webvpn.purestorage.com". When I connect, I get "purestorage.com" added to the "search" line in my /etc/resolv.conf (and /run/resolvconf/interface/systemd-resolved) - which makes

[Bug 1717995] [NEW] extra domains not removed from resolv.conf when VPN disconnects

Public bug reported: I use a VPN (network manager "vpnc" config) to connect to my work network. The gateway is "webvpn.purestorage.com". When I connect, I get "purestorage.com" added to the "search" line in my /etc/resolv.conf (and /run/resolvconf/interface/systemd-resolved) - which makes

[Bug 1717995] [NEW] extra domains not removed from resolv.conf when VPN disconnects

Public bug reported: I use a VPN (network manager "vpnc" config) to connect to my work network. The gateway is "webvpn.purestorage.com". When I connect, I get "purestorage.com" added to the "search" line in my /etc/resolv.conf (and /run/resolvconf/interface/systemd-resolved) - which makes

Re: [Patch v2 00/19] CIFS: Implement SMBDirect

> Starting with SMB2 dialect 3.0, Microsoft introduced SMBDirect transport > protocol for transferring upper layer (SMB2) payload over RDMA via > Infiniband, RoCE or iWARP. The prococol is published in [MS-SMBD] > (https://msdn.microsoft.com/en-us/library/hh536346.aspx). This is great to see.

Re: [Patch v2 00/19] CIFS: Implement SMBDirect

> Starting with SMB2 dialect 3.0, Microsoft introduced SMBDirect transport > protocol for transferring upper layer (SMB2) payload over RDMA via > Infiniband, RoCE or iWARP. The prococol is published in [MS-SMBD] > (https://msdn.microsoft.com/en-us/library/hh536346.aspx). This is great to see.

Re: [PATCH] PCI: Update ACS quirk for more Intel 10G NICs

> I think the conclusion is that a hard-wired ACS capability is a > positive indication of isolation for a multifunction device, the code > is intended to support this and appears to do so, and Roland was going > to investigate the sightings that inspired this patch in more detail. > Dropping for

Re: [PATCH] PCI: Update ACS quirk for more Intel 10G NICs

> Is there a misunderstanding of the code flow here? We're never setting > EC. In the first code block we're just masking out requested > capabilities where unimplemented capabilities is the same as > implemented + enabled. We're not adding EC to the request, we're > just not removing it based

Re: [PATCH] PCI: Update ACS quirk for more Intel 10G NICs

> I think that the device implementing ACS and not implementing certain > features that are "must be implemented if..." is a positive indication > that the device does not have that behavior and therefore the ability > to control that behavior is unnecessary. pci_acs_flags_enabled() is > coded

Re: [PATCH] PCI: Update ACS quirk for more Intel 10G NICs

On Thu, Jul 20, 2017 at 3:15 PM, Alex Williamson wrote: > Most of the ACS capabilities are worded as "Must be implemented by > devices that implement ..." Shouldn't a hard-wired ACS capability > sufficiently describe that, or is there something wrong with how >

[PATCH] PCI: Update ACS quirk for more Intel 10G NICs

From: Roland Dreier <rol...@purestorage.com> Add one more variant of the 82599 plus the device IDs for X540 and X550 variants. Intel has confirmed that none of these devices does peer-to-peer between functions. The X540 and X550 have added ACS capabilities in their PCI config space, but t

Re: [ANNOUNCE]: Broadcom (Emulex) FC Target driver - efct

On Sun, Mar 5, 2017 at 8:35 AM, Sebastian Herbszt wrote: > Just like Hannes I do favour integration. I guess it could be > comparable to qla2xxx + tcm_qla2xxx, lpfc + lpfc_scst and > lpfc + tcm_lpfc. That approach might even help Bart with his > target driver unification if he

Re: [f2fs-dev] latest news

Greetings! Did you hear the latest news? You should definetely read more info here <http://today.sxipay.com/lndnz> Roland Dreier -- ___ Linux-f2fs-devel mailing list

Re: Resurrecting due to huge ipoib perf regression - [BUG] skb corruption and kernel panic at forwarding with fragmentation

On Fri, Jul 8, 2016 at 9:51 AM, Jason Gunthorpe wrote: > So, it appears, the dst and neigh can be used for all performances cases. > > For the non performance dst == null case, can we just burn cycles and > stuff the daddr in front of the packet at hardheader

Re: Resurrecting due to huge ipoib perf regression - [BUG] skb corruption and kernel panic at forwarding with fragmentation

On Fri, Jul 8, 2016 at 9:51 AM, Jason Gunthorpe wrote: > So, it appears, the dst and neigh can be used for all performances cases. > > For the non performance dst == null case, can we just burn cycles and > stuff the daddr in front of the packet at hardheader

Re: Resurrecting due to huge ipoib perf regression - [BUG] skb corruption and kernel panic at forwarding with fragmentation

On Fri, Jul 8, 2016 at 9:51 AM, Jason Gunthorpe wrote: > So, it appears, the dst and neigh can be used for all performances cases. > > For the non performance dst == null case, can we just burn cycles and > stuff the daddr in front of the packet at hardheader time, even if we > have to copy? OK,

Re: Resurrecting due to huge ipoib perf regression - [BUG] skb corruption and kernel panic at forwarding with fragmentation

On Thu, Jul 7, 2016 at 4:14 PM, Jason Gunthorpe wrote: > We have neighbour_priv, and ndo_neigh_construct/destruct now .. > > A first blush that would seem to be enough to let ipoib store the AH > and other path information in the neigh and avoid the cb? At least

Re: Resurrecting due to huge ipoib perf regression - [BUG] skb corruption and kernel panic at forwarding with fragmentation

On Thu, Jul 7, 2016 at 4:14 PM, Jason Gunthorpe wrote: > We have neighbour_priv, and ndo_neigh_construct/destruct now .. > > A first blush that would seem to be enough to let ipoib store the AH > and other path information in the neigh and avoid the cb? At least

Re: Resurrecting due to huge ipoib perf regression - [BUG] skb corruption and kernel panic at forwarding with fragmentation

On Thu, Jul 7, 2016 at 4:14 PM, Jason Gunthorpe wrote: > We have neighbour_priv, and ndo_neigh_construct/destruct now .. > > A first blush that would seem to be enough to let ipoib store the AH > and other path information in the neigh and avoid the cb? At least the > example in clip sure looks

Re: Resurrecting due to huge ipoib perf regression - [BUG] skb corruption and kernel panic at forwarding with fragmentation

>> struct skb_gso_cb { >> int mac_offset; >> int encap_level; >> __u16 csum_start; >> }; > This is based on an out-dated version of this struct. The 4.7 RC > kernel has a few more fields that were added to support local checksum > offload for encapsulated

Re: Resurrecting due to huge ipoib perf regression - [BUG] skb corruption and kernel panic at forwarding with fragmentation

>> struct skb_gso_cb { >> int mac_offset; >> int encap_level; >> __u16 csum_start; >> }; > This is based on an out-dated version of this struct. The 4.7 RC > kernel has a few more fields that were added to support local checksum > offload for encapsulated

Re: Resurrecting due to huge ipoib perf regression - [BUG] skb corruption and kernel panic at forwarding with fragmentation

>> struct skb_gso_cb { >> int mac_offset; >> int encap_level; >> __u16 csum_start; >> }; > This is based on an out-dated version of this struct. The 4.7 RC > kernel has a few more fields that were added to support local checksum > offload for encapsulated

Resurrecting due to huge ipoib perf regression - [BUG] skb corruption and kernel panic at forwarding with fragmentation

On Thu, Jan 7, 2016 at 3:00 AM, Konstantin Khlebnikov wrote: > Or just shift GSO CB and add couple checks like > BUILD_BUG_ON(sizeof(SKB_GSO_CB(skb)->room) < sizeof(*IPCB(skb))); Resurrecting this old thread, because the patch that ultimately went upstream (commit 9207f9d45b0a

Resurrecting due to huge ipoib perf regression - [BUG] skb corruption and kernel panic at forwarding with fragmentation

On Thu, Jan 7, 2016 at 3:00 AM, Konstantin Khlebnikov wrote: > Or just shift GSO CB and add couple checks like > BUILD_BUG_ON(sizeof(SKB_GSO_CB(skb)->room) < sizeof(*IPCB(skb))); Resurrecting this old thread, because the patch that ultimately went upstream (commit 9207f9d45b0a / net: preserve IP

Resurrecting due to huge ipoib perf regression - [BUG] skb corruption and kernel panic at forwarding with fragmentation

On Thu, Jan 7, 2016 at 3:00 AM, Konstantin Khlebnikov wrote: > Or just shift GSO CB and add couple checks like > BUILD_BUG_ON(sizeof(SKB_GSO_CB(skb)->room) < sizeof(*IPCB(skb))); Resurrecting this old thread, because the patch that ultimately went upstream (commit 9207f9d45b0a

[PATCH] iommu/vt-d: Don't reject NTB devices due to scope mismatch

From: Roland Dreier <rol...@purestorage.com> On a system with an Intel PCIe port configured as an NTB device, iommu initialization fails with DMAR: Device scope type does not match for :80:03.0 This is because the DMAR table reports this device as having s

[PATCH] iommu/vt-d: Don't reject NTB devices due to scope mismatch

From: Roland Dreier On a system with an Intel PCIe port configured as an NTB device, iommu initialization fails with DMAR: Device scope type does not match for :80:03.0 This is because the DMAR table reports this device as having scope 2 (ACPI_DMAR_SCOPE_TYPE_BRIDGE): [0A0h 0160

[PATCH] iommu/vt-d: Don't reject NTB devices due to scope mismatch

From: Roland Dreier <rol...@purestorage.com> On a system with an Intel PCIe port configured as an NTB device, iommu initialization fails with DMAR: Device scope type does not match for :80:03.0 This is because the DMAR table reports this device as having s

  1   2   3   4   5   6   7   8   9   10   >