Re: net-im/skype4 under FreeBSD 10.3
2016-02-16 10:49 GMT+03:00 Pavel Timofeev : > 2016-02-15 15:28 GMT+03:00 Pavel Timofeev : >> >> 15 февр. 2016 г. 14:00 пользователь "Slawa Olhovchenkov" >> написал: >> >> >>> >>> On Mon, Feb 15, 2016 at 12:06:08PM +0300, Pavel Timofeev wrote: >>> >>> > Hi! >>> > Has anybody tried net-im/skype4 under FreeBSD 10.3(-BETA[0-9])?? >>> >>> I am using net-im/skype4 under FreeBSD 10.2-STABLE (after new >>> linuxulator import). >>> Chat and voice work good. >>> >>> > Seems like net-im/skype4 missing some dependencies and if it's >>> > satisfied net-im/skype4 hangs after start. >>> > linprocfs mounting doesn't help. >>> > I installed them all from the ports tree. >>> > Any experience? >>> >>> I am don't see this issue. >> >> Ok, thank you. I'll recheck. > > Well, I've managed to start skype4. > What I did is: > # mkdir -p /compat/linux/proc/ > add linprocfs to /etc/fstab > add linux_enable="YES" to /etc/rc.conf > # reboot > # portmaster /usr/ports/net-im/skype4 > Then I tried to start it and got: > % skype > /usr/local/share/skype/skype: error while loading shared libraries: > libpulse-mainloop-glib.so.0: cannot open shared object file: No such > file or directory > Then I installed missing dependency: > # portmaster /usr/ports/audio/linux-c6-pulseaudio-libs > And tried to start it again: > % skype > /usr/local/share/skype/skype: error while loading shared libraries: > libssl.so.10: cannot open shared object file: No such file or > directory > Installed another missing dependency: > # portmaster /usr/ports/security/linux-c6-openssl > And finally skype could start. > > So there are some missing dependencies. I've created a bug report. > https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=207240 Oh, I noticed that sound stopped working on the front panel of my workstation after I upgraded FreeBSD from 10.2-RELEASE to 10.3-BETA. It works now only if I connect my headphones to the connectors at the back of my workstation. ___ 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: net-im/skype4 under FreeBSD 10.3
On Tue, Feb 16, 2016 at 10:49:01AM +0300, Pavel Timofeev wrote: > 2016-02-15 15:28 GMT+03:00 Pavel Timofeev : > > > > 15 февр. 2016 г. 14:00 пользователь "Slawa Olhovchenkov" > > написал: > > > > > >> > >> On Mon, Feb 15, 2016 at 12:06:08PM +0300, Pavel Timofeev wrote: > >> > >> > Hi! > >> > Has anybody tried net-im/skype4 under FreeBSD 10.3(-BETA[0-9])?? > >> > >> I am using net-im/skype4 under FreeBSD 10.2-STABLE (after new > >> linuxulator import). > >> Chat and voice work good. > >> > >> > Seems like net-im/skype4 missing some dependencies and if it's > >> > satisfied net-im/skype4 hangs after start. > >> > linprocfs mounting doesn't help. > >> > I installed them all from the ports tree. > >> > Any experience? > >> > >> I am don't see this issue. > > > > Ok, thank you. I'll recheck. > > Well, I've managed to start skype4. > What I did is: > # mkdir -p /compat/linux/proc/ > add linprocfs to /etc/fstab > add linux_enable="YES" to /etc/rc.conf > # reboot > # portmaster /usr/ports/net-im/skype4 > Then I tried to start it and got: > % skype > /usr/local/share/skype/skype: error while loading shared libraries: > libpulse-mainloop-glib.so.0: cannot open shared object file: No such > file or directory > Then I installed missing dependency: I am use poudriere build and all dependens present: # pkg info -d skype4 skype4-4.3.0.37,1: linux-skype_oss_wrapper-0.1.1 linux_base-c6-6.6_6 linux-c6-pulseaudio-libs-glib2-0.9.21 linux-c6-qt47-4.7.2_1 linux-c6-qt47-webkit-4.7.2_1 webcamd-4.2.0.9 linux-c6-libv4l-0.6.3_1 linux-c6-xorg-libs-7.4_3 linux-c6-expat-2.0.1_2 linux-c6-openssl-compat-0.9.8e_2 desktop-file-utils-0.22_3 linux-c6-fontconfig-2.8.0_1 linux-c6-qt47-x11-4.7.2_1 > # portmaster /usr/ports/audio/linux-c6-pulseaudio-libs > And tried to start it again: > % skype > /usr/local/share/skype/skype: error while loading shared libraries: > libssl.so.10: cannot open shared object file: No such file or > directory > Installed another missing dependency: > # portmaster /usr/ports/security/linux-c6-openssl > And finally skype could start. > > So there are some missing dependencies. I've created a bug report. > https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=207240 ___ 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: 82576 + NETMAP + VLAN
I am sorry, I did not participate to the implementation of kqueue support and I am not able to comment. Luigi and Adrian should know, however. Cheers, Giuseppe Il 15/02/2016 22:44, Slawa Olhovchenkov ha scritto: On Mon, Feb 15, 2016 at 05:02:36PM +0100, Giuseppe Lettieri wrote: Il 15/02/2016 16:13, Slawa Olhovchenkov ha scritto: On Mon, Feb 15, 2016 at 04:10:30PM +0100, Giuseppe Lettieri wrote: Hi Slawa, I think WITNESS is seeing a false positive, since those two are always different mutexes. The actual deadlock you experience should be caused by something else. I Are you sure? When deadlock occur I am see threads waiting on nm_kn_lock. The deadlock I mentioned still involves nm_kn_locks, sorry if I was not clear about that. I am just saying that we never try to take the same lock that we already holding. Nonetheless, there are indeed problems in the path that WITNESS has seen. The problem is that pipes have to notify the other end while called by kevent. kevent holds the nm_kn_lock on the TX src ring and the notification takes the nm_kn_lock on the RX dst ring. Can you comment other issuses? Is this by design or is this bug? - with kevent sync for transmiting need first register EVFILT_WRITE/EV_DISABLE and after every write EVFILT_WRITE/EV_DISPATCH - with kevent sync all opening /dev/netmap and registering need do from same thread as kevent using for sinc (unless no RX/TX). -- Dr. Ing. Giuseppe Lettieri Dipartimento di Ingegneria della Informazione Universita' di Pisa Largo Lucio Lazzarino 1, 56122 Pisa - Italy Ph. : (+39) 050-2217.649 (direct) .599 (switch) Fax : (+39) 050-2217.600 e-mail: g.letti...@iet.unipi.it ___ 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: 82576 + NETMAP + VLAN
On Tue, Feb 16, 2016 at 11:23:20AM +0100, Giuseppe Lettieri wrote: > I am sorry, I did not participate to the implementation of kqueue > support and I am not able to comment. Luigi and Adrian should know, however. Thanks! > Cheers, > Giuseppe > > Il 15/02/2016 22:44, Slawa Olhovchenkov ha scritto: > > On Mon, Feb 15, 2016 at 05:02:36PM +0100, Giuseppe Lettieri wrote: > > > >> Il 15/02/2016 16:13, Slawa Olhovchenkov ha scritto: > >>> On Mon, Feb 15, 2016 at 04:10:30PM +0100, Giuseppe Lettieri wrote: > >>> > Hi Slawa, > > I think WITNESS is seeing a false positive, since those two are always > different mutexes. > > The actual deadlock you experience should be caused by something else. I > >>> > >>> Are you sure? When deadlock occur I am see threads waiting on nm_kn_lock. > >> > >> The deadlock I mentioned still involves nm_kn_locks, sorry if I was not > >> clear about that. I am just saying that we never try to take the same > >> lock that we already holding. > >> > >> Nonetheless, there are indeed problems in the path that WITNESS has > >> seen. The problem is that pipes have to notify the other end while > >> called by kevent. kevent holds the nm_kn_lock on the TX src ring and the > >> notification takes the nm_kn_lock on the RX dst ring. > > > > Can you comment other issuses? Is this by design or is this bug? > > > > - with kevent sync for transmiting need first register > >EVFILT_WRITE/EV_DISABLE and after every write > >EVFILT_WRITE/EV_DISPATCH > > > > - with kevent sync all opening /dev/netmap and registering need do > >from same thread as kevent using for sinc (unless no RX/TX). > > > > > > > -- > Dr. Ing. Giuseppe Lettieri > Dipartimento di Ingegneria della Informazione > Universita' di Pisa > Largo Lucio Lazzarino 1, 56122 Pisa - Italy > Ph. : (+39) 050-2217.649 (direct) .599 (switch) > Fax : (+39) 050-2217.600 > e-mail: g.letti...@iet.unipi.it ___ 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: 82576 + NETMAP + VLAN
hi, please bug me in a couple weeks. still moving house, etc. -a On 16 February 2016 at 02:30, Slawa Olhovchenkov wrote: > On Tue, Feb 16, 2016 at 11:23:20AM +0100, Giuseppe Lettieri wrote: > >> I am sorry, I did not participate to the implementation of kqueue >> support and I am not able to comment. Luigi and Adrian should know, however. > > Thanks! > >> Cheers, >> Giuseppe >> >> Il 15/02/2016 22:44, Slawa Olhovchenkov ha scritto: >> > On Mon, Feb 15, 2016 at 05:02:36PM +0100, Giuseppe Lettieri wrote: >> > >> >> Il 15/02/2016 16:13, Slawa Olhovchenkov ha scritto: >> >>> On Mon, Feb 15, 2016 at 04:10:30PM +0100, Giuseppe Lettieri wrote: >> >>> >> Hi Slawa, >> >> I think WITNESS is seeing a false positive, since those two are always >> different mutexes. >> >> The actual deadlock you experience should be caused by something else. I >> >>> >> >>> Are you sure? When deadlock occur I am see threads waiting on nm_kn_lock. >> >> >> >> The deadlock I mentioned still involves nm_kn_locks, sorry if I was not >> >> clear about that. I am just saying that we never try to take the same >> >> lock that we already holding. >> >> >> >> Nonetheless, there are indeed problems in the path that WITNESS has >> >> seen. The problem is that pipes have to notify the other end while >> >> called by kevent. kevent holds the nm_kn_lock on the TX src ring and the >> >> notification takes the nm_kn_lock on the RX dst ring. >> > >> > Can you comment other issuses? Is this by design or is this bug? >> > >> > - with kevent sync for transmiting need first register >> >EVFILT_WRITE/EV_DISABLE and after every write >> >EVFILT_WRITE/EV_DISPATCH >> > >> > - with kevent sync all opening /dev/netmap and registering need do >> >from same thread as kevent using for sinc (unless no RX/TX). >> > >> > >> >> >> -- >> Dr. Ing. Giuseppe Lettieri >> Dipartimento di Ingegneria della Informazione >> Universita' di Pisa >> Largo Lucio Lazzarino 1, 56122 Pisa - Italy >> Ph. : (+39) 050-2217.649 (direct) .599 (switch) >> Fax : (+39) 050-2217.600 >> e-mail: g.letti...@iet.unipi.it ___ 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"
7 LOR dumps related to ufs, tmpfs, igmp
Hello all, I'm including below a list of LORs that I experienced running an x86 build of 10.2-RELEASE-p2. Some known LORs are also included for posterity's sake, as all are from a single session and appear in chronological order, should this information be of any additional use. I believe from a bit of hunting around that not all are documented/known-ok. Also, one is repeated below. I thought of submitting a separate email for each, but did not want to clutter the mailing list with needless "spam." Pardon the long lines. Thanks, Mahmoud 1st 0xc6aaa46c ufs (ufs) @ sys/kern/vfs_mount.c:1227 2nd 0xc6aaa5d4 devfs (devfs) @ sys/kern/vfs_subr.c:2285 KDB: stack backtrace: db_trace_self_wrapper(c120a33c,632e7262,3832323a,ca35,db7df750,...) at db_trace_self_wrapper+0x2d/frame 0xdb7df708 kdb_backtrace(c120e109,c6aaa5d4,c11ffba6,c65ae7f0,c1217ba8,...) at kdb_backtrace+0x30/frame 0xdb7df76c witness_checkorder(c6aaa5d4,9,c1217ba8,8ed,c6aaa640,...) at witness_checkorder+0xd4f/frame 0xdb7df7b8 __lockmgr_args(c6aaa5d4,80100,c6aaa640,0,0,0,c1217ba8,8ed) at __lockmgr_args+0x8d4/frame 0xdb7df894 vop_stdlock(db7df908,c1486da8,c16d26e8,8,c1759564,...) at vop_stdlock+0x53/frame 0xdb7df8c4 VOP_LOCK1_APV(c14756ac,db7df908,c0b39b31,c1759554,c14c28c0,...) at VOP_LOCK1_APV+0x10a/frame 0xdb7df8f0 _vn_lock(c6aaa5a0,80100,c1217ba8,8ed,db7df974,...) at _vn_lock+0xca/frame 0xdb7df930 vputx(c6aaa5a0,0,c11faeb6,20e,0,...) at vputx+0x37a/frame 0xdb7df974 cd9660_unmount(c6ed5000,808,db7df9e0,510,c1486da8,...) at cd9660_unmount+0x1dc/frame 0xdb7df9a8 dounmount(c6ed5000,808,c6eab310,48f,db7dfa58,...) at dounmount+0x5fa/frame 0xdb7dfa08 sys_unmount(c6eab310,db7dfb68,c6e9c304,d6,c108d221,...) at sys_unmount+0x3bb/frame 0xdb7dfad8 syscall(db7dfba8) at syscall+0x336/frame 0xdb7dfb9c Xint0x80_syscall() at Xint0x80_syscall+0x21/frame 0xdb7dfb9c --- syscall (22, FreeBSD ELF32, sys_unmount), eip = 0x853d873, esp = 0xbfbfe6d4, ebp = 0xbfbfe7a0 --- lock order reversal: 1st 0xc7d9da0c tmpfs (tmpfs) @ sys/kern/vfs_mount.c:848 2nd 0xc7e9473c ufs (ufs) @ sys/kern/vfs_subr.c:2174 KDB: stack backtrace: db_trace_self_wrapper(c120a33c,3731323a,34000a34,a38,0,...) at db_trace_self_wrapper+0x2d/frame 0xdb7e3578 kdb_backtrace(c120e109,c7e9473c,c11f31cd,c65ae928,c1217ba8,...) at kdb_backtrace+0x30/frame 0xdb7e35dc witness_checkorder(c7e9473c,9,c1217ba8,87e,c7e947a8,...) at witness_checkorder+0xd4f/frame 0xdb7e3628 __lockmgr_args(c7e9473c,80100,c7e947a8,0,0,...) at __lockmgr_args+0x8d4/frame 0xdb7e3708 ffs_lock(db7e3788,c65a6248,c65acb80,c65a6248,c16d10e8,...) at ffs_lock+0x97/frame 0xdb7e3744 VOP_LOCK1_APV(c14ae018,db7e3788,c65a8468,,c14c28c0,...) at VOP_LOCK1_APV+0x10a/frame 0xdb7e3770 _vn_lock(c7e94708,80100,c1217ba8,87e,57,...) at _vn_lock+0xca/frame 0xdb7e37b0 vget(c7e94708,80100,c6daec40,57,0,...) at vget+0x77/frame 0xdb7e37e4 vfs_hash_get(c70025d8,2,8,c6daec40,db7e38a4,...) at vfs_hash_get+0xff/frame 0xdb7e3810 ffs_vgetf(c70025d8,2,8,db7e38a4,0) at ffs_vgetf+0x44/frame 0xdb7e386c ffs_vget(c70025d8,2,8,db7e38a4,c16fe418,...) at ffs_vget+0x2f/frame 0xdb7e388c ufs_root(c70025d8,8,db7e3a90,359,c6f12390,...) at ufs_root+0x49/frame 0xdb7e38b0 vfs_donmount(c6daec40,0,0,c6ea8100,c6ea8100,...) at vfs_donmount+0x13a7/frame 0xdb7e3ab0 sys_nmount(c6daec40,db7e3b68,c6cd2000,d6,e2,...) at sys_nmount+0x78/frame 0xdb7e3ad8 syscall(db7e3ba8) at syscall+0x336/frame 0xdb7e3b9c Xint0x80_syscall() at Xint0x80_syscall+0x21/frame 0xdb7e3b9c --- syscall (378, FreeBSD ELF32, sys_nmount), eip = 0x280dc9eb, esp = 0xbfbfdda0, ebp = 0xbfbfe2f8 --- lock order reversal: 1st 0xc69bba3c if_addr_lock (if_addr_lock) @ sys/netinet/igmp.c:1710 2nd 0xc175d718 ifnet_rw (ifnet_rw) @ sys/net/if.c:244 KDB: stack backtrace: db_trace_self_wrapper(c120a33c,3a632e66,a343432,692f7400,2e706d67,...) at db_trace_self_wrapper+0x2d/frame 0xdab56720 kdb_backtrace(c120e109,c175d718,c121cefe,c65aa960,c121c998,...) at kdb_backtrace+0x30/frame 0xdab56784 witness_checkorder(c175d718,1,c121c998,f4,0,...) at witness_checkorder+0xd4f/frame 0xdab567d0 __rw_rlock(c175d728,c121c998,f4,c771f500,dab568dc,...) at __rw_rlock+0x92/frame 0xdab56858 ifnet_byindex(1,c12454ce,da,c65ab4c0,c26be200,...) at ifnet_byindex+0x23/frame 0xdab56870 igmp_intr(c771f500,c6d95c00,dab56930,c0e06833,c26c3900,...) at igmp_intr+0x1e/frame 0xdab568dc netisr_dispatch_src(2,0,c771f500) at netisr_dispatch_src+0xb6/frame 0xdab5691c netisr_dispatch(2,c771f500,0,89a,dab56978,...) at netisr_dispatch+0x20/frame 0xdab56930 igmp_v1v2_queue_report(c175d8dc,4,c122a604,6e4,c175a310,...) at igmp_v1v2_queue_report+0x1a9/frame 0xdab56978 igmp_fasttimo(dab56a50,c0b3a7cc,c175a300,dab56a50,c0b6421d,...) at igmp_fasttimo+0x417/frame 0xdab56a1c pffasttimo(0,0,c12073f5,285,c0b813be,...) at pffasttimo+0x30/frame 0xdab56a50 softclock_call_cc(0,0,c12073f5,32b,0,...) at softclock_call_cc+0x1ac/frame 0xdab56aec softclock(c175a300,c11fe255,566,78e5b803,c66e5f48,...) at softclock+0x40/frame 0xdab56b0c intr_event_execute_handlers
Re: 7 LOR dumps related to ufs, tmpfs, igmp
Apologies. The mail server is truncating the text. Attached as a TXT. On Tue, Feb 16, 2016 at 7:30 PM, Mahmoud Al-Qudsi wrote: > Hello all, > > I'm including below a list of LORs that I experienced running an x86 > build of 10.2-RELEASE-p2. > > Some known LORs are also included for posterity's sake, as all are from > a single session and appear in chronological order, should this > information be of any additional use. I believe from a bit of hunting around > that not all are documented/known-ok. Also, one is repeated below. > > I thought of submitting a separate email for each, but did not want to > clutter the mailing list with needless "spam." > > Pardon the long lines. > > Thanks, > > Mahmoud > > > 1st 0xc6aaa46c ufs (ufs) @ sys/kern/vfs_mount.c:1227 > 2nd 0xc6aaa5d4 devfs (devfs) @ sys/kern/vfs_subr.c:2285 > KDB: stack backtrace: > db_trace_self_wrapper(c120a33c,632e7262,3832323a,ca35,db7df750,...) > at db_trace_self_wrapper+0x2d/frame 0xdb7df708 > kdb_backtrace(c120e109,c6aaa5d4,c11ffba6,c65ae7f0,c1217ba8,...) at > kdb_backtrace+0x30/frame 0xdb7df76c > witness_checkorder(c6aaa5d4,9,c1217ba8,8ed,c6aaa640,...) at > witness_checkorder+0xd4f/frame 0xdb7df7b8 > __lockmgr_args(c6aaa5d4,80100,c6aaa640,0,0,0,c1217ba8,8ed) at > __lockmgr_args+0x8d4/frame 0xdb7df894 > vop_stdlock(db7df908,c1486da8,c16d26e8,8,c1759564,...) at > vop_stdlock+0x53/frame 0xdb7df8c4 > VOP_LOCK1_APV(c14756ac,db7df908,c0b39b31,c1759554,c14c28c0,...) at > VOP_LOCK1_APV+0x10a/frame 0xdb7df8f0 > _vn_lock(c6aaa5a0,80100,c1217ba8,8ed,db7df974,...) at > _vn_lock+0xca/frame 0xdb7df930 > vputx(c6aaa5a0,0,c11faeb6,20e,0,...) at vputx+0x37a/frame 0xdb7df974 > cd9660_unmount(c6ed5000,808,db7df9e0,510,c1486da8,...) at > cd9660_unmount+0x1dc/frame 0xdb7df9a8 > dounmount(c6ed5000,808,c6eab310,48f,db7dfa58,...) at > dounmount+0x5fa/frame 0xdb7dfa08 > sys_unmount(c6eab310,db7dfb68,c6e9c304,d6,c108d221,...) at > sys_unmount+0x3bb/frame 0xdb7dfad8 > syscall(db7dfba8) at syscall+0x336/frame 0xdb7dfb9c > Xint0x80_syscall() at Xint0x80_syscall+0x21/frame 0xdb7dfb9c > --- syscall (22, FreeBSD ELF32, sys_unmount), eip = 0x853d873, esp = > 0xbfbfe6d4, ebp = 0xbfbfe7a0 --- > > > lock order reversal: > 1st 0xc7d9da0c tmpfs (tmpfs) @ sys/kern/vfs_mount.c:848 > 2nd 0xc7e9473c ufs (ufs) @ sys/kern/vfs_subr.c:2174 > KDB: stack backtrace: > db_trace_self_wrapper(c120a33c,3731323a,34000a34,a38,0,...) at > db_trace_self_wrapper+0x2d/frame 0xdb7e3578 > kdb_backtrace(c120e109,c7e9473c,c11f31cd,c65ae928,c1217ba8,...) at > kdb_backtrace+0x30/frame 0xdb7e35dc > witness_checkorder(c7e9473c,9,c1217ba8,87e,c7e947a8,...) at > witness_checkorder+0xd4f/frame 0xdb7e3628 > __lockmgr_args(c7e9473c,80100,c7e947a8,0,0,...) at > __lockmgr_args+0x8d4/frame 0xdb7e3708 > ffs_lock(db7e3788,c65a6248,c65acb80,c65a6248,c16d10e8,...) at > ffs_lock+0x97/frame 0xdb7e3744 > VOP_LOCK1_APV(c14ae018,db7e3788,c65a8468,,c14c28c0,...) at > VOP_LOCK1_APV+0x10a/frame 0xdb7e3770 > _vn_lock(c7e94708,80100,c1217ba8,87e,57,...) at _vn_lock+0xca/frame 0xdb7e37b0 > vget(c7e94708,80100,c6daec40,57,0,...) at vget+0x77/frame 0xdb7e37e4 > vfs_hash_get(c70025d8,2,8,c6daec40,db7e38a4,...) at > vfs_hash_get+0xff/frame 0xdb7e3810 > ffs_vgetf(c70025d8,2,8,db7e38a4,0) at ffs_vgetf+0x44/frame 0xdb7e386c > ffs_vget(c70025d8,2,8,db7e38a4,c16fe418,...) at > ffs_vget+0x2f/frame 0xdb7e388c > ufs_root(c70025d8,8,db7e3a90,359,c6f12390,...) at > ufs_root+0x49/frame 0xdb7e38b0 > vfs_donmount(c6daec40,0,0,c6ea8100,c6ea8100,...) at > vfs_donmount+0x13a7/frame 0xdb7e3ab0 > sys_nmount(c6daec40,db7e3b68,c6cd2000,d6,e2,...) at > sys_nmount+0x78/frame 0xdb7e3ad8 > syscall(db7e3ba8) at syscall+0x336/frame 0xdb7e3b9c > Xint0x80_syscall() at Xint0x80_syscall+0x21/frame 0xdb7e3b9c > --- syscall (378, FreeBSD ELF32, sys_nmount), eip = 0x280dc9eb, esp = > 0xbfbfdda0, ebp = 0xbfbfe2f8 --- > > > > lock order reversal: > 1st 0xc69bba3c if_addr_lock (if_addr_lock) @ sys/netinet/igmp.c:1710 > 2nd 0xc175d718 ifnet_rw (ifnet_rw) @ sys/net/if.c:244 > KDB: stack backtrace: > db_trace_self_wrapper(c120a33c,3a632e66,a343432,692f7400,2e706d67,...) > at db_trace_self_wrapper+0x2d/frame 0xdab56720 > kdb_backtrace(c120e109,c175d718,c121cefe,c65aa960,c121c998,...) at > kdb_backtrace+0x30/frame 0xdab56784 > witness_checkorder(c175d718,1,c121c998,f4,0,...) at > witness_checkorder+0xd4f/frame 0xdab567d0 > __rw_rlock(c175d728,c121c998,f4,c771f500,dab568dc,...) at > __rw_rlock+0x92/frame 0xdab56858 > ifnet_byindex(1,c12454ce,da,c65ab4c0,c26be200,...) at > ifnet_byindex+0x23/frame 0xdab56870 > igmp_intr(c771f500,c6d95c00,dab56930,c0e06833,c26c3900,...) at > igmp_intr+0x1e/frame 0xdab568dc > netisr_dispatch_src(2,0,c771f500) at netisr_dispatch_src+0xb6/frame 0xdab5691c > netisr_dispatch(2,c771f500,0,89a,dab56978,...) at > netisr_dispatch+0x20/frame 0xdab56930 > igmp_v1v2_queue_report(c175d8dc,4,c122a604,6e4,c175a310,...) at > igmp_v1v2_queue_report+0x1a9/frame 0xdab56978 > igmp_fasttimo(dab56a50,c0b3a7cc,c175a300,dab56a50,c0
