All of lore.kernel.org
 help / color / mirror / Atom feed
* Fwd: usb_8dev - WARN_ON(in_irq()) Ticket #00560
@ 2020-04-03 13:04 Andrejus Falčikas
  2020-04-03 13:26 ` Wolfgang Grandegger
  0 siblings, 1 reply; 8+ messages in thread
From: Andrejus Falčikas @ 2020-04-03 13:04 UTC (permalink / raw)
  To: socketcan; +Cc: michal.sojka, linux-can

Hello Mr. Oliver Hartkopp,

I would like to notify you that the case described as the issue is
caused by non-standard use of the device and protocol.

Firstly, the model situation with only a single device on the CAN bus
is invalid and very rarely occurs in real life due to the purpose and
underlying principles of the CAN2.0 protocol. Every CAN message sent
to the bus should be acknowledged by other bus node(s) or it will
increment the error counter and will be retransmitted.

The proper usage of a single device (e. g. for testing or
self-diagnostic purposes) would be to enable loopback mode on when
initialising the device in question, as that will ensure that the
device acknowledges the messages it sends to the bus.

Secondly, usage of termination resistors is a must on a CAN bus, and
according to ISO 11898-2 (CAN High Speed) standard the bus is a linear
bus that must be terminated at each end with 120 Ohm resistors. The
termination resistors are needed to suppress reflections as well as
return the bus to its recessive or idle state.

Moreover, the kernel warnings appear to be caused by the socketCAN
layer using netif_rx() function inside an interrupt, they can be
easily recreated using the obsoleted first generation USB2CAN device
and most likely any other device using socketCAN.

Finally, TX URB aborted(-2) errors are expected in the described
scenario as error code -2 (-ENODEV) simply notifies that the specified
device for the URB to be submitted no longer exists (as is expected
when device is brought down).

Taking into account the findings above we will close this ticket as
the issue was caused by non-standard usage of the device.

Best regards,
Andrejus F.

^ permalink raw reply	[flat|nested] 8+ messages in thread

* Re: Fwd: usb_8dev - WARN_ON(in_irq()) Ticket #00560
  2020-04-03 13:04 Fwd: usb_8dev - WARN_ON(in_irq()) Ticket #00560 Andrejus Falčikas
@ 2020-04-03 13:26 ` Wolfgang Grandegger
  2020-04-03 13:53   ` Michal Sojka
  0 siblings, 1 reply; 8+ messages in thread
From: Wolfgang Grandegger @ 2020-04-03 13:26 UTC (permalink / raw)
  To: Andrejus Falčikas, socketcan; +Cc: michal.sojka, linux-can

Hello Andrejus,

please do not remove the history of this conversation! It's very
difficult to follow what you are speaking about...

Am 03.04.20 um 15:04 schrieb Andrejus Falčikas:
> Hello Mr. Oliver Hartkopp,
> 
> I would like to notify you that the case described as the issue is
> caused by non-standard use of the device and protocol.
> 
> Firstly, the model situation with only a single device on the CAN bus
> is invalid and very rarely occurs in real life due to the purpose and
> underlying principles of the CAN2.0 protocol. Every CAN message sent
> to the bus should be acknowledged by other bus node(s) or it will
> increment the error counter and will be retransmitted.
> 
> The proper usage of a single device (e. g. for testing or
> self-diagnostic purposes) would be to enable loopback mode on when
> initialising the device in question, as that will ensure that the
> device acknowledges the messages it sends to the bus.
> 
> Secondly, usage of termination resistors is a must on a CAN bus, and
> according to ISO 11898-2 (CAN High Speed) standard the bus is a linear
> bus that must be terminated at each end with 120 Ohm resistors. The
> termination resistors are needed to suppress reflections as well as
> return the bus to its recessive or idle state.
> 
> Moreover, the kernel warnings appear to be caused by the socketCAN
> layer using netif_rx() function inside an interrupt, they can be
> easily recreated using the obsoleted first generation USB2CAN device
> and most likely any other device using socketCAN.

I observe a similar problem with the GS_USB CAN controller and I have
posted a patch recently here:

  https://marc.info/?l=linux-can&m=158504888512764&w=2

Could you please give the patch for your device below a try:

diff --git a/drivers/net/can/usb/usb_8dev.c b/drivers/net/can/usb/usb_8dev.c
index 8fa224b..c9bb225 100644
--- a/drivers/net/can/usb/usb_8dev.c
+++ b/drivers/net/can/usb/usb_8dev.c
@@ -575,7 +575,7 @@ static void usb_8dev_write_bulk_callback(struct urb *urb)
 
 	atomic_dec(&priv->active_tx_urbs);
 
-	if (!netif_device_present(netdev))
+	if (!netif_device_present(netdev) || !netif_running(netdev))
 		return;
 
 	if (urb->status)


Wolfgang

^ permalink raw reply related	[flat|nested] 8+ messages in thread

* Re: Fwd: usb_8dev - WARN_ON(in_irq()) Ticket #00560
  2020-04-03 13:26 ` Wolfgang Grandegger
