from:"Matthew"

Patch on Kernel Team mailing list:

Cover Letter:
https://lists.ubuntu.com/archives/kernel-team/2024-August/153135.html
Patch:
https://lists.ubuntu.com/archives/kernel-team/2024-August/153136.html

-- 
You received this bug notification because you are a member of Ubuntu
Bugs, which is subscribed to Ubuntu.
https://bugs.launchpad.net/bugs/2069961

Title:
  turbostat fails with too many open files on large systems

To manage notifications about this bug go to:
https://bugs.launchpad.net/ubuntu/+source/linux/+bug/2069961/+subscriptions


-- 
ubuntu-bugs mailing list
ubuntu-bugs@lists.ubuntu.com
https://lists.ubuntu.com/mailman/listinfo/ubuntu-bugs

[Bug 2069961] Re: turbostat fails with too many open files on large systems

** Description changed:

BugLink: https://bugs.launchpad.net/bugs/2069961

[Impact]

On large systems, e.g. with 512 cpus or more, turbostat fails to run due
to exceeding the rlimit for number of files. 512 cpus requires 1028 file
descriptors, but the current limit is 999.

$ lscpu
...
CPU(s): 512
On-line CPU(s) list: 0-511
...

$ sudo turbostat
...
turbostat: /sys/devices/system/cpu/cpu477/cpuidle/state0/usage: open failed:
Too many open files

There is no workaround, apart from maybe using powerstat instead.

[Fix]

The fix is to increase the rlimit to increase the amount of file
descriptors that turbostat can open to 2^15, which should be plenty for
some time to come.

commit 3ac1d14d0583a2de75d49a5234d767e2590384dd
Author: Wyes Karny
Date: Tue Oct 3 05:07:51 2023 +
Subject: tools/power turbostat: Increase the limit for fd opened
Link:
https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/commit/?id=3ac1d14d0583a2de75d49a5234d767e2590384dd

- This landed in 6.9-rc4, and is a clean cherry pick to jammy. Noble got
- fixed already through upstream stable.
+ This landed in 6.9-rc4, and requires a backport for minor context
+ adjustment in the first hunk for jammy. Noble got fixed already through
+ upstream stable.

[Testcase]

Deploy a bare metal system with 512 or more cpus.

Install linux-tools:

$ sudo apt install linux-tools-$(uname -r)

Run turbostat:

$ sudo turbostat
...
turbostat: /sys/devices/system/cpu/cpu477/cpuidle/state0/usage: open failed:
Too many open files

There are test kernels available in the following ppa:

https://launchpad.net/~mruffell/+archive/ubuntu/sf388491-test

If you install them, you should be able to see normal turbostat output
for all cpus installed in the system.

[Where problems can occur]

We are simply increasing the rlimit for file descriptors that turbostat
can open. This should have no impact on any existing systems.

If a regression should occur, then turbostat functionality might not
work. Users could use powerstat instead as a workaround while things are
fixed.

--
You received this bug notification because you are a member of Ubuntu
Bugs, which is subscribed to Ubuntu.
https://bugs.launchpad.net/bugs/2069961

Title:
turbostat fails with too many open files on large systems

To manage notifications about this bug go to:
https://bugs.launchpad.net/ubuntu/+source/linux/+bug/2069961/+subscriptions

--
ubuntu-bugs mailing list
ubuntu-bugs@lists.ubuntu.com
https://lists.ubuntu.com/mailman/listinfo/ubuntu-bugs

[Bug 2069961] Re: turbostat fails with too many open files on large systems

Noble (6.8) got fixed already in 6.8.0-40-generic as a part of bug
2070349.

** Changed in: linux (Ubuntu Noble)
Status: In Progress => Fix Released

** Description changed:

BugLink: https://bugs.launchpad.net/bugs/2069961

[Impact]

On large systems, e.g. with 512 cpus or more, turbostat fails to run due
to exceeding the rlimit for number of files. 512 cpus requires 1028 file
descriptors, but the current limit is 999.

$ lscpu
...
CPU(s): 512
On-line CPU(s) list: 0-511
...

$ sudo turbostat
...
turbostat: /sys/devices/system/cpu/cpu477/cpuidle/state0/usage: open failed:
Too many open files

There is no workaround, apart from maybe using powerstat instead.

[Fix]

The fix is to increase the rlimit to increase the amount of file
descriptors that turbostat can open to 2^15, which should be plenty for
some time to come.

- This landed in 6.9-rc4, and is a clean cherry pick to jammy and noble.
+ This landed in 6.9-rc4, and is a clean cherry pick to jammy. Noble got
+ fixed already through upstream stable.

[Testcase]

Deploy a bare metal system with 512 or more cpus.

Install linux-tools:

$ sudo apt install linux-tools-$(uname -r)

Run turbostat:

$ sudo turbostat
...
turbostat: /sys/devices/system/cpu/cpu477/cpuidle/state0/usage: open failed:
Too many open files

There are test kernels available in the following ppa:

https://launchpad.net/~mruffell/+archive/ubuntu/sf388491-test

If you install them, you should be able to see normal turbostat output
for all cpus installed in the system.

[Where problems can occur]

We are simply increasing the rlimit for file descriptors that turbostat
can open. This should have no impact on any existing systems.

If a regression should occur, then turbostat functionality might not
work. Users could use powerstat instead as a workaround while things are
fixed.

--
You received this bug notification because you are a member of Ubuntu
Bugs, which is subscribed to Ubuntu.
https://bugs.launchpad.net/bugs/2069961

Title:
turbostat fails with too many open files on large systems

To manage notifications about this bug go to:
https://bugs.launchpad.net/ubuntu/+source/linux/+bug/2069961/+subscriptions

--
ubuntu-bugs mailing list
ubuntu-bugs@lists.ubuntu.com
https://lists.ubuntu.com/mailman/listinfo/ubuntu-bugs

[Bug 2069961] Re: turbostat and powerstat not working on 22.04

** Description changed:

- We're unable to run Turbostat on Turin 2P Volcano systems with core
- count greater than 400 on Ubuntu 22.04. On Ubuntu 24.04 turbostat works
- fine.
+ BugLink: https://bugs.launchpad.net/bugs/2069961

- The following commit fixes the turbostat problem :
+ [Impact]

-
https://git.kernel.org/pub/scm/linux/kernel/git/lenb/linux.git/commit/?h=turbostat&id=3ac1d14d0583a2de75d49a5234d767e2590384dd
+ On large systems, e.g. with 512 cpus or more, turbostat fails to run due
+ to exceeding the rlimit for number of files. 512 cpus requires 1028 file
+ descriptors, but the current limit is 999.
+
+ $ lscpu
+ ...
+ CPU(s): 512
+ On-line CPU(s) list: 0-511
+ ...
+
+ $ sudo turbostat
+ ...
+ turbostat: /sys/devices/system/cpu/cpu477/cpuidle/state0/usage: open failed:
Too many open files
+
+ There is no workaround, apart from maybe using powerstat instead.
+
+ [Fix]
+
+ The fix is to increase the rlimit to increase the amount of file
+ descriptors that turbostat can open to 2^15, which should be plenty for
+ some time to come.
+
+ commit 3ac1d14d0583a2de75d49a5234d767e2590384dd
+ Author: Wyes Karny
+ Date: Tue Oct 3 05:07:51 2023 +
+ Subject: tools/power turbostat: Increase the limit for fd opened
+ Link:
https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/commit/?id=3ac1d14d0583a2de75d49a5234d767e2590384dd
+
+ This landed in 6.9-rc2, and is a clean cherry pick to jammy and noble.
+
+ [Testcase]
+
+ Deploy a bare metal system with 512 or more cpus.
+
+ Install linux-tools:
+
+ $ sudo apt install linux-tools-$(uname -r)
+
+ Run turbostat:
+
+ $ sudo turbostat
+ ...
+ turbostat: /sys/devices/system/cpu/cpu477/cpuidle/state0/usage: open failed:
Too many open files
+
+ There are test kernels available in the following ppa:
+
+ https://launchpad.net/~mruffell/+archive/ubuntu/sf388491-test
+
+ If you install them, you should be able to see normal turbostat output
+ for all cpus installed in the system.
+
+ [Where problems can occur]
+
+ We are simply increasing the rlimit for file descriptors that turbostat
+ can open. This should have no impact on any existing systems.
+
+ If a regression should occur, then turbostat functionality might not
+ work. Users could use powerstat instead as a workaround while things are
+ fixed.

** Summary changed:

- turbostat and powerstat not working on 22.04
+ turbostat fails with too many open files on large systems

** Description changed:

BugLink: https://bugs.launchpad.net/bugs/2069961

[Impact]

On large systems, e.g. with 512 cpus or more, turbostat fails to run due
to exceeding the rlimit for number of files. 512 cpus requires 1028 file
descriptors, but the current limit is 999.

$ lscpu
...
CPU(s): 512
- On-line CPU(s) list: 0-511
+ On-line CPU(s) list: 0-511
...

$ sudo turbostat
...
turbostat: /sys/devices/system/cpu/cpu477/cpuidle/state0/usage: open failed:
Too many open files

There is no workaround, apart from maybe using powerstat instead.

[Fix]

The fix is to increase the rlimit to increase the amount of file
descriptors that turbostat can open to 2^15, which should be plenty for
some time to come.

- This landed in 6.9-rc2, and is a clean cherry pick to jammy and noble.
+ This landed in 6.9-rc4, and is a clean cherry pick to jammy and noble.

[Testcase]

Deploy a bare metal system with 512 or more cpus.

Install linux-tools:

$ sudo apt install linux-tools-$(uname -r)

Run turbostat:

$ sudo turbostat
...
turbostat: /sys/devices/system/cpu/cpu477/cpuidle/state0/usage: open failed:
Too many open files

There are test kernels available in the following ppa:

https://launchpad.net/~mruffell/+archive/ubuntu/sf388491-test

If you install them, you should be able to see normal turbostat output
for all cpus installed in the system.

[Where problems can occur]

We are simply increasing the rlimit for file descriptors that turbostat
can open. This should have no impact on any existing systems.

If a regression should occur, then turbostat functionality might not
work. Users could use powerstat instead as a workaround while things are
fixed.

--
You received this bug notification because you are a member of Ubuntu
Bugs, which is subscribed to Ubuntu.
https://bugs.launchpad.net/bugs/2069961

Title:
turbostat fails with too many open files on large systems

To manage notifications about this bug go to:
https://bugs.launchpad.net/ubuntu/+source/linux/+bug/2069961/+subscriptions

--
ubuntu-bugs mailing list
ubuntu-bugs@lists.ubuntu.com
https://lists.

[Bug 2069961] Re: turbostat and powerstat not working on 22.04

** Changed in: linux (Ubuntu)
   Status: New => Fix Released

** Changed in: linux (Ubuntu Jammy)
   Status: New => In Progress

** Changed in: linux (Ubuntu Noble)
   Status: New => In Progress

** Changed in: linux (Ubuntu Jammy)
   Importance: Undecided => Medium

** Changed in: linux (Ubuntu Noble)
   Importance: Undecided => Medium

** Changed in: linux (Ubuntu Jammy)
 Assignee: (unassigned) => Matthew Ruffell (mruffell)

** Changed in: linux (Ubuntu Noble)
 Assignee: (unassigned) => Matthew Ruffell (mruffell)

** Tags added: sts

-- 
You received this bug notification because you are a member of Ubuntu
Bugs, which is subscribed to Ubuntu.
https://bugs.launchpad.net/bugs/2069961

Title:
  turbostat and powerstat not working on 22.04

To manage notifications about this bug go to:
https://bugs.launchpad.net/ubuntu/+source/linux/+bug/2069961/+subscriptions


-- 
ubuntu-bugs mailing list
ubuntu-bugs@lists.ubuntu.com
https://lists.ubuntu.com/mailman/listinfo/ubuntu-bugs

[Bug 2077741] Re: No default background set for GNOME-Greeter

2024-08-23 Thread Matthew Hagemann

** Changed in: ubuntu-settings (Ubuntu)
Milestone: None => ubuntu-24.10

-- 
You received this bug notification because you are a member of Ubuntu
Bugs, which is subscribed to Ubuntu.
https://bugs.launchpad.net/bugs/2077741

Title:
  No default background  set for GNOME-Greeter

To manage notifications about this bug go to:
https://bugs.launchpad.net/ubuntu/+source/ubuntu-settings/+bug/2077741/+subscriptions


-- 
ubuntu-bugs mailing list
ubuntu-bugs@lists.ubuntu.com
https://lists.ubuntu.com/mailman/listinfo/ubuntu-bugs

[Bug 2077741] [NEW] No default background set for GNOME-Greeter

2024-08-23 Thread Matthew Hagemann

Public bug reported:

While using Gnome-Initial-Setup launched from GDM (when no user > 1000
is present on the machine), no background is set on GNOME-Greeter,
leading to a solid blue background wallpaper.

Could we set the background here to the Ubuntu default? By updating
/usr/share/glib-2.0/schemas/10_ubuntu-settings.gschema.override with:

```
# for GDM/DM
# FIXME: move to :Ubuntu-Greeter once upstream supports this, see LP: #1788

[org.gnome.desktop.interface:GNOME-Greeter]
gtk-theme = 'Yaru'
icon-theme = 'Yaru'
cursor-theme = 'Yaru'
font-name = 'Ubuntu 11'
monospace-font-name = 'Ubuntu Mono 13'
font-antialiasing = 'rgba'

[org.gnome.login-screen]
logo='/usr/share/plymouth/ubuntu-logo.png'

+ [org.gnome.desktop.background:GNOME-Greeter]
+ picture-uri = 'file:///usr/share/backgrounds/warty-final-ubuntu.png'
+ picture-uri-dark = 'file:///usr/share/backgrounds/ubuntu-wallpaper-d.png'
+ show-desktop-icons = false
```

I was able to add in one. This will help improve the GIS installer flow
for Raspberry Pi we plan to support in 24.10

ubuntu-settings:
  Installed: 24.04.3
Ubuntu version: 24.04 LTS

** Affects: ubuntu-settings (Ubuntu)
 Importance: Undecided
 Status: New

-- 
You received this bug notification because you are a member of Ubuntu
Bugs, which is subscribed to Ubuntu.
https://bugs.launchpad.net/bugs/2077741

Title:
  No default background  set for GNOME-Greeter

To manage notifications about this bug go to:
https://bugs.launchpad.net/ubuntu/+source/ubuntu-settings/+bug/2077741/+subscriptions


-- 
ubuntu-bugs mailing list
ubuntu-bugs@lists.ubuntu.com
https://lists.ubuntu.com/mailman/listinfo/ubuntu-bugs

[Bug 2077145] Re: GDS force mitigation re-enabled in 6.10 causing crashes

2024-08-21 Thread Matthew Ruffell

Hi Tormod,

