Hi!
I've got a "Bull Express5800/Series" (dual P3) with a DAC1164 RAID
controller. The mainboard is ServerWorks based and however, 2.4.2-pre3
fails to find the RAID controller. I think there's a problem at
scanning PCI busses behind PCI bridges. Here's the PCI bus layout as
2.4.0-test10 recognizes it:
-+-[01]-+-04.0 Adaptec 7899P
| +-04.1 Adaptec 7899P
| \-0a.0-[02]--+-08.0 Digital Equipment Corporation: Unknown device 1065
| \-09.0 Mylex Corporation eXtremeRAID support Device
\-[00]-+-00.0 Relience Computer CNB20HE
+-00.1 Relience Computer CNB20HE
+-02.0 ATI Technologies Inc 3D Rage IIC 215IIC [Mach64 GT IIC]
+-03.0 Intel Corporation 82557 [Ethernet Pro 100]
+-06.0 Intel Corporation 82557 [Ethernet Pro 100]
+-07.0 Intel Corporation 82557 [Ethernet Pro 100]
+-0f.0 Relience Computer: Unknown device 0200
\-0f.1 Relience Computer: Unknown device 0211
Here's log output from both 2.4.0-test10 (successfully booting) and
2.4.2-pre3 (no success due to missing root fs):
----------------------- 2.4.0-test10 -----------------------
PCI: PCI BIOS revision 2.10 entry at 0xfdb3c, last bus=2
PCI: Using configuration type 1
PCI: Probing PCI hardware
PCI: ServerWorks host bridge: secondary bus 00
PCI: ServerWorks host bridge: secondary bus 01
PCI->APIC IRQ transform: (B1,I4,P0) -> 16
PCI->APIC IRQ transform: (B1,I4,P1) -> 17
PCI->APIC IRQ transform: (B2,I8,P0) -> 20
PCI->APIC IRQ transform: (B0,I2,P0) -> 19
PCI->APIC IRQ transform: (B0,I3,P0) -> 18
PCI->APIC IRQ transform: (B0,I6,P0) -> 26
PCI->APIC IRQ transform: (B0,I7,P0) -> 23
[...]
DAC960: ***** DAC960 RAID Driver Version 2.4.8 of 19 August 2000 *****
DAC960: Copyright 1998-2000 by Leonard N. Zubkoff <[email protected]>
DAC960#0: Configuring Mylex DAC1164P PCI RAID Controller
DAC960#0: Firmware Version: 5.07-0-79, Channels: 3, Memory Size: 16MB
DAC960#0: PCI Bus: 2, Device: 8, Function: 0, I/O Address: Unassigned
DAC960#0: PCI Address: 0xFB110000 mapped at 0xE0800000, IRQ Channel: 20
DAC960#0: Controller Queue Depth: 128, Maximum Blocks per Command: 128
DAC960#0: Driver Queue Depth: 127, Scatter/Gather Limit: 33 of 33 Segments
DAC960#0: Stripe Size: 64KB, Segment Size: 8KB, BIOS Geometry: 255/63
DAC960#0: SAF-TE Enclosure Management Enabled
----------------------- 2.4.2-pre3 -------------------------------
PCI: PCI BIOS revision 2.10 entry at 0xfdb3c, last bus=2
PCI: Using configuration type 1
PCI: Probing PCI hardware
PCI: ServerWorks host bridge: last bus ff
PCI->APIC IRQ transform: (B0,I2,P0) -> 19
PCI->APIC IRQ transform: (B0,I3,P0) -> 18
PCI->APIC IRQ transform: (B0,I6,P0) -> 26
PCI->APIC IRQ transform: (B0,I7,P0) -> 23
Can you give me some advice on how to hack those PCI bridges?
MfG, JBG
--
Fehler eingestehen, Gr??e zeigen: Nehmt die Rechtschreibreform zur?ck!!!
/* Jan-Benedict Glaw <[email protected]> -- +49-177-5601720 */
keyID=0x8399E1BB fingerprint=250D 3BCF 7127 0D8C A444 A961 1DBD 5E75 8399 E1BB
"insmod vi.o and there we go..." (Alexander Viro on linux-kernel)
On Mon Feb 12, 2001 at 14:04:20 +0100, Jan-Benedict Glaw wrote:
> I've got a "Bull Express5800/Series" (dual P3) with a DAC1164 RAID
> controller. The mainboard is ServerWorks based and however, 2.4.2-pre3
> fails to find the RAID controller. I think there's a problem at
> scanning PCI busses behind PCI bridges. Here's the PCI bus layout as
> 2.4.0-test10 recognizes it:
There's was a change in the PCI bus scan code in pre3.
Could you please apply the following patch to arch/i386/kernel/pci-pc.c (against
2.4.1-pre3) and tell us your results? The fixup functions do not seem to
work right now so we'll trust the BIOS...
--- pci-pc.c.orig Tue Feb 13 00:02:50 2001
+++ pci-pc.c Tue Feb 13 00:19:29 2001
@@ -953,9 +953,6 @@
struct pci_fixup pcibios_fixups[] = {
{ PCI_FIXUP_HEADER, PCI_VENDOR_ID_INTEL, PCI_DEVICE_ID_INTEL_82451NX, pci_fixup_i450nx },
{ PCI_FIXUP_HEADER, PCI_VENDOR_ID_INTEL, PCI_DEVICE_ID_INTEL_82454GX, pci_fixup_i450gx },
- { PCI_FIXUP_HEADER, PCI_VENDOR_ID_SERVERWORKS, PCI_DEVICE_ID_SERVERWORKS_HE, pci_fixup_serverworks },
- { PCI_FIXUP_HEADER, PCI_VENDOR_ID_SERVERWORKS, PCI_DEVICE_ID_SERVERWORKS_LE, pci_fixup_serverworks },
- { PCI_FIXUP_HEADER, PCI_VENDOR_ID_SERVERWORKS, PCI_DEVICE_ID_SERVERWORKS_CMIC_HE, pci_fixup_serverworks },
{ PCI_FIXUP_HEADER, PCI_VENDOR_ID_COMPAQ, PCI_DEVICE_ID_COMPAQ_6010, pci_fixup_compaq },
{ PCI_FIXUP_HEADER, PCI_VENDOR_ID_UMC, PCI_DEVICE_ID_UMC_UM8886BF, pci_fixup_umc_ide },
{ PCI_FIXUP_HEADER, PCI_VENDOR_ID_SI, PCI_DEVICE_ID_SI_5513, pci_fixup_ide_trash },
Adam
--
Adam [email protected]
Lackorzynski http://a.home.dhs.org
On Tue, Feb 13, 2001 at 12:38:15AM +0100, Adam Lackorzynski wrote:
Hi Adam!
> On Mon Feb 12, 2001 at 14:04:20 +0100, Jan-Benedict Glaw wrote:
> > I've got a "Bull Express5800/Series" (dual P3) with a DAC1164 RAID
> > controller. The mainboard is ServerWorks based and however, 2.4.2-pre3
> > fails to find the RAID controller. I think there's a problem at
> > scanning PCI busses behind PCI bridges. Here's the PCI bus layout as
> > 2.4.0-test10 recognizes it:
>
> There's was a change in the PCI bus scan code in pre3.
>
> --- pci-pc.c.orig Tue Feb 13 00:02:50 2001
> +++ pci-pc.c Tue Feb 13 00:19:29 2001
> @@ -953,9 +953,6 @@
[Removal of serverworks fixup routines]
That patch cured the problem; the box is up'n'running again. Thanks!
Is there somebody to work on specivic serverworks fixup routines or
should this patch simply go into stock kernel (to not treat serverworks
machines specifically)?
MfG, JBG
--
Fehler eingestehen, Gr??e zeigen: Nehmt die Rechtschreibreform zur?ck!!!
/* Jan-Benedict Glaw <[email protected]> -- +49-177-5601720 */
keyID=0x8399E1BB fingerprint=250D 3BCF 7127 0D8C A444 A961 1DBD 5E75 8399 E1BB
"insmod vi.o and there we go..." (Alexander Viro on linux-kernel)
On Tue Feb 13, 2001 at 12:20:14 +0100, Jan-Benedict Glaw wrote:
> On Tue, Feb 13, 2001 at 12:38:15AM +0100, Adam Lackorzynski wrote:
> > On Mon Feb 12, 2001 at 14:04:20 +0100, Jan-Benedict Glaw wrote:
> > > I've got a "Bull Express5800/Series" (dual P3) with a DAC1164 RAID
> > > controller. The mainboard is ServerWorks based and however, 2.4.2-pre3
> > > fails to find the RAID controller. I think there's a problem at
> > > scanning PCI busses behind PCI bridges. Here's the PCI bus layout as
> > > 2.4.0-test10 recognizes it:
> >
> > --- pci-pc.c.orig Tue Feb 13 00:02:50 2001
> > +++ pci-pc.c Tue Feb 13 00:19:29 2001
> > @@ -953,9 +953,6 @@
> [Removal of serverworks fixup routines]
>
> That patch cured the problem; the box is up'n'running again. Thanks!
Ok, fine.
Since this patch works for Jan, Dan and me I'd suggest putting it into
the kernel and thus removing the fixup routines (Anyone know the reason
why they're there?).
Comments?!
Adam
--
Adam [email protected]
Lackorzynski http://a.home.dhs.org
I believe that, in general, we want working fixup routines so the we don't
have to rely on the BIOS. That said, it's apparent that the ServerWorks
routines are broken. Fixing them is going to be troublesome, given ServerWorks
attitude towards releasing specs. It's on my list of things to try to sort out,
since some of the Netfinities I use are ServerWorks based.
Tim
On Tue, Feb 13, 2001 at 03:41:37PM +0100, Adam Lackorzynski wrote:
> On Tue Feb 13, 2001 at 12:20:14 +0100, Jan-Benedict Glaw wrote:
> > On Tue, Feb 13, 2001 at 12:38:15AM +0100, Adam Lackorzynski wrote:
> > > On Mon Feb 12, 2001 at 14:04:20 +0100, Jan-Benedict Glaw wrote:
> > > > I've got a "Bull Express5800/Series" (dual P3) with a DAC1164 RAID
> > > > controller. The mainboard is ServerWorks based and however, 2.4.2-pre3
> > > > fails to find the RAID controller. I think there's a problem at
> > > > scanning PCI busses behind PCI bridges. Here's the PCI bus layout as
> > > > 2.4.0-test10 recognizes it:
> > >
> > > --- pci-pc.c.orig Tue Feb 13 00:02:50 2001
> > > +++ pci-pc.c Tue Feb 13 00:19:29 2001
> > > @@ -953,9 +953,6 @@
> > [Removal of serverworks fixup routines]
> >
> > That patch cured the problem; the box is up'n'running again. Thanks!
>
> Ok, fine.
>
> Since this patch works for Jan, Dan and me I'd suggest putting it into
> the kernel and thus removing the fixup routines (Anyone know the reason
> why they're there?).
>
> Comments?!
>
>
> Adam
> --
> Adam [email protected]
> Lackorzynski http://a.home.dhs.org
--
Tim Wright - [email protected] or [email protected] or [email protected]
IBM Linux Technology Center, Beaverton, Oregon
Interested in Linux scalability ? Look at http://lse.sourceforge.net/
"Nobody ever said I was charming, they said "Rimmer, you're a git!"" RD VI
On Tue, 13 Feb 2001, Tim Wright wrote:
> I believe that, in general, we want working fixup routines so the we don't
> have to rely on the BIOS. That said, it's apparent that the ServerWorks
> routines are broken. Fixing them is going to be troublesome, given ServerWorks
> attitude towards releasing specs. It's on my list of things to try to sort out,
> since some of the Netfinities I use are ServerWorks based.
We can get tech info on ServerWorks... just ask specific questions, and
hardware contacts etc. will do the rest.
Jeff
Does it make sense to try and keep up with the latest and greatest in
chipsets
when there is a hardware independent way of doing things? You may be able
to
get information on current chipsets, but every time something changes, the
kernel may be broken for a time. If we rely on the BIOS, the kernel can
stay
out of the chipset information race. I understand the reluctance to depend
on BIOS in general but isn't it safe to say that systems using the
ServerWorks
chipsets in question are likely servers with a non-broken BIOS?
I can tell you that if the BIOS doesn't report this stuff right on a
ProLiant
server, it would never make it out the door. It would break too many things
to go unnoticed. From this standpoint, the kernel is less likely to break
if
it relies on the BIOS rather than assuming some particular chipset design
that can easily change in the future. This is a fundamental reason for the
BIOS's existence.
Dan
-----Original Message-----
From: Jeff Garzik [mailto:[email protected]]
Sent: Tuesday, February 13, 2001 11:12 AM
To: Tim Wright
Cc: Adam Lackorzynski; Jan-Benedict Glaw; [email protected];
Zink, Dan
Subject: Re: PCI bridge handling 2.4.0-test10 -> 2.4.2-pre3
On Tue, 13 Feb 2001, Tim Wright wrote:
> I believe that, in general, we want working fixup routines so the we don't
> have to rely on the BIOS. That said, it's apparent that the ServerWorks
> routines are broken. Fixing them is going to be troublesome, given
ServerWorks
> attitude towards releasing specs. It's on my list of things to try to sort
out,
> since some of the Netfinities I use are ServerWorks based.
We can get tech info on ServerWorks... just ask specific questions, and
hardware contacts etc. will do the rest.
Jeff
On Tue, 13 Feb 2001, Zink, Dan wrote:
> Does it make sense to try and keep up with the latest and greatest in
> chipsets
> when there is a hardware independent way of doing things? You may be able
> to
> get information on current chipsets, but every time something changes, the
> kernel may be broken for a time. If we rely on the BIOS, the kernel can
> stay
> out of the chipset information race. I understand the reluctance to depend
> on BIOS in general but isn't it safe to say that systems using the
> ServerWorks
> chipsets in question are likely servers with a non-broken BIOS?
>
> I can tell you that if the BIOS doesn't report this stuff right on a
> ProLiant
> server, it would never make it out the door. It would break too many things
> to go unnoticed. From this standpoint, the kernel is less likely to break
> if
> it relies on the BIOS rather than assuming some particular chipset design
> that can easily change in the future. This is a fundamental reason for the
> BIOS's existence.
It's common knowledge that Linux is often better for hardware testing
than Microsoft's pitiful ACT software. Intel and other companies have
discovered hardware flaws that Linux exposes which all the Windows
(and ACT) testing does not. (see early P4's...) Similarly, most
BIOS out there work wonderfully with Windows but often have quirks
with Linux. An overall policy of BIOS independence minimizes if not
eliminates the chances of such quirks affecting Linux users.
Getting a vendor to fix a broken BIOS is like trying to get a reluctant
cow out of the barn: oftimes is just doesn't happen, especially if
it is a Linux-only problem. Toshiba laptops have had broken ACPI
tables for ages, but I have yet to see any BIOS updates regardless
of the number of reports sent to Toshiba.
Now, that said, in x86 land, we actually -do- allow the BIOS to
setup the PCI bus for us, and for the most part, we leave that setup
completely alone. grep for 'pcibios_assign_all_busses'... and note
it is defined to zero for x86, and 1 for alpha.
Finally, minimizing BIOS dependencies is also important for applications
like linuxbios -- an embedded firmware that initializes the CPU and
DRAM, and then passes control to a Linux kernel to do the rest.
Regards,
Jeff