Re: [hpoj-devel] 2.4 kernel issues

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

David Paschal
> It looks like it failed during the termination phase (event 23) of getting
> the device ID string (do_neg(mode=0x04)), which is before it even attempts
> to change the ECR.  The problem might have to do with the polling-timer
> changes, because when it's waiting for a signal response from the
> peripheral, it spins in a poll loop for a bit, then reschedules itself
> in the task queue, which as you discovered has been changed.

I think the debug messages were a bit misleading. I resolved this
to be a failure during the transmit mode negotiation phase due 
to the parport being set to reverse mode. This can be cured by
inserting a 
	parport_data_forward(l->port);
statement just before the 
	parDataWrite(l, ...);
statement of event 0. (or inside the parDataWrite() function call).

It seems the initial state of the parport DIRECTION registers depends
on the hardware - that's why the other poster did not encounter
these probs.

Besides that I have learned a lot about parport transmit mode 
negotiation ;-) 

But now the driver runs into another problem - the peripheral answers
the hosts MLCConfigSocket command for socket 1 with MLCError 7 after
a succesful MLCInit/InitReply pair:

	mlcpp0: Got device ID string: <MFG:HEWLETT-PACKARD;MDL:OFFICEJET R40;CMD:MLC,PCL,PML,SCL;CLS:PRINTER;DES:Hewlett-Packard OfficeJet R40;CMT:OFFICEJET PRO;SERN:SGD98AH3MWWZ;VSTATUS:$HB0$FC0,ff,DN,IDLE,CUT;LSS:01;LDF:1;LDE:1;>
	mlcpp0: usebecp=0.
	do_neg(c9068320,mode=0x10): in_1284=1, neg_mode=0x04.
	put_ecp_byte(c9068320): byte=0xCE, cmd=1.
	put_ecp_byte(c9068320): byte=0x00, cmd=0.
	put_ecp_byte(c9068320): byte=0xCD, cmd=1.
	put_ecp_byte(c9068320): byte=0x00, cmd=0.
	put_ecp_byte(c9068320): byte=0x00, cmd=0.
	put_ecp_byte(c9068320): byte=0x00, cmd=0.
	put_ecp_byte(c9068320): byte=0x08, cmd=0.
	put_ecp_byte(c9068320): byte=0x00, cmd=0.
	put_ecp_byte(c9068320): byte=0x00, cmd=0.
	put_ecp_byte(c9068320): byte=0x00, cmd=0.
	put_ecp_byte(c9068320): byte=0x03, cmd=0.
	s_idle(c9068320): Reverse data available.
	parport0 (mlcpp): use data_reverse for this!
	ecp_read_byte(c9068320): byte=0x00.
	ecp_read_byte(c9068320): byte=0x00.
	ecp_read_byte(c9068320): byte=0x00.
	ecp_read_byte(c9068320): byte=0x09.
	ecp_read_byte(c9068320): byte=0x00.
	ecp_read_byte(c9068320): byte=0x00.
	ecp_read_byte(c9068320): byte=0x80.
	ecp_read_byte(c9068320): byte=0x00.
	ecp_read_byte(c9068320): byte=0x03.
	mlc: configuring socket
	put_ecp_byte(c9068320): byte=0x00, cmd=0.
	put_ecp_byte(c9068320): byte=0x00, cmd=0.
	put_ecp_byte(c9068320): byte=0x00, cmd=0.
	put_ecp_byte(c9068320): byte=0x0D, cmd=0.
	put_ecp_byte(c9068320): byte=0x00, cmd=0.
	put_ecp_byte(c9068320): byte=0x00, cmd=0.
	put_ecp_byte(c9068320): byte=0x07, cmd=0.
	put_ecp_byte(c9068320): byte=0x01, cmd=0.
	put_ecp_byte(c9068320): byte=0x08, cmd=0.
	put_ecp_byte(c9068320): byte=0x06, cmd=0.
	put_ecp_byte(c9068320): byte=0x08, cmd=0.
	put_ecp_byte(c9068320): byte=0x06, cmd=0.
	put_ecp_byte(c9068320): byte=0x00, cmd=0.
	s_idle(c9068320): Reverse data available.
	parport0 (mlcpp): use data_reverse for this!
	ecp_read_byte(c9068320): byte=0x00.
	ecp_read_byte(c9068320): byte=0x00.
	ecp_read_byte(c9068320): byte=0x00.
	ecp_read_byte(c9068320): byte=0x08.
	ecp_read_byte(c9068320): byte=0x00.
	ecp_read_byte(c9068320): byte=0x00.
	ecp_read_byte(c9068320): byte=0x7F.
	ecp_read_byte(c9068320): byte=0x07.
	mlc: mlcpp0: Got MLCError 07
	mlc_getsockopt: c411e134
	mlc_sendmsg: c411e134 credit=0, flags=0
	mlc_release: c411e134
	do_neg(c9068320,mode=0x00): in_1284=1, neg_mode=0x10.
	ieee12844pp: unregistering device at parport0 (link mlcpp0)

To me this seems to be a gross misunderstanding between host and
peripheral. From the specs I can't see no reason why this should
happen. 

For now I am rather clueless.

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