I did use nightly 2008-10-23 bits, which already is post snv_101.
It includes these putbacks
6753758 ata driver doesn't work in snv_99 (older systems only?)
6752338 ata driver hangs in b99 on Toshiba Tecra A9
But I still see the issue with ata dma hanging the laptop after s3 resume.
> Try snv_101, in this build the driver will save
> the DMA mode for device before suspend, and when
> resuming, it will restore the DMA mode setting
> for device.
Hmm, I just checked the changes for the above two bug fixes.
I do see that the current DMA mode setting is saved to ad_dma_cap / ad_dma_mode,
and that there is code for *ATAPI* devices to restore DMA mode from these
fields.
But apparently there is no such code to restore the saved DMA mode for
non-ATAPI devices. Note that the DMA issue on my Tecra S1 exists for
the ATA HDD.
I think we also need ata_reset_dma_mode(). Note that my P-ATA disk
is using UDMA 5 before s3 suspend, and the drive does fall back to
MWDMA 2 mode after s3 resume.
ata_resume_drive() does use ata_set_dma_mode(), but for my Tecra S1,
ata_set_dma_mode() is basically a no-op. The original code is looking at
the device dma settings from the initial boot and sees UDMA 5, so does
nothing. Even when I fix ata_resume_drive() / ata_set_dma_mode() to use
the current dma settings at the time of s3 resume, the code would
see MWDMA 2 and still does nothing, because a dma mode (but not the correct
one) is already selected.
A new ata_reset_dma_mode() function that would unconditionally restore the
saved DMA mode for an ATA device would fix the problem for my Tecra S1
with a FUJITSU MHT2080 80GB P-ATA hdd.
> Thanks,
> Ada
>
> Juergen Keil wrote:
> > Hi,
> >
> >
> > One issue with using S3 suspend/resume on my Tecra S1 laptop is that
> > after a resume the first access to the p-ata hdd hangs the system.
> >
> > Just like 6742621, but I'm using nightly 2008-10-23 bits (post snv_101).
> >
> >
> > Apparently the problem is that UDMA 5 needs to be restored for the p-ata hdd
> > (fujitsu 80gb), but it isn't.
> >
> >
> > When I change the code in
usr/src/uts/intel/io/dktp/controller/ata/ata_common.c
> > ata_set_dma_mode() to always set dma mode, s3 resume starts to work just
fine.
> >
> > Basically, I remove this if ():
> >
> > 3819 /* Return if DMA mode is already selected */
> > 3820 if (((aidp->ai_validinfo & ATAC_VALIDINFO_83) &&
> > 3821 (aidp->ai_ultradma & ATAC_UDMA_SEL_MASK)) ||
> > 3822 (aidp->ai_dworddma & ATAC_MDMA_SEL_MASK))
> > 3823 return (rval);
> >
> >
> > It seems the hdd's power on defaults is MWDMA 2. The BIOS appears to
> > configure UDMA 5 before the OS (Solaris) is booted.
> >
> > But on S3 resume, we resume with the p-ata hdd set to MWDMA 2. And the
> > ICH4-M chipset in the laptop is set to UDMA. The above if () returns,
> > without setting UDMA 5 for the hdd. On the next DMA the laptop hangs.
> >
> >
> >
> > While looking at the ata resume code, I noticed something that appears to
> > be broken:
> >
> > 3523 /*
> > 3524 * resume the hard drive
> > 3525 */
> > 3526 static void
> > 3527 ata_resume_drive(ata_drv_t *ata_drvp)
> > 3528 {
> > 3529 ata_ctl_t *ata_ctlp = ata_drvp->ad_ctlp;
> > 3530 int drive_type;
> > 3531 struct ata_id id;
> > 3532
> > 3533 ADBG_TRACE(("ata_resume_drive entered\n"));
> > 3534
> > 3535 drive_type = ata_drive_type(ata_drvp->ad_drive_bits,
> > 3536 ata_ctlp->ac_iohandle1, ata_ctlp->ac_ioaddr1,
> > 3537 ata_ctlp->ac_iohandle2, ata_ctlp->ac_ioaddr2,
> > 3538 &id);
> > 3539 if (drive_type == ATA_DEV_NONE)
> > 3540 return;
> > 3541
> > 3542 if (!ATAPIDRV(ata_drvp)) {
> > 3543 /* Reset Ultra DMA mode */
> > 3544 (void) ata_set_dma_mode(ata_ctlp, ata_drvp);
> > 3545 if (!ata_disk_setup_parms(ata_ctlp, ata_drvp))
> > 3546 return;
> > 3547 } else {
> > 3548 (void) atapi_init_drive(ata_drvp);
> >
> >
> >
> > When we resume, line 3535 gets the hdd's current settings using an ata
> > identify command and stores the result in the local variable "id", line
3531.
> >
> > But when we call ata_set_dma_mode() at line 3544, the ata_drvp pointer
> > still contains the ata device's configuration settings that was read during
> > drive attach at the initial boot - not the current settings at S3 resume
> > time that were read into the local variable "id", line 3531.
> >
> > Btw, in the atapi case, line 3548, atapi_id_update() gets called which will
> > update the id data contained in the ata_drvp stucture before we call
> > ata_set_dma_mode(), so that in the atapi case ata_set_dma_mode() will work
> > with current configuration data of the atapi device at the time of the
> > s3 resume.
> >
> >
> > Isn't there a bcopy missing before line 3544, that updates the ata_id
> > data in the ata_drvp structure to the current values? Or maybe pass
> > "&ata_drvp->ad_id" at line 3538, instead of using a local ata_id copy?
> > So that ata_set_dma_mode() uses the hw's settings at s3 resume time
> > when re-enabling dma mode...
