Bug#105451: update
I think this should solve the problem!
...
> In any case mknod just creates files with minor and major numbers, and does
> not ask the kernel if these are valid. The validation only happens when
> the file is opened. The kernel only recognises major 4, with minor 64-67
> as serial ports by default. Kernel variable CONFIG_SERIAL_MANY_PORTS
> provides extra minor numbers (how many ports this adds I cannot say).
> This may or may not be set for you in the
> kernel build... this information is printed out at boot time as " MANY
> PORTS"
> and I gather that this is not printed when the module is loaded, and thus I
> am guessing that it is not set. I am getting this from the 2.4.7 kernel
> source
> so things may be different in other kernel versions (but I doubt it).
You are correct. It doesn't appear in any of the 2.2.19 flavors, so
far as I can see from the kernel-config files.
> The names of the ports and there numbers are really not that important.
> I am hoping that you only have a few serial ports in total (less than 4), so
Yes, there are just 3: the modem, the mouse, and a serial line my wife
uses to log in from a glass tty in her office.
> you can hopefully use ttyS3 or ttyS4 and use setserial to configure them to
> what you want without having to recompile the kernel. I can think of no good
> reason why MANY PORTS is not the default, though it probably adds a few 100
> bytes to the kernel size. You probably chose S14 as this is
> a SPARE tty (whatever this means) in serial.h when MANY_PORTS is defined.
I was in fact just following the convention adopted in my old Slackware
system with the ttyS14 (actually, cua14) in the rc.serial file.
> Hope this helps.
I think it should solve the problem! I tried the "vanilla" kernel and
of course had the same problem with ttyS14 as before. Ordinarily I
would be reluctant to trample on the debian port assignment, but if you
say it is OK to redefine ttyS3 as my modem, I'll go ahead and try
that.
The MANY_PORTS business had actually been suggested yesterday by
another correspondent, but without such definite information about what
is going on; so I decided to try the "vanilla" kernel first as it
seemed unlikely to me that MANY_PORTS was going to be needed, and the
"vanilla" version is described as having lots of drivers -- with all
its support for exotic hardware, who'd think it wouldn't support a
nonstandard serial port? From the naming of the modules, I had
supposed that MANY_PORTS would be required only if I literally had many
ports, not just a high-numbered one; while NONSTANDARD sounded more
likely to be required for a serial port with an odd irq and memory
address.
This whole fiasco could have been headed off if the necessary
information had been available in places one would normally look for
it. For example, if the MANY_PORTS business had been explained in the
SERIAL HOWTO, or even if the information had been available in the
Debian bug-report archives (where a search for "ttyS14" turns up
practically nothing), I could have avoided the problem.
It would also be useful if such things were explained in the
Installation instructions -- or at least, if there were a pointer there
to where the information could be found. I suppose this is too
uncommon and subtle a problem to need coverage in the installation
scripts themselves -- though it might be useful to say, either there or
in the installation manual, that *only* serial ports 0-3 are usable
without rebuilding the kernel. It would also be helpful if this were
mentioned in section 5.2 of the installation manual, where "choosing a
flavor" is discussed. The present manual makes it sound as if the
"vanilla" flavor has just about eveything needed.
Another place it would be useful to document this is in the
/etc/serial.conf file, which is already full of useful comments. As it
has dummy entries for ttyS14 and 15, I assumed I could just fill in the
blanks and setserial would set up the serial port; there is no
indication that special kernel support is needed to make ttyS14/15
work. (Probably other entries in serial.conf should have comments
added to indicate what kernel modules they need.)
While I am suggesting clarifications, let me also suggest that the
kernel-config files have at least a 1-line header comment to indicate
which kernel and flavor they refer to, as I wasted a day by having
inadvertently looked at the wrong one in chasing after a fix for my
problem. There are a lot of very similar files and subdirectories in
the Debian ftp tree, and it's easy to get lost (particularly if, like
me, you are not familiar with this distribution).
I think the fact that someone with 15 years' experience with UNIX and 5
years' experience with earlier Linux systems (me), as well as several
people with considerable familiarity with Debian (e.g., Adam) were
unable to spot the problem and solve it right off shows that more
information about this obscure point needs to be made available in the
documentation where people would normally look, such as the SERIAL
HOWTO and the Installation manual.
Would it be reasonable to add a note about this to, say, the mknod and
setserial man pages as well? It's all very well to say that all
problems are ultimately resolvable by reading the source code; but when
one is installing the system for the first time, it isn't obvious
whether the problem is in the kernel, mknod or setserial, or what --
not to mention that *most* new users don't have a clue about reading
source code, and need a good human-readable document (preferably the
Installation instructions; the HOWTOs are a bit obscure for non-Linux
people).
Thanks very much for all your help. I'll try this and let you know if
just fudging ttyS3 in serial.conf does the trick.
-- Andy Young
Reply to: