Prev: [PATCH -v3] x86,nobootmem: make alloc_bootmem_node fall back to other node when 32bit numa are used
Next: x86, mem: Optimize memcpy by avoiding memory false dependece
From: H. Peter Anvin on 10 Jul 2010 17:40 On 07/10/2010 02:07 PM, Cyrill Gorcunov wrote: > On Sat, Jul 10, 2010 at 10:40:20PM +0300, Pekka Enberg wrote: >> This patch adds serial I/O support to very early boot printf(). It's useful for >> debugging boot code when running Linux under KVM, for example. The actual code >> >> +#define cpu_relax() asm volatile("rep; nop" ::: "memory") >> + We don't need "memory" here since the early boot environment is single-threaded. -hpa -- H. Peter Anvin, Intel Open Source Technology Center I work for Intel. I don't speak on their behalf. -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majordomo(a)vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
From: Pekka Enberg on 10 Jul 2010 17:40 On Sun, Jul 11, 2010 at 12:27 AM, H. Peter Anvin <hpa(a)zytor.com> wrote: > On 07/10/2010 02:17 PM, Pekka Enberg wrote: >> On Sat, Jul 10, 2010 at 11:49 PM, Yinghai Lu <yinghai(a)kernel.org> wrote: >>> can you analyze "console=uart8250,io,0x3f8,115200n8" instead? >>> >>> that is equal to "earlyprintk=ttyS0,115200 console=ttyS0,115200" >>> >>> so we only use one for all. >>> >>> also like to kill earlyprintk=ttyS0,115200 to favor earlycon >> >> hpa, what's your take on this? >> >> The 'console' variant seems overly complicated to me. We can add it >> but we also need to check for 'earlyprintk' as long as it's supported >> by the kernel. >> > > earlyprintk= seems to be preferred over console= these days. �Quite > frankly it's idiotic to have the user enter as many low-level details as > one has to do for the console= one. > > Now, as for the I/O base, the I/O base for legacy serial ports are > available from a 4-element u16 array starting at absolute address 0x400. > �I don't think Linux currently examines that array -- instead relying on > the hard-coded values 0x3f8, 0x2f8, 0x3e8, 0x2e8 -- but it might > something to consider for the future. �However, we should match the > serial port subsystem there, of course. OK. The current patch should match 'earlyprintk' handling which uses hard-coded values only. -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majordomo(a)vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
From: Cyrill Gorcunov on 10 Jul 2010 18:00 On Sat, Jul 10, 2010 at 02:37:01PM -0700, H. Peter Anvin wrote: > On 07/10/2010 02:07 PM, Cyrill Gorcunov wrote: > > On Sat, Jul 10, 2010 at 10:40:20PM +0300, Pekka Enberg wrote: > >> This patch adds serial I/O support to very early boot printf(). It's useful for > >> debugging boot code when running Linux under KVM, for example. The actual code > >> > >> +#define cpu_relax() asm volatile("rep; nop" ::: "memory") > >> + > > We don't need "memory" here since the early boot environment is > single-threaded. > > -hpa > I rather wonder -- can't we use cpu_relax() from processor.h? Or there is some type conflicts? -- Cyrill -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majordomo(a)vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
From: H. Peter Anvin on 10 Jul 2010 18:40 On 07/10/2010 02:55 PM, Cyrill Gorcunov wrote: > > I rather wonder -- can't we use cpu_relax() from processor.h? Or there > is some type conflicts? > Probably. The boot environment is pretty different, and not sharing header files where we don't need to because of shared data structures is probably a good idea. -hpa -- H. Peter Anvin, Intel Open Source Technology Center I work for Intel. I don't speak on their behalf. -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majordomo(a)vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
From: Pekka Enberg on 11 Jul 2010 03:20
On 07/10/2010 02:55 PM, Cyrill Gorcunov wrote: >> I rather wonder -- can't we use cpu_relax() from processor.h? Or there >> is some type conflicts? H. Peter Anvin wrote: > Probably. The boot environment is pretty different, and not sharing > header files where we don't need to because of shared data structures is > probably a good idea. I did try it but got bunch of compile errors and figured I was not supposed to use it. Pekka -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majordomo(a)vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/ |