@b-9
There may be various options, depending on how comfortable you are with the
command line.
You could try to build a custom initramfs image with diagnostic tools, boot
from it and dump the necessary info to a USB drive for example. Or clone the
ubuntu kernel git repository and use git bisect
@ishinberg0
The issue ami, crysman and I had was related to a specific NVMe
controller (PCI IDs 126f:2263). 5.4.0-48 fixed it for ami and I at
least. I guess your issue is different; I suggest you file a new bug
report with details about your system (dmesg, lspci output etc.).
--
You received th
@crysman I have a NUC too. Is your nvme controller a Silicon Motion, Inc.
Device 2263 (rev 03) (126f:2263)?
It seems this controller somehow deviates from the specification.
The commit I mentioned above (ea43d9709f) made the driver stricter, causing it
to reject the device.
A fix is available ups
Same problem for me, 5.4.0-45 and -47 kernels fail to detect my nvme drive
while -42 boots fine.
According to git bisect the issue was introduced by commit
e958cbb11ed6f58dac5bbfba481631ff0f567c7d (upstream
ea43d9709f727e728e933a8157a7a7ca1a868281).
** Attachment added: "BISECT_LOG"
https:/
Yes, I noticed that one yesterday evening in the mainline repository. I've
just installed your image and it works fine too. Thanks.
--
You received this bug notification because you are a member of Kernel
Packages, which is subscribed to linux in Ubuntu.
https://bugs.launchpad.net/bugs/1301590
T
I think there is a bug, even in the latest (3.13.0-23.45) revision.
It probably affects any 32-bit EFI system.
One easy way to fix it is to insert the following line in
efi_32.c:efi_map_region():
set_bit(EFI_OLD_MEMMAP, &x86_efi_facility);
This helps ensure that the function efi.c:runtim
Ok, I've cloned the ubuntu-trusty repo, used git bisect and found the
culprit:
dc9c3ed611922e769b1fd595f8f99a93d69c026d is the first bad commit
commit dc9c3ed611922e769b1fd595f8f99a93d69c026d
Author: Borislav Petkov
Date: Thu Oct 31 17:25:08 2013 +0100
x86/efi: Runtime services virtual map
Just tried with nr_cpus=1, still freezes with no message.
On Apr 3, 2014 5:52 PM, "Seth Forshee"
wrote:
> Achille: Could you also try adding "nr_cpus=1" to the boot options and
> see if this allows you to boot?
>
> --
> You received this bug notification because you are subscribed to the bug
> re
I have read this page before reporting the bug. As I've written, no
kernel message is displayed.
With the default kernel command line, no message is displayed at all,
the machine freezes with a blank purple screen.
With the "quiet splash $vt_handoff" part removed, the last signs of
life I get befo
Public bug reported:
I'm currently stuck with the 3.13.0-19-generic version.
With both 3.13.0-20 and 3.13.0-21, the boot process fails very early: even
without "quiet splash" in the kernel command line, I do not get any message
beyond those of EFI GRUB (loading kernel & initrd).
ProblemType: Bu
10 matches
Mail list logo
