More info: ATA hang on resume

I did some more tracing on this and found that the reset of ata0 is indeed
hanging.  My machine does not have an APIC, just a simple PIC laptop (IBM
T23).  I've disabled most devices and am not using atapi-cam.

atapci0_at_pci0:31:1:      class=0x01018a card=0x02201014 chip=0x248a8086 rev=0x02 hdr=0x00
    vendor   = 'Intel Corporation'
    device   = '82801CAM (ICH3-M) UltraATA/100 EIDE Controller'

atapci0: <Intel ICH3 UDMA100 controller> port 0x1860-0x186f,0x374-0x377,0x170-0x177,0x3f4-0x3f7,0x1f0-0x1f7 at device 31.1 on pci0
ata0: at 0x1f0 irq 14 on atapci0
ata0: [MPSAFE]
ata1: at 0x170 irq 15 on atapci0
ata1: [MPSAFE]

ad0: 19077MB <IC25N020ATCS04-0> [41344/15/63] at ata0-master UDMA100
acd0: CDRW <UJDA720 DVD/CDRW> at ata1-master PIO4

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.

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.

Thanks,
-Nate