Hello everybody, The following solved my immediate need, but it's a kludge rather than a solution.
1) I pulled RAM chips out of my computer and let it run with 1 GB of memory. Reducing the size of physical memory to 2 GB was not enough. I suppose adding a mem=1GB option to /boot/grub/grub.conf, as Klaus suggested, should also solved the problem. 2) Kernel detects my Miro DC30 card and loads the driver, but does not do so correctly. I have to remove the driver manually and reload it with "card=3" option: # rmmod zr36067 # modprobe zr36067 card=3 Ad 1) I suppose the proper solution would be to integrate patches for 64-bit systems upstream. Ad 2) Back in the old times, we users of DC30 needed to add a line saying "options zr36067 card=3" to /etc/modprobe.conf. I have to figure it out where in the /etc/modprobe.d/ hierarchy this fits. Thank you all for your help! Best regards, Primož 2010/5/17 Klaus Stengel <klaus.sten...@asamnet.de>: > Hi, > > Am Montag, den 17.05.2010, 22:14 +0200 schrieb Primoz PETERLIN: >> 2010/5/17 Klaus Stengel <klaus.sten...@asamnet.de>: >> > Bernhard Praschinger wrote: >> >> I'd really like to hear of a success story (or how you call it). That a >> >> zoran card works on a 64 bit machine with a 64bit kernel. >> > >> > I have a DC10+ running with a 64-bit Linux 2.6.26 on Intel Core2 >> > Machine. But I had to do some modifications to the driver because the >> > Zoran card can only adress the lower 32-bit of RAM with its DMA engine >> > so the buffers for data transfer need to be allocated in that area. I >> > did post the necessary changes for some older Kernel versions two years >> > ago on the developer list, but I didn't receive much feedback iirc. >> >> Now that's interesting. Could it be that it worked for me because I >> didn't have more than 4 GB of memory? (Yes, I know, you may ask why >> would one bother at all with a 64-bit system in that case). > > Well, it's certainly related. The more memory you have, the bigger are > the odds that the buffers will be allocated outside the 4 GB that can be > addressed with 32 bits. But even if you don't have more than 4 GB of > RAM, most Mainboards start to map parts of the available memory into the > bigger address space much earlier. You can check this if you run the > command: > > cat /proc/iomem | grep 'System RAM' > > The output should look something like this: > 00000000-0009ebff : System RAM > 00100000-bd4a0fff : System RAM > bd4a7000-bd5b6fff : System RAM > bd60f000-bd6c5fff : System RAM > bd9ff000-bd9fffff : System RAM > 100000000-13bffffff : System RAM > > If there are (hex-)numbers which have more than 8 digits, you definitely > have some memory areas that require 64-bits to be accessed. For the > machine from the example above, everything above 3033 MB (=bd9fffff hex) > was remapped beyond the 4 GB limit. It might be possible that your > machine already does this sort of remapping and if parts of the data > buffers happen to be allocated in one of those remapped areas, the > driver will fail. That's also the reason why passing mem=4G as kernel > parameter most certainly won't help, but limiting the used memory to 2 > GB should be safe for most boards. > > Regards, > Klaus. > > > ------------------------------------------------------------------------------ > > _______________________________________________ > Mjpeg-users mailing list > Mjpeg-users@lists.sourceforge.net > https://lists.sourceforge.net/lists/listinfo/mjpeg-users > -- Primož Peterlin, Inštitut za biofiziko, Med. fakulteta, Univerza v Ljubljani Lipičeva 2, SI-1000 Ljubljana, Slovenija. primoz.peter...@mf.uni-lj.si Tel +386-1-5437612, fax +386-1-4315127, http://biofiz.mf.uni-lj.si/~peterlin/ F8021D69 OpenPGP fingerprint: CB 6F F1 EE D9 67 E0 2F 0B 59 AF 0D 79 56 19 0F ------------------------------------------------------------------------------ _______________________________________________ Mjpeg-users mailing list Mjpeg-users@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/mjpeg-users
