-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1
Bonjour,
On a Toshiba laptop, I have an integrated TV card which is strangely not recognised by udev, but which install the correct kernel module specified by lspci.
lspci gives:
02:09.0 0400: 14f1:5b7a Subsystem: 1179:0010 Flags: bus master, medium devsel, latency 64, IRQ 19 Memory at 48000000 (32-bit, non-prefetchable) [size=64M] Capabilities: [44] Vital Product Data Capabilities: [4c] Power Management version 2 Kernel modules: cx18
But at the beginning of the boot sequence, I have an error message:
dmesg | grep cx18
cx18: Start initialization, version 1.1.0 cx18-0: Initializing card 0 cx18-0: Unknown card: vendor/device: [14f1:5b7a] cx18-0: subsystem vendor/device: [1179:0111] cx18-0: Defaulting to Hauppauge HVR-1600 card cx18-0: Please mail the vendor/device and subsystem vendor/device IDs and what kind of cx18-0: card you have to the ivtv-devel mailinglist (www.ivtvdriver.org) cx18-0: Prefix your subject line with [UNKNOWN CX18 CARD]. cx18 0000:08:09.0: enabling device (0000 -> 0002) cx18 0000:08:09.0: PCI INT A -> GSI 22 (level, low) -> IRQ 22 cx18-0: cx23418 revision 01010000 (B) cx18-0: Invalid EEPROM cx18-0: Simultaneous Digital and Analog TV capture supported IRQ 22/cx18-0: IRQF_DISABLED is not guaranteed on shared IRQs cs5345 0-004c: chip found @ 0x98 (cx18 i2c driver #0-0) cx18-0: Registered device video1 for encoder MPEG (64 x 32 kB) DVB: registering new adapter (cx18) cx18-0: frontend initialization failed cx18-0: DVB failed to register cx18-0: Registered device video33 for encoder YUV (16 x 128 kB) cx18-0: Registered device vbi1 for encoder VBI (20 x 51984 bytes) cx18-0: Registered device video25 for encoder PCM audio (256 x 4 kB) cx18-0: Registered device radio1 for encoder radio cx18-0: Error -1 registering devices cx18-0: Error -1 on initialization cx18: probe of 0000:08:09.0 failed with error -1 cx18: End initialization
And it takes ages before going at the next step.
In fact, I do not need to have this card working and I don't want to make a lot of things described in some google searches to have it working.
Is there a way to tell udev to ignore this hardware and skip anything regarding it.
Thanks for any answer.
- -- François Patte UFR de mathématiques et informatique Université Paris Descartes 45, rue des Saints Pères F-75270 Paris Cedex 06 Tél. +33 (0)1 4286 2145 http://www.math-info.univ-paris5.fr/~patte
On Thu, 11 Aug 2011 20:55:51 +0200 François Patte wrote:
Is there a way to tell udev to ignore this hardware and skip anything regarding it.
I have often wondered this as well. I wish there were some way to specify PCI device IDs to be skipped on the kernel command line so the kernel would just leave that device out of the list at the earliest enumeration of devices and no one else would ever even know it was there.
On 08/11/2011 02:27 PM, Tom Horsley wrote:
On Thu, 11 Aug 2011 20:55:51 +0200 François Patte wrote:
Is there a way to tell udev to ignore this hardware and skip anything regarding it.
I have often wondered this as well. I wish there were some way to specify PCI device IDs to be skipped on the kernel command line so the kernel would just leave that device out of the list at the earliest enumeration of devices and no one else would ever even know it was there.
I do this for my Digium TDM400P card for Asterisk: /etc/modprobe.d/blacklist.netjet.conf
Which contains: # Blacklist the netjet driver for the 2.6.32 kernel as it prevents the # wctdm (TDM400P) driver from loading. blacklist netjet
You would do: blacklist cx18
On 08/12/2011 06:30 AM, Anthony Messina wrote:
On 08/11/2011 02:27 PM, Tom Horsley wrote:
On Thu, 11 Aug 2011 20:55:51 +0200 François Patte wrote:
Is there a way to tell udev to ignore this hardware and skip anything regarding it.
I have often wondered this as well. I wish there were some way to specify PCI device IDs to be skipped on the kernel command line so the kernel would just leave that device out of the list at the earliest enumeration of devices and no one else would ever even know it was there.
I do this for my Digium TDM400P card for Asterisk: /etc/modprobe.d/blacklist.netjet.conf
Which contains: # Blacklist the netjet driver for the 2.6.32 kernel as it prevents the # wctdm (TDM400P) driver from loading. blacklist netjet
You would do: blacklist cx18
There is also a kernel parameter rdblacklist=
Along with that, it may be a good idea to regenerate the initramfs with dracut to make sure the module isn't loaded at the earliest possible time.
-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1
Le 12/08/2011 01:17, Ed Greshko a écrit :
On 08/12/2011 06:30 AM, Anthony Messina wrote:
On 08/11/2011 02:27 PM, Tom Horsley wrote:
On Thu, 11 Aug 2011 20:55:51 +0200 François Patte wrote:
Is there a way to tell udev to ignore this hardware and skip anything regarding it.
I do this for my Digium TDM400P card for Asterisk: /etc/modprobe.d/blacklist.netjet.conf
Which contains: # Blacklist the netjet driver for the 2.6.32 kernel as it prevents the # wctdm (TDM400P) driver from loading. blacklist netjet
You would do: blacklist cx18
There is also a kernel parameter rdblacklist=
Along with that, it may be a good idea to regenerate the initramfs with dracut to make sure the module isn't loaded at the earliest possible time.
Thanks to both, it worked perfectly. - -- François Patte UFR de mathématiques et informatique Université Paris Descartes 45, rue des Saints Pères F-75270 Paris Cedex 06 Tél. +33 (0)1 4286 2145 http://www.math-info.univ-paris5.fr/~patte
-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1
Le 12/08/2011 11:09, François Patte a écrit :
Le 12/08/2011 01:17, Ed Greshko a écrit :
On 08/12/2011 06:30 AM, Anthony Messina wrote:
On 08/11/2011 02:27 PM, Tom Horsley wrote:
On Thu, 11 Aug 2011 20:55:51 +0200 François Patte wrote:
Is there a way to tell udev to ignore this hardware and skip anything regarding it.
I do this for my Digium TDM400P card for Asterisk: /etc/modprobe.d/blacklist.netjet.conf
Which contains: # Blacklist the netjet driver for the 2.6.32 kernel as it prevents the # wctdm (TDM400P) driver from loading. blacklist netjet
You would do: blacklist cx18
There is also a kernel parameter rdblacklist=
Along with that, it may be a good idea to regenerate the initramfs with dracut to make sure the module isn't loaded at the earliest possible time.
One more question: will it be necessary to regenerate the initramfs if the kernel is updated or the update process via yum will do the job?
Thank you.
- -- François Patte UFR de mathématiques et informatique Université Paris Descartes 45, rue des Saints Pères F-75270 Paris Cedex 06 Tél. +33 (0)1 4286 2145 http://www.math-info.univ-paris5.fr/~patte
"François Patte" francois.patte@mi.parisdescartes.fr wrote:
One more question: will it be necessary to regenerate the initramfs if the kernel is updated or the update process via yum will do the job?
No need to manually regenerate. When the new kernel is installed it creates a new initramfs file and since it is blacklisted, the driver it will be skipped in the same manner as if you were to do it manually.
-
Anthony Joseph Messina -
Ed Greshko -
François Patte -
Tom Horsley