Re: Memory Mangement Problem in 5.1-RELEASE
Ahmed Al-Hindawi wrote: dude, I have a third of my memory free!! does vmstat agree? is kernel/userland in sync? -- Matthias Buelow; [EMAIL PROTECTED],informatik.uni-wuerzburg.de} ___ [EMAIL PROTECTED] mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to "[EMAIL PROTECTED]"
Re: DragonFly lists are on the DragonFly site...
Nigel Weeks wrote: http://www.dragonflybsd.org/Main/forums.cgi Has both newsgroups and mailing lists on it... If dfbsd breaks the stupid trend of mailing lists and sets up a proper news server for that purpose, how it was meant to be, it is already a great achievement... -- Matthias Buelow; [EMAIL PROTECTED],informatik.uni-wuerzburg.de} ___ [EMAIL PROTECTED] mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to "[EMAIL PROTECTED]"
Re: ``Resource temporarily unavailable'' in vi
Mikhail Teterin writes: >Every once in a while, a vi-session dies on me with: > > input: Resource temporarily unavailable Are you running ksh93 per chance? I've seen this after I started an OpenGL program such as xscreensaver-demo from ksh93 (however that could have influenced the terminal settings or whatever is beyond my current understanding.) -- Matthias Buelow; [EMAIL PROTECTED],informatik.uni-wuerzburg.de} ___ [EMAIL PROTECTED] mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to "[EMAIL PROTECTED]"
Re: radeon lockups w/ 5.1-R
Scott M. Likens writes: >Are you using the drm kernel drivers from the kernel, or are you using >DRI-HEAD from dri.sf.net? >From the kernel (I didn't install anything else). -- Matthias Buelow; [EMAIL PROTECTED],informatik.uni-wuerzburg.de} ___ [EMAIL PROTECTED] mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to "[EMAIL PROTECTED]"
radeon lockups w/ 5.1-R
Hi folks, anyone else still seeing occasional lockups when using a Radeon graphics card? I've had these frequently with a R7500 on 5.0p7 and now installed 5.1 hoping that the issue had been fixed in the meantime. It went well for two days but it just fscked up again so the problem is still there. It only happens when I exit the X session. Display becomes garbled and the machine locked up completely (didn't always do so in the past with 5.0, I sometimes could log in over the network and reboot the machine.) I think the problem was already known for 5.0, or does it warrant a new PR? -- Matthias Buelow; [EMAIL PROTECTED],informatik.uni-wuerzburg.de} ___ [EMAIL PROTECTED] mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to "[EMAIL PROTECTED]"
Re: Anyone had hangs with Radeon, XF86 4.3.0, and DRI on logout?
Julian St. wrote: It seems not to be related, but when I try to kill my X Server using Ctrl+Alt+Backspace, my box powers down (jsut like an APM power-down). I started noticing it using 4-STABLE+ NVidia driver, but it continued to be the case on -CURRENT with Xfree86's nv driver. I always see this on one machine. I always attributed it to the mainboard (a cheap ecs k7s5a) doing the powerdown by itself somehow if the appropriate keys are pressed on the keyboard... It powers back up if you press the Any Key, tho. --mkb ___ [EMAIL PROTECTED] mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to "[EMAIL PROTECTED]"
Re: Anyone had hangs with Radeon, XF86 4.3.0, and DRI on logout?
Eric Anholt wrote: As the subject says, I'm wondering if anyone out there has experienced hangs on logging out from xdm (or perhaps switching VTs) with Radeon or matrox (perhaps r128, too) cards using the updated DRM in -current and XFree86 4.3.0. If so, I may have a fix, but I'm wondering if this affects FreeBSD. Yes, I had them from 5.0 onwards until -p7. Not only with radeon but also (although not so often) with mga. They don't seem to happen anymore with the Matrox card in -p7 but I can't right now check if it's still problematic with a Radeon (I have swapped cards in hope to workaround that problem.) But since I also had problems with the mga before -p7 and they don't seem to exist anymore now perhaps the problem has gone away? (The problem manifested itself in the X server taking 100% cpu in kernel mode, and trying to kill it, or trying to reboot made the machine freeze solid. It only happened when the X session was terminated / X server was restarted, and occasionally in some xscreensaver hacks, after a while, although I couldn't ascertain this because I usually am not there when xscreensaver is running... ;) --mkb ___ [EMAIL PROTECTED] mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to "[EMAIL PROTECTED]"
Re: Overall "feel" for the stability of FreeBSD 5
Bill Moran writes: >2) For a dedicated backup server, that can tolerate the > performance problems that folks have been reporting, and > won't upset the entire office if it panics on occasion, is 5 > good enough at this point? If the system isn't really too critical, I'd go for it. I'm running 5.0 in workstation use and had some problems with agp and X11 up until 5.0-RELEASE-p7, on which I haven't had a crash or freeze yet and all seems to be stable. I'm using scsi and ide on that machine. Apart from the agp/graphics/X11 problem and one (I think) related kernel panic I've experienced with < -p7, I've not seen any problems. IMHO it's stable enough for use in a relaxed production environment. The more people who engage in testing it, the more problems (also cutting edges in the userland) get ironed out, and the faster that will happen. --mkb ___ [EMAIL PROTECTED] mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to "[EMAIL PROTECTED]"
Re: linux-emu ioctl not implemented w/ quake3
I wrote: >Using XFree86-VidModeExtension Version 2.2 >XFree86-VidModeExtension Activated at 640x480 >libGL error: failed to open DRM: Operation not permitted Ok, I hadn't seen so far the instructions for 5.0 on Eric Anholts website... in fact, I needed to include a few lines into the kernel config and rebuild; in my case: device mgadrm options COMPAT_LINUX options DRM_LINUX did the trick. Now quake seems to work stable, although it seems to be much slower than on Windoze, the cinematics don't work and I get a good amount of garbage (flickering etc.) between frames but it's playable, and above all, doesn't crash the machine. --mkb ___ [EMAIL PROTECTED] mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to "[EMAIL PROTECTED]"
linux-emu ioctl not implemented w/ quake3
Hi folks,
I'm running 5.0-RELEASE-p7 on i386 and investigated how quake3 (linux)
would be doing at the moment. I had some relative success on 4.7
(quake3 ran ok, in 3d acceleration, but only for about 30 seconds, at
which point the whole machine froze solid) so I hoped it might just
work out. This time at least it didn't freeze but I don't even get so
far. When I run quake3.x86, I get the following:
quake3 spits:
Using XFree86-VidModeExtension Version 2.2
XFree86-VidModeExtension Activated at 640x480
libGL error: failed to open DRM: Operation not permitted
...
(at which point it offers me to use Mesa software rendering
as a fallback which, of course, works...)
and the kernel says:
Apr 3 04:59:23 reiher kernel: linux: 'ioctl' fd=13, cmd=0x6401 ('d',1) not implemented
Does anybody know what ioctl that would be? I didn't get that on 4.7,
is linux-emu divergent between -stable and -current?
The relevant ktrace excerpt follows:
...
1713 quake3.x86 RET old.setrlimit 12/0xc
1713 quake3.x86 CALL ftruncate
1713 quake3.x86 RET ftruncate 1000/0x3e8
1713 quake3.x86 CALL setrlimit(0x2cea6c30,0xbfbfea00,0)
1713 quake3.x86 NAMI "/compat/linux/dev/dri"
1713 quake3.x86 NAMI "/dev/dri"
1713 quake3.x86 RET setrlimit 0
1713 quake3.x86 CALL setrlimit(0xbfbfeb00,0xbfbfea00,0)
1713 quake3.x86 NAMI "/compat/linux/dev/dri/card0"
1713 quake3.x86 NAMI "/dev/dri/card0"
1713 quake3.x86 RET setrlimit 0
1713 quake3.x86 CALL open(0xbfbfeb00,0x2,0)
1713 quake3.x86 NAMI "/compat/linux/dev/dri/card0"
1713 quake3.x86 NAMI "/dev/dri/card0"
1713 quake3.x86 RET open 13/0xd
1713 quake3.x86 CALL ioctl(0xd,0xc0086401 ,0xbfbfec00)
1713 quake3.x86 RET ioctl -1 errno -22 Unknown error: -22
1713 quake3.x86 CALL close(0xd)
1713 quake3.x86 RET close 0
1713 quake3.x86 CALL ftruncate
1713 quake3.x86 RET ftruncate 1000/0x3e8
1713 quake3.x86 CALL setrlimit(0x2cea6c30,0xbfbfea00,0)
1713 quake3.x86 NAMI "/compat/linux/dev/dri"
1713 quake3.x86 NAMI "/dev/dri"
1713 quake3.x86 RET setrlimit 0
1713 quake3.x86 CALL setrlimit(0xbfbfeb00,0xbfbfea00,0)
1713 quake3.x86 NAMI "/compat/linux/dev/dri/card1"
1713 quake3.x86 NAMI "/dev/dri/card1"
1713 quake3.x86 RET setrlimit JUSTRETURN
1713 quake3.x86 CALL ftruncate
1713 quake3.x86 RET ftruncate 1000/0x3e8
1713 quake3.x86 CALL setrlimit(0x2cea6c30,0xbfbfea00,0)
1713 quake3.x86 NAMI "/compat/linux/dev/dri"
1713 quake3.x86 NAMI "/dev/dri"
1713 quake3.x86 RET setrlimit 0
1713 quake3.x86 CALL setrlimit(0xbfbfeb00,0xbfbfea00,0)
1713 quake3.x86 NAMI "/compat/linux/dev/dri/card2"
1713 quake3.x86 NAMI "/dev/dri/card2"
1713 quake3.x86 RET setrlimit JUSTRETURN
1713 quake3.x86 CALL ftruncate
1713 quake3.x86 RET ftruncate 1000/0x3e8
1713 quake3.x86 CALL setrlimit(0x2cea6c30,0xbfbfea00,0)
1713 quake3.x86 NAMI "/compat/linux/dev/dri"
1713 quake3.x86 NAMI "/dev/dri"
1713 quake3.x86 RET setrlimit 0
1713 quake3.x86 CALL setrlimit(0xbfbfeb00,0xbfbfea00,0)
1713 quake3.x86 NAMI "/compat/linux/dev/dri/card3"
1713 quake3.x86 NAMI "/dev/dri/card3"
1713 quake3.x86 RET setrlimit JUSTRETURN
1713 quake3.x86 CALL ftruncate
1713 quake3.x86 RET ftruncate 1000/0x3e8
1713 quake3.x86 CALL setrlimit(0x2cea6c30,0xbfbfea00,0)
1713 quake3.x86 NAMI "/compat/linux/dev/dri"
1713 quake3.x86 NAMI "/dev/dri"
1713 quake3.x86 RET setrlimit 0
1713 quake3.x86 CALL setrlimit(0xbfbfeb00,0xbfbfea00,0)
1713 quake3.x86 NAMI "/compat/linux/dev/dri/card4"
1713 quake3.x86 NAMI "/dev/dri/card4"
1713 quake3.x86 RET setrlimit JUSTRETURN
1713 quake3.x86 CALL ftruncate
1713 quake3.x86 RET ftruncate 1000/0x3e8
1713 quake3.x86 CALL setrlimit(0x2cea6c30,0xbfbfea00,0)
1713 quake3.x86 NAMI "/compat/linux/dev/dri"
1713 quake3.x86 NAMI "/dev/dri"
1713 quake3.x86 RET setrlimit 0
1713 quake3.x86 CALL setrlimit(0xbfbfeb00,0xbfbfea00,0)
1713 quake3.x86 NAMI "/compat/linux/dev/dri/card5"
1713 quake3.x86 NAMI "/dev/dri/card5"
1713 quake3.x86 RET setrlimit JUSTRETURN
1713 quake3.x86 CALL ftruncate
1713 quake3.x86 RET ftruncate 1000/0x3e8
1713 quake3.x86 CALL setrlimit(0x2cea6c30,0xbfbfea00,0)
1713 quake3.x86 NAMI "/compat/linux/dev/dri"
1713 quake3.x86 NAMI "/dev/dri"
1713 quake3.x86 RET setrlimit 0
1713 quake3.x86 CALL setrlimit(0xbfbfeb00,0xbfbfea00,0)
1713 quake3.x86 NAMI "/compat/linux/dev/dri/card6"
1713 quake3.x86 NAMI "/dev/dri/card6"
1713 quake3.x86 RET setrlimit JUSTRETURN
1713 quake3.x86 CALL ftruncate
1713 quake3.x86 RET ftruncate 1000/0x3e8
1713 quake3.x86 CALL setrlimit(0x2cea6c30,0xbfbfea00,0)
1713 quake3.x86 NAMI "/compat/linux/dev/dri"
1713 quake3.x86 NAMI "/dev/dri"
1713 quake3.x86 RET setrlimit 0
1713 quake3.x86 CALL setrlimit(0xbfbfeb00,0xbfbfea00,0)
1713 quake3.x86 NAMI "/compat/linux/dev/dri/card7"
1713 quake3.x86 NAMI "/dev/dri/card7"
1713 quake3.x86 RET setrlimit JUSTRET
