It turns out someone else reported the same crash I was seeing in em28xx-audio whenever you stopped capturing, but his case was with the HVR-900. This confirmed my suspicion that it had nothing to do with the saa7136 development. Both Mauro and Douglas successfully reproduced the issue as well.
I tried out a patch that was believed might fix the issue, and it didn't. I also started playing around with the kdump facility built into the kernel (with Mauro's help) in hopes I would be able to preserve the stack trace. Unfortunately, the kdump facility itself hits a segmentation fault when the kernel crashes. Yeah, the crash facility crashed - isn't that cute?
Gabor also tried out my USBAV 704 patch, and it didn't work. Looks like there is some weird GPIO issue where one of the devices doesn't always respond to i2c at startup, which results in the i2c hash sometimes being different. Generally speaking, I don't think the em28xx driver has a cohesive strategy for ensuring the GPIOs are in a well-known state when the driver loads, which is probably a bad thing.
I'm tempted to add a routine that basically pulls all the GPIOs low for 50ms and then leave them all high, which would put the chip in a consistent state with its reset state (and reduce the risk of demod/tuner state persisting across a reload of the driver).
