Date: Mon, 28 Mar 2011 08:18:06 -0400 From: John Baldwin <jhb@freebsd.org> To: freebsd-hardware@freebsd.org Cc: Steven Nikkel <steven_nikkel@ertyu.org> Subject: Re: 8.x and Modems Message-ID: <201103280818.06763.jhb@freebsd.org> In-Reply-To: <B5525815-7F7F-4723-B99B-0C9A78A9DB4E@ertyu.org> References: <3052ba363957ef179b4531ed0362d494.squirrel@www2.ertyu.org> <201103241315.28747.jhb@freebsd.org> <B5525815-7F7F-4723-B99B-0C9A78A9DB4E@ertyu.org>
next in thread | previous in thread | raw e-mail | index | archive | help
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
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?201103280818.06763.jhb>