Re: [PATCH 2.6] Fix i2c messsage flags in video drivers
Hi Jean, On Thu, 10 Mar 2005, Jean Delvare wrote: > > My experience is not the same as yours, it seems... I cannot explain why, > > unfortunately. (...) > > I can. [..] > So as long as you don't move to a 2.6.11 kernel, don't even bother > trying my patches, because you will never hit the code that I am trying > to fix. That makes sense. I'll try the >=.11 kernels sometime soon. Thanks, Ronald - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH 2.6] Fix i2c messsage flags in video drivers
Hi Ronald, > I indeed don't test RC/MM kernels. I'm fairly happy with the current > driver status, so I'm not doing any active new development on it. I run > standard Fedora kernels with CVS of the driver (which is the same as > what's in 2.6.10). > (...) > My experience is not the same as yours, it seems... I cannot explain why, > unfortunately. (...) I can. You are using a 2.6.10 kernel at best (that's what FC3 updates have), and the bug is triggered by changes made to the i2c-algo-bit driver somewhere between 2.6.10 and 2.6.11. So it's not surprising that you don't see any problem. Note that the version of the media/video drivers you use is not relevant here. The bug has been there for over a year, but the code path where it lies was never taken until i2c-algo-bit was updated recently. What matters is the version of i2c-algo-bit. So as long as you don't move to a 2.6.11 kernel, don't even bother trying my patches, because you will never hit the code that I am trying to fix. Thanks, -- Jean Delvare - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH 2.6] Fix i2c messsage flags in video drivers
Hi Jean, thanks for the reply. On Thu, 10 Mar 2005, Jean Delvare wrote: > I'm glad to learn you are testing things. Still the oops in saa7110 went > unnoticed for the past 3 months, so I guess that either you don't have > a DC10(+) in your test panel, or you did not test mm/rc kernels. I indeed don't test RC/MM kernels. I'm fairly happy with the current driver status, so I'm not doing any active new development on it. I run standard Fedora kernels with CVS of the driver (which is the same as what's in 2.6.10). > BUZ: > Input (saa7111): works > Output (saa7185): no init, cannot set norm I have this card, but it's no in my computer (not enough PCI slots). Last test is from a few months back. Other people (co-developers) test this for me whenever I make small driver changes. They report that it works, whatever that means. ;). I know they regularly use it for capture, so at least MJPEG capture and overlay display has to work to some degree. Output may be untested. > DC10: > Input (saa7110): oops > Output (adv7175): no init, cannot set norm > > DC30: > Input (vpx3220): works > Output (adv7175): no init, cannot set norm I have those two. Both work fine. I test raw capture, MJPEG capture and overlay display at least once a week. I don't get an oops on the DC10. I haven't tested output lately. I basically only test output when I make changes to the relevant modules, and I haven't done that lately. Last time I tested it (which must be around the time the driver was integrated into the kernel, so before 2.6.0...), it worked for me. > LM33: > Input (bt819): no init > Output (bt856): works > > LM33R10: > Input (saa7114): no init, cannot set norm > Output (adv7170): no init, cannot set norm See Buz. > As you can see, all boards are affected at some level but every user > might not be equally affected, depends whether you use input or output > or both. Note that "no init" might not affect everyone either, depends > on the chip init defaults and the user needs. Ronald, can you tell us > what exactly in the above you are testing? My experience is not the same as yours, it seems... I cannot explain why, unfortunately. Again, I'm sure your patch is correct, I'm just reporting that I'm not seeing the same thing that you're seeing. Ronald - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH 2.6] Fix i2c messsage flags in video drivers
Hi Ronald, [Jean Delvare] > It is possible that people are able to get their board to still work > without my patch, if the chips were properly configured in the first > place and they don't attempt to reconfigure them (like norm change). I > don't know the chips well enough to tell how probable this is. [Ronald S. Bultje] > I'm pretty sure the patch is correct, I trust you a lot more on that than > myself (I still need to test it, though; but that's a detail). However, > this statement is not correct. I test this driver daily, I still own a > whole bunch of such cards. Even after hard reboots, they still just work. > Norm changes, input changes, everything works. I test (and use) all of > this. I would've noticed if it was really as broken as you're describing > above. I'm glad to learn you are testing things. Still the oops in saa7110 went unnoticed for the past 3 months, so I guess that either you don't have a DC10(+) in your test panel, or you did not test mm/rc kernels. I've gone through the code again, and here is what I think is broken in 2.6.11 on the various Zoran-based boards. Then everyone will be free to pick any patch chunk he/she wants and apply it to any tree he/she likes. BUZ: Input (saa7111): works Output (saa7185): no init, cannot set norm DC10: Input (saa7110): oops Output (adv7175): no init, cannot set norm DC30: Input (vpx3220): works Output (adv7175): no init, cannot set norm LM33: Input (bt819): no init Output (bt856): works LM33R10: Input (saa7114): no init, cannot set norm Output (adv7170): no init, cannot set norm As you can see, all boards are affected at some level but every user might not be equally affected, depends whether you use input or output or both. Note that "no init" might not affect everyone either, depends on the chip init defaults and the user needs. Ronald, can you tell us what exactly in the above you are testing? Personally I have only been able to test input on a DC10+ board (saa7110 driver). I lack hardware to test the output. Hope that clarifies things, -- Jean Delvare - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH 2.6] Fix i2c messsage flags in video drivers
Hi Jean, I'm sorry for a late reply, mail is (still) misbehaving. I hope this arrives at all... On Wed, 9 Mar 2005, Jean Delvare wrote: > It is possible that people are able to get their board to still work > without my patch, if the chips were properly configured in the first > place and they don't attempt to reconfigure them (like norm change). I > don't know the chips well enough to tell how probable this is. I'm pretty sure the patch is correct, I trust you a lot more on that than myself (I still need to test it, though; but that's a detail). However, this statement is not correct. I test this driver daily, I still own a whole bunch of such cards. Even after hard reboots, they still just work. Norm changes, input changes, everything works. I test (and use) all of this. I would've noticed if it was really as broken as you're describing above. Ronald - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH 2.6] Fix i2c messsage flags in video drivers
* Jean Delvare ([EMAIL PROTECTED]) wrote: > > > > Are people reporting this as a problem? > > Not that I know. For adv7175 it couldn't be reported so far anyway > because people would hit the oops in saa7110 before (same board: DC10+, > oops fixed in a different patch). Heh, right. > It is possible that people are able to get their board to still work > without my patch, if the chips were properly configured in the first > place and they don't attempt to reconfigure them (like norm change). I > don't know the chips well enough to tell how probable this is. According to offlist mail, it does "fix a bug that bothers people." So looks like a fine candidate, and is queued up for -stable. thanks, -chris -- Linux Security Modules http://lsm.immunix.org http://lsm.bkbits.net - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH 2.6] Fix i2c messsage flags in video drivers
Hi Chris, > > While working on the saa7110 driver I found a problem with the way > > various video drivers (found on Zoran-based boards) prepare i2c > > messages to be used by i2c_transfer. The drivers improperly copy the > > i2c client flags as the message flags, while both sets are mostly > > unrelated. The net effect in this case is to trigger an I2C block > > read instead of the expected I2C block write. The fix is simply not > > to pass any flag, because none are needed. > > > > I think this patch qualifies hands down as a "critical bug fix" to > > be included in whatever bug-fix-only trees exist these days. As far > > as I can see, all Zoran-based boards are broken in 2.6.11 without > > this patch. > > Are people reporting this as a problem? Not that I know. For adv7175 it couldn't be reported so far anyway because people would hit the oops in saa7110 before (same board: DC10+, oops fixed in a different patch). It is possible that people are able to get their board to still work without my patch, if the chips were properly configured in the first place and they don't attempt to reconfigure them (like norm change). I don't know the chips well enough to tell how probable this is. Thanks, -- Jean Delvare - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH 2.6] Fix i2c messsage flags in video drivers
* Jean Delvare ([EMAIL PROTECTED]) wrote: > Hi all, > > While working on the saa7110 driver I found a problem with the way > various video drivers (found on Zoran-based boards) prepare i2c messages > to be used by i2c_transfer. The drivers improperly copy the i2c client > flags as the message flags, while both sets are mostly unrelated. The > net effect in this case is to trigger an I2C block read instead of the > expected I2C block write. The fix is simply not to pass any flag, > because none are needed. > > I think this patch qualifies hands down as a "critical bug fix" to be > included in whatever bug-fix-only trees exist these days. As far as I > can see, all Zoran-based boards are broken in 2.6.11 without this patch. Are people reporting this as a problem? -- Linux Security Modules http://lsm.immunix.org http://lsm.bkbits.net - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
