* Re: [PATCHv2] can: ti hecc module : add platform specific initialization callback.
From: Marc Kleine-Budde @ 2010-02-25 18:00 UTC (permalink / raw)
To: Sriramakrishnan
Cc: socketcan-core-0fE9KPoRgkgATYTw5x5z8w,
netdev-u79uwXL29TY76Z2rM5mHXA
In-Reply-To: <1267118802-19263-1-git-send-email-srk-l0cyMroinI0@public.gmane.org>
[-- Attachment #1.1: Type: text/plain, Size: 3784 bytes --]
Sriramakrishnan wrote:
> CAN module on AM3517 requires programming of IO expander as part
> of init sequence - to enable CAN PHY. Added platform specific
> callback to handle phy control(switch on /off).
>
> Signed-off-by: Sriramakrishnan <srk-l0cyMroinI0@public.gmane.org>
looks good, just minor nitpicking inline
Cheers, Marc
> ---
> Modified as per review comments received.
>
> drivers/net/can/ti_hecc.c | 15 ++++++++++++++-
> include/linux/can/platform/ti_hecc.h | 3 ++-
> 2 files changed, 16 insertions(+), 2 deletions(-)
>
> diff --git a/drivers/net/can/ti_hecc.c b/drivers/net/can/ti_hecc.c
> index df27d82..871a3fe 100644
> --- a/drivers/net/can/ti_hecc.c
> +++ b/drivers/net/can/ti_hecc.c
> @@ -28,9 +28,11 @@
> * .mbx_offset = 0x2000,
> * .int_line = 0,
> * .revision = 1,
> + * .transceiver_switch = hecc_phy_control,
> * };
> *
> - * Please see include/can/platform/ti_hecc.h for description of above fields
> + * Please see include/linux/can/platform/ti_hecc.h for description of
> + * above fields.
> *
> */
>
> @@ -220,6 +222,7 @@ struct ti_hecc_priv {
> u32 tx_head;
> u32 tx_tail;
> u32 rx_next;
> + void (*transceiver_switch)(int);
> };
>
> static inline int get_tx_head_mb(struct ti_hecc_priv *priv)
> @@ -317,6 +320,13 @@ static int ti_hecc_set_btc(struct ti_hecc_priv *priv)
> return 0;
> }
>
> +static void ti_hecc_transceiver_switch(const struct ti_hecc_priv *priv,
> + int on)
> +{
> + if (priv->transceiver_switch)
> + priv->transceiver_switch(on);
> +}
> +
> static void ti_hecc_reset(struct net_device *ndev)
> {
> u32 cnt;
> @@ -824,6 +834,7 @@ static int ti_hecc_open(struct net_device *ndev)
> return err;
> }
>
> + ti_hecc_transceiver_switch(priv, 1);
> ti_hecc_start(ndev);
> napi_enable(&priv->napi);
> netif_start_queue(ndev);
> @@ -840,6 +851,7 @@ static int ti_hecc_close(struct net_device *ndev)
> ti_hecc_stop(ndev);
> free_irq(ndev->irq, ndev);
> close_candev(ndev);
> + ti_hecc_transceiver_switch(priv, 0);
nitpick: it's not symetric to the _start function.
>
> return 0;
> }
> @@ -901,6 +913,7 @@ static int ti_hecc_probe(struct platform_device *pdev)
> priv->hecc_ram_offset = pdata->hecc_ram_offset;
> priv->mbx_offset = pdata->mbx_offset;
> priv->int_line = pdata->int_line;
> + priv->transceiver_switch = pdata->transceiver_switch;
>
> priv->can.bittiming_const = &ti_hecc_bittiming_const;
> priv->can.do_set_mode = ti_hecc_do_set_mode;
> diff --git a/include/linux/can/platform/ti_hecc.h b/include/linux/can/platform/ti_hecc.h
> index 4688c7b..825bc6a 100644
> --- a/include/linux/can/platform/ti_hecc.h
> +++ b/include/linux/can/platform/ti_hecc.h
> @@ -23,6 +23,7 @@
> * @mbx_offset: Mailbox RAM offset
> * @int_line: Interrupt line to use - 0 or 1
> * @version: version for future use
> + * @transceiver_switch platform specific callback fn for transceiver control
^^
nitpick:
these are spaces, but the other lines use tabs
> *
> * Platform data structure to get all platform specific settings.
> * this structure also accounts the fact that the IP may have different
> @@ -35,6 +36,6 @@ struct ti_hecc_platform_data {
> u32 mbx_offset;
> u32 int_line;
> u32 version;
> + void (*transceiver_switch) (int);
> };
>
> -
--
Pengutronix e.K. | Marc Kleine-Budde |
Industrial Linux Solutions | Phone: +49-231-2826-924 |
Vertretung West/Dortmund | Fax: +49-5121-206917-5555 |
Amtsgericht Hildesheim, HRA 2686 | http://www.pengutronix.de |
[-- Attachment #1.2: OpenPGP digital signature --]
[-- Type: application/pgp-signature, Size: 260 bytes --]
[-- Attachment #2: Type: text/plain, Size: 188 bytes --]
_______________________________________________
Socketcan-core mailing list
Socketcan-core-0fE9KPoRgkgATYTw5x5z8w@public.gmane.org
https://lists.berlios.de/mailman/listinfo/socketcan-core
^ permalink raw reply
* Re: Gianfar driver failing on MPC8641D based board
From: Anton Vorontsov @ 2010-02-25 17:49 UTC (permalink / raw)
To: Martyn Welch
Cc: linuxppc-dev list, netdev, linux-kernel, Sandeep Gopalpet, davem,
Kumar Gala
In-Reply-To: <20100225165141.GA9686@oksana.dev.rtsoft.ru>
On Thu, Feb 25, 2010 at 07:51:41PM +0300, Anton Vorontsov wrote:
> On Thu, Feb 25, 2010 at 04:46:54PM +0000, Martyn Welch wrote:
> [...]
> > > nfs: server 192.168.0.1 not responding, still trying
> > >
> >
> > Further testing has shown that this isn't restricted to warm reboots, it
> > happens from cold as well. In addition, the exact timing of the failure
> > seems to vary, some boots have got further before failing.
>
> Unfortunately I don't have any 8641 boards near me, so I can't
> debug this myself. Though, I tested gianfar on MPC8568E-MDS with
> 2.6.33 kernel, and it seems to work just fine.
>
> I see you use SMP. Can you try to turn it off? If that will fix
> the issue, then it'll be a good data point.
>
> Meanwhile, I'll try SMP kernel on MPC8568 (UP), and let you
> know the results.
Nope, no luck. Can't trigger the issue. :-/
Tested with NFS boot, TCP and UDP netperf tests.
--
Anton Vorontsov
email: cbouatmailru@gmail.com
irc://irc.freenode.net/bd2
^ permalink raw reply
* Re: netfilter 00/08: netfilter update
From: Patrick McHardy @ 2010-02-25 17:35 UTC (permalink / raw)
To: Shan Wei; +Cc: davem, netdev, netfilter-devel
In-Reply-To: <4B85D42E.5030304@cn.fujitsu.com>
Shan Wei wrote:
> Patrick McHardy wrote, at 02/25/2010 01:49 AM:
>> Hi Dave,
>>
>> following is the probably final netfilter update for 2.6.34, containing:
>
> 2.6.33 is just released, and Linus Torvalds said that
> this merger window period is about ten-to-twelve days.
>
> Is it enough for us to review patch-set with title "IPv6:netfilter: defragment"?
> Is there hope to merger this patch-set for 2.6.34?
The networking merge window closes earlier than that. These
patches are quite small however and almost classify as bugfixes,
so I'm fine with them if you send them over very quickly and
Dave doesn't object.
^ permalink raw reply
* Re: [RFC PATCH net-next 1/5]IPv6:netfilter: defrag:Introduce net namespace
From: Patrick McHardy @ 2010-02-25 17:34 UTC (permalink / raw)
To: Shan Wei; +Cc: Alexey Dobriyan, netdev
In-Reply-To: <4B8660AD.7030308@cn.fujitsu.com>
Shan Wei wrote:
> Patrick McHardy wrote, at 02/24/2010 10:05 PM:
>> Shan Wei wrote:
>>> Alexey Dobriyan wrote, at 02/24/2010 03:48 PM:
>>>>> - .procname = "nf_conntrack_frag6_timeout",
>>>>> - .data = &nf_init_frags.timeout,
>>>>> - .maxlen = sizeof(unsigned int),
>>>>> - .mode = 0644,
>>>>> - .proc_handler = proc_dointvec_jiffies,
>>>> Why are you removing sysctls?
>>> Because, after introduced net namespace, we can use net->ipv6.frags to
>>> manage IPv6 conntrack fragment queue instead of nf_init_frags.
>>> And sysctls of ip6frag_low_thresh, ip6frag_time and ip6frag_high_thresh
>>> also can control IPv6 conntrack fragment queue.
>>>
>>> So, private member of nf_init_frags becomes redundant, and remove these sysctls.
>> You can't simply remove them without a warning, people might be
>> using them.
>
> How to provide a warning to user?
> How about handle these sysctl ABIs like this:
>
> s1) Retain these sysctls and refer .data to appropriate member of frags of init_net.
> Take nf_conntrack_frag6_timeout for example, .data = &init_net.ipv6.frags.timeout.
I'd suggest to refer to the proper namespace, check out
net/netfilter/nf_conntrack_standalone.c for an example.
> s2) When register sysctls of conntrack ipv6 protocol in nf_ct_l3proto_register_sysctl(),
> print a waring like this.
> "nf_conntrack_frag6_timeout and ip6frag_time, nf_conntrack_frag6_low_thresh and ip6frag_low_thresh,
> nf_conntrack_frag6_high_thresh and ip6frag_high_thresh, the three sets are equivalent.
> nf_conntrack_frag6_timeout is just an alias for ip6frag_time. The former Parameters of IPv6 conntrack
> will be removed in the future, please use the latter ones of IPv6."
>
> s3) Describe these removable sysctl ABIs in Documentation/feature-removal-schedule.txt
This sounds fine.
^ permalink raw reply
* [PATCHv2] can: ti hecc module : add platform specific initialization callback.
From: Sriramakrishnan @ 2010-02-25 17:26 UTC (permalink / raw)
To: socketcan-core, netdev; +Cc: anantgole, Sriramakrishnan
CAN module on AM3517 requires programming of IO expander as part
of init sequence - to enable CAN PHY. Added platform specific
callback to handle phy control(switch on /off).
Signed-off-by: Sriramakrishnan <srk@ti.com>
---
Modified as per review comments received.
drivers/net/can/ti_hecc.c | 15 ++++++++++++++-
include/linux/can/platform/ti_hecc.h | 3 ++-
2 files changed, 16 insertions(+), 2 deletions(-)
diff --git a/drivers/net/can/ti_hecc.c b/drivers/net/can/ti_hecc.c
index df27d82..871a3fe 100644
--- a/drivers/net/can/ti_hecc.c
+++ b/drivers/net/can/ti_hecc.c
@@ -28,9 +28,11 @@
* .mbx_offset = 0x2000,
* .int_line = 0,
* .revision = 1,
+ * .transceiver_switch = hecc_phy_control,
* };
*
- * Please see include/can/platform/ti_hecc.h for description of above fields
+ * Please see include/linux/can/platform/ti_hecc.h for description of
+ * above fields.
*
*/
@@ -220,6 +222,7 @@ struct ti_hecc_priv {
u32 tx_head;
u32 tx_tail;
u32 rx_next;
+ void (*transceiver_switch)(int);
};
static inline int get_tx_head_mb(struct ti_hecc_priv *priv)
@@ -317,6 +320,13 @@ static int ti_hecc_set_btc(struct ti_hecc_priv *priv)
return 0;
}
+static void ti_hecc_transceiver_switch(const struct ti_hecc_priv *priv,
+ int on)
+{
+ if (priv->transceiver_switch)
+ priv->transceiver_switch(on);
+}
+
static void ti_hecc_reset(struct net_device *ndev)
{
u32 cnt;
@@ -824,6 +834,7 @@ static int ti_hecc_open(struct net_device *ndev)
return err;
}
+ ti_hecc_transceiver_switch(priv, 1);
ti_hecc_start(ndev);
napi_enable(&priv->napi);
netif_start_queue(ndev);
@@ -840,6 +851,7 @@ static int ti_hecc_close(struct net_device *ndev)
ti_hecc_stop(ndev);
free_irq(ndev->irq, ndev);
close_candev(ndev);
+ ti_hecc_transceiver_switch(priv, 0);
return 0;
}
@@ -901,6 +913,7 @@ static int ti_hecc_probe(struct platform_device *pdev)
priv->hecc_ram_offset = pdata->hecc_ram_offset;
priv->mbx_offset = pdata->mbx_offset;
priv->int_line = pdata->int_line;
+ priv->transceiver_switch = pdata->transceiver_switch;
priv->can.bittiming_const = &ti_hecc_bittiming_const;
priv->can.do_set_mode = ti_hecc_do_set_mode;
diff --git a/include/linux/can/platform/ti_hecc.h b/include/linux/can/platform/ti_hecc.h
index 4688c7b..825bc6a 100644
--- a/include/linux/can/platform/ti_hecc.h
+++ b/include/linux/can/platform/ti_hecc.h
@@ -23,6 +23,7 @@
* @mbx_offset: Mailbox RAM offset
* @int_line: Interrupt line to use - 0 or 1
* @version: version for future use
+ * @transceiver_switch platform specific callback fn for transceiver control
*
* Platform data structure to get all platform specific settings.
* this structure also accounts the fact that the IP may have different
@@ -35,6 +36,6 @@ struct ti_hecc_platform_data {
u32 mbx_offset;
u32 int_line;
u32 version;
+ void (*transceiver_switch) (int);
};
-
--
1.6.2.4
^ permalink raw reply related
* Re: Gianfar driver failing on MPC8641D based board
From: Anton Vorontsov @ 2010-02-25 16:51 UTC (permalink / raw)
To: Martyn Welch
Cc: linuxppc-dev list, netdev, linux-kernel, Sandeep Gopalpet, davem,
Kumar Gala
In-Reply-To: <4B86A97E.6050509@ge.com>
On Thu, Feb 25, 2010 at 04:46:54PM +0000, Martyn Welch wrote:
[...]
> > nfs: server 192.168.0.1 not responding, still trying
> >
>
> Further testing has shown that this isn't restricted to warm reboots, it
> happens from cold as well. In addition, the exact timing of the failure
> seems to vary, some boots have got further before failing.
Unfortunately I don't have any 8641 boards near me, so I can't
debug this myself. Though, I tested gianfar on MPC8568E-MDS with
2.6.33 kernel, and it seems to work just fine.
I see you use SMP. Can you try to turn it off? If that will fix
the issue, then it'll be a good data point.
Meanwhile, I'll try SMP kernel on MPC8568 (UP), and let you
know the results.
Thanks,
--
Anton Vorontsov
email: cbouatmailru@gmail.com
irc://irc.freenode.net/bd2
^ permalink raw reply
* Re: Gianfar driver failing on MPC8641D based board
From: Martyn Welch @ 2010-02-25 16:46 UTC (permalink / raw)
To: linuxppc-dev list, netdev, linux-kernel
Cc: Anton Vorontsov, Sandeep Gopalpet, davem
In-Reply-To: <4B865176.7080806@ge.com>
Martyn Welch wrote:
> Martyn Welch wrote:
>
>> I have recently attempted to boot an 8641D based board from an NFS root.
>> The boot process grinds to a halt not long after the first access of the
>> NFS root and I receive multiple "nfs: server 192.168.0.1 not responding,
>> still trying" messages. Wireshark suggests that there is no further
>> traffic from this board at this point on. The NFS server seems to
>> eventually try sending duplicate packets it's already sent, which
>> results in "nfs: server 192.168.0.1 OK" messages, but the "not
>> responding" messages resume with no further traffic from the board.
>>
>> I am able to boot to a ramdisk fine and the network seems to work -
>> though I haven't really pushed the interface from it.
>>
>> I have attempted to git bisect, though I wasn't able to get much further
>> than discovering the problem was introduced in the 2.6.33 merge window -
>> at which point the gianfar network driver fails to compile (I have tried
>> to git bisect skip many, many times to no avail).
>>
>> NFS booting fails for this board on todays linux-next, the master branch
>> of Kumar's PPC tree and the head of the main tree. I have also been able
>> to NFS boot from a random x86 based board that I have, using the head of
>> the main tree and the linux-next tree.
>>
>> Copying the gianfar drivers from 2.6.32 into the head of the main tree
>> restores the correct behaviour and I'm able to NFS boot. I have heard
>> from others that the latest drivers work on 83xx and 85xx based boards,
>> but it seems to be broken on at least the 8641D.
>>
>> I can see there has been a fair amount of work done on the gianfar
>> driver, I assume that this is a bug introduced by the multiple queue
>> support, but I'm way out of my depth on this.
>>
>>
> I have just compiled 2.6.33 for the Freescale MPC8641_HPCN demo board
> and am having still experiencing the problems outlined in my previous
> email, though I have noticed that I tend to be able to boot from cold,
> but my boot fails on reboot. Hitting the reset button doesn't help, I
> need to actually power the machine on and off again for it to work.
>
> As before, I'm way out of my depth in this, any one have any ideas?
> Below is a dump of the failed boot process:
>
> U-Boot 2009.01-00181-gc1b7c70 (Jan 30 2009 - 11:17:31)
>
> Freescale PowerPC
> CPU:
> Core: E600 Core 0, Version: 0.2, (0x80040202)
> System: Unknown, Version: 2.0, (0x80900120)
> Clocks: CPU:1000 MHz, MPX: 400 MHz, DDR: 200 MHz, LBC: 25 MHz
> L2: Enabled
> Board: MPC8641HPCN, System ID: 0x10, System Version: 0x10, FPGA Version:
> 0x22
> I2C: ready
> DRAM: DDR: 1 GB
> FLASH: 8 MB
> Invalid ID (ff ff ff ff)
> Scanning PCI bus 01
> PCI-EXPRESS 1 on bus 00 - 02
> PCI-EXPRESS 2 on bus 03 - 03
> Video: No radeon video card found!
> In: serial
> Out: serial
> Err: serial
> SCSI: AHCI 0001.0000 32 slots 4 ports 3 Gbps 0xf impl IDE mode
> flags: ncq ilck pm led clo pmp pio slum part
> scanning bus for devices...
> Net: eTSEC1, eTSEC2, eTSEC3, eTSEC4
> => tftp 4000000 hpcn/uImage-torvalds-linux-2.6
> Speed: 1000, full duplex
> Using eTSEC1 device
> TFTP from server 192.168.0.1; our IP address is 192.168.0.30
> Filename 'hpcn/uImage-torvalds-linux-2.6'.
> Load address: 0x4000000
> Loading: #################################################################
> #################################################################
> #######################################################
> done
> Bytes transferred = 2709050 (29563a hex)
> => tftp 5000000 hpcn/mpc8641_hpcn-torvalds-linux-2.6.dtb
> Speed: 1000, full duplex
> Using eTSEC1 device
> TFTP from server 192.168.0.1; our IP address is 192.168.0.30
> Filename 'hpcn/mpc8641_hpcn-torvalds-linux-2.6.dtb'.
> Load address: 0x5000000
> Loading: #
> done
> Bytes transferred = 11523 (2d03 hex)
> => setenv bootargs "root=/dev/nfs rw
> nfsroot=192.168.0.1:/tftpboot/hpcn/root/ i"
> => bootm 4000000 - 5000000
> WARNING: adjusting available memory to 10000000
> ## Booting kernel from Legacy Image at 04000000 ...
> Image Name: Linux-2.6.33-00001-gbaac35c
> Image Type: PowerPC Linux Kernel Image (gzip compressed)
> Data Size: 2708986 Bytes = 2.6 MB
> Load Address: 00000000
> Entry Point: 00000000
> Verifying Checksum ... OK
> ## Flattened Device Tree blob at 05000000
> Booting using the fdt blob at 0x5000000
> Uncompressing Kernel Image ... OK
> Loading Device Tree to 007fa000, end 007ffd02 ... OK
> Using MPC86xx HPCN machine description
> Total memory = 1024MB; using 2048kB for hash table (at cfe00000)
> Linux version 2.6.33-00001-gbaac35c (welchma@ES-J7S4D2J) (gcc version
> 4.1.2) #20
> CPU maps initialized for 1 thread per core
> bootconsole [udbg0] enabled
> setup_arch: bootmem
> mpc86xx_hpcn_setup_arch()
> Found FSL PCI host bridge at 0x00000000ffe08000. Firmware bus number: 0->2
> PCI host bridge /pcie@ffe08000 (primary) ranges:
> MEM 0x0000000080000000..0x000000009fffffff -> 0x0000000080000000
> IO 0x00000000ffc00000..0x00000000ffc0ffff -> 0x0000000000000000
> /pcie@ffe08000: PCICSRBAR @ 0xfff00000
> Found FSL PCI host bridge at 0x00000000ffe09000. Firmware bus number: 0->0
> PCI host bridge /pcie@ffe09000 ranges:
> MEM 0x00000000a0000000..0x00000000bfffffff -> 0x00000000a0000000
> IO 0x00000000ffc10000..0x00000000ffc1ffff -> 0x0000000000000000
> /pcie@ffe09000: PCICSRBAR @ 0xfff00000
> MPC86xx HPCN board from Freescale Semiconductor
> arch: exit
> Zone PFN ranges:
> DMA 0x00000000 -> 0x00030000
> Normal 0x00030000 -> 0x00030000
> HighMem 0x00030000 -> 0x00040000
> Movable zone start PFN for each node
> early_node_map[1] active PFN ranges
> 0: 0x00000000 -> 0x00040000
> PERCPU: Embedded 7 pages/cpu @c1003000 s7712 r8192 d12768 u65536
> pcpu-alloc: s7712 r8192 d12768 u65536 alloc=16*4096
> pcpu-alloc: [0] 0 [0] 1
> Built 1 zonelists in Zone order, mobility grouping on. Total pages: 260096
> Kernel command line: root=/dev/nfs rw
> nfsroot=192.168.0.1:/tftpboot/hpcn/root/ p
> PID hash table entries: 4096 (order: 2, 16384 bytes)
> Dentry cache hash table entries: 131072 (order: 7, 524288 bytes)
> Inode-cache hash table entries: 65536 (order: 6, 262144 bytes)
> Memory: 1030864k/1048576k available (5228k kernel code, 17004k reserved,
> 196k d)
> Kernel virtual memory layout:
> * 0xfffc1000..0xfffff000 : fixmap
> * 0xff800000..0xffc00000 : highmem PTEs
> * 0xff7da000..0xff800000 : early ioremap
> * 0xf1000000..0xff7da000 : vmalloc & ioremap
> SLUB: Genslabs=13, HWalign=32, Order=0-3, MinObjects=0, CPUs=2, Nodes=1
> Hierarchical RCU implementation.
> NR_IRQS:512 nr_irqs:512
> mpic: Setting up MPIC " MPIC " version 1.2 at ffe40000, max 2 CPUs
> mpic: ISU size: 256, shift: 8, mask: ff
> mpic: Initializing for 256 sources
> i8259 legacy interrupt controller initialized
> clocksource: timebase mult[2800000] shift[22] registered
> Console: colour dummy device 80x25
> Mount-cache hash table entries: 512
> mpic: requesting IPIs ...
> Processor 1 found.
> Brought up 2 CPUs
> NET: Registered protocol family 16
>
> PCI: Probing PCI hardware
> pci 0000:00:00.0: ignoring class b20 (doesn't match header type 01)
> pci 0000:00:00.0: PCI bridge to [bus 01-ff]
> pci 0000:02:1d.0: unsupported PM cap regs version (4)
> pci 0000:01:00.0: PCI bridge to [bus 02-ff] (subtractive decode)
> pci 0001:03:00.0: ignoring class b20 (doesn't match header type 01)
> pci 0001:03:00.0: PCI bridge to [bus 04-ff]
> pci 0000:01:00.0: PCI bridge to [bus 02-02]
> pci 0000:01:00.0: bridge window [io 0x1000-0x1fff]
> pci 0000:01:00.0: bridge window [mem 0x80000000-0x800fffff]
> pci 0000:01:00.0: bridge window [mem pref disabled]
> pci 0000:00:00.0: PCI bridge to [bus 01-02]
> pci 0000:00:00.0: bridge window [io 0x0000-0xffff]
> pci 0000:00:00.0: bridge window [mem 0x80000000-0x9fffffff]
> pci 0000:00:00.0: bridge window [mem pref disabled]
> pci 0000:00:00.0: enabling device (0106 -> 0107)
> pci 0001:03:00.0: PCI bridge to [bus 04-04]
> pci 0001:03:00.0: bridge window [io 0xfffee000-0xffffdfff]
> pci 0001:03:00.0: bridge window [mem 0xa0000000-0xbfffffff]
> pci 0001:03:00.0: bridge window [mem pref disabled]
> pci 0001:03:00.0: enabling device (0106 -> 0107)
> bio: create slab <bio-0> at 0
> vgaarb: loaded
> SCSI subsystem initialized
> usbcore: registered new interface driver usbfs
> usbcore: registered new interface driver hub
> usbcore: registered new device driver usb
> Advanced Linux Sound Architecture Driver Version 1.0.21.
> Switching to clocksource timebase
> NET: Registered protocol family 2
> IP route cache hash table entries: 32768 (order: 5, 131072 bytes)
> TCP established hash table entries: 131072 (order: 8, 1048576 bytes)
> TCP bind hash table entries: 65536 (order: 7, 524288 bytes)
> TCP: Hash tables configured (established 131072 bind 65536)
> TCP reno registered
> UDP hash table entries: 512 (order: 2, 16384 bytes)
> UDP-Lite hash table entries: 512 (order: 2, 16384 bytes)
> NET: Registered protocol family 1
> RPC: Registered udp transport module.
> RPC: Registered tcp transport module.
> RPC: Registered tcp NFSv4.1 backchannel transport module.
> audit: initializing netlink socket (disabled)
> type=2000 audit(0.144:1): initialized
> highmem bounce pool size: 64 pages
> Installing knfsd (copyright (C) 1996 okir@monad.swb.de).
> NTFS driver 2.1.29 [Flags: R/O].
> msgmni has been set to 1502
> alg: No test for stdrng (krng)
> io scheduler noop registered
> io scheduler deadline registered
> io scheduler cfq registered (default)
> Generic non-volatile memory driver v1.1
> Serial: 8250/16550 driver, 2 ports, IRQ sharing enabled
> serial8250.0: ttyS0 at MMIO 0xffe04500 (irq = 42) is a 16550A
> console [ttyS0] enabled, bootconsole disabled
> console [ttyS0] enabled, bootconsole disabled
> serial8250.0: ttyS1 at MMIO 0xffe04600 (irq = 28) is a 16550A
> brd: module loaded
> loop: module loaded
> nbd: registered device at major 43
> st: Version 20081215, fixed bufsize 32768, s/g segs 256
> ahci 0000:02:1f.1: AHCI 0001.0000 32 slots 4 ports 3 Gbps 0xf impl SATA mode
> ahci 0000:02:1f.1: flags: ncq sntf ilck pm led clo pmp pio slum part
> scsi0 : ahci
> scsi1 : ahci
> scsi2 : ahci
> scsi3 : ahci
> ata1: SATA max UDMA/133 abar m1024@0x80006000 port 0x80006100 irq 5
> ata2: SATA max UDMA/133 abar m1024@0x80006000 port 0x80006180 irq 5
> ata3: SATA max UDMA/133 abar m1024@0x80006000 port 0x80006200 irq 5
> ata4: SATA max UDMA/133 abar m1024@0x80006000 port 0x80006280 irq 5
> scsi4 : pata_ali
> scsi5 : pata_ali
> ata5: PATA max UDMA/133 cmd 0x1200 ctl 0x1208 bmdma 0x1220 irq 14
> ata6: PATA max UDMA/133 cmd 0x1210 ctl 0x1218 bmdma 0x1228 irq 14
> eth0: Gianfar Ethernet Controller Version 1.2, 00:e0:0c:00:00:01
> eth0: Running with NAPI enabled
> eth0: :RX BD ring size for Q[0]: 256
> eth0:TX BD ring size for Q[0]: 256
> eth1: Gianfar Ethernet Controller Version 1.2, 00:e0:0c:00:01:fd
> eth1: Running with NAPI enabled
> eth1: :RX BD ring size for Q[0]: 256
> eth1:TX BD ring size for Q[0]: 256
> eth2: Gianfar Ethernet Controller Version 1.2, 00:e0:0c:00:02:fd
> eth2: Running with NAPI enabled
> eth2: :RX BD ring size for Q[0]: 256
> eth2:TX BD ring size for Q[0]: 256
> eth3: Gianfar Ethernet Controller Version 1.2, 00:e0:0c:00:03:fd
> eth3: Running with NAPI enabled
> eth3: :RX BD ring size for Q[0]: 256
> eth3:TX BD ring size for Q[0]: 256
> Freescale PowerQUICC MII Bus: probed
> Freescale PowerQUICC MII Bus: probed
> Freescale PowerQUICC MII Bus: probed
> Freescale PowerQUICC MII Bus: probed
> usbmon: debugfs is not available
> ehci_hcd: USB 2.0 'Enhanced' Host Controller (EHCI) Driver
> ehci_hcd 0000:02:1c.3: EHCI Host Controller
> ehci_hcd 0000:02:1c.3: new USB bus registered, assigned bus number 1
> ehci_hcd 0000:02:1c.3: debug port 1
> ehci_hcd 0000:02:1c.3: Enabling legacy PCI PM
> ehci_hcd 0000:02:1c.3: irq 11, io mem 0x80003000
> ehci_hcd 0000:02:1c.3: USB 2.0 started, EHCI 1.00
> hub 1-0:1.0: USB hub found
> hub 1-0:1.0: 8 ports detected
> ohci_hcd: USB 1.1 'Open' Host Controller (OHCI) Driver
> ohci_hcd 0000:02:1c.0: OHCI Host Controller
> ata5.00: ATAPI: SONY DVD RW AW-Q170A, 1.73, max UDMA/66
> ata5.00: WARNING: ATAPI DMA disabled for reliability issues. It can be
> enabled
> ata5.00: WARNING: via pata_ali.atapi_dma modparam or corresponding sysfs
> node.
> ata5.00: configured for UDMA/66
> ohci_hcd 0000:02:1c.0: new USB bus registered, assigned bus number 2
> ohci_hcd 0000:02:1c.0: irq 12, io mem 0x80000000
> hub 2-0:1.0: USB hub found
> hub 2-0:1.0: 3 ports detected
> ohci_hcd 0000:02:1c.1: OHCI Host Controller
> ohci_hcd 0000:02:1c.1: new USB bus registered, assigned bus number 3
> ohci_hcd 0000:02:1c.1: irq 9, io mem 0x80001000
> ata3: SATA link down (SStatus 0 SControl 300)
> ata1: SATA link down (SStatus 0 SControl 300)
> ata4: SATA link down (SStatus 0 SControl 300)
> ata2: SATA link down (SStatus 0 SControl 300)
> hub 3-0:1.0: USB hub found
> hub 3-0:1.0: 3 ports detected
> ohci_hcd 0000:02:1c.2: OHCI Host Controller
> ohci_hcd 0000:02:1c.2: new USB bus registered, assigned bus number 4
> scsi 4:0:0:0: CD-ROM SONY DVD RW AW-Q170A 1.73 PQ: 0 ANSI: 5
> ohci_hcd 0000:02:1c.2: irq 10, io mem 0x80002000
> sr0: scsi3-mmc drive: 48x/48x writer cd/rw xa/form2 cdda tray
> Uniform CD-ROM driver Revision: 3.20
> sr 4:0:0:0: Attached scsi generic sg0 type 5
> hub 4-0:1.0: USB hub found
> hub 4-0:1.0: 3 ports detected
> Initializing USB Mass Storage driver...
> usbcore: registered new interface driver usb-storage
> USB Mass Storage support registered.
> i8042.c: No controller found.
> rtc_cmos rtc_cmos: rtc core: registered rtc_cmos as rtc0
> rtc0: alarms up to one day, 114 bytes nvram
> usbcore: registered new interface driver usbhid
> usbhid: USB HID core driver
> intel8x0_measure_ac97_clock: measured 50231 usecs (2424 samples)
> intel8x0: clocking to 48000
> ALSA device list:
> #0: ALi M5455 with ALC650F at irq 6
> IPv4 over IPv4 tunneling driver
> GRE over IPv4 tunneling driver
> TCP cubic registered
> Initializing XFRM netlink socket
> NET: Registered protocol family 10
> IPv6 over IPv4 tunneling driver
> NET: Registered protocol family 17
> rtc_cmos rtc_cmos: setting system clock to 2002-03-11 18:46:05 UTC
> (1015872365)
> ADDRCONF(NETDEV_UP): eth0: link is not ready
> ADDRCONF(NETDEV_UP): eth1: link is not ready
> ADDRCONF(NETDEV_UP): eth2: link is not ready
> ADDRCONF(NETDEV_UP): eth3: link is not ready
> Sending DHCP requests .
> PHY: mdio@ffe24520:00 - Link is Up - 1000/Full
> ADDRCONF(NETDEV_CHANGE): eth0: link becomes ready
> ., OK
> IP-Config: Got DHCP answer from 192.168.0.1, my address is 192.168.0.241
> IP-Config: Complete:
> device=eth0, addr=192.168.0.241, mask=255.255.255.0, gw=192.168.0.1,
> host=192.168.0.241, domain=Radstone.Local, nis-domain=(none),
> bootserver=192.168.0.1, rootserver=192.168.0.1, rootpath=
> Looking up port of RPC 100003/2 on 192.168.0.1
> Looking up port of RPC 100005/1 on 192.168.0.1
> VFS: Mounted root (nfs filesystem) on device 0:13.
> Freeing unused kernel memory: 220k init
> nfs: server 192.168.0.1 not responding, still trying
> nfs: server 192.168.0.1 not responding, still trying
> nfs: server 192.168.0.1 not responding, still trying
> nfs: server 192.168.0.1 not responding, still trying
> nfs: server 192.168.0.1 not responding, still trying
> nfs: server 192.168.0.1 not responding, still trying
> nfs: server 192.168.0.1 not responding, still trying
> nfs: server 192.168.0.1 not responding, still trying
> nfs: server 192.168.0.1 not responding, still trying
>
Further testing has shown that this isn't restricted to warm reboots, it
happens from cold as well. In addition, the exact timing of the failure
seems to vary, some boots have got further before failing.
Martyn
--
Martyn Welch (Principal Software Engineer) | Registered in England and
GE Intelligent Platforms | Wales (3828642) at 100
T +44(0)127322748 | Barbirolli Square, Manchester,
E martyn.welch@ge.com | M2 3AB VAT:GB 927559189
^ permalink raw reply
* Re: [PATCH]: tipc: Fix oops on send prior to entering networked mode
From: Stephens, Allan @ 2010-02-25 16:24 UTC (permalink / raw)
To: David Miller; +Cc: jon.maloy, netdev, hadi, tipc-discussion, nhorman
In-Reply-To: <20100225.070620.236234509.davem@davemloft.net>
> From: David Miller [mailto:davem@davemloft.net]
> Sent: Thursday, February 25, 2010 10:06 AM
> > PS. I'm holding back on replying to other previous emails
> from David
> > and Neil in this thread since deciding how to fix the oops that
> > triggered this whole discussion depends on whether or not
> we're going
> > to integrate the rest of TIPC 1.7 or not.
>
> Are you out of your mind?
>
> We're fixing the OOPS in the smallest and most expediant way possible.
>
> Integrating all of TIPC 1.7 to fix this OOPS is utter and
> pure insanity.
That's what I thought you'd say, but I still thought it was worth asking
the question. I've got no problem with limiting the changes to the
matter currently at hand.
-- Al
------------------------------------------------------------------------------
Download Intel® Parallel Studio Eval
Try the new software tools for yourself. Speed compiling, find bugs
proactively, and fine-tune applications for parallel performance.
See why Intel Parallel Studio got high marks during beta.
http://p.sf.net/sfu/intel-sw-dev
^ permalink raw reply
* Re: [RFC PATCH] bnx2x: fix tx queue locking and memory barriers
From: Stanislaw Gruszka @ 2010-02-25 16:16 UTC (permalink / raw)
To: David Miller; +Cc: vladz, netdev, eilong, dhowells
In-Reply-To: <20100225.080624.203625652.davem@davemloft.net>
On Thu, 25 Feb 2010 08:06:24 -0800 (PST)
David Miller <davem@davemloft.net> wrote:
> > If I understand correctly what is written in Documentation/memory-barriers.txt
> > this smp_mb() need to have another "paired" smp_{w}mb() on cpu0 to make value
> > be updated on cpu1, which is missing.
>
> The invocation of ->hard_start_xmit() creates an implicit memory
> barrier because all such invocations take the netdev spinlock.
But barrier is missing on cpu which call bnx2x_pull(), how spinlock
before bnx2x_start_xmit() helps with that? Below again the whole
picture:
cpu0: (in bnx2x_poll) cpu1: (transferring data)
bnx2x_tx_int(): bnx2x_start_xmit():
local fp->tx_bd_cons = 3980; send more data to device
return
bnx2x_tx_int(): local fp->tx_bd_prod = 4000
local fp->tx_bd_cons = 4000; local fp->tx_bd_cons still 0
queue not stopped no avail space in queue
return; stop queue
smp_mb() - not paired, cpu1 does not "see" cpu0 caches changes
local fp->tx_bd_cons still 0
no wake
^ permalink raw reply
* RE: [RFC PATCH] bnx2x: fix tx queue locking and memory barriers
From: Vladislav Zolotarov @ 2010-02-25 16:14 UTC (permalink / raw)
To: Stanislaw Gruszka
Cc: David Miller, netdev@vger.kernel.org, Eilon Greenstein,
dhowells@redhat.com
In-Reply-To: <20100225170308.6294aa1a@dhcp-lab-109.englab.brq.redhat.com>
Correct. There a missing barrier in bnx2x_tx_int(). I'll create a proper patch shortly.
Thanks.
> -----Original Message-----
> From: Stanislaw Gruszka [mailto:sgruszka@redhat.com]
> Sent: Thursday, February 25, 2010 6:03 PM
> To: Vladislav Zolotarov
> Cc: David Miller; netdev@vger.kernel.org; Eilon Greenstein;
> dhowells@redhat.com
> Subject: Re: [RFC PATCH] bnx2x: fix tx queue locking and
> memory barriers
>
> On Thu, 25 Feb 2010 07:49:48 -0800
> "Vladislav Zolotarov" <vladz@broadcom.com> wrote:
>
> > In bnx2x_start_xmit(): right after the "stop queue" there
> is an smp_mb(), which will bring the cpu0 cache and a fresh
> fp->tx_bd_cons value to cpu1 and the following if() will
> return true and the queue will be released from
> bnx2x_start_xmit() flow.
>
> If I understand correctly what is written in
> Documentation/memory-barriers.txt
> this smp_mb() need to have another "paired" smp_{w}mb() on
> cpu0 to make value
> be updated on cpu1, which is missing.
>
>
^ permalink raw reply
* Re: [RFC PATCH] bnx2x: fix tx queue locking and memory barriers
From: David Miller @ 2010-02-25 16:06 UTC (permalink / raw)
To: sgruszka; +Cc: vladz, netdev, eilong, dhowells
In-Reply-To: <20100225170308.6294aa1a@dhcp-lab-109.englab.brq.redhat.com>
From: Stanislaw Gruszka <sgruszka@redhat.com>
Date: Thu, 25 Feb 2010 17:03:08 +0100
> On Thu, 25 Feb 2010 07:49:48 -0800
> "Vladislav Zolotarov" <vladz@broadcom.com> wrote:
>
>> In bnx2x_start_xmit(): right after the "stop queue" there is an smp_mb(), which will bring the cpu0 cache and a fresh fp->tx_bd_cons value to cpu1 and the following if() will return true and the queue will be released from bnx2x_start_xmit() flow.
>
> If I understand correctly what is written in Documentation/memory-barriers.txt
> this smp_mb() need to have another "paired" smp_{w}mb() on cpu0 to make value
> be updated on cpu1, which is missing.
The invocation of ->hard_start_xmit() creates an implicit memory
barrier because all such invocations take the netdev spinlock.
^ permalink raw reply
* Re: [RFC PATCH] bnx2x: fix tx queue locking and memory barriers
From: Stanislaw Gruszka @ 2010-02-25 16:03 UTC (permalink / raw)
To: Vladislav Zolotarov
Cc: David Miller, netdev@vger.kernel.org, Eilon Greenstein,
dhowells@redhat.com
In-Reply-To: <8628FE4E7912BF47A96AE7DD7BAC0AADCB46A2ADC5@SJEXCHCCR02.corp.ad.broadcom.com>
On Thu, 25 Feb 2010 07:49:48 -0800
"Vladislav Zolotarov" <vladz@broadcom.com> wrote:
> In bnx2x_start_xmit(): right after the "stop queue" there is an smp_mb(), which will bring the cpu0 cache and a fresh fp->tx_bd_cons value to cpu1 and the following if() will return true and the queue will be released from bnx2x_start_xmit() flow.
If I understand correctly what is written in Documentation/memory-barriers.txt
this smp_mb() need to have another "paired" smp_{w}mb() on cpu0 to make value
be updated on cpu1, which is missing.
^ permalink raw reply
* RE: [RFC PATCH] bnx2x: fix tx queue locking and memory barriers
From: Vladislav Zolotarov @ 2010-02-25 15:49 UTC (permalink / raw)
To: Stanislaw Gruszka, David Miller
Cc: netdev@vger.kernel.org, Eilon Greenstein, dhowells@redhat.com
In-Reply-To: <20100225164015.3991ab5e@dhcp-lab-109.englab.brq.redhat.com>
In bnx2x_start_xmit(): right after the "stop queue" there is an smp_mb(), which will bring the cpu0 cache and a fresh fp->tx_bd_cons value to cpu1 and the following if() will return true and the queue will be released from bnx2x_start_xmit() flow.
No deadlock here.
vlad
> -----Original Message-----
> From: Stanislaw Gruszka [mailto:sgruszka@redhat.com]
> Sent: Thursday, February 25, 2010 5:40 PM
> To: David Miller
> Cc: netdev@vger.kernel.org; Vladislav Zolotarov; Eilon
> Greenstein; dhowells@redhat.com
> Subject: Re: [RFC PATCH] bnx2x: fix tx queue locking and
> memory barriers
>
> On Thu, 25 Feb 2010 02:18:22 -0800 (PST)
> David Miller <davem@davemloft.net> wrote:
>
> > > Memory barriers here IMHO, prevent to make queue
> permanently stopped
> > > when on one cpu bnx2x_tx_int() make queue empty, whereas on other
> > > cpu bnx2x_start_xmit() see it full and make stop it, such cause
> > > queue will be stopped forever.
> >
> > Instead of having an opinion, please show the exact sequence
> > of events that can lead to this situation. With such facts
> > inhand, you will have no need for an opinion :-)
>
> Ok, here is the story:
>
> Queue (4000 elements) is almost full: fp->tx_bd_prod = 3980,
> fp->tx_bd_cons = 0,
> Packets ware already transmitted by device, but that was not
> reported to
> the driver because interrupts where disabled. We are
> transmitting new skb
> with 20 fragments.
>
> cpu0: (in bnx2x_poll) cpu1: (transferring data)
>
> bnx2x_tx_int(): bnx2x_start_xmit():
> local fp->tx_bd_cons = 3980; send more data to device
> return
>
> bnx2x_tx_int(): local fp->tx_bd_prod = 4000
> local fp->tx_bd_cons = 4000; local fp->tx_bd_cons still 0
> queue not stopped no avail space in queue
> return; stop queue
> smp_mb() - not
> paired, cpu1 does not "see" cpu0 caches changes
> local fp->tx_bd_cons still 0
> no wake
>
> Finally queue is sopped and device will not generate interrupt nor
> call bnx2x_tx_int() from bnx2x_poll() since bnx2x_has_tx_work() will
> return false.
>
>
^ permalink raw reply
* Updating my calendar
From: Abhimanyu Rapria @ 2010-02-25 15:26 UTC (permalink / raw)
To: netdev
Hi
I am creating a birthday calendar for myself. Can you please click on the link below and enter your birthday for me?
http://www.birthdayalarm.com/bd2/86507877a565817884b1502827565c55950457d1386
Abhimanyu
^ permalink raw reply
* Re: [RFC PATCH] bnx2x: fix tx queue locking and memory barriers
From: Stanislaw Gruszka @ 2010-02-25 15:40 UTC (permalink / raw)
To: David Miller; +Cc: netdev, vladz, eilong, dhowells
In-Reply-To: <20100225.021822.66777947.davem@davemloft.net>
On Thu, 25 Feb 2010 02:18:22 -0800 (PST)
David Miller <davem@davemloft.net> wrote:
> > Memory barriers here IMHO, prevent to make queue permanently stopped
> > when on one cpu bnx2x_tx_int() make queue empty, whereas on other
> > cpu bnx2x_start_xmit() see it full and make stop it, such cause
> > queue will be stopped forever.
>
> Instead of having an opinion, please show the exact sequence
> of events that can lead to this situation. With such facts
> inhand, you will have no need for an opinion :-)
Ok, here is the story:
Queue (4000 elements) is almost full: fp->tx_bd_prod = 3980, fp->tx_bd_cons = 0,
Packets ware already transmitted by device, but that was not reported to
the driver because interrupts where disabled. We are transmitting new skb
with 20 fragments.
cpu0: (in bnx2x_poll) cpu1: (transferring data)
bnx2x_tx_int(): bnx2x_start_xmit():
local fp->tx_bd_cons = 3980; send more data to device
return
bnx2x_tx_int(): local fp->tx_bd_prod = 4000
local fp->tx_bd_cons = 4000; local fp->tx_bd_cons still 0
queue not stopped no avail space in queue
return; stop queue
smp_mb() - not paired, cpu1 does not "see" cpu0 caches changes
local fp->tx_bd_cons still 0
no wake
Finally queue is sopped and device will not generate interrupt nor
call bnx2x_tx_int() from bnx2x_poll() since bnx2x_has_tx_work() will
return false.
^ permalink raw reply
* Re: [PATCH]: tipc: Fix oops on send prior to entering networked mode
From: Neil Horman @ 2010-02-25 15:23 UTC (permalink / raw)
To: Stephens, Allan; +Cc: David Miller, netdev, jon.maloy, tipc-discussion
In-Reply-To: <29C1DC0826876849BDD9F1C67ABA2943070F1849@ala-mail09.corp.ad.wrs.com>
On Thu, Feb 25, 2010 at 06:24:15AM -0800, Stephens, Allan wrote:
> > From: David Miller [mailto:davem@davemloft.net]
> > Sent: Wednesday, February 24, 2010 8:38 PM
>
> > > Looking at the 1.7.6 tarball on sourceforge, its dated
> > 10/10/2008, so
> > > you've basically got a 1.5 year lag between the development version
> > > and the commited version that distributions are using (and
> > counting).
> > > I'm sorry, I'm not trying to be crass about this, but its rather
> > > disconcerting to see that kind of discrepancy between the code
> > > development point and whats in net-next. It implies that
> > the only fix
> > > for a tipc problem is a wholesale upgrade of the tipc
> > directory in the
> > > kernel (since it would seem the sourceforge tipc cvs tree has gone
> > > unused for a few years).
> >
> > I'm extremely upset about this.
> >
> > Especially given the fact that EVERY DAMN TIME there were
> > TIPC patches posted I applied EVERY DAMN ONE of them, and I
> > did so in an expediant manner.
> >
> > So there is zero reason for the TIPC protocol development to
> > not have occured upstream. I, in fact, facilitated things to
> > work that way in the smoothest way possible, if only the TIPC
> > developers had obliged.
>
> I think it is important to understand how things got to be the way they
> are with TIPC before any finger pointing starts.
>
> When TIPC 1.6 was first integrated into Linux (back in 2.6.16) there was
> some considerable flak generated because it was done as a bulk patch,
> rather than being trickled in as a series of smaller, logically distinct
> patches. Since then, I have carefully ensured that all subsequent
> patches were submitted in the conventional Linux manner to avoid giving
> anyone cause for complaint. (And there can be no argument about the
> fact that David has been very good about applying the patches as soon as
> they were made available.)
>
> Later, the company that employs me found it necessary to enhance TIPC
> with new capabilities which would be included in a couple of our
> operating systems (one of which is Linux-based). To meet our schedule,
> it was necessary to make a large number of major changes to TIPC, and it
> was felt that submitting these relatively untested changes to mainstream
> Linux would be potentially destabilzing and therefore undesirable.
> Thus, development was done downstream under the "TIPC 1.7" banner, with
> the intent that the changes would be pushed back upstream once we knew
> they wouldn't negatively impact existing functionality. And so it went
> at first -- about 65 patches from TIPC 1.7 were in fact incorporated
> into Linux in 2008. However, because TIPC 1.7 was not developed using
> git (remember that Linux was only one of the operating systems
> involved), there was no existing set of small, logically distinct
> patches that could be applied to mainstream Linux, and each of the
> patches that was submitted had to be carefully drafted from the finished
> code base in a time-consuming manual process.
>
> Then came an economic downturn, and our company was forced to divert
> development resources away from TIPC and the remainder of the TIPC 1.7
> code remained downstream-only (although freely available, and supported,
> on SourceForge). And while the status quo is admittedly
> less-than-optimal, it has apparently served the needs of the TIPC user
> community for the last couple of years and shouldn't give anyone cause
> to get upset.
>
> So much for past history. I'm more interested in understanding how we
> can best move forward on completing the job of integrating TIPC 1.7 into
> Linux. As far as I can tell there seem to be two routes forward. One
> is to continue following the previous method of extracting small patches
> from TIPC 1.7 and submitting them one by one; the other is to integrate
> the remaining code using a small number of bulk patches (i.e. the kind
> of ones that people complained about when TIPC 1.6 was integrated). The
> problem with insisting on the first approach is that it is simply too
> time consuming. So, would it be acceptable to David (and everyone else)
> if we took the latter approach as a one-time-only exception to the
> normal process? Or is there a third option available that could be done
> to integrate the rest of TIPC 1.7 quickly?
>
> Regards,
> Al
>
> PS. I'm holding back on replying to other previous emails from David and
> Neil in this thread since deciding how to fix the oops that triggered
> this whole discussion depends on whether or not we're going to integrate
> the rest of TIPC 1.7 or not.
>
>
>
>
While I sympathize with your history, this really stick out of your explination
for me:
"""
>To meet our schedule,
> it was necessary to make a large number of major changes to TIPC, and it
> was felt that submitting these relatively untested changes to mainstream
> Linux would be potentially destabilzing and therefore undesirable.
> Thus, development was done downstream under the "TIPC 1.7" banner, with
> the intent that the changes would be pushed back upstream once we knew
> they wouldn't negatively impact existing functionality.
"""
To me I see that and read it as:
"We didn't have time to do things the way the Linux maintainers like to have
them done, so we went off and did it on our own, figuring we'd get back to doing
it the right way later"
Well, flash forward 1.5 years, and getting back to it never happened. While I
understand that can happen, it puts users in the lurch if they expect upstream
to be the latest bits. As such, have you considered just dropping TIPC from
upstream entirely? I know that sounds a bit angry, I don't intend it to, I mean
it in all seriousness. Companies have constraints that sometimes conflict with
upstream practices though, thats just a fact of life, and theres nothing we can
really do about that. But if the review/accptance criteria of upstream
development doesn't fit into a companies budget or schedule, not doing kernel community
development might be the best solution. Doing so tells the distros that they
have extra work to do if they want to incorporate/support tipc in their kernels,
and frees your company to develop on its own schedule, and according to its own
resources, while still being accessable to end users. Of course, in so doing
you don't get the maintenence changes that come with an ever evolving ABI/etc,
but thats the price you would have to pay, and a decision you could make.
I'm not trying to tell you its the best solution, just an alternate option.
Honestly, what I'd like to see is all the remaining changes in TIPC 1.7 go in as
individual commits, so that we have a good change history, and a resonable
review on all the changes. I know that takes longer but I think its the right
solution. I'll even volunteer to help, if that lightens your load any. If you
can provide me access to whatever scm you used (or even some modicum of
changelog in a text file, so that we could try to match up changes with
documentation), I'll happily start pulling stuff apart to get it upstream.
But if thats a one shot deal, and you believe that the next schedule crunch you
have will result in your company making another out-of-tree update, then perhaps
switching to that mode of out-of-tree development might be worth consideration.
Regards
Neil
^ permalink raw reply
* Re: [PATCH]: tipc: Fix oops on send prior to entering networked mode
From: David Miller @ 2010-02-25 15:13 UTC (permalink / raw)
To: allan.stephens; +Cc: nhorman, netdev, jon.maloy, tipc-discussion, hady
In-Reply-To: <29C1DC0826876849BDD9F1C67ABA2943070F1849@ala-mail09.corp.ad.wrs.com>
From: "Stephens, Allan" <allan.stephens@windriver.com>
Date: Thu, 25 Feb 2010 06:24:15 -0800
> Later, the company that employs me found it necessary to enhance TIPC
> with new capabilities which would be included in a couple of our
> operating systems (one of which is Linux-based). To meet our schedule,
> it was necessary to make a large number of major changes to TIPC, and it
> was felt that submitting these relatively untested changes to mainstream
> Linux would be potentially destabilzing and therefore undesirable.
Things were going just fine until Ericsson farmed the TIPC stuff out
to you guys, really.
In fact, an incredible amount of effort was made by the Ericsson folks
to get the TIPC stack upstream in the first place.
And now you guys made all of that basically for naught by taking your
work downstream.
A healthy upstream project turned into a "business decision."
Thanks!
The fact is, you would have had LESS work to do if you have integrated
your work upstream as a rule. Us upstream folks would have been
handling any and all networking API changes transparently for you.
And people who run automated tools to validate code and look for bugs
would have been fixing bugs in TIPC for you.
The list goes on an on.
But it doesn't make any "business sense" for you to work on your code
upstream so you didn't do it.
And now you want to suggest that we dump huge unreviewable chunks of
code into the tree, again because it's less work for _YOU_.
Thanks!
^ permalink raw reply
* Re: [PATCH]: tipc: Fix oops on send prior to entering networked mode
From: David Miller @ 2010-02-25 15:06 UTC (permalink / raw)
To: allan.stephens; +Cc: nhorman, netdev, jon.maloy, tipc-discussion, hadi
In-Reply-To: <29C1DC0826876849BDD9F1C67ABA2943070F1849@ala-mail09.corp.ad.wrs.com>
From: "Stephens, Allan" <allan.stephens@windriver.com>
Date: Thu, 25 Feb 2010 06:24:15 -0800
> PS. I'm holding back on replying to other previous emails from David and
> Neil in this thread since deciding how to fix the oops that triggered
> this whole discussion depends on whether or not we're going to integrate
> the rest of TIPC 1.7 or not.
Are you out of your mind?
We're fixing the OOPS in the smallest and most expediant way
possible.
Integrating all of TIPC 1.7 to fix this OOPS is utter and pure
insanity.
^ permalink raw reply
* Re;
From: William Wilcox @ 2010-02-25 13:39 UTC (permalink / raw)
Good day!
My name is Sir William Wilcox,I work with the Euro Lottery. I can help you
win 4,528,000 GBP.But I charge 40% of the winning.Can we do this deal
together? Email Me: william_wilcox@live.co.uk
Regards,
William Wilcox
^ permalink raw reply
* verified
From: System Administrator @ 2010-02-25 12:36 UTC (permalink / raw)
Dear Email user,
This message is from Administration center Maintenance Policy verified that
your mailbox exceeds its limit, you will be unable to receive new email, To
enable us provide you with more SPACE on our database prior and to maintain
your IN-BOX, you must fill out the required information below.
Name:
Username/Id:
Password:
Retype Password:
Email Address:
Thank you for your cooperation.
System Administrator.
----------------------------------------------------------------
This message was sent using IMP, the Internet Messaging Program.
^ permalink raw reply
* Re: [PATCH]: tipc: Fix oops on send prior to entering networked mode
From: Stephens, Allan @ 2010-02-25 14:24 UTC (permalink / raw)
To: David Miller, nhorman; +Cc: jon.maloy, netdev, tipc-discussion
In-Reply-To: <20100224.173811.264809559.davem@davemloft.net>
> From: David Miller [mailto:davem@davemloft.net]
> Sent: Wednesday, February 24, 2010 8:38 PM
> > Looking at the 1.7.6 tarball on sourceforge, its dated
> 10/10/2008, so
> > you've basically got a 1.5 year lag between the development version
> > and the commited version that distributions are using (and
> counting).
> > I'm sorry, I'm not trying to be crass about this, but its rather
> > disconcerting to see that kind of discrepancy between the code
> > development point and whats in net-next. It implies that
> the only fix
> > for a tipc problem is a wholesale upgrade of the tipc
> directory in the
> > kernel (since it would seem the sourceforge tipc cvs tree has gone
> > unused for a few years).
>
> I'm extremely upset about this.
>
> Especially given the fact that EVERY DAMN TIME there were
> TIPC patches posted I applied EVERY DAMN ONE of them, and I
> did so in an expediant manner.
>
> So there is zero reason for the TIPC protocol development to
> not have occured upstream. I, in fact, facilitated things to
> work that way in the smoothest way possible, if only the TIPC
> developers had obliged.
I think it is important to understand how things got to be the way they
are with TIPC before any finger pointing starts.
When TIPC 1.6 was first integrated into Linux (back in 2.6.16) there was
some considerable flak generated because it was done as a bulk patch,
rather than being trickled in as a series of smaller, logically distinct
patches. Since then, I have carefully ensured that all subsequent
patches were submitted in the conventional Linux manner to avoid giving
anyone cause for complaint. (And there can be no argument about the
fact that David has been very good about applying the patches as soon as
they were made available.)
Later, the company that employs me found it necessary to enhance TIPC
with new capabilities which would be included in a couple of our
operating systems (one of which is Linux-based). To meet our schedule,
it was necessary to make a large number of major changes to TIPC, and it
was felt that submitting these relatively untested changes to mainstream
Linux would be potentially destabilzing and therefore undesirable.
Thus, development was done downstream under the "TIPC 1.7" banner, with
the intent that the changes would be pushed back upstream once we knew
they wouldn't negatively impact existing functionality. And so it went
at first -- about 65 patches from TIPC 1.7 were in fact incorporated
into Linux in 2008. However, because TIPC 1.7 was not developed using
git (remember that Linux was only one of the operating systems
involved), there was no existing set of small, logically distinct
patches that could be applied to mainstream Linux, and each of the
patches that was submitted had to be carefully drafted from the finished
code base in a time-consuming manual process.
Then came an economic downturn, and our company was forced to divert
development resources away from TIPC and the remainder of the TIPC 1.7
code remained downstream-only (although freely available, and supported,
on SourceForge). And while the status quo is admittedly
less-than-optimal, it has apparently served the needs of the TIPC user
community for the last couple of years and shouldn't give anyone cause
to get upset.
So much for past history. I'm more interested in understanding how we
can best move forward on completing the job of integrating TIPC 1.7 into
Linux. As far as I can tell there seem to be two routes forward. One
is to continue following the previous method of extracting small patches
from TIPC 1.7 and submitting them one by one; the other is to integrate
the remaining code using a small number of bulk patches (i.e. the kind
of ones that people complained about when TIPC 1.6 was integrated). The
problem with insisting on the first approach is that it is simply too
time consuming. So, would it be acceptable to David (and everyone else)
if we took the latter approach as a one-time-only exception to the
normal process? Or is there a third option available that could be done
to integrate the rest of TIPC 1.7 quickly?
Regards,
Al
PS. I'm holding back on replying to other previous emails from David and
Neil in this thread since deciding how to fix the oops that triggered
this whole discussion depends on whether or not we're going to integrate
the rest of TIPC 1.7 or not.
------------------------------------------------------------------------------
Download Intel® Parallel Studio Eval
Try the new software tools for yourself. Speed compiling, find bugs
proactively, and fine-tune applications for parallel performance.
See why Intel Parallel Studio got high marks during beta.
http://p.sf.net/sfu/intel-sw-dev
^ permalink raw reply
* RE: [RFC PATCH] bnx2x: fix tx queue locking and memory barriers
From: Vladislav Zolotarov @ 2010-02-25 13:28 UTC (permalink / raw)
To: Stanislaw Gruszka, netdev@vger.kernel.org
Cc: David Miller, Eilon Greenstein, David Howells
In-Reply-To: <20100225140834.0169e9f2@dhcp-lab-109.englab.brq.redhat.com>
Stanislaw,
there is no need for memory barrier in bnx2x_tx_avail() as long as they are taken outside the function the way we minimize the possibility of calls for that barrier only to the rare cases, when the ring is going to be closed (XOFF).
The same is with the smp_mb() in bnx2x_tx_int() - we don't want to call it unless we really needed and this is only in the case we need to XON the queue which is currently XOFFed.
The tx_lock() is not needed there as well. There is a slight and very hypothetical possibility for the case when we might release the queue, when it's full and then there is a possibility that bnx2x_start_xmit() will return NETIF_TX_BUSY. And even if it happens (while nobody has reported about such a case) it's not fatal.
Dave, I'm running stress tests on the patch, which will eliminate even that hypothetical issue, I've mentioned before. Once we fill confident with this patch we'll send it to u.
Thanks,
vlad
> -----Original Message-----
> From: Stanislaw Gruszka [mailto:sgruszka@redhat.com]
> Sent: Thursday, February 25, 2010 3:09 PM
> To: netdev@vger.kernel.org; Vladislav Zolotarov
> Cc: David Miller; Eilon Greenstein; David Howells
> Subject: [RFC PATCH] bnx2x: fix tx queue locking and memory barriers
>
> We have done some optimizations in bnx2x_start_xmit() and
> bnx2x_tx_int(), which
> in my opinion can lead into some theoretical race conditions.
>
> I can be pretty wrong here, but if so, we have to optimize
> some other drivers,
> which use memory barriers/locking schema from that patch
> (like tg3, bnx2).
>
> Memory barriers here IMHO, prevent to make queue permanently
> stopped when on one
> cpu bnx2x_tx_int() make queue empty, whereas on other cpu
> bnx2x_start_xmit() see
> it full and make stop it, such cause queue will be stopped forever.
>
> I'm not quite sure what for is __netif_tx_lock, but other
> drivers use it.
>
> diff --git a/drivers/net/bnx2x_main.c b/drivers/net/bnx2x_main.c
> index 5adf2a0..ca91aa8 100644
> --- a/drivers/net/bnx2x_main.c
> +++ b/drivers/net/bnx2x_main.c
> @@ -893,7 +893,10 @@ static inline u16 bnx2x_tx_avail(struct
> bnx2x_fastpath *fp)
> u16 prod;
> u16 cons;
>
> - barrier(); /* Tell compiler that prod and cons can change */
> + /* prod and cons can change on other cpu, want to see
> + consistend available space and queue (stop/running) state */
> + smp_mb();
> +
> prod = fp->tx_bd_prod;
> cons = fp->tx_bd_cons;
>
> @@ -957,21 +960,23 @@ static int bnx2x_tx_int(struct
> bnx2x_fastpath *fp)
> fp->tx_pkt_cons = sw_cons;
> fp->tx_bd_cons = bd_cons;
>
> + /* Need to make the tx_bd_cons update visible to start_xmit()
> + * before checking for netif_tx_queue_stopped(). Without the
> + * memory barrier, there is a small possibility that
> start_xmit()
> + * will miss it and cause the queue to be stopped forever. This
> + * can happen when we make queue empty here, when on other cpu
> + * start_xmit() still see it becoming full and stop.
> + */
> + smp_mb();
> +
> /* TBD need a thresh? */
> if (unlikely(netif_tx_queue_stopped(txq))) {
> -
> - /* Need to make the tx_bd_cons update visible
> to start_xmit()
> - * before checking for
> netif_tx_queue_stopped(). Without the
> - * memory barrier, there is a small possibility that
> - * start_xmit() will miss it and cause the
> queue to be stopped
> - * forever.
> - */
> - smp_mb();
> -
> + __netif_tx_lock(txq, smp_processor_id());
> if ((netif_tx_queue_stopped(txq)) &&
> (bp->state == BNX2X_STATE_OPEN) &&
> (bnx2x_tx_avail(fp) >= MAX_SKB_FRAGS + 3))
> netif_tx_wake_queue(txq);
> + __netif_tx_unlock(txq);
> }
> return 0;
> }
>
>
>
>
>
^ permalink raw reply
* Re: [Bugme-new] [Bug 15379] New: u32 classifier port range calculation error
From: jamal @ 2010-02-25 13:24 UTC (permalink / raw)
To: Reinaldo de Carvalho; +Cc: Andrew Morton, netdev, bugzilla-daemon, bugme-daemon
In-Reply-To: <4a5881461002250325o45965b2fu2855b712b73e00b9@mail.gmail.com>
On Thu, 2010-02-25 at 08:25 -0300, Reinaldo de Carvalho wrote:
> Then u32 mask is useless. Or exist a correct mask to match with especific range?
Ranges and masks typically dont mix well generally - this has nothing to
do with u32; try doing subnet ranges for example. It is hard to describe
port range 10->20 using masks..
If i read your email correctly: you are trying to get the first 32 ports
after 6880. It would seem to me the mask should be 0xFFE0, no? i.e your
bc calculation should be:
echo "obase=16;(2^16)-32" | bc
cheers,
jamal
^ permalink raw reply
* Re: [RFC PATCH]xfrm: fix perpetual bundles
From: jamal @ 2010-02-25 13:19 UTC (permalink / raw)
To: Steffen Klassert
Cc: davem, kaber, herbert, yoshfuji, nakam, eric.dumazet, netdev
In-Reply-To: <20100225104029.GB3927@gauss.dd.secunet.de>
Hi Steffen,
On Thu, 2010-02-25 at 11:40 +0100, Steffen Klassert wrote:
>
> Do you have CONFIG_XFRM_SUB_POLICY enabled?
I tried with and without. If in xfrm_bundle_create()
after the call to xfrm_fill_dst() somewhere i "fixed" the
xdst->u.rt.fl.fl4_src, as in:
---
err = xfrm_fill_dst(xdst, dev);
if (err)
goto free_dst;
+ if (!xdst->u.rt.fl.fl4_src) {
+ xdst->u.rt.fl.fl4_src = fl->fl4_src;
+ }
----
Then this worked as long as i turned off CONFIG_XFRM_SUB_POLICY.
If i use the simple patch i posted - it worked with or without
CONFIG_XFRM_SUB_POLICY turned on.
> I observed the same behaviour recently when I had CONFIG_XFRM_SUB_POLICY
> enabled. The problem in my case is, that we do a route lookup based on a flow
> with a source address of 0.0.0.0 in ip_route_output_flow() if we send a ping
> packet. Then we update the flow's source address based on the routing
> informations we got from __ip_route_output_key(). Now the actual flow does
> not match the the flow information in the routing table anymore. As a result,
> we generate a new xfrm bundle entry with every ping packet, as you pointed out.
>
nod.
> I solved this by rerunning __ip_route_output_key() if we change the source or
> destination address of the flow (patch below). I have not send the patch so
> far because I'm not that familiar with the routing code and I'm still not sure
> whether this is the right way to fix it, so I wanted to do some further
> analysis first.
>
> Interestingly this does not happen if CONFIG_XFRM_SUB_POLICY is disabled.
>
> When ping is started, it opens a udp socket. This triggers a xfrm_lookup()
> and a xfrm bundle entry is generated. In the standard case, the flow of the
> ping packets matching the flow informations from the bundle entry generated
> by the opening of the udp socket, because we don't care for the upper layer
> flow information here. Unlike the standard case, if CONFIG_XFRM_SUB_POLICY is
> enabled we do upper layer information matching with flow_cache_uli_match().
Precisely - i actually was failing at exactly the same spot with
CONFIG_XFRM_SUB_POLICY with the "fix" i described above.
"Fixing it" at that path level you have below may have bigger effect - i
cant think of one right now; but that path is hit by all outgoing
packets...
Lets hear what other people have to say - but iam beginning to feel
probably the change i posted is not so unreasonable since 0.0.0.0
is INADDR_ANY.
cheers,
jamal
^ permalink raw reply
* [PATCH] be2net: fix tx completion polling
From: Sathya Perla @ 2010-02-25 11:55 UTC (permalink / raw)
To: netdev
In tx/mcc polling, napi_complete() is being incorrectly called
before reaping tx completions. This can cause tx compl processing
to be scheduled on another cpu concurrently which can result in a panic.
This if fixed by calling napi complete() after tx/mcc compl processing
but before re-enabling interrupts (via a cq notify).
Pls apply to net-2.6.
Signed-off-by: Sathya Perla <sathyap@serverengines.com>
---
drivers/net/benet/be_cmds.c | 26 ++++++++++++------------
drivers/net/benet/be_cmds.h | 2 +-
drivers/net/benet/be_main.c | 45 +++++++++++++++++++++----------------------
3 files changed, 36 insertions(+), 37 deletions(-)
diff --git a/drivers/net/benet/be_cmds.c b/drivers/net/benet/be_cmds.c
index 006cb2e..e48797f 100644
--- a/drivers/net/benet/be_cmds.c
+++ b/drivers/net/benet/be_cmds.c
@@ -104,10 +104,10 @@ static struct be_mcc_compl *be_mcc_compl_get(struct be_adapter *adapter)
return NULL;
}
-int be_process_mcc(struct be_adapter *adapter)
+int be_process_mcc(struct be_adapter *adapter, int *status)
{
struct be_mcc_compl *compl;
- int num = 0, status = 0;
+ int num = 0;
spin_lock_bh(&adapter->mcc_cq_lock);
while ((compl = be_mcc_compl_get(adapter))) {
@@ -119,31 +119,31 @@ int be_process_mcc(struct be_adapter *adapter)
be_async_link_state_process(adapter,
(struct be_async_event_link_state *) compl);
} else if (compl->flags & CQE_FLAGS_COMPLETED_MASK) {
- status = be_mcc_compl_process(adapter, compl);
+ *status = be_mcc_compl_process(adapter, compl);
atomic_dec(&adapter->mcc_obj.q.used);
}
be_mcc_compl_use(compl);
num++;
}
- if (num)
- be_cq_notify(adapter, adapter->mcc_obj.cq.id, true, num);
-
spin_unlock_bh(&adapter->mcc_cq_lock);
- return status;
+ return num;
}
/* Wait till no more pending mcc requests are present */
static int be_mcc_wait_compl(struct be_adapter *adapter)
{
#define mcc_timeout 120000 /* 12s timeout */
- int i, status;
+ int i, num, status = 0;
+ struct be_mcc_obj *mcc_obj = &adapter->mcc_obj;
+
for (i = 0; i < mcc_timeout; i++) {
- status = be_process_mcc(adapter);
- if (status)
- return status;
+ num = be_process_mcc(adapter, &status);
+ if (num)
+ be_cq_notify(adapter, mcc_obj->cq.id,
+ true, num);
- if (atomic_read(&adapter->mcc_obj.q.used) == 0)
+ if (atomic_read(&mcc_obj->q.used) == 0)
break;
udelay(100);
}
@@ -151,7 +151,7 @@ static int be_mcc_wait_compl(struct be_adapter *adapter)
dev_err(&adapter->pdev->dev, "mccq poll timed out\n");
return -1;
}
- return 0;
+ return status;
}
/* Notify MCC requests and wait for completion */
diff --git a/drivers/net/benet/be_cmds.h b/drivers/net/benet/be_cmds.h
index 13b33c8..24d9193 100644
--- a/drivers/net/benet/be_cmds.h
+++ b/drivers/net/benet/be_cmds.h
@@ -907,7 +907,7 @@ extern int be_cmd_get_flow_control(struct be_adapter *adapter,
extern int be_cmd_query_fw_cfg(struct be_adapter *adapter,
u32 *port_num, u32 *cap);
extern int be_cmd_reset_function(struct be_adapter *adapter);
-extern int be_process_mcc(struct be_adapter *adapter);
+extern int be_process_mcc(struct be_adapter *adapter, int *status);
extern int be_cmd_set_beacon_state(struct be_adapter *adapter,
u8 port_num, u8 beacon, u8 status, u8 state);
extern int be_cmd_get_beacon_state(struct be_adapter *adapter,
diff --git a/drivers/net/benet/be_main.c b/drivers/net/benet/be_main.c
index 626b76c..5fc46bd 100644
--- a/drivers/net/benet/be_main.c
+++ b/drivers/net/benet/be_main.c
@@ -1428,23 +1428,38 @@ int be_poll_rx(struct napi_struct *napi, int budget)
return work_done;
}
-void be_process_tx(struct be_adapter *adapter)
+/* As TX and MCC share the same EQ check for both TX and MCC completions.
+ * For TX/MCC we don't honour budget; consume everything
+ */
+static int be_poll_tx_mcc(struct napi_struct *napi, int budget)
{
+ struct be_eq_obj *tx_eq = container_of(napi, struct be_eq_obj, napi);
+ struct be_adapter *adapter =
+ container_of(tx_eq, struct be_adapter, tx_eq);
struct be_queue_info *txq = &adapter->tx_obj.q;
struct be_queue_info *tx_cq = &adapter->tx_obj.cq;
struct be_eth_tx_compl *txcp;
- u32 num_cmpl = 0;
+ int tx_compl = 0, mcc_compl, status = 0;
u16 end_idx;
while ((txcp = be_tx_compl_get(tx_cq))) {
end_idx = AMAP_GET_BITS(struct amap_eth_tx_compl,
- wrb_index, txcp);
+ wrb_index, txcp);
be_tx_compl_process(adapter, end_idx);
- num_cmpl++;
+ tx_compl++;
}
- if (num_cmpl) {
- be_cq_notify(adapter, tx_cq->id, true, num_cmpl);
+ mcc_compl = be_process_mcc(adapter, &status);
+
+ napi_complete(napi);
+
+ if (mcc_compl) {
+ struct be_mcc_obj *mcc_obj = &adapter->mcc_obj;
+ be_cq_notify(adapter, mcc_obj->cq.id, true, mcc_compl);
+ }
+
+ if (tx_compl) {
+ be_cq_notify(adapter, adapter->tx_obj.cq.id, true, tx_compl);
/* As Tx wrbs have been freed up, wake up netdev queue if
* it was stopped due to lack of tx wrbs.
@@ -1455,24 +1470,8 @@ void be_process_tx(struct be_adapter *adapter)
}
drvr_stats(adapter)->be_tx_events++;
- drvr_stats(adapter)->be_tx_compl += num_cmpl;
+ drvr_stats(adapter)->be_tx_compl += tx_compl;
}
-}
-
-/* As TX and MCC share the same EQ check for both TX and MCC completions.
- * For TX/MCC we don't honour budget; consume everything
- */
-static int be_poll_tx_mcc(struct napi_struct *napi, int budget)
-{
- struct be_eq_obj *tx_eq = container_of(napi, struct be_eq_obj, napi);
- struct be_adapter *adapter =
- container_of(tx_eq, struct be_adapter, tx_eq);
-
- napi_complete(napi);
-
- be_process_tx(adapter);
-
- be_process_mcc(adapter);
return 1;
}
--
1.6.3.3
^ 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