[04:24] <tsimonq2> Hm, bug 1635597 might need some looking at.
[04:24] <ubot5`> bug 1635597 in makedumpfile (Ubuntu Trusty) "Ubuntu:talclp1: Kdump failed with multipath disk" [High,Confirmed] https://launchpad.net/bugs/1635597
[04:24] <tsimonq2> The SRU wasn't marked as fine but someone commented saying it was.
[11:22] <frickler> jsalisbury: smb: maybe I'm misunderstanding something, but it would be a shame if the bug didn't get fixed just because nobody can test it with Artful https://bugs.launchpad.net/ubuntu/+source/linux/+bug/1748408
[11:22] <ubot5`> Ubuntu bug 1748408 in linux (Ubuntu) "Servers going OOM after updating kernel from 4.10 to 4.13" [High,In progress]
[11:27] <smb> frickler, The text is a template that not always covers the real case. But the HWE 4.13 kernel is derived from the artful kernel. So if you can do a verification in Xenial with the 4.13 HWE kernel, that is fine. 
[11:30] <smb> frickler, there is a new HWE kernel in proposed as well (4.13.0-38.43~16.04.1). So mentioning that verification was done on that version.
[11:32] <frickler> smb: oh, thanks for the pointer. I can test that, but it will take maybe more than 5 days. is that a hard timeout and the patch would get delayed to another kernel release if it is not met?
[11:38] <smb> frickler, the time limit given is deliberately challenging. But at some point we will have to look at things which have not been verified and decide how much risk they pose. And if there is something that appears scary there still needs to be time to drop things and build new kernels. And all that within the 3 week cadence, so there is not too much time to wait.
[11:42] <frickler> smb: o.k., thx for explaining, I'll see what I can come up with
[12:15] <sforshee> sbeattie, tyhicks: the kernel_symbols_missing qrt test is failing for a different reason now, the /sys/module/foo/sections/.text files have mode 0400 since commit 277642dcca765a1955d4c753a5a315ff7f2eb09d
[12:16] <sforshee> (this is with bionic if you didn't guess that already)
[14:40] <sbeattie> sforshee: oh hrm, okay
[15:54] <dijuremo> We seem to be observing a pattern on machines with the latest hew-16.04 kernel which froze when they have the latest BIOS from Vendors like DELL and Lenovo. These machines also seem to have NVIDIA cards installed, but I am not quite sure if the NVIDIA driver is part of the issue. Are there known issues around this?
[15:55] <dijuremo> Rolling back the BIOS (pre-meltdown and spectre INTEL patches) fixes the freezing immediatley.
[15:56] <dijuremo> Problem is that now some systems come with the latest BIOS' and forbid you from downgrading to earlier versions, so we effectively end up with a machine that cannot run Ubuntu.
[16:10] <TJ-> dijuremo: were you reporting this about a week ago? We had the same issue we tracked to the same cause.
[16:11] <TJ-> dijuremo: didn't go any further with regard to the kernel patches because the BIOS was rolled back. The investigation we did then seemed to show that BIOS microcode that Dell provided was the January one from Intel that had the known bugs in and was supposed to be withdrawn; and presumably should now the superseded by the late Feb Intel re-release
[16:35] <dijuremo> We are seeing the problems with the latest February BIOS'
[16:35] <dijuremo> We have seen them in some laptops and T5820 workstations
[16:36] <dijuremo> The laptops were the 7480 line. One came with the old BIOS, one with the new. The laptop with new BIOS refuses to downgrade. States downgrading is *Blocked*
[16:37] <dijuremo> The Lenovo machine is the M93p also using the latest February published BIOs.
[16:41] <dijuremo> Seems like there is now a newer March 15 BIOS for the Latitude 7480, so I will have to give that a try.
[16:41] <TJ-> Ahh, last week it was a server. I recommended an email be sent to one of the kernel dev's to forward to the Dell team responsible for the microcode upgrades
[16:43] <dijuremo> In the laptop case, we did not even have discrete GPU, and the laptop would freeze after the GUI login would show up with 4.13.x Our solution on that one, since we could not downgrade the BIOS, was to go down to the 4.4.x series kernel
[16:44] <dijuremo> So we had the laptop with older firmware running 4.13.x kernel no problems and the laptop with newer firmware running 4.4.x kernel and told the end user to *not* upgrade to 4.13.x or his machine will no longer work.
[16:46] <TJ-> There are kernel command-line options you know? "nopti" and "nospectre_v2"
[17:00] <dijuremo> TJ: Good info, will have to try again the next time I see the problem to find out if those help