Netdev List
 help / color / mirror / Atom feed
* Re: [patch 15/28] drivers/net/wan/hdlc_fr.c: kmalloc + memset conversion to kzalloc
From: David Miller @ 2007-08-10 22:25 UTC (permalink / raw)
  To: akpm; +Cc: netdev, m.kozlowski, khc
In-Reply-To: <200708102111.l7ALBxJj009417@imap1.linux-foundation.org>

From: akpm@linux-foundation.org
Date: Fri, 10 Aug 2007 14:11:58 -0700

> From: Mariusz Kozlowski <m.kozlowski@tuxland.pl>
> 
>  drivers/net/wan/hdlc_fr.c | 31260 -> 31223 (-37 bytes)
>  drivers/net/wan/hdlc_fr.o | 144872 -> 144728 (-144 bytes)
> 
> Signed-off-by: Mariusz Kozlowski <m.kozlowski@tuxland.pl>
> Acked-by: Krzysztof Halasa <khc@pm.waw.pl>
> Signed-off-by: Andrew Morton <akpm@linux-foundation.org>

Applied to net-2.6, thanks!

^ permalink raw reply

* Re: RealTek 8169 support question
From: Francois Romieu @ 2007-08-10 22:23 UTC (permalink / raw)
  To: Chuck Lever; +Cc: netdev ML
In-Reply-To: <46BCD853.1010801@oracle.com>

Chuck Lever <chuck.lever@oracle.com> :
[...]
> I just bought a new Jetway mainboard with a pair of RTL 8169 NICs. 

Mini-ITX J7F4 ?

> After installing Fedora 7, and upgrading to 2.6.22.1-41.fc7, I still 
> can't get either of the NICs to recognize a link beat from my switch.
> 
> lspci -v output:
> 
> 00:09.0 Ethernet controller: Realtek Semiconductor Co., Ltd. 
> RTL-8110SC/8169SC Gigabit Ethernet (rev 10)
>         Subsystem: Jetway Information Co., Ltd. Unknown device 10ec
>         Flags: bus master, 66MHz, medium devsel, latency 32, IRQ 18
>         I/O ports at ee00 [size=256]
>         Memory at fdffe000 (32-bit, non-prefetchable) [size=256]
>         [virtual] Expansion ROM at 10020000 [disabled] [size=64K]
>         Capabilities: [dc] Power Management version 2
[...]
> I assume "Unknown device" indicates that the driver doesn't recognize 
> the model string?

Not exactly. The driver uses the PCI Vendor ID/Device ID Configuration
registers to identify the chipset. lspci used the same information to
identify a "Realtek... RTL-8110SC/8169SC...". It is a known device.
The driver does not care about the Subsystem ID ("10ec" above) so there
is nothing to worry about here.

> Thanks in advance for any advice.

Have your tried 2.6.23-git-latest or at least a post 2.6.23-rc1 kernel ?

-- 
Ueimor

^ permalink raw reply

* Re: [patch 14/28] dccp: fix memory leak and clean up style - dccp_feat_empty_confirm()
From: David Miller @ 2007-08-10 22:24 UTC (permalink / raw)
  To: akpm; +Cc: netdev, jesper.juhl, ian.mcdonald
In-Reply-To: <200708102111.l7ALBwC1009414@imap1.linux-foundation.org>

From: akpm@linux-foundation.org
Date: Fri, 10 Aug 2007 14:11:57 -0700

> From: Jesper Juhl <jesper.juhl@gmail.com>
> 
> There's a memory leak in net/dccp/feat.c::dccp_feat_empty_confirm().  If we
> hit the 'default:' case of the 'switch' statement, then we return without
> freeing 'opt', thus leaking 'struct dccp_opt_pend' bytes.
> 
> The leak is fixed easily enough by adding a kfree(opt); before the return
> statement.
> 
> The patch also changes the layout of the 'switch' to be more in line with
> CodingStyle.
> 
> Signed-off-by: Jesper Juhl <jesper.juhl@gmail.com>
> Acked-by: Ian McDonald <ian.mcdonald@jandi.co.nz>
> Signed-off-by: Andrew Morton <akpm@linux-foundation.org>

Applied to net-2.6, thanks!

^ permalink raw reply

* Re: [patch 13/28] fib_trie: macro cleanup
From: David Miller @ 2007-08-10 22:23 UTC (permalink / raw)
  To: akpm; +Cc: netdev, shemminger
In-Reply-To: <200708102111.l7ALBv6F009410@imap1.linux-foundation.org>

From: akpm@linux-foundation.org
Date: Fri, 10 Aug 2007 14:11:57 -0700

> From: Stephen Hemminger <shemminger@linux-foundation.org>
> 
> This patch converts the messy macro for MASK_PFX to inline function
> and expands TKEY_GET_MASK in the one place it is used.
> 
> Cc: "David S. Miller" <davem@davemloft.net>
> Signed-off-by: Andrew Morton <akpm@linux-foundation.org>

Applied to net-2.6.24, thanks!

^ permalink raw reply

* Re: [patch 12/28] fib_trie: cleanup
From: David Miller @ 2007-08-10 22:22 UTC (permalink / raw)
  To: akpm; +Cc: netdev, shemminger, paulmck
In-Reply-To: <200708102111.l7ALBuvR009406@imap1.linux-foundation.org>

From: akpm@linux-foundation.org
Date: Fri, 10 Aug 2007 14:11:56 -0700

> From: Stephen Hemminger <shemminger@linux-foundation.org>
> 
> Try this out:
>      * replace macro's with inlines
>      * get rid of places doing multiple evaluations of NODE_PARENT
> 
> [akpm@linux-foundation.org: rcu_dereference wants an lval]
> Cc: "David S. Miller" <davem@davemloft.net>
> Cc: "Paul E. McKenney" <paulmck@linux.vnet.ibm.com>
> Signed-off-by: Andrew Morton <akpm@linux-foundation.org>

Applied to net-2.6.24, thanks!

^ permalink raw reply

* Re: [patch 11/28] fix theoretical ccids_{read,write}_lock() race
From: David Miller @ 2007-08-10 22:21 UTC (permalink / raw)
  To: akpm; +Cc: netdev, oleg, acme, mingo
In-Reply-To: <200708102111.l7ALBteq009403@imap1.linux-foundation.org>

From: akpm@linux-foundation.org
Date: Fri, 10 Aug 2007 14:11:55 -0700

> From: Oleg Nesterov <oleg@tv-sign.ru>
> 
> Make sure that spin_unlock_wait() is properly ordered wrt atomic_inc().
> 
> (akpm: can't we convert this code to use rwlocks?)
> 
> Signed-off-by: Oleg Nesterov <oleg@tv-sign.ru>
> Cc: Arnaldo Carvalho de Melo <acme@redhat.com>
> Cc: Ingo Molnar <mingo@elte.hu>
> Cc: "David S. Miller" <davem@davemloft.net>
> Signed-off-by: Andrew Morton <akpm@linux-foundation.org>

Applied to net-2.6, thanks!

^ permalink raw reply

* Re: [patch 10/28] Clean up duplicate includes in net/xfrm/
From: David Miller @ 2007-08-10 22:20 UTC (permalink / raw)
  To: akpm; +Cc: netdev, jesper.juhl
In-Reply-To: <200708102111.l7ALBt8h009400@imap1.linux-foundation.org>

From: akpm@linux-foundation.org
Date: Fri, 10 Aug 2007 14:11:54 -0700

> From: Jesper Juhl <jesper.juhl@gmail.com>
> 
> This patch cleans up duplicate includes in
> 	net/xfrm/
> 
> Signed-off-by: Jesper Juhl <jesper.juhl@gmail.com>
> Signed-off-by: Andrew Morton <akpm@linux-foundation.org>

Applied to net-2.6, thanks!

^ permalink raw reply

* Re: [patch 09/28] Clean up duplicate includes in net/tipc/
From: David Miller @ 2007-08-10 22:19 UTC (permalink / raw)
  To: akpm; +Cc: netdev, jesper.juhl
In-Reply-To: <200708102111.l7ALBsvm009397@imap1.linux-foundation.org>

From: akpm@linux-foundation.org
Date: Fri, 10 Aug 2007 14:11:54 -0700

> From: Jesper Juhl <jesper.juhl@gmail.com>
> 
> This patch cleans up duplicate includes in
> 	net/tipc/
> 
> Signed-off-by: Jesper Juhl <jesper.juhl@gmail.com>
> Signed-off-by: Andrew Morton <akpm@linux-foundation.org>

Applied to net-2.6, thanks!

^ permalink raw reply

* Re: [patch 08/28] Clean up duplicate includes in net/sunrpc/
From: David Miller @ 2007-08-10 22:19 UTC (permalink / raw)
  To: akpm; +Cc: netdev, jesper.juhl, neilb, trond.myklebust
In-Reply-To: <200708102111.l7ALBreC009394@imap1.linux-foundation.org>

From: akpm@linux-foundation.org
Date: Fri, 10 Aug 2007 14:11:53 -0700

> From: Jesper Juhl <jesper.juhl@gmail.com>
> 
> This patch cleans up duplicate includes in
> 	net/sunrpc/
> 
> Signed-off-by: Jesper Juhl <jesper.juhl@gmail.com>
> Cc: Trond Myklebust <trond.myklebust@fys.uio.no>
> Cc: Neil Brown <neilb@suse.de>
> Signed-off-by: Andrew Morton <akpm@linux-foundation.org>

Applied to net-2.6, thanks!

^ permalink raw reply

* Re: [patch 03/18] drivers/net/ns83820.c: add paramter to disable autonegotiation
From: Andrew Morton @ 2007-08-10 22:18 UTC (permalink / raw)
  To: Benjamin LaHaise; +Cc: jeff, netdev, dan, dan, jgarzik
In-Reply-To: <20070810211349.GD978@kvack.org>

On Fri, 10 Aug 2007 17:13:49 -0400
Benjamin LaHaise <bcrl@kvack.org> wrote:

> On Fri, Aug 10, 2007 at 02:05:13PM -0700, akpm@linux-foundation.org wrote:
> > Also added a "disable_autoneg" module argument to completely disable
> > autoneg on all cards using this driver.
> ...
> > [akpm: this is a previously-nacked patch, but the problem is real]
> 
> Please remove this part of the patch.  The ethtool support is sufficient and 
> doesn't clobber other cards in the system.  At the very least the module 
> parameter has to be limited to a specific card.
> 

I think I'll drop the whole patch.  I've been nursing the thing along for
1.5 years and I don't recall seeing any reports of any bugs which it would
have fixed anyway.

^ permalink raw reply

* Re: [patch 07/28] Clean up duplicate includes in net/sched/
From: David Miller @ 2007-08-10 22:18 UTC (permalink / raw)
  To: akpm; +Cc: netdev, jesper.juhl
In-Reply-To: <200708102111.l7ALBrtS009391@imap1.linux-foundation.org>

From: akpm@linux-foundation.org
Date: Fri, 10 Aug 2007 14:11:53 -0700

> From: Jesper Juhl <jesper.juhl@gmail.com>
> 
> This patch cleans up duplicate includes in
> 	net/sched/
> 
> Signed-off-by: Jesper Juhl <jesper.juhl@gmail.com>
> Signed-off-by: Andrew Morton <akpm@linux-foundation.org>

Applied to net-2.6, thanks!

^ permalink raw reply

* Re: [patch 06/28] Clean up duplicate includes in net/ipv6/
From: David Miller @ 2007-08-10 22:18 UTC (permalink / raw)
  To: akpm; +Cc: netdev, jesper.juhl
In-Reply-To: <200708102111.l7ALBq4E009388@imap1.linux-foundation.org>

From: akpm@linux-foundation.org
Date: Fri, 10 Aug 2007 14:11:52 -0700

> From: Jesper Juhl <jesper.juhl@gmail.com>
> 
> This patch cleans up duplicate includes in
> 	net/ipv6/
> 
> Signed-off-by: Jesper Juhl <jesper.juhl@gmail.com>
> Signed-off-by: Andrew Morton <akpm@linux-foundation.org>

Applied to net-2.6, thanks!

^ permalink raw reply

* Re: [patch 05/28] Clean up duplicate includes in net/ipv4/
From: David Miller @ 2007-08-10 22:17 UTC (permalink / raw)
  To: akpm; +Cc: netdev, jesper.juhl
In-Reply-To: <200708102111.l7ALBqgG009383@imap1.linux-foundation.org>

From: akpm@linux-foundation.org
Date: Fri, 10 Aug 2007 14:11:52 -0700

> From: Jesper Juhl <jesper.juhl@gmail.com>
> 
> This patch cleans up duplicate includes in
> 	net/ipv4/
> 
> Signed-off-by: Jesper Juhl <jesper.juhl@gmail.com>
> Signed-off-by: Andrew Morton <akpm@linux-foundation.org>

Applied to net-2.6

^ permalink raw reply

* Re: [patch 04/28] Clean up duplicate includes in net/atm/
From: David Miller @ 2007-08-10 22:16 UTC (permalink / raw)
  To: akpm; +Cc: netdev, jesper.juhl, chas
In-Reply-To: <200708102111.l7ALBpV4009378@imap1.linux-foundation.org>

From: akpm@linux-foundation.org
Date: Fri, 10 Aug 2007 14:11:51 -0700

> From: Jesper Juhl <jesper.juhl@gmail.com>
> 
> This patch cleans up duplicate includes in
> 	net/atm/
> 
> Signed-off-by: Jesper Juhl <jesper.juhl@gmail.com>
> Cc: Chas Williams <chas@cmf.nrl.navy.mil>
> Signed-off-by: Andrew Morton <akpm@linux-foundation.org>

Applied to net-2.6, thanks!

^ permalink raw reply

* Re: [patch 03/28] Clean up duplicate includes in drivers/atm/
From: David Miller @ 2007-08-10 22:16 UTC (permalink / raw)
  To: akpm; +Cc: netdev, jesper.juhl, chas
In-Reply-To: <200708102111.l7ALBobp009373@imap1.linux-foundation.org>

From: akpm@linux-foundation.org
Date: Fri, 10 Aug 2007 14:11:50 -0700

> From: Jesper Juhl <jesper.juhl@gmail.com>
> 
> This patch cleans up duplicate includes in
> 	drivers/atm/
> 
> Signed-off-by: Jesper Juhl <jesper.juhl@gmail.com>
> Cc: Chas Williams <chas@cmf.nrl.navy.mil>
> Signed-off-by: Andrew Morton <akpm@linux-foundation.org>

Applied to net-2.6

^ permalink raw reply

* Re: [patch 02/28] ip_auto_config fix
From: David Miller @ 2007-08-10 22:15 UTC (permalink / raw)
  To: akpm; +Cc: netdev, joakim.tjernlund, trond.myklebust
In-Reply-To: <200708102111.l7ALBnLl009370@imap1.linux-foundation.org>

From: akpm@linux-foundation.org
Date: Fri, 10 Aug 2007 14:11:49 -0700

> From: Andrew Morton <akpm@linux-foundation.org>
> 
> Davem said (in February!):

:-)

