I have a minipci card in my laptop. It's purpose in life is to be
a modem and ethernet card, with the ethernet side being an eepro100.
lspci -vv gives me the following:
00:0d.0 Ethernet controller: Intel Corporation 82557 [Ethernet Pro 100] (rev 09)
Subsystem: Intel Corporation: Unknown device 2411
Control: I/O+ Mem+ BusMaster+ SpecCycle- MemWINV+ VGASnoop- ParErr- Stepping- SERR- FastB2B-
Status: Cap+ 66Mhz- UDF- FastB2B+ ParErr- DEVSEL=medium >TAbort- <TAbort- <MAbort+ >SERR- <PERR-
Latency: 66 (2000ns min, 14000ns max), cache line size 08
Interrupt: pin A routed to IRQ 10
Region 0: Memory at e8002000 (32-bit, non-prefetchable)
Region 1: I/O ports at 1400
Region 2: Memory at e8020000 (32-bit, non-prefetchable)
Capabilities: [dc] Power Management version 2
Flags: PMEClk- DSI+ D1+ D2+ AuxCurrent=0mA PME(D0+,D1+,D2+,D3hot+,D3cold+)
Status: D0 PME-Enable+ DSel=0 DScale=2 PME-
00:0d.1 Serial controller: Xircom: Unknown device 00d3 (prog-if 02 [16550])
Subsystem: Intel Corporation: Unknown device 2411
Control: I/O+ Mem+ BusMaster- SpecCycle- MemWINV- VGASnoop- ParErr- Stepping- SERR- FastB2B-
Status: Cap+ 66Mhz- UDF- FastB2B- ParErr- DEVSEL=medium >TAbort- <TAbort- <MAbort- >SERR- <PERR-
Interrupt: pin A routed to IRQ 10
Region 0: I/O ports at 1470
Region 1: Memory at e8003000 (32-bit, non-prefetchable)
Capabilities: [dc] Power Management version 2
Flags: PMEClk- DSI+ D1+ D2+ AuxCurrent=0mA PME(D0+,D1+,D2+,D3hot+,D3cold+)
Status: D0 PME-Enable- DSel=0 DScale=2 PME-
The modem side is not really in use as it doesn't look like a normal
modem *sob* 8(. Anyhow, rarely at bootup but more often when I unsuspend
(from disk now-a-days) I get the following:
Feb 11 22:30:18 theirongiant kernel: eepro100.c:v1.09j-t 9/29/99 Donald Becker http://cesdis.gsfc.nasa.gov/linux/drivers/eepro100.html
Feb 11 22:30:18 theirongiant kernel: eepro100.c: $Revision: 1.20.2.10 $ 2000/05/31 Modified by Andrey V. Savochkin <[email protected]> and others
Feb 11 22:30:18 theirongiant kernel: eepro100.c: VA Linux custom, Dragan Stancevic <[email protected]> 2000/11/15
Feb 11 22:30:18 theirongiant kernel: eth0: Intel PCI EtherExpress Pro100 82557, 00:10:A4:0E:7F:EC, IRQ 10.
Feb 11 22:30:18 theirongiant kernel: Board assembly 000695-001, Physical connectors present: RJ45
Feb 11 22:30:18 theirongiant kernel: Primary interface chip i82555 PHY #1.
Feb 11 22:30:18 theirongiant kernel: General self-test: passed.
Feb 11 22:30:18 theirongiant kernel: Serial sub-system self-test: passed.
Feb 11 22:30:18 theirongiant kernel: Internal registers self-test: passed.
Feb 11 22:30:18 theirongiant kernel: ROM checksum self-test: passed (0xdbd8681d).
Feb 11 22:30:18 theirongiant kernel: Receiver lock-up workaround activated.
Feb 11 22:30:18 theirongiant kernel: eepro100: cmd_wait for(0x70) timedout with(0x70)!
Feb 11 22:30:18 theirongiant kernel: eepro100: cmd_wait for(0x10) timedout with(0x10)!
Feb 11 22:30:18 theirongiant kernel: eepro100: cmd_wait for(0xffffff90) timedout with(0xffffff90)!
Feb 11 22:30:31 theirongiant last message repeated 12 times
Feb 11 22:30:31 theirongiant kernel: eth0: 0 multicast blocks dropped.
Feb 11 22:30:34 theirongiant kernel: eepro100: cmd_wait for(0x70) timedout with(0x70)!
Feb 11 22:30:34 theirongiant kernel: eepro100: cmd_wait for(0x10) timedout with(0x10)!
Feb 11 22:30:34 theirongiant kernel: eepro100: cmd_wait for(0xffffff90) timedout with(0xffffff90)!
Feb 11 22:30:49 theirongiant last message repeated 12 times
Feb 11 22:30:49 theirongiant kernel: eth0: 0 multicast blocks dropped.
Feb 11 22:30:52 theirongiant kernel: eepro100: cmd_wait for(0x70) timedout with(0x70)!
Feb 11 22:30:52 theirongiant kernel: eepro100: cmd_wait for(0x10) timedout with(0x10)!
Feb 11 22:30:52 theirongiant kernel: eepro100: cmd_wait for(0xffffff90) timedout with(0xffffff90)!
Feb 11 22:30:56 theirongiant last message repeated 7 times
Feb 11 22:30:56 theirongiant kernel: eth0: 0 multicast blocks dropped.
The only way to get it out of this, without a reboot is to drop eth0
and then bring it back up, but, like this time, that doesn't always
work and it takes a few goes at it.
The driver itself is compiled as a module and the interface is dropped and
the module unloaded when the laptop is being suspended and then the module
is loaded back in and the interface brought back up. This is because the
driver doesn't realise that the card has been turned off and it needs
reinitialisation (which is what the reloading of the module does I presume).
This also happened with 2.2.19pre7 and 2.2.18preX. I don't know if it
happens with 2.4.x as I haven't used it long enough. The ps/2 driver
seems broken (at least in 2.4.0) which is another issue I have to take up
in a seperate email.
Anyhow, can anyone help? If you need more info just holler.
--
CaT ([email protected]) *** Jenna has joined the channel.
<cat> speaking of mental giants..
<Jenna> me, a giant, bullshit
<Jenna> And i'm not mental
- An IRC session, 20/12/2000
On Sun, Feb 11, 2001 at 10:40:33PM +1100, CaT wrote:
[snip]
> Feb 11 22:30:18 theirongiant kernel: eepro100: cmd_wait for(0x70) timedout with(0x70)!
Please try the attached patch.
Actually, it's designed to solve another problem, but may be your one has the
same origin as that other.
Best regards
Andrey
On Tue, Feb 13, 2001 at 09:26:38AM +0800, Andrey Savochkin wrote:
> On Sun, Feb 11, 2001 at 10:40:33PM +1100, CaT wrote:
> [snip]
> > Feb 11 22:30:18 theirongiant kernel: eepro100: cmd_wait for(0x70) timedout with(0x70)!
>
> Please try the attached patch.
> Actually, it's designed to solve another problem, but may be your one has the
> same origin as that other.
Cool. Thanks. I recompiled the module and am trying it now. So far the
ethernet connection is fine but the above problem isn't reproducable with
100% accuracy and so it'll take me a wee while before I decide 'oooo....
aaaaa... that rocks my boat. it's fixed.'. :)
As such I'll try to give you a holler either in a few weeks time (if nothing
happens) or as soon as it breaks again.
--
CaT ([email protected]) *** Jenna has joined the channel.
<cat> speaking of mental giants..
<Jenna> me, a giant, bullshit
<Jenna> And i'm not mental
- An IRC session, 20/12/2000
On Tue, Feb 13, 2001 at 03:14:09PM +1100, CaT wrote:
> On Tue, Feb 13, 2001 at 09:26:38AM +0800, Andrey Savochkin wrote:
> > On Sun, Feb 11, 2001 at 10:40:33PM +1100, CaT wrote:
> > [snip]
> > > Feb 11 22:30:18 theirongiant kernel: eepro100: cmd_wait for(0x70) timedout with(0x70)!
> >
> > Please try the attached patch.
> > Actually, it's designed to solve another problem, but may be your one has the
> > same origin as that other.
>
> Cool. Thanks. I recompiled the module and am trying it now. So far the
> ethernet connection is fine but the above problem isn't reproducable with
> 100% accuracy and so it'll take me a wee while before I decide 'oooo....
> aaaaa... that rocks my boat. it's fixed.'. :)
It happened again. Same deal. Once was after a reboot and this time
was after a resume. :/
Help?
--
CaT ([email protected]) *** Jenna has joined the channel.
<cat> speaking of mental giants..
<Jenna> me, a giant, bullshit
<Jenna> And i'm not mental
- An IRC session, 20/12/2000
On Tue, Feb 20, 2001, CaT <[email protected]> wrote:
; > 100% accuracy and so it'll take me a wee while before I decide 'oooo....
; > aaaaa... that rocks my boat. it's fixed.'. :)
;
; It happened again. Same deal. Once was after a reboot and this time
; was after a resume. :/
What kind of trafic are you running?
--
No Kernel Hackers were harmed during writing of this email.
-Dragan
On Mon, Feb 19, 2001 at 03:37:02PM -0800, Dragan Stancevic wrote:
> On Tue, Feb 20, 2001, CaT <[email protected]> wrote:
> ; > 100% accuracy and so it'll take me a wee while before I decide 'oooo....
> ; > aaaaa... that rocks my boat. it's fixed.'. :)
> ;
> ; It happened again. Same deal. Once was after a reboot and this time
> ; was after a resume. :/
>
> What kind of trafic are you running?
None. This is before any traffic gets put through it. At worst the
card has the wrong IP for the network but that is not always the case
from memory.
--
CaT ([email protected]) *** Jenna has joined the channel.
<cat> speaking of mental giants..
<Jenna> me, a giant, bullshit
<Jenna> And i'm not mental
- An IRC session, 20/12/2000
On Tue, Feb 20, 2001, CaT <[email protected]> wrote:
;
; None. This is before any traffic gets put through it. At worst the
; card has the wrong IP for the network but that is not always the case
; from memory.
So where does that card get the address from, are you doing DHCP?
--
No Kernel Hackers were harmed during writing of this email.
-Dragan
On Mon, Feb 19, 2001 at 03:44:10PM -0800, Dragan Stancevic wrote:
> On Tue, Feb 20, 2001, CaT <[email protected]> wrote:
> ;
> ; None. This is before any traffic gets put through it. At worst the
> ; card has the wrong IP for the network but that is not always the case
> ; from memory.
>
> So where does that card get the address from, are you doing DHCP?
Set manually. In debian-speak: ifup eth0 where:
iface eth0 inet static
address 10.1.1.2
netmask 255.255.255.0
network 10.1.1.0
broadcast 10.1.1.255
gateway 10.1.1.1
So basically that does an ifconfig and route command I believe (or the
equivalent)
--
CaT ([email protected]) *** Jenna has joined the channel.
<cat> speaking of mental giants..
<Jenna> me, a giant, bullshit
<Jenna> And i'm not mental
- An IRC session, 20/12/2000
Hi,
On Tue, Feb 20, 2001 at 09:21:06AM +1100, CaT wrote:
> On Tue, Feb 13, 2001 at 03:14:09PM +1100, CaT wrote:
> > On Tue, Feb 13, 2001 at 09:26:38AM +0800, Andrey Savochkin wrote:
> > > On Sun, Feb 11, 2001 at 10:40:33PM +1100, CaT wrote:
> > > [snip]
> > > > Feb 11 22:30:18 theirongiant kernel: eepro100: cmd_wait for(0x70) timedout with(0x70)!
> > >
> > > Please try the attached patch.
> > > Actually, it's designed to solve another problem, but may be your one has the
> > > same origin as that other.
> >
> > Cool. Thanks. I recompiled the module and am trying it now. So far the
> > ethernet connection is fine but the above problem isn't reproducable with
> > 100% accuracy and so it'll take me a wee while before I decide 'oooo....
> > aaaaa... that rocks my boat. it's fixed.'. :)
>
> It happened again. Same deal. Once was after a reboot and this time
> was after a resume. :/
In my experiments wait_for_cmd timeouts almost always were related to
DumpStats command.
I think, we need to investigate what time constraints are related to this
command.
Best regards
Andrey
On Mon, 19 Feb 2001 14:49:35 -0800, Andrey Savochkin <[email protected]> wrote:
> On Tue, Feb 20, 2001 at 09:21:06AM +1100, CaT wrote:
>>
>> It happened again. Same deal. Once was after a reboot and this time
>> was after a resume. :/
>
> In my experiments wait_for_cmd timeouts almost always were related to
> DumpStats command.
> I think, we need to investigate what time constraints are related to this
> command.
Nothing documented...
CaT, can you apply this debugging patch and let us know what you get in the
logs? It should allow us to pinpoint the error a bit more precisely.
Thanks,
Ion
--
It is better to keep your mouth shut and be thought a fool,
than to open it and remove all doubt.
------------------------------------------
--- /mnt/3/linux-2.2.19pre/drivers/net/eepro100.c Thu Feb 15 16:09:19 2001
+++ linux-2.2.18/drivers/net/eepro100.c Mon Feb 19 16:13:45 2001
@@ -368,9 +368,16 @@
#define outl writel
#endif
+static char *cmdwait_string = "wait_for_cmd_done timed out at %s:%d\n";
+#define wait_for_cmd_done(ioaddr) \
+ do { \
+ if (do_wait_for_cmd_done(ioaddr)) \
+ printk(cmdwait_string, __FUNCTION__, __LINE__); \
+ } while (0)
+
/* How to wait for the command unit to accept a command.
Typically this takes 0 ticks. */
-static inline void wait_for_cmd_done(long cmd_ioaddr)
+static inline int do_wait_for_cmd_done(long cmd_ioaddr)
{
int wait = 20000;
char cmd_reg1, cmd_reg2;
@@ -383,10 +390,10 @@
if(cmd_reg2){
printk(KERN_ALERT "eepro100: cmd_wait for(%#2.2x) timedout with(%#2.2x)!\n",
cmd_reg1, cmd_reg2);
-
+ return 1;
}
}
-
+ return 0;
}
/* Offsets to the various registers.
On Mon, Feb 19, 2001 at 04:18:40PM -0800, Ion Badulescu wrote:
> > In my experiments wait_for_cmd timeouts almost always were related to
> > DumpStats command.
> > I think, we need to investigate what time constraints are related to this
> > command.
>
> Nothing documented...
>
> CaT, can you apply this debugging patch and let us know what you get in the
> logs? It should allow us to pinpoint the error a bit more precisely.
patched, old removed, new installed, waiting for fubar. :)
still with 2.2.18
--
CaT ([email protected]) *** Jenna has joined the channel.
<cat> speaking of mental giants..
<Jenna> me, a giant, bullshit
<Jenna> And i'm not mental
- An IRC session, 20/12/2000
On Tue, Feb 20, 2001 at 11:31:52AM +1100, CaT wrote:
> On Mon, Feb 19, 2001 at 04:18:40PM -0800, Ion Badulescu wrote:
> > > In my experiments wait_for_cmd timeouts almost always were related to
> > > DumpStats command.
> > > I think, we need to investigate what time constraints are related to this
> > > command.
> >
> > Nothing documented...
> >
> > CaT, can you apply this debugging patch and let us know what you get in the
> > logs? It should allow us to pinpoint the error a bit more precisely.
>
> patched, old removed, new installed, waiting for fubar. :)
Ok. this is what I got in my kern.log. this is on a fresh reboot.
Feb 20 18:31:49 theirongiant kernel: eepro100: cmd_wait for(0x70) timedout with(0x70)!
Feb 20 18:31:49 theirongiant kernel: eepro100: cmd_wait for(0x10) timedout with(0x10)!
Feb 20 18:31:49 theirongiant kernel: eepro100: cmd_wait for(0xffffff90) timedout with(0xffffff90)!
Feb 20 18:32:21 theirongiant last message repeated 29 times
Feb 20 18:33:15 theirongiant last message repeated 31 times
Feb 20 18:33:16 theirongiant kernel: eth0: Transmit timed out: status 0000 0c90 at 0/63 command 0001a000.
Feb 20 18:33:16 theirongiant kernel: eth0: Tx ring dump, Tx queue 63 / 0:
Feb 20 18:33:16 theirongiant kernel: eth0: * 0 0001a000.
Feb 20 18:33:16 theirongiant kernel: eth0: 1 00020000.
Feb 20 18:33:16 theirongiant kernel: eth0: 2 00030000.
Feb 20 18:33:16 theirongiant kernel: eth0: 3 00030000.
Feb 20 18:33:16 theirongiant kernel: eth0: 4 00030000.
Feb 20 18:33:16 theirongiant kernel: eth0: 5 00030000.
Feb 20 18:33:16 theirongiant kernel: eth0: 6 00030000.
Feb 20 18:33:16 theirongiant kernel: eth0: 7 00030000.
Feb 20 18:33:16 theirongiant kernel: eth0: 8 00020000.
Feb 20 18:33:16 theirongiant kernel: eth0: 9 00030000.
Feb 20 18:33:16 theirongiant kernel: eth0: 10 00030000.
Feb 20 18:33:16 theirongiant kernel: eth0: 11 00030000.
Feb 20 18:33:16 theirongiant kernel: eth0: 12 00030000.
Feb 20 18:33:16 theirongiant kernel: eth0: 13 000c0000.
Feb 20 18:33:16 theirongiant kernel: eth0: 14 000c0000.
Feb 20 18:33:16 theirongiant kernel: eth0: 15 00030000.
Feb 20 18:33:16 theirongiant kernel: eth0: 16 200c0000.
Feb 20 18:33:16 theirongiant kernel: eth0: 17 000c0000.
Feb 20 18:33:16 theirongiant kernel: eth0: 18 00030000.
Feb 20 18:33:16 theirongiant kernel: eth0: 19 000c0000.
Feb 20 18:33:16 theirongiant kernel: eth0: 20 000c0000.
Feb 20 18:33:16 theirongiant kernel: eth0: 21 00030000.
Feb 20 18:33:16 theirongiant kernel: eth0: 22 00030000.
Feb 20 18:33:16 theirongiant kernel: eth0: 23 00030000.
Feb 20 18:33:16 theirongiant kernel: eth0: 24 00030000.
Feb 20 18:33:16 theirongiant kernel: eth0: 25 00030000.
Feb 20 18:33:16 theirongiant kernel: eth0: 26 00030000.
Feb 20 18:33:16 theirongiant kernel: eth0: 27 00030000.
Feb 20 18:33:16 theirongiant kernel: eth0: 28 00030000.
Feb 20 18:33:16 theirongiant kernel: eth0: 29 00030000.
Feb 20 18:33:16 theirongiant kernel: eth0: 30 00030000.
Feb 20 18:33:16 theirongiant kernel: eth0: 31 00030000.
Feb 20 18:33:16 theirongiant kernel: eth0: 32 00030000.
Feb 20 18:33:16 theirongiant kernel: eth0: 33 00030000.
Feb 20 18:33:16 theirongiant kernel: eth0: 34 00030000.
Feb 20 18:33:16 theirongiant kernel: eth0: 35 00030000.
Feb 20 18:33:16 theirongiant kernel: eth0: 36 00030000.
Feb 20 18:33:16 theirongiant kernel: eth0: 37 00030000.
Feb 20 18:33:16 theirongiant kernel: eth0: 38 00030000.
Feb 20 18:33:16 theirongiant kernel: eth0: 39 00030000.
Feb 20 18:33:16 theirongiant kernel: eth0: 40 00030000.
Feb 20 18:33:16 theirongiant kernel: eth0: 41 00030000.
Feb 20 18:33:16 theirongiant kernel: eth0: 42 00030000.
Feb 20 18:33:16 theirongiant kernel: eth0: 43 00030000.
Feb 20 18:33:16 theirongiant kernel: eth0: 44 00030000.
Feb 20 18:33:16 theirongiant kernel: eth0: 45 00030000.
Feb 20 18:33:16 theirongiant kernel: eth0: 46 00030000.
Feb 20 18:33:16 theirongiant kernel: eth0: 47 00030000.
Feb 20 18:33:16 theirongiant kernel: eth0: 48 00030000.
Feb 20 18:33:16 theirongiant kernel: eth0: 49 00030000.
Feb 20 18:33:16 theirongiant kernel: eth0: 50 00030000.
Feb 20 18:33:16 theirongiant kernel: eth0: 51 00030000.
Feb 20 18:33:16 theirongiant kernel: eth0: 52 00030000.
Feb 20 18:33:16 theirongiant kernel: eth0: 53 00030000.
Feb 20 18:33:16 theirongiant kernel: eth0: 54 00030000.
Feb 20 18:33:16 theirongiant kernel: eth0: 55 000c0000.
Feb 20 18:33:16 theirongiant kernel: eth0: 56 000c0000.
Feb 20 18:33:16 theirongiant kernel: eth0: 57 00030000.
Feb 20 18:33:16 theirongiant kernel: eth0: 58 000c0000.
Feb 20 18:33:16 theirongiant kernel: eth0: 59 000c0000.
Feb 20 18:33:16 theirongiant kernel: eth0: 60 00030000.
Feb 20 18:33:16 theirongiant kernel: eth0: 61 00030000.
Feb 20 18:33:16 theirongiant kernel: eth0: 62 40030000.
Feb 20 18:33:16 theirongiant kernel: eth0: =63 00000000.
Feb 20 18:33:16 theirongiant kernel: eth0: Printing Rx ring (next to receive into 0, dirty index 0).
Feb 20 18:33:16 theirongiant kernel: eth0: *= 0 00000001.
Feb 20 18:33:16 theirongiant kernel: eth0: 1 00000001.
Feb 20 18:33:16 theirongiant kernel: eth0: 2 00000001.
Feb 20 18:33:16 theirongiant kernel: eth0: 3 00000001.
Feb 20 18:33:16 theirongiant kernel: eth0: 4 00000001.
Feb 20 18:33:16 theirongiant kernel: eth0: 5 00000001.
Feb 20 18:33:16 theirongiant kernel: eth0: 6 00000001.
Feb 20 18:33:16 theirongiant kernel: eth0: 7 00000001.
Feb 20 18:33:16 theirongiant kernel: eth0: 8 00000001.
Feb 20 18:33:16 theirongiant kernel: eth0: 9 00000001.
Feb 20 18:33:16 theirongiant kernel: eth0: 10 00000001.
Feb 20 18:33:16 theirongiant kernel: eth0: 11 00000001.
Feb 20 18:33:16 theirongiant kernel: eth0: 12 00000001.
Feb 20 18:33:16 theirongiant kernel: eth0: 13 00000001.
Feb 20 18:33:16 theirongiant kernel: eth0: 14 00000001.
Feb 20 18:33:16 theirongiant kernel: eth0: 15 00000001.
Feb 20 18:33:16 theirongiant kernel: eth0: 16 00000001.
Feb 20 18:33:16 theirongiant kernel: eth0: 17 00000001.
Feb 20 18:33:16 theirongiant kernel: eth0: 18 00000001.
Feb 20 18:33:16 theirongiant kernel: eth0: 19 00000001.
Feb 20 18:33:16 theirongiant kernel: eth0: 20 00000001.
Feb 20 18:33:16 theirongiant kernel: eth0: 21 00000001.
Feb 20 18:33:16 theirongiant kernel: eth0: 22 00000001.
Feb 20 18:33:16 theirongiant kernel: eth0: 23 00000001.
Feb 20 18:33:16 theirongiant kernel: eth0: 24 00000001.
Feb 20 18:33:16 theirongiant kernel: eth0: 25 00000001.
Feb 20 18:33:16 theirongiant kernel: eth0: 26 00000001.
Feb 20 18:33:16 theirongiant kernel: eth0: 27 00000001.
Feb 20 18:33:16 theirongiant kernel: eth0: 28 00000001.
Feb 20 18:33:16 theirongiant kernel: eth0: 29 00000001.
Feb 20 18:33:16 theirongiant kernel: eth0: 30 00000001.
Feb 20 18:33:16 theirongiant kernel: eth0: 31 00000001.
Feb 20 18:33:16 theirongiant kernel: eth0: 32 00000001.
Feb 20 18:33:16 theirongiant kernel: eth0: 33 00000001.
Feb 20 18:33:16 theirongiant kernel: eth0: 34 00000001.
Feb 20 18:33:16 theirongiant kernel: eth0: 35 00000001.
Feb 20 18:33:16 theirongiant kernel: eth0: 36 00000001.
Feb 20 18:33:16 theirongiant kernel: eth0: 37 00000001.
Feb 20 18:33:16 theirongiant kernel: eth0: 38 00000001.
Feb 20 18:33:16 theirongiant kernel: eth0: 39 00000001.
Feb 20 18:33:16 theirongiant kernel: eth0: 40 00000001.
Feb 20 18:33:16 theirongiant kernel: eth0: 41 00000001.
Feb 20 18:33:16 theirongiant kernel: eth0: 42 00000001.
Feb 20 18:33:16 theirongiant kernel: eth0: 43 00000001.
Feb 20 18:33:16 theirongiant kernel: eth0: 44 00000001.
Feb 20 18:33:16 theirongiant kernel: eth0: 45 00000001.
Feb 20 18:33:16 theirongiant kernel: eth0: 46 00000001.
Feb 20 18:33:16 theirongiant kernel: eth0: 47 00000001.
Feb 20 18:33:16 theirongiant kernel: eth0: 48 00000001.
Feb 20 18:33:16 theirongiant kernel: eth0: 49 00000001.
Feb 20 18:33:16 theirongiant kernel: eth0: 50 00000001.
Feb 20 18:33:16 theirongiant kernel: eth0: 51 00000001.
Feb 20 18:33:16 theirongiant kernel: eth0: 52 00000001.
Feb 20 18:33:16 theirongiant kernel: eth0: 53 00000001.
Feb 20 18:33:16 theirongiant kernel: eth0: 54 00000001.
Feb 20 18:33:16 theirongiant kernel: eth0: 55 00000001.
Feb 20 18:33:16 theirongiant kernel: eth0: 56 00000001.
Feb 20 18:33:16 theirongiant kernel: eth0: 57 00000001.
Feb 20 18:33:16 theirongiant kernel: eth0: 58 00000001.
Feb 20 18:33:16 theirongiant kernel: eth0: 59 00000001.
Feb 20 18:33:16 theirongiant kernel: eth0: 60 00000001.
Feb 20 18:33:16 theirongiant kernel: eth0: 61 00000001.
Feb 20 18:33:16 theirongiant kernel: eth0: 62 00000001.
Feb 20 18:33:16 theirongiant kernel: eth0: l 63 c0000002.
--
CaT ([email protected]) *** Jenna has joined the channel.
<cat> speaking of mental giants..
<Jenna> me, a giant, bullshit
<Jenna> And i'm not mental
- An IRC session, 20/12/2000
On Tue, 20 Feb 2001, CaT wrote:
> > patched, old removed, new installed, waiting for fubar. :)
>
> Ok. this is what I got in my kern.log. this is on a fresh reboot.
>
> Feb 20 18:31:49 theirongiant kernel: eepro100: cmd_wait for(0x70) timedout with(0x70)!
> Feb 20 18:31:49 theirongiant kernel: eepro100: cmd_wait for(0x10) timedout with(0x10)!
> Feb 20 18:31:49 theirongiant kernel: eepro100: cmd_wait for(0xffffff90) timedout with(0xffffff90)!
> Feb 20 18:32:21 theirongiant last message repeated 29 times
> Feb 20 18:33:15 theirongiant last message repeated 31 times
Are you sure this driver has my patch applied? There is no way you could
have gotten these messages without getting the other printk as well..
Can you check it again, please?
Thanks,
Ion
--
It is better to keep your mouth shut and be thought a fool,
than to open it and remove all doubt.
On Tue, Feb 20, 2001 at 02:00:31AM -0800, Ion Badulescu wrote:
> Are you sure this driver has my patch applied? There is no way you could
> have gotten these messages without getting the other printk as well..
>
> Can you check it again, please?
*sigh* too much kernel bouncing. I got the right kernel this time. applied
the patch and I'm off again. sorry about that. whacky day. :/
--
CaT ([email protected]) *** Jenna has joined the channel.
<cat> speaking of mental giants..
<Jenna> me, a giant, bullshit
<Jenna> And i'm not mental
- An IRC session, 20/12/2000
On Tue, Feb 13, 2001 at 09:26:38AM +0800, Andrey Savochkin wrote:
> On Sun, Feb 11, 2001 at 10:40:33PM +1100, CaT wrote:
> [snip]
> > Feb 11 22:30:18 theirongiant kernel: eepro100: cmd_wait for(0x70) timedout with(0x70)!
>
> Please try the attached patch.
> Actually, it's designed to solve another problem, but may be your one has the
> same origin as that other.
> Index: eepro100.c
Patch appears to have worked. After 2 weeks of actually using the right
module (*sheepish grin*) I've not had the card popup the above error
message. woo.
So thanks for that. :) Majorly happy about things now. :)
And now... to put ext3 on my laptop.
--
CaT ([email protected]) *** Jenna has joined the channel.
<cat> speaking of mental giants..
<Jenna> me, a giant, bullshit
<Jenna> And i'm not mental
- An IRC session, 20/12/2000