Search Linux Wireless

RE: [Ilw] [RFC 0/5] mac80211/iwlwifi: quiesce before restart hw

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

 



> Here is continuation of short discussion I started here:
> http://marc.info/?l=linux-wireless&m=137724899704012&w=2
> 
> I made patches which do quiesce and that can be used by iwlwifi restart
> procedure to avoid calling iwlwifi methods by mac80211 while firmware is not
> alive.
> 
> But honestly, I'm not happy with that work. It does not fix root of the
> problem (microcode errors/hangs) and seems to be just to much
> complication to avoid warnings, which are consequence of firmware
> malfunction. So I just prefer to remove WARN_ONCE(trans->state !=
> IWL_TRANS_FW_ALIVE) and replace it by ordinary IWL_WARN(), which does
> not generate auto bug reports.
> 
> Regarding firmware problems debugging, perhaps ftrace can be used for
> that. iwlwifi has already tracing capabilities. Allow to gather log using trace-
> cmd and call tracing_off() when firmware error will happen, perhaps will
> allow to debug firmware problems efficiently.
> If you think that's right we could add WARN_ONCE on firmware error to have
> automatic bug reports. Then we could ask user for the trace to debug and
> solve the issue. Would that work for you?
> 

Yes - definitely. We have enough debug information in place in other places. Patch is coming (will go through regular tunnel).
BTW - I guess a dump_stack doesn't trigger the abrt, does it?

--
To unsubscribe from this list: send the line "unsubscribe linux-wireless" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at  http://vger.kernel.org/majordomo-info.html




[Index of Archives]     [Linux Host AP]     [ATH6KL]     [Linux Wireless Personal Area Network]     [Linux Bluetooth]     [Linux Netdev]     [Kernel Newbies]     [Linux Kernel]     [IDE]     [Git]     [Netfilter]     [Bugtraq]     [Yosemite Hiking]     [MIPS Linux]     [ARM Linux]     [Linux RAID]

  Powered by Linux