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
