Re: INFO: task hung in flush_workqueue

2018-11-04 Thread syzbot 

syzbot has found a reproducer for the following crash on:

HEAD commit:d2ff0ff2c23f Merge tag 'armsoc-fixes' of git://git.kernel...
git tree:   upstream
console output: https://syzkaller.appspot.com/x/log.txt?x=1128a44740
kernel config:  https://syzkaller.appspot.com/x/.config?x=9384ecb1c973baed
dashboard link: https://syzkaller.appspot.com/bug?extid=69780d144754b8071f4b
compiler:   gcc (GCC) 8.0.1 20180413 (experimental)
syz repro:  https://syzkaller.appspot.com/x/repro.syz?x=12c6758340
C reproducer:   https://syzkaller.appspot.com/x/repro.c?x=15ce682b40

IMPORTANT: if you fix the bug, please add the following tag to the commit:
Reported-by: syzbot+69780d144754b8071...@syzkaller.appspotmail.com

sshd (5562) used greatest stack depth: 15232 bytes left
INFO: task syz-executor757:5654 blocked for more than 140 seconds.
  Not tainted 4.19.0+ #96
"echo 0 > /proc/sys/kernel/hung_task_timeout_secs" disables this message.
syz-executor757 D23632  5654   5653 0x0004
Call Trace:
 context_switch kernel/sched/core.c:2831 [inline]
 __schedule+0x8cf/0x21d0 kernel/sched/core.c:3472
 schedule+0xfe/0x460 kernel/sched/core.c:3516
 schedule_timeout+0x1cc/0x260 kernel/time/timer.c:1780
 do_wait_for_common kernel/sched/completion.c:83 [inline]
 __wait_for_common kernel/sched/completion.c:104 [inline]
 wait_for_common kernel/sched/completion.c:115 [inline]
 wait_for_completion+0x427/0x8a0 kernel/sched/completion.c:136
 flush_workqueue+0x742/0x1e10 kernel/workqueue.c:2707
 flush_scheduled_work include/linux/workqueue.h:599 [inline]
 vim2m_stop_streaming+0x7c/0x2c0 drivers/media/platform/vim2m.c:811
 __vb2_queue_cancel+0x171/0xd20  
drivers/media/common/videobuf2/videobuf2-core.c:1823
 vb2_core_queue_release+0x26/0x80  
drivers/media/common/videobuf2/videobuf2-core.c:2229
 vb2_queue_release+0x15/0x20  
drivers/media/common/videobuf2/videobuf2-v4l2.c:837

 v4l2_m2m_ctx_release+0x1e/0x35 drivers/media/v4l2-core/v4l2-mem2mem.c:930
 vim2m_release+0xe6/0x150 drivers/media/platform/vim2m.c:977
 v4l2_release+0x224/0x3a0 drivers/media/v4l2-core/v4l2-dev.c:456
 __fput+0x385/0xa30 fs/file_table.c:278
 fput+0x15/0x20 fs/file_table.c:309
 task_work_run+0x1e8/0x2a0 kernel/task_work.c:113
 tracehook_notify_resume include/linux/tracehook.h:188 [inline]
 exit_to_usermode_loop+0x318/0x380 arch/x86/entry/common.c:166
 prepare_exit_to_usermode arch/x86/entry/common.c:197 [inline]
 syscall_return_slowpath arch/x86/entry/common.c:268 [inline]
 do_syscall_64+0x6be/0x820 arch/x86/entry/common.c:293
 entry_SYSCALL_64_after_hwframe+0x49/0xbe
RIP: 0033:0x401010
Code: 01 f0 ff ff 0f 83 b0 0a 00 00 c3 66 2e 0f 1f 84 00 00 00 00 00 0f 1f  
44 00 00 83 3d bd 56 2d 00 00 75 14 b8 03 00 00 00 0f 05 <48> 3d 01 f0 ff  
ff 0f 83 84 0a 00 00 c3 48 83 ec 08 e8 3a 01 00 00

RSP: 002b:7ffea5ab70f8 EFLAGS: 0246 ORIG_RAX: 0003
RAX:  RBX: 0003 RCX: 00401010
RDX: 00444bb9 RSI:  RDI: 0003
RBP:  R08: 004002e0 R09: 004002e0
R10: 004002e0 R11: 0246 R12: 00401f20
R13: 00401fb0 R14:  R15: 

