iTVC15 MPEG Capture Driver for Linux

kevin thayer wrote:
> does it work? I'm going to wait till 3 or 4 folks
> declare that it works well for them before i commit.
> 
> -tmk
> 
I will test it when I get a mo.

kevin thayer wrote:
> does it work? I'm going to wait till 3 or 4 folks
> declare that it works well for them before i commit.
> 
> -tmk
> 
Works well here.
I few minor points, but I think it would be best to checkin this patch, 
and then we can work on fine tuning it.

At least I can watch TV again! :-)

One really nice thing about 2.6 over and above 2.4 for development, is 
that if it segfaults or something like that, it does not take down the 
whole system. A small sysoops appears in the log files, and nothing else.

Cheers
James

I think we just have a freqeuency list.. ie no fine
tuning

-tmk

--- Arpi <arpi@...> wrote:
> Hi,
> 
> > On Tuesday 26 August 2003 10:47 am, PlasmaJohn
> wrote:
> > > Quoting Bruno Hertz:
> > > > Just out of curiosity: did anyone try to
> reproduce this behavior on
> > > > Windows? I got no installation myself, and a
> web/usenet search doesn't
> > > > bring up as much complaints as I'd have
> expected, considering the
> > > > probably still (much?) larger user base ...
> > >
> > > Last I checked (several months ago), the Windows
> driver added a 1 second
> > > delay between channel changes specifially to
> deal with this problem.  IIRC
> > > the ref source shuts down the encoding engine
> changes the channel and
> > > restarts the encoder.
> > 
> > I've been closing/reopening the video device on
> channel/input changes in 
> > MythTV ever since I added support for these cards
> months ago because of this 
> > issue.  Works perfectly, no corruption in the
> stream.
> 
> Hmm. And how do you deal with initial channel
> scanning?
> Ie finding the channels including fine-tuning.
> 
> 
> A'rpi / Astral & ESP-team
> 
> --
> Developer of MPlayer G2, the Movie Framework for all
> - http://www.MPlayerHQ.hu
> 
> 
>
-------------------------------------------------------
> This sf.net email is sponsored by:ThinkGeek
> Welcome to geek heaven.
> http://thinkgeek.com/sf
> _______________________________________________
> ivtv-devel mailing list
> ivtv-devel@...
>
https://lists.sourceforge.net/lists/listinfo/ivtv-devel


__________________________________
Do you Yahoo!?
Yahoo! SiteBuilder - Free, easy-to-use web site design software
http://sitebuilder.yahoo.com

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

kevin thayer wrote:
| I think we just have a freqeuency list.. ie no fine
| tuning

ptune-ui.pl will let you fine tune by adding +-1 to the current channels frequency.

|
| -tmk
|
| --- Arpi <arpi@...> wrote:
|
|>Hi,
|>
|>
|>>On Tuesday 26 August 2003 10:47 am, PlasmaJohn
|>
|>wrote:
|>
|>>>Quoting Bruno Hertz:
|>>>
|>>>>Just out of curiosity: did anyone try to
|>
|>reproduce this behavior on
|>
|>>>>Windows? I got no installation myself, and a
|>
|>web/usenet search doesn't
|>
|>>>>bring up as much complaints as I'd have
|>
|>expected, considering the
|>
|>>>>probably still (much?) larger user base ...
|>>>
|>>>Last I checked (several months ago), the Windows
|>
|>driver added a 1 second
|>
|>>>delay between channel changes specifially to
|>
|>deal with this problem.  IIRC
|>
|>>>the ref source shuts down the encoding engine
|>
|>changes the channel and
|>
|>>>restarts the encoder.
|>>
|>>I've been closing/reopening the video device on
|>
|>channel/input changes in
|>
|>>MythTV ever since I added support for these cards
|>
|>months ago because of this
|>
|>>issue.  Works perfectly, no corruption in the
|>
|>stream.
|>
|>Hmm. And how do you deal with initial channel
|>scanning?
|>Ie finding the channels including fine-tuning.
|>
|>


- --
James A. Pattie
james@...

Linux  --  SysAdmin / Programmer
Xperience, Inc.
http://www.pcxperience.com/
http://www.xperienceinc.com/

GPG Key Available at http://www.pcxperience.com/gpgkeys/james.html
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.2.2 (GNU/Linux)
Comment: Using GnuPG with Debian - http://enigmail.mozdev.org

iD8DBQE/TL55tUXjwPIRLVERAvUrAKDpxHaFvbLyPjwEHHjeI5jkT8KswwCfdpKr
kb4bBvKYh87pMsp86UnaxYw=
=oJcz
-----END PGP SIGNATURE-----


-- 
This message has been scanned for viruses and
dangerous content by MailScanner, and is
believed to be clean.

Quoting Arpi:

> > I've been closing/reopening the video device on channel/input changes in 
> > MythTV ever since I added support for these cards months ago because of
> > this issue.  Works perfectly, no corruption in the stream.
> 
> Hmm. And how do you deal with initial channel scanning?
> Ie finding the channels including fine-tuning.

Are you talking about a one-time or infrequent task?   

The bug is in the firmware (or design) and the encoding engine gets confused. 
Therefore, I think YUV-only mode (not passthru!) shouldn't be affected by this
problem but should be sufficient for frequency adjustments: same
signal->hardware path but leaves out the encoding engine.

John

-- 
http://ivtv.sourceforge.net - The IvyTV Project
OpenSource Linux kernel driver for iTVCxx & CX234xx family of codecs.

On Wed, 2003-08-27 at 01:44, Bruno Hertz wrote:

> For two days I've been running things as follows
> * debug=0 (I don't believe the quiescent debug=1 has any negative
>   impact, but anyway ...)
> * recording only with mplayer -dumpstream, as has been mentioned in
>   a previous posting, no cat
> * live tv only with mplayer -cache 8192 -framedrop, no xine
> * live tuning though, without stopping anything
> and experienced no problem whatsoever.
> 

For the sake of completeness: the above went well for almost a
week. Yesterday though I got those glitches again.

To improve the situation, the only two means left which I know
of are:
* generally shut down recording/live watching before tuning
* ensure the cards IRQ isn't shared.

I'll try one after the other.

Bruno

please email me the logs you get with debug=3

-tmk

--- Samuel Kvasnica <samuel.kvasnica@...>
wrote:
> Hello,
> 
> I'm trying to capture YUV data from /dev/yuv0 at
> 720x576. Picture is ok (using patched mplayer) but
> it
> stops after 1-3 seconds using mplayer as well with
> cat
> /dev/yuv0 > file.yuv. System does not freeze, it is
> possible to stop application using C-c. I tried to
> increase yuv_buffers to 256 but with no difference.
> When decreasing the resolution e.g. to 720x384 the
> capture time increases by another 1-2 secs. The
> system
> should be fast enough - Athlon 2000+. ivtv driver
> CVS
> sources were downloaded on 27.08.2003.

__________________________________
Do you Yahoo!?
Yahoo! SiteBuilder - Free, easy-to-use web site design software
http://sitebuilder.yahoo.com

Not really sure what happened, but my box has become unstable with ivtv 
after being solid for about a week.  Anyway, looking at the messages I 
get in var/log/messages, maybe somone can shed light for me.

