What you can also do to better observe the real problem on your computer

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

 



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/


[Index of Archives]     [Linux Media Development]     [Asterisk]     [DCCP]     [Netdev]     [X.org]     [Xfree86]     [Fedora Women]     [Linux USB]

  Powered by Linux