I'll have to try to get the messages off tommorrow... but I did get the other 
two for now. I did try 'vmalloc=nnnM' as you mentioned but perhaps I didn't put 
it high enough. I set it at 192M. BTW.. the 1600s are not in the box at the 
moment as I needed to get it running for company coming tommorrow. If you need 
me to pop it back in and resend the logs I can do that. Thanks for any help.


[r...@localhost ~]# cat /proc/meminfo
MemTotal:      1034868 kB
MemFree:         27260 kB
Buffers:         45504 kB
Cached:         607796 kB
SwapCached:          0 kB
Active:         371924 kB
Inactive:       543788 kB
HighTotal:      131008 kB
HighFree:          252 kB
LowTotal:       903860 kB
LowFree:         27008 kB
SwapTotal:     2031608 kB
SwapFree:      2031608 kB
Dirty:             168 kB
Writeback:           0 kB
AnonPages:      262380 kB
Mapped:          65684 kB
Slab:            18220 kB
SReclaimable:    10276 kB
SUnreclaim:       7944 kB
PageTables:       3912 kB
NFS_Unstable:        0 kB
Bounce:              0 kB
CommitLimit:   2549040 kB
Committed_AS:  1014068 kB
VmallocTotal:   114680 kB
VmallocUsed:     79900 kB
VmallocChunk:    28148 kB
HugePages_Total:     0
HugePages_Free:      0
HugePages_Rsvd:      0
HugePages_Surp:      0
Hugepagesize:     4096 kB
[r...@localhost ~]#

[r...@localhost ~]# cat /proc/interrupts
           CPU0
  0:        758   IO-APIC-edge      timer
  1:         10   IO-APIC-edge      i8042
  4:          2   IO-APIC-edge
  6:          6   IO-APIC-edge      floppy
  7:          0   IO-APIC-edge      parport0
  8:          1   IO-APIC-edge      rtc
  9:          0   IO-APIC-fasteoi   acpi
 12:        114   IO-APIC-edge      i8042
 14:        320   IO-APIC-edge      libata
 15:       7169   IO-APIC-edge      libata
 16:          0   IO-APIC-fasteoi   ehci_hcd:usb1, uhci_hcd:usb2, 
uhci_hcd:usb3, uhci_hcd:usb4, uhci_hcd:usb5
 17:      26327   IO-APIC-fasteoi   sata_via
 18:   10808189   IO-APIC-fasteoi   eth0, nvidia
 19:     340375   IO-APIC-fasteoi   ivtv0
 20:       3615   IO-APIC-fasteoi   VIA8237
 21:      36896   IO-APIC-fasteoi   ivtv1
 22:       2963   IO-APIC-fasteoi   ivtv2
NMI:          0   Non-maskable interrupts
LOC:    1795318   Local timer interrupts
RES:          0   Rescheduling interrupts
CAL:          0   function call interrupts
TLB:          0   TLB shootdowns
TRM:          0   Thermal event interrupts
SPU:          0   Spurious interrupts
ERR:          0
MIS:          0
[r...@localhost ~]#





________________________________
From: Andy Walls <[email protected]>
To: Ben Vlug <[email protected]>; User discussion about IVTV 
<[email protected]>
Sent: Thursday, December 25, 2008 8:32:33 PM
Subject: Re: [ivtv-users] NVidia and CX18

On Thu, 2008-12-25 at 16:52 -0800, Ben Vlug wrote:
> Forgive me if this is an "old" issue but it is frustrating me to no
> end. I am not "great" with linux but usually can get done what I need
> to.
>  
> I am running MythDora 5 with an NVidia card. I have 350 and 150
> Happauge cards in it.
>  
> I wanted to put the 1600 in it but have found that as soon as I
> install the CX18 drivers from this site that NVidia pukes and won't
> load XServer.
>  
> I have googled to no end so I am now asking for help here.
>  
> Any help is appreciated.

Please provide the segment of /var/log/messages from bootup to failure.

Also provide the output of

$ cat /proc/meminfo
$ cat /proc/interrupts


I suspect you'll have to add a 'vmalloc=nnnM' kernel commandline option
that is about 128 MB greater than the VmallocTotal reported
by /proc/meminfo.

The cx18 wants a single, contiguous 64 MB chunk of vmalloc addresses for
PCI IO mappings (not real system memory) and I suspect the Nvidia
graphics driver also wants a large contiguous chunk of vmalloc addresses
for PCI/AGP graphics IO mappings.  Between the two, I suspect you're
running out of large chunks of vmalloc addresses.

Another old problem that could be the case is that the nvidia graphics
card and cx18 are sharing an interrupt.  There was a problem that came
up in the past with the VIA(? maybe it was NVidia?) linux DRM (direct
rendering manager) driver stimulating interrupts but not claiming them.
The kernel shuts off the "offending" interrupt in this case.

Let's see what your logs say...

Regards,
Andy


> Thanks!
>  
> Ben


      
_______________________________________________
ivtv-users mailing list
[email protected]
http://ivtvdriver.org/mailman/listinfo/ivtv-users

Reply via email to