@ 2020-04-03 13:53   ` Michal Sojka
  2020-04-09  6:46     ` Andrejus Falčikas
  0 siblings, 1 reply; 8+ messages in thread
From: Michal Sojka @ 2020-04-03 13:53 UTC (permalink / raw)
  To: Wolfgang Grandegger, Andrejus Falčikas, socketcan; +Cc: linux-can

Hello Wolfgang,

On Fri, Apr 03 2020, Wolfgang Grandegger wrote:
> Hello Andrejus,
>
> please do not remove the history of this conversation! It's very
> difficult to follow what you are speaking about...
>
> Am 03.04.20 um 15:04 schrieb Andrejus Falčikas:
>> Hello Mr. Oliver Hartkopp,
>> 
>> I would like to notify you that the case described as the issue is
>> caused by non-standard use of the device and protocol.

[...]

>
> I observe a similar problem with the GS_USB CAN controller and I have
> posted a patch recently here:
>
>   https://marc.info/?l=linux-can&m=158504888512764&w=2
>
> Could you please give the patch for your device below a try:

It would be great if Andrejus can try the patch. If not, I'll try it
after I get back to work where I have the device. Unfortunately, due to
current situation, I'm not sure when it will happen.

Thanks.
-Michal

^ permalink raw reply	[flat|nested] 8+ messages in thread

* Re: Fwd: usb_8dev - WARN_ON(in_irq()) Ticket #00560
  2020-04-03 13:53   ` Michal Sojka
@ 2020-04-09  6:46     ` Andrejus Falčikas
  2020-04-09 10:25       ` Wolfgang Grandegger
  0 siblings, 1 reply; 8+ messages in thread
From: Andrejus Falčikas @ 2020-04-09  6:46 UTC (permalink / raw)
  To: Michal Sojka; +Cc: Wolfgang Grandegger, socketcan, linux-can

Hello,

this Ticket #00560 is closed.

Best regards,
Andrejus F.

On Fri, Apr 3, 2020 at 4:53 PM Michal Sojka <michal.sojka@cvut.cz> wrote:
>
> Hello Wolfgang,
>
> On Fri, Apr 03 2020, Wolfgang Grandegger wrote:
> > Hello Andrejus,
> >
> > please do not remove the history of this conversation! It's very
> > difficult to follow what you are speaking about...
> >
> > Am 03.04.20 um 15:04 schrieb Andrejus Falčikas:
> >> Hello Mr. Oliver Hartkopp,
> >>
> >> I would like to notify you that the case described as the issue is
> >> caused by non-standard use of the device and protocol.
>
> [...]
>
> >
> > I observe a similar problem with the GS_USB CAN controller and I have
> > posted a patch recently here:
> >
> >   https://marc.info/?l=linux-can&m=158504888512764&w=2
> >
> > Could you please give the patch for your device below a try:
>
> It would be great if Andrejus can try the patch. If not, I'll try it
> after I get back to work where I have the device. Unfortunately, due to
> current situation, I'm not sure when it will happen.
>
> Thanks.
> -Michal

^ permalink raw reply	[flat|nested] 8+ messages in thread

* Re: Fwd: usb_8dev - WARN_ON(in_irq()) Ticket #00560
  2020-04-09  6:46     ` Andrejus Falčikas
@ 2020-04-09 10:25       ` Wolfgang Grandegger
  2020-04-09 10:37         ` Andrejus Falčikas
  0 siblings, 1 reply; 8+ messages in thread
From: Wolfgang Grandegger @ 2020-04-09 10:25 UTC (permalink / raw)
  To: Andrejus Falčikas, Michal Sojka; +Cc: socketcan, linux-can


Am 09.04.20 um 08:46 schrieb Andrejus Falčikas:
> Hello,
> 
> this Ticket #00560 is closed.

Which does not mean that the problem is gone ;)

Wolfgang

> On Fri, Apr 3, 2020 at 4:53 PM Michal Sojka <michal.sojka@cvut.cz> wrote:
>>
>> Hello Wolfgang,
>>
>> On Fri, Apr 03 2020, Wolfgang Grandegger wrote:
>>> Hello Andrejus,
>>>
>>> please do not remove the history of this conversation! It's very
>>> difficult to follow what you are speaking about...
>>>
>>> Am 03.04.20 um 15:04 schrieb Andrejus Falčikas:
>>>> Hello Mr. Oliver Hartkopp,
>>>>
>>>> I would like to notify you that the case described as the issue is
>>>> caused by non-standard use of the device and protocol.
>>
>> [...]
>>
>>>
>>> I observe a similar problem with the GS_USB CAN controller and I have
>>> posted a patch recently here:
>>>
>>>   https://marc.info/?l=linux-can&m=158504888512764&w=2
>>>
>>> Could you please give the patch for your device below a try:
>>
>> It would be great if Andrejus can try the patch. If not, I'll try it
>> after I get back to work where I have the device. Unfortunately, due to
>> current situation, I'm not sure when it will happen.
>>
>> Thanks.
>> -Michal
> 
> 

^ permalink raw reply	[flat|nested] 8+ messages in thread

* Re: Fwd: usb_8dev - WARN_ON(in_irq()) Ticket #00560
  2020-04-09 10:25       ` Wolfgang Grandegger
@ 2020-04-09 10:37         ` Andrejus Falčikas
  2020-04-09 10:43           ` Wolfgang Grandegger
  0 siblings, 1 reply; 8+ messages in thread
From: Andrejus Falčikas @ 2020-04-09 10:37 UTC (permalink / raw)
  To: Wolfgang Grandegger; +Cc: Michal Sojka, socketcan, linux-can

Hello,

Thank you Mr. Wolfgang Grandegger for the patch. I checked and the
problem disappeared, any warnings do not appear in dmesg after the
"interface down".

Best regards,
Andrejus F.

On Thu, Apr 9, 2020 at 1:25 PM Wolfgang Grandegger <wg@grandegger.com> wrote:
>
>
> Am 09.04.20 um 08:46 schrieb Andrejus Falčikas:
> > Hello,
> >
> > this Ticket #00560 is closed.
>
> Which does not mean that the problem is gone ;)
>
> Wolfgang
>
> > On Fri, Apr 3, 2020 at 4:53 PM Michal Sojka <michal.sojka@cvut.cz> wrote:
> >>
> >> Hello Wolfgang,
> >>
> >> On Fri, Apr 03 2020, Wolfgang Grandegger wrote:
> >>> Hello Andrejus,
> >>>
> >>> please do not remove the history of this conversation! It's very
> >>> difficult to follow what you are speaking about...
> >>>
> >>> Am 03.04.20 um 15:04 schrieb Andrejus Falčikas:
> >>>> Hello Mr. Oliver Hartkopp,
> >>>>
> >>>> I would like to notify you that the case described as the issue is
> >>>> caused by non-standard use of the device and protocol.
> >>
> >> [...]
> >>
> >>>
> >>> I observe a similar problem with the GS_USB CAN controller and I have
> >>> posted a patch recently here:
> >>>
> >>>   https://marc.info/?l=linux-can&m=158504888512764&w=2
> >>>
> >>> Could you please give the patch for your device below a try:
> >>
> >> It would be great if Andrejus can try the patch. If not, I'll try it
> >> after I get back to work where I have the device. Unfortunately, due to
> >> current situation, I'm not sure when it will happen.
> >>
> >> Thanks.
> >> -Michal
> >
> >

^ permalink raw reply	[flat|nested] 8+ messages in thread

* Re: Fwd: usb_8dev - WARN_ON(in_irq()) Ticket #00560
  2020-04-09 10:37         ` Andrejus Falčikas
