Date: Fri, 28 Mar 2008 12:17:18 -0400 From: "Isaac Mushinsky" <itz@mushinsky.net> To: freebsd-questions@freebsd.org, freebsd-usb@freebsd.org Subject: Re: hplip setup problems Message-ID: <bbe9e35d0803280917p4b61f46hf3f6dc80505f3d49@mail.gmail.com> In-Reply-To: <200803281142.48595.amistry@am-productions.biz> References: <200803260021.12249.itz@mushinsky.net> <200803271037.48833.amistry@am-productions.biz> <200803280358.58236.itz@mushinsky.net> <200803281142.48595.amistry@am-productions.biz>
next in thread | previous in thread | raw e-mail | index | archive | help
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@am-productions.biz> wrote: > On Friday 28 March 2008, you wrote: > > On Thursday 27 March 2008 10:37:48 you wrote: > > > 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@am-productions.biz > > > > > 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? > You could try to call sleep() to see if that fixes it. > man 3 sleep > > > -- > Anish Mistry > amistry@am-productions.biz > AM Productions http://am-productions.biz/ >
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?bbe9e35d0803280917p4b61f46hf3f6dc80505f3d49>