Very Computer

> It seems devfsd has an annoying "feature". I bought a PCI card to get a
> couple (2) more serial ports. The kernel doesn't seem to set up the
> serial ports at boot, so devfs never creates an entry. However, post
> boot, since there is no entries, I cannot configure the serial ports
> with setserial. So basically devfsd = no PCI based serial add on?

> 03:05.0 Serial controller: NetMos Technology 222N-2 I/O Card (2S+1P)
> (rev 01) (prog-if 02 [16550])
>     Subsystem: LSI Logic / Symbios Logic (formerly NCR): Unknown device
> 0002
>     Flags: medium devsel, IRQ 17
>     I/O ports at ecf8 [size=8]
>     I/O ports at ece8 [size=8]
>     I/O ports at ecd8 [size=8]
>     I/O ports at ecc8 [size=8]
>     I/O ports at ecb8 [size=8]
>     I/O ports at eca0 [size=16]

> mknod ttyS2 c 4 66
> mknod ttyS3 c 4 67
> setserial ttyS2 port 0xecf8 UART 16550A irq 17 Baud_base 9600
> setserial ttyS3 port 0xece8 UART 16550A irq 17 Baud_base 9600

> I hoped after "setting up" the serial ports with setserial some magic
> would happen and they would apear in /dev/tts... but I was wrong.

> gets me working serial ports... but it's not in /dev... :O

> Am I just screwed?

> If so, what would be a good add on PCI based solution for more serial
> ports that WORKS with devfsd? (I don't want to disable devfs as this
> opens up a different set of problems)

> Thanks for any replay!

-----Original Message-----

Sent: Friday, March 07, 2003 2:55 PM

Subject: Re: devfs + PCI serial card = no extra serial ports

BTW, this is with 2.4.19 (kernel shipped with distro).... I'm willing to
test any patches / rebuild kernel to get this working.....

> It seems devfsd has an annoying "feature". I bought a PCI card to get a
> couple (2) more serial ports. The kernel doesn't seem to set up the
> serial ports at boot, so devfs never creates an entry. However, post
> boot, since there is no entries, I cannot configure the serial ports
> with setserial. So basically devfsd = no PCI based serial add on?

> 03:05.0 Serial controller: NetMos Technology 222N-2 I/O Card (2S+1P)
> (rev 01) (prog-if 02 [16550])
>     Subsystem: LSI Logic / Symbios Logic (formerly NCR): Unknown device
> 0002
>     Flags: medium devsel, IRQ 17
>     I/O ports at ecf8 [size=8]
>     I/O ports at ece8 [size=8]
>     I/O ports at ecd8 [size=8]
>     I/O ports at ecc8 [size=8]
>     I/O ports at ecb8 [size=8]
>     I/O ports at eca0 [size=16]

> mknod ttyS2 c 4 66
> mknod ttyS3 c 4 67
> setserial ttyS2 port 0xecf8 UART 16550A irq 17 Baud_base 9600
> setserial ttyS3 port 0xece8 UART 16550A irq 17 Baud_base 9600

> I hoped after "setting up" the serial ports with setserial some magic
> would happen and they would apear in /dev/tts... but I was wrong.

> gets me working serial ports... but it's not in /dev... :O

> Am I just screwed?

> If so, what would be a good add on PCI based solution for more serial
> ports that WORKS with devfsd? (I don't want to disable devfs as this
> opens up a different set of problems)

> Thanks for any replay!

--
Bryan Whitehead
SysAdmin - JPL - Interferometry Systems and Technology
Phone: 818 354 2903

-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in

More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in

More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

> Ed

> -----Original Message-----

> Sent: Friday, March 07, 2003 2:55 PM


> Subject: Re: devfs + PCI serial card = no extra serial ports

> BTW, this is with 2.4.19 (kernel shipped with distro).... I'm willing to
> test any patches / rebuild kernel to get this working.....

