2.6.21-rc4-mm1

Temporarily at

http://userweb.kernel.org/~akpm/2.6.21-rc4-mm1/

Temporarily at

http://userweb.kernel.org/~akpm/2.6.21-rc4-mm1/

Will appear later at

ftp://ftp.kernel.org/pub/linux/kernel/people/akpm/patches/2.6/2.6.21-rc4/2.6.21-rc4-mm1/

- Restored the RSDL CPU scheduler (a new version thereof)

From elm3b239:

From elm3b245:

Quoted 10 lines · Andrew Morton

Temporarily at

http://userweb.kernel.org/~akpm/2.6.21-rc4-mm1/

Will appear later at

ftp://ftp.kernel.org/pub/linux/kernel/people/akpm/patches/2.6/2.6.21-rc4/2.6.21-rc4-mm1/

[All of the below is from the pre hot-fix runs. The very few results which are in for the hot-fix runs seem worse if anything. :( All results should be out on TKO.]

Quoted 1 line

- Restored the RSDL CPU scheduler (a new version thereof)

Unsure if the above is the culprit but there seems to be a smattering of BUG's in kernbench from the schedular on several systems, and panics which do not fully dump out.

elm3b239 is about 2/4 kernbench being the test in progress when we blammo in both failed tests, elm3b234 doesn't boot at all.

Quoted 20 lines · Andy Whitcroft

Quoted 10 lines · Andrew Morton

Temporarily at

http://userweb.kernel.org/~akpm/2.6.21-rc4-mm1/

Will appear later at

ftp://ftp.kernel.org/pub/linux/kernel/people/akpm/patches/2.6/2.6.21-rc4/2.6.21-rc4-mm1/

[All of the below is from the pre hot-fix runs. The very few results which are in for the hot-fix runs seem worse if anything. :( All results should be out on TKO.]

Quoted 1 line

- Restored the RSDL CPU scheduler (a new version thereof)

Unsure if the above is the culprit but there seems to be a smattering of BUG's in kernbench from the schedular on several systems, and panics which do not fully dump out.

Quoted 2 lines

elm3b239 is about 2/4 kernbench being the test in progress when we blammo in both failed tests, elm3b234 doesn't boot at all.

Well I have one result through for backing RSDL out on elm3b239 and that does indeed seem to give us a successful boot and test. peterz has pointed me to an incremental patch from Con which I'll push through testing and see if that sorts it out.

Quoted 22 lines · Andy Whitcroft

Quoted 21 lines · Andy Whitcroft

Quoted 9 lines · Andrew Morton

Temporarily at

http://userweb.kernel.org/~akpm/2.6.21-rc4-mm1/

Will appear later at

ftp://ftp.kernel.org/pub/linux/kernel/people/akpm/patches/2.6/2.6.21-rc 4/2.6.21-rc4-mm1/

[All of the below is from the pre hot-fix runs. The very few results which are in for the hot-fix runs seem worse if anything. :( All results should be out on TKO.]

Quoted 1 line

- Restored the RSDL CPU scheduler (a new version thereof)

Unsure if the above is the culprit but there seems to be a smattering of BUG's in kernbench from the schedular on several systems, and panics which do not fully dump out.

Quoted 7 lines

Quoted 2 lines

elm3b239 is about 2/4 kernbench being the test in progress when we blammo in both failed tests, elm3b234 doesn't boot at all.

Well I have one result through for backing RSDL out on elm3b239 and that does indeed seem to give us a successful boot and test. peterz has pointed me to an incremental patch from Con which I'll push through testing and see if that sorts it out.

Ok, tested the patch below on top of 2.6.21-rc4-mm1 and this seems to fix the problem:

http://ck.kolivas.org/patches/staircase-deadline/2.6.21-rc4-mm1-rsdl-0.32.p
atch

Hard to tell from that patch whether it will be fixed in the changes already committed to the next -mm.

Its possible that it may be fixed by the following patch:

sched-rsdl-improvements.patch

Which has the following slipped in at the end of the changelog:

A tiny change checking for MAX_PRIO in normal_prio() may prevent oopses on bootup on large SMP due to forking off the idle task.

Con, are all the changes in the 0.32 patch above with akpm?

Quoted 42 lines · Andy Whitcroft

Quoted 20 lines · Andy Whitcroft

Quoted 19 lines · Andy Whitcroft

Quoted 9 lines · Andrew Morton

Temporarily at

http://userweb.kernel.org/~akpm/2.6.21-rc4-mm1/

Will appear later at

ftp://ftp.kernel.org/pub/linux/kernel/people/akpm/patches/2.6/2.6.21-rc 4/2.6.21-rc4-mm1/

[All of the below is from the pre hot-fix runs. The very few results which are in for the hot-fix runs seem worse if anything. :( All results should be out on TKO.]

Quoted 1 line

- Restored the RSDL CPU scheduler (a new version thereof)

Unsure if the above is the culprit but there seems to be a smattering of BUG's in kernbench from the schedular on several systems, and panics which do not fully dump out.

Quoted 6 lines

Quoted 2 lines

elm3b239 is about 2/4 kernbench being the test in progress when we blammo in both failed tests, elm3b234 doesn't boot at all.

Well I have one result through for backing RSDL out on elm3b239 and that does indeed seem to give us a successful boot and test. peterz has pointed me to an incremental patch from Con which I'll push through testing and see if that sorts it out.

Ok, tested the patch below on top of 2.6.21-rc4-mm1 and this seems to fix the problem:

http://ck.kolivas.org/patches/staircase-deadline/2.6.21-rc4-mm1-rsdl-0.32.p
atch

Hard to tell from that patch whether it will be fixed in the changes already committed to the next -mm.

Its possible that it may be fixed by the following patch:

sched-rsdl-improvements.patch

Which has the following slipped in at the end of the changelog:

Quoted 5 lines

A tiny change checking for MAX_PRIO in normal_prio() may prevent oopses on bootup on large SMP due to forking off the idle task.

Con, are all the changes in the 0.32 patch above with akpm?

Yes he's queued everything in that patch you tested for the next -mm. Thanks very much for testing it.

Quoted 43 lines · Con Kolivas

Quoted 42 lines · Andy Whitcroft

Quoted 20 lines · Andy Whitcroft

Quoted 19 lines · Andy Whitcroft

Quoted 9 lines · Andrew Morton

Temporarily at

http://userweb.kernel.org/~akpm/2.6.21-rc4-mm1/

Will appear later at

ftp://ftp.kernel.org/pub/linux/kernel/people/akpm/patches/2.6/2.6.21-rc 4/2.6.21-rc4-mm1/

[All of the below is from the pre hot-fix runs. The very few results which are in for the hot-fix runs seem worse if anything. :( All results should be out on TKO.]

Quoted 1 line

- Restored the RSDL CPU scheduler (a new version thereof)

Unsure if the above is the culprit but there seems to be a smattering of BUG's in kernbench from the schedular on several systems, and panics which do not fully dump out.

Quoted 6 lines

Quoted 2 lines

elm3b239 is about 2/4 kernbench being the test in progress when we blammo in both failed tests, elm3b234 doesn't boot at all.

Well I have one result through for backing RSDL out on elm3b239 and that does indeed seem to give us a successful boot and test. peterz has pointed me to an incremental patch from Con which I'll push through testing and see if that sorts it out.

Ok, tested the patch below on top of 2.6.21-rc4-mm1 and this seems to fix the problem:

http://ck.kolivas.org/patches/staircase-deadline/2.6.21-rc4-mm1-rsdl-0.32.p
atch

Hard to tell from that patch whether it will be fixed in the changes already committed to the next -mm.

Its possible that it may be fixed by the following patch:

sched-rsdl-improvements.patch

Which has the following slipped in at the end of the changelog:

Quoted 7 lines

Quoted 5 lines

A tiny change checking for MAX_PRIO in normal_prio() may prevent oopses on bootup on large SMP due to forking off the idle task.

Con, are all the changes in the 0.32 patch above with akpm?

Yes he's queued everything in that patch you tested for the next -mm. Thanks very much for testing it.

No worries. I've just got through the results on the other machine in the mix. That machine seems to be fixed by backing out RSDL and not by the fixup 0.32 patch ...

This second machine seems to had hard very soon after user space starts executing but without a panic. I can't say that the symptoms are very definitive, but I do have a good result from that machine without RSDL and not with rsdl-0.32.

The machine is a dual-core x86_64 machine: Dual Core AMD Opteron(tm) Processor 275.

I'll let you know if I find out anything else. Shout if you want any information or have anything you want poked or tested.

Quoted 66 lines · Andy Whitcroft

Quoted 47 lines · Con Kolivas

Quoted 46 lines · Andy Whitcroft

Quoted 22 lines · Andy Whitcroft

Quoted 21 lines · Andy Whitcroft

Quoted 9 lines · Andrew Morton

Temporarily at

http://userweb.kernel.org/~akpm/2.6.21-rc4-mm1/

Will appear later at

ftp://ftp.kernel.org/pub/linux/kernel/people/akpm/patches/2.6/2.6.21 -rc 4/2.6.21-rc4-mm1/

[All of the below is from the pre hot-fix runs. The very few results which are in for the hot-fix runs seem worse if anything. :( All results should be out on TKO.]

Quoted 1 line

- Restored the RSDL CPU scheduler (a new version thereof)

Unsure if the above is the culprit but there seems to be a smattering of BUG's in kernbench from the schedular on several systems, and panics which do not fully dump out.

Quoted 7 lines

Quoted 2 lines

elm3b239 is about 2/4 kernbench being the test in progress when we blammo in both failed tests, elm3b234 doesn't boot at all.

Well I have one result through for backing RSDL out on elm3b239 and that does indeed seem to give us a successful boot and test. peterz has pointed me to an incremental patch from Con which I'll push through testing and see if that sorts it out.

Ok, tested the patch below on top of 2.6.21-rc4-mm1 and this seems to fix the problem:

http://ck.kolivas.org/patches/staircase-deadline/2.6.21-rc4-mm1-rsdl-0.
32.p atch

Hard to tell from that patch whether it will be fixed in the changes already committed to the next -mm.

Its possible that it may be fixed by the following patch:

sched-rsdl-improvements.patch

Which has the following slipped in at the end of the changelog:

Quoted 8 lines

Quoted 5 lines

A tiny change checking for MAX_PRIO in normal_prio() may prevent oopses on bootup on large SMP due to forking off the idle task.

Con, are all the changes in the 0.32 patch above with akpm?

Yes he's queued everything in that patch you tested for the next -mm. Thanks very much for testing it.

No worries. I've just got through the results on the other machine in the mix. That machine seems to be fixed by backing out RSDL and not by the fixup 0.32 patch ...

This second machine seems to had hard very soon after user space starts executing but without a panic. I can't say that the symptoms are very definitive, but I do have a good result from that machine without RSDL and not with rsdl-0.32.

Quoted 5 lines

The machine is a dual-core x86_64 machine: Dual Core AMD Opteron(tm) Processor 275.

I'll let you know if I find out anything else. Shout if you want any information or have anything you want poked or tested.

Ok, I have yet a third x86_64 machine is is blowing up with the latest 2.6.21-rc4-mm1+hotfixes+rsdl-0.32 but working with 2.6.21-rc4-mm1+hotfixes-RSDL. I have results on various hotfix levels so I have just fired off a set of tests across the affected machines on that latest hotfix stack plus the RSDL backout and the results should be in in the next hour or two.

I think there is a strong correlation between RSDL and these hangs. Any suggestions as to the next step.

Ok, I have yet a third x86_64 machine is is blowing up with the latest 2.6.21-rc4-mm1+hotfixes+rsdl-0.32 but working with 2.6.21-rc4-mm1+hotfixes-RSDL. I have results on various hotfix levels so I have just fired off a set of tests across the affected machines on that latest hotfix stack plus the RSDL backout and the results should be in in the next hour or two.

I think there is a strong correlation between RSDL and these hangs. Any suggestions as to the next step.

Quoted 9 lines · Andy Whitcroft

Ok, I have yet a third x86_64 machine is is blowing up with the latest 2.6.21-rc4-mm1+hotfixes+rsdl-0.32 but working with 2.6.21-rc4-mm1+hotfixes-RSDL. I have results on various hotfix levels so I have just fired off a set of tests across the affected machines on that latest hotfix stack plus the RSDL backout and the results should be in in the next hour or two.

I think there is a strong correlation between RSDL and these hangs. Any suggestions as to the next step.

Found a nasty in requeue_task

(quoted diff) +2 -0

+	if (list_empty(old_array->queue + old_prio))
+		__clear_bit(old_prio, p->array->prio_bitmap);

see anything wrong there? I do :P

I'll queue that up with the other changes pending and hopefully that will fix your bug.

Quoted 14 lines · Con Kolivas

Quoted 9 lines · Andy Whitcroft

Ok, I have yet a third x86_64 machine is is blowing up with the latest 2.6.21-rc4-mm1+hotfixes+rsdl-0.32 but working with 2.6.21-rc4-mm1+hotfixes-RSDL. I have results on various hotfix levels so I have just fired off a set of tests across the affected machines on that latest hotfix stack plus the RSDL backout and the results should be in in the next hour or two.

I think there is a strong correlation between RSDL and these hangs. Any suggestions as to the next step.

Found a nasty in requeue_task

(quoted diff) +2 -0

+	if (list_empty(old_array->queue + old_prio))
+		__clear_bit(old_prio, p->array->prio_bitmap);

Quoted 4 lines

see anything wrong there? I do :P

I'll queue that up with the other changes pending and hopefully that will fix your bug.

Tests queued with your rdsl-0.33 patch (I am assuming its in there). Will let you know how it looks.

Quoted 7 lines · Andy Whitcroft

Quoted 6 lines · Con Kolivas

Quoted 5 lines · Andy Whitcroft

Ok, I have yet a third x86_64 machine is is blowing up with the latest
2.6.21-rc4-mm1+hotfixes+rsdl-0.32 but working with 2.6.21-rc4-mm1+hotfixes-RSDL. I have results on various hotfix levels so I have just fired off a set of tests across the affected

Quoted 5 lines

Quoted 5 lines

Quoted 5 lines

machines on that latest hotfix stack plus the RSDL backout and the

results should be in in the next hour or two.

I think there is a strong correlation between RSDL and these

Quoted 8 lines

Quoted 8 lines

Quoted 1 line

Any suggestions as to the next step.

Found a nasty in requeue_task

(quoted diff) +2 -0

+	if (list_empty(old_array->queue + old_prio))
+		__clear_bit(old_prio, p->array->prio_bitmap);

see anything wrong there? I do :P

I'll queue that up with the other changes pending and hopefully

Quoted 4 lines

Quoted 1 line

will fix your bug.

Tests queued with your rdsl-0.33 patch (I am assuming its in there). Will let you know how it looks.

Hmmm, this is good for the original machine (as was 0.32) but not for either of the other two. I am seeing panics as below on those two.

-apw

Quoted 18 lines · Andy Whitcroft

Quoted 17 lines · Con Kolivas

Quoted 9 lines · Andy Whitcroft

Ok, I have yet a third x86_64 machine is is blowing up with the latest 2.6.21-rc4-mm1+hotfixes+rsdl-0.32 but working with 2.6.21-rc4-mm1+hotfixes-RSDL. I have results on various hotfix levels so I have just fired off a set of tests across the affected machines on that latest hotfix stack plus the RSDL backout and the results should be in in the next hour or two.

I think there is a strong correlation between RSDL and these hangs. Any suggestions as to the next step.

Found a nasty in requeue_task

(quoted diff) +2 -0

+	if (list_empty(old_array->queue + old_prio))
+		__clear_bit(old_prio, p->array->prio_bitmap);

see anything wrong there? I do :P

Quoted 5 lines

Quoted 2 lines

I'll queue that up with the other changes pending and hopefully that will fix your bug.

Tests queued with your rdsl-0.33 patch (I am assuming its in there). Will let you know how it looks.

Hmmm, this is good for the original machine (as was 0.32) but not for either of the other two. I am seeing panics as below on those two.

Quoted 19 lines · Andy Whitcroft

Quoted 18 lines · Andy Whitcroft

Quoted 17 lines · Con Kolivas

Quoted 9 lines · Andy Whitcroft

Ok, I have yet a third x86_64 machine is is blowing up with the latest 2.6.21-rc4-mm1+hotfixes+rsdl-0.32 but working with 2.6.21-rc4-mm1+hotfixes-RSDL. I have results on various hotfix levels so I have just fired off a set of tests across the affected machines on that latest hotfix stack plus the RSDL backout and the results should be in in the next hour or two.

I think there is a strong correlation between RSDL and these hangs. Any suggestions as to the next step.

Found a nasty in requeue_task

(quoted diff) +2 -0

+	if (list_empty(old_array->queue + old_prio))
+		__clear_bit(old_prio, p->array->prio_bitmap);

see anything wrong there? I do :P

Quoted 8 lines

Quoted 5 lines

Quoted 2 lines

I'll queue that up with the other changes pending and hopefully that will fix your bug.

Tests queued with your rdsl-0.33 patch (I am assuming its in there). Will let you know how it looks.

Hmmm, this is good for the original machine (as was 0.32) but not for either of the other two. I am seeing panics as below on those two.

This machine seems most sensitive to it (first column):
elm3b6
amd64
newisys
4cpu
config: amd64

Can you throw this debugging patch at it please? The console output might be very helpful. On top of sched-rsdl-0.33 thanks!

Quoted 32 lines · Con Kolivas

Quoted 16 lines · Andy Whitcroft

Quoted 15 lines · Andy Whitcroft

Quoted 14 lines · Con Kolivas

Quoted 9 lines · Andy Whitcroft

Ok, I have yet a third x86_64 machine is is blowing up with the latest 2.6.21-rc4-mm1+hotfixes+rsdl-0.32 but working with 2.6.21-rc4-mm1+hotfixes-RSDL. I have results on various hotfix levels so I have just fired off a set of tests across the affected machines on that latest hotfix stack plus the RSDL backout and the results should be in in the next hour or two.

I think there is a strong correlation between RSDL and these hangs. Any suggestions as to the next step.

Found a nasty in requeue_task

(quoted diff) +2 -0

+	if (list_empty(old_array->queue + old_prio))
+		__clear_bit(old_prio, p->array->prio_bitmap);

Quoted 8 lines

Quoted 6 lines

Quoted 4 lines

see anything wrong there? I do :P

I'll queue that up with the other changes pending and hopefully that will fix your bug.

Tests queued with your rdsl-0.33 patch (I am assuming its in there). Will let you know how it looks.

Hmmm, this is good for the original machine (as was 0.32) but not for either of the other two. I am seeing panics as below on those two.

This machine seems most sensitive to it (first column):
elm3b6
amd64
newisys
4cpu
config: amd64

Quoted 2 lines

Can you throw this debugging patch at it please? The console output might be very helpful. On top of sched-rsdl-0.33 thanks!

Better yet this one which checks the expired array as well and after pull_task.

If anyone's getting a bug they think might be due to rsdl please try this (on rsdl 0.33).

 kernel/sched.c |   51 +++++++++++++++++++++++++++++++++++++++++++++++++++
 1 file changed, 51 insertions(+)

Quoted 2 lines · Con Kolivas

 kernel/sched.c |   51 +++++++++++++++++++++++++++++++++++++++++++++++++++
 1 file changed, 51 insertions(+)

2.6.21-rc4-mm1 also fails for me.

I tried pure 2.6.21-rc4-mm1, +hotfixes, +hotfixes+rsdl33 and at last also added above debug patch.

The oops from with the debug-patch added:

[   65.426126] Freeing unused kernel memory: 312k freed
(on the console the system is starting up, getting until "Letting udev
process events ...")
[   66.665611] Unable to handle kernel NULL pointer dereference at
0000000000000020 RIP:
[   66.682030]  [<ffffffff8026167c>] __sched_text_start+0x4dc/0xa0e
[   66.707402] PGD 0
[   66.713473] Oops: 0000 [1] SMP
[   66.722968] last sysfs file:
devices/pci0000:00/0000:00:05.0/host2/target2:0:0/2:0:0:0/type
[   66.747954] CPU 0
[   66.754025] Modules linked in:
[   66.763209] Pid: 1200, comm: udevd Not tainted 2.6.21-rc4-mm1 #4
[   66.781162] RIP: 0010:[<ffffffff8026167c>]  [<ffffffff8026167c>]
__sched_text_start+0x4dc/0xa0e
[   66.807236] RSP: 0018:ffff81007d38fe78  EFLAGS: 00010082
[   66.823115] RAX: ffffffffffffffd0 RBX: 000000000000008c RCX: 000000000000058e
[   66.844439] RDX: 0000000000000000 RSI: 000000000000000c RDI: 0000000000000000
[   66.865767] RBP: ffff81007d38ff08 R08: 0000000000000064 R09: ffff810001014a58
[   66.887092] R10: 000000000000001c R11: 0000000000000246 R12: ffff810001013700
[   66.908418] R13: ffff810001014198 R14: 0000000000000001 R15: 0000000f859461fc
[   66.929745] FS:  00002b67df90e6d0(0000) GS:ffffffff807aa000(0000)
knlGS:0000000000000000
[   66.953950] CS:  0010 DS: 0000 ES: 0000 CR0: 000000008005003b
[   66.971126] CR2: 0000000000000020 CR3: 0000000000201000 CR4: 00000000000006e0
[   66.992451] Process udevd (pid: 1200, threadinfo ffff81007d38e000,
task ffff81007e354100)
[   67.016915] Stack:  00000000000004b0 0000000000000000
0000000000000000 ffff81007e354100
[   67.041097]  ffffffffffffffd0 ffff81007e354298 ffff81011d420680
ffffffff802234b1
[   67.063407]  0000000000000001 0000000000000000 0000000000000000
0000000000000246
[   67.085149] Call Trace:
[   67.093037]  [<ffffffff802234b1>] filp_close+0x71/0x90
[   67.108397]  [<ffffffff80214d97>] do_exit+0x7e7/0x800
[   67.123495]  [<ffffffff80248372>] do_group_exit+0x82/0x90

[   67.139634]  [<ffffffff8025c1de>] system_call+0x7e/0x83
[   67.155277]
[   67.159739]
[   67.159740] Code: 48 39 48 50 0f 84 8b 00 00 00 48 c7 40 40 00 00 00 00 8b 52
[   67.186877] RIP  [<ffffffff8026167c>] __sched_text_start+0x4dc/0xa0e
[   67.205919]  RSP <ffff81007d38fe78>
[   67.216348] CR2: 0000000000000020
[   67.226260] Fixing recursive fault but reboot is needed!

The system in x86_64, two 2218 on a MCP55 nvidia chipset.

2.6.21-rc3-mm1 works fine.

(gdb) list *0xffffffff8026167c 0xffffffff8026167c is in schedule (kernel/sched.c:3619).
3614 /*
3615 * When the task is chosen it is checked to see if its
quota has been

3616             * added to this runqueue level which is only performed once per
3617             * level per major rotation for each running task.
3618             */
3619            if (next->rotation != rq->prio_rotation) {
3620                            /* Task has moved during major rotation */
3621                            task_new_array(next, rq);
3622                            if (!entitled_slot(next->static_prio, idx))

3623 exchange_slot(next, rq);

Quoted 3 lines · Con Kolivas

 kernel/sched.c |   51

+++++++++++++++++++++++++++++++++++++++++++++++++++ 1 file changed, 51 insertions(+)

2.6.21-rc4-mm1 also fails for me.

I tried pure 2.6.21-rc4-mm1, +hotfixes, +hotfixes+rsdl33 and at last also added above debug patch.

The oops from with the debug-patch added:

[   65.426126] Freeing unused kernel memory: 312k freed
(on the console the system is starting up, getting until "Letting udev
process events ...")
[   66.665611] Unable to handle kernel NULL pointer dereference at
0000000000000020 RIP:
[   66.682030]  [<ffffffff8026167c>] __sched_text_start+0x4dc/0xa0e

The system in x86_64, two 2218 on a MCP55 nvidia chipset.

2.6.21-rc3-mm1 works fine.

(gdb) list *0xffffffff8026167c 0xffffffff8026167c is in schedule (kernel/sched.c:3619).

3614 /*
3615 * When the task is chosen it is checked to see if its
quota has been
3616 * added to this runqueue level which is only performed
once per 3617 * level per major rotation for each running task.
3618 */
3619 if (next->rotation != rq->prio_rotation) {

Torsten

Quoted 9 lines · Torsten Kaiser

Quoted 3 lines · Con Kolivas

 kernel/sched.c |   51

+++++++++++++++++++++++++++++++++++++++++++++++++++ 1 file changed, 51 insertions(+)

2.6.21-rc4-mm1 also fails for me.

I tried pure 2.6.21-rc4-mm1, +hotfixes, +hotfixes+rsdl33 and at last also added above debug patch.

Thank you very much for the effort!

Quoted 7 lines

The oops from with the debug-patch added:

[   65.426126] Freeing unused kernel memory: 312k freed
(on the console the system is starting up, getting until "Letting udev
process events ...")
[   66.665611] Unable to handle kernel NULL pointer dereference at
0000000000000020 RIP:
[   66.682030]  [<ffffffff8026167c>] __sched_text_start+0x4dc/0xa0e

The debug patch didn't do anything. This means it is not an unset bitmap problem at all otherwise it should have self corrected itself.

Quoted 6 lines

The system in x86_64, two 2218 on a MCP55 nvidia chipset.

2.6.21-rc3-mm1 works fine.

(gdb) list *0xffffffff8026167c 0xffffffff8026167c is in schedule (kernel/sched.c:3619).

	next = list_entry(queue->next, struct task_struct, run_list);
	rq->prio_level = idx;

Quoted 7 lines

3614 /*
3615 * When the task is chosen it is checked to see if its
quota has been
3616 * added to this runqueue level which is only performed
once per 3617 * level per major rotation for each running
task. 3618 */
3619 if (next->rotation != rq->prio_rotation) {

Urgh. Dereferencing there? That can only be next that's deferencing meaning the run_list entry is bogus. That should only ever be done under runqueue lock so I have a race somewhere where it's not. Time for more looking.

This is about the only place I can see the run_list is looked at unlocked. Can you see if this simple patch helps? The debug patch is unnecessary now.

Quoted 2 lines · Con Kolivas

This is about the only place I can see the run_list is looked at unlocked. Can you see if this simple patch helps? The debug patch is unnecessary now.

Tests queued with this patch. Will let you know.

Andy Whitcroft wrote:
Subsequent to that Con suggested testing a refactored RSDL patch. That patch seemed to work on the machine at hand, so tests have been submitted for all the affected machines.

http://ck.kolivas.org/patches/staircase-deadline/2.6.21-rc4-mm1-rsdl-0.34-t
est.patch

...

Ok, the preliminary results are in and we seem to have good boots in the three machines I was hitting early boot oops. So I think we can say that the new stack is a lot better than the old.

Con, have a Tested-by:
:/

-apw

Temporarily at

http://userweb.kernel.org/~akpm/2.6.21-rc4-mm1/

http://userweb.kernel.org/~akpm/2.6.21-rc4-mm1/

Andrew Morton napsal(a):

Quoted 1 line

http://userweb.kernel.org/~akpm/2.6.21-rc4-mm1/

I'm getting this while trying to swsusp:
Stopping tasks ...
Stopping kernel threads timed out after 20 seconds (1 tasks refusing to freeze):
swapper
Restarting tasks ... done.

What to test? Enable PM_DEBUG?

Quoted 10 lines

Andrew Morton napsal(a):

Quoted 1 line

http://userweb.kernel.org/~akpm/2.6.21-rc4-mm1/

I'm getting this while trying to swsusp:
Stopping tasks ...
Stopping kernel threads timed out after 20 seconds (1 tasks refusing to freeze):
swapper
Restarting tasks ... done.

What to test? Enable PM_DEBUG?

hm, OK. Rafael has been working on fixing the process freezer and it'll take some time to get it to where we want it to be, I expect.

Rafael, I think that we could afford to add heaps of debug in there at this stage to help us track down problems like this.

Also, it might be useful to add a temporary /proc/freeze-unfreeze thing which will simply do a freeze/unfreeze cycle. Then we can apply various workloads to the machine while madly stressing the freezer code.

Hi!

Quoted 8 lines

Quoted 8 lines

Andrew Morton napsal(a):

Quoted 1 line

http://userweb.kernel.org/~akpm/2.6.21-rc4-mm1/

I'm getting this while trying to swsusp:
Stopping tasks ...
Stopping kernel threads timed out after 20 seconds (1 tasks refusing to freeze):
swapper
Restarting tasks ... done.

Quoted 1 line

Quoted 1 line

What to test? Enable PM_DEBUG?

Is it repeatable? Freezer normally works better than that.

Quoted 3 lines

Also, it might be useful to add a temporary /proc/freeze-unfreeze thing which will simply do a freeze/unfreeze cycle. Then we can apply various workloads to the machine while madly stressing the freezer code.

echo testproc > /sys/power/disk; echo disk > /sys/power/state ... is pretty much what you want.

Quoted 6 lines

Quoted 3 lines

Also, it might be useful to add a temporary /proc/freeze-unfreeze thing which will simply do a freeze/unfreeze cycle. Then we can apply various workloads to the machine while madly stressing the freezer code.

echo testproc > /sys/power/disk; echo disk > /sys/power/state ... is pretty much what you want.

Ok, I'll try this.

Hi!

Quoted 3 lines

Quoted 3 lines

Quoted 3 lines

Also, it might be useful to add a temporary /proc/freeze-unfreeze thing which will simply do a freeze/unfreeze cycle. Then we can apply various workloads to the machine while madly stressing the freezer code.

Quoted 3 lines

Quoted 2 lines

echo testproc > /sys/power/disk; echo disk > /sys/power/state ... is pretty much what you want.

Ok, I'll try this.

It will not help you -- probably -- it is equivalent to just running s2ram. But it should make "successful" testing easier, because you no longer need machine with working suspend to test refrigerator.

Quoted 7 lines

Quoted 6 lines

Quoted 5 lines

Quoted 3 lines

Also, it might be useful to add a temporary /proc/freeze-unfreeze thing which will simply do a freeze/unfreeze cycle. Then we can apply various workloads to the machine while madly stressing the freezer code.

echo testproc > /sys/power/disk; echo disk > /sys/power/state ... is pretty much what you want.

Ok, I'll try this.

Quoted 3 lines

It will not help you -- probably -- it is equivalent to just running s2ram. But it should make "successful" testing easier, because you no longer need machine with working suspend to test refrigerator.

Aha, I didn't read it carefully. Suspend is working, but not in this kernel. I haven't tried s2ram in this version. Should I (I'm away from it) -- would it show something?

Hi!

Quoted 11 lines

Quoted 10 lines

Quoted 6 lines

Quoted 5 lines

Quoted 3 lines

Also, it might be useful to add a temporary /proc/freeze-unfreeze thing which will simply do a freeze/unfreeze cycle. Then we can apply various workloads to the machine while madly stressing the freezer code.

echo testproc > /sys/power/disk; echo disk > /sys/power/state ... is pretty much what you want.

Ok, I'll try this.

It will not help you -- probably -- it is equivalent to just running s2ram. But it should make "successful" testing easier, because you no longer need machine with working suspend to test refrigerator.

Quoted 3 lines

Aha, I didn't read it carefully. Suspend is working, but not in this kernel. I haven't tried s2ram in this version. Should I (I'm away from it) -- would it show something?

No, probably not. git bisect would help, but I guess it is easier to let Rafael sort it out.

Actually, the problem is 100% reproducible on my system too and I doubt it's caused by the recent freezer patches.

Rafael J. Wysocki napsal(a):

Quoted 2 lines

Actually, the problem is 100% reproducible on my system too and I doubt it's caused by the recent freezer patches.

I don't know what exactly do you mean by recent, but 2.6.21-rc3-mm2 works for me.

Quoted 4 lines · Jiri Slaby

Rafael J. Wysocki napsal(a):

Quoted 2 lines

Actually, the problem is 100% reproducible on my system too and I doubt it's caused by the recent freezer patches.

Quoted 2 lines

I don't know what exactly do you mean by recent, but 2.6.21-rc3-mm2 works for me.

Thanks for the confirmation.

The patches I was talking about had already been in 2.6.21-rc3-mm2, so the reason of this failure must be different.

Quoted 3 lines · Rafael J. Wysocki

Quoted 2 lines · Jiri Slaby

Rafael J. Wysocki napsal(a):

Quoted 1 line

Actually, the problem is 100% reproducible on my system too and I doubt

it's

Quoted 7 lines

Quoted 4 lines

Quoted 1 line

caused by the recent freezer patches.

I don't know what exactly do you mean by recent, but 2.6.21-rc3-mm2 works for me.

Thanks for the confirmation.

Quoted 2 lines

The patches I was talking about had already been in 2.6.21-rc3-mm2, so the reason of this failure must be different.

Bisection shows that the freezing of processes has been broken by one of the patches:

remove-the-likelypid-check-in-copy_process.patch

use-task_pgrp-task_session-in-copy_process.patch

Quoted 12 lines · Rafael J. Wysocki

Quoted 3 lines · Rafael J. Wysocki

Quoted 2 lines · Jiri Slaby

Rafael J. Wysocki napsal(a):

Quoted 1 line

Actually, the problem is 100% reproducible on my system too and I doubt

it's

Quoted 7 lines

Quoted 4 lines

Quoted 1 line

caused by the recent freezer patches.

I don't know what exactly do you mean by recent, but 2.6.21-rc3-mm2 works for me.

Thanks for the confirmation.

Quoted 7 lines

Quoted 2 lines

The patches I was talking about had already been in 2.6.21-rc3-mm2, so the reason of this failure must be different.

Bisection shows that the freezing of processes has been broken by one of the patches:

remove-the-likelypid-check-in-copy_process.patch

Grr. Oleg's review of remove-the-likelypid-check-in-copy-process showed it to be questionable (and it was just an optimization) so we can get rid of that one easily.

Although all it did that was really questionable was add the idle process to the global process list and bump a process count when we forked the idle process. Not dramatically dangerous things.

Quoted 1 line

use-task_pgrp-task_session-in-copy_process.patch

As I recall that patch was pretty trivial, and shouldn't have
anything to do with the freezer. The process freezer doesn't care
about pids does it?

Quoted 11 lines · Eric W. Biederman

Quoted 6 lines

Quoted 1 line

Quoted 1 line

Rafael J. Wysocki napsal(a):

Bisection shows that the freezing of processes has been broken by one of the patches:

remove-the-likelypid-check-in-copy_process.patch

Grr. Oleg's review of remove-the-likelypid-check-in-copy-process showed it to be questionable (and it was just an optimization) so we can get rid of that one easily.

Quoted 4 lines

Although all it did that was really questionable was add the idle process to the global process list and bump a process count when we forked the idle process. Not dramatically dangerous things.

Could the freezer code be trying to freeze the idle thread as a result?

Quoted 18 lines · Nigel Cunningham

Quoted 15 lines · Eric W. Biederman

Quoted 6 lines

Quoted 1 line

Quoted 1 line

Rafael J. Wysocki napsal(a):

Bisection shows that the freezing of processes has been broken by one of the patches:

remove-the-likelypid-check-in-copy_process.patch

Grr. Oleg's review of remove-the-likelypid-check-in-copy-process showed it to be questionable (and it was just an optimization) so we can get rid of that one easily.

Although all it did that was really questionable was add the idle process to the global process list and bump a process count when we forked the idle process. Not dramatically dangerous things.

Quoted 1 line

Could the freezer code be trying to freeze the idle thread as a result?

Yes. remove-the-likelypid-check-in-copy_process.patch make idle threads visible to for_each_process/do_each_thread. Note also that idle threads have ->mm != NULL. freezer, oom_kill, move_task_off_dead_cpu, etc, should not see idle threads, but they do now.

Quoted 21 lines · Oleg Nesterov

Quoted 19 lines · Nigel Cunningham

Quoted 7 lines · Eric W. Biederman

Quoted 6 lines

Quoted 1 line

Quoted 1 line

Rafael J. Wysocki napsal(a):

Bisection shows that the freezing of processes has been broken by one of the patches:

remove-the-likelypid-check-in-copy_process.patch

Quoted 8 lines

Grr. Oleg's review of remove-the-likelypid-check-in-copy-process showed it to be questionable (and it was just an optimization) so we can get rid of that one easily.

Although all it did that was really questionable was add the idle process to the global process list and bump a process count when we forked the idle process. Not dramatically dangerous things.

Could the freezer code be trying to freeze the idle thread as a result?

Quoted 4 lines

Yes. remove-the-likelypid-check-in-copy_process.patch make idle threads visible to for_each_process/do_each_thread. Note also that idle threads have ->mm != NULL. freezer, oom_kill, move_task_off_dead_cpu, etc, should not see idle threads, but they do now.

Well, I think this is a good enough reason for asking Andrew to drop this patch.

Quoted 9 lines · On Wed, 21 Mar 2007 15:45:16 +0100 "Rafael J. Wysocki" <[email protected]> wrote:

Quoted 7 lines · Oleg Nesterov

Quoted 2 lines

Could the freezer code be trying to freeze the idle thread as a result?

Yes. remove-the-likelypid-check-in-copy_process.patch make idle threads visible to for_each_process/do_each_thread. Note also that idle threads have ->mm != NULL. freezer, oom_kill, move_task_off_dead_cpu, etc, should not see idle threads, but they do now.

Quoted 2 lines

Well, I think this is a good enough reason for asking Andrew to drop this patch.

Or we change the freezer to skip pid==0 tasks.

Quoted 12 lines · Andrew Morton

Quoted 9 lines · On Wed, 21 Mar 2007 15:45:16 +0100 "Rafael J. Wysocki" <[email protected]> wrote:

Quoted 7 lines · Oleg Nesterov

Quoted 2 lines

Could the freezer code be trying to freeze the idle thread as a result?

Yes. remove-the-likelypid-check-in-copy_process.patch make idle threads visible to for_each_process/do_each_thread. Note also that idle threads have ->mm != NULL. freezer, oom_kill, move_task_off_dead_cpu, etc, should not see idle threads, but they do now.

Quoted 4 lines

Quoted 2 lines

Well, I think this is a good enough reason for asking Andrew to drop this patch.

Or we change the freezer to skip pid==0 tasks.

I strongly disagree. In that case we should audit all users of for_each_process. Imho, this change is too dangerous. Actually, I personally think it is very good that idle threads are special and not visible, imho we should not change this.

Btw. Rafael, Andrew, what about

	[PATCH] Make XFS workqueues nonfreezable
	http://marc.info/?l=linux-kernel&m=117270675922229

, don't you think this should go to 2.6.21 ?

Quoted 12 lines · Andrew Morton

Quoted 9 lines · On Wed, 21 Mar 2007 15:45:16 +0100 "Rafael J. Wysocki" <[email protected]> wrote:

Quoted 7 lines · Oleg Nesterov

Quoted 2 lines

Could the freezer code be trying to freeze the idle thread as a result?

Yes. remove-the-likelypid-check-in-copy_process.patch make idle threads visible to for_each_process/do_each_thread. Note also that idle threads have ->mm != NULL. freezer, oom_kill, move_task_off_dead_cpu, etc, should not see idle threads, but they do now.

Quoted 4 lines

Quoted 2 lines

Well, I think this is a good enough reason for asking Andrew to drop this patch.

Or we change the freezer to skip pid==0 tasks.

I strongly disagree. In that case we should audit all users of for_each_process.

Quoted 12 lines · Rafael J. Wysocki

Quoted 3 lines · Rafael J. Wysocki

Quoted 2 lines · Jiri Slaby

Rafael J. Wysocki napsal(a):

Quoted 1 line

Actually, the problem is 100% reproducible on my system too and I doubt

it's

Quoted 7 lines

Quoted 4 lines

Quoted 1 line

caused by the recent freezer patches.

I don't know what exactly do you mean by recent, but 2.6.21-rc3-mm2 works for me.

Thanks for the confirmation.

Quoted 7 lines

Quoted 2 lines

The patches I was talking about had already been in 2.6.21-rc3-mm2, so the reason of this failure must be different.

Bisection shows that the freezing of processes has been broken by one of the patches:

remove-the-likelypid-check-in-copy_process.patch

Grr. Oleg's review of remove-the-likelypid-check-in-copy-process showed it to be questionable (and it was just an optimization) so we can get rid of that one easily.

Although all it did that was really questionable was add the idle process to the global process list and bump a process count when we forked the idle process. Not dramatically dangerous things.

Quoted 1 line

use-task_pgrp-task_session-in-copy_process.patch

As I recall that patch was pretty trivial, and shouldn't have
anything to do with the freezer. The process freezer doesn't care
about pids does it?

Pavel Machek napsal(a):

Quoted 10 lines

Hi!

Quoted 8 lines

Quoted 8 lines

Andrew Morton napsal(a):

Quoted 1 line

http://userweb.kernel.org/~akpm/2.6.21-rc4-mm1/

I'm getting this while trying to swsusp:
Stopping tasks ...
Stopping kernel threads timed out after 20 seconds (1 tasks refusing to freeze):
swapper
Restarting tasks ... done.

Quoted 3 lines

Quoted 1 line

Quoted 1 line

What to test? Enable PM_DEBUG?

Is it repeatable? Freezer normally works better than that.

Yes, at least it happened 3 times consecutively, when I tried to asleep the machine, then I turned it off.

Quoted 6 lines

Quoted 3 lines

Also, it might be useful to add a temporary /proc/freeze-unfreeze thing which will simply do a freeze/unfreeze cycle. Then we can apply various workloads to the machine while madly stressing the freezer code.

echo testproc > /sys/power/disk; echo disk > /sys/power/state ... is pretty much what you want.

Ok, I'll try this.

Temporarily at

http://userweb.kernel.org/~akpm/2.6.21-rc4-mm1/

Will appear later at

ftp://ftp.kernel.org/pub/linux/kernel/people/akpm/patches/2.6/2.6.21-rc4/2.6.21-rc4-mm1/

Quoted 9 lines · Andrew Morton

Temporarily at

http://userweb.kernel.org/~akpm/2.6.21-rc4-mm1/

Will appear later at

ftp://ftp.kernel.org/pub/linux/kernel/people/akpm/patches/2.6/2.6.21-rc4/2.6.21-rc4-mm1/

(oops, I forgot LKML)

I have no udev events for my dvd-rw...
When I insert a disc in the dvd reader:

werewolf:~# udevmonitor
udevmonitor prints the received event from the kernel [UEVENT]
and the event which udev sends out after rule processing [UDEV]

UEVENT[1174385162.607021] mount /block/sr1 (block)
UDEV [1174385162.610056] mount /block/sr1 (block)

If I insert it in the dvd-rw drive, nothing happens.

Temporarily at

http://userweb.kernel.org/~akpm/2.6.21-rc4-mm1/

Will appear later at

ftp://ftp.kernel.org/pub/linux/kernel/people/akpm/patches/2.6/2.6.21-rc4/2.6.21-rc4-mm1/
Changes since 2.6.21-rc3-mm1:

LD .tmp_vmlinux1
kernel/built-in.o:(.data+0xfc0): undefined reference to `maps_protect'
make: *** [.tmp_vmlinux1] Error 1

with CONFIG_PROC_FS=n

Gah! Apologies. This should fix it, but I can't test it since I can't get 2.6.21-rc4-mm1 to compile (with or without this fix):

GEN .version
init/.missing_syscalls.h.cmd:2: *** missing separator. Stop.
make: *** [.tmp_vmlinux1] Error 2

Quoted 5 lines · Randy Dunlap

LD .tmp_vmlinux1
kernel/built-in.o:(.data+0xfc0): undefined reference to `maps_protect'
make: *** [.tmp_vmlinux1] Error 1

with CONFIG_PROC_FS=n

Gah! Apologies. This should fix it, but I can't test it since I can't get 2.6.21-rc4-mm1 to compile (with or without this fix):

GEN .version
init/.missing_syscalls.h.cmd:2: *** missing separator. Stop.
make: *** [.tmp_vmlinux1] Error 2

Signed-off-by Kees Cook <[email protected]>

---
diff -uNrp linux-2.6.21-rc4-mm1/kernel/sysctl.c linux-2.6.21-rc4-mm1-kees/kernel/sysctl.c

kernel/sysctl.c +5 -1

@@ -77,9 +77,12 @@ extern int pid_max_min, pid_max_max;
 extern int sysctl_drop_caches;
 extern int percpu_pagelist_fraction;
 extern int compat_log;
-extern int maps_protect;
 extern int print_fatal_signals;
 
+#ifdef CONFIG_PROC_FS
+extern int maps_protect;
+#endif
+
 #if defined(CONFIG_ADAPTIVE_READAHEAD)
 extern int readahead_ratio;
 extern int readahead_hit_rate;

@@ -619,6 +622,7 @@ static ctl_table kern_table[] = {
 		.proc_handler	= &proc_dointvec,
 	},
 #endif
+#ifdef CONFIG_PROC_FS
 	{
 		.ctl_name       = CTL_UNNUMBERED,
 		.procname       = "maps_protect",

I can't
get 2.6.21-rc4-mm1 to compile (with or without this fix):

GEN .version
init/.missing_syscalls.h.cmd:2: *** missing separator. Stop.
make: *** [.tmp_vmlinux1] Error 2

Quoted 6 lines · On Tue, 20 Mar 2007 12:20:16 -0700 Kees Cook <[email protected]> wrote:

I can't
get 2.6.21-rc4-mm1 to compile (with or without this fix):

GEN .version
init/.missing_syscalls.h.cmd:2: *** missing separator. Stop.
make: *** [.tmp_vmlinux1] Error 2

Quoted 3 lines · On Tue, 20 Mar 2007 12:20:16 -0700 Kees Cook <[email protected]> wrote:

I can't
get 2.6.21-rc4-mm1 to compile (with or without this fix):

Quoted 3 lines

GEN .version
init/.missing_syscalls.h.cmd:2: *** missing separator. Stop.
make: *** [.tmp_vmlinux1] Error 2

How'd you manage that?

Sam, I think this is a you-thing rather than a dwmw2-thing?

I will give it a shot tonight.

One issue I have with current approach is that the ARCH specific things are in a single .h file.

Quoted 1 line · Sam Ravnborg

I will give it a shot tonight.

Thanks. I'll delete the syscalls-2.6.git tree now that you have it.

Quoted 2 lines

One issue I have with current approach is that the ARCH specific things are in a single .h file.

Que? There aren't really any arch-specific things, except for a list of syscalls to be ignored which are i386-specific. That's because we're pulling in the 'master' system call list from asm-i386/unistd.h, and we need to exclude some of those which we don't really need on other architectures.

Yep - realized this when I took a closer look.
One thing striked my mind. It is correct that new things gets added to i386 first these days?

To me it looks like x86_64 is growing larger than i386 among the developers these days so using asm-x86_64/unistd.h could be a better choice?

Quoted 3 lines · Sam Ravnborg

Yep - realized this when I took a closer look.
One thing striked my mind. It is correct that new things gets added to i386 first these days?

Personally I tend to do PowerPC first, but most others seem to do i386, yes. There are still system calls being added to i386 and not x86_64...

init/missing_syscalls.h:947:3: warning: #warning syscall getcpu not implemented init/missing_syscalls.h:950:3: warning: #warning syscall epoll_pwait not implemented init/missing_syscalls.h:953:3: warning: #warning syscall lutimesat not implemented init/missing_syscalls.h:956:3: warning: #warning syscall revokeat not implemented init/missing_syscalls.h:959:3: warning: #warning syscall frevoke not implemented

Quoted 3 lines

To me it looks like x86_64 is growing larger than i386 among the developers these days so using asm-x86_64/unistd.h could be a better choice?

Or perhaps the union of i386, x86_64 and powerpc. But I think i386 is good enough for now.

Quoted 3 lines · On Tue, 20 Mar 2007 12:20:16 -0700 Kees Cook <[email protected]> wrote:

I can't
get 2.6.21-rc4-mm1 to compile (with or without this fix):

Quoted 3 lines

GEN .version
init/.missing_syscalls.h.cmd:2: *** missing separator. Stop.
make: *** [.tmp_vmlinux1] Error 2

How'd you manage that?

Sam, I think this is a you-thing rather than a dwmw2-thing?

From 5fbf06eb42fdaf81529d2433fe0953297cbc7cc6 Mon Sep 17 00:00:00 2001

Most system calls seem to get added to i386 first. This patch automatically generates a warning for any new system call which is implemented on i386 but not the architecture currently being compiled.

Quoted 3 lines · Sam Ravnborg

Most system calls seem to get added to i386 first. This patch automatically generates a warning for any new system call which is implemented on i386 but not the architecture currently being compiled.

This is now upstream, and so I see a bunch of warnings for every ia64 build. Some of them are real, I need to add some syscalls, but there are a few bogus ones because ia64 chose different names (e.g. we have a sys_clone() that glibc uses to implement fork() and vfork()).

Just checking that the right way for me to shut checksyscalls.sh up is to add:

#define __IGNORE_fork
#define __IGNORE_vfork

etc. to include/asm-ia64/unistd.h for each of the bogus ones. Or is there some other preferred mechanism?

You could add them to scripts/checksyscalls.sh itself -- I think it's fairly unlikely that those are syscalls which a new arch port is going to 'forget' :)

Quoted 3 lines

You could add them to scripts/checksyscalls.sh itself -- I think it's fairly unlikely that those are syscalls which a new arch port is going to 'forget' :)

Like this?

scripts/checksyscalls.sh +1 -0

index f98171f..4d49056 100755
@@ -98,6 +98,14 @@ cat << EOF
 #define __IGNORE_setgid32
 #define __IGNORE_setfsuid32
 #define __IGNORE_setfsgid32
+/* ... some legacy names not used by ia64 */

Looks more complex than necessary. Why do you want to execute an arch specific script to list the __IGNORE symbols? That would allow an arch to generate a list with sed/perl/etc. but that looks like overkill.

If you just have an arch specific file with the right defines. E.g. for x86_64 in include/asm-x86_64/ignore_syscalls:

#include __IGNORE_getcpu

Then the checksyscalls.sh changes would just be something like (do I need a ${srctree} before the include??):

From 9ca09c1ca8e5f65ea9f7f0bb3de71cc70a0f6511 Mon Sep 17 00:00:00 2001

From 984d35ec37866c9b10c2193fcd1b1b5c6ee4c6cb Mon Sep 17 00:00:00 2001

Quoted 11 lines · Andrew Morton

Quoted 6 lines · On Tue, 20 Mar 2007 12:20:16 -0700 Kees Cook <[email protected]> wrote:

I can't
get 2.6.21-rc4-mm1 to compile (with or without this fix):

GEN .version
init/.missing_syscalls.h.cmd:2: *** missing separator. Stop.
make: *** [.tmp_vmlinux1] Error 2

How'd you manage that?

Quoted 1 line

Sam, I think this is a you-thing rather than a dwmw2-thing?

Took a look. Things looked pretty OK but an updated patch applied to kbuild.git.
Corrected a few things in the Makefile and combined the patch from dwmw2 and Stephane.

kbuild.git pused out and patches follows.

Quoted 12 lines · On Wed, 21 Mar 2007 23:19:05 +0100 Sam Ravnborg <[email protected]> wrote:

Quoted 11 lines · Andrew Morton

Quoted 6 lines · On Tue, 20 Mar 2007 12:20:16 -0700 Kees Cook <[email protected]> wrote:

I can't
get 2.6.21-rc4-mm1 to compile (with or without this fix):

GEN .version
init/.missing_syscalls.h.cmd:2: *** missing separator. Stop.
make: *** [.tmp_vmlinux1] Error 2

How'd you manage that?

Quoted 8 lines

Quoted 1 line

Sam, I think this is a you-thing rather than a dwmw2-thing?

Took a look. Things looked pretty OK but an updated patch applied to kbuild.git.
Corrected a few things in the Makefile and combined the patch from dwmw2 and Stephane.

kbuild.git pused out and patches follows.

David has set up a git tree with this stuff, so you presumably have an out-of-date copy.

git://git.infradead.org/~dwmw2/syscalls-2.6.git

I don't know what's changed in there. One never does, with git trees :(

Temporarily at

http://userweb.kernel.org/~akpm/2.6.21-rc4-mm1/

Will appear later at

ftp://ftp.kernel.org/pub/linux/kernel/people/akpm/patches/2.6/2.6.21-rc4/2.6.21-rc4-mm1/

Avoid multiple/repeated warnings:
include/linux/utrace.h:594: warning: return type defaults to 'int'

...
Changes since 2.6.21-rc3-mm1:
...
+gregkh-pci-pciehp-event-handling-rework.patch
...
PCI tree updates
...

Temporarily at

http://userweb.kernel.org/~akpm/2.6.21-rc4-mm1/

Will appear later at

ftp://ftp.kernel.org/pub/linux/kernel/people/akpm/patches/2.6/2.6.21-rc4/2.6.21-rc4-mm1/

git-ieee1394.patch

Temporarily at

http://userweb.kernel.org/~akpm/2.6.21-rc4-mm1/

Will appear later at

ftp://ftp.kernel.org/pub/linux/kernel/people/akpm/patches/2.6/2.6.21-rc4/2.6.21-rc4-mm1/

Temporarily at

http://userweb.kernel.org/~akpm/2.6.21-rc4-mm1/

Will appear later at

ftp://ftp.kernel.org/pub/linux/kernel/people/akpm/patches/2.6/2.6.21-rc4/2.6.21-rc4-mm1/

Quoted 8 lines · On Mon, 19 Mar 2007 20:56:23 -0800 Andrew Morton wrote:

Temporarily at

http://userweb.kernel.org/~akpm/2.6.21-rc4-mm1/

Will appear later at

ftp://ftp.kernel.org/pub/linux/kernel/people/akpm/patches/2.6/2.6.21-rc4/2.6.21-rc4-mm1/

UIO_CIF should depend on PCI ??

With CONFIG_PCI=n, I get:

ERROR: "pci_module_init" [drivers/uio/uio_cif.ko] undefined!
ERROR: "pci_release_regions" [drivers/uio/uio_cif.ko] undefined! make[1]: *** [__modpost] Error 1
make: *** [modules] Error 2

Quoted 4 lines · Andrew Morton

Temporarily at

http://userweb.kernel.org/~akpm/2.6.21-rc4-mm1/

Quoted 3 lines

Will appear later at

ftp://ftp.kernel.org/pub/linux/kernel/people/akpm/patches/2.6/2.6.21-rc4/2.6.21-rc4-mm1/

First impressions:
Several of the same bugs as rc3-mm*:
* Freezes immediately if I touch the wlan0 device after loading the new Broadcom wireless driver.

* Freezes immediately if I allow Bluetooth to configure.

* All freezes simply stop, no BUG or panic happens, no watchdog, soft or NMI ever triggers. Thinking about it, I wonder if disabling EDAC_K8 would help here? Does it steal NMI? I'll try that later.

* I am using Reiser4 and after one of the above freezes and hard power cycle, files that were in use *read*only* are filled with zeros. For example, while testing and experiencing the above freezes, I lost /etc/ld.so.preload
and /lib/security/pam_limits.so. What the heck?

Good points:
* Runs longer than 5 minutes, since I am typing this while using it.
* I like RDSL so far.

Advice on who to annoy with further bug reports is welcome. Bluetooth people? USB people? Broadcom driver people, probably.

The system is a Athlon64 laptop, nForce3 motherboard.
Current lspci, dmesg (cannot get the frozen dmesgs, sorry) and .config
follow:
00:00.0 Host bridge: nVidia Corporation nForce3 Host Bridge (rev a4)
00:01.0 ISA bridge: nVidia Corporation nForce3 LPC Bridge (rev a6)
00:01.1 SMBus: nVidia Corporation nForce3 SMBus (rev a4)
00:02.0 USB Controller: nVidia Corporation nForce3 USB 1.1 (rev a5)
00:02.1 USB Controller: nVidia Corporation nForce3 USB 1.1 (rev a5)
00:02.2 USB Controller: nVidia Corporation nForce3 USB 2.0 (rev a2)
00:06.0 Multimedia audio controller: nVidia Corporation nForce3 Audio (rev a2)
00:06.1 Modem: nVidia Corporation nForce3 Audio (rev a2)
00:08.0 IDE interface: nVidia Corporation nForce3 IDE (rev a5)
00:0a.0 PCI bridge: nVidia Corporation nForce3 PCI Bridge (rev a2)
00:0b.0 PCI bridge: nVidia Corporation nForce3 AGP Bridge (rev a4)
00:18.0 Host bridge: Advanced Micro Devices [AMD] K8 [Athlon64/Opteron] HyperTransport Technology Configuration 00:18.1 Host bridge: Advanced Micro Devices [AMD] K8 [Athlon64/Opteron] Address Map
00:18.2 Host bridge: Advanced Micro Devices [AMD] K8 [Athlon64/Opteron] DRAM Controller 00:18.3 Host bridge: Advanced Micro Devices [AMD] K8 [Athlon64/Opteron] Miscellaneous Control 01:00.0 VGA compatible controller: nVidia Corporation NV17 [GeForce4 420 Go 32M] (rev a3) 02:00.0 FireWire (IEEE 1394): Texas Instruments TSB43AB21 IEEE-1394a-2000 Controller (PHY/Link) 02:01.0 Ethernet controller: Realtek Semiconductor Co., Ltd. RTL-8139/8139C/8139C+ (rev 10) 02:02.0 Network controller: Broadcom Corporation BCM4303 802.11b Wireless LAN Controller (rev 02) 02:04.0 CardBus bridge: Texas Instruments PCI1620 PC Card Controller (rev 01)
02:04.1 CardBus bridge: Texas Instruments PCI1620 PC Card Controller (rev 01)
02:04.2 System peripheral: Texas Instruments PCI1620 Firmware Loading Function (rev 01)

[    0.000000] Linux version 2.6.21-rc4-mm1 (root@zephyr) (gcc version 4.2.0-alpha20070307 (prerelease) (Gentoo 4.2.0_alpha20070307)) #1 SMP PREEMPT Tue Mar 20 14:25:42 MDT 2007
[    0.000000] Command line: root=/dev/sda2 rootfstype=reiser4 ro i8042.nomux elevator=cfq resume=/dev/sda3 single
[    0.000000] BIOS-provided physical RAM map:
[    0.000000]  BIOS-e820: 0000000000000000 - 000000000009f800 (usable)
[    0.000000]  BIOS-e820: 000000000009f800 - 00000000000a0000 (reserved)
[    0.000000]  BIOS-e820: 00000000000d0000 - 0000000000100000 (reserved)
[    0.000000]  BIOS-e820: 0000000000100000 - 000000003ff70000 (usable)
[    0.000000]  BIOS-e820: 000000003ff70000 - 000000003ff7f000 (ACPI data)
[    0.000000]  BIOS-e820: 000000003ff7f000 - 000000003ff80000 (ACPI NVS)
[    0.000000]  BIOS-e820: 000000003ff80000 - 0000000040000000 (reserved)
[    0.000000]  BIOS-e820: 00000000fff80000 - 0000000100000000 (reserved)
[    0.000000] Entering add_active_range(0, 0, 159) 0 entries of 256 used
[    0.000000] Entering add_active_range(0, 256, 262000) 1 entries of 256 used
[    0.000000] end_pfn_map = 1048576
[    0.000000] DMI present.
[    0.000000] ACPI: RSDP 000F7240, 0014 (r0 PTLTD )
[    0.000000] ACPI: RSDT 3FF7A87E, 0034 (r1 PTLTD    RSDT    6040000  LTP        0)
[    0.000000] ACPI: FACP 3FF7EE13, 0074 (r1 NVIDIA CK8       6040000 PTL_    F4240)
[    0.000000] ACPI: DSDT 3FF7A8B2, 4561 (r1 NVIDIA      CK8  6040000 MSFT  100000E)
[    0.000000] ACPI: FACS 3FF7FFC0, 0040
[    0.000000] ACPI: APIC 3FF7EE87, 005A (r1 NVIDIA NV_APIC_  6040000  LTP        0)
[    0.000000] ACPI: BOOT 3FF7EEE1, 0028 (r1 PTLTD  $SBFTBL$  6040000  LTP        1)
[    0.000000] ACPI: SSDT 3FF7EF09, 00F7 (r1 PTLTD  POWERNOW  6040000  LTP        1)
[    0.000000] Entering add_active_range(0, 0, 159) 0 entries of 256 used
[    0.000000] Entering add_active_range(0, 256, 262000) 1 entries of 256 used
[    0.000000] No mptable found.
[    0.000000] sizeof(struct page) = 88
[    0.000000] Zone PFN ranges:
[    0.000000]   DMA             0 ->     4096
[    0.000000]   DMA32        4096 ->  1048576
[    0.000000]   Normal    1048576 ->  1048576
[    0.000000] Movable zone start PFN for each node
[    0.000000] early_node_map[2] active PFN ranges
[    0.000000]     0:        0 ->      159
[    0.000000]     0:      256 ->   262000
[    0.000000] On node 0 totalpages: 261903
[    0.000000] Node 0 memmap at 0xffff810001000000 size 23068672 first pfn 0xffff810001000000
[    0.000000]   DMA zone: 88 pages used for memmap
[    0.000000]   DMA zone: 2335 pages reserved
[    0.000000]   DMA zone: 1576 pages, LIFO batch:0
[    0.000000]   DMA32 zone: 5540 pages used for memmap
[    0.000000]   DMA32 zone: 252364 pages, LIFO batch:31
[    0.000000]   Normal zone: 0 pages used for memmap
[    0.000000]   Movable zone: 0 pages used for memmap
[    0.000000] Nvidia board detected. Ignoring ACPI timer override.
[    0.000000] If you got timer trouble try acpi_use_timer_override
[    0.000000] ACPI: PM-Timer IO Port: 0x8008
[    0.000000] ACPI: Local APIC address 0xfee00000
[    0.000000] ACPI: LAPIC (acpi_id[0x00] lapic_id[0x00] enabled)
[    0.000000] Processor #0 (Bootup-CPU)
[    0.000000] ACPI: LAPIC_NMI (acpi_id[0x00] high edge lint[0x1])
[    0.000000] ACPI: IOAPIC (id[0x02] address[0xfec00000] gsi_base[0])
[    0.000000] IOAPIC[0]: apic_id 2, address 0xfec00000, GSI 0-23
[    0.000000] ACPI: INT_SRC_OVR (bus 0 bus_irq 9 global_irq 9 low level)
[    0.000000] ACPI: INT_SRC_OVR (bus 0 bus_irq 0 global_irq 2 dfl dfl)
[    0.000000] ACPI: BIOS IRQ0 pin2 override ignored.
[    0.000000] ACPI: IRQ9 used by override.
[    0.000000] Setting APIC routing to flat
[    0.000000] Using ACPI (MADT) for SMP configuration information
[    0.000000] Nosave address range: 000000000009f000 - 00000000000a0000
[    0.000000] Nosave address range: 00000000000a0000 - 00000000000d0000
[    0.000000] Nosave address range: 00000000000d0000 - 0000000000100000
[    0.000000] Allocating PCI resources starting at 50000000 (gap: 40000000:bff80000)
[    0.000000] SMP: Allowing 1 CPUs, 0 hotplug CPUs
[    0.000000] PERCPU: Allocating 37312 bytes of per cpu data
[    0.000000] Built 1 zonelists.  Total pages: 253940
[    0.000000] Kernel command line: root=/dev/sda2 rootfstype=reiser4 ro i8042.nomux elevator=cfq resume=/dev/sda3 single
[    0.000000] Initializing CPU#0
[    0.000000] PID hash table entries: 4096 (order: 12, 32768 bytes)
[   17.397762] time.c: Detected 2194.378 MHz processor.
[   17.399354] Console: colour VGA+ 80x25
[   17.402298] Lock dependency validator: Copyright (c) 2006 Red Hat, Inc., Ingo Molnar
[   17.402371] ... MAX_LOCKDEP_SUBCLASSES:    8
[   17.402423] ... MAX_LOCK_DEPTH:          30
[   17.402476] ... MAX_LOCKDEP_KEYS:        2048
[   17.402528] ... CLASSHASH_SIZE:           1024
[   17.402581] ... MAX_LOCKDEP_ENTRIES:     8192
[   17.402633] ... MAX_LOCKDEP_CHAINS:      16384
[   17.402685] ... CHAINHASH_SIZE:          8192
[   17.402744]  memory used by lock dependency info: 1648 kB
[   17.402798]  per task-struct memory footprint: 1680 bytes
[   17.402853] ------------------------
[   17.402903] | Locking API testsuite:
[   17.402954] ----------------------------------------------------------------------------
[   17.403028]                                  | spin |wlock |rlock |mutex | wsem | rsem |
[   17.403101]   --------------------------------------------------------------------------
[   17.403179]                      A-A deadlock:  ok  |  ok  |  ok  |  ok  |  ok  |  ok  |
[   17.404370]                  A-B-B-A deadlock:  ok  |  ok  |  ok  |  ok  |  ok  |  ok  |
[   17.405486]              A-B-B-C-C-A deadlock:  ok  |  ok  |  ok  |  ok  |  ok  |  ok  |
[   17.406652]              A-B-C-A-B-C deadlock:  ok  |  ok  |  ok  |  ok  |  ok  |  ok  |
[   17.407826]          A-B-B-C-C-D-D-A deadlock:  ok  |  ok  |  ok  |  ok  |  ok  |  ok  |
[   17.409052]          A-B-C-D-B-D-D-A deadlock:  ok  |  ok  |  ok  |  ok  |  ok  |  ok  |
[   17.410280]          A-B-C-D-B-C-D-A deadlock:  ok  |  ok  |  ok  |  ok  |  ok  |  ok  |
[   17.411514]                     double unlock:  ok  |  ok  |  ok  |  ok  |  ok  |  ok  |
[   17.412580]                   initialize held:  ok  |  ok  |  ok  |  ok  |  ok  |  ok  |
[   17.413647]                  bad unlock order:  ok  |  ok  |  ok  |  ok  |  ok  |  ok  |
[   17.414777]   --------------------------------------------------------------------------
[   17.414851]               recursive read-lock:             |  ok  |             |  ok  |
[   17.415334]            recursive read-lock #2:             |  ok  |             |  ok  |
[   17.415824]             mixed read-write-lock:             |  ok  |             |  ok  |
[   17.416312]             mixed write-read-lock:             |  ok  |             |  ok  |
[   17.416807]   --------------------------------------------------------------------------
[   17.416880]      hard-irqs-on + irq-safe-A/12:  ok  |  ok  |  ok  |
[   17.417444]      soft-irqs-on + irq-safe-A/12:  ok  |  ok  |  ok  |
[   17.418018]      hard-irqs-on + irq-safe-A/21:  ok  |  ok  |  ok  |
[   17.418583]      soft-irqs-on + irq-safe-A/21:  ok  |  ok  |  ok  |
[   17.419156]        sirq-safe-A => hirqs-on/12:  ok  |  ok  |  ok  |
[   17.419730]        sirq-safe-A => hirqs-on/21:  ok  |  ok  |  ok  |
[   17.420294]          hard-safe-A + irqs-on/12:  ok  |  ok  |  ok  |
[   17.420865]          soft-safe-A + irqs-on/12:  ok  |  ok  |  ok  |
[   17.421432]          hard-safe-A + irqs-on/21:  ok  |  ok  |  ok  |
[   17.422003]          soft-safe-A + irqs-on/21:  ok  |  ok  |  ok  |
[   17.422568]     hard-safe-A + unsafe-B #1/123:  ok  |  ok  |  ok  |
[   17.423164]     soft-safe-A + unsafe-B #1/123:  ok  |  ok  |  ok  |
[   17.423759]     hard-safe-A + unsafe-B #1/132:  ok  |  ok  |  ok  |
[   17.424347]     soft-safe-A + unsafe-B #1/132:  ok  |  ok  |  ok  |
[   17.424943]     hard-safe-A + unsafe-B #1/213:  ok  |  ok  |  ok  |
[   17.425530]     soft-safe-A + unsafe-B #1/213:  ok  |  ok  |  ok  |
[   17.426126]     hard-safe-A + unsafe-B #1/231:  ok  |  ok  |  ok  |
[   17.426713]     soft-safe-A + unsafe-B #1/231:  ok  |  ok  |  ok  |
[   17.427296]     hard-safe-A + unsafe-B #1/312:  ok  |  ok  |  ok  |
[   17.427874]     soft-safe-A + unsafe-B #1/312:  ok  |  ok  |  ok  |
[   17.428446]     hard-safe-A + unsafe-B #1/321:  ok  |  ok  |  ok  |
[   17.429035]     soft-safe-A + unsafe-B #1/321:  ok  |  ok  |  ok  |
[   17.429618]     hard-safe-A + unsafe-B #2/123:  ok  |  ok  |  ok  |
[   17.430205]     soft-safe-A + unsafe-B #2/123:  ok  |  ok  |  ok  |
[   17.430798]     hard-safe-A + unsafe-B #2/132:  ok  |  ok  |  ok  |
[   17.431376]     soft-safe-A + unsafe-B #2/132:  ok  |  ok  |  ok  |
[   17.431969]     hard-safe-A + unsafe-B #2/213:  ok  |  ok  |  ok  |
[   17.432550]     soft-safe-A + unsafe-B #2/213:  ok  |  ok  |  ok  |
[   17.433143]     hard-safe-A + unsafe-B #2/231:  ok  |  ok  |  ok  |
[   17.433726]     soft-safe-A + unsafe-B #2/231:  ok  |  ok  |  ok  |
[   17.434307]     hard-safe-A + unsafe-B #2/312:  ok  |  ok  |  ok  |
[   17.434894]     soft-safe-A + unsafe-B #2/312:  ok  |  ok  |  ok  |
[   17.435479]     hard-safe-A + unsafe-B #2/321:  ok  |  ok  |  ok  |
[   17.436063]     soft-safe-A + unsafe-B #2/321:  ok  |  ok  |  ok  |
[   17.436647]       hard-irq lock-inversion/123:  ok  |  ok  |  ok  |
[   17.437237]       soft-irq lock-inversion/123:  ok  |  ok  |  ok  |
[   17.437831]       hard-irq lock-inversion/132:  ok  |  ok  |  ok  |
[   17.438410]       soft-irq lock-inversion/132:  ok  |  ok  |  ok  |
[   17.439004]       hard-irq lock-inversion/213:  ok  |  ok  |  ok  |
[   17.439586]       soft-irq lock-inversion/213:  ok  |  ok  |  ok  |
[   17.440180]       hard-irq lock-inversion/231:  ok  |  ok  |  ok  |
[   17.440765]       soft-irq lock-inversion/231:  ok  |  ok  |  ok  |
[   17.441347]       hard-irq lock-inversion/312:  ok  |  ok  |  ok  |
[   17.441934]       soft-irq lock-inversion/312:  ok  |  ok  |  ok  |
[   17.442520]       hard-irq lock-inversion/321:  ok  |  ok  |  ok  |
[   17.443105]       soft-irq lock-inversion/321:  ok  |  ok  |  ok  |
[   17.443694]       hard-irq read-recursion/123:  ok  |
[   17.443943]       soft-irq read-recursion/123:  ok  |
[   17.444193]       hard-irq read-recursion/132:  ok  |
[   17.444441]       soft-irq read-recursion/132:  ok  |
[   17.444700]       hard-irq read-recursion/213:  ok  |
[   17.444949]       soft-irq read-recursion/213:  ok  |
[   17.445199]       hard-irq read-recursion/231:  ok  |
[   17.445448]       soft-irq read-recursion/231:  ok  |
[   17.445707]       hard-irq read-recursion/312:  ok  |
[   17.445956]       soft-irq read-recursion/312:  ok  |
[   17.446206]       hard-irq read-recursion/321:  ok  |
[   17.446454]       soft-irq read-recursion/321:  ok  |
[   17.446711] -------------------------------------------------------
[   17.446767] Good, all 218 testcases passed! |
[   17.446820] ---------------------------------
[   17.447871] Dentry cache hash table entries: 131072 (order: 8, 1048576 bytes)
[   17.448711] Inode-cache hash table entries: 65536 (order: 7, 524288 bytes)
[   17.448901] Checking aperture...
[   17.448953] CPU 0: aperture @ e8000000 size 128 MB
[   17.470739] Memory: 1013752k/1048000k available (3200k kernel code, 33568k reserved, 1519k data, 212k init)
[   17.530543] Calibrating delay using timer specific routine.. 4390.56 BogoMIPS (lpj=2195280)
[   17.530799] Mount-cache hash table entries: 256
[   17.531328] CPU: L1 I Cache: 64K (64 bytes/line), D cache 64K (64 bytes/line)
[   17.531387] CPU: L2 Cache: 1024K (64 bytes/line)
[   17.531462] SMP alternatives: switching to UP code
[   17.531743] Freeing SMP alternatives: 28k freed
[   17.531816] ACPI: Core revision 20070126
[   17.536624] Parsing all Control Methods:
[   17.536769] Table [DSDT](id 0001) - 650 Objects with 66 Devices 205 Methods 24 Regions
[   17.538016] Parsing all Control Methods:
[   17.538146] Table [SSDT](id 0002) - 3 Objects with 0 Devices 1 Methods 0 Regions
[   17.538263]  tbxface-0587 [02] tb_load_namespace     : ACPI Tables successfully acquired
[   17.558729] evxfevnt-0091 [02] enable                : Transition to ACPI mode successful
[   17.569330] Using local APIC timer interrupts.
[   17.614892] result 12468058
[   17.614942] Detected 12.468 MHz APIC timer.
[   17.615526] Brought up 1 CPUs
[   17.615800] PM: Adding info for No Bus:platform
[   17.616047] NET: Registered protocol family 16
[   17.616280] No dock devices found.
[   17.616370] PM: Adding info for No Bus:vtcon0
[   17.616570] ACPI: bus type pci registered
[   17.616634] PCI: Using configuration type 1
[   17.618818] evgpeblk-0952 [04] ev_create_gpe_block   : GPE 00 to 1F [_GPE] 4 regs on int 0x9
[   17.618981] evgpeblk-0952 [04] ev_create_gpe_block   : GPE 20 to 5F [_GPE] 8 regs on int 0x9
[   17.619507] evgpeblk-1049 [03] ev_initialize_gpe_bloc: Found 5 Wake, Enabled 1 Runtime GPEs in this block
[   17.619786] evgpeblk-1049 [03] ev_initialize_gpe_bloc: Found 0 Wake, Enabled 1 Runtime GPEs in this block
[   17.620361] Completing Region/Field/Buffer/Package initialization:.....................................................................
[   17.624273] Initialized 24/24 Regions 2/2 Fields 29/29 Buffers 14/21 Packages (662 nodes)
[   17.624393] Initializing Device/Processor/Thermal objects by executing _INI methods:.
[   17.624561] Executed 1 _INI methods requiring 0 _STA executions (examined 70 objects)
[   17.624693] ACPI: Interpreter enabled
[   17.624745] ACPI: (supports S0 S3 S4 S5)
[   17.624983] ACPI: Using IOAPIC for interrupt routing
[   17.625149] PM: Adding info for acpi:acpi_system:00
[   17.625225] PM: Adding info for acpi:button_power:00
[   17.625289] PM: Adding info for acpi:ACPI0007:00
[   17.625374] PM: Adding info for acpi:device:00
[   17.625455] PM: Adding info for acpi:pnp0c14:00
[   17.625608] PM: Adding info for acpi:PNP0C0C:00
[   17.625690] PM: Adding info for acpi:PNP0C0D:00
[   17.625774] PM: Adding info for acpi:PNP0A03:00
[   17.625928] PM: Adding info for acpi:device:01
[   17.626084] PM: Adding info for acpi:device:02
[   17.626170] PM: Adding info for acpi:device:03
[   17.626256] PM: Adding info for acpi:device:04
[   17.626338] PM: Adding info for acpi:device:05
[   17.626447] PM: Adding info for acpi:device:06
[   17.626525] PM: Adding info for acpi:device:07
[   17.626610] PM: Adding info for acpi:device:08
[   17.626686] PM: Adding info for acpi:device:09
[   17.626768] PM: Adding info for acpi:device:0a
[   17.626847] PM: Adding info for acpi:device:0b
[   17.626934] PM: Adding info for acpi:device:0c
[   17.627011] PM: Adding info for acpi:device:0d
[   17.627094] PM: Adding info for acpi:device:0e
[   17.627176] PM: Adding info for acpi:device:0f
[   17.627258] PM: Adding info for acpi:device:10
[   17.627336] PM: Adding info for acpi:device:11
[   17.627427] PM: Adding info for acpi:device:12
[   17.627506] PM: Adding info for acpi:device:13
[   17.627590] PM: Adding info for acpi:device:14
[   17.627672] PM: Adding info for acpi:device:15
[   17.627753] PM: Adding info for acpi:ACPI0003:00
[   17.627832] PM: Adding info for acpi:PNP0C02:00
[   17.627913] PM: Adding info for acpi:PNP0C01:00
[   17.628002] PM: Adding info for acpi:PNP0C09:00
[   17.667388] PM: Adding info for acpi:PNP0C0A:00
[   17.667474] PM: Adding info for acpi:PNP0C02:01
[   17.667555] PM: Adding info for acpi:PNP0000:00
[   17.667629] PM: Adding info for acpi:PNP0100:00
[   17.667708] PM: Adding info for acpi:PNP0200:00
[   17.667782] PM: Adding info for acpi:PNP0800:00
[   17.667862] PM: Adding info for acpi:PNP0B00:00
[   17.667936] PM: Adding info for acpi:PNP0C04:00
[   17.668093] PM: Adding info for acpi:PNP0303:00
[   17.668243] PM: Adding info for acpi:PNP0F13:00
[   17.668330] PM: Adding info for acpi:PNP0A05:00
[   17.668800] PM: Adding info for acpi:PNP0700:00
[   17.673598] PM: Adding info for acpi:PNP0401:00
[   17.673814] PM: Adding info for acpi:device:16
[   17.673974] PM: Adding info for acpi:device:17
[   17.674122] PM: Adding info for acpi:device:18
[   17.674287] PM: Adding info for acpi:video:00
[   17.674407] PM: Adding info for acpi:device:19
[   17.674526] PM: Adding info for acpi:device:1a
[   17.674640] PM: Adding info for acpi:device:1b
[   17.675014] PM: Adding info for acpi:PNP0C0F:00
[   17.675187] PM: Adding info for acpi:PNP0C0F:01
[   17.675371] PM: Adding info for acpi:PNP0C0F:02
[   17.675544] PM: Adding info for acpi:PNP0C0F:03
[   17.675724] PM: Adding info for acpi:PNP0C0F:04
[   17.675894] PM: Adding info for acpi:PNP0C0F:05
[   17.676072] PM: Adding info for acpi:PNP0C0F:06
[   17.676245] PM: Adding info for acpi:PNP0C0F:07
[   17.676430] PM: Adding info for acpi:PNP0C0F:08
[   17.676616] PM: Adding info for acpi:PNP0C0F:09
[   17.676795] PM: Adding info for acpi:PNP0C0F:0a
[   17.676968] PM: Adding info for acpi:PNP0C0F:0b
[   17.677150] PM: Adding info for acpi:PNP0C0F:0c
[   17.677354] PM: Adding info for acpi:PNP0C0F:0d
[   17.677428] PM: Adding info for acpi:thermal:00
[   17.677487] PM: Adding info for acpi:thermal:01
[   17.677838] ACPI: PCI Root Bridge [PCI0] (0000:00)
[   17.677936] PM: Adding info for No Bus:pci0000:00
[   17.678314] 0000:00:08.0: cannot adjust BAR0 (not I/O)
[   17.678371] 0000:00:08.0: cannot adjust BAR1 (not I/O)
[   17.678427] 0000:00:08.0: cannot adjust BAR2 (not I/O)
[   17.678481] 0000:00:08.0: cannot adjust BAR3 (not I/O)
[   17.679034] PCI: Bus #03 (-#06) is hidden behind  bridge #02 (-#02) (try 'pci=assign-busses')
[   17.679109] Please report the result to linux-kernel to fix this permanently
[   17.679229] PCI: Bus #07 (-#0a) is hidden behind  bridge #02 (-#02) (try 'pci=assign-busses')
[   17.679304] Please report the result to linux-kernel to fix this permanently
[   17.679476] Boot video device is 0000:01:00.0
[   17.679535] ACPI: PCI Interrupt Routing Table [\_SB_.PCI0._PRT]
[   17.679678] ACPI: PCI Interrupt Routing Table [\_SB_.PCI0.P2P0._PRT]
[   17.679749] ACPI: PCI Interrupt Routing Table [\_SB_.PCI0.AGP0._PRT]
[   17.680943] PM: Adding info for pci:0000:00:00.0
[   17.682179] PM: Adding info for pci:0000:00:01.0
[   17.683404] PM: Adding info for pci:0000:00:01.1
[   17.684622] PM: Adding info for pci:0000:00:02.0
[   17.685836] PM: Adding info for pci:0000:00:02.1
[   17.687056] PM: Adding info for pci:0000:00:02.2
[   17.688272] PM: Adding info for pci:0000:00:06.0
[   17.689498] PM: Adding info for pci:0000:00:06.1
[   17.690712] PM: Adding info for pci:0000:00:08.0
[   17.691935] PM: Adding info for pci:0000:00:0a.0
[   17.693149] PM: Adding info for pci:0000:00:0b.0
[   17.694382] PM: Adding info for pci:0000:00:18.0
[   17.695596] PM: Adding info for pci:0000:00:18.1
[   17.696821] PM: Adding info for pci:0000:00:18.2
[   17.698035] PM: Adding info for pci:0000:00:18.3
[   17.698147] PM: Adding info for pci:0000:02:00.0
[   17.698253] PM: Adding info for pci:0000:02:01.0
[   17.698373] PM: Adding info for pci:0000:02:02.0
[   17.698479] PM: Adding info for pci:0000:02:04.0
[   17.698590] PM: Adding info for pci:0000:02:04.1
[   17.698697] PM: Adding info for pci:0000:02:04.2
[   17.698814] PM: Adding info for pci:0000:01:00.0
[   17.699206] ACPI: PCI Interrupt Link [LNK1] (IRQs 16 18 19) *0
[   17.699725] ACPI: PCI Interrupt Link [LNK2] (IRQs 16 18 19) *0
[   17.700246] ACPI: PCI Interrupt Link [LNK3] (IRQs 17) *0
[   17.700706] ACPI: PCI Interrupt Link [LNK4] (IRQs 16 18 19) *0, disabled.
[   17.701249] ACPI: PCI Interrupt Link [LNK5] (IRQs 16 18 19) *0
[   17.701754] ACPI: PCI Interrupt Link [LSMB] (IRQs 20 21 22) *0
[   17.702253] ACPI: PCI Interrupt Link [LUS0] (IRQs 20 21 22) *0
[   17.702761] ACPI: PCI Interrupt Link [LUS1] (IRQs 20 21 22) *0
[   17.703260] ACPI: PCI Interrupt Link [LUS2] (IRQs 20 21 22) *0
[   17.703775] ACPI: PCI Interrupt Link [LMAC] (IRQs 20 21 22) *0, disabled.
[   17.704311] ACPI: PCI Interrupt Link [LACI] (IRQs 20 21 22) *0
[   17.704816] ACPI: PCI Interrupt Link [LMCI] (IRQs 20 21 22) *0
[   17.705333] ACPI: PCI Interrupt Link [LPID] (IRQs 20 21 22) *0, disabled.
[   17.705879] ACPI: PCI Interrupt Link [LTID] (IRQs 20 21 22) *0, disabled.
[   17.706254] Linux Plug and Play Support v0.97 (c) Adam Belay
[   17.706334] pnp: PnP ACPI init
[   17.706401] PM: Adding info for No Bus:pnp0
[   17.706597] PM: Adding info for pnp:00:00
[   17.707281] PM: Adding info for pnp:00:01
[   17.707475] PM: Adding info for pnp:00:02
[   17.728319] PM: Adding info for pnp:00:03
[   17.728404] PM: Adding info for pnp:00:04
[   17.728465] PM: Adding info for pnp:00:05
[   17.728541] PM: Adding info for pnp:00:06
[   17.728606] PM: Adding info for pnp:00:07
[   17.728716] PM: Adding info for pnp:00:08
[   17.728822] PM: Adding info for pnp:00:09
[   17.729092] PM: Adding info for pnp:00:0a
[   17.731090] PM: Adding info for pnp:00:0b
[   17.732020] pnp: PnP ACPI: found 12 devices
[   17.732153] Generic PHY: Registered new driver
[   17.732403] SCSI subsystem initialized
[   17.732504] libata version 2.20 loaded.
[   17.732614] PCI: Using ACPI for IRQ routing
[   17.732668] PCI: If a device doesn't work, try "pci=routeirq".  If it helps, post a report
[   17.732752] PCI: Cannot allocate resource region 0 of device 0000:00:00.0
[   17.733015] agpgart: Detected AGP bridge 0
[   17.733072] agpgart: Setting up Nforce3 AGP.
[   17.737586] PM: Adding info for No Bus:agpgart
[   17.737683] agpgart: AGP aperture is 128M @ 0xe8000000
[   17.737871] pnp: 00:01: ioport range 0x8000-0x807f has been reserved
[   17.737929] pnp: 00:01: ioport range 0x8080-0x80ff has been reserved
[   17.737986] pnp: 00:01: ioport range 0x8400-0x847f has been reserved
[   17.738044] pnp: 00:01: ioport range 0x8480-0x84ff has been reserved
[   17.738101] pnp: 00:01: ioport range 0x8800-0x887f has been reserved
[   17.738158] pnp: 00:01: ioport range 0x8880-0x88ff has been reserved
[   17.738216] Time: tsc clocksource has been installed.
[   17.738275] pnp: 00:01: ioport range 0x2040-0x207f has been reserved
[   17.738332] pnp: 00:01: ioport range 0x2000-0x203f has been reserved
[   17.738396] pnp: 00:02: iomem range 0xfff80000-0xffffffff has been reserved
[   17.738455] pnp: 00:02: iomem range 0xfec00000-0xfec00fff has been reserved
[   17.738514] pnp: 00:02: iomem range 0xfee00000-0xfeefffff has been reserved
[   17.738572] pnp: 00:02: iomem range 0xfed00000-0xfed00fff has been reserved
[   17.738673] PM: Adding info for No Bus:mem
[   17.738725] PM: Adding info for No Bus:kmem
[   17.738768] PM: Adding info for No Bus:null
[   17.738816] PM: Adding info for No Bus:port
[   17.738858] PM: Adding info for No Bus:zero
[   17.738905] PM: Adding info for No Bus:full
[   17.738947] PM: Adding info for No Bus:random
[   17.738997] PM: Adding info for No Bus:urandom
[   17.739039] PM: Adding info for No Bus:kmsg
[   17.739158] PCI: Failed to allocate mem resource #10:4000000@e4000000 for 0000:02:04.0
[   17.739235] PCI: Failed to allocate mem resource #10:4000000@e4000000 for 0000:02:04.1
[   17.739313] PCI: Bus 3, cardbus bridge: 0000:02:04.0
[   17.739367]   IO window: 00003000-000030ff
[   17.739421]   IO window: 00003400-000034ff
[   17.739476]   PREFETCH window: 50000000-53ffffff
[   17.739531] PCI: Bus 7, cardbus bridge: 0000:02:04.1
[   17.739585]   IO window: 00003800-000038ff
[   17.739639]   IO window: 00003c00-00003cff
[   17.739693]   PREFETCH window: 54000000-57ffffff
[   17.739748] PCI: Bridge: 0000:00:0a.0
[   17.739800]   IO window: 3000-7fff
[   17.739853]   MEM window: e0100000-e17fffff
[   17.739906]   PREFETCH window: 50000000-57ffffff
[   17.739962] PCI: Bridge: 0000:00:0b.0
[   17.740013]   IO window: disabled.
[   17.740067]   MEM window: e2000000-e2ffffff
[   17.740121]   PREFETCH window: f0000000-f80fffff
[   17.740183] PCI: Setting latency timer of device 0000:00:0a.0 to 64
[   17.740708] ACPI: PCI Interrupt Link [LNK1] enabled at IRQ 19
[   17.740772] ACPI: PCI Interrupt 0000:02:04.0[A] -> Link [LNK1] -> GSI 19 (level, low) -> IRQ 19
[   17.741334] ACPI: PCI Interrupt Link [LNK2] enabled at IRQ 18
[   17.741394] ACPI: PCI Interrupt 0000:02:04.1[B] -> Link [LNK2] -> GSI 18 (level, low) -> IRQ 18
[   17.741573] NET: Registered protocol family 2
[   17.751310] IP route cache hash table entries: 32768 (order: 6, 262144 bytes)
[   17.751620] TCP established hash table entries: 65536 (order: 10, 4194304 bytes)
[   17.757500] TCP bind hash table entries: 65536 (order: 9, 3670016 bytes)
[   17.762325] TCP: Hash tables configured (established 65536 bind 65536)
[   17.762418] TCP reno registered
[   17.765663] Simple Boot Flag at 0x37 set to 0x1
[   17.765831] PM: Adding info for No Bus:mcelog
[   17.765911] PM: Adding info for No Bus:msr0
[   17.765974] PM: Adding info for No Bus:cpu0
[   17.766279] PM: Adding info for platform:pcspkr
[   17.766553] PM: Adding info for No Bus:snapshot
[   17.766602] audit: initializing netlink socket (disabled)
[   17.766677] audit(1174429488.298:1): initialized
[   17.766920] Total HugeTLB memory allocated, 0
[   17.767309] Loading Reiser4. See www.namesys.com for a description of Reiser4.
[   17.767640] Installing knfsd (copyright (C) 1996 [email protected]).
[   17.768058] io scheduler noop registered
[   17.768111] io scheduler anticipatory registered
[   17.768164] io scheduler deadline registered
[   17.768257] io scheduler cfq registered (default)
[   17.769736] ACPI: AC Adapter [ACAD] (on-line)
[   17.791230] ACPI: Battery Slot [BAT1] (battery present)
[   17.791428] input: Power Button (FF) as /class/input/input0
[   17.791490] ACPI: Power Button (FF) [PWRF]
[   17.791611] input: Power Button (CM) as /class/input/input1
[   17.791667] ACPI: Power Button (CM) [PWRB]
[   17.791799] input: Lid Switch as /class/input/input2
[   17.791854] ACPI: Lid Switch [LID]
[   17.792327] ACPI: Video Device [VGA] (multi-head: yes  rom: no  post: no)
[   17.793720] ACPI: CPU0 (power states: C1[C1] C2[C2])
[   17.793997] cpuidle: using driver acpi_idle
[   17.825473] ACPI Exception (thermal-0412): AE_NOT_FOUND, Invalid active threshold [0] [20070126]
[   17.828471] ACPI: Thermal Zone [THRM] (62 C)
[   17.828571] PM: Adding info for No Bus:tty
[   17.828615] PM: Adding info for No Bus:console
[   17.828663] PM: Adding info for No Bus:ptmx
[   17.828702] PM: Adding info for No Bus:tty0
[   17.828765] PM: Adding info for No Bus:vcs
[   17.828811] PM: Adding info for No Bus:vcsa
[   17.828858] PM: Adding info for No Bus:tty1
[   17.828908] PM: Adding info for No Bus:tty2
[   17.828949] PM: Adding info for No Bus:tty3
[   17.828996] PM: Adding info for No Bus:tty4
[   17.829035] PM: Adding info for No Bus:tty5
[   17.829089] PM: Adding info for No Bus:tty6
[   17.829132] PM: Adding info for No Bus:tty7
[   17.829183] PM: Adding info for No Bus:tty8
[   17.829228] PM: Adding info for No Bus:tty9
[   17.829280] PM: Adding info for No Bus:tty10
[   17.829323] PM: Adding info for No Bus:tty11
[   17.829374] PM: Adding info for No Bus:tty12
[   17.829418] PM: Adding info for No Bus:tty13
[   17.829474] PM: Adding info for No Bus:tty14
[   17.829518] PM: Adding info for No Bus:tty15
[   17.829570] PM: Adding info for No Bus:tty16
[   17.829614] PM: Adding info for No Bus:tty17
[   17.829667] PM: Adding info for No Bus:tty18
[   17.829713] PM: Adding info for No Bus:tty19
[   17.829767] PM: Adding info for No Bus:tty20
[   17.829820] PM: Adding info for No Bus:tty21
[   17.829874] PM: Adding info for No Bus:tty22
[   17.829922] PM: Adding info for No Bus:tty23
[   17.829976] PM: Adding info for No Bus:tty24
[   17.830024] PM: Adding info for No Bus:tty25
[   17.830083] PM: Adding info for No Bus:tty26
[   17.830130] PM: Adding info for No Bus:tty27
[   17.830185] PM: Adding info for No Bus:tty28
[   17.830230] PM: Adding info for No Bus:tty29
[   17.830286] PM: Adding info for No Bus:tty30
[   17.830332] PM: Adding info for No Bus:tty31
[   17.830387] PM: Adding info for No Bus:tty32
[   17.830433] PM: Adding info for No Bus:tty33
[   17.830489] PM: Adding info for No Bus:tty34
[   17.830540] PM: Adding info for No Bus:tty35
[   17.830600] PM: Adding info for No Bus:tty36
[   17.830647] PM: Adding info for No Bus:tty37
[   17.830705] PM: Adding info for No Bus:tty38
[   17.830751] PM: Adding info for No Bus:tty39
[   17.830807] PM: Adding info for No Bus:tty40
[   17.830855] PM: Adding info for No Bus:tty41
[   17.830912] PM: Adding info for No Bus:tty42
[   17.830960] PM: Adding info for No Bus:tty43
[   17.831015] PM: Adding info for No Bus:tty44
[   17.831063] PM: Adding info for No Bus:tty45
[   17.831138] PM: Adding info for No Bus:tty46
[   17.831181] PM: Adding info for No Bus:tty47
[   17.831235] PM: Adding info for No Bus:tty48
[   17.831280] PM: Adding info for No Bus:tty49
[   17.831334] PM: Adding info for No Bus:tty50
[   17.831378] PM: Adding info for No Bus:tty51
[   17.831429] PM: Adding info for No Bus:tty52
[   17.831474] PM: Adding info for No Bus:tty53
[   17.831527] PM: Adding info for No Bus:tty54
[   17.831574] PM: Adding info for No Bus:tty55
[   17.831633] PM: Adding info for No Bus:tty56
[   17.831683] PM: Adding info for No Bus:tty57
[   17.831740] PM: Adding info for No Bus:tty58
[   17.831787] PM: Adding info for No Bus:tty59
[   17.831844] PM: Adding info for No Bus:tty60
[   17.831893] PM: Adding info for No Bus:tty61
[   17.831952] PM: Adding info for No Bus:tty62
[   17.832002] PM: Adding info for No Bus:tty63
[   17.832160] PM: Adding info for No Bus:rtc
[   17.832208] Real Time Clock Driver v1.12ac
[   17.832270] PM: Adding info for No Bus:hpet
[   17.832420] PM: Adding info for No Bus:watchdog
[   17.832457] Software Watchdog Timer: 0.07 initialized. soft_noboot=0 soft_margin=60 sec (nowayout= 0)
[   17.832534] Linux agpgart interface v0.102 (c) Dave Jones
[   17.832589] Hangcheck: starting hangcheck timer 0.9.0 (tick is 180 seconds, margin is 60 seconds).
[   17.832664] Hangcheck: Using get_cycles().
[   17.833305] loop: loaded (max 8 devices)
[   17.833391] Marvell 88E1101: Registered new driver
[   17.833475] Marvell 88E1111: Registered new driver
[   17.833560] Marvell 88E1145: Registered new driver
[   17.833652] Davicom DM9161E: Registered new driver
[   17.833736] Davicom DM9131: Registered new driver
[   17.833821] Cicada Cis8204: Registered new driver
[   17.833905] Cicada Cis8201: Registered new driver
[   17.833997] LXT970: Registered new driver
[   17.834087] LXT971: Registered new driver
[   17.834171] QS6612: Registered new driver
[   17.834254] SMSC LAN83C185: Registered new driver
[   17.834402] PM: Adding info for No Bus:lo
[   17.834607] 8139too Fast Ethernet driver 0.9.28
[   17.834685] ACPI: PCI Interrupt 0000:02:01.0[A] -> Link [LNK2] -> GSI 18 (level, low) -> IRQ 18
[   17.835148] PM: Adding info for No Bus:eth0
[   17.835216] eth0: RealTek RTL8139 at 0xffffc20000018800, 00:0f:b0:07:dc:49, IRQ 18
[   17.835290] eth0:  Identified 8139 chip type 'RTL-8101'
[   17.835500] pata_amd 0000:00:08.0: version 0.3.8
[   17.835526] PCI: Setting latency timer of device 0000:00:08.0 to 64
[   17.835636] ata1: PATA max UDMA/133 cmd 0x00000000000101f0 ctl 0x00000000000103f6 bmdma 0x0000000000012080 irq 14
[   17.835753] ata2: PATA max UDMA/133 cmd 0x0000000000010170 ctl 0x0000000000010376 bmdma 0x0000000000012088 irq 15
[   17.835848] scsi0 : pata_amd
[   17.835912] PM: Adding info for No Bus:host0
[   17.990015] ata1.00: ATA-6: HTS721010G9AT00, MCZOA51A, max UDMA/100
[   17.990073] ata1.00: 195371568 sectors, multi 16: LBA48 
[   17.993003] ata1.00: configured for UDMA/100
[   17.993061] scsi1 : pata_amd
[   17.993119] PM: Adding info for No Bus:host1
[   18.297591] ata2.00: ATAPI, max MWDMA2
[   18.451340] ata2.00: configured for MWDMA2
[   18.451405] PM: Adding info for No Bus:target0:0:0
[   18.451680] scsi 0:0:0:0: Direct-Access     ATA      HTS721010G9AT00  MCZO PQ: 0 ANSI: 5
[   18.452894] PM: Adding info for scsi:0:0:0:0
[   18.453120] sd 0:0:0:0: [sda] 195371568 512-byte hardware sectors (100030 MB)
[   18.453193] sd 0:0:0:0: [sda] Write Protect is off
[   18.453248] sd 0:0:0:0: [sda] Mode Sense: 00 3a 00 00
[   18.453271] sd 0:0:0:0: [sda] Write cache: enabled, read cache: enabled, doesn't support DPO or FUA
[   18.453648] sd 0:0:0:0: [sda] 195371568 512-byte hardware sectors (100030 MB)
[   18.453717] sd 0:0:0:0: [sda] Write Protect is off
[   18.453771] sd 0:0:0:0: [sda] Mode Sense: 00 3a 00 00
[   18.453793] sd 0:0:0:0: [sda] Write cache: enabled, read cache: enabled, doesn't support DPO or FUA
[   18.453901]  sda: sda1 sda2 sda3
[   18.471748] sd 0:0:0:0: [sda] Attached SCSI disk
[   18.471874] PM: Adding info for No Bus:target1:0:0
[   18.472353] scsi 1:0:0:0: CD-ROM            HL-DT-ST DVD+RW GCA-4040N 1.19 PQ: 0 ANSI: 5
[   18.472434] PM: Adding info for scsi:1:0:0:0
[   18.474384] sr0: scsi3-mmc drive: 40x/24x writer cd/rw xa/form2 cdda tray
[   18.474443] Uniform CD-ROM driver Revision: 3.20
[   18.474628] sr 1:0:0:0: Attached scsi CD-ROM sr0
[   18.474809] Yenta: CardBus bridge found at 0000:02:04.0 [103c:006d]
[   18.474880] PCI: Bus 3, cardbus bridge: 0000:02:04.0
[   18.474934]   IO window: 00003000-000030ff
[   18.474988]   IO window: 00003400-000034ff
[   18.475043]   PREFETCH window: 50000000-53ffffff
[   18.475103]   MEM window: e0400000-e07fffff
[   18.475159] Yenta: Enabling burst memory read transactions
[   18.475215] Yenta: Using CSCINT to route CSC interrupts to PCI
[   18.475270] Yenta: Routing CardBus interrupts to PCI
[   18.475327] Yenta TI: socket 0000:02:04.0, mfunc 0x01111d22, devctl 0x64
[   18.698633] Yenta: ISA IRQ mask 0x0cf8, PCI irq 19
[   18.698687] Socket status: 30000086
[   18.698742] Yenta: Raising subordinate bus# of parent bus (#02) from #02 to #06
[   18.698816] pcmcia: parent PCI bridge I/O window: 0x3000 - 0x7fff
[   18.698886] pcmcia: parent PCI bridge Memory window: 0xe0100000 - 0xe17fffff
[   18.698945] pcmcia: parent PCI bridge Memory window: 0x50000000 - 0x57ffffff
[   18.699145] PM: Adding info for No Bus:pcmcia_socket0
[   18.949375] Yenta: CardBus bridge found at 0000:02:04.1 [103c:006d]
[   18.949447] Yenta: Using CSCINT to route CSC interrupts to PCI
[   18.949502] Yenta: Routing CardBus interrupts to PCI
[   18.949560] Yenta TI: socket 0000:02:04.1, mfunc 0x01111d22, devctl 0x64
[   19.172901] Yenta: ISA IRQ mask 0x0cf8, PCI irq 18
[   19.172955] Socket status: 30000006
[   19.173009] Yenta: Raising subordinate bus# of parent bus (#02) from #06 to #0a
[   19.173083] pcmcia: parent PCI bridge I/O window: 0x3000 - 0x7fff
[   19.173140] pcmcia: parent PCI bridge Memory window: 0xe0100000 - 0xe17fffff
[   19.173198] pcmcia: parent PCI bridge Memory window: 0x50000000 - 0x57ffffff
[   19.173373] PM: Adding info for No Bus:pcmcia_socket1
[   19.423712] PNP: PS/2 Controller [PNP0303:PS2K,PNP0f13:PS2M] at 0x60,0x64 irq 1,12
[   19.423836] PM: Adding info for platform:i8042
[   19.433971] serio: i8042 KBD port at 0x60,0x64 irq 1
[   19.434082] PM: Adding info for serio:serio0
[   19.434178] serio: i8042 AUX port at 0x60,0x64 irq 12
[   19.434240] PM: Adding info for serio:serio1
[   19.434351] PM: Adding info for No Bus:psaux
[   19.434390] mice: PS/2 mouse device common for all mice
[   19.434590] async_tx: api initialized (sync-only)
[   19.434645] xor: automatically using best checksumming function: generic_sse
[   19.439565]    generic_sse:  6560.000 MB/sec
[   19.439618] xor: using function: generic_sse (6560.000 MB/sec)
[   19.439674] EDAC MC: Ver: 2.0.1 Mar 20 2007
[   19.440144] EDAC MC0: Giving out device to k8_edac Athlon64/Opteron: DEV 0000:00:18.2
[   19.440257] cpuidle: using governor ladder
[   19.440389] TCP cubic registered
[   19.440440] Initializing XFRM netlink socket
[   19.440515] NET: Registered protocol family 1
[   19.440575] NET: Registered protocol family 17
[   19.440642] NET: Registered protocol family 15
[   19.440746] powernow-k8: Found 1 AMD Athlon(tm) 64 Processor 3400+ processors (version 2.00.00)
[   19.440940] powernow-k8:    0 : fid 0xe (2200 MHz), vid 0x2
[   19.440995] powernow-k8:    1 : fid 0xa (1800 MHz), vid 0xa
[   19.441050] powernow-k8:    2 : fid 0x0 (800 MHz), vid 0x12
[   19.441737] swsusp: Resume From Partition /dev/sda3
[   19.441739] PM: Checking swsusp image.
[   19.444558] Marking TSC unstable due to possible TSC halt in C2
[   19.444618] Time: acpi_pm clocksource has been installed.
[   19.458341] PM: Resume from disk failed.
[   19.499700] input: AT Translated Set 2 keyboard as /class/input/input3
[   19.576971] reiser4: sda2: found disk format 4.0.0.
[   25.172977] VFS: Mounted root (reiser4 filesystem) readonly.
[   25.173099] Freeing unused kernel memory: 212k freed
[   25.223972] PM: Adding info for No Bus:vcs1
[   25.453962] PM: Adding info for No Bus:vcsa1
[   26.020896] PM: Removing info for No Bus:vcs1
[   26.021468] PM: Removing info for No Bus:vcsa1
[   26.021876] PM: Adding info for No Bus:vcs1
[   26.022218] PM: Adding info for No Bus:vcsa1
[   26.022602] PM: Removing info for No Bus:vcs1
[   26.022952] PM: Removing info for No Bus:vcsa1
[   26.233012] PM: Adding info for No Bus:vcs1
[   26.233388] PM: Adding info for No Bus:vcsa1
[   26.233839] PM: Removing info for No Bus:vcs1
[   26.234049] PM: Removing info for No Bus:vcsa1
[   26.235514] PM: Adding info for No Bus:vcs1
[   26.235956] PM: Adding info for No Bus:vcsa1
[   26.236402] PM: Removing info for No Bus:vcs1
[   26.236784] PM: Removing info for No Bus:vcsa1
[   26.237017] PM: Adding info for No Bus:vcs1
[   26.237587] PM: Adding info for No Bus:vcsa1
[   26.238069] PM: Removing info for No Bus:vcs1
[   26.238457] PM: Removing info for No Bus:vcsa1
[   26.302723] PM: Adding info for No Bus:vcs1
[   26.303340] PM: Adding info for No Bus:vcsa1
[   29.773194] sd 0:0:0:0: Attached scsi generic sg0 type 0
[   29.773218] sr 1:0:0:0: Attached scsi generic sg1 type 5
[   29.936763] usbcore: registered new interface driver usbfs
[   29.936876] usbcore: registered new interface driver hub
[   29.936938] usbcore: registered new device driver usb
[   29.938045] ohci_hcd: 2006 August 04 USB 1.1 'Open' Host Controller (OHCI) Driver
[   29.938092] PCI: Enabling device 0000:00:02.0 (0004 -> 0006)
[   29.938715] ACPI: PCI Interrupt Link [LUS0] enabled at IRQ 22
[   29.938727] ACPI: PCI Interrupt 0000:00:02.0[A] -> Link [LUS0] -> GSI 22 (level, low) -> IRQ 22
[   29.938746] PCI: Setting latency timer of device 0000:00:02.0 to 64
[   29.938750] ohci_hcd 0000:00:02.0: OHCI Host Controller
[   29.943103] ohci_hcd 0000:00:02.0: new USB bus registered, assigned bus number 1
[   30.154957] ohci_hcd 0000:00:02.0: irq 22, io mem 0xe0000000
[   30.190412] PM: Adding info for No Bus:timer
[   30.208166] usb usb1: new device found, idVendor=0000, idProduct=0000
[   30.208171] usb usb1: new device strings: Mfr=3, Product=2, SerialNumber=1
[   30.208173] usb usb1: Product: OHCI Host Controller
[   30.208175] usb usb1: Manufacturer: Linux 2.6.21-rc4-mm1 ohci_hcd
[   30.208177] usb usb1: SerialNumber: 0000:00:02.0
[   30.208266] PM: Adding info for usb:usb1
[   30.208743] PM: Adding info for No Bus:usbdev1.1_ep00
[   30.208769] usb usb1: configuration #1 chosen from 1 choice
[   30.209010] PM: Adding info for usb:1-0:1.0
[   30.209168] hub 1-0:1.0: USB hub found
[   30.209274] hub 1-0:1.0: 3 ports detected
[   30.310069] PM: Adding info for No Bus:usbdev1.1_ep81
[   30.310414] PM: Adding info for No Bus:usbdev1.1
[   30.310803] PCI: Enabling device 0000:00:02.1 (0004 -> 0006)
[   30.311309] ACPI: PCI Interrupt Link [LUS1] enabled at IRQ 21
[   30.311320] ACPI: PCI Interrupt 0000:00:02.1[B] -> Link [LUS1] -> GSI 21 (level, low) -> IRQ 21
[   30.311341] PCI: Setting latency timer of device 0000:00:02.1 to 64
[   30.311344] ohci_hcd 0000:00:02.1: OHCI Host Controller
[   30.311377] ohci_hcd 0000:00:02.1: new USB bus registered, assigned bus number 2
[   30.523351] ohci_hcd 0000:00:02.1: irq 21, io mem 0xe0001000
[   30.576281] usb usb2: new device found, idVendor=0000, idProduct=0000
[   30.576285] usb usb2: new device strings: Mfr=3, Product=2, SerialNumber=1
[   30.576288] usb usb2: Product: OHCI Host Controller
[   30.576290] usb usb2: Manufacturer: Linux 2.6.21-rc4-mm1 ohci_hcd
[   30.576292] usb usb2: SerialNumber: 0000:00:02.1
[   30.576318] PM: Adding info for usb:usb2
[   30.576410] PM: Adding info for No Bus:usbdev2.1_ep00
[   30.576433] usb usb2: configuration #1 chosen from 1 choice
[   30.576451] PM: Adding info for usb:2-0:1.0
[   30.576485] hub 2-0:1.0: USB hub found
[   30.576499] hub 2-0:1.0: 3 ports detected
[   30.677124] PM: Adding info for No Bus:usbdev2.1_ep81
[   30.677190] PM: Adding info for No Bus:usbdev2.1
[   30.677819] ACPI: PCI Interrupt Link [LUS2] enabled at IRQ 20
[   30.677832] ACPI: PCI Interrupt 0000:00:02.2[C] -> Link [LUS2] -> GSI 20 (level, low) -> IRQ 20
[   30.677853] PCI: Setting latency timer of device 0000:00:02.2 to 64
[   30.677856] ehci_hcd 0000:00:02.2: EHCI Host Controller
[   30.677889] ehci_hcd 0000:00:02.2: new USB bus registered, assigned bus number 3
[   30.677932] PCI: cache line size of 64 is not supported by device 0000:00:02.2
[   30.677957] ehci_hcd 0000:00:02.2: irq 20, io mem 0xe0004000
[   30.677962] ehci_hcd 0000:00:02.2: USB 2.0 started, EHCI 1.00, driver 10 Dec 2004
[   30.678054] usb usb3: new device found, idVendor=0000, idProduct=0000
[   30.678057] usb usb3: new device strings: Mfr=3, Product=2, SerialNumber=1
[   30.678059] usb usb3: Product: EHCI Host Controller
[   30.678061] usb usb3: Manufacturer: Linux 2.6.21-rc4-mm1 ehci_hcd
[   30.678063] usb usb3: SerialNumber: 0000:00:02.2
[   30.678072] PM: Adding info for usb:usb3
[   30.678141] PM: Adding info for No Bus:usbdev3.1_ep00
[   30.678162] usb usb3: configuration #1 chosen from 1 choice
[   30.678184] PM: Adding info for usb:3-0:1.0
[   30.678207] hub 3-0:1.0: USB hub found
[   30.678380] hub 3-0:1.0: 6 ports detected
[   30.778960] PM: Adding info for No Bus:usbdev3.1_ep81
[   30.779025] PM: Adding info for No Bus:usbdev3.1
[   30.783028] ACPI: PCI Interrupt Link [LACI] enabled at IRQ 22
[   30.783033] ACPI: PCI Interrupt 0000:00:06.0[A] -> Link [LACI] -> GSI 22 (level, low) -> IRQ 22
[   30.783069] PCI: Setting latency timer of device 0000:00:06.0 to 64
[   30.867183] input: PS/2 Mouse as /class/input/input4
[   30.879995] input: AlpsPS/2 ALPS GlidePoint as /class/input/input5
[   30.886726] AC'97 0 analog subsections not ready
[   31.288300] usb 2-2: new full speed USB device using ohci_hcd and address 2
[   31.446880] intel8x0_measure_ac97_clock: measured 50191 usecs
[   31.446884] intel8x0: clocking to 47393
[   31.446930] PM: Adding info for No Bus:card0
[   31.447154] PM: Adding info for No Bus:pcmC0D2p
[   31.447411] PM: Adding info for No Bus:pcmC0D1c
[   31.447441] PM: Adding info for No Bus:pcmC0D0p
[   31.447539] PM: Adding info for No Bus:pcmC0D0c
[   31.447565] PM: Adding info for ac97:0-0:AD1981B
[   31.447601] PM: Adding info for No Bus:controlC0
[   31.508940] usb 2-2: new device found, idVendor=049f, idProduct=0086
[   31.508945] usb 2-2: new device strings: Mfr=1, Product=2, SerialNumber=0
[   31.508948] usb 2-2: Product: Bluetooth by hp
[   31.508950] usb 2-2: Manufacturer: ACTIONTEC
[   31.508975] PM: Adding info for usb:2-2
[   31.509068] PM: Adding info for No Bus:usbdev2.2_ep00
[   31.509092] usb 2-2: configuration #1 chosen from 1 choice
[   31.512951] PM: Adding info for usb:2-2:1.0
[   31.513032] PM: Adding info for No Bus:usbdev2.2_ep81
[   31.513073] PM: Adding info for No Bus:usbdev2.2_ep02
[   31.513107] PM: Adding info for No Bus:usbdev2.2_ep82
[   31.513141] PM: Adding info for usb:2-2:1.1
[   31.513182] PM: Adding info for No Bus:usbdev2.2_ep03
[   31.513221] PM: Adding info for No Bus:usbdev2.2_ep83
[   31.513249] PM: Adding info for usb:2-2:1.2
[   31.513329] PM: Adding info for No Bus:usbdev2.2
[   31.717722] hci_usb: Unknown symbol hci_suspend_dev
[   31.717763] hci_usb: Unknown symbol hci_free_dev
[   31.717983] hci_usb: Unknown symbol hci_resume_dev
[   31.718035] hci_usb: Unknown symbol hci_alloc_dev
[   31.718136] hci_usb: Unknown symbol hci_unregister_dev
[   31.718243] hci_usb: Unknown symbol hci_register_dev
[   31.781354] hci_usb: Unknown symbol hci_suspend_dev
[   31.781394] hci_usb: Unknown symbol hci_free_dev
[   31.781614] hci_usb: Unknown symbol hci_resume_dev
[   31.781666] hci_usb: Unknown symbol hci_alloc_dev
[   31.781767] hci_usb: Unknown symbol hci_unregister_dev
[   31.781874] hci_usb: Unknown symbol hci_register_dev
[   31.787382] hci_usb: Unknown symbol hci_suspend_dev
[   31.787422] hci_usb: Unknown symbol hci_free_dev
[   31.787642] hci_usb: Unknown symbol hci_resume_dev
[   31.787694] hci_usb: Unknown symbol hci_alloc_dev
[   31.787795] hci_usb: Unknown symbol hci_unregister_dev
[   31.787901] hci_usb: Unknown symbol hci_register_dev
[   33.005970] NET: Registered protocol family 10
[   34.776248] ReiserFS: sda1: found reiserfs format "3.6" with standard journal
[   34.776310] ReiserFS: sda1: using ordered data mode
[   34.776796] ReiserFS: sda1: journal params: device sda1, size 8192, journal first block 18, max trans len 1024, max batch 900, max commit age 30, max trans age 30
[   34.778707] ReiserFS: sda1: checking transaction log (sda1)
[   34.810342] ReiserFS: sda1: Using r5 hash to sort names
[   35.034524] Adding 2843496k swap on /dev/disk/by-uuid/fd35277a-8dc7-4afe-8257-fda61b757344.  Priority:100 extents:1 across:2843496k
[   42.116195] PM: Removing info for No Bus:vcs1
[   42.116521] PM: Removing info for No Bus:vcsa1
[   42.146081] PM: Adding info for No Bus:vcs1
[   42.146219] PM: Adding info for No Bus:vcsa1
[ 1061.733883] su[2639]: segfault at 0000000000000008 rip 0000003103c098b2 rsp 00007fffb0fea590 error 4
[ 1601.898867] PM: Removing info for No Bus:vcs1
[ 1601.899098] PM: Removing info for No Bus:vcsa1
[ 1601.905470] PM: Adding info for No Bus:vcs1
[ 1601.905622] PM: Adding info for No Bus:vcsa1
[ 1606.464599] PM: Adding info for No Bus:vcs2
[ 1606.464845] PM: Adding info for No Bus:vcsa2
[ 1606.466860] PM: Removing info for No Bus:vcs2
[ 1606.466969] PM: Removing info for No Bus:vcsa2
[ 1606.473400] PM: Adding info for No Bus:vcs3
[ 1606.473561] PM: Adding info for No Bus:vcsa3
[ 1606.475560] PM: Removing info for No Bus:vcs3
[ 1606.475667] PM: Removing info for No Bus:vcsa3
[ 1606.478811] PM: Adding info for No Bus:vcs4
[ 1606.478973] PM: Adding info for No Bus:vcsa4
[ 1606.479291] PM: Removing info for No Bus:vcs4
[ 1606.479321] PM: Removing info for No Bus:vcsa4
[ 1606.479397] PM: Adding info for No Bus:vcs5
[ 1606.479420] PM: Adding info for No Bus:vcsa5
[ 1606.479450] PM: Removing info for No Bus:vcs5
[ 1606.479472] PM: Removing info for No Bus:vcsa5
[ 1606.479549] PM: Adding info for No Bus:vcs6
[ 1606.479572] PM: Adding info for No Bus:vcsa6
[ 1606.479604] PM: Removing info for No Bus:vcs6
[ 1606.479626] PM: Removing info for No Bus:vcsa6
[ 1606.479694] PM: Adding info for No Bus:vcs7
[ 1606.479716] PM: Adding info for No Bus:vcsa7
[ 1606.479745] PM: Removing info for No Bus:vcs7
[ 1606.479767] PM: Removing info for No Bus:vcsa7
[ 1606.479835] PM: Adding info for No Bus:vcs8
[ 1606.479859] PM: Adding info for No Bus:vcsa8
[ 1606.479928] PM: Removing info for No Bus:vcs8
[ 1606.479951] PM: Removing info for No Bus:vcsa8
[ 1606.480018] PM: Adding info for No Bus:vcs9
[ 1606.480041] PM: Adding info for No Bus:vcsa9
[ 1606.480071] PM: Removing info for No Bus:vcs9
[ 1606.480093] PM: Removing info for No Bus:vcsa9
[ 1606.480160] PM: Adding info for No Bus:vcs10
[ 1606.480183] PM: Adding info for No Bus:vcsa10
[ 1606.480212] PM: Removing info for No Bus:vcs10
[ 1606.480234] PM: Removing info for No Bus:vcsa10
[ 1606.480302] PM: Adding info for No Bus:vcs11
[ 1606.480325] PM: Adding info for No Bus:vcsa11
[ 1606.480354] PM: Removing info for No Bus:vcs11
[ 1606.480376] PM: Removing info for No Bus:vcsa11
[ 1606.910477] PM: Adding info for No Bus:vcs2
[ 1606.910514] PM: Adding info for No Bus:vcsa2
[ 1606.917302] PM: Removing info for No Bus:vcs2
[ 1606.917349] PM: Removing info for No Bus:vcsa2
[ 1606.919043] PM: Adding info for No Bus:vcs3
[ 1606.919071] PM: Adding info for No Bus:vcsa3
[ 1606.927621] PM: Adding info for No Bus:vcs4
[ 1606.927658] PM: Adding info for No Bus:vcsa4
[ 1606.928858] PM: Removing info for No Bus:vcs3
[ 1606.928892] PM: Removing info for No Bus:vcsa3
[ 1606.935224] PM: Removing info for No Bus:vcs4
[ 1606.935269] PM: Removing info for No Bus:vcsa4
[ 1606.937061] PM: Adding info for No Bus:vcs5
[ 1606.937089] PM: Adding info for No Bus:vcsa5
[ 1606.947922] PM: Removing info for No Bus:vcs5
[ 1606.947970] PM: Removing info for No Bus:vcsa5
[ 1606.951331] PM: Adding info for No Bus:vcs6
[ 1606.951366] PM: Adding info for No Bus:vcsa6
[ 1606.958845] PM: Removing info for No Bus:vcs6
[ 1606.958892] PM: Removing info for No Bus:vcsa6
[ 1606.961602] PM: Adding info for No Bus:vcs7
[ 1606.961636] PM: Adding info for No Bus:vcsa7
[ 1606.972031] PM: Removing info for No Bus:vcs7
[ 1606.972082] PM: Removing info for No Bus:vcsa7
[ 1606.973903] PM: Adding info for No Bus:vcs8
[ 1606.973933] PM: Adding info for No Bus:vcsa8
[ 1606.982366] PM: Removing info for No Bus:vcs8
[ 1606.982413] PM: Removing info for No Bus:vcsa8
[ 1606.986078] PM: Adding info for No Bus:vcs9
[ 1606.986113] PM: Adding info for No Bus:vcsa9
[ 1607.000479] PM: Adding info for No Bus:vcs10
[ 1607.000514] PM: Adding info for No Bus:vcsa10
[ 1607.000750] PM: Removing info for No Bus:vcs9
[ 1607.000782] PM: Removing info for No Bus:vcsa9
[ 1607.025869] PM: Adding info for No Bus:vcs11
[ 1607.025904] PM: Adding info for No Bus:vcsa11
[ 1607.031896] PM: Removing info for No Bus:vcs11
[ 1607.031941] PM: Removing info for No Bus:vcsa11
[ 1607.043139] PM: Removing info for No Bus:vcs10
[ 1607.043185] PM: Removing info for No Bus:vcsa10
[ 1608.025861] eth0: link up, 100Mbps, full-duplex, lpa 0xC1E1
[ 1608.343434] PM: Removing info for No Bus:vcs1
[ 1608.343599] PM: Removing info for No Bus:vcsa1
[ 1608.348965] PM: Adding info for No Bus:vcs1
[ 1608.349084] PM: Adding info for No Bus:vcsa1
[ 1608.350359] PM: Removing info for No Bus:vcs1
[ 1608.350447] PM: Removing info for No Bus:vcsa1
[ 1608.350790] PM: Adding info for No Bus:vcs1
[ 1608.350809] PM: Adding info for No Bus:vcsa1
[ 1608.350872] PM: Removing info for No Bus:vcs1
[ 1608.350891] PM: Removing info for No Bus:vcsa1
[ 1608.350927] PM: Adding info for No Bus:vcs1
[ 1608.350945] PM: Adding info for No Bus:vcsa1
[ 1608.351049] PM: Removing info for No Bus:vcs1
[ 1608.351068] PM: Removing info for No Bus:vcsa1
[ 1608.353580] PM: Adding info for No Bus:vcs1
[ 1608.353616] PM: Adding info for No Bus:vcsa1
[ 1617.090942] eth0: no IPv6 routers present
[ 1617.123609] ata1.00: configured for UDMA/100
[ 1617.123618] ata1: EH complete
[ 1617.140588] sd 0:0:0:0: [sda] 195371568 512-byte hardware sectors (100030 MB)
[ 1617.140902] sd 0:0:0:0: [sda] Write Protect is off
[ 1617.140905] sd 0:0:0:0: [sda] Mode Sense: 00 3a 00 00
[ 1617.149976] sd 0:0:0:0: [sda] Write cache: enabled, read cache: enabled, doesn't support DPO or FUA
[ 1620.665587] process `named' is using obsolete setsockopt SO_BSDCOMPAT
[ 1620.742991] PM: Adding info for No Bus:vcs7
[ 1620.744509] PM: Adding info for No Bus:vcsa7
[ 1620.792323] PM: Removing info for No Bus:vcs7
[ 1620.793678] PM: Removing info for No Bus:vcsa7
[ 1621.266697] PM: Adding info for No Bus:vcs7
[ 1621.268278] PM: Adding info for No Bus:vcsa7
[ 1622.859425] PM: Adding info for No Bus:mixer
[ 1622.939896] PM: Adding info for No Bus:adsp
[ 1622.955211] PM: Adding info for No Bus:dsp
[ 1622.958759] PM: Adding info for No Bus:audio
[ 1624.113602] esound-esd[57956]: segfault at 000000000000ac44 rip 00000036a8c55b2b rsp 00007fff9723d8f0 error 4
[ 1625.283022] PM: Adding info for No Bus:vcs2
[ 1625.284318] PM: Adding info for No Bus:vcsa2
[ 1625.285611] PM: Adding info for No Bus:vcs3
[ 1625.286744] PM: Adding info for No Bus:vcsa3
[ 1625.289092] PM: Adding info for No Bus:vcs4
[ 1625.290316] PM: Adding info for No Bus:vcsa4
[ 1625.292624] PM: Adding info for No Bus:vcs5
[ 1625.293892] PM: Adding info for No Bus:vcsa5
[ 1625.296159] PM: Adding info for No Bus:vcs6
[ 1625.297535] PM: Adding info for No Bus:vcsa6
[ 1651.450090] esd[58205]: segfault at 000000000000ac44 rip 00000036a8c55b2b rsp 00007fffebe7fcd0 error 4
[ 1658.130375] ISO 9660 Extensions: Microsoft Joliet Level 3
[ 1658.254107] ISO 9660 Extensions: RRIP_1991A
[ 1660.022177] [ACPI Debug]  String: [0x12] "=====QUERY_25====="
[ 1663.057766] 
[ 1663.057769] =======================================================
[ 1663.057775] [ INFO: possible circular locking dependency detected ]
[ 1663.057778] 2.6.21-rc4-mm1 #1
[ 1663.057780] -------------------------------------------------------
[ 1663.057783] evolution-data-/58416 is trying to acquire lock:
[ 1663.057785]  (&mm->mmap_sem){----}, at: [<ffffffff80269eda>] do_page_fault+0x35a/0x800
[ 1663.057795] 
[ 1663.057796] but task is already holding lock:
[ 1663.057798]  (&data->latch){----}, at: [<ffffffff8036a835>] read_unix_file+0x95/0x450
[ 1663.057806] 
[ 1663.057807] which lock already depends on the new lock.
[ 1663.057808] 
[ 1663.057809] 
[ 1663.057810] the existing dependency chain (in reverse order) is:
[ 1663.057812] 
[ 1663.057813] -> #1 (&data->latch){----}:
[ 1663.057816]        [<ffffffff802ae4c1>] __lock_acquire+0xd61/0x1010
[ 1663.057823]        [<ffffffff802ae7b9>] lock_acquire+0x49/0x70
[ 1663.057829]        [<ffffffff8036c721>] get_exclusive_access+0x11/0x20
[ 1663.057836]        [<ffffffff802a8c9f>] down_write+0x2f/0x40
[ 1663.057843]        [<ffffffff8036c721>] get_exclusive_access+0x11/0x20
[ 1663.057849]        [<ffffffff8036ac50>] mmap_unix_file+0x60/0x140
[ 1663.057855]        [<ffffffff8020dbf7>] do_mmap_pgoff+0x4f7/0x800
[ 1663.057862]        [<ffffffff802acfd6>] mark_held_locks+0x76/0xa0
[ 1663.057868]        [<ffffffff80267754>] _spin_unlock_irq+0x24/0x50
[ 1663.057873]        [<ffffffff8026775f>] _spin_unlock_irq+0x2f/0x50
[ 1663.057879]        [<ffffffff80234db3>] elf_map+0xa3/0x100
[ 1663.057886]        [<ffffffff80217de2>] load_elf_binary+0x902/0x1c30
[ 1663.057893]        [<ffffffff8028de20>] load_aout_binary+0x0/0x960
[ 1663.057899]        [<ffffffff802174e0>] load_elf_binary+0x0/0x1c30
[ 1663.057905]        [<ffffffff802406b3>] search_binary_handler+0xf3/0x2b0
[ 1663.057912]        [<ffffffff8024f322>] load_script+0x212/0x240
[ 1663.057919]        [<ffffffff802174e0>] load_elf_binary+0x0/0x1c30
[ 1663.057925]        [<ffffffff8024f110>] load_script+0x0/0x240
[ 1663.057930]        [<ffffffff802406b3>] search_binary_handler+0xf3/0x2b0
[ 1663.057936]        [<ffffffff8023f9f8>] do_execve+0x188/0x250
[ 1663.057942]        [<ffffffff802a1a10>] __call_usermodehelper+0x0/0x80
[ 1663.057950]        [<ffffffff80255034>] sys_execve+0x44/0x70
[ 1663.057956]        [<ffffffff80260044>] kernel_execve+0x64/0xd0
[ 1663.057963]        [<ffffffff802a1a10>] __call_usermodehelper+0x0/0x80
[ 1663.057969]        [<ffffffff802a1e0b>] ____call_usermodehelper+0x15b/0x170
[ 1663.057975]        [<ffffffff8025ffd8>] child_rip+0xa/0x12
[ 1663.057981]        [<ffffffff80267754>] _spin_unlock_irq+0x24/0x50
[ 1663.057987]        [<ffffffff8025f6c0>] restore_args+0x0/0x30
[ 1663.057993]        [<ffffffff802a1cb0>] ____call_usermodehelper+0x0/0x170
[ 1663.057999]        [<ffffffff8025ffce>] child_rip+0x0/0x12
[ 1663.058004]        [<ffffffffffffffff>] 0xffffffffffffffff
[ 1663.058042] 
[ 1663.058043] -> #0 (&mm->mmap_sem){----}:
[ 1663.058045]        [<ffffffff802ac62b>] print_circular_bug_header+0xdb/0x100
[ 1663.058051]        [<ffffffff802ae390>] __lock_acquire+0xc30/0x1010
[ 1663.058057]        [<ffffffff802ae7b9>] lock_acquire+0x49/0x70
[ 1663.058062]        [<ffffffff80269eda>] do_page_fault+0x35a/0x800
[ 1663.058068]        [<ffffffff802a8bc2>] down_read+0x32/0x40
[ 1663.058074]        [<ffffffff80269eda>] do_page_fault+0x35a/0x800
[ 1663.058080]        [<ffffffff80264207>] thread_return+0xef/0x148
[ 1663.058088]        [<ffffffff802676fd>] _spin_unlock_irqrestore+0x3d/0x70
[ 1663.058094]        [<ffffffff80267d2d>] error_exit+0x0/0x96
[ 1663.058100]        [<ffffffff8020ccbf>] file_read_actor+0x6f/0x190
[ 1663.058105]        [<ffffffff80240a6f>] __lock_page+0x5f/0x70
[ 1663.058111]        [<ffffffff8020bcd7>] do_generic_mapping_read+0x1f7/0x500
[ 1663.058117]        [<ffffffff8020cc50>] file_read_actor+0x0/0x190
[ 1663.058123]        [<ffffffff802162ca>] generic_file_aio_read+0x19a/0x1f0
[ 1663.058129]        [<ffffffff8020c91f>] do_sync_read+0xcf/0x120
[ 1663.058135]        [<ffffffff802a61f0>] autoremove_wake_function+0x0/0x30
[ 1663.058141]        [<ffffffff802675f9>] _spin_unlock+0x29/0x50
[ 1663.058146]        [<ffffffff8034f6fe>] reiser4_grab+0xae/0xd0
[ 1663.058155]        [<ffffffff8036a879>] read_unix_file+0xd9/0x450
[ 1663.058161]        [<ffffffff8020acea>] vfs_read+0xba/0x180
[ 1663.058166]        [<ffffffff80212b2e>] sys_pread64+0x5e/0x90
[ 1663.058172]        [<ffffffff8025f11e>] system_call+0x7e/0x83
[ 1663.058178]        [<ffffffffffffffff>] 0xffffffffffffffff
[ 1663.058184] 
[ 1663.058185] other info that might help us debug this:
[ 1663.058186] 
[ 1663.058188] 1 lock held by evolution-data-/58416:
[ 1663.058190]  #0:  (&data->latch){----}, at: [<ffffffff8036a835>] read_unix_file+0x95/0x450
[ 1663.058196] 
[ 1663.058196] stack backtrace:
[ 1663.058198] 
[ 1663.058198] Call Trace:
[ 1663.058204]  [<ffffffff802ac214>] print_circular_bug_tail+0x74/0x90
[ 1663.058208]  [<ffffffff802ac62b>] print_circular_bug_header+0xdb/0x100
[ 1663.058211]  [<ffffffff802ae390>] __lock_acquire+0xc30/0x1010
[ 1663.058216]  [<ffffffff802ae7b9>] lock_acquire+0x49/0x70
[ 1663.058219]  [<ffffffff80269eda>] do_page_fault+0x35a/0x800
[ 1663.058223]  [<ffffffff802a8bc2>] down_read+0x32/0x40
[ 1663.058226]  [<ffffffff80269eda>] do_page_fault+0x35a/0x800
[ 1663.058232]  [<ffffffff80264207>] thread_return+0xef/0x148
[ 1663.058236]  [<ffffffff802676fd>] _spin_unlock_irqrestore+0x3d/0x70
[ 1663.058240]  [<ffffffff80267d2d>] error_exit+0x0/0x96
[ 1663.058245]  [<ffffffff8020ccbf>] file_read_actor+0x6f/0x190
[ 1663.058248]  [<ffffffff80240a6f>] __lock_page+0x5f/0x70
[ 1663.058253]  [<ffffffff8020bcd7>] do_generic_mapping_read+0x1f7/0x500
[ 1663.058256]  [<ffffffff8020cc50>] file_read_actor+0x0/0x190
[ 1663.058263]  [<ffffffff802162ca>] generic_file_aio_read+0x19a/0x1f0
[ 1663.058267]  [<ffffffff8020c91f>] do_sync_read+0xcf/0x120
[ 1663.058272]  [<ffffffff802a61f0>] autoremove_wake_function+0x0/0x30
[ 1663.058276]  [<ffffffff802675f9>] _spin_unlock+0x29/0x50
[ 1663.058280]  [<ffffffff8034f6fe>] reiser4_grab+0xae/0xd0
[ 1663.058284]  [<ffffffff8036a879>] read_unix_file+0xd9/0x450

[ 1663.058290]  [<ffffffff8020acea>] vfs_read+0xba/0x180
[ 1663.058294]  [<ffffffff80212b2e>] sys_pread64+0x5e/0x90
[ 1663.058298]  [<ffffffff8025f11e>] system_call+0x7e/0x83
[ 1663.058301] 
[ 1714.279224] process `rndc' is using obsolete setsockopt SO_BSDCOMPAT
[ 1717.959422] eth0: link up, 100Mbps, full-duplex, lpa 0xC1E1
[ 1721.544091] process `named' is using obsolete setsockopt SO_BSDCOMPAT
[ 1725.344372] eth0: no IPv6 routers present

Quoted 9 lines · On Tue, 20 Mar 2007 17:23:54 -0600 Zan Lynx <[email protected]> wrote:

Quoted 6 lines · Andrew Morton

Temporarily at

http://userweb.kernel.org/~akpm/2.6.21-rc4-mm1/

Will appear later at

Quoted 9 lines

Quoted 3 lines

ftp://ftp.kernel.org/pub/linux/kernel/people/akpm/patches/2.6/2.6.21-rc4/2.6.21-rc4-mm1/

First impressions:
Several of the same bugs as rc3-mm*:
* Freezes immediately if I touch the wlan0 device after loading the new Broadcom wireless driver.

cc linux-wireless

Quoted 3 lines

* Freezes immediately if I allow Bluetooth to configure.

cc bluez-devel

Quoted 6 lines

* All freezes simply stop, no BUG or panic happens, no watchdog, soft or NMI ever triggers. Thinking about it, I wonder if disabling EDAC_K8 would help here? Does it steal NMI? I'll try that later.

Mabe that will be fixed by the just-uploaded ftp://ftp.kernel.org/pub/linux/kernel/people/akpm/patches/2.6/2.6.21-rc4/2.6.21-rc4-mm1/hot-fixes/tty-in-tiocsctty-when-we-steal-a-tty-hang-it-up-fix.patch

Quoted 4 lines

* I am using Reiser4 and after one of the above freezes and hard power cycle, files that were in use *read*only* are filled with zeros.

Quoted 5 lines

For example, while testing and experiencing the above
freezes, I lost /etc/ld.so.preload
and /lib/security/pam_limits.so. What the heck?

cc reiserfs-dev

Quoted 1 line

* Freezes immediately if I allow Bluetooth to configure.

cc bluez-devel

Hi Andrew,

Quoted 3 lines

Quoted 1 line

* Freezes immediately if I allow Bluetooth to configure.

cc bluez-devel

is the -mm specific or does this also happens with 2.6.21-rc4?

Quoted 5 lines · On Tue, 20 Mar 2007 17:23:54 -0600 Zan Lynx <[email protected]> wrote:

Quoted 4 lines · Andrew Morton

Temporarily at

http://userweb.kernel.org/~akpm/2.6.21-rc4-mm1/

Quoted 7 lines

Quoted 3 lines

Will appear later at

ftp://ftp.kernel.org/pub/linux/kernel/people/akpm/patches/2.6/2.6.21-rc4/2.6.21-rc4-mm1/

First impressions:
Several of the same bugs as rc3-mm*:
* Freezes immediately if I touch the wlan0 device after loading the new Broadcom wireless driver.

Quoted 1 line

02:02.0 Network controller: Broadcom Corporation BCM4303 802.11b Wireless LAN Controller (rev 02)

Quoted 5 lines · Andrew Morton

Quoted 4 lines · On Tue, 20 Mar 2007 17:23:54 -0600 Zan Lynx <[email protected]> wrote:

First impressions:
Several of the same bugs as rc3-mm*:
* Freezes immediately if I touch the wlan0 device after loading the new Broadcom wireless driver.

--snip--

Quoted 1 line

Quoted 1 line

02:02.0 Network controller: Broadcom Corporation BCM4303 802.11b Wireless LAN Controller (rev 02)

I'm a little confused. The bcm43xx-mac80211 driver does not handle 802.11b devices, and the bcm43xx-softmac driver should not freeze. Which one was configured here?

It may have partly been a problem of having half of softmac and half devicescape. I'm not entirely sure what udev did.

I tried a patch for the Sonic Silicon that was posted and I turned off all the configuration for the softmac driver.

It isn't crashing right now but 802.11 isn't working either. I may get a chance this weekend to try some things with it, and some different firmware sets.

If the new bcm43xx drivers do not support 802.11b at all and never will, I missed the documentation. Someone should add that to Kconfig.

Quoted 5 lines · On Tue, 20 Mar 2007 17:23:54 -0600 Zan Lynx <[email protected]> wrote:

Quoted 4 lines · Andrew Morton

Temporarily at

http://userweb.kernel.org/~akpm/2.6.21-rc4-mm1/

Quoted 7 lines

Quoted 3 lines

Will appear later at

ftp://ftp.kernel.org/pub/linux/kernel/people/akpm/patches/2.6/2.6.21-rc4/2.6.21-rc4-mm1/

First impressions:
Several of the same bugs as rc3-mm*:
* Freezes immediately if I touch the wlan0 device after loading the new Broadcom wireless driver.

Quoted 7 lines · Andrew Morton

Quoted 5 lines · On Tue, 20 Mar 2007 17:23:54 -0600 Zan Lynx <[email protected]> wrote:

Quoted 4 lines · Andrew Morton

Temporarily at

http://userweb.kernel.org/~akpm/2.6.21-rc4-mm1/

Quoted 7 lines

Quoted 7 lines

Quoted 3 lines

Will appear later at

ftp://ftp.kernel.org/pub/linux/kernel/people/akpm/patches/2.6/2.6.21-rc4/2.6.21-rc4-mm1/

First impressions:
Several of the same bugs as rc3-mm*:
* Freezes immediately if I touch the wlan0 device after loading the new Broadcom wireless driver.

The version of the ssb driver in 2.6.21-rc4-mm1 has a bug that causes a kernel oops if the bcm43xx chip contains a USB (dangling) core. This bug has been fixed in Michael Buesch's tree, but apparently not yet in Linville's wireless-dev tree. The patch is as follows:

commit 08531ff130bcc8181d9294a66e25010f48eefb97

Author: Michael Buesch <[email protected]>
Date:   Wed Mar 7 23:01:08 2007 +0100

ssb: Don't freeze unregistered devices.

Quoted 24 lines · Larry Finger

Quoted 7 lines · Andrew Morton

Quoted 5 lines · On Tue, 20 Mar 2007 17:23:54 -0600 Zan Lynx <[email protected]> wrote:

Quoted 4 lines · Andrew Morton

Temporarily at

http://userweb.kernel.org/~akpm/2.6.21-rc4-mm1/

Quoted 7 lines

Quoted 7 lines

Quoted 3 lines

Will appear later at

ftp://ftp.kernel.org/pub/linux/kernel/people/akpm/patches/2.6/2.6.21-rc4/2.6.21-rc4-mm1/

First impressions:
Several of the same bugs as rc3-mm*:
* Freezes immediately if I touch the wlan0 device after loading the new Broadcom wireless driver.

The version of the ssb driver in 2.6.21-rc4-mm1 has a bug that causes a kernel oops if the bcm43xx chip contains a USB (dangling) core. This bug has been fixed in Michael Buesch's tree, but apparently not yet in Linville's wireless-dev tree. The patch is as follows:

commit 08531ff130bcc8181d9294a66e25010f48eefb97

Author: Michael Buesch <[email protected]>
Date:   Wed Mar 7 23:01:08 2007 +0100

Quoted 1 line

ssb: Don't freeze unregistered devices.

No, that's a different fix for suspend.

This is the fix:
http://bu3sch.de/gitweb?p=wireless-dev.git;a=commitdiff;h=b87f743f3643ea162892dce0bbc91e6f026a49bf

Pull request was sent to John.

Quoted 10 lines · Andrew Morton

Quoted 8 lines · On Tue, 20 Mar 2007 17:23:54 -0600 Zan Lynx <[email protected]> wrote:

Quoted 7 lines · Andrew Morton

Temporarily at

http://userweb.kernel.org/~akpm/2.6.21-rc4-mm1/

Will appear later at

ftp://ftp.kernel.org/pub/linux/kernel/people/akpm/patches/2.6/2.6.21-rc4/2.6.21-rc4-mm1/

Quoted 4 lines

Quoted 4 lines

First impressions:
Several of the same bugs as rc3-mm*:
* Freezes immediately if I touch the wlan0 device after loading the new Broadcom wireless driver.

The version of the ssb driver in 2.6.21-rc4-mm1 has a bug that causes a kernel oops if the bcm43xx chip contains a USB (dangling) core. This bug has been fixed in Michael Buesch's tree, but apparently not yet in Linville's wireless-dev tree. The patch is as follows:

With the latest -mm, I'm now getting this:

Mar 21 15:06:52 cinder kernel: ipw2200: Detected Intel PRO/Wireless
2200BG Network Connection
Mar 21 15:06:52 cinder kernel: firmware_loading_store: unexpected
value (0)
Mar 21 15:06:52 cinder kernel: ipw2200: ipw2200-bss.fw
request_firmware failed:
Reason -2
Mar 21 15:06:52 cinder kernel: ipw2200: Unable to load firmware: -2
Mar 21 15:06:52 cinder kernel: ipw2200: failed to register network

device

With the latest -mm, I'm now getting this:

Mar 21 15:06:52 cinder kernel: ipw2200: Detected Intel PRO/Wireless
2200BG Network Connection
Mar 21 15:06:52 cinder kernel: firmware_loading_store: unexpected
value (0)
Mar 21 15:06:52 cinder kernel: ipw2200: ipw2200-bss.fw
request_firmware failed:
Reason -2
Mar 21 15:06:52 cinder kernel: ipw2200: Unable to load firmware: -2
Mar 21 15:06:52 cinder kernel: ipw2200: failed to register network

device

Quoted 11 lines · Matt Mackall

With the latest -mm, I'm now getting this:

Mar 21 15:06:52 cinder kernel: ipw2200: Detected Intel PRO/Wireless
2200BG Network Connection
Mar 21 15:06:52 cinder kernel: firmware_loading_store: unexpected
value (0)
Mar 21 15:06:52 cinder kernel: ipw2200: ipw2200-bss.fw
request_firmware failed:
Reason -2
Mar 21 15:06:52 cinder kernel: ipw2200: Unable to load firmware: -2
Mar 21 15:06:52 cinder kernel: ipw2200: failed to register network

Quoted 1 line

device

The problem for me is a general protection fault.

kernel: general protection fault: 0000 [1] SMP
kernel: last sysfs file: class/firmware/0000:01:00.0/loading
kernel: CPU 0
kernel: Modules linked in: af_packet snd_pcm_oss snd_mixer_oss snd_seq snd_seq_device cpufreq_conservative cpufreq_ondemand cpufreq_userspace cpufreq_powersave powernow_k8 freq_table button battery ac nls_utf8 ntfs loop nfsd exportfs nfs lockd nfs_acl sunrpc sr_mod usb_storage libusual snd_hda_intel snd_hda_codec sdhci snd_pcm snd_timer ohci1394 mmc_core snd ieee1394 forcedeth soundcore snd_page_alloc ohci_hcd ide_cd ehci_hcd cdrom usbcore i2c_nforce2 bcm43xx firmware_class ieee80211softmac ieee80211 ieee80211_crypt ext3 mbcache jbd sg edd fan sata_nv libata amd74xx thermal processor sd_mod scsi_mod ide_disk ide_core

kernel: Pid: 4026, comm: cat Not tainted 2.6.21-rc4-mm1-mm1 #6
kernel: RIP: 0010:[<ffffffff80251f99>]  [<ffffffff80251f99>] module_put+0x1f/0x35
kernel: RSP: 0018:ffff810006f85ea8  EFLAGS: 00010256
kernel: RAX: 6b6b6b6b6b6b6dab RBX: ffff810005dbe1f0 RCX: ffffffff803f6160
kernel: RDX: 0000000000000001 RSI: ffffffff802ec3dc RDI: 6b6b6b6b6b6b6b6b
kernel: RBP: ffff810006f85ea8 R08: 0000000000000000 R09: ffff810005918888
kernel: R10: 0000000000000000 R11: ffffffff8811b020 R12: ffff81000850d000
kernel: R13: ffff810004ec25a8 R14: ffff810006f38c18 R15: ffff8100034017c0
kernel: FS:  00002b621c2f86f0(0000) GS:ffffffff8051e000(0000) knlGS:0000000000000000
kernel: CS:  0010 DS: 0000 ES: 0000 CR0: 000000008005003b
kernel: CR2: 00002b621c01d3c0 CR3: 0000000008154000 CR4: 00000000000006e0
kernel: Process cat (pid: 4026, threadinfo ffff810006f84000, task ffff810005dd3140)
kernel: Stack:  ffff810006f85ec8 ffffffff802cf4ba 0000000000000008 ffff810006f38c18
kernel:  ffff810006f85f08 ffffffff80290a44 ffff81000853bde0 ffff810004ec25a8
kernel:  ffff8100035d1cb0 0000000000000000 ffff810004ec25a8 00007fff8ed0f6d0
kernel: Call Trace:
kernel:  [<ffffffff802cf4ba>] release+0x3a/0x49
kernel:  [<ffffffff80290a44>] __fput+0xca/0x180
kernel:  [<ffffffff80290b0e>] fput+0x14/0x16
kernel:  [<ffffffff8028e1aa>] filp_close+0x66/0x71
kernel:  [<ffffffff8028f3c2>] sys_close+0x98/0xdd
kernel:  [<ffffffff80209f6e>] system_call+0x7e/0x83

kernel:
kernel:
kernel: Code: 48 ff 08 83 3f 02 75 0c 48 8b bf 50 22 00 00 e8 08 9d fd ff
kernel: RIP [<ffffffff80251f99>] module_put+0x1f/0x35
kernel: RSP <ffff810006f85ea8>

With the latest -mm, I'm now getting this:

Mar 21 15:06:52 cinder kernel: ipw2200: Detected Intel PRO/Wireless
2200BG Network Connection
Mar 21 15:06:52 cinder kernel: firmware_loading_store: unexpected
value (0)
Mar 21 15:06:52 cinder kernel: ipw2200: ipw2200-bss.fw
request_firmware failed:
Reason -2
Mar 21 15:06:52 cinder kernel: ipw2200: Unable to load firmware: -2
Mar 21 15:06:52 cinder kernel: ipw2200: failed to register network

device

With the latest -mm, I'm now getting this:

Mar 21 15:06:52 cinder kernel: ipw2200: Detected Intel PRO/Wireless
2200BG Network Connection
Mar 21 15:06:52 cinder kernel: firmware_loading_store: unexpected
value (0)
Mar 21 15:06:52 cinder kernel: ipw2200: ipw2200-bss.fw
request_firmware failed:
Reason -2
Mar 21 15:06:52 cinder kernel: ipw2200: Unable to load firmware: -2
Mar 21 15:06:52 cinder kernel: ipw2200: failed to register network

device

Quoted 11 lines · On Wed, 21 Mar 2007 15:22:25 -0500 Matt Mackall <[email protected]> wrote:

With the latest -mm, I'm now getting this:

Mar 21 15:06:52 cinder kernel: ipw2200: Detected Intel PRO/Wireless
2200BG Network Connection
Mar 21 15:06:52 cinder kernel: firmware_loading_store: unexpected
value (0)
Mar 21 15:06:52 cinder kernel: ipw2200: ipw2200-bss.fw
request_firmware failed:
Reason -2
Mar 21 15:06:52 cinder kernel: ipw2200: Unable to load firmware: -2
Mar 21 15:06:52 cinder kernel: ipw2200: failed to register network

Quoted 1 line

device

The firmware loading bug is caused by driver-core-handles-kobject_uevent-failure-while-device_add.patch

Quoted 17 lines · Cornelia Huck

Quoted 14 lines · Andrew Morton

Quoted 12 lines · On Wed, 21 Mar 2007 15:22:25 -0500 Matt Mackall <[email protected]> wrote:

With the latest -mm, I'm now getting this:

Mar 21 15:06:52 cinder kernel: ipw2200: Detected Intel PRO/Wireless
2200BG Network Connection
Mar 21 15:06:52 cinder kernel: firmware_loading_store: unexpected
value (0)
Mar 21 15:06:52 cinder kernel: ipw2200: ipw2200-bss.fw
request_firmware failed:
Reason -2
Mar 21 15:06:52 cinder kernel: ipw2200: Unable to load firmware: -2
Mar 21 15:06:52 cinder kernel: ipw2200: failed to register network

device

Quoted 6 lines

Quoted 2 lines

The firmware loading bug is caused by driver-core-handles-kobject_uevent-failure-while-device_add.patch

Hm, this patch looks sane. It might be a good idea to enable CONFIG_DEBUG_KOBJECT and find out why kobject_uevent() actually fails in this case...

Attached is the appropriate portion of /var/log/messages with Kobject debugging enabled.

Mar 22 07:01:42 larrylap2 kernel: kobject 0000:01:00.0: registering. parent: firmware, set: devices
Mar 22 07:01:42 larrylap2 kernel: kobject_uevent_env
Mar 22 07:01:42 larrylap2 kernel: fill_kobj_path: path = '/class/firmware/0000:01:00.0'
Mar 22 07:01:42 larrylap2 kernel: fill_kobj_path: path = '/devices/pci0000:00/0000:00:02.0/0000:01:00.0'
Mar 22 07:01:42 larrylap2 kernel: kobject_uevent_env
Mar 22 07:01:42 larrylap2 ntpd[3434]: frequency initialized -31.513 PPM from /var/lib/ntp/drift/ntp.drift
Mar 22 07:01:43 larrylap2 kernel: fill_kobj_path: path = '/class/firmware/0000:01:00.0'
Mar 22 07:01:43 larrylap2 kernel: fill_kobj_path: path = '/devices/pci0000:00/0000:00:02.0/0000:01:00.0'
Mar 22 07:01:43 larrylap2 kernel: firmware_loading_store: unexpected value (0)
Mar 22 07:01:43 larrylap2 kernel: kobject_uevent_env
Mar 22 07:01:43 larrylap2 kernel: fill_kobj_path: path = '/class/firmware/0000:01:00.0'
Mar 22 07:01:43 larrylap2 kernel: fill_kobj_path: path = '/devices/pci0000:00/0000:00:02.0/0000:01:00.0'
Mar 22 07:01:43 larrylap2 kernel: kobject 0000:01:00.0: cleaning up

On Thu, 22 Mar 2007 07:23:06 -0500,

This would indicate that dev_uevent had been called. But how could kobject_uevent then return an error without moaning about an uevent() error code? Maybe the following debug patch could shed some light on this (all moaning is prefixed with kobject_uevent_env, so it should be easy to spot)...

Quoted 7 lines · Cornelia Huck

On Thu, 22 Mar 2007 07:23:06 -0500,

This would indicate that dev_uevent had been called. But how could kobject_uevent then return an error without moaning about an uevent() error code? Maybe the following debug patch could shed some light on this (all moaning is prefixed with kobject_uevent_env, so it should be easy to spot)...

I applied the debug patch, but I don't see any error codes being returned. This time I also got the General Protection Faults. An excerpt of the log is attached.

Quoted 2 lines · Larry Finger

I applied the debug patch, but I don't see any error codes being returned. This time I also got the General Protection Faults. An excerpt of the log is attached.

Hm, I think I have an idea about what happened.

The firmware class tried to suppress the first KOBJ_ADD uevent by returning -ENODEV in firmware_uevent if FW_STATUS_READY was not set. This only worked as long as the return code of kobject_uevent was not checked in device_add. hack-to-make-wireless-work.patch made that first uevent return successfully, but this possible triggered some udev rule too early, leading to firmware load failures.

The following (completely untested) patch uses uevent_suppress to stop the uevent from being generated during device_add. Does this work for you?

Quoted 11 lines · Larry Finger

Quoted 7 lines · Cornelia Huck

On Thu, 22 Mar 2007 07:23:06 -0500,

This would indicate that dev_uevent had been called. But how could kobject_uevent then return an error without moaning about an uevent() error code? Maybe the following debug patch could shed some light on this (all moaning is prefixed with kobject_uevent_env, so it should be easy to spot)...

I applied the debug patch, but I don't see any error codes being returned. This time I also got the General Protection Faults. An excerpt of the log is attached.

Hm, I think I have an idea about what happened.

The firmware class tried to suppress the first KOBJ_ADD uevent by returning -ENODEV in firmware_uevent if FW_STATUS_READY was not set. This only worked as long as the return code of kobject_uevent was not checked in device_add. hack-to-make-wireless-work.patch made that first uevent return successfully, but this possible triggered some udev rule too early, leading to firmware load failures.

The following (completely untested) patch uses uevent_suppress to stop the uevent from being generated during device_add. Does this work for you?

---
 drivers/base/firmware_class.c |    2 ++
 1 file changed, 2 insertions(+)

drivers/base/firmware_class.c +1 -0

@@ -333,6 +333,7 @@ static int fw_register_device(struct dev
 	f_dev->parent = device;
 	f_dev->class = &firmware_class;
 	dev_set_drvdata(f_dev, fw_priv);
+	f_dev->uevent_suppress = 1;
 	retval = device_register(f_dev);
 	if (retval) {
 		printk(KERN_ERR "%s: device_register failed\n",

Would I be right in guessing that this was all triggered by uevent-improve-error-checking-and-handling.patch?

If so, do you think I should labour on with uevent-improve-error-checking-and-handling.patch plus your fix, or should I drop the lot? (I'm inclined toward the latter, but I'm still not sure which patch(es) need to be dropped).

Quoted 2 lines · Andrew Morton

Would I be right in guessing that this was all triggered by uevent-improve-error-checking-and-handling.patch?

Looks like it, since it passed the uevent failures to the upper layer.

Quoted 4 lines

If so, do you think I should labour on with uevent-improve-error-checking-and-handling.patch plus your fix, or should I drop the lot? (I'm inclined toward the latter, but I'm still not sure which patch(es) need to be dropped).

This depends on what semantics uevent returning an error code should have. The firmware code was using it to suppress uevents, but uevent_suppress is a better idea now. So if we want uevent returning != 0 to imply "something really bad happened", all uevent functions have to be audited and those that work like firmware_uevent have to be converted to uevent_suppress. This would be cleaner, but I'm not sure it's worth the work.

Quoted 5 lines · On Mon, 26 Mar 2007 11:09:49 +0200 Cornelia Huck <[email protected]>…

Quoted 4 lines

If so, do you think I should labour on with uevent-improve-error-checking-and-handling.patch plus your fix, or should I drop the lot? (I'm inclined toward the latter, but I'm still not sure which patch(es) need to be dropped).

Quoted 7 lines

This depends on what semantics uevent returning an error code should have. The firmware code was using it to suppress uevents, but uevent_suppress is a better idea now. So if we want uevent returning != 0 to imply "something really bad happened", all uevent functions have to be audited and those that work like firmware_uevent have to be converted to uevent_suppress. This would be cleaner, but I'm not sure it's worth the work.

We're generally struggling to stay alive amongst all the bugs at present - I'll drop all those patches.

Quoted 14 lines · Andrew Morton

Quoted 5 lines · On Mon, 26 Mar 2007 11:09:49 +0200 Cornelia Huck <[email protected]>…

Quoted 4 lines

If so, do you think I should labour on with uevent-improve-error-checking-and-handling.patch plus your fix, or should I drop the lot? (I'm inclined toward the latter, but I'm still not sure which patch(es) need to be dropped).

Quoted 7 lines

This depends on what semantics uevent returning an error code should have. The firmware code was using it to suppress uevents, but uevent_suppress is a better idea now. So if we want uevent returning != 0 to imply "something really bad happened", all uevent functions have to be audited and those that work like firmware_uevent have to be converted to uevent_suppress. This would be cleaner, but I'm not sure it's worth the work.

Quoted 2 lines

We're generally struggling to stay alive amongst all the bugs at present - I'll drop all those patches.

My mistake, I wrote the guilty patch uevent-improve-error-checking-and-handling.patch assuming it was safe to treat the return value as an error code, since several uevent functions returns things like -ENOMEM.

Should I rework the patch as Cornelia suggests and resubmit later, when things have settled down a little?

Quoted 14 lines · Andrew Morton

Quoted 5 lines · On Mon, 26 Mar 2007 11:09:49 +0200 Cornelia Huck <[email protected]>…

Quoted 4 lines

If so, do you think I should labour on with uevent-improve-error-checking-and-handling.patch plus your fix, or should I drop the lot? (I'm inclined toward the latter, but I'm still not sure which patch(es) need to be dropped).

Quoted 7 lines

This depends on what semantics uevent returning an error code should have. The firmware code was using it to suppress uevents, but uevent_suppress is a better idea now. So if we want uevent returning != 0 to imply "something really bad happened", all uevent functions have to be audited and those that work like firmware_uevent have to be converted to uevent_suppress. This would be cleaner, but I'm not sure it's worth the work.

Quoted 2 lines

We're generally struggling to stay alive amongst all the bugs at present - I'll drop all those patches.

My mistake, I wrote the guilty patch uevent-improve-error-checking-and-handling.patch assuming it was safe to treat the return value as an error code, since several uevent functions returns things like -ENOMEM.

Should I rework the patch as Cornelia suggests and resubmit later, when things have settled down a little?

I don't see any point in deregistering a kernel device, if the event to userspace goes wrong, or a subsytem returns a non-zero value in the filter.

Checking the uevent return value, will not prevent any malfunction, usually this kind of "error handling" just prevents bringing up a whole subsystem, or booting-up a box, because the needed device does not exist at all.

Quoted 4 lines · Kay Sievers

Checking the uevent return value, will not prevent any malfunction, usually this kind of "error handling" just prevents bringing up a whole subsystem, or booting-up a box, because the needed device does not exist at all.

OK, if we consider uevents to be non-vital to a functioning device.

OTOH, I think using something like uevent_suppress (maybe via dev_uevent_filter?) is a saner way to suppress a uevent than to return an error code in the uevent function.

The reason for that original patch was that it is actually possible for the uevent functions to return -ENOMEM, the uevent buffer being statically allocated to BUFFER_SIZE (2048).

It used to be 1024 but that was not
always enough and it was doubled a while ago [1]. Using add_uevent_var() makes this less of a problem as such an overflow should be catched cleanly [2].

Quoted 11 lines · On Wed, 21 Mar 2007 15:22:25 -0500 Matt Mackall <[email protected]> wrote:

With the latest -mm, I'm now getting this:

Mar 21 15:06:52 cinder kernel: ipw2200: Detected Intel PRO/Wireless
2200BG Network Connection
Mar 21 15:06:52 cinder kernel: firmware_loading_store: unexpected
value (0)
Mar 21 15:06:52 cinder kernel: ipw2200: ipw2200-bss.fw
request_firmware failed:
Reason -2
Mar 21 15:06:52 cinder kernel: ipw2200: Unable to load firmware: -2
Mar 21 15:06:52 cinder kernel: ipw2200: failed to register network

Quoted 1 line

device

The firmware loading bug is caused by driver-core-handles-kobject_uevent-failure-while-device_add.patch

I've uploaded a revert patch to ftp://ftp.kernel.org/pub/linux/kernel/people/akpm/patches/2.6/2.6.21-rc4/2.6.21-rc4-mm1/hot-fixes/