On Mon, 01 Jan 2007 23:36:53 +0100, MadKraut staggered into the Black
Sun and said:
> Debian 3.1, ("Sarge" with kernel 2.4.27) everything works like a charm
> straight away. [But on Ubuntu...]
>
> eth0 Link encap:Ethernet HWaddr 00:30:54:00:2B:EE
> inet addr:192.168.254.196 Bcast:192.168.254.255
> ubuntu@ubuntu:~$ ping 192.168.254.1
> From 192.168.254.196 icmp_seq=1 Destination Host Unreachable
> [17180006.036000] NETDEV WATCHDOG: eth0: transmit timed out

There is a kernel-level problem with something here. Not usually a good
sign.

> [17179651.188000] 8139cp: pci dev 0000:00:09.0 (id 10ec:8139 rev 10) is not
> an 8139C+ compatible chip
> [17179651.188000] 8139cp: Try the "8139too" driver instead.

> Very strangely, lsmod showed _both_ driver modules, "8139cp" and
> "8139too" as loaded.

Module loading behavior changed a few years back; now you can modprobe
devices that don't exist on the bus. This is supposed to make
hotplugging easier, but it removes a semi-useful diagnostic tool.

> 00:09.0 Ethernet controller: Realtek Semiconductor Co., Ltd.
> RTL-8139/8139C/8139C+ (rev 10)
> Subsystem: Realtek Semiconductor Co., Ltd. RT8139
> Flags: bus master, medium devsel, latency 64, IRQ 10

It has an IRQ, that's good. Are there 7 or 8 other devices trying to
use the same IRQ? If so, enabling APIC may help.

> As I have mentioned, the problem seems to be exactly the same under
> Ubuntu and Debian 4.0.

I have seen *far* too many distro-supplied kernels have weird problems
with perfectly ordinary hardware to trust them for much beyond getting
the system installed. Getting a vanilla tarball onto this system and
doing the make menuconfig shuffle might solve this problem.

--
He is a rhythmic movement of the penguins, is Tux.
--MegaHAL, trained on random gibberish
Matt G|There is no Darkness in Eternity/But only Light too dim for us to see

MadKraut wrote:
> I have a problem getting the network controller...to work..
> An attempt (!) to load the driver module "8139cp" and an
> apparently successfull load of "8139too"...

I, along with many others, also have a problem with 8139 network interface card.
My notes say that it worked on my machine under the Breezy Badger version of
Ubuntu, but not Dapper Drake (6.06). See the #48456 bug, "kubuntu 6.06 LTS does
not support Realtek 8139 network card" at
https://launchpad.net/distros/ubuntu....15/+bug/48456.

My boot hangs at the modprobe of the 8139too module. It will not continue until
I remove the network cable from the card. Of course, the card still doesn't
work but at least the computer boots. (If I blacklist the 8139too module there
is no hang - and no network.)

> As I have mentioned, the problem seems to be exactly the same under
> Ubuntu and Debian 4.0.

You are probably running version 0.9.27 of the 8139too module. Perhaps the
problem is fixed in version 0.9.28 which I think is current. Perhaps the 8139
module maintainer, Jeff Garzik, is working on the problem. See line 134 of
http://lxr.linux.no/source/MAINTAINERS?v=2.6.18.

--
Chuck

Dances With Crows wrote:

> On Mon, 01 Jan 2007 23:36:53 +0100, MadKraut staggered into the Black
> Sun and said:
>> Debian 3.1, ("Sarge" with kernel 2.4.27) everything works like a charm
>> straight away. [But on Ubuntu...]
>>
>> eth0 Link encap:Ethernet HWaddr 00:30:54:00:2B:EE
>> inet addr:192.168.254.196 Bcast:192.168.254.255
>> ubuntu@ubuntu:~$ ping 192.168.254.1
>> From 192.168.254.196 icmp_seq=1 Destination Host Unreachable
>> [17180006.036000] NETDEV WATCHDOG: eth0: transmit timed out
>
> There is a kernel-level problem with something here. Not usually a good
> sign.
>
>> [17179651.188000] 8139cp: pci dev 0000:00:09.0 (id 10ec:8139 rev 10) is
>> [not
>> an 8139C+ compatible chip
>> [17179651.188000] 8139cp: Try the "8139too" driver instead.
>
>> Very strangely, lsmod showed _both_ driver modules, "8139cp" and
>> "8139too" as loaded.
>
> Module loading behavior changed a few years back; now you can modprobe
> devices that don't exist on the bus. This is supposed to make
> hotplugging easier, but it removes a semi-useful diagnostic tool.
>
>> 00:09.0 Ethernet controller: Realtek Semiconductor Co., Ltd.
>> RTL-8139/8139C/8139C+ (rev 10)
>> Subsystem: Realtek Semiconductor Co., Ltd. RT8139
>> Flags: bus master, medium devsel, latency 64, IRQ 10
>
> It has an IRQ, that's good. Are there 7 or 8 other devices trying to
> use the same IRQ? If so, enabling APIC may help.

Hi,

many thanks for your reply ! I did some investigation on apic - here is what
I have found:

These three devices share IRQ 10 with the RTL-8139

0000:00:06.0 Communication controller: Ambient Technologies Inc HaM
controllerless modem (rev 02)
0000:00:0c.0 CardBus bridge: Texas Instruments PCI1420
0000:00:0c.1 CardBus bridge: Texas Instruments PCI1420

Tried to enable apic with "lapic" boot parameter, but it refused. (This is
Ubuntu live DVD boot with 2.6.17-10 kernel):

[17179569.184000] Kernel command line: BOOT_IMAGE=/casper/vmlinuz
file=/cdrom/preseed/ubuntu.seed boot=casper initrd=/casper/initrd.gz
ramdisk_size=1048576 lapic root=/dev/ram rw quiet splash --
[17179569.184000] Local APIC disabled by BIOS -- reenabling.
[17179569.184000] Could not enable APIC!
[17179569.184000] mapped APIC to ffffd000 (0120a000)

On the other hand, with kernel 2.4.27 the RTL-8139 works fine although apic
is not working there either. That kernel seems to be compiled with apic
enabled by default, and it fails to re-enable it with exactly the same
error messages as the other kernel above.

>> As I have mentioned, the problem seems to be exactly the same under
>> Ubuntu and Debian 4.0.
>
> I have seen *far* too many distro-supplied kernels have weird problems
> with perfectly ordinary hardware to trust them for much beyond getting
> the system installed. Getting a vanilla tarball onto this system and
> doing the make menuconfig shuffle might solve this problem.
>

Hmm ... my problem is that I only have this one machine and its 20 GB hard
drive. I think the best thing to do will be installing a 2.6.x kernel in
parallel on Debian 3.1 and do some more experiments before I give 4.0
another shot. By the way - is it technically possible to go from 3.1 to 4.0
via apt, once I have a working 2.6 kernel ?

Kind Regards,

Martin

Charles wrote:

> MadKraut wrote:
>> I have a problem getting the network controller...to work..
>> An attempt (!) to load the driver module "8139cp" and an
>> apparently successfull load of "8139too"...
>
> I, along with many others, also have a problem with 8139 network interface
> card. My notes say that it worked on my machine under the Breezy Badger
> version of
> Ubuntu, but not Dapper Drake (6.06). See the #48456 bug, "kubuntu 6.06
> LTS does not support Realtek 8139 network card" at
>
https://launchpad.net/distros/ubuntu....15/+bug/48456.
>
> My boot hangs at the modprobe of the 8139too module. It will not continue
> until
> I remove the network cable from the card. Of course, the card still
> doesn't
> work but at least the computer boots. (If I blacklist the 8139too module
> there is no hang - and no network.)
>
>> As I have mentioned, the problem seems to be exactly the same under
>> Ubuntu and Debian 4.0.
>
> You are probably running version 0.9.27 of the 8139too module. Perhaps
> the
> problem is fixed in version 0.9.28 which I think is current. Perhaps the
> 8139
> module maintainer, Jeff Garzik, is working on the problem. See line 134
> of http://lxr.linux.no/source/MAINTAINERS?v=2.6.18.
>
> --
> Chuck

Hi Chuck,

thanks for your reply ! My findings with Debian 4.0 were based on the latest
network installation image available a couple of days ago. So I guess I
will just have to wait ...

And yes, at least in the case of the version of Ubuntu that I have tried, it
is indeed the 0.9.27 version of the 8139too driver that shows this
behaviour. For Debian 4.0 I can not say, as I have wiped out everything on
my drive after aborting the 4.0 install in order to put 3.1 on. One of
these days I should get a proper partitioning scheme ... ;-)

Kind Regards,

Martin

MadKraut wrote:
> thanks for your reply ! My findings with Debian 4.0 were based on the latest
> network installation image available a couple of days ago. So I guess I
> will just have to wait ...

