Hi Scott,
> I wonder why it was 64-bit specific in the first place.
I think it was part of a series where I added my 64bit assembly checksum
routines, and I didn't step back and think that the wrapper code would
be useful on 32 bit.
Anton
--
To unsubscribe from this list: send the line "unsubscr
Hi,
> As far as I know, the x86 in-kernel thingy doesn't but yeah, the
> userland one seems much more evolved and does things based on the
> "class" of the device.
>
> Christoph, have any of you tried it on powerpc ?
FYI It works fine on PowerPC and its installed by default on some
distros (eg
Hi,
I booted 2.6.23-rc8 and noticed that ehea loves its workqueues:
# ps aux|grep ehea
root 3266 0.0 0.000 ?S< 11:02 0:00 [ehea_driver_wq/]
root 3268 0.0 0.000 ?S< 11:02 0:00 [ehea_driver_wq/]
root 3269 0.0 0.000 ?S< 11:02 0:00
Hi Hugh,
> It's interesting that compat_core_sys_select() shows this kmalloc(0)
> failure but core_sys_select() does not. That's because core_sys_select()
> avoids kmalloc by using a buffer on the stack for small allocations (and
> 0 sure is small). Shouldn't compat_core_sys_select() do just th
We assign the return value of register_netdev to i, but return rc later
on. Fix it.
Signed-off-by: Anton Blanchard <[EMAIL PROTECTED]>
---
diff --git a/drivers/net/pci-skeleton.c b/drivers/net/pci-skeleton.c
index 00ca0fd..6ca4e4f 100644
--- a/drivers/net/pci-skeleton.c
+++ b/drivers/n
Hi,
> +#ifdef CONFIG_PPC_64K_PAGES
> + /* To support 64k pages we must round to 64k page boundary */
> + epas->kernel.addr =
> + ioremap((paddr_kernel & 0x), PAGE_SIZE) +
> + (paddr_kernel & 0x);
> +#else
> epas->kernel.addr = ioremap(padd
Hi,
> I asked SO to recount arguments and we've come to a conclusion that
> there're in fact 19 args not 18 as the name suggests. 19 args is
> I-N-S-A-N-E.
It will be partially cleaned up by:
http://ozlabs.org/pipermail/linuxppc-dev/2006-July/024556.html
However it doesnt fix the fact someone
> Is a conditional cheaper than a divide? In case of a misprediction I
> would assume it to be significantly slower and I don't know the ratio
> of mispredictions for this branch.
A quick scan of the web shows 40 cycles for athlon64 idiv, and its
similarly slow on many other cpus. Even assuming
Hi,
> I agree, stubbs were removed.
Thanks.
What is going to be done about the debug infrastructure in the ehea
driver? The entry and exit traces really need to go, and any other debug
you think is important to users needs to go into debugfs or something
similar.
I see a similar issue in the e
> --- linux-2.6.18-rc4-orig/drivers/net/ehea/ehea.h 1969-12-31
> +extern void exit(int);
Should be able to remove that prototype :)
Anton
-
To unsubscribe from this list: send the line "unsubscribe netdev" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at http://vger.k
Hi,
> --- linux-2.6.18-rc4-orig/drivers/net/ehea/ehea_ethtool.c 1969-12-31
> +static void netdev_get_pauseparam(struct net_device *dev,
> + struct ethtool_pauseparam *pauseparam)
> +{
> + printk("get pauseparam\n");
> +}
There are a number of stubbed out e
Hi,
> drivers/net/ehea/ehea.h| 452
> +#define EHEA_DRIVER_NAME "IBM eHEA"
You are using this for ethtool get_drvinfo. Im not sure if it should
match the module name, and I worry about having a space in the name. Any
ideas on what we should be doing here?
> +#define NET_IP_ALIGN 0
S
Hi,
> --- linux-2.6.18-rc4-orig/drivers/net/ehea/ehea_phyp.c1969-12-31
> 16:00:00.0 -0800
> +u64 ehea_h_alloc_resource_eq(const u64 hcp_adapter_handle,
...
> +u64 hipz_h_reregister_pmr(const u64 adapter_handle,
...
> +static inline int hcp_galpas_ctor(struct h_galpas *galpas,
B
Hi,
> --- linux-2.6.18-rc4-orig/drivers/net/ehea/ehea_main.c1969-12-31
> +#define DEB_PREFIX "main"
Doesnt appear to be used.
> +static struct net_device_stats *ehea_get_stats(struct net_device *dev)
...
> + cb2 = kzalloc(H_CB_ALIGNMENT, GFP_KERNEL);
I cant see where this gets fr
Hi,
> If the EEPROM has a broken checksum, the user should have an option
> that allows him to try and use the device anyways, end of story.
Ive come across this problem a number of times on e1000 chips (to be
clear it was vendor programming issues).
The driver has the option to read and write
Hi,
> Please fix the generic code if it doesn't provide the facility
> you need at the moment. Don't shoe horn it into your driver
> just to make up for that.
Ive had 3 drivers asking for write combining recently so I agree this is
a good idea. How about ioremap_wc as suggested by Willy:
http
Hi,
> We didn't get any ppc64 with PCI-E to run Linux so far. What performance
> drop should we expect with our current code ?
We have seen > 20% improvement on ppc64 running some networking
workloads when forcing 128 byte alignment (instead of 16 byte
alignment). DMA writes have to get cacheli
Hi Brice,
Sorry this review is based on your previous submission, I just noticed
it was still sitting in my mailbox. Please ignore anything that has been
fixed in the meantime :)
> +/*
> + * Set of routunes to get a new receive buffer. Any buffer which
> + * crosses a 4KB boundary must start on
to
start on a cacheline boundary, so we increase that headroom to one
cacheline.
Signed-off-by: Anton Blanchard <[EMAIL PROTECTED]>
---
Index: kernel/include/linux/skbuff.h
===
--- kernel.orig/include/linux/skbuff.h 2006-03-22
Hi Stephen,
> Replace cube root algorithim with a faster version using Newton-Raphson.
> Surprisingly, doing the scaled div64_64 is faster than a true 64 bit
> division on 64 bit CPU's.
Interesting, what cpu was this on? Was there much difference between the
two methods?
Anton
-
To unsubscribe
Hi,
> TSO fixes
> - fix rare early completion when using TSO
> - extra descriptor for the sentinel descriptor
Is this the same bug as e1000? The extra DMA descriptor is going to be
costly, especially on 10Gb. Would the e1000_unmap_and_free_tx_resource
trick used in e1000 work instead?
(Actually
Any chance we can get this patch in?
Anton
At the moment ibmveth has DEBUG enabled which is rather verbose. Disable
it.
Signed-off-by: Anton Blanchard <[EMAIL PROTECTED]>
---
Index: foobar2/drivers/net/ibmveth.c
===
--- f
Hi,
> There is still a lot of code that depends upon there being
> a scratch of ~15 bytes there at the beginning of the SKB data
> area.
>
> This kind of change, at best, would require a thorough audit
> of every single piece of the networking, particularly things
> that tunnel other protocols
for various optimisations,
unfortunately this means all receive packets start 16 bytes into a
cacheline.
By allowing this to be overridden (via the NET_SKB_PAD define), we can
define the headroom to be a cacheline and maintain cacheline alignment.
Signed-off-by: Anton Blanchard <[EMAIL PROTEC
Hi,
We had a bad ethernet card that wouldnt initialise, so I figured we
could blink all other ethernets in the box to identify the bad one.
I was surprised to find we could only blink one card at a time, the
other ethtool processes were all blocked in D state. It turns out
the ethtool ioctl take
> The trailing 1 will cause a warning.
Good point.
--
At the moment ibmveth has DEBUG enabled which is rather verbose. Disable
it.
Signed-off-by: Anton Blanchard <[EMAIL PROTECTED]>
Index: foobar2/drivers/net/
At the moment ibmveth has DEBUG enabled which is rather verbose. Disable
it.
Signed-off-by: Anton Blanchard <[EMAIL PROTECTED]>
Index: foobar2/drivers/net/ibmveth.c
===
--- foobar2.orig/drivers/net/ibmveth.c 2005-07-06
27 matches
Mail list logo
