> On May 20, 2024, at 3:33 AM, Alexander Kokorin
> wrote:
>
> We have noticed that when we receive TCP packets with the wrong
> checksum from the internet, on
> the receiving node it goes through, NIC compares the checksum, lets packet
> further and increases the kernel counter for RX ERR. It do
Ben Greear wrote:
The blacklist option worked.
I blacklisted both ixgbe and igb, and then added a pre_network init.d
script that
runs before the 'network' target. This script loads ixgbe, waits 2
seconds, loads igb.
I now see all network devices registered. This is quite a bit of a hac
Ben Greear wrote:
The blacklist option worked.
I blacklisted both ixgbe and igb, and then added a pre_network init.d
script that
runs before the 'network' target. This script loads ixgbe, waits 2
seconds, loads igb.
I now see all network devices registered. This is quite a bit of a hac
Ben Greear wrote:
Thanks for the diagnosis.
The purpose of this system is to act as a network traffic generation test
system, and we
do not expect full line-rate throughput on all ports concurrently. We do
see nice throughput over-all
on this sytem (in previous boots we tested all NICs co
Ben Greear wrote:
I forgot to mention earlier, we have 4 x 4-port NICs in here too, so
likely we are pushing
the IRQ resources. Any way to configure the NICs to use fewer IRQ
resources and still
perform at least moderately well?
And two 1G ports on the mobo as well! If you look at the ig
Ben Greear wrote:
[6.405914] ixgbe :05:00.1: Intel(R) 10 Gigabit Network Connection
[6.554373] ixgbe :06:00.0: Multiqueue Enabled: Rx Queue count =
8, Tx Queue count = 8
[6.554501] ixgbe :06:00.0: PCI Express bandwidth of 32GT/s
available
[6.554504] ixgbe :06
Hank Liu wrote:
*From:* Hank Liu [mailto:hank.tz...@gmail.com]
*Sent:* Wednesday, September 07, 2016 10:20 AM
*To:* Skidmore, Donald C
*Cc:* e1000-devel@lists.sourceforge.net
*Subject:* Re: [E1000-devel] Intel 82599 AXX10GBNIAIOM cards for 10G SFPs
UDP performance issue
Thanks for quick res
Alexey Muranov wrote:
I wrote to Asus (my laptop maker), and they responded that they can only
help with setting up the original hardware and software, and they cannot
help if i have installed Linux, because the laptop was sold with
Windows. I wrote to them again explaining that it looks
Don Buchholz wrote:
We can not (reliably) map the name "I219V" to a PCIe device.
Use lspci(8) to ascertain the device id#, and then use modinfo(8)
to see if that device ID is listed on one of the "alias" lines.
The fact that the driver loaded at all is a sign that the device is
supported by
zyjzyj2...@gmail.com wrote:
> From: Zhu Yanjun
>
> According to the suggestion from Rustad, Mark D, this behavior perhaps
> is more related to the copper phy. But to make fiber phy more robust,
> to all the interfaces as a slave interface, the link_speed and link_up
&g
Emil S wrote:
>> */
>> -if (hw->mac.type == ixgbe_mac_X540)
>> +if ((hw->mac.type == ixgbe_mac_X540) &&
>> +(netdev->flags & IFF_SLAVE))
>> if (link_speed == IXGBE_LINK_SPEED_UNKNOWN)
>> return;
>
> If you were to enter ixgbe_watchdog_link_is_up
> On Sep 10, 2015, at 1:55 PM, Tantilov, Emil S
> wrote:
>
> Yeah, we need to update the version in the upstream driver.
I did send a patch to do that in my series for X55* SFP+ support.
--
Mark Rustad, Networking Division, Intel Corporation
signature.asc
Description: Message signed with Op
Scott,
> On Jul 27, 2015, at 11:33 PM, Fujinaka, Todd wrote:
>
> That's a known issue and we have a fix for it.
However, that fix will not be released until version 4.2.x of the driver is
released.
> I think whoever wrote the readme was being optimistic about building on 4.1.2
> because cert
Christian,
> On Jun 30, 2015, at 1:33 PM, Christian Ruppert wrote:
>
> We tried Supermicro 5018D-MTF (E3-1281v3), 5017C-MTF (E3-1220L IIRC) and a
> Workstation PC (i5-4460) with an Asus mainboard (H97M-E) and it's the same
> everywhere. All Systems do have 32GB RAM, the two Supermicro even ECC
Christian,
> On Jun 30, 2015, at 1:58 AM, Christian Ruppert wrote:
>
> bad news. It didn't work either. :(
That is too bad.
> The system just did a reset tonight and there's nothing useful.
> What I did was:
> I removed the console= parameter and therefore I added your mentioned
> earlyprintk
> On Jun 26, 2015, at 8:42 AM, Christian Ruppert wrote:
>
> Neither via
> kexec/kdump nor via serial console.
Did you use the kernel command line option:
earlyprintk=ttyS0,115200,keep
That really should be able to capture the error messages, which will help a
great deal.
--
Mark Rusta
> On Jun 25, 2015, at 8:45 AM, Ronciak, John wrote:
>
> There was no patch attached. Can you please post the patch also inline of
> the email in case the patch gets stripped again?
>
> Cheers,
> John
Actually, Shota was responding with results of applying the patch that I sent
to him. So he
> On Jun 18, 2015, at 3:40 AM, shouta.ueh...@jp.yokogawa.com wrote:
>
> These results show that almost delay is spent at ioctl(SIOCBRADDBR),
> and usleep_range is called twice to ixgbe driver.
> Both of ixgbe_acquire_swfw_sync_X540 and ixgbe_release_swfw_sync_X540 call
> usleep_range(5000, 1)
> On Jun 18, 2015, at 9:02 AM, Rustad, Mark D wrote:
>
> It is part of the interface space that there should a that much delay between
> instances of taking the semaphore.
Sorry, I meant to say: It is part of the interface spec that there should be
that much delay between instanc
> On Jun 18, 2015, at 3:40 AM, shouta.ueh...@jp.yokogawa.com wrote:
>
> Both of ixgbe_acquire_swfw_sync_X540 and ixgbe_release_swfw_sync_X540 call
> usleep_range(5000, 1) just before return. It causes non-operation time
> about 20msec.
> I want to ask you why usleep_range has to be called the
> On Jun 16, 2015, at 9:39 AM, Pavel Odintsov wrote:
>
> Then, I send ticket to Intel folks about it:
> https://sourceforge.net/p/e1000/bugs/480/ and they rejected my idea.
I believe that what Don actually said was that we don't currently have plans to
do this. There are steps that you can take
> On May 11, 2015, at 2:03 PM, Keller, Jacob E wrote:
>
> Hi,
>
> On Mon, 2015-05-11 at 10:49 +0800, kendo wrote:
>> In the e1000e_cyclecounter_read function, if incvalue is 0, causes a divide
>> error.Need to add a check?
>>
>>
>>incvalue = er32(TIMINCA) & E1000_TIMINCA_INCV
On Apr 6, 2015, at 2:11 PM, Eric Hamilton wrote:
>
> Thanks again, Mark. We are already using a 64-bit kernel:
>
> [root@hbcb ~]# uname -a
> Linux hbcb 2.6.18-128.6om #1 SMP PREEMPT Fri Mar 27 00:39:10 PST 2015 x86_64
> x86_64 x86_64 GNU/Linux
Excellent. Well, at least a lot better than a 32-
Eric,
> On Apr 3, 2015, at 5:33 PM, Eric Hamilton
> wrote:
>
> Thanks for the note and the suggestion to check for BIOS settings. It looks
> like if we tell the BIOS not to assign memory BARs beyond 4GB, we can access
> the card. I haven't debugged why or whether there's a software workarou
Eric,
> On Apr 2, 2015, at 12:15 PM, Eric Hamilton
> wrote:
>
> After ixgbe_probe sets up hw->hw_addr, the very first call to
> ixgbe_read_reg(), in ixgbe_init_ops_generic where it calls IXGBE_READ_REG(hw,
> IXGBE_EEC) the read fails. It then proceeds to try to read IXGBE_STATUS
> which fai
On Feb 16, 2015, at 6:44 AM, Tal Abudi wrote:
> I'm not sure if my question fits this discussion board but it would be
> great if anyone could assist.
>
> I'm back-porting the genirq patch series to my Linux 2.6.18.
This will cause trouble with an out-of-tree driver, because you are changing
t
Doug,
On Sep 23, 2014, at 9:49 PM, Doug Anderson wrote:
> How does one use the IDX field in an advanced transmit data descriptor?
>
> I'm trying to understand this statement from
> http://www.intel.com/content/www/us/en/ethernet-controllers/82599-10-gbe-controller-datasheet.html
> :
>
>> From
On Jun 4, 2014, at 2:55 PM, Joe Perches wrote:
> On Wed, 2014-06-04 at 23:29 +0200, Rickard Strandqvist wrote:
>> Added a guaranteed null-terminate after call to strncpy.
>
> Perhaps all of these should be strlcpy
The code that is there seems fine. The length of the array exceeds the length
of
On Mar 26, 2014, at 3:36 PM, Aaron Brice wrote:
> Well, I got past the ioctl part but it seems that we're also doing
> some QoS stuff using netlink sockets that is getting delayed also, and
> I can't get rid of the rtnl lock there.. Is there anything that can
> be done on the driver side? 200ms
On Mar 26, 2014, at 10:24 AM, Aaron Brice wrote:
> On Tue, Mar 25, 2014 at 10:39 PM, Ronciak, John
> wrote:
>> How are the different PCIe slots connected into the system? In a lot of
>> cases some of the slots are not all equal in terms of how they are laid out
>> in the system. If you move
On Dec 24, 2013, at 2:30 PM, "Tantilov, Emil S"
wrote:
> You are correct - there is a bug in the function when used in a VM since all
> devices appear as part of the same bus, which leads to the driver counting
> all devices.
>
> I'm not sure if there is a good way around this. When the devic
31 matches
Mail list logo
