Re: fxp suspend/resume hangs
in summary: PR kern/18756 contains a patch (against -stable, alas, This PR has been explicitly assigned to David Greenman and should be handled by him. As I pointed out in another message, nobody but he is likely to touch the fxp driver under any circumstances so it basically comes down to either him or nobody. - Jordan To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
Re: fxp suspend/resume hangs
appended below is an excerpt from a message sent to -stable earlier tonight, containing content of a type which kris kenneway correctly suggested would find a more suitable audience on -current. in summary: PR kern/18756 contains a patch (against -stable, alas, sorry) which fixes kernel hangs in the fxp driver on some laptops after a resume from suspend. while quite a few people appear to be using this patch successfully, it hasn't been committed -- david greenman had an entirely reasonable objection to one aspect of the patch's behavior. unfortunately, my knowledge of the kernel isn't sufficient to adequately address david's concerns, and though i've mailed him to ask for guidance twice over the past 4 months, i haven't received a response. that's probably my fault, i probably should have been mailing -current to being with. I can only find the 5/22 email regarding this, so I seem to have missed your second message. With over a thousand emails a day coming into my inbox, this shouldn't be too surprising. My response to the 5/22 message was this: ... This could be a problem. If an interrupt occurs, it must be acknowledged otherwise you'll be stuck in an infinit loop - PCI interrupts are level sensitive and must be cleared in the ISR. ... In short, while it may fix a hang in your laptop case, it opens the driver up to a hang if an unexpected interrupt occurs while IFF_RUNNING is clear. I think this is dangerous enough that I don't think the code should not be compiled as part of the standard driver. One just cannot ignore level- sensitive PCI interrupts. if anybody can offer any suggestions as to how to move forward with getting this patch to the point where it can be committed, i'd certainly appreciate it. alternately, any feedback on whether the patch is necessary and/or functional on your machine, laptop or no, would be interesting. 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. Someone needs to find out what the laptop is doing to the STATACK register that causes a hang when it is accessed. Failing any better resolution, I guess that the objected-to change could be committed with an ifdef. -DG David Greenman Co-founder, The FreeBSD Project - http://www.freebsd.org President, TeraSolutions, Inc. - http://www.terasolutions.com Pave the road of life with opportunities. To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
Re: fxp suspend/resume hangs
I've made a few changes to the patches which should address my primary
concerns. Instead of using IFF_RUNNING, I added a new softc variable to
track the suspended condition. Only the APM stuff should call suspend/resume,
so the interrupt logic should be uneffected in non-APM machines. Please try
these patches out and let me know if they work as expected. They should apply
and work with both -stable and -current.
-DG
David Greenman
Co-founder, The FreeBSD Project - http://www.freebsd.org
President, TeraSolutions, Inc. - http://www.terasolutions.com
Pave the road of life with opportunities.
Index: if_fxp.c
===
RCS file: /home/ncvs/src/sys/pci/if_fxp.c,v
retrieving revision 1.77.2.3
diff -c -r1.77.2.3 if_fxp.c
*** if_fxp.c2000/06/19 00:54:30 1.77.2.3
--- if_fxp.c2000/09/17 13:15:33
***
*** 125,135
--- 125,139
fxp_lwcopy(src, dst)
volatile u_int32_t *src, *dst;
{
+ #ifdef __i386__
+ *dst = *src;
+ #else
volatile u_int16_t *a = (volatile u_int16_t *)src;
volatile u_int16_t *b = (volatile u_int16_t *)dst;
b[0] = a[0];
b[1] = a[1];
+ #endif
}
/*
***
*** 215,220
--- 219,225
static void fxp_mediastatus __P((struct ifnet *, struct ifmediareq *));
static void fxp_set_media __P((struct fxp_softc *, int));
static __inline void fxp_scb_wait __P((struct fxp_softc *));
+ static __inline void fxp_dma_wait __P((volatile u_int16_t *, struct fxp_softc *sc));
static FXP_INTR_TYPE fxp_intr __P((void *));
static void fxp_start __P((struct ifnet *));
static int fxp_ioctl __P((struct ifnet *,
***
*** 283,290
struct fxp_softc *sc;
{
int i = 1;
! while (CSR_READ_1(sc, FXP_CSR_SCB_COMMAND) --i);
}
/*
--- 288,311
struct fxp_softc *sc;
{
int i = 1;
+
+ while (CSR_READ_1(sc, FXP_CSR_SCB_COMMAND) --i)
+ DELAY(2);
+ if (i == 0)
+ printf(FXP_FORMAT ": SCB timeout\n", FXP_ARGS(sc));
+ }
+
+ static __inline void
+ fxp_dma_wait(status, sc)
+ volatile u_int16_t *status;
+ struct fxp_softc *sc;
+ {
+ int i = 1;
! while (!(*status FXP_CB_STATUS_C) --i)
! DELAY(2);
! if (i == 0)
! printf(FXP_FORMAT ": DMA timeout\n", FXP_ARGS(sc));
}
/*
***
*** 679,690
--- 700,784
return 0;
}
+ /*
+ * Device suspend routine. Stop the interface and save some PCI
+ * settings in case the BIOS doesn't restore them properly on
+ * resume.
+ */
+ static int
+ fxp_suspend(device_t dev)
+ {
+ struct fxp_softc *sc = device_get_softc(dev);
+ int i, s;
+
+ s = splimp();
+
+ fxp_stop(sc);
+
+ for (i=0; i5; i++)
+ sc-saved_maps[i] = pci_read_config(dev, PCIR_MAPS + i*4, 4);
+ sc-saved_biosaddr = pci_read_config(dev, PCIR_BIOS, 4);
+ sc-saved_intline = pci_read_config(dev, PCIR_INTLINE, 1);
+ sc-saved_cachelnsz = pci_read_config(dev, PCIR_CACHELNSZ, 1);
+ sc-saved_lattimer = pci_read_config(dev, PCIR_LATTIMER, 1);
+
+ sc-suspended = 1;
+
+ splx(s);
+
+ return 0;
+ }
+
+ /*
+ * Device resume routine. Restore some PCI settings in case the BIOS
+ * doesn't, re-enable busmastering, and restart the interface if
+ * appropriate.
+ */
+ static int
+ fxp_resume(device_t dev)
+ {
+ struct fxp_softc *sc = device_get_softc(dev);
+ struct ifnet *ifp = sc-sc_if;
+ u_int16_t pci_command;
+ int i, s;
+
+ s = splimp();
+
+ /* better way to do this? */
+ for (i=0; i5; i++)
+ pci_write_config(dev, PCIR_MAPS + i*4, sc-saved_maps[i], 4);
+ pci_write_config(dev, PCIR_BIOS, sc-saved_biosaddr, 4);
+ pci_write_config(dev, PCIR_INTLINE, sc-saved_intline, 1);
+ pci_write_config(dev, PCIR_CACHELNSZ, sc-saved_cachelnsz, 1);
+ pci_write_config(dev, PCIR_LATTIMER, sc-saved_lattimer, 1);
+
+ /* reenable busmastering */
+ pci_command = pci_read_config(dev, PCIR_COMMAND, 2);
+ pci_command |= (PCIM_CMD_MEMEN|PCIM_CMD_BUSMASTEREN);
+ pci_write_config(dev, PCIR_COMMAND, pci_command, 2);
+
+ CSR_WRITE_4(sc, FXP_CSR_PORT, FXP_PORT_SELECTIVE_RESET);
+ DELAY(10);
+
+ /* reinitialize interface if necessary */
+ if (ifp-if_flags IFF_UP)
+ fxp_init(sc);
+
+ sc-suspended = 0;
+
+ splx(s);
+
+ return 0;
+ }
+
static device_method_t fxp_methods[] = {
/* Device interface */
DEVMETHOD(device_probe, fxp_probe),
DEVMETHOD(device_attach,fxp_attach),
DEVMETHOD(device_detach,fxp_detach),
DEVMETHOD(device_shutdown,
Re: fxp suspend/resume hangs
Jordan Hubbard wrote: in summary: PR kern/18756 contains a patch (against -stable, alas, This PR has been explicitly assigned to David Greenman and should be handled by him. As I pointed out in another message, nobody but he is likely to touch the fxp driver under any circumstances so it basically comes down to either him or nobody. So I suspect that either blackmail or bribery is now in order. :-) (Hey, it worked for me with Cameron and the SBLive driver!) -- Frank Mayhar [EMAIL PROTECTED] http://www.exit.com/ Exit Consulting http://store.exit.com/ To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
Re: fxp suspend/resume hangs
On Sun, Sep 17, 2000 at 05:31:45AM -0700, David Greenman wrote: in summary: PR kern/18756 contains a patch (against -stable, alas, sorry) which fixes kernel hangs in the fxp driver on some laptops after a resume from suspend. while quite a few people appear to be using this patch successfully, it hasn't been committed -- david greenman had an entirely reasonable objection to one aspect of the patch's behavior. unfortunately, my knowledge of the kernel isn't sufficient to adequately address david's concerns, and though i've mailed him to ask for guidance twice over the past 4 months, i haven't received a response. that's probably my fault, i probably should have been mailing -current to being with. I can only find the 5/22 email regarding this, so I seem to have missed your second message. With over a thousand emails a day coming into my inbox, this shouldn't be too surprising. My response to the 5/22 message was this: ... This could be a problem. If an interrupt occurs, it must be acknowledged otherwise you'll be stuck in an infinit loop - PCI interrupts are level sensitive and must be cleared in the ISR. ... In short, while it may fix a hang in your laptop case, it opens the driver up to a hang if an unexpected interrupt occurs while IFF_RUNNING is clear. I think this is dangerous enough that I don't think the code should not be compiled as part of the standard driver. One just cannot ignore level- sensitive PCI interrupts. While programming for cardbus under FreeBSD, I ran into similar issues that when cards were powere down or removed where they would go into an infinite loop reading status registers. What actually happens is the register returns 0x whenever it is read, and the resolution I used was to check whether it is equal to 0x and do appropiate measures when it is found to be true. It looks from reading the PR that this might be a similar issue here -- that the card is powered down during suspend and of wakeup the reads to FXP_CSR_SCB_STATACK and cbp-cb_status returns 0xff. I believe this issue can be resolved by checking whether what was read equals 0x and abort the loop. This should be fairly safe as interrups shouldn't happen during powerdown (and can't be ack'ed anyway)... -- (o_ 1-2-1-2-1-2-1-2-1-2-1-2-1-2-1-2-1-2-1-2-1-2-1-2-1-2-1-2-1-2 _o) \\\_\Jonathan Chen [EMAIL PROTECTED] /_/// ) No electrons were harmed during production of this message ( ~ To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
fxp suspend/resume hangs
appended below is an excerpt from a message sent to -stable earlier tonight, containing content of a type which kris kenneway correctly suggested would find a more suitable audience on -current. in summary: PR kern/18756 contains a patch (against -stable, alas, sorry) which fixes kernel hangs in the fxp driver on some laptops after a resume from suspend. while quite a few people appear to be using this patch successfully, it hasn't been committed -- david greenman had an entirely reasonable objection to one aspect of the patch's behavior. unfortunately, my knowledge of the kernel isn't sufficient to adequately address david's concerns, and though i've mailed him to ask for guidance twice over the past 4 months, i haven't received a response. that's probably my fault, i probably should have been mailing -current to being with. if anybody can offer any suggestions as to how to move forward with getting this patch to the point where it can be committed, i'd certainly appreciate it. alternately, any feedback on whether the patch is necessary and/or functional on your machine, laptop or no, would be interesting. - Forwarded message from mike ryan [EMAIL PROTECTED] - From: mike ryan [EMAIL PROTECTED] Subject: ds1 pcm and fxp suspend/resume bugs (was Re: I'll be rolling a 4.1.1 release on September 25th) To: [EMAIL PROTECTED] Date: Sat, 16 Sep 2000 22:53:53 -0400 [ background snipped: jkh announced 4.1.1, pir asked about some patches ] 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. - End forwarded message - To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
