There's an OF helper called of_dma_is_coherent(), which checks if a
device has a "dma-coherent" property to see if the device is coherent
for DMA.
But on some platforms devices are coherent by default, and on some
platforms it's not possible to update existing device trees to add the
"dma-coherent" property.
So add a Kconfig symbol to allow arch code to tell
of_dma_is_coherent() that devices are coherent by default, regardless
of the presence of the property.
Select that symbol on powerpc when NOT_COHERENT_CACHE is not set, ie.
when the system has a coherent cache.
Fixes: 92ea637edea3 ("of: introduce of_dma_is_coherent() helper")
Cc: [email protected] # v3.16+
Reported-by: Christian Zigotzky <[email protected]>
Tested-by: Christian Zigotzky <[email protected]>
Signed-off-by: Michael Ellerman <[email protected]>
---
arch/powerpc/Kconfig | 1 +
drivers/of/Kconfig | 4 ++++
drivers/of/address.c | 6 +++++-
3 files changed, 10 insertions(+), 1 deletion(-)
diff --git a/arch/powerpc/Kconfig b/arch/powerpc/Kconfig
index 1ec34e16ed65..19f5aa8ac9a3 100644
--- a/arch/powerpc/Kconfig
+++ b/arch/powerpc/Kconfig
@@ -238,6 +238,7 @@ config PPC
select NEED_DMA_MAP_STATE if PPC64 || NOT_COHERENT_CACHE
select NEED_SG_DMA_LENGTH
select OF
+ select OF_DMA_DEFAULT_COHERENT if !NOT_COHERENT_CACHE
select OF_EARLY_FLATTREE
select OLD_SIGACTION if PPC32
select OLD_SIGSUSPEND
diff --git a/drivers/of/Kconfig b/drivers/of/Kconfig
index 37c2ccbefecd..d91618641be6 100644
--- a/drivers/of/Kconfig
+++ b/drivers/of/Kconfig
@@ -103,4 +103,8 @@ config OF_OVERLAY
config OF_NUMA
bool
+config OF_DMA_DEFAULT_COHERENT
+ # arches should select this if DMA is coherent by default for OF devices
+ bool
+
endif # OF
diff --git a/drivers/of/address.c b/drivers/of/address.c
index 99c1b8058559..e8a39c3ec4d4 100644
--- a/drivers/of/address.c
+++ b/drivers/of/address.c
@@ -995,12 +995,16 @@ int of_dma_get_range(struct device_node *np, u64 *dma_addr, u64 *paddr, u64 *siz
* @np: device node
*
* It returns true if "dma-coherent" property was found
- * for this device in DT.
+ * for this device in the DT, or if DMA is coherent by
+ * default for OF devices on the current platform.
*/
bool of_dma_is_coherent(struct device_node *np)
{
struct device_node *node = of_node_get(np);
+ if (IS_ENABLED(CONFIG_OF_DMA_DEFAULT_COHERENT))
+ return true;
+
while (node) {
if (of_property_read_bool(node, "dma-coherent")) {
of_node_put(node);
--
2.21.1
On Sun, 26 Jan 2020 at 12:53, Michael Ellerman <[email protected]> wrote:
>
> There's an OF helper called of_dma_is_coherent(), which checks if a
> device has a "dma-coherent" property to see if the device is coherent
> for DMA.
>
> But on some platforms devices are coherent by default, and on some
> platforms it's not possible to update existing device trees to add the
> "dma-coherent" property.
>
> So add a Kconfig symbol to allow arch code to tell
> of_dma_is_coherent() that devices are coherent by default, regardless
> of the presence of the property.
>
> Select that symbol on powerpc when NOT_COHERENT_CACHE is not set, ie.
> when the system has a coherent cache.
>
> Fixes: 92ea637edea3 ("of: introduce of_dma_is_coherent() helper")
> Cc: [email protected] # v3.16+
> Reported-by: Christian Zigotzky <[email protected]>
> Tested-by: Christian Zigotzky <[email protected]>
> Signed-off-by: Michael Ellerman <[email protected]>
Thanks Michael for helping out fixing and this! The patch looks good to me.
Reviewed-by: Ulf Hansson <[email protected]>
Kind regards
Uffe
> ---
> arch/powerpc/Kconfig | 1 +
> drivers/of/Kconfig | 4 ++++
> drivers/of/address.c | 6 +++++-
> 3 files changed, 10 insertions(+), 1 deletion(-)
>
> diff --git a/arch/powerpc/Kconfig b/arch/powerpc/Kconfig
> index 1ec34e16ed65..19f5aa8ac9a3 100644
> --- a/arch/powerpc/Kconfig
> +++ b/arch/powerpc/Kconfig
> @@ -238,6 +238,7 @@ config PPC
> select NEED_DMA_MAP_STATE if PPC64 || NOT_COHERENT_CACHE
> select NEED_SG_DMA_LENGTH
> select OF
> + select OF_DMA_DEFAULT_COHERENT if !NOT_COHERENT_CACHE
> select OF_EARLY_FLATTREE
> select OLD_SIGACTION if PPC32
> select OLD_SIGSUSPEND
> diff --git a/drivers/of/Kconfig b/drivers/of/Kconfig
> index 37c2ccbefecd..d91618641be6 100644
> --- a/drivers/of/Kconfig
> +++ b/drivers/of/Kconfig
> @@ -103,4 +103,8 @@ config OF_OVERLAY
> config OF_NUMA
> bool
>
> +config OF_DMA_DEFAULT_COHERENT
> + # arches should select this if DMA is coherent by default for OF devices
> + bool
> +
> endif # OF
> diff --git a/drivers/of/address.c b/drivers/of/address.c
> index 99c1b8058559..e8a39c3ec4d4 100644
> --- a/drivers/of/address.c
> +++ b/drivers/of/address.c
> @@ -995,12 +995,16 @@ int of_dma_get_range(struct device_node *np, u64 *dma_addr, u64 *paddr, u64 *siz
> * @np: device node
> *
> * It returns true if "dma-coherent" property was found
> - * for this device in DT.
> + * for this device in the DT, or if DMA is coherent by
> + * default for OF devices on the current platform.
> */
> bool of_dma_is_coherent(struct device_node *np)
> {
> struct device_node *node = of_node_get(np);
>
> + if (IS_ENABLED(CONFIG_OF_DMA_DEFAULT_COHERENT))
> + return true;
> +
> while (node) {
> if (of_property_read_bool(node, "dma-coherent")) {
> of_node_put(node);
> --
> 2.21.1
>
+ Frank (me)
On 1/26/20 5:52 AM, Michael Ellerman wrote:
> There's an OF helper called of_dma_is_coherent(), which checks if a
> device has a "dma-coherent" property to see if the device is coherent
> for DMA.
>
> But on some platforms devices are coherent by default, and on some
> platforms it's not possible to update existing device trees to add the
> "dma-coherent" property.
>
> So add a Kconfig symbol to allow arch code to tell
> of_dma_is_coherent() that devices are coherent by default, regardless
> of the presence of the property.
>
> Select that symbol on powerpc when NOT_COHERENT_CACHE is not set, ie.
> when the system has a coherent cache.
>
> Fixes: 92ea637edea3 ("of: introduce of_dma_is_coherent() helper")
> Cc: [email protected] # v3.16+
> Reported-by: Christian Zigotzky <[email protected]>
> Tested-by: Christian Zigotzky <[email protected]>
> Signed-off-by: Michael Ellerman <[email protected]>
> ---
> arch/powerpc/Kconfig | 1 +
> drivers/of/Kconfig | 4 ++++
> drivers/of/address.c | 6 +++++-
> 3 files changed, 10 insertions(+), 1 deletion(-)
>
> diff --git a/arch/powerpc/Kconfig b/arch/powerpc/Kconfig
> index 1ec34e16ed65..19f5aa8ac9a3 100644
> --- a/arch/powerpc/Kconfig
> +++ b/arch/powerpc/Kconfig
> @@ -238,6 +238,7 @@ config PPC
> select NEED_DMA_MAP_STATE if PPC64 || NOT_COHERENT_CACHE
> select NEED_SG_DMA_LENGTH
> select OF
> + select OF_DMA_DEFAULT_COHERENT if !NOT_COHERENT_CACHE
> select OF_EARLY_FLATTREE
> select OLD_SIGACTION if PPC32
> select OLD_SIGSUSPEND
> diff --git a/drivers/of/Kconfig b/drivers/of/Kconfig
> index 37c2ccbefecd..d91618641be6 100644
> --- a/drivers/of/Kconfig
> +++ b/drivers/of/Kconfig
> @@ -103,4 +103,8 @@ config OF_OVERLAY
> config OF_NUMA
> bool
>
> +config OF_DMA_DEFAULT_COHERENT
> + # arches should select this if DMA is coherent by default for OF devices
> + bool
> +
> endif # OF
> diff --git a/drivers/of/address.c b/drivers/of/address.c
> index 99c1b8058559..e8a39c3ec4d4 100644
> --- a/drivers/of/address.c
> +++ b/drivers/of/address.c
> @@ -995,12 +995,16 @@ int of_dma_get_range(struct device_node *np, u64 *dma_addr, u64 *paddr, u64 *siz
> * @np: device node
> *
> * It returns true if "dma-coherent" property was found
> - * for this device in DT.
> + * for this device in the DT, or if DMA is coherent by
> + * default for OF devices on the current platform.
> */
> bool of_dma_is_coherent(struct device_node *np)
> {
> struct device_node *node = of_node_get(np);
>
> + if (IS_ENABLED(CONFIG_OF_DMA_DEFAULT_COHERENT))
> + return true;
> +
> while (node) {
> if (of_property_read_bool(node, "dma-coherent")) {
> of_node_put(node);
>
On Sun, 26 Jan 2020 22:52:47 +1100, Michael Ellerman wrote:
> There's an OF helper called of_dma_is_coherent(), which checks if a
> device has a "dma-coherent" property to see if the device is coherent
> for DMA.
>
> But on some platforms devices are coherent by default, and on some
> platforms it's not possible to update existing device trees to add the
> "dma-coherent" property.
>
> So add a Kconfig symbol to allow arch code to tell
> of_dma_is_coherent() that devices are coherent by default, regardless
> of the presence of the property.
>
> Select that symbol on powerpc when NOT_COHERENT_CACHE is not set, ie.
> when the system has a coherent cache.
>
> Fixes: 92ea637edea3 ("of: introduce of_dma_is_coherent() helper")
> Cc: [email protected] # v3.16+
> Reported-by: Christian Zigotzky <[email protected]>
> Tested-by: Christian Zigotzky <[email protected]>
> Signed-off-by: Michael Ellerman <[email protected]>
> ---
> arch/powerpc/Kconfig | 1 +
> drivers/of/Kconfig | 4 ++++
> drivers/of/address.c | 6 +++++-
> 3 files changed, 10 insertions(+), 1 deletion(-)
>
Applied, thanks.
Rob
Ulf Hansson <[email protected]> writes:
> On Sun, 26 Jan 2020 at 12:53, Michael Ellerman <[email protected]> wrote:
>> There's an OF helper called of_dma_is_coherent(), which checks if a
>> device has a "dma-coherent" property to see if the device is coherent
>> for DMA.
>>
>> But on some platforms devices are coherent by default, and on some
>> platforms it's not possible to update existing device trees to add the
>> "dma-coherent" property.
>>
>> So add a Kconfig symbol to allow arch code to tell
>> of_dma_is_coherent() that devices are coherent by default, regardless
>> of the presence of the property.
>>
>> Select that symbol on powerpc when NOT_COHERENT_CACHE is not set, ie.
>> when the system has a coherent cache.
>>
>> Fixes: 92ea637edea3 ("of: introduce of_dma_is_coherent() helper")
>> Cc: [email protected] # v3.16+
>> Reported-by: Christian Zigotzky <[email protected]>
>> Tested-by: Christian Zigotzky <[email protected]>
>> Signed-off-by: Michael Ellerman <[email protected]>
>
> Thanks Michael for helping out fixing and this! The patch looks good to me.
>
> Reviewed-by: Ulf Hansson <[email protected]>
Thanks for the review.
cheers
Rob Herring <[email protected]> writes:
> On Sun, 26 Jan 2020 22:52:47 +1100, Michael Ellerman wrote:
>> There's an OF helper called of_dma_is_coherent(), which checks if a
>> device has a "dma-coherent" property to see if the device is coherent
>> for DMA.
>>
>> But on some platforms devices are coherent by default, and on some
>> platforms it's not possible to update existing device trees to add the
>> "dma-coherent" property.
>>
>> So add a Kconfig symbol to allow arch code to tell
>> of_dma_is_coherent() that devices are coherent by default, regardless
>> of the presence of the property.
>>
>> Select that symbol on powerpc when NOT_COHERENT_CACHE is not set, ie.
>> when the system has a coherent cache.
>>
>> Fixes: 92ea637edea3 ("of: introduce of_dma_is_coherent() helper")
>> Cc: [email protected] # v3.16+
>> Reported-by: Christian Zigotzky <[email protected]>
>> Tested-by: Christian Zigotzky <[email protected]>
>> Signed-off-by: Michael Ellerman <[email protected]>
>> ---
>> arch/powerpc/Kconfig | 1 +
>> drivers/of/Kconfig | 4 ++++
>> drivers/of/address.c | 6 +++++-
>> 3 files changed, 10 insertions(+), 1 deletion(-)
>>
>
> Applied, thanks.
Thanks.
cheers
Hello,
We regularly compile and test Linux kernels every day during the merge
window. Since Thuesday we have very high CPU loads because of the avahi
daemon on our desktop Linux systems (Ubuntu, Debian etc).
Error message: avahi-daemon[2410]: ioctl(): Inappropriate ioctl for device
Could you please test the latest Git kernel?
It is possible to deactivate the avahi daemon with the following lines
in the file "/etc/avahi/avahi-daemon.conf":
use-ipv4=no
use-ipv6=no
But this is only a temporary solution.
Thanks,
Christian
[might be network related, so adding netdev mailing list]
On 2/1/20 4:08 PM, Christian Zigotzky wrote:
> Hello,
>
> We regularly compile and test Linux kernels every day during the merge window. Since Thuesday we have very high CPU loads because of the avahi daemon on our desktop Linux systems (Ubuntu, Debian etc).
>
> Error message: avahi-daemon[2410]: ioctl(): Inappropriate ioctl for device
>
> Could you please test the latest Git kernel?
>
> It is possible to deactivate the avahi daemon with the following lines in the file "/etc/avahi/avahi-daemon.conf":
>
> use-ipv4=no
> use-ipv6=no
>
> But this is only a temporary solution.
>
> Thanks,
> Christian
--
~Randy
Hello,
Le 02/02/2020 à 01:08, Christian Zigotzky a écrit :
> Hello,
>
> We regularly compile and test Linux kernels every day during the merge
> window. Since Thuesday we have very high CPU loads because of the avahi
> daemon on our desktop Linux systems (Ubuntu, Debian etc).
>
> Error message: avahi-daemon[2410]: ioctl(): Inappropriate ioctl for device
Do you know which ioctl, on which device ?
Can you take a trace of running avahi-daemon with 'strace' ?
Can you bisect ?
Christophe
On 02 February 2020 at 09:19 am, Christophe Leroy wrote:
> Hello,
>
> Le 02/02/2020 à 01:08, Christian Zigotzky a écrit :
>> Hello,
>>
>> We regularly compile and test Linux kernels every day during the
>> merge window. Since Thuesday we have very high CPU loads because of
>> the avahi daemon on our desktop Linux systems (Ubuntu, Debian etc).
>>
>> Error message: avahi-daemon[2410]: ioctl(): Inappropriate ioctl for
>> device
>
> Do you know which ioctl, on which device ?
> Can you take a trace of running avahi-daemon with 'strace' ?
>
> Can you bisect ?
>
> Christophe
Hi Christophe,
Hi All,
I figured out that the avahi-daemon has a problem with the IPv6 address
of a network interface since the Git kernel from Thursday. (Log attached)
This generates high CPU usage because the avahi-daemon tries to access
the IPv6 address again and again and thereby it produces a lot of log
messages.
We figured out that the networking updates aren't responsible for this
issue because we created a test kernel on Wednesday. The issue is
somewhere in the commits from Wednesday night to Thursday (CET).
Please compile the latest Git kernel and test it with a desktop linux
distribution for example Ubuntu. In my point of view there are many
desktop machines affected. Many server systems don't use the avahi
daemon so they aren't affected.
It's possible to deactivate the access to the IPv6 address with the
following line in the file "/etc/avahi/avahi-daemon.conf":
use-ipv6=no
After a reboot the CPU usage is normal again. This is only a temporary
solution.
Unfortunately I don't have the time for bisecting next week. I have a
lot of other work to do. In my point of view it is very important that
you also compile the latest Git kernels. Then you will see the issue and
then you have a better possibility to fix the issue.
Thanks,
Christian
On Sun, 2 Feb 2020 16:02:18 +0100, Christian Zigotzky wrote:
> On 02 February 2020 at 09:19 am, Christophe Leroy wrote:
> > Hello,
> >
> > Le 02/02/2020 à 01:08, Christian Zigotzky a écrit :
> >> Hello,
> >>
> >> We regularly compile and test Linux kernels every day during the
> >> merge window. Since Thuesday we have very high CPU loads because of
> >> the avahi daemon on our desktop Linux systems (Ubuntu, Debian etc).
> >>
> >> Error message: avahi-daemon[2410]: ioctl(): Inappropriate ioctl for
> >> device
> >
> > Do you know which ioctl, on which device ?
> > Can you take a trace of running avahi-daemon with 'strace' ?
> >
> > Can you bisect ?
> >
> > Christophe
> Hi Christophe,
> Hi All,
>
> I figured out that the avahi-daemon has a problem with the IPv6 address
> of a network interface since the Git kernel from Thursday. (Log attached)
> This generates high CPU usage because the avahi-daemon tries to access
> the IPv6 address again and again and thereby it produces a lot of log
> messages.
>
> We figured out that the networking updates aren't responsible for this
> issue because we created a test kernel on Wednesday. The issue is
> somewhere in the commits from Wednesday night to Thursday (CET).
FWIW Thursday is when the latest networking pull came in, so could well
be networking related..
> Please compile the latest Git kernel and test it with a desktop linux
> distribution for example Ubuntu. In my point of view there are many
> desktop machines affected. Many server systems don't use the avahi
> daemon so they aren't affected.
>
> It's possible to deactivate the access to the IPv6 address with the
> following line in the file "/etc/avahi/avahi-daemon.conf":
>
> use-ipv6=no
>
> After a reboot the CPU usage is normal again. This is only a temporary
> solution.
>
> Unfortunately I don't have the time for bisecting next week. I have a
> lot of other work to do. In my point of view it is very important that
> you also compile the latest Git kernels. Then you will see the issue and
> then you have a better possibility to fix the issue.
On 03 February 2020 at 6:53 pm, Jakub Kicinski wrote:
> On Sun, 2 Feb 2020 16:02:18 +0100, Christian Zigotzky wrote:
>> On 02 February 2020 at 09:19 am, Christophe Leroy wrote:
>>> Hello,
>>>
>>> Le 02/02/2020 à 01:08, Christian Zigotzky a écrit :
>>>> Hello,
>>>>
>>>> We regularly compile and test Linux kernels every day during the
>>>> merge window. Since Thursday we have very high CPU loads because of
>>>> the avahi daemon on our desktop Linux systems (Ubuntu, Debian etc).
>>>>
>>>> Error message: avahi-daemon[2410]: ioctl(): Inappropriate ioctl for
>>>> device
>>> Do you know which ioctl, on which device ?
>>> Can you take a trace of running avahi-daemon with 'strace' ?
>>>
>>> Can you bisect ?
>>>
>>> Christophe
>> Hi Christophe,
>> Hi All,
>>
>> I figured out that the avahi-daemon has a problem with the IPv6 address
>> of a network interface since the Git kernel from Thursday. (Log attached)
>> This generates high CPU usage because the avahi-daemon tries to access
>> the IPv6 address again and again and thereby it produces a lot of log
>> messages.
>>
>> We figured out that the networking updates aren't responsible for this
>> issue because we created a test kernel on Wednesday. The issue is
>> somewhere in the commits from Wednesday night to Thursday (CET).
> FWIW Thursday is when the latest networking pull came in, so could well
> be networking related..
>
>> Please compile the latest Git kernel and test it with a desktop linux
>> distribution for example Ubuntu. In my point of view there are many
>> desktop machines affected. Many server systems don't use the avahi
>> daemon so they aren't affected.
>>
>> It's possible to deactivate the access to the IPv6 address with the
>> following line in the file "/etc/avahi/avahi-daemon.conf":
>>
>> use-ipv6=no
>>
>> After a reboot the CPU usage is normal again. This is only a temporary
>> solution.
>>
>> Unfortunately I don't have the time for bisecting next week. I have a
>> lot of other work to do. In my point of view it is very important that
>> you also compile the latest Git kernels. Then you will see the issue and
>> then you have a better possibility to fix the issue.
Hi All,
The issue still exist in the latest Git kernel. It's a PowerPC issue. I
compiled the latest Git kernel on a PC today and there aren't any issues
with the avahi daemon. Another Power Mac user reported the same issue on
his G5. I tested with the AmigaOne X1000 and X5000 in the last days.
I bisected today but I think the result isn't correct because it founds
the other problem with ordering of PCSCSI definition in esp_rev enum. I
don't know how to bisect if there is another issue at the same time.
Maybe "git bisect skip"?
2086faae3c55a652cfbd369e18ecdb703aacc493 is the first bad commit
commit 2086faae3c55a652cfbd369e18ecdb703aacc493
Author: Kars de Jong <[email protected]>
Date: Tue Nov 19 21:20:20 2019 +0100
scsi: esp_scsi: Correct ordering of PCSCSI definition in esp_rev enum
The order of the definitions in the esp_rev enum is important. The
values
are used in comparisons for chip features.
Add a comment to the enum explaining this.
Also, the actual values for the enum fields are irrelevant, so
remove the
explicit values (suggested by Geert Uytterhoeven). This makes
adding a new
field in the middle of the enum easier.
Finally, move the PCSCSI definition to the right place in the enum.
In its
previous location, at the end of the enum, the wrong values are
written to
the CONFIG3 register when used with FAST-SCSI targets.
Link:
https://lore.kernel.org/r/[email protected]
Signed-off-by: Kars de Jong <[email protected]>
Signed-off-by: Martin K. Petersen <[email protected]>
:040000 040000 cdc128596e33fb60406b5de9b17b79623c187c1a
48ceab06439f95285e8b30181e75f9a68c25fcb5 M drivers
Cheers,
Christian
Christian Zigotzky <[email protected]> writes:
> Kernel 5.5 PowerPC is also affected.
I don't know what you mean by that. What sha are you talking about?
I have a system with avahi running and everything's fine.
# grep use- /etc/avahi/avahi-daemon.conf
use-ipv4=yes
use-ipv6=yes
# systemctl status -l --no-pager avahi-daemon
● avahi-daemon.service - Avahi mDNS/DNS-SD Stack
Loaded: loaded (/lib/systemd/system/avahi-daemon.service; enabled; vendor preset: enabled)
Active: active (running) since Thu 2020-02-06 14:55:34 AEDT; 38min ago
Main PID: 1884 (avahi-daemon)
Status: "avahi-daemon 0.7 starting up."
CGroup: /system.slice/avahi-daemon.service
├─1884 avahi-daemon: running [mpe-ubuntu-le.local]
└─1888 avahi-daemon: chroot helper
Feb 06 14:55:34 mpe-ubuntu-le avahi-daemon[1884]: Registering new address record for fe80::5054:ff:fe66:2a19 on eth0.*.
Feb 06 14:55:34 mpe-ubuntu-le avahi-daemon[1884]: Registering new address record for 10.61.141.81 on eth0.IPv4.
Feb 06 14:55:34 mpe-ubuntu-le avahi-daemon[1884]: Registering new address record for ::1 on lo.*.
Feb 06 14:55:34 mpe-ubuntu-le avahi-daemon[1884]: Registering new address record for 127.0.0.1 on lo.IPv4.
Feb 06 14:55:34 mpe-ubuntu-le systemd[1]: Started Avahi mDNS/DNS-SD Stack.
Feb 06 14:55:35 mpe-ubuntu-le avahi-daemon[1884]: Server startup complete. Host name is mpe-ubuntu-le.local. Local service cookie is 3972418141.
Feb 06 14:55:38 mpe-ubuntu-le avahi-daemon[1884]: Leaving mDNS multicast group on interface eth0.IPv6 with address fe80::5054:ff:fe66:2a19.
Feb 06 14:55:38 mpe-ubuntu-le avahi-daemon[1884]: Joining mDNS multicast group on interface eth0.IPv6 with address fd69:d75f:b8b5:61:5054:ff:fe66:2a19.
Feb 06 14:55:38 mpe-ubuntu-le avahi-daemon[1884]: Registering new address record for fd69:d75f:b8b5:61:5054:ff:fe66:2a19 on eth0.*.
Feb 06 14:55:38 mpe-ubuntu-le avahi-daemon[1884]: Withdrawing address record for fe80::5054:ff:fe66:2a19 on eth0.
# uname -r
5.5.0-gcc-8.2.0
The key question is what ioctl is it complaining about. You should be
able to find that via strace.
cheers
> Christian Zigotzky wrote:
>
> Hi All,
>
> The issue with the avahi-daemon still exist in the latest Git kernel. It's a PowerPC issue. I compiled the latest Git kernel on a PC today and there aren't any issues with the avahi daemon. Another Power Mac user reported the same issue on his G5. I tested with the AmigaOne X1000 and X5000 in the last days.
>
> I bisected today but I think the result isn't correct because it found the other problem with ordering of PCSCSI definition in esp_rev enum. I don't know how to bisect if there is another issue at the same time. Maybe "git bisect skip"?
>
> 2086faae3c55a652cfbd369e18ecdb703aacc493 is the first bad commit
> commit 2086faae3c55a652cfbd369e18ecdb703aacc493
> Author: Kars de Jong <[email protected]>
> Date: Tue Nov 19 21:20:20 2019 +0100
>
> scsi: esp_scsi: Correct ordering of PCSCSI definition in esp_rev enum
>
> The order of the definitions in the esp_rev enum is important. The values
> are used in comparisons for chip features.
>
> Add a comment to the enum explaining this.
>
> Also, the actual values for the enum fields are irrelevant, so remove the
> explicit values (suggested by Geert Uytterhoeven). This makes adding a new
> field in the middle of the enum easier.
>
> Finally, move the PCSCSI definition to the right place in the enum. In its
> previous location, at the end of the enum, the wrong values are written to
> the CONFIG3 register when used with FAST-SCSI targets.
>
> Link: https://lore.kernel.org/r/[email protected]
> Signed-off-by: Kars de Jong <[email protected]>
> Signed-off-by: Martin K. Petersen <[email protected]>
>
> :040000 040000 cdc128596e33fb60406b5de9b17b79623c187c1a 48ceab06439f95285e8b30181e75f9a68c25fcb5 M drivers
On 06 February 2020 at 05:35 am, Michael Ellerman wrote:
> Christian Zigotzky <[email protected]> writes:
>> Kernel 5.5 PowerPC is also affected.
> I don't know what you mean by that. What sha are you talking about?
>
> I have a system with avahi running and everything's fine.
>
> # grep use- /etc/avahi/avahi-daemon.conf
> use-ipv4=yes
> use-ipv6=yes
>
> # systemctl status -l --no-pager avahi-daemon
> ● avahi-daemon.service - Avahi mDNS/DNS-SD Stack
> Loaded: loaded (/lib/systemd/system/avahi-daemon.service; enabled; vendor preset: enabled)
> Active: active (running) since Thu 2020-02-06 14:55:34 AEDT; 38min ago
> Main PID: 1884 (avahi-daemon)
> Status: "avahi-daemon 0.7 starting up."
> CGroup: /system.slice/avahi-daemon.service
> ├─1884 avahi-daemon: running [mpe-ubuntu-le.local]
> └─1888 avahi-daemon: chroot helper
>
> Feb 06 14:55:34 mpe-ubuntu-le avahi-daemon[1884]: Registering new address record for fe80::5054:ff:fe66:2a19 on eth0.*.
> Feb 06 14:55:34 mpe-ubuntu-le avahi-daemon[1884]: Registering new address record for 10.61.141.81 on eth0.IPv4.
> Feb 06 14:55:34 mpe-ubuntu-le avahi-daemon[1884]: Registering new address record for ::1 on lo.*.
> Feb 06 14:55:34 mpe-ubuntu-le avahi-daemon[1884]: Registering new address record for 127.0.0.1 on lo.IPv4.
> Feb 06 14:55:34 mpe-ubuntu-le systemd[1]: Started Avahi mDNS/DNS-SD Stack.
> Feb 06 14:55:35 mpe-ubuntu-le avahi-daemon[1884]: Server startup complete. Host name is mpe-ubuntu-le.local. Local service cookie is 3972418141.
> Feb 06 14:55:38 mpe-ubuntu-le avahi-daemon[1884]: Leaving mDNS multicast group on interface eth0.IPv6 with address fe80::5054:ff:fe66:2a19.
> Feb 06 14:55:38 mpe-ubuntu-le avahi-daemon[1884]: Joining mDNS multicast group on interface eth0.IPv6 with address fd69:d75f:b8b5:61:5054:ff:fe66:2a19.
> Feb 06 14:55:38 mpe-ubuntu-le avahi-daemon[1884]: Registering new address record for fd69:d75f:b8b5:61:5054:ff:fe66:2a19 on eth0.*.
> Feb 06 14:55:38 mpe-ubuntu-le avahi-daemon[1884]: Withdrawing address record for fe80::5054:ff:fe66:2a19 on eth0.
>
> # uname -r
> 5.5.0-gcc-8.2.0
>
>
> The key question is what ioctl is it complaining about. You should be
> able to find that via strace.
>
> cheers
>
Hello Michael,
Sorry it isn't true that the kernel 5.5 is also affected. A Power Mac G5
user told me that but this isn't correct. I compiled and tested the
stable kernel 5.5.1 and 5.5.2 today and both kernels don't have the
issue with the avahi daemon.
Could you please also test the latest Git kernel?
strace /usr/sbin/avahi-daemon
...
poll([{fd=4, events=POLLIN}, {fd=16, events=POLLIN}, {fd=15,
events=POLLIN}, {fd=14, events=POLLIN}, {fd=13, events=POLLIN}, {fd=12,
events=POLLIN}, {fd=11, events=POLLIN}, {fd=10, events=POLLIN}, {fd=9,
events=POLLIN}, {fd=8, events=POLLIN}, {fd=6, events=POLLIN}], 11, 65) =
2 ([{fd=12, revents=POLLIN}, {fd=9, revents=POLLIN}])
ioctl(12, FIONREAD, 0xffba6f24) = -1 ENOTTY (Inappropriate ioctl
for device)
write(2, "ioctl(): Inappropriate ioctl for"..., 39ioctl(): Inappropriate
ioctl for device) = 39
write(2, "\n", 1
) = 1
...
Thanks,
Christian
Hello Arnd,
We regularly compile and test Linux kernels every day during the merge
window. Since Thursday last week we have very high CPU usage because of
the avahi daemon on our desktop Linux systems (Ubuntu, Debian etc). The
avahi daemon produces a lot of the following log message. This generates
high CPU usage.
Error message: avahi-daemon[2410]: ioctl(): Inappropriate ioctl for device
strace /usr/sbin/avahi-daemon:
poll([{fd=4, events=POLLIN}, {fd=16, events=POLLIN}, {fd=15,
events=POLLIN}, {fd=14, events=POLLIN}, {fd=13, events=POLLIN}, {fd=12,
events=POLLIN}, {fd=11, events=POLLIN}, {fd=10, events=POLLIN}, {fd=9,
events=POLLIN}, {fd=8, events=POLLIN}, {fd=6, events=POLLIN}], 11, 65) =
2 ([{fd=12, revents=POLLIN}, {fd=9, revents=POLLIN}])
ioctl(12, FIONREAD, 0xffba6f24) = -1 ENOTTY (Inappropriate ioctl
for device)
write(2, "ioctl(): Inappropriate ioctl for"..., 39ioctl(): Inappropriate
ioctl for device) = 39
write(2, "\n", 1
) = 1
----------------------
I bisected the latest kernel source code today.
Result:
77b9040195dea3fcddf19e136c9e99a501351778 is the first bad commit
commit 77b9040195dea3fcddf19e136c9e99a501351778
Author: Arnd Bergmann <[email protected]>
Date: Wed Nov 27 21:25:36 2019 +0100
compat_ioctl: simplify the implementation
Now that both native and compat ioctl syscalls are
in the same file, a couple of simplifications can
be made, bringing the implementation closer together:
- do_vfs_ioctl(), ioctl_preallocate(), and compat_ioctl_preallocate()
can become static, allowing the compiler to optimize better
- slightly update the coding style for consistency between
the functions.
- rather than listing each command in two switch statements
for the compat case, just call a single function that has
all the common commands.
As a side-effect, FS_IOC_RESVSP/FS_IOC_RESVSP64 are now available
to x86 compat tasks, along with FS_IOC_RESVSP_32/FS_IOC_RESVSP64_32.
This is harmless for i386 emulation, and can be considered a bugfix
for x32 emulation, which never supported these in the past.
Reviewed-by: Ben Hutchings <[email protected]>
Signed-off-by: Arnd Bergmann <[email protected]>
:040000 040000 5c4b62f4d1bfe643d3bbf9d9a3b50ee50ae0f159
5ca610e3197df96adfcae4f94fceeb496756609b M fs
:040000 040000 086f2e2ac49384988733cbb706243943748c4ce7
b906926e53dfa2e8927629e77a0708dda6f49d31 M include
----------------------
Link to the first bad commit:
https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/commit/?id=77b9040195dea3fcddf19e136c9e99a501351778
I was able to revert the first bad commit.
git revert 77b9040195dea3fcddf19e136c9e99a501351778
[master a91dcf9dc14c] Revert "compat_ioctl: simplify the implementation"
4 files changed, 105 insertions(+), 64 deletions(-)
After that the avahi daemon works without any problems again.
I created a patch today. (attached)
It is also possible to deactivate the avahi daemon with the following lines
in the file "/etc/avahi/avahi-daemon.conf":
use-ipv4=no
use-ipv6=no
Could you please check your commit?
Thanks,
Christian
On Fri, Feb 7, 2020 at 3:34 PM Christian Zigotzky
<[email protected]> wrote:
>
> Hello Arnd,
>
> We regularly compile and test Linux kernels every day during the merge
> window. Since Thursday last week we have very high CPU usage because of
> the avahi daemon on our desktop Linux systems (Ubuntu, Debian etc). The
> avahi daemon produces a lot of the following log message. This generates
> high CPU usage.
>
> Error message: avahi-daemon[2410]: ioctl(): Inappropriate ioctl for device
>
> strace /usr/sbin/avahi-daemon:
>
Thanks a lot for the detailed analysis, with this I immediately saw
what went wrong in my
original commit and I sent you a fix. Please test to ensure that this
correctly addresses
the problem.
Arnd
> On 7. Feb 2020, at 18:08, Arnd Bergmann <[email protected]> wrote:
>
> On Fri, Feb 7, 2020 at 3:34 PM Christian Zigotzky
> <[email protected]> wrote:
>>
>> Hello Arnd,
>>
>> We regularly compile and test Linux kernels every day during the merge
>> window. Since Thursday last week we have very high CPU usage because of
>> the avahi daemon on our desktop Linux systems (Ubuntu, Debian etc). The
>> avahi daemon produces a lot of the following log message. This generates
>> high CPU usage.
>>
>> Error message: avahi-daemon[2410]: ioctl(): Inappropriate ioctl for device
>>
>> strace /usr/sbin/avahi-daemon:
>>
>
> Thanks a lot for the detailed analysis, with this I immediately saw
> what went wrong in my
> original commit and I sent you a fix. Please test to ensure that this
> correctly addresses
> the problem.
>
> Arnd
Hi Arnd,
Thanks a lot for your patch! I will test it as soon as possible.
Cheers,
Christian
Christian Zigotzky <[email protected]> writes:
> On 06 February 2020 at 05:35 am, Michael Ellerman wrote:
>> Christian Zigotzky <[email protected]> writes:
>>> Kernel 5.5 PowerPC is also affected.
>> I don't know what you mean by that. What sha are you talking about?
>>
>> I have a system with avahi running and everything's fine.
>>
>> # grep use- /etc/avahi/avahi-daemon.conf
>> use-ipv4=yes
>> use-ipv6=yes
>>
>> # systemctl status -l --no-pager avahi-daemon
>> ● avahi-daemon.service - Avahi mDNS/DNS-SD Stack
>> Loaded: loaded (/lib/systemd/system/avahi-daemon.service; enabled; vendor preset: enabled)
>> Active: active (running) since Thu 2020-02-06 14:55:34 AEDT; 38min ago
>> Main PID: 1884 (avahi-daemon)
>> Status: "avahi-daemon 0.7 starting up."
>> CGroup: /system.slice/avahi-daemon.service
>> ├─1884 avahi-daemon: running [mpe-ubuntu-le.local]
>> └─1888 avahi-daemon: chroot helper
>>
>> Feb 06 14:55:34 mpe-ubuntu-le avahi-daemon[1884]: Registering new address record for fe80::5054:ff:fe66:2a19 on eth0.*.
>> Feb 06 14:55:34 mpe-ubuntu-le avahi-daemon[1884]: Registering new address record for 10.61.141.81 on eth0.IPv4.
>> Feb 06 14:55:34 mpe-ubuntu-le avahi-daemon[1884]: Registering new address record for ::1 on lo.*.
>> Feb 06 14:55:34 mpe-ubuntu-le avahi-daemon[1884]: Registering new address record for 127.0.0.1 on lo.IPv4.
>> Feb 06 14:55:34 mpe-ubuntu-le systemd[1]: Started Avahi mDNS/DNS-SD Stack.
>> Feb 06 14:55:35 mpe-ubuntu-le avahi-daemon[1884]: Server startup complete. Host name is mpe-ubuntu-le.local. Local service cookie is 3972418141.
>> Feb 06 14:55:38 mpe-ubuntu-le avahi-daemon[1884]: Leaving mDNS multicast group on interface eth0.IPv6 with address fe80::5054:ff:fe66:2a19.
>> Feb 06 14:55:38 mpe-ubuntu-le avahi-daemon[1884]: Joining mDNS multicast group on interface eth0.IPv6 with address fd69:d75f:b8b5:61:5054:ff:fe66:2a19.
>> Feb 06 14:55:38 mpe-ubuntu-le avahi-daemon[1884]: Registering new address record for fd69:d75f:b8b5:61:5054:ff:fe66:2a19 on eth0.*.
>> Feb 06 14:55:38 mpe-ubuntu-le avahi-daemon[1884]: Withdrawing address record for fe80::5054:ff:fe66:2a19 on eth0.
>>
>> # uname -r
>> 5.5.0-gcc-8.2.0
>>
>>
>> The key question is what ioctl is it complaining about. You should be
>> able to find that via strace.
>>
>> cheers
>>
> Hello Michael,
>
> Sorry it isn't true that the kernel 5.5 is also affected. A Power Mac G5
> user told me that but this isn't correct. I compiled and tested the
> stable kernel 5.5.1 and 5.5.2 today and both kernels don't have the
> issue with the avahi daemon.
OK good to know.
> Could you please also test the latest Git kernel?
That's literally all I ever do.
The problem here is you didn't tell me you were running a big endian
distro, which uses compat mode.
In hindsight I should have thought of that.
Now that I know that, I can reproduce the bug:
Feb 08 23:31:12 mpe-ubuntu-be avahi-daemon[24819]: ioctl(): Inappropriate ioctl for device
Feb 08 23:31:12 mpe-ubuntu-be avahi-daemon[24819]: ioctl(): Inappropriate ioctl for device
Feb 08 23:31:12 mpe-ubuntu-be avahi-daemon[24819]: ioctl(): Inappropriate ioctl for device
Feb 08 23:31:12 mpe-ubuntu-be avahi-daemon[24819]: ioctl(): Inappropriate ioctl for device
But it seems you've already identified the problem commit, thanks for
bisecting.
I'm sure Arnd will be able to fix it now that you've identified the
problematic commit.
cheers
> strace /usr/sbin/avahi-daemon
>
> ...
> poll([{fd=4, events=POLLIN}, {fd=16, events=POLLIN}, {fd=15,
> events=POLLIN}, {fd=14, events=POLLIN}, {fd=13, events=POLLIN}, {fd=12,
> events=POLLIN}, {fd=11, events=POLLIN}, {fd=10, events=POLLIN}, {fd=9,
> events=POLLIN}, {fd=8, events=POLLIN}, {fd=6, events=POLLIN}], 11, 65) =
> 2 ([{fd=12, revents=POLLIN}, {fd=9, revents=POLLIN}])
> ioctl(12, FIONREAD, 0xffba6f24) = -1 ENOTTY (Inappropriate ioctl
> for device)
> write(2, "ioctl(): Inappropriate ioctl for"..., 39ioctl(): Inappropriate
> ioctl for device) = 39
> write(2, "\n", 1
> ) = 1
> ...
>
> Thanks,
> Christian
On 08 February 2020 at 07:59 am, Christian Zigotzky wrote:
>
>> On 7. Feb 2020, at 18:08, Arnd Bergmann <[email protected]> wrote:
>>
>> On Fri, Feb 7, 2020 at 3:34 PM Christian Zigotzky
>> <[email protected]> wrote:
>>> Hello Arnd,
>>>
>>> We regularly compile and test Linux kernels every day during the merge
>>> window. Since Thursday last week we have very high CPU usage because of
>>> the avahi daemon on our desktop Linux systems (Ubuntu, Debian etc). The
>>> avahi daemon produces a lot of the following log message. This generates
>>> high CPU usage.
>>>
>>> Error message: avahi-daemon[2410]: ioctl(): Inappropriate ioctl for device
>>>
>>> strace /usr/sbin/avahi-daemon:
>>>
>> Thanks a lot for the detailed analysis, with this I immediately saw
>> what went wrong in my
>> original commit and I sent you a fix. Please test to ensure that this
>> correctly addresses
>> the problem.
>>
>> Arnd
> Hi Arnd,
>
> Thanks a lot for your patch! I will test it as soon as possible.
>
> Cheers,
> Christian
Hi Arnd,
I successfully compiled the latest Git kernel with your patch today. The
avahi daemon works fine now. That means your patch has solved the avahi
issue.
Thanks for your patch and have a nice weekend!
Cheers,
Christian