Bug 26338 - Intermittent failure early in boot, Intel Q9100
Summary: Intermittent failure early in boot, Intel Q9100
Status: RESOLVED FIXED
Alias: None
Product: Mageia
Classification: Unclassified
Component: RPM Packages (show other bugs)
Version: 7
Hardware: x86_64 Linux
Priority: Normal normal
Target Milestone: ---
Assignee: Kernel and Drivers maintainers
QA Contact:
URL:
Whiteboard:
Keywords:
Depends on:
Blocks:
 
Reported: 2020-03-13 01:02 CET by Morgan Leijström
Modified: 2021-03-15 09:07 CET (History)
0 users

See Also:
Source RPM: kernel
CVE:
Status comment:


Attachments
Picture of screen at boot failure (590.57 KB, image/jpeg)
2020-03-13 01:29 CET, Morgan Leijström
Details

Description Morgan Leijström 2020-03-13 01:02:00 CET
Description of problem:
Sometimes boot hangs very early after grub
Even before it asks for encryption key for the disk.


Once up, it is running perfectly with Xfce
Suspend-resume perfectly including wifi.
Resuming from hibernation: same occasional problem as normal boot.
But as it is just to try again until it boots, and resuming works so i do  not set this bug critical because user do not loose work.


System: Laptop Dell Precision M4400  (bought used recently)
CPU: Intel Core 2 Quad Q9100 (fam 6 mod 23 step 10 Cpuid 13) 2,26MHz 4GB RAM
GPU: Nvidia G96GLM (Quadro FX 770M) Driver: nvidia Geforce 8100 to 415
Disk: SSD, separate /boot, then rest of system in LVM lv:s in a LUKS encrypted pv.


How reproducible:
§ About every third try in general, but may file twice in a row, or work several times.
§ Reboot or cold start does not seem to matter
§ MSWindows10 is installed in dual boot configuration and have no problem (but i have only booted less than ten times)
§ Once Mageia is booted, never any problems during ten hours use total this far.
§ Update to later kernels. Possibly 5.5 series works a tiny bit better, hard to judge.
§ If i in BIOS settings enable virtualisation, it always fail
§ If i disable speedstep it seem to work a bit better
§ No BIOS setting seem to get rid of the problem, i have tried to disable serial parallel esata and other ports and hardware.


Steps to Reproduce:

1. Install Mageia 7.1 ( I used LVM and encryption but as it dont get that far in but i dont think that matters )

2. Boot.  In Grub edit kernel boot line parameters: remove splash quiet so you see what happens. If you are lucky it works.  Else retry until it does. It reboots from Ctrl-backspace-backspace.

Grub kernel line:
linux16 /vmlinuz-5.5.9-desktop-1.mga7 root=/dev/mapper/vg--mga-lv_root ro noiswmd nokmsboot resume=/dev/vg-mga/lv_swap audit=0 vga=797
Comment 1 Morgan Leijström 2020-03-13 01:16:51 CET
All previous tests were with -desktop kernel flavour.
Now i have tried kernel-linus-5.4.20-1.mga7
It failed four times in a row.
Fifth time it passed so long i entered luks key.  I had selected maintenance mode so there i pressed Ctrl-D and it booted a tiny bit further until it hung hard.  Had to press power button.
On trying again now, grub is destroyed, i only get

 grub >

Hrmf.

Assignee: bugsquad => kernel

Comment 2 Morgan Leijström 2020-03-13 01:29:16 CET
Created attachment 11548 [details]
Picture of screen at boot failure

Here is a picture i took of the laptop screen two days ago i think.
Kernel 5.5.6 if i recall correctly.

Boot seem to progress fine for two seconds, then noting happens for almost 6 seconds when the line "random: crng init done" get written.  Then there is almost a minute until it writes out stall is detected.

If i keep waiting it repeats that messages (call trace etc) about every minute.
Comment 3 Morgan Leijström 2020-04-05 22:52:58 CEST
Still valid kernels 5.5.14 and 5.5.15.
5.5.15 also have problem suspending in this machine, Bug 26440.
Comment 4 Morgan Leijström 2020-04-05 23:00:22 CEST
For lspci output see that bug
Comment 5 Morgan Leijström 2021-03-15 09:07:14 CET
Not a sign of problem on Mageia 8 Lives nor installed. Same machine.

Also no one else reported problem, so I assume problem is gone on mga7.

Hibernation and resuming is an issue i will later look at...

Resolution: (none) => FIXED
Status: NEW => RESOLVED


Note You need to log in before you can comment on or make changes to this bug.