The machine this is being tested on is a Tyan Tomcat IIID with 2 x 166Mhz
Intel CPUs. This system works perfectly with 2.0.33 (Yes the WD7000 card
works perfectly in that), and with 2.1.101 (Everything works EXCEPT the
WD7000 card).
Linux 2.1.103 :
enabling symmetric IO mode ... ...done
enabling IO_APIC IRQs
init IO_APIC IRQs
IO-APIC pin 0,20,21,22,23 not connected.
MP-BIOS bug : 8254 timer not connected to IO_APIC
... trying to set up timer as Ext INT... ..(found pin 0).. failed
.. trying to set up timer as BP IRQ... failed
Kernel Panic: IO_APIC timer doesn't work
In Swapper task - not syncing
Here is the boot from Linux 2.1.101 (102 reacts pretty much the same way) :
Linux version 2.1.101 (root@porenn) (gcc version 2.8.1) #15 SMP Sat May 9
18:43:18 EDT 1998
Intel MultiProcessor Specification v1.4
Virtual Wire compatibility mode.
OEM ID: OEM00000 Product ID: PROD00000000 APIC at: 0xFEE00000
Processor #0 Pentium(tm) APIC version 17
Processor #1 Pentium(tm) APIC version 17
I/O APIC #2 Version 17 at 0xFEC00000.
Processors: 2
Console: 16 point font, 400 scans
Console: colour VGA+ 132x25, 1 virtual console (max 63)
Calibrating delay loop... 66.36 BogoMIPS
Memory: 62648k/65536k available (1204k kernel code, 400k reserved, 1244k
data, 40k init)
Swansea University Computer Society NET3.039 for Linux 2.1
NET3: Unix domain sockets 0.16 for Linux NET3.038.
Swansea University Computer Society TCP/IP for NET3.037
IP Protocols: ICMP, UDP, TCP, IGMP
Linux IP multicast router 0.06 plus PIM-SM
Initializing RT netlink socket
Checking 386/387 coupling... Ok, fpu using exception 16 error reporting.
Checking 'hlt' instruction... Ok.
Intel Pentium with F0 0F bug - workaround enabled.
POSIX conformance testing by UNIFIX
CPU0: Intel Pentium 75+ stepping 0c
calibrating APIC timer ...
..... CPU clock speed is 166.1935 MHz.
..... APIC bus clock speed is 66.4773 MHz.
Booting processor 1 eip 2000
Calibrating delay loop... 66.36 BogoMIPS
OK.
CPU1: Intel Pentium 75+ stepping 0c
Total of 2 processors activated (132.71 BogoMIPS).
enabling Symmetric IO mode ... ...done.
ENABLING IO-APIC IRQs
init IO_APIC IRQs
IO-APIC pin 0, 20, 21, 22, 23 not connected.
..MP-BIOS bug: 8254 timer not connected to IO-APIC
..trying to set up timer as ExtINT ... .. (found pin 0) ... works.
nr of MP irq sources: 21.
nr of IO-APIC registers: 24.
testing the IO APIC.......................
.... register #00: 02000000
....... : physical APIC id: 02
.... register #01: 00170011
....... : max redirection entries: 0017
....... : IO APIC version: 0011
.... register #02: 00000000
....... : arbitration: 00
.... IRQ redirection table:
NR Log Phy Mask Trig IRR Pol Stat Dest Deli Vect:
00 0FF 0F 0 0 0 0 0 1 7 51
01 0FF 0F 0 0 0 0 0 1 1 59
02 0FF 0F 0 0 0 0 0 1 1 51
03 0FF 0F 0 0 0 0 0 1 1 69
04 0FF 0F 0 0 0 0 0 1 1 71
05 0FF 0F 0 0 0 0 0 1 1 79
06 0FF 0F 0 0 0 0 0 1 1 81
07 0FF 0F 0 0 0 0 0 1 1 89
08 0FF 0F 0 0 0 0 0 1 1 91
09 0FF 0F 0 0 0 0 0 1 1 99
0a 0FF 0F 0 0 0 0 0 1 1 A1
0b 0FF 0F 0 0 0 0 0 1 1 A9
0c 0FF 0F 0 0 0 0 0 1 1 B1
0d 000 00 1 0 0 0 0 0 0 00
0e 0FF 0F 0 0 0 0 0 1 1 C1
0f 0FF 0F 0 0 0 0 0 1 1 C9
10 0FF 0F 0 1 0 1 0 1 1 D1
11 0FF 0F 0 1 0 1 0 1 1 D9
12 0FF 0F 0 1 0 1 0 1 1 E1
13 0FF 0F 0 1 0 1 0 1 1 E9
14 000 00 1 0 0 0 0 0 0 00
15 000 00 1 0 0 0 0 0 0 00
16 000 00 1 0 0 0 0 0 0 00
17 000 00 1 0 0 0 0 0 0 00
.................................... done.
PCI: PCI BIOS revision 2.10 entry at 0xfb3b0
PCI: Using configuration type 1
PCI: Probing PCI hardware.
PCI->APIC IRQ transform: (B0,I18,P0) -> 18
PCI->APIC IRQ transform: (B0,I19,P0) -> 17
Kernel 2.1.101 works very well for me except for the WD7000 card which
won't work. I had posted the results of my tests to this list, but I am
not sure if it went out since I never got the message at work (the other
place I subscribe to this list), so I am going to re-post a message I sent
to Molnar Ingo about it. He never got back to me on it, so I assume hes
just as stumped. Maybe someone else has an idea. Again this is with
kernel 2.1.101 and since I can't get 2.1.103 to boot, I can't see if its
been fixed since then.
Message about WD7000 card :
At 11:19 AM 5/13/98 , you wrote:
>
>Edmond,
>
>could you try the attached patch against 2.1.101 or pre-2.1.102, does it
>make any difference? (does it boot at all :) Thanks,
>
> Ingo
Ok, here are my results :
Kernel 2.1.102
I looked at your patch and some version of it is in 102 so I assume I am
running it.
Computer :
Tyan Tomcat IIID with 2x166 Mhz CPUs.
3 IDE HDs. 2 x 1.2 Gig and 1 x 4.5 Gig. (IDE0 and IDE1 interfaces @ IRQs
14 and 15)
WD 7000 SCSI Controler with 3 CD ROMs connected. (Controler @ 350, IRQ
12, DMA 6)
Travan-3 Floppy Tape Drive (Controler @ 370, IRQ 5, DMA 3)
2 COM ports @ IRQs 3 and 4 (standard ports for COM1 and COM2)
5 Paralel Ports at various addresses all at IRQ 7 (Actualy not set.) I
use polling.
Sound Blaster Proc @ 220, IRQ 10, DMA 1.
3C595 Network Adapter (Supposedly at IRQ 9 although reported as 18 by Linux)
Here are my interrupts according to Linux :
CPU0 CPU1
0: 62357 92 XT-PIC timer
1: 1045 1443 IO-APIC-level keyboard
2: 0 0 XT-PIC cascade
8: 0 0 IO-APIC-level rtc
10: 0 0 IO-APIC-level soundblaster
12: 30 71 IO-APIC-level wd7000
13: 1 0 XT-PIC fpu
14: 7062 11216 IO-APIC-level ide0
15: 830 425 IO-APIC-level ide1
18: 84 86 IO-APIC-level 3c595 Vortex 100baseTX
NMI: 0
IPI: 0
Incidentaly under Linux 2.1.101 all were edge triggerred except for the
3C595 which was level.
Ok, this is what I found.
[A] When I booted with no modifications to WD7000 or the kernel, the boot
got to the WD7000 card. Looked for it at base 350, IRQ 12, and DMA 6. It
does this by issuing a command to the card then waiting for interrupt 12 to
be triggered and its command serviced. If this doesn't occurr in 2
seconds, it assumes this configuration is wrong and tries the next one.
The next one fails since its at base 320 and it can't find anything there.
It then looks at 350, IRQ 7, and DMA 6. This succeeds. Why? My system
seems to continuously have IRQ 7s being issued. I'm guessing all "bad"
IRQs are being routed to it. Is it the "sink" of IRQs?
One can see the "extra interrupts" by looking at 2 printouts of
/proc/interrupts 1 minute apart :
CPU0 CPU1
0: 27685 172 XT-PIC timer
1: 10 76 IO-APIC-level keyboard
2: 0 0 XT-PIC cascade
7: 10872 10721 IO-APIC-level wd7000
8: 0 0 IO-APIC-level rtc
10: 0 0 IO-APIC-level soundblaster
13: 1 0 XT-PIC fpu
14: 17587 20347 IO-APIC-level ide0
15: 1083 171 IO-APIC-level ide1
18: 84 83 IO-APIC-level 3c595 Vortex 100baseTX
NMI: 0
IPI: 0
1 minute later :
CPU0 CPU1
0: 33590 193 XT-PIC timer
1: 10 76 IO-APIC-level keyboard
2: 0 0 XT-PIC cascade
7: 11586 11424 IO-APIC-level wd7000
8: 0 0 IO-APIC-level rtc
10: 0 0 IO-APIC-level soundblaster
13: 1 0 XT-PIC fpu
14: 22241 25269 IO-APIC-level ide0
15: 1083 171 IO-APIC-level ide1
18: 97 97 IO-APIC-level 3c595 Vortex 100baseTX
NMI: 0
IPI: 0
Almost 700 IRQ 7s have been issued in 1 minute. None were issued by the
WD7000 card. It was idle thoughout this. I am sure more than 700 were
generated, but probably the printk messages it was putting up were slowing
it down some.
[B] So i modified the WD7000 driver and turned on debugging. Sure enough
it was doing exactly what I thought. My log is filled with messages like :
May 15 01:29:09 porenn kernel: 7000_intr_handle: phantom interrupt...
May 15 01:29:09 porenn kernel: wd7000_intr_handle: irq = 7, host = 0xc008ae74
May 15 01:29:09 porenn kernel: wd7000_intr_handle: intr stat = 0xde
May 15 01:29:09 porenn kernel: wd7000_intr_handle: phantom interrupt...
May 15 01:29:09 porenn kernel: wd7000_intr_handle: irq = 7, host = 0xc008ae74
May 15 01:29:09 porenn kernel: wd7000_intr_handle: intr stat = 0xde
[C] So again I modified the WD7000 driver and increased the timeout from 2
seconds to like 2 minutes. The amount of time is irrelevant. IRQ 12 does
not trigger. Now just like before at any time if I press ANY key on the
keyboard, like magic IRQ 12 appears to the WD7000 driver. And as long as I
press the keyboard frequently I can use the SCSI controler. I cat'ed a
file off the CD and I just had to keep hitting the control key to get it to
actualy do the work. One can also see the difference in the number of IRQs
generated when its on its correct interrupt :
12: 30 71 IO-APIC-level wd7000
And this was after 10 minutes of uptime.
When its running in this mode, the debug messages look like :
May 15 01:43:20 porenn kernel: wd7000_detect: started
May 15 01:43:20 porenn kernel: wd7000_detect: pass 1
May 15 01:43:20 porenn kernel: WD-7000 SST BIOS detected at 0xcc000:
checking...
May 15 01:43:20 porenn kernel: wd7000_detect: check IO 0x350 region...
May 15 01:43:20 porenn kernel: wd7000_detect: ASC reset (IO 0x350) ...ok!
May 15 01:43:20 porenn kernel: wd7000_detect: adapter allocated at 0xc008ae74
May 15 01:43:20 porenn kernel: wd7000_detect: Trying init WD-7000 card at
IO 0x350, IRQ 12, DMA 6...
May 15 01:43:20 porenn kernel: wd7000_mail_out: 0xc020feac using OGMB 0x0,
scb is 0xc020feac, awaiting interrupt.
May 15 01:43:20 porenn kernel: wd7000_intr_handle: irq = 12, host = 0xc008ae74
May 15 01:43:20 porenn kernel: wd7000_intr_handle: intr stat = 0xc0
May 15 01:43:20 porenn kernel: wd7000_intr_handle: return from interrupt
handler
May 15 01:43:20 porenn kernel: wd7000_mail_out: 0xc020febe using OGMB 0x1,
scb is 0xc020febe, awaiting interrupt.
May 15 01:43:20 porenn kernel: wd7000_intr_handle: irq = 12, host = 0xc008ae74
May 15 01:43:20 porenn kernel: wd7000_intr_handle: intr stat = 0xc1
May 15 01:43:20 porenn kernel: wd7000_intr_handle: return from interrupt
handler
May 15 01:43:20 porenn kernel: Western Digital WD-7000 (rev 8.0) using IO
0x350, IRQ 12, DMA 6.
May 15 01:43:20 porenn kernel: BUS_ON time: 8000ns, BUS_OFF time: 1875ns
May 15 01:43:20 porenn kernel: wd7000_detect: pass 2
May 15 01:43:20 porenn kernel: WD-7000 SST BIOS not detected...
May 15 01:43:20 porenn kernel: wd7000_detect: check IO 0x320 region...
May 15 01:43:20 porenn kernel: wd7000_detect: ASC reset (IO 0x320) ...ok!
May 15 01:43:20 porenn kernel: wd7000_detect: pass 3
May 15 01:43:20 porenn kernel: WD-7000 SST BIOS not detected...
May 15 01:43:20 porenn kernel: wd7000_detect: check IO 0x350 region...
May 15 01:43:20 porenn kernel: wd7000_detect: IO 0x350 region already
allocated!
May 15 01:43:20 porenn kernel: wd7000_detect: pass 4
May 15 01:43:20 porenn kernel: WD-7000 SST BIOS not detected...
May 15 01:43:20 porenn kernel: scsi0 : Western Digital WD-7000
May 15 01:43:20 porenn kernel: scsi : 1 host.
May 15 01:43:20 porenn kernel: wd7000_mail_out: 0xc0237ddc using OGMB 0x2,
scb is 0xc0237ddc, awaiting interrupt.
May 15 01:43:20 porenn kernel: wd7000_intr_handle: irq = 12, host = 0xc008ae74
May 15 01:43:20 porenn kernel: wd7000_intr_handle: intr stat = 0xc2
May 15 01:43:20 porenn kernel:
May 15 01:43:20 porenn kernel: SCSI command error: SCSI 0x02 host 0x0240
return 0
May 15 01:43:20 porenn kernel: wd7000_mail_out: 0xc0237ddc using OGMB 0x3,
scb is 0xc0237ddc, awaiting interrupt.
May 15 01:43:20 porenn kernel: wd7000_intr_handle: return from interrupt
handler
May 15 01:43:20 porenn kernel: wd7000_intr_handle: irq = 12, host = 0xc008ae74
May 15 01:43:20 porenn kernel: wd7000_intr_handle: intr stat = 0xc3
May 15 01:43:20 porenn kernel: wd7000_intr_handle: return from interrupt
handler
May 15 01:43:20 porenn kernel: wd7000_mail_out: 0xc0237ddc using OGMB 0x4,
scb is 0xc0237ddc, awaiting interrupt.
May 15 01:43:20 porenn kernel: wd7000_intr_handle: irq = 12, host = 0xc008ae74
May 15 01:43:20 porenn kernel: wd7000_intr_handle: intr stat = 0xc4
May 15 01:43:20 porenn kernel: wd7000_intr_handle: return from interrupt
handler
May 15 01:43:20 porenn kernel: Vendor: NEC Model: CD-ROM DRIVE:500
Rev: 2.8
May 15 01:43:20 porenn kernel: Type: CD-ROM
ANSI SCSI revision: 02
May 15 01:43:20 porenn kernel: Detected scsi CD-ROM sr0 at scsi0, channel
0, id 0, lun 0
All in all, I would say nothing has changed from 101 to 102 as far as this
problem is concerned. My guesses of possibilities as to what is going on
are :
[A] Interrupts have been disabled or masked when we go into the wd7000.
This doesn't make much sense though because why would it work when it
thinks its on IRQ 7? Obviously, it can see interrupt 7 why not 12.
[B] IRQ 12 has been routed to some other #. Maybe I should have it look
elsewhere?
I am a complete novice, so these are quite frankly guesses.
Anyway wish to give me any ideas as to what to try next? Any debug code I
could try adding to WD7000 that would capture the state of the
interrupts/tables just prior to where it starts waiting for the interrupt?
Here is the original message I sent you Ingo (Its here just in case you
want to reference it) :
>First, I apologize for writing directly to you. I've been following the
lists closely and have found you to be the most knowledgable person about
IRQs and Intel systems. I've been debugging a problem I've been having
with the WD7000 card and Linux 2.1.101 and it seems to boil down to
interrupts. I also noticed that you stated that your latest IO-APIC fix
affects/fixes something about the keyboard. I am wondering if there is a
connection between that and my WD7000 card. Here is the scenario :
>
>Tyan Tomcat IIID with 2 Pentium 166s. I have a WD 7000 card configured
for IO=0x350, DMA=6, and IRQ=12. This computer works flawlessly under
Linux 2.0.33, while everything EXCEPT the WD7000 driver works under Linux
2.1.101. I wrote the author and he tried it on his machine and ofcourse it
worked. So, I decided to go debugging and found something rather interesting.
>
>Ok. I boot my computer. This is what shows up :
>
>Linux version 2.1.101 (root@porenn) (gcc version 2.8.1) #24 SMP Tue May 12
21:18:50 EDT 1998
>Intel MultiProcessor Specification v1.4
> Virtual Wire compatibility mode.
>OEM ID: OEM00000 Product ID: PROD00000000 APIC at: 0xFEE00000
>Processor #0 Pentium(tm) APIC version 17
>Processor #1 Pentium(tm) APIC version 17
>I/O APIC #2 Version 17 at 0xFEC00000.
>Processors: 2
>wd7000_setup: IRQ=12, DMA=6, I/O=0x350, BUS_ON=8000ns, BUS_OFF=1875ns
>Console: 16 point font, 400 scans
>Console: colour VGA+ 132x25, 1 virtual console (max 63)
>Calibrating delay loop... 66.36 BogoMIPS
>Memory: 62632k/65536k available (1212k kernel code, 400k reserved, 1252k
data, 40k init)
>Swansea University Computer Society NET3.039 for Linux 2.1
>NET3: Unix domain sockets 0.16 for Linux NET3.038.
>Swansea University Computer Society TCP/IP for NET3.037
>IP Protocols: ICMP, UDP, TCP, IGMP
>Linux IP multicast router 0.06 plus PIM-SM
>Initializing RT netlink socket
>Checking 386/387 coupling... Ok, fpu using exception 16 error reporting.
>Checking 'hlt' instruction... Ok.
>Intel Pentium with F0 0F bug - workaround enabled.
>POSIX conformance testing by UNIFIX
>CPU0: Intel Pentium 75+ stepping 0c
>calibrating APIC timer ...
>..... CPU clock speed is 166.1938 MHz.
>..... APIC bus clock speed is 66.4774 MHz.
>Booting processor 1 eip 2000
>Calibrating delay loop... 66.36 BogoMIPS
>OK.
>CPU1: Intel Pentium 75+ stepping 0c
>Total of 2 processors activated (132.71 BogoMIPS).
>enabling Symmetric IO mode ... ...done.
>ENABLING IO-APIC IRQs
>init IO_APIC IRQs
>IO-APIC pin 0, 20, 21, 22, 23 not connected.
>..MP-BIOS bug: 8254 timer not connected to IO-APIC
>..trying to set up timer as ExtINT ... .. (found pin 0) ... works.
>nr of MP irq sources: 21.
>nr of IO-APIC registers: 24.
>testing the IO APIC.......................
>.... register #00: 02000000
>....... : physical APIC id: 02
>.... register #01: 00170011
>....... : max redirection entries: 0017
>....... : IO APIC version: 0011
>.... register #02: 00000000
>....... : arbitration: 00
>.... IRQ redirection table:
>NR Log Phy Mask Trig IRR Pol Stat Dest Deli Vect:
>00 0FF 0F 0 0 0 0 0 1 7 51
>01 0FF 0F 0 0 0 0 0 1 1 59
>02 0FF 0F 0 0 0 0 0 1 1 51
>
>03 0FF 0F 0 0 0 0 0 1 1 69
>04 0FF 0F 0 0 0 0 0 1 1 71
>05 0FF 0F 0 0 0 0 0 1 1 79
>06 0FF 0F 0 0 0 0 0 1 1 81
>07 0FF 0F 0 0 0 0 0 1 1 89
>08 0FF 0F 0 0 0 0 0 1 1 91
>09 0FF 0F 0 0 0 0 0 1 1 99
>0a 0FF 0F 0 0 0 0 0 1 1 A1
>0b 0FF 0F 0 0 0 0 0 1 1 A9
>0c 0FF 0F 0 0 0 0 0 1 1 B1
>0d 000 00 1 0 0 0 0 0 0 00
>0e 0FF 0F 0 0 0 0 0 1 1 C1
>0f 0FF 0F 0 0 0 0 0 1 1 C9
>10 0FF 0F 0 1 0 1 0 1 1 D1
>11 0FF 0F 0 1 0 1 0 1 1 D9
>12 0FF 0F 0 1 0 1 0 1 1 E1
>13 0FF 0F 0 1 0 1 0 1 1 E9
>14 000 00 1 0 0 0 0 0 0 00
>15 000 00 1 0 0 0 0 0 0 00
>16 000 00 1 0 0 0 0 0 0 00
>17 000 00 1 0 0 0 0 0 0 00
>.................................... done.
>PCI: PCI BIOS revision 2.10 entry at 0xfb3b0
>PCI: Using configuration type 1
>PCI: Probing PCI hardware.
>PCI->APIC IRQ transform: (B0,I18,P0) -> 18
>PCI->APIC IRQ transform: (B0,I19,P0) -> 17
>Starting kswapd v 1.5
>parport0: PC-style at 0x3bc [SPP,PS2]
>parport1: PC-style at 0x378 [SPP,PS2]
>parport2: PC-style at 0x278 [SPP,PS2]
>parport3: PC-style at 0x268 [SPP]
>parport4: PC-style at 0x27c [SPP,PS2]
>Serial driver version 4.25 with MANY_PORTS MULTIPORT SHARE_IRQ enabled
>ttyS00 at 0x03f8 (irq = 4) is a 16550A
>ttyS01 at 0x02f8 (irq = 3) is a 16550A
>ttyS02 at 0x03e8 (irq = 4) is a 16550A
>lp0: using parport0 (polling).
>lp1: using parport1 (polling).
>lp2: using parport2 (polling).
>lp3: using parport3 (polling).
>lp4: using parport4 (polling).
>Real Time Clock Driver v1.09
>Sound initialization started
><Sound Blaster Pro (8 BIT ONLY) (3.1)> at 0x220 irq 10 dma 1,1
>SB DSP version is just 3.1 which means that your card is
>several years old (8 bit only device) or alternatively the sound driver
>is incorrectly configured.
><Yamaha OPL3 FM> at 0x388
>Sound initialization complete
>PIIX3: IDE controller on PCI bus 00 dev 39
>PIIX3: not 100% native mode: will probe irqs later
> ide0: BM-DMA at 0xf000-0xf007, BIOS settings: hda:pio, hdb:pio
> ide1: BM-DMA at 0xf008-0xf00f, BIOS settings: hdc:pio, hdd:pio
>hda: WDC AC31200F, ATA DISK drive
>hdb: WDC AC31200F, ATA DISK drive
>hdc: WDC AC35100L, ATA DISK drive
>ide2: ports already in use, skipping probe
>ide0 at 0x1f0-0x1f7,0x3f6 on irq 14
>ide1 at 0x170-0x177,0x376 on irq 15
>hda: WDC AC31200F, 1222MB w/64kB Cache, CHS=621/64/63
>hdb: WDC AC31200F, 1222MB w/64kB Cache, CHS=621/64/63
>hdc: WDC AC35100L, 4924MB w/256kB Cache, CHS=10672/15/63, DMA
>Floppy drive(s): fd0 is 1.44M
>FDC 0 is a post-1991 82077
>md driver 0.36.6 MAX_MD_DEV=4, MAX_REAL=8
>
>This looks OK. Ofcourse I don't know enough about APIC to know if it
realy is, but since everything except the WD7000 driver works, I'm
assuming. OK, here comes the interesting stuff :
>
>wd7000_detect: started
>wd7000_detect: pass 1
>
>WD-7000 SST BIOS detected at 0xcc000: checking...
>wd7000_detect: check IO 0x350 region...
>wd7000_detect: ASC reset (IO 0x350) ...ok!
>wd7000_detect: adapter allocated at 0xc0081e74
>wd7000_detect: Trying init WD-7000 card at IO 0x350, IRQ 12, DMA 6...
>wd7000_mail_out: 0xc025681c using OGMB 0x0, scb is 0xc025681c, awaiting
interrupt.
>wd7000_diagnostics: timed out.
>
>What is supposed to be happening here is that the WD7000 card has
requested and recieved the IO, IRQ and DMA resources. In the
>wd7000_mail_out: 0xc025681c using OGMB 0x0, scb is 0xc025681c, awaiting
interrupt.
>The driver is trying to test the card. It writes a request out to the
card and waits. If everything is going well, it expects an interrupt on
IRQ12. This would ofcourse be the data coming back from the card. As you
can see by the last line, the IRQ never occurrs. The driver assumes the
card is busted and continues scanning for other cards :
>
>wd7000_detect: pass 2
>WD-7000 SST BIOS detected at 0xcc000: checking...
>wd7000_detect: check IO 0x320 region...
>wd7000_detect: ASC reset (IO 0x320) ...ok!
>wd7000_detect: pass 3
>WD-7000 SST BIOS detected at 0xcc000: checking...
>wd7000_detect: check IO 0x350 region...
>wd7000_detect: ASC reset (IO 0x350) ...ok!
>wd7000_detect: adapter allocated at 0xc0081e74
>wd7000_detect: Trying init WD-7000 card at IO 0x350, IRQ 7, DMA 6...
>wd7000_mail_out: 0xc025681c using OGMB 0x0, scb is 0xc025681c, awaiting
interrupt.
>wd7000_intr_handle: return from interrupt handler
>wd7000_mail_out: 0xc025682e using OGMB 0x1, scb is 0xc025682e, awaiting
interrupt.
>wd7000_intr_handle: return from interrupt handler
>Western Digital WD-7000 (rev 8.0) using IO 0x350, IRQ 7, DMA 6.
> BUS_ON time: 8000ns, BUS_OFF time: 1875ns
>wd7000_detect: pass 4
>WD-7000 SST BIOS not detected...
>scsi0 : Western Digital WD-7000
>scsi : 1 host.
>
>It looks at IO 320 and then IO 350. Whats interesting here is the fact
that it thinks its found a card at IRQ 7. This happens because the card is
indeed at 350 and DMA 6 and when it waits for an interrupt it gets one. It
doesn't know that the WD7000 card never generated it, so it assumes
everything is fine and that its found the card. Ofcourse its wrong. My
system just seems to have frequent IRQ7 triggers eventhough I have no
hardware on IRQ7 (That I know of. One of the paralel ports may be there).
Junk interrupts perhaps?
>
>Anyway this is not the interesting part. I reboot my computer and let it
go to the following point again :
>
>wd7000_detect: started
>wd7000_detect: pass 1
>WD-7000 SST BIOS detected at 0xcc000: checking...
>wd7000_detect: check IO 0x350 region...
>wd7000_detect: ASC reset (IO 0x350) ...ok!
>wd7000_detect: adapter allocated at 0xc0081e74
>wd7000_detect: Trying init WD-7000 card at IO 0x350, IRQ 12, DMA 6...
>wd7000_mail_out: 0xc025681c using OGMB 0x0, scb is 0xc025681c, awaiting
interrupt.
>
>Now normal this times out in 2 seconds, but I upped it to 20 so that I
could watch it. If I do nothing at this point what I described above
happens (times out, goes looking for other cards and finds the false on on
IRQ 7). However, if I hit ANY key on my keyboard, I get :
>
>
>wd7000_intr_handle: return from interrupt handler
>wd7000_mail_out: 0xc02568de using OGMB 0x1, scb is 0xc02568de, awaiting
interrupt.
>wd7000_intr_handle: return from interrupt handler
>
>and so on. Since it finds the one at 350, IRQ 12. It doesn't falsely
detect one at IRQ 7. Everytime it waits for an interrupt, I just have to
press any key on my keyboard.
>
>scsi0 : Western Digital WD-7000
>scsi : 1 host.
>
>However, the interrupt thing isn't over. Everytime it waits for an
interrupt, I have to type something to generate a keyboard interrupt. If I
do that, it continues and works perfectly. It foes on to detect my SCSI CD
ROMs and then boot the rest of the system. I can access the ROMs and the
files on them. Ofcourse I just need to keep typing since the only time it
sees the WD7000's IRQ is when the keyboard triggers. Therefore it occurrs
at boot, during a normal run and even at shutdown. When I shutdown,
everyhting seems to hang until I press a key and voila it finishes shutdown.
>
>I am a programmer, but I've never worked on the kernel before and never on
such low level stuff. I have no diea what to look for from here. I would
welcome any suggestions.
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@vger.rutgers.edu