On 11/27/06, Stefan Richter <[EMAIL PROTECTED]> wrote:
But perhaps more importantly, how are the IRQs distributed?
# cat /proc/interrupts
This is almost right after boot. I generated about 40 bus resets just
to stir things up a little:
CPU0 CPU1 CPU2 CPU3
0: 33660 36393 30037 69980 IO-APIC-edge timer
1: 0 0 1 10 IO-APIC-edge i8042
8: 0 0 0 0 IO-APIC-edge rtc
9: 0 0 0 0 IO-APIC-level acpi
12: 0 0 0 113 IO-APIC-edge i8042
15: 0 270 686 215 IO-APIC-edge ide1
50: 1 0 11567 7 IO-APIC-level aic79xx
58: 0 0 0 0 IO-APIC-level ehci_hcd:usb1
66: 0 0 0 0 IO-APIC-level ohci_hcd:usb2
74: 0 1 7 80 IO-APIC-level
ohci1394, ohci1394
82: 7 23 30 28 IO-APIC-level ohci1394
90: 2 28 17 71 IO-APIC-level eth0
98: 9 27 21 9182 IO-APIC-level eth1
106: 19 17 20 26 IO-APIC-level ohci1394
114: 16 26 34 12 IO-APIC-level ohci1394
233: 0 0 15 0 IO-APIC-level aic79xx
NMI: 410 78 75 77
LOC: 166733 166657 166542 166432
ERR: 0
MIS: 0
Also:
I couldn't cause the problem when using 4 Fireboard 800s through
several hundred bus resets (usually took <= 40 for the Indigita card)
Please add
reg_read(ohci, OHCI1394_IntMaskSet);
right before hpsb_selfid_complete(host, phyid, isroot);. This will flush
the previous reg_write before hpsb_selfid_complete starts doing
unspeakable things.
Okay, so the code looks like this now:
DBGMSG("PhyReqFilter=%08x%08x",
reg_read(ohci,OHCI1394_PhyReqFilterHiSet),
reg_read(ohci,OHCI1394_PhyReqFilterLoSet));
reg_read(ohci, OHCI1394_IntMaskSet);
hpsb_selfid_complete(host, phyid, isroot);
DBGMSG( "IntEventClear %08x "
"IntEventSet %08x "
"IntMaskSet %08x",
reg_read(ohci, OHCI1394_IntEventClear),
reg_read(ohci, OHCI1394_IntEventSet),
reg_read(ohci, OHCI1394_IntMaskSet));
this is in 2.6.16-rt29 which has proved to be the easiest to provoke.
I actually couldn't get 2.6.18 to break earlier this morning (few
hundred resets).
Okay, I've lost host1 (on the Indigita), but this time the last print
statement is:
Nov 27 10:38:27 spanky kernel: ohci1394: fw-host1: IntEventClear
00000000 IntEventSet 04588000 IntMaskSet 818300f3
just like all the other hosts. I can confirm that no bus reset
handlers are called, and there are another 4,000 lines of statements
from the other hosts after the last from host1.
--
Robert Crocombe
[EMAIL PROTECTED]
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
