Bug#105451: update
...
>> This is why MAKEDEV can't configure ttyS14 by itself:
>
> MAKEDEV never configures *anything* really. It just makes files in
> /dev.
Sure enough. But it does so by calling mknod; so I'd expect the kernel
to know the device exists, even if it isn't configured correctly. If
the irq conflicted with something else, I'd expect the system to hang,
ot a call to the port would produce gibberish -- but this "No such
device" error sounds as if the mknod didn't execute correctly, even
though it does produce the correct major and minor numbers in an ls -l
listing.
>> somebody has to tell
>> it how to configure the port. In Debian's /etc, there is a file called
>> something like serial.conf in which you can enter the necessary info;
>> but that, again, gives "No such device" when the startup script calls
>> setserial to initialize the port.
>
> /etc/serial.conf is controlled by setserial. You'd have to see the
Well, I'd have put it the other way around: setserial is controlled by
serial.conf, which just tabulates arguments for calls to setserial.
> documentation on that for how it is supposed to be configured.
> Perhaps you could cite what line you have there.
The same setserial arguments as in the rc.serial file of the Slackware system:
/dev/ttyS14 uart 16550A port 0x2f0 irq 2
Of course, it produces the same "No such device" complaint as executing
setserial /dev/ttyS14 uart 16550A port 0x2f0 irq 2
by hand does. It just goes into the log file when it's done by
serial.conf.
As I recall, I also get the "No such device" if I just try to echo "AT" to
the port from the shell.
>>> Maybe you need one of the binary only drivers, e.g., as discussed on
>>> http://www.toppoint.de/~chl/linux_on_512t.html ?
>>
>> That points to www.linmodems.org so supposedly it applies to "Winmodems"
>> and not to real hardware modems, which is what I have. The only thing
>> that's strange about the modem is the irq and the memory port it uses;
>> apart from that, it's a normal (but made by some no-name clonemaker)
>> modem.
>
> Ok. Well, that's good.
>
>>> You've looked through all the kernel output it gives at bootup? That
>>> should be visible with 'dmesg |less' or looking in /var/log/messages .
>>
>> If I add the port-configuration info to serial.conf, the "No such device"
>> error appears there. I find no other output related to this serial-port
>> problem.
>
> That's irrelevant. My question is still appropriate.
The only message that refers to serial drivers says:
Serial driver version 4.27 with no serial options enabled
The syslog file has:
Failed to open /dev/ttyS14: No such device
when I try to call the modem with pppd.
>>> This really feels like more of a hardware/kernel issue than Debian
>>> issue, really.
>>
>> But if it worked under kernel 1.2.9 (the Slackware system), why is it
>> broken now? The provision of the configuration line for ttyS14 in the
>> serial.conf file shows that it's *supposed* to work, still....
>
> It has nothing to do with a provision for /dev/ttyS14 per se, just a
> provision for your non-standard serial port IO/base address sitting on
> some (assigned by you) /dev/ttyS* device.
But those non-standard settings aren't present until setserial sets them
up. I get the "No such device" errors when I try to use setserial to set
those values, as well as when trying to call the modem with pppd. If
setserial is at fault, I'd hope it would return a more descriptive
complaint than "No such device" even if I am using parameters that (for
some reason) are not legitimate under the Debian kernel. (For example, if
something else has pre-empted the memory slots, I'd expect some complaint
like "memory region already committed"; if something else is using the
irq, then there ought to be a message saying that that irq is already
taken.)
The fact that "No such device" keeps turning up when different programs
try to reach it makes it appear that this is a kernel error message, not
something just generated in setserial.
> Again, this is either a setserial issue, or a kernel issue. I doubt
> it's a kernel issue unless the device uses a uart which is not
> supported by the kernel, which seems unlikely.
The setserial call in the Slackware system specifies "uart 16550A" and
indeed querying the device (opn that system) returns this same
information; so I think it really is a 16550A.
> As you say, it works in Slackware so it's clearly not a hardware
> issue.
Right -- the hardware has been working fine for 5 years and I'm talking to
you through this very modem (under Slackware) right now....
> Thus by elimination its either misconfiguration of /etc/serial.conf by
But, remember, this already appeared when I tried to set up the port by
executing the mknod and setserial commands *by* *hand* -- before I
even discovered the "serial.conf" file (which Slackware with the 1.2.9
kernel doesn't have). So it's a direct result of running those
commands, whether they are run from the *.conf scripts or manually.
> you or else some setserial bug. I've CC'd the setserial author.
> Perhaps he could review the evidence, but I'm sure he too would like
> to see the serial.conf you are using.
I quoted the ttyS14 line above -- you want me to mail you the whole
file? It's the stock issue that came with the Debian distribution,
except that I uncommented the ttyS14 line and replaced the XXX's with
the corresponding arguments from the setserial command that *works* in
the Slackware rc.serial file.
Thanks for the effort you're putting into this. I followed your
earlier suggestion and re-submitted it as a kernel bug, as well -- but
with no response yet.
-- Andy Young
Reply to: