I think this is the case, as the problem seems to crop up after a fixed number of packet receives (around 1000, similar to our RX descriptor count).
-- Saso On 10/2/16 3:40 AM, Garrett D'Amore wrote: > probably we should do something. like reap the descriptors. i am afk but the > usual strategy is to treat these kinds of interrupts just like normal rx. > after that you should ack the interrupt of course. > > Sent from my iPhone > >> On Oct 1, 2016, at 6:31 PM, Saso Kiselkov <skiselkov...@gmail.com> wrote: >> >>> On 10/2/16 12:23 AM, Robert Mustacchi wrote: >>>> On 10/1/16 15:15 , Saso Kiselkov wrote: >>>>> On 10/1/16 11:45 PM, Dale Ghent wrote: >>>>> >>>>>> On Oct 1, 2016, at 3:36 PM, Saso Kiselkov <skiselkov...@gmail.com> wrote: >>>>>> >>>>>> So I'm playing around with a box that has an on-board Realtek NIC and >>>>>> periodically, about once every 2-5 minutes, the network just goes out to >>>>>> lunch and stops responding to ping or attempts to send anything from >>>>>> the box. I noticed that while doing so, the box is getting floored by >>>>>> interrupts from the NIC, so I see tons of rge_intr activity and one CPU >>>>>> core receiving about 160000 interrupts per second (other cores are idle). >>>>> >>>>> One core getting all the interrupts is expected, as both these chips and >>>>> the driver do not support RSS. >>>>> >>>>> The key thing here is to see what rge_intr() is actually doing. It has 2 >>>>> outcomes: It identifies the interrupt type, processes it, then returns to >>>>> the DDI that it was claimed. IF it doesn't identify the interrupt, >>>>> rge_intr() returns and reports unclaimed to the DDI. >>>>> >>>>> Knowing this info would be a good first step in figuring out what's going >>>>> on. >>>> >>>> Gah, I'm an idiot, it's actually a bitmask of two things: >>>> >>>> RX_FIFO_OVERFLOW_INT | NO_RXDESC_INT >>>> >>>> Apparently, we don't give it enough rx descriptors. Trying to now figure >>>> out where to change that... >>> >>> There'll always be cases where we don't have enough rx descriptors for >>> devices. Presumably we shouldn't actually care about receiving that >>> interrupt. Do you happen to have a specification for the device handy? >>> >>> Given that we're not doing anything with the NO_RXDESC_INT, we probably >>> should just mask it on the device if possible. >> >> Just as a general FYI, I'm dealing with 8168G version of the MAC. >> FreeBSD does have a driver that supports it, but since the driver there >> appears home-grown (similar to ours), trying to transplant it would be a >> major undertaking. I'll try to identify the major differences between >> the versions we support and the 8168G, but of course, this being >> hardware, they are many and few of them make any logical sense. >> >> -- >> Saso >> > > ------------------------------------------- illumos-discuss Archives: https://www.listbox.com/member/archive/182180/=now RSS Feed: https://www.listbox.com/member/archive/rss/182180/21175430-2e6923be Modify Your Subscription: https://www.listbox.com/member/?member_id=21175430&id_secret=21175430-6a77cda4 Powered by Listbox: http://www.listbox.com
