Re: [E1000-devel] e1000e tx queue timeout in 3.3.0 (bisected to BQL support for e1000e)
I had done some work on this and to me it looks like this can only happen if driver does not report bytes_compl and pkts_compl stats correctly. I will experiment more tomorrow. -Tushar >-Original Message- >From: netdev-ow...@vger.kernel.org [mailto:netdev-ow...@vger.kernel.org] >On Behalf Of Ben Greear >Sent: Thursday, April 19, 2012 4:27 PM >To: netdev; e1000-devel list; therb...@google.com >Subject: e1000e tx queue timeout in 3.3.0 (bisected to BQL support for >e1000e) > >Test case: > >Run full duplex traffic (900Mbps rx, 400Mbps tx) UDP traffic (moderate >speeds of traffic has issues as well, maybe not as easy to reproduce) >reset peer interface >> tx queue timeout > > >Apr 19 16:12:48 localhost kernel: e1000e: eth2 NIC Link is Down Apr 19 >16:12:48 localhost kernel: e1000e :08:00.0: eth2: Reset adapter Apr 19 >16:12:48 localhost kernel: e1000e: eth3 NIC Link is Down Apr 19 16:12:50 >localhost kernel: e1000e: eth2 NIC Link is Up 1000 Mbps Full Duplex, Flow >Control: Rx/Tx Apr 19 16:12:50 localhost kernel: ADDRCONF(NETDEV_CHANGE): >eth2: link becomes ready Apr 19 16:12:50 localhost kernel: e1000e: eth3 >NIC Link is Up 1000 Mbps Full Duplex, Flow Control: Rx/Tx Apr 19 16:12:50 >localhost kernel: ADDRCONF(NETDEV_CHANGE): eth3: link becomes ready Apr 19 >16:12:54 localhost /usr/sbin/irqbalance: Load average increasing, re- >enabling all cpus for irq balancing Apr 19 16:12:55 localhost kernel: >[ cut here ] Apr 19 16:12:55 localhost kernel: >WARNING: at /home/greearb/git/linux-3.3.dev.y/net/sched/sch_generic.c:256 >dev_watchdog+0xf4/0x154() Apr 19 16:12:55 localhost kernel: Hardware name: >X7DBU Apr 19 16:12:55 localhost kernel: NETDEV WATCHDOG: eth2 (e1000e): >transmit queue 0 timed out Apr 19 16:12:55 localhost kernel: Modules >linked in: xt_CT iptable_raw 8021q garp stp llc veth ppdev parport_pc lp >parport fuse macvlan pktgen iscsi_tcp libiscsi_tcp libiscsi >scsi_transport_iscsi lockd w83793 w83627hf hwmon_vid coretemp iTCO_wdt >microcode iTCO_vendor_support pcspkr i5k_amb ioatdma i2c_i801 i5000_edac >dca edac_core e1000e shpchp uinput sunrpc ipv6 autofs4 floppy radeon ttm >drm_kms_helper drm hwmon i2c_algo_bit i2c_core [last unloaded: nf_nat] Apr >19 16:12:55 localhost kernel: Pid: 0, comm: kworker/0:1 Not tainted 3.2.0- >rc2+ #36 Apr 19 16:12:55 localhost kernel: Call Trace: >Apr 19 16:12:55 localhost kernel: [] >warn_slowpath_common+0x80/0x98 Apr 19 16:12:55 localhost kernel: >[] warn_slowpath_fmt+0x41/0x43 Apr 19 16:12:55 localhost >kernel: [] dev_watchdog+0xf4/0x154 Apr 19 16:12:55 >localhost kernel: [] run_timer_softirq+0x16f/0x201 Apr >19 16:12:55 localhost kernel: [] ? >netif_tx_unlock+0x57/0x57 Apr 19 16:12:55 localhost kernel: >[] __do_softirq+0x86/0x12f Apr 19 16:12:55 localhost >kernel: [] ? hrtimer_interrupt+0x12b/0x1bd Apr 19 >16:12:55 localhost kernel: [] call_softirq+0x1c/0x30 Apr >19 16:12:55 localhost kernel: [] do_softirq+0x41/0x7e >Apr 19 16:12:55 localhost kernel: [] irq_exit+0x3f/0xbb >Apr 19 16:12:55 localhost kernel: [] >smp_apic_timer_interrupt+0x85/0x93 >Apr 19 16:12:55 localhost kernel: [] >apic_timer_interrupt+0x6e/0x80 Apr 19 16:12:55 localhost kernel: >[] ? mwait_idle+0x6e/0x8c Apr 19 16:12:55 localhost >kernel: [] ? mwait_idle+0x61/0x8c Apr 19 16:12:55 >localhost kernel: [] cpu_idle+0x67/0xbe Apr 19 16:12:55 >localhost kernel: [] start_secondary+0x194/0x199 Apr 19 >16:12:55 localhost kernel: ---[ end trace e3ca12fc1a8b85da ]--- Apr 19 >16:12:55 localhost kernel: e1000e :08:00.0: eth2: Reset adapter Apr 19 >16:12:57 localhost abrt-dump-oops[898]: abrt-dump-oops: Found oopses: 1 >Apr 19 16:12:57 localhost abrt-dump-oops[898]: abrt-dump-oops: Creating >dump directories Apr 19 16:12:57 localhost abrtd: Directory 'oops-2012-04- >19-16:12:57-898-0' creation detected Apr 19 16:12:57 localhost abrt-dump- >oops: Reported 1 kernel oopses to Abrt Apr 19 16:12:57 localhost abrtd: >Can't open file '/var/spool/abrt/oops-2012-04-19-16:12:57-898-0/uid': No >such file or directory Apr 19 16:12:57 localhost abrtd: DUP_OF_DIR: >/var/spool/abrt/oops-2012-04-19-15:02:13-862-0 >Apr 19 16:12:57 localhost abrtd: Dump directory is a duplicate of >/var/spool/abrt/oops-2012-04-19-15:02:13-862-0 >Apr 19 16:12:57 localhost abrtd: Deleting dump directory oops-2012-04-19- >16:12:57-898-0 (dup of oops-2012-04-19-15:02:13-862-0), sending dbus >signal Apr 19 16:12:58 localhost kernel: e1000e: eth2 NIC Link is Up 1000 >Mbps Full Duplex, Flow Control: Rx/Tx Apr 19 16:12:58 localhost kernel: >ADDRCONF(NETDEV_CHANGE): eth2: link becomes ready Apr 19 16:13:03 >localhost /usr/sbin/irqbalance: Load average increasing, re-enabling all >cpus for irq balancing Apr 19 16:13:04 localhost kernel: e1000e >:08:00.0: eth2: Reset adapter Apr 19 16:13:05 localhost chronyd[1003]: >Selected source 108.59.2.194 Apr 19 16:13:07 localhost kernel: e1000e: >eth2 NIC Link is Up 1000 Mbps Full Duplex, Flow Control: Rx/Tx Apr 19 >16:13:07 localhost kernel: ADDRCONF(NETDEV_CHANGE)
Re: [E1000-devel] e1000e tx queue timeout in 3.3.0 (bisected to BQL support for e1000e)
No, we have seen it in our test. I just checked all our Ilium machines' /var/log/messages back to earlier to month. We got numerous "tg3 transmit timed out" on Ilium GLAG machines only, no e1000e transmit queue timed out. The "tg3 transmit queue timed out" does not seem to be caused by BQL, since I can see it happen even in 420 kernel! Apr 13 18:36:08 lpb77 kernel: [ 51.684212] [ cut here ] Apr 13 18:36:08 lpb77 kernel: [ 51.684223] WARNING: at net/sched/sch_generic.c:263 dev_watchdog+0x1c8/0x1f0() Apr 13 18:36:08 lpb77 kernel: [ 51.684226] Hardware name: Greencreek,ESB2 Apr 13 18:36:08 lpb77 kernel: [ 51.684228] NETDEV WATCHDOG: eth4 (tg3): transmit queue 0 timed out Apr 13 18:36:08 lpb77 kernel: [ 51.684230] Modules linked in: bonding sata_mv i2c_imch pca954x i2c_virtual uhci_hcd msr cpuid i2c_dev i2c_i801 i2c_core i2c_debug tg3 e1000e ipv6 genrtc Apr 13 18:36:08 lpb77 kernel: [ 51.684246] Pid: 0, comm: swapper Not tainted 2.6.34-smp-420.16 #1 Apr 13 18:36:08 lpb77 kernel: [ 51.684248] Call Trace: Apr 13 18:36:08 lpb77 kernel: [ 51.684251][] warn_slowpath_common+0x7c/0xce Apr 13 18:36:08 lpb77 kernel: [ 51.684261] [] warn_slowpath_fmt+0x41/0x43 Apr 13 18:36:08 lpb77 kernel: [ 51.684265] [] dev_watchdog+0x1c8/0x1f0 Apr 13 18:36:08 lpb77 kernel: [ 51.684270] [] ? sched_clock_local+0x1c/0x82 Apr 13 18:36:08 lpb77 kernel: [ 51.684275] [] run_timer_softirq+0x34c/0x360 Apr 13 18:36:08 lpb77 kernel: [ 51.684278] [] ? dev_watchdog+0x0/0x1f0 Apr 13 18:36:08 lpb77 kernel: [ 51.684282] [] __do_softirq+0x39e/0x490 Apr 13 18:36:08 lpb77 kernel: [ 51.684316] [] ? tick_program_event+0x60/0x120 Apr 13 18:36:08 lpb77 kernel: [ 51.684319] [] ? sched_clock_local+0x1c/0x82 Apr 13 18:36:08 lpb77 kernel: [ 51.684323] [] call_softirq+0x1c/0x30 Apr 13 18:36:08 lpb77 kernel: [ 51.684327] [] do_softirq+0x42/0x80 Apr 13 18:36:08 lpb77 kernel: [ 51.684329] [] irq_exit+0x49/0xa0 Apr 13 18:36:08 lpb77 kernel: [ 51.684334] [] smp_apic_timer_interrupt+0x84/0xf4 Apr 13 18:36:08 lpb77 kernel: [ 51.684338] [] apic_timer_interrupt+0x13/0x20 Apr 13 18:36:08 lpb77 kernel: [ 51.684339][] ? mwait_idle+0x7a/0x81 Apr 13 18:36:08 lpb77 kernel: [ 51.684355] [] ? mwait_idle+0x2c/0x81 Apr 13 18:36:08 lpb77 kernel: [ 51.684358] [] cpu_idle+0x92/0x140 Apr 13 18:36:08 lpb77 kernel: [ 51.684363] [] start_secondary+0x1c3/0x1c7 Apr 13 18:36:08 lpb77 kernel: [ 51.684373] ---[ end trace fc8464e86676a1b7 ]--- On Thu, Apr 19, 2012 at 7:39 PM, Tom Herbert wrote: > Thanks, will try to reproduce. > > Tom > > On Thu, Apr 19, 2012 at 4:27 PM, Ben Greear > wrote: > > Test case: > > > > Run full duplex traffic (900Mbps rx, 400Mbps tx) UDP traffic > > (moderate speeds of traffic has issues as well, maybe not as easy to > > reproduce) > > reset peer interface > > > tx queue timeout > > > > > > Apr 19 16:12:48 localhost kernel: e1000e: eth2 NIC Link is Down > > Apr 19 16:12:48 localhost kernel: e1000e :08:00.0: eth2: Reset > adapter > > Apr 19 16:12:48 localhost kernel: e1000e: eth3 NIC Link is Down > > Apr 19 16:12:50 localhost kernel: e1000e: eth2 NIC Link is Up 1000 Mbps > Full > > Duplex, Flow Control: Rx/Tx > > Apr 19 16:12:50 localhost kernel: ADDRCONF(NETDEV_CHANGE): eth2: link > > becomes ready > > Apr 19 16:12:50 localhost kernel: e1000e: eth3 NIC Link is Up 1000 Mbps > Full > > Duplex, Flow Control: Rx/Tx > > Apr 19 16:12:50 localhost kernel: ADDRCONF(NETDEV_CHANGE): eth3: link > > becomes ready > > Apr 19 16:12:54 localhost /usr/sbin/irqbalance: Load average increasing, > > re-enabling all cpus for irq balancing > > Apr 19 16:12:55 localhost kernel: [ cut here ] > > Apr 19 16:12:55 localhost kernel: WARNING: at > > /home/greearb/git/linux-3.3.dev.y/net/sched/sch_generic.c:256 > > dev_watchdog+0xf4/0x154() > > Apr 19 16:12:55 localhost kernel: Hardware name: X7DBU > > Apr 19 16:12:55 localhost kernel: NETDEV WATCHDOG: eth2 (e1000e): > transmit > > queue 0 timed out > > Apr 19 16:12:55 localhost kernel: Modules linked in: xt_CT iptable_raw > 8021q > > garp stp llc veth ppdev parport_pc lp parport fuse macvlan pktgen > iscsi_tcp > > libiscsi_tcp libiscsi scsi_transport_iscsi lockd w83793 w83627hf > hwmon_vid > > coretemp iTCO_wdt microcode iTCO_vendor_support pcspkr i5k_amb ioatdma > > i2c_i801 > > i5000_edac dca edac_core e1000e shpchp uinput sunrpc ipv6 autofs4 floppy > > radeon ttm drm_kms_helper drm hwmon i2c_algo_bit i2c_core [last unloaded: > > nf_nat] > > Apr 19 16:12:55 localhost kernel: Pid: 0, comm: kworker/0:1 Not tainted > > 3.2.0-rc2+ #36 > > Apr 19 16:12:55 localhost kernel: Call Trace: > > Apr 19 16:12:55 localhost kernel: [] > > warn_slowpath_common+0x80/0x98 > > Apr 19 16:12:55 localhost kernel: [] > > warn_slowpath_fmt+0x41/0x43 > > Apr 19 16:12:55 localhost kernel: [] > > dev_watchdog+0xf4/0x154 > > Apr 19 16:12:55 localhost kernel: [] > > run_timer_softirq+0x16f/0x201 > > Apr 19 16:12:55 localhost kerne
Re: [E1000-devel] e1000e tx queue timeout in 3.3.0 (bisected to BQL support for e1000e)
Thanks, will try to reproduce. Tom On Thu, Apr 19, 2012 at 4:27 PM, Ben Greear wrote: > Test case: > > Run full duplex traffic (900Mbps rx, 400Mbps tx) UDP traffic > (moderate speeds of traffic has issues as well, maybe not as easy to > reproduce) > reset peer interface > > tx queue timeout > > > Apr 19 16:12:48 localhost kernel: e1000e: eth2 NIC Link is Down > Apr 19 16:12:48 localhost kernel: e1000e :08:00.0: eth2: Reset adapter > Apr 19 16:12:48 localhost kernel: e1000e: eth3 NIC Link is Down > Apr 19 16:12:50 localhost kernel: e1000e: eth2 NIC Link is Up 1000 Mbps Full > Duplex, Flow Control: Rx/Tx > Apr 19 16:12:50 localhost kernel: ADDRCONF(NETDEV_CHANGE): eth2: link > becomes ready > Apr 19 16:12:50 localhost kernel: e1000e: eth3 NIC Link is Up 1000 Mbps Full > Duplex, Flow Control: Rx/Tx > Apr 19 16:12:50 localhost kernel: ADDRCONF(NETDEV_CHANGE): eth3: link > becomes ready > Apr 19 16:12:54 localhost /usr/sbin/irqbalance: Load average increasing, > re-enabling all cpus for irq balancing > Apr 19 16:12:55 localhost kernel: [ cut here ] > Apr 19 16:12:55 localhost kernel: WARNING: at > /home/greearb/git/linux-3.3.dev.y/net/sched/sch_generic.c:256 > dev_watchdog+0xf4/0x154() > Apr 19 16:12:55 localhost kernel: Hardware name: X7DBU > Apr 19 16:12:55 localhost kernel: NETDEV WATCHDOG: eth2 (e1000e): transmit > queue 0 timed out > Apr 19 16:12:55 localhost kernel: Modules linked in: xt_CT iptable_raw 8021q > garp stp llc veth ppdev parport_pc lp parport fuse macvlan pktgen iscsi_tcp > libiscsi_tcp libiscsi scsi_transport_iscsi lockd w83793 w83627hf hwmon_vid > coretemp iTCO_wdt microcode iTCO_vendor_support pcspkr i5k_amb ioatdma > i2c_i801 > i5000_edac dca edac_core e1000e shpchp uinput sunrpc ipv6 autofs4 floppy > radeon ttm drm_kms_helper drm hwmon i2c_algo_bit i2c_core [last unloaded: > nf_nat] > Apr 19 16:12:55 localhost kernel: Pid: 0, comm: kworker/0:1 Not tainted > 3.2.0-rc2+ #36 > Apr 19 16:12:55 localhost kernel: Call Trace: > Apr 19 16:12:55 localhost kernel: [] > warn_slowpath_common+0x80/0x98 > Apr 19 16:12:55 localhost kernel: [] > warn_slowpath_fmt+0x41/0x43 > Apr 19 16:12:55 localhost kernel: [] > dev_watchdog+0xf4/0x154 > Apr 19 16:12:55 localhost kernel: [] > run_timer_softirq+0x16f/0x201 > Apr 19 16:12:55 localhost kernel: [] ? > netif_tx_unlock+0x57/0x57 > Apr 19 16:12:55 localhost kernel: [] > __do_softirq+0x86/0x12f > Apr 19 16:12:55 localhost kernel: [] ? > hrtimer_interrupt+0x12b/0x1bd > Apr 19 16:12:55 localhost kernel: [] > call_softirq+0x1c/0x30 > Apr 19 16:12:55 localhost kernel: [] do_softirq+0x41/0x7e > Apr 19 16:12:55 localhost kernel: [] irq_exit+0x3f/0xbb > Apr 19 16:12:55 localhost kernel: [] > smp_apic_timer_interrupt+0x85/0x93 > Apr 19 16:12:55 localhost kernel: [] > apic_timer_interrupt+0x6e/0x80 > Apr 19 16:12:55 localhost kernel: [] ? > mwait_idle+0x6e/0x8c > Apr 19 16:12:55 localhost kernel: [] ? > mwait_idle+0x61/0x8c > Apr 19 16:12:55 localhost kernel: [] cpu_idle+0x67/0xbe > Apr 19 16:12:55 localhost kernel: [] > start_secondary+0x194/0x199 > Apr 19 16:12:55 localhost kernel: ---[ end trace e3ca12fc1a8b85da ]--- > Apr 19 16:12:55 localhost kernel: e1000e :08:00.0: eth2: Reset adapter > Apr 19 16:12:57 localhost abrt-dump-oops[898]: abrt-dump-oops: Found oopses: > 1 > Apr 19 16:12:57 localhost abrt-dump-oops[898]: abrt-dump-oops: Creating dump > directories > Apr 19 16:12:57 localhost abrtd: Directory 'oops-2012-04-19-16:12:57-898-0' > creation detected > Apr 19 16:12:57 localhost abrt-dump-oops: Reported 1 kernel oopses to Abrt > Apr 19 16:12:57 localhost abrtd: Can't open file > '/var/spool/abrt/oops-2012-04-19-16:12:57-898-0/uid': No such file or > directory > Apr 19 16:12:57 localhost abrtd: DUP_OF_DIR: > /var/spool/abrt/oops-2012-04-19-15:02:13-862-0 > Apr 19 16:12:57 localhost abrtd: Dump directory is a duplicate of > /var/spool/abrt/oops-2012-04-19-15:02:13-862-0 > Apr 19 16:12:57 localhost abrtd: Deleting dump directory > oops-2012-04-19-16:12:57-898-0 (dup of oops-2012-04-19-15:02:13-862-0), > sending dbus signal > Apr 19 16:12:58 localhost kernel: e1000e: eth2 NIC Link is Up 1000 Mbps Full > Duplex, Flow Control: Rx/Tx > Apr 19 16:12:58 localhost kernel: ADDRCONF(NETDEV_CHANGE): eth2: link > becomes ready > Apr 19 16:13:03 localhost /usr/sbin/irqbalance: Load average increasing, > re-enabling all cpus for irq balancing > Apr 19 16:13:04 localhost kernel: e1000e :08:00.0: eth2: Reset adapter > Apr 19 16:13:05 localhost chronyd[1003]: Selected source 108.59.2.194 > Apr 19 16:13:07 localhost kernel: e1000e: eth2 NIC Link is Up 1000 Mbps Full > Duplex, Flow Control: Rx/Tx > Apr 19 16:13:07 localhost kernel: ADDRCONF(NETDEV_CHANGE): eth2: link > becomes ready > > > lspci: > > 08:00.0 Ethernet controller: Intel Corporation 82571EB Gigabit Ethernet > Controller (rev 06) > Subsystem: Intel Corporation PRO/1000 PT Dual Port Server Adapter > Control: I/O+ Mem+ BusMaster+ SpecCycle- MemWINV- VGASno
Re: [E1000-devel] 82598 does not work well on x64 centos6.2
> The RHEL6.2 stock lldpad daemon has a known bug that would cause DCB to be > enabled by default: > http://lists.open-fcoe.org/pipermail/lldp-devel/2012-March/000614.html > > Are you by any chance running lldpad? If you do not need DCB then you can > shut it down and > reload the driver which should take care of your problem. Yes. Killing lldpad solves this issue. Thanks. I'm wondering whether a DCB switch in driver is needed. Anyway, this is up to you. --Paul > > Thanks, > Emil > >> >> Thanks, >> Paul >> >> --- >> --- >> For Developers, A Lot Can Happen In A Second. >> Boundary is the first to Know...and Tell You. >> Monitor Your Applications in Ultra-Fine Resolution. Try it FREE! >> http://p.sf.net/sfu/Boundary-d2dvs2 >> ___ >> E1000-devel mailing list >> E1000-devel@lists.sourceforge.net >> https://lists.sourceforge.net/lists/listinfo/e1000-devel >> To learn more about Intel® Ethernet, visit >> http://communities.intel.com/community/wired -- For Developers, A Lot Can Happen In A Second. Boundary is the first to Know...and Tell You. Monitor Your Applications in Ultra-Fine Resolution. Try it FREE! http://p.sf.net/sfu/Boundary-d2dvs2 ___ E1000-devel mailing list E1000-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/e1000-devel To learn more about Intel® Ethernet, visit http://communities.intel.com/community/wired
[E1000-devel] Как повысить прозрачность финансов и управления для руководителя
Курс финансового управления для руководителя компании Дата проведения курса: 10 - 11 мая г. Москва Место проведения: м. Бауманская, ул. Бауманская, д.6, БЦ "Виктория Плаза" Информация по условиям обучения: 8 (495) 229 - 56 - 30 постановка финансовых целей, разработки финансовой стратегии; работа с балансом компании, отчетом о прибылях и убытках; управление движением денежных средств; планирование и анализ финансовых результатов; принятие управленческих решений в условиях неопределенности рынка; оценка деятельности компании по основным финансовым документам; анализ эффективности любых видов инвестиций. Программа курса: 1. Генеральная и финансовая стратегия бизнеса – взаимосвязь и различия. Как правильно организовать управление корпоративными финансами. Организационная структура финансово- экономической службы. Структура управленческого учета в компании. Как управлять доходами и расходами компании. Способы увеличения доходности бизнеса. Как правильно распределять чистую прибыль компании. Почему стоимость бизнеса это самый важный финансовый показатель. Процесс разработки стратегии компании и типовые стратегические позиции на конкурентном рынке. Уровни формирования стратегии бизнеса. Признаки эффективной стратегии. 2. Управление финансами компании и управленческий учет. Управление бизнесом и финансами по ключевым показателям (KPI и CFI). "Жизненная сила" компании – ликвидность, рентабельность, платежеспособность. Какие задачи и как должен решать управленческий учет. Структура управленческого учета. Полный регламент управленческой отчетности для бизнес- единицы. 2 версии управленческого учета: финансовый и директорский. Взаимосвязь, взаимодействие и отличия бухгалтерского и управленческого учета. 3. Управление денежными потоками, доходами, расходами, имуществом и обязательствами компании. Структура, построение и анализ Отчета о Движении Денежных Средств. Структура, построение и анализ Отчета о Доходах и Расходах. Построение и анализ управленческого баланса. Взаимосвязь управленческого баланса и управления стоимостью бизнеса. Основные источники финансирования бизнеса и их особенности. Финансовый анализ с точки зрения собственника. Рентабельность собственного капитала. Анализ ликвидности, платежеспособности, рентабельности и финансовой устойчивости компании. Анализ и расчет стоимости бизнеса. 4. Бюджетирование - эффективная методика финансового управления и планирования. Связь бюджетирования с финансовой стратегией компании. Построение бизнес - модели бюджетирования в форматах "как есть" и "как будет". Анализ и контроль исполнения бюджетов. Казначейский контроль и таргетирование. Сложности при внедрении системы бюджетного управления. Типовые серьезные ошибки при реализации бюджетирования. 5. Контроль бизнеса и управление рисками. Как разработать эффективную систему внутреннего контроля в бизнесе. Технология эффективного риск - менеджмента. Определение факторов (причин) риска и возможных последствий. Классификация рисков в бизнесе. Методы снижения рисков и обеспечения безопасности бизнеса. Мониторинг и контроль рисков. 6. Успешное управление бизнесом: сопряжение стратегии, финансов, маркетинга и человеческого фактора. Эффективное взаимодействие финансовых топ - менеджеров и владельцев бизнеса. Что такое сбалансированная система показателей (BSC). Сценарный стратегический и инвестиционный анализ как диагностика долгосрочных финансовых результатов. Анализа качества работы топ - менеджмента и среднего управленческого звена. Стоимость участия: 18600 рублей. В стоимость входит методический материал, обеды, кофе-паузы, сертификат. -- For Developers, A Lot Can Happen In A Second. Boundary is the first to Know...and Tell You. Monitor Your Applications in Ultra-Fine Resolution. Try it FREE! http://p.sf.net/sfu/Boundary-d2dvs2___ E1000-devel mailing list E1000-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/e1000-devel To learn more about Intel® Ethernet, visit http://communities.intel.com/community/wired
[E1000-devel] e1000e tx queue timeout in 3.3.0 (bisected to BQL support for e1000e)
Test case: Run full duplex traffic (900Mbps rx, 400Mbps tx) UDP traffic (moderate speeds of traffic has issues as well, maybe not as easy to reproduce) reset peer interface > tx queue timeout Apr 19 16:12:48 localhost kernel: e1000e: eth2 NIC Link is Down Apr 19 16:12:48 localhost kernel: e1000e :08:00.0: eth2: Reset adapter Apr 19 16:12:48 localhost kernel: e1000e: eth3 NIC Link is Down Apr 19 16:12:50 localhost kernel: e1000e: eth2 NIC Link is Up 1000 Mbps Full Duplex, Flow Control: Rx/Tx Apr 19 16:12:50 localhost kernel: ADDRCONF(NETDEV_CHANGE): eth2: link becomes ready Apr 19 16:12:50 localhost kernel: e1000e: eth3 NIC Link is Up 1000 Mbps Full Duplex, Flow Control: Rx/Tx Apr 19 16:12:50 localhost kernel: ADDRCONF(NETDEV_CHANGE): eth3: link becomes ready Apr 19 16:12:54 localhost /usr/sbin/irqbalance: Load average increasing, re-enabling all cpus for irq balancing Apr 19 16:12:55 localhost kernel: [ cut here ] Apr 19 16:12:55 localhost kernel: WARNING: at /home/greearb/git/linux-3.3.dev.y/net/sched/sch_generic.c:256 dev_watchdog+0xf4/0x154() Apr 19 16:12:55 localhost kernel: Hardware name: X7DBU Apr 19 16:12:55 localhost kernel: NETDEV WATCHDOG: eth2 (e1000e): transmit queue 0 timed out Apr 19 16:12:55 localhost kernel: Modules linked in: xt_CT iptable_raw 8021q garp stp llc veth ppdev parport_pc lp parport fuse macvlan pktgen iscsi_tcp libiscsi_tcp libiscsi scsi_transport_iscsi lockd w83793 w83627hf hwmon_vid coretemp iTCO_wdt microcode iTCO_vendor_support pcspkr i5k_amb ioatdma i2c_i801 i5000_edac dca edac_core e1000e shpchp uinput sunrpc ipv6 autofs4 floppy radeon ttm drm_kms_helper drm hwmon i2c_algo_bit i2c_core [last unloaded: nf_nat] Apr 19 16:12:55 localhost kernel: Pid: 0, comm: kworker/0:1 Not tainted 3.2.0-rc2+ #36 Apr 19 16:12:55 localhost kernel: Call Trace: Apr 19 16:12:55 localhost kernel: [] warn_slowpath_common+0x80/0x98 Apr 19 16:12:55 localhost kernel: [] warn_slowpath_fmt+0x41/0x43 Apr 19 16:12:55 localhost kernel: [] dev_watchdog+0xf4/0x154 Apr 19 16:12:55 localhost kernel: [] run_timer_softirq+0x16f/0x201 Apr 19 16:12:55 localhost kernel: [] ? netif_tx_unlock+0x57/0x57 Apr 19 16:12:55 localhost kernel: [] __do_softirq+0x86/0x12f Apr 19 16:12:55 localhost kernel: [] ? hrtimer_interrupt+0x12b/0x1bd Apr 19 16:12:55 localhost kernel: [] call_softirq+0x1c/0x30 Apr 19 16:12:55 localhost kernel: [] do_softirq+0x41/0x7e Apr 19 16:12:55 localhost kernel: [] irq_exit+0x3f/0xbb Apr 19 16:12:55 localhost kernel: [] smp_apic_timer_interrupt+0x85/0x93 Apr 19 16:12:55 localhost kernel: [] apic_timer_interrupt+0x6e/0x80 Apr 19 16:12:55 localhost kernel: [] ? mwait_idle+0x6e/0x8c Apr 19 16:12:55 localhost kernel: [] ? mwait_idle+0x61/0x8c Apr 19 16:12:55 localhost kernel: [] cpu_idle+0x67/0xbe Apr 19 16:12:55 localhost kernel: [] start_secondary+0x194/0x199 Apr 19 16:12:55 localhost kernel: ---[ end trace e3ca12fc1a8b85da ]--- Apr 19 16:12:55 localhost kernel: e1000e :08:00.0: eth2: Reset adapter Apr 19 16:12:57 localhost abrt-dump-oops[898]: abrt-dump-oops: Found oopses: 1 Apr 19 16:12:57 localhost abrt-dump-oops[898]: abrt-dump-oops: Creating dump directories Apr 19 16:12:57 localhost abrtd: Directory 'oops-2012-04-19-16:12:57-898-0' creation detected Apr 19 16:12:57 localhost abrt-dump-oops: Reported 1 kernel oopses to Abrt Apr 19 16:12:57 localhost abrtd: Can't open file '/var/spool/abrt/oops-2012-04-19-16:12:57-898-0/uid': No such file or directory Apr 19 16:12:57 localhost abrtd: DUP_OF_DIR: /var/spool/abrt/oops-2012-04-19-15:02:13-862-0 Apr 19 16:12:57 localhost abrtd: Dump directory is a duplicate of /var/spool/abrt/oops-2012-04-19-15:02:13-862-0 Apr 19 16:12:57 localhost abrtd: Deleting dump directory oops-2012-04-19-16:12:57-898-0 (dup of oops-2012-04-19-15:02:13-862-0), sending dbus signal Apr 19 16:12:58 localhost kernel: e1000e: eth2 NIC Link is Up 1000 Mbps Full Duplex, Flow Control: Rx/Tx Apr 19 16:12:58 localhost kernel: ADDRCONF(NETDEV_CHANGE): eth2: link becomes ready Apr 19 16:13:03 localhost /usr/sbin/irqbalance: Load average increasing, re-enabling all cpus for irq balancing Apr 19 16:13:04 localhost kernel: e1000e :08:00.0: eth2: Reset adapter Apr 19 16:13:05 localhost chronyd[1003]: Selected source 108.59.2.194 Apr 19 16:13:07 localhost kernel: e1000e: eth2 NIC Link is Up 1000 Mbps Full Duplex, Flow Control: Rx/Tx Apr 19 16:13:07 localhost kernel: ADDRCONF(NETDEV_CHANGE): eth2: link becomes ready lspci: 08:00.0 Ethernet controller: Intel Corporation 82571EB Gigabit Ethernet Controller (rev 06) Subsystem: Intel Corporation PRO/1000 PT Dual Port Server Adapter Control: I/O+ Mem+ BusMaster+ SpecCycle- MemWINV- VGASnoop- ParErr+ Stepping- SERR+ FastB2B- DisINTx+ Status: Cap+ 66MHz- UDF- FastB2B- ParErr- DEVSEL=fast >TAbort- SERR- Date: Mon Nov 28 16:33:16 2011 + e1000e: Support for byte queue limits Changes to e1000e to use byte queue limits.
Re: [E1000-devel] e1000e transmit queue hang in 3.3.2+
On 04/19/2012 04:03 PM, Dave, Tushar N wrote: > When you say "transmit hung", are you getting Tx hang message in dmesg. Or TX > timeout from netdev? From var/log/messages: [reset peer interface] Apr 19 16:12:48 localhost kernel: e1000e: eth2 NIC Link is Down Apr 19 16:12:48 localhost kernel: e1000e :08:00.0: eth2: Reset adapter Apr 19 16:12:48 localhost kernel: e1000e: eth3 NIC Link is Down Apr 19 16:12:50 localhost kernel: e1000e: eth2 NIC Link is Up 1000 Mbps Full Duplex, Flow Control: Rx/Tx Apr 19 16:12:50 localhost kernel: ADDRCONF(NETDEV_CHANGE): eth2: link becomes ready Apr 19 16:12:50 localhost kernel: e1000e: eth3 NIC Link is Up 1000 Mbps Full Duplex, Flow Control: Rx/Tx Apr 19 16:12:50 localhost kernel: ADDRCONF(NETDEV_CHANGE): eth3: link becomes ready Apr 19 16:12:54 localhost /usr/sbin/irqbalance: Load average increasing, re-enabling all cpus for irq balancing Apr 19 16:12:55 localhost kernel: [ cut here ] Apr 19 16:12:55 localhost kernel: WARNING: at /home/greearb/git/linux-3.3.dev.y/net/sched/sch_generic.c:256 dev_watchdog+0xf4/0x154() Apr 19 16:12:55 localhost kernel: Hardware name: X7DBU Apr 19 16:12:55 localhost kernel: NETDEV WATCHDOG: eth2 (e1000e): transmit queue 0 timed out Apr 19 16:12:55 localhost kernel: Modules linked in: xt_CT iptable_raw 8021q garp stp llc veth ppdev parport_pc lp parport fuse macvlan pktgen iscsi_tcp libiscsi_tcp libiscsi scsi_transport_iscsi lockd w83793 w83627hf hwmon_vid coretemp iTCO_wdt microcode iTCO_vendor_support pcspkr i5k_amb ioatdma i2c_i801 i5000_edac dca edac_core e1000e shpchp uinput sunrpc ipv6 autofs4 floppy radeon ttm drm_kms_helper drm hwmon i2c_algo_bit i2c_core [last unloaded: nf_nat] Apr 19 16:12:55 localhost kernel: Pid: 0, comm: kworker/0:1 Not tainted 3.2.0-rc2+ #36 Apr 19 16:12:55 localhost kernel: Call Trace: Apr 19 16:12:55 localhost kernel: [] warn_slowpath_common+0x80/0x98 Apr 19 16:12:55 localhost kernel: [] warn_slowpath_fmt+0x41/0x43 Apr 19 16:12:55 localhost kernel: [] dev_watchdog+0xf4/0x154 Apr 19 16:12:55 localhost kernel: [] run_timer_softirq+0x16f/0x201 Apr 19 16:12:55 localhost kernel: [] ? netif_tx_unlock+0x57/0x57 Apr 19 16:12:55 localhost kernel: [] __do_softirq+0x86/0x12f Apr 19 16:12:55 localhost kernel: [] ? hrtimer_interrupt+0x12b/0x1bd Apr 19 16:12:55 localhost kernel: [] call_softirq+0x1c/0x30 Apr 19 16:12:55 localhost kernel: [] do_softirq+0x41/0x7e Apr 19 16:12:55 localhost kernel: [] irq_exit+0x3f/0xbb Apr 19 16:12:55 localhost kernel: [] smp_apic_timer_interrupt+0x85/0x93 Apr 19 16:12:55 localhost kernel: [] apic_timer_interrupt+0x6e/0x80 Apr 19 16:12:55 localhost kernel: [] ? mwait_idle+0x6e/0x8c Apr 19 16:12:55 localhost kernel: [] ? mwait_idle+0x61/0x8c Apr 19 16:12:55 localhost kernel: [] cpu_idle+0x67/0xbe Apr 19 16:12:55 localhost kernel: [] start_secondary+0x194/0x199 Apr 19 16:12:55 localhost kernel: ---[ end trace e3ca12fc1a8b85da ]--- Apr 19 16:12:55 localhost kernel: e1000e :08:00.0: eth2: Reset adapter Apr 19 16:12:57 localhost abrt-dump-oops[898]: abrt-dump-oops: Found oopses: 1 Apr 19 16:12:57 localhost abrt-dump-oops[898]: abrt-dump-oops: Creating dump directories Apr 19 16:12:57 localhost abrtd: Directory 'oops-2012-04-19-16:12:57-898-0' creation detected Apr 19 16:12:57 localhost abrt-dump-oops: Reported 1 kernel oopses to Abrt Apr 19 16:12:57 localhost abrtd: Can't open file '/var/spool/abrt/oops-2012-04-19-16:12:57-898-0/uid': No such file or directory Apr 19 16:12:57 localhost abrtd: DUP_OF_DIR: /var/spool/abrt/oops-2012-04-19-15:02:13-862-0 Apr 19 16:12:57 localhost abrtd: Dump directory is a duplicate of /var/spool/abrt/oops-2012-04-19-15:02:13-862-0 Apr 19 16:12:57 localhost abrtd: Deleting dump directory oops-2012-04-19-16:12:57-898-0 (dup of oops-2012-04-19-15:02:13-862-0), sending dbus signal Apr 19 16:12:58 localhost kernel: e1000e: eth2 NIC Link is Up 1000 Mbps Full Duplex, Flow Control: Rx/Tx Apr 19 16:12:58 localhost kernel: ADDRCONF(NETDEV_CHANGE): eth2: link becomes ready Apr 19 16:13:03 localhost /usr/sbin/irqbalance: Load average increasing, re-enabling all cpus for irq balancing Apr 19 16:13:04 localhost kernel: e1000e :08:00.0: eth2: Reset adapter Apr 19 16:13:05 localhost chronyd[1003]: Selected source 108.59.2.194 Apr 19 16:13:07 localhost kernel: e1000e: eth2 NIC Link is Up 1000 Mbps Full Duplex, Flow Control: Rx/Tx Apr 19 16:13:07 localhost kernel: ADDRCONF(NETDEV_CHANGE): eth2: link becomes ready Thanks, Ben > > -Tushar > >> -Original Message- >> From: Ben Greear [mailto:gree...@candelatech.com] >> Sent: Thursday, April 19, 2012 3:34 PM >> To: Dave, Tushar N >> Cc: e1000-devel list >> Subject: Re: [E1000-devel] e1000e transmit queue hang in 3.3.2+ >> >> On 04/19/2012 11:59 AM, Dave, Tushar N wrote: >>> This is strange. There is no pending packets in ring. Looks like DMA >> controller is not hung. >>> There is something else then. Let me poke little bit into code. >> >> Bisect i
Re: [E1000-devel] e1000e transmit queue hang in 3.3.2+
When you say "transmit hung", are you getting Tx hang message in dmesg. Or TX timeout from netdev? -Tushar >-Original Message- >From: Ben Greear [mailto:gree...@candelatech.com] >Sent: Thursday, April 19, 2012 3:34 PM >To: Dave, Tushar N >Cc: e1000-devel list >Subject: Re: [E1000-devel] e1000e transmit queue hang in 3.3.2+ > >On 04/19/2012 11:59 AM, Dave, Tushar N wrote: >> This is strange. There is no pending packets in ring. Looks like DMA >controller is not hung. >> There is something else then. Let me poke little bit into code. > >Bisect is zeroing in on the e1000e bql patch, but I still have a few more >bisects left. > >Test case: > >run traffic (I'm doing around 900Mbps rx, 400Mbps tx, of UDP pkts, bi- >directional) > I've seen problems on very lightly loaded interface as well, so not >sure traffic > matters so much. >reset peer interface >*boom* > >Bug seems easy to trigger in this scenario. If someone else has an e1000e >NIC and tries this out, I'm curious to know if they can reproduce the >problem... > >Thanks, >Ben > >-- >Ben Greear >Candela Technologies Inc http://www.candelatech.com -- For Developers, A Lot Can Happen In A Second. Boundary is the first to Know...and Tell You. Monitor Your Applications in Ultra-Fine Resolution. Try it FREE! http://p.sf.net/sfu/Boundary-d2dvs2 ___ E1000-devel mailing list E1000-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/e1000-devel To learn more about Intel® Ethernet, visit http://communities.intel.com/community/wired
Re: [E1000-devel] e1000e transmit queue hang in 3.3.2+
On 04/19/2012 11:59 AM, Dave, Tushar N wrote: > This is strange. There is no pending packets in ring. Looks like DMA > controller is not hung. > There is something else then. Let me poke little bit into code. Bisect is zeroing in on the e1000e bql patch, but I still have a few more bisects left. Test case: run traffic (I'm doing around 900Mbps rx, 400Mbps tx, of UDP pkts, bi-directional) I've seen problems on very lightly loaded interface as well, so not sure traffic matters so much. reset peer interface *boom* Bug seems easy to trigger in this scenario. If someone else has an e1000e NIC and tries this out, I'm curious to know if they can reproduce the problem... Thanks, Ben -- Ben Greear Candela Technologies Inc http://www.candelatech.com -- For Developers, A Lot Can Happen In A Second. Boundary is the first to Know...and Tell You. Monitor Your Applications in Ultra-Fine Resolution. Try it FREE! http://p.sf.net/sfu/Boundary-d2dvs2 ___ E1000-devel mailing list E1000-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/e1000-devel To learn more about Intel® Ethernet, visit http://communities.intel.com/community/wired
Re: [E1000-devel] e1000e transmit queue hang in 3.3.2+
On 04/19/2012 11:59 AM, Dave, Tushar N wrote: > This is strange. There is no pending packets in ring. Looks like DMA > controller is not hung. > There is something else then. Let me poke little bit into code. Ok. It seems that 3.2.0 works OK. And 3.3.2 is definitely not. /me goes back to bisecting. Ben -- Ben Greear Candela Technologies Inc http://www.candelatech.com -- For Developers, A Lot Can Happen In A Second. Boundary is the first to Know...and Tell You. Monitor Your Applications in Ultra-Fine Resolution. Try it FREE! http://p.sf.net/sfu/Boundary-d2dvs2 ___ E1000-devel mailing list E1000-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/e1000-devel To learn more about Intel® Ethernet, visit http://communities.intel.com/community/wired
Re: [E1000-devel] 82598 does not work well on x64 centos6.2
>-Original Message- >From: Paul Guo [mailto:gg...@tilera.com] >Sent: Thursday, April 12, 2012 9:29 PM >To: e1000-devel@lists.sourceforge.net >Subject: [E1000-devel] 82598 does not work well on x64 centos6.2 > >Hi, > >I installed an 82598 10Gb PCIE NIC in an x64 server with a freshly >installed centos 6.2 running. I compiled ixgbe-3.8.21 and installed the >module in kernel since the original ixgbe driver in centos 6.2 does not >work well with the NIC + my transceiver (it keeps chip resetting after >bringing up due to tx hang). > >However during real using of this I encountered two issues both of which >seem to be related to DCB (according to related code). First of all apologies for taking so long to reply - it was not for a lack of attention. I've been looking at this for while now but kept getting sidetracked. > >1) It adds vlan tag (vlan id 0 - means the frame does not belong to any > vlan) for initial arp packet so after the interface's bringing up > ** it can not ping another side ** on which Linux without 8021q module > loaded is running. Following are the packet dumping results: > > ixgbe tx frame: > ff ff ff ff ff ff 00 1b 21 63 d0 95 08 06 00 01 > > rx packet dump in another side: > ff ff ff ff ff ff 00 1b 21 63 d0 95 81 00 00 00 > 08 06 00 01 > > I need to modprobe 8021q in another system to make ping ok. Adding vlan 0 on Tx is a sure sign that DCB is enabled. > >2) Although /var/log/message says "16 tx queues and 16 rx queues" however > during real testing I found there is rx traffic on rx queue 0 only > (observe via ethtool -S) during multi-threaded tcp testing. > >All these are out-of-box behaviors and seems to be reasonable for DCB but >do not seems to be proper as default settings. I workaround this by simply >disabling the DCB capablity for 82598 in ixgbe_sw_init() so I can use it >for network throughput testing. Is my hacking harmful for my case (tcp >iperf/netperf testing)? And why DCB is enabled by default? The RHEL6.2 stock lldpad daemon has a known bug that would cause DCB to be enabled by default: http://lists.open-fcoe.org/pipermail/lldp-devel/2012-March/000614.html Are you by any chance running lldpad? If you do not need DCB then you can shut it down and reload the driver which should take care of your problem. Thanks, Emil > >Thanks, >Paul > >--- >--- >For Developers, A Lot Can Happen In A Second. >Boundary is the first to Know...and Tell You. >Monitor Your Applications in Ultra-Fine Resolution. Try it FREE! >http://p.sf.net/sfu/Boundary-d2dvs2 >___ >E1000-devel mailing list >E1000-devel@lists.sourceforge.net >https://lists.sourceforge.net/lists/listinfo/e1000-devel >To learn more about Intel® Ethernet, visit >http://communities.intel.com/community/wired -- For Developers, A Lot Can Happen In A Second. Boundary is the first to Know...and Tell You. Monitor Your Applications in Ultra-Fine Resolution. Try it FREE! http://p.sf.net/sfu/Boundary-d2dvs2 ___ E1000-devel mailing list E1000-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/e1000-devel To learn more about Intel® Ethernet, visit http://communities.intel.com/community/wired
Re: [E1000-devel] e1000e transmit queue hang in 3.3.2+
On 04/19/2012 10:46 AM, Dave, Tushar N wrote: > Ben, > > Would you please set current message level via ethtool to hw + tx_done + > rx_status; then driver will log tx desc and rx desc data into dmesg when hang > occurs. That will show us what's going on. > Please send me the dmesg log after the tx hang. Here's some output from the 3.2.2 kernel. This NIC was already stuck before I enabled the ethtool debugging. e1000e :08:00.1: eth3: Reset adapter e1000e: eth3 NIC Link is Up 1000 Mbps Full Duplex, Flow Control: Rx/Tx ADDRCONF(NETDEV_CHANGE): eth3: link becomes ready e1000e :08:00.1: eth3: Reset adapter e1000e: eth3 NIC Link is Up 1000 Mbps Full Duplex, Flow Control: Rx/Tx ADDRCONF(NETDEV_CHANGE): eth3: link becomes ready e1000e :08:00.1: eth3: Reset adapter e1000e: eth3 NIC Link is Up 1000 Mbps Full Duplex, Flow Control: Rx/Tx ADDRCONF(NETDEV_CHANGE): eth3: link becomes ready e1000e :08:00.1: eth3: Reset adapter e1000e: eth3 NIC Link is Up 1000 Mbps Full Duplex, Flow Control: Rx/Tx e1000e :08:00.1: Net device Info e1000e: Device Name statetrans_start last_rx e1000e: eth30003 0001000F951E e1000e :08:00.1: Register Dump e1000e: Register Name Value e1000e: CTRL581c0241 e1000e: STATUS 00080387 e1000e: CTRL_EXT181400c0 e1000e: ICR e1000e: RCTL04008002 e1000e: RDLEN 1000 e1000e: RDH e1000e: RDT 00f0 e1000e: RDTR0020 e1000e: RXDCTL[0-1] 01040420 01040420 e1000e: ERT e1000e: RDBAL 0aef2000 e1000e: RDBAH 0001 e1000e: RDFH e1000e: RDFT e1000e: RDFHS e1000e: RDFTS e1000e: RDFPC e1000e: TCTL3103f0fa e1000e: TDBAL 0ed61000 e1000e: TDBAH 0001 e1000e: TDLEN 1000 e1000e: TDH e1000e: TDT e1000e: TIDV0008 e1000e: TXDCTL[0-1] 0145011f 0145011f e1000e: TADV0020 e1000e: TARC[0-1] 07a00403 07400403 e1000e: TDFH1300 e1000e: TDFT1300 e1000e: TDFHS 1300 e1000e: TDFTS 1300 e1000e: TDFPC e1000e :08:00.1: Tx Ring Summary e1000e: Queue [NTU] [NTC] [bi(ntc)->dma ] leng ntw timestamp e1000e: 0 0 0 0 e1000e :08:00.1: Tx Ring Dump e1000e: Tl[desc] [address 63:0 ] [SpeCssSCmCsLen] [bi->dma ] leng ntw timestampbi->skb <-- Legacy format e1000e: Tc[desc] [Ce CoCsIpceCoS] [MssHlRSCm0Plen] [bi->dma ] leng ntw timestampbi->skb <-- Ext Context format e1000e: Td[desc] [address 63:0 ] [VlaPoRSCm1Dlen] [bi->dma ] leng ntw timestampbi->skb <-- Ext Data format e1000e: Tl[0x000] 0 (null) NTC/U e1000e: Tl[0x001] 0 (null) e1000e: Tl[0x002] 0 (null) e1000e: Tl[0x003] 0 (null) e1000e: Tl[0x004] 0 (null) e1000e: Tl[0x005] 0 (null) e1000e: Tl[0x006] 0 (null) e1000e: Tl[0x007] 0 (null) e1000e: Tl[0x008] 0 (null) e1000e: Tl[0x009] 0 (null) e1000e: Tl[0x00A] 0 (null) e1000e: Tl[0x00B] 0 (null) e1000e: Tl[0x00C] 0 (null) e1000e: Tl[0x00D] 0 (null) e1000e: Tl[0x00E] 0 (null) e1000e: Tl[0x00F] 0 (null) e1000e: Tl[0x010] 0 (null) e1000e: Tl[0x011] 0
Re: [E1000-devel] [PATCH] e1000e: MSI interrupt test failed, using legacy interrupt
On 04/19/2012 11:09 AM, Jesse Brandeburg wrote: > On Thu, 19 Apr 2012 10:59:47 -0700 > Prasanna Panchamukhi wrote: > >> On 04/19/2012 08:54 AM, Allan, Bruce W wrote: >>> We have not seen a report of this issue before. Please provide details on >>> the NIC or LOM and system/chipset on which the problem occurs and how the >>> additional 50ms was determined. >> This has been seen mostly with Intel 82571 Dual port Gigabit Ethernet >> MAC+PHY of Intel Controller. Add-on NICs. Even 80ms works >> but to be safer I increased to 100ms. This issue has been seen when >> multiple PCI-E add-on NICs with dual ports are inserted. > in what system? The reason we are asking is that often just increasing > a delay like this will not solve all bugs in this path, without a root > cause it is difficult to justify the patch. This issue has been seen on AMD x86_64 systems. Thanks, Prasanna -- For Developers, A Lot Can Happen In A Second. Boundary is the first to Know...and Tell You. Monitor Your Applications in Ultra-Fine Resolution. Try it FREE! http://p.sf.net/sfu/Boundary-d2dvs2 ___ E1000-devel mailing list E1000-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/e1000-devel To learn more about Intel® Ethernet, visit http://communities.intel.com/community/wired
Re: [E1000-devel] [PATCH] e1000e: MSI interrupt test failed, using legacy interrupt
On Thu, 19 Apr 2012 10:59:47 -0700 Prasanna Panchamukhi wrote: > On 04/19/2012 08:54 AM, Allan, Bruce W wrote: > > We have not seen a report of this issue before. Please provide details on > > the NIC or LOM and system/chipset on which the problem occurs and how the > > additional 50ms was determined. > > This has been seen mostly with Intel 82571 Dual port Gigabit Ethernet > MAC+PHY of Intel Controller. Add-on NICs. Even 80ms works > but to be safer I increased to 100ms. This issue has been seen when > multiple PCI-E add-on NICs with dual ports are inserted. in what system? The reason we are asking is that often just increasing a delay like this will not solve all bugs in this path, without a root cause it is difficult to justify the patch. -- For Developers, A Lot Can Happen In A Second. Boundary is the first to Know...and Tell You. Monitor Your Applications in Ultra-Fine Resolution. Try it FREE! http://p.sf.net/sfu/Boundary-d2dvs2 ___ E1000-devel mailing list E1000-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/e1000-devel To learn more about Intel® Ethernet, visit http://communities.intel.com/community/wired
Re: [E1000-devel] [PATCH] e1000e: MSI interrupt test failed, using legacy interrupt
On 04/19/2012 08:54 AM, Allan, Bruce W wrote: > We have not seen a report of this issue before. Please provide details on > the NIC or LOM and system/chipset on which the problem occurs and how the > additional 50ms was determined. This has been seen mostly with Intel 82571 Dual port Gigabit Ethernet MAC+PHY of Intel Controller. Add-on NICs. Even 80ms works but to be safer I increased to 100ms. This issue has been seen when multiple PCI-E add-on NICs with dual ports are inserted. Thanks, Prasanna >> -Original Message- >> From: prasanna.panchamu...@riverbed.com >> [mailto:prasanna.panchamu...@riverbed.com] >> Sent: Wednesday, April 18, 2012 5:18 PM >> To: Allan, Bruce W; Kirsher, Jeffrey T; Brandeburg, Jesse; Pieper, >> Jeffrey E >> Cc: e1000-devel@lists.sourceforge.net; >> prasanna.panchamu...@riverbed.com >> Subject: [PATCH] e1000e: MSI interrupt test failed, using legacy >> interrupt >> >> From: Prasanna S. Panchamukhi >> >> Following logs where seen on Systems with multiple NICs, >> while using MSI interrupts as shown below: >> >> Feb 16 15:09:32 (none) user.notice kernel: :00:0d.0: lan0_0: NIC >> Link is Up >> 1000 Mbps Full Duplex, Flow Control: RX/TX >> Feb 16 15:09:32 (none) user.notice kernel: :40:0d.0: wan0_1: NIC >> Link is Up >> 1000 Mbps Full Duplex, Flow Control: RX/TX >> Feb 16 15:09:32 (none) user.notice kernel: :40:0d.0: lan0_1: NIC >> Link is Up >> 1000 Mbps Full Duplex, Flow Control: RX/TX >> Feb 16 15:09:32 (none) user.warn kernel: :40:0e.0: wan4_0: MSI >> interrupt >> test failed, using legacy interrupt. >> ^ >> Feb 16 15:09:32 (none) user.notice kernel: :00:0e.0: wan1_0: NIC >> Link is Up >> 1000 Mbps Full Duplex, Flow Control: RX/TX >> Feb 16 15:09:33 (none) user.notice kernel: :00:0e.0: lan1_0: NIC >> Link is Up >> 1000 Mbps Full Duplex, Flow Control: RX/TX >> Feb 16 15:09:33 (none) user.notice kernel: :00:0f.0: wan2_0: NIC >> Link is Up >> 1000 Mbps Full Duplex, Flow Control: RX/TX >> Feb 16 15:09:33 (none) user.notice kernel: :00:0f.0: lan2_0: NIC >> Link is Up >> 1000 Mbps Full Duplex, Flow Control: RX/TX >> Feb 16 15:09:33 (none) user.notice kernel: :40:0a.0: wan3_0: NIC >> Link is Up >> 1000 Mbps Full Duplex, Flow Control: RX/TX >> Feb 16 15:09:33 (none) user.notice kernel: :40:0a.0: lan3_0: NIC >> Link is Up >> 1000 Mbps Full Duplex, Flow Control: RX/TX >> Feb 16 15:09:34 (none) user.notice kernel: :40:0e.0: lan4_0: NIC >> Link is Up >> 1000 Mbps Full Duplex, Flow Control: RX/TX >> Feb 16 15:09:34 (none) user.notice kernel: :40:0f.0: wan5_0: NIC >> Link is Up >> 1000 Mbps Full Duplex, Flow Control: RX/TX >> Feb 16 15:09:34 (none) user.notice kernel: :40:0f.0: lan5_0: NIC >> Link is Up >> 1000 Mbps Full Duplex, Flow Control: RX/TX >> >> This patch fixes this problem by increasing the msleep from 50 to 100. >> >> Signed-off-by: Prasanna S. Panchamukhi >> --- >> drivers/net/ethernet/intel/e1000e/netdev.c |2 +- >> 1 files changed, 1 insertions(+), 1 deletions(-) >> >> diff --git a/drivers/net/ethernet/intel/e1000e/netdev.c >> b/drivers/net/ethernet/intel/e1000e/netdev.c >> index 19ab215..9520a6a 100644 >> --- a/drivers/net/ethernet/intel/e1000e/netdev.c >> +++ b/drivers/net/ethernet/intel/e1000e/netdev.c >> @@ -3799,7 +3799,7 @@ static int e1000_test_msi_interrupt(struct >> e1000_adapter *adapter) >> /* fire an unusual interrupt on the test handler */ >> ew32(ICS, E1000_ICS_RXSEQ); >> e1e_flush(); >> -msleep(50); >> +msleep(100); >> >> e1000_irq_disable(adapter); >> >> -- >> 1.7.0.4 -- For Developers, A Lot Can Happen In A Second. Boundary is the first to Know...and Tell You. Monitor Your Applications in Ultra-Fine Resolution. Try it FREE! http://p.sf.net/sfu/Boundary-d2dvs2 ___ E1000-devel mailing list E1000-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/e1000-devel To learn more about Intel® Ethernet, visit http://communities.intel.com/community/wired
Re: [E1000-devel] e1000e transmit queue hang in 3.3.2+
On 04/19/2012 10:53 AM, Ben Greear wrote: > On 04/19/2012 10:45 AM, Jesse Brandeburg wrote: >> On Thu, 19 Apr 2012 10:10:08 -0700 >> Ben Greear wrote: >> >>> On 04/18/2012 03:12 PM, Ben Greear wrote: This kernel has my rx-fcs, rx-all, tx-crc patches applied, but the features are disabled. >>> >>> I can reproduce this without pktgen (happened on >>> a port that is running no traffic at all..maybe just >>> some IPv6 auto-discovery pkts or an arp or two). >>> >>> I cannot reproduce it when using the out-of-tree e1000e >>> driver (e1000e-1.10.6). >>> >>> I'll start bisecting >> >> Ben, thanks for taking the time to report this and bisect for us. We >> are paying attention and want to get any issues fixed. > > I appreciate that. I just reproduced it on 3.2.2 (vanilla), so Err, that is 3.3.2 vanilla. Ben -- Ben Greear Candela Technologies Inc http://www.candelatech.com -- For Developers, A Lot Can Happen In A Second. Boundary is the first to Know...and Tell You. Monitor Your Applications in Ultra-Fine Resolution. Try it FREE! http://p.sf.net/sfu/Boundary-d2dvs2 ___ E1000-devel mailing list E1000-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/e1000-devel To learn more about Intel® Ethernet, visit http://communities.intel.com/community/wired
Re: [E1000-devel] e1000e transmit queue hang in 3.3.2+
On 04/19/2012 10:45 AM, Jesse Brandeburg wrote: > On Thu, 19 Apr 2012 10:10:08 -0700 > Ben Greear wrote: > >> On 04/18/2012 03:12 PM, Ben Greear wrote: >>> This kernel has my rx-fcs, rx-all, tx-crc patches applied, >>> but the features are disabled. >> >> I can reproduce this without pktgen (happened on >> a port that is running no traffic at all..maybe just >> some IPv6 auto-discovery pkts or an arp or two). >> >> I cannot reproduce it when using the out-of-tree e1000e >> driver (e1000e-1.10.6). >> >> I'll start bisecting > > Ben, thanks for taking the time to report this and bisect for us. We > are paying attention and want to get any issues fixed. I appreciate that. I just reproduced it on 3.2.2 (vanilla), so at least it isn't the patches I recently added :) Also, seems the easy way to reproduce this is just to bounce the peer interface. Seems to happen every time. >>> We do not see this problem in the 3.0 kernel, but have not tried to bisect >>> further at this point. >>> >>> This is it's lspci line: >>> 08:00.0 Ethernet controller: Intel Corporation 82571EB Gigabit Ethernet >>> Controller (rev 06) >>> >>> [root@simech2-F16_64 lanforge]# ethtool -i eth2 >>> driver: e1000e >>> version: 1.5.1-k >>> firmware-version: 5.6-2 > > wow, this is a really old Dell card, isn't it. It's not a Dell, probably something from Silicom-usa.com It is definitely old, and we haven't seen the problem in our newer test systems, but neither have we looked hard yet... I can check if it matters. > do you happen to have ASPM enabled? please include output of lspci -vvv Based on dmesg output, ASPM is not enabled? [root@simech2-F16_64 ~]# dmesg|grep -i aspm pci :01:00.0: disabling ASPM on pre-1.1 PCIe device. You can enable it with 'pcie_aspm=force' pci :02:00.0: disabling ASPM on pre-1.1 PCIe device. You can enable it with 'pcie_aspm=force' pci :02:00.0: disabling ASPM on pre-1.1 PCIe device. You can enable it with 'pcie_aspm=force' pci :04:00.0: disabling ASPM on pre-1.1 PCIe device. You can enable it with 'pcie_aspm=force' pci :06:00.0: disabling ASPM on pre-1.1 PCIe device. You can enable it with 'pcie_aspm=force' pci :07:01.0: disabling ASPM on pre-1.1 PCIe device. You can enable it with 'pcie_aspm=force' pci :07:01.0: disabling ASPM on pre-1.1 PCIe device. You can enable it with 'pcie_aspm=force' pci :08:00.0: disabling ASPM on pre-1.1 PCIe device. You can enable it with 'pcie_aspm=force' pci :09:00.0: disabling ASPM on pre-1.1 PCIe device. You can enable it with 'pcie_aspm=force' pci :0a:00.0: disabling ASPM on pre-1.1 PCIe device. You can enable it with 'pcie_aspm=force' pci :0b:01.0: disabling ASPM on pre-1.1 PCIe device. You can enable it with 'pcie_aspm=force' pci :0b:01.0: disabling ASPM on pre-1.1 PCIe device. You can enable it with 'pcie_aspm=force' pci :0b:01.0: disabling ASPM on pre-1.1 PCIe device. You can enable it with 'pcie_aspm=force' pci :0c:00.0: disabling ASPM on pre-1.1 PCIe device. You can enable it with 'pcie_aspm=force' pci :0d:00.0: disabling ASPM on pre-1.1 PCIe device. You can enable it with 'pcie_aspm=force' pci :0e:00.0: disabling ASPM on pre-1.1 PCIe device. You can enable it with 'pcie_aspm=force' ACPI _OSC control for PCIe not granted, disabling ASPM e1000e :08:00.0: Disabling ASPM L1 e1000e :08:00.1: Disabling ASPM L1 e1000e :09:00.0: Disabling ASPM L1 e1000e :09:00.1: Disabling ASPM L1 e1000e :0c:00.0: Disabling ASPM L1 e1000e :0c:00.1: Disabling ASPM L1 e1000e :0d:00.0: Disabling ASPM L1 e1000e :0d:00.1: Disabling ASPM L1 e1000e :0e:00.0: Disabling ASPM L1 e1000e :0e:00.1: Disabling ASPM L1 08:00.0 Ethernet controller: Intel Corporation 82571EB Gigabit Ethernet Controller (rev 06) Subsystem: Intel Corporation PRO/1000 PT Dual Port Server Adapter Control: I/O+ Mem+ BusMaster+ SpecCycle- MemWINV- VGASnoop- ParErr+ Stepping- SERR+ FastB2B- DisINTx+ Status: Cap+ 66MHz- UDF- FastB2B- ParErr- DEVSEL=fast >TAbort- SERR- >>> bus-info: :08:00.0 >>> supports-statistics: yes >>> supports-test: yes >>> supports-eeprom-access: yes >>> supports-register-dump: yes >>> >>> ethtool -t returns PASS. >>> >>> Please let me know if there is any additional info I can offer. > > we also have a tool called ethregs that dumps registers (downloadable > from e1000.sf.net) and we can compare the differences between a driver > loaded on 3.0 and a driver loaded on 3.3.2 Is that worth doing now, or should I go ahead and complete the bisect? Bisect is likely to take a while, but if no one has time to inspect the ethregs stuff quickly then likely it won't be so useful?? Thanks, Ben -- Ben Greear Candela Technologies Inc http://www.candelatech.com -- For Developers, A Lot Can Happen In A Second. Boundary is the first to Know...and Tell You. Monitor
Re: [E1000-devel] e1000e transmit queue hang in 3.3.2+
Ben, Would you please set current message level via ethtool to hw + tx_done + rx_status; then driver will log tx desc and rx desc data into dmesg when hang occurs. That will show us what's going on. Please send me the dmesg log after the tx hang. Thanks. -Tushar >-Original Message- >From: Ben Greear [mailto:gree...@candelatech.com] >Sent: Thursday, April 19, 2012 10:10 AM >To: e1000-devel list >Subject: Re: [E1000-devel] e1000e transmit queue hang in 3.3.2+ > >On 04/18/2012 03:12 PM, Ben Greear wrote: >> This kernel has my rx-fcs, rx-all, tx-crc patches applied, but the >> features are disabled. > >I can reproduce this without pktgen (happened on a port that is running no >traffic at all..maybe just some IPv6 auto-discovery pkts or an arp or >two). > >I cannot reproduce it when using the out-of-tree e1000e driver (e1000e- >1.10.6). > >I'll start bisecting > >Thanks, >Ben > >> >> It takes a few minutes, but we can get one of our systems running >> 3.3.2+ to exhibit xmit queue hangs. We are running full-duplex 1Gbps >> traffic using pktgen. In my testing, it ran for a while..and then I >> was testing resetting the port (ifdown, ifup, basically) while traffic >> was flowing. >> >> A few times of that and it got into this state. >> >> Apr 18 15:03:57 localhost kernel: e1000e :08:00.0: eth2: Reset >> adapter Apr 18 15:04:00 localhost kernel: e1000e: eth2 NIC Link is Up >> 1000 Mbps Full Duplex, Flow Control: Rx/Tx Apr 18 15:04:00 localhost >> kernel: ADDRCONF(NETDEV_CHANGE): eth2: link becomes ready Apr 18 >> 15:04:05 localhost kernel: NETDEV WATCHDOG: eth2 (e1000e): transmit >> queue 0 timed out, trans_start: 4305396627, wd-timeout: 5000 jiffies: >> 4305402016 >> tx-queues: 1 >> >> We do not see this problem in the 3.0 kernel, but have not tried to >> bisect further at this point. >> >> This is it's lspci line: >> 08:00.0 Ethernet controller: Intel Corporation 82571EB Gigabit >> Ethernet Controller (rev 06) >> >> [root@simech2-F16_64 lanforge]# ethtool -i eth2 >> driver: e1000e >> version: 1.5.1-k >> firmware-version: 5.6-2 >> bus-info: :08:00.0 >> supports-statistics: yes >> supports-test: yes >> supports-eeprom-access: yes >> supports-register-dump: yes >> >> ethtool -t returns PASS. >> >> Please let me know if there is any additional info I can offer. >> >> Thanks, >> Ben >> > > >-- >Ben Greear >Candela Technologies Inc http://www.candelatech.com > > >-- > >For Developers, A Lot Can Happen In A Second. >Boundary is the first to Know...and Tell You. >Monitor Your Applications in Ultra-Fine Resolution. Try it FREE! >http://p.sf.net/sfu/Boundary-d2dvs2 >___ >E1000-devel mailing list >E1000-devel@lists.sourceforge.net >https://lists.sourceforge.net/lists/listinfo/e1000-devel >To learn more about Intel® Ethernet, visit >http://communities.intel.com/community/wired -- For Developers, A Lot Can Happen In A Second. Boundary is the first to Know...and Tell You. Monitor Your Applications in Ultra-Fine Resolution. Try it FREE! http://p.sf.net/sfu/Boundary-d2dvs2 ___ E1000-devel mailing list E1000-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/e1000-devel To learn more about Intel® Ethernet, visit http://communities.intel.com/community/wired
Re: [E1000-devel] e1000e transmit queue hang in 3.3.2+
On 04/18/2012 03:12 PM, Ben Greear wrote: > This kernel has my rx-fcs, rx-all, tx-crc patches applied, > but the features are disabled. I can reproduce this without pktgen (happened on a port that is running no traffic at all..maybe just some IPv6 auto-discovery pkts or an arp or two). I cannot reproduce it when using the out-of-tree e1000e driver (e1000e-1.10.6). I'll start bisecting Thanks, Ben > > It takes a few minutes, but we can get one of our systems > running 3.3.2+ to exhibit xmit queue hangs. We are running > full-duplex 1Gbps traffic using pktgen. In my testing, > it ran for a while..and then I was testing resetting the > port (ifdown, ifup, basically) while traffic was flowing. > > A few times of that and it got into this state. > > Apr 18 15:03:57 localhost kernel: e1000e :08:00.0: eth2: Reset adapter > Apr 18 15:04:00 localhost kernel: e1000e: eth2 NIC Link is Up 1000 Mbps Full > Duplex, Flow Control: Rx/Tx > Apr 18 15:04:00 localhost kernel: ADDRCONF(NETDEV_CHANGE): eth2: link becomes > ready > Apr 18 15:04:05 localhost kernel: NETDEV WATCHDOG: eth2 (e1000e): transmit > queue 0 timed out, trans_start: 4305396627, wd-timeout: 5000 jiffies: > 4305402016 > tx-queues: 1 > > We do not see this problem in the 3.0 kernel, but have not tried to bisect > further at this point. > > This is it's lspci line: > 08:00.0 Ethernet controller: Intel Corporation 82571EB Gigabit Ethernet > Controller (rev 06) > > [root@simech2-F16_64 lanforge]# ethtool -i eth2 > driver: e1000e > version: 1.5.1-k > firmware-version: 5.6-2 > bus-info: :08:00.0 > supports-statistics: yes > supports-test: yes > supports-eeprom-access: yes > supports-register-dump: yes > > ethtool -t returns PASS. > > Please let me know if there is any additional info I can offer. > > Thanks, > Ben > -- Ben Greear Candela Technologies Inc http://www.candelatech.com -- For Developers, A Lot Can Happen In A Second. Boundary is the first to Know...and Tell You. Monitor Your Applications in Ultra-Fine Resolution. Try it FREE! http://p.sf.net/sfu/Boundary-d2dvs2 ___ E1000-devel mailing list E1000-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/e1000-devel To learn more about Intel® Ethernet, visit http://communities.intel.com/community/wired
Re: [E1000-devel] [PATCH] e1000e: MSI interrupt test failed, using legacy interrupt
We have not seen a report of this issue before. Please provide details on the NIC or LOM and system/chipset on which the problem occurs and how the additional 50ms was determined. > -Original Message- > From: prasanna.panchamu...@riverbed.com > [mailto:prasanna.panchamu...@riverbed.com] > Sent: Wednesday, April 18, 2012 5:18 PM > To: Allan, Bruce W; Kirsher, Jeffrey T; Brandeburg, Jesse; Pieper, > Jeffrey E > Cc: e1000-devel@lists.sourceforge.net; > prasanna.panchamu...@riverbed.com > Subject: [PATCH] e1000e: MSI interrupt test failed, using legacy > interrupt > > From: Prasanna S. Panchamukhi > > Following logs where seen on Systems with multiple NICs, > while using MSI interrupts as shown below: > > Feb 16 15:09:32 (none) user.notice kernel: :00:0d.0: lan0_0: NIC > Link is Up > 1000 Mbps Full Duplex, Flow Control: RX/TX > Feb 16 15:09:32 (none) user.notice kernel: :40:0d.0: wan0_1: NIC > Link is Up > 1000 Mbps Full Duplex, Flow Control: RX/TX > Feb 16 15:09:32 (none) user.notice kernel: :40:0d.0: lan0_1: NIC > Link is Up > 1000 Mbps Full Duplex, Flow Control: RX/TX > Feb 16 15:09:32 (none) user.warn kernel: :40:0e.0: wan4_0: MSI > interrupt > test failed, using legacy interrupt. > ^ > Feb 16 15:09:32 (none) user.notice kernel: :00:0e.0: wan1_0: NIC > Link is Up > 1000 Mbps Full Duplex, Flow Control: RX/TX > Feb 16 15:09:33 (none) user.notice kernel: :00:0e.0: lan1_0: NIC > Link is Up > 1000 Mbps Full Duplex, Flow Control: RX/TX > Feb 16 15:09:33 (none) user.notice kernel: :00:0f.0: wan2_0: NIC > Link is Up > 1000 Mbps Full Duplex, Flow Control: RX/TX > Feb 16 15:09:33 (none) user.notice kernel: :00:0f.0: lan2_0: NIC > Link is Up > 1000 Mbps Full Duplex, Flow Control: RX/TX > Feb 16 15:09:33 (none) user.notice kernel: :40:0a.0: wan3_0: NIC > Link is Up > 1000 Mbps Full Duplex, Flow Control: RX/TX > Feb 16 15:09:33 (none) user.notice kernel: :40:0a.0: lan3_0: NIC > Link is Up > 1000 Mbps Full Duplex, Flow Control: RX/TX > Feb 16 15:09:34 (none) user.notice kernel: :40:0e.0: lan4_0: NIC > Link is Up > 1000 Mbps Full Duplex, Flow Control: RX/TX > Feb 16 15:09:34 (none) user.notice kernel: :40:0f.0: wan5_0: NIC > Link is Up > 1000 Mbps Full Duplex, Flow Control: RX/TX > Feb 16 15:09:34 (none) user.notice kernel: :40:0f.0: lan5_0: NIC > Link is Up > 1000 Mbps Full Duplex, Flow Control: RX/TX > > This patch fixes this problem by increasing the msleep from 50 to 100. > > Signed-off-by: Prasanna S. Panchamukhi > --- > drivers/net/ethernet/intel/e1000e/netdev.c |2 +- > 1 files changed, 1 insertions(+), 1 deletions(-) > > diff --git a/drivers/net/ethernet/intel/e1000e/netdev.c > b/drivers/net/ethernet/intel/e1000e/netdev.c > index 19ab215..9520a6a 100644 > --- a/drivers/net/ethernet/intel/e1000e/netdev.c > +++ b/drivers/net/ethernet/intel/e1000e/netdev.c > @@ -3799,7 +3799,7 @@ static int e1000_test_msi_interrupt(struct > e1000_adapter *adapter) > /* fire an unusual interrupt on the test handler */ > ew32(ICS, E1000_ICS_RXSEQ); > e1e_flush(); > - msleep(50); > + msleep(100); > > e1000_irq_disable(adapter); > > -- > 1.7.0.4 -- For Developers, A Lot Can Happen In A Second. Boundary is the first to Know...and Tell You. Monitor Your Applications in Ultra-Fine Resolution. Try it FREE! http://p.sf.net/sfu/Boundary-d2dvs2 ___ E1000-devel mailing list E1000-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/e1000-devel To learn more about Intel® Ethernet, visit http://communities.intel.com/community/wired
[E1000-devel] Отдел продаж: как управлять
26-27 апреля в Москве (с 1О.ОО до 17.ЗО) УПРАВЛЕНИЕ ПРОДАЖАМИ. КАК ПРОДАВАТЬ ВДВОЕ БОЛЬШЕ. Место проведения: м. Бауманская, ул. Бауманская, д.6, бизнес центр "Виктория Плаза". Стоимость участия - 17 5OО рублей. В стоимость входит методический материал, обеды, кофе-паузы, сертификат. Информация по условиям обучения: (495) 9 2 1 - З О - 1 7 - Почему на падающих рынках можно заработать больше, чем на растущих. - Как и вокруг чего создается коллектив, нацеленный на дело. - Что сотрудников мотивирует на труд, а что – на потребительское отношение. - За что платить зарплату сотрудникам отдела продаж. - Что является ключевыми аспектами управленческой работы начальника отдела продаж. Содержание: 1. Рынок. Что руководитель коммерческой службы должен принимать в расчет. Ценовые сегменты или о вреде фраз "наш покупатель – представитель среднего класса…" Почему даже на падающем рынке немало компаний, увеличивших объемы продаж и доходность? Первые и Повторные покупки и как научить отдел продаж не сваливать их "в общую кучу". Малобюджетный маркетинг. Почти без денег или совсем без денег. Как мы можем принимать адекватные решения, включая здравый смысл. 2. Управление Отделом. Правила Игры. Правило передачи ответственности в отделе продаж. Матрица ответственности Жандарова Нормирование. Планирование. Технологические карты. Обучение, переподготовка, сравнение результатов сотрудников друг с другом. Форматы и режимы обучения: Книги, фильмы, доклады, экзамены, испытания. Формат взрослого общения. Планирование, Организация, Мотивация и Контроль. Проект "Построение по росту". Квалификация, уровни, навыки, области ответственности, ошибки. 3. Тайм-менеджмент отдела продаж. Сколько "весят" по времени операции сотрудника. Проект "разделение труда" (если у сотрудников много отвлечений от рабочего процесса") "Вредные" отвлечения от работы и их "убиение" (штрафы, прочие дисциплинарные воздействия) Обязательность планирования дел. Чему должен быть обучен сотрудник в области тайм-менеджмента. 4. Проект "золотые сотрудники". От каких сотрудников можно и должно отказаться. Каким требованиям должен соответствовать сотрудник, чтобы руководство компании держалось за него до последнего. Как сделать так, чтобы сотрудники хотели стать "золотыми". 5. Мотивация, обещания, исполнение обязательств. Во что люди верят, чего хотят и чего не хотят. Чего не стоит и как не стоит обещать. Ключевая роль связи между результатами труда и вознаграждением/порицанием. Как строить саморегулирующиеся системы управления. Как создается коллектив, чем он полезен для управления. Универсальные ошибки руководителя. Обязательные правильные навыки руководителя, как их можно натренировать. 6. Зарплата в Отделе Продаж. Почему вредно платить % от оборота Как технологически предотвратить будущую "звездность" Принципиальная математика зарплатной схемы в Отделе Продаж Проект "Внедрение" Практикум: разбор примеров зарплатных решений для сотрудников отделов продаж. -- For Developers, A Lot Can Happen In A Second. Boundary is the first to Know...and Tell You. Monitor Your Applications in Ultra-Fine Resolution. Try it FREE! http://p.sf.net/sfu/Boundary-d2dvs2___ E1000-devel mailing list E1000-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/e1000-devel To learn more about Intel® Ethernet, visit http://communities.intel.com/community/wired
