Login | Register For Free | Help
Search for: (Advanced)

Mailing List Archive: ivtv: users

Periodic Lockups With IVTV Versions > 0.4.x

 

 

ivtv users RSS feed   Index | Next | Previous | View Threaded


wepprop at sbcglobal

Jul 7, 2007, 7:34 PM

Post #1 of 18 (2786 views)
Permalink
Periodic Lockups With IVTV Versions > 0.4.x

I am consistently having a problem with hard lockups that occur every
few days to every few weeks. I am reasonably confident I have isolated
it to the ivtv driver. The problem was not present in 0.4.8. It is
present in 0.8.2, 0.9.1, 0.10.1, 0.10.2 and 0.10.3. Other than that, I
cannot say exactly when the problem appeared.

For info, I have two PVR-250 MCEs and one PVR-500 MCE. I also make a
fair amount of recordings; between 4 and 10 a day. The lockups only
occur at the very start of a recording; if the recording starts
successfully, everything is good until the next recording tries to
start.. After a lockup and a hard reboot of the box, there is never
anything in the logs or other messages to indicate what the problem
might have been: Just a B (zero length) file for the recording that
failed to start properly.

I tried to work my way out of the problem with hardware and software
changes. Hardware-wise Ive changed pretty much everything in the box
except the video hard drive, which is itself a recent WD 500G SATA
drive. Ive also made all of the software changes and tweaks I could
find documented in the mailing list archives and the wiki.

For the record, the following is a chronology of the biggest hardware
and software changes that I made and how they did or did not effect the
problem:

0.4.8, FC3, 2.6.15, Sempron 64 2600, NF3-250, 2G DDR-400, jfs perfect
in every way except choppy HD playback from the slave backend.

0.4.8, FC3, 2.6.15, Pentium D-820, Intel 865, 2G DDR-400, jfs perfect
in every way

0.10.1, FC6, 2.6.19, Pentium D-820, Intel 865, 2G DDR-400, jfs poor
video quality, intermittent lockups

0.10.2, FC6, 2.6.19, Pentium D-820, Intel 865, 2G DDR-400, jfs poor
video quality, intermittent lockups

0.10.2, FC6, 2.6.19, Pentium D-820, Intel 865, 2G DDR-400, ext3 poor
video quality, intermittent lockups

0.10.3, FC6, 2.6.19, Pentium D-820, Intel 865, 2G DDR-400, ext3
excellent video quality, intermittent lockups

0.10.3, FC6, 2.6.19, Core 2 Duo E6420, NForce 650i, 2G DDR2-800, ext3
intermittent lockups

0.10.3, FC6, 2.6.20, Core 2 Duo, E6420, NForce 650i, 2G DDR2-800, ext3,
maxcpus=1 - ran 23 days before locking up.

0.10.3, FC6, 2.6.20, Core 2 Duo, E6420, NForce 650i, 2G DDR2-800, ext3
locked up after three days.

The slave backend is similar (FC6, 2.6.19, E4300, Intel 865, 2G DDR-400,
jfs) except that it doesnt have IVTV installed and it has not suffered
a single lockup or failure to record throughout the same period.

At this point, my best option appears to be to go back to 0.4.8.
Unfortunately, going back to 0.4.8 means going back to a kernel version
<= 2.6.15 which wont support my current motherboard, so I have kinda
painted myself into an upgrade corner. Ill either have to buy yet
another new motherboard, one with a 945 chipset perhaps, or Ill have to
do a big hardware round-robin to free up an older chipset motherboard
for the Myth box, one that certainly wont support HD playback. That
leaves me back where I started. My only other option is to replace the
video partition hard drive.

In the meantime, while I think about what course to take, I would
appreciate any suggestions on ways to further troubleshoot or isolate
the problem. Downgrading might fix my stability problem but, even if it
does, it wont help fix the driver.

Bill


_______________________________________________
ivtv-users mailing list
ivtv-users [at] ivtvdriver
http://ivtvdriver.org/mailman/listinfo/ivtv-users


stinga at wolf-rock

Jul 17, 2007, 1:24 AM

Post #2 of 18 (2723 views)
Permalink
Re: Periodic Lockups With IVTV Versions > 0.4.x [In reply to]

