-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 Andy Stewart wrote:
HI gang,
I have another clue - I found a way to lockup the system *guaranteed* within about 3 minutes. Go to this URL and play this game. It is mouse only.
OK, here's more to the saga of the machine suffering from hard lockups. Here's what I tried, and in all cases, the system still locks up playing beer_golf (but I am getting really good at this game!). This is all based on suggestions from all of you - thank you!! 1) Turned off video 3D acceleration. No effect, so I turned it back on. 2) Connected the KB and mouse directly to system (no KVM), no effect, so now the KVM is back in the picture. 3) Turned off sound hardware in the BIOS - no effect, so I turned it back on. 4) Tried a different video card (and this one was PCI, the original video card is AGP) - same deal, no effect, put back the original. 5) Enabled PNP in the BIOS (that's still on 'cause I thought I should probably have had it on anyway). 6) Disabled network hardware in the BIOS, put in Linksys PCI NIC. Nope, so I pulled the Linksys and reenabled the MB NIC. 7) Tried a different PS/2 mouse and tried my original mouse on another system. All mice seem to work properly. 8) I tried to get a serial mouse to work, but I couldn't get the serial mouse to work. I can't set the baud rate down to 1200 on this MB. Weird...the lowest it will go is 9600 (verified with minicom). I might play with this again to see if I can isolate the PS/2 mouse hardware on the MB (and the software in Linux). I don't have a USB mouse and Staples didn't have any when I visited. Here is what else I did: 9) Ran memtest for 24 hours - no failures 10) Access the offending system from over the network and play the game - - no lockup! 11) The beer_golf game is a swf file, so I downloaded the file and played it locally - no lockup! 12) Only when I play beer_golf in konqueror, over the net, does the system lockup reliably. 13) CPU temps measured independently from the MB are in the low 40 degree C range. Now, with regard to the serial console, I did get that working at least to a certain point. I've connected the serial cable to another Linux system running minicom. I can see the boot and shutdown messages in two locations (minicom/remote and local). However, when the system is running, I don't see the kernel messages on the serial console. When booting from grub, I have "console=tty0 console=ttyS1,115200n8" in that order. I do see the kernel messages in /var/log/messages and in the xconsole window. - From minicom, if I sent the Break character when the system is running OK (before the lockup occurs), that acts like Alt-SysReq. So, Break-? gives me the SysRq help line. Break-T (show tasks) puts output only on the local system (can't see it on minicom). I am not running getty on this ttyS1 since it seems to interfere with my attempts to use the MagicSysReq key. When it was enabled, I did get successfully logged in. When I put the system at run level 1, then all of the Alt-SysReq output goes to the serial console (minicom can see them!). Now, here's the part that I think might be bad. When I run the program which makes the system lock up, the lockup occurs. I then try to use minicom, and I get no output whatsoever. I can't even get the SysRq help output. I fear this may mean I have a real hardware lockup and not a Linux kernel problem. I know this is a lot to digest, and I really do appreciate all of the feedback. Does anybody have any comments that might help to further isolate this problem? Is there anything that I should try which I have not tried? Thanks!! Andy - -- Andy Stewart, Founder Worcester Linux Users' Group Worcester, MA, USA http://www.wlug.org -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.2.5 (GNU/Linux) Comment: Using GnuPG with Thunderbird - http://enigmail.mozdev.org iD8DBQFCtPa7Hl0iXDssISsRAuZaAJ4mTMd8eSJEPo5LCCiqA8/rqazAQQCfSYmb mHIxlOPglV7Cq42hNKejVxU= =GJzk -----END PGP SIGNATURE-----