Skip to content

K
Kernel

openeuler / Kernel
1 年多 前同步成功

通知 8
Star 0
Fork 0
K
Kernel
切换分支/标签
  1. 19 9月, 2006 1 次提交
    • L
      Revert mmiocfg heuristics and blacklist changes · 79e453d4
      由 Linus Torvalds 提交于 
      This reverts commits 11012d41 and
40dd2d20, which allowed us to use the
MMIO accesses for PCI config cycles even without the area being marked
reserved in the e820 memory tables.

Those changes were needed for EFI-environment Intel macs, but broke some
newer Intel 965 boards, so for now it's better to revert to our old
2.6.17 behaviour and at least avoid introducing any new breakage.

Andi Kleen has a set of patches that work with both EFI and the broken
Intel 965 boards, which will be applied once they get wider testing.

Cc: Arjan van de Ven <arjan@infradead.org>
Cc: Edgar Hucek <hostmaster@ed-soft.at>
Cc: Andi Kleen <ak@suse.de>
Signed-off-by: NLinus Torvalds <torvalds@osdl.org>
      79e453d4
  3. 31 8月, 2006 2 次提交
    • A
      [PATCH] x86: Disable MMCONFIG on Intel SDV using DMI blacklist · 40dd2d20
      由 Andi Kleen 提交于 
      As a replacement for the earlier removal of the e820 MCFG check
we blacklist the Intel SDV with the original BIOS bug that
motivated that check. On those machines don't use MMCONFIG.

This also adds a new pci=mmconf parameter to override the blacklist.

Cc: Greg KH <gregkh@suse.de>
Cc: Arjan van de Ven <arjan@infradead.org>
Signed-off-by: NAndi Kleen <ak@suse.de>
Signed-off-by: NLinus Torvalds <torvalds@osdl.org>
      40dd2d20
    • A
      [PATCH] x86: Revert e820 MCFG heuristics · 11012d41
      由 Andi Kleen 提交于 
      The check for the MCFG table being reserved in the e820 map was originally
added to detect a broken BIOS in a preproduction Intel SDV. However it also
breaks the Apple x86 Macs, which can't supply this properly, but need
a working MCFG. With this patch they wouldn't use the MCFG and not work.

After some discussion I think it's best to remove the heuristic again.
It also failed on some other boxes (although it didn't cause much
problems there because old style port access for PCI config space
still works as fallback), but the preproduction SDVs can just use
pci=nommcfg. Supporting production machines properly is more
important.

Edgar Hucek did all the debugging work.

Cc: Arjan van de Ven <arjan@infradead.org>
Cc: Edgar Hucek <hostmaster@ed-soft.at>
Signed-off-by: NAndi Kleen <ak@suse.de>
Signed-off-by: NLinus Torvalds <torvalds@osdl.org>
      11012d41
  5. 27 8月, 2006 2 次提交
  7. 13 7月, 2006 1 次提交
  9. 03 7月, 2006 1 次提交
  11. 01 7月, 2006 1 次提交
  13. 28 6月, 2006 1 次提交
  15. 27 6月, 2006 1 次提交
  17. 26 6月, 2006 1 次提交
  19. 23 6月, 2006 2 次提交
  21. 22 6月, 2006 2 次提交
    • C
      [PATCH] PCI: fix issues with extended conf space when MMCONFIG disabled because of e820 · ead2bfeb
      由 Chuck Ebbert 提交于 
      On 15 Jun 2006 03:45:10 +0200, Andi Kleen wrote:

> Anyways I would say that if the BIOS can't get MCFG right then
> it's likely not been validated on that board and shouldn't be used.

According to Petr Vandrovec:

 ... "What is important (and checked) is address of MMCONFIG reported by MCFG
 table...  Unfortunately code does not bother with printing that address :-(

 "Another problem is that code has hardcoded that MMCONFIG area is 256MB large.
 Unfortunately for the code PCI specification allows any power of two between 2MB
 and 256MB if vendor knows that such amount of busses (from 2 to 128) will be
 sufficient for system.  With notebook it is quite possible that not full 8 bits
 are implemented for MMCONFIG bus number."

So here is a patch.  Unfortunately my system still fails the test because
it doesn't reserve any part of the MMCONFIG area, but this may fix others.

Booted on x86_64, only compiled on i386.  x86_64 still remaps the max area
(256MB) even though only 2MB is checked... but 2.6.16 had no check at all
so it is still better.

PCI: reduce size of x86 MMCONFIG reserved area check

1.  Print the address of the MMCONFIG area when the test for that area
    being reserved fails.

2.  Only check if the first 2MB is reserved, as that is the minimum.
Signed-off-by: NChuck Ebbert <76306.1226@compuserve.com>
Acked-by: NArjan van de Ven <arjan@linux.intel.com>
Signed-off-by: NGreg Kroah-Hartman <gregkh@suse.de>
      ead2bfeb
    • R
      [PATCH] PCI: i386/x86_84: disable PCI resource decode on device disable · 53e4d30d
      由 Rajesh Shah 提交于 
      When a PCI device is disabled via pci_disable_device(), it's still
left decoding its BAR resource ranges even though its driver
will have likely released those regions (and may even have
unloaded). pci_enable_device() already explicitly enables
BAR resource decode for the device being enabled. This patch
disables resource decode for the PCI device being disabled,
making it symmetric with the enable call.

I saw this while doing something else, not because of a
problem report. Still, seems to be the correct thing to do.
Signed-off-by: NRajesh Shah <rajesh.shah@intel.com>
Signed-off-by: NGreg Kroah-Hartman <gregkh@suse.de>
      53e4d30d
  23. 28 4月, 2006 1 次提交
  25. 15 4月, 2006 1 次提交
    • G
      [PATCH] arch/i386/pci/irq.c - new VIA chipsets (fwd) · 40d8b89b
      由 Grzegorz Janoszka 提交于 
      I use 2.6.15.6 Linux kernel and found some problems. I have about 100
Linux boxes (all with the same (binary the same) kernel). Last time I have
upgraded all those boxes from 2.4.32 to 2.6.15.6 (first 2.6.15.1, next .2,
.4 and .6) and I have found some problems on VIA based PC's. Probably the
reason of this is that some VIA chipsets are unrecognized by IRQ router.

In line 586 there is: /* FIXME: add new ones for 8233/5 */

There were only a few of chipsets ID's there, some of my VIA chipsets were
not present and kernel used default IRQ router.

I have added three entries, so that the code looks like:

        case PCI_DEVICE_ID_VIA_82C596:
        case PCI_DEVICE_ID_VIA_82C686:
        case PCI_DEVICE_ID_VIA_8231:
        case PCI_DEVICE_ID_VIA_8233A:
        case PCI_DEVICE_ID_VIA_8235:
        case PCI_DEVICE_ID_VIA_8237:
        case PCI_DEVICE_ID_VIA_8237_SATA:
                /* FIXME: add new ones for 8233/5 */
                r->name = "VIA";
                r->get = pirq_via_get;
                r->set = pirq_via_set;
                return 1;
        }

The kernel goes fine but I haven't testes it for weeks, I'm just a moment
after reboot :)
One thing is different (better?):
Using previus kernel I had:
PCI: Via IRQ fixup for 0000:00:0f.1, from 255 to 0
now I have:
PCI: Via IRQ fixup for 0000:00:0f.1, from 255 to 11

Maybe it is good idea to add there some more VIA chipsets?
The ones I have added seem to be OK.

From: Grzegorz Janoszka <Grzegorz@Janoszka.pl>
Acked-by: NMartin Mares <mj@ucw.cz>
Signed-off-by: NGreg Kroah-Hartman <gregkh@suse.de>
      40d8b89b
  27. 11 4月, 2006 1 次提交
  29. 10 4月, 2006 4 次提交
  31. 24 3月, 2006 2 次提交
    • B
      [PATCH] PCI: PCI/Cardbus cards hidden, needs pci=assign-busses to fix · 8c4b2cf9
      由 Bernhard Kaindl 提交于 
      "In some cases, especially on modern laptops with a lot of PCI and cardbus
bridges, we're unable to assign correct secondary/subordinate bus numbers
to all cardbus bridges due to BIOS limitations unless we are using
"pci=assign-busses" boot option." -- Ivan Kokshaysky (from a patch comment)

Without it, Cardbus cards inserted are never seen by PCI because the parent
PCI-PCI Bridge of the Cardbus bridge will not pass and translate Type 1 PCI
configuration cycles correctly and the system will fail to find and
initialise the PCI devices in the system.

Reference: PCI-PCI Bridges: PCI Configuration Cycles and PCI Bus Numbering:
http://www.science.unitn.it/~fiorella/guidelinux/tlk/node72.html

The reason for this is that:
 ``All PCI busses located behind a PCI-PCI bridge must reside between the
secondary bus number and the subordinate bus number (inclusive).''

"pci=assign-busses" makes pcibios_assign_all_busses return 1 and this
turns on PCI renumbering during PCI probing.

Alan suggested to use DMI automatically set assign-busses on problem systems.

The only question for me was where to put it.  I put it directly before
scanning PCI bus into pcibios_scan_root() because it's called from legacy,
acpi and numa and so it can be one place for all systems and configurations
which may need it.

AMD64 Laptops are also affected and fixed by assign-busses, and the code is
also incuded from arch/x86_64/pci/ that place will also work for x86_64
kernels, I only ifdef'-ed the x86-only Laptop in this example.

Affected and known or assumed to be fixed with it are (found by googling):

* ASUS Z71V and L3s
* Samsung X20
* Compaq R3140us and all Compaq R3000 series laptops with TI1620 Controller,
  also Compaq R4000 series (from a kernel.org bugreport)
* HP zv5000z (AMD64 3700+, known that fixup_parent_subordinate_busnr fixes it)
* HP zv5200z
* IBM ThinkPad 240
* An IBM ThinkPad (1.8 GHz Pentium M) debugged by Pavel Machek
  gives the correspondig message which detects the possible problem.
* MSI S260 / Medion SIM 2100 MD 95600

The patch also expands the "try pci=assign-busses" warning so testers will
help us to update the DMI table.

Cc: Ivan Kokshaysky <ink@jurassic.park.msu.ru>
Cc: Alan Cox <alan@lxorguk.ukuu.org.uk>
Cc: Dominik Brodowski <linux@dominikbrodowski.net>
Cc: Russell King <rmk@arm.linux.org.uk>
Signed-off-by: NAndrew Morton <akpm@osdl.org>
Signed-off-by: NGreg Kroah-Hartman <gregkh@suse.de>
      8c4b2cf9
    • A
      [PATCH] PCI: Give PCI config access initialization a defined ordering · 92c05fc1
      由 Andi Kleen 提交于 
      I moved it to a separate function which is safer.

This avoids problems with the linker reordering them and the
less useful PCI config space access methods taking priority
over the better ones.

Fixes some problems with broken MMCONFIG

Cc: Dave Hansen <haveblue@us.ibm.com>
Signed-off-by: NAndi Kleen <ak@suse.de>
Signed-off-by: NGreg Kroah-Hartman <gregkh@suse.de>
      92c05fc1
  33. 01 2月, 2006 2 次提交
  35. 15 1月, 2006 1 次提交
    • D
      [PATCH] gx1fb: (try to) play nicer with various BIOSes · a80da738
      由 David Vrabel 提交于 
      Seems that the CS5530A chip used in Geode GX1 systems has some crazy feature
that causes SMI traps when accessing the PCI configuration space of the video
device.  Various GX1 BIOSes seem to use this 'feature' to hide the real BARs
of the device.  This patch disables these traps (in an early PCI fixup) so
that Linux sees the real, physical BARs and not the virtual ones provided by
the BIOS.

This should allow the GX1 framebuffer driver to work on more systems that have
different BIOSes as the driver no longer guesses at what the virtual BARs
mean.

I'm not entirely sure it the correct solution as I can neither test regular
VGA console nor the X's 'cyrix' video driver so there might be some breakage
there -- probably best to get some more testers before applying it.
Signed-off-by: NAntonino Daplas <adaplas@pol.net>
Signed-off-by: NAndrew Morton <akpm@osdl.org>
Signed-off-by: NLinus Torvalds <torvalds@osdl.org>
      a80da738
  37. 10 1月, 2006 3 次提交
  39. 07 1月, 2006 1 次提交
  41. 21 12月, 2005 1 次提交
  43. 17 12月, 2005 1 次提交
  45. 16 12月, 2005 1 次提交
  47. 13 12月, 2005 2 次提交
  49. 24 11月, 2005 3 次提交
  51. 11 11月, 2005 1 次提交
    • J
      [PATCH] PCI: fix for Toshiba ohci1394 quirk · 6e6ece5d
      由 Jesse Barnes 提交于 
      After much testing and agony, I've discovered that my previous ohci1394
quirk for Toshiba laptops is not 100% reliable.  It apparently fails to
do the interrupt line change either correctly or in time, since in about
2 out of 5 boots, the kernel's irqdebug code will *still* disable irq 11
when the ohci1394 driver is loaded (at pci_enable_device time I think).

This patch switches things around a little in the workaround.  First, it
removes the mdelay.  I didn't see a need for it and my testing has shown
that it's not necessary for the quirk to work.

Secondly, instead of trying to change the interrupt line to what ACPI
tells us it should be, this patch makes the quirk use the value in the
PCI_INTERRUPT_LINE register.  On this laptop at least, that seems to be
the right thing to do, though additional testing on other laptops and/or
with actual firewire devices would be appreciated.
Signed-off-by: NJesse Barnes <jbarnes@virtuousgeek.org>
Signed-off-by: NGreg Kroah-Hartman <gregkh@suse.de>
      6e6ece5d