lkml.org 
[lkml]   [1998]   [Oct]   [22]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
 
Messages in this thread
/
Date
From
SubjectRe: 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/

\
 
 \ /
  Last update: 2005-03-22 13:45    [W:0.895 / U:0.420 seconds]
©2003-2020 Jasper Spaans|hosted at Digital Ocean and TransIP|Read the blog|Advertise on this site