I repaired a broken Black Box KV9316A 16-port KVM-over-IP switch through replacing electrolytic capacitors and an internal battery. The short story is that a manufacturer of several internal logic boards used cheap “TRec” electrolytic capacitors which failed with high ESR, and the manufacturer of the power supply unit used a cheap “SWC” electrolytic capacitor which failed open, causing a voltage drop under load. The long story follows.
Repair APC Back-UPS XS 1500 that doesn’t charge or turn on
July 23rd, 2016Here is a quick guide to repairing this UPS that suddenly won’t charge or turn on (mine would ‘chirp’ and do nothing). I will assume that you have checked the battery voltage and that it is good (26 volts or more for 2 batteries connected in a pack in series).
July 2023 update: Several 10uF 35V SMD capacitors failed with high ESR and one failed open circuit (C49). Several 4.7uF 25V SMD capacitors also now have high ESR. Based on this observation, I would recommend simply replacing all the SMD capacitors rather than fixing “only what’s broken”.
The problem more likely than not is the five 22uF 16V SMD electrolytic capacitors. There are four near the middle of the mainboard and one near the LED at the edge. The first thing I did, as usual when dealing with a spontaneous electronics failure, was to go over all the capacitors. When I tested the 22uF capacitors with an ESR meter, they read anywhere from tens of ohms to infinite resistance. I went over the rest of the SMD capacitors and they generally read from 1 to 5 ohms. So the 22uF caps were the outliers. Corroborating this theory were posts on forums about other similar small business models, Back-UPS RS 1500, Back-UPS RS 800, and APC Back-UPS RS 800 overload problem with no load: Solved indicating that the 22uF SMD capacitors were frequently at fault.
Notes on repairing a blown OCZ ModXStream Pro PC power supply
July 2nd, 2016A little while ago, this power supply that I purchased in 2011 blew up and in doing so, tripped the building breaker it was connected to through the APC Smart-UPS 1000 it was connected to. With a little work, I was able to repair it.
There were some mistakes in the design, resulting in what appears to be planned obsolescence judging from the recent barrage of customer reviews complaining about failures, but this series of OCZ power supplies (including 500W, 600W and 700W units) are of reasonable quality (using presumably authentic Teapo capacitors, with the exception of the questionable main filter capacitor) and should last quite a few more years.
This repair diary including partial schematic and this message board thread give the basic background on the failure mode and repair. If your model is one which has an internal fuse like mine, you are probably in luck as the blown fuse prevented further damage. Otherwise, you have more components to check and likely more work to do.
Help! My pre-UVC USB webcam doesn’t actually work on the Web!
April 23rd, 2016I encountered a bit of trouble using an old Creative Webcam 3 USB with a website that wanted to capture video from it. This camera uses an OmniVision OV511+ controller and had never been any trouble to use even with Linux. However, attempting to use it via the browser produced a message that access to the camera was denied.
The first thing to check was permissions on the /dev/video0
device. I found that the user was not in the video
group that was required to access the device by default. However, granting this permission and restarting the login session was still not enough.
It turns out that a characteristic of the USB Video Class (UVC) standard is that only video frames with certain pixel encodings can be generated by compliant devices. Whether due to this narrow scope or for other reasons, the WebRTC standard, which provides access to cameras via HTML5-compliant web browsers, only incorporated support for a relatively small number of pixel encodings, and browsers using the WebRTC library therefore only implement support for, at most, that subset of possible pixel encodings.
For example, Chrome (and any other browser which uses the WebRTC library) only supports decoding just a handful of the dozens of raw pixel formats, many vendor-specific, that are supported by the Video4Linux2 API.
Unfortunately, one of those vendor-specific pixel formats that is not supported by the WebRTC layer is the O511
pixel format generated by the OV511+ chip in the Creative Webcam 3 USB. This can be confirmed like so:
$ lsusb
Bus 001 Device 010: ID 05a9:a511 OmniVision Technologies, Inc. OV511+ Webcam
$ v4l2-ctl --all -d /dev/video0
[..]
Format Video Capture:
Width/Height : 640/480
Pixel Format : 'O511'
Okay, so what can be done? Fortunately, V4L2 developers provided a compatibility wrapper that will convert frames from esoteric pixel formats on-the-fly to the much more widely supported BGR42/YUV420 pixel formats. The wrapper is loaded using LD_PRELOAD
before the browser is launched, e.g:
$ LD_PRELOAD=/usr/lib/libv4l/v4l2convert.so firefox
$ LD_PRELOAD=/usr/lib/libv4l/v4l2convert.so chromium-browser
If your distribution is multiarch, the library will be under /usr/lib/x86_64-linux-gnu
or similar.
Solve WordPress FeedWordPress and Broken Link Checker Plugin Errors
January 1st, 2016I ran into the following problems while helping with a friend’s WordPress blog.
- The FeedWordPress plugin, when updating a feed (either scheduled or on demand), would throw an XML parser error.
Feed Error: [http://abc.com/feed/rss/] update returned error: This XML document is invalid, likely due to invalid characters. XML error: Attribute without value at line 37, column 42
If I fetched the same feed URL in a browser or with wget
, it worked and produced a valid XML file (also, one that had far fewer than 37 lines). Mystery! Also,
- The Broken Link Checker plugin shows a “403 Forbidden” in the Status column for some webpage, http://abc.com/page.html.
But again, if I fetched the same supposedly failing URL by other means, there was no problem.
So, how could I find the cause?
Read the rest of this entry »
Strange behavior of “Allow IF(eth0)” directives in cupsd.conf
December 23rd, 2015When configuring access controls for <Location>
sections in the CUPS daemon configuration file cupsd.conf
, one might notice the following in the man page cupsd.conf(5)
:
DIRECTIVES VALID WITHIN LOCATION AND LIMIT SECTIONS The following directives may be placed inside Location and Limit sections in the cupsd.conf file: [..] Allow @IF(name) [..] Allows access from the named hosts, domains, addresses, or interfaces. The Order directive controls whether Allow lines are evaluated before or after Deny lines.
On a multi-homed box, one might then be tempted to use this Allow @IF(name)
directive as e.g. Allow @IF(eth0)
, further assuming that any requests received on that interface will be allowed in the context of the associated Location
section.
Unfortunately, that is not how it works. How it actually works: Each incoming request is checked to determine whether it is on the same IP subnet as the interface named in the @IF
directive! This means that requests routed from another network, or even requests from directly attached hosts configured for a different subnet, will be mysteriously rejected by this directive, and with no real useful message in the log to find out that it was this rule that failed.
So don’t use this directive unless you know exactly what you’re doing. It’s misleading and practically undocumented.
systemd, CUPS, and /var/run/cups/cups.sock refusing connections
December 23rd, 2015I was debugging a strange problem with a printer server running CUPS the other day. The web admin interface (which executes the script /usr/lib/cups/cgi-bin/admin.cgi
via CGI) was returning a 500 “Internal Server Error”, while running lpadmin
or lpstat
would return Bad file descriptor
. Using strace
on the script locally on the server, it could be seen that the attempt to connect to the control socket /var/run/cups/cups.sock
was failing with ECONNREFUSED
. Huh? Seems like CUPS forgot about the socket, so issue service cups restart
. Well, that didn’t fix it either.
To make a long story short, when running with systemd, the /lib/systemd/system/cups.socket
control file causes systemd itself to own the socket, and to pass it to CUPS inetd
-style when the CUPS process is created. Unfortunately, if that socket gets into a bad state, it will be impossible to communicate with the CUPS child process of systemd through the socket.
# systemctl restart systemd.socket
# service cups restart
The socket will be refreshed and the newly working socket will then be passed to the CUPS child process when it is re-created.
Recovering from a nasty BTRFS meltdown on an AFS fileserver
December 4th, 2015A few years ago I was the victim of a bug in Btrfs which resulted in total inability to mount two Btrfs volumes containing AFS ‘vice’ partitions (partitions containing AFS file data, named and laid out as AFS ‘vnode’ structures). It took a while, but I was able to recover the vast majority of the data with only minor corruption. Here are my notes that might help someone in a similar situation.
Read the rest of this entry »