Aug 27 23:37:15 myth kernel: saa7115[0]: decoder set size
Aug 27 23:37:15 myth kernel: Hpsc: 0x00001, Hfsc: 0x00600
Aug 27 23:37:15 myth kernel: Setting full NTSC height
Aug 27 23:38:02 myth kernel: ivtv: stopcap error 1. Code -16
Aug 27 23:38:03 myth kernel: ivtv: stopcap error 2. Code -16
Aug 27 23:38:04 myth kernel: ivtv: EOS interrupt not received! stopping 
anyway.
Aug 27 23:38:08 myth kernel: saa7115[0]: decoder set size
Aug 27 23:38:08 myth kernel: Hpsc: 0x00001, Hfsc: 0x00600
Aug 27 23:38:08 myth kernel: Setting full NTSC height
Aug 27 23:38:13 myth kernel: ivtv: init error 5. Code -16
Aug 27 23:38:14 myth kernel: ivtv: init error 6. Code -16
Aug 27 23:38:15 myth kernel: ivtv: init error 7. Code -16
Aug 27 23:38:16 myth kernel: ivtv: init error 8. Code -16
Aug 27 23:38:17 myth kernel: ivtv: init error 9. Code -16
Aug 27 23:38:18 myth kernel: ivtv: init error 10. Code -16
Aug 27 23:38:19 myth kernel: ivtv: init error 11. Code -16
Aug 27 23:38:20 myth kernel: ivtv: init error 12. Code -16
Aug 27 23:38:21 myth kernel: ivtv: init error 13. Code -16
Aug 27 23:38:22 myth kernel: ivtv: init error 14. Code -16
Aug 27 23:38:23 myth kernel: ivtv: init error 15. Code -16
Aug 27 23:38:24 myth kernel: ivtv: init error 16. Code -16
Aug 27 23:38:25 myth kernel: ivtv: init error 17. Code -16
Aug 27 23:38:26 myth kernel: ivtv: init error 18. Code -16
Aug 27 23:38:26 myth kernel:
Aug 27 23:38:27 myth kernel: ivtv: init error 20. Code -16
Aug 27 23:38:28 myth kernel: ivtv: startcap error 2. Code -16
Aug 27 23:38:29 myth kernel: ivtv: init error 19. Code -16
Aug 27 23:38:29 myth kernel:
Aug 27 23:38:31 myth kernel: ivtv: startcap error 1. Code -16
Aug 27 23:38:32 myth kernel: ivtv: stopcap error 1. Code -16
Aug 27 23:38:33 myth kernel: ivtv: stopcap error 2. Code -16
Aug 27 23:38:34 myth kernel: ivtv: EOS interrupt not received! stopping 
anyway.



So, does any of this make sense?  It usually happens after the first 
time I change channels.  It just doesn't work after that. It will be 
just locked up until I reboot and then I am ok again until I change the 
channel.

Eric

sometimes the firmware locks up. It's on my todo list
to detect this and reload. In the meantime,
unloading/reloading ivtv should fix it

ie rmmod ivtv;insmod ivtv.o

-tmk

--- WeaselGod <mythtv@...> wrote:
> Not really sure what happened, but my box has become
> unstable with ivtv 
> after being solid for about a week.  Anyway, looking
> at the messages I 
> get in var/log/messages, maybe somone can shed light
> for me.
> 
> Aug 27 23:37:15 myth kernel: saa7115[0]: decoder set
> size
> Aug 27 23:37:15 myth kernel: Hpsc: 0x00001, Hfsc:
> 0x00600
> Aug 27 23:37:15 myth kernel: Setting full NTSC
> height
> Aug 27 23:38:02 myth kernel: ivtv: stopcap error 1.
> Code -16
> Aug 27 23:38:03 myth kernel: ivtv: stopcap error 2.
> Code -16
> Aug 27 23:38:04 myth kernel: ivtv: EOS interrupt not
> received! stopping 
> anyway.
> Aug 27 23:38:08 myth kernel: saa7115[0]: decoder set
> size
> Aug 27 23:38:08 myth kernel: Hpsc: 0x00001, Hfsc:
> 0x00600
> Aug 27 23:38:08 myth kernel: Setting full NTSC
> height
> Aug 27 23:38:13 myth kernel: ivtv: init error 5.
> Code -16
> Aug 27 23:38:14 myth kernel: ivtv: init error 6.
> Code -16
> Aug 27 23:38:15 myth kernel: ivtv: init error 7.


__________________________________
Do you Yahoo!?
Yahoo! SiteBuilder - Free, easy-to-use web site design software
http://sitebuilder.yahoo.com

