Re: dibusb-common.c FE_HAS_LOCK problem

2009-11-23 Thread Patrick Boettcher 

Hi Mario,

On Sat, 21 Nov 2009, grafgrim...@gmx.de wrote:


Am Thu, 19 Nov 2009 16:37:18 +0100 (CET)
schrieb Patrick Boettcher pboettc...@kernellabs.com:


On Sat, 7 Nov 2009, Mario Bachmann wrote:


Hi there,

I tried linux-2.6.31.5 and tuning still does not work:
tuning to 73800 Hz
video pid 0x0131, audio pid 0x0132
status 00 | signal  | snr  | ber 001f | unc  |
status 00 | signal  | snr  | ber 001f | unc  |
status 00 | signal  | snr  | ber 001f | unc  |
status 04 | signal  | snr  | ber 001f | unc  |

With some changes for the following file it works again:
/usr/src/linux/drivers/media/dvb/dvb-usb/dibusb-common.c

diff -Naur dibusb-common.c-ORIGINAL dibusb-common.c

--- dibusb-common.c-ORIGINAL2009-11-07 10:30:43.705344308 +0100
+++ dibusb-common.c 2009-11-07 10:33:49.969345253 +0100
@@ -133,17 +133,14 @@

for (i = 0; i  num; i++) {
/* write/read request */
-   if (i+1  num  (msg[i].flags  I2C_M_RD) == 0
-  (msg[i+1].flags  I2C_M_RD)) {
+   if (i+1  num  (msg[i+1].flags  I2C_M_RD)) {
if (dibusb_i2c_msg(d, msg[i].addr, 
msg[i].buf,msg[i].len,
msg[i+1].buf,msg[i+1].len)  0)
break;
i++;
-   } else if ((msg[i].flags  I2C_M_RD) == 0) {
+   } else
if (dibusb_i2c_msg(d, msg[i].addr, 
msg[i].buf,msg[i].len,NULL,0)  0)
break;
-   } else
-   break;
}


Doing it is reverting a fix which avoids that uncontrolled i2c-access from
userspace is destroying the USB-eeprom.

I understand that this is breaking the tuning for your board. I'm just not
understanding why.

If you have some time to debug this issue, could you please try the
following:

One of the devices for your board is trying to do an I2c access which is
falling into the last 'else'-branch - can you add a printk to find out
which one it is? The access must be wrongly constructed and must be fixed
in that driver.

thanks,

PS: if you don't have time to do it, please tell so.

--

Patrick
http://www.kernellabs.com/


I do not understand exactly. printk what? Could you please give me a
complete piece of code with the printk command? Would be great!

My printk-tries ends up in an Oops.


There is a
} else
break;

sequence in dibusb_i2c_xfer

instead of break, please add something like

printk(KERN_ERR - hello stupid I2C access \n);

recompile and load the new module, then check whether the line is 
appearing in /var/log/messages or /var/log/syslog when you tune the board.


If this is the case, try to identify which device is issuing the access by 
printing the i2c-address of struct i2c_msg.


HTH,
--

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

Re: dibusb-common.c FE_HAS_LOCK problem

2009-11-23 Thread Mario Bachmann 
Am Mon, 23 Nov 2009 10:01:36 +0100 (CET)
schrieb Patrick Boettcher pboettc...@kernellabs.com:

 Hi Mario,
 
 On Sat, 21 Nov 2009, grafgrim...@gmx.de wrote:
 
  Am Thu, 19 Nov 2009 16:37:18 +0100 (CET)
  schrieb Patrick Boettcher pboettc...@kernellabs.com:
 
  On Sat, 7 Nov 2009, Mario Bachmann wrote:
 
  Hi there,
 
  I tried linux-2.6.31.5 and tuning still does not work:
  tuning to 73800 Hz
  video pid 0x0131, audio pid 0x0132
  status 00 | signal  | snr  | ber 001f | unc  |
  status 00 | signal  | snr  | ber 001f | unc  |
  status 00 | signal  | snr  | ber 001f | unc  |
  status 04 | signal  | snr  | ber 001f | unc  |
 
  With some changes for the following file it works again:
  /usr/src/linux/drivers/media/dvb/dvb-usb/dibusb-common.c
 
  diff -Naur dibusb-common.c-ORIGINAL dibusb-common.c
 
  --- dibusb-common.c-ORIGINAL  2009-11-07 10:30:43.705344308 +0100
  +++ dibusb-common.c   2009-11-07 10:33:49.969345253 +0100
  @@ -133,17 +133,14 @@
 
