Depurar uma tempestade de interrupção
Um dos exemplos mais comuns de um sistema paralisado é uma tempestade de interrupção. Uma tempestade de interrupção é um sinal de interrupção acionado por nível que permanece no estado declarado.
Os seguintes eventos podem causar uma tempestade de interrupção:
Um dispositivo de hardware não libera seu sinal de interrupção depois de receber esta instrução do driver de dispositivo.
Um driver de dispositivo não instrui seu hardware a liberar o sinal de interrupção, porque ele não detecta que a interrupção foi iniciada a partir de seu hardware.
Um driver de dispositivo reivindica a interrupção mesmo que a interrupção não foi iniciada de seu hardware. Essa situação só pode ocorrer quando vários dispositivos estão compartilhando o mesmo IRQ.
O ELCR (registro de controle de nível de borda) não está definido corretamente.
Os dispositivos acionados por interrupção de nível e de borda compartilham um IRQ (por exemplo, uma porta COM e um controlador SCSI do PCI).
Este exemplo demonstra um método para detectar e depurar uma tempestade de interrupção.
Quando o computador travar, use um depurador de kernel para interromper. Use o comando de extensão !irpfind para procurar IRPs pendentes. Em seguida, use a extensão !irp para obter detalhes sobre os IRPs pendentes. Por exemplo:
kd> !irp 81183468
Irp is active with 2 stacks 2 is current (= 0x811834fc)
No Mdl Thread 00000000: Irp stack trace.
cmd flg cl Device File Completion-Context
[ 0, 0] 0 0 8145f470 00000000 00000000-00000000
\Driver\E100B
Args: 00000000 00000000 00000000 00000000
>[ 16, 2] 0 e1 8145f470 00000000 8047f744-814187a8 Success Error Cancel pending
\Driver\E100B ntoskrnl!PopCompleteSystemPowerIrp
Args: 00000000 00000000 00000002 00000002
Este exemplo mostra que \driver\e100b não retornou o IRP para ntoskrnl!PopCompleteSystemPowerIrp. Ele parece estar preso e pode estar passando por uma tempestade de interrupção.
Para investigar, use o comando kb para solicitar um rastreamento de pilha. Por exemplo:
kd> kb
ChildEBP RetAddr Args to Child
f714ee68 8046355a 00000001 80068c10 00000030 ntoskrnl!RtlpBreakWithStatusInstruction
f714ee68 80067a4f 00000001 80068c10 00000030 ntoskrnl!KeUpdateSystemTime+0x13e
f714eeec 8046380b 01001010 0000003b f714ef00 halacpi!HalBeginSystemInterrupt+0x83
f714eeec 80463c50 01001010 0000003b f714ef00 ntoskrnl!KiChainedDispatch+0x1b
f714ef78 80067cc2 00000000 00000240 8000017c ntoskrnl!KiDispatchInterrupt
f714ef78 80501cb5 00000000 00000240 8000017c halacpi!HalpDispatchInterrupt2ndEnt
A seção que começa com halacpi!HalBeginSystemInterrupt é uma expedição de interrupção. Se você usar o comando g e interromper novamente, provavelmente verá um rastreamento de pilha diferente, mas ainda verá uma expedição de interrupção. Para determinar qual interrupção é responsável pela paralisação do sistema, observe o segundo parâmetro passado para HalBeginSystemInterrupt (neste caso, 0x3B). A regra padrão é que o vetor de interrupção exibido (0x3B) é a linha IRQ mais 0x30, portanto, a interrupção é o número 0xB. A execução de outro rastreamento de pilha pode fornecer mais informações sobre qual dispositivo emitiu a ISR (solicitação de serviço de interrupção). Nesse caso, um segundo rastreamento de pilha tem o seguinte resultado:
kd> kb
ChildEBP RetAddr Args to Child
f714ee24 8046355a 00000001 00000010 00000030 ntoskrnl!RtlpBreakWithStatusInstruction
f714ee24 bfe854b9 00000001 00000010 00000030 ntoskrnl!KeUpdateSystemTime+0x13e
f714eed8 f7051796 00000000 80463850 8143ec88 atimpab!AtiInterrupt+0x109
f714eee0 80463850 8143ec88 81444038 8046380b VIDEOPRT!pVideoPortInterrupt+0x16
f714eef8 80463818 00000202 0000003b 80450bb8 ntoskrnl!KiChainedDispatch2ndLvl+0x28
f714eef8 80463c50 00000202 0000003b 80450bb8 ntoskrnl!KiChainedDispatch+0x28
f714ef78 80067cc2 00000000 00000240 8000017c ntoskrnl!KiDispatchInterrupt
f714ef78 80501cb5 00000000 00000240 8000017c halacpi!HalpDispatchInterrupt2ndEntry+0x1b
f714f084 8045f744 f714f16c 00020019 f714f148 ntoskrnl!NtCreateKey+0x113
f714f084 8042e487 f714f16c 00020019 f714f148 ntoskrnl!KiSystemService+0xc4
f714f118 804ab556 f714f16c 00020019 f714f148 ntoskrnl!ZwCreateKey+0xb
f714f184 8041f75b f714f1e8 8000017c f714f1d0 ntoskrnl!IopCreateRegistryKeyEx+0x4e
f714f204 804965cd 8145f630 00000000 00000001 ntoskrnl!IopProcessSetInterfaceState+0x93
f714f220 bfee1eb9 8145f630 00000000 8145f5a0 ntoskrnl!IoSetDeviceInterfaceState+0x2b
f714f254 bfedb416 00000004 00000800 0045f570 NDIS!ndisMCommonHaltMiniport+0x1f
f714f268 bfed4ddb bfed0660 811a2708 811a2708 NDIS!ndisPmHaltMiniport+0x9a
f714f288 bfed5146 811a2708 00000004 8145f570 NDIS!ndisSetPower+0x1d1
f714f2a8 8041c60f 81453a30 811a2708 80475b18 NDIS!ndisPowerDispatch+0x84
f714f2bc 8044cc52 80475b18 811a2708 811a279c ntoskrnl!IopfCallDriver+0x35
f714f2d4 8044cb89 811a279c 811a2708 811a27c0 ntoskrnl!PopPresentIrp+0x62
O sistema está atualmente executando a ISR para a placa de vídeo. O sistema executará a ISR para cada um dos dispositivos que compartilham a IRQ 0xB. Se nenhum processo reivindicar a interrupção, o sistema operacional aguardará infinitamente, solicitando que as ISRs do driver lidem com a interrupção. Também é possível que um processo possa lidar com a interrupção e pará-la, mas se o hardware estiver quebrado, a interrupção poderá simplesmente ser reafirmada.
Use a extensão !arbiter 4 para determinar quais dispositivos estão na IRQ 0xB. Se houver apenas um dispositivo na IRQ 0xB, você terá encontrado a causa do problema. Se houver mais de um dispositivo compartilhando a interrupção (99% dos casos), você precisará isolar o dispositivo programando manualmente os nós LNK (o que será destrutivo para o estado do sistema) ou removendo ou desabilitando o hardware.
kd> !arbiter 4
DEVNODE 8149a008 (HTREE\ROOT\0)
Interrupt Arbiter "RootIRQ" at 80472a20
Allocated ranges:
0000000000000000 - 0000000000000000 B 8149acd0
0000000000000001 - 0000000000000001 B 8149acd0
0000000000000002 - 0000000000000002 B 8149acd0
0000000000000003 - 0000000000000003 B 8149acd0
0000000000000004 - 0000000000000004 B 8149acd0
0000000000000005 - 0000000000000005 B 8149acd0
0000000000000006 - 0000000000000006 B 8149acd0
0000000000000007 - 0000000000000007 B 8149acd0
0000000000000008 - 0000000000000008 B 8149acd0
0000000000000009 - 0000000000000009 B 8149acd0
000000000000000a - 000000000000000a B 8149acd0
000000000000000b - 000000000000000b B 8149acd0
000000000000000c - 000000000000000c B 8149acd0
000000000000000d - 000000000000000d B 8149acd0
000000000000000e - 000000000000000e B 8149acd0
000000000000000f - 000000000000000f B 8149acd0
0000000000000010 - 0000000000000010 B 8149acd0
0000000000000011 - 0000000000000011 B 8149acd0
0000000000000012 - 0000000000000012 B 8149acd0
0000000000000013 - 0000000000000013 B 8149acd0
0000000000000014 - 0000000000000014 B 8149acd0
0000000000000015 - 0000000000000015 B 8149acd0
0000000000000016 - 0000000000000016 B 8149acd0
0000000000000017 - 0000000000000017 B 8149acd0
0000000000000018 - 0000000000000018 B 8149acd0
0000000000000019 - 0000000000000019 B 8149acd0
000000000000001a - 000000000000001a B 8149acd0
000000000000001b - 000000000000001b B 8149acd0
000000000000001c - 000000000000001c B 8149acd0
000000000000001d - 000000000000001d B 8149acd0
000000000000001e - 000000000000001e B 8149acd0
000000000000001f - 000000000000001f B 8149acd0
0000000000000020 - 0000000000000020 B 8149acd0
0000000000000021 - 0000000000000021 B 8149acd0
0000000000000022 - 0000000000000022 B 8149acd0
0000000000000023 - 0000000000000023 B 8149acd0
0000000000000024 - 0000000000000024 B 8149acd0
0000000000000025 - 0000000000000025 B 8149acd0
0000000000000026 - 0000000000000026 B 8149acd0
0000000000000027 - 0000000000000027 B 8149acd0
0000000000000028 - 0000000000000028 B 8149acd0
0000000000000029 - 0000000000000029 B 8149acd0
000000000000002a - 000000000000002a B 8149acd0
000000000000002b - 000000000000002b B 8149acd0
000000000000002c - 000000000000002c B 8149acd0
000000000000002d - 000000000000002d B 8149acd0
000000000000002e - 000000000000002e B 8149acd0
000000000000002f - 000000000000002f B 8149acd0
0000000000000032 - 0000000000000032 B 8149acd0
0000000000000039 - 0000000000000039 S 814776d0 (ACPI)
Possible allocation:
< none >
DEVNODE 81476f28 (ACPI_HAL\PNP0C08\0)
Interrupt Arbiter "ACPI_IRQ" at bfff10e0
Allocated ranges:
0000000000000000 - 0000000000000000 B 81495bb0
0000000000000001 - 0000000000000001 814952b0 (i8042prt)
0000000000000003 - 0000000000000003 S 81495610 (Serial)
0000000000000004 - 0000000000000004 B 8149acd0
0000000000000006 - 0000000000000006 81495730 (fdc)
0000000000000008 - 0000000000000008 81495a90
0000000000000009 - 0000000000000009 S 814776d0 (ACPI)
000000000000000b - 000000000000000b S
000000000000000b - 000000000000000b S 81453c30 (ds1)
000000000000000b - 000000000000000b S 81453a30 (E100B)
000000000000000b - 000000000000000b S 81493c30 (uhcd)
000000000000000b - 000000000000000b S 8145c390 (atirage3)
000000000000000c - 000000000000000c 814953d0 (i8042prt)
000000000000000d - 000000000000000d B 81495850
000000000000000e - 000000000000000e 8145bb50 (atapi)
000000000000000f - 000000000000000f 8145b970 (atapi)
Possible allocation:
< none >
Nesse caso, o áudio, o USB (Barramento Serial Universal), o NIC (adaptador de rede) e o vídeo estão usando a mesma IRQ.
Para descobrir qual ISR reivindica a propriedade da interrupção, examine o valor de retorno da ISR. Basta desmontar a ISR usando o comando U com o endereço fornecido na exibição !arbiter e definir um ponto de interrupção na última instrução da ISR (que será uma instrução "ret"). Observe que usar o comando g <endereço> é o equivalente a definir um ponto de interrupção nesse endereço:
kd> g bfe33e7b
ds1wdm!AdapterIsr+ad:
bfe33e7b c20800 ret 0x8
Use o comando r para examinar os registros. Especificamente, observe o registro EAX. Se o conteúdo do registro EAX mostrado no exemplo de código a seguir for diferente de zero, essa ISR reivindicou a interrupção. Caso contrário, a interrupção não foi reivindicada e o sistema operacional chamará a próxima ISR. Este exemplo mostra que a placa de vídeo não está reivindicando a interrupção:
kd> r
eax=00000000 ebx=813f4ff0 ecx=00000010 edx=ffdff848 esi=8145d168 edi=813f4fc8
eip=bfe33e7b esp=f714eec4 ebp=f714eee0 iopl=0 nv up ei pl zr na po nc
cs=0008 ss=0010 ds=0023 es=0023 fs=0030 gs=0000 efl=00000246
ds1wdm!AdapterIsr+ad:
bfe33e7b c20800 ret 0x8
Na verdade, neste caso, a interrupção não é reivindicada por nenhum dos dispositivos na IRQ 0xb. Quando você encontrar esse problema, também deverá verificar se cada parte do hardware associada à interrupção está realmente habilitada. Para PCI, isso é fácil: veja o registro CMD exibido pela saída da extensão !pci:
kd> !pci 0 0
PCI Bus 0
00:0 8086:7190.03 Cmd[0006:.mb...] Sts[2210:c....] Device Host bridge
01:0 8086:7191.03 Cmd[0107:imb..s] Sts[0220:.6...] PciBridge 0->1-1 PCI-PCI bridge
03:0 1073:000c.03 Cmd[0000:......] Sts[0210:c....] Device SubID:1073:000c Audio device
04:0 8086:1229.05 Cmd[0007:imb...] Sts[0290:c....] Device SubID:8086:0008 Ethernet
07:0 8086:7110.02 Cmd[000f:imb...] Sts[0280:.....] Device ISA bridge
07:1 8086:7111.01 Cmd[0005:i.b...] Sts[0280:.....] Device IDE controller
07:2 8086:7112.01 Cmd[0005:i.b...] Sts[0280:.....] Device USB host controller
07:3 8086:7113.02 Cmd[0003:im....] Sts[0280:.....] Device Class:6:80:0
O registro CMD do chip de áudio (rotulado como "Dispositivo de áudio") é zero. Isso significa que o chip de áudio está efetivamente desabilitado neste momento. Isso também significa que o chip de áudio não responderá aos acessos pelo driver.
Nesse caso, o chip de áudio precisa ser reabilitado manualmente.