Showing all locks held in the system:
2 locks held by kworker/0:1/12:
 #0: 3db4b92e ((wq_completion)"events"){+.+.}, at:  
__write_once_size include/linux/compiler.h:209 [inline]
 #0: 3db4b92e ((wq_completion)"events"){+.+.}, at:  
arch_atomic64_set arch/x86/include/asm/atomic64_64.h:34 [inline]
 #0: 3db4b92e ((wq_completion)"events"){+.+.}, at: atomic64_set  
include/asm-generic/atomic-instrumented.h:40 [inline]
 #0: 3db4b92e ((wq_completion)"events"){+.+.}, at: atomic_long_set  
include/asm-generic/atomic-long.h:59 [inline]
 #0: 3db4b92e ((wq_completion)"events"){+.+.}, at: set_work_data  
kernel/workqueue.c:617 [inline]
 #0: 3db4b92e ((wq_completion)"events"){+.+.}, at:  
set_work_pool_and_clear_pending kernel/workqueue.c:644 [inline]
 #0: 3db4b92e ((wq_completion)"events"){+.+.}, at:  
process_one_work+0xb43/0x1c40 kernel/workqueue.c:2124
 #1: 83c4fc0a ((work_completion)(&smc->tcp_listen_work)){+.+.}, at:  
process_one_work+0xb9a/0x1c40 kernel/workqueue.c:2128

1 lock held by khungtaskd/1008:
 #0: 3c4b94d4 (rcu_read_lock){}, at:  
debug_show_all_locks+0xd0/0x424 kernel/locking/lockdep.c:4379

1 lock held by rsyslogd/5534:
 #0: 41dcaab2 (&f->f_pos_lock){+.+.}, at: __fdget_pos+0x1bb/0x200  
fs/file.c:766

2 locks held by getty/5624:
 #0: 73aea0d8 (&tty->ldisc_sem){}, at:  
ldsem_down_read+0x32/0x40 drivers/tty/tty_ldsem.c:353
 #1: 4c00cd31 (&ldata->atomic_read_lock){+.+.}, at:  
n_tty_read+0x335/0x1e80 drivers/tty/n_tty.c:2154

2 locks held by getty/5625:
 #0: c279c8f4 (&tty->ldisc_sem){}, at:  
ldsem_down_read+0x32/0x40 drivers/tty/tty_ldsem.c:353
 #1: eaef601a (&ldata->atomic_read_lock){+.+.}, at:  
n_tty_read+0x335/0x1e80 drivers/tty/n_

Re: INFO: task hung in vivid_stop_generating_vid_cap

2018-10-29 Thread syzbot 

syzbot has found a reproducer for the following crash on:

HEAD commit:9f51ae62c84a Merge git://git.kernel.org/pub/scm/linux/kern..
git tree:   upstream
console output: https://syzkaller.appspot.com/x/log.txt?x=14bfad7b40
kernel config:  https://syzkaller.appspot.com/x/.config?x=62118286bb772a24
dashboard link: https://syzkaller.appspot.com/bug?extid=06283a66a648cd073885
compiler:   gcc (GCC) 8.0.1 20180413 (experimental)
syz repro:  https://syzkaller.appspot.com/x/repro.syz?x=15701a3340
C reproducer:   https://syzkaller.appspot.com/x/repro.c?x=154c8e4d40

IMPORTANT: if you fix the bug, please add the following tag to the commit:
Reported-by: syzbot+06283a66a648cd073...@syzkaller.appspotmail.com

INFO: task syz-executor686:5724 blocked for more than 140 seconds.
  Not tainted 4.19.0+ #309
"echo 0 > /proc/sys/kernel/hung_task_timeout_secs" disables this message.
syz-executor686 D24208  5724   5716 0x0004
Call Trace:
 context_switch kernel/sched/core.c:2831 [inline]
 __schedule+0x8cf/0x21d0 kernel/sched/core.c:3480
 schedule+0xfe/0x460 kernel/sched/core.c:3524
 schedule_timeout+0x1cc/0x260 kernel/time/timer.c:1780
 do_wait_for_common kernel/sched/completion.c:83 [inline]
 __wait_for_common kernel/sched/completion.c:104 [inline]
 wait_for_common kernel/sched/completion.c:115 [inline]
 wait_for_completion+0x427/0x8a0 kernel/sched/completion.c:136
 kthread_stop+0x1a9/0x900 kernel/kthread.c:550
 vivid_stop_generating_vid_cap+0x2bc/0x93b  
