Re: iflib-if_em tests with HEAD and lagg panic [Was: Re: svn commit: r333338 - in stable/11/sys: dev/bnxt kern net sys]
Ok, the review is updated with the EBR. If you can update your tree to r333466 or newer, apply the patch and retest, that would be great. It seems to be working here. On Thu, May 10, 2018 at 2:29 PM, Harry Schmalzbauer <free...@omnilan.de> wrote: > Bezüglich Stephen Hurd's Nachricht vom 10.05.2018 20:07 (localtime): > > No need to test the latest revision unless/until you get a LOR or a > > panic (both should be possible with the revision you currently have). > > With the recent addition of a simple EBR API, mmacy@ is working on a > > better solution. If possible, it would be great to have you re-test it > > once that is up. > > > Since this literally brand new _haswell_ (DH87MC) box is waiting now for > 3 years to replace my 10 years old core2duo, I'll keep it on the tinker > bench... > > I'd have some "smbios0: SMBIOS checksum failed" and > "[drm2:pid:hangcheck_hung]...GPU hung" issues to track/report, but since > finding Xorg's secret about "MatchIsKeyboard" took me too much time, > this is postponed. > > -harry > -- [image: Limelight Networks] <http://www.limelight.com> Stephen Hurd* Principal Engineer* EXPERIENCE FIRST. +1 616 848 0643 <+1+616+848+0643> www.limelight.com [image: Facebook] <https://www.facebook.com/LimelightNetworks>[image: LinkedIn] <http://www.linkedin.com/company/limelight-networks>[image: Twitter] <https://twitter.com/llnw> ___ freebsd-net@freebsd.org mailing list https://lists.freebsd.org/mailman/listinfo/freebsd-net To unsubscribe, send any mail to "freebsd-net-unsubscr...@freebsd.org"
Re: iflib-if_em tests with HEAD and lagg panic [Was: Re: svn commit: r333338 - in stable/11/sys: dev/bnxt kern net sys]
No need to test the latest revision unless/until you get a LOR or a panic (both should be possible with the revision you currently have). With the recent addition of a simple EBR API, mmacy@ is working on a better solution. If possible, it would be great to have you re-test it once that is up. On Thu, May 10, 2018 at 2:02 PM, Harry Schmalzbauer <free...@omnilan.de> wrote: > Bezüglich Harry Schmalzbauer's Nachricht vom 10.05.2018 19:54 (localtime): > … > > Please excuse that I'm not familar with the phabricator and just did > > "raw diff download" after briefly flying over the comments. > > According to st_mtime this was on May 9th, 08:14:02 UTC (10:14 local > > (CEST) time). > > No idea what timezone phabricator reports to me, most likely respecting > > local time. Which means latest revision was part of my test – but I'm > > Oh, I missed "pm". > Phabricator reports Wed, May 9, 9:49 PM > <https://reviews.freebsd.org/D15355#324063> as last revision, my > download was from 10:14 _AM_... > But if the web site was respecting local time zone, I guess it would > respect local time format, so not PM, but 21:49... > So I think it's most likely any UTC+>2 time, so the revision I tested > was probably Diff 42294 <https://reviews.freebsd.org/B16487>. > > Just tell me if it was useful for you to test the latest revision again. > > -harry > -- [image: Limelight Networks] <http://www.limelight.com> Stephen Hurd* Principal Engineer* EXPERIENCE FIRST. +1 616 848 0643 <+1+616+848+0643> www.limelight.com [image: Facebook] <https://www.facebook.com/LimelightNetworks>[image: LinkedIn] <http://www.linkedin.com/company/limelight-networks>[image: Twitter] <https://twitter.com/llnw> ___ freebsd-net@freebsd.org mailing list https://lists.freebsd.org/mailman/listinfo/freebsd-net To unsubscribe, send any mail to "freebsd-net-unsubscr...@freebsd.org"
Re: iflib-if_em tests with HEAD and lagg panic [Was: Re: svn commit: r333338 - in stable/11/sys: dev/bnxt kern net sys]
ff807dd348 at inm_release_task+0x218 > #11 0x806dea29 at gtaskqueue_run_locked+0x139 > #12 0x806de7a8 at gtaskqueue_thread_loop+0x88 > #13 0x80659d84 at fork_exit+0x84 > #14 0x809b767e at fork_trampoline+0xe > Sleeping thread (tid 100017, pid 0) owns a non-sleepable lock > KDB: stack backtrace of thread 100017: > sched_switch() at sched_switch+0x945/frame 0xfe00750dc5d0 > mi_switch() at mi_switch+0x18c/frame 0xfe00750dc600 > sleepq_switch() at sleepq_switch+0x10d/frame 0xfe00750dc640 > sleepq_timedwait() at sleepq_timedwait+0x50/frame 0xfe00750dc680 > _sleep() at _sleep+0x307/frame 0xfe00750dc730 > pause_sbt() at pause_sbt+0x144/frame 0xfe00750dc780 > e1000_write_phy_reg_mdic() at e1000_write_phy_reg_mdic+0xf1/frame > 0xfe00750dc7c0 > e1000_enable_phy_wakeup_reg_access_bm() at > e1000_enable_phy_wakeup_reg_access_bm+0x2f/frame 0xfe00750dc7e0 > e1000_update_mc_addr_list_pch2lan() at > e1000_update_mc_addr_list_pch2lan+0x3a/frame 0xfe00750dc820 > em_if_multi_set() at em_if_multi_set+0x1bf/frame 0xfe00750dc870 > iflib_if_ioctl() at iflib_if_ioctl+0xfe/frame 0xfe00750dc8e0 > lagg_ioctl() at lagg_ioctl+0x115/frame 0xfe00750dc990 > inm_release_task() at inm_release_task+0x218/frame 0xfe00750dc9f0 > gtaskqueue_run_locked() at gtaskqueue_run_locked+0x139/frame > 0xfe00750dca40 > gtaskqueue_thread_loop() at gtaskqueue_thread_loop+0x88/frame > 0xfe00750dca70 > fork_exit() at fork_exit+0x84/frame 0xfe00750dcab0 > fork_trampoline() at fork_trampoline+0xe/frame 0xfe00750dcab0 > --- trap 0, rip = 0, rsp = 0, rbp = 0 --- > panic: sleeping thread > cpuid = 3 > time = 1525794682 > KDB: stack backtrace: > db_trace_self_wrapper() at db_trace_self_wrapper+0x2b/frame > 0xfe008fe180e0 > vpanic() at vpanic+0x1a3/frame 0xfe008fe18140 > panic() at panic+0x43/frame 0xfe008fe181a0 > propagate_priority() at propagate_priority+0x335/frame 0xfe008fe181e0 > turnstile_wait() at turnstile_wait+0x38d/frame 0xfe008fe18230 > __mtx_lock_sleep() at __mtx_lock_sleep+0x1e1/frame 0xfe008fe182b0 > __mtx_lock_flags() at __mtx_lock_flags+0xf9/frame 0xfe008fe18300 > _rm_rlock() at _rm_rlock+0x280/frame 0xfe008fe18330 > _rm_rlock_debug() at _rm_rlock_debug+0x14c/frame 0xfe008fe18380 > lagg_transmit() at lagg_transmit+0x38/frame 0xfe008fe183f0 > ether_output_frame() at ether_output_frame+0xaa/frame 0xfe008fe18420 > ether_output() at ether_output+0x68b/frame 0xfe008fe184c0 > arprequest() at arprequest+0x474/frame 0xfe008fe185c0 > arp_ifinit() at arp_ifinit+0x58/frame 0xfe008fe18600 > ether_ioctl() at ether_ioctl+0x1d1/frame 0xfe008fe18630 > lagg_ioctl() at lagg_ioctl+0x602/frame 0xfe008fe186e0 > in_control() at in_control+0x8f5/frame 0xfe008fe18780 > ifioctl() at ifioctl+0x19c6/frame 0xfe008fe18850 > kern_ioctl() at kern_ioctl+0x2b9/frame 0xfe008fe188b0 > sys_ioctl() at sys_ioctl+0x168/frame 0xfe008fe18980 > amd64_syscall() at amd64_syscall+0x2cc/frame 0xfe008fe18ab0 > fast_syscall_common() at fast_syscall_common+0x101/frame > 0xfe008fe18ab0 > --- syscall (54, FreeBSD ELF64, sys_ioctl), rip = 0x8004820ba, rsp = > 0x7fffe1c8, rbp = 0x7fffe210 --- > KDB: enter: panic > > > Hope this helps, > > -harry > -- [image: Limelight Networks] <http://www.limelight.com> Stephen Hurd* Principal Engineer* EXPERIENCE FIRST. +1 616 848 0643 <+1+616+848+0643> www.limelight.com [image: Facebook] <https://www.facebook.com/LimelightNetworks>[image: LinkedIn] <http://www.linkedin.com/company/limelight-networks>[image: Twitter] <https://twitter.com/llnw> ___ freebsd-net@freebsd.org mailing list https://lists.freebsd.org/mailman/listinfo/freebsd-net To unsubscribe, send any mail to "freebsd-net-unsubscr...@freebsd.org"
Re: LOR in iflib_timer
Eric van Gyzen wrote: Twice a day, my router hits an LOR in iflib_timer when it jumps to the "hung" label. It's running r325049 (head 3 days ago). lock order reversal: 1st 0xfef36068 igb1:tx(0):call (igb1:tx(0):call) @ /usr/src/sys/kern/kern_mutex.c:182 2nd 0xf80003b0c150 igb1 (iflib ctx lock) @ /usr/src/sys/net/iflib.c:2139 This looks like it was fixed by the big rollup. If it was fixed by a smallish commit, can that commit alone be merged to head? If someone can point me to the commit, I'd be happy to test it. Eric I would guess it to be one of the biggest ones. Review here: https://reviews.freebsd.org/D12101 ___ freebsd-net@freebsd.org mailing list https://lists.freebsd.org/mailman/listinfo/freebsd-net To unsubscribe, send any mail to "freebsd-net-unsubscr...@freebsd.org"
Re: RFC: ethctl
Kevin Bowling wrote: I have heard from several vendors the need for a NIC configuration tool. Chelsio ships a cxgb/cxgbetool in FreeBSD as one example. There is precedence for some nod toward a basic unified tool in Linux ethtool. From your perspective, 1) What are the common requirements? 2) What are specialized requirements? For instance as a full TCP offload card Chelsio needs things others wont 3) What should it _not_ do? Several of you have experience doing Ethernet driver dev on many platforms so we should attempt to avoid repeating past design mistakes. Regarding #3, the current ethtool nvram access is a very poor match for how nvram is used on Broadcom devices. Treating it as a tree or at least a key/value store would make support a lot easier in the driver. Very little of the nvram contents can be addressed by offset anymore. For firmware upgrades, it's even worse. Newer Broadcom devices need to have the firmware flashed into a staging area, then have the device notified to validate the image before an upgrade is complete. The generic nvram read/write methods can't be used for firmware and a small set of critical configuration data. ___ freebsd-net@freebsd.org mailing list https://lists.freebsd.org/mailman/listinfo/freebsd-net To unsubscribe, send any mail to "freebsd-net-unsubscr...@freebsd.org"
RE: Patch to allow disabling logging of arp movements through sysctl
is there any chance this patch will be commited soon to the -STABLE tree? i'm having a similar problems and it's driving me crazy. my log is full with all the arp movement messages. As I understand it, there's a very good change... possibly so good that it's already done. ;-) Alfred Perlstein asked me to remind him about it after 4.4-RELEASE and I did, so it's probobly already done. Or if it isn't, it will be shortly I would think... then I can brag to all my geek friends that I wrote a kernel patch for FreeBSD and it was accepted! To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-net in the body of the message
