From owner-freebsd-amd64@FreeBSD.ORG Tue Nov 2 19:31:32 2004 Return-Path: Delivered-To: freebsd-amd64@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id EB90716A4CE for ; Tue, 2 Nov 2004 19:31:32 +0000 (GMT) Received: from canning.wemm.org (canning.wemm.org [192.203.228.65]) by mx1.FreeBSD.org (Postfix) with ESMTP id D267F43D2F for ; Tue, 2 Nov 2004 19:31:32 +0000 (GMT) (envelope-from peter@wemm.org) Received: from fw.wemm.org (canning.wemm.org [192.203.228.65]) by canning.wemm.org (Postfix) with ESMTP id B23F82A8F1 for ; Tue, 2 Nov 2004 11:31:32 -0800 (PST) (envelope-from peter@wemm.org) Received: from overcee.wemm.org (overcee.wemm.org [10.0.0.3]) by fw.wemm.org (Postfix) with ESMTP id 3C61FE2B3 for ; Tue, 2 Nov 2004 11:31:32 -0800 (PST) (envelope-from peter@wemm.org) Received: from overcee.wemm.org (localhost [127.0.0.1]) by overcee.wemm.org (8.13.1/8.13.1) with ESMTP id iA2JVVUf006729; Tue, 2 Nov 2004 11:31:31 -0800 (PST) (envelope-from peter@wemm.org) Received: from localhost (localhost [[UNIX: localhost]]) by overcee.wemm.org (8.13.1/8.13.1/Submit) id iA2JVUdI006728; Tue, 2 Nov 2004 11:31:30 -0800 (PST) (envelope-from peter@wemm.org) X-Authentication-Warning: overcee.wemm.org: peter set sender to peter@wemm.org using -f From: Peter Wemm To: freebsd-amd64@freebsd.org Date: Tue, 2 Nov 2004 12:31:30 -0700 User-Agent: KMail/1.7 References: <4187EB23.1060407@komvista.lt> In-Reply-To: <4187EB23.1060407@komvista.lt> MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit Content-Disposition: inline Message-Id: <200411021131.30701.peter@wemm.org> cc: Stasys Smailys Subject: Re: ioctl() 64-bit issues X-BeenThere: freebsd-amd64@freebsd.org X-Mailman-Version: 2.1.1 Precedence: list List-Id: Porting FreeBSD to the AMD64 platform List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 02 Nov 2004 19:31:33 -0000 On Tuesday 02 November 2004 12:16 pm, Stasys Smailys wrote: > 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. If you have a look at cdrio.h: #define CDRIOCGETPROGRESS _IOR('c', 111, int) And the implementation is: case CDRIOCGETPROGRESS: error = acd_get_progress(cdp, (int *)addr); Compare to: #define CDRIOCSENDCUE _IOW('c', 104, struct cdr_cuesheet) burncd.c: if (ioctl(fd, CDRIOCSENDCUE, &sheet) < 0) atapi-cd.c: case CDRIOCSENDCUE: error = acd_send_cue(cdp, (struct cdr_cuesheet *)addr); Our ioctl wrapper code causes a copyin/copyout according to the IOR/IOW encoding. It should be an int, and is being accessed as though it were an int within the kernel. If I had to guess, I'm wondering if you got this info from gdb.. I don't trust gdb for this stuff yet. I'd be more concerned if it was printf("pct %d\n", pct) that told you this. If you want to try something, set pct to 12345 right before the ioctl call in case you're looking at random contents or something. I don't know what is wrong though. But my initial thought is that it isn't this... -- Peter Wemm - peter@wemm.org; peter@FreeBSD.org; peter@yahoo-inc.com "All of this is for nothing if we don't go to the stars" - JMS/B5