Re: Communicator Crashes X II

Re: Communicator Crashes X II

[Kevin Puetz]

A serial port buffer issue is behind the 'FB. overflow ####' crash, also 
often exposed during VT changes while PPP is running.

This could be related. Or it might not. I really don't know the subsystem
well enough to say.
>From: Ira K Weiny <iweiny@falcon.csc.calpoly.edu>
>To: lambert@jeol.com, linuxppc-user@lists.linuxppc.org,
linuxppc-dev@lists.linuxppc.org
>Subject: Re: Communicator Crashes X II
>Date: Mon, Aug 30, 1999, 12:07 AM

> Well I may have some more news about this problem...
>
> Fisrt I just locked up using lynx!!!  Box rebooted after? 1min?  Again proves
> this is not Netscape, nor a font issue etc.

Yikes! When lynx locks up the whole box, that would rule out an X-related
instability... Were you in an xterm or straight console? Was X running on
another VT?

> I had 2 hard crashes one right after the other.  The first after having set up
> my printer on my other serial port.  One thing I did during this was to unplug
> my Pilot cradle and plug in my Printer.  The two crashes occured shortly after
> that.  Could this be a problem with the serial code/our hardware.  (PS I know
> that you are not supposed to hot swap the serial ports.  I just have gotten
> into bad habbits over the years. ;-)

I thought serial ports were supposed to be safe :-)
Only buses (like ADB/parallel) were supposed to be problematic.

> I don't know about others but my 8500 has been moved from dorm room to home
> and around more times that I can think.  I have plug/unpluged the serial port
> more time that I can think.  A couple of us have said they use Cable modems
> and I am going to DSL as soon as Pac Bell can get out here to hook me up.
> This tends to rule out the networking code...

Except that at least one person with a crashing COmmunicator does not use
PPP.

> So what about the serial ports.  I am thinking the problem may lie there.
> Does anyone else have thoughts/info which might support this theory.
>
> Thanks
> Ira Weiny


