Hi,
I'm trying to get an allmodconfig kernel to boot. The way I configure
the kernel is:
'make allmodconfig KCONFIG_ALLCONFIG=$(pwd)/arch/arm64/configs/defconfig'
allmodconfig will use the KCONFIG_ALLCONFIG file as the base and then
turn the rest into modules.
The idea behind using the defconfig as base and then configure the rest
as modules is to get a bootbable kernel that have as many features
turned on as possible. That will make it possible to run as wide a
range of testsuites as possible on a single kernel.
These patches makes it possible to boot a LE kernel.
Cheers,
Anders
Anders Roxell (3):
arm64: configs: defconfig: enable DEBUG_PREEMPT and FTRACE
arm64: configs: unset CMDLINE_FORCE
arm64: configs: unset CPU_BIG_ENDIAN
arch/arm64/configs/defconfig | 4 ++--
1 file changed, 2 insertions(+), 2 deletions(-)
--
2.20.1
When building an allmodconfig KCONFIG_ALLCONFIG=$(pwd)/arch/arm64/configs/defconfig
kernel, CONFIG_DEBUG_PREEMPT and CONFIG_FTRACE will be turn off.
There is no benefit in disabling these fragments. By enabling these
nothing will happen without interaction from the user to enable it from
the cmd or boot line.
Signed-off-by: Anders Roxell <[email protected]>
---
arch/arm64/configs/defconfig | 2 --
1 file changed, 2 deletions(-)
diff --git a/arch/arm64/configs/defconfig b/arch/arm64/configs/defconfig
index 56dc7488ff36..52a32b53b2ed 100644
--- a/arch/arm64/configs/defconfig
+++ b/arch/arm64/configs/defconfig
@@ -853,6 +853,4 @@ CONFIG_DEBUG_FS=y
CONFIG_MAGIC_SYSRQ=y
CONFIG_DEBUG_KERNEL=y
# CONFIG_SCHED_DEBUG is not set
-# CONFIG_DEBUG_PREEMPT is not set
-# CONFIG_FTRACE is not set
CONFIG_MEMTEST=y
--
2.20.1
Commit 833c97254724 ("arm64: defconfig: Enable DRM DU and V4L2 FCP + VSP
modules") ment to enable the camera framework and drivers but enabled a
bit more.
Since we don't have any drivers for MEDIA_ANALOG_TV_SUPPORT or
MEDIA_DIGITAL_TV_SUPPORT theres no meaning to enable the framework to
the defconfig.
Signed-off-by: Anders Roxell <[email protected]>
---
arch/arm64/configs/defconfig | 3 ---
1 file changed, 3 deletions(-)
diff --git a/arch/arm64/configs/defconfig b/arch/arm64/configs/defconfig
index 8e05c39eab08..56dc7488ff36 100644
--- a/arch/arm64/configs/defconfig
+++ b/arch/arm64/configs/defconfig
@@ -501,11 +501,8 @@ CONFIG_IR_MESON=m
CONFIG_IR_SUNXI=m
CONFIG_MEDIA_SUPPORT=m
CONFIG_MEDIA_CAMERA_SUPPORT=y
-CONFIG_MEDIA_ANALOG_TV_SUPPORT=y
-CONFIG_MEDIA_DIGITAL_TV_SUPPORT=y
CONFIG_MEDIA_CONTROLLER=y
CONFIG_VIDEO_V4L2_SUBDEV_API=y
-# CONFIG_DVB_NET is not set
CONFIG_MEDIA_USB_SUPPORT=y
CONFIG_USB_VIDEO_CLASS=m
CONFIG_V4L_PLATFORM_DRIVERS=y
--
2.20.1
When building allmodconfig KCONFIG_ALLCONFIG=$(pwd)/arch/arm64/configs/defconfig
CONFIG_CMDLINE_FORCE gets enabled. Which forces the user to pass the
full cmdline to CONFIG_CMDLINE="...".
Rework so that we disable CONFIG_CMDLINE_FORCE in the defconfig file so
we don't have to pass in the CONFIG_CMDLINE="..." when building an
allmodconfig kernel. Since CONFIG_CMDLINE_FORCE is unset default, so
when doing 'make savedefconfig' CONFIG_CMDLINE_FORCE will be dropped.
Signed-off-by: Anders Roxell <[email protected]>
---
arch/arm64/configs/defconfig | 1 +
1 file changed, 1 insertion(+)
diff --git a/arch/arm64/configs/defconfig b/arch/arm64/configs/defconfig
index 52a32b53b2ed..878f379d8d84 100644
--- a/arch/arm64/configs/defconfig
+++ b/arch/arm64/configs/defconfig
@@ -854,3 +854,4 @@ CONFIG_MAGIC_SYSRQ=y
CONFIG_DEBUG_KERNEL=y
# CONFIG_SCHED_DEBUG is not set
CONFIG_MEMTEST=y
+# CONFIG_CMDLINE_FORCE is not set
--
2.20.1
When building allmodconfig KCONFIG_ALLCONFIG=$(pwd)/arch/arm64/configs/defconfig
CONFIG_CPU_BIG_ENDIAN gets enabled. Which tends not to be what most
people wants.
Rework so that we disable CONFIG_CPU_BIG_ENDIAN in the defcinfig file so
it doesn't get enabled when building allmodconfig kernels. When doing a
'make savedefconfig' CONFIG_CPU_BIG_ENDIAN will be dropped.
Signed-off-by: Anders Roxell <[email protected]>
---
arch/arm64/configs/defconfig | 1 +
1 file changed, 1 insertion(+)
diff --git a/arch/arm64/configs/defconfig b/arch/arm64/configs/defconfig
index 878f379d8d84..c9aa6b9ee996 100644
--- a/arch/arm64/configs/defconfig
+++ b/arch/arm64/configs/defconfig
@@ -855,3 +855,4 @@ CONFIG_DEBUG_KERNEL=y
# CONFIG_SCHED_DEBUG is not set
CONFIG_MEMTEST=y
# CONFIG_CMDLINE_FORCE is not set
+# CONFIG_CPU_BIG_ENDIAN is not set
--
2.20.1
On 26/09/2019 20:30, Anders Roxell wrote:
> When building allmodconfig KCONFIG_ALLCONFIG=$(pwd)/arch/arm64/configs/defconfig
> CONFIG_CPU_BIG_ENDIAN gets enabled. Which tends not to be what most
> people wants.
Today allmodconfig does not enable CONFIG_ACPI due to BE config, which
is quite unfortunate, I'd say.
>
> Rework so that we disable CONFIG_CPU_BIG_ENDIAN in the defcinfig file so
defconfig
> it doesn't get enabled when building allmodconfig kernels. When doing a
> 'make savedefconfig' CONFIG_CPU_BIG_ENDIAN will be dropped.
So without having to pass KCONFIG_ALLCONFIG or do anything else, what
about a config for CONFIG_CPU_LITTLE_ENDIAN instead? I'm not sure if
that was omitted for a specific reason.
Thanks,
John
>
> Signed-off-by: Anders Roxell <[email protected]>
> ---
> arch/arm64/configs/defconfig | 1 +
> 1 file changed, 1 insertion(+)
>
> diff --git a/arch/arm64/configs/defconfig b/arch/arm64/configs/defconfig
> index 878f379d8d84..c9aa6b9ee996 100644
> --- a/arch/arm64/configs/defconfig
> +++ b/arch/arm64/configs/defconfig
> @@ -855,3 +855,4 @@ CONFIG_DEBUG_KERNEL=y
> # CONFIG_SCHED_DEBUG is not set
> CONFIG_MEMTEST=y
> # CONFIG_CMDLINE_FORCE is not set
> +# CONFIG_CPU_BIG_ENDIAN is not set
>
On Tue, 1 Oct 2019 at 16:04, John Garry <[email protected]> wrote:
>
> On 26/09/2019 20:30, Anders Roxell wrote:
> > When building allmodconfig KCONFIG_ALLCONFIG=$(pwd)/arch/arm64/configs/defconfig
> > CONFIG_CPU_BIG_ENDIAN gets enabled. Which tends not to be what most
> > people wants.
>
> Today allmodconfig does not enable CONFIG_ACPI due to BE config, which
> is quite unfortunate, I'd say.
right.
>
> >
> > Rework so that we disable CONFIG_CPU_BIG_ENDIAN in the defcinfig file so
>
> defconfig
thanks.
>
> > it doesn't get enabled when building allmodconfig kernels. When doing a
> > 'make savedefconfig' CONFIG_CPU_BIG_ENDIAN will be dropped.
>
> So without having to pass KCONFIG_ALLCONFIG or do anything else, what
> about a config for CONFIG_CPU_LITTLE_ENDIAN instead? I'm not sure if
> that was omitted for a specific reason.
Oh, I tried to elaborate on the idea in the cover letter, that using
the defconfig
as base and then configure the rest as modules is to get a bootable kernel
that have as many features turned on as possible. That will make it possible
to run as wide a range of testsuites as possible on a single kernel.
Does that make it clearer ?
Cheers,
Anders
>
> Thanks,
> John
>
> >
> > Signed-off-by: Anders Roxell <[email protected]>
> > ---
> > arch/arm64/configs/defconfig | 1 +
> > 1 file changed, 1 insertion(+)
> >
> > diff --git a/arch/arm64/configs/defconfig b/arch/arm64/configs/defconfig
> > index 878f379d8d84..c9aa6b9ee996 100644
> > --- a/arch/arm64/configs/defconfig
> > +++ b/arch/arm64/configs/defconfig
> > @@ -855,3 +855,4 @@ CONFIG_DEBUG_KERNEL=y
> > # CONFIG_SCHED_DEBUG is not set
> > CONFIG_MEMTEST=y
> > # CONFIG_CMDLINE_FORCE is not set
> > +# CONFIG_CPU_BIG_ENDIAN is not set
> >
>
>
On 03/10/2019 08:40, Anders Roxell wrote:
> On Tue, 1 Oct 2019 at 16:04, John Garry <[email protected]> wrote:
>>
>> On 26/09/2019 20:30, Anders Roxell wrote:
>>> When building allmodconfig KCONFIG_ALLCONFIG=$(pwd)/arch/arm64/configs/defconfig
>>> CONFIG_CPU_BIG_ENDIAN gets enabled. Which tends not to be what most
>>> people wants.
>>
>> Today allmodconfig does not enable CONFIG_ACPI due to BE config, which
>> is quite unfortunate, I'd say.
>
> right.
>
>>
>>>
>>> Rework so that we disable CONFIG_CPU_BIG_ENDIAN in the defcinfig file so
>>
>> defconfig
>
> thanks.
>
>>
>>> it doesn't get enabled when building allmodconfig kernels. When doing a
>>> 'make savedefconfig' CONFIG_CPU_BIG_ENDIAN will be dropped.
>>
>> So without having to pass KCONFIG_ALLCONFIG or do anything else, what
>> about a config for CONFIG_CPU_LITTLE_ENDIAN instead? I'm not sure if
>> that was omitted for a specific reason.
>
> Oh, I tried to elaborate on the idea in the cover letter, that using
> the defconfig
> as base and then configure the rest as modules is to get a bootable kernel
> that have as many features turned on as possible. That will make it possible
> to run as wide a range of testsuites as possible on a single kernel.
>
> Does that make it clearer ?
Hi Anders,
Yeah, I got the idea.
So when you say "'make savedefconfig' CONFIG_CPU_BIG_ENDIAN will be
dropped", I don't know what the rules are in terms of resyncing the
common defconfig (I was under the impression that it's done per release
cycle by the arm soc maintainers, but can't find evidence as such), but
your change may be easily lost in this way.
Thanks,
John
>
> Cheers,
> Anders
>
>
>>
>> Thanks,
>> John
>>
>>>
>>> Signed-off-by: Anders Roxell <[email protected]>
>>> ---
>>> arch/arm64/configs/defconfig | 1 +
>>> 1 file changed, 1 insertion(+)
>>>
>>> diff --git a/arch/arm64/configs/defconfig b/arch/arm64/configs/defconfig
>>> index 878f379d8d84..c9aa6b9ee996 100644
>>> --- a/arch/arm64/configs/defconfig
>>> +++ b/arch/arm64/configs/defconfig
>>> @@ -855,3 +855,4 @@ CONFIG_DEBUG_KERNEL=y
>>> # CONFIG_SCHED_DEBUG is not set
>>> CONFIG_MEMTEST=y
>>> # CONFIG_CMDLINE_FORCE is not set
>>> +# CONFIG_CPU_BIG_ENDIAN is not set
>>>
>>
>>
>
> .
>
On Thu, Oct 3, 2019 at 1:15 PM John Garry <[email protected]> wrote:
> On 03/10/2019 08:40, Anders Roxell wrote:
> > On Tue, 1 Oct 2019 at 16:04, John Garry <[email protected]> wrote:
> >> On 26/09/2019 20:30, Anders Roxell wrote:
> >>> it doesn't get enabled when building allmodconfig kernels. When doing a
> >>> 'make savedefconfig' CONFIG_CPU_BIG_ENDIAN will be dropped.
> >>
> >> So without having to pass KCONFIG_ALLCONFIG or do anything else, what
> >> about a config for CONFIG_CPU_LITTLE_ENDIAN instead? I'm not sure if
> >> that was omitted for a specific reason.
> >
> > Oh, I tried to elaborate on the idea in the cover letter, that using
> > the defconfig
> > as base and then configure the rest as modules is to get a bootable kernel
> > that have as many features turned on as possible. That will make it possible
> > to run as wide a range of testsuites as possible on a single kernel.
> >
> > Does that make it clearer ?
>
> Hi Anders,
>
> Yeah, I got the idea.
>
> So when you say "'make savedefconfig' CONFIG_CPU_BIG_ENDIAN will be
> dropped", I don't know what the rules are in terms of resyncing the
> common defconfig (I was under the impression that it's done per release
> cycle by the arm soc maintainers, but can't find evidence as such), but
> your change may be easily lost in this way.
We don't do it every release, but occasionally someone sends a patch
with a refresh, and this might easily get missed.
We could force the allmodconfig kernel to be little-endian by default,
using a choice statement to pick endianess like arch/mips and arch/sh
do, the effect would be that an allmodconfig kernel gains a few more
options that depend on !BIG_ENDIAN, but we would no longer catch
a class of endianess bugs in drivers that we otherwise get warnings
for. No idea what is better here.
Arnd
On Fri, Oct 11, 2019 at 12:25:29PM +0200, Arnd Bergmann wrote:
> On Thu, Oct 3, 2019 at 1:15 PM John Garry <[email protected]> wrote:
> > On 03/10/2019 08:40, Anders Roxell wrote:
> > > On Tue, 1 Oct 2019 at 16:04, John Garry <[email protected]> wrote:
> > >> On 26/09/2019 20:30, Anders Roxell wrote:
> > >>> it doesn't get enabled when building allmodconfig kernels. When doing a
> > >>> 'make savedefconfig' CONFIG_CPU_BIG_ENDIAN will be dropped.
> > >>
> > >> So without having to pass KCONFIG_ALLCONFIG or do anything else, what
> > >> about a config for CONFIG_CPU_LITTLE_ENDIAN instead? I'm not sure if
> > >> that was omitted for a specific reason.
> > >
> > > Oh, I tried to elaborate on the idea in the cover letter, that using
> > > the defconfig
> > > as base and then configure the rest as modules is to get a bootable kernel
> > > that have as many features turned on as possible. That will make it possible
> > > to run as wide a range of testsuites as possible on a single kernel.
> > >
> > > Does that make it clearer ?
> >
> > Hi Anders,
> >
> > Yeah, I got the idea.
> >
> > So when you say "'make savedefconfig' CONFIG_CPU_BIG_ENDIAN will be
> > dropped", I don't know what the rules are in terms of resyncing the
> > common defconfig (I was under the impression that it's done per release
> > cycle by the arm soc maintainers, but can't find evidence as such), but
> > your change may be easily lost in this way.
>
> We don't do it every release, but occasionally someone sends a patch
> with a refresh, and this might easily get missed.
>
> We could force the allmodconfig kernel to be little-endian by default,
> using a choice statement to pick endianess like arch/mips and arch/sh
> do, the effect would be that an allmodconfig kernel gains a few more
> options that depend on !BIG_ENDIAN, but we would no longer catch
> a class of endianess bugs in drivers that we otherwise get warnings
> for. No idea what is better here.
Does anybody use BIG_ENDIAN? If we're not even building it then maybe we
should get rid of it altogether on arm64. I don't know of any supported
userspace that supports it or any CPUs that are unable to run little-endian
binaries.
Will
On Fri, Oct 11, 2019 at 11:27:48AM +0100, Will Deacon wrote:
> Does anybody use BIG_ENDIAN? If we're not even building it then maybe we
> should get rid of it altogether on arm64. I don't know of any supported
> userspace that supports it or any CPUs that are unable to run little-endian
> binaries.
32-bit ARM experience is that telco class users really like big
endian.
--
RMK's Patch system: https://www.armlinux.org.uk/developer/patches/
FTTC broadband for 0.8mile line in suburbia: sync at 12.1Mbps down 622kbps up
According to speedtest.net: 11.9Mbps down 500kbps up
On Fri, Oct 11, 2019 at 12:33 PM Russell King - ARM Linux admin
<[email protected]> wrote:
>
> On Fri, Oct 11, 2019 at 11:27:48AM +0100, Will Deacon wrote:
> > Does anybody use BIG_ENDIAN? If we're not even building it then maybe we
> > should get rid of it altogether on arm64. I don't know of any supported
> > userspace that supports it or any CPUs that are unable to run little-endian
> > binaries.
So far, all 'allmodconfig' builds are big-endian and have been that way
since the option was first added, so build coverage is something we
have plenty of. It's also covered by randconfig testing, regardless of
the default endianess.
> 32-bit ARM experience is that telco class users really like big
> endian.
Right, basically anyone with a large code base migrated over from a
big-endian MIPS or PowerPC legacy that found it cheaper to change
the rest of the world than to fix their own code. The only other example
of this I heard of besides networking was from banking, where they
looked at moving from AIX on PowerPC to Linux on something cheaper,
but IIRC they ended up going with LE after all because of the lack
of distro support.
Whether any users remain in use at this time, I don't know. As most
of the larger machines require UEFI to boot, they are currently limited
to little-endian for all practical purposes, and smaller embedded
machines tend to have a smaller amount of legacy code and are
easier to move over to little-endian.
One recent reference I could find is specifically for the NXP
Layerscape LS1043 in
https://www.nxp.com/docs/en/application-note/AN5129.pdf
which apparently has some support in their codewarrior tools
for big-endian binaries.
There are also some recent openembedded bugfixes for
big-endian arm64 from NXP:
https://www.mail-archive.com/[email protected]/msg22378.html
Adding Chungrong Guo to Cc for additional insight on whether
they expect any notable big-endian users in the future.
Arnd
On 2019/10/11 18:27, Will Deacon wrote:
[...]
>
> Does anybody use BIG_ENDIAN? If we're not even building it then maybe we
> should get rid of it altogether on arm64. I don't know of any supported
> userspace that supports it or any CPUs that are unable to run little-endian
> binaries.
FWIW, massive telecommunication products (based on ARM64) form Huawei are using
BIG_ENDIAN, and will use BIG_ENDIAN in the near future as well.
Thanks
Hanjun
On Sat, Oct 12, 2019 at 9:33 AM Hanjun Guo <[email protected]> wrote:
>
> On 2019/10/11 18:27, Will Deacon wrote:
> [...]
> >
> > Does anybody use BIG_ENDIAN? If we're not even building it then maybe we
> > should get rid of it altogether on arm64. I don't know of any supported
> > userspace that supports it or any CPUs that are unable to run little-endian
> > binaries.
>
> FWIW, massive telecommunication products (based on ARM64) form Huawei are using
> BIG_ENDIAN, and will use BIG_ENDIAN in the near future as well.
Ok, thanks for the information -- that definitely makes it clear that
it cannot go
away anytime soon (though it doesn't stop us from change the
allmodconfig default
if we decide that's a good idea).
Do you know if there are currently any patches against mainline to
make big-endian
work in products, or is everything working out of the box?
Arnd
On Sat, Oct 12, 2019 at 12:47:45AM +0200, Arnd Bergmann wrote:
> On Fri, Oct 11, 2019 at 12:33 PM Russell King - ARM Linux admin
> <[email protected]> wrote:
> > 32-bit ARM experience is that telco class users really like big
> > endian.
>
> Right, basically anyone with a large code base migrated over from a
> big-endian MIPS or PowerPC legacy that found it cheaper to change
> the rest of the world than to fix their own code.
I think you need to step off your soap box! Big endian isn't going
away, and it likely has nothing to do with code bases. Just look at
networking and telco protocols. Everything in that world tends to
be big endian. BE is what is understood in that world, and there's
little we can do to change it.
Demanding that they switch to LE is tantamount to you demanding that
their entire world change - it ain't going to happen.
--
RMK's Patch system: https://www.armlinux.org.uk/developer/patches/
FTTC broadband for 0.8mile line in suburbia: sync at 12.1Mbps down 622kbps up
According to speedtest.net: 11.9Mbps down 500kbps up
Hi Arnd,
On 2019/10/12 22:05, Arnd Bergmann wrote:
> On Sat, Oct 12, 2019 at 9:33 AM Hanjun Guo <[email protected]> wrote:
>>
>> On 2019/10/11 18:27, Will Deacon wrote:
>> [...]
>>>
>>> Does anybody use BIG_ENDIAN? If we're not even building it then maybe we
>>> should get rid of it altogether on arm64. I don't know of any supported
>>> userspace that supports it or any CPUs that are unable to run little-endian
>>> binaries.
>>
>> FWIW, massive telecommunication products (based on ARM64) form Huawei are using
>> BIG_ENDIAN, and will use BIG_ENDIAN in the near future as well.
>
> Ok, thanks for the information -- that definitely makes it clear that
> it cannot go
> away anytime soon (though it doesn't stop us from change the
> allmodconfig default
> if we decide that's a good idea).
I agree with you.
>
> Do you know if there are currently any patches against mainline to
> make big-endian
> work in products, or is everything working out of the box?
We are not using mainline kernel for product, but LTS 4.4 is working
fine, and also we tested LTS 4.19 kernel without any other big-endian
patches, the latest big-endian bug we found is this:
a6002ec5a8c6 arm64: opcodes.h: Add arm big-endian config options before including arm header
The running kernel code covered but Huawei's telecommunication products
is limited, but I think ARM64 arch code is working fine for big-endian.
Thanks
Hanjun
On 26/09/2019 20:30, Anders Roxell wrote:
> Hi,
>
> I'm trying to get an allmodconfig kernel to boot. The way I configure
> the kernel is:
> 'make allmodconfig KCONFIG_ALLCONFIG=$(pwd)/arch/arm64/configs/defconfig'
> allmodconfig will use the KCONFIG_ALLCONFIG file as the base and then
> turn the rest into modules.
>
> The idea behind using the defconfig as base and then configure the rest
> as modules is to get a bootbable kernel that have as many features
> turned on as possible. That will make it possible to run as wide a
> range of testsuites as possible on a single kernel.
>
> These patches makes it possible to boot a LE kernel.
JFYI, the CMDLINE_FORCE and CPU_BIG_ENDIAN changes only allow the
5.4-rc3 allmodconfig kernel to start to boot, but finally die, on my
arm64 ACPI-based system.
There is a lot of complaining from the kernel during its *10 minutes* of
booting, like this ...
39.993176][ T1] BUG: KASAN: use-after-free in
ghes_edac_unregister+0x28/0x70
[ 39.993187][ T1] Read of size 8 at addr ffff00235a099bdc by task
swapper/0/1
[ 39.993195][ T1]
[ 39.993209][ T1] CPU: 65 PID: 1 Comm: swapper/0 Tainted: G
W 5.4.0-rc3+ #1133
[ 39.993218][ T1] Hardware name: Huawei D06 /D06, BIOS Hisilicon
D06 UEFI RC0 - V1.16.01 03/15/2019
[ 39.993227][ T1] Call trace:
[ 39.993239][ T1] dump_backtrace+0x0/0x298
[ 39.993250][ T1] show_stack+0x20/0x30
[ 39.993262][ T1] dump_stack+0x190/0x21c
[ 39.993275][ T1] print_address_description.isra.6+0x80/0x3d0
[ 39.993286][ T1] __kasan_report+0x174/0x23c
[ 39.993298][ T1] kasan_report+0xc/0x18
[ 39.993310][ T1] __asan_load8+0xa4/0xb0
[ 39.993321][ T1] ghes_edac_unregister+0x28/0x70
[ 39.993333][ T1] ghes_remove+0x274/0x2a0
[ driver_probe_device+0x190/0x1f0
[ 39.993378][ T1] device_driver_attach+0x7c/0xb0
[ 39.993389][ T1] __driver_attach+0x1b8/0x1d0
[ 39.993401][ T1] bus_for_each_dev+0xf8/0x190
[ 39.993411][ T1] driver_attach+0x34/0x40
[ 39.993422][ T1] bus_add_driver+0x1d8/0x340
and then finally a watchdog timeout panic due to a hung task:
[ 624.246846][ T1143] kobject: '(null)' ((____ptrval____)): calling
ktype release
[ 624.263168][ T723] async_synchronize_cookie_domain+0x194/0x288
[ 624.269210][ T723] async_synchronize_cookie+0x28/0x38
[ 624.274473][ T723] async_port_probe+0x70/0xa8
[ 624.278833][ T850] kobject: '(null)' ((____ptrval____)):
kobject_cleanup, parent (____ptrval____)
[ 624.278844][ T1157] kobject: '(null)' ((____ptrval____)):
kobject_cleanup, parent (____ptrval____)
[ 624.278856][ T1157] kobject: '(null)' ((____ptrval____)): calling
ktype release
[ 624.279046][ T723] async_run_entry_fn+0x118/0x340
[ 624.287997][ T850] kobject: '(null)' ((____ptrval____)): calling
ktype release
[ 624.296975][ T723] process_one_work+0x7b8/0xdb8
[ 624.296989][ T723] worker_thread+0x414/0x6b8
[ 624.325726][ T723] kthread+0x1d4/0x1f0
[ 624.329684][ T723] ret_from_fork+0x10/0x18
[ 624.334007][ T723] INFO: task kworker/u195:4:1019 blocked for more
than 121 seconds.
[ 624.341871][ T723] Tainted: G B W 5.4.0-rc3+ #1133
[ 624.342853][ T415] kobject: '(null)' ((____ptrval____)):
kobject_cleanup, parent (____ptrval____)
[ 624.348427][ T723] "echo 0 >
/proc/sys/kernel/hung_task_timeout_secs" disables this message.
[ 624.348439][ T723] kworker/u195:4 D28496 1019 2 0x00000028
[ 624.357420][ T415] kobject: '(null)' ((____ptrval____)): calling
ktype release
[ 624.365968][ T723] Workqueue: events_unbound async_run_entry_fn
[ 624.385519][ T723] Call trace:
[ 624.388696][ T723] __switch_to+0x300/0x3e8
[ 624.393000][ T723] __schedule+0xc6c/0xd38
[ 624.397217][ T723] schedule+0x10c/0x168
[ 624.401262][ T723] async_synchronize_cookie_domain+0x194/0x288
[ 624.406842][ T950] kobject: '(null)' ((____ptrval____)):
kobject_cleanup, parent (____ptrval____)
[ 624.407300][ T723] async_synchronize_cookc_port_probe+0x5c/0xa8
[ 624.421511][ T723] async_run_entry_fn+0x118/0x340
[ 624.438286][ T723] process_one_work+0x7b8/0xdb8
[ 624.443027][ T723] worker_thread+0x414/0x6b8
[ 624.447504][ T723] kthread+0x1d4/0x1f0
[ 624.451462][ T723] ret_from_fork+0x10/0x18
[ 624.455932][ T723] INFO: lockdep is turned off.
[ 624.460587][ T723] Kernel panic - not syncing: hung_task: blocked tasks
[ 624.467292][ T723] CPU: 48 PID: 723 Comm: khungtaskd Tainted: G B
W 5.4.0-rc3+ #1133
[ 624.476248][ T723] Hardware name: Huawei D06 /D06, BIOS Hisilicon
D06 UEFI RC0 - V1.16.01 03/15/2019
[ 624.485461][ T723] Call trace:
[ 624.488603][ T723] dump_backtrace+0x0/0x298
[ 624.492958][ T723] show_stack+0x20/0x30
[ 624.496966][ T723] dump_stack+0x190/0x21c
[ 624.501148][ T723] panic+0x274/0x5a8
[ 624.504898][ T723] watchdog+0xa44/0xa88
[ 624.508906][ T723] kthread+0x1d4/0x1f0
[ 624.512827][ T723] ret_from_fork+0x10/0x18
[ 624.517387][ T723] SMP: stopping secondary CPUs
[ 624.522033][ T723] Kernel Offset: disabled
[ 624.526215][ T723] CPU features: 0x0002,23208a38
[ 624.530915][ T723] Memory Limit: none
[ 624.534815][ T723] ---[ end Kernel panic - not syncing: hung_task:
blocked tasks ]---
I think that I'm opening a can of worms here...
John
>
> Cheers,
> Anders
>
> Anders Roxell (3):
> arm64: configs: defconfig: enable DEBUG_PREEMPT and FTRACE
> arm64: configs: unset CMDLINE_FORCE
> arm64: configs: unset CPU_BIG_ENDIAN
>
> arch/arm64/configs/defconfig | 4 ++--
> 1 file changed, 2 insertions(+), 2 deletions(-)
>
On Sat, Oct 12, 2019 at 04:05:57PM +0200, Arnd Bergmann wrote:
> On Sat, Oct 12, 2019 at 9:33 AM Hanjun Guo <[email protected]> wrote:
> >
> > On 2019/10/11 18:27, Will Deacon wrote:
> > [...]
> > >
> > > Does anybody use BIG_ENDIAN? If we're not even building it then maybe we
> > > should get rid of it altogether on arm64. I don't know of any supported
> > > userspace that supports it or any CPUs that are unable to run little-endian
> > > binaries.
> >
> > FWIW, massive telecommunication products (based on ARM64) form Huawei are using
> > BIG_ENDIAN, and will use BIG_ENDIAN in the near future as well.
>
> Ok, thanks for the information -- that definitely makes it clear that
> it cannot go
> away anytime soon (though it doesn't stop us from change the
> allmodconfig default
> if we decide that's a good idea).
Agreed on both counts.
> Do you know if there are currently any patches against mainline to
> make big-endian
> work in products, or is everything working out of the box?
I suspect "everything" is probably much narrower in scope than for
little-endian configurations simply because of the lack of distribution
support and associated testing. If the companies using it are willing
to contribute back fixes as they run into problems, then that's probably
the best we can hope for.
Will
On Sat, Oct 12, 2019 at 03:50:55PM +0100, Russell King - ARM Linux admin wrote:
> On Sat, Oct 12, 2019 at 12:47:45AM +0200, Arnd Bergmann wrote:
> > On Fri, Oct 11, 2019 at 12:33 PM Russell King - ARM Linux admin
> > <[email protected]> wrote:
> > > 32-bit ARM experience is that telco class users really like big
> > > endian.
> >
> > Right, basically anyone with a large code base migrated over from a
> > big-endian MIPS or PowerPC legacy that found it cheaper to change
> > the rest of the world than to fix their own code.
>
> I think you need to step off your soap box! Big endian isn't going
> away, and it likely has nothing to do with code bases. Just look at
> networking and telco protocols. Everything in that world tends to
> be big endian. BE is what is understood in that world, and there's
> little we can do to change it.
>
> Demanding that they switch to LE is tantamount to you demanding that
> their entire world change - it ain't going to happen.
Oh, I wasn't demanding anything! Just interested to know if big-endian is
actually being used because it's not something that I'm able to test
sensibly and I haven't see anywhere near the amount of (public) effort to
keep it supported as for little-endian. However, having asked the question,
it's clear that it does have some users so we'll keep maintaining it on a
best-effort basis and rely on those users to let us know if anything breaks.
Will
On 2019/10/15 0:24, Will Deacon wrote:
> On Sat, Oct 12, 2019 at 03:50:55PM +0100, Russell King - ARM Linux admin wrote:
>> On Sat, Oct 12, 2019 at 12:47:45AM +0200, Arnd Bergmann wrote:
>>> On Fri, Oct 11, 2019 at 12:33 PM Russell King - ARM Linux admin
>>> <[email protected]> wrote:
>>>> 32-bit ARM experience is that telco class users really like big
>>>> endian.
>>>
>>> Right, basically anyone with a large code base migrated over from a
>>> big-endian MIPS or PowerPC legacy that found it cheaper to change
>>> the rest of the world than to fix their own code.
>>
>> I think you need to step off your soap box! Big endian isn't going
>> away, and it likely has nothing to do with code bases. Just look at
>> networking and telco protocols. Everything in that world tends to
>> be big endian. BE is what is understood in that world, and there's
>> little we can do to change it.
>>
>> Demanding that they switch to LE is tantamount to you demanding that
>> their entire world change - it ain't going to happen.
>
> Oh, I wasn't demanding anything! Just interested to know if big-endian is
> actually being used because it's not something that I'm able to test
> sensibly and I haven't see anywhere near the amount of (public) effort to
> keep it supported as for little-endian. However, having asked the question,
> it's clear that it does have some users so we'll keep maintaining it on a
> best-effort basis and rely on those users to let us know if anything breaks.
Sure, we (Huawei kernel team) did that and we will do that in the future
as well.
Thanks
Hanjun
On 26/09/2019 20:30, Anders Roxell wrote:
> When building allmodconfig KCONFIG_ALLCONFIG=$(pwd)/arch/arm64/configs/defconfig
> CONFIG_CMDLINE_FORCE gets enabled. Which forces the user to pass the
> full cmdline to CONFIG_CMDLINE="...".
>
> Rework so that we disable CONFIG_CMDLINE_FORCE in the defconfig file so
> we don't have to pass in the CONFIG_CMDLINE="..." when building an
> allmodconfig kernel. Since CONFIG_CMDLINE_FORCE is unset default, so
> when doing 'make savedefconfig' CONFIG_CMDLINE_FORCE will be dropped.
>
> Signed-off-by: Anders Roxell <[email protected]>
> ---
> arch/arm64/configs/defconfig | 1 +
> 1 file changed, 1 insertion(+)
>
> diff --git a/arch/arm64/configs/defconfig b/arch/arm64/configs/defconfig
> index 52a32b53b2ed..878f379d8d84 100644
> --- a/arch/arm64/configs/defconfig
> +++ b/arch/arm64/configs/defconfig
> @@ -854,3 +854,4 @@ CONFIG_MAGIC_SYSRQ=y
> CONFIG_DEBUG_KERNEL=y
> # CONFIG_SCHED_DEBUG is not set
> CONFIG_MEMTEST=y
> +# CONFIG_CMDLINE_FORCE is not set
This was my initial idea for an alternative Kconfig change:
--->8---
According to the comment for CMDLINE, we should at least have the root
device defined. So if CMDLINE is "", then it can not be defined so
disallow CMDLINE_FORCE in this scenario.
diff --git a/arch/arm64/Kconfig b/arch/arm64/Kconfig
index 950a56b71ff0..6f3bff2f385e 100644
--- a/arch/arm64/Kconfig
+++ b/arch/arm64/Kconfig
@@ -1580,6 +1580,7 @@ config CMDLINE
config CMDLINE_FORCE
bool "Always use the default kernel command string"
+ depends on CMDLINE != ""
help
Always use the default kernel command string, even if the boot
loader passes other arguments to the kernel.
>