Cdda2wav and cdrecord use the highest realtime priority and thus may conflict with other realtime processes such as isdnd. I have a system which occasionally hangs if cdrecord is running while a PPP over ISDN connection is up. Cdda2wav may also cause the system to spend the CPU in an excessive amount of time (>80%) in 'interrupt mode' and thus freezing the display if cdda2wav is run without appropriate -S and an ATAPI drive uses UDMA33. Fix: Use rtprio and renice after cdda2wav or cdrecord has been launched. Cdda2wav may be run with speed limitation -S to reduce CPU time spent in 'interrupt mode'. The patches allow to make use of environment variables to control the realtime priority and in case of cdda2wav a preset nice priority will be honored.
Responsible Changed From-To: freebsd-ports-bugs->dirk Over to maintainer
This isn't really FreeBSD specific and at least for cdrecord the negative impact on letting the user fiddle with the priority easily is hard to judge, i.e. it most likely doesn't run with the highest realtime priority by default without a reason. Could you please run this patch through cdrecord-developers@lists.berlios.de?
On Thu, Jan 08, 2004 at 12:00:48AM +0100, Hanspeter Roth wrote: > On Jan 06 at 14:48, Marius Strobl spoke: > > > > > This isn't really FreeBSD specific and at least for cdrecord the negative > > Yes, it's not specific to FreeBSD. > > > impact on letting the user fiddle with the priority easily is hard to > > judge, i.e. it most likely doesn't run with the highest realtime priority > > by default without a reason. Could you please run this patch through > > I've been trying to ask the reason for this on > cdwrite@other.debian.org but I got no answer: > > http://lists.debian.org/cdwrite/2003/cdwrite-200312/msg00001.html > > I guess that the reason for the high priority comes from the matter > that in Linux 2.4 it was not possible to access an ATAPI drive via > DMA. (At least I got no answer on a mailing list how to acomplish > this.) So for drives which are not burn proof the cdrecord process > must never be inhibited by another process. That's the most plausible reason but it doesn't explain why cdda2wav also uses the highest realtime priority by default. > As of FreeBSD 4.9 one can switch on DMA for all ATAPI drives at > once. > But it's still not the default and there are most likely still burners not featuring burn proof in use. The real reason why I'm not in favour of adding your patches to the FreeBSD cdrtools ports if not really serving a purpose to the generic user is because according to the "GPL clarifications text" in cdrecord.c modified versions are not supported by Joerg Schilling. Instead the author of the modification, i.e. in case of the ports the maintainer, has to provide the full support or there's no support at all. In this regard sysutils/cdrtools currently even violates the cdrtools license as it isn't built with the SOURCE_MODIFIED macro defined. That's also why I as the maintainer of sysutils/cdrtools-devel want to get rid of all the local modifacations in the middle-term if possible. > > cdrecord-developers@lists.berlios.de? > > I've tried to submit a similar patch on cdwrite@other.debian.org: > > http://lists.debian.org/cdwrite/2003/cdwrite-200312/msg00097.html > > And the answer was: > http://lists.debian.org/cdwrite/2003/cdwrite-200312/msg00127.html > > So do you think it makes sence that I submit the new patch to > cdrecord-developers@lists.berlios.de ? > I don't read cdwrite@other.debian.org (thought all relevant discussion moved to cdrecord-developers@lists.berlios.de) so I wasn't aware that you already contacted Joerg Schilling and posting again wouldn't have been necessary. Thanks for doing it anyway. I primarily was interested what Joerg Schilling thinks about your patches, unfortunately his answers weren't very insightful... Could you please elaborate on your answer: https://lists.berlios.de/pipermail/cdrecord-developers/2004-January/000388.html i.e. do you still think your patches should be added to the ports? Should the (FreeBSD specific) documentation shipping with cdrtools be revised instead? Thanks, Marius
On Jan 11 at 22:05, Marius Strobl spoke: > That's the most plausible reason but it doesn't explain why cdda2wav also > uses the highest realtime priority by default. I guess that cdda2wav only needs a high priority when it's output is being piped into cdrecord in order to prevent buffer underflows. And probably also only if DMA is disabled. With DMA disabled the CPU is much more involved than with DMA enabled. When writing to wav files cdda2wav probably doesn't need the highest priority. That's my personal guess. I'd be interested in Joerg Schilling's opinion. > > As of FreeBSD 4.9 one can switch on DMA for all ATAPI drives at > > once. > > > > But it's still not the default and there are most likely still burners > not featuring burn proof in use. That patches would still run cdda2wav and cdrecord at highest realtime priority if the respective environment variables are not set. So the default behavior of the patches should fit with the default value of hw.ata.atapi_dma. > modified versions are not supported by Joerg Schilling. Instead the > author of the modification, i.e. in case of the ports the maintainer, > has to provide the full support or there's no support at all. > In this regard sysutils/cdrtools currently even violates the cdrtools > license as it isn't built with the SOURCE_MODIFIED macro defined. That's > also why I as the maintainer of sysutils/cdrtools-devel want to get rid > of all the local modifacations in the middle-term if possible. Ok. I understand that. > Could you please elaborate on your answer: > https://lists.berlios.de/pipermail/cdrecord-developers/2004-January/000388.html Do you mean the issue of the system hangs or the issue with the device used with cdda2wav or both? :-) > i.e. do you still think your patches should be added to the ports? > Should the (FreeBSD specific) documentation shipping with cdrtools be > revised instead? I haven't considered that support by Joerg Schilling could cease. So it's probably better not to include tha patches. (Unless maybe if many other users encounter the same problem.) So should I close the PR? How do I accomplish this? Do I need to subscribe to some freebsd-gnats-submit@FreeBSD.org? -Hanspeter
On Mon, Jan 12, 2004 at 06:01:54PM +0100, Hanspeter Roth wrote: > On Jan 11 at 22:05, Marius Strobl spoke: > > > That's the most plausible reason but it doesn't explain why cdda2wav also > > uses the highest realtime priority by default. > > I guess that cdda2wav only needs a high priority when it's output is > being piped into cdrecord in order to prevent buffer underflows. Yes, that makes sense. > And probably also only if DMA is disabled. With DMA disabled the CPU > is much more involved than with DMA enabled. > When writing to wav files cdda2wav probably doesn't need the highest > priority. > That's my personal guess. I'd be interested in Joerg Schilling's > opinion. There's also Heiko Eissfeldt (heiko@hexco.de), author of cdda2wav and maintainer of cdda2wav within the cdrtools package :) > > That patches would still run cdda2wav and cdrecord at highest > realtime priority if the respective environment variables are not > set. So the default behavior of the patches should fit with the > default value of hw.ata.atapi_dma. Yes, but then one would have to document properly to not fiddle with the priority knobs if DMA for ATAPI drives isn't turned on and to probably avoid them completely if ones burner doesn't support burn free. > > > Could you please elaborate on your answer: > > https://lists.berlios.de/pipermail/cdrecord-developers/2004-January/000388.html > > Do you mean the issue of the system hangs or the issue with the > device used with cdda2wav or both? :-) The issue with the hangs. Is the application you refer to a custom one? Anything to look at from the cdrtools ports perspective? Your note about directly using (ATAPI) drives with cdda2wav instead of going through the (ATAPI)CAM layer is a usefull hint, I'll look what's the best place to put it. Thanks. > > > i.e. do you still think your patches should be added to the ports? > > Should the (FreeBSD specific) documentation shipping with cdrtools be > > revised instead? > > I haven't considered that support by Joerg Schilling could cease. So > it's probably better not to include tha patches. (Unless maybe if many > other users encounter the same problem.) > > So should I close the PR? How do I accomplish this? Do I need to > subscribe to some freebsd-gnats-submit@FreeBSD.org? > Well, as you say that the patches in this PR and lowering priority in general didn't solve your problem I'll await your reply regarding the application you use and if there's no reason to keep this PR open I'll ask a committer to close it. Normally dirk@freebsd.org, whom this PR was assigned to, would deal with this, unfortunately he is inactive since quite a while... In general the state of a PR can only be changed by a committer, a good place to ask for it if you don't know a committer would be the freebsd-bugs@freebsd.org mailing list.
On Tue, Jan 13, 2004 at 07:33:53PM +0100, Marius Strobl wrote: > > The issue with the hangs. Is the application you refer to a custom one? > Anything to look at from the cdrtools ports perspective? > Could you please have a look at http://www.freebsd.org/cgi/query-pr.cgi?pr=kern/54616 if it's maybe the same issue?
On Jan 13 at 20:08, Marius Strobl spoke: > On Tue, Jan 13, 2004 at 07:33:53PM +0100, Marius Strobl wrote: > > > > The issue with the hangs. Is the application you refer to a custom one? So fare there's only a private instance. But it's at a distinct location. > > Anything to look at from the cdrtools ports perspective? > > > > Could you please have a look at > http://www.freebsd.org/cgi/query-pr.cgi?pr=kern/54616 > if it's maybe the same issue? My system could not only hang when cdrecord is burning but also when it is only trying to read the contents of a CD. But that happened only then there was some activity buy madplay or mkisofs in advance. And also preferably when ISDN activity was going on. Also I had forgotten trying to drop into DDB trying Ctrl+Alt+Esc. The situation got better after I've inserted explicitly syncs after madplay/mkisofs. I could remove them and try dropping into DDB... -Hanspeter
On Jan 13 at 19:33, Marius Strobl spoke: > Yes, but then one would have to document properly to not fiddle with the > priority knobs if DMA for ATAPI drives isn't turned on and to probably > avoid them completely if ones burner doesn't support burn free. I could try to yield a draft. But it won't probably be properly. > > > Could you please elaborate on your answer: > > > https://lists.berlios.de/pipermail/cdrecord-developers/2004-January/000388.html > > > > Do you mean the issue of the system hangs or the issue with the > > device used with cdda2wav or both? :-) > > The issue with the hangs. Is the application you refer to a custom one? It might be considered as a kind of a custom one. At least it's located somewhere else. But it isn't a commercial installation and it's still in development. > Anything to look at from the cdrtools ports perspective? The hang mostly occurred when cdrecord was burning or also when trying to read any TOC on a CDs. Just it only occurred when there was madplay/mkisofs/lame running in advance. It also happened when cdrecord wasn't active but only lame and isdnd was active. So the hang is certainly not because of cdrecord alone. I thought it might be some kind of combination. The system hasn't hung since I've inserted syncs after madplay/mkisofs/lame. Maybe I should remove them again and try to drop into DDB... > > Your note about directly using (ATAPI) drives with cdda2wav instead of > going through the (ATAPI)CAM layer is a useful hint, I'll look what's > the best place to put it. Thanks. Joerg mentions that there is a difference in quality. I haven't noticed this since our application is speech only. But it might be significant if the application is about music. An alternative for cdda2wav might be using the speed switch -S to reduce the interrupt frequency when using ATAPICAM. (But again I had problems only on a Plextor drive but not on a Memorex one.) -Hanspeter
State Changed From-To: open->closed closed because: - the author of cdrtools doesn't includes this (it's not FreeBSD specific) - the patch doesn't solves the problem of the originator Requested by: Marius Strobl <marius@alchemy.franken.de>