[lkml]   [2003]   [Nov]   [30]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
Messages in this thread
    SubjectRe: Silicon Image 3112A SATA trouble
    Bartlomiej Zolnierkiewicz wrote:
    > On Sunday 30 of November 2003 18:19, Prakash K. Cheemplavam wrote:
    >>Bartlomiej Zolnierkiewicz wrote:
    >>>In 2.6.x there is no max_kb_per_request setting in
    >>>/proc/ide/hdx/settings. Therefore
    >>> echo "max_kb_per_request:128" > /proc/ide/hde/settings
    >>>does not work.
    >>>Hmm. actually I was under influence that we have generic ioctls in 2.6.x,
    >>>but I can find only BLKSECTGET, BLKSECTSET was somehow lost. Jens?
    >>>Prakash, please try patch and maybe you will have 2 working drivers now
    >>OK, this driver fixes the transfer rate problem. Nice, so I wanted to do
    >>the right thing, but it didn't work, as you explained... Thanks.
    > Cool.
    >>Nevertheless there is still the issue left:
    >>hdparm -d1 /dev/hde makes the drive get major havoc (something like:
    >>ide: dma_intr: status=0x58 { DriveReady, SeekCOmplete, DataRequest}
    >>ide status timeout=0xd8{Busy}; messages taken from swsups kernal panic
    >>). Have to do a hard reset. I guess it is the same reason why swsusp
    >>gets a kernel panic when it sends PM commands to siimage.c. (Mybe the
    >>same error is in libata causing the same kernel panic on swsusp.)
    >>Any clues?
    > Strange. While doing 'hdparm -d1 /dev/hde' the same code path is executed
    > which is executed during boot so probably device is in different state or you
    > hit some weird driver bug :/.
    > And you are right, thats the reason why swsusp panics.

    I think the bug is, the driver specifically doesn't like my
    controller-sata converter-hd combination. As I stated in my very first
    message, on HD access the siimage.c constantly calls:

    static int siimage_mmio_ide_dma_test_irq (ide_drive_t *drive)
    ide_hwif_t *hwif = HWIF(drive);
    unsigned long base = (unsigned long)hwif->hwif_data;
    unsigned long addr = siimage_selreg(hwif, 0x1);

    if (SATA_ERROR_REG) {
    u32 ext_stat = hwif->INL(base + 0x10);
    u8 watchdog = 0;
    if (ext_stat & ((hwif->channel) ? 0x40 : 0x10)) {
    // u32 sata_error = hwif->INL(SATA_ERROR_REG);
    // hwif->OUTL(sata_error, SATA_ERROR_REG);
    // watchdog = (sata_error & 0x00680000) ? 1 : 0;
    //#if 1
    // printk(KERN_WARNING "%s: sata_error = 0x%08x, "
    // "watchdog = %d, %s\n",
    // drive->name, sata_error, watchdog,
    // __FUNCTION__);

    } else {

    Thats why I commented above portions out, otherwise my dmesg gets
    flooded. What is strange, when I compile the kernel to *not* enable DMA
    at boot, the siimage DMA gets enabled nevertheless, so I am not sure
    whether hdparm -d1 and kernel boot take the same path to enable DMA. It
    seems some sort of hack within siimage.c is used to enable DMA on my
    drive. Remember, I have no native SATA drive, maybe thats the problem.


    To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
    the body of a message to
    More majordomo info at
    Please read the FAQ at

     \ /
      Last update: 2005-03-22 13:59    [W:0.024 / U:35.504 seconds]
    ©2003-2017 Jasper Spaans. hosted at Digital OceanAdvertise on this site