Hi All,
This is due to the system polling the serial interface by continually
adding a task to the workqueue
The flush cpu workqueue is waiting for the workqueue to be empty which
never happens due to serial polling action.
I have not got a "good" solution yet.
Some options are :
1/ turn
Bob, I was having similar problems about 2 months back. I was porting
the eb01/eb40 code over to an at91sam7se512. The uart PDC registers on
the sam7 are at higher addresses than they were on the eb40 [and
serial_atmel driver code]. Until I had located these registers
correctly [padding th
Glenn Henshaw wrote:
Has anyone experienced an issue with including the Atmel serial driver
and the console connection to the Atmel serial driver not allowing the
system to continue to boot.
If i do not have the Atmel serial driver built into the kernel image
the system boots to the romfs (/b
On 2-May-08, at 12:20 PM, rwarner wrote:
Hi,
Has anyone experienced an issue with including the Atmel serial
driver and the console connection to the Atmel serial driver not
allowing the system to continue to boot.
If i do not have the Atmel serial driver built into the kernel image
th
Hi,
Has anyone experienced an issue with including the Atmel serial driver
and the console connection to the Atmel serial driver not allowing the
system to continue to boot.
If i do not have the Atmel serial driver built into the kernel image the
system boots to the romfs (/bin/init executed
Hi Matt,
Matt Waddel wrote:
Greg Ungerer wrote:
Sebastian Siewior wrote:
* Greg Ungerer | 2008-04-29 10:20:35 [+1000]:
The mcfserial.c driver is obsolete, and I plan on removing it
>from the kernel soon. The mcf.c driver is now the appropriate
one to use. It uese the modern style serial dr
Greg Ungerer wrote:
Sebastian Siewior wrote:
Greg Ungerer wrote:
Sebastian Siewior wrote:
May we agree on a git tree? This would make things easier I guess. Even
Russell has one these days :) This would atleast avoid [2]. And if you
remove the stack address in my other patch please let me know
Sebastian Siewior wrote:
Greg Ungerer wrote:
Sebastian Siewior wrote:
May we agree on a git tree? This would make things easier I guess. Even
Russell has one these days :) This would atleast avoid [2]. And if you
remove the stack address in my other patch please let me know or alteast
leave a n
Greg Ungerer wrote:
Hi Sebastian,
Hi Greg,
Sebastian Siewior wrote:
- you forwarded my patches after you edit them.
Rebased, and regenerated them. Any other change is an
over site. Can you be more specific what content changed?
- You removed the stack address from the backtrace.
- A few f
