Comment 9 for bug 100114

Funny how you can arrive at the same point from different directions. I noticed in your tracing that int_cnt had far more interrupts (for the same file) just after resume than when the module had been freshly loaded (389 vs 11) and had traced through to the posbuf from struct azx_dev:

hda_intel.c:257
 struct azx_dev {
  u32 *posbuf; /* position buffer pointer */

hda_intel.c:334
 struct snd_dma_buffer posbuf;

/include/sound/memalloc.h:57

 struct snd_dma_buffer {
  struct snd_dma_device dev; /* device type */
  unsigned char *area; /* virtual pointer */
  dma_addr_t addr; /* physical address */
  size_t bytes; /* buffer size in bytes */
  void *private_data; /* private for allocator; don't touch */
 };

In azx_init_chip():

 /* program the position buffer */
 azx_writel(chip, DPLBASE, (u32)chip->posbuf.addr);
 azx_writel(chip, DPUBASE, upper_32bit(chip->posbuf.addr));

and in azx_setup_controller():

 /* enable the position buffer */
 if (! (azx_readl(chip, DPLBASE) & ICH6_DPLBASE_ENABLE))
  azx_writel(chip, DPLBASE, (u32)chip->posbuf.addr | ICH6_DPLBASE_ENABLE);

Notice how that code is conditional? I've been looking for conditional code because its the only place where something different could be done during resume compared to device start-up. I'm not suggesting this particular code is the culprit but this or something similar is probably the root cause of the issue.

Can you tell me precisely where in azx_pcm_pointer() you are reporting the value of pos, and also which code-path is being executed (there's an if...else in there) ?

Also, could you show a sample of the pos values for the good and bugged scenarios from a printk (kernel times could be useful) ?