On Sep 9 20:34, poma wrote: > On 09/09/2015 05:55 PM, Corinna Vinschen wrote: > > On Sep 9 17:54, Corinna Vinschen wrote: > >> On Sep 9 17:24, poma wrote: > >>> [PATCH net] r8169: Fix sleeping function called during get_stats64 > >>> http://marc.info/?l=linux-netdev&m=144180123410135&q=raw > >>> - the noise is still present > >> > >> Are you really sure? The entire dma_alloc/dma_free stuff has been moved > >> away. There's no locking or sleeping involved different from what was > >> there before my original patch when calling .ndo_get_stats64. > >> > > > It is literally the kernel ring buffer output, > so I really can not understand your question.
I'm asking because I'm wondering if you're actually testing the right r8169.ko module, the one with the patch applied. See below. > >> How would I be able to reproduce this on the command line? > > This I have already written, here's once more for you, > <quote> > This noise is induced via userspace, xfce4-netload-plugin, > http://goodies.xfce.org/projects/panel-plugins/xfce4-netload-plugin > > $ grep -i device .config/xfce4/panel/netload-16.rc > Network_Device=enp3s0 > > $ ethtool -i enp3s0 | grep driver > driver: r8169 > </quote> > > Therefore, to try to reproduce this issue, 'xfce4-netload-plugin' must run > within 'xfce4-panel', > moreover 'xfce4-netload-plugin' must be configured to monitor affected > network interface. I'lll see if I can try this tomorrow. > No command line this time, hombre. If it has to be spanish, I'd prefer mujer, but whatever. > > It would also be interesting to see the "noise" as it looks after > > applying the above patch... > > The "noise" after applying "r8169: Fix sleeping function called during > get_stats64": > [...] > [ 215.049067] Call Trace: > [ 215.049078] [<ffffffff8184b6c1>] dump_stack+0x4b/0x63 > [ 215.049090] [<ffffffff81100d77>] lockdep_rcu_suspicious+0xd7/0x110 > [ 215.049099] [<ffffffff810d5377>] ___might_sleep+0xa7/0x230 > [ 215.049107] [<ffffffff810d5549>] __might_sleep+0x49/0x80 > [ 215.049121] [<ffffffff811e575e>] __alloc_pages_nodemask+0x2fe/0xb90 > [ 215.049130] [<ffffffff81121b0d>] ? debug_lockdep_rcu_enabled+0x1d/0x20 > [ 215.049141] [<ffffffff81024b29>] ? sched_clock+0x9/0x10 > [ 215.049149] [<ffffffff810e258c>] ? local_clock+0x1c/0x20 > [ 215.049157] [<ffffffff81121b0d>] ? debug_lockdep_rcu_enabled+0x1d/0x20 > [ 215.049168] [<ffffffff810218e6>] dma_generic_alloc_coherent+0x96/0x130 > [ 215.049178] [<ffffffff81069865>] x86_swiotlb_alloc_coherent+0x25/0x50 > [ 215.049193] [<ffffffff810215fd>] dma_alloc_attrs+0x6d/0xe0 > [ 215.049208] [<ffffffffa002e25e>] rtl8169_map_counters+0x3e/0x70 [r8169] This is very certainly not the r8169.ko driver with my patch applied. There is no rtl8169_map_counters function anymore, just as with Francois' patch. I'm not sure what you're doing wrong there, but this stack dump definitely cannot be produced with either Francois or my patch, so you're apparently testing the unpatched upstream driver all the time. > ... > etc. > etc. > etc. > > This looks the same as at the beginning, as if you were dealing with > an entirely different problem, hombre. No, sorry, it's you running the wrong kernel module, and a single occurence of the stack dump would have been sufficient, but thanks all the same. Corinna
pgpskJpMKmMHs.pgp
Description: PGP signature
