Bug#1029373: kernel panic on Odroid U2 with default environment
On Sat, Jan 21, 2023 at 17:46, Vagrant Cascadian
wrote:
On 2023-01-21, Joost van Zwieten wrote:
Booting a kernel with initrd using U-Boot from bullseye with default
environment results in a kernel panic, because U-Boot loads the
initrd
in highmem [1]. The problem has been fixed upstream [2]. Please
consider
including the fix in bullseye. I've tested the attached patch, which
applies to v2021.01 and which is a backport of the fix (variable
`CONFIG_SYS_BOOTMAPSZ` has been renamed to `CFG_SYS_BOOTMAPSZ` in
v2023.01).
Thanks!
Could you please also test against the version in unstable? Generally
we
need fixes to go to unstable before backporting them to stable... and
given that bookworm will likely release this year, I would like for
the
version in bookworm (currently based on upstream v2023.01) to work as
well...
Unfortunately I can't. In v2021.10 and v2023.01 two separate problems
were introduced [1], [2]. A fix for one of them is pending. For the
other I don't have an idea how to fix this yet (reverting a commit works
for me, but might break other boards).
[1]: https://lists.denx.de/pipermail/u-boot/2023-January/504116.html
[2]: https://lists.denx.de/pipermail/u-boot/2023-January/504115.html
Looks like the patch got merged upstream:
https://source.denx.de/u-boot/u-boot/-/commit/ace75d642fa71034b248cde30709c79e06c52d61
Would be good to include a link to the upstream fix in the comments of
the patch, and also explain that it is backported with regards to
CFG_SYS_BOOTMAPSZ vs. CONFIG_SYS_BOOTMAPSZ in the patch itself... it
was
a little confusing to see the text of patch use one and the patch
describe another...
I've attached an updated patch.
live well,
vagrant
>From 9926ea7e2103ad4ce390797c170aaf6993f5cb81 Mon Sep 17 00:00:00 2001
From: Joost van Zwieten
Date: Sun, 15 Jan 2023 00:57:30 +0100
Subject: [PATCH] odroid: limit boot memory to lowmem
This patch prevents a kernel panic on the Odroid U2/U3 when booting a
kernel with initrd and default U-Boot environment (Debian bug #1029373,
discussion upstream: [1]). This patch is a backport of
ace75d642fa71034b248cde30709c79e06c52d61 [2] which has been merged into
upstream master *after* tagging v2023.01. Between v2022.10 and v2023.01
the variable `CONFIG_SYS_BOOTMAPSZ` has been renamed to
`CFG_SYS_BOOTMAPSZ`, which is accounted for in this backport.
[1]: https://lists.denx.de/pipermail/u-boot/2023-January/504469.html
[2]: https://source.denx.de/u-boot/u-boot/-/commit/ace75d642fa71034b248cde30709c79e06c52d61
The original (backported) commit message:
In commit 4963f63fe61f ("image: Use gd->ram_base/_size in
env_get_bootm_size()") the size of the available memory for U-Boot to
use when relocating images, and not otherwise constrained, was changed
to include all known memory banks. In the case of this platform however,
all of the memory known to U-Boot is not also part of the Linux kernel
"lowmem" and so we must use CONFIG_SYS_BOOTMAPSZ to limit where we
relocate images to. We set a conservative limit of 256MB here to mirror
the previous behavior.
Signed-off-by: Joost van Zwieten
[trini: Reword the commit messsage]
Signed-off-by: Tom Rini
---
include/configs/odroid.h | 1 +
1 file changed, 1 insertion(+)
diff --git a/include/configs/odroid.h b/include/configs/odroid.h
index 1367d13891..dfb1eeb784 100644
--- a/include/configs/odroid.h
+++ b/include/configs/odroid.h
@@ -21,6 +21,7 @@
#define CONFIG_MACH_TYPE 4289
+#define CONFIG_SYS_BOOTMAPSZ 0x1000
#define CONFIG_SYS_SDRAM_BASE 0x4000
#define SDRAM_BANK_SIZE (256 << 20) /* 256 MB */
#define PHYS_SDRAM_1 CONFIG_SYS_SDRAM_BASE
--
2.30.2
Bug#1029373: kernel panic on Odroid U2 with default environment
Package: u-boot-exynos
Version: 2021.01+dfsg-5
Dear maintainers,
Booting a kernel with initrd using U-Boot from bullseye with default
environment results in a kernel panic, because U-Boot loads the initrd
in highmem [1]. The problem has been fixed upstream [2]. Please consider
including the fix in bullseye. I've tested the attached patch, which
applies to v2021.01 and which is a backport of the fix (variable
`CONFIG_SYS_BOOTMAPSZ` has been renamed to `CFG_SYS_BOOTMAPSZ` in
v2023.01).
Best, Joost
[1]: https://lists.denx.de/pipermail/u-boot/2023-January/504469.html
[2]: https://lists.denx.de/pipermail/u-boot/2023-January/505358.html
>From 9926ea7e2103ad4ce390797c170aaf6993f5cb81 Mon Sep 17 00:00:00 2001
From: Joost van Zwieten
Date: Sun, 15 Jan 2023 00:57:30 +0100
Subject: [PATCH] odroid: limit boot memory to lowmem
In commit 4963f63fe61f ("image: Use gd->ram_base/_size in
env_get_bootm_size()") the size of the available memory for U-Boot to
use when relocating images, and not otherwise constrained, was changed
to include all known memory banks. In the case of this platform however,
all of the memory known to U-Boot is not also part of the Linux kernel
"lowmem" and so we must use CFG_SYS_BOOTMAPSZ to limit where we relocate
images to. We set a conservative limit of 256MB here to mirror the
previous behavior.
Signed-off-by: Joost van Zwieten
[trini: Reword the commit messsage]
Signed-off-by: Tom Rini
---
include/configs/odroid.h | 1 +
1 file changed, 1 insertion(+)
diff --git a/include/configs/odroid.h b/include/configs/odroid.h
index 1367d13891..dfb1eeb784 100644
--- a/include/configs/odroid.h
+++ b/include/configs/odroid.h
@@ -21,6 +21,7 @@
#define CONFIG_MACH_TYPE 4289
+#define CONFIG_SYS_BOOTMAPSZ 0x1000
#define CONFIG_SYS_SDRAM_BASE 0x4000
#define SDRAM_BANK_SIZE (256 << 20) /* 256 MB */
#define PHYS_SDRAM_1 CONFIG_SYS_SDRAM_BASE
--
2.30.2
Bug#1016963: Please test u-boot for odroid
Hi Vagrant, Sorry for the late reply. I've been testing u-boot on the Odroid U3 the last couple of days. Turns out that u-boot doesn't work in stable (again, sorry!). I've bisected the problem to commit 4963f63fe61f15329d77472a762b1d8bf754d24b (u-boot repo, somewhere between v2020.10 and v2021.01). Reverting this commit in v2021.01 fixes the problem. I noticed the following change in u-boot's output. Before said commit: Kernel image @ 0x4100 [ 0x00 - 0x3fd200 ] ## Flattened Device Tree blob at 4080 Booting using the fdt blob at 0x4080 Loading Ramdisk to 4ece6000, end 49f5 ... OK Loading Device Tree to 4ecd6000, end 4ece5f41 ... OK After the commit: Kernel image @ 0x4100 [ 0x00 - 0x3fd200 ] ## Flattened Device Tree blob at 4080 Booting using the fdt blob at 0x4080 Loading Ramdisk to b9b6, end bae799f5 ... OK Loading Device Tree to b9b5, end b9b5ff41 ... OK I've browsed through the source code and found that you can control the position of the initrd using environment variable `initrd_high`. Setting this to `0x5000` solves the problem as well in v2021.01 without reverting 4963f63f. Also `0x` works, which according to u-boot's README disables the relocation of the initrd. The position of the device tree doesn't seem to matter. I'm not sure how to proceed with this and any guidance is appreciated, but given that you're busy with finishing bookworm, I completely understand that you don't have time for this. Best, Joost Op do 29 dec. 2022 om 01:39 schreef Vagrant Cascadian : > > On 2022-12-28, Vagrant Cascadian wrote: > > On 2022-12-22, Vagrant Cascadian wrote: > >> On 2022-08-20, Vagrant Cascadian wrote: > >>> On 2022-08-10, Vagrant Cascadian wrote: > This bug is just to delay migration to testing while more platforms get > tested. If you have a relevent board, please consider testing and > reporting the status: > > https://wiki.debian.org/U-boot/Status > > > > I have not received many test results for current or even remotely > > recent u-boot platforms in Debian, and u-boot has been blocked from > > migration to testing partly because of this. > > > > As the bookworm freeze approaches, this is getting to be... worrysome! > > > > If you have access to any of these boards, please consider testing > > u-boot versions as packaged in debian for versions from debian stable > > (2021.01*), testing (2022.04*), unstable (2022.10*) and experimental > > (2023.01-rc*) and updating the wiki page if successful and/or replying > > to 1016...@bugs.debian.org with a positive confirmation... > > > > ...and if not successful, filing bugs against the relevent u-boot-* > > packages and marking them as blocking 1016963. > > odroid > > live well, > vagrant
Bug#904946: gmsh: OpenCASCADE gone
Hi Kurt, Andreas, I ran into this issue today. When switching from stretch to buster I noticed that gmsh couldn't read STEP files anymore. The following error message appears: Error : Gmsh requires OpenCASCADE to import shape I've fixed the issue by building gmsh with the additional build dependency libocct-data-exchange-dev. See patch 0001. I've also added a small autopkgtest (patch 0002) using a STEP file that is part of the source package. Best, Joost From 874f4f814cc64e49ee4af6401fa1b15a931a9339 Mon Sep 17 00:00:00 2001 From: Joost van Zwieten Date: Tue, 27 Nov 2018 12:46:11 +0100 Subject: [PATCH 1/2] add missing build dep for OpenCASCADE support --- debian/control | 1 + 1 file changed, 1 insertion(+) diff --git a/debian/control b/debian/control index 469f2ebf..46f66eba 100644 --- a/debian/control +++ b/debian/control @@ -25,6 +25,7 @@ Build-Depends: chrpath, libmed-dev, libmedc-dev, libocct-modeling-data-dev, + libocct-data-exchange-dev, libocct-ocaf-dev, libocct-visualization-dev, libpng-dev, -- 2.19.2 From 57c9b40d1dab1c2c1f8d2c2926591e25065347bc Mon Sep 17 00:00:00 2001 From: Joost van Zwieten Date: Tue, 27 Nov 2018 17:33:32 +0100 Subject: [PATCH 2/2] add autopkgtest for reading step files --- debian/tests/check1 | 4 1 file changed, 4 insertions(+) diff --git a/debian/tests/check1 b/debian/tests/check1 index 171643e8..cd56a02e 100755 --- a/debian/tests/check1 +++ b/debian/tests/check1 @@ -6,6 +6,7 @@ set -e export OMPI_MCA_plm_rsh_agent=/bin/false +SRCDIR=$PWD WORKDIR=$(mktemp -d) trap "rm -rf $WORKDIR" 0 INT QUIT ABRT PIPE TERM cd $WORKDIR @@ -48,6 +49,9 @@ gmsh tetrahedra.geo -3 -o tetrahedra3d.stl gmsh tetrahedra.geo -2 -o tetrahedra2d.vtk gmsh tetrahedra.geo -3 -o tetrahedra3d.vtk +# Test support for reading step files. +gmsh "$SRCDIR/demos/boolean/component8.step" -3 -o component8.msh + ls -ln echo "run: OK" -- 2.19.2
Bug#905503: networkd doesn't like fritzbox' IPv6 announcement, interface degraded
Michael, could you anyhow cherry-pick 6554550f. That works for my Fritzbox. Or do you want me to open a separate bug report? Best, Joost On Sun, 28 Oct 2018 at 16:57, Michael Biebl wrote: > > On Fri, 7 Sep 2018 01:57:13 +0200 Michael Biebl wrote: > > Control: tags -1 + help > > > > Hi Marc > > > > On Fri, 10 Aug 2018 20:29:51 +0200 Marc Haber > > wrote: > > > The Fritzbox is an extremely common DSL router in middle europe, and > > > dual-stack networking is becoming increasingly common. Deutsche Telekom > > > and 1&1, two of Germany's largest ISPs for consumer DSL, both provide > > > dual-stacked Internet. This issue should be addressed in stretch. > > > > I'm happy to consider cherry-picking the necessary commits for stretch if > > a/ someone figures out the necessary upstream commits > > b/ the commits are (easily) backportable and not too invasive > > c/ tests the resulting package > > > > I can do b/, i.e. the backport/cherry-pick/review part, but would rely > > on help with a/ and c/ (as I have no setup to debug and test this) > > Any updates here, Marc? > > > -- > Why is it that all of the instruments seeking intelligent life in the > universe are pointed away from Earth? >
Bug#905503: networkd doesn't like fritzbox' IPv6 announcement, interface degraded
I'm not sure if I have the exact same problem. I also have a Fritzbox. At boot (or systemctl restart systemd-networkd) my machine running stretch is able to obtain an IPv6 global address and networkctl reports no problem. After several days the IPv6 global address disappears, leaving only a link-local address. This problem disappeared - tested for several months - after cherry-picking [6554550f]. See also [GH#3879]. Best, Joost [6554550f]: https://github.com/systemd/systemd/commit/6554550f35a7976f9110aff94743d3576d5f02dd [GH#3879]: https://github.com/systemd/systemd/issues/3879
Bug#799939:
Hi, Actually, there appears to be a bug in either GCC (5.3.1) or Chromium (49.0.2623.75) on armhf. Chromium crashes just after showing the browser window. The traceback ends in some iterator in libstdc++.so.6. LLVM works fine though. I'm trying to find out what causes the crash but that will take some time: building Chromium on my machine takes roughly 12 hours. I've updated the patches for armhf, see [github-armhf]. As of commit 1ba1f38, which includes `defines+=remove_webcore_debug_symbols=1`, the fourth patch of my previous mail is unnecessary. [github-armhf]: https://github.com/joostvanzwieten/pkg-chromium/tree/armhf Best, Joost On 9 March 2016 at 10:43, Riku Voipio wrote: > On 9 March 2016 at 11:00, Raphael Hertzog wrote: >> what's the status of this bug? I would love to see chromium on armhf and >> arm64. > > I've have armhf/arm64 builds of chromium for jessie at: > > http://repo.linaro.org/ubuntu/linaro-overlay/pool/main/c/chromium-browser/ > >> Michael, it looks like Riku upstreamed most of the important changes and >> what's left is reasonable to include in the Debian package. > > The patches upstream are a bit different. This week I'm at a > conferences, but for next week I can backport the patches against 49. > > Riku
Bug#799939:
On 3 November 2015 at 20:37, Joost van Zwieten
wrote:
> Hi,
>
> I have been building chromium for (and on) an armhf machine for more
> than a year using the first two of the attached patches (rebased onto
> debian/46.0.2490.71-1). I also suffered from the OOM issue during
> linking, but I solved it by disabling generating debug symbols (not in
> included in the patches!). I will test the new binutils tonight.
That took a bit longer than expected. With the latest binutils from
experimental I was still unable to link chromium: ld failed with the
message 'Memory exhausted'. I came up the following solution: reduce
the amount of debug information to line numbers only. Passing
'-gline-tables-only' to clang does the job, see fourth attached patch.
With all patches applied I can successfully build chromium.
I've updated the first patch to include defining DEB_HOST_ARCH in
debian/rules if undefined, as suggested by the man page of
dpkg-buildflags.
Best, Joost
From 682141d283abbcc62d409d82fab99b062b136a57 Mon Sep 17 00:00:00 2001
From: Joost van Zwieten
Date: Sun, 24 Aug 2014 23:46:07 +0200
Subject: [PATCH 1/4] enable armhf
---
debian/control | 6 +++---
debian/rules | 13 +
2 files changed, 16 insertions(+), 3 deletions(-)
diff --git a/debian/control b/debian/control
index 5172532..cfe66a8 100644
--- a/debian/control
+++ b/debian/control
@@ -84,7 +84,7 @@ Build-Depends:
Standards-Version: 3.9.6
Package: chromium
-Architecture: i386 amd64
+Architecture: i386 amd64 armhf
Built-Using: ${Built-Using}
Depends:
${misc:Depends},
@@ -105,7 +105,7 @@ Description: web browser
This package contains the web browser component.
Package: chromium-dbg
-Architecture: i386 amd64
+Architecture: i386 amd64 armhf
Section: debug
Priority: extra
Built-Using: ${Built-Using}
@@ -134,7 +134,7 @@ Description: web browser - language packs
ro, ru, sk, sl, sr, sv, sw, ta, te, th, tr, uk, vi, zh-CN, zh-TW
Package: chromedriver
-Architecture: i386 amd64
+Architecture: i386 amd64 armhf
Depends:
${misc:Depends},
${shlibs:Depends},
diff --git a/debian/rules b/debian/rules
index cb86461..7412adb 100755
--- a/debian/rules
+++ b/debian/rules
@@ -12,6 +12,9 @@ export LDFLAGS+=-Wl,--no-keep-memory -Wl,--reduce-memory-overheads -Wl,--hash-si
# more verbose linker output
export LDFLAGS+=-Wl,--trace -Wl,--stats
+# set DEB_HOST_ARCH if undefined
+DEB_HOST_ARCH?=$(shell dpkg-architecture -qDEB_HOST_ARCH)
+
# treat all warnings as errors
defines=werror=
@@ -83,6 +86,16 @@ defines+=use_system_icu=0 \
# can't use system nss since net/third_party/nss is heavily patched
# can't use system ots (open text *summarizer*) since that's not google's ots (open text *sanitizer*)
+ifeq ($(DEB_HOST_ARCH),armhf)
+# arm_version=7, arm_neon=0 selects arm_arch=armv7-a, arm_tune=generic-armv7-a, arm_fpu=vfpv3-d16
+defines+=sysroot= \
+ target_arch=arm \
+ arm_version=7 \
+ arm_neon=0
+# webrtc is not compatible with arm_neon=0
+defines+=enable_webrtc=0
+endif
+
# make gyp a little more informative
options+=--check \
--debug=includes \
--
2.6.2
From ab6a33d1ed51bb3f392043b3b5422671eee3daca Mon Sep 17 00:00:00 2001
From: Joost van Zwieten
Date: Wed, 3 Dec 2014 10:04:27 +0100
Subject: [PATCH 2/4] disable sse2 message for arm platforms
---
debian/scripts/chromium | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/debian/scripts/chromium b/debian/scripts/chromium
index 28f2854..a0b5c9e 100644
--- a/debian/scripts/chromium
+++ b/debian/scripts/chromium
@@ -31,7 +31,7 @@ For more information, please read and possibly provide input to their
bug tracking system at http://crbug.com/348761.";
# Check whether this system supports sse2
-if test -z "$(grep sse2 /proc/cpuinfo)"; then
+if test -z "$(grep sse2 /proc/cpuinfo)" -a -z "$(uname -m | grep arm)"; then
xmessage "$nosse2"
exit 1
fi
--
2.6.2
From d19483212de9011c6abed3191a96ffac5025ae13 Mon Sep 17 00:00:00 2001
From: Joost van Zwieten
Date: Mon, 2 Nov 2015 22:54:47 +0100
Subject: [PATCH 3/4] fix detection of ARM hard float ABI with clang
Bug reported upstream [2140#c24]. Pending approval applying the patch here.
[2140#c24] https://code.google.com/p/v8/issues/detail?id=2140#c24
---
...etection-of-ARM-hard-float-ABI-with-clang.patch | 48 ++
debian/patches/series | 2 +
2 files changed, 50 insertions(+)
create mode 100644 debian/patches/fix-detection-of-ARM-hard-float-ABI-with-clang.patch
diff --git a/debian/patches/fix-detection-of-ARM-hard-float-ABI-with-clang.patch b/debian/patches/fix-detection-of-ARM-hard-float-ABI-with-clang.patch
new file mode 100644
index 000..aee0246
--- /dev/null
+++ b/debian/patches/fix-detection-of-ARM-hard-float-ABI-with-clang.patch
@@ -0,0 +1,48 @@
+From b4d5d97f6a1446babda7cebcb039ed7fef7b73fd Mon Sep 17 0
Bug#799939:
Hi,
I have been building chromium for (and on) an armhf machine for more
than a year using the first two of the attached patches (rebased onto
debian/46.0.2490.71-1). I also suffered from the OOM issue during
linking, but I solved it by disabling generating debug symbols (not in
included in the patches!). I will test the new binutils tonight.
Until recently I was unable to build chromium using clang. That is, it
works, but maps.google.com did not. I tracked down the problem and
submitted a patch upstream, see [V8:2140#c24]. Pending approval I've
included the patch in the debian package as well (third patch).
You can also find the patches on [github-pkg-chromium].
[V8:2140#c24]: https://code.google.com/p/v8/issues/detail?id=2140#c24
[github-pkg-chromium]:
https://github.com/joostvanzwieten/pkg-chromium/compare/armhf?expand=1
Best, Joost
From 7d4888a469a1df7dc04de386fe58cf3488bc0b9c Mon Sep 17 00:00:00 2001
From: Joost van Zwieten
Date: Sun, 24 Aug 2014 23:46:07 +0200
Subject: [PATCH 1/3] enable armhf
---
debian/control | 6 +++---
debian/rules | 10 ++
2 files changed, 13 insertions(+), 3 deletions(-)
diff --git a/debian/control b/debian/control
index 5172532..cfe66a8 100644
--- a/debian/control
+++ b/debian/control
@@ -84,7 +84,7 @@ Build-Depends:
Standards-Version: 3.9.6
Package: chromium
-Architecture: i386 amd64
+Architecture: i386 amd64 armhf
Built-Using: ${Built-Using}
Depends:
${misc:Depends},
@@ -105,7 +105,7 @@ Description: web browser
This package contains the web browser component.
Package: chromium-dbg
-Architecture: i386 amd64
+Architecture: i386 amd64 armhf
Section: debug
Priority: extra
Built-Using: ${Built-Using}
@@ -134,7 +134,7 @@ Description: web browser - language packs
ro, ru, sk, sl, sr, sv, sw, ta, te, th, tr, uk, vi, zh-CN, zh-TW
Package: chromedriver
-Architecture: i386 amd64
+Architecture: i386 amd64 armhf
Depends:
${misc:Depends},
${shlibs:Depends},
diff --git a/debian/rules b/debian/rules
index cb86461..edd45eb 100755
--- a/debian/rules
+++ b/debian/rules
@@ -83,6 +83,16 @@ defines+=use_system_icu=0 \
# can't use system nss since net/third_party/nss is heavily patched
# can't use system ots (open text *summarizer*) since that's not google's ots (open text *sanitizer*)
+ifeq (armhf,$(DEB_HOST_ARCH))
+# arm_version=7, arm_neon=0 selects arm_arch=armv7-a, arm_tune=generic-armv7-a, arm_fpu=vfpv3-d16
+# webrtc is not compatible with arm_neon=0
+defines+=sysroot= \
+ target_arch=arm \
+ arm_version=7 \
+ arm_neon=0 \
+ enable_webrtc=0
+endif
+
# make gyp a little more informative
options+=--check \
--debug=includes \
--
2.6.1
From aa7b29e2fbb008e6104a531fb0ed6042fedd39d3 Mon Sep 17 00:00:00 2001
From: Joost van Zwieten
Date: Wed, 3 Dec 2014 10:04:27 +0100
Subject: [PATCH 2/3] disable sse2 message for arm platforms
---
debian/scripts/chromium | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/debian/scripts/chromium b/debian/scripts/chromium
index 28f2854..a0b5c9e 100644
--- a/debian/scripts/chromium
+++ b/debian/scripts/chromium
@@ -31,7 +31,7 @@ For more information, please read and possibly provide input to their
bug tracking system at http://crbug.com/348761.";
# Check whether this system supports sse2
-if test -z "$(grep sse2 /proc/cpuinfo)"; then
+if test -z "$(grep sse2 /proc/cpuinfo)" -a -z "$(uname -m | grep arm)"; then
xmessage "$nosse2"
exit 1
fi
--
2.6.1
From 16ccedf6f23220a42793b84f3c84617260cfaf4c Mon Sep 17 00:00:00 2001
From: Joost van Zwieten
Date: Mon, 2 Nov 2015 22:54:47 +0100
Subject: [PATCH 3/3] fix detection of ARM hard float ABI with clang
Bug reported upstream [2140#c24]. Pending approval applying the patch here.
[2140#c24] https://code.google.com/p/v8/issues/detail?id=2140#c24
---
...etection-of-ARM-hard-float-ABI-with-clang.patch | 48 ++
debian/patches/series | 2 +
2 files changed, 50 insertions(+)
create mode 100644 debian/patches/fix-detection-of-ARM-hard-float-ABI-with-clang.patch
diff --git a/debian/patches/fix-detection-of-ARM-hard-float-ABI-with-clang.patch b/debian/patches/fix-detection-of-ARM-hard-float-ABI-with-clang.patch
new file mode 100644
index 000..aee0246
--- /dev/null
+++ b/debian/patches/fix-detection-of-ARM-hard-float-ABI-with-clang.patch
@@ -0,0 +1,48 @@
+From b4d5d97f6a1446babda7cebcb039ed7fef7b73fd Mon Sep 17 00:00:00 2001
+From: Joost van Zwieten
+Date: Mon, 2 Nov 2015 21:47:21 +0100
+Subject: [PATCH] fix detection of ARM hard float ABI with clang
+
+The Linux version of `base::OS::ArmUsingHardFloat`, defined in
+`src/base/platform/platform-linux.cc`, always returns `false` when compiling V8
+with Clang, regardless of the target float ABI. When targeting ARMv7 with hard
+float ABI this results in faulty `fast_exp` and `fast_sqrt` functions,
+generated using masm in `src/arm/c
Bug#783737: u-boot-exynos: enable odroid in u-boot-exynos
Package: u-boot-exynos Version: 2015.04+dfsg1-1 Severity: wishlist Dear Maintainer, Please consider enabling the odroid target (see attached patch). I've tested this on an Odroid-U3. Best regards, Joost van Zwieten From cbd4d3d049d4487ebb8469ffc590ea53c92d1969 Mon Sep 17 00:00:00 2001 From: Joost van Zwieten Date: Wed, 29 Apr 2015 18:38:43 +0200 Subject: [PATCH] Enable odroid in u-boot-exynos. --- debian/targets | 3 +++ debian/u-boot-exynos.lintian-overrides | 2 ++ 2 files changed, 5 insertions(+) diff --git a/debian/targets b/debian/targets index 3ce3a5d..21c704b 100644 --- a/debian/targets +++ b/debian/targets @@ -17,6 +17,9 @@ armel - sheevaplug u-boot.kwb # Ian Campbell armhf exynos arndale u-boot-dtb.bin spl/arndale-spl.bin +# Joost van Zwieten , Odroid-U3 +armhf exynos odroid u-boot-dtb.bin + # Robert Nelson armhf imx mx53loco u-boot.imx diff --git a/debian/u-boot-exynos.lintian-overrides b/debian/u-boot-exynos.lintian-overrides index 7ada93f..8beaba8 100644 --- a/debian/u-boot-exynos.lintian-overrides +++ b/debian/u-boot-exynos.lintian-overrides @@ -4,8 +4,10 @@ # targets could be built on multiple architectures, but could instead install # the package for the architecture needed. u-boot-exynos [armhf]: arch-dependent-file-not-in-arch-specific-directory usr/lib/u-boot/arndale/uboot.elf +u-boot-exynos [armhf]: arch-dependent-file-not-in-arch-specific-directory usr/lib/u-boot/odroid/uboot.elf # These bootloaders need to be statically linked. u-boot-exynos [armhf]: statically-linked-binary usr/lib/u-boot/arndale/uboot.elf +u-boot-exynos [armhf]: statically-linked-binary usr/lib/u-boot/odroid/uboot.elf u-boot-exynos: description-synopsis-starts-with-article -- 2.1.4
Bug#767204: request: backport i2c-hid suspend, resume fix from 3.17 to 3.16
Package: src:linux
Version: 3.16.5-1
The touchpad (`SYN1B7D:01 06CB:2991 UNKNOWN` as reported by dmesg) of
a friend's laptop stops working after suspending and resuming the
laptop when using kernel 3.16. I cannot test older kernels as the
laptop is quite new. The problem is solved in 3.17 with commit
[109571c]. Since, AFAIK, Jessie will ship with kernel 3.16, please
consider the attached patch, which adds [109571c] to
`debian/patches/bugfix/all` and updates `debian/patches/series`.
[109571c]:
https://git.kernel.org/cgit/linux/kernel/git/torvalds/linux.git/commit/?id=109571cf3ec78a39477eedd6b11927f52cbcb1e8
Best regards,
Joost
diff -Naur debian.orig/patches/bugfix/all/i2c-hid-suspend-resume-fix.patch debian/patches/bugfix/all/i2c-hid-suspend-resume-fix.patch
--- debian.orig/patches/bugfix/all/i2c-hid-suspend-resume-fix.patch 1970-01-01 01:00:00.0 +0100
+++ debian/patches/bugfix/all/i2c-hid-suspend-resume-fix.patch 2014-10-11 15:35:34.774146332 +0200
@@ -0,0 +1,73 @@
+From 109571cf3ec78a39477eedd6b11927f52cbcb1e8 Mon Sep 17 00:00:00 2001
+From: Andrew Duggan
+Date: Fri, 11 Jul 2014 16:34:18 -0700
+Subject: [PATCH] HID: i2c-hid: call the hid driver's suspend and resume
+ callbacks
+
+Currently, the i2c-hid driver does not call the suspend, resume, and
+reset_resume callbacks in the hid_driver struct when those events occur.
+This means that HID drivers for i2c-hid devices will not be able to execute
+commands which may be needed during suspend or resume. One example is when a
+touchpad using the hid-multitouch driver gets reset by i2c-hid coming out of
+resume. Since the reset_resume callback never gets called the device is never
+put back into the correct input mode. This patch calls the suspend and resume
+callbacks and tries to duplicate the functionality of the usb-hid driver.
+
+Signed-off-by: Andrew Duggan
+Signed-off-by: Vincent Huang
+Reviewed-by: Benjamin Tissoires
+Signed-off-by: Jiri Kosina
+---
+ drivers/hid/i2c-hid/i2c-hid.c | 15 ++-
+ 1 file changed, 14 insertions(+), 1 deletion(-)
+
+diff --git a/drivers/hid/i2c-hid/i2c-hid.c b/drivers/hid/i2c-hid/i2c-hid.c
+index 21aafc8..747d544 100644
+--- a/drivers/hid/i2c-hid/i2c-hid.c
b/drivers/hid/i2c-hid/i2c-hid.c
+@@ -1054,21 +1054,29 @@ static int i2c_hid_remove(struct i2c_client *client)
+ static int i2c_hid_suspend(struct device *dev)
+ {
+ struct i2c_client *client = to_i2c_client(dev);
++ struct i2c_hid *ihid = i2c_get_clientdata(client);
++ struct hid_device *hid = ihid->hid;
++ int ret = 0;
+
+ disable_irq(client->irq);
+ if (device_may_wakeup(&client->dev))
+ enable_irq_wake(client->irq);
+
++ if (hid->driver && hid->driver->suspend)
++ ret = hid->driver->suspend(hid, PMSG_SUSPEND);
++
+ /* Save some power */
+ i2c_hid_set_power(client, I2C_HID_PWR_SLEEP);
+
+- return 0;
++ return ret;
+ }
+
+ static int i2c_hid_resume(struct device *dev)
+ {
+ int ret;
+ struct i2c_client *client = to_i2c_client(dev);
++ struct i2c_hid *ihid = i2c_get_clientdata(client);
++ struct hid_device *hid = ihid->hid;
+
+ enable_irq(client->irq);
+ ret = i2c_hid_hwreset(client);
+@@ -1078,6 +1086,11 @@ static int i2c_hid_resume(struct device *dev)
+ if (device_may_wakeup(&client->dev))
+ disable_irq_wake(client->irq);
+
++ if (hid->driver && hid->driver->reset_resume) {
++ ret = hid->driver->reset_resume(hid);
++ return ret;
++ }
++
+ return 0;
+ }
+ #endif
+--
+2.1.1
+
diff -Naur debian.orig/patches/series debian/patches/series
--- debian.orig/patches/series 2014-10-10 04:16:39.0 +0200
+++ debian/patches/series 2014-10-11 15:35:49.733657053 +0200
@@ -110,6 +110,7 @@
debian/i2o-disable-i2o_ext_adaptec-on-64bit.patch
bugfix/all/aic94xx-remove-broken-fallback-for-missing-ctrl-a.patch
bugfix/all/builddeb-put-the-dbg-files-into-the-correct-director.patch
+bugfix/all/i2c-hid-suspend-resume-fix.patch
# memfd_create() & kdbus backport
features/all/kdbus/mm-allow-drivers-to-prevent-new-writable-mappings.patch
Bug#757081: installing `gdm3` fails when `/etc/X11` does not exist
Hi, I experienced the same behaviour when installing `gdm3` right after debootstrapping jessie. The following message appeared in the console during the installation of `gdm3`: touch: cannot touch '/etc/X11/default-display-manager.debconf-update': No such file or directory gdm3 failed to preconfigure, with exit status 1 The directory `/etc/X11` did not exist at that point. I guess this problem is solved by adding something like `mkdir -p /etc/X11` to `debian/gdm3.config` before the line touch $DEFAULT_DISPLAY_MANAGER_FILE.debconf-update Creating `/etc/X11` manually before installing `gdm3` did solve the problem for me. Best, Joost -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