Yes, I think version 0.9.28 is just a few weeks old.

> And yes, at least in the case of the version of Ubuntu that I have tried, it
> is indeed the 0.9.27 version of the 8139too driver that shows this
> behaviour. For Debian 4.0 I can not say, as I have wiped out everything on
> my drive after aborting the 4.0 install in order to put 3.1 on. One of
> these days I should get a proper partitioning scheme ... ;-)

You've got plenty of room to play around. My Linux installation is on a pair of
old hard drive with a combined capacity of less than 4 gigabytes.

As an aside you might want to blacklist the 8139cp module in the
/etc/modprobe.d/blacklist file.

Also get a recent copy of the nictools-pci package. It contains the
rtl8139-diag program which might be helpful in diagnosing 8139 problems.

--
Chuck

On Tue, 02 Jan 2007 11:31:26 +0100, MadKraut staggered into the Black
Sun and said:
> Dances With Crows wrote:
>> MadKraut wrote:
>>> Debian 3.1, ("Sarge" with kernel 2.4.27) everything works like a
>>> charm straight away. [But on Ubuntu...]
>>> [17180006.036000] NETDEV WATCHDOG: eth0: transmit timed out
>>
>>> RTL-8139/8139C/8139C+ (rev 10)
>>> Flags: bus master, medium devsel, latency 64, IRQ 10
>> It has an IRQ, that's good. Are there 7 or 8 other devices trying to
>> use the same IRQ?
> These three devices share IRQ 10 with the RTL-8139
> 0000:00:06.0 Communication controller: Ambient Technologies Inc HaM
> controllerless modem (rev 02)
> 0000:00:0c.0 CardBus bridge: Texas Instruments PCI1420

This shouldn't be a problem. Just 3 devices on one ISA IRQ is fine; it
gets more dicy when there are 8.

> Tried to enable apic with "lapic" boot parameter, but it refused.

OK, you probably don't need APIC to fix this.

>> I have seen *far* too many distro-supplied kernels have weird
>> problems with perfectly ordinary hardware to trust them for much
>> beyond getting the system installed. Getting a vanilla tarball onto
>> this system and doing the make menuconfig shuffle might solve this
> Hmm ... my problem is that I only have this one machine and its 20 GB
> hard drive.

? Multiple kernels aren't a problem even on much smaller machines. Of
course, getting the tarball onto the machine may be difficult if the NIC
isn't working right. BTDT--yay for having another machine and a CD-RW.

> By the way - is it technically possible to go from 3.1 to 4.0 via apt,
> once I have a working 2.6 kernel ?

The kernel is (or should be) orthogonal to the userspace stuff. All you
should need to do is modify your /etc/apt/sources.list appropriately,
then apt-get dist-update && apt-get dist-upgrade .

--
I have had to deal with kangaroos, donkeys, cows, wild pigs
and some press leaks by former Vice President Cheney.
--MegaHAL, trained on ASR
Matt G|There is no Darkness in Eternity/But only Light too dim for us to see

Charles wrote:

> MadKraut wrote:
>> thanks for your reply ! My findings with Debian 4.0 were based on the
>> latest network installation image available a couple of days ago. So I
>> guess I will just have to wait ...
>
> Yes, I think version 0.9.28 is just a few weeks old.
>
>> And yes, at least in the case of the version of Ubuntu that I have tried,
>> it is indeed the 0.9.27 version of the 8139too driver that shows this
>> behaviour. For Debian 4.0 I can not say, as I have wiped out everything
>> on my drive after aborting the 4.0 install in order to put 3.1 on. One of
>> these days I should get a proper partitioning scheme ... ;-)
>
> You've got plenty of room to play around. My Linux installation is on a
> pair of old hard drive with a combined capacity of less than 4 gigabytes.
>
> As an aside you might want to blacklist the 8139cp module in the
> /etc/modprobe.d/blacklist file.
>
> Also get a recent copy of the nictools-pci package. It contains the
> rtl8139-diag program which might be helpful in diagnosing 8139 problems.
>
> --
> Chuck

Update: the RTL-8139 works after I did install kernel 2.6.8-2-386 (still
"stock"-image not "handmade"), and the driver version is still 0.9.27 (!).
Also, the "8139cp" module that is loaded in parallel to "8139too" does not
seem to cause any problem (both drivers get loaded, as they carry exactly
the same alias string "pci:v000010ECd00008139sv*sd*bc*sc*i*").

