I have an Ultra-60 running Gentoo with 2.6.10 and udev. I built * 1.0.5 and have been enjoying various SIP configurations, with 2 sipura phones and 2 UIP200 phones in my home, bridging in FWD and now Voiptalk too. I bought 2 X100P clones via ebay, and put one in my U60. I can see it with lspci: 0001:00:02.0 Communication controller: Tiger Jet Network Inc. Tiger3XX Modem/ISDN interface I successfully emerged zaptel, and can modprobe zaptel and wcfxo: # lsmod Module Size Used by wcfxo 14680 0 zaptel 195424 1 wcfxo crc_ccitt 2752 1 zaptel However I can't ztcfg with any success: # ztcfg -v Zaptel Configuration ====================== 1 channels configured. ZT_CHANCONFIG failed on channel 1: Invalid argument (22) Did you forget that FXS interfaces are configured with FXO signalling and that FXO interfaces use FXS signalling? In fact dmesg never shows wcfxo completely setting up the card: # dmesg <snip> Zapata Telephony Interface Registered on major 196 wcfxo: DAA mode is 'FCC' Found a Wildcard FXO: Generic Clone PCI Target abort PCI Target abort PCI Target abort Also, strange things happen while the driver is loaded too... consoles dropping, processes dying, etc. I have tried experimenting with the zaptel and wcfxo modules loaded with debug option turned on, and I get the following in /var/log/messages: # modprobe zaptel Feb 21 22:39:37 boasparc4 kernel: Zapata Telephony Interface Registered on major 196 # modprobe wcfxo Feb 21 22:39:49 boasparc4 kernel: Setting hook state to 0 (08) Feb 21 22:39:49 boasparc4 kernel: Registered Span 1 ('WCFXO/0') with 1 channels Feb 21 22:39:49 boasparc4 kernel: Span ('WCFXO/0') is new master Feb 21 22:39:49 boasparc4 kernel: New regoffset: 7 Feb 21 22:39:49 boasparc4 kernel: wcfxo: DAA mode is 'FCC' Feb 21 22:39:49 boasparc4 kernel: Found a Wildcard FXO: Generic Clone Feb 21 22:39:49 boasparc4 kernel: BATTERY! Feb 21 22:40:13 boasparc4 kernel: wcfxo_interrupt: PCI Target abort Feb 21 22:40:17 boasparc4 kernel: wcfxo_interrupt: PCI Target abort # ztcfg -v Feb 21 22:40:19 boasparc4 kernel: ioctl32(ztcfg:11904): Unknown cmd fd(3) cmd(803c4a13){00} arg(0003a278) on /dev/zap/ctl Feb 21 22:41:21 boasparc4 kernel: wcfxo_interrupt: FXO PCI Master abort # rmmod wcfxo Feb 21 22:43:08 boasparc4 kernel: Unregistering Span 'WCFXO/0' with 1 channels Feb 21 22:43:08 boasparc4 kernel: Freed a Wildcard #rmmod zaptel Feb 21 22:43:17 boasparc4 kernel: Zapata Telephony Interface Unloaded Reproducible: Always Steps to Reproduce: 1. emerge zaptel 2. modprobe zaptel 3. modprobe wcfxo 4. ztcfg -v Actual Results: ztcf failes to set up the card, ZT_CHANCONFIG failed on channel 1: Invalid argument (22) and system behaves erratically until modules are unloaded. Expected Results: # ztcfg -v Zaptel Configuration ====================== Channel map: Channel 01: FXS Kewlstart (Default) (Slaves: 01) 1 channel configured. I am told that folks in #asterisk have zaptel functioning on solaris-sparc, if it is any help. I am using udev version 051. # emerge info Portage 2.0.51-r15 (default-linux/sparc/sparc64/2004.3, gcc-3.3.5, glibc-2.3.3.20040420-r2, 2.6.10-gentoo-r6 sparc64) ================================================================= System uname: 2.6.10-gentoo-r6 sparc64 sun4u Gentoo Base System version 1.6.9 Python: dev-lang/python-2.2.3-r5,dev-lang/python-2.3.4-r1 [2.3.4 (#1, Feb 7 2005, 13:51:33)] ccache version 2.3 [enabled] dev-lang/python: 2.2.3-r5, 2.3.4-r1 sys-devel/autoconf: 2.59-r6, 2.13 sys-devel/automake: 1.5, 1.6.3, 1.7.9-r1, 1.4_p6, 1.9.4, 1.8.5-r3 sys-devel/binutils: 2.15.92.0.2-r2 sys-devel/libtool: 1.5.10-r4 virtual/os-headers: 2.4.19-r1, 2.4.23 ACCEPT_KEYWORDS="sparc ~sparc" AUTOCLEAN="yes" CFLAGS="-mcpu=ultrasparc -O3 -pipe" CHOST="sparc-unknown-linux-gnu" CONFIG_PROTECT="/etc /usr/X11R6/lib/X11/xkb /usr/kde/2/share/config /usr/kde/3.1/share/config /usr/kde/3/share/config /usr/share/config /var/qmail/control" CONFIG_PROTECT_MASK="/etc/gconf /etc/terminfo /etc/env.d" CXXFLAGS="-mcpu=ultrasparc -O3 -pipe" DISTDIR="/usr/portage/distfiles" FEATURES="autoaddcvs autoconfig ccache distlocks sandbox" GENTOO_MIRRORS="http://distfiles.gentoo.org http://distro.ibiblio.org/pub/Linux/distributions/gentoo" MAKEOPTS="-j2" PKGDIR="/usr/portage/packages" PORTAGE_TMPDIR="/var/tmp" PORTDIR="/usr/portage" SYNC="rsync://rsync.gentoo.org/gentoo-portage" USE="sparc apache2 arts avi berkdb bitmap-fonts crypt dlloader encode esd f77 fam fbcon font-server foomaticdb fortran gcc64 gdbm gif gtk2 guile imap imlib java jpeg junit libwww mad mcal mikmod motif mpeg mysql ncurses nls oggvorbis opengl oss pam pdflib perl png postgres python readline sdl slang spell ssl tcltk tcpd tiff truetype truetype-fonts type1-fonts xml xml2 xmms xv zlib" Unset: ASFLAGS, CBUILD, CTARGET, LANG, LC_ALL, LDFLAGS, PORTDIR_OVERLAY
That's the reason the zaptel USE flag is masked for sparc, and net-misc/zaptel isn't even keyworded ~sparc. I can go keyword zaptel -sparc too, but it is possible at some point upstream will fix it or i'll do it when i have time in my hands, but for the moment it's not supposed to work. I don't envision getting time to look into this for at least a couple of months, and i lack a machine with available pci slots to test it, so for the time being it's a WONTFIX.
>ZT_CHANCONFIG failed on channel 1: Invalid argument (22) >Did you forget that FXS interfaces are configured with FXO signalling and that >FXO interfaces use FXS signalling? that's a configuration issue, see http://www.voip-info.org/tiki-index.php?page=Asterisk%20config%20zaptel.conf for more information
Thanks, it's not a config issue... the "PCI Target abort" should be the first clue there. Gustavo Zacarias is right, I did try to push the envelope and test the waters to see if the zaptel on sparc has progressed any further. It would seem that there remains some work to be done. I just wanted to see if I could help. September of last year, the modules would not even load on an Ultra. Now they do. I am sure this is a "so close and yet so far" kind of issue. But it must be prioritized as the developers see fit, and that is the way it must be.
If you wanna dig around first look at ioctl issues, since it's the area more likely affected with the kernel being 64 bit and userland 32 bit. Note also that zaptel should also build against a 2.4 kernel, which is our currently considered stable on sparc (specially on SMP where 2.6 dies a horrible death most of the time). We accept patches, i'm sure upstream also does :)
This, no doubt, is the problem. Rebooting with "nosmp" eliminates the instability introduced by accessing the modules. However as you surmised, the ioctl32 calls from ztcfg are failing on the driver: Feb 22 12:18:14 boasparc4 kernel: ioctl32(ztcfg:7616): Unknown cmd fd(3) cmd(803c4a13){00} arg(0003a278) on /dev/zap/ctl Mainly due to: # file /lib/modules/2.6.10-gentoo-r6/misc/zaptel.ko /lib/modules/2.6.10-gentoo-r6/misc/zaptel.ko: ELF 64-bit MSB relocatable, SPARC V9, version 1 (SYSV), not stripped # file /lib/modules/2.6.10-gentoo-r6/misc/wcfxo.ko /lib/modules/2.6.10-gentoo-r6/misc/wcfxo.ko: ELF 64-bit MSB relocatable, SPARC V9, version 1 (SYSV), not stripped While in userspace: # file /sbin/ztcfg /sbin/ztcfg: ELF 32-bit MSB executable, SPARC32PLUS, V8+ Required, version 1 (SYSV), for GNU/Linux 2.4.1, dynamically linked (uses shared libs), stripped For that matter, # file /usr/sbin/asterisk /usr/sbin/asterisk: ELF 32-bit MSB executable, SPARC32PLUS, V8+ Required, version 1 (SYSV), for GNU/Linux 2.4.1, dynamically linked (uses shared libs), stripped Does a solution have to involve building a V9 userspace program?
You could try doing an ioctl32 compat call like alsa does, or prod eradicator about multilib on sparc which would be an easier & nicer way to solve it.
