Re: 2.6.12-rc2-mm1

[Neil Brown <neilb@cse.unsw.edu.au>]

On Tuesday April 5, akpm@osdl.org wrote:
> 
> - Nobody said anything about the PM resume and DRI behaviour in
>   2.6.12-rc1-mm4.  So it's all perfect now?

Well, Seeing you asked...

PM resume certainly seems to be improving.
My main problem in rc1-mm3 is with PCMCIA.
If I stop cardmgr before suspend-to-RAM, and then try to
restart it after resume, I cannot.  Some message about the socket
being in use, and am I sure there is no other cardmgr running (there
isn't). 

I can stop and restart happily before suspending, but not after.
If I leave it running during a suspend/resume cycle it keeps working
but if I then stop and restart, it fails.

(and if I do leave it running, my PCMCIA wireless gets started before
my tg3 wired, so eth0 and eth1 get swapped).

I just tried rc2-mm1 and... decided to go back to rc1-mm3.

It seemed to boot mostly OK.  I tried suspend-to-RAM and it seems to
suspend.  But when I turned it back on again it rebooted rather than
resumed.

During boot I got:

Apr  6 10:18:46 localhost kernel: cs: memory probe 0xf6000000-0xfbffffff:iounmap: bad address f8828000
Apr  6 10:18:46 localhost kernel:  [set_cis_map+150/256] set_cis_map+0x96/0x100
Apr  6 10:18:46 localhost kernel:  [remove_vm_area+60/80] remove_vm_area+0x3c/0x50
Apr  6 10:18:46 localhost kernel:  [pcmcia_read_cis_mem+412/560] pcmcia_read_cis_mem+0x19c/0x230
Apr  6 10:18:46 localhost kernel:  [set_cis_map+150/256] set_cis_map+0x96/0x100
Apr  6 10:18:46 localhost kernel:  [read_cis_cache+358/400] read_cis_cache+0x166/0x190
Apr  6 10:18:46 localhost kernel:  [follow_link+141/544] follow_link+0x8d/0x220
Apr  6 10:18:46 localhost kernel:  [pccard_get_next_tuple+688/784] pccard_get_next_tuple+0x2b0/0x310
Apr  6 10:18:46 localhost kernel:  [pccard_get_first_tuple+144/336] pccard_get_first_tuple+0x90/0x150
Apr  6 10:18:46 localhost kernel:  [pccard_validate_cis+151/592] pccard_validate_cis+0x97/0x250
Apr  6 10:18:46 localhost kernel:  [readable+90/160] readable+0x5a/0xa0
Apr  6 10:18:46 localhost kernel:  [cis_readable+129/224] cis_readable+0x81/0xe0
Apr  6 10:18:46 localhost kernel:  [do_mem_probe+469/496] do_mem_probe+0x1d5/0x1f0
Apr  6 10:18:46 localhost kernel:  [inv_probe+159/176] inv_probe+0x9f/0xb0
Apr  6 10:18:46 localhost kernel:  [validate_mem+271/304] validate_mem+0x10f/0x130
Apr  6 10:18:46 localhost kernel:  [default_wake_function+0/32] default_wake_function+0x0/0x20
Apr  6 10:18:46 localhost kernel:  [pcmcia_nonstatic_validate_mem+120/128] pcmcia_nonstatic_validate_mem+0x78/0x80
Apr  6 10:18:46 localhost kernel:  [pcmcia_validate_mem+26/32] pcmcia_validate_mem+0x1a/0x20
Apr  6 10:18:46 localhost kernel:  [pcmcia_card_add+42/208] pcmcia_card_add+0x2a/0xd0
....

Then it hung in some device discovery.  Not sure which device, maybe
firewire.
Alt-Sysrq-T showed

Apr  6 10:19:45 localhost kernel: khpsbpkt      S C04643E0     0  1956      1          1973   915 (L-TLB)
Apr  6 10:19:45 localhost kernel: f6cf3f94 00000046 f68dd070 c04643e0 f7c0f030 c0464410 00000000 f7c0f030 
Apr  6 10:19:45 localhost kernel:        f6cf3f8c 00000000 00000000 00000000 f68dd070 f68dd198 f8af2444 f6cf2000 
Apr  6 10:19:45 localhost kernel:        00000246 f68dd070 c031ce5d f8af244c 00000000 00000001 f68dd070 c0114a70 
Apr  6 10:19:45 localhost kernel: Call Trace:
Apr  6 10:19:45 localhost kernel:  [__down_interruptible+157/300] __down_interruptible+0x9d/0x12c
Apr  6 10:19:45 localhost kernel:  [default_wake_function+0/32] default_wake_function+0x0/0x20
Apr  6 10:19:45 localhost kernel:  [__down_failed_interruptible+7/12] __down_failed_interruptible+0x7/0xc
Apr  6 10:19:45 localhost kernel:  [pg0+945105653/1067918336] .text.lock.ieee1394_core+0x1b/0x26 [ieee1394]
Apr  6 10:19:45 localhost kernel:  [pg0+945105424/1067918336] hpsbpkt_thread+0x0/0xb0 [ieee1394]
Apr  6 10:19:45 localhost kernel:  [kernel_thread_helper+5/24] kernel_thread_helper+0x5/0x18

Apr  6 10:19:45 localhost kernel: knodemgrd_0   S C04643E0     0  1973      1          2023  1956 (L-TLB)
Apr  6 10:19:45 localhost kernel: f7e75f7c 00000046 f7c0f030 c04643e0 0000a1ff 00000000 c018a7cc f648e62c 
Apr  6 10:19:45 localhost kernel:        f6ec8380 00000000 00000000 00000000 f7c0f030 f7c0f158 f6f6b670 f7e74000 
Apr  6 10:19:45 localhost kernel:        00000246 f7c0f030 c031ce5d f6f6b678 00000000 00000001 f7c0f030 c0114a70 
Apr  6 10:19:45 localhost kernel: Call Trace:
Apr  6 10:19:45 localhost kernel:  [sysfs_make_dirent+44/160] sysfs_make_dirent+0x2c/0xa0
Apr  6 10:19:45 localhost kernel:  [__down_interruptible+157/300] __down_interruptible+0x9d/0x12c
Apr  6 10:19:45 localhost kernel:  [default_wake_function+0/32] default_wake_function+0x0/0x20
Apr  6 10:19:45 localhost kernel:  [__down_failed_interruptible+7/12] __down_failed_interruptible+0x7/0xc
Apr  6 10:19:45 localhost kernel:  [pg0+945133083/1067918336] .text.lock.nodemgr+0x112/0x1a7 [ieee1394]
Apr  6 10:19:45 localhost kernel:  [pg0+945131536/1067918336] nodemgr_host_thread+0x0/0x190 [ieee1394]
Apr  6 10:19:45 localhost kernel:  [kernel_thread_helper+5/24] kernel_thread_helper+0x5/0x18


Apr  6 10:19:45 localhost kernel: grep          D C04643E0     0  2023      1          2036  1973 (NOTLB)
Apr  6 10:19:45 localhost kernel: f640beec 00000086 f6c6da50 c04643e0 00000000 f640bec4 f710ca50 f640bec4 
Apr  6 10:19:45 localhost kernel:        f640bec4 00000000 00000000 00000000 f6c6da50 f6c6db78 f7291424 f6c6da50 
Apr  6 10:19:45 localhost kernel:        00000282 f729142c c031cd4b 00000001 f6c6da50 c0114a70 f729142c f729142c 
Apr  6 10:19:45 localhost kernel: Call Trace:
Apr  6 10:19:45 localhost kernel:  [__down+123/240] __down+0x7b/0xf0
Apr  6 10:19:45 localhost kernel:  [default_wake_function+0/32] default_wake_function+0x0/0x20
Apr  6 10:19:45 localhost kernel:  [__down_failed+7/12] __down_failed+0x7/0xc
Apr  6 10:19:45 localhost kernel:  [.text.lock.usb+22/186] .text.lock.usb+0x16/0xba
Apr  6 10:19:45 localhost kernel:  [usb_device_read+186/288] usb_device_read+0xba/0x120
Apr  6 10:19:45 localhost kernel:  [usb_device_read+0/288] usb_device_read+0x0/0x120
Apr  6 10:19:45 localhost kernel:  [vfs_read+182/368] vfs_read+0xb6/0x170
Apr  6 10:19:45 localhost kernel:  [sys_read+81/128] sys_read+0x51/0x80
Apr  6 10:19:45 localhost kernel:  [syscall_call+7/11] syscall_call+0x7/0xb


I think those are the interesting processes, but I can get the full
list if it is useful.

I managed to proceed into the boot with alt-sysrq-E (tErm) but when it
came up enough bits had been killed that I decided to cut my losses
and go back to a previous working kernel...

This in on a Dell Lattitude D800

NeilBrown
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/