Dotaz: ksoftirqd cpu load 89%

[petka]

Zdravim , zjistil jsem nedavno ze neco mi v pravidelnych intervalech brzdi system . Ma s tim taky nekdo zkusenost .

Jedna se o server , na kterym se tim padem zabrzdi veskera komunikace .

Linux server 2.6.31-17-generic #54-Ubuntu SMP Thu Dec 10 16:20:31 UTC 2009 i686 GNU/Linux

 

PID USER      PR  NI  VIRT  RES  SHR S %CPU %MEM    TIME+  COMMAND                                             
4 root      15  -5     0    0    0 R 89.8  0.0   7:12.89 ksoftirqd/0                                         
2633 root      20   0  2064  940  588 R  5.4  0.4   2:58.67 dvblast                                             
2151 root      20   0 61972 4204 1484 S  3.6  1.7   9:06.65 sasc-ng                                             
2944 server    20   0  2484 1044  784 R  1.8  0.4   0:00.02 top                                                 
1 root      20   0  2640 1544 1128 S  0.0  0.6   0:01.03 init                                                
2 root      15  -5     0    0    0 S  0.0  0.0   0:00.00 kthreadd                                            
3 root      RT  -5     0    0    0 S  0.0  0.0   0:00.00 migration/0                                         
5 root      RT  -5     0    0    0 S  0.0  0.0   0:00.00 watchdog/0                                          
6 root      15  -5     0    0    0 S  0.0  0.0   0:00.01 events/0                                            
7 root      15  -5     0    0    0 S  0.0  0.0   0:00.00 cpuset                                              
8 root      15  -5     0    0    0 S  0.0  0.0   0:00.00 khelper                                             
9 root      15  -5     0    0    0 S  0.0  0.0   0:00.00 netns                                               
10 root      15  -5     0    0    0 S  0.0  0.0   0:00.00 async/mgr                                           
11 root      15  -5     0    0    0 S  0.0  0.0   0:00.00 kintegrityd/0                                       
12 root      15  -5     0    0    0 S  0.0  0.0   0:00.08 kblockd/0                                           
13 root      15  -5     0    0    0 S  0.0  0.0   0:00.00 kacpid

Odpovědi

[frr]

Když to nastane, jak dlouho to trvá? Srovná se to samo, nebo je potřeba reboot? Kam tu zátěž řadí "top"? ("hi"? "si"?) Uštědřil byste nám pro zajímavost výpis "lspci -vv", /proc/interrupts a /proc/cpuinfo ? Zajímavý by taky mohl být nějaký "chronologický" záznam /proc/interrupts, např. aspoň dva-tři snapshoty krátce po sobě ve chvíli, kdy problém trvá...

Takhle od stolu to na mě působí dojmem, že se občas zblázní nějaký zdroj přerušení - buď pro něj není obsluha (nainstalovaný ovladač), nebo má obsluha bug, nebo je bug v ACPI IRQ tabulce v BIOSu, nebo je nějaký bug v té oblasti v kernelu... Pokud jde o možné bugy v kernelu, je ta mašina třeba nějak extrémně vytížená na CPU nebo RAM?

Ubuntu nepoužívám, takže nemám žádné poznámky specifické pro Ubuntu... jaký používají kernel, víceméně vanilkový (jako Debian), nebo ho nějak víc patchují?

[frr]

V tomhle vlákně je přiložený nějaký pythonový skript zvaný irqtop, mohl by být užitečný...

[dustin]

Osvědčilo se mi jednoduché

watch -n 1 cat /proc/interrupts

[frr]

Geniální - mám se stále co učit...

[dustin]

Tak od mistra je toto vážně kompliment :)

[frr]

Ještě mě napadlo... co když přidáte v bootloaderu (kernel command line argument) "irqpoll" ? Napadají mě i další možnosti jako pci=routeirq, pci=noacpi, acpi=off aj., ale spíš by mě zajímalo, v čem je doopravdy problém. BTW, zlobí to na holém železe, nebo tam běží nějaká virtualizace?

[petka]

Trva to jak kdy , nekdy chvilku a nekdy kolem 1 minuty . V horsim pripade je to na restart .

root@server:~# lspci -vv
00:00.0 Host bridge: nVidia Corporation nForce2 IGP2 (rev c1)
 Subsystem: ASRock Incorporation Device 01e0
 Control: I/O- Mem+ BusMaster+ SpecCycle- MemWINV- VGASnoop- ParErr- Stepping- SERR- FastB2B- DisINTx-
 Status: Cap+ 66MHz+ UDF- FastB2B+ ParErr- DEVSEL=fast >TAbort- <TAbort- <MAbort- >SERR- <PERR- INTx-
 Latency: 0
 Region 0: Memory at f8000000 (32-bit, prefetchable) [size=64M]
 Capabilities: [40] AGP version 2.0
 Status: RQ=32 Iso- ArqSz=0 Cal=0 SBA+ ITACoh- GART64- HTrans- 64bit- FW+ AGP3- Rate=x1,x2,x4
 Command: RQ=1 ArqSz=0 Cal=0 SBA- AGP- GART64- 64bit- FW- Rate=x1
 Capabilities: [60] HyperTransport: Host or Secondary Interface
 Command: WarmRst+ DblEnd-
 Link Control: CFlE- CST- CFE- <LkFail- Init+ EOC- TXO- <CRCErr=0
 Link Config: MLWI=8bit MLWO=8bit LWI=8bit LWO=8bit
 Revision ID: 0.16
 Kernel driver in use: agpgart-nvidia
 Kernel modules: nvidia-agp

00:00.1 RAM memory: nVidia Corporation nForce2 Memory Controller 1 (rev c1)
 Subsystem: ASRock Incorporation Device 01eb
 Control: I/O- Mem- BusMaster- SpecCycle- MemWINV- VGASnoop- ParErr- Stepping- SERR- FastB2B- DisINTx-
 Status: Cap- 66MHz+ UDF- FastB2B- ParErr- DEVSEL=fast >TAbort- <TAbort- <MAbort- >SERR- <PERR- INTx-

00:00.2 RAM memory: nVidia Corporation nForce2 Memory Controller 4 (rev c1)
 Subsystem: ASRock Incorporation Device 01ee
 Control: I/O- Mem- BusMaster- SpecCycle- MemWINV- VGASnoop- ParErr- Stepping- SERR- FastB2B- DisINTx-
 Status: Cap- 66MHz+ UDF- FastB2B- ParErr- DEVSEL=fast >TAbort- <TAbort- <MAbort- >SERR- <PERR- INTx-

00:00.3 RAM memory: nVidia Corporation nForce2 Memory Controller 3 (rev c1)
 Subsystem: ASRock Incorporation Device 01ed
 Control: I/O- Mem- BusMaster- SpecCycle- MemWINV- VGASnoop- ParErr- Stepping- SERR- FastB2B- DisINTx-
 Status: Cap- 66MHz+ UDF- FastB2B- ParErr- DEVSEL=fast >TAbort- <TAbort- <MAbort- >SERR- <PERR- INTx-

00:00.4 RAM memory: nVidia Corporation nForce2 Memory Controller 2 (rev c1)
 Subsystem: ASRock Incorporation Device 01ec
 Control: I/O- Mem- BusMaster- SpecCycle- MemWINV- VGASnoop- ParErr- Stepping- SERR- FastB2B- DisINTx-
 Status: Cap- 66MHz+ UDF- FastB2B- ParErr- DEVSEL=fast >TAbort- <TAbort- <MAbort- >SERR- <PERR- INTx-

00:00.5 RAM memory: nVidia Corporation nForce2 Memory Controller 5 (rev c1)
 Subsystem: ASRock Incorporation Device 01ef
 Control: I/O- Mem- BusMaster- SpecCycle- MemWINV- VGASnoop- ParErr- Stepping- SERR- FastB2B- DisINTx-
 Status: Cap- 66MHz+ UDF- FastB2B- ParErr- DEVSEL=fast >TAbort- <TAbort- <MAbort- >SERR- <PERR- INTx-

00:01.0 ISA bridge: nVidia Corporation MCP2A ISA bridge (rev a3)
 Subsystem: ASRock Incorporation Device 0080
 Control: I/O+ Mem+ BusMaster+ SpecCycle+ MemWINV- VGASnoop- ParErr- Stepping- SERR- FastB2B- DisINTx-
 Status: Cap+ 66MHz+ UDF- FastB2B+ ParErr- DEVSEL=fast >TAbort- <TAbort- <MAbort- >SERR- <PERR- INTx-
 Latency: 0
 Capabilities: [48] HyperTransport: Slave or Primary Interface
 Command: BaseUnitID=1 UnitCnt=15 MastHost- DefDir-
 Link Control 0: CFlE- CST- CFE- <LkFail- Init+ EOC+ TXO- <CRCErr=0
 Link Config 0: MLWI=8bit MLWO=8bit LWI=8bit LWO=8bit
 Link Control 1: CFlE- CST- CFE- <LkFail- Init+ EOC- TXO+ <CRCErr=0
 Link Config 1: MLWI=8bit MLWO=8bit LWI=8bit LWO=8bit
 Revision ID: 0.00

00:01.1 SMBus: nVidia Corporation MCP2A SMBus (rev a1)
 Subsystem: ASRock Incorporation Device 0084
 Control: I/O+ Mem- BusMaster- SpecCycle- MemWINV- VGASnoop- ParErr- Stepping- SERR- FastB2B- DisINTx-
 Status: Cap+ 66MHz+ UDF- FastB2B+ ParErr- DEVSEL=fast >TAbort- <TAbort- <MAbort- >SERR- <PERR- INTx-
 Interrupt: pin A routed to IRQ 5
 Region 0: I/O ports at d480 [size=32]
 Capabilities: [44] Power Management version 2
 Flags: PMEClk- DSI- D1- D2- AuxCurrent=0mA PME(D0-,D1-,D2-,D3hot+,D3cold+)
 Status: D0 PME-Enable- DSel=0 DScale=0 PME-
 Kernel driver in use: nForce2_smbus
 Kernel modules: i2c-nforce2

00:02.0 USB Controller: nVidia Corporation MCP2A USB Controller (rev a1) (prog-if 10)
 Subsystem: ASRock Incorporation Device 0087
 Control: I/O+ Mem+ BusMaster+ SpecCycle- MemWINV- VGASnoop- ParErr- Stepping- SERR- FastB2B- DisINTx-
 Status: Cap+ 66MHz+ UDF- FastB2B+ ParErr- DEVSEL=fast >TAbort- <TAbort- <MAbort- >SERR- <PERR- INTx-
 Latency: 0 (750ns min, 250ns max)
 Interrupt: pin A routed to IRQ 20
 Region 0: Memory at febfb000 (32-bit, non-prefetchable) [size=4K]
 Capabilities: [44] Power Management version 2
 Flags: PMEClk- DSI- D1+ D2+ AuxCurrent=0mA PME(D0+,D1+,D2+,D3hot+,D3cold+)
 Status: D0 PME-Enable- DSel=0 DScale=0 PME-
 Kernel driver in use: ohci_hcd

00:02.1 USB Controller: nVidia Corporation MCP2A USB Controller (rev a1) (prog-if 10)
 Subsystem: ASRock Incorporation Device 0087
 Control: I/O+ Mem+ BusMaster+ SpecCycle- MemWINV- VGASnoop- ParErr- Stepping- SERR- FastB2B- DisINTx-
 Status: Cap+ 66MHz+ UDF- FastB2B+ ParErr- DEVSEL=fast >TAbort- <TAbort- <MAbort- >SERR- <PERR- INTx-
 Latency: 0 (750ns min, 250ns max)
 Interrupt: pin B routed to IRQ 22
 Region 0: Memory at febfc000 (32-bit, non-prefetchable) [size=4K]
 Capabilities: [44] Power Management version 2
 Flags: PMEClk- DSI- D1+ D2+ AuxCurrent=0mA PME(D0+,D1+,D2+,D3hot+,D3cold+)
 Status: D0 PME-Enable- DSel=0 DScale=0 PME-
 Kernel driver in use: ohci_hcd

00:02.2 USB Controller: nVidia Corporation MCP2A USB Controller (rev a2) (prog-if 20)
 Subsystem: ASRock Incorporation Device 0088
 Control: I/O- Mem+ BusMaster+ SpecCycle- MemWINV- VGASnoop- ParErr- Stepping- SERR- FastB2B- DisINTx-
 Status: Cap+ 66MHz+ UDF- FastB2B+ ParErr- DEVSEL=fast >TAbort- <TAbort- <MAbort- >SERR- <PERR- INTx-
 Latency: 0 (750ns min, 250ns max)
 Interrupt: pin C routed to IRQ 21
 Region 0: Memory at febfdc00 (32-bit, non-prefetchable) [size=256]
 Capabilities: [44] Debug port: BAR=1 offset=0098
 Capabilities: [80] Power Management version 2
 Flags: PMEClk- DSI- D1+ D2+ AuxCurrent=0mA PME(D0+,D1+,D2+,D3hot+,D3cold+)
 Status: D0 PME-Enable- DSel=0 DScale=0 PME-
 Kernel driver in use: ehci_hcd

00:04.0 Bridge: nVidia Corporation MCP2A Ethernet Controller (rev a3)
 Subsystem: ASRock Incorporation Device 0900
 Control: I/O+ Mem+ BusMaster+ SpecCycle- MemWINV- VGASnoop- ParErr- Stepping- SERR- FastB2B- DisINTx-
 Status: Cap+ 66MHz+ UDF- FastB2B+ ParErr- DEVSEL=fast >TAbort- <TAbort- <MAbort- >SERR- <PERR- INTx-
 Latency: 0 (250ns min, 5000ns max)
 Interrupt: pin A routed to IRQ 21
 Region 0: Memory at febfe000 (32-bit, non-prefetchable) [size=4K]
 Region 1: I/O ports at dc00 [size=8]
 Capabilities: [44] Power Management version 2
 Flags: PMEClk- DSI- D1+ D2+ AuxCurrent=0mA PME(D0+,D1+,D2+,D3hot+,D3cold+)
 Status: D0 PME-Enable+ DSel=0 DScale=0 PME-
 Kernel driver in use: forcedeth
 Kernel modules: forcedeth

00:06.0 Multimedia audio controller: nVidia Corporation MCP2S AC'97 Audio Controller (rev a1)
 Subsystem: ASRock Incorporation Device 9761
 Control: I/O+ Mem+ BusMaster+ SpecCycle- MemWINV- VGASnoop- ParErr- Stepping- SERR- FastB2B- DisINTx-
 Status: Cap+ 66MHz+ UDF- FastB2B+ ParErr- DEVSEL=fast >TAbort- <TAbort- <MAbort- >SERR- <PERR- INTx-
 Latency: 0 (500ns min, 1250ns max)
 Interrupt: pin A routed to IRQ 20
 Region 0: I/O ports at d800 [size=256]
 Region 1: I/O ports at e800 [size=128]
 Region 2: Memory at febff000 (32-bit, non-prefetchable) [size=4K]
 Capabilities: [44] Power Management version 2
 Flags: PMEClk- DSI- D1+ D2+ AuxCurrent=0mA PME(D0-,D1-,D2-,D3hot-,D3cold-)
 Status: D0 PME-Enable- DSel=0 DScale=0 PME-
 Kernel driver in use: Intel ICH
 Kernel modules: snd-intel8x0

00:08.0 PCI bridge: nVidia Corporation MCP2A PCI Bridge (rev a3)
 Control: I/O+ Mem+ BusMaster+ SpecCycle- MemWINV- VGASnoop- ParErr- Stepping- SERR+ FastB2B- DisINTx-
 Status: Cap- 66MHz+ UDF- FastB2B+ ParErr- DEVSEL=fast >TAbort- <TAbort- <MAbort- >SERR- <PERR- INTx-
 Latency: 0
 Bus: primary=00, secondary=02, subordinate=02, sec-latency=32
 I/O behind bridge: 0000c000-0000cfff
 Memory behind bridge: fea00000-feafffff
 Prefetchable memory behind bridge: 10000000-100fffff
 Secondary status: 66MHz- FastB2B+ ParErr- DEVSEL=medium >TAbort- <TAbort- <MAbort+ <SERR- <PERR-
 BridgeCtl: Parity- SERR+ NoISA- VGA- MAbort- >Reset- FastB2B-
 PriDiscTmr- SecDiscTmr- DiscTmrStat- DiscTmrSERREn-
 Kernel modules: shpchp

00:09.0 IDE interface: nVidia Corporation MCP2A IDE (rev a3) (prog-if 8a [Master SecP PriP])
 Subsystem: ASRock Incorporation Device 0085
 Control: I/O+ Mem- BusMaster+ SpecCycle- MemWINV- VGASnoop- ParErr- Stepping- SERR- FastB2B- DisINTx-
 Status: Cap+ 66MHz+ UDF- FastB2B+ ParErr- DEVSEL=fast >TAbort- <TAbort- <MAbort- >SERR- <PERR- INTx-
 Latency: 0 (750ns min, 250ns max)
 Region 0: [virtual] Memory at 000001f0 (32-bit, non-prefetchable) [disabled] [size=8]
 Region 1: [virtual] Memory at 000003f0 (type 3, non-prefetchable) [disabled] [size=1]
 Region 2: [virtual] Memory at 00000170 (32-bit, non-prefetchable) [disabled] [size=8]
 Region 3: [virtual] Memory at 00000370 (type 3, non-prefetchable) [disabled] [size=1]
 Region 4: I/O ports at ffa0 [size=16]
 Capabilities: [44] Power Management version 2
 Flags: PMEClk- DSI- D1- D2- AuxCurrent=0mA PME(D0-,D1-,D2-,D3hot-,D3cold-)
 Status: D0 PME-Enable- DSel=0 DScale=0 PME-
 Kernel driver in use: pata_amd

00:0b.0 IDE interface: nVidia Corporation nForce2 Serial ATA Controller (rev a3) (prog-if 85 [Master SecO PriO])
 Subsystem: ASRock Incorporation Device 008e
 Control: I/O+ Mem- BusMaster+ SpecCycle- MemWINV- VGASnoop- ParErr- Stepping- SERR- FastB2B- DisINTx-
 Status: Cap+ 66MHz+ UDF- FastB2B+ ParErr- DEVSEL=fast >TAbort- <TAbort- <MAbort- >SERR- <PERR- INTx-
 Latency: 0 (750ns min, 250ns max)
 Interrupt: pin A routed to IRQ 22
 Region 0: I/O ports at 0ff8 [size=8]
 Region 1: I/O ports at 0ff0 [size=4]
 Region 2: I/O ports at 0fe8 [size=8]
 Region 3: I/O ports at 0fe0 [size=4]
 Region 4: I/O ports at e400 [size=16]
 Region 5: I/O ports at e000 [size=128]
 Capabilities: [44] Power Management version 2
 Flags: PMEClk- DSI- D1- D2- AuxCurrent=0mA PME(D0-,D1-,D2-,D3hot-,D3cold-)
 Status: D0 PME-Enable- DSel=0 DScale=0 PME-
 Kernel driver in use: sata_nv

00:1e.0 PCI bridge: nVidia Corporation nForce2 AGP (rev c1)
 Control: I/O+ Mem+ BusMaster+ SpecCycle- MemWINV- VGASnoop- ParErr- Stepping- SERR+ FastB2B- DisINTx-
 Status: Cap- 66MHz+ UDF- FastB2B- ParErr- DEVSEL=medium >TAbort- <TAbort- <MAbort- >SERR- <PERR- INTx-
 Latency: 32
 Bus: primary=00, secondary=01, subordinate=01, sec-latency=32
 Memory behind bridge: fc900000-fe9fffff
 Prefetchable memory behind bridge: e4800000-f47fffff
 Secondary status: 66MHz+ FastB2B- ParErr- DEVSEL=medium >TAbort- <TAbort- <MAbort+ <SERR- <PERR-
 BridgeCtl: Parity+ SERR+ NoISA- VGA+ MAbort- >Reset- FastB2B-
 PriDiscTmr- SecDiscTmr- DiscTmrStat- DiscTmrSERREn-
 Kernel modules: shpchp

