linux-kernel - Re: ieee1394: host adapter disappears on 1394 bus reset

lists.openwall.net		lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC
Open Source and information security mailing list archives

Hash Suite for Android: free password hash cracker in your pocket

[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]

Message-ID: <e6babb600611270946o738327feqd7a18f2f1ff8fccd@mail.gmail.com>
Date:	Mon, 27 Nov 2006 10:46:15 -0700
From:	"Robert Crocombe" <rcrocomb@...il.com>
To:	"Stefan Richter" <stefanr@...6.in-berlin.de>
Cc:	linux-kernel <linux-kernel@...r.kernel.org>,
	linux1394-devel <linux1394-devel@...ts.sourceforge.net>
Subject: Re: ieee1394: host adapter disappears on 1394 bus reset

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