headers
Crutcher Dunnavant | 2 Jul 2002 06:54
Favicon

init_foodev cleanup questions

Hello all.

I've got some time on my hands, so I am walking through
all the network drivers, and cleaning up use of init_foodev.
This means zapping foo_setup, and kmallocing or memseting
dev->priv;

I'm doing this at the prompting of an entry on the
kernel-janitors TODO list.

Very much of this code is utter crap, and the fixes are
obvious.

However, I have some questions regarding the legacy probe
code from drivers/net/Space.c

can I safely remove bar_probe() from Space.c, if I also
cleanup bar.c so as to make it a module_init/module_exit
based module?

Oh, and something seems to be wrong with the listserver,
I'm getting the following error, and Sender: is not
getting set correctly.

	X-Authentication-Warning: oss.sgi.com: majordomo set sender to owner-netdev <at> oss.sgi.com using -f

--

-- 
Crutcher Dunnavant <crutcher+spam <at> eng.ua.edu>
ECSS System Hacker / UA COE CS Senior
(Continue reading)

Permalink | Reply | 1 comment |
headers
Crutcher Dunnavant | 2 Jul 2002 16:48
Favicon

Re: init_foodev cleanup questions

++ 01/07/02 23:54 -0500 - Crutcher Dunnavant:
> Hello all.
> 
> I've got some time on my hands, so I am walking through
> all the network drivers, and cleaning up use of init_foodev.
> This means zapping foo_setup, and kmallocing or memseting
> dev->priv;
> 
> I'm doing this at the prompting of an entry on the
> kernel-janitors TODO list.
> 
> Very much of this code is utter crap, and the fixes are
> obvious.
> 
> However, I have some questions regarding the legacy probe
> code from drivers/net/Space.c
> 
> can I safely remove bar_probe() from Space.c, if I also
> cleanup bar.c so as to make it a module_init/module_exit
> based module?

below is an (untested) example of what I'm talking about. Is this kosher?

--- linux-2.5.24/drivers/net/3c509.c.init_netdev	Mon Jul  1 23:22:12 2002
+++ linux-2.5.24/drivers/net/3c509.c	Mon Jul  1 23:36:31 2002
 <at>  <at>  -233,8 +233,9  <at>  <at> 
 #endif /* __ISAPNP__ */
 static int nopnp;

-int __init el3_probe(struct net_device *dev, int card_idx)
(Continue reading)

Permalink | Reply | 0 comments |
headers
Crutcher Dunnavant | 2 Jul 2002 21:36
Favicon

proposed changes to init_*dev() for GFP_DMA

Hello all.

For the 2.5 tree,

I'm wondering if there would be support for extending the
underlying init_*dev() -> init_netdev() interfaces, so that
there is a way to pass in the GFP_DMA alloc flag, or any other
flag, if needed for the private memory to be kmalloced for
dev->priv? This would allow more drivers to use the same
interface.

Basicaly, I'm thinking something like:

struct net_device *init_etherdev(struct net_device *dev, int sizeof_priv, int flags);

/* for regualr devices */
dev = init_etherdev(NULL, sizeof(struct foo_priv), GFP_KERNEL);

or 

/* for DMA devices */
dev = init_etherdev(NULL, sizeof(struct foo_priv), GFP_KERNEL | GFP_DMA);

--

-- 
Crutcher Dunnavant <crutcher+spam <at> eng.ua.edu>
ECSS System Hacker / UA COE CS Senior
Permalink | Reply | 0 comments |
headers
bert hubert | 4 Jul 2002 16:41
Picon

SMP issues on ingress queue grafting

Alexey, Werner, Jamal, Others,

On 2.4.18-ac3 SMP, Dimitris Zilaskos reports that he can reliably hang his
system with the following two line script repeated during heavy traffic.

Full thread starts here:
http://mailman.ds9a.nl/pipermail/lartc/2002q3/004316.html

Hope this points you to any problems.

Regards,

bert

----- Forwarded message from Dimitris Zilaskos <dzila <at> tassadar.physics.auth.gr> -----

From: Dimitris Zilaskos <dzila <at> tassadar.physics.auth.gr>
To: Stef Coene <stef.coene <at> docum.org>
Cc: lartc <at> mailman.ds9a.nl
Subject: Re: [LARTC] tc reliably hangs my system
Date: Thu, 4 Jul 2002 13:07:08 +0300 (EEST)

 ok , this 2 lines repated anything from 5 to 20 times cause the hang :

tc qdisc del dev eth0 ingress
tc qdisc add dev eth0 handle ffff: ingress

 again , the presence of sustained outgoing traffic catalyses the effect .
It takes at least 150-200 kbytes/sec to easily cause the hang .
(Continue reading)

Permalink | Reply | 1 comment |
headers
jamal | 4 Jul 2002 20:12
Picon
Picon

Re: SMP issues on ingress queue grafting


Maybe related to what Doron was seeing:
Theres a patch thats been sitting around for a year or so;

http://www.cyberus.ca/~hadi/patches/ing-stats.patch

hopefuly the patch would be in 2.4.19 when it comes out. Ask him to test
it out.

cheers,
jamal

On Thu, 4 Jul 2002, bert hubert wrote:

> Alexey, Werner, Jamal, Others,
>
> On 2.4.18-ac3 SMP, Dimitris Zilaskos reports that he can reliably hang his
> system with the following two line script repeated during heavy traffic.
>
> Full thread starts here:
> http://mailman.ds9a.nl/pipermail/lartc/2002q3/004316.html
>
> Hope this points you to any problems.
>
> Regards,
>
> bert
>
> ----- Forwarded message from Dimitris Zilaskos <dzila <at> tassadar.physics.auth.gr> -----
>
(Continue reading)

Permalink | Reply | 0 comments |
headers
bert hubert | 5 Jul 2002 16:57
Picon

[dzila <at> tassadar.physics.auth.gr: Re: [LARTC] tc reliably hangs my system]

Jamal,

The patch you mentioned works fine, so I suggest it be merged pronto :-)

Thanks!

----- Forwarded message from Dimitris Zilaskos <dzila <at> tassadar.physics.auth.gr> -----

Date: Fri, 5 Jul 2002 16:35:33 +0300 (EEST)
From: Dimitris Zilaskos <dzila <at> tassadar.physics.auth.gr>
To: bert hubert <ahu <at> ds9a.nl>
Cc: lartc <at> mailman.ds9a.nl
Subject: Re: [LARTC] tc reliably hangs my system

>
>
> http://www.cyberus.ca/~hadi/patches/ing-stats.patch
>
> This fixes a known issue that looks like this - can you try if this resolves
> your problem? This patch will be in in 2.4.19 probably.

  Thnx . I am using the patch now with success . I can no longer reproduce
the hang .

  Regards ,

--
=============================================================================

Dimitris Zilaskos
(Continue reading)

Permalink | Reply | 0 comments |
headers
kuznet | 5 Jul 2002 18:05
Picon

Re: IPv6 ND on PPC hardware

Hello!

> When I try to ping another host on the LAN it usually works the first
> time, and then stops working because the other host does not replies to
> ND requests. 

It would be better if you gave full tcpdump where "working" stage
is present too.

> Apparently verything works again if I switch the interface
> in promiscuous mode.

At receiver? If yes, then it is most likely wrongly configured
multicast filter at device. Though it is still not clear why it worked
the first time.

Alexey
Permalink | Reply | 0 comments |
headers
Werner Almesberger | 8 Jul 2002 23:28
Favicon

Re: tc lockup on 2.4.19 up

bert hubert wrote:
> I think the rule gets matched circularly, but I'm unsure. 

Indeed. Happens with tcsim too.

I need to think a bit about this one. As a work-around, you can use
tcc with -One, which generates a bunch of tests for equality instead
of the single negation.

Thanks,
- Werner

--

-- 
  _________________________________________________________________________
 / Werner Almesberger, Buenos Aires, Argentina         wa <at> almesberger.net /
/_http://icapeople.epfl.ch/almesber/_____________________________________/
Permalink | Reply | 0 comments |
headers
bert hubert | 8 Jul 2002 22:48
Picon

tc lockup on 2.4.19 up

Hi,

While writing a chapter on tcng (USE IT!), I made this setup, which locks up
my 2.4.19-pre10 laptop solidly after a single packet matched:

#include "fields.tc"

dev eth0 
{       
        cbq (bandwidth 100Mbps, maxburst 5p, avpkt 1000B, allot 1500B){
                class (2, rate 10kBps, bounded)
                        if ip_dst == 213.244.168.210 && ip_tos!=0x10;
        }
}

which translates into:

tc qdisc add dev eth0 handle 1:0 root cbq bandwidth 12500000bps avpkt 1000
tc class add dev eth0 parent 1:0 classid 1:2 cbq bandwidth 12500000bps rate \
 10000bps allot 1500 avpkt 1000 maxburst 5 bounded
tc filter add dev eth0 parent 1:0 protocol ip prio 1 handle 1:0:0 u32 \
 divisor 1
tc filter add dev eth0 parent 1:0 protocol ip prio 1 u32 match u32 \
 0xd5f4a8d2 0xffffffff at 16 match u8 0x10 0xff at 1 classid 1:0
########
tc filter add dev eth0 parent 1:0 protocol ip prio 1 u32 match u32 \
 0xd5f4a8d2 0xffffffff at 16 classid 1:2
tc filter add dev eth0 parent 1:0 protocol ip prio 1 u32 match u32 0 0 at 0 \
 classid 1:0
(Continue reading)

Permalink | Reply | 1 comment |
headers
Tong Lee | 9 Jul 2002 03:48
Picon
Favicon

An answer for "Scheduling in interrupt".


Dear Krishna Kumar,

I have finally figured our what caused the "Scheduling in interrupt" panic. 
I didn't realize that ip_local_deliver is run within the bottom_half 
context, and I had used a semaphore there. It is that semaphore which had 
induced a sleep and therefore a schedule.

However I now have a new problem to fight with: my kgdb became 
dysfunctional. Upon reaching a "return" statement and when I typed "next", 
it simply went off and never returned! Have you any comments on how to 
solve or bypass this problem?

Lee Tong

_________________________________________________________________
与联机的朋友进行交流，请使用 MSN Messenger: 
http://messenger.microsoft.com/cn/
Permalink | Reply | 0 comments |

Gmane