> As I expected. I hadn't added the sound_free_dmap stuff to the tree because
> of exactly this. It appears it got added to 2.1.120 either by accident or
> because Linus added someone elses patch
Seems strange for me.
How adding of sound_free_dmap to close_dmap can affect sync_output?
audio_release called only from sound_release at mostly end.
sync_output called from audio_release before DMAbuf_release
and DMAbuf_release called as last call in audio_release.
So sync_output must get untouched dmap in both cases
(with and without sound_free_dmap).
Or should we add check that dmap->raw_buf != NULL
at start of sync_output?
And even if dmap was freed, then why we get OOPS
in second memset, not the first one?
Anyway I cannot reproduce this OOPS.
mordor:$ cat /dev/audio >/dev/null
sound_release
audio_release...
sync_output..., dmap=c182f0d4
mordor:$
The path is exactly the same as in posted oops, but I did not get OOPS
However I use Sound Blaster driver. Perhaps something wrong in ad1848 driver?
And I saw in 2.0.35 sound driver, that sound_free_dmap is there in close_dmap
and nobody complains about it, however code is pretty look like as that in
2.1.12X (I mean audio_release, sync_output).
And can somebody explain why do we moved increment of p (pointer to
currently cleaning fragment) from end of loop to begin of it?
p = dmap->qtail; <-- qtail is pointer to first unused fragment, right?
for (i = dmap->qlen + 1; i < dmap->nbufs; i++)
{ So why preincrement it?
p = (p + 1) % dmap->nbufs; <------- here it is in 2.1.12X
if (((dmap->raw_buf + p * dmap->fragment_size) + dmap->fragment_size) >
(dmap->raw_buf + dmap->buffsize))
printk(KERN_ERR "audio: Buffer error 2\n");
memset(dmap->raw_buf + p * dmap->fragment_size,
dmap->neutral_byte,
dmap->fragment_size);
<------------------------ Here it is in 2.0.35
}
Bye,
Oleg
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@vger.rutgers.edu
Please read the FAQ at http://www.tux.org/lkml/faq.html