Hi,
I've noticed that mencoder no longer works with bttv
capture on my system; with today's git tree
(ec1890c5df451799dec969a3581ff72e1934b5ee),
while it used to work on 2.6.14-rc5.
xawtv functions.
I'm looking for people who experienced the same problem,
or possibly for a fix.
The devices are:
0000:03:0b.0 Multimedia video controller: Brooktree Corporation Bt878 Video Capture (rev 11)
0000:03:0b.1 Multimedia controller: Brooktree Corporation Bt878 Audio Capture (rev 11)
0000:03:0b.0 0400: 109e:036e (rev 11)
0000:03:0b.1 0480: 109e:0878 (rev 11)
I'm using mencoder Debian package '1:1.0-pre7cvs20051102-0.0' from marillat's
for x86_64 architecture.
$ mencoder --version
MEncoder dev-CVS--4.0.2 (C) 2000-2005 MPlayer Team
CPU: Advanced Micro Devices Athlon 64 Newcastle,Winchester,San Diego,Venice; Sempron Palermo (Family: 15, Stepping: 0)
Detected cache-line size is 64 bytes
CPUflags: Type: 15 MMX: 1 MMX2: 1 3DNow: 1 3DNow2: 1 SSE: 1 SSE2: 1
Compiled for x86 CPU with extensions: MMX MMX2 3DNow 3DNowEx SSE SSE2
--version is not an MEncoder option
Exiting... (error parsing cmdline)
Linux dancer64 2.6.14-rc5dancer-gb563c9b1 #1 Thu Oct 27 12:55:05 JST 2005 x86_64 GNU/Linux
mencoder output on 2.6.14 (today's git)
channel: 12
minutes: 30
output filename: /home/dancer/XXX/XXX/
MEncoder dev-CVS--4.0.2 (C) 2000-2005 MPlayer Team
CPU: Advanced Micro Devices (Family: 8, Stepping: 0)
Detected cache-line size is 64 bytes
CPUflags: Type: 8 MMX: 1 MMX2: 1 3DNow: 1 3DNow2: 1 SSE: 1 SSE2: 1
Compiled for x86 CPU with extensions: MMX MMX2 3DNow 3DNowEx SSE SSE2
File not found: 'frameno.avi'
Failed to open frameno.avi
success: format: 9 data: 0x0 - 0x0
TV detected! ;-)
Selected driver: v4l2
name: Video 4 Linux 2 input
author: Martin Olschewski
comment: first try, more to come ;-)
Selected device: BT878 video (IODATA GV-BCTV5/PC
Tuner cap:
Tuner rxs: MONO
Capabilites: video capture video overlay VBI capture device tuner read/write streaming
supported norms: 0 = PAL; 1 = NTSC; 2 = SECAM; 3 = PAL-Nc; 4 = PAL-M; 5 = PAL-N; 6 = NTSC-JP; 7 = PAL-60;
inputs: 0 = Television; 1 = Composite1; 2 = S-Video;
Current input: 0
Current format: YUYV
v4l2: current audio mode is : STEREO
Selected channel: 12 (freq: 217.250)
v4l2: ioctl queue buffer failed: Bad address
Linux dancer64 2.6.14-rc5dancer-gb563c9b1 #1 Thu Oct 27 12:55:05 JST 2005 x86_64 GNU/Linux
mencoder output on 2.6.14-rc5:
channel: 12
minutes: 1
output filename: /tmp/aaaa.avi
MEncoder dev-CVS--4.0.2 (C) 2000-2005 MPlayer Team
CPU: Advanced Micro Devices Athlon 64 Newcastle,Winchester,San Diego,Venice; Sempron Palermo (Family: 15, Stepping: 0)
Detected cache-line size is 64 bytes
CPUflags: Type: 15 MMX: 1 MMX2: 1 3DNow: 1 3DNow2: 1 SSE: 1 SSE2: 1
Compiled for x86 CPU with extensions: MMX MMX2 3DNow 3DNowEx SSE SSE2
success: format: 9 data: 0x0 - 0x0
Selected driver: v4l2
name: Video 4 Linux 2 input
author: Martin Olschewski <[email protected]>
comment: first try, more to come ;-)
Selected device: BT878 video (IODATA GV-BCTV5/PC
Tuner cap:
Tuner rxs: MONO
Capabilites: video capture video overlay VBI capture device tuner read/write streaming
supported norms: 0 = PAL; 1 = NTSC; 2 = SECAM; 3 = PAL-Nc; 4 = PAL-M; 5 = PAL-N; 6 = NTSC-JP; 7 = PAL-60;
inputs: 0 = Television; 1 = Composite1; 2 = S-Video;
Current input: 0
Current format: YUYV
v4l2: current audio mode is : STEREO
Selected channel: 12 (freq: 217.250)
[V] filefmt:9 fourcc:0x30323449 size:320x240 fps:29.97 ftime:=0.0334
==========================================================================
Opening audio decoder: [pcm] Uncompressed PCM audio decoder
AUDIO: 48000 Hz, 2 ch, s16le, 1536.0 kbit/100.00% (ratio: 192000->192000)
Selected audio codec: [pcm] afm: pcm (Uncompressed PCM)
==========================================================================
Opening video filter: [expand osd=1]
Expand: -1 x -1, -1 ; -1, osd: 1, aspect: 0.000000, round: 1
==========================================================================
Opening video decoder: [raw] RAW Uncompressed Video
VDec: vo config request - 320 x 240 (preferred colorspace: Planar I420)
VDec: using Planar I420 as output csp (no 0)
Movie-Aspect is undefined - no prescaling applied.
videocodec: libavcodec (320x240 fourcc=34504d46 [FMP4])
High quality encoding selected (non real time)!
Selected video codec: [rawi420] vfm: raw (RAW I420)
==========================================================================
Building audio filter chain for 48000Hz/2ch/s16le -> 0Hz/0ch/??...
MP3 audio selected
Building audio filter chain for 48000Hz/2ch/s16le -> 48000Hz/2ch/s16le...
Writing AVI header...
ODML: Aspect information not (yet?) available or unspecified, not writing vprp header.
Forcing audio preload to 0, max pts correction to 0
New_Face failed. Maybe the font path is wrong.
Please supply the text font file (~/.mplayer/subfont.ttf).
subtitle font: load_sub_face failed.
ODML: Aspect information not (yet?) available or unspecified, not writing vprp header.
Pos: 4.1s 124f ( 0%) 26fps Trem: 0min 0mb A-V:0.000 [1082:128]
Flushing video frames
CBR audio: 16000 bytes/sec, 384 bytes/block
Writing AVI index...
Fixing AVI header...
ODML: Aspect information not (yet?) available or unspecified, not writing vprp header.
Video stream: 1082.222 kbit/s (135277 B/s) size: 559707 bytes 4.137 secs 124 frames
Audio stream: 128.000 kbit/s (16000 B/s) size: 66048 bytes 4.128 secs
v4l2: 139 frames successfully processed, 0 frames dropped.
regards,
junichi
--
dancer@{debian.org,netfort.gr.jp} Debian Project
Hi,
I've tried running mplayer v4l2 input on a bt878 card, and it fails.
xawtv works fine, and 2.6.14-rc5 used to work fine.
On git 3b44f137b9a846c5452d9e6e1271b79b1dbcc942 :
$ mplayer tv://1 -tv driver=v4l2
MPlayer dev-CVS--4.0.2 (C) 2000-2005 MPlayer Team
CPU: Advanced Micro Devices Athlon 64 Newcastle,Winchester,San Diego,Venice; Sempron Palermo (Family: 15, Stepping: 0)
Detected cache-line size is 64 bytes
CPUflags: MMX: 1 MMX2: 1 3DNow: 1 3DNow2: 1 SSE: 1 SSE2: 1
Compiled for x86 CPU with extensions: MMX MMX2 3DNow 3DNowEx SSE SSE2
Failed to open /dev/rtc: Permission denied (it should be readable by the user.)
Opening joystick device /dev/input/js0
Can't open joystick device /dev/input/js0 : Permission denied
Can't init input joystick
Setting up LIRC support...
mplayer: could not connect to socket
mplayer: No such file or directory
Failed to open LIRC support.
You will not be able to use your remote control.
Playing tv://1.
Cache fill: 0.00% (0 bytes)
Selected driver: v4l2
name: Video 4 Linux 2 input
author: Martin Olschewski <[email protected]>
comment: first try, more to come ;-)
Selected device: BT878 video (IODATA GV-BCTV5/PC
Tuner cap:
Tuner rxs: MONO
Capabilites: video capture video overlay VBI capture device tuner read/write streaming
supported norms: 0 = PAL; 1 = NTSC; 2 = SECAM; 3 = PAL-Nc; 4 = PAL-M; 5 = PAL-N; 6 = NTSC-JP; 7 = PAL-60;
inputs: 0 = Television; 1 = Composite1; 2 = S-Video;
Current input: 0
Current format: YUV420
v4l2: current audio mode is : MONO
v4l2: ioctl queue buffer failed: Bad address
v4l2: 0 frames successfully processed, 0 frames dropped.
At Thu, 03 Nov 2005 13:26:25 +0900,
Junichi Uekawa wrote:
>
> Hi,
>
> I've noticed that mencoder no longer works with bttv
> capture on my system; with today's git tree
> (ec1890c5df451799dec969a3581ff72e1934b5ee),
> while it used to work on 2.6.14-rc5.
> xawtv functions.
> I'm looking for people who experienced the same problem,
> or possibly for a fix.
>
>
> The devices are:
> 0000:03:0b.0 Multimedia video controller: Brooktree Corporation Bt878 Video Capture (rev 11)
> 0000:03:0b.1 Multimedia controller: Brooktree Corporation Bt878 Audio Capture (rev 11)
> 0000:03:0b.0 0400: 109e:036e (rev 11)
> 0000:03:0b.1 0480: 109e:0878 (rev 11)
>
>
> I'm using mencoder Debian package '1:1.0-pre7cvs20051102-0.0' from marillat's
> for x86_64 architecture.
>
> $ mencoder --version
> MEncoder dev-CVS--4.0.2 (C) 2000-2005 MPlayer Team
> CPU: Advanced Micro Devices Athlon 64 Newcastle,Winchester,San Diego,Venice; Sempron Palermo (Family: 15, Stepping: 0)
> Detected cache-line size is 64 bytes
> CPUflags: Type: 15 MMX: 1 MMX2: 1 3DNow: 1 3DNow2: 1 SSE: 1 SSE2: 1
> Compiled for x86 CPU with extensions: MMX MMX2 3DNow 3DNowEx SSE SSE2
>
> --version is not an MEncoder option
>
> Exiting... (error parsing cmdline)
>
>
>
>
>
> Linux dancer64 2.6.14-rc5dancer-gb563c9b1 #1 Thu Oct 27 12:55:05 JST 2005 x86_64 GNU/Linux
> mencoder output on 2.6.14 (today's git)
>
> channel: 12
> minutes: 30
> output filename: /home/dancer/XXX/XXX/
> MEncoder dev-CVS--4.0.2 (C) 2000-2005 MPlayer Team
> CPU: Advanced Micro Devices (Family: 8, Stepping: 0)
> Detected cache-line size is 64 bytes
> CPUflags: Type: 8 MMX: 1 MMX2: 1 3DNow: 1 3DNow2: 1 SSE: 1 SSE2: 1
> Compiled for x86 CPU with extensions: MMX MMX2 3DNow 3DNowEx SSE SSE2
>
> File not found: 'frameno.avi'
> Failed to open frameno.avi
> success: format: 9 data: 0x0 - 0x0
> TV detected! ;-)
> Selected driver: v4l2
> name: Video 4 Linux 2 input
> author: Martin Olschewski
> comment: first try, more to come ;-)
> Selected device: BT878 video (IODATA GV-BCTV5/PC
> Tuner cap:
> Tuner rxs: MONO
> Capabilites: video capture video overlay VBI capture device tuner read/write streaming
> supported norms: 0 = PAL; 1 = NTSC; 2 = SECAM; 3 = PAL-Nc; 4 = PAL-M; 5 = PAL-N; 6 = NTSC-JP; 7 = PAL-60;
> inputs: 0 = Television; 1 = Composite1; 2 = S-Video;
> Current input: 0
> Current format: YUYV
> v4l2: current audio mode is : STEREO
> Selected channel: 12 (freq: 217.250)
> v4l2: ioctl queue buffer failed: Bad address
>
>
>
> Linux dancer64 2.6.14-rc5dancer-gb563c9b1 #1 Thu Oct 27 12:55:05 JST 2005 x86_64 GNU/Linux
>
> mencoder output on 2.6.14-rc5:
> channel: 12
> minutes: 1
> output filename: /tmp/aaaa.avi
> MEncoder dev-CVS--4.0.2 (C) 2000-2005 MPlayer Team
> CPU: Advanced Micro Devices Athlon 64 Newcastle,Winchester,San Diego,Venice; Sempron Palermo (Family: 15, Stepping: 0)
> Detected cache-line size is 64 bytes
> CPUflags: Type: 15 MMX: 1 MMX2: 1 3DNow: 1 3DNow2: 1 SSE: 1 SSE2: 1
> Compiled for x86 CPU with extensions: MMX MMX2 3DNow 3DNowEx SSE SSE2
>
> success: format: 9 data: 0x0 - 0x0
> Selected driver: v4l2
> name: Video 4 Linux 2 input
> author: Martin Olschewski <[email protected]>
> comment: first try, more to come ;-)
> Selected device: BT878 video (IODATA GV-BCTV5/PC
> Tuner cap:
> Tuner rxs: MONO
> Capabilites: video capture video overlay VBI capture device tuner read/write streaming
> supported norms: 0 = PAL; 1 = NTSC; 2 = SECAM; 3 = PAL-Nc; 4 = PAL-M; 5 = PAL-N; 6 = NTSC-JP; 7 = PAL-60;
> inputs: 0 = Television; 1 = Composite1; 2 = S-Video;
> Current input: 0
> Current format: YUYV
> v4l2: current audio mode is : STEREO
> Selected channel: 12 (freq: 217.250)
> [V] filefmt:9 fourcc:0x30323449 size:320x240 fps:29.97 ftime:=0.0334
> ==========================================================================
> Opening audio decoder: [pcm] Uncompressed PCM audio decoder
> AUDIO: 48000 Hz, 2 ch, s16le, 1536.0 kbit/100.00% (ratio: 192000->192000)
> Selected audio codec: [pcm] afm: pcm (Uncompressed PCM)
> ==========================================================================
> Opening video filter: [expand osd=1]
> Expand: -1 x -1, -1 ; -1, osd: 1, aspect: 0.000000, round: 1
> ==========================================================================
> Opening video decoder: [raw] RAW Uncompressed Video
> VDec: vo config request - 320 x 240 (preferred colorspace: Planar I420)
> VDec: using Planar I420 as output csp (no 0)
> Movie-Aspect is undefined - no prescaling applied.
> videocodec: libavcodec (320x240 fourcc=34504d46 [FMP4])
> High quality encoding selected (non real time)!
> Selected video codec: [rawi420] vfm: raw (RAW I420)
> ==========================================================================
> Building audio filter chain for 48000Hz/2ch/s16le -> 0Hz/0ch/??...
> MP3 audio selected
> Building audio filter chain for 48000Hz/2ch/s16le -> 48000Hz/2ch/s16le...
> Writing AVI header...
> ODML: Aspect information not (yet?) available or unspecified, not writing vprp header.
> Forcing audio preload to 0, max pts correction to 0
> New_Face failed. Maybe the font path is wrong.
> Please supply the text font file (~/.mplayer/subfont.ttf).
> subtitle font: load_sub_face failed.
> ODML: Aspect information not (yet?) available or unspecified, not writing vprp header.
> Pos: 4.1s 124f ( 0%) 26fps Trem: 0min 0mb A-V:0.000 [1082:128]
> Flushing video frames
>
>
> CBR audio: 16000 bytes/sec, 384 bytes/block
>
> Writing AVI index...
> Fixing AVI header...
> ODML: Aspect information not (yet?) available or unspecified, not writing vprp header.
>
> Video stream: 1082.222 kbit/s (135277 B/s) size: 559707 bytes 4.137 secs 124 frames
>
> Audio stream: 128.000 kbit/s (16000 B/s) size: 66048 bytes 4.128 secs
> v4l2: 139 frames successfully processed, 0 frames dropped.
>
>
>
> regards,
> junichi
> --
> dancer@{debian.org,netfort.gr.jp} Debian Project
Junichi Uekawa wrote:
>Hi,
>
>I've tried running mplayer v4l2 input on a bt878 card, and it fails.
>xawtv works fine, and 2.6.14-rc5 used to work fine.
>
>On git 3b44f137b9a846c5452d9e6e1271b79b1dbcc942 :
>
>$ mplayer tv://1 -tv driver=v4l2
>MPlayer dev-CVS--4.0.2 (C) 2000-2005 MPlayer Team
>CPU: Advanced Micro Devices Athlon 64 Newcastle,Winchester,San Diego,Venice; Sempron Palermo (Family: 15, Stepping: 0)
>Detected cache-line size is 64 bytes
>CPUflags: MMX: 1 MMX2: 1 3DNow: 1 3DNow2: 1 SSE: 1 SSE2: 1
>Compiled for x86 CPU with extensions: MMX MMX2 3DNow 3DNowEx SSE SSE2
>
>
BTTV currently only supports v4l1. We are still in the process of
porting the bttv driver from v4l1 to v4l2. Nickolay is working on it.
-Michael Krufky
>Failed to open /dev/rtc: Permission denied (it should be readable by the user.)
>Opening joystick device /dev/input/js0
>Can't open joystick device /dev/input/js0 : Permission denied
>Can't init input joystick
>Setting up LIRC support...
>mplayer: could not connect to socket
>mplayer: No such file or directory
>Failed to open LIRC support.
>You will not be able to use your remote control.
>Playing tv://1.
>Cache fill: 0.00% (0 bytes)
>Selected driver: v4l2
> name: Video 4 Linux 2 input
> author: Martin Olschewski <[email protected]>
> comment: first try, more to come ;-)
>Selected device: BT878 video (IODATA GV-BCTV5/PC
> Tuner cap:
> Tuner rxs: MONO
> Capabilites: video capture video overlay VBI capture device tuner read/write streaming
> supported norms: 0 = PAL; 1 = NTSC; 2 = SECAM; 3 = PAL-Nc; 4 = PAL-M; 5 = PAL-N; 6 = NTSC-JP; 7 = PAL-60;
> inputs: 0 = Television; 1 = Composite1; 2 = S-Video;
> Current input: 0
> Current format: YUV420
>v4l2: current audio mode is : MONO
>v4l2: ioctl queue buffer failed: Bad address
>v4l2: 0 frames successfully processed, 0 frames dropped.
>
>
>
>At Thu, 03 Nov 2005 13:26:25 +0900,
>Junichi Uekawa wrote:
>
>
>>Hi,
>>
>>I've noticed that mencoder no longer works with bttv
>>capture on my system; with today's git tree
>>(ec1890c5df451799dec969a3581ff72e1934b5ee),
>>while it used to work on 2.6.14-rc5.
>>xawtv functions.
>>I'm looking for people who experienced the same problem,
>>or possibly for a fix.
>>
>>
>>The devices are:
>>0000:03:0b.0 Multimedia video controller: Brooktree Corporation Bt878 Video Capture (rev 11)
>>0000:03:0b.1 Multimedia controller: Brooktree Corporation Bt878 Audio Capture (rev 11)
>>0000:03:0b.0 0400: 109e:036e (rev 11)
>>0000:03:0b.1 0480: 109e:0878 (rev 11)
>>
>>
>>I'm using mencoder Debian package '1:1.0-pre7cvs20051102-0.0' from marillat's
>>for x86_64 architecture.
>>
>>$ mencoder --version
>>MEncoder dev-CVS--4.0.2 (C) 2000-2005 MPlayer Team
>>CPU: Advanced Micro Devices Athlon 64 Newcastle,Winchester,San Diego,Venice; Sempron Palermo (Family: 15, Stepping: 0)
>>Detected cache-line size is 64 bytes
>>CPUflags: Type: 15 MMX: 1 MMX2: 1 3DNow: 1 3DNow2: 1 SSE: 1 SSE2: 1
>>Compiled for x86 CPU with extensions: MMX MMX2 3DNow 3DNowEx SSE SSE2
>>
>>--version is not an MEncoder option
>>
>>Exiting... (error parsing cmdline)
>>
>>
>>
>>
>>
>>Linux dancer64 2.6.14-rc5dancer-gb563c9b1 #1 Thu Oct 27 12:55:05 JST 2005 x86_64 GNU/Linux
>>mencoder output on 2.6.14 (today's git)
>>
>>channel: 12
>>minutes: 30
>>output filename: /home/dancer/XXX/XXX/
>>MEncoder dev-CVS--4.0.2 (C) 2000-2005 MPlayer Team
>>CPU: Advanced Micro Devices (Family: 8, Stepping: 0)
>>Detected cache-line size is 64 bytes
>>CPUflags: Type: 8 MMX: 1 MMX2: 1 3DNow: 1 3DNow2: 1 SSE: 1 SSE2: 1
>>Compiled for x86 CPU with extensions: MMX MMX2 3DNow 3DNowEx SSE SSE2
>>
>>File not found: 'frameno.avi'
>>Failed to open frameno.avi
>>success: format: 9 data: 0x0 - 0x0
>>TV detected! ;-)
>>Selected driver: v4l2
>> name: Video 4 Linux 2 input
>> author: Martin Olschewski
>> comment: first try, more to come ;-)
>>Selected device: BT878 video (IODATA GV-BCTV5/PC
>> Tuner cap:
>> Tuner rxs: MONO
>> Capabilites: video capture video overlay VBI capture device tuner read/write streaming
>> supported norms: 0 = PAL; 1 = NTSC; 2 = SECAM; 3 = PAL-Nc; 4 = PAL-M; 5 = PAL-N; 6 = NTSC-JP; 7 = PAL-60;
>> inputs: 0 = Television; 1 = Composite1; 2 = S-Video;
>> Current input: 0
>> Current format: YUYV
>>v4l2: current audio mode is : STEREO
>>Selected channel: 12 (freq: 217.250)
>>v4l2: ioctl queue buffer failed: Bad address
>>
>>
>>
>>Linux dancer64 2.6.14-rc5dancer-gb563c9b1 #1 Thu Oct 27 12:55:05 JST 2005 x86_64 GNU/Linux
>>
>>mencoder output on 2.6.14-rc5:
>>channel: 12
>>minutes: 1
>>output filename: /tmp/aaaa.avi
>>MEncoder dev-CVS--4.0.2 (C) 2000-2005 MPlayer Team
>>CPU: Advanced Micro Devices Athlon 64 Newcastle,Winchester,San Diego,Venice; Sempron Palermo (Family: 15, Stepping: 0)
>>Detected cache-line size is 64 bytes
>>CPUflags: Type: 15 MMX: 1 MMX2: 1 3DNow: 1 3DNow2: 1 SSE: 1 SSE2: 1
>>Compiled for x86 CPU with extensions: MMX MMX2 3DNow 3DNowEx SSE SSE2
>>
>>success: format: 9 data: 0x0 - 0x0
>>Selected driver: v4l2
>> name: Video 4 Linux 2 input
>> author: Martin Olschewski <[email protected]>
>> comment: first try, more to come ;-)
>>Selected device: BT878 video (IODATA GV-BCTV5/PC
>> Tuner cap:
>> Tuner rxs: MONO
>> Capabilites: video capture video overlay VBI capture device tuner read/write streaming
>> supported norms: 0 = PAL; 1 = NTSC; 2 = SECAM; 3 = PAL-Nc; 4 = PAL-M; 5 = PAL-N; 6 = NTSC-JP; 7 = PAL-60;
>> inputs: 0 = Television; 1 = Composite1; 2 = S-Video;
>> Current input: 0
>> Current format: YUYV
>>v4l2: current audio mode is : STEREO
>>Selected channel: 12 (freq: 217.250)
>>[V] filefmt:9 fourcc:0x30323449 size:320x240 fps:29.97 ftime:=0.0334
>>==========================================================================
>>Opening audio decoder: [pcm] Uncompressed PCM audio decoder
>>AUDIO: 48000 Hz, 2 ch, s16le, 1536.0 kbit/100.00% (ratio: 192000->192000)
>>Selected audio codec: [pcm] afm: pcm (Uncompressed PCM)
>>==========================================================================
>>Opening video filter: [expand osd=1]
>>Expand: -1 x -1, -1 ; -1, osd: 1, aspect: 0.000000, round: 1
>>==========================================================================
>>Opening video decoder: [raw] RAW Uncompressed Video
>>VDec: vo config request - 320 x 240 (preferred colorspace: Planar I420)
>>VDec: using Planar I420 as output csp (no 0)
>>Movie-Aspect is undefined - no prescaling applied.
>>videocodec: libavcodec (320x240 fourcc=34504d46 [FMP4])
>>High quality encoding selected (non real time)!
>>Selected video codec: [rawi420] vfm: raw (RAW I420)
>>==========================================================================
>>Building audio filter chain for 48000Hz/2ch/s16le -> 0Hz/0ch/??...
>>MP3 audio selected
>>Building audio filter chain for 48000Hz/2ch/s16le -> 48000Hz/2ch/s16le...
>>Writing AVI header...
>>ODML: Aspect information not (yet?) available or unspecified, not writing vprp header.
>>Forcing audio preload to 0, max pts correction to 0
>>New_Face failed. Maybe the font path is wrong.
>>Please supply the text font file (~/.mplayer/subfont.ttf).
>>subtitle font: load_sub_face failed.
>>ODML: Aspect information not (yet?) available or unspecified, not writing vprp header.
>>Pos: 4.1s 124f ( 0%) 26fps Trem: 0min 0mb A-V:0.000 [1082:128]
>>Flushing video frames
>>
>>
>>CBR audio: 16000 bytes/sec, 384 bytes/block
>>
>>Writing AVI index...
>>Fixing AVI header...
>>ODML: Aspect information not (yet?) available or unspecified, not writing vprp header.
>>
>>Video stream: 1082.222 kbit/s (135277 B/s) size: 559707 bytes 4.137 secs 124 frames
>>
>>Audio stream: 128.000 kbit/s (16000 B/s) size: 66048 bytes 4.128 secs
>>v4l2: 139 frames successfully processed, 0 frames dropped.
>>
>>
>>
>>regards,
>> junichi
>>--
>>dancer@{debian.org,netfort.gr.jp} Debian Project
>>
>>
>-
>To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
>the body of a message to [email protected]
>More majordomo info at http://vger.kernel.org/majordomo-info.html
>Please read the FAQ at http://www.tux.org/lkml/
>
>
--
Michael Krufky
Hi,
> >I've tried running mplayer v4l2 input on a bt878 card, and it fails.
> >xawtv works fine, and 2.6.14-rc5 used to work fine.
> >
> >On git 3b44f137b9a846c5452d9e6e1271b79b1dbcc942 :
> >
> >$ mplayer tv://1 -tv driver=v4l2
> >MPlayer dev-CVS--4.0.2 (C) 2000-2005 MPlayer Team
> >CPU: Advanced Micro Devices Athlon 64 Newcastle,Winchester,San Diego,Venice; Sempron Palermo (Family: 15, Stepping: 0)
> >Detected cache-line size is 64 bytes
> >CPUflags: MMX: 1 MMX2: 1 3DNow: 1 3DNow2: 1 SSE: 1 SSE2: 1
> >Compiled for x86 CPU with extensions: MMX MMX2 3DNow 3DNowEx SSE SSE2
> >
> >
> BTTV currently only supports v4l1. We are still in the process of
> porting the bttv driver from v4l1 to v4l2. Nickolay is working on it.
>
Thanks for the info. It's strange since this is a regression
(pre 2.6.14 used to work. New code made it fail).
Do you mean there was a change that broke v4l2 support in bttv ?
Ever since Linux Kernel 2.6.3, I used v4l2 for recording (more
than one and a half years...)
regards,
junichi
--
dancer@{debian.org,netfort.gr.jp} Debian Project
Junichi Uekawa wrote:
>Hi,
>
>>>I've tried running mplayer v4l2 input on a bt878 card, and it fails.
>>>xawtv works fine, and 2.6.14-rc5 used to work fine.
>>>
>>>On git 3b44f137b9a846c5452d9e6e1271b79b1dbcc942 :
>>>
>>>$ mplayer tv://1 -tv driver=v4l2
>>>MPlayer dev-CVS--4.0.2 (C) 2000-2005 MPlayer Team
>>>CPU: Advanced Micro Devices Athlon 64 Newcastle,Winchester,San Diego,Venice; Sempron Palermo (Family: 15, Stepping: 0)
>>>Detected cache-line size is 64 bytes
>>>CPUflags: MMX: 1 MMX2: 1 3DNow: 1 3DNow2: 1 SSE: 1 SSE2: 1
>>>Compiled for x86 CPU with extensions: MMX MMX2 3DNow 3DNowEx SSE SSE2
>>>
>>bttv currently only supports v4l1. We are still in the process of
>>porting the bttv driver from v4l1 to v4l2. Nickolay is working on it.
>>
>Thanks for the info. It's strange since this is a regression
>(pre 2.6.14 used to work. New code made it fail).
>Do you mean there was a change that broke v4l2 support in bttv ?
>Ever since Linux Kernel 2.6.3, I used v4l2 for recording (more
>than one and a half years...)
>
>
v4l2 support could not have been broken, since it was never present.
You were going through a compat layer.... Maybe that's where the
regression is.
Anyhow, I will discuss this with the other v4l guys... One of us will
get back to you, maybe ask you to test a patch or two.
One question -- At exactly what point does this break for you? The git
commit key above was from today, but at what point did this LAST work
for you? It would be really helpful if you can do a git bisection test,
so that we can isolate the trouble patch if in fact it is a regression.
You might also like to join us in #v4l on irc.freenode.net ... Sometimes
it's much quicker to troubleshoot this stuff over irc instead of email.
-Michael Krufky
Hi,
> >>>$ mplayer tv://1 -tv driver=v4l2
> >>>MPlayer dev-CVS--4.0.2 (C) 2000-2005 MPlayer Team
> >>>CPU: Advanced Micro Devices Athlon 64 Newcastle,Winchester,San Diego,Venice; Sempron Palermo (Family: 15, Stepping: 0)
> >>>Detected cache-line size is 64 bytes
> >>>CPUflags: MMX: 1 MMX2: 1 3DNow: 1 3DNow2: 1 SSE: 1 SSE2: 1
> >>>Compiled for x86 CPU with extensions: MMX MMX2 3DNow 3DNowEx SSE SSE2
> >>>
> >>bttv currently only supports v4l1. We are still in the process of
> >>porting the bttv driver from v4l1 to v4l2. Nickolay is working on it.
> >>
> >Thanks for the info. It's strange since this is a regression
> >(pre 2.6.14 used to work. New code made it fail).
> >Do you mean there was a change that broke v4l2 support in bttv ?
> >Ever since Linux Kernel 2.6.3, I used v4l2 for recording (more
> >than one and a half years...)
> >
> >
> v4l2 support could not have been broken, since it was never present.
> You were going through a compat layer.... Maybe that's where the
> regression is.
> One question -- At exactly what point does this break for you? The git
> commit key above was from today, but at what point did this LAST work
> for you? It would be really helpful if you can do a git bisection test,
> so that we can isolate the trouble patch if in fact it is a regression.
df70b17f88a4d1d8545d3569a1f6d28c6004f9e4 2 Nov 2005 Nonfunctional bttv
d83c671fb7023f69a9582e622d01525054f23b66 1 Nov 2005 (fails to boot due to USB issues)
6e9d6b8ee4e0c37d3952256e6472c57490d6780d 27 Oct 2005 Functional bttv
> You might also like to join us in #v4l on irc.freenode.net ... Sometimes
> it's much quicker to troubleshoot this stuff over irc instead of email.
joined, but currently rebooting sporadically to test
different kernels.
regards,
junichi
Junichi Uekawa wrote:
>>>>> mplayer tv://1 -tv driver=v4l2
>>>>>MPlayer dev-CVS--4.0.2 (C) 2000-2005 MPlayer Team
>>>>>CPU: Advanced Micro Devices Athlon 64 Newcastle,Winchester,San Diego,Venice; Sempron Palermo (Family: 15, Stepping: 0)
>>>>>Detected cache-line size is 64 bytes
>>>>>CPUflags: MMX: 1 MMX2: 1 3DNow: 1 3DNow2: 1 SSE: 1 SSE2: 1
>>>>>Compiled for x86 CPU with extensions: MMX MMX2 3DNow 3DNowEx SSE SSE2
>>>>>
>>>>bttv currently only supports v4l1. We are still in the process of
>>>>porting the bttv driver from v4l1 to v4l2. Nickolay is working on it.
>>>>
>>>Thanks for the info. It's strange since this is a regression
>>>(pre 2.6.14 used to work. New code made it fail).
>>>Do you mean there was a change that broke v4l2 support in bttv ?
>>>Ever since Linux Kernel 2.6.3, I used v4l2 for recording (more
>>>than one and a half years...)
>>>
>>v4l2 support could not have been broken, since it was never present.
>>You were going through a compat layer.... Maybe that's where the
>>regression is.
>>
>>
>>One question -- At exactly what point does this break for you? The git
>>commit key above was from today, but at what point did this LAST work
>>for you? It would be really helpful if you can do a git bisection test,
>>so that we can isolate the trouble patch if in fact it is a regression.
>>
>>
>df70b17f88a4d1d8545d3569a1f6d28c6004f9e4 2 Nov 2005 Nonfunctional bttv
>d83c671fb7023f69a9582e622d01525054f23b66 1 Nov 2005 (fails to boot due to USB issues)
>6e9d6b8ee4e0c37d3952256e6472c57490d6780d 27 Oct 2005 Functional bttv
>
>
This info was quite helpful... Looking through gitweb, it looks like the
trouble began for you BEFORE Mauro started to send our new patchsets
over to akpm. If I am correct, this indicates that the problem patch is
from elsewhere in the kernel.
I saw a thread about some i2c related bttv problem... I don't know if
that's a red herring or not, but it was also around the time that you
say your kernel breaks.
At this point, the best thing that you can do is run a git bisection
regression test, like I had previously suggested. Linus has written a
HOWTO thread about it a few months ago on LKML. Does anybody know if
there is a howto online for git bisection testing? Maybe there's a copy
of the thread on kerneltrap.org? just a guess...
If we can narrow this down to the exact patch that is causing the
problem for you, it would be a lot easier to deal with.
>>You might also like to join us in #v4l on irc.freenode.net ... Sometimes
>>it's much quicker to troubleshoot this stuff over irc instead of email.
>>
>>
>joined, but currently rebooting sporadically to test
>different kernels.
>
>
Okay, well here are a few other things that I would have you try:
#1) Try using v4l-kernel cvs, and tell us if you still have the problem.
Since I think that the problem is occurring for you elsewhere in the
kernel, using our code in cvs should yeild no change in behavior. Even
though this doesn't sound promising, it can help us to prove whether v4l
is responsible for this problem or not:
http://linuxtv.org/v4lwiki/index.php/How_to_build_from_CVS
First, try out latest cvs. Yes, there is still some new code in cvs that
we have not yet sent upstream, including some compat_ioctl32.c fixes
from Nickolay from this morning.
#2) After testing the latest cvs, then I would ask for you to wipe out
the cvs tree and try again, but using older code..... Say, from October
first or so, maybe even September first. To do this, follow the same
procedure in the wiki-howto above, but add the -D parameter to the cvs
checkout command. ( cvs co -D 2005-09-01 -- see man cvs)
I would assume that there will be no difference in behavior between the
different cvs versions, but maybe you will find otherwise.
#3) Another thing you can try is to build the current cvs modules
against the last known working kernel. If the new cvs modules in the
older kernel break it again, then it tells us that some new v4l code IS
to blame.
#4) Once again, the -git bisection regression testing is the best thing
to do here.
Regards,
Michael Krufky
Hi,
> > One question -- At exactly what point does this break for you? The git
> > commit key above was from today, but at what point did this LAST work
> > for you? It would be really helpful if you can do a git bisection test,
> > so that we can isolate the trouble patch if in fact it is a regression.
>
> df70b17f88a4d1d8545d3569a1f6d28c6004f9e4 2 Nov 2005 Nonfunctional bttv
> d83c671fb7023f69a9582e622d01525054f23b66 1 Nov 2005 (fails to boot due to USB issues)
> 6e9d6b8ee4e0c37d3952256e6472c57490d6780d 27 Oct 2005 Functional bttv
That was wrong; I re-tested it and it looks like
6e9d6b8ee4e0c37d3952256e6472c57490d6780d was a bad one.
2.6.14 (741b2252a5e14d6c60a913c77a6099abe73a854a) is functional.
$ git-bisect start
$ git-bisect bad 6e9d6b8ee4e0c37d3952256e6472c57490d6780d
$ git-bisect good 741b2252a5e14d6c60a913c77a6099abe73a854a
Bisecting: 721 revisions left to test after this
regards,
junichi
On Fri, 11 Nov 2005, Junichi Uekawa wrote:
>
> > > One question -- At exactly what point does this break for you? The git
> > > commit key above was from today, but at what point did this LAST work
> > > for you? It would be really helpful if you can do a git bisection test,
> > > so that we can isolate the trouble patch if in fact it is a regression.
>
> $ git-bisect start
> $ git-bisect bad 6e9d6b8ee4e0c37d3952256e6472c57490d6780d
> $ git-bisect good 741b2252a5e14d6c60a913c77a6099abe73a854a
> Bisecting: 721 revisions left to test after this
This is probably going to converge on the PageReserved removal patch,
and the way get_user_pages now refuses on a VM_RESERVED vma.
I don't want to send you a patch for that immediately, we're still
thinking through the implications of allowing VM_RESERVED there again
(it might just hit another BUG, or leak memory). And we probably
need to take the separate "vbetool" problem into account too.
Though if you're curious and impatient, you could try just editing
the " | VM_RESERVED" out of mm/memory.c get_user_pages.
Hugh
Hi,
> That was wrong; I re-tested it and it looks like
> 6e9d6b8ee4e0c37d3952256e6472c57490d6780d was a bad one.
> 2.6.14 (741b2252a5e14d6c60a913c77a6099abe73a854a) is functional.
>
> $ git-bisect start
> $ git-bisect bad 6e9d6b8ee4e0c37d3952256e6472c57490d6780d
> $ git-bisect good 741b2252a5e14d6c60a913c77a6099abe73a854a
> Bisecting: 721 revisions left to test after this
After that I tried:
$ git-bisect bad
Bisecting: 1966 revisions left to test after this
[23fd07750a789a66fe88cf173d52a18f1a387da4] Merge ../linux-2.6 by hand
I'm not quite sure why the following happened.
6e9d6b8ee4e0c37d3952256e6472c57490d6780d 30 Oct is broken
741b2252a5e14d6c60a913c77a6099abe73a854a 27 Oct is functional
6e6ece5dc6022e8086c565498d23511bbceda811 10 Nov is broken
23fd07750a789a66fe88cf173d52a18f1a387da4 31 Oct -- does not boot due to USB/PCI quirks
Maybe I'm doing something wrong.
$ git-bisect log
git-bisect start
# bad: [6e9d6b8ee4e0c37d3952256e6472c57490d6780d] Merge branch 'upstream-linus' of master.kernel.org:/pub/scm/linux/kernel/git/jgarzik/libata-dev
git-bisect bad 6e9d6b8ee4e0c37d3952256e6472c57490d6780d
# good: [741b2252a5e14d6c60a913c77a6099abe73a854a] Linux v2.6.14
git-bisect good 741b2252a5e14d6c60a913c77a6099abe73a854a
# bad: [6e6ece5dc6022e8086c565498d23511bbceda811] PCI: fix for Toshiba ohci1394 quirk
git-bisect bad 6e6ece5dc6022e8086c565498d23511bbceda811
regards,
junichi
Hello again;
We just got confirmation from someone at freenode that this problem
exists with other chips as well (saa7134, in this case), so it's not
chip dependent. It seems to be confined to x86_64 and 2.6.15, though.
On Fri, 2005-11-11 at 23:21 +0900, Junichi Uekawa wrote:
> Hi,
>
> > That was wrong; I re-tested it and it looks like
> > 6e9d6b8ee4e0c37d3952256e6472c57490d6780d was a bad one.
> > 2.6.14 (741b2252a5e14d6c60a913c77a6099abe73a854a) is functional.
> >
> > $ git-bisect start
> > $ git-bisect bad 6e9d6b8ee4e0c37d3952256e6472c57490d6780d
> > $ git-bisect good 741b2252a5e14d6c60a913c77a6099abe73a854a
> > Bisecting: 721 revisions left to test after this
>
> After that I tried:
> $ git-bisect bad
> Bisecting: 1966 revisions left to test after this
> [23fd07750a789a66fe88cf173d52a18f1a387da4] Merge ../linux-2.6 by hand
>
> I'm not quite sure why the following happened.
> 6e9d6b8ee4e0c37d3952256e6472c57490d6780d 30 Oct is broken
> 741b2252a5e14d6c60a913c77a6099abe73a854a 27 Oct is functional
> 6e6ece5dc6022e8086c565498d23511bbceda811 10 Nov is broken
> 23fd07750a789a66fe88cf173d52a18f1a387da4 31 Oct -- does not boot due to USB/PCI quirks
>
> Maybe I'm doing something wrong.
>
>
>
> $ git-bisect log
> git-bisect start
> # bad: [6e9d6b8ee4e0c37d3952256e6472c57490d6780d] Merge branch 'upstream-linus' of master.kernel.org:/pub/scm/linux/kernel/git/jgarzik/libata-dev
> git-bisect bad 6e9d6b8ee4e0c37d3952256e6472c57490d6780d
> # good: [741b2252a5e14d6c60a913c77a6099abe73a854a] Linux v2.6.14
> git-bisect good 741b2252a5e14d6c60a913c77a6099abe73a854a
> # bad: [6e6ece5dc6022e8086c565498d23511bbceda811] PCI: fix for Toshiba ohci1394 quirk
> git-bisect bad 6e6ece5dc6022e8086c565498d23511bbceda811
>
>
>
> regards,
> junichi
>
> --
> video4linux-list mailing list
> Unsubscribe mailto:[email protected]?subject=unsubscribe
> https://www.redhat.com/mailman/listinfo/video4linux-list
--
Ricardo Cerqueira
ISP - Service & Platform Architectures
Novis Telecom - Estrada da Outurela, 118 A / 2795-606 Carnaxide /
Portugal
Tel: +351 2 1010 4686 - Fax: +351 2 1012 9248
Hello all.
We have even found the hack that fix that problem:
Index: linux/drivers/media/video/video-buf.c
===================================================================
RCS file: /cvs/video4linux/v4l-kernel/linux/drivers/media/video/video-buf.c,v
retrieving revision 1.21
diff -u -p -r1.21 video-buf.c
--- linux/drivers/media/video/video-buf.c 16 Oct 2005 12:13:58 -0000
+++ linux/drivers/media/video/video-buf.c 12 Nov 2005 22:19:13 -0000
@@ -1248,7 +1248,7 @@ int videobuf_mmap_mapper(struct videobuf
map->end = vma->vm_end;
map->q = q;
vma->vm_ops = &videobuf_vm_ops;
- vma->vm_flags |= VM_DONTEXPAND | VM_RESERVED;
+ vma->vm_flags |= VM_DONTEXPAND;
vma->vm_flags &= ~VM_IO; /* using shared anonymous pages */
vma->vm_private_data = map;
dprintk(1,"mmap %p: q=%p %08lx-%08lx pgoff %08lx bufs %d-%d\n",
Somehow since 2.6.15-rc1 VM_RESERVED makes get_user_pages return EFAULT. I don't know the exact reason of
that behavior and the correct way to fix that problem. Just kernel interfaces changed once again, the old
point everyone knows. So if someone can explain it, that would be helpful.
On Sun, Nov 13, 2005 at 01:22:51AM +0300, Nickolay V. Shmyrev wrote:
> Hello all.
>
> We have even found the hack that fix that problem:
A hack, but working one..
(for the small while that I tested it)
> Index: linux/drivers/media/video/video-buf.c
> ===================================================================
> RCS file: /cvs/video4linux/v4l-kernel/linux/drivers/media/video/video-buf.c,v
> retrieving revision 1.21
> diff -u -p -r1.21 video-buf.c
> --- linux/drivers/media/video/video-buf.c 16 Oct 2005 12:13:58 -0000
> +++ linux/drivers/media/video/video-buf.c 12 Nov 2005 22:19:13 -0000
> @@ -1248,7 +1248,7 @@ int videobuf_mmap_mapper(struct videobuf
> map->end = vma->vm_end;
> map->q = q;
> vma->vm_ops = &videobuf_vm_ops;
> - vma->vm_flags |= VM_DONTEXPAND | VM_RESERVED;
> + vma->vm_flags |= VM_DONTEXPAND;
> vma->vm_flags &= ~VM_IO; /* using shared anonymous pages */
> vma->vm_private_data = map;
> dprintk(1,"mmap %p: q=%p %08lx-%08lx pgoff %08lx bufs %d-%d\n",
>
> Somehow since 2.6.15-rc1 VM_RESERVED makes get_user_pages return EFAULT.
> I don't know the exact reason of that behavior and the correct way to fix
> that problem. Just kernel interfaces changed once again, the old
> point everyone knows. So if someone can explain it, that would be helpful.
This EFAULT rejection is due to change in get_user_pages() function
in mm/memory.c file of 2.6.14-git2
@@ -945,8 +947,8 @@ int get_user_pages(struct task_struct *t
continue;
}
- if (!vma || (vma->vm_flags & VM_IO)
- || !(flags & vma->vm_flags))
+ if (!vma || (vma->vm_flags & (VM_IO | VM_RESERVED))
+ || !(vm_flags & vma->vm_flags))
return i ? : -EFAULT;
if (is_vm_hugetlb_page(vma)) {
I don't know how to use git tools to see, whose patch actually
did this particular change.
/Matti Aarnio
Hi,
> This EFAULT rejection is due to change in get_user_pages() function
> in mm/memory.c file of 2.6.14-git2
>
>
> @@ -945,8 +947,8 @@ int get_user_pages(struct task_struct *t
> continue;
> }
>
> - if (!vma || (vma->vm_flags & VM_IO)
> - || !(flags & vma->vm_flags))
> + if (!vma || (vma->vm_flags & (VM_IO | VM_RESERVED))
> + || !(vm_flags & vma->vm_flags))
> return i ? : -EFAULT;
>
> if (is_vm_hugetlb_page(vma)) {
>
>
> I don't know how to use git tools to see, whose patch actually
> did this particular change.
To quote:
> MAP_PRIVATE, PROT_WRITE of VM_RESERVED regions is tentatively being
> deprecated. We never completely handled it correctly anyway, and is be
> reintroduced in future if required (Hugh has a proof of concept).
diff-tree b5810039a54e5babf428e9a1e89fc1940fabff11 (from f9c98d0287de42221c62448Author: Nick Piggin <[email protected]>
Date: Sat Oct 29 18:16:12 2005 -0700
[PATCH] core remove PageReserved
Remove PageReserved() calls from core code by tightening VM_RESERVED
handling in mm/ to cover PageReserved functionality.
PageReserved special casing is removed from get_page and put_page.
All setting and clearing of PageReserved is retained, and it is now flagged
in the page_alloc checks to help ensure we don't introduce any refcount
based freeing of Reserved pages.
MAP_PRIVATE, PROT_WRITE of VM_RESERVED regions is tentatively being
deprecated. We never completely handled it correctly anyway, and is be
reintroduced in future if required (Hugh has a proof of concept).
Once PageReserved() calls are removed from kernel/power/swsusp.c, and all
arch/ and driver code, the Set and Clear calls, and the PG_reserved bit can
be trivially removed.
Last real user of PageReserved is swsusp, which uses PageReserved to
determine whether a struct page points to valid memory or not. This still
needs to be addressed (a generic page_is_ram() should work).
A last caveat: the ZERO_PAGE is now refcounted and managed with rmap (and
thus mapcounted and count towards shared rss). These writes to the struct
page could cause excessive cacheline bouncing on big systems. There are a
number of ways this could be addressed if it is an issue.
Signed-off-by: Nick Piggin <[email protected]>
Refcount bug fix for filemap_xip.c
Signed-off-by: Carsten Otte <[email protected]>
Signed-off-by: Andrew Morton <[email protected]>
Signed-off-by: Linus Torvalds <[email protected]>
I think the relevant changes (snipped out) are:
diff --git a/include/linux/mm.h b/include/linux/mm.h
index 0c64484..da42093 100644
--- a/include/linux/mm.h
+++ b/include/linux/mm.h
@@ -157,7 +157,7 @@ extern unsigned int kobjsize(const void
#define VM_DONTCOPY 0x00020000 /* Do not copy this vma on fork */
#define VM_DONTEXPAND 0x00040000 /* Cannot expand with mremap() */
-#define VM_RESERVED 0x00080000 /* Don't unmap it from swap_out */
+#define VM_RESERVED 0x00080000 /* Pages managed in a special way */
#define VM_ACCOUNT 0x00100000 /* Is a VM accounted object */
#define VM_HUGETLB 0x00400000 /* Huge TLB Page VM */
#define VM_NONLINEAR 0x00800000 /* Is non-linear (remap_file_pages) */
diff --git a/mm/memory.c b/mm/memory.c
index da642b5..e83f944 100644
--- a/mm/memory.c
+++ b/mm/memory.c
@@ -967,7 +992,7 @@ int get_user_pages(struct task_struct *t
continue;
}
- if (!vma || (vma->vm_flags & VM_IO)
+ if (!vma || (vma->vm_flags & (VM_IO | VM_RESERVED))
|| !(flags & vma->vm_flags))
return i ? : -EFAULT;
regards,
junichi
? ???, 13/11/2005 ? 04:54 +0200, Matti Aarnio ?????:
> On Sun, Nov 13, 2005 at 01:22:51AM +0300, Nickolay V. Shmyrev wrote:
> > Hello all.
> >
> > We have even found the hack that fix that problem:
>
> A hack, but working one..
> (for the small while that I tested it)
>
> > Index: linux/drivers/media/video/video-buf.c
> > ===================================================================
> > RCS file: /cvs/video4linux/v4l-kernel/linux/drivers/media/video/video-buf.c,v
> > retrieving revision 1.21
> > diff -u -p -r1.21 video-buf.c
> > --- linux/drivers/media/video/video-buf.c 16 Oct 2005 12:13:58 -0000
> > +++ linux/drivers/media/video/video-buf.c 12 Nov 2005 22:19:13 -0000
> > @@ -1248,7 +1248,7 @@ int videobuf_mmap_mapper(struct videobuf
> > map->end = vma->vm_end;
> > map->q = q;
> > vma->vm_ops = &videobuf_vm_ops;
> > - vma->vm_flags |= VM_DONTEXPAND | VM_RESERVED;
> > + vma->vm_flags |= VM_DONTEXPAND;
> > vma->vm_flags &= ~VM_IO; /* using shared anonymous pages */
> > vma->vm_private_data = map;
> > dprintk(1,"mmap %p: q=%p %08lx-%08lx pgoff %08lx bufs %d-%d\n",
> >
> > Somehow since 2.6.15-rc1 VM_RESERVED makes get_user_pages return EFAULT.
> > I don't know the exact reason of that behavior and the correct way to fix
> > that problem. Just kernel interfaces changed once again, the old
> > point everyone knows. So if someone can explain it, that would be helpful.
>
> This EFAULT rejection is due to change in get_user_pages() function
> in mm/memory.c file of 2.6.14-git2
>
>
> @@ -945,8 +947,8 @@ int get_user_pages(struct task_struct *t
> continue;
> }
>
> - if (!vma || (vma->vm_flags & VM_IO)
> - || !(flags & vma->vm_flags))
> + if (!vma || (vma->vm_flags & (VM_IO | VM_RESERVED))
> + || !(vm_flags & vma->vm_flags))
> return i ? : -EFAULT;
>
> if (is_vm_hugetlb_page(vma)) {
>
>
> I don't know how to use git tools to see, whose patch actually
> did this particular change.
>
>
> /Matti Aarnio
It's sad, but I still don't understand the way it should be fixed.
Removal of VM_RESERVED is certainly not a solution, since we don't going
to swap mmaped pages and VM_RESERVED is used in other drivers (for
example, some sound drivers)
So, we need to find the problem itself. After looking at the code I've
found that the x86_64 dependency of that problem lies in the check in
memory.c:get_user_pages
if (vma && in_gate_area (task, start))
x86_64 defines it's own arch-dependant function in_gate_area which fails
in our case. Can someone trace that code and find why do we fail and
fail only on x86_64. It would be nice if someone could point me to
get_user_pages documentation, why it's so differently behaves for 64 bit
arch.
Also it seems that I had traces of video-buf module with debug enabled
on 64 bit, but lost them. Can someone just enable debug option to video-
buf module and collect those traces.
On Wed, 16 Nov 2005, Nickolay V. Shmyrev wrote:
>
> It's sad, but I still don't understand the way it should be fixed.
> Removal of VM_RESERVED is certainly not a solution, since we don't going
> to swap mmaped pages and VM_RESERVED is used in other drivers (for
> example, some sound drivers)
Early in this thread (last Friday) I said that I was working on
the fix for this and some other PageReserved removal problems.
I suggested then:
Though if you're curious and impatient, you could try just editing
the " | VM_RESERVED" out of mm/memory.c get_user_pages.
Does that not work for you? It's not the full solution to all the
issues, but I'd expect it to be enough to get you going. If it does
not work for you, then I need to understand why not in a hurry:
please let me know either way.
I'm at last getting near with my patches, hope to post later tonight
(but everything always takes me longer than I expect).
> So, we need to find the problem itself. After looking at the code I've
> found that the x86_64 dependency of that problem lies in the check in
> memory.c:get_user_pages
>
> if (vma && in_gate_area (task, start))
>
> x86_64 defines it's own arch-dependant function in_gate_area which fails
> in our case.
Why would you expect "in_gate_area" to pass in your case? I'd be very
surprised if the user pages you're trying to get are in the gate area.
I doubt that has anything to do with it: please try what I suggested.
Hugh
> Can someone trace that code and find why do we fail and
> fail only on x86_64. It would be nice if someone could point me to
> get_user_pages documentation, why it's so differently behaves for 64 bit
> arch.
>
> Also it seems that I had traces of video-buf module with debug enabled
> on 64 bit, but lost them. Can someone just enable debug option to video-
> buf module and collect those traces.
Hi,
Verified that with the following patch, I can run mencoder fine.
$ uname -a
Linux dancer64 2.6.15-rc1dancer-gf6ff56cd #1 Thu Nov 17 08:18:33 JST 2005 x86_64 GNU/Linux
Applied upon linus' git from yesterday:
commit f6ff56cd56b83d8edf4b3cffc5c53c56b37a5081
tree 0ec4807d49a602ba785e60e5352b542f1581d4c9
parent fb6d73d3014babb69f5cc2d1d78b31e9d09fc5df
parent 5a6f294e43e432bd207a702fea49ebb303ef9b23
author Linus Torvalds <[email protected]> Tue Nov 15 16:59:38 UTC 2005
committer Linus Torvalds <[email protected]> Tue Nov 15 16:59:38 UTC 2005
Merge master.kernel.org:/pub/scm/linux/kernel/git/davem/net-2.6
>
> We have even found the hack that fix that problem:
>
> Index: linux/drivers/media/video/video-buf.c
> ===================================================================
> RCS file: /cvs/video4linux/v4l-kernel/linux/drivers/media/video/video-buf.c,v
> retrieving revision 1.21
> diff -u -p -r1.21 video-buf.c
> --- linux/drivers/media/video/video-buf.c 16 Oct 2005 12:13:58 -0000
> +++ linux/drivers/media/video/video-buf.c 12 Nov 2005 22:19:13 -0000
> @@ -1248,7 +1248,7 @@ int videobuf_mmap_mapper(struct videobuf
> map->end = vma->vm_end;
> map->q = q;
> vma->vm_ops = &videobuf_vm_ops;
> - vma->vm_flags |= VM_DONTEXPAND | VM_RESERVED;
> + vma->vm_flags |= VM_DONTEXPAND;
> vma->vm_flags &= ~VM_IO; /* using shared anonymous pages */
> vma->vm_private_data = map;
> dprintk(1,"mmap %p: q=%p %08lx-%08lx pgoff %08lx bufs %d-%d\n",
>
> Somehow since 2.6.15-rc1 VM_RESERVED makes get_user_pages return EFAULT. I don't know the exact reason of
> that behavior and the correct way to fix that problem. Just kernel interfaces changed once again, the old
> point everyone knows. So if someone can explain it, that would be helpful.
>
regards,
junichi
--
dancer@{debian.org,netfort.gr.jp} Debian Project
Hi,
> Does that not work for you? It's not the full solution to all the
> issues, but I'd expect it to be enough to get you going. If it does
> not work for you, then I need to understand why not in a hurry:
> please let me know either way.
>
> I'm at last getting near with my patches, hope to post later tonight
> (but everything always takes me longer than I expect).
I am assuming that the following patch went in as a fix for this
problem. I have tested linus' tree as of today, and bttv works fine
on x86_64, problem solved.
Thanks!
commit ed5297a94090d9a9f27b0ce1f9601ebe73561cff
tree 00d28144ae949b3f9d566279cb12be0c802f86e6
parent aa1a64ee12ae130706f3fc0007841ce9b0ddf9c2
author Hugh Dickins <[email protected]>
committer Linus Torvalds <[email protected]>
[PATCH] unpaged: get_user_pages VM_RESERVED
regards,
junichi
--
dancer@{debian.org,netfort.gr.jp} Debian Project