em28xx driver crashes device

em28xx driver crashes device

[Markus Rechberger]

Hey,

[24004.018614] EEPROM ID= 0x9567eb1a, hash = 0x1067368a
[24004.018618] Vendor/Product ID= eb1a:2861
[24004.018622] AC97 audio (5 sample rates)
[24004.018626] 500mA max power
[24004.018629] Table at 0x04, strings=0x206a, 0x0000, 0x0000
[24004.049201]  failed!
[24004.049210] em28xx #0: reading from i2c device failed (error=-71)
[24004.049444]  failed!
[24004.049451] em28xx #0: reading from i2c device failed (error=-71)
[24004.049655]  failed!
[24004.049659] em28xx #0: reading from i2c device failed (error=-71)
[24004.049891]  failed!
[24004.049895] em28xx #0: reading from i2c device failed (error=-71)
[24004.050141]  failed!
[24004.050145] em28xx #0: reading from i2c device failed (error=-71)
[24004.050393]  failed!
[24004.050396] em28xx #0: reading from i2c device failed (error=-71)
[24004.050641]  failed!
[24004.050644] em28xx #0: reading from i2c device failed (error=-71)
[24004.050890]  failed!
[24004.050894] em28xx #0: reading from i2c device failed (error=-71)
[24004.051141]  failed!
[24004.051145] em28xx #0: reading from i2c device failed (error=-71)
[24004.051392]  failed!
[24004.051395] em28xx #0: reading from i2c device failed (error=-71)
[24004.051641]  failed!
[24004.051645] em28xx #0: reading from i2c device failed (error=-71)
[24004.051892]  failed!
[24004.051895] em28xx #0: reading from i2c device failed (error=-71)
[24004.052140]  failed!
[24004.052143] em28xx #0: reading from i2c device failed (error=-71)
[24004.052393]  failed!
[24004.052396] em28xx #0: reading from i2c device failed (error=-71)
[24004.052642]  failed!
[24004.052645] em28xx #0: reading from i2c device failed (error=-71)
[24004.052892]  failed!
[24004.052895] em28xx #0: reading from i2c device failed (error=-71)
[24004.057741]  failed!
[24004.057746] em28xx #0: reading from i2c device failed (error=-71)
[24004.057880]  failed!
[24004.057884] em28xx #0: reading from i2c device failed (error=-71)
[24004.058125]  failed!
[24004.058129] em28xx #0: reading from i2c device failed (error=-71)
[24004.058379]  failed!
[24004.058383] em28xx #0: reading from i2c device failed (error=-71)
[24004.058628]  failed!
[24004.058633] em28xx #0: reading from i2c device failed (error=-71)
[24004.058880]  failed!
[24004.058883] em28xx #0: reading from i2c device failed (error=-71)
[24004.059128]  failed!
[24004.059131] em28xx #0: reading from i2c device failed (error=-71)
[24004.059380]  failed!
[24004.059383] em28xx #0: reading from i2c device failed (error=-71)
[24004.059636]  failed!
[24004.059640] em28xx #0: reading from i2c device failed (error=-71)
[24004.059914]  failed!
[24004.059917] em28xx #0: reading from i2c device failed (error=-71)
[24004.060140]  failed!
[24004.060145] em28xx #0: reading from i2c device failed (error=-71)
[24004.060388]  failed!
[24004.060392] em28xx #0: reading from i2c device failed (error=-71)
[24004.060636]  failed!
[24004.060640] em28xx #0: reading from i2c device failed (error=-71)
[24004.060884]  failed!
[24004.060887] em28xx #0: reading from i2c device failed (error=-71)
[24004.061126]  failed!
[24004.061132] em28xx #0: reading from i2c device failed (error=-71)
[24004.062214]  failed!
[24004.062219] em28xx #0: reading from i2c device failed (error=-71)
[24004.062378]  failed!
[24004.062383] em28xx #0: reading from i2c device failed (error=-71)
[24004.062632]  failed!
[24004.062636] em28xx #0: reading from i2c device failed (error=-71)
[24004.062884]  failed!
[24004.062889] em28xx #0: reading from i2c device failed (error=-71)
[24004.063126]  failed!
[24004.063131] em28xx #0: reading from i2c device failed (error=-71)
[24004.063375]  failed!
[24004.063380] em28xx #0: reading from i2c device failed (error=-71)
[24004.063626]  failed!
[24004.063631] em28xx #0: reading from i2c device failed (error=-71)
[24004.063875]  failed!
[24004.063880] em28xx #0: reading from i2c device failed (error=-71)
[24004.064127]  failed!
[24004.064132] em28xx #0: reading from i2c device failed (error=-71)
[24004.064376]  failed!
[24004.064380] em28xx #0: reading from i2c device failed (error=-71)
[24004.064625]  failed!
[24004.064630] em28xx #0: reading from i2c device failed (error=-71)
[24004.064876]  failed!
[24004.064881] em28xx #0: reading from i2c device failed (error=-71)
[24004.065126]  failed!
[24004.065130] em28xx #0: reading from i2c device failed (error=-71)
[24004.065376]  failed!
[24004.065381] em28xx #0: reading from i2c device failed (error=-71)
[24004.065626]  failed!
[24004.065632] em28xx #0: reading from i2c device failed (error=-71)
[24004.065875]  failed!
[24004.065880] em28xx #0: reading from i2c device failed (error=-71)
[24004.066126]  failed!
[24004.066131] em28xx #0: reading from i2c device failed (error=-71)
[24004.066376]  failed!
[24004.066381] em28xx #0: reading from i2c device failed (error=-71)
[24004.066625]  failed!
[24004.066629] em28xx #0: reading from i2c device failed (error=-71)
[24004.066875]  failed!
[24004.066880] em28xx #0: reading from i2c device failed (error=-71)
[24004.066890] em28xx #0: Your board has no unique USB ID and thus
need a hint to be detected.
[24004.066900] em28xx #0: You may try to use card=<n> insmod option to
workaround that.
[24004.066908] em28xx #0: Please send an email with this log to:
[24004.066916] em28xx #0: 	V4L Mailing List <video4linux-list@redhat.com>
[24004.066924] em28xx #0: Board eeprom hash is 0x1067368a


can someone just check for errors if one error occures stop it?
We're facing that this driver crashes entire devices.

regards,
Markus

Re: em28xx driver crashes device

[Devin Heitmueller]

