Last weekend, I had the pleasure of two power outages, one in the early morning and one very late at night. (Damn the wholly unreliable electric utility company in this town.) I woke up the next morning to find one of my boxes had suffered physical disk failure–that lovely grinding sound of a disk head skipping across the surface of the platter. Luckily, the last time something like this happened, I moved everything to a RAID-1 (mirrored) setup as well as performing daily snapshot backups. Everything, except of course, the root filesystem. That remained on a crappy little 1 GB drive and snapshot backups were taken of that daily, too. Of course, the drive that died? The root filesystem.
No problem, I thought. I’ll just yank the drive, replace it with a spare sitting on my desk, restore the backup using a bootable Linux rescue CD, and be back up and running in no time. Well, you guessed it: I restored the root filesystem, wrote the master boot record (MBR) with lilo using the restored lilo.conf … rebooted … and, it wouldn’t boot properly. When trying to boot the initrd, it crapped out with a kernel panic. I futzed with this for a good many hours, trying all sorts of stupidity to try and get it to boot. Finally, I gave up: I downloaded the latest Debian netinst CD image in the “testing” tree and did a fresh install of Debian “etch” beta 3 onto this new disk.
The install went smoothly even though it took a good long time (I only have a 384K SDSL) to install over the net. Once I got the minimal install booting, I started the tedious process of manually restoring files out of the root filesystem by hand. Eventually, I got enough restored and working so that DNS, mail and web services were back online. However, one place I ran into a snag was printing. I couldn’t get LPRng to spool anything to /dev/lp0. This used to work … so, what changed?
Previously, I ran kernels that I configured and compiled myself. This time, I decided to try out a Debian kernel package. The more packages I can run off-the-shelf, the easier it is for me to keep current. So, the symptom of my printing problems looked like this:
$ echo "test" >/dev/lp0
It would just hang there. Looking at /var/log/kern.log, I’d see:
DMA write timed out parport0: BUSY timeout (1) in compat_write_block_pio
Well, this was annoying. After much Googling and searching various bug databases, it seemed that this is a frequently asked question with very few decent answers. Looking at Documentation/parport.txt in the Linux kernel source, it recommends disabling CONFIG_PARPORT_PC_FIFO (which it admits is not a module option but should be) as a step in troubleshooting problems. Looking at the kernel .config for my previous, hand-build kernel, I notice that I had this option disabled. Looking at the Debian kernel image’s .config, I notice they build the kernel with this option enabled.
After disabling CONFIG_PARPORT_PC_FIFO and recompiling my kernel modules, I installed the new parport_pc.ko module and loaded it. As you would have guessed, the printer started working with the newly compiled module. This is what the dmesg looked like with the Debian modules:
pnp: Device 00:09 activated. parport: PnPBIOS parport detected. parport0: PC-style at 0x378 (0x778), irq 7, dma 3 [PCSPP,TRISTATE,COMPAT,EPP,ECP,DMA] parport0: Printer, Canon BJC-8200 lp0: using parport0 (interrupt-driven).
Here is what it looks like after disabling CONFIG_PARPORT_PC_FIFO:
pnp: Device 00:09 activated. parport: PnPBIOS parport detected. parport0: PC-style at 0x378 (0x778), irq 7 [PCSPP,TRISTATE,EPP] parport0: Printer, Canon BJC-8200 lp0: using parport0 (interrupt-driven).
The COMPAT, ECP and DMA are gone, but at least my printer can print again!
I’ve gone and submitted Bug #388309 in Debian BTS. Hopefully, this information will help others with their printing problems, or at least get someone to tell me how else I could fix mine.