Re: regression: (repost) firmware loading for dvico dual digital 4
Hi Mauro, thanks for taking the time to look at this. On Mon, Jun 30, 2014 at 11:56:33AM -0300, Mauro Carvalho Chehab wrote: > Em Mon, 30 Jun 2014 23:19:46 +1000 > Vincent McIntyre escreveu: > > > Hi, > > > > I am reposting this since it got ignored/missed last time around... > > > > On 5/14/14, Vincent McIntyre wrote: > > > Hi, > > > > > > Antti asked me to report this. > > > > > > I built the latest media_build git on Ubuntu 12.04, with 3.8.0 kernel, > > > using './build --main-git'. > > > The attached tarball has the relvant info. > > > > > > Without the media_build modules, firmware loads fine (file dmesg.1) > > > Once I build and install the media_build modules, the firmware no > > > longer loads. (dmesg.2) > > > > > > The firmware loading issue appears to have been reported to ubuntu (a > > > later kernel, 3.11) with a possible fix proposed, see > > > https://bugs.launchpad.net/ubuntu/+source/linux/+bug/1291459 > > > > > > I can post lspci etc details if people want. > > > > > > > An updated version of the tar file is attached. > > > > dmesg.1 is from 3.8.0-38 plus media-build modules and shows the > > firmware loading issue. > > The media-build HEAD revision was > > commit e4a8d40f63afa8b0276ea7758d9b4d32e64a964d > > Author: Hans Verkuil > > Date: Wed Jun 18 10:27:51 2014 +0200 > > > > dmesg.2 is from 3.8.0-42 with the ubuntu-provided modules and does not > > show the issue. > > > > The issue occurs in later ubuntu kernels, 3.11 as noted previously > > and 3.13.0-30. > > > > The OS is ubuntu 12.04 LTS, amd64. > > > > I looked into bisecting this but could not figure out a procedure > > since the 'build' script tries really hard to use the latest > > media-build and kernel sources. It looks like one has to run the > > media-build 'make' against a checkout of the vanilla kernel that > > roughly corresponds in time (or at least is not from a time later than > > the current media-build revision that is checked out). > > > > > > > Please respond this time > > Next time, please add the logs directly at the email, as this makes > clearer about what's the problem and what driver has the issues. > Ok. I wanted to ensure it did not get mangled into unreadability by the journey through various email systems. > Anyway, based on this: > > [ 16.332247] xc2028 0-0061: Loading firmware for type=BASE F8MHZ (3), id > . > [ 16.344378] cxusb: i2c wr: len=64 is too big! > > I suspect that the enclosed patch should fix your issue. Please test. If it > works, please reply to this email with: > Tested-by: your name > The patch is working for me. My tested-by is inline below. Test procedure: - git checkout git://linuxtv.org/media_build.git - cd media_build - ./build --main-git - grep "define MAX_XFER_SIZE" media/drivers/media/usb/dvb-usb/cxusb.c #define MAX_XFER_SIZE 64 - vi media/drivers/media/usb/dvb-usb/cxusb.c - grep "define MAX_XFER_SIZE" media/drivers/media/usb/dvb-usb/cxusb.c #define MAX_XFER_SIZE 80 - cd media; make -C ../v4l; cd .. - sudo make install - sudo halt - (after boot) dmesg - try to tune one of the receivers - works ok - dmesg The final dmesg output is inline below. > Cheers, > Mauro > > - > > cxusb: increase buffer lenght to 80 bytes > > As reported by Vincent: > [ 16.332247] xc2028 0-0061: Loading firmware for type=BASE F8MHZ (3), > id . > [ 16.344378] cxusb: i2c wr: len=64 is too big! > > 64 bytes is too short for firmware load on this device. So, increase it > to 80 bytes. > > Reported-by: Vincent McIntyre > Signed-off-by: Mauro Carvalho Chehab Tested-by: Vincent McIntyre > > diff --git a/drivers/media/usb/dvb-usb/cxusb.c > b/drivers/media/usb/dvb-usb/cxusb.c > index 6acde5ee4324..a22726ccca64 100644 > --- a/drivers/media/usb/dvb-usb/cxusb.c > +++ b/drivers/media/usb/dvb-usb/cxusb.c > @@ -44,7 +44,7 @@ > #include "atbm8830.h" > > /* Max transfer size done by I2C transfer functions */ > -#define MAX_XFER_SIZE 64 > +#define MAX_XFER_SIZE 80 > > /* debug */ > static int dvb_usb_cxusb_debug; > Final dmesg [0.00] Initializing cgroup subsys cpuset [0.00] Initializing cgroup subsys cpu [0.00] Linux version 3.8.0-38-generic (buildd@lamiak) (gcc version 4.6.3 (Ubuntu/Linaro 4.6.3-1ubuntu5) ) #56~precise1-Ubuntu SMP Thu Mar 13 16:22:48 UTC 2014 (Ubuntu 3.8.0-38.56~precise1-generic 3.8.13.19) [0.00] Command line: BOOT_IMAGE=/boot/vmlinuz-3.8.0-38-generic root=UUID=00d24ba0-1c1a-420b-a0de-e811e8a8b90c ro [0.00] KERNEL supported cpus: [0.00] Intel GenuineIntel [0.00] AMD AuthenticAMD [0.00] Centaur CentaurHauls [0.00] e820: BIOS-provided physical RAM map: [0.00] BIOS-e820: [mem 0x-0x0009ebff] usable [0.00] BIOS-e820: [mem 0x0009ec00-0x0009] reserved [0.00] BIOS-e820: [mem 0x000e-0x000f] reserved [0.00] BIOS-e820: [m
Re: regression: (repost) firmware loading for dvico dual digital 4
Em Mon, 30 Jun 2014 23:19:46 +1000 Vincent McIntyre escreveu: > Hi, > > I am reposting this since it got ignored/missed last time around... > > On 5/14/14, Vincent McIntyre wrote: > > Hi, > > > > Antti asked me to report this. > > > > I built the latest media_build git on Ubuntu 12.04, with 3.8.0 kernel, > > using './build --main-git'. > > The attached tarball has the relvant info. > > > > Without the media_build modules, firmware loads fine (file dmesg.1) > > Once I build and install the media_build modules, the firmware no > > longer loads. (dmesg.2) > > > > The firmware loading issue appears to have been reported to ubuntu (a > > later kernel, 3.11) with a possible fix proposed, see > > https://bugs.launchpad.net/ubuntu/+source/linux/+bug/1291459 > > > > I can post lspci etc details if people want. > > > > An updated version of the tar file is attached. > > dmesg.1 is from 3.8.0-38 plus media-build modules and shows the > firmware loading issue. > The media-build HEAD revision was > commit e4a8d40f63afa8b0276ea7758d9b4d32e64a964d > Author: Hans Verkuil > Date: Wed Jun 18 10:27:51 2014 +0200 > > dmesg.2 is from 3.8.0-42 with the ubuntu-provided modules and does not > show the issue. > > The issue occurs in later ubuntu kernels, 3.11 as noted previously > and 3.13.0-30. > > The OS is ubuntu 12.04 LTS, amd64. > > I looked into bisecting this but could not figure out a procedure > since the 'build' script tries really hard to use the latest > media-build and kernel sources. It looks like one has to run the > media-build 'make' against a checkout of the vanilla kernel that > roughly corresponds in time (or at least is not from a time later than > the current media-build revision that is checked out). > > > Please respond this time Next time, please add the logs directly at the email, as this makes clearer about what's the problem and what driver has the issues. Anyway, based on this: [ 16.332247] xc2028 0-0061: Loading firmware for type=BASE F8MHZ (3), id . [ 16.344378] cxusb: i2c wr: len=64 is too big! I suspect that the enclosed patch should fix your issue. Please test. If it works, please reply to this email with: Tested-by: your name Cheers, Mauro - cxusb: increase buffer lenght to 80 bytes As reported by Vincent: [ 16.332247] xc2028 0-0061: Loading firmware for type=BASE F8MHZ (3), id . [ 16.344378] cxusb: i2c wr: len=64 is too big! 64 bytes is too short for firmware load on this device. So, increase it to 80 bytes. Reported-by: Vincent McIntyre Signed-off-by: Mauro Carvalho Chehab diff --git a/drivers/media/usb/dvb-usb/cxusb.c b/drivers/media/usb/dvb-usb/cxusb.c index 6acde5ee4324..a22726ccca64 100644 --- a/drivers/media/usb/dvb-usb/cxusb.c +++ b/drivers/media/usb/dvb-usb/cxusb.c @@ -44,7 +44,7 @@ #include "atbm8830.h" /* Max transfer size done by I2C transfer functions */ -#define MAX_XFER_SIZE 64 +#define MAX_XFER_SIZE 80 /* debug */ static int dvb_usb_cxusb_debug; -- 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
regression: (repost) firmware loading for dvico dual digital 4
Hi, I am reposting this since it got ignored/missed last time around... On 5/14/14, Vincent McIntyre wrote: > Hi, > > Antti asked me to report this. > > I built the latest media_build git on Ubuntu 12.04, with 3.8.0 kernel, > using './build --main-git'. > The attached tarball has the relvant info. > > Without the media_build modules, firmware loads fine (file dmesg.1) > Once I build and install the media_build modules, the firmware no > longer loads. (dmesg.2) > > The firmware loading issue appears to have been reported to ubuntu (a > later kernel, 3.11) with a possible fix proposed, see > https://bugs.launchpad.net/ubuntu/+source/linux/+bug/1291459 > > I can post lspci etc details if people want. > An updated version of the tar file is attached. dmesg.1 is from 3.8.0-38 plus media-build modules and shows the firmware loading issue. The media-build HEAD revision was commit e4a8d40f63afa8b0276ea7758d9b4d32e64a964d Author: Hans Verkuil Date: Wed Jun 18 10:27:51 2014 +0200 dmesg.2 is from 3.8.0-42 with the ubuntu-provided modules and does not show the issue. The issue occurs in later ubuntu kernels, 3.11 as noted previously and 3.13.0-30. The OS is ubuntu 12.04 LTS, amd64. I looked into bisecting this but could not figure out a procedure since the 'build' script tries really hard to use the latest media-build and kernel sources. It looks like one has to run the media-build 'make' against a checkout of the vanilla kernel that roughly corresponds in time (or at least is not from a time later than the current media-build revision that is checked out). Please respond this time Vince dmesg.tar.xz Description: Binary data
