On Mon, 8 Apr 2019 at 12:20, Wen Gong <wgong@xxxxxxxxxxxxxxxx> wrote: > > -----Original Message----- > > From: Wen Gong > > Sent: Monday, April 1, 2019 2:11 PM > > To: 'Michał Kazior' <kazikcz@xxxxxxxxx> > > Cc: Wen Gong <wgong@xxxxxxxxxxxxxx>; linux-wireless <linux- > > wireless@xxxxxxxxxxxxxxx>; ath10k@xxxxxxxxxxxxxxxxxxx > > Subject: RE: [EXT] Re: [PATCH] ath10k: Remove ATH10K_STATE_RESTARTED in > > simulate fw crash > > > > > > > > If it's still bothering you then please consider a crash counter > > > threshold so that, e.g. after 5 crash-while-restarting it's going to > > > give up. However I doubt it's worth the effort. My experience tells me > > > firmware crashes during recovery are rarely, if at all, transient. > > > > > > The simulated fw crash is not representative here. It's a mere tool to > > > test driver code. > > > > > Hi Michal, > > There have a stress test case for the simulate fw crash, it will simulate fw > > crash > > in a very short time for each test, this will trigger the stress test fail. > > The simulate fw crash process should not be run parallel, after this patch, the > > Stress test case will pass. > > > > > Hi Michał, > Do you have some new comments? My original use case was to be able to exercise the driver's robustness in handling nested fw crashes, IOW crash-within-a-crash. Your test case, as far as I understand, intends to perform consecutive, non-nested fw crash simulation stress test. Both of these are mutually exclusive and your patch fixes your test case at the expense of breaking my original case. To satisfy both I would suggest you either expose ar->state via debugfs and make your test procedure wait for that to get back into ON state before simulating a crash again, or to extend the set of current simulate_fw_crash commands (currently just: soft, hard, assert, hw-restart) to something that allows expressing the intent whether crash-in-crash prevention is intended (your case) or not (my original case). This could be for example something like this: echo soft wait-ready > simulate_fw_crash The "wait-ready" extra keyword would imply crash-in-crash prevention. This would keep existing tools working (both behavior and syntax) and would allow your test case to be implemented. Michał