I tried that.  It doesn't seem to help.  Once this locks, it stays 
locked.  The weird this is, this was working fine.  Well, maybe I will 
get up the time to start running some debug.

Kevin, is there any other debug level I can set it to for more 
information for you?
Eric


kevin thayer wrote:

>sometimes the firmware locks up. It's on my todo list
>to detect this and reload. In the meantime,
>unloading/reloading ivtv should fix it
>
>ie rmmod ivtv;insmod ivtv.o
>
>-tmk
>
>--- WeaselGod <mythtv@...> wrote:
>  
>
>>Not really sure what happened, but my box has become
>>unstable with ivtv 
>>after being solid for about a week.  Anyway, looking
>>at the messages I 
>>get in var/log/messages, maybe somone can shed light
>>for me.
>>
>>Aug 27 23:37:15 myth kernel: saa7115[0]: decoder set
>>size
>>Aug 27 23:37:15 myth kernel: Hpsc: 0x00001, Hfsc:
>>0x00600
>>Aug 27 23:37:15 myth kernel: Setting full NTSC
>>height
>>Aug 27 23:38:02 myth kernel: ivtv: stopcap error 1.
>>Code -16
>>Aug 27 23:38:03 myth kernel: ivtv: stopcap error 2.
>>Code -16
>>Aug 27 23:38:04 myth kernel: ivtv: EOS interrupt not
>>received! stopping 
>>anyway.
>>Aug 27 23:38:08 myth kernel: saa7115[0]: decoder set
>>size
>>Aug 27 23:38:08 myth kernel: Hpsc: 0x00001, Hfsc:
>>0x00600
>>Aug 27 23:38:08 myth kernel: Setting full NTSC
>>height
>>Aug 27 23:38:13 myth kernel: ivtv: init error 5.
>>Code -16
>>Aug 27 23:38:14 myth kernel: ivtv: init error 6.
>>Code -16
>>Aug 27 23:38:15 myth kernel: ivtv: init error 7.
>>    
>>
>
>
>__________________________________
>Do you Yahoo!?
>Yahoo! SiteBuilder - Free, easy-to-use web site design software
>http://sitebuilder.yahoo.com
>
>
>-------------------------------------------------------
>This sf.net email is sponsored by:ThinkGeek
>Welcome to geek heaven.
>http://thinkgeek.com/sf
>_______________________________________________
>ivtv-devel mailing list
>ivtv-devel@...
>https://lists.sourceforge.net/lists/listinfo/ivtv-devel
>  
>

interesting. What motherboard/system specs do you
have?

Those errors on close are semi-normal, and probably
somewhat misleading :/ No way to tell if they are
'real'

-tmk

--- David Muench <dave@...> wrote:
> Hi, I am working on a mythtv setup with 2 ivtv cards
> (a Freestyle and a 
> PVR-250) and am running into DMA errors when I use
> both at once. Using 
> just one works great, but after recording for a
> little while on both 
> (say 15 minutes), I get this:
> 
> Aug 27 20:15:57 server kernel: ivtv: DMA Error.
> Result: 0x0000000b
> Aug 27 20:16:24 server kernel: ivtv: DMA Error.
> Result: 0x0000000b
> Aug 27 20:17:21 server kernel: ivtv: DMA Error.
> Result: 0x0000000b


__________________________________
Do you Yahoo!?
Yahoo! SiteBuilder - Free, easy-to-use web site design software
http://sitebuilder.yahoo.com

The motherboard is a Gigabyte GA-7DPXDW+. Here is a link to the board on 
newegg:

http://www.newegg.com/app/viewproduct.asp?DEPA=&submit=Go&description=GA%2D7DPXDW%2B

It has just 1 AMD XP 1600+ cpu in it and 1 512 meg stick of PC2100 ram. 
The Freestyle and PVR250 are in the two 32 bit PCI slots furthest from 
the CPU's, and the 64 bit PCI slots are occupied by a couple of 3ware 
IDE RAID cards. They have 20 hard drives hanging off of them totaling 
about 2.2TB of usable space. It's powered by an Antec Truepower 550.

