Date: Wed, 05 May 2004 17:46:30 +0200 From: "Carlos Velasco" <freebsd@newipnet.com> To: "Bruce Evans" <bde@zeta.org.au> Cc: freebsd-mobile@freebsd.org Subject: Re[4]: Modem + Network in Xircom cards, and maybe others Message-ID: <200405051746300245.2039F9A4@192.168.128.16> In-Reply-To: <20040505233435.B15444@gamplex.bde.org> References: <200405021259230046.12648609@192.168.128.16> <20040502.091407.20913778.imp@bsdimp.com> <200405022224250625.14440A3D@192.168.128.16> <200405051311330554.1F584985@192.168.128.16> <20040505233435.B15444@gamplex.bde.org>
next in thread | previous in thread | raw e-mail | index | archive | help
On 06/05/2004 at 0:26 Bruce Evans wrote: >It seems like a patch for MFC sincd it has mfc's in it (what is a MFC?). MFC == Multi Function PCMCIA cards. FreeBSD has yet support for REAL MFC cards. However Xircom and maybe other cards don't work as REAL MFC. Right now only the last function (usually Network function) is the one that works in these cards with CURRENT. I'm patching it to activate both functions (usually modem/serial and network). Network is in xe driver, however I'm passing modem to sio. It works, however sio reports interrupt-level buffer overflows when I'm above 2400bps, losing characters, and here is where I'm lost. >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 >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 >hz = 1000 actually worked, then the buffer would be drained every 1 >msec and would never have more than 12 characters in it, but the >software interrupt latency is apparently sometimes >= 12 msec so the >buffer overflows. There are some mii Giant hogs which sometimes delay >timeout processing for that long or nearly so (each). Lost here... I think understand that problem is related to GIANT driver delaying this, 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? >sio's software interrupt[s] should have a priority higher than timeouts, >but sio now has 2 software interrupts with one of them having the same >low priority as timeouts. This priority should work (in fact, old >versions of sio just use timeouts), but in RELENG_4 the priority is >much higher than that as a side effect of having only only the correct >number of SWIs (1). RELENG_4 may now depend on this. Sorry, totally lost here. Maybe problem is here? sio4: <Xircom CreditCard Ethernet 10/100 + Modem 56> at port 0x2e8-0x2ef irq 11 function 0 config 39 on pccard0 sio4: type 16550A sio4: unable to activate interrupt in fast mode - using normal mode Interrupt is in normal mode that has not a high priority? I don't know why sio activate interrupt in normal mode and can't do it in fast, though. Regards, Carlos Velasco
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?200405051746300245.2039F9A4>