Pedram M wrote:
How about this one? Am I doing it right now?
If not, please try to explain more to me what I am
doing wrong.
You need a changelog entry (or explanation of what you're doing). You
need a signed-off-by line and your patch needs to apply to the root of
the kernel tree with -p1,
Pedram M wrote:
How about this one? Am I doing it right now?
If not, please try to explain more to me what I am
doing wrong.
You need a changelog entry (or explanation of what you're doing). You
need a signed-off-by line and your patch needs to apply to the root of
the kernel tree with -p1,
Mike Galbraith wrote:
> At 10:33 PM 8/5/2005 +0200, you wrote:
>
>> Hello all,
>>
>> I'm absolutely stumped with this one. We are still having problems
>> deciding whether this is a software problem or a hardware problem.
>
> Given the number of kernels it freezes under, I'd say hardware.
That
Mike Galbraith wrote:
At 10:33 PM 8/5/2005 +0200, you wrote:
Hello all,
I'm absolutely stumped with this one. We are still having problems
deciding whether this is a software problem or a hardware problem.
Given the number of kernels it freezes under, I'd say hardware.
That is what we
Hello all,
I'm absolutely stumped with this one. We are still having problems
deciding whether this is a software problem or a hardware problem. This
particular box (specs lower down) just freezes up sporadically when in
Linux.
Normally it just stops responding entirely. As in one moment it's
Hello all,
I'm absolutely stumped with this one. We are still having problems
deciding whether this is a software problem or a hardware problem. This
particular box (specs lower down) just freezes up sporadically when in
Linux.
Normally it just stops responding entirely. As in one moment it's
Dmitry Torokhov wrote:
> On Apr 5, 2005 4:01 PM, Jaco Kroon <[EMAIL PROTECTED]> wrote:
>
>>btw Dmitri, that patch does not seem to work. But the kernel panic that
>>kicks in when X starts up does imply that _something_ changed. No sync
>>however, so no stack trac
Dmitry Torokhov wrote:
On Apr 5, 2005 4:01 PM, Jaco Kroon [EMAIL PROTECTED] wrote:
btw Dmitri, that patch does not seem to work. But the kernel panic that
kicks in when X starts up does imply that _something_ changed. No sync
however, so no stack trace in the logs either. In fact, looking
Dmitry Torokhov wrote:
> On Apr 5, 2005 4:01 PM, Jaco Kroon <[EMAIL PROTECTED]> wrote:
>
>>btw Dmitri, that patch does not seem to work. But the kernel panic that
>>kicks in when X starts up does imply that _something_ changed. No sync
>>however, so no stack trac
Dmitry Torokhov wrote:
> On Apr 5, 2005 1:20 PM, Stefan Seyfried <[EMAIL PROTECTED]> wrote:
>>Jaco Kroon wrote:
>>>Dmitry Torokhov wrote:
>>>>You should be able to control that in xorg.conf.
>>>
>>>My thoughts exactly. The same goe
Dmitry Torokhov wrote:
On Apr 5, 2005 1:20 PM, Stefan Seyfried [EMAIL PROTECTED] wrote:
Jaco Kroon wrote:
Dmitry Torokhov wrote:
You should be able to control that in xorg.conf.
My thoughts exactly. The same goes for gpm.
No. AFAIK multifinger taps are handled by the touchpad firmware
Dmitry Torokhov wrote:
On Apr 5, 2005 4:01 PM, Jaco Kroon [EMAIL PROTECTED] wrote:
btw Dmitri, that patch does not seem to work. But the kernel panic that
kicks in when X starts up does imply that _something_ changed. No sync
however, so no stack trace in the logs either. In fact, looking
Dmitry Torokhov wrote:
> A-haa.. Well, in that case we'll cheat ;) and just disable MUX mode
> for your Toshiba via a DMI quirk, like we do for certain Fujitsus. If
> there is no external port there is no reason to have the controller in
> MUX mode.
>
> Could you please send me output of
Dmitry Torokhov wrote:
> Ok, try booting with "usb-handoff i8042.nomux". If that cures
yes, it cures both problems (death on reboot and ALPS), in fact. But I
must have *both* params. nomux without usb-handoff causes all input
devices to fail. Thanks goodness for ssh. Anyway - I'm now running
Dmitry Torokhov wrote:
> On Apr 4, 2005 3:35 PM, Jaco Kroon <[EMAIL PROTECTED]> wrote:
>
>>As for loading the modules i8042, atkbd and psmouse (in that order):
>>black void of death.
>>
> Hmm.. remind me, if you boot with usb-handoff does it switch the i8042
>
Dmitry Torokhov wrote:
> On Apr 4, 2005 12:07 PM, Jaco Kroon <[EMAIL PROTECTED]> wrote:
>>Dmitry Torokhov wrote:
>>>On Apr 4, 2005 11:10 AM, Jaco Kroon <[EMAIL PROTECTED]> wrote:
>>>>A while back there was quite a discussion on this issue and then
>&g
Dmitry Torokhov wrote:
> Hi,
>
> On Apr 4, 2005 11:10 AM, Jaco Kroon <[EMAIL PROTECTED]> wrote:
>
>>Hello all
>>
>>A while back there was quite a discussion on this issue and then
>>specifically "i8042 timing issues". I refer you to
Hello all
A while back there was quite a discussion on this issue and then
specifically "i8042 timing issues". I refer you to
http://lkml.org/lkml/2005/1/27/11 for more detail.
It turns out that it was the case that the i8042 controller responds too
late on commands, for example, we issue a
Hello all
A while back there was quite a discussion on this issue and then
specifically i8042 timing issues. I refer you to
http://lkml.org/lkml/2005/1/27/11 for more detail.
It turns out that it was the case that the i8042 controller responds too
late on commands, for example, we issue a
Dmitry Torokhov wrote:
Hi,
On Apr 4, 2005 11:10 AM, Jaco Kroon [EMAIL PROTECTED] wrote:
Hello all
A while back there was quite a discussion on this issue and then
specifically i8042 timing issues. I refer you to
http://lkml.org/lkml/2005/1/27/11 for more detail.
...
I was under
Dmitry Torokhov wrote:
On Apr 4, 2005 12:07 PM, Jaco Kroon [EMAIL PROTECTED] wrote:
Dmitry Torokhov wrote:
On Apr 4, 2005 11:10 AM, Jaco Kroon [EMAIL PROTECTED] wrote:
A while back there was quite a discussion on this issue and then
specifically i8042 timing issues. I refer you to
http
Dmitry Torokhov wrote:
On Apr 4, 2005 3:35 PM, Jaco Kroon [EMAIL PROTECTED] wrote:
As for loading the modules i8042, atkbd and psmouse (in that order):
black void of death.
Hmm.. remind me, if you boot with usb-handoff does it switch the i8042
into active multiplexing mode (you get 4 AUX
Dmitry Torokhov wrote:
Ok, try booting with usb-handoff i8042.nomux. If that cures
yes, it cures both problems (death on reboot and ALPS), in fact. But I
must have *both* params. nomux without usb-handoff causes all input
devices to fail. Thanks goodness for ssh. Anyway - I'm now running a
Dmitry Torokhov wrote:
A-haa.. Well, in that case we'll cheat ;) and just disable MUX mode
for your Toshiba via a DMI quirk, like we do for certain Fujitsus. If
there is no external port there is no reason to have the controller in
MUX mode.
Could you please send me output of 'dmidecode'
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:
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 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
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
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
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
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
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
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
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
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
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
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
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
38 matches
Mail list logo
