Re: Backwards 11ac
ath10k cannot show tx rates right now in a easy way. since tx rate handling is done by the cards own firmware and not by the mac80211 wireless stack Sebastian Am 30.10.2016 um 21:50 schrieb James Cloos: I recently received my turris omnia and put it into operation yesterday. (It is only doing wireless; I have a different box for my main router.) All of the machines on the wlan show backwards transfer speeds; they upload reasonable fast but downloads are in the kbit/s range. That applies to the both the 11ac-capable machines and the 11n-on-2.4 machines. Luci's status/overview page shows 'Bitrate: 6 Mbit/s' for the ath10k and 'Bitrate: 61.5 Mbit/s' for the ath9k. (The two wireless cards in it are: 01:00.0 Network controller: Qualcomm Atheros AR9287 Wireless Network Adapter (PCI-Express) (rev 01) 02:00.0 Network controller: Qualcomm Atheros QCA986x/988x 802.11ac Wireless Network Adapter ) Googling has not helped me figure out how to get propper bandwidth. All of the search results were about wan links, not about wlan links. What should I look at to diagnose this? -JimC -- Mit freundlichen Grüssen / Regards Sebastian Gottschall / CTO NewMedia-NET GmbH - DD-WRT Firmensitz: Berliner Ring 101, 64625 Bensheim Registergericht: Amtsgericht Darmstadt, HRB 25473 Geschäftsführer: Peter Steinhäuser, Christian Scheele http://www.dd-wrt.com email: s.gottsch...@dd-wrt.com Tel.: +496251-582650 / Fax: +496251-5826565
Re: [PATCH 2/2] rtl8xxxu: Fix for bogus data used to determine macpower
John Heenan writes: > Thanks for your reply. > > The code was tested on a Cube i9 which has an internal rtl8723bu. > > No other devices were tested. > > I am happy to accept in an ideal context hard coding macpower is > undesirable, the comment is undesirable and it is wrong to assume the > issue is not unique to the rtl8723bu. > > Your reply is idealistic. What can I do now? I should of course have > factored out other untested devices in my patches. The apparent > concern you have with process over outcome is a useful lesson. > > We are not in an ideal situation. The comment is of course relevant > and useful to starting a process to fixing a real bug I do not have > sufficient information to refine any further for and others do. In the > circumstances nothing really more can be expected. Well you should start by reporting the issue and either providing a patch that only affects 8723bu, or work on a generic solution. I appreciate patches, but I do not appreciate patches that will make something work for one person and break for everyone else - I spent a lot of time making sure the driver works across the different devices. The comment violates all Linux standards - first rule when modifying code is to respect the style of the code you are dealing with. Code is 80 characters wide, and comments are /* */ never the ugly C++ crap. > My patch cover letter, [PATCH 0/2] provides evidence of a mess with > regard to determining macpower for the rtl8723bu and what is > subsequently required. This is important. > > The kernel driver code is very poorly documented and there is not a > single source reference to device documentation. For example macpower > is noting more than a setting that is true or false according to > whether a read of a particular register return 0xef or not. Such value > was never obtained so a full init sequence was never performed. The kernel driver is documented with the information I have - there is NO device documentation because Realtek refuses to provide any. I have written the driver based on what I have retried by reading the vendor drivers. If you can provide better documentation, I certainly would love to get it. > It would be helpful if you could provide a link to device references. > As it is, how am I supposed to revise the patch without relevant > information? Look at the USB device table, it shows you which devices are supported. > My patch code works with the Cube i9, as is, despite a lack of > adequate information. Before it did not. That is a powerful statement The driver works with a lot of different devices in itself that is a powerful statement! Yes I want to see it work with as many devices as possible, but just moving things around without balancing it and not explaining why is not a fix. If we move more of the init sequence to _start() you also have to move matching pieces to _stop(). Jes
Backwards 11ac
I recently received my turris omnia and put it into operation yesterday. (It is only doing wireless; I have a different box for my main router.) All of the machines on the wlan show backwards transfer speeds; they upload reasonable fast but downloads are in the kbit/s range. That applies to the both the 11ac-capable machines and the 11n-on-2.4 machines. Luci's status/overview page shows 'Bitrate: 6 Mbit/s' for the ath10k and 'Bitrate: 61.5 Mbit/s' for the ath9k. (The two wireless cards in it are: 01:00.0 Network controller: Qualcomm Atheros AR9287 Wireless Network Adapter (PCI-Express) (rev 01) 02:00.0 Network controller: Qualcomm Atheros QCA986x/988x 802.11ac Wireless Network Adapter ) Googling has not helped me figure out how to get propper bandwidth. All of the search results were about wan links, not about wlan links. What should I look at to diagnose this? -JimC -- James Cloos OpenPGP: 0x997A9F17ED7DAEA6
Re: [PATCH v6] mwifiex: parse device tree node for PCIe
On Fri, Oct 21, 2016 at 02:21:09PM -0700, Rajat Jain wrote:
> From: Xinming Hu
>
> This patch derives device tree node from pcie bus layer framework, and
> fixes a minor memory leak in mwifiex_pcie_probe() (in failure path).
> Device tree bindings file has been renamed(marvell-sd8xxx.txt ->
> marvell-8xxx.txt) to accommodate PCIe changes.
>
> Signed-off-by: Xinming Hu
> Signed-off-by: Amitkumar Karwar
> Signed-off-by: Rajat Jain
> Reviewed-by: Brian Norris
> ---
> v2: Included vendor and product IDs in compatible strings for PCIe
> chipsets(Rob Herring)
> v3: Patch is created using -M option so that it will only include diff of
> original and renamed files(Rob Herring)
> Resend v3: Resending the patch because I missed to include device tree mailing
> while sending v3.
> v4: Fix error handling, also move-on even if no device tree node is present.
> v5: Update commit log to include memory leak, return -EINVAL instead of -1.
> v6: Remove an unnecessary error print, fix typo in commit log
>
> .../{marvell-sd8xxx.txt => marvell-8xxx.txt} | 8 +++--
> drivers/net/wireless/marvell/mwifiex/pcie.c| 36
> +++---
> drivers/net/wireless/marvell/mwifiex/sta_cmd.c | 3 +-
> 3 files changed, 39 insertions(+), 8 deletions(-)
> rename Documentation/devicetree/bindings/net/wireless/{marvell-sd8xxx.txt =>
> marvell-8xxx.txt} (91%)
>
> diff --git
> a/Documentation/devicetree/bindings/net/wireless/marvell-sd8xxx.txt
> b/Documentation/devicetree/bindings/net/wireless/marvell-8xxx.txt
> similarity index 91%
> rename from Documentation/devicetree/bindings/net/wireless/marvell-sd8xxx.txt
> rename to Documentation/devicetree/bindings/net/wireless/marvell-8xxx.txt
> index c421aba..dfe5f8e 100644
> --- a/Documentation/devicetree/bindings/net/wireless/marvell-sd8xxx.txt
> +++ b/Documentation/devicetree/bindings/net/wireless/marvell-8xxx.txt
> @@ -1,8 +1,8 @@
> -Marvell 8897/8997 (sd8897/sd8997) SDIO devices
> +Marvell 8897/8997 (sd8897/sd8997/pcie8997) SDIO/PCIE devices
> --
>
> -This node provides properties for controlling the marvell sdio wireless
> device.
> -The node is expected to be specified as a child node to the SDIO controller
> that
> +This node provides properties for controlling the marvell sdio/pcie wireless
> device.
s/marvell/Marvell/
s/sdio\/pcie/SDIO\/PCIE/
> +The node is expected to be specified as a child node to the SDIO/PCIE
> controller that
> connects the device to the system.
>
> Required properties:
> @@ -10,6 +10,8 @@ Required properties:
>- compatible : should be one of the following:
> * "marvell,sd8897"
> * "marvell,sd8997"
> + * "pci11ab,2b42"
> + * "pci1b4b,2b42"
I think I already said this, but you have the vendor and product IDs
reversed.
Rob
Re: [PATCH 2/2] rtl8xxxu: Fix for bogus data used to determine macpower
Thanks for your reply. The code was tested on a Cube i9 which has an internal rtl8723bu. No other devices were tested. I am happy to accept in an ideal context hard coding macpower is undesirable, the comment is undesirable and it is wrong to assume the issue is not unique to the rtl8723bu. Your reply is idealistic. What can I do now? I should of course have factored out other untested devices in my patches. The apparent concern you have with process over outcome is a useful lesson. We are not in an ideal situation. The comment is of course relevant and useful to starting a process to fixing a real bug I do not have sufficient information to refine any further for and others do. In the circumstances nothing really more can be expected. My patch cover letter, [PATCH 0/2] provides evidence of a mess with regard to determining macpower for the rtl8723bu and what is subsequently required. This is important. The kernel driver code is very poorly documented and there is not a single source reference to device documentation. For example macpower is noting more than a setting that is true or false according to whether a read of a particular register return 0xef or not. Such value was never obtained so a full init sequence was never performed. It would be helpful if you could provide a link to device references. As it is, how am I supposed to revise the patch without relevant information? My patch code works with the Cube i9, as is, despite a lack of adequate information. Before it did not. That is a powerful statement Have a nice day. John Heenan On 30 October 2016 at 22:00, Jes Sorensen wrote: > John Heenan writes: >> Code tests show data returned by rtl8xxxu_read8(priv, REG_CR), used to set >> macpower, is never 0xea. It is only ever 0x01 (first time after modprobe) >> using wpa_supplicant and 0x00 thereafter using wpa_supplicant. These results >> occurs with 'Fix for authentication failure' [PATCH 1/2] in place. >> >> Whatever was returned, code tests always showed that at least >> rtl8xxxu_init_queue_reserved_page(priv); >> is always required. Not called if macpower set to true. >> >> Please see cover letter, [PATCH 0/2], for more information from tests. >> > > Sorry but this patch is neither serious nor acceptable. First of all, > hardcoding macpower like this right after an if statement is plain > wrong, second your comments violate all kernel rules. > > Second, you argue this was tested using code test - on which device? Did > you test it on all rtl8xxxu based devices or just rtl8723bu? > > NACK > > Jes
Re: [PATCH 2/2] rtl8xxxu: Fix for bogus data used to determine macpower
John Heenan writes:
> Code tests show data returned by rtl8xxxu_read8(priv, REG_CR), used to set
> macpower, is never 0xea. It is only ever 0x01 (first time after modprobe)
> using wpa_supplicant and 0x00 thereafter using wpa_supplicant. These results
> occurs with 'Fix for authentication failure' [PATCH 1/2] in place.
>
> Whatever was returned, code tests always showed that at least
> rtl8xxxu_init_queue_reserved_page(priv);
> is always required. Not called if macpower set to true.
>
> Please see cover letter, [PATCH 0/2], for more information from tests.
>
> For rtl8xxxu-devel branch of
> git.kernel.org/pub/scm/linux/kernel/git/jes/linux.git
>
> Signed-off-by: John Heenan
> ---
> drivers/net/wireless/realtek/rtl8xxxu/rtl8xxxu_core.c | 1 +
> 1 file changed, 1 insertion(+)
>
> diff --git a/drivers/net/wireless/realtek/rtl8xxxu/rtl8xxxu_core.c
> b/drivers/net/wireless/realtek/rtl8xxxu/rtl8xxxu_core.c
> index f25b4df..aae05f3 100644
> --- a/drivers/net/wireless/realtek/rtl8xxxu/rtl8xxxu_core.c
> +++ b/drivers/net/wireless/realtek/rtl8xxxu/rtl8xxxu_core.c
> @@ -3904,6 +3904,7 @@ static int rtl8xxxu_init_device(struct ieee80211_hw *hw)
> macpower = false;
> else
> macpower = true;
> + macpower = false; // Code testing shows macpower must always be set to
> false to avoid failure
>
> ret = fops->power_on(priv);
> if (ret < 0) {
Sorry but this patch is neither serious nor acceptable. First of all,
hardcoding macpower like this right after an if statement is plain
wrong, second your comments violate all kernel rules.
Second, you argue this was tested using code test - on which device? Did
you test it on all rtl8xxxu based devices or just rtl8723bu?
NACK
Jes
RFC if==else in halbtc8723b1ant.c
Hi !
in your commit f5b586909581 ("rtlwifi: btcoexist: Modify driver to support
BT coexistence in rtl8723be") you introduced a if/else where both branches
are the same but the comment in the else branch suggests that this might be
unintended.
from code review only I can´t say what the intent is.
/drivers/net/wireless/realtek/rtlwifi/btcoexist/halbtc8723b1ant.c:halbtc8723b1ant_action_wifi_connected_bt_acl_busy()
1838 if ((bt_rssi_state == BTC_RSSI_STATE_HIGH) ||
1839 (bt_rssi_state == BTC_RSSI_STATE_STAY_HIGH)) {
1840 halbtc8723b1ant_ps_tdma(btcoexist, NORMAL_EXEC,
1841 true, 14);
1842 coex_dm->auto_tdma_adjust = false;
1843 } else { /*for low BT RSSI*/
1844 halbtc8723b1ant_ps_tdma(btcoexist, NORMAL_EXEC,
1845 true, 14);
1846 coex_dm->auto_tdma_adjust = false;
1847 }
basically the same construct is also in
halbtc8723b1ant_run_coexist_mechanism()
2213 if ((wifi_rssi_state == BTC_RSSI_STATE_HIGH) ||
2214 (wifi_rssi_state == BTC_RSSI_STATE_STAY_HIGH))
{
2215 halbtc8723b1ant_limited_tx(btcoexist,
2216NORMAL_EXEC,
22171, 1, 1, 1);
2218 } else {
2219 halbtc8723b1ant_limited_tx(btcoexist,
2220NORMAL_EXEC,
22211, 1, 1, 1);
}
where the if condition is the same so the else may also only apply to the
low BT RSSI - and the if and else are again the same - if this is intended
or not is not clear. If this is intended it should have appropriate comments.
thx!
hofrat
[PATCH 1/2] rtl8xxxu: Fix for authentication failure
This fix enables the same sequence of init behaviour as the alternative working driver for the wireless rtl8723bu IC at https://github.com/lwfinger/rtl8723bu For exampe rtl8xxxu_init_device is now called each time userspace wpa_supplicant is executed instead of just once when modprobe is executed. Along with 'Fix for bogus data used to determine macpower', wpa_supplicant now reliably and successfully authenticates. For rtl8xxxu-devel branch of git.kernel.org/pub/scm/linux/kernel/git/jes/linux.git Signed-off-by: John Heenan --- drivers/net/wireless/realtek/rtl8xxxu/rtl8xxxu_core.c | 9 + 1 file changed, 5 insertions(+), 4 deletions(-) diff --git a/drivers/net/wireless/realtek/rtl8xxxu/rtl8xxxu_core.c b/drivers/net/wireless/realtek/rtl8xxxu/rtl8xxxu_core.c index 04141e5..f25b4df 100644 --- a/drivers/net/wireless/realtek/rtl8xxxu/rtl8xxxu_core.c +++ b/drivers/net/wireless/realtek/rtl8xxxu/rtl8xxxu_core.c @@ -5779,6 +5779,11 @@ static int rtl8xxxu_start(struct ieee80211_hw *hw) ret = 0; + ret = rtl8xxxu_init_device(hw); + if (ret) + goto error_out; + + init_usb_anchor(&priv->rx_anchor); init_usb_anchor(&priv->tx_anchor); init_usb_anchor(&priv->int_anchor); @@ -6080,10 +6085,6 @@ static int rtl8xxxu_probe(struct usb_interface *interface, goto exit; } - ret = rtl8xxxu_init_device(hw); - if (ret) - goto exit; - hw->wiphy->max_scan_ssids = 1; hw->wiphy->max_scan_ie_len = IEEE80211_MAX_DATA_LEN; hw->wiphy->interface_modes = BIT(NL80211_IFTYPE_STATION); -- 2.10.1
[PATCH 2/2] rtl8xxxu: Fix for bogus data used to determine macpower
Code tests show data returned by rtl8xxxu_read8(priv, REG_CR), used to set
macpower, is never 0xea. It is only ever 0x01 (first time after modprobe)
using wpa_supplicant and 0x00 thereafter using wpa_supplicant. These results
occurs with 'Fix for authentication failure' [PATCH 1/2] in place.
Whatever was returned, code tests always showed that at least
rtl8xxxu_init_queue_reserved_page(priv);
is always required. Not called if macpower set to true.
Please see cover letter, [PATCH 0/2], for more information from tests.
For rtl8xxxu-devel branch of
git.kernel.org/pub/scm/linux/kernel/git/jes/linux.git
Signed-off-by: John Heenan
---
drivers/net/wireless/realtek/rtl8xxxu/rtl8xxxu_core.c | 1 +
1 file changed, 1 insertion(+)
diff --git a/drivers/net/wireless/realtek/rtl8xxxu/rtl8xxxu_core.c
b/drivers/net/wireless/realtek/rtl8xxxu/rtl8xxxu_core.c
index f25b4df..aae05f3 100644
--- a/drivers/net/wireless/realtek/rtl8xxxu/rtl8xxxu_core.c
+++ b/drivers/net/wireless/realtek/rtl8xxxu/rtl8xxxu_core.c
@@ -3904,6 +3904,7 @@ static int rtl8xxxu_init_device(struct ieee80211_hw *hw)
macpower = false;
else
macpower = true;
+ macpower = false; // Code testing shows macpower must always be set to
false to avoid failure
ret = fops->power_on(priv);
if (ret < 0) {
--
2.10.1
[PATCH 0/2] rtl8xxxu: Fix allows wpa_supplicant to authenticate
With the current kernel release, wpa_supplicant results in authentication failure with a Cube i9 tablet (a Surface Pro like device): Successfully initialized wpa_supplicant wlp0s20f0u7i2: SME: Trying to authenticate with 10:fe:ed:62:7a:78 (SSID='localre' freq=2417 MHz) wlp0s20f0u7i2: SME: Trying to authenticate with 10:fe:ed:62:7a:78 (SSID='localre' freq=2417 MHz) wlp0s20f0u7i2: SME: Trying to authenticate with 10:fe:ed:62:7a:78 (SSID='localre' freq=2417 MHz) wlp0s20f0u7i2: SME: Trying to authenticate with 10:fe:ed:62:7a:78 (SSID='localre' freq=2417 MHz) wlp0s20f0u7i2: CTRL-EVENT-SSID-TEMP-DISABLED id=0 ssid="localre" auth_failures=1 duration=10 reason=CONN_FAILED There is a workaround: that ONLY works once per invocation of wpa_supplicant: rmmod rtl8xxxu modprobe rtl8xxxu The follwing two patches result in reliable behaviour, without a workaround, of wpa_supplicant: Successfully initialized wpa_supplicant wlp0s20f0u7i2: SME: Trying to authenticate with 10:fe:ed:62:7a:78 (SSID='localre' freq=2417 MHz) wlp0s20f0u7i2: Trying to associate with 10:fe:ed:62:7a:78 (SSID='localre' freq=2417 MHz) wlp0s20f0u7i2: Associated with 10:fe:ed:62:7a:78 wlp0s20f0u7i2: CTRL-EVENT-SUBNET-STATUS-UPDATE status=0 wlp0s20f0u7i2: WPA: Key negotiation completed with 10:fe:ed:62:7a:78 [PTK=CCMP GTK=CCMP] wlp0s20f0u7i2: CTRL-EVENT-CONNECTED - Connection to 10:fe:ed:62:7a:78 completed [id=0 id_str=] The patches are for kernel tree: git://git.kernel.org/pub/scm/linux/kernel/git/jes/linux.git branch: rtl8xxxu-devel The first patch moves init code so that each time wpa_supplicant is invoked there is similar init behaviour as the alternative working rtl8xxxu driver https://github.com/lwfinger/rtl8723bu The second patch enables more complete initialisation to occur. There are three issues: 1. The value returned by "rtl8xxxu_read8(priv, REG_CR);", to set macpower, is never 0xef. The value is either 0x01 (first time with wpa_supplcant after modprobe) or 0x00 (re executing wpa_supplicant) 2. Trying to use the value 0x00 or 0x01 retutned to determine macpower setting always resulted in failure 3. At the very least 'rtl8xxxu_init_queue_reserved_page(priv);' must always be invoked, even if not all of the extra init sequence arising from setting macpower to false is run. Patched code with a suitable Makefile will be available from https://github.com/johnheenan/rtl8xxxu for testing by Cube i9 owners John Heenan (2): rtl8xxxu: Fix for authentication failure rtl8xxxu: Fix for bogus data used to determine macpower drivers/net/wireless/realtek/rtl8xxxu/rtl8xxxu_core.c | 10 ++ 1 file changed, 6 insertions(+), 4 deletions(-) -- 2.10.1
pull-request: wireless-drivers-next 2016-10-30
Hi Dave, few fixes for 4.9. I tagged this on the plane over a slow mosh connection while travelling to Plumbers so I might have done something wrong, please check more carefully than usually. For example I had to redo the signed tag because of some whitespace damage. Please let me know if there are any problems. Kalle The following changes since commit 67f0160fe34ec5391a428603b9832c9f99d8f3a1: MAINTAINERS: Update qlogic networking drivers (2016-10-26 23:29:12 -0400) are available in the git repository at: git://git.kernel.org/pub/scm/linux/kernel/git/kvalo/wireless-drivers.git tags/wireless-drivers-for-davem-2016-10-30 for you to fetch changes up to d3532ea6ce4ea501e421d130555e59edc2945f99: brcmfmac: avoid maybe-uninitialized warning in brcmf_cfg80211_start_ap (2016-10-27 18:04:54 +0300) wireless-drivers fixes for 4.9 iwlwifi * some fixes for suspend/resume with unified FW images * a fix for a false-positive lockdep report * a fix for multi-queue that caused an unnecessary 1 second latency * a fix for an ACPI parsing bug that caused a misleading error message brcmfmac * fix a variable uninitialised warning in brcmf_cfg80211_start_ap() Arnd Bergmann (1): brcmfmac: avoid maybe-uninitialized warning in brcmf_cfg80211_start_ap Haim Dreyfuss (1): iwlwifi: mvm: comply with fw_restart mod param on suspend Johannes Berg (1): iwlwifi: pcie: mark command queue lock with separate lockdep class Kalle Valo (1): Merge tag 'iwlwifi-for-kalle-2015-10-25' of git://git.kernel.org/.../iwlwifi/iwlwifi-fixes Luca Coelho (4): iwlwifi: mvm: use ssize_t for len in iwl_debugfs_mem_read() iwlwifi: mvm: fix d3_test with unified D0/D3 images iwlwifi: pcie: fix SPLC structure parsing iwlwifi: mvm: fix netdetect starting/stopping for unified images Sara Sharon (1): iwlwifi: mvm: wake the wait queue when the RX sync counter is zero .../broadcom/brcm80211/brcmfmac/cfg80211.c |2 +- drivers/net/wireless/intel/iwlwifi/mvm/d3.c| 49 +--- drivers/net/wireless/intel/iwlwifi/mvm/debugfs.c |4 +- drivers/net/wireless/intel/iwlwifi/mvm/mac80211.c |3 +- drivers/net/wireless/intel/iwlwifi/mvm/mvm.h |1 + drivers/net/wireless/intel/iwlwifi/mvm/ops.c |1 + drivers/net/wireless/intel/iwlwifi/mvm/rxmq.c |3 +- drivers/net/wireless/intel/iwlwifi/mvm/scan.c | 33 ++-- drivers/net/wireless/intel/iwlwifi/pcie/drv.c | 79 drivers/net/wireless/intel/iwlwifi/pcie/tx.c |8 ++ 10 files changed, 129 insertions(+), 54 deletions(-)
Re: compex wle900vx (ath10k) problem on 4.4.24 / armv7
>> I (naively) went through pci/pm git log and found the following was >> applied on 4.7-rc2 (i.e. prior to 4.7 release): >> >> commit 006d44e49a259b39947366728d65a873a19aadc0 >> Author: Mika Westerberg >> Date: Thu Jun 2 11:17:15 2016 +0300 >> >> PCI: Add runtime PM support for PCIe ports >> >> From reading the commit log it seems to me like it could be it. >> >> ath10k tries to wake up the device during probing before it starts >> talking to it and it does so through MMIO/PCI config space. If it's >> not mapped properly then driver will not be able to wake it up and >> will timeout waiting for it. >> >> Can you try cherry-picking it into your 4.4.24 and see if it helps? >> >> > Thanks for the help! > > Until now I did not compile a kernel for the board. > I will give it a try and come back with the results ... > > > Best regards, > Matthias > good news, just got a message from the support with a quote from one of their developers: Have the customer that needs support for the ath cards to use this branch. https://github.com/SolidRun/linux-stable/tree/linux-4.4.y-marvell note that the device-tree is board specific and for now they should create a symlink from their board file to armada-388-clearfog.dtb when i look at the change, https://github.com/SolidRun/linux-stable/commit/e12aa24ca56ca773b5c59a3cc2915b4e82e6be18 this looks exactly like the problem we had :) I will try this today. Regards Oli