I've had this system running for awhile as my fileserver and it runs 
great. The new additions are the Hauppauge boards and mythtv.

Hope that helps, if you need any other information, please let me know.

Dave

kevin thayer wrote:

> interesting. What motherboard/system specs do you
> have?
> 
> Those errors on close are semi-normal, and probably
> somewhat misleading :/ No way to tell if they are
> 'real'
> 
> -tmk
> 
> --- David Muench <dave@...> wrote:
> 
>>Hi, I am working on a mythtv setup with 2 ivtv cards
>>(a Freestyle and a 
>>PVR-250) and am running into DMA errors when I use
>>both at once. Using 
>>just one works great, but after recording for a
>>little while on both 
>>(say 15 minutes), I get this:
>>
>>Aug 27 20:15:57 server kernel: ivtv: DMA Error.
>>Result: 0x0000000b
>>Aug 27 20:16:24 server kernel: ivtv: DMA Error.
>>Result: 0x0000000b
>>Aug 27 20:17:21 server kernel: ivtv: DMA Error.
>>Result: 0x0000000b

what kernel rev/distro/version of lirc

can you get the output of ksymoops?

looks like an lirc problem to me. I've had many folks
say lirc works for them, no kernel oops's reported.

-tmk

--- Edwin Chiu <edwin@...> wrote:
> Hi, details below:
> 
> lirc_dev: lirc_unregister_plugin:plugin lirc_i2c[0]
> in use!<1>Unable
> to handle kernel paging request at virtual address
> e2a37a1c
>  printing eip:
>  e297bf12
>  *pde = 1ea3d067
>  *pte = 00000000
>  Oops: 0000
>  CPU:    0
>  EIP:    0010:[<e297bf12>]    Tainted: P
>  EFLAGS: 00010296
>  eax: c15ab7d8   ebx: e2a379f4   ecx: 00000246  
> edx: 00000008
>  esi: d4cdbfe0   edi: 00000000   ebp: 00000003  
> esp: d4cdbf5c
>  ds: 0018   es: 0018   ss: 0018
>  Process lirc_dev (pid: 1702, stackpage=d4cdb000)
>  Stack: c15ab780 d4cdbfe0 00000000 e29f6040 dc493b40
> 00000000 d4cdbfa8
>  0005295b
>         00000000 c02a4000 d9841080 00000000 00000246
> d4cdbfa8 c01162e0
>     e29f8190
>         c15ab7d8 d4cdbfb0 00000003 c15f3fc0 d4cdbfe0
> 0005295b
>         e29f419c c15ab780
>       Call Trace:    [<e29f6040>] [<c01162e0>]
> [<e29f8190>]
>       [<e29f419c>] [<e29f6040>]
>       [<c01070bf>] [<c01070c8>] [<e29f6040>]
> 
>  Code: 8b 43 28 83 78 28 00 0f 84 a1 00 00 00 8b 54
> 24
>  40 0f b7 42
> 
> This is how to reproduce:
> 
> modprobe lirc_i2c
> /etc/init.d/lirc start
> modprobe ivtv
> rmmod ivtv
> 
> lirc_i2c is patched using 
> http://delvare.free.fr/i2c/lirc-CVS-i2c-2.8.0.patch,
> which I incidently 
> help write. I did have a more detailed log, but I
> didn't save it.
> 
> Any hints? I have a detailed syslog as well, if it's
> needed...


__________________________________
Do you Yahoo!?
Yahoo! SiteBuilder - Free, easy-to-use web site design software
http://sitebuilder.yahoo.com

kevin thayer wrote:

>what kernel rev/distro/version of lirc
>
>can you get the output of ksymoops?
>
>looks like an lirc problem to me. I've had many folks
>say lirc works for them, no kernel oops's reported.
>
>-tmk
>  
>
It may be related to the patch I had to munge together to work with the 
new i2c backend that the lm_sensors crew created when they released 2.8.0

I'm running Debian 3.0, using a custom built kernel

