From owner-freebsd-stable@FreeBSD.ORG Tue Aug 16 20:57:30 2011 Return-Path: Delivered-To: freebsd-stable@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id B5C731065701; Tue, 16 Aug 2011 20:57:30 +0000 (UTC) (envelope-from yuri@rawbw.com) Received: from shell0.rawbw.com (shell0.rawbw.com [198.144.192.45]) by mx1.freebsd.org (Postfix) with ESMTP id 9D2DA8FC14; Tue, 16 Aug 2011 20:57:30 +0000 (UTC) Received: from eagle.yuri.org (stunnel@localhost [127.0.0.1]) (authenticated bits=0) by shell0.rawbw.com (8.14.4/8.14.4) with ESMTP id p7GKvQAb081091; Tue, 16 Aug 2011 13:57:26 -0700 (PDT) (envelope-from yuri@rawbw.com) Message-ID: <4E4AD9B6.2030001@rawbw.com> Date: Tue, 16 Aug 2011 13:57:26 -0700 From: Yuri User-Agent: Mozilla/5.0 (X11; FreeBSD amd64; rv:5.0) Gecko/20110716 Thunderbird/5.0 MIME-Version: 1.0 To: d@delphij.net References: <4E4A0C81.7020501@rawbw.com> <4E4A20BE.3060603@delphij.net> <4E4A3788.3030605@rawbw.com> <201108161157.20890.jhb@freebsd.org> <4E4ACAAD.3030506@rawbw.com> <4E4AD50E.6050906@delphij.net> In-Reply-To: <4E4AD50E.6050906@delphij.net> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Cc: freebsd-stable@freebsd.org, Xin LI , John Baldwin Subject: Re: How to use unrecognized COM port card? X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Production branch of FreeBSD source code List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 16 Aug 2011 20:57:30 -0000 On 08/16/2011 13:37, Xin LI wrote: > And I think John's patch is right, I've added a new PCI ID for it > though, found from the datasheet. Did you have uart(4) in your kernel > (remove my old patch)? Yes, uart(4) is in kernel and puc(4) is the loaded module. I think this might be a problem that puc(4) is a module loaded later and that's why serial device isn't registered. I found the reference to the similar situation with some other card that got cured when puc(4) was compiled into kernel. (http://www.adras.com/Quadtech-DSC-100-PCI-dual-serial-port-on-8-0R-i386.t6999-79.html) I have yet to try building puc(4) into kernel, but the way how I have it now is the default in GENERIC. Should uart(4) instead be removed from kernel and made loadable too to prevent such initialization order issue? Or what would be the right fix? Have too much stuff in kernel isn't right too. uart probably isn't used by 99% of users. Yuri