hpoj-devel

Re: [hpoj-devel] (Unofficial patch) 2nd patch to hpoj for 2.4

[<pa...@rc...>]

da...@cy... said:
> I'm sorry everybody but Burkhard's new patch didn't make its way into
> my mailbox when I posted mine. 

My bad.  The mailing list was configured not to allow postings greater than
40KB.  I didn't check my e-mail until later in the day, when I found the
notices about both of your messages' getting held for approval.  Sorry about
that!  For now it's set to "unlimited".

Many thanks to both of you for working on these problems.  Since I have
neither 2.4 (yet) nor SMP, let me know when you think it's stable and I'll
do some testing with 2.2 and put out another release.

BTW, there is still another problem with the kernel drivers which causes
more-or-less random lockups of the client process, for example, when doing
a large scan.  If you're able to do anything about that or even just have
any ideas on what could be causing it, it would be much appreciated too.  :-)

David

Re: [hpoj-devel] (Unofficial patch) 2nd patch to hpoj for 2.4

[DG <dg...@um...>]

>BTW, there is still another problem with the kernel drivers which causes
>more-or-less random lockups of the client process, for example, when doing
>a large scan.  If you're able to do anything about that or even just have
>any ideas on what could be causing it, it would be much appreciated too. 
:-)

I've spent a little time reaquainting myself with the code, and I think I
can take a shot at this.  Fortunately (maybe), it hangs reliably with
debugging turned on, suggesting a timing issue (interrupt scheduling
conflicts maybe?).

I want to start with a small scan like maybe 'scanimage --test', but I don't
know how the protocol works.  How can I find out what the data exchange
should look like between the driver and scanner during a scan?  Something
like a step-by-step explanation would be best.  A dump of the incoming and
outgoing data would also help.  Then I can compare what I'm getting with
what I should be getting and hopefully find out where the error is creeping
in.

ZZZ-dgun-ZZZ-@-ZZZ-umpire.com-ZZZ
(Remove the Z-'s to reply)
______________________________________________
FREE Personalized Email at Mail.com
Sign up at http://www.mail.com/?sr=signup

Re: [hpoj-devel] (Unofficial patch) 2nd patch to hpoj for 2.4

[Burkhard K. <bu...@bu...>]

DG
> >BTW, there is still another problem with the kernel drivers which causes
> >more-or-less random lockups of the client process, for example, when doing
> >a large scan.  If you're able to do anything about that or even just have
> >any ideas on what could be causing it, it would be much appreciated too. 
> :-)
> 
> I've spent a little time reaquainting myself with the code, and I think I
> can take a shot at this.  Fortunately (maybe), it hangs reliably with
> debugging turned on, suggesting a timing issue (interrupt scheduling
> conflicts maybe?).
Are we talking about the driver compiled under 2.2 or 2.4?
I know we have a timing issue under 2.4 and I hope it is related 
to changes in the underlying parport layer. 

Under 2.4 the driver becomes somehow  sluggish without debugging 
turned on (sic!) - which means that the overall reaction becomes
faster if some loops slow down.

-- 
Burkhard Kohl			buk at/auf buks.ipn.de

Re: [hpoj-devel] (Unofficial patch) 2nd patch to hpoj for 2.4

[<pa...@rc...>]

> >BTW, there is still another problem with the kernel drivers which causes
> >more-or-less random lockups of the client process, for example, when doing
> >a large scan.  If you're able to do anything about that or even just have
> >any ideas on what could be causing it, it would be much appreciated too. 
> :-)
> 
> I've spent a little time reaquainting myself with the code, and I think I
> can take a shot at this.  Fortunately (maybe), it hangs reliably with
> debugging turned on, suggesting a timing issue (interrupt scheduling
> conflicts maybe?).
> 
> I want to start with a small scan like maybe 'scanimage --test', but I don't
> know how the protocol works.  How can I find out what the data exchange
> should look like between the driver and scanner during a scan?  Something
> like a step-by-step explanation would be best.  A dump of the incoming and
> outgoing data would also help.  Then I can compare what I'm getting with
> what I should be getting and hopefully find out where the error is creeping
> in.

