Date: Tue, 02 Nov 2004 22:16:35 +0200 From: Stasys Smailys <ssmailys@komvista.lt> To: "[FreeBSD-AMD64]" <freebsd-amd64@freebsd.org> Subject: ioctl() 64-bit issues Message-ID: <4187EB23.1060407@komvista.lt>
next in thread | raw e-mail | index | archive | help
Hi, all! I think we have a problem here at least it seems so to me. Trying to fix an infinite loop that occured in usr.sbin/burncd/burncd.c when I have tried to blank cdrw disc I discovered that sys/ioccom.h [...] int ioctl(int, unsigned long, ...); [...] usr.sbin/burncd/burncd.c [...] int blank, pct, last = 0; [...] if (ioctl(fd, CDRIOCGETPROGRESS, &pct) == -1) err(EX_IOERR,"ioctl(CDRIOGETPROGRESS)"); [...] always returns a zero value in pct (pct == 0). By the way there is a typo in burncd.c: the second CDRIOCGETPROGRESS misses 'C'. Anyway it is not essential. As you can see by yourself in that case the loop becomes infinite. Further investigations showed me that pct gets overwritten every ioctl's call by CDRIOCGETPROGRESS constant's upper bytes. At the moment of ioctl's call the CDRIOCGETPROGRESS value is 0x0000004004636f. I suppose this is not the only case. May be this case and PR amd64/69704 (ext2/ext3 unstable in amd64) are interconnected somehow, because both use sys/ioccom.h. May be some others too. I don't know. Here is something to start: http://docsun.cites.uiuc.edu/sun_docs/C/solaris_9/SUNWdev/SOL64TRANS/p15.html -- WBR Stasys Smailys
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?4187EB23.1060407>