Hi,
I have tried the "slow down printk" , and I have two questions.
1. why it depends the DEBUG_KERNEL? Sometimes we only need boot_delay
to see the printk infomations. How about set it as a standalone
config option?
2. In My system if I boot with boot_delay=200 the early part of
booting will be very slow, eapecially at the very beginning (after the
compressing and start kernel, it nearly stop here many minutes).
And I wonder if we can simply use mdelay in the boot_delay_msec(). I
tested the mdelay , and the result is more accurate.
Regards
dave
On Wed, 8 Aug 2007 07:39:33 +0000 Dave Young wrote:
> Hi,
> I have tried the "slow down printk" , and I have two questions.
>
> 1. why it depends the DEBUG_KERNEL? Sometimes we only need boot_delay
> to see the printk infomations. How about set it as a standalone
> config option?
Is depending on DEBUG_KERNEL a problem? If so, why?
It sure seems like a kernel debug option to me, although
I have no strong preference pro or con on this.
> 2. In My system if I boot with boot_delay=200 the early part of
> booting will be very slow, eapecially at the very beginning (after the
> compressing and start kernel, it nearly stop here many minutes).
>
> And I wonder if we can simply use mdelay in the boot_delay_msec(). I
> tested the mdelay , and the result is more accurate.
I wasn't convinced that loops_per_jiffy was always set for all
architectures that early during boot. Did you audit and verify that
it is set early enough to use during boot_delay_msec()?
and if so, for all architectures?
What architectures did you test this on?
---
~Randy
*** Remember to use Documentation/SubmitChecklist when testing your code ***
>On 8/12/07, Randy Dunlap <[email protected]> wrote:
> On Wed, 8 Aug 2007 07:39:33 +0000 Dave Young wrote:
>
> > Hi,
> > I have tried the "slow down printk" , and I have two questions.
> >
> > 1. why it depends the DEBUG_KERNEL? Sometimes we only need boot_delay
> > to see the printk infomations. How about set it as a standalone
> > config option?
>
> Is depending on DEBUG_KERNEL a problem? If so, why?
IMHO, the DEBUG_KERNEL will build a big kernel and the building time
is long, so if the we only want to look at the boot messages at panic
point, the DEBUG_KERNEL is not needed.
>
> It sure seems like a kernel debug option to me, although
> I have no strong preference pro or con on this.
>
> > 2. In My system if I boot with boot_delay=200 the early part of
> > booting will be very slow, eapecially at the very beginning (after the
> > compressing and start kernel, it nearly stop here many minutes).
> >
> > And I wonder if we can simply use mdelay in the boot_delay_msec(). I
> > tested the mdelay , and the result is more accurate.
>
> I wasn't convinced that loops_per_jiffy was always set for all
> architectures that early during boot. Did you audit and verify that
> it is set early enough to use during boot_delay_msec()?
> and if so, for all architectures?
> What architectures did you test this on?
I386 for me. I tested boot_delay=300 again:
1. From "Uncompressing Linux.. Ok,booting the kernel" to "console
[tty0] enabled"
keep the same screen about 5-6 minutes
2. After that every line will need 20-30 seconds.
My cpuinfo:
processor : 0
vendor_id : GenuineIntel
cpu family : 15
model : 4
model name : Intel(R) Pentium(R) D CPU 2.80GHz
stepping : 7
cpu MHz : 2793.181
cache size : 1024 KB
physical id : 0
siblings : 2
core id : 0
cpu cores : 2
fdiv_bug : no
hlt_bug : no
f00f_bug : no
coma_bug : no
fpu : yes
fpu_exception : yes
cpuid level : 5
wp : yes
flags : fpu vme de pse tsc msr pae mce cx8 apic sep mtrr pge mca cmov
pat pse36 clflush dts acpi mmx fxsr sse sse2 ss ht tm pbe nx lm
constant_tsc pebs bts sync_rdtsc pni monitor ds_cpl cid cx16 xtpr
lahf_lm
bogomips : 5591.66
clflush size : 64
processor : 1
vendor_id : GenuineIntel
cpu family : 15
model : 4
model name : Intel(R) Pentium(R) D CPU 2.80GHz
stepping : 7
cpu MHz : 2793.181
cache size : 1024 KB
physical id : 0
siblings : 2
core id : 1
cpu cores : 2
fdiv_bug : no
hlt_bug : no
f00f_bug : no
coma_bug : no
fpu : yes
fpu_exception : yes
cpuid level : 5
wp : yes
flags : fpu vme de pse tsc msr pae mce cx8 apic sep mtrr pge mca cmov
pat pse36 clflush dts acpi mmx fxsr sse sse2 ss ht tm pbe nx lm
constant_tsc pebs bts sync_rdtsc pni monitor ds_cpl cid cx16 xtpr
lahf_lm
bogomips : 5587.46
clflush size : 64
Regards
dave
On Wed, Aug 15, 2007 at 03:45:08PM +0800, Dave Young wrote:
> >On 8/12/07, Randy Dunlap <[email protected]> wrote:
> > On Wed, 8 Aug 2007 07:39:33 +0000 Dave Young wrote:
> >
> > > Hi,
> > > I have tried the "slow down printk" , and I have two questions.
> > >
> > > 1. why it depends the DEBUG_KERNEL? Sometimes we only need boot_delay
> > > to see the printk infomations. How about set it as a standalone
> > > config option?
> >
> > Is depending on DEBUG_KERNEL a problem? If so, why?
>
> IMHO, the DEBUG_KERNEL will build a big kernel and the building time
> is long, so if the we only want to look at the boot messages at panic
> point, the DEBUG_KERNEL is not needed.
Only if you enable other debug options too. (Yes, some default to on,
perhaps they shouldn't).
DEBUG_KERNEL itself shouldn't make any difference to the generated
code at all.
Dave
--
http://www.codemonkey.org.uk