Discussion:
Getting freeze on early start with linux 4.9-1 kernel.
(too old to reply)
fredbezies via arch-general
2016-12-23 12:59:34 UTC
Permalink
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)

Thanks!
--
Frederic Bezies
***@gmail.com
Carsten Mattner via arch-general
2016-12-23 13:58:03 UTC
Permalink
On Fri, Dec 23, 2016 at 1:59 PM, fredbezies via arch-general
Post by fredbezies via arch-general
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,
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.

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.
Mauro Santos via arch-general
2016-12-23 14:17:36 UTC
Permalink
Post by Carsten Mattner via arch-general
On Fri, Dec 23, 2016 at 1:59 PM, fredbezies via arch-general
Post by fredbezies via arch-general
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,
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.

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?
Post by Carsten Mattner via arch-general
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.
--
Mauro Santos
Bennett Piater
2016-12-23 14:31:50 UTC
Permalink
Post by Mauro Santos via arch-general
There is an LTS kernel in the repos, which you
can have installed exactly for things like this.
Exactly. I never actually needed it, but I have linux-lts installed and
configured in systemd-boot for cases like this.
Keeping old kernels around doesn't solve more than this does, *and*
opens up more security issues.

I even remember to test that every now and then :)

Cheers,
Bennett
--
GPG fingerprint: 871F 1047 7DB3 DDED 5FC4 47B2 26C7 E577 EF96 7808
Carsten Mattner via arch-general
2016-12-24 14:14:52 UTC
Permalink
On Fri, Dec 23, 2016 at 3:17 PM, Mauro Santos via arch-general
Post by Mauro Santos via arch-general
Post by Carsten Mattner via arch-general
On Fri, Dec 23, 2016 at 1:59 PM, fredbezies via arch-general
Post by fredbezies via arch-general
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,
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/
Post by Mauro Santos via arch-general
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.
Post by Mauro Santos via arch-general
Post by Carsten Mattner via arch-general
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.
Mauro Santos via arch-general
2016-12-24 15:33:22 UTC
Permalink
Post by Carsten Mattner via arch-general
On Fri, Dec 23, 2016 at 3:17 PM, Mauro Santos via arch-general
Post by Mauro Santos via arch-general
Post by Carsten Mattner via arch-general
On Fri, Dec 23, 2016 at 1:59 PM, fredbezies via arch-general
Post by fredbezies via arch-general
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,
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/
The kernel only might not take much space but you have to take into
account the initramfs images and kernel modules too. All together it
should amount to over 100MiB per kernel.

What other distros do is recommend a 1GB /boot or changing the
configuration to reduce the number of older kernels installed[1]. People
have complained about small libraries needing to be installed as being
wasteful, at a grand total 100MiB+ for each kernel that would start a
nice flamewar.
Post by Carsten Mattner via arch-general
Post by Mauro Santos via arch-general
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.
It is you who said "I wish arch would (like other distros) keep 2 or
three old kernel versions around" not me. Other distributions
automagically take care of updating the bootloader configuration, as
much would be expected of arch.

Some people already have trouble managing to update one kernel properly,
imagine the chaos it would be with more than one if manual steps were
involved, not to mention old kernels have _known_ security issues and
having old stuff around is not the Arch way.
Post by Carsten Mattner via arch-general
Post by Mauro Santos via arch-general
Post by Carsten Mattner via arch-general
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.
Then you've done your part and no one can fault you, if the drm devs
don't think it is a problem there isn't much you can do. That said, if
the only problem is seeing some spam in the output of dmesg I can
understand why they wouldn't give it top priority.