01:00.0 VGA compatible controller: nVidia Corporation NV11 [GeForce2 MX/MX 400] (rev b2)
 Subsystem: ASUSTeK Computer Inc. Device 4041
 Control: I/O+ Mem+ BusMaster+ SpecCycle- MemWINV- VGASnoop- ParErr- Stepping- SERR- FastB2B- DisINTx-
 Status: Cap+ 66MHz+ UDF- FastB2B+ ParErr- DEVSEL=medium >TAbort- <TAbort- <MAbort- >SERR- <PERR- INTx-
 Latency: 32 (1250ns min, 250ns max)
 Interrupt: pin A routed to IRQ 10
 Region 0: Memory at fd000000 (32-bit, non-prefetchable) [size=16M]
 Region 1: Memory at e8000000 (32-bit, prefetchable) [size=128M]
 Expansion ROM at fe9f0000 [disabled] [size=64K]
 Capabilities: [60] Power Management version 2
 Flags: PMEClk- DSI- D1- D2- AuxCurrent=0mA PME(D0-,D1-,D2-,D3hot-,D3cold-)
 Status: D0 PME-Enable- DSel=0 DScale=0 PME-
 Capabilities: [44] AGP version 2.0
 Status: RQ=32 Iso- ArqSz=0 Cal=0 SBA- ITACoh- GART64- HTrans- 64bit- FW+ AGP3- Rate=x1,x2,x4
 Command: RQ=1 ArqSz=0 Cal=0 SBA- AGP- GART64- 64bit- FW- Rate=<none>
 Kernel modules: nvidiafb, rivafb

02:08.0 Ethernet controller: Realtek Semiconductor Co., Ltd. RTL-8139/8139C/8139C+ (rev 10)
 Subsystem: Realtek Semiconductor Co., Ltd. RTL-8139/8139C/8139C+
 Control: I/O+ Mem+ BusMaster+ SpecCycle- MemWINV- VGASnoop- ParErr- Stepping- SERR+ FastB2B- DisINTx-
 Status: Cap- 66MHz- UDF- FastB2B+ ParErr- DEVSEL=medium >TAbort- <TAbort- <MAbort- >SERR- <PERR- INTx-
 Latency: 32 (8000ns min, 16000ns max)
 Interrupt: pin A routed to IRQ 16
 Region 0: I/O ports at c800 [size=256]
 Region 1: Memory at feadfc00 (32-bit, non-prefetchable) [size=256]
 Expansion ROM at 10000000 [disabled] [size=64K]
 Kernel driver in use: 8139too
 Kernel modules: epl, 8139too, 8139cp

02:09.0 Ethernet controller: Atheros Communications Inc. Atheros AR5001X+ Wireless Network Adapter (rev 01)
 Subsystem: Atheros Communications Inc. Device 2051
 Control: I/O- Mem+ BusMaster+ SpecCycle- MemWINV+ VGASnoop- ParErr- Stepping- SERR+ FastB2B- DisINTx-
 Status: Cap+ 66MHz- UDF- FastB2B+ ParErr- DEVSEL=medium >TAbort- <TAbort- <MAbort- >SERR- <PERR- INTx-
 Latency: 168 (2500ns min, 7000ns max), Cache Line Size: 256 bytes
 Interrupt: pin A routed to IRQ 17
 Region 0: Memory at feae0000 (32-bit, non-prefetchable) [size=64K]
 Capabilities: [44] Power Management version 2
 Flags: PMEClk- DSI- D1- D2- AuxCurrent=375mA PME(D0-,D1-,D2-,D3hot-,D3cold-)
 Status: D0 PME-Enable- DSel=0 DScale=2 PME-
 Kernel driver in use: ath_pci
 Kernel modules: ath_pci, ath5k

02:0a.0 Network controller: Techsan Electronics Co Ltd B2C2 FlexCopII DVB chip / Technisat SkyStar2 DVB card (rev 02)
 Subsystem: Techsan Electronics Co Ltd B2C2 FlexCopII DVB chip / Technisat SkyStar2 DVB card
 Control: I/O+ Mem+ BusMaster+ SpecCycle- MemWINV- VGASnoop- ParErr- Stepping- SERR+ FastB2B- DisINTx-
 Status: Cap- 66MHz- UDF- FastB2B- ParErr- DEVSEL=slow >TAbort- <TAbort- <MAbort- >SERR- <PERR- INTx-
 Latency: 32
 Interrupt: pin A routed to IRQ 18
 Region 0: Memory at feaf0000 (32-bit, non-prefetchable) [size=64K]
 Region 1: I/O ports at cc00 [size=32]
 Kernel driver in use: b2c2_flexcop_pci
 Kernel modules: b2c2-flexcop-pci

Vsiml jsem si ze se to svtava pri vetsim prenosu dat pres wlan0 v modu ap . Napriklad streamovane video . Tipnul bych to na spatne ovladace wifi karty Atheros AR5001X+ .

Ovladac je ze zdrojaku madwifi-0.9.4-r4119-20100201 .

[frr]

> Vsiml jsem si ze se to svtava pri vetsim prenosu dat pres wlan0 v modu ap .
> Napriklad streamovane video . Tipnul bych to na spatne ovladace wifi karty
> Atheros AR5001X+ .

