Re: Status of PCIe Hotplug?
On 09/27/2016 17:51, Eric van Gyzen wrote: > In the case of Jan's USB 3.0 ExpressCard, it's possible that one or all > of the USB controller drivers (xhci, ehci, uhci) didn't cope with the > surprise removal of the controller. Before removing the card, try > detaching the driver(s) with "devctl detach xhciN". There might be more > than one device. Use "pciconf -lc" to find the HotPlug-capable pcib > devices (bridges). Use devinfo to find which one is your ExpressCard > slot and find all the devices attached to it. Then use devctl to detach > the devices. There could be a tree of devices; in that case, you can > usually start at the level immediately under pcibN; you don't need to > detach every device from the bottom up. Once all the devices are > detached, you should be able to remove the card safely. Doing "devctl detach xhci0" before the removal of the USB 3.0 ExpressCard, there is no panic, the device gets deattached properly, and I can reconnect it later. Anyhow, because the mechanism holding the ExpressCard is not completely reliable, on the third time inserting the card, it did not hold and I got a panic, because it was immediately ejected without devctl detach. Due to the card not holding firmly, I often pulled it together with the usb device on 10.3-RELEASE and never got a panic. I guess it is a regression in the usb driver dealing with sudden loss of the device. The panic message is below, I guess I should take this discussion to freebsd-usb@, CCed. Thanks, Jan Henrik Fatal trap 9: general protection fault while in kernel mode cpuid = 1; acpic id = 01 instruction pointer = 0x20:0x80b1549c stack pointer = 0x28:0xfe022f62ca00 frame pointer = 0x28:0xfe022f62ca70 code segment= base 0x0, limit 0xf, type 0x1b = DPL 0, pres 1, long 1, def32 0, gran 1 processor eflags= interrupt enabled, resume, IOPL = 0 current process = 14 (usbus1) trap number = 9 panic: general protection fault cpuid = 1 KDB: stack backtrace: #0 0x80b24077 at kdb_backtrace+0x67 #1 0x80ad93e2 at vpanic+0x182 #2 0x80ad9253 at panic+0x43 #3 0x80fa0d31 at trap_fatal+0x351 #4 0x80fa09c8 at trap+0x768 #5 0x80f84141 at calltrap+0x8 #6 0x808f2f63 at usb_detach_device+0xf3 #7 0x808f1d5b at usb_unconfigure+0x2b #8 0x808f5623 at usb_free_device+0x103 #9 0x808f58b1 at usb_bus_detach+0x161 #10 0x80903e95 at usb_process+0x125 #11 0x80a90055 at fork_exit+0x85 #12 0x80f8467e at fork_trampoline+0xe Uptime: 18m27s Automatic reboot in 15 seconds - press a key on the console to abort ___ freebsd-stable@freebsd.org mailing list https://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to "freebsd-stable-unsubscr...@freebsd.org"
Re: Status of PCIe Hotplug?
Hi, Can you compile your kernel with debugging enabled so that we get the sourcelines in the dump below. Also please include some parts of the preceeding dmesg. Do you have USB compiled into the kernel or loaded as a module? What does kldstat output after you plug the card? What is the dmesg leading up to this? The bug looks like some .ko was unloaded too early, due to refcounts dropping incorrectly. --HPS Fatal trap 9: general protection fault while in kernel mode cpuid = 1; acpic id = 01 instruction pointer = 0x20:0x80b1549c stack pointer = 0x28:0xfe022f62ca00 frame pointer = 0x28:0xfe022f62ca70 code segment= base 0x0, limit 0xf, type 0x1b = DPL 0, pres 1, long 1, def32 0, gran 1 processor eflags= interrupt enabled, resume, IOPL = 0 current process = 14 (usbus1) trap number = 9 panic: general protection fault cpuid = 1 KDB: stack backtrace: #0 0x80b24077 at kdb_backtrace+0x67 #1 0x80ad93e2 at vpanic+0x182 #2 0x80ad9253 at panic+0x43 #3 0x80fa0d31 at trap_fatal+0x351 #4 0x80fa09c8 at trap+0x768 #5 0x80f84141 at calltrap+0x8 #6 0x808f2f63 at usb_detach_device+0xf3 #7 0x808f1d5b at usb_unconfigure+0x2b #8 0x808f5623 at usb_free_device+0x103 #9 0x808f58b1 at usb_bus_detach+0x161 #10 0x80903e95 at usb_process+0x125 #11 0x80a90055 at fork_exit+0x85 #12 0x80f8467e at fork_trampoline+0xe Uptime: 18m27s Automatic reboot in 15 seconds - press a key on the console to abort ___ freebsd-stable@freebsd.org mailing list https://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to "freebsd-stable-unsubscr...@freebsd.org"
Re: Status of PCIe Hotplug?
> On 27 Sep 2016, at 17:51, Eric van Gyzen wrote: > > > To my knowledge, all the necessary PCIe-layer code is present. However, > that's just one layer: Many drivers will likely need changes in order > to cope with surprise removal of their devices. Thank you very much, that’s what I needed to know :) I saw that the bits were indeed present, but I was wondering wether I should expect it to work or not. > For that reason, HotPlug needs a lot of testing on a variety of > platforms. The FreeBSD developer base is much smaller than its user > base, of course, so the variety of our testing is rather limited. You > can help immensely by giving us detailed bug reports, either on a > mailing list or in Bugzilla. For a panic, the panic messages and stack > trace of the current thread will be very helpful. Complete crashinfo(8) > output would be great. Of course. Unfortunately, due to poor timing and a DOA server last month, this server is in a countdown to get into production tomorrow running Solaris, but I’ll try to get whatever I can today. Thanks! Borja. ___ freebsd-stable@freebsd.org mailing list https://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to "freebsd-stable-unsubscr...@freebsd.org"
Re: 11.0 stuck on high network load
Hi Slawa, On 9/26/16 7:22 PM, Slawa Olhovchenkov wrote: > On Mon, Sep 26, 2016 at 11:33:12AM +0200, Julien Charbon wrote: >> On 9/25/16 2:46 PM, Slawa Olhovchenkov wrote: >>> On Fri, Sep 23, 2016 at 11:01:43PM +0300, Slawa Olhovchenkov wrote: > On 9/21/16 9:51 PM, Slawa Olhovchenkov wrote: >> On Wed, Sep 21, 2016 at 09:11:24AM +0200, Julien Charbon wrote: >>> You can also use Dtrace and lockstat (especially with the lockstat -s >>> option): >>> >>> https://wiki.freebsd.org/DTrace/One-Liners#Kernel_Locks >>> https://www.freebsd.org/cgi/man.cgi?query=lockstat&manpath=FreeBSD+11.0-RELEASE >>> >>> But I am less familiar with Dtrace/lockstat tools. >> >> I am still use old kernel and got lockdown again. >> Try using lockstat (I am save more output), interesting may be next: >> >> R/W writer spin on writer: 190019 events in 1.070 seconds (177571 >> events/sec) >> >> --- >> Count indv cuml rcnt nsec Lock Caller >> >> 140839 74% 74% 0.0024659 tcpinp >> tcp_tw_2msl_scan+0xc6 >> >> nsec -- Time Distribution -- count Stack >> >> 4096 | 913 tcp_twstart+0xa3 >> >> 8192 | 58191 >> tcp_do_segment+0x201f >> 16384 |@@ 29594 tcp_input+0xe1c >> >> 32768 | 23447 ip_input+0x15f >> >> 65536 |@@@16197 >> 131072 |@ 8674 >> 262144 | 3358 >> 524288 | 456 >>1048576 | 9 >> --- >> Count indv cuml rcnt nsec Lock Caller >> >> 49180 26% 100% 0.0015929 tcpinp >> tcp_tw_2msl_scan+0xc6 >> >> nsec -- Time Distribution -- count Stack >> >> 4096 | 157 pfslowtimo+0x54 >> >> 8192 |@@@24796 >> softclock_call_cc+0x179 >> 16384 |@@ 11223 softclock+0x44 >> >> 32768 | 7426 >> intr_event_execute_handlers+0x95 >> 65536 |@@ 3918 >> 131072 | 1363 >> 262144 | 278 >> 524288 | 19 >> --- > > This is interesting, it seems that you have two call paths competing > for INP locks here: > > - pfslowtimo()/tcp_tw_2msl_scan(reuse=0) and > > - tcp_input()/tcp_twstart()/tcp_tw_2msl_scan(reuse=1) My current hypothesis: nginx do write() (or may be close()?) to socket, kernel lock first inp in V_twq_2msl, happen callout for pfslowtimo() on the same CPU core and tcp_tw_2msl_scan infinity locked on same inp. In this case you modification can't help, before next try we need some like yeld(). >>> >>> Or may be locks leaks. >>> Or both. >> >> You are totally right, pfslowtimo()/tcp_tw_2msl_scan(reuse=0) is >> infinitely blocked on INP_WLOCK() by "something" (that could be related >> to write()). >> >> As I reached my limit of debugging without WITNESS, could you share >> your /etc/sysctl.conf, /boot/loader.conf files? And any specific >> configuration you have (like having a Nginx workers affinity, Nginx >> special options, etc.). Like that I can try to reproduce it on releng/11.0. > > Some more traces from ddb: > > Tracing command intr pid 12 tid 100103 td 0xf8012508ea00 > sched_switch() at 0x804c956d = sched_switch+0x6ad/frame > 0xfe2020ea8330 > mi_switch() at 0x804a8d92 = mi_switch+0xd2/frame 0xfe2020ea8360 > turnstile_wait() at 0x804ef177 = turnstile_wait+0x2a7/frame > 0xfe2020ea83a0 > __mtx_lock_sleep() at 0x80484d9d = __mtx_lock_sleep+0x13d/frame > 0xfe2020ea8420 > sodealloc() at 0x8051b992 = sodealloc+0x32/frame 0xfe2020ea8460 > tcp_close() at 0x80618150 = tcp_close+0xd0/frame 0xfe2020ea8490 > tcp_do_segment() at 0x80610226 = tcp_do_segment+0x1666/frame > 0xfe2020ea8590 > tcp_input() at 0x8060e17c = tcp_input+0xe1c/frame 0xfe2020ea86e0 > ip_input() at 0x805a087f = ip_input+0x15f/frame 0xfe20
Re: 11.0 stuck on high network load
On Wed, Sep 28, 2016 at 12:06:47PM +0200, Julien Charbon wrote: > > Tracing command intr pid 12 tid 100026 td 0xf8011424b500 > > sched_switch() at 0x804c956d = sched_switch+0x6ad/frame > > 0xfe3876f0 > > mi_switch() at 0x804a8d92 = mi_switch+0xd2/frame 0xfe387720 > > critical_exit() at 0x804a6bee = critical_exit+0x7e/frame > > 0xfe387740 > > ipi_bitmap_handler() at 0x80775629 = ipi_bitmap_handler+0x79/frame > > 0xfe387780 > > Xipi_intr_bitmap_handler() at 0x806cc15e = > > Xipi_intr_bitmap_handler+0x8e/frame 0xfe387780 > > --- interrupt, rip = 0x80484c1f, rsp = 0xfe387850, rbp = > > 0xfe387850 --- > > __mtx_lock_flags() at 0x80484c1f = __mtx_lock_flags+0x2f/frame > > 0xfe387850 > > sodealloc() at 0x8051b992 = sodealloc+0x32/frame 0xfe387890 > > tcp_close() at 0x80618150 = tcp_close+0xd0/frame 0xfe3878c0 > > tcp_timer_2msl() at 0x8061dda3 = tcp_timer_2msl+0x1f3/frame > > 0xfe3878f0 > > softclock_call_cc() at 0x804b4ca9 = softclock_call_cc+0x179/frame > > 0xfe3879c0 > > softclock() at 0x804b5034 = softclock+0x44/frame 0xfe3879e0 > > intr_event_execute_handlers() at 0x8046c605 = > > intr_event_execute_handlers+0x95/frame 0xfe387a20 > > ithread_loop() at 0x8046cc26 = ithread_loop+0xa6/frame > > 0xfe387a70 > > fork_exit() at 0x8046a211 = fork_exit+0x71/frame 0xfe387ab0 > > fork_trampoline() at 0x806cb50e = fork_trampoline+0xe/frame > > 0xfe387ab0 > > --- trap 0, rip = 0, rsp = 0, rbp = 0 --- > > Nice stack traces, all threads are blocked in sodealloc() or soalloc() > and if you look at how mtx_lock(&so_global_mtx) and > mtx_unlock(&so_global_mtx) are used, it is hard to think about a > scenario that can lead to this state. > > I am still trying to reproduce your issue, without success so far. May be some hardware-related (low-speed CPU?). Yesternight I am collect new stack traces and kernel dump. May be I can see something? db> ps pid ppid pgrp uid state wmesg wchancmd 12 0 0 0 RL (threaded) [intr] 100023 RunQ[swi4: clock (8)] 100107 Run CPU 8 [irq291: ix0:q2] 11 0 0 0 RL (threaded) [idle] 100011 CanRun [idle: cpu8] cpuid= 8 dynamic pcpu = 0xfe201d69cf00 curthread= 0xf8012508d500: pid 12 "irq291: ix0:q2" curpcb = 0xfe2020ebcb80 fpcurthread = none idlethread = 0xf8011422c500: tid 100011 "idle: cpu8" curpmap = 0x80d49998 tssp = 0x80d7fcd0 commontssp = 0x80d7fcd0 rsp0 = 0xfe2020ebcb80 gs32p= 0x80d86528 ldt = 0x80d86568 tss = 0x80d86558 Tracing command nginx pid 1061 tid 101747 td 0xf8014b35b500 sched_switch() at 0x804c956d = sched_switch+0x6ad/frame 0xfe2021b70330 mi_switch() at 0x804a8d92 = mi_switch+0xd2/frame 0xfe2021b70360 turnstile_wait() at 0x804ef177 = turnstile_wait+0x2a7/frame 0xfe2021b703a0 __rw_wlock_hard() at 0x8049c314 = __rw_wlock_hard+0x94/frame 0xfe2021b70430 in_lltable_lookup() at 0x80594823 = in_lltable_lookup+0x83/frame 0xfe2021b70450 arpresolve() at 0x8058d2aa = arpresolve+0x9a/frame 0xfe2021b704b0 ether_output() at 0x805755e2 = ether_output+0x2f2/frame 0xfe2021b70550 ip_output() at 0x805a4200 = ip_output+0x1390/frame 0xfe2021b706b0 tcp_output() at 0x806149d5 = tcp_output+0x17a5/frame 0xfe2021b70850 tcp_usr_disconnect() at 0x80620094 = tcp_usr_disconnect+0x74/frame 0xfe2021b70880 soclose() at 0x8051c238 = soclose+0x38/frame 0xfe2021b708b0 _fdrop() at 0x8045639a = _fdrop+0x1a/frame 0xfe2021b708d0 closef() at 0x80458a53 = closef+0x1e3/frame 0xfe2021b70960 closefp() at 0x804567ad = closefp+0x7d/frame 0xfe2021b709a0 amd64_syscall() at 0x806e4051 = amd64_syscall+0x2c1/frame 0xfe2021b70ab0 Xfast_syscall() at 0x806cb2bb = Xfast_syscall+0xfb/frame 0xfe2021b70ab0 --- syscall (6, FreeBSD ELF64, sys_close), rip = 0x8019dbeaa, rsp = 0x7fffe6a8, rbp = 0x7fffe6c0 --- Tracing command nginx pid 1060 tid 101749 td 0xf80126a53a00 sched_switch() at 0x804c956d = sched_switch+0x6ad/frame 0xfe2021b7a240 mi_switch() at 0x804a8d92 = mi_switch+0xd2/frame 0xfe2021b7a270 turnstile_wait() at 0x804ef177 = turnstile_wait+0x2a7/frame 0xfe2021b7a2b0 __rw_wlock_hard() at 0x8049c314 = __rw_wlock_hard+0x94/frame 0xfe2021b7a340 in_lltable_lookup() at 0x80594823 = in_lltable_lookup+0x83/frame 0xfe2
Faça sua Pós-Graduação na Faculdade SENAI Últimos dias
___ freebsd-stable@freebsd.org mailing list https://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to "freebsd-stable-unsubscr...@freebsd.org"
[HEADS-UP] 11.0-RELEASE status update
-BEGIN PGP SIGNED MESSAGE- Hash: SHA256 Dear FreeBSD Community: Although the FreeBSD 11.0-RELEASE has not yet been officially announced, many have found images on the Project FTP mirrors. However, please be aware the final 11.0-RELEASE will be rebuilt and republished on the Project mirrors as a result of a few last-minute security fixes we feel are imperative to include in the final release. FreeBSD users already running 11.0-RELEASE will be given instructions on how to safely upgrade systems to the 11.0-RELEASE-p1 in the final announcement email. Those building from source code can obtain the latest security updates from the releng/11.0 branch in Subversion: svn://svn.freebsd.org/base/releng/11.0 As the FreeBSD Project strives to provide the best possible product, the Release Engineering team decided to build an updated release to include the fixes. At present, we expect to have the final release available Wednesday, October 3rd. If you have not yet downloaded 11.0-RELEASE, please wait for the official release announcement. Thank you in advance for your patience waiting for 11.0-RELEASE, and of course for understanding the reasons behind the updated release. Glen On behalf of: re@ -BEGIN PGP SIGNATURE- Version: GnuPG v2 iQIcBAEBCAAGBQJX7EaGAAoJEAMUWKVHj+KTtrgP/iaIozjqDQ2poH1i7J+BewmE wov+vRcfmGmBvCFLxGPWDsXsYWYw8HCUNrloBesNlUZNe7BoFKliVrBp7KAN5YRE R+l9AQU8u7UhYoKbM1epB28nDYdLH/veKMpkhyEr2mPglmRDJoJa1JL3xcnRXDj+ yFeeCH5He/jH/ILiO8ChfY8e3aA+K/qMOSicVENW5M2kGs/q0m/i5UZK2LZ+gT7R /eMl0USfW2B5LebHViv3a6GRArfTzBYZKYdoxXH7vUZ1zgb9CcEPfhYBxu41RMe3 I+HquvqzWKPNwG3GhwqPmKfwQt4PHlATkZwddGosIgSmUZRhhD4eR0DWdXD6k/oS iSi7QR8lef6ALcVTjt65JNqzPF/9eUJsZikcI0Ov6I0TkV2yzAGnUNneZQ6+22AS //ZhqWkIu7w1hePJ+Af+SZJDzVdUWzVNiAyMmSFkfW3mFaidyhjR0OULnquG6kSS kdPOdl/RwJzfP3wkFjt56I8YTyk7YQdwNEcEBQUlXlyZOC/NvUH5eebPJ1Va5UDV q0FHFaYiATKvQyZUO3Ne9eLzBdYQhmaPSrvTGXrZw53hgShIBOEnwkJYiEGgySL3 vCDro397boLkRL89HUXwuCFurZp/7g/V+I3w4X45y2/GpC/w7isPX/5YYJloETnR VLGBedKpJbR/5LUJH8Bw =t8IC -END PGP SIGNATURE- ___ freebsd-stable@freebsd.org mailing list https://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to "freebsd-stable-unsubscr...@freebsd.org"
[REVISED] [HEADS-UP] 11.0-RELEASE status update
-BEGIN PGP SIGNED MESSAGE- Hash: SHA256 Dear FreeBSD Community: [Corrected the date.] Although the FreeBSD 11.0-RELEASE has not yet been officially announced, many have found images on the Project FTP mirrors. However, please be aware the final 11.0-RELEASE will be rebuilt and republished on the Project mirrors as a result of a few last-minute security fixes we feel are imperative to include in the final release. FreeBSD users already running 11.0-RELEASE will be given instructions on how to safely upgrade systems to the 11.0-RELEASE-p1 in the final announcement email. Those building from source code can obtain the latest security updates from the releng/11.0 branch in Subversion: svn://svn.freebsd.org/base/releng/11.0 As the FreeBSD Project strives to provide the best possible product, the Release Engineering team decided to build an updated release to include the fixes. At present, we expect to have the final release available Wednesday, October 5th. If you have not yet downloaded 11.0-RELEASE, please wait for the official release announcement. Thank you in advance for your patience waiting for 11.0-RELEASE, and of course for understanding the reasons behind the updated release. Glen On behalf of: re@ -BEGIN PGP SIGNATURE- Version: GnuPG v2 iQIcBAEBCAAGBQJX7FPNAAoJEAMUWKVHj+KT2joP/0/0AOYfTbFUgZeEUXlmdfew 7nS31bQrBCXi7dgPicfSavdvDfqi4sgiw2/+HY3MxpfLWFJ/WNGveiwryGSiapkA V3BJ9MCOZb3ZZTbp0JlwbRk1NyGg4ur0S4L6zD+MXuHE95Kts3m/ON8CiGtNUE+1 rzE7Yr10tsU2Zu1Bvtv8rJa9SfLCln8k2FXtG0pxVWO+cK2xo6v84bjOJdExrB4t eXYoMSoxIyZd1Kv2nLbL1mG7RrLQFVm4TrurMwALI39hVr+IWIvElmo6wndDhTly XE8aMtpgUMp9b4PrQM+BgFVooR4ihFl0cslHfDuBGuiVJMQoa63agUfGAkclc9Na nwiJiwcQStOdHcRAnZNBms9DTeNXDD0whq30JoY45kFRI74wjjqP8oNUCUWEd6e8 n1puD2Zr2fqX0NziwtRg3Hy0EHM+9rQTEDtyHCG05sqTncyU7p6tkd49FfndXqaq h/JkHTP1iyQYsq07GZzyhPA04e/i3N8Djwm+WoRgOlSrItJiPQ/FuqKV0cSERvPR XZm3DPPRt04aOFe7XGrl2IHi+J6LZ5uwYEXiHFb+fPQMuROZ+IJC0Wu56HI2LHGL f5wyPiNE1NJIeYLzIgk3UUrENaylsW4/NsgLFj6TW//24ekF2NR+Nk8u7mvoJuXq vcLDdPW7mReqF13WLzh/ =RcJK -END PGP SIGNATURE- ___ freebsd-stable@freebsd.org mailing list https://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to "freebsd-stable-unsubscr...@freebsd.org"
RE: [REVISED] [HEADS-UP] 11.0-RELEASE status update
Will final 11.0-RELEASE include fixes related to broken Hyper-V compatibility? 11.0-RC2, 11.0-RC3 and non-final 11.0-RELEASE failed to install on Hyper-V 2012 R2 with all current updates. storvsc0: on vmbus0 (probe0:blkvsc0:0:0:0): storvsc scsi_status = 2 (probe0:blkvsc0:0:1:1): invalid LUN 1 ... (probe0:blkvsc0:0:0:1): invalid LUN 1 da0 at blkvsc0 bus 0 scbus1 target 0 lun 0 da0: da0 at blkvsc0 bus 0 scbus1 target 0 lun 0 da0: detached Problem documented in PR https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=212721 --- Regards, Alexander ___ freebsd-stable@freebsd.org mailing list https://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to "freebsd-stable-unsubscr...@freebsd.org"
