Re: hplip setup problems
- From: "Isaac Mushinsky" <itz@xxxxxxxxxxxxx>
- Date: Fri, 28 Mar 2008 12:17:18 -0400
Yes, of course sleep() works. But I am looking for the *proper* way to fix
it.
My questions at this point are:
1. Does USB standard permit these sequential requests, or there should be
some reset/synch mechanism utilized in between? I could also usb_close() and
reopen the device, but is there a softer reset than that? Is the bug really
in hplip, or libusb, or sys/dev/usb?
2. If the driver, libusb and hplip are acting properly, then perhaps the
race condition is inside the device? i.e. it should be ready to accept the
second control msg after the 1st one returned, but for some reason is not
really ready. So then it is the printer that violates the protocol, and
there is nothing to do on our side but sleep(). Or usb_close(), and reopen,
hopefully that will bring the Photosmart to its senses.
I am posting this to freebsd-usb as well, people there are probably better
equipped to answer this.
On Fri, Mar 28, 2008 at 11:42 AM, Anish Mistry <amistry@xxxxxxxxxxxxxxxxxx>
wrote:
On Friday 28 March 2008, you wrote:_______________________________________________
On Thursday 27 March 2008 10:37:48 you wrote:You could try to call sleep() to see if that fixes it.
On Thursday 27 March 2008, Isaac Mushinsky wrote:
Anish Mistry (the port maintainer) has answered below. It seems
that this is a printer defect after all then. I'll try to patch
the code to fill in the missing serial id with some fake
string, and shall report if I get the thing to work.
Is the hp backend the only entry point to libusb, or should I
have to patch libusb? e.g. cups or sane apps, can they call
libusb directly, or only through hpaio backend? I would rather
have a patch to hplip distribution only, because libusb
correctly throws an error code for the missing serial id. But
if some apps query the device directly, the missing serial id
may be a problem, they will all have to all be patched
separately.
See what you can get to work, and then we can decide on what the
proper fix entails.
It looks like there is some problem with the C42XX printers
that is causing the serial numbers to no be reported. I got
a similar report about a HP Photosmart C4200 series a couple
weeks ago. Unfortunately I'm VERY busy right now. It will be
a couple of week before I can dive into the issue. If you do
happen to find a solution, please let me know so I can
integrate it into the port and notify others. Thanks,
--
Anish Mistry
amistry@xxxxxxxxxxxxxxxxxx
AM Productions http://am-productions.biz/
I tried to load hplip into debugger, but if I try to trace the
problem, it works! Serial number is read correctly. It also seems
to work with a non-SMP kernel (at least the race does not show).
The printer has the serial number after all.
There appears to be some sort of race condition when calling
usb_control_msg for product id and then serial id strings in rapid
succession in musb.c. I am not sure how to deal with that yet, but
pausing in between the calls is a workaround for now. What can be
done in between the calls other than close and reopen the device?
man 3 sleep
--
Anish Mistry
amistry@xxxxxxxxxxxxxxxxxx
AM Productions http://am-productions.biz/
freebsd-questions@xxxxxxxxxxx mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-questions
To unsubscribe, send any mail to "freebsd-questions-unsubscribe@xxxxxxxxxxx"
- References:
- hplip setup problems
- From: Isaac Mushinsky
- Re: hplip setup problems
- From: Anish Mistry
- Re: hplip setup problems
- From: Isaac Mushinsky
- hplip setup problems
- Prev by Date: Re: Understanding Flags, Refs, Use, Expire in Routing Table
- Next by Date: Re: Permission to publish article
- Previous by thread: Re: hplip setup problems
- Next by thread: Re: hplip setup problems
- Index(es):
Relevant Pages
|
