serial driver bug

[Saveliy Tretiakov]

Hi.
I tested a new serial driver in a vmware with 4 serial ports.
It creates only one serial device and a symbolic link to it ("COM3");
When I write to "COM3" output goes to COM1 and mix with debug output there.
This is a bug imho.

[Hervé Poussineau]

Hi!

Saveliy Tretiakov a écrit :
>   I tested a new serial driver in a vmware with 4 serial
> ports.
>  It creates only one serial device and a symbolic link to it ("COM3");
>  When I write to "COM3" output goes to COM1 and mix with debug output there.
>  This is a bug imho. 
This is not a bug, it's a feature ;)
Serial stuff is not ready. Serial driver doesn't support reading, we 
don't have any serial enumerator (serenum), serial mouse driver directly 
reads and writes to port without using serial driver. Debug output does 
the same.

I'm planning to replace these drivers one after one. During this time, I 
don't want to break working stuff. So I decided to keep all the existing 
infrastructure, and create a parallel one. That's why I created COM3.
COM1 uses the old stuff (direct write access to the port)
COM3 uses the new serial driver, and redirects to COM1

If you have a second serial port, COM4 is also an "alias" for COM2.

Your 4 serial ports in vmware are a bit "out of norm". Most of PCs only 
have 2 ports. That's why I don't want to support more than the first 2 
serial ports during this transition period.

Hervé

[Saveliy Tretiakov]

Hervé Poussineau wrote:

>  
>  This is not a bug, it's a feature ;)
>  Serial stuff is not ready. Serial driver doesn't support reading, we 
>  don't have any serial enumerator (serenum), serial mouse driver 
>  directly reads and writes to port without using serial driver. Debug 
>  output does the same.
>
>  I'm planning to replace these drivers one after one. During this time, 
>  I don't want to break working stuff. So I decided to keep all the 
>  existing infrastructure, and create a parallel one. That's why I 
>  created COM3.
>  COM1 uses the old stuff (direct write access to the port)
>  COM3 uses the new serial driver, and redirects to COM1
>  
Existing infrastructure doesn't create any symbolic links to com 
port.(At least on my machine...)
So, I can't see how we can break things by creating "COM1" alias for COM1. 

COM3 and COM4 aliases still point to COM1 and COM2, and this can really 
break debug output and serial mouse.
Just renaming symbolic links can't solve the problem. In my opinion, the 
right solution is to disable COM1 and COM2 at all,
and make COM3 and COM4 symbolic links point to real COM3 and COM4. So, I 
will be able to hack on serial driver
without touching debug output :)

>   If you have a second serial port, COM4 is also an
> "alias" for COM2. 
I have a second serial port, but COM4 is not created...

[Royce Mitchell III]

> >   
> Existing infrastructure doesn't create any symbolic links to com 
>  port.(At least on my machine...)
>  So, I can't see how we can break things by creating "COM1" alias for 
>  COM1.
>  COM3 and COM4 aliases still point to COM1 and COM2, and this can 
>  really break debug output and serial mouse.
>  Just renaming symbolic links can't solve the problem. In my opinion, 
>  the right solution is to disable COM1 and COM2 at all,
>  and make COM3 and COM4 symbolic links point to real COM3 and COM4. So, 
>  I will be able to hack on serial driver
>  without touching debug output :)
>  
I've got a machine at work with... hmm... 6 or 8 serial ports... 
something like that... I'd be happy to test it if somebody thinks it's 
ready. If you want I'll give you details on exactly what hardware it is 
when I get there today.

[Robert Köpferl]

Be aware that it makes a difference  wether you have got a so called 
multi serial card or  several plain old serial HW. I may be wrong, but 
isn't 4 the limit. Due to 'reserved' ports for that kind of HW?

Royce Mitchell III wrote:
>   
> > >   
> > Existing infrastructure doesn't create any symbolic links to com 
> >  port.(At least on my machine...)
> >  So, I can't see how we can break things by creating "COM1" alias for 
> >  COM1.
> >  COM3 and COM4 aliases still point to COM1 and COM2, and this can 
> >  really break debug output and serial mouse.
> >  Just renaming symbolic links can't solve the problem. In my opinion, 
> >  the right solution is to disable COM1 and COM2 at all,
> >  and make COM3 and COM4 symbolic links point to real COM3 and COM4. So, 
> >  I will be able to hack on serial driver
> >  without touching debug output :)
> >  
>  I've got a machine at work with... hmm... 6 or 8 serial ports... 
>  something like that... I'd be happy to test it if somebody thinks it's 
>  ready. If you want I'll give you details on exactly what hardware it is 
>  when I get there today.
>  
>  _______________________________________________
>  Ros-dev mailing list
>  Ros-dev(a)reactos.com
>  http://reactos.com:8080/mailman/listinfo/ros-dev
>

