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]
Date:	Sat, 2 Jun 2007 16:53:19 -0700 (PDT)
From:	Tear <tarrqt@...oo.com>
To:	Linus Torvalds <torvalds@...ux-foundation.org>
Cc:	mingo@...hat.com, akpm@...ux-foundation.org,
	Linux Kernel Mailing List <linux-kernel@...r.kernel.org>,
	"Brown, Len" <len.brown@...el.com>
Subject: Re: [RFC][PATCH] IO-APIC blacklist

Linus Torvalds <torvalds@...ux-foundation.org> wrote:
> On Sat, 2 Jun 2007, Tear wrote:
> > 
> > I have tested my system with different kernel command lines
> > and have ruled out all of the four possibilities. Here's a
> > matrix which summarizes the situtation. My USB-enabled
> > digital camera's data transfer rate is as follows:
> 
> That's not the interesting part.
> 
> There's no way the IO-APIC itself "cant' work". That's a normal Intel 
> IO-APIC, it's fine. There's somethign else that causes things to not work, 
> properly, and the question is why.
> 
> So the APIC choice triggers some other bug that then ACPI fixes up.
> 
> From the dmesg between "acpi=ht" and "acpi-force", the prime candidates 
> would seem to be:
> 
>    ENABLING IO-APIC IRQs
>   -...TIMER: vector=0x31 apic1=0 pin1=2 apic2=0 pin2=0	 # slow
>   +...TIMER: vector=0x31 apic1=0 pin1=2 apic2=-1 pin2=-1 # fine
> 
> and
> 
>   -uhci_hcd 0000:00:1f.2: irq 19, io base 0x0000ff80	 # slow
>   +uhci_hcd 0000:00:1f.2: irq 17, io base 0x0000ff80	 # fine
> 
> (Interestingly, your *other* USB controller at 0:1f.4 gets assigned irq 18 
> in both cases).
> 
> 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). 

No, the camera is fast when I use acpi=force and pci=routeirq.
It does not matter which USB port I use. I am attaching
the dmesg output with acpi=force and pci=routeirq appended to
the kernel command line.

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

>From this we learn that the problematic ports are on the front
panel whereas the "always-working" ports are on the rear panel.
The problematic ports work when acpi=force is appended to the
kernel command line.

> Finally, I wonder why that particular box is marked with an "acpi=ht" 
> blacklisting in the first place. Rather than add a new blacklist, it might 
> be better to remove an old (and perhaps incorrect) one.
> 
> That blacklist entry is _ancient_. It's entirely possible that it's just 
> bogus: we've had so many ACPI fixes since it was added, that it's quite 
> possible that the blacklist entry itself is bogus, and is the result of 
> some old ACPI bug that triggered on that entry.
> 
> The Dell GX240 entry was added by commit 68e4ad79294 in the historic Linux 
> archive:
> 
>     Author: Len Brown <len.brown@...el.com>
>     Date:   Sat Aug 9 15:00:59 2003 -0400
> 
>     ACPI from 2.4:
>     build: add ACPI_HT, delete ACPI_HT_ONLY
>     boot: add acpi={force, off, ht}; delete "noht", "acpismp="
>     add DMI blacklist from UnitedLinux
> 
> and since it sounds like the machine _works_ with ACPI on, my real 
> preference would be to just remove the black-list entry.

I would prefer to patch the kernel to prevent IO-APIC when
ACPI is not enabled by using the "acpi_disabled" variable.
But since you are the kernel developer among you and I,
I guess you should have the right choose what the best
option is.

> In fact, I thought that patch already existed in the -mm tree?

Yes, I had made an attempt to get it out of the blacklist a
couple of weeks ago. The patch is in the -mm tree. Could we
please get that patch into the main tree?

> Len - do you have any archives back from 2003 and earlier to indicate why 
> the Dell GX240 was blacklisted?
> 
> In fact, googling for this shows some other users saying that removing the 
> blacklist entry fixes things:
> 
> 	http://forums.fedoraforum.org/showthread.php?t=107291
> 
> and there is another report ("Lil_miss_linux") claiming that moving a USB 
> cardreader from one USB plug to another just "fixed" the issue they had. 
> So I'm doubly interested to hear whether maybe the camera works fine in 
> another USB port (which I'd guess is the one presumably connected to 
> irq18).

As I said above, with acpi=ht, the camera works
fine when connected to the USB port on the back
side of the computer. (Not the ports on the front
side.)

Thank you for spending time on this problem.
I really appreciate your efforts.

Regards,
- Tear




 
____________________________________________________________________________________
Expecting? Get great news right away with email Auto-Check. 
Try the Yahoo! Mail Beta.
http://advision.webevents.yahoo.com/mailbeta/newmail_tools.html 
View attachment "dmesg-acpi=force-pci=routeirq.txt" of type "text/plain" (15454 bytes)