After power drift

1. reboot system
2. into single mode (4)
3. fsck -y

FreeBSD的 current , stable , release 版本, 有何差別?

current 就是還在開發中的，每天都會有新的程式碼加入world , kernel中，會是production release的下一版，也就是還在開發中的版本，通常都是心臟很強的系統管理者在用的，或是有在開發world , kernel的core team成員在用的版本，不保證功能都會正常，也不保證穩定性，這邊指的版本是大的版本編號，例如從7到8這樣的大版號跳躍

stable 並不是所謂的穩定版，它只是目前的release版本到下一個release版本之間的版本，每天都會有新功能加進來，不過和current 比起來，算是比較穩定的，下一個release版本的新功能會在stable先做測試，新功能測試的差不多之後就會變成新的release，適合喜歡用新功能，可是又怕不穩的人，或是自己的工作站，自己的desktop這類的用途，這邊指的版本是小的版本編號，例如從7.0到7.1這樣的小版號跳躍

release 顧名思義就是發行版，release只要發行了之後，程式碼就不會再做更動了，只會有安全性修正的patch會加進來，比較適合做為server用途，追求穩定的時候就適合使用release版搭配security patch

Flash 9 for FreeBSD 7.1

Step 1: Enable Linux compatibility and linprocfs

Add linux_enable="YES" to /etc/rc.conf. Add compat.linux.osrelease=2.6.16 to /etc/sysctl.conf. Add OVERRIDE_LINUX_BASE_PORT=f8 to /etc/make.conf. Add this line to /etc/fstab:

linproc /usr/compat/linux/proc linprocfs rw 0 0

Then run these commands:

mkdir -p /usr/compat/linux/proc
mount /usr/compat/linux/proc
/etc/rc.d/abi start
/etc/rc.d/sysctl start

Step 2: Update ports and install all the needed software

You will now need to install the following ports and their dependencies:

cd /usr/ports/emulators/linux_base-f8 && make install clean
cd /usr/ports/www/linux-flashplugin9 && make install clean
( or cd /usr/ports/www/linux-f8-flashplugin10 && make install clean )
cd /usr/ports/www/nspluginwrapper && make install clean

Follow the nspluginwrapper instructions to enable all available plugins:

# nspluginwrapper -v -a -i
Auto-install plugins from /usr/X11R6/lib/browser_plugins
Looking for plugins in /usr/X11R6/lib/browser_plugins
Auto-install plugins from /usr/local/lib/npapi/linux-flashplugin
Looking for plugins in /usr/local/lib/npapi/linux-flashplugin
Install plugin /usr/local/lib/npapi/linux-flashplugin/libflashplayer.so
into /usr/local/lib/browser_plugins/npwrapper.libflashplayer.so
Auto-install plugins from /root/.mozilla/plugins
Looking for plugins in /root/.mozilla/plugins

Restart or open Firefox 3 and enter about:plugins into your address bar. You should see something like the following:
"Shockwave Flash 9.0 r124"

Original source : http://crnl.org/blog/2008/11/01/flash-9-for-freebsd-71

PS(1) : plugin 原本是放在 /usr/local/lib/brower_plugins 之下. 但 firefox 3.x 之後, 似乎要放到 ~/.mozilla/plugins 才可正常運作.

PS(2) : How to disable flash in FreeBSD:
Method1 : install extension : flashblock
Method2 : install FreeBSD port : dummyflash

PS(3) : plugin 可能存放位置
/usr/local/lib/browser_plugins
/usr/local/lib/firefox/plugin
~/.mozilla/plugins
/usr/X11R6/lib/firefox
/usr/X11R6/lib/browser_plugins

Adding a new slice, problem with sysinstall

1. Create a new slice : sysinstall->Configure->Fdisk

2. Make sure only one ACTIVE slice ( partition )
fdisk /dev/ad0
fdisk -a -1 /dev/ad0

3. Add a 'standard' label, remember disks start from zero, but slices start
from one!:
# bsdlabel -w /dev/ad0s3

4. Edit the label:
# bsdlabel - e /dev/ad0s3
Change fstype on the line beginning a: from unknown to 4.2BSD, then save
and exit.

5. Format the new partition:
# newfs /dev/ad0s3a

6. Test mount the partition:
# mount /dev/ad0s3a /mnt

7. Edit /etc/fstab. Add a new line similar to the line for /dev/ad0s2a.
Careful! getting fstab wrong can prevent your system starting.
Test the new fstab with # mount -a.

Installing dri drivers on FreeBSD

Installing dri drivers on FreeBSD