for (i = 0; i  num; i++) {
/* write/read request */
  - if (i+1  num  (msg[i].flags  I2C_M_RD) == 0
  -(msg[i+1].flags  I2C_M_RD)) {
  + if (i+1  num  (msg[i+1].flags  I2C_M_RD)) {
if (dibusb_i2c_msg(d, msg[i].addr, 
  msg[i].buf,msg[i].len,
msg[i+1].buf,msg[i+1].len)  0)
break;
i++;
  - } else if ((msg[i].flags  I2C_M_RD) == 0) {
  + } else
if (dibusb_i2c_msg(d, msg[i].addr, 
  msg[i].buf,msg[i].len,NULL,0)  0)
break;
  - } else
  - break;
}
 
  Doing it is reverting a fix which avoids that uncontrolled i2c-access from
  userspace is destroying the USB-eeprom.
 
  I understand that this is breaking the tuning for your board. I'm just not
  understanding why.
 
  If you have some time to debug this issue, could you please try the
  following:
 
  One of the devices for your board is trying to do an I2c access which is
  falling into the last 'else'-branch - can you add a printk to find out
  which one it is? The access must be wrongly constructed and must be fixed
  in that driver.
 
  thanks,
 
  PS: if you don't have time to do it, please tell so.
 
  --
 
  Patrick
  http://www.kernellabs.com/
 
  I do not understand exactly. printk what? Could you please give me a
  complete piece of code with the printk command? Would be great!
 
  My printk-tries ends up in an Oops.
 
 There is a
   } else
   break;
 
 sequence in dibusb_i2c_xfer
 
 instead of break, please add something like
 
 printk(KERN_ERR - hello stupid I2C access \n);
 
 recompile and load the new module, then check whether the line is 
 appearing in /var/log/messages or /var/log/syslog when you tune the board.
 
 If this is the case, try to identify which device is issuing the access by 
 printing the i2c-address of struct i2c_msg.
 
 HTH,
 --
 
 Patrick
 http://www.kernellabs.com/

Hello Patrick, 

I tried it with Kernel 2.6.31.6 (same as before). 

I made the printk-change, recompiled and reloaded the modules and pluged in my 
Twinhan Magic Box...
It definately jumps in the last else-branch and shows hello stupid I2C 
access, but no KERN_ERR ?!

dmesg
usb 4-2: new full speed USB device using ohci_hcd and address 4
usb 4-2: configuration #1 chosen from 1 choice
dvb-usb: found a 'TwinhanDTV USB-Ter USB1.1 / Magic Box I / HAMA USB1.1 DVB-T 
device' in cold state, will try to load a firmware
usb 4-2: firmware: requesting dvb-usb-dibusb-5.0.0.11.fw
dvb-usb: downloading firmware from file 'dvb-usb-dibusb-5.0.0.11.fw'
usbcore: registered new interface driver dvb_usb_dibusb_mb
usb 4-2: USB disconnect, address 4
dvb-usb: generic DVB-USB module successfully deinitialized and disconnected.
usb 4-2: new full speed USB device using ohci_hcd and address 5
usb 4-2: configuration #1 chosen from 1 choice
dvb-usb: found a 'TwinhanDTV USB-Ter USB1.1 / Magic Box I / HAMA USB1.1 DVB-T 
device' in warm state.
dvb-usb: will use the device's hardware PID filter (table count: 16).
DVB: registering new adapter (TwinhanDTV USB-Ter USB1.1 / Magic Box I / HAMA 
USB1.1 DVB-T device)
DVB: registering adapter 0 frontend 0 (DiBcom 3000M-B DVB-T)...
dibusb: This device has the Thomson Cable onboard. Which is default.
- hello stupid I2C access 
input: IR-receiver inside an USB DVB receiver as 
/devices/pci:00/:00:04.0/usb4/4-2/input/input5
dvb-usb: schedule remote query interval to 150 msecs.
dvb-usb: TwinhanDTV USB-Ter USB1.1 / Magic Box I / HAMA USB1.1 DVB-T device 
successfully initialized and connected.

tail -30 /var/log/messages
Nov 23 11:49:46 x2 kernel: usb 4-2: new full speed USB device using ohci_hcd 
and address 4
Nov 23 11:49:46 x2 kernel: usb 4-2: configuration #1 chosen from 1 choice
Nov 23 11:49:46 x2 kernel: dvb-usb:

Re: dibusb-common.c FE_HAS_LOCK problem

2009-11-23 Thread Patrick Boettcher 

On Mon, 23 Nov 2009, Mario Bachmann wrote:

sequence in dibusb_i2c_xfer

instead of break, please add something like

printk(KERN_ERR - hello stupid I2C access \n);

recompile and load the new module, then check whether the line is
appearing in /var/log/messages or /var/log/syslog when you tune the board.

If this is the case, try to identify which device is issuing the access by
printing the i2c-address of struct i2c_msg.

HTH,
--

Patrick
http://www.kernellabs.com/


Hello Patrick,

I tried it with Kernel 2.6.31.6 (same as before).

I made the printk-change, recompiled and reloaded the modules and pluged in my 
Twinhan Magic Box...
It definately jumps in the last else-branch and shows hello stupid I2C 
access, but no KERN_ERR ?!


KERN_ERR is a prefix for printk to define the message priority to high. 
(to have it in syslog or messages)



dibusb: This device has the Thomson Cable onboard. Which is default.
- hello stupid I2C access 


Hmm... where is this coming from:

can you write it like that:

else {
printk(...);
dump_stack();
}


Hey, without the break-command, tuning seems to work:
$ tzap pro7 -r
using '/dev/dvb/adapter0/frontend0' and '/dev/dvb/adapter0/demux0'
reading channels from file '/home/grafrotz/.tzap/channels.conf'
tuning to 73800 Hz
video pid 0x0131, audio pid 0x0132
status 00 | signal  | snr  | ber 001f | unc  |
status 1f | signal 0b20 | snr 008d | ber 001f | unc  | FE_HAS_LOCK
status 1f | signal f4dd | snr 0077 | ber 0770 | unc  | FE_HAS_LOCK
status 1f | signal  | snr 008c | ber 0770 | unc  | FE_HAS_LOCK


We are close to identify the drivers in charge for the stupid I2c access.

--

Patrick Boettcher - Kernel Labs
http://www.kernellabs.com/
--
To unsubscribe from this list: send the line unsubscribe linux-media in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: dibusb-common.c FE_HAS_LOCK problem

2009-11-23 Thread grafgrimm77 
Am Mon, 23 Nov 2009 12:11:40 +0100 (CET)
schrieb Patrick Boettcher pboettc...@kernellabs.com:

 On Mon, 23 Nov 2009, Mario Bachmann wrote:
  sequence in dibusb_i2c_xfer
 
  instead of break, please add something like
 
  printk(KERN_ERR - hello stupid I2C access \n);
 
  recompile and load the new module, then check whether the line is
  appearing in /var/log/messages or /var/log/syslog when you tune the board.
 
  If this is the case, try to identify which device is issuing the access by
  printing the i2c-address of struct i2c_msg.
 
  HTH,
  --
 
  Patrick
  http://www.kernellabs.com/
 
  Hello Patrick,
 
  I tried it with Kernel 2.6.31.6 (same as before).
 
  I made the printk-change, recompiled and reloaded the modules and pluged in 
  my Twinhan Magic Box...
  It definately jumps in the last else-branch and shows hello stupid I2C 
  access, but no KERN_ERR ?!
 
 KERN_ERR is a prefix for printk to define the message priority to high. 
 (to have it in syslog or messages)
 
  dibusb: This device has the Thomson Cable onboard. Which is default.
  - hello stupid I2C access 
 
 Hmm... where is this coming from:
 
 can you write it like that:
 
 else {
   printk(...);
   dump_stack();
 }
 
  Hey, without the break-command, tuning seems to work:
  $ tzap pro7 -r
  using '/dev/dvb/adapter0/frontend0' and '/dev/dvb/adapter0/demux0'
  reading channels from file '/home/grafrotz/.tzap/channels.conf'
  tuning to 73800 Hz
  video pid 0x0131, audio pid 0x0132
  status 00 | signal  | snr  | ber 001f | unc  |
  status 1f | signal 0b20 | snr 008d | ber 001f | unc  | 
  FE_HAS_LOCK
  status 1f | signal f4dd | snr 0077 | ber 0770 | unc  | 
  FE_HAS_LOCK
  status 1f | signal  | snr 008c | ber 0770 | unc  | 
  FE_HAS_LOCK
 
 We are close to identify the drivers in charge for the stupid I2c access.
 
 --
 
 Patrick Boettcher - Kernel Labs
 http://www.kernellabs.com/

