ivtv:Crash 2.6.26 with KUROTOSIKOU CX23416-STVLP

PATCH In review Kyuma Ohta 3 participants 8 messages Jul 17, 2008 – Aug 10, 2008

Subsystems (2)

Media (V4L/DVB) I2C

lore

Share & tools

lore

Kyuma Ohta

author

2008-07-17 15:20 UTC #0 lore raw

PATCH 1/1 ivtv:Crash 2.6.26 with KUROTOSIKOU CX23416-STVLP

Hi,
I'm testing 2.6.26/amd64 with Athlon64 x2 Box with KUROTOSIKOU CX23416-STVLP,always crash ivtv driver when loading upd64083 driver.
I checked crash dump,this issue cause of loading upd64083.ko with i2c_probed_new_device(). So,I fixed ivtv-i2c.c of 2.6.26 vanilla,and fixed *pretty* differnce memory allocation,structure of upd64083.c.
I'm running patched 2.6.26 vanilla with below attached patches over 24hrs,and over 10hrs recording from ivtv, not happend anything;-)
Please apply below to 2.6.26.x..

Best regards,
Ohta.

E-Mail: [email protected] (Public) Home Page: http://d.hatena.ne.jp/artane/
(Sorry,not maintaining,and written in Japanese only...)
Twitter: Artanejp (Mainly Japanese)
ICQ: 366538955
KEYID: 6B79F95F
FINGERPRINT:
9AB3 8569 6033 FDBE 352B CB6D DBFA B9E2 6B79 F95F

drivers/media/video/ivtv/ivtv-cards.c +1 -0

diff -urN a/drivers/media/video/ivtv/ivtv-cards.c b/drivers/media/video/ivtv/ivtv-cards.c
@@ -28,6 +28,7 @@
 #include <media/cs53l32a.h>
 #include <media/cx25840.h>
 #include <media/upd64031a.h>
+#include <media/upd64083.h> // Fix 20080715 K.Ohta
 
 #define MSP_TUNER  MSP_INPUT(MSP_IN_SCART1, MSP_IN_TUNER1, \
 				MSP_DSP_IN_TUNER, MSP_DSP_IN_TUNER)

drivers/media/video/ivtv/ivtv-i2c.c +2 -3

diff -urN a/drivers/media/video/ivtv/ivtv-i2c.c b/drivers/media/video/ivtv/ivtv-i2c.c
@@ -177,10 +177,9 @@
 	}
 
 	if (id != I2C_DRIVERID_TUNER) {
-		if (id == I2C_DRIVERID_UPD64031A ||
-		    id == I2C_DRIVERID_UPD64083) {
+		if (id == I2C_DRIVERID_UPD64031A ) { // Apply only upd64031a 20080716
 			unsigned short addrs[2] = { info.addr, I2C_CLIENT_END };
-
+		   
 			c = i2c_new_probed_device(&itv->i2c_adap, &info, addrs);
 		} else
 			c = i2c_new_device(&itv->i2c_adap, &info);

drivers/media/video/upd64083.c +5 -5

diff -urN a/drivers/media/video/upd64083.c b/drivers/media/video/upd64083.c
@@ -51,9 +51,9 @@
 };
 
 struct upd64083_state {
+   	u8 regs[TOT_REGS];
 	u8 mode;
 	u8 ext_y_adc;
-	u8 regs[TOT_REGS];
 };
 
 /* Initial values when used in combination with the

@@ -178,20 +178,19 @@
 	struct upd64083_state *state;
 	int i;
 
-	if (!i2c_check_functionality(client->adapter, I2C_FUNC_SMBUS_BYTE_DATA))
+        if (!i2c_check_functionality(client->adapter, I2C_FUNC_SMBUS_BYTE_DATA))
 		return -EIO;
-
 	v4l_info(client, "chip found @ 0x%x (%s)\n",
 			client->addr << 1, client->adapter->name);
 
-	state = kmalloc(sizeof(struct upd64083_state), GFP_KERNEL);
+	state = kzalloc(sizeof(struct upd64083_state), GFP_KERNEL); // Fix 20080716
 	if (state == NULL)
 		return -ENOMEM;
 	i2c_set_clientdata(client, state);
 	/* Initially assume that a ghost reduction chip is present */
 	state->mode = 0;  /* YCS mode */
 	state->ext_y_adc = (1 << 5);
-	memcpy(state->regs, upd64083_init, TOT_REGS);
+	memcpy(state->regs, upd64083_init, sizeof(state->regs)); // Fix 20080716
 	for (i = 0; i < TOT_REGS; i++)
 		upd64083_write(client, i, state->regs[i]);
 	return 0;

@@ -217,5 +216,6 @@
 	.command = upd64083_command,
 	.probe = upd64083_probe,
 	.remove = upd64083_remove,
+        .legacy_class = I2C_CLASS_TV_ANALOG | I2C_CLASS_TV_DIGITAL , // Add 20080716
 	.id_table = upd64083_id,
 };

