* Re: TESTING ROUTING CODE !!
From: Mulyadi Santosa @ 2009-07-16 18:34 UTC (permalink / raw)
To: Leena M.; +Cc: Kent Tu, kernelnewbies@nl.linux.org, netdev@vger.kernel.org
In-Reply-To: <e49baca60907161113s411e7d4ck472a9141881f56a1@mail.gmail.com>
On Fri, Jul 17, 2009 at 1:13 AM, Leena M.<kernmonk@gmail.com> wrote:
> Any specific VM do you recommend , How about Xen ?
>
> Regards,
> Leena
Please don't top post...
Since you talked about routing protocol, I think User Mode Linux would
do just fine. It runs completely in user space and can be easily
hooked with gdb.
--
regards,
Mulyadi Santosa
Freelance Linux trainer
blog: the-hydra.blogspot.com
^ permalink raw reply
* Re: TESTING ROUTING CODE !!
From: Deepak Shah @ 2009-07-16 18:36 UTC (permalink / raw)
To: Leena M.; +Cc: Kent Tu, kernelnewbies@nl.linux.org, netdev@vger.kernel.org
In-Reply-To: <e49baca60907161113s411e7d4ck472a9141881f56a1@mail.gmail.com>
[-- Attachment #1: Type: text/plain, Size: 599 bytes --]
you can use xen , vmware or virtual box....
thanks
deepak
On Thu, Jul 16, 2009 at 11:43 PM, Leena M. <kernmonk@gmail.com> wrote:
> Any specific VM do you recommend , How about Xen ?
>
> Regards,
> Leena
>
>
> On Thu, Jul 16, 2009 at 11:36 PM, Kent Tu <kachin2@gmail.com> wrote:
>
>> I'd recommend you to use virtual machines.
>>
>>
>>
>>
>> On Jul 16, 2009, at 10:39 AM, "Leena M." <kernmonk@gmail.com> wrote:
>>
>> How can we test routing and other networking code
>>> given a single machine with plenty of ram and processing power ?
>>>
>>> Regards,
>>> Leena
>>>
>>
>
--
Thanks
Deepak Shah
[-- Attachment #2: Type: text/html, Size: 1526 bytes --]
^ permalink raw reply
* Re: [PATCHv2] tcp: Fix MD5 signature checking on IPv4 mapped sockets
From: Stephen Hemminger @ 2009-07-16 18:36 UTC (permalink / raw)
To: John Dykstra; +Cc: netdev
In-Reply-To: <1247756691.7627.5.camel@Maple>
On Thu, 16 Jul 2009 10:04:51 -0500
John Dykstra <john.dykstra1@gmail.com> wrote:
> This revision to the patch removes a misplaced
> blank line.
>
> ---
> Fix MD5 signature checking so that an IPv4 active open
> to an IPv6 socket can succeed. In particular, use the
> correct address family's signature generation function
> for the SYN/ACK.
>
> Reported-by: Stephen Hemminger <shemminger@vyatta.com>
> Signed-off-by: John Dykstra <john.dykstra1@gmail.com>
This fixes the syn-ack, but data does not flow.
I had a simpler attempt that had same problem:
--- a/net/ipv6/tcp_ipv6.c 2009-07-15 18:08:11.042505387 -0700
+++ b/net/ipv6/tcp_ipv6.c 2009-07-15 20:05:56.270009553 -0700
@@ -1169,8 +1169,17 @@ static int tcp_v6_conn_request(struct so
#define want_cookie 0
#endif
- if (skb->protocol == htons(ETH_P_IP))
- return tcp_v4_conn_request(sk, skb);
+ if (skb->protocol == htons(ETH_P_IP)) {
+ int err;
+#ifdef CONFIG_TCP_MD5SIG
+ tp->af_specific = &tcp_sock_ipv6_mapped_specific;
+#endif
+ err = tcp_v4_conn_request(sk, skb);
+#ifdef CONFIG_TCP_MD5SIG
+ tp->af_specific = &tcp_sock_ipv6_specific;
+#endif
+ return err;
+ }
if (!ipv6_unicast_destination(skb))
goto drop;
^ permalink raw reply
* Re: ixgbe: schedule while atomic bug during dev_disable_lro 2.6.31-rc3
From: Waskiewicz Jr, Peter P @ 2009-07-16 19:13 UTC (permalink / raw)
To: Ben Greear; +Cc: NetDev
In-Reply-To: <4A5E5F8A.308@candelatech.com>
On Wed, 15 Jul 2009, Ben Greear wrote:
> I just got a fancy new 10G NIC and tried it out in a (patched elsewhere, but stock ixgbe driver) 2.6.31-rc3) kernel.
>
> First of all, it runs very fast: sustained 9.5Gbps tx + rx on two ports concurrently (using modified pktgen),
> with 1500 byte pkts.
>
> I did see a warning in the boot logs though.
Yes, see below for an explanation.
> ixgbe: 0000:03:00.0: ixgbe_init_interrupt_scheme: Multiqueue Enabled: Rx Queue count = 8, Tx Queue count = 8
> ixgbe 0000:03:00.0: (PCI Express:5.0Gb/s:Width x8) 00:0c:bd:00:90:1a
> ixgbe 0000:03:00.0: MAC: 2, PHY: 9, SFP+: 5, PBA No: e57138-000
> ixgbe 0000:03:00.0: This device is a pre-production adapter/LOM. Please be aware there may be issues associated with your hardware. If you are experiencing
> problems please contact your Intel or hardware representative who provided you with this hardware.
It's self-explanatory; the EEPROM version on the NIC is not the
production-level EEPROM. If you run ethtool -i ethX on this interface,
you will see what the firmware (EEPROM) version is. My guess is it's
going to be 0.5-1 or something; the production firmware is 0.9-3. If you
received this NIC from an Intel rep, they can get you the production
EEPROM and tools necessary to reprogram the NIC.
> BUG: scheduling while atomic: S99lanforge/2133/0x00000002
> Modules linked in: sco stp llc bnep l2cap bluetooth nfs lockd fscache nfs_acl auth_rpcgss sunrpc ipv6 dm_multipath uinput ixgbe i2c_i801 i2c_core dca mdio
> e1000e iTCO_wdt iTCO_vendor_support pcspkr ata_generic pata_acpi [last unloaded: bridge]
> Pid: 2133, comm: S99lanforge Not tainted 2.6.31-rc3 #2
> Call Trace:
> [<ffffffff81042456>] __schedule_bug+0x5c/0x60
> [<ffffffff813e6712>] schedule+0xc1/0x85e
> [<ffffffff8104488a>] ? check_preempt_wakeup+0x2d/0x1b7
> [<ffffffff813e880b>] ? _spin_unlock_irqrestore+0x37/0x42
> [<ffffffff813e7182>] schedule_timeout+0x97/0xbb
> [<ffffffff8105857e>] ? process_timeout+0x0/0xb
> [<ffffffff813e71bf>] schedule_timeout_uninterruptible+0x19/0x1b
> [<ffffffff81058a25>] msleep+0x16/0x1d
> [<ffffffffa005e160>] ixgbe_stop_adapter_generic+0x38/0x97 [ixgbe]
> [<ffffffffa0063e5a>] ixgbe_reset_hw_82599+0x13/0x1a4 [ixgbe]
> [<ffffffffa005cfc3>] ixgbe_init_hw_generic+0xf/0x1d [ixgbe]
> [<ffffffffa0056f04>] ixgbe_reset+0x1e/0xef [ixgbe]
> [<ffffffffa005ee71>] ixgbe_set_flags+0x5c/0x66 [ixgbe]
> [<ffffffff81343fe2>] dev_disable_lro+0x4d/0x69
> [<ffffffff81398191>] devinet_sysctl_forward+0xd7/0x1a4
> [<ffffffff81136111>] proc_sys_call_handler+0x8d/0xb7
> [<ffffffff8113614a>] proc_sys_write+0xf/0x11
> [<ffffffff810e856d>] vfs_write+0xa9/0x106
> [<ffffffff810e8680>] sys_write+0x45/0x69
> [<ffffffff81011b42>] system_call_fastpath+0x16/0x1b
We haven't seen such a panic in our testing, but we don't heavily test
toggling the LRO flags. We lightly touch the flags, but nothing heavy.
Note that there is a difference in this device, 82599 (assumed since
your lspci shows you're linked at 5.0 Gt/sec), that we have a HW-based
LRO running. This is the preferred configuration the driver uses at
load; there may be something broken with how we switch between HW LRO +
GRO and just straight GRO.
I will see if our validation guys can reproduce this. In the meantime,
can you try without preempt enabled? Also, it wasn't obvious to me if
this is 100% reproducible, or if it's racy. Can you comment on that?
Cheers,
-PJ
^ permalink raw reply
* Re: ixgbe: schedule while atomic bug during dev_disable_lro 2.6.31-rc3
From: Ben Greear @ 2009-07-16 19:32 UTC (permalink / raw)
To: Waskiewicz Jr, Peter P; +Cc: NetDev
In-Reply-To: <Pine.WNT.4.64.0907161206260.5316@ppwaskie-MOBL2.amr.corp.intel.com>
On 07/16/2009 12:13 PM, Waskiewicz Jr, Peter P wrote:
> On Wed, 15 Jul 2009, Ben Greear wrote:
>
>> I just got a fancy new 10G NIC and tried it out in a (patched elsewhere, but stock ixgbe driver) 2.6.31-rc3) kernel.
>>
>> First of all, it runs very fast: sustained 9.5Gbps tx + rx on two ports concurrently (using modified pktgen),
>> with 1500 byte pkts.
>>
>> I did see a warning in the boot logs though.
>
> Yes, see below for an explanation.
>
>> ixgbe: 0000:03:00.0: ixgbe_init_interrupt_scheme: Multiqueue Enabled: Rx Queue count = 8, Tx Queue count = 8
>> ixgbe 0000:03:00.0: (PCI Express:5.0Gb/s:Width x8) 00:0c:bd:00:90:1a
>> ixgbe 0000:03:00.0: MAC: 2, PHY: 9, SFP+: 5, PBA No: e57138-000
>> ixgbe 0000:03:00.0: This device is a pre-production adapter/LOM. Please be aware there may be issues associated with your hardware. If you are experiencing
>> problems please contact your Intel or hardware representative who provided you with this hardware.
>
> It's self-explanatory; the EEPROM version on the NIC is not the
> production-level EEPROM. If you run ethtool -i ethX on this interface,
> you will see what the firmware (EEPROM) version is. My guess is it's
> going to be 0.5-1 or something; the production firmware is 0.9-3. If you
> received this NIC from an Intel rep, they can get you the production
> EEPROM and tools necessary to reprogram the NIC.
Yes, 0.5-1
I got it from interfacemasters.com, but they can probably help me do the same.
> We haven't seen such a panic in our testing, but we don't heavily test
> toggling the LRO flags. We lightly touch the flags, but nothing heavy.
> Note that there is a difference in this device, 82599 (assumed since
> your lspci shows you're linked at 5.0 Gt/sec), that we have a HW-based
> LRO running. This is the preferred configuration the driver uses at
> load; there may be something broken with how we switch between HW LRO +
> GRO and just straight GRO.
I believe the trigger for this is my script that enables ip_forward. I'm
not twiddling LRO settings directly as far as I can tell.
> I will see if our validation guys can reproduce this. In the meantime,
> can you try without preempt enabled? Also, it wasn't obvious to me if
> this is 100% reproducible, or if it's racy. Can you comment on that?
It is 100% reproducible on the system I'm testing. I haven't tried other servers
or other ixgbe NICs yet.
I'll try w/out pre-empt, should have results later today.
Thanks,
Ben
--
Ben Greear <greearb@candelatech.com>
Candela Technologies Inc http://www.candelatech.com
^ permalink raw reply
* Re: ixgbe: schedule while atomic bug during dev_disable_lro 2.6.31-rc3
From: Jesper Dangaard Brouer @ 2009-07-16 19:58 UTC (permalink / raw)
To: Ben Greear; +Cc: Waskiewicz Jr, Peter P, NetDev
In-Reply-To: <4A5F8062.6090009@candelatech.com>
On Thu, 16 Jul 2009, Ben Greear wrote:
> On 07/16/2009 12:13 PM, Waskiewicz Jr, Peter P wrote:
>> On Wed, 15 Jul 2009, Ben Greear wrote:
>>
>> > I just got a fancy new 10G NIC and tried it out in a (patched elsewhere,
>> > but stock ixgbe driver) 2.6.31-rc3) kernel.
>> >
>> > First of all, it runs very fast: sustained 9.5Gbps tx + rx on two ports
>> > concurrently (using modified pktgen),
>> > with 1500 byte pkts.
Yes, its very fast! Using pktgen, I can generate 11Mpps with 64 bytes
packets. Compared to my other 10GbE NIC which can do 3-4 Mpps.
>> > ixgbe 0000:03:00.0: This device is a pre-production adapter/LOM. Please
>> > be aware there may be issues associated with your hardware. If you are
>> > experiencing
>> > problems please contact your Intel or hardware representative who
>> > provided you with this hardware.
>>
>> It's self-explanatory; the EEPROM version on the NIC is not the
>> production-level EEPROM. If you run ethtool -i ethX on this interface,
>> you will see what the firmware (EEPROM) version is. My guess is it's
>> going to be 0.5-1 or something; the production firmware is 0.9-3. If you
>> received this NIC from an Intel rep, they can get you the production
>> EEPROM and tools necessary to reprogram the NIC.
>
> Yes, 0.5-1
I'm running firmware-version: 0.9-3 (which I think Peter upgraded for me).
I'm also seeing the issue (sorry for not reporting it before now, Peter, I
was going to bring it up later. Didn't think the NIC was being shipped
yet)
> I believe the trigger for this is my script that enables ip_forward. I'm
> not twiddling LRO settings directly as far as I can tell.
Also think its when the boot scripts enable ip_forward.
See the devinet_sysctl_forward() call below.
root@firesoul:~# uname -a
Linux firesoul 2.6.31-rc1-net-2.6-00122-ge594e96 #8 SMP PREEMPT Fri Jul 10 17:01:40 CEST 2009 x86_64 GNU/Linux
[ 11.729520] ixgbe: eth33 NIC Link is Up 10 Gbps, Flow Control: RX/TX
[ 11.729541] ixgbe: eth33 NIC Link is Up 10 Gbps, Flow Control: RX/TX
[ 12.496856] BUG: scheduling while atomic: sysctl/3214/0x00000002
[ 12.497184] Modules linked in: asus_atk0110 ixgbe hwmon mdio r8169
[ 12.497190] Pid: 3214, comm: sysctl Not tainted 2.6.31-rc1-net-2.6-00122-ge594e96 #8
[ 12.497192] Call Trace:
[ 12.497198] [<ffffffff8102f8c2>] __schedule_bug+0x57/0x5c
[ 12.497202] [<ffffffff81428291>] schedule+0xcb/0x88f
[ 12.497206] [<ffffffff810aaedb>] ? __inc_zone_state+0x11/0x75
[ 12.497211] [<ffffffff81044301>] ? lock_timer_base+0x26/0x4a
[ 12.497214] [<ffffffff8142a10a>] ? _spin_unlock_irqrestore+0x2c/0x37
[ 12.497217] [<ffffffff81044872>] ? __mod_timer+0x102/0x114
[ 12.497220] [<ffffffff81428d7f>] schedule_timeout+0x98/0xbf
[ 12.497223] [<ffffffff81044413>] ? process_timeout+0x0/0xb
[ 12.497225] [<ffffffff81428d7a>] ? schedule_timeout+0x93/0xbf
[ 12.497228] [<ffffffff81428dbf>] schedule_timeout_uninterruptible+0x19/0x1b
[ 12.497231] [<ffffffff81044898>] msleep+0x14/0x1e
[ 12.497240] [<ffffffffa001d19f>] ixgbe_down+0xc7/0x25e [ixgbe]
[ 12.497248] [<ffffffffa001e512>] ixgbe_reinit_locked+0x59/0x70 [ixgbe]
[ 12.497256] [<ffffffffa0020691>] ixgbe_set_flags+0x52/0x66 [ixgbe]
[ 12.497260] [<ffffffff813882f6>] dev_disable_lro+0x4d/0x69
[ 12.497264] [<ffffffff813d904e>] devinet_sysctl_forward+0xd2/0x1a2
[ 12.497268] [<ffffffff8110aea9>] proc_sys_call_handler+0x96/0xbc
[ 12.497272] [<ffffffff811a9482>] ? __up_read+0x92/0x9c
[ 12.497274] [<ffffffff8110aede>] proc_sys_write+0xf/0x11
[ 12.497277] [<ffffffff810cd625>] vfs_write+0xab/0x105
[ 12.497280] [<ffffffff810cd743>] sys_write+0x47/0x6e
[ 12.497284] [<ffffffff8100baeb>] system_call_fastpath+0x16/0x1b
Cheers,
Jesper Brouer
--
-------------------------------------------------------------------
MSc. Master of Computer Science
Dept. of Computer Science, University of Copenhagen
Author of http://www.adsl-optimizer.dk
-------------------------------------------------------------------
^ permalink raw reply
* Re: [PATCH] imwc3200: move iwmc3200 SDIO ids to sdio_ids.h
From: David Miller @ 2009-07-16 20:07 UTC (permalink / raw)
To: marcel; +Cc: tomasw, yi.zhu, drzeus-list, netdev, linux-wireless, linux-kernel
In-Reply-To: <1247763454.4549.56.camel@violet>
From: Marcel Holtmann <marcel@holtmann.org>
Date: Thu, 16 Jul 2009 18:57:34 +0200
> Hi Dave,
>
>> > > Subject: RE: [PATCH] imwc3200: move iwmc3200 SDIO ids to sdio_ids.h
>> >
>> > BTW, subject should be "iwmc3200".
>>
>> Thanks. I'll address all comments although I'm not sure how to split
>> the patch since adding SDIO_VENDOR_ID_INTEL to sdio_ids.h it affects
>> all the drivers anyhow, so I'm suggesting to route it through netdev.
>
> I think it is best that you take the whole patch via net-next-2.6 to
> avoid breakage during the next merge window.
Fair enough.
^ permalink raw reply
* Re: TESTING ROUTING CODE !!
From: Gregory Carter @ 2009-07-16 19:16 UTC (permalink / raw)
To: Mulyadi Santosa
Cc: Leena M., Kent Tu, kernelnewbies@nl.linux.org,
netdev@vger.kernel.org
In-Reply-To: <f284c33d0907161134q20d01fc2wf63f484b63bb52d@mail.gmail.com>
I am currently using KVM.
Works very well for creating virtual networks, and testing iptable and
marking of packets for different routing code tests.
I use KVM because it keeps all of the machines seperate, and of course,
some of my machines are BSD.
So if you have different code bases you want to try your modifications
with, KVM is a good choice IMHO.
-Gregory Carter
-Applied Engineering Software Group
-gcarter@aesgi.com
On 07/16/2009 01:34 PM, Mulyadi Santosa wrote:
> On Fri, Jul 17, 2009 at 1:13 AM, Leena M.<kernmonk@gmail.com> wrote:
>> Any specific VM do you recommend , How about Xen ?
>>
>> Regards,
>> Leena
>
> Please don't top post...
>
> Since you talked about routing protocol, I think User Mode Linux would
> do just fine. It runs completely in user space and can be easily
> hooked with gdb.
>
>
^ permalink raw reply
* Re: ixgbe: schedule while atomic bug during dev_disable_lro 2.6.31-rc3
From: David Miller @ 2009-07-16 20:17 UTC (permalink / raw)
To: greearb; +Cc: peter.p.waskiewicz.jr, netdev
In-Reply-To: <4A5F8062.6090009@candelatech.com>
From: Ben Greear <greearb@candelatech.com>
Date: Thu, 16 Jul 2009 12:32:50 -0700
> I believe the trigger for this is my script that enables ip_forward.
> I'm not twiddling LRO settings directly as far as I can tell.
Turning on/off bridging or forwarding twiddles the LRO settings
as a side effect.
^ permalink raw reply
* Re: [PATCH 7/8] rt2x00: Use %pM conversion specifier
From: Ivo van Doorn @ 2009-07-16 20:27 UTC (permalink / raw)
To: Tobias Klauser; +Cc: linville, netdev, linux-wireless, users
In-Reply-To: <1247734839-21394-1-git-send-email-klto@zhaw.ch>
On Thursday 16 July 2009, Tobias Klauser wrote:
> Use the %pM conversion specifier for printk instead of print_mac.
>
> Signed-off-by: Tobias Klauser <klto@zhaw.ch>
Acked-by: Ivo van Doorn <IvDoorn@gmail.com>
> ---
> drivers/net/wireless/rt2x00/rt2800usb.c | 4 +---
> 1 files changed, 1 insertions(+), 3 deletions(-)
>
> diff --git a/drivers/net/wireless/rt2x00/rt2800usb.c b/drivers/net/wireless/rt2x00/rt2800usb.c
> index 3756166..da84afb 100644
> --- a/drivers/net/wireless/rt2x00/rt2800usb.c
> +++ b/drivers/net/wireless/rt2x00/rt2800usb.c
> @@ -2224,10 +2224,8 @@ static int rt2800usb_validate_eeprom(struct rt2x00_dev *rt2x00dev)
> */
> mac = rt2x00_eeprom_addr(rt2x00dev, EEPROM_MAC_ADDR_0);
> if (!is_valid_ether_addr(mac)) {
> - DECLARE_MAC_BUF(macbuf);
> -
> random_ether_addr(mac);
> - EEPROM(rt2x00dev, "MAC: %s\n", print_mac(macbuf, mac));
> + EEPROM(rt2x00dev, "MAC: %pM\n", mac);
> }
>
> rt2x00_eeprom_read(rt2x00dev, EEPROM_ANTENNA, &word);
^ permalink raw reply
* Re: [PATCH 7/8] rt2x00: Use %pM conversion specifier
From: Luis R. Rodriguez @ 2009-07-16 20:35 UTC (permalink / raw)
To: Ivo van Doorn
Cc: Tobias Klauser, linville-2XuSBdqkA4R54TAoqtyWWQ,
netdev-u79uwXL29TY76Z2rM5mHXA,
linux-wireless-u79uwXL29TY76Z2rM5mHXA,
users-poMEt7QlJxcwIE2E9O76wjtx2kNaKg5H
In-Reply-To: <200907162227.30362.IvDoorn-Re5JQEeQqe8AvxtiuMwx3w@public.gmane.org>
On Thu, Jul 16, 2009 at 1:27 PM, Ivo van Doorn<ivdoorn-Re5JQEeQqe8AvxtiuMwx3w@public.gmane.org> wrote:
> On Thursday 16 July 2009, Tobias Klauser wrote:
>> Use the %pM conversion specifier for printk instead of print_mac.
>>
>> Signed-off-by: Tobias Klauser <klto-xXYtEe5Xh1A@public.gmane.org>
>
> Acked-by: Ivo van Doorn <IvDoorn-Re5JQEeQqe8AvxtiuMwx3w@public.gmane.org>
Johannes already has a patch for this posted which takes care of all of these.
http://marc.info/?l=linux-wireless&m=124767211929848&w=2
Luis
--
To unsubscribe from this list: send the line "unsubscribe linux-wireless" in
the body of a message to majordomo-u79uwXL29TY76Z2rM5mHXA@public.gmane.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
^ permalink raw reply
* Re: [PATCH] bonding: clean muticast addresses when bevice changes type
From: Jay Vosburgh @ 2009-07-16 20:57 UTC (permalink / raw)
To: Moni Shoua; +Cc: David Miller, Roland Dreier, bonding-devel, netdev
In-Reply-To: <4A5DEE1F.4090707@Voltaire.COM>
Moni Shoua <monis@voltaire.com> wrote:
>Bonding device forbids slave device of different types under the same master.
>However, it is possible for a bonding master to change type during its lifetime.
>This can be either from ARPHRD_ETHER to ARPHRD_INFINIBAND or the other way arround.
>The change of type requires device level multicast address cleanup because device
>level multicast addresses depend on the device type.
>
>The patch adds a call to dev_close() before the bonding master changes type and
>dev_open() just after that.
>
>In the example below I enslaved an IPoIB device (ib0) under bond0. Since
>each bonding master starts as device of type ARPHRD_ETHER by default, a change
>of type occurs when ib0 is enslaved.
>
>This is how /proc/net/dev_mcast looks like without the patch
>
>5 bond0 1 0 00ffffffff12601bffff000000000001ff96ca05
>5 bond0 1 0 01005e000116
>5 bond0 1 0 01005e7ffffd
>5 bond0 1 0 01005e000001
>5 bond0 1 0 333300000001
>6 ib0 1 0 00ffffffff12601bffff000000000001ff96ca05
>6 ib0 1 0 333300000001
>6 ib0 1 0 01005e000001
>6 ib0 1 0 01005e7ffffd
>6 ib0 1 0 01005e000116
>6 ib0 1 0 00ffffffff12401bffff00000000000000000001
>6 ib0 1 0 00ffffffff12601bffff00000000000000000001
>
>and this is how it looks like after the patch.
>
>5 bond0 1 0 00ffffffff12601bffff000000000001ff96ca05
>5 bond0 1 0 00ffffffff12601bffff00000000000000000001
>5 bond0 1 0 00ffffffff12401bffff0000000000000ffffffd
>5 bond0 1 0 00ffffffff12401bffff00000000000000000116
>5 bond0 1 0 00ffffffff12401bffff00000000000000000001
>6 ib0 1 0 00ffffffff12601bffff000000000001ff96ca05
>6 ib0 1 0 00ffffffff12401bffff00000000000000000116
>6 ib0 1 0 00ffffffff12401bffff0000000000000ffffffd
>6 ib0 2 0 00ffffffff12401bffff00000000000000000001
>6 ib0 2 0 00ffffffff12601bffff00000000000000000001
>
>Signed-off-by: Moni Shoua <monis@voltaire.com>
I checked the discussion noted in a separate email, and the
rationale seems reasonable.
Signed-off-by: Jay Vosburgh <fubar@us.ibm.com>
>
> drivers/net/bonding/bond_main.c | 12 ++++++++++--
> 1 file changed, 10 insertions(+), 2 deletions(-)
>
>diff --git a/drivers/net/bonding/bond_main.c b/drivers/net/bonding/bond_main.c
>index d927f71..aa1be1f 100644
>--- a/drivers/net/bonding/bond_main.c
>+++ b/drivers/net/bonding/bond_main.c
>@@ -1459,8 +1459,16 @@ int bond_enslave(struct net_device *bond_dev, struct net_device *slave_dev)
> * ether type (eg ARPHRD_ETHER and ARPHRD_INFINIBAND) share the same bond
> */
> if (bond->slave_cnt == 0) {
>- if (slave_dev->type != ARPHRD_ETHER)
>- bond_setup_by_slave(bond_dev, slave_dev);
>+ if (bond_dev->type != slave_dev->type) {
>+ dev_close(bond_dev);
>+ pr_debug("%s: change device type from %d to %d\n",
>+ bond_dev->name, bond_dev->type, slave_dev->type);
>+ if (slave_dev->type != ARPHRD_ETHER)
>+ bond_setup_by_slave(bond_dev, slave_dev);
>+ else
>+ ether_setup(bond_dev);
>+ dev_open(bond_dev);
>+ }
> } else if (bond_dev->type != slave_dev->type) {
> pr_err(DRV_NAME ": %s ether type (%d) is different "
> "from other slaves (%d), can not enslave it.\n",
^ permalink raw reply
* Re: ixgbe: schedule while atomic bug during dev_disable_lro 2.6.31-rc3
From: Ben Greear @ 2009-07-16 21:08 UTC (permalink / raw)
To: Waskiewicz Jr, Peter P; +Cc: NetDev
In-Reply-To: <4A5F8062.6090009@candelatech.com>
On 07/16/2009 12:32 PM, Ben Greear wrote:
> It is 100% reproducible on the system I'm testing. I haven't tried other
> servers
> or other ixgbe NICs yet.
>
> I'll try w/out pre-empt, should have results later today.
I set pre-empt to Voluntary and I no longer see these warnings
in dmesg.
Thanks,
Ben
--
Ben Greear <greearb@candelatech.com>
Candela Technologies Inc http://www.candelatech.com
^ permalink raw reply
* Re: [PATCH 1/2 v3] fs_enet/mii-fec.c: fix MII speed calculation
From: Wolfgang Denk @ 2009-07-16 21:21 UTC (permalink / raw)
To: Grant Likely; +Cc: linuxppc-dev, Kumar Gala, netdev
In-Reply-To: <fa686aa40907151017n76524708tdb028689adad4b5f@mail.gmail.com>
Dear Grant Likely,
In message <fa686aa40907151017n76524708tdb028689adad4b5f@mail.gmail.com> you wrote:
> On Wed, Jul 15, 2009 at 9:18 AM, Wolfgang Denk<wd@denx.de> wrote:
> > The MII speed calculation was based on the CPU clock (ppc_proc_freq),
> > but for MPC512x we must use the bus clock instead.
> >
> > This patch makes it use the correct clock and makes sure we don't
> > clobber reserved bits in the MII_SPEED register.
...
> Drop the common code bit. The 5200 and 5121 are different devices and
> it is a tiny bit of code. I don't think there is any benefit to
> having it as a common function. Just roll the get_mii_speed function
> in the mii-fec driver itself.
I don't like to see the code repeated - it makes maintenance harder
and increases the memory footprint. But if you like it that way I'll
do that.
> Also, this patch can be quite a bit simpler if you use the .data
> pointer in the drivers match table to specify the function used to
> return the bus clock speed. Something like this:
OK, will do that, too.
Best regards,
Wolfgang Denk
--
DENX Software Engineering GmbH, MD: Wolfgang Denk & Detlev Zundel
HRB 165235 Munich, Office: Kirchenstr.5, D-82194 Groebenzell, Germany
Phone: (+49)-8142-66989-10 Fax: (+49)-8142-66989-80 Email: wd@denx.de
Weekends were made for programming. - Karl Lehenbauer
^ permalink raw reply
* Re: [PATCH 2/2] MPC52xx FEC: be more conservative when setting MII_SPEED register
From: Wolfgang Denk @ 2009-07-16 21:21 UTC (permalink / raw)
To: Grant Likely; +Cc: linuxppc-dev, Kumar Gala, netdev
In-Reply-To: <fa686aa40907151018n194a154cmb8549c98c673d2bb@mail.gmail.com>
Dear Grant Likely,
In message <fa686aa40907151018n194a154cmb8549c98c673d2bb@mail.gmail.com> you wrote:
> On Wed, Jul 15, 2009 at 9:18 AM, Wolfgang Denk<wd@denx.de> wrote:
> > This patch adds error checking and prevents clobbering unrelated bits
> > (reserved bits or the DIS_PREAMBLE bit) when writing the MII_SPEED
> > register on MPC52xx systems.
...
> As I mentioned in the other patch, I don't want the 5121 and 5200 FEC
> devices using common code for this. It is a tiny block of code and
> they are different devices. Just open code the needed calculation
> into this driver.
OK, will do.
^ permalink raw reply
* RFC: VETH patch to zero timestamp.
From: Ben Greear @ 2009-07-16 21:26 UTC (permalink / raw)
To: NetDev, xemul, Eric W. Biederman
The patch below helps when using VETH and bridge(s)
This makes sure that the pkt timestamp is properly (re)calculated on
receiving the packet on the peer veth device.
I'm sure this patch is white-space damaged. If this looks
useful, I'll generate a clean patch and send as attachment.
Signed-off-by: Ben Greear<greearb@candelatech.com>
diff --git a/drivers/net/veth.c b/drivers/net/veth.c
index 1097c72..e9136af 100644
--- a/drivers/net/veth.c
+++ b/drivers/net/veth.c
@@ -170,7 +173,12 @@ static int veth_xmit(struct sk_buff *skb, struct net_device *dev)
if (skb->len > (rcv->mtu + MTU_PAD))
goto rx_drop;
-
+
+ /* Zero out the time-stamp so that receiving code is forced
+ * to recalculate it.
+ */
+ skb->tstamp.tv64 = 0;
+
skb->pkt_type = PACKET_HOST;
skb->protocol = eth_type_trans(skb, rcv);
if (dev->features & NETIF_F_NO_CSUM)
Thanks,
Ben
--
Ben Greear <greearb@candelatech.com>
Candela Technologies Inc http://www.candelatech.com
^ permalink raw reply related
* [PATCH 2/2 v2] MPC52xx FEC: be more conservative when setting MII_SPEED register
From: Wolfgang Denk @ 2009-07-16 21:42 UTC (permalink / raw)
To: linuxppc-dev; +Cc: Wolfgang Denk, Grant Likely, Kumar Gala, netdev
In-Reply-To: <1247671133-12148-1-git-send-email-wd@denx.de>
This patch adds error checking and prevents clobbering unrelated bits
(reserved bits or the DIS_PREAMBLE bit) when writing the MII_SPEED
register on MPC52xx systems.
Signed-off-by: Wolfgang Denk <wd@denx.de>
Cc: Grant Likely <grant.likely@secretlab.ca>
Cc: Kumar Gala <galak@kernel.crashing.org>
Cc: <netdev@vger.kernel.org>
---
drivers/net/fec_mpc52xx.c | 2 +-
drivers/net/fec_mpc52xx_phy.c | 21 ++++++++++++++++++---
2 files changed, 19 insertions(+), 4 deletions(-)
diff --git a/drivers/net/fec_mpc52xx.c b/drivers/net/fec_mpc52xx.c
index cc78633..b69d440 100644
--- a/drivers/net/fec_mpc52xx.c
+++ b/drivers/net/fec_mpc52xx.c
@@ -639,7 +639,7 @@ static void mpc52xx_fec_hw_init(struct net_device *dev)
/* set phy speed.
* this can't be done in phy driver, since it needs to be called
* before fec stuff (even on resume) */
- out_be32(&fec->mii_speed, priv->mdio_speed);
+ clrsetbits_be32(&fec->mii_speed, 0x7E, priv->mdio_speed);
}
/**
diff --git a/drivers/net/fec_mpc52xx_phy.c b/drivers/net/fec_mpc52xx_phy.c
index 31e6d62..4c33dc5 100644
--- a/drivers/net/fec_mpc52xx_phy.c
+++ b/drivers/net/fec_mpc52xx_phy.c
@@ -70,7 +70,7 @@ static int mpc52xx_fec_mdio_probe(struct of_device *of,
struct mpc52xx_fec_mdio_priv *priv;
struct resource res = {};
int err;
- int i;
+ int i, clock, speed;
bus = mdiobus_alloc();
if (bus == NULL)
@@ -105,8 +105,23 @@ static int mpc52xx_fec_mdio_probe(struct of_device *of,
dev_set_drvdata(dev, bus);
/* set MII speed */
- out_be32(&priv->regs->mii_speed,
- ((mpc5xxx_get_bus_frequency(of->node) >> 20) / 5) << 1);
+ clock = mpc5xxx_get_bus_frequency(of->node);
+ if (!clock) {
+ dev_err(&of->dev, "could not determine IPS/IPB clock\n");
+ goto out_unmap;
+ }
+
+ /* scale for a MII clock <= 2.5 MHz */
+ speed = (clock + 2499999) / 2500000;
+
+ /* only 6 bits (25:30) available for MII speed */
+ if (speed > 0x3F) {
+ speed = 0x3F;
+ dev_err(&of->dev, "MII clock (%d Hz) exceeds max (2.5 MHz)\n",
+ clock / speed);
+ }
+
+ clrsetbits_be32(&priv->regs->mii_speed, 0x7E, speed << 1);
err = of_mdiobus_register(bus, np);
if (err)
--
1.6.0.6
^ permalink raw reply related
* [PATCH 1/2 v4] fs_enet/mii-fec.c: fix MII speed calculation
From: Wolfgang Denk @ 2009-07-16 21:42 UTC (permalink / raw)
To: linuxppc-dev; +Cc: Wolfgang Denk, Grant Likely, Kumar Gala, netdev
In-Reply-To: <1247671133-12148-1-git-send-email-wd@denx.de>
The MII speed calculation was based on the CPU clock (ppc_proc_freq),
but for MPC512x we must use the bus clock instead.
This patch makes it use the correct clock and makes sure we don't
clobber reserved bits in the MII_SPEED register.
Signed-off-by: Wolfgang Denk <wd@denx.de>
Cc: Grant Likely <grant.likely@secretlab.ca>
Cc: Kumar Gala <galak@kernel.crashing.org>
Cc: <netdev@vger.kernel.org>
Signed-off-by: Wolfgang Denk <wd@denx.de>
---
drivers/net/fs_enet/mii-fec.c | 35 +++++++++++++++++++++++++++++++----
1 files changed, 31 insertions(+), 4 deletions(-)
diff --git a/drivers/net/fs_enet/mii-fec.c b/drivers/net/fs_enet/mii-fec.c
index 75a0999..62b2d7a 100644
--- a/drivers/net/fs_enet/mii-fec.c
+++ b/drivers/net/fs_enet/mii-fec.c
@@ -103,11 +103,11 @@ static int fs_enet_fec_mii_reset(struct mii_bus *bus)
static int __devinit fs_enet_mdio_probe(struct of_device *ofdev,
const struct of_device_id *match)
{
- struct device_node *np = NULL;
struct resource res;
struct mii_bus *new_bus;
struct fec_info *fec;
- int ret = -ENOMEM, i;
+ int (*get_bus_freq)(struct device_node *) = match->data;
+ int ret = -ENOMEM, clock, speed;
new_bus = mdiobus_alloc();
if (!new_bus)
@@ -133,13 +133,34 @@ static int __devinit fs_enet_mdio_probe(struct of_device *ofdev,
if (!fec->fecp)
goto out_fec;
- fec->mii_speed = ((ppc_proc_freq + 4999999) / 5000000) << 1;
+ if (get_bus_freq) {
+ clock = get_bus_freq(ofdev->node);
+
+ if (!clock) {
+ dev_err(&ofdev->dev, "could not determine IPS/IPB clock\n");
+ goto out_unmap_regs;
+ }
+ } else
+ clock = ppc_proc_freq;
+
+ /* scale for a MII clock <= 2.5 MHz */
+ speed = (clock + 2499999) / 2500000;
+
+ /* only 6 bits (25:30) available for MII speed */
+ if (speed > 0x3F) {
+ speed = 0x3F;
+ dev_err(&ofdev->dev,
+ "MII clock (%d Hz) exceeds max (2.5 MHz)\n",
+ clock / speed);
+ }
+
+ fec->mii_speed = speed << 1;
setbits32(&fec->fecp->fec_r_cntrl, FEC_RCNTRL_MII_MODE);
setbits32(&fec->fecp->fec_ecntrl, FEC_ECNTRL_PINMUX |
FEC_ECNTRL_ETHER_EN);
out_be32(&fec->fecp->fec_ievent, FEC_ENET_MII);
- out_be32(&fec->fecp->fec_mii_speed, fec->mii_speed);
+ clrsetbits_be32(&fec->fecp->fec_mii_speed, 0x7E, fec->mii_speed);
new_bus->phy_mask = ~0;
new_bus->irq = kmalloc(sizeof(int) * PHY_MAX_ADDR, GFP_KERNEL);
@@ -188,6 +209,12 @@ static struct of_device_id fs_enet_mdio_fec_match[] = {
{
.compatible = "fsl,pq1-fec-mdio",
},
+#if defined(CONFIG_PPC_MPC512x)
+ {
+ .compatible = "fsl,mpc5121-fec-mdio",
+ .data = mpc5xxx_get_bus_frequency,
+ },
+#endif
{},
};
--
1.6.0.6
^ permalink raw reply related
* Re: Debounce code vs. dma_sync_single_range_for_cpu() and e100 driver.
From: Jeff Kirsher @ 2009-07-16 22:27 UTC (permalink / raw)
To: David Miller
Cc: khc, netdev, jesse.brandeburg, bruce.w.allan,
peter.p.waskiewicz.jr, john.ronciak, e1000-devel
In-Reply-To: <20090714.140507.211725964.davem@davemloft.net>
On Tue, Jul 14, 2009 at 2:05 PM, David Miller<davem@davemloft.net> wrote:
> From: Krzysztof Halasa <khc@pm.waw.pl>
> Date: Tue, 14 Jul 2009 23:01:54 +0200
>
>> Maybe you apply the workaround for 2.6.31 and I (or someone) will
>> convert e100 to coherent allocs for packet descriptors, post-31?
>
> I think that's a good plan.
>
> Will give a few days for Intel folks to chime in before applying
> your patch for 2.6.31, but otherwise that's my plan.
Acked-by: Jeff Kirsher <jeffrey.t.kirsher@intel.com>
--
Cheers,
Jeff
^ permalink raw reply
* Re: [PATCH 1/2 v3] fs_enet/mii-fec.c: fix MII speed calculation
From: Grant Likely @ 2009-07-16 22:37 UTC (permalink / raw)
To: Wolfgang Denk; +Cc: linuxppc-dev, Kumar Gala, netdev
In-Reply-To: <20090716212129.70710832E416@gemini.denx.de>
On Thu, Jul 16, 2009 at 3:21 PM, Wolfgang Denk<wd@denx.de> wrote:
> Dear Grant Likely,
>
> In message <fa686aa40907151017n76524708tdb028689adad4b5f@mail.gmail.com> you wrote:
>> On Wed, Jul 15, 2009 at 9:18 AM, Wolfgang Denk<wd@denx.de> wrote:
>> > The MII speed calculation was based on the CPU clock (ppc_proc_freq),
>> > but for MPC512x we must use the bus clock instead.
>> >
>> > This patch makes it use the correct clock and makes sure we don't
>> > clobber reserved bits in the MII_SPEED register.
> ...
>> Drop the common code bit. The 5200 and 5121 are different devices and
>> it is a tiny bit of code. I don't think there is any benefit to
>> having it as a common function. Just roll the get_mii_speed function
>> in the mii-fec driver itself.
>
> I don't like to see the code repeated - it makes maintenance harder
> and increases the memory footprint. But if you like it that way I'll
> do that.
Neither do I, but in this case has some mitigating factors. diff stat
is interesting:
Old:
arch/powerpc/include/asm/mpc5xxx.h | 10 +++++++++
arch/powerpc/sysdev/mpc5xxx_clocks.c | 37 ++++++++++++++++++++++++++++++++++
drivers/net/fs_enet/mii-fec.c | 13 +++++++++--
drivers/net/fec_mpc52xx.c | 2 +-
drivers/net/fec_mpc52xx_phy.c | 6 ++++--
5 files changed, 62 insertions(+), 6 deletions(-)
New:
drivers/net/fs_enet/mii-fec.c | 35 +++++++++++++++++++++++++++++++----
drivers/net/fec_mpc52xx.c | 2 +-
drivers/net/fec_mpc52xx_phy.c | 21 ++++++++++++++++++---
3 files changed, 50 insertions(+), 8 deletions(-)
If the two devices were somewhat related then my opinion might be
different. However the combination of the tiny amount of calculation
code, the drivers being kept completely separate (or at least as
separate as they were before), the smaller code impact, and the lower
driver complexity (because the calculation code is inline instead of
in a different file) makes me like the second approach is better.
g.
--
Grant Likely, B.Sc., P.Eng.
Secret Lab Technologies Ltd.
^ permalink raw reply
* Re: [PATCH 1/2 v4] fs_enet/mii-fec.c: fix MII speed calculation
From: Grant Likely @ 2009-07-16 22:44 UTC (permalink / raw)
To: Wolfgang Denk; +Cc: linuxppc-dev, Kumar Gala, netdev
In-Reply-To: <1247780546-4426-1-git-send-email-wd@denx.de>
On Thu, Jul 16, 2009 at 3:42 PM, Wolfgang Denk<wd@denx.de> wrote:
> The MII speed calculation was based on the CPU clock (ppc_proc_freq),
> but for MPC512x we must use the bus clock instead.
>
> This patch makes it use the correct clock and makes sure we don't
> clobber reserved bits in the MII_SPEED register.
>
> Signed-off-by: Wolfgang Denk <wd@denx.de>
> Cc: Grant Likely <grant.likely@secretlab.ca>
> Cc: Kumar Gala <galak@kernel.crashing.org>
> Cc: <netdev@vger.kernel.org>
Looks good to me. Thanks for the work!
I assume this is tested. I have not tested this on my board, and I've
got one question below, but otherwise I think I can say....
Acked-by: Grant Likely <grant.likely@secretlab.ca>
> - fec->mii_speed = ((ppc_proc_freq + 4999999) / 5000000) << 1;
> + if (get_bus_freq) {
> + clock = get_bus_freq(ofdev->node);
> +
> + if (!clock) {
> + dev_err(&ofdev->dev, "could not determine IPS/IPB clock\n");
> + goto out_unmap_regs;
> + }
> + } else
> + clock = ppc_proc_freq;
> +
> + /* scale for a MII clock <= 2.5 MHz */
> + speed = (clock + 2499999) / 2500000;
The calculation has changed here for non mpc5121 users. Shouldn't the
"clock = ppc_proc_freq;" line above be "clock = ppc_proc_freq / 2;"?
Or was this also a bug in the original driver?
g.
--
Grant Likely, B.Sc., P.Eng.
Secret Lab Technologies Ltd.
^ permalink raw reply
* Re: [PATCH 2/2 v2] MPC52xx FEC: be more conservative when setting MII_SPEED register
From: Grant Likely @ 2009-07-16 22:48 UTC (permalink / raw)
To: Wolfgang Denk; +Cc: linuxppc-dev, netdev
In-Reply-To: <1247780546-4426-2-git-send-email-wd@denx.de>
On Thu, Jul 16, 2009 at 3:42 PM, Wolfgang Denk<wd@denx.de> wrote:
> This patch adds error checking and prevents clobbering unrelated bits
> (reserved bits or the DIS_PREAMBLE bit) when writing the MII_SPEED
> register on MPC52xx systems.
>
> Signed-off-by: Wolfgang Denk <wd@denx.de>
> Cc: Grant Likely <grant.likely@secretlab.ca>
> Cc: Kumar Gala <galak@kernel.crashing.org>
> Cc: <netdev@vger.kernel.org>
Mostly good. One comment below. When it's resolved, feel free to add
my acked-by line. Thanks for getting this done.
> @@ -105,8 +105,23 @@ static int mpc52xx_fec_mdio_probe(struct of_device *of,
> dev_set_drvdata(dev, bus);
>
> /* set MII speed */
> - out_be32(&priv->regs->mii_speed,
> - ((mpc5xxx_get_bus_frequency(of->node) >> 20) / 5) << 1);
> + clock = mpc5xxx_get_bus_frequency(of->node);
> + if (!clock) {
> + dev_err(&of->dev, "could not determine IPS/IPB clock\n");
> + goto out_unmap;
> + }
Just thought of something. If it cannot find the clock, then wouldn't
it be better to just use the maximum divider and print a warning
instead of bailing completely? This goes for the other patch as well.
> +
> + /* scale for a MII clock <= 2.5 MHz */
> + speed = (clock + 2499999) / 2500000;
> +
> + /* only 6 bits (25:30) available for MII speed */
> + if (speed > 0x3F) {
> + speed = 0x3F;
> + dev_err(&of->dev, "MII clock (%d Hz) exceeds max (2.5 MHz)\n",
> + clock / speed);
> + }
> +
> + clrsetbits_be32(&priv->regs->mii_speed, 0x7E, speed << 1);
>
> err = of_mdiobus_register(bus, np);
> if (err)
> --
> 1.6.0.6
>
>
--
Grant Likely, B.Sc., P.Eng.
Secret Lab Technologies Ltd.
^ permalink raw reply
* [PATCH] sky2: revert shutdown changes
From: Stephen Hemminger @ 2009-07-16 23:20 UTC (permalink / raw)
To: David Miller; +Cc: netdev
The commit changes to shutdown path broke startup on some systems.
revert commit c0bad0f2e4366d5bbfe0c4a7a80bca8f4b05272b
Signed-off-by: Stephen Hemminger <shemminger@vyatta.com>
---
drivers/net/sky2.c | 9 +--------
1 file changed, 1 insertion(+), 8 deletions(-)
--- a/drivers/net/sky2.c 2009-07-07 18:06:44.485898870 -0700
+++ b/drivers/net/sky2.c 2009-07-07 18:14:10.587041228 -0700
@@ -1151,14 +1151,7 @@ stopped:
/* reset the Rx prefetch unit */
sky2_write32(hw, Y2_QADDR(rxq, PREF_UNIT_CTRL), PREF_UNIT_RST_SET);
-
- /* Reset the RAM Buffer receive queue */
- sky2_write8(hw, RB_ADDR(rxq, RB_CTRL), RB_RST_SET);
-
- /* Reset Rx MAC FIFO */
- sky2_write8(hw, SK_REG(sky2->port, RX_GMF_CTRL_T), GMF_RST_SET);
-
- sky2_read8(hw, B0_CTST);
+ mmiowb();
}
/* Clean out receive buffer area, assumes receiver hardware stopped */
^ permalink raw reply
* Re: [PATCH] sky2: Avoid races in sky2_down
From: Stephen Hemminger @ 2009-07-16 23:21 UTC (permalink / raw)
To: Mike McCormack; +Cc: netdev
In-Reply-To: <392fb48f0907112228v52624339x4f6c418ed0ee07a5@mail.gmail.com>
On Sun, 12 Jul 2009 14:28:04 +0900
Mike McCormack <mikem@ring3k.org> wrote:
> Hi Stephen,
>
> Resending with sign off. (You may have this in your tree already, but
> just in case...)
> I ran some overnight tests with this patch in, and my machine manages
> to stay up all night, where it crashed within minutes before.
>
> Mike
>
> ---
>
> Reset rx chain before trying to drain it.
> Shut interrupts off last, incase there's something to report.
>
> Signed-off-by: Mike McCormack <mikem@ring3k.org>
Acked-by: Stephen Hemminger <shemminger@vyatta.com>
^ permalink raw reply
* Bad sky2 interrupt handling?
From: Jesse Barnes @ 2009-07-16 23:25 UTC (permalink / raw)
To: Stephen Hemminger, netdev
I was debugging what I thought was a graphics driver problem today (some
page flipping code I'm working on was only flipping at about 10Hz
rather than ~60Hz) but it appears it's actually due to a bad
interaction with the Marvell 88E8036 controller on this machine.
MSI fails on this box (haven't looked too much at why yet), so the i915
driver shares an interrupt with USB, firewire, sdhci and the NIC.
Is sky2 the wrong driver to be using here? Or is there some way of
reducing its overhead when (presumably) it doesn't have anything to do?
--
Jesse Barnes, Intel Open Source Technology Center
^ 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