2.4.21 + low latency (but not used, i never set the sysctl)
      + ppp mppe patch
      + wireless extensions 0.16
      + i2c patches from lm_sensors 2.8.0, core + i2c-matrox, 
matroxfb_maven
      + variable HZ patch + 64-bit jiffies patch

I'm thinking the i2c patches might be the cause... not sure.

Output of ksymoops

ksymoops 2.4.5 on i686 2.4.21-ec8.  Options used
     -V (default)
     -k /proc/ksyms (default)
     -l /proc/modules (default)
     -o /lib/modules/2.4.21-ec8/ (default)
     -m /System.map (specified)

Warning (compare_maps): ksyms_base symbol 
IO_APIC_get_PCI_irq_vector_R__ver_IO_APIC_get_PCI_irq_vector not found 
in System.map.  Ignoring ksyms_base entry
Warning (compare_maps): ksyms_base symbol 
__enable_lowlatency_R__ver___enable_lowlatency not found in System.map.  
Ignoring ksyms_base entry
Unable to handle kernel paging request at virtual address e29ffa1c
e297bf12
*pde = 1e96d067
Oops: 0000
CPU:    0
EIP:    0010:[<e297bf12>]    Tainted: P
Using defaults from ksymoops -t elf32-i386 -a i386
EFLAGS: 00010296
eax: c15ab7d8   ebx: e29ff9f4   ecx: 00000246   edx: 00000008
esi: dd853fe0   edi: 00000000   ebp: 00000003   esp: dd853f5c
ds: 0018   es: 0018   ss: 0018
Process lirc_dev (pid: 63, stackpage=dd853000)
Stack: c15ab780 dd853fe0 00000000 e2a56040 dc18c240 df9a6b00 dd853fa8 
0006f7ef
       00000000 d258a000 dc18c240 00000000 00000246 dd853fa8 c01162e0 
e2a58190
       c15ab7d8 dd853fb0 00000003 de683940 dd853fe0 0006f7ef e2a5419c 
c15ab780
Call Trace:    [<e2a56040>] [<c01162e0>] [<e2a58190>] [<e2a5419c>] 
[<e2a56040>]
  [<c01070bf>] [<c01070c8>] [<e2a56040>]
Code: 8b 43 28 83 78 28 00 0f 84 a1 00 00 00 8b 54 24 40 0f b7 42


> >EIP; e297bf12 <[i2c-core]i2c_master_recv+12/e0>   <=====

> >eax; c15ab7d8 <_end+12b0944/2065c16c>
> >ebx; e29ff9f4 <[saa7115].data.end+d2f5/13901>
> >esi; dd853fe0 <_end+1d55914c/2065c16c>
> >esp; dd853f5c <_end+1d5590c8/2065c16c>

Trace; e2a56040 <[lirc_dev]irctls+0/0>
Trace; c01162e0 <schedule_timeout+80/a0>
Trace; e2a58190 <[lirc_i2c]get_key_haup+40/f0>
Trace; e2a5419c <[lirc_dev]__module_license+122/236>
Trace; e2a56040 <[lirc_dev]irctls+0/0>
Trace; c01070bf <arch_kernel_thread+1f/40>
Trace; c01070c8 <arch_kernel_thread+28/40>
Trace; e2a56040 <[lirc_dev]irctls+0/0>

Code;  e297bf12 <[i2c-core]i2c_master_recv+12/e0>
00000000 <_EIP>:
Code;  e297bf12 <[i2c-core]i2c_master_recv+12/e0>   <=====
   0:   8b 43 28                  mov    0x28(%ebx),%eax   <=====
Code;  e297bf15 <[i2c-core]i2c_master_recv+15/e0>
   3:   83 78 28 00               cmpl   $0x0,0x28(%eax)
Code;  e297bf19 <[i2c-core]i2c_master_recv+19/e0>
   7:   0f 84 a1 00 00 00         je     ae <_EIP+0xae> e297bfc0 
