# Returning to FreeBSD after 15 years



## jssilva (Apr 1, 2017)

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:

```
# 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
```


```
$ 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


----------



## drhowarddrfine (Apr 1, 2017)

https://wiki.freebsd.org/Graphics#AMD_.2F_Radeon_Graphics



> Radeon video cards:
> 
> AGP cards not supported before FreeBSD 10-CURRENT
> Features not yet working/implemented:
> ...


----------



## jssilva (Apr 1, 2017)

drhowarddrfine said:


> https://wiki.freebsd.org/Graphics#AMD_.2F_Radeon_Graphics


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?


----------



## Terry_Kennedy (Apr 2, 2017)

jssilva said:


> 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.


----------



## Phishfry (Apr 2, 2017)

An alternative generic display driver exists in the xf86-video-scfb.


----------



## drhowarddrfine (Apr 2, 2017)

jssilva said:


> 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.


----------



## jssilva (Apr 2, 2017)

Terry_Kennedy said:


> 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.


```
# 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.


----------



## jssilva (Apr 2, 2017)

Phishfry said:


> An alternative generic display driver exists in the xf86-video-scfb.



Thank you, doesn't work:

driver.conf:

```
Section "Device"
    Identifier  "Card0"
    BusID       "PCI:1:0:0"
    Driver      "scfb"
EndSection
```

Xorg.0.log:

```
[   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.


----------



## Terry_Kennedy (Apr 2, 2017)

jssilva said:


> 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.


----------



## Crivens (Apr 4, 2017)

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`?



Terry_Kennedy said:


> 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.


----------



## Terry_Kennedy (Apr 4, 2017)

Crivens said:


> ... 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:







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






* 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.


----------



## shepper (Apr 4, 2017)

drhowarddrfine said:


> 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.


----------



## ShelLuser (Apr 4, 2017)

jssilva said:


> 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.


----------



## drhowarddrfine (Apr 4, 2017)

Terry_Kennedy said:


> 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.


----------



## Terry_Kennedy (Apr 4, 2017)

drhowarddrfine said:


> 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."


----------



## Terry_Kennedy (Apr 4, 2017)

ShelLuser said:


> 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.


----------



## drhowarddrfine (Apr 5, 2017)

I got a fairly new car from someone cause the ash trays were filling up and the tires were getting low.


----------



## Terry_Kennedy (Apr 5, 2017)

drhowarddrfine said:


> I got a fairly new car from someone cause the ash trays were filling up and the tires were getting low.







Seriously, I'll stop if you stop, and we can go back to being useful to the original poster.


----------



## Deleted member 9563 (Apr 5, 2017)

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.


----------



## jssilva (Apr 11, 2017)

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


----------



## jssilva (Apr 11, 2017)

OJ said:


> 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.


----------



## Deleted member 9563 (Apr 12, 2017)

jssilva said:


> 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.


----------

