* Bonanza
From: Werley David @ 2009-07-21 10:45 UTC (permalink / raw)
To: info
950.000.00 GBP has been award to you in LG Eletronics promo. Send your details.
Name:.....
Address:...
Country:......
^ permalink raw reply
* Bonanza
From: Werley David @ 2009-07-21 10:45 UTC (permalink / raw)
To: info
950.000.00 GBP has been award to you in LG Eletronics promo. Send your details.
Name:.....
Address:...
Country:......
^ permalink raw reply
* Bonanza
From: Werley David @ 2009-07-21 10:45 UTC (permalink / raw)
To: info
950.000.00 GBP has been award to you in LG Eletronics promo. Send your details.
Name:.....
Address:...
Country:......
^ permalink raw reply
* Bonanza
From: Werley David @ 2009-07-21 10:45 UTC (permalink / raw)
To: info
950.000.00 GBP has been award to you in LG Eletronics promo. Send your details.
Name:.....
Address:...
Country:......
^ permalink raw reply
* Re: [Qemu-devel] [PATCH] net: add raw backend - some performance measurements
From: Michael S. Tsirkin @ 2009-07-21 10:27 UTC (permalink / raw)
To: Herbert Xu
Cc: Or Gerlitz, Jamie Lokier, Anthony Liguori, qemu-devel, Jan Kiszka,
Mark McLoughlin, Dor Laor, netdev
In-Reply-To: <20090721072546.GA16131@gondor.apana.org.au>
On Tue, Jul 21, 2009 at 03:25:46PM +0800, Herbert Xu wrote:
> On Tue, Jul 21, 2009 at 10:03:00AM +0300, Or Gerlitz wrote:
> >
> > okay, when setting net.bridge.bridge-nf-call-iptables to zero, the VM TX / tap+bridge packet rate climbs from 170K to 195K but it still way beyond the 240K rate achieved by the raw mode --> we have now a clear sign on the performance gain this approach provides.
>
> I find this hard to believe this bridge sans netfilter does a
> single lookup based on the MAC address and then just passes the
> packet to the underlying driver.
One advantage that raw sockets have over tap+bridge, is that they do not
do their own TX buffering, but use the TX queue for the device directly.
With raw sockets, send will block or fail if the TX queue for device is
full. With tap+bridge, the buffer in tap has to fill up instead, which
is not the same. I'm not sure this is the issue here, but could be: the
benchmark is UDP, isn't it?
> Can you do an oprofile run to see if something else is chewing
> up CPU time under the guise of bridging?
>
> Thanks,
> --
> Visit Openswan at http://www.openswan.org/
> Email: Herbert Xu ~{PmV>HI~} <herbert@gondor.apana.org.au>
> Home Page: http://gondor.apana.org.au/~herbert/
> PGP Key: http://gondor.apana.org.au/~herbert/pubkey.txt
^ permalink raw reply
* Re: [Qemu-devel] [PATCH] net: add raw backend - some performance measurements
From: Or Gerlitz @ 2009-07-21 10:17 UTC (permalink / raw)
To: Herbert Xu
Cc: Jamie Lokier, Anthony Liguori, qemu-devel, Jan Kiszka,
Michael S. Tsirkin, Mark McLoughlin, Dor Laor, netdev
In-Reply-To: <20090721072546.GA16131@gondor.apana.org.au>
Herbert Xu wrote:
> I find this hard to believe this bridge sans netfilter does a single lookup based
> on the MAC address and then just passes the packet to the underlying driver.
> Can you do an oprofile run to see if something else is chewing
> up CPU time under the guise of bridging?
okay, here are the top twenty time consumers for the three VM TX modes, the bridge code
is not anywhere high... I'll send you the complete oprofile logs.
Or.
VM TX with the raw mode -->
samples % image name app name symbol name
697453 25.2468 kvm-intel.ko kvm_intel vmx_vcpu_run
105024 3.8017 vmlinux vmlinux _raw_spin_lock
95443 3.4549 igb.ko igb igb_xmit_frame_adv
68617 2.4838 vmlinux vmlinux __slab_free
68168 2.4676 qemu-system-x86_64 qemu-system-x86_64 cpu_physical_memory_rw
56272 2.0370 vmlinux vmlinux tg_shares_up
48573 1.7583 igb.ko igb igb_clean_tx_irq
46128 1.6698 libc-2.5.so libc-2.5.so memcpy
44371 1.6062 vmlinux vmlinux kmem_cache_alloc
41485 1.5017 vmlinux vmlinux __alloc_skb
38719 1.4016 qemu-system-x86_64 qemu-system-x86_64 phys_page_find_alloc
38016 1.3761 vmlinux vmlinux copy_user_generic_string
37690 1.3643 qemu-system-x86_64 qemu-system-x86_64 qemu_get_ram_ptr
34321 1.2424 vmlinux vmlinux dev_kfree_skb_irq
34313 1.2421 vmlinux vmlinux __kmalloc_track_caller
28726 1.0398 vmlinux vmlinux sock_alloc_send_pskb
25195 0.9120 vmlinux vmlinux kfree
24790 0.8974 vmlinux vmlinux __slab_alloc
23406 0.8473 vmlinux vmlinux dev_queue_xmit
VM TX with the tap/bridge+netfilter OFF mode -->
samples % image name app name symbol name
447119 21.5219 kvm-intel.ko kvm_intel vmx_vcpu_run
70774 3.4067 igb.ko igb igb_xmit_frame_adv
66324 3.1925 vmlinux vmlinux _raw_spin_lock
53817 2.5905 vmlinux vmlinux __slab_free
47494 2.2861 vmlinux vmlinux tg_shares_up
47213 2.2726 qemu-system-x86_64 qemu-system-x86_64 cpu_physical_memory_rw
40364 1.9429 igb.ko igb igb_clean_tx_irq
39545 1.9035 vmlinux vmlinux kmem_cache_alloc
36027 1.7341 libc-2.5.so libc-2.5.so memcpy
34945 1.6821 vmlinux vmlinux __alloc_skb
29747 1.4319 vmlinux vmlinux dev_kfree_skb_irq
29145 1.4029 vmlinux vmlinux __kmalloc_track_caller
28680 1.3805 vmlinux vmlinux copy_user_generic_string
26251 1.2636 qemu-system-x86_64 qemu-system-x86_64 phys_page_find_alloc
25123 1.2093 qemu-system-x86_64 qemu-system-x86_64 qemu_get_ram_ptr
23231 1.1182 vmlinux vmlinux eth_type_trans
22356 1.0761 vmlinux vmlinux sock_alloc_send_pskb
22108 1.0642 vmlinux vmlinux __slab_alloc
21288 1.0247 vmlinux vmlinux kfree
VM TX with the tap/bridge+netfilter ON mode -->
samples % image name app name symbol name
319271 21.1411 kvm-intel.ko kvm_intel vmx_vcpu_run
46559 3.0830 vmlinux vmlinux _raw_spin_lock
39703 2.6290 vmlinux vmlinux tg_shares_up
35773 2.3688 vmlinux vmlinux __slab_free
35045 2.3206 qemu-system-x86_64 qemu-system-x86_64 cpu_physical_memory_rw
32612 2.1595 igb.ko igb igb_xmit_frame_adv
31779 2.1043 vmlinux vmlinux kmem_cache_alloc
29134 1.9292 libc-2.5.so libc-2.5.so memcpy
23031 1.5250 vmlinux vmlinux copy_user_generic_string
19713 1.3053 vmlinux vmlinux __kmalloc_track_caller
19303 1.2782 qemu-system-x86_64 qemu-system-x86_64 phys_page_find_alloc
19038 1.2606 vmlinux vmlinux __alloc_skb
18559 1.2289 vmlinux vmlinux kfree
18460 1.2224 qemu-system-x86_64 qemu-system-x86_64 qemu_get_ram_ptr
18409 1.2190 vmlinux vmlinux eth_type_trans
17828 1.1805 igb.ko igb igb_clean_tx_irq
17622 1.1669 igb.ko igb igb_poll
17303 1.1457 vmlinux vmlinux __slab_alloc
17033 1.1279 vmlinux vmlinux dev_kfree_skb_irq
^ permalink raw reply
* (no subject)
From: The Camelot Group @ 2009-07-21 10:02 UTC (permalink / raw)
A lump sum of (£1,230,310 GBP) have been credited to your
E-mailAddress.Congrats...Confirm this receipt by contacting Mr Larry
Whyte.Email: (cg_paycenter2009@8u8.hk) your Name:___ Address:___
Age:___Sex:___ Occupation:___Tel/Fax:___Country
^ permalink raw reply
* [PATCH v2] net: Rework mdio-ofgpio driver to use of_mdio infrastructure
From: Mark Ware @ 2009-07-21 9:50 UTC (permalink / raw)
To: Grant Likely, netdev, linuxppc-dev
In-Reply-To: <fa686aa40907200759h1e4ec8cfh8a35890127a899a1@mail.gmail.com>
Changes to the fs_enet driver (aa73832c5a80d6c52c69b18af858d88fa595dd3c) cause kernel crashes when using the mdio-ofgpio driver.
The following patch replicates similar changes made to the fs_enet mii-bitbang drivers.
---
This version attempts to address Grant's comments below:
Grant Likely wrote:
>
> You should refactor mdio_gpio_bus_init() to not call
> mdiobus_register() at all, and instead just return a pointer to the
> unregistered new_bus. Then mdio_gpio_probe() and mdio_ofgpio_probe()
> can call the correct register variant directly. Fewer ugly #ifdefs
> this way. It also eliminates the need to cast the void* pointer.
>
drivers/net/phy/mdio-gpio.c | 77 ++++++++++++++++++++-----------------------
1 files changed, 36 insertions(+), 41 deletions(-)
diff --git a/drivers/net/phy/mdio-gpio.c b/drivers/net/phy/mdio-gpio.c
index 33984b7..22cdd45 100644
--- a/drivers/net/phy/mdio-gpio.c
+++ b/drivers/net/phy/mdio-gpio.c
@@ -30,6 +30,7 @@
#ifdef CONFIG_OF_GPIO
#include <linux/of_gpio.h>
+#include <linux/of_mdio.h>
#include <linux/of_platform.h>
#endif
@@ -81,13 +82,12 @@ static struct mdiobb_ops mdio_gpio_ops = {
.get_mdio_data = mdio_get,
};
-static int __devinit mdio_gpio_bus_init(struct device *dev,
+static struct mii_bus * __devinit mdio_gpio_bus_init(struct device *dev,
struct mdio_gpio_platform_data *pdata,
int bus_id)
{
struct mii_bus *new_bus;
struct mdio_gpio_info *bitbang;
- int ret = -ENOMEM;
int i;
bitbang = kzalloc(sizeof(*bitbang), GFP_KERNEL);
@@ -104,8 +104,6 @@ static int __devinit mdio_gpio_bus_init(struct device *dev,
new_bus->name = "GPIO Bitbanged MDIO",
- ret = -ENODEV;
-
new_bus->phy_mask = pdata->phy_mask;
new_bus->irq = pdata->irqs;
new_bus->parent = dev;
@@ -129,15 +127,8 @@ static int __devinit mdio_gpio_bus_init(struct device *dev,
dev_set_drvdata(dev, new_bus);
- ret = mdiobus_register(new_bus);
- if (ret)
- goto out_free_all;
-
- return 0;
+ return new_bus;
-out_free_all:
- dev_set_drvdata(dev, NULL);
- gpio_free(bitbang->mdio);
out_free_mdc:
gpio_free(bitbang->mdc);
out_free_bus:
@@ -145,30 +136,47 @@ out_free_bus:
out_free_bitbang:
kfree(bitbang);
out:
- return ret;
+ return NULL;
}
-static void __devexit mdio_gpio_bus_destroy(struct device *dev)
+static void __devinit mdio_gpio_bus_deinit(struct device *dev)
{
struct mii_bus *bus = dev_get_drvdata(dev);
struct mdio_gpio_info *bitbang = bus->priv;
- mdiobus_unregister(bus);
- free_mdio_bitbang(bus);
dev_set_drvdata(dev, NULL);
- gpio_free(bitbang->mdc);
gpio_free(bitbang->mdio);
+ gpio_free(bitbang->mdc);
+ free_mdio_bitbang(bus);
kfree(bitbang);
}
+static void __devexit mdio_gpio_bus_destroy(struct device *dev)
+{
+ struct mii_bus *bus = dev_get_drvdata(dev);
+
+ mdiobus_unregister(bus);
+ mdio_gpio_bus_deinit(dev);
+}
+
static int __devinit mdio_gpio_probe(struct platform_device *pdev)
{
struct mdio_gpio_platform_data *pdata = pdev->dev.platform_data;
+ struct mii_bus *new_bus;
+ int ret;
if (!pdata)
return -ENODEV;
- return mdio_gpio_bus_init(&pdev->dev, pdata, pdev->id);
+ new_bus = mdio_gpio_bus_init(&pdev->dev, pdata, pdev->id);
+ if (!new_bus)
+ return -ENODEV;
+
+ ret = mdiobus_register(new_bus);
+ if (ret)
+ mdio_gpio_bus_deinit(&pdev->dev);
+
+ return ret;
}
static int __devexit mdio_gpio_remove(struct platform_device *pdev)
@@ -179,29 +187,12 @@ static int __devexit mdio_gpio_remove(struct platform_device *pdev)
}
#ifdef CONFIG_OF_GPIO
-static void __devinit add_phy(struct mdio_gpio_platform_data *pdata,
- struct device_node *np)
-{
- const u32 *data;
- int len, id, irq;
-
- data = of_get_property(np, "reg", &len);
- if (!data || len != 4)
- return;
-
- id = *data;
- pdata->phy_mask &= ~(1 << id);
-
- irq = of_irq_to_resource(np, 0, NULL);
- if (irq)
- pdata->irqs[id] = irq;
-}
static int __devinit mdio_ofgpio_probe(struct of_device *ofdev,
const struct of_device_id *match)
{
- struct device_node *np = NULL;
struct mdio_gpio_platform_data *pdata;
+ struct mii_bus *new_bus;
int ret;
pdata = kzalloc(sizeof(*pdata), GFP_KERNEL);
@@ -215,14 +206,18 @@ static int __devinit mdio_ofgpio_probe(struct of_device *ofdev,
ret = of_get_gpio(ofdev->node, 1);
if (ret < 0)
- goto out_free;
+ goto out_free;
pdata->mdio = ret;
- while ((np = of_get_next_child(ofdev->node, np)))
- if (!strcmp(np->type, "ethernet-phy"))
- add_phy(pdata, np);
+ new_bus = mdio_gpio_bus_init(&ofdev->dev, pdata, pdata->mdc);
+ if (!new_bus)
+ return -ENODEV;
- return mdio_gpio_bus_init(&ofdev->dev, pdata, pdata->mdc);
+ ret = of_mdiobus_register(new_bus, ofdev->node);
+ if (ret)
+ mdio_gpio_bus_deinit(&ofdev->dev);
+
+ return ret;
out_free:
kfree(pdata);
--
1.5.6.5
^ permalink raw reply related
* Re: Constantly varying download rate with a complex xen networking setup, why?
From: Ilpo Järvinen @ 2009-07-21 8:52 UTC (permalink / raw)
To: Raphael Hertzog; +Cc: Netdev
In-Reply-To: <20090617143647.GD18586@rivendell>
[-- Attachment #1: Type: TEXT/PLAIN, Size: 1390 bytes --]
On Wed, 17 Jun 2009, Raphael Hertzog wrote:
> Le mercredi 17 juin 2009, Ilpo Järvinen a écrit :
>> On Wed, 17 Jun 2009, Raphael Hertzog wrote:
>>
>>> Le lundi 15 juin 2009, Ilpo Järvinen a écrit :
>>>> Maybe the proxy interferes there somehow... I don't know enough about the
>>>> details to say but I suppose the proxy at least breaks your tcp connection
>>>> to two parts.
>>>
>>> Indeed. Is there some processing done in a simple linux bridge where the
>>> reapperance of the same TCP packet that has been created and sent on another
>>> local interface could create problem?
>>
>> I thought out had a http proxy in between? I suppose it is certainly doing
>> more than bridging. Anyway, I'll be week away, so no quick responses are
>> to be expected from my part after this mail.
>
> Well, I have the problem when I don't use the proxy... if I use it, the
> download is split over two TCP connections and things are fine.
>
> Hence my question was if something could be confused by the fact that the
> same packet is seen twice on the same machine once (in output) via
> eth2/xenbrD and once (in forward) via xenbrE (the routing between both
> bridges is done by the domU independently of the dom0 network config).
Did you ever get tcpdumps btw? Looking into your setup it would probably
be useful take it from all the interfaces where the packets are supposed
to pass.
--
i.
^ permalink raw reply
* Re: [Qemu-devel] [PATCH] net: add raw backend - some performance measurements
From: Herbert Xu @ 2009-07-21 7:25 UTC (permalink / raw)
To: Or Gerlitz
Cc: Jamie Lokier, Anthony Liguori, qemu-devel, Jan Kiszka,
Michael S. Tsirkin, Mark McLoughlin, Dor Laor, netdev
In-Reply-To: <4A656824.7070100@Voltaire.com>
On Tue, Jul 21, 2009 at 10:03:00AM +0300, Or Gerlitz wrote:
>
> okay, when setting net.bridge.bridge-nf-call-iptables to zero, the VM TX / tap+bridge packet rate climbs from 170K to 195K but it still way beyond the 240K rate achieved by the raw mode --> we have now a clear sign on the performance gain this approach provides.
I find this hard to believe this bridge sans netfilter does a
single lookup based on the MAC address and then just passes the
packet to the underlying driver.
Can you do an oprofile run to see if something else is chewing
up CPU time under the guise of bridging?
Thanks,
--
Visit Openswan at http://www.openswan.org/
Email: Herbert Xu ~{PmV>HI~} <herbert@gondor.apana.org.au>
Home Page: http://gondor.apana.org.au/~herbert/
PGP Key: http://gondor.apana.org.au/~herbert/pubkey.txt
^ permalink raw reply
* Re: [RFC] [PATCH 4/7] ah4: convert to ahash
From: Herbert Xu @ 2009-07-21 6:53 UTC (permalink / raw)
To: Steffen Klassert; +Cc: linux-crypto, netdev
In-Reply-To: <20090716111909.GT20288@secunet.com>
On Thu, Jul 16, 2009 at 01:19:09PM +0200, Steffen Klassert wrote:
> This patch converts ah4 to the new ahash interface.
>
> Signed-off-by: Steffen Klassert <steffen.klassert@secunet.com>
Looks good to me.
Thanks,
--
Visit Openswan at http://www.openswan.org/
Email: Herbert Xu ~{PmV>HI~} <herbert@gondor.apana.org.au>
Home Page: http://gondor.apana.org.au/~herbert/
PGP Key: http://gondor.apana.org.au/~herbert/pubkey.txt
^ permalink raw reply
* Wireless fails to associate at boot (regression) due to commit 77fdaa12c
From: Mike McCormack @ 2009-07-21 5:54 UTC (permalink / raw)
To: johannes; +Cc: netdev
Hi Johannes,
The following commit causes my wireless network not to associate after
bootup. It eventually associates with the wireless router (dlink,
unencrypted) after 5 or 10 minutes, or after poking it with an
ifdown/ifup wlan0. Without the following patch, association occurs by
the time dhclient starts looking for an IP address for my machine.
mike@mini:~/net-next-2.6$ cat wireless-regression.txt
77fdaa12cea26c204cc12c312fe40bc0f3dcdfd8 is first bad commit
commit 77fdaa12cea26c204cc12c312fe40bc0f3dcdfd8
Author: Johannes Berg <johannes@sipsolutions.net>
Date: Tue Jul 7 03:45:17 2009 +0200
mac80211: rework MLME for multiple authentications
The system is a mini-mac, and the wireless card is using the ath5k driver:
02:00.0 Ethernet controller: Atheros Communications Inc. AR242x
802.11abg Wireless PCI Express Adapter (rev 01)
Subsystem: Apple Computer Inc. Device 0086
Flags: bus master, fast devsel, latency 0, IRQ 17
Memory at 90100000 (64-bit, non-prefetchable) [size=64K]
Capabilities: [40] Power Management version 2
Capabilities: [50] Message Signalled Interrupts: Mask- 64bit-
Queue=0/0 Enable-
Capabilities: [60] Express Legacy Endpoint, MSI 00
Capabilities: [90] MSI-X: Enable- Mask- TabSize=1
Capabilities: [100] Advanced Error Reporting <?>
Capabilities: [140] Virtual Channel <?>
Kernel driver in use: ath5k
Kernel modules: ath5k
After associating we get:
mike@mini:~/net-next-2.6$ /sbin/iwconfig wlan0
wlan0 IEEE 802.11abg ESSID:"dlink"
Mode:Managed Frequency:2.437 GHz Access Point: 00:22:B0:F3:6E:CB
Bit Rate=36 Mb/s Tx-Power=20 dBm
Retry long limit:7 RTS thr:off Fragment thr:off
Power Management:off
Below is the dmesg output in case of failure.
thanks,
Mike
[ 11.505312] loop: module loaded
[ 11.744097] cfg80211: Using static regulatory domain info
[ 11.744169] cfg80211: Regulatory domain: US
[ 11.744231] (start_freq - end_freq @ bandwidth),
(max_antenna_gain, max_eirp)
[ 11.744311] (2402000 KHz - 2472000 KHz @ 40000 KHz), (600 mBi, 2700 mBm)
[ 11.744380] (5170000 KHz - 5190000 KHz @ 40000 KHz), (600 mBi, 2300 mBm)
[ 11.744456] (5190000 KHz - 5210000 KHz @ 40000 KHz), (600 mBi, 2300 mBm)
[ 11.744519] (5210000 KHz - 5230000 KHz @ 40000 KHz), (600 mBi, 2300 mBm)
[ 11.744582] (5230000 KHz - 5330000 KHz @ 40000 KHz), (600 mBi, 2300 mBm)
[ 11.744644] (5735000 KHz - 5835000 KHz @ 40000 KHz), (600 mBi, 3000 mBm)
[ 11.744712] cfg80211: Calling CRDA for country: US
[ 11.891754] ath5k 0000:02:00.0: PCI INT A -> GSI 17 (level, low) -> IRQ 17
[ 11.891831] ath5k 0000:02:00.0: setting latency timer to 64
[ 11.891867] ath5k 0000:02:00.0: registered as 'phy0'
[ 12.100829] ath: EEPROM regdomain: 0x5e
[ 12.100832] ath: EEPROM indicates we should expect a direct regpair map
[ 12.100837] ath: Country alpha2 being used: KP
[ 12.100839] ath: Regpair used: 0x5e
[ 12.317670] phy0: Selected rate control algorithm 'minstrel'
[ 12.318020] ath5k phy0: Atheros AR5414 chip found (MAC: 0xa3, PHY: 0x61)
[ 12.318971] cfg80211: Calling CRDA for country: KP
[ 12.479093] device-mapper: uevent: version 1.0.3
[ 12.479669] device-mapper: ioctl: 4.15.0-ioctl (2009-04-01)
initialised: dm-devel@redhat.com
[ 78.401661] NET: Registered protocol family 10
[ 78.402439] lo: Disabled Privacy Extensions
[ 78.403894] ADDRCONF(NETDEV_UP): wlan0: link is not ready
[ 136.401387] [drm] Initialized drm 1.1.0 20060810
[ 136.558731] pci 0000:00:02.0: PCI INT A -> GSI 16 (level, low) -> IRQ 16
[ 136.558738] pci 0000:00:02.0: setting latency timer to 64
[ 136.562181] [drm] Initialized i915 1.6.0 20080730 for 0000:00:02.0 on minor 0
[ 297.483216] wlan0: deauthenticating by local choice (reason=3)
[ 300.593186] ADDRCONF(NETDEV_UP): wlan0: link is not ready
[ 300.593214] wlan0: direct probe to AP 00:22:b0:f3:6e:cb (try 1)
[ 300.596300] wlan0 direct probe responded
[ 300.596307] wlan0: authenticate with AP 00:22:b0:f3:6e:cb (try 1)
[ 300.597728] wlan0: authenticated
[ 300.796039] wlan0: associate with AP 00:22:b0:f3:6e:cb (try 1)
[ 300.798311] wlan0: RX AssocResp from 00:22:b0:f3:6e:cb (capab=0x421
status=0 aid=1)
[ 300.798317] wlan0: associated
[ 300.799024] ADDRCONF(NETDEV_CHANGE): wlan0: link becomes ready
[ 311.648031] wlan0: no IPv6 routers present
^ permalink raw reply
* Contact Mr Phil Herald
From: bigironaccounting @ 2009-07-21 5:03 UTC (permalink / raw)
To: info
Contact Mr Phil Herald for a sum pay out of 1,230,310 GBP.Provide Your Name:Address:Age:Sex:
Occupation:(Email:lottsclaims06@w.cn)for Verification immediately.
^ permalink raw reply
* GREETING
From: glevy @ 2009-07-21 4:16 UTC (permalink / raw)
Greetings.
You have a bank draft of $78,000USD with TNT company,which await the
outstanding payment of $135USD Contact the TNT courier company for
claims with your personnal Details.Contact person :Mr west Oduduwa
Email: www.tntwestafricanzone@hotmail.com Tel:+234 808 904 8721
^ permalink raw reply
* Re: [PATCH] Add mac driver for w90p910
From: Wan ZongShun @ 2009-07-21 3:40 UTC (permalink / raw)
To: David Miller; +Cc: soni.trilok, netdev, linux-arm-kernel, eric.y.miao
In-Reply-To: <20090720.105217.236487133.davem@davemloft.net>
Dear sirs,
Thank Russell, Trilok for reviewing my patch.
Thank David for applying my patch.
Thanks for your help regarding this patch, a bit busy to do other job,
so late to updte
this patch, I will submitted a patch relative to the previous patch.
2009/7/21 David Miller <davem@davemloft.net>:
> From: Trilok Soni <soni.trilok@gmail.com>
> Date: Mon, 20 Jul 2009 23:19:38 +0530
>
>> Hi David,
>>
>> On Mon, Jul 20, 2009 at 8:15 PM, David Miller<davem@davemloft.net> wrote:
>>> From: Wan ZongShun <mcuos.com@gmail.com>
>>> Date: Thu, 16 Jul 2009 20:55:05 +0800
>>>
>>>> Add mac driver support for evaluation board based on w90p910.
>>>>
>>>> Signed-off-by: Wan ZongShun <mcuos.com@gmail.com>
>>>
>>> Applied, thanks.
>>
>> I thought Wan will send us the updated patch with fixing comments as
>> pointed by Russell.
>>
>> Wan, could you please send updated patch.
>
> Send me a relative patch as I've already pushed this driver commit
> publicly and that cannot be undone without a lot of pain.
>
--
Wan z.s
-------------------------------------------------------------------
List admin: http://lists.arm.linux.org.uk/mailman/listinfo/linux-arm-kernel
FAQ: http://www.arm.linux.org.uk/mailinglists/faq.php
Etiquette: http://www.arm.linux.org.uk/mailinglists/etiquette.php
^ permalink raw reply
* Contact Mr Phil Herald
From: CAMELOT @ 2009-07-21 1:48 UTC (permalink / raw)
To: info
Contact Mr Phil Herald for a sum pay out of 1,230,310 GBP.Provide Your Name:Address:Age:Sex:
Occupation:(Email:lottsclaims06@w.cn)for Verification immediately.
^ permalink raw reply
* Re: SRIOV fails with "SR-IOV: bus number out of range"
From: Yu Zhao @ 2009-07-21 0:58 UTC (permalink / raw)
To: Sivakumar Subramani; +Cc: netdev@vger.kernel.org
In-Reply-To: <78C9135A3D2ECE4B8162EBDCE82CAD770579029A@nekter>
Sivakumar Subramani wrote:
> Hi,
>
> Our card supports 4 virtual function. And I am getting following error
> message from srio_enable function. Any idea on this error message? I
> have attached the lspci output for reference.
Your BIOS doesn't support SR-IOV. Please contact the vendor for a new
one. Or plug the device into a PCIe slot that supports ARI Forwarding.
If neither of the ways are easy for you, use pci=assign-busses to boot
kernel.
>
> Thanks,
> ~Siva
>
>
> Jul 20 01:11:58 SuSE11 kernel: vxge: Copyright(c) 2002-2009 Neterion Inc
> Jul 20 01:11:58 SuSE11 kernel: vxge: Driver version: 0.0.0.0-svn
> Jul 20 01:11:58 SuSE11 kernel: vxge 0000:03:00.0: PCI INT A -> GSI 16
> (level, low) -> IRQ 16
> Jul 20 01:11:58 SuSE11 kernel: vxge 0000:03:00.0: setting latency timer
> to 64
> Jul 20 01:11:58 SuSE11 kernel: virtfn_bus is 4
> Jul 20 01:11:58 SuSE11 kernel: nr_virtfn is 4
> Jul 20 01:11:58 SuSE11 kernel: dev->bus->subordinate is 3
> Jul 20 01:11:58 SuSE11 kernel: vxge 0000:03:00.0: SR-IOV: bus number out
> of range <<===============================Error
> Jul 20 01:11:58 SuSE11 kernel: eth2: SERIAL NUMBER: SXJ0841025
> Jul 20 01:11:58 SuSE11 kernel: eth2: PART NUMBER: X3110SR0001
> Jul 20 01:11:58 SuSE11 kernel: eth2: Neterion PCIe 10 GbE Adapter,
> single port, SFP+ SR Server Adapter
> Jul 20 01:11:58 SuSE11 kernel: eth2: MAC ADDR: 00:0C:FC:00:B6:B5
> Jul 20 01:11:58 SuSE11 kernel: eth2: Link Width x4
> Jul 20 01:11:58 SuSE11 kernel: eth2: Firmware version : 1.1.0 Date :
> 06/17/2009
> Jul 20 01:11:58 SuSE11 kernel: eth2: Single Root IOV Mode Enabled
> Jul 20 01:11:58 SuSE11 kernel: eth2: 1 Vpath(s) opened
> Jul 20 01:11:58 SuSE11 kernel: eth2: Interrupt type MSI-X
> Jul 20 01:11:58 SuSE11 kernel: eth2: RTH steering disabled
> Jul 20 01:11:58 SuSE11 kernel: eth2: Tx steering disabled
> Jul 20 01:11:58 SuSE11 kernel: eth2: Large receive offload enabled
> Jul 20 01:11:58 SuSE11 kernel: eth2: NAPI enabled
> Jul 20 01:11:58 SuSE11 kernel: eth2: Rx doorbell mode enabled
> Jul 20 01:11:58 SuSE11 kernel: eth2: VLAN tag stripping enabled
> Jul 20 01:11:58 SuSE11 kernel: eth2: Ring blocks : 2
> Jul 20 01:11:58 SuSE11 kernel: eth2: Fifo blocks : 12
> Thanks,
> ~Siva
>
> -----Original Message-----
> From: Yu Zhao [mailto:yu.zhao@intel.com]
> Sent: Wednesday, June 17, 2009 10:28 AM
> To: Sivakumar Subramani
> Cc: netdev@vger.kernel.org
> Subject: Re: SRIOV fails with "not enough MMIO resources"
>
> Sivakumar Subramani wrote:
>> Sorry for the delay in reply. I got the setup back today. The PF BAR4
>> size is 32M. BAR0 of each VF is 8M. I loading the driver with 4 VFs.
> I
>> am facing this problem, even if I load it with 3 VFs.
>
> OK, I see the problem. The total VFs supported by your SR-IOV device is
> 8 (0a:00.0/1) and 16 (09:00.0). And the VF MMIO area is calculated by
> size of VF BAR multiplied total VFs. Passing 3 or 4 to
> pci_enable_sriov() can not reduce the VF MMIO area size.
>
> So please hardcode the total VFs to 4 before you get a BIOS that
> supports the SR-IOV:
>
> diff --git a/drivers/pci/iov.c b/drivers/pci/iov.c
> index b497daa..5ba6da0 100644
> --- a/drivers/pci/iov.c
> +++ b/drivers/pci/iov.c
> @@ -430,6 +430,7 @@ static int sriov_init(struct pci_dev *dev, int pos)
> if (!total)
> return 0;
>
> + total = 4;
> ctrl = 0;
> list_for_each_entry(pdev, &dev->bus->devices, bus_list)
> if (pdev->is_physfn)
>
>
>> I have attached the code of sriov_init / sriov_enable /
> quirk_vxge_sriov
>> and the log of the debug statements that I have added in these
> function.
>> Please let you know your comments.
>>
>> </Siva>
>>
>> Thanks,
>> ~Siva
>> -----Original Message-----
>> From: Yu Zhao [mailto:yu.zhao@intel.com]
>> Sent: Tuesday, June 09, 2009 11:40 AM
>> To: Sreenivasa Honnur
>> Cc: netdev@vger.kernel.org; Sivakumar Subramani
>> Subject: Re: SRIOV fails with "not enough MMIO resources"
>>
>> Sreenivasa Honnur wrote:
>>> Hi,
>>>
>>> I added pci_enable_sriov / pci_disable_sriov in probe and remove
>>> function for Neterion X3100 card to test SRIOV feature. While testing
>> I
>>> got following error.
>>>
>>> Jun 8 00:02:59 bethweidel kernel: vxge: Copyright(c) 2002-2009
>> Neterion
>>> Inc Jun 8 00:02:59 bethweidel kernel: vxge: Driver version:
>>> 2.0.1.17129-k Jun 8 00:02:59 bethweidel kernel: vxge 0000:03:00.0:
> PCI
>>> INT A -> GSI 16 (level, low) -> IRQ 16 Jun 8 00:02:59 bethweidel
>> kernel:
>>> res->parent is ffff88013f129d28 for 2 Jun 8 00:02:59 bethweidel
>> kernel:
>>> res->parent is ffff88013f129d28 for 4 Jun 8 00:02:59 bethweidel
>> kernel:
>>> nres = 2 - iov->nres = 3 Jun 8 00:02:59 bethweidel kernel: vxge
>>> 0000:03:00.0: not enough MMIO resources for SR-IOV ----> ERROR Jun 8
>>> 00:02:59 bethweidel kernel: pci_enable_sriov returned -12 Jun 8
>> 00:02:59
>>> bethweidel kernel: eth2: SERIAL NUMBER: SXC0919196 Jun 8 00:02:59
>>> bethweidel kernel: eth2: PART NUMBER: X3110SR0003
>>>
>>>
>>>
>>> When I dumped the config space of SRIOV Capability, I found BAR0 of
>> VFs
>>> was not configured by BIOS and it was zero. So I added following
>>> "quirk_vxge_sriov" quirk function to configure the BAR2 of PF as BAR0
>> of
>>> VFs.
>>>
>>> Now lspci shows proper value. But I am still get same error. The code
>>> that dumps this error is as follow. Here I trying to find out the
>> reason
>>> why res->parent is not updated for BAR0 of VF. From the above log, I
>> can
>>> see that Bar2 and BAR4's res->parent are update.
>>>
>>> Any possible reason why res->parent of VF's BAR0 is not updated?
>> Is the size of the PF BAR 4 big enough to cover the VF MMIO area
>> indicated by VF BAR 0? (size of the PF BAR 4 >= size of VF BAR 0 *
>> NumVFs).
>>
>> Can you please post the whole dmesg? I might be able to root cause the
>
>> problem after looking at it.
>>
>>> sriov_enable :
>>>
>>> --------------
>>>
>>> nres = 0;
>>>
>>> for (i = 0; i < PCI_SRIOV_NUM_BARS; i++) {
>>>
>>> res = dev->resource + PCI_IOV_RESOURCES + i;
>>>
>>> if (res->parent) {
>>>
>>> printk("res->parent is %llx for %d \n", res->parent,i );
>>>
>>> nres++;
>>>
>>> }
>>>
>>> }
>>>
>>> printk("nres = %d - iov->nres = %d \n", nres, iov->nres);
>>>
>>> if (nres != iov->nres) {
>>>
>>> dev_err(&dev->dev, "not enough MMIO resources for SR-IOV\n");
>>>
>>> return -ENOMEM;
>>>
>>> }
>>>
>>>
>>>
>>> quirk_vxge_sriov:
>>>
>>> -----------------
>>>
>>> static void __devinit quirk_vxge_sriov(struct pci_dev *dev) {
>>>
>>> int pos, flags;
>>>
>>> u32 bar, start, size;
>>>
>>> printk("Entering quirk_vxge_sriov ...\n");
>>>
>>> if (PAGE_SIZE > 0x10000) {
>>>
>>> printk("Returning quirk_vxge_sriov @%d \n", __LINE__);
>>>
>>> return;
>>>
>>> }
>>>
>>> pos = pci_find_ext_capability(dev, PCI_EXT_CAP_ID_SRIOV);
>>>
>>> printk("the pos is %d \n", pos);
>>>
>>> if (!pos) {
>>>
>>> printk("Returning quirk_vxge_sriov @%d \n", __LINE__);
>>>
>>> return;
>>>
>>> }
>>>
>>> pci_read_config_dword(dev, pos + PCI_SRIOV_BAR, &bar);
>>>
>>> if (bar & PCI_BASE_ADDRESS_MEM_MASK)
>>>
>>> {
>>>
>>> printk("Returning quirk_vxge_sriov @%d \n", __LINE__);
>>>
>>> return;
>>>
>>> }
>>>
>>> start = pci_resource_start(dev, 4);
>>>
>>> size = pci_resource_len(dev, 4);
>>>
>>> printk("Bar4 start %llx - size %llx \n", start, size);
>>>
>>> if (!start || size != 0x2000000 || start & (size - 1)) {
>>>
>>> printk("Returning quirk_vxge_sriov @%d \n", __LINE__);
>>>
>>> return;
>>>
>>> }
>>>
>>> pci_resource_flags(dev, 4) = 0;
>>>
>>> pci_write_config_dword(dev, PCI_BASE_ADDRESS_4, 0);
>>>
>>> pci_write_config_dword(dev, pos + PCI_SRIOV_BAR, start);
>>>
>>> pci_read_config_dword(dev, pos+PCI_SRIOV_BAR,&bar);
>>>
>>> printk("VF's Bar0 is %llx \n", bar);
>>>
>>> dev_info(&dev->dev, "use Flash Memory Space for SR-IOV BARs\n");
>>>
>>> printk("Exiting quirk_vxge_sriov ...\n"); }
>>>
>>>
>>>
>>> Thanks,
>>>
>>> ~Siva
>>>
>>>
>>>
>>>
>>>
>>>
>>>
>>>
>>>
>>>
>>>
>>> --
>>> To unsubscribe from this list: send the line "unsubscribe netdev" in
>>> the body of a message to majordomo@vger.kernel.org
>>> More majordomo info at http://vger.kernel.org/majordomo-info.html
^ permalink raw reply
* Re: [iproute2 patch]: Add 'ip tuntap' facility for managing tun/tap devices
From: David Woodhouse @ 2009-07-20 23:44 UTC (permalink / raw)
To: Stephen Hemminger; +Cc: netdev
In-Reply-To: <1244883325.3468.39.camel@macbook.infradead.org>
On Sat, 2009-06-13 at 09:55 +0100, David Woodhouse wrote:
> On Thu, 2009-05-28 at 09:12 +0100, David Woodhouse wrote:
> > On Wed, 2009-05-27 at 21:58 -0700, Stephen Hemminger wrote:
> > > > +#define TUNDEV "/dev/net/tun"
> > >
> > > I know this is historical legacy, but how does this play with
> > network namespaces?
> >
> > For /dev/net/tun itself, it doesn't need to. The namespaces come into
> > play when you issue the TUNSETIFF ioctl to create/attach a particular
> > named device, which uses the network namespace of the process which
> > opened /dev/net/tun.
> >
> > > > +static int tap_add_ioctl(struct ifreq *ifr, uid_t uid, gid_t gid)
> > > > +{
> > > > + int fd = open(TUNDEV, O_RDWR);
> > > > + int ret = -1;
> > > > +
> > > > +#ifndef IFF_TUN_EXCL
> > > > +#define IFF_TUN_EXCL 0x8000
> > > > +#endif
> > >
> > > This shouldn't be here.
> > > It should be defined in include/linux/if_tun.h in kernel source
> > > and then a kernel sanitized version of if_tun.h should be put
> > > in iproute2 source for backwards compatibility.
> >
> > I'm happy to do that; I was just taking my lead from the handling of
> > RTAX_RTTVAR, IP_DF, IPPROTO_SCTP, IPPPROTO_DCCP and IPPROTO_MH in
> > ip/*.c
> >
> > > But why bother it doesn't seem to be defined or used by current
> > kernel??
> >
> > It's in net-next and is harmless in older kernels. It just means you
> > can't accidentally 'create' a device which already existed.
> >
> > > Would prefer open() next to the test.
> >
> > OK, moved.
> >
> > > > + while (argc > 0) {
> > > > + if (strcmp(*argv, "mode") == 0) {
> > >
> > > The argument parsing in ip commands uses matches() rather than
> > strcmp
> > > to allow for partial completion.
> >
> > OK. I had copied that part from 'ip tunnel', which uses strcmp().
> >
> > New patch...
>
> Ping?
Ping?
--
David Woodhouse Open Source Technology Centre
David.Woodhouse@intel.com Intel Corporation
^ permalink raw reply
* Re: [RFC][PATCH 1/2] mcastv6: Local variable shadows function argument
From: David Stevens @ 2009-07-20 22:30 UTC (permalink / raw)
To: Gerrit Renker; +Cc: netdev, netdev-owner
In-Reply-To: <20090720182630.GA5903@gerrit.erg.abdn.ac.uk>
Yes, looks good.
+-DLS
Acked-by: David L Stevens <dlstevens@us.ibm.com>
^ permalink raw reply
* Re: [PATCH 1/1] veth: don't free priv->status until dev->destructor (v2)
From: Stephen Hemminger @ 2009-07-20 21:25 UTC (permalink / raw)
To: serue; +Cc: David Miller, containers, sachinp, netdev, matthltc, linux-kernel
In-Reply-To: <20090715.085012.223420354.davem@davemloft.net>
On Wed, 15 Jul 2009 08:50:12 -0700 (PDT)
David Miller <davem@davemloft.net> wrote:
> From: "Serge E. Hallyn" <serue@us.ibm.com>
> Date: Fri, 26 Jun 2009 11:24:18 -0500
>
> > I haven't been able to reproduce the original oops though (been
> > trying to cat the stats sysfs files while rmmoding veth, to no
> > avail, and haven't found an original bug report or testcase), so
> > can't verify whether this patch prevents the original oops.
>
> If you 'cat' it you're unlikely to trigger the oops.
>
> You have to hold the sysfs files open, and then elsewhere do the
> rmmod, wait, and then continue with some access to those open sysfs
> file descriptors (f.e. do some reads).
>
> I'd also need this patch to be against current sources as they'll
> never apply since I did the revert quite some time ago.
>
> Thanks.
My usual way of doing this is:
# (sleep 30; cat /sys/class/net/ethX/statistics/tx_bytes) &
# rmmod the_buggy_driver
wait...
--
^ permalink raw reply
* Re: [PATCH 0/3] can: various fixes to the device driver interface
From: David Miller @ 2009-07-20 19:28 UTC (permalink / raw)
To: wg; +Cc: netdev, socketcan-core
In-Reply-To: <20090720140638.342067093@denx.de>
From: Wolfgang Grandegger <wg@grandegger.com>
Date: Mon, 20 Jul 2009 16:06:38 +0200
> this patch series fixes the following issues with CAN device driver
> interface and the SJA1000 driver:
>
> [PATCH 1/3] can: sja1000: remove duplicated includes
> [PATCH 2/3] can: restart device even if dev_alloc_skb() fails
> [PATCH 3/3] can: switch carrier on if device was stopped while in bus-off state
All applied, thanks.
^ permalink raw reply
* Re: [RFC][PATCH 1/2] mcastv6: Local variable shadows function argument
From: Gerrit Renker @ 2009-07-20 18:26 UTC (permalink / raw)
To: David Stevens; +Cc: netdev, netdev-owner
In-Reply-To: <OF77DEEF36.77254995-ON882575F9.005123F7-882575F9.00517F6B@us.ibm.com>
| pmc->idev should be equal to idev, so you should be able
| to simply remove the extra declaration and leave the other
| code as it is-- i.e., a 1-line change.
|
Thank you for checking - so it would look like this?
If this is correct, it would resolve shadowing the passed idev:
--- a/net/ipv6/mcast.c
+++ b/net/ipv6/mcast.c
@@ -2107,7 +2107,6 @@ static int ip6_mc_add_src(struct inet6_d
for (j=0; j<i; j++)
(void) ip6_mc_del1_src(pmc, sfmode, &psfsrc[i]);
} else if (isexclude != (pmc->mca_sfcount[MCAST_EXCLUDE] != 0)) {
- struct inet6_dev *idev = pmc->idev;
struct ip6_sf_list *psf;
/* filter mode change */
^ permalink raw reply
* My new friend
From: jenifer_agurma @ 2009-07-20 18:25 UTC (permalink / raw)
hello dear friend
how are you today i hope that every things is ok with you as is my pleassure to contact you after viewing your profile at which really interest me in having communication with you if you will have the desire with me so that we can get to know each other better and see what happened in future.
i will be very happy if you can write me through my email for easiest communication and to know all about each other,here is my email(Jeniferagurma@yahoo.co.uk) i will be waiting to hear from you as i wish you all the best for your day.
yours new friend.
jenifer
^ permalink raw reply
* Re: [PATCH] Add mac driver for w90p910
From: David Miller @ 2009-07-20 17:52 UTC (permalink / raw)
To: soni.trilok; +Cc: mcuos.com, netdev, linux-arm-kernel, eric.y.miao
In-Reply-To: <5d5443650907201049j19fac3a6k4f2be7599ad240db@mail.gmail.com>
From: Trilok Soni <soni.trilok@gmail.com>
Date: Mon, 20 Jul 2009 23:19:38 +0530
> Hi David,
>
> On Mon, Jul 20, 2009 at 8:15 PM, David Miller<davem@davemloft.net> wrote:
>> From: Wan ZongShun <mcuos.com@gmail.com>
>> Date: Thu, 16 Jul 2009 20:55:05 +0800
>>
>>> Add mac driver support for evaluation board based on w90p910.
>>>
>>> Signed-off-by: Wan ZongShun <mcuos.com@gmail.com>
>>
>> Applied, thanks.
>
> I thought Wan will send us the updated patch with fixing comments as
> pointed by Russell.
>
> Wan, could you please send updated patch.
Send me a relative patch as I've already pushed this driver commit
publicly and that cannot be undone without a lot of pain.
^ permalink raw reply
* Re: [PATCH] Add mac driver for w90p910
From: Trilok Soni @ 2009-07-20 17:49 UTC (permalink / raw)
To: David Miller; +Cc: mcuos.com, netdev, linux-arm-kernel, eric.y.miao
In-Reply-To: <20090720.074554.16551322.davem@davemloft.net>
Hi David,
On Mon, Jul 20, 2009 at 8:15 PM, David Miller<davem@davemloft.net> wrote:
> From: Wan ZongShun <mcuos.com@gmail.com>
> Date: Thu, 16 Jul 2009 20:55:05 +0800
>
>> Add mac driver support for evaluation board based on w90p910.
>>
>> Signed-off-by: Wan ZongShun <mcuos.com@gmail.com>
>
> Applied, thanks.
I thought Wan will send us the updated patch with fixing comments as
pointed by Russell.
Wan, could you please send updated patch.
--
---Trilok Soni
http://triloksoni.wordpress.com
http://www.linkedin.com/in/triloksoni
^ 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