Linux-kernel mailing list archive 1998-31,: Re: PCI patch for 2.1.114

# Re: PCI patch for 2.1.114

peloy@ven.ra.rockwell.com
5 Aug 1998 00:58:05 GMT

- Messages sorted by: [ date ][ thread ][ subject ][ author ]
- Next message: Allan Hsu: "2.1.X sound?"
- Previous message: Michel Catudal: "Re: No more connection to internet after Kernel 2.1.113"
- Maybe in reply to: Martin Mares: "PCI patch for 2.1.114"
- Next in thread: peloy@ven.ra.rockwell.com: "Re: PCI patch for 2.1.114"

Hi Martin,

Martin Mares <mj@atrey.karlin.mff.cuni.cz> wrote:

> This patch makes 2.1.113 compile without CONFIG_PCI_DIRECT and also makes
> the direct hardware access more paranoid than before (for more information,
> just see the comment).

This patch allows 2.1.114 to compile but it still does not fix the
"PCI: Discovered primary peer bus %02x" message I started to see in
2.1.112 while boot. The machine goes nuts printing these messages and
then hangs with an oops.

My .config has these options:

CONFIG_PCI=y
CONFIG_PCI_BIOS=y
# CONFIG_PCI_DIRECT is not set
# CONFIG_PCI_QUIRKS is not set
# CONFIG_PCI_OLD_PROC is not set

They used to work just fine before 2.1.112.

Martin, is there anything you want me to try besides disabling PCI
BIOS access? I enabled PCI direct access and disable PCI BIOS access:

CONFIG_PCI=y
# CONFIG_PCI_BIOS is not set
CONFIG_PCI_DIRECT=y
# CONFIG_PCI_QUIRKS is not set
# CONFIG_PCI_OLD_PROC is not set

and was able to boot 2.1.114. dmesg shows this:

[...]
PCI: Using configuration type 2
PCI: Probing PCI hardware
Starting kswapd v 1.5
Serial driver version 4.26 with no serial options enabled
ttyS00 at 0x03f8 (irq = 4) is a 16550A
ttyS01 at 0x02f8 (irq = 3) is a 16550A
Floppy drive(s): fd0 is 1.44M
FDC 0 is a National Semiconductor PC87306
ncr53c8xx: at PCI bus 0, device 1, function 0
ncr53c8xx: 53c810 detected
[...]

Uhhmmm... I don't quite understand. Am I supossed to start accesing
directly the PCI bus instead of using the BIOS like in the past? Or is
just a minor bug in bios32.c?

See ya!

peloy.-

> --- /mj/linux-2.1/arch/i386/kernel/bios32.c Tue Aug 4 15:19:37 1998
> +++ arch/i386/kernel/bios32.c Tue Aug 4 18:54:11 1998
> @@ -1,7 +1,7 @@
> /*
> * bios32.c - Low-Level PCI Access
> *
> - * $Id: bios32.c,v 1.43 1998/08/03 15:59:20 mj Exp $
> + * $Id: bios32.c,v 1.44 1998/08/04 14:54:56 mj Exp $
> *
> * Copyright 1993, 1994 Drew Eckhardt
> * Visionary Computing
> @@ -65,6 +65,12 @@
> *
> * Jun 19, 1998 : Changed to use spinlocks, so that PCI configuration space
> * can be accessed from interrupts even on SMP systems. [mj]
> + *
> + * August 1998 : Better support for peer host bridges and more paranoid
> + * checks for direct hardware access. Ugh, this file starts to look as
> + * a large gallery of common hardware bug workarounds (watch the comments)
> + * -- the PCI specs themselves are sane, but most implementors should be
> + * hit hard with \hammer scaled \magstep5. [mj]
> */
>
> #include <linux/config.h>
> @@ -331,6 +337,25 @@
> pci_conf2_write_config_dword
> };
>
> +/*
> + * Before we decide to use direct hardware access mechanisms, we try to do some
> + * trivial checks to ensure it at least _seems_ to be working -- we just test
> + * whether bus 00 contains a host bridge (this is similar to checking
> + * techniques used in XFree86, but ours should be more reliable since we
> + * attempt to make use of direct access hints provided by the PCI BIOS).
> + */
> +__initfunc(int pci_sanity_check(struct pci_access *a))
> +{
> + u16 dfn, class;
> +
> + for(dfn=0; dfn < 0x100; dfn++)
> + if (!a->read_config_word(0, dfn, PCI_CLASS_DEVICE, &class) &&
> + class == PCI_CLASS_BRIDGE_HOST)
> + return 1;
> + DBG("PCI: Sanity check failed\n");
> + return 0;
> +}
> +
> __initfunc(static struct pci_access *pci_check_direct(void))
> {
> unsigned int tmp;
> @@ -345,7 +370,8 @@
> outb (0x01, 0xCFB);
> tmp = inl (0xCF8);
> outl (0x80000000, 0xCF8);
> - if (inl (0xCF8) == 0x80000000) {
> + if (inl (0xCF8) == 0x80000000 &&
> + pci_sanity_check(&pci_direct_conf1)) {
> outl (tmp, 0xCF8);
> __restore_flags(flags);
> printk("PCI: Using configuration type 1\n");
> @@ -361,7 +387,8 @@
> outb (0x00, 0xCFB);
> outb (0x00, 0xCF8);
> outb (0x00, 0xCFA);
> - if (inb (0xCF8) == 0x00 && inb (0xCFA) == 0x00) {
> + if (inb (0xCF8) == 0x00 && inb (0xCFA) == 0x00 &&
> + pci_sanity_check(&pci_direct_conf2)) {
> __restore_flags(flags);
> printk("PCI: Using configuration type 2\n");
> return &pci_direct_conf2;
> @@ -920,6 +947,7 @@
> struct pci_bus *b = &pci_root;
> int i;
>
> +#ifdef CONFIG_PCI_DIRECT
> /*
> * Don't search for peer host bridges if we use config type 2
> * since it reads bogus values for non-existent busses and
> @@ -927,6 +955,7 @@
> */
> if (access_pci == &pci_direct_conf2)
> return;
> +#endif
> do {
> int n = b->subordinate+1;
> u16 l;
>

    --

    Eloy A. Paris
    Information Technology Department
    Rockwell Automation Venezuela
    Telephone: +58-2-9432311 Fax: +58-2-9431645

    -
    To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
    the body of a message to majordomo@vger.rutgers.edu
    Please read the FAQ at http://www.altern.org/andrebalsa/doc/lkml-faq.html

- Next message: Allan Hsu: "2.1.X sound?"
- Previous message: Michel Catudal: "Re: No more connection to internet after Kernel 2.1.113"
- Maybe in reply to: Martin Mares: "PCI patch for 2.1.114"
- Next in thread: peloy@ven.ra.rockwell.com: "Re: PCI patch for 2.1.114"