Jason Xing wrote:
> On Wed, Apr 14, 2021 at 12:27 AM Jesse Brandeburg
> wrote:
> >
> > kerneljasonx...@gmail.com wrote:
> >
> > > From: Jason Xing
> >
> > Hi Jason,
> >
> > Sorry, I missed this on the first time: Added intel-wired-la
se+0xed/0x120
> [2160294.719365] rtnl_newlink+0x73b/0x860
>
> Fixes: 41c445ff0f48 ("i40e: main driver core")
> Co-developed-by: Shujin Li
> Signed-off-by: Shujin Li
> Signed-off-by: Jason Xing
Reviewed-by: Jesse Brandeburg
@Jakub/@DaveM - feel free to apply this directly.
Nitesh Narayan Lal wrote:
> > The original issue as seen, was that if you rmmod/insmod a driver
> > *without* irqbalance running, the default irq mask is -1, which means
> > any CPU. The older kernels (this issue was patched in 2014) used to use
> > that affinity mask, but the value programmed int
kerneljasonx...@gmail.com wrote:
> From: Jason Xing
Hi Jason,
Sorry, I missed this on the first time: Added intel-wired-lan,
please include on any future submissions for Intel drivers.
get-maintainers script might help here?
>
> Fix this panic by adding more rules to calculate the value of @r
kerneljasonx...@gmail.com wrote:
> From: Jason Xing
>
> Re: [PATCH] i40e: fix the panic when running bpf in xdpdrv mode
Please use netdev style subject lines when patching net kernel to
indicate which kernel tree this is targeted at, "net" or "net-next"
[PATCH net v2] i40e: ...
> Fix this by a
Continuing a thread from a bit ago...
Nitesh Narayan Lal wrote:
> > After a little more digging, I found out why cpumask_local_spread change
> > affects the general/initial smp_affinity for certain device IRQs.
> >
> > After the introduction of the commit:
> >
> > e2e64a932 genirq: Set initia
Bhaskar Chowdhury wrote:
>
> s/Reprogam/Reprogram/
>
> Signed-off-by: Bhaskar Chowdhury
Reviewed-by: Jesse Brandeburg
ot;net: stmmac: Add support for CBS QDISC")
> Suggested-by: Gomes, Vinicius
> Signed-off-by: Mohammad Athari Bin Ismail
> Signed-off-by: Song, Yoong Siang
Reviewed-by: Jesse Brandeburg
Geetha sowjanya wrote:
> v2-v3
> Reposting as a single thread.
FYI, it didn't work, suggest you try adding the git-send-email option
(via git-config)
sendemail.thread=true
sendemail.chainreplyto=false
And you can test locally by using first using git send-email to export
to mbox and checking fo
>
> Suggested-by: David Rientjes
> Suggested-by: Jakub Kicinski
> Cc: John Hubbard
> Signed-off-by: Alexander Lobakin
I don't know why it was missed in the series update, but:
Reviewed-by: Jesse Brandeburg
Zheng Yongjun wrote:
> When kzalloc failed, should return ENOMEM rather than ENOBUFS.
All these patches have the same subject and description, couldn't they
just be part of a single series with a good cover letter?
I'm not saying make them a single patch, because that is bad for
bisection, but h
n sending like [PATCH net-next]
otherwise, for net-next:
Reviewed-by: Jesse Brandeburg
uot;hv_netvsc: Add validation for untrusted Hyper-V
> values")
Reviewed-by: Jesse Brandeburg
gainst 0")
> Fixes: 04987ca1b9b6 ("net: hns3: add debugfs support for tm nodes, priority
> and qset info")
> Signed-off-by: Colin Ian King
Reviewed-by: Jesse Brandeburg
Colin King wrote:
> From: Colin Ian King
>
> There is a spelling mistake in a netdev_warn message. Fix it.
>
> Signed-off-by: Colin Ian King
Trivial patch, looks fine!
Reviewed-by: Jesse Brandeburg
0 duplex full autoneg on
>
> Signed-off-by: Christina Jacob
> Signed-off-by: Sunil Goutham
> Signed-off-by: Hariprasad Kelam
Reviewed-by: Jesse Brandeburg
e frame use: No
> Advertised auto-negotiation: No
> Advertised FEC modes: None
>
> ethtool lbk0
> Settings for lbk0:
> Speed: 10Mb/s
> Duplex: Full
>
> Signed-off-by: Christina Jacob
> Signed-off-by: Sunil Goutham
> Signed-
gt; Signed-off-by: Sunil Goutham
> Signed-off-by: Hariprasad Kelam
Reviewed-by: Jesse Brandeburg
adds mailbox handler set_link_mode, fw_data_get to
> configure and read these parameters.
>
> Signed-off-by: Christina Jacob
> Signed-off-by: Sunil Goutham
> Signed-off-by: Hariprasad Kelam
Reviewed-by: Jesse Brandeburg
- ethtool --show-fec eth0
>
> Signed-off-by: Christina Jacob
> Signed-off-by: Sunil Goutham
> Signed-off-by: Hariprasad Kelam
Reviewed-by: Jesse Brandeburg
CMD_GET_PHY_FEC_STATS, also add CGX_CMD_PRBS and
> CGX_CMD_DISPLAY_EYE to enum cgx_cmd_id so that Linux's enum list is in sync
> with firmware's enum list.
>
> Signed-off-by: Felix Manlunas
> Signed-off-by: Christina Jacob
> Signed-off-by: Sunil Kovvuri Goutham
>
Signed-off-by: Sunil Goutham
> Signed-off-by: Hariprasad Kelam
Reviewed-by: Jesse Brandeburg
he previous posting of v3 that it looked good.
Reviewed-by: Jesse Brandeburg
first argument of
> skb_propagate_pfmemalloc().
> In Page Pool core code, it can be simply inlined instead.
> Most of the callers from NIC drivers were just doppelgangers of
> the same condition tests. Derive them into a new common function
> do deduplicate the code.
This is a useful cleanup! Thanks.
Fo
ellanox/mlx5/core/en_rx.c | 7 +--
> include/linux/skbuff.h| 15 +++
> 11 files changed, 27 insertions(+), 83 deletions(-)
For the patch, and esp. for the Intel drivers:
Reviewed-by: Jesse Brandeburg
Xiaohui Zhang wrote:
> From: Zhang Xiaohui
>
> If the hardware receives an oversized packet with too many rx fragments,
> skb_shinfo(skb)->frags can overflow and corrupt memory of adjacent pages.
> This becomes especially visible if it corrupts the freelist pointer of
> a slab page.
As I replie
Xiaohui Zhang wrote:
> From: Zhang Xiaohui
>
> If the hardware receives an oversized packet with too many rx fragments,
> skb_shinfo(skb)->frags can overflow and corrupt memory of adjacent pages.
> This becomes especially visible if it corrupts the freelist pointer of
> a slab page.
>
> Signed-
h needs more discussion.
> V3 - fix a typo error in #1 reported by Jakub Kicinski.
> rewrite #9 commit log.
> remove #11 from this series.
> V2 - reorder #2 & #3 to fix compiler error.
> fix some checkpatch warnings in #10 & #11.
For the series:
Reviewed-by: Jesse Brandeburg
Zhang Changzhong wrote:
> Fix to return a negative error code from the error handling
> case instead of 0, as done elsewhere in this function.
>
> Fixes: b66c7bc1cd4d ("iavf: Refactor init state machine")
> Reported-by: Hulk Robot
> Signed-off-by: Zhang Changzhong
Jakub Kicinski wrote:
> On Fri, 16 Oct 2020 14:23:48 -0700 Jesse Brandeburg wrote:
> > > These are tested to be the latest as part of the tools/lib/bpf build.
> >
> > But you didn't mention why you're making these changes, and you're
> > removing a
Grygorii Strashko wrote:
> Hi
>
> This series adds multi-port support in mac-only mode (multi MAC mode) to TI
> AM65x CPSW driver in preparation for enabling support for multi-port devices,
> like Main CPSW0 on K3 J721E SoC or future CPSW3g on K3 AM64x SoC.
For the series
Rev
Hi Ian,
Ian Rogers wrote:
> These are tested to be the latest as part of the tools/lib/bpf build.
But you didn't mention why you're making these changes, and you're
removing a lot of comments without explaining why/where there might be
a replacement or why the comments are useless. I now see tha
ue, right? I'm sure ixgbe and ice both have this problem
too, you should fix them as well, at a minimum, and probably other
vendors drivers:
$ rg -c --stats num_online_cpus drivers/net/ethernet
...
50 files contained matches
for this patch i40e
Acked-by: Jesse Brandeburg
Nitesh Narayan Lal wrote:
> Introduce a new API num_housekeeping_cpus(), that can be used to retrieve
> the number of housekeeping CPUs by reading an atomic variable
> __num_housekeeping_cpus. This variable is set from housekeeping_setup().
>
> This API is introduced for the purpose of drivers th
Wang Hai wrote:
> Wang Hai (3):
> i40e: Fix some kernel-doc warnings in i40e_client.c
> i40e: Fix some kernel-doc warnings in i40e_common.c
> i40e: Fix a kernel-doc warning in i40e_ptp.c
>
> drivers/net/ethernet/intel/i40e/i40e_client.c | 2 --
> drivers/net/ethernet/intel/i40e/i40e_common
Lennart Sorensen wrote:
> On Thu, Aug 27, 2020 at 02:30:39PM -0400, Lennart Sorensen wrote:
> > I have hit a new problem with the X722 chipset (Intel R1304WFT server).
> > VRRP simply does not work.
> >
> > When keepalived registers a vmac interface, and starts transmitting
> > multicast packets
Murali Karicheri wrote:
> To flush the vid + mc entries from ALE, which is required when a VLAN
> interface is removed, driver needs to call cpsw_ale_flush_multicast()
> with ALE_PORT_HOST for port mask as these entries are added only for
> host port. Without this, these entries remain in the ALE
Murali Karicheri wrote:
> To flush the vid + mc entries from ALE, which is required when a VLAN
> interface is removed, driver needs to call cpsw_ale_flush_multicast()
> with ALE_PORT_HOST for port mask as these entries are added only for
> host port. Without this, these entries remain in the ALE
Steven Rostedt wrote:
> On Wed, 19 Aug 2020 17:01:06 +0530
> Naresh Kamboju wrote:
>
> > kernel warning noticed on x86_64 while running LTP tracing
> > ftrace-stress-test
> > case. started noticing on the stable-rc linux-5.8.y branch.
> >
> > This device booted with KASAN config and DYNAMIC tr
On Tue, 18 Aug 2020 09:10:56 +
Xu Wang wrote:
> Remove unnecassary casts in the argument to kfree.
>
> Signed-off-by: Xu Wang
You seem to have several of these patches, they should be sent in a
series with the series patch subject (for example):
[PATCH net-next 0/n] fix up casts on kfree
On Tue, 18 Aug 2020 16:21:03 +0800
Qingyu Li wrote:
> When creating a raw PF_BLUETOOTH socket,
> CAP_NET_RAW needs to be checked first.
>
> Signed-off-by: Qingyu Li
Please see my replies to your previous patches.
On Tue, 18 Aug 2020 16:15:55 +0800
Qingyu Li wrote:
> When creating a raw PF_BLUETOOTH socket,
> CAP_NET_RAW needs to be checked first.
Please see my previous replies.
On Tue, 18 Aug 2020 16:07:03 +0800
Qingyu Li wrote:
> When creating a raw PF_BLUETOOTH socket,
> CAP_NET_RAW needs to be checked first.
>
These changes should be part of a series (patch 0,1,2 at least), and all
my replies on your other patch apply to this one as well.
On Tue, 18 Aug 2020 15:56:48 +0800
Qingyu Li wrote:
> When creating a raw PF_BLUETOOTH socket,
> CAP_NET_RAW needs to be checked first.
>
Thanks for the patch! Your subject doesn't need to end in a period. In
your commit message, I can guess why you'd want this patch, but your
commit message sh
On Mon, 17 Aug 2020 16:27:01 +0300
Kalle Valo wrote:
> I was surprised to see that someone was using this driver in 2015, so
> I'm not sure anymore what to do. Of course we could still just remove
> it and later revert if someone steps up and claims the driver is still
> usable. Hmm. Does anyone
On Tue, 11 Aug 2020 14:46:14 +0200
Pavel Machek wrote:
> > --- a/drivers/net/ethernet/intel/i40e/i40e_virtchnl_pf.c
> > +++ b/drivers/net/ethernet/intel/i40e/i40e_virtchnl_pf.c
> > @@ -449,16 +450,19 @@ static int i40e_config_iwarp_qvlist(stru
> > "Incorrect number of iwarp v
preciate the work done to find the right
fix and clean up the code while not breaking sparse! I had a look at
the assembly from gcc 9.3.1 and it looks good. Thanks!
Reviewed-by: Jesse Brandeburg
On Mon, 4 May 2020 12:51:12 -0700
Nick Desaulniers wrote:
> Sorry for the very late report. It turns out that if your config
> tickles __builtin_constant_p just right, this now produces invalid
> assembly:
>
> $ cat foo.c
> long a(long b, long c) {
> asm("orb\t%1, %0" : "+q"(c): "r"(b));
>
c: ARP Offload for GMAC4+ Cores
For the series, looks good to me.
Reviewed-by: Jesse Brandeburg
On Wed, 7 Aug 2019 10:38:08 +0800
YueHaibing wrote:
> We should also enable bonding's vlan tx offload in hw_enc_features,
You mean team's vlan tx offload?
> pass the vlan packets to the slave devices with vlan tci, let them
s/let them to/let the slave/
> to handle vlan tunneling offload imple
On Wed, 31 Jul 2019 16:53:46 +0800
Ding Xiang wrote:
> "error" is unneeded,just return 0
>
> Signed-off-by: Ding Xiang
Reviewed-by: Jesse Brandeburg
On Wed, 31 Jul 2019 10:06:48 +0200
Christophe JAILLET wrote:
> There is no need to use GFP_ATOMIC here, GFP_KERNEL should be enough.
> The 'kcalloc()' just a few lines above, already uses GFP_KERNEL.
>
> Signed-off-by: Christophe JAILLET
Reviewed-by: Jesse Brandeburg
.
>
> Signed-off-by: Christophe JAILLET
Reviewed-by: Jesse Brandeburg
7;)
>
> Use GFP_KERNEL which should be enough.
>
> Signed-off-by: Christophe JAILLET
Sure, but generally I'd say GFP_ATOMIC is ok if you're in an init path
and you can afford to have the allocation thread sleep while memory is
being found by the kernel.
Reviewed-by: Jesse Brandeburg
On Wed, 5 Jun 2019 22:24:26 +0800 Kefeng wrote:
> IS_ERR(_OR_NULL) already contain an 'unlikely' compiler flag,
> so no need to do that again from its callers. Drop it.
>
> segs = __skb_gso_segment(skb, features, false);
> - if (unlikely(IS_ERR_OR_NULL(segs))) {
> + if (IS_ERR_OR_
On Tue, 4 Jun 2019 01:16:08 + Xue wrote:
> This patch adds LRO support for the HiNIC driver.
>
> Reported-by: kbuild test robot
> Reviewed-by: Jesse Brandeburg
> Signed-off-by: Xue Chaojing
Hm, you added my reviewed-by tag, but I didn't add it myself, I
only commented
some review comments below...
On Mon, 3 Jun 2019 04:35:36 +
Xue Chaojing wrote:
> This patch adds LRO support for the HiNIC driver.
>
> Signed-off-by: Xue Chaojing
> ---
> .../net/ethernet/huawei/hinic/hinic_hw_dev.c | 2 +
> .../net/ethernet/huawei/hinic/hinic_hw_dev.h | 8 +-
> ..
On Mon, 21 May 2018 17:04:31 +0800 Jason wrote:
> This patch implement build XDP buffers in vhost_net. The idea is do
> userspace copy in vhost_net and build XDP buff based on the
> page. Vhost_net can then submit one or an array of XDP buffs to
> underlayer socket (e.g TUN). TUN can choose to do X
On Mon, 21 May 2018 17:04:25 +0800 Jason wrote:
> Instead of mixing zerocopy and datacopy logics, this patch tries to
> split datacopy logic out. This results for a more compact code and
> specific optimization could be done on top more easily.
>
> Signed-off-by: Jason Wang
> ---
> drivers/vhost
On Mon, 21 May 2018 17:04:24 +0800 Jason wrote:
> Signed-off-by: Jason Wang
> ---
> drivers/vhost/net.c | 12 +---
> 1 file changed, 9 insertions(+), 3 deletions(-)
>
> diff --git a/drivers/vhost/net.c b/drivers/vhost/net.c
> index de544ee..4ebac76 100644
> --- a/drivers/vhost/net.c
> ++
On Mon, 21 May 2018 17:04:23 +0800 Jason wrote:
> Signed-off-by: Jason Wang
> ---
> drivers/vhost/net.c | 13 -
> 1 file changed, 8 insertions(+), 5 deletions(-)
>
> diff --git a/drivers/vhost/net.c b/drivers/vhost/net.c
> index 15d191a..de544ee 100644
> --- a/drivers/vhost/net.c
> +
Hi Jason, a few nits.
On Mon, 21 May 2018 17:04:22 +0800 Jason wrote:
> Signed-off-by: Jason Wang
> ---
> drivers/vhost/net.c | 34 +++---
> 1 file changed, 23 insertions(+), 11 deletions(-)
>
> diff --git a/drivers/vhost/net.c b/drivers/vhost/net.c
> index c4b49fc.
se the typedefs which are still available. They also work on
> older glibcs.
>
> Signed-off-by: Andi Kleen
same patch that I sent on Feb 1st. Hope you can get more traction than
I did.
https://www.mail-archive.com/user-mode-linux-devel@lists.sourceforge.net/msg10071.html
Reviewed-by: Jesse Brandeburg
ode-linux-de...@lists.sourceforge.net
Signed-off-by: Jesse Brandeburg
---
arch/um/os-Linux/signal.c | 2 +-
arch/x86/um/stub_segv.c | 2 +-
2 files changed, 2 insertions(+), 2 deletions(-)
diff --git a/arch/um/os-Linux/signal.c b/arch/um/os-Linux/signal.c
index a86d7cc2c2d8..a5c0c909c48b 100644
-
d-off-by: Markus Elfring
Thanks for the patch.
Acked-by: Jesse Brandeburg
hex filename
>1953 496 02449 991 i40e_diag.o
>
> After:
>text data bss dec hex filename
>1798 584 02382 94e i40e_diag.o
>
> (gcc 6.3.0, x86-64)
>
> Signed-off-by: Colin Ian King
Looks good, thanks Colin!
Acked-by: Jesse Brandeburg
just before return, so assigning a value to this
> variable in this code block is useless.
>
> Addresses-Coverity-ID: 1397693
> Signed-off-by: Gustavo A. R. Silva
Thanks for the fix, looks reasonable.
Acked-by: Jesse Brandeburg
evice IDs to include these so that we hide that the
> device supports INTx at all to the user.
>
Acked-by: Jesse Brandeburg
t; errors from the spurious interrupt handler when we try to use it
> with device assignment.
Thanks for doing this Alex,
Acked-by: Jesse Brandeburg
On Wed, 19 Oct 2016 14:37:59 +0200
Henrik Austad wrote:
> The current list of E1000_TXDCTL-registers is incomplete. This adds
> the missing parts for the Transmit Descriptor Control (TXDCTL)
> register.
>
> The rest of these values (threshold for descriptor read/write) for
> TXDCTL seems to be d
On Sat, 23 Jul 2016 12:44:32 -0400
Jarod Wilson wrote:
> This little series factors out the systim sanitization code first, then
> adds e1000_pch_lpt as a new case in the switch that calls the sanitize
> function, fixing PTP clock issues I've had reported against an Intel
> I-218V NIC in an Intel
On Fri, 3 Apr 2015 08:55:57 +0200
Ingo Molnar wrote:
> So the original commit also has the problem that it unnecessary
> drops/retakes the descriptor lock:
>
> > irq_put_desc_unlock(desc, flags);
> > - /* set the initial affinity to prevent every interrupt being on CPU0 */
> > - if (m)
>
evert the change if no-one else can help me debug what is going
wrong, we can pick up the change later.
This commit would also revert commit 4fe7ffb7e17ca ("genirq: Fix null pointer
reference in irq_set_affinity_hint()") which was a bug fix to the original
patch.
Signed-off-by: Jesse Bra
Commit-ID: 4fe7ffb7e17ca6ad9173b8de35f260c9c8fc2f79
Gitweb: http://git.kernel.org/tip/4fe7ffb7e17ca6ad9173b8de35f260c9c8fc2f79
Author: Jesse Brandeburg
AuthorDate: Wed, 28 Jan 2015 10:57:39 -0800
Committer: Ingo Molnar
CommitDate: Mon, 9 Feb 2015 18:47:42 +0100
genirq: Fix null
On Tue, 27 Jan 2015 22:36:23 -0800
Yinghai Lu wrote:
> On Fri, Jan 23, 2015 at 2:42 AM, tip-bot for Jesse Brandeburg
> wrote:
> > Commit-ID: e2e64a932556cdfae455497dbe94a8db151fc9fa
> > Gitweb:
> > http://git.kernel.org/tip/e2e64a932556cdfae455497dbe94a8db151fc9
ty in irq_set_affinity_hint()")
Reported-by: Yinghai Lu
Signed-off-by: Jesse Brandeburg
CC: Thomas Gleixner
CC: net...@vger.kernel.org
---
kernel/irq/manage.c |3 ++-
1 file changed, 2 insertions(+), 1 deletion(-)
diff --git a/kernel/irq/manage.c b/kernel/irq/manage.c
index f038e58..196a
On Tue, 27 Jan 2015 22:36:23 -0800
Yinghai Lu wrote:
> On Fri, Jan 23, 2015 at 2:42 AM, tip-bot for Jesse Brandeburg
> wrote:
> > Commit-ID: e2e64a932556cdfae455497dbe94a8db151fc9fa
> > Gitweb:
> > http://git.kernel.org/tip/e2e64a932556cdfae455497dbe94a8db151fc9
Commit-ID: e2e64a932556cdfae455497dbe94a8db151fc9fa
Gitweb: http://git.kernel.org/tip/e2e64a932556cdfae455497dbe94a8db151fc9fa
Author: Jesse Brandeburg
AuthorDate: Thu, 18 Dec 2014 17:22:06 -0800
Committer: Thomas Gleixner
CommitDate: Fri, 23 Jan 2015 11:38:25 +0100
genirq: Set
+netdev, as network driver developers might be interested in this functionality.
On Thu, Dec 18, 2014 at 5:22 PM, Jesse Brandeburg
wrote:
> Problem:
> The default behavior of the kernel is somewhat undesirable as all
> requested interrupts end up on CPU0 after registration. A user
:1
drivers/soc/ti/knav_qmss_queue.c:2
drivers/virtio/virtio_pci_common.c:2
Signed-off-by: Jesse Brandeburg
CC: Thomas Gleixner
---
kernel/irq/manage.c |2 ++
1 file changed, 2 insertions(+)
diff --git a/kernel/irq/manage.c b/kernel/irq/manage.c
index 8069237..f038e58 100644
--- a/kernel/irq
On Thu, 18 Dec 2014 23:42:03 +0100
Thomas Gleixner wrote:
> On Thu, 18 Dec 2014, Jesse Brandeburg wrote:
> > Enabling this function means that kernel drivers can include
> > an initial affinity setting for the interrupt, instead of all
> > interrupts starting out life on CP
compile
due to the lack of an export even though already defined via extern.
Signed-off-by: Jesse Brandeburg
CC: Thomas Gleixner
---
Note: The use of EXPORT_SYMBOL_GPL was only because the next
latest function added to this file (irq_set_affinity_hint)
also used it.
---
kernel/irq
On Wed, Jul 23, 2014 at 2:03 AM, Alexey Kardashevskiy wrote:
> On 07/23/2014 06:11 AM, Tejun Heo wrote:
>> Hello,
>>
>> Can you please test the following patch?
>
> Tested-by: Alexey Kardashevskiy
>
> on POWER8 + IBM IPR SCSI.
FWIW, I tested Linus's current git tree and the issue is fixed. Thank
+linux-pci
On Thu, Jan 2, 2014 at 4:21 PM, David Miller wrote:
> From: Jeff Kirsher
> Date: Sat, 28 Dec 2013 04:36:13 -0800
>
>> Add missing PCI bus link speed 8.0 GT/s and bus link widths of
>> x1, x2, x4 and x8.
>>
>> CC:
>> Signed-off-by: Jeff Kirsher
>
> Can a PCI person please ACK this?
Remove memset from the static inline dma_zalloc_coherent
> and add just one use of __GFP_ZERO instead.
>
> Trivially reduces the size of the existing uses of
> dma_zalloc_coherent.
>
> Realign arguments as appropriate.
>
> Signed-off-by: Joe Perches
e1000 and ixg
please copy netdev, or better yet [EMAIL PROTECTED] in
the future for e1000 issues like this. Feel free to move the
conversation there, if you would like.
On 4/19/07, David Ford <[EMAIL PROTECTED]> wrote:
I have a rackmount server that has a dual port onboard 82546EB card.
I've googled and see
added netdev.
On 3/29/07, Andrei Popa <[EMAIL PROTECTED]> wrote:
In a dual core 2 server with an intel motherboard and 5 network
cards(two onboard) and 1 pci express card with two slots and one pci-x
pci64 card the kernel sees all of them in dmesg but in mii-tool are
misnumbered and one card is
On 3/26/07, Ingo Molnar <[EMAIL PROTECTED]> wrote:
hm, on a T60, after suspend/resume, i get an e1000 timeout:
e1000: eth0: e1000_watchdog: NIC Link is Up 1000 Mbps Full Duplex, Flow
Control: RX/TX
e1000: eth0: e1000_clean_tx_irq: Detected Tx Unit Hang
Tx Queue <0>
TDH
e
> word out in case someone else is testing this kernel on this nic chipset.
Upon some further investigation with Allen, I got this info, and it
appears that his system is not freeing MSI irq's correctly.
from our discussion:
Allen wrote:
Jesse Brandeburg wrote:
I believe you may hav
On 1/2/07, Eric Piel <[EMAIL PROTECTED]> wrote:
Hi, I've been using e100 for years with no problem, however more by
curiosity than necessity I'd like to know how will be handled the
devices which are (supposedly) supported by eepro100 and not by e100?
According to "modinfo eepro100" and "modinfo
On 12/20/06, Arjan van de Ven <[EMAIL PROTECTED]> wrote:
> Yeah, I guess that's a problem. From a user perspective, the
> functionality is only really useful if the latency is very small. I
> think where possible we'd want to power down the chip while keeping the
> phy up, but it would be nice t
On 12/1/06, John <[EMAIL PROTECTED]> wrote:
> can you try adding mdelay(100); in e100_eeprom_load before the for loop,
> and then change the multiple udelay(4) to mdelay(1) in e100_eeprom_read
I applied the attached patch.
Loading the driver now takes around one minute :-)
ouch, but yep, that
sorry for the delay, your mail got marked as spam. In the future
please copy networking issues to netdev@vger.kernel.org, and be sure
to copy the maintainers of the driver you're having problems with
(they are in the MAINTAINERS file)
On 11/22/06, Amin Azez <[EMAIL PROTECTED]> wrote:
I notice a
On 11/29/06, John <[EMAIL PROTECTED]> wrote:
> Let's go ahead and print the output from e100_load_eeprom
> debug patch attached.
Loading (then unloading) e100.ko fails the first few times (i.e. the
driver claims one of the EEPROMs is corrupted). Thereafter, sometimes it
fails, other times it wor
On 11/27/06, John <[EMAIL PROTECTED]> wrote:
John wrote:
>> -0009 : System RAM
>> 000a-000b : Video RAM area
>> 000f-000f : System ROM
>> 0010-0ffe : System RAM
>> 0010-00296a1a : Kernel code
>> 00296a1b-0031bbe7 : Kernel data
>> 0fff-0fff2fff : AC
On 11/16/06, Krzysztof Sierota <[EMAIL PROTECTED]> wrote:
Hi,
I'm getting the following in dmesg with 2.6.19-rc5 and 2.6.19-rc6 kernels quad
opteron server running 64bit kernel, and the network card gets disabled.
On identical server running 32bit kernel, same cards, same slots, same
configurat
on 2.6.11/12 when it isn't working maybe you should send us the output
of lspci -vvv
just a hint, I'm guessing its power management related, and / or
something to do with the pci bus code.
On 8/30/05, Daniel Drake <[EMAIL PROTECTED]> wrote:
> Forwarding on, please reply-to-all in future.
>
> Ste
On 8/11/05, Stephen D. Williams <[EMAIL PROTECTED]> wrote:
> The chipset is an Intel 8x0 something. Unfortunately, there is a
> heatsink semi-permanently installed over everything. Is there a /proc
> pseudofile that will give me good identifying chipset info to report here?
you can show the chip
On 7/27/05, John W. Linville <[EMAIL PROTECTED]> wrote:
> Some PCI devices (e.g. 3c905B, 3c556B) lose all configuration
> (including BARs) when transitioning from D3hot->D0. This leaves such
> a device in an inaccessible state. The patch below causes the BARs
> to be restored when enabling such a
On 7/13/05, Mikhail Kshevetskiy <[EMAIL PROTECTED]> wrote:
> symptom
> ===
> modprobe e100
> ifconfig eth0 netmask
>
> result:
> ===
> SIOCADDRT: Network is unreachable
>
> There were no such error in 2.6.13-rc2
odd, both e100 and eepro100 are broken? This might indicate something
wie
100 matches
Mail list logo
