* DONATION!!!
From: Mrs Birgit Rausing @ 2014-10-30 22:04 UTC (permalink / raw)
I,Birgit authenticate this email, you can read about me on:
http://en.wikipedia.org/wiki/Birgit_Rausing
I have funds for you to manage and disburse to various charities of your
choice. If you are sure you can handle this, it will be of help to you and
others. Please reply if you are interested for more details.please
Contact my private email;( mrs_BirgitRausin0@qq.com ) for more
information
With love,
Mrs Birgit Rausing
^ permalink raw reply
* DONATION!!!
From: Mrs Birgit Rausing @ 2014-10-30 22:11 UTC (permalink / raw)
I,Birgit authenticate this email, you can read about me on:
http://en.wikipedia.org/wiki/Birgit_Rausing
I have funds for you to manage and disburse to various charities of your
choice. If you are sure you can handle this, it will be of help to you and
others. Please reply if you are interested for more details.please
Contact my private email;( mrs_BirgitRausin0@qq.com ) for more
information
With love,
Mrs Birgit Rausing
^ permalink raw reply
* Re: [PATCH -next 0/2] net: allow setting ecn via routing table
From: Florian Westphal @ 2014-10-30 22:15 UTC (permalink / raw)
To: Eric Dumazet; +Cc: Florian Westphal, David Miller, netdev
In-Reply-To: <1414703260.15352.9.camel@edumazet-glaptop2.roam.corp.google.com>
Eric Dumazet <eric.dumazet@gmail.com> wrote:
> On Thu, 2014-10-30 at 21:52 +0100, Florian Westphal wrote:
>
> > So, what about changing the default to 1 in net-next?
> >
> > We could add automatic 'no-ecn' to retransmitted syns to avoid
> > ecn blackholes (Daniel Borkmann has a patch for this), and, in case
> > ecn=1 causes too much breakage we can always revert (and re-consider ecn
> > per route settings as an intermediate step).
> >
> > What do you think?
>
> I think this is way too dangerous.
>
> I played a lot with ECN in the past (and fixed number of bugs in linux)
> and discovered many times I had to disable it to be able to surf the
> Internet.
[..]
> Reverting might take a long long time, it wont help people stuck behind
> buggy equipment.
Do you think a fallback to non-ecn for retransmitted syns would help?
If not, do you think having ecn tunable available via route is helpful?
Thanks!
^ permalink raw reply
* Re: [PATCH v2 net 1/2] drivers/net: Disable UFO through virtio
From: Ben Hutchings @ 2014-10-30 22:20 UTC (permalink / raw)
To: Eric Dumazet; +Cc: netdev, Hannes Frederic Sowa, virtualization
In-Reply-To: <1414694849.15352.3.camel@edumazet-glaptop2.roam.corp.google.com>
[-- Attachment #1.1: Type: text/plain, Size: 817 bytes --]
On Thu, 2014-10-30 at 11:47 -0700, Eric Dumazet wrote:
> On Thu, 2014-10-30 at 18:27 +0000, Ben Hutchings wrote:
>
>
> > + {
> > + static bool warned;
> > +
> > + if (!warned) {
> > + warned = true;
> > + netdev_warn(tun->dev,
> > + "%s: using disabled UFO feature; please fix this program\n",
> > + current->comm);
> > + }
> >
>
> It might be time to add netdev_warn_once() ;)
Could do. I'm trying to make small fixes that are suitable for stable.
> Alternatively, you could use
> pr_warn_once("%s: using disabled UFO feature; please fix this program\n",
> tun->dev->name, current->comm);
That's missing a "%s: ", but yes that would also work.
Ben.
--
Ben Hutchings
The program is absolutely right; therefore, the computer must be wrong.
[-- Attachment #1.2: This is a digitally signed message part --]
[-- Type: application/pgp-signature, Size: 811 bytes --]
[-- Attachment #2: Type: text/plain, Size: 183 bytes --]
_______________________________________________
Virtualization mailing list
Virtualization@lists.linux-foundation.org
https://lists.linuxfoundation.org/mailman/listinfo/virtualization
^ permalink raw reply
* Re: [PATCH v3 09/15] net: dsa: Add support for switch EEPROM access
From: Guenter Roeck @ 2014-10-30 22:39 UTC (permalink / raw)
To: Andrew Lunn; +Cc: netdev, David S. Miller, Florian Fainelli, linux-kernel
In-Reply-To: <20141030211131.GB32139@lunn.ch>
On Thu, Oct 30, 2014 at 10:11:31PM +0100, Andrew Lunn wrote:
> > +static int dsa_slave_get_eeprom_len(struct net_device *dev)
> > +{
> > + struct dsa_slave_priv *p = netdev_priv(dev);
> > + struct dsa_switch *ds = p->parent;
> > +
> > + if (ds->pd->eeprom_len)
> > + return ds->pd->eeprom_len;
> > +
> > + if (ds->drv->get_eeprom_len)
> > + return ds->drv->get_eeprom_len(ds);
> > +
> > + return 0;
> > +}
> > +
>
> Hi Guenter
>
> I just started doing some testing with this patchset. A bit late since
> David just accepted it, but...
>
> root@dir665:~# ethtool -e lan4
> Cannot get EEPROM data: Invalid argument
> root@dir665:~# ethtool -e eth0
> Cannot get EEPROM data: Operation not supported
>
> There is no eeprom for the hardware i'm testing. Operation not
> supported seems like a better error code and Invalid argument, and is
> what other network drivers i tried returned.
>
Hi Andrew,
I think the problem is that the infrastructure code (net/core/ethtool.c)
does not accept an error from the get_eeprom_len function, but instead
assumes that reporting eeprom data is supported if a driver provides
the access functions. The get_eeprom_len function returns 0 in your case,
which in ethtool_get_any_eeprom() translates to -EINVAL because user space
either requests no data or more data than available. I wonder why user
space requests anything in the first place; I would have assumed that it
reads the driver information first and is told that the eeprom length is 0,
but I guess that is a different question.
I quickly browsed through a couple of other drivers supporting get_eprom_len,
and they all return 0 if there is no eeprom. Doesn't that mean that they all
end up reporting -EINVAL if an attempt is made to read the eeprom ?
The only solution that comes to my mind would be to have the infrastructure
code check the return value from get_eeprom_len and return -EOPNOTSUPP
if the reported eeprom length is 0. That would be an infrastructure change,
though. Does that sound reasonable, or do you have a better idea ?
In parallel, I'll have a look into the ethtool command to see why it
requests eeprom data even though the reported eeprom length is 0.
Thanks,
Guenter
^ permalink raw reply
* Re: [PATCH 0/6 3.18] Fixes for iwlwifi drivers
From: Murilo Opsfelder Araujo @ 2014-10-30 22:44 UTC (permalink / raw)
To: Larry Finger, linville-2XuSBdqkA4R54TAoqtyWWQ
Cc: linux-wireless-u79uwXL29TY76Z2rM5mHXA,
netdev-u79uwXL29TY76Z2rM5mHXA
In-Reply-To: <1414642633-3700-1-git-send-email-Larry.Finger-tQ5ms3gMjBLk1uMJSBkQmQ@public.gmane.org>
On 10/30/2014 02:17 AM, Larry Finger wrote:
> Some late changes to rtlwifi made some of the older drivers not start correctly.
> These patches should be applied to 3.18.
>
> Signed-off-by: Larry Finger <Larry.Finger-tQ5ms3gMjBLk1uMJSBkQmQ@public.gmane.org>
> Cc: Murilo Opsfelder Araujo <mopsfelder-Re5JQEeQqe8AvxtiuMwx3w@public.gmane.org>
>
> Larry Finger (6):
> rtlwifi: rtl8192ce: rtl8192de: rtl8192se: Fix handling for missing
> get_btc_status
> rtlwifi: rtl8192se: Fix duplicate calls to ieee80211_register_hw()
> rtlwifi: rtl8192se: Add missing section to read descriptor setting
> rtlwifi: rtl8192ce: Add missing section to read descriptor setting
> rtlwifi: rtl8821ae: Remove extra semicolons
> rtlwifi: rtl8192se: Fix firmware loading
>
> drivers/net/wireless/rtlwifi/core.c | 6 ++++++
> drivers/net/wireless/rtlwifi/core.h | 1 +
> drivers/net/wireless/rtlwifi/rtl8192ce/def.h | 2 ++
> drivers/net/wireless/rtlwifi/rtl8192ce/sw.c | 1 +
> drivers/net/wireless/rtlwifi/rtl8192ce/trx.c | 3 +++
> drivers/net/wireless/rtlwifi/rtl8192de/sw.c | 1 +
> drivers/net/wireless/rtlwifi/rtl8192se/def.h | 2 ++
> drivers/net/wireless/rtlwifi/rtl8192se/sw.c | 22 +++-------------------
> drivers/net/wireless/rtlwifi/rtl8192se/trx.c | 3 +++
> drivers/net/wireless/rtlwifi/rtl8821ae/phy.c | 12 ++++++------
> 10 files changed, 28 insertions(+), 25 deletions(-)
>
Hi, Larry.
I've applied this patchset on top of next-20141030 and got the same
result: kernel panic went away but the rtl8192se device does not associate.
Thanks anyway for dedicating your family time to trying to get this fixed.
We can talk about that later when you're back on regular schedule.
Appreciated!
--
Murilo
--
To unsubscribe from this list: send the line "unsubscribe linux-wireless" in
the body of a message to majordomo-u79uwXL29TY76Z2rM5mHXA@public.gmane.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
^ permalink raw reply
* Re: [PATCH net-next 4/8] net/mlx4_en: Add __GFP_COLD gfp flags in alloc_pages
From: Or Gerlitz @ 2014-10-30 22:49 UTC (permalink / raw)
To: Eric Dumazet
Cc: Or Gerlitz, David S. Miller, Linux Netdev List, Matan Barak,
Amir Vadai, Saeed Mahameed, Shani Michaeli, Ido Shamay
In-Reply-To: <1414689333.9028.0.camel@edumazet-glaptop2.roam.corp.google.com>
On Thu, Oct 30, 2014 at 7:15 PM, Eric Dumazet <eric.dumazet@gmail.com> wrote:
>> @@ -54,7 +54,7 @@ static int mlx4_alloc_pages(struct mlx4_en_priv *priv,
>> dma_addr_t dma;
>>
>> for (order = MLX4_EN_ALLOC_PREFER_ORDER; ;) {
>> - gfp_t gfp = _gfp;
>> + gfp_t gfp = _gfp | __GFP_COLD;
> This should be set by callers, to avoid extra code
> GFP_ATOMIC | __GFP_COLD
> or
> GFP_KERNEL | __GFP_COLD
I guess we can do that, sure.
^ permalink raw reply
* DONATION!!!
From: Mrs Birgit Rausing @ 2014-10-30 22:54 UTC (permalink / raw)
I,Birgit authenticate this email, you can read about me on:
http://en.wikipedia.org/wiki/Birgit_Rausing
I have funds for you to manage and disburse to various charities of your
choice. If you are sure you can handle this, it will be of help to you and
others. Please reply if you are interested for more details.please
Contact my private email;( mrs_BirgitRausin0@qq.com ) for more
information
With love,
Mrs Birgit Rausing
^ permalink raw reply
* Re: [PATCH -next 0/2] net: allow setting ecn via routing table
From: Eric Dumazet @ 2014-10-30 23:05 UTC (permalink / raw)
To: Florian Westphal; +Cc: David Miller, netdev
In-Reply-To: <20141030221501.GA9416@breakpoint.cc>
On Thu, 2014-10-30 at 23:15 +0100, Florian Westphal wrote:
> Do you think a fallback to non-ecn for retransmitted syns would help?
> If not, do you think having ecn tunable available via route is helpful?
Unfortunately some firewalls are buggy and accept a single SYN per flow.
You would need to blacklist ecn at first sign of a possible ecn problem,
for all following connections attempts.
Note that ECN problems are not only contained in SYN packets being
eventually dropped. You might have a success to establish a flow, and
later get CE marks for all packets and cwnd converges to 1.
This is really a lot of work to get all sorted out.
^ permalink raw reply
* Re: [PATCH v2 net 1/2] drivers/net: Disable UFO through virtio
From: Eric Dumazet @ 2014-10-30 23:16 UTC (permalink / raw)
To: Ben Hutchings; +Cc: netdev, Hannes Frederic Sowa, virtualization
In-Reply-To: <1414707602.16849.70.camel@decadent.org.uk>
On Thu, 2014-10-30 at 22:20 +0000, Ben Hutchings wrote:
> Could do. I'm trying to make small fixes that are suitable for stable.
Oh right, makes sense ;)
^ permalink raw reply
* Re: [PATCH -next 0/2] net: allow setting ecn via routing table
From: Florian Westphal @ 2014-10-30 23:16 UTC (permalink / raw)
To: Eric Dumazet; +Cc: Florian Westphal, David Miller, netdev
In-Reply-To: <1414710342.15352.14.camel@edumazet-glaptop2.roam.corp.google.com>
Eric Dumazet <eric.dumazet@gmail.com> wrote:
> On Thu, 2014-10-30 at 23:15 +0100, Florian Westphal wrote:
>
> > Do you think a fallback to non-ecn for retransmitted syns would help?
>
> Unfortunately some firewalls are buggy and accept a single SYN per flow.
[..]
> Note that ECN problems are not only contained in SYN packets being
> eventually dropped. You might have a success to establish a flow, and
> later get CE marks for all packets and cwnd converges to 1.
I see. So that makes ecn=1 default a pure fantasy.
Thanks for explaining this.
^ permalink raw reply
* Re: [PATCH RESEND v2] ipv4: Do not cache routing failures due to disabled forwarding.
From: David Miller @ 2014-10-30 23:21 UTC (permalink / raw)
To: nicolas.cavallari; +Cc: kuznet, jmorris, yoshfuji, kaber, netdev, linux-kernel
In-Reply-To: <1414660193-4177-1-git-send-email-nicolas.cavallari@green-communications.fr>
From: Nicolas Cavallari <nicolas.cavallari@green-communications.fr>
Date: Thu, 30 Oct 2014 10:09:53 +0100
> If we cache them, the kernel will reuse them, independently of
> whether forwarding is enabled or not. Which means that if forwarding is
> disabled on the input interface where the first routing request comes
> from, then that unreachable result will be cached and reused for
> other interfaces, even if forwarding is enabled on them. The opposite
> is also true.
>
> This can be verified with two interfaces A and B and an output interface
> C, where B has forwarding enabled, but not A and trying
> ip route get $dst iif A from $src && ip route get $dst iif B from $src
>
> Signed-off-by: Nicolas Cavallari <nicolas.cavallari@green-communications.fr>
> Reviewed-by: Julian Anastasov <ja@ssi.bg>
Applied and queued up for -stable, thanks.
^ permalink raw reply
* DONATION!!!
From: Mrs Birgit Rausing @ 2014-10-30 23:23 UTC (permalink / raw)
I,Birgit authenticate this email, you can read about me on:
http://en.wikipedia.org/wiki/Birgit_Rausing
I have funds for you to manage and disburse to various charities of your
choice. If you are sure you can handle this, it will be of help to you and
others. Please reply if you are interested for more details.please
Contact my private email;( mrs_BirgitRausin0@qq.com ) for more
information
With love,
Mrs Birgit Rausing
^ permalink raw reply
* Re: [PATCH net-next 5/8] net/mlx4_en: Remove redundant code from RX/GRO path
From: Or Gerlitz @ 2014-10-30 23:25 UTC (permalink / raw)
To: Eric Dumazet
Cc: Or Gerlitz, David S. Miller, Linux Netdev List, Matan Barak,
Amir Vadai, Saeed Mahameed, Shani Michaeli, Ido Shamay
In-Reply-To: <1414695631.15352.5.camel@edumazet-glaptop2.roam.corp.google.com>
On Thu, Oct 30, 2014 at 9:00 PM, Eric Dumazet <eric.dumazet@gmail.com> wrote:
> On Thu, 2014-10-30 at 18:06 +0200, Or Gerlitz wrote:
>> Remove the code which goes through napi_gro_frags() on the RX path,
>> use only napi_gro_receive().
> Hmpff... napi_gro_frags() should be faster.
> Have you benchmarked this ?
yep we did, napi_gro_frags() was somehow better for single stream. Do
you think we need to do it the other way around, e.g converge to use
napi_gro_frags()?
^ permalink raw reply
* Re: [PATCH net-next 8/8] net/mlx4_en: Extend checksum offloading by CHECKSUM COMPLETE
From: Or Gerlitz @ 2014-10-30 23:28 UTC (permalink / raw)
To: Jerry Chu
Cc: Or Gerlitz, David S. Miller, netdev@vger.kernel.org, Matan Barak,
Amir Vadai, Saeed Mahameed, Shani Michaeli
In-Reply-To: <CAPshTChwewGiP712ki-BGu6VWhZTVOfZDzFm8NEqvon7uLhEWA@mail.gmail.com>
On Thu, Oct 30, 2014 at 11:20 PM, Jerry Chu <hkchu@google.com> wrote:
> Acked-by: H.K. Jerry Chu <hkchu@google.com>
>
> BTW, will the patch work for all versions of the chip?
If you'll look carefully, you'll see we go that path only when
priv->flags & MLX4_EN_FLAG_RX_CSUM_NON_TCP_UDP is true. This currently
holds only for ConnectX3 and not ConnectX3-pro. Down the road, the
feature will also be available for the -pro too.
^ permalink raw reply
* Re: [PATCH -next 0/2] net: allow setting ecn via routing table
From: Eric Dumazet @ 2014-10-30 23:30 UTC (permalink / raw)
To: Florian Westphal; +Cc: David Miller, netdev
In-Reply-To: <20141030231637.GF10069@breakpoint.cc>
On Fri, 2014-10-31 at 00:16 +0100, Florian Westphal wrote:
> I see. So that makes ecn=1 default a pure fantasy.
Well, I had this dream about 2 or 3 years ago, but I eventually came to
this (sad) conclusion.
^ permalink raw reply
* DONATION!!!
From: Mrs Birgit Rausing @ 2014-10-30 23:30 UTC (permalink / raw)
I,Birgit authenticate this email, you can read about me on:
http://en.wikipedia.org/wiki/Birgit_Rausing
I have funds for you to manage and disburse to various charities of your
choice. If you are sure you can handle this, it will be of help to you and
others. Please reply if you are interested for more details.please
Contact my private email;( mrs_BirgitRausin0@qq.com ) for more
information
With love,
Mrs Birgit Rausing
^ permalink raw reply
* Re: [net-next 1/2] sctp: add transport state in /proc/net/sctp/remaddr
From: David Miller @ 2014-10-30 23:40 UTC (permalink / raw)
To: michele; +Cc: vyasevich, nhorman, linux-sctp, netdev
In-Reply-To: <1414661356-17255-1-git-send-email-michele@acksyn.org>
From: Michele Baldessari <michele@acksyn.org>
Date: Thu, 30 Oct 2014 10:29:15 +0100
> It is often quite helpful to be able to know the state of a transport
> outside of the application itself (for troubleshooting purposes or for
> monitoring purposes). Add it under /proc/net/sctp/remaddr.
>
> Signed-off-by: Michele Baldessari <michele@acksyn.org>
Applied.
^ permalink raw reply
* Re: [net-next 2/2] sctp: replace seq_printf with seq_puts
From: David Miller @ 2014-10-30 23:40 UTC (permalink / raw)
To: michele; +Cc: vyasevich, nhorman, linux-sctp, netdev
In-Reply-To: <1414661356-17255-2-git-send-email-michele@acksyn.org>
From: Michele Baldessari <michele@acksyn.org>
Date: Thu, 30 Oct 2014 10:29:16 +0100
> Fixes checkpatch warning:
> "WARNING: Prefer seq_puts to seq_printf"
>
> Signed-off-by: Michele Baldessari <michele@acksyn.org>
Applied.
^ permalink raw reply
* DONATION!!!
From: Mrs Birgit Rausing @ 2014-10-30 23:43 UTC (permalink / raw)
I,Birgit authenticate this email, you can read about me on:
http://en.wikipedia.org/wiki/Birgit_Rausing
I have funds for you to manage and disburse to various charities of your
choice. If you are sure you can handle this, it will be of help to you and
others. Please reply if you are interested for more details.please
Contact my private email;( mrs_BirgitRausin0@qq.com ) for more
information
With love,
Mrs Birgit Rausing
^ permalink raw reply
* Re: [PATCH] stmmac: pci: set default of the filter bins
From: David Miller @ 2014-10-30 23:44 UTC (permalink / raw)
To: andriy.shevchenko; +Cc: peppe.cavallaro, netdev, hock.leong.kweh, vbridgers2013
In-Reply-To: <1414661965-1140-1-git-send-email-andriy.shevchenko@linux.intel.com>
From: Andy Shevchenko <andriy.shevchenko@linux.intel.com>
Date: Thu, 30 Oct 2014 11:39:25 +0200
> @@ -32,7 +32,10 @@ static struct stmmac_dma_cfg dma_cfg;
>
> static void stmmac_default_data(void)
> {
> + struct plat_stmmacenet_data *plat = &plat_dat;
> +
> memset(&plat_dat, 0, sizeof(struct plat_stmmacenet_data));
> +
> plat_dat.bus_id = 1;
> plat_dat.phy_addr = 0;
> plat_dat.interface = PHY_INTERFACE_MODE_GMII;
> @@ -47,6 +50,12 @@ static void stmmac_default_data(void)
> dma_cfg.pbl = 32;
> dma_cfg.burst_len = DMA_AXI_BLEN_256;
> plat_dat.dma_cfg = &dma_cfg;
> +
> + /* Set default value for multicast hash bins */
> + plat->multicast_filter_bins = HASH_TABLE_SIZE;
> +
> + /* Set default value for unicast filter entries */
> + plat->unicast_filter_entries = 1;
Don't do this.
The rest of the function goes "plat_dat.foo" so it looks terribly
inconsistent when you add the local variable to dereference it like
this.
So just do "plat_dat.multicast_filter_bins = x;" etc.
^ permalink raw reply
* DONATION!!!
From: Mrs Birgit Rausing @ 2014-10-30 23:45 UTC (permalink / raw)
I,Birgit authenticate this email, you can read about me on:
http://en.wikipedia.org/wiki/Birgit_Rausing
I have funds for you to manage and disburse to various charities of your
choice. If you are sure you can handle this, it will be of help to you and
others. Please reply if you are interested for more details.please
Contact my private email;( mrs_BirgitRausin0@qq.com ) for more
information
With love,
Mrs Birgit Rausing
^ permalink raw reply
* Re: [net 0/4][pull request] Intel Wired LAN Driver Updates 2014-10-30
From: David Miller @ 2014-10-30 23:47 UTC (permalink / raw)
To: jeffrey.t.kirsher; +Cc: netdev, nhorman, sassmann, jogreene
In-Reply-To: <1414672436-20616-1-git-send-email-jeffrey.t.kirsher@intel.com>
From: Jeff Kirsher <jeffrey.t.kirsher@intel.com>
Date: Thu, 30 Oct 2014 05:33:52 -0700
> This series contains updates to e1000, igb and ixgbe.
>
> Francesco Ruggeri fixes an issue with e1000 where in a VM the driver did
> not support unicast filtering.
>
> Roman Gushchin fixes an issue with igb where the driver was re-using
> mapped pages so that packets were still getting dropped even if all
> the memory issues are gone and there is free memory.
>
> Junwei Zhang found where in the ixgbe_clean_rx_ring() we were repeating
> the assignment of NULL to the receive buffer skb and fixes it.
>
> Emil fixes a race condition between setup_link and SFP detection routine
> in the watchdog when setting the advertised speed.
Pulled, thanks Jeff.
^ permalink raw reply
* Re: [PATCH net 0/2] mlx4 driver encapsulation/steering fixes
From: David Miller @ 2014-10-30 23:49 UTC (permalink / raw)
To: ogerlitz; +Cc: netdev, matanb, amirv, saeedm
In-Reply-To: <1414677568-28409-1-git-send-email-ogerlitz@mellanox.com>
From: Or Gerlitz <ogerlitz@mellanox.com>
Date: Thu, 30 Oct 2014 15:59:26 +0200
> The 1st patch fixes a bug in the TX path that supports offloading the
> TX checksum of (VXLAN) encapsulated TCP packets. It turns out that the
> bug is revealed only when the receiver runs in non-offloaded mode, so
> we somehow missed it so far... please queue it for -stable >= 3.14
>
> The 2nd patch makes sure not to leak steering entry on error flow,
> please queue it to 3.17-stable
Applied and queue up for -stable.
^ permalink raw reply
* DONATION!!!
From: Mrs Birgit Rausing @ 2014-10-30 23:51 UTC (permalink / raw)
I,Birgit authenticate this email, you can read about me on:
http://en.wikipedia.org/wiki/Birgit_Rausing
I have funds for you to manage and disburse to various charities of your
choice. If you are sure you can handle this, it will be of help to you and
others. Please reply if you are interested for more details.please
Contact my private email;( mrs_BirgitRausin0@qq.com ) for more
information
With love,
Mrs Birgit Rausing
^ permalink raw reply
page: next (older) | prev (newer) | latest
- recent:[subjects (threaded)|topics (new)|topics (active)]
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox