HEADS UP: Plan to MFC new em driver
I have a version of code ready to MFC, the big difference with CURRENT is that TSO is #ifdef'd off until Andre is able to get that back. I wanted a chance for any concerns to be aired before I did it, issues that anyone has had with the driver in CURRENT? Regards, Jack ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: HEADS UP: Plan to MFC new em driver
On 6/6/07, David Christensen [EMAIL PROTECTED] wrote: I have a version of code ready to MFC, the big difference with CURRENT is that TSO is #ifdef'd off until Andre is able to get that back. Is something broken with TSO? I just added TSO support to bce on CURRENT and was planning on MFC'ing to RELENG_6 within the next week. TSO support is not present in RELENG_6. -Kip ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to [EMAIL PROTECTED]
RE: HEADS UP: Plan to MFC new em driver
I have a version of code ready to MFC, the big difference with CURRENT is that TSO is #ifdef'd off until Andre is able to get that back. Is something broken with TSO? I just added TSO support to bce on CURRENT and was planning on MFC'ing to RELENG_6 within the next week. Dave ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: HEADS UP: Plan to MFC new em driver
On 6/6/07, Jack Vogel [EMAIL PROTECTED] wrote: I have a version of code ready to MFC, the big difference with CURRENT is that TSO is #ifdef'd off until Andre is able to get that back. I wanted a chance for any concerns to be aired before I did it, issues that anyone has had with the driver in CURRENT? I think it would be a good idea to have some testing done before the MFC, so I will try and get a driver tarball put together shortly and post that here, I would appreciate any volunteers that could install and 'kick the tires' a bit :) Jack ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to [EMAIL PROTECTED]
ULE-scheduler helped (Re: new em-driver still broken)
On Tuesday 31 October 2006 20:41, Jack Vogel wrote: = I still think it looks like some kind of scheduler issue going on = here, so maybe this is something to check. Ok. First I tried to cvs the sys/dev/em back to 6.1 -- the new kernel had the same problems... Then I tried to change the 'PCI latency timer' in the BIOS -- from the minimum of 32 to the maximum of 360. Same problems. Then, finally, I decided to give the ULE-scheduler a try -- and things seem to work just fine (with polling enabled on the interface)... The dump has completed -- in 7 hours or so... Could this (failure of the BSD44 scheduler) be due to my using slightly different CPUs (Opteron 244 in the first slot and 246 in the second)? I thought, BIOS/motherboard take care to downgrade the second one to match -- according to the dmesg.boot, both processors are identified as: CPU: AMD Opteron(tm) Processor 244 (1800.01-MHz K8-class CPU) But if the scheduler looks at some CPU-local register, it may, in some cases, still think, it is running on 246? To summarize, unless someone else continues to see em-related problems, the current driver is fine, I guess... -mi ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to [EMAIL PROTECTED]
New em driver - still watchdog timeouts
Hello! Our central backup server is still experiencing the same random problems. The timouts occur every other night or so, when the server has got high CPU load (compressing the backups) and transfers large amounts of data at the same time. Nov 2 02:19:34 datatomb kernel: em1: watchdog timeout -- resetting Nov 2 02:19:34 datatomb kernel: em1: link state changed to DOWN Nov 2 02:19:34 datatomb kernel: vlan23: link state changed to DOWN Nov 2 02:19:34 datatomb kernel: vlan22: link state changed to DOWN Nov 2 02:19:36 datatomb kernel: em1: link state changed to UP Nov 2 02:19:36 datatomb kernel: vlan23: link state changed to UP Nov 2 02:19:36 datatomb kernel: vlan22: link state changed to UP Jack, the hardware should be easy for you or someone else at Intel to get your hands on: http://www.intel.com/design/servers/storage/ssr212cc/index.htm Unfortunately I cannot give you root access to _that_ one. Regards, Patrick -- punkt.de GmbH Internet - Dienstleistungen - Beratung Vorholzstr. 25Tel. 0721 9109 -0 Fax: -100 76137 Karlsruhe http://punkt.de ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: New em driver - still watchdog timeouts
Yes, I know this is still happening. I also have pretty good data now that its a bogus problem, meaning due to scheduling issues the watchdog does not get reset even though the system is just fine as far as transmit descriptors is concerned. I have a patch that detects this and keeps the watchdog from erroneously resetting you, it has been running on my test system for days now without problems. Jack On 11/2/06, Patrick M. Hausen [EMAIL PROTECTED] wrote: Hello! Our central backup server is still experiencing the same random problems. The timouts occur every other night or so, when the server has got high CPU load (compressing the backups) and transfers large amounts of data at the same time. Nov 2 02:19:34 datatomb kernel: em1: watchdog timeout -- resetting Nov 2 02:19:34 datatomb kernel: em1: link state changed to DOWN Nov 2 02:19:34 datatomb kernel: vlan23: link state changed to DOWN Nov 2 02:19:34 datatomb kernel: vlan22: link state changed to DOWN Nov 2 02:19:36 datatomb kernel: em1: link state changed to UP Nov 2 02:19:36 datatomb kernel: vlan23: link state changed to UP Nov 2 02:19:36 datatomb kernel: vlan22: link state changed to UP Jack, the hardware should be easy for you or someone else at Intel to get your hands on: http://www.intel.com/design/servers/storage/ssr212cc/index.htm Unfortunately I cannot give you root access to _that_ one. Regards, Patrick -- punkt.de GmbH Internet - Dienstleistungen - Beratung Vorholzstr. 25Tel. 0721 9109 -0 Fax: -100 76137 Karlsruhe http://punkt.de ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to [EMAIL PROTECTED] ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: New em driver - still watchdog timeouts
On Thu, Nov 02, 2006 at 09:43:34AM -0800, Jack Vogel wrote: Yes, I know this is still happening. I also have pretty good data now that its a bogus problem, meaning due to scheduling issues the watchdog does not get reset even though the system is just fine as far as transmit descriptors is concerned. I have a patch that detects this and keeps the watchdog from erroneously resetting you, it has been running on my test system for days now without problems. I don't understand this explanation of the problem. Here's how I read this paragraph: * It's a bogus problem (which means there's not a problem) * ...due to scheduling issues (which means there IS a problem) * The watchdog does NOT get reset * ...but there's a patch (to fix the bogus problem? or what?) * ...which keeps the watchdog from resetting (but you just said...) Maybe you were in a hurry, I don't know. Either way, the paragraph doesn't make sense. I call for clarification! ;-) -- | Jeremy Chadwick jdc at parodius.com | | Parodius Networkinghttp://www.parodius.com/ | | UNIX Systems Administrator Mountain View, CA, USA | | Making life hard for others since 1977. PGP: 4BD6C0CB | ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: New em driver - still watchdog timeouts
On 11/2/06, Jeremy Chadwick [EMAIL PROTECTED] wrote: On Thu, Nov 02, 2006 at 09:43:34AM -0800, Jack Vogel wrote: Yes, I know this is still happening. I also have pretty good data now that its a bogus problem, meaning due to scheduling issues the watchdog does not get reset even though the system is just fine as far as transmit descriptors is concerned. I have a patch that detects this and keeps the watchdog from erroneously resetting you, it has been running on my test system for days now without problems. I don't understand this explanation of the problem. Here's how I read this paragraph: * It's a bogus problem (which means there's not a problem) * ...due to scheduling issues (which means there IS a problem) * The watchdog does NOT get reset * ...but there's a patch (to fix the bogus problem? or what?) * ...which keeps the watchdog from resetting (but you just said...) Maybe you were in a hurry, I don't know. Either way, the paragraph doesn't make sense. I call for clarification! ;-) OK OK, so I wasnt at my most lucid :) When I said its bogus what I mean is that the watchdog is designed to detect and correct a certain condition, but what is really happening is NOT THAT condition. The watchdog gets set when there is transmit cleanup work pending, everytime SOME progress is made on cleaning it gets restarted, if you actually clean the WHOLE ring then you turn it off. So the idea is it protects against transmit hangs. So why do I say what we see is bogus... because the watchdog is firing even though we DON'T have tx hangs or descriptor shortages. I have a hack that rechecks the number of free descriptors in the watchdog code and returns without resetting if we have max free. I am still trying to figure out how this can happen in the first place however, I'd rather do something that didnt feel quite as much a hack :) So, is that somewhat clearer? Jack ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: New em driver - still watchdog timeouts
Hi, Jack! On Thu, Nov 02, 2006 at 10:39:16AM -0800, Jack Vogel wrote: So why do I say what we see is bogus... because the watchdog is firing even though we DON'T have tx hangs or descriptor shortages. I have a hack that rechecks the number of free descriptors in the watchdog code and returns without resetting if we have max free. I am still trying to figure out how this can happen in the first place however, I'd rather do something that didnt feel quite as much a hack :) This is really good news. I'm confident you will come up with solution. Thanks for all the effort you, Kris and Scott are putting into this. Kind regards, Patrick M. Hausen Leiter Netzwerke und Sicherheit -- punkt.de GmbH Internet - Dienstleistungen - Beratung Vorholzstr. 25Tel. 0721 9109 -0 Fax: -100 76137 Karlsruhe http://punkt.de ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: New em driver - still watchdog timeouts
On Thu, Nov 02, 2006 at 10:39:16AM -0800, Jack Vogel wrote: So, is that somewhat clearer? Very much so! Thank you for the concise answer. This makes much more sense. (The description, I mean -- the actual problem is still a mystery.) -- | Jeremy Chadwick jdc at parodius.com | | Parodius Networkinghttp://www.parodius.com/ | | UNIX Systems Administrator Mountain View, CA, USA | | Making life hard for others since 1977. PGP: 4BD6C0CB | ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to [EMAIL PROTECTED]
New em driver breaks jumbo frames
Don't have much time right now, but wanted to report that the new em driver in -STABLE breaks jumbo frame support for me. With it in the kernel and this card: em1: Intel(R) PRO/1000 Network Connection Version - 6.2.9 port 0xe8c0-0xe8ff mem 0xfe18-0xfe19 irq 18 at device 12.0 on pci2 I'm unable to send an ethernet frame bigger than 2034 bytes, no matter what the mtu is set to. No errors, no kernel messages, it just doesn't go out. tcpdump on both local and remote side show nothing at all. Reverting to the previous driver fixed it. Craig ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: New em driver breaks jumbo frames
Yes, this is the second report I've had, other came to me personally. I'm looking into it. Jack On 11/2/06, Craig Boston [EMAIL PROTECTED] wrote: Don't have much time right now, but wanted to report that the new em driver in -STABLE breaks jumbo frame support for me. With it in the kernel and this card: em1: Intel(R) PRO/1000 Network Connection Version - 6.2.9 port 0xe8c0-0xe8ff mem 0xfe18-0xfe19 irq 18 at device 12.0 on pci2 I'm unable to send an ethernet frame bigger than 2034 bytes, no matter what the mtu is set to. No errors, no kernel messages, it just doesn't go out. tcpdump on both local and remote side show nothing at all. Reverting to the previous driver fixed it. Craig ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to [EMAIL PROTECTED] ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: New em driver breaks jumbo frames
On Thu, Nov 02, 2006 at 02:09:29PM -0800, Jack Vogel wrote: Yes, this is the second report I've had, other came to me personally. There is already a PR about it. mcl ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: New em driver breaks jumbo frames
On Thu, Nov 02, 2006 at 09:27:14PM -0600, Mark Linimon wrote: On Thu, Nov 02, 2006 at 02:09:29PM -0800, Jack Vogel wrote: Yes, this is the second report I've had, other came to me personally. There is already a PR about it. Ah, thanks, guess I should have searched there first... Craig ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: new em-driver still broken
On Tuesday 31 October 2006 20:41, Jack Vogel wrote: = I still think it looks like some kind of scheduler issue going on = here, so maybe this is something to check. Why would the scheduler affect the sys component of the load (which shoots to the sky before the machine drops of the network)? I thought, it only matters for user-space programs (the order in which they run)... Also, if this were a scheduler problem, why would pressing Shift on the keyboard wake everything up? -mi ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: new em-driver still broken
Mikhail Teterin wrote: Actually, it stalls even with polling disabled. It just takes A LOT longer, as I just found out. Instead of minutes, it takes hours of heavey traffict to stall, but it still happens. Pressing a key still wakes it up... Sounds like apm or something making the machine go to sleep? Steve This e.mail is private and confidential between Multiplay (UK) Ltd. and the person or entity to whom it is addressed. In the event of misdirection, the recipient is prohibited from using, copying, printing or otherwise disseminating it or any information contained in it. In the event of misdirection, illegible or incomplete transmission please telephone +44 845 868 1337 or return the E.mail to [EMAIL PROTECTED] ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: new em-driver still broken
середа 01 листопад 2006 08:44, Steven Hartland написав: Actually, it stalls even with polling disabled. It just takes A LOT longer, as I just found out. Instead of minutes, it takes hours of heavey traffict to stall, but it still happens. Pressing a key still wakes it up... Sounds like apm or something making the machine go to sleep? Why would not that happen, when the machine is idle?.. -mi ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: new em-driver still broken
вівторок 31 жовтень 2006 19:43, Jack Vogel написав: This is fairly bizarre :) I think I can say pretty safely that this is NOT an em driver issue, its a scheduler problem of some sort. Am I the only one having problems with em driver? In its latest 6.x-incarnation? Or is the enabled DEVICE_POLLING, but don't enable polling supposed to work? I seem to remember BDE saying, that the driver can cause problem even in the slow-interrupt mode on SMP machines -- just less often (as in my case)... -mi ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: new em-driver still broken
Mikhail Teterin wrote: Why would the scheduler affect the sys component of the load (which shoots to the sky before the machine drops of the network)? I thought, it only matters for user-space programs (the order in which they run)... It also schedules internal kernel threads (such as device driver interrupt threads, etc.) ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: New em driver
On Wed, 01 Nov 2006 00:48:46 +0100, Ronald Klop [EMAIL PROTECTED] wrote: On Sat, 28 Oct 2006 03:44:37 +0200, Jack Vogel [EMAIL PROTECTED] wrote: After a conference call today, it was decided that a merge of my Intel driver base and the STABLE code would take place. This code undoes the INTR_FAST/taskqueue approach for right now. Work will continue to get that to work, but the hope is that this driver will be more stable for the 6.2 release. I encourage everyone that has been having issues to pull the new driver and give us feedback. A few select testers so far have seen stable performance. I'm running this at my workstation at work. Today it still had DEVICE_POLLING compiled in, but no +polling on the interface. It looks ok. I recompiled without DEVICE_POLLING in the kernel tonight and wil report when I have more experience tomorrow. I didn't really stress-test it, but that wasn't necessary in the past to trigger the watchdog timeouts. A little CPU load did the job in the past. Ronald. Without DEVICE_POLLING in the kernel my em0 also survived the day. But again I didn't stresstest it, because there was no time to do that at work. Ronald. -- Ronald Klop Amsterdam, The Netherlands ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: New em driver
On Saturday, 28 October 2006 at 10:10:26 -0700, Jack Vogel wrote: On 10/28/06, Nikolay Pavlov [EMAIL PROTECTED] wrote: On Friday, 27 October 2006 at 18:44:37 -0700, Jack Vogel wrote: After a conference call today, it was decided that a merge of my Intel driver base and the STABLE code would take place. This code undoes the INTR_FAST/taskqueue approach for right now. Work will continue to get that to work, but the hope is that this driver will be more stable for the 6.2 release. I encourage everyone that has been having issues to pull the new driver and give us feedback. A few select testers so far have seen stable performance. Cheers, Jack ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to [EMAIL PROTECTED] Hi, Jack. Could you please post here exact revision number of this merge, just for history. Sure thing: Log: Merge of Intel 6.2.9 em driver code. Approved by: re, scottl, jhb, pdeuskar Revision ChangesPath 1.65.2.19 +731 -589 src/sys/dev/em/if_em.c 1.32.2.5 +97 -71src/sys/dev/em/if_em.h 1.16.2.4 +574 -531 src/sys/dev/em/if_em_hw.c 1.15.2.5 +96 -148 src/sys/dev/em/if_em_hw.h 1.14.2.3 +46 -52src/sys/dev/em/if_em_osdep.h ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to [EMAIL PROTECTED] Hi, Jack. After 22 minutes of production running i have watchdog timeout with new em driver: [EMAIL PROTECTED]:~# uname -a FreeBSD movieserver 6.2-PRERELEASE FreeBSD 6.2-PRERELEASE #0: Tue Oct 31 11:00:14 EST 2006 [EMAIL PROTECTED]:/usr/obj/usr/src/sys/GENERIC i386 Oct 31 12:22:12 movieserver kernel: em0: watchdog timeout -- resetting Oct 31 12:22:12 movieserver kernel: em0: link state changed to DOWN Oct 31 12:22:15 movieserver kernel: em0: link state changed to UP Average load on this em card is ~ 5000-6000 interrupts per second. BUT i want to admit that i have watchdog timeout problems ONLY with this chip: [EMAIL PROTECTED]:2:0: class=0x02 card=0x10118086 chip=0x10108086 rev=0x01 hdr=0x00 vendor = 'Intel Corporation' device = '82546EB Dual Port Gigabit Ethernet Controller (Copper)' class= network subclass = ethernet on all my servers regardless of UP or SMP kernel. I have even box with FreeBSD 5.5 with such em timeouts. -- == - Best regards, Nikolay Pavlov. --- == ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: new em-driver still broken
понеділок 30 жовтень 2006 23:23, Mikhail Teterin написав: Ok. I rebooted and restarted the heavy traffic dump (DEVICE_POLLING in kernel, but without polling actialy enabled). The dump got underway, although the amount of sys load was rather high -- way above 70% most of the time (on a dual-CPU machine). Then I tried to enable polling. The following command worked fine: (ifconfig em0 down; sleep 1; ifconfig em0 polling; sleep 1; ifconfig em0 up) Traffic resumed a couple of second later... A minute later, ALL TRAFFIC stopped. The machine is, again, unreachable via network... Conclusion: The only way to have a working em-interface is to compile with DEVICE_POLLING, but without polling enabled... It is slow (very CPU intensive), but it seems to work... FWIW, enabling polling at boot (via rc.conf) does not change anything either... -mi ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: new em-driver still broken
On 10/31/06, Mikhail Teterin [EMAIL PROTECTED] wrote: понеділок 30 жовтень 2006 23:23, Mikhail Teterin написав: Ok. I rebooted and restarted the heavy traffic dump (DEVICE_POLLING in kernel, but without polling actialy enabled). The dump got underway, although the amount of sys load was rather high -- way above 70% most of the time (on a dual-CPU machine). Then I tried to enable polling. The following command worked fine: (ifconfig em0 down; sleep 1; ifconfig em0 polling; sleep 1; ifconfig em0 up) Traffic resumed a couple of second later... A minute later, ALL TRAFFIC stopped. The machine is, again, unreachable via network... Conclusion: The only way to have a working em-interface is to compile with DEVICE_POLLING, but without polling enabled... It is slow (very CPU intensive), but it seems to work... FWIW, enabling polling at boot (via rc.conf) does not change anything either... Scott's question still hasnt been answered, or if so I dont understand it. If everything was working why were you trying to turn on polling? And if the machine is unreachable over the net, what is happening ON the machine at that point, does it emit any useful information? Jack ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: new em-driver still broken
вівторок 31 жовтень 2006 13:49, Jack Vogel написав: Scott's question still hasnt been answered, or if so I dont understand it. If everything was working why were you trying to turn on polling? Because it was working poorly -- over 50% of the (combined) CPU time was spent in the kernel (sys) instead of on compressing the data (user). Polling seems to promise relief exactly for such situations, so I tried to enable it. And if the machine is unreachable over the net, what is happening ON the machine at that point, does it emit any useful information? Nothing -- the screen (console) is not updated. If I leave top(1) running, I'll see INSANE amounts of CPU-time (1300% each, for example) getting attributed to the compressing programs -- after that top stops refreshing. Hitting a key (even Shift) on the console's keyboard wakes everything up for some time, and traffic resumes -- only to stall again a minute or so later... -mi ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: new em-driver still broken
On Tue, Oct 31, 2006 at 01:57:54PM -0500, Mikhail Teterin wrote: Nothing -- the screen (console) is not updated. If I leave top(1) running, I'll see INSANE amounts of CPU-time (1300% each, for example) getting attributed to the compressing programs -- after that top stops refreshing. What scheduler are you using? 4BSD or ULE? Please check. -- | Jeremy Chadwick jdc at parodius.com | | Parodius Networkinghttp://www.parodius.com/ | | UNIX Systems Administrator Mountain View, CA, USA | | Making life hard for others since 1977. PGP: 4BD6C0CB | ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: new em-driver still broken
вівторок 31 жовтень 2006 14:14, Jeremy Chadwick написав: On Tue, Oct 31, 2006 at 01:57:54PM -0500, Mikhail Teterin wrote: Nothing -- the screen (console) is not updated. If I leave top(1) running, I'll see INSANE amounts of CPU-time (1300% each, for example) getting attributed to the compressing programs -- after that top stops refreshing. What scheduler are you using? 4BSD or ULE? Please check. 4BSD -- the default: % fgrep SCHED /sys/amd64/conf/PANDORA #optionsSCHED_ULE # ULE scheduler options SCHED_4BSD # 4BSD scheduler options _KPOSIX_PRIORITY_SCHEDULING # POSIX P1003_1B real-time extensions Yours, -mi ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: New em driver
On Sat, 28 Oct 2006 03:44:37 +0200, Jack Vogel [EMAIL PROTECTED] wrote: After a conference call today, it was decided that a merge of my Intel driver base and the STABLE code would take place. This code undoes the INTR_FAST/taskqueue approach for right now. Work will continue to get that to work, but the hope is that this driver will be more stable for the 6.2 release. I encourage everyone that has been having issues to pull the new driver and give us feedback. A few select testers so far have seen stable performance. I'm running this at my workstation at work. Today it still had DEVICE_POLLING compiled in, but no +polling on the interface. It looks ok. I recompiled without DEVICE_POLLING in the kernel tonight and wil report when I have more experience tomorrow. I didn't really stress-test it, but that wasn't necessary in the past to trigger the watchdog timeouts. A little CPU load did the job in the past. Ronald. -- Ronald Klop Amsterdam, The Netherlands ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: new em-driver still broken
Actually, it stalls even with polling disabled. It just takes A LOT longer, as I just found out. Instead of minutes, it takes hours of heavey traffict to stall, but it still happens. Pressing a key still wakes it up... -mi ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: new em-driver still broken
On 10/31/06, Mikhail Teterin [EMAIL PROTECTED] wrote: Actually, it stalls even with polling disabled. It just takes A LOT longer, as I just found out. Instead of minutes, it takes hours of heavey traffict to stall, but it still happens. Pressing a key still wakes it up... -mi This is fairly bizarre :) I think I can say pretty safely that this is NOT an em driver issue, its a scheduler problem of some sort. Jack ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: new em-driver still broken
On 10/31/06, Jack Vogel [EMAIL PROTECTED] wrote: On 10/31/06, Mikhail Teterin [EMAIL PROTECTED] wrote: Actually, it stalls even with polling disabled. It just takes A LOT longer, as I just found out. Instead of minutes, it takes hours of heavey traffict to stall, but it still happens. Pressing a key still wakes it up... -mi This is fairly bizarre :) I think I can say pretty safely that this is NOT an em driver issue, its a scheduler problem of some sort. Jack So like : options _KPOSIX_PRIORITY_SCHEDULING # POSIX P1003_1B real-time extensions Looks like a special option that most probably dont have, but I'm guessing that this is not something you can do without?? ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: new em-driver still broken
On Tue, 31 Oct 2006 16:46:10 -0800 Jack Vogel [EMAIL PROTECTED] wrote: So like : options _KPOSIX_PRIORITY_SCHEDULING # POSIX P1003_1B real-time extensions Looks like a special option that most probably dont have [...] This option is in GENERIC, so it is something most people probably have. Joerg -- | /\ ASCII ribbon | GnuPG Key ID | e86d b753 3deb e749 6c3a | | \ / campaign against |0xbbcaad24 | 5706 1f7d 6cfd bbca ad24 | | XHTML in email |.the next sentence is true. | | / \ and news | .the previous sentence was a lie.| signature.asc Description: PGP signature
Re: new em-driver still broken
On 10/31/06, Joerg Pernfuss [EMAIL PROTECTED] wrote: On Tue, 31 Oct 2006 16:46:10 -0800 Jack Vogel [EMAIL PROTECTED] wrote: So like : options _KPOSIX_PRIORITY_SCHEDULING # POSIX P1003_1B real-time extensions Looks like a special option that most probably dont have [...] This option is in GENERIC, so it is something most people probably have. Opps, guess I should have checked first :) I still think it looks like some kind of scheduler issue going on here, so maybe this is something to check. Jack ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: New em driver
On Friday, 27 October 2006 at 18:44:37 -0700, Jack Vogel wrote: After a conference call today, it was decided that a merge of my Intel driver base and the STABLE code would take place. This code undoes the INTR_FAST/taskqueue approach for right now. Work will continue to get that to work, but the hope is that this driver will be more stable for the 6.2 release. I encourage everyone that has been having issues to pull the new driver and give us feedback. A few select testers so far have seen stable performance. Cheers, Jack ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to [EMAIL PROTECTED] Hi, Jack. Could you please post here exact revision number of this merge, just for history. -- == - Best regards, Nikolay Pavlov. --- == ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: new em-driver still broken
Mikhail Teterin wrote: On Saturday 21 October 2006 13:33, Gleb Smirnoff wrote: = We aren't currently speaking about performance, we need to know whether = kernel with DEVICE_POLLING option makes NIC work stable. Having noticed today's em-driver update, I rebuilt world/kernel and tried the dump-test again. The kernel had the DEVICE_POLLING option in it, but polling was not, actually, enabled on em0. With three simultanious dumps arriving, the system-component of the load was 40-50%: 2 usersLoad 2.64 0.98 0.41 28 ??? 00:13 Mem:KBREALVIRTUAL VN PAGER SWAP PAGER Tot Share TotShareFree in out in out Act 109936 30080 19606442464 1642672 count All 366172 32684 1413555k48140 pages Interrupts Proc:r p d s wCsw Trp Sys Int Sof Fltcow6720 total 3 55 9736 151241k19989 47 232248 wireirq1: atkb 79108 act irq6: fdc0 35.8%Sys 4.5%Intr 59.7%User 0.0%Nice 0.0%Idl60372 inact irq15: ata ||||||||||276 cache irq17: fwo ==++ 1642396 freeirq20: nve daefr irq21: ohc Namei Name-cacheDir-cache prcfr irq22: ehc Calls hits% hits% react 2710 irq25: em0 229 229 100 pdwak24 irq29: amr zfodpdpgs 1993 cpu0: time Disks ad4 ad6 amrd0 ozfod intrn 1993 cpu1: time KB/t 0.00 0.00 128 %slo-z 221184 buf tps 0 012 4 tfree22 dirtybuf MB/s 0.00 0.00 1.4910 desiredvnodes % busy0 030 2409 numvnodes It was working... Then I entered the following shell command: % (ifconfig em0 polling; sleep 179; ifconfig em0 -polling) Hoping, that, even if polling causes problems, three minutes later it will turn back off automatically. Unfortunately, the machine dropped off the network immediately and is not coming back. I'll get to its console on Monday, but something is still very wrong with the em-driver :-( -mi So the driver works fine for you so long as you don't try to change the polling parameter while it's running? Scott ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: New em driver
On 10/28/06, Nikolay Pavlov [EMAIL PROTECTED] wrote: On Friday, 27 October 2006 at 18:44:37 -0700, Jack Vogel wrote: After a conference call today, it was decided that a merge of my Intel driver base and the STABLE code would take place. This code undoes the INTR_FAST/taskqueue approach for right now. Work will continue to get that to work, but the hope is that this driver will be more stable for the 6.2 release. I encourage everyone that has been having issues to pull the new driver and give us feedback. A few select testers so far have seen stable performance. Cheers, Jack ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to [EMAIL PROTECTED] Hi, Jack. Could you please post here exact revision number of this merge, just for history. Sure thing: Log: Merge of Intel 6.2.9 em driver code. Approved by: re, scottl, jhb, pdeuskar Revision ChangesPath 1.65.2.19 +731 -589 src/sys/dev/em/if_em.c 1.32.2.5 +97 -71src/sys/dev/em/if_em.h 1.16.2.4 +574 -531 src/sys/dev/em/if_em_hw.c 1.15.2.5 +96 -148 src/sys/dev/em/if_em_hw.h 1.14.2.3 +46 -52src/sys/dev/em/if_em_osdep.h ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to [EMAIL PROTECTED]
New em driver
After a conference call today, it was decided that a merge of my Intel driver base and the STABLE code would take place. This code undoes the INTR_FAST/taskqueue approach for right now. Work will continue to get that to work, but the hope is that this driver will be more stable for the 6.2 release. I encourage everyone that has been having issues to pull the new driver and give us feedback. A few select testers so far have seen stable performance. Cheers, Jack ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to [EMAIL PROTECTED]
new em-driver still broken (was: Re: em network issues)
On Saturday 21 October 2006 13:33, Gleb Smirnoff wrote: = We aren't currently speaking about performance, we need to know whether = kernel with DEVICE_POLLING option makes NIC work stable. Having noticed today's em-driver update, I rebuilt world/kernel and tried the dump-test again. The kernel had the DEVICE_POLLING option in it, but polling was not, actually, enabled on em0. With three simultanious dumps arriving, the system-component of the load was 40-50%: 2 usersLoad 2.64 0.98 0.41 28 жов 00:13 Mem:KBREALVIRTUAL VN PAGER SWAP PAGER Tot Share TotShareFree in out in out Act 109936 30080 19606442464 1642672 count All 366172 32684 1413555k48140 pages Interrupts Proc:r p d s wCsw Trp Sys Int Sof Fltcow6720 total 3 55 9736 151241k19989 47 232248 wireirq1: atkb 79108 act irq6: fdc0 35.8%Sys 4.5%Intr 59.7%User 0.0%Nice 0.0%Idl60372 inact irq15: ata ||||||||||276 cache irq17: fwo ==++ 1642396 freeirq20: nve daefr irq21: ohc Namei Name-cacheDir-cache prcfr irq22: ehc Calls hits% hits% react 2710 irq25: em0 229 229 100 pdwak24 irq29: amr zfodpdpgs 1993 cpu0: time Disks ad4 ad6 amrd0 ozfod intrn 1993 cpu1: time KB/t 0.00 0.00 128 %slo-z 221184 buf tps 0 012 4 tfree22 dirtybuf MB/s 0.00 0.00 1.4910 desiredvnodes % busy0 030 2409 numvnodes It was working... Then I entered the following shell command: % (ifconfig em0 polling; sleep 179; ifconfig em0 -polling) Hoping, that, even if polling causes problems, three minutes later it will turn back off automatically. Unfortunately, the machine dropped off the network immediately and is not coming back. I'll get to its console on Monday, but something is still very wrong with the em-driver :-( -mi ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to [EMAIL PROTECTED]
