Debug system freeze

arp242

arp242

I've had this issue for a while, at least since FreeBSD 8.2, but not on some earlier version (Don't remember exactly, 8.0, 8.1, or some 8-STABLE), I upgraded to 9-BETA3 yesterday and the issue persists.

Mplayer works great, putting my laptop to sleep (Using zzz) and waking up also works great, but starting Mplayer after I've put my laptop to sleep causes a complete system freeze. Always. I see the Mplayer window (No video) for a second, and then nothing. Only resolution is to force the power off.

If I exit X, and fire it up again, it does work. Seems some sort of X/dri/Intel driver issue (?) ... Note this also occurs with vlc, not just Mplayer. Didn't try other video programs.

Now, this is of course really the stuff for a PR/bug report. My question is:
how does one get more information about a complete system freeze.

This is not something I can readily find information about, and such info might be useful in a PR ;)

Thanks.
 
If you run freecolor (i386) before starting vlc or mplayer and it fixes it, it may be a "stuck memory" problem. (Slight chance..., I know.) Sorry to not also answer the main question.
 
The system runs fine for days and even weeks. The issue *only* occurs with video playback.
 
Carpetsmoker,

just to get things right... mplayer runs fine all the time but is causing trouble when being run after resuming the system? Only mplayer or are there other applications causing same symptoms?

livelocks are rare conditions but from my experience, when running X.Org a thing can happen often that is looking very similar to a livelock for an end user.

The next time the "lock" happens, can you please check if blindly pressing the keys ''res'' and "Enter" does something?

If my imagination is right, you may run into a kernel panic situation but unfortunately as you're running X.Org you don't see it. You should see a frozen X screen. Pressing "res" gives the kernel debugger (even while you don't see it on screen, it's there and waiting for your commands) the instruction to reset the machine and restart the OS. Be aware you may loose data that is not yet saved to disk if you do this but as you're already in a panic situation, you're lost at all.

I'm wondering if you can please confirm that.

Other than that, you may want to switch to the console screen vt0 or vt1 and start mplayer from there (setting the appropriate DISPLAY before). That way, you should actually see the panic message.

Depending on available hardware, the next best option is to setup a firewire connection or a serial console.
 
Thank you for your hints!

After my update to FreeBSD 9, I'm sure suspend worked at least one or twice, but was unable to get it working *at all* after that. On resume it would just short VT0 with no output at all. (Even on a fresh start, with no X).

Yesterday I recompiled my kernel, I disabled the debugging features, and disabled all drivers I didn't need/wanted (Such as firewire, USB, etc). And that "solved" the problem! I need to investigate this later, but first back to the original problem!

just to get things right... mplayer runs fine all the time but is causing trouble when being run after resuming the system? Only mplayer or are there other applications causing same symptoms?
Click to expand...

Yes, mplayer works fine. After the resume, everything works fine (I've had the system suspend/resume for days, w/o any other problems).
If I restart X, I can run mplayer without problems.
Note that VLC also exhibits the same behavior!

The next time the "lock" happens, can you please check if blindly pressing the keys ''res'' and "Enter" does something?
Click to expand...

That doesn't seem to do anything.

Other than that, you may want to switch to the console screen vt0 or vt1 and start mplayer from there (setting the appropriate DISPLAY before). That way, you should actually see the panic message.
Click to expand...

Mplayer works fine as long as I don't switch to the X VT. I can hear sound (But obviously no video). When I switch to X it shows the black mplayer window, and crashes in the same method.

One thing that is different in FreeBSD 9 v.s. FreeBSD 8 is that I can still move my cursor -- It doesn't do anything, and the cursor doesn't change when it should (On windows borders, or text selection, tooltips) ... But I'm guessing this means it's not a kernel panic situation (?)
 
Tried two more things:

I also tried starting # sleep 30 && kill <XORG PID> && sleep 10 && xinit in VT1 before attempting to run mplayer -- That didn't do anything.

I also switched from the intel driver to the vesa driver in my xorg.conf, that "solved" the problem! This means the problem is somewhere in the dri/dri_i915 modules and/or the intel driver?
Still not sure how to get more information for a usable bug report ... you mentioned a firewire console?
 
I've had similar lockups with the radeon driver, if I stop and restart X. I actually have a serial console setup to another machine, yet nothing is ever displayed on the console, forcing a hard reset. So I, too, would be very happy to find a way to get more debugging information.

Adam
 
Running CURRENT (on a laptop) from march 2011, upgraded to releng_9 and exiting X almost immediately crashes. Per another post, changing EXA to XAA in xorg.confmakes the crashes few/gone immediately after exiting X (a few times so far), but occur randomly after that. Maybe further testing with "vesa" rather than "ati" ...
//update//
GENERIC , removed sound drivers, debugging paragraph, debug line;
xorg.conf, changed EXA to XAA and ati to vesa per the posts above
removed and touched as a zero byte file /var/account/acct (file had grown too large).
....seems to have "exiting X" working smoothly again. I'll know after a few hours usage but not within the next few weeks afaik... (releng_9 as of about oct 05 2011)
 
Well, yes, I know that the radeon driver is the issue. Disabling direct rendering and/or using vesa, and there's no lockup when restarting X (and for me, the lockup happens a few seconds after X starts the second time, not when I quit out of X).

But that's a bad workaround, not a solution :-)

Adam
 
You must log in or register to reply here.
Back
Top