Messages in this thread | | | Date | Sun, 13 Sep 1998 00:29:38 +0400 | From | Oleg Drokin <> | Subject | Re: sound recording broken in 2.1.120+ |
| |
>> No oops any more.
> 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
| |