8139cp 0000:03:08.0: This (id 10ec:8139 rev 10) is not an 8139C+ compatible chip

[stephane lepain]

Hi,

I have had this error message coming up every time I start my PC where
it seems to be searching for the right driver. The problem is that it
takes a while at start time for my box to switch from "8139cp" to "8139too"
Is there a way I could tell my box to use the driver 8139too instead of
it choosing the 8139cp?

Sorry if I am not being clear and concise. I have just started with
Linux and I am learning at the moment.

_My Config_

Hardware: AMD64 3800+
OS: Debian testing

*Mar  1 10:50:52 margoullat kernel: ata4: SATA link down (SStatus 0
SControl 310)
Mar  1 10:50:52 margoullat kernel: 8139cp 0000:03:08.0: This (id
10ec:8139 rev 10) is not an 8139C+ compatible chip
Mar  1 10:50:52 margoullat kernel: 8139cp 0000:03:08.0: Try the
"8139too" driver instead.
Mar  1 10:50:52 margoullat kernel: 8139too Fast Ethernet driver 0.9.28*


--
To UNSUBSCRIBE, email to debian-user-REQUEST@...
with a subject of "unsubscribe". Trouble? Contact listmaster@...

[Adrian Levi]

On 01/03/2008, stephane lepain <penguindeb@...> wrote:

> Hi,
>
>  I have had this error message coming up every time I start my PC where
>  it seems to be searching for the right driver. The problem is that it
>  takes a while at start time for my box to switch from "8139cp" to "8139too"
>  Is there a way I could tell my box to use the driver 8139too instead of
>  it choosing the 8139cp?
>
>  Sorry if I am not being clear and concise. I have just started with
>  Linux and I am learning at the moment.

Welcome to the community,

For your problem you could try placing 8139too into
/etc/modules

That might see that your 8139too driver gets loaded first.
Incidentally comment any references to 8139cp that you run across. HTH

Adrian

--
24x7x365 != 24x7x52 Stupid or bad maths?
<erno> hm. I've lost a machine.. literally _lost_. it responds to
ping, it works completely, I just can't figure out where in my
apartment it is.


--
To UNSUBSCRIBE, email to debian-user-REQUEST@...
with a subject of "unsubscribe". Trouble? Contact listmaster@...

[stephane lepain]

Adrian Levi a écrit :

> On 01/03/2008, stephane lepain <penguindeb@...> wrote:
>  
>> Hi,
>>
>>  I have had this error message coming up every time I start my PC where
>>  it seems to be searching for the right driver. The problem is that it
>>  takes a while at start time for my box to switch from "8139cp" to "8139too"
>>  Is there a way I could tell my box to use the driver 8139too instead of
>>  it choosing the 8139cp?
>>
>>  Sorry if I am not being clear and concise. I have just started with
>>  Linux and I am learning at the moment.
>>    
>
> Welcome to the community,
>
> For your problem you could try placing 8139too into
> /etc/modules
>
> That might see that your 8139too driver gets loaded first.
> Incidentally comment any references to 8139cp that you run across. HTH
>
> Adrian
>
>  

After one day of trying to dig up a solution for my problem. I have given up

Nothing seems to be working. I still get the same error message
"8139cp 0000:03:08.0: This (id 10ec:8139 rev 10) is not an 8139C+
compatible chip"

There seems to be a bug with the driver 8139too with realtek ethernet card.

http://groups.google.fr/group/comp.os.linux.hardware/browse_thread/thread/7cc2d557544f3228/ca5ce7244b8e55a8?hl=fr&lnk=st&q=8139cp+This+is+not+an+8139C%2B+compatible+chip#ca5ce7244b8e55a8

My biggest trouble is that I haven't found any fix for it.

What is hard to understand is that when I do a lspci -v I can clearly
see that the two modules  are loaded (8139cp, and 8139too). So why on
earth would I still get this error message if the module 8139too is
loaded in the kernel. My network card should be up and working.
Shouldn't it. Unfortunatly, I am not experienced enough to dig deeper
than that. Hope someone could give me hand here :)

03:08.0 Ethernet controller: Realtek Semiconductor Co., Ltd.
RTL-8139/8139C/8139C+ (rev 10)
Subsystem: Realtek Semiconductor Co., Ltd. RT8139
Flags: medium devsel, IRQ 16
I/O ports at ac00 [size=256]
Memory at fdefe000 (32-bit, non-prefetchable) [size=256]
Capabilities: [50] Power Management version 2
Kernel modules: 8139cp, 8139too



--
To UNSUBSCRIBE, email to debian-user-REQUEST@...
with a subject of "unsubscribe". Trouble? Contact listmaster@...

[Florian Kulzer-3]

On Sat, Mar 01, 2008 at 11:52:50 +0100, stephane lepain wrote:

> Hi,
>
> I have had this error message coming up every time I start my PC where  
> it seems to be searching for the right driver. The problem is that it  
> takes a while at start time for my box to switch from "8139cp" to
> "8139too"
> Is there a way I could tell my box to use the driver 8139too instead of  
> it choosing the 8139cp?
>
> Sorry if I am not being clear and concise. I have just started with  
> Linux and I am learning at the moment.
>
> _My Config_
>
> Hardware: AMD64 3800+
> OS: Debian testing
>
> *Mar  1 10:50:52 margoullat kernel: ata4: SATA link down (SStatus 0  
> SControl 310)
> Mar  1 10:50:52 margoullat kernel: 8139cp 0000:03:08.0: This (id  
> 10ec:8139 rev 10) is not an 8139C+ compatible chip
> Mar  1 10:50:52 margoullat kernel: 8139cp 0000:03:08.0: Try the  
> "8139too" driver instead.
> Mar  1 10:50:52 margoullat kernel: 8139too Fast Ethernet driver 0.9.28*

Please tell me if I understand you correctly: Your RTL8139 does work
once the system comes up; your only problem is getting rid of the
message and the delay during boot?

Try to unload the 8139cp module after the system has booted by running
this command as root:

modprobe -rv 8139cp

Do you get any error messages? Check with "lsmod | grep 8139" and make
sure that 8139cp is really gone and only 8139too is still loaded. Verify
that your network still works, e.g. by running "ping www.kernel.org".

Assuming that this is all OK, you then have to generate a file that
tells modprobe not to load the 8139cp anymore during boot. To do this,
you can run (again as root):

echo -e "blacklist 8139cp\ninstall 8139cp /bin/true" > /etc/modprobe.d/local-8139cp

This should create the file /etc/modprobe.d/local-8139cp containing
these two lines:

blacklist 8139cp
install 8139cp /bin/true

Check with "cat /etc/modprobe.d/local-8139cp" if this was successful.
(If you already know how to use one of the various text editors
available under Linux then you can of course also create the file by
entering these two lines in your editor of choice and saving the
result.)

Then reboot and test if your system behaves properly now. Report back if
it does not; in that case we will have to take a closer look at your
initrd and maybe also at modules.dep.

--
Regards,            | http://users.icfo.es/Florian.Kulzer
          Florian   |


--
To UNSUBSCRIBE, email to debian-user-REQUEST@...
with a subject of "unsubscribe". Trouble? Contact listmaster@...

[Jamin Davis]

stephane lepain wrote:

>> For your problem you could try placing 8139too into
>> /etc/modules
>>
>> That might see that your 8139too driver gets loaded first.
>> Incidentally comment any references to 8139cp that you run across. HTH
>>
>> Adrian
>>
>>  
> After one day of trying to dig up a solution for my problem. I have
> given up

You might need a little more patience using Linux ;-).

> Nothing seems to be working. I still get the same error message
> "8139cp 0000:03:08.0: This (id 10ec:8139 rev 10) is not an 8139C+
> compatible chip"

You can blacklist the 8139cp module in /etc/modprobe.d/blacklist file
(might need to create this if it doesn't already exist):

blacklist 8139cp

and if you have 8139too in /etc/modules then the boot process should
load that instead of 8139cp. I have checked on a machine which has an
8139too NIC and that works for me. There's a package called nictools-pci
which has a file rtl8139-diag -- might be useful for fixing 8139 related
probs.


--
Jamin @ Home @ Chester UK


--
To UNSUBSCRIBE, email to debian-user-REQUEST@...
with a subject of "unsubscribe". Trouble? Contact listmaster@...

[Andrew Sackville-West]

On Sat, Mar 01, 2008 at 10:00:49PM +0000, Jamin Davis wrote:

> stephane lepain wrote:
>
>
>>> For your problem you could try placing 8139too into
>>> /etc/modules
>>>
>>> That might see that your 8139too driver gets loaded first.
>>> Incidentally comment any references to 8139cp that you run across. HTH
>>>
>>> Adrian
>>>
>>>  
>> After one day of trying to dig up a solution for my problem. I have  
>> given up
>
> You might need a little more patience using Linux ;-).

but once it's working, it'll work so well for so long that you'll
forget how to fix it if it comes up again...

>
>> Nothing seems to be working. I still get the same error message
>> "8139cp 0000:03:08.0: This (id 10ec:8139 rev 10) is not an 8139C+  
>> compatible chip"
>
> You can blacklist the 8139cp module in /etc/modprobe.d/blacklist file  
> (might need to create this if it doesn't already exist):
>
> blacklist 8139cp
>
> and if you have 8139too in /etc/modules then the boot process should  
> load that instead of 8139cp. I have checked on a machine which has an  
> 8139too NIC and that works for me. There's a package called nictools-pci  
> which has a file rtl8139-diag -- might be useful for fixing 8139 related  
> probs.
>

and the blacklisting won't work if the module is in your initrd! You
at least need to run update-initramfs and you would probably be
advised to unpack one to make *sure* it's not in there...

A

[Jamin Davis]

Andrew Sackville-West wrote:

> and the blacklisting won't work if the module is in your initrd! You
> at least need to run update-initramfs and you would probably be
> advised to unpack one to make *sure* it's not in there...

Good point. But if the blacklist did work there'd be no need to check
the initrd :). Yes, of course!

--
Jamin @ Home @ Chester UK


--
To UNSUBSCRIBE, email to debian-user-REQUEST@...
with a subject of "unsubscribe". Trouble? Contact listmaster@...

[Andrew Sackville-West]

On Mon, Mar 03, 2008 at 02:07:17AM +0000, Jamin Davis wrote:
> Andrew Sackville-West wrote:
>
>> and the blacklisting won't work if the module is in your initrd! You
>> at least need to run update-initramfs and you would probably be
>> advised to unpack one to make *sure* it's not in there...
>
> Good point. But if the blacklist did work there'd be no need to check  
> the initrd :). Yes, of course!

I'm confused now. My point was that if you blacklist a module but the
initrd's haven't been rebuilt, you may still have the module in the
initrd. Honestly, I don't know, without looking, what net modules
might get included in the initrd, but if your initrd's are built with
a "most" modules configuration, it just may be in there. If that
module gets inserted during the initrd phase of the boot, no amount of
blacklisting will do you any good because it's already inserted.

But I'm not fully up on this thread, so I'll bow out now.

A

[Dominik Dera]

Andrew Sackville-West wrote:

On Sat, Mar 01, 2008 at 10:00:49PM +0000, Jamin Davis wrote:
> stephane lepain wrote:
>
>
>>> For your problem you could try placing 8139too into
>>> /etc/modules
>>>
>>> That might see that your 8139too driver gets loaded first.
>>> Incidentally comment any references to 8139cp that you run across. HTH
>>>
>>> Adrian
>>>
>>>  
>> After one day of trying to dig up a solution for my problem. I have  
>> given up
>
> You might need a little more patience using Linux ;-).

but once it's working, it'll work so well for so long that you'll
forget how to fix it if it comes up again...

>
>> Nothing seems to be working. I still get the same error message
>> "8139cp 0000:03:08.0: This (id 10ec:8139 rev 10) is not an 8139C+  
>> compatible chip"
>
> You can blacklist the 8139cp module in /etc/modprobe.d/blacklist file  
> (might need to create this if it doesn't already exist):
>
> blacklist 8139cp
>
> and if you have 8139too in /etc/modules then the boot process should  
> load that instead of 8139cp. I have checked on a machine which has an  
> 8139too NIC and that works for me. There's a package called nictools-pci  
> which has a file rtl8139-diag -- might be useful for fixing 8139 related  
> probs.
>

and the blacklisting won't work if the module is in your initrd! You
at least need to run update-initramfs and you would probably be
advised to unpack one to make *sure* it's not in there...

A

 

This problem can be solved by removing 8139cp module, and afterwards updating initramfs. So it goes like this:

rmmod -v 8139cp
update-initramfs -uv

[Andrei Popescu-3]

On Mon,21.Jul.08, 03:55:20, Dominik Dera wrote:
 
> Andrew Sackville-West wrote:
 
> > and the blacklisting won't work if the module is in your initrd! You
> > at least need to run update-initramfs and you would probably be
> > advised to unpack one to make *sure* it's not in there...
 
> This problem can be solved by removing 8139cp module, and afterwards
> updating initramfs. So it goes like this:
>
> rmmod -v 8139cp
> update-initramfs -uv
 
This will not survive a linux-image update.

Regards,
Andrei
--
If you can't explain it simply, you don't understand it well enough.
(Albert Einstein)

[Nigel Henry-3]

On Monday 21 July 2008 13:27, Andrei Popescu wrote:

> On Mon,21.Jul.08, 03:55:20, Dominik Dera wrote:
> > Andrew Sackville-West wrote:
> > > and the blacklisting won't work if the module is in your initrd! You
> > > at least need to run update-initramfs and you would probably be
> > > advised to unpack one to make *sure* it's not in there...
> >
> > This problem can be solved by removing 8139cp module, and afterwards
> > updating initramfs. So it goes like this:
> >
> > rmmod -v 8139cp
> > update-initramfs -uv
>
> This will not survive a linux-image update.
>
> Regards,
> Andrei

Personally, I've never found any problems with both modules being loaded. I've
had to add 8139too to /etc/modules, and both are loaded, and I think the
bootup messages complain about 8139cp, and then goes on to say "using
8139too".

If the blacklisting won't work, I've had success with loading the unwanted
module to /bin/true, where it's loaded into nowhere land. Add a line to a
file in /etc/modprobe.d. I don't know if it matters which file you add it to,
and I put it, in the case of "pcspkr" in the alsa-base file. See below.

install 8139cp /bin/true

Nigel.


--
To UNSUBSCRIBE, email to debian-user-REQUEST@...
with a subject of "unsubscribe". Trouble? Contact listmaster@...

[Andrew Sackville-West]

On Mon, Jul 21, 2008 at 02:24:46PM +0200, Nigel Henry wrote:

> On Monday 21 July 2008 13:27, Andrei Popescu wrote:
> > On Mon,21.Jul.08, 03:55:20, Dominik Dera wrote:
> > > Andrew Sackville-West wrote:
> > > > and the blacklisting won't work if the module is in your initrd! You
> > > > at least need to run update-initramfs and you would probably be
> > > > advised to unpack one to make *sure* it's not in there...
> > >
> > > This problem can be solved by removing 8139cp module, and afterwards
> > > updating initramfs. So it goes like this:
> > >
> > > rmmod -v 8139cp
> > > update-initramfs -uv
> >
> > This will not survive a linux-image update.
> >
> > Regards,
> > Andrei
>
> Personally, I've never found any problems with both modules being loaded. I've
> had to add 8139too to /etc/modules, and both are loaded, and I think the
> bootup messages complain about 8139cp, and then goes on to say "using
> 8139too".
>
> If the blacklisting won't work, I've had success with loading the unwanted
> module to /bin/true, where it's loaded into nowhere land. Add a line to a
> file in /etc/modprobe.d. I don't know if it matters which file you add it to,
> and I put it, in the case of "pcspkr" in the alsa-base file. See below.
>
> install 8139cp /bin/true

make a "local" file in modprobe.d so that updates to those files won't
bork your custom stuff.

A

[Nigel Henry-3]

On Monday 21 July 2008 17:42, Andrew Sackville-West wrote:

> On Mon, Jul 21, 2008 at 02:24:46PM +0200, Nigel Henry wrote:
> > On Monday 21 July 2008 13:27, Andrei Popescu wrote:
> > > On Mon,21.Jul.08, 03:55:20, Dominik Dera wrote:
> > > > Andrew Sackville-West wrote:
> > > > > and the blacklisting won't work if the module is in your initrd!
> > > > > You at least need to run update-initramfs and you would probably be
> > > > > advised to unpack one to make *sure* it's not in there...
> > > >
> > > > This problem can be solved by removing 8139cp module, and afterwards
> > > > updating initramfs. So it goes like this:
> > > >
> > > > rmmod -v 8139cp
> > > > update-initramfs -uv
> > >
> > > This will not survive a linux-image update.
> > >
> > > Regards,
> > > Andrei
> >
> > Personally, I've never found any problems with both modules being loaded.
> > I've had to add 8139too to /etc/modules, and both are loaded, and I think
> > the bootup messages complain about 8139cp, and then goes on to say "using
> > 8139too".
> >
> > If the blacklisting won't work, I've had success with loading the
> > unwanted module to /bin/true, where it's loaded into nowhere land. Add a
> > line to a file in /etc/modprobe.d. I don't know if it matters which file
> > you add it to, and I put it, in the case of "pcspkr" in the alsa-base
> > file. See below.
> >
> > install 8139cp /bin/true
>
> make a "local" file in modprobe.d so that updates to those files won't
> bork your custom stuff.
>
> A

Thanks for that suggestion Andrew. With Fedora it's easy, as it's all added
to /etc/modprobe.conf. I've always been a bit confused as to where to add
options lines, etc, in my Debian installs /etc/modprobe.d, as there are so
many files in this directory. Obviously some are a no-go, but it becomes a
bit hit and miss, like close your eyes, and stick a pin in. Ok I'll put the
option in this one.

I'll definately create a "local" file, and use this in the future.

Thanks again.

Nigel.





--
To UNSUBSCRIBE, email to debian-user-REQUEST@...
with a subject of "unsubscribe". Trouble? Contact listmaster@...