On Thu, 2008-12-25 at 19:50 -0800, Ben Vlug wrote: > 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
> VmallocTotal: 114680 kB > VmallocUsed: 79900 kB > VmallocChunk: 28148 kB Total = 112 MB Used = 78 MB (Remaining = 34 MB) Largest remaining chunk = 27.5 MB You really should add a 'vmalloc=256M' or higher to your kernel command line. There's no need to be very conservative here, unless you like headaches. You're not wasting large amounts of system memory by setting it higher; you're only "wasting" page table entries that you likely aren't using anyway. (It's not real system memory that's used for IO mappings, it's memory and register space on devices across the PCI bus.) > [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 This won't be interesting to me until I see what IRQ the cx18 driver gets mapped to. The 10.8 million eth0+nvidia interrupts do look a little insane: 6 eth0+nvidia interrupts per local timer interrupt. I wonder for what events the nvidia driver has setup to watch from the graphics chip. (Note that once you get the 1600 cards in and working, on this single core machine with a high interrupt rate, you may have to set the cx18 module parameters for individual buffer sizes [e.g. enc_mpg_bufsize=32] a little larger than default, just so the system interrupt service latency doesn't cause you to loose data from the CX23418 encoder.) Regards, Andy ________________________________________________________________________ > 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
