Date: Mon, 3 Mar 2003 14:50:20 +0200 From: Aleksey Kukhar <tiran@azuritesoft.com> To: Bruce Evans <bde@zeta.org.au> Cc: freebsd-hardware@FreeBSD.ORG Subject: Re[2]: multiport cards' operation problem on 5.0-RELEASE Message-ID: <1103036976.20030303145020@azuritesoft.com> In-Reply-To: <20030303232557.T33704-100000@gamplex.bde.org> References: <20030303232557.T33704-100000@gamplex.bde.org>
next in thread | previous in thread | raw e-mail | index | archive | help
Hello Bruce, Monday, March 3, 2003, 2:39:50 PM, you wrote: BE> On Mon, 3 Mar 2003, Aleksey Kukhar wrote: >> Please advice me. I have computer with ancient isa multiport card in >> it. A couple of days before we have switched to 5.0-RELEASE from >> 4.2-RELEASE. Now I am experiencing problems with the multiport card. >> No hardware settings (including BIOS) were changed. >> >> Kernel reports that "sioXX: configured irq 10 not in bitmap of probed >> irqs 0". Irq 10 is dedicated (BIOS) to legacy ISA devices. >> >> Please, help me with this issue. I include some useful information >> about my system here (a-e): BE> Is anything actually broken? The above message is only to help diagnose BE> non-working interrupts. It is printed if interrupts are broken at BE> probe time. Interrupts might be broken at probe time but work later. Yes, I have problems. Standard serial ports work perfectly while ports from multiport card cause "silo overflow" messages. >> a) 4.2-RELEASE kernel messages (everything is ok): >> > ... >> > : sio2 at port 0x180-0x187 irq 10 flags 0x205 on isa0 >> > : sio2: type 16550A (multiport master) >> > : sio3 at port 0x188-0x18f flags 0x205 on isa0 >> > : sio3: type 16550A (multiport) >> > ... >> > : sio9 at port 0x1b8-0x1bf flags 0x205 on isa0 >> > : sio9: type 16550A (multiport) >> c) 5.0-RELEASE, fragment of /boot/device.hints (ports of multiport >> card are sio4-sio11): >> ... >> > hint.sio.4.at="isa" >> > hint.sio.4.port="0x180" >> > hint.sio.4.flags="0x405" >> > hint.sio.4.irq="10" >> > hint.sio.5.at="isa" >> > hint.sio.5.port="0x188" >> > hint.sio.5.flags="0x405" >> > ... >> > hint.sio.11.at="isa" >> > hint.sio.11.port="0x1b8" >> > hint.sio.11.flags="0x405" BE> The new configuration seems to be OK, but is different (the master port BE> is 4 instead of 2). I tried numbering from 2 to 9 (the situation was the same) but to avoid undiscovered errors I have made my configuration more similar to examples from sio(4) man page. >> d) 5.0-RELEASE, some kernel messages from boot sequence: >> > ... >> > : sio10: configured irq 10 not in bitmap of probed irqs 0 >> > : sio10: port may not be enabled >> > : sio10 at port 0x1b0-0x1b7 flags 0x405 on isa0 >> > : sio10: type 16550A (multiport) >> > : sio11: configured irq 10 not in bitmap of probed irqs 0 >> > : sio11: port may not be enabled >> > : sio11 at port 0x1b8-0x1bf flags 0x405 on isa0 >> > : sio11: type 16550A (multiport) >> > : sio4: configured irq 10 not in bitmap of probed irqs 0 >> > : sio4: port may not be enabled >> > : sio4 at port 0x180-0x187 irq 10 flags 0x405 on isa0 >> > : sio4: type 16550A (multiport master) >> > : ... >> > : sio9: configured irq 10 not in bitmap of probed irqs 0 >> > : sio9: port may not be enabled >> > : sio9 at port 0x1a8-0x1af flags 0x405 on isa0 >> > : sio9: type 16550A (multiport) BE> Something unsorted sio10-sio11. All the sio ports are in numerical BE> order in hints but are in lexical order for probes. This shouldn't BE> matter, but the code that is supposed to give order independence was BE> broken a long time ago and never fixed (it is inside `#if 0' in both BE> RELENG_4 and -current). BE> I don't see how this can be fatal or give misbehaviour much different BE> from in RELENG_4. I would have expected the "not in bitmap" warning BE> more consistently. You seem to have accidentally avoided the disordering BE> of sio10-sio11 in RELENG_4 by only using 1-digit port numbers. Try BE> deleting sio2-sio3 from hints and moving sio4-sio11 down to sio2-9 to BE> get the same configuration as in RELENG_4. Try to duplicate the problem BE> with RELENG_4 by misconfiguring to get -current's strange probe order. I have explained above that problem was not cause by the way kernel sorts its hints. -- Best regards, Aleksey mailto:tiran@azuritesoft.com To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-hardware" in the body of the message
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?1103036976.20030303145020>