,
-Sreekanth
On 8/8/16, 2:02 PM, "Sean Bruno" wrote:
It sounds like QEMU is spamming packets and interrupts incorrectly as
normal hardware doesn't have this issue.
___
freebsd-net@freebsd.org mailing list
https://lists.freebsd.org/m
Thanks,
-Sreekanth
> On Aug 8, 2016, at 12:09 PM, Sean Bruno wrote:
>
> Is this with the "lem" driver or the "em" driver under QEMU?
>
It's for lem driver under qemu. My question is mainly about there being no
specific bit for a packet received in th
is 0. Can anyone tell me if it’s ok or not to
remove the check for 0 value ?
Thanks,
-Sreekanth
___
freebsd-net@freebsd.org mailing list
https://lists.freebsd.org/mailman/listinfo/freebsd-net
To unsubscribe, send any mail to "freeb
o run this test in bare metal
mode. Another point I confirmed is that the descriptor is consumed by the
hardware(I get igb_txeof calls for the packets). The issue is not happening in
the previously unified em driver(before igb driver was created)
Thanks,
-Sreekanth
On Jun 3, 2016, at 1:22 PM,
Wondering if this can happen if somehow the mbuf->m_len is not correct(e.g., 0)
and thus causing the dma to fail silently. The only way this is happening if
the arp request is larger than 64 bytes and the arp response code is reusing
the packet to send a 64 byte response.
Thanks,
-Sreeka
>
>Very interesting. Do you tune defaults at all? What does sysctl hw.igb
>say? Not sure if bumping up txd would help.
>
I do not think it’s a problem with txd, as the traffic is very light(about
500packets/sec). Anyways, here are the values.
hw.igb.rx_process_limit: 100
hw.igb.num_queues: 0
hw.i
Don’t see any errors as such. Here’s the complete stats.
Thanks,
-Sreekanth
From: Jack Vogel
Date: Thursday, June 2, 2016 at 2:40 PM
To: Sreekanth Rupavatharam
Cc: hiren panchasara , "freebsd-net@freebsd.org"
Subject: Re: Possible transmit/stats problem in igb driver.
Hmm
Inline
>Apart from stats, do you see anything else going wrong? i.e. do you
>actually see less packets (arp replies??) than expected?
[SR] The packets are not going out on the wire. The tool doesn’t receive the
packets. That’s how I started noticing the issue.
>Taking your example, tx_packets
I am seeing a strange issue with transmit with igb driver and wanted to check
with you if this issue is already noted. I didn’t find anything particularly
matching in Bugzilla. There is a test I am running where a iXIa is sending arps
at about 500/sec for 10 seconds. This test works fine if the
D-10>(adapter<http://optimus.englab.juniper.net:8180/source/s?defs=adapter&project=X-FreeBSD-10>->ifp<http://optimus.englab.juniper.net:8180/source/s?defs=ifp&project=X-FreeBSD-10>);
766<http://optimus.englab.juniper.net:8180/source/xref/X-FreeBSD-10/sys/dev/e1000/if_em.c#7
igb_detach there
causes a NULL pointer access. The best way to deal with it is to take out the
igb_detach call from the err_late: label. Thoughts? Comments?
-- Thanks,
Sreekanth
From: Jack Vogel mailto:jfvo...@gmail.com>>
Date: Tuesday, January 27, 2015 at 12:42 PM
To: Sreekanth Rupava
Done,
I have also attached the patch in the bug report.
-- Thanks,
Sreekanth
On 1/27/15, 12:54 PM, "Adrian Chadd" wrote:
>Hi!
>
>Sreekanth - this does look like it is valid and needs fixing. Just
>file a FreeBSD PR (bugs.freebsd.org/submit/) and we'
Thanks jack,
Now, can you please review these changes? And commit if you deem it fit?
Thanks,
-Sreekanth
On Jan 27, 2015, at 12:24 PM, "Jack Vogel"
mailto:jfvo...@gmail.com>> wrote:
E, I am one of those people :)
(jack.vo...@intel.com<mailto:jack.vo...@intel.c
Definitely, but I didn't have the contact info of those people.
Thanks,
-Sreekanth
On Jan 27, 2015, at 12:15 PM, "Jack Vogel"
mailto:jfvo...@gmail.com>> wrote:
If you want something committed to an Intel driver, asking Intel might be the
courteous thing to do, don't
) == 0) /* igb_detach did the cleanup */
+ return(error);
igb_free_transmit_structures(adapter);
igb_free_receive_structures(adapter);
igb_release_hw_control(adapter);
-- Thanks,
Sreekanth
On 1/27/15, 11:28 AM, "hiren panchasara"
mailto:hi...@strugglingcoder.info>> w
>
>Seems reasonable to me at the first glance.
>
>We need to call IGB_CORE_LOCK_DESTROY(adapter) before returning though.
>
Not necessary. igb_detach does that.
___
freebsd-net@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-n
leanup */
+ return;
igb_free_transmit_structures(adapter);
Can anyone comment on it and tell me if my understanding is incorrect?
-- Thanks,
Sreekanth
___
freebsd-net@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-net
To unsubscrib
Netstat errors are those errors reported by the Hardware(NIC) for e.g,
buffer underrun overrun etc,They do not check for errors in tcp layer.
Sreekanth
> -Original Message-
> From: [EMAIL PROTECTED]
> [mailto:[EMAIL PROTECTED] On Behalf Of Sherwood Botsford
> Sent: Wednesd
4.6 machine and the client is Windows
2000
Thanks in advance
Sreekanth
___
[EMAIL PROTECTED] mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-net
To unsubscribe, send any mail to "[EMAIL PROTECTED]"
Try
ifconfig xl0 media auto
Sreekanth
> -Original Message-
> From: [EMAIL PROTECTED]
> [mailto:[EMAIL PROTECTED] On Behalf Of Andrea Venturoli
> Sent: Tuesday, July 29, 2003 4:47 PM
> To: [EMAIL PROTECTED]
> Subject: Re: xl0 full duplex
>
>
> **
That brings an interesting topic.If the Interface has not been assigned
an IP address.The Interface is NOT initialized.So you cannot really use
the interface.Ofcourse you can bypass this by hacking into driver.But do
you want to do that is another questions.
Just my 2 cents
Sreekanth
Couldn't it be done just by executing the following command ?
#route add 255.255.255.255 -net 255.255.255.255 -ifp [primary interface]
I know it is kind of crude but it works in my case :-)
Sreekanth
> -Original Message-
> From: [EMAIL PROTECTED]
> [mailto:[EMAIL PROTEC
does not tell you explicitly that it is half-duplex.If
there is no full-duplex in ifconfig display it is half-duplex.Check
those settings again and may be you are in for a surprise..
Sreekanth
> -Original Message-
> From: [EMAIL PROTECTED]
> [mailto:[EMAIL PROTECTED] On Behalf
aseTX switch).
2) Connect it to a 100Base port and try.
3) Connect to another machine with crossover cable and try
First try 1 and if it fails try 2 and 3.
Hope it helps.
Sreekanth
> -Original Message-
> From: [EMAIL PROTECTED]
> [mailto:[EMAIL PROTECTED] On Behalf Of
>
suggestion is to use the flags IFF_RUNNING|IFF_OACTIVE
to decide if we want to reset the interface again.
Comments..?
Sreekanth
> -Original Message-
> From: [EMAIL PROTECTED]
> [mailto:[EMAIL PROTECTED] On Behalf Of Sreekanth
> Sent: Thursday, May 29, 2003 9:36 AM
> To: [EMAIL
em_ioctl() has a call to ether_ioctl() which in turn calls arp_ifinit().
Sreekanth
> -Original Message-
> From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED]
> Sent: Thursday, May 29, 2003 9:17 AM
> To: Sreekanth
> Cc: 'Petri Helenius'; 'Ruslan Ermilov&
Could be attributed to the spanning tree in the switch.I have seen it
happening(especially with cisco switches).I bet you are not able to send
out any packet(Not just Garp).
Sreekanth
> -Original Message-
> From: [EMAIL PROTECTED]
> [mailto:[EMAIL PROTECTED] On Behalf Of Petri
27 matches
Mail list logo
