It's the ISA/IDE part of the Intel chips he said he had, 440BX.
A quick web-search will confirm that while Intel doesn't appear
to officially call the 82371AB PIIX4 controller "South Bridge", many
different independent source do call it this. Presumably it's some kind of
project name or something like that. (AltaVista Advanced Search, "South
Bridge" NEAR Intel)
A quick check on ASUS web-site (www.asus.com.tw) confirms that ASUS P2B-DS
is a 440BX based dual motherboard, with onboard Adaptec SCSI. It also
tells us that ASUS is one of the many firms who call the 440BX ISA/IDE
part "PIIX4E South Bridge"
> If this is an Alladin base mainboard, I have only just begun to review the
> data sheets. This any and all ide-timing issue are still a mystery.
It doesn't look like ASUS has any non-Intel PII/PPro based card...
They DO have non-Intel P5/Socket7 boards (various, including Ali Aladin
5), but you couldn't possibly put the Celeron 266 he claims to have into
these.
> The next thing that bothers me is the 'C' firmware revision MPC3084AT.
> Since the via82c586 base UDMA controls hang hard with the MPC3043AT 4.3G
> Fujitsu drives and not MPB3043AT 4.3G drives with 'B' firmware revision,
> there is a potential problem to check into also. This assumption is based
> upon the similar methodology for setting chipset timings on VIA boards and
> ALI boards.....the values an close but discrete locations in the
> pci-config space differ.
But why would that affect *hda*, which is a Quantum Fireball on the
main-board controller, when all of the Fujitsu drives are on the Promise
Ultra33 controller?
> > I've been able to stop this by commenting out line 168 in
> > drivers/block/ide-pci.c:
> > pci_write_config_byte(dev, PCI_ROM_ADDRESS, PCI_ROM_ADDRESS_ENABLE);
>
> What is the chipset base for your ASUS board?
According to the part you quoted it's a ASUS P2B-DS with a 440BX...
ide-pci.c have somewhat different line-numbers in the 2.1.126-pre2ac2 I
use, but it was easy to find the correct line. In my version that line is
executed for ARTOP_ATP850UF and PROMISE_20246, which sounds like it
*could* be his Promise Ultra33? (At least it's the right producer...)
Now, unless it's actually run for the WRONG IDE chip-set I don't see how
it could affect hda, but then again, weird things isn't that unusual in PC
hardware :-)
> > Doing a binary search test with the kernels showed the problem occured
> > at 2.1.122. Piecemeal application of patch-2.1.122 revealed that
> > commenting out ide_special_settings() stopped the DMA disable. Further
> > fiddling showed just commenting out line 168 did the same job. Last week
> > I wanted to try the new RAID stuff, and patched a virgin 2.1.125 with
> > ftp.kernel.org/pub/linux/daemons/raid/alpha/raid0145-19981005-C-2.1.124.gz,
> > adjusting for 124/125 differences. Surprisingly, this kernel didn't
> > disable DMA during the partition check, so I did some more testing.
Sounds more and more like some kind of timing race. The patch does some
minor changes in various IDE files (altought not in ide-pci.c), but none
that appears to related to this.
Anyway, it's definitely worth checking for BIOS upgrades for both the
motherboard (www.asus.com.tw) and the Promise card (the MB BIOS sounds
more likely, but...).
Just checking, that 266 MHz Celeron isn't OVERCLOCKED? And the the PCI bus
is running on 33 MHz. Otherwise all bets are of...
-
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.tux.org/lkml/