Unfortunately I've received no response from NVIDIA's networking team on
this matter. Since their validation was what I had planned to use to
verify this SRU, I suppose it is now time to mark this "Won't Fix". If
anyone wants to continue to push for this and has an alternate
validation plan, please
** Changed in: edk2 (Ubuntu)
Status: New => Fix Released
** Changed in: edk2 (Ubuntu Oracular)
Status: New => Fix Released
** Changed in: edk2 (Ubuntu Oracular)
Assignee: (unassigned) => dann frazier (dannf)
** Changed in: edk2 (Ubuntu)
Assignee: (unassigned
** Changed in: dmidecode (Ubuntu)
Status: New => Fix Released
--
You received this bug notification because you are a member of Kernel
Packages, which is subscribed to dmidecode in Ubuntu.
https://bugs.launchpad.net/bugs/2081611
Title:
Add processor support from SMBIOS 3.6.0 in Jammy an
Apologies for the delay - I took a few months off over the summer. I
agree that we should close this ticket if IPRoute2 is not to be
upgraded, but I do not see that this decision has been reached. It is
clear from #25 that we need to maintain `ubuntu-fan` support - so that
patchset would need to be
Hi Andrea - since this is now a stable release update, I *think* the
next steps should be:
1) Edit this bug to use the SRU Template
https://wiki.ubuntu.com/StableReleaseUpdates#SRU_Bug_Template
(now done)
Since your team owns this package, please review that and let me know if you
have any conc
** Description changed:
- iproute2 upstream produces releases coinciding with upstream kernel
- releases to support the latest kernel features. Noble's iproute2 is
- still back at v6.1 even though it will use the v6.8 kernel. This means
- we provide no userspace interface for newer features - some
** Summary changed:
- [FFe] Merge iproute2 with the latest Debian version: 6.8.0-1 from
testing/unstable (main)
+ Backport iproute2 6.8.0 to noble
--
You received this bug notification because you are a member of Kernel
Packages, which is subscribed to iproute2 in Ubuntu.
Matching subscriptions
On Mon, Apr 22, 2024 at 11:07:54AM -, Matthieu Baerts wrote:
> > I don't think we can justify dropping FAN support in an SRU, so let's
> add that port back in.
>
> Even if it will not be used in Ubuntu 24.04,
I'm happy to drop it if the stable release team would accept it.
Here's the policy:
Thank Utkarsh. Yeah, we just dropped the ball on not getting this done
sooner. I'd like to see if we can make the case for SRU'ing 6.8 in, so
let's convert the bug to that.
I don't think we can justify dropping FAN support in an SRU, so let's
add that port back in.
We'll need to make a convincing
*** This bug is a duplicate of bug 2051672 ***
https://bugs.launchpad.net/bugs/2051672
Amir - we're working on this in bug 2051672, and I subscribed you to it.
I have prepared a build of iproute2 6.8 for noble in a PPA:
https://launchpad.net/~dannf/+archive/ubuntu/test
If there is some testi
** Description changed:
iproute2 upstream produces releases coinciding with upstream kernel
releases to support the latest kernel features. Noble's iproute2 is
still back at v6.1 even though it will use the v6.8 kernel. This means
we provide no userspace interface for newer features - some
** Description changed:
- A few versions have been released and Ubuntu Noble still has the 6.1
- version (6.1.0-1ubuntu2) from one year ago. Could it be possible to
- import the latest version from Debian unstable fixing a bunch of issues
- and supporting features from more recent kernels?
+ iprou
Thanks Matthieu. I spoke to the kernel team and I think they will handle
the update. I'm just trying to help unblock them by getting this
reviewed/agreed by our release team ahead of time.
--
You received this bug notification because you are a member of Kernel
Packages, which is subscribed to ip
** Attachment added: "Upstream 6.7 changelog"
https://bugs.launchpad.net/ubuntu/+source/iproute2/+bug/2051672/+attachment/5763789/+files/6.7-changes.txt
--
You received this bug notification because you are a member of Kernel
Packages, which is subscribed to iproute2 in Ubuntu.
Matching subsc
** Attachment added: "Upstream 6.8 changelog"
https://bugs.launchpad.net/ubuntu/+source/iproute2/+bug/2051672/+attachment/5763790/+files/6.8-changes.txt
--
You received this bug notification because you are a member of Kernel
Packages, which is subscribed to iproute2 in Ubuntu.
Matching subsc
** Attachment added: "Upstream 6.6 changelog"
https://bugs.launchpad.net/ubuntu/+source/iproute2/+bug/2051672/+attachment/5763788/+files/6.6-changes.txt
--
You received this bug notification because you are a member of Kernel
Packages, which is subscribed to iproute2 in Ubuntu.
Matching subsc
** Attachment added: "Upstream 6.5 changelog"
https://bugs.launchpad.net/ubuntu/+source/iproute2/+bug/2051672/+attachment/5763787/+files/6.5-changes.txt
--
You received this bug notification because you are a member of Kernel
Packages, which is subscribed to iproute2 in Ubuntu.
Matching subsc
** Attachment added: "Upstream 6.4 changelog"
https://bugs.launchpad.net/ubuntu/+source/iproute2/+bug/2051672/+attachment/5763786/+files/6.4-changes.txt
--
You received this bug notification because you are a member of Kernel
Packages, which is subscribed to iproute2 in Ubuntu.
Matching subsc
It seems like this bug should now be a FFe (see
https://wiki.ubuntu.com/FreezeExceptionProcess) - so converting...
--
You received this bug notification because you are a member of Kernel
Packages, which is subscribed to iproute2 in Ubuntu.
Matching subscriptions: iproute2
https://bugs.launchpad.
** Attachment added: "Upstream 6.2 changelog"
https://bugs.launchpad.net/ubuntu/+source/iproute2/+bug/2051672/+attachment/5763784/+files/6.2-changes.txt
--
You received this bug notification because you are a member of Kernel
Packages, which is subscribed to iproute2 in Ubuntu.
Matching subsc
** Attachment added: "Upstream 6.3 changelog"
https://bugs.launchpad.net/ubuntu/+source/iproute2/+bug/2051672/+attachment/5763785/+files/6.3-changes.txt
--
You received this bug notification because you are a member of Kernel
Packages, which is subscribed to iproute2 in Ubuntu.
Matching subsc
** Summary changed:
- Merge iproute2 with the latest Debian version: 6.8.0-1 from testing/unstable
(main)
+ [FFe] Merge iproute2 with the latest Debian version: 6.8.0-1 from
testing/unstable (main)
--
You received this bug notification because you are a member of Kernel
Packages, which is subs
*** This bug is a duplicate of bug 2051672 ***
https://bugs.launchpad.net/bugs/2051672
** This bug has been marked a duplicate of bug 2051672
Merge iproute2 with the latest Debian version: 6.8.0-1 from testing/unstable
(main)
--
You received this bug notification because you are a member
** Changed in: linux (Ubuntu)
Assignee: Jose Ogando Justo (joseogando) => Mitchell Augustin
(mitchellaugustin)
** Changed in: linux (Ubuntu)
Status: Fix Committed => In Progress
--
You received this bug notification because you are a member of Kernel
Packages, which is subscribed to
I've build-tested on all architectures in this PPA:
https://launchpad.net/~dannf/+archive/ubuntu/mthp/+packages
I manually tested on a few systems, timing a full kernel build w/ the
Ubuntu config in a tmpfs (both to stress the system, and look for
performance differences).
- ppc64el / Power9 -
** Changed in: linux (Ubuntu)
Status: New => In Progress
--
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/2059316
Title:
backport arm64 THP improvements from 6.9
Status in linux pa
** Changed in: linux (Ubuntu)
Assignee: (unassigned) => dann frazier (dannf)
--
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/2059316
Title:
backport arm64 THP improvements from
Public bug reported:
Initial support for multi-size THP landed upstream in v6.8. In the 6.9
merge window, 2 other series have landed that show significant
performance improvements on arm64
mm/memory: optimize fork() with PTE-mapped THP
https://lkml.iu.edu/hypermail/linux/kernel/2401.3/02766.htm
= Verification =
$ cat /proc/version
Linux version 6.5.0-27-generic (buildd@lcy02-amd64-059)
(x86_64-linux-gnu-gcc-13 (Ubuntu 13.2.0-4ubuntu3) 13.2.0, GNU ld (GNU Binutils
for Ubuntu) 2.41) #28-Ubuntu SMP PREEMPT_DYNAMIC Thu Mar 7 18:21:00 UTC 2024
ubuntu@ubuntu:~/autotest-client-tests/ubuntu
** Changed in: shim-signed (Ubuntu Cosmic)
Status: Triaged => Won't Fix
** Changed in: shim-signed (Ubuntu Bionic)
Status: Triaged => Fix Released
** Changed in: linux-signed (Ubuntu Cosmic)
Status: Triaged => Won't Fix
** Changed in: linux-meta (Ubuntu Cosmic)
Status
: Undecided
Status: Won't Fix
** Affects: linux (Ubuntu Mantic)
Importance: Undecided
Assignee: dann frazier (dannf)
Status: In Progress
** Also affects: linux (Ubuntu Mantic)
Importance: Undecided
Status: New
** Changed in: linux (Ubuntu)
Status: New =&g
I'm glad to hear you are seeing an improvement! The current
implementation is still racy as mentioned in Comment #22. I did a search
of the logs I downloaded, and I believe this one shows that the
mount_partition() race isn't just theoretical:
https://autopkgtest.ubuntu.com/results/autopkgtest-
ma
** Also affects: linux (Ubuntu)
Importance: Undecided
Status: New
** Also affects: nvidia-graphics-drivers-535-server (Ubuntu)
Importance: Undecided
Status: New
--
You received this bug notification because you are a member of Kernel
Packages, which is subscribed to linux in
While the above MP is now merged, I still see additional potential races
in the code. For example, anything calling mount_partition() for the
first partition, and also maybe bug 2030771. I don't see a good way to
solve that w/o `udevadm lock` because these functions don't currently
know what the fu
** Also affects: util-linux (Ubuntu Mantic)
Importance: Undecided
Status: New
** Also affects: livecd-rootfs (Ubuntu Mantic)
Importance: Undecided
Status: New
** Also affects: linux (Ubuntu Mantic)
Importance: Undecided
Status: New
** Also affects: util-linux (Ubunt
** Attachment added: "jammy: verification steps 4-6"
https://bugs.launchpad.net/ubuntu/+source/linux-nvidia/+bug/2043059/+attachment/5744328/+files/jammy.log
** Tags removed: verification-needed verification-needed-jammy
verification-needed-mantic
** Tags added: verification-done verification
** Attachment added: "mantic: verification steps 4-6"
https://bugs.launchpad.net/ubuntu/+source/linux-nvidia/+bug/2043059/+attachment/5744327/+files/mantic.log
--
You received this bug notification because you are a member of Kernel
Packages, which is subscribed to linux-nvidia in Ubuntu.
htt
# verification steps 1-3: installation in a chroot
I set up 2 chroots - one w/ the normal sources.list, the other w/
proposed enabled, and did a side by side install test.
$ for chroot in mantic mantic-proposed jammy jammy-proposed; do sudo chroot
$chroot apt list kdump-tools; done
Listing... Do
** Changed in: libpcap (Ubuntu)
Assignee: (unassigned) => dann frazier (dannf)
** Changed in: libpcap (Ubuntu)
Status: Triaged => In Progress
--
You received this bug notification because you are a member of Kernel
Packages, which is subscribed to linux in Ubuntu.
** Also affects: linux-nvidia-tegra-igx (Ubuntu)
Importance: Undecided
Status: New
** No longer affects: linux-nvidia-tegra (Ubuntu)
** No longer affects: linux-nvidia-tegra (Ubuntu Jammy)
--
You received this bug notification because you are a member of Kernel
Packages, which is subs
** Description changed:
- Processing triggers for linux-image-5.15.0-1040-nvidia (5.15.0-1040.40) ...
- /etc/kernel/postinst.d/dkms:
- * dkms: running auto installation service for kernel 5.15.0-1040-nvidia
-...done.
- /etc/kernel/postinst.d/initramfs-tools:
- update-initramfs: Generating /bo
** Also affects: linux-nvidia (Ubuntu Noble)
Importance: Undecided
Status: Invalid
** Also affects: kdump-tools (Ubuntu Noble)
Importance: Undecided
Assignee: dann frazier (dannf)
Status: Fix Released
** Also affects: linux-nvidia (Ubuntu Mantic)
Importance: Undecided
Public bug reported:
From
https://objectstorage.prodstack5.canonical.com/swift/v1/AUTH_0f9aae918d5b4744bf7b827671c86842/autopkgtest-
jammy/jammy/arm64/l/linux-nvidia-6.5/20240131_012859_fd7ca@/log.gz:
7141s dpkg-deb: building package 'linux-nvidia-6.5-tools-6.5.0-1011' in
'../linux-nvidia-6.5-to
Public bug reported:
From
https://objectstorage.prodstack5.canonical.com/swift/v1/AUTH_0f9aae918d5b4744bf7b827671c86842/autopkgtest-
jammy/jammy/arm64/l/linux-nvidia-tegra-igx/20240121_072109_094a7@/log.gz
:
6243s dpkg-deb: building package 'linux-nvidia-tegra-igx-tools-5.15.0-1007' in
'../linux
The test passed w/ flock as well:
https://autopkgtest.ubuntu.com/results/autopkgtest-noble-dannf-loop/noble/amd64/l/livecd-rootfs/20240131_104633_df869@/log.gz
274 successful iterations before the timeout killed it.
I've updated the MP:
https://code.launchpad.net/~dannf/livecd-rootfs/+git/l
On Tue, Jan 30, 2024 at 6:21 PM Michael Hudson-Doyle
<2045...@bugs.launchpad.net> wrote:
>
> Oh wait, we've been through something very like this before
> https://bugs.launchpad.net/cloud-initramfs-tools/+bug/1834875. I suspect
> a judicious application of flock may be the most correct solution
> a
I updated my livecd-rootfs PPA test package that runs this section of
code in a loop to use this pattern, and it survived until the
autopkgtest timeout - 304 iterations:
https://autopkgtest.ubuntu.com/results/autopkgtest-noble-dannf-
loop/noble/amd64/l/livecd-rootfs/20240128_061640_5c909@/log.gz
I was bothered by the fact that we only sometimes see the double
partition rescan in dmesg. If udev always rescans the partitions of a
full block devices, shouldn't we always see those messages twice?
It turns out that udev doesn't rescan partitions just because a new
block device appears. When it
That kernel change doesn't fix the issue:
https://autopkgtest.ubuntu.com/results/autopkgtest-noble-dannf-
loop/noble/amd64/l/livecd-rootfs/20240125_203808_8b5c9@/log.gz
Which actually didn't surprise me after thinking about it. systemd-udevd
is going to ask for a partition reread when it gets the
On Tue, Jan 23, 2024 at 8:55 PM Michael Hudson-Doyle
<2045...@bugs.launchpad.net> wrote:
>
> Amazing debugging Dann. Until we can get a kernel fix, what's the way
> forward here? Run losetup without -P, run udevadm settle, run partprobe
> on the device (then maybe run udevadm settle again??)
That
We're checking to see if the system behaves the same with NVIDIA's
BaseOS. If it is, we'll probably move on and this can move to Won't Fix.
--
You received this bug notification because you are a member of Kernel
Packages, which is subscribed to linux-nvidia in Ubuntu.
https://bugs.launchpad.net/
** Summary changed:
- livecd-rootfs uses losetup -P for theoretically reliable/synchronous
partition setup but it's not reliable in noble
+ livecd-rootfs uses losetup -P for theoretically reliable/synchronous
partition setup but it's not reliable
--
You received this bug notification because y
I ran the above test:
https://autopkgtest.ubuntu.com/results/autopkgtest-jammy-dannf-test/jammy/amd64/l/livecd-rootfs/20240123_035147_6470b@/log.gz
It does appear that systemd-udevd is trying to scan partitions at the
same time as losetup:
1599s ++ losetup --show -f -P -v binary/boot/disk-uefi
I ran into this on jammy/amd64:
https://autopkgtest.ubuntu.com/results/autopkgtest-
jammy/jammy/amd64/l/livecd-rootfs/20240121_173406_e4f9a@/log.gz
I downloaded all of the amd64 failures and searched for this failure
pattern. These were the kernels that were running at the time:
"Linux 5.15.0-91-
On Fri, Dec 15, 2023 at 3:55 PM Sam Tannous <2043...@bugs.launchpad.net> wrote:
>
> You're correct. It can fail for other reasons. I don't think we could check
> the errno, could we? It would be 1, "Operation not permitted".
The exit code is not documented in the manpage, and it appears to exi
Cool, thanks for testing Sam. Apologies for the missing ${SW_IMG}.
And thanks for the 'unshare -U true' suggestion. I gather your point is
that 'unshare -U' will fail in any chroot environment. I'm not an expert
on namespaces but, from what I can tell, that does seem to be true in
all modern kerne
hey Sam,
I looked into ways to try to teach the chroot detection tools how to
detect a chroot in a new pid namespace (which is actually the problem,
not the mount namespace), but I didn't find a good solution there.
However, it occurs to me that you can simply override the answer:
ln -sf ../../b
** Also affects: kdump-tools (Ubuntu)
Importance: Undecided
Status: New
** Changed in: linux-nvidia (Ubuntu)
Status: New => Invalid
** Changed in: kdump-tools (Ubuntu)
Status: New => Triaged
** Changed in: kdump-tools (Ubuntu)
Assignee: (unassigned) => dan
Thanks for providing that script Sam. Jamie has nailed the problem in
Comment #2. A *seemingly* obvious solution is to add code to the
/etc/kernel/postinst.d/kdump-tools hook that detects when it is running
in a chroot, and if so, exits before trying to make an initramfs. When
the real system boots
: dann frazier (dannf)
Status: In Progress
** Changed in: linux (Ubuntu)
Status: New => In Progress
** Changed in: linux (Ubuntu)
Assignee: (unassigned) => dann frazier (dannf)
--
You received this bug notification because you are a member of Kernel
Packages, wh
** Also affects: kdump-tools (Ubuntu)
Importance: Undecided
Status: New
** No longer affects: kdump-tools (Ubuntu)
--
You received this bug notification because you are a member of Kernel
Packages, which is subscribed to makedumpfile in Ubuntu.
Matching subscriptions: Maintainer
https:
** Also affects: linux (Ubuntu)
Importance: Undecided
Status: New
** Also affects: linux (Ubuntu Jammy)
Importance: Undecided
Status: New
** Also affects: linux-bluefield (Ubuntu Jammy)
Importance: Undecided
Status: New
** Changed in: linux (Ubuntu Jammy)
Sta
It appears that Linus applied a fix for this directly in a merge commit:
https://github.com/torvalds/linux/commits/fc02cb2b37fe2cbf1d3334b9f0f0eab9431766c4
When the change with this bug was backported to stable, the fix was
squashed. But we appear to have cherry-picked the version from mainline
** Summary changed:
- No video output from discrete GPU (DGX Station A100)
+ Archive races can cause nvidia driver / kernel version ABI mismatch
** Also affects: linux-restricted-modules (Ubuntu)
Importance: Undecided
Status: New
--
You received this bug notification because you are a
** Changed in: linux-nvidia-6.2 (Ubuntu)
Status: New => In Progress
--
You received this bug notification because you are a member of Kernel
Packages, which is subscribed to linux-nvidia-6.2 in Ubuntu.
https://bugs.launchpad.net/bugs/2026891
Title:
linux-nvidia-6.2 on DGX servers: "WARN
It seems like this would impact the generic kernel as well, in which
case, it would be nice to fix it there and let the -bluefield kernel
inherit it via rebase.
--
You received this bug notification because you are a member of Kernel
Packages, which is subscribed to linux-bluefield in Ubuntu.
htt
This bug is about installing on a system with a different version of
binutils. I assumed that is what you are doing because that is what this
bug is about. But based on your comment @khteh, I now assume that you
are not hitting the problem I reported. Do you have a reason to believe
your issue is c
I was curious why this wasn't a problem with focal/5.4. I took a look at
the last cert run that used focal/5.4[*], and I see these errors in the
logs as well. I then went back to the cert run that was used to award
focal certification[**] and those errors do *not* appear there.
So either this is a
** Package changed: ubuntu => linux-nvidia (Ubuntu)
--
You received this bug notification because you are a member of Kernel
Packages, which is subscribed to linux-nvidia in Ubuntu.
https://bugs.launchpad.net/bugs/2025616
Title:
kernel Firmware Bug: TSC ADJUST differs failures during suspend
Canonical has provided a signature for an exact set of bytes in the .ko
file. The packaging needs to relink the object files into that exact set
of bytes on the target system for the signature to match. The relinking
is required for license compliance AIUI. binutils does the linking. If
you use a d
*** This bug is a duplicate of bug 2008157 ***
https://bugs.launchpad.net/bugs/2008157
** This bug has been marked a duplicate of bug 2008157
[SRU][Ubuntu 22.04.1]: Observed "Array Index out of bounds" Call Trace
multiple times on Ubuntu 22.04.1 OS during boot
--
You received this bug no
** Also affects: linux (Ubuntu Jammy)
Importance: Undecided
Status: New
** Also affects: linux (Ubuntu Kinetic)
Importance: Undecided
Status: New
--
You received this bug notification because you are a member of Kernel
Packages, which is subscribed to linux in Ubuntu.
https:/
** Changed in: linux (Ubuntu)
Status: Incomplete => In Progress
--
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/2008824
Title:
sched: cpumask: improve on cpumask_local_spread() loc
valuable to land those in lunar, allowing our LTS users to
adopt them more quickly starting with the HWE kernel in 22.04.3.
** Affects: linux (Ubuntu)
Importance: Undecided
Assignee: dann frazier (dannf)
Status: Incomplete
** Changed in: linux (Ubuntu)
Assignee: (unassigned
This issue only impacts linux-bluefield/focal because it uniquely
included a backport of upstream commit 339706bc21c1 ("netfilter:
nft_lookup: update element stateful expression") from v5.7-rc1 without
these follow up fixes that also landed in upstream before v5.7 final:
24791b9aa1ab0 netfilter: n
** Bug watch added: Debian Bug tracker #1030898
https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=1030898
** Also affects: libpcap (Debian) via
https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=1030898
Importance: Unknown
Status: Unknown
** No longer affects: libpcap (Ubuntu Bioni
** Also affects: libpcap (Ubuntu)
Importance: Undecided
Status: New
** Changed in: linux (Ubuntu)
Status: Incomplete => Invalid
** Summary changed:
- [focal, jammy]Enable rdma-sniffer for libpcap
+ Enable rdma-sniffer for libpcap
** Also affects: libpcap (Ubuntu Focal)
Impo
>From the serial log, it looks to me like you don't have enough memory
reserved. Try bumping up crashkernel=? You're not getting to the point
of running makedumpfile so I don't see how it would be impacted.
Its hard to say why jammy works for you and focal does not. I don't
think we have a larger
What happened here is that we dropped the 510 driver in lrm
5.4.0-135.152+1, transitioning it to the 515 driver. It therefore did
not produce a 5.4.0-135.152+1 version of linux-modules-
nvidia-510-server-5.4.0-135-generic. Ubuntu always keeps the latest
version of a binary package in the archive, e
** Also affects: kdump-tools (Ubuntu Lunar)
Importance: High
Status: In Progress
** Also affects: kdump-tools (Ubuntu Kinetic)
Importance: Undecided
Status: New
** Also affects: kdump-tools (Ubuntu Jammy)
Importance: Undecided
Status: New
--
You received this bug n
Thanks! OK, that shows that we've successfully booted the kernel, but it
is having an issue bringing up a CPU. I've pasted the relevant snippet
below. It isn't obvious to me if this is a kernel issue or some other
platform issue. As a next step, I'd suggest attempting to reproduce w/
the latest mai
Whether or not we can reproduce on other machines, I think we still need
to try to diagnose what is going on with papat. I think there's a series
of steps we can do to help diagnose that - I'd suggest starting w/ the
"earlycon" test.
--
You received this bug notification because you are a member
On Wed, Sep 28, 2022 at 12:41 PM Kellen Renshaw
<1970...@bugs.launchpad.net> wrote:
>
> Thanks Dann!
>
> Oof, the links didn't make it from the draft document, fixed now.
>
> If I understand your previous comment correctly, a better variant of
> this testing procedure would be a regression testing
On Fri, Sep 23, 2022 at 11:15 AM Kellen Renshaw
<1970...@bugs.launchpad.net> wrote:
>
> I have put up a draft SRU exception page at
> https://wiki.ubuntu.com/MakedumpfileUpdates. Comments/edits are welcome.
> I am working on finding an appropriate place for test vmcores to be
> stored.
Awesome! Th
** Also affects: grub2 (Ubuntu)
Importance: Undecided
Status: New
** Also affects: linux (Ubuntu)
Importance: Undecided
Status: New
** No longer affects: ubuntu
--
You received this bug notification because you are a member of Kernel
Packages, which is subscribed to linux in
Well, yes and no. xgene-uboot *is* required. But xgene-uboot *is* the
generic kernel - it just has a u-boot wrapper prepended. So what I meant
by comment #10, is that I wonder should allow xgene-uboot in the same
cases where we allow -generic for HWE kernels, such as this code from
src/maasserver/u
I wonder if we just need to treat xgene-uboot as an alias for generic in
the MAAS code?
--
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/1922910
Title:
Unable to deploy HWE kernel with sub
I'm not on the kernel team, but I'm not sure what would make this flavor
invalid w/ HWE. The xgene-uboot flavor is merely a wrapped version of
the -generic kernel. This kernel works fine on the target platform, once
you can get it installed.
** Changed in: maas
Status: Expired => New
** De
This is actually 100% reproducible for me - perhaps a hardware issue?
--
You received this bug notification because you are a member of Kernel
Packages, which is subscribed to linux-bluefield in Ubuntu.
https://bugs.launchpad.net/bugs/1987122
Title:
Null pointer dereference at pc : pka_drv_pro
** Also affects: linux-bluefield (Ubuntu Focal)
Importance: Undecided
Status: New
--
You received this bug notification because you are a member of Kernel
Packages, which is subscribed to linux-bluefield in Ubuntu.
https://bugs.launchpad.net/bugs/1987122
Title:
Null pointer dereferen
Public bug reported:
Seen once booting 5.4.0-1042.47
[9.389510] Unable to handle kernel NULL pointer dereference at virtual
address
[9.398549] Mem abort info:
[9.401407] ESR = 0x9604
[9.404494] EC = 0x25: DABT (current EL), IL = 32 bits
[9.409820] S
The merging of 5.15.44 is tracked in bug 1981649
--
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/1973153
Title:
kernel oops triggered by read_all_sys in ubuntu_ltp/fs on J-5.15 /
J-5.17
This appears to now be addressed in stable:
https://www.mail-archive.com/ovs-dev@openvswitch.org/msg65275.html
And that fix is currently queued in jammy/master-next:
https://git.launchpad.net/~ubuntu-kernel/ubuntu/+source/linux/+git/jammy/commit/?h=master-next&id=352a39407e5bab5a5965e5bcb7abf1
** Also affects: linux (Ubuntu)
Importance: Undecided
Status: New
--
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/1977847
Title:
OVS/CT kernel stack trace during boot on Jammy O
** Changed in: linux (Ubuntu Jammy)
Status: Fix Committed => Fix Released
--
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/1952933
Title:
impish kernel crashes on hp m400 in mlx4_en
This fix is merged in v5.15.44
--
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/1973153
Title:
kernel oops triggered by read_all_sys in ubuntu_ltp/fs on J-5.15 /
J-5.17 ARM64 "helo-kerne
** Changed in: linux (Ubuntu)
Status: Fix Committed => Fix Released
--
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/1966194
Title:
[Jammy, mlx5, ConnectX-7] add CX7 support for sof
Yeah, I don't think an autopkgtest is a requirement. Having the test
live within the package itself would make it more accessible, and
autopkgtest was my first thought as to how to do that. But I don't see a
"disable by default" flag, and I agree that huge downloads on every test
run could be a pro
Patches are now queued for all applicable stable trees (linux-4.14.y+)
--
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/1973153
Title:
kernel oops triggered by read_all_sys in ubuntu_ltp/f
Thanks everyone for trying to tackle this long-standing issue. fwiw,
here's my $0.02 no how we could proceed:
Someone should draft a special case page for makedumpfile:
https://wiki.ubuntu.com/StableReleaseUpdates#Documentation_for_Special_Cases
I'm happy to review/provide feedback, but I'd rather
1 - 100 of 1501 matches
Mail list logo
