[no subject]
subscribe netdev
[no subject]
Hey Netdev http://arc-protect.com/m7_gift_giver.php?isnt=pfcz272prn36hk Oliver
[no subject]
Subject: [PATCH net-next 00/11] qed*: Support VF XDP attachment Each driver queue [Rx, Tx, XDP-forwarding] requires an allocated HW/FW connection + configured queue-zone. VF handling by the PF has several limitations that prevented adding the capability to perform XDP at driver-level: - The VF assumes there's 1-to-1 correspondance between the VF queue and the used connection, meaning q is always going to use cid, whereas for its own queues the PF is acquiring a new cid per each new queue. - There's a 1-to-1 correspondate between the VF-queues and the HW queue zones. While this is necessary for Rx-queues [as the queue-zone contains the producer], transmission queues can share the underlaying queue-zone [only shared configuration is coalescing]. But all VF<->PF communication mechanisms assume there's a single identifier that identify a queue [as queue-zone == queue], while sharing queue-zones requires passing additional information. - VFs currently don't try mapping a doorbell bar - there's a small doorbell window in the regview allowing VFs to doorbell up to 16 connections; but this window isn's wide enough for the added XDP forwarding queues. This series is going to add the necessary infrastrucutre to finally let our VFs support XDP assuming both the PF and VF drivers are sufficiently new [Legacy support would be retained both for older VFs and older PFs, but both will be needed for this new support to work]. Basically, the various database driver maintains for its queue-cids would be revised, and queue-cids would be identified using the (queue-zone, unique index) pair. The TLV mechanism would then be extended to allow VFs to communicate that unique-index as well as the already provided queue-zone. Finally, the VFs would try to map their doorbell bar and inform their PF that they're using it. Almost all the changes are in qed, with exception of #3 [which does some cleanup in qede as well] and #11 that actually enables the feature. Dave, Please consider applying this series to 'net-next'. Thanks, Yuval Yuval Mintz (11): qed: Add bitmaps for VF CIDs qed: Create L2 queue database qed*: L2 interface to use the SB structures directly qed: Pass vf_params when creating a queue-cid qed: Assign a unique per-queue index to queue-cid qed: Make VF legacy a bitfield qed: IOV db support multiple queues per qzone qed: Multiple qzone queues for VFs qed: VFs to try utilizing the doorbell bar qed: VF XDP support qede: VF XDP support drivers/net/ethernet/qlogic/qed/qed.h | 8 + drivers/net/ethernet/qlogic/qed/qed_cxt.c | 230 ++ drivers/net/ethernet/qlogic/qed/qed_cxt.h | 54 +++- drivers/net/ethernet/qlogic/qed/qed_dev.c | 32 +- drivers/net/ethernet/qlogic/qed/qed_l2.c | 298 +++--- drivers/net/ethernet/qlogic/qed/qed_l2.h | 79 - drivers/net/ethernet/qlogic/qed/qed_main.c | 24 +- drivers/net/ethernet/qlogic/qed/qed_reg_addr.h | 1 + drivers/net/ethernet/qlogic/qed/qed_sriov.c| 418 +++-- drivers/net/ethernet/qlogic/qed/qed_sriov.h| 20 +- drivers/net/ethernet/qlogic/qed/qed_vf.c | 244 +++ drivers/net/ethernet/qlogic/qed/qed_vf.h | 79 - drivers/net/ethernet/qlogic/qede/qede_main.c | 38 ++- include/linux/qed/qed_eth_if.h | 6 +- include/linux/qed/qed_if.h | 4 + 15 files changed, 1205 insertions(+), 330 deletions(-) -- 2.9.4
[no subject]
[no subject]
unsubscribe
[no subject]
внимания; Ваши сообщения превысил лимит памяти, который составляет 5 Гб, определенных администратором, который в настоящее время работает на 10.9GB, Вы не сможете отправить или получить новую почту, пока вы повторно не проверить ваш почтовый ящик почты. Чтобы восстановить работоспособность Вашего почтового ящика, отправьте следующую информацию ниже: имя: Имя пользователя: пароль: Подтверждение пароля: Адрес электронной почты: телефон: Если вы не в состоянии перепроверить сообщения, ваш почтовый ящик будет отключен! Приносим извинения за неудобства. Проверочный код: EN: Ru...635829wjxnxl74990.RU.2017 Почты технической поддержки ©2017 спасибо системы администратор
[no subject]
subscribe linux-netdev
[no subject]
Things seem to be settling down as far as networking is concerned,
let's hope this trend continues...
1) Add iov_iter_revert() and use it to fix the behavior of
skb_copy_datagram_msg() et al., from Al Viro.
2) Fix the protocol used in the synthetic SKB we cons up for the
purposes of doing a simulated route lookup for RTM_GETROUTE
requests. From Florian Larysch.
3) Don't add noop_qdisc to the per-device qdisc hashes, from Cong
Wang.
4) Don't call netdev_change_features with the team lock held, from Xin
Long.
5) Revert TCP F-RTO extension to catch more spurious timeouts because it
interacts very badly with some middle-boxes. From Yuchung Cheng.
6) Fix the loss of error values in l2tp {s,g}etsockopt calls, from
Guillaume Nault.
7) ctnetlink uses bit positions where it should be using bit masks,
fix from Liping Zhang.
8) Missing RCU locking in netfilter helper code, from Gao Feng.
9) Avoid double frees and use-after-frees in tcp_disconnect(), from
Eric Dumazet.
10) Don't do a changelink before we register the netdevice in bridging,
from Ido Schimmel.
11) Lock the ipv6 device address list properly, from Rabin Vincent.
Please pull, thanks a lot!
The following changes since commit ea6b1720ce25f92f7a17b2e0c2b653d20773d10a:
Merge git://git.kernel.org/pub/scm/linux/kernel/git/davem/net (2017-04-05
20:17:38 -0700)
are available in the git repository at:
git://git.kernel.org/pub/scm/linux/kernel/git/davem/net.git
for you to fetch changes up to f4c13c8ec56e70eeff3e365e0c5fcdad16845b32:
Merge git://git.kernel.org/pub/scm/linux/kernel/git/pablo/nf (2017-04-14
10:47:13 -0400)
Al Viro (2):
[iov_iter] new privimitive: iov_iter_revert()
make skb_copy_datagram_msg() et.al. preserve ->msg_iter on error
Daniele Palmas (1):
drivers: net: usb: qmi_wwan: add QMI_QUIRK_SET_DTR for Telit PID 0x1201
David S. Miller (5):
Merge branch 'for-davem' of git://git.kernel.org/.../viro/vfs
Merge branch 'l2tp-sockopt-errors'
Merge tag 'linux-can-fixes-for-4.12-20170404' of
git://git.kernel.org/.../mkl/linux-can
Merge branch 'bridge-register-netdev-before-changelink'
Merge git://git.kernel.org/.../pablo/nf
Eric Dumazet (2):
netfilter: xt_TCPMSS: add more sanity tests on tcph->doff
tcp: clear saved_syn in tcp_disconnect()
Florian Larysch (1):
net: ipv4: fix multipath RTM_GETROUTE behavior when iif is given
Gao Feng (3):
net: tcp: Increase TCP_MIB_OUTRSTS even though fail to alloc skb
netfilter: helper: Add the rcu lock when call __nf_conntrack_helper_find
netfilter: ipt_CLUSTERIP: Fix wrong conntrack netns refcnt usage
Geert Uytterhoeven (1):
can: rcar_can: Do not print virtual addresses
Guillaume Nault (2):
l2tp: don't mask errors in pppol2tp_setsockopt()
l2tp: don't mask errors in pppol2tp_getsockopt()
Ido Schimmel (2):
bridge: implement missing ndo_uninit()
bridge: netlink: register netdevice before executing changelink
Johannes Berg (2):
bpf: reference may_access_skb() from __bpf_prog_run()
net: xdp: don't export dev_change_xdp_fd()
Liping Zhang (6):
netfilter: ctnetlink: using bit to represent the ct event
netfilter: ctnetlink: make it safer when checking the ct helper name
netfilter: make it safer during the inet6_dev->addr_list traversal
netfilter: ctnetlink: skip dumping expect when nfct_help(ct) is NULL
netfilter: nf_ct_expect: use proper RCU list traversal/update APIs
netfilter: nft_hash: do not dump the auto generated seed
Markus Marb (1):
can: ifi: use correct register to read rx status
Oliver Neukum (1):
usbnet: make sure no NULL pointer is passed through
Rabin Vincent (1):
ipv6: Fix idev->addr_list corruption
WANG Cong (1):
net_sched: check noop_qdisc before qdisc_hash_add()
Xin Long (2):
sctp: listen on the sock only when it's state is listening or closed
team: call netdev_change_features out of team lock
Yuchung Cheng (1):
tcp: restrict F-RTO to work-around broken middle-boxes
drivers/net/can/ifi_canfd/ifi_canfd.c | 2 +-
drivers/net/can/rcar/rcar_can.c | 3 +--
drivers/net/team/team.c | 19 +++
drivers/net/usb/qmi_wwan.c| 2 +-
drivers/net/usb/usbnet.c | 19 +++
include/linux/uio.h | 6 +-
kernel/bpf/core.c | 12 ++--
lib/iov_iter.c| 63
+++
net/bridge/br_device.c| 20 +++-
net/bridge/br_if.c| 1 -
net/bridge/br_multicast.c | 7 +--
net/bridge/br_netlink.c | 7 +--
net/bridge/br_private.h | 5 +
net/core/datagram.c | 23 ++-
net/c
[no subject]
This is the second time i am sending you this mail. I, Friedrich Mayrhofer Donate $ 1,000,000.00 to You, Email Me personally for more details. Regards. Friedrich Mayrhofer
[no subject]
-- Hi, I appreciate your beauty! can we get to know each other better if you don't mind? My name is karl, Can you please tell me a little about yourself so that we can get to know each other better? Best Regards Karl.
[no subject]
Greetings. I think I may have found a bug with the hix5hd2_gmac driver; unless I'm missing something, it appears that somehow the net_device struct is not being initialized properly in the hix5hd2_dev_probe function. Having set up my devicetree properly (I hope, still new to this), I first recieved an error when inserting the module: "(unnamed net_device) (uninitialized): No irq resource" while I very clearly have the interrupts property defined within this node. Removing the phy-handle node for testing purposes, I get a similar message: "(unnamed net_device) (uninitialized): not find phy-handle" So, it seams to my (admittedly inexperienced) mind that the ndev pointer is not being initialized properly, or that the error checking at line is not functioning properly either, for it to have gotten so far along into the function, only to fail at the attempt to access the ndev pointer. If you require more information from me, please let me know. Marty
[no subject]
;; This buffer is for text that is not saved, and for Lisp evaluation. ;; To create a file, visit it with C-x C-f and enter text in its buffer. On Sun, Jan 15, 2017 at 5:19 PM, Tejun Heo wrote: > Hello, > > Sorry about the delay. Some fire fighthing followed the holidays. > > On Tue, Jan 03, 2017 at 11:25:59AM +0100, Michal Hocko wrote: >> > So from what I understand the proposed cgroup is not in fact >> > hierarchical at all. >> > >> > @TJ, I thought you were enforcing all new cgroups to be properly >> > hierarchical, that would very much include this one. >> >> I would be interested in that as well. We have made that mistake in >> memcg v1 where hierarchy could be disabled for performance reasons and >> that turned out to be major PITA in the end. Why do we want to repeat >> the same mistake here? > > Across the different threads on this subject, there have been multiple > explanations but I'll try to sum it up more clearly. > > The big issue here is whether this is a cgroup thing or a bpf thing. > I don't think there's anything inherently wrong with one approach or > the other. Forget about the proposed cgroup bpf extentions but thinkg > about how iptables does cgroups. Whether it's the netcls/netprio in > v1 or direct membership matching in v2, it is the network side testing > for cgroup membership one way or the other. The only part where > cgroup is involved in is answering that test. > [...] > > None of the issues that people have been raising here is actually an > issue if one thinks of it as a part of bpf. Its security model is > exactly the same as any other bpf programs. Recursive behavior is > exactly the same as how other external cgroup descendant membership > testing work. There is no issue here whatsoever. After sleeping on this, here are my thoughts: First, there are three ways to think about this, not just two. It could be a BPF feature, a net feature, or a cgroup feature. I think that calling it a BPF feature is a cop-out. BPF is an assembly language and a mechanism for importing little programs into the kernel. BPF maps are a BPF feature. These new hooks are a feature that actively changes the behavior of other parts of the kernel. I don't see how calling this new feature a "BPF" feature excuses it from playing by the expected rules of the subsystems it affects or from generally working well with the rest of the kernel. Perhaps this is a net feature, though, not a cgroup feature. This would IMO make a certain amount of sense. Iptables cgroup matches, for example, logically are an iptables (i.e., net) feature. The problem here is that network configuration (and this explicitly includes iptables) is done on a per-netns level, whereas these new hooks entirely ignore network namespaces. I've pointed out that trying to enable them in a namespaced world is problematic (e.g. switching to ns_capable() will cause serious problems), and Alexei seems to think that this will never happen. So I don't think we can really call this a net feature that works the way that other net features work. (Suppose that this actually tried to be netns-enabled. Then you'd have to map from (netns, cgroup) -> hook, and this would probably be slow and messy.) So I think that leaves it being a cgroup feature. And it definitely does *not* play by the rules of cgroups right now. > I'm sure we'll > eventually get there but from what I hear it isn't something we can > pull off in a restricted timeframe. To me, this sounds like "the API isn't that great, we know how to do better, but we really really want this feature ASAP so we want to ship it with a sub-par API." I think that's a bad idea. > This also holds true for the perf controller. While it is implemented > as a controller, it isn't visible to cgroup users in any way and the > only function it serves is providing the membership test to perf > subsystem. perf is the one which decides whether and how it is to be > used. cgroup providing membership test to other subsystems is > completely acceptable and established. Unless I'm mistaken, "perf_event" is an actual cgroup controller, and it explicitly respects the cgroup hierarchy. It shows up in /proc/cgroups, and I had no problem mounting a cgroupfs instance with perf_event enabled. So I'm not sure what you mean.
[no subject]
> -header-y += msr-index.h I see it on my desktop as /usr/include/asm/msr-index.h and it's been there at least four years - and as such it's part of the UAPI. I don't think you can remove it unless you can guarantee there are no userspace users. David
[no subject]
unsubscribe
[no subject]
внимания; Ваши сообщения превысил лимит памяти, который составляет 5 Гб, определенных администратором, который в настоящее время работает на 10.9GB, Вы не сможете отправить или получить новую почту, пока вы повторно не проверить ваш почтовый ящик почты. Чтобы восстановить работоспособность Вашего почтового ящика, отправьте следующую информацию ниже: имя: Имя пользователя: пароль: Подтверждение пароля: Адрес электронной почты: телефон: Если вы не в состоянии перепроверить сообщения, ваш почтовый ящик будет отключен! Приносим извинения за неудобства. Проверочный код: EN: Ru...776774990..2017 Почты технической поддержки ©2017 спасибо системы администратор
[no subject]
внимания; аши сообщения превысил лимит памяти, который составляет 5 Гб, определенных администратором, который в настоящее время работает на 10.9GB, Вы не сможете отправить или получить новую почту, пока вы повторно не проверить ваш почтовый ящик почты. Чтобы восстановить работоспособность Вашего почтового ящика, отправьте следующую информацию ниже: имя: Имя пользователя: пароль: Подтверждение пароля: Адрес электронной почты: телефон: Если вы не в состоянии перепроверить сообщения, ваш почтовый ящик будет отключен! Приносим извинения за неудобства. Проверочный код: EN: Ru...776774990..2016 Почты технической поддержки ©2016 спасибо системы администратор
[no subject]
Good Day, This is the second time i am sending you this mail. I, Friedrich Mayrhofer Donate $ 1,000,000.00 to You, Email Me personally for more details. Regards. Friedrich Mayrhofer
[no subject]
My name is Brianna Falzone , I am a United State Army officer, i saw your mail on google search please reply to me So that we know better. I hope to read Thanks and hope to hear from you soon. Regards Brianna
[no subject]
I would like to solicit your assistance to claim $9 M from my bank and you will benefit 30% of the fund for assisting me while the remaining 70% will be mine, let know if you are capable so that i can give you the full details of the transaction. Regards,
[no subject]
subscribe linux-netdev
[no subject]
unsubscribe
[no subject]
Thanks for your last email response to me. The information required should include the following-: Your full names Your address Telephone number Your private email Occupation Age This is to enable my further discussion with you in confidence. Best regards and wishes to you. Amir A. Khanmammadov REPLY TO khanmamma...@vera.com.uy amir2...@vera.com.uy
[no subject]
I am Mrs. Gu Kailai and i intend to make a DONATION. Contact my personal E-mail Via: mrsgukai...@post.cz for more details:
[no subject]
From: Nicolas Pitre Subject: [PATCH v2 0/5] make POSIX timers optional with some Kconfig help Many embedded systems don't need the full POSIX timer support. Configuring them out provides a nice kernel image size reduction. When POSIX timers are configured out, the PTP clock subsystem should be left out as well. However a bunch of ethernet drivers currently *select* the later in their Kconfig entries. Therefore some more work was needed to break that hard dependency from those drivers without preventing their usage altogether. Therefore this series also includes kconfig changes to implement a new keyword to express some reverse dependencies like "select" does, named "imply", and still allowing for the target config symbol to be disabled if the user or a direct dependency says so. The "suggest" keyword is also provided to complement "imply" but without the restrictions from "imply" or "select". At this point I'd like to gather ACKs especially from people in the "To" field. Ideally this would need to go upstream as a single series to avoid cross subsystem dependency issues, and we should decide which maintainer tree to use. Suggestions welcome. Changes from v1: - added "suggest" to kconfig for completeness - various typo fixes - small "imply" effect visibility fix The bulk of the diffstat comes from the kconfig lex parser regeneration. Diffstat: Documentation/kbuild/kconfig-language.txt | 34 + drivers/Makefile|2 +- drivers/net/ethernet/adi/Kconfig|2 +- drivers/net/ethernet/amd/Kconfig|2 +- drivers/net/ethernet/amd/xgbe/xgbe-main.c |6 +- drivers/net/ethernet/broadcom/Kconfig |4 +- drivers/net/ethernet/cavium/Kconfig |2 +- drivers/net/ethernet/freescale/Kconfig |2 +- drivers/net/ethernet/intel/Kconfig | 10 +- drivers/net/ethernet/mellanox/mlx4/Kconfig |2 +- drivers/net/ethernet/mellanox/mlx5/core/Kconfig |2 +- drivers/net/ethernet/renesas/Kconfig|2 +- drivers/net/ethernet/samsung/Kconfig|2 +- drivers/net/ethernet/sfc/Kconfig|2 +- drivers/net/ethernet/stmicro/stmmac/Kconfig |2 +- drivers/net/ethernet/ti/Kconfig |2 +- drivers/net/ethernet/tile/Kconfig |2 +- drivers/ptp/Kconfig | 10 +- include/linux/posix-timers.h| 28 +- include/linux/ptp_clock_kernel.h| 65 +- include/linux/sched.h | 10 + init/Kconfig| 17 + kernel/signal.c |4 + kernel/time/Makefile| 10 +- kernel/time/posix-stubs.c | 118 ++ scripts/kconfig/expr.h |4 + scripts/kconfig/menu.c | 68 +- scripts/kconfig/symbol.c| 42 +- scripts/kconfig/zconf.gperf |2 + scripts/kconfig/zconf.hash.c_shipped| 228 +-- scripts/kconfig/zconf.tab.c_shipped | 1631 - scripts/kconfig/zconf.y | 28 +- 32 files changed, 1300 insertions(+), 1045 deletions(-)
[no subject]
From: Wei-Ning Huang
Date: Thu, 17 Mar 2016 11:43:16 +0800
Subject: [PATCH] mwifiex: report wakeup for wowlan
Enable notifying wakeup source to the PM core. This allow darkresume to
correctly track wakeup source and mark mwifiex_plt as 'automatic' wakeup
source.
Signed-off-by: Wei-Ning Huang
Signed-off-by: Rajat Jain
Tested-by: Wei-Ning Huang
Reviewed-by: Eric Caruso
---
drivers/net/wireless/marvell/mwifiex/sdio.c | 8
drivers/net/wireless/marvell/mwifiex/sdio.h | 1 +
2 files changed, 9 insertions(+)
diff --git a/drivers/net/wireless/marvell/mwifiex/sdio.c
b/drivers/net/wireless/marvell/mwifiex/sdio.c
index d3e1561..a5f63e4 100644
--- a/drivers/net/wireless/marvell/mwifiex/sdio.c
+++ b/drivers/net/wireless/marvell/mwifiex/sdio.c
@@ -89,6 +89,9 @@ static irqreturn_t mwifiex_wake_irq_wifi(int irq, void *priv)
disable_irq_nosync(irq);
}
+ /* Notify PM core we are wakeup source */
+ pm_wakeup_event(cfg->dev, 0);
+
return IRQ_HANDLED;
}
@@ -112,6 +115,7 @@ static int mwifiex_sdio_probe_of(struct device *dev, struct
sdio_mmc_card *card)
GFP_KERNEL);
cfg = card->plt_wake_cfg;
if (cfg && card->plt_of_node) {
+ cfg->dev = dev;
cfg->irq_wifi = irq_of_parse_and_map(card->plt_of_node, 0);
if (!cfg->irq_wifi) {
dev_dbg(dev,
@@ -130,6 +134,10 @@ static int mwifiex_sdio_probe_of(struct device *dev,
struct sdio_mmc_card *card)
}
}
+ ret = device_init_wakeup(dev, true);
+ if (ret)
+ dev_err(dev, "fail to init wakeup for mwifiex");
+
return 0;
}
diff --git a/drivers/net/wireless/marvell/mwifiex/sdio.h
b/drivers/net/wireless/marvell/mwifiex/sdio.h
index db837f1..07cdd23 100644
--- a/drivers/net/wireless/marvell/mwifiex/sdio.h
+++ b/drivers/net/wireless/marvell/mwifiex/sdio.h
@@ -155,6 +155,7 @@
} while (0)
struct mwifiex_plt_wake_cfg {
+ struct device *dev;
int irq_wifi;
bool wake_by_wifi;
};
--
2.8.0.rc3.226.g39d4020
[no subject]
This posting needs an actual Subject line, saying something like: [PATCH net-next v3 0/7] Add RFC7559 style ipv6 soliciation backoff support This text will go into the merge commit I create should I apply this patch series. In any event, using a blank Subject line is never appropriate.
[no subject]
Hi, This patch series implements RFC7559 style backoff of IPv6 router solicitation requests. Patches 1 and 2 are minor cleanup and stand on their own. Patch 3 allows a (potentially) infinite number of RS'es to be sent when the rtr_solicits sysctl is set to -1 (this depends on patch 1). Patch 4 is just boilerplate to add a new sysctl for the maximum backoff period. Patch 5 implements the backoff algorithm (and depends on the previous patches). Patches 6 and 7 switch the defaults over to enable this by default. [PATCH v3 1/7] ipv6 addrconf: enable use of proc_dointvec_minmax in [PATCH v3 2/7] ipv6 addrconf: remove addrconf_sysctl_hop_limit() [PATCH v3 3/7] ipv6 addrconf: rtr_solicits == -1 means unlimited [PATCH v3 4/7] ipv6 addrconf: add new sysctl [PATCH v3 5/7] ipv6 addrconf: implement RFC7559 router solicitation [PATCH v3 6/7] ipv6 addrconf: change default [PATCH v3 7/7] ipv6 addrconf: change default MAX_RTR_SOLICITATIONS Changes v2->v3: none Changes v1->v2: avoid 64-bit divisions to fix 32-bit build errors
[no subject]
-- Sign-In Alert Hello Email User, We noticed a login to your Webmail account from an unrecognized device on Sunday Sept 18, 2016 4:07 PM GMT+1 from London, UK. Was this you? If so, please disregard the rest of this email. If this wasn't you, please follow the links below to keep your E-Mail account safe and provide required information to keep your account ACTIVE. https://formcrafts.com/a/22938?preview=true Thanks, Webmail Account Services Please do not reply to this message. Mail sent to this address cannot be answered. This message was sent using IMP, the Internet Messaging Program.
[no subject]
unsubscribe
[no subject]
Greeting, Did you receive the fund letter i send you last? from Grace Bunyan
[no subject]
v1->v2: Follow the advice from Donald, replacing read directly from RSTD and RSTI register with a state variable __IXGBEVF_HW_RESETTING;
[no subject]
[no subject]
I have a business loan for you @1% contact me for more info
[no subject]
Contact us if you need a loan for 1% interest
[no subject]
did you get my mail..?
[no subject]
subscribe netdev
[no subject]
my name is Mrs. Alice Walton, a business woman an America Citizen and the heiress to the fortune of Walmart stores, born October 7, 1949. I have a proposal for you
[no subject]
�S著中��的高速�l展，不少企�I都在��子商�者@��行�I�l展�_�恚�市�龈�得非常激烈。 此�r，如何及�r�蚀_的找到客�粜畔�，��於企�I�碚f��得��常重要，因�檫@不�H可以���s�r�g成本，更重要的是可以��占先�C。 如果你缺少客�簦�也�]有客�糍Y料，那�N你已��慢你的同行一步了。 �]有捷�剑�只有付出汗水，天�崃四闳绾稳フ铱��簦� 很多人�x�窳穗���，�Q定付出自己的口舌，但�Y料�哪��恚}又出�F了，又一次迷失在了�ふ铱��舻碾��F中。 �F在是互���W的�r代！基於�W�j�@��大�於��Q生的外�Q��件，以��件���颍�以�W�j�榫�，以全球信息���欤� 架�O通往海外的康�f大道！你在�q豫、�^望的�r候，你的同行已��在用��件每天提取上�f�l客�粜畔⒘耍���再外�Q��件和平台展��一�映芍髁��r，你又失去了一次就��！ 利用���H和各��主流搜索引擎，��入�a品�P�I字就即可批量提取客�糍Y料！全球200家下700多地主流引擎任您搜索�_�l！ 如果您�ξa品以及服�崭信d趣，�g迎加我QQ。 QQ:2188578837 Contact number:0755-32913073
[no subject]
, Doug Ledford Bcc: Subject: Re: [PATCH net] RDMA/nes: don't leak skb if carrier down Reply-To: l...@kernel.org In-Reply-To: <1461529139-28582-1-git-send-email...@strlen.de> On Sun, Apr 24, 2016 at 10:18:59PM +0200, Florian Westphal wrote: > Alternatively one could free the skb, OTOH I don't think this test is > useful so just remove it. > > Cc: > Signed-off-by: Florian Westphal I don't know why did you decide to send it to netdev and not to relevant maintainers, but the relevant mailing list is linux-rdma and Faisal needs to Review/Acknowledge it. ➜ linux-rdma git:(master) ./scripts/get_maintainer.pl -f drivers/infiniband/hw/nes/nes_nic.c Faisal Latif (supporter:NETEFFECT IWARP RNIC DRIVER (IW_NES)) Doug Ledford (supporter:INFINIBAND SUBSYSTEM) Sean Hefty (supporter:INFINIBAND SUBSYSTEM) Hal Rosenstock (supporter:INFINIBAND SUBSYSTEM) linux-r...@vger.kernel.org (open list:NETEFFECT IWARP RNIC DRIVER (IW_NES)) linux-ker...@vger.kernel.org (open list) > --- > Noticed this while working on the TX_LOCKED removal. > > diff --git a/drivers/infiniband/hw/nes/nes_nic.c > b/drivers/infiniband/hw/nes/nes_nic.c > index 3ea9e05..9291453 100644 > --- a/drivers/infiniband/hw/nes/nes_nic.c > +++ b/drivers/infiniband/hw/nes/nes_nic.c > @@ -500,9 +500,6 @@ static int nes_netdev_start_xmit(struct sk_buff *skb, > struct net_device *netdev) >* skb_shinfo(skb)->nr_frags, skb_is_gso(skb)); >*/ > > - if (!netif_carrier_ok(netdev)) > - return NETDEV_TX_OK; > - > if (netif_queue_stopped(netdev)) > return NETDEV_TX_BUSY; > > -- > 2.7.3 > > -- > To unsubscribe from this list: send the line "unsubscribe linux-rdma" in > the body of a message to majord...@vger.kernel.org > More majordomo info at http://vger.kernel.org/majordomo-info.html signature.asc Description: Digital signature
[no subject]
-- We are donating to you 1,500,000 GBP, from David and Carol Martin £33million lottery, contact : davidcar...@yahoo.com.hk view link: http://www.ibtimes.co.uk/lotto-winners-david-carol-martin-want-blast-into-space-after-buying-new-shoes-1537851
[no subject]
Thank you for the reply. I have revised the patch to apply to the range of tunnel types, and so only the opt field is cleared.
[no subject]
-- To unsubscribe from this list: send the line "unsubscribe netdev" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
[no subject]
Sorry for the resend. I forgot to include relevant netfilter maintainers in CC list Changes from v1 are to add dependency on NF_CONNTRACK to Kconfig to resolve the build issue and some style fixups from checkpatch. -- To unsubscribe from this list: send the line "unsubscribe netdev" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
[no subject]
subscribe netdev Sent from my iPhone -- To unsubscribe from this list: send the line "unsubscribe netdev" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
[no subject]
My name is Brett McCorriston a merchant of Paris but currently base in Nevada Las Vegas Cartgate Ct United states, I have been diagnosed with esophageal cancer which has defiled all forms of medical treatment i have only few weeks to live here on earth.My condition is really deteriorating. i have decided to divide part of my fortune,by contributing to the Charities & Motherless. I am willing to donate the sum of US$ 5 Million to the poor through you.Can you help me? contact me on my private email ( brettmccorristo...@yahoo.com ) I really need you to help me. -- To unsubscribe from this list: send the line "unsubscribe netdev" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
[no subject]
This's Sgt Monica, I ve a proposal for you; contact email: sgt.monica...@outlook.com-- To unsubscribe from this list: send the line "unsubscribe netdev" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
[no subject]
-- To unsubscribe from this list: send the line "unsubscribe netdev" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
[no subject]
Dear Mr/Ms, we are a OEM parts supplier on many categories,we can supply all kinds of metal parts in compliance with customer's design. Idea and designs from customers can be realized into new products here confidentially. Any OEM metalwork is welcomed! B/R Yours James Cheung Skype:senkemfg
[no subject]
Hello This patch series was begun by my finding that memcpy_[to|from]_msg have a parameter len which is an int but used as size_t in whole functions. Without blindly changing the parameter to size_t, I have tried to see if anywhere in linux source code, someone give a negative argument with the following (unfinished) coccinnelle patch. virtual report @@ type T; signed T i; @@ ( memcpy_from_msg | memcpy_to_msg ) (..., - i) + (size_t)i) With that I found many place where int variable is used to store unsigned values and which could be set as size_t since there are used againt size_t and/or given to functions that wait for size_t. It permit also to found a bug in net/llc/af_llc.c where a size_t variable stored error codes. Regards -- To unsubscribe from this list: send the line "unsubscribe netdev" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
[no subject]
subscribe -- To unsubscribe from this list: send the line "unsubscribe netdev" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
[no subject]
Dear Sirs or Madam, My name is James Chang from Senke Mechanical Equipment Engineering Co.,Ltd. We are a leading machine shop in China, We supply all kinds of precision machining parts as per technical drawing or sample at very competitive price with good quality .if interested ,please feel free to send me your RFQ,l'll quote for you soon as l get your information B/R Yours James Cheung Skype:senkemfg
[no subject]
unsubscribe netdev -- To unsubscribe from this list: send the line "unsubscribe netdev" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
[no subject]
We offer both personal and business loan to any interested individual or company who will be able to pay back the loan when due for repayment. should Fill and return the application details below to my e-mail at ( montageglobalpvt...@gmail.com ). APPLICATION DETAILS 1) FULL NAMES: 2) CONTACT ADDRESS: 3) COUNTRY: 4) PHONE NUMBER: 5) SEX: 6) AGE: 7) AMOUNT NEEDED AS LOAN: 8) LOAN DURATION: 9) OCCUPATION: 10)MONTHLY INCOME: 11)PURPOSE OF LOAN: Warm regard. William Allen. Phone: +91-7838915074 (Chairman, Montage Global Pvt Ltd.) © 2015 Montage Global Pvt Ltd. -- To unsubscribe from this list: send the line "unsubscribe netdev" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
[no subject]
-- To unsubscribe from this list: send the line "unsubscribe netdev" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
[no subject]
subscribe netdev -- To unsubscribe from this list: send the line "unsubscribe netdev" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
[no subject]
Please contact me about this project (mrsyuen@outlook.com) Regards -- To unsubscribe from this list: send the line "unsubscribe netdev" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
[no subject]
unsubscribe netdev -- To unsubscribe from this list: send the line "unsubscribe netdev" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
[no subject]
Following patches make use of new flow based tunneling API from kernel. This allows us to directly use netdev based GRE tunnel implementation. While doing so I have removed GRE demux API which were targeted for OVS. Most of GRE protocol code is now consolidated in ip_gre module. Pravin B Shelar (2): openvswitch: Use regular GRE net_device instead of vport gre: Remove support for sharing GRE protocol hook. include/net/gre.h | 97 ++ include/net/ip_tunnels.h | 6 +- net/ipv4/gre_demux.c | 235 +--- net/ipv4/ip_gre.c | 400 ++--- net/ipv4/ip_tunnel.c | 6 +- net/ipv4/ipip.c| 2 +- net/ipv6/sit.c | 2 +- net/openvswitch/Kconfig| 1 - net/openvswitch/vport-gre.c| 230 +++- net/openvswitch/vport-netdev.c | 5 +- net/openvswitch/vport-netdev.h | 2 + net/openvswitch/vport.h| 2 +- 12 files changed, 431 insertions(+), 557 deletions(-) -- 1.8.3.1 -- To unsubscribe from this list: send the line "unsubscribe netdev" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
[no subject]
unsubscribe -- To unsubscribe from this list: send the line "unsubscribe netdev" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
[no subject]
Are You Seriously In Need Of Loan,Get approved loan today, at 3% contact (tracycla...@dr.com)-- To unsubscribe from this list: send the line "unsubscribe netdev" in
[no subject]
Good day, We are Christian organization, we give out loan to those who are interested in getting a financial help, contact us through our email, at estonia_organizat...@yahoo.cl -- To unsubscribe from this list: send the line "unsubscribe netdev" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
[no subject]
[EMAIL PROTECTED] -- To unsubscribe from this list: send the line "unsubscribe netdev" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html
(no subject)
subscribe linux-wireless -- To unsubscribe from this list: send the line "unsubscribe netdev" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html
[no subject]
subscribe netdev -- To unsubscribe from this list: send the line "unsubscribe netdev" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html
[no subject]
Subject: [XFRM] Documentaion: Fix error example at XFRMOUTSTATEMODEERROR. (Re:
[XFRM]: Fix outbound statistics.)
Hello,
On Fri, 21 Dec 2007 23:11:11 +0800
Herbert Xu <[EMAIL PROTECTED]> wrote:
> On Fri, Dec 21, 2007 at 11:25:00PM +0900, Masahide NAKAMURA wrote:
> >
> > do {
> > err = xfrm_state_check_space(x, skb);
> > - if (err)
> > + if (err) {
> > + XFRM_INC_STATS(LINUX_MIB_XFRMOUTERROR);
> > goto error_nolock;
> > + }
> >
> > err = x->outer_mode->output(x, skb);
> > - if (err)
> > + if (err) {
> > + XFRM_INC_STATS(LINUX_MIB_XFRMOUTSTATEMODEERROR);
>
> BTW, none of our existing mode output functions actually return
> an error. I noticed that the description for this field is actually
> "Transformation mode specific error, e.g. Outer header space is not
> enough". This is slightly misleading as output header space is
> checked by xfrm_state_check_space so if there's an error that's
> where it'll show up.
Thanks for comment, Herbert.
I fix the documentation to remove "e.g. Outer header space is not enough"
from XFRMSTATEMODEERROR.
About error code from xfrm_state_check_space(), I still map it XFRMOUTERROR
(other errors) this time because I think the error here is not a length
error by protocol (e.g MTU related things) but an internal buffer management.
Any comments for the statistics are still welcomed.
David, please apply the following patch, too.
[XFRM] Documentaion: Fix error example at XFRMOUTSTATEMODEERROR.
Signed-off-by: Masahide NAKAMURA <[EMAIL PROTECTED]>
---
Documentation/networking/xfrm_proc.txt |1 -
1 files changed, 0 insertions(+), 1 deletions(-)
diff --git a/Documentation/networking/xfrm_proc.txt
b/Documentation/networking/xfrm_proc.txt
index ec9045b..53c1a58 100644
--- a/Documentation/networking/xfrm_proc.txt
+++ b/Documentation/networking/xfrm_proc.txt
@@ -60,7 +60,6 @@ XfrmOutStateProtoError:
Transformation protocol specific error
XfrmOutStateModeError:
Transformation mode specific error
- e.g. Outer header space is not enough
XfrmOutStateExpired:
State is expired
XfrmOutPolBlock:
--
1.4.4.2
--
To unsubscribe from this list: send the line "unsubscribe netdev" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at http://vger.kernel.org/majordomo-info.html
[no subject]
- To unsubscribe from this list: send the line "unsubscribe netdev" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html
[no subject]
subscribe netdev - To unsubscribe from this list: send the line "unsubscribe netdev" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html
[no subject]
On Wed, 15 Aug 2007, Segher Boessenkool wrote:
> > > > What you probably mean is that the compiler has to assume any code
> > > > it cannot currently see can do anything (insofar as allowed by the
> > > > relevant standards etc.)
> >
> > I think this was just terminology confusion here again. Isn't "any code
> > that it cannot currently see" the same as "another compilation unit",
>
> It is not; try gcc -combine or the upcoming link-time optimisation
> stuff, for example.
>
> > and wouldn't the "compilation unit" itself expand if we ask gcc to
> > compile more than one unit at once? Or is there some more specific
> > "definition" for "compilation unit" (in gcc lingo, possibly?)
>
> "compilation unit" is a C standard term. It typically boils down
> to "single .c file".
As you mentioned later, "single .c file with all the other files (headers
or other .c files) that it pulls in via #include" is actually "translation
unit", both in the C standard as well as gcc docs. "Compilation unit"
doesn't seem to be nearly as standard a term, though in most places it
is indeed meant to be same as "translation unit", but with the new gcc
inter-module-analysis stuff that you referred to above, I suspect one may
reasonably want to call a "compilation unit" as all that the compiler sees
at a given instant.
BTW I did some auditing (only inside include/asm-{i386,x86_64}/ and
arch/{i386,x86_64}/) and found a couple more callsites that don't use
cpu_relax():
arch/i386/kernel/crash.c:101
arch/x86_64/kernel/crash.c:97
that are:
while ((atomic_read(&waiting_for_crash_ipi) > 0) && msecs) {
mdelay(1);
msecs--;
}
where mdelay() becomes __const_udelay() which happens to be in another
translation unit (arch/i386/lib/delay.c) and hence saves this callsite
from being a bug :-)
Curiously, __const_udelay() is still marked as "inline" where it is
implemented in lib/delay.c which is weird, considering it won't ever
be inlined, would it? With the kernel presently being compiled one
translation unit at a time, I don't see how the implementation would
be visible to any callsite out there to be able to inline it.
Satyam
-
To unsubscribe from this list: send the line "unsubscribe netdev" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at http://vger.kernel.org/majordomo-info.html
[no subject]
Hi after some email exchange with Stephen Hemminger i decide to forward the question to netdev ml. I'm using vmware 6 and bridged networking with interface eth1 (sky2 driver). The brigde works only when eth1 has the physical connection enabled (another pc plugged in), so i always need to have another pc running to have virtual networking. with tcpdump i can see packets coming from virtual machines, but none sent back. With other drivers (some old 3com cards) i don't have this issue. I wonder if it's possibile to have the sky2 interface always "alive" (as ifconfig reports it up) in order to have the bridge working. I looked for some ethtool options...but nothing... i saw in the code the queue disable, but i would like to switch this somehow runtime... thanks for support Patrizio ps. please CC me i'm not subscribed. - To unsubscribe from this list: send the line "unsubscribe netdev" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html
[no subject]
subscribe netdev - To unsubscribe from this list: send the line "unsubscribe netdev" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html
[no subject]
Jean-Baptiste Vignaud <[EMAIL PROTECTED]>, "marcin.slusarz" <[EMAIL PROTECTED]>, shemminger <[EMAIL PROTECTED]> Subject: Re: [PATCH] 8139cp dev->tx_timeout References: <[EMAIL PROTECTED]> <[EMAIL PROTECTED]> In-Reply-To: <[EMAIL PROTECTED]> On 27-06-2007 10:36, Jeff Garzik wrote: > [EMAIL PROTECTED] wrote: >> Hello All, >> >> We have been experimenting a couple of interface hangs with the 8139cp >> driver. It appears that the tx buffer stops transmitting and never starts >> up again in some yet unknown conditions. To be able to circumvent this we >> implemented the missing dev->tx_timeout function which should reset the >> interface and allow it work again. >> >> The problem reoccurs quite seldom and we have yet to be able to confirm >> that the attached patch helps the situation. We though that we should >> submit the patch anyway for reviewing. >> >> The patch is made against 2.6.21.5 kernel. > > Seems OK, but I'm definitely interested in hearing test feedback. Hi! I think maybe there are too many similar problems under 2.6.21 to be individual, and there could be something common to fix? So, I "link" here a few probably interested souls to cc: Subject: Re: 2.6.20->2.6.21 - networking dies after random time ... On Tue, Jun 26, 2007 at 04:24:07PM +0200, Jean-Baptiste Vignaud wrote: > Hello, i have a very similar problem with 2.6.21 also; > > 2 3com NICs and they are failling randomly. > > The kernel is a basic fedora 7 kernel (2.6.21-1.3228.fc7) > I found a bug report and added details here : > https://bugzilla.redhat.com/bugzilla/show_bug.cgi?id=243960 > > I'm not subcribed on this list, so please cc me if there is any questions. > > JB > > > On Tue, Jun 26, 2007 at 08:10:17AM +0200, Marcin Ślusarz wrote: > > ... > > > I reproduced it on minimal config: ... > > We know your hardware should be OK - since it was fine with 2.6.20. ... It looks like there is something common in the air... Marcin: ne2k_pci with 8390, Jean: 3com, and now I see similar problem with 8139cp too (plus some ideas): http://marc.info/?l=linux-netdev&m=118293314109648&w=2 So, you probably should wait a little & look for new patches here. Cheers, Jarek P. - To unsubscribe from this list: send the line "unsubscribe netdev" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html
[no subject]
subscribe netdev - To unsubscribe from this list: send the line "unsubscribe netdev" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html
[no subject]
subscribe [EMAIL PROTECTED] - To unsubscribe from this list: send the line "unsubscribe netdev" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html
[no subject]
Help -- Luca Fornasari FURNA.COM - To unsubscribe from this list: send the line "unsubscribe netdev" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: No Subject
> We need to use different auto-neg initial settings between > for 10/100Mbps ethernet switches and for Gbps ethernet switches. That is strange ! What PHY chip are you using ? Are you sure it's not just you not properly configuring the PHY ? Is the datasheet for the PHY available somewhere ? > Driver don't know which type of network switch is connected to > network card, so we try both settings alternately in auto negtiation > sequences by using a variable "is1000". sungem has an autoneg sequence that falls back to forced speeds but it's not useful on any modern setup. Your PHY should be perfectly capable to autoneg on both 1000bT and 10/100bT... > Furthermore, we have a problem that poll_link() may succeed even when > the auto-neg initial setting is for different network switch type, > and the network card does not work on this case. We retry auto-neg > with the another initial setting on this case. Ugh ? What is that initial setting bit exactly ? If the link is up, it should work. > >- spider_net_write_reg(card, SPIDER_NET_GMACST, > >-spider_net_read_reg(card, SPIDER_NET_GMACST)); > >- spider_net_write_reg(card, SPIDER_NET_GMACINTEN, 0x4); > > These codes are enabling LINK status interrupt which is disabled > at the beginning of auto-neg. > Without this operation, auto negotiation works only when a connection > detected for the first time, and auto negotiation will not work > when an ethernet cable is unpluged or pluged. Most drivers poll the link rather than use an interrupt as those are often unreliable. > (3) > >- mii_phy_probe(phy, phy->mii_id); > It seems that PHY reset is necessary before auto negotiation, > after a link once went down. It shouldn't be... again, what PHY are you using ? > We can't call directly reset routine from driver, so we call > mii_phy_probe(). If you really need to reset it, then change sungem_phy.c to export the reset function. But I'm surprised you need that. Another option is to reset the PHY in your PHY's setup_aneg() function. > We are still developping the patch as we noted, and we are considering > to call mii_phy_probe() from spider_net_setup_aneg(), or to call > reset_one_mii_phy() from bcm54xx_setup_aneg(). > > We think these (1)-(3) are necessary, but we are afraid that you removed > them > by a reason that they causes some trouble in Cell Blade. If so please > tell us. You might want to borrow the link state machine from sungem.c instead... it tends to just work :-) Ben. - To unsubscribe from this list: send the line "unsubscribe netdev" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html
[no subject]
subscribe netdev - To unsubscribe from this list: send the line "unsubscribe netdev" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html
[no subject]
subscribe - To unsubscribe from this list: send the line "unsubscribe netdev" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html
[no subject]
subscribe - To unsubscribe from this list: send the line "unsubscribe netdev" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html
(no subject)
subscribe netdev - To unsubscribe from this list: send the line "unsubscribe netdev" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html
[no subject]
- To unsubscribe from this list: send the line "unsubscribe netdev" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html
[no subject]
subscribe linux-netdev --- - To unsubscribe from this list: send the line "unsubscribe netdev" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html
[no subject]
subscribe [EMAIL PROTECTED] - To unsubscribe from this list: send the line "unsubscribe netdev" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html
[no subject]
Hi, I've just seen the following assertions pop out of one of my servers running 2.6.16.9 with grsecurity. I've searched the archives of LKML and netdev and I've only found posts relating to 2.6.9, after which some related bugs were fixed... It looks like these bugs are related to e1000, which is the driver I'm using. The system was running 24 days before these appeared and it's still running absolutely fine. May 16 09:15:12 baldrick kernel: [6442250.504000] KERNEL: assertion (! sk->sk_forward_alloc) failed at net/core/stream.c (283) May 16 09:15:12 baldrick kernel: [6442250.513000] KERNEL: assertion (! sk->sk_forward_alloc) failed at net/ipv4/af_inet.c (150) baldrick bootc # ethtool -k eth0 Offload parameters for eth0: rx-checksumming: on tx-checksumming: on scatter-gather: on tcp segmentation offload: on Many thanks, Chris PS: I'm not subscribed to netdev. -- Chris Boot [EMAIL PROTECTED] http://www.bootc.net/ - To unsubscribe from this list: send the line "unsubscribe netdev" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html
[no subject]
subcribe netdev - To unsubscribe from this list: send the line "unsubscribe netdev" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html
[no subject]
Need to force a transmit coalesce timer restart after processing
transmit packets. Otherwise, can get transmit status after last
update and chip doesn't send the next one.
Can go with the chip defaults for coalescing timers, except for
Tx timer which needs to be bigger.
Signed-off-by: Stephen Hemminger <[EMAIL PROTECTED]>
--- sky2.orig/drivers/net/sky2.c2006-02-22 11:33:17.0 -0800
+++ sky2/drivers/net/sky2.c 2006-02-22 11:33:33.0 -0800
@@ -1988,13 +1988,12 @@
sky2_tx_check(hw, 0, tx_done[0]);
sky2_tx_check(hw, 1, tx_done[1]);
- if (likely(work_done < to_do)) {
- /* need to restart TX timer */
- if (is_ec_a1(hw)) {
- sky2_write8(hw, STAT_TX_TIMER_CTRL, TIM_STOP);
- sky2_write8(hw, STAT_TX_TIMER_CTRL, TIM_START);
- }
+ if (sky2_read8(hw, STAT_TX_TIMER_CTRL) == TIM_START) {
+ sky2_write8(hw, STAT_TX_TIMER_CTRL, TIM_STOP);
+ sky2_write8(hw, STAT_TX_TIMER_CTRL, TIM_START);
+ }
+ if (likely(work_done < to_do)) {
netif_rx_complete(dev0);
hw->intr_mask |= Y2_IS_STAT_BMU;
sky2_write32(hw, B0_IMSK, hw->intr_mask);
@@ -2352,8 +2351,7 @@
sky2_write8(hw, STAT_FIFO_ISR_WM, 16);
sky2_write32(hw, STAT_TX_TIMER_INI, sky2_us2clk(hw, 1000));
- sky2_write32(hw, STAT_LEV_TIMER_INI, sky2_us2clk(hw, 100));
- sky2_write32(hw, STAT_ISR_TIMER_INI, sky2_us2clk(hw, 20));
+ sky2_write32(hw, STAT_ISR_TIMER_INI, sky2_us2clk(hw, 7));
}
/* enable status unit */
--
-
To unsubscribe from this list: send the line "unsubscribe netdev" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at http://vger.kernel.org/majordomo-info.html
[no subject]
subscribe netdev - To unsubscribe from this list: send the line "unsubscribe netdev" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html
