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 pat
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 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'
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 t
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 do
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
i
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 sinc
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 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 h
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 was
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.
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.
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 b
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 w
> > 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 for
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 har
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 (0x00,
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 - I
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(¶m, I8042_CMD_AUX_LOOP) || param != 0
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, 0x
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 c
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:)
Than
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
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
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.
>
> Myth
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 applied
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
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 wha
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
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 = i
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 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 objectio
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 wr
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 dispe
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 statu
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_stat
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 to
Hi,
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 access both registers and I wonder if that's the piece that
makes i8
47 matches
Mail list logo
