2.6.22.15: kernel processes stuck in D state

2.6.22.15: kernel processes stuck in D state

[CaT]

[-- Attachment #1: Type: text/plain, Size: 769 bytes --]

I recently upgraded from an amd 64bit system to an intel one and changed my 
kernekl accordingly. Everything's great except this:

root         6  0.0  0.0     0    0 ?        D<   17:11   0:00 [migration/1]
root         7  0.0  0.0     0    0 ?        D<   17:11   0:00 [ksoftirqd/1]
root         8  0.0  0.0     0    0 ?        D<   17:11   0:00 [watchdog/1]

I've tried various kernel configs and that stays the same, including a 
constant load of 3. My current kernel config and dmesg is attached
(compressed as I think the ml limit is 40k).

Not sure what other info to provide so if anything else would be
helpful, please shout.

-- 
    "To the extent that we overreact, we proffer the terrorists the
    greatest tribute."
    	- High Court Judge Michael Kirby

[-- Attachment #2: config.gz --]
[-- Type: application/octet-stream, Size: 7550 bytes --]

[-- Attachment #3: dmesg.gz --]
[-- Type: application/octet-stream, Size: 5414 bytes --]

Re: 2.6.22.15: kernel processes stuck in D state

[Stefan Richter]

CaT wrote:
> Not sure what other info to provide

Is the bug present in 2.6.24-rc7?
-- 
Stefan Richter
-=====-==--- ---= -=-==
http://arcgraph.de/sr/

Re: 2.6.22.15: kernel processes stuck in D state

[CaT]

On Fri, Jan 11, 2008 at 12:20:58PM +0100, Stefan Richter wrote:
> CaT wrote:
> > Not sure what other info to provide
> 
> Is the bug present in 2.6.24-rc7?

Can't rightly say. I didn't try it before because 2.6.23 fails to
compile under debian sarge. 2.6.24-rc7 did compile but it has failed to
come back up. Don't know why as the box is remote (though it wasn't in
use again yet due to the afore mentioned problems so this is merely an
annoyance). I'll find out more on Monday.

-- 
    "To the extent that we overreact, we proffer the terrorists the
    greatest tribute."
    	- High Court Judge Michael Kirby

Re: 2.6.22.15: kernel processes stuck in D state

[CaT]

On Sat, Jan 12, 2008 at 09:15:16AM +1100, CaT wrote:
> On Fri, Jan 11, 2008 at 12:20:58PM +0100, Stefan Richter wrote:
> > CaT wrote:
> > > Not sure what other info to provide
> > 
> > Is the bug present in 2.6.24-rc7?
> 
> Can't rightly say. I didn't try it before because 2.6.23 fails to
> compile under debian sarge. 2.6.24-rc7 did compile but it has failed to
> come back up. Don't know why as the box is remote (though it wasn't in
> use again yet due to the afore mentioned problems so this is merely an
> annoyance). I'll find out more on Monday.

Ok. Not sure why it didn't boot the first time (black screen) but it
booted the second time. This time both CPUs got initialised and are in
use, no kernel oops during init and no kernel processes stuck in D
state. Should've tried .24 earlier but .23 failed to compile under sarge
due to a buggy binutils so I figured .24 would too.

-- 
    "To the extent that we overreact, we proffer the terrorists the
    greatest tribute."
    	- High Court Judge Michael Kirby

Re: 2.6.22.15: kernel processes stuck in D state

[CaT]

On Fri, Jan 11, 2008 at 07:12:33PM +1100, CaT wrote:
> I recently upgraded from an amd 64bit system to an intel one and changed my 
> kernekl accordingly. Everything's great except this:
> 
> root         6  0.0  0.0     0    0 ?        D<   17:11   0:00 [migration/1]
> root         7  0.0  0.0     0    0 ?        D<   17:11   0:00 [ksoftirqd/1]
> root         8  0.0  0.0     0    0 ?        D<   17:11   0:00 [watchdog/1]
> 
> I've tried various kernel configs and that stays the same, including a 
> constant load of 3. My current kernel config and dmesg is attached
> (compressed as I think the ml limit is 40k).
> 
> Not sure what other info to provide so if anything else would be
> helpful, please shout.

I'm just taking a closer look at things now that I've recovered from
spending a day in a nice, loud server room and things are popping up
that make me wonder if 2.6.22.15 is just too old for this motherboard.

> MPTABLE: OEM ID: OEM00000 MPTABLE: Product ID: PROD00000000 MPTABLE: APIC at: 0xFEE00000
> Processor #0 (Bootup-CPU)
> Processor #1
> I/O APIC #4 at 0xFEC00000.
> Setting APIC routing to flat
> Processors: 2

As it should be. Dual core.

> Booting processor 1/2 APIC 0x1
> Not responding.
> Inquiring remote APIC #1...
> ... APIC #1 ID: failed
> ... APIC #1 VERSION: failed
> ... APIC #1 SPIV: failed
> Brought up 1 CPUs

Ook? Shouldn't that be 2? Infact, /proc/cpuinfo confirms this. I only
have one core up.

> Initializing CPU#1
...
> Kernel panic - not syncing: smp_callin: CPU1 started up but did not get a callout!

Eek! This doesn't look so good.

So I now have a nice, brand new, spiffy motherboard and a dual core
cpu... with one core not in use, a weird panic relating to CPUs and
kernel processes hung in D state. Whee! :)

-- 
    "To the extent that we overreact, we proffer the terrorists the
    greatest tribute."
    	- High Court Judge Michael Kirby