Yeah, I know what you mean about people pleading for help then ignoring the help they receive. This should be a cardinal sin, but well, let me tell you alittle about the principle of Buddha (yeah I've factored him down too): Now here is a holy figure that indulges in many vices, we give him money in a pot, he has a pot belly and he's bald.
How is it that this can be a suitable idol for worship I wondered, when I began one day thinking about the prohibition. Here we have a time in western history that practiced the abolition of alcohol: by virtue that alcohol was an evil to man and was unsuitable for his society. So a curfew was imposed and as surely as a leak in a dam will eventually erupt, so too did the prohibition finally desist for virtue of tolerance and better judgement. And so, this Buddha fellow is a testament to the principle that man should ultimately be given the experience of something before he decides if it is right or wrong.
Even the smallest of weights across a (proportional) expanse of space can counterbalance the mightiest of Titans. --me (As long as you have your proportions right, you're laughing ...)
But yeah, maybe your suggestion stayed with my subconscious mind for I finally decided to change cables and b-i-n-g-o: I was given the green light. But if you pardon my address: there was a more pressing matter that required my attention: that of the init sequencing in conjunction with mounting the PCMCIA services. There is a flaw here, for the init process does not allow for the PCMCIA latency. I believe this init/PCMCIA problem should be addressed in Bering-uClibc.
From: Ray Olszewski <[EMAIL PROTECTED]> To: [EMAIL PROTECTED] Subject: Re: [leaf-user] Almost there ... Date: Sat, 21 Feb 2004 20:29:05 -0800
At 03:00 AM 2/22/2004 +0000, joah moat wrote:Okay, I have made some more progress with my Bering-uClibc2.1rc2 on notebook:
I made an error in my report this morning: lsmod does return the use of pcnet_cs.o module. (Darn, go figure I should prompt lsmod when the pcmcia services are still initializing.) But yeah, all the modules are there, and furthermore:
ping 192.168.1.254 returns an average of .1 ms (so hooray I am getting a ping to my eth1). Futhermore, I was not connecting my cat-5 to a hub, I was connecting it directly to my PC network card, hence it was male to male (yuck). I decided to use a cross-over cable and lo and behold, there appeared a bright green led on my eth1.
You know, I looked back over the threads involving your connection. I note that in your FIRST message, you said:
>My windows box cannot auto detect ip address from LEAF router, green light
>on my (PCMCIA) eth1 is off.
The FIRST sentence of my response to this was:
"This sounds like it could be a hardware problem ... with the NIC, the cable
to it, or the hub or switch it connects to."
I find it discouraging when people ask for help, then ignore the help they get. But maybe I'm just in a bad mood tonight.
But still, using this cross-over cable connection, I am still not able to ping from PC to router.
Okay, now I guess I need to provide you with some info. But before I continue, is it possible to establish a connection with a cross-over cable, or do I require a network hub? (my-oh-my the intricacies.)
In principle it is possible to establish a connection with a crossover cable; I've done it often (though never with the specific NIC you have). But one problem I have seen some NICs run into is determining the speed of the connection (100 Mbps vs 10 Mbps). NICs connected to hubs and switches handle this fine, but when the connection is NIC to NIC, sometimes they cannot manage to agree on a speed. The dmesg output you quoted at the end of your report, namely ...
eth1: NE2000 (DL10022 rev 30): io 0x300, irq 5, hw_addr 00:05:5D:37:7F:65 eth1: found link beat eth1: link partner did not autonegotiate eth1: lost link beat :( eth1: found link beat :) eth1: link partner did not autonegotiate eth1: lost link beat :(
... suggests to me that you are having this problem. The *usual* symptom of this problem is that both ends falls back to 10 Mbps, not that they fail to communicate at all. But since I'm not familiar with the D-Link NIC on the LEAF end, and you haven't said what NIC is at the far end, I suppose you might be seeing a different symptom.
So even if you hope eventually to do a direct connection between the two hosts, I would suggest borrow a hub (or buy one; at least in the US, small ones are dirt cheap) and use it when testing.
If using a hub deals with the problem then it is a hardware limitation of one or the other of the NICs. Not really a problem for a Linux list, but if you now tell us the NIC at the other end, I suppose someone might have a bright idea. FOr example, the order in which you do things (boot the two machines and actually connect the NICs) might matter to the outcome.
[details deleted]
------------------------------------------------------- SF.Net is sponsored by: Speed Start Your Linux Apps Now. Build and deploy apps & Web services for Linux with a free DVD software kit from IBM. Click Now! http://ads.osdn.com/?ad_id=1356&alloc_id=3438&op=click ------------------------------------------------------------------------ leaf-user mailing list: [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/leaf-user SR FAQ: http://leaf-project.org/pub/doc/docmanager/docid_1891.html
_________________________________________________________________
Say “good-bye” to spam, viruses and pop-ups with MSN Premium -- free trial offer! http://click.atdmt.com/AVE/go/onm00200359ave/direct/01/
------------------------------------------------------- SF.Net is sponsored by: Speed Start Your Linux Apps Now. Build and deploy apps & Web services for Linux with a free DVD software kit from IBM. Click Now! http://ads.osdn.com/?ad_id=1356&alloc_id=3438&op=click ------------------------------------------------------------------------ leaf-user mailing list: [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/leaf-user SR FAQ: http://leaf-project.org/pub/doc/docmanager/docid_1891.html
