2.6.24-rc4-mm1 - Kernel

This is a discussion on 2.6.24-rc4-mm1 - Kernel ; Greg KH wrote: > On Thu, Dec 06, 2007 at 03:54:51PM -0800, Badari Pulavarty wrote: >> On Thu, 2007-12-06 at 12:31 -0800, Greg KH wrote: >>> On Fri, Dec 07, 2007 at 12:28:58AM +0530, Balbir Singh wrote: >>>> Greg KH ...

+ Reply to Thread
Page 3 of 6 FirstFirst 1 2 3 4 5 ... LastLast
Results 41 to 60 of 111

Thread: 2.6.24-rc4-mm1

  1. Re: 2.6.24-rc4-mm1 kobject changes broken with hvcs driver on powerpc

    Greg KH wrote:
    > On Thu, Dec 06, 2007 at 03:54:51PM -0800, Badari Pulavarty wrote:
    >> On Thu, 2007-12-06 at 12:31 -0800, Greg KH wrote:
    >>> On Fri, Dec 07, 2007 at 12:28:58AM +0530, Balbir Singh wrote:
    >>>> Greg KH wrote:
    >>>>
    >>>>>> Why release the spinlock here? It's done after the count is incremented.
    >>>>>> This patch does not seem correct.
    >>>>> Doh, you are correct, I'll make sure that I fix this up before applying
    >>>>> it.
    >>>>>
    >>>>> thanks,
    >>>>>
    >>>>> greg k-h
    >>>> Hi, Greg,
    >>>>
    >>>> I ran some tests with the fixed up version of this patch and the system
    >>>> fails to come up.
    >>>>
    >>>> I see the WARN_ON in lib/kref.c:33 and the system fails to boot beyond
    >>>> that point. I have not yet found time to debug it though.
    >>> That's not good, that warning means that someone has tried to use this
    >>> kref _before_ it was initialized, so there is a logic error in the code
    >>> that was previously being papered over with the lack of this message in
    >>> the kobject code.
    >>>
    >>> I do have this same message availble as a patch for the kobject core, it
    >>> would be interesting if you could just run 2.6.24-rc4 with just this
    >>> patch:
    >>> http://www.kernel.org/pub/linux/kern...ect-warn.patch
    >>>
    >>> it might take some fuzz to fit properly, but all you really want to do
    >>> is add:
    >>> WARN_ON(atomic_read(&kobj->kref.refcount));
    >>> before the kref_init() call in kobject_init().
    >>>
    >>> thanks,
    >>>
    >>> greg k-h

    >> 2.6.24-rc4 with above patch booted fine without any warnings.
    >> But 2.6.24-rc4-mm1 doesn't boot, it hangs after following messages.
    >>
    >>
    >> e100: Intel(R) PRO/100 Network Driver, 3.5.23-k4-NAPI
    >> e100: Copyright(c) 1999-2006 Intel Corporation
    >> ipr: IBM Power RAID SCSI Device Driver version: 2.4.1 (April 24, 2007)
    >> ipr 0000:d0:01.0: Found IOA with IRQ: 119
    >> ipr 0000:d0:01.0: Starting IOA initialization sequence.
    >> ipr 0000:d0:01.0: Adapter firmware version: 020A005E
    >> ipr 0000:d0:01.0: IOA initialized.
    >> scsi0 : IBM 570B Storage Adapter
    >> scsi 0:0:3:0: Direct-Access IBM H0 HUS103014FL3800 RPQF PQ: 0 ANSI: 4
    >> scsi 0:0:5:0: Direct-Access IBM H0 HUS103014FL3800 RPQF PQ: 0 ANSI: 4
    >> scsi 0:0:8:0: Direct-Access IBM H0 HUS103014FL3800 RPQF PQ: 0 ANSI: 4
    >> scsi 0:0:15:0: Enclosure IBM VSBPD4E2 U4SCSI 7134 PQ: 0 ANSI: 2
    >> ------------[ cut here ]------------
    >> Badness at lib/kref.c:33
    >> NIP: c0000000002e1254 LR: c0000000002dfbd8 CTR: c0000000002e60f0
    >> REGS: c00000003f0db050 TRAP: 0700 Not tainted (2.6.24-rc4-mm1)
    >> MSR: 8000000000029032 CR: 28002042 XER: 0000000f
    >> TASK = c00000003f0d78d0[1] 'swapper' THREAD: c00000003f0d8000 CPU: 0
    >> GPR00: 0000000000000000 c00000003f0db2d0 c000000000724098 c00000003f131620
    >> GPR04: fffffffffffffff1 fffffffffffffffe 000000000000000a ffffffffffffffff
    >> GPR08: c00000003d4d9000 c00000003f0cbfe0 c000000000556591 0000000000000073
    >> GPR12: 0000000024002084 c000000000651980 0000000000000000 0000000000000000
    >> GPR16: 0000000000000000 d000080080080000 c00000000064d6f0 c00000003d4d9570
    >> GPR20: c00000003d4d94b8 0000000000000002 c00000003d4d9170 c00000003d4d9170
    >> GPR24: c00000003d4d9000 0000000000000001 c00000003d570d58 c00000003d570d18
    >> GPR28: 0000000000000000 c00000003d4d9260 c0000000006b5400 c00000003f131618
    >> NIP [c0000000002e1254] .kref_get+0x10/0x2c
    >> LR [c0000000002dfbd8] .kobject_get+0x24/0x40
    >> Call Trace:
    >> [c00000003f0db2d0] [c00000003f0db360] 0xc00000003f0db360 (unreliable)
    >> [c00000003f0db350] [c0000000002e00e8] .kobject_add+0x8c/0x21c
    >> [c00000003f0db3e0] [c000000000344b00] .device_add+0xd4/0x680
    >> [c00000003f0db4a0] [c0000000003a1c4c] .scsi_alloc_target+0x218/0x404
    >> [c00000003f0db570] [c0000000003a1fb4] .__scsi_scan_target+0xa8/0x640
    >> [c00000003f0db6b0] [c0000000003a25c4] .scsi_scan_channel+0x78/0xdc
    >> [c00000003f0db750] [c0000000003a26f8] .scsi_scan_host_selected+0xd0/0x140
    >> [c00000003f0db7f0] [c0000000003c3ff4] .ipr_probe+0x1270/0x1348

    >
    > This looks like a scsi issue to me, I don't see how the kref changes
    > could cause this backtrace/oops, do you?
    >
    > thanks,
    >
    > greg k-h


    The 2.6.24-rc4 with the above patch, boots fine for me either, and with
    2.6.24-rc4-mm1 i get similar backtrace,

    Badness at lib/kref.c:33
    NIP: c00000000021908c LR: c000000000217b88 CTR: c00000000029b71c
    REGS: c00000003c066fc0 TRAP: 0700 Not tainted (2.6.24-rc4-mm1-autokern1)
    MSR: 8000000000029032 CR: 88002022 XER: 00000001
    TASK = c00000003ef4c840[339] 'insmod' THREAD: c00000003c064000 CPU: 0
    GPR00: 0000000000000000 c00000003c067240 c0000000005d32c0 c00000003e0101a0
    GPR04: fffffffffffffff2 fffffffffffffffe 000000000000000a 0000000000000002
    GPR08: 0000000000000000 c00000003ef8ae50 ffffffffffffffff c000000000449269
    GPR12: 0000000024002084 c000000000515980 0000000000000000 0000000000000000
    GPR16: 0000000000000000 0000000000000000 0000000000240000 0000000000000000
    GPR20: 0000000010000290 0000000000000002 c00000003ef3f970 c00000003ef3f970
    GPR24: 0000000000000001 0000000000000000 c00000003c039958 c00000003c039918
    GPR28: 0000000000000000 c00000003ef3fa60 c00000000058e588 c00000003e010198
    NIP [c00000000021908c] .kref_get+0x10/0x2c
    LR [c000000000217b88] .kobject_get+0x20/0x3c
    Call Trace:
    [c00000003c067240] [c000000000217a48] .kobject_set_name_vargs+0x38/0x60 (unreliable)
    [c00000003c0672c0] [c000000000217ffc] .kobject_add+0x88/0x20c
    [c00000003c067350] [c00000000029b7ec] .device_add+0xd0/0x648
    [c00000003c067410] [d000000000613c84] .scsi_alloc_target+0x238/0x414 [scsi_mod]
    [c00000003c0674e0] [d000000000614e70] .__scsi_scan_target+0xac/0x718 [scsi_mod]
    [c00000003c067630] [d00000000061566c] .scsi_scan_channel+0x78/0xdc [scsi_mod]
    [c00000003c0676d0] [d0000000006157f0] .scsi_scan_host_selected+0x120/0x194 [scsi_mod]
    [c00000003c067780] [d000000000682148] .ibmvscsi_probe+0x450/0x4fc [ibmvscsic]
    [c00000003c067870] [c000000000025fe8] .vio_bus_probe+0x74/0x9c
    [c00000003c067900] [c00000000029f2c8] .driver_probe_device+0x110/0x1ec
    [c00000003c067990] [c00000000029f57c] .__driver_attach+0xd0/0x160
    [c00000003c067a20] [c00000000029da58] .bus_for_each_dev+0x7c/0xcc
    [c00000003c067ad0] [c00000000029f634] .driver_attach+0x28/0x40
    [c00000003c067b50] [c00000000029e6a4] .bus_add_driver+0xe8/0x2b4
    [c00000003c067c00] [c00000000029fd80] .driver_register+0x80/0x9c
    [c00000003c067c80] [c0000000000260b0] .vio_register_driver+0x40/0x5c
    [c00000003c067d10] [d000000000682c04] .init_module+0x68/0xa4 [ibmvscsic]
    [c00000003c067da0] [c00000000009301c] .sys_init_module+0xf4/0x1ac
    [c00000003c067e30] [c00000000000872c] syscall_exit+0x0/0x40
    Instruction dump:
    7d808120 4e800020 38a00000 4bfffad0 38000001 90030000 7c0004ac 4e800020
    80030000 7c0007b4 2f800000 40be0008 <0fe00000> 7c001828 30000001 7c00192d



    --
    Thanks & Regards,
    Kamalesh Babulal,
    Linux Technology Center,
    IBM, ISTL.
    --
    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/

  2. Re: [PATCH x86/mm] x86 vDSO: canonicalize sysenter .eh_frame

    Thanks. That enabled me to compile as well. Now, if I can figure out
    why the resulting kernel has a boot process that hangs... :-)

    Miles
    --
    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/

  3. Re: 2.6.24-rc4-mm1 kobject changes broken with hvcs driver on powerpc

    On Fri, Dec 07, 2007 at 08:32:26AM +0530, Kamalesh Babulal wrote:
    > Greg KH wrote:
    > > On Thu, Dec 06, 2007 at 03:54:51PM -0800, Badari Pulavarty wrote:
    > >> On Thu, 2007-12-06 at 12:31 -0800, Greg KH wrote:
    > >>> On Fri, Dec 07, 2007 at 12:28:58AM +0530, Balbir Singh wrote:
    > >>>> Greg KH wrote:
    > >>>>
    > >>>>>> Why release the spinlock here? It's done after the count is incremented.
    > >>>>>> This patch does not seem correct.
    > >>>>> Doh, you are correct, I'll make sure that I fix this up before applying
    > >>>>> it.
    > >>>>>
    > >>>>> thanks,
    > >>>>>
    > >>>>> greg k-h
    > >>>> Hi, Greg,
    > >>>>
    > >>>> I ran some tests with the fixed up version of this patch and the system
    > >>>> fails to come up.
    > >>>>
    > >>>> I see the WARN_ON in lib/kref.c:33 and the system fails to boot beyond
    > >>>> that point. I have not yet found time to debug it though.
    > >>> That's not good, that warning means that someone has tried to use this
    > >>> kref _before_ it was initialized, so there is a logic error in the code
    > >>> that was previously being papered over with the lack of this message in
    > >>> the kobject code.
    > >>>
    > >>> I do have this same message availble as a patch for the kobject core, it
    > >>> would be interesting if you could just run 2.6.24-rc4 with just this
    > >>> patch:
    > >>> http://www.kernel.org/pub/linux/kern...ect-warn.patch
    > >>>
    > >>> it might take some fuzz to fit properly, but all you really want to do
    > >>> is add:
    > >>> WARN_ON(atomic_read(&kobj->kref.refcount));
    > >>> before the kref_init() call in kobject_init().
    > >>>
    > >>> thanks,
    > >>>
    > >>> greg k-h
    > >> 2.6.24-rc4 with above patch booted fine without any warnings.
    > >> But 2.6.24-rc4-mm1 doesn't boot, it hangs after following messages.
    > >>
    > >>
    > >> e100: Intel(R) PRO/100 Network Driver, 3.5.23-k4-NAPI
    > >> e100: Copyright(c) 1999-2006 Intel Corporation
    > >> ipr: IBM Power RAID SCSI Device Driver version: 2.4.1 (April 24, 2007)
    > >> ipr 0000:d0:01.0: Found IOA with IRQ: 119
    > >> ipr 0000:d0:01.0: Starting IOA initialization sequence.
    > >> ipr 0000:d0:01.0: Adapter firmware version: 020A005E
    > >> ipr 0000:d0:01.0: IOA initialized.
    > >> scsi0 : IBM 570B Storage Adapter
    > >> scsi 0:0:3:0: Direct-Access IBM H0 HUS103014FL3800 RPQF PQ: 0 ANSI: 4
    > >> scsi 0:0:5:0: Direct-Access IBM H0 HUS103014FL3800 RPQF PQ: 0 ANSI: 4
    > >> scsi 0:0:8:0: Direct-Access IBM H0 HUS103014FL3800 RPQF PQ: 0 ANSI: 4
    > >> scsi 0:0:15:0: Enclosure IBM VSBPD4E2 U4SCSI 7134 PQ: 0 ANSI: 2
    > >> ------------[ cut here ]------------
    > >> Badness at lib/kref.c:33
    > >> NIP: c0000000002e1254 LR: c0000000002dfbd8 CTR: c0000000002e60f0
    > >> REGS: c00000003f0db050 TRAP: 0700 Not tainted (2.6.24-rc4-mm1)
    > >> MSR: 8000000000029032 CR: 28002042 XER: 0000000f
    > >> TASK = c00000003f0d78d0[1] 'swapper' THREAD: c00000003f0d8000 CPU: 0
    > >> GPR00: 0000000000000000 c00000003f0db2d0 c000000000724098 c00000003f131620
    > >> GPR04: fffffffffffffff1 fffffffffffffffe 000000000000000a ffffffffffffffff
    > >> GPR08: c00000003d4d9000 c00000003f0cbfe0 c000000000556591 0000000000000073
    > >> GPR12: 0000000024002084 c000000000651980 0000000000000000 0000000000000000
    > >> GPR16: 0000000000000000 d000080080080000 c00000000064d6f0 c00000003d4d9570
    > >> GPR20: c00000003d4d94b8 0000000000000002 c00000003d4d9170 c00000003d4d9170
    > >> GPR24: c00000003d4d9000 0000000000000001 c00000003d570d58 c00000003d570d18
    > >> GPR28: 0000000000000000 c00000003d4d9260 c0000000006b5400 c00000003f131618
    > >> NIP [c0000000002e1254] .kref_get+0x10/0x2c
    > >> LR [c0000000002dfbd8] .kobject_get+0x24/0x40
    > >> Call Trace:
    > >> [c00000003f0db2d0] [c00000003f0db360] 0xc00000003f0db360 (unreliable)
    > >> [c00000003f0db350] [c0000000002e00e8] .kobject_add+0x8c/0x21c
    > >> [c00000003f0db3e0] [c000000000344b00] .device_add+0xd4/0x680
    > >> [c00000003f0db4a0] [c0000000003a1c4c] .scsi_alloc_target+0x218/0x404
    > >> [c00000003f0db570] [c0000000003a1fb4] .__scsi_scan_target+0xa8/0x640
    > >> [c00000003f0db6b0] [c0000000003a25c4] .scsi_scan_channel+0x78/0xdc
    > >> [c00000003f0db750] [c0000000003a26f8] .scsi_scan_host_selected+0xd0/0x140
    > >> [c00000003f0db7f0] [c0000000003c3ff4] .ipr_probe+0x1270/0x1348

    > >
    > > This looks like a scsi issue to me, I don't see how the kref changes
    > > could cause this backtrace/oops, do you?
    > >
    > > thanks,
    > >
    > > greg k-h

    >
    > The 2.6.24-rc4 with the above patch, boots fine for me either, and with
    > 2.6.24-rc4-mm1 i get similar backtrace,
    >
    > Badness at lib/kref.c:33
    > NIP: c00000000021908c LR: c000000000217b88 CTR: c00000000029b71c
    > REGS: c00000003c066fc0 TRAP: 0700 Not tainted (2.6.24-rc4-mm1-autokern1)
    > MSR: 8000000000029032 CR: 88002022 XER: 00000001
    > TASK = c00000003ef4c840[339] 'insmod' THREAD: c00000003c064000 CPU: 0
    > GPR00: 0000000000000000 c00000003c067240 c0000000005d32c0 c00000003e0101a0
    > GPR04: fffffffffffffff2 fffffffffffffffe 000000000000000a 0000000000000002
    > GPR08: 0000000000000000 c00000003ef8ae50 ffffffffffffffff c000000000449269
    > GPR12: 0000000024002084 c000000000515980 0000000000000000 0000000000000000
    > GPR16: 0000000000000000 0000000000000000 0000000000240000 0000000000000000
    > GPR20: 0000000010000290 0000000000000002 c00000003ef3f970 c00000003ef3f970
    > GPR24: 0000000000000001 0000000000000000 c00000003c039958 c00000003c039918
    > GPR28: 0000000000000000 c00000003ef3fa60 c00000000058e588 c00000003e010198
    > NIP [c00000000021908c] .kref_get+0x10/0x2c
    > LR [c000000000217b88] .kobject_get+0x20/0x3c
    > Call Trace:
    > [c00000003c067240] [c000000000217a48] .kobject_set_name_vargs+0x38/0x60 (unreliable)
    > [c00000003c0672c0] [c000000000217ffc] .kobject_add+0x88/0x20c
    > [c00000003c067350] [c00000000029b7ec] .device_add+0xd0/0x648
    > [c00000003c067410] [d000000000613c84] .scsi_alloc_target+0x238/0x414 [scsi_mod]
    > [c00000003c0674e0] [d000000000614e70] .__scsi_scan_target+0xac/0x718 [scsi_mod]
    > [c00000003c067630] [d00000000061566c] .scsi_scan_channel+0x78/0xdc [scsi_mod]
    > [c00000003c0676d0] [d0000000006157f0] .scsi_scan_host_selected+0x120/0x194 [scsi_mod]
    > [c00000003c067780] [d000000000682148] .ibmvscsi_probe+0x450/0x4fc [ibmvscsic]
    > [c00000003c067870] [c000000000025fe8] .vio_bus_probe+0x74/0x9c
    > [c00000003c067900] [c00000000029f2c8] .driver_probe_device+0x110/0x1ec
    > [c00000003c067990] [c00000000029f57c] .__driver_attach+0xd0/0x160
    > [c00000003c067a20] [c00000000029da58] .bus_for_each_dev+0x7c/0xcc
    > [c00000003c067ad0] [c00000000029f634] .driver_attach+0x28/0x40
    > [c00000003c067b50] [c00000000029e6a4] .bus_add_driver+0xe8/0x2b4
    > [c00000003c067c00] [c00000000029fd80] .driver_register+0x80/0x9c
    > [c00000003c067c80] [c0000000000260b0] .vio_register_driver+0x40/0x5c
    > [c00000003c067d10] [d000000000682c04] .init_module+0x68/0xa4 [ibmvscsic]
    > [c00000003c067da0] [c00000000009301c] .sys_init_module+0xf4/0x1ac
    > [c00000003c067e30] [c00000000000872c] syscall_exit+0x0/0x40
    > Instruction dump:
    > 7d808120 4e800020 38a00000 4bfffad0 38000001 90030000 7c0004ac 4e800020
    > 80030000 7c0007b4 2f800000 40be0008 <0fe00000> 7c001828 30000001 7c00192d


    How about running 2.6.24-rc4 with _only_ the patch to this driver to
    convert it to krefs? Does that combination cause problems?

    The patch is at:
    http://www.kernel.org/pub/linux/kern...-kobject.patch

    and you can also try:
    http://www.kernel.org/pub/linux/kern...-kobject.patch
    if you have the hardware.

    thanks,

    greg k-h
    --
    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/

  4. Re: [PATCH x86/mm] x86 vDSO: canonicalize sysenter .eh_frame


    * Roland McGrath wrote:

    > Some assembler versions automagically optimize .eh_frame contents,
    > changing their size. The CFI in sysenter.S was not using optimal
    > formatting, so it would be changed by newer/smarter assemblers. This
    > ran afoul of the wired constant for padding out the other vDSO images
    > to match its size. This changes the original hand-coded source to use
    > the optimal format encoding for its operations. That leaves nothing
    > more for a fancy assembler to do, so the sizes will match the wired-in
    > expected size regardless of the assembler version.
    >
    > Signed-off-by: Roland McGrath ---


    thanks, applied.

    Ingo
    --
    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/

  5. Re: 2.6.24-rc4-mm1: VDSOSYM build error


    * Andrew Morton wrote:

    > On Thu, 6 Dec 2007 18:28:25 -0500
    > "Miles Lane" wrote:
    >
    > > How can I find Roland's patches, so I can try backing them out?
    > > I looked in the broken out patches and only saw one related
    > > to VDSO. Backing it out did not help. I tried searching for
    > > messages to LKML sent by "roland" but mostly got a bunch of
    > > folks sending spam.

    >
    > They're all clumped into git-x86.patch. Hard.


    in theory the git merges could be generated as a flat series of patch
    files:

    x86.git.foo-fixes.patch
    x86.git.bar-updates.patch
    x86.git.foo-fixes-feh.patch
    ...

    which could also include the commit log. "git-log -p" might be a
    suitable generator. For example, x86.git can be processed per commit,
    via this script:

    for N in `git-rev-list --reverse --no-merges --remove-empty master..mm`; do
    git-log -p $N
    done

    the following git-export-quilt script (just wrote it, might be buggy, so
    careful - and it blows away the patches/ directory wherever you run it)
    will generate a series file into patches/series that can be applied via
    quilt:

    rm -rf patches
    mkdir patches
    for N in `git-rev-list --reverse --no-merges --remove-empty master..mm`; do
    git-log -p -1 $N > .tmp
    export SUBJECT=`head -5 .tmp | tail -1`

    # generate filename out of subject line:
    FILE=x86.git-"`echo $SUBJECT | cut -c10- |
    tr '[unct:] \t' '-' | tr -s - | tr '[:upper:]' '[:lower:]'`"

    # generate unique name:
    while [ -f patches/$FILE.patch ]; do FILE="$FILE"_; done

    echo $FILE.patch
    mv .tmp patches/$FILE.patch
    echo $FILE.patch >> patches/series
    done

    ls -l patches/series

    i ran this script over x86.git and it produced a patch series with 247
    patches that quilt was able to push correctly. (in theory this concept
    should work for other git trees too - but i have not tried it)

    this would increase the series size quite substantially though - but it
    would make cherry-picking and patch based bisection a lot easier.

    Ingo
    --
    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/

  6. Re: 2.6.24-rc4-mm1

    On Wed, 5 Dec 2007, David Miller wrote:

    > From: Reuben Farrelly
    > Date: Thu, 06 Dec 2007 17:59:37 +1100
    >
    > > On 5/12/2007 4:17 PM, Andrew Morton wrote:
    > > > - Lots of device IDs have been removed from the e1000 driver and moved over
    > > > to e1000e. So if your e1000 stops working, you forgot to set CONFIG_E1000E.

    > >
    > > This non fatal oops which I have just noticed may be related to this change then
    > > - certainly looks networking related.
    > >
    > > WARNING: at net/ipv4/tcp_input.c:2518 tcp_fastretrans_alert()
    > > Pid: 0, comm: swapper Not tainted 2.6.24-rc4-mm1 #1
    > >
    > > Call Trace:
    > > [] tcp_fastretrans_alert+0x229/0xe63
    > > [] tcp_ack+0xa3f/0x127d
    > > [] tcp_rcv_established+0x55f/0x7f8
    > > [] tcp_v4_do_rcv+0xdb/0x3a7
    > > [] :nf_conntrack:nf_ct_deliver_cached_events+0x75/0x99

    >
    > No, it's from TCP assertions and changes added by Ilpo to the
    > net-2.6.25 tree recently.


    Yeah, this (very likely) due to the new SACK processing (in net-2.6.25).
    I'll look what could go wrong with fack_count calculations, most likely
    it's the reason (I've found earlier one out-of-place retransmission
    segment in one of my test case which already indicated that there's
    something incorrect with them but didn't have time to debug it yet).

    Thanks for report. Some info about how easily you can reproduce &
    couple of sentences about the test case might be useful later on when
    evaluating the fix.

    --
    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/

  7. [PATCH BUGFIX] hid: the `bit' in hidinput_mapping_quirks() is an out parameter

    Fix a panic, by changing
    hidinput_mapping_quirks(,, unsigned long *bit,)
    to
    hidinput_mapping_quirks(,, unsigned long **bit,)

    The `bit' in this function is an out parameter.

    Cc: Jiri Kosina
    Signed-off-by: Fengguang Wu
    ---
    drivers/hid/hid-input-quirks.c | 36 +++++++++++++++----------------
    drivers/hid/hid-input.c | 2 -
    include/linux/hid.h | 2 -
    3 files changed, 20 insertions(+), 20 deletions(-)

    --- linux-2.6.24-rc4-mm1.orig/include/linux/hid.h
    +++ linux-2.6.24-rc4-mm1/include/linux/hid.h
    @@ -526,7 +526,7 @@ extern void hidinput_disconnect(struct h
    int hid_set_field(struct hid_field *, unsigned, __s32);
    int hid_input_report(struct hid_device *, int type, u8 *, int, int);
    int hidinput_find_field(struct hid_device *hid, unsigned int type, unsigned int code, struct hid_field **field);
    -int hidinput_mapping_quirks(struct hid_usage *, struct input_dev *, unsigned long *, int *);
    +int hidinput_mapping_quirks(struct hid_usage *, struct input_dev *, unsigned long **, int *);
    void hidinput_event_quirks(struct hid_device *, struct hid_field *, struct hid_usage *, __s32);
    int hidinput_apple_event(struct hid_device *, struct input_dev *, struct hid_usage *, __s32);
    void hid_input_field(struct hid_device *hid, struct hid_field *field, __u8 *data, int interrupt);
    --- linux-2.6.24-rc4-mm1.orig/drivers/hid/hid-input.c
    +++ linux-2.6.24-rc4-mm1/drivers/hid/hid-input.c
    @@ -382,7 +382,7 @@ static void hidinput_configure_usage(str
    }

    /* handle input mappings for quirky devices */
    - ret = hidinput_mapping_quirks(usage, input, bit, &max);
    + ret = hidinput_mapping_quirks(usage, input, &bit, &max);
    if (ret)
    goto mapped;

    --- linux-2.6.24-rc4-mm1.orig/drivers/hid/hid-input-quirks.c
    +++ linux-2.6.24-rc4-mm1/drivers/hid/hid-input-quirks.c
    @@ -16,16 +16,16 @@
    #include
    #include

    -#define map_abs(c) do { usage->code = c; usage->type = EV_ABS; bit = input->absbit; *max = ABS_MAX; } while (0)
    -#define map_rel(c) do { usage->code = c; usage->type = EV_REL; bit = input->relbit; *max = REL_MAX; } while (0)
    -#define map_key(c) do { usage->code = c; usage->type = EV_KEY; bit = input->keybit; *max = KEY_MAX; } while (0)
    -#define map_led(c) do { usage->code = c; usage->type = EV_LED; bit = input->ledbit; *max = LED_MAX; } while (0)
    +#define map_abs(c) do { usage->code = c; usage->type = EV_ABS; *bit = input->absbit; *max = ABS_MAX; } while (0)
    +#define map_rel(c) do { usage->code = c; usage->type = EV_REL; *bit = input->relbit; *max = REL_MAX; } while (0)
    +#define map_key(c) do { usage->code = c; usage->type = EV_KEY; *bit = input->keybit; *max = KEY_MAX; } while (0)
    +#define map_led(c) do { usage->code = c; usage->type = EV_LED; *bit = input->ledbit; *max = LED_MAX; } while (0)

    -#define map_abs_clear(c) do { map_abs(c); clear_bit(c, bit); } while (0)
    -#define map_key_clear(c) do { map_key(c); clear_bit(c, bit); } while (0)
    +#define map_abs_clear(c) do { map_abs(c); clear_bit(c, *bit); } while (0)
    +#define map_key_clear(c) do { map_key(c); clear_bit(c, *bit); } while (0)

    static int quirk_belkin_wkbd(struct hid_usage *usage, struct input_dev *input,
    - unsigned long *bit, int *max)
    + unsigned long **bit, int *max)
    {
    if ((usage->hid & HID_USAGE_PAGE) != HID_UP_CONSUMER)
    return 0;
    @@ -41,7 +41,7 @@ static int quirk_belkin_wkbd(struct hid_
    }

    static int quirk_cherry_cymotion(struct hid_usage *usage, struct input_dev *input,
    - unsigned long *bit, int *max)
    + unsigned long **bit, int *max)
    {
    if ((usage->hid & HID_USAGE_PAGE) != HID_UP_CONSUMER)
    return 0;
    @@ -57,7 +57,7 @@ static int quirk_cherry_cymotion(struct
    }

    static int quirk_logitech_ultrax_remote(struct hid_usage *usage, struct input_dev *input,
    - unsigned long *bit, int *max)
    + unsigned long **bit, int *max)
    {
    if ((usage->hid & HID_USAGE_PAGE) != HID_UP_LOGIVENDOR)
    return 0;
    @@ -90,7 +90,7 @@ static int quirk_logitech_ultrax_remote(
    }

    static int quirk_chicony_tactical_pad(struct hid_usage *usage, struct input_dev *input,
    - unsigned long *bit, int *max)
    + unsigned long **bit, int *max)
    {
    if ((usage->hid & HID_USAGE_PAGE) != HID_UP_MSVENDOR)
    return 0;
    @@ -115,7 +115,7 @@ static int quirk_chicony_tactical_pad(st
    }

    static int quirk_microsoft_ergonomy_kb(struct hid_usage *usage, struct input_dev *input,
    - unsigned long *bit, int *max)
    + unsigned long **bit, int *max)
    {
    if ((usage->hid & HID_USAGE_PAGE) != HID_UP_MSVENDOR)
    return 0;
    @@ -138,7 +138,7 @@ static int quirk_microsoft_ergonomy_kb(s
    }

    static int quirk_microsoft_presenter_8k(struct hid_usage *usage, struct input_dev *input,
    - unsigned long *bit, int *max)
    + unsigned long **bit, int *max)
    {
    if ((usage->hid & HID_USAGE_PAGE) != HID_UP_MSVENDOR)
    return 0;
    @@ -156,7 +156,7 @@ static int quirk_microsoft_presenter_8k(
    }

    static int quirk_petalynx_remote(struct hid_usage *usage, struct input_dev *input,
    - unsigned long *bit, int *max)
    + unsigned long **bit, int *max)
    {
    if (((usage->hid & HID_USAGE_PAGE) != HID_UP_LOGIVENDOR) &&
    ((usage->hid & HID_USAGE_PAGE) != HID_UP_CONSUMER))
    @@ -184,7 +184,7 @@ static int quirk_petalynx_remote(struct
    }

    static int quirk_logitech_wireless(struct hid_usage *usage, struct input_dev *input,
    - unsigned long *bit, int *max)
    + unsigned long **bit, int *max)
    {
    if ((usage->hid & HID_USAGE_PAGE) != HID_UP_CONSUMER)
    return 0;
    @@ -236,7 +236,7 @@ static int quirk_logitech_wireless(struc
    }

    static int quirk_cherry_genius_29e(struct hid_usage *usage, struct input_dev *input,
    - unsigned long *bit, int *max)
    + unsigned long **bit, int *max)
    {
    if ((usage->hid & HID_USAGE_PAGE) != HID_UP_CONSUMER)
    return 0;
    @@ -254,7 +254,7 @@ static int quirk_cherry_genius_29e(struc
    }

    static int quirk_btc_8193(struct hid_usage *usage, struct input_dev *input,
    - unsigned long *bit, int *max)
    + unsigned long **bit, int *max)
    {
    if ((usage->hid & HID_USAGE_PAGE) != HID_UP_CONSUMER)
    return 0;
    @@ -307,7 +307,7 @@ static int quirk_btc_8193(struct hid_usa
    static const struct hid_input_blacklist {
    __u16 idVendor;
    __u16 idProduct;
    - int (*quirk)(struct hid_usage *, struct input_dev *, unsigned long *, int *);
    + int (*quirk)(struct hid_usage *, struct input_dev *, unsigned long **, int *);
    } hid_input_blacklist[] = {
    { VENDOR_ID_BELKIN, DEVICE_ID_BELKIN_WIRELESS_KEYBOARD, quirk_belkin_wkbd },

    @@ -335,7 +335,7 @@ static const struct hid_input_blacklist

    int hidinput_mapping_quirks(struct hid_usage *usage,
    struct input_dev *input,
    - unsigned long *bit, int *max)
    + unsigned long **bit, int *max)
    {
    struct hid_device *device = input_get_drvdata(input);
    int i = 0;

    --
    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/

  8. broken suspend (sched related) [Was: 2.6.24-rc4-mm1]

    On 12/05/2007 06:17 AM, Andrew Morton wrote:
    > ftp://ftp.kernel.org/pub/linux/kerne....6.24-rc4-mm1/


    > git-sched.patch


    breaks suspend here since -rc3-mm2. More precisely, this one:
    softlockup: automatically detect hung TASK_UNINTERRUPTIBLE tasks

    2.6.24-rc4-mm1 minus this one works just fine. Otherwise disks stop, graphics
    stops and then it hangs not powering down.

    Core 2 Duo, SMP kernel, voluntary preempt, 250 HZ, SLUB, 64 bit.

    Ideas?
    --
    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/

  9. Re: broken suspend (sched related) [Was: 2.6.24-rc4-mm1]


    * Jiri Slaby wrote:

    > On 12/05/2007 06:17 AM, Andrew Morton wrote:
    > > ftp://ftp.kernel.org/pub/linux/kerne....6.24-rc4-mm1/

    >
    > > git-sched.patch

    >
    > breaks suspend here since -rc3-mm2. More precisely, this one:
    > softlockup: automatically detect hung TASK_UNINTERRUPTIBLE tasks
    >
    > 2.6.24-rc4-mm1 minus this one works just fine. Otherwise disks stop, graphics
    > stops and then it hangs not powering down.
    >
    > Core 2 Duo, SMP kernel, voluntary preempt, 250 HZ, SLUB, 64 bit.
    >
    > Ideas?


    thanks for tracking it down. Does the patch below help?

    Ingo

    ---
    kernel/softlockup.c | 8 ++++++--
    1 file changed, 6 insertions(+), 2 deletions(-)

    Index: linux/kernel/softlockup.c
    ================================================== =================
    --- linux.orig/kernel/softlockup.c
    +++ linux/kernel/softlockup.c
    @@ -101,7 +101,11 @@ void softlockup_tick(void)

    now = get_timestamp(this_cpu);

    - /* Warn about unreasonable delays: */
    + /* Wake up the high-prio watchdog task every second: */
    + if (now > (touch_timestamp + 1))
    + wake_up_process(per_cpu(watchdog_task, this_cpu));
    +
    + /* Warn about unreasonable 10+ seconds delays: */
    if (now <= (touch_timestamp + softlockup_thresh))
    return;

    @@ -214,7 +218,7 @@ static int watchdog(void *__bind_cpu)
    */
    while (!kthread_should_stop()) {
    touch_softlockup_watchdog();
    - msleep_interruptible(10000);
    + schedule();

    /*
    * Only do the hung-tasks check on one CPU:
    --
    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/

  10. Re: broken suspend (sched related) [Was: 2.6.24-rc4-mm1]


    * Ingo Molnar wrote:

    > thanks for tracking it down. Does the patch below help?


    oops, that should be the patch below. Otherwise the watchdog kernel
    threads will just loop around.

    Ingo

    ---
    kernel/softlockup.c | 9 +++++++--
    1 file changed, 7 insertions(+), 2 deletions(-)

    Index: linux/kernel/softlockup.c
    ================================================== =================
    --- linux.orig/kernel/softlockup.c
    +++ linux/kernel/softlockup.c
    @@ -101,7 +101,11 @@ void softlockup_tick(void)

    now = get_timestamp(this_cpu);

    - /* Warn about unreasonable delays: */
    + /* Wake up the high-prio watchdog task every second: */
    + if (now > (touch_timestamp + 1))
    + wake_up_process(per_cpu(watchdog_task, this_cpu));
    +
    + /* Warn about unreasonable 10+ seconds delays: */
    if (now <= (touch_timestamp + softlockup_thresh))
    return;

    @@ -213,8 +217,9 @@ static int watchdog(void *__bind_cpu)
    * debug-printout triggers in softlockup_tick().
    */
    while (!kthread_should_stop()) {
    + set_current_state(TASK_INTERRUPTIBLE);
    touch_softlockup_watchdog();
    - msleep_interruptible(10000);
    + schedule();

    /*
    * Only do the hung-tasks check on one CPU:
    --
    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/

  11. [PATCH] md: balance braces in raid5 debug code

    Hello,

    This patch fixes the compilation breakage. Normally you don't see
    that as this piece of code is under #ifdef DEBUG. This was introduced by
    git-md-accel.patch at line 3179.

    Signed-off-by: Mariusz Kozlowski

    drivers/md/raid5.c | 2 +-
    1 file changed, 1 insertion(+), 1 deletion(-)

    --- linux-2.6.24-rc4-mm1-a/drivers/md/raid5.c 2007-12-06 09:27:02.000000000 +0100
    +++ linux-2.6.24-rc4-mm1-b/drivers/md/raid5.c 2007-12-06 09:28:14.000000000 +0100
    @@ -4972,7 +4972,7 @@ static void print_sh (struct seq_file *s
    seq_printf(seq, "sh %llu, count %d.\n",
    (unsigned long long)sh->sector, atomic_read(&sh->count));
    seq_printf(seq, "sh %llu, ", (unsigned long long)sh->sector);
    - for (i = 0; i < sh->sq->disks; i++) {
    + for (i = 0; i < sh->sq->disks; i++)
    seq_printf(seq, "(cache%d: %p %ld) ",
    i, sh->dev[i].page, sh->dev[i].flags);
    seq_printf(seq, "\n");


    --
    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/

  12. Re: [dm-devel] Re: 2.6.24-rc4-mm1

    On Fri, 07 Dec 2007 00:24:04 +0100, Kay Sievers said:
    > On Thu, 2007-12-06 at 18:12 -0500, Valdis.Kletnieks@vt.edu wrote:
    > > On Thu, 06 Dec 2007 23:04:12 +0100, Kay Sievers said:
    > >
    > > > What's the value of SYSFS_DEPRECATED? Care to set it to yes, if it isn't,
    > > > and try again?

    > >
    > > I *knew* there was a D'Oh! error in here.
    > >
    > > Bisection is fast closing in on gregkh-driver-block-device.patch, which broke
    > > my LVM almost the exact same way the *last* time it showed up in -mm

    >
    > Oh, it must not, if SYSFS_DEPRECATED=y is set. I hope we fixed all
    > issues. Please let us know if it does not work, then we will need to
    > look into it.


    I changed SYSFS_DEPRECATED to y, and it was able to boot with the same old
    initrd I've been using for a while.

    Note that I had it set to 'n' for at least the last 4-5 -mm kernels, so it
    *was* working fine without it..

    > > > A fix for LVM to handle symlinks instead of directories is in the LVM
    > > > CVS tree, but there wasn't a release since August.

    > >
    > > I seem to recall it was 'nash' rather than LVM that had the indigestion the
    > > last time around.

    >
    > I think that a recent nash should work, even with SYSFS_DEPRECATED=n.
    > Anyway, nothing should change when SYSFS_DEPRECATED set, nash works fine
    > here, with that.


    It was working fine with =n here until -rc4-mm1 as well, that's why it's a bit
    of a surprise. What got added to the 'deprecated' list in this iteration?

    Now for the truly odd part - I just tried with a rebuilt initrd that included
    the lvm.static from last night's Rawhide (lvm2-2.02.29-1.fc9). And that didn't
    work any better.

    So to summarize: (old lvm == 2.02.24)

    release SYSFS_DEPRECATED lvm2 works
    -rc3-mm2 N old yes
    -rc4-mm1 N old no
    -rc4-mm1 Y old yes
    -rc4-mm1 N new no

    (I'm sure looking at that, everybody is now going 'WTF??!?'

    gregkh-driver-driver-core-fix-class-glue-dir-cleanup-logic.patch and
    gregkh-driver-block-device.patch are the only patches left in the (very small)
    bisect window that reference SYSFS_DEPRECATED at all (according to grep)

    Anybody got any brilliant ideas?





    -----BEGIN PGP SIGNATURE-----
    Version: GnuPG v1.4.7 (GNU/Linux)
    Comment: Exmh version 2.5 07/13/2001

    iD8DBQFHWY7ucC3lWbTT17ARAqaWAKDuUACTkOjPdhc/8MsYUYCmmIW2zACgihYh
    1LDyFqmjT6mLdHldes8KUP4=
    =mXXh
    -----END PGP SIGNATURE-----


  13. Re: [dm-devel] Re: 2.6.24-rc4-mm1

    On Fri, 2007-12-07 at 13:20 -0500, Valdis.Kletnieks@vt.edu wrote:
    > On Fri, 07 Dec 2007 00:24:04 +0100, Kay Sievers said:
    > > On Thu, 2007-12-06 at 18:12 -0500, Valdis.Kletnieks@vt.edu wrote:
    > > > On Thu, 06 Dec 2007 23:04:12 +0100, Kay Sievers said:
    > > >
    > > > > What's the value of SYSFS_DEPRECATED? Care to set it to yes, if it isn't,
    > > > > and try again?
    > > >
    > > > I *knew* there was a D'Oh! error in here.
    > > >
    > > > Bisection is fast closing in on gregkh-driver-block-device.patch, which broke
    > > > my LVM almost the exact same way the *last* time it showed up in -mm

    > >
    > > Oh, it must not, if SYSFS_DEPRECATED=y is set. I hope we fixed all
    > > issues. Please let us know if it does not work, then we will need to
    > > look into it.

    >
    > I changed SYSFS_DEPRECATED to y, and it was able to boot with the same old
    > initrd I've been using for a while.


    Great!

    > Note that I had it set to 'n' for at least the last 4-5 -mm kernels, so it
    > *was* working fine without it..


    Yeah, but the raw block kobjects got converted to devices, which are
    symlinks with SYSFS_DEPRECATED=n.

    > > > > A fix for LVM to handle symlinks instead of directories is in the LVM
    > > > > CVS tree, but there wasn't a release since August.
    > > >
    > > > I seem to recall it was 'nash' rather than LVM that had the indigestion the
    > > > last time around.

    > >
    > > I think that a recent nash should work, even with SYSFS_DEPRECATED=n.
    > > Anyway, nothing should change when SYSFS_DEPRECATED set, nash works fine
    > > here, with that.

    >
    > It was working fine with =n here until -rc4-mm1 as well, that's why it's a bit
    > of a surprise. What got added to the 'deprecated' list in this iteration?


    Block devices got integrated in the driver model.

    > Now for the truly odd part - I just tried with a rebuilt initrd that included
    > the lvm.static from last night's Rawhide (lvm2-2.02.29-1.fc9). And that didn't
    > work any better.
    >
    > So to summarize: (old lvm == 2.02.24)
    >
    > release SYSFS_DEPRECATED lvm2 works
    > -rc3-mm2 N old yes
    > -rc4-mm1 N old no
    > -rc4-mm1 Y old yes
    > -rc4-mm1 N new no
    >
    > (I'm sure looking at that, everybody is now going 'WTF??!?'
    >
    > gregkh-driver-driver-core-fix-class-glue-dir-cleanup-logic.patch and
    > gregkh-driver-block-device.patch are the only patches left in the (very small)
    > bisect window that reference SYSFS_DEPRECATED at all (according to grep)
    >
    > Anybody got any brilliant ideas?


    I guess it's nash again, which version is it?

    You probably need to wait for Red Hat to catch up, and don't disable
    SYSFS_DEPRECATED for now, they don't support that.

    Kay

    --
    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/

  14. Re: [dm-devel] Re: 2.6.24-rc4-mm1

    On Fri, 07 Dec 2007 19:44:29 +0100, Kay Sievers said:

    > > Anybody got any brilliant ideas?

    >
    > I guess it's nash again, which version is it?


    Confirmed - nash again. 6.0.9 does not work, upgrading to 6.0.19 works.

    init/Kconfig says this for SYSFS_DEPRECATED (which is where I got lead astray,
    as most of my laptop is Fedora Rawhide and therefor "released this week"):

    If you are using a distro that was released in 2006 or later,
    it should be safe to say N here.

    nash 6.0.9 came out in April 2007, and I suspect, but can't prove, that the
    relevant change was this one:

    * Mon Aug 27 2007 Peter Jones - 6.0.12-2
    - Fix segfault in scsi vpd probe code
    - Fix block device creation

    That was just over 3 months ago. We probably need to fix that help text,
    but I admit not being sure what guidance we should give now....

    -----BEGIN PGP SIGNATURE-----
    Version: GnuPG v1.4.7 (GNU/Linux)
    Comment: Exmh version 2.5 07/13/2001

    iD8DBQFHWazncC3lWbTT17ARAs16AKDXkv2UrOsdk3oLKLYGqs UyYzYpnACg8KSp
    C3+qRTiLDfiaNruTEzgHqx0=
    =v8o5
    -----END PGP SIGNATURE-----


  15. Re: [dm-devel] Re: 2.6.24-rc4-mm1

    On Fri, 2007-12-07 at 15:28 -0500, Valdis.Kletnieks@vt.edu wrote:
    > On Fri, 07 Dec 2007 19:44:29 +0100, Kay Sievers said:
    >
    > > > Anybody got any brilliant ideas?

    > >
    > > I guess it's nash again, which version is it?

    >
    > Confirmed - nash again. 6.0.9 does not work, upgrading to 6.0.19 works.


    Oh, cool!

    I expected 6.0.9 to contain the fix though:
    http://lkml.org/lkml/2007/6/7/209

    > init/Kconfig says this for SYSFS_DEPRECATED (which is where I got lead astray,
    > as most of my laptop is Fedora Rawhide and therefor "released this week"):
    >
    > If you are using a distro that was released in 2006 or later,
    > it should be safe to say N here.
    >
    > nash 6.0.9 came out in April 2007, and I suspect, but can't prove, that the
    > relevant change was this one:
    >
    > * Mon Aug 27 2007 Peter Jones - 6.0.12-2
    > - Fix segfault in scsi vpd probe code
    > - Fix block device creation
    >
    > That was just over 3 months ago.


    Yeah right, even if it is fixed earlier, it's at least 6 months.

    > We probably need to fix that help text,
    > but I admit not being sure what guidance we should give now....


    Right, the help text needs to be changed. There are distros like Red Hat
    which don't support !DEPRECATED at all today, so we should probably just
    remove the date and add that to the help text.

    On the other hand, we are currently considering making the DEPRECATED
    behavior a boot-time option, so it can be changed on the kernel command
    line instead of a compile option. There would only be a compile-time
    default to set.
    We will get to that after the current kobject work (~100 patches) in
    Greg's tree is finished.

    Thanks for your help and patience,
    Kay

    --
    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/

  16. Re: 2.6.24-rc4-mm1 kobject changes broken with hvcs driver on powerpc


    > How about running 2.6.24-rc4 with _only_ the patch to this driver to
    > convert it to krefs? Does that combination cause problems?
    >
    > The patch is at:
    > http://www.kernel.org/pub/linux/kern...-kobject.patch


    This patch works fine with _changes_ on 2.6.24-rc4. I can confirm that
    it's not a kref problem in that case. This patch still assumes that
    kref_get() returns a value. This is no longer true. The kref_get() call
    site needs to be changed.

    --
    Warm Regards,
    Balbir Singh
    Linux Technology Center
    IBM, ISTL
    --
    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/

  17. Re: 2.6.24-rc4-mm1

    On Dec 6, 2007 9:12 PM, Dave Young wrote:
    > Hi,
    >
    > 2.6.24-rc4-mm1 build failed at drivers/net/wireless/ath5k/base.c for some inline functions like this:
    > drivers/net/wireless/ath5k/base.c:292: sorry, unimplemented: inlining failed in call to 'ath5k_extend_tsf': function body not available
    >
    > fix it with adjust the order of inline function body.
    >
    > Signed-off-by: Dave Young


    Acked-by: Luis R. Rodriguez

    Thanks Dave. What version of gcc were you using? I haven't run into this.

    BTW, nothing new was added in this patch, things were just shifted,
    but even that may be copyrightable. Is it fair to assume you are
    licensing these changes under the same license the file is in?

    For this file we'd usually use:

    Changes-licensed-under: 3-clause-BSD

    For future reference:

    http://linuxwireless.org/en/develope...ensed-undertag

    Luis
    --
    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/

  18. Re: 2.6.24-rc4-mm1: undefined reference to `compat_sys_timerfd' on sparc64

    Hello,

    I tried it on sun ultra 60 (dual sparc64) station. Unfortunately it failed
    to compile.

    AS arch/sparc64/lib/xor.o
    AR arch/sparc64/lib/lib.a
    GEN .version
    CHK include/linux/compile.h
    dnsdomainname: Unknown host
    UPD include/linux/compile.h
    CC init/version.o
    LD init/built-in.o
    LD .tmp_vmlinux1
    arch/sparc64/kernel/head.o: In function `sys_call_table32':
    arch/sparc64/kernel/head.S.text+0x224e0): undefined reference to `compat_sys_timerfd'
    make: *** [.tmp_vmlinux1] Error 1

    Any hints?

    Regards,

    Mariusz

    Linux sparc64 2.6.23-gentoo-r3 #4 SMP PREEMPT Sat Dec 8 00:50:12 CET 2007 sparc64 sun4u TI UltraSparc II (BlackBird) GNU/Linux

    Gnu C 4.1.1
    Gnu make 3.81
    binutils 2.17
    util-linux 2.12r
    mount 2.12r
    module-init-tools 3.2.2
    e2fsprogs 1.39
    Linux C Library 2.5
    Dynamic linker (ldd) 2.5
    Procps 3.2.6
    Net-tools 1.60
    Kbd 1.12
    Sh-utils 6.4
    udev 104
    Modules Loaded sr_mod cdrom sg



  19. Re: 2.6.24-rc4-mm1: undefined reference to `compat_sys_timerfd' on sparc64

    On Sat, 8 Dec 2007 01:04:55 +0100
    Mariusz Kozlowski wrote:

    > Hello,
    >
    > I tried it on sun ultra 60 (dual sparc64) station. Unfortunately it failed
    > to compile.
    >
    > AS arch/sparc64/lib/xor.o
    > AR arch/sparc64/lib/lib.a
    > GEN .version
    > CHK include/linux/compile.h
    > dnsdomainname: Unknown host
    > UPD include/linux/compile.h
    > CC init/version.o
    > LD init/built-in.o
    > LD .tmp_vmlinux1
    > arch/sparc64/kernel/head.o: In function `sys_call_table32':
    > arch/sparc64/kernel/head.S.text+0x224e0): undefined reference to `compat_sys_timerfd'
    > make: *** [.tmp_vmlinux1] Error 1


    argh, sorry, I am soooooo fed up with fixing that patch.

    --- a/arch/sparc64/kernel/systbls.S~timerfd-v3-new-timerfd-api-sparc64-fix
    +++ a/arch/sparc64/kernel/systbls.S
    @@ -80,7 +80,7 @@ sys_call_table32:
    .word sys_fchmodat, sys_faccessat, compat_sys_pselect6, compat_sys_ppoll, sys_unshare
    /*300*/ .word compat_sys_set_robust_list, compat_sys_get_robust_list, compat_sys_migrate_pages, compat_sys_mbind, compat_sys_get_mempolicy
    .word compat_sys_set_mempolicy, compat_sys_kexec_load, compat_sys_move_pages, sys_getcpu, compat_sys_epoll_pwait
    -/*310*/ .word compat_sys_utimensat, compat_sys_signalfd, compat_sys_timerfd, sys_eventfd, compat_sys_fallocate
    +/*310*/ .word compat_sys_utimensat, compat_sys_signalfd, sys_ni_syscall, sys_eventfd, compat_sys_fallocate

    #endif /* CONFIG_COMPAT */

    _

    Or should this have been sys_nis_syscall()?


    I should have picked this up in cross-build testing but iirc
    sparc64 broke for other reasons. Let me check on that.
    --
    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/

  20. Re: broken suspend (sched related) [Was: 2.6.24-rc4-mm1]

    On 12/07/2007 06:51 PM, Ingo Molnar wrote:
    > * Ingo Molnar wrote:
    >
    >> thanks for tracking it down. Does the patch below help?

    >
    > oops, that should be the patch below. Otherwise the watchdog kernel
    > threads will just loop around.
    >
    > Ingo
    >
    > ---
    > kernel/softlockup.c | 9 +++++++--
    > 1 file changed, 7 insertions(+), 2 deletions(-)
    >
    > Index: linux/kernel/softlockup.c
    > ================================================== =================
    > --- linux.orig/kernel/softlockup.c
    > +++ linux/kernel/softlockup.c
    > @@ -101,7 +101,11 @@ void softlockup_tick(void)
    >
    > now = get_timestamp(this_cpu);
    >
    > - /* Warn about unreasonable delays: */
    > + /* Wake up the high-prio watchdog task every second: */
    > + if (now > (touch_timestamp + 1))
    > + wake_up_process(per_cpu(watchdog_task, this_cpu));
    > +
    > + /* Warn about unreasonable 10+ seconds delays: */
    > if (now <= (touch_timestamp + softlockup_thresh))
    > return;
    >
    > @@ -213,8 +217,9 @@ static int watchdog(void *__bind_cpu)
    > * debug-printout triggers in softlockup_tick().
    > */
    > while (!kthread_should_stop()) {
    > + set_current_state(TASK_INTERRUPTIBLE);
    > touch_softlockup_watchdog();
    > - msleep_interruptible(10000);
    > + schedule();
    >
    > /*
    > * Only do the hung-tasks check on one CPU:


    Unfortunately no change here.
    --
    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/

+ Reply to Thread
Page 3 of 6 FirstFirst 1 2 3 4 5 ... LastLast