[arch-general] Getting freeze on early start with linux 4.9-1 kernel.

[Carsten Mattner]

On Fri, Dec 23, 2016 at 3:17 PM, Mauro Santos via arch-general
<arch-general at archlinux.org> wrote:
> On 23-12-2016 13:58, Carsten Mattner via arch-general wrote:
>> On Fri, Dec 23, 2016 at 1:59 PM, fredbezies via arch-general
>> <arch-general at archlinux.org> wrote:
>>> Hello.
>>>
>>> I'm facing an annoying bug with linux 4.9-1 kernel on my 6 or 7 years
>>> old Toshiba Laptop. When I try to make it boot on with linux 4.9-1
>>> kernel, it freeze right after loading initramfs.
>>>
>>> 4.8.xx kernel was working flawlessly. My eeePC (nearly 9 years old)
>>> and my desktop computer (which is AMD based) are both starting with
>>> linux 4.9.
>>>
>>> I opened a bug : https://bugs.archlinux.org/task/52246
>>>
>>> Here is my lspci. If someone can help me finding what is happening,
>>> I'll be very happy :
>>>
>>> 00:00.0 Host bridge: Intel Corporation Mobile 4 Series Chipset Memory
>>> Controller Hub (rev 07)
>>> 00:02.0 VGA compatible controller: Intel Corporation Mobile 4 Series
>>> Chipset Integrated Graphics Controller (rev 07)
>>> 00:02.1 Display controller: Intel Corporation Mobile 4 Series Chipset
>>> Integrated Graphics Controller (rev 07)
>>> 00:1a.0 USB controller: Intel Corporation 82801I (ICH9 Family) USB
>>> UHCI Controller #4 (rev 03)
>>> 00:1a.1 USB controller: Intel Corporation 82801I (ICH9 Family) USB
>>> UHCI Controller #5 (rev 03)
>>> 00:1a.7 USB controller: Intel Corporation 82801I (ICH9 Family) USB2
>>> EHCI Controller #2 (rev 03)
>>> 00:1b.0 Audio device: Intel Corporation 82801I (ICH9 Family) HD Audio
>>> Controller (rev 03)
>>> 00:1c.0 PCI bridge: Intel Corporation 82801I (ICH9 Family) PCI Express
>>> Port 1 (rev 03)
>>> 00:1c.1 PCI bridge: Intel Corporation 82801I (ICH9 Family) PCI Express
>>> Port 2 (rev 03)
>>> 00:1c.4 PCI bridge: Intel Corporation 82801I (ICH9 Family) PCI Express
>>> Port 5 (rev 03)
>>> 00:1d.0 USB controller: Intel Corporation 82801I (ICH9 Family) USB
>>> UHCI Controller #1 (rev 03)
>>> 00:1d.1 USB controller: Intel Corporation 82801I (ICH9 Family) USB
>>> UHCI Controller #2 (rev 03)
>>> 00:1d.2 USB controller: Intel Corporation 82801I (ICH9 Family) USB
>>> UHCI Controller #3 (rev 03)
>>> 00:1d.3 USB controller: Intel Corporation 82801I (ICH9 Family) USB
>>> UHCI Controller #6 (rev 03)
>>> 00:1d.7 USB controller: Intel Corporation 82801I (ICH9 Family) USB2
>>> EHCI Controller #1 (rev 03)
>>> 00:1e.0 PCI bridge: Intel Corporation 82801 Mobile PCI Bridge (rev 93)
>>> 00:1f.0 ISA bridge: Intel Corporation ICH9M LPC Interface Controller (rev 03)
>>> 00:1f.2 SATA controller: Intel Corporation 82801IBM/IEM
>>> (ICH9M/ICH9M-E) 4 port SATA Controller [AHCI mode] (rev 03)
>>> 00:1f.3 SMBus: Intel Corporation 82801I (ICH9 Family) SMBus Controller (rev 03)
>>> 02:00.0 Ethernet controller: Realtek Semiconductor Co., Ltd.
>>> RTL8101/2/6E PCI Express Fast/Gigabit Ethernet controller (rev 02)
>>> 03:00.0 Ethernet controller: Qualcomm Atheros AR242x / AR542x Wireless
>>> Network Adapter (PCI-Express) (rev 01)
>>
>> Does the fallback boot entry work?
>>
>> Have you tried reinstalling the kernel?
>>
>> I wish arch would (like other distros) keep 2 or three old kernel
>> versions around because it doesn't take any space to do so
>> and works around boot bugs in new kernels.
>>
>
> Care to explain how "doesn't take any space" works? Last time I checked
> files do take up space. There is an LTS kernel in the repos, which you
> can have installed exactly for things like this.

While writing that I knew somebody would read it in strict interpretation mode.
s/no space/not enough space in \/boot to matter/

> There is also the matter of automagic bootloader configuration change to
> support that, not to mention people that use efistub to boot their
> system, how do you propose to handle that?

If you have installed archlinux, it's reasonable to expect that one knows
how to configure this.

>> If this is a regression you will have to post dmesg. If you don't see
>> errors/warnings, then kernel developers would usually ask to enable
>> debug flags for printing more information during boot.
>>
>> That said, I have one old machine with a Core2Duo and GM4xx and
>> ever since DRM's atomic modesetting was introduced in 4.2, I can
>> only use 4.1 warning free. Regressions do happen but you had no
>> warnings or errors in 4.8 so yours looks like a different regression.
>>
>
> If you don't report the bugs upstream they don't get fixed, if you have
> reported it and no one got around to take a look at it then fine,
> otherwise don't be lazy and report those bugs and help get them fixed.

I did report it and it's been written off as "why do you care about the new
warning/stacktrace?". Given that I didn't bother trying to convince the
DRM devs of the importance since I don't have a RHEL or SLES support
contract I pay for.