Arch Linux

Please read this before reporting a bug:
https://wiki.archlinux.org/index.php/Reporting_Bug_Guidelines

Do NOT report bugs when a package is just outdated, or it is in Unsupported. Use the 'flag out of date' link on the package page, or the Mailing List.

REPEAT: Do NOT report bugs for outdated packages!
Tasklist

FS#47509 - [linux] Boot hangs anytime with 4.x kernel on Dell 1012 Inspiron (Intel Pineview)

Attached to Project: Arch Linux
Opened by kozaki (kozaki) - Wednesday, 23 December 2015, 23:27 GMT
Last edited by Doug Newgard (Scimmia) - Friday, 20 October 2017, 14:57 GMT
Task Type Bug Report
Category Kernel
Status Closed
Assigned To Tobias Powalowski (tpowa)
Architecture All
Severity High
Priority Normal
Reported Version
Due in Version Undecided
Due Date Undecided
Percent Complete 100%
Votes 1
Private No

Details

Description:
System freezes anytime I boot Arch with a 4.x kernel i686 and x86_64. A hard reboot is needed.

Additional info:
- Booted kernels ARCH, ck, zen, lts and all freeze
- Intel Atom N450 "Pineview" (Intel NM10 Express / GMA 3150) netbook Dell Mini 1012
- MBR layout Momentus 5.4k HDD
- happened on i686 which was a 4 years old install. Single HD layout (no Raid, LVM or encryprion).
- I formatted the whole drive and installed a new system using archiso-201501 x86_64. Kept default settings whenever possible to strip down the search for possible causes of this freeze. At the end it reproduces the same issue.

Steps to reproduce:
- Boot Arch with a kernel 4x, freeze.

Observation:
- with any kernel 3x system boots and runs fine.
- i686 booted with *intel_ucode cheatcode*; with new install the system won't start booting until that cheatcode is removed.
- Maybe interesting: *First boot upon install* boots and run just fine; not any further one. I installed twice to check and could reproduce that.
This task depends upon

Closed by  Doug Newgard (Scimmia)
Friday, 20 October 2017, 14:57 GMT
Reason for closing:  No response
Comment by kozaki (kozaki) - Wednesday, 23 December 2015, 23:37 GMT
Last logs, lspci and cpuinfo

* x86_64
https://ptpb.pw/suNu First boot upon install, no issue, 8 days uptime.

Second boot log is empty, like that:
-- Logs begin at Sun 2015-12-13 03:18:36 UTC, end at Mon 2015-12-21 23:54:05 UTC. --
Dec 21 23:50:16 gwenael systemd-journald[212]: Runtime journal (/run/log/journal/) is currently using 8.0M.
Maximum allowed usage is set to 99.7M.
Leaving at least 149.6M free (of currently available 989.6M of space).
Enforced usage limit is thus 99.7M, of which 91.7M are still available.
Dec 21 23:50:16 gwenael systemd-journald[212]: System journal (/var/log/journal/) is currently using 104.0M.
Maximum allowed usage is set to 793.5M.
Leaving at least 1.1G free (of currently available 5.6G of space).
Enforced usage limit is thus 793.5M, of which 689.5M are still available.
Dec 21 23:50:17 gwenael systemd-journald[212]: Time spent on flushing to /var is 1.002057s for 2 entries.

https://ptpb.pw/rtrJ with 3.10.94-1-lts310-ck, boot fine.

i686
https://ptpb.pw/9C8o with 4.2.1-ARCH-fallback boot & freeze.
Comment by kozaki (kozaki) - Saturday, 26 December 2015, 02:14 GMT
Managed to get new logs on the x86_64 install for failed boot with Arch stock kernel, using more appropriate cheatcodes. Will attach ASAP (due lunch time :p )

EDIT: boot logs attached.
First with: ro loglevel=7 earlyprintk=vga debug initrd=../initramfs-linux-fallback.img
Second one same but: rw nomodeset

Note: Atm I'm unable to mount my xfs external HDD while on linux-lts310-ck even after have runned `xfs_repair`.
Comment by kozaki (kozaki) - Sunday, 27 December 2015, 22:04 GMT
linux-4.0.7-2-ARCH built on the Atom ;} boots fine --if intel_ucode is removed from the cheatcodes.
Comment by kozaki (kozaki) - Friday, 01 January 2016, 22:41 GMT
Booted with **linux 4.4.0-rc7-mainline** and at first thought it booted til the console! Yeah, but it was the recovery shell. Next boot with this kernel freezed at the same apparent stage well into the boot. E.g. config files are read and systemd-vconsole-setup succeeds. Little difference compared to the stock kernel.

Attaching log for boot freezing with linux 4.4.0-rc7-mainline.
Comment by kozaki (kozaki) - Thursday, 04 February 2016, 19:29 GMT
Update.

1/ Arch
Linux mainline 4.4.1 hangs like the other 4.1x kernels.

2/ Fedora 23
I installed Fedora 23 on a spare logical partition and tested various 4x kernels, to confirm it's upstream issue. Here follow the results:

linux-4.2.3-300.fc23:
Runs just fine on first boot-up after installing the distro --> same as Arch.
Hangs upon the following boots --> same as Arch.

linux-4.3.3-301.fc23 and 4.1.0-1.fc23
Hangs upon boot-up --> same as Arch.

linux-4.0.8-300.fc22
Boots up to the gui login / tty (where I can't login for some unknown hostname reason).
After it freezes, I can't see anything in the logs about a kernel panic which is making me think this is some kind of serious fault as the kernel doesn't even have chance to log any related output that I can grasp.

Hang happens after I unplugged any external device from the laptop.

@brain0 and @tpowa if that still lacks usefull information please let me know.
Comment by kozaki (kozaki) - Saturday, 12 March 2016, 10:46 GMT
Linux mainline 4.5rc7 have the system hangs like with the other 4.1+ kernels.

I don't want to stay running linux 4.0.7 until the sky falls on my head. Will get OpenMediaVault or Rockstor NAS OS running and delete Arch + Fedora from this unsupported netbook. Hopefully will go on making a good job as a small NAS device.
Comment by Tobias Powalowski (tpowa) - Monday, 14 March 2016, 07:13 GMT
Without bisecting and reporting this upstream probably nothing will change.
Comment by kozaki (kozaki) - Monday, 14 March 2016, 09:52 GMT
Thanks for this first bit of information. I had no idea about this (see above asking if I could provide additional info). Maybe it could have been said before eight months testing and reporting new kernels? Now our backup workflow is waiting for the Dell to be ready as a Nas. No more time to digest https://wiki.archlinux.org/index.php/Bisecting_bugs unfortunately.
Comment by Tobias Powalowski (tpowa) - Monday, 14 March 2016, 11:22 GMT
We cannot fix kernel bugs, users need to ideally bisect the commit which broke it and report it upstream.
Comment by kozaki (kozaki) - Sunday, 03 July 2016, 10:38 GMT
Unfortunately I found no time to co my first bisect. But `systemd.restore_state=0` kernel parameter allows the ARCH kernel to boot the dell mini 1012, yeap! Source on https://bbs.archlinux.org/viewtopic.php?id=201523&p=2
Comment by mattia (nTia89) - Monday, 02 October 2017, 20:08 GMT
is this issue still valid?

Loading...