On Mon, Dec 12, 2005, Tim Hewett wrote: > 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. le16_to_cpu() does nothing on Intel. But IIRC those le16_to_cpu() calls were added because of some other PPC user's complaints. See rev 1.63 in http://linuxtv.org/cgi-bin/viewcvs.cgi/v4l-dvb/linux/drivers/media/dvb/ttusb-dec/ttusb_dec.c?rev=1.77&root=v4l&view=log I need to check this. Does someone have a hint for me? Anyway, I noticed before that the switch() statement lacks a default label. Of course I thought "it can't happen, because _probe() won't be called for a wrong id"... > 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 digging into this. Johannes