[[ This message was sent via the linuxppc-dev mailing list.  Replies are ]]
[[ not  forced  back  to the list, so be sure to Cc linuxppc-dev if your ]]
[[ reply is of general interest. Please check http://lists.linuxppc.org/ ]]
[[ and http://www.linuxppc.org/ for useful information before posting.   ]]

Re: Communicator Crashes X II

[Takashi Oe]

On Mon, 30 Aug 1999, Kevin Puetz wrote:

> A serial port buffer issue is behind the 'FB. overflow ####' crash, also 
> often exposed during VT changes while PPP is running.

I think this crash will occur less often, once serial DMA support is
present.  I've just started writing the necessary DMA code, and I hope to
get something working within a few weeks for the receiving side.

> This could be related. Or it might not. I really don't know the subsystem
> well enough to say.

I don't really know either, but kernel may be spending too much time in
the interrupt handling section of the serial driver.


Takashi Oe


[[ This message was sent via the linuxppc-dev mailing list.  Replies are ]]
[[ not  forced  back  to the list, so be sure to Cc linuxppc-dev if your ]]
[[ reply is of general interest. Please check http://lists.linuxppc.org/ ]]
[[ and http://www.linuxppc.org/ for useful information before posting.   ]]

Re: Communicator Crashes X II

[Geert Uytterhoeven]

On Mon, 30 Aug 1999, Takashi Oe wrote:
> On Mon, 30 Aug 1999, Kevin Puetz wrote:
> > A serial port buffer issue is behind the 'FB. overflow ####' crash, also 
> > often exposed during VT changes while PPP is running.
> 
> I think this crash will occur less often, once serial DMA support is
> present.  I've just started writing the necessary DMA code, and I hope to
> get something working within a few weeks for the receiving side.
> 
> > This could be related. Or it might not. I really don't know the subsystem
> > well enough to say.
> 
> I don't really know either, but kernel may be spending too much time in
> the interrupt handling section of the serial driver.

Perhaps the kernel spends too much time in the interrupt handling section of
the IDE driver? We saw similar things on m68k.

Greetings,

						Geert

--
Geert Uytterhoeven                     Geert.Uytterhoeven@cs.kuleuven.ac.be
Wavelets, Linux/{m68k~Amiga,PPC~CHRP}  http://www.cs.kuleuven.ac.be/~geert/
Department of Computer Science -- Katholieke Universiteit Leuven -- Belgium


[[ This message was sent via the linuxppc-dev mailing list.  Replies are ]]
[[ not  forced  back  to the list, so be sure to Cc linuxppc-dev if your ]]
[[ reply is of general interest. Please check http://lists.linuxppc.org/ ]]
[[ and http://www.linuxppc.org/ for useful information before posting.   ]]

Re: Communicator Crashes X II

[Paul Mackerras]

Geert Uytterhoeven <Geert.Uytterhoeven@cs.kuleuven.ac.be> wrote:

> Perhaps the kernel spends too much time in the interrupt handling section of
> the IDE driver? We saw similar things on m68k.

Or the SCSI code.  I recently converted the mesh and mac53c94 drivers
to use the `new-style' error handling (it didn't take as much hacking
as I had expected).  One result is that the command-done processing in
the scsi mid-layer gets done in a BH handler rather than in an
interrupt handler with interrupts disabled.  I noticed that I got far
fewer serial overruns with the new code during disk activity.

I don't see the FB. overflow messages, but then I don't run the serial
port at 115200, only at 57600.  Is it a common feature that people who
see the FB. overflow message are running the serial port at 115200 or
230400 baud?

Paul.

[[ This message was sent via the linuxppc-dev mailing list.  Replies are ]]
[[ not  forced  back  to the list, so be sure to Cc linuxppc-dev if your ]]
[[ reply is of general interest. Please check http://lists.linuxppc.org/ ]]
[[ and http://www.linuxppc.org/ for useful information before posting.   ]]

Improving gatwick interrupts

[Benjamin Herrenschmidt]

Hi !

The current implementation of the interrupt handler for gatwick (the
second mac-io found on some PowerBooks) is not perfect. Currently, it's a
special handler for the cascaded interrupt which will decode the GW
interrupt and call back recursively the ppc_irq_dispatch_handler.

That means that while a given GW interrupt is beeing handled, all other
GW interrupts are suspended (masked). In theory, once we have ask&mask'ed
the real interrupt in GW controller, we could re-enable the GW cascade
interrupt itself to let other interrupts come in from the second controller. 

The problem is that it requires an awful hack to the current
architecture, like passing a special parameter to
ppc_irq_dispatch_handler with the interrupt to re-enable after the
ack&mask operation.

Do you think there is interest in doing that ? Currently, the only
possible users of GW interrupts are the internal modem of the wallstreet,
the left media bay IDE devices or the left media bay floppies.


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


[[ This message was sent via the linuxppc-dev mailing list.  Replies are ]]
[[ not  forced  back  to the list, so be sure to Cc linuxppc-dev if your ]]
[[ reply is of general interest. Please check http://lists.linuxppc.org/ ]]
[[ and http://www.linuxppc.org/ for useful information before posting.   ]]

A few sleep patches

[Benjamin Herrenschmidt]

At:

<http://calvaweb.calvacom.fr/bh40/test.html>

You'll find a few patches to apply to your latest stable tree. I've
changed a bit of things in the media bay code (increasing reset timer and
a few more hacks to make sure the states goes to MB_NO before switching
to a new device, just in case...), it looks a lot more reliable on my
wallstreet (no more CD badly inserted printk, at least not today ;-)

I've added the sleep code for media bay, macserial (untested) and fixed a
minor thing in the sleep code for video (added a chipid, enabled FB
backup (we may be able to get rid of it, I'm not sure for LP_CHIP_ID)).

There may be one or two more things, I don't remember if I included my
root partition detect fix (actually, I don't remember if my mkpatch
script did diff drivers/block/genhd.c and can't test now).

Tell me if it causes trouble on your machine, I'll try to do more tests
tomorrow.

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


[[ This message was sent via the linuxppc-dev mailing list.  Replies are ]]
[[ not  forced  back  to the list, so be sure to Cc linuxppc-dev if your ]]
[[ reply is of general interest. Please check http://lists.linuxppc.org/ ]]
[[ and http://www.linuxppc.org/ for useful information before posting.   ]]

Re: Communicator Crashes X II

[Jerry Quinn]

>> "Paul" == Paul Mackerras <paulus@cs.anu.edu.au> writes:

 Paul> Geert Uytterhoeven <Geert.Uytterhoeven@cs.kuleuven.ac.be> wrote:

 Paul> I don't see the FB. overflow messages, but then I don't run the serial
 Paul> port at 115200, only at 57600.  Is it a common feature that people who
 Paul> see the FB. overflow message are running the serial port at 115200 or
 Paul> 230400 baud?

I see a lot of these messages at 115200 when downloading big files over ppp.
This is on a powercenter on vanilla 2.2.10.

Jerry

-- 
Jerry Quinn                             Tel: (514) 761-8737
jquinn@nortelnetworks.com               Fax: (514) 761-8505
Speech Recognition Research


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

Re: Communicator Crashes X II

[Ira K Weiny]

Well I may have some more news about this problem...

Fisrt I just locked up using lynx!!!  Box rebooted after? 1min?  Again proves
this is not Netscape, nor a font issue etc.
 
I had 2 hard crashes one right after the other.  The first after having set up
my printer on my other serial port.  One thing I did during this was to unplug
my Pilot cradle and plug in my Printer.  The two crashes occured shortly after
that.  Could this be a problem with the serial code/our hardware.  (PS I know
that you are not supposed to hot swap the serial ports.  I just have gotten
into bad habbits over the years. ;-)

I don't know about others but my 8500 has been moved from dorm room to home and
around more times that I can think.  I have plug/unpluged the serial port more
time that I can think.  A couple of us have said they use Cable modems and I am
going to DSL as soon as Pac Bell can get out here to hook me up.  This tends to
rule out the networking code...

So what about the serial ports.  I am thinking the problem may lie there.  Does
anyone else have thoughts/info which might support this theory.

Thanks
Ira Weiny

BTW I am trying to get 2.2.10 compiled so I can start messing with the code.
Have not gotten it to boot yet...  ;-(  Was just trying to get some OF info off
the web when this problem acted up...


[[ This message was sent via the linuxppc-dev mailing list.  Replies are ]]
[[ not  forced  back  to the list, so be sure to Cc linuxppc-dev if your ]]
[[ reply is of general interest. Please check http://lists.linuxppc.org/ ]]
[[ and http://www.linuxppc.org/ for useful information before posting.   ]]