drivers/media/video/upd64031a.c +3 -2

diff -urN a/drivers/media/video/upd64031a.c b/drivers/media/video/upd64031a.c
@@ -207,7 +207,7 @@
 	v4l_info(client, "chip found @ 0x%x (%s)\n",
 			client->addr << 1, client->adapter->name);
 
-	state = kmalloc(sizeof(struct upd64031a_state), GFP_KERNEL);
+	state = kzalloc(sizeof(struct upd64031a_state), GFP_KERNEL); // Fix 20080716
 	if (state == NULL)
 		return -ENOMEM;
 	i2c_set_clientdata(client, state);

@@ -239,6 +239,7 @@
 	.driverid = I2C_DRIVERID_UPD64031A,
 	.command = upd64031a_command,
 	.probe = upd64031a_probe,
-	.remove = upd64031a_remove,
+       .legacy_class = I2C_CLASS_TV_ANALOG | I2C_CLASS_TV_DIGITAL , // Add 20080716
+       .remove = upd64031a_remove,
 	.id_table = upd64031a_id,
 };

--
video4linux-list mailing list
Unsubscribe mailto:[email protected]?subject=unsubscribe
https://www.redhat.com/mailman/listinfo/video4linux-list

Hans Verkuil

2008-07-17 16:00 UTC #1 lore raw

Quoted 14 lines · On Thursday 17 July 2008 17:20:14 Kyuma Ohta wrote:

Hi,
I'm testing 2.6.26/amd64 with Athlon64 x2 Box with KUROTOSIKOU CX23416-STVLP,always crash ivtv driver when loading upd64083 driver.
I checked crash dump,this issue cause of loading upd64083.ko with i2c_probed_new_device(). So,I fixed ivtv-i2c.c of 2.6.26 vanilla,and fixed *pretty* differnce memory allocation,structure of upd64083.c.
I'm running patched 2.6.26 vanilla with below attached patches over 24hrs,and over 10hrs recording from ivtv, not happend anything;-)
Please apply below to 2.6.26.x..

Quoted 2 lines

Best regards,
Ohta.

Hi Ohta,

Thanks for the patches. If I'm not mistaken there are several variants of this card: without upd* devices, only with upd64083 and with both upd devices. Which one do you have?

Can you also show the dmesg output when ivtv loads?

Looking at the four patches, I would say that the only relevant patch is the fix-probing patch. If you try it with only that one applied, does it still work correct for you? Note that this patch will not work with a KUROTOSIKOU card that has no upd* devices at all.

Can you also give me the kernel backtrace when you load ivtv with the vanilla 2.6.26? I do not quite understand why it should crash.

Regards,

Hans

--
video4linux-list mailing list
Unsubscribe mailto:[email protected]?subject=unsubscribe
https://www.redhat.com/mailman/listinfo/video4linux-list

Kyuma Ohta

author

2008-07-17 23:15 UTC #2 lore raw

Dear Hans,
Thanx for reply.

Quoted 31 lines · Hans Verkuil

Quoted 14 lines · On Thursday 17 July 2008 17:20:14 Kyuma Ohta wrote:
Hi,
I'm testing 2.6.26/amd64 with Athlon64 x2 Box with KUROTOSIKOU CX23416-STVLP,always crash ivtv driver when loading upd64083 driver.
I checked crash dump,this issue cause of loading upd64083.ko with i2c_probed_new_device(). So,I fixed ivtv-i2c.c of 2.6.26 vanilla,and fixed *pretty* differnce memory allocation,structure of upd64083.c.
I'm running patched 2.6.26 vanilla with below attached patches over 24hrs,and over 10hrs recording from ivtv, not happend anything;-)
Please apply below to 2.6.26.x..
Quoted 2 lines
Best regards,
Ohta.
Hi Ohta,
Thanks for the patches. If I'm not mistaken there are several variants of this card: without upd* devices, only with upd64083 and with both upd devices. Which one do you have?
Can you also show the dmesg output when ivtv loads?
Looking at the four patches, I would say that the only relevant patch is the fix-probing patch. If you try it with only that one applied, does it still work correct for you? Note that this patch will not work with a KUROTOSIKOU card that has no upd* devices at all.

Quoted 7 lines

Can you also give me the kernel backtrace when you load ivtv with the vanilla 2.6.26? I do not quite understand why it should crash.
Regards,
Hans

I have a ivtv card with *both* upd64083 and upd64031a. I don't still try testing apply only one of patch,only apply all of...

I attach compressed logs when loading ivtv at boottime, parallel probing saa7134 v4l2 device,
both applied (successed) ,not applied (failed).

Best regards,
Ohta

lspci -n
00:00.0 0500: 10de:03ea (rev a1)
00:01.0 0601: 10de:03e0 (rev a2)
00:01.1 0c05: 10de:03eb (rev a2)
00:01.2 0500: 10de:03f5 (rev a2)
00:02.0 0c03: 10de:03f1 (rev a2)
00:02.1 0c03: 10de:03f2 (rev a2)
00:04.0 0604: 10de:03f3 (rev a1)
00:05.0 0403: 10de:03f0 (rev a2)
00:06.0 0101: 10de:03ec (rev a2)
00:07.0 0680: 10de:03ef (rev a2)
00:08.0 0101: 10de:03f6 (rev a2)
00:08.1 0101: 10de:03f6 (rev a2)
00:09.0 0604: 10de:03e8 (rev a2)
00:18.0 0600: 1022:1100
00:18.1 0600: 1022:1101
00:18.2 0600: 1022:1102
00:18.3 0600: 1022:1103
01:06.0 0200: 10ec:8139 (rev 10)
01:07.0 0480: 1131:7134 (rev 01)
01:08.0 0400: 4444:0016 (rev 01)
01:09.0 0401: 1102:0008
01:0e.0 0c00: 104c:8024
02:00.0 0300: 10de:0404 (rev a1)
---
lspci
00:00.0 RAM memory: nVidia Corporation MCP61 Memory Controller (rev a1)
00:01.0 ISA bridge: nVidia Corporation MCP61 LPC Bridge (rev a2)
00:01.1 SMBus: nVidia Corporation MCP61 SMBus (rev a2)
00:01.2 RAM memory: nVidia Corporation MCP61 Memory Controller (rev a2)
00:02.0 USB Controller: nVidia Corporation MCP61 USB Controller (rev a2)
00:02.1 USB Controller: nVidia Corporation MCP61 USB Controller (rev a2)
00:04.0 PCI bridge: nVidia Corporation MCP61 PCI bridge (rev a1)
00:05.0 Audio device: nVidia Corporation MCP61 High Definition Audio (rev a2)
00:06.0 IDE interface: nVidia Corporation MCP61 IDE (rev a2)
00:07.0 Bridge: nVidia Corporation MCP61 Ethernet (rev a2)
00:08.0 IDE interface: nVidia Corporation MCP61 SATA Controller (rev a2)
00:08.1 IDE interface: nVidia Corporation MCP61 SATA Controller (rev a2)
00:09.0 PCI bridge: nVidia Corporation MCP61 PCI Express bridge (rev a2)
00:18.0 Host bridge: Advanced Micro Devices [AMD] K8 [Athlon64/Opteron] HyperTransport Technology Configuration 00:18.1 Host bridge: Advanced Micro Devices [AMD] K8 [Athlon64/Opteron] Address Map
00:18.2 Host bridge: Advanced Micro Devices [AMD] K8 [Athlon64/Opteron] DRAM Controller 00:18.3 Host bridge: Advanced Micro Devices [AMD] K8 [Athlon64/Opteron] Miscellaneous Control 01:06.0 Ethernet controller: Realtek Semiconductor Co., Ltd. RTL-8139/8139C/8139C+ (rev 10) 01:07.0 Multimedia controller: Philips Semiconductors SAA7134/SAA7135HL Video Broadcast Decoder (rev 01) 01:08.0 Multimedia video controller: Internext Compression Inc iTVC16 (CX23416) MPEG-2 Encoder (rev 01) 01:09.0 Multimedia audio controller: Creative Labs SB0400 Audigy2 Value
01:0e.0 FireWire (IEEE 1394): Texas Instruments TSB43AB23 IEEE-1394a-2000 Controller (PHY/Link) 02:00.0 VGA compatible controller: nVidia Corporation GeForce 8400 GS (rev a1)

