* Re: DViCO FusionHDTV7 Dual Express I2C write failed [not found] <20101207190753.GA21666@io.frii.com> @ 2011-01-10 2:14 ` Mark Zimmerman 2011-01-19 15:59 ` VDR User 2011-01-17 23:12 ` Timothy D. Lenz 2011-02-12 15:29 ` [get-bisect results]: " Mark Zimmerman 2 siblings, 1 reply; 25+ messages in thread From: Mark Zimmerman @ 2011-01-10 2:14 UTC (permalink / raw) To: linux-media On Tue, Dec 07, 2010 at 12:07:53PM -0700, Mark Zimmerman wrote: > Greetings: > > I have a DViCO FusionHDTV7 Dual Express card that works with 2.6.35 but > which fails to initialize with the latest 2.6.36 kernel. The firmware > fails to load due to an i2c failure. A search of the archives indicates > that this is not the first time this issue has occurred. > > What can I do to help get this problem fixed? > > Here is the dmesg from 2.6.35, for the two tuners: > > xc5000: waiting for firmware upload (dvb-fe-xc5000-1.6.114.fw)... > xc5000: firmware read 12401 bytes. > xc5000: firmware uploading... > xc5000: firmware upload complete... > xc5000: waiting for firmware upload (dvb-fe-xc5000-1.6.114.fw)... > xc5000: firmware read 12401 bytes. > xc5000: firmware uploading... > xc5000: firmware upload complete.. > > and here is what happens with 2.6.36: > > xc5000: waiting for firmware upload (dvb-fe-xc5000-1.6.114.fw)... > xc5000: firmware read 12401 bytes. > xc5000: firmware uploading... > xc5000: I2C write failed (len=3) > xc5000: firmware upload complete... > xc5000: Unable to initialise tuner > xc5000: waiting for firmware upload (dvb-fe-xc5000-1.6.114.fw)... > xc5000: firmware read 12401 bytes. > xc5000: firmware uploading... > xc5000: I2C write failed (len=3) > xc5000: firmware upload complete... > More information about this: I tried 2.6.37 (vanilla source from kernel.org) and the problem persisted. So, I enabled these options: CONFIG_I2C_DEBUG_CORE=y CONFIG_I2C_DEBUG_ALGO=y CONFIG_I2C_DEBUG_BUS=y hoping to get more information but this time the firmware loaded successfully and the tuner works properly. This leads me to suspect a race condition somewhere, or maybe a tunable parameter that can be adjusted. The fact that the 'write failed' message occurs before the 'upload complete' message would tend to support this. Can anyone suggest something I might try? -- Mark ^ permalink raw reply [flat|nested] 25+ messages in thread
* Re: DViCO FusionHDTV7 Dual Express I2C write failed 2011-01-10 2:14 ` DViCO FusionHDTV7 Dual Express I2C write failed Mark Zimmerman @ 2011-01-19 15:59 ` VDR User 2011-01-19 16:13 ` Devin Heitmueller 0 siblings, 1 reply; 25+ messages in thread From: VDR User @ 2011-01-19 15:59 UTC (permalink / raw) To: Mark Zimmerman; +Cc: linux-media On Sun, Jan 9, 2011 at 6:14 PM, Mark Zimmerman <markzimm@frii.com> wrote: >> I have a DViCO FusionHDTV7 Dual Express card that works with 2.6.35 but >> which fails to initialize with the latest 2.6.36 kernel. The firmware >> fails to load due to an i2c failure. A search of the archives indicates >> that this is not the first time this issue has occurred. >> >> What can I do to help get this problem fixed? >> >> Here is the dmesg from 2.6.35, for the two tuners: >> >> xc5000: waiting for firmware upload (dvb-fe-xc5000-1.6.114.fw)... >> xc5000: firmware read 12401 bytes. >> xc5000: firmware uploading... >> xc5000: firmware upload complete... >> xc5000: waiting for firmware upload (dvb-fe-xc5000-1.6.114.fw)... >> xc5000: firmware read 12401 bytes. >> xc5000: firmware uploading... >> xc5000: firmware upload complete.. >> >> and here is what happens with 2.6.36: >> >> xc5000: waiting for firmware upload (dvb-fe-xc5000-1.6.114.fw)... >> xc5000: firmware read 12401 bytes. >> xc5000: firmware uploading... >> xc5000: I2C write failed (len=3) >> xc5000: firmware upload complete... >> xc5000: Unable to initialise tuner >> xc5000: waiting for firmware upload (dvb-fe-xc5000-1.6.114.fw)... >> xc5000: firmware read 12401 bytes. >> xc5000: firmware uploading... >> xc5000: I2C write failed (len=3) >> xc5000: firmware upload complete... >> > > More information about this: I tried 2.6.37 (vanilla source from > kernel.org) and the problem persisted. So, I enabled these options: > CONFIG_I2C_DEBUG_CORE=y > CONFIG_I2C_DEBUG_ALGO=y > CONFIG_I2C_DEBUG_BUS=y > hoping to get more information but this time the firmware loaded > successfully and the tuner works properly. > > This leads me to suspect a race condition somewhere, or maybe a > tunable parameter that can be adjusted. The fact that the 'write > failed' message occurs before the 'upload complete' message would tend > to support this. Can anyone suggest something I might try? Can someone please look into this and possibly provide a fix for the bug? I'm surprised it hasn't happened yet after all this time but maybe it's been forgotten the bug existed. Thanks. ^ permalink raw reply [flat|nested] 25+ messages in thread
* Re: DViCO FusionHDTV7 Dual Express I2C write failed 2011-01-19 15:59 ` VDR User @ 2011-01-19 16:13 ` Devin Heitmueller 2011-01-19 17:22 ` VDR User 2011-01-19 19:01 ` Timothy D. Lenz 0 siblings, 2 replies; 25+ messages in thread From: Devin Heitmueller @ 2011-01-19 16:13 UTC (permalink / raw) To: VDR User; +Cc: Mark Zimmerman, linux-media On Wed, Jan 19, 2011 at 10:59 AM, VDR User <user.vdr@gmail.com> wrote: > Can someone please look into this and possibly provide a fix for the > bug? I'm surprised it hasn't happened yet after all this time but > maybe it's been forgotten the bug existed. You shouldn't be too surprised. In many cases device support for more obscure products comes not from the maintainer of the actual driver but rather from some random user who hacked in an additional board profile (in many cases, not doing it correctly but good enough so it "works for them"). In cases like that, the changes get committed, the original submitter disappears, and then when things break there is nobody with the appropriate knowledge and the hardware to debug the problem. Devin -- Devin J. Heitmueller - Kernel Labs http://www.kernellabs.com ^ permalink raw reply [flat|nested] 25+ messages in thread
* Re: DViCO FusionHDTV7 Dual Express I2C write failed 2011-01-19 16:13 ` Devin Heitmueller @ 2011-01-19 17:22 ` VDR User 2011-01-19 17:39 ` Mark Zimmerman 2011-01-19 19:01 ` Timothy D. Lenz 1 sibling, 1 reply; 25+ messages in thread From: VDR User @ 2011-01-19 17:22 UTC (permalink / raw) To: Devin Heitmueller; +Cc: Mark Zimmerman, linux-media On Wed, Jan 19, 2011 at 8:13 AM, Devin Heitmueller <dheitmueller@kernellabs.com> wrote: >> Can someone please look into this and possibly provide a fix for the >> bug? I'm surprised it hasn't happened yet after all this time but >> maybe it's been forgotten the bug existed. > > You shouldn't be too surprised. In many cases device support for more > obscure products comes not from the maintainer of the actual driver > but rather from some random user who hacked in an additional board > profile (in many cases, not doing it correctly but good enough so it > "works for them"). In cases like that, the changes get committed, the > original submitter disappears, and then when things break there is > nobody with the appropriate knowledge and the hardware to debug the > problem. Good point. My understanding is that this is a fairly common card so I wouldn't think that would be the case. At any rate, hopefully we'll be able to narrow down the cause of the problem and get it fixed. Thanks. ^ permalink raw reply [flat|nested] 25+ messages in thread
* Re: DViCO FusionHDTV7 Dual Express I2C write failed 2011-01-19 17:22 ` VDR User @ 2011-01-19 17:39 ` Mark Zimmerman 2011-01-24 15:49 ` Mark Zimmerman 0 siblings, 1 reply; 25+ messages in thread From: Mark Zimmerman @ 2011-01-19 17:39 UTC (permalink / raw) To: linux-media On Wed, Jan 19, 2011 at 09:22:28AM -0800, VDR User wrote: > On Wed, Jan 19, 2011 at 8:13 AM, Devin Heitmueller > <dheitmueller@kernellabs.com> wrote: > >> Can someone please look into this and possibly provide a fix for the > >> bug? ??I'm surprised it hasn't happened yet after all this time but > >> maybe it's been forgotten the bug existed. > > > > You shouldn't be too surprised. ??In many cases device support for more > > obscure products comes not from the maintainer of the actual driver > > but rather from some random user who hacked in an additional board > > profile (in many cases, not doing it correctly but good enough so it > > "works for them"). ??In cases like that, the changes get committed, the > > original submitter disappears, and then when things break there is > > nobody with the appropriate knowledge and the hardware to debug the > > problem. > > Good point. My understanding is that this is a fairly common card so > I wouldn't think that would be the case. At any rate, hopefully we'll > be able to narrow down the cause of the problem and get it fixed. > Were there changes to i2c between 2.6.35 and 2.6.36 that are missing from the xc5000 driver? If so, is there another driver that has the required updates so I can look at what changed? I would like to get some traction on this but I really don't know where to start. Thanks, -- Mark ^ permalink raw reply [flat|nested] 25+ messages in thread
* Re: DViCO FusionHDTV7 Dual Express I2C write failed 2011-01-19 17:39 ` Mark Zimmerman @ 2011-01-24 15:49 ` Mark Zimmerman 2011-01-24 15:57 ` Devin Heitmueller 0 siblings, 1 reply; 25+ messages in thread From: Mark Zimmerman @ 2011-01-24 15:49 UTC (permalink / raw) To: linux-media On Wed, Jan 19, 2011 at 10:39:46AM -0700, Mark Zimmerman wrote: > On Wed, Jan 19, 2011 at 09:22:28AM -0800, VDR User wrote: > > On Wed, Jan 19, 2011 at 8:13 AM, Devin Heitmueller > > <dheitmueller@kernellabs.com> wrote: > > >> Can someone please look into this and possibly provide a fix for the > > >> bug? ??I'm surprised it hasn't happened yet after all this time but > > >> maybe it's been forgotten the bug existed. > > > > > > You shouldn't be too surprised. ??In many cases device support for more > > > obscure products comes not from the maintainer of the actual driver > > > but rather from some random user who hacked in an additional board > > > profile (in many cases, not doing it correctly but good enough so it > > > "works for them"). ??In cases like that, the changes get committed, the > > > original submitter disappears, and then when things break there is > > > nobody with the appropriate knowledge and the hardware to debug the > > > problem. > > > > Good point. My understanding is that this is a fairly common card so > > I wouldn't think that would be the case. At any rate, hopefully we'll > > be able to narrow down the cause of the problem and get it fixed. > > > > Were there changes to i2c between 2.6.35 and 2.6.36 that are missing > from the xc5000 driver? If so, is there another driver that has the > required updates so I can look at what changed? I would like to get > some traction on this but I really don't know where to start. > >From looking at the code and a dump of the firmware file, the first i2c write would have a length of 3; so this error: xc5000: I2C write failed (len=3) tells me that there were probably no successful i2c transactions on this device. The i2c write call looks the same as that in other drivers, so I wonder if there is an initialization step that is now necessary but which is missing. Still hoping for suggestions... -- Mark ^ permalink raw reply [flat|nested] 25+ messages in thread
* Re: DViCO FusionHDTV7 Dual Express I2C write failed 2011-01-24 15:49 ` Mark Zimmerman @ 2011-01-24 15:57 ` Devin Heitmueller 2011-01-25 14:27 ` Mark Zimmerman 0 siblings, 1 reply; 25+ messages in thread From: Devin Heitmueller @ 2011-01-24 15:57 UTC (permalink / raw) To: Mark Zimmerman; +Cc: linux-media On Mon, Jan 24, 2011 at 10:49 AM, Mark Zimmerman <markzimm@frii.com> wrote: > From looking at the code and a dump of the firmware file, the first > i2c write would have a length of 3; so this error: > > xc5000: I2C write failed (len=3) > > tells me that there were probably no successful i2c transactions on > this device. The i2c write call looks the same as that in other > drivers, so I wonder if there is an initialization step that is now > necessary but which is missing. > > Still hoping for suggestions... My guess would be that somebody screwed up either the GPIO config int the cx88 board profile, or the i2c gate, which is resulting in not being able to reach the tuner at all. Do you have an oscilloscope? If so, I bet you will find that the xc5000 pin is being held in reset. I would probably take a hard look at the board profile in cx88-cards.c as well as whether there have been any changes to the GPIO setup and power management code. Devin -- Devin J. Heitmueller - Kernel Labs http://www.kernellabs.com ^ permalink raw reply [flat|nested] 25+ messages in thread
* Re: DViCO FusionHDTV7 Dual Express I2C write failed 2011-01-24 15:57 ` Devin Heitmueller @ 2011-01-25 14:27 ` Mark Zimmerman 0 siblings, 0 replies; 25+ messages in thread From: Mark Zimmerman @ 2011-01-25 14:27 UTC (permalink / raw) To: linux-media; +Cc: Devin Heitmueller On Mon, Jan 24, 2011 at 10:57:02AM -0500, Devin Heitmueller wrote: > On Mon, Jan 24, 2011 at 10:49 AM, Mark Zimmerman <markzimm@frii.com> wrote: > > From looking at the code and a dump of the firmware file, the first > > i2c write would have a length of 3; so this error: > > > > xc5000: I2C write failed (len=3) > > > > tells me that there were probably no successful i2c transactions on > > this device. The i2c write call looks the same as that in other > > drivers, so I wonder if there is an initialization step that is now > > necessary but which is missing. > > > > Still hoping for suggestions... > > My guess would be that somebody screwed up either the GPIO config int > the cx88 board profile, or the i2c gate, which is resulting in not > being able to reach the tuner at all. > > Do you have an oscilloscope? If so, I bet you will find that the > xc5000 pin is being held in reset. If I had an oscilloscope I probably wouldn't know where to stick the probe. > > I would probably take a hard look at the board profile in cx88-cards.c > as well as whether there have been any changes to the GPIO setup and > power management code. cx23885-cards.c, actually. I'll see what I can find in there. Thanks, -- Mark ^ permalink raw reply [flat|nested] 25+ messages in thread
* Re: DViCO FusionHDTV7 Dual Express I2C write failed 2011-01-19 16:13 ` Devin Heitmueller 2011-01-19 17:22 ` VDR User @ 2011-01-19 19:01 ` Timothy D. Lenz 1 sibling, 0 replies; 25+ messages in thread From: Timothy D. Lenz @ 2011-01-19 19:01 UTC (permalink / raw) To: linux-media So what would a "mainstream" dual (or more) tuner card be? I've found these Fusions to be flaky. Had one die and another went flaky when I enabled the sleep mode. Can't really afford any more now, but am always watching. A company called Ceton seems to havea quad, but it's a cable card tuner costing $450. On 1/19/2011 9:13 AM, Devin Heitmueller wrote: > On Wed, Jan 19, 2011 at 10:59 AM, VDR User<user.vdr@gmail.com> wrote: >> Can someone please look into this and possibly provide a fix for the >> bug? I'm surprised it hasn't happened yet after all this time but >> maybe it's been forgotten the bug existed. > > You shouldn't be too surprised. In many cases device support for more > obscure products comes not from the maintainer of the actual driver > but rather from some random user who hacked in an additional board > profile (in many cases, not doing it correctly but good enough so it > "works for them"). In cases like that, the changes get committed, the > original submitter disappears, and then when things break there is > nobody with the appropriate knowledge and the hardware to debug the > problem. > > Devin > ^ permalink raw reply [flat|nested] 25+ messages in thread
* Re: DViCO FusionHDTV7 Dual Express I2C write failed [not found] <20101207190753.GA21666@io.frii.com> 2011-01-10 2:14 ` DViCO FusionHDTV7 Dual Express I2C write failed Mark Zimmerman @ 2011-01-17 23:12 ` Timothy D. Lenz 2011-02-12 15:29 ` [get-bisect results]: " Mark Zimmerman 2 siblings, 0 replies; 25+ messages in thread From: Timothy D. Lenz @ 2011-01-17 23:12 UTC (permalink / raw) To: linux-media I just tried to update from kernel 2.6.34 and in doing so had to switch to git for v4l. I noticed the chip in this this post and saved it to look at latter. now I'm glad I did. I ran into the same problem. Driver seems to load ok, but when I try to start vdr I get thet same messages in syslog. Jan 16 21:50:48 LLLx64-32 vdr: [6170] saved setup to /usr/local/dvb/VDR/config/setup.conf Jan 16 21:50:49 LLLx64-32 kernel: xc5000: waiting for firmware upload (dvb-fe-xc5000-1.6.114.fw)... Jan 16 21:50:49 LLLx64-32 kernel: xc5000: firmware read 12401 bytes. Jan 16 21:50:49 LLLx64-32 kernel: xc5000: firmware uploading... Jan 16 21:50:49 LLLx64-32 vdr: [6176] section handler thread ended (pid=6170, tid=6176) Jan 16 21:50:49 LLLx64-32 kernel: xc5000: I2C write failed (len=3) Jan 16 21:50:49 LLLx64-32 kernel: xc5000: firmware upload complete... Jan 16 21:50:50 LLLx64-32 vdr: [6175] tuner on frontend 0/0 thread ended (pid=6170, tid=6175) Jan 16 21:50:50 LLLx64-32 kernel: xc5000: waiting for firmware upload (dvb-fe-xc5000-1.6.114.fw)... Jan 16 21:50:50 LLLx64-32 kernel: xc5000: firmware read 12401 bytes. Jan 16 21:50:50 LLLx64-32 kernel: xc5000: firmware uploading... Jan 16 21:50:50 LLLx64-32 vdr: [6174] CI adapter on device 0 thread ended (pid=6170, tid=6174) ....... On 12/7/2010 12:07 PM, Mark Zimmerman wrote: > Greetings: > > I have a DViCO FusionHDTV7 Dual Express card that works with 2.6.35 but > which fails to initialize with the latest 2.6.36 kernel. The firmware > fails to load due to an i2c failure. A search of the archives indicates > that this is not the first time this issue has occurred. > > What can I do to help get this problem fixed? > > Here is the dmesg from 2.6.35, for the two tuners: > > xc5000: waiting for firmware upload (dvb-fe-xc5000-1.6.114.fw)... > xc5000: firmware read 12401 bytes. > xc5000: firmware uploading... > xc5000: firmware upload complete... > xc5000: waiting for firmware upload (dvb-fe-xc5000-1.6.114.fw)... > xc5000: firmware read 12401 bytes. > xc5000: firmware uploading... > xc5000: firmware upload complete.. > > and here is what happens with 2.6.36: > > xc5000: waiting for firmware upload (dvb-fe-xc5000-1.6.114.fw)... > xc5000: firmware read 12401 bytes. > xc5000: firmware uploading... > xc5000: I2C write failed (len=3) > xc5000: firmware upload complete... > xc5000: Unable to initialise tuner > xc5000: waiting for firmware upload (dvb-fe-xc5000-1.6.114.fw)... > xc5000: firmware read 12401 bytes. > xc5000: firmware uploading... > xc5000: I2C write failed (len=3) > xc5000: firmware upload complete... > > -- Mark > -- > 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 > ^ permalink raw reply [flat|nested] 25+ messages in thread
* [get-bisect results]: DViCO FusionHDTV7 Dual Express I2C write failed [not found] <20101207190753.GA21666@io.frii.com> 2011-01-10 2:14 ` DViCO FusionHDTV7 Dual Express I2C write failed Mark Zimmerman 2011-01-17 23:12 ` Timothy D. Lenz @ 2011-02-12 15:29 ` Mark Zimmerman 2011-02-12 16:27 ` Andy Walls 2011-02-13 14:47 ` [corrected get-bisect " Mark Zimmerman 2 siblings, 2 replies; 25+ messages in thread From: Mark Zimmerman @ 2011-02-12 15:29 UTC (permalink / raw) To: linux-media; +Cc: Jarod Wilson On Tue, Dec 07, 2010 at 12:07:53PM -0700, Mark Zimmerman wrote: > Greetings: > > I have a DViCO FusionHDTV7 Dual Express card that works with 2.6.35 but > which fails to initialize with the latest 2.6.36 kernel. The firmware > fails to load due to an i2c failure. A search of the archives indicates > that this is not the first time this issue has occurred. > > What can I do to help get this problem fixed? > > Here is the dmesg from 2.6.35, for the two tuners: > > xc5000: waiting for firmware upload (dvb-fe-xc5000-1.6.114.fw)... > xc5000: firmware read 12401 bytes. > xc5000: firmware uploading... > xc5000: firmware upload complete... > xc5000: waiting for firmware upload (dvb-fe-xc5000-1.6.114.fw)... > xc5000: firmware read 12401 bytes. > xc5000: firmware uploading... > xc5000: firmware upload complete.. > > and here is what happens with 2.6.36: > > xc5000: waiting for firmware upload (dvb-fe-xc5000-1.6.114.fw)... > xc5000: firmware read 12401 bytes. > xc5000: firmware uploading... > xc5000: I2C write failed (len=3) > xc5000: firmware upload complete... > xc5000: Unable to initialise tuner > xc5000: waiting for firmware upload (dvb-fe-xc5000-1.6.114.fw)... > xc5000: firmware read 12401 bytes. > xc5000: firmware uploading... > xc5000: I2C write failed (len=3) > xc5000: firmware upload complete... > I did a git bisect on this and finally reached the end of the line. Here is what it said: qpc$ git bisect bad 82ce67bf262b3f47ecb5a0ca31cace8ac72b7c98 is the first bad commit commit 82ce67bf262b3f47ecb5a0ca31cace8ac72b7c98 Author: Jarod Wilson <jarod@redhat.com> Date: Thu Jul 29 18:20:44 2010 -0300 V4L/DVB: staging/lirc: fix non-CONFIG_MODULES build horkage Fix when CONFIG_MODULES is not enabled: drivers/staging/lirc/lirc_parallel.c:243: error: implicit declaration of function 'module_refcount' drivers/staging/lirc/lirc_it87.c:150: error: implicit declaration of function 'module_refcount' drivers/built-in.o: In function `it87_probe': lirc_it87.c:(.text+0x4079b0): undefined reference to `init_chrdev' lirc_it87.c:(.text+0x4079cc): undefined reference to `drop_chrdev' drivers/built-in.o: In function `lirc_it87_exit': lirc_it87.c:(.exit.text+0x38a5): undefined reference to `drop_chrdev' Its a quick hack and untested beyond building, since I don't have the hardware, but it should do the trick. Acked-by: Randy Dunlap <randy.dunlap@oracle.com> Signed-off-by: Jarod Wilson <jarod@redhat.com> Signed-off-by: Mauro Carvalho Chehab <mchehab@redhat.com> :040000 040000 f645b46a07b7ff87a2c11ac9296a5ff56e89a0d0 49e50945ccf8e1c8567c049908890d2752443b72 M drivers ^ permalink raw reply [flat|nested] 25+ messages in thread
* Re: [get-bisect results]: DViCO FusionHDTV7 Dual Express I2C write failed 2011-02-12 15:29 ` [get-bisect results]: " Mark Zimmerman @ 2011-02-12 16:27 ` Andy Walls 2011-02-12 16:36 ` Mark Zimmerman 2011-02-13 14:47 ` [corrected get-bisect " Mark Zimmerman 1 sibling, 1 reply; 25+ messages in thread From: Andy Walls @ 2011-02-12 16:27 UTC (permalink / raw) To: Mark Zimmerman; +Cc: linux-media, Jarod Wilson On Sat, 2011-02-12 at 08:29 -0700, Mark Zimmerman wrote: > On Tue, Dec 07, 2010 at 12:07:53PM -0700, Mark Zimmerman wrote: > > Greetings: > > > > I have a DViCO FusionHDTV7 Dual Express card that works with 2.6.35 but > > which fails to initialize with the latest 2.6.36 kernel. The firmware > > fails to load due to an i2c failure. A search of the archives indicates > > that this is not the first time this issue has occurred. > > > > What can I do to help get this problem fixed? > > > > Here is the dmesg from 2.6.35, for the two tuners: > > > > xc5000: waiting for firmware upload (dvb-fe-xc5000-1.6.114.fw)... > > xc5000: firmware read 12401 bytes. > > xc5000: firmware uploading... > > xc5000: firmware upload complete... > > xc5000: waiting for firmware upload (dvb-fe-xc5000-1.6.114.fw)... > > xc5000: firmware read 12401 bytes. > > xc5000: firmware uploading... > > xc5000: firmware upload complete.. > > > > and here is what happens with 2.6.36: > > > > xc5000: waiting for firmware upload (dvb-fe-xc5000-1.6.114.fw)... > > xc5000: firmware read 12401 bytes. > > xc5000: firmware uploading... > > xc5000: I2C write failed (len=3) > > xc5000: firmware upload complete... > > xc5000: Unable to initialise tuner > > xc5000: waiting for firmware upload (dvb-fe-xc5000-1.6.114.fw)... > > xc5000: firmware read 12401 bytes. > > xc5000: firmware uploading... > > xc5000: I2C write failed (len=3) > > xc5000: firmware upload complete... > > > > I did a git bisect on this and finally reached the end of the line. > Here is what it said: > > qpc$ git bisect bad > 82ce67bf262b3f47ecb5a0ca31cace8ac72b7c98 is the first bad commit > commit 82ce67bf262b3f47ecb5a0ca31cace8ac72b7c98 > Author: Jarod Wilson <jarod@redhat.com> > Date: Thu Jul 29 18:20:44 2010 -0300 > > V4L/DVB: staging/lirc: fix non-CONFIG_MODULES build horkage > > Fix when CONFIG_MODULES is not enabled: > > drivers/staging/lirc/lirc_parallel.c:243: error: implicit declaration of function 'module_refcount' > drivers/staging/lirc/lirc_it87.c:150: error: implicit declaration of function 'module_refcount' > drivers/built-in.o: In function `it87_probe': > lirc_it87.c:(.text+0x4079b0): undefined reference to `init_chrdev' > lirc_it87.c:(.text+0x4079cc): undefined reference to `drop_chrdev' > drivers/built-in.o: In function `lirc_it87_exit': > lirc_it87.c:(.exit.text+0x38a5): undefined reference to `drop_chrdev' > > Its a quick hack and untested beyond building, since I don't have the > hardware, but it should do the trick. > > Acked-by: Randy Dunlap <randy.dunlap@oracle.com> > Signed-off-by: Jarod Wilson <jarod@redhat.com> > Signed-off-by: Mauro Carvalho Chehab <mchehab@redhat.com> > > :040000 040000 f645b46a07b7ff87a2c11ac9296a5ff56e89a0d0 49e50945ccf8e1c8567c049908890d2752443b72 M drivers Hmm. git log --patch 82ce67bf262b3f47ecb5a0ca31cace8ac72b7c98 shows the commit is completely unrealted. Please try and see if things are good or bad at commit 18a87becf85d50e7f3d547f1b7a75108b151374d: commit 18a87becf85d50e7f3d547f1b7a75108b151374d Author: Jean Delvare <khali@linux-fr.org> Date: Sun Jul 18 17:05:17 2010 -0300 V4L/DVB: cx23885: i2c_wait_done returns 0 or 1, don't check for < 0 return v Function i2c_wait_done() never returns negative values, so there is no point in checking for them. Signed-off-by: Jean Delvare <khali@linux-fr.org> Signed-off-by: Andy Walls <awalls@md.metrocast.net> Signed-off-by: Mauro Carvalho Chehab <mchehab@redhat.com> Which is the first commit, prior to the one you found, that seems to me to have any direct bearing to I2C transactions. If that commit is good, then these commits in between would be my next likely suspects: e5514f104d875b3d28cbcd5d4f2b96ab2fca1e29 dbe83a3b921328e12b2abe894fc692afba293d7f Regards, Andy > -- > 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 ^ permalink raw reply [flat|nested] 25+ messages in thread
* Re: [get-bisect results]: DViCO FusionHDTV7 Dual Express I2C write failed 2011-02-12 16:27 ` Andy Walls @ 2011-02-12 16:36 ` Mark Zimmerman 2011-02-12 16:46 ` Andy Walls 0 siblings, 1 reply; 25+ messages in thread From: Mark Zimmerman @ 2011-02-12 16:36 UTC (permalink / raw) To: Andy Walls; +Cc: linux-media, Jarod Wilson On Sat, Feb 12, 2011 at 11:27:27AM -0500, Andy Walls wrote: > On Sat, 2011-02-12 at 08:29 -0700, Mark Zimmerman wrote: > > On Tue, Dec 07, 2010 at 12:07:53PM -0700, Mark Zimmerman wrote: > > > Greetings: > > > > > > I have a DViCO FusionHDTV7 Dual Express card that works with 2.6.35 but > > > which fails to initialize with the latest 2.6.36 kernel. The firmware > > > fails to load due to an i2c failure. A search of the archives indicates > > > that this is not the first time this issue has occurred. > > > > > > What can I do to help get this problem fixed? > > > > > > Here is the dmesg from 2.6.35, for the two tuners: > > > > > > xc5000: waiting for firmware upload (dvb-fe-xc5000-1.6.114.fw)... > > > xc5000: firmware read 12401 bytes. > > > xc5000: firmware uploading... > > > xc5000: firmware upload complete... > > > xc5000: waiting for firmware upload (dvb-fe-xc5000-1.6.114.fw)... > > > xc5000: firmware read 12401 bytes. > > > xc5000: firmware uploading... > > > xc5000: firmware upload complete.. > > > > > > and here is what happens with 2.6.36: > > > > > > xc5000: waiting for firmware upload (dvb-fe-xc5000-1.6.114.fw)... > > > xc5000: firmware read 12401 bytes. > > > xc5000: firmware uploading... > > > xc5000: I2C write failed (len=3) > > > xc5000: firmware upload complete... > > > xc5000: Unable to initialise tuner > > > xc5000: waiting for firmware upload (dvb-fe-xc5000-1.6.114.fw)... > > > xc5000: firmware read 12401 bytes. > > > xc5000: firmware uploading... > > > xc5000: I2C write failed (len=3) > > > xc5000: firmware upload complete... > > > > > > > I did a git bisect on this and finally reached the end of the line. > > Here is what it said: > > > > qpc$ git bisect bad > > 82ce67bf262b3f47ecb5a0ca31cace8ac72b7c98 is the first bad commit > > commit 82ce67bf262b3f47ecb5a0ca31cace8ac72b7c98 > > Author: Jarod Wilson <jarod@redhat.com> > > Date: Thu Jul 29 18:20:44 2010 -0300 > > > > V4L/DVB: staging/lirc: fix non-CONFIG_MODULES build horkage > > > > Fix when CONFIG_MODULES is not enabled: > > > > drivers/staging/lirc/lirc_parallel.c:243: error: implicit declaration of function 'module_refcount' > > drivers/staging/lirc/lirc_it87.c:150: error: implicit declaration of function 'module_refcount' > > drivers/built-in.o: In function `it87_probe': > > lirc_it87.c:(.text+0x4079b0): undefined reference to `init_chrdev' > > lirc_it87.c:(.text+0x4079cc): undefined reference to `drop_chrdev' > > drivers/built-in.o: In function `lirc_it87_exit': > > lirc_it87.c:(.exit.text+0x38a5): undefined reference to `drop_chrdev' > > > > Its a quick hack and untested beyond building, since I don't have the > > hardware, but it should do the trick. > > > > Acked-by: Randy Dunlap <randy.dunlap@oracle.com> > > Signed-off-by: Jarod Wilson <jarod@redhat.com> > > Signed-off-by: Mauro Carvalho Chehab <mchehab@redhat.com> > > > > :040000 040000 f645b46a07b7ff87a2c11ac9296a5ff56e89a0d0 49e50945ccf8e1c8567c049908890d2752443b72 M drivers > > Hmm. git log --patch 82ce67bf262b3f47ecb5a0ca31cace8ac72b7c98 shows the > commit is completely unrealted. > > Please try and see if things are good or bad at commit > 18a87becf85d50e7f3d547f1b7a75108b151374d: > > commit 18a87becf85d50e7f3d547f1b7a75108b151374d > Author: Jean Delvare <khali@linux-fr.org> > Date: Sun Jul 18 17:05:17 2010 -0300 > > V4L/DVB: cx23885: i2c_wait_done returns 0 or 1, don't check for < 0 return v > > Function i2c_wait_done() never returns negative values, so there is no > point in checking for them. > > Signed-off-by: Jean Delvare <khali@linux-fr.org> > Signed-off-by: Andy Walls <awalls@md.metrocast.net> > Signed-off-by: Mauro Carvalho Chehab <mchehab@redhat.com> > > Which is the first commit, prior to the one you found, that seems to me > to have any direct bearing to I2C transactions. > > If that commit is good, then these commits in between would be my next > likely suspects: > e5514f104d875b3d28cbcd5d4f2b96ab2fca1e29 > dbe83a3b921328e12b2abe894fc692afba293d7f > > Regards, > Andy > Sorry to require so much hand holding, but I am new to all of this git gymnastics. Would you mind sending me the correct git command to get to a specific commit? Also, do I need to do a bisect reset? Thanks, -- Mark ^ permalink raw reply [flat|nested] 25+ messages in thread
* Re: [get-bisect results]: DViCO FusionHDTV7 Dual Express I2C write failed 2011-02-12 16:36 ` Mark Zimmerman @ 2011-02-12 16:46 ` Andy Walls 2011-02-12 17:03 ` Mark Zimmerman 2011-02-12 19:05 ` Mark Zimmerman 0 siblings, 2 replies; 25+ messages in thread From: Andy Walls @ 2011-02-12 16:46 UTC (permalink / raw) To: Mark Zimmerman; +Cc: linux-media, Jarod Wilson On Sat, 2011-02-12 at 09:36 -0700, Mark Zimmerman wrote: > On Sat, Feb 12, 2011 at 11:27:27AM -0500, Andy Walls wrote: > > On Sat, 2011-02-12 at 08:29 -0700, Mark Zimmerman wrote: > > > On Tue, Dec 07, 2010 at 12:07:53PM -0700, Mark Zimmerman wrote: > > > > Greetings: > > > > > > > > I have a DViCO FusionHDTV7 Dual Express card that works with 2.6.35 but > > > > which fails to initialize with the latest 2.6.36 kernel. The firmware > > > > fails to load due to an i2c failure. A search of the archives indicates > > > > that this is not the first time this issue has occurred. > > > > > > > > What can I do to help get this problem fixed? > > > > > > > > Here is the dmesg from 2.6.35, for the two tuners: > > > > > > > > xc5000: waiting for firmware upload (dvb-fe-xc5000-1.6.114.fw)... > > > > xc5000: firmware read 12401 bytes. > > > > xc5000: firmware uploading... > > > > xc5000: firmware upload complete... > > > > xc5000: waiting for firmware upload (dvb-fe-xc5000-1.6.114.fw)... > > > > xc5000: firmware read 12401 bytes. > > > > xc5000: firmware uploading... > > > > xc5000: firmware upload complete.. > > > > > > > > and here is what happens with 2.6.36: > > > > > > > > xc5000: waiting for firmware upload (dvb-fe-xc5000-1.6.114.fw)... > > > > xc5000: firmware read 12401 bytes. > > > > xc5000: firmware uploading... > > > > xc5000: I2C write failed (len=3) > > > > xc5000: firmware upload complete... > > > > xc5000: Unable to initialise tuner > > > > xc5000: waiting for firmware upload (dvb-fe-xc5000-1.6.114.fw)... > > > > xc5000: firmware read 12401 bytes. > > > > xc5000: firmware uploading... > > > > xc5000: I2C write failed (len=3) > > > > xc5000: firmware upload complete... > > > > > > > > > > I did a git bisect on this and finally reached the end of the line. > > > Here is what it said: > > > > > > qpc$ git bisect bad > > > 82ce67bf262b3f47ecb5a0ca31cace8ac72b7c98 is the first bad commit > > > commit 82ce67bf262b3f47ecb5a0ca31cace8ac72b7c98 > > > Author: Jarod Wilson <jarod@redhat.com> > > > Date: Thu Jul 29 18:20:44 2010 -0300 > > > > > > V4L/DVB: staging/lirc: fix non-CONFIG_MODULES build horkage > > > > > > Fix when CONFIG_MODULES is not enabled: > > > > > > drivers/staging/lirc/lirc_parallel.c:243: error: implicit declaration of function 'module_refcount' > > > drivers/staging/lirc/lirc_it87.c:150: error: implicit declaration of function 'module_refcount' > > > drivers/built-in.o: In function `it87_probe': > > > lirc_it87.c:(.text+0x4079b0): undefined reference to `init_chrdev' > > > lirc_it87.c:(.text+0x4079cc): undefined reference to `drop_chrdev' > > > drivers/built-in.o: In function `lirc_it87_exit': > > > lirc_it87.c:(.exit.text+0x38a5): undefined reference to `drop_chrdev' > > > > > > Its a quick hack and untested beyond building, since I don't have the > > > hardware, but it should do the trick. > > > > > > Acked-by: Randy Dunlap <randy.dunlap@oracle.com> > > > Signed-off-by: Jarod Wilson <jarod@redhat.com> > > > Signed-off-by: Mauro Carvalho Chehab <mchehab@redhat.com> > > > > > > :040000 040000 f645b46a07b7ff87a2c11ac9296a5ff56e89a0d0 49e50945ccf8e1c8567c049908890d2752443b72 M drivers > > > > Hmm. git log --patch 82ce67bf262b3f47ecb5a0ca31cace8ac72b7c98 shows the > > commit is completely unrealted. > > > > Please try and see if things are good or bad at commit > > 18a87becf85d50e7f3d547f1b7a75108b151374d: > > > > commit 18a87becf85d50e7f3d547f1b7a75108b151374d > > Author: Jean Delvare <khali@linux-fr.org> > > Date: Sun Jul 18 17:05:17 2010 -0300 > > > > V4L/DVB: cx23885: i2c_wait_done returns 0 or 1, don't check for < 0 return v > > > > Function i2c_wait_done() never returns negative values, so there is no > > point in checking for them. > > > > Signed-off-by: Jean Delvare <khali@linux-fr.org> > > Signed-off-by: Andy Walls <awalls@md.metrocast.net> > > Signed-off-by: Mauro Carvalho Chehab <mchehab@redhat.com> > > > > Which is the first commit, prior to the one you found, that seems to me > > to have any direct bearing to I2C transactions. > > > > If that commit is good, then these commits in between would be my next > > likely suspects: > > e5514f104d875b3d28cbcd5d4f2b96ab2fca1e29 > > dbe83a3b921328e12b2abe894fc692afba293d7f > > > > Regards, > > Andy > > > > Sorry to require so much hand holding, but I am new to all of this git > gymnastics. Would you mind sending me the correct git command to get > to a specific commit? It should just be $ git checkout 18a87becf85d50e7f3d547f1b7a75108b151374d or whatever the commit number git log shows you for the change I suspect is the problem. > Also, do I need to do a bisect reset? I wouldn't reset the git bisect yet. If you test a commit and it is good, you will want to mark it with 'git bisect good <commit-hash>', and if it is bad, you will want to mark it with 'git bisect bad <commit-hash>' BTW, can you provide the output of 'git bisect log' ? Regards, Andy ^ permalink raw reply [flat|nested] 25+ messages in thread
* Re: [get-bisect results]: DViCO FusionHDTV7 Dual Express I2C write failed 2011-02-12 16:46 ` Andy Walls @ 2011-02-12 17:03 ` Mark Zimmerman 2011-02-12 19:05 ` Mark Zimmerman 1 sibling, 0 replies; 25+ messages in thread From: Mark Zimmerman @ 2011-02-12 17:03 UTC (permalink / raw) To: Andy Walls; +Cc: linux-media, Jarod Wilson On Sat, Feb 12, 2011 at 11:46:13AM -0500, Andy Walls wrote: > On Sat, 2011-02-12 at 09:36 -0700, Mark Zimmerman wrote: > > On Sat, Feb 12, 2011 at 11:27:27AM -0500, Andy Walls wrote: > > > On Sat, 2011-02-12 at 08:29 -0700, Mark Zimmerman wrote: > > > > On Tue, Dec 07, 2010 at 12:07:53PM -0700, Mark Zimmerman wrote: > > > > > Greetings: > > > > > > > > > > I have a DViCO FusionHDTV7 Dual Express card that works with 2.6.35 but > > > > > which fails to initialize with the latest 2.6.36 kernel. The firmware > > > > > fails to load due to an i2c failure. A search of the archives indicates > > > > > that this is not the first time this issue has occurred. > > > > > > > > > > What can I do to help get this problem fixed? > > > > > > > > > > Here is the dmesg from 2.6.35, for the two tuners: > > > > > > > > > > xc5000: waiting for firmware upload (dvb-fe-xc5000-1.6.114.fw)... > > > > > xc5000: firmware read 12401 bytes. > > > > > xc5000: firmware uploading... > > > > > xc5000: firmware upload complete... > > > > > xc5000: waiting for firmware upload (dvb-fe-xc5000-1.6.114.fw)... > > > > > xc5000: firmware read 12401 bytes. > > > > > xc5000: firmware uploading... > > > > > xc5000: firmware upload complete.. > > > > > > > > > > and here is what happens with 2.6.36: > > > > > > > > > > xc5000: waiting for firmware upload (dvb-fe-xc5000-1.6.114.fw)... > > > > > xc5000: firmware read 12401 bytes. > > > > > xc5000: firmware uploading... > > > > > xc5000: I2C write failed (len=3) > > > > > xc5000: firmware upload complete... > > > > > xc5000: Unable to initialise tuner > > > > > xc5000: waiting for firmware upload (dvb-fe-xc5000-1.6.114.fw)... > > > > > xc5000: firmware read 12401 bytes. > > > > > xc5000: firmware uploading... > > > > > xc5000: I2C write failed (len=3) > > > > > xc5000: firmware upload complete... > > > > > > > > > > > > > I did a git bisect on this and finally reached the end of the line. > > > > Here is what it said: > > > > > > > > qpc$ git bisect bad > > > > 82ce67bf262b3f47ecb5a0ca31cace8ac72b7c98 is the first bad commit > > > > commit 82ce67bf262b3f47ecb5a0ca31cace8ac72b7c98 > > > > Author: Jarod Wilson <jarod@redhat.com> > > > > Date: Thu Jul 29 18:20:44 2010 -0300 > > > > > > > > V4L/DVB: staging/lirc: fix non-CONFIG_MODULES build horkage > > > > > > > > Fix when CONFIG_MODULES is not enabled: > > > > > > > > drivers/staging/lirc/lirc_parallel.c:243: error: implicit declaration of function 'module_refcount' > > > > drivers/staging/lirc/lirc_it87.c:150: error: implicit declaration of function 'module_refcount' > > > > drivers/built-in.o: In function `it87_probe': > > > > lirc_it87.c:(.text+0x4079b0): undefined reference to `init_chrdev' > > > > lirc_it87.c:(.text+0x4079cc): undefined reference to `drop_chrdev' > > > > drivers/built-in.o: In function `lirc_it87_exit': > > > > lirc_it87.c:(.exit.text+0x38a5): undefined reference to `drop_chrdev' > > > > > > > > Its a quick hack and untested beyond building, since I don't have the > > > > hardware, but it should do the trick. > > > > > > > > Acked-by: Randy Dunlap <randy.dunlap@oracle.com> > > > > Signed-off-by: Jarod Wilson <jarod@redhat.com> > > > > Signed-off-by: Mauro Carvalho Chehab <mchehab@redhat.com> > > > > > > > > :040000 040000 f645b46a07b7ff87a2c11ac9296a5ff56e89a0d0 49e50945ccf8e1c8567c049908890d2752443b72 M drivers > > > > > > Hmm. git log --patch 82ce67bf262b3f47ecb5a0ca31cace8ac72b7c98 shows the > > > commit is completely unrealted. > > > > > > Please try and see if things are good or bad at commit > > > 18a87becf85d50e7f3d547f1b7a75108b151374d: > > > > > > commit 18a87becf85d50e7f3d547f1b7a75108b151374d > > > Author: Jean Delvare <khali@linux-fr.org> > > > Date: Sun Jul 18 17:05:17 2010 -0300 > > > > > > V4L/DVB: cx23885: i2c_wait_done returns 0 or 1, don't check for < 0 return v > > > > > > Function i2c_wait_done() never returns negative values, so there is no > > > point in checking for them. > > > > > > Signed-off-by: Jean Delvare <khali@linux-fr.org> > > > Signed-off-by: Andy Walls <awalls@md.metrocast.net> > > > Signed-off-by: Mauro Carvalho Chehab <mchehab@redhat.com> > > > > > > Which is the first commit, prior to the one you found, that seems to me > > > to have any direct bearing to I2C transactions. > > > > > > If that commit is good, then these commits in between would be my next > > > likely suspects: > > > e5514f104d875b3d28cbcd5d4f2b96ab2fca1e29 > > > dbe83a3b921328e12b2abe894fc692afba293d7f > > > > > > Regards, > > > Andy > > > > > > > Sorry to require so much hand holding, but I am new to all of this git > > gymnastics. Would you mind sending me the correct git command to get > > to a specific commit? > > It should just be > > $ git checkout 18a87becf85d50e7f3d547f1b7a75108b151374d > > or whatever the commit number git log shows you for the change I suspect > is the problem. > > > > Also, do I need to do a bisect reset? > > I wouldn't reset the git bisect yet. If you test a commit and it is > good, you will want to mark it with 'git bisect good <commit-hash>', and > if it is bad, you will want to mark it with 'git bisect bad > <commit-hash>' > > BTW, can you provide the output of 'git bisect log' ? > I suspect I know why the bisect process went astray. Early on, I was unable to get a successful build because of mismatch errors. Turning off CONFIG_STAGING fixed this. If most of the changes were related to staging then the bisect could have skipped the relevant change. Note the unlikely string of 5 bad ones in a row at the end. Here is the log: git bisect start # good: [9fe6206f400646a2322096b56c59891d530e8d51] Linux 2.6.35 git bisect good 9fe6206f400646a2322096b56c59891d530e8d51 # bad: [f6f94e2ab1b33f0082ac22d71f66385a60d8157f] Linux 2.6.36 git bisect bad f6f94e2ab1b33f0082ac22d71f66385a60d8157f # good: [78417334b5cb6e1f915b8fdcc4fce3f1a1b4420c] Merge branch 'bkl/core' of git://git.kernel.org/pub/scm/linux/kernel/git/frederic/random-tracing git bisect good 78417334b5cb6e1f915b8fdcc4fce3f1a1b4420c # bad: [14a4fa20a10d76eb98b7feb25be60735217929ba] Merge branch 'for-linus' of git://git.kernel.org/pub/scm/linux/kernel/git/tiwai/sound-2.6 git bisect bad 14a4fa20a10d76eb98b7feb25be60735217929ba # good: [8196867c74890ccdf40a2b5e3e173597fbc4f9ac] Merge branch 'for-linus' of git://git.kernel.org/pub/scm/linux/kernel/git/bcopeland/omfs git bisect good 8196867c74890ccdf40a2b5e3e173597fbc4f9ac # bad: [3d30701b58970425e1d45994d6cb82f828924fdd] Merge branch 'for-linus' of git://neil.brown.name/md git bisect bad 3d30701b58970425e1d45994d6cb82f828924fdd # good: [9895850b23886e030cd1e7241d5529a57e969c3d] Merge git://git.kernel.org/pub/scm/linux/kernel/git/gregkh/usb-2.6 git bisect good 9895850b23886e030cd1e7241d5529a57e969c3d # good: [de75d60d5ea235e6e09f4962ab22541ce0fe176a] block: make sure that REQ_* types are seen even with CONFIG_BLOCK=n git bisect good de75d60d5ea235e6e09f4962ab22541ce0fe176a # bad: [6dd5aff3cab284556952d96f1112b17299e126d8] V4L/DVB: v4l2-ctrls: Whitespace cleanups git bisect bad 6dd5aff3cab284556952d96f1112b17299e126d8 # good: [efce8ca3c5d8a35018f801d687396e1911cfc868] V4L/DVB: staging/lirc: fix Kconfig dependencies git bisect good efce8ca3c5d8a35018f801d687396e1911cfc868 # bad: [9bde9f263e958b0d588aada03854fcc0f0c88b86] V4L/DVB: uvcvideo: Drop corrupted compressed frames git bisect bad 9bde9f263e958b0d588aada03854fcc0f0c88b86 # bad: [39b2c0687b238d8bce19d5e8c0c8dc4e7fe50ed4] V4L/DVB: IR: JVC: make repeat work git bisect bad 39b2c0687b238d8bce19d5e8c0c8dc4e7fe50ed4 # bad: [2c1101d5aeddda7bd0dd03bddea7aed6dbf80074] V4L/DVB: IR: put newly ported streamzap driver in proper home git bisect bad 2c1101d5aeddda7bd0dd03bddea7aed6dbf80074 # bad: [7c294402d58e22bb760c0e1a825eea5d582a8f2d] V4L/DVB: IR/mceusb: less generic callback name and remove cruft git bisect bad 7c294402d58e22bb760c0e1a825eea5d582a8f2d # bad: [82ce67bf262b3f47ecb5a0ca31cace8ac72b7c98] V4L/DVB: staging/lirc: fix non-CONFIG_MODULES build horkage git bisect bad 82ce67bf262b3f47ecb5a0ca31cace8ac72b7c98 ^ permalink raw reply [flat|nested] 25+ messages in thread
* Re: [get-bisect results]: DViCO FusionHDTV7 Dual Express I2C write failed 2011-02-12 16:46 ` Andy Walls 2011-02-12 17:03 ` Mark Zimmerman @ 2011-02-12 19:05 ` Mark Zimmerman 2011-02-12 20:48 ` Andy Walls 1 sibling, 1 reply; 25+ messages in thread From: Mark Zimmerman @ 2011-02-12 19:05 UTC (permalink / raw) To: Andy Walls; +Cc: linux-media On Sat, Feb 12, 2011 at 11:46:13AM -0500, Andy Walls wrote: > On Sat, 2011-02-12 at 09:36 -0700, Mark Zimmerman wrote: > > On Sat, Feb 12, 2011 at 11:27:27AM -0500, Andy Walls wrote: > > > On Sat, 2011-02-12 at 08:29 -0700, Mark Zimmerman wrote: > > > > On Tue, Dec 07, 2010 at 12:07:53PM -0700, Mark Zimmerman wrote: > > > > > Greetings: > > > > > > > > > > I have a DViCO FusionHDTV7 Dual Express card that works with 2.6.35 but > > > > > which fails to initialize with the latest 2.6.36 kernel. The firmware > > > > > fails to load due to an i2c failure. A search of the archives indicates > > > > > that this is not the first time this issue has occurred. > > > > > > > > > > What can I do to help get this problem fixed? > > > > > > > > > > Here is the dmesg from 2.6.35, for the two tuners: > > > > > > > > > > xc5000: waiting for firmware upload (dvb-fe-xc5000-1.6.114.fw)... > > > > > xc5000: firmware read 12401 bytes. > > > > > xc5000: firmware uploading... > > > > > xc5000: firmware upload complete... > > > > > xc5000: waiting for firmware upload (dvb-fe-xc5000-1.6.114.fw)... > > > > > xc5000: firmware read 12401 bytes. > > > > > xc5000: firmware uploading... > > > > > xc5000: firmware upload complete.. > > > > > > > > > > and here is what happens with 2.6.36: > > > > > > > > > > xc5000: waiting for firmware upload (dvb-fe-xc5000-1.6.114.fw)... > > > > > xc5000: firmware read 12401 bytes. > > > > > xc5000: firmware uploading... > > > > > xc5000: I2C write failed (len=3) > > > > > xc5000: firmware upload complete... > > > > > xc5000: Unable to initialise tuner > > > > > xc5000: waiting for firmware upload (dvb-fe-xc5000-1.6.114.fw)... > > > > > xc5000: firmware read 12401 bytes. > > > > > xc5000: firmware uploading... > > > > > xc5000: I2C write failed (len=3) > > > > > xc5000: firmware upload complete... > > > > > > > > > > > > > I did a git bisect on this and finally reached the end of the line. > > > > Here is what it said: > > > > > > > > qpc$ git bisect bad > > > > 82ce67bf262b3f47ecb5a0ca31cace8ac72b7c98 is the first bad commit > > > > commit 82ce67bf262b3f47ecb5a0ca31cace8ac72b7c98 > > > > Author: Jarod Wilson <jarod@redhat.com> > > > > Date: Thu Jul 29 18:20:44 2010 -0300 > > > > > > > > V4L/DVB: staging/lirc: fix non-CONFIG_MODULES build horkage > > > > > > > > Fix when CONFIG_MODULES is not enabled: > > > > > > > > drivers/staging/lirc/lirc_parallel.c:243: error: implicit declaration of function 'module_refcount' > > > > drivers/staging/lirc/lirc_it87.c:150: error: implicit declaration of function 'module_refcount' > > > > drivers/built-in.o: In function `it87_probe': > > > > lirc_it87.c:(.text+0x4079b0): undefined reference to `init_chrdev' > > > > lirc_it87.c:(.text+0x4079cc): undefined reference to `drop_chrdev' > > > > drivers/built-in.o: In function `lirc_it87_exit': > > > > lirc_it87.c:(.exit.text+0x38a5): undefined reference to `drop_chrdev' > > > > > > > > Its a quick hack and untested beyond building, since I don't have the > > > > hardware, but it should do the trick. > > > > > > > > Acked-by: Randy Dunlap <randy.dunlap@oracle.com> > > > > Signed-off-by: Jarod Wilson <jarod@redhat.com> > > > > Signed-off-by: Mauro Carvalho Chehab <mchehab@redhat.com> > > > > > > > > :040000 040000 f645b46a07b7ff87a2c11ac9296a5ff56e89a0d0 49e50945ccf8e1c8567c049908890d2752443b72 M drivers > > > > > > Hmm. git log --patch 82ce67bf262b3f47ecb5a0ca31cace8ac72b7c98 shows the > > > commit is completely unrealted. > > > > > > Please try and see if things are good or bad at commit > > > 18a87becf85d50e7f3d547f1b7a75108b151374d: > > > > > > commit 18a87becf85d50e7f3d547f1b7a75108b151374d > > > Author: Jean Delvare <khali@linux-fr.org> > > > Date: Sun Jul 18 17:05:17 2010 -0300 > > > > > > V4L/DVB: cx23885: i2c_wait_done returns 0 or 1, don't check for < 0 return v > > > > > > Function i2c_wait_done() never returns negative values, so there is no > > > point in checking for them. > > > > > > Signed-off-by: Jean Delvare <khali@linux-fr.org> > > > Signed-off-by: Andy Walls <awalls@md.metrocast.net> > > > Signed-off-by: Mauro Carvalho Chehab <mchehab@redhat.com> > > > > > > Which is the first commit, prior to the one you found, that seems to me > > > to have any direct bearing to I2C transactions. > > > > > > If that commit is good, then these commits in between would be my next > > > likely suspects: > > > e5514f104d875b3d28cbcd5d4f2b96ab2fca1e29 > > > dbe83a3b921328e12b2abe894fc692afba293d7f > > > > > > Regards, > > > Andy > > > > > > > Sorry to require so much hand holding, but I am new to all of this git > > gymnastics. Would you mind sending me the correct git command to get > > to a specific commit? > > It should just be > > $ git checkout 18a87becf85d50e7f3d547f1b7a75108b151374d > > or whatever the commit number git log shows you for the change I suspect > is the problem. > > > > Also, do I need to do a bisect reset? > > I wouldn't reset the git bisect yet. If you test a commit and it is > good, you will want to mark it with 'git bisect good <commit-hash>', and > if it is bad, you will want to mark it with 'git bisect bad > <commit-hash>' OK, I did a git checkout 18a87becf85d50e7f3d547f1b7a75108b151374d and turned CONFIG_STAGING back on in .config and the kernel built fine. The i2c problem is there, however. I wonder if I should start over with a reset, then replay the good/bad commands up to the last good one, then do git bisect bad 18a8... and proceed from there. Does that make sense? ^ permalink raw reply [flat|nested] 25+ messages in thread
* Re: [get-bisect results]: DViCO FusionHDTV7 Dual Express I2C write failed 2011-02-12 19:05 ` Mark Zimmerman @ 2011-02-12 20:48 ` Andy Walls 0 siblings, 0 replies; 25+ messages in thread From: Andy Walls @ 2011-02-12 20:48 UTC (permalink / raw) To: Mark Zimmerman; +Cc: linux-media On Sat, 2011-02-12 at 12:05 -0700, Mark Zimmerman wrote: > On Sat, Feb 12, 2011 at 11:46:13AM -0500, Andy Walls wrote: > > On Sat, 2011-02-12 at 09:36 -0700, Mark Zimmerman wrote: > > > On Sat, Feb 12, 2011 at 11:27:27AM -0500, Andy Walls wrote: > > > > On Sat, 2011-02-12 at 08:29 -0700, Mark Zimmerman wrote: > > > > > On Tue, Dec 07, 2010 at 12:07:53PM -0700, Mark Zimmerman wrote: > > > > > > Greetings: > > > > > > > > > > > > I have a DViCO FusionHDTV7 Dual Express card that works with 2.6.35 but > > > > > > which fails to initialize with the latest 2.6.36 kernel. The firmware > > > > > > fails to load due to an i2c failure. A search of the archives indicates > > > > > > that this is not the first time this issue has occurred. > > > > > > > > > > > > What can I do to help get this problem fixed? > > > > > > > > > > > > Here is the dmesg from 2.6.35, for the two tuners: > > > > > > > > > > > > xc5000: waiting for firmware upload (dvb-fe-xc5000-1.6.114.fw)... > > > > > > xc5000: firmware read 12401 bytes. > > > > > > xc5000: firmware uploading... > > > > > > xc5000: firmware upload complete... > > > > > > xc5000: waiting for firmware upload (dvb-fe-xc5000-1.6.114.fw)... > > > > > > xc5000: firmware read 12401 bytes. > > > > > > xc5000: firmware uploading... > > > > > > xc5000: firmware upload complete.. > > > > > > > > > > > > and here is what happens with 2.6.36: > > > > > > > > > > > > xc5000: waiting for firmware upload (dvb-fe-xc5000-1.6.114.fw)... > > > > > > xc5000: firmware read 12401 bytes. > > > > > > xc5000: firmware uploading... > > > > > > xc5000: I2C write failed (len=3) > > > > > > xc5000: firmware upload complete... > > > > > > xc5000: Unable to initialise tuner > > > > > > xc5000: waiting for firmware upload (dvb-fe-xc5000-1.6.114.fw)... > > > > > > xc5000: firmware read 12401 bytes. > > > > > > xc5000: firmware uploading... > > > > > > xc5000: I2C write failed (len=3) > > > > > > xc5000: firmware upload complete... > > > > > > > > > > > > > > > > I did a git bisect on this and finally reached the end of the line. > > > > > Here is what it said: > > > > > > > > > > qpc$ git bisect bad > > > > > 82ce67bf262b3f47ecb5a0ca31cace8ac72b7c98 is the first bad commit > > > > > commit 82ce67bf262b3f47ecb5a0ca31cace8ac72b7c98 > > > > > Author: Jarod Wilson <jarod@redhat.com> > > > > > Date: Thu Jul 29 18:20:44 2010 -0300 > > > > > > > > > > V4L/DVB: staging/lirc: fix non-CONFIG_MODULES build horkage > > > > > > > > > > Fix when CONFIG_MODULES is not enabled: > > > > > > > > > > drivers/staging/lirc/lirc_parallel.c:243: error: implicit declaration of function 'module_refcount' > > > > > drivers/staging/lirc/lirc_it87.c:150: error: implicit declaration of function 'module_refcount' > > > > > drivers/built-in.o: In function `it87_probe': > > > > > lirc_it87.c:(.text+0x4079b0): undefined reference to `init_chrdev' > > > > > lirc_it87.c:(.text+0x4079cc): undefined reference to `drop_chrdev' > > > > > drivers/built-in.o: In function `lirc_it87_exit': > > > > > lirc_it87.c:(.exit.text+0x38a5): undefined reference to `drop_chrdev' > > > > > > > > > > Its a quick hack and untested beyond building, since I don't have the > > > > > hardware, but it should do the trick. > > > > > > > > > > Acked-by: Randy Dunlap <randy.dunlap@oracle.com> > > > > > Signed-off-by: Jarod Wilson <jarod@redhat.com> > > > > > Signed-off-by: Mauro Carvalho Chehab <mchehab@redhat.com> > > > > > > > > > > :040000 040000 f645b46a07b7ff87a2c11ac9296a5ff56e89a0d0 49e50945ccf8e1c8567c049908890d2752443b72 M drivers > > > > > > > > Hmm. git log --patch 82ce67bf262b3f47ecb5a0ca31cace8ac72b7c98 shows the > > > > commit is completely unrealted. > > > > > > > > Please try and see if things are good or bad at commit > > > > 18a87becf85d50e7f3d547f1b7a75108b151374d: > > > > > > > > commit 18a87becf85d50e7f3d547f1b7a75108b151374d > > > > Author: Jean Delvare <khali@linux-fr.org> > > > > Date: Sun Jul 18 17:05:17 2010 -0300 > > > > > > > > V4L/DVB: cx23885: i2c_wait_done returns 0 or 1, don't check for < 0 return v > > > > > > > > Function i2c_wait_done() never returns negative values, so there is no > > > > point in checking for them. > > > > > > > > Signed-off-by: Jean Delvare <khali@linux-fr.org> > > > > Signed-off-by: Andy Walls <awalls@md.metrocast.net> > > > > Signed-off-by: Mauro Carvalho Chehab <mchehab@redhat.com> > > > > > > > > Which is the first commit, prior to the one you found, that seems to me > > > > to have any direct bearing to I2C transactions. > > > > > > > > If that commit is good, then these commits in between would be my next > > > > likely suspects: > > > > e5514f104d875b3d28cbcd5d4f2b96ab2fca1e29 > > > > dbe83a3b921328e12b2abe894fc692afba293d7f > > > > > > > > Regards, > > > > Andy > > > > > > > > > > Sorry to require so much hand holding, but I am new to all of this git > > > gymnastics. Would you mind sending me the correct git command to get > > > to a specific commit? > > > > It should just be > > > > $ git checkout 18a87becf85d50e7f3d547f1b7a75108b151374d > > > > or whatever the commit number git log shows you for the change I suspect > > is the problem. > > > > > > > Also, do I need to do a bisect reset? > > > > I wouldn't reset the git bisect yet. If you test a commit and it is > > good, you will want to mark it with 'git bisect good <commit-hash>', and > > if it is bad, you will want to mark it with 'git bisect bad > > <commit-hash>' > > OK, I did a git checkout 18a87becf85d50e7f3d547f1b7a75108b151374d and > turned CONFIG_STAGING back on in .config and the kernel built fine. > The i2c problem is there, however. > > I wonder if I should start over with a reset, then replay the good/bad > commands up to the last good one, then do git bisect bad 18a8... and > proceed from there. Does that make sense? Well, looking at your git bisect log, the last known good declaration you made was: efce8ca3c5d8a35018f801d687396e1911cfc868 (July 29, 2010) which comes after 18a87becf85d50e7f3d547f1b7a75108b151374d (July 18, 2010) which you say just tested bad. Also the previous one declared good, 9895850b23886e030cd1e7241d5529a57e969c3d, happens after both of those. One or more of those declarations has to be incorrect. So there's either something not quite right with your build/install/test process or you're dealing with a bug that intermittently does not show symptoms. So my recommendations: 1. Turn CONFIG_STAGING off. git bisect doesn't really care, but if the flaky drivers in there are causing problem with some kernel builds, then they are wasting your time - don't compile them. 2. When using git bisect to make declarations: good means the *precise* symptoms that you care about do not manifest bad means the *precise* symptoms that you care about do manifest Don't use bad for "the kernel didn't build". use git bisect skip for that case and git will try to pick another nearby commit. 3. Make sure with every kernel iteration you rebuild all the kernel source and modules you have configured to be built, install the newly built modules and the newly built kernel, and reboot. Not rebuilding everything you are installing may invalidate your testing. 4. Yeah you'll probably need to restart the git bisect process with commits you have high confidence are known good and known bad. For your I2C & XC5000 related problem you can limit git bisect to changes in: drivers/media include/media drivers/i2c include/linux/i2c* which might keep the number of iterations down. 'git help bisect' shows the manual page. The command would look something like: $ git bisect start <bad-commit> <good-commit> -- drivers/media include/media drivers/i2c include/linux/i2c* Where <good-commit> is a commit hash or version tags that should have been before the <bad-commit> commit hash or version tag. Note that git log outputs commits in reverse chronological order (newest first). 5. When testing each kernel iteration, try to test such that you hopefully avoid any "false good" indications caused by intermittent behavior of the bug. I have no recommendation on what would constitute a thorough enough test. Regards, Andy ^ permalink raw reply [flat|nested] 25+ messages in thread
* [corrected get-bisect results]: DViCO FusionHDTV7 Dual Express I2C write failed 2011-02-12 15:29 ` [get-bisect results]: " Mark Zimmerman 2011-02-12 16:27 ` Andy Walls @ 2011-02-13 14:47 ` Mark Zimmerman 2011-02-13 14:52 ` Devin Heitmueller 2011-02-14 8:05 ` Jean Delvare 1 sibling, 2 replies; 25+ messages in thread From: Mark Zimmerman @ 2011-02-13 14:47 UTC (permalink / raw) To: linux-media; +Cc: Jean Delvare, Andy Walls On Sat, Feb 12, 2011 at 08:29:54AM -0700, Mark Zimmerman wrote: > On Tue, Dec 07, 2010 at 12:07:53PM -0700, Mark Zimmerman wrote: > > Greetings: > > > > I have a DViCO FusionHDTV7 Dual Express card that works with 2.6.35 but > > which fails to initialize with the latest 2.6.36 kernel. The firmware > > fails to load due to an i2c failure. A search of the archives indicates > > that this is not the first time this issue has occurred. > > > > What can I do to help get this problem fixed? > > > > Here is the dmesg from 2.6.35, for the two tuners: > > > > xc5000: waiting for firmware upload (dvb-fe-xc5000-1.6.114.fw)... > > xc5000: firmware read 12401 bytes. > > xc5000: firmware uploading... > > xc5000: firmware upload complete... > > xc5000: waiting for firmware upload (dvb-fe-xc5000-1.6.114.fw)... > > xc5000: firmware read 12401 bytes. > > xc5000: firmware uploading... > > xc5000: firmware upload complete.. > > > > and here is what happens with 2.6.36: > > > > xc5000: waiting for firmware upload (dvb-fe-xc5000-1.6.114.fw)... > > xc5000: firmware read 12401 bytes. > > xc5000: firmware uploading... > > xc5000: I2C write failed (len=3) > > xc5000: firmware upload complete... > > xc5000: Unable to initialise tuner > > xc5000: waiting for firmware upload (dvb-fe-xc5000-1.6.114.fw)... > > xc5000: firmware read 12401 bytes. > > xc5000: firmware uploading... > > xc5000: I2C write failed (len=3) > > xc5000: firmware upload complete... > > > > I did a git bisect on this and finally reached the end of the line. > Blah blah blah... > Clearly my previous bisection went astray; I think I have a more sensible result this time. qpc$ git bisect good 44835f197bf1e3f57464f23dfb239fef06cf89be is the first bad commit commit 44835f197bf1e3f57464f23dfb239fef06cf89be Author: Jean Delvare <khali@linux-fr.org> Date: Sun Jul 18 16:52:05 2010 -0300 V4L/DVB: cx23885: Check for slave nack on all transactions Don't just check for nacks on zero-length transactions. Check on other transactions too. Signed-off-by: Jean Delvare <khali@linux-fr.org> Signed-off-by: Andy Walls <awalls@md.metrocast.net> Signed-off-by: Mauro Carvalho Chehab <mchehab@redhat.com> :040000 040000 e48c9f6efc6186800e8d711c05987c0ad9445c09 1ba37458c6a5fc22d19271f09cde2f336887c616 M drivers git bisect start # good: [9fe6206f400646a2322096b56c59891d530e8d51] Linux 2.6.35 git bisect good 9fe6206f400646a2322096b56c59891d530e8d51 # bad: [18a87becf85d50e7f3d547f1b7a75108b151374d] V4L/DVB: cx23885: i2c_wait_done returns 0 or 1, don't check for < 0 return value git bisect bad 18a87becf85d50e7f3d547f1b7a75108b151374d # good: [03da30986793385af57eeca3296253c887b742e6] Merge git://git.kernel.org/pub/scm/linux/kernel/git/jejb/scsi-misc-2.6 git bisect good 03da30986793385af57eeca3296253c887b742e6 # good: [ab69bcd66fb4be64edfc767365cb9eb084961246] Merge git://git.kernel.org/pub/scm/linux/kernel/git/gregkh/driver-core-2.6 git bisect good ab69bcd66fb4be64edfc767365cb9eb084961246 # good: [a57f9a3e811cf1246b394f0cc667c6bc5a52e099] Merge branch 'for-linus' of git://git.kernel.org/pub/scm/linux/kernel/git/ryusuke/nilfs2 git bisect good a57f9a3e811cf1246b394f0cc667c6bc5a52e099 # good: [9e50ab91d025afc17ca14a1764be2e1d0c24245d] Merge branch 'acpica' of git://git.kernel.org/pub/scm/linux/kernel/git/lenb/linux-acpi-2.6 git bisect good 9e50ab91d025afc17ca14a1764be2e1d0c24245d # good: [d71048e22f47725a5808ea2e4e1e72fa36c1a788] Merge branch 'omap-for-linus' of git://git.kernel.org/pub/scm/linux/kernel/git/tmlind/linux-omap-2.6 git bisect good d71048e22f47725a5808ea2e4e1e72fa36c1a788 # good: [4fd6c6bf83cb16321e9902b00e2af79054f4e0d6] Merge branch 'for-linus' of git://android.kernel.org/kernel/tegra git bisect good 4fd6c6bf83cb16321e9902b00e2af79054f4e0d6 # good: [c1c8f558749cbf2a7ed16b6ae6e19a4238b6fa33] CRIS: Return something from profile write git bisect good c1c8f558749cbf2a7ed16b6ae6e19a4238b6fa33 # good: [ab11b487402f97975f3ac1eeea09c82f4431481e] Merge branch 'master' into for-linus git bisect good ab11b487402f97975f3ac1eeea09c82f4431481e # good: [30d4554a02d3ad6f9928767c9f98214775f4dcb2] V4L/DVB: gspca - main: Version change git bisect good 30d4554a02d3ad6f9928767c9f98214775f4dcb2 # good: [6e80cc51b4419ca0f8162024ee2497d7ec8ba31c] V4L/DVB: gspca - sq930x: Cleanup source, add comments git bisect good 6e80cc51b4419ca0f8162024ee2497d7ec8ba31c # good: [3d217c8656842c77d6f33329a034102157363c8d] V4L/DVB: gspca - vc032x: Force main register write at probe time (poxxxx) git bisect good 3d217c8656842c77d6f33329a034102157363c8d # bad: [44835f197bf1e3f57464f23dfb239fef06cf89be] V4L/DVB: cx23885: Check for slave nack on all transactions git bisect bad 44835f197bf1e3f57464f23dfb239fef06cf89be # good: [f4acb3c4ccca74f5448354308f917e87ce83505a] V4L/DVB: cx23885: Return -ENXIO on slave nack git bisect good f4acb3c4ccca74f5448354308f917e87ce83505a ^ permalink raw reply [flat|nested] 25+ messages in thread
* Re: [corrected get-bisect results]: DViCO FusionHDTV7 Dual Express I2C write failed 2011-02-13 14:47 ` [corrected get-bisect " Mark Zimmerman @ 2011-02-13 14:52 ` Devin Heitmueller 2011-02-13 20:26 ` Mark Zimmerman 2011-02-14 8:05 ` Jean Delvare 1 sibling, 1 reply; 25+ messages in thread From: Devin Heitmueller @ 2011-02-13 14:52 UTC (permalink / raw) To: Mark Zimmerman; +Cc: linux-media, Jean Delvare, Andy Walls On Sun, Feb 13, 2011 at 9:47 AM, Mark Zimmerman <markzimm@frii.com> wrote: > Clearly my previous bisection went astray; I think I have a more > sensible result this time. > > qpc$ git bisect good > 44835f197bf1e3f57464f23dfb239fef06cf89be is the first bad commit > commit 44835f197bf1e3f57464f23dfb239fef06cf89be > Author: Jean Delvare <khali@linux-fr.org> > Date: Sun Jul 18 16:52:05 2010 -0300 > > V4L/DVB: cx23885: Check for slave nack on all transactions > > Don't just check for nacks on zero-length transactions. Check on > other transactions too. This could be a combination of the xc5000 doing clock stretching and the cx23885 i2c master not properly implementing clock stretch. In the past I've seen i2c masters broken in their handling of clock stretching where they treat it as a NAK. The xc5000 being one of the few devices that actually does i2c clock stretching often exposes cases where it is improperly implemented in the i2c master driver (I've had to fix this with several bridges). Devin -- Devin J. Heitmueller - Kernel Labs http://www.kernellabs.com ^ permalink raw reply [flat|nested] 25+ messages in thread
* Re: [corrected get-bisect results]: DViCO FusionHDTV7 Dual Express I2C write failed 2011-02-13 14:52 ` Devin Heitmueller @ 2011-02-13 20:26 ` Mark Zimmerman 2011-02-13 21:26 ` Andy Walls 0 siblings, 1 reply; 25+ messages in thread From: Mark Zimmerman @ 2011-02-13 20:26 UTC (permalink / raw) To: Devin Heitmueller; +Cc: linux-media On Sun, Feb 13, 2011 at 09:52:25AM -0500, Devin Heitmueller wrote: > On Sun, Feb 13, 2011 at 9:47 AM, Mark Zimmerman <markzimm@frii.com> wrote: > > Clearly my previous bisection went astray; I think I have a more > > sensible result this time. > > > > qpc$ git bisect good > > 44835f197bf1e3f57464f23dfb239fef06cf89be is the first bad commit > > commit 44835f197bf1e3f57464f23dfb239fef06cf89be > > Author: Jean Delvare <khali@linux-fr.org> > > Date: ? Sun Jul 18 16:52:05 2010 -0300 > > > > ? ?V4L/DVB: cx23885: Check for slave nack on all transactions > > > > ? ?Don't just check for nacks on zero-length transactions. Check on > > ? ?other transactions too. > > This could be a combination of the xc5000 doing clock stretching and > the cx23885 i2c master not properly implementing clock stretch. In > the past I've seen i2c masters broken in their handling of clock > stretching where they treat it as a NAK. > > The xc5000 being one of the few devices that actually does i2c clock > stretching often exposes cases where it is improperly implemented in > the i2c master driver (I've had to fix this with several bridges). > Thanks for your insight. I am looking at cx23885-i2c.c and there is no clock stretching logic in i2c_slave_did_ack(). Would this be the right place for it to be? Can you point me to an example of another driver that does it correctly? I really don't know what I am doing... -- Mark ^ permalink raw reply [flat|nested] 25+ messages in thread
* Re: [corrected get-bisect results]: DViCO FusionHDTV7 Dual Express I2C write failed 2011-02-13 20:26 ` Mark Zimmerman @ 2011-02-13 21:26 ` Andy Walls 2011-02-14 0:16 ` Andy Walls 2011-02-14 0:37 ` Mark Zimmerman 0 siblings, 2 replies; 25+ messages in thread From: Andy Walls @ 2011-02-13 21:26 UTC (permalink / raw) To: Mark Zimmerman; +Cc: Devin Heitmueller, linux-media On Sun, 2011-02-13 at 13:26 -0700, Mark Zimmerman wrote: > On Sun, Feb 13, 2011 at 09:52:25AM -0500, Devin Heitmueller wrote: > > On Sun, Feb 13, 2011 at 9:47 AM, Mark Zimmerman <markzimm@frii.com> wrote: > > > Clearly my previous bisection went astray; I think I have a more > > > sensible result this time. > > > > > > qpc$ git bisect good > > > 44835f197bf1e3f57464f23dfb239fef06cf89be is the first bad commit > > > commit 44835f197bf1e3f57464f23dfb239fef06cf89be > > > Author: Jean Delvare <khali@linux-fr.org> > > > Date: ? Sun Jul 18 16:52:05 2010 -0300 > > > > > > ? ?V4L/DVB: cx23885: Check for slave nack on all transactions > > > > > > ? ?Don't just check for nacks on zero-length transactions. Check on > > > ? ?other transactions too. > > > > This could be a combination of the xc5000 doing clock stretching and > > the cx23885 i2c master not properly implementing clock stretch. In > > the past I've seen i2c masters broken in their handling of clock > > stretching where they treat it as a NAK. > > > > The xc5000 being one of the few devices that actually does i2c clock > > stretching often exposes cases where it is improperly implemented in > > the i2c master driver (I've had to fix this with several bridges). > > > > Thanks for your insight. I am looking at cx23885-i2c.c and there is no > clock stretching logic in i2c_slave_did_ack(). Would this be the > right place for it to be? Can you point me to an example of another > driver that does it correctly? I really don't know what I am doing... Mark, You don't have much hope of getting that right without the CX23885 datasheet. Let's just get the bad commit reverted and into 2.6.38, and fix what used to work for you. Doing a git bisect is enough work for anyone. I'll do a patch to revert the commit and ask it to be pulled for 2.6.38-rc-whatever. I'll be sure to add a Bisected-by: Mark Zimmerman <markzimm@frii.com> tag to the patch. (The Linux Kernel devs understand the work involved to do a bisection.) Later, if I can work up a patch to deal with clock stretching properly, I may ask you to test. Regards, Andy ^ permalink raw reply [flat|nested] 25+ messages in thread
* Re: [corrected get-bisect results]: DViCO FusionHDTV7 Dual Express I2C write failed 2011-02-13 21:26 ` Andy Walls @ 2011-02-14 0:16 ` Andy Walls 2011-02-14 14:29 ` Devin Heitmueller 2011-02-14 0:37 ` Mark Zimmerman 1 sibling, 1 reply; 25+ messages in thread From: Andy Walls @ 2011-02-14 0:16 UTC (permalink / raw) To: Devin Heitmueller, Mark Zimmerman; +Cc: linux-media On Sun, 2011-02-13 at 16:26 -0500, Andy Walls wrote: > On Sun, 2011-02-13 at 13:26 -0700, Mark Zimmerman wrote: > > On Sun, Feb 13, 2011 at 09:52:25AM -0500, Devin Heitmueller wrote: > > > On Sun, Feb 13, 2011 at 9:47 AM, Mark Zimmerman <markzimm@frii.com> wrote: > > > > Clearly my previous bisection went astray; I think I have a more > > > > sensible result this time. > > > > > > > > qpc$ git bisect good > > > > 44835f197bf1e3f57464f23dfb239fef06cf89be is the first bad commit > > > > commit 44835f197bf1e3f57464f23dfb239fef06cf89be > > > > Author: Jean Delvare <khali@linux-fr.org> > > > > Date: ? Sun Jul 18 16:52:05 2010 -0300 > > > > > > > > ? ?V4L/DVB: cx23885: Check for slave nack on all transactions > > > > > > > > ? ?Don't just check for nacks on zero-length transactions. Check on > > > > ? ?other transactions too. > > > > > > This could be a combination of the xc5000 doing clock stretching and > > > the cx23885 i2c master not properly implementing clock stretch. In > > > the past I've seen i2c masters broken in their handling of clock > > > stretching where they treat it as a NAK. > > > > > > The xc5000 being one of the few devices that actually does i2c clock > > > stretching often exposes cases where it is improperly implemented in > > > the i2c master driver (I've had to fix this with several bridges). > > > Devin, I just checked. The CX23885 driver *is* setting up to allow slaves to stretch the clock. By analysis, I have confirmed that Jean's sugguested patch that I moved forward was wrong for the hardware's behavior. When the cx23885 I2C routines decide to set the I2C_EXTEND flag (and maybe the I2C_NOSTOP flag), we most certainly should *not* be expecting an ACK from the particular hardware register. The original commit should certainly be reverted. Checking for slave ACK/NAK will need to be done with a little more care; so for now, I'll settle for ignoring them. Regards, Andy ^ permalink raw reply [flat|nested] 25+ messages in thread
* Re: [corrected get-bisect results]: DViCO FusionHDTV7 Dual Express I2C write failed 2011-02-14 0:16 ` Andy Walls @ 2011-02-14 14:29 ` Devin Heitmueller 0 siblings, 0 replies; 25+ messages in thread From: Devin Heitmueller @ 2011-02-14 14:29 UTC (permalink / raw) To: Andy Walls; +Cc: Mark Zimmerman, linux-media On Sun, Feb 13, 2011 at 7:16 PM, Andy Walls <awalls@md.metrocast.net> wrote: > Devin, > > I just checked. The CX23885 driver *is* setting up to allow slaves to > stretch the clock. > > By analysis, I have confirmed that Jean's sugguested patch that I moved > forward was wrong for the hardware's behavior. When the cx23885 I2C > routines decide to set the I2C_EXTEND flag (and maybe the I2C_NOSTOP > flag), we most certainly should *not* be expecting an ACK from the > particular hardware register. The original commit should certainly be > reverted. > > Checking for slave ACK/NAK will need to be done with a little more care; > so for now, I'll settle for ignoring them. Ok, that makes sense. I just threw out the possibility of it being related to clock stretch because I've seen that with other bridges and the xc5000. I haven't really reviewed the code in question or the cx23885 datasheet. Cheers, Devin -- Devin J. Heitmueller - Kernel Labs http://www.kernellabs.com ^ permalink raw reply [flat|nested] 25+ messages in thread
* Re: [corrected get-bisect results]: DViCO FusionHDTV7 Dual Express I2C write failed 2011-02-13 21:26 ` Andy Walls 2011-02-14 0:16 ` Andy Walls @ 2011-02-14 0:37 ` Mark Zimmerman 1 sibling, 0 replies; 25+ messages in thread From: Mark Zimmerman @ 2011-02-14 0:37 UTC (permalink / raw) To: Andy Walls; +Cc: Devin Heitmueller, linux-media On Sun, Feb 13, 2011 at 04:26:50PM -0500, Andy Walls wrote: > On Sun, 2011-02-13 at 13:26 -0700, Mark Zimmerman wrote: > > On Sun, Feb 13, 2011 at 09:52:25AM -0500, Devin Heitmueller wrote: > > > On Sun, Feb 13, 2011 at 9:47 AM, Mark Zimmerman <markzimm@frii.com> wrote: > > > > Clearly my previous bisection went astray; I think I have a more > > > > sensible result this time. > > > > > > > > qpc$ git bisect good > > > > 44835f197bf1e3f57464f23dfb239fef06cf89be is the first bad commit > > > > commit 44835f197bf1e3f57464f23dfb239fef06cf89be > > > > Author: Jean Delvare <khali@linux-fr.org> > > > > Date: ? Sun Jul 18 16:52:05 2010 -0300 > > > > > > > > ? ?V4L/DVB: cx23885: Check for slave nack on all transactions > > > > > > > > ? ?Don't just check for nacks on zero-length transactions. Check on > > > > ? ?other transactions too. > > > > > > This could be a combination of the xc5000 doing clock stretching and > > > the cx23885 i2c master not properly implementing clock stretch. In > > > the past I've seen i2c masters broken in their handling of clock > > > stretching where they treat it as a NAK. > > > > > > The xc5000 being one of the few devices that actually does i2c clock > > > stretching often exposes cases where it is improperly implemented in > > > the i2c master driver (I've had to fix this with several bridges). > > > > > > > Thanks for your insight. I am looking at cx23885-i2c.c and there is no > > clock stretching logic in i2c_slave_did_ack(). Would this be the > > right place for it to be? Can you point me to an example of another > > driver that does it correctly? I really don't know what I am doing... > > > Mark, > > You don't have much hope of getting that right without the CX23885 > datasheet. > > Let's just get the bad commit reverted and into 2.6.38, and fix what > used to work for you. Doing a git bisect is enough work for anyone. > > I'll do a patch to revert the commit and ask it to be pulled for > 2.6.38-rc-whatever. I'll be sure to add a > > Bisected-by: Mark Zimmerman <markzimm@frii.com> > > tag to the patch. (The Linux Kernel devs understand the work involved > to do a bisection.) > > > Later, if I can work up a patch to deal with clock stretching properly, > I may ask you to test. > Thanks, that would be great. Meanwhile, I have built a 2.6.37 with the offending commit removed: git bisect reset git checkout v2.6.37 git revert 44835f197bf1e3f57464f23dfb239fef06cf89be and it seems to be working fine using both tuners: xc5000: waiting for firmware upload (dvb-fe-xc5000-1.6.114.fw)... xc5000: firmware read 12401 bytes. xc5000: firmware uploading... xc5000: firmware upload complete... xc5000: waiting for firmware upload (dvb-fe-xc5000-1.6.114.fw)... xc5000: firmware read 12401 bytes. xc5000: firmware uploading... xc5000: firmware upload complete... Thanks again -- Mark ^ permalink raw reply [flat|nested] 25+ messages in thread
* Re: [corrected get-bisect results]: DViCO FusionHDTV7 Dual Express I2C write failed 2011-02-13 14:47 ` [corrected get-bisect " Mark Zimmerman 2011-02-13 14:52 ` Devin Heitmueller @ 2011-02-14 8:05 ` Jean Delvare 1 sibling, 0 replies; 25+ messages in thread From: Jean Delvare @ 2011-02-14 8:05 UTC (permalink / raw) To: Mark Zimmerman; +Cc: linux-media, Andy Walls Hi Mark, On Sun, 13 Feb 2011 07:47:59 -0700, Mark Zimmerman wrote: > Clearly my previous bisection went astray; I think I have a more > sensible result this time. > > qpc$ git bisect good > 44835f197bf1e3f57464f23dfb239fef06cf89be is the first bad commit > commit 44835f197bf1e3f57464f23dfb239fef06cf89be > Author: Jean Delvare <khali@linux-fr.org> > Date: Sun Jul 18 16:52:05 2010 -0300 > > V4L/DVB: cx23885: Check for slave nack on all transactions > > Don't just check for nacks on zero-length transactions. Check on > other transactions too. > > Signed-off-by: Jean Delvare <khali@linux-fr.org> > Signed-off-by: Andy Walls <awalls@md.metrocast.net> > Signed-off-by: Mauro Carvalho Chehab <mchehab@redhat.com> I'm sorry for the trouble :( I should probably refrain from writing patches for media drivers I don't own. -- Jean Delvare ^ permalink raw reply [flat|nested] 25+ messages in thread
end of thread, other threads:[~2011-02-14 14:29 UTC | newest]
Thread overview: 25+ messages (download: mbox.gz / follow: Atom feed)
-- links below jump to the message on this page --
[not found] <20101207190753.GA21666@io.frii.com>
2011-01-10 2:14 ` DViCO FusionHDTV7 Dual Express I2C write failed Mark Zimmerman
2011-01-19 15:59 ` VDR User
2011-01-19 16:13 ` Devin Heitmueller
2011-01-19 17:22 ` VDR User
2011-01-19 17:39 ` Mark Zimmerman
2011-01-24 15:49 ` Mark Zimmerman
2011-01-24 15:57 ` Devin Heitmueller
2011-01-25 14:27 ` Mark Zimmerman
2011-01-19 19:01 ` Timothy D. Lenz
2011-01-17 23:12 ` Timothy D. Lenz
2011-02-12 15:29 ` [get-bisect results]: " Mark Zimmerman
2011-02-12 16:27 ` Andy Walls
2011-02-12 16:36 ` Mark Zimmerman
2011-02-12 16:46 ` Andy Walls
2011-02-12 17:03 ` Mark Zimmerman
2011-02-12 19:05 ` Mark Zimmerman
2011-02-12 20:48 ` Andy Walls
2011-02-13 14:47 ` [corrected get-bisect " Mark Zimmerman
2011-02-13 14:52 ` Devin Heitmueller
2011-02-13 20:26 ` Mark Zimmerman
2011-02-13 21:26 ` Andy Walls
2011-02-14 0:16 ` Andy Walls
2011-02-14 14:29 ` Devin Heitmueller
2011-02-14 0:37 ` Mark Zimmerman
2011-02-14 8:05 ` Jean Delvare
This is an external index of several public inboxes, see mirroring instructions on how to clone and mirror all data and code used by this external index.