Bug#105451: update
Andy,
I don't recall how device numbering worked in 1.2.x (seems like eons ago
now), but have you considered trying /dev/ttyS13 instead of 14?... I know
some kernel releases numbered the serial ports starting at 1, while 2.2.x
numbers starting with 0. That could have moved your 14 back to 13. (If
you've already tried this, ignore me. Just trying to be helpful.)
... Adam Conrad
-----Original Message-----
From: Andrew Young [mailto:aty@sciences.sdsu.edu]
Sent: Sunday, July 29, 2001 10:57 PM
To: adam@onshore.com
Cc: 105451@bugs.debian.org; setserial@packages.debian.org
Subject: 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
--
To UNSUBSCRIBE, email to debian-bugs-dist-request@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact
listmaster@lists.debian.org
Reply to: