Re: [Fwd: Bug: 2.2.12 still hangs PPC after some PPP activity]

Re: [Fwd: Bug: 2.2.12 still hangs PPC after some PPP activity]

[Geert Uytterhoeven]

On Wed, 29 Sep 1999, Lou Langholtz wrote:
> What might happen if a driver does:

point A

> save_flags(old_flags);
> cli();
> restore_flags(old_flags);
> save_flags(new_flags);
> cli();
> restore_flags(new_flags);

point B

> /* can't we be interupted here? Assume yes, if so */
> restore_flags(old_flags);

point C

> seems like this might introduce a bug if we could get interrupted after the
> restore of the new_flags but before the second restore of old flags in such a
> way such that the proper state of old_flags could change. I'm not comfortable
> enough though with my understanding of interrupts and driver routines to be
> certain one way or another. To be more specific, consider the case on just a
> single processor system. If this strikes anyone else as a possible race
> condition that could introduce a bug, then this is what we need to fix in
> macserial.c's rs_write routine since this code can potentially happen.
> 
> Opinions??? Please clue me in anyway... this stuff's a kick! :-)

The interrupt mask register has the same contents at points A, B and C. Hence,
if we could be interrupt a point A, we can be interrupt at points B and C.

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/

Re: [Fwd: Bug: 2.2.12 still hangs PPC after some PPP activity]

[Takashi Oe]

On Wed, 29 Sep 1999, Lou Langholtz wrote:

> What might happen if a driver does:
> 
> save_flags(old_flags);
> cli();
> restore_flags(old_flags);
> save_flags(new_flags);
> cli();
> restore_flags(new_flags);
> /* can't we be interupted here? Assume yes, if so */
> restore_flags(old_flags);
> 
> seems like this might introduce a bug if we could get interrupted after the
> restore of the new_flags but before the second restore of old flags in such a
> way such that the proper state of old_flags could change. I'm not comfortable
> enough though with my understanding of interrupts and driver routines to be
> certain one way or another. To be more specific, consider the case on just a
> single processor system. If this strikes anyone else as a possible race
> condition that could introduce a bug, then this is what we need to fix in
> macserial.c's rs_write routine since this code can potentially happen.

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


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

Re: [Fwd: Bug: 2.2.12 still hangs PPC after some PPP activity]

[Geert Uytterhoeven]

On Wed, 29 Sep 1999, Takashi Oe wrote:
> On Wed, 29 Sep 1999, Lou Langholtz wrote:
> > What might happen if a driver does:
> > 
> > save_flags(old_flags);
> > cli();
> > restore_flags(old_flags);
> > save_flags(new_flags);
> > cli();
> > restore_flags(new_flags);
> > /* can't we be interupted here? Assume yes, if so */
> > restore_flags(old_flags);
> > 
> > seems like this might introduce a bug if we could get interrupted after the
> > restore of the new_flags but before the second restore of old flags in such a
> > way such that the proper state of old_flags could change. I'm not comfortable
> > enough though with my understanding of interrupts and driver routines to be
> > certain one way or another. To be more specific, consider the case on just a
> > single processor system. If this strikes anyone else as a possible race
> > condition that could introduce a bug, then this is what we need to fix in
> > macserial.c's rs_write routine since this code can potentially happen.
> 
> I'm fairly certain it's a bug.  Good spotting.  The last restore_flags()
> shouldn't be there.

Or one of the others. The last restore_flags() may make me think there's
something wrong, but it cannot cause harm. If there's a real bug, it should be
related to the other flag manipulation calls.

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/

Re: [Fwd: Bug: 2.2.12 still hangs PPC after some PPP activity]

[Benjamin Herrenschmidt]

On Wed, Sep 29, 1999, Takashi Oe <toe@unlserve.unl.edu> 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;
> }

This doesn't look like the only problem. For example, in rs_close, we
call tty_wait_until_sent with interrupt disabled. Can't this cause a
deadlock ? There may be other cases like this.

