LinuxLists.cc - linux-next: Tree for May 15

On Wed, May 24, 2023 at 03:41:15PM -0700, Randy Dunlap wrote:
> On 5/23/23 23:23, Arnd Bergmann wrote:
> > On Wed, May 24, 2023, at 03:29, Palmer Dabbelt wrote:
> >> On Tue, 23 May 2023 17:22:20 PDT (-0700), [email protected] wrote:
> >>> On 5/23/23 06:07, Alexandre Ghiti wrote:
> >>>> On 23/05/2023 04:28, Randy Dunlap wrote:
> >>>>> On 5/19/23 03:42, Alexandre Ghiti wrote:
> >>>>>>>> /opt/crosstool/gcc-12.2.0-nolibc/riscv64-linux/bin/riscv64-linux-ld: section .data LMA [000000000041a000,00000000075bffd7] overlaps section .text LMA [00000000000f09d4,00000000033562ab]
> >>>>>>>> /opt/crosstool/gcc-12.2.0-nolibc/riscv64-linux/bin/riscv64-linux-ld: section .init.pi.text LMA [00000000033562ac,0000000003359137] overlaps section .data LMA [000000000041a000,00000000075bffd7]
> >>>>>>>
> >>>>>>> I'll check this one too which seems to be related to kernel/pi introduction.
> >>>>>>
> >>>>>> Thanks to Bjorn: this is caused by XIP_KERNEL, which is known to have limited size, hence the overlap, so no fix for this one. Is there a way to exclude this config from randconfig?
> >>>>> Does this mean exclude XIP_KERNEL or something else from randconfigs?
> >>>>
> >>>>
> >>>> I meant excluding XIP_KERNEL from randconfigs: it has very strict constraints regarding what can/can't be enabled then it needs human intervention to make sure the error above does not happen. So I would not bother testing this in randconfigs if possible.
> >>>
> >>> I can exclude it from my randconfig builds, but I don't know of a way to exclude it from randconfig builds in general (i.e., for everyone).
> >>
> >> Arnd had suggested a trick related to menus that would result in
> >> randconfig never enabling some config. It'd suggested for
> >> CONFIG_NONPORTABLE, but we didn't use it because it'd reduce randconfig
> >> coverage.
> >>
> >> Maybe we should add a CONFIG_VERYSPECIAL of some sort and hide things
> >> like XIP behind it (maybe M-mode too)?
> >
> > I usually add 'depends on !COMPILE_TEST', that excludes it from most
> > build bots.
>
> XIP_KERNEL already has "depends on !COMPILE_TEST", since April of 2021.

Half of me wants to say just remove XIP_KERNEL entirely. Or make it
depend on BROKEN, since noone seems to actually test it and I don't
think we even know if it works right now?

Attachments:

(No filename) (2.28 kB)
signature.asc (235.00 B)
Download all attachments

2023-05-25 00:11:59

by Palmer Dabbelt

[permalink] [raw]

Subject: Re: linux-next: Tree for May 15 (several RV64 build errors)

On Wed, 24 May 2023 15:49:41 PDT (-0700), Conor Dooley wrote:
> On Wed, May 24, 2023 at 03:41:15PM -0700, Randy Dunlap wrote:
>> On 5/23/23 23:23, Arnd Bergmann wrote:
>> > On Wed, May 24, 2023, at 03:29, Palmer Dabbelt wrote:
>> >> On Tue, 23 May 2023 17:22:20 PDT (-0700), [email protected] wrote:
>> >>> On 5/23/23 06:07, Alexandre Ghiti wrote:
>> >>>> On 23/05/2023 04:28, Randy Dunlap wrote:
>> >>>>> On 5/19/23 03:42, Alexandre Ghiti wrote:
>> >>>>>>>> /opt/crosstool/gcc-12.2.0-nolibc/riscv64-linux/bin/riscv64-linux-ld: section .data LMA [000000000041a000,00000000075bffd7] overlaps section .text LMA [00000000000f09d4,00000000033562ab]
>> >>>>>>>> /opt/crosstool/gcc-12.2.0-nolibc/riscv64-linux/bin/riscv64-linux-ld: section .init.pi.text LMA [00000000033562ac,0000000003359137] overlaps section .data LMA [000000000041a000,00000000075bffd7]
>> >>>>>>>
>> >>>>>>> I'll check this one too which seems to be related to kernel/pi introduction.
>> >>>>>>
>> >>>>>> Thanks to Bjorn: this is caused by XIP_KERNEL, which is known to have limited size, hence the overlap, so no fix for this one. Is there a way to exclude this config from randconfig?
>> >>>>> Does this mean exclude XIP_KERNEL or something else from randconfigs?
>> >>>>
>> >>>>
>> >>>> I meant excluding XIP_KERNEL from randconfigs: it has very strict constraints regarding what can/can't be enabled then it needs human intervention to make sure the error above does not happen. So I would not bother testing this in randconfigs if possible.
>> >>>
>> >>> I can exclude it from my randconfig builds, but I don't know of a way to exclude it from randconfig builds in general (i.e., for everyone).
>> >>
>> >> Arnd had suggested a trick related to menus that would result in
>> >> randconfig never enabling some config. It'd suggested for
>> >> CONFIG_NONPORTABLE, but we didn't use it because it'd reduce randconfig
>> >> coverage.
>> >>
>> >> Maybe we should add a CONFIG_VERYSPECIAL of some sort and hide things
>> >> like XIP behind it (maybe M-mode too)?
>> >
>> > I usually add 'depends on !COMPILE_TEST', that excludes it from most
>> > build bots.
>>
>> XIP_KERNEL already has "depends on !COMPILE_TEST", since April of 2021.
>
> Half of me wants to say just remove XIP_KERNEL entirely. Or make it
> depend on BROKEN, since noone seems to actually test it and I don't
> think we even know if it works right now?

Ya, let's do it. If it's broken and nobody has said anything but
randconfig, then probably nobody's using it. Let's mark it as broken or
deprecated or whatever and then see if anyone complains.

2023-05-25 13:00:35

by Conor Dooley

[permalink] [raw]

Subject: Re: linux-next: Tree for May 15 (several RV64 build errors)

On Wed, May 24, 2023 at 04:11:05PM -0700, Palmer Dabbelt wrote:
> On Wed, 24 May 2023 15:49:41 PDT (-0700), Conor Dooley wrote:
> > On Wed, May 24, 2023 at 03:41:15PM -0700, Randy Dunlap wrote:

> > > XIP_KERNEL already has "depends on !COMPILE_TEST", since April of 2021.
> >
> > Half of me wants to say just remove XIP_KERNEL entirely. Or make it
> > depend on BROKEN, since noone seems to actually test it and I don't
> > think we even know if it works right now?
>
> Ya, let's do it. If it's broken and nobody has said anything but
> randconfig, then probably nobody's using it. Let's mark it as broken or
> deprecated or whatever and then see if anyone complains.

Apart from being able to generate kernels that are broken (IOW this
randconfig), when we changed the dtb back to being in the fix, we
removed some special case XIP_KERNEL stuff (that's commit f1581626071c
("riscv: Do not set initial_boot_params to the linear address of the
dtb")) where Alex didn't know for sure whether it was safe to do.

Vexriscv (which is Myrtle I think) & Vitaly Wool both have an interest
in it. I dunno Myrtle's email, but I've CCed Vitaly. Maybe someone can
at least test the thing :)

Cheers,
Conor.

Attachments:

(No filename) (1.20 kB)
signature.asc (235.00 B)
Download all attachments