Steam does not have a clue..i was hoping for a long shot that somebody could shed some light on what is going on.

Jason Dixon wrote:

On Jan 25, 2005, at 8:42 PM, William Warren wrote:

...

What is frustrating is that it runs fine after i reformat the box for about a month then it dies.

Reposting this information 30 minutes later doesn't make it any more relevant. I'm not sure why you're asking the CentOS list instead of a Steam forum.

-- Jason Dixon DixonGroup Consulting http://www.dixongroup.net

---

CentOS mailing list CentOS@caosity.org http://lists.caosity.org/mailman/listinfo/centos

Michael Best wrote:

A reformat reinstall is nothing more than erasing the disk and starting over, give or take some log files.

*) Erase all files associated with the application and reinstall, test *) swap space is being corrupted? turn off swap make swap with the check for bad blocks option, turn swap back on *) Run harddrive diagnostics perhaps the harddrives are going bad *) Run memtest+, if you can do this as an overnight burn in *) Perhaps Steam is the problem, who knows?

First off, I'd set up a way to recover the system from a time before it stopped working correctly. Mirroring the files to another disk is probably the fastest way, then you could just boot off KNOPPIX and rsync the backup files over what's there. If you were running from within VMware, you could just schedule snapshots and revert to a previous snapshot of the system when it was working properly. Restoring from tape is too slow and a pain to do, not something you want to get stuck doing every couple weeks, much easier and faster to just rsync off an extra disk or another computer.

If possible, I would repartition the system with two "root" partitions called "/" and "/r2" and "/r2" would just be an rsync backup of "/". You would set up LILO or GRUB entries to be able to boot off /r2, plus you need to modify /r2/etc/fstab since the root partition is different to "run" on that copy. Say for example you sync / -> /r2 daily, and the day the app stops working, you just reboot the system into /r2 and the system is probably working again, then sync /r2 -> /. I have used this approach a lot so that I could install a newer OS on /r2 but leave the old OS on / in case there was a problem getting any custom applications to work I could just reboot to the old OS and it's no problem. Some people have complained that it "wastes disk space" so lately I split the OS into "/" and "/usr/share" then when I want to install a newer OS I move /usr/share to a loop filesystem on /home for example and the /usr/share partition becomes /r2. It's a bit more complicated but it works.

Offhand, I'd burn a stresslinux CD and try memtest86 and the appropriate versions of cpuburn to see if anything weird happens:

http://www.stresslinux.org/

Then still running off the CD, I'd try the "mkswap -c" and "e2fsck -c -f" on all of the filesystems, assuming you're using ext2 or ext3 filesystem--usual disclaimer to BACK UP your system and so on. Maybe Steam is getting its data out of the "wrong place" w.r.t. the Linux kernel like reading from fs buffers that may be out of sync as happened with "dump" but that is just a wild guess because I deleted the original message and have no idea what Steam is. What follows is just some general advice to come up with a plan of attack and brainstorming ideas.

I'd avoid having any part of Steam rely on files on an NFS filesystem, if that is your setup that would be my #1 suspect. If Steam uses any databases, you might want to run any tools to optimize / fix the tables periodically.

Try to break down the problem into "layers" analogous to the OSI layers of what is processing the data where, and then check out the problem at each "layer" just roughly something like:

application libraries database kernel filesystem hardware network

Those might not be in the "right" order but could give you some ideas. The goal is to try to isolate and identify what "layer" the problem is occurring at. I have solved problems where the cause of the problem was unexpected, like ypbind losing its connection to the NIS server which seemed like it shouldn't have affected the application but did for some reason, like the application used certain system calls that ended up tying into NIS.

--jonathan

This is a freshly reloaded system with a new hdd..full repartition and format:

./hlds_run: line 423: 4844 Segmentation fault (core dumped) $HL_CMD Cannot access memory at address 0xb75fe700 Cannot access memory at address 0xbfffebb0 debug.cmds:3: Error in sourced command file: Cannot access memory at address 0xb75fe700 email debug.log to linux@valvesoftware.com Wed Jan 26 21:24:48 EST 2005: Server restart ------------------------------------------------------------------- ---------------------------------------------- CRASH: Wed Jan 26 21:24:48 EST 2005 Start Line: ./hlds_i686 -game cstrike -debug +port 27015 +maxplayers 11 -autoupdate +map cs_tiki -steamuser *** -steampass *** -pidfile hlds.4830.pid Using host libthread_db library "/lib/tls/libthread_db.so.1". Core was generated by `./hlds_i686 -game cstrike -debug +port 27015 +maxplayers 11 -autoupdate +map cs'. Program terminated with signal 11, Segmentation fault. #0 0xb3a9baab in ?? () #0 0xb3a9baab in ?? () No symbol table info available. End of crash report ----------------------------------------------

This is most assuredly an aplication error right? I have stressed the system and no errors(except the OS hdd which was replaced).

William Warren wrote:

Ok i swapped out the boot hard disk. One of the hdd diags i ran always hit a one second pause during testing at the same spot everytime but never threw an error. hopefully this fixes things.

cs 1.6. here is a link to the debug entry:

http://forums.steampowered.com/forums/showthread.php?s=&postid=2160742#p...

Mike Kercher wrote:

William Warren wrote:

...

This is a freshly reloaded system with a new hdd..full repartition and format:

./hlds_run: line 423: 4844 Segmentation fault (core dumped) $HL_CMD Cannot access memory at address 0xb75fe700 Cannot access memory at address 0xbfffebb0 debug.cmds:3: Error in sourced command file: Cannot access memory at address 0xb75fe700 email debug.log to linux@valvesoftware.com Wed Jan 26 21:24:48 EST 2005: Server restart

Is this CSS or 1.6? What does your debug.log show? I use to run some HLDS problems, but didn't have any major problems with 1.5/1.6 The real problems started with CSS

Mike

---

CentOS mailing list CentOS@caosity.org http://lists.caosity.org/mailman/listinfo/centos .

Mike Kercher wrote:

William Warren wrote:

...

Can anyone tell me what is causing htis by chance? I know it is the

<9,000+ lines snipped>

What is the actual commandline you are using to start hlds? Are you running any plugins such as AMX, metamod, etc?

come on people, a grip here wouldn't hurt....but copying how ever many lines to add 21 words?

that is worse than me sending this email...

Mike Kercher wrote: here is the startup argument i am using:

screen -A -m -d -S hlds ./hlds_run -game cstrike -debug +ip 192.168.0.201 +port 27015 +maxplayers 11 -autoupdate +map cs_tiki -steamuser **** -steampass ****

I ma using the latest metamod and adminmod. However i ahve another athlon xp system running fedora with this setup and it runs fine. I am going to try that stress test cd and see what comes up.

What is the actual commandline you are using to start hlds? Are you running any plugins such as AMX, metamod, etc?

Mike

---

CentOS mailing list CentOS@caosity.org http://lists.caosity.org/mailman/listinfo/centos .