@ 2020-04-09 10:43           ` Wolfgang Grandegger
  2020-04-09 13:00             ` Andrejus Falčikas
  0 siblings, 1 reply; 8+ messages in thread
From: Wolfgang Grandegger @ 2020-04-09 10:43 UTC (permalink / raw)
  To: Andrejus Falčikas; +Cc: Michal Sojka, socketcan, linux-can

Hello Andrejus,

thanks for testing. Can I have your

Tested-by: Andrejus Falčikas <andrejus.f@8devices.com> ?

Wolfgang

Am 09.04.20 um 12:37 schrieb Andrejus Falčikas:
> Hello,
> 
> Thank you Mr. Wolfgang Grandegger for the patch. I checked and the
> problem disappeared, any warnings do not appear in dmesg after the
> "interface down".
> 
> Best regards,
> Andrejus F.
> 
> On Thu, Apr 9, 2020 at 1:25 PM Wolfgang Grandegger <wg@grandegger.com> wrote:
>>
>>
>> Am 09.04.20 um 08:46 schrieb Andrejus Falčikas:
>>> Hello,
>>>
>>> this Ticket #00560 is closed.
>>
>> Which does not mean that the problem is gone ;)
>>
>> Wolfgang
>>
>>> On Fri, Apr 3, 2020 at 4:53 PM Michal Sojka <michal.sojka@cvut.cz> wrote:
>>>>
>>>> Hello Wolfgang,
>>>>
>>>> On Fri, Apr 03 2020, Wolfgang Grandegger wrote:
>>>>> Hello Andrejus,
>>>>>
>>>>> please do not remove the history of this conversation! It's very
>>>>> difficult to follow what you are speaking about...
>>>>>
>>>>> Am 03.04.20 um 15:04 schrieb Andrejus Falčikas:
>>>>>> Hello Mr. Oliver Hartkopp,
>>>>>>
>>>>>> I would like to notify you that the case described as the issue is
>>>>>> caused by non-standard use of the device and protocol.
>>>>
>>>> [...]
>>>>
>>>>>
>>>>> I observe a similar problem with the GS_USB CAN controller and I have
>>>>> posted a patch recently here:
>>>>>
>>>>>   https://marc.info/?l=linux-can&m=158504888512764&w=2
>>>>>
>>>>> Could you please give the patch for your device below a try:
>>>>
>>>> It would be great if Andrejus can try the patch. If not, I'll try it
>>>> after I get back to work where I have the device. Unfortunately, due to
>>>> current situation, I'm not sure when it will happen.
>>>>
>>>> Thanks.
>>>> -Michal
>>>
>>>
> 
> 

^ permalink raw reply	[flat|nested] 8+ messages in thread

