Hi list,
I just noticed the serial_8250 driver in the opensuse kernel is set to support AND initialize/create 32 serial ports. Is this still useful on a nowadays desktop machine? And even if CONFIG_SERIAL_8250_NR_UARTS=32 is set, why not set CONFIG_SERIAL_8250_RUNTIME_UARTS to something more reasonable? (It's also set to 32).
I know I can override it with 8250.nr_uarts kernel parameter, but it would be more logical that this is used by someone who really has a lot of serial ports.
(I ran across it because wine automatically sets links in ~/.wine/dosdevices/ for serial hardware. So I end up with com1-com34, where com33 and com34 are the actually useful ones, being the ttyUSB? units almost anyone likely uses nowadays...)
On 08/30/2018 06:30 AM, Peter Suetterlin wrote:
I just noticed the serial_8250 driver
That certainly takes me back. Many years ago, I designed and built an 8 port serial I/O board for my IMSAI 8080 computer. I used the 8250 UART. In the process I found a bug in the 8250 and advised the manufacturer. I designed the board so that all the UARTs shared the same address, as was commonly done on mini-computers, but not on PCs, where each had it's own address. I also wrote my own software to run it.
https://en.wikipedia.org/wiki/IMSAI_8080
Op donderdag 30 augustus 2018 13:13:51 CEST schreef James Knott:
On 08/30/2018 06:30 AM, Peter Suetterlin wrote:
I just noticed the serial_8250 driver
That certainly takes me back. Many years ago, I designed and built an 8 port serial I/O board for my IMSAI 8080 computer. I used the 8250 UART. In the process I found a bug in the 8250 and advised the manufacturer. I designed the board so that all the UARTs shared the same address, as was commonly done on mini-computers, but not on PCs, where each had it's own address. I also wrote my own software to run it.
Can we please keep this the opensuse-factory@o.o list, where factory- development is discussed?
On Thu, Aug 30, 2018 at 12:31 PM Peter Suetterlin pit@astro.su.se wrote:
(I ran across it because wine automatically sets links in ~/.wine/dosdevices/ for serial hardware. So I end up with com1-com34, where com33 and com34 are the actually useful ones, being the ttyUSB? units almost anyone likely uses nowadays...)
Except for those using GPS units that provide a PPS signal. I use this to be a stratum 1 time source. Of course, I only have one of these. And yes, this is on a desktop system. Our use is perhaps unique.
I agree that serial ports are rare. But not totally obsolete!
Roger Oberholtzer wrote:
On Thu, Aug 30, 2018 at 12:31 PM Peter Suetterlin pit@astro.su.se wrote:
(I ran across it because wine automatically sets links in ~/.wine/dosdevices/ for serial hardware. So I end up with com1-com34, where com33 and com34 are the actually useful ones, being the ttyUSB? units almost anyone likely uses nowadays...)
Except for those using GPS units that provide a PPS signal. I use this to be a stratum 1 time source. Of course, I only have one of these. And yes, this is on a desktop system. Our use is perhaps unique.
Yes, but that's one port, not 32, is it?
I agree that serial ports are rare. But not totally obsolete!
Definitely not, and I highly appreciated my old laptop (Samsung P560) that did have a real serial port. We use serial a lot, but even the crasiest machine (central control hub for many of the telescope devices) only has 20 of them...
So I mostly wondered who (and why) changed the value to 32 from the (AFAIK) default 4....
On 08/30/2018 07:22 AM, Peter Suetterlin wrote:
Yes, but that's one port, not 32, is it?
Many years ago, I used to work on mini-computers that had hundreds of ports. This is the environment that Unix was created in.
James Knott wrote:
On 08/30/2018 07:22 AM, Peter Suetterlin wrote:
Yes, but that's one port, not 32, is it?
Many years ago, I used to work on mini-computers that had hundreds of ports. This is the environment that Unix was created in.
James, I'm the last one that wants to get rid of serial ports. We (at work) depend a lot on them. Still, creating 32 device files for millions of users where only a handfull has actually more than one or two installed is somewhat bloated IMHO.
I expect you create more support traffic from users not knowing what their proper serial port is (cf. my wine example) than from people complaining only 8 (or 4) of their ports work without adding a kernel parameter ;^>
On 08/30/2018 09:53 AM, Peter Suetterlin wrote:
James, I'm the last one that wants to get rid of serial ports. We (at work) depend a lot on them. Still, creating 32 device files for millions of users where only a handfull has actually more than one or two installed is somewhat bloated IMHO.
As I mentioned, I suspect this sort of thing was inherited from Unix practice, back when serial ports were common. Also, how much in the way of resources does this consume? Software designed to handle multiple devices, as was what I wrote for my IMSAI, can handle any practical number of them. What is the harm of having that? When I look in /dev, I see a lot of devices that I never use, yet support has to be there for those who do.
BTW, I just looked at my system and see 64 tty and 32 ttyS listed. How much memory, CPU, etc., do they consume, if not connected to anything?
On 2018-08-30 10:07 a.m., James Knott wrote:
As I mentioned, I suspect this sort of thing was inherited from Unix practice, back when serial ports were common. Also, how much in the way of resources does this consume? Software designed to handle multiple devices, as was what I wrote for my IMSAI, can handle any practical number of them.
My experience with the PDP-11 and a Motoroal box that had 128 serial ports on the back as shipped was that the hardware actually did a lot of work, the UARETS were pretty smarts and the on-board hardware often had deep caches.
IIR three was one PDP-11 device that had what amounted to DMA, but they called it something else. You told the board where there was a control block in memory and that was fetched by 'dma' and that also pointed to a buffer of characters. For forms/rewrite or 'cat'ing files, this was great, very little CPU load.
I do recall from Dr Dobbs that some micro boards didn't have proper UARTS and did serial ports using the CPU flip a 1-bit IO port one and off with the 'correct' timing. Hellishly CPU intensive!
Anton Aylward wrote:
On 2018-08-30 10:07 a.m., James Knott wrote:
As I mentioned, I suspect this sort of thing was inherited from Unix practice, back when serial ports were common. Also, how much in the way of resources does this consume? Software designed to handle multiple devices, as was what I wrote for my IMSAI, can handle any practical number of them.
My experience with the PDP-11 and a Motoroal box that had 128 serial ports on the back as shipped was that the hardware actually did a lot of work, the UARETS were pretty smarts and the on-board hardware often had deep caches.
Guys, it's not really on-topic here.
James Knott wrote:
As I mentioned, I suspect this sort of thing was inherited from Unix practice, back when serial ports were common.
In the reply from Stefan you can see that this is an openSUSE specific thing that had been done because someone with two (or more) multiport cards complained about missing OOTB support. Has nothing to do with unix history. The vanilla kernel default still seems to be 4 or 8.
Also, how much in the way of resources does this consume?
None. Did I complain about resources? I don't want to kick out serial support, I don't want to reduce CONFIG_SERIAL_8250_NR_UARTS (increasing that was well sensible). I want a sort-of clean /dev directory that doesn't list too much useless stuff. Or do you want to get rid of udev and get back to a static /dev that just has everything that could ever be used?
BTW, I just looked at my system and see 64 tty and 32 ttyS listed. How much memory, CPU, etc., do they consume, if not connected to anything?
And now you connect a serial-to-USB converter, and fire up some Windows program via wine that needs to talk to the device connected there. And you have to guess which of the 33 COM devices offered is the correct one....
On Thu, 2018-08-30 at 10:07 -0400, James Knott wrote:
On 08/30/2018 09:53 AM, Peter Suetterlin wrote: As I mentioned, I suspect this sort of thing was inherited from Unix practice, back when serial ports were common. Also, how much in the way of resources does this consume?
Essentially nothing. This seems like optimization for the sake of optimization in the most theoretical sense.
When I look in /dev, I see a lot of devices that I never use,
Yep.
Am 30.08.2018 um 16:07 schrieb James Knott:
On 08/30/2018 09:53 AM, Peter Suetterlin wrote:
James, I'm the last one that wants to get rid of serial ports. We (at work) depend a lot on them. Still, creating 32 device files for millions of users where only a handfull has actually more than one or two installed is somewhat bloated IMHO.
As I mentioned, I suspect this sort of thing was inherited from Unix practice, back when serial ports were common.
No, it was not. The commit I mentioned increased the hard limit from 16 to 32 (in order to support more than one 8-port-serial board plus one or two onboard ports, see the mentioned bugzilla).
But it increased the default number from 8 to 32 at the same time (which is something the few people with more than, say, 4 ports in their machine can set easily with a boot parameter).
Also, how much in the way of resources does this consume?
Well, not too much. But it can confuse users, like Peter's wine example clearly shows.
Most people really would not expect their first plugged in usb-serial device to turn up as "com33:" in wine.
On 08/30/2018 11:01 AM, Stefan Seyfried wrote:
Most people really would not expect their first plugged in usb-serial device to turn up as "com33:" in wine.
One thing I've noticed is that when a USB serial port is used in Linux, it will always have the same ID, no matter which port it's plugged into. With Windows, on the same computer, the COM port number will change with the USB port used. Now that's confusing!
On Donnerstag, 30. August 2018 17:18:02 CEST James Knott wrote:
On 08/30/2018 11:01 AM, Stefan Seyfried wrote:
Most people really would not expect their first plugged in usb-serial device to turn up as "com33:" in wine.
One thing I've noticed is that when a USB serial port is used in Linux, it will always have the same ID, no matter which port it's plugged into. With Windows, on the same computer, the COM port number will change with the USB port used. Now that's confusing!
Always the same name is only guranteed as long as you only have one converter. Add a few and some external hub, and it gets almost random.
As almost always with USB, manufacturers are to blame here. Most devices have either no serial number, or a fixed one (FTDI clones). So the device itself can not provide a stable identifier*.
On Linux, there is a udev rule to make the devices recognizable, i.e. by providing symlinks with a speaking name. These are based on Vendor/Product, serial number, or physical location in the USB tree. Symlinks are generated in /dev/serial/by-{path,id}/
AFAIK, Windows only uses the physical path if the device has no serial number, and even that can be changed IIRC in the registry or the like.
Kind regards,
Stefan
PS: Some device *do* have unique serial numbers factory programmed. For the Silabs cp210x, there is a tool to reprogram the device, so you can at least generate locally unique ids.
On 2018-08-30 9:53 a.m., Peter Suetterlin wrote:
James, I'm the last one that wants to get rid of serial ports. We (at work) depend a lot on them. Still, creating 32 device files for millions of users where only a handfull has actually more than one or two installed is somewhat bloated IMHO.
This is in the category of "yes. it used to be, but we changed all that". It used to be that device nodes were actual nodes on the FS, they existed there on the FS even when the machine was down. You could mount the root FS on another machine under /mnt/disk and see them there.
Somewhere that as changed and the device nodes are now a sort of 'visualized' thing. I forget when this occurred. Maybe someone else can help here.
if you run the 'mount' command you will see that /dev is not a proper dis-bound FS:
devtmpfs on /dev type devtmpfs (rw,nosuid,size=1941496k,nr_inodes=485374,mode=755)
So what is 'devtmpfs'? <quote src="https://en.wikipedia.org/wiki/Device_file#devfs"> Maintaining these special files on a physically implemented file system (i.e. harddrive) is inconvenient, and as it needs kernel assistance anyway, the idea arose of a special-purpose logical file system that is not physically stored. </quote>
As for the number, I think that's a confurable as well.
Last night I saw upon the stair, A little man who wasn't there, He wasn't there again today Oh, how I wish he'd go away...
On 08/30/2018 07:15 AM, Roger Oberholtzer wrote:
I agree that serial ports are rare. But not totally obsolete!
A lot of network and telecom gear is initially configured via the serial port. In fact, some Cisco equipment now has built in USB - serial converter. Also, routers often have a serial port, connected to a modem, for back door access.
Peter Suetterlin wrote:
Hi list,
I just noticed the serial_8250 driver in the opensuse kernel is set to support AND initialize/create 32 serial ports. Is this still useful on a nowadays desktop machine? And even if CONFIG_SERIAL_8250_NR_UARTS=32 is set, why not set CONFIG_SERIAL_8250_RUNTIME_UARTS to something more reasonable? (It's also set to 32).
I have a box with 8 serial ports, still running 3.12.67. In that one:
CONFIG_SERIAL_8250_NR_UARTS=16 CONFIG_SERIAL_8250_RUNTIME_UARTS=8
I get 8 ports at runtime.
I know I can override it with 8250.nr_uarts kernel parameter, but it would be more logical that this is used by someone who really has a lot of serial ports.
32 does seem a pretty odd default.
Per Jessen wrote:
I have a box with 8 serial ports, still running 3.12.67. In that one:
CONFIG_SERIAL_8250_NR_UARTS=16 CONFIG_SERIAL_8250_RUNTIME_UARTS=8
I get 8 ports at runtime.
Obviously not a TW system with recent kernel-default :D
I know I can override it with 8250.nr_uarts kernel parameter, but it would be more logical that this is used by someone who really has a lot of serial ports.
32 does seem a pretty odd default.
Yep, that's why I'm asking. But it's not really something for a bug report, is it?
Am 30.08.2018 um 14:08 schrieb Peter Suetterlin:
Per Jessen wrote:
I have a box with 8 serial ports, still running 3.12.67. In that one:
CONFIG_SERIAL_8250_NR_UARTS=16 CONFIG_SERIAL_8250_RUNTIME_UARTS=8
I get 8 ports at runtime.
Obviously not a TW system with recent kernel-default :D
I know I can override it with 8250.nr_uarts kernel parameter, but it would be more logical that this is used by someone who really has a lot of serial ports.
32 does seem a pretty odd default.
Yep, that's why I'm asking. But it's not really something for a bug report, is it?
I'd ask on opensuse-kernel, though, as nobody is reading opensuse-factory anymore anyway.
Since CONFIG_SERIAL_8250_RUNTIME_UARTS only sets the default for 8250.nr_uarts parameter, it should be safe to set it down to 4.
The real "hard" limit is CONFIG_SERIAL_8250_NR_UARTS which is fine at 32 (for me at least ;-)
Stefan Seyfried wrote:
Since CONFIG_SERIAL_8250_RUNTIME_UARTS only sets the default for 8250.nr_uarts parameter, it should be safe to set it down to 4.
The real "hard" limit is CONFIG_SERIAL_8250_NR_UARTS which is fine at 32 (for me at least ;-)
Yes, I completely agree! You don't want to have to recompile the kernel to support them, but adding a kernel boot parameter should really not be an issue...
On 08/30/2018 07:57 AM, Per Jessen wrote:
32 does seem a pretty odd default.
How much of this was inherited from Unix? Years ago, every console would require it's own serial port. There would also be ports used for remote communications.
BTW, I used to be a computer tech for a telecommunications company. Every system I worked on had many serial ports. One example I worked on would be the old Air Canada reservation system, where there were terminals at airports and travel agents around the world. On that network, there were a couple of dozen PDP-11s, each with up to 4 boards, with 8 serial ports on each board. Even though several terminals could share a port, through polling and concentrators, there were still a lot of ports needed.
30.08.2018 14:57, Per Jessen пишет:
32 does seem a pretty odd default.
Ubuntu has
CONFIG_SERIAL_8250_NR_UARTS=48 CONFIG_SERIAL_8250_RUNTIME_UARTS=32
So it is not something entirely specific to openSUSE.
Andrei Borzenkov wrote:
30.08.2018 14:57, Per Jessen пишет:
32 does seem a pretty odd default.
Ubuntu has
CONFIG_SERIAL_8250_NR_UARTS=48 CONFIG_SERIAL_8250_RUNTIME_UARTS=32
So it is not something entirely specific to openSUSE.
Right - I guess it's a kernel default that was changed at some point. For amusement, going even further back in time - in 2.6.25 :
CONFIG_SERIAL_8250_NR_UARTS=4 CONFIG_SERIAL_8250_RUNTIME_UARTS=4
:-)
On Friday, 31 August 2018 8:20 Per Jessen wrote:
Andrei Borzenkov wrote:
30.08.2018 14:57, Per Jessen ?????:
32 does seem a pretty odd default.
Ubuntu has
CONFIG_SERIAL_8250_NR_UARTS=48 CONFIG_SERIAL_8250_RUNTIME_UARTS=32
So it is not something entirely specific to openSUSE.
Right - I guess it's a kernel default that was changed at some point. For amusement, going even further back in time - in 2.6.25 :
CONFIG_SERIAL_8250_NR_UARTS=4 CONFIG_SERIAL_8250_RUNTIME_UARTS=4
:-)
OK, let's go for some amusement. We have such tool, it's called "git" and it can tell you rather quickly where that "some point" was. And in this particular case, it could even point you to bsc#652954 and this bug then to
http://www.spinics.net/lists/linux-serial/msg03020.html
I don't say I agree with the reasoning, personally I think that four would be reasonable default for openSUSE (and you don't even have to put the module parameter on kernel command line, that's what /etc/modprobe.d exists for), but there is really no need to pretend there is some dark mystery about the change(s).
Michal Kubecek
Am 31.08.2018 um 09:08 schrieb Michal Kubecek:
would be reasonable default for openSUSE (and you don't even have to put the module parameter on kernel command line, that's what /etc/modprobe.d exists for)
CONFIG_SERIAL_8250=y
I think this only really works without hackery with a kernel boot parameter ;)
On Friday, 31 August 2018 9:14 Stefan Seyfried wrote:
Am 31.08.2018 um 09:08 schrieb Michal Kubecek:
would be reasonable default for openSUSE (and you don't even have to put the module parameter on kernel command line, that's what /etc/modprobe.d exists for)
CONFIG_SERIAL_8250=y
I think this only really works without hackery with a kernel boot parameter ;)
Ah, right. But it's also something to think about, given vast majority of today's notebooks has no serial ports and vast majority of consumer desktops has them only as motherboard headers (so that you need to buy an extra bracket to actually use them).
But I'm afraid having the driver as a module would harm debugging boot issues using serial console so it will be probably safer to keep "Y" here.
Michal Kubecek
Am 31.08.2018 um 09:30 schrieb Michal Kubecek:
Ah, right. But it's also something to think about, given vast majority of today's notebooks has no serial ports and vast majority of consumer desktops has them only as motherboard headers (so that you need to buy an extra bracket to actually use them).
I even bought a PCI card some years ago to be able to use my serial dcf77 receiver for NTP ;)
But I'm afraid having the driver as a module would harm debugging boot issues using serial console so it will be probably safer to keep "Y" here.
Exactly. At least on SLES :-) I really like to be able to use "console=ttyS0" with an IPMI connected virtual serial port on our servers to avoid having to use horrible .NET (or even worse: Java) consoles via windows termial servers ;-)
Oh, and for debugging VMs and stuff in QEMU / KVM, the always built in serial console support is also nice.
Actually the best thing would probably be to enhance that driver to only create devices for ports, that are actually available. But then I think only very brave (and bored) people would really dare to touch this code ;-)
On Friday, 31 August 2018 9:37 Stefan Seyfried wrote:
Am 31.08.2018 um 09:30 schrieb Michal Kubecek:
But I'm afraid having the driver as a module would harm debugging boot issues using serial console so it will be probably safer to keep "Y" here.
Exactly. At least on SLES :-)
Oh, I was talking about openSUSE, I wouldn't dare to even think about it for SLE. :-)
Oh, and for debugging VMs and stuff in QEMU / KVM, the always built in serial console support is also nice.
Good point. I forgot VMs still have serial ports usable without buying extra hardware. (Even if I'm using the feature myself quite often.)
Actually the best thing would probably be to enhance that driver to only create devices for ports, that are actually available. But then I think only very brave (and bored) people would really dare to touch this code ;-)
That's what some people suggested in those earlier discussions. But nobody took the challenge. Can't say I'm surprised, though... :-)
Michal Kubecek
On 08/31/2018, 09:45 AM, Michal Kubecek wrote:
Actually the best thing would probably be to enhance that driver to only create devices for ports, that are actually available. But then I think only very brave (and bored) people would really dare to touch this code ;-)
That's what some people suggested in those earlier discussions. But nobody took the challenge. Can't say I'm surprised, though... :-)
Heh :D. I wrote and rewrote a lot of pieces in there. And the reason why we create ports which are not "available" is quite simple. You can use setserial on those /dev nodes to actually configure the port and make it available immediately...
So if you demand NR_UARTS via config, we create NR_UARTS for you – as simple as that.
thanks,
On 08/31/2018, 10:34 AM, Jiri Slaby wrote:
On 08/31/2018, 09:45 AM, Michal Kubecek wrote:
Actually the best thing would probably be to enhance that driver to only create devices for ports, that are actually available. But then I think only very brave (and bored) people would really dare to touch this code ;-)
That's what some people suggested in those earlier discussions. But nobody took the challenge. Can't say I'm surprised, though... :-)
Heh :D. I wrote and rewrote a lot of pieces in there. And the reason why we create ports which are not "available" is quite simple. You can use setserial on those /dev nodes to actually configure the port and make it available immediately...
Example:
qemu ... -serial stdio -chardev file,path=/tmp/ser,id=mychr -device isa-serial,iobase=0x1000,chardev=mychr
factory:~ # setserial /dev/ttyS0 /dev/ttyS0, UART: 16550A, Port: 0x03f8, IRQ: 4 factory:~ # setserial /dev/ttyS1 /dev/ttyS1, UART: unknown, Port: 0x02f8, IRQ: 3 factory:~ # echo a > /dev/ttyS1 -bash: echo: write error: Input/output error factory:~ # setserial /dev/ttyS1 port 0x1000 autoconfig factory:~ # echo a > /dev/ttyS1 factory:~ #
And "a" is suddenly in /tmp/ser on the host.
thanks,
Am 31.08.2018 um 10:57 schrieb Jiri Slaby:
On 08/31/2018, 10:34 AM, Jiri Slaby wrote:
Heh :D. I wrote and rewrote a lot of pieces in there. And the reason why
You *are* brave! ;-)
we create ports which are not "available" is quite simple. You can use setserial on those /dev nodes to actually configure the port and make it available immediately...
Example:
qemu ... -serial stdio -chardev file,path=/tmp/ser,id=mychr -device isa-serial,iobase=0x1000,chardev=mychr
factory:~ # setserial /dev/ttyS0 /dev/ttyS0, UART: 16550A, Port: 0x03f8, IRQ: 4 factory:~ # setserial /dev/ttyS1 /dev/ttyS1, UART: unknown, Port: 0x02f8, IRQ: 3 factory:~ # echo a > /dev/ttyS1 -bash: echo: write error: Input/output error factory:~ # setserial /dev/ttyS1 port 0x1000 autoconfig factory:~ # echo a > /dev/ttyS1 factory:~ #
And "a" is suddenly in /tmp/ser on the host.
But only if "Hardware" is present.
server:~ # ls /dev/ttyS* /dev/ttyS0 /dev/ttyS12 /dev/ttyS16 /dev/ttyS2 /dev/ttyS23 /dev/ttyS27 /dev/ttyS30 /dev/ttyS6 /dev/ttyS1 /dev/ttyS13 /dev/ttyS17 /dev/ttyS20 /dev/ttyS24 /dev/ttyS28 /dev/ttyS31 /dev/ttyS7 /dev/ttyS10 /dev/ttyS14 /dev/ttyS18 /dev/ttyS21 /dev/ttyS25 /dev/ttyS29 /dev/ttyS4 /dev/ttyS8 /dev/ttyS11 /dev/ttyS15 /dev/ttyS19 /dev/ttyS22 /dev/ttyS26 /dev/ttyS3 /dev/ttyS5 /dev/ttyS9 server:~ # setserial -bg /dev/ttyS* /dev/ttyS0 at 0x03f8 (irq = 4) is a 16550A /dev/ttyS1 at 0x02f8 (irq = 3) is a 16550A /dev/ttyS4 at 0x1c90 (irq = 17) is a 16550A server:~ # dmesg|grep ttyS [ 0.396050] 00:06: ttyS0 at I/O 0x3f8 (irq = 4, base_baud = 115200) is a 16550A [ 0.416797] 00:07: ttyS1 at I/O 0x2f8 (irq = 3, base_baud = 115200) is a 16550A [ 0.438146] 0000:00:03.3: ttyS4 at I/O 0x1c90 (irq = 17, base_baud = 115200) is a 16550A server:~ # lspci -s 0000:00:03.3 00:03.3 Serial controller: Intel Corporation 4 Series Chipset Serial KT Controller (rev 03)
"setserial /dev/ttyS16 port 0x1000 autoconfig" is not going to magically make an additional serial port appear on this machine ;-)
On 08/31/2018, 12:43 PM, Stefan Seyfried wrote:
"setserial /dev/ttyS16 port 0x1000 autoconfig" is not going to magically make an additional serial port appear on this machine ;-)
Ok, will setserial /dev/ttyS16 port 0x1000 baud_base 115200 auto_irq autoconfig do the job?
(You can omit auto_irq to rely on polling.)
thanks,
Am 31.08.2018 um 15:21 schrieb Jiri Slaby:
On 08/31/2018, 12:43 PM, Stefan Seyfried wrote:
"setserial /dev/ttyS16 port 0x1000 autoconfig" is not going to magically make an additional serial port appear on this machine ;-)
Ok, will setserial /dev/ttyS16 port 0x1000 baud_base 115200 auto_irq autoconfig do the job?
No (and how could it? there is only hardware for two serial ports plus one "virtual" in the Intel Management Engine on the board :-)
On 08/31/2018, 03:38 PM, Stefan Seyfried wrote:
Am 31.08.2018 um 15:21 schrieb Jiri Slaby:
On 08/31/2018, 12:43 PM, Stefan Seyfried wrote:
"setserial /dev/ttyS16 port 0x1000 autoconfig" is not going to magically make an additional serial port appear on this machine ;-)
Ok, will setserial /dev/ttyS16 port 0x1000 baud_base 115200 auto_irq autoconfig do the job?
No (and how could it? there is only hardware for two serial ports plus one "virtual" in the Intel Management Engine on the board :-)
Oh, you mean hardware. You still own a real HW these days :P?
Anyway, there is definitely some serial interface hiding at some weird address, only waiting for you to run setserial.
BTW I have nothing against lowering the runtime limit, given we are in 2018.
have (a lot of) fun,
Michal Kubecek wrote:
On Friday, 31 August 2018 8:20 Per Jessen wrote:
Andrei Borzenkov wrote:
30.08.2018 14:57, Per Jessen ?????:
32 does seem a pretty odd default.
Ubuntu has
CONFIG_SERIAL_8250_NR_UARTS=48 CONFIG_SERIAL_8250_RUNTIME_UARTS=32
So it is not something entirely specific to openSUSE.
Right - I guess it's a kernel default that was changed at some point. For amusement, going even further back in time - in 2.6.25 :
CONFIG_SERIAL_8250_NR_UARTS=4 CONFIG_SERIAL_8250_RUNTIME_UARTS=4
:-)
OK, let's go for some amusement. We have such tool, it's called "git" and it can tell you rather quickly where that "some point" was. And in this particular case, it could even point you to bsc#652954 and this bug then to
Right, that's what Stefan also posted yesterday.
I don't say I agree with the reasoning, personally I think that four would be reasonable default for openSUSE (and you don't even have to put the module parameter on kernel command line, that's what /etc/modprobe.d exists for),
Just fyi, there is no module, it is built-in. Kernel argument seems to be the only way.
but there is really no need to pretend there is some dark mystery about the change(s).
Nono, I wasn't trying to suggest anything like that.
On 31/08/2018 16:38, Michal Kubecek wrote:
On Friday, 31 August 2018 8:20 Per Jessen wrote:
Andrei Borzenkov wrote:
30.08.2018 14:57, Per Jessen ?????:
32 does seem a pretty odd default.
Ubuntu has
CONFIG_SERIAL_8250_NR_UARTS=48 CONFIG_SERIAL_8250_RUNTIME_UARTS=32
So it is not something entirely specific to openSUSE.
Right - I guess it's a kernel default that was changed at some point. For amusement, going even further back in time - in 2.6.25 :
CONFIG_SERIAL_8250_NR_UARTS=4 CONFIG_SERIAL_8250_RUNTIME_UARTS=4
:-)
OK, let's go for some amusement. We have such tool, it's called "git" and it can tell you rather quickly where that "some point" was. And in this particular case, it could even point you to bsc#652954 and this bug then to
http://www.spinics.net/lists/linux-serial/msg03020.html
I don't say I agree with the reasoning, personally I think that four would be reasonable default for openSUSE (and you don't even have to put the module parameter on kernel command line, that's what /etc/modprobe.d exists for), but there is really no need to pretend there is some dark mystery about the change(s).
Michal Kubecek
Personally I think 4 is too low, especially for those who have worked in electrical engineering contexts, at my last job I commonly had 8-10 ports sometimes more, this was partly because I had a 8 port moxa box plus a couple of other single cables and regularly a device or two with an inbuilt ftdi chip for usb->serial conversion.
Granted I'm an extreme case but given makers / hackers are one of our target audiences I can easily see some of them frequently using more then 4.
Am 02.09.2018 um 07:23 schrieb Simon Lees:
On 31/08/2018 16:38, Michal Kubecek wrote:
On Friday, 31 August 2018 8:20 Per Jessen wrote:
Andrei Borzenkov wrote:
30.08.2018 14:57, Per Jessen ?????:
32 does seem a pretty odd default.
Ubuntu has
CONFIG_SERIAL_8250_NR_UARTS=48 CONFIG_SERIAL_8250_RUNTIME_UARTS=32
So it is not something entirely specific to openSUSE.
Right - I guess it's a kernel default that was changed at some point. For amusement, going even further back in time - in 2.6.25 :
CONFIG_SERIAL_8250_NR_UARTS=4 CONFIG_SERIAL_8250_RUNTIME_UARTS=4
:-)
OK, let's go for some amusement. We have such tool, it's called "git" and it can tell you rather quickly where that "some point" was. And in this particular case, it could even point you to bsc#652954 and this bug then to
http://www.spinics.net/lists/linux-serial/msg03020.html
I don't say I agree with the reasoning, personally I think that four would be reasonable default for openSUSE (and you don't even have to put the module parameter on kernel command line, that's what /etc/modprobe.d exists for), but there is really no need to pretend there is some dark mystery about the change(s).
Michal Kubecek
Personally I think 4 is too low, especially for those who have worked in electrical engineering contexts, at my last job I commonly had 8-10 ports sometimes more, this was partly because I had a 8 port moxa box
boot parameter 8250.nr_uarts=32 will give you the old behaviour back.
plus a couple of other single cables and regularly a device or two with an inbuilt ftdi chip for usb->serial conversion.
Those are not affected by the 8250 driver.
Granted I'm an extreme case but given makers / hackers are one of our target audiences I can easily see some of them frequently using more then 4.
I can easily see them adding a simple boot parameter :-)
Am 02.09.2018 um 11:28 schrieb Stefan Seyfried:
Am 02.09.2018 um 07:23 schrieb Simon Lees:
On 31/08/2018 16:38, Michal Kubecek wrote:
On Friday, 31 August 2018 8:20 Per Jessen wrote:
Andrei Borzenkov wrote:
30.08.2018 14:57, Per Jessen ?????:
32 does seem a pretty odd default.
Right - I guess it's a kernel default that was changed at some point. For amusement, going even further back in time - in 2.6.25 :
CONFIG_SERIAL_8250_NR_UARTS=4 CONFIG_SERIAL_8250_RUNTIME_UARTS=4
OK, let's go for some amusement. We have such tool, it's called "git" and it can tell you rather quickly where that "some point" was. And in this particular case, it could even point you to bsc#652954 and this bug then to
http://www.spinics.net/lists/linux-serial/msg03020.html
I don't say I agree with the reasoning, personally I think that four would be reasonable default for openSUSE (and you don't even have to put the module parameter on kernel command line, that's what /etc/modprobe.d exists for), but there is really no need to pretend there is some dark mystery about the change(s).
Personally I think 4 is too low, especially for those who have worked in electrical engineering contexts, at my last job I commonly had 8-10 ports sometimes more, this was partly because I had a 8 port moxa box
boot parameter 8250.nr_uarts=32 will give you the old behaviour back.
Granted I'm an extreme case but given makers / hackers are one of our target audiences I can easily see some of them frequently using more then 4.
I can easily see them adding a simple boot parameter :-)
Really?
I've just been faced with this topic on arm64. I came to the conclusion, based on what is there for x86_64 and others, that it's much easier for me and other users that mind it to _lower_ the number of ttyS devices via /etc/default/grub config than to run into situations where the port you expect just doesn't show up and you don't know why.
http://bugzilla.opensuse.org/show_bug.cgi?id=1073193
So really there's two topics being mixed:
1) The maximum number of possible ttyS devices. 2) The number of ttyS devices actually shown in the file system.
The first is a decision that every serial driver is faced with. For 8250 the Kconfig documentation is not entirely clear and you only fully understand by reading what 8250_core.c does with the symbols: NR_UARTS is merely an upper bound and you need to set RUNTIME_UARTS high enough. Replacing the static port arrays used in virtually all serial drivers with a linked list would make the lookup go from O(1) to O(n), but with numbers up to 32 that might not matter that much?
The present ttyS devices seem an ugliness specific to the 8250 driver, and jslaby's argumentation for having them around doesn't apply to other architectures or at least I don't see why this one subsystem should allow to override any ACPI/DT-supplied configuration. Getting 8250 more in line with other serial drivers so that ttyS devices only show up after initialized (think ttyUSB) would be the most elegant solution, and I assume the number of users complaining would be as low as those complaining about NR_CPUS being higher than their respective system has.
Until then, keeping a high default seems safest for those that may want to hot-plug ports and for whom rebooting to bump 8250.nr_uarts would be inconvenient. Keep in mind not every openSUSE user runs a desktop. It'll also save kernel engineers from "invalid" Bugzilla tickets.
In the end, whatever we do about the 32 ttyS*, let's not forget there's still the 64 tty* next to them. And if some program looked specifically at ttyS rather than tty, then it would miss ttyUSB, ttyACM, ttyAMA and many other alternative device file names.
Regards, Andreas
Am 02.09.2018 um 18:40 schrieb Andreas Färber:
Am 02.09.2018 um 11:28 schrieb Stefan Seyfried:
Am 02.09.2018 um 07:23 schrieb Simon Lees:
Personally I think 4 is too low, especially for those who have worked in electrical engineering contexts, at my last job I commonly had 8-10 ports sometimes more, this was partly because I had a 8 port moxa box
boot parameter 8250.nr_uarts=32 will give you the old behaviour back.
Granted I'm an extreme case but given makers / hackers are one of our target audiences I can easily see some of them frequently using more then 4.
I can easily see them adding a simple boot parameter :-)
Really?
Yes, i can imagine that someone who is able to put a 200+$ PCIE card into his machine is also able to find out about the boot parameter.
I've just been faced with this topic on arm64. I came to the conclusion, based on what is there for x86_64 and others, that it's much easier for me and other users that mind it to _lower_ the number of ttyS devices via /etc/default/grub config than to run into situations where the port you expect just doesn't show up and you don't know why.
Well, but on arm almost every board still has its own kconfig (and probably still no hot-pluggable serial port cards), so it of course makes sense to then set the default to a number of ports thats likely to be available.
[...] The present ttyS devices seem an ugliness specific to the 8250 driver, and jslaby's argumentation for having them around doesn't apply to other architectures or at least I don't see why this one subsystem should allow to override any ACPI/DT-supplied configuration. Getting 8250 more in line with other serial drivers so that ttyS devices only show up after initialized (think ttyUSB) would be the most elegant solution, and I assume the number of users complaining would be as low as those complaining about NR_CPUS being higher than their respective system has.
Certainly, that would be the best solution, as only devices that have actual hardware present would show up.
Until then, keeping a high default seems safest for those that may want to hot-plug ports and for whom rebooting to bump 8250.nr_uarts would be inconvenient. Keep in mind not every openSUSE user runs a desktop. It'll also save kernel engineers from "invalid" Bugzilla tickets.
Do you know of any hot-plug capable, 8250-driven serial port cards? I don't. The only hot-pluggable serial cards I know of are (rather old nowadays) 3G/UMTS ExpressCards, but those actually are implemented on the USB part of ExpressCard, not PCIE and thus are driven by usbserial.
(Yes, I know that there are servers that can do PCI or PCIE hotplugging, but I don't deem them "common" or relevant to this discussion).
On 09/02/2018, 06:40 PM, Andreas Färber wrote:
The present ttyS devices seem an ugliness specific to the 8250 driver, and jslaby's argumentation for having them around doesn't apply to other architectures or at least I don't see why this one subsystem should allow to override any ACPI/DT-supplied configuration. Getting 8250 more in line with other serial drivers so that ttyS devices only show up after initialized (think ttyUSB) would be the most elegant solution, and I assume the number of users complaining would be as low as those complaining about NR_CPUS being higher than their respective system has.
Welcome to the legacy of ISA. You can initialize the ports only when a user tells you where they are… The longterm solution is to rewrite setserial not to use the actual /dev/ttyS, but some common single node which would create a ttyS node dynamically. My guess is nobody will ever implement this.
On the top of that, I personally don't think there is a box with more than 2 legacy ports which are not defined in PNP, ACPI, DTD, or other tables (the two being at 0x2f8 and 0x3f8). But I might be mistaken.
And we can indeed make the creation of the dummy nodes arch-dependent. Or even arch-or-config-dependent.
thanks,
On 09/02/2018, 07:23 AM, Simon Lees wrote:
Personally I think 4 is too low, especially for those who have worked in electrical engineering contexts, at my last job I commonly had 8-10 ports sometimes more, this was partly because I had a 8 port moxa box plus a couple of other single cables and regularly a device or two with an inbuilt ftdi chip for usb->serial conversion.
ttyUSB and ttyMX (or ttyMI) are not discussed here at all.
thanks,
On Sunday, 2 September 2018 7:23 Simon Lees wrote:
Personally I think 4 is too low, especially for those who have worked in electrical engineering contexts, at my last job I commonly had 8-10 ports sometimes more, this was partly because I had a 8 port moxa box plus a couple of other single cables and regularly a device or two with an inbuilt ftdi chip for usb->serial conversion.
Granted I'm an extreme case but given makers / hackers are one of our target audiences I can easily see some of them frequently using more then 4.
I already have to remove "quiet" from kernel command line and replace it by "net.ifnames=0 splash=0" on all my openSUSE systems, add something like "crashkernel=256M" on most and "console=tty0 console=ttyS0,115200" on some. My view may be biased therefore but I don't really understand why it's considered impossible for these makers / hackers to add one command line parameter.
Michal Kubecek
Am 31.08.2018 um 08:20 schrieb Per Jessen:
Andrei Borzenkov wrote:
30.08.2018 14:57, Per Jessen пишет:
32 does seem a pretty odd default.
Ubuntu has
CONFIG_SERIAL_8250_NR_UARTS=48 CONFIG_SERIAL_8250_RUNTIME_UARTS=32
So it is not something entirely specific to openSUSE.
Right - I guess it's a kernel default that was changed at some point. For amusement, going even further back in time - in 2.6.25 :
CONFIG_SERIAL_8250_NR_UARTS=4 CONFIG_SERIAL_8250_RUNTIME_UARTS=4
(All below is for x86_64 only, these defaults are arch specific, which is not a bad idea IMHO)
Upstream default for NR_UARTS was last changed from 4 to 32 during 2.6.27 development cycle with commit
commit 5cb04df8d3f03e37a19f2502591a84156be71772 Author: Ingo Molnar mingo@elte.hu Date: Sun May 4 19:49:04 2008 +0200
x86: defconfig updates
refresh 32-bit defconfig too, and update the 64-bit configs as well, the defconfig should be much more useful by default, so most of the updates are the enabling of various options.
Signed-off-by: Ingo Molnar mingo@elte.hu Signed-off-by: Thomas Gleixner tglx@linutronix.de
The default for RUNTIME_UARTS was always at 4.
...but if you want that changed for openSUSE, this is still the wrong list IMVHO.
Am 30.08.2018 um 12:30 schrieb Peter Suetterlin:
Hi list,
I just noticed the serial_8250 driver in the opensuse kernel is set to support AND initialize/create 32 serial ports.
It took you almost 8 years to notice ;-)
commit 85c87e3ee0de95bc7eb4710bb051840fbd70e027 Author: Greg Kroah-Hartman gregkh@suse.de Date: Thu Nov 11 10:37:05 2010 -0800
- Update config files. (bnc#) increase the number of possible and default uarts for users with multi-port serial cards for the i386 and x86-64 default configs.
diff --git a/config/i386/default b/config/i386/default index 96bd6b356b..c487b7fba5 100644 --- a/config/i386/default +++ b/config/i386/default @@ -2804,8 +2804,8 @@ CONFIG_FIX_EARLYCON_MEM=y CONFIG_SERIAL_8250_PCI=y CONFIG_SERIAL_8250_PNP=y CONFIG_SERIAL_8250_CS=m -CONFIG_SERIAL_8250_NR_UARTS=16 -CONFIG_SERIAL_8250_RUNTIME_UARTS=8 +CONFIG_SERIAL_8250_NR_UARTS=32 +CONFIG_SERIAL_8250_RUNTIME_UARTS=32 # CONFIG_SERIAL_8250_EXTENDED is not set
# diff --git a/config/x86_64/default b/config/x86_64/default index 00e6782eeb..101242619f 100644 --- a/config/x86_64/default +++ b/config/x86_64/default @@ -2659,8 +2659,8 @@ CONFIG_FIX_EARLYCON_MEM=y CONFIG_SERIAL_8250_PCI=y CONFIG_SERIAL_8250_PNP=y CONFIG_SERIAL_8250_CS=m -CONFIG_SERIAL_8250_NR_UARTS=16 -CONFIG_SERIAL_8250_RUNTIME_UARTS=8 +CONFIG_SERIAL_8250_NR_UARTS=32 +CONFIG_SERIAL_8250_RUNTIME_UARTS=32 # CONFIG_SERIAL_8250_EXTENDED is not set
#
https://bugzilla.opensuse.org/show_bug.cgi?id=652954
git repo on https://github.com/openSUSE/kernel-source
Stefan Seyfried wrote:
Am 30.08.2018 um 12:30 schrieb Peter Suetterlin:
Hi list,
I just noticed the serial_8250 driver in the opensuse kernel is set to support AND initialize/create 32 serial ports.
It took you almost 8 years to notice ;-)
Hey, I never claimed to be an investigative Usain Bolt :D
I had actually 'noticed' earlier, but so far never cared asking for the when and why. So thanks for digging this out.
(Just wondering if I would need my second hand to finger-count the users that need OOTB support for several multiport cards.... ;^> )
Gentle reader,
Am 30.08.2018 um 12:30 schrieb Peter Suetterlin:
Hi list,
I just noticed the serial_8250 driver in the opensuse kernel is set to support AND initialize/create 32 serial ports. Is this still useful on a nowadays desktop machine?
it depends, how You do define a desktop. A LInux powered scanner checkout is somehow a hybrid between a desktop and an embedded systems, and nowadays always networked. Here go cards from vendors like Comtrol, providing up to 32 ports. The serial lines are used to control the special keyboard, scanner, balance, customer display, card reader, cash drawer, printer, and, and, and...
Moving the stuff to the embedded tree?
Yours sincerely
Christoph-Erdmann Pfeiler
And even if CONFIG_SERIAL_8250_NR_UARTS=32 is set, why not set CONFIG_SERIAL_8250_RUNTIME_UARTS to something more reasonable? (It's also set to 32).
I know I can override it with 8250.nr_uarts kernel parameter, but it would be more logical that this is used by someone who really has a lot of serial ports.
(I ran across it because wine automatically sets links in ~/.wine/dosdevices/ for serial hardware. So I end up with com1-com34, where com33 and com34 are the actually useful ones, being the ttyUSB? units almost anyone likely uses nowadays...)
-
Adam Tauno Williams -
Andreas Färber -
Andrei Borzenkov -
Anton Aylward -
Brüns, Stefan -
Christoph-Erdmann Pfeiler -
James Knott -
Jiri Slaby -
Knurpht-openSUSE -
Michal Kubecek -
Per Jessen -
Peter Suetterlin -
Roger Oberholtzer -
Simon Lees -
Stefan Seyfried