Why is em nic generating interrupts?
Hello, everyone! I've got a [uniprocessor 5.1-RELEASE] router machine with fxp and em nics. I've built my kernel with the following included: options DEVICE_POLLING options HZ=2500 and enabled polling in /etc/sysctl.conf. Having looked through a vmstat -i output I see that the em card is generating interrupts, although they should be disabled (as I see in em's source code). interrupt total rate stray irq01 0 stray irq61 0 npx0 irq131 0 ata0 irq14 2339 0 em0 irq10421457155 fxp0 irq5 2 0 atkbd0 irq13326 1 clk irq06778872 2500 rtc irq8 346899127 Total 7552898 2786 What's happening? Is polling working in my case? If yes, why is vmstat showing interrupts? I see clearly, that fxp's counter doesn't increase, and em's is constantly growing. Is there anyone who knows for sure that em's polling works? Thanks in advance to anyone for an idea! Please also CC: me as I'm not subscribed. P.S. I've posted this question to questions@, but so far the question is still open. So if someone finds this post familiar, please just ignore it. -- Best wishes, [EMAIL PROTECTED] ___ [EMAIL PROTECTED] mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to [EMAIL PROTECTED]
RE: Why is em nic generating interrupts?
-Original Message- From: Terry Lambert [mailto:[EMAIL PROTECTED] Sent: Thursday, October 09, 2003 5:19 PM To: Michael O. Boev Cc: [EMAIL PROTECTED] Subject: Re: Why is em nic generating interrupts? Michael O. Boev wrote: I've got a [uniprocessor 5.1-RELEASE] router machine with fxp and em nics. I've built my kernel with the following included: options DEVICE_POLLING options HZ=2500 and enabled polling in /etc/sysctl.conf. [ ... ] What's happening? Is polling working in my case? If yes, why is vmstat showing interrupts? I see clearly, that fxp's counter doesn't increase, and em's is constantly growing. Is there anyone who knows for sure that em's polling works? You may want to ask Luigi; polling is his code. However, I believe the issue is that polling doesn't start until you take an interrupt, and it stops as soon as there is no more data to process, and waits for the next interrupt. If you were to jack your load way up, you would probably see an increase in interrupts, then them dropping off dramatically. To this dare I object, that there is traffic going through this machine, and fxp0 is NOT generating interrupts, while em IS. So, if the rule above works, they both have to behave in same ways. If all else fails, read the source code... 8-). )) I've tried to, but... had to ask here. So all is left is to ask Luigi and Intel. -- Terry -- Best wishes, [EMAIL PROTECTED] ___ [EMAIL PROTECTED] mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: Why is em nic generating interrupts?
- Original Message - From: Terry Lambert [EMAIL PROTECTED] To: Michael O. Boev [EMAIL PROTECTED]; Terry Lambert [EMAIL PROTECTED] Cc: [EMAIL PROTECTED] Sent: Saturday, October 11, 2003 3:54 AM Subject: RE: Why is em nic generating interrupts? Michael O. Boev wrote: From: Terry Lambert [mailto:[EMAIL PROTECTED] Michael O. Boev wrote: I've got a [uniprocessor 5.1-RELEASE] router machine with fxp and em nics. I've built my kernel with the following included: options DEVICE_POLLING options HZ=2500 and enabled polling in /etc/sysctl.conf. [ ... ] What's happening? Is polling working in my case? If yes, why is vmstat showing interrupts? I see clearly, that fxp's counter doesn't increase, and em's is constantly growing. Is there anyone who knows for sure that em's polling works? You may want to ask Luigi; polling is his code. However, I believe the issue is that polling doesn't start until you take an interrupt, and it stops as soon as there is no more data to process, and waits for the next interrupt. If you were to jack your load way up, you would probably see an increase in interrupts, then them dropping off dramatically. To this dare I object, that there is traffic going through this machine, and fxp0 is NOT generating interrupts, while em IS. So, if the rule above works, they both have to behave in same ways. This is the third time I've received this message. I guess you feel some urgency about receiving a reply? Oh, no )). I even didn't send it for 3 times. Sorry for annoyance. My answer is this: I did the polling code for a number of the drivers, and though it was committed by someone else, I can guarantee you that it will have interrupts, unless the code was implemented incorreectly, since the code is meant to do this polling only under heavy load. I believe you... I just wondered why two drivers behaved differently. ... If your FXP is not generating any interrupts at all, i think that the polling code in it is probably broken. Note: I believe this might be one of the ones I modified, since Luigi's code originally only dealt with Gigabit NICs, though I may be mistaken. If so, my statement that it's broken should be considered to be pretty authoritative. 8-). Then, OK, it is now fxp's polling that probably behaves oddly :)). Since I've ever been only using fxps, I got used to this behaviour. Thus my questions. -- Terry Thanks for thorough explanations! Mike. ___ [EMAIL PROTECTED] mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to [EMAIL PROTECTED]
ifconfig problem
Hello! I've upgraded one of my boxes (4.5-RELEASE to FreeBSD 4.6-RELEASE) and encountered the following problem: After the upgrade it won't bring one of its two identical interfaces (ed0 and ed1) up at the boot-time. The internal one(ed1) was brought up cleanly, the external one(ed0) didn't get up. The only difference between them was that i was setting a specific MAC address on ed0. My rc.conf line for ed0 was like: ifconfig_ed0=inet 1.2.3.4 lladdr 01:02:03:04:05:06 And the ifconfig at the boot time said that it: can't set link-level netmask or broadcast. Changing lladdr to link or ether didn't help, nor did interchanging the order of these addresses on the config line. Now I've found that I still can bring the interface up by executing two separate ifconfigs like: ifconfig ed0 lladdr 01:02:03:04:05:06 ifconfig ed0 inet 1.2.3.4 My current workaround is to set MAC in /etc/rc.early and the IP in rc.conf. My investigation revealed that this error message was introduced during the MFC of /src/sbin/ifconfig/ifconfig.c, version 1.51.2.16, 2002/04/03 by ru. I suspect that I've no real intention to set any link level netmask or broadcasts. Therefore, there must be an programming error somewhere in ifconfig.c, I even suppose it is in the setifaddr function, but I can't say it for sure, because I lack knowledge to understand the code in whole. I will make a PR soon, if there're no sudden objections. Best wishes, Mike Boev. To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-current in the body of the message
