Date: Mon, 03 Apr 2000 14:50:44 -0600 From: Warner Losh <imp@village.org> To: nate@yogotech.com (Nate Williams) Cc: Randy Bush <randy@psg.com>, Nick Hibma <n_hibma@calcaphon.com>, FreeBSD Laptoppers <freebsd-mobile@FreeBSD.ORG> Subject: Re: usb on vaio 505tx Message-ID: <200004032050.OAA63575@harmony.village.org> In-Reply-To: Your message of "Mon, 03 Apr 2000 14:33:43 MDT." <200004032033.OAA00900@nomad.yogotech.com> References: <200004032033.OAA00900@nomad.yogotech.com> <E12cBL7-000IuE-00@rip.psg.com> <E12c8Bj-000Hhr-00@rip.psg.com> <E12c7bd-000HUo-00@rip.psg.com> <Pine.BSF.4.20.0004031519420.10760-100000@localhost> <200004031804.MAA62588@harmony.village.org> <200004031917.NAA62888@harmony.village.org>
next in thread | previous in thread | raw e-mail | index | archive | help
In message <200004032033.OAA00900@nomad.yogotech.com> Nate Williams writes: : This may be a known 'race' in the existing code that Guido and I both : attempted to fix. While that problem might exist, in this case I think something else is going on. I believe that the bridge chips are being reset by the BIOS in the suspend routine and then not properly resotred in the resume routine to bring them back to a known state. The driver doesn't even see the card events. The pcic chip is alive (since timeouts work), just disconnected from the interrupt stream. This seems to be true even if we explicitly reconnect the management irq in the resume routine. That's what leads me to believe that one of the other bridge chips involved is being put in a strange state. It has been a while since I looked at the problem, so maybe my recollection of it is stale and obsolete. Warner To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-mobile" in the body of the message
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?200004032050.OAA63575>