> Signed-off-by: Joakim Tjernlund <joakim.tjernlund@transmode.se>
> Cc: "David S. Miller" <davem@davemloft.net>
> Cc: Trond Myklebust <trond.myklebust@fys.uio.no>
> 
> Signed-off-by: Andrew Morton <akpm@linux-foundation.org>

Applied to net-2.6, thanks!

^ permalink raw reply

* Re: [patch 01/28] fore200e_param_bs_queue() must be __devinit
From: David Miller @ 2007-08-10 22:13 UTC (permalink / raw)
  To: akpm; +Cc: netdev, bunk
In-Reply-To: <200708102111.l7ALBm47009367@imap1.linux-foundation.org>

From: akpm@linux-foundation.org
Date: Fri, 10 Aug 2007 14:11:48 -0700

> From: Adrian Bunk <bunk@stusta.de>
> 
> WARNING: drivers/built-in.o(.text+0x6203bb): Section mismatch: reference to .init.text:fore200e_param_bs_queue (between 'fore200e_initialize' and 'fore200e_monitor_putc')
> 
> Signed-off-by: Adrian Bunk <bunk@stusta.de>
> Signed-off-by: Andrew Morton <akpm@linux-foundation.org>

Bug fix, so applied to net-2.6, thanks.

^ permalink raw reply

* Re: [PATCH 1/4] Add ETHTOOL_[GS]FLAGS sub-ioctls
From: David Miller @ 2007-08-10 22:10 UTC (permalink / raw)
  To: greearb; +Cc: jeff, auke-jan.h.kok, netdev, linux-kernel
