* Re: [patch 2/2] MAINTAINERS: add entry for wireless networking
From: David S. Miller @ 2006-01-18 22:53 UTC (permalink / raw)
To: linville; +Cc: linux-kernel, netdev
In-Reply-To: <20060118224453.GG6583@tuxdriver.com>
Both applied, thanks John.
^ permalink raw reply
* Re: [Bcm43xx-dev] wireless: the contenders
From: Johannes Berg @ 2006-01-19 0:19 UTC (permalink / raw)
To: John W. Linville; +Cc: netdev, linux-kernel, jbenc, softmac-dev, bcm43xx-dev
In-Reply-To: <20060118200616.GC6583@tuxdriver.com>
[-- Attachment #1: Type: text/plain, Size: 488 bytes --]
On Wed, 2006-01-18 at 15:06 -0500, John W. Linville wrote:
> The tree also has "softmac" and "dscape" branches. The "softmac"
> branch includes the Johannes Berg softmac code as well as the the
> BCM43xx driver based upon that code.
I guess that branch also contains my enhancements to ieee80211, do you
have any intentions of pulling those over to your upstream tree? I
suppose I should rather post them as a series of patches to netdev for
wider consideration.
johannes
[-- Attachment #2: This is a digitally signed message part --]
[-- Type: application/pgp-signature, Size: 832 bytes --]
^ permalink raw reply
* Re: 32 bit (socket layer) ioctl emulation for 64 bit kernels
From: Arnd Bergmann @ 2006-01-19 0:57 UTC (permalink / raw)
To: spereira
Cc: YOSHIFUJI Hideaki / 吉藤英明, acme, ak,
linux-kernel, netdev, pereira.shaun, Arnd Bergmann
In-Reply-To: <1137567396.14130.2.camel@spereira05.tusc.com.au>
Am Wednesday 18 January 2006 07:56 schrieb Shaun Pereira:
> Assuming you are happy with the state of the patches, is there anyway
> for me to know if they will become a part of the next release?
I don't see any more technical problems with your patches. You still need
to proper patch description and Signed-off-by: line like it is described
in Documentation/SubmittingPatches.
You can add an 'Acked-by: Arnd Bergmann <arnd@arndb.de>' line to the four
patches you posted last if you like.
> Usually submitted/reviewed patches to netdev does not not always
> guarantee they will be acccepted/signed-off.
> Any advice would be useful
I'm not that familiar with the process for non-driver patches for netdev
(nor for device drivers as it seems ;-)), but my understanding is that you
should address those to Jeff Garzik as well, asking for inclusion in the
netdev-2.6 git tree in your introductory '[PATCH 0/4]' mail.
Since the official merge window for 2.6.16 is now over (2.6.16-rc1 has been
released), it may have to wait for 2.6.17 to become part of the mainline
kernel, that probably depends on Jeffs judgement.
I would think it can still go in since it is a bug fix for the execution of
32 bit programs using x25 ioctls, but it's clearly not my decision ;-).
Arnd <><
^ permalink raw reply
* Re: 32 bit (socket layer) ioctl emulation for 64 bit kernels
From: David S. Miller @ 2006-01-19 1:05 UTC (permalink / raw)
To: arnd; +Cc: spereira, yoshfuji, acme, ak, linux-kernel, netdev, pereira.shaun
In-Reply-To: <200601190157.38277.arnd@arndb.de>
From: Arnd Bergmann <arnd@arndb.de>
Date: Thu, 19 Jan 2006 01:57:37 +0100
> I'm not that familiar with the process for non-driver patches for
> netdev (nor for device drivers as it seems ;-)), but my
> understanding is that you should address those to Jeff Garzik as
> well, asking for inclusion in the netdev-2.6 git tree in your
> introductory '[PATCH 0/4]' mail.
Those should be CC:'d to me, not Jeff, he has enough to review
and merge :)
^ permalink raw reply
* [2.6 patch] schedule SHAPER for removal
From: Adrian Bunk @ 2006-01-19 2:11 UTC (permalink / raw)
To: Andrew Morton; +Cc: Alan Cox, jgarzik, netdev, linux-kernel
Signed-off-by: Adrian Bunk <bunk@stusta.de>
---
This patch was already sent on:
- 13 Jan 2006
--- linux-2.6.15-mm3-full/Documentation/feature-removal-schedule.txt.old 2006-01-13 15:02:15.000000000 +0100
+++ linux-2.6.15-mm3-full/Documentation/feature-removal-schedule.txt 2006-01-13 15:06:19.000000000 +0100
@@ -164,0 +165,6 @@
+---------------------------
+
+What: Traffic Shaper (CONFIG_SHAPER)
+When: July 2006
+Why: obsoleted by the code in net/sched/
+Who: Adrian Bunk <bunk@stusta.de
--- linux-2.6.15-mm3-full/drivers/net/Kconfig.old 2006-01-13 15:06:34.000000000 +0100
+++ linux-2.6.15-mm3-full/drivers/net/Kconfig 2006-01-13 15:06:49.000000000 +0100
@@ -2663,7 +2663,7 @@
"SCSI generic support".
config SHAPER
- tristate "Traffic Shaper (EXPERIMENTAL)"
+ tristate "Traffic Shaper (OBSOLETE)"
depends on EXPERIMENTAL
---help---
The traffic shaper is a virtual network device that allows you to
^ permalink raw reply
* Re: [Bcm43xx-dev] wireless: the contenders
From: John W. Linville @ 2006-01-19 15:27 UTC (permalink / raw)
To: Johannes Berg; +Cc: netdev, linux-kernel, jbenc, softmac-dev, bcm43xx-dev
In-Reply-To: <1137629980.4385.9.camel@localhost>
On Thu, Jan 19, 2006 at 01:19:40AM +0100, Johannes Berg wrote:
> On Wed, 2006-01-18 at 15:06 -0500, John W. Linville wrote:
>
> > The tree also has "softmac" and "dscape" branches. The "softmac"
> > branch includes the Johannes Berg softmac code as well as the the
> > BCM43xx driver based upon that code.
>
> I guess that branch also contains my enhancements to ieee80211, do you
> have any intentions of pulling those over to your upstream tree? I
> suppose I should rather post them as a series of patches to netdev for
> wider consideration.
I pulled from the softmac-2.6.git tree. I think there was ieee80211
stuff in there as well, but you probably know better than I do. :-)
The history in your tree isn't formatted properly for the kernel,
so something would have to be done before that went upstream anyway.
I think it would be best for you to post the patches to netdev,
including patches covering softmac if you are so inclined. Please be
sure to follow kernel patch posting conventions:
http://linux.yyz.us/patch-format.html
Thanks,
John
--
John W. Linville
linville@tuxdriver.com
^ permalink raw reply
* Re: My vote against eepro* removal
From: Adrian Bunk @ 2006-01-19 16:20 UTC (permalink / raw)
To: kus Kusche Klaus
Cc: Lee Revell, linux-kernel, john.ronciak, ganesh.venkatesan,
jesse.brandeburg, netdev
In-Reply-To: <AAD6DA242BC63C488511C611BD51F367323322@MAILIT.keba.co.at>
On Thu, Jan 19, 2006 at 11:26:51AM +0100, kus Kusche Klaus wrote:
> > From: Lee Revell
> > On Thu, 2006-01-19 at 08:19 +0100, kus Kusche Klaus wrote:
> > > Last time I tested (around 2.6.12), eepro100 worked much better
> > > in -rt kernels w.r.t. latencies than e100:
> > >
> > > e100 caused a periodic latency of about 500 microseconds
> > > exactly every 2 seconds, no matter what the load on the interface
> > > was (i.e. even on an idle interface).
> > >
> > > eepro100 did not show any latencies that long, it worked much
> > > smoother w.r.t. latencies.
> > >
> > > Of course I would prefer to have e100 fixed over keeping eepro100
> > > around forever, but the last time I checked, it still wasn't fixed.
> >
> > Please provide latency traces to illustrate the problematic code path.
>
> It's not a "latency": As far as I can tell, interrupts or preemption
> are not disabled, the latency tracer doesn't show anything.
>
> I just noticed that low-pri rt processes did not get scheduled for
> about 500 microseconds when e100 was active (even if the net was
> idle), and that there were no such breaks with eepro100.
>
> I didn't analyze it in detail at that time, I believed that the e100
> interrupt handler thread was running every 2 seconds for 500
> microseconds, because the interrupt count of eth0 incremented every
> 2 seconds, exactly when my rt processes paused.
>
> This would be bad: That irq thread is at rt prio 47 on my system,
> above many importent things.
>
> However, I checked more closely now, and found out that only a small
> portion of the 500 microseconds is spent in the irq thread. Most of
> it is spent in the timer thread, at rt prio 1, so the whole thing
> is a much smaller problem than I originally believed.
>
> Must be the function e100_watchdog.
>...
Is this with 2.6.12 or 2.6.16-rc1?
If it's the former, please check whether the problem is still presnt in
the latter.
If it's the latter, I'm sure the e100 developers (Cc'ed) are interested
in your problem.
cu
Adrian
--
"Is there not promise of rain?" Ling Tan asked suddenly out
of the darkness. There had been need of rain for many days.
"Only a promise," Lao Er said.
Pearl S. Buck - Dragon Seed
^ permalink raw reply
* Re: help with e1000 issue?
From: Christopher Friesen @ 2006-01-19 16:48 UTC (permalink / raw)
To: Jesse Brandeburg; +Cc: netdev, e1000-devel
In-Reply-To: <4807377b0601181316w2ac0fb0dod976e456816331ae@mail.gmail.com>
Jesse Brandeburg wrote:
> On 1/18/06, Christopher Friesen <cfriesen@nortel.com> wrote:
>>So, somehow we're getting into a state where we can't receive packets,
>>and we're never getting out of that state.
> Are you sure that you're able to transmit and you aren't just handing
> it to the hardware and it never gets out? tcpdump on a remote machine
> would verify.
I haven't tried the new driver yet, so this is still with the old driver
(had the hung machine still up from yesterday).
It looks like tx is working--we see the packets on the other machines on
the network. I tested unicast and broadcast, and both seem to be working.
I tried a broadcast ping to the whole subnet. For that one the icmp
packet goes out, then we see ARPs from everyone on the subnet trying to
get the MAC address of the machine with eth issues.
On the machine with hung ethernet:
root@172.24.101.12:/root> ping -b 172.25.0.0
WARNING: pinging broadcast address
PING 172.25.0.0 (172.25.0.0) 56(84) bytes of data.
64 bytes from 172.25.101.12: icmp_seq=1 ttl=64 time=0.041 ms
64 bytes from 172.25.101.12: icmp_seq=2 ttl=64 time=0.046 ms
On the other machine:
root@10.102.92.28:/root> tcpdump -n -i bond1 host 172.25.101.12
tcpdump: verbose output suppressed, use -v or -vv for full protocol decode
listening on bond1, link-type EN10MB (Ethernet), capture size 96 bytes
01:51:27.275594 IP 172.25.101.12 > 172.25.0.0: icmp 64: echo request seq 1
01:51:27.275748 arp who-has 172.25.101.12 tell 172.25.80.0
01:51:27.275824 arp who-has 172.25.101.12 tell 172.25.101.16
01:51:27.276248 arp who-has 172.25.101.12 tell 172.25.101.13
01:51:27.276373 arp who-has 172.25.101.12 tell 172.25.101.1
01:51:28.275674 arp who-has 172.25.101.12 tell 172.25.101.16
01:51:28.276258 arp who-has 172.25.101.12 tell 172.25.101.1
01:51:28.278017 arp who-has 172.25.101.12 tell 172.25.80.0
01:51:28.278260 IP 172.25.101.12 > 172.25.0.0: icmp 64: echo request seq 2
01:51:28.278388 arp who-has 172.25.101.12 tell 172.25.101.13
01:51:29.275520 arp who-has 172.25.101.12 tell 172.25.101.16
01:51:29.276018 arp who-has 172.25.101.12 tell 172.25.101.1
01:51:29.280032 IP 172.25.101.12 > 172.25.0.0: icmp 64: echo request seq 3
01:51:29.280277 arp who-has 172.25.101.12 tell 172.25.80.0
01:51:29.280524 arp who-has 172.25.101.12 tell 172.25.101.13
Chris
-------------------------------------------------------
This SF.net email is sponsored by: Splunk Inc. Do you grep through log files
for problems? Stop! Download the new AJAX search engine that makes
searching your log files as easy as surfing the web. DOWNLOAD SPLUNK!
http://sel.as-us.falkag.net/sel?cmd=lnk&kid=103432&bid=230486&dat=121642
^ permalink raw reply
* Re: My vote against eepro* removal
From: John Ronciak @ 2006-01-19 17:16 UTC (permalink / raw)
To: Adrian Bunk
Cc: kus Kusche Klaus, Lee Revell, linux-kernel, john.ronciak,
ganesh.venkatesan, jesse.brandeburg, netdev
In-Reply-To: <20060119162056.GP19398@stusta.de>
During the watchdog the e100 driver reads all of the status registers
from the actual hardware. There are 26 (worst case) register reads.
There is also a spin lock for another check in the watchdog. It would
still surprise me that all of this would take 500 usec. If you are
seeing this delay, you can comment out the scheduling of the watchdog
to see if this goes away. We'll need to narrow down exactly what in
the watchdog is causing the delay
Thanks.
--
Cheers,
John
^ permalink raw reply
* Re: [2.6 patch] schedule SHAPER for removal
From: Jan Engelhardt @ 2006-01-19 20:18 UTC (permalink / raw)
To: Adrian Bunk; +Cc: Andrew Morton, Alan Cox, jgarzik, netdev, linux-kernel
In-Reply-To: <20060119021150.GC19398@stusta.de>
>Subject: [2.6 patch] schedule SHAPER for removal
Replaced by what; the QoS subsystem?
> config SHAPER
>- tristate "Traffic Shaper (EXPERIMENTAL)"
>+ tristate "Traffic Shaper (OBSOLETE)"
> depends on EXPERIMENTAL
Jan Engelhardt
--
| Alphagate Systems, http://alphagate.hopto.org/
| jengelh's site, http://jengelh.hopto.org/
^ permalink raw reply
* Re: [2.6 patch] schedule SHAPER for removal
From: Benjamin LaHaise @ 2006-01-19 21:57 UTC (permalink / raw)
To: Adrian Bunk; +Cc: Andrew Morton, Alan Cox, jgarzik, netdev, linux-kernel
In-Reply-To: <20060119021150.GC19398@stusta.de>
On Thu, Jan 19, 2006 at 03:11:50AM +0100, Adrian Bunk wrote:
> +What: Traffic Shaper (CONFIG_SHAPER)
> +When: July 2006
> +Why: obsoleted by the code in net/sched/
> +Who: Adrian Bunk <bunk@stusta.de
This length of obsolete cycles is way too short -- it's not even enough
time for a single release of a distro to ship with the feature marked as
obsolete.
-ben
^ permalink raw reply
* Re: WCONF, netlink based WE replacement.
From: Harald Welte @ 2006-01-20 8:48 UTC (permalink / raw)
To: Thomas Graf; +Cc: Michael Buesch, linux-kernel, netdev
In-Reply-To: <20060113131503.GA379@postel.suug.ch>
[-- Attachment #1: Type: text/plain, Size: 1177 bytes --]
On Fri, Jan 13, 2006 at 02:15:03PM +0100, Thomas Graf wrote:
> * Michael Buesch <mbuesch@freenet.de> 2006-01-12 18:24
> > This is an attempt to rewrite the Wireless Extensions
> > userspace API, using netlink sockets.
> > There should also be a notification API, to inform
> > userspace for changes (config changes, state changes, etc).
> > It is not implemented, yet.
>
> I'll only comment on the netlink bits and leave the rest to
> others. I'd highly recommend the use of attributes instead
> of fixed message structures to allow the interface to be
> flexible to extensions while staying binary compatible.
I can only second Thomas' suggestion. The power and flexibility of the
use of netlink is only really unveiled if you use attributes. This way
you can easily extend your data structures later on without breaking
compatibility, etc.
--
- Harald Welte <laforge@gnumonks.org> http://gnumonks.org/
============================================================================
"Privacy in residential applications is a desirable marketing option."
(ETSI EN 300 175-7 Ch. A6)
[-- Attachment #2: Type: application/pgp-signature, Size: 189 bytes --]
^ permalink raw reply
* RE: My vote against eepro* removal
From: kus Kusche Klaus @ 2006-01-20 9:37 UTC (permalink / raw)
To: John Ronciak, Adrian Bunk
Cc: kus Kusche Klaus, Lee Revell, linux-kernel, john.ronciak,
ganesh.venkatesan, jesse.brandeburg, netdev, Steven Rostedt
> From: John Ronciak
> During the watchdog the e100 driver reads all of the status registers
> from the actual hardware. There are 26 (worst case) register reads.
> There is also a spin lock for another check in the watchdog. It would
> still surprise me that all of this would take 500 usec. If you are
> seeing this delay, you can comment out the scheduling of the watchdog
> to see if this goes away. We'll need to narrow down exactly what in
> the watchdog is causing the delay
Retested it.
Software:
2.6.15.1-rt6, no additional patches, configured for full preemption.
Hardware:
500 MHz Pentium 3
According to lspci: 82443+82371 Chipset (440 BX + PIIX4)
According to lspci: 82559ER (09) e100
100 Mbit full duplex
Measurement software:
* I start the rtc at 8192 Hz.
* I read from /dev/rtc in a usermode realtime process.
* After each read, I read the tsc and calculate the interval.
* It should be 122 us most of the time, and indeed it is.
At rtprio 2-99, practically all measurements are < 160-175 us
on an otherwise idle machine (160 for 99, 175 for 2).
At rtprio 1, there are some intervals of up to 300 us on an
idle machine.
* The program records the intervals in internal arrays and prints
them at the end, it doesn't perform any I/O while it is running.
Basically, my software measures how long it takes for a realtime
process at prio n to get executed after it became ready:
The actual interval minus 122 is the time the process was waiting
for the CPU (didn't get scheduled).
This means that there was continuous CPU activity for at least
that long, either at a higher or the same rt prio, on in
non-thread kernel code.
(the rtc threaded interrupt handler is running above all others)
Effect of the e100 driver:
* There is no measurable effect when my test program is running
at prio 2 - 99.
* For prio 1, I get an interval of 500-650 us every 2 seconds,
which indicates a scheduling latency of 380-530 us.
Hence, some piece of code is running for ~500 us at rt prio 1.
Analysis of e100:
* If I comment out the whole body of e100_watchdog except for the
timer re-registration, the delays are gone (so it is really the
body of e100_watchdog). However, this makes eth0 non-functional.
* Commenting out parts of it, I found out that most of the time
goes into its first half: The code from mii_ethtool_gset to
mii_check_link (including) makes the big difference, as far as
I can tell especially mii_ethtool_gset.
Effect of desktop preemption:
With desktop preemption insted of full preemption, the 400-500 us
scheduling delay hits at any rt priority, even at 99, i.e. the
CPU is occupied by non-thread kernel code.
Again, commenting out e100_watchdog brings the delays back to
well below 400 us.
Latency traces:
None.
The latency tracer does not record this scheduling latency.
My max. traces are around 35 us with full preemption and
around 70 us with desktop preemption, and are not related to e100.
--
Klaus Kusche (Software Development - Control Systems)
KEBA AG Gewerbepark Urfahr, A-4041 Linz, Austria (Europe)
Tel: +43 / 732 / 7090-3120 Fax: +43 / 732 / 7090-6301
E-Mail: kus@keba.com WWW: www.keba.com
^ permalink raw reply
* Re: My vote against eepro* removal
From: Evgeniy Polyakov @ 2006-01-20 9:55 UTC (permalink / raw)
To: kus Kusche Klaus
Cc: John Ronciak, Adrian Bunk, Lee Revell, linux-kernel, john.ronciak,
ganesh.venkatesan, jesse.brandeburg, netdev, Steven Rostedt
In-Reply-To: <AAD6DA242BC63C488511C611BD51F367323324@MAILIT.keba.co.at>
On Fri, Jan 20, 2006 at 10:37:43AM +0100, kus Kusche Klaus (kus@keba.com) wrote:
> > From: John Ronciak
> > During the watchdog the e100 driver reads all of the status registers
> > from the actual hardware. There are 26 (worst case) register reads.
> > There is also a spin lock for another check in the watchdog. It would
> > still surprise me that all of this would take 500 usec. If you are
> > seeing this delay, you can comment out the scheduling of the watchdog
> > to see if this goes away. We'll need to narrow down exactly what in
> > the watchdog is causing the delay
>
> Retested it.
...
> Effect of the e100 driver:
> * There is no measurable effect when my test program is running
> at prio 2 - 99.
> * For prio 1, I get an interval of 500-650 us every 2 seconds,
> which indicates a scheduling latency of 380-530 us.
> Hence, some piece of code is running for ~500 us at rt prio 1.
>
> Analysis of e100:
> * If I comment out the whole body of e100_watchdog except for the
> timer re-registration, the delays are gone (so it is really the
> body of e100_watchdog). However, this makes eth0 non-functional.
> * Commenting out parts of it, I found out that most of the time
> goes into its first half: The code from mii_ethtool_gset to
> mii_check_link (including) makes the big difference, as far as
> I can tell especially mii_ethtool_gset.
Each MDIO read can take upto 2 msecs (!) and at least 20 usecs in e100,
and this runs in timer handler.
Concider attaching (only compile tested) patch which moves e100 watchdog
into workqueue.
Signed-off-by: Evgeniy Polyakov <johnpol@2ka.mipt.ru>
diff --git a/drivers/net/e100.c b/drivers/net/e100.c
index 22cd045..e884578 100644
--- a/drivers/net/e100.c
+++ b/drivers/net/e100.c
@@ -549,7 +549,7 @@ struct nic {
enum phy phy;
struct params params;
struct net_device_stats net_stats;
- struct timer_list watchdog;
+ struct work_struct watchdog;
struct timer_list blink_timer;
struct mii_if_info mii;
struct work_struct tx_timeout_task;
@@ -1495,7 +1495,7 @@ static void e100_adjust_adaptive_ifs(str
}
}
-static void e100_watchdog(unsigned long data)
+static void e100_watchdog(void *data)
{
struct nic *nic = (struct nic *)data;
struct ethtool_cmd cmd;
@@ -1539,7 +1539,7 @@ static void e100_watchdog(unsigned long
else
nic->flags &= ~ich_10h_workaround;
- mod_timer(&nic->watchdog, jiffies + E100_WATCHDOG_PERIOD);
+ schedule_delayed_work(&nic->watchdog, E100_WATCHDOG_PERIOD);
}
static inline void e100_xmit_prepare(struct nic *nic, struct cb *cb,
@@ -2004,7 +2004,7 @@ static int e100_up(struct nic *nic)
goto err_clean_cbs;
e100_set_multicast_list(nic->netdev);
e100_start_receiver(nic, NULL);
- mod_timer(&nic->watchdog, jiffies);
+ schedule_work(&nic->watchdog);
if((err = request_irq(nic->pdev->irq, e100_intr, SA_SHIRQ,
nic->netdev->name, nic->netdev)))
goto err_no_irq;
@@ -2016,7 +2016,7 @@ static int e100_up(struct nic *nic)
return 0;
err_no_irq:
- del_timer_sync(&nic->watchdog);
+ cancel_rearming_delayed_work(&nic->watchdog);
err_clean_cbs:
e100_clean_cbs(nic);
err_rx_clean_list:
@@ -2031,7 +2031,7 @@ static void e100_down(struct nic *nic)
netif_stop_queue(nic->netdev);
e100_hw_reset(nic);
free_irq(nic->pdev->irq, nic->netdev);
- del_timer_sync(&nic->watchdog);
+ flush_scheduled_work();
netif_carrier_off(nic->netdev);
e100_clean_cbs(nic);
e100_rx_clean_list(nic);
@@ -2570,9 +2570,7 @@ static int __devinit e100_probe(struct p
pci_set_master(pdev);
- init_timer(&nic->watchdog);
- nic->watchdog.function = e100_watchdog;
- nic->watchdog.data = (unsigned long)nic;
+ INIT_WORK(&nic->watchdog, e100_watchdog, nic);
init_timer(&nic->blink_timer);
nic->blink_timer.function = e100_blink_led;
nic->blink_timer.data = (unsigned long)nic;
> --
> Klaus Kusche (Software Development - Control Systems)
> KEBA AG Gewerbepark Urfahr, A-4041 Linz, Austria (Europe)
> Tel: +43 / 732 / 7090-3120 Fax: +43 / 732 / 7090-6301
> E-Mail: kus@keba.com WWW: www.keba.com
--
Evgeniy Polyakov
^ permalink raw reply related
* RE: My vote against eepro* removal
From: kus Kusche Klaus @ 2006-01-20 10:19 UTC (permalink / raw)
To: Evgeniy Polyakov
Cc: John Ronciak, Adrian Bunk, Lee Revell, linux-kernel, john.ronciak,
ganesh.venkatesan, jesse.brandeburg, netdev, Steven Rostedt
From: Evgeniy Polyakov
> Each MDIO read can take upto 2 msecs (!) and at least 20
> usecs in e100,
> and this runs in timer handler.
> Concider attaching (only compile tested) patch which moves
> e100 watchdog
> into workqueue.
Hmmm, I don't think moving it around is worth the trouble
(nevertheless, I will test later if I find time).
For a full preemption kernel, both timer code and workqueue code
are executed in a thread of their own. If I know that there is a
500 us piece of code in either of them, I have to adjust the prio
of the corresponding thread (and all others) accordingly anyway.
For a non-full preemption kernel, your patch moves the 500 us
piece of code from kernel to thread context, so it really
improves things. But is 500 us something to worry about in a
non-full preemption kernel?
--
Klaus Kusche (Software Development - Control Systems)
KEBA AG Gewerbepark Urfahr, A-4041 Linz, Austria (Europe)
Tel: +43 / 732 / 7090-3120 Fax: +43 / 732 / 7090-6301
E-Mail: kus@keba.com WWW: www.keba.com
^ permalink raw reply
* RE: My vote against eepro* removal
From: kus Kusche Klaus @ 2006-01-20 10:51 UTC (permalink / raw)
To: Evgeniy Polyakov
Cc: John Ronciak, Adrian Bunk, Lee Revell, linux-kernel, john.ronciak,
ganesh.venkatesan, jesse.brandeburg, netdev, Steven Rostedt
From: Evgeniy Polyakov [mailto:johnpol@2ka.mipt.ru]
> Each MDIO read can take upto 2 msecs (!) and at least 20
> usecs in e100,
> and this runs in timer handler.
> Concider attaching (only compile tested) patch which moves
> e100 watchdog
> into workqueue.
Tested the patch. Works and has the expected effects:
Fully preemptible kernel:
No change: 500 us delay at rtprio 1, no delay at higher rtprio.
(you just moved the 500 us piece of code from one rtprio 1 kernel
thread to another rtprio 1 kernel thread).
Kernel with desktop preemption:
Originally: Threads at any rtprio suffered from 500 us delay.
With your patch: Only rtprio 1 threads suffer from 500 us delay,
no delay at higher rtprio.
--
Klaus Kusche (Software Development - Control Systems)
KEBA AG Gewerbepark Urfahr, A-4041 Linz, Austria (Europe)
Tel: +43 / 732 / 7090-3120 Fax: +43 / 732 / 7090-6301
E-Mail: kus@keba.com WWW: www.keba.com
^ permalink raw reply
* Re: My vote against eepro* removal
From: Evgeniy Polyakov @ 2006-01-20 11:02 UTC (permalink / raw)
To: kus Kusche Klaus
Cc: John Ronciak, Adrian Bunk, Lee Revell, linux-kernel, john.ronciak,
ganesh.venkatesan, jesse.brandeburg, netdev, Steven Rostedt
In-Reply-To: <AAD6DA242BC63C488511C611BD51F367323325@MAILIT.keba.co.at>
On Fri, Jan 20, 2006 at 11:19:20AM +0100, kus Kusche Klaus (kus@keba.com) wrote:
> From: Evgeniy Polyakov
> > Each MDIO read can take upto 2 msecs (!) and at least 20
> > usecs in e100,
> > and this runs in timer handler.
> > Concider attaching (only compile tested) patch which moves
> > e100 watchdog
> > into workqueue.
>
> Hmmm, I don't think moving it around is worth the trouble
> (nevertheless, I will test later if I find time).
>
> For a full preemption kernel, both timer code and workqueue code
> are executed in a thread of their own. If I know that there is a
> 500 us piece of code in either of them, I have to adjust the prio
> of the corresponding thread (and all others) accordingly anyway.
>
> For a non-full preemption kernel, your patch moves the 500 us
> piece of code from kernel to thread context, so it really
> improves things. But is 500 us something to worry about in a
> non-full preemption kernel?
In the worst case it will be milliseconds, which is not very nice
timeout for timer handler...
P.S. above patch works without problems with my e100 card.
> --
> Klaus Kusche (Software Development - Control Systems)
> KEBA AG Gewerbepark Urfahr, A-4041 Linz, Austria (Europe)
> Tel: +43 / 732 / 7090-3120 Fax: +43 / 732 / 7090-6301
> E-Mail: kus@keba.com WWW: www.keba.com
--
Evgeniy Polyakov
^ permalink raw reply
* Re: My vote against eepro* removal
From: Evgeniy Polyakov @ 2006-01-20 11:05 UTC (permalink / raw)
To: kus Kusche Klaus
Cc: John Ronciak, Adrian Bunk, Lee Revell, linux-kernel, john.ronciak,
ganesh.venkatesan, jesse.brandeburg, netdev, Steven Rostedt
In-Reply-To: <AAD6DA242BC63C488511C611BD51F367323326@MAILIT.keba.co.at>
On Fri, Jan 20, 2006 at 11:51:23AM +0100, kus Kusche Klaus (kus@keba.com) wrote:
> From: Evgeniy Polyakov [mailto:johnpol@2ka.mipt.ru]
> > Each MDIO read can take upto 2 msecs (!) and at least 20
> > usecs in e100,
> > and this runs in timer handler.
> > Concider attaching (only compile tested) patch which moves
> > e100 watchdog
> > into workqueue.
>
> Tested the patch. Works and has the expected effects:
>
> Fully preemptible kernel:
> No change: 500 us delay at rtprio 1, no delay at higher rtprio.
> (you just moved the 500 us piece of code from one rtprio 1 kernel
> thread to another rtprio 1 kernel thread).
>
> Kernel with desktop preemption:
> Originally: Threads at any rtprio suffered from 500 us delay.
> With your patch: Only rtprio 1 threads suffer from 500 us delay,
> no delay at higher rtprio.
Just a hack:
--- drivers/net/e100.c.1 2006-01-20 13:39:19.000000000 +0300
+++ drivers/net/e100.c 2006-01-20 14:15:40.000000000 +0300
@@ -879,8 +879,8 @@
writel((reg << 16) | (addr << 21) | dir | data, &nic->csr->mdi_ctrl);
- for(i = 0; i < 100; i++) {
- udelay(20);
+ for(i = 0; i < 1000; i++) {
+ udelay(2);
if((data_out = readl(&nic->csr->mdi_ctrl)) & mdi_ready)
break;
}
> --
> Klaus Kusche (Software Development - Control Systems)
> KEBA AG Gewerbepark Urfahr, A-4041 Linz, Austria (Europe)
> Tel: +43 / 732 / 7090-3120 Fax: +43 / 732 / 7090-6301
> E-Mail: kus@keba.com WWW: www.keba.com
>
--
Evgeniy Polyakov
^ permalink raw reply
* RE: My vote against eepro* removal
From: kus Kusche Klaus @ 2006-01-20 11:27 UTC (permalink / raw)
To: Evgeniy Polyakov
Cc: John Ronciak, Adrian Bunk, Lee Revell, linux-kernel, john.ronciak,
ganesh.venkatesan, jesse.brandeburg, netdev, Steven Rostedt
From: Evgeniy Polyakov
> Just a hack:
>
> --- drivers/net/e100.c.1 2006-01-20 13:39:19.000000000 +0300
> +++ drivers/net/e100.c 2006-01-20 14:15:40.000000000 +0300
> @@ -879,8 +879,8 @@
>
> writel((reg << 16) | (addr << 21) | dir | data,
> &nic->csr->mdi_ctrl);
>
> - for(i = 0; i < 100; i++) {
> - udelay(20);
> + for(i = 0; i < 1000; i++) {
> + udelay(2);
> if((data_out = readl(&nic->csr->mdi_ctrl)) & mdi_ready)
> break;
> }
My test environment and software is not precise enough for small
improvements, but I'd say this results in a 10-15 % improvement
(i.e. something like 50 us shorter delay) on the average.
To be sure, one would have to take and print tsc timestamps directly
in the watchdog code, but printk's mess up my timings.
--
Klaus Kusche (Software Development - Control Systems)
KEBA AG Gewerbepark Urfahr, A-4041 Linz, Austria (Europe)
Tel: +43 / 732 / 7090-3120 Fax: +43 / 732 / 7090-6301
E-Mail: kus@keba.com WWW: www.keba.com
^ permalink raw reply
* [2.6 patch] AIRO{,_CS} <-> CRYPTO fixes
From: Adrian Bunk @ 2006-01-21 0:35 UTC (permalink / raw)
To: linville; +Cc: netdev, linux-kernel
CRYPTO is a helper variable, and to make it easier for users, it should
therefore select'ed and not be listed in the dependencies.
drivers/net/wireless/airo.c requires CONFIG_CRYPTO for compilations.
Therefore, AIRO_CS also has to CRYPTO.
Additionally, this patch removes the #ifdef's for the non-compiling
CRYPTO=n case from drivers/net/wireless/airo.c.
Signed-off-by: Adrian Bunk <bunk@stusta.de>
---
drivers/net/wireless/Kconfig | 4 +-
drivers/net/wireless/airo.c | 56 +----------------------------------
2 files changed, 5 insertions(+), 55 deletions(-)
--- linux-2.6.15-mm2-full/drivers/net/wireless/Kconfig.old 2006-01-10 20:40:12.000000000 +0100
+++ linux-2.6.15-mm2-full/drivers/net/wireless/Kconfig 2006-01-10 21:06:08.000000000 +0100
@@ -244,6 +244,7 @@
config AIRO
tristate "Cisco/Aironet 34X/35X/4500/4800 ISA and PCI cards"
- depends on NET_RADIO && ISA_DMA_API && CRYPTO && (PCI || BROKEN)
+ depends on NET_RADIO && ISA_DMA_API && (PCI || BROKEN)
+ select CRYPTO
---help---
This is the standard Linux driver to support Cisco/Aironet ISA and
PCI 802.11 wireless cards.
@@ -391,6 +392,7 @@
config AIRO_CS
tristate "Cisco/Aironet 34X/35X/4500/4800 PCMCIA cards"
depends on NET_RADIO && PCMCIA && (BROKEN || !M32R)
+ select CRYPTO
---help---
This is the standard Linux driver to support Cisco/Aironet PCMCIA
802.11 wireless cards. This driver is the same as the Aironet
--- linux-2.6.15-mm2-full/drivers/net/wireless/airo.c.old 2006-01-10 20:40:31.000000000 +0100
+++ linux-2.6.15-mm2-full/drivers/net/wireless/airo.c 2006-01-10 20:42:44.000000000 +0100
@@ -36,6 +36,7 @@
#include <linux/in.h>
#include <linux/bitops.h>
#include <linux/scatterlist.h>
+#include <linux/crypto.h>
#include <asm/io.h>
#include <asm/system.h>
@@ -87,14 +88,6 @@
#include <linux/delay.h>
#endif
-/* Support Cisco MIC feature */
-#define MICSUPPORT
-
-#if defined(MICSUPPORT) && !defined(CONFIG_CRYPTO)
-#warning MIC support requires Crypto API
-#undef MICSUPPORT
-#endif
-
/* Hack to do some power saving */
#define POWER_ON_DOWN
@@ -1118,7 +1111,6 @@
static int writerids(struct net_device *dev, aironet_ioctl *comp);
static int flashcard(struct net_device *dev, aironet_ioctl *comp);
#endif /* CISCO_EXT */
-#ifdef MICSUPPORT
static void micinit(struct airo_info *ai);
static int micsetup(struct airo_info *ai);
static int encapsulate(struct airo_info *ai, etherHead *pPacket, MICBuffer *buffer, int len);
@@ -1127,9 +1119,6 @@
static u8 airo_rssi_to_dbm (tdsRssiEntry *rssi_rid, u8 rssi);
static u8 airo_dbm_to_pct (tdsRssiEntry *rssi_rid, u8 dbm);
-#include <linux/crypto.h>
-#endif
-
struct airo_info {
struct net_device_stats stats;
struct net_device *dev;
@@ -1190,12 +1179,10 @@
unsigned long scan_timestamp; /* Time started to scan */
struct iw_spy_data spy_data;
struct iw_public_data wireless_data;
-#ifdef MICSUPPORT
/* MIC stuff */
struct crypto_tfm *tfm;
mic_module mod[2];
mic_statistics micstats;
-#endif
HostRxDesc rxfids[MPI_MAX_FIDS]; // rx/tx/config MPI350 descriptors
HostTxDesc txfids[MPI_MAX_FIDS];
HostRidDesc config_desc;
@@ -1229,7 +1216,6 @@
static int flashputbuf(struct airo_info *ai);
static int flashrestart(struct airo_info *ai,struct net_device *dev);
-#ifdef MICSUPPORT
/***********************************************************************
* MIC ROUTINES *
***********************************************************************
@@ -1686,7 +1672,6 @@
digest[2] = (val>>8) & 0xFF;
digest[3] = val & 0xFF;
}
-#endif
static int readBSSListRid(struct airo_info *ai, int first,
BSSListRid *list) {
@@ -2005,7 +1990,6 @@
* Firmware automaticly puts 802 header on so
* we don't need to account for it in the length
*/
-#ifdef MICSUPPORT
if (test_bit(FLAG_MIC_CAPABLE, &ai->flags) && ai->micstats.enabled &&
(ntohs(((u16 *)buffer)[6]) != 0x888E)) {
MICBuffer pMic;
@@ -2022,9 +2006,7 @@
memcpy (sendbuf, &pMic, sizeof(pMic));
sendbuf += sizeof(pMic);
memcpy (sendbuf, buffer, len - sizeof(etherHead));
- } else
-#endif
- {
+ } else {
*payloadLen = cpu_to_le16(len - sizeof(etherHead));
dev->trans_start = jiffies;
@@ -2400,9 +2382,7 @@
ai->shared, ai->shared_dma);
}
}
-#ifdef MICSUPPORT
crypto_free_tfm(ai->tfm);
-#endif
del_airo_dev( dev );
free_netdev( dev );
}
@@ -2726,9 +2706,7 @@
ai->thr_pid = kernel_thread(airo_thread, dev, CLONE_FS | CLONE_FILES);
if (ai->thr_pid < 0)
goto err_out_free;
-#ifdef MICSUPPORT
ai->tfm = NULL;
-#endif
rc = add_airo_dev( dev );
if (rc)
goto err_out_thr;
@@ -2969,10 +2947,8 @@
airo_read_wireless_stats(ai);
else if (test_bit(JOB_PROMISC, &ai->flags))
airo_set_promisc(ai);
-#ifdef MICSUPPORT
else if (test_bit(JOB_MIC, &ai->flags))
micinit(ai);
-#endif
else if (test_bit(JOB_EVENT, &ai->flags))
airo_send_event(dev);
else if (test_bit(JOB_AUTOWEP, &ai->flags))
@@ -3010,12 +2986,10 @@
if ( status & EV_MIC ) {
OUT4500( apriv, EVACK, EV_MIC );
-#ifdef MICSUPPORT
if (test_bit(FLAG_MIC_CAPABLE, &apriv->flags)) {
set_bit(JOB_MIC, &apriv->flags);
wake_up_interruptible(&apriv->thr_wait);
}
-#endif
}
if ( status & EV_LINK ) {
union iwreq_data wrqu;
@@ -3194,11 +3168,8 @@
}
bap_read (apriv, buffer + hdrlen/2, len, BAP0);
} else {
-#ifdef MICSUPPORT
MICBuffer micbuf;
-#endif
bap_read (apriv, buffer, ETH_ALEN*2, BAP0);
-#ifdef MICSUPPORT
if (apriv->micstats.enabled) {
bap_read (apriv,(u16*)&micbuf,sizeof(micbuf),BAP0);
if (ntohs(micbuf.typelen) > 0x05DC)
@@ -3211,15 +3182,10 @@
skb_trim (skb, len + hdrlen);
}
}
-#endif
bap_read(apriv,buffer+ETH_ALEN,len,BAP0);
-#ifdef MICSUPPORT
if (decapsulate(apriv,&micbuf,(etherHead*)buffer,len)) {
badmic:
dev_kfree_skb_irq (skb);
-#else
- if (0) {
-#endif
badrx:
OUT4500( apriv, EVACK, EV_RX);
goto exitrx;
@@ -3430,10 +3396,8 @@
int len = 0;
struct sk_buff *skb;
char *buffer;
-#ifdef MICSUPPORT
int off = 0;
MICBuffer micbuf;
-#endif
memcpy_fromio(&rxd, ai->rxfids[0].card_ram_off, sizeof(rxd));
/* Make sure we got something */
@@ -3448,7 +3412,6 @@
goto badrx;
}
buffer = skb_put(skb,len);
-#ifdef MICSUPPORT
memcpy(buffer, ai->rxfids[0].virtual_host_addr, ETH_ALEN * 2);
if (ai->micstats.enabled) {
memcpy(&micbuf,
@@ -3470,9 +3433,6 @@
dev_kfree_skb_irq (skb);
goto badrx;
}
-#else
- memcpy(buffer, ai->rxfids[0].virtual_host_addr, len);
-#endif
#ifdef WIRELESS_SPY
if (ai->spy_data.spy_number > 0) {
char *sa;
@@ -3689,13 +3649,11 @@
ai->config.authType = AUTH_OPEN;
ai->config.modulation = MOD_CCK;
-#ifdef MICSUPPORT
if ((cap_rid.len>=sizeof(cap_rid)) && (cap_rid.extSoftCap&1) &&
(micsetup(ai) == SUCCESS)) {
ai->config.opmode |= MODE_MIC;
set_bit(FLAG_MIC_CAPABLE, &ai->flags);
}
-#endif
/* Save off the MAC */
for( i = 0; i < ETH_ALEN; i++ ) {
@@ -4170,15 +4128,12 @@
}
len -= ETH_ALEN * 2;
-#ifdef MICSUPPORT
if (test_bit(FLAG_MIC_CAPABLE, &ai->flags) && ai->micstats.enabled &&
(ntohs(((u16 *)pPacket)[6]) != 0x888E)) {
if (encapsulate(ai,(etherHead *)pPacket,&pMic,len) != SUCCESS)
return ERROR;
miclen = sizeof(pMic);
}
-#endif
-
// packet is destination[6], source[6], payload[len-12]
// write the payload length and dst/src/payload
if (bap_setup(ai, txFid, 0x0036, BAP1) != SUCCESS) return ERROR;
@@ -7271,13 +7226,11 @@
case AIROGSTAT: ridcode = RID_STATUS; break;
case AIROGSTATSD32: ridcode = RID_STATSDELTA; break;
case AIROGSTATSC32: ridcode = RID_STATS; break;
-#ifdef MICSUPPORT
case AIROGMICSTATS:
if (copy_to_user(comp->data, &ai->micstats,
min((int)comp->len,(int)sizeof(ai->micstats))))
return -EFAULT;
return 0;
-#endif
case AIRORRID: ridcode = comp->ridnum; break;
default:
return -EINVAL;
@@ -7309,9 +7262,7 @@
static int writerids(struct net_device *dev, aironet_ioctl *comp) {
struct airo_info *ai = dev->priv;
int ridcode;
-#ifdef MICSUPPORT
int enabled;
-#endif
Resp rsp;
static int (* writer)(struct airo_info *, u16 rid, const void *, int, int);
unsigned char *iobuf;
@@ -7368,11 +7319,9 @@
PC4500_readrid(ai,RID_STATSDELTACLEAR,iobuf,RIDSIZE, 1);
-#ifdef MICSUPPORT
enabled = ai->micstats.enabled;
memset(&ai->micstats,0,sizeof(ai->micstats));
ai->micstats.enabled = enabled;
-#endif
if (copy_to_user(comp->data, iobuf,
min((int)comp->len, (int)RIDSIZE))) {
^ permalink raw reply
* [2.6 patch] drivers/net/wireless/ipw2100.c: make ipw2100_wpa_assoc_frame() static
From: Adrian Bunk @ 2006-01-21 0:36 UTC (permalink / raw)
To: yi.zhu, jketreno; +Cc: linville, netdev, linux-kernel
This patch makes the needlessly global ipw2100_wpa_assoc_frame() static.
Signed-off-by: Adrian Bunk <bunk@stusta.de>
--- linux-2.6.16-rc1-mm2-full/drivers/net/wireless/ipw2100.c.old 2006-01-21 00:53:47.000000000 +0100
+++ linux-2.6.16-rc1-mm2-full/drivers/net/wireless/ipw2100.c 2006-01-21 00:53:59.000000000 +0100
@@ -5771,8 +5771,8 @@
return ret;
}
-void ipw2100_wpa_assoc_frame(struct ipw2100_priv *priv,
- char *wpa_ie, int wpa_ie_len)
+static void ipw2100_wpa_assoc_frame(struct ipw2100_priv *priv,
+ char *wpa_ie, int wpa_ie_len)
{
struct ipw2100_wpa_assoc_frame frame;
^ permalink raw reply
* [2.6 patch] drivers/net/wireless/ipw2200: possible cleanups
From: Adrian Bunk @ 2006-01-21 0:39 UTC (permalink / raw)
To: yi.zhu, jketreno; +Cc: linville, netdev, linux-kernel
This patch contains the following possible cleanups:
- make needlessly global functions static
- "extern inline" -> "static inline"
- #if 0 the unused global function ipw_led_activity_on()
Signed-off-by: Adrian Bunk <bunk@stusta.de>
---
drivers/net/wireless/ipw2200.c | 33 ++++++++++++++++++---------------
drivers/net/wireless/ipw2200.h | 4 ++--
2 files changed, 20 insertions(+), 17 deletions(-)
--- linux-2.6.16-rc1-mm2-full/drivers/net/wireless/ipw2200.h.old 2006-01-21 01:15:58.000000000 +0100
+++ linux-2.6.16-rc1-mm2-full/drivers/net/wireless/ipw2200.h 2006-01-21 01:16:30.000000000 +0100
@@ -853,7 +853,7 @@
u16 dwell_time[IPW_SCAN_TYPES];
} __attribute__ ((packed));
-extern inline u8 ipw_get_scan_type(struct ipw_scan_request_ext *scan, u8 index)
+static inline u8 ipw_get_scan_type(struct ipw_scan_request_ext *scan, u8 index)
{
if (index % 2)
return scan->scan_type[index / 2] & 0x0F;
@@ -861,7 +861,7 @@
return (scan->scan_type[index / 2] & 0xF0) >> 4;
}
-extern inline void ipw_set_scan_type(struct ipw_scan_request_ext *scan,
+static inline void ipw_set_scan_type(struct ipw_scan_request_ext *scan,
u8 index, u8 scan_type)
{
if (index % 2)
--- linux-2.6.16-rc1-mm2-full/drivers/net/wireless/ipw2200.c.old 2006-01-21 00:54:24.000000000 +0100
+++ linux-2.6.16-rc1-mm2-full/drivers/net/wireless/ipw2200.c 2006-01-21 01:17:04.000000000 +0100
@@ -701,7 +701,7 @@
}
-u32 ipw_register_toggle(u32 reg)
+static u32 ipw_register_toggle(u32 reg)
{
reg &= ~IPW_START_STANDBY;
if (reg & IPW_GATE_ODMA)
@@ -726,7 +726,7 @@
#define LD_TIME_LINK_OFF 2700
#define LD_TIME_ACT_ON 250
-void ipw_led_link_on(struct ipw_priv *priv)
+static void ipw_led_link_on(struct ipw_priv *priv)
{
unsigned long flags;
u32 led;
@@ -769,7 +769,7 @@
mutex_unlock(&priv->mutex);
}
-void ipw_led_link_off(struct ipw_priv *priv)
+static void ipw_led_link_off(struct ipw_priv *priv)
{
unsigned long flags;
u32 led;
@@ -847,6 +847,7 @@
}
}
+#if 0
void ipw_led_activity_on(struct ipw_priv *priv)
{
unsigned long flags;
@@ -854,8 +855,9 @@
__ipw_led_activity_on(priv);
spin_unlock_irqrestore(&priv->lock, flags);
}
+#endif /* 0 */
-void ipw_led_activity_off(struct ipw_priv *priv)
+static void ipw_led_activity_off(struct ipw_priv *priv)
{
unsigned long flags;
u32 led;
@@ -890,7 +892,7 @@
mutex_unlock(&priv->mutex);
}
-void ipw_led_band_on(struct ipw_priv *priv)
+static void ipw_led_band_on(struct ipw_priv *priv)
{
unsigned long flags;
u32 led;
@@ -925,7 +927,7 @@
spin_unlock_irqrestore(&priv->lock, flags);
}
-void ipw_led_band_off(struct ipw_priv *priv)
+static void ipw_led_band_off(struct ipw_priv *priv)
{
unsigned long flags;
u32 led;
@@ -948,24 +950,24 @@
spin_unlock_irqrestore(&priv->lock, flags);
}
-void ipw_led_radio_on(struct ipw_priv *priv)
+static void ipw_led_radio_on(struct ipw_priv *priv)
{
ipw_led_link_on(priv);
}
-void ipw_led_radio_off(struct ipw_priv *priv)
+static void ipw_led_radio_off(struct ipw_priv *priv)
{
ipw_led_activity_off(priv);
ipw_led_link_off(priv);
}
-void ipw_led_link_up(struct ipw_priv *priv)
+static void ipw_led_link_up(struct ipw_priv *priv)
{
/* Set the Link Led on for all nic types */
ipw_led_link_on(priv);
}
-void ipw_led_link_down(struct ipw_priv *priv)
+static void ipw_led_link_down(struct ipw_priv *priv)
{
ipw_led_activity_off(priv);
ipw_led_link_off(priv);
@@ -974,7 +976,7 @@
ipw_led_radio_off(priv);
}
-void ipw_led_init(struct ipw_priv *priv)
+static void ipw_led_init(struct ipw_priv *priv)
{
priv->nic_type = priv->eeprom[EEPROM_NIC_TYPE];
@@ -1025,7 +1027,7 @@
}
}
-void ipw_led_shutdown(struct ipw_priv *priv)
+static void ipw_led_shutdown(struct ipw_priv *priv)
{
ipw_led_activity_off(priv);
ipw_led_link_off(priv);
@@ -6146,7 +6148,8 @@
return ret;
}
-void ipw_wpa_assoc_frame(struct ipw_priv *priv, char *wpa_ie, int wpa_ie_len)
+static void ipw_wpa_assoc_frame(struct ipw_priv *priv, char *wpa_ie,
+ int wpa_ie_len)
{
/* make sure WPA is enabled */
ipw_wpa_enable(priv, 1);
@@ -9977,7 +9980,7 @@
mutex_unlock(&priv->mutex);
}
-void ipw_link_up(struct ipw_priv *priv)
+static void ipw_link_up(struct ipw_priv *priv)
{
priv->last_seq_num = -1;
priv->last_frag_num = -1;
@@ -10012,7 +10015,7 @@
mutex_unlock(&priv->mutex);
}
-void ipw_link_down(struct ipw_priv *priv)
+static void ipw_link_down(struct ipw_priv *priv)
{
ipw_led_link_down(priv);
netif_carrier_off(priv->net_dev);
^ permalink raw reply
* Re: My vote against eepro* removal
From: Lee Revell @ 2006-01-21 0:40 UTC (permalink / raw)
To: Evgeniy Polyakov
Cc: kus Kusche Klaus, John Ronciak, Adrian Bunk, linux-kernel,
john.ronciak, ganesh.venkatesan, jesse.brandeburg, netdev,
Steven Rostedt
In-Reply-To: <20060120095548.GA16000@2ka.mipt.ru>
On Fri, 2006-01-20 at 12:55 +0300, Evgeniy Polyakov wrote:
> > Analysis of e100:
> > * If I comment out the whole body of e100_watchdog except for the
> > timer re-registration, the delays are gone (so it is really the
> > body of e100_watchdog). However, this makes eth0 non-functional.
> > * Commenting out parts of it, I found out that most of the time
> > goes into its first half: The code from mii_ethtool_gset to
> > mii_check_link (including) makes the big difference, as far as
> > I can tell especially mii_ethtool_gset.
>
> Each MDIO read can take upto 2 msecs (!) and at least 20 usecs in
> e100,
> and this runs in timer handler.
> Concider attaching (only compile tested) patch which moves e100
> watchdog
> into workqueue.
Seems like the important question is, why does e100 need a watchdog if
eepro100 works fine without one? Isn't the point of a watchdog in this
context to work around other bugs in the driver (or the hardware)?
Lee
^ permalink raw reply
* RE: My vote against eepro* removal
From: Lee Revell @ 2006-01-21 0:45 UTC (permalink / raw)
To: kus Kusche Klaus
Cc: Evgeniy Polyakov, John Ronciak, Adrian Bunk, linux-kernel,
john.ronciak, ganesh.venkatesan, jesse.brandeburg, netdev,
Steven Rostedt
In-Reply-To: <AAD6DA242BC63C488511C611BD51F367323325@MAILIT.keba.co.at>
On Fri, 2006-01-20 at 11:19 +0100, kus Kusche Klaus wrote:
> For a non-full preemption kernel, your patch moves the 500 us
> piece of code from kernel to thread context, so it really
> improves things. But is 500 us something to worry about in a
> non-full preemption kernel?
Yes, absolutely. Once exit_mmap (a latency regression which was
introduced in 2.6.14) and rt_run_flush/rt_garbage_collect (which have
always been problematic) are fixed, 500usecs will stick out like a sore
thumb even on a regular PREEMPT kernel.
Also, you should be able to capture this latency in /proc/latency trace
by configuring an -rt kernel with PREEMPT_DESKTOP and hard/softirq
preemption disabled.
Lee
^ permalink raw reply
* Re: [2.6 patch] schedule SHAPER for removal
From: Adrian Bunk @ 2006-01-21 0:48 UTC (permalink / raw)
To: Benjamin LaHaise; +Cc: Andrew Morton, Alan Cox, jgarzik, netdev, linux-kernel
In-Reply-To: <20060119215722.GO16285@kvack.org>
On Thu, Jan 19, 2006 at 04:57:22PM -0500, Benjamin LaHaise wrote:
> On Thu, Jan 19, 2006 at 03:11:50AM +0100, Adrian Bunk wrote:
> > +What: Traffic Shaper (CONFIG_SHAPER)
> > +When: July 2006
> > +Why: obsoleted by the code in net/sched/
> > +Who: Adrian Bunk <bunk@stusta.de
>
> This length of obsolete cycles is way too short -- it's not even enough
> time for a single release of a distro to ship with the feature marked as
> obsolete.
Do we really have to wait the three years between stable Debian releases
for removing an obsolete driver that has always been marked as
EXPERIMENTAL?
Please be serious.
> -ben
cu
Adrian
--
"Is there not promise of rain?" Ling Tan asked suddenly out
of the darkness. There had been need of rain for many days.
"Only a promise," Lao Er said.
Pearl S. Buck - Dragon Seed
^ 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