I use this code now:
} else
printk(KERN_ERR - hello stupid I2C access \n);
dump_stack();
}

dmesg
dvb-usb: TwinhanDTV USB-Ter USB1.1 / Magic Box I / HAMA USB1.1 DVB-T device 
successfully deinitialized and disconnected.
usbcore: deregistering interface driver dvb_usb_dibusb_mb
usb 4-2: new full speed USB device using ohci_hcd and address 6
usb 4-2: configuration #1 chosen from 1 choice
dvb-usb: found a 'TwinhanDTV USB-Ter USB1.1 / Magic Box I / HAMA USB1.1 DVB-T 
device' in cold state, will try to load a firmware
usb 4-2: firmware: requesting dvb-usb-dibusb-5.0.0.11.fw
dvb-usb: downloading firmware from file 'dvb-usb-dibusb-5.0.0.11.fw'
usbcore: registered new interface driver dvb_usb_dibusb_mb
usb 4-2: USB disconnect, address 6
dvb-usb: generic DVB-USB module successfully deinitialized and disconnected.
usb 4-2: new full speed USB device using ohci_hcd and address 7
usb 4-2: configuration #1 chosen from 1 choice
dvb-usb: found a 'TwinhanDTV USB-Ter USB1.1 / Magic Box I / HAMA USB1.1 DVB-T 
device' in warm state.
dvb-usb: will use the device's hardware PID filter (table count: 16).
DVB: registering new adapter (TwinhanDTV USB-Ter USB1.1 / Magic Box I / HAMA 
USB1.1 DVB-T device)
Pid: 255, comm: khubd Tainted: P   A   2.6.31.6 #1
Call Trace:
 [a0042292] ? dibusb_i2c_xfer+0xe2/0x130 [dvb_usb_dibusb_common]
 [81341dc1] ? i2c_transfer+0x91/0xe0
 [a0059c23] ? dib3000_read_reg+0x63/0x80 [dib3000mb]
 [a005ad52] ? dib3000mb_attach+0x52/0xd4 [dib3000mb]
 [a0073268] ? dibusb_dib3000mb_frontend_attach+0x28/0x50 
[dvb_usb_dibusb_mb]
 [a0034ef3] ? dvb_usb_adapter_frontend_init+0x13/0x100 [dvb_usb]
 [a0034837] ? dvb_usb_device_init+0x357/0x630 [dvb_usb]
 [81314021] ? usb_match_one_id+0x31/0xb0
 [a0073050] ? dibusb_probe+0x20/0xa0 [dvb_usb_dibusb_mb]
 [81314962] ? usb_probe_interface+0xa2/0x170
 [812b0e40] ? __device_attach+0x0/0x60
 [812b0ca0] ? driver_probe_device+0x80/0x180
 [812b0e69] ? __device_attach+0x29/0x60
 [812b0e40] ? __device_attach+0x0/0x60
 [812b013c] ? bus_for_each_drv+0x5c/0x90
 [812b0f55] ? device_attach+0x85/0x90
 [812aff45] ? bus_probe_device+0x25/0x40
 [812ae879] ? device_add+0x4d9/0x5a0
 [81313af0] ? usb_set_configuration+0x4a0/0x670
 [812b0e40] ? __device_attach+0x0/0x60
 [8131c1cf] ? generic_probe+0x2f/0xb0
 [812b0ca0] ? driver_probe_device+0x80/0x180
 [812b0e69] ? __device_attach+0x29/0x60
 [812b0e40] ? __device_attach+0x0/0x60
 [812b013c] ? bus_for_each_drv+0x5c/0x90
 [812b0f55] ? device_attach+0x85/0x90
 [812aff45] ? bus_probe_device+0x25/0x40
 [812ae879] ? device_add+0x4d9/0x5a0
 [8130ceda] ? usb_new_device+0x5a/0xd0
 [8130e220] ? hub_thread+0x7e0/0x1040
 [810564c6] ? dequeue_task_fair+0x46/0x190
 [81074e70] ?

Re: dibusb-common.c FE_HAS_LOCK problem

2009-11-23 Thread Patrick Boettcher 

On Mon, 23 Nov 2009, grafgrim...@gmx.de wrote:

[..]
- hello stupid I2C access 
Pid: 255, comm: khubd Tainted: P   A   2.6.31.6 #1
Call Trace:
[a0042292] ? dibusb_i2c_xfer+0xe2/0x130 [dvb_usb_dibusb_common]
[81341dc1] ? i2c_transfer+0x91/0xe0
[a0059081] ? dib3000_write_reg+0x51/0x70 [dib3000mb]
[a00855c9] ? dvb_pll_attach+0xa9/0x238 [dvb_pll]
[..]


Voila.

This is the access with makes the dvb-pll-driver not create the tuner 
driver.


This is (I forgot the correct name) read-without-write-i2caccess. It is 
bad handled by the dibusb-driver and it can destroy the eeprom on the USB 
side.


Please try whether the attached patch fixes the whole situation for you.

If so, please send back a line like this:

Tested-by: Your name email

thanks,
--

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

Re: dibusb-common.c FE_HAS_LOCK problem

2009-11-23 Thread Patrick Boettcher 

On Mon, 23 Nov 2009, Patrick Boettcher wrote:


On Mon, 23 Nov 2009, grafgrim...@gmx.de wrote:

[..]
- hello stupid I2C access 
Pid: 255, comm: khubd Tainted: P   A   2.6.31.6 #1
Call Trace:
[a0042292] ? dibusb_i2c_xfer+0xe2/0x130 [dvb_usb_dibusb_common]
[81341dc1] ? i2c_transfer+0x91/0xe0
[a0059081] ? dib3000_write_reg+0x51/0x70 [dib3000mb]
[a00855c9] ? dvb_pll_attach+0xa9/0x238 [dvb_pll]
[..]


Voila.

This is the access with makes the dvb-pll-driver not create the tuner driver.

This is (I forgot the correct name) read-without-write-i2caccess. It is bad 
handled by the dibusb-driver and it can destroy the eeprom on the USB side.


Please try whether the attached patch fixes the whole situation for you.

If so, please send back a line like this:

Tested-by: Your name email


The patch attached.

--

Patrick Boettcher - Kernel Labs
http://www.kernellabs.com/diff -r 52da57b5e800 linux/drivers/media/dvb/dvb-usb/dibusb-common.c
--- a/linux/drivers/media/dvb/dvb-usb/dibusb-common.c   Thu Nov 19 17:15:37 
2009 +0100
+++ b/linux/drivers/media/dvb/dvb-usb/dibusb-common.c   Mon Nov 23 13:20:10 
2009 +0100
@@ -142,8 +142,13 @@
} else if ((msg[i].flags  I2C_M_RD) == 0) {
if (dibusb_i2c_msg(d, msg[i].addr, 
msg[i].buf,msg[i].len,NULL,0)  0)
break;
-   } else
-   break;
+   } else if (msg[i].addr != 0x50) {
+   /* 0x50 is the address of the eeprom - we need to 
protect it
+* from dibusb's bad i2c implementation: reads without
+* writing the offset before are forbidden */
+   if (dibusb_i2c_msg(d, msg[i].addr, NULL, 0, msg[i].buf, 
msg[i].len)  0)
+   break;
+   }
}
 
mutex_unlock(d-i2c_mutex);

Re: dibusb-common.c FE_HAS_LOCK problem

2009-11-23 Thread grafgrimm77 
Am Mon, 23 Nov 2009 14:19:10 +0100 (CET)
schrieb Patrick Boettcher pboettc...@kernellabs.com:

 On Mon, 23 Nov 2009, Patrick Boettcher wrote:
 
  On Mon, 23 Nov 2009, grafgrim...@gmx.de wrote:
  [..]
  - hello stupid I2C access 
  Pid: 255, comm: khubd Tainted: P   A   2.6.31.6 #1
  Call Trace:
  [a0042292] ? dibusb_i2c_xfer+0xe2/0x130 [dvb_usb_dibusb_common]
  [81341dc1] ? i2c_transfer+0x91/0xe0
  [a0059081] ? dib3000_write_reg+0x51/0x70 [dib3000mb]
  [a00855c9] ? dvb_pll_attach+0xa9/0x238 [dvb_pll]
  [..]
 
  Voila.
 
  This is the access with makes the dvb-pll-driver not create the tuner 
  driver.
 
  This is (I forgot the correct name) read-without-write-i2caccess. It is bad 
  handled by the dibusb-driver and it can destroy the eeprom on the USB side.
 
  Please try whether the attached patch fixes the whole situation for you.
 
  If so, please send back a line like this:
 
  Tested-by: Your name email
 
 The patch attached.
 
 --
 
 Patrick Boettcher - Kernel Labs
 http://www.kernellabs.com/

