Hello all,
My company uses a proprietary hardware monitoring solution that utilizes
communication over the serial port. A RS232-RS485 converter is plugged into
the serial port of the master of a cluster, and cat5 cables are daisy chained
between the cards to handle out of band hardware monitoring. The cards
themselves speak RS485. We have been using the same software to read the
data from the serial port since the 2.4 kernel days. As of 2.6.23, the
software no longer works.
I narrowed down the problem doing a binary search on git snapshots between .22
and .23, and found the breakage between git6 and git7. Further isolating it
found the patch mentioned in the subject to be the cause. I reversed the
patch in the .23 source and it now works properly.
Should the code be reverted back as I did, or is there something I should
change in our userspace code that reads from the serial port to correct it
instead?
Thanks,
Rick
--
Richard Warner
Lead Systems Integrator
Microway, Inc
(508)732-5517
Rick Warner wrote:
> I narrowed down the problem doing a binary search on git snapshots between .22
> and .23, and found the breakage between git6 and git7. Further isolating it
> found the patch mentioned in the subject to be the cause. I reversed the
> patch in the .23 source and it now works properly.
>
> Should the code be reverted back as I did, or is there something I should
> change in our userspace code that reads from the serial port to correct it
> instead?
Instead of reverting the patch can you try modifying
this part of the patch:
+ if (wait_event_interruptible_timeout(tty->write_wait,
+ !tty->driver->chars_in_buffer(tty), timeout))
+ return;
by changing it to:
+ if (wait_event_interruptible_timeout(tty->write_wait,
+ !tty->driver->chars_in_buffer(tty), timeout) < 0)
+ return;
It looks like the patch changed the behavior of
tty_wait_until_sent by not calling the driver
specific wait_until_sent if a timeout occurs.
--
Paul Fulghum
Microgate Systems, Ltd.
Paul Fulghum wrote:
> Instead of reverting the patch can you try modifying
> this part of the patch:
>
> + if (wait_event_interruptible_timeout(tty->write_wait,
> + !tty->driver->chars_in_buffer(tty), timeout))
> + return;
>
> by changing it to:
>
> + if (wait_event_interruptible_timeout(tty->write_wait,
> + !tty->driver->chars_in_buffer(tty), timeout) < 0)
> + return;
>
> It looks like the patch changed the behavior of
> tty_wait_until_sent by not calling the driver
> specific wait_until_sent if a timeout occurs.
I mispoke, the patch changed the behavior by not
calling the driver specific wait_until_sent if
the condition is true.
Original behavior:
call driver->wait_until_sent() on
timeout or true condition
(skip for signal)
Patch behavior:
call driver->wait_until_sent() only
on timeout (rc == 0)
(skip for signal or true)
By modifying the patch as described above,
the original behavior is restored.
--
Paul Fulghum
Microgate Systems, Ltd.
This modification solved my problem. Will this change go into mainline, or
will we need to maintain our own branch of the kernel to keep this working?
Thanks,
Rick
On Tuesday 05 February 2008, Paul Fulghum wrote:
> Paul Fulghum wrote:
> > Instead of reverting the patch can you try modifying
> > this part of the patch:
> >
> > + if (wait_event_interruptible_timeout(tty->write_wait,
> > + !tty->driver->chars_in_buffer(tty), timeout))
> > + return;
> >
> > by changing it to:
> >
> > + if (wait_event_interruptible_timeout(tty->write_wait,
> > + !tty->driver->chars_in_buffer(tty), timeout) < 0)
> > + return;
> >
> > It looks like the patch changed the behavior of
> > tty_wait_until_sent by not calling the driver
> > specific wait_until_sent if a timeout occurs.
>
> I mispoke, the patch changed the behavior by not
> calling the driver specific wait_until_sent if
> the condition is true.
>
> Original behavior:
> call driver->wait_until_sent() on
> timeout or true condition
> (skip for signal)
>
> Patch behavior:
> call driver->wait_until_sent() only
> on timeout (rc == 0)
> (skip for signal or true)
>
> By modifying the patch as described above,
> the original behavior is restored.
--
Richard Warner
Lead Systems Integrator
Microway, Inc
(508)732-5517
Rick Warner wrote:
> This modification solved my problem. Will this change go into mainline, or
> will we need to maintain our own branch of the kernel to keep this working?
It should be accepted into mainline as it restores
the original behavior. I'll put together a patch
submission tomorrow unless Jiri beats me to it.
Thanks,
Paul
--
Paul Fulghum
Microgate Systems, Ltd.
On 02/05/2008 10:37 PM, Paul Fulghum wrote:
> Rick Warner wrote:
>> This modification solved my problem. Will this change go into
>> mainline, or will we need to maintain our own branch of the kernel to
>> keep this working?
>
> It should be accepted into mainline as it restores
> the original behavior. I'll put together a patch
> submission tomorrow unless Jiri beats me to it.
It should be fixed already as of
git-describe db99247a
v2.6.24-rc6-95-gdb99247
So since 2.6.24-rc7.
Maybe we should consider the fix for 2.6.23 too.
Jiri Slaby wrote:
> It should be fixed already as of
> git-describe db99247a
> v2.6.24-rc6-95-gdb99247
>
> So since 2.6.24-rc7.
>
> Maybe we should consider the fix for 2.6.23 too.
Whoops, I missed that.
Problem solved :-)
Thanks,
Paul
On 02/05/2008 11:27 PM, Paul Fulghum wrote:
> Jiri Slaby wrote:
>> It should be fixed already as of
>> git-describe db99247a
>> v2.6.24-rc6-95-gdb99247
>>
>> So since 2.6.24-rc7.
>>
>> Maybe we should consider the fix for 2.6.23 too.
>
> Whoops, I missed that.
> Problem solved :-)
:) Thank you both for heads up.