Dale writes:
> You could have a look at doing it with udev
This does seem like what I need but I haven't gotten it
to make one bit of difference yet. With the PCMCIA card out, no
/dev/ttyS0 or /dev/ttyS1 devices are present. That modem which I
believe to be a Winmodem, is probably /dev/ttyS0. If you do
udevinfo -a -p $(udevinfo -q path -n /dev/ttyS1)
or the same command for ttyS0, you get:
Udevinfo starts with the device specified by the devpath and then
walks up the chain of parent devices. It prints for every device
found, all possible attributes in the udev rules key format.
A rule to match, can be composed by the attributes of the device
and the attributes from one single parent device.
looking at device '/class/tty/ttyS1':
KERNEL=="ttyS1"
SUBSYSTEM=="tty"
DRIVER==""
looking at parent device '/devices/platform/serial8250':
KERNELS=="serial8250"
SUBSYSTEMS=="platform"
DRIVERS=="serial8250"
ATTRS{modalias}=="platform:serial8250"
looking at parent device '/devices/platform':
KERNELS=="platform"
SUBSYSTEMS==""
DRIVERS==""
Boot the system with the PCMCIA card in and that is when
things get wrong. Both ttyS0 and ttyS1 now clame the card. Here
is ttyS1. ttyS0 is the same except for the ttyS0 designation.
Udevinfo starts
looking at device '/class/tty/ttyS1':
KERNEL=="ttyS1"
SUBSYSTEM=="tty"
DRIVER==""
looking at parent device
'/devices/pci:00/:00:1e.0/:02:04.0/:03:00.0':
KERNELS==":03:00.0"
SUBSYSTEMS=="pci"
DRIVERS=="serial"
ATTRS{vendor}=="0x4348"
ATTRS{device}=="0x3253"
ATTRS{subsystem_vendor}=="0x4348"
ATTRS{subsystem_device}=="0x3253"
ATTRS{class}=="0x070002"
ATTRS{irq}=="10"
ATTRS{local_cpus}=="ff"
ATTRS{local_cpulist}=="0-7"
ATTRS{modalias}=="pci:v4348d3253sv4348sd3253bc07sc00i02"
ATTRS{enable}=="1"
ATTRS{broken_parity_status}=="0"
ATTRS{msi_bus}==""
looking at parent device '/devices/pci:00/:00:1e.0/:02:04.0':
KERNELS==":02:04.0"
SUBSYSTEMS=="pci"
DRIVERS=="yenta_cardbus"
ATTRS{vendor}=="0x1217"
ATTRS{device}=="0x6972"
ATTRS{subsystem_vendor}=="0x1028"
ATTRS{subsystem_device}=="0x00b8"
ATTRS{class}=="0x060700"
ATTRS{irq}=="10"
ATTRS{local_cpus}=="ff"
ATTRS{local_cpulist}=="0-7"
ATTRS{modalias}=="pci:v1217d6972sv1028sd00B8bc06sc07i00"
ATTRS{enable}=="2"
ATTRS{broken_parity_status}=="0"
ATTRS{msi_bus}=="1"
looking at parent device '/devices/pci:00/:00:1e.0':
KERNELS==":00:1e.0"
SUBSYSTEMS=="pci"
DRIVERS==""
ATTRS{vendor}=="0x8086"
ATTRS{device}=="0x2448"
ATTRS{subsystem_vendor}=="0x"
ATTRS{subsystem_device}=="0x"
ATTRS{class}=="0x060400"
ATTRS{irq}=="0"
ATTRS{local_cpus}=="ff"
ATTRS{local_cpulist}=="0-7"
ATTRS{modalias}=="pci:v8086d2448svsdbc06sc04i00"
ATTRS{enable}=="1"
ATTRS{broken_parity_status}=="0"
ATTRS{msi_bus}=="1"
looking at parent device '/devices/pci:00':
KERNELS=="pci:00"
SUBSYSTEMS==""
DRIVERS==""
The weirdness only extends as far as ttyS1 so I thought
I could slug the meter, so to speak and put in the defaults for
ttyS0 and ttyS1 and hopefully the card would nicely become ttyS2.
No such luck. The card still sits right there, being both ttyS0
and ttyS1 and not really working as either.
Any other ideas as to how to get this to operate
normally? I did run udevadm in test mode and it did complain
that it could not open /dev/ttyS0.
Thank you.
Martin McCormick WB5AGZ Stillwater, OK
Systems Engineer
OSU Information Technology Department Telecommunications Services Group
--
To UNSUBSCRIBE, email to debian-user-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
