* [PATCH] USB: net: Fix asix read transfer buffer allocations.
From: Valentine Barshak @ 2007-10-24 11:33 UTC (permalink / raw)
To: linux-usb-devel; +Cc: netdev
In-Reply-To: <20071023200034.BB2B923A4FD@adsl-69-226-248-13.dsl.pltn13.pacbell.net>
On systems with noncoherent cache, allocating dma buffers
on the stack for USB IN transfers causes kernel crash,
because usb map_urb_for_dma() code calls dma_map_single(),
that invalidates data cache for DMA_FROM_DEVICE transfer direction
and causes stack data loss if transfer size is less than cache line
and not cache-line aligned. This patch makes asix usb network
driver allocate USB IN transfer buffers with kmalloc instead of
directly using variables on stack. It also sets data parameter to NULL
for zero-length transfers and uses ETH_ALEN size for allocating MAC
address buffer.
Signed-off-by: Valentine Barshak <vbarshak@ru.mvista.com>
---
drivers/net/usb/asix.c | 44 +++++++++++++++++++++++++++++++-------------
1 files changed, 31 insertions(+), 13 deletions(-)
diff -pruN linux-2.6.orig/drivers/net/usb/asix.c linux-2.6/drivers/net/usb/asix.c
--- linux-2.6.orig/drivers/net/usb/asix.c 2007-10-23 20:52:11.000000000 +0400
+++ linux-2.6/drivers/net/usb/asix.c 2007-10-23 20:57:38.000000000 +0400
@@ -568,15 +568,23 @@ static void asix_set_multicast(struct ne
static int asix_mdio_read(struct net_device *netdev, int phy_id, int loc)
{
struct usbnet *dev = netdev_priv(netdev);
+ void *buf;
u16 res;
+ buf = kmalloc(2, GFP_KERNEL);
+ if (!buf)
+ return -ENOMEM;
+
mutex_lock(&dev->phy_mutex);
asix_set_sw_mii(dev);
asix_read_cmd(dev, AX_CMD_READ_MII_REG, phy_id,
- (__u16)loc, 2, (u16 *)&res);
+ (__u16)loc, 2, buf);
asix_set_hw_mii(dev);
mutex_unlock(&dev->phy_mutex);
+ res = *((u16 *)buf);
+ kfree(buf);
+
devdbg(dev, "asix_mdio_read() phy_id=0x%02x, loc=0x%02x, returns=0x%04x", phy_id, loc, le16_to_cpu(res & 0xffff));
return le16_to_cpu(res & 0xffff);
@@ -622,13 +630,22 @@ static void
asix_get_wol(struct net_device *net, struct ethtool_wolinfo *wolinfo)
{
struct usbnet *dev = netdev_priv(net);
+ void *buf;
u8 opt;
- if (asix_read_cmd(dev, AX_CMD_READ_MONITOR_MODE, 0, 0, 1, &opt) < 0) {
+ buf = kmalloc(1, GFP_KERNEL);
+ if (!buf)
+ return;
+
+ if (asix_read_cmd(dev, AX_CMD_READ_MONITOR_MODE, 0, 0, 1, buf) < 0) {
wolinfo->supported = 0;
wolinfo->wolopts = 0;
+ kfree(buf);
return;
}
+ opt = *((u8 *)buf);
+ kfree(buf);
+
wolinfo->supported = WAKE_PHY | WAKE_MAGIC;
wolinfo->wolopts = 0;
if (opt & AX_MONITOR_MODE) {
@@ -644,7 +661,6 @@ asix_set_wol(struct net_device *net, str
{
struct usbnet *dev = netdev_priv(net);
u8 opt = 0;
- u8 buf[1];
if (wolinfo->wolopts & WAKE_PHY)
opt |= AX_MONITOR_LINK;
@@ -654,7 +670,7 @@ asix_set_wol(struct net_device *net, str
opt |= AX_MONITOR_MODE;
if (asix_write_cmd(dev, AX_CMD_WRITE_MONITOR_MODE,
- opt, 0, 0, &buf) < 0)
+ opt, 0, 0, NULL) < 0)
return -EINVAL;
return 0;
@@ -820,7 +836,7 @@ static int ax88172_bind(struct usbnet *d
for (i = 2; i >= 0; i--) {
if ((ret = asix_write_cmd(dev, AX_CMD_WRITE_GPIOS,
(gpio_bits >> (i * 8)) & 0xff, 0, 0,
- buf)) < 0)
+ NULL)) < 0)
goto out2;
msleep(5);
}
@@ -831,7 +847,7 @@ static int ax88172_bind(struct usbnet *d
/* Get the MAC address */
memset(buf, 0, ETH_ALEN);
if ((ret = asix_read_cmd(dev, AX88172_CMD_READ_NODE_ID,
- 0, 0, 6, buf)) < 0) {
+ 0, 0, ETH_ALEN, buf)) < 0) {
dbg("read AX_CMD_READ_NODE_ID failed: %d", ret);
goto out2;
}
@@ -909,7 +925,7 @@ static int ax88772_bind(struct usbnet *d
usbnet_get_endpoints(dev,intf);
- buf = kmalloc(6, GFP_KERNEL);
+ buf = kmalloc(ETH_ALEN, GFP_KERNEL);
if(!buf) {
dbg ("Cannot allocate memory for buffer");
ret = -ENOMEM;
@@ -923,7 +939,7 @@ static int ax88772_bind(struct usbnet *d
/* 0x10 is the phy id of the embedded 10/100 ethernet phy */
embd_phy = ((asix_get_phy_addr(dev) & 0x1f) == 0x10 ? 1 : 0);
if ((ret = asix_write_cmd(dev, AX_CMD_SW_PHY_SELECT,
- embd_phy, 0, 0, buf)) < 0) {
+ embd_phy, 0, 0, NULL)) < 0) {
dbg("Select PHY #1 failed: %d", ret);
goto out2;
}
@@ -998,7 +1014,7 @@ static int ax88772_bind(struct usbnet *d
if ((ret = asix_write_cmd(dev, AX_CMD_WRITE_IPG0,
AX88772_IPG0_DEFAULT | AX88772_IPG1_DEFAULT,
- AX88772_IPG2_DEFAULT, 0, buf)) < 0) {
+ AX88772_IPG2_DEFAULT, 0, NULL)) < 0) {
dbg("Write IPG,IPG1,IPG2 failed: %d", ret);
goto out2;
}
@@ -1202,20 +1218,22 @@ static int ax88178_bind(struct usbnet *d
usbnet_get_endpoints(dev,intf);
- buf = kmalloc(6, GFP_KERNEL);
+ buf = kmalloc(ETH_ALEN, GFP_KERNEL);
if(!buf) {
dbg ("Cannot allocate memory for buffer");
ret = -ENOMEM;
goto out1;
}
- eeprom = 0;
- asix_read_cmd(dev, AX_CMD_READ_GPIOS, 0, 0, 1, &eeprom);
+ memset(buf, 0, ETH_ALEN);
+ asix_read_cmd(dev, AX_CMD_READ_GPIOS, 0, 0, 1, buf);
+ eeprom = *(u8 *)buf;
dbg("GPIO Status: 0x%04x", eeprom);
asix_write_cmd(dev, AX_CMD_WRITE_ENABLE, 0, 0, 0, NULL);
- asix_read_cmd(dev, AX_CMD_READ_EEPROM, 0x0017, 0, 2, &eeprom);
+ asix_read_cmd(dev, AX_CMD_READ_EEPROM, 0x0017, 0, 2, buf);
asix_write_cmd(dev, AX_CMD_WRITE_DISABLE, 0, 0, 0, NULL);
+ eeprom = *(u16 *)buf;
dbg("EEPROM index 0x17 is 0x%04x", eeprom);
-------------------------------------------------------------------------
This SF.net email is sponsored by: Splunk Inc.
Still grepping through log files to find problems? Stop.
Now Search log events and configuration files using AJAX and a browser.
Download your FREE copy of Splunk now >> http://get.splunk.com/
_______________________________________________
linux-usb-devel@lists.sourceforge.net
To unsubscribe, use the last form field at:
https://lists.sourceforge.net/lists/listinfo/linux-usb-devel
^ permalink raw reply
* Re: [PATCH] USB: net: Fix asix read transfer buffer allocations.
From: Valentine Barshak @ 2007-10-24 11:33 UTC (permalink / raw)
To: linux-usb-devel; +Cc: david-b, netdev
In-Reply-To: <20071024112448.GA6695@ru.mvista.com>
Sorry,
CC'ed Dave Brownell instead of Dave Hollis :)
-------------------------------------------------------------------------
This SF.net email is sponsored by: Splunk Inc.
Still grepping through log files to find problems? Stop.
Now Search log events and configuration files using AJAX and a browser.
Download your FREE copy of Splunk now >> http://get.splunk.com/
_______________________________________________
linux-usb-devel@lists.sourceforge.net
To unsubscribe, use the last form field at:
https://lists.sourceforge.net/lists/listinfo/linux-usb-devel
^ permalink raw reply
* [PATCH] USB: net: Fix asix read transfer buffer allocations.
From: Valentine Barshak @ 2007-10-24 11:24 UTC (permalink / raw)
To: linux-usb-devel; +Cc: david-b, netdev
In-Reply-To: <20071023200034.BB2B923A4FD@adsl-69-226-248-13.dsl.pltn13.pacbell.net>
On systems with noncoherent cache, allocating dma buffers
on the stack for USB IN transfers causes kernel crash,
because usb map_urb_for_dma() code calls dma_map_single(),
that invalidates data cache for DMA_FROM_DEVICE transfer direction
and causes stack data loss if transfer size is less than cache line
and not cache-line aligned. This patch makes asix usb network
driver allocate USB IN transfer buffers with kmalloc instead of
directly using variables on stack. It also sets data parameter to NULL
for zero-length transfers and uses ETH_ALEN size for allocating MAC
address buffer.
Signed-off-by: Valentine Barshak <vbarshak@ru.mvista.com>
---
drivers/net/usb/asix.c | 44 +++++++++++++++++++++++++++++++-------------
1 files changed, 31 insertions(+), 13 deletions(-)
diff -pruN linux-2.6.orig/drivers/net/usb/asix.c linux-2.6/drivers/net/usb/asix.c
--- linux-2.6.orig/drivers/net/usb/asix.c 2007-10-23 20:52:11.000000000 +0400
+++ linux-2.6/drivers/net/usb/asix.c 2007-10-23 20:57:38.000000000 +0400
@@ -568,15 +568,23 @@ static void asix_set_multicast(struct ne
static int asix_mdio_read(struct net_device *netdev, int phy_id, int loc)
{
struct usbnet *dev = netdev_priv(netdev);
+ void *buf;
u16 res;
+ buf = kmalloc(2, GFP_KERNEL);
+ if (!buf)
+ return -ENOMEM;
+
mutex_lock(&dev->phy_mutex);
asix_set_sw_mii(dev);
asix_read_cmd(dev, AX_CMD_READ_MII_REG, phy_id,
- (__u16)loc, 2, (u16 *)&res);
+ (__u16)loc, 2, buf);
asix_set_hw_mii(dev);
mutex_unlock(&dev->phy_mutex);
+ res = *((u16 *)buf);
+ kfree(buf);
+
devdbg(dev, "asix_mdio_read() phy_id=0x%02x, loc=0x%02x, returns=0x%04x", phy_id, loc, le16_to_cpu(res & 0xffff));
return le16_to_cpu(res & 0xffff);
@@ -622,13 +630,22 @@ static void
asix_get_wol(struct net_device *net, struct ethtool_wolinfo *wolinfo)
{
struct usbnet *dev = netdev_priv(net);
+ void *buf;
u8 opt;
- if (asix_read_cmd(dev, AX_CMD_READ_MONITOR_MODE, 0, 0, 1, &opt) < 0) {
+ buf = kmalloc(1, GFP_KERNEL);
+ if (!buf)
+ return;
+
+ if (asix_read_cmd(dev, AX_CMD_READ_MONITOR_MODE, 0, 0, 1, buf) < 0) {
wolinfo->supported = 0;
wolinfo->wolopts = 0;
+ kfree(buf);
return;
}
+ opt = *((u8 *)buf);
+ kfree(buf);
+
wolinfo->supported = WAKE_PHY | WAKE_MAGIC;
wolinfo->wolopts = 0;
if (opt & AX_MONITOR_MODE) {
@@ -644,7 +661,6 @@ asix_set_wol(struct net_device *net, str
{
struct usbnet *dev = netdev_priv(net);
u8 opt = 0;
- u8 buf[1];
if (wolinfo->wolopts & WAKE_PHY)
opt |= AX_MONITOR_LINK;
@@ -654,7 +670,7 @@ asix_set_wol(struct net_device *net, str
opt |= AX_MONITOR_MODE;
if (asix_write_cmd(dev, AX_CMD_WRITE_MONITOR_MODE,
- opt, 0, 0, &buf) < 0)
+ opt, 0, 0, NULL) < 0)
return -EINVAL;
return 0;
@@ -820,7 +836,7 @@ static int ax88172_bind(struct usbnet *d
for (i = 2; i >= 0; i--) {
if ((ret = asix_write_cmd(dev, AX_CMD_WRITE_GPIOS,
(gpio_bits >> (i * 8)) & 0xff, 0, 0,
- buf)) < 0)
+ NULL)) < 0)
goto out2;
msleep(5);
}
@@ -831,7 +847,7 @@ static int ax88172_bind(struct usbnet *d
/* Get the MAC address */
memset(buf, 0, ETH_ALEN);
if ((ret = asix_read_cmd(dev, AX88172_CMD_READ_NODE_ID,
- 0, 0, 6, buf)) < 0) {
+ 0, 0, ETH_ALEN, buf)) < 0) {
dbg("read AX_CMD_READ_NODE_ID failed: %d", ret);
goto out2;
}
@@ -909,7 +925,7 @@ static int ax88772_bind(struct usbnet *d
usbnet_get_endpoints(dev,intf);
- buf = kmalloc(6, GFP_KERNEL);
+ buf = kmalloc(ETH_ALEN, GFP_KERNEL);
if(!buf) {
dbg ("Cannot allocate memory for buffer");
ret = -ENOMEM;
@@ -923,7 +939,7 @@ static int ax88772_bind(struct usbnet *d
/* 0x10 is the phy id of the embedded 10/100 ethernet phy */
embd_phy = ((asix_get_phy_addr(dev) & 0x1f) == 0x10 ? 1 : 0);
if ((ret = asix_write_cmd(dev, AX_CMD_SW_PHY_SELECT,
- embd_phy, 0, 0, buf)) < 0) {
+ embd_phy, 0, 0, NULL)) < 0) {
dbg("Select PHY #1 failed: %d", ret);
goto out2;
}
@@ -998,7 +1014,7 @@ static int ax88772_bind(struct usbnet *d
if ((ret = asix_write_cmd(dev, AX_CMD_WRITE_IPG0,
AX88772_IPG0_DEFAULT | AX88772_IPG1_DEFAULT,
- AX88772_IPG2_DEFAULT, 0, buf)) < 0) {
+ AX88772_IPG2_DEFAULT, 0, NULL)) < 0) {
dbg("Write IPG,IPG1,IPG2 failed: %d", ret);
goto out2;
}
@@ -1202,20 +1218,22 @@ static int ax88178_bind(struct usbnet *d
usbnet_get_endpoints(dev,intf);
- buf = kmalloc(6, GFP_KERNEL);
+ buf = kmalloc(ETH_ALEN, GFP_KERNEL);
if(!buf) {
dbg ("Cannot allocate memory for buffer");
ret = -ENOMEM;
goto out1;
}
- eeprom = 0;
- asix_read_cmd(dev, AX_CMD_READ_GPIOS, 0, 0, 1, &eeprom);
+ memset(buf, 0, ETH_ALEN);
+ asix_read_cmd(dev, AX_CMD_READ_GPIOS, 0, 0, 1, buf);
+ eeprom = *(u8 *)buf;
dbg("GPIO Status: 0x%04x", eeprom);
asix_write_cmd(dev, AX_CMD_WRITE_ENABLE, 0, 0, 0, NULL);
- asix_read_cmd(dev, AX_CMD_READ_EEPROM, 0x0017, 0, 2, &eeprom);
+ asix_read_cmd(dev, AX_CMD_READ_EEPROM, 0x0017, 0, 2, buf);
asix_write_cmd(dev, AX_CMD_WRITE_DISABLE, 0, 0, 0, NULL);
+ eeprom = *(u16 *)buf;
dbg("EEPROM index 0x17 is 0x%04x", eeprom);
-------------------------------------------------------------------------
This SF.net email is sponsored by: Splunk Inc.
Still grepping through log files to find problems? Stop.
Now Search log events and configuration files using AJAX and a browser.
Download your FREE copy of Splunk now >> http://get.splunk.com/
_______________________________________________
linux-usb-devel@lists.sourceforge.net
To unsubscribe, use the last form field at:
https://lists.sourceforge.net/lists/listinfo/linux-usb-devel
^ permalink raw reply
* Re: [BUG] 2.6.23-git19 - S390x: Kernel panic while bringing up the network interface
From: Kamalesh Babulal @ 2007-10-24 10:55 UTC (permalink / raw)
To: Heiko Carstens; +Cc: linux390, linux-s390, netdev, linux-kernel, Andy Whitcroft
In-Reply-To: <20071024050633.GA12335@osiris.boeblingen.de.ibm.com>
Heiko Carstens wrote:
> On Wed, Oct 24, 2007 at 08:59:06AM +0530, Kamalesh Babulal wrote:
>> Hi,
>>
>> Kernel panic's while bringing up the network interface with the 2.6.23-git19
>>
>> Setting network parameters: Ý OK ¨
>> Bringing up loopback interface: Ý OK ¨
>> Bringing up interface eth0:
>> Ý<00000000002e2f72>¨ inet_ioctl+0xd6/0x110
>> Ý<000000000027cae2>¨ sock_ioctl+0x26e/0x2a0
>> Ý<00000000000b4c52>¨ do_ioctl+0x4a/0xac
>> Ý<00000000000b5076>¨ vfs_ioctl+0x3c2/0x3d8
>> Ý<00000000000b50ec>¨ sys_ioctl+0x60/0x88
>> Ý<0000000000021b7e>¨ sysc_noemu+0x10/0x16
>> Ý<00000200001201ca>¨ 0x200001201ca
>>
>> <0>Kernel panic - not syncing: Fatal exception in interrupt
>> 00: HCPGSP2629I The virtual machine is placed in CP mode due to a SIGP stop from
>> CPU 01.
>> 02: HCPGSP2629I The virtual machine is placed in CP mode due to a SIGP stop from
>> CPU 01.
>> 03: HCPGSP2629I The virtual machine is placed in CP mode due to a SIGP stop from
>> CPU 01.
>> 01: HCPGIR450W CP entered; disabled wait PSW 00020001 80000000 00000000 000164DE
>
> That should be fixed with this one:
>
> commit f1ecfd5d3b69d98b814435758c485e6fd0e112de
> Author: Ursula Braun <braunu@de.ibm.com>
> Date: Mon Oct 22 16:16:14 2007 +0200
>
> remove header_ops bug in qeth driver
>
> Remove qeth bug caused by commit:
> [NET]: Move hardware header operations out of netdevice.
>
> This is the second part of the qeth header_ops patch, since
> first patch sent 10/19 has been insufficient.
> Nevertheless first patch is still valid and should be kept.
>
> Signed-off-by: Ursula Braun <braunu@de.ibm.com>
> Signed-off-by: Jeff Garzik <jeff@garzik.org>
>
> Patch is in -rc1. Could you please pull and try again? Thanks.
Hi,
The kernel panic is not seen in the 2.6.24-rc1 kernel.
--
Thanks & Regards,
Kamalesh Babulal,
Linux Technology Center,
IBM, ISTL.
^ permalink raw reply
* Re: [PATCH RESEND] ip_gre: sendto/recvfrom NBMA address
From: Alexey Kuznetsov @ 2007-10-24 10:08 UTC (permalink / raw)
To: Timo Ter?s; +Cc: Patrick McHardy, davem, netdev
In-Reply-To: <471EDE22.4090408@iki.fi>
Hello!
> I was able to set a nbma gre tunnel, add routes to it and it worked
> perfectly ok.
>
> Link-level next hop worked:
> ip route add <route> via <link-level-address> dev <tunnel-dev> onlink
This can work if you use gre0. By plain luck it has all-zero dev_addr.
It will break on nbma devices set with:
ip tunnel add XXX mode gre local a.b.c.d [key whatever] ...
Alexey
^ permalink raw reply
* Re: [PATCH 13/13] r8169: more phy init for the 8168
From: Glen Gray @ 2007-10-24 9:29 UTC (permalink / raw)
To: Francois Romieu; +Cc: jgarzik, netdev, Edward Hsu
In-Reply-To: <20071018210224.GN31724@electric-eye.fr.zoreil.com>
Are any of these likely to fix the Ethernet multicast issues a few of us
have seen with 8110sc cards ?
Francois Romieu wrote:
> Realtek's r8168 driver version 8.003.00 adds new init sequences
> (they do not appear in version 8.002.00).
>
> Signed-off-by: Francois Romieu <romieu@fr.zoreil.com>
> Cc: Edward Hsu <edward_hsu@realtek.com.tw>
> ---
> drivers/net/r8169.c | 34 ++++++++++++++++++++++++++++++++++
> 1 files changed, 34 insertions(+), 0 deletions(-)
>
> diff --git a/drivers/net/r8169.c b/drivers/net/r8169.c
> index 8ffd573..e8960f2 100644
> --- a/drivers/net/r8169.c
> +++ b/drivers/net/r8169.c
> @@ -1243,6 +1243,16 @@ static void rtl8169sb_hw_phy_config(void __iomem *ioaddr)
>
> rtl_phy_write(ioaddr, phy_reg_init, ARRAY_SIZE(phy_reg_init));
> }
> +static void rtl8168b_hw_phy_config(void __iomem *ioaddr)
> +{
> + struct phy_reg phy_reg_init[] = {
> + { 0x1f, 0x0000 },
> + { 0x10, 0xf41b },
> + { 0x1f, 0x0000 }
> + };
> +
> + rtl_phy_write(ioaddr, phy_reg_init, ARRAY_SIZE(phy_reg_init));
> +}
>
> static void rtl8168cp_hw_phy_config(void __iomem *ioaddr)
> {
> @@ -1279,6 +1289,22 @@ static void rtl8168c_hw_phy_config(void __iomem *ioaddr)
> rtl_phy_write(ioaddr, phy_reg_init, ARRAY_SIZE(phy_reg_init));
> }
>
> +static void rtl8168cx_hw_phy_config(void __iomem *ioaddr)
> +{
> + struct phy_reg phy_reg_init[] = {
> + { 0x1f, 0x0000 },
> + { 0x12, 0x2300 },
> + { 0x1f, 0x0003 },
> + { 0x16, 0x0f0a },
> + { 0x1f, 0x0000 },
> + { 0x1f, 0x0002 },
> + { 0x0c, 0x7eb8 },
> + { 0x1f, 0x0000 }
> + };
> +
> + rtl_phy_write(ioaddr, phy_reg_init, ARRAY_SIZE(phy_reg_init));
> +}
> +
> static void rtl_hw_phy_config(struct net_device *dev)
> {
> struct rtl8169_private *tp = netdev_priv(dev);
> @@ -1296,12 +1322,20 @@ static void rtl_hw_phy_config(struct net_device *dev)
> case RTL_GIGA_MAC_VER_04:
> rtl8169sb_hw_phy_config(ioaddr);
> break;
> + case RTL_GIGA_MAC_VER_11:
> + case RTL_GIGA_MAC_VER_12:
> + case RTL_GIGA_MAC_VER_17:
> + rtl8168b_hw_phy_config(ioaddr);
> + break;
> case RTL_GIGA_MAC_VER_18:
> rtl8168cp_hw_phy_config(ioaddr);
> break;
> case RTL_GIGA_MAC_VER_19:
> rtl8168c_hw_phy_config(ioaddr);
> break;
> + case RTL_GIGA_MAC_VER_20:
> + rtl8168cx_hw_phy_config(ioaddr);
> + break;
> default:
> break;
> }
>
--
Glen Gray <glen@lincor.com> Digital Depot, Thomas Street
Senior Software Engineer Dublin 8, Ireland
Lincor Solutions Ltd. Ph: +353 (0) 1 4893682
^ permalink raw reply
* Re: on the topic of alternate MAC addresses
From: Johannes Berg @ 2007-10-24 9:28 UTC (permalink / raw)
To: David Miller; +Cc: jeff, netdev
In-Reply-To: <20071023.202210.74747025.davem@davemloft.net>
[-- Attachment #1: Type: text/plain, Size: 1234 bytes --]
On Tue, 2007-10-23 at 20:22 -0700, David Miller wrote:
> However, it's not the virt clients that do this, it's the control
> node (aka: domain 0) which has to manage these things.
>
> It has to manage all of the global hardware resources and allocate
> them out to itself and the clients anyways.
>
> And this is why I think it's sufficient to just publish the list of
> MAC addresses from the driver, and leave the allocation and policy
> to the userland virtualizatin daemon running on the control node.
From a wireless angle, however, it's not sufficient. It appears that
there are some wireless cards that have multiple MAC addresses in their
EEPROM (or a way to generate multiple, by e.g. the vendor assigning only
even addresses and reserving odd ones). Then, bringing up a second,
third, ... virtual wireless interface should for best usability choose
an alternate address if the same one cannot be used due to restrictions.
We can probably manage this issue in userspace, in fact, for AP mode we
require proper configuration in hostapd, but it seems that some sort of
reservation system would be easier for multiple virtual station
interfaces when supported (currently no driver does).
johannes
[-- Attachment #2: This is a digitally signed message part --]
[-- Type: application/pgp-signature, Size: 828 bytes --]
^ permalink raw reply
* Re: [PATCH 0/5] Diet struct net_device a bit
From: Johannes Berg @ 2007-10-23 17:07 UTC (permalink / raw)
To: Pavel Emelyanov; +Cc: David Miller, Linux Netdev List, devel
In-Reply-To: <471C9830.5070407@openvz.org>
[-- Attachment #1: Type: text/plain, Size: 253 bytes --]
On Mon, 2007-10-22 at 16:31 +0400, Pavel Emelyanov wrote:
> * ieee80211_ptr is used in many wireless drivers. Need time
> to check for the config dependencies.
Depending on CFG80211 should be fine, if not that's a bug elsewhere.
johannes
[-- Attachment #2: This is a digitally signed message part --]
[-- Type: application/pgp-signature, Size: 828 bytes --]
^ permalink raw reply
* Re: [PATCH RESEND] ip_gre: sendto/recvfrom NBMA address
From: Timo Teräs @ 2007-10-24 5:54 UTC (permalink / raw)
To: Alexey Kuznetsov; +Cc: Patrick McHardy, davem, netdev
In-Reply-To: <20071023202036.GA12066@ms2.inr.ac.ru>
Hi,
Alexey Kuznetsov wrote:
>> The only dubious case is when next hop is set using routing tables.
>> But code in ipgre_tunnel_xmit() is ready to accept this situation,
>> it checks for zero destination address and fixes it when it is able to.
>
> Nevertheless, it does not work.
>
> Another thoughts?
Could you explain this a little more?
I was able to set a nbma gre tunnel, add routes to it and it worked
perfectly ok.
Link-level next hop worked:
ip route add <route> via <link-level-address> dev <tunnel-dev> onlink
Also normal route with static neighbor worked:
ip neigh add <router-tunnel-ip> lladdr <link-level-address> nud permanent dev <tunnel-dev>
ip route add <route> via <router-tunnel-ip>
In both cases packets were routed as expected to hosts accessible using
the added route. And sendto() sent a packet correctly with destination
link-level-address set. Did I miss/misunderstand something?
Cheers,
Timo
^ permalink raw reply
* Re: [PATCH] Add eeprom_bad_csum_allow module option to e1000.
From: Dave Jones @ 2007-10-24 5:38 UTC (permalink / raw)
To: Kok, Auke; +Cc: Jeff Garzik, Adam Jackson, linux-kernel, David Miller, netdev
In-Reply-To: <471E7DCA.9030700@intel.com>
On Tue, Oct 23, 2007 at 04:03:38PM -0700, Kok, Auke wrote:
> Dave Jones wrote:
> > On Tue, Oct 23, 2007 at 04:40:01PM -0400, Jeff Garzik wrote:
> >
> > > > In any case, this patch should not be merged. We often send it around to users to
> > > > debug their issue in case it involves eeproms, but merging it will just conceal
> > > > the real issue and all of a sudden a flood of people stop reporting *real* issues
> > > > to us.
> > >
> > > Sorry, I disagree. Just as with e100, if there is a clear way the user
> > > can recover their setup -- and Adam says his was effective -- I don't
> > > see why we should be denying users the ability to use their own hardware.
> >
> > Indeed. This is a common enough problem that not including it causes more pain
> > than its worth. I have two affected boxes myself that I actually thought
> > the hardware was dead before I tried ajax's patch.
>
>
> look: You should have reported this to us and you didn't. Now you are using the
> fact that you did not report it as an argument which is out of place.
you're missing the point. It looks like a hardware failure. Why would I report this?
> why do you say it is common? how often have you seen this and not reported it back
> to our support? are you willingly trying to frustrate this issue?
Not at all. The only frustration here is that I used to have a kernel that
worked, upgraded, and thought that my hardware was broken.
How many other users thought the same ?
Dave
--
http://www.codemonkey.org.uk
^ permalink raw reply
* Re: [BUG] 2.6.23-git19 - S390x: Kernel panic while bringing up the network interface
From: Heiko Carstens @ 2007-10-24 5:06 UTC (permalink / raw)
To: Kamalesh Babulal
Cc: linux390, linux-s390, netdev, linux-kernel, Andy Whitcroft
In-Reply-To: <471EBC02.5000907@linux.vnet.ibm.com>
On Wed, Oct 24, 2007 at 08:59:06AM +0530, Kamalesh Babulal wrote:
> Hi,
>
> Kernel panic's while bringing up the network interface with the 2.6.23-git19
>
> Setting network parameters: Ý OK ¨
> Bringing up loopback interface: Ý OK ¨
> Bringing up interface eth0:
> Ý<00000000002e2f72>¨ inet_ioctl+0xd6/0x110
> Ý<000000000027cae2>¨ sock_ioctl+0x26e/0x2a0
> Ý<00000000000b4c52>¨ do_ioctl+0x4a/0xac
> Ý<00000000000b5076>¨ vfs_ioctl+0x3c2/0x3d8
> Ý<00000000000b50ec>¨ sys_ioctl+0x60/0x88
> Ý<0000000000021b7e>¨ sysc_noemu+0x10/0x16
> Ý<00000200001201ca>¨ 0x200001201ca
>
> <0>Kernel panic - not syncing: Fatal exception in interrupt
> 00: HCPGSP2629I The virtual machine is placed in CP mode due to a SIGP stop from
> CPU 01.
> 02: HCPGSP2629I The virtual machine is placed in CP mode due to a SIGP stop from
> CPU 01.
> 03: HCPGSP2629I The virtual machine is placed in CP mode due to a SIGP stop from
> CPU 01.
> 01: HCPGIR450W CP entered; disabled wait PSW 00020001 80000000 00000000 000164DE
That should be fixed with this one:
commit f1ecfd5d3b69d98b814435758c485e6fd0e112de
Author: Ursula Braun <braunu@de.ibm.com>
Date: Mon Oct 22 16:16:14 2007 +0200
remove header_ops bug in qeth driver
Remove qeth bug caused by commit:
[NET]: Move hardware header operations out of netdevice.
This is the second part of the qeth header_ops patch, since
first patch sent 10/19 has been insufficient.
Nevertheless first patch is still valid and should be kept.
Signed-off-by: Ursula Braun <braunu@de.ibm.com>
Signed-off-by: Jeff Garzik <jeff@garzik.org>
Patch is in -rc1. Could you please pull and try again? Thanks.
^ permalink raw reply
* Re: [PATCH] Cleanup the IPv6 addresses printing in /proc files
From: David Miller @ 2007-10-24 4:18 UTC (permalink / raw)
To: joe; +Cc: xemul, netdev, devel
In-Reply-To: <1193199336.11845.53.camel@localhost>
From: Joe Perches <joe@perches.com>
Date: Tue, 23 Oct 2007 21:15:36 -0700
> On Tue, 2007-10-23 at 21:10 -0700, David Miller wrote:
> > We'll break things if we change it.
>
> Maybe, but definitely the macro names should
> reflect this brokenness.
That's a good point, we don't want to encourage further
use of these things.
Pavel, I'm going to revert this patch for now. It may
save some code lines, but it does so at the expense of
creating an interface we actually don't want more users
of.
^ permalink raw reply
* Re: [PATCH] Explicitly call fib_get_table() in fib_frontend.c
From: David Miller @ 2007-10-24 4:17 UTC (permalink / raw)
To: xemul; +Cc: netdev, devel
In-Reply-To: <471CC814.9040002@openvz.org>
From: Pavel Emelyanov <xemul@openvz.org>
Date: Mon, 22 Oct 2007 19:56:04 +0400
> In case the "multiple tables" config option is y, the ip_fib_local_table
> is not a variable, but a macro, that calls fib_get_table(RT_TABLE_LOCAL).
>
> Some code uses this "variable" *3* times in one place, thus implicitly
> making 3 calls. Fix it.
>
> Signed-off-by: Pavel Emelyanov <xemul@openvz.org>
Good catch, applied.
^ permalink raw reply
* Re: [PATCH 3/3] Use BUILD_BUG_ON in net/core/flowi.c
From: David Miller @ 2007-10-24 4:15 UTC (permalink / raw)
To: xemul; +Cc: netdev, devel
In-Reply-To: <471CC196.50607@openvz.org>
From: Pavel Emelyanov <xemul@openvz.org>
Date: Mon, 22 Oct 2007 19:28:22 +0400
> Instead of ugly extern not-existing function.
I can take credit for this turd. Hey, it was the accepted way to do
compile time assertions at the time :-)
> Signed-off-by: Pavel Emelyanov <xemul@openvz.org>
Applied!
^ permalink raw reply
* Re: [PATCH] Cleanup the IPv6 addresses printing in /proc files
From: Joe Perches @ 2007-10-24 4:15 UTC (permalink / raw)
To: David Miller; +Cc: xemul, netdev, devel
In-Reply-To: <20071023.211045.23014439.davem@davemloft.net>
On Tue, 2007-10-23 at 21:10 -0700, David Miller wrote:
> We'll break things if we change it.
Maybe, but definitely the macro names should
reflect this brokenness.
^ permalink raw reply
* Re: [PATCH 2/3] Remove in-code externs for some functions from net/core/dev.c
From: David Miller @ 2007-10-24 4:14 UTC (permalink / raw)
To: xemul; +Cc: netdev, devel
In-Reply-To: <471CC0FE.9030602@openvz.org>
From: Pavel Emelyanov <xemul@openvz.org>
Date: Mon, 22 Oct 2007 19:25:50 +0400
> Inconsistent prototype and real type for functions may have
> worse consequences, than those for variables, so move them
> into a header.
>
> Since they are used privately in net/core, make this file
> reside in the same place.
>
> Signed-off-by: Pavel Emelyanov <xemul@openvz.org>
Applied, thanks.
^ permalink raw reply
* Re: [PATCH 1/3] Don't declare extern variables in net/core/sysctl_net_core.c
From: David Miller @ 2007-10-24 4:14 UTC (permalink / raw)
To: xemul; +Cc: netdev, devel
In-Reply-To: <471CC043.5060301@openvz.org>
From: Pavel Emelyanov <xemul@openvz.org>
Date: Mon, 22 Oct 2007 19:22:43 +0400
> Some are already declared in include/linux/netdevice.h, while
> some others (xfrm ones) need to be declared.
>
> The driver/net/rrunner.c just uses same extern as well, so
> cleanup it also.
>
> Signed-off-by: Pavel Emelyanov <xemul@openvz.org>
Applied, thanks!
^ permalink raw reply
* Re: [PATCH] Cleanup the IPv6 addresses printing in /proc files
From: David Miller @ 2007-10-24 4:10 UTC (permalink / raw)
To: joe; +Cc: xemul, netdev, devel
In-Reply-To: <1193198641.11845.49.camel@localhost>
From: Joe Perches <joe@perches.com>
Date: Tue, 23 Oct 2007 21:04:01 -0700
> On Tue, 2007-10-23 at 20:43 -0700, David Miller wrote:
> > From: Pavel Emelyanov <xemul@openvz.org>
> > Date: Tue, 23 Oct 2007 20:37:22 +0400
> > > The /proc/net udp6, tcp6 and raw6 files print the IPs of
> > > the connection ends. Make a NIP6Lxxx macros (L stands for
> > > "long") for making the printing code look nicer.
> > > Signed-off-by: Pavel Emelyanov <xemul@openvz.org>
> > Applied, thanks.
>
> Why aren't these addresses converted with ntohl?
The reason is immaterial because whatever the kernel is doing
now we have to keep doing because applications parsing these
/proc files expect things to be how they are.
We'll break things if we change it.
^ permalink raw reply
* Re: [PATCH] Cleanup the IPv6 addresses printing in /proc files
From: Joe Perches @ 2007-10-24 4:04 UTC (permalink / raw)
To: David Miller; +Cc: xemul, netdev, devel
In-Reply-To: <20071023.204350.59654390.davem@davemloft.net>
On Tue, 2007-10-23 at 20:43 -0700, David Miller wrote:
> From: Pavel Emelyanov <xemul@openvz.org>
> Date: Tue, 23 Oct 2007 20:37:22 +0400
> > The /proc/net udp6, tcp6 and raw6 files print the IPs of
> > the connection ends. Make a NIP6Lxxx macros (L stands for
> > "long") for making the printing code look nicer.
> > Signed-off-by: Pavel Emelyanov <xemul@openvz.org>
> Applied, thanks.
Why aren't these addresses converted with ntohl?
^ permalink raw reply
* Re: [RFC][PATCH 0/3][XFRM]: Support packet processing error statistics.
From: YOSHIFUJI Hideaki / 吉藤英明 @ 2007-10-24 3:59 UTC (permalink / raw)
To: nakam; +Cc: hadi, herbert, davem, netdev, yoshfuji
In-Reply-To: <200710231608.34661.nakam@linux-ipv6.org>
In article <200710231608.34661.nakam@linux-ipv6.org> (at Tue, 23 Oct 2007 16:08:34 +0900), Masahide NAKAMURA <nakam@linux-ipv6.org> says:
> Monday 22 October 2007 21:28, jamal wrote:
> > On Mon, 2007-22-10 at 15:11 +0900, Masahide NAKAMURA wrote:
:
> This point is one of what I want to hear comment.
> My patch uses "XFRM_MIB_XXX" because I found "LINUX_MIB_XXX" definition at
> include/linux/snmp.h for TCP extended statistics at /proc/net/netstat and
> it does not seem to be defined by any RFC specification. Then I feel it is not so bad to
> use _MIB_ for them. Maybe we have another idea to merge them into LINUX_MIB.
>
> Now we have the following candidates:
>
> (1) my patch XFRM_MIB_INHDRERROR
> (2) some extender XFRM_XXX_INHDRERROR (XXX is requested)
> (3) not-mib extender XFRM_NOTMIB_INHDRERROR
> (4) no extender XFRM_INHDRERROR
> (5) merge linux-mib LINUX_MIB_XFRMINHDRERROR
>
> Comments?
I would support (5) or (1).
--yoshfuji
^ permalink raw reply
* Re: sch_prio.c vs CONFIG_NETDEVICES_MULTIQUEUE
From: David Miller @ 2007-10-24 3:51 UTC (permalink / raw)
To: xemul; +Cc: kaber, adobriyan, netdev, peter.p.waskiewicz.jr
In-Reply-To: <471DF0A4.4080504@openvz.org>
From: Pavel Emelyanov <xemul@openvz.org>
Date: Tue, 23 Oct 2007 17:01:24 +0400
> Fix more users of netiff_subqueue_stopped. To check for the
> queue id one must use the __netiff_subqueue_stoped call.
>
> These run out of my sight when I made the
> 668f895a85b0c3a62a690425145f13dabebebd7a commit :(
>
> Signed-off-by: Pavel Emelyanov <xemul@openvz.org>
Applied, thanks Pavel.
^ permalink raw reply
* Re: [PATCH] Cleanup the IPv6 addresses printing in /proc files
From: David Miller @ 2007-10-24 3:43 UTC (permalink / raw)
To: xemul; +Cc: netdev, devel
In-Reply-To: <471E2342.8090907@openvz.org>
From: Pavel Emelyanov <xemul@openvz.org>
Date: Tue, 23 Oct 2007 20:37:22 +0400
> The /proc/net udp6, tcp6 and raw6 files print the IPs of
> the connection ends. Make a NIP6Lxxx macros (L stands for
> "long") for making the printing code look nicer.
>
> Signed-off-by: Pavel Emelyanov <xemul@openvz.org>
Applied, thanks.
^ permalink raw reply
* Re: [PATCH] PowerPC: Add BCM5248 and Marvell 88E1111 PHY support to NEW EMAC.
From: Benjamin Herrenschmidt @ 2007-10-24 3:31 UTC (permalink / raw)
To: Valentine Barshak; +Cc: linuxppc-dev, netdev, jwboyer, jeff
In-Reply-To: <20071015175717.GA4602@ru.mvista.com>
On Tue, 2007-10-23 at 20:57 -0500, Valentine Barshak wrote:
> +static int m88e1111_init(struct mii_phy *phy)
> +{
> + printk("%s: Marvell 88E1111 Ethernet\n", __FUNCTION__);
> + phy_write(phy, 0x14, 0x0ce3);
> + phy_write(phy, 0x18, 0x4101);
> + phy_write(phy, 0x09, 0x0e00);
> + phy_write(phy, 0x04, 0x01e1);
> + phy_write(phy, 0x00, 0x9140);
> + phy_write(phy, 0x00, 0x1140);
> +
> + return 0;
> +}
Care to put a few comments on why the above is necessary and what it
does ?
Thanks !
Ben.
> +static struct mii_phy_ops m88e1111_phy_ops = {
> + .init = m88e1111_init,
> + .setup_aneg = genmii_setup_aneg,
> + .setup_forced = genmii_setup_forced,
> + .poll_link = genmii_poll_link,
> + .read_link = genmii_read_link
> +};
> +
> +static struct mii_phy_def m88e1111_phy_def = {
> +
> + .phy_id = 0x01410CC0,
> + .phy_id_mask = 0x0ffffff0,
> + .name = "Marvell 88E1111 Ethernet",
> + .ops = &m88e1111_phy_ops,
> +};
> +
> static struct mii_phy_def *mii_phy_table[] = {
> &cis8201_phy_def,
> + &bcm5248_phy_def,
> + &m88e1111_phy_def,
> &genmii_phy_def,
> NULL
> };
^ permalink raw reply
* Re: [PATCH RESEND] ip_gre: sendto/recvfrom NBMA address
From: David Miller @ 2007-10-24 3:32 UTC (permalink / raw)
To: kuznet; +Cc: timo.teras, kaber, netdev
In-Reply-To: <20071023190324.GA1267@ms2.inr.ac.ru>
From: Alexey Kuznetsov <kuznet@ms2.inr.ac.ru>
Date: Tue, 23 Oct 2007 23:03:24 +0400
> Hello!
>
> > When GRE tunnel is in NBMA mode, this patch allows an application to use
> > a PF_PACKET socket to:
> > - send a packet to specific NBMA address with sendto()
> > - use recvfrom() to receive packet and check which NBMA address it came from
> >
> > This is required to implement properly NHRP over GRE tunnel.
>
> Ack. This is good idea.
Patch applied, thanks everyone!
^ permalink raw reply
* [BUG] 2.6.23-git19 - S390x: Kernel panic while bringing up the network interface
From: Kamalesh Babulal @ 2007-10-24 3:29 UTC (permalink / raw)
To: linux390; +Cc: linux-s390, netdev, linux-kernel, Andy Whitcroft
Hi,
Kernel panic's while bringing up the network interface with the 2.6.23-git19
Setting network parameters: Ý OK ¨
Bringing up loopback interface: Ý OK ¨
Bringing up interface eth0:
Ý<00000000002e2f72>¨ inet_ioctl+0xd6/0x110
Ý<000000000027cae2>¨ sock_ioctl+0x26e/0x2a0
Ý<00000000000b4c52>¨ do_ioctl+0x4a/0xac
Ý<00000000000b5076>¨ vfs_ioctl+0x3c2/0x3d8
Ý<00000000000b50ec>¨ sys_ioctl+0x60/0x88
Ý<0000000000021b7e>¨ sysc_noemu+0x10/0x16
Ý<00000200001201ca>¨ 0x200001201ca
<0>Kernel panic - not syncing: Fatal exception in interrupt
00: HCPGSP2629I The virtual machine is placed in CP mode due to a SIGP stop from
CPU 01.
02: HCPGSP2629I The virtual machine is placed in CP mode due to a SIGP stop from
CPU 01.
03: HCPGSP2629I The virtual machine is placed in CP mode due to a SIGP stop from
CPU 01.
01: HCPGIR450W CP entered; disabled wait PSW 00020001 80000000 00000000 000164DE
--
Thanks & Regards,
Kamalesh Babulal,
Linux Technology Center,
IBM, ISTL.
^ 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