On Wed, Nov 08, 2006 at 03:51:19PM -0500, Robert Hardy wrote: >> I don't even know where this size value is coming from, the correct >> value is hardcoded. (Not to mention that fw->size is showing the >> size of the previous file read.) > > The first two calls to load_fw_direct are, correctly IMHO, hard coding > size to be IVTV_FIRM_IMAGE_SIZE (or 256x1024 bytes.) > > The third call to load_fw_direct, was passing data[2] which was in > theory seemed to be coming out of some decoder mailbox which, given > the results, can obviously have garbage in it... Hard coding the third > call too prevents this kind of problem.
Ah, I was unaware of that- that is a real problem. >>> v4l-cx2341x-dec.fw firmware (size=262144 bytes;fw->size=262144 bytes) >>> v4l-cx2341x-init.mpg firmware (size=155648 bytes;fw->size=262144 bytes) >> >> Same here with the previous fw->size being returned. It's like there >> needs to be some locking around the firmware retrieval code or >> something... > > No question there is something foobar with fw->size but the bottom line is > we can't and really shouldn't be trusting the contents of that memory > location for determining the ranges for our memcpy/memcpy_toio or > writel/iowrite32 loop. Apparently not. > Looking at a larger data set I don't think it is as simple as fw->size > sometimes returning the previous firmware's fw->size. The fact that this could be worked around by adding a delay (and only seems to effect SMP systems) makes me think it has to do with multiple firmware_request calls stomping on each other. -- Tyler Trafford _______________________________________________ ivtv-devel mailing list [email protected] http://ivtvdriver.org/mailman/listinfo/ivtv-devel