In-Reply-To: <46BCD47C.9060408@candelatech.com>

From: Ben Greear <greearb@candelatech.com>
Date: Fri, 10 Aug 2007 14:11:24 -0700

> Jeff Garzik wrote:
> 
> > This patch copies Auke in adding NETIF_F_LRO.  Is that just for 
> > temporary merging, or does the net core really not touch it at all?
> > 
> > Because, logically, if NETIF_F_LRO exists nowhere else but this patch, 
> > we should not add it to dev->features.  LRO knowledge can be contained 
> > entirely within the driver, if the net core never tests NETIF_F_LRO.
> > 
> > I haven't reviewed the other NETIF_F_XXX flags, but, that logic can be 
> > applied to any other NETIF_F_XXX flag:  if the net stack isn't using it, 
> > it's a piece of information specific to that driver.
> 
> I believe LRO is going to have to be disabled for routing/bridging,
> so the stack will probably need to become aware of it at some point...

The packet will be GSO'd on output I believe, so it won't
break anything.

Alternatively, we could make the driver only LRO accumulate if the
packet is unicast and matches one of the MAC's programmed into the
chip.

^ permalink raw reply

* Re: [PATCH for 2.6.24] SCTP: Rewrite of sctp buffer management code
From: David Miller @ 2007-08-10 22:06 UTC (permalink / raw)
  To: vladislav.yasevich; +Cc: netdev, nhorman, lksctp-developers
In-Reply-To: <46BCCE8B.2050605@hp.com>

From: Vlad Yasevich <vladislav.yasevich@hp.com>
Date: Fri, 10 Aug 2007 16:46:03 -0400

> This patch introduces autotuning to the sctp buffer management code
> similar to the TCP.  The buffer space can be grown if the advertised
> receive window still has room.  This might happen if small message
> sizes are used, which is common in telecom environmens.
> New tunables are introduced that provide limits to buffer growth
> and memory pressure is entered if to much buffer spaces is used.
> 
> Signed-off-by: Neil Horman <nhorman@tuxdriver.com>
> Signed-off-by: Vlad Yasevich <vladislav.yasevich@hp.com>

Applied, thanks Vlad.

Can you in the future fix up whitespace issues like this:

Adds trailing whitespace.
diff:21: 
Space in indent is followed by a tab.
diff:27: 	int amt;
Space in indent is followed by a tab.
diff:48: 		amt = asoc->base.sk->sk_sndbuf - amt;
Space in indent is followed by a tab.
diff:55:  	return amt;

I know where the "Space in indent" cases come from, you apply the
patch to merge it into a current tree, you get rejects, then you edit
in the foo.rej hunks by hand into the code but forget to remove the
extra leading whitespace characters.

:-)

^ permalink raw reply

* Re: [PATCH 9/24] make atomic_read() behave consistently on ia64
From: Andreas Schwab @ 2007-08-10 21:42 UTC (permalink / raw)
  To: Luck, Tony
  Cc: Chris Snook, linux-kernel, linux-arch, torvalds, netdev, akpm, ak,
	heiko.carstens, davem, schwidefsky, wensong, horms, wjiang,
	cfriesen, zlynx, rpjday, jesper.juhl
In-Reply-To: <617E1C2C70743745A92448908E030B2A0224C777@scsmsx411.amr.corp.intel.com>

"Luck, Tony" <tony.luck@intel.com> writes:

>> That's distressing.  I'm about to resubmit with a volatile cast in 
>> atomic_set as well, since people expect that behavior and I've been 
>> shown a legitimate case where it could matter.  Does the assembly look 
>> right with that cast in atomic_set() as well?
>
> No.  With the casts to volatile in atomic_set and atomic64_set I
> still see places where ld8 is changed to ld4 + sign-extend.

Use atomic64_read to read an atomic64_t.

Signed-off-by: Andreas Schwab <schwab@suse.de>

diff --git a/include/asm-ia64/atomic.h b/include/asm-ia64/atomic.h
index 1fc3b83..50c2b83 100644
--- a/include/asm-ia64/atomic.h
+++ b/include/asm-ia64/atomic.h
@@ -55,7 +55,7 @@ ia64_atomic64_add (__s64 i, atomic64_t *v)
 
 	do {
 		CMPXCHG_BUGCHECK(v);
-		old = atomic_read(v);
+		old = atomic64_read(v);
 		new = old + i;
 	} while (ia64_cmpxchg(acq, v, old, new, sizeof(atomic64_t)) != old);
 	return new;