[Royce Mitchell III]

Robert Köpferl wrote:

>   Be aware that it makes a difference  wether you have
> got a so called 
>  multi serial card or  several plain old serial HW. I may be wrong, but 
>  isn't 4 the limit. Due to 'reserved' ports for that kind of HW?
>  
It's a multi-serial card. The 4 limit for plain serial is due to 
reserved/limited irq if I understand correctly.

[Hervé Poussineau]

Saveliy Tretiakov a écrit :
>   I have a second serial port, but COM4 is not
> created... 
Filip gave me the reason on IRC:
"It's due to the root bus driver, that only enumerates the first 
device... We need to get ACPI working in order to enumerate the serial 
port."

I can't remove existing stuff for debug output and serial mouse support 
because enumeration needs first to be corrected.

I've committed stuff more to share my existing work and have a save of 
what I've done than to have a working serial driver in ReactOS.

Btw, current serial driver is only usable in very specific situations, 
and I've disabled it in registry.

Hervé

[Mike Nordell]

Hervé Poussineau wrote:

>   Saveliy Tretiakov a écrit :
> >   I have a second serial port, but COM4 is not
> > created... 
>  Filip gave me the reason on IRC:
>  "It's due to the root bus driver, that only enumerates the first
>  device... We need to get ACPI working in order to enumerate the
>  serial port." 
Does this imply (serial ports on) ReactOS won't work on non-ACPI systems, or
will ACPI data be faked for non-ACPI systems?

/Mike

[Hervé Poussineau]

Mike Nordell a écrit :
> > >   I have a second serial port, but COM4 is not
> > > created... 
> > Filip gave me the reason on IRC:
> > "It's due to the root bus driver, that only enumerates the first
> > device... We need to get ACPI working in order to enumerate the
> > serial port."  
>  
>  Does this imply (serial ports on) ReactOS won't work on non-ACPI systems, or
>  will ACPI data be faked for non-ACPI systems? 
ReactOS MUST work on non-ACPI systems.
On ACPI systems, ACPI will enumerate all your serial ports, even 
non-standard ones.
On all systems (ACPI and non-ACPI), standard serial ports will be probed 
to test their existence.

Hervé

[Saveliy Tretiakov]

>   ReactOS MUST work on non-ACPI systems.
>  On ACPI systems, ACPI will enumerate all your serial ports, even 
>  non-standard ones.
>  On all systems (ACPI and non-ACPI), standard serial ports will be 
>  probed to test their existence. 

I think, to correctly enumerate com ports  in this situation, you need 
to remove enumeration
code from pnp routines. What do you think about creating something like 
SerialEnumerateComPorts() routine
and call it from DriverEntry? If you are not working on this now, I can 
try to implement it. The enumeration process
is described in "Enumerating Legacy COM Ports" article from DDK.

[Saveliy Tretiakov]

Saveliy Tretiakov wrote:

>  
> >   ReactOS MUST work on non-ACPI systems.
> >  On ACPI systems, ACPI will enumerate all your serial ports, even 
> >  non-standard ones.
> >  On all systems (ACPI and non-ACPI), standard serial ports will be 
> >  probed to test their existence. 
>
>
>  I think, to correctly enumerate com ports  in this situation, you need 
>  to remove enumeration
>  code from pnp routines. What do you think about creating something 
>  like SerialEnumerateComPorts() routine
>  and call it from DriverEntry? If you are not working on this now, I 
>  can try to implement it. The enumeration process
>  is described in "Enumerating Legacy COM Ports" article from DDK.
>  
Oops, I  haven't seen  your latest changes from svn.
Maybe you already did it...

[Hervé Poussineau]

Saveliy Tretiakov a écrit :
> >   I think, to
> > correctly enumerate com ports  in this situation, you need 
> >  to remove enumeration
> >  code from pnp routines. What do you think about creating something 
> >  like SerialEnumerateComPorts() routine
> >  and call it from DriverEntry? If you are not working on this now, I 
> >  can try to implement it. The enumeration process
> >  is described in "Enumerating Legacy COM Ports" article from DDK.
> >  
>  Oops, I  haven't seen  your latest changes from svn.
>  Maybe you already did it... 
Yes, it's done.
See DetectLegacyDevices() in legacy.c. This method is called at the end 
of DriverEntry.
This is this functionality that permits detection of 2 serial ports even 
if ACPI enumeration and root bus enumeration don't fully work.

Hervé