Could you check 6.11.0-4-generic for Oracular in this particular ppa?

https://launchpad.net/~canonical-kernel-team/+archive/ubuntu/unstable

The 6.10 kernel in -proposed will be replaced by this one, or a newer
build eventually.

Just waiting for the kernel team to make the source available in the
normal oracular git repo.

Thanks,
Matthew

-- 
You received this bug notification because you are a member of Ubuntu
Bugs, which is subscribed to Ubuntu.
https://bugs.launchpad.net/bugs/2077145

Title:
  GDS force mitigation re-enabled in 6.10 causing crashes

To manage notifications about this bug go to:
https://bugs.launchpad.net/ubuntu/+source/linux/+bug/2077145/+subscriptions


-- 
ubuntu-bugs mailing list
ubuntu-bugs@lists.ubuntu.com
https://lists.ubuntu.com/mailman/listinfo/ubuntu-bugs

[Bug 2053194] Re: latest kernel update breaks sata hotplug on z690

2024-08-21 Thread Matthew Eaton

Good news. I installed kernel 6.8.0-44 from the proposed ppa and hotplug
is working again. So a fix should be in the pipeline. Can anyone else
confirm?

https://launchpad.net/~canonical-kernel-team/+archive/ubuntu/proposed

-- 
You received this bug notification because you are a member of Ubuntu
Bugs, which is subscribed to Ubuntu.
https://bugs.launchpad.net/bugs/2053194

Title:
  latest kernel update breaks sata hotplug on z690

To manage notifications about this bug go to:
https://bugs.launchpad.net/ubuntu/+source/linux-signed-hwe-6.5/+bug/2053194/+subscriptions


-- 
ubuntu-bugs mailing list
ubuntu-bugs@lists.ubuntu.com
https://lists.ubuntu.com/mailman/listinfo/ubuntu-bugs

[Bug 2077437] [NEW] unable to upgrade from 22.04 to 24.04

2024-08-20 Thread Matthew Z Wiese

Public bug reported:

matt-desktop# cat /etc/update-manager/release-upgrades
# Default behavior for the release upgrader.

[DEFAULT]
# Default prompting and upgrade behavior, valid options:
#
#  never  - Never check for, or allow upgrading to, a new release.
#  normal - Check to see if a new release is available.  If more than one new
#   release is found, the release upgrader will attempt to upgrade to
#   the supported release that immediately succeeds the
#   currently-running release.
#  lts- Check to see if a new LTS release is available.  The upgrader
#   will attempt to upgrade to the first LTS release available after
#   the currently-running one.  Note that if this option is used and
#   the currently-running release is not itself an LTS release the
#   upgrader will assume prompt was meant to be normal.
Prompt=lts
matt-desktop# do-release-upgrade -d
Checking for a new Ubuntu release

= Welcome to Ubuntu 24.04 LTS 'Noble Numbat' =

The Ubuntu team is proud to announce Ubuntu 24.04 LTS 'Noble Numbat'.

To see what's new in this release, visit:
  https://wiki.ubuntu.com/NobleNumbat/ReleaseNotes

Ubuntu is a Linux distribution for your desktop or server, with a fast
and easy install, regular releases, a tight selection of excellent
applications installed by default, and almost any other software you
can imagine available through the network.

We hope you enjoy Ubuntu.

== Feedback and Helping ==

If you would like to help shape Ubuntu, take a look at the list of
ways you can participate at

  http://www.ubuntu.com/community/participate/

Your comments, bug reports, patches and suggestions will help ensure
that our next release is the best release of Ubuntu ever.  If you feel
that you have found a bug please read:

  http://help.ubuntu.com/community/ReportingBugs

Then report bugs using apport in Ubuntu.  For example:

  ubuntu-bug linux

will open a bug report in Launchpad regarding the linux package.

If you have a question, or if you think you may have found a bug but
aren't sure, first try asking on the #ubuntu or #ubuntu-bugs IRC
channels on Libera.Chat, on the Ubuntu Users mailing list, or on the
Ubuntu forums:

  http://help.ubuntu.com/community/InternetRelayChat
  http://lists.ubuntu.com/mailman/listinfo/ubuntu-users
  http://www.ubuntuforums.org/


== More Information ==

You can find out more about Ubuntu on our website, IRC channel and wiki.
If you're new to Ubuntu, please visit:

  http://www.ubuntu.com/


To sign up for future Ubuntu announcements, please subscribe to Ubuntu's
very low volume announcement list at:

  http://lists.ubuntu.com/mailman/listinfo/ubuntu-announce


Continue [yN] y
Get:1 Upgrade tool signature [833 B]
Get:2 Upgrade tool [1,278 kB]
Fetched 1,279 kB in 0s (0 B/s)
authenticate 'noble.tar.gz' against 'noble.tar.gz.gpg'
extracting 'noble.tar.gz'

Reading cache

Checking package manager

Continue running under SSH?

This session appears to be running under ssh. It is not recommended
to perform a upgrade over ssh currently because in case of failure it
is harder to recover.

If you continue, an additional ssh daemon will be started at port
'1022'.
Do you want to continue?

Continue [yN] y

Starting additional sshd

To make recovery in case of failure easier, an additional sshd will
be started on port '1022'. If anything goes wrong with the running
ssh you can still connect to the additional one.
If you run a firewall, you may need to temporarily open this port. As
this is potentially dangerous it's not done automatically. You can
open the port with e.g.:
'iptables -I INPUT -p tcp --dport 1022 -j ACCEPT'

To continue please press [ENTER]

Reading package lists... Done
Building dependency tree... Done
Reading state information... Done
Hit http://us.archive.ubuntu.com/ubuntu jammy InRelease
Hit https://developer.download.nvidia.com/compute/cuda/repos/ubuntu2204/x86_64  
InRelease
Hit https://download.docker.com/linux/ubuntu jammy InRelease
Hit http://us.archive.ubuntu.com/ubuntu jammy-updates InRelease
Hit http://us.archive.ubuntu.com/ubuntu jammy-backports InRelease
Hit http://security.ubuntu.com/ubuntu jammy-security InRelease
Hit https://esm.ubuntu.com/apps/ubuntu jammy-apps-security InRelease
Hit https://esm.ubuntu.com/apps/ubuntu jammy-apps-updates InRelease
Hit https://esm.ubuntu.com/infra/ubuntu jammy-infra-security InRelease
Hit https://scala.jfrog.io/artifactory/debian all InRelease
Hit https://esm.ubuntu.com/infra/ubuntu jammy-infra-updates InRelease
Ign https://scala.jfrog.io/artifactory/debian  InRelease
Hit https://scala.jfrog.io/artifactory/debian  Release
Hit https://ppa.launchpadcontent.net/deadsnakes/ppa/ubuntu jammy InRelease
Fetched 0 B in 0s (0 B/s)
Reading package lists... Done
Building dependency tree... Done
Reading state information... Done

Checking for installed snaps

Calculating snap size requirements

Updating repository information

Third party sources disabled

Some third party entri

[Bug 2077044] Re: zap_pid_ns_processes() gets stuck in a busy loop when zombie processes are in namespace

2024-08-14 Thread Matthew Ruffell

This should land in 5.15.0-121-generic and 6.8.0-44-generic.

-- 
You received this bug notification because you are a member of Ubuntu
Bugs, which is subscribed to Ubuntu.
https://bugs.launchpad.net/bugs/2077044

Title:
  zap_pid_ns_processes() gets stuck in a busy loop when zombie processes
  are in namespace

To manage notifications about this bug go to:
https://bugs.launchpad.net/ubuntu/+source/linux/+bug/2077044/+subscriptions


-- 
ubuntu-bugs mailing list
ubuntu-bugs@lists.ubuntu.com
https://lists.ubuntu.com/mailman/listinfo/ubuntu-bugs

[Bug 2077044] [NEW] zap_pid_ns_processes() gets stuck in a busy loop when zombie processes are in namespace

2024-08-14 Thread Matthew Ruffell

Public bug reported:

BugLink: https://bugs.launchpad.net/bugs/2077044

[Impact]

A deadlock can occur in zap_pid_ns_processes() which can hang the system
due to RCU getting stuck.

zap_pid_ns_processes() has a busy loop that calls kernel_wait4() on a
child process of the namespace init task, waiting for it to exit. The
problem is, it clears TIF_SIGPENDING, but not TIF_NOTIFY_SIGNAL as well,
leading us to get stuck in the busy loop forever, due to the child
sleeping in synchronize_rcu(), and is never woken up due to the parent
being stuck in the busy loop and never calling schedule() or
rcu_note_context_switch().

A oops is:

Watchdog: BUG: soft lockup - CPU#3 stuck for 276s! [rcudeadlock:1836]
CPU: 3 PID: 1836 Comm: rcudeadlock Tainted: G L
5.15.0-117-generic #127-Ubuntu
RIP: 0010:_raw_read_lock+0xe/0x30
Code: f0 0f b1 17 74 08 31 c0 5d c3 cc cc cc cc b8 01 00 00 00 5d c3 cc cc cc 
cc 0f 1f 00 0f 1f 44 00 00 b8 00 02 00 00 f0 0f c1 07  ff 01 00 00 75 05 c3 
cc cc cc cc 55 48 89 e5 e8 4d 79 36 ff 5d
CR2: 00c0002b
Call Trace:
 
 ? show_trace_log_lvl+0x1d6/0x2ea
 ? show_trace_log_lvl+0x1d6/0x2ea
 ? kernel_wait4+0xaf/0x150
 ? show_regs.part.0+0x23/0x29
 ? show_regs.cold+0x8/0xd
 ? watchdog_timer_fn+0x1be/0x220
 ? lockup_detector_update_enable+0x60/0x60
 ? __hrtimer_run_queues+0x107/0x230
 ? read_hv_clock_tsc_cs+0x9/0x30
 ? hrtimer_interrupt+0x101/0x220
 ? hv_stimer0_isr+0x20/0x30
 ? __sysvec_hyperv_stimer0+0x32/0x70
 ? sysvec_hyperv_stimer0+0x7b/0x90
 
 
 ? asm_sysvec_hyperv_stimer0+0x1b/0x20
 ? _raw_read_lock+0xe/0x30
 ? do_wait+0xa0/0x310
 kernel_wait4+0xaf/0x150
 ? thread_group_exited+0x50/0x50
 zap_pid_ns_processes+0x111/0x1a0
 forget_original_parent+0x348/0x360
 exit_notify+0x4a/0x210
 do_exit+0x24f/0x3c0
 do_group_exit+0x3b/0xb0
 get_signal+0x150/0x900
 arch_do_signal_or_restart+0xde/0x100
 ? __x64_sys_futex+0x78/0x1e0
 exit_to_user_mode_loop+0xc4/0x160
 exit_to_user_mode_prepare+0xa3/0xb0
 syscall_exit_to_user_mode+0x27/0x50
 ? x64_sys_call+0x1022/0x1fa0
 do_syscall_64+0x63/0xb0
 ? __io_uring_add_tctx_node+0x111/0x1a0
 ? fput+0x13/0x20
 ? __do_sys_io_uring_enter+0x10d/0x540
 ? __smp_call_single_queue+0x59/0x90
 ? exit_to_user_mode_prepare+0x37/0xb0
 ? syscall_exit_to_user_mode+0x2c/0x50
 ? x64_sys_call+0x1819/0x1fa0
 ? do_syscall_64+0x63/0xb0
 ? try_to_wake_up+0x200/0x5a0
 ? wake_up_q+0x50/0x90
 ? futex_wake+0x159/0x190
 ? do_futex+0x162/0x1f0
 ? __x64_sys_futex+0x78/0x1e0
 ? switch_fpu_return+0x4e/0xc0
 ? exit_to_user_mode_prepare+0x37/0xb0
 ? syscall_exit_to_user_mode+0x2c/0x50
 ? x64_sys_call+0x1022/0x1fa0
 ? do_syscall_64+0x63/0xb0
 ? do_user_addr_fault+0x1e7/0x670
 ? exit_to_user_mode_prepare+0x37/0xb0
 ? irqentry_exit_to_user_mode+0xe/0x20
 ? irqentry_exit+0x1d/0x30
 ? exc_page_fault+0x89/0x170
 entry_SYSCALL_64_after_hwframe+0x6c/0xd6
 

There is no known workaround.

[Fix]

This was fixed in the below commit in 6.10-rc5:

commit 7fea700e04bd3f424c2d836e98425782f97b494e
Author: Oleg Nesterov 
Date:   Sat Jun 8 14:06:16 2024 +0200
Subject: zap_pid_ns_processes: clear TIF_NOTIFY_SIGNAL along with TIF_SIGPENDING
Link: 
https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/commit/?id=7fea700e04bd3f424c2d836e98425782f97b494e

This patch has made its way to upstream stable, and is already applied to Ubuntu
kernels.

[Testcase]

There are two possible testcases to reproduce this issue.
This reproducer is courtesy of Rachel Menge, using the reproducers in her 
github repo:

https://github.com/rlmenge/rcu-soft-lock-issue-repro

Start a Jammy or Noble VM on Azure, D8sV3 will be plenty.

$ git clone https://github.com/rlmenge/rcu-soft-lock-issue-repro.git

npm repro:

Install Docker.

$ sudo docker run telescope.azurecr.io/issue-repro/zombie:v1.1.11
$ ./rcu-npm-repro.sh

go repro:

$ go mod init rcudeadlock.go
$ go mod tidy
$ CGO_ENABLED=0 go build -o ./rcudeadlock ./
$ sudo ./rcudeadlock

Look at dmesg. After some minutes, you should see the hung task timeout
from the impact section.

[Where problems can occur]

We are clearing TIF_NOTIFY_SIGNAL in the child, in order for signal_pending() 
to return false and not lead us to a busy wait loop.
This change should work as intended.

If a regression were to occur, it could potentially affect all processes
in namespaces.

[Other Info]

Upstream mailing list discussion:
https://lore.kernel.org/linux-kernel/1386cd49-36d0-4a5c-85e9-bc42056a5...@linux.microsoft.com/T/

** Affects: linux (Ubuntu)
 Importance: Undecided
 Status: Fix Released

** Affects: linux (Ubuntu Jammy)
 Importance: Medium
 Assignee: Matthew Ruffell (mruffell)
 Status: Fix Committed

** Affects: linux (Ubuntu Noble)
 Importance: Medium
 Assignee: Matthew Ruffell (mruffell)
 Status: Fix Committed


** Tags: sts

** Also affects: linux (Ubuntu Noble)
   Importance: Undecided
   Status: New

** Also affects: linux (Ubuntu Jammy)
   Importance: Undecided
   Status: New