Hi Patrick, 

your patch [dibusb-common-fix  text/PLAIN (1054 bytes)] works here. 

Tested-by: Mario Bachmann grafgrim...@gmx.de

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

Re: dibusb-common.c FE_HAS_LOCK problem

2009-11-21 Thread grafgrimm77 
Am Thu, 19 Nov 2009 16:37:18 +0100 (CET)
schrieb Patrick Boettcher pboettc...@kernellabs.com:

 On Sat, 7 Nov 2009, Mario Bachmann wrote:
 
  Hi there,
 
  I tried linux-2.6.31.5 and tuning still does not work:
  tuning to 73800 Hz
  video pid 0x0131, audio pid 0x0132
  status 00 | signal  | snr  | ber 001f | unc  |
  status 00 | signal  | snr  | ber 001f | unc  |
  status 00 | signal  | snr  | ber 001f | unc  |
  status 04 | signal  | snr  | ber 001f | unc  |
 
  With some changes for the following file it works again:
  /usr/src/linux/drivers/media/dvb/dvb-usb/dibusb-common.c
 
  diff -Naur dibusb-common.c-ORIGINAL dibusb-common.c
 
  --- dibusb-common.c-ORIGINAL2009-11-07 10:30:43.705344308 +0100
  +++ dibusb-common.c 2009-11-07 10:33:49.969345253 +0100
  @@ -133,17 +133,14 @@
 
  for (i = 0; i  num; i++) {
  /* write/read request */
  -   if (i+1  num  (msg[i].flags  I2C_M_RD) == 0
  -  (msg[i+1].flags  I2C_M_RD)) {
  +   if (i+1  num  (msg[i+1].flags  I2C_M_RD)) {
  if (dibusb_i2c_msg(d, msg[i].addr, 
  msg[i].buf,msg[i].len,
  msg[i+1].buf,msg[i+1].len)  0)
  break;
  i++;
  -   } else if ((msg[i].flags  I2C_M_RD) == 0) {
  +   } else
  if (dibusb_i2c_msg(d, msg[i].addr, 
  msg[i].buf,msg[i].len,NULL,0)  0)
  break;
  -   } else
  -   break;
  }
 
 Doing it is reverting a fix which avoids that uncontrolled i2c-access from 
 userspace is destroying the USB-eeprom.
 
 I understand that this is breaking the tuning for your board. I'm just not 
 understanding why.
 
 If you have some time to debug this issue, could you please try the 
 following:
 
 One of the devices for your board is trying to do an I2c access which is 
 falling into the last 'else'-branch - can you add a printk to find out 
 which one it is? The access must be wrongly constructed and must be fixed 
 in that driver.
 
 thanks,
 
 PS: if you don't have time to do it, please tell so.
 
 --
 
 Patrick
 http://www.kernellabs.com/

I do not understand exactly. printk what? Could you please give me a 
complete piece of code with the printk command? Would be great! 

My printk-tries ends up in an Oops. 

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

Re: dibusb-common.c FE_HAS_LOCK problem

2009-11-19 Thread Patrick Boettcher 

On Sat, 7 Nov 2009, Mario Bachmann wrote:


Hi there,

I tried linux-2.6.31.5 and tuning still does not work:
tuning to 73800 Hz
video pid 0x0131, audio pid 0x0132
status 00 | signal  | snr  | ber 001f | unc  |
status 00 | signal  | snr  | ber 001f | unc  |
status 00 | signal  | snr  | ber 001f | unc  |
status 04 | signal  | snr  | ber 001f | unc  |

With some changes for the following file it works again:
/usr/src/linux/drivers/media/dvb/dvb-usb/dibusb-common.c

diff -Naur dibusb-common.c-ORIGINAL dibusb-common.c

--- dibusb-common.c-ORIGINAL2009-11-07 10:30:43.705344308 +0100
+++ dibusb-common.c 2009-11-07 10:33:49.969345253 +0100
@@ -133,17 +133,14 @@

