Date: Tue, 24 May 2005 13:49:34 +0200 From: Edgar Toernig <froese@gmx.de> To: Oliver Lehmann <lehmann@ans-netz.de> Cc: ports@FreeBSD.org, roger@freebsd.org Subject: Re: alevt fixed for amd64 - does it still work on i386? Message-ID: <20050524134934.3f366a42.froese@gmx.de> In-Reply-To: <20050524103944.6ae4a334.lehmann@ans-netz.de> References: <20050524103944.6ae4a334.lehmann@ans-netz.de>
next in thread | previous in thread | raw e-mail | index | archive | help
Oliver Lehmann wrote: > > It looks like I fixed alevt for amd64. But before I commit them, I want > to be shure that they won't break alevt support on i386. Can someone with > an i386 put the 3 attached files in his/her /usr/ports/misc/alevt/files > directory, do a make install and tell me if alevt is still working? > - seq = *(u32 *)&rawbuf[n - 4]; > + seq = *(u64 *)&rawbuf[n - 8]; Without testing I can tell you that it won't work on 32bit systems or on 64bit Linux. IMHO the right place to fix that would be the kernel driver - the frame counter is supposed to be a u32 not a u64 or a long. [UPDATE] I just browsed the FreeBSD sources. The relevant sections: src/sys/dev/bktr/bktr_reg.h: | | u_long vbi_sequence_number; /* sequence number for VBI */ src/sys/dev/bktr/bktr_core.c: | | unsigned int *seq_dest; |... | /* Write the VBI sequence number to the end of the vbi data */ | /* This is used by the AleVT teletext program */ | seq_dest = (unsigned int *)((unsigned char *)bktr->vbibuffer | + bktr->vbiinsert | + (VBI_DATA_SIZE - sizeof(bktr->vbi_sequence_number))); | *seq_dest = bktr->vbi_sequence_number; As one can see, the code is broken for 64bit. It stores an int but uses an offset for a long. It seems, someone (cognet?) already changed a couple of places to fix 64bit issues (changed a lot of u_long to uint32_t) and just forgot this one. Afaics, the patch is easy: src/sys/dev/bktr/bktr_reg.h: - u_long vbi_sequence_number; /* sequence number for VBI */ + int vbi_sequence_number; /* sequence number for VBI */ Ciao, ET. PS: The right change on AleVT to work around the driver bug would be: vbi.c: - seq = *(u32 *)&rawbuf[n - 4]; + seq = *(u32 *)&rawbuf[n - 8]; but of course that breaks all other platforms.
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?20050524134934.3f366a42.froese>