[Date Prev][Date Next] [Thread Prev][Thread Next] [Date Index] [Thread Index]

Bug#825026: marked as done (linux-image-4.5.0-2-armmp-lpae: heartbeat triggered LEDs don't come up by default)



Your message dated Sun, 27 Feb 2022 12:01:54 -0800 (PST)
with message-id <621bd8b2.1c69fb81.51bd8.030b@mx.google.com>
and subject line Closing this bug (BTS maintenance for src:linux bugs)
has caused the Debian Bug report #825026,
regarding linux-image-4.5.0-2-armmp-lpae: heartbeat triggered LEDs don't come up by default
to be marked as done.

This means that you claim that the problem has been dealt with.
If this is not the case it is now your responsibility to reopen the
Bug report if necessary, and/or fix the problem forthwith.

(NB: If you are a system administrator and have no idea what this
message is talking about, this may indicate a serious mail system
misconfiguration somewhere. Please contact owner@bugs.debian.org
immediately.)


-- 
825026: https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=825026
Debian Bug Tracking System
Contact owner@bugs.debian.org with problems
--- Begin Message ---
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  kmod                                    22-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  <none>
pn  fdutils                 <none>
pn  linux-doc-4.5           <none>

Versions of packages linux-image-4.5.0-2-armmp-lpae is related to:
pn  firmware-amd-graphics     <none>
pn  firmware-atheros          <none>
pn  firmware-bnx2             <none>
pn  firmware-bnx2x            <none>
pn  firmware-brcm80211        <none>
pn  firmware-cavium           <none>
pn  firmware-intel-sound      <none>
pn  firmware-intelwimax       <none>
pn  firmware-ipw2x00          <none>
pn  firmware-ivtv             <none>
pn  firmware-iwlwifi          <none>
pn  firmware-libertas         <none>
pn  firmware-linux-nonfree    <none>
pn  firmware-misc-nonfree     <none>
pn  firmware-myricom          <none>
pn  firmware-netxen           <none>
pn  firmware-qlogic           <none>
pn  firmware-realtek          <none>
pn  firmware-samsung          <none>
pn  firmware-siano            <none>
pn  firmware-ti-connectivity  <none>
pn  xen-hypervisor            <none>

-- no debconf information

--- End Message ---
--- Begin Message ---
Hi

This bug was filed for a very old kernel or the bug is old itself
without resolution.

If you can reproduce it with

- the current version in unstable/testing
- the latest kernel from backports

please reopen the bug, see https://www.debian.org/Bugs/server-control
for details.

Regards,
Salvatore

--- End Message ---

Reply to: