[prev in list] [next in list] [prev in thread] [next in thread] 

List:       freebsd-hardware
Subject:    device puc issues silo overflow errors when port is closed (fwd)
From:       "J. Seth Henry" <jshamlet () comcast ! net>
Date:       2003-05-16 14:25:50
[Download RAW message or body]

I attempted to submit this, but apparently the fact my system is behind a
NAT is causing problems. It was rejected because my host name wasn't
found. Since the web interface is down, could someone else post this bug
report for me?

Thanks,
Seth Henry

> Submitter-Id:	current-users
> Originator:	J. Seth Henry
> Organization:	Private user
> Confidential:	no
> Synopsis:	device puc issues silo overflow errors when port is closed
> Severity:	serious
> Priority:	medium
> Category:	i386
> Class:		sw-bug
> Release:	FreeBSD 4.8-RELEASE i386
> Environment:
System: FreeBSD alexandria.gambrl01.md.comcast.net 4.8-RELEASE FreeBSD 4.8-RELEASE \
#4: Sat Apr 26 23:30:25 EDT 2003 \
root@alexandria.gambrl01.md.comcast.net:/usr/src/sys/compile/alexandria i386

System in question is an VIA EPIA board running a 933MHz C3 Eden processor. This \
board has one RS232 port (sio0), and one CIR/FIR port (sio1). I have disabled the \
onboard sio1 in the kernel due to the lack of hardware support.

Since the system was intended to be a home automation controller, a SIIG 4S \
low-profile PCI 4-port serial board was installed. This board uses the cyber8000 \
chipset, and is operated by the puc device driver.

There is an APC SmartUPS attached to port 1/sio1, a CM11A on port 2/sio2, and an \
AprilAire 8870 thermostat on sio3. All three devices can send data unitiated. Port \
4/sio4 is not attached to anything.

> Description:

The puc device driver appears to issue silo overflow errors if a device is physically \
attached to a port, but there is no software agent "listening" to the port.

I discovered this while setting the system up after the initial install, as the \
devices were physically attached before the software had been fully installed. I \
noted a large number of silo overflow errors on the console while installing the \
software, so many that I had to switch to a secure shell connection on another system \
to get any work done. I also noticed that the silo overflow errors only appeared on \
ports that had devices attached, but that the controlling software hadn't been loaded \
yet. Since I installed the hardware first, and went back later and configured the \
software, I started out getting silo overflow errors for sio1,2, anda 3 - but not 0 \
or 4 (0 being the built-in com port, and 4 being unpopulated)

As I started loading the daemons for these devices, the silo errors went away for \
those ports. i.e. After installing upsd, I quit getting silo overflows on sio1, and \
likewise, when I installed the thermostat daemon, I quit getting them on sio3. Heyu, \
a CM11A listener daemon, cleared up sio2.

Later, after a reboot, I discovered heyu wasn't being loaded when silo overflow \
errors started occuring on sio2 again. Like clockwork, starting the daemon stopped \
the errors. Also, the errors don't appear to be related to system load. All of this \
occured before the system software was fully installed, so the load average was near \
0.0. Later, while compiling a new kernel, the load average rose to 0.6 ~ 0.8 - and \
the silo overflows didn't reappear.

NOTE 1: In the process of ironing this out, I added the PUC_FASTINTR, and \
PCI_ENABLE_IO_MODES options to my kernel. I did not attempt to install the bug fix \
mentioned in pr40636, as I have determined that the SIIG card is not sharing an \
interrupt with anything else. (it's all by itself on IRQ 12)

NOTE 2: All of the software involved was set to open /dev/cuaa(0-4). In most cases, a \
symlink was used. (i.e. /dev/statnet -> /dev/cuaa3)

This isn't critical per-se, as it doesn't cause data loss, but it does result in a \
very full syslog. My syslog rolled over 8 times in the space of a day due to the \
messages. (I was in the 22000 times neighborhood within a day). Due to the heavy load \
on syslog, and the fact that other messages are obscured in the white-out, I marked \
this bug as serious.

> How-To-Repeat:

To repeat this, install a serial device that transmits data on its own (such as the \
CM11A, a modem set to auto-answer, etc), but don't open the port in FreeBSD. As the \
device sends data, silo overflow errors will show up in dmesg for that port, and that \
port only. Start up minicom/tip/whatever, and open that port. The silo overflow \
messages will stop. Unload the program, and they will start again.

> Fix:

I'm not a kernel hacker by any means, but it seems that the puc driver should either \
ignore or supress FIFO warnings when the port isn't "opened".


[prev in list] [next in list] [prev in thread] [next in thread]