@@ -83,7 +83,7 @@ ia64_atomic64_sub (__s64 i, atomic64_t *v)
 
 	do {
 		CMPXCHG_BUGCHECK(v);
-		old = atomic_read(v);
+		old = atomic64_read(v);
 		new = old - i;
 	} while (ia64_cmpxchg(acq, v, old, new, sizeof(atomic64_t)) != old);
 	return new;

Andreas.

-- 
Andreas Schwab, SuSE Labs, schwab@suse.de
SuSE Linux Products GmbH, Maxfeldstraße 5, 90409 Nürnberg, Germany
PGP key fingerprint = 58CA 54C7 6D53 942B 1756  01D3 44D5 214B 8276 4ED5
"And now for something completely different."

^ permalink raw reply related

* Re: [PATCH RFC]: napi_struct V5
From: David Miller @ 2007-08-10 21:39 UTC (permalink / raw)
  To: hadi; +Cc: rdreier, xma, jgarzik, netdev, rusty, shemminger
In-Reply-To: <1186754107.5188.32.camel@localhost>

From: jamal <hadi@cyberus.ca>
Date: Fri, 10 Aug 2007 09:55:07 -0400

> On Thu, 2007-09-08 at 09:58 -0700, Roland Dreier wrote:
> 
> > Could you explain why this is unfair?  
> 
> The simple answer is the core attempts DRR scheduling (search for the
> paper by Varghese et al for more details)
> If you have multiple users of a resource (network interfaces in this
> case), then the quantum defines their weight. If you use more than your
> fair quota, then you are being unfair. 

Actually, in the ipoib case they use less than their share :)

When they re-enable interrupts and then recheck for pending events, if
events are pending they re-disable interrupts and return immediately
instead of looping and trying to use the rest of their available
"budget" in-situ.

They do this because the time it takes to return back to the ->poll()
invoker and then call back into ->poll() the chip accumulates more
work.

If they don't do this it's really easy for them to hit cases where
they process one packet, enable interrupts, more events arrive, so
re-disable interrupts and loop, over and over again which is very
inefficient if that is in fact what happens.

To be honest, it's a workaround for the hardware design and they would
do well with even the most minimalist HW irq mitigation assist.

^ permalink raw reply

* Re: [patch 04/18] via-rhine: disable rx_copybreak on archs that don't allow unaligned DMA access
From: Francois Romieu @ 2007-08-10 21:33 UTC (permalink / raw)
  To: akpm; +Cc: jeff, netdev, jailbird, ink
In-Reply-To: <200708102105.l7AL5FUp008954@imap1.linux-foundation.org>

akpm@linux-foundation.org <akpm@linux-foundation.org> :
> From: Dustin Marquess <jailbird@alcatraz.fdf.net>
> 
> Patch to disable the rx_copybreak feature on hardware architectures that
> don't allow unaligned DMA access.
> 
> #ifdef code taken from tulip_core.c.  Problem pointed out by Ivan
> Kokshaysky.

Color me confused but what are we trying to solve here ?

The rx_copybreak processing is performed after the DMA from the network
card to memory is done: DMA does not care about rx_copybreak. 

-- 
Ueimor

^ permalink raw reply

* Re: [PATCH net-2.6.24] [TCP]: Update comment about highest_sack validity
From: David Miller @ 2007-08-10 21:31 UTC (permalink / raw)
  To: ilpo.jarvinen; +Cc: netdev
In-Reply-To: <Pine.LNX.4.64.0708101428540.20173@kivilampi-30.cs.helsinki.fi>

From: "Ilpo_Järvinen" <ilpo.jarvinen@helsinki.fi>
Date: Fri, 10 Aug 2007 14:30:46 +0300 (EEST)

> 
> This stale info came from the original idea, which proved to be
> unnecessarily complex, sacked_out > 0 is easy to do and that when
> it's going to be needed anyway (it _can_ be valid also when
> sacked_out == 0 but there's not going to be a guarantee about it
> for now).
> 
> Signed-off-by: Ilpo Järvinen <ilpo.jarvinen@helsinki.fi>

