# setserial -a /dev/ttyS4
/dev/ttyS4: No such file or directory.
#ls -la /dev/ttyS4
ls: cannot access /dev/ttyS4: No such file or directory

So from reading here, it looks like my options are:
1- re-install slack 11, for the 2.4 kernel which has that port
2- buy a new modem
3- the dreaded "compile a kernel" answer, which will take days if I can do it at all.

Is there any other possibility?

My level of expertise is not high.

do:
And seek about serial ports there

dmesg | less results in 20 pages, so I tried this:

dmesg | less | grep serial
serial8250: ttyS0 at I/O 0x3f8 (irq = 4) is a 16550A
serial8250: ttyS1 at I/O 0x2f8 (irq = 3) is a 16550A


william@darkstar:~$ dmesg | less | grep port
Linux Plug and Play Support v0.97 (c) Adam Belay
PCI: If a device doesn't work, try "pci=routeirq". If it helps, post a report
vesafb: pmi: ports = 3b4 3b5 3ba 3c0 3c1 3c4 3c5 3c6 3c7 3c8 3c9 3cc 3ce 3cf 3d0 3d1 3d2 3d3 3d4 3d5 3da
Serial: 8250/16550 driver $Revision: 1.90 $ 4 ports, IRQ sharing enabled
hda: cache flushes supported
Loading iSCSI transport class v2.0-724.
iscsi: registered transport (tcp)
iscsi: registered transport (qla4xxx)
with "disable_clustering=1" and report to maintainers
hub 1-0:1.0: 6 ports detected
hub 2-0:1.0: 2 ports detected
hub 3-0:1.0: 2 ports detected
hub 4-0:1.0: 2 ports detected
USB Mass Storage support registered.
serio: i8042 KBD port at 0x60,0x64 irq 1
serio: i8042 AUX port at 0x60,0x64 irq 12
i2c_core: exports duplicate symbol i2c_smbus_write_i2c_block_data (owned by kernel)
gameport: EMU10K1 is pci0000:00:08.1/gameport0, io 0xec00, speed 1193kHz
i2c_core: exports duplicate symbol i2c_smbus_write_i2c_block_data (owned by kernel)
usbhid: exports duplicate symbol hiddev_hid_event (owned by kernel)
parport: PnPBIOS parport detected.
parport0: PC-style at 0x378 (0x778), irq 7 [PCSPP,TRISTATE,EPP]
lp0: using parport0 (interrupt-driven).
usbhid: exports duplicate symbol hiddev_hid_event (owned by kernel)


So only two serial ports.

I am guessing you are expecting more than 2 then? I can't say I have ever seen 4 physical serial ports on a machine before, even back when serial was actually in common use. The modem could be internal on it's own serial line, but to be S4 you would still need 3 other ports...

Have you tried ttyS0 and ttyS1 to see if either of them actually is the modem?

To get on the internet without the PCI modem I've plugged in an external modem on ttyS0, so that's showing.

Don't know what ttyS1 is.

most machines will have 2 serial ports [well for most see a lot]
these are probably avialable in the BIOS setup of the machine

Where did You get ttyS4 (dos='com5) ?
Is this a modem with a controller?
Which brand/model is it? a fax2.0 class?
Is it on PCI or ISA bus?

@MS3FGX|strangeslack
NOTE:
/dev/ttyS0
/dev/ttyS1
/dev/ttyS2
/dev/ttyS3
/dev/ttyS4
(!)

said ttyS0 and ttyS1 are physical ports which must not both be actually wired out on the mainboard at all.
The i8250 just has them, no mather if the MoBo OEM wires them on the PCB or not. However most MoBos have one on the back (sub-D) and one wired trough a pin-header on the board.

The ttyS4 is in no case a MoBos port, my bet it's a modem's own serial interace on the PCI or ISA bus.

Until slack 12, I used a usr5610b PCI modem in this PC, it requires ttyS4.
I could select either modem in kppp.
The external is mostly used for my laptop when away from home.

I tried the huge.s and huge.smp kernels, no joy, so re-installed slackware 11.
The usr5610b on ttyS4 works perfectly now.

This might be related to console devices in the kernel config...
try to diff out the 2.6.13.17 against 2.6.22.1 config, it could show something ?

Beyond my level of expertise. Regrets.

Willl wait for slack 12.1
There was also a problem with installing latest Nvidia driver in huge.s and 2.6.21.5-generic, resulting in no X.

William:

Don't despair quite yet. And certainly don't wait for 12.1! I suspect that you have simply fallen into the *udev* trap. And I suspect you actually have that PCI modem. It just isn't where you think you ae looking for it.

There are a couple of ways to go at this. The earlier advice to use *dmesg* was good. Perhaps you didn't see what you needed there. Try it again. Then begin to search for the place that your serial ports are initialized. This will be down after the CPU and memory are established. In my case it is down abut 200 lines. There you should see something like:

00:07: ttyS0 at I/O ...... <first serial port on mobo>
00:08: ttyS1 at I/O ...... <second serial port on mobo>

then down another line or so:

0000:02:03.0: ttyS2 at I/O ..... <this is probably your modem>

This last entry will have I/O stuff and IRO stuff that can be determined by doing a

lspci -vv

Go searching down through this listing until you find your modem and the I/O and IRQ stuff that you see in the dmesg listing. You will also see the 0000:02:03.0 number (or whatever it is in your system) which is associated with your modem (as identified via the lspci command)

You can further confirm all this by checking in /sys/bus/pci/devices. This directory is a set of symlinks which will point you to the "correct" directory (in /sys) to trace this. Drill down until you find your modem file (the 0000:02:03.0 kind of file). Once you get there, there will be all sort of various files and things, including the ttyS* that the modem has been assigned to.

Note a couple of things here:

In the dynamic allocation regime of *udev*, your modem probably ISN'T where you thought it would be--and especially NOT against something like Slack 10/11 with a static device allocation. (It almost certainly is NOT on ttyS4 as in the static system.)

The reason for the previous is that Pat's Setup/Configure routine doesn't seem to work in the *udev* regime. It still asks the modem link question like it did in the old system. But it DOESN'T make the link like it did before.

Once you finally "find" your internal PCI modem you can either call it by the assigment that udev gives to it or you can add your own *udev* rule to make make a "fixed" /dev/modem link as existed in the static system.

HTH

LDV

Try an older version. 9631 worked fine for me.

Brian

for the modem's tty:
dmesg | grep ttyS

for the PCI modem:
lspci

for X: switch back to "nv" until nvidia resolved, or at least to vesa