** Changed in: linux (Ubuntu

[Bug 2076957] Re: isolcpus are ignored when using cgroups V2, causing processes to have wrong affinity

2024-08-13 Thread Matthew Ruffell

Patches are on kernel team mailing list.

https://lists.ubuntu.com/archives/kernel-team/2024-August/152811.html
https://lists.ubuntu.com/archives/kernel-team/2024-August/152812.html

-- 
You received this bug notification because you are a member of Ubuntu
Bugs, which is subscribed to Ubuntu.
https://bugs.launchpad.net/bugs/2076957

Title:
  isolcpus are ignored when using cgroups V2, causing processes to have
  wrong affinity

To manage notifications about this bug go to:
https://bugs.launchpad.net/ubuntu/+source/linux/+bug/2076957/+subscriptions


-- 
ubuntu-bugs mailing list
ubuntu-bugs@lists.ubuntu.com
https://lists.ubuntu.com/mailman/listinfo/ubuntu-bugs

[Bug 2076957] [NEW] isolcpus are ignored when using cgroups V2, causing processes to have wrong affinity

2024-08-13 Thread Matthew Ruffell

Public bug reported:

BugLink: https://bugs.launchpad.net/bugs/2076957

[Impact]

In latency sensitive environments, it is very common to use isolcpus to
reserve a set of cpus that no other processes are to be placed on, and
run just dpdk in poll mode.

There is a bug in the jammy kernel, where if cgroups V2 are enabled,
after several minutes the kernel will place other processes onto these
reserved isolcpus at random. This disturbs dpdk and introduces latency.

The issue does not occur with cgroups V1, so a workaround is to use
cgroups V1 instead of V2 for the moment.

[Fix]

I arrived at this commit after a full git bisect, which fixes the issue.
It landed in 6.2-rc1:

commit 7fd4da9c1584be97ffbc40e600a19cb469fd4e78
Author: Waiman Long 
Date:   Sat Nov 12 17:19:39 2022 -0500
Subject: cgroup/cpuset: Optimize cpuset_attach() on v2
Link: 
https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/commit/?id=7fd4da9c1584be97ffbc40e600a19cb469fd4e78

Only the 5.15 Jammy kernel needs this fix. Focal works correctly as is.

The commit skips calls to cpuset_attach() if the underlying cpusets or
memory have not changed in a cgroup, and it seems to fix the issue.

[Testcase]

Deploy a bare metal server, ideally with a number of cores, 56 should be plenty.
Use Jammy, with the 5.15 GA kernel.

1) Edit /etc/default/grub and set GRUB_CMDLINE_LINUX_DEFAULT to have
"isolcpus=4-7,32-35 rcu_nocb_poll rcu_nocbs=4-7,32-35 
systemd.unified_cgroup_hierarchy=1"
2) sudo reboot
3) sudo cat /sys/devices/system/cpu/isolated
4-7,32-35
4) sudo apt install s-tui stress
5) sudo s-tui
6) htop
7) $ while true; do sudo ps -eLF | head -n 1; sudo ps -eLF | grep stress | awk 
-v a="4" '$9 == a {print;}'; sudo ps -eLF | grep stress | awk -v a="5" '$9 == a 
{print;}'; sudo ps -eLF | grep stress | awk -v a="6" '$9 == a {print;}'; sudo 
ps -eLF | grep stress | awk -v a="7" '$9 == a {print;}'; sudo ps -eLF | grep 
stress | awk -v a="32" '$9 == a {print;}'; sudo ps -eLF | grep stress | awk -v 
a="33" '$9 == a {print;}'; sudo ps -eLF | grep stress | awk -v a="34" '$9 == a 
{print;}'; sudo ps -eLF | grep stress | awk -v a="35" '$9 == a {print;}'; sleep 
5; done

Setup isolcpus to separate off 4-7 and 32-35, so each NUMA node has a
set of isolated CPUs.

s-tui is a great frontend for stress, and it starts stress processes.
All stress processes should initially be on non-isolated CPUs, confirm
this with htop, that 4-7 and 32-25 are at 0% while every other cpu is at
100%.

After 3 minutes, but sometimes it takes up to 10 minutes, a stress
process, or the s-tui process will be incorrectly placed onto an
isolated cpu, causing it to increase in usage in htop. The while script
checking ps with cpu affinities will also likely be printing the
incorrectly placed process.

A test kernel is available in the following ppa:

https://launchpad.net/~mruffell/+archive/ubuntu/sf391137-test

If you install it, the processes will not be placed onto the isolated
cpus.

[Where problems could occur]

The patch changes how cgroups determines when cpuset_attach() should be
called. cpuset_attach() is currently called very frequently in the 5.15
Jammy kernel, but most operations should be NOP due to no changes
occurring in cpusets or memory in the cgroup the process is attached to.
We are changing it to instead skip calling cpuset_attach() if there are
no changes, which should offer a small performance increase, as well as
fixing this isolcpus bug.

If a regression were to occur, it would affect cgroups V2 only, and it
could cause resource limits to be applied incorrectly in the worst case.

** Affects: linux (Ubuntu)
 Importance: Undecided
 Status: Fix Released

** Affects: linux (Ubuntu Jammy)
 Importance: Medium
 Assignee: Matthew Ruffell (mruffell)
 Status: In Progress


** Tags: jammy sts

** Also affects: linux (Ubuntu Jammy)
   Importance: Undecided
   Status: New

** Changed in: linux (Ubuntu)
   Status: New => Fix Released

** Changed in: linux (Ubuntu Jammy)
   Status: New => In Progress

** Changed in: linux (Ubuntu Jammy)
   Importance: Undecided => Medium

** Changed in: linux (Ubuntu Jammy)
 Assignee: (unassigned) => Matthew Ruffell (mruffell)

** Description changed:

- BugLink: https://bugs.launchpad.net/bugs/
+ BugLink: https://bugs.launchpad.net/bugs/2076957
  
  [Impact]
  
  In latency sensitive environments, it is very common to use isolcpus to
  reserve a set of cpus that no other processes are to be placed on, and
  run just dpdk in poll mode.
  
  There is a bug in the jammy kernel, where if cgroups V2 are enabled,
  after several minutes the kernel will place other processes onto these
  reserved isolcpus at random. This disturbs dpdk and introduces latency.
  
  The issue does not occur with cgroups V1, so a workar

[Bug 1861609] Re: Xorg crashed with assertion failure (usually in a VM) at [privates.h:121/122: dixGetPrivateAddr: Assertion `key->initialized' failed]

Hi Doug,

You have done some awesome work! Thank you very much for debugging and
opening a merge request upstream.

I can reproduce the issue, and yes, your patch with the help of previous
authors does fix the issue.

Hopefully we can try and get the attention of the maintainers, and see
if they are interested in pulling the patch in.

In the meantime, I built some test packages to share if anyone wants to
try the patch out.

Please note this package is NOT SUPPORTED by Canonical, and is for TESTING
PURPOSES ONLY. ONLY Install in a dedicated test environment.

Instructions to Install (On a focal, jammy, noble or oracular system):
1) sudo add-apt-repository ppa:mruffell/sf392117-test
2) sudo apt update
3) sudo apt install xserver-common xserver-xephyr xserver-xorg-core 
xserver-xorg-legacy
4) sudo apt-cache policy xserver-common | grep Installed
Oracular:
2:21.1.12-1ubuntu1+sf392117v20240813b1
Noble:
2:21.1.12-1ubuntu1+sf392117v20240813b0
Jammy:
2:21.1.4-2ubuntu1.7~22.04.11+sf392117v20240813b1 
Focal:
2:1.20.13-1ubuntu1~20.04.17+sf392117v20240813b1 

You probably want to run it in a VM. Probably best to reboot after installing
before trying to reproduce.

Thanks,
Matthew

-- 
You received this bug notification because you are a member of Ubuntu
Bugs, which is subscribed to Ubuntu.
https://bugs.launchpad.net/bugs/1861609

Title:
  Xorg crashed with assertion failure (usually in a VM) at
  [privates.h:121/122: dixGetPrivateAddr: Assertion `key->initialized'
  failed]

To manage notifications about this bug go to:
https://bugs.launchpad.net/xorg-server/+bug/1861609/+subscriptions


-- 
ubuntu-bugs mailing list
ubuntu-bugs@lists.ubuntu.com
https://lists.ubuntu.com/mailman/listinfo/ubuntu-bugs

[Bug 1861609] Re: Xorg crashed with assertion failure (usually in a VM) at [privates.h:121/122: dixGetPrivateAddr: Assertion `key->initialized' failed]

** Also affects: xorg-server (Ubuntu Focal)
   Importance: Undecided
   Status: New

** Also affects: xorg-server (Ubuntu Noble)
   Importance: Undecided
   Status: New

** Also affects: xorg-server (Ubuntu Jammy)
   Importance: Undecided
   Status: New

** Also affects: xorg-server (Ubuntu Oracular)
   Importance: High
   Status: Confirmed

** Tags added: sts

-- 
You received this bug notification because you are a member of Ubuntu
Bugs, which is subscribed to Ubuntu.
https://bugs.launchpad.net/bugs/1861609

Title:
  Xorg crashed with assertion failure (usually in a VM) at
  [privates.h:121/122: dixGetPrivateAddr: Assertion `key->initialized'
  failed]

To manage notifications about this bug go to:
https://bugs.launchpad.net/xorg-server/+bug/1861609/+subscriptions


-- 
ubuntu-bugs mailing list
ubuntu-bugs@lists.ubuntu.com
https://lists.ubuntu.com/mailman/listinfo/ubuntu-bugs

[Bug 2036467] Re: Resizing cloud-images occasionally fails due to superblock checksum mismatch in resize2fs

Performing verification for Jammy.

So, I had forgotten all about these instances, so let's check them now.

The instance with -updates:

It failed with:
+ resize2fs /dev/nvme1n1p1
resize2fs 1.46.5 (30-Dec-2021)
resize2fs: Superblock checksum does not match superblock while trying to open 
/dev/nvme1n1p1
Couldn't find valid filesystem superblock.

the timestamp is Thu Aug  1 06:59:14 UTC 2024

I started it on... Thu Aug 1 06:02:48 UTC 2024

58 minutes! I was expecting a couple of days for Jammy -updates to be honest.
I really should have checked earlier.

So we can reproduce the issue.

I then logged into the -proposed instance, with resize2fs
1.46.5-2ubuntu1.2:

It is still running, as of Mon Aug 12 10:54:06 UTC 2024.

This is fantastic. It survived 11 days and 5 hours in the high EBS traffic
us-west-2.

The package in -proposed fixes the issue. Happy to mark verified for
Jammy.

** Tags removed: verification-needed verification-needed-jammy
** Tags added: verification-done-jammy

-- 
You received this bug notification because you are a member of Ubuntu
Bugs, which is subscribed to Ubuntu.
https://bugs.launchpad.net/bugs/2036467

Title:
  Resizing cloud-images occasionally fails due to superblock checksum
  mismatch in resize2fs

To manage notifications about this bug go to:
https://bugs.launchpad.net/cloud-images/+bug/2036467/+subscriptions


-- 
ubuntu-bugs mailing list
ubuntu-bugs@lists.ubuntu.com
https://lists.ubuntu.com/mailman/listinfo/ubuntu-bugs

[Bug 2036467] Re: Resizing cloud-images occasionally fails due to superblock checksum mismatch in resize2fs

Performing verification for Noble.

So, I had forgotten all about these instances, so let's check them now.

The instance with -updates:

It failed with:
+ resize2fs /dev/nvme1n1p1
resize2fs 1.47.0 (5-Feb-2023)
resize2fs: Superblock checksum does not match superblock while trying to open 
/dev/nvme1n1p1
Couldn't find valid filesystem superblock.

the timestamp is Wed Aug  7 06:42:15 UTC 2024

I started it on... Thu Aug 1 05:46:34 UTC 2024

Okay, this is better than Focal, we lasted 6 days 1 hour.

So we can reproduce the issue.

I then logged into the -proposed instance, with resize2fs
1.47.0-2.4~exp1ubuntu4.1:

It is still running, as of Mon Aug 12 10:49:00 UTC 2024.

This is fantastic. It survived 11 days and 5 hours in the high EBS traffic
us-west-2.

I have terminated the instances now.

The package in -proposed fixes the issue. Happy to mark verified for
Noble.

** Tags removed: verification-needed-noble
** Tags added: verification-done-noble

-- 
You received this bug notification because you are a member of Ubuntu
Bugs, which is subscribed to Ubuntu.
https://bugs.launchpad.net/bugs/2036467

Title:
  Resizing cloud-images occasionally fails due to superblock checksum
  mismatch in resize2fs

To manage notifications about this bug go to:
https://bugs.launchpad.net/cloud-images/+bug/2036467/+subscriptions


-- 
ubuntu-bugs mailing list
ubuntu-bugs@lists.ubuntu.com
https://lists.ubuntu.com/mailman/listinfo/ubuntu-bugs

[Bug 2036467] Re: Resizing cloud-images occasionally fails due to superblock checksum mismatch in resize2fs

Performing verification for Focal.

So, I had forgotten all about these instances, so let's check them now.

The instance with -updates:

It failed with:
+ resize2fs /dev/nvme1n1p1
resize2fs 1.45.5 (07-Jan-2020)
resize2fs: Superblock checksum does not match superblock while trying to open 
/dev/nvme1n1p1
Couldn't find valid filesystem superblock.

the timestamp is Thu Aug  1 05:57:54 UTC 2024

I started it on... Thu Aug 1 05:46:34 UTC 2024

What! It only lasted 11 minutes! I should have checked on it earlier...

So we can reproduce the issue.

I then logged into the -proposed instance, with resize2fs
1.45.5-2ubuntu1.2:

It is still running, as of Mon Aug 12 10:41:35 UTC 2024.

This is fantastic. It survived 11 days and 5 hours in the high EBS traffic
us-west-2. 

I have terminated these instances now.

The package in -proposed fixes the issue. Happy to mark verified for
Focal.

** Tags removed: verification-needed-focal
** Tags added: verification-done-focal

-- 
You received this bug notification because you are a member of Ubuntu
Bugs, which is subscribed to Ubuntu.
https://bugs.launchpad.net/bugs/2036467

Title:
  Resizing cloud-images occasionally fails due to superblock checksum
  mismatch in resize2fs

To manage notifications about this bug go to:
https://bugs.launchpad.net/cloud-images/+bug/2036467/+subscriptions


-- 
ubuntu-bugs mailing list
ubuntu-bugs@lists.ubuntu.com
https://lists.ubuntu.com/mailman/listinfo/ubuntu-bugs

[Bug 2072755] Re: i915: Fixup regressions introduced with enabling single CCS engine

2024-08-08 Thread Matthew Ruffell

Thanks for testing TheDreadPirate. I marked the bug as verified.

** Tags removed: verification-needed-noble-linux
** Tags added: verification-done-noble-linux

-- 
You received this bug notification because you are a member of Ubuntu
Bugs, which is subscribed to Ubuntu.
https://bugs.launchpad.net/bugs/2072755

