Re: [PATCH 00/20] sh: Fix missing prototypes
On Fri, 2024-03-01 at 22:02 +0100, Geert Uytterhoeven wrote: > Hi all, > > This patch series fixes several "no previous prototype for " > warnings when building a kernel for SuperH. > > Known issues: > - The various warnings about cache functions are not yet fixed, but > I didn't want to hold off the rest of this series, > - sdk7786_defconfig needs "[PATCH/RFC] locking/spinlocks: Make __raw_* > lock ops static" [1], > - Probably there are more warnings to fix, I didn't build all > defconfigs. > > This has been boot-tested on landisk and on qemu/rts7751r2d. > > Thanks for your comments! > > [1] > https://lore.kernel.org/linux-sh/c395b02613572131568bc1fd1bc456d20d1a5426.1709325647.git.geert+rene...@glider.be > > Geert Uytterhoeven (20): > sh: pgtable: Fix missing prototypes > sh: fpu: Add missing forward declarations > sh: syscall: Add missing forward declaration for sys_cacheflush() > sh: tlb: Add missing forward declaration for handle_tlbmiss() > sh: return_address: Add missing #include > sh: traps: Add missing #include > sh: hw_breakpoint: Add missing forward declaration for > arch_bp_generic_fields() > sh: boot: Add proper forward declarations > sh: ftrace: Fix missing prototypes > sh: nommu: Add missing #include > sh: math-emu: Add missing #include > sh: dma: Remove unused dmac_search_free_channel() > sh: sh2a: Add missing #include > sh: sh7786: Remove unused sh7786_usb_use_exclock() > sh: smp: Fix missing prototypes > sh: kprobes: Merge arch_copy_kprobe() into arch_prepare_kprobe() > sh: kprobes: Make trampoline_probe_handler() static > sh: kprobes: Remove unneeded kprobe_opcode_t casts > sh: dwarf: Make dwarf_lookup_fde() static > [RFC] sh: dma: Remove unused functionality > > arch/sh/boot/compressed/cache.c | 3 + > arch/sh/boot/compressed/cache.h | 10 ++ > arch/sh/boot/compressed/misc.c | 8 +- > arch/sh/boot/compressed/misc.h | 9 ++ > arch/sh/drivers/dma/dma-api.c | 143 > arch/sh/include/asm/dma.h | 7 -- > arch/sh/include/asm/fpu.h | 3 + > arch/sh/include/asm/ftrace.h| 10 ++ > arch/sh/include/asm/hw_breakpoint.h | 2 + > arch/sh/include/asm/syscalls.h | 1 + > arch/sh/include/asm/tlb.h | 4 + > arch/sh/kernel/cpu/sh2a/opcode_helper.c | 2 + > arch/sh/kernel/cpu/sh4a/setup-sh7786.c | 14 --- > arch/sh/kernel/dwarf.c | 2 +- > arch/sh/kernel/kprobes.c| 13 +-- > arch/sh/kernel/return_address.c | 2 + > arch/sh/kernel/smp.c| 4 +- > arch/sh/kernel/traps.c | 10 +- > arch/sh/kernel/traps_32.c | 1 + > arch/sh/math-emu/math.c | 2 + > arch/sh/mm/nommu.c | 2 + > arch/sh/mm/pgtable.c| 4 +- > arch/sh/mm/tlbex_32.c | 1 + > 23 files changed, 68 insertions(+), 189 deletions(-) > create mode 100644 arch/sh/boot/compressed/cache.h > create mode 100644 arch/sh/boot/compressed/misc.h Applied to my sh-linux tree in the for-next branch. Thanks, Adrian -- .''`. John Paul Adrian Glaubitz : :' : Debian Developer `. `' Physicist `-GPG: 62FF 8A75 84E0 2956 9546 0006 7426 3B37 F5B5 F913
Re: [PATCH 20/20] [RFC] sh: dma: Remove unused functionality
Hi Geert, On Thu, 2024-05-02 at 09:03 +0200, Geert Uytterhoeven wrote: > On Wed, May 1, 2024 at 3:58 PM John Paul Adrian Glaubitz > wrote: > > On Wed, 2024-05-01 at 11:12 +0200, John Paul Adrian Glaubitz wrote: > > > On Fri, 2024-03-01 at 22:02 +0100, Geert Uytterhoeven wrote: > > > > dma_extend(), get_dma_info_by_name(), register_chan_caps(), and > > > > request_dma_bycap() are unused. Remove them, and all related code. > > > > > > > > Signed-off-by: Geert Uytterhoeven > > > > I assume we could re-add these again in case we need them, but it would > > > be good > > > if Yoshinori could comment on whether we should keep these functions or > > > not. > > > > I was wondering: Could there be any userland tools using these DMA > > functions? > > They cannot be called from userspace, as there is no API for that. > They can only be called from inside the kernel, or from a kernel module > (possibly out-of-tree). OK, thanks for the confirmation. Then I think it's safe to remove them. I will apply both your series tonight and the rest of the patches except for the one that moves the paging_init() around as it turns out the current positioning is intentional. Adrian -- .''`. John Paul Adrian Glaubitz : :' : Debian Developer `. `' Physicist `-GPG: 62FF 8A75 84E0 2956 9546 0006 7426 3B37 F5B5 F913
Re: [PATCH 20/20] [RFC] sh: dma: Remove unused functionality
Hi Geert,
On Wed, 2024-05-01 at 11:12 +0200, John Paul Adrian Glaubitz wrote:
> Hi Geert,
>
> On Fri, 2024-03-01 at 22:02 +0100, Geert Uytterhoeven wrote:
> > dma_extend(), get_dma_info_by_name(), register_chan_caps(), and
> > request_dma_bycap() are unused. Remove them, and all related code.
> >
> > Signed-off-by: Geert Uytterhoeven
> > ---
> > arch/sh/drivers/dma/dma-api.c | 116 --
> > arch/sh/include/asm/dma.h | 7 --
> > 2 files changed, 123 deletions(-)
> >
> > diff --git a/arch/sh/drivers/dma/dma-api.c b/arch/sh/drivers/dma/dma-api.c
> > index f49097fa634c36d4..87e5a892887360f5 100644
> > --- a/arch/sh/drivers/dma/dma-api.c
> > +++ b/arch/sh/drivers/dma/dma-api.c
> > @@ -41,21 +41,6 @@ struct dma_info *get_dma_info(unsigned int chan)
> > }
> > EXPORT_SYMBOL(get_dma_info);
> >
> > -struct dma_info *get_dma_info_by_name(const char *dmac_name)
> > -{
> > - struct dma_info *info;
> > -
> > - list_for_each_entry(info, _dmac_list, list) {
> > - if (dmac_name && (strcmp(dmac_name, info->name) != 0))
> > - continue;
> > - else
> > - return info;
> > - }
> > -
> > - return NULL;
> > -}
> > -EXPORT_SYMBOL(get_dma_info_by_name);
> > -
> > static unsigned int get_nr_channels(void)
> > {
> > struct dma_info *info;
> > @@ -101,66 +86,6 @@ int get_dma_residue(unsigned int chan)
> > }
> > EXPORT_SYMBOL(get_dma_residue);
> >
> > -static int search_cap(const char **haystack, const char *needle)
> > -{
> > - const char **p;
> > -
> > - for (p = haystack; *p; p++)
> > - if (strcmp(*p, needle) == 0)
> > - return 1;
> > -
> > - return 0;
> > -}
> > -
> > -/**
> > - * request_dma_bycap - Allocate a DMA channel based on its capabilities
> > - * @dmac: List of DMA controllers to search
> > - * @caps: List of capabilities
> > - *
> > - * Search all channels of all DMA controllers to find a channel which
> > - * matches the requested capabilities. The result is the channel
> > - * number if a match is found, or %-ENODEV if no match is found.
> > - *
> > - * Note that not all DMA controllers export capabilities, in which
> > - * case they can never be allocated using this API, and so
> > - * request_dma() must be used specifying the channel number.
> > - */
> > -int request_dma_bycap(const char **dmac, const char **caps, const char
> > *dev_id)
> > -{
> > - unsigned int found = 0;
> > - struct dma_info *info;
> > - const char **p;
> > - int i;
> > -
> > - BUG_ON(!dmac || !caps);
> > -
> > - list_for_each_entry(info, _dmac_list, list)
> > - if (strcmp(*dmac, info->name) == 0) {
> > - found = 1;
> > - break;
> > - }
> > -
> > - if (!found)
> > - return -ENODEV;
> > -
> > - for (i = 0; i < info->nr_channels; i++) {
> > - struct dma_channel *channel = >channels[i];
> > -
> > - if (unlikely(!channel->caps))
> > - continue;
> > -
> > - for (p = caps; *p; p++) {
> > - if (!search_cap(channel->caps, *p))
> > - break;
> > - if (request_dma(channel->chan, dev_id) == 0)
> > - return channel->chan;
> > - }
> > - }
> > -
> > - return -EINVAL;
> > -}
> > -EXPORT_SYMBOL(request_dma_bycap);
> > -
> > int request_dma(unsigned int chan, const char *dev_id)
> > {
> > struct dma_channel *channel = { 0 };
> > @@ -213,35 +138,6 @@ void dma_wait_for_completion(unsigned int chan)
> > }
> > EXPORT_SYMBOL(dma_wait_for_completion);
> >
> > -int register_chan_caps(const char *dmac, struct dma_chan_caps *caps)
> > -{
> > - struct dma_info *info;
> > - unsigned int found = 0;
> > - int i;
> > -
> > - list_for_each_entry(info, _dmac_list, list)
> > - if (strcmp(dmac, info->name) == 0) {
> > - found = 1;
> > - break;
> > - }
> > -
> > - if (unlikely(!found))
> > - return -ENODEV;
> > -
> > - for (i = 0; i < info->nr_channels; i++, caps++) {
> > - struct dma_channel *channel;
> > -
> >
Re: [PATCH 00/20] sh: Fix missing prototypes
Hi Geert, On Fri, 2024-03-01 at 22:02 +0100, Geert Uytterhoeven wrote: > Hi all, > > This patch series fixes several "no previous prototype for " > warnings when building a kernel for SuperH. > > Known issues: > - The various warnings about cache functions are not yet fixed, but > I didn't want to hold off the rest of this series, > - sdk7786_defconfig needs "[PATCH/RFC] locking/spinlocks: Make __raw_* > lock ops static" [1], > - Probably there are more warnings to fix, I didn't build all > defconfigs. > > This has been boot-tested on landisk and on qemu/rts7751r2d. > > Thanks for your comments! > > [1] > https://lore.kernel.org/linux-sh/c395b02613572131568bc1fd1bc456d20d1a5426.1709325647.git.geert+rene...@glider.be > > Geert Uytterhoeven (20): > sh: pgtable: Fix missing prototypes > sh: fpu: Add missing forward declarations > sh: syscall: Add missing forward declaration for sys_cacheflush() > sh: tlb: Add missing forward declaration for handle_tlbmiss() > sh: return_address: Add missing #include > sh: traps: Add missing #include > sh: hw_breakpoint: Add missing forward declaration for > arch_bp_generic_fields() > sh: boot: Add proper forward declarations > sh: ftrace: Fix missing prototypes > sh: nommu: Add missing #include > sh: math-emu: Add missing #include > sh: dma: Remove unused dmac_search_free_channel() > sh: sh2a: Add missing #include > sh: sh7786: Remove unused sh7786_usb_use_exclock() > sh: smp: Fix missing prototypes > sh: kprobes: Merge arch_copy_kprobe() into arch_prepare_kprobe() > sh: kprobes: Make trampoline_probe_handler() static > sh: kprobes: Remove unneeded kprobe_opcode_t casts > sh: dwarf: Make dwarf_lookup_fde() static > [RFC] sh: dma: Remove unused functionality > > arch/sh/boot/compressed/cache.c | 3 + > arch/sh/boot/compressed/cache.h | 10 ++ > arch/sh/boot/compressed/misc.c | 8 +- > arch/sh/boot/compressed/misc.h | 9 ++ > arch/sh/drivers/dma/dma-api.c | 143 > arch/sh/include/asm/dma.h | 7 -- > arch/sh/include/asm/fpu.h | 3 + > arch/sh/include/asm/ftrace.h| 10 ++ > arch/sh/include/asm/hw_breakpoint.h | 2 + > arch/sh/include/asm/syscalls.h | 1 + > arch/sh/include/asm/tlb.h | 4 + > arch/sh/kernel/cpu/sh2a/opcode_helper.c | 2 + > arch/sh/kernel/cpu/sh4a/setup-sh7786.c | 14 --- > arch/sh/kernel/dwarf.c | 2 +- > arch/sh/kernel/kprobes.c| 13 +-- > arch/sh/kernel/return_address.c | 2 + > arch/sh/kernel/smp.c| 4 +- > arch/sh/kernel/traps.c | 10 +- > arch/sh/kernel/traps_32.c | 1 + > arch/sh/math-emu/math.c | 2 + > arch/sh/mm/nommu.c | 2 + > arch/sh/mm/pgtable.c| 4 +- > arch/sh/mm/tlbex_32.c | 1 + > 23 files changed, 68 insertions(+), 189 deletions(-) > create mode 100644 arch/sh/boot/compressed/cache.h > create mode 100644 arch/sh/boot/compressed/misc.h > For the whole series: Reviewed-by: John Paul Adrian Glaubitz I would still like to get feedback from Yoshinori on patch #20 though, i.e. "sh: dma: Remove unused functionality". On the other hand, we could just merge this series and re-add the functions later if we decide they're still needed. Adrian -- .''`. John Paul Adrian Glaubitz : :' : Debian Developer `. `' Physicist `-GPG: 62FF 8A75 84E0 2956 9546 0006 7426 3B37 F5B5 F913
Re: [PATCH 20/20] [RFC] sh: dma: Remove unused functionality
han, unsigned long op, void *param)
> -{
> - struct dma_info *info = get_dma_info(chan);
> - struct dma_channel *channel = get_dma_channel(chan);
> -
> - if (info->ops->extend)
> - return info->ops->extend(channel, op, param);
> -
> - return -ENOSYS;
> -}
> -EXPORT_SYMBOL(dma_extend);
> -
> static int dma_proc_show(struct seq_file *m, void *v)
> {
> struct dma_info *info = v;
> diff --git a/arch/sh/include/asm/dma.h b/arch/sh/include/asm/dma.h
> index c8bee3f985a29393..6b6d409956d17f09 100644
> --- a/arch/sh/include/asm/dma.h
> +++ b/arch/sh/include/asm/dma.h
> @@ -56,7 +56,6 @@ struct dma_ops {
> int (*get_residue)(struct dma_channel *chan);
> int (*xfer)(struct dma_channel *chan);
> int (*configure)(struct dma_channel *chan, unsigned long flags);
> - int (*extend)(struct dma_channel *chan, unsigned long op, void *param);
> };
>
> struct dma_channel {
> @@ -118,8 +117,6 @@ extern int dma_xfer(unsigned int chan, unsigned long from,
> #define dma_read_page(chan, from, to)\
> dma_read(chan, from, to, PAGE_SIZE)
>
> -extern int request_dma_bycap(const char **dmac, const char **caps,
> - const char *dev_id);
> extern int get_dma_residue(unsigned int chan);
> extern struct dma_info *get_dma_info(unsigned int chan);
> extern struct dma_channel *get_dma_channel(unsigned int chan);
> @@ -128,10 +125,6 @@ extern void dma_configure_channel(unsigned int chan,
> unsigned long flags);
>
> extern int register_dmac(struct dma_info *info);
> extern void unregister_dmac(struct dma_info *info);
> -extern struct dma_info *get_dma_info_by_name(const char *dmac_name);
> -
> -extern int dma_extend(unsigned int chan, unsigned long op, void *param);
> -extern int register_chan_caps(const char *dmac, struct dma_chan_caps
> *capslist);
>
> /* arch/sh/drivers/dma/dma-sysfs.c */
> extern int dma_create_sysfs_files(struct dma_channel *, struct dma_info *);
I assume we could re-add these again in case we need them, but it would be good
if Yoshinori could comment on whether we should keep these functions or not.
Adrian
--
.''`. John Paul Adrian Glaubitz
: :' : Debian Developer
`. `' Physicist
`-GPG: 62FF 8A75 84E0 2956 9546 0006 7426 3B37 F5B5 F913
Re: [PATCH 12/20] sh: dma: Remove unused dmac_search_free_channel()
Hi Geert,
On Fri, 2024-03-01 at 22:02 +0100, Geert Uytterhoeven wrote:
> arch/sh/drivers/dma/dma-api.c:164:5: warning: no previous prototype for
> 'dmac_search_free_channel' [-Wmissing-prototypes]
>
> dmac_search_free_channel() never had a user in upstream, remove it.
>
> Signed-off-by: Geert Uytterhoeven
> ---
> dma_extend(), get_dma_info_by_name(), register_chan_caps(), and
> request_dma_bycap() are also unused, but don't trigger warnings
> ---
I assume the other functions didn't trigger a warning because their symbols
were exported. Correct me if I'm wrong.
Adrian
> arch/sh/drivers/dma/dma-api.c | 27 ---
> 1 file changed, 27 deletions(-)
>
> diff --git a/arch/sh/drivers/dma/dma-api.c b/arch/sh/drivers/dma/dma-api.c
> index 89cd4a3b4ccafbe2..f49097fa634c36d4 100644
> --- a/arch/sh/drivers/dma/dma-api.c
> +++ b/arch/sh/drivers/dma/dma-api.c
> @@ -161,33 +161,6 @@ int request_dma_bycap(const char **dmac, const char
> **caps, const char *dev_id)
> }
> EXPORT_SYMBOL(request_dma_bycap);
>
> -int dmac_search_free_channel(const char *dev_id)
> -{
> - struct dma_channel *channel = { 0 };
> - struct dma_info *info = get_dma_info(0);
> - int i;
> -
> - for (i = 0; i < info->nr_channels; i++) {
> - channel = >channels[i];
> - if (unlikely(!channel))
> - return -ENODEV;
> -
> - if (atomic_read(>busy) == 0)
> - break;
> - }
> -
> - if (info->ops->request) {
> - int result = info->ops->request(channel);
> - if (result)
> - return result;
> -
> - atomic_set(>busy, 1);
> - return channel->chan;
> - }
> -
> - return -ENOSYS;
> -}
> -
> int request_dma(unsigned int chan, const char *dev_id)
> {
> struct dma_channel *channel = { 0 };
--
.''`. John Paul Adrian Glaubitz
: :' : Debian Developer
`. `' Physicist
`-GPG: 62FF 8A75 84E0 2956 9546 0006 7426 3B37 F5B5 F913
Re: [PATCH v2] locking/atomic: sh: Use generic_cmpxchg_local for arch_cmpxchg_local()
On Thu, 2023-10-26 at 00:10 +0900, Masami Hiramatsu (Google) wrote:
> From: Masami Hiramatsu (Google)
>
> Use __generic_cmpxchg_local() for arch_cmpxchg_local() implementation
> in SH architecture because it does not implement arch_cmpxchg_local().
>
> Reported-by: kernel test robot
> Closes:
> https://lore.kernel.org/oe-kbuild-all/202310241310.ir5uukog-...@intel.com/
> Signed-off-by: Masami Hiramatsu (Google)
> ---
> arch/sh/include/asm/cmpxchg.h |9 +
> 1 file changed, 9 insertions(+)
>
> diff --git a/arch/sh/include/asm/cmpxchg.h b/arch/sh/include/asm/cmpxchg.h
> index 288f6f38d98f..5d617b3ef78f 100644
> --- a/arch/sh/include/asm/cmpxchg.h
> +++ b/arch/sh/include/asm/cmpxchg.h
> @@ -71,4 +71,13 @@ static inline unsigned long __cmpxchg(volatile void * ptr,
> unsigned long old,
> (unsigned long)_n_, sizeof(*(ptr))); \
>})
>
> +#include
> +
> +#define arch_cmpxchg_local(ptr, o, n) ({ \
> + (__typeof__(*ptr))__generic_cmpxchg_local((ptr),\
> + (unsigned long)(o), \
> + (unsigned long)(n), \
> + sizeof(*(ptr))); \
> +})
> +
> #endif /* __ASM_SH_CMPXCHG_H */
Reviewed-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] locking/atomic: sh: Use generic_cmpxchg_local for arch_cmpxchg_local()
On Wed, 2023-10-25 at 11:30 +0100, Mark Rutland wrote: > On Wed, Oct 25, 2023 at 08:42:55AM +0900, Masami Hiramatsu wrote: > > On Tue, 24 Oct 2023 16:08:12 +0100 > > Mark Rutland wrote: > > > > > On Tue, Oct 24, 2023 at 11:52:54PM +0900, Masami Hiramatsu (Google) wrote: > > > > From: Masami Hiramatsu (Google) > > > > > > > > Use generic_cmpxchg_local() for arch_cmpxchg_local() implementation > > > > in SH architecture because it does not implement arch_cmpxchg_local(). > > > > > > I do not think this is correct. > > > > > > The implementation in is UP-only (and it > > > only > > > disables interrupts), whereas arch/sh can be built SMP. We should > > > probably add > > > some guards into for that as we have in > > > . > > > > Isn't cmpxchg_local for the data which only needs to ensure to do cmpxchg > > on local CPU? > > So I think it doesn't care about the other CPUs (IOW, it should not touched > > by > > other CPUs), so it only considers UP case. E.g. on x86, > > arch_cmpxchg_local() is > > defined as raw "cmpxchg" without lock prefix. > > > > #define __cmpxchg_local(ptr, old, new, size)\ > > __raw_cmpxchg((ptr), (old), (new), (size), "") > > > > Yes, you're right; sorry for the noise. > > For your original patch: > > Acked-by: Mark Rutland > Geert, what's your opinion on this? Adrian -- .''`. John Paul Adrian Glaubitz : :' : Debian Developer `. `' Physicist `-GPG: 62FF 8A75 84E0 2956 9546 0006 7426 3B37 F5B5 F913
Re: [PATCH] locking/atomic: sh: Use generic_cmpxchg_local for arch_cmpxchg_local()
On Tue, 2023-10-24 at 23:52 +0900, Masami Hiramatsu (Google) wrote: > From: Masami Hiramatsu (Google) > > Use generic_cmpxchg_local() for arch_cmpxchg_local() implementation > in SH architecture because it does not implement arch_cmpxchg_local(). > > Reported-by: kernel test robot > Closes: > https://lore.kernel.org/oe-kbuild-all/202310241310.ir5uukog-...@intel.com/ > Signed-off-by: Masami Hiramatsu (Google) > --- > arch/sh/include/asm/cmpxchg.h |2 ++ > 1 file changed, 2 insertions(+) > > diff --git a/arch/sh/include/asm/cmpxchg.h b/arch/sh/include/asm/cmpxchg.h > index 288f6f38d98f..e920e61fb817 100644 > --- a/arch/sh/include/asm/cmpxchg.h > +++ b/arch/sh/include/asm/cmpxchg.h > @@ -71,4 +71,6 @@ static inline unsigned long __cmpxchg(volatile void * ptr, > unsigned long old, > (unsigned long)_n_, sizeof(*(ptr))); \ >}) > > +#include > + > #endif /* __ASM_SH_CMPXCHG_H */ Reviewed-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] ia64: module: fix symbolizer crash on fdescr
Hi Sergei! On 4/3/21 9:48 AM, Sergei Trofimovich wrote: > Noticed failure as a crash on ia64 when tried to symbolize all > backtraces collected by page_owner=on: > > $ cat /sys/kernel/debug/page_owner > > > CPU: 1 PID: 2074 Comm: cat Not tainted 5.12.0-rc4 #226 > Hardware name: hp server rx3600, BIOS 04.03 04/08/2008 > ip is at dereference_module_function_descriptor+0x41/0x100 > > Crash happens at dereference_module_function_descriptor() due to > use-after-free when dereferencing ".opd" section header. > > All section headers are already freed after module is laoded > successfully. > > To keep symbolizer working the change stores ".opd" address > and size after module is relocated to a new place and before > section headers are discarded. > > To make similar errors less obscure module_finalize() now > zeroes out all variables relevant to module loading only. Typo: s/zeroes/zero/. 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] hpsa: fix boot on ia64 (atomic_t alignment)
Hi!
On 3/24/21 7:37 PM, don.br...@microchip.com wrote:
> -Original Message-
> From: Sergei Trofimovich [mailto:sly...@gentoo.org]
> Subject: [PATCH] hpsa: fix boot on ia64 (atomic_t alignment)
>
> The failure initially observed as boot failure on rx3600 ia64 machine with
> RAID bus controller: Hewlett-Packard Company Smart Array P600:
>
> kernel unaligned access to 0xe00105dd8b95, ip=0xa00100b87551
> kernel unaligned access to 0xe00105dd8e95, ip=0xa00100b87551
> hpsa :14:01.0: Controller reports max supported commands of 0 Using
> 16 instead. Ensure that firmware is up to date.
> swapper/0[1]: error during unaligned kernel access
>
> Here unaligned access comes from 'struct CommandList' that happens to be
> packed. The change f749d8b7a ("scsi: hpsa: Correct dev cmds outstanding for
> retried cmds") introduced unexpected padding and un-aligned atomic_t from
> natural alignment to something else.
>
> This change does not remove packing annotation from struct but only restores
> alignment of atomic variable.
>
> The change is tested on the same rx3600 machine.
>
> CC: linux-i...@vger.kernel.org
> CC: storage...@microchip.com
> CC: linux-s...@vger.kernel.org
> CC: Joe Szczypek
> CC: Scott Benesh
> CC: Scott Teel
> CC: Tomas Henzl
> CC: "Martin K. Petersen"
> CC: Don Brace
> Reported-by: John Paul Adrian Glaubitz
> Suggested-by: Don Brace
> Fixes: f749d8b7a "scsi: hpsa: Correct dev cmds outstanding for retried cmds"
> Signed-off-by: Sergei Trofimovich
> ---
> drivers/scsi/hpsa_cmd.h | 14 +-
> 1 file changed, 13 insertions(+), 1 deletion(-)
>
> diff --git a/drivers/scsi/hpsa_cmd.h b/drivers/scsi/hpsa_cmd.h index
> d126bb877250..617bdae9a7de 100644
> --- a/drivers/scsi/hpsa_cmd.h
> +++ b/drivers/scsi/hpsa_cmd.h
> @@ -20,6 +20,9 @@
> #ifndef HPSA_CMD_H
> #define HPSA_CMD_H
>
> +#include /* static_assert */ #include
> + /* offsetof */
> +
> /* general boundary defintions */
> #define SENSEINFOBYTES 32 /* may vary between hbas */
> #define SG_ENTRIES_IN_CMD 32 /* Max SG entries excluding chain blocks */
> @@ -448,11 +451,20 @@ struct CommandList {
> */
> struct hpsa_scsi_dev_t *phys_disk;
>
> - bool retry_pending;
> + int retry_pending;
> struct hpsa_scsi_dev_t *device;
> atomic_t refcount; /* Must be last to avoid memset in hpsa_cmd_init()
> */ } __aligned(COMMANDLIST_ALIGNMENT);
>
> +/*
> + * Make sure our embedded atomic variable is aligned. Otherwise we
> +break atomic
> + * operations on architectures that don't support unaligned atomics like
> IA64.
> + *
> + * Ideally this header should be cleaned up to only mark individual
> +structs as
> + * packed.
> + */
> +static_assert(offsetof(struct CommandList, refcount) %
> +__alignof__(atomic_t) == 0);
> +
> /* Max S/G elements in I/O accelerator command */
> #define IOACCEL1_MAXSGENTRIES 24
> #define IOACCEL2_MAXSGENTRIES 28
> --
> 2.30.2
>
>
> Acked-by: Don Brace
>
> Thanks for your patch and extra effort.
Apologies for being so persistent, but has this patch been queued anywhere?
This should be included for 5.12 if possible as it unbreaks the kernel on alot
of Itanium servers (and potentially other machines with the HPSA controller).
If no one wants to pick the patch up, it could go through Andrew Morton's tree
(-mm).
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: [PATCH] tools: Remove duplicate definition of ia64_mf() on ia64
Hello!
On 3/23/21 7:25 PM, John Paul Adrian Glaubitz wrote:
> The ia64_mf() macro defined in tools/arch/ia64/include/asm/barrier.h
> is already defined in on ia64 which causes libbpf
> failing to build:
>
> CC /usr/src/linux/tools/bpf/bpftool//libbpf/staticobjs/libbpf.o
> In file included from /usr/src/linux/tools/include/asm/barrier.h:24,
> from /usr/src/linux/tools/include/linux/ring_buffer.h:4,
> from libbpf.c:37:
> /usr/src/linux/tools/include/asm/../../arch/ia64/include/asm/barrier.h:43:
> error: "ia64_mf" redefined [-Werror]
>43 | #define ia64_mf() asm volatile ("mf" ::: "memory")
> |
> In file included from /usr/include/ia64-linux-gnu/asm/intrinsics.h:20,
> from /usr/include/ia64-linux-gnu/asm/swab.h:11,
> from /usr/include/linux/swab.h:8,
> from /usr/include/linux/byteorder/little_endian.h:13,
> from /usr/include/ia64-linux-gnu/asm/byteorder.h:5,
> from /usr/src/linux/tools/include/uapi/linux/perf_event.h:20,
> from libbpf.c:36:
> /usr/include/ia64-linux-gnu/asm/gcc_intrin.h:382: note: this is the location
> of the previous definition
> 382 | #define ia64_mf() __asm__ volatile ("mf" ::: "memory")
> |
> cc1: all warnings being treated as errors
>
> Thus, remove the definition from tools/arch/ia64/include/asm/barrier.h.
>
> Signed-off-by: John Paul Adrian Glaubitz
> ---
> tools/arch/ia64/include/asm/barrier.h | 3 ---
> 1 file changed, 3 deletions(-)
>
> diff --git a/tools/arch/ia64/include/asm/barrier.h
> b/tools/arch/ia64/include/asm/barrier.h
> index 4d471d9511a5..6fffe5682713 100644
> --- a/tools/arch/ia64/include/asm/barrier.h
> +++ b/tools/arch/ia64/include/asm/barrier.h
> @@ -39,9 +39,6 @@
> * sequential memory pages only.
> */
>
> -/* XXX From arch/ia64/include/uapi/asm/gcc_intrin.h */
> -#define ia64_mf() asm volatile ("mf" ::: "memory")
> -
> #define mb() ia64_mf()
> #define rmb()mb()
> #define wmb() mb()
>
Shall I ask Andrew Morton to pick up this patch? It's needed to fix the Debian
kernel build on ia64 and it would be great if it could be included for 5.12.
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, v2] tools: Remove inclusion of ia64-specific version of errno.h header
Hello!
On 3/23/21 7:04 PM, John Paul Adrian Glaubitz wrote:
> There is no longer an ia64-specific version of the errno.h header
> below arch/ia64/include/uapi/asm/, so trying to build tools/bpf
> fails with:
>
> CC /usr/src/linux/tools/bpf/bpftool/btf_dumper.o
> In file included from /usr/src/linux/tools/include/linux/err.h:8,
> from btf_dumper.c:11:
> /usr/src/linux/tools/include/uapi/asm/errno.h:13:10: fatal error:
> ../../../arch/ia64/include/uapi/asm/errno.h: No such file or directory
>13 | #include "../../../arch/ia64/include/uapi/asm/errno.h"
> | ^
> compilation terminated.
>
> Thus, just remove the inclusion of the ia64-specific errno.h so that
> the build will use the generic errno.h header on this target which was
> used there anyway as the ia64-specific errno.h was just a wrapper for
> the generic header.
>
> Fixes: c25f867ddd00 ("ia64: remove unneeded uapi asm-generic wrappers")
> Signed-off-by: John Paul Adrian Glaubitz
> ---
> tools/include/uapi/asm/errno.h | 2 --
> 1 file changed, 2 deletions(-)
>
> v2:
> - Rephrase summary
>
> diff --git a/tools/include/uapi/asm/errno.h b/tools/include/uapi/asm/errno.h
> index 637189ec1ab9..d30439b4b8ab 100644
> --- a/tools/include/uapi/asm/errno.h
> +++ b/tools/include/uapi/asm/errno.h
> @@ -9,8 +9,6 @@
> #include "../../../arch/alpha/include/uapi/asm/errno.h"
> #elif defined(__mips__)
> #include "../../../arch/mips/include/uapi/asm/errno.h"
> -#elif defined(__ia64__)
> -#include "../../../arch/ia64/include/uapi/asm/errno.h"
> #elif defined(__xtensa__)
> #include "../../../arch/xtensa/include/uapi/asm/errno.h"
> #else
>
Shall I ask Andrew Morton to pick up this patch? It's needed to fix the Debian
kernel build on ia64 and it would be great if it could be included for 5.12.
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] ia64: simplify code flow around swiotlb init
Hi Sergei!
On 3/26/21 12:35 AM, Sergei Trofimovich wrote:
> Before the change CONFIG_INTEL_IOMMU && !CONFIG_SWIOTLB && !CONFIG_FLATMEM
>
> could skip `set_max_mapnr(max_low_pfn);` is iommu is not present on system.
^^
typo s/is/if/
I will test this patch to make sure it doesn't break on the BL870c i4.
Adrian
> CC: Andrew Morton
> CC: linux-i...@vger.kernel.org
> Signed-off-by: Sergei Trofimovich
> ---
> arch/ia64/mm/init.c | 7 +--
> 1 file changed, 5 insertions(+), 2 deletions(-)
>
> diff --git a/arch/ia64/mm/init.c b/arch/ia64/mm/init.c
> index 16d0d7d22657..a63585db94fe 100644
> --- a/arch/ia64/mm/init.c
> +++ b/arch/ia64/mm/init.c
> @@ -644,13 +644,16 @@ mem_init (void)
>* _before_ any drivers that may need the PCI DMA interface are
>* initialized or bootmem has been freed.
>*/
> + do {
> #ifdef CONFIG_INTEL_IOMMU
> - detect_intel_iommu();
> - if (!iommu_detected)
> + detect_intel_iommu();
> + if (iommu_detected)
> + break;
> #endif
> #ifdef CONFIG_SWIOTLB
> swiotlb_init(1);
> #endif
> + } while (0);
>
> #ifdef CONFIG_FLATMEM
> BUG_ON(!mem_map);
>
--
.''`. 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] ia64: mca: allocate early mca with GFP_ATOMIC
Hi Andrew! On 3/24/21 11:39 PM, Andrew Morton wrote: > On Wed, 24 Mar 2021 11:20:45 +0100 John Paul Adrian Glaubitz > wrote: > >>>> #NEXT_PATCHES_START mainline-later (next week, approximately) >>>> ia64-mca-allocate-early-mca-with-gfp_atomic.patch >> >> Great, thanks. We're still missing Valentin's patch for the NUMA enumeration >> issue >> though. Should Valentin send the patch again with Andrew CC'ed? > > I subscribed to linux-ia64 today, so I can go in there to find things. Good to know, thanks. > But if there's anything presently outstanding, please do resend. > > I presently have > > module-remove-duplicate-include-in-arch-ia64-kernel-heads.patch > ia64-kernel-few-typos-fixed-in-the-file-fsyss.patch > ia64-include-asm-minor-typo-fixes-in-the-file-pgtableh.patch > ia64-ensure-proper-numa-distance-and-possible-map-initialization.patch > ia64-drop-unused-ia64_fw_emu-ifdef.patch I send two patches today which fix two ia64-related build issues in tools, not sure whether you should pick those as well or I should just wait for the maintainers that get_maintainers.pl report to answer. > https://marc.info/?l=linux-netdev=161652285123466=2 > https://marc.info/?l=linux-netdev=161652400124112=2 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: [PATCH] ia64: Ensure proper NUMA distance and possible map initialization
Hi!
On 3/24/21 7:54 PM, Andrew Morton wrote:
> On Thu, 18 Mar 2021 13:06:17 + Valentin Schneider
> wrote:
>
>> John Paul reported a warning about bogus NUMA distance values spurred by
>> commit:
>>
>> 620a6dc40754 ("sched/topology: Make sched_init_numa() use a set for the
>> deduplicating sort")
>>
>> In this case, the afflicted machine comes up with a reported 256 possible
>> nodes, all of which are 0 distance away from one another. This was
>> previously silently ignored, but is now caught by the aforementioned
>> commit.
>>
>> The culprit is ia64's node_possible_map which remains unchanged from its
>> initialization value of NODE_MASK_ALL. In John's case, the machine doesn't
>> have any SRAT nor SLIT table, but AIUI the possible map remains untouched
>> regardless of what ACPI tables end up being parsed. Thus, !online &&
>> possible nodes remain with a bogus distance of 0 (distances \in [0, 9] are
>> "reserved and have no meaning" as per the ACPI spec).
>>
>> Follow x86 / drivers/base/arch_numa's example and set the possible map to
>> the parsed map, which in this case seems to be the online map.
>>
>> Link:
>> http://lore.kernel.org/r/255d6b5d-194e-eb0e-ecdd-97477a534...@physik.fu-berlin.de
>> Fixes: 620a6dc40754 ("sched/topology: Make sched_init_numa() use a set for
>> the deduplicating sort")
>> Reported-by: John Paul Adrian Glaubitz
>> Signed-off-by: Valentin Schneider
>> ---
>> This might need an earlier Fixes: tag, but all of this is quite old and
>> dusty (the git blame rabbit hole leads me to ~2008/2007)
>>
>
> Thanks. Is this worth a cc:stable tag?
Looks like the regression was introduced 5.12-rc1, so no need for backporting.
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] ia64: mca: allocate early mca with GFP_ATOMIC
Hi Sergei!
On 3/23/21 6:47 PM, Sergei Trofimovich wrote:
> On Tue, 23 Mar 2021 16:15:06 +0100
> John Paul Adrian Glaubitz wrote:
>
>> Hi Andrew!
>>
>> On 3/15/21 9:50 AM, Sergei Trofimovich wrote:
>>> The sleep warning happens at early boot right at
>>> secondary CPU activation bootup:
>>>
>>> smp: Bringing up secondary CPUs ...
>>> BUG: sleeping function called from invalid context at
>>> mm/page_alloc.c:4942
>>> in_atomic(): 0, irqs_disabled(): 1, non_block: 0, pid: 0, name:
>>> swapper/1
>>> CPU: 1 PID: 0 Comm: swapper/1 Not tainted
>>> 5.12.0-rc2-7-g79e228d0b611-dirty #99
>>>
>>> Call Trace:
>>> [] show_stack+0x90/0xc0
>>> [] dump_stack+0x150/0x1c0
>>> [] ___might_sleep+0x1c0/0x2a0
>>> [] __might_sleep+0xa0/0x160
>>> [] __alloc_pages_nodemask+0x1a0/0x600
>>> [] alloc_page_interleave+0x30/0x1c0
>>> [] alloc_pages_current+0x2c0/0x340
>>> [] __get_free_pages+0x30/0xa0
>>> [] ia64_mca_cpu_init+0x2d0/0x3a0
>>> [] cpu_init+0x8b0/0x1440
>>> [] start_secondary+0x60/0x700
>>> [] start_ap+0x750/0x780
>>> Fixed BSP b0 value from CPU 1
>>>
>>> As I understand interrupts are not enabled yet and system has a lot
>>> of memory. There is little chance to sleep and switch to GFP_ATOMIC
>>> should be a no-op.
>>>
>>> CC: Andrew Morton
>>> CC: linux-i...@vger.kernel.org
>>> Signed-off-by: Sergei Trofimovich
>>> ---
>>> arch/ia64/kernel/mca.c | 2 +-
>>> 1 file changed, 1 insertion(+), 1 deletion(-)
>>>
>>> diff --git a/arch/ia64/kernel/mca.c b/arch/ia64/kernel/mca.c
>>> index d4cae2fc69ca..adf6521525f4 100644
>>> --- a/arch/ia64/kernel/mca.c
>>> +++ b/arch/ia64/kernel/mca.c
>>> @@ -1824,7 +1824,7 @@ ia64_mca_cpu_init(void *cpu_data)
>>> data = mca_bootmem();
>>> first_time = 0;
>>> } else
>>> - data = (void *)__get_free_pages(GFP_KERNEL,
>>> + data = (void *)__get_free_pages(GFP_ATOMIC,
>>> get_order(sz));
>>> if (!data)
>>> panic("Could not allocate MCA memory for cpu %d\n",
>>>
>>
>> Has this one been picked up for your tree already?
>
> Should be there: https://www.ozlabs.org/~akpm/mmotm/series
>
>> #NEXT_PATCHES_START mainline-later (next week, approximately)
>> ia64-mca-allocate-early-mca-with-gfp_atomic.patch
Great, thanks. We're still missing Valentin's patch for the NUMA enumeration
issue
though. Should Valentin send the patch again with Andrew CC'ed?
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] hpsa: fix boot on ia64 (atomic_t alignment)
Hello!
On 3/12/21 11:27 PM, Sergei Trofimovich wrote:
> The failure initially observed as boot failure on rx3600 ia64 machine
> with RAID bus controller: Hewlett-Packard Company Smart Array P600:
>
> kernel unaligned access to 0xe00105dd8b95, ip=0xa00100b87551
> kernel unaligned access to 0xe00105dd8e95, ip=0xa00100b87551
> hpsa :14:01.0: Controller reports max supported commands of 0 Using
> 16 instead. Ensure that firmware is up to date.
> swapper/0[1]: error during unaligned kernel access
>
> Here unaligned access comes from 'struct CommandList' that happens
> to be packed. The change f749d8b7a ("scsi: hpsa: Correct dev cmds
> outstanding for retried cmds") introduced unexpected padding and
> un-aligned atomic_t from natural alignment to something else.
>
> This change does not remove packing annotation from struct but only
> restores alignment of atomic variable.
>
> The change is tested on the same rx3600 machine.
>
> CC: linux-i...@vger.kernel.org
> CC: storage...@microchip.com
> CC: linux-s...@vger.kernel.org
> CC: Joe Szczypek
> CC: Scott Benesh
> CC: Scott Teel
> CC: Tomas Henzl
> CC: "Martin K. Petersen"
> CC: Don Brace
> Reported-by: John Paul Adrian Glaubitz
> Suggested-by: Don Brace
> Fixes: f749d8b7a "scsi: hpsa: Correct dev cmds outstanding for retried cmds"
> Signed-off-by: Sergei Trofimovich
> ---
> drivers/scsi/hpsa_cmd.h | 14 +-
> 1 file changed, 13 insertions(+), 1 deletion(-)
>
> diff --git a/drivers/scsi/hpsa_cmd.h b/drivers/scsi/hpsa_cmd.h
> index d126bb877250..617bdae9a7de 100644
> --- a/drivers/scsi/hpsa_cmd.h
> +++ b/drivers/scsi/hpsa_cmd.h
> @@ -20,6 +20,9 @@
> #ifndef HPSA_CMD_H
> #define HPSA_CMD_H
>
> +#include /* static_assert */
> +#include /* offsetof */
> +
> /* general boundary defintions */
> #define SENSEINFOBYTES 32 /* may vary between hbas */
> #define SG_ENTRIES_IN_CMD32 /* Max SG entries excluding chain blocks */
> @@ -448,11 +451,20 @@ struct CommandList {
>*/
> struct hpsa_scsi_dev_t *phys_disk;
>
> - bool retry_pending;
> + int retry_pending;
> struct hpsa_scsi_dev_t *device;
> atomic_t refcount; /* Must be last to avoid memset in hpsa_cmd_init() */
> } __aligned(COMMANDLIST_ALIGNMENT);
>
> +/*
> + * Make sure our embedded atomic variable is aligned. Otherwise we break
> atomic
> + * operations on architectures that don't support unaligned atomics like
> IA64.
> + *
> + * Ideally this header should be cleaned up to only mark individual structs
> as
> + * packed.
> + */
> +static_assert(offsetof(struct CommandList, refcount) % __alignof__(atomic_t)
> == 0);
> +
> /* Max S/G elements in I/O accelerator command */
> #define IOACCEL1_MAXSGENTRIES 24
> #define IOACCEL2_MAXSGENTRIES28
I'm seeing this issue as well and without the patch, the kernel won't boot on
multiple
ia64 servers. Is there anything that speaks against fixing this?
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
[PATCH] tools: Remove duplicate definition of ia64_mf() on ia64
The ia64_mf() macro defined in tools/arch/ia64/include/asm/barrier.h
is already defined in on ia64 which causes libbpf
failing to build:
CC /usr/src/linux/tools/bpf/bpftool//libbpf/staticobjs/libbpf.o
In file included from /usr/src/linux/tools/include/asm/barrier.h:24,
from /usr/src/linux/tools/include/linux/ring_buffer.h:4,
from libbpf.c:37:
/usr/src/linux/tools/include/asm/../../arch/ia64/include/asm/barrier.h:43:
error: "ia64_mf" redefined [-Werror]
43 | #define ia64_mf() asm volatile ("mf" ::: "memory")
|
In file included from /usr/include/ia64-linux-gnu/asm/intrinsics.h:20,
from /usr/include/ia64-linux-gnu/asm/swab.h:11,
from /usr/include/linux/swab.h:8,
from /usr/include/linux/byteorder/little_endian.h:13,
from /usr/include/ia64-linux-gnu/asm/byteorder.h:5,
from /usr/src/linux/tools/include/uapi/linux/perf_event.h:20,
from libbpf.c:36:
/usr/include/ia64-linux-gnu/asm/gcc_intrin.h:382: note: this is the location of
the previous definition
382 | #define ia64_mf() __asm__ volatile ("mf" ::: "memory")
|
cc1: all warnings being treated as errors
Thus, remove the definition from tools/arch/ia64/include/asm/barrier.h.
Signed-off-by: John Paul Adrian Glaubitz
---
tools/arch/ia64/include/asm/barrier.h | 3 ---
1 file changed, 3 deletions(-)
diff --git a/tools/arch/ia64/include/asm/barrier.h
b/tools/arch/ia64/include/asm/barrier.h
index 4d471d9511a5..6fffe5682713 100644
--- a/tools/arch/ia64/include/asm/barrier.h
+++ b/tools/arch/ia64/include/asm/barrier.h
@@ -39,9 +39,6 @@
* sequential memory pages only.
*/
-/* XXX From arch/ia64/include/uapi/asm/gcc_intrin.h */
-#define ia64_mf() asm volatile ("mf" ::: "memory")
-
#define mb() ia64_mf()
#define rmb() mb()
#define wmb() mb()
--
2.31.0
[PATCH, v2] tools: Remove inclusion of ia64-specific version of errno.h header
There is no longer an ia64-specific version of the errno.h header
below arch/ia64/include/uapi/asm/, so trying to build tools/bpf
fails with:
CC /usr/src/linux/tools/bpf/bpftool/btf_dumper.o
In file included from /usr/src/linux/tools/include/linux/err.h:8,
from btf_dumper.c:11:
/usr/src/linux/tools/include/uapi/asm/errno.h:13:10: fatal error:
../../../arch/ia64/include/uapi/asm/errno.h: No such file or directory
13 | #include "../../../arch/ia64/include/uapi/asm/errno.h"
| ^
compilation terminated.
Thus, just remove the inclusion of the ia64-specific errno.h so that
the build will use the generic errno.h header on this target which was
used there anyway as the ia64-specific errno.h was just a wrapper for
the generic header.
Fixes: c25f867ddd00 ("ia64: remove unneeded uapi asm-generic wrappers")
Signed-off-by: John Paul Adrian Glaubitz
---
tools/include/uapi/asm/errno.h | 2 --
1 file changed, 2 deletions(-)
v2:
- Rephrase summary
diff --git a/tools/include/uapi/asm/errno.h b/tools/include/uapi/asm/errno.h
index 637189ec1ab9..d30439b4b8ab 100644
--- a/tools/include/uapi/asm/errno.h
+++ b/tools/include/uapi/asm/errno.h
@@ -9,8 +9,6 @@
#include "../../../arch/alpha/include/uapi/asm/errno.h"
#elif defined(__mips__)
#include "../../../arch/mips/include/uapi/asm/errno.h"
-#elif defined(__ia64__)
-#include "../../../arch/ia64/include/uapi/asm/errno.h"
#elif defined(__xtensa__)
#include "../../../arch/xtensa/include/uapi/asm/errno.h"
#else
--
2.31.0
[PATCH] tools: Remove ia64-specific errno.h inclusion from errno.h header
There is no longer an ia64-specific version of the errno.h header
below arch/ia64/include/uapi/asm/, so trying to build tools/bpf
fails with:
CC /usr/src/linux/tools/bpf/bpftool/btf_dumper.o
In file included from /usr/src/linux/tools/include/linux/err.h:8,
from btf_dumper.c:11:
/usr/src/linux/tools/include/uapi/asm/errno.h:13:10: fatal error:
../../../arch/ia64/include/uapi/asm/errno.h: No such file or directory
13 | #include "../../../arch/ia64/include/uapi/asm/errno.h"
| ^
compilation terminated.
Thus, just remove the inclusion of the ia64-specific errno.h so that
the build will use the generic errno.h header on this target which was
used there anyway as the ia64-specific errno.h was just a wrapper for
the generic header.
Fixes: c25f867ddd00 ("ia64: remove unneeded uapi asm-generic wrappers")
Signed-off-by: John Paul Adrian Glaubitz
---
tools/include/uapi/asm/errno.h | 2 --
1 file changed, 2 deletions(-)
diff --git a/tools/include/uapi/asm/errno.h b/tools/include/uapi/asm/errno.h
index 637189ec1ab9..d30439b4b8ab 100644
--- a/tools/include/uapi/asm/errno.h
+++ b/tools/include/uapi/asm/errno.h
@@ -9,8 +9,6 @@
#include "../../../arch/alpha/include/uapi/asm/errno.h"
#elif defined(__mips__)
#include "../../../arch/mips/include/uapi/asm/errno.h"
-#elif defined(__ia64__)
-#include "../../../arch/ia64/include/uapi/asm/errno.h"
#elif defined(__xtensa__)
#include "../../../arch/xtensa/include/uapi/asm/errno.h"
#else
--
2.31.0
[PATCH] tools: Remove ia64-specific errno.h inclusion from errno.h header
There is no longer an ia64-specific version of the errno.h header
below arch/ia64/include/uapi/asm/, so trying to build tools/bpf
fails with:
CC /usr/src/linux/tools/bpf/bpftool/btf_dumper.o
In file included from /usr/src/linux/tools/include/linux/err.h:8,
from btf_dumper.c:11:
/usr/src/linux/tools/include/uapi/asm/errno.h:13:10: fatal error:
../../../arch/ia64/include/uapi/asm/errno.h: No such file or directory
13 | #include "../../../arch/ia64/include/uapi/asm/errno.h"
| ^
compilation terminated.
Thus, just remove the inclusion of the ia64-specific errno.h so that
the build will use the generic errno.h header on this target which was
used there anyway as the ia64-specific errno.h was just a wrapper for
the generic header.
Fixes: c25f867ddd00 ("ia64: remove unneeded uapi asm-generic wrappers")
Signed-off-by: John Paul Adrian Glaubitz
---
tools/include/uapi/asm/errno.h | 2 --
1 file changed, 2 deletions(-)
diff --git a/tools/include/uapi/asm/errno.h b/tools/include/uapi/asm/errno.h
index 637189ec1ab9..d30439b4b8ab 100644
--- a/tools/include/uapi/asm/errno.h
+++ b/tools/include/uapi/asm/errno.h
@@ -9,8 +9,6 @@
#include "../../../arch/alpha/include/uapi/asm/errno.h"
#elif defined(__mips__)
#include "../../../arch/mips/include/uapi/asm/errno.h"
-#elif defined(__ia64__)
-#include "../../../arch/ia64/include/uapi/asm/errno.h"
#elif defined(__xtensa__)
#include "../../../arch/xtensa/include/uapi/asm/errno.h"
#else
--
2.31.0
Re: [PATCH] ia64: mca: allocate early mca with GFP_ATOMIC
Hi Andrew!
On 3/15/21 9:50 AM, Sergei Trofimovich wrote:
> The sleep warning happens at early boot right at
> secondary CPU activation bootup:
>
> smp: Bringing up secondary CPUs ...
> BUG: sleeping function called from invalid context at mm/page_alloc.c:4942
> in_atomic(): 0, irqs_disabled(): 1, non_block: 0, pid: 0, name: swapper/1
> CPU: 1 PID: 0 Comm: swapper/1 Not tainted
> 5.12.0-rc2-7-g79e228d0b611-dirty #99
>
> Call Trace:
> [] show_stack+0x90/0xc0
> [] dump_stack+0x150/0x1c0
> [] ___might_sleep+0x1c0/0x2a0
> [] __might_sleep+0xa0/0x160
> [] __alloc_pages_nodemask+0x1a0/0x600
> [] alloc_page_interleave+0x30/0x1c0
> [] alloc_pages_current+0x2c0/0x340
> [] __get_free_pages+0x30/0xa0
> [] ia64_mca_cpu_init+0x2d0/0x3a0
> [] cpu_init+0x8b0/0x1440
> [] start_secondary+0x60/0x700
> [] start_ap+0x750/0x780
> Fixed BSP b0 value from CPU 1
>
> As I understand interrupts are not enabled yet and system has a lot
> of memory. There is little chance to sleep and switch to GFP_ATOMIC
> should be a no-op.
>
> CC: Andrew Morton
> CC: linux-i...@vger.kernel.org
> Signed-off-by: Sergei Trofimovich
> ---
> arch/ia64/kernel/mca.c | 2 +-
> 1 file changed, 1 insertion(+), 1 deletion(-)
>
> diff --git a/arch/ia64/kernel/mca.c b/arch/ia64/kernel/mca.c
> index d4cae2fc69ca..adf6521525f4 100644
> --- a/arch/ia64/kernel/mca.c
> +++ b/arch/ia64/kernel/mca.c
> @@ -1824,7 +1824,7 @@ ia64_mca_cpu_init(void *cpu_data)
> data = mca_bootmem();
> first_time = 0;
> } else
> - data = (void *)__get_free_pages(GFP_KERNEL,
> + data = (void *)__get_free_pages(GFP_ATOMIC,
> get_order(sz));
> if (!data)
> panic("Could not allocate MCA memory for cpu %d\n",
>
Has this one been picked up for your tree already?
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: [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] ia64: Ensure proper NUMA distance and possible map initialization
On 3/19/21 8:10 PM, Sergei Trofimovich wrote:
> On Fri, 19 Mar 2021 15:47:09 +0100
> John Paul Adrian Glaubitz wrote:
>
>> Hi Valentin!
>>
>> On 3/18/21 2:06 PM, Valentin Schneider wrote:
>>> John Paul reported a warning about bogus NUMA distance values spurred by
>>> commit:
>>>
>>> 620a6dc40754 ("sched/topology: Make sched_init_numa() use a set for the
>>> deduplicating sort")
>>>
>>> In this case, the afflicted machine comes up with a reported 256 possible
>>> nodes, all of which are 0 distance away from one another. This was
>>> previously silently ignored, but is now caught by the aforementioned
>>> commit.
>>>
>>> The culprit is ia64's node_possible_map which remains unchanged from its
>>> initialization value of NODE_MASK_ALL. In John's case, the machine doesn't
>>> have any SRAT nor SLIT table, but AIUI the possible map remains untouched
>>> regardless of what ACPI tables end up being parsed. Thus, !online &&
>>> possible nodes remain with a bogus distance of 0 (distances \in [0, 9] are
>>> "reserved and have no meaning" as per the ACPI spec).
>>>
>>> Follow x86 / drivers/base/arch_numa's example and set the possible map to
>>> the parsed map, which in this case seems to be the online map.
>>>
>>> Link:
>>> http://lore.kernel.org/r/255d6b5d-194e-eb0e-ecdd-97477a534...@physik.fu-berlin.de
>>> Fixes: 620a6dc40754 ("sched/topology: Make sched_init_numa() use a set for
>>> the deduplicating sort")
>>> Reported-by: John Paul Adrian Glaubitz
>>> Signed-off-by: Valentin Schneider
>>> ---
>>> This might need an earlier Fixes: tag, but all of this is quite old and
>>> dusty (the git blame rabbit hole leads me to ~2008/2007)
>>>
>>> Alternatively, can we deprecate ia64 already?
>>> ---
>>> arch/ia64/kernel/acpi.c | 7 +--
>>> 1 file changed, 5 insertions(+), 2 deletions(-)
>>>
>>> diff --git a/arch/ia64/kernel/acpi.c b/arch/ia64/kernel/acpi.c
>>> index a5636524af76..e2af6b172200 100644
>>> --- a/arch/ia64/kernel/acpi.c
>>> +++ b/arch/ia64/kernel/acpi.c
>>> @@ -446,7 +446,8 @@ void __init acpi_numa_fixup(void)
>>> if (srat_num_cpus == 0) {
>>> node_set_online(0);
>>> node_cpuid[0].phys_id = hard_smp_processor_id();
>>> - return;
>>> + slit_distance(0, 0) = LOCAL_DISTANCE;
>>> + goto out;
>>> }
>>>
>>> /*
>>> @@ -489,7 +490,7 @@ void __init acpi_numa_fixup(void)
>>> for (j = 0; j < MAX_NUMNODES; j++)
>>> slit_distance(i, j) = i == j ?
>>> LOCAL_DISTANCE : REMOTE_DISTANCE;
>>> - return;
>>> + goto out;
>>> }
>>>
>>> memset(numa_slit, -1, sizeof(numa_slit));
>>> @@ -514,6 +515,8 @@ void __init acpi_numa_fixup(void)
>>> printk("\n");
>>> }
>>> #endif
>>> +out:
>>> + node_possible_map = node_online_map;
>>> }
>>> #endif /* CONFIG_ACPI_NUMA */
>>>
>>>
>>
>> Tested-by: John Paul Adrian Glaubitz
>>
>> Could you send this patch through Andrew Morton's tree? The ia64 port
>> currently
>> has no maintainer, so we have to use an alternative tree.
>>
>> @Sergei: Could you test/ack this patch as well?
>
> Booted successfully without problems on rx3600.
>
> Tested-by: Sergei Trofimovich
Great, thanks!
@Andrew: Could you pick up this patch through your tree?
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] IA64: Trivial spelling fixes
Hi Bhaskar! On 3/20/21 7:23 PM, Bhaskar Chowdhury wrote: > > s/seralize/serialize/ .three different places > > Signed-off-by: Bhaskar Chowdhury > --- > arch/ia64/kernel/pal.S | 6 +++--- > 1 file changed, 3 insertions(+), 3 deletions(-) > > diff --git a/arch/ia64/kernel/pal.S b/arch/ia64/kernel/pal.S > index d3e22c018b68..06d01a070aae 100644 > --- a/arch/ia64/kernel/pal.S > +++ b/arch/ia64/kernel/pal.S > @@ -86,7 +86,7 @@ GLOBAL_ENTRY(ia64_pal_call_static) > mov ar.pfs = loc1 > mov rp = loc0 > ;; > - srlz.d // seralize restoration of psr.l > + srlz.d // serialize restoration of psr.l > br.ret.sptk.many b0 > END(ia64_pal_call_static) > EXPORT_SYMBOL(ia64_pal_call_static) > @@ -194,7 +194,7 @@ GLOBAL_ENTRY(ia64_pal_call_phys_static) > mov rp = loc0 > ;; > mov ar.rsc=loc4 // restore RSE configuration > - srlz.d // seralize restoration of psr.l > + srlz.d // serialize restoration of psr.l > br.ret.sptk.many b0 > END(ia64_pal_call_phys_static) > EXPORT_SYMBOL(ia64_pal_call_phys_static) > @@ -252,7 +252,7 @@ GLOBAL_ENTRY(ia64_pal_call_phys_stacked) > mov rp = loc0 > ;; > mov ar.rsc=loc4 // restore RSE configuration > - srlz.d // seralize restoration of psr.l > + srlz.d // serialize restoration of psr.l > br.ret.sptk.many b0 > END(ia64_pal_call_phys_stacked) > EXPORT_SYMBOL(ia64_pal_call_phys_stacked) > -- > 2.26.2 Thanks for fixing this. Btw, we usually use all-lowercase letters for architecture names in the Linux kernel, so it should probably be "ia64: Trivial spelling fixes". And the easiest way to get those fixes into the kernel would be through Andrew Morton's tree. 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] ia64: Ensure proper NUMA distance and possible map initialization
Hi Valentin!
On 3/18/21 2:06 PM, Valentin Schneider wrote:
> John Paul reported a warning about bogus NUMA distance values spurred by
> commit:
>
> 620a6dc40754 ("sched/topology: Make sched_init_numa() use a set for the
> deduplicating sort")
>
> In this case, the afflicted machine comes up with a reported 256 possible
> nodes, all of which are 0 distance away from one another. This was
> previously silently ignored, but is now caught by the aforementioned
> commit.
>
> The culprit is ia64's node_possible_map which remains unchanged from its
> initialization value of NODE_MASK_ALL. In John's case, the machine doesn't
> have any SRAT nor SLIT table, but AIUI the possible map remains untouched
> regardless of what ACPI tables end up being parsed. Thus, !online &&
> possible nodes remain with a bogus distance of 0 (distances \in [0, 9] are
> "reserved and have no meaning" as per the ACPI spec).
>
> Follow x86 / drivers/base/arch_numa's example and set the possible map to
> the parsed map, which in this case seems to be the online map.
>
> Link:
> http://lore.kernel.org/r/255d6b5d-194e-eb0e-ecdd-97477a534...@physik.fu-berlin.de
> Fixes: 620a6dc40754 ("sched/topology: Make sched_init_numa() use a set for
> the deduplicating sort")
> Reported-by: John Paul Adrian Glaubitz
> Signed-off-by: Valentin Schneider
> ---
> This might need an earlier Fixes: tag, but all of this is quite old and
> dusty (the git blame rabbit hole leads me to ~2008/2007)
>
> Alternatively, can we deprecate ia64 already?
> ---
> arch/ia64/kernel/acpi.c | 7 +--
> 1 file changed, 5 insertions(+), 2 deletions(-)
>
> diff --git a/arch/ia64/kernel/acpi.c b/arch/ia64/kernel/acpi.c
> index a5636524af76..e2af6b172200 100644
> --- a/arch/ia64/kernel/acpi.c
> +++ b/arch/ia64/kernel/acpi.c
> @@ -446,7 +446,8 @@ void __init acpi_numa_fixup(void)
> if (srat_num_cpus == 0) {
> node_set_online(0);
> node_cpuid[0].phys_id = hard_smp_processor_id();
> - return;
> + slit_distance(0, 0) = LOCAL_DISTANCE;
> + goto out;
> }
>
> /*
> @@ -489,7 +490,7 @@ void __init acpi_numa_fixup(void)
> for (j = 0; j < MAX_NUMNODES; j++)
> slit_distance(i, j) = i == j ?
> LOCAL_DISTANCE : REMOTE_DISTANCE;
> - return;
> + goto out;
> }
>
> memset(numa_slit, -1, sizeof(numa_slit));
> @@ -514,6 +515,8 @@ void __init acpi_numa_fixup(void)
> printk("\n");
> }
> #endif
> +out:
> + node_possible_map = node_online_map;
> }
> #endif /* CONFIG_ACPI_NUMA */
>
>
Tested-by: John Paul Adrian Glaubitz
Could you send this patch through Andrew Morton's tree? The ia64 port currently
has no maintainer, so we have to use an alternative tree.
@Sergei: Could you test/ack this patch as well?
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: sparc: clang: error: unknown argument: '-mno-fpu'
On 3/19/21 12:56 PM, Arnd Bergmann wrote: >> We'll get there. There are some other SPARC-related clang bugs that need >> to be squashed first. We have made quite some improvements and it's actually >> maintained by the community. Of course, we don't have a commercial backer >> but that shouldn't be necessary for open source to work. > > I meant there is no point for Naresh to do it as part of his build > testing with tuxmake. > If someone else gets it working, they can tell Naresh to try again, but until > then, I'd limit clang regression testing to x86, arm, powerpc, s390, mips, > riscv > and arc. It's definitely a useful report as I haven't done any tests in this regard yet and we're certainly interested in getting this to work. We previously had Nick give a session on building the kernel with clang in our monthly m68k meeting [1] and he said, they are interested in supporting as many architectures as possible in their efforts. Adrian > [1] http://m68k.info/#llvm:linux:video -- .''`. 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: sparc: clang: error: unknown argument: '-mno-fpu'
On 3/19/21 12:31 PM, Arnd Bergmann wrote: > On Fri, Mar 19, 2021 at 8:36 AM Naresh Kamboju > wrote: >> >> Linux mainline master build breaks for sparc defconfig. >> There are multiple errors / warnings with clang-12 and clang-11 and 10. >> - sparc (defconfig) with clang-12, clang-11 and clang-10 >> - sparc (tinyconfig) with clang-12, clang-11 and clang-10 >> - sparc (allnoconfig) with clang-12, clang-11 and clang-10 >> >> make --silent --keep-going --jobs=8 >> O=/home/tuxbuild/.cache/tuxmake/builds/1/tmp ARCH=sparc >> CROSS_COMPILE=sparc64-linux-gnu- 'HOSTCC=sccache clang' 'CC=sccache >> clang' > > I don't think anyone has successfully built a sparc kernel with clang, > and I don't > think it's worth trying either, given how little upstream work the > sparc port sees > overall. We'll get there. There are some other SPARC-related clang bugs that need to be squashed first. We have made quite some improvements and it's actually maintained by the community. Of course, we don't have a commercial backer but that shouldn't be necessary for open source to work. 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 0/1] sched/topology: NUMA distance deduplication
Hello! On 3/18/21 12:26 AM, John Paul Adrian Glaubitz wrote: >> b) do anything? > > It fixes the problem for me. Here are the kernel messages with your patch applied: [0.00] Linux version 5.12.0-rc3+ (glaubitz@epyc) (ia64-linux-gcc (GCC) 10.1.0, GNU ld (GNU Binutils) 2.34) #207 SMP Thu Mar 18 09:50:43 CET 2021 [0.00] efi: EFI v2.00 by HP [0.00] efi: SALsystab=0x3ee7a000 ACPI 2.0=0x3fde4000 ESI=0x3ee7b000 SMBIOS=0x3ee7c000 HCDP=0x3fde2000 [0.00] PCDP: v3 at 0x3fde2000 [0.00] earlycon: uart8250 at MMIO 0x88033000 (options '115200n8') [0.00] printk: bootconsole [uart8250] enabled [0.00] ACPI: Early table checksum verification disabled [0.00] ACPI: RSDP 0x3FDE4000 28 (v02 HP) [0.00] ACPI: XSDT 0x3FDE402C A4 (v01 HP rx2660 HP ) [0.00] ACPI: FACP 0x3FDF6A08 F4 (v03 HP rx2660 HP ) [0.00] ACPI: DSDT 0x3FDE41C8 00E566 (v01 HP rx2660 0007 INTL 20050309) [0.00] ACPI: FACS 0x3FDF6B00 40 [0.00] ACPI: SPCR 0x3FDF6B40 50 (v01 HP HP ) [0.00] ACPI: DBGP 0x3FDF6B90 34 (v01 HP rx2660 HP ) [0.00] ACPI: APIC 0x3FDF6FB0 C8 (v01 HP rx2660 HP ) [0.00] ACPI: SPMI 0x3FDF6BC8 50 (v04 HP rx2660 HP ) [0.00] ACPI: CPEP 0x3FDF6E80 34 (v01 HP rx2660 HP ) [0.00] ACPI: SSDT 0x3FDF2738 0004B3 (v01 HP rx2660 0006 INTL 20050309) [0.00] ACPI: SSDT 0x3FDF2BF8 000456 (v01 HP rx2660 0006 INTL 20050309) [0.00] ACPI: SSDT 0x3FDF3058 000EB8 (v01 HP rx2660 0006 INTL 20050309) [0.00] ACPI: SSDT 0x3FDF3F18 000EB8 (v01 HP rx2660 0006 INTL 20050309) [0.00] ACPI: SSDT 0x3FDF4DD8 000866 (v01 HP rx2660 0006 INTL 20050309) [0.00] ACPI: SSDT 0x3FDF5648 000EB8 (v01 HP rx2660 0006 INTL 20050309) [0.00] ACPI: SSDT 0x3FDF6508 000138 (v01 HP rx2660 0006 INTL 20050309) [0.00] ACPI: SSDT 0x3FDF6648 00013C (v01 HP rx2660 0006 INTL 20050309) [0.00] ACPI: SSDT 0x3FDF6788 00013C (v01 HP rx2660 0006 INTL 20050309) [0.00] ACPI: SSDT 0x3FDF68C8 00013C (v01 HP rx2660 0006 INTL 20050309) [0.00] ACPI: Local APIC address (ptrval) [0.00] 4 CPUs available, 4 CPUs total [0.00] SMP: Allowing 4 CPUs, 0 hotplug CPUs [0.00] Initial ramdisk at: 0xe0002d52b000 (24744716 bytes) [0.00] SAL 3.20: HP version 4.4 [0.00] SAL Platform features: [0.00] None [0.00] SAL: AP wakeup using external interrupt vector 0xff [0.00] MCA related initialization done [0.00] Zone ranges: [0.00] DMA32[mem 0x0100-0x] [0.00] Normal [mem 0x0001-0x01007fff] [0.00] Movable zone start for each node [0.00] Early memory node ranges [0.00] node 0: [mem 0x0100-0x3e67] [0.00] node 0: [mem 0x3eaec000-0x3ee77fff] [0.00] node 0: [mem 0x3fc0-0x3fd77fff] [0.00] node 0: [mem 0x3fddc000-0x3fdd] [0.00] node 0: [mem 0x01004000-0x01007f1fbfff] [0.00] node 0: [mem 0x01007f20-0x01007fff] [0.00] Initmem setup node 0 [mem 0x0100-0x01007fff] [0.00] On node 0 totalpages: 128737 [0.00] DMA32 zone: 247 pages used for memmap [0.00] DMA32 zone: 0 pages reserved [0.00] DMA32 zone: 63202 pages, LIFO batch:15 [0.00] DMA32 zone: 2334 pages in unavailable ranges [0.00] Normal zone: 256 pages used for memmap [0.00] Normal zone: 65535 pages, LIFO batch:15 [0.00] Normal zone: 1 pages in unavailable ranges [0.00] pcpu-alloc: s33176 r8192 d220776 u262144 alloc=16*16384 [0.00] pcpu-alloc: [0] 0 [0] 1 [0] 2 [0] 3 [0.00] Built 1 zonelists, mobility grouping on. Total pages: 128234 [0.00] Policy zone: Normal [0.00] Kernel command line: BOOT_IMAGE=/boot/vmlinuz-5.12.0-rc3+ root=UUID=0c24a3da-2673-4901-b95b-d5adf2643b67 ro [0.00] Dentry cache hash table entries: 262144 (order: 7, 2097152 bytes, linear) [0.00] Inode-cache hash table entries: 131072 (order: 6, 1048576 bytes, linear) [0.00] Sorting __ex_table... [0.00] mem auto-init: stack:off, heap alloc:off, heap free:off [0.00] software IO TLB: mapped [mem 0x3a68-0x3e68] (64MB) [0.00] Memo
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 0/1] sched/topology: NUMA distance deduplication
Hi Sergei! On 3/17/21 10:14 PM, Sergei Trofimovich wrote: > Or is it just an early bootstrap message assuming more are to come? > > Could it be that we initialize too little of generic acpi boilerplace > when there is no SRAT? Somewhere around: > > > https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/tree/arch/ia64/kernel/acpi.c#n446 > > arm64 and riscv calls `arch_numa_init()` and initializes numa node > data in numa_init(). > While ia64 only calls acpi_numa_init() but not arch_acpi_numa_init() > (which would do numa_init() for us). > > x86 seems to vaguely resemble generic code by duplicating numa_init(). > > (UNTESTED) Could it be that we need something like: > > --- a/arch/ia64/kernel/setup.c > +++ b/arch/ia64/kernel/setup.c > @@ -571,7 +571,7 @@ setup_arch (char **cmdline_p) > acpi_table_init(); > early_acpi_boot_init(); > #ifdef CONFIG_ACPI_NUMA > - acpi_numa_init(); > + arch_numa_init(); > acpi_numa_fixup(); > #ifdef CONFIG_ACPI_HOTPLUG_CPU > prefill_possible_map(); That doesn't build: CALLscripts/atomic/check-atomics.sh CALLscripts/checksyscalls.sh :1511:2: warning: #warning syscall clone3 not implemented [-Wcpp] CHK include/generated/compile.h CC arch/ia64/kernel/setup.o CC arch/ia64/kernel/acpi.o arch/ia64/kernel/setup.c: In function 'setup_arch': arch/ia64/kernel/setup.c:574:2: error: implicit declaration of function 'arch_numa_init'; did you mean 'acpi_numa_init'? [-Werror=implicit-function-declaration] 574 | arch_numa_init(); | ^~ | acpi_numa_init cc1: some warnings being treated as errors make[1]: *** [scripts/Makefile.build:271: arch/ia64/kernel/setup.o] Error 1 make[1]: *** Waiting for unfinished jobs.... make: *** [Makefile:1851: arch/ia64/kernel] Error 2 -- .''`. John Paul Adrian Glaubitz : :' : Debian Developer - glaub...@debian.org `. `' Freie Universitaet Berlin - glaub...@physik.fu-berlin.de `-GPG: 62FF 8A75 84E0 2956 9546 0006 7426 3B37 F5B5 F913
Re: [PATCH 0/1] sched/topology: NUMA distance deduplication
Hi Valentin! On 3/17/21 9:56 PM, Valentin Schneider wrote: > On 17/03/21 20:04, Valentin Schneider wrote: >> Technically it *is* coping with it, it's just dumping the entire NUMA >> distance matrix in the process... Let me see if I can't figure out why your >> system doesn't end up with nr_node_ids=1. >> > > Does the below > a) compile Yes. > b) do anything? It fixes the problem for me. Will test Sergei's patch now. Adrian -- .''`. John Paul Adrian Glaubitz : :' : Debian Developer - glaub...@debian.org `. `' Freie Universitaet Berlin - glaub...@physik.fu-berlin.de `-GPG: 62FF 8A75 84E0 2956 9546 0006 7426 3B37 F5B5 F913
Re: [PATCH 0/1] sched/topology: NUMA distance deduplication
Helo Valentin! On 3/17/21 8:36 PM, Valentin Schneider wrote: > I see ACPI in your boot logs, so I'm guessing you have a bogus SLIT table > (the ACPI table with node distances). You should be able to double check > this with something like: > > $ acpidump > acpi.dump > $ acpixtract -a acpi.dump > $ iasl -d *.dat > $ cat slit.dsl There does not seem to be a SLIT table in my firmware: root@glendronach:~# acpidump > acpi.dump root@glendronach:~# acpixtract -a acpi.dump Intel ACPI Component Architecture ACPI Binary Table Extraction Utility version 20200925 Copyright (c) 2000 - 2020 Intel Corporation acpixtract(31194): unaligned access to 0x6f9b3925, ip=0x40003e91 SSDT -3768 bytes written (0x0EB8) - ssdt1.dat acpixtract(31194): unaligned access to 0x6f9b3925, ip=0x40003e00 acpixtract(31194): unaligned access to 0x6f9b3925, ip=0x40003e91 SPCR - 80 bytes written (0x0050) - spcr.dat acpixtract(31194): unaligned access to 0x6f9b3925, ip=0x40003e00 acpixtract(31194): unaligned access to 0x6f9b3925, ip=0x40003e91 APIC - 200 bytes written (0x00C8) - apic.dat SSDT -1110 bytes written (0x0456) - ssdt2.dat SSDT - 316 bytes written (0x013C) - ssdt3.dat SPMI - 80 bytes written (0x0050) - spmi.dat DSDT - 58726 bytes written (0xE566) - dsdt.dat SSDT - 312 bytes written (0x0138) - ssdt4.dat SSDT -2150 bytes written (0x0866) - ssdt5.dat SSDT - 316 bytes written (0x013C) - ssdt6.dat SSDT -3768 bytes written (0x0EB8) - ssdt7.dat FACP - 244 bytes written (0x00F4) - facp.dat SSDT -1203 bytes written (0x04B3) - ssdt8.dat CPEP - 52 bytes written (0x0034) - cpep.dat SSDT - 316 bytes written (0x013C) - ssdt9.dat DBGP - 52 bytes written (0x0034) - dbgp.dat SSDT -3768 bytes written (0x0EB8) - ssdt10.dat FACS - 64 bytes written (0x0040) - facs.dat root@glendronach:~# root@glendronach:~# ls *.dsl *.dat apic.dat cpep.dsl dsdt.dat facp.dsl spcr.dat spmi.dslssdt1.dat ssdt2.dsl ssdt4.dat ssdt5.dsl ssdt7.dat ssdt8.dsl apic.dsl dbgp.dat dsdt.dsl facs.dat spcr.dsl ssdt10.dat ssdt1.dsl ssdt3.dat ssdt4.dsl ssdt6.dat ssdt7.dsl ssdt9.dat cpep.dat dbgp.dsl facp.dat facs.dsl spmi.dat ssdt10.dsl ssdt2.dat ssdt3.dsl ssdt5.dat ssdt6.dsl ssdt8.dat ssdt9.dsl root@glendronach:~# > a) Complain to your hardware vendor to have them fix the table and ship a >firmware fix The hardware is probably too old for the vendor to care about fixing it. > b) Fix the ACPI table yourself - I've been told it's doable for *some* of >them, but I've never done that myself > c) Compile your kernel with CONFIG_NUMA=n, as AFAICT you only actually have >a single node > d) Ignore the warning > > > c) is clearly not ideal if you want to use a somewhat generic kernel image > on a wide host of machines; d) is also a bit yucky... Shouldn't the kernel be able to cope with quirky hardware? From what I remember in the past, ACPI tables used to be broken quite a lot and the kernel contained workarounds for such cases, didn't 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: 5.11 regression: "ia64: add support for TIF_NOTIFY_SIGNAL" breaks ia64 boot
Hi! On 3/17/21 6:42 PM, John Paul Adrian Glaubitz wrote: >> Here are dmesg and config from my machine with successfull boot: >> https://dev.gentoo.org/~slyfox/configs/guppy-dmesg-5.11 >> https://dev.gentoo.org/~slyfox/configs/guppy-config-5.11 > > Just gave it a try using this kernel configuration. It's never loading the > hpsa > module for me which I find really strange. The module isn't even showing up in > the kernel message buffer. Never mind. I just forgot to create an initrd this time, user error :-). Works again. >>> [0.036000] ERROR: Invalid distance value range >>> >>> [0.036000] >>> >>> [0.036000] 00 00 00 00 00 00 >> >> I don't see this string in the 5.11 kernel source. But >> >> https://lore.kernel.org/lkml/161356785681.20312.13022545187499987936.tip-bot2@tip-bot2/T/ >> hints it's might be something very new and you are in the >> middle of 5.12-rc1? > > I'm seeing this using your exact kernel configuration. This issue is still there, however. Do you see this 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: 5.11 regression: "ia64: add support for TIF_NOTIFY_SIGNAL" breaks ia64 boot
Hi! On 2/23/21 8:27 PM, Sergei Trofimovich wrote: >>> Just gave it a try and it still doesn't work. >> >> Maybe your other two patches to fix the strace issues are required as well? > > I'd say it's very unlikely they have any effect here. AFAIU they only amend > ptrace() behaviour called from userspace. Failure to boot so early is probably > way before any userspace. > >> Or do you happen to have more patches in the Gentoo kernel? > > Nope. It was a vanilla 5.11 release with 3 patches: 1 signal fix and > 2 ptrace() patches. > > Here are dmesg and config from my machine with successfull boot: > https://dev.gentoo.org/~slyfox/configs/guppy-dmesg-5.11 > https://dev.gentoo.org/~slyfox/configs/guppy-config-5.11 Just gave it a try using this kernel configuration. It's never loading the hpsa module for me which I find really strange. The module isn't even showing up in the kernel message buffer. >> [0.036000] ERROR: Invalid distance value range >> >> [0.036000] >> >> [0.036000] 00 00 00 00 00 00 > > I don't see this string in the 5.11 kernel source. But > > https://lore.kernel.org/lkml/161356785681.20312.13022545187499987936.tip-bot2@tip-bot2/T/ > hints it's might be something very new and you are in the > middle of 5.12-rc1? I'm seeing this using your exact kernel configuration. 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] hpsa: fix boot on ia64 (atomic_t alignment)
Hi Sergei!
On 3/12/21 11:27 PM, Sergei Trofimovich wrote:
> The failure initially observed as boot failure on rx3600 ia64 machine
> with RAID bus controller: Hewlett-Packard Company Smart Array P600:
>
> kernel unaligned access to 0xe00105dd8b95, ip=0xa00100b87551
> kernel unaligned access to 0xe00105dd8e95, ip=0xa00100b87551
> hpsa :14:01.0: Controller reports max supported commands of 0 Using
> 16 instead. Ensure that firmware is up to date.
> swapper/0[1]: error during unaligned kernel access
>
> Here unaligned access comes from 'struct CommandList' that happens
> to be packed. The change f749d8b7a ("scsi: hpsa: Correct dev cmds
> outstanding for retried cmds") introduced unexpected padding and
> un-aligned atomic_t from natural alignment to something else.
>
> This change does not remove packing annotation from struct but only
> restores alignment of atomic variable.
>
> The change is tested on the same rx3600 machine.
I just gave it a try on my RX2660 and for me, the hpsa driver won't load even
with your patch.
Can you share your kernel configuration so I can give it a try?
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] ia64: kernel: Few typos fixed in the file fsys.S
Hi! On 3/11/21 7:15 AM, Randy Dunlap wrote: > On 3/10/21 10:10 PM, Bhaskar Chowdhury wrote: >> >> Mundane spelling fixes. >> >> Signed-off-by: Bhaskar Chowdhury > > Acked-by: Randy Dunlap > > but no maintainer Cc:ed to pick it up... I guess Andrew's tree will just work fine in this case? Adrian -- .''`. John Paul Adrian Glaubitz : :' : Debian Developer - glaub...@debian.org `. `' Freie Universitaet Berlin - glaub...@physik.fu-berlin.de `-GPG: 62FF 8A75 84E0 2956 9546 0006 7426 3B37 F5B5 F913
Re: [GIT] SPARC
Hi Dave! On 3/9/21 12:46 AM, David Miller wrote: > Just some more random bits from Al, including a conversion over to generic > exytables. Is there a chance we could include this important fix by Rob Gardner for 5.12 as well? > https://marc.info/?l=linux-sparc=161457847223456=2 It fixes a hard kernel crash under certain loads which we have seen in Debian quite frequently. 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: 5.11 regression: "ia64: add support for TIF_NOTIFY_SIGNAL" breaks ia64 boot
Hi Sergei! On 3/2/21 11:26 PM, Sergei Trofimovich wrote: > Gave v5.12-rc1 a try today and got a similar boot failure around > hpsa queue initialization, but my failure is later: > https://dev.gentoo.org/~slyfox/configs/guppy-dmesg-5.12-rc1 > Maybe I get different error because I flipped on most debugging > kernel options :) > > Looks like 'ERROR: Invalid distance value range' while being > very scary are harmless. It's just a new spammy way for kernel > to report lack of NUMA config on the machine (no SRAT and SLIT > ACPI tables). > > At least I get hpsa detected on PCI bus. But I guess it's discovered > configuration is very wrong as I get unaligned accesses: > [ 19.811570] kernel unaligned access to 0xe00105dd8295, > ip=0xa00100b874d1 > > Bisecting now. Sounds good. I guess we should get Jens' fix for the signal regression merged as well as your two fixes for strace. 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] sh: Use generic GGC library routines
Hi Geert! On 3/2/21 5:14 PM, Geert Uytterhoeven wrote: > The C implementations of __ashldi3(), __ashrdi3__(), and __lshrdi3() in > arch/sh/lib/ are identical to the generic C implementations in lib/. > Reduce duplication by switching SH to the generic versions. > > Update the include path in arch/sh/boot/compressed accordingly. > > Signed-off-by: Geert Uytterhoeven There is a funny typo in the subject you probably want to fix :-). Adrian -- .''`. John Paul Adrian Glaubitz : :' : Debian Developer - glaub...@debian.org `. `' Freie Universitaet Berlin - glaub...@physik.fu-berlin.de `-GPG: 62FF 8A75 84E0 2956 9546 0006 7426 3B37 F5B5 F913
Re: [PATCH] [RFT] m68k: enable HAVE_LD_DEAD_CODE_DATA_ELIMINATION
Hi Arnd! On 2/25/21 12:14 PM, Arnd Bergmann wrote: > From: Arnd Bergmann > > While experimenting with CONFIG_TRIM_UNUSED_KSYMS across architectures, > I noticed that this unsurprisingly works best when combined with the > --gc-sections linker flag, which is not currently allowed on m68k. > > Enabling it with this patch shows significant improvements > for kernel size, looking at m68k defconfig with gcc-10, I get > > 4005135 1374302 167108 5546545 54a231 vmlinux-normal > 3916254 1378078 167108 5461440 5355c0 vmlinux+trim > 4012933 1362514 164280 5539727 54878f vmlinux+gcsection > 3797884 1334194 164640 5296718 50d24e vmlinux+gcsection+trim > > There are probably bugs somewhere, but if someone is able to test this > patch and fix any issues that come up, would be a useful improvement > for memory-limited machines. Thanks, that sounds like a very helpful improvement. I'll test the patch next week when I'm on vacation and report back if it works - unless someone beats me to 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: 5.11 regression: "ia64: add support for TIF_NOTIFY_SIGNAL" breaks ia64 boot
On 2/23/21 10:13 AM, John Paul Adrian Glaubitz wrote: > On 2/23/21 9:35 AM, Sergei Trofimovich wrote:> On Tue, 23 Feb 2021 00:55:50 > +0100 >> John Paul Adrian Glaubitz wrote: >> >>> For me, Debian also stopped booting on ia64 with systemd and I bisected it >>> to this >>> change. Glad to see I'm not the only one. >>> >>> The changes Jens suggested back then unfortunately didn't help :(. >> >> I wonder if systemd is less tolerant to kernel that throws signal 0 at it. >> >> Looks like https://marc.info/?l=linux-ia64=161404320617004=2 >> fixed all the issues for me. > > Just gave it a try and it still doesn't work. Maybe your other two patches to fix the strace issues are required as well? Or do you happen to have more patches in the Gentoo kernel? 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: 5.11 regression: "ia64: add support for TIF_NOTIFY_SIGNAL" breaks ia64 boot
Hi Sergei! On 2/23/21 12:34 AM, Jens Axboe wrote: > On 2/22/21 4:05 PM, Sergei Trofimovich wrote: >> Hia Jens! >> >> Tried 5.11 on rx3600 box and noticed it has >> a problem handling init (5.10 booted fine): >> >> INIT: version 2.98 booting >> >>OpenRC 0.42.1 is starting up Gentoo Linux (ia64) >> >> mkdir `/run/openrc': Read-only file system >> mkdir `/run/openrc/starting': No such file or directory >> mkdir `/run/openrc/started': No such file or directory >> mkdir `/run/openrc/stopping': No such file or directory >> mkdir `/run/openrc/inactive': No such file or directory >> mkdir `/run/openrc/wasinactive': No such file or directory >> mkdir `/run/openrc/failed': No such file or directory >> mkdir `/run/openrc/hotplugged': No such file or directory >> mkdir `/run/openrc/daemons': No such file or directory >> mkdir `/run[ 14.595059] Kernel panic - not syncing: Attempted to kill >> init! exitcode=0x000b >> [ 14.599059] ---[ end Kernel panic - not syncing: Attempted to kill init! >> exitcode=0x000b ]--- >> >> I suspect we build bad signal stack frame for userspace. For me, Debian also stopped booting on ia64 with systemd and I bisected it to this change. Glad to see I'm not the only one. The changes Jens suggested back then unfortunately didn't help :(. 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] ia64: fix ptrace(PTRACE_SYSCALL_INFO_EXIT) sign
Hi Sergei! On 2/21/21 1:25 AM, Sergei Trofimovich wrote: > In https://bugs.gentoo.org/769614 Dmitry noticed that > `ptrace(PTRACE_GET_SYSCALL_INFO)` does not return error sign properly. > (...) Do these two patches unbreak gdb on ia64? And have you, by any chance, managed to get the hpsa driver working again? 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: Pending patches for linux-sh
Hi Rich! Any chance we can get these patches (see below) merged for 5.12? And let's add this one: > - [PATCH] scripts/recordmcount.pl: support big endian for ARCH sh > - https://marc.info/?l=linux-sh=161296964604229=2 Adrian Adrian On 1/24/21 11:07 PM, John Paul Adrian Glaubitz wrote: > Hi Rich! > > The following patches are still missing after the 5.11 SH pull: > >> - [PATCH] [sh] fix trivial misannotations >> - https://marc.info/?l=linux-kernel=160945707001399=2 >> >> - [PATCH] sh: check return code of request_irq >> - https://marc.info/?l=linux-kernel=160867050030140=2 >> >> - [PATCH] sh: boards: Fix the cacography in irq.c >> - https://marc.info/?l=linux-sh=160578410511403=2 >> >> - [PATCH 1/2] sh: boot: add intermediate vmlinux.bin* to targets instead of >> extra-y >> - https://marc.info/?l=linux-kernel=161088234517301=2 >> >> - [PATCH 2/2] sh: boot: avoid unneeded rebuilds under >> arch/sh/boot/compressed/ >> - https://marc.info/?l=linux-kernel=161088245817344=2 >> >> - [PATCH] maple: fix wrong return value of maple_bus_init(). >> - https://marc.info/?l=linux-kernel=160635878212678=2 >> >> - [PATCH] sh: kdump: add some attribute to function >> - https://marc.info/?l=linux-kernel=160758311622653=2 >> >> - [PATCH] sh: kernel: traps: remove unused variable >> - https://marc.info/?l=linux-kernel=160760435528709=2 > > Shall they go in for 5.12? > > They all look fine to me as they're either trivial fixes or I verified that > they > don't cause any regression on my SH-7785LCR system. > > 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] m68k: Drop -fno-strength-reduce from KBUILD_CFLAGS
On 2/7/21 8:02 AM, Finn Thain wrote:
> References: commit 565bae6a4a8f ("[SCSI] 53c7xx: kill driver")
Does that mean there is currently no driver for the A4091?
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] ia64: Fix style guide breakage
Hi Amy! On 2/5/21 11:06 PM, Amy Parker wrote: > Some statements do not have proper spacing between their C > keywords (commonly if and for) throughout files in the ia64 tree. > This patch corrects this to follow the kernel code style guide. > > Signed-off-by: Amy Parker I never noticed. Does the kernel coding style guideline actually require space after "for" and "if" and similar statements but not before function names? 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] arch: m68k: include: asm: Reconstruct the sentence in file sun3ints.h
On 2/5/21 1:04 PM, Bhaskar Chowdhury wrote: > s/fuck/"do anything"/ What does this fix? -- .''`. 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: Pending patches for linux-sh
Hi Rich! The following patches are still missing after the 5.11 SH pull: > - [PATCH] [sh] fix trivial misannotations > - https://marc.info/?l=linux-kernel=160945707001399=2 > > - [PATCH] sh: check return code of request_irq > - https://marc.info/?l=linux-kernel=160867050030140=2 > > - [PATCH] sh: boards: Fix the cacography in irq.c > - https://marc.info/?l=linux-sh=160578410511403=2 > > - [PATCH 1/2] sh: boot: add intermediate vmlinux.bin* to targets instead of > extra-y > - https://marc.info/?l=linux-kernel=161088234517301=2 > > - [PATCH 2/2] sh: boot: avoid unneeded rebuilds under arch/sh/boot/compressed/ > - https://marc.info/?l=linux-kernel=161088245817344=2 > > - [PATCH] maple: fix wrong return value of maple_bus_init(). > - https://marc.info/?l=linux-kernel=160635878212678=2 > > - [PATCH] sh: kdump: add some attribute to function > - https://marc.info/?l=linux-kernel=160758311622653=2 > > - [PATCH] sh: kernel: traps: remove unused variable > - https://marc.info/?l=linux-kernel=160760435528709=2 Shall they go in for 5.12? They all look fine to me as they're either trivial fixes or I verified that they don't cause any regression on my SH-7785LCR system. 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 1/6] arch: rearrahge headers inclusion order in asm/bitops for m68k and sh
Hi Yury! On 1/21/21 1:06 AM, Yury Norov wrote: > m68k and sh include bitmap/find.h prior to ffs/fls headers. New > fast-path implementation in find.h requires ffs/fls. Reordering > the order of headers inclusion helps to prevent compile-time > implicit-function-declaration error. Can you fix the commit message? "arch: rearrahge headers inclusion order in asm/bitops for m68k and sh" ^ rearrange 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: Pending patches for linux-sh
Hi! On 1/21/21 2:42 AM, Rich Felker wrote: >> I will check later whether there are more patches we might have forgotten. > > Hi! Thanks for the list. From the names, I think some overlap with the > pending set in linux-next (ending at a118584e7e60) that I'm about to > send as a PR. OK, I have seen them now. I will send an updated list once the patches have landed in Linus' tree so we can see whether we missed anything. 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] arch/alpha: fix typo in a comment in arch/alpha/boot/bootpz.c
Hi Chunyou! On 1/21/21 3:20 AM, Chunyou Tang wrote: >> Right. Reading the whole paragraph helps. It probably should be: >> >> ZERO_PGE KSEG address of page full of zeroes, but >> upon entry to kernel, it can be expected >> to hold the parameter list and possible >> INTRD information. >> >> Adrian >> > > ok, I change it as : > ZERO_PGE KSEG address of page full of zeroes, but > upon entry to kernel, it can be expected > to hold the parameter list and possible > INTRD information. > then I commit it. Great, thank you. 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] arch/alpha: fix typo in a comment in arch/alpha/boot/bootpz.c
On 1/20/21 5:20 PM, Randy Dunlap wrote: > On 1/20/21 5:34 AM, ChunyouTang wrote: >> From: tangchunyou >> >> "kerne" -> "kernel" >> >> Signed-off-by: tangchunyou >> --- >> arch/alpha/boot/bootpz.c | 2 +- >> 1 file changed, 1 insertion(+), 1 deletion(-) >> >> diff --git a/arch/alpha/boot/bootpz.c b/arch/alpha/boot/bootpz.c >> index 43af718..61b61be 100644 >> --- a/arch/alpha/boot/bootpz.c >> +++ b/arch/alpha/boot/bootpz.c >> @@ -200,7 +200,7 @@ extern int decompress_kernel(void* destination, void >> *source, >> START_ADDR KSEG address of the entry point of kernel code. >> >> ZERO_PGEKSEG address of page full of zeroes, but >> -upon entry to kerne cvan be expected >> +upon entry to kernel cvan be expected > > s/cvan/can/ also Right. Reading the whole paragraph helps. It probably should be: ZERO_PGEKSEG address of page full of zeroes, but upon entry to kernel, it can be expected to hold the parameter list and possible INTRD information. 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] arch/alpha: fix typo in a comment in arch/alpha/boot/bootpz.c
Hi ChunyouTang! On 1/20/21 2:34 PM, ChunyouTang wrote: > From: tangchunyou > > "kerne" -> "kernel" > > Signed-off-by: tangchunyou > --- > arch/alpha/boot/bootpz.c | 2 +- > 1 file changed, 1 insertion(+), 1 deletion(-) > > diff --git a/arch/alpha/boot/bootpz.c b/arch/alpha/boot/bootpz.c > index 43af718..61b61be 100644 > --- a/arch/alpha/boot/bootpz.c > +++ b/arch/alpha/boot/bootpz.c > @@ -200,7 +200,7 @@ extern int decompress_kernel(void* destination, void > *source, > START_ADDR KSEG address of the entry point of kernel code. > > ZERO_PGEKSEG address of page full of zeroes, but > - upon entry to kerne cvan be expected > + upon entry to kernel cvan be expected > to hold the parameter list and possible > INTRD information. That should probably be "upon entry to the kernel cvan can be expected". 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
Pending patches for linux-sh
Hi Rich! I have tested or acked the following patches which are fine from my point of view. "Tested" means I have built and booted a current kernel with the patch in question, "acked" means, I have looked over the patch and consider the changes to be correct in the case where testing was not possible since the changes affect other SH hardware I cannot test at the moment. Here the list: - [PATCH] [sh] fix trivial misannotations - https://marc.info/?l=linux-kernel=160945707001399=2 - [PATCH] sh: check return code of request_irq - https://marc.info/?l=linux-kernel=160867050030140=2 - [PATCH] sh: boards: Fix the cacography in irq.c - https://marc.info/?l=linux-sh=160578410511403=2 - [PATCH v1] sh: Drop ARCH_NR_GPIOS definition - https://marc.info/?l=linux-sh=160578410511403=2 - [PATCH 1/2] sh: boot: add intermediate vmlinux.bin* to targets instead of extra-y - https://marc.info/?l=linux-kernel=161088234517301=2 - [PATCH 2/2] sh: boot: avoid unneeded rebuilds under arch/sh/boot/compressed/ - https://marc.info/?l=linux-kernel=161088245817344=2 - [PATCH] arch: sh: remove duplicate include - https://marc.info/?l=linux-kernel=160488997017438=2 - [PATCH] maple: fix wrong return value of maple_bus_init(). - https://marc.info/?l=linux-kernel=160635878212678=2 - [PATCH] sh: kdump: add some attribute to function - https://marc.info/?l=linux-kernel=160758311622653=2 - [PATCH] sh: kernel: traps: remove unused variable - https://marc.info/?l=linux-kernel=160760435528709=2 - [PATCH] sh: Remove unused HAVE_COPY_THREAD_TLS macro - https://marc.info/?l=linux-kernel=160247465514800=2 I will check later whether there are more patches we might have forgotten. 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: [GIT PULL] ia64: fix build regression
On 1/18/21 12:34 PM, Mike Rapoport wrote: > The following changes since commit 7c53f6b671f4aba70ff15e1b05148b10d58c2837: > > Linux 5.11-rc3 (2021-01-10 14:34:50 -0800) > > are available in the Git repository at: > > https://git.kernel.org/pub/scm/linux/kernel/git/rppt/memblock > tags/fixes-2021-01-18 > > for you to fetch changes up to 32c2bc8f2d855d4415c9a05b727e34649397bfbe: > > ia64: fix build failure caused by memory model changes (2021-01-17 13:31:09 > +0200) > > > ia64: fix build failure caused by memory model changes > > > Mike Rapoport (1): > ia64: fix build failure caused by memory model changes > > arch/ia64/include/asm/sparsemem.h | 1 + > 1 file changed, 1 insertion(+) Since I just read this sensationalist article on Phoronix [1], I just haven't gotten around to test 5.11 for ia64 as I was currently busy with testing all pending patches for SH. I will be getting around testing the ia64 build and also bisect that one issue with the hpsa driver which was no longer usable after some change in the mm tree. Adrian > [1] > https://www.phoronix.com/scan.php?page=news_item=Itanium-IA64-Linux-5.11-Broken -- .''`. 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] sh: Remove unused HAVE_COPY_THREAD_TLS macro
On 10/12/20 5:50 AM, Jinyang He wrote:
> Fixes:e1cc9d8d596e ("sh: switch to copy_thread_tls()")
> Signed-off-by: Jinyang He
> ---
> arch/sh/Kconfig | 1 -
> 1 file changed, 1 deletion(-)
>
> diff --git a/arch/sh/Kconfig b/arch/sh/Kconfig
> index d209271..165f291 100644
> --- a/arch/sh/Kconfig
> +++ b/arch/sh/Kconfig
> @@ -30,7 +30,6 @@ config SUPERH
> select HAVE_ARCH_KGDB
> select HAVE_ARCH_SECCOMP_FILTER
> select HAVE_ARCH_TRACEHOOK
> - select HAVE_COPY_THREAD_TLS
> select HAVE_DEBUG_BUGVERBOSE
> select HAVE_DEBUG_KMEMLEAK
> select HAVE_DYNAMIC_FTRACE
Acked-by: John Paul Adrian Glaubitz
--
.''`. 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] sh: kernel: traps: remove unused variable
On 12/10/20 1:44 PM, Anders Roxell wrote:
> When building defconfig the following warning shows up:
>
> arch/sh/kernel/traps.c: In function 'nmi_trap_handler':
> arch/sh/kernel/traps.c:183:15: warning: unused variable 'cpu'
> [-Wunused-variable]
> unsigned int cpu = smp_processor_id();
>^~~
>
> Remove an unused variable 'cpu'.
>
> Fixes: fe3f1d5d7cd3 ("sh: Get rid of nmi_count()")
> Signed-off-by: Anders Roxell
> ---
> arch/sh/kernel/traps.c | 1 -
> 1 file changed, 1 deletion(-)
>
> diff --git a/arch/sh/kernel/traps.c b/arch/sh/kernel/traps.c
> index f5beecdac693..e76b22157099 100644
> --- a/arch/sh/kernel/traps.c
> +++ b/arch/sh/kernel/traps.c
> @@ -180,7 +180,6 @@ static inline void arch_ftrace_nmi_exit(void) { }
>
> BUILD_TRAP_HANDLER(nmi)
> {
> - unsigned int cpu = smp_processor_id();
> TRAP_HANDLER_DECL;
>
> arch_ftrace_nmi_enter();
Good catch. Now I have one warning less when building the kernel for my
SH-7785LCR ;-).
Acked-by: John Paul Adrian Glaubitz
--
.''`. 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] sh: kdump: add some attribute to function
On 12/10/20 7:49 AM, Yejune Deng wrote:
> add '__iomem' for ioremap() and '__user' for copy_to_user().
>
> Signed-off-by: Yejune Deng
> ---
> arch/sh/kernel/crash_dump.c | 4 ++--
> 1 file changed, 2 insertions(+), 2 deletions(-)
>
> diff --git a/arch/sh/kernel/crash_dump.c b/arch/sh/kernel/crash_dump.c
> index a908612..5b41b59 100644
> --- a/arch/sh/kernel/crash_dump.c
> +++ b/arch/sh/kernel/crash_dump.c
> @@ -26,7 +26,7 @@
> ssize_t copy_oldmem_page(unsigned long pfn, char *buf,
> size_t csize, unsigned long offset, int
> userbuf)
> {
> - void *vaddr;
> + void __iomem *vaddr;
>
> if (!csize)
> return 0;
> @@ -34,7 +34,7 @@ ssize_t copy_oldmem_page(unsigned long pfn, char *buf,
> vaddr = ioremap(pfn << PAGE_SHIFT, PAGE_SIZE);
>
> if (userbuf) {
> - if (copy_to_user(buf, (vaddr + offset), csize)) {
> + if (copy_to_user((void __user *)buf, (vaddr + offset), csize)) {
> iounmap(vaddr);
> return -EFAULT;
> }
Successfully boot-tested on my SH-7785LCR. No regressions.
Tested-by: John Paul Adrian Glaubitz
--
.''`. 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] sh: check return code of request_irq
Hi Miguel! On 1/1/21 9:42 PM, Miguel Ojeda wrote: > On Fri, Jan 1, 2021 at 2:50 PM John Paul Adrian Glaubitz > wrote: >> >> Verified on my SH-7785LCR board. Boots fine. >> >> Tested-by: John Paul Adrian Glaubitz > > Thanks for testing, John! > > I think Masahiro was concerned about the error case (I assume you > tested the happy path). Not sure about testing the error case though. How do I make request_irq() fail? > In any case, if no maintainer suggests something else, looks good to > me (and it is no worse than the status quo unless the `pr_err()` can > somehow kill it), so: > > Reviewed-by: Miguel Ojeda I agree. 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] maple: fix wrong return value of maple_bus_init().
On 11/26/20 3:43 AM, Lu Wei wrote:
> If KMEM_CACHE or maple_alloc_dev failed, the maple_bus_init() will return 0
> rather than error, because the retval is not changed after KMEM_CACHE or
> maple_alloc_dev failed.
>
> Fixes: 17be2d2b1c33 ("sh: Add maple bus support for the SEGA Dreamcast.")
> Reported-by: Hulk Robot
> Signed-off-by: Lu Wei
> ---
> drivers/sh/maple/maple.c | 5 -
> 1 file changed, 4 insertions(+), 1 deletion(-)
>
> diff --git a/drivers/sh/maple/maple.c b/drivers/sh/maple/maple.c
> index e5d7fb81ad66..44a931d41a13 100644
> --- a/drivers/sh/maple/maple.c
> +++ b/drivers/sh/maple/maple.c
> @@ -835,8 +835,10 @@ static int __init maple_bus_init(void)
>
> maple_queue_cache = KMEM_CACHE(maple_buffer, SLAB_HWCACHE_ALIGN);
>
> - if (!maple_queue_cache)
> + if (!maple_queue_cache) {
> + retval = -ENOMEM;
> goto cleanup_bothirqs;
> + }
>
> INIT_LIST_HEAD(_waitq);
> INIT_LIST_HEAD(_sentq);
> @@ -849,6 +851,7 @@ static int __init maple_bus_init(void)
> if (!mdev[i]) {
> while (i-- > 0)
> maple_free_dev(mdev[i]);
> + retval = -ENOMEM;
> goto cleanup_cache;
> }
> baseunits[i] = mdev[i];
>
Acked-by: John Paul Adrian Glaubitz
--
.''`. 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] arch: sh: remove duplicate include
On 11/9/20 3:45 AM, Wang Qing wrote: > Remove duplicate header which is included twice. > > Signed-off-by: Wang Qing > --- > arch/sh/kernel/cpu/sh3/entry.S | 1 - > 1 file changed, 1 deletion(-) > > diff --git a/arch/sh/kernel/cpu/sh3/entry.S b/arch/sh/kernel/cpu/sh3/entry.S > index 25eb809..e48b3dd > --- a/arch/sh/kernel/cpu/sh3/entry.S > +++ b/arch/sh/kernel/cpu/sh3/entry.S > @@ -14,7 +14,6 @@ > #include > #include > #include > -#include > > ! NOTE: > ! GNU as (as of 2.9.1) changes bf/s into bt/s and bra, when the address Acked-by: John Paul Adrian Glaubitz -- .''`. 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 2/2] sh: boot: avoid unneeded rebuilds under arch/sh/boot/compressed/
compressed/ashldi3.c > @@ -0,0 +1,2 @@ > +// SPDX-License-Identifier: GPL-2.0-only > +#include "../../lib/ashldi3.c" > diff --git a/arch/sh/boot/compressed/ashlsi3.S > b/arch/sh/boot/compressed/ashlsi3.S > new file mode 100644 > index ..e354262b275f > --- /dev/null > +++ b/arch/sh/boot/compressed/ashlsi3.S > @@ -0,0 +1,2 @@ > +/* SPDX-License-Identifier: GPL-2.0-only */ > +#include "../../lib/ashlsi3.S" > diff --git a/arch/sh/boot/compressed/ashrsi3.S > b/arch/sh/boot/compressed/ashrsi3.S > new file mode 100644 > index ..e564be9a4dcd > --- /dev/null > +++ b/arch/sh/boot/compressed/ashrsi3.S > @@ -0,0 +1,2 @@ > +/* SPDX-License-Identifier: GPL-2.0-only */ > +#include "../../lib/ashrsi3.S" > diff --git a/arch/sh/boot/compressed/lshrsi3.S > b/arch/sh/boot/compressed/lshrsi3.S > new file mode 100644 > index ..5a8281b7e516 > --- /dev/null > +++ b/arch/sh/boot/compressed/lshrsi3.S > @@ -0,0 +1,2 @@ > +/* SPDX-License-Identifier: GPL-2.0-only */ > +#include "../../lib/lshrsi3.S" Successfully boot-tested on my SH-7785LCR. No regressions. Tested-by: John Paul Adrian Glaubitz -- .''`. 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 1/2] sh: boot: add intermediate vmlinux.bin* to targets instead of extra-y
On 1/17/21 12:16 PM, Masahiro Yamada wrote: > You do not need to build all of vmlinux.bin* > > They are built on demand as prerequsites of uImage.bin*, hence should > be added to targets instead of extra-y. > > Signed-off-by: Masahiro Yamada > --- > > arch/sh/boot/Makefile | 4 ++-- > 1 file changed, 2 insertions(+), 2 deletions(-) > > diff --git a/arch/sh/boot/Makefile b/arch/sh/boot/Makefile > index 58592dfa5cb6..dded61296c9a 100644 > --- a/arch/sh/boot/Makefile > +++ b/arch/sh/boot/Makefile > @@ -27,8 +27,8 @@ suffix-$(CONFIG_KERNEL_XZ) := xz > suffix-$(CONFIG_KERNEL_LZO) := lzo > > targets := zImage vmlinux.srec romImage uImage uImage.srec uImage.gz \ > -uImage.bz2 uImage.lzma uImage.xz uImage.lzo uImage.bin > -extra-y += vmlinux.bin vmlinux.bin.gz vmlinux.bin.bz2 vmlinux.bin.lzma \ > +uImage.bz2 uImage.lzma uImage.xz uImage.lzo uImage.bin \ > +vmlinux.bin vmlinux.bin.gz vmlinux.bin.bz2 vmlinux.bin.lzma \ > vmlinux.bin.xz vmlinux.bin.lzo > subdir- := compressed romimage Successfully boot-tested on my SH-7785LCR. No regressions. Tested-by: John Paul Adrian Glaubitz -- .''`. 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 2/2] sh: boot: avoid unneeded rebuilds under arch/sh/boot/compressed/
Hi Masahiro! On 1/17/21 5:21 PM, Masahiro Yamada wrote: >> This patch doesn't apply for me while the first one applies without problems: >> >> glaubitz@epyc:..glaubitz/linux-git> git am ../sh-patches-2021/\[PATCH\ >> 1_2\]\ sh\:\ boot\:\ add\ intermediate\ vmlinux.bin\*\ to\ targets\ instead\ >> of\ extra-y.eml >> Applying: sh: boot: add intermediate vmlinux.bin* to targets instead of >> extra-y >> glaubitz@epyc:..glaubitz/linux-git> git am ../sh-patches-2021/\[PATCH\ >> 2_2\]\ sh\:\ boot\:\ avoid\ unneeded\ rebuilds\ under\ >> arch_sh_boot_compressed_.eml >> Applying: sh: boot: avoid unneeded rebuilds under arch/sh/boot/compressed/ >> error: arch/sh/boot/compressed/ashiftrt.S: already exists in working >> directory >> error: arch/sh/boot/compressed/ashldi3.c: already exists in working directory >> error: arch/sh/boot/compressed/ashlsi3.S: already exists in working directory >> error: arch/sh/boot/compressed/ashrsi3.S: already exists in working directory >> error: arch/sh/boot/compressed/lshrsi3.S: already exists in working directory > > Adrian, these 5 files are currently generated files. > > That is why git-am failed. I already guessed that. I removed them now and the patch applies cleanly. Will test-boot on my SH-7785LCR in a minute. > They are not cleaned up by 'make ARCH=sh clean' > (this is a bug too). That should be easy to fix I guess :-). 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 2/2] sh: boot: avoid unneeded rebuilds under arch/sh/boot/compressed/
b/arch/sh/boot/compressed/ashldi3.c > @@ -0,0 +1,2 @@ > +// SPDX-License-Identifier: GPL-2.0-only > +#include "../../lib/ashldi3.c" > diff --git a/arch/sh/boot/compressed/ashlsi3.S > b/arch/sh/boot/compressed/ashlsi3.S > new file mode 100644 > index ..e354262b275f > --- /dev/null > +++ b/arch/sh/boot/compressed/ashlsi3.S > @@ -0,0 +1,2 @@ > +/* SPDX-License-Identifier: GPL-2.0-only */ > +#include "../../lib/ashlsi3.S" > diff --git a/arch/sh/boot/compressed/ashrsi3.S > b/arch/sh/boot/compressed/ashrsi3.S > new file mode 100644 > index ..e564be9a4dcd > --- /dev/null > +++ b/arch/sh/boot/compressed/ashrsi3.S > @@ -0,0 +1,2 @@ > +/* SPDX-License-Identifier: GPL-2.0-only */ > +#include "../../lib/ashrsi3.S" > diff --git a/arch/sh/boot/compressed/lshrsi3.S > b/arch/sh/boot/compressed/lshrsi3.S > new file mode 100644 > index ..5a8281b7e516 > --- /dev/null > +++ b/arch/sh/boot/compressed/lshrsi3.S > @@ -0,0 +1,2 @@ > +/* SPDX-License-Identifier: GPL-2.0-only */ > +#include "../../lib/lshrsi3.S" This patch doesn't apply for me while the first one applies without problems: glaubitz@epyc:..glaubitz/linux-git> git am ../sh-patches-2021/\[PATCH\ 1_2\]\ sh\:\ boot\:\ add\ intermediate\ vmlinux.bin\*\ to\ targets\ instead\ of\ extra-y.eml Applying: sh: boot: add intermediate vmlinux.bin* to targets instead of extra-y glaubitz@epyc:..glaubitz/linux-git> git am ../sh-patches-2021/\[PATCH\ 2_2\]\ sh\:\ boot\:\ avoid\ unneeded\ rebuilds\ under\ arch_sh_boot_compressed_.eml Applying: sh: boot: avoid unneeded rebuilds under arch/sh/boot/compressed/ error: arch/sh/boot/compressed/ashiftrt.S: already exists in working directory error: arch/sh/boot/compressed/ashldi3.c: already exists in working directory error: arch/sh/boot/compressed/ashlsi3.S: already exists in working directory error: arch/sh/boot/compressed/ashrsi3.S: already exists in working directory error: arch/sh/boot/compressed/lshrsi3.S: already exists in working directory Patch failed at 0001 sh: boot: avoid unneeded rebuilds under arch/sh/boot/compressed/ hint: Use 'git am --show-current-patch=diff' to see the failed patch When you have resolved this problem, run "git am --continue". If you prefer to skip this patch, run "git am --skip" instead. To restore the original branch and stop patching, run "git am --abort". glaubitz@epyc:..glaubitz/linux-git> 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: Old platforms: bring out your dead
Hello Linus! On 1/12/21 11:46 PM, Linus Walleij wrote: > On Tue, Jan 12, 2021 at 3:45 PM John Paul Adrian Glaubitz > wrote: > >> Yeah, I have the same impression that's the strong commercial interest pushes >> hobbyist use of the Linux kernel a bit down. A lot of these changes feel like >> they're motivated by corporate decisions. >> >> There has to be a healthy balance between hobbyist and commercial use. I >> understand >> that from a commercial point of view, it doesn't make much sense to run Linux >> on a 30-year-old computer. But it's a hobbyist project for many people and >> hacking >> Linux stuff for these old machines has a very entertaining and educational >> factor. > > This is actually one of the most interesting things written in this > discussion. > > I have both revamped and deleted subarchitectures in the ARM tree. We > never deleted anyone's pet project *unless* they were clearly unwilling to > work on it (such as simply testning new patches) and agreed that it will > not go on. I'm not arguing this. This was more about killing (sub-)architectures because they haven't seen git activity for a long time which I think is poor metric to determine whether a port is dead or not. And reading through the other answers in this thread, it seems I'm not alone with this stance. > At multiple occasions I actually found it easier to fix stuff than > delete it, both because it is a nicer thing to do and because it > simply creates less social problems, often to the point that the time > (man hours) spent trying to solve the resulting social problems from > deleting a platform would be longer than the time spent actually acquiring > the physical platform and fixing it. Good to hear. > Corporate entities can be a bit deletionist (using Wikipedia terminology) > and as in this thread there is always a strong inclusionist stance pushing > back to that. It's an obvious conflict. > The explanation is in my mind very simply that running Linux > on a 35-yo or so Amiga, Atari or Apollo Workstation is pretty impressive and > fun. And I think that fits Mr. Torvalds own sociological-or-something > explanation in the autobiographical "Just for fun" as to why to write it > in the first place. And we are very protective of that quality of the > kernel. (At least I am.) I'm happy to hear that. For me personally, it also has a very educational value as the non-mainstream platforms such as m68k offer more places of code to hack on for adding features such as SECCOMP which are still missing there. There are usually enough people working on architectures such as x86 and ARM, so there is not much room for hobbyist activities. Also, you risk making much more people upset if you break something. > That said there are a three things that people should really be doing if they > want to keep their pet archs/subarchs around as good community > members, and they are in essence to: > > 1. Test and review/ack patches that others make I am already doing that as much as I can for various architectures such as ia64, m68k, SH and POWER, SPARC although I need to ramp up my activity a bit more. I have also now added myself for the linux-alpha mailing list to test and ack patches for the Alpha architecture as well. I have to admit I have quite a number of pet architectures but that's because I'm co-maintaining these architectures in Debian Ports with regular releases of Debian installation images for these targets: > https://cdimage.debian.org/cdimage/ports/snapshots/ > 2. Migrate existing drivers to newly appeared and > appropriate subsystems (I think there are some hacky heartbeat LED > drivers down in arch/* for example) there is also the feature matrix > core maintainers like and which appears if you type > Documentation/features/list-arch.sh > would be nice if you work on them if you can support them! > Or at least take a look. Thanks for the pointer. I'm not so much active in kernel development itself yet, but I'm also trying to be more active. Although the kernel is not the only project that sometimes needs attention for these pet architectures. We're also confronted with deprecation problem in problems such as GCC although we recently saved the m68k (and VAX) backends in GCC with the help of a Bountysource campaign. The AVR backend is also backed by such a campaign and currently being worked on. We are even getting an m68k backend for LLVM hopefully soonish, so we will even be able to build the Linux kernel for m68k with clang :-). > 3. Migrate old systems to use the >contemporary hardware descriptions (such as device tree or ACPI) >because it makes things so much easier to maintain. Some >upfront work, but a great win for everyone. Especially for &g
Re: Old platforms: bring out your dead
Hello Gerhard! On 1/11/21 4:04 PM, Gerhard Pircher wrote: >>> * powerpc/cell: I'm the maintainer and I promised to send a patch to remove >>> it. >>>it's in my backlog but I will get to it. This is separate from PS3, >>>which is actively maintained and used; spufs will move to ps3 >>> * powerpc/chrp (32-bit rs6000, pegasos2): last updated in 2009 >> >> I'm still using this. Please keep it. > > I can also confirm that Pegasos2 users in the Amiga scene are running Linux > (Debian) on these machines. Thanks for raising your voice. It's nice and reliable hardware after all and still fast enough to run a recent version of Debian unstable with a lean desktop such as XFCE or MATE. >>> * powerpc/amigaone: last updated in 2009 > > I still have 2 of the 3 types of the first generation AmigaOne machines (not > to be confused with the newer AmigaOne X1000 and X5000 machines based on > PASemi and P5020 CPUs) working here. A third machine needs a repair of the > G4 CPU module (replacement parts already available). Cool. > I have to admit however that I yet have to setup an environment that allows > me to regularly test new Linux kernel versions on these machines. Especially > because there are not many Linux users for these machines - which is likely > due to the fact that no distribution officially supports these machines out > of the box (the Pegasos2 platform had more luck here). Inputs on how to > automate tests would therefore be very welcome! Are you on the debian-powerpc mailing list? If not, please subscribe and post your issues there: > https://lists.debian.org/debian-powerpc/ > Given however that the Debian PowerPC port has a proper maintainer again > (kudos to Adrian!) and there is also another new PowerPC distro (Void Linux), > I would like to ask for a period of grace. After all this is just a hobby > project for me, so keeping up with the pace of the Linux development isn't > always that easy (and no, work on this did not stop in 2009, but shifted more > towards distro support since then). Yeah, I have the same impression that's the strong commercial interest pushes hobbyist use of the Linux kernel a bit down. A lot of these changes feel like they're motivated by corporate decisions. There has to be a healthy balance between hobbyist and commercial use. I understand that from a commercial point of view, it doesn't make much sense to run Linux on a 30-year-old computer. But it's a hobbyist project for many people and hacking Linux stuff for these old machines has a very entertaining and educational factor. Plus, as Thomas Bogendoerfer already mentioned in this thread, most of the old ports run just fine. I have an Alpha XP-1000 building Debian packages for the Debian Alpha port and it runs 24/7 without a hick and is regularly kept up-to-date with dist-upgrades. 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: Old platforms: bring out your dead
Hello! On 1/11/21 3:55 PM, chase rayfield wrote: > My take is that there *would* be more interest in Sparc sun4m / Sun4d > from enthusiasts at the very least if it was possible to actually boot > the bloat hog that is Linux these days in a fully usable configuration > that probably means some modifications to SILO and Linux required. The Linux kernel is configurable. If you want a small kernel, then just configure one. No one expects you to boot a fully-fledged distribution kernel on these machines. > The problem is as I understand it, SILO only sets up a 16Mb mapping > (either due to having to assume 4MB minimum dram stick size or due to > mapping limitations not sure, most of these machines have at least > 16MB in slot one...these days though that wasn't the case for sun4c), > loads Linux into it and says good Luck. This isn't enough for a modern > kernel with any hardware support built in. So you might for instance > get a kernel to fit but only if you dropped all of networking support > etc... That makes no sense. It worked in the past, why shouldn't it work nowadays? As I said, you disable everything you don't need. I'm booting my SH-7785LCR SuperH board with a kernel that is less than 4 MB in size and which includes everything I need. > I'm guessing the fix for this would be to modify silo to map a > larger amount in a way that Linux expects so it can remap it as it > likes, or just have SILO map the full memory as Linux would. Anyway > that is THE main demotivation for these architectures otherwise > they have plenty of ram and performance to do basic router/server > tasks sans SSL. Or just configure a smaller kernel. > This has been the status quo for since the last of the 2.6 series of > kernels which it was still possible to just barely squeeze a usable > kernel out of... If someone wanted to take a few hours and fix this > issue, and keep these architectures around I'd be happy to "buy them a > round of pizza", though I recognize that many people that work on this > already have nice jobs, and just don't have time. I haven't gotten around to setup my SPARCstation 5 yet, but I will certainly going to do that later this year to give it a try. > Also Sparc would probably be a good project for someone to extend/test > Andi Keen's Linux LTO patch set so we could reduce the kernel binary > size that way also even if sun4 architectures are dropped, it would > still be useful for embedded sparc. Also there is a port of Temlib to > the Mister hardware now, 3 cores roughly equivalent to a mid 90s > machine, at least 128MB ram is possible ( more if a way to map the ARM > system memory also 1GB is available there, it would have higher > latency though). > > It is perfectly viable to build Sparc v7 or v8 32bit binaries in a > chroot on a fast machine also, and I would recommend this if you wish > to retain sanity rather than attempting cross compiler voodoo, unless > that is your thing. We build anything SPARC on a SPARC T5 that we have for Debian, no need for cross-compilation and that machine is actually quite fast. 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: Old platforms: bring out your dead
Hi Geert!
On 1/11/21 10:20 AM, Geert Uytterhoeven wrote:
>> Sounds interesting. Do these SoCs come with an MMU? And do they use the
>> ColdFire instruction set or do they run plain 68k code?
>
> No MMU, plain m68k code.
>
> 68328 Soc = 68000 core + some peripherals,
> 68360 SoC = CPU32 core (based on 68020 + some peripherals.
OK, I guess that would be useful for the NoMMU Linux port.
> Anyone working on integrating m68k (and SPARC and MIPS?) softcores in
> LiteX? ;-)
I'm personally waiting for the Vampire to gain support for the real 68851
as the hardware in general looks very attractive [1].
Adrian
> {1]
> https://retromodsblog.wordpress.com/2020/01/28/a-look-at-the-vampire-v4-stand-alone-fpga-first-impressions/
--
.''`. 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: Old platforms: bring out your dead
Hi Daniel! > On Sat, 9 Jan 2021 at 07:56, Arnd Bergmann wrote: >> * 68000/68328 (Dragonball): these are less capable than the >> 68020+ or the Coldfire MCF5xxx line and similar to the 68360 >> that was removed in 2016. > > I have some patches for the DragonBall series to enable SPI etc there, > some patches to support the SuperVZ variant, some tools to upload > Linux via the integrated serial bootloader. > The DragonBall is probably what anyone that wants to build a 68K retro > computer should use as the DRAM controller is integrated and it can > access 32MB of SDRAM. Sounds interesting. Do these SoCs come with an MMU? And do they use the ColdFire instruction set or do they run plain 68k code? 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: Old platforms: bring out your dead
Hello! On 1/10/21 10:46 PM, Sam Ravnborg wrote: >> I don't think this has reached any agreement yet. Multiple people want it to >> stay. > > None of the people that replied have any real use of the sun4m port, > they only wanted it to stay because they had some machines or such. > In other words - people will be sad if we sunset sun4m, but it will not > hurt anyone as there are no users left. > > I will include the above summary when I post v2 of the patch to sunset > sun4m and sun4d. Then we will see what we conclude in the end. I'm not sure I understand the reasoning for doing this. The SPARC architecture isn't going to see any new hardware developments in the future after Oracle let go of most of the SPARC developers. So it's not that we need to make room for new hardware. And I also disagree with Arnd's stance that a port seems broken because it doesn't see frequent or recent changes. As pointed out by Thomas Bogendoerfer in this thread [1], missing updates don't necessarily mean that something is broken but it can also just mean the hardware is fully supported and working, so why fix something that isn't broken? On the other hand, there are really serious bugs in the kernel that easily allow crashing the whole machine (here on POWER [2] or here on SPARC [3]) that never get addressed. We have a $10k IBM POWER server in Debian Ports which hosts a big-endian PowerKVM build server instance and regularly hard-crashes because of the bug in [2]. This bug has remained unfixed for almost a year now. On top of that, some of the tree-wide conversions like [4] have completely broken the Linux kernel on certain machines so that any larger ia64 servers are stuck on the 4.14 kernel with no fix in sight. Before that, the kernel worked perfectly fine on these machines. I understand that cleaning up code and modernizing things is important, but I think that the top priority should be to deliver something that is stable and usable by the enduser. But kernel development shouldn't be about scratching an itch which I sometimes have the impression is the main driver behind some changes in the kernel. I have personally invested a lot of time and effort in the past years to get Debian into shape on exotic and older architectures and I feel all this effort goes to waste when upstream projects just decide to kill of a certain platform in the kernel or toolchain like it already happened with PowerPCSPE in GCC. Adrian > [1] https://lore.kernel.org/lkml/20210108234430.ga17...@alpha.franken.de/ > [2] https://bugzilla.kernel.org/show_bug.cgi?id=206669 > [3] https://marc.info/?l=linux-sparc=160967865029609=2 > [4] https://marc.info/?l=linux-ia64=156144480821712=2 -- .''`. John Paul Adrian Glaubitz : :' : Debian Developer - glaub...@debian.org `. `' Freie Universitaet Berlin - glaub...@physik.fu-berlin.de `-GPG: 62FF 8A75 84E0 2956 9546 0006 7426 3B37 F5B5 F913
Re: Old platforms: bring out your dead
Hi Arnd!
(Please let's have this cross-posted for more visibility. I only learned about
this
while reading Phoronix news)
> I also looked at non-ARM platforms while preparing for my article. Some of
> these look like they are no longer actively maintained or used, but I'm not
> doing anything about those unless the maintainers would like me to:
>
> * h8300: Steven Rostedt has repeatedly asked about it to be removed
>or fixed in 2020 with no reply. This was killed before in 2013, added back
>in 2015 but has been mostly stale again since 2016
As far as I know, Yoshinori Sato is actively maintaining H8300 support, see:
> https://osdn.net/projects/uclinux-h8/
> * c6x: Added in 2011, this has seen very few updates since, but
> Mark still Acks patches when they come. Like most other DSP platforms,
> the model of running Linux on a DSP appears to have been obsoleted
> by using Linux on ARM with on-chip DSP cores running bare-metal code.
> * sparc/sun4m: A patch for removing 32-bit Sun sparc support (not LEON)
>is currently under review
I don't think this has reached any agreement yet. Multiple people want it to
stay.
> * powerpc/cell: I'm the maintainer and I promised to send a patch to remove
> it.
>it's in my backlog but I will get to it. This is separate from PS3,
> which is actively
>maintained and used; spufs will move to ps3
> * powerpc/chrp (32-bit rs6000, pegasos2): last updated in 2009
I'm still using this. Please keep it.
> * powerpc/amigaone: last updated in 2009
> * powerpc/maple: last updated in 2011
> * m68k/{apollo,hp300,sun3,q40} these are all presumably dead and have not
>seen updates in many years (atari/amiga/mac and coldfire are very much
>alive)
Dito. I have both sun3 and hp300 machines.
> * mips/jazz: last updated in 2007
> * mips/cobalt: last updated in 2010
>
> There might be some value in dropping old CPU support on architectures
> and platforms that are almost exclusively used with more modern CPUs.
> If there are only few users, those can still keep using v5.10 or v5.4 stable
> kernels for a few more years. Again, I'm not doing anything about them,
> except mention them since I did the research.
> These are the oldest one by architecture, and they may have reached
> their best-served-by-date:
>
> * 80486SX/DX: 80386 CPUs were dropped in 2012, and there are
> indications that 486 have no users either on recent kernels.
> There is still the Vortex86 family of SoCs, and the oldest of those were
> 486SX-class, but all the modern ones are 586-class.
> * Alpha 2106x: First generation that lacks some of the later features.
> Since all Alphas are ancient by now, it's hard to tell whether these have
> any fewer users.
I don't see the point in crippling Alpha support. Does this achieve anything?
> * IA64 Merced: first generation Itanium (2001) was quickly replaced by
> Itanium II in 2002.
> * MIPS R3000/TX39xx: 32-bit MIPS-II generation, mostly superseded by
> 64-bit MIPS-III (R4000 and higher) starting in 1991. arch/mips still
> supports these in DECstation and Toshiba Txx9, but it appears that most
> of those machines are of the 64-bit kind. Later MIPS32 such as 4Kc and
> later are rather different and widely used.
> * PowerPC 601 (from 1992) just got removed, later 60x, 4xx, 8xx etc
> are apparently all still used.
> * SuperH SH-2: We discussed removing SH-2 (not J2 or SH-4)
> support in the past, I don't think there were any objections, but
> nobody submitted a patch.
Isn't SH-2 basically J-2? I'm not sure what we would gain here.
> * 68000/68328 (Dragonball): these are less capable than the
> 68020+ or the Coldfire MCF5xxx line and similar to the 68360
> that was removed in 2016.
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] ia64: fix xchg() warning
Hi! On 1/5/21 4:36 PM, Luck, Tony wrote: >> diff --git a/MAINTAINERS b/MAINTAINERS >> index 0f2e55faaf7f..b74093803154 100644 >> --- a/MAINTAINERS >> +++ b/MAINTAINERS >> @@ -8432,11 +8432,8 @@ F: drivers/i3c/ >> F: include/linux/i3c/ >> >> IA64 (Itanium) PLATFORM >> -M: Tony Luck >> -M: Fenghua Yu >> L: linux-i...@vger.kernel.org >> -S: Odd Fixes >> -T: git git://git.kernel.org/pub/scm/linux/kernel/git/aegl/linux.git >> +S: Orphan >> F: Documentation/ia64/ >> F: arch/ia64/ >> >> Is that what you had in mind? I see that Fenghua Yu has not been >> actively involved for a long time. If you are both out, that would >> make the port unmaintained, but that may actually help find someone >> else to either volunteer as a maintainer or pay someone if they >> have a commercial interest. > > Yes. Fenghua has moved to working on other things, so that looks good. > > Acked-by: Tony Luck I wonder whether I can take over maintainership. I'm certainly not experienced as Tony or Fenghua, but I guess one can grow with the task, can't one? 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] ia64: fix xchg() warning
Hi Arnd! On 1/4/21 9:58 AM, Arnd Bergmann wrote: > Change it to a compound expression like the other architectures have > to get a clean defconfig build. Slightly OT: Has your other fix for the timer regression on ia64 already been merged? I can test this patch later today. 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: [sparc64] running stress-ng and a sparc64 hardware / kernel woes
Hi Anatoly! On 1/3/21 1:56 PM, Anatoly Pugachev wrote: > Running a simple stress-ng as a non-privileged (non root) user : > > stress-ng --opcode 1 --timeout 60 --metrics-brief > > will almost always bring the linux kernel to an unusable state, > starting from "Unable to handle kernel NULL pointer dereference", > "Bogus kernel PC [] in fault handler", "Kernel > unaligned access at TPC", "Unable to handle kernel paging request at > virtual address" and "rcu: INFO: rcu_sched detected stalls on > CPUs/tasks"... This looks very similar to the kernel crashes on SPARC that we saw on the buildds for the GCC testsuite in the past (and other packages). I wonder whether we can use stress-ng to provoke the kernel crash on POWER when hosting big-endian VMs with high load on little-endian hosts [1]. Adrian > [1] https://bugzilla.kernel.org/show_bug.cgi?id=206669 -- .''`. 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: [sh] smp-shx3.c: error: ignoring return value of 'request_irq', declared with attribute warn_unused_result
Hello Naresh! On 12/9/20 6:26 PM, Naresh Kamboju wrote: > Linux next 20201209 tag the arch 'sh' defconfig build failed to build with > gcc-8, gcc-9 and gcc-10. > > arch/sh/kernel/cpu/sh4a/smp-shx3.c: In function 'shx3_prepare_cpus': > arch/sh/kernel/cpu/sh4a/smp-shx3.c:76:3: error: ignoring return value > of 'request_irq', declared with attribute warn_unused_result > [-Werror=unused-result] >request_irq(104 + i, ipi_interrupt_handler, >^~~ > IRQF_PERCPU, "IPI", (void *)(long)i); > > > Reported-by: Naresh Kamboju I can't reproduce this issue on Linus' current tree as of today. Maybe the issue has been fixed in the meantime? 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 02/19] sh: Get rid of nmi_count()
Hello Thomas!
On 11/13/20 3:02 PM, Thomas Gleixner wrote:
> nmi_count() is a historical leftover and SH is the only user. Replace it
> with regular per cpu accessors.
>
> Signed-off-by: Thomas Gleixner
> Cc: Yoshinori Sato
> Cc: Rich Felker
> Cc: linux...@vger.kernel.org
> ---
> arch/sh/kernel/irq.c |2 +-
> arch/sh/kernel/traps.c |2 +-
> 2 files changed, 2 insertions(+), 2 deletions(-)
>
> --- a/arch/sh/kernel/irq.c
> +++ b/arch/sh/kernel/irq.c
> @@ -44,7 +44,7 @@ int arch_show_interrupts(struct seq_file
>
> seq_printf(p, "%*s: ", prec, "NMI");
> for_each_online_cpu(j)
> - seq_printf(p, "%10u ", nmi_count(j));
> + seq_printf(p, "%10u ", per_cpu(irq_stat.__nmi_count, j);
> seq_printf(p, " Non-maskable interrupts\n");
>
> seq_printf(p, "%*s: %10u\n", prec, "ERR", atomic_read(_err_count));
> --- a/arch/sh/kernel/traps.c
> +++ b/arch/sh/kernel/traps.c
> @@ -186,7 +186,7 @@ BUILD_TRAP_HANDLER(nmi)
> arch_ftrace_nmi_enter();
>
> nmi_enter();
> - nmi_count(cpu)++;
> + this_cpu_inc(irq_stat.__nmi_count);
>
> switch (notify_die(DIE_NMI, "NMI", regs, 0, vec & 0xff, SIGINT)) {
> case NOTIFY_OK:
>
Just booted my SH7785LCR board with a kernel based on Linus' latest tree
and can confirm that this change does not cause any regressions.
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] sh: boards: Fix the cacography in irq.c
On 11/19/20 11:56 AM, Tang Bin wrote:
> The world 'swtich' is wrong, so fix it.
>
> Signed-off-by: Tang Bin
> ---
> arch/sh/boards/mach-landisk/irq.c | 4 ++--
> 1 file changed, 2 insertions(+), 2 deletions(-)
>
> diff --git a/arch/sh/boards/mach-landisk/irq.c
> b/arch/sh/boards/mach-landisk/irq.c
> index 29b8b1f85..0b672b80c 100644
> --- a/arch/sh/boards/mach-landisk/irq.c
> +++ b/arch/sh/boards/mach-landisk/irq.c
> @@ -26,8 +26,8 @@ enum {
> PCI_INTD, /* PCI int D */
> ATA, /* ATA */
> FATA, /* CF */
> - POWER,/* Power swtich */
> - BUTTON, /* Button swtich */
> + POWER,/* Power switch */
> + BUTTON, /* Button switch */
> };
>
> /* Vectors for LANDISK */
>
Reviewed-by: John Paul Adrian Glaubitz
--
.''`. 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] sh: check return code of request_irq
Hi Nick!
On 12/22/20 9:54 PM, Nick Desaulniers wrote:
> request_irq is marked __must_check, but the call in shx3_prepare_cpus
> has a void return type, so it can't propagate failure to the caller.
> Follow cues from hexagon and just print an error.
>
> Fixes: c7936b9abcf5 ("sh: smp: Hook in to the generic IPI handler for SH-X3
> SMP.")
> Cc: Miguel Ojeda
> Cc: Paul Mundt
> Reported-by: Guenter Roeck
> Signed-off-by: Nick Desaulniers
> ---
> arch/sh/kernel/cpu/sh4a/smp-shx3.c | 5 +++--
> 1 file changed, 3 insertions(+), 2 deletions(-)
>
> diff --git a/arch/sh/kernel/cpu/sh4a/smp-shx3.c
> b/arch/sh/kernel/cpu/sh4a/smp-shx3.c
> index f8a2bec0f260..1261dc7b84e8 100644
> --- a/arch/sh/kernel/cpu/sh4a/smp-shx3.c
> +++ b/arch/sh/kernel/cpu/sh4a/smp-shx3.c
> @@ -73,8 +73,9 @@ static void shx3_prepare_cpus(unsigned int max_cpus)
> BUILD_BUG_ON(SMP_MSG_NR >= 8);
>
> for (i = 0; i < SMP_MSG_NR; i++)
> - request_irq(104 + i, ipi_interrupt_handler,
> - IRQF_PERCPU, "IPI", (void *)(long)i);
> + if (request_irq(104 + i, ipi_interrupt_handler,
> + IRQF_PERCPU, "IPI", (void *)(long)i))
> + pr_err("Failed to request irq %d\n", i);
>
> for (i = 0; i < max_cpus; i++)
> set_cpu_present(i, true);
>
Verified on my SH-7785LCR board. Boots fine.
Tested-by: John Paul Adrian Glaubitz
--
.''`. 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] [sh] fix trivial misannotations
gt; -#define WRITE(d,a) ({if(put_user(d, (typeof (d)*)a)) return -EFAULT;})
> -#define READ(d,a)({if(get_user(d, (typeof (d)*)a)) return -EFAULT;})
> +#define WRITE(d,a) ({if(put_user(d, (typeof (d) __user *)a)) return
> -EFAULT;})
> +#define READ(d,a)({if(get_user(d, (typeof (d) __user *)a)) return
> -EFAULT;})
>
> #define PACK_S(r,f) FP_PACK_SP(,f)
> #define UNPACK_S(f,r)FP_UNPACK_SP(f,)
> diff --git a/arch/sh/mm/nommu.c b/arch/sh/mm/nommu.c
> index 8b4504413c5f..78c4b6e6d33b 100644
> --- a/arch/sh/mm/nommu.c
> +++ b/arch/sh/mm/nommu.c
> @@ -28,9 +28,9 @@ __kernel_size_t __copy_user(void *to, const void *from,
> __kernel_size_t n)
> return 0;
> }
>
> -__kernel_size_t __clear_user(void *to, __kernel_size_t n)
> +__kernel_size_t __clear_user(void __user *to, __kernel_size_t n)
> {
> - memset(to, 0, n);
> + memset((__force void *)to, 0, n);
> return 0;
> }
>
>
Verified on my SH-7785LCR board. Boots fine.
Tested-by: John Paul Adrian Glaubitz
--
.''`. 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] m68k: Enable seccomp architecture tracking
Hi Geert! On 12/20/20 9:51 AM, Geert Uytterhoeven wrote: > To enable seccomp constant action bitmaps, we need to have a static > mapping to the audit architecture and system call table size. > > Signed-off-by: Geert Uytterhoeven > --- > Needed for CONFIG_SECCOMP_CACHE_DEBUG. > Note that upstream doesn't have m68k seccomp support yet. Have we added SECCOMP support for m68k to the kernel yet? It's actually something I was hoping to do over the holidays ;-). 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 PATCH 0/13] sparc32: sunset sun4m and sun4d
On 12/19/20 10:40 PM, Sam Ravnborg wrote: > Please keep the inputs coming independent if you are pro or not > for the sunset of sun4m and sun4d. I would personally be in favor of keeping it and I should finally get my SPARCstation 5 up and running again. 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 v2 05/15] ia64: convert to legacy_timer_tick
Hi Arnd! On 12/18/20 11:13 PM, John Paul Adrian Glaubitz wrote: >> I've attached a patch for a partial revert of my original change, this >> should still work with the final cleanup on top, but restore the loop >> plus the local_irq_enable()/local_irq_disable() that I dropped from >> the original code. Does this make a difference? > > I'll give it a try and report back. Yes. That solves the timer issues. Now there is unfortunately still a second, unrelated regression with the hpsa driver that was introduced by one of the ia64 patches in the mm tree from Andrew which makes the hpsa driver not load at all. Haven't figured out yet what the problem is. 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 v2 05/15] ia64: convert to legacy_timer_tick
timer tick before it's due" > warning > triggered at any point? It's difficult, to be honest. The problem is that the above message spams the whole kernel buffer to the point that the buffer of the built-in serial console is filled up. So I'm not sure if I've seen this message. > I've attached a patch for a partial revert of my original change, this > should still work with the final cleanup on top, but restore the loop > plus the local_irq_enable()/local_irq_disable() that I dropped from > the original code. Does this make a difference? I'll give it a try and 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: [PATCH v2 05/15] ia64: convert to legacy_timer_tick
1:0:0: resetting logical Direct-Access HP LOGICAL VOLUME RAID-0 SSDSmartPathCap- En- Exp=1 [ 908.434923] hpsa :05:00.0: device is ready. [ 908.434923] hpsa :05:00.0: scsi 0:1:0:0: reset logical completed successfully Direct-Access HP LOGICAL VOLUME RAID-0 SSDSmartPathCap- En- Exp=1 [ 908.710922] hpsa :05:00.0: scsi 0:1:0:0: resetting logical Direct-Access HP LOGICAL VOLUME RAID-0 SSDSmartPathCap- En- Exp=1 [ 908.714922] hpsa :05:00.0: device is ready. [ 908.714922] hpsa :05:00.0: scsi 0:1:0:0: reset logical completed successfully Direct-Access HP LOGICAL VOLUME RAID-0 SSDSmartPathCap- En- Exp=1 [ 908.754922] hpsa :05:00.0: scsi 0:1:0:0: resetting logical Direct-Access HP LOGICAL VOLUME RAID-0 SSDSmartPathCap- En- Exp=1 [ 908.758922] hpsa :05:00.0: device is ready. [ 908.758922] hpsa :05:00.0: scsi 0:1:0:0: reset logical completed successfully Direct-Access HP LOGICAL VOLUME RAID-0 SSDSmartPathCap- En- Exp=1 [ 908.788106] systemd[1]: Inserted module 'autofs4' [ 908.972107] systemd[1]: systemd 246.6-5 running in system mode. (+PAM +AUDIT +SELINUX +IMA +APPARMOR +SMACK +SYSVINIT +UTMP +LIBCRYPTSETUP +GCRYPT +GNUTLS +ACL +XZ +LZ4 +ZSTD -SECCOMP +BLKID +ELFUTILS +KMOD +IDN2 -IDN +PCRE2 default-hierarchy=hybrid) [ 908.976013] systemd[1]: Detected architecture ia64. Welcome to Debian GNU/Linux bullseye/sid! [ 909.020014] systemd[1]: Set hostname to . [ 909.178923] hpsa :05:00.0: scsi 0:1:0:0: resetting logical Direct-Access HP LOGICAL VOLUME RAID-0 SSDSmartPathCap- En- Exp=1 [ 909.182922] hpsa :05:00.0: device is ready. [ 909.182922] hpsa :05:00.0: scsi 0:1:0:0: reset logical completed successfully Direct-Access HP LOGICAL VOLUME RAID-0 SSDSmartPathCap- En- Exp=1 [ 909.242922] hpsa :05:00.0: scsi 0:1:0:0: resetting logical Direct-Access HP LOGICAL VOLUME RAID-0 SSDSmartPathCap- En- Exp=1 [ 909.254922] hpsa :05:00.0: device is ready. [ 909.254922] hpsa :05:00.0: scsi 0:1:0:0: reset logical completed successfully Direct-Access HP LOGICAL VOLUME RAID-0 SSDSmartPathCap- En- Exp=1 [ 909.322922] hpsa :05:00.0: scsi 0:1:0:0: resetting logical Direct-Access HP LOGICAL VOLUME RAID-0 SSDSmartPathCap- En- Exp=1 [ 909.334922] hpsa :05:00.0: device is ready. [ 909.334922] hpsa :05:00.0: scsi 0:1:0:0: reset logical completed successfully Direct-Access HP LOGICAL VOLUME RAID-0 SSDSmartPathCap- En- Exp=1 [ 909.360108] INFO: task systemd-sysv-ge:200 blocked for more than 127 seconds. [ 909.360108] Not tainted 5.10.0+ #130 [ 909.360108] "echo 0 > /proc/sys/kernel/hung_task_timeout_secs" disables this message. [ 909.360108] task:systemd-sysv-ge state:D stack:0 pid: 200 ppid: 189 flags:0x [ 909.364108] [ 909.364108] Call Trace: [ 909.364423] [] __schedule+0x890/0x21e0 [ 909.364423] sp=e100487d7b70 bsp=e100487d1748 [ 909.368423] [] schedule+0xa0/0x240 [ 909.368423] sp=e100487d7b90 bsp=e100487d16e0 [ 909.368558] [] io_schedule+0x70/0xa0 [ 909.368558] sp=e100487d7b90 bsp=e100487d16c0 [ 909.372290] [] bit_wait_io+0x20/0xe0 [ 909.372290] sp=e100487d7b90 bsp=e100487d1698 [ 909.374168] rcu: INFO: rcu_sched detected stalls on CPUs/tasks: [ 909.376290] [] __wait_on_bit+0xc0/0x1c0 [ 909.376290] sp=e100487d7b90 bsp=e100487d1648 [ 909.374168] rcu: 3-: (2 ticks this GP) idle=19e/1/0x4002 softirq=1581/1581 fqs=2 [ 909.374168] (detected by 0, t=5661 jiffies, g=1089, q=3) [ 909.376290] [] out_of_line_wait_on_bit+0x120/0x140 [ 909.376290] sp=e100487d7b90 bsp=e100487d1610 [ 909.374168] Task dump for CPU 3: [ 909.374168] task:khungtaskd state:R running task Adrian -- .''`. John Paul Adrian Glaubitz : :' : Debian Developer - glaub...@debian.org `. `' Freie Univ
Re: [PATCH v2 00/13] arch, mm: deprecate DISCONTIGMEM
Hi Christoph! On 12/2/20 9:43 AM, Christoph Hellwig wrote: > On Tue, Dec 01, 2020 at 04:33:01PM +0100, Geert Uytterhoeven wrote: >>> That's a lot of typos in that patch... I wonder why the buildbot hasn't >>> complained about this. Thanks for fixing this up! I'm going to fold this >>> into the original to avoid the breakage. >> >> Does l...@intel.com do ia64 builds? Yes, it builds zx1_defconfig. > > I've never got results. Which is annoying, as debian doesn't ship an > ia64 cross toolchain either, and I can't find any pre-built one that > works for me. The ia64 toolchain available from kernel.org works for me for cross-building a kernel that boots on my RX2600. It's just not a fully-fledged toolchain due to the limitations with libunwind. 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 v2 00/13] arch, mm: deprecate DISCONTIGMEM
Hi Mike! On 12/1/20 4:07 PM, John Paul Adrian Glaubitz wrote: > This fixes the issue for me. > > Tested-by: John Paul Adrian Glaubitz I just booted the kernel from the linux-mm branch and I can't get the hpsa driver to work anymore. Even if I compile it into the kernel, the driver is no longer loaded and hence I can't access the disks. Any idea what could be wrong? 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 v2 00/13] arch, mm: deprecate DISCONTIGMEM
On 12/1/20 2:56 PM, Mike Rapoport wrote:
> (added Jens)
>
> On Tue, Dec 01, 2020 at 01:16:05PM +0100, John Paul Adrian Glaubitz wrote:
>> Hi Mike!
>>
>> On 12/1/20 1:10 PM, Mike Rapoport wrote:
>>> On Tue, Dec 01, 2020 at 12:35:09PM +0100, John Paul Adrian Glaubitz wrote:
>>>> Hi Mike!
>>>>
>>>> On 12/1/20 11:29 AM, Mike Rapoport wrote:
>>>>> These changes are in linux-mm tree (https://www.ozlabs.org/~akpm/mmotm/
>>>>> with a mirror at https://github.com/hnaz/linux-mm)
>>>>>
>>>>> I beleive they will be coming in 5.11.
>>>>
>>>> Just pulled from that tree and gave it a try, it actually fails to build:
>>>>
>>>> LDS arch/ia64/kernel/vmlinux.lds
>>>> AS arch/ia64/kernel/entry.o
>>>> arch/ia64/kernel/entry.S: Assembler messages:
>>>> arch/ia64/kernel/entry.S:710: Error: Operand 2 of `and' should be a
>>>> general register
>>>> arch/ia64/kernel/entry.S:710: Error: qualifying predicate not followed by
>>>> instruction
>>>> arch/ia64/kernel/entry.S:848: Error: Operand 2 of `and' should be a
>>>> general register
>>>> arch/ia64/kernel/entry.S:848: Error: qualifying predicate not followed by
>>>> instruction
>>>> GEN usr/initramfs_data.cpio
>>>> make[1]: *** [scripts/Makefile.build:364: arch/ia64/kernel/entry.o] Error 1
>>>> make: *** [Makefile:1797: arch/ia64/kernel] Error 2
>>>> make: *** Waiting for unfinished jobs
>>>> CC init/do_mounts_initrd.o
>>>> SHIPPED usr/initramfs_inc_data
>>>> AS usr/initramfs_data.o
>>>
>>> Hmm, it was buidling fine with v5.10-rc2-mmotm-2020-11-07-21-40.
>>> I'll try to see what could cause this.
>>>
>>> Do you build with defconfig or do you use a custom config?
>>
>> That's with "localmodconfig", see attached configuration file.
>
> Thanks.
> It seems that the recent addition of TIF_NOTIFY_SIGNAL to ia64 in
> linux-next caused the issue. Can you please try the below patch?
>
> From c4d06cf1c2938e6b2302e7ed0be95c3401181ebb Mon Sep 17 00:00:00 2001
> From: Mike Rapoport
> Date: Tue, 1 Dec 2020 15:40:28 +0200
> Subject: [PATCH] ia64: fix TIF_NOTIFY_SIGNAL implementation
>
> * Replace wrong spelling of TIF_SIGNAL_NOTIFY with the correct
> TIF_NOTIFY_SIGNAL
> * Remove mistyped plural in test_thread_flag() call in
> process::do_notify_resume_user()
> * Use number 5 for TIF_NOTIFY_SIGNAL as 7 is too big and assembler is not
> happy:
>
> AS arch/ia64/kernel/entry.o
> arch/ia64/kernel/entry.S: Assembler messages:
> arch/ia64/kernel/entry.S:710: Error: Operand 2 of `and' should be an 8-bit
> integer (-128-127)
> arch/ia64/kernel/entry.S:710: Error: qualifying predicate not followed by
> instruction
>
> Reported-by: John Paul Adrian Glaubitz
> Fixes: bbb026da151c ("ia64: add support for TIF_NOTIFY_SIGNAL")
> Signed-off-by: Mike Rapoport
> ---
>
> The Fixes tag is based on the commit in next-20201201, I'm not 100% sure
> it is stable
>
> arch/ia64/include/asm/thread_info.h | 4 ++--
> arch/ia64/kernel/process.c | 2 +-
> 2 files changed, 3 insertions(+), 3 deletions(-)
>
> diff --git a/arch/ia64/include/asm/thread_info.h
> b/arch/ia64/include/asm/thread_info.h
> index 759d7d68a5f2..51d20cb37706 100644
> --- a/arch/ia64/include/asm/thread_info.h
> +++ b/arch/ia64/include/asm/thread_info.h
> @@ -103,8 +103,8 @@ struct thread_info {
> #define TIF_SYSCALL_TRACE2 /* syscall trace active */
> #define TIF_SYSCALL_AUDIT3 /* syscall auditing active */
> #define TIF_SINGLESTEP 4 /* restore singlestep on return
> to user mode */
> +#define TIF_NOTIFY_SIGNAL5 /* signal notification exist */
> #define TIF_NOTIFY_RESUME6 /* resumption notification requested */
> -#define TIF_NOTIFY_SIGNAL7 /* signal notification exist */
> #define TIF_MEMDIE 17 /* is terminating due to OOM killer */
> #define TIF_MCA_INIT 18 /* this task is processing MCA or INIT
> */
> #define TIF_DB_DISABLED 19 /* debug trap disabled for
> fsyscall */
> @@ -116,7 +116,7 @@ struct thread_info {
> #define _TIF_SINGLESTEP (1 << TIF_SINGLESTEP)
> #define _TIF_SYSCALL_TRACEAUDIT
> (_TIF_SYSCALL_TRACE|_TIF_SYSCALL_AUDIT|_TIF_SINGLESTEP)
> #define _TIF_NOTIFY_RESUME (1 << TIF_NOTIFY_RESUME)
> -#define _TIF_SIGNAL_NOTIFY (1 << TIF_SIGNAL_NOTIFY)
> +#defin
Re: [PATCH v2 00/13] arch, mm: deprecate DISCONTIGMEM
Hi Mike! On 12/1/20 1:10 PM, Mike Rapoport wrote: > On Tue, Dec 01, 2020 at 12:35:09PM +0100, John Paul Adrian Glaubitz wrote: >> Hi Mike! >> >> On 12/1/20 11:29 AM, Mike Rapoport wrote: >>> These changes are in linux-mm tree (https://www.ozlabs.org/~akpm/mmotm/ >>> with a mirror at https://github.com/hnaz/linux-mm) >>> >>> I beleive they will be coming in 5.11. >> >> Just pulled from that tree and gave it a try, it actually fails to build: >> >> LDS arch/ia64/kernel/vmlinux.lds >> AS arch/ia64/kernel/entry.o >> arch/ia64/kernel/entry.S: Assembler messages: >> arch/ia64/kernel/entry.S:710: Error: Operand 2 of `and' should be a general >> register >> arch/ia64/kernel/entry.S:710: Error: qualifying predicate not followed by >> instruction >> arch/ia64/kernel/entry.S:848: Error: Operand 2 of `and' should be a general >> register >> arch/ia64/kernel/entry.S:848: Error: qualifying predicate not followed by >> instruction >> GEN usr/initramfs_data.cpio >> make[1]: *** [scripts/Makefile.build:364: arch/ia64/kernel/entry.o] Error 1 >> make: *** [Makefile:1797: arch/ia64/kernel] Error 2 >> make: *** Waiting for unfinished jobs >> CC init/do_mounts_initrd.o >> SHIPPED usr/initramfs_inc_data >> AS usr/initramfs_data.o > > Hmm, it was buidling fine with v5.10-rc2-mmotm-2020-11-07-21-40. > I'll try to see what could cause this. > > Do you build with defconfig or do you use a custom config? That's with "localmodconfig", see attached configuration file. 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 # # Automatically generated file; DO NOT EDIT. # Linux/ia64 5.10.0-rc5-mm1 Kernel Configuration # CONFIG_CC_VERSION_TEXT="gcc (Debian 10.2.0-19) 10.2.0" CONFIG_CC_IS_GCC=y CONFIG_GCC_VERSION=100200 CONFIG_LD_VERSION=23501 CONFIG_CLANG_VERSION=0 CONFIG_CC_CAN_LINK=y CONFIG_CC_CAN_LINK_STATIC=y CONFIG_CC_HAS_ASM_GOTO=y CONFIG_CC_HAS_ASM_INLINE=y CONFIG_IRQ_WORK=y # # General setup # CONFIG_INIT_ENV_ARG_LIMIT=32 # CONFIG_COMPILE_TEST is not set CONFIG_LOCALVERSION="" # CONFIG_LOCALVERSION_AUTO is not set CONFIG_BUILD_SALT="4.19.0-5-mckinley" CONFIG_DEFAULT_INIT="" CONFIG_DEFAULT_HOSTNAME="(none)" CONFIG_SWAP=y CONFIG_SYSVIPC=y CONFIG_SYSVIPC_SYSCTL=y CONFIG_POSIX_MQUEUE=y CONFIG_POSIX_MQUEUE_SYSCTL=y # CONFIG_WATCH_QUEUE is not set CONFIG_CROSS_MEMORY_ATTACH=y # CONFIG_USELIB is not set CONFIG_AUDIT=y CONFIG_HAVE_ARCH_AUDITSYSCALL=y CONFIG_AUDITSYSCALL=y # # IRQ subsystem # CONFIG_GENERIC_IRQ_LEGACY=y CONFIG_GENERIC_IRQ_PROBE=y CONFIG_GENERIC_IRQ_SHOW=y CONFIG_GENERIC_PENDING_IRQ=y CONFIG_IRQ_DOMAIN=y CONFIG_IRQ_DOMAIN_HIERARCHY=y CONFIG_GENERIC_MSI_IRQ=y CONFIG_GENERIC_MSI_IRQ_DOMAIN=y # CONFIG_GENERIC_IRQ_DEBUGFS is not set # end of IRQ subsystem CONFIG_ARCH_CLOCKSOURCE_DATA=y CONFIG_GENERIC_TIME_VSYSCALL=y CONFIG_LEGACY_TIMER_TICK=y # CONFIG_PREEMPT_NONE is not set CONFIG_PREEMPT_VOLUNTARY=y # CONFIG_PREEMPT is not set # # CPU/Task time and stats accounting # CONFIG_TICK_CPU_ACCOUNTING=y # CONFIG_VIRT_CPU_ACCOUNTING_NATIVE is not set CONFIG_BSD_PROCESS_ACCT=y CONFIG_BSD_PROCESS_ACCT_V3=y CONFIG_TASKSTATS=y CONFIG_TASK_DELAY_ACCT=y CONFIG_TASK_XACCT=y CONFIG_TASK_IO_ACCOUNTING=y # CONFIG_PSI is not set # end of CPU/Task time and stats accounting CONFIG_CPU_ISOLATION=y # # RCU Subsystem # CONFIG_TREE_RCU=y # CONFIG_RCU_EXPERT is not set CONFIG_SRCU=y CONFIG_TREE_SRCU=y CONFIG_TASKS_RCU_GENERIC=y CONFIG_TASKS_TRACE_RCU=y CONFIG_RCU_STALL_COMMON=y CONFIG_RCU_NEED_SEGCBLIST=y # end of RCU Subsystem CONFIG_BUILD_BIN2C=y CONFIG_IKCONFIG=m # CONFIG_IKCONFIG_PROC is not set # CONFIG_IKHEADERS is not set CONFIG_LOG_BUF_SHIFT=17 CONFIG_LOG_CPU_MAX_BUF_SHIFT=12 CONFIG_PRINTK_SAFE_LOG_BUF_SHIFT=13 CONFIG_HAVE_UNSTABLE_SCHED_CLOCK=y # # Scheduler features # # CONFIG_UCLAMP_TASK is not set # end of Scheduler features CONFIG_CC_HAS_INT128=y CONFIG_CGROUPS=y CONFIG_PAGE_COUNTER=y CONFIG_MEMCG=y CONFIG_MEMCG_SWAP=y CONFIG_MEMCG_KMEM=y CONFIG_BLK_CGROUP=y CONFIG_CGROUP_WRITEBACK=y CONFIG_CGROUP_SCHED=y CONFIG_FAIR_GROUP_SCHED=y CONFIG_CFS_BANDWIDTH=y # CONFIG_RT_GROUP_SCHED is not set CONFIG_CGROUP_PIDS=y CONFIG_CGROUP_RDMA=y CONFIG_CGROUP_FREEZER=y # CONFIG_CGROUP_HUGETLB is not set CONFIG_CPUSETS=y CONFIG_PROC_PID_CPUSET=y CONFIG_CGROUP_DEVICE=y CONFIG_CGROUP_CPUACCT=y CONFIG_CGROUP_BPF=y # CONFIG_CGROUP_DEBUG is not set CONFIG_SOCK_CGROUP_DATA=y CONFIG_NAMESPACES=y CONFIG_UTS_NS=y CONFIG_IPC_NS=y CONFIG_USER_NS=y CONFIG_PID_NS=y CONFIG_NET_NS=y CONFIG_CHECKPOINT_RESTORE=y CONFIG_SCHED_AUTOGROUP=y # CONFIG_SYSFS_DEPRECATED is
Re: [PATCH v2 00/13] arch, mm: deprecate DISCONTIGMEM
Hi Mike! On 12/1/20 11:29 AM, Mike Rapoport wrote: > These changes are in linux-mm tree (https://www.ozlabs.org/~akpm/mmotm/ > with a mirror at https://github.com/hnaz/linux-mm) > > I beleive they will be coming in 5.11. Just pulled from that tree and gave it a try, it actually fails to build: LDS arch/ia64/kernel/vmlinux.lds AS arch/ia64/kernel/entry.o arch/ia64/kernel/entry.S: Assembler messages: arch/ia64/kernel/entry.S:710: Error: Operand 2 of `and' should be a general register arch/ia64/kernel/entry.S:710: Error: qualifying predicate not followed by instruction arch/ia64/kernel/entry.S:848: Error: Operand 2 of `and' should be a general register arch/ia64/kernel/entry.S:848: Error: qualifying predicate not followed by instruction GEN usr/initramfs_data.cpio make[1]: *** [scripts/Makefile.build:364: arch/ia64/kernel/entry.o] Error 1 make: *** [Makefile:1797: arch/ia64/kernel] Error 2 make: *** Waiting for unfinished jobs CC init/do_mounts_initrd.o SHIPPED usr/initramfs_inc_data AS usr/initramfs_data.o 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 v2 00/13] arch, mm: deprecate DISCONTIGMEM
Hi Mike! On 11/17/20 7:23 AM, Mike Rapoport wrote: >> Apologies for the late reply. Is this still relevant for testing? >> >> I have already successfully tested v1 of the patch set, shall I test v2? > > There were minor differences only for m68k between the versions. I've > verified them on ARAnyM but if you have a real machine a run there would > be nice. I have just built a fresh kernel from the tip of Linus' tree and it boots fine on my RX-2600: root@glendronach:~# uname -a Linux glendronach 5.10.0-rc6 #6 SMP Tue Dec 1 04:52:49 CET 2020 ia64 GNU/Linux root@glendronach:~# No issues observed so far. Looking at the git log, it seems these changes haven't been merged for 5.10 yet. I assume they will be coming with 5.11? 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] selftests/seccomp: sh: Fix register names
On 11/17/20 9:56 PM, Kees Cook wrote:
> It looks like the seccomp selftests were never actually built for sh.
> This fixes it, though I don't have an environment to do a runtime test
> of it yet.
>
> Fixes: 0bb605c2c7f2b4b3 ("sh: Add SECCOMP_FILTER")
> Signed-off-by: Kees Cook
> ---
> tools/testing/selftests/seccomp/seccomp_bpf.c | 4 ++--
> 1 file changed, 2 insertions(+), 2 deletions(-)
>
> diff --git a/tools/testing/selftests/seccomp/seccomp_bpf.c
> b/tools/testing/selftests/seccomp/seccomp_bpf.c
> index 7f7ecfcd66db..26c72f2b61b1 100644
> --- a/tools/testing/selftests/seccomp/seccomp_bpf.c
> +++ b/tools/testing/selftests/seccomp/seccomp_bpf.c
> @@ -1804,8 +1804,8 @@ TEST_F(TRACE_poke, getpid_runs_normally)
> #define SYSCALL_RET(_regs) (_regs).a[(_regs).windowbase * 4 + 2]
> #elif defined(__sh__)
> # define ARCH_REGS struct pt_regs
> -# define SYSCALL_NUM(_regs) (_regs).gpr[3]
> -# define SYSCALL_RET(_regs) (_regs).gpr[0]
> +# define SYSCALL_NUM(_regs) (_regs).regs[3]
> +# define SYSCALL_RET(_regs) (_regs).regs[0]
> #else
> # error "Do not know how to find your architecture's registers and syscalls"
> #endif
Yes, this fix is indeed necessary. However, there is another build issue that I
ran into
and I'm not sure why it happens, but commenting out "#include "
in
../clone3/clone3_selftests.h fixes it.
root@tirpitz:..selftests/seccomp> make
gcc -Wl,-no-as-needed -Wall -lpthread seccomp_bpf.c
/usr/src/linux-5.9.8/tools/testing/selftests/kselftest_harness.h
/usr/src/linux-5.9.8/tools/testing/selftests/kselftest.h -o
/usr/src/linux-5.9.8/tools/testing/selftests/seccomp/seccomp_bpf
In file included from seccomp_bpf.c:55:
../clone3/clone3_selftests.h:28:8: error: redefinition of ‘struct clone_args’
28 | struct clone_args {
|^~
In file included from ../clone3/clone3_selftests.h:8,
from seccomp_bpf.c:55:
/usr/include/linux/sched.h:92:8: note: originally defined here
92 | struct clone_args {
|^~
make: *** [../lib.mk:140:
/usr/src/linux-5.9.8/tools/testing/selftests/seccomp/seccomp_bpf] Error 1
root@tirpitz:..selftests/seccomp>
Your actual register naming fix is correct in any case as without your patch,
building the seccomp
selftest fails with:
seccomp_bpf.c: In function ‘get_syscall’:
seccomp_bpf.c:1741:37: error: ‘struct pt_regs’ has no member named ‘gpr’; did
you mean ‘pr’?
1741 | # define SYSCALL_NUM(_regs) (_regs).gpr[3]
| ^~~
seccomp_bpf.c:1794:9: note: in expansion of macro ‘SYSCALL_NUM’
1794 | return SYSCALL_NUM(regs);
| ^~~
seccomp_bpf.c: In function ‘change_syscall’:
seccomp_bpf.c:1741:37: error: ‘struct pt_regs’ has no member named ‘gpr’; did
you mean ‘pr’?
1741 | # define SYSCALL_NUM(_regs) (_regs).gpr[3]
| ^~~
seccomp_bpf.c:1817:3: note: in expansion of macro ‘SYSCALL_NUM’
1817 | SYSCALL_NUM(regs) = syscall;
| ^~~
seccomp_bpf.c:1742:37: error: ‘struct pt_regs’ has no member named ‘gpr’; did
you mean ‘pr’?
1742 | # define SYSCALL_RET(_regs) (_regs).gpr[0]
| ^~~
seccomp_bpf.c:1859:3: note: in expansion of macro ‘SYSCALL_RET’
1859 | SYSCALL_RET(regs) = result;
| ^~~
seccomp_bpf.c: In function ‘get_syscall’:
seccomp_bpf.c:1795:1: warning: control reaches end of non-void function
[-Wreturn-type]
1795 | }
| ^
make: *** [../lib.mk:140:
/usr/src/linux-5.9.8/tools/testing/selftests/seccomp/seccomp_bpf] Error 1
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] selftests/seccomp: sh: Fix register names
On 11/17/20 10:35 PM, Kees Cook wrote: >> We were testing libsecomp itself but I think we might have forgotten the >> self-test. Not sure how these are run. > > If you're building natively, you can just build and run: > > cd tools/testing/selftests/seccomp > make > ./seccomp_bpf Thanks, I'll give that a try. 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] selftests/seccomp: sh: Fix register names
Hi Kees! On 11/17/20 9:56 PM, Kees Cook wrote: > It looks like the seccomp selftests were never actually built for sh. > This fixes it, though I don't have an environment to do a runtime test > of it yet. We were testing libsecomp itself but I think we might have forgotten the self-test. Not sure how these are run. 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 v2 00/13] arch, mm: deprecate DISCONTIGMEM
Hi Mike! On 11/17/20 7:23 AM, Mike Rapoport wrote: > There were minor differences only for m68k between the versions. I've > verified them on ARAnyM but if you have a real machine a run there would > be nice. I do have a real machine (Amiga 68060) but it's currently not set up (but it will be in the near future). So I'm not sure if I can test the change within a short time frame. I will certainly report back when I run into issues on real hardware. 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: [PATCH v2 00/13] arch, mm: deprecate DISCONTIGMEM
Hi! On 11/1/20 6:04 PM, Mike Rapoport wrote: > It's been a while since DISCONTIGMEM is generally considered deprecated, > but it is still used by four architectures. This set replaces DISCONTIGMEM > with a different way to handle holes in the memory map and marks > DISCONTIGMEM configuration as BROKEN in Kconfigs of these architectures with > the intention to completely remove it in several releases. > > While for 64-bit alpha and ia64 the switch to SPARSEMEM is quite obvious > and was a matter of moving some bits around, for smaller 32-bit arc and > m68k SPARSEMEM is not necessarily the best thing to do. > > On 32-bit machines SPARSEMEM would require large sections to make section > index fit in the page flags, but larger sections mean that more memory is > wasted for unused memory map. > > Besides, pfn_to_page() and page_to_pfn() become less efficient, at least on > arc. > > So I've decided to generalize arm's approach for freeing of unused parts of > the memory map with FLATMEM and enable it for both arc and m68k. The > details are in the description of patches 10 (arc) and 13 (m68k). Apologies for the late reply. Is this still relevant for testing? I have already successfully tested v1 of the patch set, shall I test v2? 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] fs/affs: Fix basic permission bits to actually work
Hi Max! On 8/27/20 5:49 PM, Max Staudt wrote: > The basic permission bits (protection bits in AmigaOS) have been broken > in Linux' affs - it would only set bits, but never delete them. > Also, contrary to the documentation, the Archived bit was not handled. > > Let's fix this for good, and set the bits such that Linux and classic > AmigaOS can coexist in the most peaceful manner. > > Also, update the documentation to represent the current state of things. Has there already been any progress on reviewing this? Adrian -- .''`. John Paul Adrian Glaubitz : :' : Debian Developer - glaub...@debian.org `. `' Freie Universitaet Berlin - glaub...@physik.fu-berlin.de `-GPG: 62FF 8A75 84E0 2956 9546 0006 7426 3B37 F5B5 F913
