* Re: TCP not retransmitting supposedly lost segment
From: Florian Zumbiehl @ 2006-04-23 23:56 UTC (permalink / raw)
To: Herbert Xu; +Cc: netdev
In-Reply-To: <20060423122718.GA16504@gondor.apana.org.au>
Hi,
> This tells us that the kernel was indeed retransmitting but the
> packet didn't make it out of the interface according to your
> tcpdump.
Well, at least the tcp part of it, it seems, yep. The debugging I've
done so far also seems to confirm that the problem is somewhere beyond
the tcp code, but I don't have any real clue yet ...
> Do you have any firewall rules? Any tc rules?
ip6tables rules, yes, but none in the filter/OUTPUT chain (and policy
ACCEPT, of course) and only counting rules in mangle/OUTPUT (using
only user-defined chains and target RETURN, with policy ACCEPT, once
again).
So i'd wonder if that'd be the cause of the problem.
BTW, other TCP/IPv6 (IRC) connections active at the same time work
without problems - but each of them fails in that way now and
then ...
Well, all in all that probably doesn't help you much - but any
hints as to how/where to further debug are welcome :-)
Florian
^ permalink raw reply
* Re: Congestion Avoidance Monitoring Tools
From: Hagen Paul Pfeifer @ 2006-04-23 22:52 UTC (permalink / raw)
To: Stephen Hemminger; +Cc: piet, netdev, linux-net
In-Reply-To: <20060421081917.34ea952b@localhost.localdomain>
* Stephen Hemminger | 2006-04-21 08:19:17 [-0700]:
>2.6.13 still had lots of problems, things didn't really get working
>right till 2.6.15 or later. Especially with TSO.
--verbose?
>I have a tool using kprobe's see http://developer.osdl.org/shemminger/prototypes/tcpprobe.tar.gz
>I try to keep it up to date with current kernel and build process, last used it
>on 2.6.16.
wget http://developer.osdl.org/shemminger/prototypes/tcpprobe.tar.gz
Ended with following error code: ;-)
00:32:48 ERROR 403: Forbidden.
HGN
--
Microsoft is to software what McDonalds is to gourmet cooking.
^ permalink raw reply
* Re: [Fireflier-devel] Re: [PATCH][RFC] Security marking
From: Török Edwin @ 2006-04-23 18:57 UTC (permalink / raw)
To: netdev; +Cc: James Morris, Patrick McHardy, fireflier-devel
In-Reply-To: <Pine.LNX.4.64.0604172051510.20174@d.namei>
On Tuesday 18 April 2006 04:01, James Morris wrote:
> On Mon, 17 Apr 2006, edwin@gurde.com wrote:
> > Secmark, or skfilter is exactly what fireflier needs to solve the shared
> > socket issue. Thanks for working on this. If this gets integrated in
> > mainline, fireflier LSM will be dropped.
>
> I think you probably need skfilter as a standalone option.
I'll use skfilter then.
>
> > Is it possible to have an SELinux policy that reinjects the packets if
> > didn't match any rules? I.e. if a program that listens on port 80 doesn't
> > have access to the packet, (because it doesn't have the proper domain,)
> > and the SELinux won't allow the program to read the packet: is it
> > possible to reinject this packet in the netfilter chain, instead of
> > dropping it?
> >
> > This would allow creating rules interactively (fireflier).
>
> This could be done with nfqueue, modular policy and a pretty simple tool.
How do I determine if the policy needs to be changed? I.e. how do I determine
if the packet would be dropped? You say packets are silently dropped, won't
they generate an avc denied at least? (at least the first time?)
Once I determine that, I understand what you are saying:
catch the packet with a nfqueue target, and write a proper "allow my_t
my_packet_t:packet { recv }" to a modular policy .te file, build that as
a .pp, and load it using semodule (or libsemanage).
> > P.S.: Where can I get the full secmark patches, so I can test them to see
> > if they really fit my needs? Do you have an estimate timeline for
> > mainline integration? (in terms of n weeks, m months)
>
> The rest of the secmark related patches don't exist yet, I posted the core
> changes needed, and the others will be SELinux-specific. Mainline
> integration would hopefully be 2.6.18, if it all works out ok.
Sounds good.
>
>
> If you're looking for skfilter:
> http://people.redhat.com/jmorris/selinux/skfilter/
Thanks, I know , I tested them already.
>
> Patrick McHardy has some ideas on resolving some of the skfilter issues.
Patrick what is the status of solving the skfilter issues? Can I help with
testing patches, etc.?
On Monday 20 February 2006 18:42, Patrick McHardy wrote:
> Confirmation of conntrack entries. They shouldn't be confirmed before
> packets have passed the socket hooks. This is the tricky part because
> we don't know if packets will be delivered to a raw socket or not
> when calling the regular LOCAL_IN hook.
> The only way to solve this
> seems to be to use the socket hooks for all incoming packets, that
> way we can defer confirmation unconditionally.
Are there any problems with using socket hooks for all packets?
> The nicest way would
> be to just move the regular LOCAL_IN hook to the socket hooks, but
> this doesn't work with SNAT in LOCAL_IN because the socket lookup
> needs the already NATed address.
Move just the non SNAT part of LOCAL_IN to socket hooks?(does this make
sense?)
As you can see at http://fireflier.isgeeky.com/wiki/Ipt_fireflier_test,
skfilter is working, although my test case was a very simple one.
Could you provide a simple testcase where skfilter is not working right
(conntrack...), so that I can test it too?
I applied only the ipv4 iptables related patches , there were a few failures
due to the move to x_tables, but I think I solved them correctly. So here are
the patch I actually applied:
http://edwintorok.googlepages.com/linux-2.6.16.1-skfilter.patch, let me know
if there is something wrong there.
P.S.: Fireflier will use SELinux for labeling processes (and sockets), and
skfilter to do the actual filtering
Cheers,
Edwin
^ permalink raw reply
* Re: [Bugme-new] [Bug 6430] New: ipsec tunnel : reply is not forwarded
From: Andrew Morton @ 2006-04-23 19:53 UTC (permalink / raw)
To: bugme-daemon; +Cc: astier.raphael, netdev
In-Reply-To: <200604231526.k3NFQ5dO010175@fire-2.osdl.org>
bugme-daemon@bugzilla.kernel.org wrote:
>
> http://bugzilla.kernel.org/show_bug.cgi?id=6430
>
> Summary: ipsec tunnel : reply is not forwarded
> Kernel Version: 2.6.14.5
> Status: NEW
> Severity: normal
> Owner: shemminger@osdl.org
> Submitter: astier.raphael@free.fr
>
>
> Most recent kernel where this bug did not occur: 2.6.14
> Distribution: debian sarge 3.1
> Hardware Environment:
> Software Environment: isakmpd
> Problem Description:
> The situation is the following :
> hostA -- GW1 <==> GW2 -- hostB, with an ipsec tunnel between GW1 and GW2.
> Encryption : des-cbc, Auth : hmac-md5, and automatic keyring with isakmpd
> on GW1 and GW2.
> The tunnel is correctly mounted, with symmetrical spi on both sides GW1 and GW2.
> (I have verified with setkey)
> When hostA ping hostB, packets are correctly send to hostB, and returns
> to GW1, and are decrypted here, but are not forwarded to hostA.
> (Symmetrically when hostB ping hostA packet returned on GW2 are not
> forwarded to hostB). I have verified with tcpdump.
> I have try exactly the same configuration with standard kernel 2.6.8 from
> sarge distrib. and it works perfectly.
> I also try to echo 0 > /proc/...eth0/rp_filter where eth0 is the interface on
> GW2 "connected" to GW1 but result is the same.
> I have also try replacing GW2 by a Cisco PIX, and I have same result
> on linux (2.6.14.5) GW1.
>
> Steps to reproduce:
> Configure an ipsec tunnel between GW1 and GW2 as described above. I have done
> it with isakmpd, and with standard support of ipsec in kernel, not with
> freeswan.
>
That's quite an old kernel. Are you able to test 2.6.16?
^ permalink raw reply
* Your Awaiting Payment ...
From: Revd. Fr.Fredrick Nelson @ 2006-04-23 19:30 UTC (permalink / raw)
To: netdev
OFFICE OF REVD.FR FREDRICK NELSON
DIRECTOR SPECIAL DUTIES, UNITED NATIONS ORGANISATION
IN CONJUNCTION WITH THE INTERNATIONAL MONETARY FUND
WORLD BANK FACT-FINDING & SPECIAL DUTIES OFFICE
DAKAR, SENEGAL.
TEL: + 221 5545692
EMAIL:fr.frednelson@katamail.com
Dear Friend.
I am Revd. Fr.Fredrick Nelson, a senior staff with
the World Bank fact finding & special duties office.
I am writing you this letter based on the fact that
cool penny is better than millions of dollars means
it's better for one to live and die poor honest man
than a rich dishonest one.
I and the Chief security officer (CSO) of this
organization have arranged with an officer in the
computer section Engineer Peter Cliff to bring out
part of your total pending payment with reference
number (LM-05-371) amounting to US$10 million. Why we
did this is because according to information gathered
from the banks security computer, you have been
waiting for a long time to receive this payment
without success. As I found out that you have almost
met all the statutory requirements in respect of your
pending payment. The problem we feel you are having
is that of interest groups. A lot of people are
interested in your payment and those people are
merely doing paper works with you and that explains
why you receive different kinds of untrue email and
phone messages from different people everyday. For
security reasons you do not have to tell anybody that
your have your payment on the way until the payment
gets to you.
The said payment is been arranged in a security-proof
box weighing 75kg. In order to get this box shipped
to you I and the (CSO) Yesterday went to this four
courier companies Dhl, Ems, FedEx and Ups to make
arrangements on how to get the box shipped to you by
courier, but to no avail the above courier companies
all made us to understand that they will have to open
the box for inspection by the customs before
shipment. This is something we want to avoid because
this box is been padded with synthetic nylon and to
open it you will have to cut the pad before you will
meet the button that you will press to open the dial
code-lock. There is no way you can open the box and
be able to close it again because it was padded with
machine. We told the courier services that the box
contained film materials and when open will spoil the
materials. N B: we did not declare money because
courier does not carry money.
Today a friend of mine who is diplomat disclosed to
me that there is a security courier service company
that is specialized in sending diplomatic materials
and information from one country to another, which
also has diplomatic immunity and consignment such as
this, cannot be checked by any customs anywhere in
the world. I have therefore met the official of the
security courier service and concluded shipping
arrangement with them, which they will commence as
soon as I have your go ahead order. The diplomat who
will be bring in this consignment to you is an expert
and has been in this line of work for many years now
so we have Nothing to worry about. After all
arrangements we have concluded that you must donate
Five Hundred Thousand United States dollars
(US$500,000.00) to any charity organization I
designate as soon as you receive your money. To this
effect, you will send to us a promissory note for the
donation along with your address where you will like
the box to be delivered by courier. Please maintain
topmost secrecy as it may cause a lot of problems if
found out that we are using this way to help you. You
are advised not to inform anyone about this until you
received your money. Am helping you on this because
something in me is tells me that you are an honest
person. When you conclude this and you send our
promise, we will help to ship the final part of your
money to you.
May God be with you as i wait for your response
through this Email:fr.frednelson@katamail.com . Feel free to call
me if you will like us to discuses more on this TEL:
+ 221 5545692.
Yours Faithfully
Revd. Fr.Fredrick Nelson
Director, Special Duties. UNO/WBF
^ permalink raw reply
* Re: via_rhine/qdisc Dead loop on netdevice eth1, fix it urgently!
From: James Bourne @ 2006-04-23 17:04 UTC (permalink / raw)
To: Herbert Xu; +Cc: netdev
In-Reply-To: <20060423113107.GA16193@gondor.apana.org.au>
On Sun, 23 Apr 2006, Herbert Xu wrote:
> On Fri, Apr 14, 2006 at 03:51:15PM +0000, James Bourne wrote:
>>
>> Apr 14 08:32:54 bama kernel: [<c02becbb>] netpoll_send_skb+0xa8/0x100 [<f8c4c174>] write_msg+0x140/0x181 [netconsole]
>
> This is the culprit. Disable that and the problem will go away.
That's done now, but... This has been happening for a while now, and I had
enabled netdump/netconsole to try and troubleshoot the problem if there was
a crash involved (which unfortunately there never has been).
Thanks though, and if/when it happens I'll let you know.
Regards
James
>
> Cheers,
>
--
James Bourne | Email: jbourne@hardrock.org
UNIX Systems Administration | WWW: http://www.hardrock.org
Custom UNIX Programming | Linux: The choice of a GNU generation
----------------------------------------------------------------------
"All you need's an occasional kick in the philosophy." Frank Herbert
^ permalink raw reply
* Re: Van Jacobson's net channels and real-time
From: Ingo Oeser @ 2006-04-23 14:15 UTC (permalink / raw)
To: David S. Miller; +Cc: netdev, simlo, linux-kernel, mingo, netdev
In-Reply-To: <20060422.225639.93889487.davem@davemloft.net>
Hi Dave,
On Sunday, 23. April 2006 07:56, David S. Miller wrote:
> > If cacheline bouncing because of the shared filled_entries becomes an issue,
> > you are receiving or sending a lot.
>
> Cacheline bouncing is the core issue being addressed by this
> data structure, so we really can't consider your idea seriously.
Ok, I can see it now more clearly. Many thanks for clearing that up
in the other replies. I had a major misunderstanding there.
> I've just got an off-by-one error, no need to wreck the entire
> data structure just to solve that :-)
Yes, you are right. But even then I can still implement the
reserve/commit once you provide the helpers for
producer_space and consumer_space.
Regards
Ingo Oeser
^ permalink raw reply
* Re: [PATCH 00/10] e1000: Driver fixes and update to 7.0.38-k2
From: Auke Kok @ 2006-04-23 14:13 UTC (permalink / raw)
To: David S. Miller
Cc: herbert, jgarzik, auke-jan.h.kok, netdev, john.ronciak,
jesse.brandeburg, Jeffrey.t.kirsher, auke
In-Reply-To: <20060422.225345.125621531.davem@davemloft.net>
David S. Miller wrote:
> From: Herbert Xu <herbert@gondor.apana.org.au>
> Date: Sat, 22 Apr 2006 15:22:54 +1000
>
>> Jeff Garzik <jgarzik@pobox.com> wrote:
>>>> 05/10: [PATCH] Update truesize with the length of the packet for
>>>> packet split
>>> These 10 patches look OK, but since the current kernel version is
>>> 2.6.17-rc1, that means we are in "bug fix only" mode right now.
>>>
>>> Should I (a) apply these all to netdev2-.6.git#upstream, queueing them
>>> for 2.6.18, or (b) let you split the submission into two parts, bug
>>> fixes only and everything else?
>> It turns out that the truesize patch is pretty important as otherwise
>> most of TCP receive socket buffer accounting falls apart. So it should
>> probably go into 2.6.17 and even 2.6.16-stable.
>
> I totally agree.
>
> Jeff please try to get at least this skb->truesize fix queued
> to both -stable and current 2.6.x, it's really needed and
> important for proper socket memory accounting on receive with
> e1000.
I agree, Jeff, please go ahead or let me know if you want me to submit this
separately.
Auke
^ permalink raw reply
* Re: TCP not retransmitting supposedly lost segment
From: Herbert Xu @ 2006-04-23 12:27 UTC (permalink / raw)
To: Florian Zumbiehl; +Cc: netdev
In-Reply-To: <20060410010005.GA9282@florz.florz.dyndns.org>
On Mon, Apr 10, 2006 at 01:00:05AM +0000, Florian Zumbiehl wrote:
>
> meanwhile I gathered some information from /proc/net/tcp6 on this
> problem - in case anyone is interested :-)
>
> | 1144560959: 8: xxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxx:1223 xxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxx:1A0B 01 00000000:00000000 02:00097F82 00000000 1000 0 3188619 8 c1409260 89 10 20 2 2
> | 1144560969: 8: xxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxx:1223 xxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxx:1A0B 01 00000016:00000000 01:00000074 00000004 1000 0 3188619 9 c1409260 1424 10 18 1 2
> | 1144560980: 8: xxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxx:1223 xxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxx:1A0B 01 00000016:00000000 01:000000FA 00000005 1000 0 3188619 9 c1409260 2848 10 18 1 2
> | 1144560990: 8: xxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxx:1223 xxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxx:1A0B 01 00000016:00000000 01:000005F2 00000006 1000 0 3188619 9 c1409260 5696 10 18 1 2
This tells us that the kernel was indeed retransmitting but the
packet didn't make it out of the interface according to your
tcpdump.
Do you have any firewall rules? Any tc rules?
Cheers,
--
Visit Openswan at http://www.openswan.org/
Email: Herbert Xu ~{PmV>HI~} <herbert@gondor.apana.org.au>
Home Page: http://gondor.apana.org.au/~herbert/
PGP Key: http://gondor.apana.org.au/~herbert/pubkey.txt
^ permalink raw reply
* Re: Netpoll checksum issue
From: Herbert Xu @ 2006-04-23 11:34 UTC (permalink / raw)
To: Aubrey; +Cc: Stephen Hemminger, netdev
In-Reply-To: <6d6a94c50604191854m73b241e3v104d713b7bb93674@mail.gmail.com>
On Thu, Apr 20, 2006 at 09:54:54AM +0800, Aubrey wrote:
>
> Hi Herbert - I'm working on blackfin uclinux platform. My network
> driver is for blackfin on-chip EMAC. Of course it's open source, but
> so far it's not committed into mainline tree. We can be found at here:
> http://www.blackfin.uclinux.org
Please send me a copy of the driver source that you were using when
this happened.
> My driver didn't assign any value to skb->ip_summed, and didn't
> define tx/rx checksum routine like "e1000_rx_checksum", but it did
> work before on 2.6.12. I'm trying to find what's broken.
Could you please add a printk in checksum_udp to print out the pertinent
values such as the expected checksum and actual checksum?
Thanks,
--
Visit Openswan at http://www.openswan.org/
Email: Herbert Xu ~{PmV>HI~} <herbert@gondor.apana.org.au>
Home Page: http://gondor.apana.org.au/~herbert/
PGP Key: http://gondor.apana.org.au/~herbert/pubkey.txt
^ permalink raw reply
* Re: via_rhine/qdisc Dead loop on netdevice eth1, fix it urgently!
From: Herbert Xu @ 2006-04-23 11:31 UTC (permalink / raw)
To: James Bourne; +Cc: netdev
In-Reply-To: <Pine.LNX.4.58.0604140935220.4085@ldap2.hardrock.org>
On Fri, Apr 14, 2006 at 03:51:15PM +0000, James Bourne wrote:
>
> Apr 14 08:32:54 bama kernel: [<c02becbb>] netpoll_send_skb+0xa8/0x100 [<f8c4c174>] write_msg+0x140/0x181 [netconsole]
This is the culprit. Disable that and the problem will go away.
Cheers,
--
Visit Openswan at http://www.openswan.org/
Email: Herbert Xu ~{PmV>HI~} <herbert@gondor.apana.org.au>
Home Page: http://gondor.apana.org.au/~herbert/
PGP Key: http://gondor.apana.org.au/~herbert/pubkey.txt
^ permalink raw reply
* [PATCH] bcm43xx: make PIO mode usable
From: Michael Buesch @ 2006-04-23 11:23 UTC (permalink / raw)
To: John W. Linville; +Cc: Andrew Morton, netdev, bcm43xx-dev
[-- Attachment #1: Type: text/plain, Size: 10100 bytes --]
Please apply this to 2.6.17, because it can be used
as a tempoary workaround for people with the >1G problem.
--
This patch fixes PIO mode on the softmac bcm43xx
driver. (A dscape patch will follow).
It mainly fixes endianess issues.
This patch is tested on PowerPC32 and i386.
Signed-off-by: Michael Buesch <mb@bu3sch.de>
Index: wireless-2.6/drivers/net/wireless/bcm43xx/bcm43xx_dma.h
===================================================================
--- wireless-2.6.orig/drivers/net/wireless/bcm43xx/bcm43xx_dma.h 2006-04-11 06:26:46.000000000 +0200
+++ wireless-2.6/drivers/net/wireless/bcm43xx/bcm43xx_dma.h 2006-04-22 16:47:51.000000000 +0200
@@ -213,6 +213,14 @@
void bcm43xx_dma_rx(struct bcm43xx_dmaring *ring)
{
}
+static inline
+void bcm43xx_dma_tx_suspend(struct bcm43xx_dmaring *ring)
+{
+}
+static inline
+void bcm43xx_dma_tx_resume(struct bcm43xx_dmaring *ring)
+{
+}
#endif /* CONFIG_BCM43XX_DMA */
#endif /* BCM43xx_DMA_H_ */
Index: wireless-2.6/drivers/net/wireless/bcm43xx/bcm43xx_pio.c
===================================================================
--- wireless-2.6.orig/drivers/net/wireless/bcm43xx/bcm43xx_pio.c 2006-04-11 06:26:46.000000000 +0200
+++ wireless-2.6/drivers/net/wireless/bcm43xx/bcm43xx_pio.c 2006-04-23 13:10:02.000000000 +0200
@@ -27,6 +27,7 @@
#include "bcm43xx_pio.h"
#include "bcm43xx_main.h"
#include "bcm43xx_xmit.h"
+#include "bcm43xx_power.h"
#include <linux/delay.h>
@@ -44,10 +45,10 @@
bcm43xx_pio_write(queue, BCM43xx_PIO_TXDATA,
octet);
bcm43xx_pio_write(queue, BCM43xx_PIO_TXCTL,
- BCM43xx_PIO_TXCTL_WRITEHI);
+ BCM43xx_PIO_TXCTL_WRITELO);
} else {
bcm43xx_pio_write(queue, BCM43xx_PIO_TXCTL,
- BCM43xx_PIO_TXCTL_WRITEHI);
+ BCM43xx_PIO_TXCTL_WRITELO);
bcm43xx_pio_write(queue, BCM43xx_PIO_TXDATA,
octet);
}
@@ -103,7 +104,7 @@
bcm43xx_pio_write(queue, BCM43xx_PIO_TXDATA,
skb->data[skb->len - 1]);
bcm43xx_pio_write(queue, BCM43xx_PIO_TXCTL,
- BCM43xx_PIO_TXCTL_WRITEHI |
+ BCM43xx_PIO_TXCTL_WRITELO |
BCM43xx_PIO_TXCTL_COMPLETE);
} else {
bcm43xx_pio_write(queue, BCM43xx_PIO_TXCTL,
@@ -112,9 +113,10 @@
}
static u16 generate_cookie(struct bcm43xx_pioqueue *queue,
- int packetindex)
+ struct bcm43xx_pio_txpacket *packet)
{
u16 cookie = 0x0000;
+ int packetindex;
/* We use the upper 4 bits for the PIO
* controller ID and the lower 12 bits
@@ -135,6 +137,7 @@
default:
assert(0);
}
+ packetindex = pio_txpacket_getindex(packet);
assert(((u16)packetindex & 0xF000) == 0x0000);
cookie |= (u16)packetindex;
@@ -184,7 +187,7 @@
bcm43xx_generate_txhdr(queue->bcm,
&txhdr, skb->data, skb->len,
(packet->xmitted_frags == 0),
- generate_cookie(queue, pio_txpacket_getindex(packet)));
+ generate_cookie(queue, packet));
tx_start(queue);
octets = skb->len + sizeof(txhdr);
@@ -241,7 +244,7 @@
queue->tx_devq_packets++;
queue->tx_devq_used += octets;
- assert(packet->xmitted_frags <= packet->txb->nr_frags);
+ assert(packet->xmitted_frags < packet->txb->nr_frags);
packet->xmitted_frags++;
packet->xmitted_octets += octets;
}
@@ -257,8 +260,14 @@
unsigned long flags;
struct bcm43xx_pio_txpacket *packet, *tmp_packet;
int err;
+ u16 txctl;
bcm43xx_lock_mmio(bcm, flags);
+
+ txctl = bcm43xx_pio_read(queue, BCM43xx_PIO_TXCTL);
+ if (txctl & BCM43xx_PIO_TXCTL_SUSPEND)
+ goto out_unlock;
+
list_for_each_entry_safe(packet, tmp_packet, &queue->txqueue, list) {
assert(packet->xmitted_frags < packet->txb->nr_frags);
if (packet->xmitted_frags == 0) {
@@ -288,6 +297,7 @@
next_packet:
continue;
}
+out_unlock:
bcm43xx_unlock_mmio(bcm, flags);
}
@@ -330,12 +340,19 @@
(unsigned long)queue);
value = bcm43xx_read32(bcm, BCM43xx_MMIO_STATUS_BITFIELD);
- value |= BCM43xx_SBF_XFER_REG_BYTESWAP;
+ value &= ~BCM43xx_SBF_XFER_REG_BYTESWAP;
bcm43xx_write32(bcm, BCM43xx_MMIO_STATUS_BITFIELD, value);
qsize = bcm43xx_read16(bcm, queue->mmio_base + BCM43xx_PIO_TXQBUFSIZE);
+ if (qsize == 0) {
+ printk(KERN_ERR PFX "ERROR: This card does not support PIO "
+ "operation mode. Please use DMA mode "
+ "(module parameter pio=0).\n");
+ goto err_freequeue;
+ }
if (qsize <= BCM43xx_PIO_TXQADJUST) {
- printk(KERN_ERR PFX "PIO tx device-queue too small (%u)\n", qsize);
+ printk(KERN_ERR PFX "PIO tx device-queue too small (%u)\n",
+ qsize);
goto err_freequeue;
}
qsize -= BCM43xx_PIO_TXQADJUST;
@@ -444,15 +461,10 @@
{
struct bcm43xx_pioqueue *queue = bcm43xx_current_pio(bcm)->queue1;
struct bcm43xx_pio_txpacket *packet;
- u16 tmp;
assert(!queue->tx_suspended);
assert(!list_empty(&queue->txfree));
- tmp = bcm43xx_pio_read(queue, BCM43xx_PIO_TXCTL);
- if (tmp & BCM43xx_PIO_TXCTL_SUSPEND)
- return -EBUSY;
-
packet = list_entry(queue->txfree.next, struct bcm43xx_pio_txpacket, list);
packet->txb = txb;
packet->xmitted_frags = 0;
@@ -462,7 +474,7 @@
assert(queue->nr_txfree < BCM43xx_PIO_MAXTXPACKETS);
/* Suspend TX, if we are out of packets in the "free" queue. */
- if (unlikely(list_empty(&queue->txfree))) {
+ if (list_empty(&queue->txfree)) {
netif_stop_queue(queue->bcm->net_dev);
queue->tx_suspended = 1;
}
@@ -480,15 +492,15 @@
queue = parse_cookie(bcm, status->cookie, &packet);
assert(queue);
-//TODO
-if (!queue)
-return;
+
free_txpacket(packet, 1);
- if (unlikely(queue->tx_suspended)) {
+ if (queue->tx_suspended) {
queue->tx_suspended = 0;
netif_wake_queue(queue->bcm->net_dev);
}
- /* If there are packets on the txqueue, poke the tasklet. */
+ /* If there are packets on the txqueue, poke the tasklet
+ * to transmit them.
+ */
if (!list_empty(&queue->txqueue))
tasklet_schedule(&queue->txtask);
}
@@ -519,12 +531,9 @@
int i, preamble_readwords;
struct sk_buff *skb;
-return;
tmp = bcm43xx_pio_read(queue, BCM43xx_PIO_RXCTL);
- if (!(tmp & BCM43xx_PIO_RXCTL_DATAAVAILABLE)) {
- dprintkl(KERN_ERR PFX "PIO RX: No data available\n");//TODO: remove this printk.
+ if (!(tmp & BCM43xx_PIO_RXCTL_DATAAVAILABLE))
return;
- }
bcm43xx_pio_write(queue, BCM43xx_PIO_RXCTL,
BCM43xx_PIO_RXCTL_DATAAVAILABLE);
@@ -538,8 +547,7 @@
return;
data_ready:
-//FIXME: endianess in this function.
- len = le16_to_cpu(bcm43xx_pio_read(queue, BCM43xx_PIO_RXDATA));
+ len = bcm43xx_pio_read(queue, BCM43xx_PIO_RXDATA);
if (unlikely(len > 0x700)) {
pio_rx_error(queue, 0, "len > 0x700");
return;
@@ -555,7 +563,7 @@
preamble_readwords = 18 / sizeof(u16);
for (i = 0; i < preamble_readwords; i++) {
tmp = bcm43xx_pio_read(queue, BCM43xx_PIO_RXDATA);
- preamble[i + 1] = cpu_to_be16(tmp);//FIXME?
+ preamble[i + 1] = cpu_to_le16(tmp);
}
rxhdr = (struct bcm43xx_rxhdr *)preamble;
rxflags2 = le16_to_cpu(rxhdr->flags2);
@@ -591,16 +599,40 @@
}
skb_put(skb, len);
for (i = 0; i < len - 1; i += 2) {
- tmp = cpu_to_be16(bcm43xx_pio_read(queue, BCM43xx_PIO_RXDATA));
- *((u16 *)(skb->data + i)) = tmp;
+ tmp = bcm43xx_pio_read(queue, BCM43xx_PIO_RXDATA);
+ *((u16 *)(skb->data + i)) = cpu_to_le16(tmp);
}
if (len % 2) {
tmp = bcm43xx_pio_read(queue, BCM43xx_PIO_RXDATA);
skb->data[len - 1] = (tmp & 0x00FF);
+/* The specs say the following is required, but
+ * it is wrong and corrupts the PLCP. If we don't do
+ * this, the PLCP seems to be correct. So ifdef it out for now.
+ */
+#if 0
if (rxflags2 & BCM43xx_RXHDR_FLAGS2_TYPE2FRAME)
- skb->data[0x20] = (tmp & 0xFF00) >> 8;
+ skb->data[2] = (tmp & 0xFF00) >> 8;
else
- skb->data[0x1E] = (tmp & 0xFF00) >> 8;
+ skb->data[0] = (tmp & 0xFF00) >> 8;
+#endif
}
+ skb_trim(skb, len - IEEE80211_FCS_LEN);
bcm43xx_rx(queue->bcm, skb, rxhdr);
}
+
+void bcm43xx_pio_tx_suspend(struct bcm43xx_pioqueue *queue)
+{
+ bcm43xx_power_saving_ctl_bits(queue->bcm, -1, 1);
+ bcm43xx_pio_write(queue, BCM43xx_PIO_TXCTL,
+ bcm43xx_pio_read(queue, BCM43xx_PIO_TXCTL)
+ | BCM43xx_PIO_TXCTL_SUSPEND);
+}
+
+void bcm43xx_pio_tx_resume(struct bcm43xx_pioqueue *queue)
+{
+ bcm43xx_pio_write(queue, BCM43xx_PIO_TXCTL,
+ bcm43xx_pio_read(queue, BCM43xx_PIO_TXCTL)
+ & ~BCM43xx_PIO_TXCTL_SUSPEND);
+ bcm43xx_power_saving_ctl_bits(queue->bcm, -1, -1);
+ tasklet_schedule(&queue->txtask);
+}
Index: wireless-2.6/drivers/net/wireless/bcm43xx/bcm43xx_pio.h
===================================================================
--- wireless-2.6.orig/drivers/net/wireless/bcm43xx/bcm43xx_pio.h 2006-04-11 06:26:46.000000000 +0200
+++ wireless-2.6/drivers/net/wireless/bcm43xx/bcm43xx_pio.h 2006-04-22 16:47:17.000000000 +0200
@@ -14,8 +14,8 @@
#define BCM43xx_PIO_RXCTL 0x08
#define BCM43xx_PIO_RXDATA 0x0A
-#define BCM43xx_PIO_TXCTL_WRITEHI (1 << 0)
-#define BCM43xx_PIO_TXCTL_WRITELO (1 << 1)
+#define BCM43xx_PIO_TXCTL_WRITELO (1 << 0)
+#define BCM43xx_PIO_TXCTL_WRITEHI (1 << 1)
#define BCM43xx_PIO_TXCTL_COMPLETE (1 << 2)
#define BCM43xx_PIO_TXCTL_INIT (1 << 3)
#define BCM43xx_PIO_TXCTL_SUSPEND (1 << 7)
@@ -95,6 +95,7 @@
u16 offset, u16 value)
{
bcm43xx_write16(queue->bcm, queue->mmio_base + offset, value);
+ mmiowb();
}
@@ -107,6 +108,9 @@
struct bcm43xx_xmitstatus *status);
void bcm43xx_pio_rx(struct bcm43xx_pioqueue *queue);
+void bcm43xx_pio_tx_suspend(struct bcm43xx_pioqueue *queue);
+void bcm43xx_pio_tx_resume(struct bcm43xx_pioqueue *queue);
+
#else /* CONFIG_BCM43XX_PIO */
static inline
@@ -133,6 +137,14 @@
void bcm43xx_pio_rx(struct bcm43xx_pioqueue *queue)
{
}
+static inline
+void bcm43xx_pio_tx_suspend(struct bcm43xx_pioqueue *queue)
+{
+}
+static inline
+void bcm43xx_pio_tx_resume(struct bcm43xx_pioqueue *queue)
+{
+}
#endif /* CONFIG_BCM43XX_PIO */
#endif /* BCM43xx_PIO_H_ */
--
Greetings Michael.
[-- Attachment #2: Type: application/pgp-signature, Size: 191 bytes --]
^ permalink raw reply
* Re: Van Jacobson's net channels and real-time
From: Avi Kivity @ 2006-04-23 9:23 UTC (permalink / raw)
To: Ingo Oeser
Cc: Jörn Engel, Ingo Oeser, David S. Miller, simlo, linux-kernel,
mingo, netdev
In-Reply-To: <200604221529.59899.ioe-lkml@rameria.de>
Ingo Oeser wrote:
> Hi Jörn,
>
> On Saturday, 22. April 2006 13:48, Jörn Engel wrote:
>
>> Unless I completely misunderstand something, one of the main points of
>> the netchannels if to have *zero* fields written to by both producer
>> and consumer.
>>
>
> Hmm, for me the main point was to keep the complete processing
> of a single packet within one CPU/Core where this is a non-issue.
>
But the interrupt for a packet can be received by cpu 0 whereas the rest
of processing proceeds on cpu 1; so it still helps to keep the producer
index and consumer index on separate cachelines.
--
error compiling committee.c: too many arguments to function
^ permalink raw reply
* Your Invoice is Ready
From: Joni Slaughter @ 2006-04-23 8:37 UTC (permalink / raw)
To: netdev
"Cia-lis Sof`tabs" is better than Pfizer V`ia`g`ra
and normal Ci-ialis because:
- Guarantes 40 hours lasting
- Safe to take, no side efects at all
- Boost and increase se-xual performance
- Harder e`rectiiions and quick recharge
- Proven and certified by experts and doctors
- only $1.56 per tabs
- Special offeer! These prices
- are valid until 30th of April!
Clisk here: http://shubuobbctr.info
inscription autosuggestible dashboard confusion carol antonym bestseller cloth eben ladyfern
shareholder intimate bacterial lifeblood quito digitalis fluorspar cowpunch drainage
dynamo mine rock breakwater alcoa tarpon kankakee dodecahedra alumna arcturus noose
surjection dad d occipital yukon waggle jar annihilate
vestal ablution deadwood resin bizet pinscher drought busch
extolling abram audible serine balinese baldwin turbinate brothel
^ permalink raw reply
* Re: Van Jacobson's net channels and real-time
From: David S. Miller @ 2006-04-23 5:56 UTC (permalink / raw)
To: netdev; +Cc: simlo, linux-kernel, mingo, netdev, ioe-lkml
In-Reply-To: <200604211852.47335.netdev@axxeo.de>
From: Ingo Oeser <netdev@axxeo.de>
Date: Fri, 21 Apr 2006 18:52:47 +0200
> nice to see you getting started with it.
Thanks for reviewing.
> I'm not sure about the queue logic there.
>
> 1867 /* Caller must have exclusive producer access to the netchannel. */
> 1868 int netchannel_enqueue(struct netchannel *np, struct netchannel_buftrailer *bp)
> 1869 {
> 1870 unsigned long tail;
> 1871
> 1872 tail = np->netchan_tail;
> 1873 if (tail == np->netchan_head)
> 1874 return -ENOMEM;
>
> This looks wrong, since empty and full are the same condition in your
> case.
Thanks, that's obviously wrong. I'll try to fix this up.
> What about sth. like
>
> struct netchannel {
> /* This is only read/written by the writer (producer) */
> unsigned long write_ptr;
> struct netchannel_buftrailer *netchan_queue[NET_CHANNEL_ENTRIES];
>
> /* This is modified by both */
> atomic_t filled_entries; /* cache_line_align this? */
>
> /* This is only read/written by the reader (consumer) */
> unsigned long read_ptr;
> }
As stated elsewhere, if you add atomic operations you break the entire
idea of net channels. They are meant to be SMP efficient data structures
where the producer has one cache line that only it dirties and the
consumer has one cache line that likewise only it dirties.
> If cacheline bouncing because of the shared filled_entries becomes an issue,
> you are receiving or sending a lot.
Cacheline bouncing is the core issue being addressed by this
data structure, so we really can't consider your idea seriously.
I've just got an off-by-one error, no need to wreck the entire
data structure just to solve that :-)
^ permalink raw reply
* Re: [PATCH 00/10] e1000: Driver fixes and update to 7.0.38-k2
From: David S. Miller @ 2006-04-23 5:53 UTC (permalink / raw)
To: herbert
Cc: jgarzik, auke-jan.h.kok, netdev, john.ronciak, jesse.brandeburg,
Jeffrey.t.kirsher, auke
In-Reply-To: <E1FXAa6-0001Wt-00@gondolin.me.apana.org.au>
From: Herbert Xu <herbert@gondor.apana.org.au>
Date: Sat, 22 Apr 2006 15:22:54 +1000
> Jeff Garzik <jgarzik@pobox.com> wrote:
> >
> >> 05/10: [PATCH] Update truesize with the length of the packet for
> >> packet split
> >
> > These 10 patches look OK, but since the current kernel version is
> > 2.6.17-rc1, that means we are in "bug fix only" mode right now.
> >
> > Should I (a) apply these all to netdev2-.6.git#upstream, queueing them
> > for 2.6.18, or (b) let you split the submission into two parts, bug
> > fixes only and everything else?
>
> It turns out that the truesize patch is pretty important as otherwise
> most of TCP receive socket buffer accounting falls apart. So it should
> probably go into 2.6.17 and even 2.6.16-stable.
I totally agree.
Jeff please try to get at least this skb->truesize fix queued
to both -stable and current 2.6.x, it's really needed and
important for proper socket memory accounting on receive with
e1000.
Thanks.
^ permalink raw reply
* Re: Van Jacobson's net channels and real-time
From: David S. Miller @ 2006-04-23 5:53 UTC (permalink / raw)
To: bert.hubert; +Cc: simlo, linux-kernel, mingo, netdev
In-Reply-To: <20060422193024.GA29040@outpost.ds9a.nl>
From: bert hubert <bert.hubert@netherlabs.nl>
Date: Sat, 22 Apr 2006 21:30:24 +0200
> On Thu, Apr 20, 2006 at 12:09:55PM -0700, David S. Miller wrote:
> > Going all the way to the socket is a large endeavor and will require a
> > lot of restructuring to do it right, so expect this to take on the
> > order of months.
>
> That's what you said about Niagara too :-)
I'm just trying to keep the expectations low so it's easier
to exceed them :-)
^ permalink raw reply
* Re: Van Jacobson's net channels and real-time
From: David S. Miller @ 2006-04-23 5:52 UTC (permalink / raw)
To: ioe-lkml; +Cc: joern, netdev, simlo, linux-kernel, mingo, netdev
In-Reply-To: <200604221529.59899.ioe-lkml@rameria.de>
From: Ingo Oeser <ioe-lkml@rameria.de>
Date: Sat, 22 Apr 2006 15:29:58 +0200
> On Saturday, 22. April 2006 13:48, Jörn Engel wrote:
> > Unless I completely misunderstand something, one of the main points of
> > the netchannels if to have *zero* fields written to by both producer
> > and consumer.
>
> Hmm, for me the main point was to keep the complete processing
> of a single packet within one CPU/Core where this is a non-issue.
Both are the important issues.
You move the bulk of the packet processing work to the end
cores of the system, yes. But you do so with an enormously
SMP friendly queue data structure so that it does not matter
at all that the packet is received on one cpu, yet processed
in socket context on another.
If you elide either part of the implementation, you miss the
entire point of net channels.
^ permalink raw reply
* Re: Van Jacobson's net channels and real-time
From: David S. Miller @ 2006-04-23 5:51 UTC (permalink / raw)
To: joern; +Cc: netdev, simlo, linux-kernel, mingo, netdev, ioe-lkml
In-Reply-To: <20060422114846.GA6629@wohnheim.fh-wedel.de>
From: Jörn Engel <joern@wohnheim.fh-wedel.de>
Date: Sat, 22 Apr 2006 13:48:46 +0200
> Unless I completely misunderstand something, one of the main points of
> the netchannels if to have *zero* fields written to by both producer
> and consumer. Receiving and sending a lot can be expected to be the
> common case, so taking a performance hit in this case is hardly a good
> idea.
That's absolutely correct, this is absolutely critical to
the implementation.
If you're doing any atomic operations, or any write operations by both
consumer and producer to the same cacheline, you've broken things :-)
^ permalink raw reply
* Re: Van Jacobson's net channels and real-time
From: David S. Miller @ 2006-04-23 5:50 UTC (permalink / raw)
To: ioe-lkml; +Cc: joern, netdev, simlo, linux-kernel, mingo, netdev
In-Reply-To: <200604230205.33668.ioe-lkml@rameria.de>
From: Ingo Oeser <ioe-lkml@rameria.de>
Date: Sun, 23 Apr 2006 02:05:32 +0200
> On Saturday, 22. April 2006 15:49, Jörn Engel wrote:
> > That was another main point, yes. And the endpoints should be as
> > little burden on the bottlenecks as possible. One bottleneck is the
> > receive interrupt, which shouldn't wait for cachelines from other cpus
> > too much.
>
> Thats right. This will be made a non issue with early demuxing
> on the NIC and MSI (or was it MSI-X?) which will select
> the right CPU based on hardware channels.
It is not clear that MSI'ing the RX interrupt to multiple cpus is the
answer.
Consider the fact that by doing so you're reducing the amount of batch
work each interrupt does by a factor N. One of the biggest gains of
NAPI btw is that it batches patcket receive, if you don't believe the
benefits of this put a simply cycle counter sample around
netif_receive_skb() calls, and note the difference between the first
packet processed and subsequent ones, it's several orders of magnitude
faster to process subsequent packets within a batch. I've done this
before on tg3 with sparc64 and posted the numbers on netdev about a
year or so ago.
If you are doing something like netchannels, it helps to batch so that
the demuxing table stays hot in the cpu cache.
There is even talk of dedicating a thread on enormously multi-
threaded cpus just to the NIC hardware interrupt, so it could net
channel to the socket processes running on the other strands.
^ permalink raw reply
* Re: Fw: [Bug 6421] New: kernel 2.6.10-2.6.16 on alpha: arch/alpha/kernel/io.c, iowrite16_rep() BUG_ON((unsigned long)src & 0x1) triggered
From: Herbert Xu @ 2006-04-23 5:49 UTC (permalink / raw)
To: Stephen Hemminger; +Cc: p_gortmaker, netdev, tomri
In-Reply-To: <E1FXXNS-0003dJ-00@gondolin.me.apana.org.au>
On Sun, Apr 23, 2006 at 03:43:22PM +1000, Herbert Xu wrote:
>
> Can you please put some printks in to find out if
>
> 1) skb_padto is being called.
> 2) Is the input to skb_padto aligned?
I'd also help if you could print out the contents of the packet itself.
--
Visit Openswan at http://www.openswan.org/
Email: Herbert Xu ~{PmV>HI~} <herbert@gondor.apana.org.au>
Home Page: http://gondor.apana.org.au/~herbert/
PGP Key: http://gondor.apana.org.au/~herbert/pubkey.txt
^ permalink raw reply
* Re: Fw: [Bug 6421] New: kernel 2.6.10-2.6.16 on alpha: arch/alpha/kernel/io.c, iowrite16_rep() BUG_ON((unsigned long)src & 0x1) triggered
From: Herbert Xu @ 2006-04-23 5:43 UTC (permalink / raw)
To: Stephen Hemminger; +Cc: p_gortmaker, netdev, tomri
In-Reply-To: <20060421102757.45d26db0@localhost.localdomain>
<tomri@gmx.net> wrote:
>
> And the output in the kernel ring buffer is:
> dmesg | grep xmit
> ei_start_xmit(): skb->data unaligned fffffc0019be55d5 align to fffffc001ef37620
> length 60
Very weird. The length seems to indicate that this packet went through
skb_padto. However, I can't see how skb_padto can produce an unaligned
skb if the input was aligned (the input coming out of TCP should definitely
be aligned).
Can you please put some printks in to find out if
1) skb_padto is being called.
2) Is the input to skb_padto aligned?
> Here some stack traces with BUG_ON/ WARN_ON added by me in more places to trace
> down the problem:
> Kernel bug at net/ipv4/ip_output.c:297
> cc1(2841): Kernel Bug 1
> pc = [<fffffc000062a92c>] ra = [<fffffc00006407c8>] ps = 0000 Not tainted
> pc is at ip_queue_xmit+0x59c/0x690
> ra is at tcp_transmit_skb+0x588/0xbb0
This is pretty meaningless if you don't show us the check that you added
to produce this.
Thanks,
--
Visit Openswan at http://www.openswan.org/
Email: Herbert Xu ~{PmV>HI~} <herbert@gondor.apana.org.au>
Home Page: http://gondor.apana.org.au/~herbert/
PGP Key: http://gondor.apana.org.au/~herbert/pubkey.txt
^ permalink raw reply
* Re: ipsec tunnel asymmetrical mtu
From: Herbert Xu @ 2006-04-23 3:51 UTC (permalink / raw)
To: Marco Berizzi; +Cc: herbert, netdev
In-Reply-To: <BAY103-F21399F30719D1EBD180B04B2CC0@phx.gbl>
Marco Berizzi <pupilla@hotmail.com> wrote:
>
> Is there any news about this issue?
Sorry for the delay, I've been travelling.
The fact that tcpdump with "host 172.16.0.138" does not fix it tells
us that this is related to the NAT that you're doing to the 172.16
side of the network.
Looking at your packet dump your setup is definitely suboptimal in
that correct MTU information is not being provided to either side
of the connection.
The result is that the 10.16 end is sending fragments which have to
be reassembled at mimosa before immediately getting refragmented on
its way to pleiadi.
So if it was my network this would be the first issue I'd try to
address, possibly through MSS clamping.
However, the fact that the tcpdump causes more chunky packets to
make it through could be an indication that there is a bug somewhere
in our NAT/IPsec code or at least a suboptimal memory allocation
strategy that's somehow avoided when AF_PACKET pins the skb down.
So I would like your help in tracking that down before you fix your
network properly.
For a start could you please send me the complete kern.log messages
on mimosa from boot time to the point after a slow connection has
occured. I'd also like to see /proc/net/snmp at that point.
Thanks,
--
Visit Openswan at http://www.openswan.org/
Email: Herbert Xu ~{PmV>HI~} <herbert@gondor.apana.org.au>
Home Page: http://gondor.apana.org.au/~herbert/
PGP Key: http://gondor.apana.org.au/~herbert/pubkey.txt
^ permalink raw reply
* Re: Van Jacobson's net channels and real-time
From: Ingo Oeser @ 2006-04-23 0:05 UTC (permalink / raw)
To: Jörn Engel
Cc: Ingo Oeser, David S. Miller, simlo, linux-kernel, mingo, netdev
In-Reply-To: <20060422134956.GC6629@wohnheim.fh-wedel.de>
On Saturday, 22. April 2006 15:49, Jörn Engel wrote:
> That was another main point, yes. And the endpoints should be as
> little burden on the bottlenecks as possible. One bottleneck is the
> receive interrupt, which shouldn't wait for cachelines from other cpus
> too much.
Thats right. This will be made a non issue with early demuxing
on the NIC and MSI (or was it MSI-X?) which will select
the right CPU based on hardware channels.
In the meantime I would reduce the effects with only committing
on full buffer or on leaving the interrupt handler.
This would be ok, because here you have to wakeup the process
anyway on full buffer and if it slept because of empty buffer.
You loose only, if your application didn't sleep yet and you need to
leave the interrupt handler because there is no work anymore.
In this case the atomic_add would be significant.
All this is quite similiar to now we do page_vec stuff in mm/ already.
Regards
Ingo Oeser
^ permalink raw reply
* Fw: sky2 driver network freeze while transfering data
From: Andrew Morton @ 2006-04-22 23:21 UTC (permalink / raw)
To: netdev; +Cc: thomas klein
Begin forwarded message:
Date: Sat, 22 Apr 2006 12:45:44 +0200
From: thomas klein <tkl@laposte.net>
To: linux-kernel@vger.kernel.org
Subject: sky2 driver network freeze while transfering data
pitfall@archon:~/kernel/linux-2.6.16.9$ sh scripts/ver_linux
If some fields are empty or look unusual you may have an old version.
Compare to the current minimal requirements in Documentation/Changes.
Linux archon 2.6.15-20-686 #1 SMP PREEMPT Tue Apr 4 18:37:00 UTC 2006
i686 GNU/Linux
Gnu C 4.0.3
Gnu make 3.81beta4
binutils 2.16.91
util-linux 2.12r
mount 2.12r
module-init-tools 3.2.2
e2fsprogs 1.38
jfsutils 1.1.8
reiserfsprogs 3.6.19
reiser4progs 1.0.5
xfsprogs 2.7.7
pcmcia-cs 3.2.8
Linux C Library 2.3.6
Dynamic linker (ldd) 2.3.6
Procps 3.2.6
Net-tools 1.60
Console-tools 0.2.3
Sh-utils 5.93
udev 079pitfall@archon:~/kernel/linux-2.6.16.9$ sh
scripts/ver_linux
If some fields are empty or look unusual you may have an old version.
Compare to the current minimal requirements in Documentation/Changes.
Linux archon 2.6.15-20-686 #1 SMP PREEMPT Tue Apr 4 18:37:00 UTC 2006
i686 GNU/Linux
Gnu C 4.0.3
Gnu make 3.81beta4
binutils 2.16.91
util-linux 2.12r
mount 2.12r
module-init-tools 3.2.2
e2fsprogs 1.38
jfsutils 1.1.8
reiserfsprogs 3.6.19
reiser4progs 1.0.5
xfsprogs 2.7.7
pcmcia-cs 3.2.8
Linux C Library 2.3.6
Dynamic linker (ldd) 2.3.6
Procps 3.2.6
Net-tools 1.60
Console-tools 0.2.3
Sh-utils 5.93
udev 079
Modules Loaded binfmt_misc rfcomm l2cap bluetooth sonypi
speedstep_centrino cpufreq_userspace cpufreq_stats freq_table
cpufreq_powersave cpufreq_ondemand cpufreq_conservative video
tc1100_wmi sony_acpi pcc_acpi hotkey dev_acpi container button
acpi_sbs battery ac i2c_acpi_ec ipv6 dm_mod af_packet md_mod sr_mod
sbp2 parport_pc lp parport pcmcia joydev yenta_socket rsrc_nonstatic
ohci1394 sky2 pcmcia_core ieee1394 nvidia i2c_core rtc psmouse
serio_raw snd_hda_intel snd_hda_codec snd_pcm_oss snd_mixer_oss
snd_pcm snd_timer snd soundcore snd_page_alloc shpchp pci_hotplug
intel_agp agpgart tsdev evdev sg usbhid ext3 jbd ide_generic ehci_hcd
uhci_hcd usbcore sd_mod ata_piix libata scsi_mod ide_cd cdrom piix
generic thermal processor fan capability commoncap vga16fb vgastate
fbcon tileblit font bitblit softcursor
Modules Loaded binfmt_misc rfcomm l2cap bluetooth sonypi
speedstep_centrino cpufreq_userspace cpufreq_stats freq_table
cpufreq_powersave cpufreq_ondemand cpufreq_conservative video
tc1100_wmi sony_acpi pcc_acpi hotkey dev_acpi container button
acpi_sbs battery ac i2c_acpi_ec ipv6 dm_mod af_packet md_mod sr_mod
sbp2 parport_pc lp parport pcmcia joydev yenta_socket rsrc_nonstatic
ohci1394 sky2 pcmcia_core ieee1394 nvidia i2c_core rtc psmouse
serio_raw snd_hda_intel snd_hda_codec snd_pcm_oss snd_mixer_oss
snd_pcm snd_timer snd soundcore snd_page_alloc shpchp pci_hotplug
intel_agp agpgart tsdev evdev sg usbhid ext3 jbd ide_generic ehci_hcd
uhci_hcd usbcore sd_mod ata_piix libata scsi_mod ide_cd cdrom piix
generic thermal processor fan capability commoncap vga16fb vgastate
fbcon tileblit font bitblit softcursor
This is the stock kernel I'm using... I tried the latest 2.6.16.9, the
problem was the same.
Problem :
0000:07:00.0 Ethernet controller: Marvell Technology Group Ltd.
88E8036 Fast Ethernet Controller (rev 15)
I can browse the web, check emails etc... but, If I try some rsync
from my old laptop (to backup my stuff) the network freeze after 1 or
2minutes.
the bug is reproductible.
I don't have logs each time, but, sometimes I got this
Apr 15 11:35:42 archon kernel: [4297572.802000] NETDEV WATCHDOG:
eth0: transmit timed out
Apr 15 11:35:42 archon kernel: [4297572.802000] sky2 hardware hung?
flushing
same freeze with the 2.6.16.9
thanks in advance,
thomas.
PS : I didn't subscribe any linux ml, can I see any progress on this
report somewhere ?
-
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
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