Hans Verkuil

2008-07-19 19:09 UTC #3 lore raw

Quoted 2 lines · On Friday 18 July 2008 01:13:45 Kyuma Ohta wrote:

Dear Hans,
Thanx for reply.

Hi Ohta,

I've decided to wait until I have access to my own card with upd64083 and upd64031a devices. I'll be back in the Netherlands in about two weeks from now, and then I can pick it up and bring it back with me to Oslo where I can test it and fix the problem.

The backtrace doesn't really help me, I think I need to do a bit of debugging myself.

A bit of a shame that I didn't bring it with me a week ago. It was on my list of things to take with me, but my suitcase was already pretty full so I decided against it. Next time I'll make sure I have it :-)

For now just use your workaround. It can't do any harm, but it is not the right solution. That will have to wait until I can test it myself.

Regards,

Hans

Quoted 53 lines

Quoted 32 lines · Hans Verkuil
Quoted 14 lines · On Thursday 17 July 2008 17:20:14 Kyuma Ohta wrote:
Hi,
I'm testing 2.6.26/amd64 with Athlon64 x2 Box with KUROTOSIKOU CX23416-STVLP,always crash ivtv driver when loading upd64083 driver.
I checked crash dump,this issue cause of loading upd64083.ko with i2c_probed_new_device(). So,I fixed ivtv-i2c.c of 2.6.26 vanilla,and fixed *pretty* differnce memory allocation,structure of upd64083.c.
I'm running patched 2.6.26 vanilla with below attached patches over 24hrs,and over 10hrs recording from ivtv, not happend anything;-)
Please apply below to 2.6.26.x..
Quoted 2 lines
Best regards,
Ohta.
Hi Ohta,
Thanks for the patches. If I'm not mistaken there are several variants of this card: without upd* devices, only with upd64083 and with both upd devices. Which one do you have?
Can you also show the dmesg output when ivtv loads?
Looking at the four patches, I would say that the only relevant patch is the fix-probing patch. If you try it with only that one applied, does it still work correct for you? Note that this patch will not work with a KUROTOSIKOU card that has no upd* devices at all.
Quoted 6 lines
Can you also give me the kernel backtrace when you load ivtv with the vanilla 2.6.26? I do not quite understand why it should crash.
Regards,
Hans
I have a ivtv card with *both* upd64083 and upd64031a. I don't still try testing apply only one of patch,only apply all of...
I attach compressed logs when loading ivtv at boottime, parallel probing saa7134 v4l2 device,
both applied (successed) ,not applied (failed).
Best regards,
Ohta

