[PATCH] 8xx_io/uart.c
Joakim Tjernlund
joakim.tjernlund at lumentis.se
Wed Feb 12 05:07:54 EST 2003
> Joakim Tjernlund wrote:
>
> > ..... Will KGDB/XMON write this early and/or
> > is KGDB/XMON guaranteed not to write a LF?
>
> Yes, yes. Making these work, especially kgdb, was a real PITA.
> Both format their own packets/strings and expect behavior of
> reading/writing directly to a uart FIFO. Like I said, if you really
> understand how xmon/kgdb work, you would understand why these functions
> are written exactly as they are.
I think I know why the are as they are now. KGDB/XMON stuff is messy and if you
are sure that XMON/KGDB never outputs a LF all is fine.
>
> The printk never calls a serial driver before it is fully initialized.
> Debugger serial interfaces, especially kgdb, expect a simple uart fifo
> immediately available within a few hundred lines of kernel code execution.
printk's will go out after serial_console_setup() has executed which I don't
consider "fully initialized" but it's initialized enough for printk's to get
out safely.
>
>
> > The buffer is kmalloc'ed and kmalloc always returns L1 cache aligned buffers.
> > Then __dev_alloc_skb()/dev_alloc_skb() reserves 16 bytes in the beginning of the
> > buffer and since the L1 cache line is 16 bytes it is still L1 cache aligned.
>
> It's the data at the end of the buffer that's the problem. The IP stack (used
> to) stores information in dynamically allocated memory that would get corrupted
> when buffers were invalidated. There was lots of discussion about this on kernel
> and other mailing lists (like mips and arm). After we found it, there was some
> discussion about how to fix it, but I didn't follow up on all of the details.
> To ensure this works, you have to configure a forwarding/routing multiple
> ethernet environment and get the 8xx to forward packets across the links.
> That was the failure condition, there are people using 8xx in these configurations,
> and we can't introduce a "solution" that has been known to be a problem in
> the past.
>
> > You think I just hacked this up and throwed it over the fence?
>
> No, but you could have saved yourself some time by reading the archives.
> You could have started with:
> http://lists.linuxppc.org/linuxppc-embedded/200008/msg00105.html
> and then:
> http://lists.linuxppc.org/linuxppc-embedded/200106/msg00078.html
>
Like I said, if you had given me a better hint then "the archives" we
could had resolved this long ago.
I have checked the links above it looks like it's solved. As far as I can
tell alternative:
0. change alloc_skb()/skb_add_mtu() to force the allocated size to be a
cache line multiple.
has been impl. in the kernel:
- skb_add_mtu() does not exist anymore.
- alloc_skb() does L1 cache align the size:
size = requested_size + 16;
size = SKB_DATA_ALIGN(size); /* this does L1 cache alignment */
data = kmalloc(size + sizeof(struct skb_shared_info), gfp_mask);
This makes the skb_shared_info to always start on a new cache line.
There is no risk that it is invalidated by dma_cache_inv() call.
Jocke
** Sent via the linuxppc-embedded mail list. See http://lists.linuxppc.org/
More information about the Linuxppc-embedded
mailing list