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.
--
To
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
--
To unsubscribe from this list: send the line "unsubscribe linux-ker
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
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 unle
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
> >
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
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 prope
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 monitor
8 matches
Mail list logo