Date: Wed, 24 Dec 2003 12:27:20 +0100 (CET) From: Soren Schmidt <sos@spider.deepcore.dk> To: Nate Lawson <nate@root.org> Cc: current@FreeBSD.ORG Subject: Re: More info: ATA hang on resume Message-ID: <200312241127.hBOBRKd6001398@spider.deepcore.dk> In-Reply-To: <20031223172258.B93254@root.org>
next in thread | previous in thread | raw e-mail | index | archive | help
It seems Nate Lawson wrote:
> After putting in some debugging prints, I found that the hang is
> happening in this call stack:
>
> ata_controlcmd(ATA_SF_SETXFER) ata-chipset.c:874
> ata_intel_new_setmode() ata-chipset.c:851
> ch->device[MASTER].setmode(..., ATA_PIO_MAX) ata-all.c:681
> ata_identify_devices() ata-all.c:276
> ata_reinit() ata-all.c:231
>
> I don't know what in ata_controlcmd() is hanging. If I remove the call to
> setting ATA_PIO_MAX so I just do the call to set ATA_DMA_MAX, it still
> hangs in that call in the same place. Are you sure it's legal to call
> ATA_SF_SETXFER with a mode of ATA_PIO_MAX (0x0f) or ATA_DMA_MAX (0x4f)?
> I tried changing these calls to set PIO4 and UDMA5 just in case, but no
> luck.
It hangs because the command newer finishes, it there is no interrupt
getting through (this is the first time interrupts are getting used
after the resume).
> What information can I find to help you track down this regression? You
> fixed suspend/resume early October (I think) although it broke again
> sometime in November.
I haven't changed anything in this regard since, so the problem is probably
a side effect of other changes in the system (APIC, interrupt code, ???)
-Søren
Yes I know it works under windows!!
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?200312241127.hBOBRKd6001398>