From owner-freebsd-hackers Fri Jul 7 11:26:15 1995 Return-Path: hackers-owner Received: (from majordom@localhost) by freefall.cdrom.com (8.6.10/8.6.6) id LAA19791 for hackers-outgoing; Fri, 7 Jul 1995 11:26:15 -0700 Received: from tserv.lodgenet.com (root@dial8.iw.net [204.157.148.57]) by freefall.cdrom.com (8.6.10/8.6.6) with ESMTP id LAA19772 for ; Fri, 7 Jul 1995 11:24:48 -0700 Received: from jake.lodgenet.com (jake.lodgenet.com [204.124.120.30]) by tserv.lodgenet.com (8.6.12/8.6.12) with ESMTP id NAA06704; Fri, 7 Jul 1995 13:25:48 -0500 Received: from localhost (localhost [127.0.0.1]) by jake.lodgenet.com (8.6.11/8.6.9) with SMTP id NAA06498; Fri, 7 Jul 1995 13:25:07 -0500 Message-Id: <199507071825.NAA06498@jake.lodgenet.com> X-Authentication-Warning: jake.lodgenet.com: Host localhost didn't use HELO protocol X-Mailer: exmh version 1.6 4/21/95 To: davidg@Root.COM cc: hackers@FreeBSD.org Subject: Re: Buslogic bt946 controller In-reply-to: Your message of "Fri, 07 Jul 1995 08:01:07 PDT." <199507071502.IAA00442@corbin.Root.COM> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Date: Fri, 07 Jul 1995 13:25:06 -0500 From: "Eric L. Hernes" Sender: hackers-owner@FreeBSD.org Precedence: bulk > >Has anyone gotten this controller to work with a custom kernel? > > > >I'm running current on it now, but I've had the same experience with > >2.0.5. The GENERIC kernel works fine, but if I try to use a custom kernel > >it will run for a while, then I get messages like: > > > > bt0 at 0x330 irq 11 drq 5 on isa > ... > > uart0 not probed due to I/O address conflict with bt0 at 0x330 > ... > > device uart0 at isa? port 0x330 irq 5 vector "m6850intr" > > Do you have a device conflict at 0x330 with the Buslogic and your sound > card (I assume that's what the 'uart0' is above)? > maybe, but why does it work with the GENERIC kernel and not my custom one, with exactly the same hardware? I've now discovered that with the generic kernel, the controller goes into `async only' mode, but with the custom kernel, it goes to `fast sync' mode. It appears that the logic to differentiate between these modes is pulled directly from the card. My immediate fix is to cheat and #ifdef for my machine to force `async only' mode, which appears to work. One possible reason for this behavior is that the other drivers in the generic kernel that probe 0x330 are affecting my controller into not thinking it can handle `fast sync' (which it apparently can't), and without these probes, the controller tries to go fast and falls apart. > -DG > eric. -- erich@lodgenet.com erich@rrnet.com