From: Ralf Baechle <ralf@linux-mips.org>
To: Giuseppe Sacco <giuseppe@eppesuigoccas.homedns.org>
Cc: linux-mips@linux-mips.org
Subject: Re: pci-to-pci bridges on ip32
Date: Thu, 13 Sep 2007 14:46:21 +0100 [thread overview]
Message-ID: <20070913134621.GB9125@linux-mips.org> (raw)
In-Reply-To: <1189687699.7506.18.camel@scarafaggio>
On Thu, Sep 13, 2007 at 02:48:19PM +0200, Giuseppe Sacco wrote:
> Il giorno gio, 13/09/2007 alle 00.20 +0100, Ralf Baechle ha scritto:
> [...]
> > Can you give a few more details on the sympthom with this card on IP32?
> >
> > Ralf
>
> I have an SGI O2 with an R5000 CPU, 1 SCSI CD-ROM, 2 SCSI disks, 128Mb
> of RAM and a PCI ethernet card. I replaced the PCI card with this new
> board, but it seems the board is listed but otherwise ignored. The only
> trace is in lspci output. There isn't a list of devices in the other
> side of this PCI-to-PCI chip.
>
> # lspci
> 00:01.0 SCSI storage controller: Adaptec AIC-7880U
> 00:02.0 SCSI storage controller: Adaptec AIC-7880U
> 00:03.0 PCI Bridge: Netmos technology Unknown device 9250
> (The card vendor and product are IDs 9710:9250.)
>
> When I plug the card on an i386 machine, it is recognised since lspci
> display the card and all three devices present on the same card (devices
> accessible via the PCI-to-PCI bridge). All these devices are available
> to udev, so udev start all relevant drivers.
>
> I started checking my kernel config. Do I have to activate any specific
> CONFIG_?? option in order to use such a card (beside the driver for all
> devices).
I got a quad Tulip card on my Malta here and that works fine:
# lspci
00:0a.0 ISA bridge: Intel Corp. 82371AB/EB/MB PIIX4 ISA (rev 02)
00:0a.1 IDE interface: Intel Corp. 82371AB/EB/MB PIIX4 IDE (rev 01)
00:0a.2 USB Controller: Intel Corp. 82371AB/EB/MB PIIX4 USB (rev 01)
00:0a.3 Bridge: Intel Corp. 82371AB/EB/MB PIIX4 ACPI (rev 02)
00:0b.0 Ethernet controller: Advanced Micro Devices [AMD] 79c970 [PCnet LANCE] (rev 43)
00:0c.0 Multimedia audio controller: Cirrus Logic Crystal CS4281 PCI Audio (rev 01)
00:11.0 Host bridge: Unknown device df53:0001 (rev 97)
00:12.0 PCI bridge: Digital Equipment Corporation DECchip 21154 (rev 05)
00:13.0 Ethernet controller: Digital Equipment Corporation DECchip 21040 [Tulip] (rev 23)
01:04.0 Ethernet controller: Digital Equipment Corporation DECchip 21142/43 (rev 41)
01:05.0 Ethernet controller: Digital Equipment Corporation DECchip 21142/43 (rev 41)
01:06.0 Ethernet controller: Digital Equipment Corporation DECchip 21142/43 (rev 41)
01:07.0 Ethernet controller: Digital Equipment Corporation DECchip 21142/43 (rev 41)
#
> I am using kernel 2.6.18 on both machines, as shipped with Debian
> stable.
I wonder if somebody hacked that kernel to just scan the PCI bus. That
means it would trust whatever the ARCS firmware has setup and ARCS is
definately broken, doesn't know how to handle PCI-to-PCI bridges and will
just skip over them. Exactly what you observe.
Ralf
prev parent reply other threads:[~2007-09-13 13:46 UTC|newest]
Thread overview: 4+ messages / expand[flat|nested] mbox.gz Atom feed top
2007-09-11 18:55 pci-to-pci bridges on ip32 Giuseppe Sacco
2007-09-12 23:20 ` Ralf Baechle
2007-09-13 12:48 ` Giuseppe Sacco
2007-09-13 13:46 ` Ralf Baechle [this message]
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=20070913134621.GB9125@linux-mips.org \
--to=ralf@linux-mips.org \
--cc=giuseppe@eppesuigoccas.homedns.org \
--cc=linux-mips@linux-mips.org \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.