On Mon, 28 Feb 2005 00:48:20 -0500
bsdnooby [EMAIL PROTECTED] wrote:
[...]
I think this line is bad:
The selected video_out device is incompatible with this codec.
[...]
I get this with a number of video files that I have here locally, but it
doesn't prevent mplayer from actually playing
Currently, if I log in, do some work, then log out (from plain TTY, no
X/SSH/etc), the output of my previous session is still readable above
the new login: prompt. One can use scroll lock to view even more.
How do I get it to clear the screen (and the scroll buffer) when the
login prompt gets
On Sun, May 3, 2009 at 12:48 PM, gabe g johndoeismyn...@gmail.com wrote:
Hey John,
In order to achieve this, there are two methods that I know of,
however, they are only tested in the Bourne and Bourne Again shells.
clear logout # Bourne Again (Bash) Shell
clear exit
On Sun, May 3, 2009 at 1:51 PM, Paul B. Mahol one...@gmail.com wrote:
echo $TERM | grep cons25 /dev/null clear vidcontrol -C
Aha! I didn't know about 'vidcontrol -C'
That combined with 'clear' does the trick.
However...
Is there any way I could have this execute when the login: prompt
I've been having an intermittent problem, wonder if someone on the
list has any ideas.
First my setup:
FreeBSD 7.2-RELEASE (amd64)
quad-core Phenom processor
mobo: MSI K9N2G Neo
chipset: NVIDIA GeForce 8200, which FreeBSD recognizes as nForce (not
sure how that works)
I have a 3ware RAID card
I'm trying to figure out a strange panic issue (see:
http://lists.freebsd.org/pipermail/freebsd-questions/2009-July/201842.html).
The problem is I generally need to run it overnight in order to reproduce it.
By the time I get back to it, the machine has auto-rebooted, losing
precious info in
Hello,
I am trying to use audio/ripit to rip an audio CD, but it results in a
system hang (no panic) every time.
Here is the tail of /var/log/messages when it happens:
Jul 18 22:25:46 lumpy kernel: acd0: WARNING - TEST_UNIT_READY
taskqueue timeout - completing request directly
Jul 18
On Sat, Jul 18, 2009 at 11:25 PM, Polytroponfree...@edvax.de wrote:
Maybe wrong cable (40 pin)? The device detached message
doesn't look good. First of all, it shouzld at least be UDMA66.
Maybe defective drive due to failing TUR taskqueuing?
Wow, thanks for the 'bad cable' idea. I replaced
\ cvh
CustomLog /usr/local/logs/everything.log cvh
So you can scale out to 5000 vhosts and not run into any limit
problems. For errors the splitting up is a bit more tricky, but you
should be able to get it done as well.
Good luck,
Bert JW Regeer
