Re: [RFC][PATCH] IO-APIC blacklist
Len Brown <[EMAIL PROTECTED]> wrote: > [snip] > > Also, please capture the output from acpidump > and attach it to a bug report here: > http://bugzilla.kernel.org/enter_bug.cgi?product=ACPI > > [snip] Hi, I have created a bug report in bugzilla.kernel.org. Here's the URL: http://bugzilla.kernel.org/show_bug.cgi?id=8572 I have attached the output of acpidump to the bug report. Let's continue our discussion there. Thanks, - Tear Yahoo! oneSearch: Finally, mobile search that gives answers, not web links. http://mobile.yahoo.com/mobileweb/onesearch?refer=1ONXIC - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [RFC][PATCH] IO-APIC blacklist
Len Brown <[EMAIL PROTECTED]> wrote: > On Saturday 02 June 2007 19:53, Tear wrote: > > Linus Torvalds <[EMAIL PROTECTED]> 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/ real0m18.343s user0m0.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 real0m16.757s user0m0.000s sys 0m0.004s ~ Fast: (acpi=ht, USB port on the *rear* panel) ~ # time mount /dev/sda1 /media/usbdisk/ real0m0.259s user0m0.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 real0m2.606s user0m0.000s sys 0m0.020s ~ Fast: (acpi=force, USB port on the *front* panel) ~ # time mount /dev/sda1 /media/usbdisk/ real0m0.287s user0m0.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 real0m2.612s user0m0.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: 0XT-PIC-XTcascade 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 [EMAIL PROTECTED]::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
Re: [RFC][PATCH] IO-APIC blacklist
Len Brown [EMAIL PROTECTED] wrote: On Saturday 02 June 2007 19:53, Tear wrote: Linus Torvalds [EMAIL PROTECTED] 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/ real0m18.343s user0m0.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 real0m16.757s user0m0.000s sys 0m0.004s ~ Fast: (acpi=ht, USB port on the *rear* panel) ~ # time mount /dev/sda1 /media/usbdisk/ real0m0.259s user0m0.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 real0m2.606s user0m0.000s sys 0m0.020s ~ Fast: (acpi=force, USB port on the *front* panel) ~ # time mount /dev/sda1 /media/usbdisk/ real0m0.287s user0m0.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 real0m2.612s user0m0.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: 0XT-PIC-XTcascade 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 [EMAIL PROTECTED]::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
Re: [RFC][PATCH] IO-APIC blacklist
Len Brown [EMAIL PROTECTED] wrote: [snip] Also, please capture the output from acpidump and attach it to a bug report here: http://bugzilla.kernel.org/enter_bug.cgi?product=ACPI [snip] Hi, I have created a bug report in bugzilla.kernel.org. Here's the URL: http://bugzilla.kernel.org/show_bug.cgi?id=8572 I have attached the output of acpidump to the bug report. Let's continue our discussion there. Thanks, - Tear Yahoo! oneSearch: Finally, mobile search that gives answers, not web links. http://mobile.yahoo.com/mobileweb/onesearch?refer=1ONXIC - To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [RFC][PATCH] IO-APIC blacklist
On Saturday 02 June 2007 19:53, Tear wrote: > Linus Torvalds <[EMAIL PROTECTED]> 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 [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [RFC][PATCH] IO-APIC blacklist
Linus Torvalds <[EMAIL PROTECTED]> 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 :00:1f.2: irq 19, io base 0xff80 # slow
> +uhci_hcd :00:1f.2: irq 17, io base 0xff80 # 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 <[EMAIL PROTECTED]>
> 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 Linux
Re: [RFC][PATCH] IO-APIC blacklist
Linus Torvalds wrote:
> On Sat, 2 Jun 2007, Tear wrote:
> > >
> > > Wouldn't this also disable the IOAPIC in the (working) ACPI+IOAPIC case?
> >
> > Yes, it would. However, I wanted to make my addition
> > to the kernel generic so that other people with
> > problematic IO-APIC implementations can blacklist
> > their systems without checking whether ACPI is enabled
> > or not.
>
> But that's just wrong. First off, all distro kernels come with ACPI on, so
> the thing you're fixing is really just for somebody who compiles his own
> kernel in a particular (and unusual/strange) configuration, and you're
> making it _worse_ for everybody else.
Mr. Torvalds,
The patch scans the DMI for "Dell OptiPlex GX240"
and disables IO-APIC only if such a system is detected.
It does not disable IO-APIC for other people.
In addition, Dell OptiPlex GX240 is (at least currently)
in the ACPI blacklist. So with a regular distro, one
gets IO-APIC and acpi=ht which causes USB transfers
to be very slow.
I have made an attempt to get Dell OptiPlex GX240
out of the ACPI blacklist. Please see:
http://marc.info/?t=11789788191=1=2
Nevertheless, I am willing to modify the patch
to make IO-APIC work when ACPI is enabled. A
quick search pointed me to the variable named
"acpi_disabled". I can use this variable to
detect whether ACPI is enabled and disable
IO-APIC if it is not. Please see the
attached patch for such an implementation.
> And you're blacklisting it without even understaning _what_ is wrong. I
> really think we should figure that part out first,
I willing to put effort into figuring out what
is wrong. Please let me know if there is anything
I can do to further our information about this
problem. As I said before, I would be glad to
send to you the diff between any of the four
cases I mentioned in my previous e-mail to you.
Were you able to take a look at the dmesg
outputs in my previous e-mail?
Thank you for your attention.
Regards,
- Tear
Choose the right car based on your needs. Check out Yahoo! Autos new Car
Finder tool.
http://autos.yahoo.com/carfinder/--- linux-2.6.21.3.orig/arch/i386/kernel/io_apic.c 2007-06-02 14:17:10.0 +
+++ linux-2.6.21.3/arch/i386/kernel/io_apic.c 2007-06-02 22:24:44.0 +
@@ -35,6 +35,7 @@
#include
#include
#include
+#include
#include
#include
@@ -44,6 +45,7 @@
#include
#include
#include
+#include
#include
#include
@@ -98,6 +100,33 @@
unsigned int data;
};
+static int __init disable_gx240_ioapic(struct dmi_system_id *d)
+{
+ /* Disable IO-APIC only if ACPI is disabled */
+ if (acpi_disabled) {
+ printk(KERN_WARNING "%s detected... Disabling IO-APIC\n", d->ident);
+ skip_ioapic_setup = 1;
+ }
+ return(0);
+}
+
+static struct dmi_system_id __initdata ioapic_blacklist_dmi_table[] = {
+ {
+ .callback = disable_gx240_ioapic,
+ .ident = "Dell OptiPlex GX240",
+ .matches = {
+ DMI_MATCH(DMI_SYS_VENDOR, "Dell Computer Corporation"),
+ DMI_MATCH(DMI_PRODUCT_NAME, "OptiPlex GX240"),
+ },
+ },
+ { }
+};
+
+void __init check_ioapic_blacklist(void) {
+ printk(KERN_INFO "Checking for IO-APIC blacklisted systems...\n");
+ dmi_check_system(ioapic_blacklist_dmi_table);
+}
+
static __attribute_const__ struct io_apic __iomem *io_apic_base(int idx)
{
return (void __iomem *) __fix_to_virt(FIX_IO_APIC_BASE_0 + idx)
--- linux-2.6.21.3.orig/arch/i386/kernel/setup.c 2007-06-02 14:17:10.0 +
+++ linux-2.6.21.3/arch/i386/kernel/setup.c 2007-06-02 22:39:46.0 +
@@ -124,6 +124,7 @@
#endif
extern void early_cpu_init(void);
+extern void check_ioapic_blacklist(void);
extern int root_mountflags;
unsigned long saved_videomode;
@@ -642,6 +643,11 @@
"CONFIG_X86_GENERICARCH or CONFIG_X86_BIGSMP.\n");
#endif
#endif
+
+#ifdef CONFIG_X86_IO_APIC
+ check_ioapic_blacklist(); /* This must be after acpi_boot_init */
+#endif
+
#ifdef CONFIG_X86_LOCAL_APIC
if (smp_found_config)
get_smp_config();
Re: [RFC][PATCH] IO-APIC blacklist
> -uhci_hcd :00:1f.2: irq 19, io base 0xff80 # slow > +uhci_hcd :00:1f.2: irq 17, io base 0xff80 # fine nope, this function is on on hardware IRQ 19 in both cases. it just looks like IRQ 17 in the ACPI case due to this: ACPI: PCI Interrupt :00:1f.2[D] -> GSI 19 (level, low) -> IRQ 17 Totally bogus? Yes. google "Kill IRQ compression" But while I truly hate this particular hack and I've wanted it gone for a long time, it doesn't appear to be related to the failure at hand -- it just makes it more irritating to debug. -Len - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [RFC][PATCH] IO-APIC blacklist
On Saturday 02 June 2007 17:28, Linus Torvalds wrote:
> 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 migth
> 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 <[EMAIL PROTECTED]>
> 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.
>
> In fact, I thought that patch already existed in the -mm tree?
Yes, Tear sent the correct patch a while back, akpm picked it up, and i slurped
it into my tree just last night for 2.6.23:
http://git.kernel.org/?p=linux/kernel/git/lenb/linux-acpi-2.6.git;a=commit;h=4d2fafd17a325b3f4f5f9edb1211bc7f4c311269
> Len - do you have any archives back from 2003 and earlier to indicate why
> the Dell GX240 was blacklisted?
Yep, it came to us in this Cset on 2003-08-09
http://linux.bkbits.net:8080/linux-2.6.11-stable/?PAGE=cset=3f35b56btNYYpQfjOuQmiUdjSGFtWg
A young, impressionable maintainer, I'd been working on Linux for about 2
months.
I sync'd the workarounds from 2.4 into 2.5, and this particular one came
from the "UnitedLinux" tree.
My theory at the time was that SuSE had been most successful deploying ACPI,
and so upstream should benefit from their workarounds.
I later realized that this was a strategic mistake, as distro workarounds
often paper-over real bugs by addressing the symptom only.
A bunch of these entries were removed over time, and these days I add
DMI workarounds only when we are sure we have the root cause.
cheers,
-Len
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Re: [RFC][PATCH] IO-APIC blacklist
On Sat, 2 Jun 2007 14:28:58 -0700 (PDT) Linus Torvalds <[EMAIL PROTECTED]>
wrote:
> 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 <[EMAIL PROTECTED]>
> 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.
>
> In fact, I thought that patch already existed in the -mm tree?
It is. remove-dell-optiplex-gx240-from-the-acpi-blacklist.patch
> Len - do you have any archives back from 2003 and earlier to indicate why
> the Dell GX240 was blacklisted?
"add DMI blacklist from UnitedLinux". Lost in the mists of time, I expect.
I guess we can tag remove-dell-optiplex-gx240-from-the-acpi-blacklist.patch
as "backport to 2.6.22.x if it doesn't break anything in 2.6.23-rcX".
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Re: [RFC][PATCH] IO-APIC blacklist
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 :00:1f.2: irq 19, io base 0xff80 # slow
+uhci_hcd :00:1f.2: irq 17, io base 0xff80 # 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).
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..
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 migth
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 <[EMAIL PROTECTED]>
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.
In fact, I thought that patch already existed in the -mm 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).
Linus
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Re: [RFC][PATCH] IO-APIC blacklist
On Sat, 2 Jun 2007, Tear wrote: > > > > Wouldn't this also disable the IOAPIC in the (working) ACPI+IOAPIC case? > > Yes, it would. However, I wanted to make my addition > to the kernel generic so that other people with > problematic IO-APIC implementations can blacklist > their systems without checking whether ACPI is enabled > or not. But that's just wrong. First off, all distro kernels come with ACPI on, so the thing you're fixing is really just for somebody who compiles his own kernel in a particular (and unusual/strange) configuration, and you're making it _worse_ for everybody else. And you're blacklisting it without even understaning _what_ is wrong. I really think we should figure that part out first, Linus - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [RFC][PATCH] IO-APIC blacklist
--- Len Brown <[EMAIL PROTECTED]> wrote:
> > +static int __init disable_blacklisted_ioapic(struct dmi_system_id *d)
> > +{
> > + printk(KERN_WARNING "%s detected... Disabling IO-APIC\n", d->ident);
> > + skip_ioapic_setup = 1;
> > + return(0);
> > +}
>
> Wouldn't this also disable the IOAPIC in the (working) ACPI+IOAPIC case?
Yes, it would. However, I wanted to make my addition
to the kernel generic so that other people with
problematic IO-APIC implementations can blacklist
their systems without checking whether ACPI is enabled
or not.
Thank you for your question/attention.
Regards,
- Tear
Take the Internet to Go: Yahoo!Go puts the Internet in your pocket: mail, news,
photos & more.
http://mobile.yahoo.com/go?refer=1GNXIC
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Re: [RFC][PATCH] IO-APIC blacklist
> +static int __init disable_blacklisted_ioapic(struct dmi_system_id *d)
> +{
> + printk(KERN_WARNING "%s detected... Disabling IO-APIC\n", d->ident);
> + skip_ioapic_setup = 1;
> + return(0);
> +}
Wouldn't this also disable the IOAPIC in the (working) ACPI+IOAPIC case?
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Re: [RFC][PATCH] IO-APIC blacklist
On Sat, 2 Jun 2007, Tear wrote: > > I own a Dell OptiPlex GX240 which, when ACPI is disabled > but IO-APIC is enabled, shows very slow USB performance. > I thought that this could be related to IO-APIC and > tried to boot with "noapic" appended to the kernel > command line. This way the USB transfer speed returned > to normal values. Well, it's almost certainly not the IO-APIC per se. It's more likely to be some irq routing issue, where ACPI fixes up something. Do you have diffs of 'dmesg' with and without ACPI? Linus - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [RFC][PATCH] IO-APIC blacklist
On Sat, Jun 02, 2007 at 07:10:58AM -0700, Tear wrote: > I would like this patch to be merged into the main > tree. If there is any revision/correction that needs to > be done on the patch, please let me know. You forgot: Signed-off-by: Random J Developer <[EMAIL PROTECTED]> (See Documentation/SubmittingPatches) -- Heikki Orsila Barbie's law: [EMAIL PROTECTED] "Math is hard, let's go shopping!" http://www.iki.fi/shd - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
[RFC][PATCH] IO-APIC blacklist
Hi,
I own a Dell OptiPlex GX240 which, when ACPI is disabled
but IO-APIC is enabled, shows very slow USB performance.
I thought that this could be related to IO-APIC and
tried to boot with "noapic" appended to the kernel
command line. This way the USB transfer speed returned
to normal values.
To make sure that noone else encounters a similar problem,
I have written a patch which includes an IO-APIC blacklist
and disables IO-APIC according to the blacklist.
I would like this patch to be merged into the main
tree. If there is any revision/correction that needs to
be done on the patch, please let me know.
I would appreciate any comments.
Thank you for your attention.
Regards,
- Tear
Note: The patch is appended and attached (in case
Yahoo wraps some lines.)
diff -u -r linux-2.6.21.3.orig/arch/i386/kernel/io_apic.c
linux-2.6.21.3/arch/i386/kernel/io_apic.c
--- linux-2.6.21.3.orig/arch/i386/kernel/io_apic.c 2007-06-01
19:01:35.0 +
+++ linux-2.6.21.3/arch/i386/kernel/io_apic.c 2007-06-01 21:00:46.0
+
@@ -35,6 +35,7 @@
#include
#include
#include
+#include
#include
#include
@@ -98,6 +99,30 @@
unsigned int data;
};
+static int __init disable_blacklisted_ioapic(struct dmi_system_id *d)
+{
+ printk(KERN_WARNING "%s detected... Disabling IO-APIC\n", d->ident);
+ skip_ioapic_setup = 1;
+ return(0);
+}
+
+static struct dmi_system_id __initdata ioapic_blacklist_dmi_table[] = {
+ {
+ .callback = disable_blacklisted_ioapic,
+ .ident = "Dell OptiPlex GX240",
+ .matches = {
+ DMI_MATCH(DMI_SYS_VENDOR, "Dell Computer Corporation"),
+ DMI_MATCH(DMI_PRODUCT_NAME, "OptiPlex GX240"),
+ },
+ },
+ { }
+};
+
+void __init check_ioapic_blacklist(void) {
+ printk(KERN_INFO "Checking for IO-APIC blacklisted systems...\n");
+ dmi_check_system(ioapic_blacklist_dmi_table);
+}
+
static __attribute_const__ struct io_apic __iomem *io_apic_base(int idx)
{
return (void __iomem *) __fix_to_virt(FIX_IO_APIC_BASE_0 + idx)
diff -u -r linux-2.6.21.3.orig/arch/i386/kernel/setup.c
linux-2.6.21.3/arch/i386/kernel/setup.c
--- linux-2.6.21.3.orig/arch/i386/kernel/setup.c2007-06-01
19:01:35.0 +
+++ linux-2.6.21.3/arch/i386/kernel/setup.c 2007-06-01 21:04:01.0
+
@@ -124,6 +124,7 @@
#endif
extern void early_cpu_init(void);
+extern void check_ioapic_blacklist(void);
extern int root_mountflags;
unsigned long saved_videomode;
@@ -616,6 +617,11 @@
#ifdef CONFIG_X86_GENERICARCH
generic_apic_probe();
#endif
+
+#ifdef CONFIG_X86_IO_APIC
+ check_ioapic_blacklist();
+#endif
+
if (efi_enabled)
efi_map_memmap();
Sick sense of humor? Visit Yahoo! TV's
Comedy with an Edge to see what's on, when.
http://tv.yahoo.com/collections/222diff -u -r linux-2.6.21.3.orig/arch/i386/kernel/io_apic.c linux-2.6.21.3/arch/i386/kernel/io_apic.c
--- linux-2.6.21.3.orig/arch/i386/kernel/io_apic.c 2007-06-01 19:01:35.0 +
+++ linux-2.6.21.3/arch/i386/kernel/io_apic.c 2007-06-01 21:00:46.0 +
@@ -35,6 +35,7 @@
#include
#include
#include
+#include
#include
#include
@@ -98,6 +99,30 @@
unsigned int data;
};
+static int __init disable_blacklisted_ioapic(struct dmi_system_id *d)
+{
+ printk(KERN_WARNING "%s detected... Disabling IO-APIC\n", d->ident);
+ skip_ioapic_setup = 1;
+ return(0);
+}
+
+static struct dmi_system_id __initdata ioapic_blacklist_dmi_table[] = {
+ {
+ .callback = disable_blacklisted_ioapic,
+ .ident = "Dell OptiPlex GX240",
+ .matches = {
+ DMI_MATCH(DMI_SYS_VENDOR, "Dell Computer Corporation"),
+ DMI_MATCH(DMI_PRODUCT_NAME, "OptiPlex GX240"),
+ },
+ },
+ { }
+};
+
+void __init check_ioapic_blacklist(void) {
+ printk(KERN_INFO "Checking for IO-APIC blacklisted systems...\n");
+ dmi_check_system(ioapic_blacklist_dmi_table);
+}
+
static __attribute_const__ struct io_apic __iomem *io_apic_base(int idx)
{
return (void __iomem *) __fix_to_virt(FIX_IO_APIC_BASE_0 + idx)
diff -u -r linux-2.6.21.3.orig/arch/i386/kernel/setup.c linux-2.6.21.3/arch/i386/kernel/setup.c
--- linux-2.6.21.3.orig/arch/i386/kernel/setup.c 2007-06-01 19:01:35.0 +
+++ linux-2.6.21.3/arch/i386/kernel/setup.c 2007-06-01 21:04:01.0 +
@@ -124,6 +124,7 @@
#endif
extern void early_cpu_init(void);
+extern void check_ioapic_blacklist(void);
extern int root_mountflags;
unsigned long saved_videomode;
@@ -616,6 +617,11 @@
#ifdef CONFIG_X86_GENERICARCH
generic_apic_probe();
#endif
+
+#ifdef CONFIG_X86_IO_APIC
+ check_ioapic_blacklist();
+#endif
+
if (efi_enabled)
efi_map_memmap();
[RFC][PATCH] IO-APIC blacklist
Hi,
I own a Dell OptiPlex GX240 which, when ACPI is disabled
but IO-APIC is enabled, shows very slow USB performance.
I thought that this could be related to IO-APIC and
tried to boot with noapic appended to the kernel
command line. This way the USB transfer speed returned
to normal values.
To make sure that noone else encounters a similar problem,
I have written a patch which includes an IO-APIC blacklist
and disables IO-APIC according to the blacklist.
I would like this patch to be merged into the main
tree. If there is any revision/correction that needs to
be done on the patch, please let me know.
I would appreciate any comments.
Thank you for your attention.
Regards,
- Tear
Note: The patch is appended and attached (in case
Yahoo wraps some lines.)
diff -u -r linux-2.6.21.3.orig/arch/i386/kernel/io_apic.c
linux-2.6.21.3/arch/i386/kernel/io_apic.c
--- linux-2.6.21.3.orig/arch/i386/kernel/io_apic.c 2007-06-01
19:01:35.0 +
+++ linux-2.6.21.3/arch/i386/kernel/io_apic.c 2007-06-01 21:00:46.0
+
@@ -35,6 +35,7 @@
#include linux/msi.h
#include linux/htirq.h
#include linux/freezer.h
+#include linux/dmi.h
#include asm/io.h
#include asm/smp.h
@@ -98,6 +99,30 @@
unsigned int data;
};
+static int __init disable_blacklisted_ioapic(struct dmi_system_id *d)
+{
+ printk(KERN_WARNING %s detected... Disabling IO-APIC\n, d-ident);
+ skip_ioapic_setup = 1;
+ return(0);
+}
+
+static struct dmi_system_id __initdata ioapic_blacklist_dmi_table[] = {
+ {
+ .callback = disable_blacklisted_ioapic,
+ .ident = Dell OptiPlex GX240,
+ .matches = {
+ DMI_MATCH(DMI_SYS_VENDOR, Dell Computer Corporation),
+ DMI_MATCH(DMI_PRODUCT_NAME, OptiPlex GX240),
+ },
+ },
+ { }
+};
+
+void __init check_ioapic_blacklist(void) {
+ printk(KERN_INFO Checking for IO-APIC blacklisted systems...\n);
+ dmi_check_system(ioapic_blacklist_dmi_table);
+}
+
static __attribute_const__ struct io_apic __iomem *io_apic_base(int idx)
{
return (void __iomem *) __fix_to_virt(FIX_IO_APIC_BASE_0 + idx)
diff -u -r linux-2.6.21.3.orig/arch/i386/kernel/setup.c
linux-2.6.21.3/arch/i386/kernel/setup.c
--- linux-2.6.21.3.orig/arch/i386/kernel/setup.c2007-06-01
19:01:35.0 +
+++ linux-2.6.21.3/arch/i386/kernel/setup.c 2007-06-01 21:04:01.0
+
@@ -124,6 +124,7 @@
#endif
extern void early_cpu_init(void);
+extern void check_ioapic_blacklist(void);
extern int root_mountflags;
unsigned long saved_videomode;
@@ -616,6 +617,11 @@
#ifdef CONFIG_X86_GENERICARCH
generic_apic_probe();
#endif
+
+#ifdef CONFIG_X86_IO_APIC
+ check_ioapic_blacklist();
+#endif
+
if (efi_enabled)
efi_map_memmap();
Sick sense of humor? Visit Yahoo! TV's
Comedy with an Edge to see what's on, when.
http://tv.yahoo.com/collections/222diff -u -r linux-2.6.21.3.orig/arch/i386/kernel/io_apic.c linux-2.6.21.3/arch/i386/kernel/io_apic.c
--- linux-2.6.21.3.orig/arch/i386/kernel/io_apic.c 2007-06-01 19:01:35.0 +
+++ linux-2.6.21.3/arch/i386/kernel/io_apic.c 2007-06-01 21:00:46.0 +
@@ -35,6 +35,7 @@
#include linux/msi.h
#include linux/htirq.h
#include linux/freezer.h
+#include linux/dmi.h
#include asm/io.h
#include asm/smp.h
@@ -98,6 +99,30 @@
unsigned int data;
};
+static int __init disable_blacklisted_ioapic(struct dmi_system_id *d)
+{
+ printk(KERN_WARNING %s detected... Disabling IO-APIC\n, d-ident);
+ skip_ioapic_setup = 1;
+ return(0);
+}
+
+static struct dmi_system_id __initdata ioapic_blacklist_dmi_table[] = {
+ {
+ .callback = disable_blacklisted_ioapic,
+ .ident = Dell OptiPlex GX240,
+ .matches = {
+ DMI_MATCH(DMI_SYS_VENDOR, Dell Computer Corporation),
+ DMI_MATCH(DMI_PRODUCT_NAME, OptiPlex GX240),
+ },
+ },
+ { }
+};
+
+void __init check_ioapic_blacklist(void) {
+ printk(KERN_INFO Checking for IO-APIC blacklisted systems...\n);
+ dmi_check_system(ioapic_blacklist_dmi_table);
+}
+
static __attribute_const__ struct io_apic __iomem *io_apic_base(int idx)
{
return (void __iomem *) __fix_to_virt(FIX_IO_APIC_BASE_0 + idx)
diff -u -r linux-2.6.21.3.orig/arch/i386/kernel/setup.c linux-2.6.21.3/arch/i386/kernel/setup.c
--- linux-2.6.21.3.orig/arch/i386/kernel/setup.c 2007-06-01 19:01:35.0 +
+++ linux-2.6.21.3/arch/i386/kernel/setup.c 2007-06-01 21:04:01.0 +
@@ -124,6 +124,7 @@
#endif
extern void early_cpu_init(void);
+extern void check_ioapic_blacklist(void);
extern int root_mountflags;
unsigned long saved_videomode;
@@ -616,6 +617,11 @@
#ifdef CONFIG_X86_GENERICARCH
generic_apic_probe();
#endif
+
+#ifdef CONFIG_X86_IO_APIC
+ check_ioapic_blacklist();
+#endif
+
if (efi_enabled)
efi_map_memmap();
Re: [RFC][PATCH] IO-APIC blacklist
On Sat, Jun 02, 2007 at 07:10:58AM -0700, Tear wrote: I would like this patch to be merged into the main tree. If there is any revision/correction that needs to be done on the patch, please let me know. You forgot: Signed-off-by: Random J Developer [EMAIL PROTECTED] (See Documentation/SubmittingPatches) -- Heikki Orsila Barbie's law: [EMAIL PROTECTED] Math is hard, let's go shopping! http://www.iki.fi/shd - To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [RFC][PATCH] IO-APIC blacklist
On Sat, 2 Jun 2007, Tear wrote: I own a Dell OptiPlex GX240 which, when ACPI is disabled but IO-APIC is enabled, shows very slow USB performance. I thought that this could be related to IO-APIC and tried to boot with noapic appended to the kernel command line. This way the USB transfer speed returned to normal values. Well, it's almost certainly not the IO-APIC per se. It's more likely to be some irq routing issue, where ACPI fixes up something. Do you have diffs of 'dmesg' with and without ACPI? Linus - To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [RFC][PATCH] IO-APIC blacklist
+static int __init disable_blacklisted_ioapic(struct dmi_system_id *d)
+{
+ printk(KERN_WARNING %s detected... Disabling IO-APIC\n, d-ident);
+ skip_ioapic_setup = 1;
+ return(0);
+}
Wouldn't this also disable the IOAPIC in the (working) ACPI+IOAPIC case?
-
To unsubscribe from this list: send the line unsubscribe linux-kernel in
the body of a message to [EMAIL PROTECTED]
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Re: [RFC][PATCH] IO-APIC blacklist
--- Len Brown [EMAIL PROTECTED] wrote:
+static int __init disable_blacklisted_ioapic(struct dmi_system_id *d)
+{
+ printk(KERN_WARNING %s detected... Disabling IO-APIC\n, d-ident);
+ skip_ioapic_setup = 1;
+ return(0);
+}
Wouldn't this also disable the IOAPIC in the (working) ACPI+IOAPIC case?
Yes, it would. However, I wanted to make my addition
to the kernel generic so that other people with
problematic IO-APIC implementations can blacklist
their systems without checking whether ACPI is enabled
or not.
Thank you for your question/attention.
Regards,
- Tear
Take the Internet to Go: Yahoo!Go puts the Internet in your pocket: mail, news,
photos more.
http://mobile.yahoo.com/go?refer=1GNXIC
-
To unsubscribe from this list: send the line unsubscribe linux-kernel in
the body of a message to [EMAIL PROTECTED]
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Re: [RFC][PATCH] IO-APIC blacklist
On Sat, 2 Jun 2007, Tear wrote: Wouldn't this also disable the IOAPIC in the (working) ACPI+IOAPIC case? Yes, it would. However, I wanted to make my addition to the kernel generic so that other people with problematic IO-APIC implementations can blacklist their systems without checking whether ACPI is enabled or not. But that's just wrong. First off, all distro kernels come with ACPI on, so the thing you're fixing is really just for somebody who compiles his own kernel in a particular (and unusual/strange) configuration, and you're making it _worse_ for everybody else. And you're blacklisting it without even understaning _what_ is wrong. I really think we should figure that part out first, Linus - To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [RFC][PATCH] IO-APIC blacklist
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 :00:1f.2: irq 19, io base 0xff80 # slow
+uhci_hcd :00:1f.2: irq 17, io base 0xff80 # 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).
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..
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 migth
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 [EMAIL PROTECTED]
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.
In fact, I thought that patch already existed in the -mm 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).
Linus
-
To unsubscribe from this list: send the line unsubscribe linux-kernel in
the body of a message to [EMAIL PROTECTED]
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Re: [RFC][PATCH] IO-APIC blacklist
On Sat, 2 Jun 2007 14:28:58 -0700 (PDT) Linus Torvalds [EMAIL PROTECTED]
wrote:
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 [EMAIL PROTECTED]
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.
In fact, I thought that patch already existed in the -mm tree?
It is. remove-dell-optiplex-gx240-from-the-acpi-blacklist.patch
Len - do you have any archives back from 2003 and earlier to indicate why
the Dell GX240 was blacklisted?
add DMI blacklist from UnitedLinux. Lost in the mists of time, I expect.
I guess we can tag remove-dell-optiplex-gx240-from-the-acpi-blacklist.patch
as backport to 2.6.22.x if it doesn't break anything in 2.6.23-rcX.
-
To unsubscribe from this list: send the line unsubscribe linux-kernel in
the body of a message to [EMAIL PROTECTED]
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Re: [RFC][PATCH] IO-APIC blacklist
On Saturday 02 June 2007 17:28, Linus Torvalds wrote:
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 migth
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 [EMAIL PROTECTED]
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.
In fact, I thought that patch already existed in the -mm tree?
Yes, Tear sent the correct patch a while back, akpm picked it up, and i slurped
it into my tree just last night for 2.6.23:
http://git.kernel.org/?p=linux/kernel/git/lenb/linux-acpi-2.6.git;a=commit;h=4d2fafd17a325b3f4f5f9edb1211bc7f4c311269
Len - do you have any archives back from 2003 and earlier to indicate why
the Dell GX240 was blacklisted?
Yep, it came to us in this Cset on 2003-08-09
http://linux.bkbits.net:8080/linux-2.6.11-stable/?PAGE=csetREV=3f35b56btNYYpQfjOuQmiUdjSGFtWg
A young, impressionable maintainer, I'd been working on Linux for about 2
months.
I sync'd the workarounds from 2.4 into 2.5, and this particular one came
from the UnitedLinux tree.
My theory at the time was that SuSE had been most successful deploying ACPI,
and so upstream should benefit from their workarounds.
I later realized that this was a strategic mistake, as distro workarounds
often paper-over real bugs by addressing the symptom only.
A bunch of these entries were removed over time, and these days I add
DMI workarounds only when we are sure we have the root cause.
cheers,
-Len
-
To unsubscribe from this list: send the line unsubscribe linux-kernel in
the body of a message to [EMAIL PROTECTED]
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Re: [RFC][PATCH] IO-APIC blacklist
-uhci_hcd :00:1f.2: irq 19, io base 0xff80 # slow +uhci_hcd :00:1f.2: irq 17, io base 0xff80 # fine nope, this function is on on hardware IRQ 19 in both cases. it just looks like IRQ 17 in the ACPI case due to this: ACPI: PCI Interrupt :00:1f.2[D] - GSI 19 (level, low) - IRQ 17 Totally bogus? Yes. google Kill IRQ compression But while I truly hate this particular hack and I've wanted it gone for a long time, it doesn't appear to be related to the failure at hand -- it just makes it more irritating to debug. -Len - To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [RFC][PATCH] IO-APIC blacklist
Linus Torvalds wrote:
On Sat, 2 Jun 2007, Tear wrote:
Wouldn't this also disable the IOAPIC in the (working) ACPI+IOAPIC case?
Yes, it would. However, I wanted to make my addition
to the kernel generic so that other people with
problematic IO-APIC implementations can blacklist
their systems without checking whether ACPI is enabled
or not.
But that's just wrong. First off, all distro kernels come with ACPI on, so
the thing you're fixing is really just for somebody who compiles his own
kernel in a particular (and unusual/strange) configuration, and you're
making it _worse_ for everybody else.
Mr. Torvalds,
The patch scans the DMI for Dell OptiPlex GX240
and disables IO-APIC only if such a system is detected.
It does not disable IO-APIC for other people.
In addition, Dell OptiPlex GX240 is (at least currently)
in the ACPI blacklist. So with a regular distro, one
gets IO-APIC and acpi=ht which causes USB transfers
to be very slow.
I have made an attempt to get Dell OptiPlex GX240
out of the ACPI blacklist. Please see:
http://marc.info/?t=11789788191r=1w=2
Nevertheless, I am willing to modify the patch
to make IO-APIC work when ACPI is enabled. A
quick search pointed me to the variable named
acpi_disabled. I can use this variable to
detect whether ACPI is enabled and disable
IO-APIC if it is not. Please see the
attached patch for such an implementation.
And you're blacklisting it without even understaning _what_ is wrong. I
really think we should figure that part out first,
I willing to put effort into figuring out what
is wrong. Please let me know if there is anything
I can do to further our information about this
problem. As I said before, I would be glad to
send to you the diff between any of the four
cases I mentioned in my previous e-mail to you.
Were you able to take a look at the dmesg
outputs in my previous e-mail?
Thank you for your attention.
Regards,
- Tear
Choose the right car based on your needs. Check out Yahoo! Autos new Car
Finder tool.
http://autos.yahoo.com/carfinder/--- linux-2.6.21.3.orig/arch/i386/kernel/io_apic.c 2007-06-02 14:17:10.0 +
+++ linux-2.6.21.3/arch/i386/kernel/io_apic.c 2007-06-02 22:24:44.0 +
@@ -35,6 +35,7 @@
#include linux/msi.h
#include linux/htirq.h
#include linux/freezer.h
+#include linux/dmi.h
#include asm/io.h
#include asm/smp.h
@@ -44,6 +45,7 @@
#include asm/nmi.h
#include asm/msidef.h
#include asm/hypertransport.h
+#include asm/acpi.h
#include mach_apic.h
#include mach_apicdef.h
@@ -98,6 +100,33 @@
unsigned int data;
};
+static int __init disable_gx240_ioapic(struct dmi_system_id *d)
+{
+ /* Disable IO-APIC only if ACPI is disabled */
+ if (acpi_disabled) {
+ printk(KERN_WARNING %s detected... Disabling IO-APIC\n, d-ident);
+ skip_ioapic_setup = 1;
+ }
+ return(0);
+}
+
+static struct dmi_system_id __initdata ioapic_blacklist_dmi_table[] = {
+ {
+ .callback = disable_gx240_ioapic,
+ .ident = Dell OptiPlex GX240,
+ .matches = {
+ DMI_MATCH(DMI_SYS_VENDOR, Dell Computer Corporation),
+ DMI_MATCH(DMI_PRODUCT_NAME, OptiPlex GX240),
+ },
+ },
+ { }
+};
+
+void __init check_ioapic_blacklist(void) {
+ printk(KERN_INFO Checking for IO-APIC blacklisted systems...\n);
+ dmi_check_system(ioapic_blacklist_dmi_table);
+}
+
static __attribute_const__ struct io_apic __iomem *io_apic_base(int idx)
{
return (void __iomem *) __fix_to_virt(FIX_IO_APIC_BASE_0 + idx)
--- linux-2.6.21.3.orig/arch/i386/kernel/setup.c 2007-06-02 14:17:10.0 +
+++ linux-2.6.21.3/arch/i386/kernel/setup.c 2007-06-02 22:39:46.0 +
@@ -124,6 +124,7 @@
#endif
extern void early_cpu_init(void);
+extern void check_ioapic_blacklist(void);
extern int root_mountflags;
unsigned long saved_videomode;
@@ -642,6 +643,11 @@
CONFIG_X86_GENERICARCH or CONFIG_X86_BIGSMP.\n);
#endif
#endif
+
+#ifdef CONFIG_X86_IO_APIC
+ check_ioapic_blacklist(); /* This must be after acpi_boot_init */
+#endif
+
#ifdef CONFIG_X86_LOCAL_APIC
if (smp_found_config)
get_smp_config();
Re: [RFC][PATCH] IO-APIC blacklist
Linus Torvalds [EMAIL PROTECTED] 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 :00:1f.2: irq 19, io base 0xff80 # slow
+uhci_hcd :00:1f.2: irq 17, io base 0xff80 # 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 [EMAIL PROTECTED]
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 Linux version 2.6.21.3-smp ([EMAIL PROTECTED]) (gcc version 4.1.2 20061115
(prerelease) (Debian 4.1.1-21)) #25 SMP
Re: [RFC][PATCH] IO-APIC blacklist
On Saturday 02 June 2007 19:53, Tear wrote: Linus Torvalds [EMAIL PROTECTED] 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 [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
