* Re: [PATCH] be2net: Adding support for 802.1ad (q-in-q mode)
From: David Miller @ 2009-07-23 17:01 UTC (permalink / raw)
To: kaber; +Cc: sarveshwarb, netdev
In-Reply-To: <4A6890C1.2000108@trash.net>
From: Patrick McHardy <kaber@trash.net>
Date: Thu, 23 Jul 2009 18:33:05 +0200
> David Miller wrote:
>>> Sarveshwar Bandi wrote:
>>>> The outer vlan is totally transparent to the host. It is used by the NIC
>>>> to demux packets across multiple pci network functions. Currently the
>>>> outer vlan tags are configured on the NIC by OEM provided utilities.
>>> I see. A proper changelog entry would have explained that and avoided
>>> all this confusion. Not that I think using another tool for this is a
>>> good solution, but no objections from a functional POV.
>>
>> Using OEM tools makes no sense, there should be something like an
>> ethtool interface for changing this setting and appropriate changes
>> to the common userland tools to provide access to them.
>>
>> I'm not putting this change in until there is common infrastructure
>> submitted to common tools to control this configuration.
>
> Thanks, thats my opinion as well. But I think we should handle
> Q-in-Q using the VLAN netlink API and iproute instead of ethtool
> for consistency.
That works for me too.
^ permalink raw reply
* Re: Kernel oops on setting sky2 interfaces down
From: Stephen Hemminger @ 2009-07-23 17:28 UTC (permalink / raw)
To: Rene Mayrhofer; +Cc: netdev, Richard Leitner
In-Reply-To: <4A65EC3F.4050400@gibraltar.at>
On Tue, 21 Jul 2009 18:26:39 +0200
Rene Mayrhofer <rene.mayrhofer@gibraltar.at> wrote:
> Hi everybody,
>
> [Please CC me in replies, I am not currently subscribed to this list.]
>
> I have a fully reproducible kernel oops in the sky2 module in kernel
> 2.6.28.10. The kernel is a vanilla 2.6.28.10 (and I can't switch to
> anything newer at this time because of missing squashfs-lzma support),
> patched with PaX, netfilter-layer7, squashfs (with LZMA), and IMQ. The
> base system is a Debian Lenny with some updates from testing/unstable.
>
> Whenever interfaces using the sky2 module (this box has 8 network
> interfaces in a 19" rack appliance) go down, the oops occurs:
>
You could try commenting out sky2_shutdown which does the Wol
power down stuff. Maybe changing setting of Wake On Lan would
help as well.
What happens if you take interface down 'ip link set eth0 down' (or ifconfig)?
There are several different register writes in the shutdown path.
You could add code to check if a particular access is disabling
the PCI buss with:
sky2_write(... som register...)
BUG_ON(sky2_read16(sky2->hw, B0_CTST) == 0xffff);
--
^ permalink raw reply
* Re: [Bugme-new] [Bug 13760] New: 2.6.30 kernel locks up with pppoe in back trace (regression)
From: Andrew Morton @ 2009-07-23 17:51 UTC (permalink / raw)
To: David Miller
Cc: for.poige+bugzilla.kernel.org, bugzilla-daemon, bugme-daemon,
netdev
In-Reply-To: <20090723.091523.180916751.davem@davemloft.net>
On Thu, 23 Jul 2009 09:15:23 -0700 (PDT) David Miller <davem@davemloft.net> wrote:
> From: Andrew Morton <akpm@linux-foundation.org>
> Date: Thu, 23 Jul 2009 00:01:00 -0700
>
> > Below is a ppp fix from 2.6.31, but it seems unlikely to fix your problem.
>
> Andrew, that change was reverted, it's a NOP in the current tree.
>
> There were various TTY layer fixups from Alan that could effect
> PPP and related drivers.
I wouldn't have thought that pppoe would be affected by tty changes?
As opposed to pppotty :)
^ permalink raw reply
* Re: [Bugme-new] [Bug 13760] New: 2.6.30 kernel locks up with pppoe in back trace (regression)
From: David Miller @ 2009-07-23 17:53 UTC (permalink / raw)
To: akpm; +Cc: for.poige+bugzilla.kernel.org, bugzilla-daemon, bugme-daemon,
netdev
In-Reply-To: <20090723105141.5272aee1.akpm@linux-foundation.org>
From: Andrew Morton <akpm@linux-foundation.org>
Date: Thu, 23 Jul 2009 10:51:41 -0700
> I wouldn't have thought that pppoe would be affected by tty changes?
>
> As opposed to pppotty :)
Good point. So it's unlikely any of the changes we're discussing
will influence this bug.
^ permalink raw reply
* Re: [PATCH v3 RESEND] net: Rework mdio-ofgpio driver to use of_mdio infrastructure
From: David Miller @ 2009-07-23 17:56 UTC (permalink / raw)
To: mware; +Cc: grant.likely, netdev, linuxppc-dev
In-Reply-To: <4A68477B.4090505@elphinstone.net>
From: Mark Ware <mware@elphinstone.net>
Date: Thu, 23 Jul 2009 21:20:27 +1000
> Changes to the fs_enet driver (aa73832c5a80d6c52c69b18af858d88fa595dd3c) cause kernel crashes when using the mdio-ofgpio driver.
>
> This patch replicates similar changes made to the fs_enet mii-bitbang drivers. It has been tested on a custom mpc8280 based board using an NFS mounted root.
>
> Signed-off-by: Mark Ware <mware@elphinstone.net>
> Acked-by: Grant Likely <grant.likely@secretlab.ca>
Applied.
^ permalink raw reply
* Re: [PATCH net-next-2.6] bnx2: Update vlan_features
From: David Miller @ 2009-07-23 17:59 UTC (permalink / raw)
To: eric.dumazet; +Cc: ogerlitz, kaber, fubar, netdev, eilong, mchan
In-Reply-To: <4A685122.3090300@gmail.com>
From: Eric Dumazet <eric.dumazet@gmail.com>
Date: Thu, 23 Jul 2009 14:01:38 +0200
> [PATCH net-next-2.6] bnx2: Update vlan_features
>
> In order to get full use of some advanced features of BNX2, we now need to
> fill dev->vlan_features.
>
> Patch successfully tested with vlan devices built on top of bonding.
> (bond0 : one bnx2 slave, one tg3 slave (not yet vlan_features enabled)
>
> Signed-off-by: Eric Dumazet <eric.dumazet@gmail.com>
Can I get some Broadcom ACKs for this?
Thanks.
^ permalink raw reply
* Re: [net-2.6 PATCH 1/2] ixgbe: Enable FCoE offload when DCB is enabled for 82599
From: David Miller @ 2009-07-23 18:06 UTC (permalink / raw)
To: jeffrey.t.kirsher; +Cc: netdev, gospo, yi.zou, peter.p.waskiewicz.jr
In-Reply-To: <20090723000705.27299.19299.stgit@localhost.localdomain>
From: Jeff Kirsher <jeffrey.t.kirsher@intel.com>
Date: Wed, 22 Jul 2009 17:07:12 -0700
> From: Yi Zou <yi.zou@intel.com>
>
> Currently, FCoE offload feature is turned on when the kernel config has
> CONFIG_FCOE or CONFIG_FCOE_MODULE set. However, we really want to turn
> FCoE offload on when there is FCoE traffic passing and turn it off when
> it's just LAN traffic. Since FCoE depends on a lossless network provided
> by DCB, this allows us to have FCoE turned on/off when user turns on DCB
> using dcbtool.
>
> Signed-off-by: Yi Zou <yi.zou@intel.com>
> Acked-by: Peter P Waskiewicz Jr <peter.p.waskiewicz.jr@intel.com>
> Signed-off-by: Jeff Kirsher <jeffrey.t.kirsher@intel.com>
Applied.
^ permalink raw reply
* Re: [net-2.6 PATCH 2/2] ixgbe: Don't priority tag control frames in DCB mode
From: David Miller @ 2009-07-23 18:06 UTC (permalink / raw)
To: jeffrey.t.kirsher; +Cc: netdev, gospo, lucy.liu, peter.p.waskiewicz.jr
In-Reply-To: <20090723000733.27299.56014.stgit@localhost.localdomain>
From: Jeff Kirsher <jeffrey.t.kirsher@intel.com>
Date: Wed, 22 Jul 2009 17:07:33 -0700
> From: Lucy Liu <lucy.liu@intel.com>
>
> Certain types of control packets (LLDP, LACP, etc.) are not supposed to have a
> priority tag or vlan tag inserted. Ixgbe driver is currently priority
> tagging everything (if packet is not on a VLAN interface).
>
> This patch modifies DCB mode, so that packets marked with skb priority
> TC_PRIO_CONTROL are not priority tagged. It also transmits these packets on
> the highest priority traffic class.
> Programs (like dcbd) can set the skb priority using a socket option. Or, a tc
> filter can be configured to set the priority value. Using the value
> TC_PRIO_CONTROL (7) has the benefit that it is already defined in the kernel,
> and the bonding LACP code already sets the skb->priority field to this value.
>
> Signed-off-by: Lucy Liu <lucy.liu@intel.com>
> Acked-by: Peter P Waskiewicz Jr <peter.p.waskiewicz.jr@intel.com>
> Signed-off-by: Jeff Kirsher <jeffrey.t.kirsher@intel.com>
Applied.
^ permalink raw reply
* Re: [PATCH] igb/e1000e/e1000/e100: make wol usable
From: David Miller @ 2009-07-23 18:06 UTC (permalink / raw)
To: peter.p.waskiewicz.jr
Cc: andy, alexander.duyck, john.ronciak, netdev, jeffrey.t.kirsher,
jesse.brandeburg, bruce.w.allan, stable
In-Reply-To: <Pine.WNT.4.64.0907221642110.9900@ppwaskie-MOBL2.amr.corp.intel.com>
From: "Waskiewicz Jr, Peter P" <peter.p.waskiewicz.jr@intel.com>
Date: Wed, 22 Jul 2009 16:43:03 -0700 (Pacific Daylight Time)
> On Wed, 22 Jul 2009, Andy Gospodarek wrote:
>
>> [PATCH] ixgbe: remove unnecessary call to device_init_wakeup
>>
>> Calls to device_init_wakeup should not be necessary in drivers that use
>> device_set_wakeup_enable since pci_pm_init will set the can_wakeup flag
>> for the device when initialized.
>>
>> I can't test this since I don't have any of the 82599 KX4 interfaces
>> (the only ones capable of WOL), but I did instrument ixgbe_probe and
>> know that can_wakeup=1 when device_init_wakeup is removed.
>>
>> Signed-off-by: Andy Gospodarek <andy@greyhouse.net>
...
> Works just fine on two different 82599 mezz cards that support WoL.
> Thanks Andy for finding and fixing.
>
> Acked-by: Peter P Waskiewicz Jr <peter.p.waskiewicz.jr@intel.com>
Applied, thanks.
^ permalink raw reply
* Re: [Open-FCoE] [net-next-2.6 PATCH 5/5] fcoe: Use NETIF_F_FCOE_MTU flag to set up max frame size (lport->mfs)
From: Robert Love @ 2009-07-23 18:27 UTC (permalink / raw)
To: davem, Jeff Kirsher; +Cc: linux-scsi, netdev, gospo, devel
In-Reply-To: <20090722232956.26937.24429.stgit@localhost.localdomain>
On Wed, 2009-07-22 at 16:29 -0700, Jeff Kirsher wrote:
> From: Yi Zou <yi.zou@intel.com>
>
> Add a define of FCOE_MTU as 2158 bytes and use FCOE_MTU when the LLD is found
> to support NETIF_F_FCOE_MTU. The lport->mfs is then calculated out of the
> 2158 FCOE_MTU. Otherwise, we stick with the netdev->mtu, i.e., LAN MTU. Also,
> change the notification on NETDEV_CHANGEMTU event to bypass changing mfs when
> LAN MTU is changed if NETIF_F_FCOE_MTU is supported.
>
> Signed-off-by: Yi Zou <yi.zou@intel.com>
> Signed-off-by: Jeff Kirsher <jeffrey.t.kirsher@intel.com>
> ---
Hi Dave,
Please don't apply this patch to net-next. The other 4 patches in this
series should be fine without it. If this patch is applied to net-next
it means that most/all of the other fcoe features (that will go through
linux-scsi) become dependent on this patch.
I was hoping to push the other fcoe features as-is and then push this
patch through linux-scsi after the other 4 patches in this series had
been merged by you.
Thanks, //Rob
^ permalink raw reply
* Re: [Open-FCoE] [net-next-2.6 PATCH 5/5] fcoe: Use NETIF_F_FCOE_MTU flag to set up max frame size (lport->mfs)
From: David Miller @ 2009-07-23 18:40 UTC (permalink / raw)
To: robert.w.love; +Cc: jeffrey.t.kirsher, linux-scsi, netdev, gospo, devel
In-Reply-To: <1248373648.23392.24.camel@fritz>
From: Robert Love <robert.w.love@intel.com>
Date: Thu, 23 Jul 2009 11:27:28 -0700
> Please don't apply this patch to net-next. The other 4 patches in this
> series should be fine without it. If this patch is applied to net-next
> it means that most/all of the other fcoe features (that will go through
> linux-scsi) become dependent on this patch.
>
> I was hoping to push the other fcoe features as-is and then push this
> patch through linux-scsi after the other 4 patches in this series had
> been merged by you.
Sure, I was just reading over this stuff.
But on the other hand, linux-scsi will be dependant upon net-next-2.6
because this patch here uses flags that will only be added there.
Therefore there has to be a dependency in one direction or another,
the question is which one works better for you FCOE guys.
The best thing to do in these situations is usually to create the
dependency and merge into the tree where most of the subsystem
specific bits (and thus developer ACKs) are needed. And then
just occaisionally go and ask the other subsystem guys for ACKs
when necessary.
^ permalink raw reply
* Re: [net-next 6/10] bnx2x: Update vlan_features
From: Jay Vosburgh @ 2009-07-23 18:47 UTC (permalink / raw)
To: Or Gerlitz; +Cc: Patrick McHardy, eilong, David Miller, netdev, Eric Dumazet
In-Reply-To: <4A6849D6.4050200@voltaire.com>
Or Gerlitz <ogerlitz@voltaire.com> wrote:
>okay, understood. So the patches to bnx2 and bnx2x can/should be made
>simpler and the patch to bonding has to change and include a call to
>netdev_features_change(), Jay, I assume you prefer to do that, if not, let
>me know and I will.
I'm working on the new bonding patch; adding the
netdev_features_change call has locking implications, so the calls to
bond_compute_features have to move around a bit.
Should have something later today.
-J
---
-Jay Vosburgh, IBM Linux Technology Center, fubar@us.ibm.com
^ permalink raw reply
* Re: [net-next-2.6 PATCH 5/5] fcoe: Use NETIF_F_FCOE_MTU flag to set up max frame size (lport->mfs)
From: Robert Love @ 2009-07-23 18:48 UTC (permalink / raw)
To: David Miller, James.Bottomley-d9PhHud1JfjCXq6kfMZ53/egYHeGw8Jk
Cc: netdev-u79uwXL29TY76Z2rM5mHXA, gospo-H+wXaHxf7aLQT0dZR+AlfA,
devel-s9riP+hp16TNLxjTenLetw, linux-scsi-u79uwXL29TY76Z2rM5mHXA,
jeffrey.t.kirsher-ral2JQCrhuEAvxtiuMwx3w
In-Reply-To: <20090723.114002.51085260.davem-fT/PcQaiUtIeIZ0/mPfg9Q@public.gmane.org>
On Thu, 2009-07-23 at 11:40 -0700, David Miller wrote:
> From: Robert Love <robert.w.love-ral2JQCrhuEAvxtiuMwx3w@public.gmane.org>
> Date: Thu, 23 Jul 2009 11:27:28 -0700
>
> > Please don't apply this patch to net-next. The other 4 patches in this
> > series should be fine without it. If this patch is applied to net-next
> > it means that most/all of the other fcoe features (that will go through
> > linux-scsi) become dependent on this patch.
> >
> > I was hoping to push the other fcoe features as-is and then push this
> > patch through linux-scsi after the other 4 patches in this series had
> > been merged by you.
>
> Sure, I was just reading over this stuff.
>
> But on the other hand, linux-scsi will be dependant upon net-next-2.6
> because this patch here uses flags that will only be added there.
>
Yes, absolutely, but it's only this small patch that creates the
dependency. I figured that all of the other fcoe patches could go into
James' scsi-misc tree and get merged first. Then this one could go into
his scsi-post-merge tree and depend on net-next.
It's really up to you and James, I just thought that would be easier.
> Therefore there has to be a dependency in one direction or another,
> the question is which one works better for you FCOE guys.
>
> The best thing to do in these situations is usually to create the
> dependency and merge into the tree where most of the subsystem
> specific bits (and thus developer ACKs) are needed. And then
> just occaisionally go and ask the other subsystem guys for ACKs
> when necessary.
>
> _______________________________________________
> devel mailing list
> devel-s9riP+hp16TNLxjTenLetw@public.gmane.org
> http://www.open-fcoe.org/mailman/listinfo/devel
^ permalink raw reply
* Re: [Bugme-new] [Bug 13760] New: 2.6.30 kernel locks up with pppoe in back trace (regression)
From: Jarek Poplawski @ 2009-07-23 19:11 UTC (permalink / raw)
To: David Miller
Cc: akpm, for.poige+bugzilla.kernel.org, bugzilla-daemon,
bugme-daemon, netdev
In-Reply-To: <20090723.105344.244636270.davem@davemloft.net>
David Miller wrote, On 07/23/2009 07:53 PM:
> From: Andrew Morton <akpm@linux-foundation.org>
> Date: Thu, 23 Jul 2009 10:51:41 -0700
>
>> I wouldn't have thought that pppoe would be affected by tty changes?
>>
>> As opposed to pppotty :)
>
> Good point. So it's unlikely any of the changes we're discussing
> will influence this bug.
Here is a link showing around pppoe problem quite similar to
the one fixed later in pty.c by Alan Cox, so IMHO the current
2.6.31-rc is worth trying.
From: Dave Young <hidave.darkstar@gmail.com>
Subject: BUG: sleeping function called from invalid context at
kernel/mutex.c:280
Date: Fri, 19 Jun 2009 10:36:13 +0800
http://permalink.gmane.org/gmane.linux.network/131166
Jarek P.
^ permalink raw reply
* Re: md5 on listening sockets
From: John Dykstra @ 2009-07-23 19:16 UTC (permalink / raw)
To: Martin Djernæs; +Cc: netdev
In-Reply-To: <aa9682190907230738y23636cc5yd8b4e7a854f7b59c@mail.gmail.com>
On Thu, 2009-07-23 at 16:38 +0200, Martin Djernæs wrote:
> I've been looking at using the md5 keys on a listening socket as one
> means of restricting access to the socket.
MD5 authentication is typically used for BGP sessions. It is not a
particularly strong authentication mechanism, as discussed in RFC 4278,
and there are several better options available as long as you don't have
to be compatible with BGP peers.
> When I specify an md5 key
> (with or without a peer ip address in the option) any tcp connect from
> another IP address will be accepted by this connection if the source
> IP is not found in the "md5sig->keys4" array.
The current behavior is consistent with the way MD5 authentication works
on OpenBSD, and perhaps other BSDs. This behavior is expected by open
source routing applications.
I believe the intent is that the BGP well-known port must be able to
accept connections from both authenticated and non-authenticated peers.
It is up to the application to filter connections based on the address
of the connecting peer.
I agree that this behavior would be unfortunate for a general-purpose
authentication mechanism, but that is not what TCP MD5 authentication
is.
--
John Dykstra
voice: +1 651 484-1098 Yahoo IM: jdykstra72
LinkedIn: http://www.linkedin.com/in/JohnDykstra
Blog: http://johndykstra.blogspot.com/
^ permalink raw reply
* Re: [Bugme-new] [Bug 13791] New: tg3 transmit timeout kills interface
From: Andrew Morton @ 2009-07-23 20:50 UTC (permalink / raw)
To: netdev; +Cc: bugzilla-daemon, bugme-daemon, mcarlson, mchan, kernel
In-Reply-To: <bug-13791-10286@http.bugzilla.kernel.org/>
(switched to email. Please respond via emailed reply-to-all, not via the
bugzilla web interface).
On Fri, 17 Jul 2009 13:49:15 GMT
bugzilla-daemon@bugzilla.kernel.org wrote:
> http://bugzilla.kernel.org/show_bug.cgi?id=13791
>
> Summary: tg3 transmit timeout kills interface
> Product: Drivers
> Version: 2.5
> Kernel Version: 2.6.29.5-191.fc11.x86_64
> Platform: All
> OS/Version: Linux
> Tree: Fedora
> Status: NEW
> Severity: normal
> Priority: P1
> Component: Network
> AssignedTo: drivers_network@kernel-bugs.osdl.org
> ReportedBy: kernel@mattgillen.net
> Regression: No
>
>
> Created an attachment (id=22389)
> --> (http://bugzilla.kernel.org/attachment.cgi?id=22389)
> Kernel messages dumped to /var/log/messages
>
> Overview:
> Starting with Fedora 10, and continuing in Fedora 11, I started getting the
> kernel dump in /var/log/messages (see attachment) at least once a day,
> regardless of network load on the machine. After this message, the network
> interface no longer works, and I have to reboot. I don't recall ever having
> this issue with Fedora 8/9 (I ran each of those for roughly 7 months).
>
> It looks like Fedora 10 shipped with kernel 2.6.27, so that's roughly when I
> started seeing this issue.
>
> Steps to Reproduce: Leave my laptop up and plugged into a wired network for 12
> hours or so.
>
> Additional Information:
> I have a Dell Latitude D630 with a Broadcom ethernet card; as reported by
> lspci:
> 09:00.0 Ethernet controller: Broadcom Corporation NetXtreme BCM5755M Gigabit
> Ethernet PCI Express (rev 02)
>
Thanks, I'll mark this as a regression.
The nvidia driver tainted the kernel. People might want to know
whether the problem can be reproduced in a kernel which never had the
nvidia driver loaded.
Here's the log:
Jul 15 14:38:58 localhost kernel: ------------[ cut here ]------------
Jul 15 14:38:58 localhost kernel: WARNING: at net/sched/sch_generic.c:226 dev_watchdog+0xcf/0x12c() (Tainted: P )
Jul 15 14:38:58 localhost kernel: Hardware name: Latitude D630
Jul 15 14:38:58 localhost kernel: NETDEV WATCHDOG: eth0 (tg3): transmit timed out
Jul 15 14:38:58 localhost kernel: Modules linked in: ipt_MASQUERADE iptable_nat nf_nat bridge stp llc bnep sco l2cap bluetooth autofs4 sunrpc ip6t_REJECT ip6t_ipv6header nf_conntrack_ipv6 ip6table_filter ip6_tables ipv6 cpufreq_ondemand acpi_cpufreq freq_table fuse dm_multipath kvm_intel kvm uinput nvidia(P) arc4 ecb snd_hda_codec_idt iwlagn snd_hda_intel snd_hda_codec iwlcore snd_hwdep firewire_ohci snd_pcm lib80211 video dell_laptop mac80211 firewire_core iTCO_wdt tg3 yenta_socket snd_timer i2c_i801 wmi iTCO_vendor_support i2c_core rsrc_nonstatic snd soundcore cfg80211 snd_page_alloc crc_itu_t output dcdbas pcspkr joydev [last unloaded: microcode]
Jul 15 14:38:58 localhost kernel: Pid: 0, comm: swapper Tainted: P 2.6.29.5-191.fc11.x86_64 #1
Jul 15 14:38:58 localhost kernel: Call Trace:
Jul 15 14:38:58 localhost kernel: <IRQ> [<ffffffff8104883f>] warn_slowpath+0xbc/0xf0
Jul 15 14:38:58 localhost kernel: [<ffffffff813abe44>] ? _spin_unlock_irqrestore+0x2c/0x42
Jul 15 14:38:58 localhost kernel: [<ffffffff81039604>] ? task_rq_unlock+0x11/0x13
Jul 15 14:38:58 localhost kernel: [<ffffffff8104056b>] ? try_to_wake_up+0x25b/0x26d
Jul 15 14:38:58 localhost kernel: [<ffffffff8104058f>] ? default_wake_function+0x12/0x14
Jul 15 14:38:58 localhost kernel: [<ffffffff8105c8ed>] ? autoremove_wake_function+0x16/0x39
Jul 15 14:38:58 localhost kernel: [<ffffffff810379ac>] ? __wake_up_common+0x4e/0x84
Jul 15 14:38:58 localhost kernel: [<ffffffff813abe44>] ? _spin_unlock_irqrestore+0x2c/0x42
Jul 15 14:38:58 localhost kernel: [<ffffffff813abbfa>] ? _spin_lock+0xe/0x11
Jul 15 14:38:58 localhost kernel: [<ffffffff8132196d>] dev_watchdog+0xcf/0x12c
Jul 15 14:38:58 localhost kernel: [<ffffffff810596a7>] ? __queue_work+0x3a/0x42
Jul 15 14:38:58 localhost kernel: [<ffffffff813abf5f>] ? _spin_lock_irq+0x27/0x2a
Jul 15 14:38:58 localhost kernel: [<ffffffff81051e67>] run_timer_softirq+0x19e/0x224
Jul 15 14:38:58 localhost kernel: [<ffffffff81063094>] ? getnstimeofday+0x5f/0xb3
Jul 15 14:38:58 localhost kernel: [<ffffffff8104df6f>] __do_softirq+0x94/0x155
Jul 15 14:38:58 localhost kernel: [<ffffffff8101274c>] call_softirq+0x1c/0x30
Jul 15 14:38:58 localhost kernel: [<ffffffff810138ce>] do_softirq+0x52/0xb9
Jul 15 14:38:58 localhost kernel: [<ffffffff8104db92>] irq_exit+0x53/0x90
Jul 15 14:38:58 localhost kernel: [<ffffffff81022464>] smp_apic_timer_interrupt+0x8e/0xa7
Jul 15 14:38:58 localhost kernel: [<ffffffff81012123>] apic_timer_interrupt+0x13/0x20
Jul 15 14:38:58 localhost kernel: <EOI> [<ffffffff812ed312>] ? menu_reflect+0x2a/0x6e
Jul 15 14:38:58 localhost kernel: [<ffffffff812ec73f>] ? cpuidle_idle_call+0xbd/0xc2
Jul 15 14:38:58 localhost kernel: [<ffffffff810102a1>] ? cpu_idle+0x68/0xb3
Jul 15 14:38:58 localhost kernel: [<ffffffff813a5e3c>] ? start_secondary+0x199/0x19e
Jul 15 14:38:58 localhost kernel: ---[ end trace ed7f6377ede4163b ]---
Jul 15 14:38:58 localhost kernel: tg3: eth0: transmit timed out, resetting
Jul 15 14:38:58 localhost kernel: tg3: DEBUG: MAC_TX_STATUS[0000000b] MAC_RX_STATUS[00000000]
Jul 15 14:38:58 localhost kernel: tg3: DEBUG: RDMAC_STATUS[00000010] WDMAC_STATUS[00000000]
Jul 15 14:38:58 localhost kernel: tg3: tg3_stop_block timed out, ofs=2c00 enable_bit=2
Jul 15 14:38:58 localhost kernel: tg3: tg3_stop_block timed out, ofs=4800 enable_bit=2
Jul 15 14:38:58 localhost kernel: tg3: eth0: Link is down.
Jul 15 14:38:58 localhost NetworkManager: <info> (eth0): carrier now OFF (device state 8)
Jul 15 14:38:58 localhost NetworkManager: <info> (eth0): device state change: 8 -> 2
Jul 15 14:38:58 localhost NetworkManager: <info> (eth0): deactivating device (reason: 40).
^ permalink raw reply
* Claimed reduction in ARP table size when ARPD is configured
From: Jeff Haran @ 2009-07-23 21:23 UTC (permalink / raw)
To: netdev
Johathan Layes,
Your name shows up in the list of maintainers for ARPD, so I am asking you my question. If this is inappropriate, my apologies, please let me know who I could forward the question to.
net/ipv4/Kconfig contains the following text about config ARPD:
"If you say Y here, the kernel's internal ARP cache will never grow to more than 256 entries"
Yet, try as I might, I cannot see where in the kernel sources any #ifdef CONFIG_ARPD'ed code would actually change the maximum size of the kernel resident ARP cache.
Is this statement about the maximum internal ARP cache size when ARPD is configured no longer accurate or am I missing something?
If kernel code did at one time reduce the maximum internal ARP cache size, what is the latest version in which it did?
BTW, I know ARPD is described as obsolete, but we have a use for the notifications it provides that has nothing to do with user space ARP daemons and if it goes away in the future we will deal with it then.
Please response to my email directly, as I do not subscribe to netdev.
Thanks,
Jeffrey Haran
Brocade Communications
^ permalink raw reply
* Re: [Bugme-new] [Bug 13803] New: hso: Tx timed out.
From: Andrew Morton @ 2009-07-23 22:43 UTC (permalink / raw)
To: linux-usb, netdev; +Cc: bugzilla-daemon, bugme-daemon, Jan Dumon, fabo
In-Reply-To: <bug-13803-10286@http.bugzilla.kernel.org/>
(switched to email. Please respond via emailed reply-to-all, not via the
bugzilla web interface).
(argh at the wordwrapping - I'm trying to get bugzilla fixed but
appatently it's tricky).
On Mon, 20 Jul 2009 15:02:09 GMT
bugzilla-daemon@bugzilla.kernel.org wrote:
> http://bugzilla.kernel.org/show_bug.cgi?id=13803
>
> Summary: hso: Tx timed out.
> Product: Drivers
> Version: 2.5
> Kernel Version: 2.6.30
> Platform: All
> OS/Version: Linux
> Tree: Mainline
> Status: NEW
> Severity: normal
> Priority: P1
> Component: USB
> AssignedTo: greg@kroah.com
> ReportedBy: fabo@debian.org
> Regression: No
>
>
> I've got the following issue using Option GlobeTrotter GTM382 (device id
> 0af0:7601) with 2.6.29 and 2.6.30 kernels:
> Jul 20 15:35:18 os kernel: [ 1722.322633] WARNING: at
> /tmp/buildd/linux-2.6-2.6.30/debian/build/source_i386_none/net/sched/sch_generic.c:226
> dev_watchdog+0xa8/0x135()
> Jul 20 15:35:18 os kernel: [ 1722.326745] Hardware name: No System Name
> Jul 20 15:35:18 os kernel: [ 1722.330797] NETDEV WATCHDOG: hso0 (hso): transmit
> timed out
> Jul 20 15:35:18 os kernel: [ 1722.333567] Modules linked in: nfsd nfs lockd
> fscache nfs_acl auth_rpcgss sunrpc hso rfkill snd_pcsp snd_pcm psmouse
> snd_timer via686a snd evdev serio_raw soundcore snd_page_alloc ipw2200
> i2c_viapro parport_pc i2c_core parport shpchp efficeon_agp libipw pci_hotplug
> lib80211 agpgart usb_storage uhci_hcd sd_mod crc_t10dif squashfs loop aufs
> exportfs ext3 jbd mbcache ide_gd_mod ata_generic libata scsi_mod ohci_hcd
> ehci_hcd usbcore e100 mii via82cxxx thermal_sys ide_pci_generic ide_core
> Jul 20 15:35:18 os kernel: [ 1722.442859] Pid: 0, comm: swapper Not tainted
> 2.6.30-itlabs.1-686 #1
> Jul 20 15:35:18 os kernel: [ 1722.444389] Call Trace:
> Jul 20 15:35:18 os kernel: [ 1722.446154] [<c012703c>] ?
> warn_slowpath_common+0x5e/0x8a
> Jul 20 15:35:18 os kernel: [ 1722.447747] [<c029efd0>] ?
> dev_watchdog+0x0/0x135
> Jul 20 15:35:18 os kernel: [ 1722.449308] [<c012709a>] ?
> warn_slowpath_fmt+0x26/0x2a
> Jul 20 15:35:18 os kernel: [ 1722.451439] [<c029f078>] ?
> dev_watchdog+0xa8/0x135
> Jul 20 15:35:18 os kernel: [ 1722.453260] [<c0133da1>] ? insert_work+0x71/0x78
> Jul 20 15:35:18 os kernel: [ 1722.454854] [<c01343b9>] ?
> delayed_work_timer_fn+0x0/0x28
> Jul 20 15:35:18 os kernel: [ 1722.456769] [<c012e3f3>] ?
> run_timer_softirq+0x13d/0x19d
> Jul 20 15:35:18 os kernel: [ 1722.458617] [<c029efd0>] ?
> dev_watchdog+0x0/0x135
> Jul 20 15:35:18 os kernel: [ 1722.460382] [<c012b137>] ?
> __do_softirq+0x8e/0x135
> Jul 20 15:35:18 os kernel: [ 1722.461956] [<c012b20c>] ? do_softirq+0x2e/0x38
> Jul 20 15:35:18 os kernel: [ 1722.463503] [<c012b2ef>] ? irq_exit+0x26/0x53
> Jul 20 15:35:18 os kernel: [ 1722.465293] [<c01049ea>] ? do_IRQ+0x65/0x76
> Jul 20 15:35:18 os kernel: [ 1722.467446] [<c01036c9>] ?
> common_interrupt+0x29/0x30
> Jul 20 15:35:18 os kernel: [ 1722.470343] [<c011642c>] ?
> native_safe_halt+0x2/0x3
> Jul 20 15:35:18 os kernel: [ 1722.472337] [<c010895e>] ?
> default_idle+0x41/0x6a
> Jul 20 15:35:18 os kernel: [ 1722.473985] [<c010239a>] ? cpu_idle+0x46/0x60
> Jul 20 15:35:18 os kernel: [ 1722.475527] [<c044476d>] ?
> start_kernel+0x2c2/0x2c5
> Jul 20 15:35:18 os kernel: [ 1722.477061] ---[ end trace 489bf763e8487f0a ]---
> Jul 20 15:35:18 os kernel: [ 1722.478618] net hso0: Tx timed out.
> Jul 20 15:35:38 os kernel: [ 1742.321537] net hso0: Tx timed out.
> Jul 20 15:35:58 os kernel: [ 1762.325396] net hso0: Tx timed out.
> Jul 20 15:36:18 os kernel: [ 1782.329539] net hso0: Tx timed out.
> Jul 20 15:36:38 os kernel: [ 1802.332445] net hso0: Tx timed out.
> Jul 20 15:36:58 os kernel: [ 1822.336094] net hso0: Tx timed out.
> Jul 20 15:37:18 os kernel: [ 1842.339743] net hso0: Tx timed out.
> Jul 20 15:37:38 os kernel: [ 1862.343416] net hso0: Tx timed out.
> Jul 20 15:37:58 os kernel: [ 1882.347041] net hso0: Tx timed out.
> etc...
^ permalink raw reply
* Re: [1/4 v2] Remove unused zero-copy code from velocity NIC driver.
From: David Miller @ 2009-07-23 22:58 UTC (permalink / raw)
To: davej; +Cc: netdev
In-Reply-To: <20090721.123322.118453668.davem@davemloft.net>
From: David Miller <davem@davemloft.net>
Date: Tue, 21 Jul 2009 12:33:22 -0700 (PDT)
> Ok, all applied to net-next-2.6, thanks.
Ok, now we have a stinking pile of poo situation when one tries to
compile the velocity driver without CONFIG_PM defined.
First we hit:
drivers/net/via-velocity.c: In function ‘velocity_init_module’:
drivers/net/via-velocity.c:3303: error: implicit declaration of function ‘velocity_register_notifier’
drivers/net/via-velocity.c:3306: error: implicit declaration of function ‘velocity_unregister_notifier’
Because the whole CONFIG_PM + CONFIG_INET ifdeffery around these functions
was missed up. Simple enough to fix, but then we get:
drivers/net/via-velocity.c:2957: warning: ‘velocity_suspend’ defined but not used
drivers/net/via-velocity.c:3026: warning: ‘velocity_resume’ defined but not used
Fine, let's ifdef protect these two functions with CONFIG_PM:
drivers/net/via-velocity.c:2853: warning: ‘velocity_set_wol’ defined but not used
drivers/net/via-velocity.c:2939: warning: ‘velocity_save_context’ defined but not used
drivers/net/via-velocity.c:3001: warning: ‘velocity_restore_context’ defined but not used
And at this point I really give up Dave. This whole thing to move
functions around to avoid forward decls has created a worse problem
than it solved.
Unless you can fix this, like, immediately. I want to revert.
This is keeping me from pulling more work into my net-next-2.6
tree.
^ permalink raw reply
* Re: [PATCH net-next-2.6] bnx2: Update vlan_features
From: Michael Chan @ 2009-07-24 0:12 UTC (permalink / raw)
To: David Miller
Cc: eric.dumazet@gmail.com, ogerlitz@voltaire.com, kaber@trash.net,
fubar@us.ibm.com, netdev@vger.kernel.org, Eilon Greenstein
In-Reply-To: <20090723.105932.249439810.davem@davemloft.net>
On Thu, 2009-07-23 at 10:59 -0700, David Miller wrote:
> From: Eric Dumazet <eric.dumazet@gmail.com>
> Date: Thu, 23 Jul 2009 14:01:38 +0200
>
> > [PATCH net-next-2.6] bnx2: Update vlan_features
> >
> > In order to get full use of some advanced features of BNX2, we now need to
> > fill dev->vlan_features.
> >
> > Patch successfully tested with vlan devices built on top of bonding.
> > (bond0 : one bnx2 slave, one tg3 slave (not yet vlan_features enabled)
> >
> > Signed-off-by: Eric Dumazet <eric.dumazet@gmail.com>
>
> Can I get some Broadcom ACKs for this?
>
I've reviewed and tested Eric's 2nd patch. Thanks.
Acked-by: Michael Chan <mchan@broadcom.com>
^ permalink raw reply
* Re: [1/4 v2] Remove unused zero-copy code from velocity NIC driver.
From: Dave Jones @ 2009-07-24 0:44 UTC (permalink / raw)
To: David Miller; +Cc: netdev
In-Reply-To: <20090723.155855.108555685.davem@davemloft.net>
On Thu, Jul 23, 2009 at 03:58:55PM -0700, David Miller wrote:
> From: David Miller <davem@davemloft.net>
> Date: Tue, 21 Jul 2009 12:33:22 -0700 (PDT)
>
> > Ok, all applied to net-next-2.6, thanks.
>
> Ok, now we have a stinking pile of poo situation when one tries to
> compile the velocity driver without CONFIG_PM defined.
>
> First we hit:
>
> drivers/net/via-velocity.c: In function ‘velocity_init_module’:
> drivers/net/via-velocity.c:3303: error: implicit declaration of function ‘velocity_register_notifier’
> drivers/net/via-velocity.c:3306: error: implicit declaration of function ‘velocity_unregister_notifier’
>
> Because the whole CONFIG_PM + CONFIG_INET ifdeffery around these functions
> was missed up. Simple enough to fix, but then we get:
>
> drivers/net/via-velocity.c:2957: warning: ‘velocity_suspend’ defined but not used
> drivers/net/via-velocity.c:3026: warning: ‘velocity_resume’ defined but not used
>
> Fine, let's ifdef protect these two functions with CONFIG_PM:
>
> drivers/net/via-velocity.c:2853: warning: ‘velocity_set_wol’ defined but not used
> drivers/net/via-velocity.c:2939: warning: ‘velocity_save_context’ defined but not used
> drivers/net/via-velocity.c:3001: warning: ‘velocity_restore_context’ defined but not used
>
> And at this point I really give up Dave. This whole thing to move
> functions around to avoid forward decls has created a worse problem
> than it solved.
>
> Unless you can fix this, like, immediately. I want to revert.
>
> This is keeping me from pulling more work into my net-next-2.6
> tree.
apologies.. This should fix it..
Dave
--
Previous changes broke compilation with CONFIG_PM disabled.
This widens the ifdefs to cover the functions that only get called
within the suspend/resume routines.
Signed-off-by: Dave Jones <davej@redhat.com>
diff --git a/drivers/net/via-velocity.c b/drivers/net/via-velocity.c
index b4bd1d3..47be41a 100644
--- a/drivers/net/via-velocity.c
+++ b/drivers/net/via-velocity.c
@@ -2805,6 +2805,7 @@ err_free_dev:
}
+#ifdef CONFIG_PM
/**
* wol_calc_crc - WOL CRC
* @pattern: data pattern
@@ -2952,7 +2953,6 @@ static void velocity_save_context(struct velocity_info *vptr, struct velocity_co
}
-
static int velocity_suspend(struct pci_dev *pdev, pm_message_t state)
{
struct net_device *dev = pci_get_drvdata(pdev);
@@ -3056,7 +3056,7 @@ static int velocity_resume(struct pci_dev *pdev)
return 0;
}
-
+#endif
/*
* Definition for our device driver. The PCI layer interface
@@ -3239,7 +3239,6 @@ static const struct ethtool_ops velocity_ethtool_ops = {
};
#ifdef CONFIG_PM
-
#ifdef CONFIG_INET
static int velocity_netdev_event(struct notifier_block *nb, unsigned long notification, void *ptr)
{
@@ -3263,6 +3262,7 @@ static int velocity_netdev_event(struct notifier_block *nb, unsigned long notifi
return NOTIFY_DONE;
}
#endif /* CONFIG_INET */
+#endif /* CONFIG_PM */
#if defined(CONFIG_PM) && defined(CONFIG_INET)
static struct notifier_block velocity_inetaddr_notifier = {
@@ -3286,8 +3286,6 @@ static void velocity_unregister_notifier(void)
#endif /* defined(CONFIG_PM) && defined(CONFIG_INET) */
-#endif /* CONFIG_PM */
-
/**
* velocity_init_module - load time function
*
^ permalink raw reply related
* Re: [1/4 v2] Remove unused zero-copy code from velocity NIC driver.
From: David Miller @ 2009-07-24 2:02 UTC (permalink / raw)
To: davej; +Cc: netdev
In-Reply-To: <20090724004449.GA16422@redhat.com>
From: Dave Jones <davej@redhat.com>
Date: Thu, 23 Jul 2009 20:44:49 -0400
> Previous changes broke compilation with CONFIG_PM disabled.
> This widens the ifdefs to cover the functions that only get called
> within the suspend/resume routines.
>
> Signed-off-by: Dave Jones <davej@redhat.com>
Applied, thanks Dave.
^ permalink raw reply
* Re: [PATCH] IPVS: Add handling of incoming ICMPV6_PKT_TOOBIG messages
From: Simon Horman @ 2009-07-24 2:47 UTC (permalink / raw)
To: lvs-devel, netdev; +Cc: David Miller, Julius Volz, Rob Gallagher
In-Reply-To: <20090624132232.GA9633@egardia>
From: Julius Volz <julius.volz@gmail.com>
IPVS: Add handling of incoming ICMPV6_PKT_TOOBIG messages
Add handling of incoming ICMPv6 Packet Too Big messages. This message
is received when a realserver sends a packet >PMTU to the client. The
hop on this path with insufficient MTU will generate an ICMPv6 Packet
Too Big message back to the VIP. The LVS server receives this message,
but the call to the function handling this has been missing. Thus, IPVS
fails to forward the message to the real server, which then does not
adjust the path MTU. This patch adds the missing call to
ip_vs_in_icmp_v6() in ip_vs_in() to handle this situation.
Thanks to Rob Gallagher from HEAnet for reporting this issue and for
testing this patch in production (with direct routing mode).
Signed-off-by: Julius Volz <julius.volz@gmail.com>
Tested-by: Rob Gallagher <robert.gallagher@heanet.ie>
Signed-off-by: Simon Horman <horms@verge.net.au>
---
net/netfilter/ipvs/ip_vs_core.c | 23 +++++++++++++++++------
1 files changed, 17 insertions(+), 6 deletions(-)
Dave, please consider applying this change.
I'm ok with it not going into 2.6.31 as I don't think that
many people are affected by this problem.
diff --git a/net/netfilter/ipvs/ip_vs_core.c b/net/netfilter/ipvs/ip_vs_core.c
index 8dddb17..5750800 100644
--- a/net/netfilter/ipvs/ip_vs_core.c
+++ b/net/netfilter/ipvs/ip_vs_core.c
@@ -1274,13 +1274,24 @@ ip_vs_in(unsigned int hooknum, struct sk_buff *skb,
return NF_ACCEPT;
}
- if (unlikely(iph.protocol == IPPROTO_ICMP)) {
- int related, verdict = ip_vs_in_icmp(skb, &related, hooknum);
+#ifdef CONFIG_IP_VS_IPV6
+ if (af == AF_INET6) {
+ if (unlikely(iph.protocol == IPPROTO_ICMPV6)) {
+ int related, verdict = ip_vs_in_icmp_v6(skb, &related, hooknum);
- if (related)
- return verdict;
- ip_vs_fill_iphdr(af, skb_network_header(skb), &iph);
- }
+ if (related)
+ return verdict;
+ ip_vs_fill_iphdr(af, skb_network_header(skb), &iph);
+ }
+ } else
+#endif
+ if (unlikely(iph.protocol == IPPROTO_ICMP)) {
+ int related, verdict = ip_vs_in_icmp(skb, &related, hooknum);
+
+ if (related)
+ return verdict;
+ ip_vs_fill_iphdr(af, skb_network_header(skb), &iph);
+ }
/* Protocol supported? */
pp = ip_vs_proto_get(iph.protocol);
^ permalink raw reply related
* [net-2.6 PATCH] ixgbe: fix for 82599 errata marking UDP checksum errors
From: Jeff Kirsher @ 2009-07-24 4:00 UTC (permalink / raw)
To: davem; +Cc: netdev, gospo, Don Skidmore, Jeff Kirsher
From: Don Skidmore <donald.c.skidmore@intel.com>
There is an 82599 errata that UDP frames with a zero checksum are
incorrectly marked as checksum invalid by the hardware. This was
leading to misleading hw_csum_rx_error counts. This patch adds a
test around this counter increase for this condition.
Signed-off-by: Don Skidmore <donald.c.skidmore@intel.com>
Signed-off-by: Jeff Kirsher <jeffrey.t.kirsher@intel.com>
---
drivers/net/ixgbe/ixgbe_main.c | 17 +++++++++++++++--
1 files changed, 15 insertions(+), 2 deletions(-)
diff --git a/drivers/net/ixgbe/ixgbe_main.c b/drivers/net/ixgbe/ixgbe_main.c
index 6887759..200454f 100644
--- a/drivers/net/ixgbe/ixgbe_main.c
+++ b/drivers/net/ixgbe/ixgbe_main.c
@@ -511,8 +511,11 @@ static void ixgbe_receive_skb(struct ixgbe_q_vector *q_vector,
* @skb: skb currently being received and modified
**/
static inline void ixgbe_rx_checksum(struct ixgbe_adapter *adapter,
- u32 status_err, struct sk_buff *skb)
+ union ixgbe_adv_rx_desc *rx_desc,
+ struct sk_buff *skb)
{
+ u32 status_err = le32_to_cpu(rx_desc->wb.upper.status_error);
+
skb->ip_summed = CHECKSUM_NONE;
/* Rx csum disabled */
@@ -530,6 +533,16 @@ static inline void ixgbe_rx_checksum(struct ixgbe_adapter *adapter,
return;
if (status_err & IXGBE_RXDADV_ERR_TCPE) {
+ u16 pkt_info = rx_desc->wb.lower.lo_dword.hs_rss.pkt_info;
+
+ /*
+ * 82599 errata, UDP frames with a 0 checksum can be marked as
+ * checksum errors.
+ */
+ if ((pkt_info & IXGBE_RXDADV_PKTTYPE_UDP) &&
+ (adapter->hw.mac.type == ixgbe_mac_82599EB))
+ return;
+
adapter->hw_csum_rx_error++;
return;
}
@@ -803,7 +816,7 @@ static bool ixgbe_clean_rx_irq(struct ixgbe_q_vector *q_vector,
goto next_desc;
}
- ixgbe_rx_checksum(adapter, staterr, skb);
+ ixgbe_rx_checksum(adapter, rx_desc, skb);
/* probably a little skewed due to removing CRC */
total_rx_bytes += skb->len;
^ permalink raw reply related
* [net-next-2.6 PATCH 01/13] igb: remove media type fiber as it is misleading
From: Jeff Kirsher @ 2009-07-24 4:07 UTC (permalink / raw)
To: davem; +Cc: netdev, gospo, Alexander Duyck, Jeff Kirsher
From: Alexander Duyck <alexander.h.duyck@intel.com>
The current igb driver only supports copper and serdes. The fiber media
type is a holdover from earlier NICs as the current nics supported by igb
all use serdes when communicating over a fiber connection. As a result we
can remove media type fiber without losing any functionality.
Signed-off-by: Alexander Duyck <alexander.h.duyck@intel.com>
Signed-off-by: Jeff Kirsher <jeffrey.t.kirsher@intel.com>
---
drivers/net/igb/e1000_82575.c | 3 +--
drivers/net/igb/e1000_hw.h | 3 +--
drivers/net/igb/e1000_mac.c | 37 +++++++++++--------------------------
drivers/net/igb/igb_ethtool.c | 25 +++++++++----------------
drivers/net/igb/igb_main.c | 12 ------------
5 files changed, 22 insertions(+), 58 deletions(-)
diff --git a/drivers/net/igb/e1000_82575.c b/drivers/net/igb/e1000_82575.c
index ac28dd5..bd3efdb 100644
--- a/drivers/net/igb/e1000_82575.c
+++ b/drivers/net/igb/e1000_82575.c
@@ -867,8 +867,7 @@ void igb_shutdown_fiber_serdes_link_82575(struct e1000_hw *hw)
u32 reg;
if (hw->mac.type != e1000_82576 ||
- (hw->phy.media_type != e1000_media_type_fiber &&
- hw->phy.media_type != e1000_media_type_internal_serdes))
+ hw->phy.media_type != e1000_media_type_internal_serdes)
return;
/* if the management interface is not enabled, then power down */
diff --git a/drivers/net/igb/e1000_hw.h b/drivers/net/igb/e1000_hw.h
index 68aac20..f096ddd 100644
--- a/drivers/net/igb/e1000_hw.h
+++ b/drivers/net/igb/e1000_hw.h
@@ -61,8 +61,7 @@ enum e1000_mac_type {
enum e1000_media_type {
e1000_media_type_unknown = 0,
e1000_media_type_copper = 1,
- e1000_media_type_fiber = 2,
- e1000_media_type_internal_serdes = 3,
+ e1000_media_type_internal_serdes = 2,
e1000_num_media_types
};
diff --git a/drivers/net/igb/e1000_mac.c b/drivers/net/igb/e1000_mac.c
index 472f3f1..37706d9 100644
--- a/drivers/net/igb/e1000_mac.c
+++ b/drivers/net/igb/e1000_mac.c
@@ -713,8 +713,7 @@ s32 igb_config_fc_after_link_up(struct e1000_hw *hw)
* configuration of the MAC to match the "fc" parameter.
*/
if (mac->autoneg_failed) {
- if (hw->phy.media_type == e1000_media_type_fiber ||
- hw->phy.media_type == e1000_media_type_internal_serdes)
+ if (hw->phy.media_type == e1000_media_type_internal_serdes)
ret_val = igb_force_mac_fc(hw);
} else {
if (hw->phy.media_type == e1000_media_type_copper)
@@ -1161,22 +1160,16 @@ s32 igb_blink_led(struct e1000_hw *hw)
u32 ledctl_blink = 0;
u32 i;
- if (hw->phy.media_type == e1000_media_type_fiber) {
- /* always blink LED0 for PCI-E fiber */
- ledctl_blink = E1000_LEDCTL_LED0_BLINK |
- (E1000_LEDCTL_MODE_LED_ON << E1000_LEDCTL_LED0_MODE_SHIFT);
- } else {
- /*
- * set the blink bit for each LED that's "on" (0x0E)
- * in ledctl_mode2
- */
- ledctl_blink = hw->mac.ledctl_mode2;
- for (i = 0; i < 4; i++)
- if (((hw->mac.ledctl_mode2 >> (i * 8)) & 0xFF) ==
- E1000_LEDCTL_MODE_LED_ON)
- ledctl_blink |= (E1000_LEDCTL_LED0_BLINK <<
- (i * 8));
- }
+ /*
+ * set the blink bit for each LED that's "on" (0x0E)
+ * in ledctl_mode2
+ */
+ ledctl_blink = hw->mac.ledctl_mode2;
+ for (i = 0; i < 4; i++)
+ if (((hw->mac.ledctl_mode2 >> (i * 8)) & 0xFF) ==
+ E1000_LEDCTL_MODE_LED_ON)
+ ledctl_blink |= (E1000_LEDCTL_LED0_BLINK <<
+ (i * 8));
wr32(E1000_LEDCTL, ledctl_blink);
@@ -1191,15 +1184,7 @@ s32 igb_blink_led(struct e1000_hw *hw)
**/
s32 igb_led_off(struct e1000_hw *hw)
{
- u32 ctrl;
-
switch (hw->phy.media_type) {
- case e1000_media_type_fiber:
- ctrl = rd32(E1000_CTRL);
- ctrl |= E1000_CTRL_SWDPIN0;
- ctrl |= E1000_CTRL_SWDPIO0;
- wr32(E1000_CTRL, ctrl);
- break;
case e1000_media_type_copper:
wr32(E1000_LEDCTL, hw->mac.ledctl_mode1);
break;
diff --git a/drivers/net/igb/igb_ethtool.c b/drivers/net/igb/igb_ethtool.c
index 9598ac0..a9c37cb 100644
--- a/drivers/net/igb/igb_ethtool.c
+++ b/drivers/net/igb/igb_ethtool.c
@@ -168,8 +168,7 @@ static int igb_get_settings(struct net_device *netdev, struct ethtool_cmd *ecmd)
ecmd->duplex = -1;
}
- ecmd->autoneg = ((hw->phy.media_type == e1000_media_type_fiber) ||
- hw->mac.autoneg) ? AUTONEG_ENABLE : AUTONEG_DISABLE;
+ ecmd->autoneg = hw->mac.autoneg ? AUTONEG_ENABLE : AUTONEG_DISABLE;
return 0;
}
@@ -191,23 +190,18 @@ static int igb_set_settings(struct net_device *netdev, struct ethtool_cmd *ecmd)
if (ecmd->autoneg == AUTONEG_ENABLE) {
hw->mac.autoneg = 1;
- if (hw->phy.media_type == e1000_media_type_fiber)
- hw->phy.autoneg_advertised = ADVERTISED_1000baseT_Full |
- ADVERTISED_FIBRE |
- ADVERTISED_Autoneg;
- else
- hw->phy.autoneg_advertised = ecmd->advertising |
- ADVERTISED_TP |
- ADVERTISED_Autoneg;
+ hw->phy.autoneg_advertised = ecmd->advertising |
+ ADVERTISED_TP |
+ ADVERTISED_Autoneg;
ecmd->advertising = hw->phy.autoneg_advertised;
- } else
+ } else {
if (igb_set_spd_dplx(adapter, ecmd->speed + ecmd->duplex)) {
clear_bit(__IGB_RESETTING, &adapter->state);
return -EINVAL;
}
+ }
/* reset the link */
-
if (netif_running(adapter->netdev)) {
igb_down(adapter);
igb_up(adapter);
@@ -267,8 +261,8 @@ static int igb_set_pauseparam(struct net_device *netdev,
} else
igb_reset(adapter);
} else
- retval = ((hw->phy.media_type == e1000_media_type_fiber) ?
- igb_setup_link(hw) : igb_force_mac_fc(hw));
+ retval = ((hw->phy.media_type == e1000_media_type_copper) ?
+ igb_force_mac_fc(hw) : igb_setup_link(hw));
clear_bit(__IGB_RESETTING, &adapter->state);
return retval;
@@ -1483,8 +1477,7 @@ static int igb_setup_loopback_test(struct igb_adapter *adapter)
struct e1000_hw *hw = &adapter->hw;
u32 reg;
- if (hw->phy.media_type == e1000_media_type_fiber ||
- hw->phy.media_type == e1000_media_type_internal_serdes) {
+ if (hw->phy.media_type == e1000_media_type_internal_serdes) {
reg = rd32(E1000_RCTL);
reg |= E1000_RCTL_LBM_TCVR;
wr32(E1000_RCTL, reg);
diff --git a/drivers/net/igb/igb_main.c b/drivers/net/igb/igb_main.c
index adb09d3..39b3b6a 100644
--- a/drivers/net/igb/igb_main.c
+++ b/drivers/net/igb/igb_main.c
@@ -2618,10 +2618,6 @@ static bool igb_has_link(struct igb_adapter *adapter)
link_active = true;
}
break;
- case e1000_media_type_fiber:
- ret_val = hw->mac.ops.check_for_link(hw);
- link_active = !!(rd32(E1000_STATUS) & E1000_STATUS_LU);
- break;
case e1000_media_type_internal_serdes:
ret_val = hw->mac.ops.check_for_link(hw);
link_active = hw->mac.serdes_has_link;
@@ -5136,14 +5132,6 @@ int igb_set_spd_dplx(struct igb_adapter *adapter, u16 spddplx)
mac->autoneg = 0;
- /* Fiber NICs only allow 1000 gbps Full duplex */
- if ((adapter->hw.phy.media_type == e1000_media_type_fiber) &&
- spddplx != (SPEED_1000 + DUPLEX_FULL)) {
- dev_err(&adapter->pdev->dev,
- "Unsupported Speed/Duplex configuration\n");
- return -EINVAL;
- }
-
switch (spddplx) {
case SPEED_10 + DUPLEX_HALF:
mac->forced_speed_duplex = ADVERTISE_10_HALF;
^ permalink raw reply related
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