linux-kernel - Re: 2.6.25.3: serial problem (minicom)

lists.openwall.net		lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC
Open Source and information security mailing list archives

Hash Suite for Android: free password hash cracker in your pocket

[<prev] [next>] [<thread-prev] [day] [month] [year] [list]

Date:	Fri, 20 Jun 2008 06:22:20 -0500 (CDT)
From:	"R.L. Horn" <lists@...tcheap.org>
To:	Hans-Peter Jansen <hpj@...la.net>
cc:	linux-kernel@...r.kernel.org
Subject: Re: 2.6.25.3: serial problem (minicom)

On Fri, 20 Jun 2008, Hans-Peter Jansen wrote:

> Alan, I got to test this by applying the changeset (Olivier, many thanks
> for your valuable hint, I'm sure, I will reuse this knowledge soon), to
> the otherwise unchanged kernel, but unfortunately, it doesn't solve my
> issue.
>
> A different patch must have changed the behavior/state of some RS232 lines
> in the 2.6.25 time frame,

There was a deliberate change in DTR behavior, though I'm not up on the 
details.  If you have a copy of 2.6.25.something handy and want to check 
that that's the problem, you might look at drivers/serial/serial_core.c. 
Round about line 2160 (in uart_configure_port()), you'll see:

   /*
    * Ensure that the modem control lines are de-activated.
    * keep the DTR setting that is set in uart_set_options()
    * We probably don't need a spinlock around this, but
    */
   spin_lock_irqsave(&port->lock, flags);
   port->ops->set_mctrl(port, port->mctrl & TIOCM_DTR);

Change the last line to:

   port->ops->set_mctrl(port, 0);

which reverts to 2.6.24 behavior.

If your problem isn't resolved here, please contact me off-list with some 
details about your receiver, ntpd version, etc. and I'll look into it 
further.  I've been thinking about building a WWVB doodad, and a solution 
to this might save me some grief later on.

> As another data point: using a usb <-> rs232 converter, the dcf device 
> got back to life again. It still doesn't work in its entirety, but at 
> least, some data arrives in ntpd. Expected is something similar to:
> -#--#-#####-###--D--S124--2-p------p-----21-4-24-----8-- (incomplete)
> but it reads:
> ###############RADMLS1248124P124812P1248121241248112481248P
> thus, obviously it doesn't get any 0 values back (displayed as - above).

That looks like a hardware problem.  Odds are, something here (and it 
could be the USB<->RS232 converter or the DCF receiver or both) either 
isn't up to RS-232 specs or the receiver is making unfounded assumptions 
about the DTE port.  In particular, I'd want to know the mark/space 
voltages coming out of that USB thingy.
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@...r.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/