for (i = 0; i  num; i++) {
/* write/read request */
-   if (i+1  num  (msg[i].flags  I2C_M_RD) == 0
-  (msg[i+1].flags  I2C_M_RD)) {
+   if (i+1  num  (msg[i+1].flags  I2C_M_RD)) {
if (dibusb_i2c_msg(d, msg[i].addr, 
msg[i].buf,msg[i].len,
msg[i+1].buf,msg[i+1].len)  0)
break;
i++;
-   } else if ((msg[i].flags  I2C_M_RD) == 0) {
+   } else
if (dibusb_i2c_msg(d, msg[i].addr, 
msg[i].buf,msg[i].len,NULL,0)  0)
break;
-   } else
-   break;
}


Doing it is reverting a fix which avoids that uncontrolled i2c-access from 
userspace is destroying the USB-eeprom.


I understand that this is breaking the tuning for your board. I'm just not 
understanding why.


If you have some time to debug this issue, could you please try the 
following:


One of the devices for your board is trying to do an I2c access which is 
falling into the last 'else'-branch - can you add a printk to find out 
which one it is? The access must be wrongly constructed and must be fixed 
in that driver.


thanks,

PS: if you don't have time to do it, please tell so.

--

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

dibusb-common.c FE_HAS_LOCK problem

2009-11-07 Thread Mario Bachmann 
Hi there, 

I tried linux-2.6.31.5 and tuning still does not work: 
tuning to 73800 Hz
video pid 0x0131, audio pid 0x0132
status 00 | signal  | snr  | ber 001f | unc  | 
status 00 | signal  | snr  | ber 001f | unc  | 
status 00 | signal  | snr  | ber 001f | unc  | 
status 04 | signal  | snr  | ber 001f | unc  | 

With some changes for the following file it works again:
/usr/src/linux/drivers/media/dvb/dvb-usb/dibusb-common.c

diff -Naur dibusb-common.c-ORIGINAL dibusb-common.c

--- dibusb-common.c-ORIGINAL2009-11-07 10:30:43.705344308 +0100
+++ dibusb-common.c 2009-11-07 10:33:49.969345253 +0100
@@ -133,17 +133,14 @@
 
for (i = 0; i  num; i++) {
/* write/read request */
-   if (i+1  num  (msg[i].flags  I2C_M_RD) == 0
-  (msg[i+1].flags  I2C_M_RD)) {
+   if (i+1  num  (msg[i+1].flags  I2C_M_RD)) {
if (dibusb_i2c_msg(d, msg[i].addr, 
msg[i].buf,msg[i].len,
msg[i+1].buf,msg[i+1].len)  0)
break;
i++;
-   } else if ((msg[i].flags  I2C_M_RD) == 0) {
+   } else
if (dibusb_i2c_msg(d, msg[i].addr, 
msg[i].buf,msg[i].len,NULL,0)  0)
break;
-   } else
-   break;
}
 
mutex_unlock(d-i2c_mutex);


With this patch, tuning works again:
tuning to 73800 Hz
video pid 0x0131, audio pid 0x0132
status 00 | signal  | snr  | ber 001f | unc  | 
status 1f | signal  | snr 008d | ber 001f | unc  | FE_HAS_LOCK
status 1f | signal  | snr 00a1 | ber 05a4 | unc 0043 | FE_HAS_LOCK
status 1f | signal  | snr 00a3 | ber 05a4 | unc 0043 | FE_HAS_LOCK
status 1f | signal  | snr 009d | ber  | unc  | FE_HAS_LOCK


This is my DVB-T-Box (dmesg):
usb 4-2: new full speed USB device using ohci_hcd and address 6
usb 4-2: configuration #1 chosen from 1 choice
dvb-usb: found a 'TwinhanDTV USB-Ter USB1.1 / Magic Box I / HAMA USB1.1
DVB-T device' in warm state. dvb-usb: will use the device's hardware
PID filter (table count: 16). DVB: registering new adapter (TwinhanDTV
USB-Ter USB1.1 / Magic Box I / HAMA USB1.1 DVB-T device) DVB:
registering adapter 0 frontend 0 (DiBcom 3000M-B DVB-T)... dibusb: This
device has the Thomson Cable onboard. Which is default. input:
IR-receiver inside an USB DVB receiver
as /devices/pci:00/:00:04.0/usb4/4-2/input/input6 dvb-usb:
schedule remote query interval to 150 msecs. dvb-usb: TwinhanDTV
USB-Ter USB1.1 / Magic Box I / HAMA USB1.1 DVB-T device successfully
initialized and connected.

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