[linux-dvb] HVR-1500Q eeprom not being parsed correctly
awalls at radix.net
Thu Sep 11 03:10:47 CEST 2008
On Wed, 2008-09-10 at 20:37 -0400, Patrick Boisvenue wrote:
> Andy Walls wrote:
> > On Tue, 2008-09-09 at 22:37 -0400, Steven Toth wrote:
> >> Patrick Boisvenue wrote:
> >>> Steven Toth wrote:
> >>>> Patrick Boisvenue wrote:
> >>> When launching dvbscan I get the following in dmesg:
> >>> xc5000: waiting for firmware upload (dvb-fe-xc5000-1.1.fw)...
> >>> firmware: requesting dvb-fe-xc5000-1.1.fw
> >>> kobject_add_internal failed for i2c-2 with -EEXIST, don't try to
> >>> register things with the same name in the same directory.
> >>> Pid: 8059, comm: kdvb-fe-0 Tainted: P 2.6.26-gentoo #11
> >>> Call Trace:
> >>> [<ffffffff8036abb5>] kobject_add_internal+0x13f/0x17e
> >>> [<ffffffff8036aff2>] kobject_add+0x74/0x7c
> >>> [<ffffffff80230b02>] printk+0x4e/0x56
> >>> [<ffffffff803eb84a>] device_add+0x9b/0x483
> >>> [<ffffffff8036a876>] kobject_init+0x41/0x69
> >>> [<ffffffff803f059d>] _request_firmware+0x169/0x324
> >>> [<ffffffffa00e9a7e>] :xc5000:xc_load_fw_and_init_tuner+0x64/0x293
> >>> [<ffffffff804a7222>] i2c_transfer+0x75/0x7f
> >>> [<ffffffffa00e53ad>] :s5h1409:s5h1409_writereg+0x51/0x83
> >>> [<ffffffffa00e9cea>] :xc5000:xc5000_init+0x3d/0x6f
> >>> [<ffffffffa0091b0c>] :dvb_core:dvb_frontend_init+0x49/0x63
> >>> [<ffffffffa0092e2c>] :dvb_core:dvb_frontend_thread+0x78/0x2f0
> >>> [<ffffffffa0092db4>] :dvb_core:dvb_frontend_thread+0x0/0x2f0
> >>> [<ffffffff80240eaf>] kthread+0x47/0x74
> >>> [<ffffffff8022bc41>] schedule_tail+0x27/0x5b
> >>> [<ffffffff8020be18>] child_rip+0xa/0x12
> >>> [<ffffffff80240e68>] kthread+0x0/0x74
> >>> [<ffffffff8020be0e>] child_rip+0x0/0x12
> >>> fw_register_device: device_register failed
> >>> xc5000: Upload failed. (file not found?)
> >>> xc5000: Unable to initialise tuner
> >>> I have the firmware file located here:
> >>> # ls -l /lib/firmware/dvb-fe-xc5000-1.1.fw
> >>> -rw-r--r-- 1 root root 12332 Aug 31 12:56
> >>> /lib/firmware/dvb-fe-xc5000-1.1.fw
> >>> If there is anything else I can provide (or try) to help debug, let me
> >>> know,
> >>> ...Patrick
> >> > kobject_add_internal failed for i2c-2 with -EEXIST, don't try to
> >> > register things with the same name in the same directory.
> >> Ooh, that's nasty problem, this is new - and looks like it's i2c related.
> >> Why does this sound familiar? Anyone?
> > A cx18 user had a similar problem on one distro. I remeber running it
> > down to a race condition in creating device nodes in one of the
> > "virtual" filesystems (/proc or /sys) the device was looking for a
> > paretn PCI device entry to hook onto, but it wasn't created at the time
> > so it tries to create it itself. In the meantime some other part of the
> > kernel subsystem did actually finish creating the entry - so it exists
> > by the time the firmware load tries to make it.
> > As far as I could tell, it should be non-fatal (not an Oops or panic),
> > but if the driver gives up on -EEXIST then things won't work obviously.
> > I never resolved the problem for the user. I think some kernel change
> > outside of cx18 resolved it. That's all the details I have.
> > Regards,
> > Andy
> So what are my options?
Good question. I don't know. Working with kobjects is way out of my
I looked at the kernel code long enough to decide that without being
able to reproduce the problem myself, I won't be able to spot the root
cause. Part of the reason is that this problem is about looking for and
creating sysfs objects as it relates to driver probing and firmware
loading. I couldn't quite sort out what had to happen in series and
what the kernel could be executing in parallel.
I think your best option would be to post to the LKML or wherever else
the sysfs and kobject experts hang out.
Another option could be to modify the driver code that gives up when the
firmware operation returns an error code because a sysfs device node
already exists (-EEXIST). That's no big deal, and a driver should be
able to merrily go forward, if it can easily detect the condition.
> Different kernels? Wait for newer kernels and
> try again?
That's sub-optimal as it provides not guarantee of resolution.
> Running 2.6.26 right now and I have 2.6.25 available,
> however, I cannot go lower since my Thinkpad needs >=2.6.25 to run properly.
More information about the linux-dvb