Re: Linux 6.4.4 on m68k - Q40 - pata_falcon causes oops at boot time

Re: Linux 6.4.4 on m68k - Q40 - pata_falcon causes oops at boot time

[Geert Uytterhoeven]

Hi Will,

CC linux-m68k
CC Finn

On Sat, Jul 22, 2023 at 3:29 PM William R Sowerbutts
<will@sowerbutts.com> wrote:
> I am writing to you as you're listed as the maintainer of the Linux M68K
> architecture.
>
> Sorry for the long email! The TL;DR is that pata_falcon.c on Q40 is broken
> because it tries to access the IDE hardware at the wrong address, but I'm not
> sure which of several possible solutions might be the best.

Thanks for your (extensive) bug report!

> Previously I have ported Linux 4.5 and later 6.2 to a homebrew 68030 machine
> (KISS-68030) which involved adding a new machine type and writing some
> drivers, so I have a little bit of experience hacking on the kernel.

Very cool!

> I thought it might be interesting to have another M68K machine around, so I
> recently acquired a Q40 machine (a Sinclair QL successor with 40MHz 68040,
> 32MB RAM). It was broken and missing several components but I've fixed it up
> and I believe the hardware is now reliable.
>
> I've built Linux 6.2.1 and 6.4.4 kernels with Q40 support based on the
> kernel.org sources (both with and without my patches for KISS-68030) and
> tested booting on the Q40.
>
> If I omit the pata_falcon driver it boots fine, only dying when it finds no
> root filesystem available to mount.
>
> With the pata_falcon driver compiled in, however, it dies as shown below,
> while trying to access an ISA I/O port in the drivers/ata/libsff-ata.c code
> which pata_falcon uses.
>
> I did a little digging and it appears the root of the problem is that it is
> accessing the wrong address when trying to access the IDE taskfile registers.
> I believe this is because ISA addresses are being translated twice. The first
> translation makes sense but the second should not happen and results in the
> wrong address.
>
> The Q40 has an ISA bus through which the IDE bus is accessed. One of the
> CPLDs will synthesise ISA I/O and memory cycles from CPU memory accesses to
> certain regions of the physical address space.
>
> I traced through the code to try and understand the problem:
>
> I'll use 0x3f6 as an example ISA port address since this is what is being
> accessed when the crash occurs.
>
> First the correct ISA port address (0x3f6) is translated to the correct MMIO
> address (0xff400000 + 4 * 0x3f6 = 0xff400fd8).  This is done when the
> platform device is declared in arch/m68k/q40/config.c around line 288.
>
> Then this address is passed to pata_falcon which computes the correct MMIO
> addresses for the ATA task file registers in drivers/ata/pata_falcon.c around
> line 168 (ap->ioaddr.altstatus_addr = 0xff400fd8 + 1 = 0xff400fd9)
>
> The access to the hardware registers is performed in drivers/ata/libata-sff.c
> which uses ioread8/iowrite8. These functions are defined in lib/iomap.c.
> These functions look at the address passed it, determine that it is an MMIO
> address, and pass it to readb/writeb. This is the first error, we actually
> want to do an ISA I/O cycle, not memory cycle, but being passed a
> pre-translated address confuses these two functions.
>
> arch/m68k/include/asm/io_mm.h defines inb/outb/readb/writeb etc. They
> translate the provided address into the MMIO address in the Q40s physical
> address space and then perform the MMIO access.  This is where the second,
> unnecessary, translation takes place, and the resulting address is wrong:
> (0xff800000 + 1 + 4 * 0xff400fd9) & 0xffffffff = 0xfc803f65 -- and this is
> the address accessed when we get the oops.

