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.047 / U:0.044 seconds]
    ©2003-2016 Jasper Spaans. hosted at Digital OceanAdvertise on this site