>> Do you have a large number of other devices / drivers loaded? I >> suspect another driver is burning through kernel memory before the >> saa7164 has a chance to be initialized. > > Nope nothing I can see Its actually the only addon card I have in this > system.. > I'd be buggered If 4GB of RAM is fragmented enough early on in the boot > stage...? I agree. > I've hunted but can't find a nice way to determine what contiguous blocks > are available.. > Noted there was a simple module that could be compiled in to test such > things, I'll play with that and see what it turns up.. Let us know how that goes. > >> I took a quick look at saa7164-fw.c this morning, I see no reason why >> the allocation is required at all. With a small patch the function >> could be made to memcpy from 'src' directly, dropping the need to >> allocate srcbuf what-so-ever. This would remove the need for the 4MB >> temporary allocation, and might get you past this issue, likely on to >> the next (user buffer allocations are also large - as I recall). Note >> that the 4MB allocation is temporary, so its not a long term saving, >> but it might get you past the hump. > > That was my thoughts exactly.. but I took a minimal fiddling approach to > begin with.. > I wasn't sure if there was some requirement for the memcpy_toio requiring a > specially allocated source..? can't see why.. > Was going to dig into that next as a side job.. At this stage the code is 7-8 years old, so I don't recall the rationale for why I did that back in 2008(?) - but looking at it today, I think its needless.... and its a fairly trivial thing to remove and test. -- Steven Toth - Kernel Labs http://www.kernellabs.com -- To unsubscribe from this list: send the line "unsubscribe linux-media" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html
