On Sat, Sep 16, 2000 at 06:07:37PM -0400, Peter Radcliffe wrote: > Jordan Hubbard <[EMAIL PROTECTED]> probably said: > > standard configuration, I'll be rolling a network-only patch release > > to 4.1 called 4.1.1. If you therefore have anything to MFC, please > > do the following: > > Can we _please_ get these two patches into at least -stable before or > after this release cut ? > > Many of us have been using them for months and they make the built in > ether and sound work through a suspend/resume on my laptop; > > http://www.FreeBSD.org/cgi/query-pr.cgi?pr=18756 > http://www.freebsd.org/cgi/query-pr.cgi?pr=20255 cameron grant committed an alternate (and cleaner) fix based on PR 20891 to -current for the yamaha ds1 pcm suspend/resume problem a couple weeks ago. here's the commit message: http://docs.freebsd.org/cgi/getmsg.cgi?fetch=399173+0+archive/2000/cvs-all/20000903.cvs-all i just got around to patching this into my -stable system earlier today, and while there are some minor issues (stuttering during suspend, suspend/resume stops xmms), it's a big step in the right direction: the audio device is usable after a resume. presumably this will be mfc-ed eventually. i'll write up a more detailed report (i.e. a patch) for those minor problems hopefully within the next few days, if nobody beats me to it... the fxp fix (PR 18756), on the other hand, has gone nowhere. david greenman expressed concern about one bit of the patch (see the PR for details), then disappeared. i've sent him a couple messages (on may 22, also in the PR, and again august 26th in private mail) asking if he had any advice on how to fix the fix, but i've gotten no response. i saw a message on cvs-all a few days ago suggesting that he had "resigned in a huff a few months ago", so perhaps this got orphaned then? more importantly, maybe somebody on this list can help? briefly: after a suspend/resume on some sony laptops, the fxp device needs to have certain PCI registers reset, notably including the memory mapped base address registers. in several places the fxp driver issues a command, then busy-waits on a DMA indicating completion. if such a command is issued before the base address registers have been reprogrammed, the kernel will wait forever for a DMA that'll never occur. CSR_READs will hang the kernel similarly. the patch in PR 18756 does several things, mostly based on ideas from the netbsd and linux drivers: - saves and restores sufficient PCI registers across suspend/resume. - adds timeouts to DMA busy-waits. - attempts to avoid handling interrupts before the device has been resumed, to prevent hanging on the CSR_READ at the top of fxp_intr(). it's the latter that DG thought might be a problem. the intent (and effect, at least on my sony z505hs) was to protect against shared interrupts delivered before the device is resumed. on my machine, the fxp and uhci devices share irq 9. if the uhci controller is resumed and generates an irq before the fxp device is resumed, the fxp_intr() routine is also called and the machine freezes. i wouldn't be at all surprised if there were a better approach than simply ignoring interrupts when the device isn't running, but it's not clear to me what that would be. if anybody has any suggestions as to how to clean this up, i'm all ears. alternately, if any committers want to take this on, that'd be swell too. To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-stable" in the body of the message
