* Re: [Bugme-new] [Bug 9937] New: Bug in bonding driver - Kernel oops whenever driver is loaded with max_bonds parameter
From: Andrew Morton @ 2008-02-11 23:56 UTC (permalink / raw)
To: netdev, Jay Vosburgh; +Cc: bugme-daemon, kantica
In-Reply-To: <bug-9937-10286@http.bugzilla.kernel.org/>
On Mon, 11 Feb 2008 15:04:03 -0800 (PST)
bugme-daemon@bugzilla.kernel.org wrote:
> http://bugzilla.kernel.org/show_bug.cgi?id=9937
>
> Summary: Bug in bonding driver - Kernel oops whenever driver is
> loaded with max_bonds parameter
> Product: Networking
> Version: 2.5
> KernelVersion: 2.6.24.2
> Platform: All
> OS/Version: Linux
> Tree: Mainline
> Status: NEW
> Severity: high
> Priority: P1
> Component: IPV4
> AssignedTo: shemminger@linux-foundation.org
> ReportedBy: kantica@gmail.com
>
>
> Latest working kernel version:
> Earliest failing kernel version: 2.6.24.2
> Distribution: Slackware / Debian GNU/Linux
> Hardware Environment: HP ProLiant DL380 G5 (Debian), Slackware Acer TravelMate
> 4001 Laptop
> Software Environment:
> Problem Description: Kernel oops whenever bonding driver with max_bonds=2 (or >
> 2) is loaded ...
>
> Steps to reproduce:
>
> modprobe bonding mode=0 miimon=100 max_bonds=2
> or
> modprobe bonding max_bonds=2
>
>
> dmesg output (from slackware laptop / x86):
>
> BUG: unable to handle kernel NULL pointer dereference at virtual address
> 00000000
> printing eip: c028eeaf *pde = 00000000
> Oops: 0000 [#1] SMP
> Modules linked in: bonding snd_seq_dummy snd_seq_oss snd_seq_midi_event snd_seq
> snd_seq_device snd_pcm_oss snd_mixer_oss ntfs pcmcia yenta_socket
> rsrc_nonstatic tifm_7xx1 tifm_core pcmcia_core snd_intel8x0 snd_ac97_codec
> ac97_bus snd_pcm i2c_i801 snd_timer snd i2c_core shpchp snd_page_alloc ehci_hcd
> uhci_hcd pci_hotplug
>
> Pid: 2729, comm: modprobe Not tainted (2.6.24.2 #2)
> EIP: 0060:[<c028eeaf>] EFLAGS: 00010282 CPU: 0
> EIP is at strnicmp+0x17/0x61
> EAX: d8162800 EBX: 00000000 ECX: 00000010 EDX: 00000062
> ESI: 00000010 EDI: 00000000 EBP: d8162801 ESP: d82c9f60
> DS: 007b ES: 007b FS: 00d8 GS: 0033 SS: 0068
> Process modprobe (pid: 2729, ti=d82c8000 task=df926550 task.ti=d82c8000)
> Stack: d8162c80 00000000 e0c76814 00000000 e0c67170 00000001 df80b700 e0c77180
> 00000001 00000000 0000000c d82c8000 e0afe05e e0c6ed14 e0c6ce70 e0c76c00
> 0805c098 0000000c c014e355 b7e7a008 0805c098 c0106f12 b7e7a008 00019477
> Call Trace:
> [<e0c67170>] bond_create+0x4a/0x162 [bonding]
> [<e0afe05e>] bonding_init+0x5e/0xf0 [bonding]
> [<c014e355>] sys_init_module+0x91/0x11b
> [<c0106f12>] syscall_call+0x7/0xb
> [<c0470000>] sctp_setsockopt_bindx+0xe8/0x127
> =======================
> Code: 08 fe dc ba 98 c7 40 0c 76 54 32 10 c7 40 10 f0 e1 d2 c3 c3 55 89 c5 57
> 89 d7 31 d2 56 89 ce 53 31 db 85 c9 74 42 0f b6 55 00 45 <0f> b6 1f 47 84 d2 74
> 35 84 db 74 31 38 da 74 2a 0f b6 c2 88 d1
> EIP: [<c028eeaf>] strnicmp+0x17/0x61 SS:ESP 0068:d82c9f60
> ---[ end trace 75761717808bf4ee ]---
>
> dmesg output (from Debian x86_64 - HP ProLiant DL380):
>
> Unable to handle kernel NULL pointer dereference at 0000000000000000 RIP:
> [<ffffffff8030271e>] strnicmp+0x12/0x5f
> PGD 223005067 PUD 223b22067 PMD 0
> Oops: 0000 [1] SMP
> CPU 7
> Modules linked in: bonding mptctl mptbase fan ac battery ipv6 dm_snapshot
> dm_mirror dm_mod loop usbhid ide_cd cdrom bnx2 generic thermal ipmi_si piix
> serio_raw evdev shpchp
> psmouse pci_hotplug container pcspkr ide_core ipmi_msghandler uhci_hcd button
> processor ehci_hcd e1000 ext3 jbd mbcache reiserfs cciss
> Pid: 12469, comm: modprobe Not tainted 2.6.24.2 #1
> RIP: 0010:[<ffffffff8030271e>] [<ffffffff8030271e>] strnicmp+0x12/0x5f
> RSP: 0018:ffff81022339fe00 EFLAGS: 00010202
> RAX: ffff81022307e6c0 RBX: ffffffff88233918 RCX: 00000000000020e7
> RDX: 0000000000000010 RSI: 0000000000000000 RDI: ffff81022307e000
> RBP: 0000000000000000 R08: ffff810223b90362 R09: 0000000000000010
> R10: ffffffff8822d60b R11: 0000000000000001 R12: 0000000000000000
> R13: ffffffff88234b00 R14: ffff81022307e7c8 R15: 0000000000000000
> FS: 00002b07aa3166e0(0000) GS:ffff81022743bd00(0000) knlGS:0000000000000000
> CS: 0010 DS: 0000 ES: 0000 CR0: 000000008005003b
> CR2: 0000000000000000 CR3: 000000022339c000 CR4: 00000000000006e0
> DR0: 0000000000000000 DR1: 0000000000000000 DR2: 0000000000000000
> DR3: 0000000000000000 DR6: 00000000ffff0ff0 DR7: 0000000000000400
> Process modprobe (pid: 12469, threadinfo ffff81022339e000, task
> ffff8102239aa000)
> Stack: ffffffff882200ce ffff8102239ad000 0000000000000001 ffff8102274273c0
> 0000000000000000 0000000000000001 ffffc20011bef960 ffff810225c88540
> ffffffff8809f7bf ffffffff882340c0 ffffffff882340c0 ffff8102263f7f00
> Call Trace:
> [<ffffffff882200ce>] :bonding:bond_create+0x4e/0x30e
> [<ffffffff8809f7bf>] :bonding:bonding_init+0x7bf/0x85d
> [<ffffffff8024f752>] sys_init_module+0x176d/0x183f
> [<ffffffff8020be8e>] system_call+0x7e/0x83
>
>
> Code: 8a 0e 48 ff c7 48 ff c6 45 84 c0 74 36 84 c9 74 32 41 38 c8
> RIP [<ffffffff8030271e>] strnicmp+0x12/0x5f
> RSP <ffff81022339fe00>
> CR2: 0000000000000000
> ---[ end trace ba3d7089e7da64fa ]---
>
^ permalink raw reply
* Re: [PATCH][PPPOL2TP]: Fix SMP oops in pppol2tp driver
From: James Chapman @ 2008-02-11 23:42 UTC (permalink / raw)
To: Jarek Poplawski; +Cc: netdev
In-Reply-To: <20080211225533.GB2863@ami.dom.local>
Jarek Poplawski wrote:
> On Mon, Feb 11, 2008 at 11:49:24PM +0100, Jarek Poplawski wrote:
>> On Mon, Feb 11, 2008 at 10:19:35PM +0000, James Chapman wrote:
>> ...
>>> Below is example output from lockdep. The oops is reproducible when
>>> creating/deleting lots of sessions while passing data. The lock is being
>>> acquired for read and write in softirq contexts.
>
> ...Hmmm... And according to this, changing read_locks should be
> necessary too.
The patch changes both read and write locks.
--
James Chapman
Katalix Systems Ltd
http://www.katalix.com
Catalysts for your Embedded Linux software development
^ permalink raw reply
* Re: [PATCH][PPPOL2TP]: Fix SMP oops in pppol2tp driver
From: James Chapman @ 2008-02-11 23:41 UTC (permalink / raw)
To: Jarek Poplawski; +Cc: netdev
In-Reply-To: <20080211224924.GA2863@ami.dom.local>
Jarek Poplawski wrote:
> On Mon, Feb 11, 2008 at 10:19:35PM +0000, James Chapman wrote:
> ...
>> Below is example output from lockdep. The oops is reproducible when
>> creating/deleting lots of sessions while passing data. The lock is being
>> acquired for read and write in softirq contexts.
>>
>> Is there a better way to fix this?
>>
>> =================================
>> [ INFO: inconsistent lock state ]
>> 2.6.24-core2 #1
>> ---------------------------------
>> inconsistent {in-softirq-R} -> {softirq-on-W} usage.
>> openl2tpd/3215 [HC0[0]:SC0[0]:HE1:SE1] takes:
>> (&tunnel->hlist_lock){---?}, at: [<f8eea157>]
>> pppol2tp_connect+0x517/0x6d0 [pppol2tp]
>> {in-softirq-R} state was registered at:
>
> IMHO, according to this, disabling bh should be enough. And if it's
> like in this report: only read_lock is taken from softirqs, then this
> should be necessary to change only all write_locks to write_lock_bh
> (of course unless somewhere bhs are disabled already). Unless I miss
> something?!
I thought so too. I tried _bh locks first and the problem still
occurred. Maybe I'll try it again in case I messed something up.
--
James Chapman
Katalix Systems Ltd
http://www.katalix.com
Catalysts for your Embedded Linux software development
^ permalink raw reply
* Re: [PATCH][PPPOL2TP]: Fix SMP oops in pppol2tp driver
From: Jarek Poplawski @ 2008-02-11 22:55 UTC (permalink / raw)
To: James Chapman; +Cc: netdev
In-Reply-To: <20080211224924.GA2863@ami.dom.local>
On Mon, Feb 11, 2008 at 11:49:24PM +0100, Jarek Poplawski wrote:
> On Mon, Feb 11, 2008 at 10:19:35PM +0000, James Chapman wrote:
> ...
> > Below is example output from lockdep. The oops is reproducible when
> > creating/deleting lots of sessions while passing data. The lock is being
> > acquired for read and write in softirq contexts.
...Hmmm... And according to this, changing read_locks should be
necessary too.
Jarek P.
^ permalink raw reply
* Re: [PATCH] Execute tasklets in the same order they were queued
From: Andrew Morton @ 2008-02-11 22:49 UTC (permalink / raw)
To: Olof Johansson; +Cc: linux-kernel, netdev
In-Reply-To: <20080211222813.GA14316@lixom.net>
On Mon, 11 Feb 2008 16:28:13 -0600
Olof Johansson <olof@lixom.net> wrote:
> I noticed this when looking at an openswan issue. Openswan (ab?)uses
> the tasklet API to defer processing of packets in some situations,
> with one packet per tasklet_action(). I started noticing sequences of
> reverse-ordered sequence numbers coming over the wire, since new tasklets
> are always queued at the head of the list but processed sequentially.
>
> Convert it to instead append new entries to the tail of the list. As an
> extra bonus, the splicing code in takeover_tasklets() no longer has to
> iterate over the list.
>
hm, I'd have thought that this would already have caused problems in
networking. And perhaps this change might have effects on networking too?
Probably it won't have _much_ effect on networking because networking
probably isn't queueing one tasklet per packet(!) but perhaps with bonded
channels or something like that?
^ permalink raw reply
* Re: [PATCH][PPPOL2TP]: Fix SMP oops in pppol2tp driver
From: Jarek Poplawski @ 2008-02-11 22:49 UTC (permalink / raw)
To: James Chapman; +Cc: netdev
In-Reply-To: <47B0C9F7.5040200@katalix.com>
On Mon, Feb 11, 2008 at 10:19:35PM +0000, James Chapman wrote:
...
> Below is example output from lockdep. The oops is reproducible when
> creating/deleting lots of sessions while passing data. The lock is being
> acquired for read and write in softirq contexts.
>
> Is there a better way to fix this?
>
> =================================
> [ INFO: inconsistent lock state ]
> 2.6.24-core2 #1
> ---------------------------------
> inconsistent {in-softirq-R} -> {softirq-on-W} usage.
> openl2tpd/3215 [HC0[0]:SC0[0]:HE1:SE1] takes:
> (&tunnel->hlist_lock){---?}, at: [<f8eea157>]
> pppol2tp_connect+0x517/0x6d0 [pppol2tp]
> {in-softirq-R} state was registered at:
IMHO, according to this, disabling bh should be enough. And if it's
like in this report: only read_lock is taken from softirqs, then this
should be necessary to change only all write_locks to write_lock_bh
(of course unless somewhere bhs are disabled already). Unless I miss
something?!
Cheers,
Jarek P.
^ permalink raw reply
* Re: [PATCH] mlx4: needs vmalloc.h for vmap()
From: Roland Dreier @ 2008-02-11 22:34 UTC (permalink / raw)
To: Kyle McMartin; +Cc: netdev, Roland Dreier, Jack Morgenstein
In-Reply-To: <20080211221115.GH4516@phobos.i.cabal.ca>
thanks, just merged the same patch from Olof Johansson.
^ permalink raw reply
* Re: WARN_ON() hit in fsl bitbanged phy driver
From: Scott Wood @ 2008-02-11 22:26 UTC (permalink / raw)
To: Rune Torgersen; +Cc: linuxppc-dev, netdev
In-Reply-To: <DCEAAC0833DD314AB0B58112AD99B93B03F9325F@ismail.innsys.innovsys.com>
Rune Torgersen wrote:
> Scott Wood wrote:
>> Rune Torgersen wrote:
>>> I hit the following WARN_ON when using mii-tools agains a ethernet
>>> interface using a bit-banged mii interface
>> It looks like the kernel thinks it's in an interrupt, even though it
>> clearly isn't from the backtrace. Presumably, something
>> slept from an
>> interrupt handler; try turning on sleep-in-spinlock debugging.
>
> I turned on sleep-in-spinlock and it did not reveal anything. I'm trying
> some other debug options.
>
>> The root cause was probably something other than the phy code.
> I'm not so sure, because it only happens when I run mii-tool agains the
> interface useing the bit-banged driver, and then only the first time.
OK, it seems I should have checked 2.6.24 instead of head-of-tree;
softirq.c:139 is a different assertion than I thought. It's not
in_irq(), but irqs_disabled(). fs_ioctl() is disabling interrupts, and
spin_unlock_bh() doesn't like that. The current use of mutexes likes it
even less. The locking should be moved inside the phy bus
implementation, if it's needed at all.
It only happens once because it's a WARN_ON_ONCE(). :-)
-Scott
^ permalink raw reply
* [PATCH] mlx4: needs vmalloc.h for vmap()
From: Kyle McMartin @ 2008-02-11 22:11 UTC (permalink / raw)
To: netdev; +Cc: Roland Dreier, Jack Morgenstein
Commit 313abe55a87bc10e55d00f337d609e17ad5f8c9a added a vmap usage to
mlx4. Unfortunately on some platforms (ppc64) <linux/vmalloc.h> is not
implicitly included. Fix that.
Signed-off-by: Kyle McMartin <kmcmartin@redhat.com>
---
diff --git a/drivers/net/mlx4/alloc.c b/drivers/net/mlx4/alloc.c
index 521dc03..75ef9d0 100644
--- a/drivers/net/mlx4/alloc.c
+++ b/drivers/net/mlx4/alloc.c
@@ -34,6 +34,7 @@
#include <linux/slab.h>
#include <linux/bitmap.h>
#include <linux/dma-mapping.h>
+#include <linux/vmalloc.h>
#include "mlx4.h"
^ permalink raw reply related
* Re: [PATCH][PPPOL2TP]: Fix SMP oops in pppol2tp driver
From: James Chapman @ 2008-02-11 22:19 UTC (permalink / raw)
To: Jarek Poplawski; +Cc: netdev
In-Reply-To: <47B09A90.7040508@gmail.com>
Jarek Poplawski wrote:
> James Chapman wrote, On 02/11/2008 10:22 AM:
>
>> Fix locking issues in the pppol2tp driver which can cause a kernel
>> crash on SMP boxes when hundreds of L2TP sessions are created/deleted
>> simultaneously (ISP environment). The driver was violating read_lock()
>> and write_lock() scheduling rules so we now consistently use the _irq
>> variants of the lock functions.
> ...
>
> Hi,
>
> Could you explain what exactly scheduling rules do you mean here,
> and why disabling interrupts is the best solution for this?
Below is example output from lockdep. The oops is reproducible when
creating/deleting lots of sessions while passing data. The lock is being
acquired for read and write in softirq contexts.
Is there a better way to fix this?
=================================
[ INFO: inconsistent lock state ]
2.6.24-core2 #1
---------------------------------
inconsistent {in-softirq-R} -> {softirq-on-W} usage.
openl2tpd/3215 [HC0[0]:SC0[0]:HE1:SE1] takes:
(&tunnel->hlist_lock){---?}, at: [<f8eea157>]
pppol2tp_connect+0x517/0x6d0 [pppol2tp]
{in-softirq-R} state was registered at:
[<c014edaf>] __lock_acquire+0x6bf/0x10a0
[<c03ee75b>] fn_hash_lookup+0x1b/0xe0
[<c014f804>] lock_acquire+0x74/0xa0
[<f8ee859f>] pppol2tp_session_find+0x1f/0x80 [pppol2tp]
[<c040427a>] _read_lock+0x2a/0x40
[<f8ee859f>] pppol2tp_session_find+0x1f/0x80 [pppol2tp]
[<f8ee859f>] pppol2tp_session_find+0x1f/0x80 [pppol2tp]
[<f8ee8dc8>] pppol2tp_recv_core+0xd8/0x960 [pppol2tp]
[<f8d3f72a>] ipt_do_table+0x23a/0x500 [ip_tables]
[<f8ee967e>] pppol2tp_udp_encap_recv+0x2e/0x70 [pppol2tp]
[<c0403fb4>] _read_unlock+0x14/0x20
[<c03dd696>] udp_queue_rcv_skb+0x106/0x2a0
[<c03ddc5a>] __udp4_lib_rcv+0x42a/0x7e0
[<f8d57090>] ipt_hook+0x0/0x20 [iptable_filter]
[<c03bc2da>] ip_local_deliver_finish+0xca/0x1c0
[<c03bc23e>] ip_local_deliver_finish+0x2e/0x1c0
[<c03bbfaf>] ip_rcv_finish+0xff/0x360
[<c03bc6dc>] ip_rcv+0x20c/0x2a0
[<c03bbeb0>] ip_rcv_finish+0x0/0x360
[<c039ad87>] netif_receive_skb+0x317/0x4b0
[<c039ab70>] netif_receive_skb+0x100/0x4b0
[<f8d9627a>] e1000_clean_rx_irq_ps+0x28a/0x560 [e1000]
[<f8d95ff0>] e1000_clean_rx_irq_ps+0x0/0x560 [e1000]
[<f8d9384d>] e1000_clean+0x5d/0x290 [e1000]
[<c039d580>] net_rx_action+0x1a0/0x2a0
[<c039d43f>] net_rx_action+0x5f/0x2a0
[<c0131e72>] __do_softirq+0x92/0x120
[<c0131f78>] do_softirq+0x78/0x80
[<c010b15a>] do_IRQ+0x4a/0xa0
[<c0108dcc>] common_interrupt+0x24/0x34
[<c0108dd6>] common_interrupt+0x2e/0x34
[<c01062d6>] mwait_idle_with_hints+0x46/0x60
[<c0106550>] mwait_idle+0x0/0x20
[<c0106694>] cpu_idle+0x74/0xe0
[<c0536a9a>] start_kernel+0x30a/0x3a0
[<c0536150>] unknown_bootoption+0x0/0x1f0
[<ffffffff>] 0xffffffff
irq event stamp: 275
hardirqs last enabled at (275): [<c0132317>] local_bh_enable_ip+0xa7/0x120
hardirqs last disabled at (273): [<c01322a6>] local_bh_enable_ip+0x36/0x120
softirqs last enabled at (274): [<f8eab8bc>]
ppp_register_channel+0xdc/0xf0 [ppp_generic]
softirqs last disabled at (272): [<c040410b>] _spin_lock_bh+0xb/0x40
--
James Chapman
Katalix Systems Ltd
http://www.katalix.com
Catalysts for your Embedded Linux software development
^ permalink raw reply
* RE: WARN_ON() hit in fsl bitbanged phy driver
From: Rune Torgersen @ 2008-02-11 22:12 UTC (permalink / raw)
To: Scott Wood; +Cc: linuxppc-dev, netdev
In-Reply-To: <47B0C30A.1030801@freescale.com>
Scott Wood wrote:
> Rune Torgersen wrote:
>> I hit the following WARN_ON when using mii-tools agains a ethernet
>> interface using a bit-banged mii interface
>
> It looks like the kernel thinks it's in an interrupt, even though it
> clearly isn't from the backtrace. Presumably, something
> slept from an
> interrupt handler; try turning on sleep-in-spinlock debugging.
I turned on sleep-in-spinlock and it did not reveal anything. I'm trying
some other debug options.
> The root cause was probably something other than the phy code.
I'm not so sure, because it only happens when I run mii-tool agains the
interface useing the bit-banged driver, and then only the first time.
^ permalink raw reply
* Re: WARN_ON() hit in fsl bitbanged phy driver
From: Scott Wood @ 2008-02-11 21:50 UTC (permalink / raw)
To: Rune Torgersen; +Cc: linuxppc-dev, netdev
In-Reply-To: <DCEAAC0833DD314AB0B58112AD99B93B03F931E6@ismail.innsys.innovsys.com>
Rune Torgersen wrote:
> I hit the following WARN_ON when using mii-tools agains a ethernet
> interface using a bit-banged mii interface
> It is only diplayed once, and does not seem to impact usage at all
>
> Does somebody know what is wrong, and how to fix it?
It looks like the kernel thinks it's in an interrupt, even though it
clearly isn't from the backtrace. Presumably, something slept from an
interrupt handler; try turning on sleep-in-spinlock debugging.
The root cause was probably something other than the phy code.
-Scott
^ permalink raw reply
* WARN_ON() hit in fsl bitbanged phy driver
From: Rune Torgersen @ 2008-02-11 21:28 UTC (permalink / raw)
To: linuxppc-dev, netdev
I hit the following WARN_ON when using mii-tools agains a ethernet
interface using a bit-banged mii interface
It is only diplayed once, and does not seem to impact usage at all
Does somebody know what is wrong, and how to fix it?
The PHY is an Intel LXT973
Badness at kernel/softirq.c:139
NIP: c001f8bc LR: c0121170 CTR: c01269d8
REGS: dfaa5ce0 TRAP: 0700 Tainted: P (2.6.24-cpu2)
MSR: 00021032 <ME,IR,DR> CR: 20002222 XER: 20000000
TASK = de0c2b40[825] 'mii-tool' THREAD: dfaa4000
GPR00: 00000001 dfaa5d90 de0c2b40 0000782d 00000000 00000005 00000001
0ff6a37c
GPR08: 00000000 c0250000 df86bb60 08000000 80000242 1001aa20 00000000
100aa258
GPR16: 10090000 00000000 10090000 00000000 10070000 100aa170 10010000
bff3bd94
GPR24: 00000003 00000000 00000001 c0123234 0000782d dfaa4000 00000000
df003a00
NIP [c001f8bc] local_bh_enable+0x28/0x9c
LR [c0121170] phy_read+0x5c/0x74
Call Trace:
[dfaa5d90] [dfaa4000] 0xdfaa4000 (unreliable)
[dfaa5da0] [c0121170] phy_read+0x5c/0x74
drivers/net/phy/phy.c:80
[dfaa5dc0] [c012140c] phy_mii_ioctl+0x64/0x170
drivers/net/phy/phy.c:368
[dfaa5de0] [c0125394] fs_ioctl+0x4c/0x8c
[dfaa5e00] [c0143744] dev_ifsioc+0x2e8/0x314
[dfaa5e20] [c0144eb8] dev_ioctl+0x6f4/0x8a8
[dfaa5ea0] [c0136aa8] sock_ioctl+0x1fc/0x21c
[dfaa5ec0] [c00742e0] do_ioctl+0x44/0xa8
[dfaa5ee0] [c00746e8] vfs_ioctl+0x3a4/0x3e8
[dfaa5f10] [c007476c] sys_ioctl+0x40/0x70
[dfaa5f40] [c000edc8] ret_from_syscall+0x0/0x38
--- Exception: c01 at 0xff6a37c
LR = 0xffecd58
Instruction dump:
7c0803a6 4e800020 9421fff0 7c0802a6 90010014 7c0000a6 70098000 40a2002c
3d20c025 8009d2a8 7c000034 5400d97e <0f000000> 2f800000 41be0010
38000001
(gdb) list *0xc0121170
0xc0121170 is in phy_read (drivers/net/phy/phy.c:80).
75 spin_lock_bh(&bus->mdio_lock);
76 retval = bus->read(bus, phydev->addr, regnum);
77 spin_unlock_bh(&bus->mdio_lock);
78
79 return retval;
80 }
81 EXPORT_SYMBOL(phy_read);
82
83 /**
84 * phy_write - Convenience function for writing a given PHY
register
(gdb) list *0xc012140c
0xc012140c is in phy_mii_ioctl (drivers/net/phy/phy.c:368).
363 switch (cmd) {
364 case SIOCGMIIPHY:
365 mii_data->phy_id = phydev->addr;
366 break;
367 case SIOCGMIIREG:
368 mii_data->val_out = phy_read(phydev,
mii_data->reg_num);
369 break;
370
371 case SIOCSMIIREG:
372 if (!capable(CAP_NET_ADMIN))
(gdb) list *0xc001f8bc
0xc001f8bc is in local_bh_enable (kernel/softirq.c:139).
134 #ifdef CONFIG_TRACE_IRQFLAGS
135 unsigned long flags;
136
137 WARN_ON_ONCE(in_irq());
138 #endif
139 WARN_ON_ONCE(irqs_disabled());
140
141 #ifdef CONFIG_TRACE_IRQFLAGS
142 local_irq_save(flags);
143 #endif
the relevant part of my device tree is:
ethernet@11340 {
device_type = "network";
compatible = "fsl,mpc8280-fcc-enet",
"fsl,cpm2-fcc-enet";
reg = <11340 20 8600 100 113d0 1>;
interrupts = <22 8>;
interrupt-parent = <&PIC>;
phy-handle = <&PHY1>;
linux,network-index = <1>;
fsl,cpm-command = <1a400300>;
local-mac-address = [00 00 00 00 00 00];
};
mdio@10d40 {
device_type = "mdio";
compatible = "fsl,pq2fads-mdio-bitbang",
"fsl,mpc8280-mdio-bitbang",
"fsl,cpm2-mdio-bitbang";
#address-cells = <1>;
#size-cells = <0>;
reg = <10d40 14>;
fsl,mdio-pin = <5>;
fsl,mdc-pin = <4>;
PHY1: ethernet-phy@1 {
//interrupt-parent = <&PIC>;
//interrupts = <19 2>;
reg = <1>;
device_type = "ethernet-phy";
};
};
^ permalink raw reply
* An ioctl to delete an ipv6 tunnel leads to a kernel panic
From: Natalie Protasevich @ 2008-02-11 20:49 UTC (permalink / raw)
To: David Miller, netdev; +Cc: Andrew Morton
Hello,
This bug was reported to bugzilla.kernel.org:
http://bugzilla.kernel.org/show_bug.cgi?id=8895
Hardware Environment: user mode linux and vmware
Software Environment: an evolution of mip6d (ip mobility daemon)
Problem Description: The mip6d HA was modified to make a
redondancy evolution, when an HA is interrupted, the other takes over,
this leads to some
creation/deletion of routes and tunnels.
Note: The HA ip address known by the mobile (MR) stays the same, the
slave HA takes it with an override neighbor advertisement message. So
the tunnel between
the mobile router and the HA(s) keep the same end adresses.
The problem occurs when a Ctrl C is done on the master HA, the slave
takes over but sometimes, the master gets a kernel panic.
Possible reason for this failure was identified and tested by the
submitter and several other reporters that ran into the same problem.
Can the patch be reviewed and pushed upstream if accepted (if the
problem hasn't been addressed already)?
Thanks,
--Natalie
^ permalink raw reply
* Re: [patch 2.6.24-git] net/enc28j60: oops fix, low power mode
From: David Brownell @ 2008-02-11 20:23 UTC (permalink / raw)
To: Claudio Lanconelli; +Cc: netdev
In-Reply-To: <47B03A9A.2060605@eptar.com>
On Monday 11 February 2008, Claudio Lanconelli wrote:
> I have tried your latest patch. Only after the following change it
> works fine (no more rx errors during ifconfig up).
Hmm, what chip rev do you have? Different errata and all.
ISTR mine is rev4; so, not the most current, but not the
oldest version either.
> I added enc28j60_lowpower(false) just before enc28j60_hw_init()
Hmm, I'd have expected it would go best *before* that, but
what you include below shows it going *after* ...
If there's some problem where reset doesn't work correctly
in low power mode, who knows what else would need manual
resetting.
> @@ -1318,8 +1347,9 @@
> }
> return -EADDRNOTAVAIL;
> }
> - /* Reset the hardware here */
> + /* Reset the hardware here (and take it out of low power mode) */
> enc28j60_hw_disable(priv);
> + enc28j60_lowpower(priv, false);
> if (!enc28j60_hw_init(priv)) {
> if (netif_msg_ifup(priv))
> dev_err(&dev->dev, "hw_reset() failed\n");
>
> With this addition you can add Acked-by line.
Better yet, since I can't reproduce the problem, why don't
you just update my latest patch with the relevant version
of this tweak, and then forward it as "From: " me and with
both our signoffs. That's the usual way to cope with this
type of tweaking. (Not all updates to your driver should
need your signoff, but then most patches shouldn't need
very many iterations either.)
- Dave
^ permalink raw reply
* Re: [git patches] net driver updates
From: Divy Le Ray @ 2008-02-11 20:07 UTC (permalink / raw)
To: Jeff Garzik; +Cc: David Miller, netdev, LKML
In-Reply-To: <20080211170516.GA13872@havoc.gtf.org>
Jeff Garzik wrote:
> Mostly fixes, a few cleanups (generally assisting fixes), and an
> exception for PS3 wireless because it had been posted, reviewed and
> acked for a while, just not committed.
>
> Please pull from 'upstream-davem' branch of
> master.kernel.org:/pub/scm/linux/kernel/git/jgarzik/netdev-2.6.git upstream-davem
>
> to receive the following updates:
>
>
> drivers/net/cxgb3/sge.c | 35 +-
>
>
> diff --git a/drivers/net/cxgb3/sge.c b/drivers/net/cxgb3/sge.c
> index 9ca8c66..979f3fc 100644
> --- a/drivers/net/cxgb3/sge.c
> +++ b/drivers/net/cxgb3/sge.c
> @@ -1059,6 +1059,14 @@ static void write_tx_pkt_wr(struct adapter *adap, struct sk_buff *skb,
> htonl(V_WR_TID(q->token)));
> }
>
> +static inline void t3_stop_queue(struct net_device *dev, struct sge_qset *qs,
> + struct sge_txq *q)
> +{
> + netif_stop_queue(dev);
> + set_bit(TXQ_ETH, &qs->txq_stopped);
> + q->stops++;
> +}
> +
> /**
> * eth_xmit - add a packet to the Ethernet Tx queue
> * @skb: the packet
> @@ -1090,31 +1098,18 @@ int t3_eth_xmit(struct sk_buff *skb, struct net_device *dev)
> ndesc = calc_tx_descs(skb);
>
> if (unlikely(credits < ndesc)) {
> - if (!netif_queue_stopped(dev)) {
> - netif_stop_queue(dev);
> - set_bit(TXQ_ETH, &qs->txq_stopped);
> - q->stops++;
> - dev_err(&adap->pdev->dev,
> - "%s: Tx ring %u full while queue awake!\n",
> - dev->name, q->cntxt_id & 7);
> - }
> + t3_stop_queue(dev, qs, q);
> + dev_err(&adap->pdev->dev,
> + "%s: Tx ring %u full while queue awake!\n",
> + dev->name, q->cntxt_id & 7);
> spin_unlock(&q->lock);
> return NETDEV_TX_BUSY;
> }
>
> q->in_use += ndesc;
> - if (unlikely(credits - ndesc < q->stop_thres)) {
> - q->stops++;
> - netif_stop_queue(dev);
> - set_bit(TXQ_ETH, &qs->txq_stopped);
> -#if !USE_GTS
> - if (should_restart_tx(q) &&
> - test_and_clear_bit(TXQ_ETH, &qs->txq_stopped)) {
> - q->restarts++;
> - netif_wake_queue(dev);
> - }
> -#endif
> - }
> + if (unlikely(credits - ndesc < q->stop_thres))
> + if (USE_GTS || !should_restart_tx(q))
> + t3_stop_queue(dev, qs, q);
>
> gen = q->gen;
> q->unacked += ndesc;
>
Hi Jeff,
I thought I had NAK'ed the patch modifying sge.c from Krishna Kumar.
Looking back at my answer at the time, I was obviously unclear.
Can you please revert the drivers/net/cxgb3sge.c change ?
Cheers,
Divy
^ permalink raw reply
* RE: [Patch 2.6.24 1/3]S2io: Support for vlan_rx_kill_vid entry point
From: Ramkrishna Vepa @ 2008-02-11 20:02 UTC (permalink / raw)
To: Jeff Garzik, Sreenivasa Honnur; +Cc: netdev, support
In-Reply-To: <47B0740B.5040006@garzik.org>
Reply inline -
> Subject: Re: [Patch 2.6.24 1/3]S2io: Support for vlan_rx_kill_vid
entry
> point
>
> Sreenivasa Honnur wrote:
> > - Added s2io_vlan_rx_kill_vid entry point function for unregistering
> vlan.
> > - Fix to aggregate vlan packets. IP offset is incremented by
> > 4 bytes if the packet contains vlan header.
> > - resubmit for 2.6.24 kernel
> >
> > Signed-off-by: Surjit Reang <surjit.reang@neterion.com>
> > Signed-off-by: Ramkrishna Vepa <ram.vepa@neterion.com>
>
> it's difficult to sort through these patches, because they clash a bit
> with the kernel development model.
>
> You always need to send against the latest kernel (generally davem's
> tree if it's during -rc bug fix cycle, or linus's otherwise).
[Ram] Got it. We thought the window was still open for 2.6.24...
>
> Once the changes are in place, then email the commit ids or backported
> patches to stable@kernel.org for inclusion in an already-released
kernel.
>
> In this case, 2.6.24 was well on its way to being released weeks ago,
> when this set of patches was last resend (and then I subsequently
> screwed up, and apparently applied a wrong patch, as discussed)
>
> So what we need are patches against the latest kernel
> (torvalds/linux-2.6.git), and after those are applied, email
> stable@kernel.org with whatever you want in 2.6.24.x.
[Ram] We will recreate these patches (with fixes and features) based on
torvalds/linux-2.6.git, and then send the fixes alone to
stable@kernel.org for 2.6.24.x.
Thanks,
Ram
>
> Jeff
>
>
^ permalink raw reply
* Re: [PATCH 1/6] [NET] replace code with FIELD_SIZEOF
From: Jeff Garzik @ 2008-02-11 19:51 UTC (permalink / raw)
To: Auke Kok; +Cc: e1000-devel, netdev
In-Reply-To: <20080211172539.29090.99369.stgit@localhost.localdomain>
Auke Kok wrote:
> From: Julia Lawall <julia@diku.dk>
>
> Signed-off-by: Julia Lawall <julia@diku.dk>
> Signed-off-by: Auke Kok <auke-jan.h.kok@intel.com>
> ---
>
> drivers/net/e1000/e1000_ethtool.c | 2 +-
> drivers/net/igb/igb_ethtool.c | 2 +-
> drivers/net/ixgb/ixgb_ethtool.c | 2 +-
> 3 files changed, 3 insertions(+), 3 deletions(-)
applied 1-6 to #upstream-fixes
-------------------------------------------------------------------------
This SF.net email is sponsored by: Microsoft
Defy all challenges. Microsoft(R) Visual Studio 2008.
http://clk.atdmt.com/MRT/go/vse0120000070mrt/direct/01/
^ permalink raw reply
* Re: [PATCH 3/5 v3] Tsi108_eth: remove not needed code
From: Jeff Garzik @ 2008-02-11 19:50 UTC (permalink / raw)
To: Alex Bounine; +Cc: netdev, linuxppc-dev
In-Reply-To: <d5f62df20802111135q36e47070w611291b2cea2253e@mail.gmail.com>
Alex Bounine wrote:
> Code clean-up for tsi108_eth network driver.
> This patch removes not needed dummy read and the corresponding comment.
> The PHY logic requires two reads from the status register to get
> current link status. This is done correctly inside mii_check_media().
>
> Signed-off-by: Alexandre Bounine <alexandreb@tundra.com>
> ---
>
> diff -pNur linux-2.6.24/drivers/net/tsi108_eth.c
> linux-2.6.24-fix/drivers/net/tsi108_eth.c
> --- linux-2.6.24/drivers/net/tsi108_eth.c 2008-02-06 15:47:35.000000000 -0500
> +++ linux-2.6.24-fix/drivers/net/tsi108_eth.c 2008-02-06
> 15:54:14.000000000 -0500
> @@ -297,18 +297,11 @@ static void tsi108_check_phy(struct net_
> u32 speed;
> unsigned long flags;
>
> - /* Do a dummy read, as for some reason the first read
> - * after a link becomes up returns link down, even if
> - * it's been a while since the link came up.
> - */
> -
> spin_lock_irqsave(&phy_lock, flags);
>
> if (!data->phy_ok)
> goto out;
>
> - tsi108_read_mii(data, MII_BMSR);
> -
> duplex = mii_check_media(&data->mii_if, netif_msg_link(data),
> data->init_media);
applied all five, but each one was still corrupted according to git-am.
I was able to apply four via patch(1), which is more forgiving, but
there are still email problems.
As as you can see from the above quoted (last) line, your email client
is still word-wrapping patches.
^ permalink raw reply
* Re: [PATCH] [IPV4]: Remove warning in node_set_parent.
From: Stephen Hemminger @ 2008-02-11 19:48 UTC (permalink / raw)
To: Denis V. Lunev; +Cc: davem, netdev, devel, Denis V. Lunev
In-Reply-To: <1202719637-4925-1-git-send-email-den@openvz.org>
On Mon, 11 Feb 2008 11:47:17 +0300
"Denis V. Lunev" <den@openvz.org> wrote:
> net/ipv4/fib_trie.c: In function 'node_set_parent':
> net/ipv4/fib_trie.c:184: warning: assignment makes integer from pointer
> without a cast
>
> Signed-off-by: Denis V. Lunev <den@openvz.org>
> ---
> net/ipv4/fib_trie.c | 7 ++++---
> 1 files changed, 4 insertions(+), 3 deletions(-)
>
> diff --git a/net/ipv4/fib_trie.c b/net/ipv4/fib_trie.c
> index f5fba3f..1753cd4 100644
> --- a/net/ipv4/fib_trie.c
> +++ b/net/ipv4/fib_trie.c
> @@ -177,10 +177,11 @@ static inline struct tnode *node_parent_rcu(struct node *node)
> return rcu_dereference(ret);
> }
>
> -static inline void node_set_parent(struct node *node, struct tnode *ptr)
> +static inline void node_set_parent(struct node *node, struct tnode *__ptr)
> {
> - rcu_assign_pointer(node->parent,
> - (unsigned long)ptr | NODE_TYPE(node));
> + struct node *ptr;
> + ptr = (struct node *)((unsigned long)__ptr | NODE_TYPE(node));
> + rcu_assign_pointer(node->parent, ptr);
> }
>
> static inline struct node *tnode_get_child(struct tnode *tn, unsigned int i)
No, this causes new warning from assigning pointer (ptr) to integer node->parent.
Why not just change rcupdate.h to do the right thing.
>From a00f7cbf1c2f2282eced236e1e8b99b0fecd213a Mon Sep 17 00:00:00 2001
From: Stephen Hemminger <stephen.hemminger@vyatta.com>
Date: Mon, 11 Feb 2008 11:28:13 -0800
Subject: [PATCH] eliminate warnings when rcu_assign_pointer is used with unsigned long
It is reasonable to use RCU with non-pointer values, and describe
the optimization.
Signed-off-by: Stephen Hemminger <shemminger@vyatta.com>
---
include/linux/rcupdate.h | 13 +++++++------
1 files changed, 7 insertions(+), 6 deletions(-)
diff --git a/include/linux/rcupdate.h b/include/linux/rcupdate.h
index 37a642c..c44ac87 100644
--- a/include/linux/rcupdate.h
+++ b/include/linux/rcupdate.h
@@ -172,14 +172,15 @@ struct rcu_head {
* structure after the pointer assignment. More importantly, this
* call documents which pointers will be dereferenced by RCU read-side
* code.
+ *
+ * If value is the NULL (constant 0), then no barrier is needed.
*/
-#define rcu_assign_pointer(p, v) \
- ({ \
- if (!__builtin_constant_p(v) || \
- ((v) != NULL)) \
- smp_wmb(); \
- (p) = (v); \
+#define rcu_assign_pointer(p, v) \
+ ({ \
+ if (!(__builtin_constant_p(v) && v)) \
+ smp_wmb(); \
+ (p) = (v); \
})
/**
--
1.5.3.8
--
Stephen Hemminger <stephen.hemminger@vyatta.com>
^ permalink raw reply related
* Re: [BUG] bad address in twothirdsMD4Transform
From: Jiri Slaby @ 2008-02-11 19:47 UTC (permalink / raw)
To: Matt Mackall; +Cc: netdev, David S. Miller, Andrew Morton
In-Reply-To: <1202758960.12383.2.camel@cinder.waste.org>
On 02/11/2008 08:42 PM, Matt Mackall wrote:
>> BUG: unable to handle kernel paging request at ffff8102366213f8
>> IP: [<ffffffff803558f4>] twothirdsMD4Transform+0xc4/0x3b0
>
> You should mention what kernel you're using.
Kernel version is in the bug below modules and above registers.
> This bug is only in -mm
> (you didn't cc: Andrew), and it's fixed here:
>
> http://www.kernel.org/pub/linux/kernel/people/akpm/patches/2.6/2.6.24/2.6.24-mm1/hot-fixes/random-clean-up-checkpatch-complaints-fix.patch
I need to ask google first! Sorry.
^ permalink raw reply
* Re: [BUG] bad address in twothirdsMD4Transform
From: Matt Mackall @ 2008-02-11 19:42 UTC (permalink / raw)
To: Jiri Slaby; +Cc: netdev, David S. Miller, Andrew Morton
In-Reply-To: <47B0A220.8040400@gmail.com>
On Mon, 2008-02-11 at 20:29 +0100, Jiri Slaby wrote:
> Hi,
>
> I get this with 32 bit Firefox 3b2 and java 1.6.0_03 on 64 bit:
>
> BUG: unable to handle kernel paging request at ffff8102366213f8
> IP: [<ffffffff803558f4>] twothirdsMD4Transform+0xc4/0x3b0
You should mention what kernel you're using. This bug is only in -mm
(you didn't cc: Andrew), and it's fixed here:
http://www.kernel.org/pub/linux/kernel/people/akpm/patches/2.6/2.6.24/2.6.24-mm1/hot-fixes/random-clean-up-checkpatch-complaints-fix.patch
--
Mathematics is the supreme nostalgia of our time.
^ permalink raw reply
* [PATCH 5/5 v3] Tsi108_eth: Add ethtool support
From: Alex Bounine @ 2008-02-11 19:36 UTC (permalink / raw)
To: jgarzik, netdev; +Cc: linuxppc-dev, tie-fei.zang, jwboyer
Add ethtool support to tsi108_eth network driver.
Signed-off-by: Alexandre Bounine <alexandreb@tundra.com>
---
diff -pNur linux-2.6.24/drivers/net/tsi108_eth.c
linux-2.6.24-fix/drivers/net/tsi108_eth.c
--- linux-2.6.24/drivers/net/tsi108_eth.c 2008-02-06 17:10:53.000000000 -0500
+++ linux-2.6.24-fix/drivers/net/tsi108_eth.c 2008-02-06
18:09:43.000000000 -0500
@@ -36,6 +36,7 @@
#include <linux/net.h>
#include <linux/netdevice.h>
#include <linux/etherdevice.h>
+#include <linux/ethtool.h>
#include <linux/skbuff.h>
#include <linux/slab.h>
#include <linux/spinlock.h>
@@ -1519,12 +1520,46 @@ static void tsi108_init_mac(struct net_d
TSI_WRITE(TSI108_EC_INTMASK, ~0);
}
+static int tsi108_get_settings(struct net_device *dev, struct ethtool_cmd *cmd)
+{
+ struct tsi108_prv_data *data = netdev_priv(dev);
+ unsigned long flags;
+ int rc;
+
+ spin_lock_irqsave(&data->txlock, flags);
+ rc = mii_ethtool_gset(&data->mii_if, cmd);
+ spin_unlock_irqrestore(&data->txlock, flags);
+
+ return rc;
+}
+
+static int tsi108_set_settings(struct net_device *dev, struct ethtool_cmd *cmd)
+{
+ struct tsi108_prv_data *data = netdev_priv(dev);
+ unsigned long flags;
+ int rc;
+
+ spin_lock_irqsave(&data->txlock, flags);
+ rc = mii_ethtool_sset(&data->mii_if, cmd);
+ spin_unlock_irqrestore(&data->txlock, flags);
+
+ return rc;
+}
+
static int tsi108_do_ioctl(struct net_device *dev, struct ifreq *rq, int cmd)
{
struct tsi108_prv_data *data = netdev_priv(dev);
+ if (!netif_running(dev))
+ return -EINVAL;
return generic_mii_ioctl(&data->mii_if, if_mii(rq), cmd, NULL);
}
+static const struct ethtool_ops tsi108_ethtool_ops = {
+ .get_link = ethtool_op_get_link,
+ .get_settings = tsi108_get_settings,
+ .set_settings = tsi108_set_settings,
+};
+
static int
tsi108_init_one(struct platform_device *pdev)
{
@@ -1589,6 +1624,7 @@ tsi108_init_one(struct platform_device *
dev->get_stats = tsi108_get_stats;
netif_napi_add(dev, &data->napi, tsi108_poll, 64);
dev->do_ioctl = tsi108_do_ioctl;
+ dev->ethtool_ops = &tsi108_ethtool_ops;
/* Apparently, the Linux networking code won't use scatter-gather
* if the hardware doesn't do checksums. However, it's faster
^ permalink raw reply
* [PATCH 4/5 v3] Tsi108_eth: fix link recovery after disconnect
From: Alex Bounine @ 2008-02-11 19:36 UTC (permalink / raw)
To: jgarzik, netdev; +Cc: linuxppc-dev, tie-fei.zang, jwboyer
Bug fix for tsi108_eth network driver.
This patch fixes a problem with link recovery after connection was lost.
Signed-off-by: Alexandre Bounine <alexandreb@tundra.com>
---
diff -pNur linux-2.6.24/drivers/net/tsi108_eth.c
linux-2.6.24-fix/drivers/net/tsi108_eth.c
--- linux-2.6.24/drivers/net/tsi108_eth.c 2008-02-06 16:16:00.000000000 -0500
+++ linux-2.6.24-fix/drivers/net/tsi108_eth.c 2008-02-06
16:57:41.000000000 -0500
@@ -338,22 +338,21 @@ static void tsi108_check_phy(struct net_
TSI_WRITE(TSI108_MAC_CFG2, mac_cfg2_reg);
TSI_WRITE(TSI108_EC_PORTCTRL, portctrl_reg);
+ }
- if (data->link_up == 0) {
- /* The manual says it can take 3-4 usecs for the speed change
- * to take effect.
- */
- udelay(5);
-
- spin_lock(&data->txlock);
- if (is_valid_ether_addr(dev->dev_addr) && data->txfree)
- netif_wake_queue(dev);
+ if (data->link_up == 0) {
+ /* The manual says it can take 3-4 usecs for the speed change
+ * to take effect.
+ */
+ udelay(5);
- data->link_up = 1;
- spin_unlock(&data->txlock);
- }
- }
+ spin_lock(&data->txlock);
+ if (is_valid_ether_addr(dev->dev_addr) && data->txfree)
+ netif_wake_queue(dev);
+ data->link_up = 1;
+ spin_unlock(&data->txlock);
+ }
} else {
if (data->link_up == 1) {
netif_stop_queue(dev);
@@ -1267,12 +1266,11 @@ static void tsi108_init_phy(struct net_d
* PHY_STAT register before the link up status bit is set.
*/
- data->link_up = 1;
+ data->link_up = 0;
while (!((phyval = tsi108_read_mii(data, MII_BMSR)) &
BMSR_LSTATUS)) {
if (i++ > (MII_READ_DELAY / 10)) {
- data->link_up = 0;
break;
}
spin_unlock_irqrestore(&phy_lock, flags);
^ permalink raw reply
* [PATCH 3/5 v3] Tsi108_eth: remove not needed code
From: Alex Bounine @ 2008-02-11 19:35 UTC (permalink / raw)
To: jgarzik, netdev; +Cc: linuxppc-dev, tie-fei.zang, jwboyer
Code clean-up for tsi108_eth network driver.
This patch removes not needed dummy read and the corresponding comment.
The PHY logic requires two reads from the status register to get
current link status. This is done correctly inside mii_check_media().
Signed-off-by: Alexandre Bounine <alexandreb@tundra.com>
---
diff -pNur linux-2.6.24/drivers/net/tsi108_eth.c
linux-2.6.24-fix/drivers/net/tsi108_eth.c
--- linux-2.6.24/drivers/net/tsi108_eth.c 2008-02-06 15:47:35.000000000 -0500
+++ linux-2.6.24-fix/drivers/net/tsi108_eth.c 2008-02-06
15:54:14.000000000 -0500
@@ -297,18 +297,11 @@ static void tsi108_check_phy(struct net_
u32 speed;
unsigned long flags;
- /* Do a dummy read, as for some reason the first read
- * after a link becomes up returns link down, even if
- * it's been a while since the link came up.
- */
-
spin_lock_irqsave(&phy_lock, flags);
if (!data->phy_ok)
goto out;
- tsi108_read_mii(data, MII_BMSR);
-
duplex = mii_check_media(&data->mii_if, netif_msg_link(data),
data->init_media);
data->init_media = 0;
^ 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