From owner-freebsd-bugs Wed Jun 7 2:58:17 2000 Delivered-To: freebsd-bugs@freebsd.org Received: from mailman.zeta.org.au (mailman.zeta.org.au [203.26.10.16]) by hub.freebsd.org (Postfix) with ESMTP id 818CA37BB88; Wed, 7 Jun 2000 02:58:07 -0700 (PDT) (envelope-from bde@zeta.org.au) Received: from bde.zeta.org.au (bde.zeta.org.au [203.2.228.102]) by mailman.zeta.org.au (8.8.7/8.8.7) with ESMTP id TAA17144; Wed, 7 Jun 2000 19:57:55 +1000 Date: Wed, 7 Jun 2000 19:57:50 +1000 (EST) From: Bruce Evans X-Sender: bde@besplex.bde.org To: Leonid Lukiyanets Cc: freebsd-bugs@FreeBSD.ORG, dfr@FreeBSD.ORG, yokota@FreeBSD.ORG Subject: Re: sio number cannot be over 25??? In-Reply-To: <20000603052347.26386.qmail@hotmail.com> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-freebsd-bugs@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.org On Sat, 3 Jun 2000, Leonid Lukiyanets wrote: > I am upgrading from 3.4 to 4.0 version. > In my system 3 Moxa multiport adapters are used. > So my usual setup is sio0 for com1, sio25 for com2 and sio1 to sio 24 > assigned to multiports. > Everything worked perfectly fine with FreeBSD 3.4, but when I tried to > compile such a kernel under 4.0 version my keyboard stopped working after > reboot. > After numerous kernel experiments I have discovered that when I assign sio > with number over 24 to com2 the system fails to load keyboard driver. Allocation of unit numbers is quite broken in 4.0 and -current. It happens to work for the normal allocation order { 0, 1, 2, ... }, but your configuration gives the order { 0, 25, 1, 2, ... } for sio. When the unit number for sio25 is allocated, only enough space for 8 units is actually allocated. The short amount of space happens to be allocated a bit below the resource entry for atkbdc's ports, and the assignment to dc->devices[dev->unit] happens to corrupt the `type' member in this entry, so the first call to atkbdc_probe() fails because the ports can't be found. Fortunately, the corruption with my configuration was in the same place as you reported, so it was easy to reproduce the bug. Fix: diff -c2 subr_bus.c~ subr_bus.c *** subr_bus.c~ Sun May 28 16:05:23 2000 --- subr_bus.c Wed Jun 7 18:54:51 2000 *************** *** 377,382 **** int newsize; ! newsize = (dc->maxunit ? 2 * dc->maxunit ! : MINALLOCSIZE / sizeof(device_t)); newlist = malloc(sizeof(device_t) * newsize, M_BUS, M_NOWAIT); if (!newlist) --- 377,381 ---- int newsize; ! newsize = roundup((unit + 1), MINALLOCSIZE / sizeof(device_t)); newlist = malloc(sizeof(device_t) * newsize, M_BUS, M_NOWAIT); if (!newlist) I didn't bother rounding up the allocation size to a power of 2 like the old code attempted. Minor bugs found while investigating this: atkbdc_probe() is called later for the PNP entry that normally causes the warning "unknown: can't assign resources" on an Abit BP6 motherboard. When the initial probe fails due to the bug, the second probe succeeds, so the message "atkbdc1: at port 0x60,0x64 irq 1 on isa0" is printed instead of the warning, but the unit number is bogus, and atkbdc_attach() fails and the message: "device_probe_and_attach: atkbdc1 attach returned 12" is printed. Here "12" is ENOMEM, which is returned by atkbdc_attach() when atkbdc_get_softc() fails, but the error has nothing to do with memory allocation failure. Bruce To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-bugs" in the body of the message