On Thu, Jul 23, 2009 at 5:40 AM, Markus Rechberger<mrechberger@gmail.com> wrote:
> Hey,
>
> [24004.018614] EEPROM ID= 0x9567eb1a, hash = 0x1067368a
> [24004.018618] Vendor/Product ID= eb1a:2861
> [24004.018622] AC97 audio (5 sample rates)
> [24004.018626] 500mA max power
> [24004.018629] Table at 0x04, strings=0x206a, 0x0000, 0x0000
> [24004.049201]  failed!
> [24004.049210] em28xx #0: reading from i2c device failed (error=-71)
> [24004.049444]  failed!
> [24004.049451] em28xx #0: reading from i2c device failed (error=-71)
> [24004.049655]  failed!
> [24004.049659] em28xx #0: reading from i2c device failed (error=-71)
> [24004.049891]  failed!
> [24004.049895] em28xx #0: reading from i2c device failed (error=-71)
> [24004.050141]  failed!
> [24004.050145] em28xx #0: reading from i2c device failed (error=-71)
> [24004.050393]  failed!
> [24004.050396] em28xx #0: reading from i2c device failed (error=-71)
> [24004.050641]  failed!
> [24004.050644] em28xx #0: reading from i2c device failed (error=-71)
> [24004.050890]  failed!
> [24004.050894] em28xx #0: reading from i2c device failed (error=-71)
> [24004.051141]  failed!
> [24004.051145] em28xx #0: reading from i2c device failed (error=-71)
> [24004.051392]  failed!
> [24004.051395] em28xx #0: reading from i2c device failed (error=-71)
> [24004.051641]  failed!
> [24004.051645] em28xx #0: reading from i2c device failed (error=-71)
> [24004.051892]  failed!
> [24004.051895] em28xx #0: reading from i2c device failed (error=-71)
> [24004.052140]  failed!
> [24004.052143] em28xx #0: reading from i2c device failed (error=-71)
> [24004.052393]  failed!
> [24004.052396] em28xx #0: reading from i2c device failed (error=-71)
> [24004.052642]  failed!
> [24004.052645] em28xx #0: reading from i2c device failed (error=-71)
> [24004.052892]  failed!
> [24004.052895] em28xx #0: reading from i2c device failed (error=-71)
> [24004.057741]  failed!
> [24004.057746] em28xx #0: reading from i2c device failed (error=-71)
> [24004.057880]  failed!
> [24004.057884] em28xx #0: reading from i2c device failed (error=-71)
> [24004.058125]  failed!
> [24004.058129] em28xx #0: reading from i2c device failed (error=-71)
> [24004.058379]  failed!
> [24004.058383] em28xx #0: reading from i2c device failed (error=-71)
> [24004.058628]  failed!
> [24004.058633] em28xx #0: reading from i2c device failed (error=-71)
> [24004.058880]  failed!
> [24004.058883] em28xx #0: reading from i2c device failed (error=-71)
> [24004.059128]  failed!
> [24004.059131] em28xx #0: reading from i2c device failed (error=-71)
> [24004.059380]  failed!
> [24004.059383] em28xx #0: reading from i2c device failed (error=-71)
> [24004.059636]  failed!
> [24004.059640] em28xx #0: reading from i2c device failed (error=-71)
> [24004.059914]  failed!
> [24004.059917] em28xx #0: reading from i2c device failed (error=-71)
> [24004.060140]  failed!
> [24004.060145] em28xx #0: reading from i2c device failed (error=-71)
> [24004.060388]  failed!
> [24004.060392] em28xx #0: reading from i2c device failed (error=-71)
> [24004.060636]  failed!
> [24004.060640] em28xx #0: reading from i2c device failed (error=-71)
> [24004.060884]  failed!
> [24004.060887] em28xx #0: reading from i2c device failed (error=-71)
> [24004.061126]  failed!
> [24004.061132] em28xx #0: reading from i2c device failed (error=-71)
> [24004.062214]  failed!
> [24004.062219] em28xx #0: reading from i2c device failed (error=-71)
> [24004.062378]  failed!
> [24004.062383] em28xx #0: reading from i2c device failed (error=-71)
> [24004.062632]  failed!
> [24004.062636] em28xx #0: reading from i2c device failed (error=-71)
> [24004.062884]  failed!
> [24004.062889] em28xx #0: reading from i2c device failed (error=-71)
> [24004.063126]  failed!
> [24004.063131] em28xx #0: reading from i2c device failed (error=-71)
> [24004.063375]  failed!
> [24004.063380] em28xx #0: reading from i2c device failed (error=-71)
> [24004.063626]  failed!
> [24004.063631] em28xx #0: reading from i2c device failed (error=-71)
> [24004.063875]  failed!
> [24004.063880] em28xx #0: reading from i2c device failed (error=-71)
> [24004.064127]  failed!
> [24004.064132] em28xx #0: reading from i2c device failed (error=-71)
> [24004.064376]  failed!
> [24004.064380] em28xx #0: reading from i2c device failed (error=-71)
> [24004.064625]  failed!
> [24004.064630] em28xx #0: reading from i2c device failed (error=-71)
> [24004.064876]  failed!
> [24004.064881] em28xx #0: reading from i2c device failed (error=-71)
> [24004.065126]  failed!
> [24004.065130] em28xx #0: reading from i2c device failed (error=-71)
> [24004.065376]  failed!
> [24004.065381] em28xx #0: reading from i2c device failed (error=-71)
> [24004.065626]  failed!
> [24004.065632] em28xx #0: reading from i2c device failed (error=-71)
> [24004.065875]  failed!
> [24004.065880] em28xx #0: reading from i2c device failed (error=-71)
> [24004.066126]  failed!
> [24004.066131] em28xx #0: reading from i2c device failed (error=-71)
> [24004.066376]  failed!
> [24004.066381] em28xx #0: reading from i2c device failed (error=-71)
> [24004.066625]  failed!
> [24004.066629] em28xx #0: reading from i2c device failed (error=-71)
> [24004.066875]  failed!
> [24004.066880] em28xx #0: reading from i2c device failed (error=-71)
> [24004.066890] em28xx #0: Your board has no unique USB ID and thus
> need a hint to be detected.
> [24004.066900] em28xx #0: You may try to use card=<n> insmod option to
> workaround that.
> [24004.066908] em28xx #0: Please send an email with this log to:
> [24004.066916] em28xx #0:       V4L Mailing List <video4linux-list@redhat.com>
> [24004.066924] em28xx #0: Board eeprom hash is 0x1067368a
>
>
> can someone just check for errors if one error occures stop it?
> We're facing that this driver crashes entire devices.
>
> regards,
> Markus
> --
> To unsubscribe from this list: send the line "unsubscribe linux-media" in
> the body of a message to majordomo@vger.kernel.org
> More majordomo info at  http://vger.kernel.org/majordomo-info.html
>

Hey Markus,

Could you stick a dump_stack() line in there so we can see where it is
stuck in the loop?

Thanks,

Devin

-- 
Devin J. Heitmueller - Kernel Labs
http://www.kernellabs.com

Re: em28xx driver crashes device

[Markus Rechberger]

