* Re: [PATCH 4/6] myri10ge - First half of the driver
From: Francois Romieu @ 2006-05-10 23:13 UTC (permalink / raw)
To: Brice Goglin; +Cc: netdev, Andrew Morton, LKML, Andrew J. Gallatin, brice
In-Reply-To: <Pine.GSO.4.44.0605101438410.498-100000@adel.myri.com>
Brice Goglin <bgoglin@myri.com> :
> [PATCH 4/6] myri10ge - First half of the driver
>
> The first half of the myri10ge driver core.
>
> Signed-off-by: Brice Goglin <brice@myri.com>
> Signed-off-by: Andrew J. Gallatin <gallatin@myri.com>
>
> myri10ge.c | 1483 +++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++
> 1 file changed, 1483 insertions(+)
>
> --- /dev/null 2006-05-09 19:43:19.324446250 +0200
> +++ linux/drivers/net/myri10ge/myri10ge.c 2006-05-09 23:00:55.000000000 +0200
[...]
> +module_param(myri10ge_flow_control, int, S_IRUGO);
> +module_param(myri10ge_deassert_wait, int, S_IRUGO | S_IWUSR);
> +module_param(myri10ge_force_firmware, int, S_IRUGO);
> +module_param(myri10ge_skb_cross_4k, int, S_IRUGO | S_IWUSR);
> +module_param(myri10ge_initial_mtu, int, S_IRUGO);
> +module_param(myri10ge_napi, int, S_IRUGO);
> +module_param(myri10ge_napi_weight, int, S_IRUGO);
> +module_param(myri10ge_watchdog_timeout, int, S_IRUGO);
> +module_param(myri10ge_max_irq_loops, int, S_IRUGO);
MODULE_PARM_DESC() would be nice.
> +
> +#define MYRI10GE_FW_OFFSET 1024*1024
> +#define MYRI10GE_HIGHPART_TO_U32(X) \
> +(sizeof (X) == 8) ? ((uint32_t)((uint64_t)(X) >> 32)) : (0)
> +#define MYRI10GE_LOWPART_TO_U32(X) ((uint32_t)(X))
> +
> +#define myri10ge_pio_copy(to,from,size) __iowrite64_copy(to,from,size/8)
> +
> +int myri10ge_hyper_msi_cap_on(struct pci_dev *pdev)
static int ?
[...]
> +static int
> +myri10ge_send_cmd(struct myri10ge_priv *mgp, uint32_t cmd,
> + myri10ge_cmd_t *data)
> +{
> + mcp_cmd_t *buf;
> + char buf_bytes[sizeof(*buf) + 8];
> + volatile mcp_cmd_response_t *response = mgp->cmd;
> + volatile char __iomem *cmd_addr = mgp->sram + MYRI10GE_MCP_CMD_OFFSET;
> + uint32_t dma_low, dma_high;
> + int sleep_total = 0;
> +
> + /* ensure buf is aligned to 8 bytes */
> + buf = (mcp_cmd_t *) ((unsigned long)(buf_bytes + 7) & ~7UL);
> +
> + buf->data0 = htonl(data->data0);
> + buf->data1 = htonl(data->data1);
> + buf->data2 = htonl(data->data2);
> + buf->cmd = htonl(cmd);
> + dma_low = MYRI10GE_LOWPART_TO_U32(mgp->cmd_bus);
> + dma_high = MYRI10GE_HIGHPART_TO_U32(mgp->cmd_bus);
> +
> + buf->response_addr.low = htonl(dma_low);
> + buf->response_addr.high = htonl(dma_high);
> + spin_lock(&mgp->cmd_lock);
> + response->result = 0xffffffff;
> + mb();
> + myri10ge_pio_copy((void __iomem *) cmd_addr, buf, sizeof (*buf));
> +
> + /* wait up to 2 seconds */
You must not hold a spinlock for up to 2 seconds.
> + for (sleep_total = 0; sleep_total < (2 * 1000); sleep_total += 10) {
> + mb();
> + if (response->result != 0xffffffff) {
> + if (response->result == 0) {
> + data->data0 = ntohl(response->data);
> + spin_unlock(&mgp->cmd_lock);
> + return 0;
> + } else {
> + dev_err(&mgp->pdev->dev,
> + "command %d failed, result = %d\n",
> + cmd, ntohl(response->result));
> + spin_unlock(&mgp->cmd_lock);
> + return -ENXIO;
Return in a middle of a spinlock-intensive function. :o(
> + }
> + }
> + udelay(1000 * 10);
> + }
> + spin_unlock(&mgp->cmd_lock);
> + dev_err(&mgp->pdev->dev, "command %d timed out, result = %d\n",
> + cmd, ntohl(response->result));
> + return -EAGAIN;
> +}
> +
> +
> +/*
> + * The eeprom strings on the lanaiX have the format
> + * SN=x\0
> + * MAC=x:x:x:x:x:x\0
> + * PT:ddd mmm xx xx:xx:xx xx\0
> + * PV:ddd mmm xx xx:xx:xx xx\0
> + */
> +int
> +myri10ge_read_mac_addr(struct myri10ge_priv *mgp)
static int ?
[...]
> +static void
> +myri10ge_dummy_rdma(struct myri10ge_priv *mgp, int enable)
> +{
> + volatile uint32_t *confirm;
> + volatile char __iomem *submit;
> + uint32_t buf[16];
> + uint32_t dma_low, dma_high;
> + int i;
> +
> + /* clear confirmation addr */
> + confirm = (volatile uint32_t *) mgp->cmd;
> + *confirm = 0;
> + mb();
> +
> + /* send a rdma command to the PCIe engine, and wait for the
> + * response in the confirmation address. The firmware should
> + * write a -1 there to indicate it is alive and well
> + */
> + dma_low = MYRI10GE_LOWPART_TO_U32(mgp->cmd_bus);
> + dma_high = MYRI10GE_HIGHPART_TO_U32(mgp->cmd_bus);
> +
> + buf[0] = htonl(dma_high); /* confirm addr MSW */
> + buf[1] = htonl(dma_low); /* confirm addr LSW */
> + buf[2] = htonl(0xffffffff); /* confirm data */
> + buf[3] = htonl(dma_high); /* dummy addr MSW */
> + buf[4] = htonl(dma_low); /* dummy addr LSW */
> + buf[5] = htonl(enable); /* enable? */
> +
> + submit = mgp->sram + 0xfc01c0;
> +
> + myri10ge_pio_copy((void __iomem *) submit, &buf, sizeof (buf));
> + mb();
> + udelay(1000);
> + mb();
> + i = 0;
> + while (*confirm != 0xffffffff && i < 20) {
> + udelay(1000);
> + i++;
> + }
for (i = 0; *confirm != 0xffffffff && i < 20; i++)
udelay(1000);
[...]
> +static int
> +myri10ge_adopt_running_firmware(struct myri10ge_priv *mgp)
> +{
> + mcp_gen_header_t *hdr;
> + struct device *dev = &mgp->pdev->dev;
> + size_t bytes, hdr_offset;
> + int status;
> +
> + /* find running firmware header */
> + hdr_offset = ntohl(__raw_readl(mgp->sram + MCP_HEADER_PTR_OFFSET));
> +
> + if ((hdr_offset & 3) || hdr_offset + sizeof(*hdr) > mgp->sram_size) {
> + dev_err(dev, "Running firmware has bad header offset (%d)\n",
> + (int)hdr_offset);
> + return -EIO;
> + }
> +
> + /* copy header of running firmware from SRAM to host memory to
> + * validate firmware */
> + bytes = sizeof (mcp_gen_header_t);
const size_t bytes = ...
> + hdr = (mcp_gen_header_t *) kmalloc(bytes, GFP_KERNEL);
Useless cast.
[...]
> +static int
> +myri10ge_change_pause(struct myri10ge_priv *mgp, int pause)
> +{
> + myri10ge_cmd_t cmd;
> + int status;
> +
> + if (pause)
> + status = myri10ge_send_cmd(mgp, MYRI10GE_MCP_ENABLE_FLOW_CONTROL, &cmd);
> + else
> + status = myri10ge_send_cmd(mgp, MYRI10GE_MCP_DISABLE_FLOW_CONTROL, &cmd);
ctl = pause ? MYRI10GE_MCP_ENABLE_FLOW_CONTROL :
MYRI10GE_MCP_DISABLE_FLOW_CONTROL;
status = myri10ge_send_cmd(mgp, ctl, ...)
> +
> + if (status) {
> + printk(KERN_ERR "myri10ge: %s: Failed to set flow control mode\n",
> + mgp->dev->name);
> + return -ENXIO;
Why not use the status code returned by myri10ge_send_cmd() ?
[...]
> +static int
> +myri10ge_reset(struct myri10ge_priv *mgp)
> +{
[...]
> + cmd.data0 = MYRI10GE_LOWPART_TO_U32(mgp->rx_done.bus);
> + cmd.data1 = MYRI10GE_HIGHPART_TO_U32(mgp->rx_done.bus);
> + cmd.data2 = len * 0x10001;
> + status |= myri10ge_send_cmd(mgp, MYRI10GE_MCP_DMA_TEST, &cmd);
The status code is not used.
> + mgp->read_write_dma = ((cmd.data0>>16) * len * 2 * 2) /
> + (cmd.data0 & 0xffff);
> +
> + memset(mgp->rx_done.entry, 0, bytes);
> +
> + /* reset mcp/driver shared state back to 0 */
> + mgp->tx.req = 0;
> + mgp->tx.done = 0;
> + mgp->tx.pkt_start = 0;
> + mgp->tx.pkt_done = 0;
> + mgp->rx_big.cnt = 0;
> + mgp->rx_small.cnt = 0;
> + mgp->rx_done.idx = 0;
> + mgp->rx_done.cnt = 0;
> + status = myri10ge_update_mac_address(mgp, mgp->dev->dev_addr);
> + myri10ge_change_promisc(mgp, 0);
> + myri10ge_change_pause(mgp, mgp->pause);
> + return status;
> +}
> +
> +static inline void
> +myri10ge_submit_8rx(mcp_kreq_ether_recv_t __iomem *dst, mcp_kreq_ether_recv_t *src)
> +{
> + uint32_t low;
> +
> + low = src->addr_low;
> + src->addr_low = 0xffffffff;
DMA_32BIT_MASK ?
> + myri10ge_pio_copy(dst, src, 8 * sizeof(*src));
> + mb();
> + src->addr_low = low;
> + *(uint32_t __force *) &dst->addr_low = src->addr_low;
> + mb();
> +}
> +
> +/*
> + * Set of routunes to get a new receive buffer. Any buffer which
> + * crosses a 4KB boundary must start on a 4KB boundary due to PCIe
> + * wdma restrictions. We also try to align any smaller allocation to
> + * at least a 16 byte boundary for efficiency. We assume the linux
> + * memory allocator works by powers of 2, and will not return memory
> + * smaller than 2KB which crosses a 4KB boundary. If it does, we fall
> + * back to allocating 2x as much space as required.
> + */
> +
> +static inline struct sk_buff *
> +myri10ge_alloc_big(int bytes)
It fits on a single line.
> +{
> + struct sk_buff *skb;
> + unsigned long data, roundup;
> +
> + skb = dev_alloc_skb(bytes + 4096 + MYRI10GE_MCP_ETHER_PAD);
> + if (skb == NULL)
> + return NULL;
Imho you will want to work directly with pages shortly.
[...]
> +static irqreturn_t
> +myri10ge_napi_intr(int irq, void *arg, struct pt_regs *regs)
> +{
> + struct myri10ge_priv *mgp = (struct myri10ge_priv *) arg;
Useless cast.
[...]
> +static int
> +myri10ge_set_settings(struct net_device *netdev, struct ethtool_cmd *cmd)
> +{
> + return -EINVAL;
> +}
Useless.
--
Ueimor
^ permalink raw reply
* Re: [PATCH] bonding: fix sparse warnings
From: Al Viro @ 2006-05-10 23:22 UTC (permalink / raw)
To: Stephen Hemminger; +Cc: ctindel, Jay Vosburgh, bonding-devel, netdev
In-Reply-To: <20060510161405.4ded4250@localhost.localdomain>
On Wed, May 10, 2006 at 04:14:05PM -0700, Stephen Hemminger wrote:
> Fix warning from sparse in bonding code about "incorrect type in assignment"
*snerk*
Only if you are building without -Wcast-to-as. It _is_ incorrect type in
assignment. And the real fix is to expand the call, killing set_fs()
in there.
^ permalink raw reply
* Re: [PATCH] dl2k: use explicit DMA_48BIT_MASK
From: Jon Mason @ 2006-05-10 23:52 UTC (permalink / raw)
To: Francois Romieu; +Cc: Daniel Walker, akpm, edward_peng, netdev, linux-kernel
In-Reply-To: <20060510185718.GA25334@electric-eye.fr.zoreil.com>
On Wed, May 10, 2006 at 08:57:18PM +0200, Francois Romieu wrote:
> Typo will be harder with this one.
While I agree that a #define is much better than the magic number, I
think this is bastardizing the intended use of DMA_*BIT_MASK.
DMA_*BIT_MASK is intended to be used in the DMA_API's checking of
DMA controller's addressable memory, where as this is masking off the
lower 48bits of a descriptor for its DMA address.
I think a better solution (which I should've done when I pushed the
original patch) would be a driver specific #define.
Thanks,
Jon
>
> Signed-off-by: Francois Romieu <romieu@fr.zoreil.com>
>
> ---
>
> drivers/net/dl2k.c | 13 ++++++-------
> include/linux/dma-mapping.h | 1 +
> 2 files changed, 7 insertions(+), 7 deletions(-)
>
> 5019a27a2a4e259f29a7bd03e905764eedfa034c
> diff --git a/drivers/net/dl2k.c b/drivers/net/dl2k.c
> index ca73f07..18d67cf 100644
> --- a/drivers/net/dl2k.c
> +++ b/drivers/net/dl2k.c
> @@ -765,8 +765,7 @@ rio_free_tx (struct net_device *dev, int
> break;
> skb = np->tx_skbuff[entry];
> pci_unmap_single (np->pdev,
> - np->tx_ring[entry].fraginfo &
> - 0xffffffffffffULL,
> + np->tx_ring[entry].fraginfo & DMA_48BIT_MASK,
> skb->len, PCI_DMA_TODEVICE);
> if (irq)
> dev_kfree_skb_irq (skb);
> @@ -895,7 +894,7 @@ receive_packet (struct net_device *dev)
> if (pkt_len > copy_thresh) {
> pci_unmap_single (np->pdev,
> desc->fraginfo &
> - 0xffffffffffffULL,
> + DMA_48BIT_MASK,
> np->rx_buf_sz,
> PCI_DMA_FROMDEVICE);
> skb_put (skb = np->rx_skbuff[entry], pkt_len);
> @@ -903,7 +902,7 @@ receive_packet (struct net_device *dev)
> } else if ((skb = dev_alloc_skb (pkt_len + 2)) != NULL) {
> pci_dma_sync_single_for_cpu(np->pdev,
> desc->fraginfo &
> - 0xffffffffffffULL,
> + DMA_48BIT_MASK,
> np->rx_buf_sz,
> PCI_DMA_FROMDEVICE);
> skb->dev = dev;
> @@ -915,7 +914,7 @@ receive_packet (struct net_device *dev)
> skb_put (skb, pkt_len);
> pci_dma_sync_single_for_device(np->pdev,
> desc->fraginfo &
> - 0xffffffffffffULL,
> + DMA_48BIT_MASK,
> np->rx_buf_sz,
> PCI_DMA_FROMDEVICE);
> }
> @@ -1803,7 +1802,7 @@ rio_close (struct net_device *dev)
> if (skb) {
> pci_unmap_single(np->pdev,
> np->rx_ring[i].fraginfo &
> - 0xffffffffffffULL,
> + DMA_48BIT_MASK,
> skb->len, PCI_DMA_FROMDEVICE);
> dev_kfree_skb (skb);
> np->rx_skbuff[i] = NULL;
> @@ -1814,7 +1813,7 @@ rio_close (struct net_device *dev)
> if (skb) {
> pci_unmap_single(np->pdev,
> np->tx_ring[i].fraginfo &
> - 0xffffffffffffULL,
> + DMA_48BIT_MASK,
> skb->len, PCI_DMA_TODEVICE);
> dev_kfree_skb (skb);
> np->tx_skbuff[i] = NULL;
> diff --git a/include/linux/dma-mapping.h b/include/linux/dma-mapping.h
> index ff61817..635690c 100644
> --- a/include/linux/dma-mapping.h
> +++ b/include/linux/dma-mapping.h
> @@ -14,6 +14,7 @@ enum dma_data_direction {
> };
>
> #define DMA_64BIT_MASK 0xffffffffffffffffULL
> +#define DMA_48BIT_MASK 0x0000ffffffffffffULL
> #define DMA_40BIT_MASK 0x000000ffffffffffULL
> #define DMA_39BIT_MASK 0x0000007fffffffffULL
> #define DMA_32BIT_MASK 0x00000000ffffffffULL
> --
> 1.3.1
>
> -
> To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
> the body of a message to majordomo@vger.kernel.org
> More majordomo info at http://vger.kernel.org/majordomo-info.html
> Please read the FAQ at http://www.tux.org/lkml/
^ permalink raw reply
* [PATCH] sis900 Foxconn 661FX7MI-S PHY support
From: James Cameron @ 2006-05-11 0:05 UTC (permalink / raw)
To: netdev, Daniele Venzano, Stephen Hemminger
This patch is required to get sis900 ethernet working well on a Foxconn
661FX7MI-S motherboard which uses the SiS 661FX chipset. The patch adds
an entry to mii_chip_info for the transceiver.
Signed-off-by: James Cameron <james.cameron@hp.com>
Acked-by: Daniele Venzano <venza@brownhat.org>
---
diff -puN linux-2.6.17-rc3-git17/drivers/net/sis900.c.orig linux-2.6.17-rc3-git17/drivers/net/sis900.c
--- linux-2.6.17-rc3-git17/drivers/net/sis900.c.orig 2006-05-11 09:21:52.000000000 +1000
+++ linux-2.6.17-rc3-git17/drivers/net/sis900.c 2006-05-11 09:34:26.000000000 +1000
@@ -127,6 +127,7 @@ static const struct mii_chip_info {
} mii_chip_table[] = {
{ "SiS 900 Internal MII PHY", 0x001d, 0x8000, LAN },
{ "SiS 7014 Physical Layer Solution", 0x0016, 0xf830, LAN },
+ { "SiS 900 on Foxconn 661 7MI", 0x0143, 0xBC70, LAN },
{ "Altimata AC101LF PHY", 0x0022, 0x5520, LAN },
{ "ADM 7001 LAN PHY", 0x002e, 0xcc60, LAN },
{ "AMD 79C901 10BASE-T PHY", 0x0000, 0x6B70, LAN },
^ permalink raw reply
* Re: [RFC PATCH 34/35] Add the Xen virtual network device driver.
From: Herbert Xu @ 2006-05-11 0:33 UTC (permalink / raw)
To: Andi Kleen
Cc: xen-devel, ian.pratt, netdev, rdreier, linux-kernel, chrisw,
virtualization, shemminger
In-Reply-To: <200605102028.22974.ak@suse.de>
Andi Kleen <ak@suse.de> wrote:
>
> But if sampling virtual events for randomness is really unsafe (is it
> really?) then native guests in Xen would also get bad random numbers
> and this would need to be somehow addressed.
Good point. I wonder what VMWare does in this situation.
--
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: r8169+NAPI soft lockup
From: Richard Gregory @ 2006-05-11 1:47 UTC (permalink / raw)
To: Francois Romieu, netdev
In-Reply-To: <20060510215004.GA25395@electric-eye.fr.zoreil.com>
[-- Attachment #1: Type: text/plain, Size: 483 bytes --]
Francois Romieu wrote:
> Richard Gregory <R.Gregory@liverpool.ac.uk> :
> [...]
>
>># locked in 1 min. Output in bug5.txt
>>$ for i in `seq 0 26` ; do cat /dev/md1 > /dev/tcp/linuxbox/9 &
>>$ cat /dev/md0 > /dev/tcp/localhost/9
>
>
> Can you replace /dev/tcp/foo with a simple /dev/null and send the output
> of 'vmstat 1' during 2 minutes of test ?
>
> A few seconds of 'vmstat 1' during a simple dd from /dev/md0
> (resp. /dev/md1) would be welcome too.
>
Attached.
Richard
[-- Attachment #2: r8169vmstat.txt --]
[-- Type: text/plain, Size: 15893 bytes --]
# for i in `seq 0 26` ; do cat /dev/md1 > /dev/null ; done &
# cat /dev/md0 > /dev/null
$ vmstat 1
procs -----------memory---------- ---swap-- -----io---- --system-- ----cpu----
r b swpd free buff cache si so bi bo in cs us sy id wa
0 0 7280 631436 848704 25264 0 0 0 37 31 39 1 14 83 2
0 0 7280 631436 848712 25264 0 0 0 56 232 26 0 0 100 0
0 0 7280 631436 848712 25264 0 0 0 0 212 12 0 0 100 0
0 0 7280 631436 848712 25264 0 0 0 0 221 24 0 0 100 0
0 0 7280 631436 848712 25264 0 0 0 0 212 10 0 0 100 0
0 0 7280 631436 848712 25264 0 0 0 0 208 12 0 0 100 0
0 0 7280 631436 848712 25264 0 0 0 0 209 6 0 0 100 0
0 0 7280 631436 848712 25264 0 0 0 0 212 14 0 0 100 0
0 0 7280 631436 848712 25264 0 0 0 0 209 8 0 0 100 0
0 1 7280 630572 849708 25328 0 0 17948 0 361 479 0 5 52 43
0 1 7280 630864 849404 25328 0 0 50384 0 621 1249 0 14 0 86
0 1 7280 630204 850044 25328 0 0 47360 0 583 1161 0 17 0 83
1 2 7280 631044 849040 25328 0 0 102292 0 1314 1319 0 65 0 35
0 2 7280 630984 849296 25328 0 0 122112 0 1627 1303 0 77 0 23
2 1 7280 630932 849296 25328 0 0 118400 60 1590 1291 1 78 0 21
1 1 7280 631044 849232 25328 0 0 123584 0 1582 1315 0 78 0 22
0 2 7280 630984 849252 25328 0 0 123264 0 1619 1315 0 74 0 26
1 2 7280 631104 848932 25328 0 0 116672 64 1681 1282 2 76 0 22
2 1 7280 631108 848964 25328 0 0 120704 0 1559 1299 1 74 0 25
2 1 7280 630572 849684 25328 0 0 124224 0 1670 1354 1 76 0 23
1 2 7280 631104 848988 25328 0 0 120128 32 1655 1327 0 77 0 23
procs -----------memory---------- ---swap-- -----io---- --system-- ----cpu----
r b swpd free buff cache si so bi bo in cs us sy id wa
0 2 7280 630984 849252 25328 0 0 126336 0 1821 1416 1 83 0 16
0 2 7280 631112 849124 25328 0 0 126592 0 1818 1413 0 88 0 12
1 2 7280 631164 848888 25328 0 0 127104 0 1824 1401 1 87 0 12
1 2 7280 631292 848760 25328 0 0 122880 0 1678 1311 1 77 0 22
2 1 7280 630392 849856 25328 0 0 124864 32 1842 1392 1 85 0 14
2 1 7280 631232 848840 25328 0 0 123776 0 1744 1385 0 83 0 17
2 1 7280 630984 849288 25328 0 0 122816 0 1702 1319 0 78 0 22
2 2 7280 630932 849352 25328 0 0 127040 0 1786 1402 1 83 0 16
1 1 7280 631104 848976 25328 0 0 123520 12 1637 1351 0 79 0 21
0 2 7280 631112 849188 25328 0 0 118080 20 1666 1263 3 70 2 25
2 1 7280 630504 849772 25328 0 0 128960 0 1925 1462 1 89 0 10
2 1 7280 630144 850156 25328 0 0 122880 0 1641 1352 1 76 0 23
2 1 7280 630744 849520 25328 0 0 125952 0 1777 1383 1 81 0 18
1 3 7280 630444 849848 25328 0 0 122820 20 1671 1369 3 76 0 21
2 1 7280 630924 849340 25328 0 0 120832 12 1689 1322 2 78 0 20
2 2 7280 631164 848960 25328 0 0 123904 0 1705 1378 2 82 0 16
1 1 7280 631044 849232 25328 0 0 126336 0 1752 1385 2 78 0 20
2 1 7280 630324 849956 25328 0 0 124228 40 1883 1442 1 88 0 11
2 1 7280 630624 849700 25328 0 0 122240 0 1628 1297 0 79 0 21
1 2 7280 631104 848996 25328 0 0 123072 0 1620 1346 2 77 0 21
1 1 7280 631052 849252 25328 0 0 123520 0 1697 1358 0 77 0 23
procs -----------memory---------- ---swap-- -----io---- --system-- ----cpu----
r b swpd free buff cache si so bi bo in cs us sy id wa
0 2 7280 630924 849380 25328 0 0 127488 0 1901 1420 1 87 0 12
1 2 7280 630144 850156 25328 0 0 120064 32 1664 1321 0 83 0 17
1 2 7280 631224 848880 25328 0 0 124544 0 1666 1343 0 81 0 19
2 2 7280 631104 849228 25328 0 0 122816 0 1686 1362 1 83 0 16
2 1 7280 630812 849484 25328 0 0 120448 0 1552 1307 0 70 0 30
1 1 7280 630512 849804 25328 0 0 124864 0 1753 1389 1 80 0 19
2 1 7280 630444 849876 25328 0 0 120384 32 1711 1317 0 77 0 23
1 2 7280 630804 849492 25328 0 0 120192 0 1596 1364 3 76 0 21
1 2 7280 631164 848988 25328 0 0 121472 0 1549 1300 0 83 0 17
1 2 7280 631224 848924 25328 0 0 125504 0 1777 1383 0 77 0 23
2 2 7280 630624 849716 25328 0 0 121728 20 1776 1337 0 85 0 15
0 2 7280 630864 849468 25328 0 0 115712 32 1548 1246 1 66 2 31
2 1 7280 631232 848892 25328 0 0 123456 0 1720 1389 3 79 0 18
0 2 7280 631104 849220 25328 0 0 128704 0 1870 1412 0 90 0 10
2 1 7280 630384 849924 25328 0 0 126016 0 1801 1407 1 85 0 14
0 2 7280 630984 849348 25328 0 0 123200 0 1625 1340 1 77 0 22
2 1 7280 630504 849804 25328 0 0 118208 32 1597 1307 3 70 2 25
2 1 7280 630392 849952 25328 0 0 128128 0 1867 1412 0 86 0 14
0 2 7280 630444 849896 25328 0 0 120768 0 1570 1313 0 71 0 29
0 2 7280 631044 849256 25328 0 0 124672 0 1710 1365 1 79 0 20
0 2 7280 630924 849384 25328 0 0 125952 0 1789 1406 0 89 0 11
procs -----------memory---------- ---swap-- -----io---- --system-- ----cpu----
r b swpd free buff cache si so bi bo in cs us sy id wa
1 1 7280 630504 849840 25328 0 0 121408 32 1773 1385 2 81 0 17
1 1 7280 630812 849520 25328 0 0 123200 0 1705 1376 1 77 0 22
0 2 7280 631224 849144 25328 0 0 126976 0 1700 1379 0 77 0 23
1 2 7280 630924 849420 25328 0 0 123776 0 1658 1358 1 78 0 21
1 2 7280 630384 849932 25328 0 0 122368 0 1592 1308 0 75 0 25
2 2 7280 630744 849620 25328 0 0 121920 32 1741 1338 2 79 0 19
0 2 7280 631104 849236 25328 0 0 125440 0 1737 1373 1 85 0 14
2 1 7280 630444 849884 25328 0 0 123648 0 1652 1343 0 80 0 20
1 1 7280 630804 849564 25328 0 0 125504 0 1716 1387 3 80 0 17
3 2 7280 631164 849180 25328 0 0 126208 0 1855 1407 2 85 0 13
1 1 7280 630932 849400 25328 0 0 119104 32 1726 1354 0 82 2 16
2 1 7280 630384 849976 25328 0 0 121152 0 1506 1304 0 66 0 34
1 2 7280 631224 848960 25328 0 0 124800 0 1733 1369 0 81 0 19
2 1 7280 630564 849792 25328 0 0 125888 0 1821 1439 0 85 0 15
1 1 7280 630452 849920 25328 0 0 127616 0 1840 1406 1 83 0 16
1 2 7280 630684 849672 25328 0 0 114048 32 1538 1233 1 71 0 28
0 2 7280 630564 849800 25328 0 0 124160 0 1672 1360 0 83 0 17
0 2 7280 631104 849252 25328 0 0 122944 0 1652 1332 0 76 0 24
2 1 7280 630572 849764 25328 0 0 121472 0 1596 1307 1 76 0 23
2 1 7280 630564 849828 25328 0 0 122176 0 1604 1329 1 77 0 22
2 1 7280 631232 848940 25328 0 0 118272 32 1643 1285 0 75 2 23
procs -----------memory---------- ---swap-- -----io---- --system-- ----cpu----
r b swpd free buff cache si so bi bo in cs us sy id wa
0 2 7280 630444 849900 25328 0 0 123072 0 1656 1314 0 80 0 20
2 1 7280 630144 850228 25328 0 0 126144 0 1783 1356 1 81 0 18
2 1 7280 630812 849588 25328 0 0 125568 0 1788 1376 1 85 0 14
2 1 7280 631112 849288 25328 0 0 123968 0 1705 1335 0 77 0 23
2 1 7280 630624 849744 25328 0 0 120512 32 1678 1314 3 76 0 21
1 1 7280 630624 849744 25328 0 0 125312 0 1761 1388 2 79 0 19
2 1 7280 630744 849624 25328 0 0 124160 0 1718 1329 0 81 0 19
2 1 7280 630392 850000 25328 0 0 121592 0 1696 1355 2 74 0 24
1 2 7280 630932 849424 25328 0 0 124224 0 1734 1363 3 81 0 16
2 1 7280 630384 850008 25328 0 0 118592 32 1657 1290 0 77 2 21
1 1 7280 631284 849068 25328 0 0 124864 0 1771 1352 0 84 0 16
1 2 7280 630804 849588 25328 0 0 124544 0 1762 1402 0 82 0 18
2 1 7280 630572 849844 25328 0 0 124032 0 1695 1335 0 82 0 18
0 2 7280 630992 849396 25328 0 0 123328 0 1651 1319 0 83 0 17
2 1 7280 630324 850044 25328 0 0 115968 32 1537 1250 1 71 1 27
1 1 7280 631044 849148 25328 0 0 126592 0 1795 1399 0 84 0 16
1 1 7280 630324 850052 25328 0 0 123776 0 1672 1353 0 79 0 21
2 1 7280 630864 849556 25328 0 0 122496 0 1705 1359 0 80 0 20
2 2 7280 630444 849944 25328 0 0 121088 0 1603 1316 1 77 0 22
2 1 7280 631052 849376 25328 0 0 114880 32 1494 1234 0 72 2 26
2 1 7280 630264 850144 25328 0 0 123392 0 1653 1326 0 76 0 24
procs -----------memory---------- ---swap-- -----io---- --system-- ----cpu----
r b swpd free buff cache si so bi bo in cs us sy id wa
2 1 7280 630324 850088 25328 0 0 121408 0 1548 1326 1 71 0 28
2 2 7280 631044 849384 25328 0 0 124352 0 1775 1399 0 83 0 17
1 2 7280 630864 849512 25328 0 0 123136 0 1682 1352 0 83 0 17
0 2 7280 631104 849268 25328 0 0 115456 32 1585 1319 2 70 2 26
2 1 7280 630444 849988 25328 0 0 121024 0 1593 1321 0 77 0 23
2 1 7280 630564 849868 25328 0 0 123904 0 1729 1351 0 83 0 17
2 1 7280 631224 848972 25328 0 0 124672 0 1728 1359 1 77 0 22
2 1 7280 630924 849484 25328 0 0 123008 0 1740 1323 2 80 0 18
2 1 7280 630444 850004 25328 0 0 121600 32 1821 1359 1 81 2 16
0 2 7280 630984 849428 25328 0 0 126656 0 1792 1395 2 82 0 16
2 1 7280 630384 850012 25328 0 0 123200 0 1647 1348 0 78 0 22
0 2 7280 630324 850096 25328 0 0 122048 0 1634 1306 1 76 0 23
0 2 7280 630984 849456 25328 0 0 125184 0 1779 1403 0 80 0 20
2 2 7280 630812 849592 25328 0 0 119552 32 1682 1288 0 76 0 24
2 1 7280 630264 850168 25328 0 0 121920 0 1586 1317 1 75 0 24
1 2 7280 631112 849344 25328 0 0 127424 0 1834 1383 1 84 0 15
2 1 7280 631044 849216 25328 0 0 125952 0 1736 1368 0 77 0 23
0 2 7280 630684 849728 25328 0 0 121600 0 1591 1306 1 73 0 26
2 1 7280 630512 849948 25328 0 0 119360 32 1668 1327 1 77 0 22
0 2 7280 630744 849692 25328 0 0 126336 0 1821 1403 1 80 0 19
2 1 7280 630504 849956 25328 0 0 124032 0 1733 1371 1 82 0 17
procs -----------memory---------- ---swap-- -----io---- --system-- ----cpu----
r b swpd free buff cache si so bi bo in cs us sy id wa
2 1 7280 630744 849700 25328 0 0 121856 0 1652 1298 2 77 0 21
0 2 7280 630924 849508 25328 0 0 129856 0 1947 1488 1 91 0 8
1 2 7280 630864 849580 25328 0 0 119616 32 1675 1328 0 80 0 20
2 1 7280 630324 850092 25328 0 0 123520 0 1654 1343 0 81 0 19
1 2 7280 631224 849032 25328 0 0 121408 0 1561 1292 1 75 0 24
0 2 7280 631164 849288 25328 0 0 127104 0 1862 1404 0 89 0 11
0 0 7280 631052 849420 25328 0 0 120320 12 1595 1303 0 80 2 18
2 1 7280 630444 850000 25328 0 0 121920 20 1709 1357 2 80 0 18
2 1 7280 631164 849108 25328 0 0 124928 0 1800 1418 1 82 0 17
2 1 7280 630564 849880 25328 0 0 125568 0 1768 1395 2 80 0 18
1 2 7280 631104 849176 25328 0 0 123840 0 1691 1354 1 74 0 25
0 1 7280 630864 849588 25328 0 0 97408 32 1339 1212 1 58 2 39
0 1 7280 630504 849972 25328 0 0 45824 0 573 1129 1 14 0 85
0 1 7280 630384 850100 25328 0 0 46976 0 575 1145 0 14 0 86
0 1 7280 630212 850228 25328 0 0 46976 0 589 1163 0 15 0 85
0 0 7280 630520 849972 25328 0 0 40064 0 539 1000 0 10 15 75
0 0 7280 630520 849980 25328 0 0 0 28 224 24 0 0 100 0
0 0 7280 630520 849980 25328 0 0 0 0 208 8 0 0 100 0
0 0 7280 630536 849980 25328 0 0 0 0 209 8 0 0 100 0
0 0 7280 630536 849980 25328 0 0 0 0 212 10 0 0 100 0
# dd if=/dev/md0 > /dev/null
# vmstat 1
procs -----------memory---------- ---swap-- -----io---- --system-- ----cpu----
r b swpd free buff cache si so bi bo in cs us sy id wa
0 0 7280 630828 849780 25340 0 0 28 37 32 39 1 14 83 2
0 0 7280 630828 849780 25340 0 0 0 0 216 8 0 0 100 0
0 0 7280 630828 849780 25340 0 0 0 0 209 8 0 0 100 0
0 0 7280 630828 849780 25340 0 0 0 0 209 8 0 0 100 0
0 1 7280 630648 849964 25372 0 0 15308 68 450 197 5 59 16 20
1 0 7280 630528 850092 25372 0 0 65408 0 1099 485 5 60 0 35
0 1 7280 631120 849324 25372 0 0 65408 0 1078 474 4 52 0 44
1 0 7280 630460 850156 25372 0 0 65856 0 1104 501 5 50 0 45
0 1 7280 630520 850092 25372 0 0 64960 0 1080 483 4 49 0 48
1 0 7280 630880 849780 25372 0 0 63168 28 1058 474 2 59 0 39
1 0 7280 630880 849780 25372 0 0 66304 0 1117 526 6 52 0 42
0 1 7280 630948 849716 25372 0 0 64960 0 1060 466 4 57 0 39
0 0 7280 630460 850164 25372 0 0 47936 0 861 369 2 41 27 31
0 0 7280 630468 850164 25372 0 0 0 0 208 8 0 0 100 0
0 0 7280 630468 850172 25372 0 0 0 28 227 26 0 1 99 0
# dd if=/dev/md1 > /dev/null
$ vmstat 1
procs -----------memory---------- ---swap-- -----io---- --system-- ----cpu----
r b swpd free buff cache si so bi bo in cs us sy id wa
0 0 7280 630468 850172 25372 0 0 29 37 32 39 1 14 83 2
0 0 7280 630468 850172 25372 0 0 0 0 217 8 0 0 100 0
0 0 7280 630468 850172 25372 0 0 0 0 237 56 0 0 100 0
0 0 7280 630468 850172 25372 0 0 0 0 217 19 0 0 100 0
0 0 7280 630468 850172 25372 0 0 0 40 236 25 0 0 100 0
1 1 7280 630468 850200 25372 0 0 36492 52 512 920 1 18 18 63
0 1 7280 630700 849948 25372 0 0 46464 4 573 1139 2 21 0 77
1 0 7280 631180 849436 25372 0 0 45056 8 567 1102 4 25 0 71
0 1 7280 630580 850076 25372 0 0 47360 0 579 1156 0 30 0 70
0 1 7280 631180 849308 25372 0 0 47360 0 578 1157 2 27 0 71
0 1 7280 630820 849820 25372 0 0 47360 0 578 1152 3 24 0 73
0 1 7280 630700 849948 25372 0 0 43008 28 560 1063 4 19 2 75
0 1 7280 630156 850460 25372 0 0 47360 0 578 1152 3 22 0 75
0 1 7280 630820 849820 25372 0 0 47360 0 580 1158 1 28 0 71
0 0 7280 630828 849820 25372 0 0 10496 0 301 276 0 9 78 13
0 0 7280 630836 849820 25372 0 0 0 0 208 10 0 0 100 0
0 0 7280 630836 849820 25372 0 0 0 28 225 24 0 1 99 0
0 0 7280 630836 849820 25372 0 0 0 0 208 8 0 0 100 0
^ permalink raw reply
* Re: [Bugme-new] [Bug 6530] New: MAINLINE
From: Andrew Morton @ 2006-05-11 3:29 UTC (permalink / raw)
To: Paul Mackerras; +Cc: bugme-daemon, netdev, xeb
In-Reply-To: <17505.49174.848331.686297@cargo.ozlabs.ibm.com>
Paul Mackerras <paulus@samba.org> wrote:
>
> Andrew Morton writes:
>
> > hm, a PPP fix. We seem to need some of those lately.
> >
> > Paul, does this look sane?
>
> /me pages in 7 year old code...
>
> > @@ -516,6 +516,8 @@ static void ppp_async_process(unsigned l
> > /* try to push more stuff out */
> > if (test_bit(XMIT_WAKEUP, &ap->xmit_flags) && ppp_async_push(ap))
> > ppp_output_wakeup(&ap->chan);
> > + else if (test_bit(XMIT_FULL, &ap->xmit_flags))
> > + ppp_asynctty_wakeup(ap->tty);
>
> ppp_asynctty_wakeup is supposed to be called by the serial driver when
> it can take more output. It's slightly bogus having ppp_async call it
> itself whether or not the serial driver can take more output at the
> moment, but I suppose it won't hurt. I would really like to know the
> precise circumstances where we need this fake wakeup though. Is the
> serial driver failing to give us a wakeup call where it should, or is
> ppp_async ignoring a wakeup for some reason?
>
> I think the same effect could be achieved without an extra trip
> through tasklet_schedule et al. by making those lines look like this
> (untested):
>
> if ((test_bit(XMIT_WAKEUP, &ap->xmit_flags) ||
> test_bit(XMIT_FULL, &ap->xmit_flags)) && ppp_async_push(ap))
> ppp_output_wakeup(&ap->chan);
>
> so that ppp_async_push gets called if either XMIT_WAKEUP or XMIT_FULL
> is set.
>
> This is all relying on getting some input to kick off more output when
> the wakeup gets missed, though. That's a reasonable workaround in most
> situations, I guess, but I'd really like to know why the wakeup is
> getting missed.
>
(xeb, on this bug please respond via email using reply-to-all rather than
via the bugzilla web form).
xeb has said:
in this construction:
if ((test_bit(XMIT_WAKEUP, &ap->xmit_flags) ||
test_bit(XMIT_FULL, &ap->xmit_flags)) && ppp_async_push(ap))
ppp_output_wakeup(&ap->chan);
if ppp_async_push() doesn't send any data i.e. XMIT_FULL is set then all
(transfer) hangs up while somebody push again, for instance lcp-echo.
^ permalink raw reply
* Re: [PATCH] bcm43xx: Fix array overrun in bcm43xx_geo_init
From: Andrew Morton @ 2006-05-11 3:42 UTC (permalink / raw)
To: Michael Buesch; +Cc: linville, st3, bcm43xx-dev, netdev, Stephen Hemminger
In-Reply-To: <200605051723.51609.mb@bu3sch.de>
Michael Buesch <mb@bu3sch.de> wrote:
>
> The problem here is that the bcm34xx driver and the ieee80211
> stack do not agree on what channels are possible for 802.11a.
> The ieee80211 stack only wants channels between 34 and 165, while
> the bcm43xx driver accepts anything from 0 to 200. I made the
> bcm43xx driver comply with the ieee80211 stack expectations, by
> using the proper constants.
>
> Signed-off-by: Jean Delvare <jdelvare@suse.de>
>
> [mb]: Reduce stack usage by kzalloc-ing ieee80211_geo
>
> Signed-off-by: Michael Buesch <mb@bu3sch.de>
I find this changelog confusing. We seem to have two patches, one written
by Jean and one by yourself, perhaps? And the fact that the changlog
didn't start with
From: Jean Delvare <jdelvare@suse.de>
indicates that you are to be considered the primary author?
btw, we seem to have a number of bcm43xx patches banking up. I don't know
if John has merged them because we're back in the situation where some of
John's tree has been merged into Jeff's tree but hasn't gone upstream - so
my git-wireless.patch generates a massive reject storm against git-netdev.patch
So I suspect that all these bcm43xx might not be making it into 2.6.17.
^ permalink raw reply
* Re: [PATCH] bonding: fix sparse warnings
From: Stephen Hemminger @ 2006-05-11 3:45 UTC (permalink / raw)
To: Al Viro; +Cc: ctindel, Jay Vosburgh, bonding-devel, netdev
In-Reply-To: <20060510232203.GK27946@ftp.linux.org.uk>
On Thu, 11 May 2006 00:22:03 +0100
Al Viro <viro@ftp.linux.org.uk> wrote:
> On Wed, May 10, 2006 at 04:14:05PM -0700, Stephen Hemminger wrote:
> > Fix warning from sparse in bonding code about "incorrect type in assignment"
>
> *snerk*
>
> Only if you are building without -Wcast-to-as. It _is_ incorrect type in
> assignment. And the real fix is to expand the call, killing set_fs()
> in there.
More like this (in br_if.c)?
struct ethtool_cmd ecmd = { ETHTOOL_GSET };
struct ifreq ifr;
mm_segment_t old_fs;
int err;
strncpy(ifr.ifr_name, dev->name, IFNAMSIZ);
ifr.ifr_data = (void __user *) &ecmd;
old_fs = get_fs();
set_fs(KERNEL_DS);
err = dev_ethtool(&ifr);
set_fs(old_fs);
if (!err)
...
^ permalink raw reply
* Re: [Bugme-new] [Bug 6530] New: MAINLINE
From: Paul Mackerras @ 2006-05-11 4:01 UTC (permalink / raw)
To: Andrew Morton; +Cc: bugme-daemon, netdev, xeb
In-Reply-To: <20060510202943.35f548db.akpm@osdl.org>
Andrew Morton writes:
> xeb has said:
>
> in this construction:
>
> if ((test_bit(XMIT_WAKEUP, &ap->xmit_flags) ||
> test_bit(XMIT_FULL, &ap->xmit_flags)) && ppp_async_push(ap))
> ppp_output_wakeup(&ap->chan);
>
> if ppp_async_push() doesn't send any data i.e. XMIT_FULL is set then all
> (transfer) hangs up while somebody push again, for instance lcp-echo.
If XMIT_FULL and ppp_async_push doesn't send any data, that means the
serial driver's output buffer was full. If that's the case, *and* we
don't see a call to ppp_output_wakeup, then the finger points squarely
at the serial driver as the source of the bug.
Paul.
^ permalink raw reply
* Ad:¡ºÎÒÊÇÍæ¼Ò¡»£¬ÓÎÏ·Íæ¼ÒµÄÍøÉϼÒÔ°£¡
From: q9PkTm2V6oUsKt3 @ 2006-05-11 4:04 UTC (permalink / raw)
To: yPCv5lJhWFRcK
¡ºÎÒÊÇÍæ¼Ò¡»ÍøÕ¾ http://iamwanjia.oicp.net/ ÊÇΪÓÎÏ·Íæ¼ÒÌṩһ¸ö»¥ÏàÈÏʶ£¬½»Á÷£¬¹µÍ¨µÄÒ»¸öÉçÇøƽ̨¡£
ÔÚÕâ¸öƽ̨ÖУ¬Ä¿Ç°ÓС°Íæ¼Ò¶Ô¶ÔÅö¡±£¬¡°ÒµÄÚ×îÐÂÏûÏ¢¡±£¬¡°×°±¸µã¿¨½»Ò×½»»»Çø¡±£¬
¡°ÓÎÏ·ÈËÉú¡±£¬ ¡°ÓéÀÖÐÝÏÐÇø¡± µÈ¶ÔÍæ¼Ò¿ª·ÅµÄÖ÷Ìâ¡£
Èç¹ûÄã¶ÔÓÎÏ·ÓÐÐËȤ£¬Çë¼ÓÈëÎÒÃÇ£¬ÎÒÃÇһͬ½¨ÉèÎÒÃÇ×Ô¼ºµÄÍøÉϼÒÔ°¡£
±¾Õ¾³¤ÆÚÕÐƸ°æÖ÷¡£»¶ÓÄã¼ÓÃË¡£
^ permalink raw reply
* Re: [Bugme-new] [Bug 6530] New: MAINLINE
From: Andrew Morton @ 2006-05-11 4:06 UTC (permalink / raw)
To: Paul Mackerras; +Cc: bugme-daemon, netdev, xeb
In-Reply-To: <17506.46898.503580.4994@cargo.ozlabs.ibm.com>
Paul Mackerras <paulus@samba.org> wrote:
>
> Andrew Morton writes:
>
> > xeb has said:
> >
> > in this construction:
> >
> > if ((test_bit(XMIT_WAKEUP, &ap->xmit_flags) ||
> > test_bit(XMIT_FULL, &ap->xmit_flags)) && ppp_async_push(ap))
> > ppp_output_wakeup(&ap->chan);
> >
> > if ppp_async_push() doesn't send any data i.e. XMIT_FULL is set then all
> > (transfer) hangs up while somebody push again, for instance lcp-echo.
>
> If XMIT_FULL and ppp_async_push doesn't send any data, that means the
> serial driver's output buffer was full. If that's the case, *and* we
> don't see a call to ppp_output_wakeup, then the finger points squarely
> at the serial driver as the source of the bug.
>
OK, thanks. So the next question is: which driver is being used?
^ permalink raw reply
* Re: [Bugme-new] [Bug 6530] New: MAINLINE
From: Andy Gay @ 2006-05-11 5:51 UTC (permalink / raw)
To: Paul Mackerras; +Cc: Andrew Morton, bugme-daemon, netdev, xeb
In-Reply-To: <17505.49174.848331.686297@cargo.ozlabs.ibm.com>
On Wed, 2006-05-10 at 20:27 +1000, Paul Mackerras wrote:
> Andrew Morton writes:
>
> > hm, a PPP fix. We seem to need some of those lately.
> >
> > Paul, does this look sane?
>
> /me pages in 7 year old code...
>
> > @@ -516,6 +516,8 @@ static void ppp_async_process(unsigned l
> > /* try to push more stuff out */
> > if (test_bit(XMIT_WAKEUP, &ap->xmit_flags) && ppp_async_push(ap))
> > ppp_output_wakeup(&ap->chan);
> > + else if (test_bit(XMIT_FULL, &ap->xmit_flags))
> > + ppp_asynctty_wakeup(ap->tty);
>
> ppp_asynctty_wakeup is supposed to be called by the serial driver when
> it can take more output.
How does the serial driver know it has to call ppp_asynctty_wakeup()?
I'd have thought it wouldn't know or care if it's being used for ppp or
any other async traffic.
There were a bunch of changes to the serial drivers between 2.6.15 and
2.6.16, maybe that's where this problem was introduced. Do we know which
serial driver is involved in the original report?
(I'm interested in this because I need to convert an out of tree serial
driver for 2.6.16+, I'm wondering if I'll need to do anything special to
support ppp).
> It's slightly bogus having ppp_async call it
> itself whether or not the serial driver can take more output at the
> moment, but I suppose it won't hurt. I would really like to know the
> precise circumstances where we need this fake wakeup though. Is the
> serial driver failing to give us a wakeup call where it should, or is
> ppp_async ignoring a wakeup for some reason?
>
> I think the same effect could be achieved without an extra trip
> through tasklet_schedule et al. by making those lines look like this
> (untested):
>
> if ((test_bit(XMIT_WAKEUP, &ap->xmit_flags) ||
> test_bit(XMIT_FULL, &ap->xmit_flags)) && ppp_async_push(ap))
> ppp_output_wakeup(&ap->chan);
>
> so that ppp_async_push gets called if either XMIT_WAKEUP or XMIT_FULL
> is set.
>
> This is all relying on getting some input to kick off more output when
> the wakeup gets missed, though. That's a reasonable workaround in most
> situations, I guess, but I'd really like to know why the wakeup is
> getting missed.
>
> Paul.
> -
> 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: [Bugme-new] [Bug 6530] New: MAINLINE
From: Andrew Morton @ 2006-05-11 5:56 UTC (permalink / raw)
To: Andy Gay; +Cc: paulus, bugme-daemon, netdev, xeb
In-Reply-To: <1147326683.29448.80.camel@tahini.andynet.net>
Andy Gay <andy@andynet.net> wrote:
>
> On Wed, 2006-05-10 at 20:27 +1000, Paul Mackerras wrote:
> > Andrew Morton writes:
> >
> > > hm, a PPP fix. We seem to need some of those lately.
> > >
> > > Paul, does this look sane?
> >
> > /me pages in 7 year old code...
> >
> > > @@ -516,6 +516,8 @@ static void ppp_async_process(unsigned l
> > > /* try to push more stuff out */
> > > if (test_bit(XMIT_WAKEUP, &ap->xmit_flags) && ppp_async_push(ap))
> > > ppp_output_wakeup(&ap->chan);
> > > + else if (test_bit(XMIT_FULL, &ap->xmit_flags))
> > > + ppp_asynctty_wakeup(ap->tty);
> >
> > ppp_asynctty_wakeup is supposed to be called by the serial driver when
> > it can take more output.
>
> How does the serial driver know it has to call ppp_asynctty_wakeup()?
> I'd have thought it wouldn't know or care if it's being used for ppp or
> any other async traffic.
xeb (who forgot to do reply-to-all) tells me that pptpd uses ptys.
^ permalink raw reply
* Re: Initial benchmarks of some VJ ideas [mmap memcpy vs copy_to_user].
From: Evgeniy Polyakov @ 2006-05-11 6:40 UTC (permalink / raw)
To: David S. Miller; +Cc: netdev, caitlinb, kelly, rusty
In-Reply-To: <20060510.125848.44052388.davem@davemloft.net>
On Wed, May 10, 2006 at 12:58:48PM -0700, David S. Miller (davem@davemloft.net) wrote:
> From: Evgeniy Polyakov <johnpol@2ka.mipt.ru>
> Date: Mon, 8 May 2006 16:24:22 +0400
>
> > I hope he does not take offence at name shortening :)
>
> Perhaps you are still not convinced how truly expensive the code path
> from netif_receive_skb() to the protocol receive processing really is.
That is why UDP was selected - it is itself does not cost anything,
ip_rcv() + netif_receive_skb() will be in any channels, but instead of
searching through unified cache with src/port/dst/port/proto we search
through src/port/dst/port + through proto in ip_rcv().
There are no locks there except disabled preemption, those codepath
_never_ showed in profiles.
Grand unified cache is of course a good idea, but it will not bring new
performance gain to Linux.
It _is_ much more convenient and code path will be shorter, but only
because route/dst lookup will be hidden in unified cache.
Memory copy and context switch were eliminated in net channel, and that
trashed any cache much more than than removing 50 lines of code accessed
parts of skb->data.
> It is absolutely necessary to find ways to get rid of these layering
> costs. "Layering is how you design networking protocols, not how you
> implement them."
If I provide a patch which will allow to mark special socket as
no-protocol-and-any-upper-layer-lookup, but instead process skb->data
(like copying to userspace, or just allow recv() to return without any
copy) and performance will not differ from what we have with layers,
will it justify that not abstract cache trashing and lookup split into
socket/route are not the problem?
Or have you switched from engineering to researching mode? :)
--
Evgeniy Polyakov
^ permalink raw reply
* Re: [RFC][SECMARK 03/08] Add xtables SECMARK target
From: Patrick McHardy @ 2006-05-11 7:06 UTC (permalink / raw)
To: James Morris
Cc: selinux, netdev, netfilter-devel, Stephen Smalley, Daniel J Walsh
In-Reply-To: <Pine.LNX.4.64.0605100925340.30577@d.namei>
James Morris wrote:
> On Wed, 10 May 2006, Patrick McHardy wrote:
>
>
>>The netfilter parts all look fine too me (just one question,
>>see below). Shall I add the userspace parts to SVN or do you
>>want to do it yourself?
>
>
> Might be better if you do it, although I'm still looking into one issue at
> this stage.
Just tell me when you want me to add it.
^ permalink raw reply
* Re: Initial benchmarks of some VJ ideas [mmap memcpy vs copy_to_user].
From: David S. Miller @ 2006-05-11 7:07 UTC (permalink / raw)
To: johnpol; +Cc: netdev, caitlinb, kelly, rusty
In-Reply-To: <20060511064037.GB22770@2ka.mipt.ru>
From: Evgeniy Polyakov <johnpol@2ka.mipt.ru>
Date: Thu, 11 May 2006 10:40:37 +0400
> > It is absolutely necessary to find ways to get rid of these layering
> > costs. "Layering is how you design networking protocols, not how you
> > implement them."
>
> If I provide a patch which will allow to mark special socket as
> no-protocol-and-any-upper-layer-lookup, but instead process skb->data
> (like copying to userspace, or just allow recv() to return without any
> copy) and performance will not differ from what we have with layers,
> will it justify that not abstract cache trashing and lookup split into
> socket/route are not the problem?
>
> Or have you switched from engineering to researching mode? :)
You test with single socket and single source ID, what do you expect?
Everything is hot in the cache, as expected.
It is not research, I did put cycle counter sampling all over these
spots on sparc64 a long time ago just to familiarize myself with where
cpu spends most of it's time in softint processing when there are lots
of sockets and unique remote addresses.
And most of the time from netif_receive_skb() to the meat of
{udp,tcp}_rcv() is touching the routing cache and socket demux hash
tables. Add bonus costs to netfilter if that is enabled too. Once
you are past that point, for TCP, tcp_ack() is the primary cpu cycle
eater.
You can test with single stream, but then you are only testing
in-cache case. Try several thousand sockets and real load from many
unique source systems, it becomes interesting then.
>From profiles of heavily used web server, what shows up is bulk of cpu
being in socket demux and tcp_ack(). Next bubble is routing cache.
I have not seen good profiles from a heavy web server employing any
real use of netfilter, that would be interesting as well.
^ permalink raw reply
* Re: [RFC PATCH 34/35] Add the Xen virtual network device driver.
From: Keir Fraser @ 2006-05-11 7:49 UTC (permalink / raw)
To: Herbert Xu
Cc: xen-devel, virtualization, netdev, rdreier, Andi Kleen,
linux-kernel, chrisw, ian.pratt, shemminger
In-Reply-To: <E1Fdz7v-0007zc-00@gondolin.me.apana.org.au>
On 11 May 2006, at 01:33, Herbert Xu wrote:
>> But if sampling virtual events for randomness is really unsafe (is it
>> really?) then native guests in Xen would also get bad random numbers
>> and this would need to be somehow addressed.
>
> Good point. I wonder what VMWare does in this situation.
Well, there's not much they can do except maybe jitter interrupt
delivery. I doubt they do that though.
The original complaint in our case was that we take entropy from
interrupts caused by other local VMs, as well as external sources.
There was a feeling that the former was more predictable and could form
the basis of an attack. I have to say I'm unconvinced: I don't really
see that it's significantly easier to inject precisely-timed interrupts
into a local VM. Certainly not to better than +/- a few microseconds.
As long as you add cycle-counter info to the entropy pool, the least
significant bits of that will always be noise.
The alternatives are unattractive:
1. We have no good way to distinguish interrupts caused by packets
from local VMs versus packets from remote hosts. Both get muxed on the
same virtual interface.
2. An entropy front/back is tricky -- how do we decide how much
entropy to pull from domain0? How much should domain0 be prepared to
give other domains? How easy is it to DoS domain0 by draining its
entropy pool? Yuk.
-- Keir
^ permalink raw reply
* Re: [RFC PATCH 34/35] Add the Xen virtual network device driver.
From: Herbert Xu @ 2006-05-11 8:04 UTC (permalink / raw)
To: Keir Fraser
Cc: xen-devel, ian.pratt, rdreier, linux-kernel, netdev, Andi Kleen,
virtualization, chrisw, shemminger
In-Reply-To: <fb99d7085b85310ef7d423a8f135db32@cl.cam.ac.uk>
On Thu, May 11, 2006 at 08:49:04AM +0100, Keir Fraser wrote:
>
> The alternatives are unattractive:
> 1. We have no good way to distinguish interrupts caused by packets
> from local VMs versus packets from remote hosts. Both get muxed on the
> same virtual interface.
> 2. An entropy front/back is tricky -- how do we decide how much
> entropy to pull from domain0? How much should domain0 be prepared to
> give other domains? How easy is it to DoS domain0 by draining its
> entropy pool? Yuk.
IMHO there just isn't enough real entropy to go around in one physical
machine without a proper HRNG. So either use urandom in all the guests
or for those that really have to use /dev/random, install a hardware
RNG (or wait for it :).
Cheers,
--
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: [PATCH] bcm43xx: Fix array overrun in bcm43xx_geo_init
From: Michael Buesch @ 2006-05-11 8:29 UTC (permalink / raw)
To: Andrew Morton; +Cc: linville, st3, bcm43xx-dev, netdev, Stephen Hemminger
In-Reply-To: <20060510204200.43ed67fb.akpm@osdl.org>
On Thursday 11 May 2006 05:42, you wrote:
> Michael Buesch <mb@bu3sch.de> wrote:
> >
> > The problem here is that the bcm34xx driver and the ieee80211
> > stack do not agree on what channels are possible for 802.11a.
> > The ieee80211 stack only wants channels between 34 and 165, while
> > the bcm43xx driver accepts anything from 0 to 200. I made the
> > bcm43xx driver comply with the ieee80211 stack expectations, by
> > using the proper constants.
> >
> > Signed-off-by: Jean Delvare <jdelvare@suse.de>
> >
> > [mb]: Reduce stack usage by kzalloc-ing ieee80211_geo
> >
> > Signed-off-by: Michael Buesch <mb@bu3sch.de>
>
> I find this changelog confusing. We seem to have two patches, one written
> by Jean and one by yourself, perhaps? And the fact that the changlog
> didn't start with
I simply added one or two lines of code.
> From: Jean Delvare <jdelvare@suse.de>
>
> indicates that you are to be considered the primary author?
No, I forgot about that line.
> btw, we seem to have a number of bcm43xx patches banking up. I don't know
> if John has merged them because we're back in the situation where some of
> John's tree has been merged into Jeff's tree but hasn't gone upstream - so
> my git-wireless.patch generates a massive reject storm against git-netdev.patch
>
> So I suspect that all these bcm43xx might not be making it into 2.6.17.
I think most of the patches should already be merged by john. But I did not
recheck this. It would be bad, if they won't make it for 2.6.17, though,
as they are all heavy bugfixes that prevent hard oopses for people
with special cards, that the developers did not have.
--
Greetings Michael.
^ permalink raw reply
* Re: Initial benchmarks of some VJ ideas [mmap memcpy vs copy_to_user].
From: Evgeniy Polyakov @ 2006-05-11 8:30 UTC (permalink / raw)
To: David S. Miller; +Cc: netdev, caitlinb, kelly, rusty
In-Reply-To: <20060511.000721.60889163.davem@davemloft.net>
On Thu, May 11, 2006 at 12:07:21AM -0700, David S. Miller (davem@davemloft.net) wrote:
> You can test with single stream, but then you are only testing
> in-cache case. Try several thousand sockets and real load from many
> unique source systems, it becomes interesting then.
Route lookup is _additional_ cost for the system, but, as far as I
understand, netchannels are supposed to help with data processing, not
with destination point selection. It must have route lookups,
socket(netchannel) lookups, they just will be in other place.
I can test system with large number of streams, but unfortunately only
from small number of different src/dst ip addresses, so I can not
benchmark route lookup performance in layered design.
> From profiles of heavily used web server, what shows up is bulk of cpu
> being in socket demux and tcp_ack(). Next bubble is routing cache.
> I have not seen good profiles from a heavy web server employing any
> real use of netfilter, that would be interesting as well.
I have several oprofiles of static test web server which does 2.5k
requests/sec with about 3000 sockets created/removed per second. All
connections are very tiny.
Machines are in LAN, so no heavy route lookups, but socket lookup is quite
heavy. The most heavyweight network function is tcp_v4_rcv() (number 15),
next one is __alloc_skb() (25'th place), __kfree_skb() (35'th place).
netif_receive_skb() at 63, ip_rcv() - 80'th place.
tcp_ack() at 99. No *inet_lookup at all.
I do understand that it is synthetic benchmark, but it is not so rare
usage case.
--
Evgeniy Polyakov
^ permalink raw reply
* Re: [RFC PATCH 34/35] Add the Xen virtual network device driver.
From: Andi Kleen @ 2006-05-11 9:47 UTC (permalink / raw)
To: Keir Fraser, tytso
Cc: xen-devel, Herbert Xu, virtualization, netdev, rdreier,
linux-kernel, chrisw, ian.pratt, shemminger
In-Reply-To: <fb99d7085b85310ef7d423a8f135db32@cl.cam.ac.uk>
On Thursday 11 May 2006 09:49, Keir Fraser wrote:
> On 11 May 2006, at 01:33, Herbert Xu wrote:
> >> But if sampling virtual events for randomness is really unsafe (is it
> >> really?) then native guests in Xen would also get bad random numbers
> >> and this would need to be somehow addressed.
> >
> > Good point. I wonder what VMWare does in this situation.
>
> Well, there's not much they can do except maybe jitter interrupt
> delivery. I doubt they do that though.
>
> The original complaint in our case was that we take entropy from
> interrupts caused by other local VMs, as well as external sources.
> There was a feeling that the former was more predictable and could form
> the basis of an attack. I have to say I'm unconvinced: I don't really
> see that it's significantly easier to inject precisely-timed interrupts
> into a local VM. Certainly not to better than +/- a few microseconds.
> As long as you add cycle-counter info to the entropy pool, the least
> significant bits of that will always be noise.
I think I agree - e.g. i would expect the virtual interrupts to have
enough jitter too. Maybe it would be good if someone could
run a few statistics on the resulting numbers?
Ok the randomness added doesn't consist only of the least significant
bits. Currently it adds jiffies+full 32bit cycle count. I guess if it was
a real problem the code could be changed to leave out the jiffies and
only add maybe a 8 bit word from the low bits. But that would only
help for the para case because the algorithm for native guests
cannot be changed.
> 2. An entropy front/back is tricky -- how do we decide how much
> entropy to pull from domain0? How much should domain0 be prepared to
> give other domains? How easy is it to DoS domain0 by draining its
> entropy pool? Yuk.
I claim (without having read any code) that in theory you need to have solved
that problem already in the vTPM @)
-Andi
^ permalink raw reply
* Re: [PATCH wireless-dev] d80211: Add support for user space clientMLME
From: Johannes Berg @ 2006-05-11 11:41 UTC (permalink / raw)
To: Jouni Malinen; +Cc: Jiri Benc, John W. Linville, netdev, jkmaline
In-Reply-To: <20060510171749.GH23571@instant802.com>
[-- Attachment #1: Type: text/plain, Size: 1314 bytes --]
On Wed, 2006-05-10 at 10:17 -0700, Jouni Malinen wrote:
> This is still somewhat open, but at minimum, there needs to be a
> mechanism for receiving and sending management frames from user space.
> d80211 uses a "management netdev" for this currently (the same one that
> was used before with hostapd for AP mode). In addition to that,
> wpa_supplicant expect to be able to read list of support channels and TX
> rates (get_hw_feature_data handler in driver wrapper) and to be able to
> add and remove STA entries (e.g., for TX rate control and association
> status validation in kernel code).
Right.
> Currently, scanning is done simply by setting the channel with
> SIOCSIWFREQ and listening for management frames. However, the goal is to
> provide simple atomic operations that user space programs can request
> the kernel code to do. This would cover not only scanning, but also some
> other needs like IEEE 802.11k radio measurements. These operations could
> be something like "stop transmit, move to channel 5, report received
> management frames, record noise level, do this for 5 ms, return to
> operational channel, enable transmit".
Yeah, we talked about that. I suppose softmac will never support the
current interface, we'll just design a new one and use that.
johannes
[-- Attachment #2: This is a digitally signed message part --]
[-- Type: application/pgp-signature, Size: 793 bytes --]
^ permalink raw reply
* Re: IPv6 connect() from site-local to global IPv6 address.
From: Kazunori Miyazawa @ 2006-05-11 12:54 UTC (permalink / raw)
To: David Woodhouse
Cc: Rick Jones, YOSHIFUJI Hideaki / 吉藤英明,
netdev
In-Reply-To: <1147114080.2885.164.camel@hades.cambridge.redhat.com>
Hi,
I lost some mails on the list because of my network trouble.
This might not be a correct thread to reply. Sorry.
Anyway, I traced the probelem.
My test environment likes:
The host in my network could reach to the global network via NAT-T on IPv4.
But it could not reach to the global network on IPv6 because router did not have
the default route.
The radvd on the router advertised a global scope prefix for the hosts.
The hosts accordingly have a global scoped address.
DNS server returned both AAAA and A of the target host(server).
The router and the host is Ubuntu 5.10 with the kernel 2.6.16.9.
I tested with these steps:
1. I did "dig" to check that the host could got AAAA address.
2. I did ping6 to check that the host received dest unreach
with no route from the router.
3. I run "evalution" and connected to my server which have AAAA and A.
It falled back to IPv4 and it could connect the server via IPv4 network.
It also falled back by "Time exceeded". My evolution version is 2.4.1.
Of course, when I added IPv6 default route, it connected via IPv6 network.
I think they works well as far as ICMPv6 error messages can be received.
I did not test in the environment in which ICMPv6 error messages are filtered.
Best regards,
David Woodhouse wrote:
> On Mon, 2006-05-08 at 09:44 -0700, Rick Jones wrote:
>
>>Or get the applications fixed no? Kludging around application bugs
>>sounds a bit like the "Fram Oil Filter" commercial where the mechanic is
>>grinning while he says "You can pay me now, or you can pay be later." As
>>in pay for the slightly more expensive oil filter now, or engine repair
>>later.
>
>
> Well, obviously. That's _why_ I want to deploy IPv6 and get it tested.
> But I used to be able to do this without actually breaking the network,
> and without being told to _stop_ running radvd because it breaks things.
>
>
>>Other than fixing the applications that only take the first response
>>(isn't that a generic application bug going back nearly decades now?
>>amazing how things stay the same isn't it) Can you run a caching-only
>>name server at the edge that filters-out the IPv6 responses so your
>>systems never see Global IPV6 responses?
>
>
> I don't think that kind of answer is going to be sufficient to persuade
> Uli to switch back from favouring IPv4 over IPv6. That's done the trick,
> admittedly -- by ensuring that we get _no_ testing of IPv6 unless we run
> with IPv6-only networking :)
>
--
Kazunori Miyazawa
^ permalink raw reply
* [NET_SCHED]: HFSC: fix thinko in hfsc_adjust_levels()
From: Patrick McHardy @ 2006-05-11 14:56 UTC (permalink / raw)
To: David S. Miller; +Cc: Linux Netdev List
[-- Attachment #1: Type: text/plain, Size: 0 bytes --]
[-- Attachment #2: x --]
[-- Type: text/plain, Size: 1098 bytes --]
[NET_SCHED]: HFSC: fix thinko in hfsc_adjust_levels()
When deleting the last child the level of a class should drop to zero.
Noticed by Andreas Mueller <andreas@stapelspeicher.org>
Signed-off-by: Patrick McHardy <kaber@trash.net>
---
commit c75053e281212b5ed3990a0aaced865db7e456d2
tree be2c674d4545ea41200fc5c57d53a03cb0672a93
parent 0e44dc383787b472a7f13564c6bd8a44cc07d408
author Patrick McHardy <kaber@trash.net> Thu, 11 May 2006 10:29:30 +0200
committer Patrick McHardy <kaber@trash.net> Thu, 11 May 2006 10:29:30 +0200
net/sched/sch_hfsc.c | 6 +++---
1 files changed, 3 insertions(+), 3 deletions(-)
diff --git a/net/sched/sch_hfsc.c b/net/sched/sch_hfsc.c
index 91132f6..f1c7bd2 100644
--- a/net/sched/sch_hfsc.c
+++ b/net/sched/sch_hfsc.c
@@ -974,10 +974,10 @@ hfsc_adjust_levels(struct hfsc_class *cl
do {
level = 0;
list_for_each_entry(p, &cl->children, siblings) {
- if (p->level > level)
- level = p->level;
+ if (p->level >= level)
+ level = p->level + 1;
}
- cl->level = level + 1;
+ cl->level = level;
} while ((cl = cl->cl_parent) != NULL);
}
^ permalink raw reply related
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