Bug 166708

Summary: RFE: Hauppauge Nova-T model 909 entries in pcitable
Product: [Fedora] Fedora Reporter: Jón Fairbairn <jon.fairbairn>
Component: kudzuAssignee: Bill Nottingham <notting>
Status: CLOSED RAWHIDE QA Contact: David Lawrence <dkl>
Severity: medium Docs Contact:
Priority: medium    
Version: 4CC: pierre-bugzilla, rvokal
Target Milestone: ---   
Target Release: ---   
Hardware: i386   
OS: Linux   
Whiteboard:
Fixed In Version: Doc Type: Bug Fix
Doc Text:
Story Points: ---
Clone Of: Environment:
Last Closed: 2006-01-20 21:45:24 UTC Type: ---
Regression: --- Mount Type: ---
Documentation: --- CRM:
Verified Versions: Category: ---
oVirt Team: --- RHEL 7.3 requirements from Atomic Host:
Cloudforms Team: --- Target Upstream Version:
Embargoed:
Bug Depends On:    
Bug Blocks: 150221    
Attachments:
Description Flags
pcitable entries for Nova-T none

Description Jón Fairbairn 2005-08-24 20:07:20 UTC
From Bugzilla Helper:
User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.7.10) Gecko/20050720 Fedora/1.0.6-1.1.fc4 Firefox/1.0.6

Description of problem:
/usr/share/hdwata/pci{.ids,table} lack entries for the Hauppauge Nova-T model 909
DVB card

The driver (cx88-dvb) is present from kernel >= 2.6.12

Version-Release number of selected component (if applicable):
hwdata-0.158.1-1

How reproducible:
Always

Steps to Reproduce:
1. look in the files...
2.
3.
  

Actual Results:  no entries for Nova-T...

Additional info:

Comment 1 Jón Fairbairn 2005-08-24 20:10:24 UTC
Created attachment 118091 [details]
pcitable entries for Nova-T

I've submitted the relevant entries for pci.ids to pciids.sf.net

Comment 2 Bill Nottingham 2005-08-25 18:42:42 UTC
Shouldn't be needed in pcitable ; should be handled fine with modules.pcimap.

Comment 3 Jón Fairbairn 2005-08-25 20:39:03 UTC
It isn't. The modules.pcimap that depmod generates for kernel 2.6.12-1.1398_FC4
doesn't handle the subvendor or something; I don't know how it's supposed to
work, but it doesn't load cx88-dvb for this device. ISTR that before I made the
change it loaded (uselessly) cx88-blackbird, but I can't revert to check just at
the moment.


Comment 4 Bill Nottingham 2005-08-25 20:45:39 UTC
cx88-dvb             0x000014f1 0x00008802 0xffffffff 0xffffffff 0x00000000
0x00000000 0x0

If it's supposed to match the 0x8800 you mention in your pcitable patch, the
driver needs updated.

The problem is that both -dvb and -blackbird claim the device, which in FC4
causes one to get loaded at random.

We're looking at fixing this for FC5.

Comment 5 Jón Fairbairn 2005-08-25 21:07:33 UTC
The card in question has 0x8800, 0x8802 and 0x8804 devices.  Wouldn't the clash
be resolved if the subvendor and subdevice ids were filled in?

lspci -n -v -s 01:01
01:01.0 Class 0400: 14f1:8800 (rev 05)
        Subsystem: 0070:9002
        Flags: bus master, medium devsel, latency 32, IRQ 10
        Memory at fb000000 (32-bit, non-prefetchable) [size=16M]
        Capabilities: <available only to root>

01:01.2 Class 0480: 14f1:8802 (rev 05)
        Subsystem: 0070:9002
        Flags: bus master, medium devsel, latency 32, IRQ 10
        Memory at fc000000 (32-bit, non-prefetchable) [size=16M]
        Capabilities: <available only to root>

01:01.4 Class 0480: 14f1:8804 (rev 05)
        Subsystem: 0070:9002
        Flags: bus master, medium devsel, latency 32, IRQ 10
        Memory at fd000000 (32-bit, non-prefetchable) [size=16M]
        Capabilities: <available only to root>

(as I said, I don't know how it's supposed to work... 0070 is Hauppauge, and I
think 9002 only matches the Nova-T DVB model 909)

Anyway, with the patch I made it works for me, so I'm happy (and look forward to
it just working in FC5), and anyone trying to find out why their Nova-T isn't
detected in FC4 will stand a chance of finding this. For the benefit of such
searchers, it might be worth mentioning that after patching pcitable and
pci.ids, I ran kudzu. I'm not sure if each of these steps is necessary.


Comment 6 Bill Nottingham 2005-09-16 16:15:09 UTC
*** Bug 168411 has been marked as a duplicate of this bug. ***

Comment 7 Bill Nottingham 2006-01-20 21:45:24 UTC
This was fixed in mid-December; we now use sysfs & udev to load modules at boot;
this should load both modules.