Hi Masahiro,
I can confirm as well, that your patch
linux/export: fix reference to exported functions for parisc64
does indeed fix the boot issue on parisc64.
I did tested it on a C3000 workstation on top of Linus' v6.6-rc1 git tree.
You may add:
Tested-by: Helge Deller <[email protected]>
Dave, I don't see the issue you mention below...
Helge
On 9/10/23 23:30, John David Anglin wrote:
> Hi Masahiro,
>
> The attached change fixed boot at ddb5cdbafaaa ????
>
> However, v6.5.x boot is still broken:
>
> Run /init as init process
> process '/usr/bin/sh' started with executable stack
> Loading, please wait...
> Starting systemd-udevd version 254.1-3
> e1000 alternatives: applied 0 out of 569 patches
> e1000: Intel(R) PRO/1000 Network Driver
> e1000: Copyright (c) 1999-2006 Intel Corporation.
> scsi_mod alternatives: applied 0 out of 7 patches
> SCSI subsystem initialized
> usbcore alternatives: applied 0 out of 18 patches
> usbcore: registered new interface driver usbfs
> libata alternatives: applied 0 out of 3 patches
> usbcore: registered new interface driver hub
> usbcore: registered new device driver usb
> mptbase alternatives: applied 0 out of 73 patches
> ehci_hcd alternatives: applied 0 out of 114 patches
> sata_sil24 alternatives: applied 0 out of 56 patches
> Fusion MPT base driver 3.04.20
> Copyright (c) 1999-2008 LSI Corporation
> sata_sil24 0000:00:01.0: Applying completion IRQ loss on PCI-X errata fix
> scsi host0: sata_sil24
> scsi host1: sata_sil24
> pata_sil680 0000:60:02.0: sil680: 133MHz clock.
> scsi host2: sata_sil24
> ehci_pci alternatives: applied 0 out of 2 patches
> ohci_hcd alternatives: applied 0 out of 144 patches
> ehci-pci 0000:60:01.2: EHCI Host Controller
> scsi host3: pata_sil680
> ehci-pci 0000:60:01.2: new USB bus registered, assigned bus number 1
> scsi host4: sata_sil24
> ata1: SATA max UDMA/100 host m128@0xffffffff80088000 port 0xffffffff80080000 ir6
> ata2: SATA max UDMA/100 host m128@0xffffffff80088000 port 0xffffffff80082000 ir6
> ata3: SATA max UDMA/100 host m128@0xffffffff80088000 port 0xffffffff80084000 ir6
> ata4: SATA max UDMA/100 host m128@0xffffffff80088000 port 0xffffffff80086000 ir6
> e1000 0000:60:03.0 eth0: (PCI:33MHz:32-bit) 00:11:0a:31:8a:77
> ehci-pci 0000:60:01.2: irq 71, io mem 0xffffffffb00a1000
> scsi host5: pata_sil680
> ata5: PATA max UDMA/133 cmd 0x26058 ctl 0x26064 bmdma 0x26040 irq 72
> ata6: PATA max UDMA/133 cmd 0x26050 ctl 0x26060 bmdma 0x26048 irq 72
> e1000 0000:60:03.0 eth0: Intel(R) PRO/1000 Network Connection
> ehci-pci 0000:60:01.2: USB 2.0 started, EHCI 0.95
> usb usb1: New USB device found, idVendor=1d6b, idProduct=0002, bcdDevice= 6.05
> usb usb1: New USB device strings: Mfr=3, Product=2, SerialNumber=1
> usb usb1: Product: EHCI Host Controller
> usb usb1: Manufacturer: Linux 6.5.2-dirty ehci_hcd
> usb usb1: SerialNumber: 0000:60:01.2
> hub 1-0:1.0: USB hub found
> hub 1-0:1.0: 5 ports detected
> ata1: SATA link down (SStatus 0 SControl 0)
> ata2: SATA link down (SStatus 0 SControl 0)
> ata3: SATA link down (SStatus 0 SControl 0)
> ata4: SATA link up 3.0 Gbps (SStatus 123 SControl 0)
> ata4.00: ATA-10: ST4000VN008-2DR166, SC60, max UDMA/133
> ata4.00: 7814037168 sectors, multi 0: LBA48 NCQ (depth 31/32)
> ata4.00: configured for UDMA/100
> scsi 4:0:0:0: Direct-Access ATA ST4000VN008-2DR1 SC60 PQ: 0 ANSI: 5
> ata6.00: ATAPI: HL-DT-STDVD+-RW GSA-H21L, 1.04, max UDMA/44
> scsi 5:0:0:0: CD-ROM HL-DT-ST DVD+-RW GSA-H21L 1.04 PQ: 0 ANSI: 5
> random: crng init done
> Timed out for waiting the udev queue being empty.
> Begin: Loading essential drivers ... done.
> Begin: Running /scripts/init-premount ... done.
> Begin: Mounting root file system ... Begin: Running /scripts/local-top ... done.
> Begin: Running /scripts/local-premount ... done.
> Timed out for waiting the udev queue being empty.
> Begin: Waiting for root file system ... Begin: Running /scripts/local-block ....
> Begin: Running /scripts/local-block ... done.
> Begin: Running /scripts/local-block ... done.
> Begin: Running /scripts/local-block ... done.
> Begin: Running /scripts/local-block ... done.
> Begin: Running /scripts/local-block ... done.
> Begin: Running /scripts/local-block ... done.
> Begin: Running /scripts/local-block ... done.
> Begin: Running /scripts/local-block ... done.
> Begin: Running /scripts/local-block ... done.
> Begin: Running /scripts/local-block ... done.
> Begin: Running /scripts/local-block ... done.
> Begin: Running /scripts/local-block ... done.
> Begin: Running /scripts/local-block ... done.
> Begin: Running /scripts/local-block ... done.
> Begin: Running /scripts/local-block ... done.
> Begin: Running /scripts/local-block ... done.
> Begin: Running /scripts/local-block ... done.
> Begin: Running /scripts/local-block ... done.
> done.
> Gave up waiting for root file system device. Common problems:
> - Boot args (cat /proc/cmdline)
> - Check rootdelay= (did the system wait long enough?)
> - Missing modules (cat /proc/modules; ls /dev)
> ALERT! LABEL=ROOT does not exist. Dropping to a shell!
> Rebooting automatically due to panic= boot argument
>
> I'll see if I can find the commit that breaks 6.5.
>
> Thanks,
> Dave
>
> On 2023-09-10 3:47 a.m., Masahiro Yamada wrote:
>> Hi John, Helge,
>>
>> Could you test the attached patch please?
>>
>>
>> Again, I only tested compilation for this.
>> I do not have parisc64 hardware.
>> In my understanding, QEMU does not support hppa64.
>> I do not find a way to test parisc64.
>>
>>
>> Masahiro Yamada
>>
>>
>>
>>
>>
>> On Sun, Sep 10, 2023 at 4:20 AM Masahiro Yamada <[email protected]> wrote:
>>> With a little more investigation,
>>> I found arch/parisc/kernel/parisc_ksyms.c
>>> is causing the issue.
>>>
>>> That file is a collection of EXPORT_SYMBOL
>>> of assembly code.
>>>
>>> I will take a closer look tomorrow.
>>>
>>>
>>>
>>>
>>>
>>>
>>>
>>>
>>>
>>>
>>>
>>> On Sun, Sep 10, 2023 at 2:20 AM Masahiro Yamada <[email protected]> wrote:
>>>> On Fri, Sep 8, 2023 at 7:02 AM John David Anglin <[email protected]> wrote:
>>>>> On 2023-09-05 7:59 p.m., John David Anglin wrote:
>>>>>> On 2023-09-05 5:57 p.m., John David Anglin wrote:
>>>>>>> I'll check ddb5cdbafaaa.
>>>>>> Similar fault with ddb5cdbafaaa:
>>>>> The alignment of the __kstrtab_ symbols in vmlinux seems wrong.
>>>> __kstrtab_ symbols do not need alignment.
>>>>
>>>> They were not aligned at all
>>>> before ddb5cdbafaaa^.
>>>>
>>>>
>>>>
>>>>> I'm fairly certain that function
>>>>> references prefixed with P% on hppa64 need 8 byte alignment.
>>>> Yeah.
>>>> In the following dump, all of __ksymtab_* are correctly 8-byte aligned.
>>>>
>>>>
>>>>> 81662: 0000000040ea4358 0 NOTYPE LOCAL DEFAULT 16 __kstrtab_system[...]
>>>>> 81663: 0000000040ea4748 0 NOTYPE LOCAL DEFAULT 16 __kstrtabns_syst[...]
>>>>> 81664: 0000000040e8e830 0 NOTYPE LOCAL DEFAULT 14 __ksymtab_system[...]
>>>>> 81665: 0000000040ea4365 0 NOTYPE LOCAL DEFAULT 16 __kstrtab_static[...]
>>>>> 81666: 0000000040ea4748 0 NOTYPE LOCAL DEFAULT 16 __kstrtabns_stat[...]
>>>>> 81667: 0000000040ea1640 0 NOTYPE LOCAL DEFAULT 15 __ksymtab_static[...]
>>>>> 81668: 0000000040ea437c 0 NOTYPE LOCAL DEFAULT 16 __kstrtab_reset_[...]
>>>>> 81669: 0000000040ea4748 0 NOTYPE LOCAL DEFAULT 16 __kstrtabns_rese[...]
>>>>> 81670: 0000000040e8bbc0 0 NOTYPE LOCAL DEFAULT 14 __ksymtab_reset_[...]
>>>>> 81671: 0000000040ea438a 0 NOTYPE LOCAL DEFAULT 16 __kstrtab_loops_[...]
>>>>> 81672: 0000000040ea4748 0 NOTYPE LOCAL DEFAULT 16 __kstrtabns_loop[...]
>>>>> 81673: 0000000040e86610 0 NOTYPE LOCAL DEFAULT 14 __ksymtab_loops_[...]
>>>>> 81674: 0000000040ea439a 0 NOTYPE LOCAL DEFAULT 16 __kstrtab_init_uts_ns
>>>>> 81675: 0000000040ea4748 0 NOTYPE LOCAL DEFAULT 16 __kstrtabns_init[...]
>>>>> 81676: 0000000040e99180 0 NOTYPE LOCAL DEFAULT 15 __ksymtab_init_uts_ns
>>>>> 81677: 0000000040ea43a6 0 NOTYPE LOCAL DEFAULT 16 __kstrtab_name_t[...]
>>>>> 81678: 0000000040ea4748 0 NOTYPE LOCAL DEFAULT 16 __kstrtabns_name[...]
>>>>> 81679: 0000000040e9b340 0 NOTYPE LOCAL DEFAULT 15 __ksymtab_name_t[...]
>>>>> 81680: 0000000040ea43b4 0 NOTYPE LOCAL DEFAULT 16 __kstrtab_wait_f[...]
>>>>> 81681: 0000000040ea4748 0 NOTYPE LOCAL DEFAULT 16 __kstrtabns_wait[...]
>>>>> 81682: 0000000040ea3638 0 NOTYPE LOCAL DEFAULT 15 __ksymtab_wait_f[...]
>>>>> 81683: 0000000040ea43c7 0 NOTYPE LOCAL DEFAULT 16 __kstrtab_init_task
>>>>> [...]
>>>>>
>>>>> I'm not sure how we get symbols that aren't 8 byte aligned. The ".balign 4" directive
>>>>> in __KSYMTAB doesn't seem correct but it's not the whole problem.
>>>>>
>>>>> Dave
Hi Helge,
It occurs consistently on my c8000 but I'm having difficulty bisecting it. Trying a bisect
with --first-parent.
Note I had to pull ATI graphics card from the machine as it started to malfunction causing crashes.
However, v6.1.52 boots fine.
Dave
On 2023-09-12 9:01 a.m., Helge Deller wrote:
> Hi Masahiro,
>
> I can confirm as well, that your patch
> linux/export: fix reference to exported functions for parisc64
> does indeed fix the boot issue on parisc64.
>
> I did tested it on a C3000 workstation on top of Linus' v6.6-rc1 git tree.
> You may add:
> Tested-by: Helge Deller <[email protected]>
>
> Dave, I don't see the issue you mention below...
>
> Helge
>
> On 9/10/23 23:30, John David Anglin wrote:
>> Hi Masahiro,
>>
>> The attached change fixed boot at ddb5cdbafaaa ????
>>
>> However, v6.5.x boot is still broken:
>>
>> Run /init as init process
>> process '/usr/bin/sh' started with executable stack
>> Loading, please wait...
>> Starting systemd-udevd version 254.1-3
>> e1000 alternatives: applied 0 out of 569 patches
>> e1000: Intel(R) PRO/1000 Network Driver
>> e1000: Copyright (c) 1999-2006 Intel Corporation.
>> scsi_mod alternatives: applied 0 out of 7 patches
>> SCSI subsystem initialized
>> usbcore alternatives: applied 0 out of 18 patches
>> usbcore: registered new interface driver usbfs
>> libata alternatives: applied 0 out of 3 patches
>> usbcore: registered new interface driver hub
>> usbcore: registered new device driver usb
>> mptbase alternatives: applied 0 out of 73 patches
>> ehci_hcd alternatives: applied 0 out of 114 patches
>> sata_sil24 alternatives: applied 0 out of 56 patches
>> Fusion MPT base driver 3.04.20
>> Copyright (c) 1999-2008 LSI Corporation
>> sata_sil24 0000:00:01.0: Applying completion IRQ loss on PCI-X errata fix
>> scsi host0: sata_sil24
>> scsi host1: sata_sil24
>> pata_sil680 0000:60:02.0: sil680: 133MHz clock.
>> scsi host2: sata_sil24
>> ehci_pci alternatives: applied 0 out of 2 patches
>> ohci_hcd alternatives: applied 0 out of 144 patches
>> ehci-pci 0000:60:01.2: EHCI Host Controller
>> scsi host3: pata_sil680
>> ehci-pci 0000:60:01.2: new USB bus registered, assigned bus number 1
>> scsi host4: sata_sil24
>> ata1: SATA max UDMA/100 host m128@0xffffffff80088000 port 0xffffffff80080000 ir6
>> ata2: SATA max UDMA/100 host m128@0xffffffff80088000 port 0xffffffff80082000 ir6
>> ata3: SATA max UDMA/100 host m128@0xffffffff80088000 port 0xffffffff80084000 ir6
>> ata4: SATA max UDMA/100 host m128@0xffffffff80088000 port 0xffffffff80086000 ir6
>> e1000 0000:60:03.0 eth0: (PCI:33MHz:32-bit) 00:11:0a:31:8a:77
>> ehci-pci 0000:60:01.2: irq 71, io mem 0xffffffffb00a1000
>> scsi host5: pata_sil680
>> ata5: PATA max UDMA/133 cmd 0x26058 ctl 0x26064 bmdma 0x26040 irq 72
>> ata6: PATA max UDMA/133 cmd 0x26050 ctl 0x26060 bmdma 0x26048 irq 72
>> e1000 0000:60:03.0 eth0: Intel(R) PRO/1000 Network Connection
>> ehci-pci 0000:60:01.2: USB 2.0 started, EHCI 0.95
>> usb usb1: New USB device found, idVendor=1d6b, idProduct=0002, bcdDevice= 6.05
>> usb usb1: New USB device strings: Mfr=3, Product=2, SerialNumber=1
>> usb usb1: Product: EHCI Host Controller
>> usb usb1: Manufacturer: Linux 6.5.2-dirty ehci_hcd
>> usb usb1: SerialNumber: 0000:60:01.2
>> hub 1-0:1.0: USB hub found
>> hub 1-0:1.0: 5 ports detected
>> ata1: SATA link down (SStatus 0 SControl 0)
>> ata2: SATA link down (SStatus 0 SControl 0)
>> ata3: SATA link down (SStatus 0 SControl 0)
>> ata4: SATA link up 3.0 Gbps (SStatus 123 SControl 0)
>> ata4.00: ATA-10: ST4000VN008-2DR166, SC60, max UDMA/133
>> ata4.00: 7814037168 sectors, multi 0: LBA48 NCQ (depth 31/32)
>> ata4.00: configured for UDMA/100
>> scsi 4:0:0:0: Direct-Access ATA ST4000VN008-2DR1 SC60 PQ: 0 ANSI: 5
>> ata6.00: ATAPI: HL-DT-STDVD+-RW GSA-H21L, 1.04, max UDMA/44
>> scsi 5:0:0:0: CD-ROM HL-DT-ST DVD+-RW GSA-H21L 1.04 PQ: 0 ANSI: 5
>> random: crng init done
>> Timed out for waiting the udev queue being empty.
>> Begin: Loading essential drivers ... done.
>> Begin: Running /scripts/init-premount ... done.
>> Begin: Mounting root file system ... Begin: Running /scripts/local-top ... done.
>> Begin: Running /scripts/local-premount ... done.
>> Timed out for waiting the udev queue being empty.
>> Begin: Waiting for root file system ... Begin: Running /scripts/local-block ....
>> Begin: Running /scripts/local-block ... done.
>> Begin: Running /scripts/local-block ... done.
>> Begin: Running /scripts/local-block ... done.
>> Begin: Running /scripts/local-block ... done.
>> Begin: Running /scripts/local-block ... done.
>> Begin: Running /scripts/local-block ... done.
>> Begin: Running /scripts/local-block ... done.
>> Begin: Running /scripts/local-block ... done.
>> Begin: Running /scripts/local-block ... done.
>> Begin: Running /scripts/local-block ... done.
>> Begin: Running /scripts/local-block ... done.
>> Begin: Running /scripts/local-block ... done.
>> Begin: Running /scripts/local-block ... done.
>> Begin: Running /scripts/local-block ... done.
>> Begin: Running /scripts/local-block ... done.
>> Begin: Running /scripts/local-block ... done.
>> Begin: Running /scripts/local-block ... done.
>> Begin: Running /scripts/local-block ... done.
>> done.
>> Gave up waiting for root file system device. Common problems:
>> - Boot args (cat /proc/cmdline)
>> - Check rootdelay= (did the system wait long enough?)
>> - Missing modules (cat /proc/modules; ls /dev)
>> ALERT! LABEL=ROOT does not exist. Dropping to a shell!
>> Rebooting automatically due to panic= boot argument
>>
>> I'll see if I can find the commit that breaks 6.5.
>>
>> Thanks,
>> Dave
>>
>> On 2023-09-10 3:47 a.m., Masahiro Yamada wrote:
>>> Hi John, Helge,
>>>
>>> Could you test the attached patch please?
>>>
>>>
>>> Again, I only tested compilation for this.
>>> I do not have parisc64 hardware.
>>> In my understanding, QEMU does not support hppa64.
>>> I do not find a way to test parisc64.
>>>
>>>
>>> Masahiro Yamada
>>>
>>>
>>>
>>>
>>>
>>> On Sun, Sep 10, 2023 at 4:20 AM Masahiro Yamada <[email protected]> wrote:
>>>> With a little more investigation,
>>>> I found arch/parisc/kernel/parisc_ksyms.c
>>>> is causing the issue.
>>>>
>>>> That file is a collection of EXPORT_SYMBOL
>>>> of assembly code.
>>>>
>>>> I will take a closer look tomorrow.
>>>>
>>>>
>>>>
>>>>
>>>>
>>>>
>>>>
>>>>
>>>>
>>>>
>>>>
>>>> On Sun, Sep 10, 2023 at 2:20 AM Masahiro Yamada <[email protected]> wrote:
>>>>> On Fri, Sep 8, 2023 at 7:02 AM John David Anglin <[email protected]> wrote:
>>>>>> On 2023-09-05 7:59 p.m., John David Anglin wrote:
>>>>>>> On 2023-09-05 5:57 p.m., John David Anglin wrote:
>>>>>>>> I'll check ddb5cdbafaaa.
>>>>>>> Similar fault with ddb5cdbafaaa:
>>>>>> The alignment of the __kstrtab_ symbols in vmlinux seems wrong.
>>>>> __kstrtab_ symbols do not need alignment.
>>>>>
>>>>> They were not aligned at all
>>>>> before ddb5cdbafaaa^.
>>>>>
>>>>>
>>>>>
>>>>>> I'm fairly certain that function
>>>>>> references prefixed with P% on hppa64 need 8 byte alignment.
>>>>> Yeah.
>>>>> In the following dump, all of __ksymtab_* are correctly 8-byte aligned.
>>>>>
>>>>>
>>>>>> 81662: 0000000040ea4358 0 NOTYPE LOCAL DEFAULT 16 __kstrtab_system[...]
>>>>>> 81663: 0000000040ea4748 0 NOTYPE LOCAL DEFAULT 16 __kstrtabns_syst[...]
>>>>>> 81664: 0000000040e8e830 0 NOTYPE LOCAL DEFAULT 14 __ksymtab_system[...]
>>>>>> 81665: 0000000040ea4365 0 NOTYPE LOCAL DEFAULT 16 __kstrtab_static[...]
>>>>>> 81666: 0000000040ea4748 0 NOTYPE LOCAL DEFAULT 16 __kstrtabns_stat[...]
>>>>>> 81667: 0000000040ea1640 0 NOTYPE LOCAL DEFAULT 15 __ksymtab_static[...]
>>>>>> 81668: 0000000040ea437c 0 NOTYPE LOCAL DEFAULT 16 __kstrtab_reset_[...]
>>>>>> 81669: 0000000040ea4748 0 NOTYPE LOCAL DEFAULT 16 __kstrtabns_rese[...]
>>>>>> 81670: 0000000040e8bbc0 0 NOTYPE LOCAL DEFAULT 14 __ksymtab_reset_[...]
>>>>>> 81671: 0000000040ea438a 0 NOTYPE LOCAL DEFAULT 16 __kstrtab_loops_[...]
>>>>>> 81672: 0000000040ea4748 0 NOTYPE LOCAL DEFAULT 16 __kstrtabns_loop[...]
>>>>>> 81673: 0000000040e86610 0 NOTYPE LOCAL DEFAULT 14 __ksymtab_loops_[...]
>>>>>> 81674: 0000000040ea439a 0 NOTYPE LOCAL DEFAULT 16 __kstrtab_init_uts_ns
>>>>>> 81675: 0000000040ea4748 0 NOTYPE LOCAL DEFAULT 16 __kstrtabns_init[...]
>>>>>> 81676: 0000000040e99180 0 NOTYPE LOCAL DEFAULT 15 __ksymtab_init_uts_ns
>>>>>> 81677: 0000000040ea43a6 0 NOTYPE LOCAL DEFAULT 16 __kstrtab_name_t[...]
>>>>>> 81678: 0000000040ea4748 0 NOTYPE LOCAL DEFAULT 16 __kstrtabns_name[...]
>>>>>> 81679: 0000000040e9b340 0 NOTYPE LOCAL DEFAULT 15 __ksymtab_name_t[...]
>>>>>> 81680: 0000000040ea43b4 0 NOTYPE LOCAL DEFAULT 16 __kstrtab_wait_f[...]
>>>>>> 81681: 0000000040ea4748 0 NOTYPE LOCAL DEFAULT 16 __kstrtabns_wait[...]
>>>>>> 81682: 0000000040ea3638 0 NOTYPE LOCAL DEFAULT 15 __ksymtab_wait_f[...]
>>>>>> 81683: 0000000040ea43c7 0 NOTYPE LOCAL DEFAULT 16 __kstrtab_init_task
>>>>>> [...]
>>>>>>
>>>>>> I'm not sure how we get symbols that aren't 8 byte aligned. The ".balign 4" directive
>>>>>> in __KSYMTAB doesn't seem correct but it's not the whole problem.
>>>>>>
>>>>>> Dave
>
--
John David Anglin [email protected]
Hi Dave,
On 9/12/23 15:20, John David Anglin wrote:
> It occurs consistently on my c8000 but I'm having difficulty bisecting it. Trying a bisect
> with --first-parent.
I just tried to boot the v6.6-rc1 with Masahiro's patch on c8000, and it succeeds as well.
I've copied my pre-built kernel here:
http://backup.parisc-linux.org/kernel/linux-image-6.6.0-rc1-dirty_6.6.0-rc1-250_hppa.deb
So, I think Masahiro's patch is basically ok and probably isn't the root cause
for your udev issues below.
Did you checked if initramfs included all necessary filesystem modules?
Maybe updating your machine to latest ramfstools and re-installing your kernel?
Helge
> Note I had to pull ATI graphics card from the machine as it started to malfunction causing crashes.
> However, v6.1.52 boots fine.
>
> On 2023-09-12 9:01 a.m., Helge Deller wrote:
>> Hi Masahiro,
>>
>> I can confirm as well, that your patch
>> linux/export: fix reference to exported functions for parisc64
>> does indeed fix the boot issue on parisc64.
>>
>> I did tested it on a C3000 workstation on top of Linus' v6.6-rc1 git tree.
>> You may add:
>> Tested-by: Helge Deller <[email protected]>
>>
>> Dave, I don't see the issue you mention below...
>>
>> Helge
>>
>> On 9/10/23 23:30, John David Anglin wrote:
>>> Hi Masahiro,
>>>
>>> The attached change fixed boot at ddb5cdbafaaa ????
>>>
>>> However, v6.5.x boot is still broken:
>>>
>>> Run /init as init process
>>> process '/usr/bin/sh' started with executable stack
>>> Loading, please wait...
>>> Starting systemd-udevd version 254.1-3
>>> e1000 alternatives: applied 0 out of 569 patches
>>> e1000: Intel(R) PRO/1000 Network Driver
>>> e1000: Copyright (c) 1999-2006 Intel Corporation.
>>> scsi_mod alternatives: applied 0 out of 7 patches
>>> SCSI subsystem initialized
>>> usbcore alternatives: applied 0 out of 18 patches
>>> usbcore: registered new interface driver usbfs
>>> libata alternatives: applied 0 out of 3 patches
>>> usbcore: registered new interface driver hub
>>> usbcore: registered new device driver usb
>>> mptbase alternatives: applied 0 out of 73 patches
>>> ehci_hcd alternatives: applied 0 out of 114 patches
>>> sata_sil24 alternatives: applied 0 out of 56 patches
>>> Fusion MPT base driver 3.04.20
>>> Copyright (c) 1999-2008 LSI Corporation
>>> sata_sil24 0000:00:01.0: Applying completion IRQ loss on PCI-X errata fix
>>> scsi host0: sata_sil24
>>> scsi host1: sata_sil24
>>> pata_sil680 0000:60:02.0: sil680: 133MHz clock.
>>> scsi host2: sata_sil24
>>> ehci_pci alternatives: applied 0 out of 2 patches
>>> ohci_hcd alternatives: applied 0 out of 144 patches
>>> ehci-pci 0000:60:01.2: EHCI Host Controller
>>> scsi host3: pata_sil680
>>> ehci-pci 0000:60:01.2: new USB bus registered, assigned bus number 1
>>> scsi host4: sata_sil24
>>> ata1: SATA max UDMA/100 host m128@0xffffffff80088000 port 0xffffffff80080000 ir6
>>> ata2: SATA max UDMA/100 host m128@0xffffffff80088000 port 0xffffffff80082000 ir6
>>> ata3: SATA max UDMA/100 host m128@0xffffffff80088000 port 0xffffffff80084000 ir6
>>> ata4: SATA max UDMA/100 host m128@0xffffffff80088000 port 0xffffffff80086000 ir6
>>> e1000 0000:60:03.0 eth0: (PCI:33MHz:32-bit) 00:11:0a:31:8a:77
>>> ehci-pci 0000:60:01.2: irq 71, io mem 0xffffffffb00a1000
>>> scsi host5: pata_sil680
>>> ata5: PATA max UDMA/133 cmd 0x26058 ctl 0x26064 bmdma 0x26040 irq 72
>>> ata6: PATA max UDMA/133 cmd 0x26050 ctl 0x26060 bmdma 0x26048 irq 72
>>> e1000 0000:60:03.0 eth0: Intel(R) PRO/1000 Network Connection
>>> ehci-pci 0000:60:01.2: USB 2.0 started, EHCI 0.95
>>> usb usb1: New USB device found, idVendor=1d6b, idProduct=0002, bcdDevice= 6.05
>>> usb usb1: New USB device strings: Mfr=3, Product=2, SerialNumber=1
>>> usb usb1: Product: EHCI Host Controller
>>> usb usb1: Manufacturer: Linux 6.5.2-dirty ehci_hcd
>>> usb usb1: SerialNumber: 0000:60:01.2
>>> hub 1-0:1.0: USB hub found
>>> hub 1-0:1.0: 5 ports detected
>>> ata1: SATA link down (SStatus 0 SControl 0)
>>> ata2: SATA link down (SStatus 0 SControl 0)
>>> ata3: SATA link down (SStatus 0 SControl 0)
>>> ata4: SATA link up 3.0 Gbps (SStatus 123 SControl 0)
>>> ata4.00: ATA-10: ST4000VN008-2DR166, SC60, max UDMA/133
>>> ata4.00: 7814037168 sectors, multi 0: LBA48 NCQ (depth 31/32)
>>> ata4.00: configured for UDMA/100
>>> scsi 4:0:0:0: Direct-Access ATA ST4000VN008-2DR1 SC60 PQ: 0 ANSI: 5
>>> ata6.00: ATAPI: HL-DT-STDVD+-RW GSA-H21L, 1.04, max UDMA/44
>>> scsi 5:0:0:0: CD-ROM HL-DT-ST DVD+-RW GSA-H21L 1.04 PQ: 0 ANSI: 5
>>> random: crng init done
>>> Timed out for waiting the udev queue being empty.
>>> Begin: Loading essential drivers ... done.
>>> Begin: Running /scripts/init-premount ... done.
>>> Begin: Mounting root file system ... Begin: Running /scripts/local-top ... done.
>>> Begin: Running /scripts/local-premount ... done.
>>> Timed out for waiting the udev queue being empty.
>>> Begin: Waiting for root file system ... Begin: Running /scripts/local-block ....
>>> Begin: Running /scripts/local-block ... done.
>>> Begin: Running /scripts/local-block ... done.
>>> Begin: Running /scripts/local-block ... done.
>>> Begin: Running /scripts/local-block ... done.
>>> Begin: Running /scripts/local-block ... done.
>>> Begin: Running /scripts/local-block ... done.
>>> Begin: Running /scripts/local-block ... done.
>>> Begin: Running /scripts/local-block ... done.
>>> Begin: Running /scripts/local-block ... done.
>>> Begin: Running /scripts/local-block ... done.
>>> Begin: Running /scripts/local-block ... done.
>>> Begin: Running /scripts/local-block ... done.
>>> Begin: Running /scripts/local-block ... done.
>>> Begin: Running /scripts/local-block ... done.
>>> Begin: Running /scripts/local-block ... done.
>>> Begin: Running /scripts/local-block ... done.
>>> Begin: Running /scripts/local-block ... done.
>>> Begin: Running /scripts/local-block ... done.
>>> done.
>>> Gave up waiting for root file system device. Common problems:
>>> - Boot args (cat /proc/cmdline)
>>> - Check rootdelay= (did the system wait long enough?)
>>> - Missing modules (cat /proc/modules; ls /dev)
>>> ALERT! LABEL=ROOT does not exist. Dropping to a shell!
>>> Rebooting automatically due to panic= boot argument
>>>
>>> I'll see if I can find the commit that breaks 6.5.
>>>
>>> Thanks,
>>> Dave
>>>
>>> On 2023-09-10 3:47 a.m., Masahiro Yamada wrote:
>>>> Hi John, Helge,
>>>>
>>>> Could you test the attached patch please?
>>>>
>>>>
>>>> Again, I only tested compilation for this.
>>>> I do not have parisc64 hardware.
>>>> In my understanding, QEMU does not support hppa64.
>>>> I do not find a way to test parisc64.
>>>>
>>>>
>>>> Masahiro Yamada
>>>>
>>>>
>>>>
>>>>
>>>>
>>>> On Sun, Sep 10, 2023 at 4:20 AM Masahiro Yamada <[email protected]> wrote:
>>>>> With a little more investigation,
>>>>> I found arch/parisc/kernel/parisc_ksyms.c
>>>>> is causing the issue.
>>>>>
>>>>> That file is a collection of EXPORT_SYMBOL
>>>>> of assembly code.
>>>>>
>>>>> I will take a closer look tomorrow.
>>>>>
>>>>>
>>>>>
>>>>>
>>>>>
>>>>>
>>>>>
>>>>>
>>>>>
>>>>>
>>>>>
>>>>> On Sun, Sep 10, 2023 at 2:20 AM Masahiro Yamada <[email protected]> wrote:
>>>>>> On Fri, Sep 8, 2023 at 7:02 AM John David Anglin <[email protected]> wrote:
>>>>>>> On 2023-09-05 7:59 p.m., John David Anglin wrote:
>>>>>>>> On 2023-09-05 5:57 p.m., John David Anglin wrote:
>>>>>>>>> I'll check ddb5cdbafaaa.
>>>>>>>> Similar fault with ddb5cdbafaaa:
>>>>>>> The alignment of the __kstrtab_ symbols in vmlinux seems wrong.
>>>>>> __kstrtab_ symbols do not need alignment.
>>>>>>
>>>>>> They were not aligned at all
>>>>>> before ddb5cdbafaaa^.
>>>>>>
>>>>>>
>>>>>>
>>>>>>> I'm fairly certain that function
>>>>>>> references prefixed with P% on hppa64 need 8 byte alignment.
>>>>>> Yeah.
>>>>>> In the following dump, all of __ksymtab_* are correctly 8-byte aligned.
>>>>>>
>>>>>>
>>>>>>> 81662: 0000000040ea4358 0 NOTYPE LOCAL DEFAULT 16 __kstrtab_system[...]
>>>>>>> 81663: 0000000040ea4748 0 NOTYPE LOCAL DEFAULT 16 __kstrtabns_syst[...]
>>>>>>> 81664: 0000000040e8e830 0 NOTYPE LOCAL DEFAULT 14 __ksymtab_system[...]
>>>>>>> 81665: 0000000040ea4365 0 NOTYPE LOCAL DEFAULT 16 __kstrtab_static[...]
>>>>>>> 81666: 0000000040ea4748 0 NOTYPE LOCAL DEFAULT 16 __kstrtabns_stat[...]
>>>>>>> 81667: 0000000040ea1640 0 NOTYPE LOCAL DEFAULT 15 __ksymtab_static[...]
>>>>>>> 81668: 0000000040ea437c 0 NOTYPE LOCAL DEFAULT 16 __kstrtab_reset_[...]
>>>>>>> 81669: 0000000040ea4748 0 NOTYPE LOCAL DEFAULT 16 __kstrtabns_rese[...]
>>>>>>> 81670: 0000000040e8bbc0 0 NOTYPE LOCAL DEFAULT 14 __ksymtab_reset_[...]
>>>>>>> 81671: 0000000040ea438a 0 NOTYPE LOCAL DEFAULT 16 __kstrtab_loops_[...]
>>>>>>> 81672: 0000000040ea4748 0 NOTYPE LOCAL DEFAULT 16 __kstrtabns_loop[...]
>>>>>>> 81673: 0000000040e86610 0 NOTYPE LOCAL DEFAULT 14 __ksymtab_loops_[...]
>>>>>>> 81674: 0000000040ea439a 0 NOTYPE LOCAL DEFAULT 16 __kstrtab_init_uts_ns
>>>>>>> 81675: 0000000040ea4748 0 NOTYPE LOCAL DEFAULT 16 __kstrtabns_init[...]
>>>>>>> 81676: 0000000040e99180 0 NOTYPE LOCAL DEFAULT 15 __ksymtab_init_uts_ns
>>>>>>> 81677: 0000000040ea43a6 0 NOTYPE LOCAL DEFAULT 16 __kstrtab_name_t[...]
>>>>>>> 81678: 0000000040ea4748 0 NOTYPE LOCAL DEFAULT 16 __kstrtabns_name[...]
>>>>>>> 81679: 0000000040e9b340 0 NOTYPE LOCAL DEFAULT 15 __ksymtab_name_t[...]
>>>>>>> 81680: 0000000040ea43b4 0 NOTYPE LOCAL DEFAULT 16 __kstrtab_wait_f[...]
>>>>>>> 81681: 0000000040ea4748 0 NOTYPE LOCAL DEFAULT 16 __kstrtabns_wait[...]
>>>>>>> 81682: 0000000040ea3638 0 NOTYPE LOCAL DEFAULT 15 __ksymtab_wait_f[...]
>>>>>>> 81683: 0000000040ea43c7 0 NOTYPE LOCAL DEFAULT 16 __kstrtab_init_task
>>>>>>> [...]
>>>>>>>
>>>>>>> I'm not sure how we get symbols that aren't 8 byte aligned. The ".balign 4" directive
>>>>>>> in __KSYMTAB doesn't seem correct but it's not the whole problem.
>>>>>>>
>>>>>>> Dave
>>
>
>