Hmm... žeby closed-source HAL? Ale vlastně MadWifi do hloubky nerozumím, nerad bych lacině ukazoval prstem.
Bylo by zajímavé vědět, jak se vyvíjí /proc/interrupts ve chvíli, kdy to nastane. Mohlo by to ukázat na konkrétní zařízení - wifi nebo nějaké jiné. Taky je potenciálně možné, že nadměrná spotřeba CPU vzniká nějakým nezdravým cyklem v obsluze (konkrétně v kontextu "soft IRQ"), a počet hardwarových IRQ událostí nebude nijak extrémní...
Pokud chcete tuhle hypotézu otestovat, zvažte přechod na ath5k. Pokud z Vašeho výpisu správně dešifruji PCI Device ID = 0x0013, tak se zdá, že Váš čip je open-source driverem ath5k podporován. Je fakt, že framework mac80211/cfg80211/nl80211 se poslední dobou bouřlivě vyvíjí, možná by to chtělo novější jádro, tak 2.6.33 nebo vyšší.
Taky je možné, že Vaše Ubuntu driver ath5k v nějaké verzi obsahuje a stačí ho "odzátkovat".

[petka]

Uz jsem zkousel ath5k , ale mam s nim problem v modu ap stale nefunguje spravne . Proto jsem musel odazatkovat ath_pci a zazatkovat ath5k .

Nevim zkusim stahnou posledni aktualizaci ovladace , doufam ze se neco zmenilo . Trochu jsem testoval system a dela to jen pri prenosu pres wifi .

[LFCIB]

Přílohy:

• lspci-vv.txt (20738 bytů)
• Ping_loopback_last_864000.png (27635 bytů)

Ahoj,

mám stejný problém.

Debian GNU/Linux 2.6.26-2-686 #1 SMP Thu Sep 16 19:35:51 UTC 2010 i686 GNU/Linux

Je to router do netu s trafikem přes 20 Mib/s víceméně stabilně.

Ke zbavení problému pomůže jedině restart. Přikládám i graf pingu na loopback, kde je vidět co to udělá po několika dnech bez restartu.

Má dvě gigové síťovky Intel Corporation PRO/1000 GT Desktop Adapter což asi předpokládám bude ten problém na přerušení. Co tam máte Vy?

V příloze je výpis lspci -vv

           CPU0       CPU1
  0:         67          0   IO-APIC-edge      timer
  1:          8          0   IO-APIC-edge      i8042
  7:          0          0   IO-APIC-edge      parport0
  8:          5          0   IO-APIC-edge      rtc0
  9:          0          0   IO-APIC-fasteoi   acpi
 14:    6530373          0   IO-APIC-edge      ata_piix
 15:          0          0   IO-APIC-edge      ata_piix
 16:          0          0   IO-APIC-fasteoi   uhci_hcd:usb1, ahci
 17:          0          0   IO-APIC-fasteoi   uhci_hcd:usb2, ide0, ide1
 18:          0          0   IO-APIC-fasteoi   ehci_hcd:usb3, uhci_hcd:usb6
 19:          0          0   IO-APIC-fasteoi   uhci_hcd:usb5, ata_piix
 21: 1046331285          0   IO-APIC-fasteoi   eth0
 22: 1507344592          0   IO-APIC-fasteoi   eth1
 23:          0          0   IO-APIC-fasteoi   uhci_hcd:usb4, ehci_hcd:usb7
NMI:          0          0   Non-maskable interrupts
LOC: 1205108286   11074877   Local timer interrupts
RES:      33283      36976   Rescheduling interrupts
CAL:     118418     100232   function call interrupts
TLB:    1239099    1365167   TLB shootdowns
TRM:          0          0   Thermal event interrupts
SPU:          0          0   Spurious interrupts
ERR:          0
MIS:          0

[frr]

... a v kritické situaci "top" říká, že je CPU přetížené v softirq? Opravdu je to identický problém?

Ten graf říká, že se ping na loopback postupně den za dnem zhoršuje. Jsou tam vidět drobné "hrby" prime time. Jako kdyby se někde postupně zhoršovala fragmentace, nebo narůstal nějaký seznam který je třeba procházet, nebo se krutě rozbalancoval nějaký strom, nebo co. Aniž bych o tom cokoli věděl, napadá mě scatter-gather DMA alokující a dealokující buffery pořád dokola podle potřeby. Nebo podobný jev někde v obecné správě paměti (uff). Nenapadá mě, jak by se dalo něčeho takového dosáhnout (ne)šikovnou konfigurací IPtables apod. Hehe... žeby nějaká porucha ve správě asociativní tabulky při "stateful inspection" v netfilteru? Těžko říct... A když postavíte kernel "znovu na start", tak je zase chvíli klid. Tohle by bylo zralé na dotaz do LKML - až na to, že 2.6.26.2 je jednak docela starý kernel, jednak skoro kulatá verze... co takhle upgrade na nějakou verzi, která je buď citelně mladší, nebo má hodně vysoký počet "desetin", nejlíp oboje? V Debianu se používají takřka vanilkové kernely, upgrade na mnohem vyšší verzi by technicky neměl být problém...

Docela by mě zajímal postupný časový vývoj "TLB Shootdowns" Jestli rostou lineárně (tj. za jednotku času k nim dochází pořád stejně), nebo jestli nějak akcelerují... A najdou se i další zajímavé indikátory ohledně fragmentace paměti a ohledně počtů různých "soft IRQ": /proc/buddyinfo, /proc/pagetypeinfo, /proc/softirqs . Viz Documentation/filesystems/proc.txt

[petka]

Vypis

