Re: 2.6.17-rc2-mm1

Re: 2.6.17-rc2-mm1

[Andrew Morton]

(I did s/linux-kernel@google.com/linux-kernel@vger.kernel.org/)

Martin Bligh <mbligh@google.com> wrote:
>
> Still crashes in LTP on x86_64:
> (introduced in previous release)
> 
> http://test.kernel.org/abat/29674/debug/console.log

What a mess.  A doublefault inside an NMI watchdog timeout.  I think.  It's
hard to see.  Some CPUs are stuck on a CPU scheduler lock, others seem to
be stuck in flush_tlb_others.  One of these could be a consequence of the
other, or both could be a consequence of something else.

> Different panic on 2-way ppp64  blade, again during LTP.
> 
> http://test.kernel.org/abat/29675/debug/console.log
> 
>   Oops: Kernel access of bad area, sig: 11 [#1]
> SMP NR_CPUS=128 NUMA
> Modules linked in: evdev joydev st sr_mod ipv6 usbcore sg dm_mod
> NIP: C000000000048F0C LR: C0000000000AF854 CTR: 800000000000A984
> REGS: c0000000074af560 TRAP: 0300   Not tainted  (2.6.17-rc2-mm1-autokern1)
> MSR: 8000000000001032 <ME,IR,DR>  CR: 24002024  XER: 00000010
> DAR: C00001800056B0B0, DSISR: 0000000040010000
> TASK = c000000007460800[84] 'kswapd0' THREAD: c0000000074ac000 CPU: 1
> GPR00: 8000000000001032 C0000000074AF7E0 C000000000691420 C0000000007586A8
> GPR04: 000000000000000F 0000000000000000 0000000000000000 0000000000000000
> GPR08: C0000000FE80AAD8 C00001800056B080 0000000000000001 C0000000007586A8
> GPR12: 0000000024002024 C00000000056B280 0000000000000020 0000000000000020
> GPR16: 0000000000000020 0000000000000000 0000000000000000 000000000000000F
> GPR20: C0000000074AF860 0000000000000000 C0000000FFFF3098 0000000000000001
> GPR24: C0000000074AFE00 C00000000059FCC0 0000000000000001 C0000000007586A8
> GPR28: C000000000545680 0000000000000022 C0000000005A4DA8 C00000000056B080
> NIP [C000000000048F0C] .try_to_wake_up+0x98/0x598
> LR [C0000000000AF854] .add_to_swapped_list+0x23c/0x264
> Call Trace:
> [C0000000074AF7E0] [C0000000005A4DA8] 0xc0000000005a4da8 (unreliable)
> [C0000000074AF8F0] [C0000000000AF854] .add_to_swapped_list+0x23c/0x264
> [C0000000074AF990] [C000000000098290] .remove_mapping+0x88/0x174
> [C0000000074AFA20] [C000000000099340] .shrink_zone+0xc74/0xf9c
> [C0000000074AFD30] [C00000000009A008] .kswapd+0x3e4/0x54c
> [C0000000074AFED0] [C0000000000705C8] .kthread+0x174/0x1c4
> [C0000000074AFF90] [C000000000024AB0] .kernel_thread+0x4c/0x68
> Instruction dump:
> 3a810080 7d2000a6 79208042 f9340000 78008000 7c010164 e97b0008 ebfe8008
> eb9e8000 812b0010 79294da4 7d29fa14 <e8090030> 7fbc0214 7fa3eb78 4841f615
> -- 0:conmux-control -- time-stamp -- Apr/27/06  5:10:48 --

Well that's silly.  kswapd died trying to wake up kprefetchd.  That code's
bog-simple, so I'd assume something's gone wrong with a CPU scheduler data
structure.  So if there's a common strand here, it's breakage of sched data
structures by mtest01.   Let me see if I can provoke it here.

Re: 2.6.17-rc2-mm1

[Martin J. Bligh]

Andrew Morton wrote:
> (I did s/linux-kernel@google.com/linux-kernel@vger.kernel.org/)
> 
> Martin Bligh <mbligh@google.com> wrote:
> 
>>Still crashes in LTP on x86_64:
>>(introduced in previous release)
>>
>>http://test.kernel.org/abat/29674/debug/console.log
> 
> 
> What a mess.  A doublefault inside an NMI watchdog timeout.  I think.  It's
> hard to see.  Some CPUs are stuck on a CPU scheduler lock, others seem to
> be stuck in flush_tlb_others.  One of these could be a consequence of the
> other, or both could be a consequence of something else.

OK, well the latest one seems cleaner, on -rc3-mm1.
http://test.kernel.org/abat/30007/debug/console.log

Just has the double fault, with no NMI watchdog timeouts. Not that
it means any more to me, but still ;-) mtest01 seems to be able to
reproduce this every time, but I don't have an appropriate box here
to diagnose it with (this was a 4x Opteron inside IBM), and it's
definitely something in -mm that's not in mainline.

M.

double fault: 0000 [1] SMP
last sysfs file: /devices/pci0000:00/0000:00:06.0/resource
CPU 0
Modules linked in:
Pid: 20519, comm: mtest01 Not tainted 2.6.17-rc3-mm1-autokern1 #1
RIP: 0010:[<ffffffff8047c8b8>] <ffffffff8047c8b8>{__sched_text_start+1856}
RSP: 0000:0000000000000000  EFLAGS: 00010082
RAX: 0000000000000000 RBX: 0000000000000000 RCX: ffffffff805d9438
RDX: ffff8100db12c0d0 RSI: ffffffff805d9438 RDI: ffff8100db12c0d0
RBP: ffffffff805d9438 R08: 0000000000000000 R09: 0000000000000000
R10: 0000000000000000 R11: 0000000000000000 R12: 0000000000000000
R13: ffff8100e39bd440 R14: ffff810008003620 R15: 000002b02751726c
FS:  0000000000000000(0000) GS:ffffffff805fa000(0063) knlGS:00000000f7dd0460
CS:  0010 DS: 002b ES: 002b CR0: 000000008005003b
CR2: fffffffffffffff8 CR3: 00000000da399000 CR4: 00000000000006e0
Process mtest01 (pid: 20519, threadinfo ffff8100b1bb4000, task 
ffff8100db12c0d0)
Stack: ffffffff80579e20 ffff8100db12c0d0 0000000000000001 ffffffff80579f58
        0000000000000000 ffffffff80579e78 ffffffff8020b0b2 ffffffff80579f58
        0000000000000000 ffffffff80485520
Call Trace: <#DF> <ffffffff8020b0b2>{show_registers+140}
        <ffffffff8020b357>{__die+159} <ffffffff8020b3cc>{die+50}
        <ffffffff8020bba6>{do_double_fault+115} 
<ffffffff8020aa91>{double_fault+125}
        <ffffffff8047c8b8>{__sched_text_start+1856} <EOE>

Code: e8 4c ba d8 ff 65 48 8b 34 25 00 00 00 00 4c 8b 46 08 f0 41
RIP <ffffffff8047c8b8>{__sched_text_start+1856} RSP <0000000000000000>
  -- 0:conmux-control -- time-stamp -- May/01/06  3:54:37 --

Re: 2.6.17-rc2-mm1

[Andrew Morton]

"Martin J. Bligh" <mbligh@google.com> wrote:
>
> Andrew Morton wrote:
> > (I did s/linux-kernel@google.com/linux-kernel@vger.kernel.org/)
> > 
> > Martin Bligh <mbligh@google.com> wrote:
> > 
> >>Still crashes in LTP on x86_64:
> >>(introduced in previous release)
> >>
> >>http://test.kernel.org/abat/29674/debug/console.log
> > 
> > 
> > What a mess.  A doublefault inside an NMI watchdog timeout.  I think.  It's
> > hard to see.  Some CPUs are stuck on a CPU scheduler lock, others seem to
> > be stuck in flush_tlb_others.  One of these could be a consequence of the
> > other, or both could be a consequence of something else.
> 
> OK, well the latest one seems cleaner, on -rc3-mm1.
> http://test.kernel.org/abat/30007/debug/console.log
> 
> Just has the double fault, with no NMI watchdog timeouts. Not that
> it means any more to me, but still ;-) mtest01 seems to be able to
> reproduce this every time, but I don't have an appropriate box here
> to diagnose it with (this was a 4x Opteron inside IBM), and it's
> definitely something in -mm that's not in mainline.
> 
> M.
> 
> double fault: 0000 [1] SMP
> last sysfs file: /devices/pci0000:00/0000:00:06.0/resource
> CPU 0
> Modules linked in:
> Pid: 20519, comm: mtest01 Not tainted 2.6.17-rc3-mm1-autokern1 #1
> RIP: 0010:[<ffffffff8047c8b8>] <ffffffff8047c8b8>{__sched_text_start+1856}
> RSP: 0000:0000000000000000  EFLAGS: 00010082
> RAX: 0000000000000000 RBX: 0000000000000000 RCX: ffffffff805d9438
> RDX: ffff8100db12c0d0 RSI: ffffffff805d9438 RDI: ffff8100db12c0d0
> RBP: ffffffff805d9438 R08: 0000000000000000 R09: 0000000000000000
> R10: 0000000000000000 R11: 0000000000000000 R12: 0000000000000000
> R13: ffff8100e39bd440 R14: ffff810008003620 R15: 000002b02751726c
> FS:  0000000000000000(0000) GS:ffffffff805fa000(0063) knlGS:00000000f7dd0460
> CS:  0010 DS: 002b ES: 002b CR0: 000000008005003b
> CR2: fffffffffffffff8 CR3: 00000000da399000 CR4: 00000000000006e0
> Process mtest01 (pid: 20519, threadinfo ffff8100b1bb4000, task 
> ffff8100db12c0d0)
> Stack: ffffffff80579e20 ffff8100db12c0d0 0000000000000001 ffffffff80579f58
>         0000000000000000 ffffffff80579e78 ffffffff8020b0b2 ffffffff80579f58
>         0000000000000000 ffffffff80485520
> Call Trace: <#DF> <ffffffff8020b0b2>{show_registers+140}
>         <ffffffff8020b357>{__die+159} <ffffffff8020b3cc>{die+50}
>         <ffffffff8020bba6>{do_double_fault+115} 
> <ffffffff8020aa91>{double_fault+125}
>         <ffffffff8047c8b8>{__sched_text_start+1856} <EOE>
> 
> Code: e8 4c ba d8 ff 65 48 8b 34 25 00 00 00 00 4c 8b 46 08 f0 41
> RIP <ffffffff8047c8b8>{__sched_text_start+1856} RSP <0000000000000000>
>   -- 0:conmux-control -- time-stamp -- May/01/06  3:54:37 --

I was not able to reproduce this on the 4-way EMT64 machine.  Am a bit stuck.

Re: 2.6.17-rc2-mm1

[Martin Bligh]

>>double fault: 0000 [1] SMP
>>last sysfs file: /devices/pci0000:00/0000:00:06.0/resource
>>CPU 0
>>Modules linked in:
>>Pid: 20519, comm: mtest01 Not tainted 2.6.17-rc3-mm1-autokern1 #1
>>RIP: 0010:[<ffffffff8047c8b8>] <ffffffff8047c8b8>{__sched_text_start+1856}
>>RSP: 0000:0000000000000000  EFLAGS: 00010082
>>RAX: 0000000000000000 RBX: 0000000000000000 RCX: ffffffff805d9438
>>RDX: ffff8100db12c0d0 RSI: ffffffff805d9438 RDI: ffff8100db12c0d0
>>RBP: ffffffff805d9438 R08: 0000000000000000 R09: 0000000000000000
>>R10: 0000000000000000 R11: 0000000000000000 R12: 0000000000000000
>>R13: ffff8100e39bd440 R14: ffff810008003620 R15: 000002b02751726c
>>FS:  0000000000000000(0000) GS:ffffffff805fa000(0063) knlGS:00000000f7dd0460
>>CS:  0010 DS: 002b ES: 002b CR0: 000000008005003b
>>CR2: fffffffffffffff8 CR3: 00000000da399000 CR4: 00000000000006e0
>>Process mtest01 (pid: 20519, threadinfo ffff8100b1bb4000, task 
>>ffff8100db12c0d0)
>>Stack: ffffffff80579e20 ffff8100db12c0d0 0000000000000001 ffffffff80579f58
>>        0000000000000000 ffffffff80579e78 ffffffff8020b0b2 ffffffff80579f58
>>        0000000000000000 ffffffff80485520
>>Call Trace: <#DF> <ffffffff8020b0b2>{show_registers+140}
>>        <ffffffff8020b357>{__die+159} <ffffffff8020b3cc>{die+50}
>>        <ffffffff8020bba6>{do_double_fault+115} 
>><ffffffff8020aa91>{double_fault+125}
>>        <ffffffff8047c8b8>{__sched_text_start+1856} <EOE>
>>
>>Code: e8 4c ba d8 ff 65 48 8b 34 25 00 00 00 00 4c 8b 46 08 f0 41
>>RIP <ffffffff8047c8b8>{__sched_text_start+1856} RSP <0000000000000000>
>>  -- 0:conmux-control -- time-stamp -- May/01/06  3:54:37 --
> 
> 
> I was not able to reproduce this on the 4-way EMT64 machine.  Am a bit stuck.

OK, is there anything we could run this with that'd dump more info?
(eg debug patches or something). There's bugger all of use that I
can see in that stack (and why does __sched_text_start come up anyway,
is that an x86_64-ism ?). I suppose if we're really desperate, we can
play chop search, but that's very boring to try to do remotely ...

It's a couple-of-year-old 4x newisys box.

M.

Re: 2.6.17-rc2-mm1

[Badari Pulavarty]

On Mon, 2006-05-01 at 10:07 -0700, Andrew Morton wrote:
> "Martin J. Bligh" <mbligh@google.com> wrote:
> >
> > Andrew Morton wrote:
> > > (I did s/linux-kernel@google.com/linux-kernel@vger.kernel.org/)
> > > 
> > > Martin Bligh <mbligh@google.com> wrote:
> > > 
> > >>Still crashes in LTP on x86_64:
> > >>(introduced in previous release)
> > >>
> > >>http://test.kernel.org/abat/29674/debug/console.log
> > > 
> > > 
> > > What a mess.  A doublefault inside an NMI watchdog timeout.  I think.  It's
> > > hard to see.  Some CPUs are stuck on a CPU scheduler lock, others seem to
> > > be stuck in flush_tlb_others.  One of these could be a consequence of the
> > > other, or both could be a consequence of something else.
> > 
> > OK, well the latest one seems cleaner, on -rc3-mm1.
> > http://test.kernel.org/abat/30007/debug/console.log
> > 
> > Just has the double fault, with no NMI watchdog timeouts. Not that
> > it means any more to me, but still ;-) mtest01 seems to be able to
> > reproduce this every time, but I don't have an appropriate box here
> > to diagnose it with (this was a 4x Opteron inside IBM), and it's
> > definitely something in -mm that's not in mainline.
> > 
> > M.
> > 
> > double fault: 0000 [1] SMP
> > last sysfs file: /devices/pci0000:00/0000:00:06.0/resource
> > CPU 0
> > Modules linked in:
> > Pid: 20519, comm: mtest01 Not tainted 2.6.17-rc3-mm1-autokern1 #1
> > RIP: 0010:[<ffffffff8047c8b8>] <ffffffff8047c8b8>{__sched_text_start+1856}
> > RSP: 0000:0000000000000000  EFLAGS: 00010082
> > RAX: 0000000000000000 RBX: 0000000000000000 RCX: ffffffff805d9438
> > RDX: ffff8100db12c0d0 RSI: ffffffff805d9438 RDI: ffff8100db12c0d0
> > RBP: ffffffff805d9438 R08: 0000000000000000 R09: 0000000000000000
> > R10: 0000000000000000 R11: 0000000000000000 R12: 0000000000000000
> > R13: ffff8100e39bd440 R14: ffff810008003620 R15: 000002b02751726c
> > FS:  0000000000000000(0000) GS:ffffffff805fa000(0063) knlGS:00000000f7dd0460
> > CS:  0010 DS: 002b ES: 002b CR0: 000000008005003b
> > CR2: fffffffffffffff8 CR3: 00000000da399000 CR4: 00000000000006e0
> > Process mtest01 (pid: 20519, threadinfo ffff8100b1bb4000, task 
> > ffff8100db12c0d0)
> > Stack: ffffffff80579e20 ffff8100db12c0d0 0000000000000001 ffffffff80579f58
> >         0000000000000000 ffffffff80579e78 ffffffff8020b0b2 ffffffff80579f58
> >         0000000000000000 ffffffff80485520
> > Call Trace: <#DF> <ffffffff8020b0b2>{show_registers+140}
> >         <ffffffff8020b357>{__die+159} <ffffffff8020b3cc>{die+50}
> >         <ffffffff8020bba6>{do_double_fault+115} 
> > <ffffffff8020aa91>{double_fault+125}
> >         <ffffffff8047c8b8>{__sched_text_start+1856} <EOE>
> > 
> > Code: e8 4c ba d8 ff 65 48 8b 34 25 00 00 00 00 4c 8b 46 08 f0 41
> > RIP <ffffffff8047c8b8>{__sched_text_start+1856} RSP <0000000000000000>
> >   -- 0:conmux-control -- time-stamp -- May/01/06  3:54:37 --
> 
> I was not able to reproduce this on the 4-way EMT64 machine.  Am a bit stuck.

I ran mtest01 multiple times with various options on my 4-way AMD64 box.
So far couldn't reproduce the problem (2.6.17-rc3-mm1).

Are there any special config or test options you are testing with ?

Thanks,
Badari

Re: 2.6.17-rc2-mm1

[Martin Bligh]

> I ran mtest01 multiple times with various options on my 4-way AMD64 box.
> So far couldn't reproduce the problem (2.6.17-rc3-mm1).
> 
> Are there any special config or test options you are testing with ?

Config is here:

http://ftp.kernel.org/pub/linux/kernel/people/mbligh/config/abat/amd64

It's just doing "runalltests", I think.

M.

Re: 2.6.17-rc2-mm1

[Badari Pulavarty]

On Mon, 2006-05-01 at 10:26 -0700, Martin Bligh wrote:
> > I ran mtest01 multiple times with various options on my 4-way AMD64 box.
> > So far couldn't reproduce the problem (2.6.17-rc3-mm1).
> > 
> > Are there any special config or test options you are testing with ?
> 
> Config is here:
> 
> http://ftp.kernel.org/pub/linux/kernel/people/mbligh/config/abat/amd64
> 
> It's just doing "runalltests", I think.

FWIW, I tried your config file on my 4-way AMD64 (melody) box 
and ran latest "mtest01" fine.

