linux-kernel - Re: [RFC][PATCH] IO-APIC blacklist

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: <200706030016.54555.lenb@kernel.org>
Date:	Sun, 3 Jun 2007 00:16:54 -0400
From:	Len Brown <lenb@...nel.org>
To:	Tear <tarrqt@...oo.com>
Cc:	Linus Torvalds <torvalds@...ux-foundation.org>, mingo@...hat.com,
	akpm@...ux-foundation.org,
	Linux Kernel Mailing List <linux-kernel@...r.kernel.org>
Subject: Re: [RFC][PATCH] IO-APIC blacklist

On Saturday 02 June 2007 19:53, Tear wrote:
> Linus Torvalds <torvalds@...ux-foundation.org> wrote:
> > On Sat, 2 Jun 2007, Tear wrote:

> > Now, I doubt it's the timer, and the UHCI irq thing sounds more likely to 
> > be a problem anyway, since it's USB that's slow, so it would be 
> > interesting to hear whether:
> > 
> > 	acpi=force pci=routeirq
> > 
> > is still slow (it should enable ACPI, but then force the interrupt routing 
> > to use the PIRQ table anyway). 

I think you meant to suggest acpi=force plus "acpi=noirq", which will
cause all of ACPI except its interrupt routing code to run.
(similarly, "pci=noacpi" causes all of ACPI to run except its
 interrupt code and PCI bus enumeration code)

pci=routeirq actually just goes and forces the interrupt routing
for all PCI devices to be set up before driver probe time
when it is normally done.  This is a workaround for PCI drivers
that don't call pci_enable_device() to enable their IRQ.

In any case, it is possible that the assumption that IRQs
are broken on this box may be invalid.  In the case of
the PCI interrupts above 15 on this box -- they are
all "hard coded" in the _PRT -- there is no run-time
interrupt link to program, Linux will always use the
same IRQ for each device and it has no choice in the matter
in ACPI mode.  So the same is likely true in legacy mode.

> > Also, if you can figure out which USB ports are on the _other_ controller 
> > (the one that gets irq 18 regardless of whether ACPI is on or off), it 
> > would also be interesting to hear whether the camera is always fast (or 
> > perhaps always slow) when connected to a part that is off that 
> > controller..
> 
> Originally I have been using the USB ports on the front panel of
> the computer. I had not tested the USB ports on the rear panel
> of the computer. I have just tested the USB ports on the rear
> panel of the computer with acpi=ht, and surprise, the camera is fast!

When we talk about "fast" and "slow" here, what are we talking about?
What are the relative speeds?
I see uhci only in dmesg, I guess there is no ehci on this box?

Also, can you associate the physical ports on back and front
with the software drivers loaded by performing an operation
on the port and observing which line in /proc/interrupts increments?

do all of the USB interfaces tested have their own unshared
IRQ in /proc/interrupts?

thanks,
-Len

ps. there could still be some "ACPI magic" going on here.
We've seen motherboards that enable parts of USB based
on what OS they think they are running.  Try
acpi=force acpi_os_name=Linux acpi_osi=
and if that makes USB go slow, that is proof
of where the magic lives.

Also, please capture the output from acpidump
and attach it to a bug report here:
http://bugzilla.kernel.org/enter_bug.cgi?product=ACPI
If you don't have acpidump installed, you can get it
from pmtools here:
http://ftp.kernel.org/pub/linux/kernel/people/lenb/acpi/utils/

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