Hi, Daniel.  There is a little section at the end of SCAN-HOWTO telling how
to turn on debug output for the SANE HP backend and for PTAL:
>        export SANE_DEBUG_HP=128
>        export PTAL_DEBUG=2
You'll probably want to have HP's SCL documentation handy (available from
http://www.hp-developer-solutions.com, free registration required).  If you
want you can e-mail the output to me (pa...@rc..., not the mailing
list) and I'll take a look at it too.

After I wrote that last paragraph I re-read your question and realized I
didn't answer it.  :-)  It sounds like you're wanting debug output from
some successful runs.  "scanimage --test" may work OK for you (try it and
let me know if even that gives you trouble).  Let me know exactly what
operations you want debug output for and I'll send it to you.

David

Re: [hpoj-devel] (Unofficial patch) 2nd patch to hpoj for 2.4

[DG <dg...@um...>]

From: pa...@rc... (David Paschal)
> > I want to start with a small scan like maybe 'scanimage --test', but I
don't
> > know how the protocol works.  How can I find out what the data exchange
> > should look like between the driver and scanner during a scan? 
Something
> > like a step-by-step explanation would be best.  A dump of the incoming
and
> > outgoing data would also help.  Then I can compare what I'm getting with
> > what I should be getting and hopefully find out where the error is
creeping
> > in.
>
> Hi, Daniel.  There is a little section at the end of SCAN-HOWTO telling
how
> to turn on debug output for the SANE HP backend and for PTAL:
> >        export SANE_DEBUG_HP=128
> >        export PTAL_DEBUG=2
> You'll probably want to have HP's SCL documentation handy (available from
> http://www.hp-developer-solutions.com, free registration required).  If
you
> want you can e-mail the output to me (pa...@rc..., not the mailing
> list) and I'll take a look at it too.
>
> After I wrote that last paragraph I re-read your question and realized I
> didn't answer it.  :-)  It sounds like you're wanting debug output from
> some successful runs.  "scanimage --test" may work OK for you (try it and
> let me know if even that gives you trouble).  Let me know exactly what
> operations you want debug output for and I'll send it to you.

Yes, that's what I want.  Rather than 'scanimage --test', I'll start with
something simpler.  Using the 'ptal-connect -scan' command, what are the PCL
commands to scan a single line?  I'll start there and then move up to
'scanimage --test' when I (hopefully) figure out how the ptal commands are
handled by the ieee12844 modules.

--
Daniel
ZZZ-dgun-ZZZ-@-ZZZ-umpire.com-ZZZ
(Remove the Z-'s to reply)
______________________________________________
FREE Personalized Email at Mail.com
Sign up at http://www.mail.com/?sr=signup

Re: [hpoj-devel] (Unofficial patch) 2nd patch to hpoj for 2.4

[DG <dg...@um...>]

From: Burkhard Kohl <bu...@bu...>
>DG
>> >BTW, there is still another problem with the kernel drivers which causes
>> >more-or-less random lockups of the client process, for example, when
doing
>> >a large scan.  If you're able to do anything about that or even just
have
>> >any ideas on what could be causing it, it would be much appreciated too.
>> :-)
>>
>> I've spent a little time reaquainting myself with the code, and I think I
>> can take a shot at this.  Fortunately (maybe), it hangs reliably with
>> debugging turned on, suggesting a timing issue (interrupt scheduling
>> conflicts maybe?).
>Are we talking about the driver compiled under 2.2 or 2.4?
>I know we have a timing issue under 2.4 and I hope it is related
>to changes in the underlying parport layer.

Compiled under 2.2.17 to be exact.  I haven't tried other kernels.

>Under 2.4 the driver becomes somehow  sluggish without debugging
>turned on (sic!) - which means that the overall reaction becomes
>faster if some loops slow down.

--
Burkhard Kohl			buk at/auf buks.ipn.de
_______________________________________________
hpoj-devel mailing list
hpo...@li...
http://lists.sourceforge.net/mailman/listinfo/hpoj-devel

--
Daniel
ZZZ-dgun-ZZZ-@-ZZZ-umpire.com-ZZZ
(Remove the Z-'s to reply)
______________________________________________
FREE Personalized Email at Mail.com
Sign up at http://www.mail.com/?sr=signup

Re: [hpoj-devel] (Unofficial patch) 2nd patch to hpoj for 2.4

[Burkhard K. <bu...@bu...>]

DG
> From: Burkhard Kohl <bu...@bu...>
> >DG
> >> I've spent a little time reaquainting myself with the code, and I think I
> >> can take a shot at this.  Fortunately (maybe), it hangs reliably with
> >> debugging turned on, suggesting a timing issue (interrupt scheduling
> >> conflicts maybe?).

Daniel, could you please try out different debugging levels for ieee12844.o?
That way we might have a chance to narrow down the problem. This module
uses some weird combinations of 0x01, 0x02, 0x04 and 0x05 debug values 
with 0x02 being the most common. Which values do hang the module? What
about turning on debugging on the ieee12844pp module. If you have some
debug output which you think might be hintful (is that an english word?)
please send it to my private mail address (and maybe damcha's - is that
ok?).

Another point. Under some circumstances (2.4) I have an extreme latency
before scanning starts - did you ever tried waiting for 30 secs?

Burkhard

-- 
Burkhard Kohl			bu...@bu...