On Thu, Jul 23, 2009 at 1:41 PM, Devin
Heitmueller<dheitmueller@kernellabs.com> wrote:
> On Thu, Jul 23, 2009 at 5:40 AM, Markus Rechberger<mrechberger@gmail.com> wrote:
>> Hey,
>>
>> [24004.018614] EEPROM ID= 0x9567eb1a, hash = 0x1067368a
>> [24004.018618] Vendor/Product ID= eb1a:2861
>> [24004.018622] AC97 audio (5 sample rates)
>> [24004.018626] 500mA max power
>> [24004.018629] Table at 0x04, strings=0x206a, 0x0000, 0x0000
>> [24004.049201]  failed!
>> [24004.049210] em28xx #0: reading from i2c device failed (error=-71)
>> [24004.049444]  failed!
>> [24004.049451] em28xx #0: reading from i2c device failed (error=-71)
>> [24004.049655]  failed!
>> [24004.049659] em28xx #0: reading from i2c device failed (error=-71)
>> [24004.049891]  failed!
>> [24004.049895] em28xx #0: reading from i2c device failed (error=-71)
>> [24004.050141]  failed!
>> [24004.050145] em28xx #0: reading from i2c device failed (error=-71)
>> [24004.050393]  failed!
>> [24004.050396] em28xx #0: reading from i2c device failed (error=-71)
>> [24004.050641]  failed!
>> [24004.050644] em28xx #0: reading from i2c device failed (error=-71)
>> [24004.050890]  failed!
>> [24004.050894] em28xx #0: reading from i2c device failed (error=-71)
>> [24004.051141]  failed!
>> [24004.051145] em28xx #0: reading from i2c device failed (error=-71)
>> [24004.051392]  failed!
>> [24004.051395] em28xx #0: reading from i2c device failed (error=-71)
>> [24004.051641]  failed!
>> [24004.051645] em28xx #0: reading from i2c device failed (error=-71)
>> [24004.051892]  failed!
>> [24004.051895] em28xx #0: reading from i2c device failed (error=-71)
>> [24004.052140]  failed!
>> [24004.052143] em28xx #0: reading from i2c device failed (error=-71)
>> [24004.052393]  failed!
>> [24004.052396] em28xx #0: reading from i2c device failed (error=-71)
>> [24004.052642]  failed!
>> [24004.052645] em28xx #0: reading from i2c device failed (error=-71)
>> [24004.052892]  failed!
>> [24004.052895] em28xx #0: reading from i2c device failed (error=-71)
>> [24004.057741]  failed!
>> [24004.057746] em28xx #0: reading from i2c device failed (error=-71)
>> [24004.057880]  failed!
>> [24004.057884] em28xx #0: reading from i2c device failed (error=-71)
>> [24004.058125]  failed!
>> [24004.058129] em28xx #0: reading from i2c device failed (error=-71)
>> [24004.058379]  failed!
>> [24004.058383] em28xx #0: reading from i2c device failed (error=-71)
>> [24004.058628]  failed!
>> [24004.058633] em28xx #0: reading from i2c device failed (error=-71)
>> [24004.058880]  failed!
>> [24004.058883] em28xx #0: reading from i2c device failed (error=-71)
>> [24004.059128]  failed!
>> [24004.059131] em28xx #0: reading from i2c device failed (error=-71)
>> [24004.059380]  failed!
>> [24004.059383] em28xx #0: reading from i2c device failed (error=-71)
>> [24004.059636]  failed!
>> [24004.059640] em28xx #0: reading from i2c device failed (error=-71)
>> [24004.059914]  failed!
>> [24004.059917] em28xx #0: reading from i2c device failed (error=-71)
>> [24004.060140]  failed!
>> [24004.060145] em28xx #0: reading from i2c device failed (error=-71)
>> [24004.060388]  failed!
>> [24004.060392] em28xx #0: reading from i2c device failed (error=-71)
>> [24004.060636]  failed!
>> [24004.060640] em28xx #0: reading from i2c device failed (error=-71)
>> [24004.060884]  failed!
>> [24004.060887] em28xx #0: reading from i2c device failed (error=-71)
>> [24004.061126]  failed!
>> [24004.061132] em28xx #0: reading from i2c device failed (error=-71)
>> [24004.062214]  failed!
>> [24004.062219] em28xx #0: reading from i2c device failed (error=-71)
>> [24004.062378]  failed!
>> [24004.062383] em28xx #0: reading from i2c device failed (error=-71)
>> [24004.062632]  failed!
>> [24004.062636] em28xx #0: reading from i2c device failed (error=-71)
>> [24004.062884]  failed!
>> [24004.062889] em28xx #0: reading from i2c device failed (error=-71)
>> [24004.063126]  failed!
>> [24004.063131] em28xx #0: reading from i2c device failed (error=-71)
>> [24004.063375]  failed!
>> [24004.063380] em28xx #0: reading from i2c device failed (error=-71)
>> [24004.063626]  failed!
>> [24004.063631] em28xx #0: reading from i2c device failed (error=-71)
>> [24004.063875]  failed!
>> [24004.063880] em28xx #0: reading from i2c device failed (error=-71)
>> [24004.064127]  failed!
>> [24004.064132] em28xx #0: reading from i2c device failed (error=-71)
>> [24004.064376]  failed!
>> [24004.064380] em28xx #0: reading from i2c device failed (error=-71)
>> [24004.064625]  failed!
>> [24004.064630] em28xx #0: reading from i2c device failed (error=-71)
>> [24004.064876]  failed!
>> [24004.064881] em28xx #0: reading from i2c device failed (error=-71)
>> [24004.065126]  failed!
>> [24004.065130] em28xx #0: reading from i2c device failed (error=-71)
>> [24004.065376]  failed!
>> [24004.065381] em28xx #0: reading from i2c device failed (error=-71)
>> [24004.065626]  failed!
>> [24004.065632] em28xx #0: reading from i2c device failed (error=-71)
>> [24004.065875]  failed!
>> [24004.065880] em28xx #0: reading from i2c device failed (error=-71)
>> [24004.066126]  failed!
>> [24004.066131] em28xx #0: reading from i2c device failed (error=-71)
>> [24004.066376]  failed!
>> [24004.066381] em28xx #0: reading from i2c device failed (error=-71)
>> [24004.066625]  failed!
>> [24004.066629] em28xx #0: reading from i2c device failed (error=-71)
>> [24004.066875]  failed!
>> [24004.066880] em28xx #0: reading from i2c device failed (error=-71)
>> [24004.066890] em28xx #0: Your board has no unique USB ID and thus
>> need a hint to be detected.
>> [24004.066900] em28xx #0: You may try to use card=<n> insmod option to
>> workaround that.
>> [24004.066908] em28xx #0: Please send an email with this log to:
>> [24004.066916] em28xx #0:       V4L Mailing List <video4linux-list@redhat.com>
>> [24004.066924] em28xx #0: Board eeprom hash is 0x1067368a
>>
>>
>> can someone just check for errors if one error occures stop it?
>> We're facing that this driver crashes entire devices.
>>
>> regards,
>> Markus
>> --
>> To unsubscribe from this list: send the line "unsubscribe linux-media" in
>> the body of a message to majordomo@vger.kernel.org
>> More majordomo info at  http://vger.kernel.org/majordomo-info.html
>>
>
> Hey Markus,
>
> Could you stick a dump_stack() line in there so we can see where it is
> stuck in the loop?


no sorry it's a customer's system, just make it stop whenever an error
occures in the usb control part.
I removed the driver on his system now it works.

regards,
Markus

Re: em28xx driver crashes device

[Markus Rechberger]

