Hi, Joe. I looked at the debug log you sent me, but I didn't see anything
out of the ordinary. I was looking for a line that said "mlcpp_intr ERROR"
(with some stuff before and afterwards), and one should see that even if
debug messages are turned off.
Joe Piolunek wrote:
> I rebuilt xojpanel with sleep(6); between the calls that retrieve the
> LCD messages. My script then started/killed it with 'sleep 12'
> between the execute and kill commands. It still failed to start 9
> times out of 250. That was without any extra ieee12844pp.o options.
Could you forward me this script? It's possible that I could duplicate this
myself given a large enough sample size. Now that I think about it, I seem
to recall having intermittent trouble like this, although I think I had to
reload the drivers to make it work.
> > I'm not sure why you couldn't add a delay between lines 1 and 2. Did you
> > try calling sleep(5 seconds or whatever) in between the two line requests
> > in getPrinterLCDMessages?
> We might have been having a misunderstanding. Maybe it was only me.
>
> The sleep() call did cause a delay when I finally tried to introduce one. It
> didn't prevent the no-start problem though.
This delay was in the context of my question about what happens if the poll
timer pops more often than the peripheral is able to keep up, not about the
"no start" issue.
(regarding the latest CVS code)
> The xojpanel "start failures" still occur. I tried connecting the
> OfficeJet to the MB-based port instead of the IO card, but there was
> no improvement. Rebooting or reinserting the ieee12844 modules has no
> effect either.
I'm not surprised, since I didn't change anything that would have fixed it.
I'll try to look into it this week, but I need to release 0.7 by the beginning
of next week or I won't have another chance until January.
> The cause of the problem seems to have been introduced after hpoj-0.5.
> As a test, I inserted the ieee12844 modules from the 0.5 release. The
> no-start problem then disappeared. In /var/log/messages (using
> debug=1), lines containing "Got device ID string" are definitely
> related to the problem. One such message occurs for each failure to
> execute.
So you're saying you see this problem even in 0.6, but never in 0.5? That
is good to know, since it narrows down the culprit. The only kernel-level
change I made in 0.6 that I can think of that could cause a problem is the
"udelay(RESET_DELAY)" calls I added to ieee12844pp.c to make the LaserJet
1100A work. You could try commenting them out of s_resetting() and see if
that makes the problem go away.
David
|
