Advanced
Mailing List Archive

Mailing List Archive

  1. Home >
  2. ivtv>
  3. users
reboots with kernel > 2.6.22
ivtv at roosnl
Jun 11, 2009, 11:59 AM
Post #1 of 22 (16771 views)
Permalink
Hello all,

I have a PVR-500 card on a Via Epia EN15000 board. I am running Gentoo
Linux on it for MyhthTV. Ever since upgrading from kernel 2.6.22, I have
been having reboots on my system whenever it tries recording something.
Because I have had some issues with the SATA drivers on it previously, I
have always suspected that to be the problem, however, after some more
research I am now pretty sure that the IVTV driver is the culprit.

When using kernel 2.6.22 (with Gentoo patches) everything works fine. I
have tried many different kernels after that, and with all the system
eventually reboots. The current I have running is the vanilla 2.6.29.4
kernel, still the same problem.

I can easily reproduce the problem by running:

dd if=/dev/video0 of=/dev/null bs=64k count=10000

usually it reboots before it reaches 5000 blocks, sometimes it takes a
little longer, but eventually the system reboots.

I think that I rule out all other components of the system by copying to
/dev/null.

Any video recorded with the card is good (that is, when it's not sent to
/dev/null :-) )

I have checked http://www.ivtvdriver.org/index.php/Howto and everything
seems to be installed as it should be, after that I checked
http://www.ivtvdriver.org/index.php/Troubleshooting, but that does not
seem to mention anything that is describing my situation.

I have tried setting debug to 127, but I don't see anything that looks
like an error, it also doesn't display anything just before crashing.

the dmesg | tac ... etc script on the "how to ask for help" page does
not give any output, so I'll just include dmesg | grep ivtv...

I think I am using the in-kernel version of ivtv, but I am not 100%
sure, how do I check?

I have run out of options on what to try next, any ideas?


Thanks,
Jeroen


video ~ # dmesg | grep ivtv
ivtv: Start initialization, version 1.4.0
ivtv0: Initializing card 0
ivtv0: Autodetected Hauppauge card (cx23416 based)
ivtv 0000:04:08.0: PCI INT A -> GSI 17 (level, low) -> IRQ 17
ivtv0: Unreasonably low latency timer, setting to 64 (was 32)
ivtv0: Autodetected WinTV PVR 500 (unit #1)
cx25840 1-0044: cx25843-24 found @ 0x88 (ivtv i2c driver #0)
tuner 1-0060: chip found @ 0xc0 (ivtv i2c driver #0)
tuner 1-0043: chip found @ 0x86 (ivtv i2c driver #0)
tuner 1-0061: chip found @ 0xc2 (ivtv i2c driver #0)
wm8775 1-001b: chip found @ 0x36 (ivtv i2c driver #0)
IRQ 17/ivtv0: IRQF_DISABLED is not guaranteed on shared IRQs
ivtv0: Registered device video0 for encoder MPG (4096 kB)
ivtv0: Registered device video32 for encoder YUV (2048 kB)
ivtv0: Registered device vbi0 for encoder VBI (1024 kB)
ivtv0: Registered device video24 for encoder PCM (320 kB)
ivtv0: Registered device radio0 for encoder radio
ivtv0: Initialized card: WinTV PVR 500 (unit #1)
ivtv1: Initializing card 1
ivtv1: Autodetected Hauppauge card (cx23416 based)
ivtv 0000:04:09.0: PCI INT A -> GSI 18 (level, low) -> IRQ 18
ivtv1: Unreasonably low latency timer, setting to 64 (was 32)
ivtv1: Correcting tveeprom data: no radio present on second unit
ivtv1: Autodetected WinTV PVR 500 (unit #2)
cx25840 2-0044: cx25843-24 found @ 0x88 (ivtv i2c driver #1)
tuner 2-0043: chip found @ 0x86 (ivtv i2c driver #1)
tuner 2-0061: chip found @ 0xc2 (ivtv i2c driver #1)
wm8775 2-001b: chip found @ 0x36 (ivtv i2c driver #1)
IRQ 18/ivtv1: IRQF_DISABLED is not guaranteed on shared IRQs
ivtv1: Registered device video1 for encoder MPG (4096 kB)
ivtv1: Registered device video33 for encoder YUV (2048 kB)
ivtv1: Registered device vbi1 for encoder VBI (1024 kB)
ivtv1: Registered device video25 for encoder PCM (320 kB)
ivtv1: Initialized card: WinTV PVR 500 (unit #2)
ivtv: End initialization
ivtv 0000:04:08.0: firmware: requesting v4l-cx2341x-enc.fw
ivtv0: Loaded v4l-cx2341x-enc.fw firmware (376836 bytes)
ivtv0: Encoder revision: 0x02060039
ivtv 0000:04:09.0: firmware: requesting v4l-cx2341x-enc.fw
ivtv1: Loaded v4l-cx2341x-enc.fw firmware (376836 bytes)
ivtv1: Encoder revision: 0x02060039

video ~ # lspci | grep video
04:08.0 Multimedia video controller: Internext Compression Inc iTVC16
(CX23416) MPEG-2 Encoder (rev 01)
04:09.0 Multimedia video controller: Internext Compression Inc iTVC16
(CX23416) MPEG-2 Encoder (rev 01)

video ~ # uname -a
Linux video 2.6.29.4 #1 SMP Wed Jun 10 20:58:40 CEST 2009 i686 VIA
Esther processor 1500MHz CentaurHauls GNU/Linux

_______________________________________________
ivtv-users mailing list
ivtv-users@ivtvdriver.org
http://ivtvdriver.org/mailman/listinfo/ivtv-users
Re: reboots with kernel > 2.6.22 [ In reply to ]
kenmink at alumni
Jun 12, 2009, 1:11 PM
Post #2 of 22 (16562 views)
Permalink
This sounds almost exactly like the reboot issue I've been having. I'm
using a AMD processor, but the motherboard is VIA chipsets. I am running
CentOS. The kernel reports itself as 2.6.18, but there a lot of
backporting in it.

I am going to start compiling vanilla kernels and see if I can find one
where the PVR-500 is stable. I'm starting with 2.6.25 and working backwards.

I am not willing to bet on my success. My issue could easily be a
hardware problem. My gut says it's not, though.

Jeroen Roos wrote:
> Hello all,
>
> I have a PVR-500 card on a Via Epia EN15000 board. I am running Gentoo
> Linux on it for MyhthTV. Ever since upgrading from kernel 2.6.22, I have
> been having reboots on my system whenever it tries recording something.
> Because I have had some issues with the SATA drivers on it previously, I
> have always suspected that to be the problem, however, after some more
> research I am now pretty sure that the IVTV driver is the culprit.
>
> When using kernel 2.6.22 (with Gentoo patches) everything works fine. I
> have tried many different kernels after that, and with all the system
> eventually reboots. The current I have running is the vanilla 2.6.29.4
> kernel, still the same problem.
>
> I can easily reproduce the problem by running:
>
> dd if=/dev/video0 of=/dev/null bs=64k count=10000
>
> usually it reboots before it reaches 5000 blocks, sometimes it takes a
> little longer, but eventually the system reboots.
>
> I think that I rule out all other components of the system by copying to
> /dev/null.
>
> Any video recorded with the card is good (that is, when it's not sent to
> /dev/null :-) )
>
> I have checked http://www.ivtvdriver.org/index.php/Howto and everything
> seems to be installed as it should be, after that I checked
> http://www.ivtvdriver.org/index.php/Troubleshooting, but that does not
> seem to mention anything that is describing my situation.
>
> I have tried setting debug to 127, but I don't see anything that looks
> like an error, it also doesn't display anything just before crashing.
>
> the dmesg | tac ... etc script on the "how to ask for help" page does
> not give any output, so I'll just include dmesg | grep ivtv...
>
> I think I am using the in-kernel version of ivtv, but I am not 100%
> sure, how do I check?
>
> I have run out of options on what to try next, any ideas?
>
>
> Thanks,
> Jeroen
>
>
> video ~ # dmesg | grep ivtv
> ivtv: Start initialization, version 1.4.0
> ivtv0: Initializing card 0
> ivtv0: Autodetected Hauppauge card (cx23416 based)
> ivtv 0000:04:08.0: PCI INT A -> GSI 17 (level, low) -> IRQ 17
> ivtv0: Unreasonably low latency timer, setting to 64 (was 32)
> ivtv0: Autodetected WinTV PVR 500 (unit #1)
> cx25840 1-0044: cx25843-24 found @ 0x88 (ivtv i2c driver #0)
> tuner 1-0060: chip found @ 0xc0 (ivtv i2c driver #0)
> tuner 1-0043: chip found @ 0x86 (ivtv i2c driver #0)
> tuner 1-0061: chip found @ 0xc2 (ivtv i2c driver #0)
> wm8775 1-001b: chip found @ 0x36 (ivtv i2c driver #0)
> IRQ 17/ivtv0: IRQF_DISABLED is not guaranteed on shared IRQs
> ivtv0: Registered device video0 for encoder MPG (4096 kB)
> ivtv0: Registered device video32 for encoder YUV (2048 kB)
> ivtv0: Registered device vbi0 for encoder VBI (1024 kB)
> ivtv0: Registered device video24 for encoder PCM (320 kB)
> ivtv0: Registered device radio0 for encoder radio
> ivtv0: Initialized card: WinTV PVR 500 (unit #1)
> ivtv1: Initializing card 1
> ivtv1: Autodetected Hauppauge card (cx23416 based)
> ivtv 0000:04:09.0: PCI INT A -> GSI 18 (level, low) -> IRQ 18
> ivtv1: Unreasonably low latency timer, setting to 64 (was 32)
> ivtv1: Correcting tveeprom data: no radio present on second unit
> ivtv1: Autodetected WinTV PVR 500 (unit #2)
> cx25840 2-0044: cx25843-24 found @ 0x88 (ivtv i2c driver #1)
> tuner 2-0043: chip found @ 0x86 (ivtv i2c driver #1)
> tuner 2-0061: chip found @ 0xc2 (ivtv i2c driver #1)
> wm8775 2-001b: chip found @ 0x36 (ivtv i2c driver #1)
> IRQ 18/ivtv1: IRQF_DISABLED is not guaranteed on shared IRQs
> ivtv1: Registered device video1 for encoder MPG (4096 kB)
> ivtv1: Registered device video33 for encoder YUV (2048 kB)
> ivtv1: Registered device vbi1 for encoder VBI (1024 kB)
> ivtv1: Registered device video25 for encoder PCM (320 kB)
> ivtv1: Initialized card: WinTV PVR 500 (unit #2)
> ivtv: End initialization
> ivtv 0000:04:08.0: firmware: requesting v4l-cx2341x-enc.fw
> ivtv0: Loaded v4l-cx2341x-enc.fw firmware (376836 bytes)
> ivtv0: Encoder revision: 0x02060039
> ivtv 0000:04:09.0: firmware: requesting v4l-cx2341x-enc.fw
> ivtv1: Loaded v4l-cx2341x-enc.fw firmware (376836 bytes)
> ivtv1: Encoder revision: 0x02060039
>
> video ~ # lspci | grep video
> 04:08.0 Multimedia video controller: Internext Compression Inc iTVC16
> (CX23416) MPEG-2 Encoder (rev 01)
> 04:09.0 Multimedia video controller: Internext Compression Inc iTVC16
> (CX23416) MPEG-2 Encoder (rev 01)
>
> video ~ # uname -a
> Linux video 2.6.29.4 #1 SMP Wed Jun 10 20:58:40 CEST 2009 i686 VIA
> Esther processor 1500MHz CentaurHauls GNU/Linux
>
> _______________________________________________
> ivtv-users mailing list
> ivtv-users@ivtvdriver.org
> http://ivtvdriver.org/mailman/listinfo/ivtv-users


--
"They that can give up essential liberty to obtain a little temporary
safety deserve neither liberty nor safety."--Benjamin Franklin
" 'Necessity' is the plea for every infringement of human liberty; it
is the argument of tyrants; it is the creed of slaves."--William Pitt

_______________________________________________
ivtv-users mailing list
ivtv-users@ivtvdriver.org
http://ivtvdriver.org/mailman/listinfo/ivtv-users
Re: reboots with kernel > 2.6.22 [ In reply to ]
ken.ivtv at minker
Jun 12, 2009, 1:12 PM
Post #3 of 22 (16557 views)
Permalink
This sounds almost exactly like the reboot issue I've been having. I'm
using a AMD processor, but the motherboard is VIA chipsets. I am running
CentOS. The kernel reports itself as 2.6.18, but there a lot of
backporting in it.

I am going to start compiling vanilla kernels and see if I can find one
where the PVR-500 is stable. I'm starting with 2.6.25 and working backwards.

I am not willing to bet on my success. My issue could easily be a
hardware problem. My gut says it's not, though.

Jeroen Roos wrote:
> Hello all,
>
> I have a PVR-500 card on a Via Epia EN15000 board. I am running Gentoo
> Linux on it for MyhthTV. Ever since upgrading from kernel 2.6.22, I have
> been having reboots on my system whenever it tries recording something.
> Because I have had some issues with the SATA drivers on it previously, I
> have always suspected that to be the problem, however, after some more
> research I am now pretty sure that the IVTV driver is the culprit.
>
> When using kernel 2.6.22 (with Gentoo patches) everything works fine. I
> have tried many different kernels after that, and with all the system
> eventually reboots. The current I have running is the vanilla 2.6.29.4
> kernel, still the same problem.
>
> I can easily reproduce the problem by running:
>
> dd if=/dev/video0 of=/dev/null bs=64k count=10000
>
> usually it reboots before it reaches 5000 blocks, sometimes it takes a
> little longer, but eventually the system reboots.
>
> I think that I rule out all other components of the system by copying to
> /dev/null.
>
> Any video recorded with the card is good (that is, when it's not sent to
> /dev/null :-) )
>
> I have checked http://www.ivtvdriver.org/index.php/Howto and everything
> seems to be installed as it should be, after that I checked
> http://www.ivtvdriver.org/index.php/Troubleshooting, but that does not
> seem to mention anything that is describing my situation.
>
> I have tried setting debug to 127, but I don't see anything that looks
> like an error, it also doesn't display anything just before crashing.
>
> the dmesg | tac ... etc script on the "how to ask for help" page does
> not give any output, so I'll just include dmesg | grep ivtv...
>
> I think I am using the in-kernel version of ivtv, but I am not 100%
> sure, how do I check?
>
> I have run out of options on what to try next, any ideas?
>
>
> Thanks,
> Jeroen
>
>
> video ~ # dmesg | grep ivtv
> ivtv: Start initialization, version 1.4.0
> ivtv0: Initializing card 0
> ivtv0: Autodetected Hauppauge card (cx23416 based)
> ivtv 0000:04:08.0: PCI INT A -> GSI 17 (level, low) -> IRQ 17
> ivtv0: Unreasonably low latency timer, setting to 64 (was 32)
> ivtv0: Autodetected WinTV PVR 500 (unit #1)
> cx25840 1-0044: cx25843-24 found @ 0x88 (ivtv i2c driver #0)
> tuner 1-0060: chip found @ 0xc0 (ivtv i2c driver #0)
> tuner 1-0043: chip found @ 0x86 (ivtv i2c driver #0)
> tuner 1-0061: chip found @ 0xc2 (ivtv i2c driver #0)
> wm8775 1-001b: chip found @ 0x36 (ivtv i2c driver #0)
> IRQ 17/ivtv0: IRQF_DISABLED is not guaranteed on shared IRQs
> ivtv0: Registered device video0 for encoder MPG (4096 kB)
> ivtv0: Registered device video32 for encoder YUV (2048 kB)
> ivtv0: Registered device vbi0 for encoder VBI (1024 kB)
> ivtv0: Registered device video24 for encoder PCM (320 kB)
> ivtv0: Registered device radio0 for encoder radio
> ivtv0: Initialized card: WinTV PVR 500 (unit #1)
> ivtv1: Initializing card 1
> ivtv1: Autodetected Hauppauge card (cx23416 based)
> ivtv 0000:04:09.0: PCI INT A -> GSI 18 (level, low) -> IRQ 18
> ivtv1: Unreasonably low latency timer, setting to 64 (was 32)
> ivtv1: Correcting tveeprom data: no radio present on second unit
> ivtv1: Autodetected WinTV PVR 500 (unit #2)
> cx25840 2-0044: cx25843-24 found @ 0x88 (ivtv i2c driver #1)
> tuner 2-0043: chip found @ 0x86 (ivtv i2c driver #1)
> tuner 2-0061: chip found @ 0xc2 (ivtv i2c driver #1)
> wm8775 2-001b: chip found @ 0x36 (ivtv i2c driver #1)
> IRQ 18/ivtv1: IRQF_DISABLED is not guaranteed on shared IRQs
> ivtv1: Registered device video1 for encoder MPG (4096 kB)
> ivtv1: Registered device video33 for encoder YUV (2048 kB)
> ivtv1: Registered device vbi1 for encoder VBI (1024 kB)
> ivtv1: Registered device video25 for encoder PCM (320 kB)
> ivtv1: Initialized card: WinTV PVR 500 (unit #2)
> ivtv: End initialization
> ivtv 0000:04:08.0: firmware: requesting v4l-cx2341x-enc.fw
> ivtv0: Loaded v4l-cx2341x-enc.fw firmware (376836 bytes)
> ivtv0: Encoder revision: 0x02060039
> ivtv 0000:04:09.0: firmware: requesting v4l-cx2341x-enc.fw
> ivtv1: Loaded v4l-cx2341x-enc.fw firmware (376836 bytes)
> ivtv1: Encoder revision: 0x02060039
>
> video ~ # lspci | grep video
> 04:08.0 Multimedia video controller: Internext Compression Inc iTVC16
> (CX23416) MPEG-2 Encoder (rev 01)
> 04:09.0 Multimedia video controller: Internext Compression Inc iTVC16
> (CX23416) MPEG-2 Encoder (rev 01)
>
> video ~ # uname -a
> Linux video 2.6.29.4 #1 SMP Wed Jun 10 20:58:40 CEST 2009 i686 VIA
> Esther processor 1500MHz CentaurHauls GNU/Linux
>
> _______________________________________________
> ivtv-users mailing list
> ivtv-users@ivtvdriver.org
> http://ivtvdriver.org/mailman/listinfo/ivtv-users


_______________________________________________
ivtv-users mailing list
ivtv-users@ivtvdriver.org
http://ivtvdriver.org/mailman/listinfo/ivtv-users
Re: reboots with kernel > 2.6.22 [ In reply to ]
matt.beadon at gmail
Jun 12, 2009, 1:51 PM
Post #4 of 22 (16555 views)
Permalink
On Fri, Jun 12, 2009 at 1:11 PM, Ken Mink <kenmink@alumni.clemson.edu>wrote:

> This sounds almost exactly like the reboot issue I've been having. I'm
> using a AMD processor, but the motherboard is VIA chipsets. I am running
> CentOS. The kernel reports itself as 2.6.18, but there a lot of
> backporting in it.
>
> I am going to start compiling vanilla kernels and see if I can find one
> where the PVR-500 is stable. I'm starting with 2.6.25 and working
> backwards.
>
> I am not willing to bet on my success. My issue could easily be a
> hardware problem. My gut says it's not, though.
>
> Jeroen Roos wrote:
> > Hello all,
> >
> > I have a PVR-500 card on a Via Epia EN15000 board. I am running Gentoo
> > Linux on it for MyhthTV. Ever since upgrading from kernel 2.6.22, I have
> > been having reboots on my system whenever it tries recording something.
> > Because I have had some issues with the SATA drivers on it previously, I
> > have always suspected that to be the problem, however, after some more
> > research I am now pretty sure that the IVTV driver is the culprit.
> >
> > When using kernel 2.6.22 (with Gentoo patches) everything works fine. I
> > have tried many different kernels after that, and with all the system
> > eventually reboots. The current I have running is the vanilla 2.6.29.4
> > kernel, still the same problem.
> >
> > I can easily reproduce the problem by running:
> >
> > dd if=/dev/video0 of=/dev/null bs=64k count=10000
> >
> > usually it reboots before it reaches 5000 blocks, sometimes it takes a
> > little longer, but eventually the system reboots.
> >
> > I think that I rule out all other components of the system by copying to
> > /dev/null.
> >
> > Any video recorded with the card is good (that is, when it's not sent to
> > /dev/null :-) )
> >
> > I have checked http://www.ivtvdriver.org/index.php/Howto and everything
> > seems to be installed as it should be, after that I checked
> > http://www.ivtvdriver.org/index.php/Troubleshooting, but that does not
> > seem to mention anything that is describing my situation.
> >
> > I have tried setting debug to 127, but I don't see anything that looks
> > like an error, it also doesn't display anything just before crashing.
> >
> > the dmesg | tac ... etc script on the "how to ask for help" page does
> > not give any output, so I'll just include dmesg | grep ivtv...
> >
> > I think I am using the in-kernel version of ivtv, but I am not 100%
> > sure, how do I check?
>

I can't say definitively how to check but I was using the in-kernel version
for 2.6.26 (debian lenny) and got the following in my dmesg:
ivtv: Start initialization, version 1.4.1
Which is newer than the one you reported below.

>
> > I have run out of options on what to try next, any ideas?
>

How about building the latest ivtv? http://ivtvdriver.org/index.php/Howto

>
> >
> >
> > Thanks,
> > Jeroen
> >
> >
> > video ~ # dmesg | grep ivtv
> > ivtv: Start initialization, version 1.4.0
> > ivtv0: Initializing card 0
> > ivtv0: Autodetected Hauppauge card (cx23416 based)
> > ivtv 0000:04:08.0: PCI INT A -> GSI 17 (level, low) -> IRQ 17
> > ivtv0: Unreasonably low latency timer, setting to 64 (was 32)
> > ivtv0: Autodetected WinTV PVR 500 (unit #1)
> > cx25840 1-0044: cx25843-24 found @ 0x88 (ivtv i2c driver #0)
> > tuner 1-0060: chip found @ 0xc0 (ivtv i2c driver #0)
> > tuner 1-0043: chip found @ 0x86 (ivtv i2c driver #0)
> > tuner 1-0061: chip found @ 0xc2 (ivtv i2c driver #0)
> > wm8775 1-001b: chip found @ 0x36 (ivtv i2c driver #0)
> > IRQ 17/ivtv0: IRQF_DISABLED is not guaranteed on shared IRQs
> > ivtv0: Registered device video0 for encoder MPG (4096 kB)
> > ivtv0: Registered device video32 for encoder YUV (2048 kB)
> > ivtv0: Registered device vbi0 for encoder VBI (1024 kB)
> > ivtv0: Registered device video24 for encoder PCM (320 kB)
> > ivtv0: Registered device radio0 for encoder radio
> > ivtv0: Initialized card: WinTV PVR 500 (unit #1)
> > ivtv1: Initializing card 1
> > ivtv1: Autodetected Hauppauge card (cx23416 based)
> > ivtv 0000:04:09.0: PCI INT A -> GSI 18 (level, low) -> IRQ 18
> > ivtv1: Unreasonably low latency timer, setting to 64 (was 32)
> > ivtv1: Correcting tveeprom data: no radio present on second unit
> > ivtv1: Autodetected WinTV PVR 500 (unit #2)
> > cx25840 2-0044: cx25843-24 found @ 0x88 (ivtv i2c driver #1)
> > tuner 2-0043: chip found @ 0x86 (ivtv i2c driver #1)
> > tuner 2-0061: chip found @ 0xc2 (ivtv i2c driver #1)
> > wm8775 2-001b: chip found @ 0x36 (ivtv i2c driver #1)
> > IRQ 18/ivtv1: IRQF_DISABLED is not guaranteed on shared IRQs
> > ivtv1: Registered device video1 for encoder MPG (4096 kB)
> > ivtv1: Registered device video33 for encoder YUV (2048 kB)
> > ivtv1: Registered device vbi1 for encoder VBI (1024 kB)
> > ivtv1: Registered device video25 for encoder PCM (320 kB)
> > ivtv1: Initialized card: WinTV PVR 500 (unit #2)
> > ivtv: End initialization
> > ivtv 0000:04:08.0: firmware: requesting v4l-cx2341x-enc.fw
> > ivtv0: Loaded v4l-cx2341x-enc.fw firmware (376836 bytes)
> > ivtv0: Encoder revision: 0x02060039
> > ivtv 0000:04:09.0: firmware: requesting v4l-cx2341x-enc.fw
> > ivtv1: Loaded v4l-cx2341x-enc.fw firmware (376836 bytes)
> > ivtv1: Encoder revision: 0x02060039
> >
> > video ~ # lspci | grep video
> > 04:08.0 Multimedia video controller: Internext Compression Inc iTVC16
> > (CX23416) MPEG-2 Encoder (rev 01)
> > 04:09.0 Multimedia video controller: Internext Compression Inc iTVC16
> > (CX23416) MPEG-2 Encoder (rev 01)
> >
> > video ~ # uname -a
> > Linux video 2.6.29.4 #1 SMP Wed Jun 10 20:58:40 CEST 2009 i686 VIA
> > Esther processor 1500MHz CentaurHauls GNU/Linux
> >
> > _______________________________________________
> > ivtv-users mailing list
> > ivtv-users@ivtvdriver.org
> > http://ivtvdriver.org/mailman/listinfo/ivtv-users
>
>
> --
> "They that can give up essential liberty to obtain a little temporary
> safety deserve neither liberty nor safety."--Benjamin Franklin
> " 'Necessity' is the plea for every infringement of human liberty; it
> is the argument of tyrants; it is the creed of slaves."--William Pitt
>
> _______________________________________________
> ivtv-users mailing list
> ivtv-users@ivtvdriver.org
> http://ivtvdriver.org/mailman/listinfo/ivtv-users
>
Re: reboots with kernel > 2.6.22 [ In reply to ]
drescherjm at gmail
Jun 12, 2009, 2:39 PM
Post #5 of 22 (16569 views)
Permalink
On Fri, Jun 12, 2009 at 4:51 PM, Matt Beadon<matt.beadon@gmail.com> wrote:
> On Fri, Jun 12, 2009 at 1:11 PM, Ken Mink <kenmink@alumni.clemson.edu>
> wrote:
>>
>> This sounds almost exactly like the reboot issue I've been having. I'm
>> using a AMD processor, but the motherboard is VIA chipsets. I am running
>> CentOS. The kernel reports itself as 2.6.18, but there a lot of
>> backporting in it.
>>
>> I am going to start compiling vanilla kernels and see if I can find one
>> where the PVR-500 is stable. I'm starting with 2.6.25 and working
>> backwards.
>>
>> I am not willing to bet on my success. My issue could easily be a
>> hardware problem. My gut says it's not, though.
>>
>> Jeroen Roos wrote:
>> > Hello all,
>> >
>> > I have a PVR-500 card on a Via Epia EN15000 board. I am running Gentoo
>> > Linux on it for MyhthTV. Ever since upgrading from kernel 2.6.22, I have
>> > been having reboots on my system whenever it tries recording something.
>> > Because I have had some issues with the SATA drivers on it previously, I
>> >  have always suspected that to be the problem, however, after some more
>> > research I am now pretty sure that the IVTV driver is the culprit.
>> >
>> > When using kernel 2.6.22 (with Gentoo patches) everything works fine. I
>> > have tried many different kernels after that, and with all the system
>> > eventually reboots. The current I have running is the vanilla 2.6.29.4
>> > kernel, still the same problem.
>> >
>> > I can easily reproduce the problem by running:
>> >
>> > dd if=/dev/video0 of=/dev/null bs=64k count=10000
>> >
>> > usually it reboots before it reaches 5000 blocks, sometimes it takes a
>> > little longer, but eventually the system reboots.
>> >
>> > I think that I rule out all other components of the system by copying to
>> > /dev/null.
>> >
>> > Any video recorded with the card is good (that is, when it's not sent to
>> > /dev/null :-) )
>> >
>> > I have checked http://www.ivtvdriver.org/index.php/Howto and everything
>> > seems to be installed as it should be, after that I checked
>> > http://www.ivtvdriver.org/index.php/Troubleshooting, but that does not
>> > seem to mention anything that is describing my situation.
>> >
>> > I have tried setting debug to 127, but I don't see anything that looks
>> > like an error, it also doesn't display anything just before crashing.
>> >
>> > the dmesg | tac ... etc script on the "how to ask for help" page does
>> > not give any output, so I'll just include dmesg | grep ivtv...
>> >
>> > I think I am using the in-kernel version of ivtv, but I am not 100%
>> > sure, how do I check?
>
> I can't say definitively how to check but I was using the in-kernel version
> for 2.6.26 (debian lenny) and got the following in my dmesg:
> ivtv: Start initialization, version 1.4.1
> Which is newer than the one you reported below.
>
>> >
>> > I have run out of options on what to try next, any ideas?
>
> How about building the latest ivtv?  http://ivtvdriver.org/index.php/Howto
>>

On gentoo if you want to do that remove/disable ivtv from the kernel.

Remove media-tv/ivtv

and install

media-tv/v4l-dvb-hg-0.1-r3 and media-tv/ivtv-utils

John

_______________________________________________
ivtv-users mailing list
ivtv-users@ivtvdriver.org
http://ivtvdriver.org/mailman/listinfo/ivtv-users
Re: reboots with kernel > 2.6.22 [ In reply to ]
ivtv at roosnl
Aug 17, 2009, 2:29 AM
Post #6 of 22 (15989 views)
Permalink
On Thursday 11 June 2009 20:59:55 Jeroen Roos wrote:
Hello all,

I reported this problem to the list some time ago. Unfortunately I have not
had much time to look into it.

> I have a PVR-500 card on a Via Epia EN15000 board. I am running Gentoo
> Linux on it for MyhthTV. Ever since upgrading from kernel 2.6.22, I have
> been having reboots on my system whenever it tries recording something.
> Because I have had some issues with the SATA drivers on it previously, I
> have always suspected that to be the problem, however, after some more
> research I am now pretty sure that the IVTV driver is the culprit.

There were a few replies, most regarding the ivtv version I was using (1.4.0).
I have now upgraded to a newer kernel; tried both Gentoo's 2.6.30-gentoo-r4
and the vanilla 2.6.30.3 kernels and, unfortunately, the issue remains.

At least I am now on 1.4.1:
jeroen@video ~ $ dmesg | grep ivtv | grep version
ivtv: Start initialization, version 1.4.1

> I can easily reproduce the problem by running:
>
> dd if=/dev/video0 of=/dev/null bs=64k count=10000
>
> usually it reboots before it reaches 5000 blocks, sometimes it takes a
> little longer, but eventually the system reboots.
>
> I think that I rule out all other components of the system by copying to
> /dev/null.

I can still consistently trigger a reboot with this command.

Any ideas?

Thanks & best regards,
Jeroen


Some more info:

jeroen@video ~ $ dmesg | grep ivtv
ivtv: Start initialization, version 1.4.1
ivtv0: Initializing card 0
ivtv0: Autodetected Hauppauge card (cx23416 based)
ivtv 0000:04:08.0: PCI INT A -> GSI 17 (level, low) -> IRQ 17
ivtv0: Unreasonably low latency timer, setting to 64 (was 32)
ivtv0: Autodetected WinTV PVR 500 (unit #1)
cx25840 1-0044: cx25843-24 found @ 0x88 (ivtv i2c driver #0)
tuner 1-0060: chip found @ 0xc0 (ivtv i2c driver #0)
tuner 1-0043: chip found @ 0x86 (ivtv i2c driver #0)
tuner 1-0061: chip found @ 0xc2 (ivtv i2c driver #0)
wm8775 1-001b: chip found @ 0x36 (ivtv i2c driver #0)
IRQ 17/ivtv0: IRQF_DISABLED is not guaranteed on shared IRQs
ivtv0: Registered device video0 for encoder MPG (4096 kB)
ivtv0: Registered device video32 for encoder YUV (2048 kB)
ivtv0: Registered device vbi0 for encoder VBI (1024 kB)
ivtv0: Registered device video24 for encoder PCM (320 kB)
ivtv0: Registered device radio0 for encoder radio
ivtv0: Initialized card: WinTV PVR 500 (unit #1)
ivtv1: Initializing card 1
ivtv1: Autodetected Hauppauge card (cx23416 based)
ivtv 0000:04:09.0: PCI INT A -> GSI 18 (level, low) -> IRQ 18
ivtv1: Unreasonably low latency timer, setting to 64 (was 32)
ivtv1: Correcting tveeprom data: no radio present on second unit
ivtv1: Autodetected WinTV PVR 500 (unit #2)
cx25840 2-0044: cx25843-24 found @ 0x88 (ivtv i2c driver #1)
tuner 2-0043: chip found @ 0x86 (ivtv i2c driver #1)
tuner 2-0061: chip found @ 0xc2 (ivtv i2c driver #1)
wm8775 2-001b: chip found @ 0x36 (ivtv i2c driver #1)
IRQ 18/ivtv1: IRQF_DISABLED is not guaranteed on shared IRQs
ivtv1: Registered device video1 for encoder MPG (4096 kB)
ivtv1: Registered device video33 for encoder YUV (2048 kB)
ivtv1: Registered device vbi1 for encoder VBI (1024 kB)
ivtv1: Registered device video25 for encoder PCM (320 kB)
ivtv1: Initialized card: WinTV PVR 500 (unit #2)
ivtv: End initialization
ivtv 0000:04:08.0: firmware: requesting v4l-cx2341x-enc.fw
ivtv0: Loaded v4l-cx2341x-enc.fw firmware (376836 bytes)
ivtv0: Encoder revision: 0x02060039
ivtv 0000:04:09.0: firmware: requesting v4l-cx2341x-enc.fw
ivtv1: Loaded v4l-cx2341x-enc.fw firmware (376836 bytes)
ivtv1: Encoder revision: 0x02060039




video ~ # lspci | grep video
04:08.0 Multimedia video controller: Internext Compression Inc iTVC16
(CX23416) MPEG-2 Encoder (rev 01)
04:09.0 Multimedia video controller: Internext Compression Inc iTVC16
(CX23416) MPEG-2 Encoder (rev 01)

video ~ # uname -a
Linux video 2.6.30.3 #1 SMP Mon Aug 17 09:49:43 CEST 2009 i686 VIA Esther
processor 1500MHz CentaurHauls GNU/Linux


_______________________________________________
ivtv-users mailing list
ivtv-users@ivtvdriver.org
http://ivtvdriver.org/mailman/listinfo/ivtv-users
Re: reboots with kernel > 2.6.22 [ In reply to ]
ivtv at roosnl
Aug 23, 2009, 1:18 AM
Post #7 of 22 (15945 views)
Permalink
Unfortunately I have not received any replies on this, is there anyone
who can help me? It doesn't have to be the solution, I'd be very happy
with some tips on how to continue troubleshooting... Thanks!

On Thursday 11 June 2009 20:59:55 Jeroen Roos wrote:
Hello all,

I reported this problem to the list some time ago. Unfortunately I have not
had much time to look into it.

> I have a PVR-500 card on a Via Epia EN15000 board. I am running Gentoo
> Linux on it for MyhthTV. Ever since upgrading from kernel 2.6.22, I have
> been having reboots on my system whenever it tries recording something.
> Because I have had some issues with the SATA drivers on it previously, I
> have always suspected that to be the problem, however, after some more
> research I am now pretty sure that the IVTV driver is the culprit.

There were a few replies, most regarding the ivtv version I was using
(1.4.0).
I have now upgraded to a newer kernel; tried both Gentoo's 2.6.30-gentoo-r4
and the vanilla 2.6.30.3 kernels and, unfortunately, the issue remains.

At least I am now on 1.4.1:
jeroen@video ~ $ dmesg | grep ivtv | grep version
ivtv: Start initialization, version 1.4.1

> I can easily reproduce the problem by running:
>
> dd if=/dev/video0 of=/dev/null bs=64k count=10000
>
> usually it reboots before it reaches 5000 blocks, sometimes it takes a
> little longer, but eventually the system reboots.
>
> I think that I rule out all other components of the system by copying to
> /dev/null.

I can still consistently trigger a reboot with this command.

Any ideas?

Thanks & best regards,
Jeroen


Some more info:

jeroen@video ~ $ dmesg | grep ivtv
ivtv: Start initialization, version 1.4.1
ivtv0: Initializing card 0
ivtv0: Autodetected Hauppauge card (cx23416 based)
ivtv 0000:04:08.0: PCI INT A -> GSI 17 (level, low) -> IRQ 17
ivtv0: Unreasonably low latency timer, setting to 64 (was 32)
ivtv0: Autodetected WinTV PVR 500 (unit #1)
cx25840 1-0044: cx25843-24 found @ 0x88 (ivtv i2c driver #0)
tuner 1-0060: chip found @ 0xc0 (ivtv i2c driver #0)
tuner 1-0043: chip found @ 0x86 (ivtv i2c driver #0)
tuner 1-0061: chip found @ 0xc2 (ivtv i2c driver #0)
wm8775 1-001b: chip found @ 0x36 (ivtv i2c driver #0)
IRQ 17/ivtv0: IRQF_DISABLED is not guaranteed on shared IRQs
ivtv0: Registered device video0 for encoder MPG (4096 kB)
ivtv0: Registered device video32 for encoder YUV (2048 kB)
ivtv0: Registered device vbi0 for encoder VBI (1024 kB)
ivtv0: Registered device video24 for encoder PCM (320 kB)
ivtv0: Registered device radio0 for encoder radio
ivtv0: Initialized card: WinTV PVR 500 (unit #1)
ivtv1: Initializing card 1
ivtv1: Autodetected Hauppauge card (cx23416 based)
ivtv 0000:04:09.0: PCI INT A -> GSI 18 (level, low) -> IRQ 18
ivtv1: Unreasonably low latency timer, setting to 64 (was 32)
ivtv1: Correcting tveeprom data: no radio present on second unit
ivtv1: Autodetected WinTV PVR 500 (unit #2)
cx25840 2-0044: cx25843-24 found @ 0x88 (ivtv i2c driver #1)
tuner 2-0043: chip found @ 0x86 (ivtv i2c driver #1)
tuner 2-0061: chip found @ 0xc2 (ivtv i2c driver #1)
wm8775 2-001b: chip found @ 0x36 (ivtv i2c driver #1)
IRQ 18/ivtv1: IRQF_DISABLED is not guaranteed on shared IRQs
ivtv1: Registered device video1 for encoder MPG (4096 kB)
ivtv1: Registered device video33 for encoder YUV (2048 kB)
ivtv1: Registered device vbi1 for encoder VBI (1024 kB)
ivtv1: Registered device video25 for encoder PCM (320 kB)
ivtv1: Initialized card: WinTV PVR 500 (unit #2)
ivtv: End initialization
ivtv 0000:04:08.0: firmware: requesting v4l-cx2341x-enc.fw
ivtv0: Loaded v4l-cx2341x-enc.fw firmware (376836 bytes)
ivtv0: Encoder revision: 0x02060039
ivtv 0000:04:09.0: firmware: requesting v4l-cx2341x-enc.fw
ivtv1: Loaded v4l-cx2341x-enc.fw firmware (376836 bytes)
ivtv1: Encoder revision: 0x02060039




video ~ # lspci | grep video
04:08.0 Multimedia video controller: Internext Compression Inc iTVC16
(CX23416) MPEG-2 Encoder (rev 01)
04:09.0 Multimedia video controller: Internext Compression Inc iTVC16
(CX23416) MPEG-2 Encoder (rev 01)

video ~ # uname -a
Linux video 2.6.30.3 #1 SMP Mon Aug 17 09:49:43 CEST 2009 i686 VIA Esther
processor 1500MHz CentaurHauls GNU/Linux


_______________________________________________
ivtv-users mailing list
ivtv-users@ivtvdriver.org
http://ivtvdriver.org/mailman/listinfo/ivtv-users


_______________________________________________
ivtv-users mailing list
ivtv-users@ivtvdriver.org
http://ivtvdriver.org/mailman/listinfo/ivtv-users
Re: reboots with kernel > 2.6.22 [ In reply to ]
m+ivtv at mattyo
Aug 23, 2009, 5:27 AM
Post #8 of 22 (15958 views)
Permalink
Jeroen Roos wrote:
> I have a PVR-500 card on a Via Epia EN15000 board. I am running Gentoo
> Linux on it for MyhthTV. Ever since upgrading from kernel 2.6.22, I have
> been having reboots on my system whenever it tries recording something.


Hi, I have no ideas, but I found this reference to someone having
a problem with that motherboard rebooting while _playing_ video
under Windows MCE:

http://thegreenbutton.com/forums/p/31994/173737.aspx#173737

That's without a PVR-500 AFAICT, but maybe it points to a mobo issue
with high disk or PCI usage. Just random thoughts....

-Matt

_______________________________________________
ivtv-users mailing list
ivtv-users@ivtvdriver.org
http://ivtvdriver.org/mailman/listinfo/ivtv-users
Re: reboots with kernel > 2.6.22 [ In reply to ]
awalls at radix
Aug 23, 2009, 6:27 AM
Post #9 of 22 (15959 views)
Permalink
On Sun, 2009-08-23 at 10:18 +0200, Jeroen Roos wrote:
> Unfortunately I have not received any replies on this, is there anyone
> who can help me? It doesn't have to be the solution, I'd be very happy
> with some tips on how to continue troubleshooting... Thanks!

Well, looking through the lessons of the past:

http://www.google.com/search?q=ivtv+PVR-500+VIA+reboot
http://www.gossamer-threads.com/lists/engine?list=ivtv&do=search_results&search_forum=forum_2&search_string=VIA+ivtv+reboot+PVR-500&search_type=AND

you are not the first to have a problem with a VIA PCI chipset and the
Hint Corp PCI bridge on the PVR-500.


The reboot is caused by hardware interactions, causing the VIA PCI
chipset to decide to reboot the system.

Those detremental hardware interactions are set in motion by the ivtv
driver, CX23416 firmware, and kernel software.

What are the software actions causing the reboot? Who knows...

Without detailed chipset data from VIA, details on the Hint Corp bridge
on the PVR-500, and details on how your BIOS and the linux kernel are
configuring those chipsets, troubleshooting the issue to the root cause
through analysis and hypothesis testing has low probably of being
successful in any reasonable timeframe. (The hours you may spend
troubleshooting could cost more in labor, than buying two PVR-150's off
of eBay.)

Unfortunately this is a system level issue with many unknowns, little
documentation available, and very few test points from which to gain
insight. The reboot by hardware means no diagnostic information can be
recorded to disk or a serial port when the problem happens.

I can say that with the new kernel you are using, the implications of
these messages looks worth investigating:

IRQ 17/ivtv0: IRQF_DISABLED is not guaranteed on shared IRQs
IRQ 18/ivtv1: IRQF_DISABLED is not guaranteed on shared IRQs

Other than digging into that, you can try what others have tried in the
past in the links above.

(Forgive me, maybe I'm just in a pessimistic mood this morning.)

Regards,
Andy

> On Thursday 11 June 2009 20:59:55 Jeroen Roos wrote:
> Hello all,
>
> I reported this problem to the list some time ago. Unfortunately I have not
> had much time to look into it.
>
> > I have a PVR-500 card on a Via Epia EN15000 board. I am running Gentoo
> > Linux on it for MyhthTV. Ever since upgrading from kernel 2.6.22, I have
> > been having reboots on my system whenever it tries recording something.
> > Because I have had some issues with the SATA drivers on it previously, I
> > have always suspected that to be the problem, however, after some more
> > research I am now pretty sure that the IVTV driver is the culprit.
>
> There were a few replies, most regarding the ivtv version I was using
> (1.4.0).
> I have now upgraded to a newer kernel; tried both Gentoo's 2.6.30-gentoo-r4
> and the vanilla 2.6.30.3 kernels and, unfortunately, the issue remains.
>
> At least I am now on 1.4.1:
> jeroen@video ~ $ dmesg | grep ivtv | grep version
> ivtv: Start initialization, version 1.4.1
>
> > I can easily reproduce the problem by running:
> >
> > dd if=/dev/video0 of=/dev/null bs=64k count=10000
> >
> > usually it reboots before it reaches 5000 blocks, sometimes it takes a
> > little longer, but eventually the system reboots.
> >
> > I think that I rule out all other components of the system by copying to
> > /dev/null.
>
> I can still consistently trigger a reboot with this command.
>
> Any ideas?
>
> Thanks & best regards,
> Jeroen



_______________________________________________
ivtv-users mailing list
ivtv-users@ivtvdriver.org
http://ivtvdriver.org/mailman/listinfo/ivtv-users
Re: reboots with kernel > 2.6.22 [ In reply to ]
ivtv at roosnl
Aug 23, 2009, 8:08 AM
Post #10 of 22 (15947 views)
Permalink
m+ivtv@mattyo.net wrote:

> Hi, I have no ideas, but I found this reference to someone having
> a problem with that motherboard rebooting while _playing_ video
> under Windows MCE:
>
> http://thegreenbutton.com/forums/p/31994/173737.aspx#173737
>
> That's without a PVR-500 AFAICT, but maybe it points to a mobo issue
> with high disk or PCI usage. Just random thoughts....

Thanks for your reply.

I think the issue only exists when copying from /dev/video0 or
/dev/video1, so not any PCI / disk activity.

I have done a few tests, copying a large amount of data
- from /dev/video0 to /dev/null,
- from /dev/video0 to a disk file
- from /dev/urandom to /dev/null
- from /dev/urandom to a disk file
- from a disk file to another disk file

Only the first two cause a reboot.

Also, I don't have any issues playing video, only when recording. (I did
have issues with that before, it turned out to be the CPU frequency
scaling, when the cpufreqd changed the frequency, the system would crash
or reboot - and since it usually did that when starting a playback...)

Thanks,
Jeroen


_______________________________________________
ivtv-users mailing list
ivtv-users@ivtvdriver.org
http://ivtvdriver.org/mailman/listinfo/ivtv-users
Re: reboots with kernel > 2.6.22 [ In reply to ]
jeroen at roosnl
Aug 23, 2009, 8:52 AM
Post #11 of 22 (15944 views)
Permalink
Andy Walls wrote:
> Well, looking through the lessons of the past:
>
> http://www.google.com/search?q=ivtv+PVR-500+VIA+reboot
> http://www.gossamer-threads.com/lists/engine?list=ivtv&do=search_results&search_forum=forum_2&search_string=VIA+ivtv+reboot+PVR-500&search_type=AND

Thanks for your reply, I checked those out and ran a few extra tests:

- Adding "noapic nolapic pci=noacpi acpi=off" to my kernel, as found on
http://ivtvdriver.org/index.php/Via_motherboard_problems

- setpci -s 00:0c.0 COMMAND=0107 (the exact opposite from
http://www.gossamer-threads.com/lists/ivtv/users/38179?search_string=VIA%20ivtv%20reboot%20PVR-500;#38179,
since mine was already reporting 0007 to start with)

Neither solved the problem, unfortunately.

> you are not the first to have a problem with a VIA PCI chipset and the
> Hint Corp PCI bridge on the PVR-500.
>
>
> The reboot is caused by hardware interactions, causing the VIA PCI
> chipset to decide to reboot the system.
>
> Those detremental hardware interactions are set in motion by the ivtv
> driver, CX23416 firmware, and kernel software.
>
> What are the software actions causing the reboot? Who knows...

The strange thing is, that with a kernel before 2.6.22, I did not have
these issues, so that would point to something software, not hardware
related (or at least a hardware problem that can be avoided).

> I can say that with the new kernel you are using, the implications of
> these messages looks worth investigating:
>
> IRQ 17/ivtv0: IRQF_DISABLED is not guaranteed on shared IRQs
> IRQ 18/ivtv1: IRQF_DISABLED is not guaranteed on shared IRQs
>
> Other than digging into that, you can try what others have tried in the
> past in the links above.

So, how can I investigate that? I am sorry, I am quite an experienced
Linux user, but the kernel is mostly a black box for me...

Thanks again,
Jeroen

_______________________________________________
ivtv-users mailing list
ivtv-users@ivtvdriver.org
http://ivtvdriver.org/mailman/listinfo/ivtv-users
Re: reboots with kernel > 2.6.22 [ In reply to ]
ivtv at roosnl
Aug 23, 2009, 8:53 AM
Post #12 of 22 (15937 views)
Permalink
Andy Walls wrote:
> Well, looking through the lessons of the past:
>
> http://www.google.com/search?q=ivtv+PVR-500+VIA+reboot
> http://www.gossamer-threads.com/lists/engine?list=ivtv&do=search_results&search_forum=forum_2&search_string=VIA+ivtv+reboot+PVR-500&search_type=AND

Thanks for your reply, I checked those out and ran a few extra tests:

- Adding "noapic nolapic pci=noacpi acpi=off" to my kernel, as found on
http://ivtvdriver.org/index.php/Via_motherboard_problems

- setpci -s 00:0c.0 COMMAND=0107 (the exact opposite from
http://www.gossamer-threads.com/lists/ivtv/users/38179?search_string=VIA%20ivtv%20reboot%20PVR-500;#38179,
since mine was already reporting 0007 to start with)

Neither solved the problem, unfortunately.

> you are not the first to have a problem with a VIA PCI chipset and the
> Hint Corp PCI bridge on the PVR-500.
>
>
> The reboot is caused by hardware interactions, causing the VIA PCI
> chipset to decide to reboot the system.
>
> Those detremental hardware interactions are set in motion by the ivtv
> driver, CX23416 firmware, and kernel software.
>
> What are the software actions causing the reboot? Who knows...

The strange thing is, that with a kernel before 2.6.22, I did not have
these issues, so that would point to something software, not hardware
related (or at least a hardware problem that can be avoided).

> I can say that with the new kernel you are using, the implications of
> these messages looks worth investigating:
>
> IRQ 17/ivtv0: IRQF_DISABLED is not guaranteed on shared IRQs
> IRQ 18/ivtv1: IRQF_DISABLED is not guaranteed on shared IRQs
>
> Other than digging into that, you can try what others have tried in the
> past in the links above.

So, how can I investigate that? I am sorry, I am quite an experienced
Linux user, but the kernel is mostly a black box for me...

Thanks again,
Jeroen


_______________________________________________
ivtv-users mailing list
ivtv-users@ivtvdriver.org
http://ivtvdriver.org/mailman/listinfo/ivtv-users
Re: reboots with kernel > 2.6.22 [ In reply to ]
awalls at radix
Aug 23, 2009, 9:55 AM
Post #13 of 22 (15970 views)
Permalink
On Sun, 2009-08-23 at 17:53 +0200, Jeroen Roos wrote:
> Andy Walls wrote:
> > Well, looking through the lessons of the past:
> >
> > http://www.google.com/search?q=ivtv+PVR-500+VIA+reboot
> > http://www.gossamer-threads.com/lists/engine?list=ivtv&do=search_results&search_forum=forum_2&search_string=VIA+ivtv+reboot+PVR-500&search_type=AND
>
> Thanks for your reply, I checked those out and ran a few extra tests:
>
> - Adding "noapic nolapic pci=noacpi acpi=off" to my kernel, as found on
> http://ivtvdriver.org/index.php/Via_motherboard_problems
>
> - setpci -s 00:0c.0 COMMAND=0107 (the exact opposite from
> http://www.gossamer-threads.com/lists/ivtv/users/38179?search_string=VIA%20ivtv%20reboot%20PVR-500;#38179,
> since mine was already reporting 0007 to start with)
>
> Neither solved the problem, unfortunately.

Not surprising.


> > you are not the first to have a problem with a VIA PCI chipset and the
> > Hint Corp PCI bridge on the PVR-500.
> >
> >
> > The reboot is caused by hardware interactions, causing the VIA PCI
> > chipset to decide to reboot the system.
> >
> > Those detremental hardware interactions are set in motion by the ivtv
> > driver, CX23416 firmware, and kernel software.
> >
> > What are the software actions causing the reboot? Who knows...
>
> The strange thing is, that with a kernel before 2.6.22, I did not have
> these issues, so that would point to something software, not hardware
> related (or at least a hardware problem that can be avoided).

A hardware problem that can be avoided sounds correct. Without detailed
insight into the PCI chipsets, your best course of action is to do some
differential analysis:

1. Find that latest kernel that still works and the earliest kernel that
does not.

A binary search will terminate in a few trials, e.g. .30, .26, .24, .23.
(I suspect this could be painful on a Gentoo system, if you have to
rebuild each kernel.)

2. Diff the source tree of the two kernels.

3. Analyze the diff for the change that may have caused the problem.

That will narrow the cause down from "anything" to "one of these
changes". That changeset still could be rather large.


> > I can say that with the new kernel you are using, the implications of
> > these messages looks worth investigating:
> >
> > IRQ 17/ivtv0: IRQF_DISABLED is not guaranteed on shared IRQs
> > IRQ 18/ivtv1: IRQF_DISABLED is not guaranteed on shared IRQs
> >
> > Other than digging into that, you can try what others have tried in the
> > past in the links above.
>
> So, how can I investigate that? I am sorry, I am quite an experienced
> Linux user, but the kernel is mostly a black box for me...

Hmm. Upon reflection, it may not be important. What the kernel is
trying to say is that ivtv's interrupt handler may get interrupted under
certain circumstances. The guranatee that ivtv's interrupt handler for
a certain IRQ line will be serialized (ivtv's irq handler can't be
called while ivtv's irq handler is interrupted) should still be in
place.

Let's defer looking into this. You'll make the most ground with
differential analysis.


Regards,
Andy

> Thanks again,
> Jeroen


_______________________________________________
ivtv-users mailing list
ivtv-users@ivtvdriver.org
http://ivtvdriver.org/mailman/listinfo/ivtv-users
Re: reboots with kernel > 2.6.22 [ In reply to ]
hverkuil at xs4all
Aug 23, 2009, 12:29 PM
Post #14 of 22 (15939 views)
Permalink
On Sunday 23 August 2009 18:55:41 Andy Walls wrote:
> On Sun, 2009-08-23 at 17:53 +0200, Jeroen Roos wrote:
> > Andy Walls wrote:
> > > Well, looking through the lessons of the past:
> > >
> > > http://www.google.com/search?q=ivtv+PVR-500+VIA+reboot
> > > http://www.gossamer-threads.com/lists/engine?list=ivtv&do=search_resu
> > >lts&search_forum=forum_2&search_string=VIA+ivtv+reboot+PVR-500&search_
> > >type=AND
> >
> > Thanks for your reply, I checked those out and ran a few extra tests:
> >
> > - Adding "noapic nolapic pci=noacpi acpi=off" to my kernel, as found on
> > http://ivtvdriver.org/index.php/Via_motherboard_problems
> >
> > - setpci -s 00:0c.0 COMMAND=0107 (the exact opposite from
> > http://www.gossamer-threads.com/lists/ivtv/users/38179?search_string=VI
> >A%20ivtv%20reboot%20PVR-500;#38179, since mine was already reporting
> > 0007 to start with)
> >
> > Neither solved the problem, unfortunately.
>
> Not surprising.
>
> > > you are not the first to have a problem with a VIA PCI chipset and
> > > the Hint Corp PCI bridge on the PVR-500.
> > >
> > >
> > > The reboot is caused by hardware interactions, causing the VIA PCI
> > > chipset to decide to reboot the system.
> > >
> > > Those detremental hardware interactions are set in motion by the ivtv
> > > driver, CX23416 firmware, and kernel software.
> > >
> > > What are the software actions causing the reboot? Who knows...
> >
> > The strange thing is, that with a kernel before 2.6.22, I did not have
> > these issues, so that would point to something software, not hardware
> > related (or at least a hardware problem that can be avoided).
>
> A hardware problem that can be avoided sounds correct. Without detailed
> insight into the PCI chipsets, your best course of action is to do some
> differential analysis:
>
> 1. Find that latest kernel that still works and the earliest kernel that
> does not.
>
> A binary search will terminate in a few trials, e.g. .30, .26, .24, .23.
> (I suspect this could be painful on a Gentoo system, if you have to
> rebuild each kernel.)
>
> 2. Diff the source tree of the two kernels.
>
> 3. Analyze the diff for the change that may have caused the problem.
>
> That will narrow the cause down from "anything" to "one of these
> changes". That changeset still could be rather large.
>
> > > I can say that with the new kernel you are using, the implications of
> > > these messages looks worth investigating:
> > >
> > > IRQ 17/ivtv0: IRQF_DISABLED is not guaranteed on shared IRQs
> > > IRQ 18/ivtv1: IRQF_DISABLED is not guaranteed on shared IRQs
> > >
> > > Other than digging into that, you can try what others have tried in
> > > the past in the links above.
> >
> > So, how can I investigate that? I am sorry, I am quite an experienced
> > Linux user, but the kernel is mostly a black box for me...
>
> Hmm. Upon reflection, it may not be important. What the kernel is
> trying to say is that ivtv's interrupt handler may get interrupted under
> certain circumstances. The guranatee that ivtv's interrupt handler for
> a certain IRQ line will be serialized (ivtv's irq handler can't be
> called while ivtv's irq handler is interrupted) should still be in
> place.
>
> Let's defer looking into this. You'll make the most ground with
> differential analysis.

Hmm, the problem with that is that 2.6.22 is the moment that ivtv was
finally merged into the kernel. So you probably end up with the merger of
ivtv as being the moment it broke :-) Not useful that.

The core problem is that 1) you're the first reporter of this problem, 2) it
doesn't happen on non-VIA PCs (at least, to my knowledge), 3) I strongly
suspect that it might be related to the PCI bridge on the PVR-500 together
with some interaction in other parts of the kernel. I actually have one
server that refuses to boot if I install an PVR-500. These things are very
hard to debug and, to be very honest, it is simply not worth the time to
attempt to resolve this.

It doesn't help you at all, I realize that, but it's the truth. It would be
different if I see such bug reports all the time, but that is not the case.

Regards,

Hans

--
Hans Verkuil - video4linux developer - sponsored by TANDBERG

_______________________________________________
ivtv-users mailing list
ivtv-users@ivtvdriver.org
http://ivtvdriver.org/mailman/listinfo/ivtv-users
Re: reboots with kernel > 2.6.22 [ In reply to ]
ivtv at roosnl
Aug 23, 2009, 12:58 PM
Post #15 of 22 (15949 views)
Permalink
Andy Walls wrote:
> 1. Find that latest kernel that still works and the earliest kernel that
> does not.
>
> A binary search will terminate in a few trials, e.g. .30, .26, .24, .23.
> (I suspect this could be painful on a Gentoo system, if you have to
> rebuild each kernel.)
I have done this in the past, unfortunately not down to patchlevel, but
I have found that linux-2.6.22-gentoo-r8 works and
linux-2.6.23-gentoo-r3 not. I have just booted from the first and did
not have the reboot issue there. Unfortunately I no longer have a
compiled version of the .23 release, and I cannot compile them anymore
since they cannot be compiled with gcc 4.3

> 2. Diff the source tree of the two kernels.

video src # diff -r linux-2.6.22-gentoo-r9 linux-2.6.23-gentoo-r3 | wc -l
472301

....mmmmm little bit too much

>
> 3. Analyze the diff for the change that may have caused the problem.
>
> That will narrow the cause down from "anything" to "one of these
> changes". That changeset still could be rather large.

Indeed, but if I just check the ivtv part, it goes down:

video ~ # cd /usr/src/linux-2.6.22-gentoo-r9/drivers/media/video/
video video # diff -r ivtv
/usr/src/linux-2.6.23-gentoo-r3/drivers/media/video/ivtv | wc -l
556

Also, a reasonable part of that is changes in comments and printed text.

I think it's a bit too big to include in or attach to the mail, but for
anyone interested, there's a unified diff (diff -uN) at
http://thuis.tuxinet.nl/ivtv.patch.


Jeroen

_______________________________________________
ivtv-users mailing list
ivtv-users@ivtvdriver.org
http://ivtvdriver.org/mailman/listinfo/ivtv-users
Re: reboots with kernel > 2.6.22 [ In reply to ]
hverkuil at xs4all
Aug 23, 2009, 1:07 PM
Post #16 of 22 (15950 views)
Permalink
On Sunday 23 August 2009 21:29:18 Hans Verkuil wrote:
> On Sunday 23 August 2009 18:55:41 Andy Walls wrote:
> > On Sun, 2009-08-23 at 17:53 +0200, Jeroen Roos wrote:
> > > Andy Walls wrote:
> > > > Well, looking through the lessons of the past:
> > > >
> > > > http://www.google.com/search?q=ivtv+PVR-500+VIA+reboot
> > > > http://www.gossamer-threads.com/lists/engine?list=ivtv&do=search_re
> > > >su
> > > > lts&search_forum=forum_2&search_string=VIA+ivtv+reboot+PVR-500&sear
> > > >ch_ type=AND
> > >
> > > Thanks for your reply, I checked those out and ran a few extra tests:
> > >
> > > - Adding "noapic nolapic pci=noacpi acpi=off" to my kernel, as found
> > > on http://ivtvdriver.org/index.php/Via_motherboard_problems
> > >
> > > - setpci -s 00:0c.0 COMMAND=0107 (the exact opposite from
> > > http://www.gossamer-threads.com/lists/ivtv/users/38179?search_string=
> > >VI A%20ivtv%20reboot%20PVR-500;#38179, since mine was already
> > > reporting 0007 to start with)
> > >
> > > Neither solved the problem, unfortunately.
> >
> > Not surprising.
> >
> > > > you are not the first to have a problem with a VIA PCI chipset and
> > > > the Hint Corp PCI bridge on the PVR-500.
> > > >
> > > >
> > > > The reboot is caused by hardware interactions, causing the VIA PCI
> > > > chipset to decide to reboot the system.
> > > >
> > > > Those detremental hardware interactions are set in motion by the
> > > > ivtv driver, CX23416 firmware, and kernel software.
> > > >
> > > > What are the software actions causing the reboot? Who knows...
> > >
> > > The strange thing is, that with a kernel before 2.6.22, I did not
> > > have these issues, so that would point to something software, not
> > > hardware related (or at least a hardware problem that can be
> > > avoided).
> >
> > A hardware problem that can be avoided sounds correct. Without
> > detailed insight into the PCI chipsets, your best course of action is
> > to do some differential analysis:
> >
> > 1. Find that latest kernel that still works and the earliest kernel
> > that does not.
> >
> > A binary search will terminate in a few trials, e.g. .30, .26, .24,
> > .23. (I suspect this could be painful on a Gentoo system, if you have
> > to rebuild each kernel.)
> >
> > 2. Diff the source tree of the two kernels.
> >
> > 3. Analyze the diff for the change that may have caused the problem.
> >
> > That will narrow the cause down from "anything" to "one of these
> > changes". That changeset still could be rather large.
> >
> > > > I can say that with the new kernel you are using, the implications
> > > > of these messages looks worth investigating:
> > > >
> > > > IRQ 17/ivtv0: IRQF_DISABLED is not guaranteed on shared IRQs
> > > > IRQ 18/ivtv1: IRQF_DISABLED is not guaranteed on shared IRQs
> > > >
> > > > Other than digging into that, you can try what others have tried in
> > > > the past in the links above.
> > >
> > > So, how can I investigate that? I am sorry, I am quite an experienced
> > > Linux user, but the kernel is mostly a black box for me...
> >
> > Hmm. Upon reflection, it may not be important. What the kernel is
> > trying to say is that ivtv's interrupt handler may get interrupted
> > under certain circumstances. The guranatee that ivtv's interrupt
> > handler for a certain IRQ line will be serialized (ivtv's irq handler
> > can't be called while ivtv's irq handler is interrupted) should still
> > be in place.
> >
> > Let's defer looking into this. You'll make the most ground with
> > differential analysis.
>
> Hmm, the problem with that is that 2.6.22 is the moment that ivtv was
> finally merged into the kernel. So you probably end up with the merger of
> ivtv as being the moment it broke :-) Not useful that.

Sorry, ignore this. I thought that it was broken in 2.6.22, but it broke in
2.6.23. In that case the binary search method might well result in
something useful.

Regards,

Hans

>
> The core problem is that 1) you're the first reporter of this problem, 2)
> it doesn't happen on non-VIA PCs (at least, to my knowledge), 3) I
> strongly suspect that it might be related to the PCI bridge on the
> PVR-500 together with some interaction in other parts of the kernel. I
> actually have one server that refuses to boot if I install an PVR-500.
> These things are very hard to debug and, to be very honest, it is simply
> not worth the time to attempt to resolve this.
>
> It doesn't help you at all, I realize that, but it's the truth. It would
> be different if I see such bug reports all the time, but that is not the
> case.
>
> Regards,
>
> Hans



--
Hans Verkuil - video4linux developer - sponsored by TANDBERG

_______________________________________________
ivtv-users mailing list
ivtv-users@ivtvdriver.org
http://ivtvdriver.org/mailman/listinfo/ivtv-users
Re: reboots with kernel > 2.6.22 [ In reply to ]
hverkuil at xs4all
Aug 23, 2009, 1:18 PM
Post #17 of 22 (15940 views)
Permalink
On Sunday 23 August 2009 21:58:03 Jeroen Roos wrote:
> Andy Walls wrote:
> > 1. Find that latest kernel that still works and the earliest kernel
> > that does not.
> >
> > A binary search will terminate in a few trials, e.g. .30, .26, .24,
> > .23. (I suspect this could be painful on a Gentoo system, if you have
> > to rebuild each kernel.)
>
> I have done this in the past, unfortunately not down to patchlevel, but
> I have found that linux-2.6.22-gentoo-r8 works and
> linux-2.6.23-gentoo-r3 not. I have just booted from the first and did
> not have the reboot issue there. Unfortunately I no longer have a
> compiled version of the .23 release, and I cannot compile them anymore
> since they cannot be compiled with gcc 4.3
>
> > 2. Diff the source tree of the two kernels.
>
> video src # diff -r linux-2.6.22-gentoo-r9 linux-2.6.23-gentoo-r3 | wc -l
> 472301
>
> ....mmmmm little bit too much
>
> > 3. Analyze the diff for the change that may have caused the problem.
> >
> > That will narrow the cause down from "anything" to "one of these
> > changes". That changeset still could be rather large.
>
> Indeed, but if I just check the ivtv part, it goes down:
>
> video ~ # cd /usr/src/linux-2.6.22-gentoo-r9/drivers/media/video/
> video video # diff -r ivtv
> /usr/src/linux-2.6.23-gentoo-r3/drivers/media/video/ivtv | wc -l
> 556
>
> Also, a reasonable part of that is changes in comments and printed text.
>
> I think it's a bit too big to include in or attach to the mail, but for
> anyone interested, there's a unified diff (diff -uN) at
> http://thuis.tuxinet.nl/ivtv.patch.

I don't think any of these changes can have caused this. All changes are
either logging/comment changes, or they are related to PVR-350 MPEG decoder
support, neither of which has anything to do with the PVR-500.

I suspect it is elsewhere in the kernel and to find that will require a
proper (and time consuming) binary search.

You might also google first to see if anyone else has reported problems with
your chipset/motherboard. I.e., not ivtv-related but with pci devices and
reboots on your boards in general since kernel 2.6.23 and up.

Regards,

Hans

--
Hans Verkuil - video4linux developer - sponsored by TANDBERG

_______________________________________________
ivtv-users mailing list
ivtv-users@ivtvdriver.org
http://ivtvdriver.org/mailman/listinfo/ivtv-users
Re: reboots with kernel > 2.6.22 [ In reply to ]
ivtv at roosnl
Aug 23, 2009, 1:24 PM
Post #18 of 22 (15934 views)
Permalink
> Hmm, the problem with that is that 2.6.22 is the moment that ivtv was
> finally merged into the kernel. So you probably end up with the merger of
> ivtv as being the moment it broke :-) Not useful that.

That is what I thought, but the 2.6.22-gentoo-r8 release that seems to
work for me (I couldn't reproduce the issue anymore) appears to have
ivtv in-kernel. Unfortunately it has been removed from the 'portage'
tree, so I cannot check out on what vanilla version/patchlevel it was
based. Besides that, as mentionned in my previous mail, I cannot compile
these kernels anymore, since they can't be built with GCC 4.3

> The core problem is that 1) you're the first reporter of this problem,

That makes me think that there's more to this problem... I simply can't
imagine that I am the only person in the world running this motherboard
(that was designed specifically for video-purposes) with this card (one
of the most popular analog tv cards for PVR's, I think) and Linux...

> 2) it doesn't happen on non-VIA PCs (at least, to my knowledge), 3) I strongly
> suspect that it might be related to the PCI bridge on the PVR-500 together
> with some interaction in other parts of the kernel. I actually have one
> server that refuses to boot if I install an PVR-500. These things are very
> hard to debug and, to be very honest, it is simply not worth the time to
> attempt to resolve this.

Well, it is worth *MY* time, as I simply don't want to throw out a
system that should be working perfectly except for a software error.

I'd be happy to try and test and figure out things, but I need some
guidance on what to try and interpreting kernel messages and stuff...

Jeroen

_______________________________________________
ivtv-users mailing list
ivtv-users@ivtvdriver.org
http://ivtvdriver.org/mailman/listinfo/ivtv-users
Re: reboots with kernel > 2.6.22 [ In reply to ]
awalls at radix
Aug 23, 2009, 6:21 PM
Post #19 of 22 (15968 views)
Permalink
On Sun, 2009-08-23 at 22:24 +0200, Jeroen Roos wrote:
> > Hmm, the problem with that is that 2.6.22 is the moment that ivtv was
> > finally merged into the kernel. So you probably end up with the merger of
> > ivtv as being the moment it broke :-) Not useful that.
>
> That is what I thought, but the 2.6.22-gentoo-r8 release that seems to
> work for me (I couldn't reproduce the issue anymore) appears to have
> ivtv in-kernel. Unfortunately it has been removed from the 'portage'
> tree, so I cannot check out on what vanilla version/patchlevel it was
> based. Besides that, as mentionned in my previous mail, I cannot compile
> these kernels anymore, since they can't be built with GCC 4.3

Jeroen,

IN your previous email you mentioned ivtv diffs. The change that
induces the problem is likely not there (or all there).

Your symptoms indiicate PCI chipset configuration, interrupt
configuration, IO memory management, or DMA configuration problems.
Basically anything that might do something to make the motherboard's PCI
chipset unhappy enough to decide to reboot the machine.

It's not the CPU or the kernel rebooting the machine, it's the PCI
chipset.

> > The core problem is that 1) you're the first reporter of this problem,
>
> That makes me think that there's more to this problem... I simply can't
> imagine that I am the only person in the world running this motherboard
> (that was designed specifically for video-purposes) with this card (one
> of the most popular analog tv cards for PVR's, I think) and Linux...
>
> > 2) it doesn't happen on non-VIA PCs (at least, to my knowledge), 3) I strongly
> > suspect that it might be related to the PCI bridge on the PVR-500 together
> > with some interaction in other parts of the kernel. I actually have one
> > server that refuses to boot if I install an PVR-500. These things are very
> > hard to debug and, to be very honest, it is simply not worth the time to
> > attempt to resolve this.
>
> Well, it is worth *MY* time, as I simply don't want to throw out a
> system that should be working perfectly except for a software error.
>
> I'd be happy to try and test and figure out things, but I need some
> guidance on what to try and interpreting kernel messages and stuff...


There will be no kernel messages to interpret - the PCI chipset is
rebooting the machine. No state will be saved, no messages will be
emitted, the thing will just reboot. Even if the kernel notices
something and starts to log it, it will never flush the message to
screen, serial port, or disk before the reboot happens.

If you really want to figure it out, you'll need to collect documents
and do some reading:

1. The PCI local bus and PCI bridge specifications. You'll need to have
a medium to advanced understanding of the PCI bus.

2. The data sheets for your motherboard's PCI chipset: northbridge and
southbridge. You'll be looking for documented conditions which will
cause the chipset to assert reset or maybe generate non-maskable
interrupts.

3. The datasheet for the Hint Corp HB6 PCI-PCI bridge. I believe they
were bought by PLX Tech: http://www.plxtech.com/ . Look for the PCI
6254 (HB6) bridge documents, if they have them publicly available. This
bridge chip supports a few different modes, IIRC.

4. You'll need to dump the registers and inspect the configuration of
the bridge chips against their datasheets so you understand how they
should be behaving.


Once you've done that homework, then you can start working on serious
hypotheses about what may be causing the reboot and testing them. You
should inform your hypotheses with the diff between working and
non-working kernel.

That's the only way I would know to isolate the root cause without
without a very expensive PCI bus analyzer.


There is no magic solution here. It is simply a lot of work. It's also
not work that can be easily divided among a number of people nor
resolved without the hardware in hand.

I agree with Hans, it is hardly worth the time to fix the problem:

Assume you spend 60 hours or more on document research, software
modifications, and testing to resolve the problem. If 2 PVR-150's cost
US$200 total, then over 60 hours of work, US$3.33/hour is the break-even
point on the wage equivalent of one's time. If one were to also sell
the PVR-500 on eBay for, say, US$125, then the break-even point sinks to
US$1.25/hour.

The only things worth the time are probably the intangible results of
persuing the solution: learning about the PCI bus, satisfaction from
solving a hard problem, learning about the linux kernel internals, etc.


Regards,
Andy


> Jeroen



_______________________________________________
ivtv-users mailing list
ivtv-users@ivtvdriver.org
http://ivtvdriver.org/mailman/listinfo/ivtv-users
Re: reboots with kernel > 2.6.22 [ In reply to ]
ivtv at roosnl
Sep 14, 2009, 12:39 PM
Post #20 of 22 (15247 views)
Permalink
Hello all,

A quick update on the progress with this...

Using git bisect, I have located the patch that caused my problem. It is
a change to the CX700 PCI driver, disabling PCI parking and caching. If
I remove that code from a recent kernel, it works fine. I am working
with the author of that patch to see if we can get it fixed.

Jeroen

_______________________________________________
ivtv-users mailing list
ivtv-users@ivtvdriver.org
http://ivtvdriver.org/mailman/listinfo/ivtv-users
Re: reboots with kernel > 2.6.22 [ In reply to ]
hverkuil at xs4all
Sep 14, 2009, 1:20 PM
Post #21 of 22 (15241 views)
Permalink
On Monday 14 September 2009 21:39:46 Jeroen Roos wrote:
> Hello all,
>
> A quick update on the progress with this...
>
> Using git bisect, I have located the patch that caused my problem. It is
> a change to the CX700 PCI driver, disabling PCI parking and caching. If
> I remove that code from a recent kernel, it works fine. I am working
> with the author of that patch to see if we can get it fixed.

Good work! Thanks for letting us know what caused the reboot.

Regards,

Hans

--
Hans Verkuil - video4linux developer - sponsored by TANDBERG Telecom

_______________________________________________
ivtv-users mailing list
ivtv-users@ivtvdriver.org
http://ivtvdriver.org/mailman/listinfo/ivtv-users
Re: reboots with kernel > 2.6.22 [ In reply to ]
awalls at radix
Sep 14, 2009, 5:35 PM
Post #22 of 22 (15243 views)
Permalink
On Mon, 2009-09-14 at 21:39 +0200, Jeroen Roos wrote:
> Hello all,
>
> A quick update on the progress with this...
>
> Using git bisect, I have located the patch that caused my problem. It is
> a change to the CX700 PCI driver, disabling PCI parking and caching. If
> I remove that code from a recent kernel, it works fine. I am working
> with the author of that patch to see if we can get it fixed.
>
> Jeroen

These things usually aren't pleasant to run down. I imagine it took
time and persistence on your part. Good work!

Regards,
Andy



_______________________________________________
ivtv-users mailing list
ivtv-users@ivtvdriver.org
http://ivtvdriver.org/mailman/listinfo/ivtv-users

©2024 GT.net. A Gossamer Threads company.
5th Floor, 455 Granville St., Vancouver, BC V6C 1T1, Canada | Legal