drivers/media/platform/vivid/vivid-kthread-cap.c:919
 vid_cap_stop_streaming+0x8d/0xe0  
drivers/media/platform/vivid/vivid-vid-cap.c:256
 __vb2_queue_cancel+0x171/0xca0  
drivers/media/common/videobuf2/videobuf2-core.c:1659
 vb2_core_streamoff+0x60/0x140  
drivers/media/common/videobuf2/videobuf2-core.c:1795
 __vb2_cleanup_fileio+0x73/0x160  
drivers/media/common/videobuf2/videobuf2-core.c:2316
 vb2_core_queue_release+0x1e/0x80  
drivers/media/common/videobuf2/videobuf2-core.c:2043
 vb2_queue_release drivers/media/common/videobuf2/videobuf2-v4l2.c:672  
[inline]
 _vb2_fop_release+0x1d2/0x2b0  
drivers/media/common/videobuf2/videobuf2-v4l2.c:843
 vb2_fop_release+0x77/0xc0  
drivers/media/common/videobuf2/videobuf2-v4l2.c:857

 vivid_fop_release+0x18e/0x440 drivers/media/platform/vivid/vivid-core.c:474
 v4l2_release+0xfb/0x1a0 drivers/media/v4l2-core/v4l2-dev.c:448
 __fput+0x385/0xa30 fs/file_table.c:278
 fput+0x15/0x20 fs/file_table.c:309
 task_work_run+0x1e8/0x2a0 kernel/task_work.c:113
 tracehook_notify_resume include/linux/tracehook.h:188 [inline]
 exit_to_usermode_loop+0x318/0x380 arch/x86/entry/common.c:166
 prepare_exit_to_usermode arch/x86/entry/common.c:197 [inline]
 syscall_return_slowpath arch/x86/entry/common.c:268 [inline]
 do_syscall_64+0x6be/0x820 arch/x86/entry/common.c:293
 entry_SYSCALL_64_after_hwframe+0x49/0xbe
RIP: 0033:0x400f00
Code: 00 00 00 00 00 00 00 00 00 00 d6 01 00 00 12 00 00 00 00 00 00 00 00  
00 00 00 00 00 00 00 00 00 00 00 00 03 00 00 12 00 00 00 <00> 00 00 00 00  
00 00 00 00 00 00 00 00 00 00 00 b8 02 00 00 12 00

RSP: 002b:7ffc53169f28 EFLAGS: 0246 ORIG_RAX: 0003
RAX:  RBX: 0003 RCX: 00400f00
RDX: 00d6 RSI: 2140 RDI: 0003
RBP:  R08: 024b1880 R09: 004002e0
R10:  R11: 0246 R12: 00401e10
R13: 00401ea0 R14:  R15: 
INFO: task syz-executor686:5730 blocked for more than 140 seconds.
  Not tainted 4.19.0+ #309
"echo 0 > /proc/sys/kernel/hung_task_timeout_secs" disables this message.
syz-executor686 D24208  5730   5721 0x0004
Call Trace:
 context_switch kernel/sched/core.c:2831 [inline]
 __schedule+0x8cf/0x21d0 kernel/sched/core.c:3480
 schedule+0xfe/0x460 kernel/sched/core.c:3524
 schedule_timeout+0x1cc/0x260 kernel/time/timer.c:1780
 do_wait_for_common kernel/sched/completion.c:83 [inline]
 __wait_for_common kernel/sched/completion.c:104 [inline]
 wait_for_common kernel/sched/completion.c:115 [inline]
 wait_for_completion+0x427/0x8a0 kernel/sched/completion.c:136
 kthread_stop+0x1a9/0x900 kernel/kthread.c:550
 vivid_stop_generating_vid_cap+0x2bc/0x93b  
drivers/media/platform/vivid/vivid-kthread-cap.c:919
 vid_cap_stop_streaming+0x8d/0xe0  
drivers/media/platform/vivid/vivid-vid-cap.c:256
 __vb2_queue_cancel+0x171/0xca0  
drivers/media/common/videobuf2/videobuf2-core.c:1659
 vb2_core_streamoff+0x60/0x140  