Quoted 8 lines

E-Mail: [email protected] (Public) Home Page: http://d.hatena.ne.jp/artane/
(Sorry,not maintaining,and written in Japanese only...)
Twitter: Artanejp (Mainly Japanese)
ICQ: 366538955
KEYID: 6B79F95F
FINGERPRINT:
9AB3 8569 6033 FDBE 352B CB6D DBFA B9E2 6B79 F95F

--
video4linux-list mailing list
Unsubscribe mailto:[email protected]?subject=unsubscribe
https://www.redhat.com/mailman/listinfo/video4linux-list

Hans Verkuil

2008-08-03 21:13 UTC #4 lore raw

In reply to Kyuma Ohta

Hi Ohta,

Well, I picked up my card this weekend and tested it. It turns out to be an i2c-core.c bug: chips with i2c addresses in the 0x5x range are probed differently than other chips and the probe command contains an error. The upd64083 has an address in that range and so was hit by this bug. The attached patch for linux/drivers/i2c/i2c-core.c will fix it.

As you can see, this mail also goes to Jean Delvare so that he can move this upstream (should also go to the 2.6.26-stable series, Jean!).

For the ivtv driver this bug will only hit cards where ivtv has to probe for an upd64083.

SoB for this patch:

Signed-off-by Hans Verkuil <[email protected]>

I've verified that this is only an issue with kernels 2.6.26 and up. Older kernels are not affected unless the ivtv driver from the v4l-dvb repository is used. To be more precise: this bug has been in i2c-core.c since 2.6.22, but the ivtv driver in 2.6.26 was the first driver that used i2c_new_probed_device() with an i2c address in a range that caused the broken probe to be used.

Thanks for the report Ohta!

Regards,

Hans

Quoted 56 lines · On Friday 18 July 2008 01:13:45 Kyuma Ohta wrote:

Dear Hans,
Thanx for reply.
Quoted 32 lines · Hans Verkuil
Quoted 14 lines · On Thursday 17 July 2008 17:20:14 Kyuma Ohta wrote:
Hi,
I'm testing 2.6.26/amd64 with Athlon64 x2 Box with KUROTOSIKOU CX23416-STVLP,always crash ivtv driver when loading upd64083 driver.
I checked crash dump,this issue cause of loading upd64083.ko with i2c_probed_new_device(). So,I fixed ivtv-i2c.c of 2.6.26 vanilla,and fixed *pretty* differnce memory allocation,structure of upd64083.c.
I'm running patched 2.6.26 vanilla with below attached patches over 24hrs,and over 10hrs recording from ivtv, not happend anything;-)
Please apply below to 2.6.26.x..
Quoted 2 lines
Best regards,
Ohta.
Hi Ohta,
Thanks for the patches. If I'm not mistaken there are several variants of this card: without upd* devices, only with upd64083 and with both upd devices. Which one do you have?
Can you also show the dmesg output when ivtv loads?
Looking at the four patches, I would say that the only relevant patch is the fix-probing patch. If you try it with only that one applied, does it still work correct for you? Note that this patch will not work with a KUROTOSIKOU card that has no upd* devices at all.
Quoted 6 lines
Can you also give me the kernel backtrace when you load ivtv with the vanilla 2.6.26? I do not quite understand why it should crash.
Regards,
Hans
I have a ivtv card with *both* upd64083 and upd64031a. I don't still try testing apply only one of patch,only apply all of...
I attach compressed logs when loading ivtv at boottime, parallel probing saa7134 v4l2 device,
both applied (successed) ,not applied (failed).
Best regards,
Ohta

Quoted 8 lines

E-Mail: [email protected] (Public) Home Page: http://d.hatena.ne.jp/artane/
(Sorry,not maintaining,and written in Japanese only...)
Twitter: Artanejp (Mainly Japanese)
ICQ: 366538955
KEYID: 6B79F95F
FINGERPRINT:
9AB3 8569 6033 FDBE 352B CB6D DBFA B9E2 6B79 F95F

drivers/i2c/i2c-core.c renamed from drivers/i2c/i2c-core.c.orig +3 -1

@@ -1196,9 +1196,11 @@
 		if ((addr_list[i] & ~0x07) == 0x30
 		 || (addr_list[i] & ~0x0f) == 0x50
 		 || !i2c_check_functionality(adap, I2C_FUNC_SMBUS_QUICK)) {
+			union i2c_smbus_data data;
+
 			if (i2c_smbus_xfer(adap, addr_list[i], 0,
 					   I2C_SMBUS_READ, 0,
-					   I2C_SMBUS_BYTE, NULL) >= 0)
+					   I2C_SMBUS_BYTE, &data) >= 0)
 				break;
 		} else {
 			if (i2c_smbus_xfer(adap, addr_list[i], 0,

--
video4linux-list mailing list
Unsubscribe mailto:[email protected]?subject=unsubscribe
https://www.redhat.com/mailman/listinfo/video4linux-list

Kyuma Ohta

author

2008-08-06 13:18 UTC #5 lore raw

Dear Hans,
Sorry for later picked up this article cause of my lazyness(^^;

Thanx for check I2C bus on card you have...I've no physical probes (such as oscillo-scope or cheapi2c!!) now...thanx...

I'll test attached patch until after morning (in JAPAN) firstly, and testing long-running if happend nothing above short test.. If problem will be occured,'ll report .

Best regards,
Ohta.

2008-08-03 (Sun) ,23:12 +0200 Hans Verkuil Wrote:

Quoted 25 lines

Hi Ohta,
Well, I picked up my card this weekend and tested it. It turns out to be an i2c-core.c bug: chips with i2c addresses in the 0x5x range are probed differently than other chips and the probe command contains an error. The upd64083 has an address in that range and so was hit by this bug. The attached patch for linux/drivers/i2c/i2c-core.c will fix it.
As you can see, this mail also goes to Jean Delvare so that he can move this upstream (should also go to the 2.6.26-stable series, Jean!).
For the ivtv driver this bug will only hit cards where ivtv has to probe for an upd64083.
SoB for this patch:
Signed-off-by Hans Verkuil <[email protected]>
I've verified that this is only an issue with kernels 2.6.26 and up. Older kernels are not affected unless the ivtv driver from the v4l-dvb repository is used. To be more precise: this bug has been in i2c-core.c since 2.6.22, but the ivtv driver in 2.6.26 was the first driver that used i2c_new_probed_device() with an i2c address in a range that caused the broken probe to be used.

Quoted 73 lines

Thanks for the report Ohta!
Regards,
Hans
Quoted 64 lines · On Friday 18 July 2008 01:13:45 Kyuma Ohta wrote:
Dear Hans,
Thanx for reply.
Quoted 32 lines · Hans Verkuil
Quoted 14 lines · On Thursday 17 July 2008 17:20:14 Kyuma Ohta wrote:
Hi,
I'm testing 2.6.26/amd64 with Athlon64 x2 Box with KUROTOSIKOU CX23416-STVLP,always crash ivtv driver when loading upd64083 driver.
I checked crash dump,this issue cause of loading upd64083.ko with i2c_probed_new_device(). So,I fixed ivtv-i2c.c of 2.6.26 vanilla,and fixed *pretty* differnce memory allocation,structure of upd64083.c.
I'm running patched 2.6.26 vanilla with below attached patches over 24hrs,and over 10hrs recording from ivtv, not happend anything;-)
Please apply below to 2.6.26.x..
Quoted 2 lines
Best regards,
Ohta.
Hi Ohta,
Thanks for the patches. If I'm not mistaken there are several variants of this card: without upd* devices, only with upd64083 and with both upd devices. Which one do you have?
Can you also show the dmesg output when ivtv loads?
Looking at the four patches, I would say that the only relevant patch is the fix-probing patch. If you try it with only that one applied, does it still work correct for you? Note that this patch will not work with a KUROTOSIKOU card that has no upd* devices at all.
Quoted 6 lines
Can you also give me the kernel backtrace when you load ivtv with the vanilla 2.6.26? I do not quite understand why it should crash.
Regards,
Hans
I have a ivtv card with *both* upd64083 and upd64031a. I don't still try testing apply only one of patch,only apply all of...
I attach compressed logs when loading ivtv at boottime, parallel probing saa7134 v4l2 device,
both applied (successed) ,not applied (failed).
Best regards,
Ohta
E-Mail: [email protected] (Public) Home Page: http://d.hatena.ne.jp/artane/
(Sorry,not maintaining,and written in Japanese only...)
Twitter: Artanejp (Mainly Japanese)
ICQ: 366538955
KEYID: 6B79F95F
FINGERPRINT:
9AB3 8569 6033 FDBE 352B CB6D DBFA B9E2 6B79 F95F

Jean Delvare

2008-08-07 13:08 UTC #6 lore raw

In reply to Hans Verkuil

Hi Hans,

Quoted 16 lines · Hans Verkuil

Hi Ohta,
Well, I picked up my card this weekend and tested it. It turns out to be an i2c-core.c bug: chips with i2c addresses in the 0x5x range are probed differently than other chips and the probe command contains an error. The upd64083 has an address in that range and so was hit by this bug. The attached patch for linux/drivers/i2c/i2c-core.c will fix it.
As you can see, this mail also goes to Jean Delvare so that he can move this upstream (should also go to the 2.6.26-stable series, Jean!).
For the ivtv driver this bug will only hit cards where ivtv has to probe for an upd64083.
SoB for this patch:

Quoted 8 lines

Signed-off-by Hans Verkuil <[email protected]>
I've verified that this is only an issue with kernels 2.6.26 and up. Older kernels are not affected unless the ivtv driver from the v4l-dvb repository is used. To be more precise: this bug has been in i2c-core.c since 2.6.22, but the ivtv driver in 2.6.26 was the first driver that used i2c_new_probed_device() with an i2c address in a range that caused the broken probe to be used.

Good catch, thanks for the patch. I'll push it to Linus by the end of the week.

Signature · 1 line

Jean Delvare

Kyuma Ohta

author

2008-08-10 16:20 UTC #7 lore raw

Dear Hans,and Jean;
I was applied Hans's patch to 2.6.26.1 vanilla at
morning of 08/06 (JST),and running to now,problem cause from IIC issue was not happend.
Thanx for you (^^)

Ohta
---
E-Mail: [email protected] (Public)
Home Page: http://d.hatena.ne.jp/artane/
  (Sorry,not maintaining,and written in Japanese only...)
Twitter: Artanejp (Mainly Japanese)
KEYID: 6B79F95F
FINGERPRINT:
9AB3 8569 6033 FDBE 352B  CB6D DBFA B9E2 6B79 F95F
---

Quoted 31 lines · Jean Delvare

Hi Hans,
Quoted 16 lines · Hans Verkuil
Hi Ohta,
Well, I picked up my card this weekend and tested it. It turns out to be an i2c-core.c bug: chips with i2c addresses in the 0x5x range are probed differently than other chips and the probe command contains an error. The upd64083 has an address in that range and so was hit by this bug. The attached patch for linux/drivers/i2c/i2c-core.c will fix it.
As you can see, this mail also goes to Jean Delvare so that he can move this upstream (should also go to the 2.6.26-stable series, Jean!).
For the ivtv driver this bug will only hit cards where ivtv has to probe for an upd64083.
SoB for this patch:
Quoted 8 lines
Signed-off-by Hans Verkuil <[email protected]>
I've verified that this is only an issue with kernels 2.6.26 and up. Older kernels are not affected unless the ivtv driver from the v4l-dvb repository is used. To be more precise: this bug has been in i2c-core.c since 2.6.22, but the ivtv driver in 2.6.26 was the first driver that used i2c_new_probed_device() with an i2c address in a range that caused the broken probe to be used.
Good catch, thanks for the patch. I'll push it to Linus by the end of the week.