Friday, November 26 2004 @ 04:17 PM CET Contributed by: bart Views: 3724 I am getting quite a few questions with regards to installing dri enabled graphics drivers on FreeBSD. In this article I'll discuss the general setup, and it shoudl enable you to get this to work for every card that is supported. Supported hardware: Older Matrox hardware (g200 - g550), everything before the P series Older ATI hardware (8xxx and 9000 upto 9400, basicly everything with a rv2xx chipset) Some S3 hardware What is inmediately clear from this is that it almost exclusively concerns older hardware. WHat is also clear is the complete lack of NVIDIA in the list. Why do you need dri? Accelerated 3d graphics, ie: OpenGL support. OpenGL support is usefull for more then a bit of gaming. Makign previews in renderign software is just one of the more serious uses for it. What do you need? Of course you need a supported video card. Beyond that, you will need the sources for the kernel and you need XFree86 v4.x or Xorg 6.7 or later. Installation After installing the kernel sources, do the following: cd /usr/src/sys/modules/drm make make install Now you have the direct rendering modules installed, and you can load the one appropriate for your video card. The best way to do this is by adding it to the boot loader configuration, to do so, you have to add a line to /boot/loader.conf similar to: radeon_load="YES" Replace radeon with the proper module name for your card (mga for Matrox, s3 for.. s3) Known issues It is worth noting that you really should load the module at boot time or at least make absolutely sure that you have either agp enabled in your kernel, or load the agp module at boot. The issue here is that the agp module can not be loaded after the kernel booted, and the dri modules depend on agp. So if you don't have agp support when your kernel boots, dri is NOT going to work ever. Installing X Once the module works, you will get a message during startup that will tell you that drm is enabled and has found soem graphics hardware. Now it is time for configuring the X server. This should be pretty straightforward, just make sure you have the dri and glx modules loaded, and select a driver appropriate for your card, and things should be fine. You can verify if your setup indeed uses direct rendering with the glxinfo command. Not getting X to start? If you do not get a working X at all but the dri modules are loaded by the kernel and give the expected output on boot, it might well eb that you have a problem with your AGP setup. The first thing to do in such a case is goto your bios and DISABLE fast write and any other advanced AGP features. Try again and see if it works now. If it does, enable the features one by oen and try each time if the X server still starts and works. Especially ATI Radeon cards on boards with a VIA chipset are extremely picky about AGP setup, and will fail in mysterious ways when you enable fast write, so unless you like such mysteries, you better just disable this.

DRI Troubleshooting

This is a process for troubleshooting the DRI. It only works if you do it in order. OS names prefix OS-specific parts.

This process assumes you have XFree86 4.3.0 or newer installed. If not, update to any version of X.Org, or XFree86 4.3.0 or newer, before starting.

Contents

1. Kernel Setup
1. AGP
2. DRM
2. X server setup
3. Userspace setup

Kernel Setup

AGP

If you have a PCI card you may skip this section (DRM will load the AGP driver to resolve symbols, but otherwise doesn't need it). If you have a non-Intel PCIE chipset you may also skip this step.

Check that AGP has been set up properly. If you have a PCI or PCIE card you may skip this step. Otherwise, if dmesg | grep agp returns nothing, you need to fix it.

FreeBSD:

• If dmesg | grep agp doesn't show anything about agp, make sure you have device agp in your kernel (it's default in -stable and -current). AGP does not work when loaded as a module after boot until FreeBSD 7.0-current.

• If your AGP module is loaded according to kldload but it didn't show up, probes fine, then you may have device agp in the kernel and loaded from loader.conf. This doesn't work, so remove it from loader.conf.

• If you aren't using RELENG_6 (note: not RELENG_6_0), you may need to update to get support for your AGP chipset.

• If you have device agp in the kernel but not in loader.conf, and are using RELENG_6 or newer, and it still doesn't probe, please file a PR containing the output of scanpci and your dmesg.

Linux:

• If there are no agpgart: lines, compile agpgart into your kernel or load it as a module.

• If it complains about an unsupported chipset/bridge, make sure you included your chipset-specific AGP support when you configured the kernel. This chipset support is for your motherboard, not for your video card, so if you have a Radeon on an Intel motherboard, you need intel-agp.ko, not ati-agp.ko.

DRM

Check that the DRM (Direct Rendering Module, the kernel module) is loaded and has found your card. Do dmesg | grep drm. You should have several lines of info, with samples below:

FreeBSD:

drm0:  port 0x9000-0x90ff mem 0xed000000-0xed00ffff,0xe0000000-0xe7ffffff irq 10 at device 0.0 on pci1
info: [drm] AGP at 0xe8000000 64MB
info: [drm] Initialized radeon 1.9.0 20020828 on minor 0
info: [drm] Loading R200 Microcode

Linux:

[drm] AGP 0.99 on Intel i815 @ 0xe8000000 64MB
[drm] Initialized radeon 1.1.1 20010405 on minor 0

Note that 64MB is not the size of the card's memory; it's the size of the AGP aperture (how much system memory can be accessed by the card if X chooses to use that much).

FreeBSD:

• If kldload (card being one of mga, r128, radeon, sis, tdfx) says Exec format error, check your dmesg for complaints about unresolved symbols. If the unresolved symbols are agp, look at the AGP instructions above.

• If kldstat shows your card module is loaded but nothing shows up in dmesg | grep drm, you may not have a supported card, or it may not be getting probed due to the PCI ID being missing from the driver.

Linux:

• If you get DRM version output but not your card-specific DRM version output, you may not have a supported card, or it may not be getting probed due to the PCI ID being missing from the driver.

If your card isn't getting probed, please make sure you are using current DRM CVS sources before submitting a report of missing support. Instructions for building the DRM are at: Building.

If you are using current DRM sources and your card should be supported by an existing driver but isn't, please submit a report to http://bugs.freedesktop.org/ with the output of scanpci

X server setup

At this point DRM should be set up correctly. Start the X server and grep "Direct rendering" /var/log/Xorg.0.log. If that grep returns "Direct rendering enabled", skip ahead to the next section.

If that grep returns nothing, make sure you have lines for Load "dri" and Load "glx" in the Modules section of xorg.conf. If your changes to xorg.conf have no effect, make sure the xorg.conf you are editing matches the one being used according to grep config\ file /var/log/Xorg.0.log

Next, make sure that X works with the DRM correctly. Look at the bottom of the X log where it has lines with [dri], [drm], [agp], etc. If there are any (EE) errors in there, look at those.

If you get a message like this:

(EE) [dri] RADEONDRIScreenInit failed because of a version mismatch
(EE) [dri] libdri version is 4.2.0 but version 5.0.0 is needed.
(EE) [dri] Disabling DRI.

then your libdri module is too old. If you installed from a snapshot, be sure to update the common module. If the version numbers are the other way around (version is 5.0 but version 4.2 is needed) then you updated your server without updating your 2D driver as well.

If it complains about the kernel module version, you have to update your kernel modules. For FreeBSD, this means either modules from -current or from -stable as described in the install section. For Linux, the kernel DRM is updated semi-regularly, and Alan Hourihane's website also has kernel modules.

Linux:

• If you get this error message:

  [agp] AGP not available
  

  despite the fact that the agpgart module loaded and initialized without problems, ensure that agpgart loads before the driver module for your chipset (like the radeon module). If agpgart loads later, the driver module will not see the AGP bus. As well, make sure the kernel module for your AGP bridge loads before the driver module for your chipset. For example, if your AGP bridge is an AMD Irongate (this can be determined via lspci -v and looking for the line containing AGP), make sure that amd_k7_agp is loaded before the driver module (say radeon).

• If you thought you had updated your kernel module and the updated version shows up after you modprobe the appropriate .o, make sure your kernel doesn't have the DRM compiled in. If you dmesg | grep drm, it will show that multiple versions were loaded. Recompile your kernel without the DRM, and install the updated module again.

• If it says:

  [drm] drmSetBusid failed (7, PCI:1:0:0), Permission denied
  

  people have said that it's because the modules were built with a different gcc version than the kernel. Make sure they are in sync. Also, dmesg output should show something about version magic mismatches if this is the case.

• If at this point, dmesg says:

  [drm:radeon_cp_init] *ERROR* radeon_cp_init called without lock held
  

  then you missed the part above about having the correct AGP modules loaded. 2.6 users need to make sure both the agpgart core module and the appropriate chipset-specific module are loaded. Run lspci | grep "AGP bridge" to find out what sort of AGP chipset you have. Intel needs intel-agp, VIA needs via-agp, etc.

If you find a line saying:

(EE) RADEON(0): [dri] RADEONInitVisualConfigs failed (depth 8 not supported). Disabling DRI.

or something along those lines, this is because none of the DRI drivers support rendering in 8-bit mode. If you have a Voodoo3, it only works in 16-bit mode and will say something similar if you try 32-bit. Change your depth appropriately by adding:

   DefaultDepth 16

or

   DefaultDepth 24
 DefaultFbBpp 32

as appropriate to your xorg.conf's Screen section.

If there are no [dri] lines and it says Direct Rendering disabled, you may be trying to use too high a resolution. grep Static\ buffer /var/log/Xorg.0.log will find a line like:

(WW) ATI(0): DRI static buffer allocation failed -- need at least 4608 kB video memory

If so, reduce your resolution or color depth. The video ram necessary for a given resolution/depth is width*height*(depth/8)*3 kilobytes. (The 3 is for front, back, and depth buffers).

If you are using Intel i8xx hardware and it says:

(WW) I810(0): xf86AllocateGARTMemory: allocation of 1024 pages failed
 (Cannot allocate memory)

You need to have X.Org allocate more system memory to the integrated graphics. In the Device section of xorg.conf, set VideoRam to something higher, for example:.

   VideoRam 32768

If you see messages about:

Symbol __glXActiveScreens from module /usr/X11R6/lib/modules/extensions/libdri.a is unresolved!

make sure you have Load "glx" in your xorg.conf's modules section. If you do have Load "glx", make sure you don't have any parts of the nvidia binary driver installed, particularly libglx.so*. Remove those, and reinstall X.Org if you continue to have problems.

Userspace setup

Next, look at a GL program. Set the environment variable LIBGL_DEBUG to verbose, i.e. setenv LIBGL_DEBUG verbose for csh-based shells or export LIBGL_DEBUG=verbose for bash-based shells. Run glxinfo, which should be included with X.Org. At the top it should show libGL trying to load the driver-specific hardware rendering library, like:

libGL: OpenDriver: trying /usr/X11R6/lib/modules/dri/radeon_dri.so.

If it isn't doing that, you have replaced your X.Org-provided libGL with some other libGL, or it's finding an old libGL from somewhere. Run ldd /usr/X11R6/bin/glxinfo and see which libGL it's finding. Make sure it's the one in /usr/X11R6/lib/libGL, or a link in /usr/lib to the one in /usr/X11R6/lib. You shouldn't have any libMesaGL* on your system.

If the driver complains about unresolved symbols:

libGL error: dlopen /usr/X11R6/lib/modules/dri/radeon_dri.so failed
 (/usr/X11R6/lib/modules/dri/radeon_dri.so: undefined symbol: _glapi_noop_enable_warnings)

then your libGL is out of sync with your DRI drivers. Because APIs change, you typically need a libGL from the latest X.Org release to run DRI drivers, and sometimes you need a libGL from X.Org CVS for the latest drivers. Reinstall both your drivers and your libGL from sources from the same date.

If you get:

libGL error: failed to open DRM: Operation not permitted
libGL error: reverting to (slow) indirect rendering

then you are trying to run as a user that doesn't have permission to use the DRI (root is the default allowed user). To let all users access the DRI, add the following section to your xorg.conf:

Section "DRI"
  Mode 0666
EndSection

If you get (the driver name may vary):

libGL error: dlopen /usr/X11R6/lib/modules/dri/r200_dri.so failed (libexpat.so.1 : cannot open shared object file: No such file or directory)
libGL error: unable to find driver: r200_dri.so

then make sure that you have libexpat.so.1 installed. Binary snapshots now come with a statically linked libexpat, so this should no longer be a problem.

If you get (the driver name may vary):

libGL error: dlopen /usr/X11R6/lib/modules/dri/r200_dri.so failed (r200_dri.so : cannot open shared object file: No such file or directory)

then make sure you have compiled the appropriate dri module for your card. It it could be either in a separate file (r200_dri.so in this case), or bundled in libGL.so. Edit xc/config/cf/host.def and make sure you list at least your driver (if not all available) in a line:\ \

#define BuildXF86DRI YES
/* 2D accel drivers are: ati mga glint s3virge sis savage nv tga rendition tdfx vga i810 sunffb sunleo suncg6 suncg3 suncg14 suntcx */
#define XF86CardDrivers ati
/* the next line DriDrivers defines dri modules. Valid choices: gamma i810 i915 mach64 mga r128 radeon r200 tdfx savage sis ffb
 ati is not a valid DriDriver name. For new Radeon cards use r200 instead. */
#define DriDrivers radeon r200

If you have a 3dfx card and it's complaining about libglide3, or there are glide errors, you need to install the correct glide for your card as provided by your distribution.

If you are using a radeon and it complains about the module versions and maybe fails on an assertion, you need to update your DRM as in the instructions above.

If you've made it this far, glxinfo should be printing direct rendering: Yes and direct rendering for native GL programs should be working. Make sure that you are running at reasonable settings for your card, and maybe adjust your expectations of speed.

If you are experiencing trouble using GL with any program, maybe setting more environment variables may help you.

FreeBSD:

• Linux compatibility has its own set of issues. To debug Linux DRI compatibility (i.e. quake3/UT), use /compat/linux/usr/X11R6/bin/glxinfo with LIBGL_DEBUG=verbose set. You should be using -current as of April 25, 2003, or -stable as of May 2, 2003. Your linux_dri version should exactly match the X you have installed. If not you'll probably get segfaults. If your X.Org segfaults, make sure you don't have the linux_glx port installed. If you get coredumps on your system with SSE support (Pentium 3 and up, Athlon XP and up), you may need to set the environment variable MESA_FORCE_SSE to 1 due to what appears to be a bug with our linux compat's signal handling.