Re: Boot failure with ppc64 port on iMacs G5
Hi Michael, On Wed, 2024-03-06 at 12:57 +1100, Michael Ellerman wrote: > > Yep, the second, older image works as expected. However, the recent one > > does not > > and I have absolutely no clue why. > > I actually tested both, and both work, but then I cited the wrong one in > my email >_< > > So at least on qemu that newer kernel is OK: > > Preparing to boot Linux version 6.6.15-powerpc64 > (debian-ker...@lists.debian.org) (gcc-13 (Debian 13.2.0-13) 13.2.0, GNU ld > (GNU Binutils for Debian) 2.42) #1 SMP Debian 6.6.15-2 (2024-02-04) > ... > Booting Linux via __start() @ 0x0480 ... > Hello World ! > smp_core99_probe > smp_core99_bringup_done > Starting system log daemon: syslogd, klogd. Did you get around testing the images on real hardware? And can tell me what command line you used for booting with QEMU? Maybe that gives us a clue where the problem is. Users are still reporting boot lockups with kernel 6.6.x. Adrian -- .''`. John Paul Adrian Glaubitz : :' : Debian Developer `. `' Physicist `-GPG: 62FF 8A75 84E0 2956 9546 0006 7426 3B37 F5B5 F913
Re: Boot failure with ppc64 port on iMacs G5
Hi Michael, On Fri, 2024-03-01 at 12:56 +1100, Michael Ellerman wrote: > OK. > > That second iso boots OK for me in qemu. It boots grub and then the > kernel loads and shows: > > Loading ... > OF stdout device is: /pci@f000/mac-io@c/escc@13000/ch-a@13020 > Preparing to boot Linux version 6.3.0-1-powerpc64 > (debian-ker...@lists.debian.org) (gcc-12 (Debian 12.3.0-2) 12.3.0, GNU ld > (GNU Binutils for Debian) 2.40) #1 SMP Debian 6.3.7-1 (2023-06-12) > Detected machine type: 0400 > command line: BOOT_IMAGE=/install/vmlinux --- quiet > memory layout at init: > memory_limit : (16 MB aligned) > alloc_bottom : 05e7 > alloc_top: 3000 > alloc_top_hi : 8000 > rmo_top : 3000 > ram_top : 8000 > copying OF device tree... > Building dt strings... > Building dt structure... > Device tree strings 0x05e8 -> 0x05e80560 > Device tree struct 0x05e9 -> 0x05ea > Quiescing Open Firmware ... > Booting Linux via __start() @ 0x0200 ... > Hello World ! > smp_core99_probe > smp_core99_bringup_done > Starting system log daemon: syslogd, klogd. > > And eventually starts the installer. Yep, the second, older image works as expected. However, the recent one does not and I have absolutely no clue why. > That's using no VGA, so possibly there's something wrong with the video > setup on real hardware: > > $ qemu-system-ppc64 -nographic -vga none -M mac99,via=pmu -smp 1 -m 2G -nic > user -drive > file=$HOME/debian-12.0.0-ppc64-NETINST-1.2023-06-18.iso,format=raw,media=cdrom > -boot d > > I'll try and find time to test it on my actual G5 next week when I'm in > the office. The video issue can usually be worked around by disabling mode-setting or passing other kernel options related to the video card. That's not the main problem here though. The problem is that the newer image doesn't boot and currently I don't know why because installing the exact same kernel later from the package manager into an installed system works yields a bootable system with the latest kernel. The installer images are built from the same kernel package which makes the whole thing even more confusing. I'm using debian-cd to build the installation images: > https://salsa.debian.org/images-team/debian-cd/ Adrian -- .''`. John Paul Adrian Glaubitz : :' : Debian Developer `. `' Physicist `-GPG: 62FF 8A75 84E0 2956 9546 0006 7426 3B37 F5B5 F913
Re: Boot failure with ppc64 port on iMacs G5
Hi Michael, On Thu, 2024-02-29 at 17:42 +1100, Michael Ellerman wrote: > > There seems to be a regression in the kernel which affects PowerPC 970 > > machines, > > i.e. PowerMac G5 CPUs. The issue needs to be bisected and reported upstream. > > I have a quad G5 that is booting mainline happily. it's a really tricky problem because it seems to depend on how the kernel image is booted. It fails when trying to boot the kernel off the installation CD, i.e. like from here: > https://cdimage.debian.org/cdimage/ports/snapshots/2024-02-25/debian-12.0.0-ppc64-NETINST-1.iso but the kernel will boot fine when installing in an existing system which was installed with an installation CD which uses an older kernel. > https://cdimage.debian.org/cdimage/ports/snapshots/2023-06-18/debian-12.0.0-ppc64-NETINST-1.iso I have not really figured out yet what the problem is. Adrian -- .''`. John Paul Adrian Glaubitz : :' : Debian Developer `. `' Physicist `-GPG: 62FF 8A75 84E0 2956 9546 0006 7426 3B37 F5B5 F913
Re: Boot failure with ppc64 port on iMacs G5
Hello, On Tue, 2024-02-20 at 04:16 +0100, tuxayo wrote: > I tried snapshots/2024-01-31/debian-12.0.0-ppc64-NETINST-1.iso > > And was able to start booting from usb with: > boot usb0/disk@1:,\boot\grub\powerpc.elf > (typed in Open Firmware shell) > (usb0 is the top port) > > Grub worked, and then I tried default install (the 1st option) and it > started loading during like 2 minutes. > And then it got stuck with some superposition of the messages > smp_core99_probe > and > the stuff before > DO-QUIESCE finisedBooting Linux via __start() @ 0x0209 ... There seems to be a regression in the kernel which affects PowerPC 970 machines, i.e. PowerMac G5 CPUs. The issue needs to be bisected and reported upstream. If you have the time, I would really appreciate if you could test the various snapshots and let me know which kernel is the first to not work. I expect that the breakage occurred somewhere around kernel 6.3 or so. CC'ing Claudia Neumann who observed this bug before and can maybe share some additional information. > Full message of the two iMacs G5 ↓↓↓ > https://transfert.facil.services/r/Ksfq_2VM9_#tDATBcLXzB0zkAEaiqm9gfLfsaXliVJ13rQxKUHgUmA= > https://transfert.facil.services/r/Zs1h1jEtb2#jufjxv6+1DfHnO3TSfhmYD+teOvY46sGClHyz7SiXd4= Adrian -- .''`. John Paul Adrian Glaubitz : :' : Debian Developer `. `' Physicist `-GPG: 62FF 8A75 84E0 2956 9546 0006 7426 3B37 F5B5 F913
Re: [PATCH linux-next v3 10/14] sh, crash: wrap crash dumping code into crash related ifdefs
Hello Baoquan, On Wed, 2024-01-24 at 13:12 +0800, Baoquan He wrote: > Now crash codes under kernel/ folder has been split out from kexec > code, crash dumping can be separated from kexec reboot in config > items on SuperH with some adjustments. > > wrap up crash dumping codes with CONFIG_CRASH_DUMP ifdeffery, and > use IS_ENABLED(CONFIG_CRASH_RESERVE) check to decide if compiling > in the crashkernel reservation code. Comparing this to the patches, it seems you missed the first word "Here". Either amend that or write the word "wrap" capitalized. I would omit "Here" as it's not necessary and just start the sentence with "Wrap". Adrian -- .''`. John Paul Adrian Glaubitz : :' : Debian Developer `. `' Physicist `-GPG: 62FF 8A75 84E0 2956 9546 0006 7426 3B37 F5B5 F913
Re: Does anyone use Appletalk?
On Thu, 2023-11-02 at 13:13 +1100, Finn Thain wrote: > So I can't object to the removal of the localtalk code. But I do object to > the underhand manner in which it is done. I agree. I have the impression that the actual users of the affected code are never asked. It's usually a question posed on a mailing list where 99% of the affected users don't hang around. Naturally, there won't be any objections to the removal because affected users didn't receive a heads-up in the first place. Adrian -- .''`. John Paul Adrian Glaubitz : :' : Debian Developer `. `' Physicist `-GPG: 62FF 8A75 84E0 2956 9546 0006 7426 3B37 F5B5 F913
Re: [PATCH 00/10] Remove obsolete and orphaned wifi drivers
Hi Arnd! There is some non-x86 hardware like the Amiga that still uses PCMCIA-style networking cards on machines like the A600 and A1200. So, unless these drivers are actually causing problems, I would rather not see them go yet. Thanks, Adrian -- .''`. John Paul Adrian Glaubitz : :' : Debian Developer `. `' Physicist `-GPG: 62FF 8A75 84E0 2956 9546 0006 7426 3B37 F5B5 F913
Re: [PATCH v5 3/4] arch/*/io.h: remove ioremap_uc in some architectures
E_UNCACHED) > -#define ioremap_uc ioremap > > /* > * ioremap_cache - map bus memory into CPU space > diff --git a/arch/parisc/include/asm/io.h b/arch/parisc/include/asm/io.h > index 366537042465..48630c78714a 100644 > --- a/arch/parisc/include/asm/io.h > +++ b/arch/parisc/include/asm/io.h > @@ -132,8 +132,6 @@ static inline void gsc_writeq(unsigned long long val, > unsigned long addr) > > #define ioremap_wc(addr, size) \ > ioremap_prot((addr), (size), _PAGE_IOREMAP) > -#define ioremap_uc(addr, size) \ > - ioremap_prot((addr), (size), _PAGE_IOREMAP) > > #define pci_iounmap pci_iounmap > > diff --git a/arch/powerpc/include/asm/io.h b/arch/powerpc/include/asm/io.h > index 0732b743e099..21bd3e8bffce 100644 > --- a/arch/powerpc/include/asm/io.h > +++ b/arch/powerpc/include/asm/io.h > @@ -900,7 +900,6 @@ void __iomem *ioremap_wt(phys_addr_t address, unsigned > long size); > #endif > > void __iomem *ioremap_coherent(phys_addr_t address, unsigned long size); > -#define ioremap_uc(addr, size) ioremap((addr), (size)) > #define ioremap_cache(addr, size) \ > ioremap_prot((addr), (size), pgprot_val(PAGE_KERNEL)) > > diff --git a/arch/sh/include/asm/io.h b/arch/sh/include/asm/io.h > index f2f38e9d489a..790bea22c9b5 100644 > --- a/arch/sh/include/asm/io.h > +++ b/arch/sh/include/asm/io.h > @@ -302,8 +302,6 @@ unsigned long long poke_real_address_q(unsigned long long > addr, > ioremap_prot((addr), (size), pgprot_val(PAGE_KERNEL)) > #endif /* CONFIG_MMU */ > > -#define ioremap_uc ioremap > - > /* > * Convert a physical pointer to a virtual kernel pointer for /dev/mem > * access > diff --git a/arch/sparc/include/asm/io_64.h b/arch/sparc/include/asm/io_64.h > index 9303270b22f3..d8ee1442f303 100644 > --- a/arch/sparc/include/asm/io_64.h > +++ b/arch/sparc/include/asm/io_64.h > @@ -423,7 +423,6 @@ static inline void __iomem *ioremap(unsigned long offset, > unsigned long size) > return (void __iomem *)offset; > } > > -#define ioremap_uc(X,Y) ioremap((X),(Y)) > #define ioremap_wc(X,Y) ioremap((X),(Y)) > #define ioremap_wt(X,Y) ioremap((X),(Y)) > static inline void __iomem *ioremap_np(unsigned long offset, unsigned long > size) Acked-by: John Paul Adrian Glaubitz (SuperH) -- .''`. John Paul Adrian Glaubitz : :' : Debian Developer `. `' Physicist `-GPG: 62FF 8A75 84E0 2956 9546 0006 7426 3B37 F5B5 F913
Re: [PATCH v2 08/18] sh: Assign FB_MODE_IS_UNKNOWN to struct fb_videomode.flag
Hi Thomas!
On Thu, 2023-07-13 at 15:53 +0200, John Paul Adrian Glaubitz wrote:
> On Thu, 2023-07-13 at 14:58 +0200, Thomas Zimmermann wrote:
> > Assign FB_MODE_IS_UNKNOWN to sh7763fb_videomode.flag instead of
> > FBINFO_FLAG_DEFAULT. Both are 0, so the stored value does not change.
> >
> > FBINFO_FLAG_DEFAULT is a flag for a framebuffer in struct fb_info.
> > Flags for videomodes are prefixed with FB_MODE_.
> >
> > v2:
> > * assign FB_MODE_IS_UNKNOWN (Adrian)
> >
> > Signed-off-by: Thomas Zimmermann
> > Acked-by: Sam Ravnborg
> > Cc: Yoshinori Sato
> > Cc: Rich Felker
> > Cc: John Paul Adrian Glaubitz
> > ---
> > arch/sh/boards/mach-sh7763rdp/setup.c | 2 +-
> > 1 file changed, 1 insertion(+), 1 deletion(-)
> >
> > diff --git a/arch/sh/boards/mach-sh7763rdp/setup.c
> > b/arch/sh/boards/mach-sh7763rdp/setup.c
> > index 97e715e4e9b3..e25193001ea0 100644
> > --- a/arch/sh/boards/mach-sh7763rdp/setup.c
> > +++ b/arch/sh/boards/mach-sh7763rdp/setup.c
> > @@ -119,7 +119,7 @@ static struct fb_videomode sh7763fb_videomode = {
> > .vsync_len = 1,
> > .sync = 0,
> > .vmode = FB_VMODE_NONINTERLACED,
> > - .flag = FBINFO_FLAG_DEFAULT,
> > + .flag = FB_MODE_IS_UNKNOWN,
> > };
> >
> > static struct sh7760fb_platdata sh7763fb_def_pdata = {
>
> Acked-by: John Paul Adrian Glaubitz
Ah, just one tiny request: Could you change the subject to include the
board name, i.e.:
sh: mach-sh7763rdp: Assign FB_MODE_IS_UNKNOWN to struct
fb_videomode.flag
?
I wasn't paying close attention to the path of the file being changed when
I first looked at your patch. Sorry for that.
Adrian
--
.''`. John Paul Adrian Glaubitz
: :' : Debian Developer
`. `' Physicist
`-GPG: 62FF 8A75 84E0 2956 9546 0006 7426 3B37 F5B5 F913
Re: [PATCH v2 08/18] sh: Assign FB_MODE_IS_UNKNOWN to struct fb_videomode.flag
On Thu, 2023-07-13 at 14:58 +0200, Thomas Zimmermann wrote:
> Assign FB_MODE_IS_UNKNOWN to sh7763fb_videomode.flag instead of
> FBINFO_FLAG_DEFAULT. Both are 0, so the stored value does not change.
>
> FBINFO_FLAG_DEFAULT is a flag for a framebuffer in struct fb_info.
> Flags for videomodes are prefixed with FB_MODE_.
>
> v2:
> * assign FB_MODE_IS_UNKNOWN (Adrian)
>
> Signed-off-by: Thomas Zimmermann
> Acked-by: Sam Ravnborg
> Cc: Yoshinori Sato
> Cc: Rich Felker
> Cc: John Paul Adrian Glaubitz
> ---
> arch/sh/boards/mach-sh7763rdp/setup.c | 2 +-
> 1 file changed, 1 insertion(+), 1 deletion(-)
>
> diff --git a/arch/sh/boards/mach-sh7763rdp/setup.c
> b/arch/sh/boards/mach-sh7763rdp/setup.c
> index 97e715e4e9b3..e25193001ea0 100644
> --- a/arch/sh/boards/mach-sh7763rdp/setup.c
> +++ b/arch/sh/boards/mach-sh7763rdp/setup.c
> @@ -119,7 +119,7 @@ static struct fb_videomode sh7763fb_videomode = {
> .vsync_len = 1,
> .sync = 0,
> .vmode = FB_VMODE_NONINTERLACED,
> - .flag = FBINFO_FLAG_DEFAULT,
> + .flag = FB_MODE_IS_UNKNOWN,
> };
>
> static struct sh7760fb_platdata sh7763fb_def_pdata = {
Acked-by: John Paul Adrian Glaubitz
--
.''`. John Paul Adrian Glaubitz
: :' : Debian Developer
`. `' Physicist
`-GPG: 62FF 8A75 84E0 2956 9546 0006 7426 3B37 F5B5 F913
Re: [PATCH 08/17] arch/sh: Do not assign FBINFO_FLAG_DEFAULT to fb_videomode.flag
Hi! On Mon, 2023-07-10 at 16:04 +0200, Thomas Zimmermann wrote: > > > I won't argue with that, but the flag itself is wrong. > > > FBINFO_FLAG_DEFAULT is/was for struct fb_info.flags. You have struct > > > fb_videomode.flag. The valid flags for this field are at [1]. If > > > anything, the field could be initialized to FB_MODE_IS_UNKNOWN, which > > > has the same value. > > > > > > [1] https://elixir.bootlin.com/linux/latest/source/include/linux/fb.h#L681 > > > > FB_MODE_IS_UNKNOWN sounds very reasonable to me. Would you agree using that > > instead? > > Sure, I'll update the patch accordingly. Thanks! I'll ack the updated patch. Adrian -- .''`. John Paul Adrian Glaubitz : :' : Debian Developer `. `' Physicist `-GPG: 62FF 8A75 84E0 2956 9546 0006 7426 3B37 F5B5 F913
Re: [PATCH 08/17] arch/sh: Do not assign FBINFO_FLAG_DEFAULT to fb_videomode.flag
Hi Thomas! On Mon, 2023-07-10 at 15:52 +0200, Thomas Zimmermann wrote: > > I would argue that the current code is more readable that your proposed > > change. > > > > I agree that it's a no-op, but code is not just about functionality but also > > readability, isn't it? > > I won't argue with that, but the flag itself is wrong. > FBINFO_FLAG_DEFAULT is/was for struct fb_info.flags. You have struct > fb_videomode.flag. The valid flags for this field are at [1]. If > anything, the field could be initialized to FB_MODE_IS_UNKNOWN, which > has the same value. > > [1] https://elixir.bootlin.com/linux/latest/source/include/linux/fb.h#L681 FB_MODE_IS_UNKNOWN sounds very reasonable to me. Would you agree using that instead? > > > > Also, I prefer "sh:" as the architecture prefix, not "arch/sh:". > > Ok. Thanks. Adrian -- .''`. John Paul Adrian Glaubitz : :' : Debian Developer `. `' Physicist `-GPG: 62FF 8A75 84E0 2956 9546 0006 7426 3B37 F5B5 F913
Re: [PATCH 08/17] arch/sh: Do not assign FBINFO_FLAG_DEFAULT to fb_videomode.flag
Hi Thomas!
On Mon, 2023-07-10 at 14:50 +0200, Thomas Zimmermann wrote:
> FBINFO_FLAG_DEFAULT is a flag for a framebuffer in struct fb_info.
> Flags for videomodes are prefixed with FB_MODE_. FBINFO_FLAG_DEFAULT
> is 0 and the static declaration already clears the memory area of
> sh7763fb_videomode. So remove the assignment.
>
> Signed-off-by: Thomas Zimmermann
> Cc: Yoshinori Sato
> Cc: Rich Felker
> Cc: John Paul Adrian Glaubitz
> ---
> arch/sh/boards/mach-sh7763rdp/setup.c | 1 -
> 1 file changed, 1 deletion(-)
>
> diff --git a/arch/sh/boards/mach-sh7763rdp/setup.c
> b/arch/sh/boards/mach-sh7763rdp/setup.c
> index 97e715e4e9b3..345f2b76c85a 100644
> --- a/arch/sh/boards/mach-sh7763rdp/setup.c
> +++ b/arch/sh/boards/mach-sh7763rdp/setup.c
> @@ -119,7 +119,6 @@ static struct fb_videomode sh7763fb_videomode = {
> .vsync_len = 1,
> .sync = 0,
> .vmode = FB_VMODE_NONINTERLACED,
> - .flag = FBINFO_FLAG_DEFAULT,
> };
>
> static struct sh7760fb_platdata sh7763fb_def_pdata = {
I would argue that the current code is more readable that your proposed change.
I agree that it's a no-op, but code is not just about functionality but also
readability, isn't it?
Also, I prefer "sh:" as the architecture prefix, not "arch/sh:".
Thanks,
Adrian
--
.''`. John Paul Adrian Glaubitz
: :' : Debian Developer
`. `' Physicist
`-GPG: 62FF 8A75 84E0 2956 9546 0006 7426 3B37 F5B5 F913
Re: [FSL P50x0] [PASEMI] The Access to partitions on disks with an Amiga partition table doesn't work anymore after the block updates 2023-06-23
Hello Christian! On Thu, 2023-06-29 at 06:59 +0200, Christian Zigotzky wrote: > The access to partitions on disks with an Amiga partition table (via > the Rigid Disk Block RDB) doesn't work anymore on my Cyrus+ board with a > FSL P50x0 PowerPC SoC [1] and on my P.A. Semi Nemo board [2] after the > block updates 2023-06-23 [3]. > > parted -l > > Model: ATA ST2000DM001-9YN1 (scsi) > Disk /dev/sda: 2000GB > Sector size (logical/physical): 512B/4096B > Partition Table: amiga > Disk Flags: > > Number Start End Size File system Name Flags > 1 1057kB 123MB 122MB affs7 BDH0 hidden > 2 123MB 2274MB 2150MB DH0 boot > 3 2274MB 691GB 689GB DH2 > 4 691GB 1992GB 1301GB ext4 dhx boot What version of AmigaOS is that? > dmesg | grep -i sda > > [ 4.208905] sd 0:0:0:0: [sda] 3907029168 512-byte logical blocks: > (2.00 TB/1.82 TiB) > [ 4.253995] sd 0:0:0:0: [sda] 4096-byte physical blocks > [ 4.254826] sd 0:0:0:0: [sda] Write Protect is off > [ 4.300069] sd 0:0:0:0: [sda] Mode Sense: 00 3a 00 00 > [ 4.486476] sd 0:0:0:0: [sda] Write cache: enabled, read cache: > enabled, doesn't support DPO or FUA > [ 4.580507] sd 0:0:0:0: [sda] Preferred minimum I/O size 4096 bytes > [ 4.712624] Dev sda: unable to read partition block 4294967295 > [ 4.761532] sda: RDSK (512) sda1 (DOS^G)(res 2 spb 2) sda2 > (SFS^B)(res 2 spb 1) sda3 (SFS^B)(res 2 spb 2) sda4 ((res 2 spb 1) > unable to read partition table > [ 4.761892] sda: partition table beyond EOD, > [ 4.861681] Dev sda: unable to read partition block 4294967295 > [ 4.912094] sda: RDSK (512) sda1 (DOS^G)(res 2 spb 2) sda2 > (SFS^B)(res 2 spb 1) sda3 (SFS^B)(res 2 spb 2) sda4 ((res 2 spb 1) > unable to read partition table > [ 4.963387] sda: partition table beyond EOD, > [ 5.014769] sd 0:0:0:0: [sda] Attached SCSI disk Maybe the RDB is corrupted? Did you try on a freshly created RDB? > I created a patch for reverting the commit. [4] That can be done with just "git revert ". > The access works again with this patch: > > [ 0.00] Kernel command line: root=/dev/sda4 > [ 3.987717] sd 0:0:0:0: [sda] 3907029168 512-byte logical blocks: > (2.00 TB/1.82 TiB) > [ 4.031349] sd 0:0:0:0: [sda] 4096-byte physical blocks > [ 4.123773] sd 0:0:0:0: [sda] Write Protect is off > [ 4.168682] sd 0:0:0:0: [sda] Mode Sense: 00 3a 00 00 > [ 4.279304] sd 0:0:0:0: [sda] Write cache: enabled, read cache: > enabled, doesn't support DPO or FUA > [ 4.463508] sd 0:0:0:0: [sda] Preferred minimum I/O size 4096 bytes > [ 4.519477] sda: RDSK (512) sda1 (DOS^G)(res 2 spb 2) sda2 > (SFS^B)(res 2 spb 1) sda3 (SFS^B)(res 2 spb 2) sda4 ((res 2 spb 1) > [ 4.720896] sda: p4 size 18446744071956107760 extends beyond EOD, > [ 4.922550] sda: RDSK (512) sda1 (DOS^G)(res 2 spb 2) sda2 > (SFS^B)(res 2 spb 1) sda3 (SFS^B)(res 2 spb 2) sda4 ((res 2 spb 1) > [ 4.948655] sda: p4 size 18446744071956107760 extends beyond EOD, > truncated Looks like the old code is complaining about your partition table as well. > Could you please check your commit? Please also make sure that your RDB is not corrupted. Adrian -- .''`. John Paul Adrian Glaubitz : :' : Debian Developer `. `' Physicist `-GPG: 62FF 8A75 84E0 2956 9546 0006 7426 3B37 F5B5 F913
Re: [PATCH v2 13/13] sh/kexec: refactor for kernel/Kconfig.kexec
Hi Eric! On Mon, 2023-06-19 at 10:58 -0400, Eric DeVolder wrote: > The kexec and crash kernel options are provided in the common > kernel/Kconfig.kexec. Utilize the common options and provide > the ARCH_SUPPORTS_ and ARCH_SELECTS_ entries to recreate the > equivalent set of KEXEC and CRASH options. > > Signed-off-by: Eric DeVolder > --- > arch/sh/Kconfig | 46 -- > 1 file changed, 8 insertions(+), 38 deletions(-) > > diff --git a/arch/sh/Kconfig b/arch/sh/Kconfig > index 9652d367fc37..d52e0beed7e9 100644 > --- a/arch/sh/Kconfig > +++ b/arch/sh/Kconfig > @@ -546,44 +546,14 @@ menu "Kernel features" > > source "kernel/Kconfig.hz" > > -config KEXEC > - bool "kexec system call (EXPERIMENTAL)" > - depends on MMU > - select KEXEC_CORE > - help > - kexec is a system call that implements the ability to shutdown your > - current kernel, and to start another kernel. It is like a reboot > - but it is independent of the system firmware. And like a reboot > - you can start any kernel with it, not just Linux. > - > - The name comes from the similarity to the exec system call. > - > - It is an ongoing process to be certain the hardware in a machine > - is properly shutdown, so do not be surprised if this code does not > - initially work for you. As of this writing the exact hardware > - interface is strongly in flux, so no good recommendation can be > - made. > - > -config CRASH_DUMP > - bool "kernel crash dumps (EXPERIMENTAL)" > - depends on BROKEN_ON_SMP > - help > - Generate crash dump after being started by kexec. > - This should be normally only set in special crash dump kernels > - which are loaded in the main kernel with kexec-tools into > - a specially reserved region and then later executed after > - a crash by kdump/kexec. The crash dump kernel must be compiled > - to a memory address not used by the main kernel using > - PHYSICAL_START. > - > - For more details see Documentation/admin-guide/kdump/kdump.rst > - > -config KEXEC_JUMP > - bool "kexec jump (EXPERIMENTAL)" > - depends on KEXEC && HIBERNATION > - help > - Jump between original kernel and kexeced kernel and invoke > - code via KEXEC > +config ARCH_SUPPORTS_KEXEC > + def_bool MMU > + > +config ARCH_SUPPORTS_CRASH_DUMP > + def_bool BROKEN_ON_SMP > + > +config ARCH_SUPPORTS_KEXEC_JUMP > + def_bool y > > config PHYSICAL_START > hex "Physical address where the kernel is loaded" if (EXPERT || > CRASH_DUMP) Acked-by: John Paul Adrian Glaubitz -- .''`. John Paul Adrian Glaubitz : :' : Debian Developer `. `' Physicist `-GPG: 62FF 8A75 84E0 2956 9546 0006 7426 3B37 F5B5 F913
Re: [PATCH v3 30/34] sh: Convert pte_free_tlb() to use ptdescs
On Wed, 2023-05-31 at 14:30 -0700, Vishal Moola (Oracle) wrote:
> Part of the conversions to replace pgtable constructor/destructors with
> ptdesc equivalents. Also cleans up some spacing issues.
>
> Signed-off-by: Vishal Moola (Oracle)
> ---
> arch/sh/include/asm/pgalloc.h | 9 +
> 1 file changed, 5 insertions(+), 4 deletions(-)
>
> diff --git a/arch/sh/include/asm/pgalloc.h b/arch/sh/include/asm/pgalloc.h
> index a9e98233c4d4..5d8577ab1591 100644
> --- a/arch/sh/include/asm/pgalloc.h
> +++ b/arch/sh/include/asm/pgalloc.h
> @@ -2,6 +2,7 @@
> #ifndef __ASM_SH_PGALLOC_H
> #define __ASM_SH_PGALLOC_H
>
> +#include
> #include
>
> #define __HAVE_ARCH_PMD_ALLOC_ONE
> @@ -31,10 +32,10 @@ static inline void pmd_populate(struct mm_struct *mm,
> pmd_t *pmd,
> set_pmd(pmd, __pmd((unsigned long)page_address(pte)));
> }
>
> -#define __pte_free_tlb(tlb,pte,addr) \
> -do { \
> - pgtable_pte_page_dtor(pte); \
> - tlb_remove_page((tlb), (pte)); \
> +#define __pte_free_tlb(tlb, pte, addr) \
> +do { \
> + pagetable_pte_dtor(page_ptdesc(pte)); \
> + tlb_remove_page_ptdesc((tlb), (page_ptdesc(pte))); \
> } while (0)
>
> #endif /* __ASM_SH_PGALLOC_H */
Acked-by: John Paul Adrian Glaubitz
--
.''`. John Paul Adrian Glaubitz
: :' : Debian Developer
`. `' Physicist
`-GPG: 62FF 8A75 84E0 2956 9546 0006 7426 3B37 F5B5 F913
Re: [PATCH v3 30/34] sh: Convert pte_free_tlb() to use ptdescs
On Thu, 2023-06-01 at 09:42 +0200, Geert Uytterhoeven wrote:
> Hi Adrian,
>
> On Thu, Jun 1, 2023 at 9:28 AM John Paul Adrian Glaubitz
> wrote:
> > On Thu, 2023-06-01 at 09:20 +0200, Geert Uytterhoeven wrote:
> > > On Wed, May 31, 2023 at 11:33 PM Vishal Moola (Oracle)
> > > wrote:
> > > > Part of the conversions to replace pgtable constructor/destructors with
> > > > ptdesc equivalents. Also cleans up some spacing issues.
> > > >
> > > > Signed-off-by: Vishal Moola (Oracle)
> > >
> > > LGTM, so
> > > Reviewed-by: Geert Uytterhoeven
> >
> > I assume this series is supposed to go through some mm tree?
>
> I think so, so your Acked-by would be appreciated...
OK, I will have a look. Btw, can you have a look at the second series by
Artur ("SuperH DMAC fixes")? I haven't had the time for these yet, but
I will have time in the weekend.
Adrian
--
.''`. John Paul Adrian Glaubitz
: :' : Debian Developer
`. `' Physicist
`-GPG: 62FF 8A75 84E0 2956 9546 0006 7426 3B37 F5B5 F913
Re: [PATCH v3 30/34] sh: Convert pte_free_tlb() to use ptdescs
Hi Geert! On Thu, 2023-06-01 at 09:20 +0200, Geert Uytterhoeven wrote: > On Wed, May 31, 2023 at 11:33 PM Vishal Moola (Oracle) > wrote: > > Part of the conversions to replace pgtable constructor/destructors with > > ptdesc equivalents. Also cleans up some spacing issues. > > > > Signed-off-by: Vishal Moola (Oracle) > > LGTM, so > Reviewed-by: Geert Uytterhoeven I assume this series is supposed to go through some mm tree? Adrian -- .''`. John Paul Adrian Glaubitz : :' : Debian Developer `. `' Physicist `-GPG: 62FF 8A75 84E0 2956 9546 0006 7426 3B37 F5B5 F913
Re: [PATCH v2 30/34] sh: Convert pte_free_tlb() to use ptdescs
Hi Vishal!
On Mon, 2023-05-01 at 12:28 -0700, Vishal Moola (Oracle) wrote:
> Part of the conversions to replace pgtable constructor/destructors with
> ptdesc equivalents. Also cleans up some spacing issues.
>
> Signed-off-by: Vishal Moola (Oracle)
> ---
> arch/sh/include/asm/pgalloc.h | 9 +
> 1 file changed, 5 insertions(+), 4 deletions(-)
>
> diff --git a/arch/sh/include/asm/pgalloc.h b/arch/sh/include/asm/pgalloc.h
> index a9e98233c4d4..ce2ba99dbd84 100644
> --- a/arch/sh/include/asm/pgalloc.h
> +++ b/arch/sh/include/asm/pgalloc.h
> @@ -2,6 +2,7 @@
> #ifndef __ASM_SH_PGALLOC_H
> #define __ASM_SH_PGALLOC_H
>
> +#include
> #include
>
> #define __HAVE_ARCH_PMD_ALLOC_ONE
> @@ -31,10 +32,10 @@ static inline void pmd_populate(struct mm_struct *mm,
> pmd_t *pmd,
> set_pmd(pmd, __pmd((unsigned long)page_address(pte)));
> }
>
> -#define __pte_free_tlb(tlb,pte,addr) \
> -do { \
> - pgtable_pte_page_dtor(pte); \
> - tlb_remove_page((tlb), (pte)); \
> +#define __pte_free_tlb(tlb, pte, addr) \
> +do { \
> + ptdesc_pte_dtor(page_ptdesc(pte)); \
> + tlb_remove_page_ptdesc((tlb), (page_ptdesc(pte))); \
> } while (0)
>
> #endif /* __ASM_SH_PGALLOC_H */
Looking at the patch which introduces tlb_remove_page_ptdesc() [1], it seems
that
tlb_remove_page_ptdesc() already calls tlb_remove_page() with ptdesc_page(pt),
so
I'm not sure whether the above tlb_remove_page_ptdesc((tlb), (page_ptdesc(pte)))
is correct.
Shouldn't it just be tlb_remove_page_ptdesc((tlb), (pte))?
Thanks,
Adrian
> [1]
> https://lore.kernel.org/linux-mm/20230417205048.15870-5-vishal.mo...@gmail.com/
--
.''`. John Paul Adrian Glaubitz
: :' : Debian Developer
`. `' Physicist
`-GPG: 62FF 8A75 84E0 2956 9546 0006 7426 3B37 F5B5 F913
Re: [PATCH v3 16/19] arch/sh: Implement with generic helpers
On Mon, 2023-04-17 at 14:56 +0200, Thomas Zimmermann wrote:
> Replace the architecture's fbdev helpers with the generic
> ones from . No functional changes.
>
> v2:
> * use default implementation for fb_pgprotect() (Arnd)
>
> Signed-off-by: Thomas Zimmermann
> Cc: Yoshinori Sato
> Cc: Rich Felker
> Cc: John Paul Adrian Glaubitz
> ---
> arch/sh/include/asm/fb.h | 15 +--
> 1 file changed, 1 insertion(+), 14 deletions(-)
>
> diff --git a/arch/sh/include/asm/fb.h b/arch/sh/include/asm/fb.h
> index 9a0bca2686fd..19df13ee9ca7 100644
> --- a/arch/sh/include/asm/fb.h
> +++ b/arch/sh/include/asm/fb.h
> @@ -2,19 +2,6 @@
> #ifndef _ASM_FB_H_
> #define _ASM_FB_H_
>
> -#include
> -#include
> -#include
> -
> -static inline void fb_pgprotect(struct file *file, struct vm_area_struct
> *vma,
> - unsigned long off)
> -{
> - vma->vm_page_prot = pgprot_writecombine(vma->vm_page_prot);
> -}
> -
> -static inline int fb_is_primary_device(struct fb_info *info)
> -{
> - return 0;
> -}
> +#include
>
> #endif /* _ASM_FB_H_ */
Acked-by: John Paul Adrian Glaubitz
--
.''`. John Paul Adrian Glaubitz
: :' : Debian Developer
`. `' Physicist
`-GPG: 62FF 8A75 84E0 2956 9546 0006 7426 3B37 F5B5 F913
Re: [PATCH v3 16/19] arch/sh: Implement with generic helpers
Hi Thomas!
On Mon, 2023-04-17 at 16:06 +0200, Thomas Zimmermann wrote:
> Hi
>
> Am 17.04.23 um 15:02 schrieb John Paul Adrian Glaubitz:
> > Hi Thomas!
> >
> > On Mon, 2023-04-17 at 14:56 +0200, Thomas Zimmermann wrote:
> > > Replace the architecture's fbdev helpers with the generic
> > > ones from . No functional changes.
> > >
> > > v2:
> > > * use default implementation for fb_pgprotect() (Arnd)
> > >
> > > Signed-off-by: Thomas Zimmermann
> > > Cc: Yoshinori Sato
> > > Cc: Rich Felker
> > > Cc: John Paul Adrian Glaubitz
> > > ---
> > > arch/sh/include/asm/fb.h | 15 +--
> > > 1 file changed, 1 insertion(+), 14 deletions(-)
> > >
> > > diff --git a/arch/sh/include/asm/fb.h b/arch/sh/include/asm/fb.h
> > > index 9a0bca2686fd..19df13ee9ca7 100644
> > > --- a/arch/sh/include/asm/fb.h
> > > +++ b/arch/sh/include/asm/fb.h
> > > @@ -2,19 +2,6 @@
> > > #ifndef _ASM_FB_H_
> > > #define _ASM_FB_H_
> > >
> > > -#include
> > > -#include
> > > -#include
> > > -
> > > -static inline void fb_pgprotect(struct file *file, struct vm_area_struct
> > > *vma,
> > > - unsigned long off)
> > > -{
> > > - vma->vm_page_prot = pgprot_writecombine(vma->vm_page_prot);
> > > -}
> >
> > Looking at the macro in asm-generic/fb.h, fb_pgprotect() is being replaced
> > with
> > a no-op function. Is that intentional? Can you briefly explain the
> > background
> > for this change?
>
> Patch 01 of this patchset changes the generic fb_pgprotect() to set
> pgprot_writecombine(). So on SH, there should be no change at all.
>
Ah, I missed that, thanks for the explanation. Let me check and Ack your patch
then. I assume you will be taking this patch as part of the whole series through
your own tree?
Thanks,
Adrian
--
.''`. John Paul Adrian Glaubitz
: :' : Debian Developer
`. `' Physicist
`-GPG: 62FF 8A75 84E0 2956 9546 0006 7426 3B37 F5B5 F913
Re: [PATCH v3 16/19] arch/sh: Implement with generic helpers
Hi Thomas!
On Mon, 2023-04-17 at 14:56 +0200, Thomas Zimmermann wrote:
> Replace the architecture's fbdev helpers with the generic
> ones from . No functional changes.
>
> v2:
> * use default implementation for fb_pgprotect() (Arnd)
>
> Signed-off-by: Thomas Zimmermann
> Cc: Yoshinori Sato
> Cc: Rich Felker
> Cc: John Paul Adrian Glaubitz
> ---
> arch/sh/include/asm/fb.h | 15 +--
> 1 file changed, 1 insertion(+), 14 deletions(-)
>
> diff --git a/arch/sh/include/asm/fb.h b/arch/sh/include/asm/fb.h
> index 9a0bca2686fd..19df13ee9ca7 100644
> --- a/arch/sh/include/asm/fb.h
> +++ b/arch/sh/include/asm/fb.h
> @@ -2,19 +2,6 @@
> #ifndef _ASM_FB_H_
> #define _ASM_FB_H_
>
> -#include
> -#include
> -#include
> -
> -static inline void fb_pgprotect(struct file *file, struct vm_area_struct
> *vma,
> - unsigned long off)
> -{
> - vma->vm_page_prot = pgprot_writecombine(vma->vm_page_prot);
> -}
Looking at the macro in asm-generic/fb.h, fb_pgprotect() is being replaced with
a no-op function. Is that intentional? Can you briefly explain the background
for this change?
> -static inline int fb_is_primary_device(struct fb_info *info)
> -{
> - return 0;
> -}
> +#include
>
> #endif /* _ASM_FB_H_ */
Thanks,
Adrian
--
.''`. John Paul Adrian Glaubitz
: :' : Debian Developer
`. `' Physicist
`-GPG: 62FF 8A75 84E0 2956 9546 0006 7426 3B37 F5B5 F913
Re: [PATCH v3 10/24] sparc: Remove COMMAND_LINE_SIZE from uapi
On Tue, 2023-02-14 at 16:59 +0800, WANG Xuerui wrote: > On 2023/2/14 16:50, Sergey Shtylyov wrote: > > On 2/14/23 10:49 AM, Alexandre Ghiti wrote: > > > > > From: Palmer Dabbelt > > > > > > As far as I can tell this is not used by userspace and thus should not > > > be part of the user-visible API. > > > > > > Signed-off-by: Palmer Dabbelt > > > --- > > > arch/sparc/include/asm/setup.h | 6 +- > > > arch/sparc/include/uapi/asm/setup.h | 7 --- > > > 2 files changed, 5 insertions(+), 8 deletions(-) > > > > > > diff --git a/arch/sparc/include/asm/setup.h > > > b/arch/sparc/include/asm/setup.h > > > index 72205684e51e..d1384ed92547 100644 > > > --- a/arch/sparc/include/asm/setup.h > > > +++ b/arch/sparc/include/asm/setup.h > > > @@ -7,7 +7,11 @@ > > > > > > #include > > > > > > -#include > > > +#if defined(__sparc__) && defined(__arch64__) > > > > Mhm, I don't think these two can be #define'd simulaneously... > > I believe it's just a SPARC-ism [1] [2] that may look strange and be > easily confused for __aarch64__ (notice the extra 'a')... Yep, that's correct. On 64-bit Linux/SPARC, gcc/clang define __sparc__ AND __arch64__. Adrian -- .''`. John Paul Adrian Glaubitz : :' : Debian Developer `. `' Physicist `-GPG: 62FF 8A75 84E0 2956 9546 0006 7426 3B37 F5B5 F913
Re: Calculating array sizes in C - was: Re: Build regressions/improvements in v6.2-rc1
Hi! On 1/20/23 20:29, Michael Karcher wrote: Hello Adrian, Could you post a kernel patch for that? I would be happy to test it on my SH-7785CLR board. Also, I'm going to file a bug report against GCC. I filed the bug already. It's https://gcc.gnu.org/bugzilla/show_bug.cgi?id=108483. The diff is attached. It's published as CC0 in case anyone considers this trivial change copyrightable. This patch prevents this one specific warning from being upgraded to "error" even if you configure the kernel to use "-Werror". It still keeps it active as warning, though. I used the following variant and it fixes the issue for me: diff --git a/arch/sh/Makefile b/arch/sh/Makefile index 5c8776482530..11b22f7167d2 100644 --- a/arch/sh/Makefile +++ b/arch/sh/Makefile @@ -167,7 +167,7 @@ drivers-y += arch/sh/drivers/ cflags-y += $(foreach d, $(cpuincdir-y), -I $(srctree)/arch/sh/include/$(d)) \ $(foreach d, $(machdir-y), -I $(srctree)/arch/sh/include/$(d)) -KBUILD_CFLAGS += -pipe $(cflags-y) +KBUILD_CFLAGS += -pipe -Wno-error=sizeof-pointer-div $(cflags-y) KBUILD_CPPFLAGS+= $(cflags-y) KBUILD_AFLAGS += $(cflags-y) If you agree, can you post a patch to LKML so we can unbreak the SH build for CONFIG_WERROR? Thanks, Adrian -- .''`. John Paul Adrian Glaubitz : :' : Debian Developer `. `' Physicist `-GPG: 62FF 8A75 84E0 2956 9546 0006 7426 3B37 F5B5 F913
Re: Calculating array sizes in C - was: Re: Build regressions/improvements in v6.2-rc1
Hi Michael! On 1/19/23 23:11, Michael.Karcher wrote: I suggest to file a bug against gcc complaining about a "spurious warning", and using "-Werror -Wno-error-sizeof-pointer-div" until gcc is adapted to not emit the warning about the pointer division if the result is not used. Could you post a kernel patch for that? I would be happy to test it on my SH-7785CLR board. Also, I'm going to file a bug report against GCC. Adrian -- .''`. John Paul Adrian Glaubitz : :' : Debian Developer `. `' Physicist `-GPG: 62FF 8A75 84E0 2956 9546 0006 7426 3B37 F5B5 F913
Re: Calculating array sizes in C - was: Re: Build regressions/improvements in v6.2-rc1
Hi! On 1/17/23 21:05, Geert Uytterhoeven wrote: Isn't this supposed to be caught by this check: a, __same_type(a, NULL) ? Yeah, but gcc thinks it is smarter than us... Probably it drops the test, assuming UB cannot happen. Hmm, sounds like a GGC bug to me then. Not sure how to fix this then. Adrian -- .''`. John Paul Adrian Glaubitz : :' : Debian Developer `. `' Physicist `-GPG: 62FF 8A75 84E0 2956 9546 0006 7426 3B37 F5B5 F913
Re: Calculating array sizes in C - was: Re: Build regressions/improvements in v6.2-rc1
Hi! On 1/17/23 18:01, Geert Uytterhoeven wrote: The issue is that some of the parameters are not arrays, but NULL. E.g.: arch/sh/kernel/cpu/sh2/setup-sh7619.c:static DECLARE_INTC_DESC(intc_desc, "sh7619", vectors, NULL, arch/sh/kernel/cpu/sh2/setup-sh7619.c- NULL, prio_registers, NULL); Isn't this supposed to be caught by this check: a, __same_type(a, NULL) ? Adrian -- .''`. John Paul Adrian Glaubitz : :' : Debian Developer `. `' Physicist `-GPG: 62FF 8A75 84E0 2956 9546 0006 7426 3B37 F5B5 F913
Calculating array sizes in C - was: Re: Build regressions/improvements in v6.2-rc1
Hi Geert!
On 1/6/23 16:17, Geert Uytterhoeven wrote:
I'm not seeing this one, but I am getting this one instead:
In file included from ./arch/sh/include/asm/hw_irq.h:6,
from ./include/linux/irq.h:596,
from ./include/asm-generic/hardirq.h:17,
from ./arch/sh/include/asm/hardirq.h:9,
from ./include/linux/hardirq.h:11,
from ./include/linux/interrupt.h:11,
from ./include/linux/serial_core.h:13,
from ./include/linux/serial_sci.h:6,
from arch/sh/kernel/cpu/sh2/setup-sh7619.c:11:
./include/linux/sh_intc.h:100:63: error: division 'sizeof (void *) / sizeof
(void)' does not compute the number of array elements
[-Werror=sizeof-pointer-div]
100 | #define _INTC_ARRAY(a) a, __same_type(a, NULL) ? 0 :
sizeof(a)/sizeof(*a)
| ^
./include/linux/sh_intc.h:105:31: note: in expansion of macro '_INTC_ARRAY'
105 | _INTC_ARRAY(vectors), _INTC_ARRAY(groups), \
| ^~~
The easiest fix for the latter is to disable CONFIG_WERROR.
Unfortunately I don't know a simple solution to get rid of the warning.
I did some research and it seems that what the macro _INT_ARRAY() does with
"sizeof(a)/sizeof(*a)"
is a commonly used way to calculate array sizes and the kernel has even its own
macro for that
called ARRAY_SIZE() which Linus asks people to use here [1].
So, I replaced _INTC_ARRAY() with ARRAY_SIZE() (see below), however the
kernel's own ARRAY_SIZE()
macro triggers the same compiler warning. I'm CC'ing Michael Karcher who has
more knowledge on
writing proper C code than me and maybe an idea how to fix this warning.
Thanks,
Adrian
[1] https://lkml.org/lkml/2015/9/3/428
diff --git a/include/linux/sh_intc.h b/include/linux/sh_intc.h
index c255273b0281..07a187686a84 100644
--- a/include/linux/sh_intc.h
+++ b/include/linux/sh_intc.h
@@ -97,14 +97,12 @@ struct intc_hw_desc {
unsigned int nr_subgroups;
};
-#define _INTC_ARRAY(a) a, __same_type(a, NULL) ? 0 : sizeof(a)/sizeof(*a)
-
#define INTC_HW_DESC(vectors, groups, mask_regs, \
prio_regs, sense_regs, ack_regs) \
{ \
- _INTC_ARRAY(vectors), _INTC_ARRAY(groups), \
- _INTC_ARRAY(mask_regs), _INTC_ARRAY(prio_regs), \
- _INTC_ARRAY(sense_regs), _INTC_ARRAY(ack_regs), \
+ ARRAY_SIZE(vectors), ARRAY_SIZE(groups),\
+ ARRAY_SIZE(mask_regs), ARRAY_SIZE(prio_regs), \
+ ARRAY_SIZE(sense_regs), ARRAY_SIZE(ack_regs), \
}
struct intc_desc {
--
.''`. John Paul Adrian Glaubitz
: :' : Debian Developer
`. `' Physicist
`-GPG: 62FF 8A75 84E0 2956 9546 0006 7426 3B37 F5B5 F913
Re: ia64 removal (was: Re: lockref scalability on x86-64 vs cpu_relax)
On 1/15/23 13:04, Sedat Dilek wrote: Exactly, Debian Popularity Contest was what I was looking for yesterday. Thanks Matthew. [1] says in Inst (204701): Name || Number || % == binutils-x86-64-linux-gnu || 101548 || 49.61% binutils-ia64-linux-gnu || 11 || 0.01% HELP: Inst. is the number of people who installed this package (sum of the four categories below) There may be more popular packages than binutils. ( binutils might tell something about development happening or not. ) Anyway, I am not a popcon expert and never participated in Debian's Popularity Contest. And that's the point, it's opt-in! Adrian -- .''`. John Paul Adrian Glaubitz : :' : Debian Developer `. `' Physicist `-GPG: 62FF 8A75 84E0 2956 9546 0006 7426 3B37 F5B5 F913
Re: ia64 removal (was: Re: lockref scalability on x86-64 vs cpu_relax)
On 1/15/23 01:27, Matthew Wilcox wrote: More useful perhaps is to look at https://popcon.debian.org/ There are three machines reporting popcon results. It's dead. It's an opt-in mechanism that reports 190,000 machines running Debian on x86_64. Do you think that there are only 190,000 servers world-wide running Debian? Adrian -- .''`. John Paul Adrian Glaubitz : :' : Debian Developer `. `' Physicist `-GPG: 62FF 8A75 84E0 2956 9546 0006 7426 3B37 F5B5 F913
Re: ia64 removal (was: Re: lockref scalability on x86-64 vs cpu_relax)
On 1/14/23 12:28, Sedat Dilek wrote: [ ... ] Best is to ask the Debian release-team or (if there exist) maintainers or responsibles for the IA64 port - which is an ***unofficial*** port. Here we go: https://lists.debian.org/debian-ia64/ Posting address: debian-i...@lists.debian.org Found via <https://lists.debian.org/completeindex.html> And the wiki lists Jason Duerstock, Jessica Clarke and me as maintainers: https://wiki.debian.org/Ports/ia64 Adrian -- .''`. John Paul Adrian Glaubitz : :' : Debian Developer `. `' Physicist `-GPG: 62FF 8A75 84E0 2956 9546 0006 7426 3B37 F5B5 F913
Re: ia64 removal (was: Re: lockref scalability on x86-64 vs cpu_relax)
On 1/14/23 12:24, Sedat Dilek wrote: Example #1: binutils packages Checking available binutils package for Debian/unstable IA64 (version: 2.39.90.20230110-1): https://packages.debian.org/sid/binutils <--- Clearly states IA64 as "unofficial port" And? https://packages.debian.org/sid/ia64/binutils/filelist Example #2: linux-image packages Cannot say what this means... https://packages.debian.org/search?arch=amd64=linux-image (AMD64 - matches) https://packages.debian.org/search?arch=ia64=linux-image (IA64 - no matches) https://packages.debian.org/search?arch=ia64=linux (IA64 - matches - but no linux-image which ships normally a bootable Linux-kernel) No, the package is called "linux-image-$ARCH-$FLAVOR". There is no "linux-image" package for amd64 either. Does that prove amd64 is dead? What you are looking for can be found here: http://ftp.ports.debian.org/debian-ports/pool-ia64/main/l/linux/ As stated I have no expertise in Debian whatever release for IA64 arch. Well, maybe let me answer the questions then since I am maintaining the port in Debian. Adrian -- .''`. John Paul Adrian Glaubitz : :' : Debian Developer `. `' Physicist `-GPG: 62FF 8A75 84E0 2956 9546 0006 7426 3B37 F5B5 F913
Re: ia64 removal (was: Re: lockref scalability on x86-64 vs cpu_relax)
Hi Ard! On 1/14/23 00:25, Ard Biesheuvel wrote: Thanks for reporting back. I (mis)read the debian ports page [3], which mentions Debian 7 as the highest Debian version that supports IA64, and so I assumed that support had been dropped from Debian. This page talks about officially supported ports. Debian Ports is an unofficial spin maintained by a number of Debian Developers and external developers that are volunteering to maintain these ports. However, if only a handful of people want to keep this port alive for reasons of nostalgia, it is obviously obsolete, and we should ask ourselves whether it is reasonable to expect Linux contributors to keep spending time on this. You could say this about a lot of hardware, can't you? Does the Debian ia64 port have any users? Or is the system that builds the packages the only one that consumes them? There is the popcon statistics. However, that is opt-on and the numbers are not really trustworthy. We are getting feedback from time to time from people using it. Is there any problem with the ia64 port at the moment that would justify removal? Adrian -- .''`. John Paul Adrian Glaubitz : :' : Debian Developer `. `' Physicist `-GPG: 62FF 8A75 84E0 2956 9546 0006 7426 3B37 F5B5 F913
Re: ia64 removal (was: Re: lockref scalability on x86-64 vs cpu_relax)
Hello Ard! Can I take that as an ack on [0]? The EFI subsystem has evolved substantially over the years, and there is really no way to do any IA64 testing beyond build testing, so from that perspective, dropping it entirely would be welcomed. ia64 is regularly tested in Debian and Gentoo [1][2]. Debian's ia64 porterbox yttrium runs a recent kernel without issues: root@yttrium:~# uname -a Linux yttrium 5.19.0-2-mckinley #1 SMP Debian 5.19.11-1 (2022-09-24) ia64 GNU/Linux root@yttrium:~# root@yttrium:~# journalctl -b|head -n10 Nov 14 14:46:10 yttrium kernel: Linux version 5.19.0-2-mckinley (debian-ker...@lists.debian.org) (gcc-11 (Debian 11.3.0-6) 11.3.0, GNU ld (GNU Binutils for Debian) 2.39) #1 SMP Debian 5.19.11-1 (2022-09-24) Nov 14 14:46:10 yttrium kernel: efi: EFI v2.10 by HP Nov 14 14:46:10 yttrium kernel: efi: SALsystab=0xdfdd63a18 ESI=0xdfdd63f18 ACPI 2.0=0x3d3c4014 HCDP=0xd8798 SMBIOS=0x3d368000 Nov 14 14:46:10 yttrium kernel: PCDP: v3 at 0xd8798 Nov 14 14:46:10 yttrium kernel: earlycon: uart8250 at I/O port 0x4000 (options '115200n8') Nov 14 14:46:10 yttrium kernel: printk: bootconsole [uart8250] enabled Nov 14 14:46:10 yttrium kernel: ACPI: Early table checksum verification disabled Nov 14 14:46:10 yttrium kernel: ACPI: RSDP 0x3D3C4014 24 (v02 HP ) Nov 14 14:46:10 yttrium kernel: ACPI: XSDT 0x3D3C4580 000124 (v01 HP RX2800-2 0001 0113) Nov 14 14:46:10 yttrium kernel: ACPI: FACP 0x3D3BE000 F4 (v03 HP RX2800-2 0001 HP 0001) root@yttrium:~# Same applies to the buildds: root@lifshitz:~# uname -a Linux lifshitz 6.0.0-4-mckinley #1 SMP Debian 6.0.8-1 (2022-11-11) ia64 GNU/Linux root@lifshitz:~# root@lenz:~# uname -a Linux lenz 6.0.0-4-mckinley #1 SMP Debian 6.0.8-1 (2022-11-11) ia64 GNU/Linux root@lenz:~# EFI works fine as well using the latest version of GRUB2. Thanks, Adrian [1] https://cdimage.debian.org/cdimage/ports/snapshots/ [2] https://mirror.yandex.ru/gentoo-distfiles//releases/ia64/autobuilds/
Re: [PATCH net-next 0/7] Remove three Sun net drivers
On 1/7/23 03:04, Anirudh Venkataramanan wrote: On 1/6/2023 5:36 PM, John Paul Adrian Glaubitz wrote: Hello! On 1/6/23 23:00, Anirudh Venkataramanan wrote: This series removes the Sun Cassini, LDOM vswitch and sunvnet drivers. This would affect a large number of Linux on SPARC users. Please don't! Thanks for chiming in. Does your statement above apply to all 3 drivers? Yes! We're still maintaining an active sparc64 port for Debian, see [1]. So does Gentoo [2]. In a recent patch series that touched these drivers [1], it was suggested that these drivers should be removed completely. git logs suggest that there hasn't been any significant feature addition, improvement or fixes to user-visible bugs in a while. A web search didn't indicate any recent discussions or any evidence that there are users out there who care about these drivers. Well, these drivers just work and I don't see why there should be regular discussions about them or changes. That's fair, but lack of discussion can also be signs of disuse, and that's really the hunch I was following up on. Given what you and Karl have said, I agree that we shouldn't remove these drivers. I'll stop pursuing this unless there are new arguments to the contrary. It's a common problem in my opinion on the LKML that many kernel developers assume that users of certain drivers and kernel subsystems are present and active on the kernel mailing lists to be able to raise their voices in these discussions. If you want to find out whether some parts of the kernel are actively being used, it's better to ask on distribution mailing lists because it's way more likely to find any users there. I try to be present on as many kernel mailing lists as I can to be able to answer these questions, but sometimes there is just too much traffic for me to handle. Adrian -- .''`. John Paul Adrian Glaubitz : :' : Debian Developer `. `' Physicist `-GPG: 62FF 8A75 84E0 2956 9546 0006 7426 3B37 F5B5 F913
Re: [PATCH net-next 0/7] Remove three Sun net drivers
Hello! On 1/6/23 23:00, Anirudh Venkataramanan wrote: This series removes the Sun Cassini, LDOM vswitch and sunvnet drivers. This would affect a large number of Linux on SPARC users. Please don't! We're still maintaining an active sparc64 port for Debian, see [1]. So does Gentoo [2]. In a recent patch series that touched these drivers [1], it was suggested that these drivers should be removed completely. git logs suggest that there hasn't been any significant feature addition, improvement or fixes to user-visible bugs in a while. A web search didn't indicate any recent discussions or any evidence that there are users out there who care about these drivers. Well, these drivers just work and I don't see why there should be regular discussions about them or changes. Adrian [1] https://cdimage.debian.org/cdimage/ports/snapshots/2022-12-09/ [2] https://www.gentoo.org/downloads/ -- .''`. John Paul Adrian Glaubitz : :' : Debian Developer `. `' Physicist `-GPG: 62FF 8A75 84E0 2956 9546 0006 7426 3B37 F5B5 F913
Re: Build regressions/improvements in v6.2-rc1
Hi Geert!
On 12/27/22 09:35, Geert Uytterhoeven wrote:
+ /kisskb/src/include/linux/compiler_types.h: error: call to
'__compiletime_assert_262' declared with attribute error: Unsupported access size
for {READ,WRITE}_ONCE().: => 358:45
+ /kisskb/src/include/linux/compiler_types.h: error: call to
'__compiletime_assert_263' declared with attribute error: Unsupported access size
for {READ,WRITE}_ONCE().: => 358:45
In function 'follow_pmd_mask',
inlined from 'follow_pud_mask' at /kisskb/src/mm/gup.c:735:9,
inlined from 'follow_p4d_mask' at /kisskb/src/mm/gup.c:752:9,
inlined from 'follow_page_mask' at /kisskb/src/mm/gup.c:809:9:
sh4-gcc11/sh-defconfig (Günter wondered if pmd_t should use union)
I'm seeing this, too. Also for sh7785lcr_defconfig.
sh4-gcc11/sh-allmodconfig (ICE = internal compiler error)
I'm not seeing this one, but I am getting this one instead:
In file included from ./arch/sh/include/asm/hw_irq.h:6,
from ./include/linux/irq.h:596,
from ./include/asm-generic/hardirq.h:17,
from ./arch/sh/include/asm/hardirq.h:9,
from ./include/linux/hardirq.h:11,
from ./include/linux/interrupt.h:11,
from ./include/linux/serial_core.h:13,
from ./include/linux/serial_sci.h:6,
from arch/sh/kernel/cpu/sh2/setup-sh7619.c:11:
./include/linux/sh_intc.h:100:63: error: division 'sizeof (void *) / sizeof
(void)' does not compute the number of array elements
[-Werror=sizeof-pointer-div]
100 | #define _INTC_ARRAY(a) a, __same_type(a, NULL) ? 0 :
sizeof(a)/sizeof(*a)
| ^
./include/linux/sh_intc.h:105:31: note: in expansion of macro '_INTC_ARRAY'
105 | _INTC_ARRAY(vectors), _INTC_ARRAY(groups), \
| ^~~
Adrian
--
.''`. John Paul Adrian Glaubitz
: :' : Debian Developer
`. `' Physicist
`-GPG: 62FF 8A75 84E0 2956 9546 0006 7426 3B37 F5B5 F913
Re: [PATCH v4 00/13] Fix LKDTM for PPC64/IA64/PARISC v4
Hi! On 2/16/22 13:25, John Paul Adrian Glaubitz wrote: >> This series does some cleanup in the three architectures and >> refactors function descriptors so that it can then easily use it >> in a generic way in LKDTM. > > I'll test the series on ia64 later this week. I have an Itanium box at > home for testing kernel patches. Series applied on top of 038101e6b2cd5c55f888f85db42ea2ad3aecb4b6 and successfully tested on my HP Integrity RX2600 server. Tested-by: John Paul Adrian Glaubitz 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: [PATCH v4 00/13] Fix LKDTM for PPC64/IA64/PARISC v4
Hi! On 2/15/22 13:40, Christophe Leroy wrote: > PPC64/IA64/PARISC have function descriptors. LKDTM doesn't work > on those three architectures because LKDTM messes up function > descriptors with functions. > > This series does some cleanup in the three architectures and > refactors function descriptors so that it can then easily use it > in a generic way in LKDTM. I'll test the series on ia64 later this week. I have an Itanium box at home for testing kernel 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
Re: [PATCH v4 16/20] Kbuild: add Rust support
Hi! On Sat, Feb 12, 2022 at 02:03:42PM +0100, Miguel Ojeda wrote: > +config RUST > + bool "Rust support" > + depends on RUST_IS_AVAILABLE > + depends on ARM64 || CPU_32v6 || CPU_32v6K || (PPC64 && > CPU_LITTLE_ENDIAN) || X86_64 || RISCV Is there any particular reason why this list excludes MIPS*, i386, big-endian PowerPC and SPARC targets which are already supported by the Rust programming language? Are the arch/$ARCH/rust/target.json files everything that's needed for supporting the other targets? 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
Re: Linux kernel: powerpc: KVM guest can trigger host crash on Power8
Hi Michael! On 1/13/22 01:17, John Paul Adrian Glaubitz wrote: > On 1/9/22 23:17, John Paul Adrian Glaubitz wrote: >> On 1/7/22 12:20, John Paul Adrian Glaubitz wrote: >>>> Can you separately test with (on the host): >>>> >>>> # echo 0 > /sys/module/kvm_hv/parameters/dynamic_mt_modes >>> >>> I'm trying to turn off "dynamic_mt_modes" first and see if that makes any >>> difference. >>> >>> I will report back. >> >> So far the machine is running stable now and the VM built gcc-9 without >> crashing the host. I will continue to monitor the machine and report back >> if it crashes, but it looks like this could be it. > > So, it seems that setting "dynamic_mt_modes" actually did the trick, the host > is no longer > crashing. However, I have observed on two occasions now that the build VM is > just suddenly > off as if someone has shut it down using the "force-off" option in the > virt-manager user > interface. Just as a heads-up. Ever since I set echo 0 > /sys/module/kvm_hv/parameters/dynamic_mt_modes on the host machine, I never saw the crash again. So the issue seems to be related to the dynamic_mt_modes feature. 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
Fix for PowerPC kernel with new assembler behavior?
Hi! Since this change in [1], the kernel no longer builds on 32- and 64-bit PowerPC and I was wondering whether anyone has already a patch available fixing this issue? Thanks, Adrian > [1] > https://sourceware.org/git/?p=binutils-gdb.git;a=commit;h=b25f942e18d6ecd7ec3e2d2e9930eb4f996c258a -- .''`. 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: Linux kernel: powerpc: KVM guest can trigger host crash on Power8
Hi Michael! On 1/9/22 23:17, John Paul Adrian Glaubitz wrote: > On 1/7/22 12:20, John Paul Adrian Glaubitz wrote: >>> Can you separately test with (on the host): >>> >>> # echo 0 > /sys/module/kvm_hv/parameters/dynamic_mt_modes >> >> I'm trying to turn off "dynamic_mt_modes" first and see if that makes any >> difference. >> >> I will report back. > > So far the machine is running stable now and the VM built gcc-9 without > crashing the host. I will continue to monitor the machine and report back > if it crashes, but it looks like this could be it. So, it seems that setting "dynamic_mt_modes" actually did the trick, the host is no longer crashing. However, I have observed on two occasions now that the build VM is just suddenly off as if someone has shut it down using the "force-off" option in the virt-manager user interface. Not sure why that happens. 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: Linux kernel: powerpc: KVM guest can trigger host crash on Power8
Hi Michael! On 1/7/22 12:20, John Paul Adrian Glaubitz wrote: >> Can you separately test with (on the host): >> >> # echo 0 > /sys/module/kvm_hv/parameters/dynamic_mt_modes > > I'm trying to turn off "dynamic_mt_modes" first and see if that makes any > difference. > > I will report back. So far the machine is running stable now and the VM built gcc-9 without crashing the host. I will continue to monitor the machine and report back if it crashes, but it looks like this could be 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
Re: Linux kernel: powerpc: KVM guest can trigger host crash on Power8
Hi Michael! On 1/6/22 11:58, Michael Ellerman wrote: >> We're currently running 5.15.x on the host system and the guests and the >> testsuite >> for gcc-9 still reproducibly kills the KVM host. > > Have you been able to try the different -smp options I suggested? > > Can you separately test with (on the host): > > # echo 0 > /sys/module/kvm_hv/parameters/dynamic_mt_modes I'm trying to turn off "dynamic_mt_modes" first and see if that makes any difference. I will report back. 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: Linux kernel: powerpc: KVM guest can trigger host crash on Power8
Hi Michael! On 11/1/21 08:37, John Paul Adrian Glaubitz wrote: > I made another experiment and upgraded the host to 5.15-rc7 which contains > your > fixes and made the guests build gcc-10. Interestingly, this time, the gcc-10 > build crashed the guest but didn't manage to crash the host. I will update the > guest to 5.15-rc7 now as well and see how that goes. OK, so I'm definitely able to crash the 5.15 kernel as well: [57031.404944] watchdog: BUG: soft lockup - CPU#24 stuck for 14957s! [migration/24:14] [57035.420898] watchdog: BUG: soft lockup - CPU#48 stuck for 14961s! [CPU 17/KVM:1815] [57047.456761] watchdog: BUG: soft lockup - CPU#152 stuck for 14841s! [CPU 13/KVM:1811] [57055.404670] watchdog: BUG: soft lockup - CPU#24 stuck for 14979s! [migration/24:14] [57059.420624] watchdog: BUG: soft lockup - CPU#48 stuck for 14983s! [CPU 17/KVM:1815] [57064.064573] rcu: INFO: rcu_sched self-detected stall on CPU [57064.064584] rcu: 48-: (3338577 ticks this GP) idle=9f3/1/0x4002 softirq=77540/77540 fqs=15421 [57064.064598] rcu: rcu_sched kthread timer wakeup didn't happen for 3988041 jiffies! g125265 f0x2 RCU_GP_WAIT_FQS(5) ->state=0x200 [57064.064606] rcu: Possible timer handling issue on cpu=136 timer-softirq=313650 [57064.064611] rcu: rcu_sched kthread starved for 3988042 jiffies! g125265 f0x2 RCU_GP_WAIT_FQS(5) ->state=0x200 ->cpu=136 [57064.064618] rcu: Unless rcu_sched kthread gets sufficient CPU time, OOM is now expected behavior. [57064.064624] rcu: RCU grace-period kthread stack dump: [57064.064665] rcu: Stack dump where RCU GP kthread last ran: [57071.456487] watchdog: BUG: soft lockup - CPU#152 stuck for 14863s! [CPU 13/KVM:1811] [57079.404396] watchdog: BUG: soft lockup - CPU#24 stuck for 15002s! [migration/24:14] And the gcc-10 testsuite is able to trigger the crash very reliably. 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: Linux kernel: powerpc: KVM guest can trigger host crash on Power8
Hi Michael! On 11/1/21 07:53, Michael Ellerman wrote: > Sure, will give that a try. > > I was able to crash my machine over the weekend, building openjdk, but I > haven't been able to reproduce it for ~24 hours now (I didn't change > anything). I made another experiment and upgraded the host to 5.15-rc7 which contains your fixes and made the guests build gcc-10. Interestingly, this time, the gcc-10 build crashed the guest but didn't manage to crash the host. I will update the guest to 5.15-rc7 now as well and see how that goes. > Can you try running your guests with no SMT threads? > > I think one of your guests was using: > > -smp 32,sockets=1,dies=1,cores=8,threads=4 > > Can you change that to: > > -smp 8,sockets=1,dies=1,cores=8,threads=1 > > > And something similar for the other guest(s). Sure. I will try that later. But first I want to switch the guests to 5.15-rc7 as well. > If the system is stable with those settings that would be useful > information, and would also mean you could use the system without it > crashing semi regularly. Gotcha. 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: Linux kernel: powerpc: KVM guest can trigger host crash on Power8
Hi Michael! On 10/28/21 08:39, Michael Ellerman wrote: > That completed fine on my BE VM here. > > I ran these in two tmux windows: > $ sbuild -d sid --arch=powerpc --no-arch-all gcc-11_11.2.0-10.dsc > $ sbuild -d sid --arch=ppc64 --no-arch-all gcc-11_11.2.0-10.dsc Could you try gcc-10 instead? It's testsuite has crashed the host for me with a patched kernel twice now. $ dget -u https://deb.debian.org/debian/pool/main/g/gcc-10/gcc-10_10.3.0-12.dsc $ sbuild -d sid --arch=powerpc --no-arch-all gcc-10_10.3.0-12.dsc $ sbuild -d sid --arch=ppc64 --no-arch-all gcc-10_10.3.0-12.dsc 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
Re: Linux kernel: powerpc: KVM guest can trigger host crash on Power8
7:02:31 watson kernel: [14110.585275] CPU 136 didn't respond to backtrace IPI, inspecting paca. Oct 25 17:02:31 watson kernel: [14110.585279] irq_soft_mask: 0x03 in_mce: 0 in_nmi: 0 current: 1813 (CPU 12/KVM) Oct 25 17:02:31 watson kernel: [14110.585284] Back trace of paca->saved_r1 (0xc0180640f4c0) (possibly stale): Oct 25 17:02:31 watson kernel: [14110.585286] Call Trace: Oct 25 17:02:31 watson kernel: [14110.585378] task:rcu_sched state:R running task stack:0 pid: 13 ppid: 2 flags:0x0800 Oct 25 17:02:31 watson kernel: [14110.585386] Call Trace: Oct 25 17:02:31 watson kernel: [14110.585388] [ce0978d0] [c01f71c0] rcu_implicit_dynticks_qs+0x0/0x370 (unreliable) Oct 25 17:02:31 watson kernel: [14110.585399] [ce097ac0] [c001b264] __switch_to+0x1d4/0x2e0 Oct 25 17:02:31 watson kernel: [14110.585407] [ce097b30] [c0cb9838] __schedule+0x2f8/0xbb0 Oct 25 17:02:31 watson kernel: [14110.585416] [ce097c00] [c0cba334] __cond_resched+0x64/0x90 Oct 25 17:02:31 watson kernel: [14110.585424] [ce097c30] [c01f8670] force_qs_rnp+0xe0/0x2e0 Oct 25 17:02:31 watson kernel: [14110.585433] [ce097cd0] [c01fc8a8] rcu_gp_kthread+0x9c8/0xc90 Oct 25 17:02:31 watson kernel: [14110.585442] [ce097da0] [c017403c] kthread+0x17c/0x190 Oct 25 17:02:31 watson kernel: [14110.585450] [ce097e10] [c000cf64] ret_from_kernel_thread+0x5c/0x64 Oct 25 17:02:31 watson kernel: [14110.585462] Sending NMI from CPU 80 to CPUs 32: Oct 25 17:02:31 watson kernel: [14110.585469] NMI backtrace for cpu 32 Oct 25 17:02:31 watson kernel: [14110.585473] CPU: 32 PID: 1289 Comm: in:imklog Tainted: GEL5.14.0-0.bpo.2-powerpc64le #1 Debian 5.14.9-2~bpo11+2 Oct 25 17:02:31 watson kernel: [14110.585477] NIP: 7fff92bc3bbc LR: 7fff92bc5e90 CTR: 7fff92bc5bf0 Oct 25 17:02:31 watson kernel: [14110.585480] REGS: c0001c9bfe80 TRAP: 0500 Tainted: GEL (5.14.0-0.bpo.2-powerpc64le Debian 5.14.9-2~bpo11+2) Oct 25 17:02:31 watson kernel: [14110.585483] MSR: 9280f033 CR: 48004802 XER: Oct 25 17:02:31 watson kernel: [14110.585496] CFAR: 7fff92bc3c34 IRQMASK: 0 Oct 25 17:02:31 watson kernel: [14110.585496] GPR00: 7fff9220d940 7fff92d37100 000c Oct 25 17:02:31 watson kernel: [14110.585496] GPR04: 7fff9222f928 7fff8460 7fff84097800 7fff84000900 Oct 25 17:02:31 watson kernel: [14110.585496] GPR08: 7fff840008d0 7fff8450 7fff8408f3a0 0007 Oct 25 17:02:31 watson kernel: [14110.585496] GPR12: 28004802 7fff92236810 7fff84097af0 Oct 25 17:02:31 watson kernel: [14110.585496] GPR16: 7fff9304 7fff92f54478 7fff9222f160 Oct 25 17:02:31 watson kernel: [14110.585496] GPR20: 7fff9222f810 7fff9220e4f0 0008 7fff927156b0 Oct 25 17:02:31 watson kernel: [14110.585496] GPR24: 7fff92715638 7fff927304f8 1fa0 Oct 25 17:02:31 watson kernel: [14110.585496] GPR28: 7fff9220e529 006f 7fff8420 0030 Oct 25 17:02:31 watson kernel: [14110.585530] NIP [7fff92bc3bbc] 0x7fff92bc3bbc Oct 25 17:02:31 watson kernel: [14110.585534] LR [7fff92bc5e90] 0x7fff92bc5e90 > Could you try a sysrq+w to get a trace of blocked tasks? Not sure how to send a magic sysrequest over the IPMI serial console. Any idea? > Are you able to shut down the guests and exit qemu normally? Not after the crash. I have to hard-reboot the whole machine. Adrian > [1] https://www.kernel.org/doc/html/latest/admin-guide/lockup-watchdogs.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
Re: Linux kernel: powerpc: KVM guest can trigger host crash on Power8
Hi! On 10/28/21 16:05, John Paul Adrian Glaubitz wrote: > The following packages were being built at the same time: > > - guest 1: virtuoso-opensource and openturns > - guest 2: llvm-toolchain-13 > > I really did a lot of testing today with no issues and just after I sent my > report > to oss-security that the machine seems to be stable again, the issue showed > up :(. Do you know whether IPMI features any sort of monitoring for capturing the output of the serial console non-interactively? This way I would be able to capture the crash besides what I have seen above. 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: Linux kernel: powerpc: KVM guest can trigger host crash on Power8
Hi Michael! On 10/28/21 13:20, John Paul Adrian Glaubitz wrote: > It seems I also can no longer reproduce the issue, even when building the > most problematic > packages and I think we should consider it fixed for now. I will keep > monitoring the server, > of course, and will let you know in case the problem shows again. The host machine is stuck again but I'm not 100% sure what triggered the problem: [194817.984249] watchdog: BUG: soft lockup - CPU#80 stuck for 246s! [CPU 2/KVM:1836] [194818.012248] watchdog: BUG: soft lockup - CPU#152 stuck for 246s! [CPU 3/KVM:1837] [194825.960164] watchdog: BUG: soft lockup - CPU#24 stuck for 246s! [khugepaged:318] [194841.983991] watchdog: BUG: soft lockup - CPU#80 stuck for 268s! [CPU 2/KVM:1836] [194842.011991] watchdog: BUG: soft lockup - CPU#152 stuck for 268s! [CPU 3/KVM:1837] [194849.959906] watchdog: BUG: soft lockup - CPU#24 stuck for 269s! [khugepaged:318] [194865.983733] watchdog: BUG: soft lockup - CPU#80 stuck for 291s! [CPU 2/KVM:1836] [194866.011733] watchdog: BUG: soft lockup - CPU#152 stuck for 291s! [CPU 3/KVM:1837] [194873.959648] watchdog: BUG: soft lockup - CPU#24 stuck for 291s! [khugepaged:318] [194889.983475] watchdog: BUG: soft lockup - CPU#80 stuck for 313s! [CPU 2/KVM:1836] [194890.011475] watchdog: BUG: soft lockup - CPU#152 stuck for 313s! [CPU 3/KVM:1837] [194897.959390] watchdog: BUG: soft lockup - CPU#24 stuck for 313s! [khugepaged:318] [194913.983218] watchdog: BUG: soft lockup - CPU#80 stuck for 335s! [CPU 2/KVM:1836] [194914.011217] watchdog: BUG: soft lockup - CPU#152 stuck for 335s! [CPU 3/KVM:1837] [194921.959133] watchdog: BUG: soft lockup - CPU#24 stuck for 336s! [khugepaged:318] The following packages were being built at the same time: - guest 1: virtuoso-opensource and openturns - guest 2: llvm-toolchain-13 I really did a lot of testing today with no issues and just after I sent my report to oss-security that the machine seems to be stable again, the issue showed up :(. Sorry, 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: Linux kernel: powerpc: KVM guest can trigger host crash on Power8
Hello! On 10/28/21 15:52, John Paul Adrian Glaubitz wrote: > I am not sure what triggered my previous crash but I don't think it's related > to this > particular bug. I will keep monitoring the server in any case and open a new > bug report > in case I'm running into similar issues. This is very unfortunate, but just after I sent this mail, the machine crashed again. Sorry for the premature success report. I will have to check now what happened and get in touch with Michael. 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: Linux kernel: powerpc: KVM guest can trigger host crash on Power8
Hello! An update to this post with oss-security CC'ed. On 10/26/21 10:48, John Paul Adrian Glaubitz wrote: > I have tested these patches against 5.14 but it seems the problem [1] still > remains for me > for big-endian guests. I built a patched kernel yesterday, rebooted the KVM > server and let > the build daemons do their work over night. I have done thorough testing and I'm no longer seeing the problem with the patched kernel. I am not sure what triggered my previous crash but I don't think it's related to this particular bug. I will keep monitoring the server in any case and open a new bug report in case I'm running into similar issues. 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
Re: Linux kernel: powerpc: KVM guest can trigger host crash on Power8
Hi Michael! On 10/28/21 08:39, Michael Ellerman wrote: >>> No, I will try that now. > > That completed fine on my BE VM here. > > I ran these in two tmux windows: > $ sbuild -d sid --arch=powerpc --no-arch-all gcc-11_11.2.0-10.dsc > $ sbuild -d sid --arch=ppc64 --no-arch-all gcc-11_11.2.0-10.dsc > > > The VM has 32 CPUs, with 4 threads per core: > > $ ppc64_cpu --info > Core 0:0*1*2*3* > Core 1:4*5*6*7* > Core 2:8*9* 10* 11* > Core 3: 12* 13* 14* 15* > Core 4: 16* 17* 18* 19* > Core 5: 20* 21* 22* 23* > Core 6: 24* 25* 26* 27* > Core 7: 28* 29* 30* 31* It seems I also can no longer reproduce the issue, even when building the most problematic packages and I think we should consider it fixed for now. I will keep monitoring the server, of course, and will let you know in case the problem shows again. Thanks a lot again for fixing this 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
Re: Linux kernel: powerpc: KVM guest can trigger host crash on Power8
Hi Michael! On 10/27/21 13:06, Michael Ellerman wrote: > John Paul Adrian Glaubitz writes: >> Hi Michael! >> >> On 10/27/21 07:30, Michael Ellerman wrote: >>> I did test the repro case you gave me before (in the bugzilla), which >>> was building glibc, that passes for me with a patched host. >> >> Did you manage to crash the unpatched host? > > Yes, the parallel builds of glibc you described crashed the unpatched > host 100% reliably for me. OK, that is very good news! > I also have a standalone reproducer I'll send you. Thanks, that would be helpful! >> Also, I'll try a kernel from git with Debian's config. >> >>> I guess we have yet another bug. >>> >>> I tried the following in a debian BE VM and it completed fine: >>> >>> $ dget -u http://ftp.debian.org/debian/pool/main/g/git/git_2.33.1-1.dsc >>> $ sbuild -d sid --arch=powerpc --no-arch-all git_2.33.1-1.dsc >>> >>> Same for ppc64. >>> >>> And I also tried both at once, repeatedly in a loop. >> >> Did you try building gcc-11 for powerpc and ppc64 both at once? > > No, I will try that now. OK, great! 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: Linux kernel: powerpc: KVM guest can trigger host crash on Power8
Hi Michael! On 10/27/21 07:30, Michael Ellerman wrote: > I did test the repro case you gave me before (in the bugzilla), which > was building glibc, that passes for me with a patched host. Did you manage to crash the unpatched host? If the unpatched host crashes for you but the patched doesn't, I will make sure I didn't accidentally miss anything. Also, I'll try a kernel from git with Debian's config. > I guess we have yet another bug. > > I tried the following in a debian BE VM and it completed fine: > > $ dget -u http://ftp.debian.org/debian/pool/main/g/git/git_2.33.1-1.dsc > $ sbuild -d sid --arch=powerpc --no-arch-all git_2.33.1-1.dsc > > Same for ppc64. > > And I also tried both at once, repeatedly in a loop. Did you try building gcc-11 for powerpc and ppc64 both at once? > I guess it's something more complicated. > > What exact host/guest kernel versions and configs are you running? Both the host and guest are running Debian's stock 5.14.12 kernel. The host has a kernel with your patches applied, the guest doesn't. Let me do some more testing. 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: Linux kernel: powerpc: KVM guest can trigger host crash on Power8
Hi Michael!
> The Linux kernel for powerpc since v5.2 has a bug which allows a
> malicious KVM guest to crash the host, when the host is running on
> Power8.
>
> Only machines using Linux as the hypervisor, aka. KVM, powernv or bare
> metal, are affected by the bug. Machines running PowerVM are not
> affected.
>
> The bug was introduced in:
>
> 10d91611f426 ("powerpc/64s: Reimplement book3s idle code in C")
>
> Which was first released in v5.2.
>
> The upstream fix is:
>
> cdeb5d7d890e ("KVM: PPC: Book3S HV: Make idle_kvm_start_guest() return 0 if
> it went to guest")
>
> https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/commit/?id=cdeb5d7d890e14f3b70e8087e745c4a6a7d9f337
>
> Which will be included in the v5.16 release.
I have tested these patches against 5.14 but it seems the problem [1] still
remains for me
for big-endian guests. I built a patched kernel yesterday, rebooted the KVM
server and let
the build daemons do their work over night.
When I got up this morning, I noticed the machine was down, so I checked the
serial console
via IPMI and saw the same messages again as reported in [1]:
[41483.963562] watchdog: BUG: soft lockup - CPU#104 stuck for 25521s!
[migration/104:175]
[41507.963307] watchdog: BUG: soft lockup - CPU#104 stuck for 25544s!
[migration/104:175]
[41518.311200] rcu: INFO: rcu_sched detected stalls on CPUs/tasks:
[41518.311216] rcu: 136-...0: (135 ticks this GP)
idle=242/1/0x4000 softirq=32031/32033 fqs=2729959
[41547.962882] watchdog: BUG: soft lockup - CPU#104 stuck for 25581s!
[migration/104:175]
[41571.962627] watchdog: BUG: soft lockup - CPU#104 stuck for 25603s!
[migration/104:175]
[41581.330530] rcu: INFO: rcu_sched detected stalls on CPUs/tasks:
[41581.330546] rcu: 136-...0: (135 ticks this GP)
idle=242/1/0x4000 softirq=32031/32033 fqs=2736378
[41611.962202] watchdog: BUG: soft lockup - CPU#104 stuck for 25641s!
[migration/104:175]
[41635.961947] watchdog: BUG: soft lockup - CPU#104 stuck for 25663s!
[migration/104:175]
[41644.349859] rcu: INFO: rcu_sched detected stalls on CPUs/tasks:
[41644.349876] rcu: 136-...0: (135 ticks this GP)
idle=242/1/0x4000 softirq=32031/32033 fqs=2742753
[41671.961564] watchdog: BUG: soft lockup - CPU#104 stuck for 25697s!
[migration/104:175]
[41695.961309] watchdog: BUG: soft lockup - CPU#104 stuck for 25719s!
[migration/104:175]
[41707.369190] rcu: INFO: rcu_sched detected stalls on CPUs/tasks:
[41707.369206] rcu: 136-...0: (135 ticks this GP)
idle=242/1/0x4000 softirq=32031/32033 fqs=2749151
[41735.960884] watchdog: BUG: soft lockup - CPU#104 stuck for 25756s!
[migration/104:175]
[41759.960629] watchdog: BUG: soft lockup - CPU#104 stuck for 25778s!
[migration/104:175]
[41770.388520] rcu: INFO: rcu_sched detected stalls on CPUs/tasks:
[41770.388548] rcu: 136-...0: (135 ticks this GP)
idle=242/1/0x4000 softirq=32031/32033 fqs=2755540
[41776.076307] rcu: rcu_sched kthread timer wakeup didn't happen for 1423
jiffies! g49897 f0x0 RCU_GP_WAIT_FQS(5) ->state=0x402
[41776.076327] rcu: Possible timer handling issue on cpu=32
timer-softirq=1056014
[41776.076336] rcu: rcu_sched kthread starved for 1424 jiffies! g49897 f0x0
RCU_GP_WAIT_FQS(5) ->state=0x402 ->cpu=32
[41776.076350] rcu: Unless rcu_sched kthread gets sufficient CPU time, OOM
is now expected behavior.
[41776.076360] rcu: RCU grace-period kthread stack dump:
[41776.076434] rcu: Stack dump where RCU GP kthread last ran:
[41783.960374] watchdog: BUG: soft lockup - CPU#104 stuck for 25801s!
[migration/104:175]
[41807.960119] watchdog: BUG: soft lockup - CPU#104 stuck for 25823s!
[migration/104:175]
[41831.959864] watchdog: BUG: soft lockup - CPU#104 stuck for 25846s!
[migration/104:175]
[41833.407851] rcu: INFO: rcu_sched detected stalls on CPUs/tasks:
[41833.407868] rcu: 136-...0: (135 ticks this GP)
idle=242/1/0x4000 softirq=32031/32033 fqs=2760381
[41863.959524] watchdog: BUG: soft lockup - CPU#104 stuck for 25875s!
[migration/104:175]
It seems that in this case, it was the testsuite of the git package [2] that
triggered the bug. As you
can see from the overview, the git package has been in the building state for 8
hours meaning the
build server crashed and is no longer giving feedback to the database.
Adrian
> [1] https://bugzilla.kernel.org/show_bug.cgi?id=206669
> [2] https://buildd.debian.org/status/package.php?p=git=experimental
--
.''`. 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: [PATCH 02/10] ARM: disable CONFIG_IDE in footbridge_defconfig
On 3/22/21 4:15 PM, Russell King - ARM Linux admin wrote: > I'm quite surprised that the CY82C693 even works on Alpha - I've > asked for a lspci for that last week but nothing has yet been > forthcoming from whoever responded to your patch for Alpha - so I > can't compare what I'm seeing with what's happening with Alpha. Here is lspci on my DEC Alpha XP-1000: root@tsunami:~> lspci :00:07.0 ISA bridge: Contaq Microsystems 82c693 :00:07.1 IDE interface: Contaq Microsystems 82c693 :00:07.2 IDE interface: Contaq Microsystems 82c693 :00:07.3 USB controller: Contaq Microsystems 82c693 :00:0d.0 VGA compatible controller: Texas Instruments TVP4020 [Permedia 2] (rev 01) 0001:01:03.0 Ethernet controller: Digital Equipment Corporation DECchip 21142/43 (rev 41) 0001:01:06.0 SCSI storage controller: QLogic Corp. ISP1020 Fast-wide SCSI (rev 06) 0001:01:08.0 PCI bridge: Digital Equipment Corporation DECchip 21152 (rev 03) 0001:02:09.0 Ethernet controller: Intel Corporation 82541PI Gigabit Ethernet Controller (rev 05) root@tsunami:~> It's using pata_cypress: root@tsunami:~> lsmod|grep cypress pata_cypress3595 3 libata235071 2 ata_generic,pata_cypress root@tsunami:~ 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: remove the legacy ide driver
Hello Christoph! On 3/18/21 5:56 AM, Christoph Hellwig wrote: > libata mostly covers all hardware supported by the legacy ide driver. > There are three mips drivers that are not supported, but the linux-mips > list could not identify any users of those. There also are two m68k > drivers that do not have libata equivalents, which might or might not > have users, so we'll need some input and possibly help from the m68k > community here. I think those drivers were the Q60 driver and the MacIDE driver, weren't they? Either way, I have so far been unsuccessful in obtaining access to these machines but I assume once we gain access to such machines, Bartlomiej could convert the drivers the same way he already converted the falcon, gayle and buddha drivers, for example. One could also just convert the drivers to libata and include them untested, the conversion itself seems pretty little work for someone experienced with libata. 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: [PATCH 01/10] alpha: use libata instead of the legacy ide driver
Hi Al! On 3/18/21 6:54 AM, Al Viro wrote: > On Thu, Mar 18, 2021 at 05:56:57AM +0100, Christoph Hellwig wrote: >> Switch the alpha defconfig from the legacy ide driver to libata. > > Umm... I don't have an IDE alpha box in a usable shape (fans on > CPU module shat themselves), and it would take a while to resurrect > it, but I remember the joy it used to cause in some versions. > > Do you have reports of libata variants of drivers actually tested on > those? At least pata_cypress works fine on my AlphaStation XP1000: root@tsunami:~> lspci :00:07.0 ISA bridge: Contaq Microsystems 82c693 :00:07.1 IDE interface: Contaq Microsystems 82c693 :00:07.2 IDE interface: Contaq Microsystems 82c693 :00:07.3 USB controller: Contaq Microsystems 82c693 :00:0d.0 VGA compatible controller: Texas Instruments TVP4020 [Permedia 2] (rev 01) 0001:01:03.0 Ethernet controller: Digital Equipment Corporation DECchip 21142/43 (rev 41) 0001:01:06.0 SCSI storage controller: QLogic Corp. ISP1020 Fast-wide SCSI (rev 06) 0001:01:08.0 PCI bridge: Digital Equipment Corporation DECchip 21152 (rev 03) 0001:02:09.0 Ethernet controller: Intel Corporation 82541PI Gigabit Ethernet Controller (rev 05) root@tsunami:~> lsmod|grep pata pata_cypress3595 3 libata235071 2 ata_generic,pata_cypress root@tsunami:~> I also have two AlphaStation 233 currently in storage which I assume use different IDE chipset which I could test as well. 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: [PATCH] macintosh: therm_windtunnel: fix regression when instantiating devices
Hello! On 2/25/20 3:12 PM, Wolfram Sang wrote: > Adding the Debian-PPC List to reach further people maybe willing to > test. This might be related [1]. Adrian > [1] https://lists.debian.org/debian-powerpc/2020/01/msg00062.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
Re: Call for report - G5/PPC970 status
On 12/12/19 9:00 AM, Romain Dolbeau wrote: > Could you share the screen/log of the crash? > > For my G5 with 5.5rc1 I have one, but the photo is terrible: > <http://www.dolbeau.name/dolbeau/files/Photo0031.jpg> > Timestamps overlap, as after the 'crash' (backtrace) there was > more messages from the (S)ATA subsystem. I suggest booting the machine with a netconsole to get a dump of the crash over the network, see [1]. Adrian > [1] https://wiki.archlinux.org/index.php/Netconsole -- .''`. 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: Found the commit for: 5.3.7 64-bits kernel doesn't boot on G5 Quad [regression]
Hi! On 12/10/19 9:35 AM, Romain Dolbeau wrote: > Le sam. 16 nov. 2019 à 17:34, Romain Dolbeau a écrit : >> So it seems to me that 0034d395f89d9c092bb15adbabdca5283e258b41 >> introduced the bug that crashes the PowerMac G5 > > There's been some commits in that subsystem, so I tried again; as of > 6794862a16ef41f753abd75c03a152836e4c8028, the kernel still crashes > when trying to boot my PowerMac G5. If Aneesh is currently unable to look at the problem, I would suggest reverting the commit in question since I don't think it's acceptable that users are unable to boot their machines anymore after a kernel upgrade. 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: Found the commit for: 5.3.7 64-bits kernel doesn't boot on G5 Quad
Hi Romain! Great detective work! On 11/16/19 5:34 PM, Romain Dolbeau wrote: > So it seems to me that 0034d395f89d9c092bb15adbabdca5283e258b41 > introduced the bug that crashes the PowerMac G5 (as/could anyone > tried/try on some other PPC970-based system, like a JS20 ? to see if > it's PowerMac-specific or not). So, that would be this commit [1] then: > authorAneesh Kumar K.V2019-04-17 > 18:29:14 +0530 > committer Michael Ellerman 2019-04-21 23:12:39 > +1000 > commit0034d395f89d9c092bb15adbabdca5283e258b41 (patch) > tree e5850612e6ada1285b19b21a21722fb2ea95b43e > parenta35a3c6f60657812366fca86a9ce71df1b8f7aff (diff) > download linux-0034d395f89d9c092bb15adbabdca5283e258b41.tar.gz > powerpc/mm/hash64: Map all the kernel regions in the same 0xc range > This patch maps vmalloc, IO and vmemap regions in the 0xc address range > instead of the current 0xd and 0xf range. This brings the mapping closer > to radix translation mode. > If anyone has an idea on how to fix this, that would be very welcome, > as I'm way out of my depth in the PPC64 MMU code. The best thing would be to notify the author of said commit about the regression which would be Aneesh Kumar (CC'ed). Adrian > [1] > https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/commit/?id=0034d395f89d9c092bb15adbabdca5283e258b41 -- .''`. 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: [PATCH 37/41] drivers: tty: serial: 8250: simplify io resource size computation
On 4/27/19 2:52 PM, Enrico Weigelt, metux IT consult wrote: > Simpily io resource size computation by setting mapsize field. Here's a typo 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: [RFC] new SYSCALL_DEFINE/COMPAT_SYSCALL_DEFINE wrappers
On 03/27/2018 12:40 PM, Linus Torvalds wrote: > On Mon, Mar 26, 2018 at 4:37 PM, John Paul Adrian Glaubitz > <glaub...@physik.fu-berlin.de> wrote: >> >> What about a tarball with a minimal Debian x32 chroot? Then you can >> install interesting packages you would like to test yourself. > > That probably works fine. I just created a fresh Debian x32 unstable chroot using this command: $ debootstrap --no-check-gpg --variant=minbase --arch=x32 unstable debian-x32-unstable http://ftp.ports.debian.org/debian-ports It can be downloaded from my Debian webspace along checksum files for verification: > https://people.debian.org/~glaubitz/chroots/ Let me know if you run into any issues. 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: [RFC] new SYSCALL_DEFINE/COMPAT_SYSCALL_DEFINE wrappers
On 03/27/2018 10:03 AM, Linus Torvalds wrote: > Hmm. Do you have a few statically built binaries that could be tested > without installing a whole distribution? Something real and meaningful > enough that it actually exercised a few real system calls, but not > something that needs to bring in 50 different shared libraries? > > Something in /sbin, perhaps, that is still runnable by a regular user > and doesn't require some distro-specific /etc layout etc, so that it > would work even if you don't run Debian at all? Maybe some shell > binary or something? What about a tarball with a minimal Debian x32 chroot? Then you can install interesting packages you would like to test yourself. 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: [RFC] new SYSCALL_DEFINE/COMPAT_SYSCALL_DEFINE wrappers
Hi Linus! On 03/26/2018 03:15 PM, Linus Torvalds wrote: > Secretly, I was hoping to kill x32, because it's not being used afaik. FWIW, we are maintaining an x32 port in Debian and there are some people actually using it [1]. There is one build instance running on VMWare that I am hosting [2] and around 10800 out of 12900 source packages build fine on x32 (12900 being the number for x86_64). The port is mostly stable but the fact that it's a 32-bit target with a 64-bit kernel API often blows up in people's faces because they don't expect things like a 64-bit time_t on a 32-bit system. The port also has some issues with software unaware of the x32 and builds fail when they just test for __x86_64__ but not for __ILP32__, but overall it's usable and stable and has some performance advantages over x86_64. Adrian > [1] http://debian-x32.org/ > [2] https://buildd.debian.org/status/architecture.php?a=x32=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
Re: Build regression introduced by 31cdd0c39c7544ced79da53aa0b7e989f3a39582
On 09/10/2016 11:53 AM, Michael Ellerman wrote: >> Thanks for the quick fix! > > I assume by that it worked for you? I'll add a Tested-by: for you? Not yet. I just got my second PowerPC e500 evaluation board yesterday and the other board is running 24/7 as an automatic build machine. I will need a few days to be able to assemble the second machine since I need to order some parts (SSD, power supply, memory and so on) first. 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
Re: Build regression introduced by 31cdd0c39c7544ced79da53aa0b7e989f3a39582
On 09/09/2016 03:29 AM, Michael Ellerman wrote: > Interestingly it builds fine for me, even for 32-bit configs, I assume > because my toolchains are 32/64-bit they are able to cope with it. I'll > try and built a 32-bit only toolchain to catch these problems in future. Yeah, I was just asking myself the same question after seeing your patch on the list as the kernel package builds fine on Debian's powerpc port [1]. However, the powerpc Debian package always builds a 64-bit kernel image as well in order to be able to use a 32-bit userland on a 64-bit kernel when the hardware is capable of 64-bit. So, your guess above might actually be true, but I haven't tested it. What I do know is that "ld" is definitely not available on PowerPC e500 while "lwz" is available, see 3-68 in the e500 reference manual [2]. Thanks for the quick fix! Adrian > [1] > https://buildd.debian.org/status/fetch.php?pkg=linux=powerpc=4.7.2-1=1472464832 > [2] http://www.nxp.com/files/32bit/doc/ref_manual/E500CORERM.pdf -- .''`. 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
Build regression introduced by 31cdd0c39c7544ced79da53aa0b7e989f3a39582
Hi Paul! I'm referring to your change [1]: "powerpc/xmon: Fix SPR read/write commands and add command to dump SPRs" which introduced assembly code in the new file arch/powerpc/xmon/spr_access.S. Unfortunately, this code contains assembly instructions which are not available on all ppc targets. In particular, this change breaks the build on PPC e500v2 targets, see the corresponding Debian bug report [2]. Could you have a look and possibly add some guarding #ifdefs for the ppc targets where "ld" is not a supported instruction? Thanks, Adrian > [1] > https://git.kernel.org/cgit/linux/kernel/git/torvalds/linux.git/commit/?id=31cdd0c39c7544ced79da53aa0b7e989f3a39582 > [2] https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=836741 -- .''`. 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#836741: linux: FTBFS on powerpcspe due to the use of unsupported instructions
Source: linux Version: 4.7.2-1 Severity: normal User: debian-powe...@lists.debian.org Usertags: powerpcspe Hi! Linux 4.7.x introduced another regression on powerpcspe due to the use of unsupported assembly instructions [1]: /<>/arch/powerpc/xmon/spr_access.S: Assembler messages: /<>/arch/powerpc/xmon/spr_access.S:5: Error: unrecognized opcode: `ld' /<>/arch/powerpc/xmon/spr_access.S:10: Error: unrecognized opcode: `ld' /<>/scripts/Makefile.build:331: recipe for target 'arch/powerpc/xmon/spr_access.o' failed make[6]: *** [arch/powerpc/xmon/spr_access.o] Error 1 This is very reminiscent of #823526 [2] which also used some FPU instructions not available on powerpcspe/e500. And, indeed, like "ldarx" and "stdcx", "ld" is not available on e500 either [3] (see p. 3-68). I haven't looked at the code yet, but I assume guarding the code with some additional #ifdef's should fix the issue the same way as in #823526. Thanks, Adrian > [1] > https://buildd.debian.org/status/fetch.php?pkg=linux=powerpcspe=4.7.2-1=1472977882 > [2] https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=823526 > [3] http://www.nxp.com/files/32bit/doc/ref_manual/E500CORERM.pdf -- .''`. 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
