* Re: [PATCH 2/2] ipg: redundancy with mii.h
From: David Vrabel @ 2006-05-04 6:52 UTC (permalink / raw)
To: Francois Romieu; +Cc: Pekka J Enberg, linux-kernel, netdev, david
In-Reply-To: <20060503233558.GA27232@electric-eye.fr.zoreil.com>
Francois Romieu wrote:
>
> ipg: remove forward declarations
>
> It makes no sense in a new driver.
>
> Signed-off-by: Francois Romieu <romieu@fr.zoreil.com>
Ack.
> ipg: replace #define with enum
>
> Added some underscores to improve readability.
>
> Signed-off-by: Francois Romieu <romieu@fr.zoreil.com>
Nack. Register names in code should match those used in the
documentation (even if they are a bit unreadable). Though I will
conceed that the available datasheet doesn't actually describe the
majority of the registers.
> ipg: removal of useless #defines
>
> IPG_TX_NOTBUSY apart (one occurence in ipg.c), the #defines appear
> nowhere in the sources.
Ack.
> ipg: redundancy with mii.h - take II
>
> Replace a bunch of #define with their counterpart from mii.h
>
> It is applied to the usual MII registers this time.
Ack.
^ permalink raw reply
* Re: RFC: au1000_etc.c phylib rewrite
From: Robin H. Johnson @ 2006-05-04 6:49 UTC (permalink / raw)
To: Herbert Valerio Riedel; +Cc: linux-mips, netdev
In-Reply-To: <1146674056.31241.18.camel@localhost.localdomain>
[-- Attachment #1: Type: text/plain, Size: 648 bytes --]
On Wed, May 03, 2006 at 06:34:16PM +0200, Herbert Valerio Riedel wrote:
> while at it, does anyone happen to know what the phy-addr/MAC assignment
> on the XXS1500 is?
Nope.
> but one thing that seems strange to me; CONFIG_BCM5222_DUAL_PHY doesn't
> seem to be defined anywhere; shouldn't that be at least defined in some
> Kconfig file, especially if the XXS1550 board is supposed to make use of
> it?
Hmm, I do recall submitting a patch previously that added
'select BCM5222_DUAL_PHY' for the XXS1500 unit.
--
Robin Hugh Johnson
E-Mail : robbat2@gentoo.org
GnuPG FP : 11AC BA4F 4778 E3F6 E4ED F38E B27B 944E 3488 4E85
[-- Attachment #2: Type: application/pgp-signature, Size: 241 bytes --]
^ permalink raw reply
* Re: [PATCH] DECnet: Fix level1 router hello
From: David S. Miller @ 2006-05-04 6:36 UTC (permalink / raw)
To: patrick; +Cc: netdev, steve
In-Reply-To: <4450BB03.4050404@tykepenguin.com>
From: Patrick Caulfield <patrick@tykepenguin.com>
Date: Thu, 27 Apr 2006 13:37:23 +0100
> This patch fixes hello messages sent when a node is a level 1 router. Slightly
> contrary to the spec (maybe) VMS ignores hello messages that do not name
> level2 routers that it also knows about.
>
> So, here we simply name all the routers that the node knows about rather just
> other level1 routers.
> (I hope the patch is clearer than the description. sorry).
>
> Patrick
>
> Signed-off-by: Patrick Caulfield <patrick@tykepenguin.com>
Applied, thanks Patrick.
^ permalink raw reply
* Re: [TCP]: Fix sock_orphan dead lock
From: David S. Miller @ 2006-05-04 6:32 UTC (permalink / raw)
To: herbert; +Cc: mingo, arjan, netdev
In-Reply-To: <20060429131320.GA4145@gondor.apana.org.au>
From: Herbert Xu <herbert@gondor.apana.org.au>
Date: Sat, 29 Apr 2006 23:13:20 +1000
> On Sat, Apr 29, 2006 at 09:15:07PM +1000, herbert wrote:
> >
> > Unfortunately this is only true for TCP. All of the connectionless
> > protocols use the callback lock without the socket lock so it does
> > still serve a purpose.
> >
> > I'd be happy to see your patch included.
>
> I've just changed my mind :) Instead of disabling BH on the read_lock
> callers, we can instead move sock_orphan outside bh_lock_sock.
>
> [TCP]: Fix sock_orphan dead lock
Ok, it took me a while to review this one as verifying such
a set of changes is always tricky, but looks good!
Applied, thanks a lot.
^ permalink raw reply
* Re: [PATCH 3/3] Eleminate HZ from ROSE kernel interfaces
From: David S. Miller @ 2006-05-04 6:28 UTC (permalink / raw)
To: ralf; +Cc: netdev, linux-hams
In-Reply-To: <20060429141924.GA2941@linux-mips.org>
From: Ralf Baechle <ralf@linux-mips.org>
Date: Sat, 29 Apr 2006 15:19:24 +0100
> Convert all ROSE sysctl time values from jiffies to ms as units.
>
> Signed-off-by: Ralf Baechle <ralf@linux-mips.org>
Applied.
^ permalink raw reply
* Re: [PATCH 2/3] Eleminate HZ from NET/ROM kernel interfaces
From: David S. Miller @ 2006-05-04 6:27 UTC (permalink / raw)
To: ralf; +Cc: netdev, linux-hams
In-Reply-To: <20060429141613.GA2811@linux-mips.org>
From: Ralf Baechle <ralf@linux-mips.org>
Date: Sat, 29 Apr 2006 15:16:13 +0100
> Convert all NET/ROM sysctl time values from jiffies to ms as units.
>
> Signed-off-by: Ralf Baechle <ralf@linux-mips.org>
Applied.
^ permalink raw reply
* Re: [PATCH 1/3] Eleminate HZ from AX.25 kernel interfaces
From: David S. Miller @ 2006-05-04 6:27 UTC (permalink / raw)
To: ralf; +Cc: netdev, linux-hams
In-Reply-To: <20060429141244.GA2407@linux-mips.org>
From: Ralf Baechle DL5RB <ralf@linux-mips.org>
Date: Sat, 29 Apr 2006 15:12:44 +0100
> Convert all AX.25 sysctl time values from jiffies to ms as units.
>
> Signed-off-by: Ralf Baechle <ralf@linux-mips.org>
Applied.
^ permalink raw reply
* Re: [ROSE] Fix routing table locking in rose_remove_neigh.
From: David S. Miller @ 2006-05-04 6:26 UTC (permalink / raw)
To: ralf; +Cc: netdev, pidoux, linux-hams
In-Reply-To: <20060429133141.GA31820@linux-mips.org>
From: Ralf Baechle <ralf@linux-mips.org>
Date: Sat, 29 Apr 2006 14:31:41 +0100
> The locking rule for rose_remove_neigh() are that the called needs to
> hold rose_neigh_list_lock, so we better don't take it yet again in
> rose_neigh_list_lock.
>
> Signed-off-by: Ralf Baechle <ralf@linux-mips.org>
Applied, thanks.
^ permalink raw reply
* Re: [AX.25] Move AX.25 symbol exports
From: David S. Miller @ 2006-05-04 6:25 UTC (permalink / raw)
To: ralf; +Cc: netdev, linux-hams
In-Reply-To: <20060429134023.GA32158@linux-mips.org>
From: Ralf Baechle <ralf@linux-mips.org>
Date: Sat, 29 Apr 2006 14:40:23 +0100
> Move AX.25 symbol exports to next to their definitions where they're
> supposed to be these days.
>
> Signed-off-by: Ralf Baechle <ralf@linux-mips.org>
Applied.
^ permalink raw reply
* Re: [HAMRADIO] Remove remaining SET_MODULE_OWNER calls from hamradio drivers.
From: David S. Miller @ 2006-05-04 6:24 UTC (permalink / raw)
To: ralf; +Cc: jeff, netdev, linux-hams
In-Reply-To: <20060429143413.GA4630@linux-mips.org>
From: Ralf Baechle DL5RB <ralf@linux-mips.org>
Date: Sat, 29 Apr 2006 15:34:13 +0100
> Signed-off-by: Ralf Baechle DL5RB <ralf@linux-mips.org>
Applied.
^ permalink raw reply
* Re: [AX25, ROSE] Remove useless SET_MODULE_OWNER calls.
From: David S. Miller @ 2006-05-04 6:23 UTC (permalink / raw)
To: ralf; +Cc: netdev, linux-hams
In-Reply-To: <20060429142943.GA4402@linux-mips.org>
From: Ralf Baechle DL5RB <ralf@linux-mips.org>
Date: Sat, 29 Apr 2006 15:29:43 +0100
> Signed-off-by: Ralf Baechle <ralf@linux-mips.org>
Applied, thanks.
^ permalink raw reply
* Re: [ROSE] Remove useless prototype for rose_remove_neigh().
From: David S. Miller @ 2006-05-04 6:22 UTC (permalink / raw)
To: ralf; +Cc: netdev
In-Reply-To: <20060429132553.GA31622@linux-mips.org>
From: Ralf Baechle <ralf@linux-mips.org>
Date: Sat, 29 Apr 2006 14:25:53 +0100
> Signed-off-by: Ralf Baechle <ralf@linux-mips.org>
Applied, thanks.
^ permalink raw reply
* Re: [AX.25] Spelling fix
From: David S. Miller @ 2006-05-04 6:22 UTC (permalink / raw)
To: ralf; +Cc: netdev, linux-hams
In-Reply-To: <20060429142427.GA3684@linux-mips.org>
From: Ralf Baechle DL5RB <ralf@linux-mips.org>
Date: Sat, 29 Apr 2006 15:24:27 +0100
> Signed-off-by: Ralf Baechle <ralf@linux-mips.org>
Applied.
^ permalink raw reply
* Re: [PATCH 1/3] Rough VJ Channel Implementation - vj_core.patch
From: Kelly Daly @ 2006-05-04 2:59 UTC (permalink / raw)
Cc: David S. Miller, rusty, netdev
In-Reply-To: <20060426.232501.119306252.davem@davemloft.net>
On Thursday 27 April 2006 16:25, you wrote:
> So the idea in your scheme is to give the buffer pools to the NIC
> in a per-channel way via a simple descriptor table? And the u32's
> are arbitrary keys that index into this descriptor table, right?
>
yeah - it _was_... Although since having a play with coding it into your
implementation we've come up with the following:
Using the descriptor table adds excess complexity for kernel buffers, and is
really only useful for userspace. So instead of using descriptor tables for
everything we've come up with a dynamic descriptor table scheme instead where
they are used only for userspace.
The move to skb-ising the buffers has made it more difficult to keep track of
buffer lifetimes. Previously we were leaving the buffers in the ring until
completely finished with them. The producer could reuse the buffer once the
consumer head had moved on. With the graft to skb we can no longer do this
unless the packets are processed serially (which is ok for socket channels,
but not realistic for the default).
We DID write an infrastructure to resolve this issue, although it is more
complex than the dynamic descriptor scheme for userspace. And we want to
keep this simple - right?
Cheers,
K
^ permalink raw reply
* Re: latest -stable breaks Squid
From: Ian McDonald @ 2006-05-04 1:59 UTC (permalink / raw)
To: Ben Greear
Cc: Herbert Xu, Dave Jones, netdev, stable, fedora-list, fedoralist
In-Reply-To: <4459574D.6000303@candelatech.com>
On 5/4/06, Ben Greear <greearb@candelatech.com> wrote:
> Herbert Xu wrote:
> > Dave Jones <davej@redhat.com> wrote:
> >
> >>So I pushed out an update for Fedora Core 5 users yesterday
> >>that moved the kernel from 2.6.16.9 to 2.6.16.13.
> >>I've since heard "My network performance is awful", and worse
> >>yet, some apps seem broken as in the report below.
> >>
> >>Anyone have any ideas ?
> >
> >
> > Try reverting the e1000 truesize patch. Although the fix is 100%
> > correct, it might have a negative impact on user-space apps with
> > particuarly small rcvbuf settings. Prior to the fix, due to the
> > incorrect accounting we are essentially enlarging rcvbuf by as much
> > as 10 times.
>
> At least one of the reports shows problems with non e1000 NICs, so it's
> probably not just the e1000 change.
>
> https://bugzilla.redhat.com/bugzilla/show_bug.cgi?id=190620
>
> Ben
>
Wouldn't it be more likely commit 5d0b6f2bdaf7e016e750cd24164a241512d968a3
as this touches net/ipv4/tcp_output.c and is also in same general area?
--
Ian McDonald
Web: http://wand.net.nz/~iam4
Blog: http://imcdnzl.blogspot.com
WAND Network Research Group
Department of Computer Science
University of Waikato
New Zealand
^ permalink raw reply
* Fw: [Bugme-new] [Bug 6484] New: dropouts with user mode PPPoE
From: Andrew Morton @ 2006-05-04 1:56 UTC (permalink / raw)
To: netdev
Begin forwarded message:
Date: Tue, 2 May 2006 13:28:22 -0700
From: bugme-daemon@bugzilla.kernel.org
To: bugme-new@lists.osdl.org
Subject: [Bugme-new] [Bug 6484] New: dropouts with user mode PPPoE
http://bugzilla.kernel.org/show_bug.cgi?id=6484
Summary: dropouts with user mode PPPoE
Kernel Version: 2.6.16 and above
Status: NEW
Severity: normal
Owner: acme@conectiva.com.br
Submitter: lkml@jawad.org
Distribution: Debian
Hardware Environment: P4 Northwood, 2 GB, i875, e1000 CSA
Software Environment: pppd, rp-pppoe
Problem Description:
ADSL connection through PPPoE occasionally stalls for 30 to 50 seconds,
especially under load. During these dropouts, packets are received but none that
are supposed to be sent appear on ppp0. Ethernet interface continues to work,
telnet session to modem does not stall.
Exhibition of the bug is not affected by:
SMP or uniprocessor kernel, Hyper Threading disabled or enabled, pppd version
(tested with 2.4.2 and 2.4.4b1), rp-pppoe version (tested 3.5 & 3.8).
CPU load is probably not a factor either.
Dropouts seem to appear more frequently when the connection is under load (large
Bittorrent swarms are a good test). They can appear as soon as a few minutes
after start but it also took more than 5 hours once. Most of the time, they will
appear every half to one hour.
Problem does not occur with 2.6.15.7 or earlier. Second system with AMD64
SanDiego & NForce4 is not affected, will try to match configuration as closely
as possible and retest.
Kernel mode PPPoE using the rp-pppoe plugin does also not exhibit the bug.
2.6.17-rc3 .config:
http://jawad.org/.config
------- You are receiving this mail because: -------
You are on the CC list for the bug, or are watching someone who is.
^ permalink raw reply
* Re: latest -stable breaks Squid
From: Ben Greear @ 2006-05-04 1:22 UTC (permalink / raw)
To: Herbert Xu; +Cc: Dave Jones, netdev, stable, fedora-list, fedoralist
In-Reply-To: <E1FbSM8-0002lx-00@gondolin.me.apana.org.au>
Herbert Xu wrote:
> Dave Jones <davej@redhat.com> wrote:
>
>>So I pushed out an update for Fedora Core 5 users yesterday
>>that moved the kernel from 2.6.16.9 to 2.6.16.13.
>>I've since heard "My network performance is awful", and worse
>>yet, some apps seem broken as in the report below.
>>
>>Anyone have any ideas ?
>
>
> Try reverting the e1000 truesize patch. Although the fix is 100%
> correct, it might have a negative impact on user-space apps with
> particuarly small rcvbuf settings. Prior to the fix, due to the
> incorrect accounting we are essentially enlarging rcvbuf by as much
> as 10 times.
At least one of the reports shows problems with non e1000 NICs, so it's
probably not just the e1000 change.
https://bugzilla.redhat.com/bugzilla/show_bug.cgi?id=190620
Ben
>
> Cheers,
--
Ben Greear <greearb@candelatech.com>
Candela Technologies Inc http://www.candelatech.com
^ permalink raw reply
* Re: latest -stable breaks Squid
From: Herbert Xu @ 2006-05-04 1:10 UTC (permalink / raw)
To: Dave Jones; +Cc: netdev, stable, fedora-list, fedoralist
In-Reply-To: <20060503211915.GD27368@redhat.com>
Dave Jones <davej@redhat.com> wrote:
>
> So I pushed out an update for Fedora Core 5 users yesterday
> that moved the kernel from 2.6.16.9 to 2.6.16.13.
> I've since heard "My network performance is awful", and worse
> yet, some apps seem broken as in the report below.
>
> Anyone have any ideas ?
Try reverting the e1000 truesize patch. Although the fix is 100%
correct, it might have a negative impact on user-space apps with
particuarly small rcvbuf settings. Prior to the fix, due to the
incorrect accounting we are essentially enlarging rcvbuf by as much
as 10 times.
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: latest -stable breaks Squid
From: Dave Jones @ 2006-05-04 0:43 UTC (permalink / raw)
To: netdev; +Cc: stable, Andreas M. Kirchwitz, Vassilios Kotoulas
In-Reply-To: <20060503211915.GD27368@redhat.com>
On Wed, May 03, 2006 at 05:19:15PM -0400, Dave Jones wrote:
> So I pushed out an update for Fedora Core 5 users yesterday
> that moved the kernel from 2.6.16.9 to 2.6.16.13.
> I've since heard "My network performance is awful", and worse
> yet, some apps seem broken as in the report below.
Further problems found (not all network related, but there does
seem to be a pattern amongst some of them) can be seen at
http://tinyurl.com/o7uqj
Dave
--
http://www.codemonkey.org.uk
^ permalink raw reply
* Re: [PATCH 2/2] ipg: redundancy with mii.h
From: Francois Romieu @ 2006-05-03 23:35 UTC (permalink / raw)
To: Pekka J Enberg; +Cc: David Vrabel, linux-kernel, netdev, david
In-Reply-To: <Pine.LNX.4.58.0605030913210.6032@sbz-30.cs.Helsinki.FI>
Pekka J Enberg <penberg@cs.Helsinki.FI> :
[...]
> maintain the tree, I can send you my patches so you can recreate the full
> history. The first steps were produced by quilt on the original
> out-of-tree driver, though, so they're probably not helpful.
It will be welcome.
I have added a few little things (changelog below). Next step will
probably be some mii/ethtool stuff.
The branch 'netdev-ipg' is available at:
git://electric-eye.fr.zoreil.com/home/romieu/linux-2.6.git.
Serie of patches (ala 'git format-patch'):
http://www.fr.zoreil.com/linux/kernel/2.6.x/2.6.17-rc3/ip1000a/
All-in-one patch:
http://www.fr.zoreil.com/people/francois/misc/20060504-2.6.17-rc3-git-ip1000-test.patch
ChangeLog from yesterday version:
commit 8b0a8db32d1ac6e9bc23300a6a0533b4d7e251e3
Author: Francois Romieu <romieu@fr.zoreil.com>
Date: Thu May 4 00:29:59 2006 +0200
ipg: remove forward declarations
It makes no sense in a new driver.
Signed-off-by: Francois Romieu <romieu@fr.zoreil.com>
commit 65940e5e0ab88d92fbac0f96b5d46ddfbd5cfa93
Author: Francois Romieu <romieu@fr.zoreil.com>
Date: Thu May 4 00:04:57 2006 +0200
ipg: replace #define with enum
Added some underscores to improve readability.
Signed-off-by: Francois Romieu <romieu@fr.zoreil.com>
commit ab87a106690d6eaba4b7426fb074270e2e503e40
Author: Francois Romieu <romieu@fr.zoreil.com>
Date: Wed May 3 22:51:16 2006 +0200
ipg: removal of useless #defines
IPG_TX_NOTBUSY apart (one occurence in ipg.c), the #defines appear
nowhere in the sources.
Signed-off-by: Francois Romieu <romieu@fr.zoreil.com>
commit ef7bfd886bc436d14649e962edb6f5189cc4dcac
Author: Francois Romieu <romieu@fr.zoreil.com>
Date: Wed May 3 22:44:47 2006 +0200
ipg: redundancy with mii.h - take II
Replace a bunch of #define with their counterpart from mii.h
It is applied to the usual MII registers this time.
Signed-off-by: Francois Romieu <romieu@fr.zoreil.com>
--
Ueimor
^ permalink raw reply
* Re: netlink+ARP+CLIP == broken,
From: Stephen Hemminger @ 2006-05-03 21:43 UTC (permalink / raw)
To: Simon Kelley; +Cc: netdev, linux-kernel
In-Reply-To: <44592177.5080801@thekelleys.org.uk>
On Wed, 03 May 2006 22:32:39 +0100
Simon Kelley <simon@thekelleys.org.uk> wrote:
> Both net/ipv4/arp.c and net/arm/clip.c create neighbour tables with
> family == AF_INET. For most purposes this is fine, since the two modules
> each hold a pointer to their table and pass it into the neigh_* functions.
>
> A problem arises in neigh_add, which is called by the rtnetlink code and
> which iterates through all the neighbour tables looking for the first
> one with the correct family. Since there are two different tables with
> family == AF_INET, sometimes it picks the wrong one.
>
> This leads to the situation where sending a RTM_NEWNEIGH message via
> netlink can generate an ignored and useless entry in the clip table,
> whilst the not affecting another entry in the ARP table, both entries
> for the same IP.
>
> Viz:
> sid:~# ip neigh
> 192.168.3.40 dev eth0 lladdr 52:54:00:12:34:59 REACHABLE
> 192.168.3.40 dev eth0 FAILED
>
>
> It's not immediately obvious how to fix this in a conceptually clean
> manner: neighbour tables are not associated with single netdevices, and
> they don't carry an address-type field. Given a {IP,lladdr,device}
> triple, its easy to determine if the device is ether-like or CLIP, but
> then the update call would have to go via the ARP and CLIP modules,
> instead of direct to the neighbour module in an address independent way.
> New address types would need further additions to the netlink/neighbour
> code.
>
> OTOH there are several obvious hacks that will fix the immediate
> problem. I'm happy to provide a patch implementing one if that's desired.
>
> Looking again, I think this is also a security hole, since the CLIP code
> keeps a whole struct including pointers in the neighbour table entry
> where ARP has the MAC address. So this might provide a way to poke
> arbitrary pointers into the kernel via RTM_NEWNEIGH. Only for root, though.
>
This was fixed in 2.6.16.6 and current 2.6.17
^ permalink raw reply
* netlink+ARP+CLIP == broken,
From: Simon Kelley @ 2006-05-03 21:32 UTC (permalink / raw)
To: netdev, linux-kernel
Both net/ipv4/arp.c and net/arm/clip.c create neighbour tables with
family == AF_INET. For most purposes this is fine, since the two modules
each hold a pointer to their table and pass it into the neigh_* functions.
A problem arises in neigh_add, which is called by the rtnetlink code and
which iterates through all the neighbour tables looking for the first
one with the correct family. Since there are two different tables with
family == AF_INET, sometimes it picks the wrong one.
This leads to the situation where sending a RTM_NEWNEIGH message via
netlink can generate an ignored and useless entry in the clip table,
whilst the not affecting another entry in the ARP table, both entries
for the same IP.
Viz:
sid:~# ip neigh
192.168.3.40 dev eth0 lladdr 52:54:00:12:34:59 REACHABLE
192.168.3.40 dev eth0 FAILED
It's not immediately obvious how to fix this in a conceptually clean
manner: neighbour tables are not associated with single netdevices, and
they don't carry an address-type field. Given a {IP,lladdr,device}
triple, its easy to determine if the device is ether-like or CLIP, but
then the update call would have to go via the ARP and CLIP modules,
instead of direct to the neighbour module in an address independent way.
New address types would need further additions to the netlink/neighbour
code.
OTOH there are several obvious hacks that will fix the immediate
problem. I'm happy to provide a patch implementing one if that's desired.
Looking again, I think this is also a security hole, since the CLIP code
keeps a whole struct including pointers in the neighbour table entry
where ARP has the MAC address. So this might provide a way to poke
arbitrary pointers into the kernel via RTM_NEWNEIGH. Only for root, though.
Cheers,
Simon.
^ permalink raw reply
* latest -stable breaks Squid
From: Dave Jones @ 2006-05-03 21:19 UTC (permalink / raw)
To: netdev; +Cc: stable, Andreas M. Kirchwitz, Vassilios Kotoulas
[-- Attachment #1: Type: text/plain, Size: 290 bytes --]
So I pushed out an update for Fedora Core 5 users yesterday
that moved the kernel from 2.6.16.9 to 2.6.16.13.
I've since heard "My network performance is awful", and worse
yet, some apps seem broken as in the report below.
Anyone have any ideas ?
Dave
--
http://www.codemonkey.org.uk
[-- Attachment #2: Type: message/rfc822, Size: 4270 bytes --]
From: "Andreas M. Kirchwitz" <fedora-list@list.zikzak.de>
To: fedora-list@redhat.com
Subject: Kernel 2.6.16-1.2107_FC5 breaks Squid
Date: Wed, 3 May 2006 12:53:04 +0000 (UTC)
Message-ID: <slrne5h9tg.or2.amk@nautilus.zikzak.de>
Hi folks!
Just installed the new kernel 2.6.16-1.2107_FC5 (32-bit, i686),
and everything seems to work fine -- except Squid (not matter
if I use the one that ships with FC5 or my own).
No problem with small data objects (a few kilobytes).
telnet localhost 3128
GET http://www.kirchwitz.de/test.html HTTP/1.0
Large data objects won't work. According to ethereal, the data
is loaded successfully. And I also find the complete objects
in /var/spool/squid, but the data is not output to the application:
telnet localhost 3128
GET http://www.heise.de/ HTTP/1.0
After a few kilobytes, the stream suddenly stops. Sometimes,
Squid doesn't do any output at all, although the object is in
the cache.
With the previous kernel 2.6.16-1.2096_FC5 all is well.
What has changed in the kernel that makes Squid break so hardly?
Maybe other applications are affected as well. Don't know yet.
The error with squid was simply very obvious. ;-)
Greetings, Andreas
--
fedora-list mailing list
fedora-list@redhat.com
To unsubscribe: https://www.redhat.com/mailman/listinfo/fedora-list
^ permalink raw reply
* Re: [PATCH 2/3] ipg: leaks in ipg_probe
From: David Gómez @ 2006-05-03 21:00 UTC (permalink / raw)
To: Pekka Enberg; +Cc: Francois Romieu, David Vrabel, linux-kernel, netdev
In-Reply-To: <1146596687.13675.1.camel@localhost>
Hi Pekka,
On May 02 at 10:04:47, Pekka Enberg wrote:
> > No clear idea but it matches the significant part of the BAR register
> > for the 256 bytes of I/O space that the device uses.
>
> OK. David & David, would appreciate if either you could give the patch a
> spin with Francois' changes. Thanks.
I applied latest Francois patch and the changes (and specially the dma
changes) seems to be ok.
On the other hand i'm having some problems. Nothing related to the
patches, because it happens with the original driver too: After some
time using it, the driver becomes unresponsive and i need to restart
the interface and/or unload-load the ipg module. I'd need to compile
it with debug enabled when i have some time to see what it's going
on...
cheers,
--
David Gómez Jabber ID: davidge@jabber.org
^ permalink raw reply
* RE: VJ Channel API - driver level (PATCH)
From: Caitlin Bestler @ 2006-05-03 20:40 UTC (permalink / raw)
To: David S. Miller, johnpol; +Cc: Leonid.Grossman, shemminger, alex, netdev
David S. Miller wrote:
> From: Evgeniy Polyakov <johnpol@2ka.mipt.ru>
> Date: Wed, 3 May 2006 22:07:40 +0400
>
>> On Wed, May 03, 2006 at 08:56:23AM -0700, Caitlin Bestler
> (caitlinb@broadcom.com) wrote:
>>>> I'd expect high end NIC ASICs to implement rx steering based upon
>>>> some sort of hash (for load balancing), as well as explicit "1:1"
>>>> steering between a sw channel and a hw channel. Both options for
>>>> channel configuration are present in the driver interface.
>>>> If netfilter assists can be done in hardware, I agree the driver
>>>> interface will need to add support for these - otherwise,
>>>> netfilter processing will stay above the driver.
>>>>
>>>>
>>>
>>> Even if the hardware cannot fully implement netfilter rules there is
>>> still value in having an interface that documents exactly how much
>>> filtering a given piece of hardware can do.
>>> There is no point in having the kernel repeat packet classifications
>>> that have already been done by the NIC.
>>
>> Please do not suppose that vj channel must rely on underlaying
>> hardware.
>
> I am not. I am just saying that it is futile to build
> hardware that cannot handle netfilter at least to some
> extent, because this will result in HW net channels being
> disabled for %99 of real users which makes the hardware just a waste.
Or netfilters being disabled, which would be just as bad or worse.
The kernel and hardware need to co-operate so that users are not
asked to make artificial choices between performance and security.
^ 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