Johannes, On 10 Dec 2005, at 20:31, Johannes Stezenbach wrote: [DEC2000-t problem] >> NIP [c0012168] strlen+0x4/0x18 >> LR [c01609ec] strlcpy+0x24/0x70 >> Call trace: >> [c01ec704] _request_firmware+0xc8/0x37c >> [f22dbe6c] ttusb_dec_probe+0x2ac/0xc58 [ttusb_dec] > > Can't see from the code why it would crash here (provided the > calltrace > isn't bogus). You could add a printk() just before the > request_firmware() call in ttusb_dec_boot_dsp() to check if the > parameters are sane. Or just generally sprinkle some printk() > in there to find the reason for the crash. Experimentally I removed the calls to le16_to_cpu() in ttusb_dec_probe() and it now works, so it was a byte ordering issue. It is worrying that the calls to le16_to_cpu() do not resolve this automatically, from the name of that function I would imagine that it exists to convert between 16 bit little endian into a native CPU byte ordered short integer, adapting its behaviour between doing nothing and swapping bytes around depending on the architecture it was compiled on. The kernel source for le16_to_cpu() doesn't appear to differentiate depending on architecture so where byte swapping is needed for Intel is it also done on PowerPC when it shouldn't be. Many Kernel devices also call le16_to_cpu() so quite how Linux manages to run on PowerPC at all is a bit of a mystery. Maybe no devices are shared with any available for Intel, DVB ones excepted. Now both devices work on Yellow Dog Linux on the PowerPC CPU, the Freecom even supports recording multiple channels from the same multiplex, the DEC2000 doesn't probably because USB1.1 isn't fast enough. Thanks for your help. > Johannes Regards, Tim.
