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: <58017.73709.qm@web63607.mail.re1.yahoo.com>
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

Powered by Openwall GNU/*/Linux Powered by OpenVZ