.
6.10.11 had build issues on hppa.
Could you cherry-pick those two patches from master branch into sid
(in this order) to avoid the build issue?
commit 61be2a3b21df7139a43cf80324a928e8532477ad
Author: Helge Deller
Date: Thu Sep 12 18:47:40 2024 +0200
[hppa] Fix kernel build with CONFIG_DRM=y on
ines sigset_t depending if _NSIG_WORDS is defined.
Signed-off-by: Helge Deller
diff -up ./usr/include/arch/parisc/klibc/archsignal.h.org ./usr/include/arch/parisc/klibc/archsignal.h
--- ./usr/include/arch/parisc/klibc/archsignal.h.org 2024-07-05 21:21:26.047846414 +
+++ ./usr/include/arch/parisc/klibc
On 7/5/24 21:06, Thorsten Glaser wrote:
Package: libklibc-dev
Version: 2.0.13-4
Severity: important
X-Debbugs-Cc: t...@mirbsd.de, Helge Deller
] In file included from /usr/lib/klibc/include/signal.h:14,
] from /usr/lib/klibc/include/sys/select.h:11,
] from
This kernel bug is now fixed, since binutils will now
support hppa64 binaries as well. See bz #1059674
Package: linux
Tags: hppa, ftbfs
Version: 6.6.8-1
Depends: 1059674
Kernel FTBFS on hppa.
Problem is, that on hppa the 32-bit strip and 32-bit objdump binaries can't
process
hppa 64-bit objects. Log shows, e.g.:
make[3]: Leaving directory '/home/deller/build/linux/linux-6.6.8'
dh_strip --no-aut
On 7/14/23 01:56, Thorsten Glaser wrote:
Dixi quod…
My guess here is that it’s, as usual, the fault of qemu-user,
Strong evidence for that: doesn’t look like it even executes
one bit of klibc code:
$ qemu-arm-static -d cpu ./fstype --help
qemu: uncaught target signal 11 (Segmentation fault)
Can you check if this patch fixes the problem:
https://patchew.org/QEMU/mvmpm55qnno@suse.de/
(linux-user: make sure brk(0) returns a page-aligned value, from Andreas
Schwab)
Ursprüngliche Nachricht Von: Thorsten Glaser
Datum: 14.07.23 00:48 (GMT+01:00) An: venkata.p...@t
Just wondering / guessing:
Are the ARM machines on ci.debian.net (ci-worker-arm??-??)
physical machines, or are they running on qemu-user VMs?
If they run qemu, this bug report
https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=1024653
might be similiar.
If so, then qemu probably needs fixing o
Hi Helmut,
On 1/24/23 06:27, Helmut Grohne wrote:
On Mon, Jan 23, 2023 at 10:48:27PM +0100, Helge Deller wrote:
--- ./init.org 2023-01-23 21:40:33.079738389 +
+++ ./init 2023-01-23 21:40:45.983861851 +
@@ -205,6 +205,15 @@ else
resume=${RESUME:-}
fi
+if [ -z "${RU
).
Please apply to the next initramfs-tools update.
Signed-off-by: Helge Deller diff -up ./init.org ./init
--- ./init.org 2023-01-23 21:40:33.079738389 +
+++ ./init 2023-01-23 21:40:45.983861851 +
@@ -205,6 +205,15 @@ else
resume=${RESUME:-}
fi
+if [ -z "${RUNSIZE}" ] || [[
I think the patch I sent in #1027915 should fix this issue:
https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=1027915#24
Hi Helmut,
On 1/4/23 14:26, Helmut Grohne wrote:
On Wed, Jan 04, 2023 at 02:08:00PM +0100, Helge Deller wrote:
My suggestion:
Please check that the /run mountpoint is mounted with at least 20MB, independend
of the installed RAM memory in the machine...
Your suggestion makes sense in
>> Can you check whether the benh/libgcc_s branch works for you?
> Yes, I can confirm that this fixes the issue for me.
Ben, could you push out a new initramfs-tools package with this fix soon?
Everytime I update the kernel package it fails to create the initrd...
Helge
* Ben Hutchings :
> On Fri, 2020-05-29 at 18:02 +0200, Helge Deller wrote:
> [...]
> > How can I flag the "linux-image-parisc" meta-package to become a successor
> > of the
> > "linux-image-parisc-smp" meta-package (e.g. Provides:
> > linux-imag
In the past we had on hppa/parisc up to four debian kernel variants,
for 32- and 64-bit kernels, with and without SMP:
linux-image-parisc
linux-image-parisc-smp
linux-image-parisc64
linux-image-parisc64-smp
Then we got live-patching working on the hppa kernels, which made extra
SMP kernels superfl
hook functions in
/usr/share/initramfs-tools/hooks/btrfs.
Tested on hppa.
Signed-off-by: Helge Deller
Noticed-by: John Paul Adrian Glaubitz
Bug: https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=959768
Fixes: f2ac13e8881f ("hook-functions: copy_exec: Copy libgcc_s.so.0 along with
libpthre
The debian kernel build switched to use debhelper
compatibility level 12 with this commit:
commit 59a5af36cbf1cc01ef48b91719f999a699d99fab
Author: Ben Hutchings
Date: Sun Apr 19 19:49:03 2020 +0100
debhelper started complaining about level 9, so it's time to upgrade
again.
This change
It turns out, that changing
dh_strip --no-automatic-dbgsym -Xvmlinux
to
dh_strip --no-automatic-dbgsym -Xvmlinux -Xvmlinuz
in debian/rules.real fixes the build.
I added some tracing code and this shows that in former compat level 9,
the strip command is never executed on the vmlinu
Package: linux
Version: 5.6.7-1
Severity: important
Tags: ftbfs
The Debian Linux kernel fails to build from source for all kernels > 5.5.17-1,
as can be seen here:
https://buildd.debian.org/status/logs.php?pkg=linux&arch=hppa
During build a 32-bit Linux kernel and a 64-bit Linux kernel is built.
On 29.04.20 15:36, Ben Hutchings wrote:
> Control: tag -1 upstream fixed-upstream patch
>
> On Wed, 2020-04-29 at 14:12 +1000, Russell Coker wrote:
>> Package: klibc-utils
>> Version: 2.0.7-1
>> Severity: normal
>>
>> root@sevm:~/pol# /usr/lib/klibc/bin/fstype < /dev/sda2
>> Segmentation fault
>>
On 12.06.2017 16:58, Ben Hutchings wrote:
> On Thu, 2017-06-08 at 21:23 +0200, Helge Deller wrote:
>> Can you backport at least the commit 05f0e38724e8 ?
>
> This appears to depend on commit 9385a84d7e1f which looks hard to backport.
Ben, if it's too much work, maybe just
Package: linux
Version: 4.9.30
The LTP testcase fanotify07 creates hanging processes
with debian kernel 4.9.30 on the hppa platform.
In the source code of LTP's fanotify07.c testcase one can read:
* Kernel crashes should be fixed by:
* 96d41019e3ac "fanotify: fix list corruption in fanotify_ge
Hi Ben,
On 30.09.2016 23:20, Ben Hutchings wrote:
> On Tue, 2016-09-27 at 23:09 +0200, Helge Deller wrote:
>> On 27.09.2016 21:07, Ben Hutchings wrote:
>>> On Tue, 2016-09-27 at 14:48 +0200, Helge Deller wrote:
>>>> On 23.09.2016 05:39, Ben Hutchings wrote:
>>
Hi Ben,
On 27.09.2016 21:07, Ben Hutchings wrote:
> On Tue, 2016-09-27 at 14:48 +0200, Helge Deller wrote:
>> On 23.09.2016 05:39, Ben Hutchings wrote:
>>>
>>> I pushed a fix to the sid branch which I've tested on a powerpc
>>> porterbox.
>>
>>
Hi Ben,
On 23.09.2016 05:39, Ben Hutchings wrote:
> I pushed a fix to the sid branch which I've tested on a powerpc
> porterbox.
The addition of
dh_strip --no-automatic-dbgsym
broke the 64bit parisc/hppa kernel build:
dh_strip --no-automatic-dbgsym
strip:debian/linux-image-4.7.0-1-parisc64-sm
Hi Ben,
On 19.09.2016 20:56, Ben Hutchings wrote:
> On Mon, 2016-09-19 at 20:50 +0200, Helge Deller wrote:
>> On 19.09.2016 19:41, Ben Hutchings wrote:
>>> On Mon, 2016-09-12 at 20:28 +0100, Ben Hutchings wrote:
>>>> On Mon, 2016-09-12 at 18:17 +0200, Helge Deller
Hi Ben,
On 19.09.2016 19:41, Ben Hutchings wrote:
> On Mon, 2016-09-12 at 20:28 +0100, Ben Hutchings wrote:
>> On Mon, 2016-09-12 at 18:17 +0200, Helge Deller wrote:
>>> So, can you please deactivate CONFIG_FTRACE completely for 32- and
>>> 64bit hppa configs?
Package: linux
Version: 4.7.2-1
Severity: important
We sadly will need to disable CONFIG_FTRACE for hppa architecture completely
for now.
The problem is, that gcc creates lots of overhead when adding the code for the
mcount call (minimum 16 bytes per function, plus two relocation symbol entries)
On 05.05.2016 03:17, Ben Hutchings wrote:
> There's a silly type error in an alpha-specific module that now breaks
> the build:
>
> /«PKGBUILDDIR»/fs/binfmt_em86.c: In function 'load_em86':
> /«PKGBUILDDIR»/fs/binfmt_em86.c:73:35: error: passing argument 2 of
> 'copy_strings_kernel' from incompat
Hi Ben,
On 05.05.2016 03:29, Ben Hutchings wrote:
> Building linux 4.6~rc5-1~exp1 on hppa failed with:
>
> hppa64-linux-gnu-ld: net/built-in.o(.init.text+0x51c): cannot reach
> register_net_sysctl
> net/built-in.o: In function `sysctl_core_init':
> net/core/sysctl_net_core.o:(.init.text+0x51c):
Hi Ben,
On 14.04.2016 00:48, Ben Hutchings wrote:
> On Thu, 2016-03-10 at 18:23 +0100, Helge Deller wrote:
>> Since kernel 4.3 we have a problem on hppa that it crashes at bootup
>> during the SCSI drive detection.
>> There are multiple threads about this issue and this
Since kernel 4.3 we have a problem on hppa that it crashes at bootup
during the SCSI drive detection.
There are multiple threads about this issue and this link is maybe a good start:
https://patchwork.kernel.org/patch/8402441/.
Now, after quite some time, we could identify what's going wrong.
The
Source: linux
Version: 3.16.7-2
Severity: important
Tags: patch
Dear debian kernel maintainers,
please apply the attached patch to the debian kernel sources for the next
upload.
It fixes this error when building and packaging the debian hppa kernel:
...
kernel-wedge install-files 3.16.0-4
...
Source: linux
Version: 3.16.0-4
Severity: important
Tags: patch
This is a follow-up on Bug#766793.
I'm not sure if I tested something wrong when I opened Bug#766793, but now
while packaging the udeb packages we get this error:
kernel-wedge install-files 3.16.0-4
install -D -m 644
debi
t's valid to assume they will all have distinct values
to fit into a switch).
Committed as the only solution we possibly have here.
commit 1f25df2eff5b25f52c139d3ff31bc883eee9a0ab
Author: Helge Deller
Date: Fri Oct 10 22:20:17 2014 +0200
parisc: Reduce SIGRTMIN from 37 to 32 to behave l
Package: linux
Version: 3.16
Severity: bug
Tags: patch
I just noticed during an "apt-get install gnome-core" run, that hppa lacks the
bluetooth stack.
The problem is, that gnome pulls in the bluez package which then fails to
install, because the kernel lacks bluetooth support. In the end, I can
could you please temporarily add this hppa-specific patch to the debian
kernel sources?
...
diff --git a/arch/parisc/Makefile b/arch/parisc/Makefile
index 7187664..5db8882 100644
--- a/arch/parisc/Makefile
+++ b/arch/parisc/Makefile
@@ -48,7 +48,12 @@ cflags-y := -pipe
# These flags should
On 09/22/2014 09:24 AM, Uwe Kleine-König wrote:
diff --git a/arch/parisc/Makefile b/arch/parisc/Makefile
--- a/arch/parisc/Makefile
+++ b/arch/parisc/Makefile
# These flags should be implied by an hppa-linux configuration, but they
# are not in gcc 3.2.
-cflags-y += -mno-space-regs -mfa
Package: linux
Version: 3.16.3-2
Severity: bug
Tags: patch
Dear Debian Kernel maintainers,
could you please temporarily add this hppa-specific patch to the debian
kernel sources?
Currently the 64bit hppa kernel gets miscompiled by gcc-4.8 and as such
it will not boot.
The attached patch fixes
Package: linux
Version: 3.14
Severity: bug
Tags: patch
64bit (but not 32bit) parisc machines (like the C8000) do provide a BMC with
IPMI support.
This patchs adds IPMI support to the 64bit debian kernel.
Please apply to the next kernel.
Thanks,
Helge
diff -up ./debian/config/hppa/config.parisc6
Package: linux
Version: 3.14
Severity: bug
Tags: patch
In older kernels on parisc we had troubles linking the kernel modules for the
xfs filesystem because some symbols could then not be resolved due to the size
of the xfs module. That was probably the reason, why xfs was not provided as
udeb i
.
I think it makes sense to pre-initialize FSTYPE to the value "unknown" before
calling fstype. That way the program logic will continue correctly if something
with the fstype program is wrong.
Attached script fixes this.
Please apply.
Signed-off-by: Helge Deller
diff -up ./scripts/fun
Hi Ben,
On 02/10/2014 02:15 AM, Ben Hutchings wrote:
> You could add a new drm-modules udeb, but I suggest you reuse the name
> fb-modules which is already defined in debian/installer/package-list.
> The list of modules is very much architecture-specific so add it under
> debian/installer/hppa/mod
Package: linux
Version: 3.13
Severity: wishlist
Tags: patch
Hello,
this is a follow-up to bug
http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=721191
In that bugzilla I originally asked to add the following config entries to
./debian/config/hppa/config.parisc64-smp:
+# and for ATI FireGL DRM
Package: linux
Version: 3.13
Severity: bug
Tags: patch
As soon as the debian kernel will start with kernel 3.13, please remove the
CONFIG_MLONGCALLS=y option as it's then not any longer needed. The option is
still needed in the <= 3.12 kernel.
(This is a follow-up on Bug# 721191)
Index: linux/d
Package: linux
Version: 3.12
Severity: bug
Tags: patch
In Bug# 721191 we removed the parisc-smp and parisc64 (non-SMP) kernel variants.
Sadly I forgot to correct the kernel versions in the
debian/installer/hppa/kernel-versions file, so that the final build stage
failed because it tried to packag
Hi Ben,
On 12/06/2013 04:01 AM, Ben Hutchings wrote:
> On Sun, 2013-09-08 at 22:26 +0200, Helge Deller wrote:
>> After the request to reduce the kernels to e.g. SMP-only, my thought was
>> to provide only 32bit-UP and 64bit SMP kernels.
>> To be sure I asked on the parisc ma
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
On 09/08/2013 06:30 PM, Ben Hutchings wrote:
> On Wed, 2013-08-28 at 23:22 +0200, Helge Deller wrote:
>> +# For the IDE CDROM in C8000 workstation
>> +CONFIG_IDE=m
>> +CONFIG_BLK_DEV_SIIMAGE=m
>
> Why not CONFIG_PATA_SIL6
On 09/08/2013 04:19 PM, Bastian Blank wrote:
> On Wed, Aug 28, 2013 at 11:53:58PM +0200, Helge Deller wrote:
>> On 08/28/2013 11:35 PM, Bastian Blank wrote:
>>> Looks reasonable. But please send further changes to remove the
>>> non-smp kernels.
>> I can do tha
On 08/28/2013 11:35 PM, Bastian Blank wrote:
> On Wed, Aug 28, 2013 at 11:22:09PM +0200, Helge Deller wrote:
>> It would be nice, if you could apply this patch to your linux
>> source code tree.
>
> Looks reasonable. But please send further changes to remove the
> non-smp
In the file "debian/installer/hppa/modules/hppa/pata-modules" I added an entry
for the "siimage" module (for the IDE CDROM). Maybe it would be better, if this
entry could be moved to the generic "pata-modules" file instead? But I leave
this decision up to you...
Thank
On 04/02/2010 09:35 PM, John David Anglin wrote:
> On Fri, 02 Apr 2010, NIIBE Yutaka wrote:
>
>> NIIBE Yutaka wrote:
>>> To have same semantics as other archs, I think that VIPT-WB cache
>>> machine should have cache flush at ptep_set_wrprotect, so that memory
>>> of the page has up-to-date data.
Hmm...
I just marked this bug "grave", but I'm not sure if it should be "important"
instead. Please advise...
Fact is, that the hppa 2.6.26-2 kernel, as it's currently available, has a
major bug, which can easily hang and DOS the full machine under various loads.
I can reproduce this bug with m
e Used by
ipv6 493320 70
reiserfs 461624 0
nfs 300704 0
lockd 144456 1 nfs
nfs_acl 5592 1 nfs
sunrpc382312 3 nfs,lockd,nfs_acl
msdos 15032 0
fat 91248 1 msdos
Hel
On 07/31/2009 08:49 PM, Carlos O'Donell wrote:
[...]
However, on 64-bit the long format of ldd has a 16-bit signed
immediate offset (0x), meaning it can reach +0x7fff e.g. 4095 GOT
slots.
Do you have the time to test something out?
* Make this conditional on 32-bit vs. 64-bit and allow for
On 07/31/2009 09:03 PM, John David Anglin wrote:
Only 32-bit targets have the 14-bit signed immediate offset (0x3fff),
which becomes a 13-bit limit when loading positive offsets e.g.
+0x1fff or 1023 GOT slots.
Can't we offset the table and double the number of entries?
Dave,
Can you explain t
dann frazier wrote:
> On Tue, Jan 06, 2009 at 09:26:33AM -0700, dann frazier wrote:
>> On Tue, Jan 06, 2009 at 10:08:39AM +0100, Helge Deller wrote:
>>> Patches which solves the xfs loading bug on parisc has been accepted
>>> upstream.
>>> Mainstrea
Patches which solves the xfs loading bug on parisc has been accepted upstream.
Mainstream Kernel 2.6.29 will contain the fix.
Description of the problem:
http://marc.info/?l=linux-kernel&m=123055968113465&w=2
Needed patches which were accepted upstream:
a) module: fix module loading failure of la
I've just sent two patches which do solve this problem for review to Linux
kernel mailing list.
Description of the problem:
http://marc.info/?l=linux-kernel&m=123055968113465&w=2
Two patches:
http://marc.info/?l=linux-kernel&m=123055978413612&w=2
http://marc.info/?l=linux-kernel&m=12305598641374
Moritz Muehlenhoff wrote:
> On Tue, Dec 23, 2008 at 12:35:51PM +0100, Helge Deller wrote:
>> Moritz Muehlenhoff wrote:
>>>> The boot-kernel (2.6.18) does not detect this keyboard on the HIL bus.
>>>> It seems the needed .config values are not set when it was built
Moritz Muehlenhoff wrote:
>> The boot-kernel (2.6.18) does not detect this keyboard on the HIL bus.
>> It seems the needed .config values are not set when it was built.
>> To solve this problem, the boot kernel needs the "CONFIG_KEYBOARD_HIL_OLD=y"
>> option set.
>> Additionally, all other "HIL" o
61 matches
Mail list logo
