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

RE: serial spewing garbage



You have two options:

1. I have an experimental fix for this problem that is
currently being tested by developers at Axis. I can
send this patch to you.

2. In arch/cris/kernel/debugport.c there is a console
struct called sercons.  If you call unregister_console
with this as argument the console messages should
disappear. To do this you have to make sercons public
and maybe rename it to avoid namclashing.

/Mikael

-----Original Message-----
From: owner-dev-etrax@xxxxxxx.com
To: dev-etrax
Sent: 2003-02-12 17:09
Subject: serial spewing garbage

Hi,

We are using two Etrax 100lx's in our design.

We are experiencing occational garbage characters coming out of the
serial 
port on one of the processors. Not just one or two characters, but
hundreds 
at a time. When this happens, it's like the serial driver takes over and

everything else takes a back seat. The output is meaningless. It looks
like 
  digital vomit. After it's finished, things go back to normal.

The processor that this happens on is running a device driver that we
have 
written. Also this processor is *very* busy followed by a short period 
where it's idle. When the serial starts spewing, it screws up our driver

(ie. things don't get done on time).

I have turned off all printk's in the driver except for boot time
messages. 
This seems to help reduce the occurance of the problem. Or another way
of 
putting it is; If I perform a few printk's while the driver is idle, the

problem happens quite often.

Both processors are running the same kernel image. The only difference
is 
that the driver on the "happy" processor is not exercising the driver at

all (the interrupt is hooked but it's disabled and no ioctls are
called).

Now to my question:

How can I completely disable all serial ports on the one processor after

boot up, using the same kernel image?

We don't want to have to deal with two different kernel images. I know
this 
is a kludge, but it's the only work around I can think of.

Can I just disable "free_irq()" all of the interrupts used by the
serial?

Thanks,

Randy