ioctl FE_GET_INFO hangs with DViCO FusionHDTV DVB-T Dual Digital 4 card

Bug #1291459 reported by Ben Stanley on 2014-03-12
18
This bug affects 3 people
Affects Status Importance Assigned to Milestone
linux (Ubuntu)
Medium
Unassigned
linux-firmware (Ubuntu)
Medium
Unassigned

Bug Description

Top level symptom:
mythtv-backend fails to listen for client connections.
It stops at: (strace mythbackend)
open("/dev/dvb/adapter1/frontend0", O_RDWR|O_NONBLOCK) = 16
ioctl(16, FE_GET_INFO

me-tv also hangs in a similar manner.

I expected the ioctl call to succeed, and for the top level applications to function properly. Instead, they hang.

The machine has 3 dvb tuners as follows:
**************** Adapter 0
Mar 12 22:32:53 mythtv kernel: [ 17.428195] input: Budget-CI dvb ir receiver saa7146 (0) as /devices/pci0000:00/0000:00:1e.0/0000:05
:00.0/rc/rc0/input13
Mar 12 22:32:53 mythtv kernel: [ 17.428251] rc0: Budget-CI dvb ir receiver saa7146 (0) as /devices/pci0000:00/0000:00:1e.0/0000:05:0
0.0/rc/rc0
Mar 12 22:32:53 mythtv kernel: [ 17.432801] budget_ci dvb 0000:05:00.0: DVB: registering adapter 0 frontend 0 (Philips TDA10045H DVB
-T)...
**************** Adapter 1
Mar 12 22:32:53 mythtv kernel: [ 17.646727] DVB: registering new adapter (DViCO FusionHDTV DVB-T Dual Digital 4)
Mar 12 22:32:53 mythtv kernel: [ 17.797366] usb 3-1: DVB: registering adapter 1 frontend 0 (Zarlink ZL10353 DVB-T)...
**************** Adapter 2
Mar 12 22:32:53 mythtv kernel: [ 17.831769] DVB: registering new adapter (DViCO FusionHDTV DVB-T Dual Digital 4)
Mar 12 22:32:53 mythtv kernel: [ 17.882250] cxusb: No IR receiver detected on this device.
Mar 12 22:32:53 mythtv kernel: [ 17.882258] usb 3-2: DVB: registering adapter 2 frontend 0 (Zarlink ZL10353 DVB-T)...

There appears to be a problem loading the firmware for the xc2028 in the DViCO FusionHDTV card:

Mar 13 02:07:59 mythtv kernel: [ 37.348226] xc2028 10-0061: Loading firmware for type=BASE F8MHZ (3), id 0000000000000000.
Mar 13 02:07:59 mythtv kernel: [ 37.360226] cxusb: i2c wr: len=64 is too big!
Mar 13 02:07:59 mythtv kernel: [ 37.360226]
Mar 13 02:07:59 mythtv kernel: [ 37.360230] xc2028 10-0061: i2c output error: rc = -95 (should be 64)
Mar 13 02:07:59 mythtv kernel: [ 37.360231] xc2028 10-0061: -95 returned from send
Mar 13 02:07:59 mythtv kernel: [ 37.360234] xc2028 10-0061: Error -22 while loading base firmware
Mar 13 02:07:59 mythtv kernel: [ 37.412233] xc2028 11-0061: Loading firmware for type=BASE F8MHZ (3), id 0000000000000000.
Mar 13 02:07:59 mythtv kernel: [ 37.424360] cxusb: i2c wr: len=64 is too big!
Mar 13 02:07:59 mythtv kernel: [ 37.424360]
Mar 13 02:07:59 mythtv kernel: [ 37.424364] xc2028 11-0061: i2c output error: rc = -95 (should be 64)
Mar 13 02:07:59 mythtv kernel: [ 37.424365] xc2028 11-0061: -95 returned from send
Mar 13 02:07:59 mythtv kernel: [ 37.424368] xc2028 11-0061: Error -22 while loading base firmware
Mar 13 02:07:59 mythtv kernel: [ 37.428486] xc2028 10-0061: Loading firmware for type=BASE F8MHZ (3), id 0000000000000000.
Mar 13 02:07:59 mythtv kernel: [ 37.492247] xc2028 11-0061: Loading firmware for type=BASE F8MHZ (3), id 0000000000000000.

The firmware is loaded from the file xc3028-v27.fw:
Mar 13 02:07:42 mythtv kernel: [ 18.108746] xc2028 11-0061: creating new instance
Mar 13 02:07:42 mythtv kernel: [ 18.108748] xc2028 11-0061: type set to XCeive xc2028/xc3028 tuner
Mar 13 02:07:42 mythtv kernel: [ 18.108801] xc2028 11-0061: Loading 80 firmware images from xc3028-v27.fw, type: xc2028 firmware, ver 2.7
Mar 13 02:07:42 mythtv kernel: [ 18.109670] dvb-usb: DViCO FusionHDTV DVB-T Dual Digital 4 successfully initialized and connected.

The firmware file /lib/firmware/xc3028-v27.fw belongs to the linux-firmware-nonfree 1.14.ubuntu1 package. I have located instructions on the origin of this file (http://www.linuxtv.org/wiki/index.php/Xceive_XC3028/XC2028#How_to_Obtain_the_Firmware)
and I have verified that the firmware file is identical to the one obtained by that method.

The DViCO FusionHDTV card has been used for several years in this machine. This problem only occurred after upgrading to saucy salamander.

ProblemType: Bug
DistroRelease: Ubuntu 13.10
Package: linux-image-3.11.0-18-generic 3.11.0-18.32
ProcVersionSignature: Ubuntu 3.11.0-18.32-generic 3.11.10.4
Uname: Linux 3.11.0-18-generic x86_64
ApportVersion: 2.12.5-0ubuntu2.2
Architecture: amd64
AudioDevicesInUse:
 USER PID ACCESS COMMAND
 /dev/snd/controlC1: loungeroom 2246 F.... pulseaudio
 /dev/snd/controlC0: loungeroom 2246 F.... pulseaudio
Date: Thu Mar 13 02:28:43 2014
HibernationDevice: RESUME=UUID=335a7d97-3ccb-47e1-a25a-78717e9f04a7
IwConfig:
 eth1 no wireless extensions.

 lo no wireless extensions.
MachineType: Gigabyte Technology Co., Ltd. EP43-DS3L
MarkForUpload: True
ProcEnviron:
 TERM=xterm
 PATH=(custom, no user)
 LANG=en_AU.UTF-8
 SHELL=/bin/bash
ProcFB: 0 radeondrmfb
ProcKernelCmdLine: BOOT_IMAGE=/vmlinuz-3.11.0-18-generic root=/dev/mapper/Ubuntu-precise_root ro radeon.audio=1 crashkernel=384M-2G:64M,2G-:128M quiet splash vt.handoff=7
PulseList:
 Error: command ['pacmd', 'list'] failed with exit code 1: Home directory not accessible: Permission denied
 No PulseAudio daemon running, or not running as session daemon.
RelatedPackageVersions:
 linux-restricted-modules-3.11.0-18-generic N/A
 linux-backports-modules-3.11.0-18-generic N/A
 linux-firmware 1.116.2
RfKill: Error: [Errno 2] No such file or directory: 'rfkill'
SourcePackage: linux
UpgradeStatus: Upgraded to saucy on 2014-02-20 (20 days ago)
WifiSyslog:

dmi.bios.date: 09/22/2008
dmi.bios.vendor: Award Software International, Inc.
dmi.bios.version: F8
dmi.board.name: EP43-DS3L
dmi.board.vendor: Gigabyte Technology Co., Ltd.
dmi.chassis.type: 3
dmi.chassis.vendor: Gigabyte Technology Co., Ltd.
dmi.modalias: dmi:bvnAwardSoftwareInternational,Inc.:bvrF8:bd09/22/2008:svnGigabyteTechnologyCo.,Ltd.:pnEP43-DS3L:pvr:rvnGigabyteTechnologyCo.,Ltd.:rnEP43-DS3L:rvr:cvnGigabyteTechnologyCo.,Ltd.:ct3:cvr:
dmi.product.name: EP43-DS3L
dmi.sys.vendor: Gigabyte Technology Co., Ltd.

Ben Stanley (ben-stanley) wrote :

This change was made by a bot.

Changed in linux (Ubuntu):
status: New → Confirmed

Would it be possible for you to test the latest upstream kernel? Refer to https://wiki.ubuntu.com/KernelMainlineBuilds . Please test the latest v3.13 kernel[0].

If this bug is fixed in the mainline kernel, please add the following tag 'kernel-fixed-upstream'.

If the mainline kernel does not fix this bug, please add the tag: 'kernel-bug-exists-upstream'.

If you are unable to test the mainline kernel, for example it will not boot, please add the tag: 'kernel-unable-to-test-upstream'.
Once testing of the upstream kernel is complete, please mark this bug as "Confirmed".

Thanks in advance.

[0] http://kernel.ubuntu.com/~kernel-ppa/mainline/v3.14-rc6-trusty/

Changed in linux (Ubuntu):
importance: Undecided → Medium
Changed in linux-firmware (Ubuntu):
importance: Undecided → Medium
Changed in linux (Ubuntu):
status: Confirmed → Incomplete
Changed in linux-firmware (Ubuntu):
status: New → Confirmed
Ben Stanley (ben-stanley) wrote :

Tested with Linux version 3.14.0-031400rc6-generic (apw@gomeisa) (gcc version 4.6.3 (Ubuntu/Linaro 4.6.3-1ubuntu5) ) #201403100035 SMP Mon Mar 10 04:36:54 UTC 2014

The firmware loading error is now repeated many times:
Mar 13 21:50:53 mythtv kernel: [ 42.816252] xc2028 10-0061: Loading firmware for type=BASE F8MHZ (3), id 0000000000000000.
Mar 13 21:50:53 mythtv kernel: [ 42.828256] cxusb: i2c wr: len=64 is too big!
Mar 13 21:50:53 mythtv kernel: [ 42.828256]
Mar 13 21:50:53 mythtv kernel: [ 42.828260] xc2028 10-0061: i2c output error: rc = -95 (should be 64)
Mar 13 21:50:53 mythtv kernel: [ 42.828262] xc2028 10-0061: -95 returned from send
Mar 13 21:50:53 mythtv kernel: [ 42.828290] xc2028 10-0061: Error -22 while loading base firmware
Mar 13 21:50:53 mythtv kernel: [ 42.900304] xc2028 10-0061: Loading firmware for type=BASE F8MHZ (3), id 0000000000000000.
Mar 13 21:50:53 mythtv kernel: [ 42.912314] cxusb: i2c wr: len=64 is too big!
Mar 13 21:50:53 mythtv kernel: [ 42.912314]
Mar 13 21:50:53 mythtv kernel: [ 42.912318] xc2028 10-0061: i2c output error: rc = -95 (should be 64)
Mar 13 21:50:53 mythtv kernel: [ 42.912320] xc2028 10-0061: -95 returned from send
Mar 13 21:50:53 mythtv kernel: [ 42.912344] xc2028 10-0061: Error -22 while loading base firmware
Mar 13 21:50:53 mythtv kernel: [ 42.984236] xc2028 10-0061: Loading firmware for type=BASE F8MHZ (3), id 0000000000000000.
<repeats>

However, mythbackend no longer hangs, and continues to start listening on its server port:
Mar 13 22:05:31 mythtv mythbackend: mythbackend[4117]: I CoreContext serverpool.cpp:399 (listen) Listening on TCP 127.0.0.1:6544
Mar 13 22:05:31 mythtv mythbackend: mythbackend[4117]: I CoreContext serverpool.cpp:399 (listen) Listening on TCP 192.168.1.10:6544
Mar 13 22:05:31 mythtv mythbackend: mythbackend[4117]: I CoreContext serverpool.cpp:399 (listen) Listening on TCP [::1]:6544
Mar 13 22:05:31 mythtv mythbackend: mythbackend[4117]: I CoreContext serverpool.cpp:399 (listen) Listening on TCP [fe80::21f:d0ff:fe5d:27a6%eth1]:6544

mythbackend did not make it this far with the previous 3.11 kernel
Linux version 3.11.0-18-generic (buildd@toyol) (gcc version 4.8.1 (Ubuntu/Linaro 4.8.1-10ubuntu8) ) #32-Ubuntu SMP Tue Feb 18 21:11:14 UTC 2014 (Ubuntu 3.11.0-18.32-generic 3.11.10.4)

It would appear that the ioctl FE_GET_INFO is succeeding with the upstream 3.14 kernel, whereas it failed with the ubuntu 3.11 kernel.

However, the firmware error messages appear worse with the upstream 3.14 kernel than with the ubuntu 3.11 kernel.

Changed in linux (Ubuntu):
status: Incomplete → Confirmed
summary: - xc2028 11-0061: Error -22 while loading base firmware
+ ioctl FE_GET_INFO hangs with DViCO FusionHDTV
summary: - ioctl FE_GET_INFO hangs with DViCO FusionHDTV
+ ioctl FE_GET_INFO hangs with DViCO FusionHDTV DVB-T Dual Digital 4 card
tags: added: kernel-fixed-upstream
tags: added: kernel-bug-exists-upstream
removed: kernel-fixed-upstream
Ben Stanley (ben-stanley) wrote :

Furhter testing has revealed that the DViCO FusionHDTV tuners don't work with mythtv or with me-tv (running upstream 3.14 kernel). The Budget-CI card is working OK with me-tv.

It appears that the firmware loading problems are real.

Vince McIntyre (vmcintyr) wrote :

I see the same firmware loading issue. I assumed the problem was in tuner_xc2028, as I don't see any related messages in dmesg after the firmware blob fails to load:

Mar 26 22:03:20 localhost kernel: [ 11.567369] xc2028 0-0061: Loading firmware for type=BASE F8MHZ (3), id 0000000000000
000.
Mar 26 22:03:20 localhost kernel: [ 11.576247] cxusb: i2c wr: len=64 is too big!
Mar 26 22:03:20 localhost kernel: [ 11.576247]
Mar 26 22:03:20 localhost kernel: [ 11.576253] xc2028 0-0061: i2c output error: rc = -95 (should be 64)
Mar 26 22:03:20 localhost kernel: [ 11.576255] xc2028 0-0061: -95 returned from send
Mar 26 22:03:20 localhost kernel: [ 11.576258] xc2028 0-0061: Error -22 while loading base firmware
Mar 26 22:03:20 localhost kernel: [ 11.648380] xc2028 0-0061: Loading firmware for type=BASE F8MHZ (3), id 0000000000000000.

This is from the linux-image-generic-lts-saucy v3.11.0.18.17 running on a Precise LTS system (amd64).
cat /etc/lsb-release
DISTRIB_ID=Ubuntu
DISTRIB_RELEASE=12.04
DISTRIB_CODENAME=precise
DISTRIB_DESCRIPTION="Ubuntu 12.04.4 LTS"

At the risk of starting a wild goose chase this _might_ be related to:
  http://git.kernel.org/cgit/linux/kernel/git/stable/linux-stable.git/commit/?id=e9812be28ce0f4e4bf5586f1a542551c8fc80ffa
which has been merged into the saucy kernel, as far as I can tell,
  http://kernel.ubuntu.com/git?p=ubuntu/ubuntu-saucy.git;a=commit;h=d1ba3eb8a51b2ebb09bdfd7277fde2c8ff679f87

Vince McIntyre (vmcintyr) wrote :

Not seeing the issue on linux-image-generic-lts-raring v3.8.0.37.37 .

Ben Stanley (ben-stanley) wrote :
Download full text (8.8 KiB)

I have poked around in the source code and found some inconsistencies.

=====================================
Summary:
There are multiple definitions of MAX_XFER_SIZE in the drivers/media sub-directory, containing values such as 64, 80, 128, 256.
The definition that appears to matter is in
drivers/media/usb/dvb-usb/cxusb.c
#define MAX_XFER_SIZE 64
It seems that passing a larger msg.len to cxusb_i2c_xfer causes the errors noted in this report.
The buffer size is declared separately in various places, having many different sizes. It seems that there are many ways that this error could be caused.

I have changed MAX_XFER_SIZE in tuner-xc2028.c from 80 to 64. With this change, the kernel logs no longer contain an error when the firmare is loaded. Indeed, the firmware appears to load successfully.

However, I have not yet been able to test whether a DVB signal can be received and decoded.

These tests were performed after upgrading to trusty 14.04, using kernel 3.13.0-24-generic.
=====================================

Notes

Initial testing performed using 3.14.0-031400rc6-generic on Ubuntu 14.04 (same kernel as used previously, but the rest of the OS was upgraded).
Apr 29 14:56:17 mythtv kernel: [ 2385.788462] cxusb: No IR receiver detected on this device.
Apr 29 14:56:17 mythtv kernel: [ 2385.788472] usb 3-2: DVB: registering adapter 2 frontend 0 (Zarlink ZL10353 DVB-T)...
Apr 29 14:56:17 mythtv kernel: [ 2385.788565] xc2028 11-0061: creating new instance
Apr 29 14:56:17 mythtv kernel: [ 2385.788568] xc2028 11-0061: type set to XCeive xc2028/xc3028 tuner
Apr 29 14:56:17 mythtv kernel: [ 2385.790357] xc2028 11-0061: Loading 80 firmware images from xc3028-v27.fw, type: xc2028 firmware, ver 2.7
Apr 29 14:56:17 mythtv kernel: [ 2385.790714] dvb-usb: DViCO FusionHDTV DVB-T Dual Digital 4 successfully initialized and connected.
Apr 29 14:56:17 mythtv kernel: [ 2385.790760] usbcore: registered new interface driver dvb_usb_cxusb

Apr 29 14:58:32 mythtv kernel: [ 2520.932221] xc2028 10-0061: Loading firmware for type=BASE F8MHZ (3), id 0000000000000000.
Apr 29 14:58:32 mythtv kernel: [ 2520.944221] cxusb: i2c wr: len=64 is too big!
Apr 29 14:58:32 mythtv kernel: [ 2520.944221]
Apr 29 14:58:32 mythtv kernel: [ 2520.944226] xc2028 10-0061: i2c output error: rc = -95 (should be 64)
Apr 29 14:58:32 mythtv kernel: [ 2520.944228] xc2028 10-0061: -95 returned from send
Apr 29 14:58:32 mythtv kernel: [ 2520.944231] xc2028 10-0061: Error -22 while loading base firmware
<repeats 8 times>

I have located the origin of each of these messages:

Apr 29 14:58:32 mythtv kernel: [ 2520.932221] xc2028 10-0061: Loading firmware for type=BASE F8MHZ (3), id 0000000000000000.
drivers/media/tuners/tuner-xc2028.c
static int load_firmware(struct dvb_frontend *fe, unsigned int type,
    v4l2_std_id *id)

 tuner_info("Loading firmware for type=");
 dump_firm_type(priv->firm[pos].type);
 printk("(%x), id %016llx.\n", priv->firm[pos].type,
        (unsigned long long)*id);

further down

  /* Sends message chunks */
  while (size > 0) {
   int len = (size < priv->ctrl.max_len - 1) ?
       size : priv->ctrl.max_len - 1;

   memcpy(buf + 1, p, len);

   rc = i2c_send(priv, buf, le...

Read more...

Ben Stanley (ben-stanley) wrote :

Unfortunately, that change had no effect. The errors found in the log previously still occur, but they are delayed from the initially successful output posted previously. More investigation is required.

Ben Stanley (ben-stanley) wrote :

After further work and testing, I have found that changing
drivers/media/tuners/tuner-xc2028.c:28
#define MAX_XFER_SIZE 80
to
#define MAX_XFER_SIZE 61
is enough to fix the problem.

I have confirmed that with this change the firmware loads and I am able to watch TV using me-tv.

Ben Stanley (ben-stanley) wrote :

The details of how the problem was traced are contained in the attached Notes_xc2028.txt file.

Blowdesign (g-hardy) wrote :

Hi,

How do fix this issue ?

I've the same error :

 3242.308051] xc2028 0-0061: i2c output error: rc = -95 (should be 64)
[ 3242.308055] xc2028 0-0061: -95 returned from send
[ 3242.317961] xc2028 0-0061: Error -22 while loading base firmware
[ 3242.352112] xc2028 1-0061: Loading firmware for type=BASE F8MHZ (3), id 0000000000000000.
[ 3242.364130] cxusb: i2c wr: len=64 is too big!

Where is the file drivers/media/tuners/tuner-xc2028 to change the MAX_XFER_SIZE ?

Thanks in advance.

It turns out that a much deeper fix is necessary, and I have not created
it. My current solution is to blacklist the driver. I plan to replace the card.

Alternatively, you could big the guys at Linux tv.org, the ones who write
the drivers in the first place. Launched doesn't seem to be where they hang
out.

The change I made was in the kernel source code. First you have to get the
ubuntu kernel source. After making the change, you have to recompile the
kernel module and copy it into the correct location. The process is very
technical and requires developer skills. But, it doesn't work as well as I
claimed.

Regards,
Ben Stanley

On 28 August 2014 5:21:08 AM Blowdesign <email address hidden> wrote:

> Hi,
>
> How do fix this issue ?
>
> I've the same error :
>
> 3242.308051] xc2028 0-0061: i2c output error: rc = -95 (should be 64)
> [ 3242.308055] xc2028 0-0061: -95 returned from send
> [ 3242.317961] xc2028 0-0061: Error -22 while loading base firmware
> [ 3242.352112] xc2028 1-0061: Loading firmware for type=BASE F8MHZ (3), id
> 0000000000000000.
> [ 3242.364130] cxusb: i2c wr: len=64 is too big!
>
> Where is the file drivers/media/tuners/tuner-xc2028 to change the
> MAX_XFER_SIZE ?
>
> Thanks in advance.
>
> --
> You received this bug notification because you are subscribed to the bug
> report.
> https://bugs.launchpad.net/bugs/1291459
>
> Title:
> ioctl FE_GET_INFO hangs with DViCO FusionHDTV DVB-T Dual Digital 4
> card
>
> To manage notifications about this bug go to:
> https://bugs.launchpad.net/ubuntu/+source/linux/+bug/1291459/+subscriptions

Blowdesign (g-hardy) wrote :

Thanks for your reply.

I think I'll use the old kernel.

Regards

Ben Stanley (ben-stanley) wrote :

Sounds like a good solution.

On 28 August 2014 6:21:25 PM Blowdesign <email address hidden> wrote:

> Thanks for your reply.
>
> I think I'll use the old kernel.
>
> Regards
>
> --
> You received this bug notification because you are subscribed to the bug
> report.
> https://bugs.launchpad.net/bugs/1291459
>
> Title:
> ioctl FE_GET_INFO hangs with DViCO FusionHDTV DVB-T Dual Digital 4
> card
>
> To manage notifications about this bug go to:
> https://bugs.launchpad.net/ubuntu/+source/linux/+bug/1291459/+subscriptions

Blowdesign (g-hardy) wrote :

Ok, I've changed my default boot kernel to come back to the kernel 3.2.0.29 (Ubuntu 12.04.1 LTS april 2017) and it works fine, it's less expensive than change the card ;-)

The problem is since the kernel 3.13 (Ubuntu 12.04.5)

Thanks for your help.

psalter (phil-salter) wrote :

Thanks to the details above I was able to get my Dvico Fusion Dual Digital 4 working on Mythbuntu Trusty 14.04.3 . The problem was solved at kernel 3.19. Problem is related to cxusb.c where the #define MAX_XFER_SIZE 80 was changed from 64 to 80. Details of change are at LinuxTV.org:
https://git.linuxtv.org/media_tree.git/commit/?id=eb9da073bd002f2968c84129a5c49625911a3199

diff --git a/drivers/media/usb/dvb-usb/cxusb.c b/drivers/media/usb/dvb-usb/cxusb.c
index b7461ac..f379f7e 100644
--- a/drivers/media/usb/dvb-usb/cxusb.c
+++ b/drivers/media/usb/dvb-usb/cxusb.c
@@ -46,7 +46,7 @@
 #include "si2157.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;

I looked through the ubuntu kernels for the updated cxusb.c and found it looked ok after 3.19.0 .
To fix my Mythbuntu Trusty I loaded linux-headers-3.19.0-47 and it all worked.

I wanted to update comments here so that anyone else doing searches for the problem might find a quick answer as there are not very many search results relating to Dvico card and later kernel.

Ben Stanley (ben-stanley) wrote :

psalter,

I have just reproduced the fix you described in post #17. I am now able to use my Dvico Fusion Dual Digital 4 again!

I installed the packages
linux-image-generic-lts-vivid
linux-headers-generic-lts-vivid

The net result is
linux-image-generic-3.19.0-49-generic
linux-headers-generic-3.19.0-49-generic

and my tuners work at last!
Thanks for doing the hard work and figuring out what fixed it!
Ben.

To post a comment you must log in.
This report contains Public information  Edit
Everyone can see this information.

Other bug subscribers