<[i2c-core]i2c_master_recv+c0/e0>
Code;  e297bf1f <[i2c-core]i2c_master_recv+1f/e0>
   d:   8b 54 24 40               mov    0x40(%esp,1),%edx
Code;  e297bf23 <[i2c-core]i2c_master_recv+23/e0>
  11:   0f b7 42 00               movzwl 0x0(%edx),%eax


2 warnings issued.  Results may not be reliable.

And the last part of dmesg

ivtv: Disabling interrupts!
ivtv: Stopping card parts
ivtv: Stopping firmware
ivtv: API Call: 0x00000002
ivtv: getting mailbox
ivtv: [0] .. 0x00000000
ivtv: got free mailbox: 0
ivtv: retval: 0xffffffff
ivtv: Releasing mailbox (before 0x00000007, ivtv: after 0x00000000 )
ivtv: API Call: 0x000000c3
ivtv: getting mailbox
ivtv: [0] .. 0x00000000
ivtv: got free mailbox: 0
ivtv: retval: 0x00000000
ivtv: Releasing mailbox (before 0x00000007, ivtv: after 0x00000000 )
ivtv: Sleeping for 10ms
ivtv: API Call: 0x0000000e
ivtv: getting mailbox
ivtv: [0] .. 0x00000000
ivtv: got free mailbox: 0
ivtv: retval: 0x00000000
ivtv: Releasing mailbox (before 0x00000004, ivtv: after 0x00000000 )
ivtv: Sleeping for 10ms
ivtv: Freeing buffers
ivtv: Unregistering v4l devices!
ivtv: v4l2 unregister
ivtv: Freeing dma resources
ivtv: unregistering i2c
lirc_dev: lirc_unregister_plugin:plugin lirc_i2c[0] in use!ivtv: 
releasing irq
ivtv: releasing regmem
ivtv: releasing encmbox
ivtv: releasing decmbox
ivtv: releasing mem
ivtv: You've not seen the last of willy!
Unable to handle kernel paging request at virtual address e29ffa1c
 printing eip:
e297bf12
*pde = 1e96d067
*pte = 00000000
Oops: 0000
CPU:    0
EIP:    0010:[<e297bf12>]    Tainted: P
EFLAGS: 00010296
eax: c15ab7d8   ebx: e29ff9f4   ecx: 00000246   edx: 00000008
esi: dd853fe0   edi: 00000000   ebp: 00000003   esp: dd853f5c
ds: 0018   es: 0018   ss: 0018
Process lirc_dev (pid: 63, stackpage=dd853000)
Stack: c15ab780 dd853fe0 00000000 e2a56040 dc18c240 df9a6b00 dd853fa8 
0006f7ef
       00000000 d258a000 dc18c240 00000000 00000246 dd853fa8 c01162e0 
e2a58190
       c15ab7d8 dd853fb0 00000003 de683940 dd853fe0 0006f7ef e2a5419c 
c15ab780
Call Trace:    [<e2a56040>] [<c01162e0>] [<e2a58190>] [<e2a5419c>] 
[<e2a56040>]
  [<c01070bf>] [<c01070c8>] [<e2a56040>]

Code: 8b 43 28 83 78 28 00 0f 84 a1 00 00 00 8b 54 24 40 0f b7 42

Regards,
Edwin

PS Could someone delete my message waiting in the queue? It was held up, 
because it was too large.

looks like an error on unload. 

With all those i2c patches, i'd blame one of them. I'd
say your best bet is to start with a fresh kernel and
go one patch at a time till it breaks. then figure out
why.

-tmk

--- Edwin Chiu <edwin@...> wrote:
> It may be related to the patch I had to munge
> together to work with the 
> new i2c backend that the lm_sensors crew created
> when they released 2.8.0
> 
> I'm running Debian 3.0, using a custom built kernel
> 
> 2.4.21 + low latency (but not used, i never set the
> sysctl)
>       + ppp mppe patch
>       + wireless extensions 0.16
>       + i2c patches from lm_sensors 2.8.0, core +
> i2c-matrox, 
> matroxfb_maven
>       + variable HZ patch + 64-bit jiffies patch
> 
> I'm thinking the i2c patches might be the cause...
> not sure.


