KDL when ripping CDs

[dsuden]

I'm using hrev 49856, which seems great in other respects, but is really touchy when attempting to rip CDs. Usually the KDL occurs just after I insert a CD, and before I have a chance to start the rip (a problem that's been around for a long time, not just this version). Here's a pretty detailed KDL photo, in case it helps. If I can do any additional testing or provide more info, just let me know.

Dane

[dsuden]

KDL photo

[pulkomandy]

That backtrace looks... interesting.

1) How does get_next_team_info ends up reading audio files using the media kit? Where does this "mp-loader" thread comes from, and what is audio::Loader? (is it one of TuneTracker apps trying to access the CD as soon as it is inserted?)

2) No matter what, reading from the CD using the media kit should not result in a KDL like this. Maybe a syslog would be helpful (you can use the KDL command syslog, if other ways to get it fail).

[bonefish]

Replying to pulkomandy:

1) How does get_next_team_info ends up reading audio files using the media kit? Where does this "mp-loader" thread comes from, and what is audio::Loader? (is it one of TuneTracker apps trying to access the CD as soon as it is inserted?)

The "(nearest)" after "_get_next_team_info" means that the actual function could not be determined and the nearest function (before the respective address) whose name is known is printed instead.

[ttcoder]

The ".....-loader" thread I think is the one created together with the "_BMediaRoster_" thread, when an application uses a BMediaFile object -- at least there's no such code in TunePrepper anyhow (TP is our CD ripping application). As a tangeant, might be worth noting we no longer use the "userland-fs" method of ripping CDs, because kernel-land cdda was most stable for us in 49137 (Dane still managed to crash once or twice in userland-fs cdda mode, he's a tough tester that way :-) .. But now that I think of it, maybe we should revisit that.. So to put it as a one-liner summary, Dane reports that instability is back in TunePrepper now that we're about to use 49856 instead [*]; most of the time it's this "VMCache" panic. Might be a corner-case kernel vulnerability that was lurking and is coming out in the open

[*] when the "alfonzo-suse" buildbot is fixed (as tracked in another ticket) I'll try newer nightlies too, there's goodies in there that I'd like Dane to try out :-)

[vidrep]

[*] when the "alfonzo-suse" buildbot is fixed (as tracked in another ticket) I'll try newer nightlies too, there's goodies in there that I'd like Dane to try out :-)

I have done several pkgman updates over the past week, and I am no longer seeing the same issues as before. I assume it was quietly fixed sometime earlier this week. However, the same video playback issues I noted in my other tickets remain. Take a chance, do an update, and report back on the result.

[waddlesplash]

Is this still readily reproducible? Could we get a copy of the causing application if so?

[ttcoder]

This was discussed wiith Dane a while back: best to close this, we'll open fresh tickets if we attempt to tackle CD ripping again in the future. At this point it makes no sense to keep our TunePrepper tickets active years after we stopped developping that app. Shoot me an email if I'm missing something and can help with related topics though.