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).
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/
[Index of Archives]
[Kernel Newbies]
[Netfilter]
[Bugtraq]
[Photo]
[Stuff]
[Gimp]
[Yosemite News]
[MIPS Linux]
[ARM Linux]
[Linux Security]
[Linux RAID]
[Video 4 Linux]
[Linux for the blind]
[Linux Resources]
