On Sat, Dec 10, 2005 at 04:02:50PM +0000, Tim Hewett wrote: > I managed to get my Yellow Dog kernel up from 2.6.10 to 2.6.14.3 > (clean download, not patched). The Freecom USB stick is now > detected but I get the same problems as Michael Hanke recently > reported (thread subject "dnt Euro Stick DVB-T -- FATAL: FE_GET_INFO > failed: 22") where the device won't tune. The Freecom works fine > with EyeTV under MacOS X, no tuning problems or issues associated > with input signal saturation as reported by Mike Choy (thread subject > "freecom dvb-t usb firmware coldstate") so there's nothing wrong with > the stick or the aerial feed. But I get the same "recv bulk message > failed: -110" as everyone else under Linux. Maybe Patrick could comment, but I guess this -110 error isn't a serious problem if I interpreted google results correctly. Seems like your device works, Michael Hanke has a different problem. > I tried the DEC2000-t with the new kernel, same problem as before, here > are the logs for that: > > DEC2000-t dmesg output: > > usb 4-1: new full speed USB device using ohci_hcd and address 2 > ttusb_dec: Firmware 1.05de > Oops: kernel access of bad area, sig: 11 [#1] > NIP: C0012168 LR: C01609EC SP: EFF2BC60 REGS: eff2bbb0 TRAP: 0300 > Not tainted > MSR: 00009032 EE: 1 PR: 0 FP: 0 ME: 1 IR/DR: 11 > DAR: 00000000, DSISR: 40000000 > TASK = c0608bd0[31] 'khubd' THREAD: eff2a000 > Last syscall: -1 > GPR00: C01EC704 EFF2BC60 C0608BD0 00000000 FFFFFFFF 0000001E 00000000 > 000001A4 > GPR08: 00000000 00000000 C01ECDDC C01ECC20 00000000 00000000 C18D6418 > C18B4890 > GPR16: 00000004 C18B48E2 C18A7E30 C03D0000 C0290000 C0380000 F22E0000 > 00000001 > GPR24: 00000000 EFF2BD7C EDC1C860 00000000 0000001E 00000000 C0684120 > C0684120 > 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. Johannes
