Bad Ethernet card causing problems?

[bobbyc]

Hi, we attempted to light up our newest tower yesterday, but half the time it would mess up during the bootup and then it would ask for username, and when it would ask for password it would either report it as wrong passwd or just ask for the username again. So today I brought up a different hard drive, and I ran into a different problem. When it got to the bottom of the boot up sequence, it would just sit at activating PCMCIA cards... or it would only detect a few of the cards and not all 4. I tried different card orders, different bios settings, always the same result.
Both hard drives work just fine here at my house with my test star-os server, and it is all the same hardware (asus tusl2-c) celeron processors, orinoco pcmcia-pci adapters. The difference is the vga pci card and the ethernet pci cards. But get this...
When I was setting up this towers' system at my office last weekend, the network card in question was acting flakey. I could ping it but couldn't SSH into it. I swapped network cards, and it worked. I then put back in the network card in question, restarted my XP machine, and it then worked. So I figured that was it. Maybe not however.
So, is it possible? Ever heard of this behavior before? I'll find out monday when I go up there and swap out network cards for the last network card I have a key for.
I can log into the tower right now, but I am afraid to reboot it since it might not come back up. I sat there at the hilltop for a couple minutes and it would be stuck at the activating PCMCIA cards, so I turned off and back on and it started up so I left it alone and went home because it was getting dark.
Thanks, Bob C
Oh yeah I think it is a AOPEN skinny network card, wish I knew what chipset was on it for you guys.

[bobbyc]

Well while both hard drives work fine here on my test star-OS server, One I have to set as LARGE in the BIOS(the 512mb one that is up there right now giving me the pcmcia activation problems) in order to boot up.

[tony]

We have seen this issue in the past, and all the cases it was caused by the RAM needing replacement in the system. Pop a few new SDRAM sticks in and see if the problem clears up.

Thanks!

[bobbyc]

I replaced the (2) 64 rams that were in it with a different brand (1) 64mb module while I was up there.
I'll bring another one up monday and try that before I swap out the network cards, and if neither work I'll be swapping out the pcmcia adapters and vga.
I'm just glad to know it isn't a HD issue, since they work fine here.
Bob C

[bobbyc]

Just an update.
I went up there with new ram, new ethernet card in hand. When I got up there, i shut it down, replaced the ram, and hooked up monitor/keyboard/mouse. started up and it didn't even boot. I put in old ram and it still didn't boot. I left in old ram and switched card orders.
It worked. I restared 7 times while I was there and everything activated beautifully. I am assuming the card order was the problem. We ran into this before with freeBSD machines and the lucent pcmcia-->pci adapters we use. Sometimes you just have to swap around the pci cards until it worked and you didn't get any timeouts. And no it wasn't IRQ conflicts.
I'm going to update the firmware remotely tonight, and if it doesn't start back up when I restart it, I'll be suspicious of the network card or ram again...
Bob C
BTW, why is it that this cpu, along with another of ours, takes forever to ask for the psswd when you log into them remotely? What should we be looking into as being the culprit? Ram, HD???? I do think these towers both have older/crappier hard drives. Would this possibly effect customers?

[georgew]

The PCI subsystem has addressable slots, and during boot the PCI controller assigns interrupts to cards in sequence. I have seen cases where ordering the cards impacts things in an undesirable manner... I have also seen PCI controllers that seem to assign Interrupts randomly, such that they come up different each time, causing some cards to work then not work the next boot. When this happens you have to either update the bios, or go into the cmos settings and pre-assign io values to cards that are causing the problem. Updating the bios usually clears up most problems.... when other methods fail...


George

[tony]

why is it that this cpu, along with another of ours, takes forever to ask for the psswd when you log into them remotely?

This is caused by a DNS timeout looking up the IP you logged in with. If you enter it in your DNS server (the one the StarOS system is pointing too), the login delay will go away. The login delay will also go away if you remove the DNS entries, or leave it at the default 127.0.0.1

[bobbyc]

Thanks tony, that did the trick.
I love this forum.
Bob C