On Tue, Feb 9, 2010 at 9:14 PM, Andy Walls <awalls@xxxxxxxxx> wrote: > Both Ooops below are related to userspace loading of firmware for the > HVR-950Q. Very strange. The xc5000 function doesn't appear to really do anything unusual. It calls request_firmware(), pushes the code into the chip, and then call release_firmware() [see xc5000.c:xc5000_fwupload() ] One thing that does jump out at me which could be problematic is the function will call release_firmware() even if request_firmware() fails. I doubt that is the correct behavior. And combined with the fact that his dmesg shows the error "run_program: '/lib/udev/firmware.sh' abnormal exit" makes me wonder if the subsequent to release_firmware() despite the error condition is what is causing the problem. The other thing that is a bit unusual about the xc5000 in this particular case is the time to load the firmware is exceptionally long (around 7 seconds) due to a hardware bug in the au0828 which requires us to run the i2c bus at a very slow rate. Hence, it's possible that the unusually long time between request_firmware() and release_firmware() has exposed some sort of race in the firmware loading core. It would be useful if we could get the full dmesg output so we can get some more context leading up to the oops. Also, it would be helpful if the user could enable the "debug=1" in the xc5000 modprobe options. One more question: is the user doing any suspend/resume operations? For example, is this a laptop in which he is closing the lid and this is the first attempt to use the device after resume? Devin -- Devin J. Heitmueller - Kernel Labs http://www.kernellabs.com -- To unsubscribe from this list: send the line "unsubscribe linux-media" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html
