Hi Olav, thank you for your response. Trying to actualy run the driver with PTD_TRACE enabled is not realy possible. As soon as I open my device I get flooded with repeated messages:
[ 122.480000] td: f 8i2 0,64,64 0 101 [ 122.480000] - [ 122.480000] td: f 8i2 0,64,64 0 101 [ 122.480000] td: f 8i2 0,64,64 0 101 [ 122.480000] - [ 122.480000] td: f 8i2 0,64,64 0 101 [ 122.490000] td: f 8i2 0,64,64 0 101 [ 122.490000] - [ 122.490000] td: f 8i1 0,16,16 0 100 [ 122.490000] td: f 8i2 0,64,64 0 101 [ 122.500000] td: f 8i1 0,16,16 0 100 [ 122.500000] td: f 8i2 0,64,64 0 101 [ 122.500000] - [ 122.500000] td: f 8i2 0,64,64 0 101 [ 122.520000] td: f 8i2 0,64,64 0 101 [ 122.520000] - ..................... I will try to set up some other debugging environment on Wendesday (I'm out off office tomorrow) and than get back to you. Thank you and best regards, Peter On Mon, 13 Feb 2006, Olav Kongas wrote: > > > On Mon, 13 Feb 2006, Peter Wippich wrote: > > Dear Olav, > > Hi Peter, > > Please keep linux-usb-devel list CC-d. > > > I'm trying to use your driver (from kernel 2.6.14) on a PXA26x (ARM) > > platform. We only need to connect to a single device (an ACM Modem). In > > general, this works. > > However, after a short time (lets say a few minutes) we get a Bugcheck > > even without transferring any data. > > What we have investigated so far: > > As soon as we open the device we get a lot of interrupts from the ISP1160. > > This may be because EP0 is an interrupt channel which needs to be polled. > > EP0 is always a control endpoint. But yes, you'll get lot of > of interrupts, if interrupt endpoints get involved. > > > Also the driver switches Interrupt mode from ATL to SOF (I do not yet > > understand this, but have to read a little bit more about the chip > > itself). > > This is just an optimization - SOF interrupt mode is > necessary for interrupt transfers (interrupt arrives once in > a millisecond), while ATL interrupt mode suffices for > control transfers (interrupts arrive only when submitted > transfers finish). > > > Than, after some time we get a bugcheck in function > > start_atl_transfers(..), around line 560 (hacked the driver a little for > > debugging). This triggers because urb->actual_length is bigger than the > > buffer length. If it happens start_atl_transfer(..) is always called from > > the ISR. We tried to disable kernel preemption but this doesn't help. We > > also tried to change hardware timings, but with no success. Verifying > > with a scope shows that timing is far away from critical. > > > > Do you have heard of such problems before ?? > > I don't remember anyone stumbling on that bugcheck before. > > > Any hints how to localize the problem ?? > > Could you please do the following. Take the original > (non-hacked) driver. Enable DEBUG, URB_TRACE and PTD_TRACE > macros at the beginning of the isp116x-hcd.c. Save the log > spit out by the driver until the BUG() is hit. There > will probably be LOT OF OUTPUT! > > Then could you please put this log temporarily up to the > web, or alternatively, send it directly to me, without > bothering the usb-devel list. However, let's keep all the > discussion still posted to the list too. > > Olav > | Peter Wippich Voice: +49 30 46776411 | | G&W Instruments GmbH fax: +49 30 46776419 | | Gustav-Meyer-Allee 25, Geb. 12 Email: [EMAIL PROTECTED] | | D-13355 Berlin / Germany | ------------------------------------------------------- This SF.net email is sponsored by: Splunk Inc. Do you grep through log files for problems? Stop! Download the new AJAX search engine that makes searching your log files as easy as surfing the web. DOWNLOAD SPLUNK! http://sel.as-us.falkag.net/sel?cmd=lnk&kid=103432&bid=230486&dat=121642 _______________________________________________ [email protected] To unsubscribe, use the last form field at: https://lists.sourceforge.net/lists/listinfo/linux-usb-devel
