Tiny Core Linux
Tiny Core Base => TCB Q&A Forum => Topic started by: secdroid on October 13, 2011, 02:17:13 PM
-
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?
-
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.
-
Hi secdroid
Anything interesting pop up from dmesg | grep -i eth0
-
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:
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)
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?
-
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?
-
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.
-
Perhaps the 64bit kernel will work.
-
Hi secdroid
If you don't want to pull the RAM, maybe this boot code can help:
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.
-
Perhaps the 64bit kernel will work.
Worth a shot --- http://wiki.tinycorelinux.net/wiki:microcore64_kiss_install_guide (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 (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 (http://compute.cnr.berkeley.edu/cgi-bin/man-cgi?uname+1) the "uname -m" arg is deprecated. It results in [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 [usr@myhost ~]$ uname -p
Intel(R) Celeron(R) CPU 450 @ 2.20GHz
Googling the CPU and going to http://ark.intel.com/products/35239/Intel-Celeron-Processor-450-(512K-Cache-2_20-GHz-800-MHz-FSB) (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.)
-
Hi secdroid
If you don't want to pull the RAM, maybe this boot code can help:
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 (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 --
[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.
-
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.
-
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
-
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.
-
There should be no general issues with lots of ram. I believe you're either seeing a bios or kernel bug.
-
Thanks Rich, I hate it when I introduce a typo where I should have used 'copy-paste' instead.
-
Got some data. Saved dmesg output prior to network start on four configs:
- TC plus with 2GB RAM
- TC plus with 4GB RAM
- TC plus with 4GB RAM and boot parm max_addr=2G
- TC plus with 4GB RAM and boot parm max_addr=4000M
Results:- 4GB RAM - booting TC plus from CD with max_addr=2G --- networking is OK
- 4GB RAM - booting TC plus from CD with max_addr=4000M --- networking is inoperative
So, the "max_addr=2G" parm is a great workaround that solves my problem. Thanks, Rich.
If anyone is interested, I'd be happy to work with them on analyzing the dmesg output and/or determining a higher working upper memory bound.
There should be no general issues with lots of ram. I believe you're either seeing a bios or kernel bug.
I am a bit curious why a 32 bit non-PAE TC kernel would be affected by a BIOS bug while a 32 bit non-PAE Arch Linux kernel would not.