Heimo Claasen wrote: > > My Dear Steven - what you tell me here is sheer nonsense: > > They were unable to get to terms with it because you did not > > provide the (full) information they needed to diagnoze it.
Not nonsense Dear Heimo. The information you provided was insufficient to determine the cause of the problem. > The question was, as I again did put it here: "What is there > to do if the modem is moved from com2, irq 3 to com4, irq 7", Repeating the question over and over does not get us closer to the answer. > and the best anser in that long list thread over there was, > "use 'setserial /dev/ttyS3 irq 7'" Indeed, that was a useful suggestion. > - and this does not work. Provenly. Period. Perhaps this did not make your problem disappear, but it certainly was a positive step. Since you are using a non- standard IRQ on that port, it is necessary to use setserial. > And the diatribe you run here Which diatribe is that? It was you who said the gurus at the Linux-newbie list were unable to get to terms with your problem. I was simply giving the reason: they did not get sufficient information from you. > is _precisely_ of the kind that puts off for good anyone > who isn't a Linux-idolatric by birth; You should realize that your abrasive attitude to Linux makes Linux "gurus" less inclined to help you with your problems. This is why people stopped trying to help you at linux-newbie. > a la: 'what stupid question, don't you KNOW that you have > to check [43 or more, and these other 13 config] files before > you dare to ask such a dumb question ?!' They asked to see the contents of certain config files because they were hoping to see the cause of your problem. A perfectly reasonable request. > On top of it, to indignatetedly ask about "what type of UART" > is so completely off the issue Why? You said the modem worked on COM2, but didn't work when it was moved to COM4. It is possible that COM2 has a 16550A and COM4 has an 8250. In that case a pppd speed setting of 115200 (that worked fine on COM2) would not work on COM4. > that I's rather prefer some Douglas Adam quip. If you respond with snide remarks to genuine attempts to help, then you should not be surprised that people stop trying to help you. > I had made the exact same experience before, and had found > the only solution, namely to re-install the whole "system" > (or more precisely, the distro's kernel) anew If re-installing works, then the previous installation was probably fouled by a user error. > because it's a design fault In the Linux kernel? In RedHat? > which makes that it is difficult to alter the IRQ setting > associated with commports It's not difficult. That's what setserial is for. > _after_ the kernel is installed. Installed? What difference does that make? When RedHat "installs" the kernel, that does not change the kernel in any way -- it just copies the stock kernel from the installation CD to your HD. > Go to the endless threads about this in various kernel > groups which resulted in no change yet Really? I doubt that you know enough about the Linux kernel to understand what the "endless threads" are about. > You are utterly wrong if you pose as an answer to the > question put, that "PPP doesn't care about IRQs." "Utterly wrong" you say? Have a look at the pppd manpage. There is no reference to IRQ. None. Lots of references to ports and devices, but nothing about IRQ. There is a reason for that: it doesn't care about IRQs. It cares about speed. It cares about which /dev to use. It cares about authentication. It cares about lots of stuff. But not IRQ. > the kernel _does_ work only with those precise IRQs assigned > to the various commport addresses; Until they are changed by setserial (some other tool). > and it _does_ need the _correct_ IRQ to drive the modem. That's why setserial needs to be used (as I said in my previous message). The correct IRQ needs to be assigned to the /dev > And, aha, you haven't _got_ the "man" for "setserial ? Oh yes I do. And I consulted it before answering your last message. My setserial (version 2.12) does not have a -G parameter. > So go and look it up there <g> and what is says about the > "-G" argument. Is this how you respond to everyone who tries to help you with your problems? > BTW, that was a long thread in that newbie-list too, and > I _did_ give all information I could find on/in my "system" But did you give all the information that was requested by the people who were trying to help you? In my last message I asked for several bits of information (trying to help find your problem) and you have provide none of them. > Now, I do not take this fact for calling _you_ dishonest; > I take it as an indicator of "system-blindness", an > inability to look beyond a rigid set of terminologies Sounds like a diatribe to me. > I find so much of this in the Linux literature and even "man" > writings - that this doesn't help anyone who doesn't know all > of it beforehand The manpages were not designed for learners. Rather, they are meant to be a ready-reference for experienced users who need to remind themselves of parameters or other details of the command. > Anway, my demand for an explanation Demanding explanations will not get you very far on the linux-newbie list. > why Kppp _could_ work around the problem while Setserial > would _not_ solve it The answer is quite simple: Kppp was designed for idiots (point+click, no worries). setserial (and other CLI tools) are for people who know what they are doing. I have used setserial successfully. Lots of other people have used setserial successfully. Do not blame setserial. > it's just irrelevant Says who? > if the script [sic] You don't like the word script? What word would you prefer? > to launch pppd is "ifup", "pon", or "p-on"; just nothing in > there, or called from there, has anything to do with the > crucial - and wrong - IRQ setting the kernel uses. Says who? What makes you so sure the IRQ is the problem? You've given no evidence to back this idea. I asked for the syslog output. I asked whether you use the debug parameter. Why are you ignoring these requests? The fact is: the modem was moved from /dev/ttyS1 to /dev/ttyS3. Don't you think that might be a relevant variable? It is possible that the pppd configuration is still pointing at the wrong device. There are several ways this could occur and one of ways is inside the script used to launch pppd. Another way is a link to /dev/mouse (and I asked about that too in my last message). I asked sensible questions to try to get to the root of your problem. The fact that you have made no attempt to investigate these indicates that you are not really interested in finding the answer. Apparently all you want to do is complain about Linux and/or Linux "gurus". > IRQ setting the kernel uses. It's the latter which has to > be changed _after_ a hardware change That is not correct. If a non-standard IRQ is used (via setserial), it has to be changed EVERY TIME the system is booted. This is an important point (which you might have missed). Changes made by setserial are not persistent -- they disappear when the system is turned off. Setserial must be re-run at system startup. > So back to square one and my question: WHY can Kppp do what > Setserial cannot achieve So back to square one with my response: > > > > I suggest you execute: > > ----------------------- > > setserial -a /dev/ttyS3 > > ----------------------- > > when it is working with Kppp and make note of the settings. > > Compare them to the settings you get without using Kppp. > > Are all the settings identical? Cheers, Steven To unsubscribe from SURVPC send a message to [EMAIL PROTECTED] with unsubscribe SURVPC in the body of the message. Also, trim this footer from any quoted replies. More info can be found at; http://www.softcon.com/archives/SURVPC.html
