public inbox for linux-kernel@vger.kernel.org
 help / color / mirror / Atom feed
From: Lukas Hejtmanek <xhejtman@mail.muni.cz>
To: linux-kernel@vger.kernel.org, kraxel@bytesex.org
Subject: CX8800 driver and 2.6.15-RC2
Date: Fri, 2 Dec 2005 21:14:08 +0100	[thread overview]
Message-ID: <20051202201408.GA11046@mail.muni.cz> (raw)

Hello,

I tried cx8800 driver with Leadtek Winfast 2000XP Expert card.
This is from dmesg:
cx2388x v4l2 driver version 0.0.5 loaded
ACPI: PCI Interrupt 0000:01:05.0[A] -> GSI 18 (level, low) -> IRQ 19
CORE cx88[0]: subsystem: 107d:6611, board: Leadtek Winfast 2000XP Expert
[card=5,autodetected]
TV tuner 44 at 0x1fe, Radio tuner -1 at 0x1fe
cx88[0]: Leadtek Winfast 2000XP Expert config: tuner=38, eeprom[0]=0x01
input: cx88 IR (Leadtek Winfast 2000XP as /class/input/input2
cx88[0]/0: found at 0000:01:05.0, rev: 5, irq: 19, latency: 64, mmio: 0xfd000000
tuner 0-0060: All bytes are equal. It is not a TEA5767
tuner 0-0060: chip found @ 0xc0 (cx88[0])
tuner 0-0060: type set to 38 (Philips PAL/SECAM multi (FM1216ME MK3))
tda9887 0-0043: chip found @ 0x86 (cx88[0])
cx88[0]/0: registered device video0 [v4l2]
cx88[0]/0: registered device vbi0
cx88[0]/0: registered device radio0

seems to be ok.

However, using xawtv I got:
This is xawtv-3.94, running on Linux/i686 (2.6.15-rc2-git1)
/dev/video0 [v4l2]: ioctl VIDIOC_G_FBUF: Invalid argument
v4l-conf had some trouble, trying to continue anyway
ioctl: VIDIOC_G_FBUF(capability=0x0 [];flags=0x0
[];base=(nil);fmt.width=0;fmt.height=0;fmt.pixelformat=0x00000000
[....];fmt.field=ANY;fmt.bytesperline=0;fmt.sizeimage=0;fmt.colorspace=unknown;fmt.priv=0):
Invalid argument
ioctl:
VIDIOC_TRY_FMT(type=VIDEO_OVERLAY;fmt.win.w.left=852;fmt.win.w.top=45;fmt.win.w.width=384;fmt.win.w.height=288;fmt.win.field=ANY;fmt.win.chromakey=0;fmt.win.clips=(nil);fmt.win.clipcount=0;fmt.win.bitmap=(nil)):
Invalid argument
ioctl:
VIDIOC_S_FMT(type=VIDEO_OVERLAY;fmt.win.w.left=852;fmt.win.w.top=45;fmt.win.w.width=384;fmt.win.w.height=288;fmt.win.field=ANY;fmt.win.chromakey=0;fmt.win.clips=(nil);fmt.win.clipcount=0;fmt.win.bitmap=(nil)):
Invalid argument
ioctl: VIDIOC_OVERLAY(int=0): Invalid argument
ioctl: VIDIOC_QBUF(index=0;type=VIDEO_CAPTURE;bytesused=0;flags=0x0
[];field=ANY;;timecode.type=0;timecode.flags=0;timecode.frames=0;timecode.seconds=0;timecode.minutes=0;timecode.hours=0;timecode.userbits="";sequence=0;memory=MMAP):
Bad address
ioctl: VIDIOC_QBUF(index=0;type=VIDEO_CAPTURE;bytesused=0;flags=0x0
[];field=ANY;;timecode.type=0;timecode.flags=0;timecode.frames=0;timecode.seconds=0;timecode.minutes=0;timecode.hours=0;timecode.userbits="";sequence=0;memory=MMAP):
Bad address
ioctl: VIDIOC_DQBUF(index=0;type=VIDEO_CAPTURE;bytesused=0;flags=0x0
[];field=ANY;;timecode.type=0;timecode.flags=0;timecode.frames=0;timecode.seconds=0;timecode.minutes=0;timecode.hours=0;timecode.userbits="";sequence=0;memory=unknown):
Invalid argument
ioctl: VIDIOC_QBUF(index=0;type=VIDEO_CAPTURE;bytesused=0;flags=0x0
[];field=ANY;;timecode.type=0;timecode.flags=0;timecode.frames=0;timecode.seconds=0;timecode.minutes=0;timecode.hours=0;timecode.userbits="";sequence=0;memory=MMAP):
Bad address
ioctl: VIDIOC_QBUF(index=0;type=VIDEO_CAPTURE;bytesused=0;flags=0x0
[];field=ANY;;timecode.type=0;timecode.flags=0;timecode.frames=0;timecode.seconds=0;timecode.minutes=0;timecode.hours=0;timecode.userbits="";sequence=0;memory=MMAP):
Bad address

I inserted video_buf module with debug option and I got:
kernel: vbuf: reqbufs: bufs=2, size=0x36000 [108 pages total]
kernel: vbuf: mmap setup: 2 buffers, 221184 bytes each
kernel: vbuf: mmap ca74c420: q=ca8fe848 ae94c000-ae982000 pgoff 00000000 bufs
0-0
kernel: vbuf: mmap ca74c3e0: q=ca8fe848 ae916000-ae94c000 pgoff 00000036 bufs
1-1
kernel: vbuf: init user [0xae94c000+0x36000 => 54 pages]
kernel: vbuf: get_user_pages: err=-14 [0]
kernel: vbuf: init user [0xae94c000+0x36000 => 54 pages]
kernel: vbuf: get_user_pages: err=-14 [0]
kernel: vbuf: munmap ca74c420 q=ca8fe848
kernel: vbuf: munmap ca74c3e0 q=ca8fe848
kernel: vbuf: init user [0x8476fc8+0x6c000 => 109 pages]
kernel: vbuf: reqbufs: bufs=2, size=0xe1000 [450 pages total]
kernel: vbuf: mmap setup: 2 buffers, 921600 bytes each
kernel: vbuf: mmap cfdd4f80: q=cec35848 b7304000-b73e5000 pgoff 00000000 bufs
0-0
kernel: vbuf: init user [0xb7304000+0xe1000 => 225 pages]
kernel: vbuf: get_user_pages: err=-14 [0]
kernel: vbuf: munmap cfdd4f80 q=cec35848


Is it a bug in kernel modules?

-- 
Lukáš Hejtmánek

             reply	other threads:[~2005-12-02 20:15 UTC|newest]

Thread overview: 6+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2005-12-02 20:14 Lukas Hejtmanek [this message]
2005-12-02 20:37 ` CX8800 driver and 2.6.15-RC2 Michael Krufky
2005-12-03 18:07   ` Lukas Hejtmanek
2005-12-03 21:10     ` Michael Krufky
2005-12-04 10:05       ` Lukas Hejtmanek
2005-12-11 15:04       ` Lukas Hejtmanek

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=20051202201408.GA11046@mail.muni.cz \
    --to=xhejtman@mail.muni.cz \
    --cc=kraxel@bytesex.org \
    --cc=linux-kernel@vger.kernel.org \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox