* 8139cp TX stall, timeout, failed recovery
From: David Woodhouse @ 2012-11-24 18:39 UTC (permalink / raw)
To: netdev; +Cc: romieu, jasowang, gilboad, jgarzik
[-- Attachment #1: Type: text/plain, Size: 33253 bytes --]
When I stress it hard, I see a Tx timeout that it doesn't recover from.
This is 3.6.7, with or without my recent init path patch (and with or
without my BQL patch).
To reproduce this, I send a *large* flood of packets (ping -l 1000) from
inside my network to the ADSL router. Its internal-facing interface is
an 8139cp. It seems to work best if the packets are destined for the
outside world over the ADSL lines, rather than the router itself. But
it's hard to tell. I need between 10 and 30 runs of 'ping -l 1000
$outside' before it happens. Or sometimes more...
Log shows it all running fine, followed by a flood of incoming packets
starting at around 28498.05. At 28498.060901 we queue a new tx, and
*immediately* afterwards (28498.060936) we get an interrupt with status
0x0080 (Tx Descriptor Unavailable, but no Tx Done). That's the last
tx-related interrupt we ever get.
This seems to be a consistent pattern — when we get that 0x0080
interrupt and it dies, it's *very* soon after queueing a new tx:
8139dead2.cap-[27538.841952] 8139cp 0000:00:0b.0: eth1: tx queued, slot 54, skblen 98
8139dead2.cap:[27538.841985] 8139cp 0000:00:0b.0: eth1: intr, status 0080 cmd 0c cpcmd 002b
--
8139dead3a.cap-[28498.060901] 8139cp 0000:00:0b.0: eth1: tx queued, slot 12, skblen 98
8139dead3a.cap:[28498.060936] 8139cp 0000:00:0b.0: eth1: intr, status 0080 cmd 0c cpcmd 002b
--
8139dead4.cap-[30230.248780] 8139cp 0000:00:0b.0: eth1: tx queued, slot 27, skblen 98
8139dead4.cap:[30230.248816] 8139cp 0000:00:0b.0: eth1: intr, status 0080 cmd 0c cpcmd 002b
--
8139dead.cap-[ 228.119159] 8139cp 0000:00:0b.0: eth1: tx queued, slot 63, skblen 98
8139dead.cap:[ 228.119195] 8139cp 0000:00:0b.0: eth1: intr, status 0080 cmd 0c cpcmd 002b
Here's a full log of one of those, showing the failure to recover too...
Looking at it now... do we wrap around the Rx ring buffer at 28498.055
and process some of the packets more than once? Or is the hardware
genuinely keeping up with us as we suck out, descriptors 51-63, 0-63,
and 0-39 again all off the same interrupt? Perhaps there lies the root
of the problem?
[28497.924957] 8139cp 0000:00:0b.0: eth1: rx slot 44 status 0x320141d8 len 468
[28498.032253] 8139cp 0000:00:0b.0: eth1: intr, status 0001 cmd 0c cpcmd 002b
[28498.032300] 8139cp 0000:00:0b.0: eth1: rx slot 45 status 0x32022062 len 94
[28498.040770] 8139cp 0000:00:0b.0: eth1: tx queued, slot 7, skblen 110
[28498.040816] 8139cp 0000:00:0b.0: eth1: intr, status 0484 cmd 0c cpcmd 002b
[28498.040836] 8139cp 0000:00:0b.0: eth1: tx done, slot 6
[28498.041048] 8139cp 0000:00:0b.0: eth1: tx queued, slot 8, skblen 1514
[28498.041090] 8139cp 0000:00:0b.0: eth1: intr, status 0484 cmd 0c cpcmd 002b
[28498.041108] 8139cp 0000:00:0b.0: eth1: tx done, slot 7
[28498.041177] 8139cp 0000:00:0b.0: eth1: tx queued, slot 9, skblen 1514
[28498.041218] 8139cp 0000:00:0b.0: eth1: intr, status 0484 cmd 0c cpcmd 002b
[28498.041236] 8139cp 0000:00:0b.0: eth1: tx done, slot 8
[28498.041677] 8139cp 0000:00:0b.0: eth1: intr, status 0001 cmd 0c cpcmd 002b
[28498.041709] 8139cp 0000:00:0b.0: eth1: rx slot 46 status 0x3200e04e len 74
[28498.041846] 8139cp 0000:00:0b.0: eth1: tx queued, slot 10, skblen 533
[28498.041882] 8139cp 0000:00:0b.0: eth1: intr, status 0484 cmd 0c cpcmd 002b
[28498.041901] 8139cp 0000:00:0b.0: eth1: tx done, slot 9
[28498.043028] 8139cp 0000:00:0b.0: eth1: intr, status 0001 cmd 0c cpcmd 002b
[28498.043056] 8139cp 0000:00:0b.0: eth1: rx slot 47 status 0x3200e04e len 74
[28498.043264] 8139cp 0000:00:0b.0: eth1: intr, status 0001 cmd 0c cpcmd 002b
[28498.043291] 8139cp 0000:00:0b.0: eth1: rx slot 48 status 0x3200e04e len 74
[28498.043456] 8139cp 0000:00:0b.0: eth1: intr, status 0001 cmd 0c cpcmd 002b
[28498.043483] 8139cp 0000:00:0b.0: eth1: rx slot 49 status 0x3200e04e len 74
[28498.043905] 8139cp 0000:00:0b.0: eth1: tx queued, slot 11, skblen 245
[28498.043941] 8139cp 0000:00:0b.0: eth1: intr, status 0484 cmd 0c cpcmd 002b
[28498.043960] 8139cp 0000:00:0b.0: eth1: tx done, slot 10
[28498.051129] 8139cp 0000:00:0b.0: eth1: intr, status 0001 cmd 0c cpcmd 002b
[28498.051165] 8139cp 0000:00:0b.0: eth1: rx slot 50 status 0x32036066 len 98
[28498.051333] 8139cp 0000:00:0b.0: eth1: rx slot 51 status 0x32036066 len 98
[28498.051394] 8139cp 0000:00:0b.0: eth1: rx slot 52 status 0x32036066 len 98
[28498.051451] 8139cp 0000:00:0b.0: eth1: rx slot 53 status 0x32036066 len 98
[28498.051523] 8139cp 0000:00:0b.0: eth1: rx slot 54 status 0x32036066 len 98
[28498.051575] 8139cp 0000:00:0b.0: eth1: rx slot 55 status 0x32036066 len 98
[28498.051623] 8139cp 0000:00:0b.0: eth1: rx slot 56 status 0x32036066 len 98
[28498.051672] 8139cp 0000:00:0b.0: eth1: rx slot 57 status 0x32036066 len 98
[28498.051720] 8139cp 0000:00:0b.0: eth1: rx slot 58 status 0x32036066 len 98
[28498.051771] 8139cp 0000:00:0b.0: eth1: rx slot 59 status 0x32036066 len 98
[28498.051821] 8139cp 0000:00:0b.0: eth1: rx slot 60 status 0x32036066 len 98
[28498.051871] 8139cp 0000:00:0b.0: eth1: rx slot 61 status 0x32036066 len 98
[28498.051962] 8139cp 0000:00:0b.0: eth1: intr, status 0001 cmd 0c cpcmd 002b
[28498.051989] 8139cp 0000:00:0b.0: eth1: rx slot 62 status 0x32036066 len 98
[28498.052041] 8139cp 0000:00:0b.0: eth1: rx slot 63 status 0x72036066 len 98
[28498.052089] 8139cp 0000:00:0b.0: eth1: rx slot 0 status 0x32036066 len 98
[28498.052139] 8139cp 0000:00:0b.0: eth1: rx slot 1 status 0x32036066 len 98
[28498.052189] 8139cp 0000:00:0b.0: eth1: rx slot 2 status 0x32036066 len 98
[28498.052238] 8139cp 0000:00:0b.0: eth1: rx slot 3 status 0x32036066 len 98
[28498.052287] 8139cp 0000:00:0b.0: eth1: rx slot 4 status 0x32036066 len 98
[28498.052370] 8139cp 0000:00:0b.0: eth1: intr, status 0001 cmd 0c cpcmd 002b
[28498.052396] 8139cp 0000:00:0b.0: eth1: rx slot 5 status 0x32036066 len 98
[28498.052446] 8139cp 0000:00:0b.0: eth1: rx slot 6 status 0x32036066 len 98
[28498.052496] 8139cp 0000:00:0b.0: eth1: rx slot 7 status 0x32036066 len 98
[28498.052562] 8139cp 0000:00:0b.0: eth1: rx slot 8 status 0x32036066 len 98
[28498.052612] 8139cp 0000:00:0b.0: eth1: rx slot 9 status 0x32036066 len 98
[28498.052661] 8139cp 0000:00:0b.0: eth1: rx slot 10 status 0x32036066 len 98
[28498.052711] 8139cp 0000:00:0b.0: eth1: rx slot 11 status 0x32036066 len 98
[28498.052760] 8139cp 0000:00:0b.0: eth1: rx slot 12 status 0x32036066 len 98
[28498.052810] 8139cp 0000:00:0b.0: eth1: rx slot 13 status 0x32036066 len 98
[28498.052860] 8139cp 0000:00:0b.0: eth1: rx slot 14 status 0x32036066 len 98
[28498.052975] 8139cp 0000:00:0b.0: eth1: intr, status 0001 cmd 0c cpcmd 002b
[28498.053001] 8139cp 0000:00:0b.0: eth1: rx slot 15 status 0x32036066 len 98
[28498.053053] 8139cp 0000:00:0b.0: eth1: rx slot 16 status 0x32036066 len 98
[28498.053103] 8139cp 0000:00:0b.0: eth1: rx slot 17 status 0x32036066 len 98
[28498.053151] 8139cp 0000:00:0b.0: eth1: rx slot 18 status 0x32036066 len 98
[28498.053201] 8139cp 0000:00:0b.0: eth1: rx slot 19 status 0x32036066 len 98
[28498.053249] 8139cp 0000:00:0b.0: eth1: rx slot 20 status 0x32036066 len 98
[28498.053299] 8139cp 0000:00:0b.0: eth1: rx slot 21 status 0x32036066 len 98
[28498.053348] 8139cp 0000:00:0b.0: eth1: rx slot 22 status 0x32036066 len 98
[28498.053397] 8139cp 0000:00:0b.0: eth1: rx slot 23 status 0x32036066 len 98
[28498.053446] 8139cp 0000:00:0b.0: eth1: rx slot 24 status 0x32036066 len 98
[28498.053495] 8139cp 0000:00:0b.0: eth1: rx slot 25 status 0x32036066 len 98
[28498.053561] 8139cp 0000:00:0b.0: eth1: rx slot 26 status 0x32036066 len 98
[28498.053611] 8139cp 0000:00:0b.0: eth1: rx slot 27 status 0x32036066 len 98
[28498.053661] 8139cp 0000:00:0b.0: eth1: rx slot 28 status 0x32036066 len 98
[28498.053711] 8139cp 0000:00:0b.0: eth1: rx slot 29 status 0x32036066 len 98
[28498.053760] 8139cp 0000:00:0b.0: eth1: rx slot 30 status 0x32036066 len 98
[28498.053810] 8139cp 0000:00:0b.0: eth1: rx slot 31 status 0x32036066 len 98
[28498.053860] 8139cp 0000:00:0b.0: eth1: rx slot 32 status 0x32036066 len 98
[28498.053947] 8139cp 0000:00:0b.0: eth1: intr, status 0001 cmd 0c cpcmd 002b
[28498.053973] 8139cp 0000:00:0b.0: eth1: rx slot 33 status 0x32036066 len 98
[28498.054025] 8139cp 0000:00:0b.0: eth1: rx slot 34 status 0x32036066 len 98
[28498.054074] 8139cp 0000:00:0b.0: eth1: rx slot 35 status 0x32036066 len 98
[28498.054123] 8139cp 0000:00:0b.0: eth1: rx slot 36 status 0x32036066 len 98
[28498.054173] 8139cp 0000:00:0b.0: eth1: rx slot 37 status 0x32036066 len 98
[28498.054222] 8139cp 0000:00:0b.0: eth1: rx slot 38 status 0x32036066 len 98
[28498.054272] 8139cp 0000:00:0b.0: eth1: rx slot 39 status 0x32036066 len 98
[28498.054320] 8139cp 0000:00:0b.0: eth1: rx slot 40 status 0x32036066 len 98
[28498.054405] 8139cp 0000:00:0b.0: eth1: intr, status 0001 cmd 0c cpcmd 002b
[28498.054432] 8139cp 0000:00:0b.0: eth1: rx slot 41 status 0x32036066 len 98
[28498.054482] 8139cp 0000:00:0b.0: eth1: rx slot 42 status 0x32036066 len 98
[28498.054548] 8139cp 0000:00:0b.0: eth1: rx slot 43 status 0x32036066 len 98
[28498.054597] 8139cp 0000:00:0b.0: eth1: rx slot 44 status 0x32036066 len 98
[28498.054648] 8139cp 0000:00:0b.0: eth1: rx slot 45 status 0x32036066 len 98
[28498.054697] 8139cp 0000:00:0b.0: eth1: rx slot 46 status 0x32036066 len 98
[28498.054747] 8139cp 0000:00:0b.0: eth1: rx slot 47 status 0x32036066 len 98
[28498.054796] 8139cp 0000:00:0b.0: eth1: rx slot 48 status 0x32036066 len 98
[28498.054846] 8139cp 0000:00:0b.0: eth1: rx slot 49 status 0x32036066 len 98
[28498.054895] 8139cp 0000:00:0b.0: eth1: rx slot 50 status 0x32036066 len 98
[28498.055030] 8139cp 0000:00:0b.0: eth1: intr, status 0001 cmd 0c cpcmd 002b
[28498.055057] 8139cp 0000:00:0b.0: eth1: rx slot 51 status 0x32036066 len 98
[28498.055109] 8139cp 0000:00:0b.0: eth1: rx slot 52 status 0x32036066 len 98
[28498.055158] 8139cp 0000:00:0b.0: eth1: rx slot 53 status 0x32036066 len 98
[28498.055206] 8139cp 0000:00:0b.0: eth1: rx slot 54 status 0x32036066 len 98
[28498.055256] 8139cp 0000:00:0b.0: eth1: rx slot 55 status 0x32036066 len 98
[28498.055305] 8139cp 0000:00:0b.0: eth1: rx slot 56 status 0x32036066 len 98
[28498.055355] 8139cp 0000:00:0b.0: eth1: rx slot 57 status 0x32036066 len 98
[28498.055403] 8139cp 0000:00:0b.0: eth1: rx slot 58 status 0x32036066 len 98
[28498.055453] 8139cp 0000:00:0b.0: eth1: rx slot 59 status 0x32036066 len 98
[28498.055519] 8139cp 0000:00:0b.0: eth1: rx slot 60 status 0x32036066 len 98
[28498.055568] 8139cp 0000:00:0b.0: eth1: rx slot 61 status 0x32036066 len 98
[28498.055617] 8139cp 0000:00:0b.0: eth1: rx slot 62 status 0x32036066 len 98
[28498.055666] 8139cp 0000:00:0b.0: eth1: rx slot 63 status 0x72036066 len 98
[28498.055715] 8139cp 0000:00:0b.0: eth1: rx slot 0 status 0x32036066 len 98
[28498.055763] 8139cp 0000:00:0b.0: eth1: rx slot 1 status 0x32036066 len 98
[28498.055812] 8139cp 0000:00:0b.0: eth1: rx slot 2 status 0x32036066 len 98
[28498.055861] 8139cp 0000:00:0b.0: eth1: rx slot 3 status 0x32036066 len 98
[28498.055910] 8139cp 0000:00:0b.0: eth1: rx slot 4 status 0x32036066 len 98
[28498.055958] 8139cp 0000:00:0b.0: eth1: rx slot 5 status 0x32036066 len 98
[28498.056007] 8139cp 0000:00:0b.0: eth1: rx slot 6 status 0x32036066 len 98
[28498.056056] 8139cp 0000:00:0b.0: eth1: rx slot 7 status 0x32036066 len 98
[28498.056105] 8139cp 0000:00:0b.0: eth1: rx slot 8 status 0x32036066 len 98
[28498.056154] 8139cp 0000:00:0b.0: eth1: rx slot 9 status 0x32036066 len 98
[28498.056202] 8139cp 0000:00:0b.0: eth1: rx slot 10 status 0x32036066 len 98
[28498.056251] 8139cp 0000:00:0b.0: eth1: rx slot 11 status 0x32036066 len 98
[28498.056300] 8139cp 0000:00:0b.0: eth1: rx slot 12 status 0x32036066 len 98
[28498.056349] 8139cp 0000:00:0b.0: eth1: rx slot 13 status 0x32036066 len 98
[28498.056398] 8139cp 0000:00:0b.0: eth1: rx slot 14 status 0x32036066 len 98
[28498.056447] 8139cp 0000:00:0b.0: eth1: rx slot 15 status 0x32036066 len 98
[28498.056495] 8139cp 0000:00:0b.0: eth1: rx slot 16 status 0x32036066 len 98
[28498.056544] 8139cp 0000:00:0b.0: eth1: rx slot 17 status 0x32036066 len 98
[28498.056593] 8139cp 0000:00:0b.0: eth1: rx slot 18 status 0x32036066 len 98
[28498.056678] 8139cp 0000:00:0b.0: eth1: rx slot 19 status 0x32036066 len 98
[28498.056728] 8139cp 0000:00:0b.0: eth1: rx slot 20 status 0x32036066 len 98
[28498.056777] 8139cp 0000:00:0b.0: eth1: rx slot 21 status 0x32036066 len 98
[28498.056826] 8139cp 0000:00:0b.0: eth1: rx slot 22 status 0x32036066 len 98
[28498.056875] 8139cp 0000:00:0b.0: eth1: rx slot 23 status 0x32036066 len 98
[28498.056923] 8139cp 0000:00:0b.0: eth1: rx slot 24 status 0x32036066 len 98
[28498.056972] 8139cp 0000:00:0b.0: eth1: rx slot 25 status 0x32036066 len 98
[28498.057020] 8139cp 0000:00:0b.0: eth1: rx slot 26 status 0x32036066 len 98
[28498.057069] 8139cp 0000:00:0b.0: eth1: rx slot 27 status 0x32036066 len 98
[28498.057117] 8139cp 0000:00:0b.0: eth1: rx slot 28 status 0x32036066 len 98
[28498.057166] 8139cp 0000:00:0b.0: eth1: rx slot 29 status 0x32036066 len 98
[28498.057214] 8139cp 0000:00:0b.0: eth1: rx slot 30 status 0x32036066 len 98
[28498.057263] 8139cp 0000:00:0b.0: eth1: rx slot 31 status 0x32036066 len 98
[28498.057312] 8139cp 0000:00:0b.0: eth1: rx slot 32 status 0x32036066 len 98
[28498.057362] 8139cp 0000:00:0b.0: eth1: rx slot 33 status 0x32036066 len 98
[28498.057410] 8139cp 0000:00:0b.0: eth1: rx slot 34 status 0x32036066 len 98
[28498.057459] 8139cp 0000:00:0b.0: eth1: rx slot 35 status 0x32036066 len 98
[28498.057508] 8139cp 0000:00:0b.0: eth1: rx slot 36 status 0x32036066 len 98
[28498.057557] 8139cp 0000:00:0b.0: eth1: rx slot 37 status 0x32036066 len 98
[28498.057606] 8139cp 0000:00:0b.0: eth1: rx slot 38 status 0x32036066 len 98
[28498.057654] 8139cp 0000:00:0b.0: eth1: rx slot 39 status 0x32036066 len 98
[28498.057703] 8139cp 0000:00:0b.0: eth1: rx slot 40 status 0x32036066 len 98
[28498.057752] 8139cp 0000:00:0b.0: eth1: rx slot 41 status 0x32036066 len 98
[28498.057800] 8139cp 0000:00:0b.0: eth1: rx slot 42 status 0x32036066 len 98
[28498.057848] 8139cp 0000:00:0b.0: eth1: rx slot 43 status 0x32036066 len 98
[28498.057897] 8139cp 0000:00:0b.0: eth1: rx slot 44 status 0x32036066 len 98
[28498.057946] 8139cp 0000:00:0b.0: eth1: rx slot 45 status 0x32036066 len 98
[28498.057994] 8139cp 0000:00:0b.0: eth1: rx slot 46 status 0x32036066 len 98
[28498.058043] 8139cp 0000:00:0b.0: eth1: rx slot 47 status 0x32036066 len 98
[28498.058091] 8139cp 0000:00:0b.0: eth1: rx slot 48 status 0x32036066 len 98
[28498.058141] 8139cp 0000:00:0b.0: eth1: rx slot 49 status 0x32036066 len 98
[28498.058190] 8139cp 0000:00:0b.0: eth1: rx slot 50 status 0x32036066 len 98
[28498.058238] 8139cp 0000:00:0b.0: eth1: rx slot 51 status 0x32036066 len 98
[28498.058287] 8139cp 0000:00:0b.0: eth1: rx slot 52 status 0x32036066 len 98
[28498.058337] 8139cp 0000:00:0b.0: eth1: rx slot 53 status 0x32036066 len 98
[28498.058385] 8139cp 0000:00:0b.0: eth1: rx slot 54 status 0x32036066 len 98
[28498.058434] 8139cp 0000:00:0b.0: eth1: rx slot 55 status 0x32036066 len 98
[28498.058482] 8139cp 0000:00:0b.0: eth1: rx slot 56 status 0x32036066 len 98
[28498.058531] 8139cp 0000:00:0b.0: eth1: rx slot 57 status 0x32036066 len 98
[28498.058579] 8139cp 0000:00:0b.0: eth1: rx slot 58 status 0x32036066 len 98
[28498.058629] 8139cp 0000:00:0b.0: eth1: rx slot 59 status 0x32036066 len 98
[28498.058678] 8139cp 0000:00:0b.0: eth1: rx slot 60 status 0x32036066 len 98
[28498.058727] 8139cp 0000:00:0b.0: eth1: rx slot 61 status 0x32036066 len 98
[28498.058775] 8139cp 0000:00:0b.0: eth1: rx slot 62 status 0x32036066 len 98
[28498.058824] 8139cp 0000:00:0b.0: eth1: rx slot 63 status 0x72036066 len 98
[28498.058872] 8139cp 0000:00:0b.0: eth1: rx slot 0 status 0x32036066 len 98
[28498.058921] 8139cp 0000:00:0b.0: eth1: rx slot 1 status 0x32036066 len 98
[28498.058969] 8139cp 0000:00:0b.0: eth1: rx slot 2 status 0x32036066 len 98
[28498.059018] 8139cp 0000:00:0b.0: eth1: rx slot 3 status 0x32036066 len 98
[28498.059066] 8139cp 0000:00:0b.0: eth1: rx slot 4 status 0x32036066 len 98
[28498.059115] 8139cp 0000:00:0b.0: eth1: rx slot 5 status 0x32036066 len 98
[28498.059164] 8139cp 0000:00:0b.0: eth1: rx slot 6 status 0x32036066 len 98
[28498.059212] 8139cp 0000:00:0b.0: eth1: rx slot 7 status 0x32036066 len 98
[28498.059261] 8139cp 0000:00:0b.0: eth1: rx slot 8 status 0x32036066 len 98
[28498.059309] 8139cp 0000:00:0b.0: eth1: rx slot 9 status 0x32036066 len 98
[28498.059358] 8139cp 0000:00:0b.0: eth1: rx slot 10 status 0x32036066 len 98
[28498.059407] 8139cp 0000:00:0b.0: eth1: rx slot 11 status 0x32036066 len 98
[28498.059455] 8139cp 0000:00:0b.0: eth1: rx slot 12 status 0x32036066 len 98
[28498.059504] 8139cp 0000:00:0b.0: eth1: rx slot 13 status 0x32036066 len 98
[28498.059553] 8139cp 0000:00:0b.0: eth1: rx slot 14 status 0x32036066 len 98
[28498.059602] 8139cp 0000:00:0b.0: eth1: rx slot 15 status 0x32036066 len 98
[28498.059651] 8139cp 0000:00:0b.0: eth1: rx slot 16 status 0x32036066 len 98
[28498.059700] 8139cp 0000:00:0b.0: eth1: rx slot 17 status 0x32036066 len 98
[28498.059748] 8139cp 0000:00:0b.0: eth1: rx slot 18 status 0x32036066 len 98
[28498.059814] 8139cp 0000:00:0b.0: eth1: rx slot 19 status 0x32036066 len 98
[28498.059863] 8139cp 0000:00:0b.0: eth1: rx slot 20 status 0x32036066 len 98
[28498.059913] 8139cp 0000:00:0b.0: eth1: rx slot 21 status 0x32036066 len 98
[28498.059961] 8139cp 0000:00:0b.0: eth1: rx slot 22 status 0x32036066 len 98
[28498.060011] 8139cp 0000:00:0b.0: eth1: rx slot 23 status 0x32036066 len 98
[28498.060059] 8139cp 0000:00:0b.0: eth1: rx slot 24 status 0x32036066 len 98
[28498.060108] 8139cp 0000:00:0b.0: eth1: rx slot 25 status 0x32036066 len 98
[28498.060156] 8139cp 0000:00:0b.0: eth1: rx slot 26 status 0x32036066 len 98
[28498.060205] 8139cp 0000:00:0b.0: eth1: rx slot 27 status 0x32036066 len 98
[28498.060253] 8139cp 0000:00:0b.0: eth1: rx slot 28 status 0x32036066 len 98
[28498.060302] 8139cp 0000:00:0b.0: eth1: rx slot 29 status 0x32036066 len 98
[28498.060350] 8139cp 0000:00:0b.0: eth1: rx slot 30 status 0x32036066 len 98
[28498.060399] 8139cp 0000:00:0b.0: eth1: rx slot 31 status 0x32036066 len 98
[28498.060447] 8139cp 0000:00:0b.0: eth1: rx slot 32 status 0x32036066 len 98
[28498.060496] 8139cp 0000:00:0b.0: eth1: rx slot 33 status 0x32036066 len 98
[28498.060544] 8139cp 0000:00:0b.0: eth1: rx slot 34 status 0x32036066 len 98
[28498.060594] 8139cp 0000:00:0b.0: eth1: rx slot 35 status 0x32036066 len 98
[28498.060642] 8139cp 0000:00:0b.0: eth1: rx slot 36 status 0x32036066 len 98
[28498.060691] 8139cp 0000:00:0b.0: eth1: rx slot 37 status 0x32036066 len 98
[28498.060740] 8139cp 0000:00:0b.0: eth1: rx slot 38 status 0x32036066 len 98
[28498.060789] 8139cp 0000:00:0b.0: eth1: rx slot 39 status 0x32036066 len 98
[28498.060901] 8139cp 0000:00:0b.0: eth1: tx queued, slot 12, skblen 98
[28498.060936] 8139cp 0000:00:0b.0: eth1: intr, status 0080 cmd 0c cpcmd 002b
[28498.061814] 8139cp 0000:00:0b.0: eth1: tx queued, slot 13, skblen 98
[28498.064007] 8139cp 0000:00:0b.0: eth1: tx queued, slot 14, skblen 98
[28498.065750] 8139cp 0000:00:0b.0: eth1: tx queued, slot 15, skblen 98
[28498.067472] 8139cp 0000:00:0b.0: eth1: tx queued, slot 16, skblen 98
[28498.068062] 8139cp 0000:00:0b.0: eth1: tx queued, slot 17, skblen 79
[28498.068221] 8139cp 0000:00:0b.0: eth1: tx queued, slot 18, skblen 74
[28498.070711] 8139cp 0000:00:0b.0: eth1: tx queued, slot 19, skblen 98
[28498.072137] 8139cp 0000:00:0b.0: eth1: tx queued, slot 20, skblen 98
[28498.074369] 8139cp 0000:00:0b.0: eth1: tx queued, slot 21, skblen 98
[28498.075829] 8139cp 0000:00:0b.0: eth1: tx queued, slot 22, skblen 98
[28498.078074] 8139cp 0000:00:0b.0: eth1: tx queued, slot 23, skblen 98
[28498.079772] 8139cp 0000:00:0b.0: eth1: tx queued, slot 24, skblen 98
[28498.082254] 8139cp 0000:00:0b.0: eth1: tx queued, slot 25, skblen 98
[28498.120915] 8139cp 0000:00:0b.0: eth1: intr, status 0001 cmd 0c cpcmd 002b
[28498.120946] 8139cp 0000:00:0b.0: eth1: rx slot 40 status 0x3201404e len 74
[28498.140144] 8139cp 0000:00:0b.0: eth1: tx queued, slot 26, skblen 74
[28498.182530] 8139cp 0000:00:0b.0: eth1: tx queued, slot 27, skblen 66
[28498.276742] 8139cp 0000:00:0b.0: eth1: tx queued, slot 28, skblen 79
[28498.421426] 8139cp 0000:00:0b.0: eth1: intr, status 0001 cmd 0c cpcmd 002b
[28498.421454] 8139cp 0000:00:0b.0: eth1: rx slot 41 status 0x320141d8 len 468
[28498.485291] 8139cp 0000:00:0b.0: eth1: tx queued, slot 29, skblen 74
[28498.578432] 8139cp 0000:00:0b.0: eth1: tx queued, slot 30, skblen 66
[28498.646429] 8139cp 0000:00:0b.0: eth1: tx queued, slot 31, skblen 118
[28498.649979] 8139cp 0000:00:0b.0: eth1: intr, status 0001 cmd 0c cpcmd 002b
[28498.650008] 8139cp 0000:00:0b.0: eth1: rx slot 42 status 0x32036094 len 144
[28498.650098] 8139cp 0000:00:0b.0: eth1: rx slot 43 status 0x32036096 len 146
[28498.650165] 8139cp 0000:00:0b.0: eth1: rx slot 44 status 0x32036094 len 144
[28498.696744] 8139cp 0000:00:0b.0: eth1: tx queued, slot 32, skblen 79
[28498.804309] 8139cp 0000:00:0b.0: eth1: intr, status 0001 cmd 0c cpcmd 002b
[28498.804338] 8139cp 0000:00:0b.0: eth1: rx slot 45 status 0x320140a0 len 156
[28498.885404] 8139cp 0000:00:0b.0: eth1: tx queued, slot 33, skblen 125
[28499.086435] 8139cp 0000:00:0b.0: eth1: tx queued, slot 34, skblen 74
[28499.098211] 8139cp 0000:00:0b.0: eth1: intr, status 0001 cmd 0c cpcmd 002b
[28499.098239] 8139cp 0000:00:0b.0: eth1: rx slot 46 status 0x32014046 len 66
[28499.108839] 8139cp 0000:00:0b.0: eth1: tx queued, slot 35, skblen 66
[28499.121567] 8139cp 0000:00:0b.0: eth1: intr, status 0001 cmd 0c cpcmd 002b
[28499.121596] 8139cp 0000:00:0b.0: eth1: rx slot 47 status 0x3201404e len 74
[28499.121992] 8139cp 0000:00:0b.0: eth1: intr, status 0001 cmd 0c cpcmd 002b
[28499.122018] 8139cp 0000:00:0b.0: eth1: rx slot 48 status 0x3200e0a0 len 156
[28499.139903] 8139cp 0000:00:0b.0: eth1: tx queued, slot 36, skblen 74
[28499.401749] 8139cp 0000:00:0b.0: eth1: intr, status 0001 cmd 0c cpcmd 002b
[28499.401777] 8139cp 0000:00:0b.0: eth1: rx slot 49 status 0x320141d8 len 468
[28499.558938] 8139cp 0000:00:0b.0: eth1: tx queued, slot 37, skblen 66
[28499.775920] 8139cp 0000:00:0b.0: eth1: intr, status 0001 cmd 0c cpcmd 002b
[28499.775948] 8139cp 0000:00:0b.0: eth1: rx slot 50 status 0x3203605e len 90
[28499.888841] 8139cp 0000:00:0b.0: eth1: tx queued, slot 38, skblen 116
[28500.286470] 8139cp 0000:00:0b.0: eth1: tx queued, slot 39, skblen 74
[28500.353205] 8139cp 0000:00:0b.0: eth1: tx queued, slot 40, skblen 66
[28501.125519] 8139cp 0000:00:0b.0: eth1: intr, status 0001 cmd 0c cpcmd 002b
[28501.125553] 8139cp 0000:00:0b.0: eth1: rx slot 51 status 0x3201404e len 74
[28501.143803] 8139cp 0000:00:0b.0: eth1: tx queued, slot 41, skblen 74
[28501.373644] 8139cp 0000:00:0b.0: eth1: intr, status 0001 cmd 0c cpcmd 002b
[28501.373673] 8139cp 0000:00:0b.0: eth1: rx slot 52 status 0x320141d8 len 468
[28501.530366] 8139cp 0000:00:0b.0: eth1: tx queued, slot 42, skblen 66
[28501.648615] 8139cp 0000:00:0b.0: eth1: tx queued, slot 43, skblen 112
[28501.888561] 8139cp 0000:00:0b.0: eth1: tx queued, slot 44, skblen 121
[28502.094862] 8139cp 0000:00:0b.0: eth1: intr, status 0001 cmd 0c cpcmd 002b
[28502.094891] 8139cp 0000:00:0b.0: eth1: rx slot 53 status 0x32014046 len 66
[28502.105856] 8139cp 0000:00:0b.0: eth1: tx queued, slot 45, skblen 66
[28502.113535] 8139cp 0000:00:0b.0: eth1: tx queued, slot 46, skblen 94
[28502.221163] 8139cp 0000:00:0b.0: eth1: tx queued, slot 47, skblen 58
[28502.507301] SysRq : Changing Loglevel
[28502.511000] Loglevel set to 9
[28502.690951] 8139cp 0000:00:0b.0: eth1: tx queued, slot 48, skblen 74
[28502.725709] 8139cp 0000:00:0b.0: eth1: tx queued, slot 49, skblen 62
[28502.891993] 8139cp 0000:00:0b.0: eth1: tx queued, slot 50, skblen 116
[28502.997597] 8139cp 0000:00:0b.0: eth1: tx queued, slot 51, skblen 102
[28504.652076] 8139cp 0000:00:0b.0: eth1: tx queued, slot 52, skblen 118
[28504.886623] 8139cp 0000:00:0b.0: eth1: tx queued, slot 53, skblen 147
[28504.894552] 8139cp 0000:00:0b.0: eth1: tx queued, slot 54, skblen 123
[28505.133020] 8139cp 0000:00:0b.0: eth1: intr, status 0001 cmd 0c cpcmd 002b
[28505.140825] 8139cp 0000:00:0b.0: eth1: rx slot 54 status 0x3201404e len 74
[28505.149255] 8139cp 0000:00:0b.0: eth1: tx queued, slot 55, skblen 147
[28505.167408] 8139cp 0000:00:0b.0: eth1: tx queued, slot 56, skblen 74
[28505.317183] 8139cp 0000:00:0b.0: eth1: intr, status 0001 cmd 0c cpcmd 002b
[28505.325489] 8139cp 0000:00:0b.0: eth1: rx slot 55 status 0x320141d8 len 468
[28508.094647] 8139cp 0000:00:0b.0: eth1: intr, status 0001 cmd 0c cpcmd 002b
[28508.101681] 8139cp 0000:00:0b.0: eth1: rx slot 56 status 0x32014046 len 66
[28508.913790] 8139cp 0000:00:0b.0: eth1: intr, status 0001 cmd 0c cpcmd 002b
[28508.921135] 8139cp 0000:00:0b.0: eth1: rx slot 57 status 0x32022040 len 60
[28510.009002] 8139cp 0000:00:0b.0: eth1: intr, status 0001 cmd 0c cpcmd 002b
[28510.016533] 8139cp 0000:00:0b.0: eth1: rx slot 58 status 0x3201406b len 103
[28510.239735] 8139cp 0000:00:0b.0: eth1: intr, status 0001 cmd 0c cpcmd 002b
[28510.246717] 8139cp 0000:00:0b.0: eth1: rx slot 59 status 0x3201406b len 103
[28510.702856] 8139cp 0000:00:0b.0: eth1: intr, status 0001 cmd 0c cpcmd 002b
[28510.709886] 8139cp 0000:00:0b.0: eth1: rx slot 60 status 0x3201406b len 103
[28511.098502] 8139cp 0000:00:0b.0: eth1: intr, status 0001 cmd 0c cpcmd 002b
[28511.105396] 8139cp 0000:00:0b.0: eth1: rx slot 61 status 0x3202205d len 89
[28511.629295] 8139cp 0000:00:0b.0: eth1: intr, status 0001 cmd 0c cpcmd 002b
[28511.636190] 8139cp 0000:00:0b.0: eth1: rx slot 62 status 0x3201406b len 103
[28511.898925] 8139cp 0000:00:0b.0: eth1: intr, status 0001 cmd 0c cpcmd 002b
[28511.905833] 8139cp 0000:00:0b.0: eth1: rx slot 63 status 0x7202205d len 89
[28512.011147] 8139cp 0000:00:0b.0: eth1: intr, status 0001 cmd 0c cpcmd 002b
[28512.018063] 8139cp 0000:00:0b.0: eth1: rx slot 0 status 0x3202206b len 103
[28513.017313] 8139cp 0000:00:0b.0: eth1: Transmit timeout, status c 2b 0 80ff
[28513.025121] 8139cp 0000:00:0b.0: eth1: tx queued, slot 1, skblen 66
[28513.031420] 8139cp 0000:00:0b.0: eth1: tx queued, slot 2, skblen 111
[28513.037801] 8139cp 0000:00:0b.0: eth1: tx queued, slot 3, skblen 116
[28513.044164] 8139cp 0000:00:0b.0: eth1: tx queued, slot 4, skblen 109
[28513.050549] 8139cp 0000:00:0b.0: eth1: tx queued, slot 5, skblen 118
[28513.056912] 8139cp 0000:00:0b.0: eth1: tx queued, slot 6, skblen 111
[28513.063300] 8139cp 0000:00:0b.0: eth1: tx queued, slot 7, skblen 114
[28513.069685] 8139cp 0000:00:0b.0: eth1: tx queued, slot 8, skblen 125
[28513.076049] 8139cp 0000:00:0b.0: eth1: tx queued, slot 9, skblen 147
[28513.082426] 8139cp 0000:00:0b.0: eth1: tx queued, slot 10, skblen 66
[28513.088804] 8139cp 0000:00:0b.0: eth1: tx queued, slot 11, skblen 147
[28513.095254] 8139cp 0000:00:0b.0: eth1: tx queued, slot 12, skblen 74
[28513.101631] 8139cp 0000:00:0b.0: eth1: tx queued, slot 13, skblen 66
[28513.108009] 8139cp 0000:00:0b.0: eth1: tx queued, slot 14, skblen 147
[28513.114461] 8139cp 0000:00:0b.0: eth1: tx queued, slot 15, skblen 66
[28513.120846] 8139cp 0000:00:0b.0: eth1: tx queued, slot 16, skblen 66
[28513.127210] 8139cp 0000:00:0b.0: eth1: tx queued, slot 17, skblen 94
[28513.133595] 8139cp 0000:00:0b.0: eth1: tx queued, slot 18, skblen 66
[28513.139973] 8139cp 0000:00:0b.0: eth1: tx queued, slot 19, skblen 108
[28513.146425] 8139cp 0000:00:0b.0: eth1: tx queued, slot 20, skblen 110
[28513.152897] 8139cp 0000:00:0b.0: eth1: tx queued, slot 21, skblen 62
[28513.159273] 8139cp 0000:00:0b.0: eth1: tx queued, slot 22, skblen 66
[28513.165639] 8139cp 0000:00:0b.0: eth1: tx queued, slot 23, skblen 110
[28513.172111] 8139cp 0000:00:0b.0: eth1: tx queued, slot 24, skblen 147
[28513.178575] 8139cp 0000:00:0b.0: eth1: tx queued, slot 25, skblen 135
[28513.185027] 8139cp 0000:00:0b.0: eth1: tx queued, slot 26, skblen 70
[28513.191411] 8139cp 0000:00:0b.0: eth1: tx queued, slot 27, skblen 70
[28513.661282] 8139cp 0000:00:0b.0: eth1: tx queued, slot 28, skblen 110
[28513.902182] 8139cp 0000:00:0b.0: eth1: tx queued, slot 29, skblen 114
[28514.152998] 8139cp 0000:00:0b.0: eth1: tx queued, slot 30, skblen 62
[28514.904881] 8139cp 0000:00:0b.0: eth1: tx queued, slot 31, skblen 109
[28515.996046] 8139cp 0000:00:0b.0: eth1: tx queued, slot 32, skblen 70
[28516.664680] 8139cp 0000:00:0b.0: eth1: tx queued, slot 33, skblen 125
[28516.904608] 8139cp 0000:00:0b.0: eth1: tx queued, slot 34, skblen 126
[28517.916878] 8139cp 0000:00:0b.0: eth1: tx queued, slot 35, skblen 115
[28518.352300] 8139cp 0000:00:0b.0: eth1: tx queued, slot 36, skblen 66
[28519.028318] 8139cp 0000:00:0b.0: eth1: tx queued, slot 37, skblen 102
[28519.339446] 8139cp 0000:00:0b.0: eth1: tx queued, slot 38, skblen 141
[28519.668103] 8139cp 0000:00:0b.0: eth1: tx queued, slot 39, skblen 112
[28519.756759] 8139cp 0000:00:0b.0: eth1: tx queued, slot 40, skblen 141
[28519.907770] 8139cp 0000:00:0b.0: eth1: tx queued, slot 41, skblen 109
[28520.188635] 8139cp 0000:00:0b.0: eth1: tx queued, slot 42, skblen 62
[28520.596861] 8139cp 0000:00:0b.0: eth1: tx queued, slot 43, skblen 141
[28520.635544] 8139cp 0000:00:0b.0: eth1: tx queued, slot 44, skblen 147
[28520.911469] 8139cp 0000:00:0b.0: eth1: tx queued, slot 45, skblen 125
[28531.018105] 8139cp 0000:00:0b.0: eth1: Transmit timeout, status c 2b 485 0
[28531.025915] 8139cp 0000:00:0b.0: eth1: tx queued, slot 1, skblen 141
[28531.032305] 8139cp 0000:00:0b.0: eth1: tx queued, slot 2, skblen 117
[28531.038685] 8139cp 0000:00:0b.0: eth1: tx queued, slot 3, skblen 115
[28531.045049] 8139cp 0000:00:0b.0: eth1: tx queued, slot 4, skblen 117
[28531.051433] 8139cp 0000:00:0b.0: eth1: tx queued, slot 5, skblen 126
[28531.057797] 8139cp 0000:00:0b.0: eth1: tx queued, slot 6, skblen 112
[28531.064184] 8139cp 0000:00:0b.0: eth1: tx queued, slot 7, skblen 121
[28531.070559] 8139cp 0000:00:0b.0: eth1: tx queued, slot 8, skblen 118
[28531.076925] 8139cp 0000:00:0b.0: eth1: tx queued, slot 9, skblen 118
[28531.083310] 8139cp 0000:00:0b.0: eth1: tx queued, slot 10, skblen 115
[28531.089779] 8139cp 0000:00:0b.0: eth1: tx queued, slot 11, skblen 79
[28531.096148] 8139cp 0000:00:0b.0: eth1: tx queued, slot 12, skblen 141
[28531.102613] 8139cp 0000:00:0b.0: eth1: tx queued, slot 13, skblen 94
[28531.108990] 8139cp 0000:00:0b.0: eth1: tx queued, slot 14, skblen 42
[28531.115354] 8139cp 0000:00:0b.0: eth1: tx queued, slot 15, skblen 42
[28531.121738] 8139cp 0000:00:0b.0: eth1: tx queued, slot 16, skblen 42
[28531.128116] 8139cp 0000:00:0b.0: eth1: tx queued, slot 17, skblen 42
[28531.858156] 8139cp 0000:00:0b.0: eth1: tx queued, slot 18, skblen 42
[28532.256232] 8139cp 0000:00:0b.0: eth1: tx queued, slot 19, skblen 141
[28532.858193] 8139cp 0000:00:0b.0: eth1: tx queued, slot 20, skblen 42
[28533.862354] 8139cp 0000:00:0b.0: eth1: tx queued, slot 21, skblen 42
[28534.858290] 8139cp 0000:00:0b.0: eth1: tx queued, slot 22, skblen 42
[28535.858336] 8139cp 0000:00:0b.0: eth1: tx queued, slot 23, skblen 42
[28536.634367] 8139cp 0000:00:0b.0: eth1: tx queued, slot 24, skblen 147
[28537.684826] 8139cp 0000:00:0b.0: eth1: tx queued, slot 25, skblen 42
[28538.678444] 8139cp 0000:00:0b.0: eth1: tx queued, slot 26, skblen 42
[28539.678487] 8139cp 0000:00:0b.0: eth1: tx queued, slot 27, skblen 42
[28540.688218] 8139cp 0000:00:0b.0: eth1: tx queued, slot 28, skblen 42
[28541.678581] 8139cp 0000:00:0b.0: eth1: tx queued, slot 29, skblen 42
[28542.678622] 8139cp 0000:00:0b.0: eth1: tx queued, slot 30, skblen 42
[28543.690661] 8139cp 0000:00:0b.0: eth1: tx queued, slot 31, skblen 42
[28544.688708] 8139cp 0000:00:0b.0: eth1: tx queued, slot 32, skblen 42
[28545.575351] 8139cp 0000:00:0b.0: eth1: tx queued, slot 33, skblen 141
[28545.688766] 8139cp 0000:00:0b.0: eth1: tx queued, slot 34, skblen 42
[28546.694068] 8139cp 0000:00:0b.0: eth1: tx queued, slot 35, skblen 42
[28547.688840] 8139cp 0000:00:0b.0: eth1: tx queued, slot 36, skblen 42
[28548.688882] 8139cp 0000:00:0b.0: eth1: tx queued, slot 37, skblen 42
[28549.697713] 8139cp 0000:00:0b.0: eth1: tx queued, slot 38, skblen 42
[28550.579007] 8139cp 0000:00:0b.0: eth1: tx queued, slot 39, skblen 86
[28550.688971] 8139cp 0000:00:0b.0: eth1: tx queued, slot 40, skblen 42
[28550.811035] SysRq : Changing Loglevel
[28550.814730] Loglevel set to 1
[28551.579045] 8139cp 0000:00:0b.0: eth1: tx queued, slot 41, skblen 86
[28551.689016] 8139cp 0000:00:0b.0: eth1: tx queued, slot 42, skblen 42
[28551.719077] 8139cp 0000:00:0b.0: eth1: tx queued, slot 43, skblen 79
[28552.579071] 8139cp 0000:00:0b.0: eth1: tx queued, slot 44, skblen 86
[28552.701599] 8139cp 0000:00:0b.0: eth1: tx queued, slot 45, skblen 42
[28555.116322] 8139cp 0000:00:0b.0: eth1: disabling interface
[28555.116663] br-lan: port 2(eth1) entered disabled state
[28555.120239] device eth1 left promiscuous mode
[-- Attachment #2: smime.p7s --]
[-- Type: application/x-pkcs7-signature, Size: 6171 bytes --]
^ permalink raw reply
* Re: BQL support in gianfar causes network hickup
From: Tino Keitel @ 2012-11-24 20:42 UTC (permalink / raw)
To: netdev
In-Reply-To: <50AFA599.9040108@windriver.com>
Paul Gortmaker <paul.gortmaker <at> windriver.com> writes:
>
> On 12-11-23 10:58 AM, Keitel, Tino (ALC NetworX GmbH) wrote:
> > Hi,
> >
> > commit d8a0f1b0af67679bba886784de10d8c21acc4e0e causes the following
> > trace on a Freescale RDB8313 board:
>
> Thanks for the report.
>
> >
> > NETDEV WATCHDOG: eth1 (fsl-gianfar): transmit queue 0 timed out
> > ------------[ cut here ]------------
> > WARNING:
> > at /home/keitelt1/src/git/linux-stable/net/sched/sch_generic.c:255
> > Modules linked in:
> > NIP: c02448b0 LR: c02448b0 CTR: c01c19b8
> > REGS: c7ffbe40 TRAP: 0700 Not tainted (3.7.0-rc6-rt18)
> ^^^^^^^^^^^^^^^
> I almost overlooked the above. It would have been nice to
> see more explicit information on what kernel you are running.
> I say that because the above concerns me. For several reasons.
>
> 1) it looks to be not mainline, but preempt_rt
> 2) There is no RT on 3.7 yet, so I'm assuming this is a custom
> forward port of the 250 odd RT patches. (The RT is 3.6.7-rt18,
> i.e. based on the 3.6 gregKH stable tree.)
Sorry for the confusion. This was a 3.7.0-rc6 tree, and I forgot git clean after
trying the rt-patches and git reset --hard v3.7.0-rc6, so the localversion file
for -rt was still present, and the kernel was named 3.7.0-rc6-rt18. If I got
this right, this should be a normal kernel with just the version file modified.
I tried kernel 3.3, which doesnt have the issue. I tried 3.4, 3.6.7 and 3.7-rc6,
which all show the kernel trace and ptp client misbehaviour. I tried 3.4, 3.6.7,
3.7-rc6 and 3.6.5-rt18 with the patch I posted, and they were ok.
The patch I posted is for 3.7-rc6.
Regards,
Tino
^ permalink raw reply
* Re: [PATCH 1/7] batman-adv: Move soft-interface initialization to ndo_init
From: David Miller @ 2012-11-24 20:59 UTC (permalink / raw)
To: sven; +Cc: b.a.t.m.a.n, netdev
In-Reply-To: <1353715332-4284-1-git-send-email-sven@narfation.org>
No pull request?
^ permalink raw reply
* [PATCH] MAINTAINERS: Add Q: patchwork entries for net/ and drivers/net/
From: Joe Perches @ 2012-11-24 21:18 UTC (permalink / raw)
To: David Miller; +Cc: netdev
Add the netdev patchwork entries for networking drivers.
Change the W: entry to Q:for networking.
Signed-off-by: Joe Perches <joe@perches.com>
---
MAINTAINERS | 3 ++-
1 files changed, 2 insertions(+), 1 deletions(-)
diff --git a/MAINTAINERS b/MAINTAINERS
index a9c794c..7549075 100644
--- a/MAINTAINERS
+++ b/MAINTAINERS
@@ -5056,7 +5056,7 @@ NETWORKING [GENERAL]
M: "David S. Miller" <davem@davemloft.net>
L: netdev@vger.kernel.org
W: http://www.linuxfoundation.org/en/Net
-W: http://patchwork.ozlabs.org/project/netdev/list/
+Q: http://patchwork.ozlabs.org/project/netdev/list/
T: git git://git.kernel.org/pub/scm/linux/kernel/git/davem/net.git
T: git git://git.kernel.org/pub/scm/linux/kernel/git/davem/net-next.git
S: Maintained
@@ -5116,6 +5116,7 @@ F: drivers/net/wireless/
NETWORKING DRIVERS
L: netdev@vger.kernel.org
W: http://www.linuxfoundation.org/en/Net
+Q: http://patchwork.ozlabs.org/project/netdev/list/
T: git git://git.kernel.org/pub/scm/linux/kernel/git/davem/net.git
T: git git://git.kernel.org/pub/scm/linux/kernel/git/davem/net-next.git
S: Odd Fixes
^ permalink raw reply related
* Re: [PATCH 1/7] batman-adv: Move soft-interface initialization to ndo_init
From: Sven Eckelmann @ 2012-11-24 21:23 UTC (permalink / raw)
To: David Miller
Cc: netdev-u79uwXL29TY76Z2rM5mHXA,
b.a.t.m.a.n-ZwoEplunGu2X36UT3dwllkB+6BGkLq7r
In-Reply-To: <20121124.155902.1261596975089040930.davem-fT/PcQaiUtIeIZ0/mPfg9Q@public.gmane.org>
[-- Attachment #1: Type: text/plain, Size: 145 bytes --]
On Saturday 24 November 2012 15:59:02 David Miller wrote:
> No pull request?
They didn't apply it yet. (sry for Cc'ing you)
Kind regards,
Sven
[-- Attachment #2: This is a digitally signed message part. --]
[-- Type: application/pgp-signature, Size: 836 bytes --]
^ permalink raw reply
* Re: 8139cp TX stall, timeout, failed recovery
From: David Woodhouse @ 2012-11-24 21:39 UTC (permalink / raw)
To: netdev; +Cc: romieu, jasowang, gilboad, jgarzik, nathan
In-Reply-To: <1353782365.26346.266.camel@shinybook.infradead.org>
[-- Attachment #1: Type: text/plain, Size: 1672 bytes --]
On Sat, 2012-11-24 at 18:39 +0000, David Woodhouse wrote:
> This seems to be a consistent pattern — when we get that 0x0080
> interrupt and it dies, it's *very* soon after queueing a new tx:
Once I realise that the 'tx queued' message actually prints the number
of the *next* slot that'll be used, not the slot that was just filled,
that becomes obvious. The hardware takes only 30µs or so to consume the
descriptor that was just submitted. It isn't just coincidence that one
packet completes just as the *next* one is being submitted, as I
originally thought.
The hardware seems to asserts the 0x80 'Tx Descriptor Unavailable'
interrupt first, and the other bits (0x404) come later. I *often* get
into cp_tx() with only 0x80 in the IntrStatus bits, and the other bits
are often set before my heavily-debug-laden cp_tx() has even finished
running).
Register 0x82 indicates the low bits of the address of the most recently
consumed Tx descriptor, and always seems to agree with the driver's
processing of the ring. When we get a 0x80 interrupt, the most recently
consumed descriptor is always the one before tx_head, as you'd expect.
And tx_head always looks sane and (as long as you read it quickly) still
has the 'Own' bit set, as it should.
Eventually I get a 0x80 interrupt which *isn't* immediately followed by
the other 0x404 bits. And then the hardware has crapped itself and is no
longer eating descriptors. We submit more to the queue and we bang on
the TxPoll register *every* time, but that doesn't wake it.
Adding a cp_enable_irq() into the cp_tx_timeout() function at least
makes it recover *eventually*.
--
dwmw2
[-- Attachment #2: smime.p7s --]
[-- Type: application/x-pkcs7-signature, Size: 6171 bytes --]
^ permalink raw reply
* Re: 8139cp TX stall, timeout, failed recovery
From: Francois Romieu @ 2012-11-24 21:33 UTC (permalink / raw)
To: David Woodhouse; +Cc: netdev, jasowang, gilboad, jgarzik
In-Reply-To: <1353782365.26346.266.camel@shinybook.infradead.org>
David Woodhouse <dwmw2@infradead.org> :
[...]
> To reproduce this, I send a *large* flood of packets (ping -l 1000) from
> inside my network to the ADSL router. Its internal-facing interface is
> an 8139cp. It seems to work best if the packets are destined for the
> outside world over the ADSL lines, rather than the router itself. But
> it's hard to tell. I need between 10 and 30 runs of 'ping -l 1000
> $outside' before it happens. Or sometimes more...
Did you try pktgen as well ?
[...]
> Looking at it now... do we wrap around the Rx ring buffer at 28498.055
> and process some of the packets more than once? Or is the hardware
> genuinely keeping up with us as we suck out, descriptors 51-63, 0-63,
> and 0-39 again all off the same interrupt? Perhaps there lies the root
> of the problem?
Rx slots are always spaced by ~50 us, i.e. more than needed to get a 98 bytes
packets. I do not like the lack of barrier wrt opts2 and opts1 writes for rx
descriptors but it does nprobably not matter for your problem.
If the r8169 experience is any guide, cp_tx_timeout is too light. It should
imho match the init sequence more closely, especially wrt descriptor rings
addresses and CpCmd.
--
Ueimor
^ permalink raw reply
* [PATCH] 8139cp: re-enable interrupts after tx timeout
From: David Woodhouse @ 2012-11-24 22:11 UTC (permalink / raw)
To: Francois Romieu; +Cc: netdev, jasowang, gilboad, jgarzik
In-Reply-To: <20121124213348.GA8313@electric-eye.fr.zoreil.com>
[-- Attachment #1: Type: text/plain, Size: 735 bytes --]
Recovery doesn't work too well if we leave interrupts disabled...
Signed-off-by: David Woodhouse <David.Woodhouse@intel.com>
---
For stable too, I suppose.
diff --git a/drivers/net/ethernet/realtek/8139cp.c b/drivers/net/ethernet/realtek/8139cp.c
index 1c81825..ad6afc3 100644
--- a/drivers/net/ethernet/realtek/8139cp.c
+++ b/drivers/net/ethernet/realtek/8139cp.c
@@ -1192,6 +1192,7 @@ static void cp_tx_timeout(struct net_device *dev)
cp_clean_rings(cp);
rc = cp_init_rings(cp);
cp_start_hw(cp);
+ cp_enable_irq(cp);
netif_wake_queue(dev);
--
David Woodhouse Open Source Technology Centre
David.Woodhouse@intel.com Intel Corporation
[-- Attachment #2: smime.p7s --]
[-- Type: application/x-pkcs7-signature, Size: 6171 bytes --]
^ permalink raw reply related
* Re: [PATCH] 8139cp: re-enable interrupts after tx timeout
From: Francois Romieu @ 2012-11-24 22:58 UTC (permalink / raw)
To: David Woodhouse; +Cc: netdev, jasowang, gilboad, jgarzik
In-Reply-To: <1353795081.26346.287.camel@shinybook.infradead.org>
David Woodhouse <dwmw2@infradead.org> :
> Recovery doesn't work too well if we leave interrupts disabled...
>
> Signed-off-by: David Woodhouse <David.Woodhouse@intel.com>
Acked-by: Francois Romieu <romieu@fr.zoreil.com>
While you are at it, do you see what would prevent the watchdog
timer and the rx napi handler to race on two different CPUs
("using a Geode" could be an answer :o) ) ?
> ---
> For stable too, I suppose.
Yes. Watch for http://patchwork.ozlabs.org/bundle/davem/stable/
--
Ueimor
^ permalink raw reply
* Re: [PATCH] 8139cp: re-enable interrupts after tx timeout
From: David Woodhouse @ 2012-11-24 23:27 UTC (permalink / raw)
To: Francois Romieu; +Cc: netdev, jasowang, gilboad, jgarzik
In-Reply-To: <20121124225855.GA17340@electric-eye.fr.zoreil.com>
[-- Attachment #1: Type: text/plain, Size: 379 bytes --]
On Sat, 2012-11-24 at 23:58 +0100, Francois Romieu wrote:
> While you are at it, do you see what would prevent the watchdog
> timer and the rx napi handler to race on two different CPUs
Hm, good point. Is it sufficient just to stick napi_disable() and
napi_enable() in there? And should we try to reset the TX state machine
without stomping on RX at all?
--
dwmw2
[-- Attachment #2: smime.p7s --]
[-- Type: application/x-pkcs7-signature, Size: 6171 bytes --]
^ permalink raw reply
* Re: BQL support in gianfar causes network hickup
From: Eric Dumazet @ 2012-11-24 23:43 UTC (permalink / raw)
To: Tino Keitel; +Cc: netdev
In-Reply-To: <loom.20121124T213422-650@post.gmane.org>
On Sat, 2012-11-24 at 20:42 +0000, Tino Keitel wrote:
> Paul Gortmaker <paul.gortmaker <at> windriver.com> writes:
>
> >
> > On 12-11-23 10:58 AM, Keitel, Tino (ALC NetworX GmbH) wrote:
> > > Hi,
> > >
> > > commit d8a0f1b0af67679bba886784de10d8c21acc4e0e causes the following
> > > trace on a Freescale RDB8313 board:
> >
> > Thanks for the report.
> >
> > >
> > > NETDEV WATCHDOG: eth1 (fsl-gianfar): transmit queue 0 timed out
> > > ------------[ cut here ]------------
> > > WARNING:
> > > at /home/keitelt1/src/git/linux-stable/net/sched/sch_generic.c:255
> > > Modules linked in:
> > > NIP: c02448b0 LR: c02448b0 CTR: c01c19b8
> > > REGS: c7ffbe40 TRAP: 0700 Not tainted (3.7.0-rc6-rt18)
> > ^^^^^^^^^^^^^^^
> > I almost overlooked the above. It would have been nice to
> > see more explicit information on what kernel you are running.
> > I say that because the above concerns me. For several reasons.
> >
> > 1) it looks to be not mainline, but preempt_rt
> > 2) There is no RT on 3.7 yet, so I'm assuming this is a custom
> > forward port of the 250 odd RT patches. (The RT is 3.6.7-rt18,
> > i.e. based on the 3.6 gregKH stable tree.)
>
> Sorry for the confusion. This was a 3.7.0-rc6 tree, and I forgot git clean after
> trying the rt-patches and git reset --hard v3.7.0-rc6, so the localversion file
> for -rt was still present, and the kernel was named 3.7.0-rc6-rt18. If I got
> this right, this should be a normal kernel with just the version file modified.
>
> I tried kernel 3.3, which doesnt have the issue. I tried 3.4, 3.6.7 and 3.7-rc6,
> which all show the kernel trace and ptp client misbehaviour. I tried 3.4, 3.6.7,
> 3.7-rc6 and 3.6.5-rt18 with the patch I posted, and they were ok.
>
> The patch I posted is for 3.7-rc6.
>
Hmm, I wonder if BQL makes a particular bug showing more often.
I see gianfar uses a very small watchdog_timeo of 1 second, while many
drivers use 5 seconds.
What happens if you change this to 5 seconds ?
diff --git a/drivers/net/ethernet/freescale/gianfar.c b/drivers/net/ethernet/freescale/gianfar.c
index 19ac096..3a994f9 100644
--- a/drivers/net/ethernet/freescale/gianfar.c
+++ b/drivers/net/ethernet/freescale/gianfar.c
@@ -101,7 +101,7 @@
#include "gianfar.h"
-#define TX_TIMEOUT (1*HZ)
+#define TX_TIMEOUT (5*HZ)
const char gfar_driver_version[] = "1.3";
^ permalink raw reply related
* Re: [RFC net-next PATCH V1 0/9] net: fragmentation performance scalability on NUMA/SMP systems
From: Eric Dumazet @ 2012-11-25 2:31 UTC (permalink / raw)
To: Jesper Dangaard Brouer
Cc: David S. Miller, Florian Westphal, netdev, Pablo Neira Ayuso,
Thomas Graf, Cong Wang, Patrick McHardy, Paul E. McKenney,
Herbert Xu
In-Reply-To: <20121123130749.18764.25962.stgit@dragon>
On Fri, 2012-11-23 at 14:08 +0100, Jesper Dangaard Brouer wrote:
> This patchset implements significant performance improvements for
> fragmentation handling in the kernel, with a focus on NUMA and SMP
> based systems.
>
> Review:
>
> Please review these patches. I have on purpose added comments in the
> code with the "//" comments style. These comments are to be removed
> before applying. They serve as a questions to, you, the reviewer.
>
> The fragmentation code today:
>
> The fragmentation code "protects" kernel resources, by implementing
> some memory resource limitation code. This is centered around a
> global readers-writer lock, and (per network namespace) an atomic mem
> counter and a LRU (Least-Recently-Used) list. (Although separate
> global variables and namespace resources, are kept for IPv4, IPv6
> and Netfilter reassembly.)
>
> The code tries to keep the memory usage between a high and low
> threshold (see: /proc/sys/net/ipv4/ipfrag_{high,low}_thresh). The
> "evictor" code cleans up fragments, when the high threshold is
> exceeded, and stops only, when the low threshold is reached.
>
> The scalability problem:
>
> Having a global/central variable for a resource limit is obviously a
> scalability issue on SMP systems, and even amplified on a NUMA based
> system.
>
But ... , what practical workload even use fragments ?
Sure, netperf -t UDP_STREAM uses frags, but its a benchmark.
The only heavy user was NFS in the days it was using UDP, a very long
time ago.
A single lost fragment means the whole packet is lost.
Another problem with fragments is the lack of 4-tuple hashing, as only
the first frag contains the dst/src ports.
Also there is the sysctl_ipfrag_max_dist issue...
Hint : many NIC provide TSO (TCP offload), but none provide UFO,
probably because there is no demand for it.
^ permalink raw reply
* [Feature request] ip rule replace
From: Damjan @ 2012-11-25 3:22 UTC (permalink / raw)
To: netdev
similar to "ip route replace" there should be an "ip rule replace"
command. Using "del" and then "add" is more fragile.
--
дамјан
^ permalink raw reply
* Re: [PATCH RFC 3/5] printk: modify printk interface for syslog_namespace
From: Serge E. Hallyn @ 2012-11-25 4:28 UTC (permalink / raw)
To: Libo Chen
Cc: netdev-u79uwXL29TY76Z2rM5mHXA,
containers-cunTk1MwBs9QetFLy7KEm3xJsTq8ys+cHZ5vskTnxNA,
Eric W. Biederman
In-Reply-To: <50B0ADDB.4000303-Re5JQEeQqe8AvxtiuMwx3w@public.gmane.org>
Quoting Libo Chen (chenlibo.3-Re5JQEeQqe8AvxtiuMwx3w@public.gmane.org):
> On 2012/11/22 1:49, Serge E. Hallyn wrote:
>
> > I notice that you haven't made any changes to the struct cont. I
> > suspect this means that to-be-continued msgs from one ns can be
> > erroneously mixed with another ns.
> >
> Yes, I confirmed this problem. There will be erroneously mixed with another ns.
> Thank you very much.
>
> > You said you don't mind putting the syslogns into the userns. If
> > there's no reason not to do that, then we should do so as it will
> > remove a bunch of code (plus the use of a new CLONE flag) from your
> > patch, and the new syslog(NEW_NS) command from mine.
> >
> I agree with you, both are removable.
>
> > Now IMO the ideal place for syslog_ns would be in the devices ns,
> > but that does not yet exist, and may never. The bonus to that would
> > be that the consoles sort of belong there. I avoid this by not
> > having consoles in child syslog namespaces. You put the console in
> > the ns. I haven't looked closely enough to see if what you do is
> > ok (will do so soon).
> >
> > WOuld you mind looking through my patch to see if it suffices for
> > your needs? Where it does not, patches would be greatly appreciated
> > if simple enough.
>
> follow your patch, I can see inject message by "dmesg call" in container, is right?
If I understand you right, yes.
> I am worry that I debug or see messages from serial ports console in some embedded system,
> since console belongs to init_syslog, so the message in container can`t be printed.
Sorry, I don't understand which way you're going with that. Could you
rephrase? You want to prevent console messages from going to a
container? (That should definately not happen) Or something else?
> > Note I'm not at all wedded to my patchset. I'm happy to go with
> > something else entirely. My set was just a proof of concept.
thanks,
-serge
^ permalink raw reply
* [PATCH net] ipv4: avoid passing NULL to inet_putpeer() in icmpv4_xrlim_allow()
From: Neal Cardwell @ 2012-11-25 4:54 UTC (permalink / raw)
To: David Miller; +Cc: netdev, Neal Cardwell
inet_getpeer_v4() can return NULL under OOM conditions, and while
inet_peer_xrlim_allow() is OK with a NULL peer, inet_putpeer() will
crash.
This code path now uses the same idiom as the others from:
1d861aa4b3fb08822055345f480850205ffe6170 ("inet: Minimize use of
cached route inetpeer.").
Signed-off-by: Neal Cardwell <ncardwell@google.com>
---
net/ipv4/icmp.c | 3 ++-
1 files changed, 2 insertions(+), 1 deletions(-)
diff --git a/net/ipv4/icmp.c b/net/ipv4/icmp.c
index f2eccd5..17ff9fd 100644
--- a/net/ipv4/icmp.c
+++ b/net/ipv4/icmp.c
@@ -257,7 +257,8 @@ static inline bool icmpv4_xrlim_allow(struct net *net, struct rtable *rt,
struct inet_peer *peer = inet_getpeer_v4(net->ipv4.peers, fl4->daddr, 1);
rc = inet_peer_xrlim_allow(peer,
net->ipv4.sysctl_icmp_ratelimit);
- inet_putpeer(peer);
+ if (peer)
+ inet_putpeer(peer);
}
out:
return rc;
--
1.7.7.3
^ permalink raw reply related
* private netdev flags into UAPI?
From: Or Gerlitz @ 2012-11-25 7:43 UTC (permalink / raw)
To: David Howells, netdev
not sure if this has been brought up before, but I realized that the
private IFF_yyy netdevice flags which weren't exposed to user space so
far have been moved to include/uapi/linux/if.h, isn't that wrong?
Or.
> /* Private (from user) interface flags (netdevice->priv_flags). */
> #define IFF_802_1Q_VLAN 0x1 /* 802.1Q VLAN device. */
> #define IFF_EBRIDGE 0x2 /* Ethernet bridging device. */
> [...] * change when it's running */
^ permalink raw reply
* Re: [RFC net-next PATCH V1 0/9] net: fragmentation performance scalability on NUMA/SMP systems
From: Jesper Dangaard Brouer @ 2012-11-25 8:53 UTC (permalink / raw)
To: Eric Dumazet
Cc: David S. Miller, Florian Westphal, netdev, Pablo Neira Ayuso,
Thomas Graf, Cong Wang, Patrick McHardy, Paul E. McKenney,
Herbert Xu
In-Reply-To: <1353810665.2590.4774.camel@edumazet-glaptop>
On Sat, 2012-11-24 at 18:31 -0800, Eric Dumazet wrote:
> On Fri, 2012-11-23 at 14:08 +0100, Jesper Dangaard Brouer wrote:
> > This patchset implements significant performance improvements for
> > fragmentation handling in the kernel, with a focus on NUMA and SMP
> > based systems.
> >
> > Review:
> >
> > Please review these patches. I have on purpose added comments in the
> > code with the "//" comments style. These comments are to be removed
> > before applying. They serve as a questions to, you, the reviewer.
> >
> > The fragmentation code today:
> >
> > The fragmentation code "protects" kernel resources, by implementing
> > some memory resource limitation code. This is centered around a
> > global readers-writer lock, and (per network namespace) an atomic mem
> > counter and a LRU (Least-Recently-Used) list. (Although separate
> > global variables and namespace resources, are kept for IPv4, IPv6
> > and Netfilter reassembly.)
> >
> > The code tries to keep the memory usage between a high and low
> > threshold (see: /proc/sys/net/ipv4/ipfrag_{high,low}_thresh). The
> > "evictor" code cleans up fragments, when the high threshold is
> > exceeded, and stops only, when the low threshold is reached.
> >
> > The scalability problem:
> >
> > Having a global/central variable for a resource limit is obviously a
> > scalability issue on SMP systems, and even amplified on a NUMA based
> > system.
> >
>
>
> But ... , what practical workload even use fragments ?
(1) DNS (default for Bind) will use up-to 3 UDP fragments before
switching to TCP. This is getting more and more relevant after the
introduction of DNSSEC. That's why I'm explicit testing the 3xUDP
fragments so heavily.
(2) For IPVS (load-balancing) we have recently allowed fragmentation in
tunnel mode, towards the realservers (to hide the MTU reduction for the
clients). Thus, we need better frag performance in this case.
(3) I also have a customer that have a usage scenario/application (at
4x10G) that needs this... but I'm trying to convince them to fix/change
their application...
Scenario (1) is the real reason I want to fix this scalability issue in
the code.
> Sure, netperf -t UDP_STREAM uses frags, but its a benchmark.
Yes, for the default large 64k packets size, its just a "fake"
benchmark. And notice with my fixes, we are even faster than the
none-frag/single-UDP packet case... but its because we are getting a
GSO/GRO effect.
That's why I'm adjusting the UDP "frag" packet size to get a more
realistic use case... to simulate the DNS use-case (1).
> The only heavy user was NFS in the days it was using UDP, a very long
> time ago.
>
> A single lost fragment means the whole packet is lost.
That is correct, that's why we need the fix in patch-01.
(It actually reminds me of the problem with ADSL/ATM, where (small) ATM
frame are used for carrying IP packets, and when some (more central) ATM
link gets overloaded and starts to drops ATM frames, not taking the AAL5
packets into account).
> Another problem with fragments is the lack of 4-tuple hashing, as only
> the first frag contains the dst/src ports.
>
> Also there is the sysctl_ipfrag_max_dist issue...
>
> Hint : many NIC provide TSO (TCP offload), but none provide UFO,
> probably because there is no demand for it.
--
Best regards,
Jesper Dangaard Brouer
MSc.CS, Sr. Network Kernel Developer at Red Hat
Author of http://www.iptv-analyzer.org
LinkedIn: http://www.linkedin.com/in/brouer
^ permalink raw reply
* Re: [PATCH] ewrk3: silence GCC warning
From: richard -rw- weinberger @ 2012-11-25 10:45 UTC (permalink / raw)
To: Paul Bolle; +Cc: netdev, linux-kernel
In-Reply-To: <1353759165.1420.33.camel@x61.thuisdomein>
On Sat, Nov 24, 2012 at 1:12 PM, Paul Bolle <pebolle@tiscali.nl> wrote:
> Building ewrk3.o triggers this GCC warning:
> drivers/net/ethernet/dec/ewrk3.c: In function '__check_irq':
> drivers/net/ethernet/dec/ewrk3.c:1915:1: warning: return from incompatible pointer type [enabled by default]
>
> This can be trivially fixed by changing the 'irq' parameter from int to
> byte (which is the alias for unsigned char for module parameters).
>
> While we're touching this code also drop an outdated comment, that
> should have been dropped with the patch named "MODULE_PARM conversions"
> from early 2005.
Please send this change as an additional patch.
--
Thanks,
//richard
^ permalink raw reply
* [PATCH] net: qmi_wwan: add Huawei E173
From: Bjørn Mork @ 2012-11-25 16:03 UTC (permalink / raw)
To: netdev; +Cc: linux-usb, Thomas Schäfer, Bjørn Mork
The Huawei E173 is a QMI/wwan device which normally appear
as 12d1:1436 in Linux. The descriptors displayed in that
mode will be picked up by cdc_ether. But the modem has
another mode with a different device ID and a slightly
different set of descriptors. This is the mode used by
Windows like this:
3Modem: USB\VID_12D1&PID_140C&MI_00\6&3A1D2012&0&0000
Networkcard: USB\VID_12D1&PID_140C&MI_01\6&3A1D2012&0&0001
Appli.Inter: USB\VID_12D1&PID_140C&MI_02\6&3A1D2012&0&0002
PC UI Inter: USB\VID_12D1&PID_140C&MI_03\6&3A1D2012&0&0003
Reported-by: Thomas Schäfer <tschaefer@t-online.de>
Signed-off-by: Bjørn Mork <bjorn@mork.no>
---
drivers/net/usb/qmi_wwan.c | 1 +
1 file changed, 1 insertion(+)
diff --git a/drivers/net/usb/qmi_wwan.c b/drivers/net/usb/qmi_wwan.c
index 3b566fa..1ea91f4 100644
--- a/drivers/net/usb/qmi_wwan.c
+++ b/drivers/net/usb/qmi_wwan.c
@@ -385,6 +385,7 @@ static const struct usb_device_id products[] = {
},
/* 3. Combined interface devices matching on interface number */
+ {QMI_FIXED_INTF(0x12d1, 0x140c, 1)}, /* Huawei E173 */
{QMI_FIXED_INTF(0x19d2, 0x0002, 1)},
{QMI_FIXED_INTF(0x19d2, 0x0012, 1)},
{QMI_FIXED_INTF(0x19d2, 0x0017, 3)},
--
1.7.10.4
^ permalink raw reply related
* Re: [RFC net-next PATCH V1 0/9] net: fragmentation performance scalability on NUMA/SMP systems
From: Eric Dumazet @ 2012-11-25 16:11 UTC (permalink / raw)
To: Jesper Dangaard Brouer
Cc: David S. Miller, Florian Westphal, netdev, Pablo Neira Ayuso,
Thomas Graf, Cong Wang, Patrick McHardy, Paul E. McKenney,
Herbert Xu
In-Reply-To: <1353833627.11754.134.camel@localhost>
On Sun, 2012-11-25 at 09:53 +0100, Jesper Dangaard Brouer wrote:
> Yes, for the default large 64k packets size, its just a "fake"
> benchmark. And notice with my fixes, we are even faster than the
> none-frag/single-UDP packet case... but its because we are getting a
> GSO/GRO effect.
Could you elaborate on this GSO/GRO effect ?
^ permalink raw reply
* [PATCH net-next] ipv4: ipmr: various fixes and cleanups
From: Eric Dumazet @ 2012-11-25 16:41 UTC (permalink / raw)
To: David Miller; +Cc: netdev
From: Eric Dumazet <edumazet@google.com>
1) ip_mroute_setsockopt() & ip_mroute_getsockopt() should not
access/set raw_sk(sk)->ipmr_table before making sure the socket
is a raw socket, and protocol is IGMP
2) MRT_INIT should return -EINVAL if optlen != sizeof(int), not
-ENOPROTOOPT
3) MRT_ASSERT & MRT_PIM should validate optlen
4) " (v) ? 1 : 0 " can be written as " !!v "
Signed-off-by: Eric Dumazet <edumazet@google.com>
---
net/ipv4/ipmr.c | 24 +++++++++++++++++-------
1 file changed, 17 insertions(+), 7 deletions(-)
diff --git a/net/ipv4/ipmr.c b/net/ipv4/ipmr.c
index 6168c4d..af4ef54 100644
--- a/net/ipv4/ipmr.c
+++ b/net/ipv4/ipmr.c
@@ -1207,6 +1207,10 @@ int ip_mroute_setsockopt(struct sock *sk, int optname, char __user *optval, unsi
struct net *net = sock_net(sk);
struct mr_table *mrt;
+ if (sk->sk_type != SOCK_RAW ||
+ inet_sk(sk)->inet_num != IPPROTO_IGMP)
+ return -EOPNOTSUPP;
+
mrt = ipmr_get_table(net, raw_sk(sk)->ipmr_table ? : RT_TABLE_DEFAULT);
if (mrt == NULL)
return -ENOENT;
@@ -1219,11 +1223,8 @@ int ip_mroute_setsockopt(struct sock *sk, int optname, char __user *optval, unsi
switch (optname) {
case MRT_INIT:
- if (sk->sk_type != SOCK_RAW ||
- inet_sk(sk)->inet_num != IPPROTO_IGMP)
- return -EOPNOTSUPP;
if (optlen != sizeof(int))
- return -ENOPROTOOPT;
+ return -EINVAL;
rtnl_lock();
if (rtnl_dereference(mrt->mroute_sk)) {
@@ -1284,9 +1285,11 @@ int ip_mroute_setsockopt(struct sock *sk, int optname, char __user *optval, unsi
case MRT_ASSERT:
{
int v;
+ if (optlen != sizeof(v))
+ return -EINVAL;
if (get_user(v, (int __user *)optval))
return -EFAULT;
- mrt->mroute_do_assert = (v) ? 1 : 0;
+ mrt->mroute_do_assert = !!v;
return 0;
}
#ifdef CONFIG_IP_PIMSM
@@ -1294,9 +1297,11 @@ int ip_mroute_setsockopt(struct sock *sk, int optname, char __user *optval, unsi
{
int v;
+ if (optlen != sizeof(v))
+ return -EINVAL;
if (get_user(v, (int __user *)optval))
return -EFAULT;
- v = (v) ? 1 : 0;
+ v = !!v;
rtnl_lock();
ret = 0;
@@ -1325,7 +1330,8 @@ int ip_mroute_setsockopt(struct sock *sk, int optname, char __user *optval, unsi
} else {
if (!ipmr_new_table(net, v))
ret = -ENOMEM;
- raw_sk(sk)->ipmr_table = v;
+ else
+ raw_sk(sk)->ipmr_table = v;
}
rtnl_unlock();
return ret;
@@ -1351,6 +1357,10 @@ int ip_mroute_getsockopt(struct sock *sk, int optname, char __user *optval, int
struct net *net = sock_net(sk);
struct mr_table *mrt;
+ if (sk->sk_type != SOCK_RAW ||
+ inet_sk(sk)->inet_num != IPPROTO_IGMP)
+ return -EOPNOTSUPP;
+
mrt = ipmr_get_table(net, raw_sk(sk)->ipmr_table ? : RT_TABLE_DEFAULT);
if (mrt == NULL)
return -ENOENT;
^ permalink raw reply related
* Re: [PATCH net-next] ipv4: ipmr: various fixes and cleanups
From: Joe Perches @ 2012-11-25 18:27 UTC (permalink / raw)
To: Eric Dumazet; +Cc: David Miller, netdev
In-Reply-To: <1353861705.30446.675.camel@edumazet-glaptop>
On Sun, 2012-11-25 at 08:41 -0800, Eric Dumazet wrote:
> 4) " (v) ? 1 : 0 " can be written as " !!v "
Or maybe the compiler could do it by changing
mroute_do_assert and mroute_do_pim to bool to
save a few bytes per table too.
^ permalink raw reply
* Re: [PATCH net-next] ipv4: ipmr: various fixes and cleanups
From: Eric Dumazet @ 2012-11-25 19:13 UTC (permalink / raw)
To: Joe Perches; +Cc: David Miller, netdev
In-Reply-To: <1353868023.6558.10.camel@joe-AO722>
On Sun, 2012-11-25 at 10:27 -0800, Joe Perches wrote:
> On Sun, 2012-11-25 at 08:41 -0800, Eric Dumazet wrote:
> > 4) " (v) ? 1 : 0 " can be written as " !!v "
>
> Or maybe the compiler could do it by changing
> mroute_do_assert and mroute_do_pim to bool to
> save a few bytes per table too.
>
>
Yeah, but mroute is probably used only by a very limited
number of machines in the world.
Please submit an additional patch, as I already put too many
things in mine.
^ permalink raw reply
* [PATCH] ipv4/ipmr and ipv6/ip6mr: Convert int mroute_do_<foo> to bool
From: Joe Perches @ 2012-11-25 19:35 UTC (permalink / raw)
To: Eric Dumazet; +Cc: David Miller, netdev
In-Reply-To: <1353870787.30446.831.camel@edumazet-glaptop>
Save a few bytes per table by convert mroute_do_assert and
mroute_do_pim from int to bool.
Remove !! as the compiler does that when assigning int to bool.
Signed-off-by: Joe Perches <joe@perches.com>
---
> mroute is probably used only by a very limited
> number of machines in the world.
>
> Please submit an additional patch, as I already put too many
> things in mine.
On top of Eric's cleanup...
net/ipv4/ipmr.c | 6 +++---
net/ipv6/ip6mr.c | 6 +++---
2 files changed, 6 insertions(+), 6 deletions(-)
diff --git a/net/ipv4/ipmr.c b/net/ipv4/ipmr.c
index 0394a8e..fc09ef9 100644
--- a/net/ipv4/ipmr.c
+++ b/net/ipv4/ipmr.c
@@ -83,8 +83,8 @@ struct mr_table {
struct vif_device vif_table[MAXVIFS];
int maxvif;
atomic_t cache_resolve_queue_len;
- int mroute_do_assert;
- int mroute_do_pim;
+ bool mroute_do_assert;
+ bool mroute_do_pim;
#if defined(CONFIG_IP_PIMSM_V1) || defined(CONFIG_IP_PIMSM_V2)
int mroute_reg_vif_num;
#endif
@@ -1289,7 +1289,7 @@ int ip_mroute_setsockopt(struct sock *sk, int optname, char __user *optval, unsi
return -EINVAL;
if (get_user(v, (int __user *)optval))
return -EFAULT;
- mrt->mroute_do_assert = !!v;
+ mrt->mroute_do_assert = v;
return 0;
}
#ifdef CONFIG_IP_PIMSM
diff --git a/net/ipv6/ip6mr.c b/net/ipv6/ip6mr.c
index d7330f8..79bb490 100644
--- a/net/ipv6/ip6mr.c
+++ b/net/ipv6/ip6mr.c
@@ -66,8 +66,8 @@ struct mr6_table {
struct mif_device vif6_table[MAXMIFS];
int maxvif;
atomic_t cache_resolve_queue_len;
- int mroute_do_assert;
- int mroute_do_pim;
+ bool mroute_do_assert;
+ bool mroute_do_pim;
#ifdef CONFIG_IPV6_PIMSM_V2
int mroute_reg_vif_num;
#endif
@@ -1648,7 +1648,7 @@ int ip6_mroute_setsockopt(struct sock *sk, int optname, char __user *optval, uns
int v;
if (get_user(v, (int __user *)optval))
return -EFAULT;
- mrt->mroute_do_assert = !!v;
+ mrt->mroute_do_assert = v;
return 0;
}
^ permalink raw reply related
* [PATCH] net: ipmr: limit MRT_TABLE identifiers
From: Eric Dumazet @ 2012-11-25 19:44 UTC (permalink / raw)
To: Chen Gang; +Cc: David Miller, netdev
In-Reply-To: <50AC9CF6.2020501@asianux.com>
From: Eric Dumazet <edumazet@google.com>
Name of pimreg devices are built from following format :
char name[IFNAMSIZ]; // IFNAMSIZ == 16
sprintf(name, "pimreg%u", mrt->id);
We must therefore limit mrt->id to 9 decimal digits
or risk a buffer overflow and a crash.
Restrict table identifiers in [0 ... 999999999] interval.
Reported-by: Chen Gang <gang.chen@asianux.com>
Signed-off-by: Eric Dumazet <edumazet@google.com>
---
net/ipv4/ipmr.c | 4 ++++
1 file changed, 4 insertions(+)
diff --git a/net/ipv4/ipmr.c b/net/ipv4/ipmr.c
index 6168c4d..3eab2b2 100644
--- a/net/ipv4/ipmr.c
+++ b/net/ipv4/ipmr.c
@@ -1318,6 +1318,10 @@ int ip_mroute_setsockopt(struct sock *sk, int optname, char __user *optval, unsi
if (get_user(v, (u32 __user *)optval))
return -EFAULT;
+ /* "pimreg%u" should not exceed 16 bytes (IFNAMSIZ) */
+ if (v != RT_TABLE_DEFAULT && v >= 1000000000)
+ return -EINVAL;
+
rtnl_lock();
ret = 0;
if (sk == rtnl_dereference(mrt->mroute_sk)) {
^ permalink raw reply related
page: next (older) | prev (newer) | latest
- recent:[subjects (threaded)|topics (new)|topics (active)]
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox