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!!Received on Wed Dec 24 2003 - 02:28:26 UTC
This archive was generated by hypermail 2.4.0 : Wed May 19 2021 - 11:37:35 UTC