Re: ieee1394: host adapter disappears on 1394 bus reset

[Robert Crocombe]

On 11/27/06, Stefan Richter <stefanr@xxxxxxxxxxxxxxxxx> 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
rcrocomb@xxxxxxxxx
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/