[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

RE: Sync Serial 1



Hi Mikael,

I think I found the problem.
After I made a minicom capture file I discovered that the capture file
contained a lot more info than what I got from the screen.

There is indeed a kernel panic at the bottom of the capture file saying:
"Kernel panic: Can't allocate sync serial port 3 IRQ", this is due to
the cause of
me using the ETRAX_FAST_TIMER feature of the etraxboard. The kernel is
at this moment compiling with the fast timer disabled and sync serial
dma enabled.

But that brings me to my next problem :-)
I had enabled the fast_timer to lower the latency on the async serial
port.
We are using the async serial port ( ttyS1 ) as a command and status
communication port
with the firmware. Before I had enabled the fasttimer the latencies
between
async commands was 150ms and with the fasttimer enabled we got a latency
of about
15ms. So now when I must disable the fasttimer to get the sync serial
port running,
We are back at 150ms command and status latency.
Is there any other way to steed up the async port ?????


Thanx,

Peter






> -----Original Message-----
> From: owner-dev-etrax@xxxxxxx.com
> [mailto:owner-dev-etrax@xxxxxxx.com] On Behalf Of Mikael Starvik
> Sent: 14 May 2004 07:40
> To: Peter van Duijn; dev-etrax
> Subject: RE: Sync Serial 1
>
>
> Sorry, I misread your email. It is kind of confusing to
> discuss sync serial 0 that is on serial 1 and sync serial 1
> that is on serial 3...
>
> I still think this is a resource allocation problem (e.g.
> that serial port 3 is enabled). Can you send me the
> kernelconfig and the output
> on the console during bootup (until it stops)?
>
> Regards
> /Mikael
>
> -----Original Message-----
> From: Peter van Duijn [mailto:E.van.Duijn@xxxxxxx.nl]
> Sent: Thursday, May 13, 2004 5:37 PM
> To: 'Mikael Starvik'; dev-etrax
> Subject: RE: Sync Serial 1
>
>
> Thanx Mikael for your quick response.
>
> I'm indeed using async serial port 0 (debug) and port 1.
> But according to the documentation this shouldn't be a
> problem when I want to use the Sync Serial port 1 ( aka serial3 ).
>
> The kernel refuses to boot ( no OOPS, it just stops ) when I
> enable the DMA for sync serial 1. When I disable the DMA for
> this port the kernel boots correctly, but when I read from
> port I get no data back and The read call blocks.
>
> I'm planning to use the sync serial port in slave input mode.
> The firmware on the other side of the port is generating a
> clock And putting data on the port. An application suppose to
> read this And send it to a tcpclient.
>
> What are the correct settings for the SLAVE_INPUT mode.
>
>
> Thanx,
> Peter
>
>
> > -----Original Message-----
> > From: Mikael Starvik [mailto:mikael.starvik@xxxxxxx.com]
> > Sent: 13 May 2004 10:33
> > To: 'Peter van Duijn'; dev-etrax
> > Subject: RE: Sync Serial 1
> >
> >
> > A guess is that you have the normal serial port 1 enabled.
> This must
> > be disabled to run the synchronous serial port ("Serial port 1
> > enabled" in kernelconfig).
> >
> > How does the kernel crash? With some kind of panic printout
> or with a
> > kernel oops? If it dies with an OOPS you can do
> >
> > cd os/linux
> > ksymoops -v vmlinux -K -L -O -m System.map
> >
> > and then copy-paste the OOPS output and email me the result.
> >
> > Can you tell me more about your usage of the sync serial
> port? In some
> > cases the sync serial port is not as useful as you might expect.
> >
> > /Mikael
> >
> > -----Original Message-----
> > From: owner-dev-etrax@xxxxxxx.com">mailto:owner-dev-etrax@xxxxxxx.com] On
> > Behalf Of > Peter van Duijn
> > Sent: Thursday, May 13, 2004 10:19 AM
> > To: dev-etrax
> > Subject: Sync Serial 1
> >
> >
> > Hi group,
> >
> > Can anyone help me with my Sync serial problem.
> > I'm working on the Devboard 82 and I'm trying to enable the
> syncserial
> > 1 port. But every time boot up with a kernel that has the
> sync serial
> > port 1 enabled (and async 3 disabled), the kernel crashes :-(
> >
> > Any suggestions ?
> >
> > Regards,
> > Peter
> >
> >
>
>