Returning to FreeBSD after 15 years

Hello,

Yes, 15 years ago I took my first step out of the MS world and NT machines, by building a FreeBSD server for my company. It didn't last long; I had to change to Gentoo first, and then Debian, for administering easiness.

All the machines that I now administer are mostly Manjaro OpenRC and some Debian Wheezy (pre-systemd), the later on conversion process. My mission critical laptop is a MacBook Pro running Manjaro OpenRC. I like the Apple hardware, although difficult to justify the price.

So, to evaluate the possibility of a move to FreeBSD, I went to the basement and grabbed one of my old laptops for testing, also about 15 years old, a Fujitsu-Siemens Amilo D 6820, which has an ATI graphics Radeon 9000 Mobility M9 (RV250) (AGP), and I've been struggling to install FreeBSD on this.

First of all, either Knopix 6.2 or Ubuntu 10.04 live cd's work perfectly with this, using the radeon driver. But FreeBSD 11.0 STABLE (or RELEASE, same result), work well with Vesa driver but give a blank screen with the radeon driver. The problem seems to be that this build of the driver is incapable of detecting the LVDS output. But it detects the VGA and S-Video outputs. Can't be a hardware problem because, as I said, either Knopix or Ubuntu detect LVDS perfectly.

I have tried almost every combination of option parameters in Device, Monitor, Screen, and other, sections of xorg.conf to no avail. No xorg.conf at all (pulling radeon) doesn't work either. The simple fact of loading radeonkms produces a blank screen. I already inserted kern.vty=vt in /boot/loader.conf.

Relevant output and logs:
Code:
# pciconf -lv
vgapci0@pci0:1:0:0:   class=0x030000 card=0x205817c0 chip=0x4c661002 rev=0x01 hdr=0x00
    vendor     = 'Advanced Micro Devices, Inc. [AMD/ATI]'
    device     = 'RV250/M9 GL [Mobility FireGL 9000/Radeon 9000]'
    class      = display
    subclass   = VGA

Code:
$ startxfce4 --with-ck-launch
from ssh:
$ cat /var/log/Xorg.0.log
...
[   295.441] (II) RADEON(0): SwapBuffers wait for vsync: enabled
[   295.444] (II) RADEON(0): Output VGA-0 has no monitor section
[   295.447] (II) RADEON(0): Output S-video has no monitor section
[   295.450] (II) RADEON(0): EDID for output VGA-0
[   295.476] (II) RADEON(0): EDID for output S-video
[   295.476] (II) RADEON(0): Output VGA-0 disconnected
[   295.477] (II) RADEON(0): Output S-video disconnected
[   295.477] (WW) RADEON(0): No outputs definitely connected, trying again...
[   295.477] (II) RADEON(0): Output VGA-0 disconnected
[   295.477] (II) RADEON(0): Output S-video disconnected
[   295.477] (WW) RADEON(0): Unable to find connected outputs - setting 1024x768 initial framebuffer
...

So, I would appreciate any help to solve this, in order to evaluate whether FreeBSD is a valid option for our needs.

Rgds
jss
 
Thank you for replying

Well, the wiki says Radeon 9000 RV250 is fully supported.

Furthermore, as I said, I'm using 11.0-STABLE. Should support AGP, isn't it?

Multiple cards sharing output connectors -> I guess I have the reverse situation, that is, one card with multiple output connectors, of which one is not being detected.

The other notes are of no interest to me at this moment:
Features not yet working/implemented:
Hardware-assisted video decoding
Audio over HDMI or DisplayPort
Power management

Any comments?
 
Any comments?
I have no idea, since I don't use xorg or even video cards in my servers.

But a quick stroll through the code in /sys/dev/drm2/radeon/ shows lots of DRM_DEBUG lines, and there does seem to be LVDS support. I think this may be controlled by a sysctl used in /sys/dev/drm2/drm_sysctl.c. I'd suggest doing a # sysctl -a | grep drm or # sysctl -a | grep radeon and see if there are any debug sysctls in there. If there are, try setting them and repeating your tests and see if they produce any debugging output. Thay may lead to further ideas, or at least indicate if the code is detecting your display at all.
 
Any comments?
I will never understand why people want to experiment with the new version of a new operating system using antique hardware.

While Radeon support is far better than it has been, some people here use it, most will plug in a nVidia card first cause nVidia supports FreeBSD.

I have one card with two outputs to my monitors which works just fine. I always say I'm going to plug in my other card to have four monitors but am often too busy.

I always buy bleeding edge hardware. The last time was two years ago for my super galoopin' workstation. I had no issues installing FreeBSD and making anything work.
 
I have no idea, since I don't use xorg or even video cards in my servers.

But a quick stroll through the code in /sys/dev/drm2/radeon/ shows lots of DRM_DEBUG lines, and there does seem to be LVDS support. I think this may be controlled by a sysctl used in /sys/dev/drm2/drm_sysctl.c. I'd suggest doing a # sysctl -a | grep drm or # sysctl -a | grep radeon and see if there are any debug sysctls in there. If there are, try setting them and repeating your tests and see if they produce any debugging output. Thay may lead to further ideas, or at least indicate if the code is detecting your display at all.

Very clever lead, thank you.

Code:
# sysctl -a | grep drm
hw.drm.msi: 1
dev.fbd.0.%parent: drmn0
dev.radeon_iicbb.3.%parent: drmn0
dev.radeon_iicbb.2.%parent: drmn0
dev.radeon_iicbb.1.%parent: drmn0
dev.radeon_iicbb.0.%parent: drmn0
dev.drmn.0.%parent: vgapci0
dev.drmn.0.%pnpinfo:
dev.drmn.0.%location:
dev.drmn.0.%driver: drmn
dev.drmn.0.%desc: ATI Radeon Lf RV250 Mobility 9000 M9 / FireMV 2400 PCI
dev.drmn.%parent:

# sysctl -a | grep radeon
hw.dri.0.name: radeon 0x70 pci:0000:01:00.0
dev.iicbb.3.%parent: radeon_iicbb3
dev.iicbb.2.%parent: radeon_iicbb2
dev.iicbb.1.%parent: radeon_iicbb1
dev.iicbb.0.%parent: radeon_iicbb0
dev.radeon_iicbb.3.%parent: drmn0
dev.radeon_iicbb.3.%pnpinfo:
dev.radeon_iicbb.3.%location:
dev.radeon_iicbb.3.%driver: radeon_iicbb
dev.radeon_iicbb.3.%desc: Radeon i2c bit bus CRT2_DDC
dev.radeon_iicbb.2.%parent: drmn0
dev.radeon_iicbb.2.%pnpinfo:
dev.radeon_iicbb.2.%location:
dev.radeon_iicbb.2.%driver: radeon_iicbb
dev.radeon_iicbb.2.%desc: Radeon i2c bit bus MONID
dev.radeon_iicbb.1.%parent: drmn0
dev.radeon_iicbb.1.%pnpinfo:
dev.radeon_iicbb.1.%location:
dev.radeon_iicbb.1.%driver: radeon_iicbb
dev.radeon_iicbb.1.%desc: Radeon i2c bit bus VGA_DDC
dev.radeon_iicbb.0.%parent: drmn0
dev.radeon_iicbb.0.%pnpinfo:
dev.radeon_iicbb.0.%location:
dev.radeon_iicbb.0.%driver: radeon_iicbb
dev.radeon_iicbb.0.%desc: Radeon i2c bit bus DVI_DDC
dev.radeon_iicbb.%parent:

I'm not able to set a correlation between the output names at xorg.log (VGA-0, S-video, LVDS) and these (CRT2_DDC, VGA_DDC, DVI_DDC). I think I'll have to take a look at the code of the radeon driver to investigate.

On the other hand, I heard that 11.0-RELEASE had some problems and that 11.1 is just around the corner. I wonder if it's best to postpone this.

Concerning xorg at servers, although most of our administering jobs is done by ssh, we usually also also install xorg with openbox and x11vnc server for those seldom jobs that require a GUI.

But, in my case, I would like to start by installing FreeBSD on my MacBook, dual boot with Manjaro OpenRC, to gradually make the transition and expand from there. And, my MacBook Pro has two GPU's, one integrated Intel and one discrete Radeon. I don't use the Radeon at all, it's very power-hungry. So, this problem is probably going to show-up, I didn't try yet, I prefer to use the Fujitsu-Siemems as a Guinea pig.
 
An alternative generic display driver exists in the xf86-video-scfb.

Thank you, doesn't work:

driver.conf:
Code:
Section "Device"
    Identifier  "Card0"
    BusID       "PCI:1:0:0"
    Driver      "scfb"
EndSection

Xorg.0.log:
Code:
[   358.494] (II) LoadModule: "scfb"
[   358.494] (II) Loading /usr/local/lib/xorg/modules/drivers/scfb_drv.so
[   358.494] (II) Module scfb: vendor="X.Org Foundation"
[   358.494]    compiled for 1.18.4, module version = 0.0.4
[   358.494]    ABI class: X.Org Video Driver, version 20.0
[   358.494] (II) scfb: driver for wsdisplay framebuffer: scfb
[   358.495] (--) Using syscons driver with X support (version 2.0)
[   358.495] (--) using VT number 9

[   358.521] (WW) Falling back to old probe method for scfb
[   358.521] scfb trace: probe start
[   358.521] scfb trace: probe done
[   358.521] (EE) No devices detected.

Anyway, vesa is similar, also slow.
 
On the other hand, I heard that 11.0-RELEASE had some problems and that 11.1 is just around the corner. I wonder if it's best to postpone this.
I'm not sure where this story is coming from. I replied to an earlier mention of it in this post. Unless it is happening in near-total secrecy, it is unfounded.

Even if 11.1 was iminent, you could pick up most of the changes by updating your source tree to 11-STABLE and recompiling kernel + world. That isn't as scary as it sounds, though I wouldn't attempt it on a 15-year-old laptop. My servers here do it pretty quickly (kernel: 2.5 minutes, world: 12 minutes), but they're relatively high-end modern systems. The laptop will probably take the better part of a day, if not longer.

Note to others - if you install something other than a -RELEASE version, freebsd-update(8) probably won't know how to update that to a new -RELEASE.
 
If I remember correctly, support for the M9 was dropped out of Xorg some time ago, so you may need to run VESA. What does knoppix say with glxinfo?

My servers here do it pretty quickly (kernel: 2.5 minutes, world: 12 minutes)
... I hate you.
;) not really, looks like a nice outfit. I would hate to pay for it and it's power bills, tough.
 
... I hate you.
;) not really, looks like a nice outfit. I would hate to pay for it and it's power bills, tough.
Dell R710, 2 rack units, 200-ish watts, and I got it for free* out of a dumpster over 3 years ago:

r710-wattage.png


The spikes up to 235W are kernel+world builds.

server-dumpster.jpg


* Over time, I've paid (not much) to upgrade the RAID controller and drives. But everything else (including memory and CPUs) is as it came from the dumpster.
 
I always buy bleeding edge hardware. The last time was two years ago for my super galoopin' workstation. I had no issues installing FreeBSD and making anything work.

I think this deserves some clarification prior to anyone going out and dropping a few C-notes on bleeding edge hardware that they intend to run FreeBSD. As drhowarddrfine said, he uses nVidia video cards. If you prefer Open Source drivers such as intel or ATI/Radeon you will be better served looking at the supported hardware list.
 
Furthermore, as I said, I'm using 11.0-STABLE. Should support AGP, isn't it?
Do keep in mind though that STABLE (and CURRENT) are both snapshot (development) releases, so there's always a possibility that stuff doesn't work due to caveats or bugs instead of incompatibility. Figured I'd mention it because there seem to be quite a few people who approach STABLE as a regular release while in fact it's not.
 
Over time, I've paid (not much) to upgrade the RAID controller and drives. But everything else (including memory and CPUs) is as it came from the dumpster.
Yep! I went for years without having to buy hardware as Windows users "upgraded" their "old" computers and handed me their systems for free. I pointed out a while back that I didn't know if it was the economy or what but no one has given me any free computers lately and that's why I finally broke down and built my own a few years back.
 
Yep! I went for years without having to buy hardware as Windows users "upgraded" their "old" computers and handed me their systems for free. I pointed out a while back that I didn't know if it was the economy or what but no one has given me any free computers lately and that's why I finally broke down and built my own a few years back.
I just got a pair of nice R510's from a colo customer who was un-racking them. The reason? "The PERC batteries reported as failed, and when I called Dell they said the systems were out of warranty, and that made us nervous so we replaced them with new systems."
 
Do keep in mind though that STABLE (and CURRENT) are both snapshot (development) releases, so there's always a possibility that stuff doesn't work due to caveats or bugs instead of incompatibility. Figured I'd mention it because there seem to be quite a few people who approach STABLE as a regular release while in fact it's not.
If you're willing to do a little work, -STABLE is pretty solid. Most of that work is "build kernel + world on a test system, and if there are no errors reboot it and test". If someone breaks -STABLE they're pretty good about responding quickly and going "Oops - my bad - fixed now". That of course means you need to track -STABLE closely enough that you can tell which commit broke it. Tracking -STABLE also means there's a lot less work to do when the next .x release comes along.

The downside (aside from what you mentioned) is that you need to keep your source tree up-to-date, do manual builds, and realize "you can't get there from here" with freebsd-update(8), so you're pretty much committed to the build-it-yourself method of updating.
 
I recently tried to find a use for an old Toshiba laptop (Sat-3000) from the days of Win98. After scrounging around, all I could find were two 128MB SDRAM sticks so only ended up with 256MB RAM. That's great for a server but really minimal if you want to see pictures. I didn't see the OP specify the RAM, but 15 years ago it was but a drop in the bucket compared to modern expectations.
 
Thank you, thank you!

I'm amazed by the amount of people that jumped in to help, one of the best communities I ever met!

Anyway, I decided that FreeBSD is still not for my production machines, mainly the desktops (please don't flame me, I might be wrong). I'll try again later and stick to Manjaro OpenRC for the time being.

Regards,
jss
 
I recently tried to find a use for an old Toshiba laptop (Sat-3000) from the days of Win98. After scrounging around, all I could find were two 128MB SDRAM sticks so only ended up with 256MB RAM. That's great for a server but really minimal if you want to see pictures. I didn't see the OP specify the RAM, but 15 years ago it was but a drop in the bucket compared to modern expectations.

Not that bad, 768MB, enough for Manjaro with Xfce4 anyway.
 
Not that bad, 768MB, enough for Manjaro with Xfce4 anyway.

Well that's a long way from 256MB. However Fluxbox is pretty functional and works with low resources to deliver a nice desktop experience.
 
Back
Top