Re: em28xx driver crashes device
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 -- 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: em28xx driver crashes device
On Thu, Jul 23, 2009 at 8:59 PM, Mauro Carvalho Chehabmche...@infradead.org wrote: Em Thu, 23 Jul 2009 16:29:02 +0200 Markus Rechberger mrechber...@gmail.com escreveu: On Thu, Jul 23, 2009 at 4:05 PM, Devin Heitmuellerdheitmuel...@kernellabs.com wrote: On Thu, Jul 23, 2009 at 8:10 AM, Markus Rechbergermrechber...@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 -- 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: em28xx driver crashes device
Em Fri, 24 Jul 2009 12:54:27 +0200 Markus Rechberger mrechber...@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 -- 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: em28xx driver crashes device
On Fri, Jul 24, 2009 at 2:06 PM, Mauro Carvalho Chehabmche...@infradead.org wrote: Em Fri, 24 Jul 2009 12:54:27 +0200 Markus Rechberger mrechber...@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 -- 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: em28xx driver crashes device
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 -- 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: em28xx driver crashes device
Em Fri, 24 Jul 2009 14:15:16 +0200 Markus Rechberger mrechber...@gmail.com escreveu: On Fri, Jul 24, 2009 at 2:06 PM, Mauro Carvalho Chehabmche...@infradead.org wrote: Em Fri, 24 Jul 2009 12:54:27 +0200 Markus Rechberger mrechber...@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)] -- 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: em28xx driver crashes device
On Fri, Jul 24, 2009 at 3:06 PM, Mauro Carvalho Chehabmche...@infradead.org wrote: Em Fri, 24 Jul 2009 14:15:16 +0200 Markus Rechberger mrechber...@gmail.com escreveu: On Fri, Jul 24, 2009 at 2:06 PM, Mauro Carvalho Chehabmche...@infradead.org wrote: Em Fri, 24 Jul 2009 12:54:27 +0200 Markus Rechberger mrechber...@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 -- 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: em28xx driver crashes device
Markus Rechberger wrote: On Fri, Jul 24, 2009 at 2:06 PM, Mauro Carvalho Chehabmche...@infradead.org wrote: Em Fri, 24 Jul 2009 12:54:27 +0200 Markus Rechberger mrechber...@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 -- 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: em28xx driver crashes device
Am Freitag 24 Juli 2009 15:06:08 schrieben Sie: Em Fri, 24 Jul 2009 14:15:16 +0200 Markus Rechberger mrechber...@gmail.com escreveu: On Fri, Jul 24, 2009 at 2:06 PM, Mauro Carvalho Chehabmche...@infradead.org wrote: Em Fri, 24 Jul 2009 12:54:27 +0200 Markus Rechberger mrechber...@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 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: em28xx driver crashes device
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 -- 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: em28xx driver crashes device
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. -- 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: em28xx driver crashes device
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 -- 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: em28xx driver crashes device
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 -- 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: em28xx driver crashes device
On Thu, Jul 23, 2009 at 5:40 AM, Markus Rechbergermrechber...@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, 0x, 0x [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]
Re: em28xx driver crashes device
On Thu, Jul 23, 2009 at 1:41 PM, Devin Heitmuellerdheitmuel...@kernellabs.com wrote: On Thu, Jul 23, 2009 at 5:40 AM, Markus Rechbergermrechber...@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, 0x, 0x [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!
Re: em28xx driver crashes device
On Thu, Jul 23, 2009 at 7:46 AM, Markus Rechbergermrechber...@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 -- 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: em28xx driver crashes device
On Thu, Jul 23, 2009 at 2:03 PM, Devin Heitmuellerdheitmuel...@kernellabs.com wrote: On Thu, Jul 23, 2009 at 7:46 AM, Markus Rechbergermrechber...@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 -- 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: em28xx driver crashes device
On Thu, Jul 23, 2009 at 8:10 AM, Markus Rechbergermrechber...@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 -- 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: em28xx driver crashes device
On Thu, Jul 23, 2009 at 4:05 PM, Devin Heitmuellerdheitmuel...@kernellabs.com wrote: On Thu, Jul 23, 2009 at 8:10 AM, Markus Rechbergermrechber...@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 -- 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: em28xx driver crashes device
Em Thu, 23 Jul 2009 16:29:02 +0200 Markus Rechberger mrechber...@gmail.com escreveu: On Thu, Jul 23, 2009 at 4:05 PM, Devin Heitmuellerdheitmuel...@kernellabs.com wrote: On Thu, Jul 23, 2009 at 8:10 AM, Markus Rechbergermrechber...@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 -- 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
