Bug#825026: linux-image-4.5.0-2-armmp-lpae: heartbeat triggered LEDs don't come up by default
Control: fixed -1 5.15-1~exp1 On Sun, 22 May 2016 17:23:08 +0200 "Steinar H. Gunderson" wrote: > Package: src:linux > Version: 4.5.3-2 > > My ODROID XU4 has a blue LED on it, which, after #824941 has been fixed, > is supposed to be a heartbeat LED, being solid-on during the bootloader > and then flashing when the OS is active. (The manual says so, and > “heartbeat” is the default mapping in the device tree for XU4.) > > However, Debian's kernel ships with CONFIG_LEDS_TRIGGER_HEARTBEAT=m, > which means this function doesn't work out of the box. As a workaround, > you can load the module manually (or put it in /etc/modules). I happen to have filed a similar bug #992184 which got fixed in 5.15-1~exp1, so I'm marking this bug as fixed with that version as well. signature.asc Description: This is a digitally signed message part.
Bug#825026: linux-image-4.5.0-2-armmp-lpae: heartbeat triggered LEDs don't come up by default
Control: tags -1 + moreinfo Hi Steiner, On Sun, May 22, 2016 at 09:42:38PM +0200, Steinar H. Gunderson wrote: > On Sun, May 22, 2016 at 08:10:18PM +0100, Ben Hutchings wrote: > > We build in code because we have to, not because it's merely useful. > > And here we're talking about modules that are useful for only a small > > proportion of armhf systems. > > Well, if you count number of device trees, it's about 110 devices out of > 741 (having heartbeat or default-on as policy). So it's a minority (at least > if you don't try to weight by number of sold devices, which would be much > harder), but not complete obscurity. > > Anyways, I'm not going to try to drive this; my ARM bug reports are already > being met with deafening silence on the Exynos list, so there's enough > frustration involved :-) It's far from the most important thing in the big > picture. Despite the above involved frustration, do you know if someone else did report the problem and/or you know the issue is not present anymore with a recent kernel (from unstable ideally or mainline)? Regards, Salvatore
Bug#825026: linux-image-4.5.0-2-armmp-lpae: heartbeat triggered LEDs don't come up by default
On Sun, May 22, 2016 at 09:42:38PM +0200, Steinar H. Gunderson wrote: > Well, if you count number of device trees, it's about 110 devices out of > 741 (having heartbeat or default-on as policy). So it's a minority (at least > if you don't try to weight by number of sold devices, which would be much > harder), but not complete obscurity. By the way, you might also want to consider taking out CONFIG_LEDS_TRIGGER_CPU; it has =y, but is used in only eight out of those 741 device trees. /* Steinar */ -- Homepage: https://www.sesse.net/
Bug#825026: linux-image-4.5.0-2-armmp-lpae: heartbeat triggered LEDs don't come up by default
On Sun, May 22, 2016 at 08:10:18PM +0100, Ben Hutchings wrote: > We build in code because we have to, not because it's merely useful. > And here we're talking about modules that are useful for only a small > proportion of armhf systems. Well, if you count number of device trees, it's about 110 devices out of 741 (having heartbeat or default-on as policy). So it's a minority (at least if you don't try to weight by number of sold devices, which would be much harder), but not complete obscurity. Anyways, I'm not going to try to drive this; my ARM bug reports are already being met with deafening silence on the Exynos list, so there's enough frustration involved :-) It's far from the most important thing in the big picture. /* Steinar */ -- Homepage: https://www.sesse.net/
Bug#825026: linux-image-4.5.0-2-armmp-lpae: heartbeat triggered LEDs don't come up by default
On Sun, 2016-05-22 at 21:01 +0200, Steinar H. Gunderson wrote: > On Sun, May 22, 2016 at 07:49:35PM +0100, Ben Hutchings wrote: > > > > The device tree already tells the kernel what trigger should be used, > > and the kernel can then make the decision whether that requires loading > > a module. > Does this mean the initramfs would also need to know that the module should > be included? I assume the kernel cannot re-trigger modules when switching > from initramfs to the real root. If the module is loaded based on a device's uevent, rather than a request_module() from the kernel, there is another chance to load it when udev is restarted. That's how most drivers get loaded! > > > > I disagree; it doesn't make sense to build in every trigger that might > > be needed. > Why not? They are small, and some would be useful even before loading > initramfs (although this would necessitate also having the PWM driver =y). We build in code because we have to, not because it's merely useful. And here we're talking about modules that are useful for only a small proportion of armhf systems. Ben. -- Ben Hutchings friends: People who know you well, but like you anyway. signature.asc Description: This is a digitally signed message part
Bug#825026: linux-image-4.5.0-2-armmp-lpae: heartbeat triggered LEDs don't come up by default
On Sun, May 22, 2016 at 07:49:35PM +0100, Ben Hutchings wrote: > The device tree already tells the kernel what trigger should be used, > and the kernel can then make the decision whether that requires loading > a module. Does this mean the initramfs would also need to know that the module should be included? I assume the kernel cannot re-trigger modules when switching from initramfs to the real root. > I disagree; it doesn't make sense to build in every trigger that might > be needed. Why not? They are small, and some would be useful even before loading initramfs (although this would necessitate also having the PWM driver =y). /* Steinar */ -- Homepage: https://www.sesse.net/
Bug#825026: linux-image-4.5.0-2-armmp-lpae: heartbeat triggered LEDs don't come up by default
Control: tag -1 upstream On Sun, 2016-05-22 at 17:23 +0200, Steinar H. Gunderson wrote: > Package: src:linux > Version: 4.5.3-2 > Severity: normal > > Hi, > > My ODROID XU4 has a blue LED on it, which, after # has been fixed, > is supposed to be a heartbeat LED, being solid-on during the bootloader > and then flashing when the OS is active. (The manual says so, and > “heartbeat” is the default mapping in the device tree for XU4.) > > However, Debian's kernel ships with CONFIG_LEDS_TRIGGER_HEARTBEAT=m, > which means this function doesn't work out of the box. As a workaround, > you can load the module manually (or put it in /etc/modules). I don't know of > a > way to have the device tree signal to the kernel that a given module should be > loaded The device tree already tells the kernel what trigger should be used, and the kernel can then make the decision whether that requires loading a module. > (and I don't know how that would interact with initramfs), but I haven't > looked too deeply. However, it should probably come up as soon as possible to > check that the bootloader actually managed to boot the kernel, and it's not > big (the .ko is ~9 kB), so it's probably best to just build it into the > kernel, > which is also what the Kconfig help text says. > > On a quick grep, it seems most of these LEDs in the device trees are mapped > to either cpu*, mmc, default-on or heartbeat. CPU is already built in > and MMC logically gets loaded along with the device, but always-on and > heartbeat are built as modules. > > So my guess would be that the kernel should have these changes: > > CONFIG_LEDS_TRIGGER_HEARTBEAT=y > CONFIG_LEDS_TRIGGER_DEFAULT_ON=y I disagree; it doesn't make sense to build in every trigger that might be needed. This is really a bug in the LED device core, not in our configuration. Ben. -- Ben Hutchings friends: People who know you well, but like you anyway. signature.asc Description: This is a digitally signed message part
Bug#825026: linux-image-4.5.0-2-armmp-lpae: heartbeat triggered LEDs don't come up by default
On Sun, May 22, 2016 at 05:23:08PM +0200, Steinar H. Gunderson wrote: > My ODROID XU4 has a blue LED on it, which, after # has been fixed, I meant #824941. /* Steinar */ -- Homepage: https://www.sesse.net/
Bug#825026: linux-image-4.5.0-2-armmp-lpae: heartbeat triggered LEDs don't come up by default
Package: src:linux Version: 4.5.3-2 Severity: normal Hi, My ODROID XU4 has a blue LED on it, which, after # has been fixed, is supposed to be a heartbeat LED, being solid-on during the bootloader and then flashing when the OS is active. (The manual says so, and “heartbeat” is the default mapping in the device tree for XU4.) However, Debian's kernel ships with CONFIG_LEDS_TRIGGER_HEARTBEAT=m, which means this function doesn't work out of the box. As a workaround, you can load the module manually (or put it in /etc/modules). I don't know of a way to have the device tree signal to the kernel that a given module should be loaded (and I don't know how that would interact with initramfs), but I haven't looked too deeply. However, it should probably come up as soon as possible to check that the bootloader actually managed to boot the kernel, and it's not big (the .ko is ~9 kB), so it's probably best to just build it into the kernel, which is also what the Kconfig help text says. On a quick grep, it seems most of these LEDs in the device trees are mapped to either cpu*, mmc, default-on or heartbeat. CPU is already built in and MMC logically gets loaded along with the device, but always-on and heartbeat are built as modules. So my guess would be that the kernel should have these changes: CONFIG_LEDS_TRIGGER_HEARTBEAT=y CONFIG_LEDS_TRIGGER_DEFAULT_ON=y -- System Information: Debian Release: stretch/sid APT prefers testing APT policy: (500, 'testing'), (1, 'experimental') Architecture: armhf (armv7l) Kernel: Linux 4.6.0 (SMP w/8 CPU cores) Locale: LANG=en_DK.UTF-8, LC_CTYPE=en_DK.UTF-8 (charmap=UTF-8) Shell: /bin/sh linked to /bin/dash Init: systemd (via /run/systemd/system) Versions of packages linux-image-4.5.0-2-armmp-lpae depends on: ii debconf [debconf-2.0] 1.5.59 ii initramfs-tools [linux-initramfs-tool] 0.125 ii kmod22-1.1 ii linux-base 4.0 Versions of packages linux-image-4.5.0-2-armmp-lpae recommends: ii firmware-linux-free 3.4 ii irqbalance 1.1.0-2 Versions of packages linux-image-4.5.0-2-armmp-lpae suggests: pn debian-kernel-handbook pn fdutils pn linux-doc-4.5 Versions of packages linux-image-4.5.0-2-armmp-lpae is related to: pn firmware-amd-graphics pn firmware-atheros pn firmware-bnx2 pn firmware-bnx2x pn firmware-brcm80211 pn firmware-cavium pn firmware-intel-sound pn firmware-intelwimax pn firmware-ipw2x00 pn firmware-ivtv pn firmware-iwlwifi pn firmware-libertas pn firmware-linux-nonfree pn firmware-misc-nonfree pn firmware-myricom pn firmware-netxen pn firmware-qlogic pn firmware-realtek pn firmware-samsung pn firmware-siano pn firmware-ti-connectivity pn xen-hypervisor -- no debconf information
