Hello all,
test12-pre7 seems to randomly just power off my machine.
CONFIG_APM=y and CONFIG_APM_REAL_MODE_POWER_OFF=y as well. Could this
be what is
making it power off the machine randomly? Has it been fixed in pre8?
I wasn't doing much on the machine at the time.. it just happens
sporadically.
Also, regarding the eepro100 driver, are there any plans to fix
support for the following chipset (given by lspci):
02:08.0 Ethernet controller: Intel Corporation 82820 820 (Camino 2)
Chipset Ethernet (rev 01)
I have one of these at work and I will get the following messages:
Dec 11 10:46:13 morpheus kernel: eepro100: cmd_wait for(0xffffff80)
+timedout with(0xffffff80)!
Dec 11 10:46:20 morpheus last message repeated 6 times
(using eepro100 from 2.2.18pre27.. I guess it's not 2.2.18 proper)
Thanks in advance,
Tom
ps. please reply to my e-mail address. Thanks!
__________________________________________________
Do You Yahoo!?
Yahoo! Shopping - Thousands of Stores. Millions of Products.
http://shopping.yahoo.com/
Hello,
On Mon, Dec 11, 2000 at 10:52:19AM -0800, Tom Murphy wrote:
> Also, regarding the eepro100 driver, are there any plans to fix
> support for the following chipset (given by lspci):
>
[snip]
> I have one of these at work and I will get the following messages:
>
> Dec 11 10:46:13 morpheus kernel: eepro100: cmd_wait for(0xffffff80)
> +timedout with(0xffffff80)!
> Dec 11 10:46:20 morpheus last message repeated 6 times
>
> (using eepro100 from 2.2.18pre27.. I guess it's not 2.2.18 proper)
Last time you asked the similar question, my answer to you bounced.
This debug output was submitted by Dragan Stancevic <[email protected]>.
The current timeout values are high enough to try to increase them more.
The question I'm interested in is how command 0x80 appeared in the command
register...
To answer your question in short, yet, we hope to fix the problem sooner or
later.
Regards
Andrey V.
Savochkin
On Tue, Dec 12, 2000, Andrey Savochkin <[email protected]> wrote:
; To answer your question in short, yet, we hope to fix the problem sooner or
; later.
I added the print out of the message to see in what state was the card
being left after it was wedged.
The card seems to be locking up with undefined opcodes, atleast according to
my specs.
The command doesn't necessarly come from the driver, I'we done some
experimenting and it seems that sending the card an undefined opcode
will lock up the card with a different value in the command register.
I am still waiting for latest specs from intel, I wonder if the new
specs will define those values.
--
I knew I was alone, I was scared, it was getting dark and
it was a hardware problem.
-Dragan