From owner-freebsd-mobile@FreeBSD.ORG Mon May 17 04:31:44 2004 Return-Path: Delivered-To: freebsd-mobile@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 7799116A4CE; Mon, 17 May 2004 04:31:44 -0700 (PDT) Received: from smtp.newipnet.com (5.Red-80-32-157.pooles.rima-tde.net [80.32.157.5]) by mx1.FreeBSD.org (Postfix) with ESMTP id 97DBC43D54; Mon, 17 May 2004 04:31:40 -0700 (PDT) (envelope-from freebsd@newipnet.com) Received: by smtp.newipnet.com (ESMTP Server, from userid 511) id 9F2062051C; Mon, 17 May 2004 13:31:37 +0200 (CEST) Received: from madre (madre.newipnet.com [192.168.128.4]) by smtp.newipnet.com (ESMTP Server) with ESMTP id 8F36B20608; Mon, 17 May 2004 13:31:25 +0200 (CEST) Message-ID: <200405171330450414.08078360@192.168.128.16> In-Reply-To: <20040506151240.J19057@gamplex.bde.org> References: <200405021259230046.12648609@192.168.128.16> <200405022224250625.14440A3D@192.168.128.16> <20040505233435.B15444@gamplex.bde.org> <200405051746300245.2039F9A4@192.168.128.16> <20040506151240.J19057@gamplex.bde.org> X-Mailer: Courier 3.50.00.09.1097 (http://www.rosecitysoftware.com) (P) Date: Mon, 17 May 2004 13:30:45 +0200 From: "Carlos Velasco" To: "Bruce Evans" Content-Type: text/plain; charset="us-ascii" X-Spam-Checker-Version: SpamAssassin 2.63 (2004-01-11) on atlas.newipnet.com X-Spam-Level: X-Spam-Status: No, hits=-104.9 required=5.0 tests=BAYES_00,USER_IN_WHITELIST autolearn=ham version=2.63 cc: freebsd-current@freebsd.org cc: scott@uk.freebsd.org cc: freebsd-mobile@freebsd.org Subject: Re[5]: Modem + Network in Xircom cards, and maybe others X-BeenThere: freebsd-mobile@freebsd.org X-Mailman-Version: 2.1.1 Precedence: list List-Id: Mobile computing with FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 17 May 2004 11:31:44 -0000 On 06/05/2004 at 16:44 Bruce Evans wrote: >On Wed, 5 May 2004, Carlos Velasco wrote: > >> On 06/05/2004 at 0:26 Bruce Evans wrote: >> >> >However, you may need only this part of it. This part permits software >> >interrupts to be delayed by 38 ticks instead of the expected maximim >> >of 2 ticks. I keep forgetting to fix this. Scaling by hz is not quite Yes, this patch in sio.c seems to work perfectly. So I think sio swi is being delayed somewhere by Giant or any other thing. >> >right, because hz may be set to values that are too small to work all >> >the time or even most of the time. There is a clamp to 128 (min), but >> >this is a bit small. E.g., with hz = 1000 and speed = 115200, the >> >original code in the above gives cp4ticks = 44 and ibufsize = 128. If what about if we fix the value or making it adjustable via sysctl? >The broken interrupt priorities are easy to see in "ps laxw | sort -n +4" >output. Note that the highest priorities are numerically lowest: > 0 27 0 0 -48 0 0 12 - WL ?? 0:00.06 (swi8: >tty:cy+ clock) > > [I think this is supposed to be the low priority softclock ithread > (the "slow" cy and sio SWIs attach to it and misname themselves as > tty:cy and tty:sio instead of clk:cy and clk:sio). It actually has > _highest_ priority among SWIs, so the problem is sort of the opposite > of what I thought, but mostly worse. The "slow" cy and sio SWIs > actually have the same bogus high priority, so they don't compete > with other SWIs. However, they compete with softclock, and all > other SWIs have lower priority than softclock so they don't even > compete with it. This is the reverse of what is supposed to > happen. I think softclock starts with the correct low priority, but > its priority gets clobbered when the cy and sio SWIs attach to it. > > 0 37 0 0 -48 0 0 12 - WL ?? 0:00.00 (swi0: >tty:cy+) > > [I think this is the "fast" cy and sio SWI. Verbose names which get > truncated complicate debugging.] I have here: 0 22 0 0 -80 0 0 12 - WL ?? 0:00.01 (irq11: cbb0 cbb1+) ... 0 28 0 0 -48 0 0 12 - WL ?? 0:01.74 (swi8: tty:sio clock) 0 39 0 0 -48 0 0 12 - WL ?? 0:00.00 (swi0: tty:sio) So, I assume you are right. >> I believe this patch to sio.c is only a temporary solution that should be >> removed when GIANT dissapears in most drivers, am I right? > >No, it (the cp4ticks one) is a more general patch, though it is temporary >because it is not in its final form. Best-case interrupt latency cannot >be guaranteed for SWIs, and even a saftey margin of a factor of 4 is not >enough even without the Giant and priority bugs, since it doesn't scale >right when "hz" is configured to large values, and configuring "hz" to >too-large values is now encouraged by DEVICE_POLLING. Could we commit it or something similar? I think sio is normal mode is broken for high speeds cause this like my problem with modem pccard. Regards, Carlos Velasco