On 08/07/07 03:34:15, William Powers wrote:
> I am consistently having a problem with hard lockups that occur every
> few days to every few weeks. I am reasonably confident I have
> isolated
>
> it to the ivtv driver. The problem was not present in 0.4.8. It is
> present in 0.8.2, 0.9.1, 0.10.1, 0.10.2 and 0.10.3. Other than that,
> I
>
> cannot say exactly when the problem appeared.
>
> For info, I have two PVR-250 MCE’s and one PVR-500 MCE. I also make a
> fair amount of recordings; between 4 and 10 a day. The lockups only
> occur at the very start of a recording; if the recording starts
> successfully, everything is good until the next recording tries to
> start.. After a lockup and a hard reboot of the box, there is never
> anything in the logs or other messages to indicate what the problem
> might have been: Just a ‘B’ (zero length) file for the recording that
> failed to start properly.
>
> I tried to work my way out of the problem with hardware and software
> changes. Hardware-wise I’ve changed pretty much everything in the box
> except the video hard drive, which is itself a recent WD 500G SATA
> drive. I’ve also made all of the software changes and tweaks I could
> find documented in the mailing list archives and the wiki.
>
> For the record, the following is a chronology of the biggest hardware
> and software changes that I made and how they did or did not effect
> the
> problem:
>
> 0.4.8, FC3, 2.6.15, Sempron 64 2600, NF3-250, 2G DDR-400, jfs –
> perfect
> in every way except choppy HD playback from the slave backend.
>
> 0.4.8, FC3, 2.6.15, Pentium D-820, Intel 865, 2G DDR-400, jfs –
> perfect
> in every way
>
> 0.10.1, FC6, 2.6.19, Pentium D-820, Intel 865, 2G DDR-400, jfs – poor
> video quality, intermittent lockups
>
> 0.10.2, FC6, 2.6.19, Pentium D-820, Intel 865, 2G DDR-400, jfs – poor
> video quality, intermittent lockups
>
> 0.10.2, FC6, 2.6.19, Pentium D-820, Intel 865, 2G DDR-400, ext3 –
> poor
>
> video quality, intermittent lockups
>
> 0.10.3, FC6, 2.6.19, Pentium D-820, Intel 865, 2G DDR-400, ext3 –
> excellent video quality, intermittent lockups
>
> 0.10.3, FC6, 2.6.19, Core 2 Duo E6420, NForce 650i, 2G DDR2-800, ext3
> –
> intermittent lockups
>
> 0.10.3, FC6, 2.6.20, Core 2 Duo, E6420, NForce 650i, 2G DDR2-800,
> ext3,
> maxcpus=1 - ran 23 days before locking up.
>
> 0.10.3, FC6, 2.6.20, Core 2 Duo, E6420, NForce 650i, 2G DDR2-800,
> ext3
> –
> locked up after three days.
>
> The slave backend is similar (FC6, 2.6.19, E4300, Intel 865, 2G
> DDR-400,
> jfs) except that it doesn’t have IVTV installed and it has not
> sufferedm
> a single lockup or failure to record throughout the same period.
>
> At this point, my best option appears to be to go back to 0.4.8.
> Unfortunately, going back to 0.4.8 means going back to a kernel
> version
> <= 2.6.15 which won’t support my current motherboard, so I have kinda
> painted myself into an upgrade corner. I’ll either have to buy yet
> another new motherboard, one with a 945 chipset perhaps, or I’ll have
> to
> do a big hardware round-robin to free up an older chipset motherboard
> for the Myth box, one that certainly won’t support HD playback. That
> leaves me back where I started. My only other option is to replace
> the
>
> video partition hard drive.
>
> In the meantime, while I think about what course to take, I would
> appreciate any suggestions on ways to further troubleshoot or isolate
> the problem. Downgrading might fix my stability problem but, even if
> it
> does, it won’t help fix the driver.
>
> Bill

Yep, I have the same.
It has always happened to my knoppmyth box, various versions, various
hard configs.
Always at the start of a recording.
Sometimes we can stay up for 20 days days sometimes its 1.
I used to get dumps in the log but they disappeared, with one of the
upgrades.

I do remote logging and removed the caching so that the log would
appear in real time.

I have a aviosys power switch box and chunk of code that looks for
mythtv not working and then it power cycles it.

Not the best solution but it seems to work.

Also need to remove the lock file since knoppmyth does not do this on
boot and then the backend wont start.

At the moment, my myth box won't start unless I hit a key on the
keyboard, I have not idea what has caused this new feature! I did have
to put a new power supply in the other day when the smoke that makes it
work leaked out.

--
'ooroo

stinga...(:)-)
---------------------------------------------------
Email: stinga [at] wolf-rock o
You need only two tools. o /////
A hammer and duct tape. If it /@ `\ /) ~
doesn't move and it should, > (O) X< ~ Fish!!
use the hammer. If it moves and `\___/' \) ~
shouldn't, use the tape. \\\
---------------------------------------------------


_______________________________________________
ivtv-users mailing list
ivtv-users [at] ivtvdriver
http://ivtvdriver.org/mailman/listinfo/ivtv-users


hverkuil at xs4all

Jul 17, 2007, 2:10 AM

Post #3 of 18 (2710 views)
Permalink
Re: Periodic Lockups With IVTV Versions > 0.4.x [In reply to]

> On 08/07/07 03:34:15, William Powers wrote:
>> I am consistently having a problem with hard lockups that occur every
>> few days to every few weeks. I am reasonably confident I have
>> isolated
>>
>> it to the ivtv driver. The problem was not present in 0.4.8. It is
>> present in 0.8.2, 0.9.1, 0.10.1, 0.10.2 and 0.10.3. Other than that,
>> I
>>
>> cannot say exactly when the problem appeared.
>>
>> For info, I have two PVR-250 MCE’s and one PVR-500 MCE. I also make a
>> fair amount of recordings; between 4 and 10 a day. The lockups only
>> occur at the very start of a recording; if the recording starts
>> successfully, everything is good until the next recording tries to
>> start.. After a lockup and a hard reboot of the box, there is never
>> anything in the logs or other messages to indicate what the problem
>> might have been: Just a ‘B’ (zero length) file for the recording
>> that
>> failed to start properly.
>>
>> I tried to work my way out of the problem with hardware and software
>> changes. Hardware-wise I’ve changed pretty much everything in the box
>> except the video hard drive, which is itself a recent WD 500G SATA
>> drive. I’ve also made all of the software changes and tweaks I could
>> find documented in the mailing list archives and the wiki.
>>
>> For the record, the following is a chronology of the biggest hardware
>> and software changes that I made and how they did or did not effect
>> the
>> problem:
>>
>> 0.4.8, FC3, 2.6.15, Sempron 64 2600, NF3-250, 2G DDR-400, jfs –
>> perfect
>> in every way except choppy HD playback from the slave backend.
>>
>> 0.4.8, FC3, 2.6.15, Pentium D-820, Intel 865, 2G DDR-400, jfs –
>> perfect
>> in every way
>>
>> 0.10.1, FC6, 2.6.19, Pentium D-820, Intel 865, 2G DDR-400, jfs – poor
>> video quality, intermittent lockups
>>
>> 0.10.2, FC6, 2.6.19, Pentium D-820, Intel 865, 2G DDR-400, jfs – poor
>> video quality, intermittent lockups
>>
>> 0.10.2, FC6, 2.6.19, Pentium D-820, Intel 865, 2G DDR-400, ext3 –
>> poor
>>
>> video quality, intermittent lockups
>>
>> 0.10.3, FC6, 2.6.19, Pentium D-820, Intel 865, 2G DDR-400, ext3 –
>> excellent video quality, intermittent lockups
>>
>> 0.10.3, FC6, 2.6.19, Core 2 Duo E6420, NForce 650i, 2G DDR2-800, ext3
>> –
>> intermittent lockups
>>
>> 0.10.3, FC6, 2.6.20, Core 2 Duo, E6420, NForce 650i, 2G DDR2-800,
>> ext3,
>> maxcpus=1 - ran 23 days before locking up.
>>
>> 0.10.3, FC6, 2.6.20, Core 2 Duo, E6420, NForce 650i, 2G DDR2-800,
>> ext3
>> –
>> locked up after three days.
>>
>> The slave backend is similar (FC6, 2.6.19, E4300, Intel 865, 2G
>> DDR-400,
>> jfs) except that it doesn’t have IVTV installed and it has not
>> sufferedm
>> a single lockup or failure to record throughout the same period.
>>
>> At this point, my best option appears to be to go back to 0.4.8.
>> Unfortunately, going back to 0.4.8 means going back to a kernel
>> version
>> <= 2.6.15 which won’t support my current motherboard, so I have kinda
>> painted myself into an upgrade corner. I’ll either have to buy yet
>> another new motherboard, one with a 945 chipset perhaps, or I’ll have
>> to
>> do a big hardware round-robin to free up an older chipset motherboard
>> for the Myth box, one that certainly won’t support HD playback. That
>> leaves me back where I started. My only other option is to replace
>> the
>>
>> video partition hard drive.
>>
>> In the meantime, while I think about what course to take, I would
>> appreciate any suggestions on ways to further troubleshoot or isolate
>> the problem. Downgrading might fix my stability problem but, even if
>> it
>> does, it won’t help fix the driver.
>>
>> Bill
>
> Yep, I have the same.
> It has always happened to my knoppmyth box, various versions, various
> hard configs.
> Always at the start of a recording.
> Sometimes we can stay up for 20 days days sometimes its 1.
> I used to get dumps in the log but they disappeared, with one of the
> upgrades.
>
> I do remote logging and removed the caching so that the log would
> appear in real time.
>
> I have a aviosys power switch box and chunk of code that looks for
> mythtv not working and then it power cycles it.
>
> Not the best solution but it seems to work.
>
> Also need to remove the lock file since knoppmyth does not do this on
> boot and then the backend wont start.
>
> At the moment, my myth box won't start unless I hit a key on the
> keyboard, I have not idea what has caused this new feature! I did have
> to put a new power supply in the other day when the smoke that makes it
> work leaked out.

This week I'll release ivtv-0.10.4 which fixes one deadlock that can occur
if both a video and a vbi stream is opened almost simultaneously. This
might (or might not) be the cause of these problems. But in addition it
will also have improved logging that should make it easier to trace issues
like this.

If MythTV does indeed open both the vbi and video device when a recording
starts, then this is almost certainly the cause of the lock up and then
ivtv-0.10.4 will fix it.

Regards,

Hans


_______________________________________________
ivtv-users mailing list
ivtv-users [at] ivtvdriver
http://ivtvdriver.org/mailman/listinfo/ivtv-users


stinga at wolf-rock

Jul 17, 2007, 4:18 AM

Post #4 of 18 (2718 views)
Permalink
Re: Periodic Lockups With IVTV Versions > 0.4.x [In reply to]

On 17/07/07 10:10:16, Hans Verkuil wrote:

> This week I'll release ivtv-0.10.4 which fixes one deadlock that can
> occur
> if both a video and a vbi stream is opened almost simultaneously.
> This
> might (or might not) be the cause of these problems. But in addition
> it
> will also have improved logging that should make it easier to trace
> issues
> like this.
>
> If MythTV does indeed open both the vbi and video device when a
> recording
> starts, then this is almost certainly the cause of the lock up and
> then
> ivtv-0.10.4 will fix it.
>

Sorry about my last email, it looked a right mess!!!
(Hopefully this one will be a bit better)

Your comment about vbi stream tickles somnething in my mind and I am
sure I have seen that mentioned in the logs, when I used to get
something in the log.
Can't confirm though.

Need to research how to upgrade ivtv-0.10.4 when it comes out (and how
to go back... just in case!)

--
'ooroo

stinga...(:)-)
---------------------------------------------------
Email: stinga [at] wolf-rock o
You need only two tools. o /////
A hammer and duct tape. If it /@ `\ /) ~
doesn't move and it should, > (O) X< ~ Fish!!
use the hammer. If it moves and `\___/' \) ~
shouldn't, use the tape. \\\
---------------------------------------------------

_______________________________________________
ivtv-users mailing list
ivtv-users [at] ivtvdriver
http://ivtvdriver.org/mailman/listinfo/ivtv-users


wepprop at sbcglobal

Jul 22, 2007, 6:22 PM

Post #5 of 18 (2647 views)
Permalink
Re: Periodic Lockups With IVTV Versions > 0.4.x [In reply to]

Hans Verkuil wrote:
> This week I'll release ivtv-0.10.4 which fixes one deadlock that can occur
> if both a video and a vbi stream is opened almost simultaneously. This
> might (or might not) be the cause of these problems. But in addition it
> will also have improved logging that should make it easier to trace issues
> like this.
>
> If MythTV does indeed open both the vbi and video device when a recording
> starts, then this is almost certainly the cause of the lock up and then
> ivtv-0.10.4 will fix it.
>
Well, at least I didn't have to wait long to find out. Approximately 36
hours (and about 20 recordings) after upgrading to 0.10.5 the box locked
up hard at the beginning of a new recording. Nothing in either the
system log or the mythbackend log.

