Dtrace: Module is no longer loaded
Hi, I am running FreeBSD current on RouterStation Pro (Mips) using nfs. I followed the handbook about how to compile for Dtrace support. and kldload dtraceall succeeded. But when I tried to run: dtrace -n 'syscall:::' I got error message saying: 'dtrace: invalid probe specifier syscall /usr/lib/dtrace/psinfo.d, line 88: failed to resolve type kernel`struct thread * for identifier curthread: Module is no longer loaded' I even tried to run some scripts I found here http://wiki.freebsd.org/DTrace/Examples but got same error. What am I missing? kldstat shows: Id Refs AddressSize Name 1 24 0x8005 64fc60 kernel 101 0xcdd9b000 a03 dtraceall.ko 111 0xce2b2000 54d3 profile.ko 12 10 0xce2b8000 4621 opensolaris.ko 133 0xce2bd000 4a3c cyclic.ko 148 0xce2c2000 138cfc dtrace.ko 151 0xce3fb000 15ff4systrace.ko 161 0xce411000 4a95 sdt.ko 171 0xce416000 4c2b lockstat.ko 181 0xce41b000 54f0 dtnfsclient.ko 191 0xce421000 49d7 dtmalloc.ko 201 0xce426000 49e1 dtio.ko uname -a: FreeBSD MESHGATE-12 10.0-CURRENT FreeBSD 10.0-CURRENT #7: Fri Oct 26 13:20:29 CEST 2012 root@challenger:/usr/obj/mips.mips/usr/src/sys/RSPRO_NFS mips FreeBSD head r238604. thank you, -- Monthadar Al Jaberi ___ freebsd-current@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to freebsd-current-unsubscr...@freebsd.org
Re: Dtrace: Module is no longer loaded
You didn't build with WITH_CTF=1 ___ freebsd-current@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to freebsd-current-unsubscr...@freebsd.org
Re: Dtrace: Module is no longer loaded
On Mon, Oct 29, 2012 at 2:10 PM, Ryan Stone ryst...@gmail.com wrote: You didn't build with WITH_CTF=1 Yes I did, sorry forgot to attach kernel config. # # Ubiquiti Routerstation Pro: boot from NFS # # $FreeBSD$ # include AR71XX_BASE ident RSPRO_NFS hints RSPRO.hints makeoptions MODULES_OVERRIDE+=opensolaris dtrace cyclic dtrace/dtnfsclient dtrace/dtnfscl dtrace/lockstat dtrace/profile makeoptions WITH_CTF=1 options KDTRACE_HOOKS # all architectures - enable general DTrace hooks options DDB_CTF # all architectures - kernel ELF linker loads CTF data #optionsNFSCL #Network Filesystem Client # RTC - requires hackery in the spibus code to work device pcf2123_rtc # GEOM modules device geom_redboot# to get access to the SPI flash partitions device geom_uzip # compressed in-memory filesystem hackery! options GEOM_UZIP # Boot from NFS options NFSLOCKD#Network Lock Manager options NFSCLIENT #Network Filesystem Client options NFS_ROOT options BOOTP options BOOTP_NFSROOT options BOOTP_NFSV3 options BOOTP_WIRED_TO=arge0 options BOOTP_COMPAT options ROOTDEVNAME=\nfs:172.16.1.101:/usr/obj/rspro/nfs\ -- Monthadar Al Jaberi ___ freebsd-current@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to freebsd-current-unsubscr...@freebsd.org
Re: Dtrace: Module is no longer loaded
on 29/10/2012 16:40 Monthadar Al Jaberi said the following: On Mon, Oct 29, 2012 at 2:10 PM, Ryan Stone ryst...@gmail.com wrote: You didn't build with WITH_CTF=1 Yes I did, sorry forgot to attach kernel config. What about -g ? http://wiki.freebsd.org/DTrace # # Ubiquiti Routerstation Pro: boot from NFS # # $FreeBSD$ # include AR71XX_BASE ident RSPRO_NFS hints RSPRO.hints makeoptions MODULES_OVERRIDE+=opensolaris dtrace cyclic dtrace/dtnfsclient dtrace/dtnfscl dtrace/lockstat dtrace/profile makeoptions WITH_CTF=1 options KDTRACE_HOOKS # all architectures - enable general DTrace hooks options DDB_CTF # all architectures - kernel ELF linker loads CTF data #options NFSCL #Network Filesystem Client # RTC - requires hackery in the spibus code to work devicepcf2123_rtc # GEOM modules devicegeom_redboot# to get access to the SPI flash partitions devicegeom_uzip # compressed in-memory filesystem hackery! options GEOM_UZIP # Boot from NFS options NFSLOCKD#Network Lock Manager options NFSCLIENT #Network Filesystem Client options NFS_ROOT options BOOTP options BOOTP_NFSROOT options BOOTP_NFSV3 options BOOTP_WIRED_TO=arge0 options BOOTP_COMPAT options ROOTDEVNAME=\nfs:172.16.1.101:/usr/obj/rspro/nfs\ -- Andriy Gapon ___ freebsd-current@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to freebsd-current-unsubscr...@freebsd.org
Re: Dtrace: Module is no longer loaded
-g is included in the base file AR71XX_BASE which I have not changed. The error message seems cryptic to me, which module it is talking about that is not loaded? Attaching base file: # # AR71XX -- Kernel configuration file for FreeBSD/MIPS for Atheros 71xx systems # # This includes all the common drivers for the AR71XX boards along with # the usb, net80211 and atheros driver code. # # $FreeBSD$ # machine mips mips ident AR71XX_BASE cpu CPU_MIPS4KC makeoptions KERNLOADADDR=0x8005 options HZ=1000 options HWPMC_HOOKS files ../atheros/files.ar71xx # For now, hints are per-board. hints AR71XX_BASE.hints makeoptions DEBUG=-g#Build kernel with gdb(1) debug symbols # Build these as modules so small platform builds will have the # modules already built. makeoptions MODULES_OVERRIDE=random gpio ar71xx if_gif if_gre if_bridge bridgestp usb wlan wlan_xauth wlan_acl wlan_wep wlan_tkip wlan_ccmp wlan_rssadapt wlan_amrr ath ath_pci options DDB options KDB options SCHED_4BSD #4BSD scheduler options INET#InterNETworking options INET6 # IPv6 # options NFS_CL #Network Filesystem Client options PSEUDOFS#Pseudo-filesystem framework options _KPOSIX_PRIORITY_SCHEDULING #Posix P1003_1B real-time extensions # options NFS_LEGACYRPC # Debugging for use in -current options INVARIANTS options INVARIANT_SUPPORT options WITNESS options WITNESS_SKIPSPIN options DEBUG_REDZONE options DEBUG_MEMGUARD options FFS #Berkeley Fast Filesystem # options SOFTUPDATES #Enable FFS soft updates support # options UFS_ACL #Support for access control lists # options UFS_DIRHASH #Improve performance on big directories # options MSDOSFS # Read MSDOS filesystems; useful for USB/CF device pci device ar71xx_pci # 802.11 framework options IEEE80211_DEBUG options IEEE80211_ALQ options IEEE80211_SUPPORT_MESH # This option is currently broken for if_ath_tx. options IEEE80211_SUPPORT_TDMA options IEEE80211_AMPDU_AGE device wlan# 802.11 support device wlan_wep# 802.11 WEP support device wlan_ccmp # 802.11 CCMP support device wlan_tkip # 802.11 TKIP support device wlan_xauth # 802.11 hostap support device wlan_acl# 802.11 ACL support # Atheros wireless NICs device ath # Atheros interface support device ath_pci # Atheros PCI/Cardbus bus options ATH_DEBUG options ATH_DIAGAPI options ATH_ENABLE_11N options AH_DEBUG options AH_DEBUG_ALQ options ALQ device ath_hal option AH_SUPPORT_AR5416 device ath_rate_sample option AH_RXCFG_SDMAMW_4BYTES option AH_AR5416_INTERRUPT_MITIGATION # There's no DFS radar detection support yet so this won't actually # detect radars. It however does enable the rest of the channel change # machinery so DFS can be debugged. option ATH_ENABLE_DFS device mii device arge device usb options USB_EHCI_BIG_ENDIAN_DESC# handle big-endian byte order options USB_DEBUG options USB_HOST_ALIGN=32 # AR71XX (MIPS in general?) requires this device ehci device scbus device umass device da # On-board SPI flash device spibus device ar71xx_spi device mx25l device ar71xx_wdog device uart device loop device ether device md device bpf device random device if_bridge device gif # ip[46] in ip[46] tunneling protocol device gre # generic encapsulation - only for IPv4 in IPv4 though atm options ARGE_DEBUG # Enable if_arge debugging for now # Enable GPIO device gpio device gpioled On Mon, Oct 29, 2012 at 3:55 PM, Andriy Gapon a...@freebsd.org wrote: on 29/10/2012 16:40 Monthadar Al Jaberi said the following: On Mon, Oct 29, 2012 at 2:10 PM, Ryan Stone ryst...@gmail.com wrote: You didn't build with WITH_CTF=1 Yes I did, sorry forgot to attach kernel config. What about -g ? http://wiki.freebsd.org/DTrace # # Ubiquiti Routerstation Pro: boot from NFS # # $FreeBSD$ # include AR71XX_BASE ident RSPRO_NFS hints RSPRO.hints makeoptions MODULES_OVERRIDE+=opensolaris dtrace cyclic dtrace/dtnfsclient dtrace/dtnfscl dtrace/lockstat dtrace/profile makeoptions WITH_CTF=1 options KDTRACE_HOOKS # all
Interfaces connected by bridge(4) do not pass arp replies
With 2 interfaces present on a bridge0, an arp request is send from msk0 and is received by a machine on em0. When a reply to that arp request is sent by a machine on em0 it is not visible on the bridge0 nor on msk0 as indicated by tcpdump. The arp reply is visible while watching em0 with tcpdump. This behaviour is also true when arp requests are sent from a wlan interface ath0 and received on a wired interface, the arp reply is visible on the wired interface but not visible monitoring with 'tcpdump -i bridge0 arp'. The machine running the em0, msk0 and ath0 interfaces and bridge0 can receive arp requests from any interface and the arp replies are received fine from the machine by the arp requester -err requestor. Any help is greatly appreciated. thanks -kim ___ freebsd-current@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to freebsd-current-unsubscr...@freebsd.org
Re: Interfaces connected by bridge(4) do not pass arp replies
On Mon, Oct 29, 2012 at 8:46 PM, Kim Culhan w8hd...@gmail.com wrote: With 2 interfaces present on a bridge0, an arp request is send from msk0 and is received by a machine on em0. When a reply to that arp request is sent by a machine on em0 it is not visible on the bridge0 nor on msk0 as indicated by tcpdump. The arp reply is visible while watching em0 with tcpdump. Is em0 set in promisc mode? This behaviour is also true when arp requests are sent from a wlan interface ath0 and received on a wired interface, the arp reply is visible on the wired interface but not visible monitoring with 'tcpdump -i bridge0 arp'. Hmm, I am briding between ath0 and wired (arge0). Can you provide more info? what is your rc.conf? How does it set the interfaces? Can you give ifconfig output? The are reply that you dont see on bridge0 can you dump it from wired interface? The machine running the em0, msk0 and ath0 interfaces and bridge0 can receive arp requests from any interface and the arp replies are received fine from the machine by the arp requester -err requestor. Any help is greatly appreciated. thanks -kim ___ freebsd-current@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to freebsd-current-unsubscr...@freebsd.org -- Monthadar Al Jaberi ___ freebsd-current@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to freebsd-current-unsubscr...@freebsd.org
Re: Interfaces connected by bridge(4) do not pass arp replies
On Mon, Oct 29, 2012 at 3:59 PM, Monthadar Al Jaberi montha...@gmail.com wrote: On Mon, Oct 29, 2012 at 8:46 PM, Kim Culhan w8hd...@gmail.com wrote: With 2 interfaces present on a bridge0, an arp request is send from msk0 and is received by a machine on em0. When a reply to that arp request is sent by a machine on em0 it is not visible on the bridge0 nor on msk0 as indicated by tcpdump. The arp reply is visible while watching em0 with tcpdump. Is em0 set in promisc mode? This behaviour is also true when arp requests are sent from a wlan interface ath0 and received on a wired interface, the arp reply is visible on the wired interface but not visible monitoring with 'tcpdump -i bridge0 arp'. Hmm, I am briding between ath0 and wired (arge0). Can you provide more info? what is your rc.conf? How does it set the interfaces? Can you give ifconfig output? The are reply that you dont see on bridge0 can you dump it from wired interface? What svn revision of FreeBSD -current are you running? The machine running the em0, msk0 and ath0 interfaces and bridge0 can receive arp requests from any interface and the arp replies are received fine from the machine by the arp requester -err requestor. Any help is greatly appreciated. thanks -kim ___ freebsd-current@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to freebsd-current-unsubscr...@freebsd.org -- Monthadar Al Jaberi ___ freebsd-current@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to freebsd-current-unsubscr...@freebsd.org
Re: Interfaces connected by bridge(4) do not pass arp replies
On Mon, Oct 29, 2012 at 9:55 PM, Kim Culhan w8hd...@gmail.com wrote: On Mon, Oct 29, 2012 at 3:59 PM, Monthadar Al Jaberi montha...@gmail.com wrote: On Mon, Oct 29, 2012 at 8:46 PM, Kim Culhan w8hd...@gmail.com wrote: With 2 interfaces present on a bridge0, an arp request is send from msk0 and is received by a machine on em0. When a reply to that arp request is sent by a machine on em0 it is not visible on the bridge0 nor on msk0 as indicated by tcpdump. The arp reply is visible while watching em0 with tcpdump. Is em0 set in promisc mode? This behaviour is also true when arp requests are sent from a wlan interface ath0 and received on a wired interface, the arp reply is visible on the wired interface but not visible monitoring with 'tcpdump -i bridge0 arp'. Hmm, I am briding between ath0 and wired (arge0). Can you provide more info? what is your rc.conf? How does it set the interfaces? Can you give ifconfig output? The are reply that you dont see on bridge0 can you dump it from wired interface? What svn revision of FreeBSD -current are you running? FreeBSD head r238604. The machine running the em0, msk0 and ath0 interfaces and bridge0 can receive arp requests from any interface and the arp replies are received fine from the machine by the arp requester -err requestor. Any help is greatly appreciated. thanks -kim ___ freebsd-current@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to freebsd-current-unsubscr...@freebsd.org -- Monthadar Al Jaberi -- Monthadar Al Jaberi ___ freebsd-current@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to freebsd-current-unsubscr...@freebsd.org
Re: Interfaces connected by bridge(4) do not pass arp replies
On Mon, Oct 29, 2012 at 5:17 PM, Monthadar Al Jaberi montha...@gmail.com wrote: On Mon, Oct 29, 2012 at 9:55 PM, Kim Culhan w8hd...@gmail.com wrote: On Mon, Oct 29, 2012 at 3:59 PM, Monthadar Al Jaberi montha...@gmail.com wrote: On Mon, Oct 29, 2012 at 8:46 PM, Kim Culhan w8hd...@gmail.com wrote: With 2 interfaces present on a bridge0, an arp request is send from msk0 and is received by a machine on em0. When a reply to that arp request is sent by a machine on em0 it is not visible on the bridge0 nor on msk0 as indicated by tcpdump. The arp reply is visible while watching em0 with tcpdump. Is em0 set in promisc mode? This behaviour is also true when arp requests are sent from a wlan interface ath0 and received on a wired interface, the arp reply is visible on the wired interface but not visible monitoring with 'tcpdump -i bridge0 arp'. Hmm, I am briding between ath0 and wired (arge0). Can you provide more info? what is your rc.conf? How does it set the interfaces? Can you give ifconfig output? The are reply that you dont see on bridge0 can you dump it from wired interface? What svn revision of FreeBSD -current are you running? FreeBSD head r238604. I should have mentioned earlier this is with r242126, there have been some changes to the network code since 238604, maybe that is why you don't have this problem. -kim ___ freebsd-current@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to freebsd-current-unsubscr...@freebsd.org
