Oliver Mangold
2016-Oct-09 14:04 UTC
[syslinux] Enumeration of ISA serial ports inconsistent between Linux and Syslinux
On 09.10.2016 14:49, Gene Cumm wrote:> Excellent job digging up the differences. Looks like the code comes > from commit ID c4fa331 but is much older. The code comes from 7916325 > which is derived from the ASM in beaaa4f. It appears to me that it > was used to check the presence of a serial port and it was assumed the > order at that memory address would be consistent and either the proper > value or 0. > > I'm trying to dig for some documentation like Ralph Brown's Interrupt > list. Have you checked for firmware updates? Have you tried > experimenting with redoing what serial port is assigned what IO base > address to make it consistent between Syslinux and Linux? > > Alternatively, have you considered specifying the full IO address > instead of the low number (like "0x3F8")? > >Hi, actually I didn't do much with Syslinux myself. I found the issue with Grub2 first, and after I brief exchange about it on the Linux-Serial mailing list I decided to look up how Syslinux handles this, and found it has the same problem as Grub2. So I decided to do a good deed and report it to you, too :) As I understand the Supermicro BIOS, the issue could be fixed in the BIOS settings, by manually changing the ports to the default (Linux) order. Nonetheless the vendor default seems to be COM0=2f8, COM1=3f8. I don't have enough different boards to play with to give you an accurate answer on which SM boards/firmware revisions are affected, but it isn't the first time I have seen something like this.> RBIL MEMORY.LST release 61 starting at line 31: > > --------S-M00400000-------------------------- > MEM 0040h:0000h - BASE I/O ADDRESS OF FIRST SERIAL I/O PORT > Size: WORD > Notes: the BIOS sets this word to zero if is unable to find any serial ports > at the addresses it is programmed to check at boot > DOS and BIOS serial device numbers may be redefined by re-assigning > these values of the base I/O addresses stored here > > > > So the behavior of Syslinux makes sense since the sequence numbers can > be re-assigned by the firmware (in this case, the CSM of the EFI > firmware) by moving the values around.I'm quite aware of this, and I would even tend to agree with you that this behavior makes sense. Unfortunately it seems, though, that both Linux and OpenBSD use the traditional static ordering without looking at the BIOS info, and at least for Linux I get the impression that it is quite unlikely that this will change anytime soon. Here is the thread I started on Linux-Serial, in case you want to read Greg's answer for yourself: http://www.spinics.net/lists/linux-serial/msg23997.html I don't want to stir up any complicated discussion about who is right and who is wrong, but as a user I would prefer the behavior to be consistent between all OSes and bootloaders. Best regards, Oliver
Gene Cumm
2016-Oct-09 14:53 UTC
[syslinux] Enumeration of ISA serial ports inconsistent between Linux and Syslinux
On Sun, Oct 9, 2016 at 10:04 AM, Oliver Mangold via Syslinux <syslinux at zytor.com> wrote:> On 09.10.2016 14:49, Gene Cumm wrote: >> >> Excellent job digging up the differences. Looks like the code comes >> from commit ID c4fa331 but is much older. The code comes from 7916325 >> which is derived from the ASM in beaaa4f. It appears to me that it >> was used to check the presence of a serial port and it was assumed the >> order at that memory address would be consistent and either the proper >> value or 0. >> >> I'm trying to dig for some documentation like Ralph Brown's Interrupt >> list. Have you checked for firmware updates? Have you tried >> experimenting with redoing what serial port is assigned what IO base >> address to make it consistent between Syslinux and Linux? >> >> Alternatively, have you considered specifying the full IO address >> instead of the low number (like "0x3F8")? >> >> > Hi, > > actually I didn't do much with Syslinux myself. I found the issue with Grub2 > first, and after I brief exchange about it on the Linux-Serial mailing list > I decided to look up how Syslinux handles this, and found it has the same > problem as Grub2. So I decided to do a good deed and report it to you, too > :) As I understand the Supermicro BIOS, the issue could be fixed in the BIOS > settings, by manually changing the ports to the default (Linux) order. > Nonetheless the vendor default seems to be COM0=2f8, COM1=3f8. I don't have > enough different boards to play with to give you an accurate answer on which > SM boards/firmware revisions are affected, but it isn't the first time I > have seen something like this. > >> RBIL MEMORY.LST release 61 starting at line 31: >> >> --------S-M00400000-------------------------- >> MEM 0040h:0000h - BASE I/O ADDRESS OF FIRST SERIAL I/O PORT >> Size: WORD >> Notes: the BIOS sets this word to zero if is unable to find any serial >> ports >> at the addresses it is programmed to check at boot >> DOS and BIOS serial device numbers may be redefined by re-assigning >> these values of the base I/O addresses stored here >> >> >> >> So the behavior of Syslinux makes sense since the sequence numbers can >> be re-assigned by the firmware (in this case, the CSM of the EFI >> firmware) by moving the values around. > > I'm quite aware of this, and I would even tend to agree with you that this > behavior makes sense. Unfortunately it seems, though, that both Linux and > OpenBSD use the traditional static ordering without looking at the BIOS > info, and at least for Linux I get the impression that it is quite unlikely > that this will change anytime soon. Here is the thread I started on > Linux-Serial, in case you want to read Greg's answer for yourself: > > http://www.spinics.net/lists/linux-serial/msg23997.html > > I don't want to stir up any complicated discussion about who is right and > who is wrong, but as a user I would prefer the behavior to be consistent > between all OSes and bootloaders.And I think therein lies the issue. Due to differing interpretations, they shall never be consistent less your firmware is configured to match the traditional order. Older bootloaders and lesser OSs like DOS shall often use the order in RAM while some others shall often use the static list of IO ports to assign devices then use the RAM values to check their presence/validity. For yet another datapoint, check what a Windows OS does. I think the only way to have consistency is to fix the firmware config (and preferably for Supermicro to fix their defaults OR heavily document their reason for such a discrepancy). -- -Gene
Ady Ady
2016-Oct-09 15:16 UTC
[syslinux] Enumeration of ISA serial ports inconsistent between Linux and Syslinux
> I don't want to stir up any complicated discussion about who is right > and who is wrong, but as a user I would prefer the behavior to be > consistent between all OSes and bootloaders. > > Best regards, > > OliverIMHO, FWIW... Unfortunately, there is no such a thing as "consistency between all OSes and bootloaders". Changing a (default) behavior that has been in use for so long in Syslinux would mean - if I understood correctly this discussion / proposal - breaking backward compatibility in at least some cases. I don't like breaking backward compatibility, unless there is a very good reason. Considering that there is at least one alternative (i.e. using the I/O address), and that most PC-compatible computers use the classic "default" order / relations between serial ports and I/O addresses, I currently don't see this situation / reason to be "good enough" so as to change the default behavior in Syslinux. Again, IMHO and FWIW. As a side note, please remember that, in _some_ versions of Syslinux, some hex values are not parsed correctly by the SERIAL directive. As suggested in the Syslinux wiki, the workaround is to use the equivalent decimal values, which should be parsed correctly. Regards, Ady.> _______________________________________________ > Syslinux mailing list > Submissions to Syslinux at zytor.com > Unsubscribe or set options at: > http://www.zytor.com/mailman/listinfo/syslinux
H. Peter Anvin
2016-Oct-12 16:59 UTC
[syslinux] Enumeration of ISA serial ports inconsistent between Linux and Syslinux
On 10/09/16 07:53, Gene Cumm via Syslinux wrote:>>> >>> So the behavior of Syslinux makes sense since the sequence numbers can >>> be re-assigned by the firmware (in this case, the CSM of the EFI >>> firmware) by moving the values around. >> >> I'm quite aware of this, and I would even tend to agree with you that this >> behavior makes sense. Unfortunately it seems, though, that both Linux and >> OpenBSD use the traditional static ordering without looking at the BIOS >> info, and at least for Linux I get the impression that it is quite unlikely >> that this will change anytime soon. Here is the thread I started on >> Linux-Serial, in case you want to read Greg's answer for yourself: >> >> http://www.spinics.net/lists/linux-serial/msg23997.html >> >> I don't want to stir up any complicated discussion about who is right and >> who is wrong, but as a user I would prefer the behavior to be consistent >> between all OSes and bootloaders. > > And I think therein lies the issue. Due to differing interpretations, > they shall never be consistent less your firmware is configured to > match the traditional order. Older bootloaders and lesser OSs like > DOS shall often use the order in RAM while some others shall often use > the static list of IO ports to assign devices then use the RAM values > to check their presence/validity. For yet another datapoint, check > what a Windows OS does. > > I think the only way to have consistency is to fix the firmware config > (and preferably for Supermicro to fix their defaults OR heavily > document their reason for such a discrepancy). >I would say, obviously, that the chief culprit here is SuperMicro; 3F8h and 2F8h as COM1 and COM2 (what Linux calls ttyS0 and ttyS1) dates back to the original IBM PC (after COM2 the assignments aren't so consistent.) In many ways I think Linux' behavior is wrong and it should have used the BIOS table to start out with, but that is water under the bridge, and I don't think anyone would have anticipated such a braindead move by a hardware vendor. I do not want to change Syslinux for this, because I think discovery can be even more complex for bootloader users, and if you really want a fixed sequence of addresses you can just specify the raw port address. -hpa
Maybe Matching Threads
- Enumeration of ISA serial ports inconsistent between Linux and Syslinux
- Enumeration of ISA serial ports inconsistent between Linux and Syslinux
- Enumeration of ISA serial ports inconsistent between Linux and Syslinux
- how do I find out if I am on a zfs filesystem
- isohybrid boot from logical partition