John, For me, seg. fault immediately implies hardware problem (at least with otherwise proven software). See below for more comments...
> From: John Karns <[EMAIL PROTECTED]> > Subject: Re: [Ltsp-discuss] segmentation fault > > On Sun, 7 Jul 2002, [EMAIL PROTECTED] said: >> Hi John, >> from my experience I had seg faults for different reasons. >> Hardware related: >> One was bad ram, the other a bad mobo (on our ltsp-machines). >> I also had seg faults on my personal machine for different (software related). >> Check if it's defietely not a hardware prob. >> (This is from the view of a "non"-programmer :) - perhaps there's two >> different kinds of seg-faults) >> regards, > > Yes, I hadn't really thought of it from that angle, as the machine is new; > but you're right - could be bad RAM or whatever. In any case a somewhat > strange problem. I had given thought to hardware in a different sense > though, as I swapped the hub and NIC. What doesn't make sense though is > that after a successful boot, all runs fine; the client inits to xdm then > I can run KDE with no problems at all, so that would seem to rule out > hardware. No, it doesn't. The thing about hardware errors is that they are often random and unpredictable. That the boot itself was successful tells you that whatever normally is flaky in the machine is running fine, at least for the moment. My first presumption would be hardware problem, especially with seg faults. > One other thing I should have mentioned is that a similar problem happens > earlier in the boot process the first time the DHCP server is contacted, > *before* the kernel is DL'd via tftp. About 4 instances of the message > "ALERT: got a fragmented packet - reconfigure your server". The msg comes > from etherboot (5.0.6) main.c, just after line 1033 with the comment: > > Till Straumann <[EMAIL PROTECTED]> > added udp checksum (safer on a wireless link) > added fragmentation check: I had a corrupted image > in memory due to fragmented TFTP packets - took me > 3 days to find the cause for this :-( > > So I was pretty sure that the the dhcp server or client was at fault, so I > updated the dhcp components. Yes, you should've mentioned this. This changes everything. This points at the problem being with the networking, which is still hardware, but not necessarily client hardware. A good test to firm up this assumption would be whether other clients also experience problems like this. If not, then the problem is with your client and could be your NIC, the network cable, the hub port, or even still something to do with RAM/mobo. If other clients are having this problem, then it is either network in general (hub, switch, cabling) or the networking to your DHCP server (cable, NIC, port on the hub/switch). As for the Etherboot code comment, it says to me that Herr Straumann is responsible for adding the code to check for fragmentation, which kindly reported to you the reason for which you may be experiencing problems. It indeed sounds like you have a networking problem somewhere. My only confusion lies in that you say these messages occur before the TFTP download begins, yet the comment in the code seems to discuss TFTP packets... I haven't looked at the code, but it could just be that Herr Straumann had a problem with his TFTP packets, but wound up adding checksum and fragmentation checking for other stages of the boot process as well. Jason PS: In reference to your original post, there is no grounds to suspect any binary incompatibility between your DHCP server's system and the LTSP clients. The DHCPD server is compiled and run on your server. The DHCP client code is run on the client hardware. LTSP ships with an entire set of its own libs now for the client and takes nothing from the server. This precludes anything like what you were considering. As long as the two binaries speak the same language over the network they should behave well regardless of what libraries they are compiled against and even what architecture they run on! Your server could be an Alpha or PPC or Sparc architecture and the client i386-compatible. ------------------------------------------------------- This sf.net email is sponsored by:ThinkGeek We have stuff for geeks like you. http://thinkgeek.com/sf _____________________________________________________________________ Ltsp-discuss mailing list. To un-subscribe, or change prefs, goto: https://lists.sourceforge.net/lists/listinfo/ltsp-discuss For additional LTSP help, try #ltsp channel on irc.openprojects.net
