with the fact that, even though I was able to fix the problem of my system hanging after a reboot, I still hadn't figured out why accessing /dev/cuaa0 caused my system to freeze up. Well, I'm happy to report that after many hours and loss of hair, I've been able to identify the problem and get it fixed!
Before I continue, special thanks should go to Mark Staudinger who helped me get this problem fixed after I posted to FreeBSD-hackers@FreeBSD.org. He advised I look in a different place to identify my problem - outside the OS. Here are his comments that got me on track:
"First, let me state that the quickest way I know of to freeze a FreeBSD system is to disable a COM port in the BIOS (COM1, /dev/cuaa0 in your case), and then try to access it in FreeBSD. I found this out on a system with a serial console - I accidentally disabled COM1 in the BIOS, and the thing wouldn't even get past the second stage boot loader. This only applies to a FreeBSD installation with serial ports enabled, and the ports disabled in the BIOS. If the port wasn't configured in the BIOS, you'd just get a "device not configured" message, no freeze."
This is something I hadn't even considered previously and set things in motion to check the status of the serial port in the BIOS.
Before I installed FreeBSD on the Compaq, I remember being able to access the BIOS by hitting F10 at boot up but now, that function had disappeared. I tried rebooting my machine and hitting F10 and every other combination of special function keys but couldn't get into the BIOS as I'd done before the installation. Since I had previous experience reinstalling/upgrading the BIOS on PCs before, I went to www.compaq.com and downloaded the appropriate F10 Setup Utility for my Compaq Deskpro. With this utility, you have the option of creating a set of boot floppies that give you the ability to either access the BIOS from floppy or install it on the same partition as the BIOS. I chose to access the BIOS from the floppy.
After booting from floppy and accessing the pc setup/BIOS, I discovered that the serial port (COM1) had indeed been disabled. You can imagine how relieved and elated I was at this point! After a few slaps up the side of my head and a long sigh of relief, I enabled the serial port, saved my changes and exited.
When Mark first responded, he requested that I send him a printout of my dmesg. Suspecting that he wanted to see if I had any IRQ conflicts, I sent him the printout by issuing the following command: dmesg | grep -i IRQ Here is what it looked like:
ahc0: rev 0x01 int a irq 11 on pci0.2.0
xl0: <3Com 3c905B-TX Fast Etherlink XL> rev 0x30 int a irq 11 on pci0.4.0
vga0: rev 0x03 int a irq 11 on pci0.15.0
atkbd0 irq 1 on isa
psm0 irq 12 on isa
sio0: configured irq 4 not in bitmap of probed irqs 0
sio0 at 0x3f8-0x3ff irq 4 flags 0x10 on isa
fdc0 at 0x3f0-0x3f7 irq 6 drq 2 on isa
wdc0 at 0x1f0-0x1f7 irq 14 on isa
wdc1 at 0x170-0x177 irq 15 on isa
ppc0 at 0x3bc irq 7 flags 0x40 on isa
As you can see, the text in bold indicates that COM1 had either been disabled or set up in some non-standard fashion. Upon seeing this, Mark recommended that when I got into my BIOS, to give the serial port the same address that was listed in my kernel configuration.
After making the appropriate changes to the serial port in the BIOS, this is the message that appeared during reboot:
sio0 at 0x3F8-0x3FF irq 4 flags 0x10 on isa
After rebooting, I wanted to find out if I could successfully connect to my serial port without my system freezing again. I did this with the use of a communication utility called Kermit. Before I discovered the problem with the serial port being disabled, I had tried to use Kermit to connect to the port but ended up freezing my system again. From a terminal window I issued kermit from the command prompt. Then I set the line and line speed with set line /dev/cuaa0 and set speed 2400, respectively. Lastly, I issued connect and used CTRL + \ + s to get a status on the line. This is what I got:
Device: /dev/cuaa0
Speed 2400
Terminal echo: remote
Terminal bytesize: 7
Command bytesize: 7
Parity: none
Autodownload: on
Session log: (none)
Carrier Detect (CD): On
Dataset Ready (DSR): Off
Clear To Send (CTS): On
Ring Indicator (RI): Off
Data Terminal Ready (DTR): On
Request To Send (RTS): On
Elapsed time: 00:02:30
As you can see, I was able to successfully connect to my serial port and get a line status, all without freezing this time!
Now, since I could access my serial port without freezing my system, I could concentrate on installing an application that would allow my system to communicate with my UPS and do a graceful shutdown, in the event of a power outage.
I had previously decided that I wanted a UPS application that was a little more functional than the standard lot and at the recommendation from someone who had responded to a previous post to FreeBSD-questions@FreeBSD.org, I became interested in a suite of small UPS applications called Network UPS tools or NUT, that can be found at http://www.exploits.org/nut/. The NUT suite incorporates useful features like safe shutdowns and live web monitoring. You can also have many systems running different operating systems monitoring a single physical UPS with help from the network communications layer. The software was designed for a variety of UNIX based operating systems including Linux, FreeBSD, NetBSD, OpenBSD, BSD/OS, Solaris and IRIX.
I downloaded and installed the NUT suite and am well on my way towards my goal of getting my FreeBSD system to work with my UPS and provide needed protection in the event of a power outage.
During all of this, I've learned more about my FreeBSD system and have gained valuable experience. I've also learned, that no matter how difficult the problem, not to give up and that, in the end, the fruits of being persistent are many.
