lkml.org 
[lkml]   [2009]   [Jun]   [23]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
 
Messages in this thread
    /
    From
    SubjectRe: cmd64x: irq 14: nobody cared - system is dreadfully slow
    Date
    On Tuesday 23 June 2009, you wrote:
    > We might need to bisect this one. But Frans, just for the record
    > could you simply test reverting just that hunk? Thanks!

    I'm way ahead of you :-)

    Instead of a bisect [1] I decided to first see if some printks in both .26
    and .31 would show anything useful.

    With 2.6.31 and code included below I get:
    hda: ST34342A, ATA DISK drive
    FJP: id_dma_bug 0x7: &4: 0x0-0x4 no error
    hda: MWDMA2 mode selected
    hdc: Maxtor 6E040L0, ATA DISK drive
    hdd: CD-ROM 56X/AKH, ATAPI CD/DVD-ROM drive
    hdc: host max PIO5 wanted PIO255(auto-tune) selected PIO4
    FJP: ID_FIELD_VALID: 0x7 (true)
    FJP: id_dma_bug 0x7: &4: 0x0-0x4 no error
    hdc: MWDMA2 mode selected
    hdd: host max PIO5 wanted PIO255(auto-tune) selected PIO4
    FJP: ID_FIELD_VALID: 0x2 (true)
    FJP: id_dma_bug 0x2: &2: 0x1-0x1 bad modes <-------------
    hdd: bad DMA info in identify block

    Note that this included a complete revert of 8d64fcd9 (with minor conflict
    resolved).

    Here's the same output with 2.6.26.3 with equivalent debug statements:
    hda: ST34342A, ATA DISK drive
    FJP: id_dma_bug 0x7: &4: 0x0-0x0 no error
    hda: MWDMA2 mode selected
    hdc: Maxtor 6E040L0, ATA DISK drive
    hdd: CD-ROM 56X/AKH, ATAPI CD/DVD-ROM drive
    FJP: id_dma_bug 0x7: &4: 0x0-0x0 no error
    hdc: MWDMA2 mode selected
    FJP: id_dma_bug 0x2: &2: 0x0-0x0 no error <-------------
    hdd: MWDMA2 mode selected

    So it seems to me that in 2.6.26 something was broken in the way these ID
    fields were handled, at least in this check. This is now fixed (possibly
    by the changes around 5b90e990..48fb2688) and *that* causes the
    regression. Note that the hard disks are also affected.

    If I'm correct I guess that supports Bart's patch to just remove the whole
    thing. But did this only affect the id_dma_bug check or also the use of
    these fields elsewhere?

    Cheers,
    FJP

    [1] I don't have a crossbuild environment for sparc, so a bisect would be
    painful with 300MHz; I at least have plenty memory luckily.

    int ide_id_dma_bug(ide_drive_t *drive)
    {
    u16 *id = drive->id;

    printk("FJP: id_dma_bug 0x%x:", id[ATA_ID_FIELD_VALID]);
    if (id[ATA_ID_FIELD_VALID] & 4) {
    printk(" &4: 0x%x-0x%x", (id[ATA_ID_UDMA_MODES] >> 8),
    (id[ATA_ID_MWDMA_MODES] >> 8));
    if ((id[ATA_ID_UDMA_MODES] >> 8) &&
    (id[ATA_ID_MWDMA_MODES] >> 8)) {
    printk(" bad modes");
    goto err_out;
    }
    } else if (id[ATA_ID_FIELD_VALID] & 2) {
    printk(" &2: 0x%x-0x%x", (id[ATA_ID_MWDMA_MODES] >> 8),
    (id[ATA_ID_SWDMA_MODES] >> 8));
    if ((id[ATA_ID_MWDMA_MODES] >> 8) &&
    (id[ATA_ID_SWDMA_MODES] >> 8)) {
    printk(" bad modes");
    goto err_out;
    }
    }
    printk(" no error\n");
    return 0;
    err_out:
    printk("\n");
    printk(KERN_ERR "%s: bad DMA info in identify block\n",
    drive->name);
    return 1;
    }


    \
     
     \ /
      Last update: 2009-06-23 17:01    [W:0.023 / U:90.036 seconds]
    ©2003-2016 Jasper Spaans. hosted at Digital OceanAdvertise on this site