Lothar schrieb:
> >with Line 417 being
> >
> >WARN_ON((!(__isp1362_read_reg16(dev, HCuPINT) & HCuPINT_ISP116x_AIIEOT)));
> ALLEOT is set when the amount of data programmed in the XFERCOUNT
> register has been transferred to/from the chip buffer. If it's not set
> at the end of the the read/write_buffer it means that the chip is
> waiting for more data. Could be a hardware timing problem.
Hm. I am excluding timing problems. I tried a dozen of printk, mdelay or
none of them. Every time same behaviour. I even lovered the CPU/BUS
frequency from 200/72 to 150/64 with no change in the behaviuor of the
driver framework.
This happens trying to access wlan wit wlanctl-ng:
R-
buf_curlen(old) = 0
buf_curlen(new) = 8, xfer_size 0, xfer_size_real 0
S-
num 1f81, rem 2def
num 1f81, rem 2d4c
R-
buf_curlen(old) = 0
buf_curlen(new) = 3008, xfer_size 3000, xfer_size_real 3000
buf_curlen(old) = 3008
buf_curlen(new) = 3080, xfer_size 64, xfer_size_real 64
S-
num 1f9b, rem 2de0
num 1f9b, rem 1165
Badness in isp116x_send_queue at drivers/usb/host/ohci-isp116x-emu.c:417
hfa384x_docmd: ctlx failure=REQ_TIMEOUT
hfa384x_drvr_start: cmd_initialize() failed, result=-5
prism2sta_ifstate: hfa384x_drvr_start() failed,result=-5
message=lnxreq_ifstate
ifstate=enable
resultcode=implementation_failure
_Every_ time after double occurence of buf_curlen(old) buf_curlen(new)
the Badness is triggered. Btw. is this double occurence intentional?
Following happens, when plugging in usb-storage:
Jan 1 00:29:41 scb9328 kern.debug klogd: usb-storage: *** thread sleeping.
Jan 1 00:29:41 scb9328 kern.info klogd: sda:<7>usb-storage: queuecommand
called
Jan 1 00:29:41 scb9328 kern.debug klogd: usb-storage: *** thread awakened.
Jan 1 00:29:41 scb9328 kern.debug klogd: usb-storage: Command READ_10 (10
bytes)
Jan 1 00:29:41 scb9328 kern.debug klogd: usb-storage: 28 00 00 00 00 00 00 00
08 00
Jan 1 00:29:41 scb9328 kern.debug klogd: usb-storage: Bulk Command S
0x43425355 T 0x33 L 4096 F 128 Trg 0 LUN 0 CL 10
Jan 1 00:29:41 scb9328 kern.debug klogd: usb-storage:
usb_stor_bulk_transfer_buf: xfer 31 bytes
Jan 1 00:29:41 scb9328 kern.debug klogd: usb-storage: Status code 0;
transferred 31/31
Jan 1 00:29:41 scb9328 kern.debug klogd: usb-storage: -- transfer complete
Jan 1 00:29:41 scb9328 kern.debug klogd: usb-storage: Bulk command transfer
result=0
Jan 1 00:29:41 scb9328 kern.debug klogd: usb-storage:
usb_stor_bulk_transfer_sglist: xfer 4096 bytes, 1 entries
Jan 1 00:30:11 scb9328 kern.debug klogd: usb-storage: command_abort called
Jan 1 00:30:11 scb9328 kern.debug klogd: usb-storage: usb_stor_stop_transport
called
Jan 1 00:30:11 scb9328 kern.debug klogd: usb-storage: -- cancelling sg request
Jan 1 00:30:11 scb9328 kern.debug klogd: usb-storage: Status code -104;
transferred 0/4096
Jan 1 00:30:11 scb9328 kern.debug klogd: usb-storage: -- transfer cancelled
Jan 1 00:30:11 scb9328 kern.debug klogd: usb-storage: Bulk data transfer
result 0x4
Jan 1 00:30:11 scb9328 kern.debug klogd: usb-storage: -- command was aborted
Jan 1 00:30:11 scb9328 kern.debug klogd: usb-storage: usb_stor_Bulk_reset
called
Jan 1 00:30:11 scb9328 kern.debug klogd: usb-storage: usb_stor_control_msg:
rq=ff rqtype=21 value=0000 index=00 len=0
Jan 1 00:30:17 scb9328 kern.debug klogd: usb-storage: Soft reset: clearing
bulk-in endpoint halt
Jan 1 00:30:17 scb9328 kern.debug klogd: usb-storage: usb_stor_control_msg:
rq=01 rqtype=02 value=0000 index=81 len=0
Jan 1 00:30:17 scb9328 kern.debug klogd: usb-storage: usb_stor_clear_halt:
result = 0
Jan 1 00:30:17 scb9328 kern.debug klogd: usb-storage: Soft reset: clearing
bulk-out endpoint halt
Jan 1 00:30:17 scb9328 kern.debug klogd: usb-storage: usb_stor_control_msg:
rq=01 rqtype=02 value=0000 index=02 len=0
Jan 1 00:30:17 scb9328 kern.debug klogd: usb-storage: usb_stor_clear_halt:
result = 0
Jan 1 00:30:17 scb9328 kern.debug klogd: usb-storage: Soft reset done
Jan 1 00:30:17 scb9328 kern.debug klogd: usb-storage: scsi command aborted
Jan 1 00:30:17 scb9328 kern.debug klogd: usb-storage: *** thread sleeping.
Jan 1 00:30:17 scb9328 kern.debug klogd: usb-storage: queuecommand called
Jan 1 00:30:17 scb9328 kern.debug klogd: usb-storage: *** thread awakened.
Jan 1 00:30:17 scb9328 kern.debug klogd: usb-storage: Command TEST_UNIT_READY
(6 bytes)
Jan 1 00:30:17 scb9328 kern.debug klogd: usb-storage: 00 00 00 00 00 00
Jan 1 00:30:17 scb9328 kern.debug klogd: usb-storage: Bulk Command S
0x43425355 T 0x33 L 0 F 0 Trg 0 LUN 0 CL 6
Jan 1 00:30:17 scb9328 kern.debug klogd: usb-storage:
usb_stor_bulk_transfer_buf: xfer 31 bytes
Jan 1 00:30:17 scb9328 kern.debug klogd: usb-storage: Status code 0;
transferred 31/31
Jan 1 00:30:17 scb9328 kern.debug klogd: usb-storage: -- transfer complete
Jan 1 00:30:17 scb9328 kern.debug klogd: usb-storage: Bulk command transfer
result=0
Jan 1 00:30:17 scb9328 kern.debug klogd: usb-storage: Attempting to get CSW...
Jan 1 00:30:17 scb9328 kern.debug klogd: usb-storage:
usb_stor_bulk_transfer_buf: xfer 13 bytes
Jan 1 00:30:17 scb9328 kern.debug klogd: usb-storage: Status code 0;
transferred 0/13
Jan 1 00:30:17 scb9328 kern.debug klogd: usb-storage: -- short transfer
Jan 1 00:30:17 scb9328 kern.debug klogd: usb-storage: Received 0-length CSW;
retrying...
Jan 1 00:30:17 scb9328 kern.debug klogd: usb-storage:
usb_stor_bulk_transfer_buf: xfer 13 bytes
_Every_ time, when
Jan 1 00:29:41 scb9328 kern.debug klogd: usb-storage:
usb_stor_bulk_transfer_sglist: xfer 4096 bytes, 1 entries
happens, the usb ohci framework does not react at all. nothing.
On all other operations from usb-storage it does something. Is this to big for
something? Even the wlan timeout looks weird to me and makes me think, there
are not enough or too small buffers or such.
I tried different
if (dev->ptd_mem_size == 0) {
dev->istl0_queue.num_bufs = 0;
dev->istl1_queue.num_bufs = 0;
dev->intl_queue.num_bufs = 0;
dev->atl_queue.num_bufs = 30;
dev->istl0_queue.blk_size = 0;
dev->istl1_queue.blk_size = 0;
dev->intl_queue.blk_size = 64;
dev->atl_queue.blk_size = 128;
setups (1*4080, 30*128, 14*265...) but the driver breaks at the same
places...
Damn! *ARGH*
I will read this code again in the hope finding anything again...
So long, Konsti
--
GPG KeyID EF62FCEF
Fingerprint: 13C9 B16B 9844 EC15 CC2E A080 1E69 3FDA EF62 FCEF
-------------------------------------------------------
SF email is sponsored by - The IT Product Guide
Read honest & candid reviews on hundreds of IT Products from real users.
Discover which products truly live up to the hype. Start reading now.
http://productguide.itmanagersjournal.com/
_______________________________________________
[EMAIL PROTECTED]
To unsubscribe, use the last form field at:
https://lists.sourceforge.net/lists/listinfo/linux-usb-devel
