>Unless you're running PCI64 or PCI-X or PCIe, you're running at 33MHz; >Standard PCI hasn't changed much over the years. That 800MHz stuff you were >referring to is system memory speed and has absolutely nothing to do with >PCI.
Ahh, well nevermind then. I stand corrected. :) >I'm running my PVR350 in a Shuttle S55 (I think) X-PC. It's got a Celeron > 1.8 in it and that's it -- no HDD, it boots and runs off the network. Whoh cool, you can do that? Forgive me for asking, I'm sure you have a good reason, but why? I can see having a netboot front end. Is it that someone somewhere had a huge underutilized file server? (as I think of the 2.8TB server upstairs doing nothing except humming and awaiting a "use"... damn government budget rules :) ) Ooh idea, not original I'm sure, where can I get a sub sub sub micro sized netboot dumb terminal (cheap preferably)? I remember seeing one used in our library that was about the size of a small laptop back when they had hopes of controlling people's use of the internet. But anyways, if you can run a bi-directional video stream over 100mbits/s (I assume) Ethernet then the pci bus (127Mbytes/s?) should be bored to death. Which brings be back to my conclusion of DMA sharing deadlock. The motherboard/kernel getting confused on who is doing what with DMA and thereby assuming someone still has a lock on the channel and not freeing it. Until another packet of info knocks it back into order (the packet from ssh) and things start flowing again. I remember back from the DOS days you had to set a DMA and IRQ channel manually. Does that still hold today? I know windows (and I suppose Linux also) has the capability of sharing those DMA and IRQ channels. In windows sometimes you have to override the IRQ. Would manually fiddling with the DMA's help any? Or is this obsolete thinking? Brent PS. Whew I wish I could think of a book or something. I sure can write a lot about nothing :) -----Original Message----- From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of Andrew Kohlsmith Sent: Monday, February 14, 2005 7:06 AM To: [email protected] Subject: Re: [ivtv-devel] Lockup / System freeze w/ new PVR-350 On February 14, 2005 06:40 am, Brent Kilgore wrote: > Since you are willing to build a new one, I saw someone mention > somewhere that most if not all VIA and Intel mobo chipsets are > supported. YMMV. If you get in the 1.8GZ range this problem should > disappear from what I've been told. Get one of those new fangled 800mzh > intel bus things :) it should work like a dream. > > Overall, what I've seen about our problem, the bus speed seems to be the > limiting factor. CPU isn't the problem. I think my bus is running at > 66mzh. Probably anything you can buy now will make a difference Unless you're running PCI64 or PCI-X or PCIe, you're running at 33MHz; Standard PCI hasn't changed much over the years. That 800MHz stuff you were referring to is system memory speed and has absolutely nothing to do with PCI. I'm running my PVR350 in a Shuttle S55 (I think) X-PC. It's got a Celeron 1.8 in it and that's it -- no HDD, it boots and runs off the network. There are people running PVR350s in MUCH lower-end hardware without difficulty so I really doubt it the system. When I play back or record with the thing I'm at 0% CPU usage, which was the entire point of the card. -A. ------------------------------------------------------- SF email is sponsored by - The IT Product Guide Read honest & candid reviews on hundreds of IT Products from real users. Discover which products truly live up to the hype. Start reading now. http://ads.osdn.com/?ad_id=6595&alloc_id=14396&op=click _______________________________________________ ivtv-devel mailing list [email protected] https://lists.sourceforge.net/lists/listinfo/ivtv-devel ------------------------------------------------------- SF email is sponsored by - The IT Product Guide Read honest & candid reviews on hundreds of IT Products from real users. Discover which products truly live up to the hype. Start reading now. http://ads.osdn.com/?ad_id=6595&alloc_id=14396&op=click _______________________________________________ ivtv-devel mailing list [email protected] https://lists.sourceforge.net/lists/listinfo/ivtv-devel
