Rune Torgersen wrote:> Scott Wood wrote:
> Of course I then ran headfirst into another one
> This one seems to happen when I attempt to read flash through an mtd
> driver.
Both if these is hitting a BUG_ON in kmap_atomic
(include/asm-powerpc/highmem.h)
>
> Oops: Exception in kernel mode, si
Scott Wood wrote:
> Rune Torgersen wrote:
>> Scott Wood wrote:
>>> Try calling irq_set_chip_and_handler() with handle_level_irq, rather
>>> than irq_set_chip(). The -rt patch doesn't seem to have threadified
>>> the __do_IRQ() path.
>>
>> The demuxer is setting itself up with set_irq_chained ha
Rune Torgersen wrote:
Scott Wood wrote:
Try calling irq_set_chip_and_handler() with handle_level_irq, rather
than irq_set_chip(). The -rt patch doesn't seem to have threadified
the __do_IRQ() path.
The demuxer is setting itself up with set_irq_chained handler(), any
pointers on how to chang
Scott Wood wrote:
> Try calling irq_set_chip_and_handler() with handle_level_irq, rather
> than irq_set_chip(). The -rt patch doesn't seem to have threadified
> the __do_IRQ() path.
The demuxer is setting itself up with set_irq_chained handler(), any
pointers on how to change to irq_set_chip_an
Rune Torgersen wrote:
Scott Wood wrote:
Almost certainly the latter. Is the disk interrupt shared with any
other interrupts, that are marked IRQF_NODELAY? The -rt
patch doesn't seem to handle mixing the two well.
Disk is on a muxed PCI interrupt. None of the other interrupts on the
mux is fi
Scott Wood wrote:
> Almost certainly the latter. Is the disk interrupt shared with any
> other interrupts, that are marked IRQF_NODELAY? The -rt
> patch doesn't seem to handle mixing the two well.
Disk is on a muxed PCI interrupt. None of the other interrupts on the
mux is fireing at the time.
I
Rune Torgersen wrote:
Scott Wood wrote:
You're recursively entering lock_timer_base, which does a
spin_lock_irqsave(). Either interrupts are enabled when they should
not be, or an interrupt was supposed to be threaded that isn't.
Sort of figured. How do I figure out which one, and how to fix
Rune Torgersen wrote:
Scott Wood wrote:
You're recursively entering lock_timer_base, which does a
spin_lock_irqsave(). Either interrupts are enabled when they should
not be, or an interrupt was supposed to be threaded that isn't.
Sort of figured. How do I figure out which one, and how to fix
Scott Wood wrote:
> Rune Torgersen wrote:
>> Hi
>> I get the following oops when trying to boot a arch/powerpc kernel
>> with preempt-rt installed (v2.6.25.4-rt1)
>> The board is using a Freescale 8280 as the main CPU and a Silicon
>> Image SII3124 SATA controller. The oops seems to happen on
>> fi
Rune Torgersen wrote:
Hi
I get the following oops when trying to boot a arch/powerpc kernel with
preempt-rt installed (v2.6.25.4-rt1)
The board is using a Freescale 8280 as the main CPU and a Silicon Image
SII3124 SATA controller. The oops seems to happen on fileaccess right
after init starts.
Hi
I get the following oops when trying to boot a arch/powerpc kernel with
preempt-rt installed (v2.6.25.4-rt1)
The board is using a Freescale 8280 as the main CPU and a Silicon Image
SII3124 SATA controller. The oops seems to happen on fileaccess right
after init starts.
I need ideas what to loo
11 matches
Mail list logo