[1]
https://wiki.centos.org/Manuals/ReleaseNotes/CentOS7#head-281c090cc4fbc6bb5c7d4cd82a266fce807eee7c
--
Mauro Santos
Carsten Mattner via arch-general
2016-12-25 01:33:28 UTC
Permalink
On Sat, Dec 24, 2016 at 4:33 PM, Mauro Santos
Post by Mauro Santos via arch-general
Post by Carsten Mattner via arch-general
On Fri, Dec 23, 2016 at 3:17 PM, Mauro Santos via arch-general
Post by Mauro Santos via arch-general
Post by Carsten Mattner via arch-general
On Fri, Dec 23, 2016 at 1:59 PM, fredbezies via arch-general
Post by fredbezies via arch-general
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,
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/
The kernel only might not take much space but you have to take into
account the initramfs images and kernel modules too. All together it
should amount to over 100MiB per kernel.
What other distros do is recommend a 1GB /boot or changing the
configuration to reduce the number of older kernels installed[1]. People
have complained about small libraries needing to be installed as being
wasteful, at a grand total 100MiB+ for each kernel that would start a
nice flamewar.
Post by Carsten Mattner via arch-general
Post by Mauro Santos via arch-general
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.
It is you who said "I wish arch would (like other distros) keep 2 or
three old kernel versions around" not me. Other distributions
automagically take care of updating the bootloader configuration, as
much would be expected of arch.
Some people already have trouble managing to update one kernel properly,
imagine the chaos it would be with more than one if manual steps were
involved, not to mention old kernels have _known_ security issues and
having old stuff around is not the Arch way.
Fair point. My suggestion was of course for the default arch kernel
to have at least one alt version there as a fallback and I think one of old
LTS branches would make sense, if you don't happen to require 4.10
for AMD Ryzen or have a similar requirement.

Knowing that there's 4.1-lts or 3.18-lts in the boot menu that works
good enough to access the system and fix any boot issue with 4.9
is invaluable, if we stop suggesting to people to make small /boot
partitions. Unless you're in a constrained environment, it isn't
a big deal to allocate 2G for /boot and even 1G would be plenty
enough for one stable kernel and a fallback lts kernel as the
emergency boot option, plus more.

I have 4 different kernels, all with two initrds in a 256MB /boot
partition and still over 100MB free. The biggest initrds are the
fallback ones and those are around 20MB.

For one standard arch config kernel:
5MB vimage
8MB initrd
22MB initrd.fallback

35MB * 2 = 70MB.

With a 256 /boot partitition we can have two versions per
variant (linux, linux-old, linux-lts, linux-old) and still be good
in a constrained /boot.

It's less space needed than I thought.
Post by Mauro Santos via arch-general
Post by Carsten Mattner via arch-general
Post by Mauro Santos via arch-general
Post by Carsten Mattner via arch-general
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.
Then you've done your part and no one can fault you, if the drm devs
don't think it is a problem there isn't much you can do. That said, if
the only problem is seeing some spam in the output of dmesg I can
understand why they wouldn't give it top priority.
Xorg wasn't working properly and seeing stacktraces caused by
atomic modesetting regressions and those being brushed off as
warnings to ignore, either means their kprintf's are bad or they (Intel)
don't have a lab with all the supported GPU. It's one thing to stop
supporting a chip in a driver, but if you claim support it's important
not to regress. This is why people like RHEL and SLES and I
cannot blame them, but I think the better solution is that of a
stable ABI, where you limit the security potential just one old
driver, which is bad but not as bad as having to use a complete
old kernel not just one driver.
Eli Schwartz via arch-general
2016-12-26 02:54:32 UTC
Permalink
Post by Mauro Santos via arch-general
What other distros do is recommend a 1GB /boot or changing the
configuration to reduce the number of older kernels installed[1]. People
have complained about small libraries needing to be installed as being
wasteful, at a grand total 100MiB+ for each kernel that would start a
nice flamewar.
Well, we already expect people to take care of orphans themselves, and
nobody is suggesting old kernels *must* be kept around forever.
Post by Mauro Santos via arch-general
Post by Carsten Mattner via arch-general
Post by Mauro Santos via arch-general
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?
The blatantly obvious way would be with a dummy kernel package
containing a symlink to the vmlinuz/initramfs of the latest versioned
package. Old bootloader configurations don't care about how many new and
irrelevant files aren't being looked at.

If you want new bootloader entries to be automatically added in grub.cfg
then simply use a pacman hook to re-run grub-mkconfig -- I am sure
something similar can be easily done for syslinux/EFI.
You can also edit the boot cmdline from grub itself...
Post by Mauro Santos via arch-general
Post by Carsten Mattner via arch-general
If you have installed archlinux, it's reasonable to expect that one knows
how to configure this.
It is you who said "I wish arch would (like other distros) keep 2 or
three old kernel versions around" not me. Other distributions
automagically take care of updating the bootloader configuration, as
much would be expected of arch.
Some people already have trouble managing to update one kernel properly,
imagine the chaos it would be with more than one if manual steps were
involved, not to mention old kernels have _known_ security issues and
having old stuff around is not the Arch way.
What problems are people having with updating one kernel? Please
elaborate on your vagueness.

As for known security issues and keeping old stuff around, I could care
less about offering all kernels in the repos -- I just don't want my old
kernel to be uninstalled until I say so.

See http://bugs.archlinux.org/task/16702 for more details, but the basic
gist is that versioned kernel installs are a *good* thing, as opposed to
being forced to reboot every time your --sysupgrade includes the kernel
(which is what *I* would call not-very-Arch-way), and it is intended
that we will eventually get versioned kernels, and the fact that we
don't have that today is simply because it is low-priority and tpowa
hasn't gotten around to it yet.

(I am not entirely sure what the holdup is, though.)
--
Eli Schwartz
Doug Newgard
2016-12-26 04:56:13 UTC
Permalink
On Sun, 25 Dec 2016 21:54:32 -0500
Post by Eli Schwartz via arch-general
The blatantly obvious way would be with a dummy kernel package
containing a symlink to the vmlinuz/initramfs of the latest versioned
package. Old bootloader configurations don't care about how many new and
irrelevant files aren't being looked at.
If you want new bootloader entries to be automatically added in grub.cfg
then simply use a pacman hook to re-run grub-mkconfig -- I am sure
something similar can be easily done for syslinux/EFI.
You can also edit the boot cmdline from grub itself...
Symlinks won't work, as the filesystem of the ESP is generally FAT32. Trying to
automate adding it to bootloaders is also a bad thing, as Arch has no idea how
the user has set them up.
Mauro Santos via arch-general
2016-12-26 14:05:41 UTC
Permalink
Post by Eli Schwartz via arch-general
Post by Mauro Santos via arch-general
What other distros do is recommend a 1GB /boot or changing the
configuration to reduce the number of older kernels installed[1]. People
have complained about small libraries needing to be installed as being
wasteful, at a grand total 100MiB+ for each kernel that would start a
nice flamewar.
Well, we already expect people to take care of orphans themselves, and
nobody is suggesting old kernels *must* be kept around forever.
Post by Mauro Santos via arch-general
Post by Carsten Mattner via arch-general
Post by Mauro Santos via arch-general
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?
The blatantly obvious way would be with a dummy kernel package
containing a symlink to the vmlinuz/initramfs of the latest versioned
package. Old bootloader configurations don't care about how many new and
irrelevant files aren't being looked at.
If you want new bootloader entries to be automatically added in grub.cfg
then simply use a pacman hook to re-run grub-mkconfig -- I am sure
something similar can be easily done for syslinux/EFI.
You can also edit the boot cmdline from grub itself...
Automagic updates? No thank you. Stay away from my configuration files
and efi variables.
Post by Eli Schwartz via arch-general
Post by Mauro Santos via arch-general
Post by Carsten Mattner via arch-general
If you have installed archlinux, it's reasonable to expect that one knows
how to configure this.
It is you who said "I wish arch would (like other distros) keep 2 or
three old kernel versions around" not me. Other distributions
automagically take care of updating the bootloader configuration, as
much would be expected of arch.
Some people already have trouble managing to update one kernel properly,
imagine the chaos it would be with more than one if manual steps were
involved, not to mention old kernels have _known_ security issues and
having old stuff around is not the Arch way.
What problems are people having with updating one kernel? Please
elaborate on your vagueness.
Forgetting to reboot, which you address below and I have to agree that
as things are now they are not optimal. Forgetting to mount /boot and
all the "fun" stuff that every once in a while pops up in the forum.
Post by Eli Schwartz via arch-general
As for known security issues and keeping old stuff around, I could care
less about offering all kernels in the repos -- I just don't want my old
kernel to be uninstalled until I say so.
See http://bugs.archlinux.org/task/16702 for more details, but the basic
gist is that versioned kernel installs are a *good* thing, as opposed to
being forced to reboot every time your --sysupgrade includes the kernel
(which is what *I* would call not-very-Arch-way), and it is intended
that we will eventually get versioned kernels, and the fact that we
don't have that today is simply because it is low-priority and tpowa
hasn't gotten around to it yet.
(I am not entirely sure what the holdup is, though.)
--
Mauro Santos
fredbezies via arch-general
2016-12-23 15:42:11 UTC
Permalink
Post by Carsten Mattner via arch-general
On Fri, Dec 23, 2016 at 1:59 PM, fredbezies via arch-general
Post by fredbezies via arch-general
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,
[...]
Post by Carsten Mattner via arch-general
Does the fallback boot entry work?
No.
Post by Carsten Mattner via arch-general
Have you tried reinstalling the kernel?
Yes.