Looks like something was missed in commit 44b1fbc0f5f30e66 ("m68k/q40:
Replace q40ide driver with pata_falcon and falconide") in v5.14.
Before, Q40 used its own IDE driver (q40ide, CONFIG_BLK_DEV_Q40IDE).
It might be a good idea to verify that IDE works in v5.13, as something
else might have been broken along the long road since last time someone
used IDE on Q40.

> I made an initial attempt to fix this: I rewrote pata_falcon.c to use the IO
> resources (untranslated ISA port addresses) and to store these in the
> ap->ioaddr struct instead:
>
> +        ap->ioaddr.cmd_addr = base_res->start;
> +        ap->ioaddr.ctl_addr = ctl_res->start;
> +        ata_sff_std_ports(&ap->ioaddr);
> +        ap->ioaddr.altstatus_addr = ap->ioaddr.ctl_addr;
>
> (one also has to fix up the pata_falcon_data_xfer function)
>
> This causes the ioread8/iowrite8 functions to complain loudly about "Bad IO
> access", because it wants me to be using cookies provided by ioport_map().
>
> Try two, using devm_ioport_map():
>
> +        ap->ioaddr.cmd_addr = devm_ioport_map(&pdev->dev, base_res->start, 8);
> +        ap->ioaddr.ctl_addr = devm_ioport_map(&pdev->dev, ctl_res->start, 1);
> +        ata_sff_std_ports(&ap->ioaddr);
> +        ap->ioaddr.altstatus_addr = ap->ioaddr.ctl_addr;
>
> This feels like the correct solution to me, however it also fails, because
> devm_ioport_map() only returns NULL without CONFIG_HAS_IOPORT_MAP -- but I
> think it should otherwise work.
>
> I tried using ioport_map() instead of devm_ioport_map, but the m68k version
> of this just returns the address without the offset that ioread8/iowrite8
> check for (without this offset it complains "Bad IO access").  I hacked up
> arch/m68k/include/asm/kmap.h to add this offset (wrong way to fix this, I
> know) and it works: disk is detected, partition table read from the media,
> happy days!
>
> [    1.680000] ata1: PATA max PIO4 cmd 0x1f0 ctl 0x3f6 irq 14
> [    1.970000] ata1.00: CFA: InnoDisk Corp. - iCF4000 2GB, 080414S4, max UDMA/66
> [    1.970000] ata1.00: 4095504 sectors, multi 2: LBA
> [    1.980000] ata1.00: configured for PIO
> [    1.990000] scsi 0:0:0:0: Direct-Access     ATA      InnoDisk Corp. - 14S4 PQ: 0 ANSI: 5
> [    2.040000] sd 0:0:0:0: [sda] 4095504 512-byte logical blocks: (2.10 GB/1.95 GiB)
> [    2.040000] sd 0:0:0:0: [sda] Write Protect is off
> [    2.060000] sd 0:0:0:0: [sda] Write cache: disabled, read cache: enabled, doesn't support DPO or FUA
> [    2.070000] sd 0:0:0:0: [sda] Preferred minimum I/O size 512 bytes
> [    2.300000]  sda: AHDI sda1 sda2 sda3
> [    2.330000] sd 0:0:0:0: [sda] Attached SCSI disk
>
> So the driver code is apparently functional.
>
> I feel that turning on CONFIG_HAS_IOPORT_MAP is part of the answer here. But
> at this point I'm beyond changing a single driver and into much wider M68K
> changes which is why I am reaching out for advice!
>
> I could alternatively fix this by further rewriting pata_falcon to replace
> the libata-sff.c functions that perform I/O access with my own versions that
> call inb/outb instead of ioread8/iowrite8 -- but this feels like the wrong
> place to solve the problem ... If I could fix ioport_map and ioread*/iowrite*
> then any ISA hardware driver using this interface should become usable on the
> Q40.
>
> Sorry again for the long email -- just trying to give you enough detail to
> understand the problem fully!
>
> Thanks
>
> Will
>
> --
>
>
> [    0.000000] Linux version 6.4.4-wrs (btg@carbon) (m68k-linux-gnu-gcc (Debian 12.2.0-13) 12.2.0, GNU ld (GNU Binutils for Debian) 2.40) #1 Sat Jul 22 12:13:58 BST 2023
> [    0.000000] Zone ranges:
> [    0.000000]   DMA      [mem 0x0000000000040000-0x0000001fffffffff]
> [    0.000000]   Normal   empty
> [    0.000000] Movable zone start for each node
> [    0.000000] Early memory node ranges
> [    0.000000]   node   0: [mem 0x0000000000040000-0x0000000001ffffff]
> [    0.000000] Initmem setup node 0 [mem 0x0000000000040000-0x0000000001ffffff]
> [    0.000000] Kernel command line: console=ttyS2,115200n8 earlyprintk=ttyS2,115200  BOOT_IMAGE=vmlinux
> [    0.000000] Unknown kernel command line parameters "BOOT_IMAGE=vmlinux", will be passed to user space.
> [    0.000000] Dentry cache hash table entries: 4096 (order: 2, 16384 bytes, linear)
> [    0.000000] Inode-cache hash table entries: 2048 (order: 1, 8192 bytes, linear)
> [    0.000000] Sorting __ex_table...
> [    0.000000] Built 1 zonelists, mobility grouping on.  Total pages: 8056
> [    0.000000] mem auto-init: stack:off, heap alloc:off, heap free:off
> [    0.000000] Memory: 27340K/32512K available (3220K kernel code, 443K rwdata, 988K rodata, 120K init, 129K bss, 5172K reserved, 0K cma-reserved)
> [    0.000000] NR_IRQS: 43
> [    0.000000] Console: colour dummy device 80x25
> [    0.000000] printk: console [ttyS2] enabled
> [    0.090000] Calibrating delay loop... 26.16 BogoMIPS (lpj=130816)
> [    0.200000] pid_max: default: 32768 minimum: 301
> [    0.210000] Mount-cache hash table entries: 1024 (order: 0, 4096 bytes, linear)
> [    0.220000] Mountpoint-cache hash table entries: 1024 (order: 0, 4096 bytes, linear)
> [    0.260000] cblist_init_generic: Setting adjustable number of callback queues.
> [    0.260000] cblist_init_generic: Setting shift to 0 and lim to 1.
> [    0.280000] devtmpfs: initialized
> [    0.310000] clocksource: jiffies: mask: 0xffffffff max_cycles: 0xffffffff, max_idle_ns: 19112604462750000 ns
> [    0.320000] futex hash table entries: 256 (order: -1, 3072 bytes, linear)
> [    0.360000] NET: Registered PF_NETLINK/PF_ROUTE protocol family
> [    0.370000] DMA: preallocated 128 KiB GFP_KERNEL pool for atomic allocations
> [    0.370000] DMA: preallocated 128 KiB GFP_KERNEL|GFP_DMA pool for atomic allocations
> [    0.430000] SCSI subsystem initialized
> [    0.790000] NET: Registered PF_INET protocol family
> [    0.800000] IP idents hash table entries: 2048 (order: 2, 16384 bytes, linear)
> [    0.830000] tcp_listen_portaddr_hash hash table entries: 1024 (order: 0, 4096 bytes, linear)
> [    0.840000] Table-perturb hash table entries: 65536 (order: 6, 262144 bytes, linear)
> [    0.850000] TCP established hash table entries: 1024 (order: 0, 4096 bytes, linear)
> [    0.850000] TCP bind hash table entries: 1024 (order: 1, 8192 bytes, linear)
> [    0.860000] TCP: Hash tables configured (established 1024 bind 1024)
> [    0.870000] UDP hash table entries: 256 (order: 0, 4096 bytes, linear)
> [    0.870000] UDP-Lite hash table entries: 256 (order: 0, 4096 bytes, linear)
> [    0.880000] NET: Registered PF_UNIX/PF_LOCAL protocol family
> [    0.910000] workingset: timestamp_bits=30 max_order=13 bucket_order=0
> [    1.310000] fb0: Q40 frame buffer alive and kicking !
> [    1.320000] Serial: 8250/16550 driver, 8 ports, IRQ sharing disabled
> [    1.330000] serial8250: ttyS0 at I/O 0x3f8 (irq = 4, base_baud = 115200) is a 16450
> [    1.340000] serial8250: ttyS1 at I/O 0x2f8 (irq = 3, base_baud = 115200) is a 16450
> [    1.360000] serial8250: ttyS2 at I/O 0x3e8 (irq = 4, base_baud = 115200) is a 16550A
> [    1.380000] serial8250: ttyS3 at I/O 0x2e8 (irq = 3, base_baud = 115200) is a 16550A
> [    1.590000] loop: module loaded
> [    1.590000] atari-falcon-ide atari-falcon-ide.0: Atari Falcon and Q40/Q60 PATA controller
> [    1.600000] Unable to handle kernel access at virtual address (ptrval)
> [    1.600000] Oops: 00000000
> [    1.600000] Modules linked in:
> [    1.600000] PC: [<001bb4aa>] iowrite8+0x1c/0x46
> [    1.600000] SR: 2710  SP: (ptrval)  a2: 007d5570
> [    1.600000] d0: fc803f65    d1: 0000000a    d2: 00002000    d3: 00000000
> [    1.600000] d4: 00000000    d5: 0021178a    a0: fc803f65    a1: 00000000
> [    1.600000] Process swapper (pid: 1, task=(ptrval))
> [    1.600000] Frame format=7 eff addr=007d7dd4 ssw=04a5 faddr=fc803f65
> [    1.600000] wb 1 stat/addr/data: 0005 0091568d 009156c8
> [    1.600000] wb 2 stat/addr/data: 00a5 fc803f65 0000000a
> [    1.600000] wb 3 stat/addr/data: 0025 fc803f65 0000000a
> [    1.600000] push data: 009156c8 00000000 ff400fd8 09ffffff
> [    1.600000] Stack from 007d7d80:
> [    1.600000]         00210060 0000000a ff400fd9 0021008a 00914000 0000000a 00914000 0020beee
> [    1.600000]         00914000 00965bc0 0020c2f4 00914000 00000001 00203de4 00914000 001ea3e0
> [    1.600000]         0000000e 0034a504 00965bc0 0020be4c 007fe000 00965bc0 00204482 00965bc0
> [    1.600000]         001ea3e0 007f9940 00000000 00000000 00002080 00914000 0020be4c 007fe000
> [    1.600000]         0049d366 00965bc0 0000000e 0021178a 00000080 0034a504 00000000 00000000
> [    1.600000]         007fe00a 00465d40 00306e00 0090fcb4 001ea98a 007fe000 007fe00a 00465d40
> [    1.600000] Call Trace: [<00210060>] ata_sff_set_devctl+0x3c/0x42
> [    1.600000]  [<0021008a>] ata_sff_freeze+0x24/0x4c
> [    1.600000]  [<0020beee>] __ata_port_freeze+0x3a/0x46
> [    1.600000]  [<0020c2f4>] ata_eh_freeze_port+0x1c/0x24
> [    1.600000]  [<00203de4>] ata_host_start+0x112/0x130
> [    1.600000]  [<001ea3e0>] platform_get_resource+0x0/0x48
> [    1.600000]  [<0020be4c>] ata_port_desc+0x0/0x68
> [    1.600000]  [<00204482>] ata_host_activate+0x20/0xf8
> [    1.600000]  [<001ea3e0>] platform_get_resource+0x0/0x48
> [    1.600000]  [<00002080>] do_one_initcall+0x0/0x184
> [    1.600000]  [<0020be4c>] ata_port_desc+0x0/0x68
> [    1.600000]  [<0049d366>] pata_falcon_init_one+0x1f8/0x206
> [    1.600000]  [<0021178a>] ata_sff_interrupt+0x0/0x144
> [    1.600000]  [<00306e00>] klist_next+0x0/0x80
> [    1.600000]  [<001ea98a>] platform_probe+0x22/0x4e
> [    1.600000]  [<001e916e>] really_probe+0xfa/0x200
> [    1.600000]  [<001e9366>] driver_probe_device+0x20/0x78
> [    1.600000]  [<00314f4a>] strcpy+0x0/0x1c
> [    1.600000]  [<001e9502>] __driver_attach+0xbe/0xce
> [    1.600000]  [<00306e00>] klist_next+0x0/0x80
> [    1.600000]  [<001e7930>] bus_for_each_dev+0x62/0x86
> [    1.600000]  [<001e8b7c>] driver_attach+0x16/0x1c
> [    1.600000]  [<001e9444>] __driver_attach+0x0/0xce
> [    1.600000]  [<001e85ec>] bus_add_driver+0x96/0x18c
> [    1.600000]  [<001e9ba2>] driver_register+0x9c/0xda
> [    1.600000]  [<001ea932>] __platform_driver_probe+0x64/0x9a
> [    1.600000]  [<0049d156>] pata_falcon_driver_init+0x0/0x18
> [    1.600000]  [<0049d168>] pata_falcon_driver_init+0x12/0x18
> [    1.600000]  [<0049d16e>] pata_falcon_init_one+0x0/0x206
> [    1.600000]  [<000020da>] do_one_initcall+0x5a/0x184
> [    1.600000]  [<00314f4a>] strcpy+0x0/0x1c
> [    1.600000]  [<00028354>] parse_args+0x0/0x25e
> [    1.600000]  [<00002080>] do_one_initcall+0x0/0x184
> [    1.600000]  [<00060006>] check_max_stack_depth+0x188/0x1f8
> [    1.600000]  [<0048f4ba>] kernel_init_freeable+0x132/0x18a
> [    1.600000]  [<0048f508>] kernel_init_freeable+0x180/0x18a
> [    1.600000]  [<0049d156>] pata_falcon_driver_init+0x0/0x18
> [    1.600000]  [<000286a8>] list_del_init+0x0/0x1c
> [    1.600000]  [<00015cbc>] kernel_thread+0x0/0x68
> [    1.600000]  [<00320c50>] kernel_init+0x0/0xec
> [    1.600000]  [<00320c64>] kernel_init+0x14/0xec
> [    1.600000]  [<00320c50>] kernel_init+0x0/0xec
> [    1.600000]  [<00002898>] ret_from_kernel_thread+0xc/0x14
> [    1.600000]
> [    1.600000] Code: 0000 650e e588 0680 ff80 0001 2040 1081 <4e75> 0c80 0001 0000 6310 0280 0000 ffff e588 0680 ff40 0001 60e2 2f7c 003e 1365
> [    1.600000] Disabling lock debugging due to kernel taint
> [    1.600000] note: swapper[1] exited with irqs disabled
> [    1.610000] Kernel panic - not syncing: Attempted to kill init! exitcode=0x0000000b
> [    1.610000] ---[ end Kernel panic - not syncing: Attempted to kill init! exitcode=0x0000000b ]---
>
>
>
> _________________________________________________________________________
> William R Sowerbutts                                  will@sowerbutts.com
> "Carpe post meridiem"                               http://sowerbutts.com
>          main(){char*s=">#=0> ^#X@#@^7=",c=0,m;for(;c<15;c++)for
>          (m=-1;m<7;putchar(m++/6&c%3/2?10:s[c]-31&1<<m?42:32));}
>

Gr{oetje,eeting}s,

                        Geert

-- 
Geert Uytterhoeven -- There's lots of Linux beyond ia32 -- geert@linux-m68k.org

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

Re: Linux 6.4.4 on m68k - Q40 - pata_falcon causes oops at boot time

[Finn Thain]

On Sun, 23 Jul 2023, Geert Uytterhoeven wrote:

> >
> > First the correct ISA port address (0x3f6) is translated to the 
> > correct MMIO address (0xff400000 + 4 * 0x3f6 = 0xff400fd8).  This is 
> > done when the platform device is declared in arch/m68k/q40/config.c 
> > around line 288.
> >
> > Then this address is passed to pata_falcon which computes the correct 
> > MMIO addresses for the ATA task file registers in 
> > drivers/ata/pata_falcon.c around line 168 (ap->ioaddr.altstatus_addr = 
> > 0xff400fd8 + 1 = 0xff400fd9)
> >
> > The access to the hardware registers is performed in 
> > drivers/ata/libata-sff.c which uses ioread8/iowrite8. These functions 
> > are defined in lib/iomap.c. These functions look at the address passed 
> > it, determine that it is an MMIO address, and pass it to readb/writeb. 
> > This is the first error, we actually want to do an ISA I/O cycle, not 
> > memory cycle, but being passed a pre-translated address confuses these 
> > two functions.
> >
> > arch/m68k/include/asm/io_mm.h defines inb/outb/readb/writeb etc. They 
> > translate the provided address into the MMIO address in the Q40s 
> > physical address space and then perform the MMIO access.  This is 
> > where the second, unnecessary, translation takes place, and the 
> > resulting address is wrong: (0xff800000 + 1 + 4 * 0xff400fd9) & 
> > 0xffffffff = 0xfc803f65 -- and this is the address accessed when we 
> > get the oops.
> 

Could be related to the bug that Michael tackled here?
https://lore.kernel.org/linux-m68k/1623290683-17859-1-git-send-email-schmitzmic@gmail.com/

> Looks like something was missed in commit 44b1fbc0f5f30e66 ("m68k/q40: 
> Replace q40ide driver with pata_falcon and falconide") in v5.14. Before, 
> Q40 used its own IDE driver (q40ide, CONFIG_BLK_DEV_Q40IDE). 

Could be that too.

> It might be a good idea to verify that IDE works in v5.13

Yes, please do.

Re: Linux 6.4.4 on m68k - Q40 - pata_falcon causes oops at boot time

[William R Sowerbutts]

>> It might be a good idea to verify that IDE works in v5.13
>
>Yes, please do.

It does:

[    0.000000] Linux version 5.13.0-wrs (btg@carbon) (m68k-linux-gnu-gcc (Debian 12.2.0-13) 12.2.0, GNU ld (GNU Binutils for Debian) 2.40) #1 Sun Jul 23 15:47:14 BST 2023
[    0.000000] Zone ranges:
[    0.000000]   DMA      [mem 0x0000000000040000-0x0000001fffffffff]
[    0.000000]   Normal   empty
[    0.000000] Movable zone start for each node
[    0.000000] Early memory node ranges
[    0.000000]   node   0: [mem 0x0000000000040000-0x0000000001ffffff]
[    0.000000] Initmem setup node 0 [mem 0x0000000000040000-0x0000000001ffffff]
[    0.000000] Built 1 zonelists, mobility grouping on.  Total pages: 8056
[    0.000000] Kernel command line: console=ttyS2,115200n8 earlyprintk=ttyS2,115200  BOOT_IMAGE=vmlinux513
[    0.000000] Dentry cache hash table entries: 4096 (order: 2, 16384 bytes, linear)
[    0.000000] Inode-cache hash table entries: 2048 (order: 1, 8192 bytes, linear)
[    0.000000] Sorting __ex_table...
[    0.000000] mem auto-init: stack:off, heap alloc:off, heap free:off
[    0.000000] Memory: 27708K/32512K available (2991K kernel code, 449K rwdata, 856K rodata, 104K init, 133K bss, 4804K reserved, 0K cma-reserved)
[    0.000000] NR_IRQS: 43
[    0.010000] Console: colour dummy device 80x25
[    0.090000] printk: console [ttyS2] enabled
[    0.090000] Calibrating delay loop... 26.16 BogoMIPS (lpj=130816)
[    0.210000] pid_max: default: 32768 minimum: 301
[    0.220000] Mount-cache hash table entries: 1024 (order: 0, 4096 bytes, linear)
[    0.230000] Mountpoint-cache hash table entries: 1024 (order: 0, 4096 bytes, linear)
[    0.270000] devtmpfs: initialized
[    0.290000] random: get_random_u32 called from bucket_table_alloc.isra.0+0xe0/0xf8 with crng_init=0
[    0.300000] clocksource: jiffies: mask: 0xffffffff max_cycles: 0xffffffff, max_idle_ns: 19112604462750000 ns
[    0.310000] futex hash table entries: 256 (order: -1, 3072 bytes, linear)
[    0.330000] NET: Registered protocol family 16
[    0.330000] DMA: preallocated 128 KiB GFP_KERNEL pool for atomic allocations
[    0.340000] DMA: preallocated 128 KiB GFP_KERNEL|GFP_DMA pool for atomic allocations
[    0.500000] wait_for_initramfs() called before rootfs_initcalls
[    0.530000] SCSI subsystem initialized
[    0.800000] NET: Registered protocol family 2
[    0.810000] IP idents hash table entries: 2048 (order: 2, 16384 bytes, linear)
[    0.830000] tcp_listen_portaddr_hash hash table entries: 512 (order: 0, 4096 bytes, linear)
[    0.840000] TCP established hash table entries: 1024 (order: 0, 4096 bytes, linear)
[    0.840000] TCP bind hash table entries: 1024 (order: 0, 4096 bytes, linear)
[    0.850000] TCP: Hash tables configured (established 1024 bind 1024)
[    0.850000] UDP hash table entries: 256 (order: 0, 4096 bytes, linear)
[    0.860000] UDP-Lite hash table entries: 256 (order: 0, 4096 bytes, linear)
[    0.870000] NET: Registered protocol family 1
[    0.890000] workingset: timestamp_bits=30 max_order=13 bucket_order=0
[    0.930000] fb0: Q40 frame buffer alive and kicking !
[    0.940000] Serial: 8250/16550 driver, 8 ports, IRQ sharing disabled
[    0.950000] serial8250: ttyS0 at I/O 0x3f8 (irq = 4, base_baud = 115200) is a 16450
[    0.960000] serial8250: ttyS1 at I/O 0x2f8 (irq = 3, base_baud = 115200) is a 16450
[    0.980000] serial8250: ttyS2 at I/O 0x3e8 (irq = 4, base_baud = 115200) is a 16550A
[    0.990000] serial8250: ttyS3 at I/O 0x2e8 (irq = 3, base_baud = 115200) is a 16550A
[    1.160000] loop: module loaded
[    1.160000] Uniform Multi-Platform E-IDE driver
[    1.170000] ide: Q40 IDE controller
[    1.170000] legacy IDE will be removed in 2021, please switch to libata
[    1.170000] Report any missing HW support to linux-ide@vger.kernel.org
[    1.280000] random: fast init done
[    1.540000] hda: InnoDisk Corp. - iCF4000 2GB, CFA DISK drive
[    2.680000] ide0 at 0xff4007c0 on irq 14
[    2.690000] ide1 at 0xff4005c0 on irq 15
[    2.700000] ide-gd driver 1.18
[    2.700000] hda: max request size: 128KiB
[    2.710000] hda: 4095504 sectors (2096 MB) w/1KiB Cache, CHS=4063/16/63
[    2.750000] hda: cache flushes supported
[    2.780000]  hda: AHDI hda1 hda2 hda3
[    2.910000] PPP generic driver version 2.4.2
[    2.920000] serio: Q40 kbd registered
[    2.940000] NET: Registered protocol family 10
[    2.960000] input: AT Raw Set 2 keyboard as /devices/platform/q40kbd/serio0/input/input0
[    2.980000] Segment Routing with IPv6
[    3.000000] VFS: Cannot open root device "(null)" or unknown-block(0,0): error -6

_________________________________________________________________________
William R Sowerbutts                                  will@sowerbutts.com
"Carpe post meridiem"                               http://sowerbutts.com
         main(){char*s=">#=0> ^#X@#@^7=",c=0,m;for(;c<15;c++)for
         (m=-1;m<7;putchar(m++/6&c%3/2?10:s[c]-31&1<<m?42:32));}  

Re: Linux 6.4.4 on m68k - Q40 - pata_falcon causes oops at boot time

[Finn Thain]

On Sun, 23 Jul 2023, William R Sowerbutts wrote:

> > > It might be a good idea to verify that IDE works in v5.13
> >
> > Yes, please do.
> 
> It does:
> 
> [    0.000000] Linux version 5.13.0-wrs (btg@carbon) (m68k-linux-gnu-gcc (Debian 12.2.0-13) 12.2.0, GNU ld (GNU Binutils for Debian) 2.40) #1 Sun Jul 23 15:47:14 BST 2023

Thankyou for building and testing 5.13. Would you please send the .configs 
from your 5.13 and 6.4 builds?

Re: Linux 6.4.4 on m68k - Q40 - pata_falcon causes oops at boot time

[William R Sowerbutts]

[-- Attachment #1: Type: text/plain, Size: 887 bytes --]

Certainly -- attached

On Mon, Jul 24, 2023 at 11:43:44AM +1000, Finn Thain wrote:
>On Sun, 23 Jul 2023, William R Sowerbutts wrote:
>
>> > > It might be a good idea to verify that IDE works in v5.13
>> >
>> > Yes, please do.
>> 
>> It does:
>> 
>> [    0.000000] Linux version 5.13.0-wrs (btg@carbon) (m68k-linux-gnu-gcc (Debian 12.2.0-13) 12.2.0, GNU ld (GNU Binutils for Debian) 2.40) #1 Sun Jul 23 15:47:14 BST 2023
>
>Thankyou for building and testing 5.13. Would you please send the .configs 
>from your 5.13 and 6.4 builds?

_________________________________________________________________________
William R Sowerbutts                                  will@sowerbutts.com
"Carpe post meridiem"                               http://sowerbutts.com
         main(){char*s=">#=0> ^#X@#@^7=",c=0,m;for(;c<15;c++)for
         (m=-1;m<7;putchar(m++/6&c%3/2?10:s[c]-31&1<<m?42:32));}  


[-- Attachment #2: config-5.13.gz --]
[-- Type: application/gzip, Size: 9722 bytes --]

[-- Attachment #3: config-6.4.4.gz --]
[-- Type: application/gzip, Size: 10356 bytes --]

Re: Linux 6.4.4 on m68k - Q40 - pata_falcon causes oops at boot time

[Finn Thain]

On Mon, 24 Jul 2023, William R Sowerbutts wrote:

> Certainly -- attached
> 

Thanks for that. I see that you're using a .config with CONFIG_ATARI 
disabled, meaning that MULTI_ISA is not in play.

Re: Linux 6.4.4 on m68k - Q40 - pata_falcon causes oops at boot time

[Michael Schmitz]

Hi Finn, William,

On 23/07/23 21:59, Finn Thain wrote:
> On Sun, 23 Jul 2023, Geert Uytterhoeven wrote:
>
>>> First the correct ISA port address (0x3f6) is translated to the
>>> correct MMIO address (0xff400000 + 4 * 0x3f6 = 0xff400fd8).  This is
>>> done when the platform device is declared in arch/m68k/q40/config.c
>>> around line 288.
>>>
>>> Then this address is passed to pata_falcon which computes the correct
>>> MMIO addresses for the ATA task file registers in
>>> drivers/ata/pata_falcon.c around line 168 (ap->ioaddr.altstatus_addr =
>>> 0xff400fd8 + 1 = 0xff400fd9)
>>>
>>> The access to the hardware registers is performed in
>>> drivers/ata/libata-sff.c which uses ioread8/iowrite8. These functions
>>> are defined in lib/iomap.c. These functions look at the address passed
>>> it, determine that it is an MMIO address, and pass it to readb/writeb.
>>> This is the first error, we actually want to do an ISA I/O cycle, not

Thanks for testing the function of Q40 IDE after rebuilding a Q40!

I was left with the impression that the Q40 does not actually have the 
IDE controller on the ISA bus. The address translation in io_mm.h 
assumes IDE on Q40 works through MMIO on the 0xff400000 IO window. This 
also assumes that addresses passed to the m68k IO primitives must be IO 
port addresses (< 0x1000 or so).

If that assumption is incorrect, the address translation in io_mm.h must 
be changed.


>>> memory cycle, but being passed a pre-translated address confuses these
>>> two functions.
Doesn't seem to do that for my Falcon - the addresses passed are all 
from the 0xffxxxxxx range and get passed straight through to the IDE 
controller. But there's no translation in use for IDE there.
>>>
>>> arch/m68k/include/asm/io_mm.h defines inb/outb/readb/writeb etc. They
>>> translate the provided address into the MMIO address in the Q40s
>>> physical address space and then perform the MMIO access.  This is
>>> where the second, unnecessary, translation takes place, and the
>>> resulting address is wrong: (0xff800000 + 1 + 4 * 0xff400fd9) &
>>> 0xffffffff = 0xfc803f65 -- and this is the address accessed when we
>>> get the oops.
> Could be related to the bug that Michael tackled here?
> https://lore.kernel.org/linux-m68k/1623290683-17859-1-git-send-email-schmitzmic@gmail.com/

That patch just tried to make sure the address translation and IO 
primitives are selected based on the machine (and ISA bus) type. It 
didn't change the Q40 address translations.

The problem appears to be that pata_falcon.c used addresses from the 
MMIO range for both IO and memory cycles (there's no difference on 
Falcon - the address translation in use for IDE is an identity mapping). 
On Q40, the addresses set up in pata_falcon_init_one() ought to be IO 
port addresses instead, as long as Q40 address translations then map 
these into the correct IO or memory access windows. But pata_falcon 
takes the addresses to use from resources defined at platform init time, 
so that won't work anymore. I rather think the second patch in this 
context is to blame:

>> Looks like something was missed in commit 44b1fbc0f5f30e66 ("m68k/q40:
>> Replace q40ide driver with pata_falcon and falconide") in v5.14. Before,
>> Q40 used its own IDE driver (q40ide, CONFIG_BLK_DEV_Q40IDE).
> Could be that too.

Yep - what's been missed is that the Q40 address translation functions 
Q40_ISA_IO_B() and Q40_ISA_IO_W() were only used to set up the register 
addresses in the old Q40 driver. My intention with that patch was to 
only use the new IO resources for the purpose of request_region(), but 
at least (!) since converting to the pata_falcon driver, they are now 
also used for the unwanted second translation step.

Can you try changing Q40_ISA_IO_B() and Q40_ISA_IO_W() to identity 
mappings, so only one set of translations takes place?

>
>> It might be a good idea to verify that IDE works in v5.13
> Yes, please do.

And please also verify it's broken after 44b1fbc0f5f30e66 was applied.

Cheers,

     Michael

Re: Linux 6.4.4 on m68k - Q40 - pata_falcon causes oops at boot time

[William R Sowerbutts]

>I was left with the impression that the Q40 does not actually have the IDE
>controller on the ISA bus.

This is mistaken.

IDE is definitely accessed over the ISA bus.

There is some documentation on the Q40/Q60 hardware here:
http://www.q40.de/download/harddoc.pdf

The motherboard integrates the CPU, DRAM, video DRAM and display controller, 
audio DACs, RTC, interrupt controller, keyboard controller, and an LED 
output.

There are two ISA slots where all other I/O devices are connected. These are 
described (concisely!) on page 7 of the linked manual:

8-bit ISA I/O cycles are performed for CPU byte accesses to 0xFF400001 + 4 * ISA address

16-bit ISA I/O cycles are performed for CPU word accesses to 0xFF400000 + 4 * ISA address

8-bit ISA memory cycles are performed for CPU byte accesses to 0xFF800001 + 4 * ISA address

16-bit ISA memory cycles are performed for CPU word accesses to 0xFF800000 + 4 * ISA address

I understand that the machines originally shipped with a 16-bit ISA card 
based on the W83787IF "PC super I/O" chip, integrating a floppy controller, 
IDE interface, game port, parallel port, and two 16550A UARTs.

My Q40 came without this card, so I am using a card based on the similar 
W83757 chip (the serial ports are 16450 instead of 16550A, it doesn't support 
the fancy EPP/ECP parallel port modes).

>> > It might be a good idea to verify that IDE works in v5.13
>> Yes, please do.

It did.

>And please also verify it's broken after 44b1fbc0f5f30e66 was applied.

I will try to do that!

Thanks

Will

_________________________________________________________________________
William R Sowerbutts                                  will@sowerbutts.com
"Carpe post meridiem"                               http://sowerbutts.com
         main(){char*s=">#=0> ^#X@#@^7=",c=0,m;for(;c<15;c++)for
         (m=-1;m<7;putchar(m++/6&c%3/2?10:s[c]-31&1<<m?42:32));}  

Re: Linux 6.4.4 on m68k - Q40 - pata_falcon causes oops at boot time

[Michael Schmitz]

Thanks William,

On 24/07/23 23:42, William R Sowerbutts wrote:
>> I was left with the impression that the Q40 does not actually have the IDE
>> controller on the ISA bus.
> This is mistaken.
>
> IDE is definitely accessed over the ISA bus.
>
> There is some documentation on the Q40/Q60 hardware here:
> http://www.q40.de/download/harddoc.pdf
Noted - hadn't seen this one before.
>
> The motherboard integrates the CPU, DRAM, video DRAM and display controller,
> audio DACs, RTC, interrupt controller, keyboard controller, and an LED
> output.

No disk controller on the main board - that's where my error originated.

Note that this also means that the address hardcoded for IDE may be 
incorrect (AFAIR, IDE cards could have their IO base reassigned by 
firmware).

> There are two ISA slots where all other I/O devices are connected. These are
> described (concisely!) on page 7 of the linked manual:
>
> 8-bit ISA I/O cycles are performed for CPU byte accesses to 0xFF400001 + 4 * ISA address
>
> 16-bit ISA I/O cycles are performed for CPU word accesses to 0xFF400000 + 4 * ISA address
>
> 8-bit ISA memory cycles are performed for CPU byte accesses to 0xFF800001 + 4 * ISA address
>
> 16-bit ISA memory cycles are performed for CPU word accesses to 0xFF800000 + 4 * ISA address
Yep, that much is evident from the Q40 address translation scheme. But a 
similar sort of scheme is used on other m68k platforms to wire up 
peripherals that were originally designed for Intel systems, and these 
are not connected through an ISA bus.
> I understand that the machines originally shipped with a 16-bit ISA card
> based on the W83787IF "PC super I/O" chip, integrating a floppy controller,
> IDE interface, game port, parallel port, and two 16550A UARTs.
OK.
>
> My Q40 came without this card, so I am using a card based on the similar
> W83757 chip (the serial ports are 16450 instead of 16550A, it doesn't support
> the fancy EPP/ECP parallel port modes).
>
>>>> It might be a good idea to verify that IDE works in v5.13
>>> Yes, please do.
> It did.
>
>> And please also verify it's broken after 44b1fbc0f5f30e66 was applied.
> I will try to do that!

Probably just try v5.14 - in my tree, 44b1fbc0f5f30e66 came on top of 
5.13-rc2 so 5.14 ought to have it applied (but rather check, just the same).

Cheers,

     Michael


>
> Thanks
>
> Will
>
> _________________________________________________________________________
> William R Sowerbutts                                  will@sowerbutts.com
> "Carpe post meridiem"                               http://sowerbutts.com
>           main(){char*s=">#=0> ^#X@#@^7=",c=0,m;for(;c<15;c++)for
>           (m=-1;m<7;putchar(m++/6&c%3/2?10:s[c]-31&1<<m?42:32));}
>

Re: Linux 6.4.4 on m68k - Q40 - pata_falcon causes oops at boot time

[Finn Thain]

On Tue, 25 Jul 2023, Michael Schmitz wrote:

> Thanks William,
> 
> On 24/07/23 23:42, William R Sowerbutts wrote:
> >> I was left with the impression that the Q40 does not actually have the IDE
> >> controller on the ISA bus.
> > This is mistaken.
> >
> > IDE is definitely accessed over the ISA bus.
> >
> > There is some documentation on the Q40/Q60 hardware here:
> > http://www.q40.de/download/harddoc.pdf
> Noted - hadn't seen this one before.
> >
> > The motherboard integrates the CPU, DRAM, video DRAM and display controller,
> > audio DACs, RTC, interrupt controller, keyboard controller, and an LED
> > output.
> 
> No disk controller on the main board - that's where my error originated.
> 
> Note that this also means that the address hardcoded for IDE may be 
> incorrect (AFAIR, IDE cards could have their IO base reassigned by 
> firmware).
> 
> > There are two ISA slots where all other I/O devices are connected. These are
> > described (concisely!) on page 7 of the linked manual:
> >
> > 8-bit ISA I/O cycles are performed for CPU byte accesses to 0xFF400001 + 4 *
> > ISA address
> >
> > 16-bit ISA I/O cycles are performed for CPU word accesses to 0xFF400000 + 4
> > * ISA address
> >
> > 8-bit ISA memory cycles are performed for CPU byte accesses to 0xFF800001 +
> > 4 * ISA address
> >
> > 16-bit ISA memory cycles are performed for CPU word accesses to 0xFF800000 +
> > 4 * ISA address
> Yep, that much is evident from the Q40 address translation scheme. But a 
> similar sort of scheme is used on other m68k platforms to wire up 
> peripherals that were originally designed for Intel systems, and these 
> are not connected through an ISA bus.

I can't figure out why those platforms don't suffer from the same "double 
translation" problem that William described on q40.

> > I understand that the machines originally shipped with a 16-bit ISA card
> > based on the W83787IF "PC super I/O" chip, integrating a floppy controller,
> > IDE interface, game port, parallel port, and two 16550A UARTs.
> OK.
> >
> > My Q40 came without this card, so I am using a card based on the similar
> > W83757 chip (the serial ports are 16450 instead of 16550A, it doesn't
> > support
> > the fancy EPP/ECP parallel port modes).
> >
> >>>> It might be a good idea to verify that IDE works in v5.13
> >>> Yes, please do.
> > It did.
> >
> >> And please also verify it's broken after 44b1fbc0f5f30e66 was applied.
> > I will try to do that!
> 
> Probably just try v5.14 - in my tree, 44b1fbc0f5f30e66 came on top of 5.13-rc2
> so 5.14 ought to have it applied (but rather check, just the same).
> 

If git is an obstacle, one may obtain the 44b1fbc0f5f30e66 tree (as 
easily as the v5.14 tree) by clicking the 'download' button here: 
https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/commit/?id=44b1fbc0f5f30e66

Re: Linux 6.4.4 on m68k - Q40 - pata_falcon causes oops at boot time

[Michael Schmitz]

Hi Finn,

On 26/07/23 21:22, Finn Thain wrote:
>
>>> There are two ISA slots where all other I/O devices are connected. These are
>>> described (concisely!) on page 7 of the linked manual:
>>>
>>> 8-bit ISA I/O cycles are performed for CPU byte accesses to 0xFF400001 + 4 *
>>> ISA address
>>>
>>> 16-bit ISA I/O cycles are performed for CPU word accesses to 0xFF400000 + 4
>>> * ISA address
>>>
>>> 8-bit ISA memory cycles are performed for CPU byte accesses to 0xFF800001 +
>>> 4 * ISA address
>>>
>>> 16-bit ISA memory cycles are performed for CPU word accesses to 0xFF800000 +
>>> 4 * ISA address
>> Yep, that much is evident from the Q40 address translation scheme. But a
>> similar sort of scheme is used on other m68k platforms to wire up
>> peripherals that were originally designed for Intel systems, and these
>> are not connected through an ISA bus.
> I can't figure out why those platforms don't suffer from the same "double
> translation" problem that William described on q40.

There are only two other address translation schemes in effect - Amiga 
Gayle, which handles byte/word address offsets, and gets passed IO 
addresses (in the sense that these are the addresses where registers are 
mapped in memory), and Atari EtherNEC, which handles IO ports (from the 
ne.c legacy ISA driver).

The Gayle address translation, taking MMIO addresses does not add an IO 
base address. The EtherNEC address translation, OTOH, takes IO ports and 
must add the ROM port base address as IO base.

What I did not realize at the time I rewrote the Q40 driver as platform 
driver is that the old driver used IO ports, not MMIO addresses. In 
order to reserve the IDE register area (we don't have a MMIO area 
corresponding to the IO ports range mapped on m68k), I did add the Q40 
ISA base address to the IO port range to populate the platform memory 
resources, forgetting that the same base address is then added a second 
time through the IO address translation.

Seeing as the address passed into address translation already has the IO 
base offset of 0xff400000 and register scaling of 4 applied, it could be 
sufficient to change the address translations to only add the additional 
IO mem offset of 0x00400000:

#define q40_io_mem_offset 0x00400000

#define Q40_ISA_IO_B(ioaddr) ((unsigned long)(ioaddr))
#define Q40_ISA_IO_W(ioaddr) ((unsigned long)(ioaddr))
#define Q40_ISA_MEM_B(madr)  (q40_io_mem_offset + ((unsigned long)(madr)))
#define Q40_ISA_MEM_W(madr)  (q40_io_mem_offset + ((unsigned long)(madr)))

Note that this will play havoc with all other ISA drivers on Q40, so I'd 
just suggest that to test my hypothesis about how the address 
translation affects the IDE IO.


A correct fix would keep the current IO translation intact, and instead 
use the platform mem resource to register the driver IO range, and the 
platform IO resource as base offset to populate the port ioaddr struct 
(minus the register scaling and byte offset, mind you).

I'll give this some more thought ASAP.

And yes, I'm painfully aware the m68k low level IO code is becoming a 
bit of a maintainance legacy, in no small part due to my hacks around 
Atari EtherNEC.

Cheers,

     Michael


>
>>> I understand that the machines originally shipped with a 16-bit ISA card
>>> based on the W83787IF "PC super I/O" chip, integrating a floppy controller,
>>> IDE interface, game port, parallel port, and two 16550A UARTs.
>> OK.
>>> My Q40 came without this card, so I am using a card based on the similar
>>> W83757 chip (the serial ports are 16450 instead of 16550A, it doesn't
>>> support
>>> the fancy EPP/ECP parallel port modes).
>>>
>>>>>> It might be a good idea to verify that IDE works in v5.13
>>>>> Yes, please do.
>>> It did.
>>>
>>>> And please also verify it's broken after 44b1fbc0f5f30e66 was applied.
>>> I will try to do that!
>> Probably just try v5.14 - in my tree, 44b1fbc0f5f30e66 came on top of 5.13-rc2
>> so 5.14 ought to have it applied (but rather check, just the same).
>>
> If git is an obstacle, one may obtain the 44b1fbc0f5f30e66 tree (as
> easily as the v5.14 tree) by clicking the 'download' button here:
> https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/commit/?id=44b1fbc0f5f30e66

Re: Linux 6.4.4 on m68k - Q40 - pata_falcon causes oops at boot time

[Finn Thain]

On Thu, 27 Jul 2023, Michael Schmitz wrote:

> > I can't figure out why those platforms don't suffer from the same 
> > "double translation" problem that William described on q40.
> 
> There are only two other address translation schemes in effect - Amiga 
> Gayle, which handles byte/word address offsets, and gets passed IO 
> addresses (in the sense that these are the addresses where registers are 
> mapped in memory), and Atari EtherNEC, which handles IO ports (from the 
> ne.c legacy ISA driver).
> 
> The Gayle address translation, taking MMIO addresses does not add an IO 
> base address. The EtherNEC address translation, OTOH, takes IO ports and 
> must add the ROM port base address as IO base.
> 
> What I did not realize at the time I rewrote the Q40 driver as platform 
> driver is that the old driver used IO ports, not MMIO addresses. In 
> order to reserve the IDE register area (we don't have a MMIO area 
> corresponding to the IO ports range mapped on m68k), I did add the Q40 
> ISA base address to the IO port range to populate the platform memory 
> resources, forgetting that the same base address is then added a second 
> time through the IO address translation.
> [...]
> 
> A correct fix would keep the current IO translation intact, and instead 
> use the platform mem resource to register the driver IO range, and the 
> platform IO resource as base offset to populate the port ioaddr struct 
> (minus the register scaling and byte offset, mind you).
> 
> I'll give this some more thought ASAP.
> 

I wonder whether Will's suggestion (CONFIG_HAS_IOPORT_MAP) is feasible in 
light of the needs of Gayle and EtherNEC drivers.

> And yes, I'm painfully aware the m68k low level IO code is becoming a 
> bit of a maintainance legacy, in no small part due to my hacks around 
> Atari EtherNEC.
> 

I guess you and I both can share the blame for 44b1fbc0f5f30e66...

Anyway, you make a good point about on-going maintenance. Do you think 
that by supporting standard ISA drivers we might actually reduce the 
ideosyncracies in m68k IO code?

Re: Linux 6.4.4 on m68k - Q40 - pata_falcon causes oops at boot time

[Michael Schmitz]

Hi Finn,

Am 27.07.2023 um 13:16 schrieb Finn Thain:
>> A correct fix would keep the current IO translation intact, and instead
>> use the platform mem resource to register the driver IO range, and the
>> platform IO resource as base offset to populate the port ioaddr struct
>> (minus the register scaling and byte offset, mind you).
>>
>> I'll give this some more thought ASAP.
>>
>
> I wonder whether Will's suggestion (CONFIG_HAS_IOPORT_MAP) is feasible in
> light of the needs of Gayle and EtherNEC drivers.

I'll have to see how that works - both Gayle and EtherNEC don't just 
need address translation but their respective quirky IO access functions.

>
>> And yes, I'm painfully aware the m68k low level IO code is becoming a
>> bit of a maintainance legacy, in no small part due to my hacks around
>> Atari EtherNEC.
>>
>
> I guess you and I both can share the blame for 44b1fbc0f5f30e66...
>
> Anyway, you make a good point about on-going maintenance. Do you think
> that by supporting standard ISA drivers we might actually reduce the
> ideosyncracies in m68k IO code?

You and DaveM ought to have a chat about that - abstracting the legacy 
drivers from the ISA constraints was his preferred option when I last 
attempted to get the Gayle network driver patches merged. When I say 
'preferred', I'm probably understating a little.

I had toyed with that using the EtherNEC driver as test case but never 
got very far (this would have been splitting the driver into a core 
lib8390 module and a platform-specific module that allows to hook a 
variety of IO accessors as hooks, not static defines, and I wasn't too 
certain about performance impacts of such a change, the performance of 
the EtherNEC being so shitty it won't make any impact there),

The only other option (that I can see) would be creating a bus driver 
for the ISA bus, with platforms allowed to register their particular IO 
accessors for IO and memory accesses - again, performance impacts to 
consider and getting test coverage on legacy ISA hardware a nightmare. 
This would allow to use legacy driver code more or less unchanged. 
Haven't given that much thought at all (the idea pretty much originated 
from this present mess, but that's all).

There may be other approaches that can be considered, if none of this is 
what you had in mind.

Cheers,

	Michael

Re: Linux 6.4.4 on m68k - Q40 - pata_falcon causes oops at boot time

[Finn Thain]

On Thu, 27 Jul 2023, Michael Schmitz wrote:

> >
> >> And yes, I'm painfully aware the m68k low level IO code is becoming a 
> >> bit of a maintainance legacy, in no small part due to my hacks around 
> >> Atari EtherNEC.
> >>
> >
> > I guess you and I both can share the blame for 44b1fbc0f5f30e66...
> >
> > Anyway, you make a good point about on-going maintenance. Do you think 
> > that by supporting standard ISA drivers we might actually reduce the 
> > ideosyncracies in m68k IO code?
> 
> You and DaveM ought to have a chat about that - abstracting the legacy 
> drivers from the ISA constraints was his preferred option when I last 
> attempted to get the Gayle network driver patches merged. When I say 
> 'preferred', I'm probably understating a little.
> 

A discussion with maintainers probably won't get far without working code 
to look at. Perhaps William will send an RFC patch to illustrate his 
approach.

> I had toyed with that using the EtherNEC driver as test case but never 
> got very far (this would have been splitting the driver into a core 
> lib8390 module and a platform-specific module that allows to hook a 
> variety of IO accessors as hooks, not static defines, and I wasn't too 
> certain about performance impacts of such a change, the performance of 
> the EtherNEC being so shitty it won't make any impact there),
> 
> The only other option (that I can see) would be creating a bus driver 
> for the ISA bus, with platforms allowed to register their particular IO 
> accessors for IO and memory accesses - again, performance impacts to 
> consider and getting test coverage on legacy ISA hardware a nightmare. 
> This would allow to use legacy driver code more or less unchanged. 
> Haven't given that much thought at all (the idea pretty much originated 
> from this present mess, but that's all).
> 
> There may be other approaches that can be considered, if none of this is 
> what you had in mind.
> 

What I had in mind is probably unacceptable because drivers end up having 
to do byteswapping as happens in pata_falcon (or falconide and q40ide). 
Perhaps your bus driver idea would probabably find more acceptance. OTOH 
if the aim of the exercise is to use standard drivers (like pata_legacy) 
there would probably be driver changes either way.

It might be helpful to look for some precedent for this kind of thing 
among the other big-endian platforms with ISA. MIPS Magnum is dual-endian 
but Linux only runs in little-endian mode and the problem doesn't arise. 
But there must be other examples. Maybe CHRP?

Re: Linux 6.4.4 on m68k - Q40 - pata_falcon causes oops at boot time

[Geert Uytterhoeven]

Hi Finn,

On Fri, Jul 28, 2023 at 1:47 AM Finn Thain <fthain@linux-m68k.org> wrote:
> It might be helpful to look for some precedent for this kind of thing
> among the other big-endian platforms with ISA. MIPS Magnum is dual-endian
> but Linux only runs in little-endian mode and the problem doesn't arise.
> But there must be other examples. Maybe CHRP?

The ISA symbol on PPC indeed depends on CHRP.
But e.g. my LongTrail didn't have ISA slots.

Gr{oetje,eeting}s,

                        Geert

-- 
Geert Uytterhoeven -- There's lots of Linux beyond ia32 -- geert@linux-m68k.org

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

Re: Linux 6.4.4 on m68k - Q40 - pata_falcon causes oops at boot time

[Michael Schmitz]

Hi Finn,

Am 28.07.2023 um 11:47 schrieb Finn Thain:
>>> Anyway, you make a good point about on-going maintenance. Do you think
>>> that by supporting standard ISA drivers we might actually reduce the
>>> ideosyncracies in m68k IO code?
>>
>> You and DaveM ought to have a chat about that - abstracting the legacy
>> drivers from the ISA constraints was his preferred option when I last
>> attempted to get the Gayle network driver patches merged. When I say
>> 'preferred', I'm probably understating a little.
>>
>
> A discussion with maintainers probably won't get far without working code
> to look at. Perhaps William will send an RFC patch to illustrate his
> approach.

That would be good to have. Once that's tested and shown to work, we can 
float the idea with the IDE maintainers first.

>> I had toyed with that using the EtherNEC driver as test case but never
>> got very far (this would have been splitting the driver into a core
>> lib8390 module and a platform-specific module that allows to hook a
>> variety of IO accessors as hooks, not static defines, and I wasn't too
>> certain about performance impacts of such a change, the performance of
>> the EtherNEC being so shitty it won't make any impact there),
>>
>> The only other option (that I can see) would be creating a bus driver
>> for the ISA bus, with platforms allowed to register their particular IO
>> accessors for IO and memory accesses - again, performance impacts to
>> consider and getting test coverage on legacy ISA hardware a nightmare.
>> This would allow to use legacy driver code more or less unchanged.
>> Haven't given that much thought at all (the idea pretty much originated
>> from this present mess, but that's all).
>>
>> There may be other approaches that can be considered, if none of this is
>> what you had in mind.
>>
>
> What I had in mind is probably unacceptable because drivers end up having
> to do byteswapping as happens in pata_falcon (or falconide and q40ide).

Yes, but Q40 and Falcon are impossible to support any other way, and 
byte swapping the IDE interface in hardware was never repeated anywhere 
else, fortunately. We will have to keep pata_falcon around for that 
cause in any event.

> Perhaps your bus driver idea would probabably find more acceptance. OTOH
> if the aim of the exercise is to use standard drivers (like pata_legacy)
> there would probably be driver changes either way.

Supporting non-IDE drivers without too much hassle would be enough for 
starters (again excepting EtherNEC. Hmmm - I don't seem to have any 
hardware to test that wouldn't need quirky accessor hooks!).

> It might be helpful to look for some precedent for this kind of thing
> among the other big-endian platforms with ISA. MIPS Magnum is dual-endian
> but Linux only runs in little-endian mode and the problem doesn't arise.
> But there must be other examples. Maybe CHRP?

Not all of CHRP, hearing Geert tell it. But there must be some boards 
that have an ISA bus?
Probably not ISA, but I've got a PCMCIA slot on the Powerbook that I 
haven't been able to use. Maybe something's to be gleaned there.

Cheers.

	Michael

Re: Linux 6.4.4 on m68k - Q40 - pata_falcon causes oops at boot time

[Geert Uytterhoeven]

Hi Michael,

On Fri, Jul 28, 2023 at 9:52 AM Michael Schmitz <schmitzmic@gmail.com> wrote:
> Am 28.07.2023 um 11:47 schrieb Finn Thain:
> > What I had in mind is probably unacceptable because drivers end up having
> > to do byteswapping as happens in pata_falcon (or falconide and q40ide).
>
> Yes, but Q40 and Falcon are impossible to support any other way, and
> byte swapping the IDE interface in hardware was never repeated anywhere
> else, fortunately. We will have to keep pata_falcon around for that
> cause in any event.

Anyone remember TiVo? PPC with byte-swapped IDE interface.

> > It might be helpful to look for some precedent for this kind of thing
> > among the other big-endian platforms with ISA. MIPS Magnum is dual-endian
> > but Linux only runs in little-endian mode and the problem doesn't arise.
> > But there must be other examples. Maybe CHRP?
>
> Not all of CHRP, hearing Geert tell it. But there must be some boards
> that have an ISA bus?

It did have an ISA bus, but no ISA slots.
But the only external device on that bus was cs4232 audio.
All other ISA devices were internal to the south bridge.
http://g33rt.be/migrated/Linux/PPC/pci/isaAT1/.

Gr{oetje,eeting}s,

                        Geert

-- 
Geert Uytterhoeven -- There's lots of Linux beyond ia32 -- geert@linux-m68k.org

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

Re: Linux 6.4.4 on m68k - Q40 - pata_falcon causes oops at boot time

[Michael Schmitz]

Hi Geert,

Am 28.07.2023 um 20:03 schrieb Geert Uytterhoeven:
> Hi Michael,
>
> On Fri, Jul 28, 2023 at 9:52 AM Michael Schmitz <schmitzmic@gmail.com> wrote:
>> Am 28.07.2023 um 11:47 schrieb Finn Thain:
>>> What I had in mind is probably unacceptable because drivers end up having
>>> to do byteswapping as happens in pata_falcon (or falconide and q40ide).
>>
>> Yes, but Q40 and Falcon are impossible to support any other way, and
>> byte swapping the IDE interface in hardware was never repeated anywhere
>> else, fortunately. We will have to keep pata_falcon around for that
>> cause in any event.
>
> Anyone remember TiVo? PPC with byte-swapped IDE interface.

I vaguely remember, but had forgotten even that it was a PPC machine.

>
>>> It might be helpful to look for some precedent for this kind of thing
>>> among the other big-endian platforms with ISA. MIPS Magnum is dual-endian
>>> but Linux only runs in little-endian mode and the problem doesn't arise.
>>> But there must be other examples. Maybe CHRP?
>>
>> Not all of CHRP, hearing Geert tell it. But there must be some boards
>> that have an ISA bus?
>
> It did have an ISA bus, but no ISA slots.
> But the only external device on that bus was cs4232 audio.

Thanks, I'll take a look at that.

Cheers,

	Michael

> All other ISA devices were internal to the south bridge.
> http://g33rt.be/migrated/Linux/PPC/pci/isaAT1/.
>
> Gr{oetje,eeting}s,
>
>                         Geert
>

Re: Linux 6.4.4 on m68k - Q40 - pata_falcon causes oops at boot time

[Michael Schmitz]

Hi Finn,

Am 28.07.23 um 11:47 schrieb Finn Thain:
> On Thu, 27 Jul 2023, Michael Schmitz wrote:
>
>>>> And yes, I'm painfully aware the m68k low level IO code is becoming a 
>>>> bit of a maintainance legacy, in no small part due to my hacks around 
>>>> Atari EtherNEC.
>>>>
>>> I guess you and I both can share the blame for 44b1fbc0f5f30e66...
>>>
>>> Anyway, you make a good point about on-going maintenance. Do you think 
>>> that by supporting standard ISA drivers we might actually reduce the 
>>> ideosyncracies in m68k IO code?
>> You and DaveM ought to have a chat about that - abstracting the legacy 
>> drivers from the ISA constraints was his preferred option when I last 
>> attempted to get the Gayle network driver patches merged. When I say 
>> 'preferred', I'm probably understating a little.
>>
> A discussion with maintainers probably won't get far without working code 
> to look at. Perhaps William will send an RFC patch to illustrate his 
> approach.

Haven't seen anything yet, so I've just sent a patch switching
pata_falcon.c to use the IO resources instead of the memory resources.
Survived compile and ARAnyM boot tests only so far. I've checked and
confirmed the entire 0xffxxxxx range is mapped transparent in head.S for
Q40 so I don't see what else might be missing.

Please have a look and test if possible. Haven't yet bothered
linux-block or linux-ide... the patch still needs a Fixes: and other
trimmings so isn't ready for submission anyway.

>> I had toyed with that using the EtherNEC driver as test case but never 
>> got very far (this would have been splitting the driver into a core 
>> lib8390 module and a platform-specific module that allows to hook a 
>> variety of IO accessors as hooks, not static defines, and I wasn't too 
>> certain about performance impacts of such a change, the performance of 
>> the EtherNEC being so shitty it won't make any impact there),
>>
>> The only other option (that I can see) would be creating a bus driver 
>> for the ISA bus, with platforms allowed to register their particular IO 
>> accessors for IO and memory accesses - again, performance impacts to 
>> consider and getting test coverage on legacy ISA hardware a nightmare. 
>> This would allow to use legacy driver code more or less unchanged. 
>> Haven't given that much thought at all (the idea pretty much originated 
>> from this present mess, but that's all).
>>
>> There may be other approaches that can be considered, if none of this is 
>> what you had in mind.
>>
> What I had in mind is probably unacceptable because drivers end up having 
> to do byteswapping as happens in pata_falcon (or falconide and q40ide). 
> Perhaps your bus driver idea would probabably find more acceptance. OTOH 
> if the aim of the exercise is to use standard drivers (like pata_legacy) 
> there would probably be driver changes either way.

I discovered a problem with my bus driver idea - on Atari, ne.c and
pata_falcon.c must both use the same bus driver but with different
address translations and low level IO primitives. I'd need to switch
between either based on some quality specific to the driver use
(currently, that's the address range used - anything that looks like a
memory mapped IO range doesn't get address translation).

Unless that ugliness can somehow be avoided, I don't see the point of
replacing a kludge in io_mm.h by another equally ugly one in a bus
driver module.

Need to think about that some more.

Cheers,

    Michael

Re: Linux 6.4.4 on m68k - Q40 - pata_falcon causes oops at boot time

[Finn Thain]

Michael, William,

On Sun, 13 Aug 2023, Michael Schmitz wrote:

> Am 28.07.23 um 11:47 schrieb Finn Thain:
> > On Thu, 27 Jul 2023, Michael Schmitz wrote:
> >
> >>>> And yes, I'm painfully aware the m68k low level IO code is becoming 
> >>>> a bit of a maintainance legacy, in no small part due to my hacks 
> >>>> around Atari EtherNEC.
> >>>>
> >>> I guess you and I both can share the blame for 44b1fbc0f5f30e66...
> >>>
> >>> Anyway, you make a good point about on-going maintenance. Do you 
> >>> think that by supporting standard ISA drivers we might actually 
> >>> reduce the ideosyncracies in m68k IO code?
> >> You and DaveM ought to have a chat about that - abstracting the 
> >> legacy drivers from the ISA constraints was his preferred option when 
> >> I last attempted to get the Gayle network driver patches merged. When 
> >> I say 'preferred', I'm probably understating a little.
> >>
> > A discussion with maintainers probably won't get far without working 
> > code to look at. Perhaps William will send an RFC patch to illustrate 
> > his approach.
> 
> Haven't seen anything yet, so I've just sent a patch switching 
> pata_falcon.c to use the IO resources instead of the memory resources.

Thanks for sending that.

> Survived compile and ARAnyM boot tests only so far. I've checked and 
> confirmed the entire 0xffxxxxx range is mapped transparent in head.S for 
> Q40 so I don't see what else might be missing.
> 

In the message that Geert originally forwarded, William was quoted as 
saying it was necessary to "fix up the pata_falcon_data_xfer function". He 
also said that using the IO port resources "causes the ioread8/iowrite8 
functions to complain loudly". 
https://lore.kernel.org/linux-m68k/CAMuHMdUU62jjunJh9cqSqHT87B0H0A4udOOPs=WN7WZKpcagVA@mail.gmail.com/

I think your patch is taking the same approach and may run into the same 
issues... I guess we shall see when William tests it.

> Please have a look and test if possible. Haven't yet bothered 
> linux-block or linux-ide... the patch still needs a Fixes: and other 
> trimmings so isn't ready for submission anyway.
> 

Right. You'll want to run checkpatch.pl on it at some stage.

Re: Linux 6.4.4 on m68k - Q40 - pata_falcon causes oops at boot time

[Michael Schmitz]

Hi Finn,

On 13/08/23 19:38, Finn Thain wrote:
>
>> Haven't seen anything yet, so I've just sent a patch switching
>> pata_falcon.c to use the IO resources instead of the memory resources.
> Thanks for sending that.
>
>> Survived compile and ARAnyM boot tests only so far. I've checked and
>> confirmed the entire 0xffxxxxx range is mapped transparent in head.S for
>> Q40 so I don't see what else might be missing.
>>
> In the message that Geert originally forwarded, William was quoted as
> saying it was necessary to "fix up the pata_falcon_data_xfer function". He
> also said that using the IO port resources "causes the ioread8/iowrite8
> functions to complain loudly".
> https://lore.kernel.org/linux-m68k/CAMuHMdUU62jjunJh9cqSqHT87B0H0A4udOOPs=WN7WZKpcagVA@mail.gmail.com/
>
> I think your patch is taking the same approach and may run into the same
> issues... I guess we shall see when William tests it.

Not having seen William's patch, I can only speculate.

My patch differs from what William reported as changes, in that I'm not 
using ata_sff_std_ports(). I thought to have sidestepped the iomap issue 
that way, but perhaps not. I'll send a new version.

>
>> Please have a look and test if possible. Haven't yet bothered
>> linux-block or linux-ide... the patch still needs a Fixes: and other
>> trimmings so isn't ready for submission anyway.
>>
> Right. You'll want to run checkpatch.pl on it at some stage.

Sure.

Cheers,

     Michael

Re: Linux 6.4.4 on m68k - Q40 - pata_falcon causes oops at boot time

[William R Sowerbutts]

[-- Attachment #1: Type: text/plain, Size: 7566 bytes --]

Hello

Thank you for your interest and patience!

Sorry for the delay in providing more information.  The only method I had to 
transfer test kernels onto the Q40 was painfully slow and involved swapping 
ISA cards which is itself problematic as the pins in one of the ISA slots are 
breaking.

In the end I decided my best option was to dispose of the standard operating 
system (SMSQ/E) and write a new boot ROM for the machine with support for 
FAT32 filesystems on an IDE disk and TFTP transfers using an NE2000 card.
It's still in development but is now working well enough to use. The source 
code is at https://github.com/willsowerbutts/q40boot 

During the process I learned a bit more about the Q40 hardware, and 
transferring a kernel now takes 7 seconds instead of over 20 minutes.

I've run the various tests as requested;

* 5.13.19 -- IDE works (but the data on disk is byte-swapped, see below)

* 5.13.19+44b1fbc0f5f30e66a56d29575349f0b1ebe2b0ee -- IDE fails (crash)

* 5.14.21 -- IDE fails (crash)

* 6.4.10 + Michael's RFC patch -- IDE fails (no crash, but "Bad IO access")

* 6.4.10 + my patch -- IDE works, data on disk is NOT byte-swapped

Copies of the boot output for each kernel are attached to this email.

I've also attached the patch I am currently using on my Q40 kernel. It's 
based in part on Michael's patch. It bodges up "ioport_map" to apply the 
offset required to convert raw ISA address into "cookies" and thus allow the 
IDE to work without "Bad IO" complaints. To be crystal clear I am NOT 
proposing this as a solution, it's obviously a hack job, but I wanted to 
illustrate at least one way that *does* work on the Q40. 

I think one proper solution might involve enabling CONFIG_HAS_IOPORT_MAP but 
I've not yet looked properly into the implications of doing so. I'm very open 
to alternative solutions too.

As a side note, the NE2000 driver, which is also using 8- and 16-bit ISA I/O, 
works correctly with both 5.13 and 6.4. If one allows it to auto-probe the 
card's interrupt it locks up the machine due to limitations of the interrupt 
controller, but I understand this was always the case; I've made a tiny patch 
to ne.c to prevent it trying this.


On Tue, Jul 25, 2023 at 08:26:28AM +1200, Michael Schmitz wrote:
>Note that this also means that the address hardcoded for IDE may be 
>incorrect (AFAIR, IDE cards could have their IO base reassigned by 
>firmware).

The W83757 on my ISA IO card, and the W83787IF on the ISA IO card that 
shipped with the machine, are configurable only using jumpers. They can only 
use the two standard base addresses (0x1F0 or 0x170).


On Fri, Jul 28, 2023 at 9:52 AM Michael Schmitz <schmitzmic@gmail.com> wrote:
> Yes, but Q40 and Falcon are impossible to support any other way, and
> byte swapping the IDE interface in hardware was never repeated anywhere
> else, fortunately. We will have to keep pata_falcon around for that
> cause in any event.

I wonder if this is a misunderstanding about Q40 IDE.

The Q40 does not have an on-board IDE controller.  IDE is accessed via a 
common ISA PC Super-IO card.  When you do a 16-bit transfer from the ISA I/O 
address the data comes out backwards and the CPU needs to byteswap it.

I found it interesting and quite unexpected that 5.13 read data from the IDE 
drive byte-swapped.  I had prepared a drive for the machine with an MBR 
partition table and an ext4 filesystem but the kernel did not recognise 
either.  After a while I realised I had to byte swap the entire drive with 
'dd conv=swab', and then it worked.

For my 6.4 patch I enabled byte swapping in the pata_falcon_data_xfer() 
function -- this allows me to use an IDE drive with everything in the 
normal/compatible byte ordering, which makes life much easier. I assume this 
is the intended behaviour.

I wonder if any existing Q40 users are actually storing all the data on their 
drives byte-swapped just to avoid the overhead of byte-swapping on every
read/write. I suppose this would work just fine until you need to connect 
that drive to another machine.

For my Q40boot ROM I wrote an IDE driver. It just treats the IDE interface as 
a regular legacy PC style IDE interface (which is exactly what it is!) plus 
byte swapping of 16-bit transfers. See the functions q40_ide_read_sector_data 
and q40_ide_write_sector_data in the IDE driver (q40ide.c, q40isa.h in the 
q40boot github repository linked above).

I am going to look at the pata_legacy driver and see if it might be usable on 
the Q40 instead of pata_falcon.

As a long term fix I think I need to read up on CONFIG_HAS_IOPORT_MAP to try 
and understand how I might enable this.  I expect enabling it will have
implications for all M68K machines, so maybe someone with more experience 
should be making that decision.

I would be very happy to run further tests or to rewrite my hacky patch in 
response to pointers on how to improve it.

Thanks

Will



On Sun, Aug 13, 2023 at 05:38:00PM +1000, Finn Thain wrote:
>Michael, William,
>
>On Sun, 13 Aug 2023, Michael Schmitz wrote:
>
>> Am 28.07.23 um 11:47 schrieb Finn Thain:
>> > On Thu, 27 Jul 2023, Michael Schmitz wrote:
>> >
>> >>>> And yes, I'm painfully aware the m68k low level IO code is becoming 
>> >>>> a bit of a maintainance legacy, in no small part due to my hacks 
>> >>>> around Atari EtherNEC.
>> >>>>
>> >>> I guess you and I both can share the blame for 44b1fbc0f5f30e66...
>> >>>
>> >>> Anyway, you make a good point about on-going maintenance. Do you 
>> >>> think that by supporting standard ISA drivers we might actually 
>> >>> reduce the ideosyncracies in m68k IO code?
>> >> You and DaveM ought to have a chat about that - abstracting the 
>> >> legacy drivers from the ISA constraints was his preferred option when 
>> >> I last attempted to get the Gayle network driver patches merged. When 
>> >> I say 'preferred', I'm probably understating a little.
>> >>
>> > A discussion with maintainers probably won't get far without working 
>> > code to look at. Perhaps William will send an RFC patch to illustrate 
>> > his approach.
>> 
>> Haven't seen anything yet, so I've just sent a patch switching 
>> pata_falcon.c to use the IO resources instead of the memory resources.
>
>Thanks for sending that.
>
>> Survived compile and ARAnyM boot tests only so far. I've checked and 
>> confirmed the entire 0xffxxxxx range is mapped transparent in head.S for 
>> Q40 so I don't see what else might be missing.
>> 
>
>In the message that Geert originally forwarded, William was quoted as 
>saying it was necessary to "fix up the pata_falcon_data_xfer function". He 
>also said that using the IO port resources "causes the ioread8/iowrite8 
>functions to complain loudly". 
>https://lore.kernel.org/linux-m68k/CAMuHMdUU62jjunJh9cqSqHT87B0H0A4udOOPs=WN7WZKpcagVA@mail.gmail.com/
>
>I think your patch is taking the same approach and may run into the same 
>issues... I guess we shall see when William tests it.
>
>> Please have a look and test if possible. Haven't yet bothered 
>> linux-block or linux-ide... the patch still needs a Fixes: and other 
>> trimmings so isn't ready for submission anyway.
>> 
>
>Right. You'll want to run checkpatch.pl on it at some stage.

_________________________________________________________________________
William R Sowerbutts                                  will@sowerbutts.com
"Carpe post meridiem"                               http://sowerbutts.com
         main(){char*s=">#=0> ^#X@#@^7=",c=0,m;for(;c<15;c++)for
         (m=-1;m<7;putchar(m++/6&c%3/2?10:s[c]-31&1<<m?42:32));}  


[-- Attachment #2: linux-5.13.19 --]
[-- Type: text/plain, Size: 6861 bytes --]

1:/> vmlinux-5.13.19 console=ttyS0,115200n8 netdev=5,0x300,eth0
vmlinux-5.13.19: 6023848 bytes, ELF.
Loading 4279392 bytes from file offset 0x1000 to memory at 0x41000
Loading 106716 bytes from file offset 0x416000 to memory at 0x478000
Linux kernel detected: creating bootinfo at 0x493000
Entry at 0x42000 in supervisor mode
[    0.000000] Linux version 5.13.19-wrs (btg@carbon) (m68k-linux-gnu-gcc (Debian 12.2.0-13) 12.2.0, GNU ld (GNU Binutils for Debian) 2.40) #1 Sun Aug 13 21:47:28 BST 2023
[    0.000000] Zone ranges:
[    0.000000]   DMA      [mem 0x0000000000040000-0x0000001fffffffff]
[    0.000000]   Normal   empty
[    0.000000] Movable zone start for each node
[    0.000000] Early memory node ranges
[    0.000000]   node   0: [mem 0x0000000000040000-0x0000000001ffffff]
[    0.000000] Initmem setup node 0 [mem 0x0000000000040000-0x0000000001ffffff]
[    0.000000] Built 1 zonelists, mobility grouping on.  Total pages: 8056
[    0.000000] Kernel command line: console=ttyS0,115200n8 netdev=5,0x300,eth0
[    0.000000] Dentry cache hash table entries: 4096 (order: 2, 16384 bytes, linear)
[    0.000000] Inode-cache hash table entries: 2048 (order: 1, 8192 bytes, linear)
[    0.000000] Sorting __ex_table...
[    0.000000] mem auto-init: stack:off, heap alloc:off, heap free:off
[    0.000000] Memory: 27696K/32512K available (2996K kernel code, 449K rwdata, 860K rodata, 108K init, 133K bss, 4816K reserved, 0K cma-reserved)
[    0.000000] NR_IRQS: 43
[    0.010000] Console: colour dummy device 80x25
[    0.080000] printk: console [ttyS0] enabled
[    0.090000] Calibrating delay loop... 26.16 BogoMIPS (lpj=130816)
[    0.200000] pid_max: default: 32768 minimum: 301
[    0.210000] Mount-cache hash table entries: 1024 (order: 0, 4096 bytes, linear)
[    0.220000] Mountpoint-cache hash table entries: 1024 (order: 0, 4096 bytes, linear)
[    0.260000] devtmpfs: initialized
[    0.280000] random: get_random_u32 called from bucket_table_alloc.isra.0+0xe0/0xf8 with crng_init=0
[    0.290000] clocksource: jiffies: mask: 0xffffffff max_cycles: 0xffffffff, max_idle_ns: 19112604462750000 ns
[    0.300000] futex hash table entries: 256 (order: -1, 3072 bytes, linear)
[    0.310000] NET: Registered protocol family 16
[    0.320000] DMA: preallocated 128 KiB GFP_KERNEL pool for atomic allocations
[    0.330000] DMA: preallocated 128 KiB GFP_KERNEL|GFP_DMA pool for atomic allocations
[    0.480000] wait_for_initramfs() called before rootfs_initcalls
[    0.520000] SCSI subsystem initialized
[    0.780000] NET: Registered protocol family 2
[    0.790000] IP idents hash table entries: 2048 (order: 2, 16384 bytes, linear)
[    0.810000] tcp_listen_portaddr_hash hash table entries: 512 (order: 0, 4096 bytes, linear)
[    0.820000] TCP established hash table entries: 1024 (order: 0, 4096 bytes, linear)
[    0.820000] TCP bind hash table entries: 1024 (order: 0, 4096 bytes, linear)
[    0.830000] TCP: Hash tables configured (established 1024 bind 1024)
[    0.840000] UDP hash table entries: 256 (order: 0, 4096 bytes, linear)
[    0.840000] UDP-Lite hash table entries: 256 (order: 0, 4096 bytes, linear)
[    0.850000] NET: Registered protocol family 1
[    0.870000] workingset: timestamp_bits=30 max_order=13 bucket_order=0
[    0.910000] fb0: Q40 frame buffer alive and kicking !
[    0.920000] Serial: 8250/16550 driver, 8 ports, IRQ sharing disabled
[    0.930000] serial8250: ttyS0 at I/O 0x3f8 (irq = 4, base_baud = 115200) is a 16450
[    0.940000] serial8250: ttyS1 at I/O 0x2f8 (irq = 3, base_baud = 115200) is a 16450
[    1.120000] loop: module loaded
[    1.120000] Uniform Multi-Platform E-IDE driver
[    1.130000] ide: Q40 IDE controller
[    1.130000] legacy IDE will be removed in 2021, please switch to libata
[    1.130000] Report any missing HW support to linux-ide@vger.kernel.org
[    1.280000] random: fast init done
[    1.500000] hda: InnoDisk Corp. - iCF4000 2GB, CFA DISK drive
[    1.930000] hdb: SDCFHS-016G, CFA DISK drive
[    2.640000] ide0 at 0xff4007c0 on irq 14
[    2.650000] ide1 at 0xff4005c0 on irq 15
[    2.660000] ide-gd driver 1.18
[    2.670000] hda: max request size: 128KiB
[    2.670000] hda: 4095504 sectors (2096 MB) w/1KiB Cache, CHS=4063/16/63
[    2.720000] hda: cache flushes supported
[    2.760000] hdb: max request size: 1024KiB
[    2.770000] hdb: 31293360 sectors (16022 MB) w/1KiB Cache, CHS=31045/255/63
[    2.930000] ne ne.0 (unnamed net_device) (uninitialized): NE*000 ethercard probe at 0x300:
[    2.940000] 00:00:e8:cf:2e:39
[    2.960000] ne ne.0 eth0: RTL8019 found at 0x300, using IRQ 5.
[    2.980000] PPP generic driver version 2.4.2
[    2.990000] serio: Q40 kbd registered
[    3.010000] NET: Registered protocol family 10
[    3.030000] input: AT Raw Set 2 keyboard as /devices/platform/q40kbd/serio0/input/input0
[    3.050000] Segment Routing with IPv6
[    3.070000] VFS: Cannot open root device "(null)" or unknown-block(0,0): error -6
[    3.080000] Please append a correct "root=" boot option; here are the available partitions:
[    3.090000] 0300         2047752 hda 
[    3.090000]  driver: ide-gd
[    3.100000] 0340        15646680 hdb 
[    3.100000]  driver: ide-gd
[    3.110000] Kernel panic - not syncing: VFS: Unable to mount root fs on unknown-block(0,0)
[    3.110000] CPU: 0 PID: 1 Comm: swapper Not tainted 5.13.19-wrs #1
[    3.110000] Stack from 007d9f0c:
[    3.110000]         007d9f0c 00375e52 00375e52 002e60aa 00000000 00008001 004731ac 002e66d6
[    3.110000]         fffffffa 00993000 007d9f78 00439768 0036c5a6 007d9f78 0036c555 0036c522
[    3.110000]         00000000 007d9f78 fffffffa 00000000 0000000c 0001f9c4 00009248 002e8f10
[    3.110000]         00000000 00000000 00000000 756e6b6e 6f776e2d 626c6f63 6b28302c 302900c0
[    3.110000]         00bc8280 004397fc 0036c60a 00439826 0036c60a 00008001 00000000 0044e028
[    3.110000]         0043999a 002e8f10 00000000 00000000 002e8f18 002e8f10 0000289c 00000000
[    3.110000] Call Trace: [<002e60aa>] panic+0xc2/0x250
[    3.110000]  [<00008001>] t_avoid_unsupp+0x17/0x46
[    3.110000]  [<002e66d6>] printk+0x0/0x18
[    3.110000]  [<00439768>] mount_block_root+0x224/0x278
[    3.110000]  [<0001f9c4>] prctl_set_mm+0x1ea/0x490
[    3.110000]  [<00009248>] dp+0x8/0x2c
[    3.110000]  [<002e8f10>] kernel_init+0x0/0xd8
[    3.110000]  [<004397fc>] mount_root+0x40/0x72
[    3.110000]  [<00439826>] mount_root+0x6a/0x72
[    3.110000]  [<00008001>] t_avoid_unsupp+0x17/0x46
[    3.110000]  [<0043999a>] prepare_namespace+0x16c/0x17a
[    3.110000]  [<002e8f10>] kernel_init+0x0/0xd8
[    3.110000]  [<002e8f18>] kernel_init+0x8/0xd8
[    3.110000]  [<002e8f10>] kernel_init+0x0/0xd8
[    3.110000]  [<0000289c>] ret_from_kernel_thread+0xc/0x14
[    3.110000] 
[    3.110000] ---[ end Kernel panic - not syncing: VFS: Unable to mount root fs on unknown-block(0,0) ]---

[-- Attachment #3: linux-5.13.19+44b1f --]
[-- Type: text/plain, Size: 8375 bytes --]

1:/> vmlinux-5.13.19-44b1f console=ttyS0,115200n8 netdev=5,0x300,eth0
vmlinux-5.13.19-44b1f: 6025404 bytes, ELF.
Loading 4280032 bytes from file offset 0x1000 to memory at 0x41000
Loading 107708 bytes from file offset 0x416000 to memory at 0x478000
Linux kernel detected: creating bootinfo at 0x493000
Entry at 0x42000 in supervisor mode
[    0.000000] Linux version 5.13.19-wrs (btg@carbon) (m68k-linux-gnu-gcc (Debian 12.2.0-13) 12.2.0, GNU ld (GNU Binutils for Debian) 2.40) #2 Sun Aug 13 21:52:42 BST 2023
[    0.000000] Zone ranges:
[    0.000000]   DMA      [mem 0x0000000000040000-0x0000001fffffffff]
[    0.000000]   Normal   empty
[    0.000000] Movable zone start for each node
[    0.000000] Early memory node ranges
[    0.000000]   node   0: [mem 0x0000000000040000-0x0000000001ffffff]
[    0.000000] Initmem setup node 0 [mem 0x0000000000040000-0x0000000001ffffff]
[    0.000000] Built 1 zonelists, mobility grouping on.  Total pages: 8056
[    0.000000] Kernel command line: console=ttyS0,115200n8 netdev=5,0x300,eth0
[    0.000000] Dentry cache hash table entries: 4096 (order: 2, 16384 bytes, linear)
[    0.000000] Inode-cache hash table entries: 2048 (order: 1, 8192 bytes, linear)
[    0.000000] Sorting __ex_table...
[    0.000000] mem auto-init: stack:off, heap alloc:off, heap free:off
[    0.000000] Memory: 27696K/32512K available (2996K kernel code, 448K rwdata, 860K rodata, 108K init, 132K bss, 4816K reserved, 0K cma-reserved)
[    0.000000] NR_IRQS: 43
[    0.010000] Console: colour dummy device 80x25
[    0.090000] printk: console [ttyS0] enabled
[    0.090000] Calibrating delay loop... 26.16 BogoMIPS (lpj=130816)
[    0.200000] pid_max: default: 32768 minimum: 301
[    0.210000] Mount-cache hash table entries: 1024 (order: 0, 4096 bytes, linear)
[    0.220000] Mountpoint-cache hash table entries: 1024 (order: 0, 4096 bytes, linear)
[    0.260000] devtmpfs: initialized
[    0.280000] random: get_random_u32 called from bucket_table_alloc.isra.0+0xe0/0xf8 with crng_init=0
[    0.290000] clocksource: jiffies: mask: 0xffffffff max_cycles: 0xffffffff, max_idle_ns: 19112604462750000 ns
[    0.300000] futex hash table entries: 256 (order: -1, 3072 bytes, linear)
[    0.310000] NET: Registered protocol family 16
[    0.320000] DMA: preallocated 128 KiB GFP_KERNEL pool for atomic allocations
[    0.320000] DMA: preallocated 128 KiB GFP_KERNEL|GFP_DMA pool for atomic allocations
[    0.480000] wait_for_initramfs() called before rootfs_initcalls
[    0.520000] SCSI subsystem initialized
[    0.780000] NET: Registered protocol family 2
[    0.790000] IP idents hash table entries: 2048 (order: 2, 16384 bytes, linear)
[    0.810000] tcp_listen_portaddr_hash hash table entries: 512 (order: 0, 4096 bytes, linear)
[    0.810000] TCP established hash table entries: 1024 (order: 0, 4096 bytes, linear)
[    0.820000] TCP bind hash table entries: 1024 (order: 0, 4096 bytes, linear)
[    0.820000] TCP: Hash tables configured (established 1024 bind 1024)
[    0.830000] UDP hash table entries: 256 (order: 0, 4096 bytes, linear)
[    0.840000] UDP-Lite hash table entries: 256 (order: 0, 4096 bytes, linear)
[    0.840000] NET: Registered protocol family 1
[    0.870000] workingset: timestamp_bits=30 max_order=13 bucket_order=0
[    0.900000] fb0: Q40 frame buffer alive and kicking !
[    0.910000] Serial: 8250/16550 driver, 8 ports, IRQ sharing disabled
[    0.920000] serial8250: ttyS0 at I/O 0x3f8 (irq = 4, base_baud = 115200) is a 16450
[    0.930000] serial8250: ttyS1 at I/O 0x2f8 (irq = 3, base_baud = 115200) is a 16450
[    1.110000] loop: module loaded
[    1.110000] Uniform Multi-Platform E-IDE driver
[    1.120000] atari-falcon-ide atari-falcon-ide.0: Atari Falcon and Q40/Q60 IDE controller
[    1.120000] atari-falcon-ide atari-falcon-ide.0: resources busy
[    1.130000] atari-falcon-ide: probe of atari-falcon-ide.0 failed with error -16
[    1.140000] atari-falcon-ide atari-falcon-ide.1: Atari Falcon and Q40/Q60 IDE controller
[    1.140000] atari-falcon-ide atari-falcon-ide.1: resources busy
[    1.150000] atari-falcon-ide: probe of atari-falcon-ide.1 failed with error -16
[    1.150000] ide-gd driver 1.18
[    1.160000] atari-falcon-ide atari-falcon-ide.0: Atari Falcon and Q40/Q60 PATA controller
[    1.170000] Unable to handle kernel access at virtual address (ptrval)
[    1.170000] Oops: 00000000
[    1.170000] Modules linked in:
[    1.170000] PC: [<00195c0e>] iowrite8+0x1c/0x46
[    1.170000] SR: 2710  SP: (ptrval)  a2: 007d7aa0
[    1.170000] d0: fc803f65    d1: 0000000a    d2: 00002000    d3: 00000000
[    1.170000] d4: 00000000    d5: 002030ca    a0: fc803f65    a1: 008dc000
[    1.170000] Process swapper (pid: 1, task=(ptrval))
[    1.170000] Frame format=7 eff addr=007d9df4 ssw=04a5 faddr=fc803f65
[    1.170000] wb 1 stat/addr/data: 0005 ff400fd8 09ffffff
[    1.170000] wb 2 stat/addr/data: 00a5 fc803f65 0000000a
[    1.170000] wb 3 stat/addr/data: 0025 fc803f65 0000000a
[    1.170000] push data: 09ffffff 2010ffff 00000050 007fa700
[    1.170000] Stack from 007d9dac:
[    1.170000]         00202364 0000000a ff400fd9 008dc000 001fd94e 008dc000 0093fec0 001fdd4a
[    1.170000]         008dc000 00000001 001f5e94 008dc000 001d56e6 0000000e 0040ecb8 0093fec0
[    1.170000]         001fd8ac 00807000 0093fec0 001f60b0 0093fec0 001d56e6 007fa700 00000000
[    1.170000]         000275d6 00002098 008dc000 001fd8ac 00807000 00446e44 0093fec0 0000000e
[    1.170000]         002030ca 00000080 0040ecb8 00000000 00000000 0080700a 0040eb84 00431ad0
[    1.170000]         007d9f8c 001d5c98 00807000 0080700a 0040eb84 001d4666 0080700a 00000000
[    1.170000] Call Trace: [<00202364>] ata_sff_freeze+0x34/0x5c
[    1.170000]  [<001fd94e>] __ata_port_freeze+0x3a/0x46
[    1.170000]  [<001fdd4a>] ata_eh_freeze_port+0x1c/0x24
[    1.170000]  [<001f5e94>] ata_host_start+0x10c/0x12a
[    1.170000]  [<001d56e6>] platform_get_resource+0x0/0x48
[    1.170000]  [<001fd8ac>] ata_port_desc+0x0/0x68
[    1.170000]  [<001f60b0>] ata_host_activate+0x20/0xf8
[    1.170000]  [<001d56e6>] platform_get_resource+0x0/0x48
[    1.170000]  [<000275d6>] parse_args+0x0/0x264
[    1.170000]  [<00002098>] do_one_initcall+0x0/0x150
[    1.170000]  [<001fd8ac>] ata_port_desc+0x0/0x68
[    1.170000]  [<00446e44>] pata_falcon_init_one+0x1f8/0x206
[    1.170000]  [<002030ca>] ata_sff_interrupt+0x0/0x144
[    1.170000]  [<001d5c98>] platform_probe+0x22/0x4e
[    1.170000]  [<001d4666>] really_probe+0x1b2/0x2b4
[    1.170000]  [<001a673e>] strcpy+0x0/0x1c
[    1.170000]  [<001d49d8>] device_driver_attach+0x2e/0x4a
[    1.170000]  [<001d4a98>] __driver_attach+0xa4/0xa8
[    1.170000]  [<001d2d28>] next_device+0x0/0x18
[    1.170000]  [<001d2d9a>] bus_for_each_dev+0x5a/0x78
[    1.170000]  [<001d4022>] driver_attach+0x16/0x1c
[    1.170000]  [<001d49f4>] __driver_attach+0x0/0xa8
[    1.170000]  [<001d3c76>] bus_add_driver+0x15e/0x188
[    1.170000]  [<001d4f7e>] driver_register+0x94/0xcc
[    1.170000]  [<001d5b6e>] __platform_driver_probe+0x62/0x8e
[    1.170000]  [<00446c34>] pata_falcon_driver_init+0x0/0x18
[    1.170000]  [<00446c46>] pata_falcon_driver_init+0x12/0x18
[    1.170000]  [<00446c4c>] pata_falcon_init_one+0x0/0x206
[    1.170000]  [<000020f2>] do_one_initcall+0x5a/0x150
[    1.170000]  [<001a673e>] strcpy+0x0/0x1c
[    1.170000]  [<000275d6>] parse_args+0x0/0x264
[    1.170000]  [<00002098>] do_one_initcall+0x0/0x150
[    1.170000]  [<00060006>] do_misc_fixups+0x24/0x5f8
[    1.170000]  [<00439416>] kernel_init_freeable+0x154/0x1ac
[    1.170000]  [<00439464>] kernel_init_freeable+0x1a2/0x1ac
[    1.170000]  [<00446c34>] pata_falcon_driver_init+0x0/0x18
[    1.170000]  [<0001f9c4>] prctl_set_mm+0x1ea/0x490
[    1.170000]  [<00009248>] dp+0x8/0x2c
[    1.170000]  [<002e91d8>] kernel_init+0x0/0xd8
[    1.170000]  [<002e91e0>] kernel_init+0x8/0xd8
[    1.170000]  [<002e91d8>] kernel_init+0x0/0xd8
[    1.170000]  [<0000289c>] ret_from_kernel_thread+0xc/0x14
[    1.170000] 
[    1.170000] Code: 0000 650e e588 0680 ff80 0001 2040 1081 <4e75> 0c80 0001 0000 6310 0280 0000 ffff e588 0680 ff40 0001 60e2 2f7c 0038 b5fb
[    1.170000] Disabling lock debugging due to kernel taint
[    1.170000] Kernel panic - not syncing: Attempted to kill init! exitcode=0x0000000b
[    1.170000] ---[ end Kernel panic - not syncing: Attempted to kill init! exitcode=0x0000000b ]---


[-- Attachment #4: linux-5.14.21 --]
[-- Type: text/plain, Size: 7714 bytes --]

1:/> vmlinux-5.14.21 console=ttyS0,115200n8 netdev=5,0x300,eth0
vmlinux-5.14.21: 5979196 bytes, ELF.
Loading 4247168 bytes from file offset 0x1000 to memory at 0x41000
Loading 107324 bytes from file offset 0x40E000 to memory at 0x470000
Linux kernel detected: creating bootinfo at 0x48B000
Entry at 0x42000 in supervisor mode
[    0.000000] Linux version 5.14.21-wrs (btg@carbon) (m68k-linux-gnu-gcc (Debian 12.2.0-13) 12.2.0, GNU ld (GNU Binutils for Debian) 2.40) #1 Sun Aug 13 21:54:11 BST 2023
[    0.000000] Zone ranges:
[    0.000000]   DMA      [mem 0x0000000000040000-0x0000001fffffffff]
[    0.000000]   Normal   empty
[    0.000000] Movable zone start for each node
[    0.000000] Early memory node ranges
[    0.000000]   node   0: [mem 0x0000000000040000-0x0000000001ffffff]
[    0.000000] Initmem setup node 0 [mem 0x0000000000040000-0x0000000001ffffff]
[    0.000000] Built 1 zonelists, mobility grouping on.  Total pages: 8056
[    0.000000] Kernel command line: console=ttyS0,115200n8 netdev=5,0x300,eth0
[    0.000000] Dentry cache hash table entries: 4096 (order: 2, 16384 bytes, linear)
[    0.000000] Inode-cache hash table entries: 2048 (order: 1, 8192 bytes, linear)
[    0.000000] Sorting __ex_table...
[    0.000000] mem auto-init: stack:off, heap alloc:off, heap free:off
[    0.000000] Memory: 27728K/32512K available (2972K kernel code, 449K rwdata, 852K rodata, 108K init, 133K bss, 4784K reserved, 0K cma-reserved)
[    0.000000] NR_IRQS: 43
[    0.010000] Console: colour dummy device 80x25
[    0.090000] printk: console [ttyS0] enabled
[    0.090000] Calibrating delay loop... 26.16 BogoMIPS (lpj=130816)
[    0.200000] pid_max: default: 32768 minimum: 301
[    0.210000] Mount-cache hash table entries: 1024 (order: 0, 4096 bytes, linear)
[    0.220000] Mountpoint-cache hash table entries: 1024 (order: 0, 4096 bytes, linear)
[    0.260000] devtmpfs: initialized
[    0.280000] random: get_random_u32 called from bucket_table_alloc.isra.0+0xe0/0xf8 with crng_init=0
[    0.290000] clocksource: jiffies: mask: 0xffffffff max_cycles: 0xffffffff, max_idle_ns: 19112604462750000 ns
[    0.300000] futex hash table entries: 256 (order: -1, 3072 bytes, linear)
[    0.310000] NET: Registered PF_NETLINK/PF_ROUTE protocol family
[    0.310000] DMA: preallocated 128 KiB GFP_KERNEL pool for atomic allocations
[    0.320000] DMA: preallocated 128 KiB GFP_KERNEL|GFP_DMA pool for atomic allocations
[    0.490000] SCSI subsystem initialized
[    0.750000] NET: Registered PF_INET protocol family
[    0.760000] IP idents hash table entries: 2048 (order: 2, 16384 bytes, linear)
[    0.780000] tcp_listen_portaddr_hash hash table entries: 512 (order: 0, 4096 bytes, linear)
[    0.780000] TCP established hash table entries: 1024 (order: 0, 4096 bytes, linear)
[    0.790000] TCP bind hash table entries: 1024 (order: 0, 4096 bytes, linear)
[    0.790000] TCP: Hash tables configured (established 1024 bind 1024)
[    0.800000] UDP hash table entries: 256 (order: 0, 4096 bytes, linear)
[    0.800000] UDP-Lite hash table entries: 256 (order: 0, 4096 bytes, linear)
[    0.810000] NET: Registered PF_UNIX/PF_LOCAL protocol family
[    0.840000] workingset: timestamp_bits=30 max_order=13 bucket_order=0
[    0.870000] fb0: Q40 frame buffer alive and kicking !
[    0.880000] Serial: 8250/16550 driver, 8 ports, IRQ sharing disabled
[    0.890000] serial8250: ttyS0 at I/O 0x3f8 (irq = 4, base_baud = 115200) is a 16450
[    0.900000] serial8250: ttyS1 at I/O 0x2f8 (irq = 3, base_baud = 115200) is a 16450
[    1.070000] loop: module loaded
[    1.080000] atari-falcon-ide atari-falcon-ide.0: Atari Falcon and Q40/Q60 PATA controller
[    1.090000] Unable to handle kernel access at virtual address (ptrval)
[    1.090000] Oops: 00000000
[    1.090000] Modules linked in:
[    1.090000] PC: [<00196bf6>] iowrite8+0x1c/0x46
[    1.090000] SR: 2710  SP: (ptrval)  a2: 007d7aa0
[    1.090000] d0: fc803f65    d1: 0000000a    d2: 00002000    d3: 00000000
[    1.090000] d4: 00000000    d5: 001fbf80    a0: fc803f65    a1: 008d8000
[    1.090000] Process swapper (pid: 1, task=(ptrval))
[    1.090000] Frame format=7 eff addr=007d9de8 ssw=04a5 faddr=fc803f65
[    1.090000] wb 1 stat/addr/data: 0005 ff400fd8 09ffffff
[    1.090000] wb 2 stat/addr/data: 00a5 fc803f65 0000000a
[    1.090000] wb 3 stat/addr/data: 0025 fc803f65 0000000a
[    1.090000] push data: 09ffffff 2010ffff 00000050 007fa700
[    1.090000] Stack from 007d9da0:
[    1.090000]         001fb246 0000000a ff400fd9 008d8000 001f685e 008d8000 008ecf00 001f6c5a
[    1.090000]         008d8000 00000001 001eea6c 008d8000 001d5cf2 0000000e 00406afc 008ecf00
[    1.090000]         001f67bc 00807000 008ecf00 001ef00c 008ecf00 001d5cf2 007fa700 00000000
[    1.090000]         000275ce 00002098 008d8000 001f67bc 00807000 0043ec4c 008ecf00 0000000e
[    1.090000]         001fbf80 00000080 00406afc 00000000 0080700a 0080700a 004069c8 004055e8
[    1.090000]         007d9f88 001d6350 00807000 0080700a 004069c8 001d4bc2 0080700a 00000000
[    1.090000] Call Trace: [<001fb246>] ata_sff_freeze+0x34/0x5c
[    1.090000]  [<001f685e>] __ata_port_freeze+0x3a/0x46
[    1.090000]  [<001f6c5a>] ata_eh_freeze_port+0x1c/0x24
[    1.090000]  [<001eea6c>] ata_host_start+0x112/0x130
[    1.090000]  [<001d5cf2>] platform_get_resource+0x0/0x48
[    1.090000]  [<001f67bc>] ata_port_desc+0x0/0x68
[    1.090000]  [<001ef00c>] ata_host_activate+0x20/0xf8
[    1.090000]  [<001d5cf2>] platform_get_resource+0x0/0x48
[    1.090000]  [<000275ce>] parse_args+0x0/0x264
[    1.090000]  [<00002098>] do_one_initcall+0x0/0x150
[    1.090000]  [<001f67bc>] ata_port_desc+0x0/0x68
[    1.090000]  [<0043ec4c>] pata_falcon_init_one+0x1f8/0x206
[    1.090000]  [<001fbf80>] ata_sff_interrupt+0x0/0x144
[    1.090000]  [<001d6350>] platform_probe+0x22/0x4e
[    1.090000]  [<001d4bc2>] really_probe+0x12a/0x248
[    1.090000]  [<001d4d6c>] driver_probe_device+0x20/0x76
[    1.090000]  [<001a6d7e>] strcpy+0x0/0x1c
[    1.090000]  [<001d5088>] __driver_attach+0xac/0xbc
[    1.090000]  [<001d3318>] next_device+0x0/0x18
[    1.090000]  [<001d338a>] bus_for_each_dev+0x5a/0x78
[    1.090000]  [<001d4606>] driver_attach+0x16/0x1c
[    1.090000]  [<001d4fdc>] __driver_attach+0x0/0xbc
[    1.090000]  [<001d425a>] bus_add_driver+0x15e/0x188
[    1.090000]  [<001d558a>] driver_register+0x94/0xcc
[    1.090000]  [<001d6226>] __platform_driver_probe+0x62/0x8e
[    1.090000]  [<0043ea3c>] pata_falcon_driver_init+0x0/0x18
[    1.090000]  [<0043ea4e>] pata_falcon_driver_init+0x12/0x18
[    1.090000]  [<0043ea54>] pata_falcon_init_one+0x0/0x206
[    1.090000]  [<000020f2>] do_one_initcall+0x5a/0x150
[    1.090000]  [<001a6d7e>] strcpy+0x0/0x1c
[    1.090000]  [<000275ce>] parse_args+0x0/0x264
[    1.090000]  [<00002098>] do_one_initcall+0x0/0x150
[    1.090000]  [<00060006>] check_cond_jmp_op+0x954/0xa88
[    1.090000]  [<00431510>] kernel_init_freeable+0x13c/0x194
[    1.090000]  [<0043155e>] kernel_init_freeable+0x18a/0x194
[    1.090000]  [<0043ea3c>] pata_falcon_driver_init+0x0/0x18
[    1.090000]  [<00009248>] dp+0xc/0x2c
[    1.090000]  [<002e30b6>] kernel_init+0x0/0xe4
[    1.090000]  [<002e30ca>] kernel_init+0x14/0xe4
[    1.090000]  [<002e30b6>] kernel_init+0x0/0xe4
[    1.090000]  [<00002880>] ret_from_kernel_thread+0xc/0x14
[    1.090000] 
[    1.090000] Code: 0000 650e e588 0680 ff80 0001 2040 1081 <4e75> 0c80 0001 0000 6310 0280 0000 ffff e588 0680 ff40 0001 60e2 2f7c 0038 38c8
[    1.090000] Disabling lock debugging due to kernel taint
[    1.090000] Kernel panic - not syncing: Attempted to kill init! exitcode=0x0000000b
[    1.090000] ---[ end Kernel panic - not syncing: Attempted to kill init! exitcode=0x0000000b ]---

[-- Attachment #5: linux-6.4.10+michael-rfc --]
[-- Type: text/plain, Size: 48365 bytes --]

1:/> vmlinux-6.4.10+rfc console=ttyS0,115200n8 netdev=5,0x300,eth0
vmlinux-6.4.10+rfc: 6482976 bytes, ELF.
Loading 4637888 bytes from file offset 0x1000 to memory at 0x41000
Loading 120996 bytes from file offset 0x46E000 to memory at 0x4CE000
Linux kernel detected: creating bootinfo at 0x4EC000
Entry at 0x42000 in supervisor mode
[    0.000000] Linux version 6.4.10-wrs (btg@carbon) (m68k-linux-gnu-gcc (Debian 12.2.0-13) 12.2.0, GNU ld (GNU Binutils for Debian) 2.40) #1 Sun Aug 13 22:05:38 BST 2023
[    0.000000] Zone ranges:
[    0.000000]   DMA      [mem 0x0000000000040000-0x0000001fffffffff]
[    0.000000]   Normal   empty
[    0.000000] Movable zone start for each node
[    0.000000] Early memory node ranges
[    0.000000]   node   0: [mem 0x0000000000040000-0x0000000001ffffff]
[    0.000000] Initmem setup node 0 [mem 0x0000000000040000-0x0000000001ffffff]
[    0.000000] Kernel command line: console=ttyS0,115200n8 netdev=5,0x300,eth0
[    0.000000] Dentry cache hash table entries: 4096 (order: 2, 16384 bytes, linear)
[    0.000000] Inode-cache hash table entries: 2048 (order: 1, 8192 bytes, linear)
[    0.000000] Sorting __ex_table...
[    0.000000] Built 1 zonelists, mobility grouping on.  Total pages: 8056
[    0.000000] mem auto-init: stack:off, heap alloc:off, heap free:off
[    0.000000] Memory: 27340K/32512K available (3220K kernel code, 442K rwdata, 988K rodata, 120K init, 129K bss, 5172K reserved, 0K cma-reserved)
[    0.000000] NR_IRQS: 43
[    0.010000] Console: colour dummy device 80x25
[    0.010000] printk: console [ttyS0] enabled
[    0.090000] Calibrating delay loop... 26.16 BogoMIPS (lpj=130816)
[    0.200000] pid_max: default: 32768 minimum: 301
[    0.210000] Mount-cache hash table entries: 1024 (order: 0, 4096 bytes, linear)
[    0.220000] Mountpoint-cache hash table entries: 1024 (order: 0, 4096 bytes, linear)
[    0.260000] cblist_init_generic: Setting adjustable number of callback queues.
[    0.260000] cblist_init_generic: Setting shift to 0 and lim to 1.
[    0.280000] devtmpfs: initialized
[    0.310000] clocksource: jiffies: mask: 0xffffffff max_cycles: 0xffffffff, max_idle_ns: 19112604462750000 ns
[    0.310000] futex hash table entries: 256 (order: -1, 3072 bytes, linear)
[    0.350000] NET: Registered PF_NETLINK/PF_ROUTE protocol family
[    0.360000] DMA: preallocated 128 KiB GFP_KERNEL pool for atomic allocations
[    0.370000] DMA: preallocated 128 KiB GFP_KERNEL|GFP_DMA pool for atomic allocations
[    0.430000] SCSI subsystem initialized
[    0.790000] NET: Registered PF_INET protocol family
[    0.800000] IP idents hash table entries: 2048 (order: 2, 16384 bytes, linear)
[    0.830000] tcp_listen_portaddr_hash hash table entries: 1024 (order: 0, 4096 bytes, linear)
[    0.840000] Table-perturb hash table entries: 65536 (order: 6, 262144 bytes, linear)
[    0.840000] TCP established hash table entries: 1024 (order: 0, 4096 bytes, linear)
[    0.850000] TCP bind hash table entries: 1024 (order: 1, 8192 bytes, linear)
[    0.860000] TCP: Hash tables configured (established 1024 bind 1024)
[    0.860000] UDP hash table entries: 256 (order: 0, 4096 bytes, linear)
[    0.870000] UDP-Lite hash table entries: 256 (order: 0, 4096 bytes, linear)
[    0.880000] NET: Registered PF_UNIX/PF_LOCAL protocol family
[    0.910000] workingset: timestamp_bits=30 max_order=13 bucket_order=0
[    1.310000] fb0: Q40 frame buffer alive and kicking !
[    1.320000] Serial: 8250/16550 driver, 8 ports, IRQ sharing disabled
[    1.330000] serial8250: ttyS0 at I/O 0x3f8 (irq = 4, base_baud = 115200) is a 16450
[    1.340000] serial8250: ttyS1 at I/O 0x2f8 (irq = 3, base_baud = 115200) is a 16450
[    1.560000] loop: module loaded
[    1.570000] atari-falcon-ide atari-falcon-ide.0: Atari Falcon and Q40/Q60 PATA controller
[    1.570000] ------------[ cut here ]------------
[    1.570000] WARNING: CPU: 0 PID: 1 at lib/iomap.c:45 bad_io_access+0x32/0x38
[    1.570000] Bad IO access at port 0x3f6 (outb(val,port))
[    1.570000] Modules linked in:
[    1.570000] CPU: 0 PID: 1 Comm: swapper Not tainted 6.4.10-wrs #1
[    1.570000] Stack from 007d7cf8:
[    1.570000]         007d7cf8 003ca39a 003ca39a 00000000 00000009 00320c7a 003ca39a 0031c0de
[    1.570000]         003be068 003e12e8 0000002d 00914000 00914000 0031c16c 003e12e8 0000002d
[    1.570000]         001bb44e 00000009 00000000 007d7d58 00002000 00000000 00000000 00211826
[    1.570000]         003e12c5 007d7d78 0020c374 001bb44e 003e12e8 0000002d 00000009 003e12c5
[    1.570000]         000003f6 003e1330 002100fc 000003f6 003e1330 00210126 00914000 0000000a
[    1.570000]         00914000 0020bf8a 00914000 00964b80 0020c390 00914000 00000001 00203e80
[    1.570000] Call Trace: [<00320c7a>] dump_stack+0xc/0x10
[    1.570000]  [<0031c0de>] __warn+0x70/0xbc
[    1.570000]  [<0031c16c>] warn_slowpath_fmt+0x42/0x62
[    1.570000]  [<001bb44e>] bad_io_access+0x32/0x38
[    1.570000]  [<00002000>] _start+0x0/0x8
[    1.570000]  [<00211826>] ata_sff_interrupt+0x0/0x144
[    1.570000]  [<0020c374>] ata_eh_freeze_port+0x0/0x24
[    1.570000]  [<001bb44e>] bad_io_access+0x32/0x38
[    1.570000]  [<002100fc>] ata_sff_set_devctl+0x3c/0x42
[    1.570000]  [<00210126>] ata_sff_freeze+0x24/0x4c
[    1.570000]  [<0020bf8a>] __ata_port_freeze+0x3a/0x46
[    1.570000]  [<0020c390>] ata_eh_freeze_port+0x1c/0x24
[    1.570000]  [<00203e80>] ata_host_start+0x112/0x130
[    1.570000]  [<0020bee8>] ata_port_desc+0x0/0x68
[    1.570000]  [<0020451e>] ata_host_activate+0x20/0xf8
[    1.570000]  [<001ea47c>] platform_get_resource+0x0/0x48
[    1.570000]  [<00002080>] do_one_initcall+0x0/0x184
[    1.570000]  [<0020bee8>] ata_port_desc+0x0/0x68
[    1.570000]  [<0049d35a>] pata_falcon_init_one+0x1e6/0x1f4
[    1.570000]  [<00211826>] ata_sff_interrupt+0x0/0x144
[    1.570000]  [<00306fa0>] klist_next+0x0/0x80
[    1.570000]  [<001eaa26>] platform_probe+0x22/0x4e
[    1.570000]  [<001e920a>] really_probe+0xfa/0x200
[    1.570000]  [<001e9402>] driver_probe_device+0x20/0x78
[    1.570000]  [<003150ee>] strcpy+0x0/0x1c
[    1.570000]  [<001e959e>] __driver_attach+0xbe/0xce
[    1.570000]  [<00306fa0>] klist_next+0x0/0x80
[    1.570000]  [<001e79cc>] bus_for_each_dev+0x62/0x86
[    1.570000]  [<001e8c18>] driver_attach+0x16/0x1c
[    1.570000]  [<001e94e0>] __driver_attach+0x0/0xce
[    1.570000]  [<001e8688>] bus_add_driver+0x96/0x18c
[    1.570000]  [<001e9c3e>] driver_register+0x9c/0xda
[    1.570000]  [<001ea9ce>] __platform_driver_probe+0x64/0x9a
[    1.570000]  [<0049d15c>] pata_falcon_driver_init+0x0/0x18
[    1.570000]  [<0049d16e>] pata_falcon_driver_init+0x12/0x18
[    1.570000]  [<0049d174>] pata_falcon_init_one+0x0/0x1f4
[    1.570000]  [<000020da>] do_one_initcall+0x5a/0x184
[    1.570000]  [<003150ee>] strcpy+0x0/0x1c
[    1.570000]  [<00028374>] parse_args+0x0/0x25e
[    1.570000]  [<00002080>] do_one_initcall+0x0/0x184
[    1.570000]  [<00060006>] check_max_stack_depth_subprog+0x16e/0x220
[    1.570000]  [<0048f4b2>] kernel_init_freeable+0x132/0x18a
[    1.570000]  [<0048f500>] kernel_init_freeable+0x180/0x18a
[    1.570000]  [<0049d15c>] pata_falcon_driver_init+0x0/0x18
[    1.570000]  [<000286c8>] list_del_init+0x0/0x1c
[    1.570000]  [<00015cbc>] kernel_thread+0x0/0x68
[    1.570000]  [<00320df4>] kernel_init+0x0/0xec
[    1.570000]  [<00320e08>] kernel_init+0x14/0xec
[    1.570000]  [<00320df4>] kernel_init+0x0/0xec
[    1.570000]  [<00002898>] ret_from_kernel_thread+0xc/0x14
[    1.570000] 
[    1.570000] ---[ end trace 0000000000000000 ]---
[    1.570000] ------------[ cut here ]------------
[    1.570000] WARNING: CPU: 0 PID: 1 at lib/iomap.c:45 bad_io_access+0x32/0x38
[    1.570000] Bad IO access at port 0x1f7 (return inb(port))
[    1.570000] Modules linked in:
[    1.570000] CPU: 0 PID: 1 Comm: swapper Tainted: G        W          6.4.10-wrs #1
[    1.570000] Stack from 007d7cec:
[    1.570000]         007d7cec 003ca39a 003ca39a 00000000 00000009 00320c7a 003ca39a 0031c0de
[    1.570000]         003be068 003e12e8 0000002d 00914000 00914000 0031c16c 003e12e8 0000002d
[    1.570000]         001bb44e 00000009 00000000 007d7d4c 00002000 00000000 00000000 00211826
[    1.570000]         003e12c5 007d7d6c 0020c374 001bb44e 003e12e8 0000002d 00000009 003e12c5
[    1.570000]         000001f7 003e12f4 001bb498 000001f7 003e12f4 00210066 000001f7 00210132
[    1.570000]         00914000 00914000 0000000a 00914000 0020bf8a 00914000 00964b80 0020c390
[    1.570000] Call Trace: [<00320c7a>] dump_stack+0xc/0x10
[    1.570000]  [<0031c0de>] __warn+0x70/0xbc
[    1.570000]  [<0031c16c>] warn_slowpath_fmt+0x42/0x62
[    1.570000]  [<001bb44e>] bad_io_access+0x32/0x38
[    1.570000]  [<00002000>] _start+0x0/0x8
[    1.570000]  [<00211826>] ata_sff_interrupt+0x0/0x144
[    1.570000]  [<0020c374>] ata_eh_freeze_port+0x0/0x24
[    1.570000]  [<001bb44e>] bad_io_access+0x32/0x38
[    1.570000]  [<001bb498>] ioread8+0x44/0x4c
[    1.570000]  [<00210066>] ata_sff_check_status+0xe/0x12
[    1.570000]  [<00210132>] ata_sff_freeze+0x30/0x4c
[    1.570000]  [<0020bf8a>] __ata_port_freeze+0x3a/0x46
[    1.570000]  [<0020c390>] ata_eh_freeze_port+0x1c/0x24
[    1.570000]  [<00203e80>] ata_host_start+0x112/0x130
[    1.570000]  [<0020bee8>] ata_port_desc+0x0/0x68
[    1.570000]  [<0020451e>] ata_host_activate+0x20/0xf8
[    1.570000]  [<001ea47c>] platform_get_resource+0x0/0x48
[    1.570000]  [<00002080>] do_one_initcall+0x0/0x184
[    1.570000]  [<0020bee8>] ata_port_desc+0x0/0x68
[    1.570000]  [<0049d35a>] pata_falcon_init_one+0x1e6/0x1f4
[    1.570000]  [<00211826>] ata_sff_interrupt+0x0/0x144
[    1.570000]  [<00306fa0>] klist_next+0x0/0x80
[    1.570000]  [<001eaa26>] platform_probe+0x22/0x4e
[    1.570000]  [<001e920a>] really_probe+0xfa/0x200
[    1.570000]  [<001e9402>] driver_probe_device+0x20/0x78
[    1.570000]  [<003150ee>] strcpy+0x0/0x1c
[    1.570000]  [<001e959e>] __driver_attach+0xbe/0xce
[    1.570000]  [<00306fa0>] klist_next+0x0/0x80
[    1.570000]  [<001e79cc>] bus_for_each_dev+0x62/0x86
[    1.570000]  [<001e8c18>] driver_attach+0x16/0x1c
[    1.570000]  [<001e94e0>] __driver_attach+0x0/0xce
[    1.570000]  [<001e8688>] bus_add_driver+0x96/0x18c
[    1.570000]  [<001e9c3e>] driver_register+0x9c/0xda
[    1.570000]  [<001ea9ce>] __platform_driver_probe+0x64/0x9a
[    1.570000]  [<0049d15c>] pata_falcon_driver_init+0x0/0x18
[    1.570000]  [<0049d16e>] pata_falcon_driver_init+0x12/0x18
[    1.570000]  [<0049d174>] pata_falcon_init_one+0x0/0x1f4
[    1.570000]  [<000020da>] do_one_initcall+0x5a/0x184
[    1.570000]  [<003150ee>] strcpy+0x0/0x1c
[    1.570000]  [<00028374>] parse_args+0x0/0x25e
[    1.570000]  [<00002080>] do_one_initcall+0x0/0x184
[    1.570000]  [<00060006>] check_max_stack_depth_subprog+0x16e/0x220
[    1.570000]  [<0048f4b2>] kernel_init_freeable+0x132/0x18a
[    1.570000]  [<0048f500>] kernel_init_freeable+0x180/0x18a
[    1.570000]  [<0049d15c>] pata_falcon_driver_init+0x0/0x18
[    1.570000]  [<000286c8>] list_del_init+0x0/0x1c
[    1.570000]  [<00015cbc>] kernel_thread+0x0/0x68
[    1.570000]  [<00320df4>] kernel_init+0x0/0xec
[    1.570000]  [<00320e08>] kernel_init+0x14/0xec
[    1.570000]  [<00320df4>] kernel_init+0x0/0xec
[    1.570000]  [<00002898>] ret_from_kernel_thread+0xc/0x14
[    1.570000] 
[    1.570000] ---[ end trace 0000000000000000 ]---
[    1.600000] scsi host0: pata_falcon
[    1.610000] ata1: PATA max PIO4 cmd 0x1f0 ctl 0x3f6 irq 14
[    1.620000] atari-falcon-ide atari-falcon-ide.1: Atari Falcon and Q40/Q60 PATA controller
[    1.630000] ------------[ cut here ]------------
[    1.630000] WARNING: CPU: 0 PID: 1 at lib/iomap.c:45 bad_io_access+0x32/0x38
[    1.630000] Bad IO access at port 0x376 (outb(val,port))
[    1.630000] Modules linked in:
[    1.630000] CPU: 0 PID: 1 Comm: swapper Tainted: G        W          6.4.10-wrs #1
[    1.630000] Stack from 007d7cf8:
[    1.630000]         007d7cf8 003ca39a 003ca39a 00000000 00000009 00320c7a 003ca39a 0031c0de
[    1.630000]         003be068 003e12e8 0000002d 00990000 00990000 0031c16c 003e12e8 0000002d
[    1.630000]         001bb44e 00000009 00000000 007d7d58 00002000 00000000 00000000 00211826
[    1.630000]         003e12c5 007d7d78 0020c374 001bb44e 003e12e8 0000002d 00000009 003e12c5
[    1.630000]         00000376 003e1330 002100fc 00000376 003e1330 00210126 00990000 0000000a
[    1.630000]         00990000 0020bf8a 00990000 009646c0 0020c390 00990000 00000001 00203e80
[    1.630000] Call Trace: [<00320c7a>] dump_stack+0xc/0x10
[    1.630000]  [<0031c0de>] __warn+0x70/0xbc
[    1.630000]  [<0031c16c>] warn_slowpath_fmt+0x42/0x62
[    1.630000]  [<001bb44e>] bad_io_access+0x32/0x38
[    1.630000]  [<00002000>] _start+0x0/0x8
[    1.630000]  [<00211826>] ata_sff_interrupt+0x0/0x144
[    1.630000]  [<0020c374>] ata_eh_freeze_port+0x0/0x24
[    1.630000]  [<001bb44e>] bad_io_access+0x32/0x38
[    1.630000]  [<002100fc>] ata_sff_set_devctl+0x3c/0x42
[    1.630000]  [<00210126>] ata_sff_freeze+0x24/0x4c
[    1.630000]  [<0020bf8a>] __ata_port_freeze+0x3a/0x46
[    1.630000]  [<0020c390>] ata_eh_freeze_port+0x1c/0x24
[    1.630000]  [<00203e80>] ata_host_start+0x112/0x130
[    1.630000]  [<0020bee8>] ata_port_desc+0x0/0x68
[    1.630000]  [<0020451e>] ata_host_activate+0x20/0xf8
[    1.630000]  [<001ea47c>] platform_get_resource+0x0/0x48
[    1.630000]  [<00002080>] do_one_initcall+0x0/0x184
[    1.630000]  [<0020bee8>] ata_port_desc+0x0/0x68
[    1.630000]  [<0049d35a>] pata_falcon_init_one+0x1e6/0x1f4
[    1.630000]  [<00211826>] ata_sff_interrupt+0x0/0x144
[    1.630000]  [<00306fa0>] klist_next+0x0/0x80
[    1.630000]  [<001eaa26>] platform_probe+0x22/0x4e
[    1.630000]  [<001e920a>] really_probe+0xfa/0x200
[    1.630000]  [<001e9402>] driver_probe_device+0x20/0x78
[    1.630000]  [<003150ee>] strcpy+0x0/0x1c
[    1.630000]  [<001e959e>] __driver_attach+0xbe/0xce
[    1.630000]  [<00306fa0>] klist_next+0x0/0x80
[    1.630000]  [<001e79cc>] bus_for_each_dev+0x62/0x86
[    1.630000]  [<001e8c18>] driver_attach+0x16/0x1c
[    1.630000]  [<001e94e0>] __driver_attach+0x0/0xce
[    1.630000]  [<001e8688>] bus_add_driver+0x96/0x18c
[    1.630000]  [<001e9c3e>] driver_register+0x9c/0xda
[    1.630000]  [<001ea9ce>] __platform_driver_probe+0x64/0x9a
[    1.630000]  [<0049d15c>] pata_falcon_driver_init+0x0/0x18
[    1.630000]  [<0049d16e>] pata_falcon_driver_init+0x12/0x18
[    1.630000]  [<0049d174>] pata_falcon_init_one+0x0/0x1f4
[    1.630000]  [<000020da>] do_one_initcall+0x5a/0x184
[    1.630000]  [<003150ee>] strcpy+0x0/0x1c
[    1.630000]  [<00028374>] parse_args+0x0/0x25e
[    1.630000]  [<00002080>] do_one_initcall+0x0/0x184
[    1.630000]  [<00060006>] check_max_stack_depth_subprog+0x16e/0x220
[    1.630000]  [<0048f4b2>] kernel_init_freeable+0x132/0x18a
[    1.630000]  [<0048f500>] kernel_init_freeable+0x180/0x18a
[    1.630000]  [<0049d15c>] pata_falcon_driver_init+0x0/0x18
[    1.630000]  [<000286c8>] list_del_init+0x0/0x1c
[    1.630000]  [<00015cbc>] kernel_thread+0x0/0x68
[    1.630000]  [<00320df4>] kernel_init+0x0/0xec
[    1.630000]  [<00320e08>] kernel_init+0x14/0xec
[    1.630000]  [<00320df4>] kernel_init+0x0/0xec
[    1.630000]  [<00002898>] ret_from_kernel_thread+0xc/0x14
[    1.630000] 
[    1.630000] ---[ end trace 0000000000000000 ]---
[    1.630000] ------------[ cut here ]------------
[    1.630000] WARNING: CPU: 0 PID: 1 at lib/iomap.c:45 bad_io_access+0x32/0x38
[    1.630000] Bad IO access at port 0x177 (return inb(port))
[    1.630000] Modules linked in:
[    1.630000] CPU: 0 PID: 1 Comm: swapper Tainted: G        W          6.4.10-wrs #1
[    1.630000] Stack from 007d7cec:
[    1.630000]         007d7cec 003ca39a 003ca39a 00000000 00000009 00320c7a 003ca39a 0031c0de
[    1.630000]         003be068 003e12e8 0000002d 00990000 00990000 0031c16c 003e12e8 0000002d
[    1.630000]         001bb44e 00000009 00000000 007d7d4c 00002000 00000000 00000000 00211826
[    1.630000]         003e12c5 007d7d6c 0020c374 001bb44e 003e12e8 0000002d 00000009 003e12c5
[    1.630000]         00000177 003e12f4 001bb498 00000177 003e12f4 00210066 00000177 00210132
[    1.630000]         00990000 00990000 0000000a 00990000 0020bf8a 00990000 009646c0 0020c390
[    1.630000] Call Trace: [<00320c7a>] dump_stack+0xc/0x10
[    1.630000]  [<0031c0de>] __warn+0x70/0xbc
[    1.630000]  [<0031c16c>] warn_slowpath_fmt+0x42/0x62
[    1.630000]  [<001bb44e>] bad_io_access+0x32/0x38
[    1.630000]  [<00002000>] _start+0x0/0x8
[    1.630000]  [<00211826>] ata_sff_interrupt+0x0/0x144
[    1.630000]  [<0020c374>] ata_eh_freeze_port+0x0/0x24
[    1.630000]  [<001bb44e>] bad_io_access+0x32/0x38
[    1.630000]  [<001bb498>] ioread8+0x44/0x4c
[    1.630000]  [<00210066>] ata_sff_check_status+0xe/0x12
[    1.630000]  [<00210132>] ata_sff_freeze+0x30/0x4c
[    1.630000]  [<0020bf8a>] __ata_port_freeze+0x3a/0x46
[    1.630000]  [<0020c390>] ata_eh_freeze_port+0x1c/0x24
[    1.630000]  [<00203e80>] ata_host_start+0x112/0x130
[    1.630000]  [<0020bee8>] ata_port_desc+0x0/0x68
[    1.630000]  [<0020451e>] ata_host_activate+0x20/0xf8
[    1.630000]  [<001ea47c>] platform_get_resource+0x0/0x48
[    1.630000]  [<00002080>] do_one_initcall+0x0/0x184
[    1.630000]  [<0020bee8>] ata_port_desc+0x0/0x68
[    1.630000]  [<0049d35a>] pata_falcon_init_one+0x1e6/0x1f4
[    1.630000]  [<00211826>] ata_sff_interrupt+0x0/0x144
[    1.630000]  [<00306fa0>] klist_next+0x0/0x80
[    1.630000]  [<001eaa26>] platform_probe+0x22/0x4e
[    1.630000]  [<001e920a>] really_probe+0xfa/0x200
[    1.630000]  [<001e9402>] driver_probe_device+0x20/0x78
[    1.630000]  [<003150ee>] strcpy+0x0/0x1c
[    1.630000]  [<001e959e>] __driver_attach+0xbe/0xce
[    1.630000]  [<00306fa0>] klist_next+0x0/0x80
[    1.630000]  [<001e79cc>] bus_for_each_dev+0x62/0x86
[    1.630000]  [<001e8c18>] driver_attach+0x16/0x1c
[    1.630000]  [<001e94e0>] __driver_attach+0x0/0xce
[    1.630000]  [<001e8688>] bus_add_driver+0x96/0x18c
[    1.630000]  [<001e9c3e>] driver_register+0x9c/0xda
[    1.630000]  [<001ea9ce>] __platform_driver_probe+0x64/0x9a
[    1.630000]  [<0049d15c>] pata_falcon_driver_init+0x0/0x18
[    1.630000]  [<0049d16e>] pata_falcon_driver_init+0x12/0x18
[    1.630000]  [<0049d174>] pata_falcon_init_one+0x0/0x1f4
[    1.630000]  [<000020da>] do_one_initcall+0x5a/0x184
[    1.630000]  [<003150ee>] strcpy+0x0/0x1c
[    1.630000]  [<00028374>] parse_args+0x0/0x25e
[    1.630000]  [<00002080>] do_one_initcall+0x0/0x184
[    1.630000]  [<00060006>] check_max_stack_depth_subprog+0x16e/0x220
[    1.630000]  [<0048f4b2>] kernel_init_freeable+0x132/0x18a
[    1.630000]  [<0048f500>] kernel_init_freeable+0x180/0x18a
[    1.630000]  [<0049d15c>] pata_falcon_driver_init+0x0/0x18
[    1.630000]  [<000286c8>] list_del_init+0x0/0x1c
[    1.630000]  [<00015cbc>] kernel_thread+0x0/0x68
[    1.630000]  [<00320df4>] kernel_init+0x0/0xec
[    1.630000]  [<00320e08>] kernel_init+0x14/0xec
[    1.630000]  [<00320df4>] kernel_init+0x0/0xec
[    1.630000]  [<00002898>] ret_from_kernel_thread+0xc/0x14
[    1.630000] 
[    1.630000] ---[ end trace 0000000000000000 ]---
[    1.650000] ------------[ cut here ]------------
[    1.650000] WARNING: CPU: 0 PID: 18 at lib/iomap.c:45 bad_io_access+0x32/0x38
[    1.660000] Bad IO access at port 0x1f7 (return inb(port))
[    1.670000] Modules linked in:
[    1.670000] CPU: 0 PID: 18 Comm: scsi_eh_0 Tainted: G        W          6.4.10-wrs #1
[    1.670000] Stack from 00989cf8:
[    1.670000]         00989cf8 003ca39a 003ca39a 00000000 00000009 00320c7a 003ca39a 0031c0de
[    1.670000]         003be068 003e12e8 0000002d 00915550 ffff8d69 0031c16c 003e12e8 0000002d
[    1.670000]         001bb44e 00000009 00000000 00989d58 ffff8f5d ffff8b75 ffff8f5d 00000000
[    1.670000]         003e12c5 00989d78 002042c8 001bb44e 003e12e8 0000002d 00000009 003e12c5
[    1.670000]         000001f7 003e12f4 001bb498 000001f7 003e12f4 00210066 000001f7 0020ffde
[    1.670000]         00914000 00204ef6 00915550 ffff8f5d 0021075c 0000000c 00000000 0020ca8a
[    1.670000] Call Trace: [<00320c7a>] dump_stack+0xc/0x10
[    1.670000]  [<0031c0de>] __warn+0x70/0xbc
[    1.670000]  [<0031c16c>] warn_slowpath_fmt+0x42/0x62
[    1.670000]  [<001bb44e>] bad_io_access+0x32/0x38
[    1.670000]  [<002042c8>] ata_link_online+0x0/0x2a
[    1.670000]  [<001bb44e>] bad_io_access+0x32/0x38
[    1.670000]  [<001bb498>] ioread8+0x44/0x4c
[    1.670000]  [<00210066>] ata_sff_check_status+0xe/0x12
[    1.670000]  [<0020ffde>] ata_sff_check_ready+0x12/0x2a
[    1.670000]  [<00204ef6>] ata_wait_ready+0x6c/0x120
[    1.670000]  [<0021075c>] ata_sff_softreset+0x0/0x154
[    1.670000]  [<0020ca8a>] ata_eh_about_to_do+0x0/0x42
[    1.670000]  [<002100ba>] ata_sff_wait_ready+0x12/0x18
[    1.670000]  [<0020ffcc>] ata_sff_check_ready+0x0/0x2a
[    1.670000]  [<00210c36>] ata_sff_prereset+0x38/0x8a
[    1.670000]  [<00210bfe>] ata_sff_prereset+0x0/0x8a
[    1.670000]  [<0020da8c>] ata_eh_reset+0x212/0x8e8
[    1.670000]  [<0020bcc8>] ata_class_enabled+0x0/0x1c
[    1.670000]  [<0020c9aa>] ata_eh_schedule_probe+0x0/0xe0
[    1.670000]  [<0020c92e>] ata_eh_detach_dev+0x0/0x7c
[    1.670000]  [<00203bec>] ata_link_next+0x0/0x8c
[    1.670000]  [<0020d87a>] ata_eh_reset+0x0/0x8e8
[    1.670000]  [<0020c320>] ata_count_probe_trials_cb+0x0/0x54
[    1.670000]  [<0020bcc8>] ata_class_enabled+0x0/0x1c
[    1.670000]  [<0020e5d8>] ata_eh_recover+0x37e/0xbe4
[    1.670000]  [<00210bfe>] ata_sff_prereset+0x0/0x8a
[    1.670000]  [<0021075c>] ata_sff_softreset+0x0/0x154
[    1.670000]  [<002108b0>] ata_sff_postreset+0x0/0x76
[    1.670000]  [<00210bfe>] ata_sff_prereset+0x0/0x8a
[    1.670000]  [<0021075c>] ata_sff_softreset+0x0/0x154
[    1.670000]  [<00012004>] fp_roundint+0x50/0x1e8
[    1.670000]  [<002108b0>] ata_sff_postreset+0x0/0x76
[    1.670000]  [<00203bec>] ata_link_next+0x0/0x8c
[    1.670000]  [<00023d60>] __flush_work.isra.0+0x54/0x134
[    1.670000]  [<0000405e>] do_notify_resume+0x56/0x4a8
[    1.670000]  [<00022f22>] set_work_data+0x0/0x46
[    1.670000]  [<00024b3a>] try_to_grab_pending+0x0/0xc0
[    1.670000]  [<0020d386>] ata_eh_autopsy+0x8c/0x94
[    1.670000]  [<0031ba44>] memset+0x0/0x94
[    1.670000]  [<0020f2c0>] ata_do_eh+0x3a/0x8e
[    1.670000]  [<00210bfe>] ata_sff_prereset+0x0/0x8a
[    1.670000]  [<0021075c>] ata_sff_softreset+0x0/0x154
[    1.670000]  [<002108b0>] ata_sff_postreset+0x0/0x76
[    1.670000]  [<0021075c>] ata_sff_softreset+0x0/0x154
[    1.670000]  [<00312001>] siphash_2u64+0xd/0x8b2
[    1.670000]  [<002109a6>] ata_sff_error_handler+0x80/0x8a
[    1.670000]  [<00210bfe>] ata_sff_prereset+0x0/0x8a
[    1.670000]  [<0021075c>] ata_sff_softreset+0x0/0x154
[    1.670000]  [<002108b0>] ata_sff_postreset+0x0/0x76
[    1.670000]  [<002046f2>] ata_dev_next+0x0/0xac
[    1.670000]  [<0031b8ec>] memcpy+0x0/0x78
[    1.670000]  [<0020ef80>] ata_scsi_port_error_handler+0x90/0x2fc
[    1.670000]  [<00015cbc>] kernel_thread+0x0/0x68
[    1.670000]  [<00028736>] kthread_should_stop+0x0/0x12
[    1.670000]  [<001f3460>] scsi_host_busy+0x0/0x2a
[    1.670000]  [<0020f258>] ata_scsi_error+0x6c/0x9a
[    1.670000]  [<001f4c5e>] scsi_device_online+0x0/0x24
[    1.670000]  [<00028736>] kthread_should_stop+0x0/0x12
[    1.670000]  [<001f681a>] scsi_error_handler+0x5e/0x242
[    1.670000]  [<000286c8>] list_del_init+0x0/0x1c
[    1.670000]  [<00015cbc>] kernel_thread+0x0/0x68
[    1.670000]  [<000295a4>] kthread_exit+0x0/0x14
[    1.670000]  [<001f67bc>] scsi_error_handler+0x0/0x242
[    1.670000]  [<00322a26>] schedule_preempt_disabled+0xa/0xe
[    1.670000]  [<000295a4>] kthread_exit+0x0/0x14
[    1.670000]  [<00029668>] kthread+0x96/0xa0
[    1.670000]  [<000295d2>] kthread+0x0/0xa0
[    1.670000]  [<00002898>] ret_from_kernel_thread+0xc/0x14
[    1.670000] 
[    1.680000] ---[ end trace 0000000000000000 ]---
[    1.680000] ------------[ cut here ]------------
[    1.680000] WARNING: CPU: 0 PID: 18 at lib/iomap.c:45 bad_io_access+0x32/0x38
[    1.680000] Bad IO access at port 0x3f6 (outb(val,port))
[    1.680000] Modules linked in:
[    1.680000] CPU: 0 PID: 18 Comm: scsi_eh_0 Tainted: G        W          6.4.10-wrs #1
[    1.680000] Stack from 00989d34:
[    1.680000]         00989d34 003ca39a 003ca39a 00000000 00000009 00320c7a 003ca39a 0031c0de
[    1.680000]         003be068 003e12e8 0000002d 00914000 00914000 0031c16c 003e12e8 0000002d
[    1.680000]         001bb44e 00000009 00000000 00989d94 00002000 0021075c 0000000c 00000000
[    1.680000]         003e12c5 00989db4 00915780 001bb44e 003e12e8 0000002d 00000009 003e12c5
[    1.680000]         000003f6 003e1330 002100fc 000003f6 003e1330 00210126 00914000 0000000a
[    1.680000]         00914000 0020bf8a 00914000 00915550 0020c390 00914000 00000000 0020db1a
[    1.680000] Call Trace: [<00320c7a>] dump_stack+0xc/0x10
[    1.680000]  [<0031c0de>] __warn+0x70/0xbc
[    1.680000]  [<0031c16c>] warn_slowpath_fmt+0x42/0x62
[    1.680000]  [<001bb44e>] bad_io_access+0x32/0x38
[    1.680000]  [<00002000>] _start+0x0/0x8
[    1.680000]  [<0021075c>] ata_sff_softreset+0x0/0x154
[    1.680000]  [<001bb44e>] bad_io_access+0x32/0x38
[    1.680000]  [<002100fc>] ata_sff_set_devctl+0x3c/0x42
[    1.680000]  [<00210126>] ata_sff_freeze+0x24/0x4c
[    1.680000]  [<0020bf8a>] __ata_port_freeze+0x3a/0x46
[    1.680000]  [<0020c390>] ata_eh_freeze_port+0x1c/0x24
[    1.680000]  [<0020db1a>] ata_eh_reset+0x2a0/0x8e8
[    1.680000]  [<0020bcc8>] ata_class_enabled+0x0/0x1c
[    1.680000]  [<0020c9aa>] ata_eh_schedule_probe+0x0/0xe0
[    1.680000]  [<0020c92e>] ata_eh_detach_dev+0x0/0x7c
[    1.680000]  [<00203bec>] ata_link_next+0x0/0x8c
[    1.680000]  [<0020d87a>] ata_eh_reset+0x0/0x8e8
[    1.680000]  [<0020c320>] ata_count_probe_trials_cb+0x0/0x54
[    1.680000]  [<0020e5d8>] ata_eh_recover+0x37e/0xbe4
[    1.680000]  [<00210bfe>] ata_sff_prereset+0x0/0x8a
[    1.680000]  [<0021075c>] ata_sff_softreset+0x0/0x154
[    1.680000]  [<002108b0>] ata_sff_postreset+0x0/0x76
[    1.680000]  [<00210bfe>] ata_sff_prereset+0x0/0x8a
[    1.680000]  [<0021075c>] ata_sff_softreset+0x0/0x154
[    1.680000]  [<00012004>] fp_roundint+0x50/0x1e8
[    1.680000]  [<002108b0>] ata_sff_postreset+0x0/0x76
[    1.680000]  [<00203bec>] ata_link_next+0x0/0x8c
[    1.680000]  [<00023d60>] __flush_work.isra.0+0x54/0x134
[    1.680000]  [<0000405e>] do_notify_resume+0x56/0x4a8
[    1.680000]  [<00022f22>] set_work_data+0x0/0x46
[    1.680000]  [<00024b3a>] try_to_grab_pending+0x0/0xc0
[    1.680000]  [<0020d386>] ata_eh_autopsy+0x8c/0x94
[    1.680000]  [<0031ba44>] memset+0x0/0x94
[    1.680000]  [<0020f2c0>] ata_do_eh+0x3a/0x8e
[    1.680000]  [<00210bfe>] ata_sff_prereset+0x0/0x8a
[    1.680000]  [<0021075c>] ata_sff_softreset+0x0/0x154
[    1.680000]  [<002108b0>] ata_sff_postreset+0x0/0x76
[    1.680000]  [<0021075c>] ata_sff_softreset+0x0/0x154
[    1.680000]  [<00312001>] siphash_2u64+0xd/0x8b2
[    1.680000]  [<002109a6>] ata_sff_error_handler+0x80/0x8a
[    1.680000]  [<00210bfe>] ata_sff_prereset+0x0/0x8a
[    1.680000]  [<0021075c>] ata_sff_softreset+0x0/0x154
[    1.680000]  [<002108b0>] ata_sff_postreset+0x0/0x76
[    1.680000]  [<002046f2>] ata_dev_next+0x0/0xac
[    1.680000]  [<0031b8ec>] memcpy+0x0/0x78
[    1.680000]  [<0020ef80>] ata_scsi_port_error_handler+0x90/0x2fc
[    1.680000]  [<00015cbc>] kernel_thread+0x0/0x68
[    1.680000]  [<00028736>] kthread_should_stop+0x0/0x12
[    1.680000]  [<001f3460>] scsi_host_busy+0x0/0x2a
[    1.680000]  [<0020f258>] ata_scsi_error+0x6c/0x9a
[    1.680000]  [<001f4c5e>] scsi_device_online+0x0/0x24
[    1.680000]  [<00028736>] kthread_should_stop+0x0/0x12
[    1.680000]  [<001f681a>] scsi_error_handler+0x5e/0x242
[    1.680000]  [<000286c8>] list_del_init+0x0/0x1c
[    1.680000]  [<00015cbc>] kernel_thread+0x0/0x68
[    1.680000]  [<000295a4>] kthread_exit+0x0/0x14
[    1.680000]  [<001f67bc>] scsi_error_handler+0x0/0x242
[    1.680000]  [<00322a26>] schedule_preempt_disabled+0xa/0xe
[    1.680000]  [<000295a4>] kthread_exit+0x0/0x14
[    1.680000]  [<00029668>] kthread+0x96/0xa0
[    1.680000]  [<000295d2>] kthread+0x0/0xa0
[    1.680000]  [<00002898>] ret_from_kernel_thread+0xc/0x14
[    1.680000] 
[    1.680000] ---[ end trace 0000000000000000 ]---
[    1.680000] ------------[ cut here ]------------
[    1.680000] WARNING: CPU: 0 PID: 18 at lib/iomap.c:45 bad_io_access+0x32/0x38
[    1.680000] Bad IO access at port 0x1f7 (return inb(port))
[    1.680000] Modules linked in:
[    1.680000] CPU: 0 PID: 18 Comm: scsi_eh_0 Tainted: G        W          6.4.10-wrs #1
[    1.680000] Stack from 00989d28:
[    1.680000]         00989d28 003ca39a 003ca39a 00000000 00000009 00320c7a 003ca39a 0031c0de
[    1.680000]         003be068 003e12e8 0000002d 00914000 00914000 0031c16c 003e12e8 0000002d
[    1.680000]         001bb44e 00000009 00000000 00989d88 00002000 0021075c 0000000c 00000000
[    1.680000]         003e12c5 00989da8 00915780 001bb44e 003e12e8 0000002d 00000009 003e12c5
[    1.680000]         000001f7 003e12f4 001bb498 000001f7 003e12f4 00210066 000001f7 00210132
[    1.680000]         00914000 00914000 0000000a 00914000 0020bf8a 00914000 00915550 0020c390
[    1.680000] Call Trace: [<00320c7a>] dump_stack+0xc/0x10
[    1.680000]  [<0031c0de>] __warn+0x70/0xbc
[    1.680000]  [<0031c16c>] warn_slowpath_fmt+0x42/0x62
[    1.680000]  [<001bb44e>] bad_io_access+0x32/0x38
[    1.680000]  [<00002000>] _start+0x0/0x8
[    1.680000]  [<0021075c>] ata_sff_softreset+0x0/0x154
[    1.680000]  [<001bb44e>] bad_io_access+0x32/0x38
[    1.680000]  [<001bb498>] ioread8+0x44/0x4c
[    1.680000]  [<00210066>] ata_sff_check_status+0xe/0x12
[    1.680000]  [<00210132>] ata_sff_freeze+0x30/0x4c
[    1.680000]  [<0020bf8a>] __ata_port_freeze+0x3a/0x46
[    1.680000]  [<0020c390>] ata_eh_freeze_port+0x1c/0x24
[    1.680000]  [<0020db1a>] ata_eh_reset+0x2a0/0x8e8
[    1.680000]  [<0020bcc8>] ata_class_enabled+0x0/0x1c
[    1.680000]  [<0020c9aa>] ata_eh_schedule_probe+0x0/0xe0
[    1.680000]  [<0020c92e>] ata_eh_detach_dev+0x0/0x7c
[    1.680000]  [<00203bec>] ata_link_next+0x0/0x8c
[    1.680000]  [<0020d87a>] ata_eh_reset+0x0/0x8e8
[    1.680000]  [<0020c320>] ata_count_probe_trials_cb+0x0/0x54
[    1.680000]  [<0020e5d8>] ata_eh_recover+0x37e/0xbe4
[    1.680000]  [<00210bfe>] ata_sff_prereset+0x0/0x8a
[    1.680000]  [<0021075c>] ata_sff_softreset+0x0/0x154
[    1.680000]  [<002108b0>] ata_sff_postreset+0x0/0x76
[    1.680000]  [<00210bfe>] ata_sff_prereset+0x0/0x8a
[    1.680000]  [<0021075c>] ata_sff_softreset+0x0/0x154
[    1.680000]  [<00012004>] fp_roundint+0x50/0x1e8
[    1.680000]  [<002108b0>] ata_sff_postreset+0x0/0x76
[    1.680000]  [<00203bec>] ata_link_next+0x0/0x8c
[    1.680000]  [<00023d60>] __flush_work.isra.0+0x54/0x134
[    1.680000]  [<0000405e>] do_notify_resume+0x56/0x4a8
[    1.680000]  [<00022f22>] set_work_data+0x0/0x46
[    1.680000]  [<00024b3a>] try_to_grab_pending+0x0/0xc0
[    1.680000]  [<0020d386>] ata_eh_autopsy+0x8c/0x94
[    1.680000]  [<0031ba44>] memset+0x0/0x94
[    1.680000]  [<0020f2c0>] ata_do_eh+0x3a/0x8e
[    1.680000]  [<00210bfe>] ata_sff_prereset+0x0/0x8a
[    1.680000]  [<0021075c>] ata_sff_softreset+0x0/0x154
[    1.680000]  [<002108b0>] ata_sff_postreset+0x0/0x76
[    1.680000]  [<0021075c>] ata_sff_softreset+0x0/0x154
[    1.680000]  [<00312001>] siphash_2u64+0xd/0x8b2
[    1.680000]  [<002109a6>] ata_sff_error_handler+0x80/0x8a
[    1.680000]  [<00210bfe>] ata_sff_prereset+0x0/0x8a
[    1.680000]  [<0021075c>] ata_sff_softreset+0x0/0x154
[    1.680000]  [<002108b0>] ata_sff_postreset+0x0/0x76
[    1.680000]  [<002046f2>] ata_dev_next+0x0/0xac
[    1.680000]  [<0031b8ec>] memcpy+0x0/0x78
[    1.680000]  [<0020ef80>] ata_scsi_port_error_handler+0x90/0x2fc
[    1.680000]  [<00015cbc>] kernel_thread+0x0/0x68
[    1.680000]  [<00028736>] kthread_should_stop+0x0/0x12
[    1.680000]  [<001f3460>] scsi_host_busy+0x0/0x2a
[    1.680000]  [<0020f258>] ata_scsi_error+0x6c/0x9a
[    1.680000]  [<001f4c5e>] scsi_device_online+0x0/0x24
[    1.680000]  [<00028736>] kthread_should_stop+0x0/0x12
[    1.680000]  [<001f681a>] scsi_error_handler+0x5e/0x242
[    1.680000]  [<000286c8>] list_del_init+0x0/0x1c
[    1.680000]  [<00015cbc>] kernel_thread+0x0/0x68
[    1.680000]  [<000295a4>] kthread_exit+0x0/0x14
[    1.680000]  [<001f67bc>] scsi_error_handler+0x0/0x242
[    1.680000]  [<00322a26>] schedule_preempt_disabled+0xa/0xe
[    1.680000]  [<000295a4>] kthread_exit+0x0/0x14
[    1.680000]  [<00029668>] kthread+0x96/0xa0
[    1.680000]  [<000295d2>] kthread+0x0/0xa0
[    1.680000]  [<00002898>] ret_from_kernel_thread+0xc/0x14
[    1.680000] 
[    1.680000] ---[ end trace 0000000000000000 ]---
[    1.690000] ------------[ cut here ]------------
[    1.690000] WARNING: CPU: 0 PID: 18 at lib/iomap.c:45 bad_io_access+0x32/0x38
[    1.700000] Bad IO access at port 0x1f6 (outb(val,port))
[    1.700000] Modules linked in:
[    1.710000] CPU: 0 PID: 18 Comm: scsi_eh_0 Tainted: G        W          6.4.10-wrs #1
[    1.710000] Stack from 00989d04:
[    1.710000]         00989d04 003ca39a 003ca39a 00000000 00000009 00320c7a 003ca39a 0031c0de
[    1.710000]         003be068 003e12e8 0000002d 00914000 00915550 0031c16c 003e12e8 0000002d
[    1.710000]         001bb44e 00000009 00000000 00989d64 00000000 00000001 0000000c 00000000
[    1.710000]         003e12c5 00989d84 00915780 001bb44e 003e12e8 0000002d 00000009 003e12c5
[    1.710000]         000001f6 003e1330 00210d20 000001f6 003e1330 00914000 00210166 00914000
[    1.710000]         00000000 00000000 00914000 00915550 0021077c 00914000 00000000 00000000
[    1.710000] Call Trace: [<00320c7a>] dump_stack+0xc/0x10
[    1.710000]  [<0031c0de>] __warn+0x70/0xbc
[    1.710000]  [<0031c16c>] warn_slowpath_fmt+0x42/0x62
[    1.710000]  [<001bb44e>] bad_io_access+0x32/0x38
[    1.710000]  [<001bb44e>] bad_io_access+0x32/0x38
[    1.710000]  [<00210d20>] ata_sff_dev_select+0x20/0x32
[    1.710000]  [<00210166>] ata_devchk+0x18/0x8e
[    1.710000]  [<0021077c>] ata_sff_softreset+0x20/0x154
[    1.710000]  [<0021075c>] ata_sff_softreset+0x0/0x154
[    1.710000]  [<0020dba6>] ata_eh_reset+0x32c/0x8e8
[    1.710000]  [<0020bcc8>] ata_class_enabled+0x0/0x1c
[    1.710000]  [<0020c9aa>] ata_eh_schedule_probe+0x0/0xe0
[    1.710000]  [<0020c92e>] ata_eh_detach_dev+0x0/0x7c
[    1.710000]  [<00203bec>] ata_link_next+0x0/0x8c
[    1.710000]  [<0020d87a>] ata_eh_reset+0x0/0x8e8
[    1.710000]  [<0020c320>] ata_count_probe_trials_cb+0x0/0x54
[    1.710000]  [<0020e5d8>] ata_eh_recover+0x37e/0xbe4
[    1.710000]  [<00210bfe>] ata_sff_prereset+0x0/0x8a
[    1.710000]  [<0021075c>] ata_sff_softreset+0x0/0x154
[    1.710000]  [<002108b0>] ata_sff_postreset+0x0/0x76
[    1.710000]  [<00210bfe>] ata_sff_prereset+0x0/0x8a
[    1.710000]  [<0021075c>] ata_sff_softreset+0x0/0x154
[    1.710000]  [<00012004>] fp_roundint+0x50/0x1e8
[    1.710000]  [<002108b0>] ata_sff_postreset+0x0/0x76
[    1.710000]  [<00203bec>] ata_link_next+0x0/0x8c
[    1.710000]  [<00023d60>] __flush_work.isra.0+0x54/0x134
[    1.710000]  [<0000405e>] do_notify_resume+0x56/0x4a8
[    1.710000]  [<00022f22>] set_work_data+0x0/0x46
[    1.710000]  [<00024b3a>] try_to_grab_pending+0x0/0xc0
[    1.710000]  [<0020d386>] ata_eh_autopsy+0x8c/0x94
[    1.710000]  [<0031ba44>] memset+0x0/0x94
[    1.710000]  [<0020f2c0>] ata_do_eh+0x3a/0x8e
[    1.710000]  [<00210bfe>] ata_sff_prereset+0x0/0x8a
[    1.710000]  [<0021075c>] ata_sff_softreset+0x0/0x154
[    1.710000]  [<002108b0>] ata_sff_postreset+0x0/0x76
[    1.710000]  [<0021075c>] ata_sff_softreset+0x0/0x154
[    1.710000]  [<00312001>] siphash_2u64+0xd/0x8b2
[    1.710000]  [<002109a6>] ata_sff_error_handler+0x80/0x8a
[    1.710000]  [<00210bfe>] ata_sff_prereset+0x0/0x8a
[    1.710000]  [<0021075c>] ata_sff_softreset+0x0/0x154
[    1.710000]  [<002108b0>] ata_sff_postreset+0x0/0x76
[    1.710000]  [<002046f2>] ata_dev_next+0x0/0xac
[    1.710000]  [<0031b8ec>] memcpy+0x0/0x78
[    1.710000]  [<0020ef80>] ata_scsi_port_error_handler+0x90/0x2fc
[    1.710000]  [<00015cbc>] kernel_thread+0x0/0x68
[    1.710000]  [<00028736>] kthread_should_stop+0x0/0x12
[    1.710000]  [<001f3460>] scsi_host_busy+0x0/0x2a
[    1.710000]  [<0020f258>] ata_scsi_error+0x6c/0x9a
[    1.710000]  [<001f4c5e>] scsi_device_online+0x0/0x24
[    1.710000]  [<00028736>] kthread_should_stop+0x0/0x12
[    1.710000]  [<001f681a>] scsi_error_handler+0x5e/0x242
[    1.710000]  [<000286c8>] list_del_init+0x0/0x1c
[    1.710000]  [<00015cbc>] kernel_thread+0x0/0x68
[    1.710000]  [<000295a4>] kthread_exit+0x0/0x14
[    1.710000]  [<001f67bc>] scsi_error_handler+0x0/0x242
[    1.710000]  [<00322a26>] schedule_preempt_disabled+0xa/0xe
[    1.710000]  [<000295a4>] kthread_exit+0x0/0x14
[    1.710000]  [<00029668>] kthread+0x96/0xa0
[    1.710000]  [<000295d2>] kthread+0x0/0xa0
[    1.710000]  [<00002898>] ret_from_kernel_thread+0xc/0x14
[    1.710000] 
[    1.720000] ---[ end trace 0000000000000000 ]---
[    1.720000] ------------[ cut here ]------------
[    1.730000] WARNING: CPU: 0 PID: 18 at lib/iomap.c:45 bad_io_access+0x32/0x38
[    1.730000] Bad IO access at port 0x3f6 (return inb(port))
[    1.740000] Modules linked in:
[    1.740000] CPU: 0 PID: 18 Comm: scsi_eh_0 Tainted: G        W          6.4.10-wrs #1
[    1.740000] Stack from 00989cf0:
[    1.740000]         00989cf0 003ca39a 003ca39a 00000000 00000009 00320c7a 003ca39a 0031c0de
[    1.740000]         003be068 003e12e8 0000002d 00000000 00915550 0031c16c 003e12e8 0000002d
[    1.740000]         001bb44e 00000009 00000000 00989d50 00000000 00000001 0000000c 00000000
[    1.740000]         003e12c5 00989d70 00915780 001bb44e 003e12e8 0000002d 00000009 003e12c5
[    1.740000]         000003f6 003e12f4 001bb498 000003f6 003e12f4 0021009e 000003f6 00914000
[    1.740000]         00210cc4 00914000 00000000 00210166 00914000 00000000 00000000 00914000
[    1.740000] Call Trace: [<00320c7a>] dump_stack+0xc/0x10
[    1.740000]  [<0031c0de>] __warn+0x70/0xbc
[    1.740000]  [<0031c16c>] warn_slowpath_fmt+0x42/0x62
[    1.740000]  [<001bb44e>] bad_io_access+0x32/0x38
[    1.740000]  [<001bb44e>] bad_io_access+0x32/0x38
[    1.740000]  [<001bb498>] ioread8+0x44/0x4c
[    1.740000]  [<0021009e>] ata_sff_altstatus+0x34/0x3e
[    1.740000]  [<00210cc4>] ata_sff_pause+0xa/0x46
[    1.740000]  [<00210166>] ata_devchk+0x18/0x8e
[    1.740000]  [<0021077c>] ata_sff_softreset+0x20/0x154
[    1.740000]  [<0021075c>] ata_sff_softreset+0x0/0x154
[    1.740000]  [<0020dba6>] ata_eh_reset+0x32c/0x8e8
[    1.740000]  [<0020bcc8>] ata_class_enabled+0x0/0x1c
[    1.740000]  [<0020c9aa>] ata_eh_schedule_probe+0x0/0xe0
[    1.740000]  [<0020c92e>] ata_eh_detach_dev+0x0/0x7c
[    1.740000]  [<00203bec>] ata_link_next+0x0/0x8c
[    1.740000]  [<0020d87a>] ata_eh_reset+0x0/0x8e8
[    1.740000]  [<0020c320>] ata_count_probe_trials_cb+0x0/0x54
[    1.740000]  [<0020e5d8>] ata_eh_recover+0x37e/0xbe4
[    1.740000]  [<00210bfe>] ata_sff_prereset+0x0/0x8a
[    1.740000]  [<0021075c>] ata_sff_softreset+0x0/0x154
[    1.740000]  [<002108b0>] ata_sff_postreset+0x0/0x76
[    1.740000]  [<00210bfe>] ata_sff_prereset+0x0/0x8a
[    1.740000]  [<0021075c>] ata_sff_softreset+0x0/0x154
[    1.740000]  [<00012004>] fp_roundint+0x50/0x1e8
[    1.740000]  [<002108b0>] ata_sff_postreset+0x0/0x76
[    1.740000]  [<00203bec>] ata_link_next+0x0/0x8c
[    1.740000]  [<00023d60>] __flush_work.isra.0+0x54/0x134
[    1.740000]  [<0000405e>] do_notify_resume+0x56/0x4a8
[    1.740000]  [<00022f22>] set_work_data+0x0/0x46
[    1.740000]  [<00024b3a>] try_to_grab_pending+0x0/0xc0
[    1.740000]  [<0020d386>] ata_eh_autopsy+0x8c/0x94
[    1.740000]  [<0031ba44>] memset+0x0/0x94
[    1.740000]  [<0020f2c0>] ata_do_eh+0x3a/0x8e
[    1.740000]  [<00210bfe>] ata_sff_prereset+0x0/0x8a
[    1.740000]  [<0021075c>] ata_sff_softreset+0x0/0x154
[    1.740000]  [<002108b0>] ata_sff_postreset+0x0/0x76
[    1.740000]  [<0021075c>] ata_sff_softreset+0x0/0x154
[    1.740000]  [<00312001>] siphash_2u64+0xd/0x8b2
[    1.740000]  [<002109a6>] ata_sff_error_handler+0x80/0x8a
[    1.740000]  [<00210bfe>] ata_sff_prereset+0x0/0x8a
[    1.740000]  [<0021075c>] ata_sff_softreset+0x0/0x154
[    1.740000]  [<002108b0>] ata_sff_postreset+0x0/0x76
[    1.740000]  [<002046f2>] ata_dev_next+0x0/0xac
[    1.740000]  [<0031b8ec>] memcpy+0x0/0x78
[    1.740000]  [<0020ef80>] ata_scsi_port_error_handler+0x90/0x2fc
[    1.740000]  [<00015cbc>] kernel_thread+0x0/0x68
[    1.740000]  [<00028736>] kthread_should_stop+0x0/0x12
[    1.740000]  [<001f3460>] scsi_host_busy+0x0/0x2a
[    1.740000]  [<0020f258>] ata_scsi_error+0x6c/0x9a
[    1.740000]  [<001f4c5e>] scsi_device_online+0x0/0x24
[    1.740000]  [<00028736>] kthread_should_stop+0x0/0x12
[    1.740000]  [<001f681a>] scsi_error_handler+0x5e/0x242
[    1.740000]  [<000286c8>] list_del_init+0x0/0x1c
[    1.740000]  [<00015cbc>] kernel_thread+0x0/0x68
[    1.740000]  [<000295a4>] kthread_exit+0x0/0x14
[    1.740000]  [<001f67bc>] scsi_error_handler+0x0/0x242
[    1.740000]  [<00322a26>] schedule_preempt_disabled+0xa/0xe
[    1.740000]  [<000295a4>] kthread_exit+0x0/0x14
[    1.740000]  [<00029668>] kthread+0x96/0xa0
[    1.740000]  [<000295d2>] kthread+0x0/0xa0
[    1.740000]  [<00002898>] ret_from_kernel_thread+0xc/0x14
[    1.740000] 
[    1.750000] ---[ end trace 0000000000000000 ]---
[    1.750000] ------------[ cut here ]------------
[    1.760000] WARNING: CPU: 0 PID: 18 at lib/iomap.c:45 bad_io_access+0x32/0x38
[    1.760000] Bad IO access at port 0x1f2 (outb(val,port))
[    1.770000] Modules linked in:
[    1.770000] CPU: 0 PID: 18 Comm: scsi_eh_0 Tainted: G        W          6.4.10-wrs #1
[    1.770000] Stack from 00989d0c:
[    1.770000]         00989d0c 003ca39a 003ca39a 00000000 00000009 00320c7a 003ca39a 0031c0de
[    1.770000]         003be068 003e12e8 0000002d 00914000 001bb536 0031c16c 003e12e8 0000002d
[    1.770000]         001bb44e 00000009 00000000 00989d6c 00000000 00000001 0000000c 00000000
[    1.770000]         003e12c5 00989d8c 00915780 001bb44e 003e12e8 0000002d 00000009 003e12c5
[    1.770000]         000001f2 003e1330 00210176 000001f2 003e1330 00914000 00000000 00000000
[    1.770000]         00914000 00915550 0021077c 00914000 00000000 00000000 0021075c 0000000c
[    1.770000] Call Trace: [<00320c7a>] dump_stack+0xc/0x10
[    1.770000]  [<0031c0de>] __warn+0x70/0xbc
[    1.770000]  [<001bb536>] iowrite8+0x0/0x46
[    1.770000]  [<0031c16c>] warn_slowpath_fmt+0x42/0x62
[    1.770000]  [<001bb44e>] bad_io_access+0x32/0x38
[    1.770000]  [<001bb44e>] bad_io_access+0x32/0x38
[    1.770000]  [<00210176>] ata_devchk+0x28/0x8e
[    1.770000]  [<0021077c>] ata_sff_softreset+0x20/0x154
[    1.770000]  [<0021075c>] ata_sff_softreset+0x0/0x154
[    1.770000]  [<0020dba6>] ata_eh_reset+0x32c/0x8e8
[    1.770000]  [<0020bcc8>] ata_class_enabled+0x0/0x1c
[    1.770000]  [<0020c9aa>] ata_eh_schedule_probe+0x0/0xe0
[    1.770000]  [<0020c92e>] ata_eh_detach_dev+0x0/0x7c
[    1.770000]  [<00203bec>] ata_link_next+0x0/0x8c
[    1.770000]  [<0020d87a>] ata_eh_reset+0x0/0x8e8
[    1.770000]  [<0020c320>] ata_count_probe_trials_cb+0x0/0x54
[    1.770000]  [<0020e5d8>] ata_eh_recover+0x37e/0xbe4
[    1.770000]  [<00210bfe>] ata_sff_prereset+0x0/0x8a
[    1.770000]  [<0021075c>] ata_sff_softreset+0x0/0x154
[    1.770000]  [<002108b0>] ata_sff_postreset+0x0/0x76
[    1.770000]  [<00210bfe>] ata_sff_prereset+0x0/0x8a
[    1.770000]  [<0021075c>] ata_sff_softreset+0x0/0x154
[    1.770000]  [<00012004>] fp_roundint+0x50/0x1e8
[    1.770000]  [<002108b0>] ata_sff_postreset+0x0/0x76
[    1.770000]  [<00203bec>] ata_link_next+0x0/0x8c
[    1.770000]  [<00023d60>] __flush_work.isra.0+0x54/0x134
[    1.770000]  [<0000405e>] do_notify_resume+0x56/0x4a8
[    1.770000]  [<00022f22>] set_work_data+0x0/0x46
[    1.770000]  [<00024b3a>] try_to_grab_pending+0x0/0xc0
[    1.770000]  [<0020d386>] ata_eh_autopsy+0x8c/0x94
[    1.770000]  [<0031ba44>] memset+0x0/0x94
[    1.770000]  [<0020f2c0>] ata_do_eh+0x3a/0x8e
[    1.770000]  [<00210bfe>] ata_sff_prereset+0x0/0x8a
[    1.770000]  [<0021075c>] ata_sff_softreset+0x0/0x154
[    1.770000]  [<002108b0>] ata_sff_postreset+0x0/0x76
[    1.770000]  [<0021075c>] ata_sff_softreset+0x0/0x154
[    1.770000]  [<00312001>] siphash_2u64+0xd/0x8b2
[    1.770000]  [<002109a6>] ata_sff_error_handler+0x80/0x8a
[    1.770000]  [<00210bfe>] ata_sff_prereset+0x0/0x8a
[    1.770000]  [<0021075c>] ata_sff_softreset+0x0/0x154
[    1.770000]  [<002108b0>] ata_sff_postreset+0x0/0x76
[    1.770000]  [<002046f2>] ata_dev_next+0x0/0xac
[    1.770000]  [<0031b8ec>] memcpy+0x0/0x78
[    1.770000]  [<0020ef80>] ata_scsi_port_error_handler+0x90/0x2fc
[    1.770000]  [<00015cbc>] kernel_thread+0x0/0x68
[    1.770000]  [<00028736>] kthread_should_stop+0x0/0x12
[    1.770000]  [<001f3460>] scsi_host_busy+0x0/0x2a
[    1.770000]  [<0020f258>] ata_scsi_error+0x6c/0x9a
[    1.770000]  [<001f4c5e>] scsi_device_online+0x0/0x24
[    1.770000]  [<00028736>] kthread_should_stop+0x0/0x12
[    1.770000]  [<001f681a>] scsi_error_handler+0x5e/0x242
[    1.770000]  [<000286c8>] list_del_init+0x0/0x1c
[    1.770000]  [<00015cbc>] kernel_thread+0x0/0x68
[    1.770000]  [<000295a4>] kthread_exit+0x0/0x14
[    1.770000]  [<001f67bc>] scsi_error_handler+0x0/0x242
[    1.770000]  [<00322a26>] schedule_preempt_disabled+0xa/0xe
[    1.770000]  [<000295a4>] kthread_exit+0x0/0x14
[    1.770000]  [<00029668>] kthread+0x96/0xa0
[    1.770000]  [<000295d2>] kthread+0x0/0xa0
[    1.770000]  [<00002898>] ret_from_kernel_thread+0xc/0x14
[    1.770000] 
[    1.780000] ---[ end trace 0000000000000000 ]---
[    1.790000] scsi host1: pata_falcon
[    1.800000] ata2: PATA max PIO4 cmd 0x170 ctl 0x376 irq 15
[    1.900000] ne ne.0 (unnamed net_device) (uninitialized): NE*000 ethercard probe at 0x300:
[    1.900000] 00:00:e8:cf:2e:39
[    1.920000] ne ne.0 eth0: RTL8019 found at 0x300, using IRQ 5.
[    1.940000] PPP generic driver version 2.4.2
[    1.960000] serio: Q40 kbd registered
[    1.990000] NET: Registered PF_INET6 protocol family
[    2.010000] input: AT Raw Set 2 keyboard as /devices/platform/q40kbd/serio0/input/input0
[    2.050000] Segment Routing with IPv6
[    2.060000] In-situ OAM (IOAM) with IPv6
[    2.240000] /dev/root: Can't open blockdev
[    2.240000] VFS: Cannot open root device "(null)" or unknown-block(0,0): error -6
[    2.250000] Please append a correct "root=" boot option; here are the available partitions:
[    2.250000] Kernel panic - not syncing: VFS: Unable to mount root fs on unknown-block(0,0)
[    2.250000] CPU: 0 PID: 1 Comm: swapper Tainted: G        W          6.4.10-wrs #1
[    2.250000] Stack from 007d7ed8:
[    2.250000]         007d7ed8 003ca39a 003ca39a 00000000 ffffffff 00320c7a 003ca39a 0031bf24
[    2.250000]         00000006 00008001 00000000 0031c660 009ca000 007d7f54 004cc968 0048f828
[    2.250000]         003be5f0 007d7f54 003be59f 003be56c 00000000 007d7f54 fffffffa 00000000
[    2.250000]         0000000c 000286c8 00015cbc 00320df4 00000000 00000000 00000000 756e6b6e
[    2.250000]         6f776e2d 626c6f63 6b28302c 302900c0 00bc8280 0048f8c8 003be654 0048f8f2
[    2.250000]         003be654 00008001 00000001 007dc000 000286c8 00015cbc 00000000 00000000
[    2.250000] Call Trace: [<00320c7a>] dump_stack+0xc/0x10
[    2.250000]  [<0031bf24>] panic+0xba/0x204
[    2.250000]  [<00008001>] t_operr+0xb/0x1a
[    2.250000]  [<0031c660>] _printk+0x0/0x18
[    2.250000]  [<0048f828>] mount_block_root+0x132/0x18a
[    2.250000]  [<000286c8>] list_del_init+0x0/0x1c
[    2.250000]  [<00015cbc>] kernel_thread+0x0/0x68
[    2.250000]  [<00320df4>] kernel_init+0x0/0xec
[    2.250000]  [<0048f8c8>] mount_root+0x48/0x14e
[    2.250000]  [<0048f8f2>] mount_root+0x72/0x14e
[    2.250000]  [<00008001>] t_operr+0xb/0x1a
[    2.250000]  [<000286c8>] list_del_init+0x0/0x1c
[    2.250000]  [<00015cbc>] kernel_thread+0x0/0x68
[    2.250000]  [<00320df4>] kernel_init+0x0/0xec
[    2.250000]  [<0048fb3a>] prepare_namespace+0x16c/0x17a
[    2.250000]  [<00320df4>] kernel_init+0x0/0xec
[    2.250000]  [<00320e08>] kernel_init+0x14/0xec
[    2.250000]  [<00320df4>] kernel_init+0x0/0xec
[    2.250000]  [<00002898>] ret_from_kernel_thread+0xc/0x14
[    2.250000] 
[    2.250000] ---[ end Kernel panic - not syncing: VFS: Unable to mount root fs on unknown-block(0,0) ]---

[-- Attachment #6: linux-6.4.10+wrs --]
[-- Type: text/plain, Size: 6726 bytes --]

1:/> vmlinux-6.4.10+wrs console=ttyS0,115200n8 netdev=5,0x300,eth0 root=/dev/sdb3
vmlinux-6.4.10+wrs: 6482816 bytes, ELF.
Loading 4637888 bytes from file offset 0x1000 to memory at 0x41000
Loading 120836 bytes from file offset 0x46E000 to memory at 0x4CE000
Linux kernel detected: creating bootinfo at 0x4EC000
Entry at 0x42000 in supervisor mode
[    0.000000] Linux version 6.4.10-wrs (btg@carbon) (m68k-linux-gnu-gcc (Debian 12.2.0-13) 12.2.0, GNU ld (GNU Binutils for Debian) 2.40) #1 Sun Aug 13 22:32:30 BST 2023
[    0.000000] Zone ranges:
[    0.000000]   DMA      [mem 0x0000000000040000-0x0000001fffffffff]
[    0.000000]   Normal   empty
[    0.000000] Movable zone start for each node
[    0.000000] Early memory node ranges
[    0.000000]   node   0: [mem 0x0000000000040000-0x0000000001ffffff]
[    0.000000] Initmem setup node 0 [mem 0x0000000000040000-0x0000000001ffffff]
[    0.000000] Kernel command line: console=ttyS0,115200n8 netdev=5,0x300,eth0 root=/dev/sdb3
[    0.000000] Dentry cache hash table entries: 4096 (order: 2, 16384 bytes, linear)
[    0.000000] Inode-cache hash table entries: 2048 (order: 1, 8192 bytes, linear)
[    0.000000] Sorting __ex_table...
[    0.000000] Built 1 zonelists, mobility grouping on.  Total pages: 8056
[    0.000000] mem auto-init: stack:off, heap alloc:off, heap free:off
[    0.000000] Memory: 27340K/32512K available (3220K kernel code, 442K rwdata, 988K rodata, 120K init, 129K bss, 5172K reserved, 0K cma-reserved)
[    0.000000] NR_IRQS: 43
[    0.010000] Console: colour dummy device 80x25
[    0.010000] printk: console [ttyS0] enabled
[    0.100000] Calibrating delay loop... 26.16 BogoMIPS (lpj=130816)
[    0.210000] pid_max: default: 32768 minimum: 301
[    0.220000] Mount-cache hash table entries: 1024 (order: 0, 4096 bytes, linear)
[    0.230000] Mountpoint-cache hash table entries: 1024 (order: 0, 4096 bytes, linear)
[    0.270000] cblist_init_generic: Setting adjustable number of callback queues.
[    0.270000] cblist_init_generic: Setting shift to 0 and lim to 1.
[    0.290000] devtmpfs: initialized
[    0.320000] clocksource: jiffies: mask: 0xffffffff max_cycles: 0xffffffff, max_idle_ns: 19112604462750000 ns
[    0.320000] futex hash table entries: 256 (order: -1, 3072 bytes, linear)
[    0.360000] NET: Registered PF_NETLINK/PF_ROUTE protocol family
[    0.370000] DMA: preallocated 128 KiB GFP_KERNEL pool for atomic allocations
[    0.380000] DMA: preallocated 128 KiB GFP_KERNEL|GFP_DMA pool for atomic allocations
[    0.440000] SCSI subsystem initialized
[    0.800000] NET: Registered PF_INET protocol family
[    0.810000] IP idents hash table entries: 2048 (order: 2, 16384 bytes, linear)
[    0.840000] tcp_listen_portaddr_hash hash table entries: 1024 (order: 0, 4096 bytes, linear)
[    0.840000] Table-perturb hash table entries: 65536 (order: 6, 262144 bytes, linear)
[    0.850000] TCP established hash table entries: 1024 (order: 0, 4096 bytes, linear)
[    0.850000] TCP bind hash table entries: 1024 (order: 1, 8192 bytes, linear)
[    0.860000] TCP: Hash tables configured (established 1024 bind 1024)
[    0.860000] UDP hash table entries: 256 (order: 0, 4096 bytes, linear)
[    0.870000] UDP-Lite hash table entries: 256 (order: 0, 4096 bytes, linear)
[    0.880000] NET: Registered PF_UNIX/PF_LOCAL protocol family
[    0.900000] workingset: timestamp_bits=30 max_order=13 bucket_order=0
[    1.300000] fb0: Q40 frame buffer alive and kicking !
[    1.310000] Serial: 8250/16550 driver, 8 ports, IRQ sharing disabled
[    1.320000] serial8250: ttyS0 at I/O 0x3f8 (irq = 4, base_baud = 115200) is a 16450
[    1.340000] serial8250: ttyS1 at I/O 0x2f8 (irq = 3, base_baud = 115200) is a 16450
[    1.560000] loop: module loaded
[    1.570000] atari-falcon-ide atari-falcon-ide.0: Atari Falcon and Q40/Q60 PATA controller
[    1.590000] scsi host0: pata_falcon
[    1.600000] ata1: PATA max PIO4 cmd 0x1f0 ctl 0x3f6 irq 14
[    1.610000] atari-falcon-ide atari-falcon-ide.1: Atari Falcon and Q40/Q60 PATA controller
[    1.650000] scsi host1: pata_falcon
[    1.660000] ata2: PATA max PIO4 cmd 0x170 ctl 0x376 irq 15
[    1.760000] ne ne.0 (unnamed net_device) (uninitialized): NE*000 ethercard probe at 0x300:
[    1.760000] 00:00:e8:cf:2e:39
[    1.780000] ne ne.0 eth0: RTL8019 found at 0x300, using IRQ 5.
[    1.790000] PPP generic driver version 2.4.2
[    1.810000] serio: Q40 kbd registered
[    1.840000] NET: Registered PF_INET6 protocol family
[    1.870000] input: AT Raw Set 2 keyboard as /devices/platform/q40kbd/serio0/input/input0
[    1.910000] Segment Routing with IPv6
[    1.920000] In-situ OAM (IOAM) with IPv6
[    2.110000] ata1.00: CFA: InnoDisk Corp. - iCF4000 2GB, 080414S4, max UDMA/66
[    2.110000] ata1.00: 4095504 sectors, multi 2: LBA 
[    2.120000] ata1.01: CFA: SDCFHS-016G, HDX13.04, max UDMA/100
[    2.120000] ata1.01: 31293360 sectors, multi 0: LBA48 
[    2.140000] ata1.00: configured for PIO
[    2.140000] ata1.01: configured for PIO
[    2.150000] scsi 0:0:0:0: Direct-Access     ATA      InnoDisk Corp. - 14S4 PQ: 0 ANSI: 5
[    2.190000] scsi 0:0:1:0: Direct-Access     ATA      SDCFHS-016G      3.04 PQ: 0 ANSI: 5
[    2.230000] sd 0:0:0:0: [sda] 4095504 512-byte logical blocks: (2.10 GB/1.95 GiB)
[    2.230000] sd 0:0:0:0: [sda] Write Protect is off
[    2.240000] sd 0:0:0:0: [sda] Write cache: disabled, read cache: enabled, doesn't support DPO or FUA
[    2.250000] sd 0:0:0:0: [sda] Preferred minimum I/O size 512 bytes
[    2.260000] sd 0:0:1:0: [sdb] 31293360 512-byte logical blocks: (16.0 GB/14.9 GiB)
[    2.280000] sd 0:0:1:0: [sdb] Write Protect is off
[    2.280000] sd 0:0:1:0: [sdb] Write cache: disabled, read cache: enabled, doesn't support DPO or FUA
[    2.290000] sd 0:0:1:0: [sdb] Preferred minimum I/O size 512 bytes
[    2.360000] sd 0:0:0:0: [sda] Attached SCSI disk
[    2.370000]  sdb: sdb1 sdb2 sdb3
[    2.400000] sd 0:0:1:0: [sdb] Attached SCSI removable disk
[    2.460000] EXT4-fs (sdb3): INFO: recovery required on readonly filesystem
[    2.470000] EXT4-fs (sdb3): write access will be enabled during recovery
[    2.730000] EXT4-fs (sdb3): recovery complete
[    2.760000] EXT4-fs (sdb3): mounted filesystem f8a23063-b7c5-46f5-8693-5e1ae0b418b0 ro with ordered data mode. Quota mode: disabled.
[    2.760000] VFS: Mounted root (ext4 filesystem) readonly on device 8:19.
[    2.780000] devtmpfs: mounted
[    2.780000] Freeing unused kernel image (initmem) memory: 120K
[    2.790000] This architecture does not have kernel memory protection.
[    2.790000] Run /sbin/init as init process
[    3.910000] EXT4-fs (sdb3): re-mounted f8a23063-b7c5-46f5-8693-5e1ae0b418b0 r/w. Quota mode: disabled.
Starting syslogd: OK
Starting klogd: OK


[-- Attachment #7: linux-6.4.10-q40.patch --]
[-- Type: text/x-diff, Size: 4999 bytes --]

diff -urN linux-6.4.10.orig/arch/m68k/include/asm/kmap.h linux-6.4.10.q40/arch/m68k/include/asm/kmap.h
--- linux-6.4.10.orig/arch/m68k/include/asm/kmap.h	2023-08-11 11:14:29.000000000 +0100
+++ linux-6.4.10.q40/arch/m68k/include/asm/kmap.h	2023-08-13 15:36:32.400206567 +0100
@@ -61,7 +61,7 @@
 #define ioport_map ioport_map
 static inline void __iomem *ioport_map(unsigned long port, unsigned int nr)
 {
-	return (void __iomem *) port;
+	return (void __iomem *) port + 0x10000UL; /* NOW YOU HAVE TWO PROBLEMS */
 }
 
 #define ioport_unmap ioport_unmap
diff -urN linux-6.4.10.orig/drivers/ata/pata_falcon.c linux-6.4.10.q40/drivers/ata/pata_falcon.c
--- linux-6.4.10.orig/drivers/ata/pata_falcon.c	2023-08-11 11:14:29.000000000 +0100
+++ linux-6.4.10.q40/drivers/ata/pata_falcon.c	2023-08-13 15:47:18.426870857 +0100
@@ -43,12 +43,14 @@
 {
 	struct ata_device *dev = qc->dev;
 	struct ata_port *ap = dev->link->ap;
-	void __iomem *data_addr = ap->ioaddr.data_addr;
+	void __iomem *data_addr = ap->private_data;
 	unsigned int words = buflen >> 1;
 	struct scsi_cmnd *cmd = qc->scsicmd;
 	bool swap = 1;
 
-	if (dev->class == ATA_DEV_ATA && cmd &&
+        /* WRS: on my Q40 I need byteswapping to read from any normal disks? */
+	if (!MACH_IS_Q40 && 
+            dev->class == ATA_DEV_ATA && cmd &&
 	    !blk_rq_is_passthrough(scsi_cmd_to_rq(cmd)))
 		swap = 0;
 
@@ -165,26 +167,40 @@
 	ap->pio_mask = ATA_PIO4;
 	ap->flags |= ATA_FLAG_SLAVE_POSS | ATA_FLAG_NO_IORDY;
 
-	base = (void __iomem *)base_mem_res->start;
-	/* N.B. this assumes data_addr will be used for word-sized I/O only */
-	ap->ioaddr.data_addr		= base + 0 + 0 * 4;
-	ap->ioaddr.error_addr		= base + 1 + 1 * 4;
-	ap->ioaddr.feature_addr		= base + 1 + 1 * 4;
-	ap->ioaddr.nsect_addr		= base + 1 + 2 * 4;
-	ap->ioaddr.lbal_addr		= base + 1 + 3 * 4;
-	ap->ioaddr.lbam_addr		= base + 1 + 4 * 4;
-	ap->ioaddr.lbah_addr		= base + 1 + 5 * 4;
-	ap->ioaddr.device_addr		= base + 1 + 6 * 4;
-	ap->ioaddr.status_addr		= base + 1 + 7 * 4;
-	ap->ioaddr.command_addr		= base + 1 + 7 * 4;
-
-	base = (void __iomem *)ctl_mem_res->start;
-	ap->ioaddr.altstatus_addr	= base + 1;
-	ap->ioaddr.ctl_addr		= base + 1;
-
-	ata_port_desc(ap, "cmd 0x%lx ctl 0x%lx",
-		      (unsigned long)base_mem_res->start,
-		      (unsigned long)ctl_mem_res->start);
+	if (MACH_IS_Q40) {
+                ap->private_data = isa_itw(base_res->start);
+                ap->ioaddr.cmd_addr = ioport_map(base_res->start, 8);
+                ap->ioaddr.ctl_addr = ioport_map(ctl_res->start, 1);
+                ata_sff_std_ports(&ap->ioaddr);
+                ap->ioaddr.altstatus_addr = ap->ioaddr.ctl_addr;
+
+		ata_port_desc(ap, "cmd 0x%lx ctl 0x%lx",
+			      (unsigned long)base_res->start,
+			      (unsigned long)ctl_res->start);
+	} else {
+		base = (void __iomem *)base_mem_res->start;
+		/* N.B. this assumes data_addr will be used for word-sized I/O only */
+		ap->ioaddr.data_addr		= base + 0 + 0 * 4;
+		ap->ioaddr.error_addr		= base + 1 + 1 * 4;
+		ap->ioaddr.feature_addr		= base + 1 + 1 * 4;
+		ap->ioaddr.nsect_addr		= base + 1 + 2 * 4;
+		ap->ioaddr.lbal_addr		= base + 1 + 3 * 4;
+		ap->ioaddr.lbam_addr		= base + 1 + 4 * 4;
+		ap->ioaddr.lbah_addr		= base + 1 + 5 * 4;
+		ap->ioaddr.device_addr		= base + 1 + 6 * 4;
+		ap->ioaddr.status_addr		= base + 1 + 7 * 4;
+		ap->ioaddr.command_addr		= base + 1 + 7 * 4;
+
+		base = (void __iomem *)ctl_mem_res->start;
+		ap->ioaddr.altstatus_addr	= base + 1;
+		ap->ioaddr.ctl_addr		= base + 1;
+
+                ap->private_data = ap->ioaddr.data_addr; /* UNTESTED */
+
+		ata_port_desc(ap, "cmd 0x%lx ctl 0x%lx",
+			      (unsigned long)base_mem_res->start,
+			      (unsigned long)ctl_mem_res->start);
+	}
 
 	irq_res = platform_get_resource(pdev, IORESOURCE_IRQ, 0);
 	if (irq_res && irq_res->start > 0) {
diff -urN linux-6.4.10.orig/drivers/net/ethernet/8390/ne.c linux-6.4.10.q40/drivers/net/ethernet/8390/ne.c
--- linux-6.4.10.orig/drivers/net/ethernet/8390/ne.c	2023-08-11 11:14:29.000000000 +0100
+++ linux-6.4.10.q40/drivers/net/ethernet/8390/ne.c	2023-08-13 20:05:09.993504684 +0100
@@ -468,8 +468,11 @@
 #endif
 	}
 
-	if (dev->irq < 2)
-	{
+	if (dev->irq < 2 
+#ifdef CONFIG_Q40
+                && !MACH_IS_Q40 /* Q40 cannot do IRQ probing, it just locks up */
+#endif
+                ) {
 		unsigned long cookie = probe_irq_on();
 		outb_p(0x50, ioaddr + EN0_IMR);	/* Enable one interrupt. */
 		outb_p(0x00, ioaddr + EN0_RCNTLO);
diff -urN linux-6.4.10.orig/Makefile linux-6.4.10.q40/Makefile
--- linux-6.4.10.orig/Makefile	2023-08-11 11:14:29.000000000 +0100
+++ linux-6.4.10.q40/Makefile	2023-08-13 14:49:35.522277706 +0100
@@ -388,7 +388,8 @@
 # Alternatively CROSS_COMPILE can be set in the environment.
 # Default value for CROSS_COMPILE is not to prefix executables
 # Note: Some architectures assign CROSS_COMPILE in their arch/*/Makefile
-ARCH		?= $(SUBARCH)
+ARCH		?= m68k
+CROSS_COMPILE   ?= m68k-linux-gnu-
 
 # Architecture as present in compile.h
 UTS_MACHINE 	:= $(ARCH)

Re: Linux 6.4.4 on m68k - Q40 - pata_falcon causes oops at boot time

[Michael Schmitz]

Hi William,

thanks for running these tests!

On 14/08/23 10:24, William R Sowerbutts wrote:
> Hello
>
> Thank you for your interest and patience!
>
> Sorry for the delay in providing more information.  The only method I had to
> transfer test kernels onto the Q40 was painfully slow and involved swapping
> ISA cards which is itself problematic as the pins in one of the ISA slots are
> breaking.
>
> In the end I decided my best option was to dispose of the standard operating
> system (SMSQ/E) and write a new boot ROM for the machine with support for
> FAT32 filesystems on an IDE disk and TFTP transfers using an NE2000 card.
> It's still in development but is now working well enough to use. The source
> code is at https://github.com/willsowerbutts/q40boot
>
> During the process I learned a bit more about the Q40 hardware, and
> transferring a kernel now takes 7 seconds instead of over 20 minutes.
>
> I've run the various tests as requested;
>
> * 5.13.19 -- IDE works (but the data on disk is byte-swapped, see below)
>
> * 5.13.19+44b1fbc0f5f30e66a56d29575349f0b1ebe2b0ee -- IDE fails (crash)
>
> * 5.14.21 -- IDE fails (crash)
>
> * 6.4.10 + Michael's RFC patch -- IDE fails (no crash, but "Bad IO access")

That might be fixed by my second RFC patch, just gone out today.

This one still byte-swaps the data from disk though. I understood that 
was always the case for Q40, but I may have been mistaken there.

>
> * 6.4.10 + my patch -- IDE works, data on disk is NOT byte-swapped
>
> Copies of the boot output for each kernel are attached to this email.
>
> I've also attached the patch I am currently using on my Q40 kernel. It's
> based in part on Michael's patch. It bodges up "ioport_map" to apply the
> offset required to convert raw ISA address into "cookies" and thus allow the
> IDE to work without "Bad IO" complaints. To be crystal clear I am NOT
> proposing this as a solution, it's obviously a hack job, but I wanted to
> illustrate at least one way that *does* work on the Q40.
Yep, my patch is also just meant to find a way to make the driver work 
at all, and then do it again properly (perhaps using 
CONFIG_HAS_IOPORT_MAP).
>
> I think one proper solution might involve enabling CONFIG_HAS_IOPORT_MAP but
> I've not yet looked properly into the implications of doing so. I'm very open
> to alternative solutions too.
>
> As a side note, the NE2000 driver, which is also using 8- and 16-bit ISA I/O,
> works correctly with both 5.13 and 6.4. If one allows it to auto-probe the
> card's interrupt it locks up the machine due to limitations of the interrupt
> controller, but I understand this was always the case; I've made a tiny patch
> to ne.c to prevent it trying this.
I've had autoprobe lockups (rather, interrupts coming in before 
interrupt handling was set up) with ne.c and the ROM port adapter, which 
does not use interrupts. Might be easier to load this driver as a 
module. This may not be an option if you boot the kernel from the 
network card.
>
>
> On Tue, Jul 25, 2023 at 08:26:28AM +1200, Michael Schmitz wrote:
>> Note that this also means that the address hardcoded for IDE may be
>> incorrect (AFAIR, IDE cards could have their IO base reassigned by
>> firmware).
> The W83757 on my ISA IO card, and the W83787IF on the ISA IO card that
> shipped with the machine, are configurable only using jumpers. They can only
> use the two standard base addresses (0x1F0 or 0x170).
>
>
> On Fri, Jul 28, 2023 at 9:52 AM Michael Schmitz <schmitzmic@gmail.com> wrote:
>> Yes, but Q40 and Falcon are impossible to support any other way, and
>> byte swapping the IDE interface in hardware was never repeated anywhere
>> else, fortunately. We will have to keep pata_falcon around for that
>> cause in any event.
> I wonder if this is a misunderstanding about Q40 IDE.
>
> The Q40 does not have an on-board IDE controller.  IDE is accessed via a
> common ISA PC Super-IO card.  When you do a 16-bit transfer from the ISA I/O
> address the data comes out backwards and the CPU needs to byteswap it.
>
> I found it interesting and quite unexpected that 5.13 read data from the IDE
> drive byte-swapped.  I had prepared a drive for the machine with an MBR
> partition table and an ext4 filesystem but the kernel did not recognise
> either.  After a while I realised I had to byte swap the entire drive with
> 'dd conv=swab', and then it worked.
>
> For my 6.4 patch I enabled byte swapping in the pata_falcon_data_xfer()
> function -- this allows me to use an IDE drive with everything in the
> normal/compatible byte ordering, which makes life much easier. I assume this
> is the intended behaviour.
That would be the sane behaviour, but the designers of both the Falcon 
and apparently the TiVo decided otherwise, wired up the IDE data bus 
byte-swapped and saved the byteswap operations in the driver. I'm unsure 
how this was intended to work on Q40.
> I wonder if any existing Q40 users are actually storing all the data on their
> drives byte-swapped just to avoid the overhead of byte-swapping on every
> read/write. I suppose this would work just fine until you need to connect
> that drive to another machine.

Yes, it does work just fine with that little inconvenience. (When I had 
to fix a corrupted partition table an FAT, I had to hook the Falcon disk 
up to a PC and run ARAnyM on it to get byte-swapped access to the data.)

Now the question is how data on legacy Q40 IDE disks have been stored. 
If it's byte-swapped, we'd better keep that byte order in the current 
driver (meaning your changes to pata_falcon_data_xfer() won't be needed, 
but you would have to swap back data on your disk). If it's always been 
in PC compatible byte order, all data (not just the identify data) must 
be swapped.

I'd like to have Richard's opinion on this (or hear from any other 
former Q40 user).

>
> For my Q40boot ROM I wrote an IDE driver. It just treats the IDE interface as
> a regular legacy PC style IDE interface (which is exactly what it is!) plus
> byte swapping of 16-bit transfers. See the functions q40_ide_read_sector_data
> and q40_ide_write_sector_data in the IDE driver (q40ide.c, q40isa.h in the
> q40boot github repository linked above).
>
> I am going to look at the pata_legacy driver and see if it might be usable on
> the Q40 instead of pata_falcon.
>
> As a long term fix I think I need to read up on CONFIG_HAS_IOPORT_MAP to try
> and understand how I might enable this.  I expect enabling it will have
> implications for all M68K machines, so maybe someone with more experience
> should be making that decision.
>
> I would be very happy to run further tests or to rewrite my hacky patch in
> response to pointers on how to improve it.

If you test my RFC v2 patch, do remember to change 
pata_falcon_data_xfer() to swap all data. I'll have a look at your patch 
to see whether there's anything else I missed or misunderstood.

If you want to handle patch submission yourself, please by all means do 
so. I cannot test any of the Q40 changes, only make sure none of the 
changes modify driver behaviour on Falcon.

Cheers,

     Michael


>
> Thanks
>
> Will
>
>
>
> On Sun, Aug 13, 2023 at 05:38:00PM +1000, Finn Thain wrote:
>> Michael, William,
>>
>> On Sun, 13 Aug 2023, Michael Schmitz wrote:
>>
>>> Am 28.07.23 um 11:47 schrieb Finn Thain:
>>>> On Thu, 27 Jul 2023, Michael Schmitz wrote:
>>>>
>>>>>>> And yes, I'm painfully aware the m68k low level IO code is becoming
>>>>>>> a bit of a maintainance legacy, in no small part due to my hacks
>>>>>>> around Atari EtherNEC.
>>>>>>>
>>>>>> I guess you and I both can share the blame for 44b1fbc0f5f30e66...
>>>>>>
>>>>>> Anyway, you make a good point about on-going maintenance. Do you
>>>>>> think that by supporting standard ISA drivers we might actually
>>>>>> reduce the ideosyncracies in m68k IO code?
>>>>> You and DaveM ought to have a chat about that - abstracting the
>>>>> legacy drivers from the ISA constraints was his preferred option when
>>>>> I last attempted to get the Gayle network driver patches merged. When
>>>>> I say 'preferred', I'm probably understating a little.
>>>>>
>>>> A discussion with maintainers probably won't get far without working
>>>> code to look at. Perhaps William will send an RFC patch to illustrate
>>>> his approach.
>>> Haven't seen anything yet, so I've just sent a patch switching
>>> pata_falcon.c to use the IO resources instead of the memory resources.
>> Thanks for sending that.
>>
>>> Survived compile and ARAnyM boot tests only so far. I've checked and
>>> confirmed the entire 0xffxxxxx range is mapped transparent in head.S for
>>> Q40 so I don't see what else might be missing.
>>>
>> In the message that Geert originally forwarded, William was quoted as
>> saying it was necessary to "fix up the pata_falcon_data_xfer function". He
>> also said that using the IO port resources "causes the ioread8/iowrite8
>> functions to complain loudly".
>> https://lore.kernel.org/linux-m68k/CAMuHMdUU62jjunJh9cqSqHT87B0H0A4udOOPs=WN7WZKpcagVA@mail.gmail.com/
>>
>> I think your patch is taking the same approach and may run into the same
>> issues... I guess we shall see when William tests it.
>>
>>> Please have a look and test if possible. Haven't yet bothered
>>> linux-block or linux-ide... the patch still needs a Fixes: and other
>>> trimmings so isn't ready for submission anyway.
>>>
>> Right. You'll want to run checkpatch.pl on it at some stage.
> _________________________________________________________________________
> William R Sowerbutts                                  will@sowerbutts.com
> "Carpe post meridiem"                               http://sowerbutts.com
>           main(){char*s=">#=0> ^#X@#@^7=",c=0,m;for(;c<15;c++)for
>           (m=-1;m<7;putchar(m++/6&c%3/2?10:s[c]-31&1<<m?42:32));}
>

Re: Linux 6.4.4 on m68k - Q40 - pata_falcon causes oops at boot time

[Finn Thain]

[-- Attachment #1: Type: text/plain, Size: 3426 bytes --]

On Mon, 14 Aug 2023, Michael Schmitz wrote:

> > On Fri, Jul 28, 2023 at 9:52 AM Michael Schmitz <schmitzmic@gmail.com> 
> > wrote:
> >> Yes, but Q40 and Falcon are impossible to support any other way, and 
> >> byte swapping the IDE interface in hardware was never repeated 
> >> anywhere else, fortunately. We will have to keep pata_falcon around 
> >> for that cause in any event.
> > I wonder if this is a misunderstanding about Q40 IDE.
> >
> > The Q40 does not have an on-board IDE controller.  IDE is accessed via 
> > a common ISA PC Super-IO card.  When you do a 16-bit transfer from the 
> > ISA I/O address the data comes out backwards and the CPU needs to 
> > byteswap it.
> >
> > I found it interesting and quite unexpected that 5.13 read data from 
> > the IDE drive byte-swapped.  I had prepared a drive for the machine 
> > with an MBR partition table and an ext4 filesystem but the kernel did 
> > not recognise either.  After a while I realised I had to byte swap the 
> > entire drive with 'dd conv=swab', and then it worked.
> >
> > For my 6.4 patch I enabled byte swapping in the 
> > pata_falcon_data_xfer() function -- this allows me to use an IDE drive 
> > with everything in the normal/compatible byte ordering, which makes 
> > life much easier. I assume this is the intended behaviour.
> That would be the sane behaviour, but the designers of both the Falcon 
> and apparently the TiVo decided otherwise, wired up the IDE data bus 
> byte-swapped and saved the byteswap operations in the driver. I'm unsure 
> how this was intended to work on Q40.

Why did Atari do that? Was it because they wanted to interoperate with 
exotic filesystems (i.e. Microsoft) without paying a byte swapping tax in 
software? (Despite the 68000 instructions for that purpose.)

> > I wonder if any existing Q40 users are actually storing all the data 
> > on their drives byte-swapped just to avoid the overhead of 
> > byte-swapping on every read/write. I suppose this would work just fine 
> > until you need to connect that drive to another machine.
> 
> Yes, it does work just fine with that little inconvenience. (When I had 
> to fix a corrupted partition table an FAT, I had to hook the Falcon disk 
> up to a PC and run ARAnyM on it to get byte-swapped access to the data.)
> 
> Now the question is how data on legacy Q40 IDE disks have been stored. 
> If it's byte-swapped, we'd better keep that byte order in the current 
> driver (meaning your changes to pata_falcon_data_xfer() won't be needed, 
> but you would have to swap back data on your disk). If it's always been 
> in PC compatible byte order, all data (not just the identify data) must 
> be swapped.
> 
> I'd like to have Richard's opinion on this (or hear from any other 
> former Q40 user).
> 

Yes.

If the Linux port for Q40 could use pata_legacy unmodified, that has to be 
more maintainable. However, I could imagine a scenario where the standard 
Q40 firmware, bootloader and/or vendor operating system would cease to 
interoperate with Linux if Linux has no byteswapping IDE driver. If true, 
would it matter?

Unix has a long tradition of pushing the byteswapping problem onto 
userland for those who need to migrate data. Hence tools like cpio and dd 
which are able to do byteswapping. One has to wonder whether drivers and 
peripherals are the wrong places for that.

Re: Linux 6.4.4 on m68k - Q40 - pata_falcon causes oops at boot time

[Michael Schmitz]

Hi Finn,

On 14/08/23 11:37, Finn Thain wrote:
>
>>> The Q40 does not have an on-board IDE controller.  IDE is accessed via
>>> a common ISA PC Super-IO card.  When you do a 16-bit transfer from the
>>> ISA I/O address the data comes out backwards and the CPU needs to
>>> byteswap it.
>>>
>>> I found it interesting and quite unexpected that 5.13 read data from
>>> the IDE drive byte-swapped.  I had prepared a drive for the machine
>>> with an MBR partition table and an ext4 filesystem but the kernel did
>>> not recognise either.  After a while I realised I had to byte swap the
>>> entire drive with 'dd conv=swab', and then it worked.
>>>
>>> For my 6.4 patch I enabled byte swapping in the
>>> pata_falcon_data_xfer() function -- this allows me to use an IDE drive
>>> with everything in the normal/compatible byte ordering, which makes
>>> life much easier. I assume this is the intended behaviour.
>> That would be the sane behaviour, but the designers of both the Falcon
>> and apparently the TiVo decided otherwise, wired up the IDE data bus
>> byte-swapped and saved the byteswap operations in the driver. I'm unsure
>> how this was intended to work on Q40.
> Why did Atari do that? Was it because they wanted to interoperate with
> exotic filesystems (i.e. Microsoft) without paying a byte swapping tax in
> software? (Despite the 68000 instructions for that purpose.)

Interoperability cannot have been a concern - otherwise they would have 
made sure the on-disk format was compatible. Saving a byte swap 
operation for each word transferred must have seemed worth it.

They just took what was available in terms of hard drive interfaces 
(SCSI as well as IDE). IDE was 16 bytes wide, and the drive identify 
data were ending up in the 'wrong' byte order, so they just swapped 
those data.

As far as I know, neither floppy nor disk FAT formats are 100% identical 
to the PC ones, just somewhat compatible.

>
>>> I wonder if any existing Q40 users are actually storing all the data
>>> on their drives byte-swapped just to avoid the overhead of
>>> byte-swapping on every read/write. I suppose this would work just fine
>>> until you need to connect that drive to another machine.
>> Yes, it does work just fine with that little inconvenience. (When I had
>> to fix a corrupted partition table an FAT, I had to hook the Falcon disk
>> up to a PC and run ARAnyM on it to get byte-swapped access to the data.)
>>
>> Now the question is how data on legacy Q40 IDE disks have been stored.
>> If it's byte-swapped, we'd better keep that byte order in the current
>> driver (meaning your changes to pata_falcon_data_xfer() won't be needed,
>> but you would have to swap back data on your disk). If it's always been
>> in PC compatible byte order, all data (not just the identify data) must
>> be swapped.
>>
>> I'd like to have Richard's opinion on this (or hear from any other
>> former Q40 user).
>>
> Yes.
>
> If the Linux port for Q40 could use pata_legacy unmodified, that has to be
> more maintainable. However, I could imagine a scenario where the standard
> Q40 firmware, bootloader and/or vendor operating system would cease to
> interoperate with Linux if Linux has no byteswapping IDE driver. If true,
> would it matter?

I use the Atari TOS partition that the Falcon boots into to run the boot 
loader from, and I transfer kernels to that partition from Linux using 
the vfat file system (after copying them to the Linux partition over 
ethernet). That would all break without a byte swapping IDE driver.

Something similar may be true for Q40 users, but there can't be many of 
these left, otherwise I'd have expected to hear about the broken 
pata_falcon issue a lot sooner.

> Unix has a long tradition of pushing the byteswapping problem onto
> userland for those who need to migrate data. Hence tools like cpio and dd
> which are able to do byteswapping. One has to wonder whether drivers and
> peripherals are the wrong places for that.

Probably not - in that regard, not caring about the on-disk format might 
even be the Right Thing to do.

I suspect there's a way to do byte swapping on the fly using a loopback 
device and some dm magic, so disks with the 'wrong' byte order could be 
accessed on non-native systems. I just have never been bothered enough 
about the issue to find out.

Most other Falcon users might use SCSI (and SCSI-SD adapters) to 
transport data between systems. Not an option for Q40.

Cheers,

     Michael

Re: Linux 6.4.4 on m68k - Q40 - pata_falcon causes oops at boot time

[Finn Thain]

On Mon, 14 Aug 2023, Michael Schmitz wrote:

> 
> Most other Falcon users might use SCSI (and SCSI-SD adapters) to 
> transport data between systems. Not an option for Q40.
> 

Well, it could be of some help inasmuchas we still support a number of ISA 
SCSI host adapters. I wonder whether the Q40 ROM, bootloader or vendor 
software etc. has any support for SCSI cards (with no byteswapping)...

Re: Linux 6.4.4 on m68k - Q40 - pata_falcon causes oops at boot time

[Michael Schmitz]

Hi Finn,

Am 14.08.2023 um 13:15 schrieb Finn Thain:
>
> On Mon, 14 Aug 2023, Michael Schmitz wrote:
>
>>
>> Most other Falcon users might use SCSI (and SCSI-SD adapters) to
>> transport data between systems. Not an option for Q40.
>>
>
> Well, it could be of some help inasmuchas we still support a number of ISA
> SCSI host adapters. I wonder whether the Q40 ROM, bootloader or vendor
> software etc. has any support for SCSI cards (with no byteswapping)...

The issue of byte swapping does not arise for SCSI AFAIR (most host 
adapters used on these systems are narrow so disk byte order is 
preserved, and byte swapping happens at the filesystem level if need be. 
Byte order for wide adapters may be possible to set by the host).

SCSI support came as third party drivers for Atari, I suspect it's been 
the same for Q40.

Cheers,

	Michael

Re: Linux 6.4.4 on m68k - Q40 - pata_falcon causes oops at boot time

[William R Sowerbutts]

[-- Attachment #1: Type: text/plain, Size: 2619 bytes --]

On Mon, Aug 14, 2023 at 10:54:54AM +1200, Michael Schmitz wrote:
>On 14/08/23 10:24, William R Sowerbutts wrote:
>> * 6.4.10 + Michael's RFC patch -- IDE fails (no crash, but "Bad IO 
>> access")
>
>That might be fixed by my second RFC patch, just gone out today.

6.4.10 + your "RFC v2" patch boots without the "Bad IO access" errors!

Your patch looks correct to me.

>This one still byte-swaps the data from disk though. I understood that was
>always the case for Q40, but I may have been mistaken there.

It is indeed returning byte-swapped data.  This is easily fixed, I'm using
the attached patch.

>> For my 6.4 patch I enabled byte swapping in the pata_falcon_data_xfer()
>> function -- this allows me to use an IDE drive with everything in the
>> normal/compatible byte ordering, which makes life much easier. I assume this
>> is the intended behaviour.
>That would be the sane behaviour, but the designers of both the Falcon and
>apparently the TiVo decided otherwise, wired up the IDE data bus byte-swapped
>and saved the byteswap operations in the driver. I'm unsure how this was
>intended to work on Q40.

The Q40 does NOT have hardware to reverse the byte-swapping.  The CPU has to 
byte-swap data if you want to use disks with standard/compatible data.

>Now the question is how data on legacy Q40 IDE disks have been stored. If
>it's byte-swapped, we'd better keep that byte order in the current driver
>(meaning your changes to pata_falcon_data_xfer() won't be needed, but you
>would have to swap back data on your disk). If it's always been in PC
>compatible byte order, all data (not just the identify data) must be swapped.
>
>I'd like to have Richard's opinion on this (or hear from any other former Q40
>user).

I have learned that the "standard" firmware for the Q40, SMSQ/E, does not 
byte-swap data (it also uses an obscure partition scheme and filesystem).

Personally, I am strongly in favour of Linux on the Q40 using standard 
byte-order disks that are compatible with other machines. This feels like the 
right thing to do and it is what I think most users would expect.

Users (if there are any!) with legacy byte-swapped disks can always use the 
standard tools to byte swap them into the correct, compatible format.

Thanks

Will

_________________________________________________________________________
William R Sowerbutts                                  will@sowerbutts.com
"Carpe post meridiem"                               http://sowerbutts.com
         main(){char*s=">#=0> ^#X@#@^7=",c=0,m;for(;c<15;c++)for
         (m=-1;m<7;putchar(m++/6&c%3/2?10:s[c]-31&1<<m?42:32));}  


[-- Attachment #2: pata_falcon-q40-byteswap.patch --]
[-- Type: text/x-diff, Size: 431 bytes --]

--- linux-6.4.10+michael-rfc2/drivers/ata/pata_falcon.c.orig	2023-08-14 11:21:48.636681174 +0100
+++ linux-6.4.10+michael-rfc2/drivers/ata/pata_falcon.c	2023-08-14 11:34:17.244301035 +0100
@@ -48,7 +48,7 @@
 	struct scsi_cmnd *cmd = qc->scsicmd;
 	bool swap = 1;
 
-	if (dev->class == ATA_DEV_ATA && cmd &&
+	if (!MACH_IS_Q40 && dev->class == ATA_DEV_ATA && cmd &&
 	    !blk_rq_is_passthrough(scsi_cmd_to_rq(cmd)))
 		swap = 0;
 

Re: Linux 6.4.4 on m68k - Q40 - pata_falcon causes oops at boot time

[Michael Schmitz]

Hi William,

On 14/08/23 23:18, William R Sowerbutts wrote:
> On Mon, Aug 14, 2023 at 10:54:54AM +1200, Michael Schmitz wrote:
>> On 14/08/23 10:24, William R Sowerbutts wrote:
>>> * 6.4.10 + Michael's RFC patch -- IDE fails (no crash, but "Bad IO
>>> access")
>> That might be fixed by my second RFC patch, just gone out today.
> 6.4.10 + your "RFC v2" patch boots without the "Bad IO access" errors!
>
> Your patch looks correct to me.
Thanks - I'll look into whether we can use CONFIG_HAS_IOPORT_MAP without 
any ill effects now (or wheher our own ioport_map() must be modified to 
add the IO token on Q40).
>
>> This one still byte-swaps the data from disk though. I understood that was
>> always the case for Q40, but I may have been mistaken there.
> It is indeed returning byte-swapped data.  This is easily fixed, I'm using
> the attached patch.
>
>>> For my 6.4 patch I enabled byte swapping in the pata_falcon_data_xfer()
>>> function -- this allows me to use an IDE drive with everything in the
>>> normal/compatible byte ordering, which makes life much easier. I assume this
>>> is the intended behaviour.
>> That would be the sane behaviour, but the designers of both the Falcon and
>> apparently the TiVo decided otherwise, wired up the IDE data bus byte-swapped
>> and saved the byteswap operations in the driver. I'm unsure how this was
>> intended to work on Q40.
> The Q40 does NOT have hardware to reverse the byte-swapping.  The CPU has to
> byte-swap data if you want to use disks with standard/compatible data.
I understand that - the issue was (and is) whether byte swapping by CPU 
is required in order to support legacy disks, or not.
>
>> Now the question is how data on legacy Q40 IDE disks have been stored. If
>> it's byte-swapped, we'd better keep that byte order in the current driver
>> (meaning your changes to pata_falcon_data_xfer() won't be needed, but you
>> would have to swap back data on your disk). If it's always been in PC
>> compatible byte order, all data (not just the identify data) must be swapped.
>>
>> I'd like to have Richard's opinion on this (or hear from any other former Q40
>> user).
> I have learned that the "standard" firmware for the Q40, SMSQ/E, does not
> byte-swap data (it also uses an obscure partition scheme and filesystem).
Thanks, that's what I was worried about.
> Personally, I am strongly in favour of Linux on the Q40 using standard
> byte-order disks that are compatible with other machines. This feels like the
> right thing to do and it is what I think most users would expect.
Yes, but ...
>
> Users (if there are any!) with legacy byte-swapped disks can always use the
> standard tools to byte swap them into the correct, compatible format.

That would make these disks impossible to use by the default firmware 
though.

As ugly as it may be, I think we'll need a module parameter (or Q40 boot 
option) to switch the driver to legacy disk mode here. That could be 
always set for Falcon, and set on demand for Q40 so we save the 
MACH_IS_Q40 test on each data transfer.

Cheers,

     Michael

>
> Thanks
>
> Will
>
> _________________________________________________________________________
> William R Sowerbutts                                  will@sowerbutts.com
> "Carpe post meridiem"                               http://sowerbutts.com
>           main(){char*s=">#=0> ^#X@#@^7=",c=0,m;for(;c<15;c++)for
>           (m=-1;m<7;putchar(m++/6&c%3/2?10:s[c]-31&1<<m?42:32));}
>

Re: Linux 6.4.4 on m68k - Q40 - pata_falcon causes oops at boot time

[Richard Z]

On August 14, 2023 8:15:53 PM UTC, Michael Schmitz <schmitzmic@gmail.com> wrote:
>Hi William,
>
>On 14/08/23 23:18, William R Sowerbutts wrote:
>> On Mon, Aug 14, 2023 at 10:54:54AM +1200, Michael Schmitz wrote:
>>> On 14/08/23 10:24, William R Sowerbutts wrote:
>>>> * 6.4.10 + Michael's RFC patch -- IDE fails (no crash, but "Bad IO
>>>> access")
>>> That might be fixed by my second RFC patch, just gone out today.
>> 6.4.10 + your "RFC v2" patch boots without the "Bad IO access" errors!
>> 
>> Your patch looks correct to me.
>Thanks - I'll look into whether we can use CONFIG_HAS_IOPORT_MAP without any ill effects now (or wheher our own ioport_map() must be modified to add the IO token on Q40).
>> 
>>> This one still byte-swaps the data from disk though. I understood that was
>>> always the case for Q40, but I may have been mistaken there.
>> It is indeed returning byte-swapped data.  This is easily fixed, I'm using
>> the attached patch.
>> 
>>>> For my 6.4 patch I enabled byte swapping in the pata_falcon_data_xfer()
>>>> function -- this allows me to use an IDE drive with everything in the
>>>> normal/compatible byte ordering, which makes life much easier. I assume this
>>>> is the intended behaviour.
>>> That would be the sane behaviour, but the designers of both the Falcon and
>>> apparently the TiVo decided otherwise, wired up the IDE data bus byte-swapped
>>> and saved the byteswap operations in the driver. I'm unsure how this was
>>> intended to work on Q40.
>> The Q40 does NOT have hardware to reverse the byte-swapping.  The CPU has to
>> byte-swap data if you want to use disks with standard/compatible data.
>I understand that - the issue was (and is) whether byte swapping by CPU is required in order to support legacy disks, or not.
>> 
>>> Now the question is how data on legacy Q40 IDE disks have been stored. If
>>> it's byte-swapped, we'd better keep that byte order in the current driver
>>> (meaning your changes to pata_falcon_data_xfer() won't be needed, but you
>>> would have to swap back data on your disk). If it's always been in PC
>>> compatible byte order, all data (not just the identify data) must be swapped.
>>> 
>>> I'd like to have Richard's opinion on this (or hear from any other former Q40
>>> user).
>> I have learned that the "standard" firmware for the Q40, SMSQ/E, does not
>> byte-swap data (it also uses an obscure partition scheme and filesystem).
>Thanks, that's what I was worried about.
>> Personally, I am strongly in favour of Linux on the Q40 using standard
>> byte-order disks that are compatible with other machines. This feels like the
>> right thing to do and it is what I think most users would expect.
>Yes, but ...
>> 
>> Users (if there are any!) with legacy byte-swapped disks can always use the
>> standard tools to byte swap them into the correct, compatible format.
>
>That would make these disks impossible to use by the default firmware though.
>
>As ugly as it may be, I think we'll need a module parameter (or Q40 boot option) to switch the driver to legacy disk mode here. That could be always set for Falcon, and set on demand for Q40 so we save the MACH_IS_Q40 test on each data transfer.

Well ideally it would be a per-device option. This would help the ide SD cards greatly and people could byte swap their devices one at a time.

Richard 

Re: Linux 6.4.4 on m68k - Q40 - pata_falcon causes oops at boot time

[Finn Thain]

On Mon, 14 Aug 2023, Richard Z wrote:

> 
> Well ideally it would be a per-device option. This would help the ide SD 
> cards greatly and people could byte swap their devices one at a time.
> 

Would a byte-swapping IDE cable help, e.g. if the same flash memory card 
was moved from an IDE interface to a SCSI interface (on the same Q40)?

Perhaps we should not worry too much about unusual use-cases during what 
would be a temporary transition period...

> Think of it, if you want to boot an older kernel you don't want to 
> byteswap your whole hard disk back and forth every time when testing an 
> older or newer kernel.

Probably not an issue for end-users, as they are more likely to boot an 
old userland together with an old kernel. But potentially an issue for 
kernel developers who need to mix new kernels with old userland. However, 
kernel developers can use out-of-tree code to help with their testing, as 
usual.

Re: Linux 6.4.4 on m68k - Q40 - pata_falcon causes oops at boot time

[Richard Z]

On August 14, 2023 11:31:36 PM UTC, Finn Thain <fthain@linux-m68k.org> wrote:
>
>On Mon, 14 Aug 2023, Richard Z wrote:
>
>> 
>> Well ideally it would be a per-device option. This would help the ide SD 
>> cards greatly and people could byte swap their devices one at a time.
>> 
>
>Would a byte-swapping IDE cable help, e.g. if the same flash memory card 
>was moved from an IDE interface to a SCSI interface (on the same Q40)?

The Q40 doesn't have SCSI. The only issue is exchanging devices with other computers.

Byteswapping cable would help the performance but will also swap the ide ident string so the kernel must take that into account.

>
>Perhaps we should not worry too much about unusual use-cases during what 
>would be a temporary transition period...


You are right, there are sure many other ways to solve the issue with SD cards.

>> Think of it, if you want to boot an older kernel you don't want to 
>> byteswap your whole hard disk back and forth every time when testing an 
>> older or newer kernel.
>
>Probably not an issue for end-users, as they are more likely to boot an 
>old userland together with an old kernel. But potentially an issue for 
>kernel developers who need to mix new kernels with old userland. However, 
>kernel developers can use out-of-tree code to help with their testing, as 
>usual.

Just don't think this transition is worth it if it will make everything more complicated and noticeably slower. 

Richard

Re: Linux 6.4.4 on m68k - Q40 - pata_falcon causes oops at boot time

[Michael Schmitz]

Hi Richard,

Am 15.08.2023 um 15:05 schrieb Richard Z:
>
>
> On August 14, 2023 11:31:36 PM UTC, Finn Thain <fthain@linux-m68k.org> wrote:
>>
>> On Mon, 14 Aug 2023, Richard Z wrote:
>>
>>>
>>> Well ideally it would be a per-device option. This would help the ide SD
>>> cards greatly and people could byte swap their devices one at a time.
>>>
>>
>> Would a byte-swapping IDE cable help, e.g. if the same flash memory card
>> was moved from an IDE interface to a SCSI interface (on the same Q40)?
>
> The Q40 doesn't have SCSI. The only issue is exchanging devices with other computers.

You could plug one of the old ISA SCSI host adapters into an ISA slot 
(assuming there's more than one).

> Byteswapping cable would help the performance but will also swap the ide ident string so the kernel must take that into account.

That's what pata_falcon does already - 'swap' is true by default to make 
that happen, and gets set to false if data are transfered.

>
>>
>> Perhaps we should not worry too much about unusual use-cases during what
>> would be a temporary transition period...
>
>
> You are right, there are sure many other ways to solve the issue with SD cards.
>
>>> Think of it, if you want to boot an older kernel you don't want to
>>> byteswap your whole hard disk back and forth every time when testing an
>>> older or newer kernel.
>>
>> Probably not an issue for end-users, as they are more likely to boot an
>> old userland together with an old kernel. But potentially an issue for
>> kernel developers who need to mix new kernels with old userland. However,
>> kernel developers can use out-of-tree code to help with their testing, as
>> usual.
>
> Just don't think this transition is worth it if it will make everything more complicated and noticeably slower.

The problem here is that we'd already done the transition to libata / 
pata_falcon and the old IDE code has been removed. Q40 IDE was broken in 
the process.

We need to fix pata_falcon for Q40, and with data on William's disk in 
little endian order, but data on other users' disks in big endian order, 
we need to come up with a way to support both for now.

Cheers,

	Michael

>
> Richard
>

Re: Linux 6.4.4 on m68k - Q40 - pata_falcon causes oops at boot time

[William R Sowerbutts]

>We need to fix pata_falcon for Q40, and with data on William's disk in 
>little endian order, but data on other users' disks in big endian order, we 
>need to come up with a way to support both for now.

I don't mind if you break my disk -- I can always byte-swap it if required,
or patch my kernel to use my preferred byte ordering.

Valid points have been made about needing to keep existing disks working.  

For the kernel driver to switch byte order after some specific version seems
unexpected.

On the other hand, having disks compatible with other systems is important, 
and as a naive new user the byte-swapped disk format was quite unexpected to 
me.

It seems there are reasonable arguments for both sides.

I had a cursory look through other drivers and could not find any that make 
byte ordering a user-selectable option.  Is there any precedent for this?  It 
would be interesting to learn how they exposed the option to the user.

I'm not clear if pata_falcon on Atari records data on disk in normal or 
swapped byte order.  Can I take a drive from my Atari Falcon Linux machine 
and connect it to a PC without needing to byte swap it?

I want to float some potential solutions for discussion;

 * Add a kernel configuration option to choose between legacy and compatible 
   byte ordering on Q40 at compile time (affecting all disks)
 
 * Add a pata_falcon driver option to choose which of the connected disks 
   should use legacy or compatible byte ordering at run time

 * Extend pata_falcon to examine the connected disk's contents, looking for 
   some marker that reliably indicates a legacy byte order disk is connected.  
   Default to compatible byte ordering if this mark is not found.  Maybe it 
   would be cleaner for some optional module atop the driver to do this.

 * Assuming pata_legacy can be made to work well: Have pata_falcon retain 
   legacy byte ordering, while pata_legacy drives the same hardware in 
   compatible byte ordering mode.  User chooses the driver to choose byte 
   ordering.

 * Switch pata_falcon to compatible byte order, document for any legacy disk 
   users how they can either do a one-time migration of their data to 
   compatible format, or setup the block layer to do byte swapping 
   on-the-fly.

Thanks

Will

_________________________________________________________________________
William R Sowerbutts                                  will@sowerbutts.com
"Carpe post meridiem"                               http://sowerbutts.com
         main(){char*s=">#=0> ^#X@#@^7=",c=0,m;for(;c<15;c++)for
         (m=-1;m<7;putchar(m++/6&c%3/2?10:s[c]-31&1<<m?42:32));}  

Re: Linux 6.4.4 on m68k - Q40 - pata_falcon causes oops at boot time

[Geert Uytterhoeven]

Hi William,

On Tue, Aug 15, 2023 at 11:49 AM William R Sowerbutts
<will@sowerbutts.com> wrote:
> >We need to fix pata_falcon for Q40, and with data on William's disk in
> >little endian order, but data on other users' disks in big endian order, we
> >need to come up with a way to support both for now.
>
> I don't mind if you break my disk -- I can always byte-swap it if required,
> or patch my kernel to use my preferred byte ordering.
>
> Valid points have been made about needing to keep existing disks working.
>
> For the kernel driver to switch byte order after some specific version seems
> unexpected.
>
> On the other hand, having disks compatible with other systems is important,
> and as a naive new user the byte-swapped disk format was quite unexpected to
> me.
>
> It seems there are reasonable arguments for both sides.
>
> I had a cursory look through other drivers and could not find any that make
> byte ordering a user-selectable option.  Is there any precedent for this?  It
> would be interesting to learn how they exposed the option to the user.

IIRC, the consensus was to not add any more byteswapping _options_
to IDE drivers.  Just make sure the driver returns all data in host order.
The IDE core will take care of converting the drive identification from
little to native endian when needed (see swap_buf_le16()).

Note that "data" means both the drive identification block (as read
from the drive's firmware), as user data (as stored on the platters).
Hence if the interface is byte-swapped, the driver must swap all data
read, to make sure the drive identification block is correct.

Now, if your native (non-Linux) OS byte-swapped only the drive
identification block, but not the user data, you have an incompatibility.
Solving that is meant to be handled through a byte-swapping md layer
(although I can't seem to find that anymore?).

Gr{oetje,eeting}s,

                        Geert

-- 
Geert Uytterhoeven -- There's lots of Linux beyond ia32 -- geert@linux-m68k.org

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

Re: Linux 6.4.4 on m68k - Q40 - pata_falcon causes oops at boot time

[Richard Z]

On August 15, 2023 10:42:02 AM UTC, Geert Uytterhoeven <geert@linux-m68k.org> wrote:
>Hi William,
>
>On Tue, Aug 15, 2023 at 11:49 AM William R Sowerbutts
><will@sowerbutts.com> wrote:
>> >We need to fix pata_falcon for Q40, and with data on William's disk in
>> >little endian order, but data on other users' disks in big endian order, we
>> >need to come up with a way to support both for now.
>>
>> I don't mind if you break my disk -- I can always byte-swap it if required,
>> or patch my kernel to use my preferred byte ordering.
>>
>> Valid points have been made about needing to keep existing disks working.
>>
>> For the kernel driver to switch byte order after some specific version seems
>> unexpected.
>>
>> On the other hand, having disks compatible with other systems is important,
>> and as a naive new user the byte-swapped disk format was quite unexpected to
>> me.
>>
>> It seems there are reasonable arguments for both sides.
>>
>> I had a cursory look through other drivers and could not find any that make
>> byte ordering a user-selectable option.  Is there any precedent for this?  It
>> would be interesting to learn how they exposed the option to the user.
>
>IIRC, the consensus was to not add any more byteswapping _options_
>to IDE drivers.  Just make sure the driver returns all data in host order.
>The IDE core will take care of converting the drive identification from
>little to native endian when needed (see swap_buf_le16()).
>

The more important consensus says don't break things so whoever removed the hdX=bswap option should have implemented it in some other way. However there was very little to zero practical use for this at the time that happened so I can understand why it didn't happen.

>Now, if your native (non-Linux) OS byte-swapped only the drive
>identification block, but not the user data, you have an incompatibility.
>Solving that is meant to be handled through a byte-swapping md layer
>(although I can't seem to find that anymore?).
>

There was some talk about it but iirc it was never implemented.


Richard 

Re: Linux 6.4.4 on m68k - Q40 - pata_falcon causes oops at boot time

[Michael Schmitz]

Hi William,

On 15/08/23 21:49, William R Sowerbutts wrote:
>> We need to fix pata_falcon for Q40, and with data on William's disk in
>> little endian order, but data on other users' disks in big endian order, we
>> need to come up with a way to support both for now.
> I don't mind if you break my disk -- I can always byte-swap it if required,
> or patch my kernel to use my preferred byte ordering.
>
> Valid points have been made about needing to keep existing disks working.
>
> For the kernel driver to switch byte order after some specific version seems
> unexpected.
>
> On the other hand, having disks compatible with other systems is important,
> and as a naive new user the byte-swapped disk format was quite unexpected to
> me.
>
> It seems there are reasonable arguments for both sides.
>
> I had a cursory look through other drivers and could not find any that make
> byte ordering a user-selectable option.  Is there any precedent for this?  It
> would be interesting to learn how they exposed the option to the user.
As Geert explained, it was agreed by the IDE maintainers that any data 
byte order fixup needed would be handled in the block layer, and 
existing byte swapping options were removed as a result (as far as I 
recall, that was only ever necessary for Falcon and Q40).
> I'm not clear if pata_falcon on Atari records data on disk in normal or
> swapped byte order.  Can I take a drive from my Atari Falcon Linux machine
> and connect it to a PC without needing to byte swap it?
No, such a disk can only be read on a PC when running ARAnyM (where the 
m68k Linux kernel then handles the necessary fixup). Data are in the 
wrong byte order when hooking up a Falcon IDE disk to a PC.
>
> I want to float some potential solutions for discussion;
>
>   * Add a kernel configuration option to choose between legacy and compatible
>     byte ordering on Q40 at compile time (affecting all disks)
That's easiest ...
>   * Add a pata_falcon driver option to choose which of the connected disks
>     should use legacy or compatible byte ordering at run time
I'm trying to do that at present. I don't expect that to fly with the 
IDE or block maintainers though (for afore mentioned reasons).
>   * Extend pata_falcon to examine the connected disk's contents, looking for
>     some marker that reliably indicates a legacy byte order disk is connected.
>     Default to compatible byte ordering if this mark is not found.  Maybe it
>     would be cleaner for some optional module atop the driver to do this.
Your only hope for this is to get such autodetection into the Atari 
partition table code. It has no place in a device driver. As far as the 
device driver is concerned, a disk is just a bag of bytes, no structure. 
You'd then have to communicate the result back to user space. If you 
have enough RAM to first boot into an initrd that can then sort out what 
byte order to use for the root filesystem, this may work. I've only got 
14 MB, so won't be able to test such a scheme.
>   * Assuming pata_legacy can be made to work well: Have pata_falcon retain
>     legacy byte ordering, while pata_legacy drives the same hardware in
>     compatible byte ordering mode.  User chooses the driver to choose byte
>     ordering.
That could be a way out, but this applies to both disk either way. You 
can't have one driver handle drive 1, the other drive 2.
>   * Switch pata_falcon to compatible byte order, document for any legacy disk
>     users how they can either do a one-time migration of their data to
>     compatible format, or setup the block layer to do byte swapping
>     on-the-fly.

'compatible byte order' would have to be the byte order used by the 
native OS here. Meaning we pretty much do nothing, just use my latest 
RFC patch.

As Geert also pointed out, the block layer mechanism to effect byte 
swapping an entire disk or any partition appears to have been lost. This 
has to be revived before we can think about compatibility schemes.

Cheers,

     Michael


>
> Thanks
>
> Will
>
> _________________________________________________________________________
> William R Sowerbutts                                  will@sowerbutts.com
> "Carpe post meridiem"                               http://sowerbutts.com
>           main(){char*s=">#=0> ^#X@#@^7=",c=0,m;for(;c<15;c++)for
>           (m=-1;m<7;putchar(m++/6&c%3/2?10:s[c]-31&1<<m?42:32));}
>

Re: Linux 6.4.4 on m68k - Q40 - pata_falcon causes oops at boot time

[William R Sowerbutts]

>As Geert explained, it was agreed by the IDE maintainers that any data byte
>order fixup needed would be handled in the block layer, and existing byte
>swapping options were removed as a result (as far as I recall, that was only
>ever necessary for Falcon and Q40).

Sensible

>> I'm not clear if pata_falcon on Atari records data on disk in normal or
>> swapped byte order.  Can I take a drive from my Atari Falcon Linux machine
>> and connect it to a PC without needing to byte swap it?
>No, such a disk can only be read on a PC when running ARAnyM (where the m68k
>Linux kernel then handles the necessary fixup). Data are in the wrong byte
>order when hooking up a Falcon IDE disk to a PC.

Interesting -- thank you

>'compatible byte order' would have to be the byte order used by the native 
>OS here. Meaning we pretty much do nothing, just use my latest RFC patch.

I agree

Will

_________________________________________________________________________
William R Sowerbutts                                  will@sowerbutts.com
"Carpe post meridiem"                               http://sowerbutts.com
         main(){char*s=">#=0> ^#X@#@^7=",c=0,m;for(;c<15;c++)for
         (m=-1;m<7;putchar(m++/6&c%3/2?10:s[c]-31&1<<m?42:32));}  

Re: Linux 6.4.4 on m68k - Q40 - pata_falcon causes oops at boot time

[Michael Schmitz]

Hi Will,

On 16/08/23 10:10, William R Sowerbutts wrote:
>> As Geert explained, it was agreed by the IDE maintainers that any data byte
>> order fixup needed would be handled in the block layer, and existing byte
>> swapping options were removed as a result (as far as I recall, that was only
>> ever necessary for Falcon and Q40).
> Sensible
>
>>> I'm not clear if pata_falcon on Atari records data on disk in normal or
>>> swapped byte order.  Can I take a drive from my Atari Falcon Linux machine
>>> and connect it to a PC without needing to byte swap it?
>> No, such a disk can only be read on a PC when running ARAnyM (where the m68k
>> Linux kernel then handles the necessary fixup). Data are in the wrong byte
>> order when hooking up a Falcon IDE disk to a PC.
> Interesting -- thank you
>
>> 'compatible byte order' would have to be the byte order used by the native
>> OS here. Meaning we pretty much do nothing, just use my latest RFC patch.

I've sent a v3 of my patch which adds a module option to select which 
drive will get extra byte swapping on data transfers. Please give that a 
try. So far tested on ARAnyM with one Atari and one Mac disk image (the 
latter of which would have needed byte swapping by ARAnyM before, and 
can now be read without that trick).

If that works, I'd send this patch to linux-ide for review (split in two 
parts, the first as the minimal bugfix to restore Q40 support, the 
second as optional data portability feature on top).

Cheers,

     Michael


> I agree
>
> Will
>
> _________________________________________________________________________
> William R Sowerbutts                                  will@sowerbutts.com
> "Carpe post meridiem"                               http://sowerbutts.com
>           main(){char*s=">#=0> ^#X@#@^7=",c=0,m;for(;c<15;c++)for
>           (m=-1;m<7;putchar(m++/6&c%3/2?10:s[c]-31&1<<m?42:32));}
>

Re: Linux 6.4.4 on m68k - Q40 - pata_falcon causes oops at boot time

[Richard Z]

On August 14, 2023 7:52:18 PM UTC, Richard Z <rz@linux-m68k.org> wrote:
>
>
>On August 14, 2023 11:18:44 AM UTC, William R Sowerbutts <will@sowerbutts.com> wrote:
>>On Mon, Aug 14, 2023 at 10:54:54AM +1200, Michael Schmitz wrote:
>>>On 14/08/23 10:24, William R Sowerbutts wrote:
>>>> * 6.4.10 + Michael's RFC patch -- IDE fails (no crash, but "Bad IO 
>>>> access")
>>>
>>>That might be fixed by my second RFC patch, just gone out today.
>>
>>6.4.10 + your "RFC v2" patch boots without the "Bad IO access" errors!
>>
>>Your patch looks correct to me.
>>
>>>This one still byte-swaps the data from disk though. I understood that was
>>>always the case for Q40, but I may have been mistaken there.
>>
>>It is indeed returning byte-swapped data.  This is easily fixed, I'm using
>>the attached patch.
>>
>>>> For my 6.4 patch I enabled byte swapping in the pata_falcon_data_xfer()
>>>> function -- this allows me to use an IDE drive with everything in the
>>>> normal/compatible byte ordering, which makes life much easier. I assume this
>>>> is the intended behaviour.
>>>That would be the sane behaviour, but the designers of both the Falcon and
>>>apparently the TiVo decided otherwise, wired up the IDE data bus byte-swapped
>>>and saved the byteswap operations in the driver. I'm unsure how this was
>>>intended to work on Q40.
>>
>>The Q40 does NOT have hardware to reverse the byte-swapping.  The CPU has to 
>>byte-swap data if you want to use disks with standard/compatible data.
>>
>>>Now the question is how data on legacy Q40 IDE disks have been stored. If
>>>it's byte-swapped, we'd better keep that byte order in the current driver
>>>(meaning your changes to pata_falcon_data_xfer() won't be needed, but you
>>>would have to swap back data on your disk). If it's always been in PC
>>>compatible byte order, all data (not just the identify data) must be swapped.
>>>
>>>I'd like to have Richard's opinion on this (or hear from any other former Q40
>>>user).
>>
>>I have learned that the "standard" firmware for the Q40, SMSQ/E, does not 
>>byte-swap data (it also uses an obscure partition scheme and filesystem).

It doesn't use any obscure partition scheme, just the Atari partition table. It used to require some special magic word but the kernel code and all Linux tools would work just like if it was a normal Atari partition table. I have only modified atari-fdisik to add that magic number if it wasn't there yet to make original firmware happy.


>>
>>Personally, I am strongly in favour of Linux on the Q40 using standard 
>>byte-order disks that are compatible with other machines. This feels like the 
>>right thing to do and it is what I think most users would expect.
>>
>>Users (if there are any!) with legacy byte-swapped disks can always use the 
>>standard tools to byte swap them into the correct, compatible format.

Most users that I know have a dual boot system so this won't work until the other available OSes are modified to support byte swapping. This would be doable but the problem is for quite some time the kernel would have to understand both variants. Think of it, if you want to boot an older kernel you don't want to byteswap your whole hard disk back and forth every time when testing an older or newer kernel. Also, I would like to see data on the speed impact of the byte swapping, making the old hardware even 5% slower isn't something I would be enthusiastic about and my guess is it would more than that.

Other than that it would be nice to use the "normal" byte order because exchangeable devices became much more common, I do even have an SD card reader on the IDE port.


Richard 

Re: Linux 6.4.4 on m68k - Q40 - pata_falcon causes oops at boot time

[Michael Schmitz]

Hi Richard,

thanks for chiming in!

On 15/08/23 08:19, Richard Z wrote:
>
>>>> Now the question is how data on legacy Q40 IDE disks have been stored. If
>>>> it's byte-swapped, we'd better keep that byte order in the current driver
>>>> (meaning your changes to pata_falcon_data_xfer() won't be needed, but you
>>>> would have to swap back data on your disk). If it's always been in PC
>>>> compatible byte order, all data (not just the identify data) must be swapped.
>>>>
>>>> I'd like to have Richard's opinion on this (or hear from any other former Q40
>>>> user).
>>> I have learned that the "standard" firmware for the Q40, SMSQ/E, does not
>>> byte-swap data (it also uses an obscure partition scheme and filesystem).
> It doesn't use any obscure partition scheme, just the Atari partition table. It used to require some special magic word but the kernel code and all Linux tools would work just like if it was a normal Atari partition table. I have only modified atari-fdisik to add that magic number if it wasn't there yet to make original firmware happy.
Ah, thanks for pointing that out. Should have remembered it used Atari 
format partitioning.
>>> Personally, I am strongly in favour of Linux on the Q40 using standard
>>> byte-order disks that are compatible with other machines. This feels like the
>>> right thing to do and it is what I think most users would expect.
>>>
>>> Users (if there are any!) with legacy byte-swapped disks can always use the
>>> standard tools to byte swap them into the correct, compatible format.
> Most users that I know have a dual boot system so this won't work until the other available OSes are modified to support byte swapping. This would be doable but the problem is for quite some time the kernel would have to understand both variants. Think of it, if you want to boot an older kernel you don't want to byteswap your whole hard disk back and forth every time when testing an older or newer kernel. Also, I would like to see data on the speed impact of the byte swapping, making the old hardware even 5% slower isn't something I would be enthusiastic about and my guess is it would more than that.
Well, the inner loop of raw_insw() uses one movew whereas 
raw_insw_swapw() uses two movew and one rolw instruction. Reading or 
writing huge files that are contiguous on disk will show an impact. 
Random access of small files does have higher overhead both in waiting 
for disk latency and buffer cache/filesystem overhead. I'm sure it can 
be measured at least for the first case.
> Other than that it would be nice to use the "normal" byte order because exchangeable devices became much more common, I do even have an SD card reader on the IDE port.

I need to get one of those for tests - I have a CF adapter (which is 
basically IDE passed through to the card) but those cards are harder to 
get.

I'll think about your suggestion to make the byteswap option a 
per-device choice. It does make perfect sense for data exchange but this 
could be handled at block device level, not driver level and I fear Jens 
or whoever has to sign off on this patch will see it that way.

Cheers,

     Michael


>
> Richard

Re: Linux 6.4.4 on m68k - Q40 - pata_falcon causes oops at boot time

[William R Sowerbutts]

>> Also, I would like to see data on the speed impact of the byte swapping, 
>> making the old hardware even 5% slower isn't something I would be 
>> enthusiastic about and my guess is it would more than that.
>Well, the inner loop of raw_insw() uses one movew whereas raw_insw_swapw()
>uses two movew and one rolw instruction. Reading or writing huge files that
>are contiguous on disk will show an impact. Random access of small files does
>have higher overhead both in waiting for disk latency and buffer
>cache/filesystem overhead. I'm sure it can be measured at least for the first
>case.

I've run some tests on my Q40 (40MHz 68040), using 6.4.10 plus Michael's RFC2 
patch. I added a little tweak to pata_falcon_data_xfer() to force byte 
swapping for one specific device only (this allowed me to avoid byte swapping 
the slave IDE drive, which holds my root filesystem).

        if(MACH_IS_Q40 && qc->dev->devno == 0)
            swap = 0; // or 1, for the second test

I booted up the kernel and then timed reading the entire contents of a 2GB 
"InnoDisk Corp. iCF 4000" compact flash card using dd.

With no CPU byteswapping (legacy byte ordering) -- 1308.72 seconds:

# date; time dd if=/dev/sda bs=256k of=/dev/null; date
Tue Aug 15 11:07:19 UTC 2023
7999+1 records in
7999+1 records out
0.40user 1236.33system 21:48.72elapsed 94%CPU (0avgtext+0avgdata 1088maxresident)k
0inputs+0outputs (0major+115minor)pagefaults 0swaps
Tue Aug 15 11:29:08 UTC 2023

With CPU byteswapping (compatible byte ordering) -- 1426.46 seconds:

# date; time dd if=/dev/sda bs=256k of=/dev/null; date
Tue Aug 15 11:30:52 UTC 2023
7999+1 records in
7999+1 records out
0.42user 1348.82system 23:46.46elapsed 94%CPU (0avgtext+0avgdata 1088maxresident)k
0inputs+0outputs (0major+115minor)pagefaults 0swaps
Tue Aug 15 11:54:39 UTC 2023

So it is nearly 9% slower for very large data transfers.

Thanks

Will

_________________________________________________________________________
William R Sowerbutts                                  will@sowerbutts.com
"Carpe post meridiem"                               http://sowerbutts.com
         main(){char*s=">#=0> ^#X@#@^7=",c=0,m;for(;c<15;c++)for
         (m=-1;m<7;putchar(m++/6&c%3/2?10:s[c]-31&1<<m?42:32));}  

Re: Linux 6.4.4 on m68k - Q40 - pata_falcon causes oops at boot time

[William R Sowerbutts]

[-- Attachment #1: Type: text/plain, Size: 1623 bytes --]

On Sun, Aug 13, 2023 at 11:24:20PM +0100, William R Sowerbutts wrote:
>I am going to look at the pata_legacy driver and see if it might be usable 
>on the Q40 instead of pata_falcon.
>
>As a long term fix I think I need to read up on CONFIG_HAS_IOPORT_MAP to try 
>and understand how I might enable this.  I expect enabling it will have
>implications for all M68K machines, so maybe someone with more experience 
>should be making that decision.

Enabling CONFIG_HAS_IOPORT_MAP for the Q40 turned out to be simple.  Attached 
is the patch I am using -- it just sets NO_IOPORT_MAP=n when Q40 is enabled.

Enabling CONFIG_HAS_IOPORT_MAP allows pata_legacy to work on the Q40 with no 
further changes!

pata_legacy drives the IDE interface perfectly.  The data is byte swapped, so 
I think pata_falcon still has a place for Q40 users who want to use legacy 
reverse-byte-order disks.

I tested bulk transfer performance (exactly the same way as I tested 
pata_falcon with and without byte swapping); pata_legacy performs much the 
same as pata_falcon with byte swapping enabled (as one might expect).

I suppose the next step is to build a kernel supporting both Q40 and perhaps 
Atari, then test this in ARAnyM.  I'll try this out over the next few days.

Thanks

Will

_________________________________________________________________________
William R Sowerbutts                                  will@sowerbutts.com
"Carpe post meridiem"                               http://sowerbutts.com
         main(){char*s=">#=0> ^#X@#@^7=",c=0,m;for(;c<15;c++)for
         (m=-1;m<7;putchar(m++/6&c%3/2?10:s[c]-31&1<<m?42:32));}  


[-- Attachment #2: linux-6.4.10-q40-ioport.patch --]
[-- Type: text/x-diff, Size: 953 bytes --]

diff -urN linux-6.4.10.orig/arch/m68k/include/asm/kmap.h linux-6.4.10.q40/arch/m68k/include/asm/kmap.h
--- linux-6.4.10.orig/arch/m68k/include/asm/kmap.h	2023-08-11 11:14:29.000000000 +0100
+++ linux-6.4.10.q40/arch/m68k/include/asm/kmap.h	2023-08-16 00:34:12.894812394 +0100
@@ -58,6 +58,7 @@
 
 #endif /* CONFIG_MMU */
 
+#ifndef CONFIG_HAS_IOPORT_MAP
 #define ioport_map ioport_map
 static inline void __iomem *ioport_map(unsigned long port, unsigned int nr)
 {
@@ -68,5 +69,6 @@
 static inline void ioport_unmap(void __iomem *p)
 {
 }
+#endif /* CONFIG_HAS_IOPORT_MAP */
 
 #endif /* _KMAP_H */
diff -urN linux-6.4.10.orig/arch/m68k/Kconfig linux-6.4.10.q40/arch/m68k/Kconfig
--- linux-6.4.10.orig/arch/m68k/Kconfig	2023-08-11 11:14:29.000000000 +0100
+++ linux-6.4.10.q40/arch/m68k/Kconfig	2023-08-16 00:27:50.044269922 +0100
@@ -61,7 +61,8 @@
 	default y
 
 config NO_IOPORT_MAP
-	def_bool y
+        bool
+        default !Q40
 
 config HZ
 	int

Re: Linux 6.4.4 on m68k - Q40 - pata_falcon causes oops at boot time

[Geert Uytterhoeven]

CC rz, to make him aware of this thread

On Wed, Jul 26, 2023 at 10:13 PM Michael Schmitz <schmitzmic@gmail.com> wrote:
> On 26/07/23 21:22, Finn Thain wrote:
> >>> There are two ISA slots where all other I/O devices are connected. These are
> >>> described (concisely!) on page 7 of the linked manual:
> >>>
> >>> 8-bit ISA I/O cycles are performed for CPU byte accesses to 0xFF400001 + 4 *
> >>> ISA address
> >>>
> >>> 16-bit ISA I/O cycles are performed for CPU word accesses to 0xFF400000 + 4
> >>> * ISA address
> >>>
> >>> 8-bit ISA memory cycles are performed for CPU byte accesses to 0xFF800001 +
> >>> 4 * ISA address
> >>>
> >>> 16-bit ISA memory cycles are performed for CPU word accesses to 0xFF800000 +
> >>> 4 * ISA address
> >> Yep, that much is evident from the Q40 address translation scheme. But a
> >> similar sort of scheme is used on other m68k platforms to wire up
> >> peripherals that were originally designed for Intel systems, and these
> >> are not connected through an ISA bus.
> > I can't figure out why those platforms don't suffer from the same "double
> > translation" problem that William described on q40.
>
> There are only two other address translation schemes in effect - Amiga
> Gayle, which handles byte/word address offsets, and gets passed IO
> addresses (in the sense that these are the addresses where registers are
> mapped in memory), and Atari EtherNEC, which handles IO ports (from the
> ne.c legacy ISA driver).
>
> The Gayle address translation, taking MMIO addresses does not add an IO
> base address. The EtherNEC address translation, OTOH, takes IO ports and
> must add the ROM port base address as IO base.
>
> What I did not realize at the time I rewrote the Q40 driver as platform
> driver is that the old driver used IO ports, not MMIO addresses. In
> order to reserve the IDE register area (we don't have a MMIO area
> corresponding to the IO ports range mapped on m68k), I did add the Q40
> ISA base address to the IO port range to populate the platform memory
> resources, forgetting that the same base address is then added a second
> time through the IO address translation.
>
> Seeing as the address passed into address translation already has the IO
> base offset of 0xff400000 and register scaling of 4 applied, it could be
> sufficient to change the address translations to only add the additional
> IO mem offset of 0x00400000:
>
> #define q40_io_mem_offset 0x00400000
>
> #define Q40_ISA_IO_B(ioaddr) ((unsigned long)(ioaddr))
> #define Q40_ISA_IO_W(ioaddr) ((unsigned long)(ioaddr))
> #define Q40_ISA_MEM_B(madr)  (q40_io_mem_offset + ((unsigned long)(madr)))
> #define Q40_ISA_MEM_W(madr)  (q40_io_mem_offset + ((unsigned long)(madr)))
>
> Note that this will play havoc with all other ISA drivers on Q40, so I'd
> just suggest that to test my hypothesis about how the address
> translation affects the IDE IO.
>
>
> A correct fix would keep the current IO translation intact, and instead
> use the platform mem resource to register the driver IO range, and the
> platform IO resource as base offset to populate the port ioaddr struct
> (minus the register scaling and byte offset, mind you).
>
> I'll give this some more thought ASAP.
>
> And yes, I'm painfully aware the m68k low level IO code is becoming a
> bit of a maintainance legacy, in no small part due to my hacks around
> Atari EtherNEC.

Gr{oetje,eeting}s,

                        Geert

-- 
Geert Uytterhoeven -- There's lots of Linux beyond ia32 -- geert@linux-m68k.org

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