| 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
| ||
|
Date: Sun, 3 Jun 2007 03:24:12 -0700 (PDT)
From: Tear <tarrqt@...oo.com>
To: Len Brown <lenb@...nel.org>
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
Len Brown <lenb@...nel.org> wrote:
> 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)
acpi=force plus acpi=noirq changes the situation a little bit.
With acpi=force and acpi=noirq, the ports on the front panel
work at a "medium" speed, neither fast nor slow.
> 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?
Yes, this is a relatively old system;
it has only uhci and no ehci. Please
see the following outputs for the speed
of the USB transfers. Before each mount,
I flushed the caches with "blockdev --flushbufs".
~~~~~ Slow: (acpi=ht, USB port on the *front* panel) ~~~~~
# time mount /dev/sda1 /media/usbdisk/
real 0m18.343s
user 0m0.000s
sys 0m0.008s
# time dd if=dsc00673.jpg of=/dev/null
4295+1 records in
4295+1 records out
2199226 bytes (2,2 MB) copied, 16.7524 seconds, 131 kB/s
real 0m16.757s
user 0m0.000s
sys 0m0.004s
~~~~~ Fast: (acpi=ht, USB port on the *rear* panel) ~~~~~
# time mount /dev/sda1 /media/usbdisk/
real 0m0.259s
user 0m0.004s
sys 0m0.012s
# time dd if=dsc00673.jpg of=/dev/null
4295+1 records in
4295+1 records out
2199226 bytes (2,2 MB) copied, 2.60062 seconds, 846 kB/s
real 0m2.606s
user 0m0.000s
sys 0m0.020s
~~~~~ Fast: (acpi=force, USB port on the *front* panel) ~~~~~
# time mount /dev/sda1 /media/usbdisk/
real 0m0.287s
user 0m0.000s
sys 0m0.008s
# time dd if=dsc00673.jpg of=/dev/null
4295+1 records in
4295+1 records out
2199226 bytes (2,2 MB) copied, 2.60754 seconds, 843 kB/s
real 0m2.612s
user 0m0.000s
sys 0m0.012s
> 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?
Sure. With acpi=ht, /proc/interrupts is as follows:
CPU0
0: 201306 IO-APIC-edge timer
1: 1457 IO-APIC-edge i8042
2: 0 XT-PIC-XT cascade
6: 5 IO-APIC-edge floppy
7: 0 IO-APIC-edge parport0
8: 1 IO-APIC-edge rtc
12: 19218 IO-APIC-edge i8042
14: 18704 IO-APIC-edge ide0
15: 6973 IO-APIC-edge ide1
16: 56862 IO-APIC-fasteoi r128@pci:0000:01:00.0
17: 20792 IO-APIC-fasteoi Intel 82801BA-ICH2
18: 74 IO-APIC-fasteoi uhci_hcd:usb2, eth0
19: 38 IO-APIC-fasteoi uhci_hcd:usb1
NMI: 0
LOC: 201260
ERR: 0
MIS: 0
With acpi=force, /proc/interrupts is as follows:
CPU0
0: 71 IO-APIC-edge timer
1: 5772 IO-APIC-edge i8042
6: 5 IO-APIC-edge floppy
7: 0 IO-APIC-edge parport0
8: 1 IO-APIC-edge rtc
9: 1 IO-APIC-fasteoi acpi
12: 24882 IO-APIC-edge i8042
14: 15278 IO-APIC-edge ide0
15: 10141 IO-APIC-edge ide1
16: 1961 IO-APIC-fasteoi uhci_hcd:usb1
17: 1333 IO-APIC-fasteoi uhci_hcd:usb2
18: 609 IO-APIC-fasteoi eth0
19: 0 IO-APIC-fasteoi Intel 82801BA-ICH2
20: 83137 IO-APIC-fasteoi r128@pci:0000:01:00.0
NMI: 0
LOC: 312469
ERR: 0
MIS: 0
With acpi=force, the following is observed:
Ports on the front panel increment the following line:
17: 1763 IO-APIC-fasteoi uhci_hcd:usb2
Whereas the ports on the rear panel increment the following line:
16: 2477 IO-APIC-fasteoi uhci_hcd:usb1
> do all of the USB interfaces tested have their own unshared
> IRQ in /proc/interrupts?
With acpi=ht, no. However, with acpi=force, yes.
> 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.
acpi=force acpi_os_name=Linux acpi_osi= does not differ
from only acpi=force. Both of the USB controllers
are fast.
> 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/
I do not know what I should write in the bug report.
For this reason, I am attaching the output of acpidump.
Thank you for your attention.
Regards,
- Tear
____________________________________________________________________________________
Never miss an email again!
Yahoo! Toolbar alerts you the instant new Mail arrives.
http://tools.search.yahoo.com/toolbar/features/mail/
View attachment "acpidump.txt" of type "text/plain" (45063 bytes)
Powered by blists - more mailing lists