linux-kernel - Re: nobody cared about IRQ 19 (firewire, on a HP 2510p notebook)

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: Windows password security audit tool. GUI, reports in PDF.

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

Message-ID: <alpine.LFD.1.10.0803302201110.3219@apollo.tec.linutronix.de>
Date:	Sun, 30 Mar 2008 22:10:00 +0200 (CEST)
From:	Thomas Gleixner <tglx@...utronix.de>
To:	Stefan Richter <stefanr@...6.in-berlin.de>
cc:	Martin Michlmayr <tbm@...ius.com>,
	linux1394-devel@...ts.sourceforge.net,
	linux-kernel@...r.kernel.org, Ingo Molnar <mingo@...hat.com>,
	"H. Peter Anvin" <hpa@...or.com>
Subject: Re: nobody cared about IRQ 19 (firewire, on a HP 2510p notebook)

On Sun, 30 Mar 2008, Stefan Richter wrote:
> I tend to believe it is a problem to be addressed in the x86 platform support,
> not a driver problem.

Depends. It might be unfixable.

> I Cc'd some random x86 folk...  To rehash the issue:
> 
>   - Controller: Ricoh Co Ltd R5C832 IEEE 1394 Controller (rev 04)
>     Board: PM965/GM965/GL960 based
>     The R5C832 is known to work with ohci1394 according to
>     http://hardware4linux.info/component/14348/ and other reports.
> 
>   - Martin also saw it happen with Linux 2.6.22.
> 
>   - firewire-ohci + firewire-core as well as ohci1394 + ieee1394
>     appear to initialize the controller on Martin's laptop just fine.
>     Among else this means that a number of register reads and writes
>     succeed.
> 
>   - Some time later, without having actually used the FireWire
>     controller, "irq 19: nobody cared"/ "Disabling IRQ #19" occurs.
>     AFAIU the code, this is apparently because firewire-ohci's or
>     ohci1394's IRQ handler was called repeatedly but got either 0 or ~0
>     when reading the chip's interrupt event register.

Can we please have a full boot log (dmesg) and the output of /proc/interrupts and "lspci -vvv"

Thanks,
	tglx
--
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/