-
Notifications
You must be signed in to change notification settings - Fork 464
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
kernel error codes are possible dropped for usb devices #617
Comments
CUPS.org User: mike Hmm, yes, well, this should only happen if another process has the USB device open (e.g. two printers pointing at the same port) so it isn't a critical issue, but perhaps we could keep retrying until the printer was found (and maybe only if we get EBUSY for one or more device files?) |
CUPS.org User: mike Please try the attached patch and let me know how this works for you... |
CUPS.org User: mike Fixed in CVS - the anonymous CVS repository will be updated at midnight EST. |
"str617.patch": Index: usb.cRCS file: /development/cvs/cups/backend/usb.c,v
- sprintf(device, format, i);
/*
- sprintf(device, "/dev/usb/printer%d", i);
- did.addr = device_id;
- device_uri, sizeof(device_uri));
/*
|
Version: 1.1.20
CUPS.org User: kssingvo.suse
I see a problem in file backend/usb.c under Linux.
What happens, if "usb://Samsung/ML-1650" is used as Device-URI
and your printer is busy, because he is actualy printing?
In function open_device() all 16 devices are scanned. If one of
them is open'able, then an ioctl() for identificiation is done.
Otherwise, which is the more import part here and if the kernel
returns an EBUSY for open'ing corresponding device, all other
device nodes are scanned for this printer name. As it couldn't been
opened (= not found) and after 16 failed tries in the for()-loop
the errno is overwritten (set) to ENODEV (this is the critical part).
Then the main()-loop stops, because EBUSY isn't found, and sets printer state to disabled.
The same problem could happen for ENXIO, EIO, and possibly ENOENT.
I don't know a good solution here, but I see a (theoretical)
problem if device is named "usb://printer/model". I never tested
this part, neither heard problems regarding this.
The text was updated successfully, but these errors were encountered: