Bug#1060411: initramfs: can't boot bcachefs storage with multi devices
On Sun, Jan 28, 2024 at 11:06:53AM +0100, Steinar H. Gunderson wrote:
> I'm a bit unsure how this would work; unless you manually set
> rootfstype=bcachefs on the GRUB command line, I think this is autodetected
> from fstype (in klibc-utils), which doesn't understand bcachefs right now?
Evidently, blkid does, so that part is fine.
With the attached patch, and bcachefs-tools upgraded to a version with
mount.bcachefs included, I can boot with root=UUID= using a multi-device
filesystem. grub-mkconfig still errors out, though.
/* Steinar */
--
Homepage: https://www.sesse.net/
diff -Nru initramfs-tools-0.142/scripts/local initramfs-tools-0.142/scripts/local
--- initramfs-tools-0.142/scripts/local 2022-04-10 21:59:31.0 +0200
+++ initramfs-tools-0.142/scripts/local 2022-07-12 23:51:34.0 +0200
@@ -148,15 +148,30 @@
panic "No root device specified. Boot arguments must include a root= parameter."
fi
local_device_setup "${ROOT}" "root file system"
- ROOT="${DEV}"
# Get the root filesystem type if not set
if [ -z "${ROOTFSTYPE}" ] || [ "${ROOTFSTYPE}" = auto ]; then
- FSTYPE=$(get_fstype "${ROOT}")
+ FSTYPE=$(get_fstype "${DEV}")
else
FSTYPE=${ROOTFSTYPE}
fi
+ # If we have an UUID bcachefs mount, we must not set $ROOT to the real device,
+ # since the filesystem may be a multi-device filesystem. If so, we must keep
+ # the UUID= argument; mount.bcachefs will figure out what devices to include.
+ if [ "${FSTYPE}" = "bcachefs" ]; then
+ case "$ROOT" in
+ UUID=*)
+ ;;
+ *)
+ ROOT="${DEV}"
+ ;;
+ esac
+ else
+ # For all other filesystems, we resolve to the actual device.
+ ROOT="${DEV}"
+ fi
+
local_premount
if [ "${readonly?}" = "y" ]; then
Bug#1061662: fstype support for bcachefs
Package: klibc-utils
Version: 2.0.12-1
Severity: normal
Tags: upstream patch
Hi,
fstype should autodetect bcachefs, not the least because bcachefs filesystems
may require other treatment of UUID mounts (#1060411, #1061525). I've attached
a simple patch.
-- System Information:
Debian Release: 12.4
APT prefers stable-security
APT policy: (500, 'stable-security'), (500, 'stable-debug'), (500,
'proposed-updates'), (500, 'stable'), (1, 'experimental')
Architecture: amd64 (x86_64)
Foreign Architectures: i386
Kernel: Linux 6.7.0 (SMP w/56 CPU threads; PREEMPT)
Kernel taint flags: TAINT_WARN
Locale: LANG=en_DK.UTF-8, LC_CTYPE=en_DK.UTF-8 (charmap=UTF-8),
LANGUAGE=en_NO:en_US:en_GB:en
Shell: /bin/sh linked to /usr/bin/dash
Init: systemd (via /run/systemd/system)
Versions of packages klibc-utils depends on:
ii libklibc 2.0.12-1
klibc-utils recommends no packages.
klibc-utils suggests no packages.
-- debconf-show failed
Description:
TODO: Put a short summary on the line above and replace this paragraph
with a longer explanation of this change. Complete the meta-information
with other relevant fields (see below for details). To make it easier, the
information below has been extracted from the changelog. Adjust it or drop
it.
.
klibc (2.0.13-3) experimental; urgency=medium
.
* Install klibc shared library in /usr/lib
Author: Ben Hutchings
---
The information above should follow the Patch Tagging Guidelines, please
checkout https://dep.debian.net/deps/dep3/ to learn about the format. Here
are templates for supplementary fields that you might want to add:
Origin: (upstream|backport|vendor|other), (|commit:)
Bug:
Bug-Debian: https://bugs.debian.org/
Bug-Ubuntu: https://launchpad.net/bugs/
Forwarded: (no|not-needed|)
Applied-Upstream: , (|commit:)
Reviewed-By:
Last-Update: 2024-01-28
Index: klibc-2.0.13/usr/kinit/fstype/bcachefs_fs.h
===
--- /dev/null
+++ klibc-2.0.13/usr/kinit/fstype/bcachefs_fs.h
@@ -0,0 +1,20 @@
+#ifndef __BCACHEFS_FS_H
+#define __BCACHEFS_FS_H
+
+#define BCACHEFS_MAGIC \
+ {0xc6, 0x85, 0x73, 0xf6, 0x66, 0xce, 0x90, 0xa9, \
+0xd9, 0x6a, 0x60, 0xcf, 0x80, 0x3d, 0xf7, 0xef};
+
+/*
+ * Structure of the superblock
+ */
+struct bch_sb_layout {
+ __u8 magic[16]; /* bcachefs superblock UUID */
+ __u8 layout_type;
+ __u8 sb_max_size_bits; /* base 2 of 512 byte sectors */
+ __u8 nr_superblocks;
+ __u8 pad[5];
+ __le64 sb_offset[61];
+} __attribute__((packed));
+
+#endif /* __BCACHEFS_FS_H */
Index: klibc-2.0.13/usr/kinit/fstype/fstype.c
===
--- klibc-2.0.13.orig/usr/kinit/fstype/fstype.c
+++ klibc-2.0.13/usr/kinit/fstype/fstype.c
@@ -23,6 +23,7 @@
#define cpu_to_be32(x) __cpu_to_be32(x)/* Needed by romfs_fs.h */
+#include "bcachefs_fs.h"
#include "btrfs.h"
#include "cramfs_fs.h"
#include "ext2_fs.h"
@@ -161,6 +162,24 @@ static int ext2_image(const void *buf, u
return 0;
}
+static int bcachefs_image(const void *buf, unsigned long long *bytes)
+{
+ static const __u8 BCACHEFS_MAGIC_STRING[16] = BCACHEFS_MAGIC;
+ /* layout superblock starts at sector 7 */
+ const struct bch_sb_layout *sb =
+ (const struct bch_sb_layout *)((const char *)buf + 512);
+
+ if (memcmp(sb->magic, BCACHEFS_MAGIC_STRING,
+ sizeof(BCACHEFS_MAGIC_STRING)) == 0) {
+ /* Knowing the size of the filesystem can potentially
+ entail opening multiple devices and looking into their
+ superblocks */
+ *bytes = 0;
+ return 1;
+ }
+ return 0;
+}
+
static int reiserfs_image(const void *buf, unsigned long long *bytes)
{
const struct reiserfs_super_block *sb =
@@ -389,6 +408,7 @@ static struct imagetype images[] = {
{1, "minix", minix_image},
{1, "nilfs2", nilfs2_image},
{2, "ocfs2", ocfs2_image},
+ {3, "bcachefs", bcachefs_image},
{8, "reiserfs", reiserfs_image},
{64, "reiserfs", reiserfs_image},
{64, "reiser4", reiser4_image},
Bug#1060411: initramfs: can't boot bcachefs storage with multi devices
On Wed, Jan 10, 2024 at 09:34:18PM +0100, antonio wrote:
> The problem is in the file "/usr/share/initramfs-tools/scripts/functions" and
> depends on the "get_fstype" and "resolve_device" functions that cannot locate
> or determine the file system (since bcachefs uses the form
> device:device:device).
See also #1061525.
> get_fstype ()
> {
> + if [ "$ROOTFSTYPE" == "bcachefs" ]; then
> + FSTYPE="$ROOTFSTYPE"
> + echo "$ROOTFSTYPE"
> + return 0
> + fi
I'm a bit unsure how this would work; unless you manually set
rootfstype=bcachefs on the GRUB command line, I think this is autodetected
from fstype (in klibc-utils), which doesn't understand bcachefs right now?
/* Steinar */
--
Homepage: https://www.sesse.net/
Bug#911815: /usr/bin/perf_4.18: Please build perf against libbfd
On Thu, Sep 09, 2021 at 12:54:50PM +0200, Tony Garnock-Jones wrote: > Thanks, Steinar, for your suggestion! I've written a patch against the > non-libbfd code in perf to try it out. > > It works very well. What used to take endless minutes now takes a few > seconds. Thanks for doing this! I can confirm; I tested this on “perf report” against a perf.data with DWARF tracebacks, with perf 5.13.4 (the same file every time), and here are the results: non-bfd, without patch: 7m59s non-bfd, with patch: 15s bfd: 15s /* Steinar */ -- Homepage: https://www.sesse.net/
Bug#990165: perf: allow using other versions than the running kernel
Package: linux-base Version: 4.6 Severity: normal Tags: patch Hi, The perf wrapper script in Debian requires the perf binary of the running kernel. However, there's not really a good reason for this; perf has a stable ABI, and even though it's distributed and built with the kernel, you can freely mix and match versions (I've done so, a lot). There may still be reasons why people prefer to keep the versions matched, but perf shouldn't just give up and die if it can't find the right version. I've made a patch that makes this a bit more flexible; it first tries to find a matching version, and if it doesn't exist, it simply picks the newest one it can find. (If that's older than the kernel, it gives a warning, since there may be new features the user would want to upgrade for, but it doesn't die.) Hopefully this should be safe, while being a lot less annoying when running a newer or self-compiled kernel. :-) --- linux-base-4.6.orig/bin/perf2018-07-20 03:35:21.0 +0200 +++ linux-base-4.6/bin/perf 2021-06-22 00:15:59.618443368 +0200 @@ -10,9 +10,11 @@ ;; esac shopt -s execfail -exec "perf_$version" "$@" +if [ -x "/usr/bin/perf_$version" ]; then +exec "perf_$version" "$@" +fi -# Not found? Tell the user which package to install. +# Not found? Find out which version to install. case "$version" in 3.* | 4.0 | 4.0.*) package=linux-tools-$version @@ -21,5 +23,16 @@ package=linux-perf-$version ;; esac + +# See if we have a usable alternative available. +perfversion="$( linux-version sort --reverse $( echo /usr/bin/perf_* | sed "s,/usr/bin/perf_,,g" ) | head -n 1 )" +if [ -x "/usr/bin/perf_$perfversion" ]; then +if linux-version compare "$perfversion" lt "$version"; then +echo >&2 "W: perf_$perfversion is older than the running kernel, consider installing $package." +fi +exec "perf_$perfversion" "$@" +fi + +# Still nothing? Tell the user. echo >&2 "E: $package is not installed." exit 1 -- System Information: Debian Release: 11.0 APT prefers stable-debug APT policy: (500, 'stable-debug'), (500, 'testing'), (500, 'oldstable'), (1, 'experimental') Architecture: amd64 (x86_64) Foreign Architectures: i386 Kernel: Linux 5.12.8 (SMP w/40 CPU threads) Locale: LANG=en_DK.UTF-8, LC_CTYPE=en_DK.UTF-8 (charmap=UTF-8), LANGUAGE=en_NO:en_US:en_GB:en Shell: /bin/sh linked to /bin/dash Init: systemd (via /run/systemd/system) Versions of packages linux-base depends on: ii debconf [debconf-2.0] 1.5.75 linux-base recommends no packages. linux-base suggests no packages. -- debconf-show failed
Bug#986378: linux-image-5.10.0-5-amd64: please enable CONFIG_TLS
On Sun, Apr 04, 2021 at 06:33:43PM +0200, Steinar H. Gunderson wrote: > Please enable CONFIG_TLS=y (kTLS), so that we can get kernel-accelerated TLS > for compatible software (e.g. cubemap). It's been supported since 4.17, > so should be pretty mature by now. Correction: CONFIG_TLS=m is enough. The module is self-contained with no hooks unless you start enabling hardware acceleration etc. (I actually enabled kTLS on a buster machine that way, two days ago). /* Steinar */ -- Homepage: https://www.sesse.net/
Bug#986378: linux-image-5.10.0-5-amd64: please enable CONFIG_TLS
Package: src:linux Version: 5.10.26-1 Severity: wishlist Hi, Please enable CONFIG_TLS=y (kTLS), so that we can get kernel-accelerated TLS for compatible software (e.g. cubemap). It's been supported since 4.17, so should be pretty mature by now. /* Steinar */ -- Homepage: https://www.sesse.net/
Bug#911815: /usr/bin/perf_4.18: Please build perf against libbfd
On Fri, Oct 26, 2018 at 01:12:51AM +0100, Ben Hutchings wrote: > For future reference, that's the comment: > > # perf can link against libbfd if available, but the result is > # undistributable as they are licenced under GPL v2 and v3+ > # respectively. Override detection of libbfd and insist that > # cplus_demangle() can be found in libiberty (LGPL v2.1+). > > Tagging this wontfix since we can't fix that problem. But we can probably make the addr2line solution much faster? perf runs: scnprintf(cmd, sizeof(cmd), "addr2line -e %s %016"PRIx64, dso_name, addr); fp = popen(cmd, "r"); but the normal way of running addr2line is to run it and then start feeding it addresses on stdin (ie. don't start the program anew for each and every address we want to look up). I haven't tried, but it sounds like that would reduce overhead significantly? I also don't know if there's a cache somewhere in front of this? It seems to look up the same addresses over and over and over again, at least in my case (decoding a processor trace). /* Steinar */ -- Homepage: https://www.sesse.net/
Bug#918800: PROBLEM: USB 3.0 NIC operates only at USB 2.0 speed on Odroid HC1
merge 925167 918800 thanks On Sat, Apr 27, 2019 at 03:12:35PM +0200, Steinar H. Gunderson wrote: > Now I have; I rebuilt the Debian kernel with > > USB=y > USB_XHCI_HCD=y > CONFIG_USB_XHCI_PLATFORM=y > > and the NIC still comes up at 480M. So, no go. Correction: After a hard reset, it works. Even better, this patch makes it work also with everything as modules: https://marc.info/?l=linux-usb=155321315512949=2 and there's already a Debian bug for that, so merging. I've verified that this patch works for me (after a hard reset). Debian maintainers: This is a tiny little patch; would you be willing to accept it for buster, so that ODROID users can get unhampered speeds? (There's some big.LITTLE stuff that still keeps it back in some scenarios, but this gets my iperf on XU4 to 620 Mbit/sec output and 920 Mbit/sec input.) /* Steinar */ -- Homepage: https://www.sesse.net/
Bug#918800: PROBLEM: USB 3.0 NIC operates only at USB 2.0 speed on Odroid HC1
On Wed, Apr 24, 2019 at 01:25:54PM +0200, Steinar H. Gunderson wrote: > I have the same problem with the ODROID XU4, which also includes a dwc3 and > an 8152 (it's probably dwc3-specific; the driver has been problematic > before). I haven't checked whether CONFIG_USB_XHCI_PLATFORM=y helps, though. Now I have; I rebuilt the Debian kernel with USB=y USB_XHCI_HCD=y CONFIG_USB_XHCI_PLATFORM=y and the NIC still comes up at 480M. So, no go. /* Steinar */ -- Homepage: https://www.sesse.net/
Bug#918800: PROBLEM: USB 3.0 NIC operates only at USB 2.0 speed on Odroid HC1
On Sat, Feb 02, 2019 at 01:39:06PM +0100, Benjamin Drung wrote: > The Odroid HC1 ARM board contains a JMicron JMS578 USB 3.0 to SATA > Bridge and a Realtek Gbps Ethernet device connected to an USB 3.0 host. > The SATA bridge works correctly at USB 3.0 speed, but the Ethernet > controller operates only at USB 2.0 speed. I tracked this behaviour down > to the CONFIG_USB_XHCI_PLATFORM kernel configuration. I have the same problem with the ODROID XU4, which also includes a dwc3 and an 8152 (it's probably dwc3-specific; the driver has been problematic before). I haven't checked whether CONFIG_USB_XHCI_PLATFORM=y helps, though. Linux liadroid 4.19.0-4-armmp-lpae #1 SMP Debian 4.19.28-2 (2019-03-15) armv7l GNU/Linux /: Bus 06.Port 1: Dev 1, Class=root_hub, Driver=xhci-hcd/1p, 5000M /: Bus 05.Port 1: Dev 1, Class=root_hub, Driver=xhci-hcd/1p, 480M |__ Port 1: Dev 2, If 0, Class=Vendor Specific Class, Driver=r8152, 480M /: Bus 04.Port 1: Dev 1, Class=root_hub, Driver=xhci-hcd/1p, 5000M |__ Port 1: Dev 2, If 0, Class=Hub, Driver=hub/2p, 5000M /: Bus 03.Port 1: Dev 1, Class=root_hub, Driver=xhci-hcd/1p, 480M |__ Port 1: Dev 2, If 0, Class=Hub, Driver=hub/2p, 480M /: Bus 02.Port 1: Dev 1, Class=root_hub, Driver=exynos-ohci/3p, 12M /: Bus 01.Port 1: Dev 1, Class=root_hub, Driver=exynos-ehci/3p, 480M /* Steinar */ -- Homepage: https://www.sesse.net/
Bug#843448: linux-image-4.8.0-1-armmp-lpae: fails to boot on Odroid-Xu4 with rootfs on USB
On Wed, Sep 06, 2017 at 11:24:27PM -0700, Vagrant Cascadian wrote: >> One of them was running 4.11, and didn't seem any better or worse. > And updated to testing on 4.12.10 on one of the boards... > > Any progress getting these patches upstream? ...and on getting them into a stretch point release? It's really the only thing that's missing for completely plain stretch on these boards. :-) /* Steinar */ -- Homepage: https://www.sesse.net/
Bug#843448: linux-image-4.8.0-1-armmp-lpae: fails to boot on Odroid-Xu4 with rootfs on USB
On Sat, Jul 08, 2017 at 10:42:26AM +0200, Jochen Sprickerhof wrote: >> Don't you also want this? >> >> https://bugs.debian.org/cgi-bin/bugreport.cgi?att=1;bug=843448;filename=2166ffd004e04a61887eb2a39f8639dc12140c58-updated.diff;msg=75 > This is not needed to fix this bug. Well, you don't get working USB after a warm boot without it, do you? /* Steinar */ -- Homepage: https://www.sesse.net/
Bug#843448: linux-image-4.8.0-1-armmp-lpae: fails to boot on Odroid-Xu4 with rootfs on USB
On Sat, Jul 08, 2017 at 07:50:03AM +0200, Jochen Sprickerhof wrote: > For v4.9 the only patch needed is: > > https://bugs.debian.org/cgi-bin/bugreport.cgi?att=1;bug=843448;filename=0001-usb-dwc3-core-setup-phy-before-trying-to-read-from-i.patch;msg=97 Don't you also want this? https://bugs.debian.org/cgi-bin/bugreport.cgi?att=1;bug=843448;filename=2166ffd004e04a61887eb2a39f8639dc12140c58-updated.diff;msg=75 /* Steinar */ -- Homepage: https://www.sesse.net/
Bug#843448: linux-image-4.8.0-1-armmp-lpae: fails to boot on Odroid-Xu4 with rootfs on USB
On Fri, Jul 07, 2017 at 08:42:08PM +0200, Jochen Sprickerhof wrote: > I've created patches for v4.12 (applies to v4.11 as well) and git > master and send them to the subsystem maintainers. Would be great to see > them included in the Debian kernel as well. Thanks for doing this :-) I'd love to see this in a stretch point release so that we don't have to wait for buster to get XU4 support. (Granted, I've never tried d-i, but at least then I can rebuild my XU4 images.) /* Steinar */ -- Homepage: https://www.sesse.net/
Bug#843448: [jspri...@debian.org: Bug#843448: linux-image-4.8.0-1-armmp-lpae: fails to boot on Odroid-Xu4 with rootfs on USB]
On Mon, Jul 03, 2017 at 04:35:49PM +0200, Jochen Sprickerhof wrote: > thanks to the pointers, I've condensed the first patch (74b9605e) to the > attached one against 4.9. Can you verify that it works? > > I will try to port it to 4.11 and linux-next and post them. > > The second patch (2166ffd00-updated.diff) looks good for me, would be great to > see it in mainline. Did someone send it to the maintainers already? I've built latest 4.9.0 from stretch, plus your patch, plus 2166ffd00-updated.diff. It seems to boot on my XU4 with networking working just fine; unfortunately, I can't give it much more testing than that right now. /* Steinar */ -- Homepage: https://www.sesse.net/
Bug#843448: [jspri...@debian.org: Bug#843448: linux-image-4.8.0-1-armmp-lpae: fails to boot on Odroid-Xu4 with rootfs on USB]
On Mon, Jul 03, 2017 at 04:35:49PM +0200, Jochen Sprickerhof wrote: > thanks to the pointers, I've condensed the first patch (74b9605e) to the > attached one against 4.9. Can you verify that it works? I'll try to give it a shot, although I fear that I might not have the time before my XU4 goes down for transportation. :-) /* Steinar */ -- Homepage: https://www.sesse.net/
Bug#843448: update with both patches applied
On Sun, Jun 04, 2017 at 12:36:48PM +0100, Ben Hutchings wrote: >> Given that stretch release is in only a few weeks, time is running out for >> this bug. Is the general thought that the risk of breaking other boards is >> too great, or can we try to get these two patches into stretch to get XU4 >> working? > This has now missed stretch r0 but can still be fixed in a point > release. OK, so stretch is out :-) Should we try to hash out some sort of plan for getting this fixed in r1? My XU4 now has a problem-free month with this patch, so I believe any risk should be to other platforms. /* Steinar */ -- Homepage: https://www.sesse.net/
Bug#843448: update with both patches applied
On Tue, May 30, 2017 at 04:27:05PM +0800, gustavo panizzo wrote: > I've attached the second patch. updated, for others to try. Vagrant, can you > try this on your boards too? Given that stretch release is in only a few weeks, time is running out for this bug. Is the general thought that the risk of breaking other boards is too great, or can we try to get these two patches into stretch to get XU4 working? /* Steinar */ -- Homepage: https://www.sesse.net/
Bug#843448: linux-image-4.8.0-1-armmp-lpae: fails to boot on Odroid-Xu4 with rootfs on USB
On Sun, May 28, 2017 at 12:38:12AM +0800, gustavo panizzo wrote: > NIC works right away, I have to cold boot to see the USB3 hard > drives. > The only kernel that worked reliably after reboot was 4.5.5-1 Have you tried to apply the other patch, too? It's supposedly helping with this very problem. (I haven't tried the USB3 external ports, really.) /* Steinar */ -- Homepage: https://www.sesse.net/
Bug#843448: linux-image-4.8.0-1-armmp-lpae: fails to boot on Odroid-Xu4 with rootfs on USB
On Sat, May 27, 2017 at 08:57:00AM -0700, Vagrant Cascadian wrote: > Of course, the BeagleBoard-X15 isn't using USB for anything, so this > isn't much of a test, but it's the only other board I have available > that uses dwc3. I suppose you could plug a device into it, even if there's nothing onboard connected to it? I don't know the board, but from pictures and specs, it seems to have multiple USB 3.0 ports. /* Steinar */ -- Homepage: https://www.sesse.net/
Bug#843448: linux-image-4.8.0-1-armmp-lpae: fails to boot on Odroid-Xu4 with rootfs on USB
On Wed, May 24, 2017 at 11:37:36PM +0200, Steinar H. Gunderson wrote: > Well, it's a revert of something that's supposed to only be a > cleanup/refactor (but isn't, presumably due to phy bugs). So it _should_ be > safe, at least in theory. > > FWIW, after a bit over two hours, this happened: > > [ 7912.391226] usb 4-1: new SuperSpeed USB device number 2 using xhci-hcd > [ 7912.413744] usb 4-1: New USB device found, idVendor=05e3, idProduct=0616 > [ 7912.413752] usb 4-1: New USB device strings: Mfr=1, Product=2, > SerialNumber=0 > [ 7912.413758] usb 4-1: Product: USB3.0 Hub > [ 7912.413764] usb 4-1: Manufacturer: GenesysLogic > [ 7912.417680] hub 4-1:1.0: USB hub found > [ 7912.417989] hub 4-1:1.0: 2 ports detected 72 hours uptime now, with no more ill effects. NIC works fine. /* Steinar */ -- Homepage: https://www.sesse.net/
Bug#843448: linux-image-4.8.0-1-armmp-lpae: fails to boot on Odroid-Xu4 with rootfs on USB
On Wed, May 24, 2017 at 02:15:46PM -0700, Vagrant Cascadian wrote: >> In any case, it essentially takes the system from “totally broken” to “might >> have some problems”. Would you consider taking it in for stretch, so that the >> XU4 has networking? I'll keep running with this kernel to get more >> experience. > Unfortunately, there are numerous other boards using dwc3, so I'm not > sure this is a good idea... Well, it's a revert of something that's supposed to only be a cleanup/refactor (but isn't, presumably due to phy bugs). So it _should_ be safe, at least in theory. FWIW, after a bit over two hours, this happened: [ 7912.391226] usb 4-1: new SuperSpeed USB device number 2 using xhci-hcd [ 7912.413744] usb 4-1: New USB device found, idVendor=05e3, idProduct=0616 [ 7912.413752] usb 4-1: New USB device strings: Mfr=1, Product=2, SerialNumber=0 [ 7912.413758] usb 4-1: Product: USB3.0 Hub [ 7912.413764] usb 4-1: Manufacturer: GenesysLogic [ 7912.417680] hub 4-1:1.0: USB hub found [ 7912.417989] hub 4-1:1.0: 2 ports detected This might be the issue of warm USB3 boot the other patch talked about? (I don't have any devices connected to the external ports, so I don't really know whether they work. I just want the NIC :-) ) /* Steinar */ -- Homepage: https://www.sesse.net/
Bug#843448: linux-image-4.8.0-1-armmp-lpae: fails to boot on Odroid-Xu4 with rootfs on USB
On Sun, May 14, 2017 at 04:08:56PM +0200, Steinar H. Gunderson wrote: > I've verified that this fails on my XU4 in both Debian 4.9 and 4.11, > as well as upstream 4.12-rc1 (haven't tried 4.10, probably doesn't work). > The discussion says this broke in 4.8. The bisect pointed to a patch, which > has a partial revert here: > > https://lkml.org/lkml/2016/10/16/63 > > They seem too hackish to go into upstream, though. I checked out ODROID's own 4.9 tree, and it works fine (tested for a few days). So I diffed drivers/usb/dwc3/, and these are the only two patches that actually are missing that I can see: https://github.com/hardkernel/linux/commit/74b9605e5587b30912d6b6093e9d7fb06d043c33 https://github.com/hardkernel/linux/commit/2166ffd004e04a61887eb2a39f8639dc12140c58 The second doesn't apply cleanly, and I don't understand the commit message anyway (does it only matter if dwc3 is _not_ built as a module?), but the former seems safe enough to apply. Given that it's been in their tree since 2016, it also would seem to have received a fair amount of user testing. I've applied the former patch (the revert) on top of Debian's 4.9.25 kernel (linux-image-4.9.0-3-armmp-lpae), and it boots with working USB and thus networking on my XU4. I saw this at some point after boot, though: [ 550.087389] xhci-hcd xhci-hcd.5.auto: Cannot set link state. [ 550.087426] usb usb6-port1: cannot disable (err = -32) In any case, it essentially takes the system from “totally broken” to “might have some problems”. Would you consider taking it in for stretch, so that the XU4 has networking? I'll keep running with this kernel to get more experience. /* Steinar */ -- Homepage: https://www.sesse.net/
Bug#843448: linux-image-4.8.0-1-armmp-lpae: fails to boot on Odroid-Xu4 with rootfs on USB
On Sun, Nov 13, 2016 at 04:21:30AM +, Ben Hutchings wrote: > This message (from the core hub driver) looks important: > > 2016-11-06_17:33:29.19077 [7.510995] usb usb3-port1: connect-debounce > failed > > The device tree source for Exynos 5422 was changed between 4.7 and 4.8 > so some of the USB definitions could be shared with the 5410 (commit > cb0896562228703209644e92926ed445150cc594). This obviously shouldn't > have a functional difference to the 5422 but maybe it did? There was some discussion upstream, but with no definitive conclusion: https://lkml.org/lkml/2016/8/28/183 I've verified that this fails on my XU4 in both Debian 4.9 and 4.11, as well as upstream 4.12-rc1 (haven't tried 4.10, probably doesn't work). The discussion says this broke in 4.8. The bisect pointed to a patch, which has a partial revert here: https://lkml.org/lkml/2016/10/16/63 They seem too hackish to go into upstream, though. This bug unfortunately makes the XU4 pretty useless, since the NIC is hooked up over USB. 4.7 works, but has no security support anymore (final release was 4.7.10, in October 2016). /* Steinar */ -- Homepage: https://www.sesse.net/
Bug#823552: [PATCH] dwc3-exynos: Fix deferred probing storm.
On Fri, May 27, 2016 at 04:26:42PM +0300, Felipe Balbi wrote: >> Sent. As a fix, there's a chance it could go into 4.7, right? > yup, shouldn't be a problem. But only after v4.7-rc1 is tagged. Seemingly v4.7-rc1 is out today (I was surprised at how quick that was). /* Steinar */ -- Homepage: https://www.sesse.net/
Bug#824941: linux-image-4.5.0-2-armmp-lpae: please enable PWM for ODROID boards
On Sun, May 29, 2016 at 01:45:49PM +0100, Ben Hutchings wrote: >> Perhaps you can enlighten me on an issue: Why don't we simply enable all >> modules? > - It's a waste of build time and a waste of disk space > - Some modules conflict with each other at run-time > - A few modules are experimental, and could even damage hardware Thanks for the information. /* Steinar */ -- Homepage: https://www.sesse.net/
Bug#824941: linux-image-4.5.0-2-armmp-lpae: please enable PWM for ODROID boards
On Sun, May 29, 2016 at 01:45:10PM +0900, Roger Shimizu wrote: > Thanks for your suggestion! > It will be included in next sid kernel. Thanks! Perhaps you can enlighten me on an issue: Why don't we simply enable all modules? One would think that if there's a driver somewhere, it would actually be useful to someone, as opposed to one user having to dig through for each board in existence and file bugs to enable kernel support. /* Steinar */ -- Homepage: https://www.sesse.net/
Bug#824941: linux-image-4.5.0-2-armmp-lpae: please enable PWM for ODROID boards
On Sat, May 21, 2016 at 04:41:47PM +0200, Steinar H. Gunderson wrote: > I also no longer get errors about LEDs not being able to get a PWM line. For the sake of completeness: This also means that the heartbeat LED actually works (as soon as the right module is loaded). So double win. /* Steinar */ -- Homepage: https://www.sesse.net/
Bug#823552: Cloning to initramfs-tools
clone 823552 -1 reassign -1 initramfs-tools retitle -1 initramfs-tools: Must include I2C drivers when MODULES=most severity -1 normal found -1 0.125 thanks Hi, I'm splitting off an initramfs-tools bug from this kernel bug, since seemingly what caused this not to be an issue in jessie was that initramfs-tools included the I²C drivers (which caused the regulator to come up much earlier, since it hangs off of the I²C bus). The kernel issue should still be fixed, but so should initramfs-tools. So: initramfs-tools needs to include I²C drivers, since it wants to include regulator drivers. The driver I was missing (i2c-exynos5) is in kernel/drivers/i2c/busses, but I think kernel/drivers/i2c might be the right granularity to include? /* Steinar */ -- Homepage: https://www.sesse.net/
Bug#823552: [PATCH] dwc3-exynos: Fix deferred probing storm.
On Fri, May 27, 2016 at 04:12:59PM +0300, Felipe Balbi wrote: > yes, please do that. Keep in mind, also, that we're still in the middle > of the merge window and nothing will really happen until v4.7-rc1 is > tagged. Sent. As a fix, there's a chance it could go into 4.7, right? /* Steinar */ -- Homepage: https://www.sesse.net/
Bug#823552: [PATCH] dwc3-exynos: Fix deferred probing storm.
On Fri, May 27, 2016 at 03:23:35PM +0530, Vivek Gautam wrote: > I don't have any concerns with the patch apart from the ones > Krzysztof has already pointed out. > LGTM. Should I repost the patch, or will people just make these commit message changes for me? I guess balbi@ is the right person to review and merge, since he maintains the driver. /* Steinar */ -- Homepage: https://www.sesse.net/
Bug#823552: [PATCH] Re: Endless "supply vcc not found, using dummy regulator"
On Fri, May 27, 2016 at 03:02:48PM +0530, Vivek Gautam wrote: > Above mentioned patches were not accepted by the maintainers of generic-phy > and usb. I couldn't get any response on them for quite a long time. So, the > patches could never make it to the mainline. > I can try initiating the entire exercise once again and try to get them > merged. That would be nice; having USB3 speeds is certainly attractive. > AFA dwc3-exynos is concerned, there's definitely a resource leak as > pointed out by you. > Please post the suggested patch, adding required people in CC. http://www.spinics.net/lists/linux-usb/msg141385.html Is there anyone I should have Cc-ed that I didn't? /* Steinar */ -- Homepage: https://www.sesse.net/
Bug#823552: [PATCH] Re: Endless "supply vcc not found, using dummy regulator"
On Wed, May 25, 2016 at 07:52:36PM +0200, Steinar H. Gunderson wrote: >> Actually their are some missing patches to tune the usb3 phy. >> >> https://lkml.org/lkml/2014/10/31/266 > This explains why the default networking speed refused to go above > ~300 Mbit/sec! What happened to the patches, I wonder? Adding Vivek in case he knows. They certainly don't apply anymore, at least. /* Steinar */ -- Homepage: https://www.sesse.net/
Bug#823552: [PATCH] Re: Endless "supply vcc not found, using dummy regulator"
On Wed, May 25, 2016 at 05:46:51PM +0530, Anand Moon wrote: > Actually their are some missing patches to tune the usb3 phy. > > https://lkml.org/lkml/2014/10/31/266 This explains why the default networking speed refused to go above ~300 Mbit/sec! What happened to the patches, I wonder? /* Steinar */ -- Homepage: https://www.sesse.net/
Bug#823552: [PATCH] Re: Endless "supply vcc not found, using dummy regulator"
On Tue, May 24, 2016 at 05:53:34PM +0200, Krzysztof Kozlowski wrote:
> exynos->clk = devm_clk_get(dev, "usbdrd30");
> if (IS_ERR(exynos->clk)) {
> + // On each error path since here we need to
> + // revert work done by dwc3_exynos_register_phys()
> dev_err(dev, "couldn't get clock\n");
> return -EINVAL;
> }
> clk_prepare_enable(exynos->clk);
OK, so I took Mark's advice and moved the phy instantiation towards the end
of the function (after the regulators have successfully come up). It reduced
the number of probes, even with the original initramfs, dramatically, so
it seems to work quite well. It also reduces the text for each deferred probe
by a lot, since we no longer have the dummy regulator message for each one
(only the message about “no suspend clk specified” is left). Finally, this
arrangement reduced the need for extra error handling to a minimum.
Cc-ing Felipe and and linux-usb@, and adding the patch as a reply to this
message.
/* Steinar */
--
Homepage: https://www.sesse.net/
Bug#823552: [PATCH] dwc3-exynos: Fix deferred probing storm.
dwc3-exynos has two problems during init if the regulators are slow
to come up (for instance if the I2C bus driver is not on the initramfs)
and return probe deferral. First, every time this happens, the driver
leaks the USB phys created; they need to be deallocated on error.
Second, since the phy devices are created before the regulators fail,
this means that there's a new device to re-trigger deferred probing,
which causes it to essentially go into a busy loop of re-probing the
device until the regulators come up.
Move the phy creation to after the regulators have succeeded, and also
fix cleanup on failure. On my ODROID XU4 system (with Debian's initramfs
which doesn't contain the I2C driver), this reduces the number of probe
attempts (for each of the two controllers) from more than 2000 to eight.
Reported-by: Steinar H. Gunderson <sgunder...@bigfoot.com>
Signed-off-by: Steinar H. Gunderson <se...@google.com>
---
drivers/usb/dwc3/dwc3-exynos.c | 19 +++
1 file changed, 11 insertions(+), 8 deletions(-)
diff --git a/drivers/usb/dwc3/dwc3-exynos.c b/drivers/usb/dwc3/dwc3-exynos.c
index dd5cb55..2f1fb7e 100644
--- a/drivers/usb/dwc3/dwc3-exynos.c
+++ b/drivers/usb/dwc3/dwc3-exynos.c
@@ -128,12 +128,6 @@ static int dwc3_exynos_probe(struct platform_device *pdev)
platform_set_drvdata(pdev, exynos);
- ret = dwc3_exynos_register_phys(exynos);
- if (ret) {
- dev_err(dev, "couldn't register PHYs\n");
- return ret;
- }
-
exynos->dev = dev;
exynos->clk = devm_clk_get(dev, "usbdrd30");
@@ -183,20 +177,29 @@ static int dwc3_exynos_probe(struct platform_device *pdev)
goto err3;
}
+ ret = dwc3_exynos_register_phys(exynos);
+ if (ret) {
+ dev_err(dev, "couldn't register PHYs\n");
+ goto err4;
+ }
+
if (node) {
ret = of_platform_populate(node, NULL, NULL, dev);
if (ret) {
dev_err(dev, "failed to add dwc3 core\n");
- goto err4;
+ goto err5;
}
} else {
dev_err(dev, "no device node, failed to add dwc3 core\n");
ret = -ENODEV;
- goto err4;
+ goto err5;
}
return 0;
+err5:
+ platform_device_unregister(exynos->usb2_phy);
+ platform_device_unregister(exynos->usb3_phy);
err4:
regulator_disable(exynos->vdd10);
err3:
--
2.8.0.rc3.226.g39d4020
Bug#823552: Endless "supply vcc not found, using dummy regulator"
On Tue, May 24, 2016 at 05:53:34PM +0200, Krzysztof Kozlowski wrote:
>> Which devm_clk_get() error are you talking about? The one with susp_clk?
> Now I saw your original report on Debian bugzilla. Let's stick to v4.5.
I'm actually developing on 4.6, but sure. The differences are small from what
I can see.
> exynos->clk = devm_clk_get(dev, "usbdrd30");
> if (IS_ERR(exynos->clk)) {
> + // On each error path since here we need to
> + // revert work done by dwc3_exynos_register_phys()
> dev_err(dev, "couldn't get clock\n");
> return -EINVAL;
> }
> clk_prepare_enable(exynos->clk);
OK, sounds like these should be changed to the common goto pattern to save on
the repeated cleanup. I'll have a stab at that later today.
>> That's an interesting case because a) nothing actually uses susp_clk
>> (it's dead code, presumably waiting for further patches),
> It does not look like dead code because it is enabled.
But not a single DT seems to set such a suspend clock, from what I can see?
> Yeah, but you did not send it to appropriate people. get_maintainer.pl
> will point you (Felipe Balbi handles the patches for this driver).
Ack.
> Apparently the s2mps11 regulator driver can be built as module... but is
> not a commonly tested configuration. In our testing configs (exynos and
> multi_v7) it is built-in. Actually most of PMICs are built in.
I don't have a lot of control over how Debian chooses to build kernels --
from what I gather from previous conversations, the kernel team are unhappy
about building things into the kernel if they can be modules. And in this
case, it wasn't even about the s2mps11 module, it was just that it didn't
have an I2C bus ready for init.
/* Steinar */
--
Homepage: https://www.sesse.net/
Bug#823552: Endless "supply vcc not found, using dummy regulator"
On Tue, May 24, 2016 at 05:06:43PM +0200, Krzysztof Kozlowski wrote: > I looked quickly through the thread and I am not sure what is exactly > your problem. My immediate problem is that the repeated (deferred) probing is causing so much logging that the system doesn't actually boot. The root causes are a bit more complex and muddy (see my previous email for a breakdown). > I understood that the Exynos dwc3 driver is leaking the > PHY. That is a good catch but your patch is not sufficient. You should > clean up starting from devm_clk_get() error. Unless you are fixing > this for different kernel version. I have zero idea how all of this is supposed to be connected, much less how DWC3 works or what the driver is supposed to do. I'm just an end user trying to figure out why my system didn't boot. :-) Which devm_clk_get() error are you talking about? The one with susp_clk? That's an interesting case because a) nothing actually uses susp_clk (it's dead code, presumably waiting for further patches), and b) there was a commit not too long ago (42f69a02) upgrading the message from dev_dbg to dev_info for reasons I don't understand, making the problem worse. (The commit message had an argument that I could accept for changing _to_ dbg, but not the other way round.) > Please send an appropriate separate patch for fixing this. Your email > did not reach people, I think. I only sent one patch so far, namely the leak fix. > What other problems exactly do you have? Late binding of S2MPS11 > regulator driver? That does not look like a problem. If it is built as > a module then it should be loaded, probably from initramfs because > these are regulators. In this specific case, Debian's initramfs has neglected to include the i2c driver in the initramfs, so the regulator doesn't come up until the boot is out of the initramfs. That's probably a bug in its own right, and fixing it reduces the amount of messages by a _lot_, but even so, it sounds to me like the kernel should be able to boot without that fix. /* Steinar */ -- Homepage: https://www.sesse.net/
Bug#823552: Endless "supply vcc not found, using dummy regulator"
On Mon, May 23, 2016 at 05:24:55PM +0100, Mark Brown wrote: >>> Cc-ing Mark in case he has any insights (I hope I have the right email >>> address). > But nobody who works on probe deferral or made any of the suggestions I > mentioned in the message you linked to, nor anyone who works on the > driver you've identified a bug in... :( As for the former, I have no idea who they would be, sorry. For the latter, isn't linux-samsung-soc@ the right place? MAINTAINERS said it was. >> So fixing initramfs-tools to include the driver will seemingly fix (or maybe >> more work around) the huge amounts of spam, but this is still a larger issue >> that needs resolving. > Not really, the issue you're seeing is just a plain resource leak in the > driver that happens to blow up worse than normal in your particular > configuration. This isn't even something related to probe deferral at > the regulator level, the core is complaining that your system > description is buggy as it has omitted some of the supplies for the > device (notice how it says "using dummy regulator"...). This is > happening a lot as the DWC3 driver is leaking, it is happening at all > because when the Exynos DWC3 integration creates it PHYs it doesn't map > the supplies through to them (it should be registering a supply alias to > do this). So there are multiple issues in play here. First of all, the leak is bad, but it doesn't affect the issue with the system not booting. If I set loglevel=0, it boots with or without the leak patch; however, it still sends a gazillion error lines to dmesg (with or without the deferral). Second, there's the issue that the driver takes so long to load in the first place. This is because the regulator isn't up and doesn't come up before after initramfs is done. This is a bug in Debian's initramfs-tools, but hopefully easily remedied. Then, there's the issue of why the messages come for each deferred probe attempt. It seems from your message this is about something in the declaration of the device tree; I don't understand the nuances here, but I suppose it's pretty easy? Fourth, there's the question of why there are thousands of probe attempts; it shouldn't be even if the regulator takes a long time to come up. I guess this is what your original message was about, and fixing that would also reduce the amount of logging a ton (plus presumably speed up boot by wasting less CPU on repeated probing). But as I understand you, it's not strictly necessary to actually fix this issue? Fifth and finally, there's the question of whether we can suppress diagnostics on a probe that ends up being deferred. It would also solve the problem here, although perhaps less elegantly than fixing issues #3 or #4 (or to a lesser degree, #2), either of which will make my system boot. :-) > The patch you linked to was for a completely different error message > which is at least related to probe deferral Yes, it's a different error message, but points to the same issue as #4 above, no? > though fundamentally unless > we just stop printing diagnostics (which is getting more and more > tempting to be honest) I'm not sure anything is going to fully resolve > leaks like this, the best chance you've got is something that explicitly > looks at the dependencies like Raphael was proposing. What do you mean by “leaks” here? /* Steinar */ -- Homepage: https://www.sesse.net/
Bug#823552: Endless "supply vcc not found, using dummy regulator"
On Mon, May 23, 2016 at 03:47:37PM +0200, Steinar H. Gunderson wrote: > I don't understand entirely why it tries 2000+ times before it succeeds Now I do; the initramfs doesn't include i2c-exynos5, and before that is loaded, s2mps11 (the regulator) can't come up either. So fixing initramfs-tools to include the driver will seemingly fix (or maybe more work around) the huge amounts of spam, but this is still a larger issue that needs resolving. /* Steinar */ -- Homepage: https://www.sesse.net/
Bug#823552: Endless "supply vcc not found, using dummy regulator"
On Sat, May 21, 2016 at 04:43:08PM +0200, Steinar H. Gunderson wrote: > I still have this problem. > > I've noticed that somehow, there's a huge amount of USB PHYs being > autodetected; > probably related to this issue. > > sesse@soldroid:~$ ls -ld /sys/devices/platform/usb_phy* | wc -l > 4288 I've tracked this down partially. It has to do with probe deferral; for whatever reason, the vdd33 regulator isn't available when the dwc3 driver comes up, and this causes the probe to defer. For each and every such deferral, these messages are printed by the regulator subsystem as part of things attempted probed before vdd33. I don't understand entirely why it tries 2000+ times before it succeeds, but then I don't understand probe deferral very well to begin with. I also don't know if there's a way to avoid these messages for each time, but it seems this is a common problem: https://lkml.org/lkml/2016/3/16/269 In this case, it's not just an annoyance, though; they're so many that they keep the system from booting unless loglevel is turned down. Cc-ing Mark in case he has any insights (I hope I have the right email address). The reason for the huge amount of PHYs is that the driver doesn't clean them up on failure (including probe deferral), so they leak. This is easy to fix; I'm attaching a small fix below. >From 6df2ebcbaae74577d49dbbc41e28d52084a124b0 Mon Sep 17 00:00:00 2001 From: "Steinar H. Gunderson" <se...@google.com> Date: Mon, 23 May 2016 15:44:37 +0200 Subject: [PATCH 1/1] dwc3-exynos: Clean up phys on probe failure. Otherwise, they would leak, which is especially bad given probe deferral (one could end up with thousands of dead phys after a normal boot) Signed-off-by: Steinar H. Gunderson <se...@google.com> --- drivers/usb/dwc3/dwc3-exynos.c | 2 ++ 1 file changed, 2 insertions(+) diff --git a/drivers/usb/dwc3/dwc3-exynos.c b/drivers/usb/dwc3/dwc3-exynos.c index dd5cb55..4104ef5 100644 --- a/drivers/usb/dwc3/dwc3-exynos.c +++ b/drivers/usb/dwc3/dwc3-exynos.c @@ -202,6 +202,8 @@ err4: err3: regulator_disable(exynos->vdd33); err2: + platform_device_unregister(exynos->usb2_phy); + platform_device_unregister(exynos->usb3_phy); clk_disable_unprepare(exynos->axius_clk); clk_disable_unprepare(exynos->susp_clk); clk_disable_unprepare(exynos->clk); /* 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 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, 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
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
Bug#824941: linux-image-4.5.0-2-armmp-lpae: please enable PWM for ODROID boards
Package: src:linux Version: 4.5.3-2 Severity: wishlist Hi again, I've been diffing upstream's .config file against Debian's armmp config, and I found a setting that I'd like you to include: CONFIG_PWM_SAMSUNG=m CONFIG_SENSORS_PWM_FAN=m With these two together, my ODROID-XU4 no longer spins its fan continuously. I also no longer get errors about LEDs not being able to get a PWM line. -- 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/4 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
Bug#824435: please enable CONFIG_EXYNOS_VIDEO
On Mon, May 16, 2016 at 07:29:46PM +0100, Ben Hutchings wrote: >> ccache is probably a good idea. I ended up mostly just cp-ing the merged >> config from /boot, so I could do with just building one kernel instead of >> multiple ones. > Oh, of course there is: > https://kernel-handbook.alioth.debian.org/ch-common-tasks.html#s4.2.5 Ah, nice, thanks. But seemingly I don't need ccache when I'm building with make-kpkg (ie., explicit .config); the build system figures out by itself what needs to be recompiled and what doesn't. /* Steinar */ -- Homepage: https://www.sesse.net/
Bug#824435: please enable CONFIG_EXYNOS_VIDEO
On Mon, May 16, 2016 at 07:14:15PM +0100, Ben Hutchings wrote: >> On a guess, the relevant parts would probably be >> >> CONFIG_EXYNOS_VIDEO=m >> CONFIG_EXYNOS_MIPI_DSI=m > That still won't work. OK, that's everything under that heading. >> CONFIG_DRM_EXYNOS=m >> CONFIG_DRM_EXYNOS_MIXER=y [not in that config, but _HDMI depends on it] >> CONFIG_DRM_EXYNOS_FIMD=y >> CONFIG_DRM_EXYNOS_DSI=y >> CONFIG_DRM_EXYNOS_DP=y >> CONFIG_DRM_EXYNOS_HDMI=y >> CONFIG_PHY_EXYNOS_MIPI_VIDEO=m >> CONFIG_PHY_EXYNOS_DP_VIDEO=m > OK, I'll add these. Great. >> There are also power management settings that I believe might be useful >> (not related to display): >> >> CONFIG_DEVFREQ_EVENT_EXYNOS_PPMU=y > We don't enable CONFIG_PM_DEVFREQ_EVENT yet so this won't work. OK. >> CONFIG_ARM_EXYNOS_CPUIDLE=y > OK. Seemingly Exynos5422 wants CONFIG_ARM_BIG_LITTLE_CPUIDLE=y (exynos-cpuidle is only for other boards), but it doesn't boot for me if I enable it. > If you're changing the configuration, you'll need to use a cross- > compiler and/or ccache. ccache is probably a good idea. I ended up mostly just cp-ing the merged config from /boot, so I could do with just building one kernel instead of multiple ones. /* Steinar */ -- Homepage: https://www.sesse.net/
Bug#824435: please enable CONFIG_EXYNOS_VIDEO
On Mon, May 16, 2016 at 02:43:06PM +0200, Steinar H. Gunderson wrote: > CONFIG_ARM_EXYNOS_CPUIDLE=y seems to cause problems, so I turned that off. > Apart from that, setting the variables above on 4.6.0 gives me wonderful > fbcon on the XU4. Scratch that, the culprit was CONFIG_ARM_BIG_LITTLE_CPUIDLE=y. CONFIG_ARM_EXYNOS_CPUIDLE=y doesn't have issues from what I can see. However, /sys/devices/system/cpu/cpuidle/current_driver says “none”, so perhaps it's a noop on this platform. I'd probably leave it out for now. /* Steinar */ -- Homepage: https://www.sesse.net/
Bug#824435: please enable CONFIG_EXYNOS_VIDEO
On Mon, May 16, 2016 at 11:14:26AM +0200, Steinar H. Gunderson wrote: > On a guess, the relevant parts would probably be > > CONFIG_EXYNOS_VIDEO=m > CONFIG_EXYNOS_MIPI_DSI=m > CONFIG_DRM_EXYNOS=m > CONFIG_DRM_EXYNOS_MIXER=y [not in that config, but _HDMI depends on it] > CONFIG_DRM_EXYNOS_FIMD=y > CONFIG_DRM_EXYNOS_DSI=y > CONFIG_DRM_EXYNOS_DP=y > CONFIG_DRM_EXYNOS_HDMI=y > CONFIG_PHY_EXYNOS_MIPI_VIDEO=m > CONFIG_PHY_EXYNOS_DP_VIDEO=m > > There are also power management settings that I believe might be useful > (not related to display): > > CONFIG_DEVFREQ_EVENT_EXYNOS_PPMU=y > CONFIG_ARM_EXYNOS_CPUIDLE=y > > and I guess also > > CONFIG_EXYNOS_ADC=m CONFIG_ARM_EXYNOS_CPUIDLE=y seems to cause problems, so I turned that off. Apart from that, setting the variables above on 4.6.0 gives me wonderful fbcon on the XU4. /* Steinar */ -- Homepage: https://www.sesse.net/
Bug#824435: please enable CONFIG_EXYNOS_VIDEO
On Mon, May 16, 2016 at 01:44:38AM +0100, Ben Hutchings wrote: > That has no useful effect, as it is a boolean option that only enables > a menu of further options. > > Please explain what changes are really needed. Hm. I was trying to compile a kernel to verify this, but it took more than overnight to build the packages... This is ODROID's XU4 4.2 tree config: https://github.com/tobetter/linux/blob/39fb8734966df320584f8c186652cec831e90054/arch/arm/configs/odroidxu4_defconfig On a guess, the relevant parts would probably be CONFIG_EXYNOS_VIDEO=m CONFIG_EXYNOS_MIPI_DSI=m CONFIG_DRM_EXYNOS=m CONFIG_DRM_EXYNOS_MIXER=y [not in that config, but _HDMI depends on it] CONFIG_DRM_EXYNOS_FIMD=y CONFIG_DRM_EXYNOS_DSI=y CONFIG_DRM_EXYNOS_DP=y CONFIG_DRM_EXYNOS_HDMI=y CONFIG_PHY_EXYNOS_MIPI_VIDEO=m CONFIG_PHY_EXYNOS_DP_VIDEO=m There are also power management settings that I believe might be useful (not related to display): CONFIG_DEVFREQ_EVENT_EXYNOS_PPMU=y CONFIG_ARM_EXYNOS_CPUIDLE=y and I guess also CONFIG_EXYNOS_ADC=m I can try compiling a kernel with all of those set and see if I get any more video, but if you have any tricks to make dpkg-buildpackage go faster for kernel builds, please let me know :-) /* Steinar */ -- Homepage: https://www.sesse.net/
Bug#824435: please enable CONFIG_EXYNOS_VIDEO
Package: linux-image-4.5.0-2-armmp-lpae Version: 4.5.3-2 Severity: wishlist Hi, The ODROID XU3/XU4 run linux-image-4.5.0-2-armmp-lpae quite well (barring cpufreq and proper big.LITTLE support), but there's no video output support, only serial console. Would you please consider setting CONFIG_EXYNOS_VIDEO=m in debian/config/armhf/config.armmp? Thanks! -- System Information: Debian Release: 8.4 APT prefers stable APT policy: (750, 'stable'), (500, 'proposed-updates') Architecture: amd64 (x86_64) Foreign Architectures: i386 Kernel: Linux 4.4.0 (SMP w/40 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)
Bug#823552: endless "supply vcc not found, using dummy regulator"
On Thu, May 05, 2016 at 11:29:18PM +0200, Steinar H. Gunderson wrote: > I'm installing an ODROID XU4 (Exynos 5422-based). After upgrading it to sid > and > installing 4.5.0-2-armmp-lpae (and generating the uInitrd myself, and updating > boot.ini -- I'm not entirely sure if this can be done more automatically), the > serial console shows tens of thousands of these messages on boot: > > [ 47.161428] exynos-dwc3 usb@1200: no suspend clk specified > > [ 47.162811] usb_phy_generic.49646.auto supply vcc not found, using dummy > regulator > [ 47.163532] usb_phy_generic.49647.auto supply vcc not found, using dummy > regulator I've reproduced this on 4.6.0-rc7. Should I take it upstream, or are there still worries that this might be Debian-specific? /* Steinar */ -- Homepage: https://www.sesse.net/
Bug#823552: endless "supply vcc not found, using dummy regulator"
Package: linux-image-4.5.0-2-armmp-lpae Version: 4.5.2-1 Severity: normal Hi, I'm installing an ODROID XU4 (Exynos 5422-based). After upgrading it to sid and installing 4.5.0-2-armmp-lpae (and generating the uInitrd myself, and updating boot.ini -- I'm not entirely sure if this can be done more automatically), the serial console shows tens of thousands of these messages on boot: [ 47.161428] exynos-dwc3 usb@1200: no suspend clk specified [ 47.162811] usb_phy_generic.49646.auto supply vcc not found, using dummy regulator [ 47.163532] usb_phy_generic.49647.auto supply vcc not found, using dummy regulator They appear to go on forever, blocking boot -- until I set the log level to 0 to suppress them (using magic SysRq over the serial console), nothing else seems to happen on the machine. As a reference point, this did not happen with 4.4.0-0.bpo.1-armmp from jessie-backports, but I'm unsure if this is because of the kernel or due to something in the initramfs differing between jessie and sid.
Bug#622850: linux-2.6: Please enable Hyper-V drivers
On Fri, Apr 15, 2011 at 03:06:40PM +0200, Steinar H. Gunderson wrote: hv_netvsc. I'll see if the patch I linked to actually fixes the issue (Microsoft seems to claim it does): After a few days and some relatively high load, I can confirm 2.6.38 + that patch (hand-adjusted) works fine. /* Steinar */ -- Homepage: http://www.sesse.net/ -- To UNSUBSCRIBE, email to debian-kernel-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/20110426182850.ga13...@uio.no
Bug#622850: linux-2.6: Please enable Hyper-V drivers
Package: linux-2.6 Severity: wishlist Hi, I recently had the joy (?) of installing Debian in Microsoft's hypervisor, Hyper-V. While the hypervisor is non-free (like e.g. VMware), the Linux kernel contains free host drivers that greatly increase functionality (e.g., you can access raw devices, have drives larger than 128GB, you get networking access without going through an emulated 100Mbit/sec card, you get heartbeat functionality to the hypervisor, etc.). They currently exist in the staging tree, and have been there since 2.6.32 or thereabouts. /* Steinar */ -- Homepage: http://www.sesse.net/ -- To UNSUBSCRIBE, email to debian-kernel-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/20110415080448.ga7...@uio.no
Bug#622850: linux-2.6: Please enable Hyper-V drivers
On Fri, Apr 15, 2011 at 01:14:08PM +0100, Ben Hutchings wrote: They currently exist in the staging tree, and have been there since 2.6.32 or thereabouts. They are truly worthy of the 'crap' label though. Sure, but they are much better than nothing. Currently I'm having issues that the network card is hanging under load (also in 2.6.38)... Do you know if anybody cares about bug reports should I file them upstream? It might be worth backporting the current versions to 'squeeze', but I don't think it would be a good idea to enable the versions in 2.6.32. Mm, well, my question is for sid, I guess. /* Steinar */ -- Homepage: http://www.sesse.net/ -- To UNSUBSCRIBE, email to debian-kernel-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/20110415121704.gb8...@uio.no
Bug#622850: linux-2.6: Please enable Hyper-V drivers
On Fri, Apr 15, 2011 at 02:17:04PM +0200, Steinar H. Gunderson wrote: Sure, but they are much better than nothing. Currently I'm having issues that the network card is hanging under load (also in 2.6.38)... Do you know if anybody cares about bug reports should I file them upstream? OK, to answer my own question there: https://launchpadlibrarian.net/68558231/ms-hv.patch reportedly fixes this (it's a known issue). Patch from upstream, as Microsoft is trying to get these drivers out of staging. /* Steinar */ -- Homepage: http://www.sesse.net/ -- To UNSUBSCRIBE, email to debian-kernel-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/20110415130055.gc8...@uio.no
Bug#622850: linux-2.6: Please enable Hyper-V drivers
On Fri, Apr 15, 2011 at 01:43:27PM +0100, Ben Hutchings wrote: Which driver, hv_netvsc or the one for the emulated hardware (whatever that is)? Anyway, bug reports against the current upstream version should go upstream. hv_netvsc. I'll see if the patch I linked to actually fixes the issue (Microsoft seems to claim it does): We don't usually expect people to upgrade the kernel to get new hardware support. If these drivers are so useful then they ought to be in squeeze. Well, yes, if you're adding new stuff to squeeze I'd say a backport of the 2.6.38 drivers would be excellent. You basically can't run Debian in Hyper-V except as a toy without them (and debian-installer with out-of-tree modules is a pain). /* Steinar */ -- Homepage: http://www.sesse.net/ -- To UNSUBSCRIBE, email to debian-kernel-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/20110415130640.ga8...@uio.no
Re: Bug#598803: xserver-xorg-video-intel: X crashes / hung gpu, now and then
found 598803 2:2.13.0-2 found 598803 2:2.13.901-2 thanks On Wed, Oct 06, 2010 at 01:51:03AM +0200, Steinar H. Gunderson wrote: ...at least until I tried to watch http://www.youtube.com/watch?v=INqbAWnbstI in Chrome with HTML5 enabled. That killed all of X, and when starting up again the exact same urxvt rendering issues were back. :-/ I would just add that I'm still seeing this, also with the version from experimental, and with kernel 2.6.37-rc1. Every time I visit any page with HTML5 video (any YouTube page, any Vimeo page) in Chrome, my GPU hangs and I have to reboot to get proper graphics back. Every other player works fine, though, including the very same pages via Flash. /* Steinar */ -- Homepage: http://www.sesse.net/ -- To UNSUBSCRIBE, email to debian-kernel-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/20101120195751.ga12...@uio.no
Re: Bug#598803: xserver-xorg-video-intel: X crashes / hung gpu, now and then
On Sun, Oct 03, 2010 at 12:24:24AM +0200, Steinar H. Gunderson wrote: Upgrading to 2.13.0 makes it work just fine for me. ...at least until I tried to watch http://www.youtube.com/watch?v=INqbAWnbstI in Chrome with HTML5 enabled. That killed all of X, and when starting up again the exact same urxvt rendering issues were back. :-/ /* Steinar */ -- Homepage: http://www.sesse.net/ -- To UNSUBSCRIBE, email to debian-kernel-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/20101005235103.ga25...@uio.no
Re: Bug#598803: xserver-xorg-video-intel: X crashes / hung gpu, now and then
On Sat, Oct 02, 2010 at 06:07:51PM +0200, Cesare Leonardi wrote: Hello Steinar, can you tell us what's your chipset? 00:02.0 VGA compatible controller: Intel Corporation Mobile 945GM/GMS, 943/940GML Express Integrated Graphics Controller (rev 03) It's a Dell Latitude D420, FWIW. /* Steinar */ -- Homepage: http://www.sesse.net/ -- To UNSUBSCRIBE, email to debian-kernel-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/20101002163114.gb7...@uio.no
Re: Bug#598803: xserver-xorg-video-intel: X crashes / hung gpu, now and then
On Sat, Oct 02, 2010 at 07:07:31PM +0200, Sven Joachim wrote: 00:02.0 VGA compatible controller: Intel Corporation Mobile 945GM/GMS, 943/940GML Express Integrated Graphics Controller (rev 03) I have the same one, and the HTML5 Youtube video you mentioned works fine in Chromium with Kernel 2.6.36-rc6, libdrm 2.4.22 and xserver-xorg-video-intel 2.13.0. Upgrading to 2.13.0 makes it work just fine for me. I also realize I selected a fantastic YouTube video to experiment with :-D To my defense, I hadn't actually seen it myself (after all, my GPU was hanging every time I tried). /* Steinar */ -- Homepage: http://www.sesse.net/ -- To UNSUBSCRIBE, email to debian-kernel-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/2010100424.gi7...@uio.no
Bug#409271: Status of this bug ?
On Sun, Aug 10, 2008 at 04:35:23PM +0200, Fabrice Lorrain wrote: I've just read through bts #409271 :initramfs-tools: NFSv4 not supported for root fs and I'm interrested in knowing the status of this bug for lenny. AFAIK my understanding is: klibc's mount doesn't support NFSv4, initramfs insists on using klibc's mount, stalemate. /* Steinar */ -- Homepage: http://www.sesse.net/ -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Bug#416098: kills my server on install
On Thu, Apr 26, 2007 at 08:14:57PM +0200, Bart Cortooms wrote: The fault is definitely with the RAID controller. I had the exact same problem on 4 Dell PE 2950's, triggered by munin and was able to solve it by upgrading the firmware on the RAID controllers. Hm. We upgraded the PERC firmware March 19th due to stability issues. The bug was filed March 24th. (The stability issues were fixed by the firmware upgrade, thankfully.) Image Versions In Flash: Boot Block Version : R.2.3.12 BIOS Version : MT28 MPT Version: MPTFW-00.10.47.00-IT FW Version : 1.03.10-0216 WebBIOS Version: 1.03-04 Ctrl-R Version : 1.04-017A Image Versions In Flash: Boot Block Version : R.2.3.2 BIOS Version : MT23 MPT Version: MPTFW-00.06.71.00-IT FW Version : 1.00.02-0163 WebBIOS Version: 1.01-021 Ctrl-R Version : 1.02-007 Hm. We might not have flashed with the most recent version, then? Where did you get your version from? /* Steinar */ -- Homepage: http://www.sesse.net/ -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Bug#382339: Dell Latitude D420 does not resume from suspend-to-RAM
Package: linux-image-2.6.17-1-686
Version: 2.6.17-5
Severity: normal
Tags: patch
Dell Latitude D420 does not resume properly from suspend-to-RAM -- this
works with 2.6.16 and current git head (around 2.6.18-rc4 somewhere),
but not with 2.6.17. The included patch was applied around 2.6.18-rc1,
and fixes the issue. (It's still not 100% reliable, probably due to
other suspend issues in the kernel since uswsusp was brand new in
2.6.17, but at least it works _usually_ instead of _never_.)
-- System Information:
Debian Release: testing/unstable
APT prefers unstable
APT policy: (500, 'unstable'), (500, 'testing'), (500, 'stable'), (1,
'experimental')
Architecture: i386 (i686)
Shell: /bin/sh linked to /bin/bash
Kernel: Linux 2.6.17-sesse
Locale: LANG=nb_NO.UTF-8, LC_CTYPE=nb_NO.UTF-8 (charmap=UTF-8)
Versions of packages linux-image-2.6.17-1-686 depends on:
ii initramfs-tools [linux-initra 0.73c tools for generating an initramfs
ii module-init-tools 3.2.2-3tools for managing Linux kernel mo
Versions of packages linux-image-2.6.17-1-686 recommends:
pn libc6-i686none (no description available)
-- debconf information:
linux-image-2.6.17-1-686/preinst/bootloader-initrd-2.6.17-1-686: true
linux-image-2.6.17-1-686/postinst/old-dir-initrd-link-2.6.17-1-686: true
linux-image-2.6.17-1-686/postinst/bootloader-test-error-2.6.17-1-686:
linux-image-2.6.17-1-686/postinst/old-initrd-link-2.6.17-1-686: true
linux-image-2.6.17-1-686/preinst/lilo-has-ramdisk:
linux-image-2.6.17-1-686/postinst/depmod-error-2.6.17-1-686: false
linux-image-2.6.17-1-686/prerm/removing-running-kernel-2.6.17-1-686: true
linux-image-2.6.17-1-686/preinst/overwriting-modules-2.6.17-1-686: true
linux-image-2.6.17-1-686/preinst/lilo-initrd-2.6.17-1-686: true
linux-image-2.6.17-1-686/preinst/failed-to-move-modules-2.6.17-1-686:
linux-image-2.6.17-1-686/postinst/create-kimage-link-2.6.17-1-686: true
linux-image-2.6.17-1-686/postinst/kimage-is-a-directory:
linux-image-2.6.17-1-686/postinst/old-system-map-link-2.6.17-1-686: true
linux-image-2.6.17-1-686/preinst/elilo-initrd-2.6.17-1-686: true
linux-image-2.6.17-1-686/preinst/already-running-this-2.6.17-1-686:
linux-image-2.6.17-1-686/preinst/abort-overwrite-2.6.17-1-686:
linux-image-2.6.17-1-686/postinst/bootloader-error-2.6.17-1-686:
linux-image-2.6.17-1-686/preinst/initrd-2.6.17-1-686:
linux-image-2.6.17-1-686/postinst/depmod-error-initrd-2.6.17-1-686: false
linux-image-2.6.17-1-686/preinst/abort-install-2.6.17-1-686:
linux-image-2.6.17-1-686/prerm/would-invalidate-boot-loader-2.6.17-1-686: true
commit 55b2355eefc2f160246226d4d69fed431173a4d5
author Shaohua Li [EMAIL PROTECTED] Fri, 23 Jun 2006 02:04:49 -0700
committer Linus Torvalds [EMAIL PROTECTED] Fri, 23 Jun 2006 07:43:00 -0700
[PATCH] don't use flush_tlb_all in suspend time
flush_tlb_all uses on_each_cpu, which will disable/enable interrupt.
In suspend/resume time, this will make interrupt wrongly enabled.
Signed-off-by: Shaohua Li [EMAIL PROTECTED]
Cc: Pavel Machek [EMAIL PROTECTED]
Signed-off-by: Andrew Morton [EMAIL PROTECTED]
Signed-off-by: Linus Torvalds [EMAIL PROTECTED]
diff --git a/arch/i386/kernel/acpi/sleep.c b/arch/i386/kernel/acpi/sleep.c
index 1cb2b18..4ee8357 100644
--- a/arch/i386/kernel/acpi/sleep.c
+++ b/arch/i386/kernel/acpi/sleep.c
@@ -8,30 +8,17 @@
#include linux/acpi.h
#include linux/bootmem.h
#include linux/dmi.h
+#include linux/cpumask.h
+
#include asm/smp.h
-#include asm/tlbflush.h
/* address in low memory of the wakeup routine. */
unsigned long acpi_wakeup_address = 0;
unsigned long acpi_video_flags;
extern char wakeup_start, wakeup_end;
-extern void zap_low_mappings(void);
-
extern unsigned long FASTCALL(acpi_copy_wakeup_routine(unsigned long));
-static void init_low_mapping(pgd_t * pgd, int pgd_limit)
-{
- int pgd_ofs = 0;
-
- while ((pgd_ofs pgd_limit)
- (pgd_ofs + USER_PTRS_PER_PGD PTRS_PER_PGD)) {
- set_pgd(pgd, *(pgd + USER_PTRS_PER_PGD));
- pgd_ofs++, pgd++;
- }
- flush_tlb_all();
-}
-
/**
* acpi_save_state_mem - save kernel state
*
@@ -42,7 +29,6 @@ int acpi_save_state_mem(void)
{
if (!acpi_wakeup_address)
return 1;
- init_low_mapping(swapper_pg_dir, USER_PTRS_PER_PGD);
memcpy((void *)acpi_wakeup_address, wakeup_start,
wakeup_end - wakeup_start);
acpi_copy_wakeup_routine(acpi_wakeup_address);
@@ -55,7 +41,6 @@ int acpi_save_state_mem(void)
*/
void acpi_restore_state_mem(void)
{
- zap_low_mappings();
}
/**
diff --git a/arch/i386/kernel/acpi/wakeup.S b/arch/i386/kernel/acpi/wakeup.S
index 7c74fe0..dcb4d3c 100644
--- a/arch/i386/kernel/acpi/wakeup.S
+++ b/arch/i386/kernel/acpi/wakeup.S
@@ -56,7 +56,7 @@ wakeup_code:
1:
# set up page table
- movl $swapper_pg_dir-__PAGE_OFFSET, %eax
+ movl $swsusp_pg_dir-__PAGE_OFFSET, %eax
movl %eax, %cr3
testl $1, real_efer_save_restore - wakeup_code
diff --git a/arch/i386/mm/init.c
Bug#381475: initramfs-tools: resume from hibernation broke after change to klibc resume
Package: initramfs-tools Version: 0.73 Severity: grave Justification: makes the package unsuitable for release in maintainer's opinion After upgrading from testing (0.69b) to unstable (0.73), resuming from hibernation no longer works -- it just boots as normal. Downgrading fixes the issue. -- Package-specific info: -- /proc/cmdline root=/dev/mapper/Debian-root ro resume=/dev/hda5 -- /proc/filesystems cramfs ext3 -- lsmod Module Size Used by ppp_deflate 5792 0 zlib_deflate 18616 1 ppp_deflate ppp_async 10720 1 crc_ccitt 2208 1 ppp_async ppp_generic25492 6 ppp_deflate,ppp_async slhc6496 1 ppp_generic i915 16384 1 drm61556 2 i915 rfcomm 33428 4 l2cap 21504 7 rfcomm ppdev 8516 0 parport_pc 32132 0 lp 10852 0 parport33160 3 ppdev,parport_pc,lp button 6544 0 ac 4836 0 battery 9188 0 ipv6 221760 12 cpufreq_ondemand7148 0 speedstep_centrino 7216 1 freq_table 4544 1 speedstep_centrino sbp2 20648 0 scsi_mod 123080 1 sbp2 loop 14888 0 joydev 8992 0 mousedev 10788 1 tsdev 7392 0 snd_hda_intel 17140 1 snd_hda_codec 125408 1 snd_hda_intel snd_pcm_oss35936 0 snd_mixer_oss 15872 1 snd_pcm_oss snd_pcm74500 3 snd_hda_intel,snd_hda_codec,snd_pcm_oss pcmcia 34012 0 snd_timer 20836 1 snd_pcm hw_random 5624 0 snd48100 8 snd_hda_intel,snd_hda_codec,snd_pcm_oss,snd_mixer_oss,snd_pcm,snd_timer intel_agp 21116 1 ipw3945 170752 0 soundcore 9216 1 snd hci_usb14740 3 agpgart29864 3 drm,intel_agp ieee80211 29256 1 ipw3945 ieee80211_crypt 5856 1 ieee80211 bluetooth 42884 7 rfcomm,l2cap,hci_usb i2c_i8018236 0 psmouse34600 0 yenta_socket 23884 1 snd_page_alloc 9512 2 snd_hda_intel,snd_pcm firmware_class 9696 2 pcmcia,ipw3945 i2c_core 19520 1 i2c_i801 serio_raw 6596 0 rsrc_nonstatic 11968 1 yenta_socket pcmcia_core37300 3 pcmcia,yenta_socket,rsrc_nonstatic eth139418052 0 evdev 9088 2 rtc12340 0 pcspkr 3040 0 ext3 118152 6 jbd50260 1 ext3 mbcache 8324 1 ext3 dm_mirror 18768 0 dm_snapshot15680 0 dm_mod 49976 8 dm_mirror,dm_snapshot ide_generic 1376 0 [permanent] ide_disk 15072 4 piix9476 0 [permanent] uhci_hcd 20392 0 ohci1394 30608 0 ieee1394 86584 3 sbp2,eth1394,ohci1394 tg392772 0 generic 4420 0 [permanent] ide_core 110888 4 ide_generic,ide_disk,piix,generic ehci_hcd 28008 0 usbcore 111616 4 hci_usb,uhci_hcd,ehci_hcd thermal12904 0 processor 25512 2 speedstep_centrino,thermal fan 4516 0 -- System Information: Debian Release: testing/unstable APT prefers unstable APT policy: (500, 'unstable'), (500, 'testing'), (500, 'stable'), (1, 'experimental') Architecture: i386 (i686) Shell: /bin/sh linked to /bin/bash Kernel: Linux 2.6.17-1-686 Locale: LANG=nb_NO.UTF-8, LC_CTYPE=nb_NO.UTF-8 (charmap=UTF-8) Versions of packages initramfs-tools depends on: ii busybox 1:1.1.3-2 Tiny utilities for small and embed ii cpio 2.6-16 GNU cpio -- a program to manage ar ii klibc-utils 1.4.11-3 small statically-linked utilities ii module-init-tools 3.2.2-3tools for managing Linux kernel mo ii udev 0.093-1/dev/ and hotplug management daemo initramfs-tools recommends no packages. -- no debconf information -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Bug#377024: nfs_common: nfs client crash nfs server? ; [TCP CHECKSUM INCORRECT]
On Fri, Jul 07, 2006 at 08:53:49PM +0200, [EMAIL PROTECTED] wrote: I just find a relation between the bad checksum and lenth: You are putting way too much weight on the checksum. Ethereal's idea of the outgoing checksum is _wrong_ when you have checksum offloading enabled (and you probably do), so this is irrelevant unless it's also happening to the _incoming_ packets. /* Steinar */ -- Homepage: http://www.sesse.net/ -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Bug#377024: nfs_common: nfs client crash nfs server? ; [TCP CHECKSUM INCORRECT]
On Fri, Jul 07, 2006 at 08:38:24PM +0200, [EMAIL PROTECTED] wrote: the checksum is bad: * with NFS and SMB over TCP, but not with telnet. * only in TCP blocks wich size (Len under ethereal) is not null Not surprising; remember that nfs and smbfs is handled by the kernel. I'm not surprised if it takes another path somehow. Moreover on another computer, without the upgrade, NFS seams to work with UDP instead of TCP! That's interesting; unfortunately, I know nothing about the kernel NFS code, so you'll have to take this up with the kernel people. /* Steinar */ -- Homepage: http://www.sesse.net/ -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Bug#368912: linux-2.6: missing debian/copyright information for Xen
Package: linux-2.6 Severity: important debian/copyright currently only lists the copyright, license and upstream URL for Linux proper. Given that Xen is now part of the package, its license (a BSD variant, which is GPL-compatible, but still), copyright and upstream URL (whatever that is) should also be included; at the very least the COPYING file from upstream should be included in the *-xen-* packages. -- System Information: Debian Release: testing/unstable APT prefers unstable APT policy: (500, 'unstable'), (500, 'testing') Architecture: amd64 (x86_64) Shell: /bin/sh linked to /bin/bash Kernel: Linux 2.6.16.11 Locale: LANG=en_DK.UTF-8, LC_CTYPE=en_DK.UTF-8 (charmap=UTF-8) -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Bug#364429: initramfs-tools: fails to boot with EVMS root
Package: initramfs-tools Version: 0.59b Severity: important Since I upgraded initramfs-tools from 0.53c - 0.59b (testing machine), new initramfs-es refuse to boot my EVMS root. The boot log is a little long to paste, but a summary follows: [boot] Loading, please wait... Begin: Loading essential drivers... [unix] Done. Begin: Running /scripts/init-premount ... [load sata, nic, etc.] Done. Begin: Mounting root file system... ... Begin: Running /scripts/local-top ... [load dm, md] Error returned from evms_open_engine(): No such file or directory mknod: sda: File exists mknod: sda1: File exists [repeat for all other drives and partitions] [start md0 and md1] Done. Begin: Waiting for root file system... ... At this point, it hangs forever. I'm actually not 100% sure what the EVMS error means, but AFAIK it can be related to a missing /var/lock. I can't, however, find anything in the initramfs-tools changelogs about that. Any ideas? -- System Information: Debian Release: testing/unstable APT prefers testing APT policy: (900, 'testing'), (500, 'unstable'), (500, 'stable'), (1, 'experimental') Architecture: i386 (x86_64) Shell: /bin/sh linked to /bin/bash Kernel: Linux 2.6.15.3 Locale: LANG=en_DK.UTF-8, LC_CTYPE=en_DK.UTF-8 (charmap=UTF-8) Versions of packages initramfs-tools depends on: ii busybox 1:1.01-4 Tiny utilities for small and embed ii cpio 2.6-11 GNU cpio -- a program to manage ar ii klibc-utils 1.2.4-1small statically-linked utilities ii module-init-tools 3.2.2-2tools for managing Linux kernel mo ii udev 0.089-1/dev/ and hotplug management daemo initramfs-tools recommends no packages. -- no debconf information -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Bug#357538: immediate cause of problem diagnosed
On Mon, Mar 27, 2006 at 01:55:53AM +0200, maximilian attems wrote: parse_numeric() is rudimentary lilo support of initramfs-tools. it should work now for most cases of usual block devices. my small test programm show that it is not able to parse correctly fe it translates that to 254 instead of 63 What did I miss here? Isn't 0xFE = 254? /* Steinar */ -- Homepage: http://www.sesse.net/ -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Bug#335230: More Code also Random, but less :-)
On Tue, Nov 01, 2005 at 10:55:35PM +0100, Marco Amadori wrote: - raid1: md0 active 2 out of 2 mirrors. maybe not mdamd, this runned fine... Could Steinar, the maintainer of evms, could help to clear us some things? You have two issues I can see from the previous information in the bug: - The swapfs plugin not loading. This is probably because you do not have /sbin/swapon (or /sbin/mkswap, I forget). You don't need the plugin for yaird, so you can simply ignore it. (Or perhaps not if you want to use swsusp?) - devfs_mk_dev: could not append to parent for md/0 This one is harder. Do you have a writable /dev? Could you check out /var/log/evms-engine.log? (evms_activate will create it if /var/log exists and is writable.) Give evms_activate -d 9 to increase the amount of logging if you still can't find it. /* Steinar */ -- Homepage: http://www.sesse.net/ -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Bug#336617: initramfs-tools: evms root is broken (forgets to load dm-mod.ko)
Package: initramfs-tools Version: 0.36 Severity: serious Just to have it in the BTS: dm-mod.ko is no longer in the initramfs, and thus /sbin/evms_activate fails. A simple manual_add_module dm_mod in the hooks/evms fragment fixes it (I've tested). -- System Information: Debian Release: testing/unstable APT prefers unstable APT policy: (500, 'unstable'), (1, 'experimental') Architecture: i386 (x86_64) Shell: /bin/sh linked to /bin/bash Kernel: Linux 2.6.14-rc5 Locale: LANG=en_DK.UTF-8, LC_CTYPE=en_DK.UTF-8 (charmap=UTF-8) -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Bug#336620: initramfs-tools: doesn't recognize jfs root
Package: initramfs-tools Severity: important The initramfs created by initramfs-tools checks for root filesystem type by doing eval $( fstype $ROOT ). However, fstype doesn't recognize JFS and returns unknown; which makes the initramfs try to modprobe unknown and then mount -t unknown $ROOT /root... This doesn't work. :-) -- System Information: Debian Release: testing/unstable APT prefers unstable APT policy: (500, 'unstable'), (1, 'experimental') Architecture: i386 (x86_64) Shell: /bin/sh linked to /bin/bash Kernel: Linux 2.6.14-rc5 Locale: LANG=en_DK.UTF-8, LC_CTYPE=en_DK.UTF-8 (charmap=UTF-8) -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Bug#335230: [#335230] How to actually support EVMS in an initrd
Just thought I'd take my EVMS maintainer hat on and try to add some constructive input to this: EVMS support in yaird should not be difficult to add for someone who already knows yaird. Basically, what you need to do is: - If root= is not /dev/evms/*, _do not do anything in the initrd_. If you do, you _will_ break root mounting for anybody _not_ using root on EVMS. - Make sure /dev/ is writable, and mkdir /dev/evms. - modprobe -q dm-mapper to load the devmapper module. You might also want to modprobe raid0/raid5 if the system in question needs that for /. - Run /sbin/evms_activate (from the “evms” package). It will do partition discovery and mknod the appropriate devices in /dev/evms. That's it :-) /* Steinar */ -- Homepage: http://www.sesse.net/ -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Bug#335230: [#335230] How to actually support EVMS in an initrd
On Sat, Oct 22, 2005 at 09:47:12PM +0200, Marco Amadori wrote: - Make sure /dev/ is writable, and mkdir /dev/evms. Translate this in perl plz :-) Well, the make sure part depends on how yaird works. You may have to mount a tmpfs over /dev/evms if the initrd is read-only. (This is during _boot_ time, BTW; running /sbin/evms_activate at yaird time will help you nothing.) - Run /sbin/evms_activate (from the “evms” package). It will do partition discovery and mknod the appropriate devices in /dev/evms. First if the root device is /dev/evms/lvm2 also vgchange -a y should be launched before that, right? No, that should not be required. You can use compatibility LVM2 volumes with EVMS without needing the traditional LVM userspace. BTW, I'm a bit unsure if critical is the right severity for this bug. /* Steinar */ -- Homepage: http://www.sesse.net/ -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Bug#328167: initrd-tools: completely broken with regard to LVM devices on EVMS
On Wed, Sep 14, 2005 at 01:12:15PM +0900, Horms wrote: first up you should know that we are currently trying really hard to kill mkinitrd in sid/etch. But initrd-tools is in Sarge, so I guess that means fixes are still important. I guess a fix for this would be out of scope for sarge. If /etc/mkinitrd/scripts/evms doesn't exist, should something else be run instead? Or is just removing the exit 1, as you suggest, sufficient? EVMS has its own probe.d script. OTOH, now that everything is up and working (I was trying to transition from LVM to EVMS) mkinitrd actually doesn't complain anymore; possibly since the probe.d script already sets ok=1 for the root volume, or something? I still believe the code is wrong, but perhaps the right fix is just to remove the check for /etc/mkinitrd/scripts/evms altogether... /* Steinar */ -- Homepage: http://www.sesse.net/ -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Bug#328167: initrd-tools: completely broken with regard to LVM devices on EVMS
Package: initrd-tools Version: 0.1.82 Severity: important When running mkinitrd, I get: [EMAIL PROTECTED]:~$ sudo mkinitrd -o /boot/initrd.img-2.6.12-1-amd64-k8-smp 2.6.12-1-amd64-k8-smp File descriptor 3 left open File descriptor 4 left open File descriptor 5 left open File descriptor 6 left open File descriptor 7 left open Finding all volume groups Finding volume group pannekake /usr/sbin/mkinitrd: /dev/evms/lvm2/pannekake/root: Cannot find LVM device Obviously, /dev/evms/lvm2/pannekake/root is managed by EVMS here, so it should not just see that /sbin/lvmiopversion exists and thus try to use the LVM userspace. Anyhow, I removed lvm-common as I don't need it, but still I get Unknown DM device 254:2 since it looks for /etc/mkinitrd/scripts/evms, which to the best of my knowledge is not in the evms packages anymore (evms has a probe.d script instead). Removing the exit 1 appears to give a valid initrd. -- System Information: Debian Release: testing/unstable APT prefers unstable APT policy: (500, 'unstable'), (1, 'experimental') Architecture: i386 (i686) Shell: /bin/sh linked to /bin/bash Kernel: Linux 2.6.11.8 Locale: LANG=en_DK.UTF-8, LC_CTYPE=en_DK.UTF-8 (charmap=UTF-8) Versions of packages initrd-tools depends on: ii coreutils [fileutils] 5.2.1-2.1 The GNU core utilities ii cpio 2.6-5 GNU cpio -- a program to manage ar ii cramfsprogs 1.1-6 Tools for CramFs (Compressed ROM F ii dash 0.5.2-7The Debian Almquist Shell ii fileutils 5.2.1-2.1 The GNU file management utilities ii util-linux2.12p-7Miscellaneous system utilities initrd-tools recommends no packages. -- debconf-show failed -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
