> I'm having similar problems with a box here, although the machine doesn't
> freeze - it just disables DMA and (most of the time) continues on its way.
> 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);
>
> The long story: I have an ASUS P2B-DS (100MHz 440BX AGPset Mainboard with
> PIIX4E South Bridge) with a single Celeron 266MHz processor - hda is
> a 2.1G Quantum Fireball, and there's a Promise Ultra33 plugged in with
> 3 8.4G Fujitsu drives (MPC3084AT) as hde/hdg/hdh. It'd been running
> 2.0.34 fine for a month when I upgraded to 2.1.108. A couple of weeks
> later, Linus announced 2.1.125 as a precursor to 2.2, so I upgraded again
> to do testing. When 2.1.125 booted, it disabled DMA on hda at the
> partition check:
>
> Partition check:
> hda:hda: dma_intr: bad DMA status
> hda: dma_intr: status=0x50 { DriveReady SeekComplete }
> hda: dma_intr: bad DMA status
> hda: dma_intr: status=0x50 { DriveReady SeekComplete }
> hda: dma_intr: bad DMA status
> hda: dma_intr: status=0x50 { DriveReady SeekComplete }
> hda: dma_intr: bad DMA status
> hda: dma_intr: status=0x50 { DriveReady SeekComplete }
> hda: DMA disabled
Since 'hda' is attached to the onboard ide-chipset and ide-pci.c: line 168
is only related to two chipsets (PDC20246 and AEC6210), I can not fully
understand the relation between the two controller issues.
Second, "PIIX4E South Bridge" ???
"PIIX4" :: sounds like Intel
"South Bridge" :: sounds like Alladin
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.
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.
> 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?
> ide0: reset: success
> hda1 hda2 < hda5 hda6 hda7 >
> hde: unknown partition table
> hdg: hdg1
> hdh: hdh1
>
> 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.
>
> The base configuration is sparse - the usual stuff, SCSI_AIC7XXX,
> NE2K_PCI, MD, SMP. Kernels 2.1.108 to 2.1.121 work fine. Kernels
> 2.1.122 to 2.1.125 and 2.1.125ac1 all disable DMA at the partition check.
> I have had a couple of instances where DMA was not disabled, but
> /sbin/init was unable to read /etc/inttab and prompted for a run level, at
> which the box hung (presumably trying to read something off the disk).
>
> I have tried the following on 2.1.125+AIC7XXX+NE2KPCI+MD+SMP:
> disables DMA doesn't disable DMA
> comment out line 168
> CONFIG_PARPORT{,_PC}=y
> MD-0.90.0
> uniprocessor
> unplug ultra33
> unplug fujitsu drives
> * replace ln 168 with nops and/or __delay
> __delay before ln 168
> disable DMA in BIOS
>
>
> * Thinking that the bad DMA status in ide_dma_intr() might be caused by
> memory footprint/alignment/cache effects, I replaced the call to
> pci_write_config_byte() with enough nop()'s, and later with __delay() and
> nop()'s, to make System.map between 2.1.125 and the patched version the
> same.
>
> The Ultra33 has been tried in 3 PCI slots, and 4 IDE cables connecting
> ide0 to hda have been used, none of which were over over 18". The current
> one is 16" long.
>
> If DMA is disabled, the are no other problems. However, since hda has
> been running trouble-free with DMA in earlier kernels, I'd like to find
> out what's making it fail now. The machine isn't due for placement
> for a few weeks yet, so any suggestions for testing/patches are welcome.
>
> Cheers,
> Rick.
>
Cheers,
Andre Hedrick
The IDE-FNG for Linux
The APC UPS Specialist for Linux
http://www.dyer.vanderbilt.edu/server/udma/
http://www.dyer.vanderbilt.edu/server/apcupsd/ SUSPENDED
-
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/