drivers/media/common/videobuf2/videobuf2-core.c:1795
 __vb2_cleanup_fileio+0x73/0x160  
drivers/media/common/videobuf2/videobuf2-core.c:2316
 vb2_core_queue_release+0x1e/0x80  
drivers/media/common/videobuf2/videobuf2-core.c:2043
 vb2_queue_release drivers/media/common/videobuf2/videobuf2-v4l2.c:672  
[inline]
 _vb2_fop_release+0x1d2/0x2b0  
drivers/media/common/videobuf2/videobuf2-v4l2.c:843
 vb2_fop_release+0x77/0xc0  
drivers/media/common/videobuf2/videobuf2-v4l2.c:857

 vivid_fop_release+0x18e/0x44

Re: Info on Remote controller keys like upper-right, upper-left , lower-right, lower-left ,sub-picture etc.

2012-07-04 Thread Antti Palosaari 

On 07/04/2012 09:34 PM, Dharam Kumar wrote:

Hi All,

I've been working on a MHL( www.mhltech.org  ) transmitter driver
which needs to receive/handle incoming Remote control keys.

The specification tells me that other than normal keys[up,down,left,
right etc.] there are certain remote control keys like Upper-right,
Upper-left, Lower-right, Lower-left, Sub-picture etc.

While creating a key map in the driver, I tried to find whether these
keys has been defined in  ,but I could not find such
key definitions
in the header file.

Please note that, although the Specs do define these Remote Controller
keys, the driver will have the choice
to support the key depending on the key-map.

Something like this:
/* Key Map for the driver */
   
  { KEY_UP,  },
  { KEY_DOWN, },
  {KEY_UPPERRIGHT, },  /* No  definition for
KEY_UPPERRIGHT in input.h  */
  {KEY_UPPERLEFT, },  /* No definition for KEY_UPPERLEFT
in input.h, although this key is not supported by driver */



In other mailing lists[linux-input], it has been suggested that these
keys are similar to Joystick keys.
I've looked into drivers/input/joystick/analog.c file, but could not
find any buttons/pads which are similar to the above one[Am I missing
something here??]

any pointers??


Here is list of key bindings used for media device remote controllers 
(television, radio, etc):

http://linuxtv.org/wiki/index.php/Remote_Controllers

But still no definitions like up-left etc.

regards
Antti


--
http://palosaari.fi/


--
To unsubscribe from this list: send the line "unsubscribe linux-media" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: Info

2010-04-14 Thread Adriano Gigante 

Hi Devin,

...do you think we will have our stick (0072/terratec hybrid xs fm) 
working before FIFA World Cup?



Thanks
Adriano


Il 14/02/2010 18:33, Florent NOUVELLON ha scritto:

Hi Devin,

Did you with Prahal advanced the 0072/terratec hybrid xs fm support in
linux-dvb driver ?

If you need any kind of help (testing, or whatever) feel free to ask me.

Regards,
Florent


2010/1/18 Markus Rechberger mailto:mrechber...@gmail.com>>

On Mon, Jan 18, 2010 at 7:50 PM, fogna mailto:fogn...@gmail.com>> wrote:
 > Il 01/18/2010 06:33 PM, Markus Rechberger ha scritto:
 >> On Mon, Jan 18, 2010 at 5:36 PM, Devin Heitmueller
 >> mailto:dheitmuel...@kernellabs.com>> wrote:
 >>
 >>> Hello Markus,
 >>>
 >>> On Mon, Jan 18, 2010 at 11:29 AM, Markus Rechberger
 >>> mailto:mrechber...@gmail.com>> wrote:
 >>>
  Just fyi there's a hardware bug with the 0072/terratec hybrid
xs fm
  (cx25843 - xc5000):
 
  http://img91.imageshack.us/i/0004qf8.png/
  http://img104.imageshack.us/i/0009cp4.png/
 
  nothing that can be fixed with the driver.
 
 >>> Interesting.  If it cannot be fixed with the driver, how does the
 >>> Windows driver work then?  Is this some sort of premature hardware
 >>> failure that occurs (after which point it is irreversible)?
 >>>
 >>>
 >> conexant cx25843 - xceive xc5000 failure (as what I've heard
conexant
 >> laid off people in that area years ago while xceive (see their
driver
 >> changelog if you have access to it) tried to fix it with their
 >> firmware but didn't succeed), it also happens with windows. Those
 >> screenshots are taken from a videoclip
 >> it was of course a big problem for business customers (almost all of
 >> them happily switched away from it)
 >> This is the same retail hardware as everyone else uses out there. XS
 >> FM is not being sold anymore.
 >> I only know one company in Ireland still


ing with it, also in

 >> terms of videoquality I'd avoid that combination.
 >>
 >> Markus
 >>
 >>
 >>> Thanks for taking the time to point this out though, since I could
 >>> totally imagine banging my head against the wall for quite a while
 >>> once I saw this.
 >>>
 >>> Devin
 >>>
 >>> --
 >>> Devin J. Heitmueller - Kernel Labs
 >>> http://www.kernellabs.com
 >>>
 >>>
 >> --
 >> To unsubscribe from this list: send the line "unsubscribe
linux-media" in
 >> the body of a message to majord...@vger.kernel.org

 >> More majordomo info at http://vger.kernel.org/majordomo-info.html
 >>
 >>
 > Hi Markus, thanks for the info, i didn't know of this hardware
problem,
 > i have this usb stick and at the moment all works normally, now i
know
 > when it will be time to replace it :)
 >

it happens sporadically sometimes 1 time/5 minutes sometimes 1
time/10 minutes.
I think in windows it sometimes drops frames it also happens there and
can be seen with VLC
maybe some codecs also compensate it a little bit. There's no generic
rule about this the xc5000
overdrives the videodecoder (it's not empia related issue actually
moreover conexant/xceive)

Markus
--
To unsubscribe from this list: send the line "unsubscribe
linux-media" in
the body of a message to majord...@vger.kernel.org

More majordomo info at http://vger.kernel.org/majordomo-info.html




--
To unsubscribe from this list: send the line "unsubscribe linux-media" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: Info

2010-03-01 Thread Adriano Gigante 

Devin,
can you ask Prahal to keep this mailing list updated with the progress 
of develop?

People from the list could help him in any need.
Thank you.
Adri


On 02/14/2010 06:33 PM, Florent NOUVELLON wrote:
> > Hi Devin,
> >
> > Did you with Prahal advanced the 0072/terratec hybrid xs fm support in
> > linux-dvb driver ?
> >
> > If you need any kind of help (testing, or whatever) feel free to 
ask me.

> >
> > Regards,
> > Florent
> >
--
To unsubscribe from this list: send the line "unsubscribe linux-media" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: Info

2010-02-14 Thread Devin Heitmueller 
On Sun, Feb 14, 2010 at 12:33 PM, Florent NOUVELLON
 wrote:
> Hi Devin,
>
> Did you with Prahal advanced the 0072/terratec hybrid xs fm support in
> linux-dvb driver ?
>
> If you need any kind of help (testing, or whatever) feel free to ask me.
>
> Regards,
> Florent

Hi Florent,

