All the mail mirrored from lore.kernel.org
 help / color / mirror / Atom feed
From: Geert Uytterhoeven <Geert.Uytterhoeven@sonycom.com>
To: Lou Langholtz <ldl@chpc.utah.edu>
Cc: Takashi Oe <toe@unlserve.unl.edu>, linuxppc-dev@lists.linuxppc.org
Subject: Re: [Fwd: Bug: 2.2.12 still hangs PPC after some PPP activity]
Date: Thu, 30 Sep 1999 07:33:43 +0200 (MET DST)	[thread overview]
Message-ID: <Pine.GSO.4.10.9909300726510.8003-100000@begonia.sonytel.be> (raw)
In-Reply-To: <37F26FE5.98B8B00@chpc.utah.edu>


On Wed, 29 Sep 1999, Lou Langholtz wrote:
> Takashi Oe wrote:
> 
> > . . .I'm fairly certain it's a bug.  Good spotting.  The last restore_flags()
> > shouldn't be there.
> >
> > --- macserial.c.ORIG    Wed Sep 29 02:05:14 1999
> > +++ macserial.c Wed Sep 29 02:05:31 1999
> > @@ -1381,7 +1381,6 @@
> >         if (info->xmit_cnt && !tty->stopped && !info->tx_stopped
> >             && !info->tx_active)
> >                 transmit_chars(info);
> > -       restore_flags(flags);
> >         return ret;
> >  }
> >
> > Takashi Oe
> 
> Bummer...
> 
> I just locked up my system and had to reboot. The above change then doesn't seem
> to fix the system hangs. On the other hand I never did see the "FB. overflow"
> message at least.
> 
> I've been trying to search around HOWTOs and FAQs and mailing lists to get a
> better idea of wether nesting save_flags(flags); cli(); stuff...;
> save_flags(new_flags); cli(); restore_flags(new_flags); restore_flags(flags); is
> ever even ok. Haven't found anything conclusive yet though. Whatever the case, it
> doesn't seem like it'd be good practice anyhow. All the other serial support C
> files I've found so far seem to avoid this except for macserial.c.

Nesting `save_flags(); cli(); ... restore_flags();' is perfectly legal. That's
exactly the reason why `save_flags()' and `restore_flags()' were invented!

Normally, to disable interrupts to make sure a critical code section is not
interrupted, you do:

    cli();
    ...
    sti();

The problem with this construct is that the `sti()' will always re-enable the
interrupts, even when they were disabled when the `cli()' was called, like in

void func(void)
{
    ...
    cli();
    ...
    sti();
    ...		// interrupts accidentally re-enabled here!
}

    cli();
    ...
    func();
    ...
    sti();

So `save_flags()' saves the current interrupt mask, and `restore_flags()'
restores it. Problem solved by writing:

void func(void)
{
    ...
    save_flags(flags);
    cli();
    ...
    restore_flags(flags);
    ...		// interrupts accidentally re-enabled here!
}

For former AmigaOS programmers: it's a bit like the Disable()/Enable() Exec
functions, which allowed nestings:

    int interrupt_disable_cnt = 0;

    void Disable(void)
    {
	cli();
	interrupt_disable_cnt++;

    }

    void Enable(void)
    {
	if (--interrupt_disable_cnt == 0)
	    sti();
    }

Conclusion: use `cli()/sti()' when you're 100% sure interrupts were enabled
before the cli() was called, and `save_flags()/cli()/restore_flags()' when
interrupts may be disabled when entering your code.

Greetings,

						Geert

--
Geert Uytterhoeven ----------------- Sony Suprastructure Center Europe (SUPC-E)
Geert.Uytterhoeven@sonycom.com ------------------- Sint Stevens Woluwestraat 55
Phone +32-2-7248648 Fax +32-2-7262686 ---------------- B-1130 Brussels, Belgium


** Sent via the linuxppc-dev mail list. See http://lists.linuxppc.org/

  parent reply	other threads:[~1999-09-30  5:33 UTC|newest]

Thread overview: 31+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
     [not found] <37F1AD4B.585E99AB@chpc.utah.edu>
1999-09-29  7:11 ` [Fwd: Bug: 2.2.12 still hangs PPC after some PPP activity] Geert Uytterhoeven
1999-09-29  7:16 ` Takashi Oe
1999-09-29  7:40   ` Geert Uytterhoeven
1999-09-29  9:13   ` Benjamin Herrenschmidt
1999-09-30  0:46     ` Takashi Oe
1999-09-30  8:50       ` Benjamin Herrenschmidt
1999-09-30 16:21         ` Takashi Oe
1999-09-30 16:35           ` Benjamin Herrenschmidt
1999-10-06  5:33             ` update on macserial/DMA Takashi Oe
1999-10-06  8:35               ` Benjamin Herrenschmidt
1999-10-06 13:47                 ` Takashi Oe
1999-10-06 16:25                   ` Benjamin Herrenschmidt
1999-10-06 16:50                     ` Benjamin Herrenschmidt
1999-10-08  7:13               ` Lou Langholtz
1999-10-09 17:57                 ` Lou Langholtz
     [not found]             ` <Pine.LNX.3.96LJ1.1b7.991005234830.1210A-100000@ofey.inetne br.com>
1999-10-07  9:48               ` Franz Sirl
1999-10-07 15:37                 ` phandel
1999-10-12  7:20       ` [Fwd: Bug: 2.2.12 still hangs PPC after some PPP activity] Lou Langholtz
1999-09-29 16:44   ` Lou Langholtz
1999-09-29 17:02     ` Benjamin Herrenschmidt
1999-09-29 18:08       ` Lou Langholtz
1999-09-29 18:46   ` Lou Langholtz
1999-09-29 20:00   ` Lou Langholtz
1999-09-30  1:14     ` Takashi Oe
1999-09-30  5:33     ` Geert Uytterhoeven [this message]
1999-10-01 13:26     ` Franz Sirl
1999-10-01 13:46       ` Alvin Brattli
     [not found]       ` <Pine.OSF.3.96.991001153658.16772E-100000@mitra.phys.uit.no >
1999-10-01 14:08         ` Franz Sirl
1999-10-01 16:14       ` Lou Langholtz
     [not found] <37F1C0A3.B9F25580@chpc.utah.edu>
1999-09-29  7:39 ` Geert Uytterhoeven
1999-09-10 16:51 Lou Langholtz

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=Pine.GSO.4.10.9909300726510.8003-100000@begonia.sonytel.be \
    --to=geert.uytterhoeven@sonycom.com \
    --cc=ldl@chpc.utah.edu \
    --cc=linuxppc-dev@lists.linuxppc.org \
    --cc=toe@unlserve.unl.edu \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.