[lkml]   [2007]   [Apr]   [25]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
Messages in this thread
    SubjectRe: 2.6.21-rc7-mm1 BUG at kernel/sched-clock.c:175 init_sched_clock()
    Andrew Morton wrote:
    >> No, that would break host probing. The port is in frozen (controller
    >> initialized and IRQs masked off) state, so it's not allowed to take
    >> interrupt.
    > Sounds dodgy. What happens if the IRQ line is shared with some other
    > device? We'll enter ahci_interrupt(). We've alread set up ->port_map and
    > ->n_ports so we're wholly dependent upon that read from HOST_IRQ_STAT
    > returning zeroes.

    Shared IRQ is okay because ahci has pending IRQ register which is masked
    by ->freeze(). Controllers which don't have such feature check qc
    status to determine whether it's expecting IRQ, so it's okay for them
    too. So, AFAIK, libata is okay with shared IRQs.

    > /* sigh. 0xffffffff is a valid return from h/w */
    > if that happens we're dead, aren't we?

    Yes, we are. :-)

    >> If interrupt triggers at this point, it's low level driver
    >> bug. Berck, how reliably can you reproduce this problem? Can you post
    >> the result of 'lspci -nn'?
    > Berck doesn't apepar to be sharing that IRQ, so it'll be something else.

    I'm pretty sure Berck's problem is caused by ->freeze() not clearing
    pending IRQ bit. We haven't been too strict about ->freeze().
    Considering the above 0xffffffff case, I agree it's better to fix it in
    the core instead of fixing each LLD. Will brew up another patch.


    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: 2007-04-25 11:17    [W:0.034 / U:149.492 seconds]
    ©2003-2016 Jasper Spaans. hosted at Digital OceanAdvertise on this site