I haven't subscribed to this list in years, because ftape has been solid. Now, ftape has developed a problem, about two months into my installation of a new motherboard. I had been using kernel 2.2.14 during this time, and ftape was fine for about a month. A few days ago I started getting "no polling interrupt". I thought maybe something krept into my motherboard hardware, or something I did to the kernel. I switched back to a 2.2.10 kernel on the same disk, and which I had used for many months. That kernel, and its equally ancient, and previously reliable ftape, also failed. Naturally I thought either the motherboard, or the Conner had developed a problem. To be sure, I booted up with Windows, on the same disk, and tried the Conner Windows Backup Exec. It worked! Backup Exec ran an integrity test, and small backup/restore, and had no problem. Does this mean that ftape is not robust enough to handle parametric changes in hardware? Perhaps the Conner hardware has some mechanical "drift" that ftape cannot compensate for, but the manufacturers driver can? Even if the motherboard is to blame, shouldn't ftape be able to cope as well as Backup Exec? It would be tragic if thousands of naive Linux/ftape users should start experiencing backup failures because of a driver robustness issue. Has anyone else experienced a sudden failure of a tape drive on the Linux/ftape side, and yet had no trouble continuing to use the drive under Windows?