I'll look into adding some fixes and include them in the next kernel I
post on my page (along with a few other stuffs I'd want to get tested,
including your page_alloc() fix which _apparently_ increased the overall
perfs on my machine but I didn't do real benchmarks). But I'm wondering
if we shouldn't include your DMA driver right now and make sure it works
fine instead of doing yet another bunch of patches to the current
macserial. I didn't try the DMA driver yet, are there known problems with it ?

I'll try to make 2.3.x versions of my various patches if I find some time
this week (may have to wait next week end).

On another issue: Is there someone with a 3400 and this famous
interrupt-less ethernet combo out there who knows how to hack into
pmac_pic.c ? I have managed to get the interrupt working with an horrible
hack in de4x5.c, and I'm trying to implement a clean version with a
cascaded controller the way I did if for gatwick on the wallstreet.
Unfortuntately, the clean version doesn't work yet, I don't have one of
those machine to test, and my remote-tester was not able (or didn't have
time) to find out what's going on with the clean version. Any volunteer ?



-- 
           Perso. e-mail: <mailto:bh40@calva.net>
           Work   e-mail: <mailto:benh@mipsys.com>
BenH.      Web   : <http://calvaweb.calvacom.fr/bh40/>


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

Re: [Fwd: Bug: 2.2.12 still hangs PPC after some PPP activity]

[Lou Langholtz]

Takashi Oe wrote:

> > . . . .seems like this might introduce a bug if we could get interrupted after
> the
> > restore of the new_flags but before the second restore of old flags in such a
> > way such that the proper state of old_flags could change. I'm not comfortable
> > enough though with my understanding of interrupts and driver routines to be
> > certain one way or another. To be more specific, consider the case on just a
> > single processor system. If this strikes anyone else as a possible race
> > condition that could introduce a bug, then this is what we need to fix in
> > macserial.c's rs_write routine since this code can potentially happen.
>
> 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

This is pretty much the kernel I'm running now. I haven't had the "FB. overflow"
message yet nor system-freeze but I've experienced the TCP slowdown already.
Evidence that we've got other problems as well (IMO). It's only been 20 hours or
so with new kernel so not enough time for me to feel confident though about these
results.


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

Re: [Fwd: Bug: 2.2.12 still hangs PPC after some PPP activity]

[Benjamin Herrenschmidt]

On Wed, Sep 29, 1999, Lou Langholtz <ldl@chpc.utah.edu> wrote:

>This is pretty much the kernel I'm running now. I haven't had the "FB.
>overflow"
>message yet nor system-freeze but I've experienced the TCP slowdown already.
>Evidence that we've got other problems as well (IMO). It's only been 20 hours
>or
>so with new kernel so not enough time for me to feel confident though about
>these
>results.

I've added another fix to the kernel on my test page
(http://calvaweb.calvacom.fr/bh40/test.html). It may fix the hang on
close. I don't think it will fix anything related to a slowdown however.

-- 
           Perso. e-mail: <mailto:bh40@calva.net>
           Work   e-mail: <mailto:benh@mipsys.com>
BenH.      Web   : <http://calvaweb.calvacom.fr/bh40/>


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

Re: [Fwd: Bug: 2.2.12 still hangs PPC after some PPP activity]

[Lou Langholtz]

Benjamin Herrenschmidt wrote:

> On Wed, Sep 29, 1999, Lou Langholtz <ldl@chpc.utah.edu> wrote:
>
> >This is pretty much the kernel I'm running now. I haven't had the "FB.
> >overflow" message yet nor system-freeze but I've experienced the TCP slowdown
> already.
> >Evidence that we've got other problems as well (IMO). It's only been 20 hours
> >or so with new kernel so not enough time for me to feel confident though about
>
> >these results.
>
> I've added another fix to the kernel on my test page
> (http://calvaweb.calvacom.fr/bh40/test.html). It may fix the hang on
> close. I don't think it will fix anything related to a slowdown however.

It's interesting to note that you chose to move save_flags(flags) in
rs_write() to just before the cli()'s. What was your reasoning? I'm asking so
I can get a better understanding of all the implications of this. Most code that
I've perused so far now does what you've basically done --- keeps the
save_flags() right before the cli()'s. When I chose to just to remove that last
restore_flags() I was basing my descision not to move the originall
save_flags() on the rs_write() code in drivers/char/serial.c. In the serial.c
file they call save_flags() outside of the while loop like the original
rs_write() in macserial.c. This would save time by not being constantly
re-invoked within the loop of course but then this only works if the flags saved
stay valid. That's the part I'm having the most trouble with --- what kind of
calls could invalidate the flags that have been saved.

As to the hang-on-close problem, I've never experienced that before nor heard of
it. Is it something that you've seen or heard of? Your change makes sense anyway.
I'm just being curious in case this might be effecting me in ways I didn't even
realize.

Cheers! :-)

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

Re: [Fwd: Bug: 2.2.12 still hangs PPC after some PPP activity]

[Lou Langholtz]

Takashi Oe wrote:

> On Wed, 29 Sep 1999, Lou Langholtz wrote:
>
> > What might happen if a driver does:
> >
> > save_flags(old_flags);
> > cli();
> > restore_flags(old_flags);
> > save_flags(new_flags);
> > cli();
> > restore_flags(new_flags);
> > /* can't we be interupted here? Assume yes, if so */
> > restore_flags(old_flags);
> >. . .

> 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

If this is true, then what about wherever else transmit_chars() is called. There's
numerous instances where because transmit_chars() itself goes into a save_flags();
cli(); ...; restore_flags() where we have these nested cli()... restore_flags().
For instance in rs_throttle() transmit_chars() is called while cli()'s already in
effect. If the real problem is the nesting of the locks introduced by
transmit_chars() then this would also seem to explain the TCP die-off phenomena.
Opinions?


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

Re: [Fwd: Bug: 2.2.12 still hangs PPC after some PPP activity]

[Lou Langholtz]

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.


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

Re: [Fwd: Bug: 2.2.12 still hangs PPC after some PPP activity]

[Takashi Oe]

On Wed, 29 Sep 1999, Benjamin Herrenschmidt wrote:

> This doesn't look like the only problem. For example, in rs_close, we
> call tty_wait_until_sent with interrupt disabled. Can't this cause a
> deadlock ? There may be other cases like this.
> 
> I'll look into adding some fixes and include them in the next kernel I
> post on my page (along with a few other stuffs I'd want to get tested,
> including your page_alloc() fix which _apparently_ increased the overall
> perfs on my machine but I didn't do real benchmarks). But I'm wondering

The __get_free_pages() fix is probably not needed for 2.2.13pre, although
something similar might save a few hundred cycles.  Anyway, much to my
amazement, there is significant differences in a number of errors ppp link
report between the kernels with and without the __get_free_pages() patch.
With a stock 2.2.12 kernel, ppp link used to report 1 to 10% frame errors.
But, now, it hardly ever reports any error.  Besides, my machine hasn't
crashed for two days.  I can't remember the last time that my machine
stayed up so long.

> if we shouldn't include your DMA driver right now and make sure it works
> fine instead of doing yet another bunch of patches to the current
> macserial. I didn't try the DMA driver yet, are there known problems with it ?

I don't know of any major flaw, but the DMA code can use some testings.
I've only tested it on Power Mac 7600 with baud rate of upto 115200 bps.


Takashi Oe


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

Re: [Fwd: Bug: 2.2.12 still hangs PPC after some PPP activity]

[Takashi Oe]

On Wed, 29 Sep 1999, Lou Langholtz wrote:

> 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

Basically, cli() disables interrupts.  If the interrupts are disabled to
begin with, it amounts to nothing.  So, I think the nesting should cause
no harm.

> 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.
> 


Takashi Oe


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

Re: [Fwd: Bug: 2.2.12 still hangs PPC after some PPP activity]

[Geert Uytterhoeven]

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/

Re: [Fwd: Bug: 2.2.12 still hangs PPC after some PPP activity]

[Benjamin Herrenschmidt]

On Wed, Sep 29, 1999, Takashi Oe <toe@unlserve.unl.edu> wrote:

>I don't know of any major flaw, but the DMA code can use some testings.
>I've only tested it on Power Mac 7600 with baud rate of upto 115200 bps.

I've heard of various possible issues with DMA hardware on the serial
ports and G3 macs. There seem to be a problem with the Heathrow
generation of Apple ASICs. (This was reported to me by people who made a
special device that was plugged into those ports, with a custom driver
under MacOS). They told me some characters end up beeing garbled when
reaching the SCC. I'll do some testings with your driver and my
powerbook's internal modem this week end to see if this problem actually
occurs or not.


-- 
           Perso. e-mail: <mailto:bh40@calva.net>
           Work   e-mail: <mailto:benh@mipsys.com>
BenH.      Web   : <http://calvaweb.calvacom.fr/bh40/>


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

Re: [Fwd: Bug: 2.2.12 still hangs PPC after some PPP activity]

[Takashi Oe]

On Thu, 30 Sep 1999, Benjamin Herrenschmidt wrote:

> I've heard of various possible issues with DMA hardware on the serial
> ports and G3 macs. There seem to be a problem with the Heathrow
> generation of Apple ASICs. (This was reported to me by people who made a
> special device that was plugged into those ports, with a custom driver
> under MacOS). They told me some characters end up beeing garbled when
> reaching the SCC. I'll do some testings with your driver and my
> powerbook's internal modem this week end to see if this problem actually
> occurs or not.

I suppose that can happen if DBDMA's FIFO wasn't flushed properly for
some reason.  Do you know if the problem occurs on receiving side (from
SCC to DMA) or transmitting side (from DMA to SCC)?  How many chars were
garbled?  If the FIFO were the cause of the problem, the number should be
between 1 and 7.


Takashi Oe


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

Re: [Fwd: Bug: 2.2.12 still hangs PPC after some PPP activity]

[Benjamin Herrenschmidt]

On Thu, Sep 30, 1999, Takashi Oe <toe@unlserve.unl.edu> wrote:

>I suppose that can happen if DBDMA's FIFO wasn't flushed properly for
>some reason.  Do you know if the problem occurs on receiving side (from
>SCC to DMA) or transmitting side (from DMA to SCC)?  How many chars were
>garbled?  If the FIFO were the cause of the problem, the number should be
>between 1 and 7.

I don't know the details, it was quite a long time ago... I'll ask him again.

-- 
           Perso. e-mail: <mailto:bh40@calva.net>
           Work   e-mail: <mailto:benh@mipsys.com>
BenH.      Web   : <http://calvaweb.calvacom.fr/bh40/>


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

Re: [Fwd: Bug: 2.2.12 still hangs PPC after some PPP activity]

[Franz Sirl]

At 22:00 29.09.99 , Lou Langholtz wrote:
>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.

Hmm, in the recent kernels Paul changed the code to only print the FB 
message once! For me these lockups (I'm using vger nearly unmodified) are 
gone since quite a while, but I don't really know a reason why. The major 
specialties on my 7200/75 are:

- disabled syslog's fsync'ing of /var/log/messages (this prevents the 
amplifying effect of the FB messages)
- all major stuff is compiled with gcc-2.95.2pre

Franz.


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

Re: [Fwd: Bug: 2.2.12 still hangs PPC after some PPP activity]

[Alvin Brattli]

On Fri, 1 Oct 1999, Franz Sirl wrote:

>(I'm using vger nearly unmodified)

This is one thing that has been escaping me for quite a while:  how do I
get a specific version of the vger kernel, and how do I get a list of
the versions I can checkout?  Following the instructions given on
<http://cvs.on.openprojects.net/> only gives me the current vger
development kernel (2.3.X), and not for example the latest 2.2.X kernel
(actually, the "kernel" module does seem to exist on cvs.on.openprojects.net;
after trying different things, "linux" worked, and gave me a 2.3.X kernel).
Reading the CVS man files haven't helped me much either.
Can some kind soul enlighten me on this?


aLViN
-- 
:r .signature


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

Re: [Fwd: Bug: 2.2.12 still hangs PPC after some PPP activity]

[Franz Sirl]

At 15:46 01.10.99 , Alvin Brattli wrote:

>On Fri, 1 Oct 1999, Franz Sirl wrote:
>
> >(I'm using vger nearly unmodified)
>
>This is one thing that has been escaping me for quite a while:  how do I
>get a specific version of the vger kernel, and how do I get a list of
>the versions I can checkout?  Following the instructions given on
><http://cvs.on.openprojects.net/> only gives me the current vger
>development kernel (2.3.X), and not for example the latest 2.2.X kernel
>(actually, the "kernel" module does seem to exist on cvs.on.openprojects.net;
>after trying different things, "linux" worked, and gave me a 2.3.X kernel).
>Reading the CVS man files haven't helped me much either.
>Can some kind soul enlighten me on this?

cvs update -dP -rlinux_2_2

Franz.


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

Re: [Fwd: Bug: 2.2.12 still hangs PPC after some PPP activity]

[Lou Langholtz]

Franz Sirl wrote:

> At 22:00 29.09.99 , Lou Langholtz wrote:
> >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.
>
> Hmm, in the recent kernels Paul changed the code to only print the FB
> message once! For me these lockups (I'm using vger nearly unmodified) are
> gone since quite a while, but I don't really know a reason why. The major
> specialties on my 7200/75 are:
>
> - disabled syslog's fsync'ing of /var/log/messages (this prevents the
> amplifying effect of the FB messages)
> - all major stuff is compiled with gcc-2.95.2pre
>
> Franz.

thats good to hear. you're using a kernel newer than 2.2.12 which has the fixes
i've been experimenting with plus others. like only printing the fb overflow
message the first time it occurs in the sequence rather than all the time. the
overflow may still be occuring but the message wont keep getting printed. this no
doubt makes a few things more usable but by itself shouldn't prevent the tcp slow
down to nothing over ppp nor the complete lock up. there's also a kernel memory
routine that has some ppc specific fixes to it which seems to greatly imprive ppp
performance. 2.2.12 still has some sti() calls in macserial.c which look
suspicious. the newer code has gotten rid of at least some of those and i'm now
running a kernel that has none of those in macserial.c. this seems to be running
much better but i haven't run long enough to have a high confidence that that was
particularly problematic.


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

update on macserial/DMA

[Takashi Oe]

Hi,

I re-wrote the serial DMA support code today and put the patch against
samba/vger linux-2.2.12 source trees (as of tonight) at
ftp://ppc.linux.or.jp/pub/users/toe/serial/.
I think the patch includes most of macserial patches (Ben's and Lou's
are in there, for sure) that I know of.

This code is much better than the previous one in which it was fairly easy
to cause frame/overrun errors, although it was far better than the vanila
macserial (w/o DMA support).  To get a feeling of the driver's
performance, I tried the following operations while downloading 10 MB+
files at 49 kbps receiving/33.6 kbps transmitting modem<->ISP and 115 kbps
PMac<->modem (ftp on ppp link):

A: "dd if=/dev/zero of=400MB count=409600 bs=1024; cp 400MB /tmp; rm
400MB"
B: planb+xawtv in grabdisplay mode (~10 fps, 640x480x4 bytes/frame)

With vanila macserial:
"A": ~200 overrun errors; ftp transfers were all aborted.

With previous DMA code:
"A": ~20 frame errors per ~600 packets
"B": a few frame errors per ~50 packets
"A+B": ~30 frame errors and a few overrun errors per ~600 packets

With this new DMA code:
"A" or "B" or "A+B": no error has been observed after about an hour of
trials (I did see a few frame errors when pppd started up once.)

These trials are pretty subjective, but I'm at least glad that it passed
all the tests I tried.


Takashi Oe


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

Re: update on macserial/DMA

[Benjamin Herrenschmidt]

On Wed, Oct 6, 1999, Takashi Oe <toe@unlserve.unl.edu> wrote:

>Hi,
>
>I re-wrote the serial DMA support code today and put the patch against
>samba/vger linux-2.2.12 source trees (as of tonight) at
>ftp://ppc.linux.or.jp/pub/users/toe/serial/.
>I think the patch includes most of macserial patches (Ben's and Lou's
>are in there, for sure) that I know of.

It breaks (crash) on the wallstreet's internal modem. The reason is that
this machines has two SCCs (4 channels) but the device tree only declares
channel A on the second SCC (so we have only 3 channels visible). This
breaks the channel cross-references you use to access channel B's
registers. I'll try to make a simple fix if I find some time today and I
think I'll just rewrite the probe code by the end of the week or next
week end since it's too much dependent on the device tree layout.

BTW. Paul: The patches on my test page (url below + .../test.html)
include among other things support for the PowerBooks 3400/3500
ethernet/modem combo interrupt. It looks like there is a second ohare
chip with cascaded interrupt controller either in the combo itself or on
the motherboard (or a chip that mimmics the ohare chip). It's not
referenced by name in the device tree but by vendorid/deviceid. I'm
wondering if it might contains also an SCC cell for the modem but I can't
test, I don't have access to one of those machines. I think you have a
3400, don't you ? I'll make sure my new probe code can easily be used to
declare SCC cells for this kind of cases (but just passing the addresses
in) just in case...

-- 
           Perso. e-mail: <mailto:bh40@calva.net>
           Work   e-mail: <mailto:benh@mipsys.com>
BenH.      Web   : <http://calvaweb.calvacom.fr/bh40/>


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

Re: update on macserial/DMA

[Takashi Oe]

On Wed, 6 Oct 1999, Benjamin Herrenschmidt wrote:

> It breaks (crash) on the wallstreet's internal modem. The reason is that
> this machines has two SCCs (4 channels) but the device tree only declares
> channel A on the second SCC (so we have only 3 channels visible). This

I see.  That would be a problem.

> breaks the channel cross-references you use to access channel B's
> registers. I'll try to make a simple fix if I find some time today and I
> think I'll just rewrite the probe code by the end of the week or next
> week end since it's too much dependent on the device tree layout.

I've just tried your fix, and, as expected, it causes no harm for PMac
7600.  Thanks.  It's not a big problem, but I think we don't want the
"fake" channel to take up "/dev/ttyS3" or such in case another serial
driver is to be used concurrently.

> 
> BTW. Paul: The patches on my test page (url below + .../test.html)
> include among other things support for the PowerBooks 3400/3500
> ethernet/modem combo interrupt. It looks like there is a second ohare
> chip with cascaded interrupt controller either in the combo itself or on
> the motherboard (or a chip that mimmics the ohare chip). It's not
> referenced by name in the device tree but by vendorid/deviceid. I'm
> wondering if it might contains also an SCC cell for the modem but I can't
> test, I don't have access to one of those machines. I think you have a
> 3400, don't you ? I'll make sure my new probe code can easily be used to

I think ehternet/modem combo is only for the US model of PowerBook
3400/3500.  If Paul had it, the combo should be working a long ago. :)

> declare SCC cells for this kind of cases (but just passing the addresses
> in) just in case...
> 


Takashi Oe


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

Re: update on macserial/DMA

[Benjamin Herrenschmidt]

On Wed, Oct 6, 1999, Takashi Oe <toe@unlserve.unl.edu> wrote:

>I've just tried your fix, and, as expected, it causes no harm for PMac
>7600.  Thanks.  It's not a big problem, but I think we don't want the
>"fake" channel to take up "/dev/ttyS3" or such in case another serial
>driver is to be used concurrently.

I beleive this could be acheived by changing line 2404 to pass
zs_channels_found-1. Not pretty but not less than my fix anyway... The
fake zs_soft exist only because of the assumption zs_channel[i] matches
zs_soft[i], I didn't take time to check if this assumption exist only in
the probe code or not. I'll try to do something better next week-end if I
find some spare time.

>I think ehternet/modem combo is only for the US model of PowerBook
>3400/3500.  If Paul had it, the combo should be working a long ago. :)

Yes, you are certainly right ;)

-- 
           Perso. e-mail: <mailto:bh40@calva.net>
           Work   e-mail: <mailto:benh@mipsys.com>
BenH.      Web   : <http://calvaweb.calvacom.fr/bh40/>


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

Re: update on macserial/DMA

[Benjamin Herrenschmidt]

On Wed, Oct 6, 1999, Benjamin Herrenschmidt <bh40@calva.net> wrote:

>I beleive this could be acheived by changing line 2404 to pass
>zs_channels_found-1. Not pretty but not less than my fix anyway... The
>fake zs_soft exist only because of the assumption zs_channel[i] matches
>zs_soft[i], I didn't take time to check if this assumption exist only in
>the probe code or not. I'll try to do something better next week-end if I
>find some spare time.

Of course we must do this only when there's fake channel...

-- 
           Perso. e-mail: <mailto:bh40@calva.net>
           Work   e-mail: <mailto:benh@mipsys.com>
BenH.      Web   : <http://calvaweb.calvacom.fr/bh40/>


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

Re: update on macserial/DMA

[Franz Sirl]

At 07:33 06.10.99 , Takashi Oe wrote:

>Hi,
>
>I re-wrote the serial DMA support code today and put the patch against
>samba/vger linux-2.2.12 source trees (as of tonight) at
>ftp://ppc.linux.or.jp/pub/users/toe/serial/.
>I think the patch includes most of macserial patches (Ben's and Lou's
>are in there, for sure) that I know of.

Wow, this (well, with slight mods for 2.3.18vger) works like a charm for me 
on my slooow 7200/75. Now heavy disk usage doesn't influence the transfer 
performance anymore and the error rate is extremely low. This patch should 
be added to the kernel sources ASAP IMHO.

Many thanks,
Franz.


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

Re: update on macserial/DMA

[phandel]

On Thu, 7 Oct 1999, Franz Sirl wrote:

> Wow, this (well, with slight mods for 2.3.18vger) works like a charm for me 
> on my slooow 7200/75. Now heavy disk usage doesn't influence the transfer 
> performance anymore and the error rate is extremely low. This patch should 
> be added to the kernel sources ASAP IMHO.

Same here - I used to have to run at a port rate of 56k; now I have either
0 or 1 errors/overruns after hours of surfing/downloading at a port rate
of 230.4k! (Using Paul's rsync 2.2.12)  Thanks a bunch, Takashi!


Thanks,
Peter

-- 
Peter F. Handel          "[The anti-Christ] also forced everyone, small and
phandel@cise.ufl.edu      great ... to receive a mark [smart card?] on his
www.cise.ufl.edu/~phandel right hand or on his forehead, so that no one could
FAX: (561) 619-8051       buy or sell unless he had the mark"-Revelation13:16


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

Re: update on macserial/DMA

[Lou Langholtz]

Takashi Oe wrote:

> Hi,
>
> I re-wrote the serial DMA support code today and put the patch against
> samba/vger linux-2.2.12 source trees (as of tonight) at
> ftp://ppc.linux.or.jp/pub/users/toe/serial/.
> I think the patch includes most of macserial patches (Ben's and Lou's
> are in there, for sure) that I know of. . .

We should probably also clean up the two unneeded buf[64] allocations. These
would be at lines 1535 and 1572 in Takashi Oe's macserial.c file. They've
been left over for a few rounds now and I don't see how they're needed for
anything.


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

Re: update on macserial/DMA

[Lou Langholtz]

Lou Langholtz wrote:

> Takashi Oe wrote:
>
> > Hi,
> >
> > I re-wrote the serial DMA support code today and put the patch against
> > samba/vger linux-2.2.12 source trees (as of tonight) at
> > ftp://ppc.linux.or.jp/pub/users/toe/serial/.
> > I think the patch includes most of macserial patches (Ben's and Lou's
> > are in there, for sure) that I know of. . .
>
> We should probably also clean up the two unneeded buf[64] allocations. These
> would be at lines 1535 and 1572 in Takashi Oe's macserial.c file. They've
> been left over for a few rounds now and I don't see how they're needed for
> anything.

Also, I noticed that while others reported the DMA addition resulted in far
better TCP/IP over PPP performace, I found no such improvement. The difference
seems to be that I've been using the 2.2.12 distribution kernel rather than a
vger kernel and I'll guess that it's the memory management change that accounts
for this. Anyway, I'm going to see if the imporvement will happen now with AC's
2.2.13pre15 kernel with the assumption that the effective memory management
difference is in that. I'm very eager to see the improvements that others have
noted! :-)


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

Re: [Fwd: Bug: 2.2.12 still hangs PPC after some PPP activity]

[Lou Langholtz]

Takashi Oe wrote:

> On Wed, 29 Sep 1999, Benjamin Herrenschmidt wrote:
>
> > . . .
> > I'll look into adding some fixes and include them in the next kernel I
> > post on my page (along with a few other stuffs I'd want to get tested,
> > including your page_alloc() fix which _apparently_ increased the overall
> > perfs on my machine but I didn't do real benchmarks). But I'm wondering
>
> The __get_free_pages() fix is probably not needed for 2.2.13pre, although
> something similar might save a few hundred cycles.  Anyway, much to my
> amazement, there is significant differences in a number of errors ppp link
> report between the kernels with and without the __get_free_pages() patch.
> With a stock 2.2.12 kernel, ppp link used to report 1 to 10% frame errors.
> But, now, it hardly ever reports any error.  Besides, my machine hasn't
> crashed for two days.  I can't remember the last time that my machine
> stayed up so long. . .

I'm running AC's 2.2.13pre15 now and still seeing high error rates (17 out of 472
recieved packets). So if it even might just save a few extra cycles it still seems
worthwhile to add this __get_free_pages() fix, especially if it might have the
chance of getting rid of the high error rates again. I'll try it myself but I
suspect you could get it done much faster if this was enough inclination for you
;-)

Also, any idea why this wouldn't be true on for transmit errors? At least on my
machine, ifconfig ppp0 always reports zero errors and zero overruns on TX packets.
This seems like a good clue I'll have to dig more into :-)


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