Bug#1059676: kernel FTBFS on hppa
This kernel bug is now fixed, since binutils will now support hppa64 binaries as well. See bz #1059674
Bug#1059676: kernel FTBFS on hppa
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-automatic-dbgsym -Xvmlinux -Xvmlinuz -Xvmlinuz-6.6.8-parisc64
dh_install
dh_installdocs
dh_installchangelogs
dh_installexamples
dh_installman
dh_installudev
dh_bugfiles
dh_ucf
dh_lintian
dh_icons
dh_link
dh_compress
dh_fixperms
dh_missing
dh_makeshlibs
objdump: debian/linux-image-6.6.8-parisc64/boot/vmlinuz-6.6.8-parisc64: file
format not recognized
dh_makeshlibs: error: objdump -p
debian/linux-image-6.6.8-parisc64/boot/vmlinuz-6.6.8-parisc64 returned exit
code 1
make[2]: *** [debian/rules.real:406: binary_image] Error 25
The kernel commit e30336ff6519e31077b27210f595ea7fbd23a2c9
("Don't run dh_strip on vmlinuz") worked around the issue once.
But this patch can fix the issue too:
diff -up ./templates/image.control.in.org ./templates/image.control.in
--- ./templates/image.control.in.org2023-12-29 20:32:43.138447385 +0100
+++ ./templates/image.control.in2023-12-29 20:33:08.281814898 +0100
@@ -6,6 +6,7 @@ Build-Depends:
kernel-wedge (>= 2.105~),
# used by kernel-wedge (only on Linux, thus not declared as a dependency)
kmod,
+ binutils-multiarch [hppa]
Depends: kmod, linux-base (>= 4.3~), ${misc:Depends}
Recommends: firmware-linux-free
Suggests: linux-doc-@version@, debian-kernel-handbook
The best solution is probably to fix binutils for hppa to cope
with 32- and 64-bit hppa binaries. For that I opened ticket #1059674
Helge
Bug#1040981: klibc-utils: segfault executing armhf binaries under qemu-user
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) - core dumped Segmentation fault (core dumped) what does this show?: QEMU_STRACE=1 qemu-arm-static -d cpu ./fstype --help I still believe, that the problem is that qemu's brk(NULL) doesn't return a page-aligned address, which will have lots of other side-effects. (see Andreas' RISC-V crash here: https://lists.nongnu.org/archive/html/qemu-devel/2023-07/msg00645.html) Helge
Bug#1040981: klibc-utils: Segmentation fault while executin klibc binaries in armhf architecture under qemu-user
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...@toshiba-tsip.com, 1040...@bugs.debian.org, pkg-qemu-de...@lists.alioth.debian.org Cc: dinesh.ku...@toshiba-tsip.com Betreff: Bug#1040981: klibc-utils: Segmentation fault while executin klibc binaries in armhf architecture under qemu-user retitle 1040981 klibc-utils: segfault executing armhf binaries under qemu-userthanksvenkata.p...@toshiba-tsip.com dixit:>Follow below steps to reproduce this issue>```>$ sudo debootstrap --arch=arm bookworm arm-bookworm-rootfs/ http://deb.debian.org/debian/>$ sudo chroot arm-bookworm/ apt-update && apt install -y klibc-utils>$ sudo chroot arm-bookworm/ /usr/lib/klibc/bin/fstype --help>qemu: uncaught target signal 11 (Segmentation fault) - core dumped>Segmentation fault>```Same when just copying klibc-m13AniKHUCMUNN8mXSUhIi8CUSA.so outof libklibc_2.0.12-1_armhf.deb into /lib/ and extracting fstypefrom klibc-utils_2.0.12-1_armhf.deb… however it works both on areal-metal ARM box (amdahl.d.o) and a statically(!) linked mkshagainst klibc :/My guess here is that it’s, as usual, the fault of qemu-user,which has multiple outstanding emulation bugs, some of whichaffecting klibc-built binaries especially, though this, sincea statically linked mksh works, is probably an issue with howqemu-user handles .interp *shrug*Since your one-stage debootstrap succeeds, can you not do theremaining steps booting into the image-under-preparation andrun them there? Here, qemu-system-armhf should probably suffice.I know, it’s just as a workaround, until the people in questionfigure out why this happens.bye,//mirabilos-- Solange man keine schmutzigen Tricks macht, und ich meine *wirklich*schmutzige Tricks, wie bei einer doppelt verketteten Liste beidePointer XORen und in nur einem Word speichern, funktioniert Boehm ganzhervorragend. -- Andreas Bogk über boehm-gc in d.a.s.r
Bug#1036818: linux on armel/armhf: Perl library unable to access get CPU info from /proc/cpu or kstat
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 of the output of /proc/cpuinfo for ARM, e.g. like this: https://gitlab.com/qemu-project/qemu/-/commit/e0174afeea23e56765db56fbbe465ed1fcbdd07a Helge
Bug#1027915: systemd requires /run to be mounted with a minimum size of 20MB
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 "${RUNSIZE}" ] || [[ "${RUNSIZE}" \< "20" ]]; then
This is as bashism and init runs with dash as far as I can see.
Hmm... I did tested it, at it seemed to work...
Which part of that line exactly do you think is problematic?
I'm open for any other idea how to code it.
Also note that RUNSIZE may legitimately be given as "1g" or "19%", both
of which should work.
Both will work, because I assume that on such systems you probably have more
than 200MB RAM
and thus my patch won't touch the user-provided value at all.
I suggest just not handling the case where RUNSIZE
is set by the user
Yes, I fully agree with you and had hoped to implement it that way.
Ideally RUNSIZE shouldn't be changed if it was already provided.
But the problem is, that on some/many systems RUNSIZE is *automatically*
provided and added to
the bootloader via a default value (of 10%) given in
/etc/initramfs-tools/update-initramfs.conf.
So, even if the user didn't changed or provided anything, the 10% is always set
and thus my check would never trigger
and letting them break their system however they
like rather than risk breaking legitimate configuration.
Again, the default value is the problem...
+ read MemTotal mem_kb rest < /proc/meminfo
+ # systemd requires at minumum 16MB for /run, so reserve
+ # 20MB for machines which have less than 200MB RAM
+ if [ "$mem_kb" -lt "20" ]; then
+ RUNSIZE=20M # for machines <= 200MB RAM
Given that you initialize a default here, I think it would make the code
more obvious if you pulled the 10% default 4 lines later into an else
branch.
Not sure I understand this...?
+ fi
+fi
+
mount -t tmpfs -o "nodev,noexec,nosuid,size=${RUNSIZE:-10%},mode=0755" tmpfs
/run
mkdir -m 0700 /run/initramfs
Helmut
Thank you Helmut!
Helge
Bug#1027915: systemd requires /run to be mounted with a minimum size of 20MB
The attached patch ensures that the /run mount point
is always mounted with at least 20MB.
This is important since systemd requires at least 16MB
in /run, otherwise it will give errors and warnings and
will refuse to boot further after an emergency shell.
This patch has been tested on x86 (with VirtualBox VMs)
in configurations with 160MB RAM and 900MB RAM, as well
on a debian parisc installation with 160MB RAM.
This patch will adapt the size of /run, even if the
default value of 10% (of physical memory) is given
in the /etc/initramfs-tools/update-initramfs.conf file
(e.g. on x86).
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}" ] || [[ "${RUNSIZE}" \< "20" ]]; then
+ read MemTotal mem_kb rest < /proc/meminfo
+ # systemd requires at minumum 16MB for /run, so reserve
+ # 20MB for machines which have less than 200MB RAM
+ if [ "$mem_kb" -lt "20" ]; then
+ RUNSIZE=20M # for machines <= 200MB RAM
+ fi
+fi
+
mount -t tmpfs -o "nodev,noexec,nosuid,size=${RUNSIZE:-10%},mode=0755" tmpfs /run
mkdir -m 0700 /run/initramfs
Bug#999915: (no subject)
I think the patch I sent in #1027915 should fix this issue: https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=1027915#24
Bug#1027915: systemd requires /run to be mounted with a minimum size of 20MB
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 principle. However, it is /usr/share/initramfs-tools/init that performs the mount, so that's what would need changing. Ah, ok. Thanks Helmut! As a workaround for your situation, I suggest adding a kernel parameter initramfs.runsize=20M. Yes, that should work. Would you be able to provide a patch here? I think that if a runsize is given, it should be honoured, so it would probably work like: if test -z "$RUNSIZE"; then if system_has_at_least_200mb_ram; then RUNSIZE=10% else RUNSIZE=20M fi fi Yes, I'll try to send a patch. I just wonder, what's the best way to get the amount of physical memory? Something like this should work which gives size in kB: mem_kb=$(grep MemTotal /proc/meminfo | (read txt mem txt2; echo $mem)) && echo $mem_kb Is there a better way? I think glibc isn't running in initramfs, so "getconf _PHYS_PAGES" will probably not work? Helge
Bug#959768: [PATCH] initramfs-tools/hook-functions: Fix libgcc_s.so.1 dependency
>> 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
Re: How to define kernel meta-package successor?
* 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-image-parisc-smp)? > > How can this be realized in the debian kernel sources? > > We have to re-add the old meta-packages as transitional packages. They > should go in a new control template. I looked at this commit: commit 37f6d08a862e63263bafa057803ea2e2082c7778 Author: Bastian Blank Date: Tue Jun 20 13:08:39 2006 + * debian/bin/gencontrol.py: Remove meta packages. * debian/templates/control.extra.in: Remove transition packages. Based on that I added two entries. It seems to work. Do I miss something, or any other suggestions? diff --git a/debian/templates/control.extra.in b/debian/templates/control.extra.in index 6c2fde90d619..2413ec0ec4ce 100644 --- a/debian/templates/control.extra.in +++ b/debian/templates/control.extra.in @@ -24,3 +24,21 @@ Multi-Arch: foreign Description: Compiler for Linux on x86 (meta-package) This package depends on GCC of the appropriate version and architecture for Linux on amd64, i386 and x32. + +Package: linux-image-parisc64-smp +X-Version-Overwrite-Epoch: 1 +Architecture: hppa +Section: base +Priority: extra +Depends: linux-image-parisc64 +Description: Linux kernel for 64-bit parisc64 SMP machines - transition package + This package is for transition only. + +Package: linux-image-parisc-smp +X-Version-Overwrite-Epoch: 1 +Architecture: hppa +Section: base +Priority: extra +Depends: linux-image-parisc +Description: Linux kernel for 32-bit parisc SMP machines - transition package + This package is for transition only. > We would need to set a deadline by which people need to upgrade, after > which the transitional packages would be dropped. (For release > architectures, this would be the next stable release.) Even if hppa isn't a release architecture I think it's OK to have the same requirements and time frames. Helge
How to define kernel meta-package successor?
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 superfluous. So, since commit fc6f1855ec7f
("[hppa] Merge parisc SMP- and UP-kernels.") we now build only two kernel
variants, one for 32bit UP & SMP, and one for 64bit UP & SMP:
linux-image-parisc
linux-image-parisc64
My problem is now:
People installed linux-image-parisc-smp in the past for SMP machines.
"apt upgrade" does not upgrade to "linux-image-parisc" which it now should
and a newer "linux-image-parisc-smp" packages are of course not available.
This can be seen in this example (it stays at kernel 4.19, but I'd like it to
go to 5.6.14):
root@debian:~# dpkg -l | grep linux-image
ii linux-image-4.19.0-5-parisc-smp 4.19.37-6 hppa
Linux 4.19 for multiprocessor 32-bit PA-RISC
ii linux-image-parisc-smp 4.19+105 hppa
Linux for multiprocessor 32-bit PA-RISC (meta-package)
root@debian:~# apt search linux-image-parisc
linux-image-parisc/unstable 5.6.14-1 hppa
Linux for 32-bit PA-RISC (meta-package)
root@debian:~# apt upgrade
0 upgraded, 0 newly installed, 0 to remove and 0 not upgraded.
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-image-parisc-smp)?
How can this be realized in the debian kernel sources?
Thanks,
Helge
Bug#959768: [PATCH] initramfs-tools/hook-functions: Fix libgcc_s.so.1 dependency
Due to Debian bug #950254 the hook-functions copies libgcc_s.so.1 into
the initramfs image. But this breaks architectures which ship other
versions of libgcc_s, e.g. hppa (libgcc_s.so.4) or m68k (libgcc_s.so.2).
Fix it by searching the relevant libgcc_so files.
The fix is modelled after the btrfs 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
libpthread.so")
diff -up ./hook-functions.org ./hook-functions
--- ./hook-functions.org2020-05-27 21:57:26.994595173 +
+++ ./hook-functions2020-05-27 21:57:30.182574623 +
@@ -182,7 +182,7 @@ copy_file() {
# Location of the image dir is assumed to be $DESTDIR
# We never overwrite the target if it exists.
copy_exec() {
- local src target x nonoptlib ret
+ local src target x nonoptlib ret libgcc
src="${1}"
target="${2:-$1}"
@@ -209,7 +209,10 @@ copy_exec() {
# Handle common dlopen() dependency (Debian bug #950254)
case "${x}" in
*/libpthread.so.*)
- copy_exec "${x%/*}/libgcc_s.so.1" || return
+ LIBC_DIR=$(dirname "${x}")
+ find -L "$LIBC_DIR" -maxdepth 1 -name 'libgcc_s.*'
-type f | while read -r libgcc; do
+ copy_exec "${libgcc}" || return
+ done
;;
esac
Bug#961299: [PATCH] Don't run dh_strip on vmlinuz
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 broke the kernel build on the hppa architecture. Since compat level 12, dh_strip runs the "strip" command on any vmlinuz* files, which wasn't the case before. On hppa the 64-bit build needs to run "hppa64-linux-strip" instead of "strip". Fix it by adding "vmlinuz" to the exclude list of dh_strip, and thus behave as compat level 9 did before. Tested on hppa and x86-64. Ok to commit, or any other idea on how to fix it? Helge diff --git a/debian/rules.real b/debian/rules.real index e73588b4093c..af1d246f3b27 100644 --- a/debian/rules.real +++ b/debian/rules.real @@ -447,7 +447,7 @@ endif +$(MAKE_SELF) \ install-image_$(ARCH)_$(FEATURESET)_$(FLAVOUR)_bug \ PACKAGE_DIR='$(PACKAGE_DIR)' PACKAGE_NAME='$(PACKAGE_NAME)' REAL_VERSION='$(REAL_VERSION)' - dh_strip --no-automatic-dbgsym -Xvmlinux + dh_strip --no-automatic-dbgsym -Xvmlinux -Xvmlinuz ln -sf linux-image.NEWS debian/$(PACKAGE_NAME).NEWS +$(MAKE_SELF) install-base
Bug#961299: Acknowledgement (FTBFS: debhelper compatibility level 12 breaks linux kernel build on hppa/parisc)
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 vmlinuz file, while with compat level 12, strip is now executed like this and thus fails: strip --remove-section=.comment --remove-section=.note --strip-unneeded debian/linux-image-5.6.0-1-parisc64/boot/vmlinuz-5.6.0-1-parisc64 strip: debian/linux-image-5.6.0-1-parisc64/boot/vmlinuz-5.6.0-1-parisc64: file format not recognized dh_strip: error: strip --remove-section=.comment --remove-section=.note --strip-unneeded debian/linux-image-5.6.0-1-parisc64/boot/vmlinuz-5.6.0-1-parisc64 returned exit code 1 Any chance we can add "-Xvmlinuz" to the dh_strip command in rules.real?
Bug#961299: FTBFS: debhelper compatibility level 12 breaks linux kernel build on hppa/parisc
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=hppa During build a 32-bit Linux kernel and a 64-bit Linux kernel is built. The 32-build builds succeeds, the 64-bit build fails. The 64bit build fails like this: make[3]: Leaving directory '/home/deller/build/linux/linux-5.6.7' dh_strip --no-automatic-dbgsym -Xvmlinux strip: debian/linux-image-5.6.0-1-parisc64/boot/vmlinuz-5.6.0-1-parisc64: file format not recognized dh_strip: error: strip --remove-section=.comment --remove-section=.note --strip-unneeded debian/linux-image-5.6.0-1-parisc64/boot/vmlinuz-5.6.0-1-parisc64 returned exit code 1 dh_strip: error: Aborting due to earlier error Reverting this debian commit fixes the build again: commit 59a5af36cbf1cc01ef48b91719f999a699d99fab Author: Ben Hutchings Date: Sun Apr 19 19:49:03 2020 +0100 Use debhelper compatibility level 12 debhelper started complaining about level 9, so it's time to upgrade again. * Build-Depend on debhelper-compat and remove debian/compat (also in the signed package template) ... So, apparently something changed how debhelper starts the strip command. Please note, that for a 64-bit vmlinux file, hppa64-linux-gnu-strip is needed instead of hppa-linux-gnu-strip although I'm not sure if this is the problem. Any idea? Helge
Bug#959070: klibc-utils: fstype falsely claims to need an executable stack
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 >> root@sevm:~/pol# execstack -c /usr/lib/klibc/bin/fstype >> root@sevm:~/pol# /usr/lib/klibc/bin/fstype < /dev/sda2 >> FSTYPE=btrfs >> FSSIZE=719360278528 >> >> The fstype program is listed as needing an executable stack, which will cause >> it to crash when run on a system with a security policy preventing executable >> stacke. If you clear the execstack bit it appears to work correctly. > [...] > > I've fixed this upstream but not made a new release yet: > > https://git.kernel.org/pub/scm/libs/klibc/klibc.git/commit/?id=9d8d648e604026b32cad00a84ed6c29cbd157641 On hppa/parisc we still need executable stacks for the signal trampoline return code. Might your patch then maybe break fstype on hppa? I didn't tested it... Helge signature.asc Description: OpenPGP digital signature
Bug#864453: fanotify07 LTP testcase hangs process
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 don't do it. I think the upstream maintainer wrote something in his commit message that fixing this issue in backports might be hard/impossible. When running the testsuite, the kernel additionally reported that processes may hang, and tainted itself accordingly. Sadly I don't have the exact kernel message at hand right now. Helge
Bug#864453: fanotify07 LTP testcase hangs process
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_get_response()" * * Kernel hangs should be fixed by: * 05f0e38724e8 "fanotify: Release SRCU lock when waiting for userspace response" It seems upstream commit 05f0e38724e8 "fanotify: Release SRCU lock when waiting for userspace response" is missing in stable kernel 4.9.30 (and debian kernel), which explains why the testcase hangs. I didn't checked if the kernel crash fix is in 4.9.30. Can you backport at least the commit 05f0e38724e8 ? Thanks, Helge
Bug#837588: vmlinux in linux-image packages is unstripped
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: >>>>> >>>>> 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: >>> >>> That's strange, because it's not really an addition (we've always run >>> dh_strip). >>> >>> [...] > > Can you try adding -X$(IMAGE_FILE)? Yes, this seems to work: - dh_strip --no-automatic-dbgsym + dh_strip --no-automatic-dbgsym -X$(IMAGE_FILE) I had to restart my test-kernel-build because of another error, but from the logs the build didn't failed now because of this dh_strip line any longer. I'll have final convidence tomorrow. So, please add "-X$(IMAGE_FILE)" for now. > I have no idea how to access any hppa porterbox myself. If you need access once, just let me know. Maybe, if we have more machines up again, I will try to make one accessible as porterbox. Helge
Bug#837588: vmlinux in linux-image packages is unstripped
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. >> >> The addition of >> dh_strip --no-automatic-dbgsym >> >> broke the 64bit parisc/hppa kernel build: > > That's strange, because it's not really an addition (we've always run > dh_strip). > > [...] >> I'm currently testing this patch (not sure if this is a good patch though): >> - dh_strip --no-automatic-dbgsym >> + $(CROSS_COMPILE)strip --remove-section=.comment --remove-section=.note >> '$(DIR)/$(IMAGE_FILE)' > > This is not correct because we do want to strip the userland tools that > get included in powerpc builds. We could add -Xvmlinux to the dh_strip > command to make sure it doesn't touch the kernel. Since the error is: strip:debian/linux-image-4.7.0-1-parisc64-smp/boot/vmlinux-4.7.0-1-parisc64-smp: File format not recognized I think you would need something like -X$(IMAGE_FILE) > vmlinux is being stripped using $(CROSS_COMPILE)objcopy, but I wonder > whether we should be using hppa64-linux-gnu-objcopy instead for the 64- > bit kernel? I think $(CROSS_COMPILE)objcopy expands to hppa64-linux-gnu-objcopy when packaging the 64bit kernel. At least my patch worked which seems to indicate that. Anyhow, I'm fine with any patch you agree on and which fixes the problem. Helge signature.asc Description: OpenPGP digital signature
Bug#837588: vmlinux in linux-image packages is unstripped
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-smp/boot/vmlinux-4.7.0-1-parisc64-smp: File format not recognized dh_strip: strip --remove-section=.comment --remove-section=.note debian/linux-image-4.7.0-1-parisc64-smp/boot/vmlinux-4.7.0-1-parisc64-smp returned exit code 1 debian/rules.real:381: recipe for target 'install-image_hppa_none_parisc64-smp' failed I'm currently testing this patch (not sure if this is a good patch though): - dh_strip --no-automatic-dbgsym + $(CROSS_COMPILE)strip --remove-section=.comment --remove-section=.note '$(DIR)/$(IMAGE_FILE)' Helge
Bug#837588: hppa: Please disable CONFIG_FTRACE for hppa architecture
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 wrote: >>>>> >>>>> So, can you please deactivate CONFIG_FTRACE completely for 32- and >>>>> 64bit hppa configs? >>>>> Is it sufficient to add "CONFIG_FTRACE=n" to >>>>> debian/config/hppa/config ? >>>> >>>> Done. Argh - this didn't fixed the size issues on hppa. I was under the wrong assumption, that CONFIG_FTRACE (which was implemented in kernel 4.7 for the first time) was the culprit which increased the kernel size. This assumption was wrong. The attached patch finally fixes the issue. It re-enables the CONFIG_FTRACE option (which is set by your upper config files), and disables CONFIG_DEBUG_INFO which was now suddenly enabled by the debian kernel 4.7 (it wasn't in 4.6!). I enabled CONFIG_DEBUG_RODATA to write-protect kernel memory as well. The main problem was, that the generated dwarf debug info increases the kernel vmlinux image from 17MB to 97MB in disk size. I've compile- and run-tested the patch and built a +b1 kernel. Can you apply the attached patch on top of current git? I can commit it myself as well if you like. Thanks! Helge diff -up ./config/hppa/config.org ./config/hppa/config --- ./config/hppa/config.org 2016-09-21 21:34:30.894455256 +0200 +++ ./config/hppa/config 2016-09-22 20:48:48.314036351 +0200 @@ -571,15 +571,10 @@ CONFIG_SGETMASK_SYSCALL=y CONFIG_SYSFS_SYSCALL=y ## -## file: kernel/trace/Kconfig -## -#. As of 4.7 this has a huge size cost; see #837588 -# CONFIG_FTRACE is not set - -## ## file: lib/Kconfig.debug ## CONFIG_DEBUG_STACKOVERFLOW=y +CONFIG_DEBUG_RODATA=y # CONFIG_LOCKUP_DETECTOR is not set ## diff -up ./config/hppa/defines.org ./config/hppa/defines --- ./config/hppa/defines.org 2016-09-22 09:38:55.695723334 +0200 +++ ./config/hppa/defines 2016-09-22 09:38:36.771730760 +0200 @@ -6,6 +6,7 @@ kernel-arch: parisc image-file: vmlinux # linux-signed only works for architectures in the main archive signed-modules: false +debug-info: false [image] suggests: palo signature.asc Description: OpenPGP digital signature
Bug#837588: hppa: Please disable CONFIG_FTRACE for hppa architecture
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? >>> Is it sufficient to add "CONFIG_FTRACE=n" to >>> debian/config/hppa/config ? >> >> Done. > > But this changes the module ABI, resulting in FTBFS. From what you've > said on this bug, I'm not sure whether the previous version (4.7.2-1) > was at all usable. I was able to boot the 4.7.2-1 kernel on one of my machines where /boot was big enough. The hppa buildd servers have smaller /boot partitions though nd the kernel was not useable/installable there. > If not then I will delete the ABI reference for > hppa so the change is ignored. I'd propose to delete the ABI reference. I'm not aware of any hppa-relevant out-of-tree kernel modules either. Helge signature.asc Description: OpenPGP digital signature
Bug#837588: hppa: Please disable CONFIG_FTRACE for hppa architecture
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) which leads that the 64bit vmlinux kernel file for 4.7 becomes around 99MB, while vmlinux for kernel 4.6 was just around 17MB. This size wouldn't be a real problem itself, but sadly the default /boot partition is currently maximum 128 MB in size which is not able to keep the vmlinux file plus the size for the initrd image (which is a lot bigger than 100MB then). That leads to the fact, that people who have a default hppa installation will not be able to install the new kernel (and don't have space in /boot to keep other older images either). So, can you please deactivate CONFIG_FTRACE completely for 32- and 64bit hppa configs? Is it sufficient to add "CONFIG_FTRACE=n" to debian/config/hppa/config ? Thanks! Helge PS: I'm still working on upstream ftrace support for hppa. It's not complete yet, so we don't loose to much when we disable ftrace again now. Further more I will adjust the debian installer to create bigger /boot partitions so that we can enable it later again.
Re: linux 4.6 FTBFS on alpha
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 incompatible pointer type > [-Werror=incompatible-pointer-types] >retval = copy_strings_kernel(1, _arg, bprm); >^ > In file included from /«PKGBUILDDIR»/fs/binfmt_em86.c:14:0: > /«PKGBUILDDIR»/include/linux/binfmts.h:116:12: note: expected 'const char * > const*' but argument is of type 'char **' > extern int copy_strings_kernel(int argc, const char *const *argv, > ^ > /«PKGBUILDDIR»/fs/binfmt_em86.c:77:34: error: passing argument 2 of > 'copy_strings_kernel' from incompatible pointer type > [-Werror=incompatible-pointer-types] > retval = copy_strings_kernel(1, _name, bprm); > ^ > In file included from /«PKGBUILDDIR»/fs/binfmt_em86.c:14:0: > /«PKGBUILDDIR»/include/linux/binfmts.h:116:12: note: expected 'const char * > const*' but argument is of type 'char **' > extern int copy_strings_kernel(int argc, const char *const *argv, > ^ > > The conversion is safe but the C standard says it requires a cast. > This can easily be fixed by adding the cast, but I also wonder why we > still build this module. Even the Kconfig text says it's redundant > with binfmt_misc. What do you think? I don't know if it being used, but it seems that systemd takes care of autoloading binfmt_misc automatically, so IMHO I agree that it should be safe to simply disable binfmt_em86 from the debian alpha kernel. Question to the alpha kernel maintainers: Maybe binfmt_em86 should simply be dropped from the kernel source completely? Helge
Re: linux 4.6 FTBFS on hppa
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): relocation truncated to fit: > R_PARISC_PCREL22F against symbol `register_net_sysctl' defined in > .text.register_net_sysctl section in net/built-in.o > hppa64-linux-gnu-ld: net/built-in.o(.init.text+0x3298): cannot reach > register_net_sysctl > net/built-in.o: In function `ip_static_sysctl_init': > (.init.text+0x3298): relocation truncated to fit: R_PARISC_PCREL22F against > symbol `register_net_sysctl' defined in .text.register_net_sysctl section in > net/built-in.o > hppa64-linux-gnu-ld: net/built-in.o(.init.text+0x3404): cannot reach > register_net_sysctl > net/built-in.o: In function `ipfrag_init': > (.init.text+0x3404): relocation truncated to fit: R_PARISC_PCREL22F against > symbol `register_net_sysctl' defined in .text.register_net_sysctl section in > net/built-in.o > hppa64-linux-gnu-ld: net/built-in.o(.init.text+0x4c50): cannot reach > register_net_sysctl > net/built-in.o: In function `sysctl_ipv4_init': > net/ipv4/sysctl_net_ipv4.o:(.init.text+0x4c50): relocation truncated to fit: > R_PARISC_PCREL22F against symbol `register_net_sysctl' defined in > .text.register_net_sysctl section in net/built-in.o > hppa64-linux-gnu-ld: net/built-in.o(.init.text+0x4c88): cannot reach > unregister_net_sysctl_table > net/ipv4/sysctl_net_ipv4.o:(.init.text+0x4c88): relocation truncated to fit: > R_PARISC_PCREL22F against symbol `unregister_net_sysctl_table' defined in > .text.unregister_net_sysctl_table section in net/built-in.o > hppa64-linux-gnu-ld: net/built-in.o(.init.text+0x8b74): cannot reach > register_net_sysctl > net/built-in.o: In function `ipv6_frag_init': > (.init.text+0x8b74): relocation truncated to fit: R_PARISC_PCREL22F against > symbol `register_net_sysctl' defined in .text.register_net_sysctl section in > net/built-in.o > hppa64-linux-gnu-ld: net/built-in.o(.init.text+0x8c5c): cannot reach > unregister_net_sysctl_table > net/built-in.o: In function `ipv6_frag_init': > (.init.text+0x8c5c): relocation truncated to fit: R_PARISC_PCREL22F against > symbol `unregister_net_sysctl_table' defined in > .text.unregister_net_sysctl_table section in net/built-in.o > > It looks like we need to enable CONFIG_MLONGCALLS again (or change some > built-in things to modules, but I doubt there is much to be gained > there). Since 4.6~rc3-1~exp1 built successfully, I'm wondering if maybe something changed in the generic debian configs (or in the upstream kernel source) which could have led to this breakage? > It was previously disabled as you requested in bug #733897. Yes, but I tend to think that you are probably right to simply turn CONFIG_MLONGCALLS back on again. I do have kernel patches queued for kernel 4.7 which enable FTRACE support, and those will require CONFIG_MLONGCALLS most likely anyway then. Furthermore I just checked and I'm building my own test kernels usually with CONFIG_MLONGCALLS too, so in the long run we will probably not be able without this option. Can you turn CONFIG_MLONGCALLS back on for the next upload? Helge
Re: [PATCH] Fix hppa kernel crash at boot in block/blk-merge.c
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 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 attached patch avoids this crash by switching to compiling with >> "-O1" instead of "-O2" for a function in block/blk-merge.c (for hppa only). >> >> This patch is meant to be a temporary patch for the debian kernel, until we >> have been able to fix the real problem (in gcc and/or kernel code). >> >> Would it be possible to add this patch to the debian kernel tree for >> stable and experimental kernels in the meantime, so that we get bootable >> kernels on hppa again? > > Yes, but is this still needed when using gcc 5 (now used for all > architectures)? I need to check gcc-5. Regarding the patch to the parisc kernel, you can drop my request. We reverted a gcc-4.9 change, and now the kernel builds sucessfully again. Thanks! Helge
[PATCH] Fix hppa kernel crash at boot in block/blk-merge.c
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 attached patch avoids this crash by switching to compiling with
"-O1" instead of "-O2" for a function in block/blk-merge.c (for hppa only).
This patch is meant to be a temporary patch for the debian kernel, until we
have been able to fix the real problem (in gcc and/or kernel code).
Would it be possible to add this patch to the debian kernel tree for
stable and experimental kernels in the meantime, so that we get bootable
kernels on hppa again?
Thanks,
Helge
diff -up ./block/blk-merge.c.org ./block/blk-merge.c
--- ./block/blk-merge.c.org 2016-03-10 09:44:33.171141161 +0100
+++ ./block/blk-merge.c 2016-03-10 09:47:33.391119064 +0100
@@ -80,7 +80,15 @@ static inline unsigned get_max_io_size(s
return sectors;
}
-static struct bio *blk_bio_segment_split(struct request_queue *q,
+static struct bio *
+#ifdef __hppa__
+ /*
+* gcc-4.9 miscompiles this function at O2, leading to a kernel crash
at bootup.
+* So, let's temporarily compile this function with O1 until the bug is
fully analyzed and fixed.
+*/
+ __attribute__ ((optimize("O1")))
+#endif
+blk_bio_segment_split(struct request_queue *q,
struct bio *bio,
struct bio_set *bs,
unsigned *segs)
Bug#770102: PATCH: fix packaging the hppa kernel package
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 ... kernel-wedge find-dups 3.16.0-4-parisc some modules are in more than one package debian/pata-modules-3.16.0-4-parisc-di lib/modules/3.16.0-4-parisc/kernel/drivers/ata/libata.ko debian/ata-modules-3.16.0-4-parisc-di lib/modules/3.16.0-4-parisc/kernel/drivers/ata/libata.ko command exited with status 1 Thanks, Helge diff -up ./linux-3.16.7/debian/installer/hppa/modules/hppa/ata-modules.org ./linux-3.16.7/debian/installer/hppa/modules/hppa/ata-modules --- ./linux-3.16.7/debian/installer/hppa/modules/hppa/ata-modules.org 2014-11-05 22:27:31.0 +0100 +++ ./linux-3.16.7/debian/installer/hppa/modules/hppa/ata-modules 2014-11-13 14:58:24.0 +0100 @@ -1 +1,2 @@ #include ata-modules +libata - diff -up ./linux-3.16.7/debian/installer/hppa/package-list.org ./linux-3.16.7/debian/installer/hppa/package-list --- ./linux-3.16.7/debian/installer/hppa/package-list.org 2014-09-08 06:58:01.0 +0200 +++ ./linux-3.16.7/debian/installer/hppa/package-list 2014-11-13 22:38:11.0 +0100 @@ -12,7 +12,7 @@ Package: ide-modules Depends: kernel-image, ide-core-modules, nls-core-modules Package: pata-modules -Depends: kernel-image, scsi-core-modules +Depends: kernel-image, ata-modules, scsi-core-modules Package: fb-modules Depends: kernel-image
Bug#768297: fix udeb packaging on hppa
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 debian/linux-image-3.16.0-4-parisc/boot/vmlinux-3.16.0-4-parisc debian/kernel-image-3.16.0-4-parisc-di/boot/vmlinux-3.16.0-4-parisc install -d debian/kernel-image-3.16.0-4-parisc-di/lib/modules/3.16.0-4-parisc install -m 644 debian/linux-image-3.16.0-4-parisc/lib/modules/3.16.0-4-parisc/modules.builtin debian/linux-image-3.16.0-4-parisc/lib/modules/3.16.0-4-parisc/modules.order debian/kernel-image-3.16.0-4-parisc-di/lib/modules/3.16.0-4-parisc/ install -D -m 644 debian/linux-image-3.16.0-4-parisc/boot/System.map-3.16.0-4-parisc debian/kernel-image-3.16.0-4-parisc-di/boot/System.map-3.16.0-4-parisc kernel-wedge copy-modules 3.16.0-4 parisc 3.16.0-4-parisc kernel-wedge find-dups 3.16.0-4-parisc some modules are in more than one package debian/sata-modules-3.16.0-4-parisc-di lib/modules/3.16.0-4-parisc/kernel/drivers/ata/libata.ko debian/pata-modules-3.16.0-4-parisc-di lib/modules/3.16.0-4-parisc/kernel/drivers/ata/libata.ko debian/nic-usb-modules-3.16.0-4-parisc-di lib/modules/3.16.0-4-parisc/kernel/drivers/net/phy/libphy.ko debian/nic-modules-3.16.0-4-parisc-di lib/modules/3.16.0-4-parisc/kernel/drivers/net/phy/libphy.ko debian/scsi-modules-3.16.0-4-parisc-di lib/modules/3.16.0-4-parisc/kernel/drivers/scsi/sym53c8xx_2/sym53c8xx.ko debian/scsi-common-modules-3.16.0-4-parisc-di lib/modules/3.16.0-4-parisc/kernel/drivers/scsi/sym53c8xx_2/sym53c8xx.ko command exited with status 1 The attached tar.gz file to the debian/installer subdirectory fixes this. Can you please apply it for the next upload? It adds ata-modules and nic-shared-modules to both hppa/hppa64 directories and modifies the scsi-modules by removing sym53c8xx.ko module (which is already in scsi-common-modules. Thanks, Helge hppa_installer_debs.tgz Description: application/gzip
Bug#766635: kernel patch for hppa architecture
Source: kernel Version: 3.16.5-1 Severity: important Tags: patch Dear debian kernel maintainers, Can you please apply this hppa-arch-specific patch to the debian kernel 3.16.5 and keep it until you upgrade to sources of upstream kernel 3.18 ? Main reason for this patch is to make it possible to use systemd on hppa. Without this patch people who will by mistake install systemd (e.g. because of dependencies) will render their machines unbootable. The patch breaks the ABI on hppa, but in a way which will not affect people, because it changes the signals which are usually not used. This has been tested by installing and booting mixtures of glibc and kernel with corresponding patches. Since this patch affects kernel and glibc, I've opened this debian bug report for the glibc patch: http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=766605 Upstream Linux kernel commit (committed into kernel 3.18, as attached here) is 1f25df2eff5b25f52c139d3ff31bc883eee9a0ab http://git.kernel.org/cgit/linux/kernel/git/torvalds/linux.git/commit/?id=1f25df2eff5b25f52c139d3ff31bc883eee9a0abutm_source=anzwix Upstream glibc commit is: https://sourceware.org/git/?p=glibc.git;a=commit;h=13d845549e41823e6658122dcf268154bcbbcfde To better explain what we fix here, the glibc changelog description of Carlos is probably best (copied in here): This is a conscious ABI break for hppa. We find ourselves unable to run systemd because it expects SIGRTMIN+29 signals to be available and with hppa starting at 37 that exceeds the 64 signals available. It is arguable that the systemd code could compact their signal usage (the have a gap and don't check SIGRTMAX to see if they are over). However, that would require pursuing this upstream with systemd. The least work option is to make hppa more like other arches. The best option is to free up 3 signals for use with SIGXCPU, SIGXFSZ and SIGSTKFLT, and move those below 31. We make SIGSYS equal to SIGUNUSED as is expected. We remove SIGEMT and SIGLOST as HPUX signal we won't ever use. With that change we match all other machines. Given that these signals are so esoteric, testing by other users building minimal systems from scratch showed no problems. In fact Tcl fails to build if you make SIGEMT == SIGABRT, so we just removed SIGEMT (they use a large switch statement in C to handle signals, and I don't think it'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 del...@gmx.de Date: Fri Oct 10 22:20:17 2014 +0200 parisc: Reduce SIGRTMIN from 37 to 32 to behave like other Linux architectures This patch reduces the value of SIGRTMIN on PARISC from 37 to 32, thus increasing the number of available RT signals and bring it in sync with other Linux architectures. Historically we wanted to natively support HP-UX 32bit binaries with the PA-RISC Linux port. Because of that we carried the various available signals from HP-UX (e.g. SIGEMT and SIGLOST) and folded them in between the native Linux signals. Although this was the right decision at that time, this required us to increase SIGRTMIN to at least 37 which left us with 27 (64-37) RT signals. Those 27 RT signals haven't been a problem in the past, but with the upcoming importance of systemd we now got the problem that systemd alloctes (hardcoded) signals up to SIGRTMIN+29 which is beyond our NSIG of 64. Because of that we have not been able to use systemd on the PARISC Linux port yet. Of course we could ask the systemd developers to not use those hardcoded values, but this change is very unlikely, esp. with PA-RISC being a niche architecture. The other possibility would be to increase NSIG to e.g. 128, but this would mean to duplicate most of the existing Linux signal handling code into the parisc specific Linux kernel tree which would most likely introduce lots of new bugs beside the code duplication. The third option is to drop some HP-UX signals and shuffle some other signals around to bring SIGRTMIN to 32. This is of course an ABI change, but testing has shown that existing Linux installations are not visibly affected by this change - most likely because we move those signals around which are rarely used and move them to slots which haven't been used in Linux yet. In an existing installation I was able to exchange either the Linux kernel or glibc (or both) without affecting the boot process and installed applications. Dropping the HP-UX signals isn't an issue either, since support for HP-UX was basically dropped a few months back with Kernel 3.14 in commit f5a408d53edef3af07ac7697b8bc54a755628450 already, when we changed EWOULDBLOCK to be equal to EAGAIN. So, even if this is an ABI change, it's better to change it now
Bug#764524: Bluetooth support on HPPA kernel (with patch)
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't (fully) install gnome because of that. Attached patch fixes this by enabling the building of the bluetooth stack on hppa. Please apply for the next upload. (PS: Sparc seems to unset CONFIG_BT too - so it will probably run into the same issue) Thanks, Helge diff -up ./debian/config/hppa/config.org ./debian/config/hppa/config --- ./debian/config/hppa/config.org 2014-10-08 21:11:36.607895980 +0200 +++ ./debian/config/hppa/config 2014-10-08 21:11:59.639892592 +0200 @@ -593,12 +593,6 @@ CONFIG_FLATMEM_MANUAL=y # CONFIG_HAMRADIO is not set ## -## file: net/bluetooth/Kconfig -## -#. TODO -# CONFIG_BT is not set - -## ## file: net/decnet/Kconfig ## # CONFIG_DECNET is not set
Bug#762390: Patch for hppa arch
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 be implied by an hppa-linux configuration, but they # are not in gcc 3.2. -cflags-y += -mno-space-regs -mfast-indirect-calls +cflags-y += -mno-space-regs + +# -mfast-indirect-calls is only relevant for 32-bit kernels. FYI, this patch has now been pushed upstream and scheduled for stable kernel series: http://git.kernel.org/cgit/linux/kernel/git/torvalds/linux.git/commit/?id=d26a7730b5874a5fa6779c62f4ad7c5065a94723 Helge -- To UNSUBSCRIBE, email to debian-kernel-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: https://lists.debian.org/54233be2.1020...@gmx.de
Bug#762390: Patch for hppa arch
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 -mfast-indirect-calls +cflags-y += -mno-space-regs + +# -mfast-indirect-calls is only relevant for 32-bit kernels. Would it make sense to point out here that -mfast-indirect-calls is not only unneeded but bad until http://link.to/relevant-discussion is resolved? Yes, this makes sense, but there is no public visible discussion about it yet. It's in private mail between Dave and myself. Anyway, we decided to push this patch upstream, so I'll add some more comments in the (upstream) changelog then. Helge -- To UNSUBSCRIBE, email to debian-kernel-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: https://lists.debian.org/54206b2e.6040...@gmx.de
Bug#762390: Patch for hppa arch
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 one of the problems. Latest changes in gcc-4.8 made changes to the -mfast-indirect-calls option which now produces wrong code when compiling for 64bit. The problem is being worked on in upstream gcc-4.8, and we don't know yet if we will implement -mfast-indirect-calls for 64bit (which might introduce side-effects) or not. That's the reason why I don't want to push attached patch upstream yet. The second problem is, that gcc-4.9 (which is used in debian to bootstrap gcc-4.8) miscompiles one specific gcc-4.8 source code path and this bug is reported upstream in GCC PR: https://gcc.gnu.org/bugzilla/show_bug.cgi?id=63302 We work on that too. So, if you could apply the attached patch temporarily for now it would help us to get further. I will either send the patch upstream or we will fix the compiler. The decision is still pending, but I will inform you when this patch can be removed from debian kernel sources again (hopefully soon!). BTW: If you apply it, there is no need to trigger a new upload specifically for this bug/hppa... Thanks, Helge 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 be implied by an hppa-linux configuration, but they # are not in gcc 3.2. -cflags-y += -mno-space-regs -mfast-indirect-calls +cflags-y += -mno-space-regs + +# -mfast-indirect-calls is only relevant for 32-bit kernels. +ifndef CONFIG_64BIT +cflags-y += -mfast-indirect-calls +endif # Currently we save and restore fpregs on all kernel entry/interruption paths. # If that gets optimized, we might need to disable the use of fpregs in the
Bug#747482: Add IPMI drivers to 64bit parisc kernel
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.parisc64-smp.org ./debian/config/hppa/config.parisc64-smp --- ./debian/config/hppa/config.parisc64-smp.org 2014-05-09 10:59:19.997166749 +0200 +++ ./debian/config/hppa/config.parisc64-smp 2014-05-09 11:00:49.493146882 +0200 @@ -31,6 +31,15 @@ CONFIG_DRM_TTM=m CONFIG_DRM_RADEON=m ## +## file: drivers/char/ipmi/Kconfig +## +CONFIG_IPMI_HANDLER=m +CONFIG_IPMI_DEVICE_INTERFACE=m +CONFIG_IPMI_SI=m +CONFIG_IPMI_WATCHDOG=m +CONFIG_IPMI_POWEROFF=m + +## ## file: mm/Kconfig ## ## choice: Memory model
Bug#746506: add xfs udeb for hppa kernel [patch attached]
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 in the past. On new parisc kernels this problem is fixed, and the attached patch now adds the xfs modules again. Please apply. Thanks, Helge diff -up ./debian/installer/hppa/modules/hppa-parisc64-smp/xfs-modules.org ./debian/installer/hppa/modules/hppa-parisc64-smp/xfs-modules --- ./debian/installer/hppa/modules/hppa-parisc64-smp/xfs-modules.org 2014-04-23 15:44:16.101689773 +0200 +++ ./debian/installer/hppa/modules/hppa-parisc64-smp/xfs-modules 2014-04-23 15:44:26.277687708 +0200 @@ -0,0 +1 @@ +#include ../hppa/xfs-modules diff -up ./debian/installer/hppa/modules/hppa/xfs-modules.org ./debian/installer/hppa/modules/hppa/xfs-modules --- ./debian/installer/hppa/modules/hppa/xfs-modules.org 2014-04-23 15:44:01.541692733 +0200 +++ ./debian/installer/hppa/modules/hppa/xfs-modules 2014-04-23 15:45:15.717677728 +0200 @@ -0,0 +1 @@ +#include xfs-modules
Bug#745731: initialize FSTYPE variable
Package: initramfs-tools
Version: 0.115
Severity: normal
Tags: patch
On the hppa platform the fstype program from klibc crashed (details in
Bug#745660) which exposed a problem in the
get_fstype() shell function in file scripts/functions.
In this script, fstype is called like this:
eval $(fstype ${FS} 2 /dev/null)
if [ $FSTYPE = unknown ]
Since fstype crashed and returned nothing in the variable FSTYPE, FSTYPE
stayed empty instead of the value unknown and as such no further analysis via
blkid was done.
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 del...@gmx.de
diff -up ./scripts/functions.org ./scripts/functions
--- ./scripts/functions.org 2014-04-24 15:44:54.104641201 +0200
+++ ./scripts/functions 2014-04-24 15:45:35.809485678 +0200
@@ -307,6 +307,7 @@ get_fstype ()
# blkid has a more complete list of file systems,
# but fstype is more robust
+ FSTYPE=unknown
eval $(fstype ${FS} 2 /dev/null)
if [ $FSTYPE = unknown ] command -v blkid /dev/null 21 ; then
FSTYPE=$(blkid -o value -s TYPE ${FS})
Bug#738487: hppa patch for ATI FireGL in C8000 workstation
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/modules/hppa. thanks for the helpful explanations! Here are two patches to fix it: a) The patch (hppa-kernel.patch) is vs. trunk, which - uses MEGARAID_NEWGEN instead of MEGARAID_LEGACY (the legacy driver hangs my box), - uses CONFIG_DRM=y instead of =m (you proposed that to me in an earlier bug report) - adds the fb-modules package to installer/hppa/package-list (with standard priority because the radeon driver is necessary on a c8000 machine) b) The installer-hppa-modules.tgz file. - please extract it in the debian/installer/hppa/modules/ directory. - It creates the subfolder debian/installer/hppa/modules/hppa-parisc64-smp - The files in the subfolder are basically copies of the ones in hppa/ - Only exception is the (new) fb-modules file (as suggested by you above). It would be great if you could apply it before 3.13 :-) Thanks, Helge Index: config/hppa/config === --- config/hppa/config (revision 21047) +++ config/hppa/config (working copy) @@ -474,7 +474,7 @@ CONFIG_MEGARAID_NEWGEN=y CONFIG_MEGARAID_MM=m CONFIG_MEGARAID_MAILBOX=m -CONFIG_MEGARAID_LEGACY=m +# CONFIG_MEGARAID_LEGACY is not set ## ## file: drivers/scsi/pcmcia/Kconfig Index: config/hppa/config.parisc64-smp === --- config/hppa/config.parisc64-smp (revision 21047) +++ config/hppa/config.parisc64-smp (working copy) @@ -25,7 +25,9 @@ ## file: drivers/gpu/drm/Kconfig ## #. for ATI FireGL DRM in C8000 workstation -CONFIG_DRM=m +CONFIG_DRM=y +CONFIG_DRM_KMS_HELPER=y +CONFIG_DRM_TTM=m CONFIG_DRM_RADEON=m ## Index: installer/hppa/modules/hppa/scsi-modules === --- installer/hppa/modules/hppa/scsi-modules (revision 21047) +++ installer/hppa/modules/hppa/scsi-modules (working copy) @@ -6,7 +6,10 @@ st sym53c8xx zalon7xx -megaraid +megaraid ? +megaraid_mbox ? +megaraid_mm ? +megaraid_sas ? qlogicfas408 mptbase mptspi Index: installer/hppa/package-list === --- installer/hppa/package-list (revision 21047) +++ installer/hppa/package-list (working copy) @@ -13,3 +13,7 @@ Package: pata-modules Depends: kernel-image, scsi-core-modules + +Package: fb-modules +Depends: kernel-image +Priority: standard installer-hppa-modules.tgz Description: application/compressed-tar
Bug#738487: hppa patch for ATI FireGL in C8000 workstation
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 in C8000 workstation +CONFIG_DRM_RADEON=m +CONFIG_AGP=y +CONFIG_AGP_PARISC=y +CONFIG_VGA_ARB=y +CONFIG_VGA_ARB_MAX_GPUS=16 +CONFIG_DRM=y +CONFIG_DRM_KMS_HELPER=y +CONFIG_DRM_TTM=y +CONFIG_BACKLIGHT_LCD_SUPPORT=y In comment #55 (http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=721191#55) Ben wrote: +CONFIG_DRM=y Why should this be built-in? On the C8000 an ATI FireGL is the only built-in GFX card and it's only supported by the radeon DRM driver. So, if the driver isn't built-in, you won't be able to see the debian installer... [...] The driver won't be built-in, as you're setting CONFIG_DRM_RADEON=m. And it doesn't need to be built-in. It just needs to be in one of the module packages that's included in the installer initramfs. I think you'll need to create a new udeb for DRM drivers and then add this to the package lists for hppa images in the d-i repository. And in comment #70 (http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=721191#70) Ben wrote: - AGP/DRM are now modules. Otherwise we don't have any output on the C8000 machines. You might yet need to make them built-in, as nothing else ensures that AGP devices are initialised before DRM devices. In the meantime I was now able to build a debian-installer-cd for hppa based on the 3.12.9 debian kernel. It's available here: http://debian-ports.org/~deller/NETINST_CD_TRY4/ It works nicely on all machines, but as assumed, it's not useable on the C8000 workstation since the ATI drivers above aren't active and as such the user don't see anything on the screen. (I wanted to get everything worked out with the generation of a boot-cd before going back to this kernel questions/suggestions above). So, my question now is: Do you still suggest I should go the way as suggested in comment #55: I think you'll need to create a new udeb for DRM drivers... ? Is it then really ensured, that the drivers will then be loaded before the very first installer screen? The backside with it from my point of view is then, that people will not see any boot messages before modules gets loaded and they might think the machine crashed. And if it crashed you will get no output either. Please suggest. (PS: If I should provide a udeb-patch, which existing udeb-modules would you suggest me to look at which would be similiar? - I'm still learning here :-)). Thanks, Helge -- 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/52f7fdfd.1030...@gmx.de
Bug#733895: kernel 3.12 FTBFS and parisc patches
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 package the parisc64 variant for the debian-installer, while only the parisc64-smp variant is available. The attached patch fixes this. Furthermore the attached patch changes the kernel to build-in the AGP modules, else we get an AGP-error at boot (Ben Hutchings suggested in bug 721191 this: You might yet need to make them built-in, as nothing else ensures that AGP devices are initialised before DRM devices.). And the attached patch enables the CONFIG_DEBUG_STACKOVERFLOW=y option. With that one, we get enhanced information about stack usage in the /proc/interrupts file and stack overflows was one of the main problems regarding stability of the parisc-kernel in the past. Performance-penalty of this option is minimal. Thanks, Helge Index: linux/debian/config/hppa/config === --- linux/debian/config/hppa/config (revision 20943) +++ linux/debian/config/hppa/config (working copy) @@ -21,6 +21,7 @@ ## file: arch/parisc/Kconfig.debug ## # CONFIG_DEBUG_RODATA is not set +CONFIG_DEBUG_STACKOVERFLOW=y ## ## file: block/partitions/Kconfig Index: linux/debian/config/hppa/config.parisc64-smp === --- linux/debian/config/hppa/config.parisc64-smp (revision 20943) +++ linux/debian/config/hppa/config.parisc64-smp (working copy) @@ -19,8 +19,8 @@ ## file: drivers/char/agp/Kconfig ## #. for ATI FireGL DRM in C8000 workstation -CONFIG_AGP=m -CONFIG_AGP_PARISC=m +CONFIG_AGP=y +CONFIG_AGP_PARISC=y ## ## file: drivers/gpu/drm/Kconfig Index: linux/debian/installer/hppa/kernel-versions === --- linux/debian/installer/hppa/kernel-versions (revision 20943) +++ linux/debian/installer/hppa/kernel-versions (working copy) @@ -1,3 +1,3 @@ -# arch version flavour installedname suffix build-depends -hppa - parisc - y - -hppa - parisc64 - y - +# arch version flavour installedname suffix build-depends +hppa - parisc - y - +hppa - parisc64-smp - y -
Bug#733897: parisc patch for kernel 3.13
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/debian/config/hppa/config.parisc64-smp === --- linux/debian/config/hppa/config.parisc64-smp(revision 20943) +++ linux/debian/config/hppa/config.parisc64-smp(working copy) @@ -8,7 +8,6 @@ CONFIG_64BIT=y CONFIG_SMP=y CONFIG_NR_CPUS=8 -CONFIG_MLONGCALLS=y ## ## file: drivers/ata/Kconfig
Bug#721191: linux: patch for parisc/hppa architecture
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 mailing list. The whole thread can be read here: http://comments.gmane.org/gmane.linux.ports.parisc/5283 Summary: - yes, there exists quite some 32bit-only parisc SMP machines. - the J5600 is SMP capable in both 32bit and 64bit mode, but currently it only boots Linux with a 32bit SMP kernel and crashes with a 64bit SMP kernel. We are working on resolving this... [...] Looks like you fixed this one: commit 54e181e073fc1415e41917d725ebdbd7de956455 Author: Helge Deller del...@gmx.de Date: Sat Oct 26 23:19:25 2013 +0200 parisc: Do not crash 64bit SMP kernels on machines with = 4GB RAM Can you send a new config patch? actually I worked on a few more issues which were mentioned here in this bugreport... :-) Attached is a new patch - I hope I could address most questions. Some notes: - CONFIG_DEVTMPFS wasn't set before - needed to be able to boot - CONFIG_HP_SDC_RTC - RTC driver is buggy and not needed - we use BIOS/PDC - CONFIG_MEGARAID_NEWGEN=y - use new megaraid instead of old. Old one crashed one of my machines. - CONFIG_MLONGCALLS=y - needed for 64bit kernel. This is fixed upstream with kernel 3.13 and can be removed as soon as the debian kernel uses 3.13. Upstream commits (which I don't plan to backport): b8d8fccd68c36a19fef9768d06aa150bbc8cdd74 161bd3bf60ee2c5765455ad3e3da967d03449f4a 5ecbe3c3c690b5ab493c730c317475287a9e8b45 - CONFIG_PATA_SIL680=m, you suggested to use this one instead of SIIMAGE. Worked. SIL680-patch upstream for 3.13: a16ab68ee96005382738c706fd06bdd874d9185b - CONFIG_E1000=m, needed, existing configs only included e100. - AGP/DRM are now modules. Otherwise we don't have any output on the C8000 machines. As suggested I dropped parisc-smp and parisc64, still keeping parisc and parisc64-smp. We now can switch to use gcc-4.8 like the other arches. The control-file needs update to reflect this (not included here). Can you modify it by hand, if not, I can send a patch for that. Helge diff -up ./config/hppa/config.org ./config/hppa/config --- ./config/hppa/config.org 2013-10-17 02:11:54.0 +0200 +++ ./config/hppa/config 2013-11-25 11:06:59.0 +0100 @@ -27,6 +27,11 @@ CONFIG_PARISC_PAGE_SIZE_4KB=y ## # CONFIG_PARTITION_ADVANCED is not set +# +# Generic Driver Options +# +CONFIG_DEVTMPFS=y + ## ## file: drivers/ata/Kconfig ## @@ -128,7 +133,7 @@ CONFIG_KEYBOARD_HIL=m ## CONFIG_INPUT_MISC=y # CONFIG_INPUT_UINPUT is not set -CONFIG_HP_SDC_RTC=m +# CONFIG_HP_SDC_RTC=m ## ## file: drivers/input/mouse/Kconfig @@ -472,7 +477,7 @@ CONFIG_SCSI_NCR53C8XX_SYNC=20 ## ## file: drivers/scsi/megaraid/Kconfig.megaraid ## -# CONFIG_MEGARAID_NEWGEN is not set +CONFIG_MEGARAID_NEWGEN=y CONFIG_MEGARAID_MM=m CONFIG_MEGARAID_MAILBOX=m CONFIG_MEGARAID_LEGACY=m diff -up ./config/hppa/config.parisc64-smp.org ./config/hppa/config.parisc64-smp --- ./config/hppa/config.parisc64-smp.org 2013-10-17 02:11:54.0 +0200 +++ ./config/hppa/config.parisc64-smp 2013-12-07 20:01:27.0 +0100 @@ -8,11 +8,34 @@ CONFIG_PA8X00=y CONFIG_64BIT=y CONFIG_SMP=y CONFIG_NR_CPUS=8 +CONFIG_MLONGCALLS=y ## ## file: mm/Kconfig ## ## choice: Memory model -# CONFIG_FLATMEM_MANUAL is not set -## end choice +CONFIG_DISCONTIGMEM_MANUAL=y +CONFIG_DISCONTIGMEM=y +## +## file: drivers/ata/Kconfig +## +CONFIG_PATA_SIL680=m + +# +# Generic fallback / legacy drivers +# +CONFIG_FUSION=y +CONFIG_FUSION_SPI=m + +# +# Distributed Switch Architecture drivers +# +CONFIG_E1000=m + +# and for ATI FireGL DRM in C8000 workstation +CONFIG_DRM_RADEON=m +CONFIG_AGP=m +CONFIG_AGP_PARISC=m +CONFIG_VGA_ARB=y +CONFIG_DRM=m diff -up ./config/hppa/config.parisc-smp.org ./config/hppa/config.parisc-smp diff -up ./config/hppa/defines.org ./config/hppa/defines --- ./config/hppa/defines.org 2013-10-17 02:11:54.0 +0200 +++ ./config/hppa/defines 2013-12-08 22:47:15.0 +0100 @@ -1,35 +1,22 @@ [base] -flavours: - parisc - parisc-smp - parisc64 - parisc64-smp +flavours: parisc parisc64-smp kernel-arch: parisc -compiler: gcc-4.4 [image] suggests: palo [parisc_description] hardware: 32-bit PA-RISC +hardware-long: HP PA-RISC 32-bit systems with max. 4 GB RAM -[parisc-smp_description] -hardware: multiprocessor 32-bit PA-RISC - -[parisc64_base] -cflags: -fno-cse-follow-jumps -override-host-type: hppa64-linux-gnu - -[parisc64_description] -hardware: 64-bit PA-RISC +[parisc64-smp_description] +hardware: multiprocessor 64-bit PA-RISC +hardware-long: HP PA-RISC 64-bit SMP systems with support for more than 4 GB RAM [parisc64-smp_base] cflags: -fno-cse-follow-jumps override-host-type: hppa64-linux-gnu -[parisc64-smp_description] -hardware: multiprocessor 64-bit PA
Bug#721191: linux: patch for parisc/hppa architecture
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 that. Do you have some background on this request for me? Is it policy that you only want to gave SMP-kernels? We like to lower the image count. As long as there are no pressing needs, we like to only have one kernel variant. Ok. Are there any UP machines since PA-8800? 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 mailing list. The whole thread can be read here: http://comments.gmane.org/gmane.linux.ports.parisc/5283 Summary: - yes, there exists quite some 32bit-only parisc SMP machines. - the J5600 is SMP capable in both 32bit and 64bit mode, but currently it only boots Linux with a 32bit SMP kernel and crashes with a 64bit SMP kernel. We are working on resolving this... - 64bit SMP kernel boots fine on a 64bit UP machine. So, theretically we can drop the 64bit UP kernel. Only problem: performance loss due to unnecessary spinlock cost. So, right now, the best option would be to only drop the 64bit UP kernel. PPPS: CONFIG_MLONGCALLS=y is necessary since the built kernel otherwise gets too big so that jumps can't be reached. Are there drawbacks? Yes, it might be a little bit slower since the jumps now have one CPU instruction more. But there is no other way to solve it unless we drop some unneccessary kernel options for parisc. How much space would be needed? Some Arm configs disable SELinux for example to save space. Not much. I think it makes sense to look through the complete configs again. Maybe there are things which we can disable for parisc... Helge -- 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/522cdd93.7080...@gmx.de
Bug#721191: linux: patch for parisc/hppa architecture
-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_SIL680 instead? I will test if this works too. +# For the built-in SCSI controller in C8000 workstation +CONFIG_FUSION=y Why should this be built-in? it just enables that you can select FUSION_SPI +CONFIG_FUSION_SPI=m + +# Built-in NIC in C8000 workstation +CONFIG_E1000=m This is redundant with the top-level config. It hasn't been built before, so maybe the dependeny to top-level config didn't worked? Will check. +CONFIG_DRM=y Why should this be built-in? On the C8000 an ATI FireGL is the only built-in GFX card and it's only supported by the radeon DRM driver. So, if the driver isn't built-in, you won't be able to see the debian installer... +CONFIG_DRM_KMS_HELPER=y +CONFIG_DRM_TTM=y These are automatic configuration symbols; you can't set them. Ok, might be a mistake. +CONFIG_BACKLIGHT_LCD_SUPPORT=y [...] This is redundant with the top-level config. Again, the top-level config didn't seemed to have been pulled. Will check too. Helge -BEGIN PGP SIGNATURE- Version: GnuPG v2.0.19 (GNU/Linux) Comment: Using GnuPG with Thunderbird - http://www.enigmail.net/ iQEcBAEBAgAGBQJSLOFwAAoJEIfJwVG1Hjhk8pUH/2ubsd35e2HSAEMY9NvO+8Zm X5EtbbNavUECOidbTKb4y/NuApqfi2ggg1lEWE8wdD+RVkwMdHU47shBcKU29Rws /jki5FxLdHfqhr63ZDtwB/6NAF8ntwtt9+jsMY+DCn/i1nAZddmqnwDOzbF4x1fS T89POQaBOzJGcGk4Azyep75VaFqljxaudAPS15Aha8poZ17fbDZYJOsIWR2j+f+P 1ttybdKByVKGQXfbWvkAtgP7+nj94XXIuCh3TY6WEjzx5WyFwhfh1hOFwUEB2pLQ JLiqQC0tGkfVwdkaRZpxSylBnCh9J1SqSHCr//ywnaP4OBlCRWRm+xie4norhqk= =Gc0w -END PGP SIGNATURE- -- 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/522ce170.3090...@gmx.de
Bug#721191: linux: patch for parisc/hppa architecture
Package: linux Version: 3.10 Severity: wishlist Tags: patch Dear Debian kernel maintainers, could you please apply the attached trivial patch, which enables support for C8000 PARISC workstation with your latest 3.10 (and higher) unstable kernel. Basically this patch just adds some more Linux kernel config options for the built-in SCSI- (FUSION_SPI), IDE- (SIIMAGE), NIC- (Intel E1000) and graphics card (ATI Radeon FireGL x1/x3). Without those options, the built kernel will not boot on this workstation, since the necessary drivers are not included in the debian kernel package. The C8000 workstation only supports 64bit Linux kernels, which is why I only modified the config-parisc64 and config-parisc64-smp files. In addition, I've switched the defines file so that on parisc now the gcc-4.7 compiler will be used. All your other arches already use the gcc-4.7 compiler (with exception of m68k?), so this should be fine for you as well (I hope). I've successfully built and bootstrapped all kernels myself on various machines (including C8000, C3000 and 715/64[32bit]). It would be nice, if you could apply this patch to your linux source code tree. 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... Thanks a lot in advance, Helge Deller (PARISC (upstream) Linux kernel maintainer). PS: PARISC debian unstable packages are *NOT* available on http://www.debian-ports.org/, instead we are currently maintaining our packages at http://ftp.parisc-linux.org/debian-ports/ where we currently host more than 8600 up-to-date debian unstable packages. PPS: A switch to gcc-4.8 should be possible soon as well for the parisc kernel we are working on that at this moment PPPS: CONFIG_MLONGCALLS=y is necessary since the built kernel otherwise gets too big so that jumps can't be reached. diff -up ./debian/config/hppa/config.parisc64-smp.org ./debian/config/hppa/config.parisc64-smp --- ./debian/config/hppa/config.parisc64-smp.org 2013-05-04 04:44:45.0 +0200 +++ ./debian/config/hppa/config.parisc64-smp 2013-08-26 22:50:12.0 +0200 @@ -8,6 +8,7 @@ CONFIG_PA8X00=y CONFIG_64BIT=y CONFIG_SMP=y CONFIG_NR_CPUS=8 +CONFIG_MLONGCALLS=y ## ## file: mm/Kconfig @@ -16,3 +17,24 @@ CONFIG_NR_CPUS=8 # CONFIG_FLATMEM_MANUAL is not set ## end choice +# For the IDE CDROM in C8000 workstation +CONFIG_IDE=m +CONFIG_BLK_DEV_SIIMAGE=m + +# For the built-in SCSI controller in C8000 workstation +CONFIG_FUSION=y +CONFIG_FUSION_SPI=m + +# Built-in NIC in C8000 workstation +CONFIG_E1000=m + +# and for ATI FireGL DRM in C8000 workstation +CONFIG_DRM_RADEON=m +CONFIG_AGP=y +CONFIG_AGP_PARISC=y +CONFIG_VGA_ARB=y +CONFIG_VGA_ARB_MAX_GPUS=16 +CONFIG_DRM=y +CONFIG_DRM_KMS_HELPER=y +CONFIG_DRM_TTM=y +CONFIG_BACKLIGHT_LCD_SUPPORT=y diff -up ./debian/config/hppa/config.parisc64.org ./debian/config/hppa/config.parisc64 --- ./debian/config/hppa/config.parisc64.org 2013-05-30 04:45:35.0 +0200 +++ ./debian/config/hppa/config.parisc64 2013-08-26 22:50:09.0 +0200 @@ -19,3 +19,24 @@ CONFIG_64BIT=y # CONFIG_FLATMEM_MANUAL is not set ## end choice +# For the IDE CDROM in C8000 workstation +CONFIG_IDE=m +CONFIG_BLK_DEV_SIIMAGE=m + +# For the built-in SCSI controller in C8000 workstation +CONFIG_FUSION=y +CONFIG_FUSION_SPI=m + +# Built-in NIC in C8000 workstation +CONFIG_E1000=m + +# and for ATI FireGL DRM in C8000 workstation +CONFIG_DRM_RADEON=m +CONFIG_AGP=y +CONFIG_AGP_PARISC=y +CONFIG_VGA_ARB=y +CONFIG_VGA_ARB_MAX_GPUS=16 +CONFIG_DRM=y +CONFIG_DRM_KMS_HELPER=y +CONFIG_DRM_TTM=y +CONFIG_BACKLIGHT_LCD_SUPPORT=y diff -up ./debian/config/hppa/defines.org ./debian/config/hppa/defines --- ./debian/config/hppa/defines.org 2013-07-30 00:25:26.0 +0200 +++ ./debian/config/hppa/defines 2013-08-27 16:57:01.0 +0200 @@ -5,7 +5,7 @@ flavours: parisc64 parisc64-smp kernel-arch: parisc -compiler: gcc-4.4 +compiler: gcc-4.7 [image] suggests: palo @@ -31,5 +31,5 @@ override-host-type: hppa64-linux-gnu hardware: multiprocessor 64-bit PA-RISC [relations] -gcc-4.4: gcc-4.4, binutils-hppa64, gcc-4.4-hppa64 +gcc-4.7: gcc-4.7, binutils-hppa64, gcc-4.7-hppa64 diff -up ./debian/installer/hppa/modules/hppa/pata-modules.org ./debian/installer/hppa/modules/hppa/pata-modules --- ./debian/installer/hppa/modules/hppa/pata-modules.org 2013-05-19 01:36:34.0 +0200 +++ ./debian/installer/hppa/modules/hppa/pata-modules 2013-08-26 22:13:33.0 +0200 @@ -1,2 +1,3 @@ +siimage ? #include pata-modules diff -up ./debian/installer/hppa/modules/hppa/scsi-modules.org ./debian/installer/hppa/modules/hppa/scsi-modules --- ./debian/installer/hppa/modules/hppa/scsi-modules.org 2013-05-19 01:36:34.0 +0200 +++ ./debian/installer/hppa/modules/hppa/scsi-modules 2013-08-27 21:51:42.0 +0200
Bug#721191: linux: patch for parisc/hppa architecture
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 kernels. I can do that. Do you have some background on this request for me? Is it policy that you only want to gave SMP-kernels? (Actually I had a similiar idea to use kernel alternatives on parisc too to avoid different UP/SMP kernels). PPPS: CONFIG_MLONGCALLS=y is necessary since the built kernel otherwise gets too big so that jumps can't be reached. Are there drawbacks? Yes, it might be a little bit slower since the jumps now have one CPU instruction more. But there is no other way to solve it unless we drop some unneccessary kernel options for parisc. Helge -- 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/521e7176.4060...@gmx.de
Bug#561203: threads and fork on machine with VIPT-WB cache
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. Yes, it will be huge performance
impact for fork. But I don't find any good solution other than this
yet.
I think we could do something like (only for VIPT-WB cache machine):
-static inline void ptep_set_wrprotect(struct mm_struct *mm, unsigned
long
address, pte_t *ptep)
+static inline void ptep_set_wrprotect(struct vm_area_struct *vma,
struct
mm_struct *mm, unsigned long addr, pte_t *ptep)
{
pte_t old_pte = *ptep;
+if (atomic_read(mm-mm_users) 1)
+flush_cache_page(vma, addr, pte_pfn(old_pte));
set_pte_at(mm, addr, ptep, pte_wrprotect(old_pte));
}
I tested the hack below on two machines currently running 2.6.33.2
UP kernels. The change seems to fix Debian #561203 (minifail bug)!
Thus, I definitely think you are on the right track. I'll continue
to test.
I suspect the same issue is present for SMP kernels.
Hi Dave,
I tested your patch today on one of my machines with plain kernel 2.6.33
(32bit, SMP, B2000 I think).
Sadly I still did see the minifail bug.
Are you sure, that the patch fixed this bug for you?
Helge
do_page_fault() pid=21470 command='minifail3' type=6 address=0x0003
do_page_fault() pid=7986 command='minifail3' type=6 address=0x0003
do_page_fault() pid=19952 command='minifail3' type=6 address=0x0003
do_page_fault() pid=13549 command='minifail3' type=6 address=0x0003
do_page_fault() pid=21862 command='minifail3' type=6 address=0x0003
do_page_fault() pid=4615 command='minifail3' type=6 address=0x0003
do_page_fault() pid=17336 command='minifail3' type=6 address=0x0003
do_page_fault() pid=21986 command='minifail3' type=6 address=0x0003
do_page_fault() pid=2157 command='minifail3' type=15 address=0x00dc
do_page_fault() pid=23886 command='minifail3' type=6 address=0x0003
do_page_fault() pid=2681 command='minifail3' type=6 address=0x0003
do_page_fault() pid=3229 command='minifail3' type=15 address=0x00ec
do_page_fault() pid=26095 command='minifail3' type=6 address=0x0003
do_page_fault() pid=20722 command='minifail3' type=6 address=0x0003
do_page_fault() pid=19912 command='minifail3' type=15 address=0x00ec
...
pagealloc: memory corruption
7db0c780: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
7db0c790: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
7db0c7a0: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
7db0c7b0: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
Backtrace:
[1011ec14] show_stack+0x18/0x28
[10117ba0] dump_stack+0x1c/0x2c
[101c6594] kernel_map_pages+0x2a0/0x2b8
[1019e6c8] get_page_from_freelist+0x3d4/0x614
[1019ea3c] __alloc_pages_nodemask+0x134/0x610
[101b1d20] do_wp_page+0x268/0xac0
[101b3b34] handle_mm_fault+0x4d4/0x7c4
[1011d854] do_page_fault+0x1f8/0x2fc
[1011f450] handle_interruption+0xec/0x730
[10103078] intr_check_sig+0x0/0x34
...
do_page_fault() pid=13414 command='minifail3' type=15 address=0x00dc
do_page_fault() pid=22776 command='minifail3' type=15 address=0x
do_page_fault() pid=26290 command='minifail3' type=15 address=0x00ec
do_page_fault() pid=1399 command='minifail3' type=6 address=0x0003
do_page_fault() pid=16130 command='minifail3' type=6 address=0x0003
do_page_fault() pid=26401 command='minifail3' type=6 address=0x0003
do_page_fault() pid=3383 command='minifail3' type=6 address=0x0003
do_page_fault() pid=3400 command='minifail3' type=15 address=0x0004
do_page_fault() pid=18659 command='minifail3' type=6 address=0x0003
do_page_fault() pid=3730 command='minifail3' type=6 address=0x0003
do_page_fault() pid=28828 command='minifail3' type=6 address=0x0003
--
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/4bbe468d.5060...@gmx.de
Bug#539215: grave or important ?
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 my testcases. Given the fact that some people consider the hppa port (and the debian build servers) not very stable, I think it's important to fix this issue as soon as possible. Helge -- Jetzt kostenlos herunterladen: Internet Explorer 8 und Mozilla Firefox 3 - sicherer, schneller und einfacher! http://portal.gmx.net/de/go/atbrowser -- To UNSUBSCRIBE, email to debian-kernel-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#539378: [hppa]: fails to load nfs module: Global Offset Table
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 this idea a little more? Helge -- To UNSUBSCRIBE, email to debian-kernel-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#539378: [hppa]: fails to load nfs module: Global Offset Table overflow
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 4095 GOT entries on 64-bit. * Fix ELF_GOT_STUB for the 64-bit case. It needs to reassemble a 16-bit offset, the current code is IMO incorrect. i.e. it should be 0x7fff, and use a new reassemble_16 see the PA 2.0 book definition of ldd. * Build kernel. * Test loading NFS moudle. Carlos, thanks a lot for those explanations (and keep up your work with NPTL :-)). I'll know what you mean, and if it works it's a good idea. I'll try to come up with a patch. A few notes: - the GOT table is only used for 64bit anyway, so no need to differentiate for 32/64bits - Another possibility could be to sort the tables, so to reduce the number of needed entries. Helge -- To UNSUBSCRIBE, email to debian-kernel-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#539378: [hppa]: fails to load nfs module: Global Offset Table
On 08/01/2009 01:38 AM, Kyle McMartin wrote:
On Fri, Jul 31, 2009 at 06:00:48PM -0400, Carlos O'Donell wrote:
On Fri, Jul 31, 2009 at 5:26 PM, John David
Anglind...@hiauly1.hia.nrc.ca wrote:
I don't have more details... The idea is as Carlos outlined. There's
code in the binutils elf32-hppa.c and elf64-hppa.c files to implement
the above for dynamic libraries. That's what made me think of it.
Binutils is not involved in the kernel module loader, instead
arch/parisc/kernel/module.c (get_fdesc) chooses where the gp will
point to.
If you set gp to the middle of the GOT table, *and* implement
long/short ldd access on 64-bit, then you would get a total of 8191
possible slots per module.
Personally I think the lower risk, quicker fix, is to implement a fix
for 64-bit kernels that uses ldd in format 3 for all offsets 15
bytes, and thus allow you to set MAX_GOTS to 4095.
Note: ldd format 3 can't be used to load immediate values between 15
and -16 bytes.
Is it as simple as:
diff --git a/arch/parisc/kernel/module.c b/arch/parisc/kernel/module.c
index ef5caf2..0502fab 100644
--- a/arch/parisc/kernel/module.c
+++ b/arch/parisc/kernel/module.c
@@ -82,13 +82,6 @@
return -ENOEXEC;\
}
-/* Maximum number of GOT entries. We use a long displacement ldd from
- * the bottom of the table, which has a maximum signed displacement of
- * 0x3fff; however, since we're only going forward, this becomes
- * 0x1fff, and thus, since each GOT entry is 8 bytes long we can have
- * at most 1023 entries */
-#define MAX_GOTS 1023
-
/* three functions to determine where in the module core
* or init pieces the location is */
static inline int in_init(struct module *me, void *loc)
@@ -126,6 +119,14 @@ struct stub_entry {
};
#endif
+/* Maximum number of GOT entries. We use a long displacement ldd from
+ * the bottom of the table, which has 16-bit signed displacement from
+ * %dp. Because we only use the forward direction, we're limited to
+ * 15-bits - 1, and because each GOT entry is 8-bytes wide, we're limited
+ * to 4095 entries.
+ */
+#define MAX_GOTS (((1 15) - 1) / sizeof(struct got_entry))
+
/* Field selection types defined by hppa */
#define rnd(x)(((x)+0x1000)~0x1fff)
/* fsel: full 32 bits */
@@ -151,6 +152,15 @@ static inline int reassemble_14(int as14)
((as14 0x2000) 13));
}
+/* Unusual 16-bit encoding, for wide mode only. */
+static inline int reassemble_16a(int as16)
+{
+ int s, t;
+ t = (as16 1) 0x;
+ s = (as16 0x8000);
+ return (t ^ s ^ (s 1)) | (s 15);
+}
+
static inline int reassemble_17(int as17)
{
return (((as17 0x1) 16) |
@@ -460,12 +470,16 @@ static Elf_Addr get_stub(struct module *me, unsigned long
value, long addend,
*/
switch (stub_type) {
case ELF_STUB_GOT:
+ unsigned int d = get_got(me, value, addend) 0x7fff;
+
stub-insns[0] = 0x537b; /* ldd 0(%dp),%dp */
stub-insns[1] = 0x53610020; /* ldd 10(%dp),%r1 */
stub-insns[2] = 0xe820d000; /* bve (%r1)*/
stub-insns[3] = 0x537b0030; /* ldd 18(%dp),%dp */
- stub-insns[0] |= reassemble_14(get_got(me, value, addend)
0x3fff);
+ if (d 15)
+ stub-insns[0] |= reassemble_16a(d);
+
break;
case ELF_STUB_MILLI:
stub-insns[0] = 0x2020; /* ldil 0,%r1 */
I don't think we need to worry about the initial 15-bytes displacement,
since they're all within the first got_entry? (The resulting assembly
looks alright from a 64-bit toolchain:
k...@shortfin ~ $ cat foo.S
.text
a:
ldd 32760(%r27),%r27
break 0,0
a:
0: 53 7b ff f0 ldd 7ff8(dp),dp
int main(void) {
unsigned int opcode = 0x537b;
opcode |= re_assemble_16(32760);
printf(0x%x\n, opcode);
return 0;
}
k...@shortfin ~ $ ./foo
0x537bfff0
Looks pretty happy?
Kyle, you beat me.
Attached is my patch
Tested and works.
r...@c3000:~# uname -a
Linux c3000 2.6.31-rc4-64bit #42 SMP Sat Aug 1 01:37:29 CEST 2009 parisc64
GNU/Linux
r...@c3000:~# lsmod
Module Size 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
fat91248 1 msdos
Helge
parisc: module.c - fix GOT table overflow with large kernel modules on 64 bit kernels
Signed-off-by: Helge Deller del...@gmx.de
diff --git a/arch/parisc/kernel/module.c b/arch/parisc/kernel/module.c
index ef5caf2..d280219 100644
--- a/arch/parisc/kernel/module.c
+++ b/arch/parisc/kernel/module.c
@@ -86,8 +86,12 @@
* the bottom of the table, which has
Bug#401439: parisc: xfs module loading bug
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-kernelm=123055968113465w=2 Needed patches which were accepted upstream: a) module: fix module loading failure of large kernel modules for parisc http://git.kernel.org/?p=linux/kernel/git/torvalds/linux-2.6.git;a=commitdiff;h=088af9a6e05d51e7c3dc85d45d8b7a52c3ee08d7;hp=d1e99d7ae4e6bbd1ebb5e81ecd3af2b8793efee0 b) parisc: fix module loading failure of large kernel modules http://git.kernel.org/?p=linux/kernel/git/torvalds/linux-2.6.git;a=commitdiff;h=c298be74492bece102f3379d14015638f1fd1fac;hp=088af9a6e05d51e7c3dc85d45d8b7a52c3ee08d7 Maybe it would make sense to backport those fixes in the debian kernel for lenny. Debian bug reports which refer to this issue: http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=401439 http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=350482 http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=401439 http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=508489 -- To UNSUBSCRIBE, email to debian-kernel-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#401439: parisc: xfs module loading bug
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. Mainstream Kernel 2.6.29 will contain the fix. Description of the problem: http://marc.info/?l=linux-kernelm=123055968113465w=2 Needed patches which were accepted upstream: a) module: fix module loading failure of large kernel modules for parisc http://git.kernel.org/?p=linux/kernel/git/torvalds/linux-2.6.git;a=commitdiff;h=088af9a6e05d51e7c3dc85d45d8b7a52c3ee08d7;hp=d1e99d7ae4e6bbd1ebb5e81ecd3af2b8793efee0 b) parisc: fix module loading failure of large kernel modules http://git.kernel.org/?p=linux/kernel/git/torvalds/linux-2.6.git;a=commitdiff;h=c298be74492bece102f3379d14015638f1fd1fac;hp=088af9a6e05d51e7c3dc85d45d8b7a52c3ee08d7 Unfortunately, b) is an (hppa-specific) ABI breaker. I'm guessing its the changes to struct mod_arch_specific, but I haven't proven that yet. You are right. We could try ignoring the change - but I'm not sure how dangerous that would be. Is this structure known to modules, or is it just used in the core? That is, if you tried to load modules built w/ this patch into a kernel that didn't have this patch, would that be safe? Modules and kernel must fit. This means, if you apply this patch you will have to rebuild all modules as well. Mixing new kernel and old modules (or the other way round) will not work. Helge -- To UNSUBSCRIBE, email to debian-kernel-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#401439: hppa/xfs
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-kernelm=123055968113465w=2 Two patches: http://marc.info/?l=linux-kernelm=123055978413612w=2 http://marc.info/?l=linux-kernelm=123055986413742w=2 -- To UNSUBSCRIBE, email to debian-kernel-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#416208: Installation report HP-715/64 (HIL)
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. To solve this problem, the boot kernel needs the CONFIG_KEYBOARD_HIL_OLD=y option set. Additionally, all other HIL options should be disabled (see below). With those options, the HIL keyboard should work. HIL-Mouse will not be available, but it's not needed either for the installation process. In general, all newer HIL drivers do not work at all, so defaulting back to the old driver should be ok. The Lenny kernel sets CONFIG_KEYBOARD_HIL_OLD=m, does this still apply? Moritz, thanks for bringing this up again. I nearly forgot it! I just tried the netboot image dated 30-10-08 from http://ftp.nl.debian.org/debian/dists/testing/main/installer-hppa/current/images/netboot/2.6/. Currently the debian installer boots up nicely, but the keyboard is not functional at all (on machines with HIL keyboard). My tests with booting via serial console shows, that all what needs to be done to get those keyboards working now is, to run a modprobe hilkbd at startup. Is it possible that someone from the debian-installer teams add this modprobe hilkbd somewhere to the bootup process? This modprobe should also be carried over to the installed system afterwards. I'm willing to test any temporary images (preferably netboot images) as soon as possible. [Forwarding to debian-b...@lists.debian.org] Can that be considered for rc2? Yes, please. I should have mentioned, that adding modprobe hilkbd will not break any parisc machine which does not have HIL. So it's pretty safe to probe for this module. Helge -- To UNSUBSCRIBE, email to debian-kernel-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#416208: Installation report HP-715/64 (HIL)
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 options should be disabled (see below). With those options, the HIL keyboard should work. HIL-Mouse will not be available, but it's not needed either for the installation process. In general, all newer HIL drivers do not work at all, so defaulting back to the old driver should be ok. The Lenny kernel sets CONFIG_KEYBOARD_HIL_OLD=m, does this still apply? Moritz, thanks for bringing this up again. I nearly forgot it! I just tried the netboot image dated 30-10-08 from http://ftp.nl.debian.org/debian/dists/testing/main/installer-hppa/current/images/netboot/2.6/. Currently the debian installer boots up nicely, but the keyboard is not functional at all (on machines with HIL keyboard). My tests with booting via serial console shows, that all what needs to be done to get those keyboards working now is, to run a modprobe hilkbd at startup. Is it possible that someone from the debian-installer teams add this modprobe hilkbd somewhere to the bootup process? This modprobe should also be carried over to the installed system afterwards. I'm willing to test any temporary images (preferably netboot images) as soon as possible. Helge -- To UNSUBSCRIBE, email to debian-kernel-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
