Lewis Robbins <lewis.robbins2@xxxxxxxxx> wrote: > > Ping-Ke Shih <pkshih@xxxxxxxxxxx> writes: > > > Lewis Robbins <lewis.robbins2@xxxxxxxxx> wrote: > >> > >> Reduce the log message severity when we fail to flush device priority > >> queue. If a system has a lot of traffic, we may fail to flush the queue > >> in time. This generates a lot of messages in the kernel ring buffer. As > >> this is a common occurrence, we should use dev_info instead of dev_warn. > >> > >> Signed-off-by: Lewis Robbins <lewis.robbins2@xxxxxxxxx> > > > > Acked-by: Ping-Ke Shih <pkshih@xxxxxxxxxxx> > > > > I'd like to know situations of " If a system has a lot of traffic...". > > Did you scan or do something during traffic? > > So, after digging a bit more, it seems you're right this only happens during a > scan. The log message itself is repeated about 5-10x. That is the same as my test before. > > I'm not sure as to the cause. If the flush operation takes a long time do we > need to release any mutexes etc? And if this is just a hardware issue, then we > can do a debug print as you say. The cause is because packets in hardware TX queue that can't be sent out in time, and flush ops with 'drop = false', so driver throws one warning. I don't have good idea for now. Maybe, we can add a special debug mask to replace this kind of verbose warning with uncertain solution.