__________________________________
Do you Yahoo!?
Yahoo! SiteBuilder - Free, easy-to-use web site design software
http://sitebuilder.yahoo.com

> The symptoms?  When I cat /dev/video0 >
> first_capture.mpg, it sits as
> though recording, but when I mplayer
> first_capture.mpg, it's only about
> 5 secs long  (it looks damned good for those 5
> seconds, though!).  The
> output from dmesg follows.  Note the lines

does cat return you to shell on its own, or does it
wait till you ^C? is busmastering enabled on the card?
how are you determining that it doesn't share an IRQ?

> Can anyone expand on what they had to do to get this
> (somewhat common?)
> problem to go away?

Based on your logs, it should be sufficient to run
with debug=3.  I'll know more when you answer the
above questions though.

-tmk

__________________________________
Do you Yahoo!?
Yahoo! SiteBuilder - Free, easy-to-use web site design software
http://sitebuilder.yahoo.com

Thanks for the fast response!

> > The symptoms?  When I cat /dev/video0 >
> > first_capture.mpg, it sits as
> > though recording, but when I mplayer
> > first_capture.mpg, it's only about
> > 5 secs long  (it looks damned good for those 5
> > seconds, though!).  The
> > output from dmesg follows.  Note the lines
> 
> does cat return you to shell on its own, or does it
> wait till you ^C? is busmastering enabled on the card?
> how are you determining that it doesn't share an IRQ?
> 
It doesn't stop until I hit ^C.  I'm afraid I don't know what
busmastering is, although it seems to be flagged (see below).  However,
a lot of the entries are flagged bus master, so I'm not sure I trust
that.

To check the irq's, I use lspci -v, and cat /proc/interrupts.  They give
similar results.  Here's the entry for the hauppauge:

00:0a.0 Multimedia video controller: Internext Compression Inc: Unknown
device 0016 (rev 01)
        Subsystem: Hauppauge computer works Inc.: Unknown device 4009
        Flags: bus master, medium devsel, latency 32, IRQ 3
        Memory at dc000000 (32-bit, prefetchable) [size=64M]
        Capabilities: [44] Power Management version 2

Nothing else _seems_ to be sharing IRQ 3.

> Based on your logs, it should be sufficient to run
> with debug=3.  I'll know more when you answer the
> above questions though.
> 
Sounds good.  debug=127 dumps a lot of stuff!

Thanks again,

Todd

On Wed, 2003-08-27 at 05:48, Todd Chisholm wrote:

> ivtv: dma still pending! stopping anyway.
> ivtv: EOS interrupt not received! stopping anyway.

The same here. Happens with cat and mplayer, they just seem
to hang. Needs interruption & restart.

I got this with debug=1 (and debug=0, but if I remember right
the above log message isn't written in that case).

My pvr350 IRQ is currently shared, though. Had no time yet
to fix this:

 00:1d.2 USB Controller: Intel Corp. 82801DB USB (Hub #3) (rev 01)
 (prog-if 00 [UHCI])
        Subsystem: Asustek Computer, Inc.: Unknown device 8089
        Flags: bus master, medium devsel, latency 0, IRQ 10
        I/O ports at d000 [size=32]

 00:1f.1 IDE interface: Intel Corp. 82801DB ICH4 IDE (rev 01)
 (prog-if 8a [Master SecP PriP])
        Subsystem: Asustek Computer, Inc.: Unknown device 8089
        Flags: bus master, medium devsel, latency 0, IRQ 10

 02:0e.0 Multimedia video controller: Internext Compression Inc
 iTVC15 MPEG-2 Encoder (rev 01)
        Subsystem: Hauppauge computer works Inc.: Unknown device 4000
        Flags: bus master, medium devsel, latency 32, IRQ 10
        Memory at e8000000 (32-bit, prefetchable) [size=64M]
        Capabilities: [44] Power Management version 2

So maybe this is the reason.

Bruno