So it is neither generally 2.6.x related, nor can it be the driver -
something else in the function-packed 2.6.17-10 stock kernel must be in the
way, but I will never find out what.

As an aside (OT now): During my attempte to prevent the 8139cp module from
loading, I came across the blacklisting mechanism, but at the same time I
had to find out that there seems to be some problem with it in the
module-init-tools package (I have 3.2-pre1-2 installed). Introducing a file
"/etc/modprobe.d/blacklist" with entries of the form: "blacklist 8139cp" or
simply "8139" just caused these error messages during boot:

"modprobe: WARNING: /etc/modprobe.d/blacklist line 1: ignoring bad line
starting with blacklist"

or
"modprobe: WARNING: /etc/modprobe.d/blacklist line 1: ignoring bad line
starting with 8139cp"

Obviously modprobe processes the file during boot, but doesn't seem to know
what to do with its entries. The filename "blacklist" alone does not seem
to mean anthing to it, nor does the keyword "blacklist" have an effect. Is
this known to be broken, or am I doing something wrong ?

Regards,

Martin

MadKraut wrote:
> Update: the RTL-8139 works after I did install kernel 2.6.8-2-386 (still
> "stock"-image not "handmade"), and the driver version is still 0.9.27 (!).

> So it is neither generally 2.6.x related, nor can it be the driver -
> something else in the function-packed 2.6.17-10 stock kernel must be in the
> way, but I will never find out what.

My 2.6.15-23 and 2.6.15-27 kernels are affected but Ubuntu Breezy Badger which I
think used kernel 2.6.12 handled the 8139 okay. There's some nasty interaction
some place. Now I'm sorry that I gave away all my early Ubuntu disks.

> During my attempte to prevent the 8139cp module from
> loading, I came across the blacklisting mechanism, but at the same time I
> had to find out that there seems to be some problem with it...

> Obviously modprobe processes the file during boot, but doesn't seem to know
> what to do with its entries. The filename "blacklist" alone does not seem
> to mean anthing to it, nor does the keyword "blacklist" have an effect. Is
> this known to be broken, or am I doing something wrong ?

My blacklist is working. Here's part of my /etc/modprobe.d/blacklist file:

# This file lists those modules which we don't want to be loaded by
# alias expansion, usually so some other driver will be loaded for the
# device instead.
# Do not load these drivers.
blacklist i2c_sis5595
blacklist i2c_sis630
blacklist i2c_core
blacklist i2c_isa
blacklist sis5595
# blacklist 8139too
# Prevent the 8139cp driver from loading.
blacklist 8139cp
# Blacklist the IPV6 module.
blacklist ipv6

--
Chuck

Charles wrote:

> My blacklist is working. Here's part of my /etc/modprobe.d/blacklist
> file:
> ...
> blacklist 8139cp

That's exactly what have in there, but it gives me the error messages I have
copied in my earlier posting.

Which version of module-init-tools do you use ? Mine is "3.2-pre1-2"

Regards,

Martin

MadKraut wrote:
> That's exactly what have in there, but it gives me the error messages I have
> copied in my earlier posting.
> Which version of module-init-tools do you use ? Mine is "3.2-pre1-2"

I'm running the 3.2.2-1ubuntu7 version.
--
Chuck

In comp.os.linux.hardware MadKraut :
> Hi folks,

> I have a problem getting the network controller of my laptop (MEDION
> MD9580-F) to work with both, Ubuntu and the latest Debian 4.0. With Debian
> 3.1, ("Sarge" with kernel 2.4.27) everything works like a charm straight
> away.

I'd check if FC6 (http://fedora.redhat.com/) does a better job,
remember to run 'yum update' after installing.

However, I have to admit "MEDION" hardware seem an utter peace of
cheapo crap. I can't remember any real problems running Linux on
quality laptops from various vendors.

Good luck

--
Michael Heiming (X-PGP-Sig > GPG-Key ID: EDD27B94)
mail: echo zvpunry@urvzvat.qr | perl -pe 'y/a-z/n-za-m/'
#bofh excuse 121: halon system went off and killed the
operators.

Charles wrote:

> MadKraut wrote:
>> That's exactly what have in there, but it gives me the error messages I
>> have copied in my earlier posting.
>> Which version of module-init-tools do you use ? Mine is "3.2-pre1-2"
>
> I'm running the 3.2.2-1ubuntu7 version.
> --
> Chuck

Ah, mine seems to be the older version - so at least there is hope ..;-)

Kind Regards,

Martin