Greetings. I'm trying to get an opensolaris file server to work, which has been 
image-updated gradually from the 2008.05 original release to actual 101b. 
Somehow the network has stopped working (it worked perfectly before!) since I 
plugged 4 extra gigs of ECC ram on it (I assume it happened because of the 
shutdown and not because of the extra memory): it doesn't receive a proper 
lease via DHCP, nor does it work manually setting the network parameters. The 
ethernet frames are corrupted or incorrect. 

Hardware is a Dell T105 server with an Intel 82544GC pci gigabit ethernet card. 
Dual opteron, dual 500G disks on a mirror pool, and 6 GB DDR2 ECC ram. 
Integrated ethernet does not work (as reported in 
http://bugs.opensolaris.org/bugdatabase/view_bug.do?bug_id=6711032 , I have to 
leave it disabled ) and neither does my belkin rt73 usb wifi adapter (just 
plainly not supported), so I can't connect that machine to the network to try 
to image-upgrade. 

Things I've tried without success: 

- Booting a different image. Unfortunately I only keep two and neither does 
work. 

- Checking several different ethernet cables. 

- Connecting directly to the server with my laptop -instead of via a switch- 
and trying to serve it dhcp with dnsmasq (mdi is supported by both AFAIK, and 
I've ocasionally used that to install servers at work). 

- Unplumbing and plumbing. I've observed that unplumbing does not remove all 
instances of e1000g0: the ipv6 (autogenerated from its mac, I guess) remains 
up, and to remove it I have to do ifconfig e1000g0 inet6 unplumb. 

- Booting an ubuntu livecd. Both network interfaces (integrated broadcom 5722 
and intel) work perfectly, which discards a hardware problem as far as I can 
guess. The intel network card used to be problematic at my workplace in linux, 
sometimes reporting being up and running but not transmitting anything, but it 
might be my flakey work PC and its Asus motherboard, as from the moment I 
plugged into the opensolaris server has been working flawlessly for a month 
until now, and ubuntu liveCDs work as far as I tested (aptitude update, ping 
google, etc)). 

- Booting xvm kernel instead of the plain one (I intend to use that machine for 
virtualization). 

- Listening via wireshark while connected to the machine. I get several packets 
(I guess one per dhcp try) like this: 

0000  fe ca dd ba fe ca dd ba  fe ca dd ba fe ca dd ba   ........ ........
0010  fe ca dd ba fe ca dd ba  fe ca dd ba fe ca dd ba   ........ ........
0020  fe ca dd ba fe ca dd ba  fe ca dd ba fe ca dd ba   ........ ........
0030  fe ca dd ba fe ca dd ba  fe ca dd ba               ........ ....  

When assigning the IP manually (as in ifconfig e1000g0 192.168.0.10 netmask 
255.255.255.0 ) I get similar (but not identical) frames; I could grab them if 
useful.


Just in case it could be useful: 

- Server has a zone with a static IP (which obviously gives me an error while 
booting: iface 192.168..0.200 is not directly connected to 0.0.0.0 or something 
like that). 
- I had also problems with a different network interface (realtek gigabit 
based), which was plainly "cheepest pci I could find". It worked very bad, 
sometimes not receiving dhcp leases for a long time as well (but every now and 
then it worked!). In linux works perfectly. 
- I cannot try my cheapo PCI network cards as the server only accepts pci 2.2? 
cards (they don't fit in the socket, I believe it is voltage related). 

I just don't know what else could I do, save for reinstalling (in which case I 
might as well renounce to zfs and install plain debian on it, as both proper 
processor scaling, disk shutdown *and* network interfaces will work), or buying 
*another* pci ethernet card (which I might do). 


Any suggestions on what could I try? How to report properly the bug, if needed? 
Any additional information I could gather? Please help, I'm getting quite 
annoyed with this, I just can't seem to get opensolaris to work as I'd like... 

Thanks in advance. 

[email protected]



      

_______________________________________________
networking-discuss mailing list
[email protected]

Reply via email to