Title:
  i915: Fixup regressions introduced with enabling single CCS engine

To manage notifications about this bug go to:
https://bugs.launchpad.net/ubuntu/+source/linux/+bug/2072755/+subscriptions


-- 
ubuntu-bugs mailing list
ubuntu-bugs@lists.ubuntu.com
https://lists.ubuntu.com/mailman/listinfo/ubuntu-bugs

[Bug 2075110] Re: md: nvme over tcp with a striped underlying md raid device leads to data corruption

Performing verification for Noble.

I started a n2-standard-2 instance on Google cloud, running Noble.

I installed 6.8.0-39-generic from -updates, rebooted, and followed the 
instructions in the
testcase.

$ sudo ./check md/001
md/001 (Raid with bitmap on tcp nvmet with opt-io-size over bitmap size)

Having a look at dmesg:

unknown: run blktests md/001 at 2024-08-08 04:26:39
root[1982]: run blktests md/001
kernel: brd: module loaded
(udev-worker)[1987]: dm-0: Process '/usr/bin/unshare -m /usr/bin/snap 
auto-import --mount=/dev/dm-0' failed with exit code 1.
kernel: Key type psk registered
kernel: nvmet: adding nsid 1 to subsystem blktests-subsystem-1
kernel: nvmet_tcp: enabling port 0 (127.0.0.1:4420)
kernel: nvmet: creating nvm controller 1 for subsystem blktests-subsystem-1 for 
NQN nqn.2014-08.org.nvmexpress:uuid:0f01fb42-9f7f-4856-b0b3-51e60b8de349.
kernel: nvme nvme1: creating 2 I/O queues.
kernel: nvme nvme1: mapped 2/0/0 default/read/poll queues.
kernel: nvme nvme1: new ctrl: NQN "blktests-subsystem-1", addr 127.0.0.1:4420, 
hostnqn: nqn.2014-08.org.nvmexpress:uuid:0f01fb42-9f7f-4856-b0b3-51e60b8de349
(udev-worker)[2018]: nvme1n1: Process '/usr/bin/unshare -m /usr/bin/snap 
auto-import --mount=/dev/nvme1n1' failed with exit code 1.
(udev-worker)[2018]: md127: Process '/usr/bin/unshare -m /usr/bin/snap 
auto-import --mount=/dev/md127' failed with exit code 1.
kernel: md/raid1:md127: active with 1 out of 2 mirrors
kernel: [ cut here ]
kernel: WARNING: CPU: 0 PID: 50 at net/core/skbuff.c:6995 
skb_splice_from_iter+0x139/0x370
kernel: Modules linked in: nvme_tcp nvmet_tcp nvmet nvme_keyring brd raid1 
cfg80211 8021q garp mrp stp llc binfmt_misc nls_iso8859_1 intel_rapl_msr 
intel_rapl_common intel_uncore_frequency_common isst_if_common nfit 
crct10dif_pclmul crc32_pclmul polyval_clmulni polyval_generic 
ghash_clmulni_intel sha256_ssse3 sha1_ssse3 aesni_intel crypto_simd cryptd rapl 
pvpanic_mmio pvpanic nvme psmouse i2c_piix4 input_leds mac_hid serio_raw 
dm_multipath nvme_fabrics nvme_core nvme_auth efi_pstore nfnetlink dmi_sysfs 
virtio_rng ip_tables x_tables autofs4
kernel: CPU: 0 PID: 50 Comm: kworker/0:1H Not tainted 6.8.0-39-generic 
#39-Ubuntu
kernel: Hardware name: Google Google Compute Engine/Google Compute Engine, BIOS 
Google 06/27/2024
kernel: Workqueue: nvme_tcp_wq nvme_tcp_io_work [nvme_tcp]
kernel: RIP: 0010:skb_splice_from_iter+0x139/0x370
kernel: Code: 39 e1 48 8b 53 08 49 0f 47 cc 49 89 cd f6 c2 01 0f 85 c0 01 00 00 
66 90 48 89 da 48 8b 12 80 e6 08 0f 84 8e 00 00 00 4d 89 fe <0f> 0b 49 c7 c0 fb 
ff ff ff 48 8b 85 68 ff ff ff 41 01 46 70 41 01
kernel: RSP: 0018:bd92001b3a30 EFLAGS: 00010246
kernel: RAX:  RBX: f5f1c48d9b40 RCX: 1000
kernel: RDX:  RSI:  RDI: 
kernel: RBP: bd92001b3ad8 R08:  R09: 
kernel: R10:  R11:  R12: 20e8
kernel: R13: 1000 R14: 96834b496400 R15: 96834b496400
kernel: FS:  () GS:968477c0() 
knlGS:
kernel: CS:  0010 DS:  ES:  CR0: 80050033
kernel: CR2: 7507bcfe5f84 CR3: 00010b49c002 CR4: 003706f0
kernel: DR0:  DR1:  DR2: 
kernel: DR3:  DR6: fffe0ff0 DR7: 0400
kernel: Call Trace:
kernel:  
kernel:  ? show_regs+0x6d/0x80
kernel:  ? __warn+0x89/0x160
kernel:  ? skb_splice_from_iter+0x139/0x370
kernel:  ? report_bug+0x17e/0x1b0
kernel:  ? handle_bug+0x51/0xa0
kernel:  ? exc_invalid_op+0x18/0x80
kernel:  ? asm_exc_invalid_op+0x1b/0x20
kernel:  ? skb_splice_from_iter+0x139/0x370
kernel:  tcp_sendmsg_locked+0x352/0xd70
kernel:  ? tcp_push+0x159/0x190
kernel:  ? tcp_sendmsg_locked+0x9c4/0xd70
kernel:  tcp_sendmsg+0x2c/0x50
kernel:  inet_sendmsg+0x42/0x80
kernel:  sock_sendmsg+0x118/0x150
kernel:  nvme_tcp_try_send_data+0x18b/0x4c0 [nvme_tcp]
kernel:  nvme_tcp_try_send+0x23c/0x300 [nvme_tcp]
kernel:  nvme_tcp_io_work+0x40/0xe0 [nvme_tcp]
kernel:  process_one_work+0x16c/0x350
kernel:  worker_thread+0x306/0x440
kernel:  ? _raw_spin_unlock_irqrestore+0x11/0x60
kernel:  ? __pfx_worker_thread+0x10/0x10
kernel:  kthread+0xef/0x120
kernel:  ? __pfx_kthread+0x10/0x10
kernel:  ret_from_fork+0x44/0x70
kernel:  ? __pfx_kthread+0x10/0x10
kernel:  ret_from_fork_asm+0x1b/0x30
kernel:  
kernel: ---[ end trace  ]---
kernel: nvme nvme1: failed to send request -5
kernel: nvme nvme1: I/O tag 111 (106f) type 4 opcode 0x0 (I/O Cmd) QID 1 timeout
kernel: nvme nvme1: starting error recovery
kernel: block nvme1n1: no usable path - requeuing I/O
kernel: nvme nvme1: Reconnecting in 10 seconds...

blktests md/001 hangs the system, in this particular scenario.

I then restarted the instance, enabled -proposed2, and installed
6.8.0-41-generic:

6.8.0-41-generic #41-Ubuntu SMP PREEMPT_DYNAMIC Fri Aug  2 20:41:06 UTC
2024

I c

[Bug 2069534] Re: Linux 6.8 fails to boot on ARM64 if any param is more than 146 chars

Performing verification for Noble.

I again started two T2A instances on Google Cloud, both running Noble.

One instance has:
6.8.0-39-generic #39-Ubuntu SMP PREEMPT_DYNAMIC Sat Jul  6 02:50:39 UTC 2024
The other, 6.8.0-41-generic from -proposed2:
6.8.0-41-generic #41-Ubuntu SMP PREEMPT_DYNAMIC Fri Aug  2 23:26:06 UTC 2024

I edited /etc/default/grub.d/50-cloudimg-settings.cfg and set:

GRUB_CMDLINE_LINUX_DEFAULT="console=ttyS0,115200"

to

GRUB_CMDLINE_LINUX_DEFAULT="console=ttyS0,115200
testparam=f081c381e7b54edcba27e5f790d47911a4cc3e726d8d256878d3df9175c020e0f081c381e7b54edcba27e5f790d47911a4cc3e726d8d256878d3df9175c020e0f081c381e7b5732f126a62b4232"

ran:

$ sudo update-grub

and rebooted.

Again, I never saw the 6.8.0-39-generic again.

The 6.8.0-41-generic instance came up just fine:

$ cat /proc/cmdline 
BOOT_IMAGE=/vmlinuz-6.8.0-41-generic 
root=PARTUUID=e1ce6327-4835-4b2e-b73e-e7d6231d4869 ro console=ttyS0,115200 
testparam=f081c381e7b54edcba27e5f790d47911a4cc3e726d8d256878d3df9175c020e0f081c381e7b54edcba27e5f790d47911a4cc3e726d8d256878d3df9175c020e0f081c381e7b5732f126a62b4232

The 6.8.0-41-generic in -proposed2 fixes the issue. Happy to mark
verified for Noble.

** Tags removed: verification-needed-noble-linux
** Tags added: verification-done-noble-linux

-- 
You received this bug notification because you are a member of Ubuntu
Bugs, which is subscribed to Ubuntu.
https://bugs.launchpad.net/bugs/2069534

Title:
  Linux 6.8 fails to boot on ARM64 if any param is more than 146 chars

To manage notifications about this bug go to:
https://bugs.launchpad.net/ubuntu/+source/linux/+bug/2069534/+subscriptions


-- 
ubuntu-bugs mailing list
ubuntu-bugs@lists.ubuntu.com
https://lists.ubuntu.com/mailman/listinfo/ubuntu-bugs

[Bug 2076201] Re: Virtualbox fails when starting a VM with kernel 5.15.0-116/117

*** This bug is a duplicate of bug 2073267 ***
https://bugs.launchpad.net/bugs/2073267

** This bug has been marked a duplicate of bug 2073267
   Virtualbox Guru meditation on VM start caused by kernel commit in v6.9-rc4

-- 
You received this bug notification because you are a member of Ubuntu
Bugs, which is subscribed to Ubuntu.
https://bugs.launchpad.net/bugs/2076201

Title:
  Virtualbox fails when starting a VM with kernel 5.15.0-116/117

To manage notifications about this bug go to:
https://bugs.launchpad.net/ubuntu/+source/linux/+bug/2076201/+subscriptions


-- 
ubuntu-bugs mailing list
ubuntu-bugs@lists.ubuntu.com
https://lists.ubuntu.com/mailman/listinfo/ubuntu-bugs

[Bug 2067862] Re: Removing legacy virtio-pci devices causes kernel panic

Hi Dong,

There is nothing more to do. Don't worry about all these derivative
kernels spamming the comments, we just needed to verify the main
-generic kernel only. There will be more bot spam in the future, you can
ignore it.

Thanks,
Matthew

-- 
You received this bug notification because you are a member of Ubuntu
Bugs, which is subscribed to the bug report.
https://bugs.launchpad.net/bugs/2067862

Title:
  Removing legacy virtio-pci devices causes kernel panic

To manage notifications about this bug go to:
https://bugs.launchpad.net/ubuntu/+source/linux/+bug/2067862/+subscriptions


-- 
ubuntu-bugs mailing list
ubuntu-bugs@lists.ubuntu.com
https://lists.ubuntu.com/mailman/listinfo/ubuntu-bugs

[Bug 2073267] Re: Virtualbox Guru meditation on VM start caused by kernel commit in v6.9-rc4

Hi Arrigo,

Kernel SRU cycles are a little tricky... the Kernel Team make 150 kernels twice
a month, so not everything goes in the distro -proposed pocket.

This one is a respin, and hasn't made its way to the main -proposed pocket yet,
and because its a part of the security SRU cycle, it gets placed in the Kernel
Teams -proposed2 pocket:

https://launchpad.net/~canonical-kernel-team/+archive/ubuntu/proposed2

The Kernel Team also have a -proposed pocket, which is just like the distro
-proposed, but only has the primary kernel SRU cycle packages in it:

https://launchpad.net/~canonical-kernel-team/+archive/ubuntu/proposed

anyway, -119 is in -proposed2 if you want to try it.

The virtualbox package in -proposed is the same as the one in -updates, and
fixes a DKMS build issue with the 6.8 HWE kernel.

Hope that clears some things up.

Matthew

-- 
You received this bug notification because you are a member of Ubuntu
Bugs, which is subscribed to Ubuntu.
https://bugs.launchpad.net/bugs/2073267

Title:
  Virtualbox Guru meditation on VM start caused by kernel commit in
  v6.9-rc4

To manage notifications about this bug go to:
https://bugs.launchpad.net/ubuntu/+source/linux/+bug/2073267/+subscriptions


-- 
ubuntu-bugs mailing list
ubuntu-bugs@lists.ubuntu.com
https://lists.ubuntu.com/mailman/listinfo/ubuntu-bugs

[Bug 2073267] Re: Virtualbox Guru meditation on VM start caused by kernel commit in v6.9-rc4

2024-08-06 Thread Matthew Ruffell

Performing verification for Jammy.

I deployed a fresh baremetal server running Jammy in the Server Lab, installed
ubuntu-desktop and rebooted.

The kernel is 5.15.0-117-generic from updates:
5.15.0-117-generic #127-Ubuntu SMP Fri Jul 5 20:13:28 UTC 2024

$ sudo apt-cache policy virtualbox
virtualbox:
  Installed: 6.1.50-dfsg-1~ubuntu1.22.04.1
  
I downloaded a Ubuntu server iso from cdimage, and made a new virtualbox VM.

On starting, I get "Guru Meditation" and in the logs I see

00:00:02.191995 emR3Debug: rc=VERR_VMM_SET_JMP_ABORTED_RESUME

I then enable proposed2 and installed 5.15.0-119-generic:

5.15.0-119-generic #129-Ubuntu SMP Fri Aug 2 19:25:20 UTC 2024

The virtualbox VM started up normally. Happy to mark verified for jammy.

** Tags removed: verification-needed-jammy-linux
** Tags added: verification-done-jammy-linux

-- 
You received this bug notification because you are a member of Ubuntu
Bugs, which is subscribed to Ubuntu.
https://bugs.launchpad.net/bugs/2073267

Title:
  Virtualbox Guru meditation on VM start caused by kernel commit in
  v6.9-rc4

To manage notifications about this bug go to:
https://bugs.launchpad.net/ubuntu/+source/linux/+bug/2073267/+subscriptions


-- 
ubuntu-bugs mailing list
ubuntu-bugs@lists.ubuntu.com
https://lists.ubuntu.com/mailman/listinfo/ubuntu-bugs

[Bug 2076048] Re: My system freezes after waking from suspend

2024-08-06 Thread Matthew Ruffell

*** This bug is a duplicate of bug 2064595 ***
https://bugs.launchpad.net/bugs/2064595