As before, if there is any information I can provide or anything I can
do to help troubleshoot the problem, I would be glad to try. Otherwise,
it's time to downgrade to 0.4.10. Checking the box for every recording
just gets old after a few months.

Bill

_______________________________________________
ivtv-users mailing list
ivtv-users [at] ivtvdriver
http://ivtvdriver.org/mailman/listinfo/ivtv-users


dreitz at catdevnull

Jul 22, 2007, 8:06 PM

Post #6 of 18 (2650 views)
Permalink
Re: Periodic Lockups With IVTV Versions > 0.4.x [In reply to]

Not sure if it will help as I haven't been having stability problems of
late (knock on wood), but have you ensured that your PVR card is not
sharing an IRQ w/ any other PCI cards? From my experience w/ the
Hauppauge card I have, it is the happiest when not sharing an IRQ (this
has helped me w/ the DMA timeout issues I had been plagued with for a
long, long time).

If that doesn't work, I've heard reports that adjusting the PCI latency
can help... Check out these links:

http://www.ibm.com/developerworks/library/l-hw2.html
http://www.mythtv.org/wiki/index.php/PCI_Latency

Good luck,
Dave


William Powers wrote:
> Hans Verkuil wrote:
>
>> This week I'll release ivtv-0.10.4 which fixes one deadlock that can occur
>> if both a video and a vbi stream is opened almost simultaneously. This
>> might (or might not) be the cause of these problems. But in addition it
>> will also have improved logging that should make it easier to trace issues
>> like this.
>>
>> If MythTV does indeed open both the vbi and video device when a recording
>> starts, then this is almost certainly the cause of the lock up and then
>> ivtv-0.10.4 will fix it.
>>
>>
> Well, at least I didn't have to wait long to find out. Approximately 36
> hours (and about 20 recordings) after upgrading to 0.10.5 the box locked
> up hard at the beginning of a new recording. Nothing in either the
> system log or the mythbackend log.
>
> As before, if there is any information I can provide or anything I can
> do to help troubleshoot the problem, I would be glad to try. Otherwise,
> it's time to downgrade to 0.4.10. Checking the box for every recording
> just gets old after a few months.
>
> Bill
>
> _______________________________________________
> ivtv-users mailing list
> ivtv-users [at] ivtvdriver
> http://ivtvdriver.org/mailman/listinfo/ivtv-users
>


_______________________________________________
ivtv-users mailing list
ivtv-users [at] ivtvdriver
http://ivtvdriver.org/mailman/listinfo/ivtv-users


hverkuil at xs4all

Jul 22, 2007, 11:10 PM

Post #7 of 18 (2642 views)
Permalink
Re: Periodic Lockups With IVTV Versions > 0.4.x [In reply to]

On Monday 23 July 2007 03:22:23 William Powers wrote:
> Hans Verkuil wrote:
> > This week I'll release ivtv-0.10.4 which fixes one deadlock that
> > can occur if both a video and a vbi stream is opened almost
> > simultaneously. This might (or might not) be the cause of these
> > problems. But in addition it will also have improved logging that
> > should make it easier to trace issues like this.
> >
> > If MythTV does indeed open both the vbi and video device when a
> > recording starts, then this is almost certainly the cause of the
> > lock up and then ivtv-0.10.4 will fix it.
>
> Well, at least I didn't have to wait long to find out. Approximately
> 36 hours (and about 20 recordings) after upgrading to 0.10.5 the box
> locked up hard at the beginning of a new recording. Nothing in
> either the system log or the mythbackend log.
>
> As before, if there is any information I can provide or anything I
> can do to help troubleshoot the problem, I would be glad to try.
> Otherwise, it's time to downgrade to 0.4.10. Checking the box for
> every recording just gets old after a few months.

Well, I'd rather like to get to the bottom of this. Please
run 'ivtvctl -D479' as root to enable debugging and see if that turns
up anything interesting in the logs.

Are you also capturing VBI data in MythTV? (Check the MythTV setup) If
so, then turn that off and see if the lockup still happens.

If you make a whole bunch of small 1-minute recording, does that trigger
the bug as well? (Should reduce test time)

Regards,

Hans

_______________________________________________
ivtv-users mailing list
ivtv-users [at] ivtvdriver
http://ivtvdriver.org/mailman/listinfo/ivtv-users


hverkuil at xs4all

Jul 22, 2007, 11:18 PM

Post #8 of 18 (2645 views)
Permalink
Re: Periodic Lockups With IVTV Versions > 0.4.x [In reply to]

On Monday 23 July 2007 08:10:39 Hans Verkuil wrote:
> On Monday 23 July 2007 03:22:23 William Powers wrote:
> > Hans Verkuil wrote:
> > > This week I'll release ivtv-0.10.4 which fixes one deadlock that
> > > can occur if both a video and a vbi stream is opened almost
> > > simultaneously. This might (or might not) be the cause of these
> > > problems. But in addition it will also have improved logging that
> > > should make it easier to trace issues like this.
> > >
> > > If MythTV does indeed open both the vbi and video device when a
> > > recording starts, then this is almost certainly the cause of the
> > > lock up and then ivtv-0.10.4 will fix it.
> >
> > Well, at least I didn't have to wait long to find out.
> > Approximately 36 hours (and about 20 recordings) after upgrading to
> > 0.10.5 the box locked up hard at the beginning of a new recording.
> > Nothing in either the system log or the mythbackend log.
> >
> > As before, if there is any information I can provide or anything I
> > can do to help troubleshoot the problem, I would be glad to try.
> > Otherwise, it's time to downgrade to 0.4.10. Checking the box for
> > every recording just gets old after a few months.
>
> Well, I'd rather like to get to the bottom of this. Please
> run 'ivtvctl -D479' as root to enable debugging and see if that turns
> up anything interesting in the logs.
>
> Are you also capturing VBI data in MythTV? (Check the MythTV setup)
> If so, then turn that off and see if the lockup still happens.
>
> If you make a whole bunch of small 1-minute recording, does that
> trigger the bug as well? (Should reduce test time)

And just repeatedly running 'cat /dev/video0 >/dev/null'? Does that
trigger a lock up? Is it always the same card that locks up, or is a
different one each time?

Regards,

Hans

_______________________________________________
ivtv-users mailing list
ivtv-users [at] ivtvdriver
http://ivtvdriver.org/mailman/listinfo/ivtv-users


wepprop at sbcglobal

Jul 23, 2007, 3:34 PM

Post #9 of 18 (2645 views)
Permalink
Re: Periodic Lockups With IVTV Versions > 0.4.x [In reply to]

David Reitz wrote:
> Not sure if it will help as I haven't been having stability problems of
> late (knock on wood), but have you ensured that your PVR card is not
> sharing an IRQ w/ any other PCI cards? From my experience w/ the
> Hauppauge card I have, it is the happiest when not sharing an IRQ (this
> has helped me w/ the DMA timeout issues I had been plagued with for a
> long, long time).
>
Whenever I have a hard lockup, the first thing I also think of is
IRQ's. For what it's worth, here is the contents of /proc/interrupts:
>
> [root [at] bug mythtv]# cat /proc/interrupts
> CPU0 CPU1
> 0: 76350404 0 IO-APIC-edge timer
> 1: 18 0 IO-APIC-edge i8042
> 4: 81843 0 IO-APIC-edge lirc_serial
> 8: 3 0 IO-APIC-edge rtc
> 9: 0 0 IO-APIC-fasteoi acpi
> 12: 4 0 IO-APIC-edge i8042
> 14: 37093 460522 IO-APIC-edge ide0
> 15: 49 681006 IO-APIC-edge ide1
> 16: 2211 66153906 IO-APIC-fasteoi ohci_hcd:usb1, eth0
> 17: 132 139537 IO-APIC-fasteoi
> ehci_hcd:usb2, HDA Intel
> 18: 0 0 IO-APIC-fasteoi libata
> 19: 332801 0 IO-APIC-fasteoi libata
> 20: 1155115 0 IO-APIC-fasteoi ivtv0, ivtv3
> 21: 1 249225 IO-APIC-fasteoi ivtv1
> 22: 1 3591 IO-APIC-fasteoi ivtv2
> 23: 4215450 0 IO-APIC-fasteoi nvidia
> NMI: 0 0
> LOC: 74866183 74866212
> ERR: 1
> MIS: 0
However, the days when I can do much about IRQ assignments are long
gone. I've got (effectively) 4 IVTV cards plus the built-in motherboard
PCI devices sharing the 4 physical PCI interrupt lines. Something is
gonna have to share. Nor can I do much in the way of card swapping with
3 PCI cards to put into 3 PCI card slots.

Note that IRQ's are why I use Nvidia and/or Intel chipset motherboards
exclusively with Linux: In my experience, Via chipset motherboards tend
to lose track of IRQ's when more than one identical PCI device is
installed, resulting in recordings that just...stop. But I would get
messages in the logs when that would happen.

> If that doesn't work, I've heard reports that adjusting the PCI latency
> can help...
I pretty much worked PCI latency to completion, testing all the way from
the motherboard default (32) all the way up to 248 clocks. No effect.
Note also for the record that I got two full years of trouble-free
service with these exact three cards using the motherboard and ivtv
default latencies (32 and 64, respectively) before upgrading to FC6 /
2.6.18(19,20) / 0.10.1(2,3,5).

cpuspeed is also disabled.

Bill

_______________________________________________
ivtv-users mailing list
ivtv-users [at] ivtvdriver
http://ivtvdriver.org/mailman/listinfo/ivtv-users


wepprop at sbcglobal

Jul 23, 2007, 3:59 PM

Post #10 of 18 (2639 views)
Permalink
Re: Periodic Lockups With IVTV Versions > 0.4.x [In reply to]

Hans Verkuil wrote:
>> Well, I'd rather like to get to the bottom of this. Please
>> run 'ivtvctl -D479' as root to enable debugging and see if that turns
>> up anything interesting in the logs.
>>
Done. I'll let you know.
>> Are you also capturing VBI data in MythTV? (Check the MythTV setup)
>> If so, then turn that off and see if the lockup still happens.
>>
I can't get to mythtv-setup right now, but I have verified that
"VbiFormat" in the "settings" table of the database is set to "None". I
believe that means that VBI is disabled?

>> If you make a whole bunch of small 1-minute recording, does that
>> trigger the bug as well? (Should reduce test time)
>>
Several weeks ago, I recorded an entire weekend of 30 minute programs
back-to-back on Cartoon Network without triggering a lockup. I think it
knows when the recordings aren't important... But the next time I have
a chance, I'll try it.
>
> And just repeatedly running 'cat /dev/video0 >/dev/null'? Does that
> trigger a lock up? Is it always the same card that locks up, or is a
> different one each time?
>
I'll try that as well next time I can get near the TV without causing a
family crisis. I'll also start keeping a log of what is scheduled to
record on which tuners so I can see if there's a pattern. I should have
done that before. I know it has happened to tuner #1 (1st PVR-250)
because it has happened when transitioning from no recordings to one
recording. I also know it has happened to tuner #2 (2nd PVR-250)
because it has happened in the middle of a single recording when a
second recording tried to start. I can't say for certain whether I've
ever seen a lockup associated with either half of the PVR-500, but less
than 5% of my recordings are done on the PVR-500 so it would be rare in
any event. I can't remember a single instance, off the top of my head,
where a lockup occurred while transitioning between sequential
recordings. I can only remember lockups when a card is transitioning
from idle to recording. But I haven't kept good enough records to be
certain of that. I will do better.

If I can find a way to repeatably trigger a lockup, I will immediately
test all four devices.

Bill

_______________________________________________
ivtv-users mailing list
ivtv-users [at] ivtvdriver
http://ivtvdriver.org/mailman/listinfo/ivtv-users


swp5jhu02 at sneakemail

Jul 26, 2007, 3:10 PM

Post #11 of 18 (2621 views)
Permalink
Re: Periodic Lockups With IVTV Versions > 0.4.x [In reply to]

Hi,

I'm seeing similar behavior. Changing channels causes a freeze so it
needs a push on the reset button.

For me it happens when I just use mythtv to change channels. Changing
channels up to 50 times triggers it for sure here. But only if mythtv
does it.

If I change channels with "ivtv-tune -f ???" it *doesn't* freeze. I've
written a little script that changes between my configured channels with
ivtv-tune and it changed channels every 5 seconds for hours without
problems, while I did "cat /dev/video0 | xine -" at the same time,
seeing the channels change.

But when I change channels in mythtv it freezes "for sure" within 40-50
channel changes.

I did the "ivtvctl -D479" before the many channel changes, and
/var/log/messages is here:
http://home.morch.com/misc/noindex/ivtv_messages.txt

I haven't actually schduled any recordings, but I'm assuming this is the
same problem.

uname -r reports 2.6.20-16-generic - but I'm not sure if that is the
same as 2.6.20.16 or 2.6.20 ubuntu rev. 16. I haven't been able to find
a ubuntu 2.6.21 kernel package for ubuntu and would like to avoid
compiling my own kernel, but if this is the problem, let me know and I
will. I realize that ivtv's README says: "Kernels 2.6.20 and 2.6.20.1
should not be used due to a bug in the cx25840 firmware loading
routine.", but it seems to get past the loading stage fine...

Peter

I do think I'm running with 0.10.5. I installed Ubuntu Fiesty Fawn
(which gave me a slightly older version), downloaded, make-d and
installed 0.10.5, removed ubuntu's .ko-s, did a depmod
something-or-other, and now dmesg says 0.10.5.

P.S.: In order to distinguish whether it was the front or backend that
got it to freeze, I tried installing a frontend on another machine and
then changing channels on that front end, and yes, the *backend* - with
the ivtv card - froze.

> mysql -e 'select * from settings where value="VbiFormat"' mythconverg
+-----------+------+----------+
| value | data | hostname |
+-----------+------+----------+
| VbiFormat | None | NULL |
+-----------+------+----------+