[...]
Post by Carsten Mattner via arch-general
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.
I wonder if there is any dmesg logged while booting on initramfs...
Will try to see anyway.
Post by Carsten Mattner via arch-general
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.
I wonder which option listed here is the culprit.

https://git.archlinux.org/svntogit/packages.git/commit/trunk?h=packages/linux&id=26d5f8c9110f0fca96a7ef05c235dd005b1049a7
--
Frederic Bezies
***@gmail.com
Genes Lists via arch-general
2016-12-23 18:24:17 UTC
Permalink
Post by fredbezies via arch-general
...
I opened a bug : https://bugs.archlinux.org/task/52246
I added a comment to your bug report. 
I have one computer which doesn't boot under 4.9 - this started with
4.9-RC1 ( i build and test all kernels) and still have same problem
with 4.9 final.

As I asked in your bug report, can you identify the processor as well.
Here is what I am seeing as of now - one Ivy Bridge laptop does not
boot.

Lenovo Laptop W540 Ivy Bridge i7-4700 MQ     - Boot Failed
Lenovo Laptop W520 Sandy Bridge i7-2720QM   - OK
Desktop Ivy Bridge I7-4770                - OK
Desktop Ivy Bridge i7-4790                 - OK
Desktop Ivy Bridge i7-4771                 - OK
Desktop Core i7 Lynnfield (860)              - OK
Desktop Ivy Bridge i7-4770K              - OK
Desktop Skylake i5-6260U                     - OK
(except i do have continued graphis Display port Problems - have to
reboot 1 - 10 times before it works - true in 4.8.x as well).

gene





-- 
Gene
***@sapience.com
Iru Cai via arch-general
2016-12-24 06:21:51 UTC
Permalink
Post by Genes Lists via arch-general
Post by fredbezies via arch-general
...
I opened a bug : https://bugs.archlinux.org/task/52246
I added a comment to your bug report.
I have one computer which doesn't boot under 4.9 - this started with
4.9-RC1 ( i build and test all kernels) and still have same problem
with 4.9 final.
As I asked in your bug report, can you identify the processor as well.
Here is what I am seeing as of now - one Ivy Bridge laptop does not
boot.
Lenovo Laptop W540 Ivy Bridge i7-4700 MQ - Boot Failed
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
i7-4xxx is Haswell, not Ivy Bridge.
Post by Genes Lists via arch-general
Lenovo Laptop W520 Sandy Bridge i7-2720QM - OK
Desktop Ivy Bridge I7-4770 - OK
Desktop Ivy Bridge i7-4790 - OK
Desktop Ivy Bridge i7-4771 - OK
Desktop Core i7 Lynnfield (860) - OK
Desktop Ivy Bridge i7-4770K - OK
Desktop Skylake i5-6260U - OK
(except i do have continued graphis Display port Problems - have to
reboot 1 - 10 times before it works - true in 4.8.x as well).
gene
--
Gene
Ralf Mardorf
2016-12-24 08:04:57 UTC
Permalink
Post by Iru Cai via arch-general
Post by Genes Lists via arch-general
Lenovo Laptop W540 Ivy Bridge i7-4700 MQ - Boot Failed
i7-4xxx is Haswell, not Ivy Bridge.
FWIW 4.9 does boot on an AMD machine, at least a self-build rt patched
4.9.

[***@archlinux ~]$ uname -a
Linux archlinux 4.9.0-rt1-1-rt-presonus #1 SMP PREEMPT RT Sat Dec 24 06:35:41 CET 2016 x86_64 GNU/Linux
[***@archlinux ~]$ grep 'model name' /proc/cpuinfo | head -1
model name : AMD Athlon(tm) X2 Dual Core Processor BE-2350

Happy holidays!
Ralf
Genes Lists via arch-general
2017-01-03 02:25:01 UTC
Permalink
Post by fredbezies via arch-general
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.
Please add to this bug report:

https://bugzilla.kernel.org/show_bug.cgi?id=191801
-- 
Gene
***@sapience.com

Continue reading on narkive:
Loading...