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
