Re: 2.6.23-rc7-mm1

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

 



On Mon, 24 Sep 2007 21:07:19 +0200
"Torsten Kaiser" <[email protected]> wrote:

> On 9/24/07, Andrew Morton <[email protected]> wrote:
> >
> > ftp://ftp.kernel.org/pub/linux/kernel/people/akpm/patches/2.6/2.6.23-rc7/2.6.23-rc7-mm1/
> 
> With the five hotfixes applied it works for me.
> 
> But it fails to power down my system when shutting down.
> 
> It prints twice 'System halted' and blinks the keyboard leds, but does
> not switch off. On all other kernel version I only see one keyboard
> blink before the power goes out.

ok...

> I compared its dmesg to vanilla-rc7 and -rc4-mm1, but expect that rc-4
> assigns different IRQs I can't see any differences except the normal
> variation in BogoMips etc.
> 
> As the system still responded to SysRq I got the following informations:

good move.

> [  415.770000] SysRq : Show Regs
> [  415.770000] CPU 3:
> [  415.780000] Modules linked in: radeon drm nfsd exportfs ipv6 tuner
> tea5767 tda8290 tuner_simple mt20xx tvaudio msp3400 bttv video_buf
> ir_common compat_ioctl32 btcx_risc tveeprom videodev v4l2_common
> v4l1_compat pata_amd usbhid hid sg
> [  415.780000] Pid: 0, comm: swapper Not tainted 2.6.23-rc7-mm1 #1
> [  415.780000] RIP: 0010:[<ffffffff8020ac79>]  [<ffffffff8020ac79>]
> default_idle+0x29/0x40
> [  415.780000] RSP: 0018:ffff81010038bf30  EFLAGS: 00000246
> [  415.780000] RAX: 0000000000000400 RBX: ffffffff80810040 RCX: 0000000000000000
> [  415.780000] RDX: 0000000000000000 RSI: 0000000000000001 RDI: 0000000000000005
> [  415.780000] RBP: 0000000000030400 R08: 0000000000000000 R09: ffff81010038be68
> [  415.950000] R10: 000000000100002c R11: ffffffff80219be0 R12: 0000000000000000
> [  415.950000] R13: 0000000000000000 R14: 0000000000000000 R15: 0000000000000000
> [  415.950000] FS:  00007f35c69726f0(0000) GS:ffff810100319700(0000)
> knlGS:0000000000000000
> [  415.950000] CS:  0010 DS: 0018 ES: 0018 CR0: 000000008005003b
> [  415.950000] CR2: 00007fe432928c40 CR3: 0000000000201000 CR4: 00000000000006e0
> [  416.070000] DR0: 0000000000000000 DR1: 0000000000000000 DR2: 0000000000000000
> [  416.070000] DR3: 0000000000000000 DR6: 00000000ffff0ff0 DR7: 0000000000000400
> [  416.070000]
> [  416.070000] Call Trace:
> [  416.070000]  [<ffffffff8020acea>] cpu_idle+0x5a/0x90
> [  416.070000]
> 
> No blocked tasks were shown with SysRq+W.
> Last lines before I used SysRq+B (That worked, a normal reboot started):
> 
> [  450.780000] SysRq : Emergency Remount R/O
> [  450.790000] Emergency Remount complete
> [  453.650000] SysRq : Emergency Sync
> [  453.660000] Emergency Sync complete
> [  455.910000] SysRq : Power Off
> [  455.920000] md: stopping all md devices.
> [  455.930000] md: md1 still in use.
> [  456.940000] sd 8:0:1:0: [sdd] Synchronizing SCSI cache
> [  456.960000] sd 8:0:1:0: [sdd] Stopping disk
> [  457.480000] sd 2:0:0:0: [sdc] Synchronizing SCSI cache
> [  457.490000] sd 2:0:0:0: [sdc] Stopping disk
> [  457.500000] sd 1:0:0:0: [sdb] Synchronizing SCSI cache
> [  457.520000] sd 1:0:0:0: [sdb] Stopping disk
> [  457.530000] sd 0:0:0:0: [sda] Synchronizing SCSI cache
> [  457.550000] sd 0:0:0:0: [sda] Stopping disk
> [  457.560000] Power down.
> [  479.090000] SysRq : Power Off
> [  479.100000] md: stopping all md devices.
> [  479.110000] md: md1 still in use.
> [  480.120000] sd 8:0:1:0: [sdd] Synchronizing SCSI cache
> [  480.140000] sd 8:0:1:0: [sdd] Stopping disk
> [  480.660000] sd 2:0:0:0: [sdc] Synchronizing SCSI cache
> [  480.670000] sd 2:0:0:0: [sdc] Stopping disk
> [  480.680000] sd 1:0:0:0: [sdb] Synchronizing SCSI cache
> [  480.700000] sd 1:0:0:0: [sdb] Stopping disk
> [  480.710000] sd 0:0:0:0: [sda] Synchronizing SCSI cache
> [  480.730000] sd 0:0:0:0: [sda] Stopping disk
> [  480.740000] Power down.
> [  489.030000] SysRq : Resetting
> 

hm, dunno.  The only substantial patch which touches
arch/x86_64/kernel/process.c (which is where cpu_idle lives) is
x86_64-prep-idle-loop-for-dynticks.patch.

The problem is, 2.6.23-rc6-mm1's git-acpi patch had all the new cpuidle
code in it.  Len dropped all that code over the weekend (which is when I
picked this copy of his tree), so 2.6.23-rc7-mm1 doesn't have the cpuidle
code.  Len will be reapplying the cpuidle patches today(ish) so next -mm
_will_ have the cpuidle code.

So what we have in rc7-mm1 is this transient no-cpuidle state.  It could be
that the x86_64 dynticks code (which was developed previously tested in
conjunction with the cpuidle patches) has some dependency on cpuidle.

So it's all a bit of a mess :(

I think I'll basically stop applying things which don't look like bugfixes
for a while and try to get more -mm's out, as we seriously need to get this
lot stabilised asap.

Len, would it be possible to restore cpuidle sometime today please?
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [email protected]
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

[Index of Archives]     [Kernel Newbies]     [Netfilter]     [Bugtraq]     [Photo]     [Stuff]     [Gimp]     [Yosemite News]     [MIPS Linux]     [ARM Linux]     [Linux Security]     [Linux RAID]     [Video 4 Linux]     [Linux for the blind]     [Linux Resources]
  Powered by Linux