Great to hear it! Everyone else, hold tight, 6.8.0-40-generic will be
released soon.

-- 
You received this bug notification because you are a member of Ubuntu
Bugs, which is subscribed to Ubuntu.
https://bugs.launchpad.net/bugs/2076048

Title:
  My system freezes after waking from suspend

To manage notifications about this bug go to:
https://bugs.launchpad.net/ubuntu/+source/linux/+bug/2076048/+subscriptions


-- 
ubuntu-bugs mailing list
ubuntu-bugs@lists.ubuntu.com
https://lists.ubuntu.com/mailman/listinfo/ubuntu-bugs

[Bug 2076048] Re: My system freezes after waking from suspend

2024-08-06 Thread Matthew Ruffell

*** This bug is a duplicate of bug 2064595 ***
https://bugs.launchpad.net/bugs/2064595

I think this is going to be fixed in 6.8.0-40-generic, currently in
-proposed. You could try install it now and see if it fixes your issue.
Let me know if it doesn't.

** This bug has been marked a duplicate of bug 2064595
   AMD Rembrandt & AMD Rembrandt-R: Suspend hangs system

-- 
You received this bug notification because you are a member of Ubuntu
Bugs, which is subscribed to Ubuntu.
https://bugs.launchpad.net/bugs/2076048

Title:
  My system freezes after waking from suspend

To manage notifications about this bug go to:
https://bugs.launchpad.net/ubuntu/+source/linux/+bug/2076048/+subscriptions


-- 
ubuntu-bugs mailing list
ubuntu-bugs@lists.ubuntu.com
https://lists.ubuntu.com/mailman/listinfo/ubuntu-bugs

[Bug 1972914] Re: frequent 15-sec guest freeze with ubuntu 22.04 host and guest

Hi everyone,

$ cd Work/kernel/ubuntu-jammy/
~/Work/kernel/ubuntu-jammy$ git log --grep 'Revert "drm/qxl: simplify 
qxl_fence_wait"'
commit 1b146e3dc802253fd9a6e29e2d3b06d003fe9182
Author: Alex Constantino 
Date:   Thu Apr 4 19:14:48 2024 +0100

Revert "drm/qxl: simplify qxl_fence_wait"

...
~/Work/kernel/ubuntu-jammy$ git describe --contains 
1b146e3dc802253fd9a6e29e2d3b06d003fe9182
Ubuntu-5.15.0-115.125~199
~/Work/kernel/ubuntu-jammy$ cd ..
~/Work/kernel$ cd ubuntu-noble/
~/Work/kernel/ubuntu-noble$ git log --grep 'Revert "drm/qxl: simplify 
qxl_fence_wait"' origin/master-next
commit ee451375fd8b767eb91721fa389b022f1582cb0f
Author: Alex Constantino 
Date:   Thu Apr 4 19:14:48 2024 +0100

Revert "drm/qxl: simplify qxl_fence_wait"
...
~/Work/kernel/ubuntu-noble$ git describe --contains 
ee451375fd8b767eb91721fa389b022f1582cb0f
Ubuntu-6.8.0-38.38~331

This has been fixed in 5.15.0-115-generic or later, and 6.8.0-38-generic
or later.

Let me know if you need any more help.

Thanks,
Matthew

** Also affects: linux (Ubuntu)
   Importance: Undecided
   Status: New

** Changed in: xserver-xorg-video-qxl (Ubuntu)
   Status: Confirmed => Invalid

** Also affects: linux (Ubuntu Jammy)
   Importance: Undecided
   Status: New

** Also affects: xserver-xorg-video-qxl (Ubuntu Jammy)
   Importance: Undecided
   Status: New

** Also affects: linux (Ubuntu Noble)
   Importance: Undecided
   Status: New

** Also affects: xserver-xorg-video-qxl (Ubuntu Noble)
   Importance: Undecided
   Status: New

** No longer affects: xserver-xorg-video-qxl (Ubuntu Jammy)

** No longer affects: xserver-xorg-video-qxl (Ubuntu Noble)

** Changed in: linux (Ubuntu)
   Status: New => Fix Released

** Changed in: linux (Ubuntu Jammy)
   Status: New => Fix Released

** Changed in: linux (Ubuntu Noble)
   Status: New => Fix Released

-- 
You received this bug notification because you are a member of Ubuntu
Bugs, which is subscribed to Ubuntu.
https://bugs.launchpad.net/bugs/1972914

Title:
  frequent 15-sec guest freeze with ubuntu 22.04 host and guest

To manage notifications about this bug go to:
https://bugs.launchpad.net/ubuntu/+source/linux/+bug/1972914/+subscriptions


-- 
ubuntu-bugs mailing list
ubuntu-bugs@lists.ubuntu.com
https://lists.ubuntu.com/mailman/listinfo/ubuntu-bugs

[Bug 2070020] Re: Lenovo dock no longer working after upgrade from 6.5.0-35 to 6.5.0-41

Hi everyone,

The Jammy HWE kernel will be rolling to the 6.8 kernel from Noble in a
couple days / or a week or so. The 6.5 mantic kernel is closed to any
new commits now, so best to just move to the 6.8 kernel now where this
is already fixed.

Thanks,
Matthew

-- 
You received this bug notification because you are a member of Ubuntu
Bugs, which is subscribed to Ubuntu.
https://bugs.launchpad.net/bugs/2070020

Title:
  Lenovo dock no longer working after upgrade from 6.5.0-35 to 6.5.0-41

To manage notifications about this bug go to:
https://bugs.launchpad.net/ubuntu/+source/linux/+bug/2070020/+subscriptions


-- 
ubuntu-bugs mailing list
ubuntu-bugs@lists.ubuntu.com
https://lists.ubuntu.com/mailman/listinfo/ubuntu-bugs

[Bug 2076003] Re: Shows Unknow display

*** This bug is a duplicate of bug 2076004 ***
https://bugs.launchpad.net/bugs/2076004

** This bug has been marked a duplicate of bug 2076004
   Shows Unknown display with 6.8.0-39

-- 
You received this bug notification because you are a member of Ubuntu
Bugs, which is subscribed to Ubuntu.
https://bugs.launchpad.net/bugs/2076003

Title:
  Shows Unknow display

To manage notifications about this bug go to:
https://bugs.launchpad.net/ubuntu/+source/linux/+bug/2076003/+subscriptions


-- 
ubuntu-bugs mailing list
ubuntu-bugs@lists.ubuntu.com
https://lists.ubuntu.com/mailman/listinfo/ubuntu-bugs

[Bug 2069534] Re: Linux 6.8 fails to boot on ARM64 if any param is more than 146 chars

Hi Chris,

Yes, jammy-hwe-6.8 got fixed because Stefan Bader had to respin the kernel
for another regression anyway, so he opportunistically pulled it in.

For Noble, I think it will be part of the s2024.07.08 SRU cycle, as per
https://kernel.ubuntu.com/, as Manuel Diewald mentioned when I spoke to him.

Thanks,
Matthew

-- 
You received this bug notification because you are a member of Ubuntu
Bugs, which is subscribed to Ubuntu.
https://bugs.launchpad.net/bugs/2069534

Title:
  Linux 6.8 fails to boot on ARM64 if any param is more than 146 chars

To manage notifications about this bug go to:
https://bugs.launchpad.net/ubuntu/+source/linux/+bug/2069534/+subscriptions


-- 
ubuntu-bugs mailing list
ubuntu-bugs@lists.ubuntu.com
https://lists.ubuntu.com/mailman/listinfo/ubuntu-bugs

[Bug 2069534] Re: Linux 6.8 fails to boot on ARM64 if any param is more than 146 chars

2024-08-01 Thread Matthew Ruffell

Performing verification for jammy-hwe-6.8

I started two T2A instances on google cloud, which are arm64, with
jammy.

One instance has:
6.8.0-39-generic #39~22.04.1-Ubuntu SMP PREEMPT_DYNAMIC Wed Jul 10 16:59:11 UTC 
2
The other, 6.8.0-40-generic from -proposed:
6.8.0-40-generic #40~22.04.3-Ubuntu SMP PREEMPT_DYNAMIC Tue Jul 30 17:53:10 UTC 
2

I edited /etc/default/grub.d/50-cloudimg-settings.cfg and set:

GRUB_CMDLINE_LINUX_DEFAULT="console=ttyS0,115200"

to

GRUB_CMDLINE_LINUX_DEFAULT="console=ttyS0,115200
testparam=f081c381e7b54edcba27e5f790d47911a4cc3e726d8d256878d3df9175c020e0f081c381e7b54edcba27e5f790d47911a4cc3e726d8d256878d3df9175c020e0f081c381e7b5732f126a62b4232"

ran:

$ sudo update-grub

and rebooted.

Unfortunately, I never saw the 6.8.0-39-generic again.

The 6.8.0-40-generic instance came up just fine:

$ cat /proc/cmdline 
BOOT_IMAGE=/boot/vmlinuz-6.8.0-40-generic 
root=PARTUUID=17337627-dfbd-4ce7-9f99-4dd1da2542eb ro console=ttyS0,115200 
testparam=f081c381e7b54edcba27e5f790d47911a4cc3e726d8d256878d3df9175c020e0f081c381e7b54edcba27e5f790d47911a4cc3e726d8d256878d3df9175c020e0f081c381e7b5732f126a62b4232

The 6.8.0-40-generic in -proposed fixes the issue. Happy to mark
verified for jammy-hwe-6.8.

** Tags removed: verification-needed-jammy-linux-hwe-6.8
** Tags added: verification-done-jammy-linux-hwe-6.8

-- 
You received this bug notification because you are a member of Ubuntu
Bugs, which is subscribed to Ubuntu.
https://bugs.launchpad.net/bugs/2069534

Title:
  Linux 6.8 fails to boot on ARM64 if any param is more than 146 chars

To manage notifications about this bug go to:
https://bugs.launchpad.net/ubuntu/+source/linux/+bug/2069534/+subscriptions


-- 
ubuntu-bugs mailing list
ubuntu-bugs@lists.ubuntu.com
https://lists.ubuntu.com/mailman/listinfo/ubuntu-bugs

[Bug 2036467] Re: Resizing cloud-images occasionally fails due to superblock checksum mismatch in resize2fs

Beginning verification for noble

I started two c5.large instances on us-west-2 on AWS, the same parameters that 
we used in previous tests. Each has a 60gb GP3 volume attached to it.
Each instance is running the GA kernel, 6.8.0-1012-aws.

One is -updates, the other is e2fsprogs from -proposed:

-updates:
$ apt-cache policy e2fsprogs | grep Installed
  Installed: 1.47.0-2.4~exp1ubuntu4
-proposed:
$ apt-cache policy e2fsprogs | grep Installed
  Installed: 1.47.0-2.4~exp1ubuntu4.1
  
Each is running the same script from the testcase.

I will leave these instances running for the next 7-14 days. We will
consider this bug verified if the -updates instance is broken, and the
-proposed instance still functioning correctly at the end of this time.

The timestamp of starting both tests is: Thu Aug  1 06:10:40 UTC 2024

-- 
You received this bug notification because you are a member of Ubuntu
Bugs, which is subscribed to Ubuntu.
https://bugs.launchpad.net/bugs/2036467

Title:
  Resizing cloud-images occasionally fails due to superblock checksum
  mismatch in resize2fs

To manage notifications about this bug go to:
https://bugs.launchpad.net/cloud-images/+bug/2036467/+subscriptions


-- 
ubuntu-bugs mailing list
ubuntu-bugs@lists.ubuntu.com
https://lists.ubuntu.com/mailman/listinfo/ubuntu-bugs

[Bug 2036467] Re: Resizing cloud-images occasionally fails due to superblock checksum mismatch in resize2fs

Beginning verification for jammy

I started two c5.large instances on us-west-2 on AWS, the same parameters that 
we used in previous tests. Each has a 60gb GP3 volume attached to it.
I downgraded the HWE kernels down to GA kernels, and each is running 
5.15.0-1066-aws.

One is -updates, the other is e2fsprogs from -proposed:

-updates:
$ apt-cache policy e2fsprogs | grep Installed
  Installed: 1.46.5-2ubuntu1.1
-proposed:
$ apt-cache policy e2fsprogs | grep Installed
  Installed: 1.46.5-2ubuntu1.2
  
Each is running the same script from the testcase.

I will leave these instances running for the next 7-14 days. We will
consider this bug verified if the -updates instance is broken, and the
-proposed instance still functioning correctly at the end of this time.

The timestamp of starting both tests is: Thu Aug  1 06:02:48 UTC 2024

-- 
You received this bug notification because you are a member of Ubuntu
Bugs, which is subscribed to Ubuntu.
https://bugs.launchpad.net/bugs/2036467

Title:
  Resizing cloud-images occasionally fails due to superblock checksum
  mismatch in resize2fs

To manage notifications about this bug go to:
https://bugs.launchpad.net/cloud-images/+bug/2036467/+subscriptions


-- 
ubuntu-bugs mailing list
ubuntu-bugs@lists.ubuntu.com
https://lists.ubuntu.com/mailman/listinfo/ubuntu-bugs

[Bug 2036467] Re: Resizing cloud-images occasionally fails due to superblock checksum mismatch in resize2fs

Beginning verification for focal

I started two c5.large instances on us-west-2 on AWS, the same parameters that 
we used in previous tests. Each has a 60gb GP3 volume attached to it.
I downgraded the HWE kernels down to GA kernels, and each is running 
5.4.0-1129-aws.

One is -updates, the other is e2fsprogs from -proposed:

-updates:
$ apt-cache policy e2fsprogs | grep Installed
  Installed: 1.45.5-2ubuntu1.1
-proposed:
$ apt-cache policy e2fsprogs | grep Installed
  Installed: 1.45.5-2ubuntu1.2
  
Each is running the same script from the testcase.

I will leave these instances running for the next 7-14 days. We will
consider this bug verified if the -updates instance is broken, and the
-proposed instance still functioning correctly at the end of this time.

The timestamp of starting both tests is: Thu Aug  1 05:46:34 UTC 2024

-- 
You received this bug notification because you are a member of Ubuntu
Bugs, which is subscribed to Ubuntu.
https://bugs.launchpad.net/bugs/2036467

Title:
  Resizing cloud-images occasionally fails due to superblock checksum
  mismatch in resize2fs

To manage notifications about this bug go to:
https://bugs.launchpad.net/cloud-images/+bug/2036467/+subscriptions


-- 
ubuntu-bugs mailing list
ubuntu-bugs@lists.ubuntu.com
https://lists.ubuntu.com/mailman/listinfo/ubuntu-bugs

[Bug 2073267] Re: Virtualbox Guru meditation on VM start caused by kernel commit in v6.9-rc4

Hi David,

Yes, it does indeed seem that the CVE has now been rejected.

https://lore.kernel.org/linux-cve-announce/2024073029-clerk-
trophy-b84c@gregkh/