* Re: Fwd: usb_8dev - WARN_ON(in_irq()) Ticket #00560
  2020-04-09 10:43           ` Wolfgang Grandegger
@ 2020-04-09 13:00             ` Andrejus Falčikas
  0 siblings, 0 replies; 8+ messages in thread
From: Andrejus Falčikas @ 2020-04-09 13:00 UTC (permalink / raw)
  To: Wolfgang Grandegger; +Cc: Michal Sojka, socketcan, linux-can

Hello,
fix tested and committed to 8devices repository, a pending pull
request https://github.com/krumboeck/usb2can/pull/12 created..

Best regards,
Andrejus F

On Thu, Apr 9, 2020 at 1:43 PM Wolfgang Grandegger <wg@grandegger.com> wrote:
>
> Hello Andrejus,
>
> thanks for testing. Can I have your
>
> Tested-by: Andrejus Falčikas <andrejus.f@8devices.com> ?
>
> Wolfgang
>
> Am 09.04.20 um 12:37 schrieb Andrejus Falčikas:
> > Hello,
> >
> > Thank you Mr. Wolfgang Grandegger for the patch. I checked and the
> > problem disappeared, any warnings do not appear in dmesg after the
> > "interface down".
> >
> > Best regards,
> > Andrejus F.
> >
> > On Thu, Apr 9, 2020 at 1:25 PM Wolfgang Grandegger <wg@grandegger.com> wrote:
> >>
> >>
> >> Am 09.04.20 um 08:46 schrieb Andrejus Falčikas:
> >>> Hello,
> >>>
> >>> this Ticket #00560 is closed.
> >>
> >> Which does not mean that the problem is gone ;)
> >>
> >> Wolfgang
> >>
> >>> On Fri, Apr 3, 2020 at 4:53 PM Michal Sojka <michal.sojka@cvut.cz> wrote:
> >>>>
> >>>> Hello Wolfgang,
> >>>>
> >>>> On Fri, Apr 03 2020, Wolfgang Grandegger wrote:
> >>>>> Hello Andrejus,
> >>>>>
> >>>>> please do not remove the history of this conversation! It's very
> >>>>> difficult to follow what you are speaking about...
> >>>>>
> >>>>> Am 03.04.20 um 15:04 schrieb Andrejus Falčikas:
> >>>>>> Hello Mr. Oliver Hartkopp,
> >>>>>>
> >>>>>> I would like to notify you that the case described as the issue is
> >>>>>> caused by non-standard use of the device and protocol.
> >>>>
> >>>> [...]
> >>>>
> >>>>>
> >>>>> I observe a similar problem with the GS_USB CAN controller and I have
> >>>>> posted a patch recently here:
> >>>>>
> >>>>>   https://marc.info/?l=linux-can&m=158504888512764&w=2
> >>>>>
> >>>>> Could you please give the patch for your device below a try:
> >>>>
> >>>> It would be great if Andrejus can try the patch. If not, I'll try it
> >>>> after I get back to work where I have the device. Unfortunately, due to
> >>>> current situation, I'm not sure when it will happen.
> >>>>
> >>>> Thanks.
> >>>> -Michal
> >>>
> >>>
> >
> >

^ permalink raw reply	[flat|nested] 8+ messages in thread

end of thread, other threads:[~2020-04-09 13:00 UTC | newest]

Thread overview: 8+ messages (download: mbox.gz / follow: Atom feed)
-- links below jump to the message on this page --
2020-04-03 13:04 Fwd: usb_8dev - WARN_ON(in_irq()) Ticket #00560 Andrejus Falčikas
2020-04-03 13:26 ` Wolfgang Grandegger
2020-04-03 13:53   ` Michal Sojka
2020-04-09  6:46     ` Andrejus Falčikas
2020-04-09 10:25       ` Wolfgang Grandegger
2020-04-09 10:37         ` Andrejus Falčikas
2020-04-09 10:43           ` Wolfgang Grandegger
2020-04-09 13:00             ` Andrejus Falčikas

This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.