Re: Kernel Oops in cdc_acm

[Jean Rene Dawin <jdawin@math.uni-bielefeld.de>]

Oliver Neukum wrote on Wed 27/05/20 10:53:
> OK, we have two possibilities here. Either
> a4e7279cd1d19f48f0af2a10ed020febaa9ac092 or
> 0afccd7601514c4b83d8cc58c740089cc447051d
> 
> have had a really wierd effect, or they introduced a bug
> that hid a later bug. Can I ask you to run a complicated test
> to decide between these possibilities?
> 
> Could you test a4e7279cd1d19f48f0af2a10ed020febaa9ac092
> together with the patch I sent you applied on top?

Hi,

I tested 0afccd7601514c4b83d8cc58c740089cc447051d and couldn't get it to
show the symptoms.

Then I tested a4e7279cd1d19f48f0af2a10ed020febaa9ac092 with your patch
applied and it still showed the symptom

[  730.590055] Call Trace:
[  730.590058]  <IRQ>
[  730.590062]  queue_work_on+0x36/0x40
[  730.590065]  __usb_hcd_giveback_urb+0x6f/0x120
[  730.590067]  usb_giveback_urb_bh+0xa6/0x100
[  730.590070]  tasklet_action_common.isra.0+0x5f/0x130
[  730.590074]  __do_softirq+0x111/0x34d
[  730.590077]  irq_exit+0xac/0xd0
[  730.590078]  do_IRQ+0x89/0x140
[  730.590080]  common_interrupt+0xf/0xf

but very non-deterministic. The first time the error came up after
the battery was removed the second time. Then after the fourth time. 
And testing again this morning it was after six removals.
I will try to narrow the conditions that tirgger the behaviour.
It seems the timing is important.

Regards,
Jean Rene