[Date Prev][Date Next] [Thread Prev][Thread Next] [Date Index] [Thread Index]

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: