Following the upgrade of the hydrus web/mail server to FreeBSD 5.4, the backup server, chrome, also needed upgrading. This operation was made slightly more complicated by the fact that extremely important users (i.e. my family) relied on chrome as a file and print server.
Since /home was used as a backup for a couple of the other
machines on the network, I wanted to preserve this partition across
the upgrade. I therefore re-used the existing partition table,
but ensured that newfs was invoked for all partitions except
/home.
One slightly worrying aspect of the disk setup was that sysinstall told me that the geometry of 119150/16/63 was wrong, and it was using 7476/255/63. The former geometry was exactly the same as that determined by 4.11. I tried using the G option to set the geometry back, but sysinstall always reverted to its preferred figures. I pressed on regardless.
The upgrade continued without problem, and I was able to re-boot
into FreeBSD 5.4, with my original /home partition intact.
However, I did notice the following message on boot (if the printer
was turned on):
Interrupt storm detected on "irq7: lpt0"; throttling interrupt source
Hmm, that never happened in 4.11. I ignored it for now, but I was forced to deal with it sooner rather than later.
I pkg_add'd cvsup-without-gui, and updated the src and
ports trees. I then added the following packages (directly or indirectly):
apache autoconf cmucl compat4x-i386 cvsup-without-gui emacs expat ezm3 gettext gmake libiconv libtool libxml2 m4 perl pkgconfig popt portupgrade procmail py24-libxml2 python rsync ruby ruby18-bdb1 samba
To minimise the number of applications on chrome, I chose to use BSD
printing for Samba, rather than cups as before. By default, Samba
requires cups-base, so I set the following flags in
/etc/make.conf
WITHOUT_CUPS=true WITHOUT_LDAP=true
On testing Samba, I found that printing on the HP LaserJet5N
attached to chrome was weird. The printer's message window showed
"Processing job", then "Ready", then "Receiving Data", then ready,
until, after an inordinate length of time, the document actually
printed. Initially, I wasn't sure if this was caused by the BSD
printing, or related to the interrupt storm message, or some odd 5.4
problem. First, I rechecked the /etc/printcap file; was I
sending a banner or something by mistake?
HPLaserJet5N|HP LaserJet5N:\
:sh:sf:mx#0:\
:lp=/dev/lpt0:sd=/var/spool/output/HP:lf=/var/log/lpd-errs:
No, that looked OK - suppressing header and trailing formfeed. I then added a filter, which tee'd the print data to a file. I then realised the printing was very slow for large files; the interrupt storm must be to blame.
Armed with this information, a quick web search turned up the
solution, from both these now defunct links:
http://www.xs4all.nl/~rsmith/freebsd/ and
http://www.n0dez.com/notes.html.
Add the following to /boot/device.hints:
hint.ppc.0.flags="0x28"
This forces the parallel port to operate in polled rather than
interrupt mode. You can achieve the same effect with lptcontrol
-p. Printing speed was now normal.
