Hello Pavel Machek:
With this patch, My machine has work very fine. Without it my machine will hangup/Oops in suspend/resume.
By the way, If i'm right , I can change other driver in kernel to this model.
--- linux-2.5.42/sound/pci/intel8x0.c Sat Oct 12 21:24:58 2002
+++ linux-2.5.42-suspend/sound/pci/intel8x0.c Sat Oct 12 21:21:12 2002
@@ -1891,6 +1891,8 @@
{
snd_card_t *card = chip->card;
+ if (chip->in_suspend)
+ return;
chip->in_suspend = 1;
snd_power_lock(card);
if (card->power_state == SNDRV_CTL_POWER_D3hot)
@@ -1909,7 +1911,10 @@
snd_card_t *card = chip->card;
int i;
+ if (!chip->in_suspend)
+ return;
snd_power_lock(card);
+ chip->in_suspend = 0;
if (card->power_state == SNDRV_CTL_POWER_D0)
goto __skip;
@@ -1919,7 +1924,6 @@
if (chip->ac97[i])
snd_ac97_resume(chip->ac97[i]);
- chip->in_suspend = 0;
snd_power_change_state(card, SNDRV_CTL_POWER_D0);
__skip:
snd_power_unlock(card);
--- linux-2.5.42/drivers/net/3c59x.c Sat Oct 12 21:25:00 2002
+++ linux-2.5.42-suspend/drivers/net/3c59x.c Sat Oct 12 21:20:48 2002
@@ -809,6 +809,9 @@
spinlock_t lock; /* Serialise access to device & its vortex_private */
spinlock_t mdio_lock; /* Serialise access to mdio hardware */
u32 power_state[16];
+#ifdef CONFIG_PM
+ int in_suspend;
+#endif
};
/* The action to take with a media selection timer tick.
@@ -893,6 +896,10 @@
struct net_device *dev = pci_get_drvdata(pdev);
if (dev && dev->priv) {
+ struct vortex_private *vp = dev->priv;
+ if (vp->in_suspend)
+ return 0;
+ vp->in_suspend = 1;
if (netif_running(dev)) {
netif_device_detach(dev);
vortex_down(dev);
@@ -906,6 +913,10 @@
struct net_device *dev = pci_get_drvdata(pdev);
if (dev && dev->priv) {
+ struct vortex_private *vp = dev->priv;
+ if (!vp->in_suspend)
+ return 0;
+ vp->in_suspend = 1;
if (netif_running(dev)) {
vortex_up(dev);
netif_device_attach(dev);
--
- Hu Gang
On Sun, 13 Oct 2002, Hu Gang wrote:
> --- linux-2.5.42/drivers/net/3c59x.c Sat Oct 12 21:25:00 2002
> +++ linux-2.5.42-suspend/drivers/net/3c59x.c Sat Oct 12 21:20:48 2002
> +#ifdef CONFIG_PM
> + int in_suspend;
> +#endif
This looks like a serious design mistake. Surely it would be
better to just have the network layer stop operations when the
system is going into suspend, instead of having to modify 100
individual network drivers ?
Rik
--
Bravely reimplemented by the knights who say "NIH".
http://www.surriel.com/ http://distro.conectiva.com/
Current spamtrap: <a href=mailto:"[email protected]">[email protected]</a>
On Sun, 13 Oct 2002 01:34:22 -0200 (BRST)
Rik van Riel <[email protected]> wrote:
|On Sun, 13 Oct 2002, Hu Gang wrote:
|
|> --- linux-2.5.42/drivers/net/3c59x.c Sat Oct 12 21:25:00 2002
|> +++ linux-2.5.42-suspend/drivers/net/3c59x.c Sat Oct 12 21:20:48 2002
|
|> +#ifdef CONFIG_PM
|> + int in_suspend;
|> +#endif
|
|This looks like a serious design mistake. Surely it would be
|better to just have the network layer stop operations when the
|system is going into suspend, instead of having to modify 100
|individual network drivers ?
Yes, The other drivers have this problem , such as sound.
I'm can not confirm that idea is the best way. But I can not found any other way can do it. If you have good idea, Tell me know.
thanks.
--
- Hu Gang
Hi!
> > --- linux-2.5.42/drivers/net/3c59x.c Sat Oct 12 21:25:00 2002
> > +++ linux-2.5.42-suspend/drivers/net/3c59x.c Sat Oct 12 21:20:48 2002
>
> > +#ifdef CONFIG_PM
> > + int in_suspend;
> > +#endif
>
> This looks like a serious design mistake. Surely it would be
> better to just have the network layer stop operations when the
> system is going into suspend, instead of having to modify 100
> individual network drivers ?
Whole userland is stopped at that point. That should mean that new
requests can not come.
OTOH packet from the network *can* come, and higher levels can not do
much with that. [They could ifconfig down the network interface... But
that can have sideefects we don't want to see...]
Pavel
--
When do you have heart between your knees?
On Mon, 14 Oct 2002, Pavel Machek wrote:
> > This looks like a serious design mistake. Surely it would be
> > better to just have the network layer stop operations when the
> > system is going into suspend, instead of having to modify 100
> > individual network drivers ?
>
> Whole userland is stopped at that point. That should mean that new
> requests can not come.
>
> OTOH packet from the network *can* come, and higher levels can not do
> much with that.
Higher layers can throw away the packet. This means you just
need to modify the higher layer at one or two places, instead
of needing to modify every single network driver out there.
I don't need to tell you which of these two options is gonna
be the easiest to maintain, do I ?
regards,
Rik
--
A: No.
Q: Should I include quotations after my reply?
http://www.surriel.com/ http://distro.conectiva.com/
Hi!
> > > better to just have the network layer stop operations when the
> > > system is going into suspend, instead of having to modify 100
> > > individual network drivers ?
> >
> > Whole userland is stopped at that point. That should mean that new
> > requests can not come.
> >
> > OTOH packet from the network *can* come, and higher levels can not do
> > much with that.
>
> Higher layers can throw away the packet. This means you just
> need to modify the higher layer at one or two places, instead
> of needing to modify every single network driver out there.
>
> I don't need to tell you which of these two options is gonna
> be the easiest to maintain, do I ?
No, that one is simple.
What is not so simple is seeing that throwing that packet away is not
enough. Receiving packet means DMA, and DMA is no-no during S4
resume. So simply throwing packet away is not enough.
Pavel
--
Casualities in World Trade Center: ~3k dead inside the building,
cryptography in U.S.A. and free speech in Czech Republic.