atom feed27 messages in org.freebsd.freebsd-stableRe: Regression 7.0R -> 7-stable?
FromSent OnAttachments
Gerrit KühnAug 7, 2008 4:29 am 
Edwin GroothuisAug 7, 2008 4:46 am 
Jeremy ChadwickAug 7, 2008 5:19 am 
Gerrit KühnAug 7, 2008 5:35 am 
Edwin GroothuisAug 7, 2008 5:35 am 
Xin LIAug 7, 2008 3:55 pm 
Gerrit KühnAug 13, 2008 11:46 pm 
Gerrit KühnAug 22, 2008 5:05 am 
John BaldwinAug 23, 2008 4:49 am 
Gerrit KühnAug 25, 2008 12:49 am 
Jeremy ChadwickAug 25, 2008 12:53 am 
Gerrit KühnAug 27, 2008 2:16 am 
Gerrit KühnOct 7, 2008 4:37 am 
Gerrit KühnOct 7, 2008 5:37 am 
Jeremy ChadwickOct 7, 2008 6:36 am 
John BaldwinOct 7, 2008 7:02 am 
Gerrit KühnOct 7, 2008 7:15 am 
Jeremy ChadwickOct 7, 2008 7:25 am 
Gerrit KühnOct 7, 2008 8:07 am 
John BaldwinOct 7, 2008 9:05 am 
Gerrit KühnOct 10, 2008 3:21 am 
John BaldwinOct 10, 2008 8:21 am 
Gerrit KühnOct 13, 2008 12:09 am 
John BaldwinOct 13, 2008 7:27 am 
Gerrit KühnOct 14, 2008 2:53 am 
John BaldwinOct 14, 2008 10:11 am 
Gerrit KühnOct 31, 2008 4:01 am 
Subject:Re: Regression 7.0R -> 7-stable?
From:Gerrit Kühn (ger@pmp.uni-hannover.de)
Date:Oct 14, 2008 2:53:10 am
List:org.freebsd.freebsd-stable

On Mon, 13 Oct 2008 10:27:40 -0400 John Baldwin <jh@freebsd.org> wrote about Re: Regression 7.0R -> 7-stable?:

JB> On Monday 13 October 2008 03:09:46 am Gerrit Kühn wrote:

JB> > JB> Ok, can you run gdb on your kernel.debug and do JB> > JB> 'l *0xffffffff804608c0'

JB> > 0xffffffff804608c0 is in scheduler (/usr/src/sys/vm/vm_glue.c:670). JB> > [...lines 665-674...]

JB> I was afraid of that, it basically means that it finished the entire JB> boot process.

I already thought so because I saw a grey (not white) cursor afterwards.

JB> The next step is that init (pid 1) should be scheduled JB> and try to execute. You can maybe add some printf's to the code to JB> start up init to see how far it gets. The routine in question is JB> 'start_init()' in sys/kern/init_main.c.

Let me see... I added my first printf in line 619 (and several after that), right after the "Need just enough stack..." comment. This was never reached, the system hangs before that.

After that I added printf before and after vfs_mountroot(). Now the things runs just a bit further for the first time. I see my new printfs and between them the message "Trying to mount root from ufs:/dev/ad0s1a". After that come all my printfs I had added before, followed by "start_init: trying /sbin/init". Then it hangs again.

I am a bit puzzled because I did not see the "Trying to mount..." and "start_init:..." messages before. Just trying again to boot with the same setup hangs in vfs_mountroot() (printf before is displayed, printf after not). It appears to me as if the hang is caused by some kind of "parallel task", and what I am seeing on the console stops a bit earlier or later depending on that. As I am seeing this only with the ULE-scheduler: Is the scheduler already in action at this point, and may the hang depend on what it is deciding to do?

cu Gerrit