Jeff,
this patch adds PPC4xx EMAC support to Ethtool. Patch was generated
against your Ethtool BK repo - I haven't found anything more recent.
Let me know if you have gkernel GIT repository somewhere and I'll redo
the patch if needed.
Signed-off-by: Eugene Surovegin <[EMAIL PROTECTED]>
diff -
Add new PPC 4xx NAPI EMAC driver
Signed-off-by: Eugene Surovegin <[EMAIL PROTECTED]>
---
drivers/net/Kconfig | 70 +
drivers/net/ibm_emac/Makefile | 11
drivers/net/ibm_emac/ibm_emac.h | 309 +
drivers/net/ibm_emac/ibm_emac_core.c | 2248 +++
Remove old PPC4xx EMAC driver
Signed-off-by: Eugene Surovegin <[EMAIL PROTECTED]>
---
drivers/net/Kconfig | 34 -
drivers/net/ibm_emac/Makefile | 12
drivers/net/ibm_emac/ibm_emac.h | 267
drivers/net/ibm_emac/ibm_emac_core.c | 2011 ---
Jeff,
the following patches replace current PowerPC 4xx EMAC driver with
new, re-written version.
New driver uses NAPI, it solves problems under heavy packet load and
low memory, corrects chip register access and fixes numerous small
bugs I don't even remember now :).
This patch has been test
I've copied the function inline below, and have several questions about it.
201 static void *ipx_seq_socket_next(struct seq_file *seq, void *v,
loff_t *pos)
202 {
203 struct sock* sk, *next;
204 struct ipx_interface *i;
205 struct ipx_opt *ipxs;
206
I'm looking at code in ipv4/tcp_minisocks.c (tcp_create_openreq_child).
The function calls sk_alloc to get a new socket, then acquires a
spinlock. When does this spinlock actually become necessary? It is
never released if xfrm_sk_clone_policy fails, but it seems it's not
possible for anyone to
--- Stephen Hemminger <[EMAIL PROTECTED]> wrote:
> On Wed, 31 Aug 2005 07:49:37 +1000 (EST)
> >
> > install-8_23.tar.bz2
>
> Just look for references to CHIP_REV_YU_LITE_A3 in
> the driver
> sk98lin/skgeinit.c and sk98lin/skxmac2.c
> The comparison should always be:
Have a look but no c
Arnaud Patard <[EMAIL PROTECTED]> :
[...]
Btw it would be nice if you could give a quick test to the three
attached patches against 2.6.13-git: #0, #0 + #1, #0 + #1 + #2.
--
Ueimor
diff -puN drivers/net/sis190.c~sis190-160 drivers/net/sis190.c
--- a/drivers/net/sis190.c~sis190-160 2005-08-31 00
Arnaud Patard <[EMAIL PROTECTED]> :
[...]
> During tests, I noticed that the loss of link was not handled. This was
> resulting of some stranges situations like mii-tool saying "no link" and
> ethtool saying "link detected". Moreover, this prevents daemons like
> ifplugd to work.
>
> I've made a p
On Wed, 31 Aug 2005 07:49:37 +1000 (EST)
Steve Kieu <[EMAIL PROTECTED]> wrote:
>
> --- Stephen Hemminger <[EMAIL PROTECTED]> wrote:
>
> > You have a version of the Marvell Yukon that was
> > affected
> > by a fix in 2.6.13.
> > skge addr 0xfeaf8000 irq 19 chip Yukon-Lite rev 9
> >
> > Both
--- Stephen Hemminger <[EMAIL PROTECTED]> wrote:
> You have a version of the Marvell Yukon that was
> affected
> by a fix in 2.6.13.
> skge addr 0xfeaf8000 irq 19 chip Yukon-Lite rev 9
>
> Both the skge and sk98lin driver were fixed to check
> for this.
> Without the fix, the chip will be
On 8/30/05, Sridhar Samudrala <[EMAIL PROTECTED]> wrote:
> On Tue, 2005-08-30 at 22:45 +0200, Jesper Juhl wrote:
> > Since the patch to add a NULL short-circuit to crypto_free_tfm() went in,
> > there's no longer any need for callers of that function to check for NULL.
> > This patch removes the re
On Tue, 2005-08-30 at 22:45 +0200, Jesper Juhl wrote:
> Since the patch to add a NULL short-circuit to crypto_free_tfm() went in,
> there's no longer any need for callers of that function to check for NULL.
> This patch removes the redundant NULL checks and also a few similar checks
> for NULL bef
You have a version of the Marvell Yukon that was affected
by a fix in 2.6.13.
skge addr 0xfeaf8000 irq 19 chip Yukon-Lite rev 9
Both the skge and sk98lin driver were fixed to check for this.
Without the fix, the chip will be in the wrong power mode.
The version of sk98lin driver from SysK
On Tue, Aug 30, 2005 at 10:45:54PM +0200, Jesper Juhl wrote:
> Since the patch to add a NULL short-circuit to crypto_free_tfm() went in,
> there's no longer any need for callers of that function to check for NULL.
...
> Feedback, ACK, NACK, etc welcome.
I've no problem with the auth_gss or nfsv4
Ok, I reproduce the problem and attached several lspci
log here
--- Stephen Hemminger <[EMAIL PROTECTED]> wrote:
> On Tue, 30 Aug 2005 13:18:57 -0700
> Jesse Brandeburg <[EMAIL PROTECTED]> wrote:
>
> > on 2.6.11/12 when it isn't working maybe you
> should send us the output
> > of lspci -vvv
>
Since the patch to add a NULL short-circuit to crypto_free_tfm() went in,
there's no longer any need for callers of that function to check for NULL.
This patch removes the redundant NULL checks and also a few similar checks
for NULL before calls to kfree() that I ran into while doing the
crypto_
On Tue, 30 Aug 2005 13:18:57 -0700
Jesse Brandeburg <[EMAIL PROTECTED]> wrote:
> on 2.6.11/12 when it isn't working maybe you should send us the output
> of lspci -vvv
>
> just a hint, I'm guessing its power management related, and / or
> something to do with the pci bus code.
Also, the dmesg ou
on 2.6.11/12 when it isn't working maybe you should send us the output
of lspci -vvv
just a hint, I'm guessing its power management related, and / or
something to do with the pci bus code.
On 8/30/05, Daniel Drake <[EMAIL PROTECTED]> wrote:
> Forwarding on, please reply-to-all in future.
>
> Ste
2) Call your mdio bus initialization function from your USB probe
function.
If I have multiple devices, should I wind up having a separate MDIO
bus
for each? If so, this would make sense for handling the registration.
My theory is one bus per master (mostly). As I understand it, each
On Mon, 2005-08-29 at 16:45 -0700, Stephen Hemminger wrote:
> You must check return value from try_module_get and error out
> if it fails. This is critical for module unload races.
Good point, and of course in such a situation, sk_alloc must
free the socket. Please see the updated patch below.
Th
On Tue, Aug 30, 2005 at 03:07:33PM +0200, Jirka Bohac wrote:
> Hi,
>
> > +/* wrappers of WE functions that don't check for errors */
> > +static inline int _iwe_stream_add_point(struct translate_scan *data,
> >
> > You may wonder why the original API of iwe_stream_add_point(()
> > is the way
Hello!
> Thanks for that explanation - it helps somewhat - one thing I was
> confused by was why the timer mechanism for the garbage collection
> was so elaborate; why does it do all that back off stuff and
> adjusting itself? Why not just run at some fixed rate?
What's about timer in dst.c, it i
On Tue, 30 Aug 2005 14:30:16 +0800, Zhu Yi wrote:
> Boardcast address should also be detected by is_multicast_ether_addr().
> Otherwise is_valid_ether_addr() is broken.
Please, add a comment to is_multicast_ether_addr() stating that
broadcast is a special case of multicast.
Otherwise one can be t
Hi,
During tests, I noticed that the loss of link was not handled. This was
resulting of some stranges situations like mii-tool saying "no link" and
ethtool saying "link detected". Moreover, this prevents daemons like
ifplugd to work.
I've made a patch for this but I'm not sure if it's the correc
Hi Dave, Please apply.
--
- Harald Welte <[EMAIL PROTECTED]> http://netfilter.org/
"Fragmentation is like classful addressing -- an interesting early
architectural error that shows how much experimen
Forwarding on, please reply-to-all in future.
Steve Kieu wrote:
Hi all,
I have "fixed" the problem in a very wierd way.Reading
your post I thought maybe when removing the driver
itself it set some bit incorrectly. Then I decided to
do:
Boot with init=/bin/bash so bypass all other things.
modp
Hi,
> +/* wrappers of WE functions that don't check for errors */
> +static inline int _iwe_stream_add_point(struct translate_scan *data,
>
> You may wonder why the original API of iwe_stream_add_point(()
> is the way it is rather than the way you expect. I'll explain :
> working closely wi
Hi Stephen,
This looks like an issue I reported previously. After you use a recent skge,
you can't use any older drivers or the windows driver, but skge still works
fine every time.
http://marc.theaimsgroup.com/?l=linux-netdev&m=112268414417743&w=2
The Gentoo bug report is here:
Steve Kieu wrote:
Are you using skge or sk98lin?
sk98lin
thanks
Can you test the new skge driver instead? If that one is broken then we
probably have more chance of getting it fixed :)
Thanks,
Daniel
-
To unsubscribe from this list: send the line "unsubscribe netdev" in
the body of a mes
On Fri, Aug 26, 2005 at 12:31:06AM +0200, Pavel Machek wrote:
> > separate-from-ethernet.patch
> Okay, here it starts to be "interesting". Patches up to here seem
> quite mergeable to me. This one will rename wifi from eth1 to wlan0,
> right?
People wanting eth* could always user udev to rename d
Steve Kieu wrote:
Ok it sound wierd enough to assume that the latest
kernel 2.6.13 ethernet driver has done something wrong
with the NIC and sustain the condition after reboot or
turn off the machine.
Here is my configuration.
Laptop Asus A4500d. dmesg shows:
eth0: Yukon Gigabit Ethernet 10/10
32 matches
Mail list logo
