Opened 4 years ago

Last modified 2 years ago

#12513 new bug

KDL when ripping CDs

Reported by: dsuden Owned by: nobody
Priority: normal Milestone: Unscheduled
Component: System/Kernel Version: R1/Development
Keywords: Cc:
Blocked By: Blocking:
Has a Patch: no Platform: All

Description

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

Attachments (1)

ripping kdl.jpg (1.6 MB ) - added by dsuden 4 years ago.
KDL photo

Download all attachments as: .zip

Change History (6)

by dsuden, 4 years ago

Attachment: ripping kdl.jpg added

KDL photo

comment:1 by pulkomandy, 4 years ago

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).

in reply to:  1 comment:2 by bonefish, 4 years ago

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.

comment:3 by ttcoder, 4 years ago

The ".....blah-mp[3]-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 :-)

Last edited 4 years ago by ttcoder (previous) (diff)

comment:4 by vidrep, 4 years ago

[*] 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.

comment:5 by diver, 2 years ago

Component: - GeneralSystem/Kernel
Note: See TracTickets for help on using tickets.