Patrick,
The keyword to remain when the problem becomes complex is
simplification. Although there is an IRQ conflict between the sound
driver and 536EP driver on my computer, if I do not activate the sound
while testing the 536EP driver, I now incur no observable problem with
both the small test program and efax. I may test wvdial but this should
inevitably lead me to a NO CARRIER behavior as I no longer subscribe to
a phone line having switched to VoIP.
As the problem involves a driver, in a first approach, perform an lsmod
than you output to a text file for eventual later control. Then rmmod
all the drivers running on your computer which are unneeded for the
problem. At first glance, you should only keep a video, mouse, and
keyboard driver all used by the X server, likely as well an IP stack
related drivers and of course the 537 driver.
For the software, you only need the test program in a first approach.
Attempt to reproduce the problem with all the Intel's driver code you
downloaded from my Web site (with the "_bh" string back in
coredrv/locks.c) and the C source driver's code I last mailed you. If
you execute the test code several times quickly do you still incur the
problem ? Do you observe a computer freeze like I did during my testing.
Is the Call trace identical or different than the efax Call trace you
sent me. If different, check more closely your PC hardware.
If you no longer generate any Call trace with the test program, recheck
with the efax command I suggest on my Web site and that I mailed you. If
efax reacts normally when no phone call dialing in, then still in the
very same simple drivers environment, test a real wvdial. Is it reacting
as expected ? When it dials your Internet provider phone number, take up
the phone receiver and listen to the noise wvdial produces. Is the sound
you hear expected from a modem software ?
When and if all tests succeed without any obvious symptom proving a
badly executing software, you may then complexify step by step . For
this, you reinject using modprobe one driver at a time you rmmod and
perform again the exact same wvdial test. Also check each time using cat
/proc/interrupts which driver occupies which IRQ. Once you get wvdial no
longer correclty behaving, you perfectly know which driver causes the
interference with the 537 driver on your computer. With this knowledge,
you may act accordingly to get rid from the interference.
If none of the drivers you modprobe'd cause a problem, then you'll have
to check your natural software environment. First, reboot your computer
to start it up normally. Once your computer is operaitonal, output dmesg
to a file and study it carefully. Then recheck the wvdial command after
having started a tail -f /var/log/messages in another terminal.
If you notice again a call trace involving the Intel 537 driver and you
do not incur a freeze, then perform from root an lsof that you direct to
a file that you study in detail.
The question to answer : which software running on your computer uses
which /dev/xxxx device. Pay special attention to any software using
/dev/modem or /dev/537. Another item to look at: which software uses a
/dev device which IRQ is at the same level than for the 537 modem.
If after reboot, the wvdial command works normally with no call trace
and you did make strictly no change, either to software or to hardware,
you may likely once again incur a problem later, but when it will occur
this will be without me as your problem is purely hardware.
Philippe
--
Philippe Vouters (Fontainebleau/France)
URL: http://vouters.dyndns.org/
