Date: Tue, 23 Nov 2004 00:36:26 -0500 (EST) From: Paul Sandys <myj@nyct.net> To: "M. Warner Losh" <imp@bsdimp.com> Cc: freebsd-stable@FreeBSD.org Subject: Re: SIIG cards and puc Message-ID: <20041123002829.R70859@bsd3.nyct.net> In-Reply-To: <20041122.173636.102807556.imp@bsdimp.com> References: <20041120084456.GU57546@funkthat.com> <20041122113525.G31812@bsd3.nyct.net> <20041122.173636.102807556.imp@bsdimp.com>
next in thread | previous in thread | raw e-mail | index | archive | help
What was happening at the beginning, it was mangling data coming into the computer and 'cu -l /dev/cuaa5' was taking up 100% CPU in interrupt. It was only showing first 31 characters of input, then it froze until I hit Enter couple times and such. My original idea was "this thing claims to have 64 FIFO and it only shows 31 charaters", so I found the COM_FIFOSIZE option. Setting it didn't really help. Then I tried it together with setting the "0x00001 shared IRQs" - from sio manpage. That didn't help either. So I went through the sio.c code and found that the "COM_MULTIPORT" option is widely used in the interrupt routine, so I tried setting it - that card has only one interrupt, so it must be shared - right ? At that point, I got it to work, so I was happy. All of this was done on 4.10-STABLE machine. puc0: <SIIG Cyber Serial Dual PCI 16C650 (20x fanily)> port 0x3400-0x3407,0x3408 -0x340f irq 10 at device 7.0 on pci2 sio4: master device 0 not configured sio4: configured irq 10 not in bitmap of probed irqs 0 sio4: type 16550A lookalike with 64 bytes FIFO (multiport) sio5: master device 0 not configured sio5: configured irq 10 not in bitmap of probed irqs 0 sio5: type 16550A lookalike with 64 bytes FIFO (multiport) *** pucdata.c.orig Mon Nov 22 11:40:30 2004 --- pucdata.c Mon Nov 22 11:41:02 2004 *************** *** 539,546 **** { 0x131f, 0x2031, 0, 0 }, { 0xffff, 0xffff, 0, 0 }, { ! { PUC_PORT_TYPE_COM, 0x10, 0x00, COM_FREQ }, ! { PUC_PORT_TYPE_COM, 0x14, 0x00, COM_FREQ }, }, }, --- 539,546 ---- { 0x131f, 0x2031, 0, 0 }, { 0xffff, 0xffff, 0, 0 }, { ! { PUC_PORT_TYPE_COM, 0x10, 0x00, COM_FREQ, 0x40000001 }, ! { PUC_PORT_TYPE_COM, 0x14, 0x00, COM_FREQ, 0x40000001 }, }, }, I'm not really sure why it works now, but it does :) P. On Mon, 22 Nov 2004, M. Warner Losh wrote: > Date: Mon, 22 Nov 2004 17:36:36 -0700 (MST) > From: M. Warner Losh <imp@bsdimp.com> > To: gurney_j@resnet.uoregon.edu > Cc: myj@nyct.net, freebsd-stable@FreeBSD.org > Subject: Re: SIIG cards and puc > > In message: <20041122180515.GX57546@funkthat.com> > John-Mark Gurney <gurney_j@resnet.uoregon.edu> writes: > : Paul Sandys wrote this message on Mon, Nov 22, 2004 at 11:46 -0500: > : > The SIIG card I have does use shared interrupt for both ports, so I don't see > : > any other way around it. > : > > : > The 0x40000001 is a regular flag that's used by sio.c . I found an undocumented > : > feature in there, that allows you to set a FIFO size, so I used it in > : > combination with the shared irq flag. > : > : Ahh, yes... Then we now have the interesting problem that it appears > : that PUC and sio share flags... :( > : > : from puc.c: > : type = (sc->sc_desc.ports[i].flags & PUC_FLAGS_MEMORY) > : ? SYS_RES_MEMORY : SYS_RES_IOPORT; > : > : and: > : device_set_flags(sc->sc_ports[i].dev, > : sc->sc_desc.ports[i].flags); > : > : which means you are also turning on memory mapping for the card... > : > : I'm not comfortable including a flag for an undocumented feature as a > : standard part of the system.. Care to document it? :) > : > : Also, are you sure it's the ISMULTIPORT that needs to be set? (and not > : the MEMORY flag you are acidentally also setting?) From what I've read > : of the PUC driver, it handles the multiport case for you since it hands > : out the interrupts to the sio driver... see this comment above puc_intr: > : * This is an interrupt handler. For boards that can't tell us which > : * device generated the interrupt it just calls all the registered > : * handlers sequencially, but for boards that can tell us which > : > : hmmm.. that's probably how it gets around the fact that it doesn't need > : to pass in the multiport flag, so we should probably be clearing that > : flag before passing it down to the lower layers... > > You don't need the MULTIPORT to use PUC. If you do, then something in > the tables is setup right. MULTIPORT is only for ISA cards. So > that's clearly wrong. > > Can someone send me the patch for review. I've added devices to puc > in the past. > > Warner > <-_-_-_-_-_-_-_-_-_-_-_-_-_-_-_-_-_-_-_-_-_-_-_-_-_-_-_-_-_-_-_-_-_-_-_-_-> < myj@nyct.net Paul Sandys | New York Connect http://www.nyct.net > < network operations manager | Total Solution provider > <-------------------------------------------------------------------------> < " The Internet Solutions Provider You Can Count On ! " > <-_-_-_-_-_-_-_-_-_-_-_-_-_-_-_-_-_-_-_-_-_-_-_-_-_-_-_-_-_-_-_-_-_-_-_-_->
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?20041123002829.R70859>