On Sun, Feb 13, 2005 at 09:22:46AM +0100, Vojtech Pavlik wrote:
> And I suppose it was running just fine without the patch as well?
Correct.
> The question was whether the patch helps, or whether it is not needed.
If you look again at the patch I posted, it only borrowed a few lines
of the
On Sat, Feb 12, 2005 at 07:16:59PM -0500, Bill Rugolsky Jr. wrote:
> Sorry for the long delay in replying; the HiNote needed some effort to get
> the thing up and running again. [Various bits of hardware are broken;
> the power switch, floppy, and CD-ROM are busted/flakey.] I've now got
>
On Sat, Feb 12, 2005 at 07:16:59PM -0500, Bill Rugolsky Jr. wrote:
Sorry for the long delay in replying; the HiNote needed some effort to get
the thing up and running again. [Various bits of hardware are broken;
the power switch, floppy, and CD-ROM are busted/flakey.] I've now got
Fedora
On Sun, Feb 13, 2005 at 09:22:46AM +0100, Vojtech Pavlik wrote:
And I suppose it was running just fine without the patch as well?
Correct.
The question was whether the patch helps, or whether it is not needed.
If you look again at the patch I posted, it only borrowed a few lines
of the
On Thu, Jan 27, 2005 at 05:37:14PM +0100, Vojtech Pavlik wrote:
> On Thu, Jan 27, 2005 at 11:34:31AM -0500, Bill Rugolsky Jr. wrote:
> > I have a Digital HiNote collecting dust which had this keyboard problem
> > with the RH 6.x 2.2.x boot disk kernels, IIRC. I can test if you like,
> > but I
On Thu, Jan 27, 2005 at 05:37:14PM +0100, Vojtech Pavlik wrote:
On Thu, Jan 27, 2005 at 11:34:31AM -0500, Bill Rugolsky Jr. wrote:
I have a Digital HiNote collecting dust which had this keyboard problem
with the RH 6.x 2.2.x boot disk kernels, IIRC. I can test if you like,
but I won't be
Linus Torvalds wrote:
> On Fri, 28 Jan 2005, Jaco Kroon wrote:
> > >>
> > >>ok, how would I try this? Where can I find an example to code it from?
> > >> Sorry, I should probably be grepping ...
> > > If the udelay() didn't work, then this one isn't worth worryign about
> > > either. Back to
Linus Torvalds wrote:
On Fri, 28 Jan 2005, Jaco Kroon wrote:
ok, how would I try this? Where can I find an example to code it from?
Sorry, I should probably be grepping ...
If the udelay() didn't work, then this one isn't worth worryign about
either. Back to the drawing board.
On Saturday 29 January 2005 14:59, Jaco Kroon wrote:
> > Compiling USB 1.1 support does the very same thing as specifying
> > usb-handoff on the command like - tells the BIOS to keep its hands off
> > the USB _and_ PS/2 controllers.
>
> I'm missing something, I have USB1.1 compiled in, then why
Vojtech Pavlik wrote:
On Fri, Jan 28, 2005 at 04:20:58PM +0200, Jaco Kroon wrote:
Vojtech Pavlik wrote:
On Thu, Jan 27, 2005 at 09:29:47PM +0100, Andries Brouwer wrote:
So what _might_ happen is that we write the command, and then
i8042_wait_write() thinks that there is space to write the data
Vojtech Pavlik wrote:
What I believe is happening is that we're talking to SMM emulation of
the i8042, which doesn't have a clue about these commands, while the
underlying real hardware implementation does. And because of that they
disagree on what should happen when the command is issued, and
On Fri, Jan 28, 2005 at 04:20:58PM +0200, Jaco Kroon wrote:
> Vojtech Pavlik wrote:
> >On Thu, Jan 27, 2005 at 09:29:47PM +0100, Andries Brouwer wrote:
> >
> >
> >>>So what _might_ happen is that we write the command, and then
> >>>i8042_wait_write() thinks that there is space to write the data
On Fri, Jan 28, 2005 at 04:20:58PM +0200, Jaco Kroon wrote:
Vojtech Pavlik wrote:
On Thu, Jan 27, 2005 at 09:29:47PM +0100, Andries Brouwer wrote:
So what _might_ happen is that we write the command, and then
i8042_wait_write() thinks that there is space to write the data
immediately,
Vojtech Pavlik wrote:
What I believe is happening is that we're talking to SMM emulation of
the i8042, which doesn't have a clue about these commands, while the
underlying real hardware implementation does. And because of that they
disagree on what should happen when the command is issued, and
Vojtech Pavlik wrote:
On Fri, Jan 28, 2005 at 04:20:58PM +0200, Jaco Kroon wrote:
Vojtech Pavlik wrote:
On Thu, Jan 27, 2005 at 09:29:47PM +0100, Andries Brouwer wrote:
So what _might_ happen is that we write the command, and then
i8042_wait_write() thinks that there is space to write the data
On Saturday 29 January 2005 14:59, Jaco Kroon wrote:
Compiling USB 1.1 support does the very same thing as specifying
usb-handoff on the command like - tells the BIOS to keep its hands off
the USB _and_ PS/2 controllers.
I'm missing something, I have USB1.1 compiled in, then why does the
On Thu, Jan 27, 2005 at 06:45:06PM +0100, Andries Brouwer wrote:
> Discussion:
>
> Dmitry:
> Here are patches with some delays. One never knows - maybe they
> help someone.
>
> Andries:
> Only insert delays in the kernel source when either we know about
> at least one person who reports that it
Vojtech Pavlik wrote:
On Thu, Jan 27, 2005 at 09:29:47PM +0100, Andries Brouwer wrote:
So what _might_ happen is that we write the command, and then
i8042_wait_write() thinks that there is space to write the data
immediately, and writes the data, but now the data got lost because the
buffer
On Thu, Jan 27, 2005 at 09:29:47PM +0100, Andries Brouwer wrote:
> > So what _might_ happen is that we write the command, and then
> > i8042_wait_write() thinks that there is space to write the data
> > immediately, and writes the data, but now the data got lost because the
> > buffer was
On Fri, Jan 28, 2005 at 12:12:19AM +0200, Jaco Kroon wrote:
> Yes. You understand correctly. Booting with acpi=off though has deadly
> implications when rebooting though (bios gives you the black screen of
> void). So I would like to keep booting with acpi=off down to an
> absolute
On Fri, Jan 28, 2005 at 12:12:19AM +0200, Jaco Kroon wrote:
Yes. You understand correctly. Booting with acpi=off though has deadly
implications when rebooting though (bios gives you the black screen of
void). So I would like to keep booting with acpi=off down to an
absolute minimum.
On Thu, Jan 27, 2005 at 09:29:47PM +0100, Andries Brouwer wrote:
So what _might_ happen is that we write the command, and then
i8042_wait_write() thinks that there is space to write the data
immediately, and writes the data, but now the data got lost because the
buffer was busy.
Hmm
Vojtech Pavlik wrote:
On Thu, Jan 27, 2005 at 09:29:47PM +0100, Andries Brouwer wrote:
So what _might_ happen is that we write the command, and then
i8042_wait_write() thinks that there is space to write the data
immediately, and writes the data, but now the data got lost because the
buffer
On Thu, Jan 27, 2005 at 06:45:06PM +0100, Andries Brouwer wrote:
Discussion:
Dmitry:
Here are patches with some delays. One never knows - maybe they
help someone.
Andries:
Only insert delays in the kernel source when either we know about
at least one person who reports that it helps, or
Linus Torvalds wrote:
>
> On Fri, 28 Jan 2005, Jaco Kroon wrote:
>
ok, how would I try this? Where can I find an example to code it
from?
Sorry, I should probably be grepping ...
>>>
>>>If the udelay() didn't work, then this one isn't worth worryign about
>>>either. Back to the drawing
On Thursday 27 January 2005 17:36, Linus Torvalds wrote:
> > I also tried increasing the total timeout value to about 5 seconds
> > (versus the default half second), still no success, so the device is
> > simply not sending back the requested values.
>
> If it was the other way around (that it
> > Only the ready flag was lost.
> No, note that if there was valid data we would see 0xa5 instead of
> 0x5a that was in the buffer - because in i8042_command we invert data
> coming from AUX port.
We misunderstand each other.
Let me repeat. The following happens:
We wait, then write d3, wait,
On Fri, 28 Jan 2005, Jaco Kroon wrote:
> >>
> >>ok, how would I try this? Where can I find an example to code it from?
> >> Sorry, I should probably be grepping ...
> > If the udelay() didn't work, then this one isn't worth worryign about
> > either. Back to the drawing board.
> Yea. But
Linus Torvalds wrote:
On Thu, 27 Jan 2005, Jaco Kroon wrote:
Hmm, just an idea, shouldn't the i8042_write_command be waiting until
the device has asserted the pin to indicate that the buffer is busy?
No. Because then you might end up waiting forever for the _opposite_
reason, namely that the
On Thu, 27 Jan 2005, Jaco Kroon wrote:
>
> Hmm, just an idea, shouldn't the i8042_write_command be waiting until
> the device has asserted the pin to indicate that the buffer is busy?
No. Because then you might end up waiting forever for the _opposite_
reason, namely that the hardware was so
Linus Torvalds wrote:
On Thu, 27 Jan 2005, Jaco Kroon wrote:
Which indicates (as far as my understanding goes) that the command times
out, as such the param value stays the same (ready for re-use in the
second command). The second commands succeeds but does not return one
of the expected
On Thu, 27 Jan 2005 21:29:47 +0100, Andries Brouwer <[EMAIL PROTECTED]> wrote:
> On Thu, Jan 27, 2005 at 10:09:24AM -0800, Linus Torvalds wrote:
>
> > So what _might_ happen is that we write the command, and then
> > i8042_wait_write() thinks that there is space to write the data
> > immediately,
On Thu, Jan 27, 2005 at 10:09:24AM -0800, Linus Torvalds wrote:
> So what _might_ happen is that we write the command, and then
> i8042_wait_write() thinks that there is space to write the data
> immediately, and writes the data, but now the data got lost because the
> buffer was busy.
Hmm -
On Thu, Jan 27, 2005 at 08:23:07AM +0200, Jaco Kroon wrote:
> i8042_check_aux: param_in=0x5a, command=AUX_LOOP, param_out=5a <= -1
> i8042_check_aux: param_in=??, command=AUX_TEST, param_out=a5 <= 0
The code is
param = 0x5a;
if (i8042_command(, I8042_CMD_AUX_LOOP) || param !=
On Thu, 27 Jan 2005, Jaco Kroon wrote:
>
> Which indicates (as far as my understanding goes) that the command times
> out, as such the param value stays the same (ready for re-use in the
> second command). The second commands succeeds but does not return one
> of the expected (0x00, 0xff,
Discussion:
Dmitry:
Here are patches with some delays. One never knows - maybe they
help someone.
Andries:
Only insert delays in the kernel source when either we know about
at least one person who reports that it helps, or about data sheets
that specify that the delay is required. Otherwise one
Vojtech Pavlik wrote:
On Thu, Jan 27, 2005 at 12:12:23PM +0100, Sebastian Piechocki wrote:
Dnia czwartek, 27 stycznia 2005 11:25, Vojtech Pavlik napisał:
On Thu, Jan 27, 2005 at 08:23:07AM +0200, Jaco Kroon wrote:
Sebastian Piechocki wrote:
As I said I'm sending you mails from kernel masters:)
On Thu, Jan 27, 2005 at 11:34:31AM -0500, Bill Rugolsky Jr. wrote:
> On Thu, Jan 27, 2005 at 03:14:36PM +, Alan Cox wrote:
> > Myths are not really involved here. The IBM PC hardware specifications
> > are fairly well defined and the various bits of "we glued a 2Mhz part
> > onto the bus"
On Thu, Jan 27, 2005 at 03:14:36PM +, Alan Cox wrote:
> Myths are not really involved here. The IBM PC hardware specifications
> are fairly well defined and the various bits of "we glued a 2Mhz part
> onto the bus" stuff is all well documented. Nowdays its more complex
> because most kbc's
On Thu, Jan 27, 2005 at 03:14:36PM +, Alan Cox wrote:
> On Maw, 2005-01-25 at 20:37, Lee Revell wrote:
> > Seems like a comment along the lines of "foo hardware doesn't work right
> > unless we delay a bit here" is the obvious solution. Then someone can
> > easily disprove it later.
>
>
On Maw, 2005-01-25 at 20:37, Lee Revell wrote:
> Seems like a comment along the lines of "foo hardware doesn't work right
> unless we delay a bit here" is the obvious solution. Then someone can
> easily disprove it later.
Myths are not really involved here. The IBM PC hardware specifications
are
On Thu, Jan 27, 2005 at 12:12:23PM +0100, Sebastian Piechocki wrote:
> Dnia czwartek, 27 stycznia 2005 11:25, Vojtech Pavlik napisał:
> > On Thu, Jan 27, 2005 at 08:23:07AM +0200, Jaco Kroon wrote:
> > > Sebastian Piechocki wrote:
> > > >As I said I'm sending you mails from kernel masters:)
> > >
Dnia czwartek, 27 stycznia 2005 11:25, Vojtech Pavlik napisał:
> On Thu, Jan 27, 2005 at 08:23:07AM +0200, Jaco Kroon wrote:
> > Sebastian Piechocki wrote:
> > >As I said I'm sending you mails from kernel masters:)
> >
> > Thanks.
> >
> > >If you haven't such a problem, please send them your dmesg
On Thu, Jan 27, 2005 at 08:23:07AM +0200, Jaco Kroon wrote:
> Sebastian Piechocki wrote:
> >As I said I'm sending you mails from kernel masters:)
> Thanks.
>
> >If you haven't such a problem, please send them your dmesg with
> >i8042.debug and acpi=off.
>
> I made an alternative plan. I
On Wed, Jan 26, 2005 at 11:36:41AM -0500, Dmitry Torokhov wrote:
> On Wed, 26 Jan 2005 16:43:07 +0100, Vojtech Pavlik <[EMAIL PROTECTED]> wrote:
> > On Tue, Jan 25, 2005 at 02:41:14AM -0500, Dmitry Torokhov wrote:
> > > @@ -213,7 +217,10 @@
> > > if (!retval)
> > > for (i = 0;
On Wed, Jan 26, 2005 at 11:36:41AM -0500, Dmitry Torokhov wrote:
On Wed, 26 Jan 2005 16:43:07 +0100, Vojtech Pavlik [EMAIL PROTECTED] wrote:
On Tue, Jan 25, 2005 at 02:41:14AM -0500, Dmitry Torokhov wrote:
@@ -213,7 +217,10 @@
if (!retval)
for (i = 0; i ((command
On Thu, Jan 27, 2005 at 08:23:07AM +0200, Jaco Kroon wrote:
Sebastian Piechocki wrote:
As I said I'm sending you mails from kernel masters:)
Thanks.
If you haven't such a problem, please send them your dmesg with
i8042.debug and acpi=off.
I made an alternative plan. I applied a custom
Dnia czwartek, 27 stycznia 2005 11:25, Vojtech Pavlik napisa:
On Thu, Jan 27, 2005 at 08:23:07AM +0200, Jaco Kroon wrote:
Sebastian Piechocki wrote:
As I said I'm sending you mails from kernel masters:)
Thanks.
If you haven't such a problem, please send them your dmesg with
On Thu, Jan 27, 2005 at 12:12:23PM +0100, Sebastian Piechocki wrote:
Dnia czwartek, 27 stycznia 2005 11:25, Vojtech Pavlik napisa:
On Thu, Jan 27, 2005 at 08:23:07AM +0200, Jaco Kroon wrote:
Sebastian Piechocki wrote:
As I said I'm sending you mails from kernel masters:)
Thanks.
On Maw, 2005-01-25 at 20:37, Lee Revell wrote:
Seems like a comment along the lines of foo hardware doesn't work right
unless we delay a bit here is the obvious solution. Then someone can
easily disprove it later.
Myths are not really involved here. The IBM PC hardware specifications
are
On Thu, Jan 27, 2005 at 03:14:36PM +, Alan Cox wrote:
On Maw, 2005-01-25 at 20:37, Lee Revell wrote:
Seems like a comment along the lines of foo hardware doesn't work right
unless we delay a bit here is the obvious solution. Then someone can
easily disprove it later.
Myths are not
On Thu, Jan 27, 2005 at 03:14:36PM +, Alan Cox wrote:
Myths are not really involved here. The IBM PC hardware specifications
are fairly well defined and the various bits of we glued a 2Mhz part
onto the bus stuff is all well documented. Nowdays its more complex
because most kbc's aren't
On Thu, Jan 27, 2005 at 11:34:31AM -0500, Bill Rugolsky Jr. wrote:
On Thu, Jan 27, 2005 at 03:14:36PM +, Alan Cox wrote:
Myths are not really involved here. The IBM PC hardware specifications
are fairly well defined and the various bits of we glued a 2Mhz part
onto the bus stuff is all
Vojtech Pavlik wrote:
On Thu, Jan 27, 2005 at 12:12:23PM +0100, Sebastian Piechocki wrote:
Dnia czwartek, 27 stycznia 2005 11:25, Vojtech Pavlik napisa:
On Thu, Jan 27, 2005 at 08:23:07AM +0200, Jaco Kroon wrote:
Sebastian Piechocki wrote:
As I said I'm sending you mails from kernel masters:)
Discussion:
Dmitry:
Here are patches with some delays. One never knows - maybe they
help someone.
Andries:
Only insert delays in the kernel source when either we know about
at least one person who reports that it helps, or about data sheets
that specify that the delay is required. Otherwise one
On Thu, 27 Jan 2005, Jaco Kroon wrote:
Which indicates (as far as my understanding goes) that the command times
out, as such the param value stays the same (ready for re-use in the
second command). The second commands succeeds but does not return one
of the expected (0x00, 0xff, 0xfa)
On Thu, Jan 27, 2005 at 08:23:07AM +0200, Jaco Kroon wrote:
i8042_check_aux: param_in=0x5a, command=AUX_LOOP, param_out=5a = -1
i8042_check_aux: param_in=??, command=AUX_TEST, param_out=a5 = 0
The code is
param = 0x5a;
if (i8042_command(param, I8042_CMD_AUX_LOOP) || param !=
On Thu, Jan 27, 2005 at 10:09:24AM -0800, Linus Torvalds wrote:
So what _might_ happen is that we write the command, and then
i8042_wait_write() thinks that there is space to write the data
immediately, and writes the data, but now the data got lost because the
buffer was busy.
Hmm - I
On Thu, 27 Jan 2005 21:29:47 +0100, Andries Brouwer [EMAIL PROTECTED] wrote:
On Thu, Jan 27, 2005 at 10:09:24AM -0800, Linus Torvalds wrote:
So what _might_ happen is that we write the command, and then
i8042_wait_write() thinks that there is space to write the data
immediately, and
Linus Torvalds wrote:
On Thu, 27 Jan 2005, Jaco Kroon wrote:
Which indicates (as far as my understanding goes) that the command times
out, as such the param value stays the same (ready for re-use in the
second command). The second commands succeeds but does not return one
of the expected
On Thu, 27 Jan 2005, Jaco Kroon wrote:
Hmm, just an idea, shouldn't the i8042_write_command be waiting until
the device has asserted the pin to indicate that the buffer is busy?
No. Because then you might end up waiting forever for the _opposite_
reason, namely that the hardware was so
Linus Torvalds wrote:
On Thu, 27 Jan 2005, Jaco Kroon wrote:
Hmm, just an idea, shouldn't the i8042_write_command be waiting until
the device has asserted the pin to indicate that the buffer is busy?
No. Because then you might end up waiting forever for the _opposite_
reason, namely that the
On Fri, 28 Jan 2005, Jaco Kroon wrote:
ok, how would I try this? Where can I find an example to code it from?
Sorry, I should probably be grepping ...
If the udelay() didn't work, then this one isn't worth worryign about
either. Back to the drawing board.
Yea. But for interrests
Only the ready flag was lost.
No, note that if there was valid data we would see 0xa5 instead of
0x5a that was in the buffer - because in i8042_command we invert data
coming from AUX port.
We misunderstand each other.
Let me repeat. The following happens:
We wait, then write d3, wait, then
On Thursday 27 January 2005 17:36, Linus Torvalds wrote:
I also tried increasing the total timeout value to about 5 seconds
(versus the default half second), still no success, so the device is
simply not sending back the requested values.
If it was the other way around (that it works
Linus Torvalds wrote:
On Fri, 28 Jan 2005, Jaco Kroon wrote:
ok, how would I try this? Where can I find an example to code it
from?
Sorry, I should probably be grepping ...
If the udelay() didn't work, then this one isn't worth worryign about
either. Back to the drawing board.
Yea. But
Sebastian Piechocki wrote:
As I said I'm sending you mails from kernel masters:)
Thanks.
If you haven't such a problem, please send them your dmesg with i8042.debug
and acpi=off.
I made an alternative plan. I applied a custom patch that gives me far less
output and prevents scrolling and gets
On Wed, 26 Jan 2005 12:05:47 -0500 (EST), linux-os
<[EMAIL PROTECTED]> wrote:
> On Wed, 26 Jan 2005, Dmitry Torokhov wrote:
>
> > On Wed, 26 Jan 2005 16:43:07 +0100, Vojtech Pavlik <[EMAIL PROTECTED]>
> > wrote:
> >> On Tue, Jan 25, 2005 at 02:41:14AM -0500, Dmitry Torokhov wrote:
> >>> @@
On Wed, 26 Jan 2005, Dmitry Torokhov wrote:
On Wed, 26 Jan 2005 16:43:07 +0100, Vojtech Pavlik <[EMAIL PROTECTED]> wrote:
On Tue, Jan 25, 2005 at 02:41:14AM -0500, Dmitry Torokhov wrote:
@@ -213,7 +217,10 @@
if (!retval)
for (i = 0; i < ((command >> 8) & 0xf); i++) {
On Wed, 26 Jan 2005 16:43:07 +0100, Vojtech Pavlik <[EMAIL PROTECTED]> wrote:
> On Tue, Jan 25, 2005 at 02:41:14AM -0500, Dmitry Torokhov wrote:
> > @@ -213,7 +217,10 @@
> > if (!retval)
> > for (i = 0; i < ((command >> 8) & 0xf); i++) {
> > if ((retval =
On Tue, Jan 25, 2005 at 02:41:14AM -0500, Dmitry Torokhov wrote:
> Recently there was a patch from Alan regarding access timing violations
> in i8042. It made me curious as we only wait between accesses to status
> register but not data register. I peeked into FreeBSD code and they use
> delays
On Tue, Jan 25, 2005 at 02:41:14AM -0500, Dmitry Torokhov wrote:
Recently there was a patch from Alan regarding access timing violations
in i8042. It made me curious as we only wait between accesses to status
register but not data register. I peeked into FreeBSD code and they use
delays to
On Wed, 26 Jan 2005 16:43:07 +0100, Vojtech Pavlik [EMAIL PROTECTED] wrote:
On Tue, Jan 25, 2005 at 02:41:14AM -0500, Dmitry Torokhov wrote:
@@ -213,7 +217,10 @@
if (!retval)
for (i = 0; i ((command 8) 0xf); i++) {
if ((retval =
On Wed, 26 Jan 2005, Dmitry Torokhov wrote:
On Wed, 26 Jan 2005 16:43:07 +0100, Vojtech Pavlik [EMAIL PROTECTED] wrote:
On Tue, Jan 25, 2005 at 02:41:14AM -0500, Dmitry Torokhov wrote:
@@ -213,7 +217,10 @@
if (!retval)
for (i = 0; i ((command 8) 0xf); i++) {
On Wed, 26 Jan 2005 12:05:47 -0500 (EST), linux-os
[EMAIL PROTECTED] wrote:
On Wed, 26 Jan 2005, Dmitry Torokhov wrote:
On Wed, 26 Jan 2005 16:43:07 +0100, Vojtech Pavlik [EMAIL PROTECTED]
wrote:
On Tue, Jan 25, 2005 at 02:41:14AM -0500, Dmitry Torokhov wrote:
@@ -213,7 +217,10 @@
Sebastian Piechocki wrote:
As I said I'm sending you mails from kernel masters:)
Thanks.
If you haven't such a problem, please send them your dmesg with i8042.debug
and acpi=off.
I made an alternative plan. I applied a custom patch that gives me far less
output and prevents scrolling and gets
On Tue, 2005-01-25 at 20:46 +0100, Andries Brouwer wrote:
> On Tue, Jan 25, 2005 at 02:17:33PM -0500, Dmitry Torokhov wrote:
>
> > Still, I wonder if implementing these delays will give IO controller
> > better chances to react to our queries and will get rid of some
> > failures.
>
> My
On Tue, 25 Jan 2005 20:25:20 +0100, Vojtech Pavlik <[EMAIL PROTECTED]> wrote:
> On Tue, Jan 25, 2005 at 02:17:33PM -0500, Dmitry Torokhov wrote:
> > On Tue, 25 Jan 2005 11:51:39 +0100, Andries Brouwer <[EMAIL PROTECTED]>
> > wrote:
> > > On Tue, Jan 25, 2005 at 02:41:14AM -0500, Dmitry Torokhov
On Tue, Jan 25, 2005 at 02:17:33PM -0500, Dmitry Torokhov wrote:
> Still, I wonder if implementing these delays will give IO controller
> better chances to react to our queries and will get rid of some
> failures.
My objection is this: by doing this you create myths that may
be difficult to
On Tue, Jan 25, 2005 at 02:17:33PM -0500, Dmitry Torokhov wrote:
> On Tue, 25 Jan 2005 11:51:39 +0100, Andries Brouwer <[EMAIL PROTECTED]> wrote:
> > On Tue, Jan 25, 2005 at 02:41:14AM -0500, Dmitry Torokhov wrote:
> >
> > > Recently there was a patch from Alan regarding access timing violations
On Tue, 25 Jan 2005 11:51:39 +0100, Andries Brouwer <[EMAIL PROTECTED]> wrote:
> On Tue, Jan 25, 2005 at 02:41:14AM -0500, Dmitry Torokhov wrote:
>
> > Recently there was a patch from Alan regarding access timing violations
> > in i8042. It made me curious as we only wait between accesses to
On Maw, 2005-01-25 at 07:41, Dmitry Torokhov wrote:
> Hi,
> Anyway, regardless of whether access to data register should be done with
> delay as well there seem to be another timing access violation - in
> i8042_command we do i8042_wait_read which reads STR and then immediately
> do
On Maw, 2005-01-25 at 07:41, Dmitry Torokhov wrote:
> in i8042. It made me curious as we only wait between accesses to status
> register but not data register. I peeked into FreeBSD code and they use
> delays to access both registers and I wonder if that's the piece that
> makes i8042 mysteriously
On Tue, Jan 25, 2005 at 02:41:14AM -0500, Dmitry Torokhov wrote:
> Recently there was a patch from Alan regarding access timing violations
> in i8042. It made me curious as we only wait between accesses to status
> register but not data register. I peeked into FreeBSD code and they use
> delays
On Tue, Jan 25, 2005 at 02:41:14AM -0500, Dmitry Torokhov wrote:
Recently there was a patch from Alan regarding access timing violations
in i8042. It made me curious as we only wait between accesses to status
register but not data register. I peeked into FreeBSD code and they use
delays to
On Maw, 2005-01-25 at 07:41, Dmitry Torokhov wrote:
in i8042. It made me curious as we only wait between accesses to status
register but not data register. I peeked into FreeBSD code and they use
delays to access both registers and I wonder if that's the piece that
makes i8042 mysteriously
On Maw, 2005-01-25 at 07:41, Dmitry Torokhov wrote:
Hi,
Anyway, regardless of whether access to data register should be done with
delay as well there seem to be another timing access violation - in
i8042_command we do i8042_wait_read which reads STR and then immediately
do i8042_read_status
On Tue, 25 Jan 2005 11:51:39 +0100, Andries Brouwer [EMAIL PROTECTED] wrote:
On Tue, Jan 25, 2005 at 02:41:14AM -0500, Dmitry Torokhov wrote:
Recently there was a patch from Alan regarding access timing violations
in i8042. It made me curious as we only wait between accesses to status
On Tue, Jan 25, 2005 at 02:17:33PM -0500, Dmitry Torokhov wrote:
On Tue, 25 Jan 2005 11:51:39 +0100, Andries Brouwer [EMAIL PROTECTED] wrote:
On Tue, Jan 25, 2005 at 02:41:14AM -0500, Dmitry Torokhov wrote:
Recently there was a patch from Alan regarding access timing violations
in
On Tue, Jan 25, 2005 at 02:17:33PM -0500, Dmitry Torokhov wrote:
Still, I wonder if implementing these delays will give IO controller
better chances to react to our queries and will get rid of some
failures.
My objection is this: by doing this you create myths that may
be difficult to dispel
On Tue, 25 Jan 2005 20:25:20 +0100, Vojtech Pavlik [EMAIL PROTECTED] wrote:
On Tue, Jan 25, 2005 at 02:17:33PM -0500, Dmitry Torokhov wrote:
On Tue, 25 Jan 2005 11:51:39 +0100, Andries Brouwer [EMAIL PROTECTED]
wrote:
On Tue, Jan 25, 2005 at 02:41:14AM -0500, Dmitry Torokhov wrote:
On Tue, 2005-01-25 at 20:46 +0100, Andries Brouwer wrote:
On Tue, Jan 25, 2005 at 02:17:33PM -0500, Dmitry Torokhov wrote:
Still, I wonder if implementing these delays will give IO controller
better chances to react to our queries and will get rid of some
failures.
My objection is
92 matches
Mail list logo