https://nvd.nist.gov/vuln/detail/CVE-2024-35918
https://www.cve.org/CVERecord/?id=CVE-2024-35918

Maybe we can revert it after all!

I will have a talk with Aaron and the Kernel Team about how we should
move forward.

Thanks,
Matthew

-- 
You received this bug notification because you are a member of Ubuntu
Bugs, which is subscribed to Ubuntu.
https://bugs.launchpad.net/bugs/2073267

Title:
  Virtualbox Guru meditation on VM start caused by kernel commit in
  v6.9-rc4

To manage notifications about this bug go to:
https://bugs.launchpad.net/ubuntu/+source/linux/+bug/2073267/+subscriptions


-- 
ubuntu-bugs mailing list
ubuntu-bugs@lists.ubuntu.com
https://lists.ubuntu.com/mailman/listinfo/ubuntu-bugs

[Bug 2073267] Re: Virtualbox Guru meditation on VM start caused by kernel commit in v6.9-rc4

Hi everyone,

I see that Greg KH just assigned CVE-2024-35918 to "randomize_kstack:
Improve entropy diffusion".

I suppose that means that we cannot revert it now.

https://lore.kernel.org/linux-cve-announce/2024073029-clerk-
trophy-b84c@gregkh/T/

This is going to take some time.

Thanks,
Matthew

** CVE added: https://cve.mitre.org/cgi-bin/cvename.cgi?name=2024-35918

-- 
You received this bug notification because you are a member of Ubuntu
Bugs, which is subscribed to Ubuntu.
https://bugs.launchpad.net/bugs/2073267

Title:
  Virtualbox Guru meditation on VM start caused by kernel commit in
  v6.9-rc4

To manage notifications about this bug go to:
https://bugs.launchpad.net/ubuntu/+source/linux/+bug/2073267/+subscriptions


-- 
ubuntu-bugs mailing list
ubuntu-bugs@lists.ubuntu.com
https://lists.ubuntu.com/mailman/listinfo/ubuntu-bugs

[Bug 2073267] Re: Virtualbox Guru meditation on VM start caused by kernel commit in v6.9-rc4

Hi everyone,

Keith, thanks for testing! It is fantastic news that the test kernel
fixes the issue, and our theory is correct, and we are on the right
track.

I also tested both test kernels myself, and can confirm that reverting
"randomize_kstack: Improve entropy diffusion" fixes the issue, and that
"randomize_kstack: Remove non-functional per-arch entropy filtering" has
no improvement at all, and still has the issue.

So, I think the way forward is to do the unpopular thing, which is to
revert "randomize_kstack: Improve entropy diffusion".

We should never have changed something so fundamental as the kernel
thread stack size on a stable kernel. We can do that on the development
release sure, but not on LTS kernels.

I will have a talk with the Kernel team about it, but I will begin
preparing the patches and writing a SRU template.

Thanks,
Matthew

-- 
You received this bug notification because you are a member of Ubuntu
Bugs, which is subscribed to Ubuntu.
https://bugs.launchpad.net/bugs/2073267

Title:
  Virtualbox Guru meditation on VM start caused by kernel commit in
  v6.9-rc4

To manage notifications about this bug go to:
https://bugs.launchpad.net/ubuntu/+source/linux/+bug/2073267/+subscriptions


-- 
ubuntu-bugs mailing list
ubuntu-bugs@lists.ubuntu.com
https://lists.ubuntu.com/mailman/listinfo/ubuntu-bugs

[Bug 2075314] Re: Fence expiration time out i915-0000:03:00.0:python3[10055]:4

*** This bug is a duplicate of bug 2072755 ***
https://bugs.launchpad.net/bugs/2072755

** This bug has been marked a duplicate of bug 2072755
   i915: Fixup regressions introduced with enabling single CCS engine

-- 
You received this bug notification because you are a member of Ubuntu
Bugs, which is subscribed to Ubuntu.
https://bugs.launchpad.net/bugs/2075314

Title:
  Fence expiration time out i915-:03:00.0:python3[10055]:4

To manage notifications about this bug go to:
https://bugs.launchpad.net/ubuntu/+source/linux/+bug/2075314/+subscriptions


-- 
ubuntu-bugs mailing list
ubuntu-bugs@lists.ubuntu.com
https://lists.ubuntu.com/mailman/listinfo/ubuntu-bugs

[Bug 2073267] Re: Virtualbox Guru meditation on VM start caused by kernel commit in v6.9-rc4

Hi Gianfranco,

Great! Let's work this out together.

I have strong doubts that:

commit ef40d28f17bd384d7e0b630c7d83f108a526351b
Author: Kees Cook 
Date:   Wed Jun 19 14:47:15 2024 -0700
Subject: randomize_kstack: Remove non-functional per-arch entropy filtering
Link: 
https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/commit/?id=ef40d28f17bd384d7e0b630c7d83f108a526351b

will fix this issue. If you read the commit log and the code, it clearly
removes all per-arch entropy values, and just sticks with a universal
1KiB of space for all architectures.

The root cause of the issue is that "randomize_kstack: Improve entropy
diffusion" changed the amd64 kernel stack consumption for randomisation,
from 0.25KiB to a full 1KiB of space. The per thread kernel stacks are
only 16KiB in size, so we went from VirtualBox having 15.75KiB of stack
space down to 15KiB. VirtualBox must have been really pushing the limit
and needing that extra 0.75KiB of space, since without it, we panic.

They probably made some architectural changes in 7.0.x that reduce the
total kernel thread stack consumption, and now fall under the 15KiB
limit that "randomize_kstack: Improve entropy diffusion" imposes.

Anyway, I still made you a test kernel. It is based on
5.15.0-117-generic + "randomize_kstack: Remove non-functional per-arch
entropy filtering".

This test kernel is for Gianfranco Costamagna ONLY! Other users, please,
try my other test kernel in the above comment instead.

Gianfranco, the kernel will be ready in 3 hours from this message. They
are still building.

Please note this package is NOT SUPPORTED by Canonical, and is for TESTING
PURPOSES ONLY. ONLY Install in a dedicated test environment.

Instructions to Install (On a focal or jammy system):
1) sudo add-apt-repository ppa:mruffell/lp2073267-test-2
2) sudo apt update
3) sudo apt install linux-image-unsigned-5.15.0-117-generic 
linux-modules-5.15.0-117-generic linux-modules-extra-5.15.0-117-generic 
linux-headers-5.15.0-117-generic
4) sudo reboot
5) uname -rv
Look for +TEST2073267v20240731b2 

Anyway, I think we either need to figure out how to get the virtualbox
kernel module stack consumption down, or we revert "randomize_kstack:
Improve entropy diffusion" for focal, focal HWE, jammy, jammy HWE (but
not noble).

 virtualbox | 6.1.6-dfsg-1| focal/multiverse   
| source, amd64
 virtualbox | 6.1.32-dfsg-1build1 | jammy/multiverse   
| source, amd64
 virtualbox | 6.1.50-dfsg-1~ubuntu1.20.04.1   | focal-security/multiverse  
| source, amd64
 virtualbox | 6.1.50-dfsg-1~ubuntu1.20.04.1   | focal-updates/multiverse   
| source, amd64
 virtualbox | 6.1.50-dfsg-1~ubuntu1.22.04.1   | jammy-updates/multiverse   
| source, amd64
 virtualbox | 6.1.50-dfsg-1~ubuntu1.22.04.2   | jammy-proposed/multiverse  
| source, amd64
 virtualbox | 7.0.16-dfsg-2   | noble/multiverse   
| source, amd64
 virtualbox | 7.0.16-dfsg-2ubuntu1| noble-updates/multiverse   
| source, amd64
 virtualbox | 7.0.20-dfsg-1   | oracular/multiverse
| source, amd64

Thanks,
Matthew

-- 
You received this bug notification because you are a member of Ubuntu
Bugs, which is subscribed to Ubuntu.
https://bugs.launchpad.net/bugs/2073267

Title:
  Virtualbox Guru meditation on VM start caused by kernel commit in
  v6.9-rc4

To manage notifications about this bug go to:
https://bugs.launchpad.net/ubuntu/+source/linux/+bug/2073267/+subscriptions

-- 
ubuntu-bugs mailing list
ubuntu-bugs@lists.ubuntu.com
https://lists.ubuntu.com/mailman/listinfo/ubuntu-bugs

[Bug 2073267] Re: Virtualbox Guru meditation on VM start caused by kernel commit in v6.9-rc4

2024-07-30 Thread Matthew Ruffell

Hello everyone,

Lets get this problem solved.

Now, doing a major version update to virtualbox in Jammy from
6.1.50-dfsg-1~ubuntu1.20.04.1 to 7.0.20 is against Ubuntu SRU policy,
and would also come with the consequence that it would break all
existing VMs that use guest additions, as guest additions would have to
be removed from VMs, virtualbox upgraded, and then guest additions
installed again.

So no, doing a major upgrade to virtualbox is the wrong approach.

We have two options:
1) Locate the change in the kernel, then either revert it, or find a fix for it.
2) Locate the fix in virtualbox 7.0.20 and backport if possible to 6.1.50.

For the moment, let's just investigate 1).

I read AaronMa's comment with the upstream bug:

https://bugzilla.kernel.org/show_bug.cgi?id=219107

Now, only the first commit got backported to the jammy 5.15 kernel:

commit 507882a9d37affee0903c0ebb3d1544f4bfba024 ubuntu-jammy
Author: Kees Cook 
Date:   Sat Mar 9 12:24:48 2024 -0800
Subject: randomize_kstack: Improve entropy diffusion
Link: 
https://git.launchpad.net/~ubuntu-kernel/ubuntu/+source/linux/+git/jammy/commit/?id=507882a9d37affee0903c0ebb3d1544f4bfba024

This landed in:

$ git describe --contains 507882a9d37affee0903c0ebb3d1544f4bfba024
Ubuntu-5.15.0-115.125~210

which is when we started seeing the issues.

I have reverted this commit, and built test kernels for the more technically
inclined people to try:

https://launchpad.net/~mruffell/+archive/ubuntu/lp2073267-test

I just uploaded them. Please wait three hours from this message for them to 
have finished building.
There are both focal HWE and jammy kernels in this ppa.

Please note this package is NOT SUPPORTED by Canonical, and is for TESTING
PURPOSES ONLY. ONLY Install in a dedicated test environment.

Instructions to Install (On a focal or jammy system):
1) sudo add-apt-repository ppa:mruffell/lp2073267-test
2) sudo apt update
3) sudo apt install linux-image-unsigned-5.15.0-117-generic 
linux-modules-5.15.0-117-generic linux-modules-extra-5.15.0-117-generic 
linux-headers-5.15.0-117-generic
4) sudo reboot
5) uname -rv
Look for +TEST2073267v20240731b1

If you are asked to abort removal of the currently running kernel, say
no.

Does it fix virtualbox 6.1.50? Please let me know.

In the meantime, I will try and look through the virtualbox subversion
repository to find where virtualbox fixed this to see if backporting a
fix for virtualbox would be a better route to take.

https://www.virtualbox.org/browser/vbox/trunk

Thanks,
Matthew

-- 
You received this bug notification because you are a member of Ubuntu
Bugs, which is subscribed to Ubuntu.
https://bugs.launchpad.net/bugs/2073267

Title:
  Virtualbox Guru meditation on VM start caused by kernel commit in
  v6.9-rc4

To manage notifications about this bug go to:
https://bugs.launchpad.net/ubuntu/+source/linux/+bug/2073267/+subscriptions


-- 
ubuntu-bugs mailing list
ubuntu-bugs@lists.ubuntu.com
https://lists.ubuntu.com/mailman/listinfo/ubuntu-bugs

[Bug 2074141] Re: Kernel-Problems on many machines

2024-07-30 Thread Matthew Ruffell

Hi Detlef,

>a) crash by start

Graphics:
  Device-1: AMD Picasso/Raven 2 [Radeon Vega Series / Radeon Mobile Series] 
driver: amdgpu

You system was affected by bug 2068738, which has now been fixed as of
5.15.0-116-generic. Sorry for the inconvenience.

We will try fix c) soon.

Thanks,
Matthew

-- 
You received this bug notification because you are a member of Ubuntu
Bugs, which is subscribed to Ubuntu.
https://bugs.launchpad.net/bugs/2074141

Title:
  Kernel-Problems on many machines

To manage notifications about this bug go to:
https://bugs.launchpad.net/ubuntu/+source/linux/+bug/2074141/+subscriptions


-- 
ubuntu-bugs mailing list
ubuntu-bugs@lists.ubuntu.com
https://lists.ubuntu.com/mailman/listinfo/ubuntu-bugs

[Bug 2075110] Re: md: nvme over tcp with a striped underlying md raid device leads to data corruption

Patches are on the kernel team mailing list:

Cover letter:
https://lists.ubuntu.com/archives/kernel-team/2024-July/152506.html
Patch:
https://lists.ubuntu.com/archives/kernel-team/2024-July/152507.html

-- 
You received this bug notification because you are a member of Ubuntu
Bugs, which is subscribed to Ubuntu.
https://bugs.launchpad.net/bugs/2075110

Title:
  md: nvme over tcp with a striped underlying md raid device leads to
  data corruption

To manage notifications about this bug go to:
https://bugs.launchpad.net/ubuntu/+source/linux/+bug/2075110/+subscriptions


-- 
ubuntu-bugs mailing list
ubuntu-bugs@lists.ubuntu.com
https://lists.ubuntu.com/mailman/listinfo/ubuntu-bugs

[Bug 2075110] [NEW] md: nvme over tcp with a striped underlying md raid device leads to data corruption

Public bug reported:

BugLink: https://bugs.launchpad.net/bugs/2075110

[Impact]

There is a fault in the md subsystem where __write_sb_page() will round
the io size up to the optimal size, but it doesn't check to see if the
final io size exceeds the bitmap length.

This gets us into a situation where if we have 256K of io to submit, 64
pages are needed. md_bitmap_storage_alloc() allocates 1 page, and 63 are
allocated afterward.

When we send md writes over the network, e.g. with nvme over tcp, the
network subsystem checks the first page which is sendpage_ok(), but not
the other 63, which might not be sendpage_ok(), and will get stuck,
causing a hang and data corruption.

If you trigger the issue, you get the following oops in dmesg:

WARNING: CPU: 0 PID: 83 at net/core/skbuff.c:6995 
skb_splice_from_iter+0x139/0x370
CPU: 0 PID: 83 Comm: kworker/0:1H Not tainted 6.8.0-39-generic #39-Ubuntu
Workqueue: nvme_tcp_wq nvme_tcp_io_work [nvme_tcp]
RIP: 0010:skb_splice_from_iter+0x139/0x370
CR2: 72dab83e5f84
Call Trace:
 
 ? show_regs+0x6d/0x80
 ? __warn+0x89/0x160
 ? skb_splice_from_iter+0x139/0x370
 ? report_bug+0x17e/0x1b0
 ? handle_bug+0x51/0xa0
 ? exc_invalid_op+0x18/0x80
 ? asm_exc_invalid_op+0x1b/0x20
 ? skb_splice_from_iter+0x139/0x370
 tcp_sendmsg_locked+0x352/0xd70
 ? tcp_push+0x159/0x190
 ? tcp_sendmsg_locked+0x9c4/0xd70
 tcp_sendmsg+0x2c/0x50
 inet_sendmsg+0x42/0x80
 sock_sendmsg+0x118/0x150
 nvme_tcp_try_send_data+0x18b/0x4c0 [nvme_tcp]
 ? __tcp_cleanup_rbuf+0xc5/0xe0
 nvme_tcp_try_send+0x23c/0x300 [nvme_tcp]
 nvme_tcp_io_work+0x40/0xe0 [nvme_tcp]
 process_one_work+0x16c/0x350
 worker_thread+0x306/0x440
 ? _raw_spin_unlock_irqrestore+0x11/0x60
 ? __pfx_worker_thread+0x10/0x10
 kthread+0xef/0x120
 ? __pfx_kthread+0x10/0x10
 ret_from_fork+0x44/0x70
 ? __pfx_kthread+0x10/0x10
 ret_from_fork_asm+0x1b/0x30
 
nvme nvme1: failed to send request -5
nvme nvme1: I/O tag 125 (307d) type 4 opcode 0x0 (I/O Cmd) QID 1 timeout
nvme nvme1: starting error recovery
block nvme1n1: no usable path - requeuing I/O
nvme nvme1: Reconnecting in 10 seconds...

There is no workaround.

[Fix]

This was fixed in the below commit in 6.11-rc1:

commit ab99a87542f194f28e2364a42afbf9fb48b1c724
Author: Ofir Gal 
Date:  Fri Jun 7 10:27:44 2024 +0300
Subject: md/md-bitmap: fix writing non bitmap pages
Link: 
https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/commit/?id=ab99a87542f194f28e2364a42afbf9fb48b1c724

This is a clean cherry-pick to the Noble tree.

[Testcase]

This can be reproduced by running blktests md/001 [1], which the author
of the fix created to act as a regression test for this issue.

[1]
https://github.com/osandov/blktests/commit/a24a7b462816fbad7dc6c175e53fcc764ad0a822

Deploy a fresh Noble VM, that has a scratch NVME disk.

$ sudo apt install build-essential fio
$ git clone https://github.com/osandov/blktests.git
$ cd blktests
$ make
$ echo "TEST_DEVS=(/dev/nvme0n1)" > config
$ sudo ./check md/001

The md/001 test will hang an affected system, and the above oops message
will be visible in dmesg.

A test kernel is available in the following ppa:

https://launchpad.net/~mruffell/+archive/ubuntu/sf390669-test

If you install the test kernel, the md/001 test will complete
successfully, and the issue will no longer appear.

[Where problems could occur]

We are changing how the md subsystem calculates final IO sizes, and
taking the smaller value of the size or the bitmap_limit. This makes
sure we don't leak the final page and corrupt data.

If a regression were to occur, it would likely affect all md users, but
would be more obvious to md users over the network, like nvme over tcp.

There is no workaround. Users would have to downgrade their kernels if a
regression occurs.

[Other info]

I checked Jammy 5.15 and it works fine, so the issue must have been
introduced later on. It is not needed for Focal or Jammy.

** Affects: linux (Ubuntu)
 Importance: Undecided
 Status: Fix Released

** Affects: linux (Ubuntu Noble)
 Importance: Medium
 Assignee: Matthew Ruffell (mruffell)
 Status: In Progress


** Tags: noble sts

** Also affects: linux (Ubuntu Noble)
   Importance: Undecided
   Status: New

** Changed in: linux (Ubuntu)
   Status: New => Fix Released

** Changed in: linux (Ubuntu Noble)
   Importance: Undecided => Medium

** Changed in: linux (Ubuntu Noble)
   Status: New => In Progress

** Changed in: linux (Ubuntu Noble)
 Assignee: (unassigned) => Matthew Ruffell (mruffell)

** Description changed:

- BugLink: https://bugs.launchpad.net/bugs/
+ BugLink: https://bugs.launchpad.net/bugs/2075110
  
  [Impact]
  
  There is a fault in the md subsystem where __write_sb_page() will round
  the io size up to the optimal size, but it doesn't check to see if the
  final io size exceeds the bitmap length.
  
  This gets us into a situation where if we have 256K of io to submit, 64
  pages are needed. md_bitmap_stor

[Bug 2069534] Re: Linux 6.8 fails to boot on ARM64 if any param is more than 146 chars

Hi everyone,

SRU template is written. The patch has been submitted to the Ubuntu
Kernel mailing list.

Cover letter:
https://lists.ubuntu.com/archives/kernel-team/2024-July/152495.html
Patch:
https://lists.ubuntu.com/archives/kernel-team/2024-July/152496.html

TJ, I cc'd you incase the kernel team have any questions.

I will go speak to the kernel team now and make sure this makes
2024.08.05.

Thanks,
Matthew

-- 
You received this bug notification because you are a member of Ubuntu
Bugs, which is subscribed to Ubuntu.
https://bugs.launchpad.net/bugs/2069534

Title:
  Linux 6.8 fails to boot on ARM64 if any param is more than 146 chars

To manage notifications about this bug go to:
https://bugs.launchpad.net/ubuntu/+source/linux/+bug/2069534/+subscriptions


-- 
ubuntu-bugs mailing list
ubuntu-bugs@lists.ubuntu.com
https://lists.ubuntu.com/mailman/listinfo/ubuntu-bugs

[Bug 2069534] Re: Linux 6.8 fails to boot on ARM64 if any param is more than 146 chars

d it crashes the kernel.
  
- arm64: idreg-override: Avoid parameq() and parameqn()
+ [1]
+ https://bugs.launchpad.net/ubuntu/+source/linux/+bug/2069534/comments/20
  
+ I know SAUCE patches are to be avoided if possible, but T.J's solution
+ is minimal and fixes the root cause without the regression risk of
+ backporting the entire mini C runtime, so I suggest we go with T.J's
+ patch.
  
- Option 2.
- Unless Ubuntu Team is interested in bringing the whole Mini C Runtime rework 
to Linux 6.8 with
+ commit a4c616d2156c9c4cf7c91e6983c8bf0d51985df1
+ Author: Tj 
+ Date:   Fri Jul 26 13:48:44 2024 +
+ Subject: UBUNTU: SAUCE: arm64: v6.8: cmdline param >= 146 chars kills kernel
+ Link: 
https://lore.kernel.org/stable/JsQ4W_o2R1NfPFTCCJjjksPED-8TuWGr796GMNeUMAdCh-2NSB_16x6TXcEecXwIfgzVxHzeB_-PMQnvQuDo0gmYE_lye0rC5KkbkDgkUqM=@proton.me/T/#u
  
+ [Testcase]
  
- commit 6d75c6f40a03c97e1ecd683ae54e249abb9d922b
- Merge: fe46a7dd189e 1ef21fcd6a50
- Author: Linus Torvalds 
- Date:   Thu Mar 14 15:35:42 2024 -0700
+ 1) Deploy an ARM64 VM or use a bare metal ARM64 board with Noble, running 6.8.
+ 2) Edit /boot/grub/grub.cfg and add the following param to any boot entry 
with 
+ Linux 6.8
  
- Merge tag 'arm64-upstream' of
- git://git.kernel.org/pub/scm/linux/kernel/git/arm64/linux
+ 
testparam=f081c381e7b54edcba27e5f790d47911a4cc3e726d8d256878d3df9175c020e0f081c381e7b54edcba27e5f790d47911a4cc3e726d8d256878d3df9175c020e0f081c381e7b5732f126a62b4232
  
+ 3) Reboot the machine and select the boot entry in grub with the testparam as
+ above.
+ 4) Observe kernel never boots.
  
- Please revert the change in Linux 6.8
+ [Where problems could occur]
  
- Thanks
+ We are changing command line parsing on ARM64 systems, such that we only
+ do a memcmp() with aliased entries if the parameter we are parsing has
+ the same length as an aliased entry. This really shouldn't have any
+ change in functionality at all.
+ 
+ If a regression were to occur, then command line parsing on ARM64
+ systems could be broken, and it could lead to early boot failures,
+ likely caught on automated kernel tests.
+ 
+ [Other Info]
+ 
+ This fix is 6.8 specific. It is already fixed upstream by the mini C
+ runtime in 6.9 and later. This patch is for noble only.

** Changed in: linux (Ubuntu Noble)
   Status: Confirmed => In Progress

** Changed in: linux (Ubuntu Noble)
   Importance: Undecided => High

** Changed in: linux (Ubuntu Noble)
 Assignee: (unassigned) => Matthew Ruffell (mruffell)

** Tags added: noble seg

** Description changed:

- BugLink: https://bugs.launchpad.net/bugs/2068738
+ BugLink: https://bugs.launchpad.net/bugs/2069534
  
  [Impact]
  
  Linux 6.8 kernel fails to boot on ARM64 when any Linux command line
  param is more than 146 characters.
  
  This most notably affects MAAS deployments, as MAAS generates very long
  command line parameters for ARM64, e.g.:
  
  nomodeset
  
root=squash:http://10.254.131.130:5248/images/3b08252fa962c37a47d890fb5fe182b631a0c0478d758bf4573efa859cc2c548/ubuntu/arm64/ga-24.04/noble/stable/squashfs
  ip=sjc01-2b16-u07-mgx01b:BOOTIF ip6=off cc:\{'datasource_list':
  ['MAAS']\}end_cc cloud-config-url=http://10-254-131-128--25.maas-
  internal:5248/MAAS/metadata/latest/by-id/de6dn3/?op=get_preseed ro
  overlayroot=tmpfs overlayroot_cfgdisk=disabled log_host=10.254.131.130
  log_port=5247 --- BOOTIF=01-${net_default_mac}
  
  This was introduced in 6.8-rc1 by:
  
  commit dc3f5aae06381b43bc9d0d416bd15ee1682940e9
  Author: Ard Biesheuvel 
  Date: Wed Nov 29 12:16:12 2023 +0100
  Subject: arm64: idreg-override: Avoid parameq() and parameqn()
  Link: 
https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/commit/?id=dc3f5aae06381b43bc9d0d416bd15ee1682940e9
  
  There is no workaround, other than using command line parameters less
  than 146 characters. This is not tenable for MAAS users.
  
  [Fix]
  
  The fix arrived in a major refactor of early ARM64 init, where they
  moved from assembly to the pi mini c library. The specific commit that
  fixed the issue is:
  
  commit e223a449125571daa62debd8249fa4fc2da0a961
  Author: Ard Biesheuvel 
  Date: Wed Feb 14 13:28:50 2024 +0100
  Subject: arm64: idreg-override: Move to early mini C runtime
  Link: 
https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/commit/?id=e223a449125571daa62debd8249fa4fc2da0a961
  
  However, this needs a lot of dependencies, mostly all the "mini c
  runtime" commits in the below merge commit:
  
  commit 6d75c6f40a03c97e1ecd683ae54e249abb9d922b
  Merge: fe46a7dd189e 1ef21fcd6a50
  Author: Linus Torvalds 
  Date: Thu Mar 14 15:35:42 2024 -0700
  Subject: Merge tag 'arm64-upstream' of 
git://git.kernel.org/pub/scm/linux/kernel/git/arm64/linux
  Link: 
https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/commit/?id=6d75c6f40a03c97e1ecd683ae54e249abb9d922b
  
  The amount of code is generally unacceptabl

[Bug 2069534] Re: linux 6.8 fails to boot on arm64 if any param is more than 140 chars

Great, thanks for trying the test kernel.

I think the best way forward is to submit TJ's patch, it really is a
better solution that backporting the entire mini c runtime or reverting
the commit that introduced the problem.

I can write a SRU template and submit it tomorrow.

We need to try catch the 2024.08.05 SRU cycle as per
https://kernel.ubuntu.com/, which closes for patches on the 31st July,
which is really soon.

-- 
You received this bug notification because you are a member of Ubuntu
Bugs, which is subscribed to Ubuntu.
https://bugs.launchpad.net/bugs/2069534

Title:
  linux 6.8 fails to boot on arm64 if any param is more than 140 chars

To manage notifications about this bug go to:
https://bugs.launchpad.net/ubuntu/+source/linux/+bug/2069534/+subscriptions


-- 
ubuntu-bugs mailing list
ubuntu-bugs@lists.ubuntu.com
https://lists.ubuntu.com/mailman/listinfo/ubuntu-bugs

[Bug 2069534] Re: linux 6.8 fails to boot on arm64 if any param is more than 140 chars

2024-07-26 Thread Matthew Ruffell

Hi TJ, Shantur, Chris,

If you wait 3 hours from this message, the kernels will likely be ready. They
are building in:

https://launchpad.net/~mruffell/+archive/ubuntu/lp2069534-test

They are 6.8.0-39-generic + your patch. Both for Noble and Jammy HWE.

Test whatever you like.

Please note this package is NOT SUPPORTED by Canonical, and is for TESTING
PURPOSES ONLY. ONLY Install in a dedicated test environment.

Instructions to Install (On a Jammy, Noble system):
1) sudo add-apt-repository ppa:mruffell/lp2069534-test
2) sudo apt update
3) sudo apt install linux-image-unsigned-6.8.0-39-generic 
linux-modules-6.8.0-39-generic linux-modules-extra-6.8.0-39-generic 
linux-headers-6.8.0-39-generic
4) sudo reboot
5) uname -rv
Look for +TEST2069534v20240727b1.

If you get asked to remove the currently running kernel say no.

Can you boot it with more than 147 characters?

Let me know.

Thanks,
Matthew

-- 
You received this bug notification because you are a member of Ubuntu
Bugs, which is subscribed to Ubuntu.
https://bugs.launchpad.net/bugs/2069534

Title:
  linux 6.8 fails to boot on arm64 if any param is more than 140 chars

To manage notifications about this bug go to:
https://bugs.launchpad.net/ubuntu/+source/linux/+bug/2069534/+subscriptions


-- 
ubuntu-bugs mailing list
ubuntu-bugs@lists.ubuntu.com
https://lists.ubuntu.com/mailman/listinfo/ubuntu-bugs

[Bug 2069534] Re: linux 6.8 fails to boot on arm64 if any param is more than 140 chars

2024-07-26 Thread Matthew Ruffell

Hi TJ,

Thanks for your fix, this looks much, much more palatable than
backporting the entire mini C runtime, or reverting the commit that
caused this problem.

Now, just as Greg K-H says, 6.8.y is EOL upstream, and is closed to new
patches.

