LINK="#3366FF" VLINK="#A000A0">

"The Linux Gazette...making Linux just a little more fun!"


(?) The Answer Guy (!)


By James T. Dennis, tag@lists.linuxgazette.net
Starshine Technical Services, http://www.starshine.org/


(?) X Prevents/Kills Modem Connection

From ktoyama on Thu, 14 Jan 1999

(?) Dear Answer Guy,

Great forum of Q&A here at the Linux Gazette. Here is my problem.

I'm trying to use a US Robotics 28.8 (no winmodem) and it works fine under the linux console under windows 1-6. Once I start-up X it doesn't seem to connect to the modem and seems to lose the connection to the modem. I start up the pppd which invokes the chat script but the modem never does a connect. But if I quickly switch to (CTRL-ALT-F1) or and F1-F6 window, the modem will dial and connect. Then I switch back to X and there is a connection. I can check mail, view web pages, but then after about 2 minutes everything stalls and the connection is lost. If I switch to a console for 15-20 seconds the link restores it's speed and then I can switch back to X. Then the cycle starts all over again. Please help me in determining the root of the problem. Thanks.

Sincerely,

Kevin

(!) My first guess would be that you have an IRQ problem. If you modem and your mouse are trying to use the same IRQ --- and your modem is inactively while you're at your text consoles (i.e. you're not using gpm) --- that would be the most likely problem.
Other problems are possible. Some video cards use IRQ 2/9 (daisy chained IRQ pair) which might cause conflicts while you were in graphics mode, while not causing any problem from text consoles.
Yet another problem might have to do with the system's overall computing power. If you have a high speed modem connection it could be that X takes enough of your CPU horse power that the serial driver gets starved for attention (although that would also suggest flow control problems).
Of course a 28.8 and any sort of Pentium (even a P60) should be reasonably well matched --- assuming you have enough RAM that you aren't thrashing to disk.
Does this only happen with PPP? What if you connect to a BBS (or dial-up shell), start a file transfer and then start X? If the transfer (zmodem, Kermit, or whatever) still runs smoothly for several minutes after switching to X --- it suggests some sort of networking problem. If not, try running a file transfer while starting a non-X graphics program (such as 'zgv' --- the SVGAlib .GIF and JPEG viewer).
Also try running a file transfer while performing "cut and paste" operations on your text mode VCs (run 'gpm' to do that). Transfer a couple of page fulls of a man page into an empty editor session ('vi' -- 'emacs' or whatever).
As with any problems with any daemons, look in your /var/log/messages. Are there any error messages being posted through the syslog subsystem? Try increasing the debugging output of your pppd by adding the debug and kdebug directives to your /etc/ppp/options file (as per the man pages).
Try posting the contents of your PPP options file(s) and the command that's being used to invoke it (which may over-ride many of the directives in the options file by listing conflicting options on its command line or pointing to a supplemental options file using the "file" directive).
Try a different video card and/or a different X server. (You could even try starting a "monochrome" X server).
It's also possible that the problem lies with some X application or "toy" ('clock', your window manager, etc) rather than with the X server itself. If the probably recurs while running 'zgv' or some other SVGAlib program --- then you can conclude that it has more to do with the hardware/drivers than with the applications.
With any troubleshooting process you want to try all sorts of things that help isolate the exact components (hardware and software) that are involved. Many of these tests may not be usable as "work arounds" but they can define the problem more precisely.
You can browse around under the /proc filesystem to find out a bit more about which IRQs are in use and you can use the 'procinfo' and similar commands to determin more.
(If this is a laptop running PCMCIA drivers -- for example --- then there are any other potential problems, as laptop hardware tends to be very quirky --- video and PCMCIA interfaces especially).


Copyright © 1999, James T. Dennis
Published in The Linux Gazette Issue 37 February 1999


[ Answer Guy Index ] 1 2 3 4 5 6 7 8 9 10
11 12 14 15 16 17 18 19 21 22
23 28 29 30 31 32 33 34 37 38
39 41 42 43 44 45 46 47 48 49



[ Table Of Contents ] [ Front Page ] [ Previous Section ] [ Next Section ]