Messages in this thread | | | Date | Fri, 23 Oct 1998 13:47:50 +1000 (EST) | From | Richard Lyons <> | Subject | Re: Kernel freeze on boot (.123-.125) in IDE init |
| |
On Wed, 21 Oct 1998, Daniel Nash wrote:
> I'm currently running 2.1.113, and trying the newest ones. However, > since 2.1.123, it's been freezing during the IDE Partition check. > I've tried a minimal config, w/o scsi sound or anything extraneous > and monolithic. I also have tried 2.1.126-pre2 and 2.1.126-pre2ac1, > with the same results. > > Machine: > 430HX w/Petium 225MMX > using Promise Ultra/33 PCI controller for ide2/3 > > It freezes after displaying 'hda:' in the partition check.
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 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.
- 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/
| |