* Re: [PATCH 8/8] orinoco: New driver - spectrum_cs.
From: Pavel Roskin @ 2005-09-09 22:40 UTC (permalink / raw)
To: Christoph Hellwig; +Cc: Orinoco Development List, netdev-u79uwXL29TY76Z2rM5mHXA
In-Reply-To: <20050906112424.GA5309-wEGCiKHe2LqWVfeAwA7xHQ@public.gmane.org>
On Tue, 2005-09-06 at 12:24 +0100, Christoph Hellwig wrote:
> > +#ifdef __IN_PCMCIA_PACKAGE__
> > +#include <pcmcia/k_compat.h>
> > +#endif /* __IN_PCMCIA_PACKAGE__ */
>
> this doesn't make sense for a 2.6 driver.
Fixed in my tree, thanks. Patches will be sent shortly.
> > +#ifdef SPECTRUM_FW_INCLUDED
> > +/* Header with the firmware */
> > +#include "spectrum_fw.h"
> > +#else /* !SPECTRUM_FW_INCLUDED */
>
> While I see the point of this for the standalone orinoco driver package
> it doesn't make sense for the version in the kernel tree.
Likewise.
>
> > +#define CS_CHECK(fn, ret) \
> > + do { last_fn = (fn); if ((last_ret = (ret)) != 0) goto cs_failed; } while (0)
>
> I don't think this macro abuse helps anyone..
Sure, but it's abused by many drivers. Maybe next time.
--
Regards,
Pavel Roskin
-------------------------------------------------------
SF.Net email is Sponsored by the Better Software Conference & EXPO
September 19-22, 2005 * San Francisco, CA * Development Lifecycle Practices
Agile & Plan-Driven Development * Managing Projects & Teams * Testing & QA
Security * Process Improvement & Measurement * http://www.sqe.com/bsce5sf
^ permalink raw reply
* Re: skge: reboot on sysfs resource0 access
From: Ben Greear @ 2005-09-09 18:21 UTC (permalink / raw)
To: Stephen Hemminger; +Cc: bernd-schubert, bernd.schubert, netdev
In-Reply-To: <20050909110153.5a2e2e90@localhost.localdomain>
Stephen Hemminger wrote:
> On Fri, 9 Sep 2005 19:38:17 +0200
> Bernd Schubert <bernd.schubert@pci.uni-heidelberg.de> wrote:
>
>
>>Hello,
>>
>>today we tried 2.6.13 on our server and also tried to use the skge driver.
>>Well, in principle it works fine, until I became curious about the sysfs
>>values. Stupid me, I was using the midnight commander to read the values.
>>When I opened "/sys/bus/pci/drivers/skge/0000:01:01.0/resource0", the system
>>immediately rebooted. After the reboot we tested using cat to the resource0
>>file, which gave an input/output error. Using again the mc, the system again
>>immediately rebooted.
>>Well, I guess I better don't use the midnight commander in the future, but
>>somehow I think it shouldn't cause the system to reboot, should it? Is the
>>i/o error of cat supposed to happen?
>>
>
>
> Don't do that! resource0 is the pci space for the card and
> reading it directly accesses the memory mapped space. The
> register is sparse, and some places are unaccessable.
> Accessing non-existent memory will cause system to hang and if you
> are lucky a timeout and reboot.
>
> Sorry, this is not a driver bug.
Does that mean if you do this:
find /sys -name "*" -print|xargs grep foo
that the system will crash?
I certainly would consider that a bug, and even if that somehow works, I'd
think that at the least you should be able to read every file in the file
system without crashing the system!
Do you at least have to be root to cause this crash?
Ben
--
Ben Greear <greearb@candelatech.com>
Candela Technologies Inc http://www.candelatech.com
^ permalink raw reply
* Re: skge: reboot on sysfs resource0 access
From: Bernd Schubert @ 2005-09-09 18:09 UTC (permalink / raw)
To: Stephen Hemminger; +Cc: netdev
In-Reply-To: <20050909110153.5a2e2e90@localhost.localdomain>
On Friday 09 September 2005 20:01, you wrote:
> On Fri, 9 Sep 2005 19:38:17 +0200
>
> Bernd Schubert <bernd.schubert@pci.uni-heidelberg.de> wrote:
> > Hello,
> >
> > today we tried 2.6.13 on our server and also tried to use the skge
> > driver. Well, in principle it works fine, until I became curious about
> > the sysfs values. Stupid me, I was using the midnight commander to read
> > the values. When I opened
> > "/sys/bus/pci/drivers/skge/0000:01:01.0/resource0", the system
> > immediately rebooted. After the reboot we tested using cat to the
> > resource0 file, which gave an input/output error. Using again the mc, the
> > system again immediately rebooted.
> > Well, I guess I better don't use the midnight commander in the future,
> > but somehow I think it shouldn't cause the system to reboot, should it?
> > Is the i/o error of cat supposed to happen?
>
> Don't do that! resource0 is the pci space for the card and
> reading it directly accesses the memory mapped space. The
> register is sparse, and some places are unaccessable.
> Accessing non-existent memory will cause system to hang and if you
> are lucky a timeout and reboot.
>
> Sorry, this is not a driver bug.
Thanks, I better also won't read the resource values of the other pci-devices.
And I think I will search for some documentation of sysfs to know in the
future which values one should read and which not.
Thanks again,
Bernd
--
Bernd Schubert
Physikalisch Chemisches Institut / Theoretische Chemie
Universität Heidelberg
INF 229
69120 Heidelberg
e-mail: bernd.schubert@pci.uni-heidelberg.de
^ permalink raw reply
* Re: [PATCH] 3c59x: read current link status from phy
From: Andy Fleming @ 2005-09-09 18:08 UTC (permalink / raw)
To: Bogdan Costescu; +Cc: Linux Kernel Mailing List, Netdev
In-Reply-To: <Pine.LNX.4.63.0509091152450.23760@dingo.iwr.uni-heidelberg.de>
On Sep 9, 2005, at 05:10, Bogdan Costescu wrote:
> On Thu, 8 Sep 2005, Andy Fleming wrote:
>
>
>> Is the cost of an extra read every minute really too high?
>>
>
> You probably didn't look at the code. The MII registers are not
> exposed in the PCI space, they need to be accessed through a serial
> protocol, such that each MII register read is in fact about 200 (in
> total) of outw and inw/inl operations.
I certainly looked at the code. I'm aware that there are probably
about 150 microseconds of work, tops, to do each read. Do it outside
of interrupt time, and separate from the normal thread of the driver
(like a task struct), and it shouldn't take up that much CPU time.
And if it's being done every minute, it's really not a big deal, is it?
Anyway, it's not a big deal to me. I agree that doing only one read,
if the link is reported as up, is a good idea. I'll be sure to put
it in the next rev of the PHY Layer.
I also agree that polling should be done every 5 seconds, at least
when the link is down.
Andy Fleming
Freescale Open Source Team
^ permalink raw reply
* Re: skge: reboot on sysfs resource0 access
From: Stephen Hemminger @ 2005-09-09 18:01 UTC (permalink / raw)
To: bernd-schubert; +Cc: bernd.schubert, netdev
In-Reply-To: <200509091938.18079.bernd.schubert@pci.uni-heidelberg.de>
On Fri, 9 Sep 2005 19:38:17 +0200
Bernd Schubert <bernd.schubert@pci.uni-heidelberg.de> wrote:
> Hello,
>
> today we tried 2.6.13 on our server and also tried to use the skge driver.
> Well, in principle it works fine, until I became curious about the sysfs
> values. Stupid me, I was using the midnight commander to read the values.
> When I opened "/sys/bus/pci/drivers/skge/0000:01:01.0/resource0", the system
> immediately rebooted. After the reboot we tested using cat to the resource0
> file, which gave an input/output error. Using again the mc, the system again
> immediately rebooted.
> Well, I guess I better don't use the midnight commander in the future, but
> somehow I think it shouldn't cause the system to reboot, should it? Is the
> i/o error of cat supposed to happen?
>
Don't do that! resource0 is the pci space for the card and
reading it directly accesses the memory mapped space. The
register is sparse, and some places are unaccessable.
Accessing non-existent memory will cause system to hang and if you
are lucky a timeout and reboot.
Sorry, this is not a driver bug.
^ permalink raw reply
* TCP segmentation offload performance
From: Jan Kasprzak @ 2005-09-09 17:39 UTC (permalink / raw)
To: linux-kernel; +Cc: netdev
Hello, world!
I tried to find out whether the TCP segmentation offload
can perform better on my server than no TSO at all. My server
is dual Opteron 244 with Tyan S2882 board with the following NIC:
eth0: Tigon3 [partno(BCM95704A7) rev 2003 PHY(5704)] (PCIX:100MHz:64-bit) 10/100/1000BaseT Ethernet 00:e0:81:27:de:17
eth0: RXcsums[1] LinkChgREG[0] MIirq[0] ASF[0] Split[0] WireSpeed[1] TSOcap[1]
eth0: dma_rwctrl[769f4000]
The server runs ProFTPd with sendfile(2) enabled (and I have verified
that it is being used with strace(8)). The kernel is 2.6.12.2.
I have found that according to ethtool -k eth0 the TSO is switched
off by default. So I tried to switch it on (altough I wondered why it is
not switched on by default, provided that the hardware supports this feature).
I tried to measure the difference by downloading an ISO image of
FC4 i386 CD1 (665434112 bytes) from two hosts connected to the same
switch. I did 10 transfers of the same file with each settings, and took
the average and maximum of the last five transfers only (to avoid any
start-up temporary conditions). The client Alpha was dual Opteron 248
with Tyan S2882 board, and the client Beta was quad Opteron 848 on HP
DL-585 board.
Client TSO Average speed Max speed
Alpha off 108.7 MB/s 110.5 MB/s
Alpha on 100.9 MB/s 101.2 MB/s
Beta off 102.1 MB/s 102.4 MB/s
Beta on 93.2 MB/s 95.5 MB/s
Surprisingly enough, the tests without TSO were faster than with TSO
enabled. Looking at tcpdump it seems that the system with TSO enabled
sends only a 15 KB-sized frames to the NIC instead of full 64 KB-sized
ones:
18:45:38.993150 IP odysseus.ftp-data > alpha.33125: P 127424:143352(15928) ack 1 win 1460 <nop,nop,timestamp 2408404 698142942>
18:45:38.993203 IP odysseus.ftp-data > alpha.33125: P 143352:159280(15928) ack 1 win 1460 <nop,nop,timestamp 2408404 698142942>
So I wonder what is wrong with TSO on my hardware and whether
the TSO is expected to be faster than generating MTU-sized packets in the
TCP stack. I did not measure the CPU usage on the server, only the
network speed.
Thanks!
-Yenya
--
| Jan "Yenya" Kasprzak <kas at {fi.muni.cz - work | yenya.net - private}> |
| GPG: ID 1024/D3498839 Fingerprint 0D99A7FB206605D7 8B35FCDE05B18A5E |
| http://www.fi.muni.cz/~kas/ Journal: http://www.fi.muni.cz/~kas/blog/ |
>>> $ cd my-kernel-tree-2.6 <<<
>>> $ dotest /path/to/mbox # yes, Linus has no taste in naming scripts <<<
^ permalink raw reply
* skge: reboot on sysfs resource0 access
From: Bernd Schubert @ 2005-09-09 17:38 UTC (permalink / raw)
To: netdev; +Cc: Stephen Hemminger
Hello,
today we tried 2.6.13 on our server and also tried to use the skge driver.
Well, in principle it works fine, until I became curious about the sysfs
values. Stupid me, I was using the midnight commander to read the values.
When I opened "/sys/bus/pci/drivers/skge/0000:01:01.0/resource0", the system
immediately rebooted. After the reboot we tested using cat to the resource0
file, which gave an input/output error. Using again the mc, the system again
immediately rebooted.
Well, I guess I better don't use the midnight commander in the future, but
somehow I think it shouldn't cause the system to reboot, should it? Is the
i/o error of cat supposed to happen?
Maybe it helps, here is a strace of mc's open for a normal file:
open("/home/bernd/notes", O_RDONLY|O_NONBLOCK|O_LARGEFILE) = 6
fstat64(6, {st_mode=S_IFREG|0644, st_size=96, ...}) = 0
fcntl64(102, F_GETFL) = -1 EBADF (Bad file descriptor)
read(6, "http", 4) = 4
mmap2(NULL, 96, PROT_READ, MAP_SHARED, 6, 0) = 0x402fe000
select(5, [4], NULL, NULL, {0, 0}) = 0 (Timeout)
select(5, [4], NULL, NULL, {0, 0}) = 0 (Timeout)
write(1, "\33[1;1H\33[m\17\33[30m\33[46mFile: notes "..., 4019) = 4019
Thanks,
Bernd
--
Bernd Schubert
Physikalisch Chemisches Institut / Theoretische Chemie
Universität Heidelberg
INF 229
69120 Heidelberg
e-mail: bernd.schubert@pci.uni-heidelberg.de
--
Bernd Schubert
Physikalisch Chemisches Institut / Theoretische Chemie
Universität Heidelberg
INF 229
69120 Heidelberg
e-mail: bernd.schubert@pci.uni-heidelberg.de
^ permalink raw reply
* skge: reboot on sysfs resource0 access
From: Bernd Schubert @ 2005-09-09 17:34 UTC (permalink / raw)
To: netdev; +Cc: Stephen Hemminger
Hello,
today we tried 2.6.13 on our server and also tried to use the skge driver.
Well, in principle it works fine, until I became curious about the sysfs
values. Stupid me, I was using the midnight commander to read the values.
When I opened "/sys/bus/pci/drivers/skge/0000:01:01.0/resource0", the system
immediately rebooted. After the reboot we tested using cat to the resource0
file, which gave an input/output error. Using again the mc, the system again
immediately rebooted.
Well, I guess I better don't use the midnight commander in the future, but
somehow I think it shouldn't cause the system to reboot, should it? Is the
i/o error of cat supposed to happen?
Maybe it helps, here is a strace of mc's open for a normal file:
open("/home/bernd/notes", O_RDONLY|O_NONBLOCK|O_LARGEFILE) = 6
fstat64(6, {st_mode=S_IFREG|0644, st_size=96, ...}) = 0
fcntl64(102, F_GETFL) = -1 EBADF (Bad file descriptor)
read(6, "http", 4) = 4
mmap2(NULL, 96, PROT_READ, MAP_SHARED, 6, 0) = 0x402fe000
select(5, [4], NULL, NULL, {0, 0}) = 0 (Timeout)
select(5, [4], NULL, NULL, {0, 0}) = 0 (Timeout)
write(1, "\33[1;1H\33[m\17\33[30m\33[46mFile: notes "..., 4019) = 4019
Thanks,
Bernd
--
Bernd Schubert
Physikalisch Chemisches Institut / Theoretische Chemie
Universität Heidelberg
INF 229
69120 Heidelberg
e-mail: bernd.schubert@pci.uni-heidelberg.de
^ permalink raw reply
* Re: Fw: masquerading failure for at least icmp and tcp+sack on amd64
From: Patrick McHardy @ 2005-09-09 11:41 UTC (permalink / raw)
To: Marc Lehmann; +Cc: Andrew Morton, netdev, Netfilter Development Mailinglist
In-Reply-To: <20050907215213.GB8222@schmorp.de>
Marc Lehmann wrote:
> It's also a 64-bit-only problem. To verify, I tried this:
>
> ethtool -K eth1 rx off tx off sg off
>
> Where eth1 is the interface where pppoe runs over.
>
> ethtool -k eth1 then displayed:
>
> rx-checksumming: off
> tx-checksumming: off
> scatter-gather: off
> tcp segmentation offload: off
>
> And ICMP, TCP etc. starts working again.
>
> Thanks for the analysis and the hint, I guess that verifies that its hw
> checksumming. (Weird that hw checksumming on the underlying device somehow
> changes the ppp packets, but nevertheless).
I tried reproducing the problem without any luck. Its odd that its
happening on both eth and ppp devices, if it was just ppp I would
suspect some missing checksum update/invalidation in the ppp driver.
What network driver are you using? Please also send a list of loaded
modules and iptables rules. Thanks.
^ permalink raw reply
* Re: [PATCH] 3c59x: read current link status from phy
From: Neil Horman @ 2005-09-09 11:35 UTC (permalink / raw)
To: Andrew Morton
Cc: Tommy Christensen, linville, Bogdan.Costescu, jgarzik,
linux-kernel, netdev
In-Reply-To: <20050909004406.52a37476.akpm@osdl.org>
On Fri, Sep 09, 2005 at 12:44:06AM -0700, Andrew Morton wrote:
> Tommy Christensen <tommy.christensen@tpack.net> wrote:
> >
> > John W. Linville wrote:
> > > Any chance you could re-diff this to apply on top of the patch posted
> > > earlier today by Neil Horman?
> >
> > Sure, but his patch didn't apply to -git8.
> >
> > If Neil would please resend, then I can diff against that.
> >
>
> Is OK, I'll sort it all out.
Thanks all, I appreciate it.
Neil
--
/***************************************************
*Neil Horman
*Software Engineer
*gpg keyid: 1024D / 0x92A74FA1 - http://pgp.mit.edu
***************************************************/
^ permalink raw reply
* Re: [PATCH] 3c59x: read current link status from phy
From: Bogdan Costescu @ 2005-09-09 10:10 UTC (permalink / raw)
To: Andy Fleming; +Cc: Linux Kernel Mailing List, Netdev
In-Reply-To: <62AA8EFA-7D65-4E87-B71F-55A07321011E@freescale.com>
On Thu, 8 Sep 2005, Andy Fleming wrote:
> The new PHY Layer (drivers/net/phy/*) can provide all these features
> for you without much difficulty, I suspect.
As pointed to be Andrew a few days ago, this driver supports a lot of
chips - for most of them the test hardware would be hard to come by
and the documentation even more. Unless you'd like to do it based on
"whoever is interested should cry loud"...
> The layer supports handling the interrupts for you, or (if it's
> shared with your controller's interrupt)
Yes, there is only one interrupt that for data transmission (both Tx
and Rx), statistics, errors and (for those chips that support it) link
state change.
> Is the cost of an extra read every minute really too high?
You probably didn't look at the code. The MII registers are not
exposed in the PCI space, they need to be accessed through a serial
protocol, such that each MII register read is in fact about 200 (in
total) of outw and inw/inl operations.
--
Bogdan Costescu
IWR - Interdisziplinaeres Zentrum fuer Wissenschaftliches Rechnen
Universitaet Heidelberg, INF 368, D-69120 Heidelberg, GERMANY
Telephone: +49 6221 54 8869, Telefax: +49 6221 54 8868
E-mail: Bogdan.Costescu@IWR.Uni-Heidelberg.De
^ permalink raw reply
* Re: [PATCH] 3c59x: read current link status from phy
From: Andrew Morton @ 2005-09-09 7:44 UTC (permalink / raw)
To: Tommy Christensen
Cc: linville, Bogdan.Costescu, jgarzik, linux-kernel, netdev, nhorman
In-Reply-To: <43213B18.3020606@tpack.net>
Tommy Christensen <tommy.christensen@tpack.net> wrote:
>
> John W. Linville wrote:
> > Any chance you could re-diff this to apply on top of the patch posted
> > earlier today by Neil Horman?
>
> Sure, but his patch didn't apply to -git8.
>
> If Neil would please resend, then I can diff against that.
>
Is OK, I'll sort it all out.
^ permalink raw reply
* Re: [PATCH] 3c59x: read current link status from phy
From: Tommy Christensen @ 2005-09-09 7:34 UTC (permalink / raw)
To: John W. Linville
Cc: Bogdan Costescu, Jeff Garzik, Linux Kernel Mailing List,
Andrew Morton, Netdev List, nhorman
In-Reply-To: <20050909010816.GA28653@tuxdriver.com>
John W. Linville wrote:
> Any chance you could re-diff this to apply on top of the patch posted
> earlier today by Neil Horman?
Sure, but his patch didn't apply to -git8.
If Neil would please resend, then I can diff against that.
-Tommy
^ permalink raw reply
* Re: [PATCH] 3c59x: read current link status from phy
From: John W. Linville @ 2005-09-09 1:08 UTC (permalink / raw)
To: Tommy Christensen
Cc: Bogdan Costescu, Jeff Garzik, Linux Kernel Mailing List,
Andrew Morton, Netdev List, nhorman
In-Reply-To: <4320BD96.3060307@tpack.net>
On Fri, Sep 09, 2005 at 12:39:18AM +0200, Tommy Christensen wrote:
> --- linux-2.6.13-git8/drivers/net/3c59x.c-orig Fri Sep 9 00:05:49 2005
> +++ linux-2.6.13-git8/drivers/net/3c59x.c Fri Sep 9 00:13:55 2005
> @@ -1889,7 +1889,9 @@ vortex_timer(unsigned long data)
> {
> spin_lock_bh(&vp->lock);
> mii_status = mdio_read(dev, vp->phys[0], 1);
> - mii_status = mdio_read(dev, vp->phys[0], 1);
> + if (!(mii_status & BMSR_LSTATUS))
> + /* Re-read to get actual link status */
> + mii_status = mdio_read(dev, vp->phys[0], 1);
> ok = 1;
> if (vortex_debug > 2)
> printk(KERN_DEBUG "%s: MII transceiver has status %4.4x.\n",
Any chance you could re-diff this to apply on top of the patch posted
earlier today by Neil Horman?
Thanks,
John
--
John W. Linville
linville@tuxdriver.com
^ permalink raw reply
* Re: [PATCH] 3c59x: read current link status from phy
From: Jeff Garzik @ 2005-09-09 0:01 UTC (permalink / raw)
To: Tommy Christensen; +Cc: Andrew Morton, Bogdan.Costescu, linux-kernel, netdev
In-Reply-To: <4320C555.4020800@tpack.net>
Tommy Christensen wrote:
> Andrew Morton wrote:
>
>> Should we also decrease the polling interval? Perhaps only when the
>> cable
>> is unplugged?
>
>
> Sounds like a plan. 60 seconds certainly strikes me as being very slow.
> OTOH, I'm not aware of the reasoning behind this choice in the first place.
> It might make sense for some odd setups.
>
> Since I don't even have any HW to play around with, I think I'll step
> down for now.
The standard for Becker drivers is 5 seconds if link is down, and 60
seconds if link is up, IIRC.
Jeff
^ permalink raw reply
* Re: [PATCH] 3c59x: read current link status from phy
From: Tommy Christensen @ 2005-09-08 23:12 UTC (permalink / raw)
To: Andrew Morton; +Cc: Bogdan.Costescu, jgarzik, linux-kernel, netdev
In-Reply-To: <20050908154114.69307f92.akpm@osdl.org>
Andrew Morton wrote:
> Should we also decrease the polling interval? Perhaps only when the cable
> is unplugged?
Sounds like a plan. 60 seconds certainly strikes me as being very slow.
OTOH, I'm not aware of the reasoning behind this choice in the first place.
It might make sense for some odd setups.
Since I don't even have any HW to play around with, I think I'll step
down for now.
-Tommy
^ permalink raw reply
* Re: [PATCH] 3c59x: read current link status from phy
From: Andrew Morton @ 2005-09-08 22:41 UTC (permalink / raw)
To: Tommy Christensen; +Cc: Bogdan.Costescu, jgarzik, linux-kernel, netdev
In-Reply-To: <4320BD96.3060307@tpack.net>
Tommy Christensen <tommy.christensen@tpack.net> wrote:
>
> In order to spare some I/O operations, be more intelligent about
> when to read from the PHY.
Seems sane.
Should we also decrease the polling interval? Perhaps only when the cable
is unplugged?
^ permalink raw reply
* Re: [PATCH] 3c59x: read current link status from phy
From: Tommy Christensen @ 2005-09-08 22:39 UTC (permalink / raw)
To: Bogdan Costescu
Cc: Jeff Garzik, Linux Kernel Mailing List, Andrew Morton,
Netdev List
In-Reply-To: <Pine.LNX.4.63.0509081713500.22954@dingo.iwr.uni-heidelberg.de>
[-- Attachment #1: Type: text/plain, Size: 984 bytes --]
Bogdan Costescu wrote:
> I now understood what the problem was, so I'll put it in words for
> posterity: the Link Status bit of the MII Status register needs to be
> read twice to first clear the error state (link bit=0) after which the
> bit reports the actual value of the link. From the manual:
Yes, this is exactly the point.
> But I still don't agree with your solution: you are reading the Status
> register twice in all cases, which is wrong. What you want is to read it
> a second time only after the link was marked as down: a simple check if
> bit 2 of the Status register is 0, in which case you issue the second
> read. This still means that there will be 2 reads if the link remains
> down, but at least there is only 1 read for the case where the link is
> up and remains up.
I don't think this makes much of a difference in the big picture, but
you're certainly right: let's not waste more cycles than we have to.
Can we agree on the patch below?
-Tommy
[-- Attachment #2: 3c59x-carrier.patch --]
[-- Type: text/plain, Size: 806 bytes --]
[3c59x] Avoid blindly reading link status twice
In order to spare some I/O operations, be more intelligent about
when to read from the PHY.
Pointed out by Bogdan Costescu.
Signed-off-by: Tommy S. Christensen <tommy.christensen@tpack.net>
--- linux-2.6.13-git8/drivers/net/3c59x.c-orig Fri Sep 9 00:05:49 2005
+++ linux-2.6.13-git8/drivers/net/3c59x.c Fri Sep 9 00:13:55 2005
@@ -1889,7 +1889,9 @@ vortex_timer(unsigned long data)
{
spin_lock_bh(&vp->lock);
mii_status = mdio_read(dev, vp->phys[0], 1);
- mii_status = mdio_read(dev, vp->phys[0], 1);
+ if (!(mii_status & BMSR_LSTATUS))
+ /* Re-read to get actual link status */
+ mii_status = mdio_read(dev, vp->phys[0], 1);
ok = 1;
if (vortex_debug > 2)
printk(KERN_DEBUG "%s: MII transceiver has status %4.4x.\n",
^ permalink raw reply
* RE: IPW2100 Kconfig
From: Alejandro Bonilla @ 2005-09-08 21:17 UTC (permalink / raw)
To: 'Bharath Ramesh', 'Pavel Machek'; +Cc: netdev, linux-kernel
In-Reply-To: <c775eb9b05090814114f258dc9@mail.gmail.com>
> AFAIK hotplug looks for firmware in /lib/firmware and not
> /etc/firmware.
>
> On 9/8/05, Pavel Machek <pavel@ucw.cz> wrote:
> > Hi!
> >
> > > I checked the IPW2100 in the current git from
> linux-2.6 and the menuconfig
> > > help (Kconfig) says you need to put the firmware in
> /etc/firmware, it should
> > > be /lib/firmware.
> > >
> > > Who should I send the "patch" to? Or can someone simply
> change that?
> >
> > Are you sure it is not distro-dependend?
> > --
Right, IPW2100 came with Legacy fw load first. Maybe that was dragged from
long time ago and used incorrectly.
I'm 100% sure that new versions of hotplug try to look at /lib/firmware and
was /usr/lib/hotplug/firmware before, but there was some discussion that
/lib would make more sense cause /usr could be dependant on other stuff.
Jesper already signed the patch.
.Alejandro
^ permalink raw reply
* Re: IPW2100 Kconfig
From: Bharath Ramesh @ 2005-09-08 21:11 UTC (permalink / raw)
To: Pavel Machek; +Cc: Alejandro Bonilla, netdev, linux-kernel
In-Reply-To: <20050908080106.GB773@openzaurus.ucw.cz>
AFAIK hotplug looks for firmware in /lib/firmware and not /etc/firmware.
On 9/8/05, Pavel Machek <pavel@ucw.cz> wrote:
> Hi!
>
> > I checked the IPW2100 in the current git from linux-2.6 and the menuconfig
> > help (Kconfig) says you need to put the firmware in /etc/firmware, it should
> > be /lib/firmware.
> >
> > Who should I send the "patch" to? Or can someone simply change that?
>
> Are you sure it is not distro-dependend?
> --
> 64 bytes from 195.113.31.123: icmp_seq=28 ttl=51 time=448769.1 ms
>
> -
> To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
> the body of a message to majordomo@vger.kernel.org
> More majordomo info at http://vger.kernel.org/majordomo-info.html
> Please read the FAQ at http://www.tux.org/lkml/
>
^ permalink raw reply
* Re: [AX.25] Make asc2ax thread-proof
From: David S. Miller @ 2005-09-08 20:41 UTC (permalink / raw)
To: ralf; +Cc: netdev, linux-hams
In-Reply-To: <20050907143401.GC3493@linux-mips.org>
From: Ralf Baechle DL5RB <ralf@linux-mips.org>
Date: Wed, 7 Sep 2005 15:34:01 +0100
> Asc2ax was still using a static buffer for all invocations which isn't
> exactly SMP-safe. Change asc2ax to take an additional result buffer as
> the argument. Change all callers to provide such a buffer.
>
> This one only really is a fix for ROSE and as per recent discussions
> there's still much more to fix in ROSE ...
>
> Signed-off-by: Ralf Baechle DL5RB <ralf@linux-mips.org>
Applied, thanks Ralf.
^ permalink raw reply
* Re: [PATCH] 3c59x: read current link status from phy
From: Andy Fleming @ 2005-09-08 18:56 UTC (permalink / raw)
To: Bogdan Costescu; +Cc: Linux Kernel Mailing List, Netdev
In-Reply-To: <Pine.LNX.4.63.0509081713500.22954@dingo.iwr.uni-heidelberg.de>
On Sep 8, 2005, at 10:42, Bogdan Costescu wrote:
> On Thu, 8 Sep 2005, Tommy Christensen wrote:
>
>> Personally, I'd prefer the delay to be < 10 seconds.
>>
>
> If you sample every 60 seconds ? Teach Shannon how to do it ;-)
>
> If you mean to reduce the sampling period, there is a very good
> reason not to do it: these MDIO operations are expensive - it's a
> serial protocol. vortex_timer() might do 2 (and with the discussed
> change - 3) of them - there are better things to do for the CPU
> than wait for these I/O operations. Plus, vortex_timer() also
> disables the interrupt...
>
> The Tornado and at least some Cyclone chips support generating an
> interrupt whenever the link changes, which can be used instead of
> polling for link state. This feature is not used in the 3c59x
> driver and could give you much less than 10 seconds accuracy - but
> you have to code it. ;-)
The new PHY Layer (drivers/net/phy/*) can provide all these features
for you without much difficulty, I suspect. The layer supports
handling the interrupts for you, or (if it's shared with your
controller's interrupt) provides simple hooks to make supporting
interrupts easy.
Is the cost of an extra read every minute really too high? It's such
a small fraction of the CPU time, and provides a better user experience.
^ permalink raw reply
* netdev branch - kernel panic - bug in tcp_time_to_recover ?
From: Mateusz Berezecki @ 2005-09-08 17:39 UTC (permalink / raw)
To: netdev; +Cc: linux-kernel
[-- Attachment #1: Type: text/plain, Size: 1100 bytes --]
Hello List,
Today I builded recent git snapshot of netdev tree and after a while i
get this (hand noted due to hard lockup - no oops in syslog)
Oops: 0000 [#1]
Modules linked in:
CPU: 0
EIP: 0060:[<c03d3162>] Not tainted VLI
EFLAGS: 00010246 (2.6.13-netdev)
EIP is at tcp_time_to_recover+0x62/0xbf
eax: 00920635 ebx: ffffffff ecx: cd1afb90 edx: 00000000
esi: 00000000 edi: cd1afb90 ebp: c05c60b0 esp: c05c6d9c
es = ds: 007b ss : 0068
process: cc1
stack: ... (i can put details here later in next post if you want - im
in hurry now)
call trace:
show_stack
show_registers
die
do_page_fault
error_code
tcp_fastretrans_alert+0x132
tcp_ack
tcp_rcv_established
tcp_v4_do_rcv
tcp_v4_recv
ip_local_deliver
...
as I stated above, I can repost with more details later in the evening
as I'm in hurry now.
kind regards,
Mateusz
--
@..@ Mateusz Berezecki
(----) mateuszb@gmail.com http://mateusz.agrest.org
( >__< ) PGP: 5F1C 86DF 89DB BFE9 899E 8CBE EB60 B7A7 43F9 5808
^^ ~~ ^^
[-- Attachment #2: Type: application/pgp-signature, Size: 189 bytes --]
^ permalink raw reply
* Re: 2.6.13-git7 strange system freeze
From: Jens Axboe @ 2005-09-08 15:46 UTC (permalink / raw)
To: Michal Piotrowski; +Cc: LKML, netdev, akpm, David S. Miller
In-Reply-To: <6bffcb0e050908083822616326@mail.gmail.com>
On Thu, Sep 08 2005, Michal Piotrowski wrote:
> Hi,
>
> kernel: 2.6.13-mm2
>
> it happens when I try to download new gnome-2.12 livecd from bittorrent.
>
> ng02:/home/michal# tail /var/log/kern.log
> [..]
> Sep 8 17:15:39 ng02 kernel: [ 3241.479108] KERNEL: assertion
> ((int)tp->lost_out >= 0) failed at net/ipv4/tcp_input.c (2148)
> Sep 8 17:15:39 ng02 kernel: [ 3241.479192] KERNEL: assertion
> ((int)tp->lost_out >= 0) failed at net/ipv4/tcp_input.c (1127)
> Sep 8 17:15:39 ng02 kernel: [ 3241.479736] KERNEL: assertion
> ((int)tp->lost_out >= 0) failed at net/ipv4/tcp_input.c (1127)
> Sep 8 17:15:39 ng02 kernel: [ 3241.831114] KERNEL: assertion
> ((int)tp->lost_out >= 0) failed at net/ipv4/tcp_input.c (2148)
> Sep 8 17:15:40 ng02 kernel: [ 3242.103942] KERNEL: assertion
> ((int)tp->lost_out >= 0) failed at net/ipv4/tcp_input.c (2148)
> Sep 8 17:15:40 ng02 kernel: [ 3242.103951] Leak l=4294967295 3
Same thing happens in -git from this morning.
--
Jens Axboe
^ permalink raw reply
* RE: Git broken for IPW2200
From: Alejandro Bonilla @ 2005-09-08 15:45 UTC (permalink / raw)
To: 'Joe Bob Spamtest'
Cc: netdev, ieee80211-devel, 'linux-kernel'
In-Reply-To: <432057D6.3010208@spamtest.viacore.net>
> IPW2200 requires a different ieee80211 stack, this can be had at
> ieee80211.sourceforge.net
Joe,
The stack is already in mainline in Linus Git. I should not need to
download the ieee80211 from any place but compile with the one in the
kernel.
.Alejandro
>
>
> Alejandro Bonilla Beeche wrote:
> > Hi,
> >
> > Where does one report this? I was building Linus Git
> tree as per I
> > updated it at 09/07/2005 7:00PM PDT and got this while compiling.
> >
> > Where do I report this?
> >
> > Debian unstable updated at same time.
> >
> > it looks like ipw2200 is thinking that ieee80211 is not
> compiled in, but
> > I did select it as a module?
> >
> > drivers/net/wireless/ipw2200.c:6676: error: dereferencing pointer to
^ 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