[lkml]   [2005]   [Aug]   [17]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
Messages in this thread
    SubjectRe: 2.6.13-rc6-rt6

    * Steven Rostedt <> wrote:

    > On Wed, 2005-08-17 at 10:24 -0400, Steven Rostedt wrote:
    > > OK the output from netconsole still seems like netconsole itself is
    > > causing some problems. But I think it is also showing this lockup. I'll
    > > recompile my kernel as UP and see if netconsole works fine.
    > Well, the UP kernel boots on my laptop, but netconsole gives strange
    > warnings.
    > OK, what's the scoop with the illegal_API_call? What is it about, and
    > what is the expected work around?

    this is a recent change: i've started flagging "naked" use of
    local_irq_disable(), because it's a problem on PREEMPT_RT and it's a
    potential SMP bug on upstream kernels. A local_irq_disable() is
    converted either to raw_local_irq_disable() when justified (it's mostly
    only justified for lowlevel arch code), or is eliminated totally.
    (either by merging it into a nearby spin_lock API call, or by removing
    it altogether, making sure that code doesnt break).

    Right now we print a warning on the first such API use, and then shut up
    about it. All local_irq_() APIs map to NOPs. (we keep the PF_IRQSOFF
    flag for compatibility, but only to get irqs_off() right which in turn
    shuts off a number of BUG_ON(!irqs_disabled()) warnings, and it doesnt
    have any other functional purpose.)

    the desired end-result would be the total elimination of local_irq_*()
    API calls.

    > I'm also getting the following output on shutdown:
    > NET: Registered protocol family 31
    > Bluetooth: HCI device and connection manager initialized
    > Bluetooth: HCI socket layer initialized
    > Bluetooth: L2CAP ver 2.7
    > Bluetooth: L2CAP socket layer initialized
    > Bluetooth: RFCOMM ver 1.5
    > Bluetooth: RFCOMM socket layer initialized
    > Bluetooth: RFCOMM TTY layer initialized
    > BUG: nonzero lock count 1 at exit time?
    > nfsd: 4696 [f7183830, 115]
    > [<c0136922>] check_no_held_locks+0x62/0x330 (8)
    > [<c011df67>] do_exit+0x257/0x480 (32)
    > [<c013d052>] __module_put_and_exit+0x52/0x70 (40)
    > [<f8d54583>] nfsd+0x2b3/0x340 [nfsd] (12)
    > [<f8d542d0>] nfsd+0x0/0x340 [nfsd] (48)
    > [<c010140d>] kernel_thread_helper+0x5/0x18 (16)
    > ---------------------------
    > | preempt count: 00000000 ]
    > | 0-level deep critical section nesting:
    > ----------------------------------------
    > ------------------------------
    > | showing all locks held by: | (nfsd/4696 [f7183830, 116]):
    > ------------------------------
    > #001: [c038e184] {kernel_sem.lock}
    > ... acquired at: lock_kernel+0x21/0x40
    > BUG: nfsd/4696, BKL held at task exit time!

    hm, it seems nfsd forgets to do an unlock_kernel() in some exit path it
    seems? We are enforcing strict balanced lock use in PREEMPT_RT - the
    upstream kernel is more relaxed about it.

    > And it goes on and on. This happens everytime. Without netconsole, I
    > only get the nonzero lock count error. Also, one of my lockups on SMP
    > had to do with the kernel_thread_helper:
    > Using IPI Shortcut mode
    > khelper/794[CPU#0]: BUG in set_new_owner at kernel/rt.c:916

    this is a 'must not happen'. Somehow lock->held list got non-empty.
    Maybe some use-after-free thing? Havent seen it myself.

    To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
    the body of a message to
    More majordomo info at
    Please read the FAQ at

     \ /
      Last update: 2005-08-17 18:25    [W:0.031 / U:10.540 seconds]
    ©2003-2017 Jasper Spaans. hosted at Digital OceanAdvertise on this site