Mailing List Archive: Flow-control weirdness

One of our programmers was diagnosing a problem with a RAID driver on
Linux via serial console when he ran in to an interesting problem:

The driver would dump a bunch of debug output, then stop in the middle.
He'd bang return and about 16 characters of additional output would print.
Each time he banged return, he'd get another li'l chunk of output.

He called me over and I disabled hardware flow-control on the console's
port on the terminal server (Computone RAS2000) and then did a ^Ecd/^Eco
to cycle the port and apply the change. The rest of the output spooled
out, and I figured there was some sort of problem in the kernel's serial
console code with hardware flow-control.

To confirm the fix, I had him reproduce it again. The problem recurred
exactly the same way, even with no flow control.

Put flow-control back, cycled the port again and the reset of the output
flowed out.

For now, I've told hom to cycle the port when this happens.

I'm running Conserver 7.2.1 installed via handrolled RPM on a heavily
doctored RH 7.1 system.

Any clues, O Oracles of Serial Niftiness?

Thanks in advance,
Aaron

One thing to note here is that when using conserver with terminal
servers, you are not doing a close() and open() when you tell conserver
to reopen. You are doing a close() and connect(). Depending on the
implementation of ethernet->serial in your terminals erver, it may not
drop DTR when you do this. It may do nothing.

On Wed, 2003-03-12 at 14:56, Aaron Burt wrote:
> One of our programmers was diagnosing a problem with a RAID driver on
> Linux via serial console when he ran in to an interesting problem:
>
> The driver would dump a bunch of debug output, then stop in the middle.
> He'd bang return and about 16 characters of additional output would print.
> Each time he banged return, he'd get another li'l chunk of output.
>
> He called me over and I disabled hardware flow-control on the console's
> port on the terminal server (Computone RAS2000) and then did a ^Ecd/^Eco
> to cycle the port and apply the change. The rest of the output spooled
> out, and I figured there was some sort of problem in the kernel's serial
> console code with hardware flow-control.
>
> To confirm the fix, I had him reproduce it again. The problem recurred
> exactly the same way, even with no flow control.
>
> Put flow-control back, cycled the port again and the reset of the output
> flowed out.
>
> For now, I've told hom to cycle the port when this happens.
>
> I'm running Conserver 7.2.1 installed via handrolled RPM on a heavily
> doctored RH 7.1 system.
>
> Any clues, O Oracles of Serial Niftiness?
>
> Thanks in advance,
> Aaron
>
> _______________________________________________
> users mailing list
> users@conserver.com
> https://www.conserver.com/mailman/listinfo/users