Project Home
Project Home
Trackers
Trackers
Documents
Documents
Wiki
Wiki
Discussion Forums
Discussions
Project Information
Project Info
Forum Topic - QNX 6.5 SP 1 and USB printers: (6 Items)
   
QNX 6.5 SP 1 and USB printers  
I am having data transfer issue over usb interface to DELL and Samsung printers. The transferred data seems to be 
corrupted or missing. Those two printers also have Ethernet ports and transferring the same date over Ethernet interface
 does not cause data corruption. The format of transferred data is a pcl language and both printers support it. 
I have used lpd to print to the printer as well cp (copy ) command and in both cases the data seems to be randomly 
corrupted. The first transfer after printer is powered on is always successful.

The model of printer is Samsung M3320ND.

My guess is that devu-prn driver may be a problem. Any input or possible work around would be very appreciated. 

Best
Janusz
QNX 6.5 SP 1 x86 platform and USB printers  
 I am having data transfer issue over usb interface to DELL and Samsung 
 printers. The transferred data seems to be corrupted or missing. Those two 
 printers also have Ethernet ports and transferring the same date over Ethernet
  interface does not cause data corruption. The format of transferred data is a
  pcl language and both printers support it. 
 I have used lpd to print to the printer as well cp (copy ) command and in both
  cases the data seems to be randomly corrupted. The first transfer after 
 printer is powered on is always successful.
 
 The model of printer is Samsung M3320ND.
 
 My guess is that devu-prn driver may be a problem. Any input or possible work 
 around would be very appreciated. 
 
 Best
 Janusz


Re: QNX 6.5 SP 1 and USB printers  
Issue located.

the devu-prn driver terminates the printer transfer with a null Bulk Out packet (prn_io_close function) which causes 
some printers to corrupt next coming data. Linux generic usb printer drivers do not issue additional null data transfer.


The source code i am looking at is from DDK 6.3.2. Is the source code for QNX 6.6 different?

Janusz
RE: QNX 6.5 SP 1 and USB printers  
This problem (or one exactly like it) was fixed in 6.4.0, under PR43795. The problem was not actually in devu-prn, but 
rather in devu-ehci.

You are right that making devu-prn not issue the null packet during prn_io_close() does seem to fix the problem, but 
this null packet is needed in certain situations. The real problem was in devu-ehci which was not properly updating the 
data toggle when processing a zero length packet.

If you need more details, let me know,
Max

P.S. I'm a bit confused about releases. You mention the 6.3.2 ddk and also 6.5 SP1. This problem should be long fixed in
 6.5, but it will be present in 6.3.2. You can try narrowing things down more by using uhci/ohci instead of ehci and 
seeing if the problem goes away. There may have been other problems fixed in devu-prn that I'm not aware of. See also 
PR58292 and the more recent comments from 2011.
-----Original Message-----
From: janusz ruszel [mailto:community-noreply@qnx.com] 
Sent: Sunday, February 08, 2015 4:59 PM
To: momentics-community
Subject: Re: QNX 6.5 SP 1 and USB printers

Issue located.

the devu-prn driver terminates the printer transfer with a null Bulk Out packet (prn_io_close function) which causes 
some printers to corrupt next coming data. Linux generic usb printer drivers do not issue additional null data transfer.


The source code i am looking at is from DDK 6.3.2. Is the source code for QNX 6.6 different?

Janusz



_______________________________________________

QNX Momentics Community Support
http://community.qnx.com/sf/go/post113261
To cancel your subscription to this discussion, please e-mail momentics-community-unsubscribe@community.qnx.com
QNX 6.5 SP 1 and USB PCL printers  
Listed below printers were tested. All of them are PCL printers and data transmitted over USB was in PCL format. I have 
also tested each usb driver separately uhci/ohci and data corruption have happened. My testing environment is commercial
 QNX 6.5 SP1 on x86 platform.

Later on I grab the devu-prn source code which was published with DDK 6.3.2 and recompiled with QNX 6.5 SP1 environment.
 Repeated all test and data corruption still was noticed. 

Next step was to making devu-prn not issue the null packet during prn_io_close() and data corruption “disappeared”.

The same test run under evaluation version QNX 6.6 also corrupts the data.

 This is repeatable scenario and I am sure could be repeated by QNX driver engineers. 
If you have any suggestions/questions or would like me to run more tests I would be glad to help.  

Tested Printers : (over USB interface)
Dell B1260   
Samsung M2835DW
Samsung SL-M3320ND

Janusz
Re: QNX 6.5 SP 1 and USB PCL printers and QNX 6.6.0  
Similar symptom on x86 (system freezes) based system with  HP LaserJet P2014 printer attached to  USB port. The system 
log listed below, please advice.

Mar 19 03:41:44    6    12   100 bus::USB
busno::0x01
devno::0x09
vendor_id::0x03f0
product_id::0x3917
configurations::1
configuration::1
serial_number::LW211GS
device_class::0x00
max_packet_size0::64
manufacturer::Hewlett-Packard
product::HP LaserJet P2014
upstream_device_address::0
upstream_host_controller::1
upstream_port::2
upstream_port_speed::High
topology::(0,2)
drivers_matched::0
drivers_running::0

Mar 19 03:41:44    5    12   100 USB-1.9:0: vid=03f0, did=3917: No match found, class=0x00
Mar 19 03:41:44    2    12     0 USB_SelectInterface:  Select iface devno 9, ifc 0, alt 0
Mar 19 03:41:44    2    12     0 process_xfer_complete: No Outstanding Transfer on XRING... where is this event coming 
from???
Mar 19 03:41:44    2    12     0 process_xfer_complete: evt->w0 = 0xda229000 evt->w1 = 0x0 evt->w2 = 0x1b000000 evt->w3 
= 0x9028000
Mar 19 03:41:44    2    12     0 process_xfer_complete: No Outstanding Transfer on XRING... where is this event coming 
from???
Mar 19 03:41:44    2    12     0 process_xfer_complete: evt->w0 = 0xd6452000 evt->w1 = 0x0 evt->w2 = 0x1b000000 evt->w3 
= 0x9038000
Mar 19 03:44:05    2    12     0 process_control_xfer: Transfer Failed ep->devaddr = 0x9 ep->num = 0 ep->dir = 0x0 
Completion Code = TRB_COMP_CODE_USB_TRANSACTION_ERROR
Mar 19 03:44:05    2    12     0 process_control_xfer: evt->w0 = 0xd9bd15f0 evt->w1 = 0x0 evt->w2 = 0x4000001 evt->w3 = 
0x9018000
Mar 19 03:44:05    2    12     0 xhci_ctrl_transfer:control_xfer_wait() failed  rc = -1, epstate = 0x3
Mar 19 03:44:05    2    12     0 xhci_ctrl_transfer: Details : addr = 0x9 buffer = 0xd7ff6014 len = 1 flags = 0x80000004