On Thu, Jul 23, 2009 at 1:43 PM, Markus Rechberger<mrechberger@gmail.com> wrote:
> On Thu, Jul 23, 2009 at 1:41 PM, Devin
> Heitmueller<dheitmueller@kernellabs.com> wrote:
>> On Thu, Jul 23, 2009 at 5:40 AM, Markus Rechberger<mrechberger@gmail.com> wrote:
>>> Hey,
>>>
>>> [24004.018614] EEPROM ID= 0x9567eb1a, hash = 0x1067368a
>>> [24004.018618] Vendor/Product ID= eb1a:2861
>>> [24004.018622] AC97 audio (5 sample rates)
>>> [24004.018626] 500mA max power
>>> [24004.018629] Table at 0x04, strings=0x206a, 0x0000, 0x0000
>>> [24004.049201]  failed!
>>> [24004.049210] em28xx #0: reading from i2c device failed (error=-71)
>>> [24004.049444]  failed!
>>> [24004.049451] em28xx #0: reading from i2c device failed (error=-71)
>>> [24004.049655]  failed!
>>> [24004.049659] em28xx #0: reading from i2c device failed (error=-71)
>>> [24004.049891]  failed!
>>> [24004.049895] em28xx #0: reading from i2c device failed (error=-71)
>>> [24004.050141]  failed!
>>> [24004.050145] em28xx #0: reading from i2c device failed (error=-71)
>>> [24004.050393]  failed!
>>> [24004.050396] em28xx #0: reading from i2c device failed (error=-71)
>>> [24004.050641]  failed!
>>> [24004.050644] em28xx #0: reading from i2c device failed (error=-71)
>>> [24004.050890]  failed!
>>> [24004.050894] em28xx #0: reading from i2c device failed (error=-71)
>>> [24004.051141]  failed!
>>> [24004.051145] em28xx #0: reading from i2c device failed (error=-71)
>>> [24004.051392]  failed!
>>> [24004.051395] em28xx #0: reading from i2c device failed (error=-71)
>>> [24004.051641]  failed!
>>> [24004.051645] em28xx #0: reading from i2c device failed (error=-71)
>>> [24004.051892]  failed!
>>> [24004.051895] em28xx #0: reading from i2c device failed (error=-71)
>>> [24004.052140]  failed!
>>> [24004.052143] em28xx #0: reading from i2c device failed (error=-71)
>>> [24004.052393]  failed!
>>> [24004.052396] em28xx #0: reading from i2c device failed (error=-71)
>>> [24004.052642]  failed!
>>> [24004.052645] em28xx #0: reading from i2c device failed (error=-71)
>>> [24004.052892]  failed!
>>> [24004.052895] em28xx #0: reading from i2c device failed (error=-71)
>>> [24004.057741]  failed!
>>> [24004.057746] em28xx #0: reading from i2c device failed (error=-71)
>>> [24004.057880]  failed!
>>> [24004.057884] em28xx #0: reading from i2c device failed (error=-71)
>>> [24004.058125]  failed!
>>> [24004.058129] em28xx #0: reading from i2c device failed (error=-71)
>>> [24004.058379]  failed!
>>> [24004.058383] em28xx #0: reading from i2c device failed (error=-71)
>>> [24004.058628]  failed!
>>> [24004.058633] em28xx #0: reading from i2c device failed (error=-71)
>>> [24004.058880]  failed!
>>> [24004.058883] em28xx #0: reading from i2c device failed (error=-71)
>>> [24004.059128]  failed!
>>> [24004.059131] em28xx #0: reading from i2c device failed (error=-71)
>>> [24004.059380]  failed!
>>> [24004.059383] em28xx #0: reading from i2c device failed (error=-71)
>>> [24004.059636]  failed!
>>> [24004.059640] em28xx #0: reading from i2c device failed (error=-71)
>>> [24004.059914]  failed!
>>> [24004.059917] em28xx #0: reading from i2c device failed (error=-71)
>>> [24004.060140]  failed!
>>> [24004.060145] em28xx #0: reading from i2c device failed (error=-71)
>>> [24004.060388]  failed!
>>> [24004.060392] em28xx #0: reading from i2c device failed (error=-71)
>>> [24004.060636]  failed!
>>> [24004.060640] em28xx #0: reading from i2c device failed (error=-71)
>>> [24004.060884]  failed!
>>> [24004.060887] em28xx #0: reading from i2c device failed (error=-71)
>>> [24004.061126]  failed!
>>> [24004.061132] em28xx #0: reading from i2c device failed (error=-71)
>>> [24004.062214]  failed!
>>> [24004.062219] em28xx #0: reading from i2c device failed (error=-71)
>>> [24004.062378]  failed!
>>> [24004.062383] em28xx #0: reading from i2c device failed (error=-71)
>>> [24004.062632]  failed!
>>> [24004.062636] em28xx #0: reading from i2c device failed (error=-71)
>>> [24004.062884]  failed!
>>> [24004.062889] em28xx #0: reading from i2c device failed (error=-71)
>>> [24004.063126]  failed!
>>> [24004.063131] em28xx #0: reading from i2c device failed (error=-71)
>>> [24004.063375]  failed!
>>> [24004.063380] em28xx #0: reading from i2c device failed (error=-71)
>>> [24004.063626]  failed!
>>> [24004.063631] em28xx #0: reading from i2c device failed (error=-71)
>>> [24004.063875]  failed!
>>> [24004.063880] em28xx #0: reading from i2c device failed (error=-71)
>>> [24004.064127]  failed!
>>> [24004.064132] em28xx #0: reading from i2c device failed (error=-71)
>>> [24004.064376]  failed!
>>> [24004.064380] em28xx #0: reading from i2c device failed (error=-71)
>>> [24004.064625]  failed!
>>> [24004.064630] em28xx #0: reading from i2c device failed (error=-71)
>>> [24004.064876]  failed!
>>> [24004.064881] em28xx #0: reading from i2c device failed (error=-71)
>>> [24004.065126]  failed!
>>> [24004.065130] em28xx #0: reading from i2c device failed (error=-71)
>>> [24004.065376]  failed!
>>> [24004.065381] em28xx #0: reading from i2c device failed (error=-71)
>>> [24004.065626]  failed!
>>> [24004.065632] em28xx #0: reading from i2c device failed (error=-71)
>>> [24004.065875]  failed!
>>> [24004.065880] em28xx #0: reading from i2c device failed (error=-71)
>>> [24004.066126]  failed!
>>> [24004.066131] em28xx #0: reading from i2c device failed (error=-71)
>>> [24004.066376]  failed!
>>> [24004.066381] em28xx #0: reading from i2c device failed (error=-71)
>>> [24004.066625]  failed!
>>> [24004.066629] em28xx #0: reading from i2c device failed (error=-71)
>>> [24004.066875]  failed!
>>> [24004.066880] em28xx #0: reading from i2c device failed (error=-71)
>>> [24004.066890] em28xx #0: Your board has no unique USB ID and thus
>>> need a hint to be detected.
>>> [24004.066900] em28xx #0: You may try to use card=<n> insmod option to
>>> workaround that.
>>> [24004.066908] em28xx #0: Please send an email with this log to:
>>> [24004.066916] em28xx #0:       V4L Mailing List <video4linux-list@redhat.com>
>>> [24004.066924] em28xx #0: Board eeprom hash is 0x1067368a
>>>
>>>
>>> can someone just check for errors if one error occures stop it?
>>> We're facing that this driver crashes entire devices.
>>>
>>> regards,
>>> Markus
>>> --
>>> To unsubscribe from this list: send the line "unsubscribe linux-media" in
>>> the body of a message to majordomo@vger.kernel.org
>>> More majordomo info at  http://vger.kernel.org/majordomo-info.html
>>>
>>
>> Hey Markus,
>>
>> Could you stick a dump_stack() line in there so we can see where it is
>> stuck in the loop?
>
>
> no sorry it's a customer's system, just make it stop whenever an error
> occures in the usb control part.
> I removed the driver on his system now it works.
>

one thing, you might remove that autodetecting part and taking a
footprint of unknown devices
this causes more problems than everything else with those devices.
Maybe make this optional if someone wants to force autodetection over
it it might be acceptable
but doing that by default can also heat up devices.
Also if it thinks it has detected something, after toggling some gpios
the footprint might look different
again after reloading it.. it's just a failed technique doing it that way...

regards,
Markus

Re: em28xx driver crashes device

[Devin Heitmueller]

On Thu, Jul 23, 2009 at 7:46 AM, Markus Rechberger<mrechberger@gmail.com> wrote:
> one thing, you might remove that autodetecting part and taking a
> footprint of unknown devices
> this causes more problems than everything else with those devices.
> Maybe make this optional if someone wants to force autodetection over
> it it might be acceptable
> but doing that by default can also heat up devices.
> Also if it thinks it has detected something, after toggling some gpios
> the footprint might look different
> again after reloading it.. it's just a failed technique doing it that way...

I agree that I'm not particularly happy with how the autodetection
logic works today.  The current logic though is based on the
power-on-reset states of the GPIOs and GPOs though, so we are only
changing the GPIOs if the board matches a known profile.

That said, unless the hardware design was laid out such that the
device would burn out if no driver were loaded at all, I think the
risk is pretty minimal for a device that does not match a known
profile.

If Empia wants to describe a better heuristic for identifying their
various hardware designs with the same USB ID but different board
layouts and GPIO configs, that would be useful information and
eliminate the need for autodetection code.

Anyway, I'll take a look at the code and see if I can determine
specifically where the errors are occurring in your case.

The fun of dealing with hardware vendors that let their customers use
default USB IDs for different hardware designs....  :-)

Devin

-- 
Devin J. Heitmueller - Kernel Labs
http://www.kernellabs.com

Re: em28xx driver crashes device

[Markus Rechberger]

On Thu, Jul 23, 2009 at 2:03 PM, Devin
Heitmueller<dheitmueller@kernellabs.com> wrote:
> On Thu, Jul 23, 2009 at 7:46 AM, Markus Rechberger<mrechberger@gmail.com> wrote:
>> one thing, you might remove that autodetecting part and taking a
>> footprint of unknown devices
>> this causes more problems than everything else with those devices.
>> Maybe make this optional if someone wants to force autodetection over
>> it it might be acceptable
>> but doing that by default can also heat up devices.
>> Also if it thinks it has detected something, after toggling some gpios
>> the footprint might look different
>> again after reloading it.. it's just a failed technique doing it that way...
>
> I agree that I'm not particularly happy with how the autodetection
> logic works today.  The current logic though is based on the
> power-on-reset states of the GPIOs and GPOs though, so we are only
> changing the GPIOs if the board matches a known profile.
>
> That said, unless the hardware design was laid out such that the
> device would burn out if no driver were loaded at all, I think the
> risk is pretty minimal for a device that does not match a known
> profile.
>
> If Empia wants to describe a better heuristic for identifying their
> various hardware designs with the same USB ID but different board
> layouts and GPIO configs, that would be useful information and
> eliminate the need for autodetection code.
>
> Anyway, I'll take a look at the code and see if I can determine
> specifically where the errors are occurring in your case.
>
> The fun of dealing with hardware vendors that let their customers use
> default USB IDs for different hardware designs....  :-)
>

There's a pretty good disclosed detection from Empia available, the
linux kernel driver
just doesn't support it and very likely will never support it. Instead
of doing it the
wrong way it's better to turn it off or explicitly ask the user if he
wants to do something
undefined with his device.
The nvidia setup tools also provide an option to force it instead of
letting the software
just do whatever some developers don't know what it will cause...
You don't know what will happen to the device when doing that detection.
The initial device in question had to be replugged after we removed
the driver from the system.
You shouldn't invite people to do undefined things with their hardware
so they might break them
I think I will submit a few photos what physically can happen to the
device with wrong settings.

Markus

Re: em28xx driver crashes device

[Devin Heitmueller]

On Thu, Jul 23, 2009 at 8:10 AM, Markus Rechberger<mrechberger@gmail.com> wrote:
> There's a pretty good disclosed detection from Empia available, the
> linux kernel driver
> just doesn't support it and very likely will never support it. Instead
> of doing it the
> wrong way it's better to turn it off or explicitly ask the user if he
> wants to do something
> undefined with his device.
> The nvidia setup tools also provide an option to force it instead of
> letting the software
> just do whatever some developers don't know what it will cause...
> You don't know what will happen to the device when doing that detection.
> The initial device in question had to be replugged after we removed
> the driver from the system.
> You shouldn't invite people to do undefined things with their hardware
> so they might break them
> I think I will submit a few photos what physically can happen to the
> device with wrong settings.

Well, if there is a known heuristic, I would be very happy to get rid
of the autodetection logic.  I haven't looked at the Empia code in
months so I should probably do that.

Since I used to design hardware for a living, I am quite familiar with
what can happen with incorrect GPIOs so I do not believe you need to
attempt to convince me with photos, which is why I am in favor of
removing the logic in question.  We just need to figure out how to do
it without causing a regression in current device support.

Interesting...  I took a quick look at the code, and it seems like the
USB errors occur before we change any GPIOs, and more interesting it
appears that the em2861 itself is wedged (which I believe is the first
time I've seen that).  The code in the log above suggests that the
autodetection concluded that the profile was not known, so it did not
arbitrarily pick some incorrect device.  I am a bit surprised that
just reading the eeprom once and doing a scan of the i2c bus would
wedge the chip.

Is there any information you can give about the board in question in
terms of what product it is or what components it contains?

Devin

-- 
Devin J. Heitmueller - Kernel Labs
http://www.kernellabs.com

Re: em28xx driver crashes device

[Markus Rechberger]

On Thu, Jul 23, 2009 at 4:05 PM, Devin
Heitmueller<dheitmueller@kernellabs.com> wrote:
> On Thu, Jul 23, 2009 at 8:10 AM, Markus Rechberger<mrechberger@gmail.com> wrote:
>> There's a pretty good disclosed detection from Empia available, the
>> linux kernel driver
>> just doesn't support it and very likely will never support it. Instead
>> of doing it the
>> wrong way it's better to turn it off or explicitly ask the user if he
>> wants to do something
>> undefined with his device.
>> The nvidia setup tools also provide an option to force it instead of
>> letting the software
>> just do whatever some developers don't know what it will cause...
>> You don't know what will happen to the device when doing that detection.
>> The initial device in question had to be replugged after we removed
>> the driver from the system.
>> You shouldn't invite people to do undefined things with their hardware
>> so they might break them
>> I think I will submit a few photos what physically can happen to the
>> device with wrong settings.
>
> Well, if there is a known heuristic, I would be very happy to get rid
> of the autodetection logic.  I haven't looked at the Empia code in
> months so I should probably do that.
>
> Since I used to design hardware for a living, I am quite familiar with
> what can happen with incorrect GPIOs so I do not believe you need to
> attempt to convince me with photos, which is why I am in favor of
> removing the logic in question.  We just need to figure out how to do
> it without causing a regression in current device support.
>
> Interesting...  I took a quick look at the code, and it seems like the
> USB errors occur before we change any GPIOs, and more interesting it
> appears that the em2861 itself is wedged (which I believe is the first
> time I've seen that).  The code in the log above suggests that the
> autodetection concluded that the profile was not known, so it did not
> arbitrarily pick some incorrect device.  I am a bit surprised that
> just reading the eeprom once and doing a scan of the i2c bus would
> wedge the chip.
>
> Is there any information you can give about the board in question in
> terms of what product it is or what components it contains?
>

it was a simple TVP5150 based device...

I do not mean my old code either it's also a failure as I got more information
for the new driver after we dropped the old project.
As you know the new driver is entirely in Userpace and supported by all involved
chipcompanies, it comes with its own LinuxDVB and video4linux2 Stack.

Also vendors have a very low interest in supporting those devices in Kernelspace
as installing devices which should be sold now are not supported by
any distributions.
Devices which have been sold one year ago have a very low till no
motivation anymore.
Most people are simply not able to compile the drivers and/or prepare
the kernel development
environment just for installing and using a TV Card.

Regards,
Markus

Re: em28xx driver crashes device

[Mauro Carvalho Chehab]

Em Thu, 23 Jul 2009 16:29:02 +0200
Markus Rechberger <mrechberger@gmail.com> escreveu:

> On Thu, Jul 23, 2009 at 4:05 PM, Devin
> Heitmueller<dheitmueller@kernellabs.com> wrote:
> > On Thu, Jul 23, 2009 at 8:10 AM, Markus Rechberger<mrechberger@gmail.com> wrote:
> >> There's a pretty good disclosed detection from Empia available, the
> >> linux kernel driver
> >> just doesn't support it and very likely will never support it. Instead
> >> of doing it the
> >> wrong way it's better to turn it off or explicitly ask the user if he
> >> wants to do something
> >> undefined with his device.
> >> The nvidia setup tools also provide an option to force it instead of
> >> letting the software
> >> just do whatever some developers don't know what it will cause...
> >> You don't know what will happen to the device when doing that detection.
> >> The initial device in question had to be replugged after we removed
> >> the driver from the system.
> >> You shouldn't invite people to do undefined things with their hardware
> >> so they might break them
> >> I think I will submit a few photos what physically can happen to the
> >> device with wrong settings.
> >
> > Well, if there is a known heuristic, I would be very happy to get rid
> > of the autodetection logic.  I haven't looked at the Empia code in
> > months so I should probably do that.
> >
> > Since I used to design hardware for a living, I am quite familiar with
> > what can happen with incorrect GPIOs so I do not believe you need to
> > attempt to convince me with photos, which is why I am in favor of
> > removing the logic in question.  We just need to figure out how to do
> > it without causing a regression in current device support.
> >
> > Interesting...  I took a quick look at the code, and it seems like the
> > USB errors occur before we change any GPIOs, and more interesting it
> > appears that the em2861 itself is wedged (which I believe is the first
> > time I've seen that).  The code in the log above suggests that the
> > autodetection concluded that the profile was not known, so it did not
> > arbitrarily pick some incorrect device.  I am a bit surprised that
> > just reading the eeprom once and doing a scan of the i2c bus would
> > wedge the chip.
> >
> > Is there any information you can give about the board in question in
> > terms of what product it is or what components it contains?
> >
> 
> it was a simple TVP5150 based device...
> 
> I do not mean my old code either it's also a failure as I got more information
> for the new driver after we dropped the old project.
> As you know the new driver is entirely in Userpace and supported by all involved
> chipcompanies, it comes with its own LinuxDVB and video4linux2 Stack.
> 
> Also vendors have a very low interest in supporting those devices in Kernelspace
> as installing devices which should be sold now are not supported by
> any distributions.
> Devices which have been sold one year ago have a very low till no
> motivation anymore.
> Most people are simply not able to compile the drivers and/or prepare
> the kernel development
> environment just for installing and using a TV Card.

PLEASE STOP WITH FUD. THIS FORUM IS FOR OPEN SOURCE DRIVER DISCUSSION. AS YOU
DECIDED TO GO TO THE DARK SIDE, PLEASE STOP POSTING HERE OR AT THE OPEN SOURCE #IRC CHANNEL.

Thanks.
Mauro

Re: em28xx driver crashes device

[Markus Rechberger]

On Thu, Jul 23, 2009 at 8:59 PM, Mauro Carvalho
Chehab<mchehab@infradead.org> wrote:
> Em Thu, 23 Jul 2009 16:29:02 +0200
> Markus Rechberger <mrechberger@gmail.com> escreveu:
>
>> On Thu, Jul 23, 2009 at 4:05 PM, Devin
>> Heitmueller<dheitmueller@kernellabs.com> wrote:
>> > On Thu, Jul 23, 2009 at 8:10 AM, Markus Rechberger<mrechberger@gmail.com> wrote:
>> >> There's a pretty good disclosed detection from Empia available, the
>> >> linux kernel driver
>> >> just doesn't support it and very likely will never support it. Instead
>> >> of doing it the
>> >> wrong way it's better to turn it off or explicitly ask the user if he
>> >> wants to do something
>> >> undefined with his device.
>> >> The nvidia setup tools also provide an option to force it instead of
>> >> letting the software
>> >> just do whatever some developers don't know what it will cause...
>> >> You don't know what will happen to the device when doing that detection.
>> >> The initial device in question had to be replugged after we removed
>> >> the driver from the system.
>> >> You shouldn't invite people to do undefined things with their hardware
>> >> so they might break them
>> >> I think I will submit a few photos what physically can happen to the
>> >> device with wrong settings.
>> >
>> > Well, if there is a known heuristic, I would be very happy to get rid
>> > of the autodetection logic.  I haven't looked at the Empia code in
>> > months so I should probably do that.
>> >
>> > Since I used to design hardware for a living, I am quite familiar with
>> > what can happen with incorrect GPIOs so I do not believe you need to
>> > attempt to convince me with photos, which is why I am in favor of
>> > removing the logic in question.  We just need to figure out how to do
>> > it without causing a regression in current device support.
>> >
>> > Interesting...  I took a quick look at the code, and it seems like the
>> > USB errors occur before we change any GPIOs, and more interesting it
>> > appears that the em2861 itself is wedged (which I believe is the first
>> > time I've seen that).  The code in the log above suggests that the
>> > autodetection concluded that the profile was not known, so it did not
>> > arbitrarily pick some incorrect device.  I am a bit surprised that
>> > just reading the eeprom once and doing a scan of the i2c bus would
>> > wedge the chip.
>> >
>> > Is there any information you can give about the board in question in
>> > terms of what product it is or what components it contains?
>> >
>>
>> it was a simple TVP5150 based device...
>>
>> I do not mean my old code either it's also a failure as I got more information
>> for the new driver after we dropped the old project.
>> As you know the new driver is entirely in Userpace and supported by all involved
>> chipcompanies, it comes with its own LinuxDVB and video4linux2 Stack.
>>
>> Also vendors have a very low interest in supporting those devices in Kernelspace
>> as installing devices which should be sold now are not supported by
>> any distributions.
>> Devices which have been sold one year ago have a very low till no
>> motivation anymore.
>> Most people are simply not able to compile the drivers and/or prepare
>> the kernel development
>> environment just for installing and using a TV Card.
>
> PLEASE STOP WITH FUD. THIS FORUM IS FOR OPEN SOURCE DRIVER DISCUSSION. AS YOU
> DECIDED TO GO TO THE DARK SIDE, PLEASE STOP POSTING HERE OR AT THE OPEN SOURCE #IRC CHANNEL.
>

someone has problems here? We also support available opensource
players and will contribute some patches which can be used by all
devices.

Markus

Re: em28xx driver crashes device

[Mauro Carvalho Chehab]

Em Fri, 24 Jul 2009 12:54:27 +0200
Markus Rechberger <mrechberger@gmail.com> escreveu:

> someone has problems here? We also support available opensource
> players and will contribute some patches which can be used by all
> devices.

This mailing list, the freenode irc channels #v4l and #linuxtv, the V4L and the
LinuxTV mailing lists were created for discussing open source development
related to the kernel linux media drivers, the usability of those drivers and
related open source themes.

Anything related to binary only userspace stuff is completely out of topic and
shouldn't be posted on the above places.

Despiste what you're saying, your intention to drop support to open source is
clear: you are playing against open source since 2007, when you firstly proposed a
frontend hook at the kernel driver for userspace. This year, you dropped all
open source trees you used to have. So, it is clear that you're out of open
source business, and you won't be giving any open source support. So, please
stop posting at the open source forums



Cheers,
Mauro

Re: em28xx driver crashes device

[Markus Rechberger]

On Fri, Jul 24, 2009 at 2:06 PM, Mauro Carvalho
Chehab<mchehab@infradead.org> wrote:
> Em Fri, 24 Jul 2009 12:54:27 +0200
> Markus Rechberger <mrechberger@gmail.com> escreveu:
>
>> someone has problems here? We also support available opensource
>> players and will contribute some patches which can be used by all
>> devices.
>

Ah well Mauro,

> This mailing list, the freenode irc channels #v4l and #linuxtv, the V4L and the
> LinuxTV mailing lists were created for discussing open source development
> related to the kernel linux media drivers, the usability of those drivers and
> related open source themes.
>
> Anything related to binary only userspace stuff is completely out of topic and
> shouldn't be posted on the above places.
>
> Despiste what you're saying, your intention to drop support to open source is
> clear: you are playing against open source since 2007, when you firstly proposed a
> frontend hook at the kernel driver for userspace. This year, you dropped all
> open source trees you used to have. So, it is clear that you're out of open
> source business, and you won't be giving any open source support. So, please
> stop posting at the open source forums
>

there's no reason to argue with you since you have your own ideas. We
do give opensource support as well. So please find another target to
struggle around with. Let's see who's able to deliver the better
solution for endusers.

Thanks,
Markus

Re: em28xx driver crashes device

[Simon Kenyon]

Markus Rechberger wrote:
> there's no reason to argue with you since you have your own ideas. We
> do give opensource support as well. So please find another target to
> struggle around with. Let's see who's able to deliver the better
> solution for endusers.
>   
i raise to the bait every so often :-)

since when was this a competition?

a couple of years ago i bought a device because it was "supported"
then you took you code away and went off and did your own thing

i think that was a really immature thing to do
you could help with efforts here, but you choose not to
either work to add additional functionality to the in-kernel driver or 
just go away

but please (oh please) stop spamming this list with your "help"
--
simon

Re: em28xx driver crashes device

[Mauro Carvalho Chehab]

Em Fri, 24 Jul 2009 14:15:16 +0200
Markus Rechberger <mrechberger@gmail.com> escreveu:

> On Fri, Jul 24, 2009 at 2:06 PM, Mauro Carvalho
> Chehab<mchehab@infradead.org> wrote:
> > Em Fri, 24 Jul 2009 12:54:27 +0200
> > Markus Rechberger <mrechberger@gmail.com> escreveu:
> >
> >> someone has problems here? We also support available opensource
> >> players and will contribute some patches which can be used by all
> >> devices.
> >
> 
> Ah well Mauro,
> 
> > This mailing list, the freenode irc channels #v4l and #linuxtv, the V4L and the
> > LinuxTV mailing lists were created for discussing open source development
> > related to the kernel linux media drivers, the usability of those drivers and
> > related open source themes.
> >
> > Anything related to binary only userspace stuff is completely out of topic and
> > shouldn't be posted on the above places.
> >
> > Despiste what you're saying, your intention to drop support to open source is
> > clear: you are playing against open source since 2007, when you firstly proposed a
> > frontend hook at the kernel driver for userspace. This year, you dropped all
> > open source trees you used to have. So, it is clear that you're out of open
> > source business, and you won't be giving any open source support. So, please
> > stop posting at the open source forums
> >
> 
> there's no reason to argue with you since you have your own ideas. We
> do give opensource support as well. So please find another target to
> struggle around with. Let's see who's able to deliver the better
> solution for endusers.

This is not a sort of game to see who has a better solution for end users.

A company that has a serious commit to open source opens their datasheets to
allow public development and contributions and submit patches regularly
upstream, without any userspace hooks.

Closed source drivers don't fit well at open source market. There are lots of
examples of failures to this approach with all sorts of vendors, and lots of
buyers decision of not buying a card X because open source driver doesn't exist
or is crappy.

Anyway, it might have some space for your driver, but not on this forum.

Cheers,
Mauro

---

"What we're saying today is that you're either part of the solution or you're part of the problem."
[1968 E. Cleaver Speech (in R. Scheer, Eldridge Cleaver (1969) 32)]

Re: em28xx driver crashes device

[Markus Rechberger]

On Fri, Jul 24, 2009 at 3:06 PM, Mauro Carvalho
Chehab<mchehab@infradead.org> wrote:
> Em Fri, 24 Jul 2009 14:15:16 +0200
> Markus Rechberger <mrechberger@gmail.com> escreveu:
>
>> On Fri, Jul 24, 2009 at 2:06 PM, Mauro Carvalho
>> Chehab<mchehab@infradead.org> wrote:
>> > Em Fri, 24 Jul 2009 12:54:27 +0200
>> > Markus Rechberger <mrechberger@gmail.com> escreveu:
>> >
>> >> someone has problems here? We also support available opensource
>> >> players and will contribute some patches which can be used by all
>> >> devices.
>> >
>>
>> Ah well Mauro,
>>
>> > This mailing list, the freenode irc channels #v4l and #linuxtv, the V4L and the
>> > LinuxTV mailing lists were created for discussing open source development
>> > related to the kernel linux media drivers, the usability of those drivers and
>> > related open source themes.
>> >
>> > Anything related to binary only userspace stuff is completely out of topic and
>> > shouldn't be posted on the above places.
>> >
>> > Despiste what you're saying, your intention to drop support to open source is
>> > clear: you are playing against open source since 2007, when you firstly proposed a
>> > frontend hook at the kernel driver for userspace. This year, you dropped all
>> > open source trees you used to have. So, it is clear that you're out of open
>> > source business, and you won't be giving any open source support. So, please
>> > stop posting at the open source forums
>> >
>>
>> there's no reason to argue with you since you have your own ideas. We
>> do give opensource support as well. So please find another target to
>> struggle around with. Let's see who's able to deliver the better
>> solution for endusers.
>
> This is not a sort of game to see who has a better solution for end users.
>
> A company that has a serious commit to open source opens their datasheets to
> allow public development and contributions and submit patches regularly
> upstream, without any userspace hooks.
>

If a kerneldriver would be required for our devices we now would
definitely submit further patches to the kernel, but for USB drivers
it is just not necessary at all since the entire driver can work
without any complex dependencies in Userspace. Basically the
historically grown v4l-dvb kernelapi is just not needed and just
limits the customer base as initially pointed out that not everyone is
able to compile those drivers. It is still valid for PCI devices
probably until IOMMU is available. This has absolutely nothing to do
with what you wrote, rather than the em28xx kerneldriver is basically
not needed. If you want datasheets of various companies apply there
and work for them, everyone's free to do so.

regards,
Markus

Re: em28xx driver crashes device

[Steven Toth]

>>>> This mailing list, the freenode irc channels #v4l and #linuxtv, the V4L and the
>>>> LinuxTV mailing lists were created for discussing open source development
>>>> related to the kernel linux media drivers, the usability of those drivers and
>>>> related open source themes.
>>>>
>>>> Anything related to binary only userspace stuff is completely out of topic and
>>>> shouldn't be posted on the above places.

Markus,

The Linux community supports it's in-kernel dvb / v4l trees using this channel. 
Your attempt to use these channels to de-value the in-kernel driver and your 
agenda to promote your (partially) closed source alternative it is off topic.

This is not the first time people have had to say this.

You're only damaging your reputation further using tactics like this.

-- 
Steven Toth - Kernel Labs
http://www.kernellabs.com

Re: em28xx driver crashes device

[cyber.bogh]

Am Freitag 24 Juli 2009 18:42:58 schrieben Sie:
> >>>> This mailing list, the freenode irc channels #v4l and #linuxtv, the
> >>>> V4L and the LinuxTV mailing lists were created for discussing open
> >>>> source development related to the kernel linux media drivers, the
> >>>> usability of those drivers and related open source themes.
> >>>>
> >>>> Anything related to binary only userspace stuff is completely out of
> >>>> topic and shouldn't be posted on the above places.
>
> Markus,
>
> The Linux community supports it's in-kernel dvb / v4l trees using this
> channel. Your attempt to use these channels to de-value the in-kernel
> driver and your agenda to promote your (partially) closed source
> alternative it is off topic.

Toth,

from profound resources I do know that you personally do not know anything 
about what excesses your highly specific card knowledge, which definitely does 
not even touch Empia devices at least superficially.

In other words:
Your personal voice counts absolutely NOTHING as far as the discussed issue is 
concerned.

I would personally suggest you to volunteer as ordinary soldier for 
Afghanistan sitting in the first row. This is the perfect place of getting rid 
of small brained reactionary people like you, isn't it?

I decide to keep for me what I think about your physiognomy that can be seen 
on a photograph shot after a Linux conference somewhere in the US.....
You can call that a rest of politeness.......
I am not use to people like you in the open source movement, if not to say:
I do regard you personally as a displaced impurity.

> This is not the first time people have had to say this.

The authoritarian character (if not to say fascistoid character) described in 
the studies of Theodor Adorno tends very often to use "we" or "people" instead 
of using the "I".
This is a proof that the accordant person was kept down from the beginning of 
childhood, trained to function like a robot without any unsuppressed attempt 
of thinking freely. Characters of that rather distorted kind very often (but 
not always) become cops or soldiers as profession to earn their living.

You will not help Mauro in his displaced position anyway, Toth! 
Lessons @ Richard Stallman would possibly help, although I am not too 
optimistic in your case to be honest......

> You're only damaging your reputation further using tactics like this.

This is what I call a (stupid) boomerang.
Psychologists would call that a "projection".

The truth about you, Toth, is that you yourself do not only damage your 
personal reputation by helping reactionary people like Mauro Chehab to betray 
the open source philosophy in its deepest essence.

But in fact you show that you are a mismatch as far as human qualifications are 
concerned.

Re: em28xx driver crashes device

[Steven Toth]

On 7/24/09 1:34 PM, cyber.bogh wrote:
> Am Freitag 24 Juli 2009 18:42:58 schrieben Sie:
>>>>>> This mailing list, the freenode irc channels #v4l and #linuxtv, the
>>>>>> V4L and the LinuxTV mailing lists were created for discussing open
>>>>>> source development related to the kernel linux media drivers, the
>>>>>> usability of those drivers and related open source themes.
>>>>>>
>>>>>> Anything related to binary only userspace stuff is completely out of
>>>>>> topic and shouldn't be posted on the above places.
>> Markus,
>>
>> The Linux community supports it's in-kernel dvb / v4l trees using this
>> channel. Your attempt to use these channels to de-value the in-kernel
>> driver and your agenda to promote your (partially) closed source
>> alternative it is off topic.
>
> Toth,

<snip>

>
> But in fact you show that you are a mismatch as far as human qualifications are
> concerned.
>

This is indeed high praise coming from such a fine and noble gentlemen like 
yourself. I find myself truly humbled, nay, honored that you've chosen to grace 
us with your presence and thoughts today.

I'm probably not alone when I say that we look forward to your monumental words 
of wisdom, charm and enlightenment that you've recently chosen to share with us 
all. You have a true gift and I can only hope that you continue to share it with 
us all.

Happy Christmas, please give my regards to the wife and kids.

-- 
Steven Toth - Kernel Labs
http://www.kernellabs.com

Re: em28xx driver crashes device

[hermann pitton]

Am Freitag, den 24.07.2009, 12:42 -0400 schrieb Steven Toth:
> >>>> This mailing list, the freenode irc channels #v4l and #linuxtv, the V4L and the
> >>>> LinuxTV mailing lists were created for discussing open source development
> >>>> related to the kernel linux media drivers, the usability of those drivers and
> >>>> related open source themes.
> >>>>
> >>>> Anything related to binary only userspace stuff is completely out of topic and
> >>>> shouldn't be posted on the above places.
> 
> Markus,
> 
> The Linux community supports it's in-kernel dvb / v4l trees using this channel. 
> Your attempt to use these channels to de-value the in-kernel driver and your 
> agenda to promote your (partially) closed source alternative it is off topic.
> 
> This is not the first time people have had to say this.
> 
> You're only damaging your reputation further using tactics like this.
> 

there are also SILVERCREST empia webcams with older revisions of the
sensor chip going over the desk here for 5€ already 18 months back.

Really interesting bullshit.

The vista driver took more than one year to be present ...

Great stuff !

Chears,
Hermann

Re: em28xx driver crashes device

[cyber.bogh]

Am Freitag 24 Juli 2009 15:06:08 schrieben Sie:
> Em Fri, 24 Jul 2009 14:15:16 +0200
>
> Markus Rechberger <mrechberger@gmail.com> escreveu:
> > On Fri, Jul 24, 2009 at 2:06 PM, Mauro Carvalho
> >
> > Chehab<mchehab@infradead.org> wrote:
> > > Em Fri, 24 Jul 2009 12:54:27 +0200
> > >
> > > Markus Rechberger <mrechberger@gmail.com> escreveu:
> > >> someone has problems here? We also support available opensource
> > >> players and will contribute some patches which can be used by all
> > >> devices.
> >
> > Ah well Mauro,
> >
> > > This mailing list, the freenode irc channels #v4l and #linuxtv, the V4L
> > > and the LinuxTV mailing lists were created for discussing open source
> > > development related to the kernel linux media drivers, the usability of
> > > those drivers and related open source themes.
> > >
> > > Anything related to binary only userspace stuff is completely out of
> > > topic and shouldn't be posted on the above places.
> > >
> > > Despiste what you're saying, your intention to drop support to open
> > > source is clear: you are playing against open source since 2007, when
> > > you firstly proposed a frontend hook at the kernel driver for
> > > userspace. This year, you dropped all open source trees you used to
> > > have. So, it is clear that you're out of open source business, and you
> > > won't be giving any open source support. So, please stop posting at the
> > > open source forums
> >
> > there's no reason to argue with you since you have your own ideas. We
> > do give opensource support as well. So please find another target to
> > struggle around with. Let's see who's able to deliver the better
> > solution for endusers.
>
> This is not a sort of game to see who has a better solution for end users.

Wrong! For the user who does not look behind the curtain (and the majority of 
them do not) the recommended solution wins. The essence of the recommendation 
is the decisive point, nothing else.

> A company that has a serious commit to open source opens their datasheets
> to allow public development and contributions and submit patches regularly
> upstream, without any userspace hooks.

Nonsense! How can you talk about "public development" if the majority of 
developers is forced to sign non-disclosure agreements as a necessary 
precondition to get access to data sheets?

> Closed source drivers don't fit well at open source market. There are lots
> of examples of failures to this approach with all sorts of vendors, and
> lots of buyers decision of not buying a card X because open source driver
> doesn't exist or is crappy.

Dream on baby, I'm sure tomorrow you will tell us all that pigs can fly :)
The majority is still MS, and you and I won't change that - unfortunately.

> Anyway, it might have some space for your driver, but not on this forum.

Who gives you the right to say that to anybody?
You should perhaps take some lessons about the philosophical basics of open 
source @ Mister Richard Stallman:
There you will learn what "freedom" in the deeper sense of open source means:
It does not mean "free beer". But in fact it is equivalent to "free speech".

And this equivalent to "freedom of speech" definitely excludes fascistoid small 
brained gestures like "I am the boss" or "You are not allowed to speak in that 
forum" and other Machoist stupid omnipotence phantasies of that rather poor 
and primitive no brain kind.

> Cheers,
> Mauro
>
> ---
>
> "What we're saying today is that you're either part of the solution or
> you're part of the problem." [1968 E. Cleaver Speech (in R. Scheer,
> Eldridge Cleaver (1969) 32)] --

I'd call that fascist crap.

And to teach you, Chehab, (and of course all your brothers and sisters in 
mind) in how far you are a wrong and a completely displaced person I will give 
you a citation of John Lennon from 1966.
It treats the difference of the pure idea of "christian religion" and small 
brained human hypocritic practice on the other hand:

"Jesus was alright, but his disciples were nothing but thick and ordinary.
It's them twisting it that ruins it for me."

Available here: http://quotationsbook.com/quote/21607/

So everyone reading that who can really think further without external 
leadership (following the studies of Immanuel Kant) will easily understand in 
how far Markus' decision to quit linuxtv.org was NOT a pure technical one.

To make open source a real fun and pleasure we need large minded, real 
liberal, progressive thinking maintainers, NOT blind functioning brain-washed 
soldiers of the rather disgusting primitive fascistoid kind.

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

Re: em28xx driver crashes device

[Simon Kenyon]

Markus Rechberger wrote:
> On Fri, Jul 24, 2009 at 2:06 PM, Mauro Carvalho
> Chehab<mchehab@infradead.org> wrote:
>   
>> Em Fri, 24 Jul 2009 12:54:27 +0200
>> Markus Rechberger <mrechberger@gmail.com> escreveu:
>>
>>     
>>> someone has problems here? We also support available opensource
>>> players and will contribute some patches which can be used by all
>>> devices.
>>>       
>
> Ah well Mauro,
>
>   
>> This mailing list, the freenode irc channels #v4l and #linuxtv, the V4L and the
>> LinuxTV mailing lists were created for discussing open source development
>> related to the kernel linux media drivers, the usability of those drivers and
>> related open source themes.
>>
>> Anything related to binary only userspace stuff is completely out of topic and
>> shouldn't be posted on the above places.
>>
>> Despiste what you're saying, your intention to drop support to open source is
>> clear: you are playing against open source since 2007, when you firstly proposed a
>> frontend hook at the kernel driver for userspace. This year, you dropped all
>> open source trees you used to have. So, it is clear that you're out of open
>> source business, and you won't be giving any open source support. So, please
>> stop posting at the open source forums
>>
>>     
>
> there's no reason to argue with you since you have your own ideas. We
> do give opensource support as well. So please find another target to
> struggle around with. Let's see who's able to deliver the better
> solution for endusers.
>   
i see that mcentral.de/hg has disappeared

Re: em28xx driver crashes device

[Simon Kenyon]

Simon Kenyon wrote:
>  i see that mcentral.de/hg has disappeared
i have a copy of em28xx-new from 22nd may if anyone needs it
--
simon