>>It seems devfsd has an annoying "feature". I bought a PCI card to get a
>>couple (2) more serial ports. The kernel doesn't seem to set up the
>>serial ports at boot, so devfs never creates an entry. However, post
>>boot, since there is no entries, I cannot configure the serial ports
>>with setserial. So basically devfsd = no PCI based serial add on?

>>03:05.0 Serial controller: NetMos Technology 222N-2 I/O Card (2S+1P)
>>(rev 01) (prog-if 02 [16550])
>>    Subsystem: LSI Logic / Symbios Logic (formerly NCR): Unknown device
>>0002
>>    Flags: medium devsel, IRQ 17
>>    I/O ports at ecf8 [size=8]
>>    I/O ports at ece8 [size=8]
>>    I/O ports at ecd8 [size=8]
>>    I/O ports at ecc8 [size=8]
>>    I/O ports at ecb8 [size=8]
>>    I/O ports at eca0 [size=16]

>>mknod ttyS2 c 4 66
>>mknod ttyS3 c 4 67
>>setserial ttyS2 port 0xecf8 UART 16550A irq 17 Baud_base 9600
>>setserial ttyS3 port 0xece8 UART 16550A irq 17 Baud_base 9600

>>I hoped after "setting up" the serial ports with setserial some magic
>>would happen and they would apear in /dev/tts... but I was wrong.

>>gets me working serial ports... but it's not in /dev... :O

>>Am I just screwed?

>>If so, what would be a good add on PCI based solution for more serial
>>ports that WORKS with devfsd? (I don't want to disable devfs as this
>>opens up a different set of problems)

>>Thanks for any replay!

> It seems devfsd has an annoying "feature". I bought a PCI card to get a
> couple (2) more serial ports. The kernel doesn't seem to set up the
> serial ports at boot, so devfs never creates an entry. However, post
> boot, since there is no entries, I cannot configure the serial ports
> with setserial. So basically devfsd = no PCI based serial add on?

> 03:05.0 Serial controller: NetMos Technology 222N-2 I/O Card (2S+1P)
> (rev 01) (prog-if 02 [16550])
>     Subsystem: LSI Logic / Symbios Logic (formerly NCR): Unknown device
> 0002
>     Flags: medium devsel, IRQ 17
>     I/O ports at ecf8 [size=8]
>     I/O ports at ece8 [size=8]
>     I/O ports at ecd8 [size=8]
>     I/O ports at ecc8 [size=8]
>     I/O ports at ecb8 [size=8]
>     I/O ports at eca0 [size=16]

> mknod ttyS2 c 4 66
> mknod ttyS3 c 4 67
> setserial ttyS2 port 0xecf8 UART 16550A irq 17 Baud_base 9600
> setserial ttyS3 port 0xece8 UART 16550A irq 17 Baud_base 9600

> I hoped after "setting up" the serial ports with setserial some magic
> would happen and they would apear in /dev/tts... but I was wrong.

> gets me working serial ports... but it's not in /dev... :O

> Am I just screwed?

> If so, what would be a good add on PCI based solution for more serial
> ports that WORKS with devfsd? (I don't want to disable devfs as this
> opens up a different set of problems)

> Thanks for any replay!

> It seems devfsd has an annoying "feature". I bought a PCI card to get a
> couple (2) more serial ports. The kernel doesn't seem to set up the
> serial ports at boot, so devfs never creates an entry. However, post
> boot, since there is no entries, I cannot configure the serial ports
> with setserial. So basically devfsd = no PCI based serial add on?

-----Original Message-----

Sent: Friday, March 07, 2003 3:28 PM
To: Bryan Whitehead

Subject: Re: devfs + PCI serial card = no extra serial ports

I just found this:
http://www.uwsg.iu.edu/hypermail/linux/kernel/0212.2/0845.html

Has this patch been accepted into the new kernel series? Or should I
just toss this card (the NetMos PCI I/O card)?

> It seems devfsd has an annoying "feature". I bought a PCI card to get a
> couple (2) more serial ports. The kernel doesn't seem to set up the
> serial ports at boot, so devfs never creates an entry. However, post
> boot, since there is no entries, I cannot configure the serial ports
> with setserial. So basically devfsd = no PCI based serial add on?

> 03:05.0 Serial controller: NetMos Technology 222N-2 I/O Card (2S+1P)
> (rev 01) (prog-if 02 [16550])
>     Subsystem: LSI Logic / Symbios Logic (formerly NCR): Unknown device
> 0002
>     Flags: medium devsel, IRQ 17
>     I/O ports at ecf8 [size=8]
>     I/O ports at ece8 [size=8]
>     I/O ports at ecd8 [size=8]
>     I/O ports at ecc8 [size=8]
>     I/O ports at ecb8 [size=8]
>     I/O ports at eca0 [size=16]

> mknod ttyS2 c 4 66
> mknod ttyS3 c 4 67
> setserial ttyS2 port 0xecf8 UART 16550A irq 17 Baud_base 9600
> setserial ttyS3 port 0xece8 UART 16550A irq 17 Baud_base 9600

> I hoped after "setting up" the serial ports with setserial some magic
> would happen and they would apear in /dev/tts... but I was wrong.

> gets me working serial ports... but it's not in /dev... :O

> Am I just screwed?

> If so, what would be a good add on PCI based solution for more serial
> ports that WORKS with devfsd? (I don't want to disable devfs as this
> opens up a different set of problems)

> Thanks for any replay!

--
Bryan Whitehead
SysAdmin - JPL - Interferometry Systems and Technology
Phone: 818 354 2903

-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in

More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in

More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

> > It seems devfsd has an annoying "feature". I bought a PCI
> > card to get a couple (2) more serial ports. The kernel doesn't
> > seem to set up the serial ports at boot, so devfs never
> > creates an entry. However, post boot, since there is no
> > entries, I cannot configure the serial ports with setserial.
> > So basically devfsd = no PCI based serial add on?

> Yep.  This I pointed this out as a flaw to devfs a long, long time
> (years!) ago, but Richard chose not to listen to me.  Personally, I
> solve this (and other) problems by simply refusing to use devfs.

> I just found this:
> http://www.uwsg.iu.edu/hypermail/linux/kernel/0212.2/0845.html

> Has this patch been accepted into the new kernel series? Or should I
> just toss this card (the NetMos PCI I/O card)?

> Sure, go ahead and try the second patch that adds the Netmos cards to the
> serial driver's device tables. It is for a somewhat newer rev, but you might
> just get offsets with no failed hunks. It's worth a try.

>>>It seems devfsd has an annoying "feature". I bought a PCI
>>>card to get a couple (2) more serial ports. The kernel doesn't
>>>seem to set up the serial ports at boot, so devfs never
>>>creates an entry. However, post boot, since there is no
>>>entries, I cannot configure the serial ports with setserial.
>>>So basically devfsd = no PCI based serial add on?

>>Yep.  This I pointed this out as a flaw to devfs a long, long time
>>(years!) ago, but Richard chose not to listen to me.  Personally, I
>>solve this (and other) problems by simply refusing to use devfs.

> Ted,

> Will Bryan get the proper devfs entries if he patches serial.c to
> recognize his card at kernel initialization, or is there more
> weirdness expected?

> Best regards,
> Ed

> ----------------------------------------------------------------
> Ed Vance              edv (at) macrolink (dot) com
> Macrolink, Inc.       1500 N. Kellogg Dr  Anaheim, CA  92807
> ----------------------------------------------------------------
> -
> To unsubscribe from this list: send the line "unsubscribe linux-kernel" in

> More majordomo info at  http://vger.kernel.org/majordomo-info.html
> Please read the FAQ at  http://www.tux.org/lkml/

> Quick question: What PCI serial port add on card works with devfs in
> kernel 2.4.19 out of the box? No pissing around?

