I noticed a weird regression during the last couple of days: I'm on 2.6.35-rc3 right now and I am using MakeMKV to watch BD-movies (legally bought, of course) on Linux.
When using the latest mainline kernel when using the streaming function of MakeMKV it stops streaming mostly after a few seconds but it can take up to a few minutes regardless of the player and backend used. I first suspected MakeMKV but when that didn't chance anything I rebooted to the drm-next-tree of the 21st of May (based on .34-rc6) and the problems were gone. Rebooted to .35-rc3 and they're back. I am also noticin increased I/O loads on 2.6.35-rc3 when using MakeMKV.
Sadly dmesg and all other logs are silent about the problem (as is the program itself) so I don't quite know how to address it and how to classify it.
My BD drive (Liteon IHES 108) is housed in an external enclosure (Bus 001 Device 005: ID 152d:2338 JMicron Technology Corp. / JMicron USA Technology Corp. JM20337 Hi-Speed USB to SATA & PATA Combo Bridge).
I am attaching lsusb and lspci as well as dmesg for now.
Created attachment 26870 [details]
Created attachment 26871 [details]
lsusb and lspci
Please make the hang happen again and then crack opaen an xterm and do
dmesg -n 7
echo t > /proc/sysrq-trigger
dmesg -s 1000000 > foo
and then attach foo to this report. Hopefully it will show us where that process got stuck.
Created attachment 26894 [details]
thanks for your reply!
I did as you asked and I hope I cought the right section - the log is being spammed really really quickly...
The processes in question would be vlc, makemkv and makemkvcon.
However I noticed something else: makemkv creates an internal buffer which is filled from the blu-ray drive. When the player hangs, makemkv still continues to fill the buffer so I guess the problem is not related to the drive but rather to the streaming part itself. Normally this bug screams "userspace", but it is gone on the .34 series so unless it's a very strange userspace-dependecy-coincidence it sould be a kernel issue.
Well, FWIW, I noticed that my 2.6.35-rc3-based desktop occasionally "freezes" and becomes totally unresponsive for about a second. After that, it continues to work normally and there are not signs of anything wrong in the logs etc.
It may or may not be related.
Klaus, what graphics do you use?
Hmmm, Rafael, I haven't noticed any hangs on my system so far. Also the same movie plays back just fine when ripped into a MKV container (with no reencoding being done).
I'm on a Radeon 2600XT using the OSS driver with KMS and powermanagement enabled.
Could this problem have its roots in the networking-area of the kernel? MakeMKV streams the movies via localhost or over ethernet.
I just fired up banshee and connected to my DLNA-mediaserver and am experiencing troubles with playback too (banshee hangs while buffering). These problems sure look similar.
On another note: I tried GDB to debug VLC and MakeMKV yesterday but it hasn't gotten me anywhere.
There you go, I caught something:
[Info 10:43:52.225] Running Banshee 1.7.1: [Ubuntu maverick (development branch) (linux-gnu, x86_64) @ 2010-06-03 16:38:21 UTC]
[Info 10:43:53.000] All services are started 0,619725
[Info 10:43:53.428] nereid Client Started
[Warn 10:44:46.041] Caught an exception - System.Net.WebException: The request timed out (in `System')
at System.Net.HttpWebRequest.EndGetResponse (IAsyncResult asyncResult) [0x00000]
at System.Net.HttpWebRequest.GetResponse () [0x00000]
at Banshee.Metadata.MetadataServiceJob.GetHttpStream (System.Uri uri, System.String ignoreMimeTypes) [0x00000]
at Banshee.Metadata.MetadataServiceJob.GetHttpStream (System.Uri uri) [0x00000]
at Banshee.Metadata.Rhapsody.RhapsodyQueryJob.Run () [0x00000]
at Banshee.Metadata.MetadataServiceJob.Run () [0x00000]
I just installed and tested Ubuntu's generic .35-kernel based on -rc3 and it works there. I guess they changed something in the kernel configuration and in userspace for the .35-series which makes my own kernels not work correctly.
Now I've only got to find out what exactly it is they've changed...
They might have applied some fixes that aren't in the mainline yet.