* [PATCH] [DM9000] Add support for big-endian hosts
From: Laurent Pinchart @ 2007-08-14 11:22 UTC (permalink / raw)
To: netdev; +Cc: Ben Dooks
This patch splits the receive status in 8bit wide fields and convert the
packet length from little endian to CPU byte order.
Signed-off-by: Laurent Pinchart <laurentp@cse-semaphore.com>
---
drivers/net/dm9000.c | 13 +++++++------
1 files changed, 7 insertions(+), 6 deletions(-)
diff --git a/drivers/net/dm9000.c b/drivers/net/dm9000.c
index 264fa0e..ee578d9 100644
--- a/drivers/net/dm9000.c
+++ b/drivers/net/dm9000.c
@@ -879,7 +879,8 @@ dm9000_timer(unsigned long data)
}
struct dm9000_rxhdr {
- u16 RxStatus;
+ u8 RxPktReady;
+ u8 RxStatus;
u16 RxLen;
} __attribute__((__packed__));
@@ -920,7 +921,7 @@ dm9000_rx(struct net_device *dev)
(db->inblk)(db->io_data, &rxhdr, sizeof(rxhdr));
- RxLen = rxhdr.RxLen;
+ RxLen = le16_to_cpu(rxhdr.RxLen);
/* Packet Status check */
if (RxLen < 0x40) {
@@ -932,17 +933,17 @@ dm9000_rx(struct net_device *dev)
PRINTK1("RST: RX Len:%x\n", RxLen);
}
- if (rxhdr.RxStatus & 0xbf00) {
+ if (rxhdr.RxStatus & 0xbf) {
GoodPacket = false;
- if (rxhdr.RxStatus & 0x100) {
+ if (rxhdr.RxStatus & 0x01) {
PRINTK1("fifo error\n");
db->stats.rx_fifo_errors++;
}
- if (rxhdr.RxStatus & 0x200) {
+ if (rxhdr.RxStatus & 0x02) {
PRINTK1("crc error\n");
db->stats.rx_crc_errors++;
}
- if (rxhdr.RxStatus & 0x8000) {
+ if (rxhdr.RxStatus & 0x80) {
PRINTK1("length error\n");
db->stats.rx_length_errors++;
}
--
1.5.0
--
Laurent Pinchart
CSE Semaphore Belgium
Chaussée de Bruxelles, 732A
B-1410 Waterloo
Belgium
T +32 (2) 387 42 59
F +32 (2) 387 42 75
^ permalink raw reply related
* Re: Block device throttling [Re: Distributed storage.]
From: Evgeniy Polyakov @ 2007-08-14 11:50 UTC (permalink / raw)
To: Daniel Phillips
Cc: Jens Axboe, netdev, linux-kernel, linux-fsdevel, Peter Zijlstra
In-Reply-To: <200708140435.44979.phillips@phunq.net>
On Tue, Aug 14, 2007 at 04:35:43AM -0700, Daniel Phillips (phillips@phunq.net) wrote:
> On Tuesday 14 August 2007 04:30, Evgeniy Polyakov wrote:
> > > And it will not solve the deadlock problem in general. (Maybe it
> > > works for your virtual device, but I wonder...) If the virtual
> > > device allocates memory during generic_make_request then the memory
> > > needs to be throttled.
> >
> > Daniel, if device process bio by itself, it has a limit and thus it
> > will wait in generic_make_request()
>
> What will make it wait?
gneric_make_request() for given block device.
Example:
virt_device -> do_smth_with_bio ->bio_endio().
|
/ \
phys0 phys1
Each of three devices above works with bio, each one eventually calls
bio_endio() and bio->bi_bdev will be one of the three above devices.
Thus, when system calls generic_make_request(bio->bi_bdev == virt_device),
one of the three limits will be charged, depending on the fact, that
virtual device forward bio to physical devices or not. Actually virtual
device limit will be charged too first, but if bio is forwarded, its
portion will be reduced from virtual device's limit.
Now, if virtual device allocates bio itself (like device mapper), then
this new bio will be forwarded to physical devices via
gneric_make_request() and thus it will sleep in the physical device's
queue, if it is filled.
So, if each of three devices has a limit of 10 bios, then actual number
of bios in flight is maximum 3 * 10, since each device will be charged
up to _its_ maximum limit, not limit for the first device in the chain.
So, you set 10 to virtual device and its can process bio itself (like
send it to network), then this is number of bios in flight, which are
processed by _this_ device and not forwarded further. Actual number of
bios you can flush into virtual device is its own limit plus limits of
all physical devices atached to it.
--
Evgeniy Polyakov
^ permalink raw reply
* Re: Block device throttling [Re: Distributed storage.]
From: Daniel Phillips @ 2007-08-14 11:35 UTC (permalink / raw)
To: Evgeniy Polyakov
Cc: Jens Axboe, netdev, linux-kernel, linux-fsdevel, Peter Zijlstra
In-Reply-To: <20070814113039.GA20780@2ka.mipt.ru>
On Tuesday 14 August 2007 04:30, Evgeniy Polyakov wrote:
> > And it will not solve the deadlock problem in general. (Maybe it
> > works for your virtual device, but I wonder...) If the virtual
> > device allocates memory during generic_make_request then the memory
> > needs to be throttled.
>
> Daniel, if device process bio by itself, it has a limit and thus it
> will wait in generic_make_request()
What will make it wait?
^ permalink raw reply
* Re: Block device throttling [Re: Distributed storage.]
From: Evgeniy Polyakov @ 2007-08-14 11:30 UTC (permalink / raw)
To: Daniel Phillips
Cc: Jens Axboe, netdev, linux-kernel, linux-fsdevel, Peter Zijlstra
In-Reply-To: <200708140413.12530.phillips@phunq.net>
On Tue, Aug 14, 2007 at 04:13:10AM -0700, Daniel Phillips (phillips@phunq.net) wrote:
> On Tuesday 14 August 2007 01:46, Evgeniy Polyakov wrote:
> > On Mon, Aug 13, 2007 at 06:04:06AM -0700, Daniel Phillips
> (phillips@phunq.net) wrote:
> > > Perhaps you never worried about the resources that the device
> > > mapper mapping function allocates to handle each bio and so did not
> > > consider this hole significant. These resources can be
> > > significant, as is the case with ddsnap. It is essential to close
> > > that window through with the virtual device's queue limit may be
> > > violated. Not doing so will allow deadlock.
> >
> > This is not a bug, this is special kind of calculation - total limit
> > is number of physical devices multiplied by theirs limits. It was
> > done _on purpose_ to allow different device to have different limits
> > (for example in distributed storage project it is possible to have
> > both remote and local node in the same device, but local device
> > should not have _any_ limit at all, but network one should).
> >
> > Virtual device essentially has _no_ limit. And that as done on
> > purpose.
>
> And it will not solve the deadlock problem in general. (Maybe it works
> for your virtual device, but I wonder...) If the virtual device
> allocates memory during generic_make_request then the memory needs to
> be throttled.
Daniel, if device process bio by itself, it has a limit and thus it will
wait in generic_make_request(), if it queues it to different device,
then the same logic applies there. If virutal device does not process
bio, its limit will always be recharged to underlying devices, and
overall limit is equal to number of physical device (or devices which do
process bio) multiplied by theirs limits. This does _work_ and I showed
example how limits are processed and who and where will sleep. This
solution is not narrow fix, please check my examples I showed before.
> Regards,
>
> Daniel
--
Evgeniy Polyakov
^ permalink raw reply
* [PATCH] [DM9000] External PHY support
From: Laurent Pinchart @ 2007-08-14 11:29 UTC (permalink / raw)
To: netdev; +Cc: Ben Dooks
This patch adds a flag to the DM9000 platform data which, when set,
configures the device to use an external PHY.
Signed-off-by: Laurent Pinchart <laurentp@cse-semaphore.com>
---
drivers/net/dm9000.c | 6 ++++++
include/linux/dm9000.h | 1 +
2 files changed, 7 insertions(+), 0 deletions(-)
diff --git a/drivers/net/dm9000.c b/drivers/net/dm9000.c
index ee578d9..820f0d3 100644
--- a/drivers/net/dm9000.c
+++ b/drivers/net/dm9000.c
@@ -124,6 +124,7 @@ typedef struct board_info {
u16 dbug_cnt;
u8 io_mode; /* 0:word, 2:byte */
u8 phy_addr;
+ unsigned int flags;
void (*inblk)(void __iomem *port, void *data, int length);
void (*outblk)(void __iomem *port, void *data, int length);
@@ -513,6 +514,8 @@ dm9000_probe(struct platform_device *pdev)
if (pdata->dumpblk != NULL)
db->dumpblk = pdata->dumpblk;
+
+ db->flags = pdata->flags;
}
dm9000_reset(db);
@@ -655,6 +658,9 @@ dm9000_init_dm9000(struct net_device *dev)
iow(db, DM9000_GPCR, GPCR_GEP_CNTL); /* Let GPIO0 output */
iow(db, DM9000_GPR, 0); /* Enable PHY */
+ if (db->flags & DM9000_PLATF_EXT_PHY)
+ iow(db, DM9000_NCR, NCR_EXT_PHY);
+
/* Program operating register */
iow(db, DM9000_TCR, 0); /* TX Polling clear */
iow(db, DM9000_BPTR, 0x3f); /* Less 3Kb, 200us */
diff --git a/include/linux/dm9000.h b/include/linux/dm9000.h
index 0008e2a..ea530fd 100644
--- a/include/linux/dm9000.h
+++ b/include/linux/dm9000.h
@@ -19,6 +19,7 @@
#define DM9000_PLATF_8BITONLY (0x0001)
#define DM9000_PLATF_16BITONLY (0x0002)
#define DM9000_PLATF_32BITONLY (0x0004)
+#define DM9000_PLATF_EXT_PHY (0x0008)
/* platfrom data for platfrom device structure's platfrom_data field */
--
1.5.0
--
Laurent Pinchart
CSE Semaphore Belgium
Chaussée de Bruxelles, 732A
B-1410 Waterloo
Belgium
T +32 (2) 387 42 59
F +32 (2) 387 42 75
^ permalink raw reply related
* Re: Block device throttling [Re: Distributed storage.]
From: Daniel Phillips @ 2007-08-14 11:13 UTC (permalink / raw)
To: Evgeniy Polyakov
Cc: Jens Axboe, netdev, linux-kernel, linux-fsdevel, Peter Zijlstra
In-Reply-To: <20070814084625.GA20265@2ka.mipt.ru>
On Tuesday 14 August 2007 01:46, Evgeniy Polyakov wrote:
> On Mon, Aug 13, 2007 at 06:04:06AM -0700, Daniel Phillips
(phillips@phunq.net) wrote:
> > Perhaps you never worried about the resources that the device
> > mapper mapping function allocates to handle each bio and so did not
> > consider this hole significant. These resources can be
> > significant, as is the case with ddsnap. It is essential to close
> > that window through with the virtual device's queue limit may be
> > violated. Not doing so will allow deadlock.
>
> This is not a bug, this is special kind of calculation - total limit
> is number of physical devices multiplied by theirs limits. It was
> done _on purpose_ to allow different device to have different limits
> (for example in distributed storage project it is possible to have
> both remote and local node in the same device, but local device
> should not have _any_ limit at all, but network one should).
>
> Virtual device essentially has _no_ limit. And that as done on
> purpose.
And it will not solve the deadlock problem in general. (Maybe it works
for your virtual device, but I wonder...) If the virtual device
allocates memory during generic_make_request then the memory needs to
be throttled.
Regards,
Daniel
^ permalink raw reply
* Re: Davicom Ethernet (onboard) with many Tx timeouts...
From: Ben Dooks @ 2007-08-14 10:12 UTC (permalink / raw)
To: D?niel Fraga; +Cc: netdev
In-Reply-To: <4jut64-6m7.ln1@tux.abusar.org>
On Wed, Jan 03, 2007 at 10:33:08PM -0200, D?niel Fraga wrote:
> Linux 2.6.19 (but this problem occurs with previous kernels too)
> gcc 4.1.1
> pentium 3
> Module dmfe.ko
>
> dmfe: Davicom DM9xxx net driver, version 1.36.4 (2002-01-17)
hmm, dmfe does not cover the dm9000, a little missleading?
--
Ben (ben@fluff.org, http://www.fluff.org/)
'a smiley only costs 4 bytes'
^ permalink raw reply
* Re: dm9000: add set_mac_address()
From: Ben Dooks @ 2007-08-14 10:10 UTC (permalink / raw)
To: Jeff Garzik; +Cc: Michael Trimarchi, netdev
In-Reply-To: <46BF9304.9080709@pobox.com>
On Sun, Aug 12, 2007 at 07:08:52PM -0400, Jeff Garzik wrote:
> set_mac_address should not write to the SROM, as Michael noted.
>
> The proper operations are:
>
> probe time:
> read MAC address from SROM
>
> dev open (interface up):
> write dev->dev_addr[] to RX filter (or identity) registers
>
> EEPROM update support is available separately, via an ethtool sub-ioctl.
This sounds sensible, I am working on adding ethtool support
and should have a patch available in the next day or so.
--
Ben (ben@fluff.org, http://www.fluff.org/)
'a smiley only costs 4 bytes'
^ permalink raw reply
* Re: [patch 08/18] 3c59x: check return of pci_enable_device()
From: Mark Hindley @ 2007-08-14 9:54 UTC (permalink / raw)
To: Jeff Garzik; +Cc: akpm, netdev, klassert
In-Reply-To: <200708102105.l7AL5Jje008968@imap1.linux-foundation.org>
On Tue, Aug 14, 2007 at 01:33:26AM -0400, Jeff Garzik wrote:
> I would strongly prefer that vortex_up return a value, since all the
> important callers of this function can themselves return an error back
> to the system.
>
> we can definitely return a meaningful return value here, if
> pci_enable_device() fails, and I would rather not apply a patch that
> fails to propagate a serious condition (pci_enable_device failure is
> indeed serious) when it is possible to do so
>
OK. Any comments on this revised version? I have only ignored the return of
vortex_up in vortex_error. It is not immediately clear what to do if
vortex_up still fails there after a pci reset.
Mark
diff --git a/drivers/net/3c59x.c b/drivers/net/3c59x.c
index 001c66d..a1dfd6b 100644
--- a/drivers/net/3c59x.c
+++ b/drivers/net/3c59x.c
@@ -705,7 +705,7 @@ static struct {
static int vortex_probe1(struct device *gendev, void __iomem *ioaddr, int irq,
int chip_idx, int card_idx);
-static void vortex_up(struct net_device *dev);
+static int vortex_up(struct net_device *dev);
static void vortex_down(struct net_device *dev, int final);
static int vortex_open(struct net_device *dev);
static void mdio_sync(void __iomem *ioaddr, int bits);
@@ -841,8 +841,11 @@ static int vortex_resume(struct pci_dev *pdev)
return -EBUSY;
}
if (netif_running(dev)) {
- vortex_up(dev);
- netif_device_attach(dev);
+ err = vortex_up(dev);
+ if (err)
+ return err;
+ else
+ netif_device_attach(dev);
}
}
return 0;
@@ -1484,19 +1487,24 @@ static void vortex_check_media(struct net_device *dev, unsigned int init)
}
}
-static void
+static int
vortex_up(struct net_device *dev)
{
struct vortex_private *vp = netdev_priv(dev);
void __iomem *ioaddr = vp->ioaddr;
unsigned int config;
- int i, mii_reg1, mii_reg5;
+ int i, mii_reg1, mii_reg5, err;
if (VORTEX_PCI(vp)) {
pci_set_power_state(VORTEX_PCI(vp), PCI_D0); /* Go active */
if (vp->pm_state_valid)
pci_restore_state(VORTEX_PCI(vp));
- pci_enable_device(VORTEX_PCI(vp));
+ err = pci_enable_device(VORTEX_PCI(vp));
+ if (err) {
+ printk(KERN_WARNING "%s: Could not enable device \n",
+ dev->name);
+ goto err_out;
+ }
}
/* Before initializing select the active media port. */
@@ -1660,6 +1668,8 @@ vortex_up(struct net_device *dev)
if (vp->cb_fn_base) /* The PCMCIA people are idiots. */
iowrite32(0x8000, vp->cb_fn_base + 4);
netif_start_queue (dev);
+err_out:
+ return err;
}
static int
@@ -1673,7 +1683,7 @@ vortex_open(struct net_device *dev)
if ((retval = request_irq(dev->irq, vp->full_bus_master_rx ?
&boomerang_interrupt : &vortex_interrupt, IRQF_SHARED, dev->name, dev))) {
printk(KERN_ERR "%s: Could not reserve IRQ %d\n", dev->name, dev->irq);
- goto out;
+ goto err;
}
if (vp->full_bus_master_rx) { /* Boomerang bus master. */
@@ -1702,20 +1712,22 @@ vortex_open(struct net_device *dev)
}
}
retval = -ENOMEM;
- goto out_free_irq;
+ goto err_free_irq;
}
/* Wrap the ring. */
vp->rx_ring[i-1].next = cpu_to_le32(vp->rx_ring_dma);
}
- vortex_up(dev);
- return 0;
+ retval = vortex_up(dev);
+ if (!retval)
+ goto out;
-out_free_irq:
+err_free_irq:
free_irq(dev->irq, dev);
-out:
+err:
if (vortex_debug > 1)
printk(KERN_ERR "%s: vortex_open() fails: returning %d\n", dev->name, retval);
+out:
return retval;
}
^ permalink raw reply related
* Re: [PATCH 0/9 Rev3] Implement batching skb API and support in IPoIB
From: Krishna Kumar2 @ 2007-08-14 9:39 UTC (permalink / raw)
To: David Miller
Cc: gaagaan, general, hadi, herbert, jagana, jeff, johnpol, kaber,
kumarkr, mcarlson, mchan, netdev, peter.p.waskiewicz.jr, rdreier,
rick.jones2, Robert.Olsson, shemminger, sri, tgraf, xma
Forgot to mention one thing:
> This fix reduced
> retransmissions from 180,000 to 55,000 or so. When I changed IPoIB
> driver to use iterative sends of each skb instead of creating multiple
> Work Request's, that number went down to 15].
This also reduced TCP No Delay performance from huge percentages like
200-400% and now is almost the same as original code. So fixing this
problem in IPoIB (driver?) will enable to use the multiple Work Request
& Work Completion, rather than limiting batching to single WR/WC.
thanks,
- KK
__________________
Hi Dave,
David Miller <davem@davemloft.net> wrote on 08/08/2007 04:19:00 PM:
> From: Krishna Kumar <krkumar2@in.ibm.com>
> Date: Wed, 08 Aug 2007 15:01:14 +0530
>
> > RESULTS: The performance improvement for TCP No Delay is in the range
of -8%
> > to 320% (with -8% being the sole negative), with many individual
tests
> > giving 50% or more improvement (I think it is to do with the hw
slots
> > getting full quicker resulting in more batching when the queue gets
> > woken). The results for TCP is in the range of -11% to 93%, with
most
> > of the tests (8/12) giving improvements.
>
> Not because I think it obviates your work, but rather because I'm
> curious, could you test a TSO-in-hardware driver converted to
> batching and see how TSO alone compares to batching for a pure
> TCP workload?
>
> I personally don't think it will help for that case at all as
> TSO likely does better job of coalescing the work _and_ reducing
> bus traffic as well as work in the TCP stack.
I used E1000 (guess the choice is OK as e1000_tso returns TRUE. My
hw is 82547GI).
You are right, it doesn't help TSO case at all (infact degrades). Two
things to note though:
- E1000 may not be suitable for adding batching (which is no
longer a new API, as I have changed it already).
- Small skbs where TSO doesn't come into picture still seems to
improve. A couple of cases for large skbs did result in some
improved (like 4K, TCP No Delay, 32 procs).
[Total segments retransmission for original code test run: 2220 & for
new code test run: 1620. So the retransmission problem that I was
getting seems to be an IPoIB bug, though I did have to fix one bug
in my networking component where I was calling qdisc_run(NULL) for
regular xmit path and change to always use batching. The problem is
that skb1 - skb10 may be present in the queue after each of them
failed to be sent out, then net_tx_action fires which batches all of
these into the blist and tries to send them out again, which also
fails (eg tx lock fail or queue full), then the next single skb xmit
will send the latest skb ignoring the 10 skbs that are already waiting
in the batching list. These 10 skbs are sent out only the next time
net_tx_action is called, so out of order skbs result. This fix reduced
retransmissions from 180,000 to 55,000 or so. When I changed IPoIB
driver to use iterative sends of each skb instead of creating multiple
Work Request's, that number went down to 15].
I ran 3 iterations of 45 sec tests (total 1 hour 16 min, but I will
run a longer one tonight). The results are (results in KB/s, and %):
Test Case Org BW New BW % Change
TCP
--------
Size:32 Procs:1 1848 3918 112.01
Size:32 Procs:8 21888 21555 -1.52
Size:32 Procs:32 19317 22433 16.13
Size:256 Procs:1 15584 25991 66.78
Size:256 Procs:8 110937 74565 -32.78
Size:256 Procs:32 105767 98967 -6.42
Size:4096 Procs:1 81910 96073 17.29
Size:4096 Procs:8 113302 94040 -17.00
Size:4096 Procs:32 109664 105522 -3.77
TCP No Delay:
--------------
Size:32 Procs:1 2688 3177 18.19
Size:32 Procs:8 6568 10588 61.20
Size:32 Procs:32 6573 7838 19.24
Size:256 Procs:1 7869 12724 61.69
Size:256 Procs:8 65652 45652 -30.46
Size:256 Procs:32 95114 112279 18.04
Size:4096 Procs:1 95302 84664 -11.16
Size:4096 Procs:8 111119 89111 -19.80
Size:4096 Procs:32 109249 113919 4.27
I will submit Rev4 with suggested changes (including single merged
API) on Thursday after some more testing.
Thanks,
- KK
-
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: 2.4.35-pre1: new e1000 driver breaks old hardware
From: Wolfgang Nothdurft @ 2007-08-14 8:53 UTC (permalink / raw)
To: netdev; +Cc: Kok, Auke
In-Reply-To: <4672B5FD.7070304@intel.com>
Kok, Auke wrote:
> Wolfgang Nothdurft wrote:
>> Hi,
>>
>> with the new e1000 driver version 7.3.20 the onboard gigabit nic 82547EI
>> (8086:1019) doesn't work correctly.
>> After transferring about 100 megabytes over a gigabit link the transfer
>> stopped and I have to reinit the link either by doing a ifconfig down/up
>> or unplugging the network cable.
>> The RxIntDelay is set to 0 like described in the docu. Playing with this
>> Parameter only increases the amount of traffic to be send and the error
>> occurs later.
>
> have you tried (the default) 8000 ? Do you get the same problem when you
> run 2.6.21 with 7.5.5.1 or 7.3.20 ?
>
>> This happens also with the 7.4.35 and 7.5.5 driver from the intel side.
>> The driver 5.7.6 from kernel 2.4.33.3 and the 6.1.16 from intel works
>> very well on this hardware.
>> Also other gigabit nics we use didn't have this problem.
>> Is this issue already known?
>
> this is the first time I have heard this issue.
>
>> Is there any solution yet?
>
> I'm not that good :)
>
> Can you file a bugreport on e1000.sf.net and attach the usual (ethtool
> -e, dmesg, ifconfig -a, lspci -vv) debugging output and problem
> description for us? I'll try to see if I can have our labs setup a repro
> case, which might be hard given the adapter type, but we will do our best.
>
> Auke
> -
> 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
>
Any news about this issue?
The bug report is
http://sourceforge.net/tracker/index.php?func=detail&aid=1739537&group_id=42302&atid=447449
Kind Regards
Wolfgang
--
Wolfgang Nothdurft Wolfgang.Nothdurft@linogate.de
Linogate Internet Technologies fon: +49 (0)821 - 25 96 - 0
^ permalink raw reply
* [ofa-general] Re: [PATCH 0/9 Rev3] Implement batching skb API and support in IPoIB
From: Krishna Kumar2 @ 2007-08-14 9:02 UTC (permalink / raw)
To: David Miller
Cc: jagana, johnpol, gaagaan, jeff, Robert.Olsson, kumarkr, rdreier,
peter.p.waskiewicz.jr, hadi, mcarlson, netdev, general, mchan,
tgraf, sri, shemminger, kaber, herbert
In-Reply-To: <20070808.034900.85820906.davem@davemloft.net>
Hi Dave,
David Miller <davem@davemloft.net> wrote on 08/08/2007 04:19:00 PM:
> From: Krishna Kumar <krkumar2@in.ibm.com>
> Date: Wed, 08 Aug 2007 15:01:14 +0530
>
> > RESULTS: The performance improvement for TCP No Delay is in the range
of -8%
> > to 320% (with -8% being the sole negative), with many individual
tests
> > giving 50% or more improvement (I think it is to do with the hw
slots
> > getting full quicker resulting in more batching when the queue gets
> > woken). The results for TCP is in the range of -11% to 93%, with
most
> > of the tests (8/12) giving improvements.
>
> Not because I think it obviates your work, but rather because I'm
> curious, could you test a TSO-in-hardware driver converted to
> batching and see how TSO alone compares to batching for a pure
> TCP workload?
>
> I personally don't think it will help for that case at all as
> TSO likely does better job of coalescing the work _and_ reducing
> bus traffic as well as work in the TCP stack.
I used E1000 (guess the choice is OK as e1000_tso returns TRUE. My
hw is 82547GI).
You are right, it doesn't help TSO case at all (infact degrades). Two
things to note though:
- E1000 may not be suitable for adding batching (which is no
longer a new API, as I have changed it already).
- Small skbs where TSO doesn't come into picture still seems to
improve. A couple of cases for large skbs did result in some
improved (like 4K, TCP No Delay, 32 procs).
[Total segments retransmission for original code test run: 2220 & for
new code test run: 1620. So the retransmission problem that I was
getting seems to be an IPoIB bug, though I did have to fix one bug
in my networking component where I was calling qdisc_run(NULL) for
regular xmit path and change to always use batching. The problem is
that skb1 - skb10 may be present in the queue after each of them
failed to be sent out, then net_tx_action fires which batches all of
these into the blist and tries to send them out again, which also
fails (eg tx lock fail or queue full), then the next single skb xmit
will send the latest skb ignoring the 10 skbs that are already waiting
in the batching list. These 10 skbs are sent out only the next time
net_tx_action is called, so out of order skbs result. This fix reduced
retransmissions from 180,000 to 55,000 or so. When I changed IPoIB
driver to use iterative sends of each skb instead of creating multiple
Work Request's, that number went down to 15].
I ran 3 iterations of 45 sec tests (total 1 hour 16 min, but I will
run a longer one tonight). The results are (results in KB/s, and %):
Test Case Org BW New BW % Change
TCP
--------
Size:32 Procs:1 1848 3918 112.01
Size:32 Procs:8 21888 21555 -1.52
Size:32 Procs:32 19317 22433 16.13
Size:256 Procs:1 15584 25991 66.78
Size:256 Procs:8 110937 74565 -32.78
Size:256 Procs:32 105767 98967 -6.42
Size:4096 Procs:1 81910 96073 17.29
Size:4096 Procs:8 113302 94040 -17.00
Size:4096 Procs:32 109664 105522 -3.77
TCP No Delay:
--------------
Size:32 Procs:1 2688 3177 18.19
Size:32 Procs:8 6568 10588 61.20
Size:32 Procs:32 6573 7838 19.24
Size:256 Procs:1 7869 12724 61.69
Size:256 Procs:8 65652 45652 -30.46
Size:256 Procs:32 95114 112279 18.04
Size:4096 Procs:1 95302 84664 -11.16
Size:4096 Procs:8 111119 89111 -19.80
Size:4096 Procs:32 109249 113919 4.27
I will submit Rev4 with suggested changes (including single merged
API) on Thursday after some more testing.
Thanks,
- KK
^ permalink raw reply
* Re: Block device throttling [Re: Distributed storage.]
From: Evgeniy Polyakov @ 2007-08-14 8:46 UTC (permalink / raw)
To: Daniel Phillips
Cc: Jens Axboe, netdev, linux-kernel, linux-fsdevel, Peter Zijlstra
In-Reply-To: <200708130604.07154.phillips@phunq.net>
On Mon, Aug 13, 2007 at 06:04:06AM -0700, Daniel Phillips (phillips@phunq.net) wrote:
> Perhaps you never worried about the resources that the device mapper
> mapping function allocates to handle each bio and so did not consider
> this hole significant. These resources can be significant, as is the
> case with ddsnap. It is essential to close that window through with
> the virtual device's queue limit may be violated. Not doing so will
> allow deadlock.
This is not a bug, this is special kind of calculation - total limit is
number of physical devices multiplied by theirs limits. It was done
_on purpose_ to allow different device to have different limits (for
example in distributed storage project it is possible to have both remote
and local node in the same device, but local device should not have _any_
limit at all, but network one should).
Virtual device essentially has _no_ limit. And that as done on purpose.
--
Evgeniy Polyakov
^ permalink raw reply
* Re: [PATCH 6/24] make atomic_read() behave consistently on frv
From: Herbert Xu @ 2007-08-14 7:26 UTC (permalink / raw)
To: Nick Piggin
Cc: paulmck, csnook, dhowells, linux-kernel, linux-arch, torvalds,
netdev, akpm, ak, heiko.carstens, davem, schwidefsky, wensong,
horms, wjiang, cfriesen, zlynx, rpjday, jesper.juhl
In-Reply-To: <46C13EE1.1000707@yahoo.com.au>
On Tue, Aug 14, 2007 at 03:34:25PM +1000, Nick Piggin wrote:
>
> What do you think of this crazy idea?
>
> /* Enforce a compiler barrier for only operations to location X.
> * Call multiple times to provide an ordering between multiple
> * memory locations. Other memory operations can be assumed by
> * the compiler to remain unchanged and may be reordered
> */
> #define order(x) asm volatile("" : "+m" (x))
Yes this is a very good idea. This also makes it explicit
that the coder is depending on this rather than the more
vague connotations of atomic_read.
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]support for USB autosuspend in the asix driver
From: Oliver Neukum @ 2007-08-14 7:22 UTC (permalink / raw)
To: David Brownell; +Cc: Jeff Garzik, netdev
In-Reply-To: <200708132222.13978.david-b@pacbell.net>
Am Dienstag 14 August 2007 schrieb David Brownell:
> On Monday 13 August 2007, Jeff Garzik wrote:
> > Oliver Neukum wrote:
> > > Hi,
> > >
> > > this implements support for USB autosuspend in the asix USB ethernet
> > > driver.
> > >
> > > Regards
> > > Oliver
> > > Signed-off-by: Oliver Neukum <oneukum@suse.de>
> >
> > David, does this look OK to you? I never saw much comment from anybody,
> > and cannot really comment on the USB parts.
>
> I didn't see anything obviously wrong. I presume Oliver tested
> this with actual ASIX hardware ... assuming that, it's OK by me.
I've tested it. It works.
Regards
Oliver
^ permalink raw reply
* Re: [patch]support for USB autosuspend in the asix driver
From: David Brownell @ 2007-08-14 5:22 UTC (permalink / raw)
To: Jeff Garzik; +Cc: Oliver Neukum, netdev
In-Reply-To: <46C13546.8030508@pobox.com>
On Monday 13 August 2007, Jeff Garzik wrote:
> Oliver Neukum wrote:
> > Hi,
> >
> > this implements support for USB autosuspend in the asix USB ethernet
> > driver.
> >
> > Regards
> > Oliver
> > Signed-off-by: Oliver Neukum <oneukum@suse.de>
>
> David, does this look OK to you? I never saw much comment from anybody,
> and cannot really comment on the USB parts.
I didn't see anything obviously wrong. I presume Oliver tested
this with actual ASIX hardware ... assuming that, it's OK by me.
- Dave
>
> Jeff
>
>
>
^ permalink raw reply
* [git patches] net driver fixes
From: Jeff Garzik @ 2007-08-14 6:10 UTC (permalink / raw)
To: Andrew Morton, Linus Torvalds; +Cc: netdev, LKML
Minor stuff except for the xen-netfront fix. e1000 change is an
adds-pci-ids-only change.
Please pull from 'upstream-linus' branch of
master.kernel.org:/pub/scm/linux/kernel/git/jgarzik/netdev-2.6.git upstream-linus
to receive the following updates:
MAINTAINERS | 6 ++++++
drivers/net/3c59x.c | 1 +
drivers/net/ax88796.c | 5 +++--
drivers/net/e1000/e1000_ethtool.c | 2 ++
drivers/net/e1000/e1000_hw.c | 5 +++++
drivers/net/e1000/e1000_hw.h | 3 +++
drivers/net/e1000/e1000_main.c | 4 ++++
drivers/net/myri10ge/myri10ge.c | 25 ++++++++++++++++++-------
drivers/net/natsemi.c | 3 +++
drivers/net/via-rhine.c | 6 ++++++
drivers/net/xen-netfront.c | 7 ++++---
11 files changed, 55 insertions(+), 12 deletions(-)
Andrew Morton (2):
ax88796 printk fixes
natsemi: fix netdev error acounting
Auke Kok (1):
e1000: Add device IDs of new 82571 board variants
Brice Goglin (1):
myri10ge: Use the pause counter to avoid a needless device reset
Dustin Marquess (1):
via-rhine: disable rx_copybreak on archs that don't allow unaligned DMA access
Jeremy Fitzhardinge (1):
xen-netfront: Avoid deref'ing skbafter it is potentially freed.
Steffen Klassert (2):
3c59x: fix duplex configuration
3c59x maintainer
diff --git a/MAINTAINERS b/MAINTAINERS
index d3a0684..e4dde7f 100644
--- a/MAINTAINERS
+++ b/MAINTAINERS
@@ -97,6 +97,12 @@ M: philb@gnu.org
L: netdev@vger.kernel.org
S: Maintained
+3C59X NETWORK DRIVER
+P: Steffen Klassert
+M: klassert@mathematik.tu-chemnitz.de
+L: netdev@vger.kernel.org
+S: Maintained
+
3CR990 NETWORK DRIVER
P: David Dillow
M: dave@thedillows.org
diff --git a/drivers/net/3c59x.c b/drivers/net/3c59x.c
index 001c66d..a8c0f43 100644
--- a/drivers/net/3c59x.c
+++ b/drivers/net/3c59x.c
@@ -1555,6 +1555,7 @@ vortex_up(struct net_device *dev)
mii_reg1 = mdio_read(dev, vp->phys[0], MII_BMSR);
mii_reg5 = mdio_read(dev, vp->phys[0], MII_LPA);
vp->partner_flow_ctrl = ((mii_reg5 & 0x0400) != 0);
+ vp->mii.full_duplex = vp->full_duplex;
vortex_check_media(dev, 1);
}
diff --git a/drivers/net/ax88796.c b/drivers/net/ax88796.c
index 83da177..90e0734 100644
--- a/drivers/net/ax88796.c
+++ b/drivers/net/ax88796.c
@@ -821,8 +821,9 @@ static int ax_probe(struct platform_device *pdev)
dev->base_addr = (unsigned long)ei_status.mem;
if (ei_status.mem == NULL) {
- dev_err(&pdev->dev, "Cannot ioremap area (%08zx,%08zx)\n",
- res->start, res->end);
+ dev_err(&pdev->dev, "Cannot ioremap area (%08llx,%08llx)\n",
+ (unsigned long long)res->start,
+ (unsigned long long)res->end);
ret = -ENXIO;
goto exit_req;
diff --git a/drivers/net/e1000/e1000_ethtool.c b/drivers/net/e1000/e1000_ethtool.c
index c90c92e..4c3785c 100644
--- a/drivers/net/e1000/e1000_ethtool.c
+++ b/drivers/net/e1000/e1000_ethtool.c
@@ -1706,6 +1706,7 @@ static int e1000_wol_exclusion(struct e1000_adapter *adapter, struct ethtool_wol
case E1000_DEV_ID_82545EM_COPPER:
case E1000_DEV_ID_82546GB_QUAD_COPPER:
case E1000_DEV_ID_82546GB_PCIE:
+ case E1000_DEV_ID_82571EB_SERDES_QUAD:
/* these don't support WoL at all */
wol->supported = 0;
break;
@@ -1723,6 +1724,7 @@ static int e1000_wol_exclusion(struct e1000_adapter *adapter, struct ethtool_wol
retval = 0;
break;
case E1000_DEV_ID_82571EB_QUAD_COPPER:
+ case E1000_DEV_ID_82571EB_QUAD_FIBER:
case E1000_DEV_ID_82571EB_QUAD_COPPER_LOWPROFILE:
case E1000_DEV_ID_82546GB_QUAD_COPPER_KSP3:
/* quad port adapters only support WoL on port A */
diff --git a/drivers/net/e1000/e1000_hw.c b/drivers/net/e1000/e1000_hw.c
index 9be4469..ba120f7 100644
--- a/drivers/net/e1000/e1000_hw.c
+++ b/drivers/net/e1000/e1000_hw.c
@@ -384,7 +384,10 @@ e1000_set_mac_type(struct e1000_hw *hw)
case E1000_DEV_ID_82571EB_COPPER:
case E1000_DEV_ID_82571EB_FIBER:
case E1000_DEV_ID_82571EB_SERDES:
+ case E1000_DEV_ID_82571EB_SERDES_DUAL:
+ case E1000_DEV_ID_82571EB_SERDES_QUAD:
case E1000_DEV_ID_82571EB_QUAD_COPPER:
+ case E1000_DEV_ID_82571EB_QUAD_FIBER:
case E1000_DEV_ID_82571EB_QUAD_COPPER_LOWPROFILE:
hw->mac_type = e1000_82571;
break;
@@ -485,6 +488,8 @@ e1000_set_media_type(struct e1000_hw *hw)
case E1000_DEV_ID_82545GM_SERDES:
case E1000_DEV_ID_82546GB_SERDES:
case E1000_DEV_ID_82571EB_SERDES:
+ case E1000_DEV_ID_82571EB_SERDES_DUAL:
+ case E1000_DEV_ID_82571EB_SERDES_QUAD:
case E1000_DEV_ID_82572EI_SERDES:
case E1000_DEV_ID_80003ES2LAN_SERDES_DPT:
hw->media_type = e1000_media_type_internal_serdes;
diff --git a/drivers/net/e1000/e1000_hw.h b/drivers/net/e1000/e1000_hw.h
index bd000b8..fe87146 100644
--- a/drivers/net/e1000/e1000_hw.h
+++ b/drivers/net/e1000/e1000_hw.h
@@ -475,7 +475,10 @@ int32_t e1000_check_phy_reset_block(struct e1000_hw *hw);
#define E1000_DEV_ID_82571EB_FIBER 0x105F
#define E1000_DEV_ID_82571EB_SERDES 0x1060
#define E1000_DEV_ID_82571EB_QUAD_COPPER 0x10A4
+#define E1000_DEV_ID_82571EB_QUAD_FIBER 0x10A5
#define E1000_DEV_ID_82571EB_QUAD_COPPER_LOWPROFILE 0x10BC
+#define E1000_DEV_ID_82571EB_SERDES_DUAL 0x10D9
+#define E1000_DEV_ID_82571EB_SERDES_QUAD 0x10DA
#define E1000_DEV_ID_82572EI_COPPER 0x107D
#define E1000_DEV_ID_82572EI_FIBER 0x107E
#define E1000_DEV_ID_82572EI_SERDES 0x107F
diff --git a/drivers/net/e1000/e1000_main.c b/drivers/net/e1000/e1000_main.c
index f48b659..4a22595 100644
--- a/drivers/net/e1000/e1000_main.c
+++ b/drivers/net/e1000/e1000_main.c
@@ -100,6 +100,7 @@ static struct pci_device_id e1000_pci_tbl[] = {
INTEL_E1000_ETHERNET_DEVICE(0x1099),
INTEL_E1000_ETHERNET_DEVICE(0x109A),
INTEL_E1000_ETHERNET_DEVICE(0x10A4),
+ INTEL_E1000_ETHERNET_DEVICE(0x10A5),
INTEL_E1000_ETHERNET_DEVICE(0x10B5),
INTEL_E1000_ETHERNET_DEVICE(0x10B9),
INTEL_E1000_ETHERNET_DEVICE(0x10BA),
@@ -107,6 +108,8 @@ static struct pci_device_id e1000_pci_tbl[] = {
INTEL_E1000_ETHERNET_DEVICE(0x10BC),
INTEL_E1000_ETHERNET_DEVICE(0x10C4),
INTEL_E1000_ETHERNET_DEVICE(0x10C5),
+ INTEL_E1000_ETHERNET_DEVICE(0x10D9),
+ INTEL_E1000_ETHERNET_DEVICE(0x10DA),
/* required last entry */
{0,}
};
@@ -1096,6 +1099,7 @@ e1000_probe(struct pci_dev *pdev,
break;
case E1000_DEV_ID_82546GB_QUAD_COPPER_KSP3:
case E1000_DEV_ID_82571EB_QUAD_COPPER:
+ case E1000_DEV_ID_82571EB_QUAD_FIBER:
case E1000_DEV_ID_82571EB_QUAD_COPPER_LOWPROFILE:
/* if quad port adapter, disable WoL on all but port A */
if (global_quad_port_a != 0)
diff --git a/drivers/net/myri10ge/myri10ge.c b/drivers/net/myri10ge/myri10ge.c
index deca653..ae9bb7b 100644
--- a/drivers/net/myri10ge/myri10ge.c
+++ b/drivers/net/myri10ge/myri10ge.c
@@ -191,6 +191,7 @@ struct myri10ge_priv {
struct timer_list watchdog_timer;
int watchdog_tx_done;
int watchdog_tx_req;
+ int watchdog_pause;
int watchdog_resets;
int tx_linearized;
int pause;
@@ -2800,6 +2801,7 @@ static void myri10ge_watchdog(struct work_struct *work)
static void myri10ge_watchdog_timer(unsigned long arg)
{
struct myri10ge_priv *mgp;
+ u32 rx_pause_cnt;
mgp = (struct myri10ge_priv *)arg;
@@ -2816,19 +2818,28 @@ static void myri10ge_watchdog_timer(unsigned long arg)
myri10ge_fill_thresh)
mgp->rx_big.watchdog_needed = 0;
}
+ rx_pause_cnt = ntohl(mgp->fw_stats->dropped_pause);
if (mgp->tx.req != mgp->tx.done &&
mgp->tx.done == mgp->watchdog_tx_done &&
- mgp->watchdog_tx_req != mgp->watchdog_tx_done)
+ mgp->watchdog_tx_req != mgp->watchdog_tx_done) {
/* nic seems like it might be stuck.. */
- schedule_work(&mgp->watchdog_work);
- else
- /* rearm timer */
- mod_timer(&mgp->watchdog_timer,
- jiffies + myri10ge_watchdog_timeout * HZ);
-
+ if (rx_pause_cnt != mgp->watchdog_pause) {
+ if (net_ratelimit())
+ printk(KERN_WARNING "myri10ge %s:"
+ "TX paused, check link partner\n",
+ mgp->dev->name);
+ } else {
+ schedule_work(&mgp->watchdog_work);
+ return;
+ }
+ }
+ /* rearm timer */
+ mod_timer(&mgp->watchdog_timer,
+ jiffies + myri10ge_watchdog_timeout * HZ);
mgp->watchdog_tx_done = mgp->tx.done;
mgp->watchdog_tx_req = mgp->tx.req;
+ mgp->watchdog_pause = rx_pause_cnt;
}
static int myri10ge_probe(struct pci_dev *pdev, const struct pci_device_id *ent)
diff --git a/drivers/net/natsemi.c b/drivers/net/natsemi.c
index 6bb48ba..b47a12d 100644
--- a/drivers/net/natsemi.c
+++ b/drivers/net/natsemi.c
@@ -2438,13 +2438,16 @@ static void netdev_error(struct net_device *dev, int intr_status)
dev->name);
}
np->stats.rx_fifo_errors++;
+ np->stats.rx_errors++;
}
/* Hmmmmm, it's not clear how to recover from PCI faults. */
if (intr_status & IntrPCIErr) {
printk(KERN_NOTICE "%s: PCI error %#08x\n", dev->name,
intr_status & IntrPCIErr);
np->stats.tx_fifo_errors++;
+ np->stats.tx_errors++;
np->stats.rx_fifo_errors++;
+ np->stats.rx_errors++;
}
spin_unlock(&np->lock);
}
diff --git a/drivers/net/via-rhine.c b/drivers/net/via-rhine.c
index c3fe230..b56dff2 100644
--- a/drivers/net/via-rhine.c
+++ b/drivers/net/via-rhine.c
@@ -42,7 +42,13 @@ static int max_interrupt_work = 20;
/* Set the copy breakpoint for the copy-only-tiny-frames scheme.
Setting to > 1518 effectively disables this feature. */
+#if defined(__alpha__) || defined(__arm__) || defined(__hppa__) \
+ || defined(CONFIG_SPARC) || defined(__ia64__) \
+ || defined(__sh__) || defined(__mips__)
+static int rx_copybreak = 1518;
+#else
static int rx_copybreak;
+#endif
/* Work-around for broken BIOSes: they are unable to get the chip back out of
power state D3 so PXE booting fails. bootparam(7): via-rhine.avoid_D3=1 */
diff --git a/drivers/net/xen-netfront.c b/drivers/net/xen-netfront.c
index 489f69c..4445810 100644
--- a/drivers/net/xen-netfront.c
+++ b/drivers/net/xen-netfront.c
@@ -566,6 +566,10 @@ static int xennet_start_xmit(struct sk_buff *skb, struct net_device *dev)
if (notify)
notify_remote_via_irq(np->netdev->irq);
+ np->stats.tx_bytes += skb->len;
+ np->stats.tx_packets++;
+
+ /* Note: It is not safe to access skb after xennet_tx_buf_gc()! */
xennet_tx_buf_gc(dev);
if (!netfront_tx_slot_available(np))
@@ -573,9 +577,6 @@ static int xennet_start_xmit(struct sk_buff *skb, struct net_device *dev)
spin_unlock_irq(&np->tx_lock);
- np->stats.tx_bytes += skb->len;
- np->stats.tx_packets++;
-
return 0;
drop:
^ permalink raw reply related
* Re: [PATCH] e1000: Add device IDs of new 82571 board variants
From: Jeff Garzik @ 2007-08-14 5:54 UTC (permalink / raw)
To: Auke Kok; +Cc: netdev, bruce.w.allan, john.ronciak
In-Reply-To: <20070809210934.19268.45172.stgit@localhost.localdomain>
Auke Kok wrote:
> This patch adds support for 2 new board variants:
> - A Quad port fiber 82571 board
> - A blade version of the 82571 quad copper board
>
> Signed-off-by: Auke Kok <auke-jan.h.kok@intel.com>
> ---
>
> drivers/net/e1000/e1000_ethtool.c | 2 ++
> drivers/net/e1000/e1000_hw.c | 5 +++++
> drivers/net/e1000/e1000_hw.h | 3 +++
> drivers/net/e1000/e1000_main.c | 4 ++++
> 4 files changed, 14 insertions(+), 0 deletions(-)
applied
^ permalink raw reply
* Re: [PATCH] xen-netfront: remove dead code
From: Jeff Garzik @ 2007-08-14 5:52 UTC (permalink / raw)
To: Jeremy Fitzhardinge
Cc: Linus Torvalds, Linux Kernel Mailing List, NetDev, Adrian Bunk,
Michal Piotrowski
In-Reply-To: <46B8EA9A.5020704@goop.org>
Jeremy Fitzhardinge wrote:
> This patch removes some residual dead code left over from removing the
> "flip" receive mode. This patch doesn't change the generated output
> at all, since gcc already realized it was dead.
>
> This resolves the "regression" reported by Adrian.
>
> Signed-off-by: Jeremy Fitzhardinge <jeremy@xensource.com>
> Cc: Adrian Bunk <bunk@stusta.de>
> Cc: Michal Piotrowski <michal.k.k.piotrowski@gmail.com>
applied
^ permalink raw reply
* Re: [PATCH] xen-netfront: Avoid deref'ing skbafter it is potentially freed.
From: Jeff Garzik @ 2007-08-14 5:51 UTC (permalink / raw)
To: Jeremy Fitzhardinge; +Cc: NetDev, Keir Fraser, Linux Kernel Mailing List
In-Reply-To: <46C0B6FD.7020701@goop.org>
Jeremy Fitzhardinge wrote:
> xennet_tx_bug_gc can free the skb before we use it, so make sure we don't.
>
> Jeff, this is -rc material.
>
> Signed-off-by: Keir Fraser <keir@xensource.com>
> Signed-off-by: Jeremy Fitzhardinge <jeremy@xensource.com>
> Cc: Jeff Garzik <jeff@garzik.org>
applied
^ permalink raw reply
* Re: [PATCH] drivers/net/3c505: Convert to generic boolean
From: Jeff Garzik @ 2007-08-14 5:50 UTC (permalink / raw)
To: Richard Knutsson; +Cc: philb, netdev, kernel-janitors, linux-kernel
In-Reply-To: <20070813234814.13259.28175.sendpatchset@thinktank.campus.ltu.se>
Richard Knutsson wrote:
> Convert to generic boolean
>
> Signed-off-by: Richard Knutsson <ricknu-0@student.ltu.se>
> ---
> Compile-tested with all(yes|mod|no)config on x86(|_64) & sparc(|64)
> Diffed against Linus' git-tree.
> Sent 2007-05-01, no replys
applied
^ permalink raw reply
* Re: [PATCH] drivers/net/tokenring: Convert to generic boolean
From: Jeff Garzik @ 2007-08-14 5:50 UTC (permalink / raw)
To: Richard Knutsson; +Cc: mikep, netdev, kernel-janitors, linux-kernel
In-Reply-To: <20070814000543.13576.62289.sendpatchset@thinktank.campus.ltu.se>
Richard Knutsson wrote:
> Convert to generic boolean
>
> Signed-off-by: Richard Knutsson <ricknu-0@student.ltu.se>
> ---
> Compile-tested with all(yes|mod|no)config on x86(|_64) & sparc(|64)
> Diffed against Linus' git-tree.
> Sent 2007-05-01, no replys
applied
^ permalink raw reply
* Re: drivers/net/tokenring/3c359.c
From: Jeff Garzik @ 2007-08-14 5:50 UTC (permalink / raw)
To: surya.prabhakar; +Cc: mikep, netdev, linux-tr, Linux Kernel, kernel-janitors
In-Reply-To: <1187000010.29518.27.camel@bluegenie>
Surya Prabhakar N wrote:
> Hi,
> Replacing kmalloc with kzalloc and cleaning up memset in
> drivers/net/tokenring/3c359.c
>
>
> Signed-off-by: Surya Prabhakar <surya.prabhakar@wipro.com>
applied
^ permalink raw reply
* Re: [patch 06/18] PCI-X/PCI-Express read control interfaces: use them in myrinet
From: Brice Goglin @ 2007-08-14 5:49 UTC (permalink / raw)
To: Jeff Garzik; +Cc: akpm, netdev, peter.oruba, rolandd, shemminger
In-Reply-To: <46C13DE5.2070107@garzik.org>
Jeff Garzik wrote:
> akpm@linux-foundation.org wrote:
>> From: "Peter Oruba" <peter.oruba@amd.com>
>>
>> These driver changes incorporate the proposed PCI-X / PCI-Express
>> read byte
>> count interface. Reading and setting those valuse doesn't take place
>> "manually", instead wrapping functions are called to allow quirks for
>> some
>> PCI bridges.
>>
>
> I presume Brice will resend this one to me, next time he pushes...
Ok, I'll take care of it.
Brice
^ permalink raw reply
* Re: [PATCH 13/13] cxgb3 - test MSI capabilities
From: Jeff Garzik @ 2007-08-14 5:47 UTC (permalink / raw)
To: Divy Le Ray; +Cc: netdev, linux-kernel, swise
In-Reply-To: <20070811063036.8239.27320.stgit@speedy5>
Divy Le Ray wrote:
> From: Divy Le Ray <divy@chelsio.com>
>
> Check that the HW in really in MSI/MSI-X mode
> when it was succesfully enabled.
>
> Signed-off-by: Divy Le Ray <divy@chelsio.com>
> ---
>
> drivers/net/cxgb3/cxgb3_main.c | 42 ++++++++++++++++++++++++++++++++++++++++
> drivers/net/cxgb3/regs.h | 4 ++++
> 2 files changed, 46 insertions(+), 0 deletions(-)
we really don't need to be adding this to each driver
^ 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