Prahal was making good progress, and I was helping him over irc when I
had time.  But I have not invested any of my own time working on the
driver at this point (as I've been tied up working on other projects).

Devin

-- 
Devin J. Heitmueller - Kernel Labs
http://www.kernellabs.com
--
To unsubscribe from this list: send the line "unsubscribe linux-media" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: Info

2010-01-18 Thread Markus Rechberger 
On Mon, Jan 18, 2010 at 7:50 PM, fogna  wrote:
> Il 01/18/2010 06:33 PM, Markus Rechberger ha scritto:
>> On Mon, Jan 18, 2010 at 5:36 PM, Devin Heitmueller
>>  wrote:
>>
>>> Hello Markus,
>>>
>>> On Mon, Jan 18, 2010 at 11:29 AM, Markus Rechberger
>>>  wrote:
>>>
 Just fyi there's a hardware bug with the 0072/terratec hybrid xs fm
 (cx25843 - xc5000):

 http://img91.imageshack.us/i/0004qf8.png/
 http://img104.imageshack.us/i/0009cp4.png/

 nothing that can be fixed with the driver.

>>> Interesting.  If it cannot be fixed with the driver, how does the
>>> Windows driver work then?  Is this some sort of premature hardware
>>> failure that occurs (after which point it is irreversible)?
>>>
>>>
>> conexant cx25843 - xceive xc5000 failure (as what I've heard conexant
>> laid off people in that area years ago while xceive (see their driver
>> changelog if you have access to it) tried to fix it with their
>> firmware but didn't succeed), it also happens with windows. Those
>> screenshots are taken from a videoclip
>> it was of course a big problem for business customers (almost all of
>> them happily switched away from it)
>> This is the same retail hardware as everyone else uses out there. XS
>> FM is not being sold anymore.
>> I only know one company in Ireland still sticking with it, also in
>> terms of videoquality I'd avoid that combination.
>>
>> Markus
>>
>>
>>> Thanks for taking the time to point this out though, since I could
>>> totally imagine banging my head against the wall for quite a while
>>> once I saw this.
>>>
>>> Devin
>>>
>>> --
>>> Devin J. Heitmueller - Kernel Labs
>>> http://www.kernellabs.com
>>>
>>>
>> --
>> To unsubscribe from this list: send the line "unsubscribe linux-media" in
>> the body of a message to majord...@vger.kernel.org
>> More majordomo info at  http://vger.kernel.org/majordomo-info.html
>>
>>
> Hi Markus, thanks for the info, i didn't know of this hardware problem,
> i have this usb stick and at the moment all works normally, now i know
> when it will be time to replace it :)
>

it happens sporadically sometimes 1 time/5 minutes sometimes 1 time/10 minutes.
I think in windows it sometimes drops frames it also happens there and
can be seen with VLC
maybe some codecs also compensate it a little bit. There's no generic
rule about this the xc5000
overdrives the videodecoder (it's not empia related issue actually
moreover conexant/xceive)

Markus
--
To unsubscribe from this list: send the line "unsubscribe linux-media" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: Info

2010-01-18 Thread fogna 
Il 01/18/2010 06:33 PM, Markus Rechberger ha scritto:
> On Mon, Jan 18, 2010 at 5:36 PM, Devin Heitmueller
>  wrote:
>   
>> Hello Markus,
>>
>> On Mon, Jan 18, 2010 at 11:29 AM, Markus Rechberger
>>  wrote:
>> 
>>> Just fyi there's a hardware bug with the 0072/terratec hybrid xs fm
>>> (cx25843 - xc5000):
>>>
>>> http://img91.imageshack.us/i/0004qf8.png/
>>> http://img104.imageshack.us/i/0009cp4.png/
>>>
>>> nothing that can be fixed with the driver.
>>>   
>> Interesting.  If it cannot be fixed with the driver, how does the
>> Windows driver work then?  Is this some sort of premature hardware
>> failure that occurs (after which point it is irreversible)?
>>
>> 
> conexant cx25843 - xceive xc5000 failure (as what I've heard conexant
> laid off people in that area years ago while xceive (see their driver
> changelog if you have access to it) tried to fix it with their
> firmware but didn't succeed), it also happens with windows. Those
> screenshots are taken from a videoclip
> it was of course a big problem for business customers (almost all of
> them happily switched away from it)
> This is the same retail hardware as everyone else uses out there. XS
> FM is not being sold anymore.
> I only know one company in Ireland still sticking with it, also in
> terms of videoquality I'd avoid that combination.
>
> Markus
>
>   
>> Thanks for taking the time to point this out though, since I could
>> totally imagine banging my head against the wall for quite a while
>> once I saw this.
>>
>> Devin
>>
>> --
>> Devin J. Heitmueller - Kernel Labs
>> http://www.kernellabs.com
>>
>> 
> --
> To unsubscribe from this list: send the line "unsubscribe linux-media" in
> the body of a message to majord...@vger.kernel.org
> More majordomo info at  http://vger.kernel.org/majordomo-info.html
>
>   
Hi Markus, thanks for the info, i didn't know of this hardware problem,
i have this usb stick and at the moment all works normally, now i know
when it will be time to replace it :)
--
To unsubscribe from this list: send the line "unsubscribe linux-media" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: Info

2010-01-18 Thread Markus Rechberger 
On Mon, Jan 18, 2010 at 5:36 PM, Devin Heitmueller
 wrote:
> Hello Markus,
>
> On Mon, Jan 18, 2010 at 11:29 AM, Markus Rechberger
>  wrote:
>> Just fyi there's a hardware bug with the 0072/terratec hybrid xs fm
>> (cx25843 - xc5000):
>>
>> http://img91.imageshack.us/i/0004qf8.png/
>> http://img104.imageshack.us/i/0009cp4.png/
>>
>> nothing that can be fixed with the driver.
>
> Interesting.  If it cannot be fixed with the driver, how does the
> Windows driver work then?  Is this some sort of premature hardware
> failure that occurs (after which point it is irreversible)?
>

conexant cx25843 - xceive xc5000 failure (as what I've heard conexant
laid off people in that area years ago while xceive (see their driver
changelog if you have access to it) tried to fix it with their
firmware but didn't succeed), it also happens with windows. Those
screenshots are taken from a videoclip
it was of course a big problem for business customers (almost all of
them happily switched away from it)
This is the same retail hardware as everyone else uses out there. XS
FM is not being sold anymore.
I only know one company in Ireland still sticking with it, also in
terms of videoquality I'd avoid that combination.

Markus

> Thanks for taking the time to point this out though, since I could
> totally imagine banging my head against the wall for quite a while
> once I saw this.
>
> Devin
>
> --
> Devin J. Heitmueller - Kernel Labs
> http://www.kernellabs.com
>
--
To unsubscribe from this list: send the line "unsubscribe linux-media" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: Info

2010-01-18 Thread Devin Heitmueller 
Hello Markus,

On Mon, Jan 18, 2010 at 11:29 AM, Markus Rechberger
 wrote:
> Just fyi there's a hardware bug with the 0072/terratec hybrid xs fm
> (cx25843 - xc5000):
>
> http://img91.imageshack.us/i/0004qf8.png/
> http://img104.imageshack.us/i/0009cp4.png/
>
> nothing that can be fixed with the driver.

Interesting.  If it cannot be fixed with the driver, how does the
Windows driver work then?  Is this some sort of premature hardware
failure that occurs (after which point it is irreversible)?

Thanks for taking the time to point this out though, since I could
totally imagine banging my head against the wall for quite a while
once I saw this.

Devin

-- 
Devin J. Heitmueller - Kernel Labs
http://www.kernellabs.com
--
To unsubscribe from this list: send the line "unsubscribe linux-media" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: Info

2010-01-18 Thread Markus Rechberger 
On Mon, Jan 18, 2010 at 5:17 PM, Devin Heitmueller
 wrote:
> On Mon, Jan 18, 2010 at 11:03 AM, Adriano Gigante  wrote:
>> Hi Devin,
>>>
>>> The 0ccd:0043 is on my todo list of devices to work on (they sent me a
>>> sample board), although it's not the highest priority on my list given
>>> how old it is.
>>>
>>
>> Did they sent you also a 0ccd:0072 card (Terratec Cinergy Hybrid T USB XS
>> FM)?
>> Adri
>
> Terratec sent me two boards:  0ccd:0072 and 0ccd:0043.  I've actually
> been working with a user on the #linuxtv irc channel who is in the
> process of getting the 0ccd:0072 board to work (username Prahal).
> He's making great progress, but if he gets stuck I will find some
> cycles to work through whatever problem he finds.
>

Just fyi there's a hardware bug with the 0072/terratec hybrid xs fm
(cx25843 - xc5000):

http://img91.imageshack.us/i/0004qf8.png/
http://img104.imageshack.us/i/0009cp4.png/

nothing that can be fixed with the driver.

Markus
--
To unsubscribe from this list: send the line "unsubscribe linux-media" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: Info

2010-01-18 Thread Devin Heitmueller 
On Mon, Jan 18, 2010 at 11:03 AM, Adriano Gigante  wrote:
> Hi Devin,
>>
>> The 0ccd:0043 is on my todo list of devices to work on (they sent me a
>> sample board), although it's not the highest priority on my list given
>> how old it is.
>>
>
> Did they sent you also a 0ccd:0072 card (Terratec Cinergy Hybrid T USB XS
> FM)?
> Adri

Terratec sent me two boards:  0ccd:0072 and 0ccd:0043.  I've actually
been working with a user on the #linuxtv irc channel who is in the
process of getting the 0ccd:0072 board to work (username Prahal).
He's making great progress, but if he gets stuck I will find some
cycles to work through whatever problem he finds.

Cheers,

Devin

-- 
Devin J. Heitmueller - Kernel Labs
http://www.kernellabs.com
--
To unsubscribe from this list: send the line "unsubscribe linux-media" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html