Patch applied to net-2.6.24

^ permalink raw reply

* RealTek 8169 support question
From: Chuck Lever @ 2007-08-10 21:27 UTC (permalink / raw)
  To: romieu, netdev ML

[-- Attachment #1: Type: text/plain, Size: 1310 bytes --]

Hello Francois-

I just bought a new Jetway mainboard with a pair of RTL 8169 NICs. 
After installing Fedora 7, and upgrading to 2.6.22.1-41.fc7, I still 
can't get either of the NICs to recognize a link beat from my switch.

lspci -v output:

00:09.0 Ethernet controller: Realtek Semiconductor Co., Ltd. 
RTL-8110SC/8169SC Gigabit Ethernet (rev 10)
         Subsystem: Jetway Information Co., Ltd. Unknown device 10ec
         Flags: bus master, 66MHz, medium devsel, latency 32, IRQ 18
         I/O ports at ee00 [size=256]
         Memory at fdffe000 (32-bit, non-prefetchable) [size=256]
         [virtual] Expansion ROM at 10020000 [disabled] [size=64K]
         Capabilities: [dc] Power Management version 2

00:0b.0 Ethernet controller: Realtek Semiconductor Co., Ltd. 
RTL-8110SC/8169SC Gigabit Ethernet (rev 10)
         Subsystem: Jetway Information Co., Ltd. Unknown device 10ec
         Flags: bus master, 66MHz, medium devsel, latency 32, IRQ 19
         I/O ports at f000 [size=256]
         Memory at fdffd000 (32-bit, non-prefetchable) [size=256]
         [virtual] Expansion ROM at 10030000 [disabled] [size=64K]
         Capabilities: [dc] Power Management version 2

I assume "Unknown device" indicates that the driver doesn't recognize 
the model string?

Thanks in advance for any advice.

[-- Attachment #2: chuck.lever.vcf --]
[-- Type: text/x-vcard, Size: 290 bytes --]

begin:vcard
fn:Chuck Lever
n:Lever;Chuck
org:Oracle Corporation;Corporate Architecture: Linux Projects Group
adr:;;1015 Granger Avenue;Ann Arbor;MI;48104;USA
title:Principal Member of Staff
tel;work:+1 248 614 5091
x-mozilla-html:FALSE
url:http://oss.oracle.com/~cel
version:2.1
end:vcard


^ permalink raw reply

* Re: 2.6.23-rc2-mm2
From: Eric W. Biederman @ 2007-08-10 21:19 UTC (permalink / raw)
  To: Andrew Morton
  Cc: Gabriel C, Michal Piotrowski, linux-kernel, Netdev, coreteam
In-Reply-To: <20070810124156.2de9710e.akpm@linux-foundation.org>

Andrew Morton <akpm@linux-foundation.org> writes:

> There seems to be rather a lot of damage here.
>
> I assume that the sysctl changes are what caused the netfilter oopses.
>
> - nf_conntrack_init() calls nf_conntrack_expect_init() which fails due to
>   sysctl problems.  

In particular sysctl_check_table finds issues with the sysctl table
so register_sysctl_table refuses to register it.

> - nf_conntrack_init() bales out without calling nf_conntrack_helper_init()
>
>   So nf_ct_helper_hsize never gets initialised.
>
> - Later, netfilter client code calls helper_hash(), which gets a
>   divide-by-zero due to nf_ct_helper_hsize==0.
>
>
> yeah, that's a netfilter bug, but we're trying to get kernels tested here. 
> If I'm feeling energetic I'll drop the sysctl changes and do rc2-mm3. 
> Probably I won't feel energetic, but we'll need a lot of fixes here before
> I can release the sysctl changes in another -mm, please.

As a cheap workaround it should be possible to disable SYSCTL support
in 2.6.23-rc2-mm2 to get around these issues.


Andrew for the moment I have just sent you fixes for all of the issues
that I am aware of.  Mostly they are cheap kill the sys_sysctl()
support patches.

Hopefully that is enough to bring the pain level down to manageable.

I hadn't anticipated subsystems failing because they could not register
their sysctl tables.  I was simply expecting things not to show up in
/proc/sys.  And more of the pain of making working sysctl tables to 
be pushed back to developers.

Eric

^ permalink raw reply


This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox