From owner-freebsd-hardware@FreeBSD.ORG Mon Mar 28 12:18:08 2011 Return-Path: Delivered-To: freebsd-hardware@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 81728106566B for ; Mon, 28 Mar 2011 12:18:08 +0000 (UTC) (envelope-from jhb@freebsd.org) Received: from cyrus.watson.org (cyrus.watson.org [65.122.17.42]) by mx1.freebsd.org (Postfix) with ESMTP id 3D4CF8FC16 for ; Mon, 28 Mar 2011 12:18:08 +0000 (UTC) Received: from bigwig.baldwin.cx (66.111.2.69.static.nyinternet.net [66.111.2.69]) by cyrus.watson.org (Postfix) with ESMTPSA id CD01046B0D; Mon, 28 Mar 2011 08:18:07 -0400 (EDT) Received: from jhbbsd.localnet (unknown [209.249.190.124]) by bigwig.baldwin.cx (Postfix) with ESMTPSA id 6B78F8A01B; Mon, 28 Mar 2011 08:18:07 -0400 (EDT) From: John Baldwin To: freebsd-hardware@freebsd.org Date: Mon, 28 Mar 2011 08:18:06 -0400 User-Agent: KMail/1.13.5 (FreeBSD/8.2-CBSD-20110311; KDE/4.5.5; amd64; ; ) References: <3052ba363957ef179b4531ed0362d494.squirrel@www2.ertyu.org> <201103241315.28747.jhb@freebsd.org> In-Reply-To: MIME-Version: 1.0 Content-Type: Text/Plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit Message-Id: <201103280818.06763.jhb@freebsd.org> X-Greylist: Sender succeeded SMTP AUTH, not delayed by milter-greylist-4.2.6 (bigwig.baldwin.cx); Mon, 28 Mar 2011 08:18:07 -0400 (EDT) Cc: Steven Nikkel Subject: Re: 8.x and Modems X-BeenThere: freebsd-hardware@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: General discussion of FreeBSD hardware List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 28 Mar 2011 12:18:08 -0000 On Friday, March 25, 2011 10:17:21 am Steven Nikkel wrote: > On 2011-03-24, at 12:15 PM, John Baldwin wrote: > > > On Thursday, March 24, 2011 9:26:16 am Steven Nikkel wrote: > >> On Wed, 23 Mar 2011, John Baldwin wrote: > >> > >>> On Wednesday, March 23, 2011 1:34:54 am Steven Nikkel wrote: > >>>> On Tue, 22 Mar 2011, John Baldwin wrote: > >>>>>>> On Monday, March 21, 2011 5:17:19 pm steven_nikkel@ertyu.org wrote: > >>>>>>>> I recently upgraded my trusty old 4.x system to 8.1 and the one little > >>>>> bit > >>>>>>>> I can't get working is the internal ISA modem in the system. On 4.x it > >>>>> was > >>>>>>>> detected automatically by the sio driver: > >>>>>>>> > >>>>>>>> /kernel: sio4: <U.S. Robotics Sportster 33600 FAX/Voice Int> at > >>>>> port > >>>>>>>> 0x3e8-0x3ef irq 5 on isa0 > >>>>>>>> /kernel: sio4: type 16550A > >>>>>>> > >>>> > >>>> Ok, here's the proper verbose dump: http://pastebin.com/DJ1z0k4D > >>>> I've set it back to PnP mode and taken out all the specific hints. > >>> > >>> Hmm, no helpful bootverbose messages in the pnp.c code it seems. > >>> > >> I updated to 8.2 and patched pnp.c as you proposed. Here's the result: > >> http://pastebin.com/AWpiBxRA > >> > >> It is the modem that is causing those 'PnP device failed to report > >> resource data' > >> and I don't see it appear in devinfo. > > > > Yes, so the next step would be to instrument pnp_read_resources() to see > > exactly where it is failing. > > > > -- > > John Baldwin > > A first glance tells me the only thing that could be happening is a time out trying to read resources. So sure enough after a couple hours of compiling and reboots that is the issue. The first check shows it reads a few resources then times out trying to read one 45 bytes long. I updated the time out dramatically in pnp_get_resource_info to verify and sure enough PNP now successfully initializes the card. Curiously I looked at pnpinfo and it seems to use pretty much the exact same process, except it was working previously. (PS: I set the count to 1000 and delay to 100, extreme overkill, but I didn't want to wait for several kernel compiles to get it to work) Can you try just increasing the DELAY()? If that works I'll commit it. I wonder if DELAY(1) is broken somehow. (Would be odd if DELAY(2) worked for example, but DELAY(1) didn't.) > Here are some relevant snippets from dmesg with my debugging bits: http://pastebin.com/uKRReBc0 > > Now onto the next bit: uart doesn't seem to identify the card properly. This was about the same message I was getting when I hard coded the settings on the board (no-pnp) and put them in device.hints > > However, it does seem to produce results now when I try to use it. Different than previous usage, but at least appears to be useful. So is the card working correctly now? Is the only problem the string name in dmesg? -- John Baldwin