Skip to contentSkip to conversation

2.4.0-test12-pre7 shutdowns and eepro100 woes

DISCUSSION Tom Murphy 3 participants 3 messages Dec 11, 2000 – Dec 20, 2000

lore
Share & tools
lore

Tom Murphy

author
#0 lore raw

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/
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [email protected]
Please read the FAQ at http://www.tux.org/lkml/

#1 lore raw

Hello,

Quoted 3 lines · Tom Murphy

Also, regarding the eepro100 driver, are there any plans to fix
support for the following chipset (given by lspci):

[snip]

Quoted 7 lines

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
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [email protected]
Please read the FAQ at http://www.tux.org/lkml/

#2 lore raw
In reply to Tom Murphy

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.

Signature · 8 lines
I knew I was alone, I was scared, it was getting dark and
it was a hardware problem.

                                                -Dragan
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [email protected]
Please read the FAQ at http://www.tux.org/lkml/