| Message ID | 20210915035227.630204-1-linux@roeck-us.net (mailing list archive) |
|---|---|
| Headers | show |
| Series | Introduce and use absolute_pointer macro | expand |
On Tue, Sep 14, 2021 at 8:52 PM Guenter Roeck <linux@roeck-us.net> 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 <linux@roeck-us.net> 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 <linux@roeck-us.net> 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 <torvalds@linux-foundation.org> 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 <linux@roeck-us.net> 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 <torvalds@linux-foundation.org> wrote: > > On Wed, Sep 15, 2021 at 12:47 PM Linus Torvalds > <torvalds@linux-foundation.org> 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 <linux@roeck-us.net> 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/20210909050033.1564459-1-linux@roeck-us.net/ 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/20210909035743.1247042-1-linux@roeck-us.net/ 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/20210909184714.153068-1-linux@roeck-us.net/ === 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/20210913073220.1159520-1-liu.yun@linux.dev/ 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/20200925215524.2899527-3-sam@ravnborg.org/ 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/20210907045358.2138282-1-linux@roeck-us.net/ 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/20210912025235.3514761-1-linux@roeck-us.net/ 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 <linux@roeck-us.net> 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 <al@alarsen.net> 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 <linux@roeck-us.net> 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/20210909050033.1564459-1-linux@roeck-us.net/ > 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/20210913073220.1159520-1-liu.yun@linux.dev/ > > 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 <linux@roeck-us.net> 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/20210909035743.1247042-1-linux@roeck-us.net/ > 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 <linux@roeck-us.net> 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 <linux@roeck-us.net> 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 <ulrich.teichert@gmx.de> --- 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 */
On Sat, Sep 18, 2021 at 6:11 AM Ulrich Teichert <krypton@ulrich-teichert.org> 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, 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)
On Sat, Sep 18, 2021 at 10:17 AM Thorsten Glaser <t.glaser@tarent.de> 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, Sep 18, 2021 at 10:04 AM Linus Torvalds <torvalds@linux-foundation.org> 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
On Sat, Sep 18, 2021 at 1:26 PM Ulrich Teichert <krypton@ulrich-teichert.org> 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:46 PM Linus Torvalds <torvalds@linux-foundation.org> 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 Sat, Sep 18, 2021 at 1:26 PM Ulrich Teichert <krypton@ulrich-teichert.org> 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 Sun, Sep 19, 2021 at 8:01 AM Linus Torvalds <torvalds@linux-foundation.org> 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
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 > <krypton@ulrich-teichert.org> 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
On Mon, Sep 20, 2021 at 11:26 AM Ulrich Teichert <krypton@ulrich-teichert.org> 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
On Mon, Sep 20, 2021 at 11:46 AM Linus Torvalds <torvalds@linux-foundation.org> wrote: > > On Mon, Sep 20, 2021 at 11:26 AM Ulrich Teichert > <krypton@ulrich-teichert.org> 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:59 AM Matt Turner <mattst88@gmail.com> 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, [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
On Tue, Sep 21, 2021 at 12:14 PM Ulrich Teichert <krypton@ulrich-teichert.org> 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 <krypton@ulrich-teichert.org> 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
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