[SOLVED] No wired eth0 - Intel PRO 100 - 4.0.2

[secdroid]

Never had network problems with previous TC version, but I'm not sure what I'm doing wrong.

DLd 4.0.2 multicore today, checked MD5, burned CD at minimum speed.  Booted TC Plus (no args).

Hardware is Celeron 450 single core 2.2 GHz, 4 GB RAM, Intel PRO 10/100 NIC, wired.  Dell Inspiron 530.  (First time using TC with 4 GB RAM, but I don't think it should matter to net.)

Used Control Panel/Network to try for DHCP.  No joy.  Set manual inet 192.168.1.101, nmask 255.255.255.0, bcast 192.168.1.255, gway 192.168.1.1, ns1 8.8.8.8, ns2 8.8.4.4, just as I do with Arch on the same box.  Couldn't ping other boxes on LAN.

Checked "ifconfig eth0" and it looked fine.  Did "dmesg | grep -i net" and noticed no issues.

What did I miss?

[bmarkus]

DLd 4.0.2 multicore today, checked MD5, burned CD at minimum speed.  Booted TC Plus (no args).

Most likely not related to your issue, but burning at minimum speed is increasing risk. Better to use half of max.

[Rich]

Hi secdroid
Anything interesting pop up from   dmesg | grep -i eth0

[secdroid]

Hi secdroid
Anything interesting pop up from   dmesg | grep -i eth0

Should have thought of that...   

"dmesg | grep -i eth0" before trying to start the net IF:

Code: [Select]

e1000e 0000:00:19.0: eth0: (PCI Express:2.5GT/s:Width x1) 00:21:9b:22:40:a8
e1000e 0000:00:19.0: eth0: Intel(R) PRO/10/100 Network Connection
e1000e 0000:00:19.0: eth0: MAC: 7, PHY: 7, PBA No: FFFFFF-0FF

No change to dmesg after trying to start net via DHCP.  Result of "ifconfig eth0" showed DHCP failed to config.

No change to dmesg after trying to start net via manual config.  Result of "ifconfig eth0" (after manual net config)

Code: [Select]

eth0      Link encap:Ethernet  HWaddr 00:21:9B:22:40:A8 
          inet addr:192.168.1.101  Bcast:192.168.1.255  Mask:255.255.255.0
          UP BROADCAST MULTICAST  MTU:1500  Metric:1
          RX packets:0 errors:0 dropped:0 overruns:0 frame:0
          TX packets:0 errors:0 dropped:0 overruns:0 carrier:0
          collisions:0 txqueuelen:1000
          RX bytes:0 (0.0 B)  TX bytes:0 (0.0 B)
          Interrupt:20 Memory:fdfc0000-fdfe0000
Note: It would appeared that this network IF is indeed memory-mapped.  Any chance that TC can not handle 4GB of RAM?  Did I miss some required boot code?

[gerald_clark]

I do not believe TC has a PAE kernel.
If that is the case 4G RAM may be a problem.
Can you pop out 2G for testing?

[secdroid]

I do not believe TC has a PAE kernel.
If that is the case 4G RAM may be a problem.
Can you pop out 2G for testing?

Confirmed.

Tiny Core 4.0.2 will boot from CD but can't connect (with this network IF) to the net with 4 GB RAM.  Booted with 2 GB RAM, connected to the net with DHCP auto-config, and posted this via TC and Dillo 3.

Very disappointing.  The only machine I have with an optical disk is the one that I would like to equip with 4 GB RAM.  I guess I will have to keep a working TC USB key and do my TC USB maintenance on another machine with out using an optical drive.  And I won't be able to use TC for a troubleshooting distro on the 4 GB/optical drive machine without pulling 2 GB of RAM.

Thanks, Gerald.

[gerald_clark]

Perhaps the 64bit kernel will work.

[Rich]

Hi secdroid
If you don't want to pull the RAM, maybe this boot code can help:

Code: [Select]

max_addr=nn[KMG]    [KNL,BOOT,ia64] All physical memory greater
                    than or equal to this physical address is ignored.For example:
max_addr=2G

You could also check the first couple of pages of dmesg and see if the kernel printed any
messages about the amount of RAM installed.

[secdroid]

Perhaps the 64bit kernel will work.

Worth a shot --- http://wiki.tinycorelinux.net/wiki:microcore64_kiss_install_guide

However, I believe that there is an error in the wiki.  Page http://wiki.tinycorelinux.net/wiki:32_or_64_bit suggests  an inaccurate method of determining whether a CPU is 32 or 64 bit.  According to http://compute.cnr.berkeley.edu/cgi-bin/man-cgi?uname+1 the "uname -m" arg is deprecated.  It results in

Code: [Select]

[usr@myhost ~]$ uname -m
i686
It is best to use "uname -p" and then go to the manufacturers info.  In my case, "uname -p" gives

Code: [Select]

[usr@myhost ~]$ uname -p
Intel(R) Celeron(R) CPU 450 @ 2.20GHzGoogling the CPU and going to http://ark.intel.com/products/35239/Intel-Celeron-Processor-450-(512K-Cache-2_20-GHz-800-MHz-FSB) indicates that the CPU is capable of 64 bit addressing.



I did not check to see if the successfully booted (via CD) Live TC instance actually required working networking to create a USB install instance.  (May well not be necessary to have working networking.  Force of habit -- I always check out the TC Live instance thoroughly, including networking,  before installing to USB.)

[secdroid]

Hi secdroid
If you don't want to pull the RAM, maybe this boot code can help:

Code: [Select]

max_addr=nn[KMG]    [KNL,BOOT,ia64] All physical memory greater
                    than or equal to this physical address is ignored.For example:
max_addr=2G

You could also check the first couple of pages of dmesg and see if the kernel printed any
messages about the amount of RAM installed.

Interesting idea, Rich.  I searched through the TC boot codes, but did not think to look at the kernel boot codes.  I found the same info you cited at http://www.kernel.org/doc/Documentation/kernel-parameters.txt

I don't have the full TC DMESG handy (on Arch now), but I know I am running a 32 bit arch and one interesting thing from DMESG --

Code: [Select]

[usr@myhost ~]$ dmesg | grep -i pae
[    0.000000] Notice: NX (Execute Disable) protection cannot be enabled: non-PAE kernel!

So, 32 bit Arch non-PAE kernel and 32 bit Windows Vista (Yuck!!!) running 4 GB RAM can properly memory map the Intel NIC on this hardware, while TC can not.

Therefore, I don't believe that a PAE kernel is required, as long as one is willing to give up a bit of top RAM so that memory mapped IO can work as normal.  It would appear that a 32 bit kernel on TC could do the same.

I'll try out the max_addr kernel args tomorrow and report back.  If they solve the problem, perhaps they could be incorporated in the 32 bit default kernel args because memory spaces > 3 GB are becoming increasingly common.  Failing that, perhaps there could be a wiki page.

[Rich]

Hi secdroid
If that works, you could try upping it to
max_addr=4000M
That should leave 96Meg for mapping the NIC and other peripherals.

[maro]

As a side note: IIRC the "proper" way of checking whether it's a 64-bit CPU is to look for the 'lm' CPU flag (which indicates "long mode"), e.g. via
    grep -q '^flags[[:blank:]]*:.* lm ' /proc/cpuinfo && echo 64 || echo 32

[Rich]

Hi maro
I think you meant to type  /proc/cpuinfo  not  /proc/cpu
I don't have any 64 bit hardware to check how trustworthy it is, but  cpuinfo  contains an
address sizes  field.

[curaga]

There should be no general issues with lots of ram. I believe you're either seeing a bios or kernel bug.

[maro]

Thanks Rich, I hate it when I introduce a typo where I should have used 'copy-paste' instead.