linux-kernel - Re: question on odd APIC behavior

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]

Date:	Thu, 15 Nov 2007 16:44:06 +0000 (GMT)
From:	"Maciej W. Rozycki" <macro@...ux-mips.org>
To:	Oliver Neukum <oliver@...kum.org>
cc:	linux-kernel@...r.kernel.org
Subject: Re: question on odd APIC behavior

On Thu, 15 Nov 2007, Oliver Neukum wrote:

> >  Certainly.  One possibility is to have multiple processors marked as the 
> > destination, e.g. a logical delivery mode destination programmed with 
> > multiple bits set.
> 
> What would be the consequences?

 It depends on the exact setup and conditions.

> I am seeing an interrupt for an UHCI on #20 CPU1 also arriving on
> #19 CPU0, triggering the spurious interrupt detection.

 Well, if you see spurious interrupt detection triggered, then it is not a 
problem with the interrupt being delivered multiple times (that's handled 
silently by the interrupt dispatched), but likely the interrupt line being 
deasserted too late.  Does it happen frequently?  If your ERR counter in 
/proc/interrupts increments quite fast, then perhaps a driver does not 
handle interrupts well enough for your system.  Or there is noise on an 
interrupt line.

 You would have to provide more information to get more accurate feedback.

  Maciej
-
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/