Re: Is the sh7785lcr kernel still useful?
Hi Ben, On Sun, 2024-07-21 at 15:16 +0200, Ben Hutchings wrote: > On Sat, 2024-07-20 at 21:48 +0200, John Paul Adrian Glaubitz wrote: > [...] > > > - Does anyone have it working with a recent (6.3 or later) Debian > > > kernel package, and if so how? > > > > I am currently running a kernel built from git upstream, but I would love > > to be able to boot a Debian kernel again. I have no clue how to reduce > > the kernel image size at this point though. > > > > I am currently not using an initrd with my custom kernel. > > I made some config changes that bring the size back under the limit: > <https://salsa.debian.org/kernel-team/linux/-/merge_requests/1133>. > > Can you test that this produces a working kernel? I'll give it a try next week as I'm currently not at home and unable to access the board for testing. While I can reach the board via SSH, I don't have any kind of remote management. Thanks, Adrian -- .''`. John Paul Adrian Glaubitz : :' : Debian Developer `. `' Physicist `-GPG: 62FF 8A75 84E0 2956 9546 0006 7426 3B37 F5B5 F913
Re: Bug#1076564: pahole BTF processing seems flaky on powerpc
Hi Ben, On Mon, 2024-07-22 at 00:07 +0200, Ben Hutchings wrote: > I don't know what differences there are between these builders that > might be relevant. For kapitsa, the installed host system is powerpc while all the others run the ppc64 port. As for the hardware: kapitsa runs bare-metal (inside an LPAR) on a POWER8 machine: root@kapitsa:~# grep model /proc/cpuinfo model : IBM,8284-22A root@kapitsa:~# Both blaauw and perotto are KVMs running on watson which runs Debian's ppc64el port (little-endian): root@watson:~# grep model /proc/cpuinfo model : 8247-42L root@watson:~# root@blaauw:~# grep model /proc/cpuinfo model : IBM pSeries (emulated by qemu) root@blaauw:~# root@perotto:~# grep model /proc/cpuinfo model : IBM pSeries (emulated by qemu) root@perotto:~# Both debian-project-be-01 and debian-project-be-02 are KVMs running on OpenStack at OSUOSL's OpenPOWER platform: root@debian-project-be-1:~# grep model /proc/cpuinfo model : IBM pSeries (emulated by qemu) root@debian-project-be-1:~# root@debian-project-be-2:~# grep model /proc/cpuinfo model : IBM pSeries (emulated by qemu) root@debian-project-be-2:~# Adrian -- .''`. John Paul Adrian Glaubitz : :' : Debian Developer `. `' Physicist `-GPG: 62FF 8A75 84E0 2956 9546 0006 7426 3B37 F5B5 F913
Re: Is the sh7785lcr kernel still useful?
Hi Ben, On Sat, 2024-07-20 at 00:11 +0200, Ben Hutchings wrote: > In revieweing Debian's kernel configuration for sh4, I realised that > the sh7785lcr board file not only has a small kernel partition but has > no initramfs partition. OK. > Some time ago the compressed kernel image for sh7785lcr became larger > than its kernel partition. This was caught by a build-time check. In > version 6.3.2-1~exp1 I attempted to fix this by modularising some > drivers, on the assumption that an initramfs would be used (as is > normal for Debian packaged kernels). But it seems like this won't work > - any initramfs would have to be appended to the kernel image, so it > would still be too large for the kernel partition. > > **If this kernel flavour is no longer usable and no fix is proposed, I > intend to remove it.** > > Before I do that: > > - Does anyone still care about this board? Yes, it's my primary development board, I have multiple of these boards. > - Does anyone have it working with a recent (6.3 or later) Debian > kernel package, and if so how? I am currently running a kernel built from git upstream, but I would love to be able to boot a Debian kernel again. I have no clue how to reduce the kernel image size at this point though. I am currently not using an initrd with my custom kernel. Adrian -- .''`. John Paul Adrian Glaubitz : :' : Debian Developer `. `' Physicist `-GPG: 62FF 8A75 84E0 2956 9546 0006 7426 3B37 F5B5 F913
Re: Bug#1076564: pahole BTF processing seems flaky on powerpc
On Sat, 2024-07-20 at 21:17 +0200, Ben Hutchings wrote: > I had a go yesterday and ran into the same problem. I couldn't > reproduce with a small kernel config (allnoconfig + BPF + DEBUG_INFO + > DEBUG_INFO_BTF) and there wasn't enough disk space to build even one of > the Debian kernel flavours. > > > Will take care of it and let you know when it's (some hours). > > Thank you! There are now 120 GB of free disk space. Let me know if that's sufficient or whether I need to clean up more, probably asking others to clean up their home directories. Adrian -- .''`. John Paul Adrian Glaubitz : :' : Debian Developer `. `' Physicist `-GPG: 62FF 8A75 84E0 2956 9546 0006 7426 3B37 F5B5 F913
Re: Bug#1076564: pahole BTF processing seems flaky on powerpc
Hi Domenico, On Fri, 2024-07-19 at 23:20 +0200, Domenico Andreoli wrote: > > > Is there anything I can do to help? > > > > From the 6.10-1~exp1: > > https://buildd.debian.org/status/fetch.php?pkg=linux=powerpc=6.10-1%7Eexp1=1721287862=1 > > file: > > > > + LLVM_OBJCOPY=powerpc-linux-gnu-objcopy pahole -J -j > > --btf_features=encode_force,var,float,enum64,decl_tag,type_tag,optimized_func,consistent_func > > --lang_exclude=rust .tmp_vmlinux.btf > > > > Can I have access to that .tmp_vmlinux.btf file so that I can try to > > reproduce it here? > > I don't have access to the build host (blaauw2) and I've some doubts > it would still have that file. > > Maybe our kernel team and powerpc porters have suggestions? I have root access to all powerpc/ppc64 machines (buildds and porterbox). I'm cleaning up the porterbox now, disk is quite full, then you can try to build the kernel package on perotto.debian.net or I can try it myself. I have seen the bug myself and I wanted to debug it, but the attempt was foiled by the fact that the disk on perotto is full (again). Will take care of it and let you know when it's (some hours). Adrian -- .''`. John Paul Adrian Glaubitz : :' : Debian Developer `. `' Physicist `-GPG: 62FF 8A75 84E0 2956 9546 0006 7426 3B37 F5B5 F913
Bug#1056428: /usr/sbin/lparstat: Could not open /proc/ppc64/lparcfg when lauch lparstat
Hello Thomas, On Wed, 2024-04-03 at 12:22 +, PEPONAS Thomas wrote: > On IBM Power paltform , add cpu entitlement can not be done without > LPARCFG=Y , because /proc/ppc64/lparcfg could not open: > Logs from drmgr : > ## Apr 03 10:54:41 2024 ## > drmgr: -c cpu -r -q 10 -p ent_capacity -w 5 -d 1 > Validating CPU DLPAR capability...yes. > Could not open "/proc/ppc64/lparcfg" > No such file or directory > CPU entitlement capability is not enabled on this platform. > Could not update system parameter ent_capacity > ## Apr 03 10:54:41 2024 ## > > will the LPARCFG option be activated on future versions? The Debian kernel maintainers are informed since I have reassigned the bug to the kernel package. I assume this will be fixed in the near future. I might do it myself if I find the time during the next weeks. Adrian -- .''`. John Paul Adrian Glaubitz : :' : Debian Developer `. `' Physicist `-GPG: 62FF 8A75 84E0 2956 9546 0006 7426 3B37 F5B5 F913
Re: Ability to further support 32bit architectures
Hello Dimitri, On Thu, 2024-01-11 at 09:48 +, Dimitri John Ledkov wrote: > Separately, I wish we had cross-builders available, and cross-build > i386/armhf kernels from amd64/arm64 and thus having access to 64-bit > compiler. Helmut Grohne is actually working towards cross-builders and I think there is a chance we might see these in the foreseeable future. Adrian -- .''`. John Paul Adrian Glaubitz : :' : Debian Developer `. `' Physicist `-GPG: 62FF 8A75 84E0 2956 9546 0006 7426 3B37 F5B5 F913
Re: Ability to further support 32bit architectures
Hi! On Thu, 2024-01-11 at 10:25 +0100, Bastian Blank wrote: > Linux 6.7 fails to build on at least i386 and armhf. Even it now > manages to make the compiler fail to allocate memory: > > cc1: out of memory allocating 135266296 bytes after a total of 235675648 > > bytes > > Right now both fail on the same driver, so a short team workaround would > be to disable it. But we need a long term fix, and quickly. The long term fix would be fixing this driver so a single compilation unit doesn't take several gigabytes of RAM. > As it is now, we will not be able to provide a kernel for maybe all > 32bit architectures for Trixie. I don't think that this would be a reasonable decision. We're preparing to switch 32-bit architectures over to time64_t. Disabling 32-bit kernel builds would make this whole work moot. FWIW, both m68k and powerpc are not affected by this bug, the powerpc build fails because of a packaging problem. Adrian -- .''`. John Paul Adrian Glaubitz : :' : Debian Developer `. `' Physicist `-GPG: 62FF 8A75 84E0 2956 9546 0006 7426 3B37 F5B5 F913
Bug#1059676: kernel FTBFS on hppa
Hello! > 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 On powerpc for example, binutils is configured with: --enable-targets=powerpc64-linux-gnu Thus, we should just do this on hppa as well and close this bug report. Adrian -- .''`. John Paul Adrian Glaubitz : :' : Debian Developer `. `' Physicist `-GPG: 62FF 8A75 84E0 2956 9546 0006 7426 3B37 F5B5 F913
Bug#1040663: linux: Please build linux-libc-dev package for loong64
Hi Bastian! On Wed, 2023-07-12 at 11:07 +0200, Bastian Blank wrote: > On Sat, Jul 08, 2023 at 08:41:03PM +0200, John Paul Adrian Glaubitz wrote: > > Please enable building the linux-libc-dev package for the new Debian > > architecture loong64. > > The corresponding kernel architecture is called "loongarch". > > I can't find loong64 in the debian architecture table used on > ftp-master, so we can't add it yet. It's already part of the dpkg architecture table [1] and there is already a pool directory in Debian Ports [2]. I expect the architecture table to be updated in the near future. Adrian > [1] > https://git.dpkg.org/cgit/dpkg/dpkg.git/commit/?id=4c9e67b52672cb1cf19f7c3e86164bc70b749e77 > [2] http://ftp.ports.debian.org/debian-ports/pool-loong64/ -- .''`. John Paul Adrian Glaubitz : :' : Debian Developer `. `' Physicist `-GPG: 62FF 8A75 84E0 2956 9546 0006 7426 3B37 F5B5 F913
Bug#1040663: linux: Please build linux-libc-dev package for loong64
Source: linux Version: 6.3.11-1 Severity: normal User: debian-m...@lists.debian.org Usertags: loong64 X-Debbugs-Cc: debian-m...@lists.debian.org Hello! Please enable building the linux-libc-dev package for the new Debian architecture loong64. The corresponding kernel architecture is called "loongarch". Thanks, Adrian -- .''`. John Paul Adrian Glaubitz : :' : Debian Developer `. `' Physicist `-GPG: 62FF 8A75 84E0 2956 9546 0006 7426 3B37 F5B5 F913
Bug#1027974: linux: FTBFS on alpha due to unversioned symbols
Source: linux Version: 6.0.12-1 Severity: normal User: debian-al...@lists.debian.org Usertags: alpha X-Debbugs-Cc: debian-al...@lists.debian.org Hello! Since upstream version 5.19.x, src:linux FTBFS on alpha due to unversioned symbols [1]: > ABI is not completely versioned! Refusing to continue. > Unversioned symbols: > strcat module: vmlinux, version: > 0x, export: EXPORT_SYMBOL > strcpy module: vmlinux, version: > 0x, export: EXPORT_SYMBOL > strncat module: vmlinux, version: > 0x, export: EXPORT_SYMBOL > strncpy module: vmlinux, version: > 0x, export: EXPORT_SYMBOL > Can't read ABI reference. ABI not checked! A local build showed that this is still present in the latest package version 6.0.12-1. According to this comment [2], this issue can be fixed by adding the appropriate include to arch/$ARCH/include/asm/asm-prototypes.h but the include for is already present, so I'm not sure what the actual problem is. I'm reporting this issue to hopefully get some feedback on what else to try to fix this issue. I'm happy to provide any patches once I know what to fix. Thanks, Adrian > [1] > https://buildd.debian.org/status/fetch.php?pkg=linux=alpha=5.19.6-1=1663530012=0 > [2] https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=908161#10 -- .''`. John Paul Adrian Glaubitz : :' : Debian Developer `. `' Physicist `-GPG: 62FF 8A75 84E0 2956 9546 0006 7426 3B37 F5B5 F913
Problems with the kconfigeditor2 scripts
Hello!
I'm trying to change the kernel configuration for the two ia64 flavors using
the following workflow:
$ fakeroot make -f debian/rules.gen setup_ia64_none_itanium
$ make -C debian/build/build_ia64_none_mckinley nconfig
(changing configuration options here)
$ debian/rules orig
$ debian/rules debian/control
$ ~/kernel-team/utils/kconfigeditor2/process.py .
The last step fails with:
(sid_ia64-dchroot)glaubitz@yttrium:~/linux2/linux-5.17.3$
~/kernel-team/utils/kconfigeditor2/process.py .
Traceback (most recent call last):
File "/home/glaubitz/kernel-team/utils/kconfigeditor2/process.py", line 19,
in __init__
menu = fs_menu[featureset or 'none']
KeyError: 'rt'
During handling of the above exception, another exception occurred:
Traceback (most recent call last):
File "/home/glaubitz/kernel-team/utils/kconfigeditor2/process.py", line 70,
in
Main(package, source, config_output)
File "/home/glaubitz/kernel-team/utils/kconfigeditor2/process.py", line 21,
in __init__
menu = fs_menu[featureset] = All('%s/debian/build/source_%s' %
File
"/home/glaubitz/kernel-team/utils/kconfigeditor2/kconfigeditor/kconfig/menu/all.py",
line 31, in __init__
f = cache[filename] = self.read(filename)
File
"/home/glaubitz/kernel-team/utils/kconfigeditor2/kconfigeditor/kconfig/menu/all.py",
line 60, in read
return Parser()(open(os.path.join(self.root, filename)), filename)
FileNotFoundError: [Errno 2] No such file or directory:
'./debian/build/source_rt/Kconfig'
(sid_ia64-dchroot)glaubitz@yttrium:~/linux2/linux-5.17.3$
Does anyone know what I am doing wrong? Is the above way still the correct
method for
changing the kernel configuration in debian/config?
Thanks,
Adrian
--
.''`. John Paul Adrian Glaubitz
: :' : Debian Developer
`. `' Physicist
`-GPG: 62FF 8A75 84E0 2956 9546 0006 7426 3B37 F5B5 F913
Bug#1004255: linux-image-5.14.0-1-sparc64-smp: Debian kernels > 5.14.3-1~exp1 fail to boot on SPARC T4-1 with Fast Data Access MMU Miss
Hello Tom! On 1/23/22 17:39, Tom Turelinckx wrote: > Boot device: disk0 File and args: > SILO Version 1.4.14 > boot: > Allocated 64 Megs of memory at 0x4000 for kernel > Uncompressing image... > Loaded kernel version 5.14.6 > Loading initial ramdisk (25723814 bytes at 0x2480 phys, 0x40C0 > virt)... > ERROR: Last Trap: Fast Data Access MMU Miss This looks more like an issue with your bootloader. I haven't used SILO for a long time, so I don't have a track what currently works and what not. Can you try booting the current ISO snapshot image? [1] Adrian > [1] > https://cdimage.debian.org/cdimage/ports/snapshots/2021-10-20/debian-11.0.0-sparc64-NETINST-1.iso -- .''`. John Paul Adrian Glaubitz : :' : Debian Developer - glaub...@debian.org `. `' Freie Universitaet Berlin - glaub...@physik.fu-berlin.de `-GPG: 62FF 8A75 84E0 2956 9546 0006 7426 3B37 F5B5 F913
Bug#826796: Request for a new: linux-image-powerpc64-4K
On 10/7/21 10:46, Mathieu Malaterre wrote: >> In any case, if nouveau is completely broken with 64K pages then we >> should make sure nouveau is disabled in our default ppc64 >> configuration. > > True, but the only complaints I hear on debian-powerpc is from people on G5. I will change the kernel configuration to use 4K pages by default and create a new kernel flavor with 64K pages. We have different kernel flavors for many architectures. But getting this right in a way where the Debian kernel maintainers accept my patch is a bit tricky, so please give me some more time. As you know, there are a lot of issues piling up and a lot of the tasks end up with me. I will put this on my TODO list. Adrian -- .''`. John Paul Adrian Glaubitz : :' : Debian Developer - glaub...@debian.org `. `' Freie Universitaet Berlin - glaub...@physik.fu-berlin.de `-GPG: 62FF 8A75 84E0 2956 9546 0006 7426 3B37 F5B5 F913
Bug#961056: Bug#926539: Bug#987441: s390x installation bugs
Hi! On 5/3/21 12:21 PM, Valentin Vidic wrote: >>> I'd suggest at least retitling the bug report to mention s390x (release >>> arch, affected) instead of sparc64 (port arch, no longer affected), to >>> lower the chances people could overlook this issue, thinking it's only >>> about a port arch. >> >> We could also unmerge #926539 and #961056 again, then close the former bug >> which was sparc64-specific. > > I have unmerged the bugs now, so the sparc one can be closed. Alright, done. Thanks, Adrian -- .''`. John Paul Adrian Glaubitz : :' : Debian Developer - glaub...@debian.org `. `' Freie Universitaet Berlin - glaub...@physik.fu-berlin.de `-GPG: 62FF 8A75 84E0 2956 9546 0006 7426 3B37 F5B5 F913
Bug#926539: Bug#987441: s390x installation bugs
Hi! On 5/3/21 8:36 AM, Cyril Brulebois wrote: > From skimming through the bug log, it seems it was initially a sparc64 > problem, that was fixed in the kernel (inconsistent naming) eventually. Correct. > The same issue exists on s390x but isn't apparently going to get fixed > so we need to have d-i be smarter (hence the merge request)? Seems so. > I'd suggest at least retitling the bug report to mention s390x (release > arch, affected) instead of sparc64 (port arch, no longer affected), to > lower the chances people could overlook this issue, thinking it's only > about a port arch. We could also unmerge #926539 and #961056 again, then close the former bug which was sparc64-specific. Adrian -- .''`. John Paul Adrian Glaubitz : :' : Debian Developer - glaub...@debian.org `. `' Freie Universitaet Berlin - glaub...@physik.fu-berlin.de `-GPG: 62FF 8A75 84E0 2956 9546 0006 7426 3B37 F5B5 F913
Bug#741663: linux-image-3.13-1-powerpc-smp: therm_windtunnel does not load correctly
On 4/28/21 12:55 AM, Rick Thomas wrote: >> Rick, maybe you can check whether the windfarm module(s) get(s) loaded >> on your machine? >> >> # lsmod |grep windfarm > > On the G4 (which is _not_ the MDD) I get nothing from that Which is not surprising if the machine doesn't have the hardware. From my experience, most of the machines that use the windfarm thermal management system are G5 machines. > On the G5 I get: > > rbthomas@kmac:~$ lsmod | grep wind > windfarm_smu_sat8626 0 > windfarm_ad7417_sensor 7755 0 > windfarm_fcu_controls12227 0 > windfarm_cpufreq_clamp 3881 0 > windfarm_pm72 14329 0 > windfarm_pid3256 1 windfarm_pm72 > windfarm_lm75_sensor 5350 0 > windfarm_max6690_sensor 4600 0 > windfarm_core 11920 7 > windfarm_cpufreq_clamp,windfarm_fcu_controls,windfarm_max6690_sensor,windfarm_smu_sat,windfarm_ad7417_sensor,windfarm_pm72,windfarm_lm75_sensor That looks good. So G5 is fixed and works correctly. > PS: I do have a MDD, but I haven't yet tried Adrian's latest on it. Maybe > later today, maybe it'll have to wait for the weekend. If you could do that today, that would be great. If we know it works, we can finally close this bug report. Adrian -- .''`. John Paul Adrian Glaubitz : :' : Debian Developer - glaub...@debian.org `. `' Freie Universitaet Berlin - glaub...@physik.fu-berlin.de `-GPG: 62FF 8A75 84E0 2956 9546 0006 7426 3B37 F5B5 F913
Bug#741663: linux-image-3.13-1-powerpc-smp: therm_windtunnel does not load correctly
Hello Rick! On 4/27/21 8:54 AM, Rick Thomas wrote: > I'll look around and see if I have any MDD (mirror drive door -- the type in > the > original bugreport) machines. If so, I'll try to find some time to install > Adrian's > latest and report back. OK, thank you. Maybe someone else with a machine that previously had this issue can also comment so that we can be sure the issue has been fixed. Rick, maybe you can check whether the windfarm module(s) get(s) loaded on your machine? # lsmod |grep windfarm Adrian -- .''`. John Paul Adrian Glaubitz : :' : Debian Developer - glaub...@debian.org `. `' Freie Universitaet Berlin - glaub...@physik.fu-berlin.de `-GPG: 62FF 8A75 84E0 2956 9546 0006 7426 3B37 F5B5 F913
Bug#741663: linux-image-3.13-1-powerpc-smp: therm_windtunnel does not load correctly
On 4/27/21 2:07 AM, Rick Thomas wrote: > I've got the latest (Apr 17) running on my G5 right now. No problems. Rick, you should just confirm that this particular problem is fixed but I assume that this is the case? Adrian -- .''`. John Paul Adrian Glaubitz : :' : Debian Developer - glaub...@debian.org `. `' Freie Universitaet Berlin - glaub...@physik.fu-berlin.de `-GPG: 62FF 8A75 84E0 2956 9546 0006 7426 3B37 F5B5 F913
Bug#741663: linux-image-3.13-1-powerpc-smp: therm_windtunnel does not load correctly
Control: reopen -1 On 4/26/21 8:33 AM, Wolfram Sang wrote: > >> Wolfram just said that the you don't need custom kernels anymore but he >> didn't say whether the original bug report that the windfarm modules didn't >> load was fixed, did he? > > Yes and no. I am quite optimistic the bug was fixed with a patch which > is included upstream since 4.19-rc1. It still needs confirmation, > though, i.e. testing. The PowerMac G5 users on this list are kindly asked to confirm the bug has been fixed. Until then, I'll reopen it. > Back then, that meant compiling your own kernel. These days, you can > just use any Debian-provided kernel from 4.19 onwards. I'm not sure how this is relevant to the question whether the bug was fixed or not in the Debian kernel package. Adrian -- .''`. John Paul Adrian Glaubitz : :' : Debian Developer - glaub...@debian.org `. `' Freie Universitaet Berlin - glaub...@physik.fu-berlin.de `-GPG: 62FF 8A75 84E0 2956 9546 0006 7426 3B37 F5B5 F913
Bug#959768: [PATCH] initramfs-tools/hook-functions: Fix libgcc_s.so.1 dependency
Hi Ben! On 6/11/20 2:45 PM, Ben Hutchings wrote: >>> 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. >> Could you open a merge request on Salsa so that Ben just needs to merge this >> change? > > I actually implemented a fix for this already but didn't push it. > > Can you check whether the benh/libgcc_s branch works for you? Yes, I can confirm that this fixes the issue for me. Adrian -- .''`. John Paul Adrian Glaubitz : :' : Debian Developer - glaub...@debian.org `. `' Freie Universitaet Berlin - glaub...@physik.fu-berlin.de `-GPG: 62FF 8A75 84E0 2956 9546 0006 7426 3B37 F5B5 F913
Bug#959768: [PATCH] initramfs-tools/hook-functions: Fix libgcc_s.so.1 dependency
Hi Helge! On 5/28/20 12:14 AM, Helge Deller wrote: > 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. Could you open a merge request on Salsa so that Ben just needs to merge this change? Thanks, Adrian -- .''`. John Paul Adrian Glaubitz : :' : Debian Developer - glaub...@debian.org `. `' Freie Universitaet Berlin - glaub...@physik.fu-berlin.de `-GPG: 62FF 8A75 84E0 2956 9546 0006 7426 3B37 F5B5 F913
Bug#826796: Request for a new: linux-image-powerpc64-4K
On 6/5/20 3:03 PM, Lennart Sorensen wrote: >> Anyone with a large modern POWER machine is going to run the ppc64el >> port anyway. > > Only power8 and newer can run ppc64el, so all power 5, 6 and 7 users > would still need to run be. But there are probably a lot less than of > G5 users. And most people with work loads that have a use for 64k pages > are probably on newer machines too. Is POWER5 still supported by the Linux kernel? I thought IBM removed a bunch of older machines but kept PowerPC 970 support. Adrian -- .''`. John Paul Adrian Glaubitz : :' : Debian Developer - glaub...@debian.org `. `' Freie Universitaet Berlin - glaub...@physik.fu-berlin.de `-GPG: 62FF 8A75 84E0 2956 9546 0006 7426 3B37 F5B5 F913
Bug#826796: Request for a new: linux-image-powerpc64-4K
Hi Ben! > I'm sorry this is still unresolved. I have a couple of questions: > > * How will people discover this and know that they should use it? If > the installer is still being updated for ppc64, shouldn't we select > this kernel automatically when an Nvidia PCI device is detected? > > * Has anyone talked to the nouveau developers recently about either (a) > fixing support for larger pages or (b) fixing the dependencies for the > driver so it can't be built in an unsupported configuration? >From what I have read in the upstream bug tracker discussion, fixing this seems non-trivial as even the proprietary driver is using a hack to address this problem [1]. > In any case, if nouveau is completely broken with 64K pages then we > should make sure nouveau is disabled in our default ppc64 > configuration. I would like to switch the ppc64 kernel back to 4k pages. The majority of our users are people on G5 Macs anyway, so I don't see a point in using 64k pages. Anyone with a large modern POWER machine is going to run the ppc64el port anyway. Adrian > [1] https://gitlab.freedesktop.org/xorg/driver/xf86-video-nouveau/-/issues/258 -- .''`. John Paul Adrian Glaubitz : :' : Debian Developer - glaub...@debian.org `. `' Freie Universitaet Berlin - glaub...@physik.fu-berlin.de `-GPG: 62FF 8A75 84E0 2956 9546 0006 7426 3B37 F5B5 F913
Bug#926539: rootskel: steal-ctty no longer works on s390x
On 5/20/20 1:18 PM, Philipp Kern wrote: > But then I keep wondering how representative qemu is. Is VT220 SCLP even > something you get on a real z machine? Not that we shouldn't fix qemu, > of course. But Hercules might be closer to the real thing in this regard. Hercules shows the exact same behavior. I also don't think the emulation is relevant as the underlying issue is a naming inconsistency in the kernel which is only present on s390x and used to be present on sparc64. Adrian -- .''`. John Paul Adrian Glaubitz : :' : Debian Developer - glaub...@debian.org `. `' Freie Universitaet Berlin - glaub...@physik.fu-berlin.de `-GPG: 62FF 8A75 84E0 2956 9546 0006 7426 3B37 F5B5 F913
Bug#926539: rootskel: steal-ctty no longer works on s390x
On 5/20/20 12:42 PM, Valentin Vidić wrote: > It is hard to tell, but it seems the current state is hardcoded > in different places: > > https://www.redhat.com/archives/libguestfs/2017-May/msg00068.html This wouldn't cause breakage as with your change, the console name would actually be ttysclp0. > https://www.ibm.com/support/knowledgecenter/linuxonibm/com.ibm.linux.z.lhdd/lhdd_r_console_sum.html Well, IBM could just update their documentation. > I think it would be better to make debian-installer smarter about > this since we will probably run into the same problem again with > a different architecture/driver. It was only SPARC which had this issue as well and where it was fixed. For all the other architectures, the console and driver names already match. Adrian -- .''`. John Paul Adrian Glaubitz : :' : Debian Developer - glaub...@debian.org `. `' Freie Universitaet Berlin - glaub...@physik.fu-berlin.de `-GPG: 62FF 8A75 84E0 2956 9546 0006 7426 3B37 F5B5 F913
Bug#926539: rootskel: steal-ctty no longer works on s390x
On 5/20/20 11:17 AM, John Paul Adrian Glaubitz wrote: > I don't see any discussion in this thread. I would like to know the reasoning > why kernel upstream thinks that this naming inconsistency is correct. It > makes no sense, in my opinion and it can potentially trigger more problems. Ah, sorry. I was seeing the cached version of the thread, refreshing helped. In any case, the SPARC kernel maintainer (Dave Miller) had the same argument that it would potentially break existing setups but eventually I could convince him that the change was right. Not sure which distributions he has in mind. Adrian -- .''`. John Paul Adrian Glaubitz : :' : Debian Developer - glaub...@debian.org `. `' Freie Universitaet Berlin - glaub...@physik.fu-berlin.de `-GPG: 62FF 8A75 84E0 2956 9546 0006 7426 3B37 F5B5 F913
Bug#926539: rootskel: steal-ctty no longer works on s390x
Hi! On 5/20/20 11:00 AM, Valentin Vidić wrote: > Similar change for console name on s390x was not accepted: > > https://lkml.org/lkml/2020/5/19/854 > > so please fix in rootskel. I don't see any discussion in this thread. I would like to know the reasoning why kernel upstream thinks that this naming inconsistency is correct. It makes no sense, in my opinion and it can potentially trigger more problems. Also, this bug report should be merged with the other one that I referenced yesterday. Adrian -- .''`. John Paul Adrian Glaubitz : :' : Debian Developer - glaub...@debian.org `. `' Freie Universitaet Berlin - glaub...@physik.fu-berlin.de `-GPG: 62FF 8A75 84E0 2956 9546 0006 7426 3B37 F5B5 F913
Bug#959768: initramfs-tools: Does not account for different so versions of libgcc_s
Control: severity -1 important On 5/14/20 8:11 AM, Laurent Vivier wrote: > This bug prevents installation of new kernel packages. > > It's easy to workaround on an already installed system, with something like: > > sed -i "s/libgcc_s.so.1/libgcc_s.so.2/" > /usr/share/initramfs-tools/hook-functions > > But we can't install new systems as we can't patch the script before it > is used and the installation failed at 83% (on m68k) during the > installation of linux-image-5.6.0-1-m68k package (when it build the > initramfs). > > Do you have any solution to install a new system while this bug is not > fixed? Raising severity to important as it directly breaks Debian Ports installations. I can't raise it to serious though, unfortunately, as it's "just" Debian Ports that is broken. Adrian -- .''`. John Paul Adrian Glaubitz : :' : Debian Developer - glaub...@debian.org `. `' Freie Universitaet Berlin - glaub...@physik.fu-berlin.de `-GPG: 62FF 8A75 84E0 2956 9546 0006 7426 3B37 F5B5 F913
Re: Missing symbol on sh4: "__get_user_unknown"
On 5/10/20 3:27 PM, Ben Hutchings wrote: >> In any case, the kernel package now fails to build due to a missing symbol >> in the >> Infiniband core driver (see below). A simple workaround is to disable >> Infiniband >> support which allows me to build the kernel package normally (which I did and >> consequently uploaded). > [...] > > __get_user_unknown() is never defined, but will be referenced if the > get_user() macro is invoked with a variable of unsupported size (see > arch/sh/include/asm/uaccess.h). So my guess is that this module uses > get_user() to read a 64-bit value. Some 32-bit architectures do now > support this operation but I'm not sure whether they are expected to. I see, thanks a lot for the explanation. > This seems to have been introduced by commit 3a6532c9af1a, and could > probably be fixed by replacing the get_user() with a copy_from_user(). > > We could disable IB since it doesn't seem that likely to be used on > sh4, although I think the "verbs" layer can be used on top of Ethernet. I'm fine with that. Adrian -- .''`. John Paul Adrian Glaubitz : :' : Debian Developer - glaub...@debian.org `. `' Freie Universitaet Berlin - glaub...@physik.fu-berlin.de `-GPG: 62FF 8A75 84E0 2956 9546 0006 7426 3B37 F5B5 F913
Missing symbol on sh4: "__get_user_unknown"
(Please keep me CC'ed, I'm not subscribed to debian-kernel@)
Hi!
src:linux hasn't been building on sh4 in the past for a while now due to objdump
locking up during the build.
However, this problem has recently vanished, I assume maybe because the bug was
fixed in binutils.
In any case, the kernel package now fails to build due to a missing symbol in
the
Infiniband core driver (see below). A simple workaround is to disable Infiniband
support which allows me to build the kernel package normally (which I did and
consequently uploaded).
I vaguely remember that I have seen such issues with missing symbols in the past
with the kernel package, but I don't remember the details.
Does anyone know how to address this issue below?
Also, on sh4, the kernel needs a tiny patch by Arnd Bergmann to fix the systemd
build on sh4 after the Y2038 changes in the kernel (attached). Shall I open
a PR for that?
Thanks,
Adrian
gcc-9 -Wp,-MD,arch/sh/boot/compressed/.lshrsi3.o.d -nostdinc -isystem
/usr/lib/gcc/sh4-linux-gnu/9/include -I/<>/arch/sh/include
-I./arch/sh/include/generated -I/<>/include -I./include
-I/<>/arch/sh/include/uapi -I./arch/sh/include/generated/uapi
-I/<>/include/uapi -I./include/generated/uapi -include
/<>/include/linux/kconfig.h -D__KERNEL__ -m4 -m4-nofpu -ml
-mno-fdpic -Wa,-isa=sh4-up -ffreestanding -I
/<>/arch/sh/include/cpu-sh4 -I
/<>/arch/sh/include/cpu-common -I
/<>/arch/sh/include/mach-r2d -I
/<>/arch/sh/include/mach-common -D__ASSEMBLY__ -fno-PIE -m4
-m4-nofpu -ml -mno-fdpic -Wa,-isa=sh4-up -ffreestanding -I
/<>/arch/sh/include/cpu-sh4 -I
/<>/arch/sh/include/cpu-common -I
/<>/arch/sh/include/mach-r2d -I
/<>/arch/sh/include/mach-common -Wa,-gdwarf-2 -I
/<>/arch/sh/boot/compressed -I ./arch/sh/boot/compressed-c -o
arch/sh/boot/compressed/lshrsi3.o arch/sh/boot/compressed/lshrsi3.S
ld -EL -r --format binary --oformat elf32-sh-linux -T
/<>/arch/sh/boot/compressed/vmlinux.scr
arch/sh/boot/compressed/vmlinux.bin.xz -o arch/sh/boot/compressed/piggy.o
ld -EL --oformat elf32-sh-linux -Ttext 0x8c80 -e startup -T
arch/sh/boot/compressed/../../kernel/vmlinux.lds
arch/sh/boot/compressed/head_32.o arch/sh/boot/compressed/misc.o
arch/sh/boot/compressed/cache.o arch/sh/boot/compressed/piggy.o
arch/sh/boot/compressed/ashiftrt.o arch/sh/boot/compressed/ashldi3.o
arch/sh/boot/compressed/ashrsi3.o arch/sh/boot/compressed/ashlsi3.o
arch/sh/boot/compressed/lshrsi3.o -o arch/sh/boot/compressed/vmlinux
objcopy -O binary -R .note -R .note.gnu.build-id -R .comment -R .stab -R
.stabstr -S arch/sh/boot/compressed/vmlinux arch/sh/boot/zImage
Kernel: arch/sh/boot/zImage is ready
ERROR: "__get_user_unknown" [drivers/infiniband/core/ib_uverbs.ko] undefined!
make[5]: *** [/<>/scripts/Makefile.modpost:93: __modpost] Error 1
make[4]: *** [/<>/Makefile:1296: modules] Error 2
make[3]: *** [/<>/Makefile:180: sub-make] Error 2
make[3]: Leaving directory
'/<>/debian/build/build_sh4_none_sh7751r'
make[2]: *** [debian/rules.real:213: debian/stamps/build_sh4_none_sh7751r]
Error 2
make[2]: Leaving directory '/<>'
make[1]: *** [debian/rules.gen:701: build-arch_sh4_none_sh7751r_real] Error 2
make[1]: Leaving directory '/<>'
make: *** [debian/rules:33: build-arch] Error 2
--
.''`. John Paul Adrian Glaubitz
: :' : Debian Developer - glaub...@debian.org
`. `' Freie Universitaet Berlin - glaub...@physik.fu-berlin.de
`-GPG: 62FF 8A75 84E0 2956 9546 0006 7426 3B37 F5B5 F913
--- linux-5.6.7.orig/arch/sh/include/uapi/asm/sockios.h
+++ linux-5.6.7/arch/sh/include/uapi/asm/sockios.h
@@ -2,6 +2,8 @@
#ifndef __ASM_SH_SOCKIOS_H
#define __ASM_SH_SOCKIOS_H
+#include
+
/* Socket-level I/O control calls. */
#define FIOGETOWN _IOR('f', 123, int)
#define FIOSETOWN _IOW('f', 124, int)
Bug#959768: initramfs-tools: Does not account for different so versions of libgcc_s
Source: initramfs-tools Severity: important User: debian-h...@lists.debian.org Usertags: hppa,m68k Hello! In #950254 [1], a change was introduced to copy libgcc_s.so.1 into the initrd. Unfortunately, this change has introduced a regression on some architectures as the shared library has a different so version on these targets. amd64: root@z6:~> ls -l /lib/x86_64-linux-gnu/libgcc* -rw-r--r-- 1 root root 100736 May 2 14:09 /lib/x86_64-linux-gnu/libgcc_s.so.1 root@z6:~> hppa: root@phantom:~# ls -l /lib/hppa-linux-gnu/libgcc* -rw-r--r-- 1 root root 84412 Apr 18 09:56 /lib/hppa-linux-gnu/libgcc_s.so.4 root@phantom:~# m68k: root@elgar:~> ls -l /lib/m68k-linux-gnu/libgcc* -rw-r--r-- 1 root root 59116 Apr 18 11:56 /lib/m68k-linux-gnu/libgcc_s.so.2 root@elgar:~> Can you fix the change from #950254 to account for the different so versions of that library? Thanks, Adrian > [1] https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=950254 -- .''`. John Paul Adrian Glaubitz : :' : Debian Developer - glaub...@debian.org `. `' Freie Universitaet Berlin - glaub...@physik.fu-berlin.de `-GPG: 62FF 8A75 84E0 2956 9546 0006 7426 3B37 F5B5 F913
Bug#826796: Request for a new: linux-image-powerpc64-4K
Hi Mathieu! On 4/21/20 11:26 AM, Mathieu Malaterre wrote: > Dear Debian-kernel team, > >> Would it be possible to ship an alternate ppc64 kernel build without >> the 64K page option ? > > Could someone please clarify if this is possible/acceptable ? The new > ppc64 kernel would not be the default but could be installed on G5 > machine after installation. Another kernel flavor for powerpc64 is surely possible. It should be called -4k though as Debian does not allow uppercase letters in package names. On sh4, we also have two different flavors, see [1]. I suggest creating a branch in your Salsa home project with the necessary changes and then open a pull request. It should be mostly copy and paste work. Adrian > [1] > https://salsa.debian.org/kernel-team/linux/-/tree/master/debian%2Fconfig%2Fsh4 -- .''`. John Paul Adrian Glaubitz : :' : Debian Developer - glaub...@debian.org `. `' Freie Universitaet Berlin - glaub...@physik.fu-berlin.de `-GPG: 62FF 8A75 84E0 2956 9546 0006 7426 3B37 F5B5 F913
Bug#926539: rootskel: steal-ctty no longer works on at least sparc64
Control: reopen -1 On 3/28/20 6:16 PM, John Paul Adrian Glaubitz wrote: > On 3/28/20 5:39 PM, Ivo De Decker wrote: >> This bug wasn't fixed in time for buster. Is it still present in bullseye? If >> so, it might be good to try to fix it this time. > > I fixed the bug upstream [1], so we can safely close the issue here. Ah, I just realized this bug also affected s390x. Sorry, I will reopen it. Adrian -- .''`. John Paul Adrian Glaubitz : :' : Debian Developer - glaub...@debian.org `. `' Freie Universitaet Berlin - glaub...@physik.fu-berlin.de `-GPG: 62FF 8A75 84E0 2956 9546 0006 7426 3B37 F5B5 F913
Pull request #171
Hello! Could someone merge my pull request to disable crypto tests on m68k and sh4 [1]? Thanks, Adrian > [1] https://salsa.debian.org/kernel-team/linux/merge_requests/171
Bug#926539: rootskel: steal-ctty no longer works on at least sparc64
Hi! On 6/14/19 7:55 AM, John Paul Adrian Glaubitz wrote: > My patch has been merged upstream now and is planned for -stable [1]. It's now part of the 4.19 [1] and 5.1 [2] stable queues, so I guess we just have to wait a little now. @Ben: Can you make sure this bug gets closed with the next stable upload? Thanks! Adrian > [1] > https://git.kernel.org/pub/scm/linux/kernel/git/stable/stable-queue.git/commit/?id=cc95841f3511b943ad72133e67a105008839ead2 > [2] > https://git.kernel.org/pub/scm/linux/kernel/git/stable/stable-queue.git/commit/?id=176eeebcbf771062473c8f751fa2adb4a8baebb6 -- .''`. John Paul Adrian Glaubitz : :' : Debian Developer - glaub...@debian.org `. `' Freie Universitaet Berlin - glaub...@physik.fu-berlin.de `-GPG: 62FF 8A75 84E0 2956 9546 0006 7426 3B37 F5B5 F913
Bug#925379: linux-base: linux-version vmlinuz/vmlinux dichotomy, breaks at least m68k
Hi! On 4/17/19 10:48 PM, Ben Hutchings wrote: >> Just as a heads-up: I'm going to switch sparc and sparc64 over to an >> uncompressed kernel as well since compressed kernels are not >> officially >> supported and actually don't work with GRUB 2.04~rc1 when I tested >> on sparc64 [1]. > > It might be worth adding a versioned dependency on linux-base for the > affected architectures. Sure. I'm just waiting for the Buster release now before I'll be pushing changes to debian-installer and components and sending merge requests for src:linux and src:linux-base. I have already accumulated a couple of patches. Adrian -- .''`. John Paul Adrian Glaubitz : :' : Debian Developer - glaub...@debian.org `. `' Freie Universitaet Berlin - glaub...@physik.fu-berlin.de `-GPG: 62FF 8A75 84E0 2956 9546 0006 7426 3B37 F5B5 F913
Bug#925379: linux-base: linux-version vmlinuz/vmlinux dichotomy, breaks at least m68k
Hi!
On 3/24/19 1:28 AM, Thorsten Glaser wrote:
> This is because /usr/share/perl5/DebianLinux.pm was not updated
> accordingly:
>
> # Find kernel image name stem for this architecture
> my $image_stem;
> if ((uname())[4] =~ /^(?:mips|parisc|powerpc|ppc)/) {
> $image_stem = 'vmlinux';
> } else {
> $image_stem = 'vmlinuz';
> }
Just as a heads-up: I'm going to switch sparc and sparc64 over to an
uncompressed kernel as well since compressed kernels are not officially
supported and actually don't work with GRUB 2.04~rc1 when I tested
on sparc64 [1].
Adrian
> [1] http://lists.gnu.org/archive/html/grub-devel/2019-04/msg00071.html
--
.''`. John Paul Adrian Glaubitz
: :' : Debian Developer - glaub...@debian.org
`. `' Freie Universitaet Berlin - glaub...@physik.fu-berlin.de
`-GPG: 62FF 8A75 84E0 2956 9546 0006 7426 3B37 F5B5 F913
Bug#925379: linux-base: linux-version vmlinuz/vmlinux dichotomy, breaks at least m68k
On 3/24/19 1:28 AM, Thorsten Glaser wrote:
> Some time between 4.1.0-2 and 4.19.0-3, m68k kernels switched
> from vmlinuz-* to vmlinux-*:
I think on hppa, we switched the other way around. Putting in
debian-hppa@ into the loop.
> -rwxr-xr-x 1 root root 5933276 Feb 11 16:55 vmlinux-4.19.0-3-m68k*
> -rwxr-xr-x 1 root root 5933284 Mar 15 02:16 vmlinux-4.19.0-4-m68k*
> -rw-r--r-- 1 root root 1769849 Aug 26 2015 vmlinuz-4.1.0-2-m68k
>
> I was surprised by that 4.1.0-2 was the initrd updated by the
> initramfs-tools trigger on e2fsprogs update, before I purged
> (apt-get --purge autoremove) the 4.1.0-2 kernel, having just
> received the 4.19.0-4 one in a dist-upgrade.
>
> This is because /usr/share/perl5/DebianLinux.pm was not updated
> accordingly:
>
> # Find kernel image name stem for this architecture
> my $image_stem;
> if ((uname())[4] =~ /^(?:mips|parisc|powerpc|ppc)/) {
> $image_stem = 'vmlinux';
> } else {
> $image_stem = 'vmlinuz';
> }
>
> Since architectures can have both vmlinux-* and vmlinuz-*,
> I think this logic should be reconsidered and removed, as
> to instead take kernel images from both basenames.
>
> At the absolutely very least, it must be brought in line
> with current practicēs… however, that may break during
> upgrades, so, please redo it taking both names into account.
>
> -- System Information:
> Debian Release: buster/sid
> APT prefers unreleased
> APT policy: (500, 'unreleased'), (500, 'unstable')
> Architecture: m68k
>
> Kernel: Linux 4.19.0-3-m68k
> Locale: LANG=C, LC_CTYPE=en_GB.UTF-8 (charmap=UTF-8), LANGUAGE=C
> (charmap=UTF-8)
> Shell: /bin/sh linked to /bin/lksh
> Init: sysvinit (via /sbin/init)
>
> Versions of packages linux-base depends on:
> ii debconf [debconf-2.0] 1.5.71
>
> linux-base recommends no packages.
>
> linux-base suggests no packages.
>
> -- debconf information:
> * linux-base/disk-id-convert-auto: true
> linux-base/removing-title:
> * linux-base/disk-id-manual-boot-loader:
> linux-base/disk-id-convert-plan-no-relabel: true
> * linux-base/disk-id-convert-plan: true
> linux-base/removing-running-kernel: true
> linux-base/disk-id-manual:
> linux-base/do-bootloader-default-changed:
> linux-base/disk-id-update-failed:
>
--
.''`. John Paul Adrian Glaubitz
: :' : Debian Developer - glaub...@debian.org
`. `' Freie Universitaet Berlin - glaub...@physik.fu-berlin.de
`-GPG: 62FF 8A75 84E0 2956 9546 0006 7426 3B37 F5B5 F913
Bug#895131: linux-perf: Add libopencsd support to perf
On 3/13/19 8:14 PM, Ben Hutchings wrote: >> Since this library is ARM-specific anyway, wouldn't it make >> more sense to have this build-dependency on ARM targets only? > > Please open a *new* bug for this. Okay, can do. Although it seems that upstream is going to change libopencsd now to use -fPIC instead of -fpic. Adrian -- .''`. John Paul Adrian Glaubitz : :' : Debian Developer - glaub...@debian.org `. `' Freie Universitaet Berlin - glaub...@physik.fu-berlin.de `-GPG: 62FF 8A75 84E0 2956 9546 0006 7426 3B37 F5B5 F913
Bug#895131: linux-perf: Add libopencsd support to perf
On 3/13/19 5:14 PM, Gregor Riepl wrote: >> Since this library is ARM-specific anyway, wouldn't it make >> more sense to have this build-dependency on ARM targets only? > > libopencsd does build fine on other architectures, though. > > According to this[1], the fix should be simply replacing -fpic with -fPIC. I guess we could do this. I just find it odd that a profiling library for ARM is a build dependency on all architectures. I'll look into fixing libopencsd. Adrian -- .''`. John Paul Adrian Glaubitz : :' : Debian Developer - glaub...@debian.org `. `' Freie Universitaet Berlin - glaub...@physik.fu-berlin.de `-GPG: 62FF 8A75 84E0 2956 9546 0006 7426 3B37 F5B5 F913
Bug#895131: linux-perf: Add libopencsd support to perf
Package: src:linux Followup-For: Bug #895131 User: debian-sp...@lists.debian.org Usertags: sparc64 Hello! This change made src:linux BD-Uninstallable on sparc64 [1] as the package libopencsd doesn't build there [2]. Since this library is ARM-specific anyway, wouldn't it make more sense to have this build-dependency on ARM targets only? Thanks, Adrian > [1] https://buildd.debian.org/status/package.php?p=linux=sid > [2] https://buildd.debian.org/status/package.php?p=libopencsd=sid -- .''`. John Paul Adrian Glaubitz : :' : Debian Developer - glaub...@debian.org `. `' Freie Universitaet Berlin - glaub...@physik.fu-berlin.de `-GPG: 62FF 8A75 84E0 2956 9546 0006 7426 3B37 F5B5 F913
Bug#711135: compiling a bootable kernel for ia64 (itanium2, mckinley, rx2620)
On 02/05/2018 01:56 AM, Ivan Zakharyaschev wrote: > Now that we know how to build a bootable kernel for such machines as ours > (rx2620 with Madison CPU) and probably Daniel Kasza's rx2600, can such an > update be > published for wheezy? No, it's not possible to publish any such updates for Wheezy on ia64 as this architecture is not part of the LTS program: > https://wiki.debian.org/LTS > Perhaps, an additional variant of linux-image-mckinley built with gcc-4.4 > (4.4.7) present in wheezy? As a workaround for this bug. We are currently bootstrapping Debian buster/sid for ia64 with about 9500 packages out of 12000 packages already being built. I don't see any reason to provide kernel updates for Wheezy given these circumstances. > And what about an updated installation image? Not for Wheezy. I will create one for Debian buster/sid once I find the time though. But that won't happen before the package src:linux has been fixed on ia64 so that it builds on the buildds. > So that people trying to install Debian on such a machine would succeed not > only of they take the Debian 6 > (squeeze) image (which is definitely not the first thing they would try when > searching for an installation image), but so that Debian 7 (wheezy) images > (more > likely to be found by them) would work for them, too. I don't want to encourage people to install software which has been long out of support. People should either wait for the new installation images for buster/sid or use some of the workarounds suggested by other people in this thread. Adrian -- .''`. John Paul Adrian Glaubitz : :' : Debian Developer - glaub...@debian.org `. `' Freie Universitaet Berlin - glaub...@physik.fu-berlin.de `-GPG: 62FF 8A75 84E0 2956 9546 0006 7426 3B37 F5B5 F913
Bug#823224: ld: arch/powerpc/lib/crtsavres.o: No such file: No such file or directory
On 10/19/2017 10:18 PM, John Paul Adrian Glaubitz wrote: > I'm now running into exactly this problem when trying to build the SPL library > on a native ppc64 system for ZFS-on-Linux, see below. Addtional note: It works fine on a powerpc installation, so I'm confident it's a packaging issue. Adrian -- .''`. John Paul Adrian Glaubitz : :' : Debian Developer - glaub...@debian.org `. `' Freie Universitaet Berlin - glaub...@physik.fu-berlin.de `-GPG: 62FF 8A75 84E0 2956 9546 0006 7426 3B37 F5B5 F913
Bug#823224: ld: arch/powerpc/lib/crtsavres.o: No such file: No such file or directory
Hi Mathieu!
I'm now running into exactly this problem when trying to build the SPL library
on a native ppc64 system for ZFS-on-Linux, see below.
Can you give me a pointer on how to resolve this issue?
configure:15763: checking whether modules can be built
configure:15786: cp conftest.c build && make modules -C
/usr/src/linux-headers-4.13.0-1-powerpc64
EXTRA_CFLAGS=-Werror-implicit-function-declaration
M=/home/glaubitz/zfstests/spl/build
/bin/sh: 1: /usr/src/linux-headers-4.13.0-1-common/scripts/ld-version.sh: not
found
/bin/sh: 1: [: -ge: unexpected operator
ld: cannot find arch/powerpc/lib/crtsavres.o: No such file or directory
make[3]: *** [/home/glaubitz/zfstests/spl/build/conftest.ko] Error 1
make[2]: *** [modules] Error 2
make[1]: *** [sub-make] Error 2
make: *** [all] Error 2
configure:15789: $? = 2
configure: failed program was:
| /* confdefs.h */
| #define PACKAGE_NAME "spl"
| #define PACKAGE_TARNAME "spl"
| #define PACKAGE_VERSION "0.7.0"
| #define PACKAGE_STRING "spl 0.7.0"
| #define PACKAGE_BUGREPORT ""
| #define PACKAGE_URL ""
| #define SPL_META_NAME "spl"
| #define SPL_META_VERSION "0.7.0"
| #define SPL_META_RELEASE "17_g28920ea"
| #define SPL_META_LICENSE "GPL"
| #define SPL_META_ALIAS "spl-0.7.0-17_g28920ea"
| #define SPL_META_AUTHOR "OpenZFS on Linux"
| #define PACKAGE "spl"
| #define VERSION "0.7.0"
| #define STDC_HEADERS 1
| #define HAVE_SYS_TYPES_H 1
| #define HAVE_SYS_STAT_H 1
| #define HAVE_STDLIB_H 1
| #define HAVE_STRING_H 1
| #define HAVE_MEMORY_H 1
| #define HAVE_STRINGS_H 1
| #define HAVE_INTTYPES_H 1
| #define HAVE_STDINT_H 1
| #define HAVE_UNISTD_H 1
| #define HAVE_DLFCN_H 1
| #define LT_OBJDIR ".libs/"
|
|
| int
| main (void)
| {
|
| ;
| return 0;
| }
|
configure:15804: result: no
configure:15807: error: *** Unable to build an empty module.
Adrian
--
.''`. John Paul Adrian Glaubitz
: :' : Debian Developer - glaub...@debian.org
`. `' Freie Universitaet Berlin - glaub...@physik.fu-berlin.de
`-GPG: 62FF 8A75 84E0 2956 9546 0006 7426 3B37 F5B5 F913
Re: [m68k]: PULL: Build uncompressed kernel image by default
Hi Ben! Sorry for bothering you on a Saturday, but can you make sure this change gets merged before the next upload? Thanks, Adrian > On Oct 10, 2017, at 8:02 AM, John Paul Adrian Glaubitz > <glaub...@physik.fu-berlin.de> wrote: > > Hi Ben! > > I have changed the type of the kernel image to be uncompressed on > m68k as the bootloaders on at least Amiga and Atari systems have > problems decompressing large kernels. > > I will update debian-installer once you have merged my change, please > pull from the known location [1]. > > Thanks, > Adrian > >> [1] https://github.com/glaubitz/linux-debian > > -- > .''`. John Paul Adrian Glaubitz > : :' : Debian Developer - glaub...@debian.org > `. `' Freie Universitaet Berlin - glaub...@physik.fu-berlin.de > `-GPG: 62FF 8A75 84E0 2956 9546 0006 7426 3B37 F5B5 F913
[m68k]: PULL: Build uncompressed kernel image by default
Hi Ben! I have changed the type of the kernel image to be uncompressed on m68k as the bootloaders on at least Amiga and Atari systems have problems decompressing large kernels. I will update debian-installer once you have merged my change, please pull from the known location [1]. Thanks, Adrian > [1] https://github.com/glaubitz/linux-debian -- .''`. John Paul Adrian Glaubitz : :' : Debian Developer - glaub...@debian.org `. `' Freie Universitaet Berlin - glaub...@physik.fu-berlin.de `-GPG: 62FF 8A75 84E0 2956 9546 0006 7426 3B37 F5B5 F913
Re: [m68k]: Please pull m68k updates
Hi Ben! On 10/08/2017 07:49 PM, Ben Hutchings wrote: > I've pulled these changes and pushed them out to master. Thank you very much! > Just one question: would it not make sense to move ide-gd_mod to ide- > core-modules? It seems odd to have cdrom-core-modules depend on ide- > modules. I used this commit as a template: commit 6f6911d8334f029e5228ad32c905d8d7efabe8d9 Author: Ben Hutchings <b...@debian.org> Date: Tue Jun 11 02:48:16 2013 + udeb: Move ide-modules and ide-core-modules into ia64 configuration svn path=/dists/trunk/linux/; revision=20241 In the future, we're hopefully dropping the IDE modules anyway, so I think the current mechanism is fine as is, unless you think there is really a problem with it. Adrian -- .''`. John Paul Adrian Glaubitz : :' : Debian Developer - glaub...@debian.org `. `' Freie Universitaet Berlin - glaub...@physik.fu-berlin.de `-GPG: 62FF 8A75 84E0 2956 9546 0006 7426 3B37 F5B5 F913
[m68k]: Please pull m68k updates
Hi Ben! Please pull the master branch from [1] to add some missing drivers to ide-modules and scsi-modules on m68k. I have also enabled ata-modules for m68k which contains just libata. Apparently libata was already implicitly pulled in through pata-falcon through pata-modules. However, since other architectures list libata explicitly, I thought we should do that on m68k as well. I have also created ide-core-modules and ide-modules for m68k explicitly and moved the old-style IDE drivers from pata-modules to ide-modules, where they actually belong. Re-enabling the ide-modules is supposed to be a temporary solution until the drivers in question have been converted to libata. Those drivers are buddha, gayle, macide and q40ide and I'm helping Bartlomiej Zolnierkiewicz from Samsung who is working on the porting efforts to libata. I have build-tested my changes with the current src:linux package from experimental and verified my changes to work. Thanks, Adrian [1] https://github.com/glaubitz/linux-debian.git -- .''`. John Paul Adrian Glaubitz : :' : Debian Developer - glaub...@debian.org `. `' Freie Universitaet Berlin - glaub...@physik.fu-berlin.de `-GPG: 62FF 8A75 84E0 2956 9546 0006 7426 3B37 F5B5 F913
[m68k]: Please pull m68k updates
Hi Ben! Please pull the master branch from [1] to enable CONFIG_PATA_FALCON on m68k in src:linux. We want to start migrate to libata on m68k and falconide is one of the drivers that have already been ported. Thanks, Adrian [1] https://github.com/glaubitz/linux-debian.git -- .''`. John Paul Adrian Glaubitz : :' : Debian Developer - glaub...@debian.org `. `' Freie Universitaet Berlin - glaub...@physik.fu-berlin.de `-GPG: 62FF 8A75 84E0 2956 9546 0006 7426 3B37 F5B5 F913
Bug#865928: linux-image-4.9.0-3-m68k: fails to boot on ARAnyM due to NMI watchdog / soft stuck
Control: reassign -1 src:aranym Control: retitle -1 'aranym: Older versions of Aranym crash in atari_scsi with newer kernels' On Mon, Jun 26, 2017 at 03:03:04PM +1000, Finn Thain wrote: > > Hm, true. Unfortunately, I cannot upgrade ARAnyM until I get a newer > > kernel provided to Zigo’s domU (or switched to pvgrub-xen). > > > > The aranym fix was merged upsteam by Andreas Schwab on 2016-03-20. > https://sourceforge.net/p/aranym/code/ci/7af1cbfc5257d2c524ffe009790045d687c69fa5/ > > If you can't upgrade your emulator, why not ask the aranym maintainers to > backport the fix? If there is a fix already in Aranym, I don't think we should add any quirks to the kernel. I haven't actually run into the problem myself as the Aranym version on my laptop is recent enough. And since there is a simple work-around for those who are not able to upgrade their version of Aranym yet, I don't think further action is required. > > >This BTS entry should be reassigned to the aranym package. It's a > > > > Unclear about that. Yes, there’s an emulator bug, but does that mean > > there’s nothing to be done in the kernel? > > > > You just have to pursuade one of the driver maintainers that there is a > real need. > > Michael Schmitz and I are the maintainers for the upstream driver, and > eighteen months ago he and I were in agreement: "Making the 5380 emulation > a bit more complete such as in the MAME source snippet would be my > preference". So that's what was done. I agree with you and Michael. If the kernel behaves fine on real hardware, there is no point in trying to fix the bug there. > > I will just leave that to the parties responsible. > > > > Fair enough. We could just ask the maintainer of the Aranym package to provide an updated version in Debian Backports. Re-assigning in any case. Adrian -- .''`. John Paul Adrian Glaubitz : :' : Debian Developer - glaub...@debian.org `. `' Freie Universitaet Berlin - glaub...@physik.fu-berlin.de `-GPG: 62FF 8A75 84E0 2956 9546 0006 7426 3B37 F5B5 F913
Bug#865928: linux-image-4.9.0-3-m68k: fails to boot on ARAnyM due to NMI watchdog / soft stuck
On 06/26/2017 12:29 AM, Thorsten Glaser wrote: > I cannot boot Linux 4.9, but 4.1 still works. (I think 4.3 also failed, > but I had autoremoved that already.) I think you ran into this issue: > https://patchwork.kernel.org/patch/8098441/ Which can be worked-around by adding "initcall_blacklist=atari_scsi_driver_init" to the kernel command line. The buildd "mama" is running 4.11 with that work around. Adrian -- .''`. John Paul Adrian Glaubitz : :' : Debian Developer - glaub...@debian.org `. `' Freie Universitaet Berlin - glaub...@physik.fu-berlin.de `-GPG: 62FF 8A75 84E0 2956 9546 0006 7426 3B37 F5B5 F913
Bug#862813: linux: Please build loop-modules udeb on m68k
Source: linux Version: 4.11-1~exp2 Severity: normal Tags: patch User: debian-...@lists.debian.org Usertags: m68k Hi! debian-installer currently fails to build from source on m68k because we're missing the loop-modules udeb which is required to build the hd-media image of debian-installer. The attached patch enables it, please apply. Thanks, Adrian -- .''`. John Paul Adrian Glaubitz : :' : Debian Developer - glaub...@debian.org `. `' Freie Universitaet Berlin - glaub...@physik.fu-berlin.de `-GPG: 62FF 8A75 84E0 2956 9546 0006 7426 3B37 F5B5 F913 >From f896239b123c8b9423130ea37f793b55684441e8 Mon Sep 17 00:00:00 2001 From: John Paul Adrian Glaubitz <glaub...@physik.fu-berlin.de> Date: Wed, 17 May 2017 13:20:42 +0200 Subject: [PATCH] [m68k] udeb: Build loop-modules package Signed-off-by: John Paul Adrian Glaubitz <glaub...@physik.fu-berlin.de> --- debian/installer/m68k/modules/m68k/loop-modules | 1 + 1 file changed, 1 insertion(+) create mode 100644 debian/installer/m68k/modules/m68k/loop-modules diff --git a/debian/installer/m68k/modules/m68k/loop-modules b/debian/installer/m68k/modules/m68k/loop-modules new file mode 100644 index 0..c1c948fa3 --- /dev/null +++ b/debian/installer/m68k/modules/m68k/loop-modules @@ -0,0 +1 @@ +#include -- 2.11.0
Bug#862393: linux: FTBFS on m68k due outdated revert-m68k-move-exports-to-definitions.patch
Source: linux
Version: 4.11-1~exp2
Severity: normal
User: debian-...@lists.debian.org
Usertags: m68k
Hi!
linux currently fails to build from source in experimental because the
patch revert-m68k-move-exports-to-definitions.patch removes at least
one #include directive from arch/m68k/lib/ashldi3.c [1] which is now
required due to some upstream changes in the compiler macros used:
CC arch/m68k/lib/ashldi3.o
/<>/arch/m68k/lib/ashldi3.c:18:22: error: expected '=', ',', ';',
'asm' or '__attribute__' before '__mode'
typedef int SItype __mode(SI);
^~
/<>/arch/m68k/lib/ashldi3.c:19:30: error: expected '=', ',', ';',
'asm' or '__attribute__' before '__mode'
typedef unsigned int USItype __mode(SI);
^~
/<>/arch/m68k/lib/ashldi3.c:20:22: error: expected '=', ',', ';',
'asm' or '__attribute__' before '__mode'
typedef int DItype __mode(DI);
^~
/<>/arch/m68k/lib/ashldi3.c:21:33: error: expected '=', ',', ';',
'asm' or '__attribute__' before '__mode'
typedef int word_type __mode(__word__);
^~
/<>/arch/m68k/lib/ashldi3.c:23:18: error: unknown type name
'SItype'
struct DIstruct {SItype high, low;};
^~
/<>/arch/m68k/lib/ashldi3.c:28:3: error: unknown type name 'DItype'
DItype ll;
^~
/<>/arch/m68k/lib/ashldi3.c:31:1: error: unknown type name 'DItype'
DItype
^~
/<>/arch/m68k/lib/ashldi3.c:32:12: error: unknown type name
'DItype'
__ashldi3 (DItype u, word_type b)
^~
/<>/arch/m68k/lib/ashldi3.c:32:22: error: unknown type name
'word_type'
__ashldi3 (DItype u, word_type b)
^
/<>/scripts/Makefile.build:299: recipe for target
'arch/m68k/lib/ashldi3.o' failed
make[6]: *** [arch/m68k/lib/ashldi3.o] Error 1
arch/m68k/lib/ashldi3.c requires now because that's where
__mode() is defined as a compiler-specific macro. So the patch needs to be
updated accordingly. Since I currently don't understand why this particular
patch is necessary, I don't have a patch myself at hand.
Thanks,
Adrian
> [1]
> https://anonscm.debian.org/cgit/kernel/linux.git/tree/debian/patches/bugfix/m68k/revert-m68k-move-exports-to-definitions.patch#n86
--
.''`. John Paul Adrian Glaubitz
: :' : Debian Developer - glaub...@debian.org
`. `' Freie Universitaet Berlin - glaub...@physik.fu-berlin.de
`-GPG: 62FF 8A75 84E0 2956 9546 0006 7426 3B37 F5B5 F913
Bug#859366: linux: Please enable suffix for m68k debian-installer kernel image
Source: linux
Version: 4.9.18-1
Severity: normal
Tags: patch
User: debian-...@lists.debian.org
Usertags: m68k
Hi!
While working on fixing debian-installer on m68k, I ran into the
following problem after updating the m68k-specific configuration
to use the common m68k image:
# Set up modules.dep, ensure there is at least one standard dir (kernel
# in this case), so depmod will use its prune list for archs with no
# modules.
set -e; \
sysmap_name=; sysmap_opt=; if [ -n "t" ]; then [ ! -e
./tmp/cdrom/tree/boot/System.map-4.9.0-2-m68k ] ||
sysmap_name="./tmp/cdrom/tree/boot/System.map-4.9.0-2-m68k"; else [ ! -e
./tmp/cdrom/tree/boot/System.map ] ||
sysmap_name="./tmp/cdrom/tree/boot/System.map"; fi; [ -z "$sysmap_name" ] ||
sysmap_opt="-F $sysmap_name"; if [ -d ./tmp/cdrom/tree/lib/modules/4.9.0-2-m68k
] && [ -z "" ]; then mkdir -p ./tmp/cdrom/tree/lib/modules/4.9.0-2-m68k/kernel;
depmod $sysmap_opt -q -a -b ./tmp/cdrom/tree/ 4.9.0-2-m68k; fi; [ -z
"$sysmap_name" ] || mv $sysmap_name ./tmp/cdrom;
depmod: WARNING: Ignored deprecated option -q
# These files depmod makes are used by udev.
find ./tmp/cdrom/tree/lib/modules/ -maxdepth 2 -name 'modules*.bin' \
-not -name 'modules.builtin.bin' \
-not -type d | while read f; do rm -f ${f%.bin}; done
# These files are used to build special kernel images for some
# subarchitectures. Move them out of the way.
if [ -d ./tmp/cdrom/tree/usr/lib/kernel-image-4.9.0-2-m68k ]; then mv
./tmp/cdrom/tree/usr/lib/kernel-image-4.9.0-2-m68k ./tmp/cdrom/lib; fi; if [ -d
./tmp/cdrom/tree/usr/lib/linux-image-4.9.0-2-m68k ]; then mv
./tmp/cdrom/tree/usr/lib/linux-image-4.9.0-2-m68k ./tmp/cdrom/lib; fi;
# Move the kernel image out of the way.
mv -f ./tmp/cdrom/tree/boot/vmlinuz-4.9.0-2-m68k
./tmp/cdrom/vmlinuz-4.9.0-2-m68k;
mv: cannot stat './tmp/cdrom/tree/boot/vmlinuz-4.9.0-2-m68k': No such file or
directory
Makefile:310: recipe for target 'stamps/tree-unpack-cdrom-stamp' failed
make[7]: *** [stamps/tree-unpack-cdrom-stamp] Error 1
Looking into build/tmp/cdrom/tree/boot, both the kernel image as well
as the System.map file are missing the version suffix:
root@mama:/srv/d-i/debian-installer/installer# ls -l build/tmp/cdrom/tree/boot
total 3096
-rw-r--r-- 1 root root 1210526 Mar 30 01:16 System.map
-rw-r--r-- 1 root root 1957278 Mar 30 01:16 vmlinuz
root@mama:/srv/d-i/debian-installer/installer#
Thus, in order to fix this problem, please set the suffix option
for the d-i kernel image for m68k by applying the attached patch.
Thanks,
Adrian
--
.''`. John Paul Adrian Glaubitz
: :' : Debian Developer - glaub...@debian.org
`. `' Freie Universitaet Berlin - glaub...@physik.fu-berlin.de
`-GPG: 62FF 8A75 84E0 2956 9546 0006 7426 3B37 F5B5 F913
>From b46957d3400a1395f09d80518a555ae964ca39ec Mon Sep 17 00:00:00 2001
From: John Paul Adrian Glaubitz <glaub...@physik.fu-berlin.de>
Date: Sun, 2 Apr 2017 21:48:56 +0200
Subject: [PATCH] [m68k] udeb: Enable suffix for kernel-image
---
debian/installer/m68k/kernel-versions | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/debian/installer/m68k/kernel-versions
b/debian/installer/m68k/kernel-versions
index 86e3e98f3..ec5f9d3c4 100644
--- a/debian/installer/m68k/kernel-versions
+++ b/debian/installer/m68k/kernel-versions
@@ -1,2 +1,2 @@
# arch version flavour installedname suffix build-depends
-m68k - m68k- - -
+m68k - m68k- y -
--
2.11.0
Bug#850732: linux: please support building linux-libc-dev for the sh3 architecture
Source: linux Version: 4.9.1-1~exp1 Severity: wishlist Tags: patch User: helm...@debian.org Usertags: rebootstrap Hi! Similar to [1], I would like to ask to add basic support for sh3 in the Linux kernel package so that we can start bootstrapping this architecture in rebootstrap. The motivation is that sh3 is expected to be support by the J-Core open source CPU in the near future [2] which is fully compatible with the existing SuperH SH-3 architecture which has already partial support in Debian due to previous efforts before the SuperH port in Debian switched over to sh4 [3]. Attaching a patch against the linux source package in experimental. Thanks, Adrian > [1] https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=824524 > [2] http://j-core.org/roadmap.html > [3] https://wiki.debian.org/SH4/ -- .''`. John Paul Adrian Glaubitz : :' : Debian Developer - glaub...@debian.org `. `' Freie Universitaet Berlin - glaub...@physik.fu-berlin.de `-GPG: 62FF 8A75 84E0 2956 9546 0006 7426 3B37 F5B5 F913 >From d90c9db36b8e7660e75a0b3385836664299b9bdf Mon Sep 17 00:00:00 2001 From: John Paul Adrian Glaubitz <glaub...@physik.fu-berlin.de> Date: Mon, 9 Jan 2017 19:46:12 +0100 Subject: [PATCH] [sh3] Build a linux-libc-dev package (Closes: #-1) --- debian/changelog | 4 debian/config/defines | 1 + debian/config/sh3/defines | 4 3 files changed, 9 insertions(+) create mode 100644 debian/config/sh3/defines diff --git a/debian/changelog b/debian/changelog index 51f7dbb..3a9dc3a 100644 --- a/debian/changelog +++ b/debian/changelog @@ -1,11 +1,15 @@ linux (4.9.1-1~exp2) UNRELEASED; urgency=medium + [ Ben Hutchings ] * abiupdate.py: Use current config instead of downloading previous config * abiupdate.py: Update base URLs * abiupdate.py: Add support for incoming.ports.debian.org * Make the pickled config (config.defines.dump) reproducible * Remove debug symbol packages from debian/control to work around dak bug + [ John Paul Adrian Glaubitz ] + * [sh3] Build a linux-libc-dev package (Closes: #-1) + -- Ben Hutchings <b...@decadent.org.uk> Sat, 07 Jan 2017 17:41:34 + linux (4.9.1-1~exp1) experimental; urgency=medium diff --git a/debian/config/defines b/debian/config/defines index da2967d..c304fd5 100644 --- a/debian/config/defines +++ b/debian/config/defines @@ -31,6 +31,7 @@ arches: ppc64el s390 s390x + sh3 sh4 sparc sparc64 diff --git a/debian/config/sh3/defines b/debian/config/sh3/defines new file mode 100644 index 000..71cbe64 --- /dev/null +++ b/debian/config/sh3/defines @@ -0,0 +1,4 @@ +[base] +kernel-arch: sh +featuresets: +# empty; just building headers yet -- 2.1.4
Bug#836741: linux: FTBFS on powerpcspe due to the use of unsupported instructions
Control: forwarded -1 https://lists.ozlabs.org/pipermail/linuxppc-dev/2016-September/148424.html Control: tags -1 +pending There is now a suggested patch on the linuxppc-dev mailing list which fixes this issue [1]. Should be part of the next stable kernel update, will therefore tag this bug report as pending. Adrian > [1] https://lists.ozlabs.org/pipermail/linuxppc-dev/2016-September/148424.html -- .''`. John Paul Adrian Glaubitz : :' : Debian Developer - glaub...@debian.org `. `' Freie Universitaet Berlin - glaub...@physik.fu-berlin.de `-GPG: 62FF 8A75 84E0 2956 9546 0006 7426 3B37 F5B5 F913
Bug#833918: linux: Please enable cdc_ncm and cdc_mbim in d-i to support 'Dell 4-in-1 Adapter' Ethernet
Source: linux Version: 4.6.4-1 Severity: normal Hi! While reinstalling my Dell XPS-13 9343 yesterday, I ran into the problem that the Ethernet adapter in my external 'Dell 4-in-1 Adapter' [1] was not detected. This adapter is necessary because the XPS ultrabook series do not have an internal Ethernet adapter but require an external USB Ethernet adapter, with the 4-in-1 adapter from Dell being the standard accessory. This adapter uses the cdc_ncm/cdc_mbim kernel modules which are currently being disabled for debian-installer as those were suspected to be used by modems only [2], which is not the case, however. Here's the relevant output of lsusb, lsmod and dmesg after attaching the adapter my XPS-13 after installing with d-i Alpha 7 with a workaround. After plugging the adapter in, no additional configuration is necessary. The Ethernet adapter just works out of the box and we should therefore enable these modules in d-i, I think. glaubitz@ikarus:~$ lsusb |grep Bus\ 002 Bus 002 Device 005: ID 17e9:436f DisplayLink Bus 002 Device 004: ID 2109:0210 VIA Labs, Inc. Bus 002 Device 001: ID 1d6b:0003 Linux Foundation 3.0 root hub glaubitz@ikarus:~$ lsmod |grep cdc cdc_mbim 16384 0 cdc_wdm20480 1 cdc_mbim cdc_ncm32768 1 cdc_mbim cdc_ether 16384 0 usbnet 40960 3 cdc_mbim,cdc_ncm,cdc_ether usbcore 241664 14 btusb,snd_usb_audio,uvcvideo,snd_usbmidi_lib,ehci_hcd,ehci_pci,usbhid,usbnet,cdc_mbim,cdc_ncm,cdc_wdm,xhci_hcd,xhci_pci,cdc_ether glaubitz@ikarus:~$ dmesg | tail -n30 [ 9104.050604] usb 2-1: new SuperSpeed USB device number 4 using xhci_hcd [ 9104.06] usb 2-1: New USB device found, idVendor=2109, idProduct=0210 [ 9104.067782] usb 2-1: New USB device strings: Mfr=1, Product=2, SerialNumber=0 [ 9104.067785] usb 2-1: Product: USB3.0 Hub [ 9104.067786] usb 2-1: Manufacturer: VIA Labs, Inc. [ 9104.069404] hub 2-1:1.0: USB hub found [ 9104.069854] hub 2-1:1.0: 1 port detected [ 9104.178489] usb 1-1: new high-speed USB device number 11 using xhci_hcd [ 9104.511724] usb 1-1: New USB device found, idVendor=2109, idProduct=2210 [ 9104.511731] usb 1-1: New USB device strings: Mfr=1, Product=2, SerialNumber=0 [ 9104.511734] usb 1-1: Product: USB2.0 Hub [ 9104.511736] usb 1-1: Manufacturer: VIA Labs, Inc. [ 9104.512978] hub 1-1:1.0: USB hub found [ 9104.514078] hub 1-1:1.0: 4 ports detected [ 9105.578571] usb 2-1.1: new SuperSpeed USB device number 5 using xhci_hcd [ 9105.595153] usb 2-1.1: New USB device found, idVendor=17e9, idProduct=436f [ 9105.595157] usb 2-1.1: New USB device strings: Mfr=1, Product=2, SerialNumber=3 [ 9105.595160] usb 2-1.1: Product: Dell 4-in-1 Adapter [ 9105.595162] usb 2-1.1: Manufacturer: DisplayLink [ 9105.595164] usb 2-1.1: SerialNumber: 1505140265 [ 9105.602515] usb 2-1.1: Warning! Unlikely big volume range (=511), cval->res is probably wrong. [ 9105.602522] usb 2-1.1: [14] FU [Dell USB Audio Playback Volume] ch = 6, val = -8176/0/16 [ 9105.605635] cdc_ncm 2-1.1:1.5: MAC-Address: 9c:eb:e8:20:f5:5b [ 9105.605640] cdc_ncm 2-1.1:1.5: setting rx_max = 16384 [ 9105.605743] cdc_ncm 2-1.1:1.5: setting tx_max = 16384 [ 9105.605991] cdc_ncm 2-1.1:1.5 usb0: register 'cdc_ncm' at usb-:00:14.0-1.1, CDC NCM, 9c:eb:e8:20:f5:5b [ 9105.680400] cdc_ncm 2-1.1:1.5 enx9cebe820f55b: renamed from usb0 [ 9105.757799] IPv6: ADDRCONF(NETDEV_UP): enx9cebe820f55b: link is not ready [ 9105.757884] IPv6: ADDRCONF(NETDEV_UP): enx9cebe820f55b: link is not ready [ 9108.770155] cdc_ncm 2-1.1:1.5 enx9cebe820f55b: network connection: disconnected glaubitz@ikarus:~$ Thanks, Adrian > [1] > http://accessories.us.dell.com/sna/productdetail.aspx?c=us=19=en=470-ABHH > [2] > https://anonscm.debian.org/cgit/kernel/linux.git/tree/debian/installer/modules/nic-usb-modules -- .''`. John Paul Adrian Glaubitz : :' : Debian Developer - glaub...@debian.org `. `' Freie Universitaet Berlin - glaub...@physik.fu-berlin.de `-GPG: 62FF 8A75 84E0 2956 9546 0006 7426 3B37 F5B5 F913
Re: kernel modules does not have signatures, so taints kernel
On 06/01/2016 02:34 PM, Anatoly Pugachev wrote: > If module signing only for Secure Boot on EFI [2], why do we have it on > sparc64? Looks like an oversight to me. The kernels for the different architectures share some of the configuration, so it might just be a bug that this particular option should be set on architectures only which support SecureBoot. Adrian -- .''`. John Paul Adrian Glaubitz : :' : Debian Developer - glaub...@debian.org `. `' Freie Universitaet Berlin - glaub...@physik.fu-berlin.de `-GPG: 62FF 8A75 84E0 2956 9546 0006 7426 3B37 F5B5 F913
Bug#823526: linux: FTBFS on powerpcspe due to the use of unsupported instructions
On 05/05/2016 10:45 PM, Lennart Sorensen wrote: >> I just verified that the patch provided fixes the problem as expected. > > I have submitted it upstream. Great, that was quick. Please let me know in the bug tracker when it has been merged upstream, then Ben will be able to merge it in the Debian kernel. As I learned recently with two of my own patches, the policy we have in Debian prevented them from being merged unless they were merged upstream. Adrian -- .''`. John Paul Adrian Glaubitz : :' : Debian Developer - glaub...@debian.org `. `' Freie Universitaet Berlin - glaub...@physik.fu-berlin.de `-GPG: 62FF 8A75 84E0 2956 9546 0006 7426 3B37 F5B5 F913
Bug#823526: linux: FTBFS on powerpcspe due to the use of unsupported instructions
Control: tags -1 + patch On 05/05/2016 09:32 PM, John Paul Adrian Glaubitz wrote: >> If it works, I can submit it to the kernel. I don't have a powerpcspe >> environment to try building it, but I did notice that sstep.o contained >> those two instructions when building a ppc32 kernel, and that's wrong. >> After the patch those are gone as expected. > > I'll test it and let you know. I just verified that the patch provided fixes the problem as expected. Thanks, Adrian -- .''`. John Paul Adrian Glaubitz : :' : Debian Developer - glaub...@debian.org `. `' Freie Universitaet Berlin - glaub...@physik.fu-berlin.de `-GPG: 62FF 8A75 84E0 2956 9546 0006 7426 3B37 F5B5 F913
Bug#823526: linux: FTBFS on powerpcspe due to the use of unsupported instructions
On 05/05/2016 09:01 PM, Lennart Sorensen wrote: > I think this would fix it: > (...) Good idea, I'll give that a try! > It seems that gas on powerpc is willing to accept ldarx and stdcx even > when compiling in 32 bit mode (even though the instructions are not > allowed in 32 bit mode), while gas for powerpcspe does not seem willing > to accept them. So they need to be left out when building on 32 bit > systems, just like everywhere else in that file already did. Indeed. And ldarx and stdcx are definitely not available on e500, according to the datasheet by NXP. > If it works, I can submit it to the kernel. I don't have a powerpcspe > environment to try building it, but I did notice that sstep.o contained > those two instructions when building a ppc32 kernel, and that's wrong. > After the patch those are gone as expected. I'll test it and let you know. Adrian -- .''`. John Paul Adrian Glaubitz : :' : Debian Developer - glaub...@debian.org `. `' Freie Universitaet Berlin - glaub...@physik.fu-berlin.de `-GPG: 62FF 8A75 84E0 2956 9546 0006 7426 3B37 F5B5 F913
Bug#823526: linux: FTBFS on powerpcspe due to the use of unsupported instructions
Source: linux
Version: 4.5.2-1
Severity: normal
User: debian-powe...@lists.debian.org
Usertags: powerpcspe
Hi!
linux currently fails to build from source on powerpcspe since the compiler
is using FPU instructions which are not available on the e500v2 CPUs [1,2]:
{standard input}: Assembler messages:
{standard input}:2227: Error: unrecognized opcode: `ldarx'
{standard input}:2274: Error: unrecognized opcode: `stdcx.'
/<>/scripts/Makefile.build:263: recipe for target
'arch/powerpc/lib/sstep.o' failed
make[6]: *** [arch/powerpc/lib/sstep.o] Error 1
/<>/Makefile:954: recipe for target 'arch/powerpc/lib' failed
make[5]: *** [arch/powerpc/lib] Error 2
make[5]: *** Waiting for unfinished jobs
Looking at arch/powerpc/lib/sstep.c, there are actually #ifdefs for the
CONFIG_PPC_FPU,
however, it seems there is no way of manually setting CONFIG_PPC_FPU in the
kernel
configuration. I assume, this is done by choosing a certain type of PowerPC
hardware.
In any case, version 3.16.7 still builds fine [3], so this is a regression
either
way. Although we currently have to use a custom kernel for our e500v2 boards
anyway, it's still desirable to fix any build issues with the kernel package
on powerpcspe.
Cheers,
Adrian
> [1]
> https://buildd.debian.org/status/fetch.php?pkg=linux=powerpcspe=4.5.2-1=1462426562
> [2] http://www.nxp.com/files/32bit/doc/ref_manual/E500CORERM.pdf
> [3]
> https://buildd.debian.org/status/fetch.php?pkg=linux=powerpcspe=3.16.7-ckt9-3=1458056490
--
.''`. John Paul Adrian Glaubitz
: :' : Debian Developer - glaub...@debian.org
`. `' Freie Universitaet Berlin - glaub...@physik.fu-berlin.de
`-GPG: 62FF 8A75 84E0 2956 9546 0006 7426 3B37 F5B5 F913
Bug#815977: closed by Ben Hutchings <b...@decadent.org.uk> (Re: Bug#815977: kernel-image-4.4.0-1-sparc64-di: Please add sunvnet and sunvdc for d-i)
On 04/21/2016 01:07 PM, John Paul Adrian Glaubitz wrote: > On 04/21/2016 12:59 PM, Ben Hutchings wrote: >> As you should know, our general policy is to wait for patches to be >> applied by the subsystem maintainer. Let us know when they are. > > Ok, I wasn't aware of that. I will let you know once that has happened! That has happened now: > http://git.kernel.org/cgit/linux/kernel/git/davem/sparc.git/commit/?id=5bde2c9be701c4583f0a9243bd46590ec401bfba > http://git.kernel.org/cgit/linux/kernel/git/davem/sparc.git/commit/?id=36128d204b81c099b5779771127a5546eac549c9 Adrian -- .''`. John Paul Adrian Glaubitz : :' : Debian Developer - glaub...@debian.org `. `' Freie Universitaet Berlin - glaub...@physik.fu-berlin.de `-GPG: 62FF 8A75 84E0 2956 9546 0006 7426 3B37 F5B5 F913 signature.asc Description: OpenPGP digital signature
Bug#822364: linux: FTBFS on sh4: #error __NR_bpf not defined. libbpf does not support your arch.
Source: linux Version: 4.5.1-1 Severity: normal User: debian-sup...@lists.debian.org Usertags: sh4 Hi! Linux 4.5.1 fails to build from source on sh4 since it tries to build the libbpf code which has not been ported to sh4 yet [1]: gcc -Wp,-MD,/«PKGBUILDDIR»/debian/build/build-tools/tools/perf/.bpf.o.d,-MT,/«PKGBUILDDIR»/debian/build/build-tools/tools/perf/bpf.o -g -O2 -fstack-protector-strong -Wformat -Werror=format-security -Wall -Wdate-time -D_FORTIFY_SOURCE=2 -I/«PKGBUILDDIR»/tools/perf -I/«PKGBUILDDIR»/debian/build/build-tools/tools/perf -isystem /«PKGBUILDDIR»/debian/build/build-tools/include -DHAVE_LIBELF_MMAP_SUPPORT -DHAVE_ELF_GETPHDRNUM_SUPPORT -Wno-error -Werror -Wall -fPIC -I. -I/«PKGBUILDDIR»/tools/include -I/«PKGBUILDDIR»/arch/sh/include/uapi -I/«PKGBUILDDIR»/include/uapi -D"BUILD_STR(s)=#s" -c -o /«PKGBUILDDIR»/debian/build/build-tools/tools/perf/bpf.o bpf.c bpf.c:28:4: error: #error __NR_bpf not defined. libbpf does not support your arch. # error __NR_bpf not defined. libbpf does not support your arch. ^ bpf.c: In function 'sys_bpf': bpf.c:40:17: error: '__NR_bpf' undeclared (first use in this function) return syscall(__NR_bpf, cmd, attr, size); ^ bpf.c:40:17: note: each undeclared identifier is reported only once for each function it appears in bpf.c:41:1: error: control reaches end of non-void function [-Werror=return-type] } ^ cc1: all warnings being treated as errors mv: cannot stat '/«PKGBUILDDIR»/debian/build/build-tools/tools/perf/.bpf.o.tmp': No such file or directory make[8]: *** [/«PKGBUILDDIR»/debian/build/build-tools/tools/perf/bpf.o] Error 1 /«PKGBUILDDIR»/tools/build/Makefile.build:77: recipe for target '/«PKGBUILDDIR»/debian/build/build-tools/tools/perf/bpf.o' failed make[7]: *** [/«PKGBUILDDIR»/debian/build/build-tools/tools/perf/libbpf-in.o] Error 2 Makefile:157: recipe for target '/«PKGBUILDDIR»/debian/build/build-tools/tools/perf/libbpf-in.o' failed make[7]: Leaving directory '/«PKGBUILDDIR»/tools/lib/bpf' make[6]: *** [/«PKGBUILDDIR»/debian/build/build-tools/tools/perf/libbpf.a] Error 2 Makefile.perf:451: recipe for target '/«PKGBUILDDIR»/debian/build/build-tools/tools/perf/libbpf.a' failed make[6]: Leaving directory '/«PKGBUILDDIR»/tools/perf' make[5]: *** [all] Error 2 /«PKGBUILDDIR»/debian/rules.d/tools/perf/Makefile:49: recipe for target 'all' failed Could you disable libbpf on sh4 for the time being? Thanks, Adrian > [1] > https://buildd.debian.org/status/fetch.php?pkg=linux=sh4=4.5.1-1=1461192004 -- .''`. John Paul Adrian Glaubitz : :' : Debian Developer - glaub...@debian.org `. `' Freie Universitaet Berlin - glaub...@physik.fu-berlin.de `-GPG: 62FF 8A75 84E0 2956 9546 0006 7426 3B37 F5B5 F913
Bug#815977: closed by Ben Hutchings <b...@decadent.org.uk> (Re: Bug#815977: kernel-image-4.4.0-1-sparc64-di: Please add sunvnet and sunvdc for d-i)
On 04/21/2016 12:59 PM, Ben Hutchings wrote: > As you should know, our general policy is to wait for patches to be > applied by the subsystem maintainer. Let us know when they are. Ok, I wasn't aware of that. I will let you know once that has happened! Thanks, Adrian -- .''`. John Paul Adrian Glaubitz : :' : Debian Developer - glaub...@debian.org `. `' Freie Universitaet Berlin - glaub...@physik.fu-berlin.de `-GPG: 62FF 8A75 84E0 2956 9546 0006 7426 3B37 F5B5 F913 signature.asc Description: OpenPGP digital signature
Bug#815977: closed by Ben Hutchings <b...@decadent.org.uk> (Re: Bug#815977: kernel-image-4.4.0-1-sparc64-di: Please add sunvnet and sunvdc for d-i)
Control: retitle -1 linux: Please add autoloading support for vio On 04/14/2016 11:19 AM, John Paul Adrian Glaubitz wrote: > On 04/14/2016 10:56 AM, John Paul Adrian Glaubitz wrote: >> Hold on a second, I had a copy-and-paste error, the patch needs >> a slight update since __ATTR_RO(modalias) is misssing in >> vio_dev_attrs. > > Attaching a cleaned up patch. Ping. Can we get this patch merged or is there anything that needs further review or discussion? FWIW, the patch set has been acked upstream [1,2], but it has not been merged yet. It would be great to have this patch merged into the Debian kernel as it fixes the issues people have when installing Debian in an LDOM. Adrian > [1] http://patchwork.ozlabs.org/patch/610563/ > [2] http://patchwork.ozlabs.org/patch/610562/ -- .''`. John Paul Adrian Glaubitz : :' : Debian Developer - glaub...@debian.org `. `' Freie Universitaet Berlin - glaub...@physik.fu-berlin.de `-GPG: 62FF 8A75 84E0 2956 9546 0006 7426 3B37 F5B5 F913 signature.asc Description: OpenPGP digital signature
Bug#815977: closed by Ben Hutchings <b...@decadent.org.uk> (Re: Bug#815977: kernel-image-4.4.0-1-sparc64-di: Please add sunvnet and sunvdc for d-i)
On 04/14/2016 10:56 AM, John Paul Adrian Glaubitz wrote:
> Hold on a second, I had a copy-and-paste error, the patch needs
> a slight update since __ATTR_RO(modalias) is misssing in
> vio_dev_attrs.
Attaching a cleaned up patch.
Adrian
--
.''`. John Paul Adrian Glaubitz
: :' : Debian Developer - glaub...@debian.org
`. `' Freie Universitaet Berlin - glaub...@physik.fu-berlin.de
`-GPG: 62FF 8A75 84E0 2956 9546 0006 7426 3B37 F5B5 F913
From: John Paul Adrian Glaubitz <glaub...@physik.fu-berlin.de>
Date: Thu, 14 Apr 2016 11:14:00 +0200
Subject: sparc: Enable autoloading for vio drivers.
Bug-Debian: https://bugs.debian.org/815977
The vio driver on sparc has been missing both modalias_show as
well as a hotplug event handler which are both required to
enable automatic loading for the vio modules. With this patch,
both sunvnet and sunvdc are loaded automatically which is
necessary when installing Debian in a sparc LDOM.
Signed-off-by: John Paul Adrian Glaubitz <glaub...@physik.fu-berlin.de>
diff --git a/arch/sparc/kernel/vio.c b/arch/sparc/kernel/vio.c
index cb5789c..73b33b1 100644
--- a/arch/sparc/kernel/vio.c
+++ b/arch/sparc/kernel/vio.c
@@ -45,6 +45,14 @@ static const struct vio_device_id *vio_match_device(
return NULL;
}
+static int vio_hotplug(struct device *dev, struct kobj_uevent_env *env)
+{
+ const struct vio_dev *vio_dev = to_vio_dev(dev);
+
+ add_uevent_var(env, "MODALIAS=vio:T%sS%s", vio_dev->type, vio_dev->compat);
+ return 0;
+}
+
static int vio_bus_match(struct device *dev, struct device_driver *drv)
{
struct vio_dev *vio_dev = to_vio_dev(dev);
@@ -105,15 +113,25 @@ static ssize_t type_show(struct device *dev,
return sprintf(buf, "%s\n", vdev->type);
}
+static ssize_t modalias_show(struct device *dev, struct device_attribute *attr,
+ char *buf)
+{
+ const struct vio_dev *vdev = to_vio_dev(dev);
+
+ return sprintf(buf, "vio:T%sS%s\n", vdev->type, vdev->compat);
+}
+
static struct device_attribute vio_dev_attrs[] = {
__ATTR_RO(devspec),
__ATTR_RO(type),
+ __ATTR_RO(modalias),
__ATTR_NULL
};
static struct bus_type vio_bus_type = {
.name = "vio",
.dev_attrs = vio_dev_attrs,
+ .uevent = vio_hotplug,
.match = vio_bus_match,
.probe = vio_device_probe,
.remove = vio_device_remove,
signature.asc
Description: OpenPGP digital signature
Bug#815977: closed by Ben Hutchings <b...@decadent.org.uk> (Re: Bug#815977: kernel-image-4.4.0-1-sparc64-di: Please add sunvnet and sunvdc for d-i)
On 04/13/2016 05:27 PM, John Paul Adrian Glaubitz wrote: > Ok, tested it and it didn't work unfortunately. The modules are > not loaded automatically and it seems the reason is that the > modaliases are not generated: Hold on a second, I had a copy-and-paste error, the patch needs a slight update since __ATTR_RO(modalias) is misssing in vio_dev_attrs. Adrian -- .''`. John Paul Adrian Glaubitz : :' : Debian Developer - glaub...@debian.org `. `' Freie Universitaet Berlin - glaub...@physik.fu-berlin.de `-GPG: 62FF 8A75 84E0 2956 9546 0006 7426 3B37 F5B5 F913 signature.asc Description: OpenPGP digital signature
Bug#815977: closed by Ben Hutchings <b...@decadent.org.uk> (Re: Bug#815977: kernel-image-4.4.0-1-sparc64-di: Please add sunvnet and sunvdc for d-i)
Control: tags -1 patch
Hi Ben!
On 04/13/2016 05:40 PM, Ben Hutchings wrote:
> Try deleting the 'if (!cp)' block.
That wasn't enough. I invested some more time and now have a patch
that does the trick. Module aliases are created correctly and
module autoloading is working as expected. This has been tested
with Debian unstable and kernel 4.5.1 on a SPARC-T5 in a Linux
LDOM.
Attaching my patch. I also sent it as two single patches upstream.
Adrian
--
.''`. John Paul Adrian Glaubitz
: :' : Debian Developer - glaub...@debian.org
`. `' Freie Universitaet Berlin - glaub...@physik.fu-berlin.de
`-GPG: 62FF 8A75 84E0 2956 9546 0006 7426 3B37 F5B5 F913
diff --git a/arch/sparc/kernel/vio.c b/arch/sparc/kernel/vio.c
index cb5789c..59f4b7c 100644
--- a/arch/sparc/kernel/vio.c
+++ b/arch/sparc/kernel/vio.c
@@ -45,6 +45,13 @@ static const struct vio_device_id *vio_match_device(
return NULL;
}
+static int vio_hotplug(struct device *dev, struct kobj_uevent_env *env)
+{
+ const struct vio_dev *vio_dev = to_vio_dev(dev);
+ add_uevent_var(env, "MODALIAS=vio:T%sS%s", vio_dev->type, vio_dev->compat);
+ return 0;
+}
+
static int vio_bus_match(struct device *dev, struct device_driver *drv)
{
struct vio_dev *vio_dev = to_vio_dev(dev);
@@ -105,6 +112,13 @@ static ssize_t type_show(struct device *dev,
return sprintf(buf, "%s\n", vdev->type);
}
+static ssize_t modalias_show(struct device *dev, struct device_attribute *attr,
+ char *buf)
+{
+ const struct vio_dev *vdev = to_vio_dev(dev);
+ return sprintf(buf, "vio:T%sS%s\n", vdev->type, vdev->compat);
+}
+
static struct device_attribute vio_dev_attrs[] = {
__ATTR_RO(devspec),
__ATTR_RO(type),
@@ -114,6 +128,7 @@ static struct device_attribute vio_dev_attrs[] = {
static struct bus_type vio_bus_type = {
.name = "vio",
.dev_attrs = vio_dev_attrs,
+ .uevent = vio_hotplug,
.match = vio_bus_match,
.probe = vio_device_probe,
.remove = vio_device_remove,
signature.asc
Description: OpenPGP digital signature
Bug#815977: closed by Ben Hutchings <b...@decadent.org.uk> (Re: Bug#815977: kernel-image-4.4.0-1-sparc64-di: Please add sunvnet and sunvdc for d-i)
On 04/13/2016 02:03 PM, John Paul Adrian Glaubitz wrote: > On 04/11/2016 01:32 AM, Ben Hutchings wrote: >> The attached patch might fix that, though the correct fix would >> presumably be to merge the two implementations. > > Thanks a lot for the explanation and the patch. I will test the > patch and then we can maybe decide if we include it as a work > around. Ok, tested it and it didn't work unfortunately. The modules are not loaded automatically and it seems the reason is that the modaliases are not generated: root@deb4g:~# cat /sys/devices/channel-devices/vdc-port-0-0/modalias root@deb4g:~# Will do further debugging. Adrian -- .''`. John Paul Adrian Glaubitz : :' : Debian Developer - glaub...@debian.org `. `' Freie Universitaet Berlin - glaub...@physik.fu-berlin.de `-GPG: 62FF 8A75 84E0 2956 9546 0006 7426 3B37 F5B5 F913 signature.asc Description: OpenPGP digital signature
Bug#815977: closed by Ben Hutchings <b...@decadent.org.uk> (Re: Bug#815977: kernel-image-4.4.0-1-sparc64-di: Please add sunvnet and sunvdc for d-i)
On 04/11/2016 01:32 AM, Ben Hutchings wrote: > The attached patch might fix that, though the correct fix would > presumably be to merge the two implementations. Thanks a lot for the explanation and the patch. I will test the patch and then we can maybe decide if we include it as a work around. I have also notified upstream and Dave Miller is now looking at a proper fix. Adrian -- .''`. John Paul Adrian Glaubitz : :' : Debian Developer - glaub...@debian.org `. `' Freie Universitaet Berlin - glaub...@physik.fu-berlin.de `-GPG: 62FF 8A75 84E0 2956 9546 0006 7426 3B37 F5B5 F913 signature.asc Description: OpenPGP digital signature
Bug#815977: closed by Ben Hutchings <b...@decadent.org.uk> (Re: Bug#815977: kernel-image-4.4.0-1-sparc64-di: Please add sunvnet and sunvdc for d-i)
On 04/10/2016 10:17 PM, Ben Hutchings wrote: > Like everything else in the installer initramfs, they are installed > from a udeb. See build/pkg-lists/*/sparc64.cfg Yeah, I remember that now. Indeed, scsi-core-modules was missing. However, nic-modules was already there. I rebuilt d-i now making sure both are present and created a new set of images. When booting on a SPARC-T5, the modules are just not loaded automatically. Dropping out of d-i into a shell and just loading the modules with "modprobe sunvdc" and "modprobe sunvnet" works: [3549345.279904] sunvdc.c:v1.2 (November 24, 2014) [3549345.281060] sunvdc: Virtual Hard disk vdiska [3549345.281064] sunvdc: vdiska: 20971520 sectors (10240 MB) protocol 1.1 [3549345.281610] vdiska: vdiska1 vdiska2 vdiska3 [3549345.284722] sunvdc: Virtual CDROM vdiskb [3549345.284727] sunvdc: vdiskb: 338864 sectors (165 MB) protocol 1.1 [3549345.285054] vdiskb: vdiskb1 vdiskb2 vdiskb3 vdiskb4 vdiskb5 vdiskb6 vdiskb7 [3549361.270957] sunvnet.c:v1.0 (June 25, 2007) [3549361.273663] vnet_port vnet-port-0-0 eth0: Sun LDOM vnet 00:14:4f:f8:57:82 [3549361.273720] sunvnet: eth0: PORT ( remote-mac XX:XX:XX:XX:XX:XX switch-port ) [3549361.273930] sunvnet: eth0: PORT ( remote-mac XX:XX:XX:XX:XX:XX ) [3549361.273995] sunvnet: eth0: PORT ( remote-mac XX:XX:XX:XX:XX:XX ) [3549361.274055] sunvnet: eth0: PORT ( remote-mac XX:XX:XX:XX:XX:XX ) [3549361.274115] sunvnet: eth0: PORT ( remote-mac XX:XX:XX:XX:XX:XX ) [3549361.274175] sunvnet: eth0: PORT ( remote-mac XX:XX:XX:XX:XX:XX ) So, the question now is why those modules aren't loaded automatically when boot the debian-installer initrd and kernel. Adrian PS: I replaced the actual MAC addresses above with "XX". -- .''`. John Paul Adrian Glaubitz : :' : Debian Developer - glaub...@debian.org `. `' Freie Universitaet Berlin - glaub...@physik.fu-berlin.de `-GPG: 62FF 8A75 84E0 2956 9546 0006 7426 3B37 F5B5 F913 signature.asc Description: OpenPGP digital signature
Bug#815977: closed by Ben Hutchings <b...@decadent.org.uk> (Re: Bug#815977: kernel-image-4.4.0-1-sparc64-di: Please add sunvnet and sunvdc for d-i)
On 04/10/2016 08:50 PM, Ben Hutchings wrote: > initramfs-tools has nothing to do with the installer initramfs. Hmm, ok. Then I'll need to keep digging in debian-installer. So far, I haven't found the obvious place yet which is responsible for adding modules to the initrd in the debian-installer image. Adrian -- .''`. John Paul Adrian Glaubitz : :' : Debian Developer - glaub...@debian.org `. `' Freie Universitaet Berlin - glaub...@physik.fu-berlin.de `-GPG: 62FF 8A75 84E0 2956 9546 0006 7426 3B37 F5B5 F913 signature.asc Description: OpenPGP digital signature
Bug#815977: closed by Ben Hutchings <b...@decadent.org.uk> (Re: Bug#815977: kernel-image-4.4.0-1-sparc64-di: Please add sunvnet and sunvdc for d-i)
Hi Ben! On Sun, Mar 20, 2016 at 01:54:05AM +, Debian Bug Tracking System wrote: > $ git grep -E 'sunvdc|sunvnet' debian/installer/ > debian/installer/sparc64/modules/sparc64/nic-modules:sunvnet ? > debian/installer/sparc64/modules/sparc64/scsi-core-modules:sunvdc ? > $ dpkg-deb -c /tmp/nic-modules-4.4.0-1-sparc64-di_4.4.6-1_sparc64.udeb | grep > sunvnet > -rw-r--r-- root/root 43488 2016-03-17 23:05 > ./lib/modules/4.4.0-1-sparc64/kernel/drivers/net/ethernet/sun/sunvnet.ko > $ dpkg-deb -c /tmp/scsi-core-modules-4.4.0-1-sparc64-di_4.4.6-1_sparc64.udeb > | grep sunvdc > -rw-r--r-- root/root 28680 2016-03-17 23:04 > ./lib/modules/4.4.0-1-sparc64/kernel/drivers/block/sunvdc.ko > > All looks good to me. Sounds like you're not including the right > packages in your installer image. The packages are there, otherwise it wouldn't be possible to load the modules manually right after booting the installer. There must be an issue with the module loading mechanism. Grepping through sources.debian.net, it looks like the modules are actually loaded by initramfs-tools when /sys/bus/vio is present during boot. Thus, we first need to verify whether this is actually true. Maybe there was a change in the kernel that changed the behavior of the sysfs entry so that the check in the initramfs script fails. Cheers, Adrian > [1] > http://sources.debian.net/src/initramfs-tools/0.123/hook-functions/?hl=478#L478 -- .''`. John Paul Adrian Glaubitz : :' : Debian Developer - glaub...@debian.org `. `' Freie Universitaet Berlin - glaub...@physik.fu-berlin.de `-GPG: 62FF 8A75 84E0 2956 9546 0006 7426 3B37 F5B5 F913
Bug#815977: kernel-image-4.4.0-1-sparc64-di: Please add sunvnet and sunvdc for d-i
Source: linux Version: 4.4.2-3 Severity: normal User: debian-sp...@lists.debian.org Usertags: sparc64 Hi! Several sparc64 users recently reported that the sunvnet and sunvdc modules have been missing while installing with debian-installer and they had to load these manually [1]. As it turns out, these module have been missing in the past in the d-i kernel package on sparc [2], thus I guess the fix should be the same. If this is not directly a kernel issue but an issue with the installation images I am creating, please let me know. But since I couldn't anything in d-i which allows me to define a list of modules to be loaded, I assume it's something to be changed in the kernel package. Thanks, Adrian > [1] https://lists.debian.org/debian-sparc/2016/02/msg00054.html > [2] https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=504702 -- .''`. John Paul Adrian Glaubitz : :' : Debian Developer - glaub...@debian.org `. `' Freie Universitaet Berlin - glaub...@physik.fu-berlin.de `-GPG: 62FF 8A75 84E0 2956 9546 0006 7426 3B37 F5B5 F913
Bug#809928: linux-image-4.3.0-1-m68k: does not boot any more (on ARAnyM)
On 01/24/2016 11:48 AM, John Paul Adrian Glaubitz wrote: > Can you try kernel 4.4 from experimental? That should be available > as of now as I have enabled building experimental packages for > m68k now. Linux 4.4 works fine here on Aranym: root@pacman:~> uname -a Linux pacman 4.4.0-trunk-m68k #1 Debian 4.4-1~exp1 (2016-01-19) m68k GNU/Linux root@pacman:~> Aranym version is: glaubitz@sammel84:~$ dpkg -l aranym Desired=Unknown/Install/Remove/Purge/Hold | Status=Not/Inst/Conf-files/Unpacked/halF-conf/Half-inst/trig-aWait/Trig-pend |/ Err?=(none)/Reinst-required (Status,Err: uppercase=bad) ||/ Name Version Architecture Description +++-=-===-===-=== ii aranym1.0.2-2 amd64 Atari Running on Any Machine glaubitz@sammel84:~$ Adrian -- .''`. John Paul Adrian Glaubitz : :' : Debian Developer - glaub...@debian.org `. `' Freie Universitaet Berlin - glaub...@physik.fu-berlin.de `-GPG: 62FF 8A75 84E0 2956 9546 0006 7426 3B37 F5B5 F913
Bug#812928: udev: cdrom_id terminated by signal BUS
Control: reassign -1 src:systemd Control: found -1 228-4 Control: retitle -1 initialize_srand provokes unaligned access On 01/28/2016 07:37 AM, Anatoly Pugachev wrote: > restored original cdrom_id.c (with initialize_srand() function call) and > recompiled with memcpy() and run: > > mator@deb4g:~/systemd$ sudo ./cdrom_id -l /dev/vdiskb > ID_CDROM=1 > > there's no SIGBUS. And I don't know what it should output. Probably fixed. > Thanks. This is clearly a bug in udev/src:systemd then. I'll re-assign this and also report this upstream. Thanks for debugging this! Adrian -- .''`. John Paul Adrian Glaubitz : :' : Debian Developer - glaub...@debian.org `. `' Freie Universitaet Berlin - glaub...@physik.fu-berlin.de `-GPG: 62FF 8A75 84E0 2956 9546 0006 7426 3B37 F5B5 F913
Bug#809928: linux-image-4.3.0-1-m68k: does not boot any more (on ARAnyM)
On 01/05/2016 12:02 AM, Thorsten Glaser wrote: >> What about other kernels versions inbetween? I'm running a > > Dunno, I only use Debian kernels, but ISTR reporting a similar > issue for 4.2. Can you try kernel 4.4 from experimental? That should be available as of now as I have enabled building experimental packages for m68k now. Adrian -- .''`. John Paul Adrian Glaubitz : :' : Debian Developer - glaub...@debian.org `. `' Freie Universitaet Berlin - glaub...@physik.fu-berlin.de `-GPG: 62FF 8A75 84E0 2956 9546 0006 7426 3B37 F5B5 F913
Bug#782058: Pegasos II: installer boots up to 'returning from prom_init'
-BEGIN PGP SIGNED MESSAGE- Hash: SHA256 On 12/09/2015 03:39 AM, Milan Kupcevic wrote: > The module in question gets loaded and is used in D-I only. Pay > attention to the case you are pointing at: the graphics does not > work on boot/reboot into an installed system. At this point this > module plays no role because it is blacklisted in the main system. > This user is having some other issues unrelated to this module. Did you actually check that it is blacklisted after installation? radeon KMS worked fine on every PPC Mac hardware that I tested. However, I always ran into exactly this issue when radeonfb was loaded, even when it was unloaded later. Apparently, radeonfb sets the GPU in a state from which the radeon KMS module cannot recover it. My Mac Mini G4 is currently packed up because I am moving soon. But I will re-test this at some point because I am pretty sure this is again radeonfb messing with the GPU as the symptoms are the same. Adrian - -- .''`. John Paul Adrian Glaubitz : :' : Debian Developer - glaub...@debian.org `. `' Freie Universitaet Berlin - glaub...@physik.fu-berlin.de `-GPG: 62FF 8A75 84E0 2956 9546 0006 7426 3B37 F5B5 F913 -BEGIN PGP SIGNATURE- Version: GnuPG v2 iQIcBAEBCAAGBQJWZ/h2AAoJEHQmOzf1tfkTG5QP/3fIYZCRl+V3MbpWoXjivBU/ Njgwtsjh67Z/vouM9eT50U2Jc3Db/6a8rtWb3cwuYfES+36fxxK3HiExr5/aRwzo 19gBbkCweYGDErZLoc0OnY7UZT1Fk0FcNfU4FdC4edMtrb63dYsQAhxFbI8NVfba tJTH1pJi5MqLx03rzcPKl97/4OKFTP4b1+54nojZaXYnQG7pmFsK1Amx4nM4xqAJ 5uxbJ/q/ViEGqgLE8xso9471mKyTYm3+FI8kcxq83XNEqf9WDilRBcQgPvIkwfvW lB5ALaKpd3fjb2yOM2557W857hMuzD7+i0jW23P5ieKcb0hxc3HVOJKLCTNDrYDR inknkx/ZoOGhzHQC1sr4e8AHsT6Tp1dQLK0fyuGKasa2FKHeqN4eueYZImO2QFpG Ir/xoYYVXZPWyAS0xGH3sddn9WsP7tvOphChgPyi5VBMoaaJqq2CBupdUTLarc9/ cZeU4jPYZo7seRtCKcdTPibm0V+keInzUC5PNoVb2lDD20kWSlDpaeCHcVp+yp8s Y1ZwFUtaPYjGljz6ei23+0v+VIei2fhGyzpLkQ8xJjQt2/XsGaWT0eD9CAsNPocC C/nWxruTt8+RUg9Wg/fO9K8X1cNCh/HfU9wNtMid74ski9prxZNG+xxFgOOfzxo1 2UEz9Xkajsesb8+nZTaA =21XG -END PGP SIGNATURE-
Bug#782058: Pegasos II: installer boots up to 'returning from prom_init'
On Fri, Apr 10, 2015 at 05:39:50PM -0400, Milan Kupcevic wrote: > The module landed in sid D-I. It gets loaded automatically as it is not > blacklisted in D-I. I've been able to boot and run the installer on an > XServe G4 DP, a G4 Mac Mini, and a Pegasos II. All three machines have > radeon cards. This reddit user got different results which rather support my stance: > https://www.reddit.com/r/debian/3vyn0p/ Frankly, I think it's more important to have a working graphics driver on ubiqutous Apple PowerPC hardware than on these extremely obscure Pegasos-II boards which have very negligible user base given the fact that those were rather expensive due to their low production numbers. So my opinion remains unchanged: Drop radeonfb by any means as it's obsolete and breaks the way more ubiqutous radeon KMS driver. Cheers, Adrian -- .''`. John Paul Adrian Glaubitz : :' : Debian Developer - glaub...@debian.org `. `' Freie Universitaet Berlin - glaub...@physik.fu-berlin.de `-GPG: 62FF 8A75 84E0 2956 9546 0006 7426 3B37 F5B5 F913
Bug#782058: Pegasos II: installer boots up to 'returning from prom_init'
On 04/09/2015 02:21 PM, Ben Hutchings wrote: It isn't reverted. All I've done is to add radeonfb.ko to the drivers that are included *in the installer*. Yes, I understand that. I still disagree with the change. Neither radeon.ko nor xserver-xorg-video-radeon are included in the installer, so how could they possibly be used? If you though those should be used in the installer, you should have told people that earlier. I didn't know they weren't included. I assumed that the graphics driver modules are important enough to be present in the installer image. As it is, I think that the installer should be able to work using radeonfb.ko and xserver-xorg-video-fbdev, though I'm not sure whether radeonfb.ko will be loaded automatically. As I have said before [1], radeonfb and xserver-xorg-video-fbdev aren't really working, the graphics are broken. Here's how it looks on a Powerbook G4 (with the same result on a Mac Mini G4) with radeonfb enabled: http://i.imgur.com/Miw5CR1.jpg http://i.imgur.com/AfpNdx3.jpg http://i.imgur.com/QBUPwRA.jpg On 04/09/2015 02:24 PM, Milan Kupcevic wrote: How is that X display in debian installer on PowerPC platform working for you? I never said it is. I said your suggested fix was wrong. Your understanding of the consequences of your changes is trully stellar. So you basically disagree about the graphical installer being broken on all PowerPC machines with Radeon graphics is not an important issue? OK. Well, I've asked, no one complained until you showed up. The resulting discussion spreads very interesting scent. I complained because I care about the end product. Are you sure you want to know about every non-x86 issue I face on daily basis? If it involves making such important changes to the kernel configuration, then yes. I am a porter for the m68k and sh4 architectures in Debian and also have large numbers of different hardware platforms available to test Debian on, ranging from a 22-year-old Amiga with 68030/50 MHz to an SGI UV-1000 supercomputer, so I can cover lots of use cases and I do lots of testing. On 04/09/2015 08:11 PM, Milan Kupcevic wrote: Sorry, my reaction to personal attacks was too harsh. Will stick to technical issues and ignore any personal slurs from now on. That wasn't a personal attack. I was criticizing you for requesting such a change without apparently reading the bug report where I elaborated why I said we should no longer use radeonfb. I have repeated several times that this driver produces broken graphics and I am starting to feel like an idiot having to repeat this over and over again. Cheers, Adrian [1] https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=748398#106 -- .''`. John Paul Adrian Glaubitz : :' : Debian Developer - glaub...@debian.org `. `' Freie Universitaet Berlin - glaub...@physik.fu-berlin.de `-GPG: 62FF 8A75 84E0 2956 9546 0006 7426 3B37 F5B5 F913 -- 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/5526e0d1.9020...@physik.fu-berlin.de
Bug#782058: Pegasos II: installer boots up to 'returning from prom_init'
-BEGIN PGP SIGNED MESSAGE- Hash: SHA256 On 04/09/2015 12:38 AM, Milan Kupcevic wrote: Well, yes. As you could see from the bug report you linked above, compiling radeonfb into the kernel broke X on basically all Radeon cards. It seems that radeonfb was compiled into the kernel since the dawn of time. On the powerpc Debian kernel, yes, on the other architectures, no. radeonfb has been deprecated long time ago and should no longer be used. The only reason it was compiled into the powerpc kernel without anyone complaining is the fact that the xf86-video-ati (= Radeon X.Org) driver in Wheezy was still old enough [1] to support userland mode-setting which was dropped upstream in version 7.0.0 almost three years ago [2]. This is no longer true in Jessie and therefore we have to use radeon, not radeonfb. Otherwise you won't get any X display. The reason is that the radeon KMS module does not work once radoenfb has been loaded once. Even if you unload radeonfb later, the radeon module will still refuse to work meaning X will not be usable. This is good to know. I did thorough testing for the bug report you linked above which is why I am a bit surprised you could convince Ben so easily to partly revert my change. I think I also explained in the other bug tracker that you have to use KMS these days as UMS is being phased out. Well, I think this can be answered straight-forward: radeonfb is the wrong solution as radeonfb does not support X which means you can use the text-based installer only. But I guess you never tested that as you stated in your bug report. The proper fix for your problem is not to revert my previous fix but to use the proper driver, thus reopening. There was no my previous fix, just reporting about the state of the things in RC1 and RC2. I'm trying to help as I have access to more than a few power and powerpc machines. Sure, but please ask people in the future before you are asking for changes which you don't understand. I also have tons of different hardware available here, including several powerpc machines and way beyond that (m68k, sh4, mips etc). I think you should at least discuss such changes with some more people before you ask for them to be integrated. For anyone who follows X.Org and kernel development, it is common knowledge that all the non-KMS drivers in the kernel are being deprecated and that you should no longer use them. This also applies to X.Org. It would be nice if you could CC me in the future if you are having issues with non-x86 hardware, especially anything that's powerpc, Macintosh, or - like in this case - Amiga-related hardware. Adrian - -- .''`. John Paul Adrian Glaubitz : :' : Debian Developer - glaub...@debian.org `. `' Freie Universitaet Berlin - glaub...@physik.fu-berlin.de `-GPG: 62FF 8A75 84E0 2956 9546 0006 7426 3B37 F5B5 F913 -BEGIN PGP SIGNATURE- Version: GnuPG v1 iQIcBAEBCAAGBQJVJjNyAAoJEHQmOzf1tfkTItwQAJid5vaSBdjsJBSROc7URnNp G7kc6AEF3oaEbX1lsqQ/wfvfKsFdKztN+ro4oAPW7xgo/QxQI7qWuDxNgTvbyOl2 9ApGjwliLKU5D4em479V58qTUnl0agcTqJxruWU88Kdb5NxUQrtAnRdqrmak6e5m pHPA+uMREu8KKM1TDOjw1ErJEKUXV8lnH+LVKIWRvWBoS9n63mHTZv69YDwSTZvh +V4zhVqwb++kcrVYX+GqPaeX+/N5hH1SaS2PAwqZCXXNXMm0x3XAHNVwk1GvvDek e+pZEiJi3pr7AtyJuzHsREQyIc3ivgDzw14DUvXIpSdrvkufj1jo/WbmkT+F9aik W0Tl5mu3zFW5pmXnGInL1umUv1JcE6yE79WorCYf+xDPHnfAZfkozy7nzPdjdZrO tV1PVdNg+tpPzJzD3JC8/x+YonvOolpvVCBRiJ43c5s80pV3yNglavPNEe/TEkFE ULwzvAbp72HyBirFX1S0aTlLbI85oRrxzcGfZrao0HTA6tm9nj9rsjPWpbaGjjsQ oWcX2b6xjBu7ng73Hpi8BIaLj6ECrt0hdMUGAvDf1OnMdYzNjSqX8gpJjjOJJpDs QQwfkSeZW8IVF1Nm5U6QTJ9Mgbcma19EDQyARyCiAKnscFMMp+iWDs0pBmKfXqZA zHWeVlv7eqivC+qDfMmU =mU0y -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: https://lists.debian.org/55263372.40...@physik.fu-berlin.de
Bug#782058: Pegasos II: installer boots up to 'returning from prom_init'
-BEGIN PGP SIGNED MESSAGE- Hash: SHA256 On 04/09/2015 10:08 AM, John Paul Adrian Glaubitz wrote: The only reason it was compiled into the powerpc kernel without anyone complaining is the fact that the xf86-video-ati (= Radeon X.Org) driver in Wheezy was still old enough [1] to support userland mode-setting which was dropped upstream in version 7.0.0 almost three years ago [2]. Forgot the references. [1] https://packages.qa.debian.org/x/xserver-xorg-video-ati.html [2] http://lists.x.org/archives/xorg-announce/2012-November/002093.html - -- .''`. John Paul Adrian Glaubitz : :' : Debian Developer - glaub...@debian.org `. `' Freie Universitaet Berlin - glaub...@physik.fu-berlin.de `-GPG: 62FF 8A75 84E0 2956 9546 0006 7426 3B37 F5B5 F913 -BEGIN PGP SIGNATURE- Version: GnuPG v1 iQIcBAEBCAAGBQJVJjOqAAoJEHQmOzf1tfkTKVMP/jfVh6SApUn4+CZLWvouH3Vx gJbD9k1sv1BQ9PbF9LZXtxoUX5nEkqZPdGBx3YFbwgv6wxdshELP6T6oIEf/ui+L xtPoA1BuRf4FFZVWOzT/5+agXuJYIYkc6Wn2ctT5glU6wgjYB0iArxuR2spxuoDg wfsDpGQ93W9XB2BEyxFpolTkY+tYR/OyTQRWPYMqg1MvAnPte5WXsLpI7fT7PERt ACcNDDgV9O780GDKS0KgntlV30JDk3yBVuFXqAFEMLTK7exIiaurKR0CUxRqFvR5 kU80jw9FK0wxQ7VppMxRbrudqeWByqwNd1CKrD7wA8Yq3uIfC0IZyoxcPR54STc5 bqfuCMOZU2NwsANRjNXHo7ywbuMJLymgMW0sO1Y51ke0JsYAzFFeoTd4eVnvv1Ft /8D1ETEYdgQbgTn9VSciMplPCMenKh61Em2RPh310VgCczcPH+bVyQAtrbSSYLUe +6d25iCM98OeHJRwUY9taCQXzTl22Ix+fmOT9EwPshzwJ8IaurvpDYr3eVi88KaY VF0oqNBsTbAdtgZPz2cZOITRiHe6yrQMSjwvPxK0AYJhMr16ecXYuQpPP6DlNyE2 OASqNVLKLSkwrCGqXwAa87glr7/DX499V2EwSuYEaq8M2oJhtSePrk0eD6K86vmF yFnT92Z0zB8vRh9UfoIp =qino -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: https://lists.debian.org/552633aa.2080...@physik.fu-berlin.de
Bug#782058: Pegasos II: installer boots up to 'returning from prom_init'
Hi Milan! I just stumbled across this bug report and was actually wondering why your Pegasos-II board won't work properly with the radeon KMS driver. As far as I know, the Radeon 9250 found on the Pegasos-II board is fully supported by the radeon KMS driver, so I'd expect it to work out-of the-box. I always had the opinion that radeonfb was deprecated in favor of the KMS driver and therefore the latter is the one you should be using. Maybe it's a good idea to report any issues with the KMS driver to the radeon upstream developers? Cheers, Adrian -- .''`. John Paul Adrian Glaubitz : :' : Debian Developer - glaub...@debian.org `. `' Freie Universitaet Berlin - glaub...@physik.fu-berlin.de `-GPG: 62FF 8A75 84E0 2956 9546 0006 7426 3B37 F5B5 F913 -- 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/55256d83.1090...@physik.fu-berlin.de
Bug#782058: Pegasos II: installer boots up to 'returning from prom_init'
Control: reopen -1 Hi! On 04/08/2015 09:51 PM, Milan Kupcevic wrote: In Wheezy and in Jessie RC1 radenfb was compiled in the kernel itself while debian installer worked fine on this machine. Well, yes. As you could see from the bug report you linked above, compiling radeonfb into the kernel broke X on basically all Radeon cards. The reason is that the radeon KMS module does not work once radoenfb has been loaded once. Even if you unload radeonfb later, the radeon module will still refuse to work meaning X will not be usable. If you want to use X, you **have** to use the radeon KMS driver as the xf86-video-radeon driver does no longer support UMS modesetting which means no matter what you do, you will **never** be able to run X once radeonfb is loaded until next reboot. Neither radeon nor radeonfb driver is included in RC2 debian installer. Well, yes, we forgot to include radeon, true. OpenFirmware frame buffer never worked on Pegasos machines so I had to use serial port to install RC2. After successful installation, the machine boots up and uses radeon KMS installed on its HD. Alright, then your fix was wrong. We should have included radeon, **not** the deprecated radeonfb driver which does no longer work with X and will probably removed from the kernel at some point. Whether we want to include radeonfb module or radeon KMS module in debian installer is question open to discussion. Well, I think this can be answered straight-forward: radeonfb is the wrong solution as radeonfb does not support X which means you can use the text-based installer only. But I guess you never tested that as you stated in your bug report. The proper fix for your problem is not to revert my previous fix but to use the proper driver, thus reopening. Cheers, Adrian -- .''`. John Paul Adrian Glaubitz : :' : Debian Developer - glaub...@debian.org `. `' Freie Universitaet Berlin - glaub...@physik.fu-berlin.de `-GPG: 62FF 8A75 84E0 2956 9546 0006 7426 3B37 F5B5 F913 -- 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/55258968.6020...@physik.fu-berlin.de
Bug#775611: [sh]: FTBFS due to unknown compiler option '-m32'
-BEGIN PGP SIGNED MESSAGE- Hash: SHA256 On 01/18/2015 12:52 PM, Ben Hutchings wrote: The next question is whether recordmcount.c works properly for SH. Adrian, can you check whether ftrace seems to work on the kernel built with HAVE_C_RECORDMCOUNT selected? (See Documentation/trace/ftrace.txt and particularly the 'function' example.) I guess that involves also installing the kernel and running it? The reason why I ask is that I currently don't have physical access to any of the SH4 machines yet as I am still waiting for Nobuhiro Iwamatsu to send me one of the spare boards he has. Thus, if the kernel locks up the kernel for whatever reason, I am a bit lost until Nobuhiro can reset the machine. Having my own local SH4 machine would simplify things dramatically. Adrian - -- .''`. John Paul Adrian Glaubitz : :' : Debian Developer - glaub...@debian.org `. `' Freie Universitaet Berlin - glaub...@physik.fu-berlin.de `-GPG: 62FF 8A75 84E0 2956 9546 0006 7426 3B37 F5B5 F913 -BEGIN PGP SIGNATURE- Version: GnuPG v1 iQIcBAEBCAAGBQJUu646AAoJEHQmOzf1tfkT7V4P/R13gZfztFdJhC2t7k5naDAh IcS5dwdeilCqRHEGm0Su5eGV7d6taZASplcKahDgw14VlQ/7tpSlMNQU2AYj8IKo bQ8xJfjmwznPOE3U/4p/dH2whfQWXowLoTKIO/Ayd06N/swP2kfMvwQMbVlxfbm6 fy5BmDry7NQQO39cCfIA1GPo4Eme1VHLaG/mRRDvuXWaujX/CFA9aFdiiZ2ZRQjp achH6zIb/9TdflWVNdMbadusUaZZgkin7p3Ky4jC0kk9pWtcWRR4zZdBGoKFrr3N HsdPVJScNWZeaaH7G//3L9WNgITQHC+gjoxuBrVN4NuVU5TIoHitsdhQGdJ96wJZ TENKenPiCQxwwLwljSjJ6lV+V1B7YT1nOpOBwK5jePzqIUL3ymejigwPXNQqlwev LK4I2tGMWDyh1VwZz0lwmRLh+Nu1NdPFzlu6981OAWOO8rSpcxzGTp5ipNPPY3VY j2MC0nibwx74DJYHzgDGCUdGN5lvDe0qNtwkqyKgnKCjsVdNHKZVEynFOfdmPSLz 2YfY8PZFRgmb5/Fb59990mvfEkY+No4o67yZP6k9jBcfAY7E/jTFjpzKQQjYdkhB q3hKl2M5fcvSKMCMrDWSOPEbC4By0arYvsDVVUecTvgecP/TGeBiJpPLVY9gLSAx JlAltcZjGayAdPYLgwFV =M5g3 -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: https://lists.debian.org/54bbae3b.8020...@physik.fu-berlin.de
Bug#775611: [sh]: FTBFS due to unknown compiler option '-m32'
Package: linux Version: 3.16.7-ckt4-1 Severity: normal Tags: patch Hi! The kernel package currently fails to build from source on sh4 since the build scripts try to pass the '-m32' compiler option on gcc which is not available with gcc on sh4 (also according to the manpage). Selecting HAVE_C_RECORDMCOUNT in arch/sh/Kconfig (see attached patch by Ben Hutchings) fixes the issues. However, I also suggest removing the line $cc .= -m32; for sh compiler options in scripts/ recordmcount.pl. Thanks! Adrian diff --git a/arch/sh/Kconfig b/arch/sh/Kconfig index 0f09f52..b2c9904 100644 --- a/arch/sh/Kconfig +++ b/arch/sh/Kconfig @@ -44,6 +44,7 @@ config SUPERH select OLD_SIGSUSPEND select OLD_SIGACTION select HAVE_ARCH_AUDITSYSCALL + select HAVE_C_RECORDMCOUNT help The SuperH is a RISC processor targeted for use in embedded systems and consumer electronics; it was also used in the Sega Dreamcast
Bug#748398: Bug has returned as CONFIG_FB_RADEON=y is set again
-BEGIN PGP SIGNED MESSAGE- Hash: SHA256 Hi Ben! Here are my test results: Kernels tested: * Linux 3.16.7-ck2 and Linux 3.18.0. Hardware tested: * Apple Mac Mini G4 (Radeon 9200) * Apple Powerbook G4 (Radeon 9600 PRO Turbo) * Apple iBook G3 (Rage Mobility 128 AGP) Results before changes: * Graphics broken on Apple Mac Mini G4, both kernels, out-of-the-box, can be fixed by appending video=radeonfb:off. * Graphics broken on Apple PowerBook G4, both kernels, out-of-the-box, can be fixed by appending video=radeonfb:off. * Graphics work on Apple iBook G3, both kernels, out-of-the-box. Changes: * CONFIG_FB_RADEON=y was changed to CONFIG_FB_RADEON=m. Results: * Graphics work on Apple Mac Mini G4, both kernels, out-of-the-box, no additional kernel parameters required. * Graphics work on Apple PowerBook G4, both kernels, out-of-the-box, no additional kernel parameters required. * Graphics work on Apple iBook G3, both kernels, out-of-the-box. Remarks: * Backlight dimming control works on both laptops in this configuration. Brightness can be dimmed from 0% to 100% smoothly. No other side effects observed, graphics and display controls on both laptops and the Mac Mini work as expected. Conclusion: * Please set CONFIG_FB_RADEON=m on powerpc32. Adrian - -- .''`. John Paul Adrian Glaubitz : :' : Debian Developer - glaub...@debian.org `. `' Freie Universitaet Berlin - glaub...@physik.fu-berlin.de `-GPG: 62FF 8A75 84E0 2956 9546 0006 7426 3B37 F5B5 F913 -BEGIN PGP SIGNATURE- Version: GnuPG v1 iQIcBAEBCAAGBQJUtl07AAoJEHQmOzf1tfkT/CcQAK6ZQk6ITTqWqUiNhullIxXc kBqIpiGQE2UktPYbOGAtnJPb+hHypYEywei/JeCdkPSHPKYhN0SpLv3iggP4HFeL n0MKoRv3g6rQ1D5Kxysd3N8cfwKEnYvG6mjt9sP3OBmn6Z1q74+NaSfRlqWn7fqH JUsBfgRlTeqvn5SvCWG4rQMV3Kuko/McH94+9xm5M/pNs5BWNSr4CKHyZiBSIMjI BwsmHCjFpg7zKA/AES8JFPBwAJcYNSmX8ByPOcc/WaumrdB239aV9OadwNcxGVWw lBGuIcPGtxdbSS4PQdcL4aetQlKxkh9D4ka1qUS0TGvw5664gyCgjg4nPQrwPnyu veqP8igIn5eNzGauwcJ+LXfSCxaE1rNrgqoVolP/USrPosBageo7K3RSSuYPVueH HF0+BPnWmH2ZHgTOv+MV2A2ZUsuuNpxjEZPFJkSdcc99x7kKfVOQcpO3QKWhKIlg m8ExQOI23xOOgNe7HuyxH/kRHtdKouyI3n4i2/n7UcpR21q9B5yKCpDOpnjwfn7h BG8mtknkCChUCzI9ZgmMQnAHAZBGuN/a4kBM7pvWuNYP1bU73MCLZ4J+8lgw/80z mAWHtSPJ3XJL86DPL5zO7doTizet50EPcuLEMUpf77LUks7+AwUAaMAmr5ndaRCG W0P5iE7RkpcN++eax1CM =jITB -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: https://lists.debian.org/54b65d3b.6070...@physik.fu-berlin.de
Bug#748398: Bug has returned as CONFIG_FB_RADEON=y is set again
Hello Vladimir! On 01/04/2015 08:03 PM, Vladimir Berezenko wrote: That is still better than having no display if the backlight is not correctly controlled. I confirm that backlight is not controlled correctly. Tried kms on powerbook 5,8. With video=radeonfb:off the only thing after X loaded is a black screen. Thanks for the heads-up! Could you tell us what kernel version you used and what the version of the X.org driver was (Debian package versions)? Out of curiosity, what X.org driver are you using? Assuming you are using Debian testing with a 3.16 kernel and 7.5.0 radeon driver, you won't be able to use the radeon driver anymore but just the generic, low-performance fbdev driver. I will hopefully be able to test some Powerbooks myself this week. Adrian -- .''`. John Paul Adrian Glaubitz : :' : Debian Developer - glaub...@debian.org `. `' Freie Universitaet Berlin - glaub...@physik.fu-berlin.de `-GPG: 62FF 8A75 84E0 2956 9546 0006 7426 3B37 F5B5 F913 -- 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/54a99384.1050...@physik.fu-berlin.de
Bug#748398: Bug has returned as CONFIG_FB_RADEON=y is set again
Control: unarchive -1 Control: reopen -1 Hello Ben! I just did a dist-upgrade which also upgraded the kernel. After rebooting the machine, X was still broken as radeonfb was loaded again and blocked the radeon module from functioning properly. Since the radeonfb driver is compiled into the kernel, there is no easy way of blacklisting it except for the boot command line. It seems your changes did not actually arrive in the kernel package: root@test-adrian1:/boot grep CONFIG_FB_RADEON= config-3.16* config-3.16.0-4-powerpc:CONFIG_FB_RADEON=y config-3.16-3-powerpc:CONFIG_FB_RADEON=y root@test-adrian1:/boot Is this a mistake? It's a pretty showstopper because it forces any installation of Debian on a PowerMac with a Radeon card to use the fbdev driver by default which uses a very low colordepth and has a bad performance. Adrian -- .''`. John Paul Adrian Glaubitz : :' : Debian Developer - glaub...@debian.org `. `' Freie Universitaet Berlin - glaub...@physik.fu-berlin.de `-GPG: 62FF 8A75 84E0 2956 9546 0006 7426 3B37 F5B5 F913 -- 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/54985637.70...@physik.fu-berlin.de
Bug#748398: Bug has returned as CONFIG_FB_RADEON=y is set again
-BEGIN PGP SIGNED MESSAGE- Hash: SHA256 On 12/23/2014 02:48 AM, Ben Hutchings wrote: This change caused a regression for some other 32-bit PowerMacs the last time we tried it (#614221). Therefore I limited it to 64-bit PowerPC configurations. Thanks for the hint! Interestingly, the linked bug report mentions that the bug showed on the Mac Mini G4 model as well [1] which is the exact model which I am testing on (G4 CPU, Radeon 9200 graphics). Also, as far as I know, the iBook G4 that you tested as well as my Mac Mini G4 share exactly the same hardware, minus the display. So I am quite confident the results should be the same. I am not going to make any further changes to this, until someone can show a solution that will not reintroduce that regression. Alright, which hardware configurations do you want me to test? As I said during DebConf, I might be able to lend some G3/G4 Macs from people at my department and run some tests on them. In any case, we need to be able to use the radeon KMS driver as Radeon X.Org driver that ships with Jessie does no longer support UMS, so anyone using the 32-bit kernel on a PowerPC will have poor graphics performance either way. I will try to get into touch with the people from the #614221 bug report. They should be able to test whether the regression still exists by simply adding video=radeonfb:off on a testing/sid system. Adrian [1] https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=614221#39 - -- .''`. John Paul Adrian Glaubitz : :' : Debian Developer - glaub...@debian.org `. `' Freie Universitaet Berlin - glaub...@physik.fu-berlin.de `-GPG: 62FF 8A75 84E0 2956 9546 0006 7426 3B37 F5B5 F913 -BEGIN PGP SIGNATURE- Version: GnuPG v1 iQIcBAEBCAAGBQJUmNJNAAoJEHQmOzf1tfkT4JcP/0Ws4+rUfnFn/grdX4TrqLkt Eh18hssDnsmmqbv1CtBNHJ7XbIhCrUvxFk/8trKZwKF2cO5x7l6M8AB6SYoVxBPi xV3aLtzZMGLEu76a6a7QA7syXoFJ+V1pnWDydTlWnaL+2EyxeEVMHwe7U+Gerl+m HIPIqLn4/ICoxDTFEY+dPc6gGC3s/lSUV/YegQs5+Uh8q/hj61I0qLLMPfveTUDO DR6AzemsyG2nsr1yMUVrL6i3sXTppkXG2Mdik1DCONvfC+zoAnvAF8d8NffNioz2 aa5eQpvX9ShSrQUKhjFF5jLOBMx5iEJM1U9d1ACyIS2KjtpbwIFNWkSKIxVv2Y+Z F3Ch7jj2sWTa/M/E+3Li7/kNgN/6tUzfkg5TIDuiCdB74dfF528QHxwv7JdzysB+ P5z6RWTXbo4wESCTe2/HqT4/WvEGXx1ivPnGrKOWLAmKF0z9IKUUYzyfL0ThZowq mDxRIZwjtUPQ/lBL9XIpYqIp34CnBk0HhGf9pSkV1FKJV/MG8zD/UMCka+Eszc6d Kxf8s1JX34/forFOVtdXpR/YM9loPfb5i4CC2XHR9BdwC1Z8q2eMBMXndeSEXMjQ xgsmYJMMODNFD8unErAXp2h0fh7YSVlp+uc4wB8/VgAXCYM43ZIKw6WyC0R8bVQ+ yn3NW9kfyrGSu6C6khii =F7mk -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: https://lists.debian.org/5498d24d.8070...@physik.fu-berlin.de
Bug#748398: Bug has returned as CONFIG_FB_RADEON=y is set again
-BEGIN PGP SIGNED MESSAGE- Hash: SHA256 On 12/23/2014 03:24 AM, John Paul Adrian Glaubitz wrote: On 12/23/2014 02:48 AM, Ben Hutchings wrote: This change caused a regression for some other 32-bit PowerMacs the last time we tried it (#614221). Therefore I limited it to 64-bit PowerPC configurations. Thanks for the hint! Interestingly, the linked bug report mentions that the bug showed on the Mac Mini G4 model as well [1] which is the exact model which I am testing on (G4 CPU, Radeon 9200 graphics). Oh, and to conclude: According to the linked bug report, the problem arose on the exact same hardware that I am using but no longer occurs for me. My Mac Mini G4 works absolutely fine with CONFIG_FB_RADEON=m and using the radeon module. So, my suspicion is that the bug has actually been fixed upstream. However, as I said before, I am willing to try to borrow any particular PPC Mac and test for the regression. Adrian - -- .''`. John Paul Adrian Glaubitz : :' : Debian Developer - glaub...@debian.org `. `' Freie Universitaet Berlin - glaub...@physik.fu-berlin.de `-GPG: 62FF 8A75 84E0 2956 9546 0006 7426 3B37 F5B5 F913 -BEGIN PGP SIGNATURE- Version: GnuPG v1 iQIcBAEBCAAGBQJUmNPCAAoJEHQmOzf1tfkTJesP/i7DmxFxIhZVtt2BImiAW9m1 /hiBiPPHF47tfqykpG9NlT1PhMVwOdcW9o00NFcZ05tXDVOxxXF+Jp4TEgfkYt5t 2SOgLoHax5lTVqBy8XJ1FR7rmjcbJEgk/cj6UXs6XQhIiWIeUfnotveKLYPDTiOQ KFEmtvKlyd7JGWcE4uUhEuUzCFxLtlTRIAZlusBkbPbXGakC854CRJCo94XTeNzJ QDe1Oj3YM94xtJlkXY2nvh8Uh6NirtfDxwATaHfZwhBlukzJ56DT1KentVu5j2o6 EJDd/b9/uFqCqFg55F1fMGWo3as3B5awRt/IJcBNCh3n9ch0mlugMotvdU4aKjIk ANUAx+e8ogG/8kg+drrGp4Wab4sBSjZhra/bLHU+o1Lzj98UKF2J1vVOTu9127uT cnPFogjJLjCgyRKy/WyU4w4IOvcrqSoC2FDoqO5vG7ZT2+9hYfyWc5kkt4up9TYp 1DPNFjpj3Ymmv1EgS4iExEXbuRQK+AYQPkpBwWhOGTyEZ1HQHBjSg7KQCO4grBRS 4GlfkLEfB6n9b14oJg5pt6kl5q7e03XxZV3byKHkjoTvp4WFnCS49G2p0aUTvqcZ u5G0wK4sbVPJytKPQN3WqscJj0IcUN15ajU5/qHQvtzVguzCqUf/qz9TKdmE68qz YRYfFWoliW7+OKHmQsVl =8UML -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: https://lists.debian.org/5498d3c2.60...@physik.fu-berlin.de
Bug#772602: [sh4]: Please use default compiler instead of gcc-4.7
On 12/09/2014 02:42 AM, John Paul Adrian Glaubitz wrote: On 12/09/2014 02:05 AM, maximilian attems wrote: the compiler change better be boot tested, was it? Well, the kernel package doesn't currently build on sh4 because gcc-4.7 was built with the m4-nofpu configuration missing [1]. FYI, the latest upload of the Linux kernel package still FTBFS on sh4 and it has been so for over two years now [1]. Changing the default compiler to gcc-4.8 which has the m4-nofpu configuration enabled will fix at least the current reason for the kernel package to FTBFS as this configuration is not available on gcc-4.7. Adrian [1] http://buildd.debian-ports.org/status/logs.php?pkg=linuxarch=sh4 -- .''`. John Paul Adrian Glaubitz : :' : Debian Developer - glaub...@debian.org `. `' Freie Universitaet Berlin - glaub...@physik.fu-berlin.de `-GPG: 62FF 8A75 84E0 2956 9546 0006 7426 3B37 F5B5 F913 -- 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/548c1fe7.7010...@physik.fu-berlin.de
Bug#772602: [sh4]: Please use default compiler instead of gcc-4.7
Package: linux Version: 3.16.7-2 Severity: normal Hello! On sh4, the kernel package is still built with gcc-4.7 by default since both gcc-4.8 and gcc-4.9 were not built on sh4 until recently. This has now been resolved and both gcc-4.8 and gcc-4.9 are now readily available on sh4 to build the kernel. I assume it should just be necessary to drop the compiler statement in /debian/ config/sh4/defines. It would be nice to have this fixed for the next upload. Thanks! Adrian = buildd@yamato:~/linux-3.16.7/debian/config/sh4$ grep gcc * defines:compiler: gcc-4.7 buildd@yamato:~/linux-3.16.7/debian/config/sh4$ apt-cache policy gcc-4.8 gcc-4.8: Installed: 4.8.3-8 Candidate: 4.8.3-13 Version table: 4.8.3-13 0 500 http://ftp.debian-ports.org/debian/ unstable/main sh4 Packages *** 4.8.3-8 0 100 /var/lib/dpkg/status buildd@yamato:~/linux-3.16.7/debian/config/sh4$ apt-cache policy gcc-4.9 gcc-4.9: Installed: 4.9.1-16 Candidate: 4.9.1-16 Version table: *** 4.9.1-16 0 500 http://ftp.debian-ports.org/debian/ unstable/main sh4 Packages 100 /var/lib/dpkg/status buildd@yamato:~/linux-3.16.7/debian/config/sh4$ -- 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/20141209004442.15934.23307.report...@zlogin2.physik.fu-berlin.de
Bug#772602: [sh4]: Please use default compiler instead of gcc-4.7
On 12/09/2014 02:05 AM, maximilian attems wrote: the compiler change better be boot tested, was it? Well, the kernel package doesn't currently build on sh4 because gcc-4.7 was built with the m4-nofpu configuration missing [1]. So, I assume it's better to have an untested kernel than no kernel at all, isn't it? I will thoroughly test the kernel package once the builds were actually able to build it :). Adrian [1] http://buildd.debian-ports.org/status/fetch.php?pkg=linuxarch=sh4ver=3.16.7-2%2Bb1stamp=1417850239 -- .''`. John Paul Adrian Glaubitz : :' : Debian Developer - glaub...@debian.org `. `' Freie Universitaet Berlin - glaub...@physik.fu-berlin.de `-GPG: 62FF 8A75 84E0 2956 9546 0006 7426 3B37 F5B5 F913 -- 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/54865380.3060...@physik.fu-berlin.de
Bug#763614: m68k machines not coming up after last update
On Thu, Oct 02, 2014 at 11:11:19AM +, Thorsten Glaser wrote: #763614 causes our machines to no longer boot, since they usually at most use klibc-utils to get small ramdisks. AIUI, the “fix” is to install busybox or busybox-static. This is not enough, you have to run “update-initramfs -u” manually afterwards. Then, copy out the initrd to the host OS filesystem (VM host for ARAnyM; AmigaOS, TOS, or MacOS otherwise). A reboot with the newly generated initrd works for my VMs. Seems to be the issue that I stumbled into as well, thanks for digging up a solution to the problem! I will test whether just installing busybox, busybox-static and calling update-initramfs will fix the issue for me and report back. SCNR but to note that mksh has a realpath builtin and compiles cleanly with klibc. Yes, but unfortunately, most people agreed on using bash and often you have no other choice but to use it. I'd also rather use zsh. Adrian -- .''`. John Paul Adrian Glaubitz : :' : Debian Developer - glaub...@debian.org `. `' Freie Universitaet Berlin - glaub...@physik.fu-berlin.de `-GPG: 62FF 8A75 84E0 2956 9546 0006 7426 3B37 F5B5 F913 -- 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/20141002115730.ga16...@physik.fu-berlin.de
Re: I/O schedulers for m68k
-BEGIN PGP SIGNED MESSAGE- Hash: SHA256 On 07/11/2014 05:15 PM, Ben Hutchings wrote: I think this is a mistake and that cfq should be reverted to built-in so it can be the default, as on other architectures. Any objection to me doing that? If that means a speed up in the end, I'm all for it. Adrian - -- .''`. John Paul Adrian Glaubitz : :' : Debian Developer - glaub...@debian.org `. `' Freie Universitaet Berlin - glaub...@physik.fu-berlin.de `-GPG: 62FF 8A75 84E0 2956 9546 0006 7426 3B37 F5B5 F913 -BEGIN PGP SIGNATURE- Version: GnuPG v1 Comment: Using GnuPG with Icedove - http://www.enigmail.net/ iQIcBAEBCAAGBQJTwAXEAAoJEHQmOzf1tfkTA8sP/j9QiVcDMf2snoh29sf+MPsj fYJHtt0Q9o50P4kupaxdt+XploW7qxYB5hYVgcAXhZMnIq+gvTqfB0dtEgGiXjJg h1A7SRXs60RG237i7ok6YrsXo3ND2vZsZjDwWMSj+PmewQIwSC6WyvdRNGKe7pND JGzPbx/QWbcZxiL8Kjau4BH92IJEbeYMMG6qyIA1qoHGTeUnwTpd4RT8255oYg2A UitiAUfw9JHib7ZbRyinT/HiA2zxYvNc8GWeu14LtEQFzRJjVikOdiZ4r1aEpiGI Em23q529HknPZTqRQf6Glrbu+KopyMgvEw6+PhOZtyWW4I9p7/Pt2N3B/sJwrHD/ bKi3RrS6wjgUVXyP7+H06uhLUCYcefUM3pnupJQllkZTrYxl4ewym2ooIPQ+NT2J LdQTNCmLLvrClQS+4HF+XgMiZFKMGLIGC0Ya+3gAjKQYXq2guraFrplrAebfV04Z PZazrBL6TsEr4pKlviVJtNmSEa7Em1MBNqqNmr8OJtXY69AtBaddJkUSsX3CnRng AWb5zQrzSJQnfyvBF0+G1xnZJeDsDBx9fbQjX2WYhtJbvb//juaiBdkCYI0XvtAb fcAKrMzKX3DR1ScU8BvTmffxPNUj54AeeVrRtmGbPUNZA0WW4jzWK06O/Z9uXWiq BiDJpOd8bk1y6XXuVdXN =f5R3 -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: https://lists.debian.org/53c005c4.20...@physik.fu-berlin.de
Bug#748398: linux: Please disable CONFIG_DRM_RADEON_UMS on powerpc
control: tags -1 patch control: title -1 linux: Please disable CONFIG_DRM_RADEON_UMS on powerpc On 06/29/2014 02:19 PM, John Paul Adrian Glaubitz wrote: I will provide a proposed diff for the kernel configuration on powerpc later. Suggested patch attached which aligns the framebuffer configuration with the other architectures, making most framebuffer drivers be compiled as modules. This fixes the problem with the X.Org Radeon driver (xserver-xorg-video- radeon) not working on PowerPC Macs. I'd be glad if this patch could be applied for the next upload so people won't need to build their own kernels when using these machines. I generated the patch using the current Linux 3.15 kernel package from experimental, but the kernel configuration for framebuffer devices should be the same for 3.14. Cheers, Adrian -- .''`. John Paul Adrian Glaubitz : :' : Debian Developer - glaub...@debian.org `. `' Freie Universitaet Berlin - glaub...@physik.fu-berlin.de `-GPG: 62FF 8A75 84E0 2956 9546 0006 7426 3B37 F5B5 F913 --- config.org 2014-05-03 10:46:13.0 +0200 +++ config 2014-07-07 22:02:55.378040388 +0200 @@ -816,37 +816,42 @@ CONFIG_FB_MODE_HELPERS=y CONFIG_FB_TILEBLITTING=y CONFIG_FB_CIRRUS=m -# CONFIG_FB_PM2 is not set -# CONFIG_FB_CYBER2000 is not set +CONFIG_FB_PM2=m +CONFIG_FB_PM2_FIFO_DISCONNECT=y +CONFIG_FB_CYBER2000=m +CONFIG_FB_CYBER2000_DDC=y CONFIG_FB_OF=y CONFIG_FB_CT65550=y -# CONFIG_FB_ASILIANT is not set +CONFIG_FB_ASILIANT=y +CONFIG_FB_IMSTT=y # CONFIG_FB_VGA16 is not set CONFIG_FB_S1D13XXX=m -CONFIG_FB_MATROX=y +CONFIG_FB_MATROX=m CONFIG_FB_MATROX_MILLENIUM=y CONFIG_FB_MATROX_MYSTIQUE=y CONFIG_FB_MATROX_G=y CONFIG_FB_MATROX_I2C=m CONFIG_FB_MATROX_MAVEN=m -CONFIG_FB_RADEON=y +CONFIG_FB_RADEON=m CONFIG_FB_RADEON_I2C=y +CONFIG_FB_RADEON_BACKLIGHT=y # CONFIG_FB_RADEON_DEBUG is not set -CONFIG_FB_ATY128=y -CONFIG_FB_ATY=y +CONFIG_FB_ATY128=m +CONFIG_FB_ATY128_BACKLIGHT=y +CONFIG_FB_ATY=m CONFIG_FB_ATY_CT=y CONFIG_FB_ATY_GENERIC_LCD=y CONFIG_FB_ATY_GX=y +CONFIG_FB_ATY_BACKLIGHT=y CONFIG_FB_SAVAGE=m CONFIG_FB_SAVAGE_I2C=y CONFIG_FB_SAVAGE_ACCEL=y -CONFIG_FB_SIS=y +CONFIG_FB_SIS=m CONFIG_FB_SIS_300=y CONFIG_FB_SIS_315=y CONFIG_FB_NEOMAGIC=m CONFIG_FB_KYRO=m -CONFIG_FB_3DFX=y -CONFIG_FB_VOODOO1=y +CONFIG_FB_VOODOO1=m CONFIG_FB_TRIDENT=m CONFIG_FB_IBM_GXT4500=m # CONFIG_FB_VIRTUAL is not set