I am now trying runalltests. I guess, its time to bi-sect :(

Thanks,
Badari

Re: 2.6.17-rc2-mm1

[Martin Bligh]

Badari Pulavarty wrote:
> On Mon, 2006-05-01 at 10:26 -0700, Martin Bligh wrote:
> 
>>>I ran mtest01 multiple times with various options on my 4-way AMD64 box.
>>>So far couldn't reproduce the problem (2.6.17-rc3-mm1).
>>>
>>>Are there any special config or test options you are testing with ?
>>
>>Config is here:
>>
>>http://ftp.kernel.org/pub/linux/kernel/people/mbligh/config/abat/amd64
>>
>>It's just doing "runalltests", I think.
> 
> 
> FWIW, I tried your config file on my 4-way AMD64 (melody) box 
> and ran latest "mtest01" fine.
> 
> I am now trying runalltests. I guess, its time to bi-sect :(

There was a panic on PPC64 during LTP too, but it seems to have gone
away with rc3-mm1. Not sure if it was really fixed, or just intermittent.

http://test.kernel.org/abat/29675/debug/console.log

M.

Re: 2.6.17-rc2-mm1

[Andy Whitcroft]

Martin Bligh wrote:
> Badari Pulavarty wrote:
> 
>> On Mon, 2006-05-01 at 10:26 -0700, Martin Bligh wrote:
>>
>>>> I ran mtest01 multiple times with various options on my 4-way AMD64
>>>> box.
>>>> So far couldn't reproduce the problem (2.6.17-rc3-mm1).
>>>>
>>>> Are there any special config or test options you are testing with ?
>>>
>>>
>>> Config is here:
>>>
>>> http://ftp.kernel.org/pub/linux/kernel/people/mbligh/config/abat/amd64
>>>
>>> It's just doing "runalltests", I think.
>>
>>
>>
>> FWIW, I tried your config file on my 4-way AMD64 (melody) box and ran
>> latest "mtest01" fine.
>>
>> I am now trying runalltests. I guess, its time to bi-sect :(
> 
> 
> There was a panic on PPC64 during LTP too, but it seems to have gone
> away with rc3-mm1. Not sure if it was really fixed, or just intermittent.
> 
> http://test.kernel.org/abat/29675/debug/console.log

I think its more intermittant than gone.  I've got another machine which
runs the same tests, and she threw a very similar failure on 2.6.18-rc3-mm1.

-apw

Re: 2.6.17-rc2-mm1

[Badari Pulavarty]

Andy Whitcroft wrote:

>Martin Bligh wrote:
>
>>Badari Pulavarty wrote:
>>
>>>On Mon, 2006-05-01 at 10:26 -0700, Martin Bligh wrote:
>>>
>>>>>I ran mtest01 multiple times with various options on my 4-way AMD64
>>>>>box.
>>>>>So far couldn't reproduce the problem (2.6.17-rc3-mm1).
>>>>>
>>>>>Are there any special config or test options you are testing with ?
>>>>>
>>>>
>>>>Config is here:
>>>>
>>>>http://ftp.kernel.org/pub/linux/kernel/people/mbligh/config/abat/amd64
>>>>
>>>>It's just doing "runalltests", I think.
>>>>
>>>
>>>
>>>FWIW, I tried your config file on my 4-way AMD64 (melody) box and ran
>>>latest "mtest01" fine.
>>>
>>>I am now trying runalltests. I guess, its time to bi-sect :(
>>>
>>
>>There was a panic on PPC64 during LTP too, but it seems to have gone
>>away with rc3-mm1. Not sure if it was really fixed, or just intermittent.
>>
>>http://test.kernel.org/abat/29675/debug/console.log
>>
>
>I think its more intermittant than gone.  I've got another machine which
>runs the same tests, and she threw a very similar failure on 2.6.18-rc3-mm1.
>
I ran whole LTP with 2.6.17-rc3-mm1 on my (2-way P710) Power box and
didn't see any crashes. I also ran LTP on AMD64 box without any crashes.

Thanks,
Badari

Re: 2.6.17-rc2-mm1

[Martin Bligh]

Andrew Morton wrote:
> "Martin J. Bligh" <mbligh@google.com> wrote:
> 
>>Andrew Morton wrote:
>>
>>>(I did s/linux-kernel@google.com/linux-kernel@vger.kernel.org/)
>>>
>>>Martin Bligh <mbligh@google.com> wrote:
>>>
>>>
>>>>Still crashes in LTP on x86_64:
>>>>(introduced in previous release)
>>>>
>>>>http://test.kernel.org/abat/29674/debug/console.log
>>>
>>>
>>>What a mess.  A doublefault inside an NMI watchdog timeout.  I think.  It's
>>>hard to see.  Some CPUs are stuck on a CPU scheduler lock, others seem to
>>>be stuck in flush_tlb_others.  One of these could be a consequence of the
>>>other, or both could be a consequence of something else.
>>
>>OK, well the latest one seems cleaner, on -rc3-mm1.
>>http://test.kernel.org/abat/30007/debug/console.log
>>
>>Just has the double fault, with no NMI watchdog timeouts. Not that
>>it means any more to me, but still ;-) mtest01 seems to be able to
>>reproduce this every time, but I don't have an appropriate box here
>>to diagnose it with (this was a 4x Opteron inside IBM), and it's
>>definitely something in -mm that's not in mainline.

Andy, any chance you could do another run on elm3b6 of ltp with:
2.6.17-rc3 + http://test.kernel.org/patches/2.6.17-rc3-mm1-64

Which is:

x86_64-add-compat_sys_vmsplice-and-use-it-in.patch
i386-x86-64-fix-acpi-disabled-lapic-handling.patch
x86_64-mm-defconfig-update.patch
x86_64-mm-phys-apicid.patch
x86_64-mm-memset-always-inline.patch
x86_64-mm-amd-core-cpuid.patch
x86_64-mm-amd-cpuid4.patch
x86_64-mm-alternatives.patch
x86_64-mm-pci-dma-cleanup.patch
x86_64-mm-ia32-unistd-cleanup.patch
x86_64-mm-large-bzimage.patch
x86_64-mm-topology-comment.patch
x86_64-mm-agp-select.patch
x86_64-mm-iommu_gart_bitmap-search-to-cross-next_bit.patch
x86_64-mm-new-compat-ptrace.patch
x86_64-mm-disable-agp-resource-check.patch
x86_64-mm-avoid-irq0-ioapic-pin-collision.patch
x86_64-mm-gart-direct-call.patch
x86_64-mm-new-northbridge.patch
x86_64-mm-iommu-warning.patch
x86_64-mm-serialize-assign_irq_vector-use-of-static-variables.patch
x86_64-mm-simplify-ioapic_register_intr.patch
x86_64-mm-i386-apic-overwrite.patch
x86_64-mm-i386-up-generic-arch.patch
x86_64-mm-iommu-enodev.patch
x86_64-mm-fix-die_lock-nesting.patch
x86_64-mm-add-nmi_exit-to-die_nmi.patch
x86_64-mm-compat-printk.patch
x86_64-mm-hotadd-reserve-fix-fix-fix.patch
x86_64-mm-compat-printk-fix.patch
x86_64-mm-new-northbridge-fix.patch
x86-64-calgary-iommu-introduce-iommu_detected.patch
x86-64-calgary-iommu-calgary-specific-bits.patch
x86-64-calgary-iommu-hook-it-in.patch
x86-64-check-for-valid-dma-data-direction-in-the-dma-api.patch

Thanks,

M.

Re: 2.6.17-rc2-mm1

[Martin Bligh]

> Andy, any chance you could do another run on elm3b6 of ltp with:
> 2.6.17-rc3 + http://test.kernel.org/patches/2.6.17-rc3-mm1-64
> 
> Which is:
> 
> x86_64-add-compat_sys_vmsplice-and-use-it-in.patch
> i386-x86-64-fix-acpi-disabled-lapic-handling.patch
> x86_64-mm-defconfig-update.patch
> x86_64-mm-phys-apicid.patch
> x86_64-mm-memset-always-inline.patch
> x86_64-mm-amd-core-cpuid.patch
> x86_64-mm-amd-cpuid4.patch
> x86_64-mm-alternatives.patch
> x86_64-mm-pci-dma-cleanup.patch
> x86_64-mm-ia32-unistd-cleanup.patch
> x86_64-mm-large-bzimage.patch
> x86_64-mm-topology-comment.patch
> x86_64-mm-agp-select.patch
> x86_64-mm-iommu_gart_bitmap-search-to-cross-next_bit.patch
> x86_64-mm-new-compat-ptrace.patch
> x86_64-mm-disable-agp-resource-check.patch
> x86_64-mm-avoid-irq0-ioapic-pin-collision.patch
> x86_64-mm-gart-direct-call.patch
> x86_64-mm-new-northbridge.patch
> x86_64-mm-iommu-warning.patch
> x86_64-mm-serialize-assign_irq_vector-use-of-static-variables.patch
> x86_64-mm-simplify-ioapic_register_intr.patch
> x86_64-mm-i386-apic-overwrite.patch
> x86_64-mm-i386-up-generic-arch.patch
> x86_64-mm-iommu-enodev.patch
> x86_64-mm-fix-die_lock-nesting.patch
> x86_64-mm-add-nmi_exit-to-die_nmi.patch
> x86_64-mm-compat-printk.patch
> x86_64-mm-hotadd-reserve-fix-fix-fix.patch
> x86_64-mm-compat-printk-fix.patch
> x86_64-mm-new-northbridge-fix.patch
> x86-64-calgary-iommu-introduce-iommu_detected.patch
> x86-64-calgary-iommu-calgary-specific-bits.patch
> x86-64-calgary-iommu-hook-it-in.patch
> x86-64-check-for-valid-dma-data-direction-in-the-dma-api.patch

It worked fine with this lot. Hmmm. I guess that makes sense, if it's
the same issue that intermittently occurs on ppc64 (and perhaps it's
easier to diagnose there, since we get better stack tracing).

M.

Re: 2.6.17-rc2-mm1

[Andi Kleen]

On Monday 01 May 2006 16:24, Martin J. Bligh wrote:

> double fault: 0000 [1] SMP
> last sysfs file: /devices/pci0000:00/0000:00:06.0/resource
> CPU 0
> Modules linked in:
> Pid: 20519, comm: mtest01 Not tainted 2.6.17-rc3-mm1-autokern1 #1
> RIP: 0010:[<ffffffff8047c8b8>] <ffffffff8047c8b8>{__sched_text_start+1856}
> RSP: 0000:0000000000000000  EFLAGS: 00010082
> RAX: 0000000000000000 RBX: 0000000000000000 RCX: ffffffff805d9438
> RDX: ffff8100db12c0d0 RSI: ffffffff805d9438 RDI: ffff8100db12c0d0
> RBP: ffffffff805d9438 R08: 0000000000000000 R09: 0000000000000000
> R10: 0000000000000000 R11: 0000000000000000 R12: 0000000000000000
> R13: ffff8100e39bd440 R14: ffff810008003620 R15: 000002b02751726c
> FS:  0000000000000000(0000) GS:ffffffff805fa000(0063) knlGS:00000000f7dd0460
> CS:  0010 DS: 002b ES: 002b CR0: 000000008005003b
> CR2: fffffffffffffff8 CR3: 00000000da399000 CR4: 00000000000006e0
> Process mtest01 (pid: 20519, threadinfo ffff8100b1bb4000, task 
> ffff8100db12c0d0)
> Stack: ffffffff80579e20 ffff8100db12c0d0 0000000000000001 ffffffff80579f58
>         0000000000000000 ffffffff80579e78 ffffffff8020b0b2 ffffffff80579f58
>         0000000000000000 ffffffff80485520
> Call Trace: <#DF> <ffffffff8020b0b2>{show_registers+140}
>         <ffffffff8020b357>{__die+159} <ffffffff8020b3cc>{die+50}
>         <ffffffff8020bba6>{do_double_fault+115} 
> <ffffffff8020aa91>{double_fault+125}
>         <ffffffff8047c8b8>{__sched_text_start+1856} <EOE>

That's really strange - i wonder why the backtracer can't find the original
stack. Should probably add some printk diagnosis here.

Can you send the output with this patch?

Index: linux/arch/x86_64/kernel/traps.c
===================================================================
--- linux.orig/arch/x86_64/kernel/traps.c
+++ linux/arch/x86_64/kernel/traps.c
@@ -238,6 +238,7 @@ void show_trace(unsigned long *stack)
 			HANDLE_STACK (stack < estack_end);
 			i += printk(" <EOE>");
 			stack = (unsigned long *) estack_end[-2];
+			printk("new stack %lx (%lx %lx %lx %lx %lx)\n", stack, estack_end[0], estack_end[-1], estack_end[-2], estack_end[-3], estack_end[-4]);
 			continue;
 		}
 		if (irqstack_end) {

Re: 2.6.17-rc2-mm1

[Andy Whitcroft]

Andi Kleen wrote:
> On Monday 01 May 2006 16:24, Martin J. Bligh wrote:
> 
> 
>>double fault: 0000 [1] SMP
>>last sysfs file: /devices/pci0000:00/0000:00:06.0/resource
>>CPU 0
>>Modules linked in:
>>Pid: 20519, comm: mtest01 Not tainted 2.6.17-rc3-mm1-autokern1 #1
>>RIP: 0010:[<ffffffff8047c8b8>] <ffffffff8047c8b8>{__sched_text_start+1856}
>>RSP: 0000:0000000000000000  EFLAGS: 00010082
>>RAX: 0000000000000000 RBX: 0000000000000000 RCX: ffffffff805d9438
>>RDX: ffff8100db12c0d0 RSI: ffffffff805d9438 RDI: ffff8100db12c0d0
>>RBP: ffffffff805d9438 R08: 0000000000000000 R09: 0000000000000000
>>R10: 0000000000000000 R11: 0000000000000000 R12: 0000000000000000
>>R13: ffff8100e39bd440 R14: ffff810008003620 R15: 000002b02751726c
>>FS:  0000000000000000(0000) GS:ffffffff805fa000(0063) knlGS:00000000f7dd0460
>>CS:  0010 DS: 002b ES: 002b CR0: 000000008005003b
>>CR2: fffffffffffffff8 CR3: 00000000da399000 CR4: 00000000000006e0
>>Process mtest01 (pid: 20519, threadinfo ffff8100b1bb4000, task 
>>ffff8100db12c0d0)
>>Stack: ffffffff80579e20 ffff8100db12c0d0 0000000000000001 ffffffff80579f58
>>        0000000000000000 ffffffff80579e78 ffffffff8020b0b2 ffffffff80579f58
>>        0000000000000000 ffffffff80485520
>>Call Trace: <#DF> <ffffffff8020b0b2>{show_registers+140}
>>        <ffffffff8020b357>{__die+159} <ffffffff8020b3cc>{die+50}
>>        <ffffffff8020bba6>{do_double_fault+115} 
>><ffffffff8020aa91>{double_fault+125}
>>        <ffffffff8047c8b8>{__sched_text_start+1856} <EOE>
> 
> 
> That's really strange - i wonder why the backtracer can't find the original
> stack. Should probably add some printk diagnosis here.
> 
> Can you send the output with this patch?

Submitted, they should show up in teh matrix forthwith.  Will drop you
the output when done.

-apw

Re: 2.6.17-rc2-mm1

[Martin Bligh]

> That's really strange - i wonder why the backtracer can't find the original
> stack. Should probably add some printk diagnosis here.
> 
> Can you send the output with this patch?
> 
> Index: linux/arch/x86_64/kernel/traps.c
> ===================================================================
> --- linux.orig/arch/x86_64/kernel/traps.c
> +++ linux/arch/x86_64/kernel/traps.c
> @@ -238,6 +238,7 @@ void show_trace(unsigned long *stack)
>  			HANDLE_STACK (stack < estack_end);
>  			i += printk(" <EOE>");
>  			stack = (unsigned long *) estack_end[-2];
> +			printk("new stack %lx (%lx %lx %lx %lx %lx)\n", stack, estack_end[0], estack_end[-1], estack_end[-2], estack_end[-3], estack_end[-4]);
>  			continue;
>  		}
>  		if (irqstack_end) {

Thanks for running this Andy:

http://test.kernel.org/abat/30183/debug/console.log

Re: 2.6.17-rc2-mm1

[Andi Kleen]

On Tuesday 02 May 2006 22:00, Martin Bligh wrote:

> > Index: linux/arch/x86_64/kernel/traps.c
> > ===================================================================
> > --- linux.orig/arch/x86_64/kernel/traps.c
> > +++ linux/arch/x86_64/kernel/traps.c
> > @@ -238,6 +238,7 @@ void show_trace(unsigned long *stack)
> >  			HANDLE_STACK (stack < estack_end);
> >  			i += printk(" <EOE>");
> >  			stack = (unsigned long *) estack_end[-2];
> > +			printk("new stack %lx (%lx %lx %lx %lx %lx)\n", stack, estack_end[0], estack_end[-1], estack_end[-2], estack_end[-3], estack_end[-4]);
> >  			continue;
> >  		}
> >  		if (irqstack_end) {
> 
> Thanks for running this Andy:
> 
> http://test.kernel.org/abat/30183/debug/console.log


<EOE>new stack 0 (0 0 0 10082 10)

Hmm weird. There isn't anything resembling an exception frame at the top of the
stack.  No idea how this could happen.

-Andi

Re: 2.6.17-rc2-mm1

[Jan Beulich]

>>> Andi Kleen <ak@suse.de> 02.05.06 22:09 >>>
>On Tuesday 02 May 2006 22:00, Martin Bligh wrote:
>
>> > Index: linux/arch/x86_64/kernel/traps.c
>> > ===================================================================
>> > --- linux.orig/arch/x86_64/kernel/traps.c
>> > +++ linux/arch/x86_64/kernel/traps.c
>> > @@ -238,6 +238,7 @@ void show_trace(unsigned long *stack)
>> >  			HANDLE_STACK (stack < estack_end);
>> >  			i += printk(" <EOE>");
>> >  			stack = (unsigned long *) estack_end[-2];
>> > +			printk("new stack %lx (%lx %lx %lx %lx %lx)\n", stack, estack_end[0], estack_end[-1],
estack_end[-2], estack_end[-3], estack_end[-4]);
>> >  			continue;
>> >  		}
>> >  		if (irqstack_end) {
>> 
>> Thanks for running this Andy:
>> 
>> http://test.kernel.org/abat/30183/debug/console.log 
>
>
><EOE>new stack 0 (0 0 0 10082 10)

Looks like <rubbish> <SS> <RSP> <RFLAGS> <CS> to me, ...

>Hmm weird. There isn't anything resembling an exception frame at the top of the
>stack.  No idea how this could happen.

... which is a valid frame where the stack pointer was corrupted before the exception occurred. One more printed item
(or rather, starting items at estack_end[-1]) would allow at least seeing what RIP this came from.

This actually points out another weakness of that code: if you pick up a mis-aligned stack pointer then the conditions
in both the exception and interrupt stack invocations of HANDLE_STACK() won't prevent you from accessing an item
crossing a page boundary, and hence potentially faulting. Similarly, obtaining an entirely bad stack pointer anywhere in
that code will result in a fault. I guess the stack reads should really be done using get_user() or some other code
having recovery attached.

Jan

Re: 2.6.17-rc2-mm1

[Andi Kleen]

On Wednesday 03 May 2006 08:47, Jan Beulich wrote:
> >>> Andi Kleen <ak@suse.de> 02.05.06 22:09 >>>
> >On Tuesday 02 May 2006 22:00, Martin Bligh wrote:
> >
> >> > Index: linux/arch/x86_64/kernel/traps.c
> >> > ===================================================================
> >> > --- linux.orig/arch/x86_64/kernel/traps.c
> >> > +++ linux/arch/x86_64/kernel/traps.c
> >> > @@ -238,6 +238,7 @@ void show_trace(unsigned long *stack)
> >> >  			HANDLE_STACK (stack < estack_end);
> >> >  			i += printk(" <EOE>");
> >> >  			stack = (unsigned long *) estack_end[-2];
> >> > +			printk("new stack %lx (%lx %lx %lx %lx %lx)\n", stack, estack_end[0], estack_end[-1],
> estack_end[-2], estack_end[-3], estack_end[-4]);
> >> >  			continue;
> >> >  		}
> >> >  		if (irqstack_end) {
> >> 
> >> Thanks for running this Andy:
> >> 
> >> http://test.kernel.org/abat/30183/debug/console.log 
> >
> >
> ><EOE>new stack 0 (0 0 0 10082 10)
> 
> Looks like <rubbish> <SS> <RSP> <RFLAGS> <CS> to me, ...

Hmm, right.
 
> >Hmm weird. There isn't anything resembling an exception frame at the top of the
> >stack.  No idea how this could happen.
> 
> ... which is a valid frame where the stack pointer was corrupted before the exception occurred. One more printed item
> (or rather, starting items at estack_end[-1]) would allow at least seeing what RIP this came from.

Any can you add that please and check? 

Also worst case one could dump last branch pointers. AMD unfortunately only has four,
on Intel with 16 it's easier.

I can provide a patch for that if needed.

> This actually points out another weakness of that code: if you pick up a mis-aligned stack pointer then the conditions
> in both the exception and interrupt stack invocations of HANDLE_STACK() won't prevent you from accessing an item
> crossing a page boundary, and hence potentially faulting. 

Yes it probably should check for that.

> Similarly, obtaining an entirely bad stack pointer anywhere in 
> that code will result in a fault. I guess the stack reads should really be done using get_user() or some other code
> having recovery attached.

That can cause recursive exceptions. I'm a bit paranoid with that.

-Andi

Re: 2.6.17-rc2-mm1

[Jan Beulich]

>> ><EOE>new stack 0 (0 0 0 10082 10)
>> 
>> Looks like <rubbish> <SS> <RSP> <RFLAGS> <CS> to me, ...
>
>Hmm, right.
> 
>> >Hmm weird. There isn't anything resembling an exception frame at the top of the
>> >stack.  No idea how this could happen.
>> 
>> ... which is a valid frame where the stack pointer was corrupted before the exception occurred. One more printed
item
>> (or rather, starting items at estack_end[-1]) would allow at least seeing what RIP this came from.
>
>Any can you add that please and check? 

???

>Also worst case one could dump last branch pointers. AMD unfortunately only has four,
>on Intel with 16 it's easier.

Provided you disable recording early enough. Otherwise only one (last exception from/to) is going to be useful on
both.

>I can provide a patch for that if needed.
>
>> This actually points out another weakness of that code: if you pick up a mis-aligned stack pointer then the
conditions
>> in both the exception and interrupt stack invocations of HANDLE_STACK() won't prevent you from accessing an item
>> crossing a page boundary, and hence potentially faulting. 
>
>Yes it probably should check for that.
>
>> Similarly, obtaining an entirely bad stack pointer anywhere in 
>> that code will result in a fault. I guess the stack reads should really be done using get_user() or some other code
>> having recovery attached.
>
>That can cause recursive exceptions. I'm a bit paranoid with that.

Without doing so it can also cause recursive exceptions, just that this is going to be deadly then.

Jan

Re: 2.6.17-rc2-mm1

[Andi Kleen]

On Wednesday 03 May 2006 09:08, Jan Beulich wrote:
> >> ><EOE>new stack 0 (0 0 0 10082 10)
> >> 
> >> Looks like <rubbish> <SS> <RSP> <RFLAGS> <CS> to me, ...
> >
> >Hmm, right.
> > 
> >> >Hmm weird. There isn't anything resembling an exception frame at the top of the
> >> >stack.  No idea how this could happen.
> >> 
> >> ... which is a valid frame where the stack pointer was corrupted before the exception occurred. One more printed
> item
> >> (or rather, starting items at estack_end[-1]) would allow at least seeing what RIP this came from.
> >
> >Any can you add that please and check? 
> ???

Sorry I meant to write Andy but left out the d :-( - he did the testing
on the machine that showed the problem.

> 

> 
> >Also worst case one could dump last branch pointers. AMD unfortunately only has four,
> >on Intel with 16 it's easier.
> 
> Provided you disable recording early enough. Otherwise only one (last exception from/to) is going to be useful on
> both.

i usually just saved them as first thing in the exception entry point.

> >That can cause recursive exceptions. I'm a bit paranoid with that.
> 
> Without doing so it can also cause recursive exceptions, just that this is going to be deadly then.

Hmm point.

-Andi

 

Re: 2.6.17-rc2-mm1

[Andy Whitcroft]

Andi Kleen wrote:
> On Wednesday 03 May 2006 09:08, Jan Beulich wrote:
> 
>>>>><EOE>new stack 0 (0 0 0 10082 10)
>>>>
>>>>Looks like <rubbish> <SS> <RSP> <RFLAGS> <CS> to me, ...
>>>
>>>Hmm, right.
>>>
>>>
>>>>>Hmm weird. There isn't anything resembling an exception frame at the top of the
>>>>>stack.  No idea how this could happen.
>>>>
>>>>... which is a valid frame where the stack pointer was corrupted before the exception occurred. One more printed
>>
>>item
>>
>>>>(or rather, starting items at estack_end[-1]) would allow at least seeing what RIP this came from.
>>>
>>>Any can you add that please and check? 
>>
>>???
> 
> 
> Sorry I meant to write Andy but left out the d :-( - he did the testing
> on the machine that showed the problem.

Heh, happy to do the testing.  Just to make sure I am doing the right
thing, you want an entire stack frame dropped out in the case that
SS/RSP are 0; so we get the RIP.

-apw

Re: 2.6.17-rc2-mm1

[Jan Beulich]

>Heh, happy to do the testing.  Just to make sure I am doing the right
>thing, you want an entire stack frame dropped out in the case that
>SS/RSP are 0; so we get the RIP.

Just decrement the indices in the previous printk() by one each, i.e. ranging from -1 to -5.

Jan

Re: 2.6.17-rc2-mm1

[Andy Whitcroft]

Andi Kleen wrote:
> On Wednesday 03 May 2006 08:47, Jan Beulich wrote:
> 
>>>>>Andi Kleen <ak@suse.de> 02.05.06 22:09 >>>
>>>
>>>On Tuesday 02 May 2006 22:00, Martin Bligh wrote:
>>>
>>>
>>>>>Index: linux/arch/x86_64/kernel/traps.c
>>>>>===================================================================
>>>>>--- linux.orig/arch/x86_64/kernel/traps.c
>>>>>+++ linux/arch/x86_64/kernel/traps.c
>>>>>@@ -238,6 +238,7 @@ void show_trace(unsigned long *stack)
>>>>> 			HANDLE_STACK (stack < estack_end);
>>>>> 			i += printk(" <EOE>");
>>>>> 			stack = (unsigned long *) estack_end[-2];
>>>>>+			printk("new stack %lx (%lx %lx %lx %lx %lx)\n", stack, estack_end[0], estack_end[-1],
>>
>>estack_end[-2], estack_end[-3], estack_end[-4]);
>>
>>>>> 			continue;
>>>>> 		}
>>>>> 		if (irqstack_end) {
>>>>
>>>>Thanks for running this Andy:
>>>>
>>>>http://test.kernel.org/abat/30183/debug/console.log 
>>>
>>>
>>><EOE>new stack 0 (0 0 0 10082 10)
>>
>>Looks like <rubbish> <SS> <RSP> <RFLAGS> <CS> to me, ...
> 
> 
> Hmm, right.
>  
> 
>>>Hmm weird. There isn't anything resembling an exception frame at the top of the
>>>stack.  No idea how this could happen.
>>
>>... which is a valid frame where the stack pointer was corrupted before the exception occurred. One more printed item
>>(or rather, starting items at estack_end[-1]) would allow at least seeing what RIP this came from.
> 
> 
> Any can you add that please and check? 

Ok.  Just got some results (in full at the end of the message).  Seems
that this is indeed a stack frame:

	new stack 0 (0 0 10046 10 ffffffff8047c8e8)

And if my reading of the System.map is right, this is _just_ in schedule.

ffffffff8047c17e T sha_init
ffffffff8047c1a8 T __sched_text_start
ffffffff8047c1a8 T schedule
ffffffff8047c8ed T thread_return
ffffffff8047c9be T wait_for_completion
ffffffff8047caa8 T wait_for_completion_timeout

By the looks of it that would make it here, at the call __switch_to?
Which of course makes loads of sense _if_ the loaded stack pointer was
crap say 0.

#define switch_to(prev,next,last) \
        asm volatile(SAVE_CONTEXT     \
                     "movq %%rsp,%P[threadrsp](%[prev])\n\t" /* save RSP
*/   \
                     "movq %P[threadrsp](%[next]),%%rsp\n\t" /* restore
RSP */   \
                     "call __switch_to\n\t"   \
                     ".globl thread_return\n" \
                     "thread_return:\n\t"

I'll go shove some debug in there and see what pops out.
-apw

double fault: 0000 [1] SMP
last sysfs file: /devices/pci0000:00/0000:00:06.0/resource
CPU 0
Modules linked in:
Pid: 228, comm: kswapd0 Tainted: G   M  2.6.17-rc3-mm1-autokern1 #1
RIP: 0010:[<ffffffff8047c8e8>] <ffffffff8047c8e8>{__sched_text_start+1856}
RSP: 0000:0000000000000000  EFLAGS: 00010046
RAX: 0000000000000001 RBX: 0000000000000000 RCX: ffffffff805d9438
RDX: ffff8100e3d4a090 RSI: ffffffff805d9438 RDI: ffff8100e3d4a090
RBP: ffffffff805d9438 R08: 0000000000000001 R09: ffff8101001c9da8
R10: 0000000000000002 R11: 000000000000004d R12: ffffffff805013c0
R13: ffff8100013dc8c0 R14: ffff810008003620 R15: 000002a75ef255cc
FS:  0000000000000000(0000) GS:ffffffff805fa000(0000) knlGS:00000000f7e0b460
CS:  0010 DS: 0018 ES: 0018 CR0: 000000008005003b
CR2: fffffffffffffff8 CR3: 000000006b004000 CR4: 00000000000006e0
Process kswapd0 (pid: 228, threadinfo ffff8101001c8000, task
ffff8100e3d4a090)
Stack: ffffffff80579e20 ffff8100e3d4a090 0000000000000001 ffffffff80579f58
       0000000000000000 ffffffff80579e78 ffffffff8020b0e3 ffffffff80579f58
       0000000000000000 ffffffff80485520
Call Trace: <#DF> <ffffffff8020b0e3>{show_registers+140}
       <ffffffff8020b388>{__die+159} <ffffffff8020b3fd>{die+50}
       <ffffffff8020bbd9>{do_double_fault+115}
<ffffffff8020aa91>{double_fault+125}
       <ffffffff8047c8e8>{__sched_text_start+1856} <EOE>new stack 0 (0 0
10046 10 ffffffff8047c8e8)


Code: e8 1c ba d8 ff 65 48 8b 34 25 00 00 00 00 4c 8b 46 08 f0 41
RIP <ffffffff8047c8e8>{__sched_text_start+1856} RSP <0000000000000000>

Re: 2.6.17-rc2-mm1

[Andy Whitcroft]

Andy Whitcroft wrote:
> Andi Kleen wrote:
> 
>>On Wednesday 03 May 2006 08:47, Jan Beulich wrote:
>>
>>
>>>>>>Andi Kleen <ak@suse.de> 02.05.06 22:09 >>>
>>>>
>>>>On Tuesday 02 May 2006 22:00, Martin Bligh wrote:
>>>>
>>>>
>>>>
>>>>>>Index: linux/arch/x86_64/kernel/traps.c
>>>>>>===================================================================
>>>>>>--- linux.orig/arch/x86_64/kernel/traps.c
>>>>>>+++ linux/arch/x86_64/kernel/traps.c
>>>>>>@@ -238,6 +238,7 @@ void show_trace(unsigned long *stack)
>>>>>>			HANDLE_STACK (stack < estack_end);
>>>>>>			i += printk(" <EOE>");
>>>>>>			stack = (unsigned long *) estack_end[-2];
>>>>>>+			printk("new stack %lx (%lx %lx %lx %lx %lx)\n", stack, estack_end[0], estack_end[-1],
>>>
>>>estack_end[-2], estack_end[-3], estack_end[-4]);
>>>
>>>
>>>>>>			continue;
>>>>>>		}
>>>>>>		if (irqstack_end) {
>>>>>
>>>>>Thanks for running this Andy:
>>>>>
>>>>>http://test.kernel.org/abat/30183/debug/console.log 
>>>>
>>>>
>>>><EOE>new stack 0 (0 0 0 10082 10)
>>>
>>>Looks like <rubbish> <SS> <RSP> <RFLAGS> <CS> to me, ...
>>
>>
>>Hmm, right.
>> 
>>
>>
>>>>Hmm weird. There isn't anything resembling an exception frame at the top of the
>>>>stack.  No idea how this could happen.
>>>
>>>... which is a valid frame where the stack pointer was corrupted before the exception occurred. One more printed item
>>>(or rather, starting items at estack_end[-1]) would allow at least seeing what RIP this came from.
>>
>>
>>Any can you add that please and check? 
> 
> 
> Ok.  Just got some results (in full at the end of the message).  Seems
> that this is indeed a stack frame:
> 
> 	new stack 0 (0 0 10046 10 ffffffff8047c8e8)
> 
> And if my reading of the System.map is right, this is _just_ in schedule.
> 
> ffffffff8047c17e T sha_init
> ffffffff8047c1a8 T __sched_text_start
> ffffffff8047c1a8 T schedule
> ffffffff8047c8ed T thread_return
> ffffffff8047c9be T wait_for_completion
> ffffffff8047caa8 T wait_for_completion_timeout
> 
> By the looks of it that would make it here, at the call __switch_to?
> Which of course makes loads of sense _if_ the loaded stack pointer was
> crap say 0.

A quick patch to check for a 0 rsp triggers, so will try and find out
what the new process is.

-apw

Re: 2.6.17-rc2-mm1

[Andy Whitcroft]

Andy Whitcroft wrote:
> Andi Kleen wrote:
> 
>>On Wednesday 03 May 2006 08:47, Jan Beulich wrote:
>>
>>
>>>>>>Andi Kleen <ak@suse.de> 02.05.06 22:09 >>>
>>>>
>>>>On Tuesday 02 May 2006 22:00, Martin Bligh wrote:
>>>>
>>>>
>>>>
>>>>>>Index: linux/arch/x86_64/kernel/traps.c
>>>>>>===================================================================
>>>>>>--- linux.orig/arch/x86_64/kernel/traps.c
>>>>>>+++ linux/arch/x86_64/kernel/traps.c
>>>>>>@@ -238,6 +238,7 @@ void show_trace(unsigned long *stack)
>>>>>>			HANDLE_STACK (stack < estack_end);
>>>>>>			i += printk(" <EOE>");
>>>>>>			stack = (unsigned long *) estack_end[-2];
>>>>>>+			printk("new stack %lx (%lx %lx %lx %lx %lx)\n", stack, estack_end[0], estack_end[-1],
>>>
>>>estack_end[-2], estack_end[-3], estack_end[-4]);
>>>
>>>
>>>>>>			continue;
>>>>>>		}
>>>>>>		if (irqstack_end) {
>>>>>
>>>>>Thanks for running this Andy:
>>>>>
>>>>>http://test.kernel.org/abat/30183/debug/console.log 
>>>>
>>>>
>>>><EOE>new stack 0 (0 0 0 10082 10)
>>>
>>>Looks like <rubbish> <SS> <RSP> <RFLAGS> <CS> to me, ...
>>
>>
>>Hmm, right.
>> 
>>
>>
>>>>Hmm weird. There isn't anything resembling an exception frame at the top of the
>>>>stack.  No idea how this could happen.
>>>
>>>... which is a valid frame where the stack pointer was corrupted before the exception occurred. One more printed item
>>>(or rather, starting items at estack_end[-1]) would allow at least seeing what RIP this came from.
>>
>>
>>Any can you add that please and check? 
> 
> 
> Ok.  Just got some results (in full at the end of the message).  Seems
> that this is indeed a stack frame:
> 
> 	new stack 0 (0 0 10046 10 ffffffff8047c8e8)
> 
> And if my reading of the System.map is right, this is _just_ in schedule.
> 
> ffffffff8047c17e T sha_init
> ffffffff8047c1a8 T __sched_text_start
> ffffffff8047c1a8 T schedule
> ffffffff8047c8ed T thread_return
> ffffffff8047c9be T wait_for_completion
> ffffffff8047caa8 T wait_for_completion_timeout
> 
> By the looks of it that would make it here, at the call __switch_to?
> Which of course makes loads of sense _if_ the loaded stack pointer was
> crap say 0.
> 
> #define switch_to(prev,next,last) \
>         asm volatile(SAVE_CONTEXT     \
>                      "movq %%rsp,%P[threadrsp](%[prev])\n\t" /* save RSP
> */   \
>                      "movq %P[threadrsp](%[next]),%%rsp\n\t" /* restore
> RSP */   \
>                      "call __switch_to\n\t"   \
>                      ".globl thread_return\n" \
>                      "thread_return:\n\t"
> 
> I'll go shove some debug in there and see what pops out.


Ok.  I've been playing with this some.  Basically when we pick up the
new process to schedule it has a 0 rsp.  Dumping out the comm and flags
both reveal 0's throughout.  I tried another run poisoning the flags
field when freeing a task but the flags remain 0.

Anyone got any good ideas for patches to blame?

-apw

Re: 2.6.17-rc2-mm1

[Chuck Ebbert]

In-Reply-To: <445903DD.6090408@shadowen.org>

On Wed, 03 May 2006 20:26:21 +0100, Andy Whitcroft wrote:

>        <ffffffff8047c8e8>{__sched_text_start+1856} <EOE>new stack 0 (0 0
> 10046 10 ffffffff8047c8e8)

Wow.  The extra debug patch yields... exactly the same address that's
already being printed.

The real problem is that the stack-dump code prints the wrong symbol
name here.  I don't see any easy way to fix it other than to put some
filler at __sched_text_start so the first sched function has a unique
address.


-- 
Chuck
"Penguins don't come from next door, they come from the Antarctic!"

Re: 2.6.17-rc2-mm1

[Chuck Ebbert]

In-Reply-To: <445641EF.70601@google.com>

On Mon, 01 May 2006 10:14:23 -0700, Martin Bligh wrote:

> >>Code: e8 4c ba d8 ff 65 48 8b 34 25 00 00 00 00 4c 8b 46 08 f0 41
> >>RIP <ffffffff8047c8b8>{__sched_text_start+1856} RSP <0000000000000000>
> >>  -- 0:conmux-control -- time-stamp -- May/01/06  3:54:37 --
> > 
> > 
> > I was not able to reproduce this on the 4-way EMT64 machine.  Am a bit stuck.
> 
> OK, is there anything we could run this with that'd dump more info?
> (eg debug patches or something). There's bugger all of use that I
> can see in that stack (and why does __sched_text_start come up anyway,
> is that an x86_64-ism ?).

Look at your System.map and see if another symbol has the same address
as __sched_text_start.

I have:

ffffffff8042eb30 T io_schedule_timeout
ffffffff8042eb30 T __sched_text_start

-- 
Chuck
"Penguins don't come from next door, they come from the Antarctic!"

Re: 2.6.17-rc2-mm1

[Martin Bligh]

OK, one more time, cause I'm an idiot, and can't type.

--------------------------------

Still crashes in LTP on x86_64:
(introduced in previous release)

http://test.kernel.org/abat/29674/debug/console.log

Different panic on 2-way ppp64  blade, again during LTP.

http://test.kernel.org/abat/29675/debug/console.log

  Oops: Kernel access of bad area, sig: 11 [#1]
SMP NR_CPUS=128 NUMA
Modules linked in: evdev joydev st sr_mod ipv6 usbcore sg dm_mod
NIP: C000000000048F0C LR: C0000000000AF854 CTR: 800000000000A984
REGS: c0000000074af560 TRAP: 0300   Not tainted  (2.6.17-rc2-mm1-autokern1)
MSR: 8000000000001032 <ME,IR,DR>  CR: 24002024  XER: 00000010
DAR: C00001800056B0B0, DSISR: 0000000040010000
TASK = c000000007460800[84] 'kswapd0' THREAD: c0000000074ac000 CPU: 1
GPR00: 8000000000001032 C0000000074AF7E0 C000000000691420 C0000000007586A8
GPR04: 000000000000000F 0000000000000000 0000000000000000 0000000000000000
GPR08: C0000000FE80AAD8 C00001800056B080 0000000000000001 C0000000007586A8
GPR12: 0000000024002024 C00000000056B280 0000000000000020 0000000000000020
GPR16: 0000000000000020 0000000000000000 0000000000000000 000000000000000F
GPR20: C0000000074AF860 0000000000000000 C0000000FFFF3098 0000000000000001
GPR24: C0000000074AFE00 C00000000059FCC0 0000000000000001 C0000000007586A8
GPR28: C000000000545680 0000000000000022 C0000000005A4DA8 C00000000056B080
NIP [C000000000048F0C] .try_to_wake_up+0x98/0x598
LR [C0000000000AF854] .add_to_swapped_list+0x23c/0x264
Call Trace:
[C0000000074AF7E0] [C0000000005A4DA8] 0xc0000000005a4da8 (unreliable)
[C0000000074AF8F0] [C0000000000AF854] .add_to_swapped_list+0x23c/0x264
[C0000000074AF990] [C000000000098290] .remove_mapping+0x88/0x174
[C0000000074AFA20] [C000000000099340] .shrink_zone+0xc74/0xf9c
[C0000000074AFD30] [C00000000009A008] .kswapd+0x3e4/0x54c
[C0000000074AFED0] [C0000000000705C8] .kthread+0x174/0x1c4
[C0000000074AFF90] [C000000000024AB0] .kernel_thread+0x4c/0x68
Instruction dump:
3a810080 7d2000a6 79208042 f9340000 78008000 7c010164 e97b0008 ebfe8008
eb9e8000 812b0010 79294da4 7d29fa14 <e8090030> 7fbc0214 7fa3eb78 4841f615
-- 0:conmux-control -- time-stamp -- Apr/27/06  5:10:48 --

2.6.17-rc2-mm1

[Andrew Morton]

ftp://ftp.kernel.org/pub/linux/kernel/people/akpm/patches/2.6/2.6.17-rc2/2.6.17-rc2-mm1/


- It took six hours work to get this release building and linking in just a
  basic fashion on eight-odd architectures.  It's getting out of control.

  The acphphp driver is still broken and v4l and memory hotplug are, I
  suspect, only hanging in there by the skin of their teeth.

  Could patch submitters _please_ be a lot more careful about getting the
  Kconfig correct, testing various Kconfig combinations (yes sometimes
  people will want to disable your lovely new feature) and just generally
  think about these things a bit harder?  It isn't rocket science.

- Added the GFS tree to the -mm lineup as git-gfs2.patch .  The DLM patches
  were consequently dropped.



Boilerplate:

- See the `hot-fixes' directory for any important updates to this patchset.

- To fetch an -mm tree using git, use (for example)

  git fetch git://git.kernel.org/pub/scm/linux/kernel/git/smurf/linux-trees.git v2.6.16-rc2-mm1

- -mm kernel commit activity can be reviewed by subscribing to the
  mm-commits mailing list.

        echo "subscribe mm-commits" | mail majordomo@vger.kernel.org

- If you hit a bug in -mm and it is not obvious which patch caused it, it is
  most valuable if you can perform a bisection search to identify which patch
  introduced the bug.  Instructions for this process are at

        http://www.zip.com.au/~akpm/linux/patches/stuff/bisecting-mm-trees.txt

  But beware that this process takes some time (around ten rebuilds and
  reboots), so consider reporting the bug first and if we cannot immediately
  identify the faulty patch, then perform the bisection search.

- When reporting bugs, please try to Cc: the relevant maintainer and mailing
  list on any email.


Changes since 2.6.17-rc1-mm3:



 origin.patch
 git-acpi.patch
 git-agpgart.patch
 git-alsa.patch
 git-arm.patch
 git-cfq.patch
 git-dvb.patch
 git-gfs2.patch
 git-ieee1394.patch
 git-infiniband.patch
 git-input.patch
 git-intelfb.patch
 git-libata-all.patch
 git-mmc.patch
 git-mtd.patch
 git-netdev-all.patch
 git-nfs.patch
 git-ocfs2.patch
 git-powerpc.patch
 git-pcmcia.patch
 git-scsi-misc.patch
 git-scsi-rc-fixes.patch
 git-scsi-target.patch
 git-watchdog.patch
 git-xfs.patch
 git-cryptodev.patch
 git-viro-bird-m32r.patch
 git-viro-bird-m68k.patch
 git-viro-bird-frv.patch
 git-viro-bird-upf.patch
 git-viro-bird-volatile.patch 

 git trees

-uml-make-64-bit-cow-files-compatible-with-32-bit-ones.patch
-task-make-task-list-manipulations-rcu-safe.patch
-for_each_possible_cpu-x86_64.patch
-uml-madv_remove-fixes.patch
-m41t00-fix-bitmasks-when-writing-to-chip.patch
-swsusp-prevent-possible-image-corruption-on-resume.patch
-msi-k8t-neo2-fir-onboardsound-and-additional-soundcard.patch
-sound-fix-hang-in-mpu401_uartc.patch
-sound-fix-hang-in-mpu401_uartc-tidy.patch
-for_each_possible_cpu-for-arm.patch
-block-i-o-schedulers-document-runtime-selection.patch
-drivers-char-drm-drm_memoryc-possible-cleanups.patch
-drm-fix-further-issues-in-drivers-char-drm-via_irqc.patch
-sbp2-consolidate-workarounds.patch
-sbp2-add-read_capacity-workaround-for-ipod.patch
-sbp2-make-tsb42aa9-workaround-specific-to-momobay-cx-1.patch
-sbp2-add-ability-to-override-hardwired-blacklist.patch
-mtd-improve-parameter-parsing-for-block2mtd.patch
-mtd-improve-parameter-parsing-for-block2mtd-fix.patch
-bcm43xx-sysfs-code-cleanup.patch
-bcm43xx-fix-pctl-slowclock-limit-calculation.patch
-e1000-fix-media_type-phy_type-thinko.patch
-unaligned-access-in-sk_run_filter.patch
-nfs-make-2-functions-static.patch
-remove-needless-check-in-nfs_opendir.patch
-fix-nfs-proc_fs=n-compile-error.patch
-nfssunrpc-fix-compiler-warnings-if-config_proc_fs-config_sysctl-are-unset.patch
-nfs_show_stats-for_each_possible_cpu-not-nr_cpus.patch
-powerpc-pseries-bugfix-balance-calls-to-pci_device_put.patch
-powerpc-pseries-clear-pci-failure-counter-if-no-new-failures.patch
-serial-fix-uart_bug_txen-test.patch
-git-scsi-misc-scsi_kmap_atomic_sg-warning-fix.patch
-megaraid-unused-variable.patch
-scsi-megaraid-megaraid_mmc-fix-a-null-pointer-dereference.patch
-overrun-in-drivers-scsi-sim710c.patch
-aic7xxx-ahc_pci_write_config-fix.patch
-qla2xxx-only-free_irq-after-request_irq-succeeds.patch
-git-splice-fixup.patch
-ftdi_sio-adds-support-for-iplus-device.patch
-ipw2200-config_ipw_qos-to-config_ipw2200_qos.patch
-softmac-uses-wiress-ext.patch
-bcm43xx_phyc-fix-a-memory-leak.patch
-orinoco-remove-useless-cis-validation.patch
-orinoco-remove-pcmcia-audio-support-its-useless-for-wireless-cards.patch
-orinoco-remove-underscores-from-little-endian-field-names.patch
-orinoco-fix-truncating-commsquality-rid-with-the-latest-symbol-firmware.patch
-orinoco-remove-tracing-code-its-unused.patch
-orinoco-remove-debug-buffer-code-and-userspace-include-support.patch
-orinoco-symbol-card-supported-by-spectrum_cs-is-la4137-not-la4100.patch
-orinoco-optimize-tx-exception-handling-in-orinoco.patch
-orinoco-orinoco_xmit-should-only-return-valid-symbolic-constants.patch
-orinoco-replace-hermes_write_words-with-hermes_write_bytes.patch
-orinoco-dont-use-any-padding-for-tx-frames.patch
-orinoco-refactor-and-clean-up-tx-error-handling.patch
-orinoco-simplify-8023-encapsulation-code.patch
-orinoco-fix-bap0-offset-error-after-several-days-of-operation.patch
-orinoco-delay-fid-allocation-after-firmware-initialization.patch
-orinoco_pci-disable-device-and-free-irq-when-suspending.patch
-orinoco_pci-use-pci_iomap-for-resources.patch
-orinoco-support-pci-suspend-resume-for-nortel-plx-and-tmd-adaptors.patch
-orinoco-reduce-differences-between-pci-drivers-create-orinoco_pcih.patch
-orinoco-further-comment-cleanup-in-the-pci-drivers.patch
-orinoco-bump-version-to-015.patch
-bcm43-wireless-fix-printk-format-warnings.patch
-bcm43-fix-config-menu-alignment.patch
-x86_64-mm-kdump-trigger-points.patch
-x86_64-mm-increase-nodemap.patch
-x86_64-mm-new-syscalls.patch
-x86_64-mm-move-doublefault.patch
-x86_64-mm-alternatives-fix.patch
-arm-add_memory-build-fix.patch
-memory_hotplugh-cleanup.patch
-mm-slobc-for_each_possible_cpu-not-nr_cpus.patch
-oom-kill-mm-locking-fix.patch
-mm-fix-mm_struct-reference-counting-bugs-in-mm-oom_killc.patch
-page_allocc-buddy-handling-cleanup.patch
-hugetlbfs-add-kconfig-help-text.patch
-selinux-fix-mls-compatibility-off-by-one-bug.patch
-asm-i386-atomich-local_irq_save-should-be-used-instead-of-local_irq_disable.patch
-x86-cpuid-and-msr-notifier-callback-section-mismatches.patch
-patch-to-limit-present-cpus-to-fake-cpu-hot-add-testing.patch
-enable-sci_emulate-to-manually-simulate-physical-hotplug-testing.patch
-drivers-acpi-busc-make-struct-acpi_sci_dir-static.patch
-x86_64-use-select-for-gart_iommu-to-enable-agp.patch
-x86_64-sparsemem-does-not-need-node_mem_map.patch
-m32r-fix-pt_regs-for.patch
-m32r-update-include-asm-m32r-semaphoreh.patch
-m32r-mappi3-reboot-support.patch
-m32r-remove-a-warning-of-m32r_sioc.patch
-m32r-update-switch_to-macro-for-tuning.patch
-uml-change-sigjmp_buf-to-jmp_buf.patch
-uml-__user-annotations.patch
-uml-physical-memory-map-file-fixes.patch
-uml-add-missing-__volatile__.patch
-fix-file-lookup-without-ref.patch
-update-obsolete_oss_driver-schedule-and-dependencies.patch
-make-the-oss-sound_via82cxxx-option-available-again.patch
-kconfigdebug-set-debug_mutex-to-off-by-default.patch
-fs-fix-ocfs2-warning-when-debug_fs-is-not-enabled.patch
-voyager-no-need-to-define-bits_per_byte-when-its-already-in-typesh.patch
-apm-fix-armada-laptops-again.patch
-doc-vm-hugetlbpage-update-2.patch
-ipmi-fix-devinit-placement.patch
-config-update-usage-help-info.patch
-fix-potential-null-pointer-deref-in-gen_init_cpio.patch
-open-ipmi-bt-overflow.patch
-parport_pc-fix-section-mismatch-warnings-v2.patch
-pnp-fix-two-messages-in-managerc.patch
-fix-dependencies-of-hugetlb_page_size_64k.patch
-fix-dependencies-of-w1_slave_ds2433_crc.patch
-tpm-spacing-cleanups.patch
-tpm-reorganize-sysfs-files.patch
-tpm-chip-struct-update.patch
-tpm-return-chip-from-tpm_register_hardware.patch
-tpm-command-duration-update.patch
-tpm-new-12-sysfs-files.patch
-tpm-new-12-sysfs-files-fix.patch
-tpm-new-12-sysfs-files-fix-fix.patch
-tpm-tpm-new-12-sysfs-files-fix-fix-fix.patch
-tpm-driver-for-next-generation-tpm-chips.patch
-tpm-driver-for-next-generation-tpm-chips-fix.patch
-tpm-driver-for-next-generation-tpm-chips-fix-fix.patch
-tpm-msecs_to_jiffies-cleanups.patch
-tpm-use-clear_bit.patch
-tpm-use-clear_bit-fix.patch
-tpm-use-clear_bit-fix-fix.patch
-tpm-use-clear_bit-fix-fix-fix.patch
-tpm-use-clear_bit-fix-fix-fix-fix.patch
-tpm-tpm_infineon-updated-to-latest-interface-changes.patch
-tpm-check-mem-start-and-len.patch
-tpm-update-bios-log-code-for-12.patch
-tpm_infineon-section-fixup.patch
-bluetooth-fix-problem-with-sco.patch
-switch-kprobes-inline-functions-to-__kprobes-for-i386.patch
-switch-kprobes-inline-functions-to-__kprobes-for-x86_64.patch
-switch-kprobes-inline-functions-to-__kprobes-for-ppc64.patch
-switch-kprobes-inline-functions-to-__kprobes-for-ia64.patch
-switch-kprobes-inline-functions-to-__kprobes-for-sparc64.patch
-ide-ati-sb600-ide-support.patch
-remove-the-obsolete-idepci_flag_force_pdc.patch
-alim15x3-uli-m-1573-south-bridge-support.patch
-fb-fix-section-mismatch-in-savagefb.patch
-radeonfb-section-mismatches.patch
-savagefb-fix-section-mismatch-warnings.patch
-fbdev-fix-return-error-of-fb_write.patch
-remove-redundant-null-checks-before-free-in-net.patch

 Merged

+remove-softlockup-from-invalidate_mapping_pages.patch
+x25-fix-for-spinlock-recurse-and-spinlock-lockup-with.patch
+off-by-1-in-kernel-power-mainc.patch
+request_irq-remove-warnings-from-irq-probing.patch
+input-fix-oops-on-mk712-load.patch
+mv643xx_eth-provide-sysfs-class-device-symlink.patch
+s390-make-qeth-buildable.patch
+tpar-oops-fix.patch
+fix-array-overrun-in-drivers-char-mwave-mwaveddc.patch
+readd-the-oss-sound_cs4232-option.patch
+avoid-printing-pointless-tsc-skew-msgs.patch
+enable-x86_pc-for-hotplug_cpu.patch
+mark-vmsplit-embedded.patch
+kprobe-cleanup-for-vm_mask-judgement.patch
+kprobe-fix-resume-execution-on-i386.patch

 2.6.17 queue (mostly)

+acpiphp-use-new-dock-driver-fix.patch

 Fix acpiphp-use-new-dock-driver.patch

+fw-memory-leakages-in-driver-acpi-videoc.patch
+acpi-idle-__read_mostly-and-de-init-static-var.patch
+acpi-suppress-power-button-event-on-s3-resume.patch

 ACPI udpates

+remove-for_each_cpu.patch

 Remove for_each_cpu().

+alsa-pcmcia-sound-devices-shouldnt-depend-on-isa.patch
+alsa-rmmod-oops-fix.patch

 ALSA fixes

+iosched-use-hlist-for-request-hashtable.patch

 iosched cleanup

+gregkh-driver-frame-buffer-remove-cmap-sysfs-interface.patch
+gregkh-driver-kobject-fix-build-error.patch
+gregkh-driver-fix-ocfs2-warning-when-debug_fs-is-not-enabled.patch
+gregkh-driver-kobject-possible-cleanups.patch
+gregkh-driver-added-uri-of-linux-kernel-development-process.patch
+gregkh-driver-class-device-add-attribute_group-creation.patch
+gregkh-driver-netdev-create-attribute_groups-with-class_device_add.patch
+gregkh-driver-tty-return-class-device-pointer-from-tty_register_device.patch
+gregkh-driver-i4l-gigaset-move-sysfs-entry-to-tty-class-device.patch

 Driver tree updates

+gregkh-driver-spi-spi_bitbang-clocking-fixes.patch

 SPI fix

+netdev-hotplug-napi-race-cleanup.patch

 net cleanup

+dvb-core-ule-fixes-and-rfc4326-additions-kernel-2616.patch
+dvb-core-ule-fixes-and-rfc4326-additions-kernel-2616-tidy.patch

 DVB feature

+vivi-build-fix.patch
+git-dvb-Kconfig-fix.patch
+git-dvb-Kconfig-fix-2.patch

 git-dvb.patch is a bit sick.

+gregkh-i2c-rtc-add-support-for-m41t81-m41t85-chips-to-m41t00-driver.patch
+gregkh-i2c-i2c-piix4-remove-fix_hstcfg-parameter.patch
+gregkh-i2c-i2c-piix4-fix-typo-in-documentation.patch
+gregkh-i2c-i2c-piix4-improve-ibm-error-message.patch
+gregkh-i2c-i2c-nforce2-add-mcp51-mcp55-support.patch
+gregkh-i2c-hwmon-hdaps-update-id-list.patch
+gregkh-i2c-hwmon-w83791d-new-driver.patch
+gregkh-i2c-hwmon-lm83-documentation-update.patch
+gregkh-i2c-hwmon-improve-Kconfig-help.patch
+gregkh-i2c-hwmon-vid-mask-per-vrm.patch

 I2C tree updates.

+gregkh-i2c-w1-possible-cleanups.patch
+gregkh-i2c-w1-fix-dependencies-of-w1_slave_ds2433_crc.patch

 i2c cleanup and fix

-i2c-add-support-for-virtual-i2c-adapters-tidy.patch
-i2c-add-support-for-virtual-i2c-adapters-fix.patch

 Folded into i2c-add-support-for-virtual-i2c-adapters.patch

+i2c-mpc-fix-up-error-handling.patch
+opencores-i2c-bus-driver.patch
+opencores-i2c-bus-driver-tidy.patch
+opencores-i2c-bus-driver-fix.patch
+i2c-pca954x-fix-initial-access-to-first-mux-switch-port.patch

 I2C updates.

+smc911x-Kconfig-fix.patch
+via-rhine-zero-pad-short-packets-on-rhine-i-ethernet-cards.patch

 netdev updates

+net-use-hlist_unhashed.patch
+ipv4-inet_init-fs_initcall.patch

 net updates

+powerpc-pseries-avoid-crash-in-pci-code-if-mem-system-not-up.patch
+powerpc-pseries-avoid-crash-in-pci-code-if-mem-system-not-up-tidy.patch

 powerpc fix

+serial-fix-uart_bug_txen-test.patch

 serial fix (needs work)

-improve-pci-config-space-writeback-tidy.patch

 Folded into improve-pci-config-space-writeback.patch

+pci-quirk-via-irq-fixup-should-only-run-for-via-southbridges.patch
+reverse-pci-config-space-restore-order.patch

 PCI fixes

-revert-pci-pci-cardbus-cards-hidden-needs-pci=assign-busses-to-fix.patch

 Dropped

+drivers-scsi-fix-proc_scsi_write-to-return-length-on.patch
+drivers-scsi-sdc-fix-uninitialized-variable-in-handling-medium-errors.patch
+drivers-scsi-aic7xxx-possible-cleanups-2.patch
+scsi-remove-documentation-scsi-cpqfctxt.patch
+enable-advansys-driver.patch
+advansys-warning-workaround.patch
+scsi-clean-up-warnings-in-advansys-driver.patch
+scsi-clean-up-warnings-in-advansys-driver-fix.patch
+mpt-fusion-driver-initialization-failure-fix.patch

 SCSI fixes

-areca-raid-linux-scsi-driver-update4.patch
-areca-raid-linux-scsi-driver-update5.patch

 Foxled into areca-raid-linux-scsi-driver.patch.

+gregkh-usb-usb-resource-leak-fix-for-whiteheat-driver.patch
+gregkh-usb-usb-add-new-itegno-usb-cdma-1x-card-support-for-pl2303.patch
+gregkh-usb-usb-storage-unusual-devs-update.patch
+gregkh-usb-usb-storage-atmel-unusual-dev-update.patch
+gregkh-usb-usb-net2280-handle-stalls-for-0-length-control-in-requests.patch
+gregkh-usb-usb-net2280-send-0-length-packets-for-ep0.patch
+gregkh-usb-usb-net2280-check-for-shared-irqs.patch
+gregkh-usb-usb-net2280-set-driver-data-before-it-is-used.patch
+gregkh-usb-usb-use-new-pci_class_serial_usb_-defines.patch
+gregkh-usb-usb-ftdi_sio-vendor-code-for-rr-cirkits-locobuffer-usb.patch
+gregkh-usb-usb-ftdi_sio-adds-support-for-iplus-device.patch
+gregkh-usb-usb-ftdi_sio-add-support-for-ask-rdr-400-series-card-reader.patch
+gregkh-usb-usb-sisusbvga-possible-cleanups.patch
+gregkh-usb-usb-allow-multiple-types-of-ehci-controllers-to-be-built-as-modules.patch
+gregkh-usb-usb-console-fix-cr-lf-issues.patch
+gregkh-usb-usb-console-fix-oops.patch
+gregkh-usb-usb-console-prevent-enodev-on-node.patch
+gregkh-usb-usb-macbook-pro-touchpad-support.patch

 USB tree updates

+fix-sco-on-some-bluetooth-adapters.patch
+fix-sco-on-some-bluetooth-adapters-tidy.patch

 USB fix

+x86_64-mm-acpi-nolapic.patch
+x86_64-mm-ia32-unistd-cleanup.patch
+x86_64-mm-large-bzimage.patch
+x86_64-mm-topology-comment.patch
+x86_64-mm-agp-select.patch
+x86_64-mm-iommu_gart_bitmap-search-to-cross-next_bit.patch
+x86_64-mm-new-compat-ptrace.patch

 x86_64 tree updates

+gregkh-devfs-devfs-die-die-die.patch
+gregkh-devfs-devfs-remove-documentation.patch
+gregkh-devfs-devfs-scrub-partitions.patch
+gregkh-devfs-devfs-scrub-init.patch
+gregkh-devfs-devfs-remove-serial-subsystem.patch
+gregkh-devfs-devfs-remove-ide-subsystem.patch
+gregkh-devfs-devfs-remove-sound-subsystem.patch
+gregkh-devfs-devfs-remove-devfs-tape.patch
+gregkh-devfs-devfs-remove-devfs_mk_dir.patch
+gregkh-devfs-devfs-remove-devfs_mk_symlink.patch
+gregkh-devfs-devfs-remove-devfs_mk_bdev.patch
+gregkh-devfs-devfs-remove-devfs_mk_cdev.patch
+gregkh-devfs-devfs-remove-devfs_remove.patch
+gregkh-devfs-devfs-remove-devfs_fs_kernel.h.patch
+gregkh-devfs-devfs-remove-misc-devfs_name.patch
+gregkh-devfs-devfs-remove-genhd-devfs_name.patch
+gregkh-devfs-devfs-remove-videodev-devfs_name.patch
+gregkh-devfs-devfs-remove-line-devfs_name.patch
+gregkh-devfs-devfs-remove-tty-devfs_name.patch
+gregkh-devfs-devfs-tty_driver_no_devfs.patch
+gregkh-devfs-devfs-minor-cleanups.patch
+gregkh-devfs-devfs-feature-removal.patch
+gregkh-devfs-ndevfs.patch

 Remove devfs

+reserve-space-for-swap-label.patch
+read-write-migration-entries-implement-correct-behavior-in-copy_one_pte.patch
+read-write-migration-entries-make-mprotect-convert-write-migration.patch
+read-write-migration-entries-make-mprotect-convert-write-migration-fix.patch
+read-write-migration-entries-make-mprotect-convert-write-migration-fix-fix.patch
+read-write-migration-entries-make-mprotect-convert-write-migration-fix-fix-fix.patch
+swsusp-rework-memory-shrinker-rev-2.patch

 Memory management updates

+pgdat-allocation-for-new-node-add-specify-node-id.patch
+pgdat-allocation-for-new-node-add-specify-node-id-powerpc-fix.patch
+pgdat-allocation-for-new-node-add-specify-node-id-tidy.patch
+pgdat-allocation-for-new-node-add-specify-node-id-fix-3.patch
+pgdat-allocation-for-new-node-add-get-node-id-by-acpi.patch
+pgdat-allocation-for-new-node-add-get-node-id-by-acpi-tidy.patch
+pgdat-allocation-for-new-node-add-generic-alloc-node_data.patch
+pgdat-allocation-for-new-node-add-generic-alloc-node_data-tidy.patch
+pgdat-allocation-for-new-node-add-refresh-node_data.patch
+pgdat-allocation-for-new-node-add-refresh-node_data-fix.patch
+pgdat-allocation-for-new-node-add-export-kswapd-start-func.patch
+pgdat-allocation-for-new-node-add-export-kswapd-start-func-tidy.patch
+pgdat-allocation-for-new-node-add-call-pgdat-allocation.patch

 Memory hotplug (node add)

+mm-introduce-remap_vmalloc_range.patch
+mm-introduce-remap_vmalloc_range-tidy.patch
+mm-introduce-remap_vmalloc_range-fix.patch
+change-gen_pool-allocator-to-not-touch-managed-memory.patch
+change-gen_pool-allocator-to-not-touch-managed-memory-update.patch
+change-gen_pool-allocator-to-not-touch-managed-memory-update-2.patch
+radix-tree-direct-data.patch
+radix-tree-small.patch
+likely-cleanup-remove-unlikely-in-sys_mprotect.patch

 More memory management updates

+x86-x86_64-avoid-irq0-ioapic-pin-collision.patch
+x86-x86_64-avoid-irq0-ioapic-pin-collision-tidy.patch

 x86_64 fix

+swsusp-add-architecture-special-saveable-pages-fix.patch

 Fix swsusp-add-architecture-special-saveable-pages-support.patch

+swsusp-i386-mark-special-saveable-unsaveable-pages-fix.patch

 Fix swsusp-i386-mark-special-saveable-unsaveable-pages.patch

+swsusp-x86_64-mark-special-saveable-unsaveable-pages-fix.patch

 Fix swsusp-x86_64-mark-special-saveable-unsaveable-pages.patch

+kernel-power-snapshotc-cleanups.patch
+swsusp-use-less-memory-during-resume.patch

 swsusp updates

-uml-prepare-fixing-compilation-output.patch

 Dropped.

+s390-fix-i-o-termination-race-in-cio.patch
+s390-enable-interrupts-on-error-path.patch
+s390-bug-in-setup_rt_frame.patch
+s390-alternate-signal-stack-handling-bug.patch
+s390-qdio-memory-allocations.patch
+s390-dasd-ioctl-never-returns.patch
+s390-fix-slab-debugging.patch
+s390-futex-atomic-operations.patch
+s390-futex-atomic-operations-part-2.patch
+s390-tape-3590-changes.patch
+s390-segment-operation-error-codes.patch
+s390-instruction-processing-damage-handling.patch
+s390-add-read_mostly-optimization.patch
+s390-dasd-device-identifiers.patch
+s390-dasd-device-identifiers-fix.patch
+s390-new-system-calls.patch

 s390 updates

-fix-cdrom-being-confused-on-using-kdump-tweaks.patch

 Folded into fix-cdrom-being-confused-on-using-kdump.patch

+cond-resched-might-sleep-fix.patch
+enhancing-accessibility-of-lxdialog.patch
+the-scheduled-unexport-of-insert_resource.patch
+jbd-fix-bug-in-journal_commit_transaction.patch
+rename-swapper-to-idle.patch
+oss-cs46xx-cleanup-and-tiny-bugfix.patch
+i4l-memory-leak-fix-for-sc_ioctl.patch
+isdn-unsafe-interaction-between-isdn_write-and-isdn_writebuf_stub.patch
+invert-irq-migrationc-brach-prediction.patch
+x86-powerpc-make-hardirq_ctx-and-softirq_ctx-__read_mostly.patch
+jbd-avoid-kfree-null.patch
+ext3_clear_inode-avoid-kfree-null.patch
+make-noirqdebug-irqfixup-__read_mostly-add-unlikely.patch
+leds-amstrad-delta-led-support.patch
+leds-amstrad-delta-led-support-tidy.patch
+update-devicestxt.patch
+binfmt_elf-codingstyle-cleanup-and-remove-some-pointless-casts.patch
+binfnt_elf-remove-more-casts.patch
+fix-incorrect-sa_onstack-behaviour-for-64-bit-processes.patch
+percpu-counter-data-type-changes-to-suppport.patch
+percpu-counter-data-type-changes-to-suppport-fix.patch
+remove-unlikely-in-might_sleep_if.patch
+process-events-header-cleanup.patch
+process-events-license-change.patch
+strstrip-api.patch
+ipmi-strstrip-conversion.patch
+rcu-introduce-rcu_needs_cpu-interface.patch
+s390-exploit-rcu_needs_cpu-interface.patch

 Misc updates

+time-rename-clocksource-functions.patch
+make-pmtmr_ioport-__read_mostly.patch

 Update time management patches in -mm.

+kprobe-boost-2byte-opcodes-on-i386.patch
+kprobemulti-kprobe-posthandler-for-booster.patch
+notify-page-fault-call-chain-for-x86_64.patch
+notify-page-fault-call-chain-for-i386.patch
+notify-page-fault-call-chain-for-ia64.patch
+notify-page-fault-call-chain-for-powerpc.patch
+notify-page-fault-call-chain-for-sparc64.patch
+kprobes-registers-for-notify-page-fault.patch
+notify-page-fault-call-chain.patch

 kprobes updates

-dlm-core-locking.patch
-dlm-core-locking-resend-lookups.patch
-dlm-lockspaces-callbacks-directory.patch
-dlm-communication.patch
-dlm-recovery.patch
-dlm-recovery-clear-new_master-flag.patch
-dlm-recovery-remove-true-false-defines.patch
-dlm-configuration.patch
-dlm-device-interface.patch
-dlm-device-interface-fix-device-refcount.patch
-dlm-device-interface-dlm-force-unlock.patch
-dlm-device-interface-missing-variable.patch
-dlm-device-interface-check-allocation.patch
-dlm-device-interface-fix-unlock-race.patch
-dlm-device-interface-use-kzalloc.patch
-dlm-debug-fs.patch
-dlm-build.patch
-dlm-node-weights.patch
-dlm-rsb-flag-ops-with-inlined-functions.patch
-dlm-rework-recovery-control.patch
-dlm-better-handling-of-first-lock.patch
-dlm-no-directory-option.patch
-dlm-release-list-of-root-rsbs.patch
-dlm-return-error-in-status-reply.patch
-configfs-export-config_group_find_obj.patch
-dlm-use-configfs.patch
-dlm-remove-file.patch
-dlm-use-jhash.patch
-dlm-maintainer.patch
-drivers-dlm-fix-up-schedule_timeout-usage.patch
-dlm-cleanup-unused-functions.patch
-dlm-include-own-headers.patch
-dlm-sem2mutex.patch

 Dropped.

+smpnice-dont-consider-sched-groups-which-are-lightly-loaded-for-balancing.patch
+smpnice-dont-consider-sched-groups-which-are-lightly-loaded-for-balancing-fix.patch
+sched-avoid-unnecessarily-moving-highest-priority-task-move_tasks.patch
+sched-avoid-unnecessarily-moving-highest-priority-task-move_tasks-fix-2.patch

 CPU scheduler updates

+rtmutex-remove-buggy-bug_on-in-pi-boosting-code.patch
+futex-pi-enforce-waiter-bit-when-owner-died-is-detected.patch
+rtmutex-debug-printk-correct-task-information.patch
+futex-pi-make-use-of-restart_block-when-interrupted.patch

 pi-futex updates

+proc-dont-lock-task_structs-indefinitely-task_mmu-small-fixes.patch

 Fix proc-dont-lock-task_structs-indefinitely.patch

+ide-pdc202xx_oldc-remove-unneeded-tuneproc-call.patch
+ide-hpt3xxn-clocking-fixes.patch
+ide-io-increase-timeout-value-to-allow-for-slave-wakeup.patch
+ide-actually-honor-drives-minimum-pio-dma-cycle-times.patch

 IDE updates

+savagefb-allocate-space-for-current-and-saved-register.patch
+savagefb-add-state-save-and_restore-hooks.patch
+savagefb-add-state-save-and_restore-hooks-tidy.patch
+savagefb-add-state-save-and_restore-hooks-fix.patch
+suspend-documentation-update-for-ibm-thinkpad-x30.patch
+asiliantfb-add-help-text-in-kconfig.patch
+backlight-locomo-backlight-driver-updates.patch
+fbdev-cleanup-the-config_video_select-mess.patch
+fbdev-remove-duplicate-includes.patch
+matroxfb-fix-dvi-setup-to-be-more-compatible.patch

 fbdev updates

+drivers-char-ipmi-ipmi_msghandlerc-make-proc_ipmi_root-static.patch
+drivers-message-i2o-iopc-unexport-i2o_msg_nop.patch

 Little fixes




All 707 patches:


ftp://ftp.kernel.org/pub/linux/kernel/people/akpm/patches/2.6/2.6.17-rc2/2.6.17-rc2-mm1/patch-list

Re: 2.6.17-rc2-mm1

[Andi Kleen]

Andrew Morton <akpm@osdl.org> writes:

> ftp://ftp.kernel.org/pub/linux/kernel/people/akpm/patches/2.6/2.6.17-rc2/2.6.17-rc2-mm1/
> 
> 
> - It took six hours work to get this release building and linking in just a
>   basic fashion on eight-odd architectures.  It's getting out of control.

We all appreciate your hard work.
 
>   The acphphp driver is still broken and v4l and memory hotplug are, I
>   suspect, only hanging in there by the skin of their teeth.
> 
>   Could patch submitters _please_ be a lot more careful about getting the
>   Kconfig correct, testing various Kconfig combinations (yes sometimes
>   people will want to disable your lovely new feature) and just generally
>   think about these things a bit harder?  It isn't rocket science.

Is this something that could be automated with some machine power? 

e.g. every time a patch is added a small cluster could build the patches
with some configurations on various architectures and if it doesn't build 
autoflame the patch submitter.

We use this in SUSE for the SUSE kernels and it works quite well.

Maybe someone could contribute the build power needed for that. I suppose
it could be done by just a few scripts listening to mm-commits?

-Andi

Re: 2.6.17-rc2-mm1

[Andrew Morton]

Andi Kleen <ak@suse.de> wrote:
>
> >   The acphphp driver is still broken and v4l and memory hotplug are, I
>  >   suspect, only hanging in there by the skin of their teeth.
>  > 
>  >   Could patch submitters _please_ be a lot more careful about getting the
>  >   Kconfig correct, testing various Kconfig combinations (yes sometimes
>  >   people will want to disable your lovely new feature) and just generally
>  >   think about these things a bit harder?  It isn't rocket science.
> 
>  Is this something that could be automated with some machine power? 
> 
>  e.g. every time a patch is added a small cluster could build the patches
>  with some configurations on various architectures and if it doesn't build 
>  autoflame the patch submitter.
> 
>  We use this in SUSE for the SUSE kernels and it works quite well.
> 
>  Maybe someone could contribute the build power needed for that. I suppose
>  it could be done by just a few scripts listening to mm-commits?

I suspect something like that would be quite a lot of work to set up -
first-up one has to get all the patches to actually apply, and then work
through any compile-time interactions between them.   Dunno.

I don't like dropping patches.  Because then the thing needs to be fixed up
and resent and remerged and re-reviewed and rejects need to re-fixed-up and
this adds emailing overhead and 12-24 hour turnaround, etc.  I very much
prefer to hang onto the patch and get it fixed up.  This means that I
usually have to do the fixing-up.

And that's OK - it's one of the things I do.  But it's striking how silly
so many of these problems are - they demonstrate a very basic lack of care
and thought.

It's obvious that the originators haven't even compiled their feature with
its config option disabled, or they haven't spent the requisite 30
seconds thinking about their Kconfig dependencies, or they haven't verified
that all architectures support the architecture functions which they're
relying upon or they haven't grepped the tree for symbol clashes, etc.

So at this point in time what I'd like to do is to encourage developers to
do these very basic things.  That's the low-hanging fruit right now.

Re: 2.6.17-rc2-mm1

[Andi Kleen]

On Thursday 27 April 2006 21:19, Andrew Morton wrote:
> Andi Kleen <ak@suse.de> wrote:
> >
> > >   The acphphp driver is still broken and v4l and memory hotplug are, I
> >  >   suspect, only hanging in there by the skin of their teeth.
> >  > 
> >  >   Could patch submitters _please_ be a lot more careful about getting the
> >  >   Kconfig correct, testing various Kconfig combinations (yes sometimes
> >  >   people will want to disable your lovely new feature) and just generally
> >  >   think about these things a bit harder?  It isn't rocket science.
> > 
> >  Is this something that could be automated with some machine power? 
> > 
> >  e.g. every time a patch is added a small cluster could build the patches
> >  with some configurations on various architectures and if it doesn't build 
> >  autoflame the patch submitter.
> > 
> >  We use this in SUSE for the SUSE kernels and it works quite well.
> > 
> >  Maybe someone could contribute the build power needed for that. I suppose
> >  it could be done by just a few scripts listening to mm-commits?
> 
> I suspect something like that would be quite a lot of work to set up -
> first-up one has to get all the patches to actually apply, and then work
> through any compile-time interactions between them.   Dunno.

The invariant could be that any single new patch added should still
compile. And it should apply of course. If not then warn the submitter.
Might generate quite a lot of email though.

Problem is when people add new stuff in multiple pieces that only
compile together though. iirc they go to mm-commits as individual
pieces, not a bundle right now.

It would probably not catch everything - just a few common
configurations and architectures.

> 
> I don't like dropping patches.  Because then the thing needs to be fixed up
> and resent and remerged and re-reviewed and rejects need to re-fixed-up and
> this adds emailing overhead and 12-24 hour turnaround, etc.  I very much
> prefer to hang onto the patch and get it fixed up.  This means that I
> usually have to do the fixing-up.

If it's caught early enough the submitter can be warned and they
might even fix it up themselves and send a new patch.

> So at this point in time what I'd like to do is to encourage developers to
> do these very basic things.  That's the low-hanging fruit right now.

Write a checklist for that?

-Andi 

Re: 2.6.17-rc2-mm1

[Grant Coady]

On Thu, 27 Apr 2006 12:19:30 -0700, Andrew Morton <akpm@osdl.org> wrote:

>I don't like dropping patches.  Because then the thing needs to be fixed up
>and resent and remerged and re-reviewed and rejects need to re-fixed-up and
>this adds emailing overhead and 12-24 hour turnaround, etc.  I very much
>prefer to hang onto the patch and get it fixed up.  This means that I
>usually have to do the fixing-up.

Perhaps dropping patches with obvious faults with some feedback 
to submitter may reduce your workload ;)  And is slowing down the 
merge a little in these cases such a bad thing if it improves 
patch quality over time?

Grant.

Re: 2.6.17-rc2-mm1

[Randy.Dunlap]

On Fri, 28 Apr 2006 07:41:52 +1000 Grant Coady wrote:

> On Thu, 27 Apr 2006 12:19:30 -0700, Andrew Morton <akpm@osdl.org> wrote:
> 
> >I don't like dropping patches.  Because then the thing needs to be fixed up
> >and resent and remerged and re-reviewed and rejects need to re-fixed-up and
> >this adds emailing overhead and 12-24 hour turnaround, etc.  I very much
> >prefer to hang onto the patch and get it fixed up.  This means that I
> >usually have to do the fixing-up.
> 
> Perhaps dropping patches with obvious faults with some feedback 
> to submitter may reduce your workload ;)  And is slowing down the 
> merge a little in these cases such a bad thing if it improves 
> patch quality over time?

True dat.  That's what I would do.  :)
But I seem to need more sleep than Andrew does.

---
~Randy

Re: 2.6.17-rc2-mm1

[Andrew Morton]

"Randy.Dunlap" <rdunlap@xenotime.net> wrote:
>
> On Fri, 28 Apr 2006 07:41:52 +1000 Grant Coady wrote:
> 
> > On Thu, 27 Apr 2006 12:19:30 -0700, Andrew Morton <akpm@osdl.org> wrote:
> > 
> > >I don't like dropping patches.  Because then the thing needs to be fixed up
> > >and resent and remerged and re-reviewed and rejects need to re-fixed-up and
> > >this adds emailing overhead and 12-24 hour turnaround, etc.  I very much
> > >prefer to hang onto the patch and get it fixed up.  This means that I
> > >usually have to do the fixing-up.
> > 
> > Perhaps dropping patches with obvious faults with some feedback 
> > to submitter may reduce your workload ;)  And is slowing down the 
> > merge a little in these cases such a bad thing if it improves 
> > patch quality over time?
> 
> True dat.  That's what I would do.  :)

As I say - I prefer to keep moving in the forward direction.  So if a patch
needs coding-style cleanups, warning fixes, bugfixes, etc it's usually
quicker to just fix the thing immediately rather than send it back, wait
and then redo everything.  The submitter sees the fixes and hence will
Never Do That Again (right?)

None of this is a particular burden for me - it'd average an hour a day,
tops.  My main reason for the big whine is that this defect rate indicates
that people just aren't being sufficiently careful in their work.  If so
many silly trivial things are slipping through, then what does this tell us
about the big things, ie: runtime bugs?

> But I seem to need more sleep than Andrew does.

There's plenty of time for that in the grave.

Re: 2.6.17-rc2-mm1

[Michal Piotrowski]

Hi Andrew,

On 27/04/06, Andrew Morton <akpm@osdl.org> wrote:
> ftp://ftp.kernel.org/pub/linux/kernel/people/akpm/patches/2.6/2.6.17-rc2/2.6.17-rc2-mm1/
>
[snip]
> +gregkh-devfs-ndevfs.patch

"You don't really want to run this.  But if you did, here's a simple hack
showing how easy it is to do it.

Note, this patch will NOT be merged into mainline, so don't get your
panties into a bind..."
http://www.kernel.org/pub/linux/kernel/people/gregkh/gregkh-2.6/gregkh-05-devfs/ndevfs.patch

Please drop this patch.

Regards,
Michal

--
Michal K. K. Piotrowski
LTG - Linux Testers Group
(http://www.stardust.webpages.pl/ltg/wiki/)

Re: 2.6.17-rc2-mm1

[Michal Piotrowski]

On 27/04/06, Michal Piotrowski <michal.k.k.piotrowski@gmail.com> wrote:
> Hi Andrew,
>
> On 27/04/06, Andrew Morton <akpm@osdl.org> wrote:
> > ftp://ftp.kernel.org/pub/linux/kernel/people/akpm/patches/2.6/2.6.17-rc2/2.6.17-rc2-mm1/
> >
> [snip]
> > +gregkh-devfs-ndevfs.patch
>
> "You don't really want to run this.  But if you did, here's a simple hack
> showing how easy it is to do it.
>
> Note, this patch will NOT be merged into mainline, so don't get your
> panties into a bind..."
> http://www.kernel.org/pub/linux/kernel/people/gregkh/gregkh-2.6/gregkh-05-devfs/ndevfs.patch
>
> Please drop this patch.

Here is oops:
http://www.stardust.webpages.pl/files/mm/2.6.17-rc2-mm1/oops1.jpg

Here is config:
http://www.stardust.webpages.pl/files/mm/2.6.17-rc2-mm1/mm-config

Regards,
Michal

--
Michal K. K. Piotrowski
LTG - Linux Testers Group
(http://www.stardust.webpages.pl/ltg/wiki/)

Re: 2.6.17-rc2-mm1

[Greg KH]

On Thu, Apr 27, 2006 at 03:07:54PM +0200, Michal Piotrowski wrote:
> On 27/04/06, Michal Piotrowski <michal.k.k.piotrowski@gmail.com> wrote:
> > Hi Andrew,
> >
> > On 27/04/06, Andrew Morton <akpm@osdl.org> wrote:
> > > ftp://ftp.kernel.org/pub/linux/kernel/people/akpm/patches/2.6/2.6.17-rc2/2.6.17-rc2-mm1/
> > >
> > [snip]
> > > +gregkh-devfs-ndevfs.patch
> >
> > "You don't really want to run this.  But if you did, here's a simple hack
> > showing how easy it is to do it.
> >
> > Note, this patch will NOT be merged into mainline, so don't get your
> > panties into a bind..."
> > http://www.kernel.org/pub/linux/kernel/people/gregkh/gregkh-2.6/gregkh-05-devfs/ndevfs.patch
> >
> > Please drop this patch.
> 
> Here is oops:
> http://www.stardust.webpages.pl/files/mm/2.6.17-rc2-mm1/oops1.jpg

Ah, I guess it is causing you problems :)

> Here is config:
> http://www.stardust.webpages.pl/files/mm/2.6.17-rc2-mm1/mm-config

If you set CONFIG_NDEV_FS=n does the oops go away?

thanks,

greg k-h

Re: 2.6.17-rc2-mm1

[Michal Piotrowski]

Hi Greg,

On 27/04/06, Greg KH <gregkh@suse.de> wrote:
[snip]
>
> Ah, I guess it is causing you problems :)
>
> > Here is config:
> > http://www.stardust.webpages.pl/files/mm/2.6.17-rc2-mm1/mm-config
>
> If you set CONFIG_NDEV_FS=n does the oops go away?

Yes.

>
> thanks,
>
> greg k-h
>

Regards,
Michal

--
Michal K. K. Piotrowski
LTG - Linux Testers Group
(http://www.stardust.webpages.pl/ltg/wiki/)

Re: 2.6.17-rc2-mm1

[Greg KH]

On Thu, Apr 27, 2006 at 05:32:43PM +0200, Michal Piotrowski wrote:
> Hi Greg,
> 
> On 27/04/06, Greg KH <gregkh@suse.de> wrote:
> [snip]
> >
> > Ah, I guess it is causing you problems :)
> >
> > > Here is config:
> > > http://www.stardust.webpages.pl/files/mm/2.6.17-rc2-mm1/mm-config
> >
> > If you set CONFIG_NDEV_FS=n does the oops go away?
> 
> Yes.

Ok, I've spent a bit of time trying to reproduce this and I can't.  So
I'm just going to drop it from the patch set, because as you point out,
it's never going to go to mainline anyway, it was just a fun hack.

Sorry for the noise,

greg k-h

Re: 2.6.17-rc2-mm1

[Michal Piotrowski]

On 27/04/06, Greg KH <gregkh@suse.de> wrote:
[snip]
> Ok, I've spent a bit of time trying to reproduce this and I can't.  So
> I'm just going to drop it from the patch set, because as you point out,
> it's never going to go to mainline anyway, it was just a fun hack.
>
> Sorry for the noise,
>
> greg k-h
>

Thanks.

Regards,
Michal

--
Michal K. K. Piotrowski
LTG - Linux Testers Group
(http://www.stardust.webpages.pl/ltg/wiki/)

Re: 2.6.17-rc2-mm1

[Greg KH]

On Thu, Apr 27, 2006 at 12:27:53PM +0200, Michal Piotrowski wrote:
> Hi Andrew,
> 
> On 27/04/06, Andrew Morton <akpm@osdl.org> wrote:
> > ftp://ftp.kernel.org/pub/linux/kernel/people/akpm/patches/2.6/2.6.17-rc2/2.6.17-rc2-mm1/
> >
> [snip]
> > +gregkh-devfs-ndevfs.patch
> 
> "You don't really want to run this.  But if you did, here's a simple hack
> showing how easy it is to do it.
> 
> Note, this patch will NOT be merged into mainline, so don't get your
> panties into a bind..."
> http://www.kernel.org/pub/linux/kernel/people/gregkh/gregkh-2.6/gregkh-05-devfs/ndevfs.patch
> 
> Please drop this patch.

Why drop it?  Is it causing you any problems?

thanks,

greg k-h

Re: 2.6.17-rc2-mm1

[Michal Piotrowski]

On 27/04/06, Greg KH <gregkh@suse.de> wrote:
> On Thu, Apr 27, 2006 at 12:27:53PM +0200, Michal Piotrowski wrote:
> > Hi Andrew,
> >
> > On 27/04/06, Andrew Morton <akpm@osdl.org> wrote:
> > > ftp://ftp.kernel.org/pub/linux/kernel/people/akpm/patches/2.6/2.6.17-rc2/2.6.17-rc2-mm1/
> > >
> > [snip]
> > > +gregkh-devfs-ndevfs.patch
> >
> > "You don't really want to run this.  But if you did, here's a simple hack
> > showing how easy it is to do it.
> >
> > Note, this patch will NOT be merged into mainline, so don't get your
> > panties into a bind..."
> > http://www.kernel.org/pub/linux/kernel/people/gregkh/gregkh-2.6/gregkh-05-devfs/ndevfs.patch
> >
> > Please drop this patch.
>
> Why drop it?

As long as it doesn't go to mainline we shouldn't care about it in -mm.

>
> thanks,
>
> greg k-h
>

Regards,
Michal

--
Michal K. K. Piotrowski
LTG - Linux Testers Group
(http://www.stardust.webpages.pl/ltg/wiki/)

Re: 2.6.17-rc2-mm1

[Matthieu CASTET]

Hi Andrew,

Le Thu, 27 Apr 2006 01:41:41 -0700, Andrew Morton a écrit :

> ftp://ftp.kernel.org/pub/linux/kernel/people/akpm/patches/2.6/2.6.17-rc2/2.6.17-rc2-mm1/
> 

64 bit resources core changes in ioport.h break pnp sysfs interface.

A patch like this is needed.

Matthieu

Signed-off-by: Matthieu CASTET <castet.matthieu@free.fr>

--- 1/drivers/pnp/interface.c	2006-01-03 04:21:10.000000000 +0100
+++ 2/drivers/pnp/interface.c	2006-04-14 22:54:45.000000000 +0200
@@ -264,7 +264,7 @@
 			if (pnp_port_flags(dev, i) & IORESOURCE_DISABLED)
 				pnp_printf(buffer," disabled\n");
 			else
-				pnp_printf(buffer," 0x%lx-0x%lx\n",
+				pnp_printf(buffer," 0x%llx-0x%llx\n",
 						pnp_port_start(dev, i),
 						pnp_port_end(dev, i));
 		}
@@ -275,7 +275,7 @@
 			if (pnp_mem_flags(dev, i) & IORESOURCE_DISABLED)
 				pnp_printf(buffer," disabled\n");
 			else
-				pnp_printf(buffer," 0x%lx-0x%lx\n",
+				pnp_printf(buffer," 0x%llx-0x%llx\n",
 						pnp_mem_start(dev, i),
 						pnp_mem_end(dev, i));
 		}
@@ -286,7 +286,7 @@
 			if (pnp_irq_flags(dev, i) & IORESOURCE_DISABLED)
 				pnp_printf(buffer," disabled\n");
 			else
-				pnp_printf(buffer," %ld\n",
+				pnp_printf(buffer," %lld\n",
 						pnp_irq(dev, i));
 		}
 	}
@@ -296,7 +296,7 @@
 			if (pnp_dma_flags(dev, i) & IORESOURCE_DISABLED)
 				pnp_printf(buffer," disabled\n");
 			else
-				pnp_printf(buffer," %ld\n",
+				pnp_printf(buffer," %lld\n",
 						pnp_dma(dev, i));
 		}
 	}

Re: 2.6.17-rc2-mm1

[Vivek Goyal]

On Thu, Apr 27, 2006 at 05:47:25PM +0200, Matthieu CASTET wrote:
> Hi Andrew,
> 
> Le Thu, 27 Apr 2006 01:41:41 -0700, Andrew Morton a écrit :
> 
> > ftp://ftp.kernel.org/pub/linux/kernel/people/akpm/patches/2.6/2.6.17-rc2/2.6.17-rc2-mm1/
> > 
> 
> 64 bit resources core changes in ioport.h break pnp sysfs interface.
> 
> A patch like this is needed.
> 
> Matthieu
> 
> Signed-off-by: Matthieu CASTET <castet.matthieu@free.fr>
> 
> --- 1/drivers/pnp/interface.c	2006-01-03 04:21:10.000000000 +0100
> +++ 2/drivers/pnp/interface.c	2006-04-14 22:54:45.000000000 +0200
> @@ -264,7 +264,7 @@
>  			if (pnp_port_flags(dev, i) & IORESOURCE_DISABLED)
>  				pnp_printf(buffer," disabled\n");
>  			else
> -				pnp_printf(buffer," 0x%lx-0x%lx\n",
> +				pnp_printf(buffer," 0x%llx-0x%llx\n",
>  						pnp_port_start(dev, i),
>  						pnp_port_end(dev, i));

I think it would break on ppc64 as u64 is unsigned long. It should be
explicitly typecasted to unsigned long long. Same is true for all the
instances.

(unsigned long long) pnp_port_start(dev, i)

-vivek

>  		}
> @@ -275,7 +275,7 @@
>  			if (pnp_mem_flags(dev, i) & IORESOURCE_DISABLED)
>  				pnp_printf(buffer," disabled\n");
>  			else
> -				pnp_printf(buffer," 0x%lx-0x%lx\n",
> +				pnp_printf(buffer," 0x%llx-0x%llx\n",
>  						pnp_mem_start(dev, i),
>  						pnp_mem_end(dev, i));
>  		}
> @@ -286,7 +286,7 @@
>  			if (pnp_irq_flags(dev, i) & IORESOURCE_DISABLED)
>  				pnp_printf(buffer," disabled\n");
>  			else
> -				pnp_printf(buffer," %ld\n",
> +				pnp_printf(buffer," %lld\n",
>  						pnp_irq(dev, i));
>  		}
>  	}
> @@ -296,7 +296,7 @@
>  			if (pnp_dma_flags(dev, i) & IORESOURCE_DISABLED)
>  				pnp_printf(buffer," disabled\n");
>  			else
> -				pnp_printf(buffer," %ld\n",
> +				pnp_printf(buffer," %lld\n",
>  						pnp_dma(dev, i));
>  		}
>  	}
> 
> -
> To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
> the body of a message to majordomo@vger.kernel.org
> More majordomo info at  http://vger.kernel.org/majordomo-info.html
> Please read the FAQ at  http://www.tux.org/lkml/
> 

Re: 2.6.17-rc2-mm1

[Greg KH]

On Thu, Apr 27, 2006 at 02:02:27PM -0400, Vivek Goyal wrote:
> On Thu, Apr 27, 2006 at 05:47:25PM +0200, Matthieu CASTET wrote:
> > Hi Andrew,
> > 
> > Le Thu, 27 Apr 2006 01:41:41 -0700, Andrew Morton a ?crit?:
> > 
> > > ftp://ftp.kernel.org/pub/linux/kernel/people/akpm/patches/2.6/2.6.17-rc2/2.6.17-rc2-mm1/
> > > 
> > 
> > 64 bit resources core changes in ioport.h break pnp sysfs interface.
> > 
> > A patch like this is needed.
> > 
> > Matthieu
> > 
> > Signed-off-by: Matthieu CASTET <castet.matthieu@free.fr>
> > 
> > --- 1/drivers/pnp/interface.c	2006-01-03 04:21:10.000000000 +0100
> > +++ 2/drivers/pnp/interface.c	2006-04-14 22:54:45.000000000 +0200
> > @@ -264,7 +264,7 @@
> >  			if (pnp_port_flags(dev, i) & IORESOURCE_DISABLED)
> >  				pnp_printf(buffer," disabled\n");
> >  			else
> > -				pnp_printf(buffer," 0x%lx-0x%lx\n",
> > +				pnp_printf(buffer," 0x%llx-0x%llx\n",
> >  						pnp_port_start(dev, i),
> >  						pnp_port_end(dev, i));
> 
> I think it would break on ppc64 as u64 is unsigned long. It should be
> explicitly typecasted to unsigned long long. Same is true for all the
> instances.

Does ppc64 use the PnP code?

thanks,

greg k-h

Re: 2.6.17-rc2-mm1

[Vivek Goyal]

On Thu, Apr 27, 2006 at 04:24:44PM -0700, Greg KH wrote:
> On Thu, Apr 27, 2006 at 02:02:27PM -0400, Vivek Goyal wrote:
> > On Thu, Apr 27, 2006 at 05:47:25PM +0200, Matthieu CASTET wrote:
> > > Hi Andrew,
> > > 
> > > Le Thu, 27 Apr 2006 01:41:41 -0700, Andrew Morton a ?crit?:
> > > 
> > > > ftp://ftp.kernel.org/pub/linux/kernel/people/akpm/patches/2.6/2.6.17-rc2/2.6.17-rc2-mm1/
> > > > 
> > > 
> > > 64 bit resources core changes in ioport.h break pnp sysfs interface.
> > > 
> > > A patch like this is needed.
> > > 
> > > Matthieu
> > > 
> > > Signed-off-by: Matthieu CASTET <castet.matthieu@free.fr>
> > > 
> > > --- 1/drivers/pnp/interface.c	2006-01-03 04:21:10.000000000 +0100
> > > +++ 2/drivers/pnp/interface.c	2006-04-14 22:54:45.000000000 +0200
> > > @@ -264,7 +264,7 @@
> > >  			if (pnp_port_flags(dev, i) & IORESOURCE_DISABLED)
> > >  				pnp_printf(buffer," disabled\n");
> > >  			else
> > > -				pnp_printf(buffer," 0x%lx-0x%lx\n",
> > > +				pnp_printf(buffer," 0x%llx-0x%llx\n",
> > >  						pnp_port_start(dev, i),
> > >  						pnp_port_end(dev, i));
> > 
> > I think it would break on ppc64 as u64 is unsigned long. It should be
> > explicitly typecasted to unsigned long long. Same is true for all the
> > instances.
> 
> Does ppc64 use the PnP code?
> 

I had assumed it. Just now did a allmodconfig on ppc64 and came to know
there is no such option as CONFIG_PNP. Sorry for the noise.

Thanks
Vivek 

Re: 2.6.17-rc2-mm1

[matthieu castet]

Vivek Goyal wrote:
> On Thu, Apr 27, 2006 at 05:47:25PM +0200, Matthieu CASTET wrote:
> 
> 
> I think it would break on ppc64 as u64 is unsigned long. It should be
> explicitly typecasted to unsigned long long. Same is true for all the
> instances.
On 64 bits platform, unsigned long isn't the same as unsigned long long ?

Do you mean there will be a warning ?
But pnp_printf is a variadic fonction (with no attribute format printf), 
so gcc can't check the arguments type.


Matthieu

PS : according to arch/ppc/Kconfig, ISA (so PNP that depend on ISA) 
could be enable on PPC_PREP or PPC_CHRP [1]. But there are others 64 
bits architecture like ia64 that have ACPI and use PNP.

[1]
Find out whether you have ISA slots on your motherboard.  ISA is the
           name of a bus system, i.e. the way the CPU talks to the other 
stuff
           inside your box.  If you have an Apple machine, say N here; 
if you
           have an IBM RS/6000 or pSeries machine or a PReP machine, say 
Y.  If
           you have an embedded board, consult your board documentation.

Re: 2.6.17-rc2-mm1

[Vivek Goyal]

On Fri, Apr 28, 2006 at 06:07:17PM +0200, matthieu castet wrote:
> Vivek Goyal wrote:
> >On Thu, Apr 27, 2006 at 05:47:25PM +0200, Matthieu CASTET wrote:
> >
> >
> >I think it would break on ppc64 as u64 is unsigned long. It should be
> >explicitly typecasted to unsigned long long. Same is true for all the
> >instances.
> On 64 bits platform, unsigned long isn't the same as unsigned long long ?
> 
> Do you mean there will be a warning ?

Yes.

> But pnp_printf is a variadic fonction (with no attribute format printf), 
> so gcc can't check the arguments type.
> 

You are right. I did not notice that for pnp_printf(), attribute format
printf is not specified. So gcc won't do the type checking on format string
arguments.

( __attribute__ ((format (printf, 2, 3)));

Thanks
Vivek