Summary: | zaptel and wcfxo compile and modprobe on 2.6.10, but don't work. | ||
---|---|---|---|
Product: | Gentoo Linux | Reporter: | Rob Burcham <rob_burcham> |
Component: | Current packages | Assignee: | voip herd (OBSOLETE) <voip+disabled> |
Status: | RESOLVED WONTFIX | ||
Severity: | critical | CC: | sparc |
Priority: | High | ||
Version: | unspecified | ||
Hardware: | Sparc | ||
OS: | Linux | ||
Whiteboard: | |||
Package list: | Runtime testing required: | --- |
Description
Rob Burcham
2005-02-22 07:12:21 UTC
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. |