From: "Shai Fultheim" <shai@ftcon.com>
To: <linux-ide@vger.kernel.org>
Cc: <linux-kernel@vger.kernel.org>
Subject: Multiple (ICH3) IDE-controllers in a system
Date: Tue, 4 May 2004 15:13:29 -0700 [thread overview]
Message-ID: <200405042213.BLD39867@ms6.netsolmail.com> (raw)
Hi,
I am working on an IO-robust custom-made PC server, which runs the Linux
kernel. The machine is working very nicely with 2.4 kernels, but we
recently found out that in 2.6 it couldn't see all IDE controllers.
In Linux 2.6.x pcibios_fixups table (in arch/i386/pci/fixup.c), use the
pci_fixup_ide_trash() quirk for Intel's ICH3 (my case specifically
8086:248b). That quirk wasn't in use for ICH3 by the 2.4.x kernels. The
result of the change is that the system, which has multiple ICH3's can't use
any of the IDE controllers beside the one on the first ICH3 (again, that
worked in 2.4 kernels).
Is there a real reason to call that quirk? If there is not, why are you
calling that quirk? If there is, can I suggest that the quirk will handle
only the first ICH3 (i.e. add check in the quirk that it is called for the
first time only). This is better than "loosing" all these IDE controllers
in the case their BARs set right.
Blow references for bare 2.6.5 kernel:
Code walkup starts with pci_scan_single_device() at
http://lxr.linux.no/source/drivers/pci/probe.c?v=2.6.5#L590 which calls to
pci_fixup_device() (line 601) which in turn use the quirks table at
http://lxr.linux.no/source/arch/i386/pci/fixup.c?v=2.6.5#L190 (my chipset is
in line 248). The quirks table for ICH3 use pci_fixup_ide_trash()at
http://lxr.linux.no/source/arch/i386/pci/fixup.c?v=2.6.5#L90 - this reset
the BARs for the device. Resetting the all (4) BARs of (ICH3) IDE
controllers will cause them to use the defaults BARs (0x170, 0x1f0) in
ide_hwif_configure() at
http://lxr.linux.no/source/drivers/ide/setup-pci.c?v=2.6.5#L420. This will
fail with any subsequent (ICH3) IDE controllers (two devices can't use the
same ports).
I'm not sure if ICH3 needs to reset its BARs at all, but if it is, I suggest
making sure pci_fixup_ide_trash() reset BARs only for first time being
called. In that way subsequent IDE controllers will use the BIOS BARs
(which we set fine, and worked GREAT at 2.4.x), as said above, this is
better than "loosing" all the other IDE controllers in the case their BARs
set right.
Thanks in advance,
Shai.
_________________________
Shai Fultheim
FT Consulting
Mobile: +1 (408) 480-1612
Fax: +1 (501) 647-4113
E-Mail: shai@ftcon.com
Web: www.ftcon.com
next reply other threads:[~2004-05-04 22:13 UTC|newest]
Thread overview: 5+ messages / expand[flat|nested] mbox.gz Atom feed top
2004-05-04 22:13 Shai Fultheim [this message]
2004-05-05 15:16 ` Multiple (ICH3) IDE-controllers in a system Bartlomiej Zolnierkiewicz
2004-05-06 6:45 ` Vojtech Pavlik
2004-05-06 19:18 ` Shai Fultheim
2004-05-06 21:05 ` Shai Fultheim
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=200405042213.BLD39867@ms6.netsolmail.com \
--to=shai@ftcon.com \
--cc=linux-ide@vger.kernel.org \
--cc=linux-kernel@vger.kernel.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 a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox