Kernel test builds currently fail for several architectures with error
messages such as the following.
drivers/net/ethernet/i825xx/82596.c: In function 'i82596_probe':
./arch/m68k/include/asm/string.h:72:25: error:
'__builtin_memcpy' reading 6 bytes from a region of size 0
[-Werror=stringop-overread]
Such warnings may be reported by gcc 11.x for string and memory operations
on fixed addresses if gcc's builtin functions are used for those
operations.
This patch series introduces absolute_pointer() to fix the problem.
absolute_pointer() disassociates a pointer from its originating symbol
type and context, and thus prevents gcc from making assumptions about
pointers passed to memory operations.
v2: Drop parisc patch (the problem will be solved differently)
alpha: Move setup.h out of uapi
Define COMMAND_LINE for alpha as absolute_pointer instead of using
absolute_pointer on the define.
----------------------------------------------------------------
Guenter Roeck (4):
compiler.h: Introduce absolute_pointer macro
net: i825xx: Use absolute_pointer for memcpy from fixed memory location
alpha: Move setup.h out of uapi
alpha: Use absolute_pointer to define COMMAND_LINE
arch/alpha/include/asm/setup.h | 43 +++++++++++++++++++++++++++++++++++++
arch/alpha/include/uapi/asm/setup.h | 42 +++---------------------------------
drivers/net/ethernet/i825xx/82596.c | 2 +-
include/linux/compiler.h | 2 ++
4 files changed, 49 insertions(+), 40 deletions(-)
create mode 100644 arch/alpha/include/asm/setup.h
gcc 11.x reports the following compiler warning/error.
drivers/net/ethernet/i825xx/82596.c: In function 'i82596_probe':
./arch/m68k/include/asm/string.h:72:25: error:
'__builtin_memcpy' reading 6 bytes from a region of size 0
[-Werror=stringop-overread]
Use absolute_pointer() to work around the problem.
Cc: Geert Uytterhoeven <[email protected]>
Signed-off-by: Guenter Roeck <[email protected]>
---
v2: No change
drivers/net/ethernet/i825xx/82596.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/drivers/net/ethernet/i825xx/82596.c b/drivers/net/ethernet/i825xx/82596.c
index b8a40146b895..b482f6f633bd 100644
--- a/drivers/net/ethernet/i825xx/82596.c
+++ b/drivers/net/ethernet/i825xx/82596.c
@@ -1144,7 +1144,7 @@ static struct net_device * __init i82596_probe(void)
err = -ENODEV;
goto out;
}
- memcpy(eth_addr, (void *) 0xfffc1f2c, ETH_ALEN); /* YUCK! Get addr from NOVRAM */
+ memcpy(eth_addr, absolute_pointer(0xfffc1f2c), ETH_ALEN); /* YUCK! Get addr from NOVRAM */
dev->base_addr = MVME_I596_BASE;
dev->irq = (unsigned) MVME16x_IRQ_I596;
goto found;
--
2.33.0
alpha:allmodconfig fails to build with the following error
when using gcc 11.x.
arch/alpha/kernel/setup.c: In function 'setup_arch':
arch/alpha/kernel/setup.c:493:13: error:
'strcmp' reading 1 or more bytes from a region of size 0
Avoid the problem by declaring COMMAND_LINE as absolute_pointer().
Signed-off-by: Guenter Roeck <[email protected]>
---
v2: Declare COMMAND_LINE as absolute_pointer instead of using absolute_pointer
on the define
arch/alpha/include/asm/setup.h | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/arch/alpha/include/asm/setup.h b/arch/alpha/include/asm/setup.h
index 58fe3f45a235..262aab99e391 100644
--- a/arch/alpha/include/asm/setup.h
+++ b/arch/alpha/include/asm/setup.h
@@ -36,7 +36,7 @@
* place.
*/
#define PARAM ZERO_PGE
-#define COMMAND_LINE ((char *)(PARAM + 0x0000))
+#define COMMAND_LINE ((char *)(absolute_pointer(PARAM + 0x0000)))
#define INITRD_START (*(unsigned long *) (PARAM+0x100))
#define INITRD_SIZE (*(unsigned long *) (PARAM+0x108))
--
2.33.0
absolute_pointer() disassociates a pointer from its originating symbol
type and context. Use it to prevent compiler warnings/errors such as
drivers/net/ethernet/i825xx/82596.c: In function 'i82596_probe':
./arch/m68k/include/asm/string.h:72:25: error:
'__builtin_memcpy' reading 6 bytes from a region of size 0
[-Werror=stringop-overread]
Such warnings may be reported by gcc 11.x for string and memory operations
on fixed addresses.
Suggested-by: Linus Torvalds <[email protected]>
Signed-off-by: Guenter Roeck <[email protected]>
---
v2: No change
include/linux/compiler.h | 2 ++
1 file changed, 2 insertions(+)
diff --git a/include/linux/compiler.h b/include/linux/compiler.h
index b67261a1e3e9..3d5af56337bd 100644
--- a/include/linux/compiler.h
+++ b/include/linux/compiler.h
@@ -188,6 +188,8 @@ void ftrace_likely_update(struct ftrace_likely_data *f, int val,
(typeof(ptr)) (__ptr + (off)); })
#endif
+#define absolute_pointer(val) RELOC_HIDE((void *)(val), 0)
+
#ifndef OPTIMIZER_HIDE_VAR
/* Make the optimizer believe the variable can be manipulated arbitrarily. */
#define OPTIMIZER_HIDE_VAR(var) \
--
2.33.0
Most of the contents of setup.h have no value for userspace
applications. The file was probably moved to uapi accidentally.
Keep the file in uapi to define the alpha-specific COMMAND_LINE_SIZE.
Move all other defines to arch/alpha/include/asm/setup.h.
Suggested-by: Linus Torvalds <[email protected]>
Signed-off-by: Guenter Roeck <[email protected]>
---
v2: Added patch
arch/alpha/include/asm/setup.h | 43 +++++++++++++++++++++++++++++
arch/alpha/include/uapi/asm/setup.h | 42 ++--------------------------
2 files changed, 46 insertions(+), 39 deletions(-)
create mode 100644 arch/alpha/include/asm/setup.h
diff --git a/arch/alpha/include/asm/setup.h b/arch/alpha/include/asm/setup.h
new file mode 100644
index 000000000000..58fe3f45a235
--- /dev/null
+++ b/arch/alpha/include/asm/setup.h
@@ -0,0 +1,43 @@
+/* SPDX-License-Identifier: GPL-2.0-only */
+#ifndef __ALPHA_SETUP_H
+#define __ALPHA_SETUP_H
+
+#include <uapi/asm/setup.h>
+
+/*
+ * We leave one page for the initial stack page, and one page for
+ * the initial process structure. Also, the console eats 3 MB for
+ * the initial bootloader (one of which we can reclaim later).
+ */
+#define BOOT_PCB 0x20000000
+#define BOOT_ADDR 0x20000000
+/* Remove when official MILO sources have ELF support: */
+#define BOOT_SIZE (16*1024)
+
+#ifdef CONFIG_ALPHA_LEGACY_START_ADDRESS
+#define KERNEL_START_PHYS 0x300000 /* Old bootloaders hardcoded this. */
+#else
+#define KERNEL_START_PHYS 0x1000000 /* required: Wildfire/Titan/Marvel */
+#endif
+
+#define KERNEL_START (PAGE_OFFSET+KERNEL_START_PHYS)
+#define SWAPPER_PGD KERNEL_START
+#define INIT_STACK (PAGE_OFFSET+KERNEL_START_PHYS+0x02000)
+#define EMPTY_PGT (PAGE_OFFSET+KERNEL_START_PHYS+0x04000)
+#define EMPTY_PGE (PAGE_OFFSET+KERNEL_START_PHYS+0x08000)
+#define ZERO_PGE (PAGE_OFFSET+KERNEL_START_PHYS+0x0A000)
+
+#define START_ADDR (PAGE_OFFSET+KERNEL_START_PHYS+0x10000)
+
+/*
+ * This is setup by the secondary bootstrap loader. Because
+ * the zero page is zeroed out as soon as the vm system is
+ * initialized, we need to copy things out into a more permanent
+ * place.
+ */
+#define PARAM ZERO_PGE
+#define COMMAND_LINE ((char *)(PARAM + 0x0000))
+#define INITRD_START (*(unsigned long *) (PARAM+0x100))
+#define INITRD_SIZE (*(unsigned long *) (PARAM+0x108))
+
+#endif
diff --git a/arch/alpha/include/uapi/asm/setup.h b/arch/alpha/include/uapi/asm/setup.h
index 13b7ee465b0e..f881ea5947cb 100644
--- a/arch/alpha/include/uapi/asm/setup.h
+++ b/arch/alpha/include/uapi/asm/setup.h
@@ -1,43 +1,7 @@
/* SPDX-License-Identifier: GPL-2.0 WITH Linux-syscall-note */
-#ifndef __ALPHA_SETUP_H
-#define __ALPHA_SETUP_H
+#ifndef _UAPI__ALPHA_SETUP_H
+#define _UAPI__ALPHA_SETUP_H
#define COMMAND_LINE_SIZE 256
-/*
- * We leave one page for the initial stack page, and one page for
- * the initial process structure. Also, the console eats 3 MB for
- * the initial bootloader (one of which we can reclaim later).
- */
-#define BOOT_PCB 0x20000000
-#define BOOT_ADDR 0x20000000
-/* Remove when official MILO sources have ELF support: */
-#define BOOT_SIZE (16*1024)
-
-#ifdef CONFIG_ALPHA_LEGACY_START_ADDRESS
-#define KERNEL_START_PHYS 0x300000 /* Old bootloaders hardcoded this. */
-#else
-#define KERNEL_START_PHYS 0x1000000 /* required: Wildfire/Titan/Marvel */
-#endif
-
-#define KERNEL_START (PAGE_OFFSET+KERNEL_START_PHYS)
-#define SWAPPER_PGD KERNEL_START
-#define INIT_STACK (PAGE_OFFSET+KERNEL_START_PHYS+0x02000)
-#define EMPTY_PGT (PAGE_OFFSET+KERNEL_START_PHYS+0x04000)
-#define EMPTY_PGE (PAGE_OFFSET+KERNEL_START_PHYS+0x08000)
-#define ZERO_PGE (PAGE_OFFSET+KERNEL_START_PHYS+0x0A000)
-
-#define START_ADDR (PAGE_OFFSET+KERNEL_START_PHYS+0x10000)
-
-/*
- * This is setup by the secondary bootstrap loader. Because
- * the zero page is zeroed out as soon as the vm system is
- * initialized, we need to copy things out into a more permanent
- * place.
- */
-#define PARAM ZERO_PGE
-#define COMMAND_LINE ((char*)(PARAM + 0x0000))
-#define INITRD_START (*(unsigned long *) (PARAM+0x100))
-#define INITRD_SIZE (*(unsigned long *) (PARAM+0x108))
-
-#endif
+#endif /* _UAPI__ALPHA_SETUP_H */
--
2.33.0
On Wed, Sep 15, 2021 at 5:52 AM Guenter Roeck <[email protected]> wrote:
> absolute_pointer() disassociates a pointer from its originating symbol
> type and context. Use it to prevent compiler warnings/errors such as
>
> drivers/net/ethernet/i825xx/82596.c: In function 'i82596_probe':
> ./arch/m68k/include/asm/string.h:72:25: error:
> '__builtin_memcpy' reading 6 bytes from a region of size 0
> [-Werror=stringop-overread]
>
> Such warnings may be reported by gcc 11.x for string and memory operations
> on fixed addresses.
>
> Suggested-by: Linus Torvalds <[email protected]>
> Signed-off-by: Guenter Roeck <[email protected]>
Reviewed-by: Geert Uytterhoeven <[email protected]>
Gr{oetje,eeting}s,
Geert
--
Geert Uytterhoeven -- There's lots of Linux beyond ia32 -- [email protected]
In personal conversations with technical people, I call myself a hacker. But
when I'm talking to journalists I just say "programmer" or something like that.
-- Linus Torvalds
On Wed, Sep 15, 2021 at 5:52 AM Guenter Roeck <[email protected]> wrote:
> gcc 11.x reports the following compiler warning/error.
>
> drivers/net/ethernet/i825xx/82596.c: In function 'i82596_probe':
> ./arch/m68k/include/asm/string.h:72:25: error:
> '__builtin_memcpy' reading 6 bytes from a region of size 0
> [-Werror=stringop-overread]
>
> Use absolute_pointer() to work around the problem.
>
> Cc: Geert Uytterhoeven <[email protected]>
> Signed-off-by: Guenter Roeck <[email protected]>
Reviewed-by: Geert Uytterhoeven <[email protected]>
Gr{oetje,eeting}s,
Geert
--
Geert Uytterhoeven -- There's lots of Linux beyond ia32 -- [email protected]
In personal conversations with technical people, I call myself a hacker. But
when I'm talking to journalists I just say "programmer" or something like that.
-- Linus Torvalds
Hi Günter,
On Wed, Sep 15, 2021 at 5:52 AM Guenter Roeck <[email protected]> wrote:
> absolute_pointer() disassociates a pointer from its originating symbol
> type and context. Use it to prevent compiler warnings/errors such as
>
> drivers/net/ethernet/i825xx/82596.c: In function 'i82596_probe':
> ./arch/m68k/include/asm/string.h:72:25: error:
> '__builtin_memcpy' reading 6 bytes from a region of size 0
> [-Werror=stringop-overread]
>
> Such warnings may be reported by gcc 11.x for string and memory operations
> on fixed addresses.
>
> Suggested-by: Linus Torvalds <[email protected]>
> Signed-off-by: Guenter Roeck <[email protected]>
> ---
> v2: No change
>
> include/linux/compiler.h | 2 ++
> 1 file changed, 2 insertions(+)
>
> diff --git a/include/linux/compiler.h b/include/linux/compiler.h
> index b67261a1e3e9..3d5af56337bd 100644
> --- a/include/linux/compiler.h
> +++ b/include/linux/compiler.h
> @@ -188,6 +188,8 @@ void ftrace_likely_update(struct ftrace_likely_data *f, int val,
> (typeof(ptr)) (__ptr + (off)); })
> #endif
>
> +#define absolute_pointer(val) RELOC_HIDE((void *)(val), 0)
I guess we're not worried about "val" being evaluated multiple
times inside RELOC_HIDE(), as this is mainly intended for constants?
Gr{oetje,eeting}s,
Geert
--
Geert Uytterhoeven -- There's lots of Linux beyond ia32 -- [email protected]
In personal conversations with technical people, I call myself a hacker. But
when I'm talking to journalists I just say "programmer" or something like that.
-- Linus Torvalds
On 9/15/21 12:13 AM, Geert Uytterhoeven wrote:
> Hi Günter,
>
> On Wed, Sep 15, 2021 at 5:52 AM Guenter Roeck <[email protected]> wrote:
>> absolute_pointer() disassociates a pointer from its originating symbol
>> type and context. Use it to prevent compiler warnings/errors such as
>>
>> drivers/net/ethernet/i825xx/82596.c: In function 'i82596_probe':
>> ./arch/m68k/include/asm/string.h:72:25: error:
>> '__builtin_memcpy' reading 6 bytes from a region of size 0
>> [-Werror=stringop-overread]
>>
>> Such warnings may be reported by gcc 11.x for string and memory operations
>> on fixed addresses.
>>
>> Suggested-by: Linus Torvalds <[email protected]>
>> Signed-off-by: Guenter Roeck <[email protected]>
>> ---
>> v2: No change
>>
>> include/linux/compiler.h | 2 ++
>> 1 file changed, 2 insertions(+)
>>
>> diff --git a/include/linux/compiler.h b/include/linux/compiler.h
>> index b67261a1e3e9..3d5af56337bd 100644
>> --- a/include/linux/compiler.h
>> +++ b/include/linux/compiler.h
>> @@ -188,6 +188,8 @@ void ftrace_likely_update(struct ftrace_likely_data *f, int val,
>> (typeof(ptr)) (__ptr + (off)); })
>> #endif
>>
>> +#define absolute_pointer(val) RELOC_HIDE((void *)(val), 0)
>
> I guess we're not worried about "val" being evaluated multiple
> times inside RELOC_HIDE(), as this is mainly intended for constants?
>
No, we are not. It is quite similar to RELOC_HIDE() in that regard.
Guenter
On Tue, Sep 14, 2021 at 8:52 PM Guenter Roeck <[email protected]> wrote:
>
> This patch series introduces absolute_pointer() to fix the problem.
> absolute_pointer() disassociates a pointer from its originating symbol
> type and context, and thus prevents gcc from making assumptions about
> pointers passed to memory operations.
Ok, I've applied this to my tree.
I note that the physical BOOT_PCB addresses in the alpha setup.h file
might be useful for things like MILO in user space, but since I
couldn't even find MILO sources any more, I couldn't really check.
I suspect alpha is basically on life support and presumably nobody
would ever compile a bootloader anyway, so it's unlikely to matter.
If somebody does find any issues, we'll know better and we can ask
where the user space sources are that might use that alpha setup.h
file.
Linus
On 9/15/21 12:18 PM, Linus Torvalds wrote:
> On Tue, Sep 14, 2021 at 8:52 PM Guenter Roeck <[email protected]> wrote:
>>
>> This patch series introduces absolute_pointer() to fix the problem.
>> absolute_pointer() disassociates a pointer from its originating symbol
>> type and context, and thus prevents gcc from making assumptions about
>> pointers passed to memory operations.
>
> Ok, I've applied this to my tree.
>
> I note that the physical BOOT_PCB addresses in the alpha setup.h file
> might be useful for things like MILO in user space, but since I
> couldn't even find MILO sources any more, I couldn't really check.
>
> I suspect alpha is basically on life support and presumably nobody
> would ever compile a bootloader anyway, so it's unlikely to matter.
>
> If somebody does find any issues, we'll know better and we can ask
> where the user space sources are that might use that alpha setup.h
> file.
>
FWIW, I did find a set of MILO sources. Search for milo-2.2-18.tar.bz2;
it points to a variety of gentoo mirrors.
That version does not reference BOOT_PCB. I thought about removing this
define as well as a couple of other unused defines, but wanted to keep
the changes minimal.
On a side note, we may revive the parisc patch. Helge isn't entirely
happy with the other solution for parisc; it is quite invasive and
touches a total of 19 files if I counted correctly.
Thanks,
Guenter
On Wed, Sep 15, 2021 at 12:35 PM Guenter Roeck <[email protected]> wrote:
>
> On a side note, we may revive the parisc patch. Helge isn't entirely
> happy with the other solution for parisc; it is quite invasive and
> touches a total of 19 files if I counted correctly.
Ok, my suggestion to use the linker was not a "do it this way", it
really was just a "maybe alternate approach". So no objections if
absolute_pointer() ends up being the simpler solution.
What other notable issues end up being still live? I sent out that one
patch for sparc, but didn't get any response to it. I'm inclined to
just apply it (the 'struct mdesc_hdr' pointer misuse one).
Linus
On Wed, Sep 15, 2021 at 12:47 PM Linus Torvalds
<[email protected]> wrote:
>
> What other notable issues end up being still live? I sent out that one
> patch for sparc, but didn't get any response to it. I'm inclined to
> just apply it (the 'struct mdesc_hdr' pointer misuse one).
Oh, I forgot about the qnx4 one. That happens on sparc, possibly
others, but not on x86-64.
I'll go look at that patch too.
Linus
On 9/15/21 9:47 PM, Linus Torvalds wrote:
> On Wed, Sep 15, 2021 at 12:35 PM Guenter Roeck <[email protected]> wrote:
>>
>> On a side note, we may revive the parisc patch. Helge isn't entirely
>> happy with the other solution for parisc; it is quite invasive and
>> touches a total of 19 files if I counted correctly.
>
> Ok, my suggestion to use the linker was not a "do it this way", it
> really was just a "maybe alternate approach". So no objections if
> absolute_pointer() ends up being the simpler solution.
Yes, it's a lot simpler and makes backporting patches later much easier.
I'll send a pull request with the updated parisc patch tomorrow.
Thanks,
Helge
On Wed, Sep 15, 2021 at 12:50 PM Linus Torvalds
<[email protected]> wrote:
>
> On Wed, Sep 15, 2021 at 12:47 PM Linus Torvalds
> <[email protected]> wrote:
> >
> > What other notable issues end up being still live? I sent out that one
> > patch for sparc, but didn't get any response to it. I'm inclined to
> > just apply it (the 'struct mdesc_hdr' pointer misuse one).
>
> Oh, I forgot about the qnx4 one. That happens on sparc, possibly
> others, but not on x86-64.
>
> I'll go look at that patch too.
Ok, I didn't love any of the patches I saw for the qnx4 problem, so I
silenced that warning with a new patch of my own. Like the sparc64
case, the fix is to describe more extensively to the compiler what the
code is actually doing.
I think it ended up making it clearer what is going on to humans too.
Although that may be the old "peeing in the snow" effect - it looks
more understandable to me only because I spent so much time trying to
understand what it does, and then wrote the fix based on that possibly
flawed understanding. So of course I find it more understandable.
Looking at the qnx4 code-base history, I don't think it has gotten any
actual development outside of cleanups in the git history timeframe,
which makes me suspect nobody uses this code.
But hey, maybe it just works so well for the very specialized user base ...
Anyway, I pushed it out. I have a clean "allmodconfig" build on all
the architectures I tested, but I didn't test _that_ many. sparc64,
arm64, powerpc64.
Lots of dts warnings (which aren't fatal), though. Particularly for
the powerpc64 build.
Linus
On Wed, Sep 15, 2021 at 12:47:44PM -0700, Linus Torvalds wrote:
> On Wed, Sep 15, 2021 at 12:35 PM Guenter Roeck <[email protected]> wrote:
> >
> > On a side note, we may revive the parisc patch. Helge isn't entirely
> > happy with the other solution for parisc; it is quite invasive and
> > touches a total of 19 files if I counted correctly.
>
> Ok, my suggestion to use the linker was not a "do it this way", it
> really was just a "maybe alternate approach". So no objections if
> absolute_pointer() ends up being the simpler solution.
>
> What other notable issues end up being still live? I sent out that one
> patch for sparc, but didn't get any response to it. I'm inclined to
> just apply it (the 'struct mdesc_hdr' pointer misuse one).
>
You mean allmodconfig build failures ? There is still a bunch.
For v5.15-rc1-27-gb7213ffa0e58:
alpha:
drivers/net/ethernet/3com/3c515.c: In function 'corkscrew_start_xmit':
drivers/net/ethernet/3com/3c515.c:1053:22: error:
cast from pointer to integer of different size
That is a typecast from a pointer to an int, which is then sent to an
i/o port. That driver should probably be disabled for 64-bit builds.
---
drivers/net/wan/lmc/lmc_main.c: In function 'lmc_softreset':
drivers/net/wan/lmc/lmc_main.c:1782:50: error:
passing argument 1 of 'virt_to_bus' discards 'volatile' qualifier from pointer target type
and several other similar errors.
patch:
https://lore.kernel.org/lkml/[email protected]/
Arnd sent an Ack, but it doesn't look like it was picked up.
---
drivers/net/hamradio/6pack.c: In function 'sixpack_open':
drivers/net/hamradio/6pack.c:71:41: error:
unsigned conversion from 'int' to 'unsigned char' changes value from '256' to '0'
patch:
https://lore.kernel.org/lkml/[email protected]/
David says it is wrong, and I don't know the code well enough
to feel comfortable touching that code. That may be a lost cause.
"depends on BROKEN if ALPHA" may be appropriate here.
===
arm:
drivers/cpufreq/vexpress-spc-cpufreq.c: In function 've_spc_cpufreq_exit':
drivers/cpufreq/vexpress-spc-cpufreq.c:454:13: error: unused variable 'cur_cluster'
patch:
https://patchwork.kernel.org/project/linux-arm-kernel/patch/[email protected]/
===
m68k:
arch/m68k/mvme147/config.c: In function 'mvme147_hwclk':
arch/m68k/mvme147/config.c:174:2: error: #warning check me! [-Werror=cpp]
174 | #warning check me!
| ^~~~~~~
arch/m68k/mvme16x/config.c: In function 'mvme16x_hwclk':
arch/m68k/mvme16x/config.c:439:2: error: #warning check me! [-Werror=cpp]
drivers/misc/altera-stapl/altera-lpt.c: In function 'byteblaster_write':
arch/m68k/include/asm/raw_io.h:30:32: error:
cast to pointer from integer of different size
[ and several other similar problems ]
Patches should be queued in m68k tree.
===
mips:
In file included from arch/mips/include/asm/sibyte/sb1250.h:28,
from drivers/watchdog/sb_wdog.c:58:
arch/mips/include/asm/sibyte/bcm1480_scd.h:261: error: "M_SPC_CFG_CLEAR" redefined
and similar. Patch:
https://patchwork.kernel.org/project/linux-watchdog/patch/[email protected]/
I'll need to get Wim to push it.
===
parisc:
arch/parisc/kernel/setup.c: In function 'start_parisc':
arch/parisc/kernel/setup.c:387:28: error:
'__builtin_memcmp_eq' specified bound 8 exceeds source size 0
Waiting for the absolute_pointer patch
===
riscv32, riscv64:
drivers/gpu/drm/rockchip/cdn-dp-core.c:1126:12: error: 'cdn_dp_resume' defined but not used
patch:
https://patchwork.kernel.org/project/linux-rockchip/patch/[email protected]/
Looks like that and similar patches were submitted several times,
but never picked up.
===
s390:
drivers/spi/spi-tegra20-slink.c:1200:12: error:
'tegra_slink_runtime_resume' defined but not used
drivers/spi/spi-tegra20-slink.c:1188:12: error:
'tegra_slink_runtime_suspend' defined but not used
patch:
https://patchwork.kernel.org/project/spi-devel-general/patch/[email protected]/
marked as accepted, so should hopefully find its way upstream soon.
---
lib/test_kasan.c: In function 'kasan_alloca_oob_right':
lib/test_kasan.c:782:1: error: 'kasan_alloca_oob_right' uses dynamic stack allocation
and a couple of similar errors. s390 has a special configuration option
to enable warnings on dynamic stack allocations. A patch to remove that
option is pending according to s390 maintainers.
---
drivers/gpu/drm/rockchip/cdn-dp-core.c:1126:12: error: 'cdn_dp_resume' defined but not used
Same as for riscv.
===
xtensa:
Various stack frame errors (more than 50).
drivers/video/fbdev/omap2/omapfb/dss/dsi.c: In function 'dsi_dump_dsidev_irqs':
drivers/video/fbdev/omap2/omapfb/dss/dsi.c:1623:1: error:
the frame size of 1104 bytes is larger than 1024 bytes
Patch:
https://lore.kernel.org/lkml/[email protected]/
Should find its way upstream through mmotm.
Guenter
On Wed, Sep 15, 2021 at 12:18:58PM -0700, Linus Torvalds wrote:
> On Tue, Sep 14, 2021 at 8:52 PM Guenter Roeck <[email protected]> wrote:
> >
> > This patch series introduces absolute_pointer() to fix the problem.
> > absolute_pointer() disassociates a pointer from its originating symbol
> > type and context, and thus prevents gcc from making assumptions about
> > pointers passed to memory operations.
>
> Ok, I've applied this to my tree.
>
> I note that the physical BOOT_PCB addresses in the alpha setup.h file
> might be useful for things like MILO in user space, but since I
> couldn't even find MILO sources any more, I couldn't really check.
>
> I suspect alpha is basically on life support and presumably nobody
> would ever compile a bootloader anyway, so it's unlikely to matter.
>
> If somebody does find any issues, we'll know better and we can ask
> where the user space sources are that might use that alpha setup.h
> file.
I think everyone uses aboot now as the bootloader on Alpha. So as
long as we can still compile aboot everyone should be happy.
Cheers
Michael.
On Wednesday, 2021-09-15 23:19 Linus Torvalds wrote:
> Ok, I didn't love any of the patches I saw for the qnx4 problem, so I
> silenced that warning with a new patch of my own. Like the sparc64
> case, the fix is to describe more extensively to the compiler what the
> code is actually doing.
thanks, looks good to me, too!
> Looking at the qnx4 code-base history, I don't think it has gotten any
> actual development outside of cleanups in the git history timeframe,
> which makes me suspect nobody uses this code.
>
> But hey, maybe it just works so well for the very specialized user base ...
it's actually the latter (although I guess the user base is shrinking)
Cheers
Anders
On Thu, Sep 16, 2021 at 12:02 AM Anders Larsen <[email protected]> wrote:
>
> On Wednesday, 2021-09-15 23:19 Linus Torvalds wrote:
> >
> > But hey, maybe it just works so well for the very specialized user base ...
>
> it's actually the latter (although I guess the user base is shrinking)
Hey, so if it's actively used, maybe you can answer a question or two
that I have just because I looked at the code..
In particular, the inode number calculation is odd. Is there a reason
for the "-1"? Because iboth the link case and the direct inode case
have it, but t's a _different_ "-1":
For the "inode_entry", it does
ino = blknum * QNX4_INODES_PER_BLOCK + ix - 1;
but it's worth noting that "ix" is zero-based (index within the
block), so this kind of oddly removes one from a zero-based thing, and
the 'ino' for the very first entry ends up being -1.
Of course, it's possible that the first entry is always empty, but it
does seem a bit odd.
For the "link_info" case, it does
ino = ( le32_to_cpu(de->link.dl_inode_blk) - 1 ) *
QNX4_INODES_PER_BLOCK +
de->link.dl_inode_ndx;
so now it takes the _block_ index, and does that "-1" on it, and then
multiplies it by the "entries per block" number, and adds the index.
So now if both are zero, the inode number is -8, not -1.
But all of this matches what the *lookup* code does. It's very odd, though.
But to make it stranger, then in "qnx4_iget()", the calculations all
makes sense. There it just does "take the inode number, and look up
block and index into the block using it".
Very strange and confusing. Because it means that iget() seems to look
up a *different* inode entry than "lookup" and "readdir" actually look
at.
I must be missing something. I obviously didn't touch any of this
logic, I was just doing the "make the type system clearer for the
compiler".
Also, I have to say, since I was looking at compiler output, the
calculations in readdir() are made much worse by the fact that the
dir->pos is a "loff_t". That's signed. And then you use "%" to get the
index within a block. Using '%' instead of bitops is fairly
equivalent, but only for
(a) unsigned types
(b) when the divisor is a compile-time power-of-2
In the qnx4 case, (b) is true, but (a) is not.
Not a big deal. But usually, I tell people to avoid '% ENTRIES',
because it really has very different behavior from '& MASK' for signed
numbers.
Linus
On Wed, Sep 15, 2021 at 3:33 PM Guenter Roeck <[email protected]> wrote:
>
> drivers/net/ethernet/3com/3c515.c: In function 'corkscrew_start_xmit':
> drivers/net/ethernet/3com/3c515.c:1053:22: error:
> cast from pointer to integer of different size
>
> That is a typecast from a pointer to an int, which is then sent to an
> i/o port. That driver should probably be disabled for 64-bit builds.
Naah. I think the Jensen actually had an ISA slot. Came with a
whopping 8MB too, so the ISA DMA should work just fine.
Or maybe it was EISA only? I really don't remember.
It's possible that alpha should get rid of the ISA config option, and
use ISA_BUS instead. That would be the proper config if there aren't
actually any ISA _slots_, and it would disable the 3c515 driver.
But it turns out that the compile error is easy to fix. Just make it
use isa_virt_to_bus(), which that driver does elsewhere anyway.
I have no way - or interest - to test that on real hardware, but I did
check that if I relax the config I can at least build it cleanly on
x86-64 with that change.
It can't make matters worse, and it's the RightThing(tm).
Since Micheal replied about that other alpha issue, maybe he knows
about the ISA slot situation too?
But anyway, 3c515 should compile cleanly again.
> drivers/net/wan/lmc/lmc_main.c: In function 'lmc_softreset':
> drivers/net/wan/lmc/lmc_main.c:1782:50: error:
> passing argument 1 of 'virt_to_bus' discards 'volatile' qualifier from pointer target type
>
> and several other similar errors.
>
> patch:
> https://lore.kernel.org/lkml/[email protected]/
> Arnd sent an Ack, but it doesn't look like it was picked up.
I picked it up manually now along with the arm vexpress cpufreq one.
> m68k:
I think these should be fixed as of the pull request this morning.
> mips:
>
> In file included from arch/mips/include/asm/sibyte/sb1250.h:28,
> from drivers/watchdog/sb_wdog.c:58:
> arch/mips/include/asm/sibyte/bcm1480_scd.h:261: error: "M_SPC_CFG_CLEAR" redefined
>
> and similar. Patch:
>
> https://patchwork.kernel.org/project/linux-watchdog/patch/[email protected]/
>
> I'll need to get Wim to push it.
Ok, that hasn't hit my tree yet.
> parisc:
This one should be fixed as of the parisc pull this morning.
So a few more remaining (mainly the suspend/resume ones), but slowly
making progress.
Linus
On Wed, Sep 15, 2021 at 3:33 PM Guenter Roeck <[email protected]> wrote:
>
> drivers/net/hamradio/6pack.c: In function 'sixpack_open':
> drivers/net/hamradio/6pack.c:71:41: error:
> unsigned conversion from 'int' to 'unsigned char' changes value from '256' to '0'
>
> patch:
> https://lore.kernel.org/lkml/[email protected]/
> David says it is wrong, and I don't know the code well enough
> to feel comfortable touching that code. That may be a lost cause.
> "depends on BROKEN if ALPHA" may be appropriate here.
David is wrong.
The code here is bogus, and the docs clearly state that the transmit
data is in units of "10ms":
https://www.linux-ax25.org/wiki/6PACK
and that
#define SIXP_TXDELAY (HZ/4) /* in 1 s */
is just wrong, and the actual *uses* of that TX timeout seems correct
for that 10ms value:
mod_timer(&sp->tx_t, jiffies + ((when + 1) * HZ) / 100);
ie that "when" is clearly given in 100ths of a second, aka 10ms (ok,
that's mainly SIXP_SLOTTIME, with SIXP_TXDELAY being used mainly to
transfer the data to the other side).
So from everything I can see, your patch is correct.
Of course, to make things more confusing, the RESYNC_TIMEOUTs are
indeed given in ticks.
I spent too much time looking at this, but I'm going to apply that
patch. I suspect either nobody uses that driver any more, or the
TXDELAY values don't actually much matter, since they have clearly
been wrong and depended on random kernel configs for a long long time.
I think the most common HZ value on x86 tends to be the modern default
of 250Hz, so the old "HZ/4" means that most people got a TXDELAY of
620ms, rather than the traditional expected 250ms.
The fact that this shows up as an actual compile error on alpha is
just random luck, since alpha uses a 1024Hz clock. CONFIG_HZ_1000
isn't impossible on other platforms either, which happens to compile
cleanly, but causes that TXDELAY byte to sent out as 250, for a 2.5Hz
TX delay.
Of course, it is possible that it's the documentation that is wrong,
but considering that the documentation matches the code (see above on
that "((when + 1) * HZ)/100"), and matches the "it doesn't cause
compiler warnings", I think it's pretty clear that your patch is the
correct fix.
Linus
On Thu, Sep 16, 2021 at 11:35:36AM -0700, Linus Torvalds wrote:
> On Wed, Sep 15, 2021 at 3:33 PM Guenter Roeck <[email protected]> wrote:
> >
> > drivers/net/ethernet/3com/3c515.c: In function 'corkscrew_start_xmit':
> > drivers/net/ethernet/3com/3c515.c:1053:22: error:
> > cast from pointer to integer of different size
> >
> > That is a typecast from a pointer to an int, which is then sent to an
> > i/o port. That driver should probably be disabled for 64-bit builds.
>
> Naah. I think the Jensen actually had an ISA slot. Came with a
> whopping 8MB too, so the ISA DMA should work just fine.
>
> Or maybe it was EISA only? I really don't remember.
>
> It's possible that alpha should get rid of the ISA config option, and
> use ISA_BUS instead. That would be the proper config if there aren't
> actually any ISA _slots_, and it would disable the 3c515 driver.
>
> But it turns out that the compile error is easy to fix. Just make it
> use isa_virt_to_bus(), which that driver does elsewhere anyway.
>
> I have no way - or interest - to test that on real hardware, but I did
> check that if I relax the config I can at least build it cleanly on
> x86-64 with that change.
>
> It can't make matters worse, and it's the RightThing(tm).
>
> Since Micheal replied about that other alpha issue, maybe he knows
> about the ISA slot situation too?
Ah, yeah, not really. I am not familiar with the Jensen hardware,
and have never played around with the EISA slot on the Alphas I do
have.
Cheers
Michael.
Hi,
>
> On Thu, Sep 16, 2021 at 11:35:36AM -0700, Linus Torvalds wrote:
> > On Wed, Sep 15, 2021 at 3:33 PM Guenter Roeck <[email protected]> wrote:
> > >
> > > drivers/net/ethernet/3com/3c515.c: In function 'corkscrew_start_xmit':
> > > drivers/net/ethernet/3com/3c515.c:1053:22: error:
> > > cast from pointer to integer of different size
> > >
> > > That is a typecast from a pointer to an int, which is then sent to an
> > > i/o port. That driver should probably be disabled for 64-bit builds.
> >
> > Naah. I think the Jensen actually had an ISA slot. Came with a
> > whopping 8MB too, so the ISA DMA should work just fine.
> >
> > Or maybe it was EISA only? I really don't remember.
It's EISA only. I've made some pictures of a somewhat dusty inside of
a Jensen with 4 EISA cards (from bottom to top: SCSI, video, 2x network):
http://alpha.ulrich-teichert.org/
(don't worry about the loose cable on one of the pictures, that's just
my crude RTC battery replacment)
> > I have no way - or interest - to test that on real hardware, but I did
> > check that if I relax the config I can at least build it cleanly on
> > x86-64 with that change.
I could not get a recent kernel to boot, but it's booting ancient kernels
just fine:
Linux version 2.4.27-2-generic (tretkowski@bastille) (gcc version 3.3.5 (Debian 1:3.3.5-12)) #1 Sun May 29 18:40:58 UTC 2005
Booting GENERIC on Jensen using machine vector Jensen from SRM
Major Options: LEGACY_START
Command line: ro root=/dev/sda3
memcluster 0, usage 1, start 0, end 256
memcluster 1, usage 0, start 256, end 8192
freeing pages 256:384
freeing pages 757:8192
reserving pages 757:758
Initial ramdisk at: 0xfffffc00039d2000 (5308416 bytes)
Max ASN from HWRPB is bad (0xf)
On node 0 totalpages: 8192
zone(0): 8192 pages.
zone(1): 0 pages.
zone(2): 0 pages.
Kernel command line: ro root=/dev/sda3
...
> > It can't make matters worse, and it's the RightThing(tm).
> >
> > Since Micheal replied about that other alpha issue, maybe he knows
> > about the ISA slot situation too?
>
> Ah, yeah, not really. I am not familiar with the Jensen hardware,
> and have never played around with the EISA slot on the Alphas I do
> have.
I know the feeling.... So many computers, so little time...
While we're at it, during my vain attempts to get new kernels to boot,
I tried to disable PCI support to make the kernels smaller (after all,
the Jensen has only EISA, so what good would PCI support for?) and
got it to compile with the attached patch (which fixes some warnings,
too). Should apply cleanly to Linus tree.
Enable compile for the Jensen without PCI support.
Signed-off-by: Ulrich Teichert <[email protected]>
---
arch/alpha/include/asm/jensen.h | 8 ++++----
arch/alpha/kernel/sys_jensen.c | 2 +-
include/asm-generic/pci_iomap.h | 6 +++++-
3 files changed, 10 insertions(+), 6 deletions(-)
diff --git a/arch/alpha/include/asm/jensen.h b/arch/alpha/include/asm/jensen.h
index 916895155a88..1c4131453db2 100644
--- a/arch/alpha/include/asm/jensen.h
+++ b/arch/alpha/include/asm/jensen.h
@@ -111,18 +111,18 @@ __EXTERN_INLINE void jensen_set_hae(unsigned long addr)
* convinced that I need one of the newer machines.
*/
-static inline unsigned int jensen_local_inb(unsigned long addr)
+__EXTERN_INLINE unsigned int jensen_local_inb(unsigned long addr)
{
return 0xff & *(vuip)((addr << 9) + EISA_VL82C106);
}
-static inline void jensen_local_outb(u8 b, unsigned long addr)
+__EXTERN_INLINE void jensen_local_outb(u8 b, unsigned long addr)
{
*(vuip)((addr << 9) + EISA_VL82C106) = b;
mb();
}
-static inline unsigned int jensen_bus_inb(unsigned long addr)
+__EXTERN_INLINE unsigned int jensen_bus_inb(unsigned long addr)
{
long result;
@@ -131,7 +131,7 @@ static inline unsigned int jensen_bus_inb(unsigned long addr)
return __kernel_extbl(result, addr & 3);
}
-static inline void jensen_bus_outb(u8 b, unsigned long addr)
+__EXTERN_INLINE void jensen_bus_outb(u8 b, unsigned long addr)
{
jensen_set_hae(0);
*(vuip)((addr << 7) + EISA_IO + 0x00) = b * 0x01010101;
diff --git a/arch/alpha/kernel/sys_jensen.c b/arch/alpha/kernel/sys_jensen.c
index e5d870ff225f..40db6c3d9690 100644
--- a/arch/alpha/kernel/sys_jensen.c
+++ b/arch/alpha/kernel/sys_jensen.c
@@ -17,7 +17,7 @@
#include <asm/ptrace.h>
-#define __EXTERN_INLINE inline
+#define __EXTERN_INLINE extern inline
#include <asm/io.h>
#include <asm/jensen.h>
#undef __EXTERN_INLINE
diff --git a/include/asm-generic/pci_iomap.h b/include/asm-generic/pci_iomap.h
index df636c6d8e6c..446a0c576b33 100644
--- a/include/asm-generic/pci_iomap.h
+++ b/include/asm-generic/pci_iomap.h
@@ -18,6 +18,7 @@ extern void __iomem *pci_iomap_range(struct pci_dev *dev, int bar,
extern void __iomem *pci_iomap_wc_range(struct pci_dev *dev, int bar,
unsigned long offset,
unsigned long maxlen);
+extern void pci_iounmap(struct pci_dev *dev, void __iomem *p);
/* Create a virtual mapping cookie for a port on a given PCI device.
* Do not call this directly, it exists to make it easier for architectures
* to override */
@@ -28,7 +29,7 @@ extern void __iomem *__pci_ioport_map(struct pci_dev *dev, unsigned long port,
#define __pci_ioport_map(dev, port, nr) ioport_map((port), (nr))
#endif
-#elif defined(CONFIG_GENERIC_PCI_IOMAP)
+#elif defined(CONFIG_GENERIC_PCI_IOMAP) || !defined(CONFIG_PCI)
static inline void __iomem *pci_iomap(struct pci_dev *dev, int bar, unsigned long max)
{
return NULL;
@@ -50,6 +51,9 @@ static inline void __iomem *pci_iomap_wc_range(struct pci_dev *dev, int bar,
{
return NULL;
}
+static inline void pci_iounmap(struct pci_dev *dev, void __iomem *p)
+{
+}
#endif
#endif /* __ASM_GENERIC_PCI_IOMAP_H */
--
Dipl. Inf. Ulrich Teichert|e-mail: [email protected] | Listening to:
Stormweg 24 |Eat Lipstick: Dirty Little Secret, The Baboon Show:
24539 Neumuenster, Germany|Work Work Work, The Bellrays: Bad Reaction
On Sat, Sep 18, 2021 at 6:11 AM Ulrich Teichert
<[email protected]> wrote:
>
> Hi,
>
> >
> > On Thu, Sep 16, 2021 at 11:35:36AM -0700, Linus Torvalds wrote:
> > > Naah. I think the Jensen actually had an ISA slot. Came with a
> > > whopping 8MB too, so the ISA DMA should work just fine.
> > >
> > > Or maybe it was EISA only? I really don't remember.
>
> It's EISA only. I've made some pictures of a somewhat dusty inside of
> a Jensen with 4 EISA cards (from bottom to top: SCSI, video, 2x network):
Ok.
Looking around the config options, there _are_ systems with ISA slots,
but it's not the old Jensen one. It's apparently some evaluation
boards but also the "AlphaPC64" one.
So we do want CONFIG_ISA for alpha, even if not Jensen.
(I forget which alpha I had. For some reason I want to think I had an
EISA machine and probably Jensen. Maybe upgraded to a 164 later?)
> I could not get a recent kernel to boot, but it's booting ancient kernels
> just fine:
>
> Linux version 2.4.27-2-generic (tretkowski@bastille) (gcc version 3.3.5 (Debian 1:3.3.5-12)) #1 Sun May 29 18:40:58 UTC 2005
Ouch. Without having some kind of bisection, I guess we'll never know.
And I assume it's not really been tested since, so it could be
multiple reasons, including compiler updates causing dodgy code to not
work etc etc.
> While we're at it, during my vain attempts to get new kernels to boot,
> I tried to disable PCI support to make the kernels smaller (after all,
> the Jensen has only EISA, so what good would PCI support for?) and
> got it to compile with the attached patch (which fixes some warnings,
> too).
Can you send me your Jensen config?
I do not see why you should be using that horrible __EXERN_INLINE. It
will cause gcc to sometimes not inline at all, and not generate the
out-of-line body either.
Sometimes that is what you want: you want to generate one single body
of the function, and particularly one that is _different_ from the
inlining case (ie for inlining you want to do the simple thing, for
out-of-line you do something fancier).
But that isn't the case here, so this looks like a workaround for
something else. But this code does end up using preprocessor
concatenation etc, so I might be missing some case.
Linus
On Sat, Sep 18, 2021 at 10:17 AM Thorsten Glaser <[email protected]> wrote:
>
> Considering you can actually put ISA cards, 8 and 16 bit both,
> into EISA slots, I’d have assumed so. I don’t understand the
> “EISA only” question above.
Oh, it's so long since I had one of those machines I didn't even
remember that EISA took ISA cards too.
But yeah, there are also apparently PCI-based alpha machines with
actual ISA card slots.
Linus
On Sat, 18 Sep 2021, Linus Torvalds wrote:
> > > On Thu, Sep 16, 2021 at 11:35:36AM -0700, Linus Torvalds wrote:
> > > > Naah. I think the Jensen actually had an ISA slot. Came with a
> > > > whopping 8MB too, so the ISA DMA should work just fine.
> > > >
> > > > Or maybe it was EISA only? I really don't remember.
> >
> > It's EISA only. I've made some pictures of a somewhat dusty inside of
> So we do want CONFIG_ISA for alpha, even if not Jensen.
Considering you can actually put ISA cards, 8 and 16 bit both,
into EISA slots, I’d have assumed so. I don’t understand the
“EISA only” question above.
bye,
//mirabilos (not using an Alpha but still using x86 ISA cards)
--
<cnuke> den AGP stecker anfeilen, damit er in den slot aufm 440BX board passt…
oder netzteile, an die man auch den monitor angeschlossen hat und die dann für
ein elektrisch aufgeladenes gehäuse gesorgt haben […] für lacher gut auf jeder
LAN party │ <nvb> damals, als der pizzateig noch auf dem monior "gegangen" ist
On Sat, Sep 18, 2021 at 10:04 AM Linus Torvalds
<[email protected]> wrote:
>
> I do not see why you should be using that horrible __EXERN_INLINE. It
> will cause gcc to sometimes not inline at all, and not generate the
> out-of-line body either.
Yeah, that patch doesn't work at all with my cross-compiler, and only results in
alpha-linux-gnu-ld: arch/alpha/kernel/sys_jensen.o:(.ref.data+0x58):
undefined reference to `jensen_ioread8'
because some of those 'extern inline' cases are never instantiated.
I'll look into it, we can make Jensen build again in case somebody
then gets the energy to see what causes it to not boot.
Linus
Hi,
> > > On Thu, Sep 16, 2021 at 11:35:36AM -0700, Linus Torvalds wrote:
> > > > Naah. I think the Jensen actually had an ISA slot. Came with a
> > > > whopping 8MB too, so the ISA DMA should work just fine.
> > > >
> > > > Or maybe it was EISA only? I really don't remember.
> >
> > It's EISA only. I've made some pictures of a somewhat dusty inside of
> > a Jensen with 4 EISA cards (from bottom to top: SCSI, video, 2x network):
>
> Ok.
>
> Looking around the config options, there _are_ systems with ISA slots,
> but it's not the old Jensen one. It's apparently some evaluation
> boards but also the "AlphaPC64" one.
>
> So we do want CONFIG_ISA for alpha, even if not Jensen.
>
> (I forget which alpha I had. For some reason I want to think I had an
> EISA machine and probably Jensen. Maybe upgraded to a 164 later?)
Well, as this was way back in 1995, it was perhaps a Multia? Also
named UDB, a small "booksize" model.
> > I could not get a recent kernel to boot, but it's booting ancient kernels
> > just fine:
> >
> > Linux version 2.4.27-2-generic (tretkowski@bastille) (gcc version 3.3.5 (Debian 1:3.3.5-12)) #1 Sun May 29 18:40:58 UTC 2005
>
> Ouch. Without having some kind of bisection, I guess we'll never know.
> And I assume it's not really been tested since, so it could be
> multiple reasons, including compiler updates causing dodgy code to not
> work etc etc.
Well, I doubt that bisecting will be practical going that way back.
> > While we're at it, during my vain attempts to get new kernels to boot,
> > I tried to disable PCI support to make the kernels smaller (after all,
> > the Jensen has only EISA, so what good would PCI support for?) and
> > got it to compile with the attached patch (which fixes some warnings,
> > too).
>
> Can you send me your Jensen config?
Sure, attached here. I don't know if it helps - I can't tell you why I
used 4.18-rc5 for it, that was in 2018... Oh man, I am spending too much
time at work...
> I do not see why you should be using that horrible __EXERN_INLINE. It
> will cause gcc to sometimes not inline at all, and not generate the
> out-of-line body either.
>
> Sometimes that is what you want: you want to generate one single body
> of the function, and particularly one that is _different_ from the
> inlining case (ie for inlining you want to do the simple thing, for
> out-of-line you do something fancier).
>
> But that isn't the case here, so this looks like a workaround for
> something else. But this code does end up using preprocessor
> concatenation etc, so I might be missing some case.
I was just tinkering with it to get it compiled without warning,
I certainly didn't get the big picture :-/
HTH,
Uli
--
Dipl. Inf. Ulrich Teichert|e-mail: [email protected] | Listening to:
Stormweg 24 |Eat Lipstick: Dirty Little Secret, The Baboon Show:
24539 Neumuenster, Germany|Work Work Work, The Bellrays: Bad Reaction
On Sat, Sep 18, 2021 at 1:26 PM Ulrich Teichert
<[email protected]> wrote:
>
> >
> > (I forget which alpha I had. For some reason I want to think I had an
> > EISA machine and probably Jensen. Maybe upgraded to a 164 later?)
>
> Well, as this was way back in 1995, it was perhaps a Multia? Also
> named UDB, a small "booksize" model.
No, that came later. I had one of the very original ones.
I'm pretty sure it was that Jensen platform, but I'm too lazy to go
back and look.
> > Can you send me your Jensen config?
>
> Sure, attached here. I don't know if it helps - I can't tell you why I
> used 4.18-rc5 for it, that was in 2018... Oh man, I am spending too much
> time at work...
I ended up hacking something up which was enough to show the build
problems, and then some.
But your config shows _other_ errors with the IO functions, so I guess
I'll need to look at that one too.
There's clearly a reason that Jensen was marked BROKEN in the Kconfig,
the whole situation with the IO accessor functions on that platform is
a disaster.
Linus
On Sat, Sep 18, 2021 at 1:26 PM Ulrich Teichert
<[email protected]> wrote:
>
> I was just tinkering with it to get it compiled without warning,
> I certainly didn't get the big picture :-/
Ok, you shamed me into some tinkering too, and I fixed a couple of
issues with the alpha build.
The whole "pci_iounmap()" mess is not something I solved (you were
cc'd on the email I sent out about that), but I did test a few
different Jensen configurations and fixed a couple of uglies.
So at least _some_ Jensen configurations build cleanly once more, and
I re-enabled JENSEN as a valid machine target.
But if it doesn't boot, it's all fairly moot. And those things are a
pain to debug, and if the last booting kernel was years and years ago,
I don't think it realistically will necessarily ever be fixed.
Oh well. I have an odd love-hate relationship with alpha.
I think it's one of the worst architectures ever designed (memory
ordering is completely broken, and the lack of byte operations in the
original specs were a big reason for the initial problems and eventual
failure).
But at the same time, I really did enjoy it back in the day, and it
_was_ the first port I did, and the first truly integrated kernel
architecture (the original Linux m68k port that preceded it was a
"hack up and replace" job rather than "integrate")
Linus
On Sat, Sep 18, 2021 at 1:46 PM Linus Torvalds
<[email protected]> wrote:
>
> But your config shows _other_ errors with the IO functions, so I guess
> I'll need to look at that one too.
Oh, and all those games with
#define __EXTERN_INLINE
#include <asm/io.h>
#include <asm/jensen.h>
#undef __EXTERN_INLINE
don't actually work, because there's the usual multiple-inclusion
protection on top of asm/jensen.h:
#ifndef __ALPHA_JENSEN_H
#define __ALPHA_JENSEN_H
and this include of <asm/jensen.h> is entirely unused, because we
ended up getting the one *without* that empty __EXTERN_INLINE #define
from an earlier include of
#include <linux/interrupt.h>
that caused asm/io.h and asm/jensen.h to be included earlier.
The *other* machine files know to do their includes at the top of the file.
But then I end up getting
ERROR: modpost: "__udiv_qrnnd" [lib/mpi/mpi.ko] undefined!
because CONFIG_MATHEMU wasn't set and the crypto stuff wants the MPI code.
So there seems to be other alpha Kconfig issues in there, and they
aren't all actually Jensen-specific.
Oh well. I guess can fix things up, since I did get tthe
cross-compiler environment..
Linus
On Sun, Sep 19, 2021 at 8:01 AM Linus Torvalds
<[email protected]> wrote:
>
>
> Oh well. I have an odd love-hate relationship with alpha.
>
> I think it's one of the worst architectures ever designed (memory
> ordering is completely broken, and the lack of byte operations in the
> original specs were a big reason for the initial problems and eventual
> failure).
>
> But at the same time, I really did enjoy it back in the day, and it
> _was_ the first port I did, and the first truly integrated kernel
> architecture (the original Linux m68k port that preceded it was a
> "hack up and replace" job rather than "integrate")
As a side note, I loved the Alpha, too. Compared to the VMS port
I was too often working on in the 90s, having Linux run on it was
a joy, and for years I used my remaining older alpha boxes as
firewalls, trusting in the oddity of the architecture to resist
various and sundry attacks.
I retired the last one well over a decade back.
RIP.
>
> Linus
--
Fixing Starlink's Latencies: https://www.youtube.com/watch?v=c9gLo6Xrwgw
Dave Täht CEO, TekLibre, LLC
On Mon, Sep 20, 2021 at 11:59 AM Matt Turner <[email protected]> wrote:
>
> In the decade plus I've been around Linux on alpha I've don't actually
> recall hearing of anyone using Linux on a Jensen system before :)
Looking around, I'm pretty sure the system I did all my initial work
on was a Jensen.
This is from the linux-.1.1.83 patch:
- * I don't have any good documentation on the EISA hardware interrupt
- * stuff: I don't know the mapping between the interrupt vector and the
- * EISA interrupt number.
- *
- * It *seems* to be 0x8X0 for EISA interrupt X, and 0x9X0 for the
- * local motherboard interrupts..
+ * The vector is 0x8X0 for EISA interrupt X, and 0x9X0 for the local
+ * motherboard interrupts.. This is for the Jensen.
So yup, my initial bringup machine was that DECpc AXP 150, aka "Jensen".
The IO subsystem on that thing was absolutely horrendous. Largely
because of the lack of byte/word accesses, so doing any PCI accesses
had to be encoded on the address bus. Nasty nasty nasty.
The original design with only 32-bit and 64-bit memory accesses really
was horribly horribly wrong, and all the arguments for it were
garbage. Even outside of IO issues, it blew up code size enormously,
but the IO side became truly horrendous.
Oh well. Water under the bridge.
I did have another alpha at some point - going from the original
150HMz EV4 to a 275MHz EV45. I forget what system that was.
Linus
Hi,
[sorry for the late answer, I was sick yesterday with digestive
system trouble, but nothing serious, just painful....]
> On Sat, Sep 18, 2021 at 1:26 PM Ulrich Teichert
> <[email protected]> wrote:
> >
> > I was just tinkering with it to get it compiled without warning,
> > I certainly didn't get the big picture :-/
>
> Ok, you shamed me into some tinkering too, and I fixed a couple of
> issues with the alpha build.
>
> The whole "pci_iounmap()" mess is not something I solved (you were
> cc'd on the email I sent out about that), but I did test a few
> different Jensen configurations and fixed a couple of uglies.
>
> So at least _some_ Jensen configurations build cleanly once more, and
> I re-enabled JENSEN as a valid machine target.
Yes, I was able to build a minimal Jensen config without any warning
after pulling today, thanks! I think investing a bit in cleaning up
non-PCI configurations may help as soon as PCIe will be obsoleted
by the next bus system ;-)
> But if it doesn't boot, it's all fairly moot. And those things are a
> pain to debug, and if the last booting kernel was years and years ago,
> I don't think it realistically will necessarily ever be fixed.
The main trouble is that my system has only 64MB of memory and the smallest
kernel image with all drivers I need was about 105MB big. According
to: http://users.bart.nl/~geerten/FAQ-9.html
the Jensen can take up to 128MB of RAM and the required PS/2 SIMMs
with partity are still available on ebay, so I just bought 4x32 MB SIMMs.
After setting CONFIG_CC_OPTIMIZE_FOR_SIZE the kernel image was still
93MB big, but with 128MB I should be able to boot it. Let's see....
> Oh well. I have an odd love-hate relationship with alpha.
>
> I think it's one of the worst architectures ever designed (memory
> ordering is completely broken, and the lack of byte operations in the
> original specs were a big reason for the initial problems and eventual
> failure).
I didn't had the money for an Alpha at that time, but as soon as
cheap systems were available on ebay, I took the opportunity. At the
time I bought them, I considered the Miatas (the "Personal Workstations"
from DEC) as quite fast - that must have been around 2004/2006.
> But at the same time, I really did enjoy it back in the day, and it
> _was_ the first port I did, and the first truly integrated kernel
> architecture (the original Linux m68k port that preceded it was a
> "hack up and replace" job rather than "integrate")
My experience is that each port is good for code quality, but I can
only state that for user space applications, not having done much kernel
work,
CU,
Uli
--
Dipl. Inf. Ulrich Teichert|e-mail: [email protected] | Listening to:
Stormweg 24 |Eat Lipstick: Dirty Little Secret, The Baboon Show:
24539 Neumuenster, Germany|Work Work Work, The Bellrays: Bad Reaction
On Mon, Sep 20, 2021 at 11:46 AM Linus Torvalds
<[email protected]> wrote:
>
> On Mon, Sep 20, 2021 at 11:26 AM Ulrich Teichert
> <[email protected]> wrote:
> >
> > The main trouble is that my system has only 64MB of memory and the smallest
> > kernel image with all drivers I need was about 105MB big.
>
> Are you sure you aren't looking at some debug image?
>
> I just tried building something based on your Jensen config (lots of
> new questions, you sent your old config from 4.18.0-rc5 time), and I
> get
>
> [torvalds@ryzen linux]$ ll -h arch/alpha/boot/vmlinux*
> -rwxr-xr-x. 1 torvalds torvalds 5.4M Sep 20 11:32 arch/alpha/boot/vmlinux
> -rw-r--r--. 1 torvalds torvalds 2.3M Sep 20 11:32 arch/alpha/boot/vmlinux.gz
>
> so yeah, it's not exactly tiny, but at 5.4MB it's certainly not 105MB.
>
> The "vmlinux" file itself is huge, but that's due to CONFIG_DEBUG_INFO=y.
>
> You can easily disable DEBUG_INFO entirely (or at least do
> DEBUG_INFO_REDUCED), and get much smaller files.
>
> With the attached config, the vmlinux file is just 7MB (but the actual
> one you boot is that same 5.4M file because it's been stripped).
>
> NOTE! The attached config is basically just the one you sent me, with
> "make defconfig" done and DEBUG_INFO removed. It might have drivers
> missing, or extraneous code that you don't need because of all the
> changes in config variables since that very old one.
>
> It would be very interesting to hear whether this all still boots. I
> do think people still occasionally boot-test some other alpha
> configurations, but maybe not.
I test on a couple of alpha configurations with some regularity:
Marvel (AlphaServer ES47) and Nautilus (UP1500). I have more systems I
could test but I'd need to get a lot more organized to make space.
In the decade plus I've been around Linux on alpha I've don't actually
recall hearing of anyone using Linux on a Jensen system before :)
On Mon, Sep 20, 2021 at 11:26 AM Ulrich Teichert
<[email protected]> wrote:
>
> The main trouble is that my system has only 64MB of memory and the smallest
> kernel image with all drivers I need was about 105MB big.
Are you sure you aren't looking at some debug image?
I just tried building something based on your Jensen config (lots of
new questions, you sent your old config from 4.18.0-rc5 time), and I
get
[torvalds@ryzen linux]$ ll -h arch/alpha/boot/vmlinux*
-rwxr-xr-x. 1 torvalds torvalds 5.4M Sep 20 11:32 arch/alpha/boot/vmlinux
-rw-r--r--. 1 torvalds torvalds 2.3M Sep 20 11:32 arch/alpha/boot/vmlinux.gz
so yeah, it's not exactly tiny, but at 5.4MB it's certainly not 105MB.
The "vmlinux" file itself is huge, but that's due to CONFIG_DEBUG_INFO=y.
You can easily disable DEBUG_INFO entirely (or at least do
DEBUG_INFO_REDUCED), and get much smaller files.
With the attached config, the vmlinux file is just 7MB (but the actual
one you boot is that same 5.4M file because it's been stripped).
NOTE! The attached config is basically just the one you sent me, with
"make defconfig" done and DEBUG_INFO removed. It might have drivers
missing, or extraneous code that you don't need because of all the
changes in config variables since that very old one.
It would be very interesting to hear whether this all still boots. I
do think people still occasionally boot-test some other alpha
configurations, but maybe not.
Linus
Hi,
[del]
> > The main trouble is that my system has only 64MB of memory and the smallest
> > kernel image with all drivers I need was about 105MB big.
>
> Are you sure you aren't looking at some debug image?
>
> I just tried building something based on your Jensen config (lots of
> new questions, you sent your old config from 4.18.0-rc5 time), and I
> get
>
> [torvalds@ryzen linux]$ ll -h arch/alpha/boot/vmlinux*
> -rwxr-xr-x. 1 torvalds torvalds 5.4M Sep 20 11:32 arch/alpha/boot/vmlinux
> -rw-r--r--. 1 torvalds torvalds 2.3M Sep 20 11:32 arch/alpha/boot/vmlinux.gz
>
> so yeah, it's not exactly tiny, but at 5.4MB it's certainly not 105MB.
Right, I had DEBUG_INFO set. Stupid me. Now it looks much better:
valdese:~/soft/linux/kernel-git> ls -lh arch/alpha/boot/vmlinux*
-rwxr-xr-x 1 ut ut 6.4M Sep 21 18:12 arch/alpha/boot/vmlinux*
-rw-r--r-- 1 ut ut 3.0M Sep 21 18:12 arch/alpha/boot/vmlinux.gz
But it still dies before the first message from the kernel shows up.
[del]
> It would be very interesting to hear whether this all still boots. I
> do think people still occasionally boot-test some other alpha
> configurations, but maybe not.
I'm sure that other Alpha configurations are still working, but the
Jensen is a bit special. So far I know it's the only Alpha which needs
aboot and not milo as second stage bootloader. aboot itself seems to
be OK, as I can boot the ancient kernel just fine, but when I'm trying
to boot other kernels, I'm coming as far as:
aboot: loading compressed vmlinux-5-15-rc2
and that's it. I don't think I have to do something special with the
compressed image and according to https://tldp.org/HOWTO/SRM-HOWTO/aboot.html
I don't have to. But why do I have the feeling I am doing something
fundamentally wrong? Was there something with a different kernel
jumping in point or a special build option? I remember something like
that, but can't grasp it nor find it on the web.
I would try the SRM bootimage (make bootimage), but the build is broken:
valdese:~/soft/linux/kernel-git> make -j8 ARCH=alpha CROSS_COMPILE=alpha-linux- bootimage
...
SYSMAP System.map
AS arch/alpha/boot/head.o
CC arch/alpha/boot/stdio.o
HOSTCC arch/alpha/boot/tools/objstrip
arch/alpha/boot/stdio.c: In function ‘vsprintf’:
arch/alpha/boot/stdio.c:249:10: warning: this statement may fall through [-Wimplicit-fallthrough=]
flags |= LARGE;
^
arch/alpha/boot/stdio.c:250:3: note: here
case 'x':
^~~~
arch/alpha/boot/tools/objstrip.c: In function ‘main’:
arch/alpha/boot/tools/objstrip.c:151:36: warning: implicit declaration of function ‘str_has_prefix’ [-Wimplicit-function-declaration]
if (elf->e_ident[0] == 0x7f && str_has_prefix((char *)elf->e_ident + 1, "ELF")) {
^~~~~~~~~~~~~~
arch/alpha/boot/tools/objstrip.c:191:52: warning: format ‘%lx’ expects argument of type ‘long unsigned int’, but argument 5 has type ‘long long unsigned int’ [-Wformat=]
fprintf(stderr, "%s: extracting %#016lx-%#016lx (at %lx)\n",
^
arch/alpha/boot/tools/objstrip.c:200:12: error: ‘struct exec’ has no member named ‘fh’
if (!(aout->fh.f_flags & COFF_F_EXEC)) {
^~
arch/alpha/boot/tools/objstrip.c:206:10: error: ‘struct exec’ has no member named ‘fh’
if (aout->fh.f_opthdr != sizeof(aout->ah)) {
^~
arch/alpha/boot/tools/objstrip.c:206:38: error: ‘struct exec’ has no member named ‘ah’
if (aout->fh.f_opthdr != sizeof(aout->ah)) {
^~
arch/alpha/boot/tools/objstrip.c:218:17: error: ‘struct exec’ has no member named ‘ah’
fil_size = aout->ah.tsize + aout->ah.dsize;
^~
arch/alpha/boot/tools/objstrip.c:218:34: error: ‘struct exec’ has no member named ‘ah’
fil_size = aout->ah.tsize + aout->ah.dsize;
^~
arch/alpha/boot/tools/objstrip.c:219:28: error: ‘struct exec’ has no member named ‘ah’
mem_size = fil_size + aout->ah.bsize;
^~
arch/alpha/boot/tools/objstrip.c:223:22: error: ‘struct exec’ has no member named ‘ah’
prog_name, aout->ah.text_start,
^~
arch/alpha/boot/tools/objstrip.c:224:11: error: ‘struct exec’ has no member named ‘ah’
aout->ah.text_start + fil_size, offset);
^~
scripts/Makefile.host:95: recipe for target 'arch/alpha/boot/tools/objstrip' failed
Was that the target used to get bootable CDROMs? Could that be broken since
the move from aout to ELF? Ugh, sorry for raising so much trouble,
CU,
Uli
--
Dipl. Inf. Ulrich Teichert|e-mail: [email protected] | Listening to:
Stormweg 24 |Eat Lipstick: Dirty Little Secret, The Baboon Show:
24539 Neumuenster, Germany|Work Work Work, The Bellrays: Bad Reaction
On Tue, Sep 21, 2021 at 12:14 PM Ulrich Teichert
<[email protected]> wrote:
>
> Right, I had DEBUG_INFO set. Stupid me. Now it looks much better:
>
> valdese:~/soft/linux/kernel-git> ls -lh arch/alpha/boot/vmlinux*
> -rwxr-xr-x 1 ut ut 6.4M Sep 21 18:12 arch/alpha/boot/vmlinux*
> -rw-r--r-- 1 ut ut 3.0M Sep 21 18:12 arch/alpha/boot/vmlinux.gz
>
> But it still dies before the first message from the kernel shows up.
Ok. That's a nasty situation to debug, and it's where things like "git
bisect" are really useful just to narrow things down.
... which isn't an option here. Too bad.
I also assume thete is no virtual environment that looks like a Jensen
that would help debug this. Which all makes it a bit nasty to try to
even guess at what goes wrong.
> I don't think I have to do something special with the
> compressed image and according to https://tldp.org/HOWTO/SRM-HOWTO/aboot.html
> I don't have to.
Yeah, it's more than two decades since I used an alpha, so I'm afraid
I can't help outside of the "let's make it compile again" thing.
It could easily be that the Jensen required that SRM bootimage, but
it's so long ago that I really don't remember at all.
> I would try the SRM bootimage (make bootimage), but the build is broken:
Well, that looks like something that should be fixed, and that I might look at.
> arch/alpha/boot/tools/objstrip.c:191:52: warning: format ‘%lx’ expects argument of type ‘long unsigned int’, but argument 5 has type ‘long long unsigned int’ [-Wformat=]
> fprintf(stderr, "%s: extracting %#016lx-%#016lx (at %lx)\n",
> ^
> arch/alpha/boot/tools/objstrip.c:200:12: error: ‘struct exec’ has no member named ‘fh’
> if (!(aout->fh.f_flags & COFF_F_EXEC)) {
This looks like the "make bootimage" thing was never designed to work
in a cross-build environment. I think.
Because it looks like what happens is that when you cross-compile, it
gets the x86-64 'struct exec', and then everything goes sideways.
> Was that the target used to get bootable CDROMs? Could that be broken since
> the move from aout to ELF? Ugh, sorry for raising so much trouble,
No, this is lovely. It would be really nice to get that Jensen target
working, if only because of silly historical reasons.
I'll see if I can get around to this.
Linus
On Tue, Sep 21, 2021 at 12:14 PM Ulrich Teichert
<[email protected]> wrote:
>
> I would try the SRM bootimage (make bootimage), but the build is broken:
The attached patch is too ugly for words, and there's no way I will
commit anything like this.
But it at least builds for and seems to successfully make an alpha
bootimage even when cross-compiling on x86-64.
So something to test, perhaps..
Linus
Hi,
> > I would try the SRM bootimage (make bootimage), but the build is broken:
>
> The attached patch is too ugly for words, and there's no way I will
> commit anything like this.
>
> But it at least builds for and seems to successfully make an alpha
> bootimage even when cross-compiling on x86-64.
>
> So something to test, perhaps..
Sure, I burned it to a CDROM and booted from that per SRM. The screen
went black for a second, then the SRM console came back with:
?05 HLT INSTR
PC=00000000.20000014 PSL= 00000000.00000007
I wonder if we would be able to see more on a serial line - I can try
that perhaps tomorrow or at the weekend. To find out to what code the
PC is pointing to, I would need to understand to what point in memory SRM
loads the image into.... But this way, the process of loading the kernel
definitely worked - I still don't understand why aboot can load the
old kernel but not the new one. I'll have a look at the aboot sources,
perhaps there's a certain limit on kernel size?
I'm not sure if we can call this progress,
CU,
Uli
--
Dipl. Inf. Ulrich Teichert|e-mail: [email protected] | Listening to:
Stormweg 24 |Eat Lipstick: Dirty Little Secret, The Baboon Show:
24539 Neumuenster, Germany|Work Work Work, The Bellrays: Bad Reaction