Does this sound familiar at all?
On a squeeze installation, there is a usb scanner. Works just fine. But for unclear reasons every now and then, it may be because someone plugs in another computer to the usb hub to print, not quite sure, when xsane starts up it gives the usual message about not being able to start the scanner.
I fix this by brute force, I start up a demo copy of vuescan, after which all is well again. But I have no idea why this should work.
However, on another machine running Lenny, this did not work. Vuescan could now not find the scanner. Also (this is an MFP) I was unable to get the printer to work. I had downloaded the drivers (its a Brother) and installed them using gdebi.
So, I tackled the scanner problem first. sane-find-scanner found it, and scanimage -L also found it. Attempting to scan from the command line did not.
Running short of time, this was a friends machine, I took the brute force approach again and installed Mandriva 2010. Got the drivers, installed them, and bingo, everything works fine. Must say, this was wonderfully easy, all the bookmarks and the toolbar configuration came up intact. Could not have been easier. Mandriva will be easier for him to run, at least, until we want to upgrade it.
But, what on earth could be going on?
Peter
Peter Alcibiades wrote:
Does this sound familiar at all?
On a squeeze installation, there is a usb scanner. Works just fine. But for unclear reasons every now and then, it may be because someone plugs in another computer to the usb hub to print, not quite sure, when xsane starts up it gives the usual message about not being able to start the scanner.
I fix this by brute force, I start up a demo copy of vuescan, after which all is well again. But I have no idea why this should work.
I have seen similar things before (although not for a while) where different (or windows) drivers can put hardware into a "funny" state that the linux drivers cannot cope with. Maybe vuescan and the sane version that ships with mandriva can cope with this but whatever ships with debian can't.
It used to happen to me in the old days when I dual booted and (iirc) my soundcard. To go from windows to linux I had to powercycle the machine, a warm boot wouldn't cut it because the windows drivers did something to the state of the card.
Did you get to see what happened if you powercycled the MFP (not just a soft power off) ?
On Wed, Nov 18, 2009 at 01:06:22AM +0000, Peter Alcibiades wrote: [snip long tale of woe about USB scanner]
But, what on earth could be going on?
In my experience it's just par for the course when using USB. Many of my current issues and problems with computers seem to be with USB devices. Often it's trying to get VirtualBox to handle a USB device and other such things. I've also found that a USB to ethernet adapter just fails to work completely in Linux.
USB is inevitably complex because there are so many possible 'things' that can be plugged in. Mass storage devices are handled pretty well because they're so common but the moment you move away into other sorts of devices things become less certain.
Lots of the issues on the linux-usb list were down to devices which didn't follow the rules but had bodged windows drivers so that they work successfully with MS-Windows. The changes and patches to the Linux USB drivers were adding code to work around these bodges for each specific device.
Chris G wrote:
In my experience it's just par for the course when using USB. Many of my current issues and problems with computers seem to be with USB devices. Often it's trying to get VirtualBox to handle a USB device and other such things. I've also found that a USB to ethernet adapter just fails to work completely in Linux.
USB is inevitably complex because there are so many possible 'things' that can be plugged in. Mass storage devices are handled pretty well because they're so common but the moment you move away into other sorts of devices things become less certain.
I'm not sure that is the specific cause of the problem. There are plenty of other interfaces that have a similar selection of device types or devices on other interfaces that present the same issues.
Most of the issue I think is due to more intelligence being put into the driver rather than the device itself. The unit cost of adding some code to the driver once vs adding a chip to each device means that no longer are we looking at simple data in - data out.
Now the driver can be performing device initialisation routines, loading up the device firmware (rather than it being in ROM on the device), performing error correction and status monitoring. Winmodems were an early example.
Of course this doesn't do OSS any favours because now it is more likely that technical advantages between one product and a competitor can be in the drivercode rather than hidden in the device itself. Consider a printer from company X that prints photos better than company Y's device because of some cleverness in the dithering algorithm. Now with printers where the dithering is done by the print driver there would be an issue in releasing an open driver with the same functionality as the closed one.
This is probably more prevailant on USB simply because generally we are looking at a cheaper selection of devices that have limitations (if bus powered) on how much they can actually do on circuit. Host CPU cycles are cheap (to the device manufacturer) and plentiful on modern computers so it is inevitable that the driver ends up doing more than just being a device interface.
Lots of the issues on the linux-usb list were down to devices which didn't follow the rules but had bodged windows drivers so that they work successfully with MS-Windows. The changes and patches to the Linux USB drivers were adding code to work around these bodges for each specific device.
Well the thing is there are no "rules" beyond electrical and physical characteristics. Sure there are generic models for say mass storage or USB printing or input devices but nothing says that anyone has to implement them 100%, or even at all.
So it is natural that the implementation is only taken up to the point it needs to be for the device to work on the supported platforms or if a device bug is found it is coded around in the driver. The reason that mass storage tends to "just work" is that it is preferable that the devices work on any machine without driver installation due to their nature of being used to transfer data between machines.
-
Chris G -
Peter Alcibiades -
Wayne Stallwood