Bug 166708 - RFE: Hauppauge Nova-T model 909 entries in pcitable
Summary: RFE: Hauppauge Nova-T model 909 entries in pcitable
Alias: None
Product: Fedora
Classification: Fedora
Component: kudzu   
(Show other bugs)
Version: 4
Hardware: i386
OS: Linux
Target Milestone: ---
Assignee: Bill Nottingham
QA Contact: David Lawrence
: 168411 (view as bug list)
Depends On:
Blocks: FC5Target
TreeView+ depends on / blocked
Reported: 2005-08-24 20:07 UTC by Jón Fairbairn
Modified: 2014-03-17 02:55 UTC (History)
2 users (show)

Fixed In Version:
Doc Type: Bug Fix
Doc Text:
Story Points: ---
Clone Of:
Last Closed: 2006-01-20 21:45:24 UTC
Type: ---
Regression: ---
Mount Type: ---
Documentation: ---
Verified Versions:
Category: ---
oVirt Team: ---
RHEL 7.3 requirements from Atomic Host:
Cloudforms Team: ---

Attachments (Terms of Use)
pcitable entries for Nova-T (350 bytes, patch)
2005-08-24 20:10 UTC, Jón Fairbairn
no flags Details | Diff

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):

How reproducible:

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

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.

Note You need to log in before you can comment on or make changes to this bug.