We can probably pick this up as a SAUCE patch for Ubuntu though.

I'll build you a test distro kernel with your patch ontop for testing,
and if it works great, we will submit a SAUCE patch for SRU.

I'll write back with a test kernel soon.

Thanks,
Matthew

-- 
You received this bug notification because you are a member of Ubuntu
Bugs, which is subscribed to Ubuntu.
https://bugs.launchpad.net/bugs/2069534

Title:
  linux 6.8 fails to boot on arm64 if any param is more than 140 chars

To manage notifications about this bug go to:
https://bugs.launchpad.net/ubuntu/+source/linux/+bug/2069534/+subscriptions


-- 
ubuntu-bugs mailing list
ubuntu-bugs@lists.ubuntu.com
https://lists.ubuntu.com/mailman/listinfo/ubuntu-bugs

[Bug 2073747] Re: Kernel bug when plugging ethernet cable : Regression of 6.8.0-38

2024-07-22 Thread Matthew

Can confirm that this bug also affects me on the same kernel version and
a Dell Precision 7550, Ubuntu 24.04/linux-image-6.8.0-38-generic. I
temporarily rolled back to 24.04/linux-image-6.8.0-36-generic and the
bug is not present there.

-- 
You received this bug notification because you are a member of Ubuntu
Bugs, which is subscribed to Ubuntu.
https://bugs.launchpad.net/bugs/2073747

Title:
  Kernel bug when plugging ethernet cable : Regression of 6.8.0-38

To manage notifications about this bug go to:
https://bugs.launchpad.net/ubuntu/+source/linux/+bug/2073747/+subscriptions


-- 
ubuntu-bugs mailing list
ubuntu-bugs@lists.ubuntu.com
https://lists.ubuntu.com/mailman/listinfo/ubuntu-bugs

[Bug 2032761] Re: Bluetooth headset microphone not working after upgrade to Kernel 6.2

2024-07-19 Thread Matthew Tucker-Simmons

This seems to have been fixed for me with kernel 6.8.0-38-generic.

-- 
You received this bug notification because you are a member of Ubuntu
Bugs, which is subscribed to Ubuntu.
https://bugs.launchpad.net/bugs/2032761

Title:
  Bluetooth headset microphone not working after upgrade to Kernel 6.2

To manage notifications about this bug go to:
https://bugs.launchpad.net/ubuntu/+source/linux-signed-hwe-6.2/+bug/2032761/+subscriptions


-- 
ubuntu-bugs mailing list
ubuntu-bugs@lists.ubuntu.com
https://lists.ubuntu.com/mailman/listinfo/ubuntu-bugs

[Bug 2073543] [NEW] Cannot upgrade from 22.04 to 24.04

2024-07-18 Thread Matthew Ross

Public bug reported:

I cannot upgrade from 22.04 to 24.04. The process either complains about
update-manager or the ubuntu-desktop with the deny list being the issue.
The package 'update-manager' is marked for removal but it's in the
removal deny list. I have tried to reinstall these, but have had no
luck.

ProblemType: Bug
DistroRelease: Ubuntu 22.04
Package: ubuntu-release-upgrader-core 1:22.04.19
ProcVersionSignature: Ubuntu 5.15.0-116.126-lowlatency 5.15.158
Uname: Linux 5.15.0-116-lowlatency x86_64
ApportVersion: 2.20.11-0ubuntu82.5
Architecture: amd64
CasperMD5CheckResult: pass
CrashDB: ubuntu
CrashReports:
 600:117:124:37:2024-07-18 17:47:59.370916810 +1000:2024-07-18 
17:47:59.370916810 +1000:/var/crash/_opt_brave.com_brave_brave.1000.uploaded
 600:0:124:197589:2024-07-18 11:00:44.231811012 +1000:2024-07-18 
11:00:44.677316579 +1000:/var/crash/libpipewire-0.3-modules.0.crash
 644:1000:124:0:2024-07-18 17:47:56.286916625 +1000:2024-07-18 
17:47:56.286916625 +1000:/var/crash/_opt_brave.com_brave_brave.1000.upload
 640:1000:124:37153213:2024-07-18 17:47:56.286916625 +1000:2024-07-18 
17:47:56.312916626 +1000:/var/crash/_opt_brave.com_brave_brave.1000.crash
CurrentDesktop: ubuntu:GNOME
Date: Fri Jul 19 08:59:25 2024
InstallationDate: Installed on 2023-05-03 (442 days ago)
InstallationMedia: Ubuntu 22.04.2 LTS "Jammy Jellyfish" - Release amd64 
(20230223)
PackageArchitecture: all
SourcePackage: ubuntu-release-upgrader
UpgradeStatus: Upgraded to jammy on 2024-07-18 (0 days ago)
VarLogDistupgradeAptHistorylog:
 Start-Date: 2024-07-18  18:23:12
 Requested-By: eternity (1000)
 End-Date: 2024-07-18  18:23:12
VarLogDistupgradeApttermlog:
 Log started: 2024-07-18  18:23:12
 Log ended: 2024-07-18  18:23:12
VarLogDistupgradeTermlog:
 
mtime.conffile..etc.update-manager.release-upgrades: 2024-07-18T17:52:06.829339

** Affects: ubuntu-release-upgrader (Ubuntu)
 Importance: Undecided
 Status: New


** Tags: amd64 apport-bug dist-upgrade jammy third-party-packages 
wayland-session

-- 
You received this bug notification because you are a member of Ubuntu
Bugs, which is subscribed to Ubuntu.
https://bugs.launchpad.net/bugs/2073543

Title:
  Cannot upgrade from 22.04 to 24.04

To manage notifications about this bug go to:
https://bugs.launchpad.net/ubuntu/+source/ubuntu-release-upgrader/+bug/2073543/+subscriptions


-- 
ubuntu-bugs mailing list
ubuntu-bugs@lists.ubuntu.com
https://lists.ubuntu.com/mailman/listinfo/ubuntu-bugs

[Bug 2072933] Re: Intel GPU hangs on oneAPI kernel on 6.8.0-38 but not 6.8.0-36

2024-07-15 Thread Matthew Ruffell

*** This bug is a duplicate of bug 2072755 ***
https://bugs.launchpad.net/bugs/2072755

Fantastic. Keep an eye out on that bug, and we will get this fixed.

Thanks,
Matthew

** This bug has been marked a duplicate of bug 2072755
   i915: Fixup regressions introduced with enabling single CCS engine

-- 
You received this bug notification because you are a member of Ubuntu
Bugs, which is subscribed to Ubuntu.
https://bugs.launchpad.net/bugs/2072933

Title:
  Intel GPU hangs on oneAPI kernel on 6.8.0-38 but not 6.8.0-36

To manage notifications about this bug go to:
https://bugs.launchpad.net/ubuntu/+source/linux/+bug/2072933/+subscriptions


-- 
ubuntu-bugs mailing list
ubuntu-bugs@lists.ubuntu.com
https://lists.ubuntu.com/mailman/listinfo/ubuntu-bugs

[Bug 2072755] Re: i915: Fixup regressions introduced with enabling single CCS engine

Hi nyanmisaka, TheDreadPirate,

Thanks for trying the test kernel, and great to hear that it works.

I wrote up a SRU template, as you can see, in the description of the
bug.

I also submitted the patch to the Ubuntu kernel mailing list:

Cover Letter:
https://lists.ubuntu.com/archives/kernel-team/2024-July/152131.html
Patch:
https://lists.ubuntu.com/archives/kernel-team/2024-July/152132.html

I will let you know once the Kernel team has reviewed and acked the patch,
and when they get built into a kernel in -proposed for verification.

Thanks,
Matthew

-- 
You received this bug notification because you are a member of Ubuntu
Bugs, which is subscribed to Ubuntu.
https://bugs.launchpad.net/bugs/2072755

Title:
  i915: Fixup regressions introduced with enabling single CCS engine

To manage notifications about this bug go to:
https://bugs.launchpad.net/ubuntu/+source/linux/+bug/2072755/+subscriptions


-- 
ubuntu-bugs mailing list
ubuntu-bugs@lists.ubuntu.com
https://lists.ubuntu.com/mailman/listinfo/ubuntu-bugs

[Bug 2072755] Re: i915: Fixup regressions introduced with enabling single CCS engine

** Summary changed:

- Request backport of two i915/Intel Arc GPU patches
+ i915: Fixup regressions introduced with enabling single CCS engine

** Changed in: linux (Ubuntu Noble)
   Status: New => In Progress

** Changed in: linux (Ubuntu Noble)
   Importance: Undecided => Medium

** Changed in: linux (Ubuntu Noble)
 Assignee: (unassigned) => Matthew Ruffell (mruffell)

** Description changed:

- Hello Ubuntu Linux Kernel Team,
+ BugLink: https://bugs.launchpad.net/bugs/2072755
  
- Recently, Ubuntu 24.04 bumped the kernel version to linux 6.8.8
- (6.8.0-38.38 pkg version), which introduced an i915 regression affecting
- GPU accelerated video transcoding on Intel Arc GPU. This bug affects all
- linux 6.8.5+ kernels and was not fully fixed until linux 6.9.4.
+ [Impact]
  
- https://bugs.launchpad.net/ubuntu/+source/linux/+bug/2068087
+ Recently, the Intel i915 susbsystem underwent a change that limited the
+ number of CCS engines that were initialised by default, and exposed to
+ the user. Different chipsets have differing amounts of CCS engines, but
+ most available in the market have 4 CCS engines. The new change just
+ starts a single engine only, and allocates all CCS slices to this single
+ engine. This single engine is then exposed to userspace. This effort is
+ to workaround a hardware bug.
  
- The issue makes the ffmpeg command fail and throws i915 error in dmesg.
- `[ 81.026591] Fence expiration time out i915-:01:00.0:ffmpeg[521]:2!`
+ This all happened in:
  
+ commit 6db31251bb265813994bfb104eb4b4d0f44d64fb
+ Author: Andi Shyti 
+ Date:   Thu Mar 28 08:34:05 2024 +0100
+ Subject: drm/i915/gt: Enable only one CCS for compute workload
+ Link: 
https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/commit/?id=6db31251bb265813994bfb104eb4b4d0f44d64fb
+ 
+ which landed in:
+ 
+ $ git describe --contains 67f164e8510b16bda18642464863dba87a33d8cb
+ Ubuntu-6.8.0-38.38~525
+ 
+ There have been some side effects as a result of these changes, leading
+ to failure of userspace applications, namely in video transcoding with
+ ffmepg, resulting in fence expiration errors in dmesg like:
+ 
+ [ 81.026591] Fence expiration time out i915-:01:00.0:ffmpeg[521]:2!
+ 
+ There has also been a performance impact introduced by this change,
+ which dropped performance of the GPU to 1/4 of what it was previously.
+ This is likely due to most ARC GPUs usually having 4 CCS engines, and
+ going down to 1 only without actually allocating the other three.
+ 
+ There are no workarounds. Users are suggested to downgrade to
+ 6.8.0-36-generic while the fix is coming.
+ 
+ [Fix]
+ 
+ The regression was fixed by these two commits:
+ 
+ commit aee54e282002a127612b71255bbe879ec0103afd
+ Author: Andi Shyti 
+ Date: Fri Apr 26 02:07:23 2024 +0200
+ Subject: drm/i915/gt: Automate CCS Mode setting during engine resets
+ Link: 
https://git.launchpad.net/~ubuntu-kernel/ubuntu/+source/linux/+git/noble/commit/?id=aee54e282002a127612b71255bbe879ec0103afd
+ 
+ commit ee01b6a386eaf9984b58a2476e8f531149679da9
+ Author: Andi Shyti 
+ Date: Fri May 17 11:06:16 2024 +0200
+ Subject: drm/i915/gt: Fix CCS id's calculation for CCS mode setting
+ Link: 
https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/commit/?id=ee01b6a386eaf9984b58a2476e8f531149679da9
+ 
+ "drm/i915/gt: Automate CCS Mode setting during engine resets" is already
+ applied to noble/master-next through upstream stable v6.8.10.
+ 
+ We just need "drm/i915/gt: Fix CCS id's calculation for CCS mode
+ setting". It is queued up for v6.9.4, but that could still be another
+ SRU cycle or two away. So send it now.
+ 
+ "drm/i915/gt: Fix CCS id's calculation for CCS mode setting" restores
+ another 1/4 performance, but some performance issues still remain, and
+ will hopefully be addressed in a future patch.
+ 
+ [Testcase]
+ 
+ This affects video transcoding with ffmpeg, on machines equipped with
+ Intel ARC GPUs.
+ 
+ An example ffmpeg command might be:
+ 
+ /usr/lib/jellyfin-ffmpeg/ffmpeg -analyzeduration 200M -probesize 1G -ss
+ 00:00:03.000 -noaccurate_seek -init_hw_device
+ vaapi=va:,kernel_driver=i915,driver=iHD -init_hw_device qsv=qs@va
+ -filter_hw_device qs -hwaccel vaapi -hwaccel_output_format vaapi
+ -noautorotate -i file:"/path/to/1080_video.mkv" -noautoscale
+ -map_metadata -1 -map_chapters -1 -threads 0 -map 0:0 -map 0:1 -map -0:s
+ -codec:v:0 av1_qsv -preset veryfast -b:v 3616000 -maxrate 3616000
+ -bufsize 7232000 -g:v:0 72 -keyint_min:v:0 72 -vf
+ 
"setparams=color_primaries=bt709:color_trc=bt709:colorspace=bt709,scale_vaapi=w=1280:h=720:format=nv12:extra_hw_frames=24,hwmap=derive_device=qsv,format=qsv"
+ -codec:a:0 libfdk_aac -ac 2 -vbr:a 5 -copyts -avoid_negative_ts disabled
+ -max_muxing_queue_size 2048 -f hls -max_delay 500 -hls_time 3
+ -hls_segment_type fmp4 -hls_fmp4_init_filename
+ "c30716eb121448346fcc00a2440071a3

[Bug 2072933] Re: Intel GPU hangs on oneAPI kernel on 6.8.0-38 but not 6.8.0-36

Hi Filip,

I think this is a duplicate of bug 2072755. Can you head over there and
try the test kernel I linked?

Thanks,
Matthew

-- 
You received this bug notification because you are a member of Ubuntu
Bugs, which is subscribed to Ubuntu.
https://bugs.launchpad.net/bugs/2072933

Title:
  Intel GPU hangs on oneAPI kernel on 6.8.0-38 but not 6.8.0-36

To manage notifications about this bug go to:
https://bugs.launchpad.net/ubuntu/+source/linux/+bug/2072933/+subscriptions


-- 
ubuntu-bugs mailing list
ubuntu-bugs@lists.ubuntu.com
https://lists.ubuntu.com/mailman/listinfo/ubuntu-bugs

[Bug 2067862] Re: Removing legacy virtio-pci devices causes kernel panic