On 2004.06.11 11:41 Steven Critchfield wrote:
You next step really would to be to go looking through the module load function and maybe through some debugging code in there to have it tell you more about what is going on. Luckily enough, if you didn't crash the machine with your module, you can probably load and unload safely until you break something in the module. This is one of those nice things about linux drivers from a developer stand point.
It turns out that the Linux serial driver had claimed the modem device, and thus the wcfxo module was unable to use it. Once I disabled the Linux serial driver (for testing, not a permanent solution, of course) then the wcfxo module was able to "pick it up". The module load still failed, however:
Zapata Telephony Interface Registered on major 196
Setting hook state to 0 (08)
Registered Span 1 ('WCFXO/0') with 1 channels
Span ('WCFXO/0') is new master
wcfxo: Out of space to write register 06 with e0
wcfxo: Out of space to write register 0f with 00
Failed to initailize DAA, giving up...
Unregistering Span 'WCFXO/0' with 1 channels
Zapata Telephony Interface UnloadedDigging through more archives I see that someone else has gotten this far, also:
http://lists.digium.com/pipermail/asterisk-users/2004-February/035818.html
Following the comments on:
http://www.digium.com/index.php?menu=faq#Errors_1
... this person assumed that the failure was due to the IRQ being shared between devices. However, in my case the device had its own IRQ. Reading through more archives, I see that the general reason for those "Out of space to write register" errors is due to interrupt problems, and the general advise has been to change PCI slots. So I tried this. Depending on the presense of other PCI devices in the system as well as their configuration in the PCI slots, I would either get the outcome described above, or worse, I would get:
Zapata Telephony Interface Registered on major 196
Setting hook state to 0 (08)
Registered Span 1 ('WCFXO/0') with 1 channels
Span ('WCFXO/0') is new master
Unexpected IRQ trap at vector c8
Unexpected IRQ trap at vector ad... and then the system locks so that it requires a power-cycle/reset. IRQs were never shared in any configuration.
So, at this point I have satisfied my curiosity, and I'm going to conclude that the wcfxo driver incompatibility with the Intel 537EP chipset is not merely a problem with PCI device IDs, but also that there is some deeper incompatibility. If anyone is interested in taking this farther, or if my conclusions are incorrect, just let me know, I'll be happy to entertain the experience.
Thanks.
Lee. _______________________________________________ Asterisk-Users mailing list [EMAIL PROTECTED] http://lists.digium.com/mailman/listinfo/asterisk-users To UNSUBSCRIBE or update options visit: http://lists.digium.com/mailman/listinfo/asterisk-users