> While I'm messing around with the one I got (that doesn't
> work) I need
> one that does... any suggestions??

> Thanks to all for the help!!

>> It seems devfsd has an annoying "feature". I bought a PCI card to get a
>> couple (2) more serial ports. The kernel doesn't seem to set up the
>> serial ports at boot, so devfs never creates an entry. However, post
>> boot, since there is no entries, I cannot configure the serial ports
>> with setserial. So basically devfsd = no PCI based serial add on?

>Yep.  This I pointed this out as a flaw to devfs a long, long time
>(years!) ago, but Richard chose not to listen to me.  Personally, I
>solve this (and other) problems by simply refusing to use devfs.

>                                                - Ted

> [Sorry if this is a duplicate.  I sent it about 12 hours ago,
> and it still
> has not appeared on marc.theaimsgroup.com or
> www.uwsg.indiana.edu.-Adam]

> >> It seems devfsd has an annoying "feature". I bought a PCI
> card to get a
> >> couple (2) more serial ports. The kernel doesn't seem to
> set up the
> >> serial ports at boot, so devfs never creates an entry.
> However, post
> >> boot, since there is no entries, I cannot configure the
> serial ports
> >> with setserial. So basically devfsd = no PCI based serial add on?

> >Yep.  This I pointed this out as a flaw to devfs a long, long time
> >(years!) ago, but Richard chose not to listen to me.  Personally, I
> >solve this (and other) problems by simply refusing to use devfs.

> >                                                - Ted

>         Let me see if I understand the problem.  The sitution is
> that you have "stem cell" devices which initially are not defined
> to talk to a particular port, but which are then differentiated
> by a user level program doing ioctls to set the associated IO
> ports, interrupts and even UART types.  For example, exactly which
> kernel device is associated with which hardware device is controlled
> by user level software.

>         There is nothing in devfs that prevents you from registering
> devfs devices even if they are not yet bound to specific hardware
> (you do not need a sysfs mapping, for example).  So, you should be
> able to register /dev/tts/0..N at initialization, where N is the
> maximum number of serial devices you want to support.

>         Another approach, which I think provides a little more
> information to users, makes for a more readable /dev tree and should
> make some programs a few cycles faster would be to what my version of
> /dev/loop does (not the one currently in Linus's tree, alas): start by
> just creating /dev/tts/0, and then create /dev/tts/n+1 whenever
> /dev/tts/n is assigned and /dev/tts/n+1 has not already been defined.
> For /dev/loop, it was also useful to have the extra devices unregister
> when the highest number device became undefined (if a device in the
> middle were de-defined, it would not disappear until all higher
> numbered devices were also de-defined).

>         Is this the issue, or do I misunderstand?

> Adam J. Richter     __     ______________   575 Oroville Road

> +1 408 309-6081         | g g d r a s i l   United States of America
>                          "Free Software For The Rest Of Us."

>         Another approach, which I think provides a little more
> information to users, makes for a more readable /dev tree and should
> make some programs a few cycles faster would be to what my version of
> /dev/loop does (not the one currently in Linus's tree, alas): start by
> just creating /dev/tts/0, and then create /dev/tts/n+1 whenever
> /dev/tts/n is assigned and /dev/tts/n+1 has not already been defined.
> For /dev/loop, it was also useful to have the extra devices unregister
> when the highest number device became undefined (if a device in the
> middle were de-defined, it would not disappear until all higher
> numbered devices were also de-defined).

>         Is this the issue, or do I misunderstand?

> Adam J. Richter     __     ______________   575 Oroville Road

> +1 408 309-6081         | g g d r a s i l   United States of America
>                          "Free Software For The Rest Of Us."
> -
> To unsubscribe from this list: send the line "unsubscribe linux-kernel" in

> More majordomo info at  http://vger.kernel.org/majordomo-info.html
> Please read the FAQ at  http://www.tux.org/lkml/