http://bugzilla.opensuse.org/show_bug.cgi?id=944978
http://bugzilla.opensuse.org/show_bug.cgi?id=944978#c69
--- Comment #69 from Larry Finger
(In reply to Larry Finger from comment #55)
There is an error in the logic of this parameter. To handle the critical cases, the logic should enable clear interrupts, and allow the user to disable them if that works OK. The problem is that the code makes the wrong test. At this point, I'm not sure what change I should make.
Let's start from the clear definition of the flag and the parameter :)
In one place: MODULE_PARM_DESC(int_clear, "Set to 1 to disable interrupt clear before set (default 0)\n");
In another place: struct rtl_mod_params { .... /* default 0: 1 means do not disable interrupts */ bool int_clear;
and yet it's evaluated like: if (!rtlpci->int_clear) rtl8821ae_clear_interrupt(hw);/*clear it here first*/
IMO, what "int_clear" implies is to clear int -- so if it's 1, it should do clear interrupts. The description should be aligned with it.
One thing I'm not sure is about your intention of the default int_clear behavior. Should it clear as default (for fixing this kind of bugs with risk of other breakage), or not clear (keeping 4.0 behavior as is but just provide an option to fix)?
The interrupt clear change proposal came from Realtek, where they found that clearing the interrupts caused pauses in transmissions when using iperf. When it was reported that this commit caused a regression that led to this lockup for a few rtl8821ae units, reversion of the entire patch was proposed. I NACKed that request and came up with this change. As you noted, I botched it. For maximum availability, the default value of int_clear should enable the clearing of interrupts. Then if a user complains of the TX pauses, then we suggest that they change the parameter. The parameter should be set to 1 (true) and interrupts should be cleared under that option. I will be submitting a patch through the normal wireless channels. Once it hits wireless-drivers-next, I will report the commit here. Just for the record, this problem affects very few systems. Neither Realtek's or my setup have this problem, which complicates the debugging. -- You are receiving this mail because: You are on the CC list for the bug.