Mailing List Archive

On Mon, Mar 08, 2004 at 02:01:23PM -0500, J. Caputo wrote:
> Has anyone reported and/or solved hanging issues with the 'transcode'
> package and the ATrpms kernels for Fedora?
>
> Some messages on the transcode ML indicate that it has a problem with
> the exec-shield patch, and that "echo '0' > /proc/sys/kernel/
> exec-shield" should fix it. But it didn't fix things for me. The
> folks that were successful seemed to be running stock RH9 or Fedora
> kernels.

RH9 has no exec-shield. The ATrpms kernels should not differ from the
RH kernels in this repsect (would be quite fatal, so if you could test
it I would be much obliged!)

> If I get a chance I'm going to try (1) the stock FC1 kernel, and if that
> doesn't work (2) a vanilla kernel.
>
> If I use a vanilla kernel, what patches do you apply for (at minimum)
> XFS & ivtv support?

Puh, almost all of ATrpms. The xfs parts is the biggest of all
patches. Then there is v4l and i2c, which perhaps you do not need.

I suspect more the problem in the used package. Which transcode are you
running (rpm -q transcode)? Care to file a big at bugzilla.atrpms.net
against the rapo that has crafted it?
--
Axel.Thimm@physik.fu-berlin.de
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 189 bytes
Desc: not available
Url : http://lists.atrpms.net/pipermail/atrpms-devel/attachments/20040308/46b8f055/attachment.bin

On Monday 08 March 2004 14:30, Axel Thimm wrote:
> On Mon, Mar 08, 2004 at 02:01:23PM -0500, J. Caputo wrote:
> > Has anyone reported and/or solved hanging issues with the
> > 'transcode' package and the ATrpms kernels for Fedora?
> >
> > Some messages on the transcode ML indicate that it has a problem
> > with the exec-shield patch, and that "echo '0' > /proc/sys/kernel/
> > exec-shield" should fix it. But it didn't fix things for me. The
> > folks that were successful seemed to be running stock RH9 or Fedora
> > kernels.
>
> RH9 has no exec-shield. The ATrpms kernels should not differ from the
> RH kernels in this repsect (would be quite fatal, so if you could
> test it I would be much obliged!)
>
> > If I get a chance I'm going to try (1) the stock FC1 kernel, and if
> > that doesn't work (2) a vanilla kernel.
> >
> > If I use a vanilla kernel, what patches do you apply for (at
> > minimum) XFS & ivtv support?
>
> Puh, almost all of ATrpms. The xfs parts is the biggest of all
> patches. Then there is v4l and i2c, which perhaps you do not need.
>
> I suspect more the problem in the used package. Which transcode are
> you running (rpm -q transcode)? Care to file a big at
> bugzilla.atrpms.net against the rapo that has crafted it?

I *was* initially using Freshrpms transcode package, but after receiving
this message I downgraded to yours (ATrpms -- 0.6.10 I think). That
didn't work either. I also tried building from the latest transcode
source tarball (0.6.12), and got the same results with that version.

I think I'll try the stock FC kernel, and if that doesn't work, a
vanilla one. If one of those ends up being the solution, I'll have to
patch them with XFS & V4L, as I'm using both xfs & an ivtv-driven
capture card.

I'll post results when/if I have them.

-Joe

On Mon, Mar 08, 2004 at 06:32:54PM -0500, J. Caputo wrote:
> On Monday 08 March 2004 14:30, Axel Thimm wrote:
> > On Mon, Mar 08, 2004 at 02:01:23PM -0500, J. Caputo wrote:
> > > Has anyone reported and/or solved hanging issues with the
> > > 'transcode' package and the ATrpms kernels for Fedora?
> > >
> > > Some messages on the transcode ML indicate that it has a problem
> > > with the exec-shield patch, and that "echo '0' > /proc/sys/kernel/
> > > exec-shield" should fix it. But it didn't fix things for me. The
> > > folks that were successful seemed to be running stock RH9 or Fedora
> > > kernels.
> >
> > RH9 has no exec-shield. The ATrpms kernels should not differ from the
> > RH kernels in this repsect (would be quite fatal, so if you could
> > test it I would be much obliged!)
> >
> > > If I get a chance I'm going to try (1) the stock FC1 kernel, and if
> > > that doesn't work (2) a vanilla kernel.
> > >
> > > If I use a vanilla kernel, what patches do you apply for (at
> > > minimum) XFS & ivtv support?
> >
> > Puh, almost all of ATrpms. The xfs parts is the biggest of all
> > patches. Then there is v4l and i2c, which perhaps you do not need.
> >
> > I suspect more the problem in the used package. Which transcode are
> > you running (rpm -q transcode)? Care to file a big at
> > bugzilla.atrpms.net against the rapo that has crafted it?
>
> I *was* initially using Freshrpms transcode package, but after receiving
> this message I downgraded to yours (ATrpms -- 0.6.10 I think). That
> didn't work either. I also tried building from the latest transcode
> source tarball (0.6.12), and got the same results with that version.
>
> I think I'll try the stock FC kernel, and if that doesn't work, a
> vanilla one. If one of those ends up being the solution, I'll have to
> patch them with XFS & V4L, as I'm using both xfs & an ivtv-driven
> capture card.

Hm, the only thing I can think of (other than having a very subtly bug
somewhere) is that transcode might be using O_DIRECT, which is
activated on XFS partitions.

Could you test with

export LD_ASSUME_KERNEL=2.2.5

It effectively turns off nptl and directio stuff.

> I'll post results when/if I have them.

Thanks!

> -Joe
--
Axel.Thimm@physik.fu-berlin.de
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 189 bytes
Desc: not available
Url : http://lists.atrpms.net/pipermail/atrpms-devel/attachments/20040309/b34ce8f9/attachment.bin

On Tuesday 09 March 2004 06:07, Axel Thimm wrote:
> On Mon, Mar 08, 2004 at 06:32:54PM -0500, J. Caputo wrote:
> > On Monday 08 March 2004 14:30, Axel Thimm wrote:
> > > On Mon, Mar 08, 2004 at 02:01:23PM -0500, J. Caputo wrote:
> > > > Has anyone reported and/or solved hanging issues with the
> > > > 'transcode' package and the ATrpms kernels for Fedora?
> > > >
> > > > Some messages on the transcode ML indicate that it has a
> > > > problem with the exec-shield patch, and that "echo '0' >
> > > > /proc/sys/kernel/ exec-shield" should fix it. But it didn't
> > > > fix things for me. The folks that were successful seemed to be
> > > > running stock RH9 or Fedora kernels.
> > >
> > > RH9 has no exec-shield. The ATrpms kernels should not differ from
> > > the RH kernels in this repsect (would be quite fatal, so if you
> > > could test it I would be much obliged!)
> > >
> > > > If I get a chance I'm going to try (1) the stock FC1 kernel,
> > > > and if that doesn't work (2) a vanilla kernel.
> > > >
> > > > If I use a vanilla kernel, what patches do you apply for (at
> > > > minimum) XFS & ivtv support?
> > >
> > > Puh, almost all of ATrpms. The xfs parts is the biggest of all
> > > patches. Then there is v4l and i2c, which perhaps you do not
> > > need.
> > >
> > > I suspect more the problem in the used package. Which transcode
> > > are you running (rpm -q transcode)? Care to file a big at
> > > bugzilla.atrpms.net against the rapo that has crafted it?
> >
> > I *was* initially using Freshrpms transcode package, but after
> > receiving this message I downgraded to yours (ATrpms -- 0.6.10 I
> > think). That didn't work either. I also tried building from the
> > latest transcode source tarball (0.6.12), and got the same results
> > with that version.
> >
> > I think I'll try the stock FC kernel, and if that doesn't work, a
> > vanilla one. If one of those ends up being the solution, I'll have
> > to patch them with XFS & V4L, as I'm using both xfs & an
> > ivtv-driven capture card.
>
> Hm, the only thing I can think of (other than having a very subtly
> bug somewhere) is that transcode might be using O_DIRECT, which is
> activated on XFS partitions.
>
> Could you test with
>
> export LD_ASSUME_KERNEL=2.2.5
>
> It effectively turns off nptl and directio stuff.


Did that, same results. I also tried LD_ASSUME_KERNEL=2.4.19, which was
another suggestion that didn't work.

Last night I rebooted with the stock Fedora kernel (2.4.22-1.2115.nptl),
did an 'echo "0" > /proc/sys/kernel/exec-shield', and transcode worked
just fine. I rebooted again back to 2.4.22-1.2174.nptl_37.rhfc1.at,
did the same thing ('echo "0" ...) and transcode hung again.

This was using transcode-0.6.12-2.fr from FreshRPMS, but I the results
were the same yesterday using the RPM from ATrpms (0.6.10 I believe)
and also with a version built from the latest source tarball.

The only other difference(s) (besides the kernel itself) when using the
stock Fedora kernel were:

- using ext3 instead of xfs (couldn't mount my xfs partition w/stock
Fedora)
- some drivers not loaded: ivtv, xfs

I don't know whether the "problem" is with transcode or one of the
ATrpms kernel patches... it may be an underlying problem with transcode
that's exposed by one of the patches, or it may be a 'broken' patch
(I'd suspect transcode more than a kernel patch, but you never
know...). In any event it would be helpful to identify exactly what it
is about the ATrpms kernel that's precipitating this issue so that I
can report it to the transcode folks.

-Joe

Hi,

On Tue, Mar 09, 2004 at 10:42:40AM -0500, J. Caputo wrote:
> > Hm, the only thing I can think of (other than having a very subtly
> > bug somewhere) is that transcode might be using O_DIRECT, which is
> > activated on XFS partitions.

> Last night I rebooted with the stock Fedora kernel (2.4.22-1.2115.nptl),
> did an 'echo "0" > /proc/sys/kernel/exec-shield', and transcode worked
> just fine. I rebooted again back to 2.4.22-1.2174.nptl_37.rhfc1.at,
> did the same thing ('echo "0" ...) and transcode hung again.
>
> This was using transcode-0.6.12-2.fr from FreshRPMS, but I the results
> were the same yesterday using the RPM from ATrpms (0.6.10 I believe)
> and also with a version built from the latest source tarball.
>
> The only other difference(s) (besides the kernel itself) when using the
> stock Fedora kernel were:
>
> - using ext3 instead of xfs (couldn't mount my xfs partition w/stock
> Fedora)
> - some drivers not loaded: ivtv, xfs

could you test with the ATrpms kernel on a non-xfs partition,
i.e. umount all xfs partitions before the test? If that works, it is
an xfs vs transcode vs exec-shield problem, and I could bring that to
the xfs list. If that fails, too, I would ask you to test with the
2.4.22-1.2174.nptl Red Hat kernel to make sure the problem is not in
the differences 2115 -> 2174.

Do you have a small test case which can be used to reproduce the bug?

> I don't know whether the "problem" is with transcode or one of the
> ATrpms kernel patches... it may be an underlying problem with transcode
> that's exposed by one of the patches, or it may be a 'broken' patch
> (I'd suspect transcode more than a kernel patch, but you never
> know...). In any event it would be helpful to identify exactly what it
> is about the ATrpms kernel that's precipitating this issue so that I
> can report it to the transcode folks.

Many thanks for the testing!
--
Axel.Thimm@ATrpms.net
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 189 bytes
Desc: not available
Url : http://lists.atrpms.net/pipermail/atrpms-devel/attachments/20040309/a6f68f74/attachment.bin

On Tuesday 09 March 2004 11:51, Axel Thimm wrote:
> Hi,
>
> On Tue, Mar 09, 2004 at 10:42:40AM -0500, J. Caputo wrote:
> > > Hm, the only thing I can think of (other than having a very
> > > subtly bug somewhere) is that transcode might be using O_DIRECT,
> > > which is activated on XFS partitions.
> >
> > Last night I rebooted with the stock Fedora kernel
> > (2.4.22-1.2115.nptl), did an 'echo "0" >
> > /proc/sys/kernel/exec-shield', and transcode worked just fine. I
> > rebooted again back to 2.4.22-1.2174.nptl_37.rhfc1.at, did the same
> > thing ('echo "0" ...) and transcode hung again.
> >
> > This was using transcode-0.6.12-2.fr from FreshRPMS, but I the
> > results were the same yesterday using the RPM from ATrpms (0.6.10 I
> > believe) and also with a version built from the latest source
> > tarball.
> >
> > The only other difference(s) (besides the kernel itself) when using
> > the stock Fedora kernel were:
> >
> > - using ext3 instead of xfs (couldn't mount my xfs partition
> > w/stock Fedora)
> > - some drivers not loaded: ivtv, xfs
>
> could you test with the ATrpms kernel on a non-xfs partition,
> i.e. umount all xfs partitions before the test? If that works, it is
> an xfs vs transcode vs exec-shield problem, and I could bring that to
> the xfs list. If that fails, too, I would ask you to test with the
> 2.4.22-1.2174.nptl Red Hat kernel to make sure the problem is not in
> the differences 2115 -> 2174.
>
> Do you have a small test case which can be used to reproduce the bug?
>
> > I don't know whether the "problem" is with transcode or one of the
> > ATrpms kernel patches... it may be an underlying problem with
> > transcode that's exposed by one of the patches, or it may be a
> > 'broken' patch (I'd suspect transcode more than a kernel patch, but
> > you never know...). In any event it would be helpful to identify
> > exactly what it is about the ATrpms kernel that's precipitating
> > this issue so that I can report it to the transcode folks.
>
> Many thanks for the testing!


OK, I have more results...

Last night I unmounted my XFS partition, unloaded the xfs kernel module,
and tried transcoding a title... success! Then I remounted my XFS
partition and tried transcoding using that partition.... surprise!
success also!? So, I'm sorry to have wasted everyone's time &
bandwidth, but it appears this is either a transcode problem, a MythDVD
& dvd::rip problem, or a problem with a particular DVD. Here's what I
think happened/is happening:

The original titles I was trying to rip/transcode were titles #40 and
#41 on a DVD with about 45-50 titles. They ripped fine, but the
transcode commands generated by MythDVD and/or dvd::rip choked on
extracting anything from that title (subtitles, preview images,
transcoding... no good). Then, 2 nights ago, when I tested with the
stock Fedora kernel, I chose a different, shorter (and much earlier on
the disc) title from the same DVD as my test case because I didn't want
to wait 15 minutes while it ripped the .vobs. Then, when I rebooted
back to the ATrpms kernel, I used the vobs I had already ripped from
title 40.

Last night's test (with & w/o XFS) was using a completely different
disc, w/ no problems.

So then I went back to the .vobs I had ripped from the first disc (title
#40), and was able to hack together a 'tccat' command line that
extracted the title into an MPEG2-PS stream w/AC3 audio (mplayer/
mencoder choked on it with AC3 CRC errors, but Xine plays it fine).
So, my best guess is that, at least for this particular case, the
transcode command line(s) generated by MythDVD or dvd::rip are not 100%
correct; or possibly the command lines are correct but transcode is not
handling some edge case properly. (Just a note; the point where
transcode was failing was not in the actual transcoding, which it never
got to, but in actually extracting the stream from the .vob w/tccat &
tcdemux)

Again, sorry for wasting your time! I guess this should teach me to put
better controls on my testing!

-Joe

On Wed, Mar 10, 2004 at 09:20:38AM -0500, J. Caputo wrote:
> So, I'm sorry to have wasted everyone's time & bandwidth, but it
> appears this is either a transcode problem, a MythDVD & dvd::rip
> problem, or a problem with a particular DVD.

Sounds like a DVD problem and a back failover method from one of the
apps.

Thanks for testing and reporting!
--
Axel.Thimm at ATrpms.net
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 189 bytes
Desc: not available
Url : http://lists.atrpms.net/pipermail/atrpms-devel/attachments/20040311/4f4e4940/attachment.bin