Hi Stanislaw, On Wed, 2011-02-23 at 02:57 -0800, Stanislaw Gruszka wrote: > Hi Wey > > On Mon, Feb 21, 2011 at 11:45:33AM -0800, Wey-Yi Guy wrote: > > If device has serious problem and cause firmware can not recover itself. > > Keep reloading firmware will not help, it can only fill up the syslog and > > lock up the system because busy reloading. > Filling up logs could be simply avoided by limiting number of prints. > > > Introduce the limit reload counter, if the reload reach the maximum within > > the pre-defined duration;stop the reload operation. > We have already one mechanism for limit too frequent firmware reload, > way not reuse it? > > > + reload_msec = jiffies_to_msecs((long) reload_jiffies - > > + (long) priv->reload_jiffies); > What for are these (long) casts? > > > + /* firmware reload counter and timestamp */ > > + unsigned long reload_jiffies; > You do not initialize it, first reload_msec will have untrue value. > I am assuming it will initialized to zero at load time, but you are right, I still should initialize it, I will submit separated patch to initialize it. > Beside, all these reload firmware mechanism are just crappy workarounds > for real firmware and/or driver bugs. Instead of creating such patches, > Intel should fix real problems in firmware and driver in first place, > such reloading will be not needed. > I am also wish we can root cause the firmware problem and fix, but it take time and if we logging continuous crash and it will fill the log very fast, the side issue also cause system become un-usable because the continuous reload. Wey -- 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
