when enable "c" states , COM port were not worked at high baudrate

Hi all,

When i disable the “c” states in bios side , com port detected the "receive buffer overrun " in windows 10.

When i enable the “c” states in bios side, cpu is not enter into acpi c states if the com port used high baudrate to do data transfer in windows 10 where it used the inbox driver.

It uses the pnpo500 pnp pc device.

How i can fix this issue in windows sample driver 10 of serenum to check the driver enter into acpi c states to fix it were working in high baudrate ?

when i check in PassMark where com port detected the receive buffer overrun.

Could you please help on this issue to fix in windows sample driver for serial port.

Regards,
Prabhakar V

Maybe this is because PassMark does not support very high speed serial ports well. Look for more specialized benchmark for serial I/O. Good design of the driver probably can help too, because C states interfere with latency of interrupt handling. A custom driver for your device can do interrupt moderation or even disable C states on the CPU it runs on. Be creative, try to think out of the box :slight_smile:

– pa

Didn’t we already see this post… like, last week?

Peter
OSR
@OSRDrivers

when enable “c” states , COM port were not worked at high baudrate
[Peter]Didn’t we already see this post… like, last week?’
[Prabhakar] yes i have posted already but i need to see that when we enable the c states in bios side , it were working for high baudrate.

What will be the impact when we enable the c states it doesn’t work for high baudrate in windows 10 where showing receive buffer overrun in inbox driver.

What will be imapct when we enable the c states it doesnt work ?

What i have to do in windows sample driver code and fix this error?

if we disbale it is working for high baudrate in passmark tool.

On Jul 16, 2017, at 11:35 PM, xxxxx@gmail.com xxxxx@lists.osr.com wrote:

when enable “c” states , COM port were not worked at high baudrate
[Peter]Didn’t we already see this post… like, last week?’
[Prabhakar] yes i have posted already but i need to see that when we enable the c states in bios side , it were working for high baudrate.

What will be the impact when we enable the c states it doesn’t work for high baudrate in windows 10 where showing receive buffer overrun in inbox driver.

What will be imapct when we enable the c states it doesnt work ?
What i have to do in windows sample driver code and fix this error?
if we disbale it is working for high baudrate in passmark tool.

What are you expecting here? The answers are not going to change. As I have tried to tell you in public and in private, there is no magic answer here. The slowed down CPU can’t get around to service your interrupt before the hardware FIFO fills. So, you either turn off the use of C states, you change the level at which you get the interrupt, or you configure a larger buffer. That’s it. There are no other choices. That means you need to know your hardware, to know how the FIFOs are configured. I don’t think you know that yet.

Tim Roberts, xxxxx@probo.com
Providenza & Boekelheide, Inc.

Hi Tim,

Is there any option to disable the c states in Driver side when we enable the BIOS c state.

Is there any api to read the configuration value of BIOS chnanged of c states.

Regards,
Prabhakar V

xxxxx@gmail.com xxxxx@lists.osr.com wrote:

Is there any option to disable the c states in Driver side when we enable the BIOS c state.

Have you searched for this? I found a couple of articles that talk
about potential methods of altering the power behavior.

HOWEVER, you are looking in the wrong direction. Your hardware and
driver ought to be able to handle this. Have you done any experiments
with the FIFO levels, as I mentioned?


Tim Roberts, xxxxx@probo.com
Providenza & Boekelheide, Inc.

> What are you expecting here? The answers are not going to change.

That means you need to know your hardware, to know how the FIFOs are configured.
I don’t think you know that yet.

Well, we were all inexperienced once, right. Therefore, “please guide the OP in the same” and explain to him (2^(N!))! times why “ports were not worked” (in fact, I don’t know what the argument to the above function may be like in this context - if it is 2 this function evaluates just to 24, which is , apparently, insufficient, but at 3 it already grows to the factorial of 64, which is, probably, a way too much even by your standards) …

Anton Bassov