Skip site navigation (1)Skip section navigation (2)
Date:      Wed, 12 Jan 2005 07:29:48 -0700 (MST)
From:      "M. Warner Losh" <imp@bsdimp.com>
To:        nate@root.org
Cc:        freebsd-modile@freebsd.org
Subject:   Re: Suspend problem on FreeBSD 5.3-STABLE
Message-ID:  <20050112.072948.89901373.imp@bsdimp.com>
In-Reply-To: <41E4BC93.40608@root.org>
References:  <41E19C0E.6030400@root.org> <41E48E70.30807@vindaloo.com> <41E4BC93.40608@root.org>

next in thread | previous in thread | raw e-mail | index | archive | help
In message: <41E4BC93.40608@root.org>
            Nate Lawson <nate@root.org> writes:
: Christopher Sean Hilton wrote:
: > Nate Lawson wrote:
: >>
: >> My cardbus works fine after suspend/resume.  The only current bug is 
: >> the extremely long time before resume methods run that was introduced 
: >> in the past couple weeks.
: >>
: > 
: > This afternoon I retested. Here's a better description of the problem. 
: > My Netgear FA511 Card is not reinitialized after a suspend/resume cycle. 
: > I had thought that the problem was a cardbus issue but it only affects 
: > this one card. Some interesting information about this card: It's a 
: > 32bit cardbus adapter served by the dc driver. Plugging in a Netgear 
: > FA411 16 bit PCMCIA card after a suspend/resume works as expected. I 
: > will try to down the interface and kldunload the dc driver before 
: > shutdown to see if that helps.
: 
: That fits with my analysis as well.  It seems that cardbus handles 
: things fine but individual drivers may be lacking in suspend/resume support.

Cardbus should be detaching and reattaching the device.  So that's
clearly a bug in cardbus.  Individual drivers have no choice in this
matter, since we can't know if the cards that are there after the
resume were the ones we suspended with.  This doesn't matter too much
for NIC cards (but none of the drivers cope with MAC addresses
changing), but matters a great deal for things like flash cards.

: That's a good testing approach, btw.  If you find the dc(4) driver seems 
: to be the culprit, the next step is to go through any datasheets and 
: other OS drivers to see if you can find what we're doing differently.

I don't think that it is a dc problem.

Warner



Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?20050112.072948.89901373.imp>