Re: Question about em_irq_fast

2016-08-08 Thread Sreekanth Rupavatharam
Quite possibly, but my question remains. If the register doesn’t have any specific value for just a received packet(no other events), how is a value of 0 considered to be wrong? Or to flip the question around, what should be the value of the register for just receive of a packet? Thanks, -Sree

Re: Question about em_irq_fast

2016-08-08 Thread Sreekanth Rupavatharam
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 this register or am I missing something he

Question about em_irq_fast

2016-08-05 Thread Sreekanth Rupavatharam
We have this code snippet in em_irq_fast ifp = adapter->ifp; reg_icr = E1000_READ_REG(&adapter->hw, E1000_ICR); /* Hot eject? */ if (reg_icr == 0x) return FILTER_STRAY; /* Definitely not our interrupt. */ if (reg

Re: Possible transmit/stats problem in igb driver.

2016-06-08 Thread Sreekanth Rupavatharam
Jack Vogel mailto:jfvo...@gmail.com>> wrote: That's an interesting theory, you could add a check into the tx path looking for a zero m_len and see, seems unlikely though :) Jack On Fri, Jun 3, 2016 at 1:15 PM, Sreekanth Rupavatharam mailto:rupav...@juniper.net>> wrote: Wondering

Re: Possible transmit/stats problem in igb driver.

2016-06-03 Thread Sreekanth Rupavatharam
nth On 6/2/16, 2:41 PM, "hiren panchasara" wrote: >+ Sean, Eric > >On 06/02/16 at 09:11P, Sreekanth Rupavatharam wrote: >> Inline >> >> >Apart from stats, do you see anything else going wrong? i.e. do you >> >actually see less packets (arp repli

Re: Possible transmit/stats problem in igb driver.

2016-06-02 Thread Sreekanth Rupavatharam
> >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

Re: Possible transmit/stats problem in igb driver.

2016-06-02 Thread Sreekanth Rupavatharam
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

Re: Possible transmit/stats problem in igb driver.

2016-06-02 Thread Sreekanth Rupavatharam
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

Possible transmit/stats problem in igb driver.

2016-06-02 Thread Sreekanth Rupavatharam
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

Re: Double cleanup in igb_attach

2015-02-12 Thread Sreekanth Rupavatharam
66>err_pci<http://optimus.englab.juniper.net:8180/source/s?defs=err_pci&project=X-FreeBSD-10>: -- Thanks, Sreekanth From: Jack Vogel mailto:jfvo...@gmail.com>> Date: Thursday, February 12, 2015 at 12:00 PM To: Sreekanth Rupavatharam mailto:rupav...@juniper.net>> C

Re: Double cleanup in igb_attach

2015-02-12 Thread Sreekanth Rupavatharam
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

Re: Double cleanup in igb_attach

2015-01-27 Thread Sreekanth Rupavatharam
;ll assign it to >the intel team. > >Thanks! > > >-a > > >On 27 January 2015 at 12:42, Jack Vogel wrote: >> Yes, I will look them over. >> >> Jack >> >> >> On Tue, Jan 27, 2015 at 12:38 PM, Sreekanth Rupavatharam < >> rupav...@jun

Re: Double cleanup in igb_attach

2015-01-27 Thread Sreekanth Rupavatharam
om>) Jack On Tue, Jan 27, 2015 at 12:21 PM, Sreekanth Rupavatharam mailto:rupav...@juniper.net>> wrote: 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>> wr

Re: Double cleanup in igb_attach

2015-01-27 Thread Sreekanth Rupavatharam
you think? Jack On Tue, Jan 27, 2015 at 11:51 AM, Sreekanth Rupavatharam mailto:rupav...@juniper.net>> wrote: Hiren, Can you help commit this? Index: if_igb.c === --- if_igb.c (revision 298053) +++ if_igb.c (working copy)

Re: Double cleanup in igb_attach

2015-01-27 Thread Sreekanth Rupavatharam
rote: + Jack On Tue, Jan 27, 2015 at 12:00:19AM +, Sreekanth Rupavatharam wrote: Apologies if this is not the right forum. In igb_attach function, we have this code. err_late: igb_detach(dev); igb_free_transmit_structures(adapter); igb_free_receive_st

Re: Double cleanup in igb_attach

2015-01-27 Thread Sreekanth Rupavatharam
> >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

Double cleanup in igb_attach

2015-01-26 Thread Sreekanth Rupavatharam
Apologies if this is not the right forum. In igb_attach function, we have this code. err_late: igb_detach(dev); igb_free_transmit_structures(adapter); igb_free_receive_structures(adapter); igb_release_hw_control(adapter); err_pci: igb_free_pci_resources(adapter);