Re: Bug#638250: Needs to be adapted for libav/0.7
tags 639948 +patch thanks Hi Lennart, many thaks for your cooperation ;-) * Lennart Sorensen [110904 17:03 -0400]: > On Sun, Sep 04, 2011 at 04:13:52PM -0400, Lennart Sorensen wrote: > > Are there any that don't experience it? [...] > > So it turns out it was reported to ffmpeg upstream 3 months ago and fixed > already. > > http://ffmpeg.org/trac/ffmpeg/ticket/272 > > The patch to libavcodec/ppc/asm.S is in comment #8. > > It no longer segfaults for me with that patch applied. I confirm that this patch works for me on my powerbook G4 as well. Please find attached patch prepared for integrating to debian/patches. Elimar -- .~. /V\ L I N U X /( )\ >Phear the Penguin< ^^-^^ From: Elimar Riesebieter Subject: Fixes use of altivec flavor on PowerPC of libav-0.7 Origin: http://ffmpeg.org/trac/ffmpeg/ticket/272#comment:8 Bug: http://bugzilla.libav.org/show_bug.cgi?id=40 Forwarded: http://bugzilla.libav.org/show_bug.cgi?id=40 Bug-Debian: http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=639948 Thanks Lennart Sorensen for the hint ;-) Index: libav-0.7.1/libavcodec/ppc/asm.S === --- libav-0.7.1.orig/libavcodec/ppc/asm.S 2011-07-21 10:47:51.0 +0200 +++ libav-0.7.1/libavcodec/ppc/asm.S 2011-09-05 00:12:47.645210696 +0200 @@ -67,7 +67,11 @@ .macro movrel rd, sym #if CONFIG_PIC -lwz \rd, \sym@got(r2) +bcl 20, 31, lab_pic_\@ +lab_pic_\@: +mflr\rd +addis \rd, \rd, (\sym - lab_pic_\@)@ha +addi\rd, \rd, (\sym - lab_pic_\@)@l #else lis \rd, \sym@ha la \rd, \sym@l(\rd) signature.asc Description: Digital signature
Re: Bug#638250: Needs to be adapted for libav/0.7
On Sun, Sep 04, 2011 at 04:13:52PM -0400, Lennart Sorensen wrote: > Are there any that don't experience it? > > I just tried running ffmpeg on a power6+ machine under gdb and got: > > Program received signal SIGSEGV, Segmentation fault. > 0x0f6ff37c in ff_fft_calc_altivec () at > /root/libav-0.7.1/libavcodec/ppc/fft_altivec_s.S:447 > 447 DECL_FFTS 0 > (gdb) where > #0 0x0f6ff37c in ff_fft_calc_altivec () at > /root/libav-0.7.1/libavcodec/ppc/fft_altivec_s.S:447 > #1 0x0f6feaa8 in ff_imdct_half_altivec (s=, output= out>, input=) at > /root/libav-0.7.1/libavcodec/ppc/fft_altivec.c:93 > #2 0x0f437ce8 in imdct_and_windowing (ac=0x10040ca0, sce=0xf7f260c0) at > /root/libav-0.7.1/libavcodec/aacdec.c:1856 > #3 0x0f43caa8 in spectral_to_sample (ac=) at > /root/libav-0.7.1/libavcodec/aacdec.c:2015 > #4 aac_decode_frame_int (avctx=, data=0xf7f95020, > data_size=0xda78, gb=) at > /root/libav-0.7.1/libavcodec/aacdec.c:2170 > #5 0x0f43ccec in aac_decode_frame (avctx=, data= out>, data_size=, avpkt=) > at /root/libav-0.7.1/libavcodec/aacdec.c:2216 > #6 0x0f77f25c in avcodec_decode_audio3 (avctx=0x100406a0, samples= out>, frame_size_ptr=, avpkt=) > at /root/libav-0.7.1/libavcodec/utils.c:726 > #7 0x0ff3f924 in try_decode_frame (avpkt=0x100466e0, st=0x1003ede0) at > /root/libav-0.7.1/libavformat/utils.c:2104 > #8 av_find_stream_info (ic=0x1003e840) at > /root/libav-0.7.1/libavformat/utils.c:2388 > #9 0x1000b200 in opt_input_file (opt=, filename= out>) at /root/libav-0.7.1/ffmpeg.c:3271 > #10 0x1000f0fc in parse_options (argc=4, argv=0xe184, options=0x10026720, > parse_arg_function=0x1000cfd0 ) at > /root/libav-0.7.1/cmdutils.c:287 > #11 0x100067c8 in main (argc=4, argv=) at > /root/libav-0.7.1/ffmpeg.c: > (gdb) Program received signal SIGSEGV, Segmentation fault. > > Anyone have an idea what to look at exactly? I really wish debug builds > wouldn't have so much 'optimized out' stuff that makes reading stack > traces so hard. So it turns out it was reported to ffmpeg upstream 3 months ago and fixed already. http://ffmpeg.org/trac/ffmpeg/ticket/272 The patch to libavcodec/ppc/asm.S is in comment #8. It no longer segfaults for me with that patch applied. Apparently when compiling in pic mode, the new assembly altived fft code always segfaults, while the old version was C code and worked fine. Apparently an offset calculation was done wrong as far as I understand it. -- Len Sorensen -- To UNSUBSCRIBE, email to debian-powerpc-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/20110904210351.gc15...@caffeine.csclub.uwaterloo.ca
Re: Bug#638250: Needs to be adapted for libav/0.7
On Sun, Sep 04, 2011 at 08:47:59AM +0200, Reinhard Tartler wrote: > I strongly disagree that this arch specific defect on ppc is in any way > a blocking bug for recompiling moc-ffmpeg-plugin against the new libav > libraries. It only affects (some?) altivec enabled machines and can be > easily avoided by disabling the altivec variant. > > Ideally, we find a porter that can identify the bug and provide a patch > for fixing the segmentation fault. I've copied the powerpc porters and > ask them hereby for their assistance. > > Or, if porters approached me, I also could disable the altivec builds in > libav completely, penalizing potential altivec users that do not > experience this issue. Are there any that don't experience it? I just tried running ffmpeg on a power6+ machine under gdb and got: Program received signal SIGSEGV, Segmentation fault. 0x0f6ff37c in ff_fft_calc_altivec () at /root/libav-0.7.1/libavcodec/ppc/fft_altivec_s.S:447 447 DECL_FFTS 0 (gdb) where #0 0x0f6ff37c in ff_fft_calc_altivec () at /root/libav-0.7.1/libavcodec/ppc/fft_altivec_s.S:447 #1 0x0f6feaa8 in ff_imdct_half_altivec (s=, output=, input=) at /root/libav-0.7.1/libavcodec/ppc/fft_altivec.c:93 #2 0x0f437ce8 in imdct_and_windowing (ac=0x10040ca0, sce=0xf7f260c0) at /root/libav-0.7.1/libavcodec/aacdec.c:1856 #3 0x0f43caa8 in spectral_to_sample (ac=) at /root/libav-0.7.1/libavcodec/aacdec.c:2015 #4 aac_decode_frame_int (avctx=, data=0xf7f95020, data_size=0xda78, gb=) at /root/libav-0.7.1/libavcodec/aacdec.c:2170 #5 0x0f43ccec in aac_decode_frame (avctx=, data=, data_size=, avpkt=) at /root/libav-0.7.1/libavcodec/aacdec.c:2216 #6 0x0f77f25c in avcodec_decode_audio3 (avctx=0x100406a0, samples=, frame_size_ptr=, avpkt=) at /root/libav-0.7.1/libavcodec/utils.c:726 #7 0x0ff3f924 in try_decode_frame (avpkt=0x100466e0, st=0x1003ede0) at /root/libav-0.7.1/libavformat/utils.c:2104 #8 av_find_stream_info (ic=0x1003e840) at /root/libav-0.7.1/libavformat/utils.c:2388 #9 0x1000b200 in opt_input_file (opt=, filename=) at /root/libav-0.7.1/ffmpeg.c:3271 #10 0x1000f0fc in parse_options (argc=4, argv=0xe184, options=0x10026720, parse_arg_function=0x1000cfd0 ) at /root/libav-0.7.1/cmdutils.c:287 #11 0x100067c8 in main (argc=4, argv=) at /root/libav-0.7.1/ffmpeg.c: (gdb) Program received signal SIGSEGV, Segmentation fault. Anyone have an idea what to look at exactly? I really wish debug builds wouldn't have so much 'optimized out' stuff that makes reading stack traces so hard. -- Len Sorensen -- To UNSUBSCRIBE, email to debian-powerpc-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/20110904201352.gb15...@caffeine.csclub.uwaterloo.ca
Re: installation failed
I changed /etc/yaboot.conf to reflect that root=/dev/sdb6. Now it boots nicely into wheezy. I have pata_macio in /etc/modules now Excuse me, pata_macio is NOT in /etc/modules but it is loaded at boot (it shows up wit lsmod). During installation I chrooted into /target and added pata_macio to /etc/modules and then I updated initramfs. So the kernel module gets loaded at boot time. -- To UNSUBSCRIBE, email to debian-powerpc-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/4e63d74a.3070...@zonnet.nl
Re: installation failed
On 09/04/2011 09:38 PM, Jeroen Diederen wrote: On 09/04/2011 07:08 PM, Milan Kupcevic wrote: On 09/04/2011 10:58 AM, Jeroen Diederen wrote: I used the latest netboot image: http://d-i.debian.org/daily-images/powerpc/daily/powerpc/netboot/mini.iso I tried to install a base system. Installation went fine, yaboot installed ok too. At reboot I am thrown into a busybox shell. The error messages I get are: Gave up waiting for a root device. Common problems: - Boot args (cat /proc/cmdline) - Check rootdelay= (did the system wait long enough?) - Check root= (did the system wait for the right device?) - Missing modules (cat /proc/modules; ls /dev) ALERT! /dev/disk/by-uuid/long-number does not exist. Dropping to a shell! FATAL: Error inserting i8042 (/lib/modules/3.0.0-1-powerpc/kernel/drivers/input/serio/i8042.ko): No such device FATAL: Error inserting atkbd (/lib/modules/3.0.0-1-powerpc/kernel/drivers/input/keyboard/atkbd.ko): No such device It has nothing to do with yaboot as I also installed on another computer where I skipped yaboot installation (I had yaboot working fine). I get the same errors on that machine. It seems it has something to do with some kernel modules. Regards Jeroen Diederen http://mintppc.org Which machine are you trying to install it on? Proper installation report would help. If it is a Mac please try the suggestion from: http://lists.debian.org/debian-powerpc/2011/08/msg00050.html and report back. Milan Same error as reported earlier (i8042 atkbd failed to insert). What I see in /dev however, is that all my hard disks partitions have been renamed to sda, sdb and sdc. In the past they were all hda, hdb, hdc. I will have a look if I can adapt yaboot so I can boot into it. I changed /etc/yaboot.conf to reflect that root=/dev/sdb6. Now it boots nicely into wheezy. I have pata_macio in /etc/modules now -- To UNSUBSCRIBE, email to debian-powerpc-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/4e63d638.9050...@zonnet.nl
Re: installation failed
On 09/04/2011 07:08 PM, Milan Kupcevic wrote: On 09/04/2011 10:58 AM, Jeroen Diederen wrote: I used the latest netboot image: http://d-i.debian.org/daily-images/powerpc/daily/powerpc/netboot/mini.iso I tried to install a base system. Installation went fine, yaboot installed ok too. At reboot I am thrown into a busybox shell. The error messages I get are: Gave up waiting for a root device. Common problems: - Boot args (cat /proc/cmdline) - Check rootdelay= (did the system wait long enough?) - Check root= (did the system wait for the right device?) - Missing modules (cat /proc/modules; ls /dev) ALERT! /dev/disk/by-uuid/long-number does not exist. Dropping to a shell! FATAL: Error inserting i8042 (/lib/modules/3.0.0-1-powerpc/kernel/drivers/input/serio/i8042.ko): No such device FATAL: Error inserting atkbd (/lib/modules/3.0.0-1-powerpc/kernel/drivers/input/keyboard/atkbd.ko): No such device It has nothing to do with yaboot as I also installed on another computer where I skipped yaboot installation (I had yaboot working fine). I get the same errors on that machine. It seems it has something to do with some kernel modules. Regards Jeroen Diederen http://mintppc.org Which machine are you trying to install it on? Proper installation report would help. If it is a Mac please try the suggestion from: http://lists.debian.org/debian-powerpc/2011/08/msg00050.html and report back. Milan Same error as reported earlier (i8042 atkbd failed to insert). What I see in /dev however, is that all my hard disks partitions have been renamed to sda, sdb and sdc. In the past they were all hda, hdb, hdc. I will have a look if I can adapt yaboot so I can boot into it. -- To UNSUBSCRIBE, email to debian-powerpc-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/4e63d3ca.50...@zonnet.nl
Re: installation failed
On 09/04/2011 07:08 PM, Milan Kupcevic wrote: On 09/04/2011 10:58 AM, Jeroen Diederen wrote: I used the latest netboot image: http://d-i.debian.org/daily-images/powerpc/daily/powerpc/netboot/mini.iso I tried to install a base system. Installation went fine, yaboot installed ok too. At reboot I am thrown into a busybox shell. The error messages I get are: Gave up waiting for a root device. Common problems: - Boot args (cat /proc/cmdline) - Check rootdelay= (did the system wait long enough?) - Check root= (did the system wait for the right device?) - Missing modules (cat /proc/modules; ls /dev) ALERT! /dev/disk/by-uuid/long-number does not exist. Dropping to a shell! FATAL: Error inserting i8042 (/lib/modules/3.0.0-1-powerpc/kernel/drivers/input/serio/i8042.ko): No such device FATAL: Error inserting atkbd (/lib/modules/3.0.0-1-powerpc/kernel/drivers/input/keyboard/atkbd.ko): No such device It has nothing to do with yaboot as I also installed on another computer where I skipped yaboot installation (I had yaboot working fine). I get the same errors on that machine. It seems it has something to do with some kernel modules. Regards Jeroen Diederen http://mintppc.org Which machine are you trying to install it on? Proper installation report would help. If it is a Mac please try the suggestion from: http://lists.debian.org/debian-powerpc/2011/08/msg00050.html and report back. Milan I tried it both on a Pismo G3 / 400 and a G4 MDD. I will have a look at the suggestion. -- To UNSUBSCRIBE, email to debian-powerpc-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/4e63c1c3.30...@zonnet.nl
Re: Power Mac G5 & Radeon X1900 - driver problem
On 04/09/2011, Elimar Riesebieter wrote: > * John Ames [110902 21:17 -0500]: > >> other hand, that seems to be fixed in Sid. Obviously it's playing >> nicely enough to run framebuffer console output properly, but beyond >> that I'm not so sure. Does that "conflicting fb usage" message >> indicate some kind of driver conflict? If so, is there a way I can >> disable whatever's conflicting with it and leave only the radeon >> driver in place? > > FMPOV this is only the case if two different graphic adapters are > installed side by side or the drivesrs are loaded by /etc/modules > which is not needed nowadays. Edit this file and remove all graphic > drivers. I see a similar message using a nVIDIA card with nouveau: fb: conflicting fb hw usage nouveaufb vs OFfb NVDA,Displ - removing generic driver It doesn't seem to interfere with successful loading of the nouveau driver. (I'm guessing this message corresponds to the moment during boot when the console display briefly becomes garbage before flickering a bit and settling back down with the newly loaded driver.) I don't have any graphics listed in /etc/modules which I'm aware of: apm_emu firewire-sbp2 loop snd-powermac I did, however, have to edit yaboot.conf to prevent nvidiafb being loaded else nouveau wouldn't load at all. - cfr -- To UNSUBSCRIBE, email to debian-powerpc-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/ca+n4xyyckgrnruj9qdaeej5z9f_i9-staxyvz1rs_1g-sph...@mail.gmail.com
Re: installation failed
On 09/04/2011 10:58 AM, Jeroen Diederen wrote: > I used the latest netboot image: > http://d-i.debian.org/daily-images/powerpc/daily/powerpc/netboot/mini.iso > > I tried to install a base system. Installation went fine, yaboot > installed ok too. At reboot I am thrown into a busybox shell. The error > messages I get are: > > Gave up waiting for a root device. Common problems: > - Boot args (cat /proc/cmdline) >- Check rootdelay= (did the system wait long enough?) >- Check root= (did the system wait for the right device?) > - Missing modules (cat /proc/modules; ls /dev) > ALERT! /dev/disk/by-uuid/long-number does not exist. Dropping to a shell! > FATAL: Error inserting i8042 > (/lib/modules/3.0.0-1-powerpc/kernel/drivers/input/serio/i8042.ko): No > such device > FATAL: Error inserting atkbd > (/lib/modules/3.0.0-1-powerpc/kernel/drivers/input/keyboard/atkbd.ko): > No such device > > It has nothing to do with yaboot as I also installed on another computer > where I skipped yaboot installation (I had yaboot working fine). I get > the same errors on that machine. It seems it has something to do with > some kernel modules. > > Regards > Jeroen Diederen > http://mintppc.org > > Which machine are you trying to install it on? Proper installation report would help. If it is a Mac please try the suggestion from: http://lists.debian.org/debian-powerpc/2011/08/msg00050.html and report back. Milan -- To UNSUBSCRIBE, email to debian-powerpc-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/4e63b0a0.5070...@physics.harvard.edu
Re: installation failed
I chrooted into the newly installed system and downgraded the kernel to 2.6.39-bpo.2-powerpc. I could then get into my system without any kernel module errors. The problem seems to be linux-image-3.0.0-1-powerpc (3.0.0-3) Regards, Jeroen Diederen http://mintppc.org On 09/04/2011 04:58 PM, Jeroen Diederen wrote: I used the latest netboot image: http://d-i.debian.org/daily-images/powerpc/daily/powerpc/netboot/mini.iso I tried to install a base system. Installation went fine, yaboot installed ok too. At reboot I am thrown into a busybox shell. The error messages I get are: Gave up waiting for a root device. Common problems: - Boot args (cat /proc/cmdline) - Check rootdelay= (did the system wait long enough?) - Check root= (did the system wait for the right device?) - Missing modules (cat /proc/modules; ls /dev) ALERT! /dev/disk/by-uuid/long-number does not exist. Dropping to a shell! FATAL: Error inserting i8042 (/lib/modules/3.0.0-1-powerpc/kernel/drivers/input/serio/i8042.ko): No such device FATAL: Error inserting atkbd (/lib/modules/3.0.0-1-powerpc/kernel/drivers/input/keyboard/atkbd.ko): No such device It has nothing to do with yaboot as I also installed on another computer where I skipped yaboot installation (I had yaboot working fine). I get the same errors on that machine. It seems it has something to do with some kernel modules. Regards Jeroen Diederen http://mintppc.org -- To UNSUBSCRIBE, email to debian-powerpc-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/4e639b6b.60...@zonnet.nl
installation failed
I used the latest netboot image: http://d-i.debian.org/daily-images/powerpc/daily/powerpc/netboot/mini.iso I tried to install a base system. Installation went fine, yaboot installed ok too. At reboot I am thrown into a busybox shell. The error messages I get are: Gave up waiting for a root device. Common problems: - Boot args (cat /proc/cmdline) - Check rootdelay= (did the system wait long enough?) - Check root= (did the system wait for the right device?) - Missing modules (cat /proc/modules; ls /dev) ALERT! /dev/disk/by-uuid/long-number does not exist. Dropping to a shell! FATAL: Error inserting i8042 (/lib/modules/3.0.0-1-powerpc/kernel/drivers/input/serio/i8042.ko): No such device FATAL: Error inserting atkbd (/lib/modules/3.0.0-1-powerpc/kernel/drivers/input/keyboard/atkbd.ko): No such device It has nothing to do with yaboot as I also installed on another computer where I skipped yaboot installation (I had yaboot working fine). I get the same errors on that machine. It seems it has something to do with some kernel modules. Regards Jeroen Diederen http://mintppc.org -- To UNSUBSCRIBE, email to debian-powerpc-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/4e639219.5010...@zonnet.nl
Re: libavcodec.so.53: ffplay produces a coredump on arch ppc
* bz [110904 12:58 +0200]: > On Sun, Sep 4, 2011 at 12:21 PM, Elimar Riesebieter wrote: > > You tried it with gdb. I just want a simple > > $ ffplay 639948.aac > > $ ffplay 639948.aac > ffplay version 0.7.1-4:0.7.1-4, Copyright (c) 2003-2011 the Libav developers > built on Sep 1 2011 21:50:24 with gcc 4.6.1 [...] > libavutil51. 7. 0 / 51. 7. 0 > libavcodec 53. 5. 0 / 53. 5. 0 > libavformat 53. 2. 0 / 53. 2. 0 > libavdevice 53. 0. 0 / 53. 0. 0 > libavfilter 2. 4. 0 / 2. 4. 0 > libswscale2. 0. 0 / 2. 0. 0 > libpostproc 52. 0. 0 / 52. 0. 0 > [xcb] Unknown sequence number while processing queue > [xcb] Most likely this is a multi-threaded client and XInitThreads has > not been called > [xcb] Aborting, sorry about that. > ffplay: ../../src/xcb_io.c:273: poll_for_event: Assertion > `!xcb_xlib_threads_sequence_lost' failed. > Aborted Thanks Elimar -- The path to source is always uphill! -unknown- signature.asc Description: Digital signature
Re: libavcodec.so.53: ffplay produces a coredump on arch ppc
On Sun, Sep 4, 2011 at 12:21 PM, Elimar Riesebieter wrote: > You tied it with gdb. I just want a simple > $ ffplay 639948.aac $ ffplay 639948.aac ffplay version 0.7.1-4:0.7.1-4, Copyright (c) 2003-2011 the Libav developers built on Sep 1 2011 21:50:24 with gcc 4.6.1 configuration: --extra-version='4:0.7.1-4' --arch=powerpc --prefix=/usr --enable-vdpau --enable-bzlib --enable-libgsm --enable-libschroedinger --enable-libspeex --enable-libtheora --enable-libvorbis --enable-pthreads --enable-zlib --enable-libvpx --enable-runtime-cpudetect --enable-pic --enable-vaapi --enable-libopenjpeg --enable-gpl --enable-postproc --enable-swscale --enable-x11grab --enable-libdirac --enable-libmp3lame --enable-librtmp --enable-libx264 --enable-libxvid --enable-libdc1394 --disable-altivec --enable-shared --disable-static WARNING: library configuration mismatch avutil configuration: --extra-version='4:0.7.1-4' --arch=powerpc --prefix=/usr --enable-vdpau --enable-bzlib --enable-libgsm --enable-libschroedinger --enable-libspeex --enable-libtheora --enable-libvorbis --enable-pthreads --enable-zlib --enable-libvpx --enable-runtime-cpudetect --enable-pic --enable-vaapi --enable-libopenjpeg --enable-gpl --enable-postproc --enable-swscale --enable-x11grab --enable-libdirac --enable-libmp3lame --enable-librtmp --enable-libx264 --enable-libxvid --enable-libdc1394 --shlibdir=/usr/lib/altivec --cpu=g4 --enable-shared --disable-static --enable-altivec --disable-ffmpeg --disable-ffplay avcodec configuration: --extra-version='4:0.7.1-4' --arch=powerpc --prefix=/usr --enable-vdpau --enable-bzlib --enable-libgsm --enable-libschroedinger --enable-libspeex --enable-libtheora --enable-libvorbis --enable-pthreads --enable-zlib --enable-libvpx --enable-runtime-cpudetect --enable-pic --enable-vaapi --enable-libopenjpeg --enable-gpl --enable-postproc --enable-swscale --enable-x11grab --enable-libdirac --enable-libmp3lame --enable-librtmp --enable-libx264 --enable-libxvid --enable-libdc1394 --shlibdir=/usr/lib/altivec --cpu=g4 --enable-shared --disable-static --enable-altivec --disable-ffmpeg --disable-ffplay avformatconfiguration: --extra-version='4:0.7.1-4' --arch=powerpc --prefix=/usr --enable-vdpau --enable-bzlib --enable-libgsm --enable-libschroedinger --enable-libspeex --enable-libtheora --enable-libvorbis --enable-pthreads --enable-zlib --enable-libvpx --enable-runtime-cpudetect --enable-pic --enable-vaapi --enable-libopenjpeg --enable-gpl --enable-postproc --enable-swscale --enable-x11grab --enable-libdirac --enable-libmp3lame --enable-librtmp --enable-libx264 --enable-libxvid --enable-libdc1394 --shlibdir=/usr/lib/altivec --cpu=g4 --enable-shared --disable-static --enable-altivec --disable-ffmpeg --disable-ffplay avdeviceconfiguration: --extra-version='4:0.7.1-4' --arch=powerpc --prefix=/usr --enable-vdpau --enable-bzlib --enable-libgsm --enable-libschroedinger --enable-libspeex --enable-libtheora --enable-libvorbis --enable-pthreads --enable-zlib --enable-libvpx --enable-runtime-cpudetect --enable-pic --enable-vaapi --enable-libopenjpeg --enable-gpl --enable-postproc --enable-swscale --enable-x11grab --enable-libdirac --enable-libmp3lame --enable-librtmp --enable-libx264 --enable-libxvid --enable-libdc1394 --shlibdir=/usr/lib/altivec --cpu=g4 --enable-shared --disable-static --enable-altivec --disable-ffmpeg --disable-ffplay avfilterconfiguration: --extra-version='4:0.7.1-4' --arch=powerpc --prefix=/usr --enable-vdpau --enable-bzlib --enable-libgsm --enable-libschroedinger --enable-libspeex --enable-libtheora --enable-libvorbis --enable-pthreads --enable-zlib --enable-libvpx --enable-runtime-cpudetect --enable-pic --enable-vaapi --enable-libopenjpeg --enable-gpl --enable-postproc --enable-swscale --enable-x11grab --enable-libdirac --enable-libmp3lame --enable-librtmp --enable-libx264 --enable-libxvid --enable-libdc1394 --shlibdir=/usr/lib/altivec --cpu=g4 --enable-shared --disable-static --enable-altivec --disable-ffmpeg --disable-ffplay swscale configuration: --extra-version='4:0.7.1-4' --arch=powerpc --prefix=/usr --enable-vdpau --enable-bzlib --enable-libgsm --enable-libschroedinger --enable-libspeex --enable-libtheora --enable-libvorbis --enable-pthreads --enable-zlib --enable-libvpx --enable-runtime-cpudetect --enable-pic --enable-vaapi --enable-libopenjpeg --enable-gpl --enable-postproc --enable-swscale --enable-x11grab --enable-libdirac --enable-libmp3lame --enable-librtmp --enable-libx264 --enable-libxvid --enable-libdc1394 --shlibdir=/usr/lib/altivec --cpu=g4 --enable-shared --disable-static --enable-altivec --disable-ffmpeg --disable-ffplay postprocconfiguration: --extra-version='4:0.7.1-4' --arch=powerpc --prefix=/usr --enable-vdpau --enable-bzlib --enable-libgsm --enable-libschroedinger --enable-libspeex --enable-libtheora --enable-libvorbis --enable-pthreads --enable-zlib --enable-libvpx --enable-runtime-cpudetect --enable-pic --enable-vaapi --enable-libopenjpeg --enable-gpl
Re: Bug#638250: Bug#639948: Bug#638250: Needs to be adapted for libav/0.7
* Reinhard Tartler [110904 12:07 +0200]: > On Sun, Sep 04, 2011 at 11:23:34 (CEST), Elimar Riesebieter wrote: > > > * Reinhard Tartler [110904 08:47 +0200]: > > > >> tags 638250 help > >> stop > >> > >> On Sun, Sep 04, 2011 at 06:45:36 (CEST), Elimar Riesebieter wrote: > >> > >> > block 638250 by 639948 > >> > thanks > >> > >> I strongly disagree that this arch specific defect on ppc is in any way > >> a blocking bug for recompiling moc-ffmpeg-plugin against the new libav > >> libraries. > > > > moc-ffmpeg-plugin on ppc compiles well against libav 0.7.1 libraries > > but produces exactly the same backtraces as ffplay 0.7.1 on ppc. So > > this is surely a libav bug. > > Nobody doubts that. My objection in that the 'block' relationship is > wrong. As soon as a change for the altivec assembler code is found, > surely moc-ffmpeg-plugin will work again. > > >> It only affects (some?) altivec enabled machines and can be > >> easily avoided by disabling the altivec variant. > > > > What do you mean with only? PPC is an officialy supported > > architecture in Debian! > > I mean that we know that the bug appears on your particular machine. I > question that it might not be broken on *every* altivec machine > available. The code in question has passed an intensive regression > suite, which includes testing on altivec machines. I'm curious how this > could slip through: > > http://fate.libav.org/ These builds were done with "--enable-gpl --cpu=g4 --cc=gcc-4.6.1" only, which are totaly different from Debians build so are not coparable. The Debian package 0.7.1-4 builds well on my "particular machine" but coredumps with ffplay... Elimar -- The path to source is always uphill! -unknown- -- To UNSUBSCRIBE, email to debian-powerpc-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/20110904105055.ga14...@samweis.home.lxtec.de
Re: Bug#639948: Bug#638250: Needs to be adapted for libav/0.7
On Sun, Sep 04, 2011 at 11:23:34 (CEST), Elimar Riesebieter wrote: > * Reinhard Tartler [110904 08:47 +0200]: > >> tags 638250 help >> stop >> >> On Sun, Sep 04, 2011 at 06:45:36 (CEST), Elimar Riesebieter wrote: >> >> > block 638250 by 639948 >> > thanks >> >> I strongly disagree that this arch specific defect on ppc is in any way >> a blocking bug for recompiling moc-ffmpeg-plugin against the new libav >> libraries. > > moc-ffmpeg-plugin on ppc compiles well against libav 0.7.1 libraries > but produces exactly the same backtraces as ffplay 0.7.1 on ppc. So > this is surely a libav bug. Nobody doubts that. My objection in that the 'block' relationship is wrong. As soon as a change for the altivec assembler code is found, surely moc-ffmpeg-plugin will work again. >> It only affects (some?) altivec enabled machines and can be >> easily avoided by disabling the altivec variant. > > What do you mean with only? PPC is an officialy supported > architecture in Debian! I mean that we know that the bug appears on your particular machine. I question that it might not be broken on *every* altivec machine available. The code in question has passed an intensive regression suite, which includes testing on altivec machines. I'm curious how this could slip through: http://fate.libav.org/ > Most of the powerpc machines are altivev capable. Apple's G4 and G5, > IBM's Power6 and Power7 are all have altivec which is very useful to > accelerate multimedia applications. And please notice, that altivec > was working well on ffmpeg 0.6.2-5 so it turns out that #639948 is a > regression! Again, nobody doubts that. I just don't consider #639948 release critical. >> [...] >> >> > Thanks again for the patch but there is no solution for #639948 yet. >> > Please advice me what to do? I filed the ppc bug to libav-upstream >> > http://bugzilla.libav.org/show_bug.cgi?id=40 but there is no >> > response either from Debian-multimedia. Removing ppc from supported >> > archs isn't practicable as 639948 is a regression. >> >> Ideally, we find a porter that can identify the bug and provide a patch >> for fixing the segmentation fault. I've copied the powerpc porters and >> ask them hereby for their assistance. > > I'll check the CC settings in libav package, but as far as I can see > they are equal for ppc. Hmmm. Compiling ith gcc-4.5 would be a first > attempt to eleminate a compiler bug. Thanks. >> Or, if porters approached me, I also could disable the altivec builds in >> libav completely, penalizing potential altivec users that do not >> experience this issue. > > This might not be a very intelligent solution. Well, I just state the available options. -- Gruesse/greetings, Reinhard Tartler, KeyID 945348A4 -- To UNSUBSCRIBE, email to debian-powerpc-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/87zkik1v01@faui43f.informatik.uni-erlangen.de
Re: libavcodec.so.53: ffplay produces a coredump on arch ppc
* bz [110904 11:56 +0200]: > On Sun, Sep 4, 2011 at 11:28 AM, Elimar Riesebieter wrote: [...] > > > > If you're using sid you get an update to libav 0.7.1-4 bei ugrading. > > Yes. But I still have the "obsolete" libavformat52 and libavcodec52 packages. > > > Could you please verify that > > $ ffplay 639948.aac > > plays or produces a coredump? ffplay can be find in the package > > ffmpeg. > > No. It doesn't play. See my previous message (yesterday). You tied it with gdb. I just want a simple $ ffplay 639948.aac If you want to debug it ffmpeg-dbg is needed and you can run $ gdb ffplay core in the dir were you run ffplay. A coredump implied. Elimar -- The path to source is always uphill! -unknown- signature.asc Description: Digital signature
Re: libavcodec.so.53: ffplay produces a coredump on arch ppc
On Sun, Sep 4, 2011 at 11:28 AM, Elimar Riesebieter wrote: > * bz [110904 08:42 +0200]: > >> On Sun, Sep 4, 2011 at 5:40 AM, Elimar Riesebieter wrote: >> > * bz [110903 23:49 +0200]: >> > >> >> On Sat, Sep 3, 2011 at 2:13 PM, Elimar Riesebieter >> >> wrote: >> >> > * Elimar Riesebieter [110901 00:27 +0200]: >> >> > >> >> >> Package: libavcodec53 >> >> >> Version: 4:0.7.1-2 >> >> >> Severity: important >> >> >> File: libavcodec.so.53 >> >> >> >> >> >> I determine a bug of libav 0.7.1 playing moc on arch ppc which can be >> >> >> reproduced by ffplay version 0.7.1-4:0.7.1-2: >> >> > >> >> > As libav went to sid now I may ask if someone on this list can >> >> > confirm this bug? It can be done by using aac, m4a or any other >> >> > ffmpeg audio flavour. >> >> >> >> Using your 639948.aac on my ibook g4 1.2 ghz 12" unstable: >> >> mocp and vlc OK, but >> > >> > VLC is not linked against libavcdec. And your moc version is >> > probably linked against 0.6.5. >> >> Yes. moc and moc-ffmpeg-plugin from unstable. >> moc-ffmpeg-plugin depends on libavformat52 and libavcodec52 (0.6.2-5). > > If you're using sid you get an update to libav 0.7.1-4 bei ugrading. Yes. But I still have the "obsolete" libavformat52 and libavcodec52 packages. > Could you please verify that > $ ffplay 639948.aac > plays or produces a coredump? ffplay can be find in the package > ffmpeg. No. It doesn't play. See my previous message (yesterday). Bin > > Many thanks for your cooperation! > Elimar > > -- > "Talking much about oneself can also > be a means to conceal oneself." > -Friedrich Nietzsche > -- To UNSUBSCRIBE, email to debian-powerpc-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/cabedsecrugz-uqs-ijlr+bstyk1ritzpedpz93gs8m66rl4...@mail.gmail.com
Re: libavcodec.so.53: ffplay produces a coredump on arch ppc
* bz [110904 08:42 +0200]: > On Sun, Sep 4, 2011 at 5:40 AM, Elimar Riesebieter wrote: > > * bz [110903 23:49 +0200]: > > > >> On Sat, Sep 3, 2011 at 2:13 PM, Elimar Riesebieter > >> wrote: > >> > * Elimar Riesebieter [110901 00:27 +0200]: > >> > > >> >> Package: libavcodec53 > >> >> Version: 4:0.7.1-2 > >> >> Severity: important > >> >> File: libavcodec.so.53 > >> >> > >> >> I determine a bug of libav 0.7.1 playing moc on arch ppc which can be > >> >> reproduced by ffplay version 0.7.1-4:0.7.1-2: > >> > > >> > As libav went to sid now I may ask if someone on this list can > >> > confirm this bug? It can be done by using aac, m4a or any other > >> > ffmpeg audio flavour. > >> > >> Using your 639948.aac on my ibook g4 1.2 ghz 12" unstable: > >> mocp and vlc OK, but > > > > VLC is not linked against libavcdec. And your moc version is > > probably linked against 0.6.5. > > Yes. moc and moc-ffmpeg-plugin from unstable. > moc-ffmpeg-plugin depends on libavformat52 and libavcodec52 (0.6.2-5). If you're using sid you get an update to libav 0.7.1-4 bei ugrading. Could you please verify that $ ffplay 639948.aac plays or produces a coredump? ffplay can be find in the package ffmpeg. Many thanks for your cooperation! Elimar -- "Talking much about oneself can also be a means to conceal oneself." -Friedrich Nietzsche signature.asc Description: Digital signature
Re: Bug#638250: Needs to be adapted for libav/0.7
* Reinhard Tartler [110904 08:47 +0200]: > tags 638250 help > stop > > On Sun, Sep 04, 2011 at 06:45:36 (CEST), Elimar Riesebieter wrote: > > > block 638250 by 639948 > > thanks > > I strongly disagree that this arch specific defect on ppc is in any way > a blocking bug for recompiling moc-ffmpeg-plugin against the new libav > libraries. moc-ffmpeg-plugin on ppc compiles well against libav 0.7.1 libraries but produces exactly the same backtraces as ffplay 0.7.1 on ppc. So this is surely a libav bug. > It only affects (some?) altivec enabled machines and can be > easily avoided by disabling the altivec variant. What do you mean with only? PPC is an officialy supported architecture in Debian! Most of the powerpc machines are altivev capable. Apple's G4 and G5, IBM's Power6 and Power7 are all have altivec which is very useful to accelerate multimedia applications. And please notice, that altivec was working well on ffmpeg 0.6.2-5 so it turns out that #639948 is a regression! > [...] > > > Thanks again for the patch but there is no solution for #639948 yet. > > Please advice me what to do? I filed the ppc bug to libav-upstream > > http://bugzilla.libav.org/show_bug.cgi?id=40 but there is no > > response either from Debian-multimedia. Removing ppc from supported > > archs isn't practicable as 639948 is a regression. > > Ideally, we find a porter that can identify the bug and provide a patch > for fixing the segmentation fault. I've copied the powerpc porters and > ask them hereby for their assistance. I'll check the CC settings in libav package, but as far as I can see they are equal for ppc. Hmmm. Compiling ith gcc-4.5 would be a first attempt to eleminate a compiler bug. > Or, if porters approached me, I also could disable the altivec builds in > libav completely, penalizing potential altivec users that do not > experience this issue. This might not be a very intelligent solution. Elimar -- Alles was viel bedacht wird ist bedenklich!;-) Friedrich Nietzsche signature.asc Description: Digital signature
Re: Bug#638250: Needs to be adapted for libav/0.7
tags 638250 help stop On Sun, Sep 04, 2011 at 06:45:36 (CEST), Elimar Riesebieter wrote: > block 638250 by 639948 > thanks I strongly disagree that this arch specific defect on ppc is in any way a blocking bug for recompiling moc-ffmpeg-plugin against the new libav libraries. It only affects (some?) altivec enabled machines and can be easily avoided by disabling the altivec variant. [...] > Thanks again for the patch but there is no solution for #639948 yet. > Please advice me what to do? I filed the ppc bug to libav-upstream > http://bugzilla.libav.org/show_bug.cgi?id=40 but there is no > response either from Debian-multimedia. Removing ppc from supported > archs isn't practicable as 639948 is a regression. Ideally, we find a porter that can identify the bug and provide a patch for fixing the segmentation fault. I've copied the powerpc porters and ask them hereby for their assistance. Or, if porters approached me, I also could disable the altivec builds in libav completely, penalizing potential altivec users that do not experience this issue. Cheers, -- Gruesse/greetings, Reinhard Tartler, KeyID 945348A4 -- To UNSUBSCRIBE, email to debian-powerpc-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/87ehzw3isg@faui43f.informatik.uni-erlangen.de