> ivtvdmesg
[ 14.405847] ivtv: ==================== START INIT IVTV
====================
[ 14.405850] ivtv: version 0.10.5 (tagged release) loading
[ 14.405852] ivtv: Linux version: 2.6.20-16-generic SMP mod_unload 586
[ 14.405853] ivtv: In case of problems please include the debug info
between
[ 14.405855] ivtv: the START INIT IVTV and END INIT IVTV lines, along
with
[ 14.405856] ivtv: any module options, when mailing the ivtv-users
mailinglist.
[ 14.405903] ivtv0: Autodetected Hauppauge card (cx23415 based)
[ 14.405938] ACPI: PCI Interrupt 0000:05:05.0[A] -> GSI 21 (level,
low) -> IRQ 20
[ 14.575423] NET: Registered protocol family 10
[ 14.575488] lo: Disabled Privacy Extensions
[ 14.721959] ACPI: PCI Interrupt 0000:00:1b.0[A] -> GSI 22 (level,
low) -> IRQ 22
[ 14.721974] PCI: Setting latency timer of device 0000:00:1b.0 to 64
[ 15.081099] ivtv0: loaded v4l-cx2341x-enc.fw firmware (376836 bytes)
[ 15.105746] ivtv0: loaded v4l-cx2341x-dec.fw firmware (262144 bytes)
[ 15.327254] ivtv0: Encoder revision: 0x02060039
[ 15.335261] ivtv0: Decoder revision: 0x02020023
[ 15.401491] tveeprom 0-0050: Hauppauge model 48134, rev I121, serial#
6189642
[ 15.401494] tveeprom 0-0050: tuner model is Philips FM1216 (idx 21,
type 5)
[ 15.401496] tveeprom 0-0050: TV standards PAL(B/G) (eeprom 0x04)
[ 15.401498] tveeprom 0-0050: audio processor is MSP4418 (idx 25)
[ 15.401500] tveeprom 0-0050: decoder processor is SAA7115 (idx 19)
[ 15.401501] tveeprom 0-0050: has radio, has IR receiver, has no IR
transmitter
[ 15.401504] ivtv0: Autodetected Hauppauge WinTV PVR-350
[ 15.426536] tuner 0-0061: chip found @ 0xc2 (ivtv i2c driver #0)
[ 15.496715] saa7115 0-0021: saa7115 found (1f7115d0e100000) @ 0x42
(ivtv i2c driver #0)
[ 15.736888] saa7127 0-0044: saa7127 found @ 0x88 (ivtv i2c driver #0)
[ 15.757233] msp3400 0-0040: MSP4418G-A2 found @ 0x80 (ivtv i2c driver #0)
[ 15.757235] msp3400 0-0040: MSP4418G-A2 supports nicam and radio,
mode is autodetect and autoselect
[ 15.757345] ivtv0: Registered device video0 for encoder MPEG (4 MB)
[ 15.757476] ivtv0: Registered device video32 for encoder YUV (2 MB)
[ 15.757616] ivtv0: Registered device vbi0 for encoder VBI (1 MB)
[ 15.757672] ivtv0: Registered device video24 for encoder PCM audio (1 MB)
[ 15.757845] ivtv0: Registered device radio0 for encoder radio
[ 15.757867] ivtv0: Registered device video16 for decoder MPEG (1 MB)
[ 15.757907] ivtv0: Registered device vbi8 for decoder VBI (1 MB)
[ 15.758208] ivtv0: Registered device vbi16 for decoder VOUT
[ 15.758237] ivtv0: Registered device video48 for decoder YUV (1 MB)
[ 15.837292] ivtv0: loaded v4l-cx2341x-init.mpg firmware (155648 bytes)
[ 15.948391] tuner 0-0061: type set to 5 (Philips PAL_BG (FI1216 and
compatibles))
[ 16.298426] ivtv0: Initialized Hauppauge WinTV PVR-350, card #0
[ 16.298436] ivtv: ==================== END INIT IVTV
====================

--
Peter Valdemar Mrch
http://www.morch.com

_______________________________________________
ivtv-users mailing list
ivtv-users [at] ivtvdriver
http://ivtvdriver.org/mailman/listinfo/ivtv-users


swp5jhu02 at sneakemail

Jul 27, 2007, 8:52 AM

Post #12 of 18 (2604 views)
Permalink
Re: Periodic Lockups With IVTV Versions > 0.4.x [In reply to]

Peter Valdemar Mrch swp5jhu02-at-sneakemail.com |Lists| wrote:
> I'm seeing similar behavior. Changing channels causes a freeze so it
> needs a push on the reset button.

I have just today discovered, that if I boot the machine with "nosmp" as
a kernel parameter to disable SMP, it does changes channels just fine.

I was inspired to try this based on this troubleshooting tip:
http://ivtvdriver.org/index.php/Troubleshooting#IVTV_may_cause_hangs_when_run_on_an_Intel_processor_with_Hyperthreading_enabled.

If the other two that are also experiencing this are also on Intel Duo
processors and disabling SMP works for them too, I guess that goes a
long way to finding a root cause.

At the very least, if I don't hear to the contrary, I'll modify the
above troubleshooting section to include info about SMP for Intel
processors along with hyper threading.

Sincerely,

Peter

--
Peter Valdemar Mrch
http://www.morch.com

_______________________________________________
ivtv-users mailing list
ivtv-users [at] ivtvdriver
http://ivtvdriver.org/mailman/listinfo/ivtv-users


mark.bryars at etvinteractive

Jul 27, 2007, 9:08 AM

Post #13 of 18 (2599 views)
Permalink
Re: Periodic Lockups With IVTV Versions > 0.4.x [In reply to]

Peter Valdemar Mrch wrote:
> Peter Valdemar Mrch swp5jhu02-at-sneakemail.com |Lists| wrote:
>
>> I'm seeing similar behavior. Changing channels causes a freeze so it
>> needs a push on the reset button.
>>
>
> I have just today discovered, that if I boot the machine with "nosmp" as
> a kernel parameter to disable SMP, it does changes channels just fine.
>
>

I may have suffered from this same bug once or twice, but I have a
different problem where with hyperthreading disabled, if the load goes
too high the whole machine locks up and reboots, but with hyperthreading
enabled, it all goes smooth!

Regards,
Mark Bryars



--
Mark Bryars
Product Development Engineer
ETV Interactive Ltd
Logie Court
Stirling University Innovation Park
Stirling
Scotland, UK
FK9 4NF
T: +44 (0) 1786 455150
F: +44 (0) 1786 455179
W: www.etvinteractive.com


_______________________________________________
ivtv-users mailing list
ivtv-users [at] ivtvdriver
http://ivtvdriver.org/mailman/listinfo/ivtv-users


hverkuil at xs4all

Jul 27, 2007, 9:10 AM

Post #14 of 18 (2602 views)
Permalink
Re: Periodic Lockups With IVTV Versions > 0.4.x [In reply to]

On Friday 27 July 2007 17:52, Peter Valdemar Mrch wrote:
> Peter Valdemar Mrch swp5jhu02-at-sneakemail.com |Lists| wrote:
> > I'm seeing similar behavior. Changing channels causes a freeze so
> > it needs a push on the reset button.
>
> I have just today discovered, that if I boot the machine with "nosmp"
> as a kernel parameter to disable SMP, it does changes channels just
> fine.
>
> I was inspired to try this based on this troubleshooting tip:
> http://ivtvdriver.org/index.php/Troubleshooting#IVTV_may_cause_hangs_
>when_run_on_an_Intel_processor_with_Hyperthreading_enabled.
>
> If the other two that are also experiencing this are also on Intel
> Duo processors and disabling SMP works for them too, I guess that
> goes a long way to finding a root cause.
>
> At the very least, if I don't hear to the contrary, I'll modify the
> above troubleshooting section to include info about SMP for Intel
> processors along with hyper threading.

Do you have hyperthreading or a dual core processor? That hangs seems to
be specific to hyperthreading. Dual core should work. Well, I think
hyperthreading should also work, it's just that I never had a
hyperthreading CPU to test with.

That said, I've been able to reproduce this problem (I think) and it
seems to be related to a single firmware call. I'm currently stress
testing to see if that is indeed the case.

Watch this space :-)

Regards,

Hans

_______________________________________________
ivtv-users mailing list
ivtv-users [at] ivtvdriver
http://ivtvdriver.org/mailman/listinfo/ivtv-users


lists at morch

Jul 27, 2007, 10:41 AM

Post #15 of 18 (2598 views)
Permalink
Re: Periodic Lockups With IVTV Versions > 0.4.x [In reply to]

Hans Verkuil hverkuil-at-xs4all.nl |Lists| wrote:
> Do you have hyperthreading or a dual core processor? That hangs seems to
> be specific to hyperthreading. Dual core should work. Well, I think
> hyperthreading should also work, it's just that I never had a
> hyperthreading CPU to test with.


No, I do believe I have a dual core processor. The boot that doesn't
hang was booted with both nosmp and noht as kernel parameters, but noht
is not a valid kernel parameter, according to
http://www.mjmwired.net/kernel/Documentation/kernel-parameters.txt

If I boot without "nosmp" there are two entries here, but with, there is
only one:

# cat /proc/cpuinfo
processor : 0
vendor_id : GenuineIntel
cpu family : 6
model : 15
model name : Intel(R) Core(TM)2 CPU 6420 @ 2.13GHz
stepping : 6
cpu MHz : 600.000
cache size : 4096 KB
physical id : 0
siblings : 1
core id : 0
cpu cores : 1
fdiv_bug : no
hlt_bug : no
f00f_bug : no
coma_bug : no
fpu : yes
fpu_exception : yes
cpuid level : 10
wp : yes
flags : fpu vme de pse tsc msr pae mce cx8 apic sep mtrr pge
mca cmov pat pse36 clflush dts acpi mmx fxsr sse sse2 ss ht tm pbe nx lm
constant_tsc up pni monitor ds_cpl vmx est tm2 ssse3 cx16 xtpr lahf_lm
bogomips : 4368.97
clflush size : 64

Peter
--
Peter Valdemar Mrch
http://www.morch.com

_______________________________________________
ivtv-users mailing list
ivtv-users [at] ivtvdriver
http://ivtvdriver.org/mailman/listinfo/ivtv-users


swp5jhu02 at sneakemail

Jul 27, 2007, 10:43 AM

Post #16 of 18 (2594 views)
Permalink
Re: Periodic Lockups With IVTV Versions > 0.4.x [In reply to]

Hans Verkuil hverkuil-at-xs4all.nl |Lists| wrote:
> Do you have hyperthreading or a dual core processor? That hangs seems to
> be specific to hyperthreading. Dual core should work. Well, I think
> hyperthreading should also work, it's just that I never had a
> hyperthreading CPU to test with.

No, I do believe I have a dual core processor. The boot that doesn't
hang was booted with both nosmp and noht as kernel parameters, but noht
is not a valid kernel parameter, according to
http://www.mjmwired.net/kernel/Documentation/kernel-parameters.txt

If I boot without "nosmp" there are two entries here, but with, there is
only one:

# cat /proc/cpuinfo
processor : 0
vendor_id : GenuineIntel
cpu family : 6
model : 15
model name : Intel(R) Core(TM)2 CPU 6420 @ 2.13GHz
stepping : 6
cpu MHz : 600.000
cache size : 4096 KB
physical id : 0
siblings : 1
core id : 0
cpu cores : 1
fdiv_bug : no
hlt_bug : no
f00f_bug : no
coma_bug : no
fpu : yes
fpu_exception : yes
cpuid level : 10
wp : yes
flags : fpu vme de pse tsc msr pae mce cx8 apic sep mtrr pge
mca cmov pat pse36 clflush dts acpi mmx fxsr sse sse2 ss ht tm pbe nx lm
constant_tsc up pni monitor ds_cpl vmx est tm2 ssse3 cx16 xtpr lahf_lm
bogomips : 4368.97
clflush size : 64

Peter
--
Peter Valdemar Mrch
http://www.morch.com

_______________________________________________
ivtv-users mailing list
ivtv-users [at] ivtvdriver
http://ivtvdriver.org/mailman/listinfo/ivtv-users


sander.sweers at gmail

Jul 27, 2007, 11:05 AM

Post #17 of 18 (2607 views)
Permalink
Re: Periodic Lockups With IVTV Versions > 0.4.x [In reply to]

On vr, 2007-07-27 at 17:52 +0200, Peter Valdemar Mørch wrote:
> Peter Valdemar Mørch swp5jhu02-at-sneakemail.com |Lists| wrote:
> > I'm seeing similar behavior. Changing channels causes a freeze so it
> > needs a push on the reset button.
>
> I have just today discovered, that if I boot the machine with "nosmp" as
> a kernel parameter to disable SMP, it does changes channels just fine.
>
> I was inspired to try this based on this troubleshooting tip:
> http://ivtvdriver.org/index.php/Troubleshooting#IVTV_may_cause_hangs_when_run_on_an_Intel_processor_with_Hyperthreading_enabled.

Good to see people using the troubleshooting page and it being
helpfull :)

> If the other two that are also experiencing this are also on Intel Duo
> processors and disabling SMP works for them too, I guess that goes a
> long way to finding a root cause.

I thought (very limited Intel knowledge) the dual core intel chips also
have hyperthreading?

> At the very least, if I don't hear to the contrary, I'll modify the
> above troubleshooting section to include info about SMP for Intel
> processors along with hyper threading.

According to Hans this is HT only...

Greets
Sander


_______________________________________________
ivtv-users mailing list
ivtv-users [at] ivtvdriver
http://ivtvdriver.org/mailman/listinfo/ivtv-users


drescherjm at gmail

Jul 27, 2007, 11:10 AM

Post #18 of 18 (2604 views)
Permalink
Re: Periodic Lockups With IVTV Versions > 0.4.x [In reply to]

> I thought (very limited Intel knowledge) the dual core intel chips also
> have hyperthreading?
>
>From what I have heard core2 chips do not. The reason for this is they
shortened the pipeline as a result it is less wasteful and therefore
HT would not work well at all as hyperthreading makes use of pipeline
stalls to give a second thread cycles.

John

_______________________________________________
ivtv-users mailing list
ivtv-users [at] ivtvdriver
http://ivtvdriver.org/mailman/listinfo/ivtv-users

ivtv users RSS feed   Index | Next | Previous | View Threaded
 
 


Interested in having your list archived? Contact Gossamer Threads
 
  Web Applications & Managed Hosting Powered by Gossamer Threads Inc.