root@server:~# cat /proc/interrupts
 CPU0       
 0:         45   IO-APIC-edge      timer
 1:         14   IO-APIC-edge      i8042
 4:          7   IO-APIC-edge    
 6:          5   IO-APIC-edge      floppy
 7:          0   IO-APIC-edge      parport0
 8:          0   IO-APIC-edge      rtc0
 9:          0   IO-APIC-fasteoi   acpi
 14:      44087   IO-APIC-edge      pata_amd
 15:          0   IO-APIC-edge      pata_amd
 16:      27913   IO-APIC-fasteoi   eth0
 17:    5367178   IO-APIC-fasteoi   ath
 18:    3774770   IO-APIC-fasteoi   Technisat/B2C2 FlexCop II/IIb/III Digital TV PCI Driver
 20:          0   IO-APIC-fasteoi   ohci_hcd:usb2, NVidia CK8
 21:    9667858   IO-APIC-fasteoi   ehci_hcd:usb1, eth1
 22:      65617   IO-APIC-fasteoi   sata_nv, ohci_hcd:usb3
NMI:          0   Non-maskable interrupts
LOC:    1229256   Local timer interrupts
SPU:          0   Spurious interrupts
CNT:          0   Performance counter interrupts
PND:          0   Performance pending work
RES:          0   Rescheduling interrupts
CAL:          0   Function call interrupts
TLB:          0   TLB shootdowns
TRM:          0   Thermal event interrupts
THR:          0   Threshold APIC interrupts
MCE:          0   Machine check exceptions
MCP:         26   Machine check polls
ERR:          0
MIS:          0

Ovladac ath_pci spolecne s wlanconfig jsem vymelnil za uz funkcni ath5k a posledni hostapd . A problem zmizel . Server uz jede bez problemu , jen pravidelne kostikovani streamovaneho obrazu z dvb-s karty po cca 1 min . Zatim jsem na nic neprisel zkusim zmeni udp za rtp .

[frr]

Zakostičkuje jednou za minutu? Zajímavé...

Vy máte čipset od Nvidie - tady nemůžu moc sloužit, jsem odkojený Intelem. Zrovna v práci řeším problém s jedním člověkem, který má Ubuntu Server s jádrem okolo 2.6.31 na nějakém "generačně starším" fanless hardwaru: Intel Pentium M na čipsetu i852+ICH4M. Jeho problém spočívá v tom, že se mu zpožďují systémové hodiny. A vypadá to, že vždycky jednou za nějaký čas ztratí skokem třeba zlomek vteřiny, nebo možná i vteřinu. (Viz adjtimex, nebo třeba jenom "hwclock" proti "date".) Jako kdyby počítač na chvíli přestal reagovat na IRQčka. Pokud by se tohle stalo při streamování videa, dokážu si představit viditelné důsledky.

Obvyklým podezřelým v takových případech je nemírné použití SMI ze strany BIOSu - ale docela těžko se to vůbec detekuje a je i problém proti tomu něco dělat. Vypnout jednotlivé zdroje "neškodých" SMI bych uměl, ale u některých zdrojů SMI při jejich zákazu vytuhne počítač... Obvyklým podezřelým je emulace PS/2 klávesnice a myši nad USB (a viděl jsem i emulovaný floppy řadič) - čili tohle v BIOSu vypnout. A pak obecně některé funkce ACPI. Pokud jde ACPI šmahem vypnout, tak do toho - s trochou štěstí bude BIOS podporovat starší standard MPS a Linux si povolí APIC a naroutuje vysoké interrupty tímto způsobem. Anebo je to možná špecifikum Ubuntu - můj starší Fedoří user space s relativně novými jádry na tomtéž hardwaru jede jako z praku, čas běží normálně.

Mimochodem off topic poznámka: z Vašeho výpisu /proc/interrupts je vidět, že kernel používá pro taktování scheduleru "local timer" (těžko říct který, jestli PM timer, HPET, LAPIC timer nebo co) namísto klasického PCčkovéo i8254 "PIT" na IRQ0

[LFCIB]

... a v kritické situaci "top" říká, že je CPU přetížené v softirq? Opravdu je to identický problém?

Ano, přesně tak. Napadá mě nárůst conntrack tabulky, ale jak by to souviselo s irq? Budu to sledovat, za pár dní to bude kulminovat. Přenosová rychlost pak klesne cca na 40% z normálu. Dělalo mi to i na starším jádře z minulého stable Debianu. Ještě se do toho ponořím a napíšu sem pak nové info.

LFCIB

[frr]

Bohužel neznám netfilter pod haubnou, takže netuším, v jakém kontextu nebo kthreadu se vlastně pravidla chroupou... nevylučuju, že právě v soft-irq. Na okraj: mám takový pocit, že to bývalo soustředěno na jediné jádro (= chroupání IPtables se nerozloží mezi více jader).

[frr]

Pokud jde o hypotézu "nárůst tabulky": jak to vidí utilita conntrack? man 8 conntrack

[LFCIB]

Dobrý večer,

počet záznamů v tabulce na to nemá vliv. 2500 záznamů a ksoftirqd zatěžuje kolem 10% procesoru, občas to vyletí výš. Po vymazání tabulky žádný efekt. Na ping to taky nemá vliv, pořád roste latence, nyní se pohybuje kolem 3-5 ms. Je to obyčejné splácané PC.

 Local timer interrupts                   2113
 eth1                                     1802
 eth0                                     1240

[LFCIB]

Příloha:

• Ping_OK_last_864000.png (32475 bytů)

Tak změna, cca 2 hodiny potom co jsem vymazal conntrack tabulku se ten proces uklidnil a trvá to až doteď. Nyní je v tabulce cca 2900 spojení z toho 400 UNREPLIED. Předchozí stav byl okolo 2500 spojení a UN.. nevím.

Ping je na grafu v příloze.

Nechápu co to způsobuje. IRQ čítače jsou podobné jako předtím.

 Local timer interrupts                   3142
 eth1                                     3623
 eth0                                     2327

Díky

[frr]

Hmm... Vy jste se nám ještě nepochlubil verzí jádra

Pokud se týče conntrack tabulky, napadá mě, že by situaci mohla zhoršovat nějaká horda zombies, která tu tabulku postupně zahltí, jak se snaží všude možně rozesílat spamy, skenovat porty nebo tak něco - ale zas mi to nepřipadá moc pravděpodobné, jednak Vaše čísla z výpisu "conntrack" takovému hlcení nenasvědčují, druhak pokud jsem měl někde tenhle typ problému, tak se zombík většinou po resetu rozjel během pár minut, pak vystropoval nějaké úzké hrdlo a už jel pořád stejně rychle (na stropě). Náběh dlouhý 10 dní je blbost. A kdyby, tak bych nečekal, že to shodí zrovna firewall... Dočetl jsem se, že se dají ladit pouze dva parametry conntrack tabulky: jednak velikost hash tabulky, jednak objem paměti, který na ni lze obětovat. Je fakt, že protní rozskok skrz hash tabulku vede na uzly, ve kterých se pak prochází spojový seznam. Nemám představu, zda je reálné, abyste v této oblasti měl problém či nikoli - kdyžtak zkuste experimentovat. Je možné, že defaulty kernelu nebo Vaší distribuce jsou zbytečně asketické

No a pak jsem našel pár dalších zmínek, co taky může způsobovat vysokou zátěž ksoftirqd. Docela často se objevovala zmínka o softwarovém bridgingu a jeho STP, kde byla by default nastavena příliš vysoká frekvence HELO zpráv. Případně snad bridging v kombinaci s dynticks. V jednom případě okolo 2.6.22 byl nějaký problém s jakýmsi časovačem v TCP stacku - to se ale pochopitelně týkalo jenom TCP provozu zakončeného v user space procesu na daném stroji, nikoli prostého forwardingu procházejících paketů...

Pokud se týče nástrojů, které mohou poskytnout nějakou představu "co to tam sakra běží", existuje několik více či méně irelevantních, např.:

• /proc/timer_stats - statistiky tikání několika různých timerů
• latencytop - nic moc, zaměřuje se víceméně na vybrané blokující syscally (a čas strávený v zablokovaných voláních), což vlastně není náš případ.
• powertop - údajně často leccos odhalí (ukazuje nejčastější "důvody probuzení")
• oprofile - konkrétně "opreport -d", tj. detailní výpis by mohl obsahovat podrobnosti až na úroveň funkcí, snad i v rámci ksoftirqd. Tenhle nástroj je asi nejmocnější, ale taky relativně náročnější na použití než ostatní (je potřeba si zkompilovat jádro s podporou oprofile, a pro samostatné debugování taky trochu rozumět Cčku a kernelovým zdrojákům)

V podstatě bych to viděl na dotaz do LKML s přiloženým detailním výpisem oprofile, ale nutnou podmínkou je, že to napřed reprodukujete na nějakém rozumně novém jádře... Staré vykopávky nikdo ladit nebude, protože ten problém byl možná dávno vyřešen.

[JF]

Jednu zkusennost s ksoftirqd/0 uz mam.

Obcas se takhle zaseknul MadWiFi.

Takze abych to shrnul, pravdepodobne je nejaky jiny driver v kernelu defektni.

[petka]

Asi nejak tak u me to byl spatny ovladac , jeste bych zkusil novejsi jadro a ovladace . Mozna to pomuze .

Zapomel jsem dodat , ze mi na serveru bezi vycuc top do rrd grafu a nekdy se stalo ze po nejake zatezi " zrejme madfiwi ovladace " softirq vyletel nahoru a pak se drzel na 50% zatizeni cpu . Pomohl az jen restart . Ted uz tohle resit nemusim , vedet tohle tak jsem uz driv presel na novejsi ovladace .

[JF]

me stacilo:

ifconfig ath0 down
rmmod ath_pci
modprobe ath_pci
 ...... nakonfiguruje se ath0
ifconfig ath0 up

Pokud mas madwifi, tak bohuzel to nechali vyvojari shnit. Uz ho nikdo dale nevyviji a ovladac se sam od sebe rozpada. Jedine ath5k je aktivne vyvijen.

[JF]

Ono stačí trochu hledat:
http://permalink.gmane.org/gmane.linux.drivers.madwifi.user/15084 http://www.mail-archive.com/madwifi-tickets@lists.sourceforge.net/msg10793.html http://linux.derkeiler.com/Mailing-Lists/Kernel/2009-08/msg10844.html

[frr]

Jo. Čili e1000e měl taky nějaké dětské nemoci v téhle oblasti.

A "echo t > /proc/sysrq-trigger" je taky dobrej fígl Člověk vlastně ani nepotřebuje oprofile.