[lkml]   [2000]   [Sep]   [12]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
Messages in this thread
SubjectRe: Adding set_system_gate fails in arch/i386/kernel/traps.
On 12 Sep 00 at 21:25, Keith Owens wrote:
> >0x85) vanish after the system has booted further. printk shows that
> >idt_table is correctly updated immediately after the set_system_gate
> >but once the system has booted the entries for my new traps have
> >reverted. (printk telemetry available on request). However, once the
> >system has booted, a little module which simply updates
> >idt_table[MY_NEW_VECTOR] directly works fine and "sticks". Help?
> >(Or, more accurately "Aaarrrgh?").
> I can confirm that this sometimes occurs in 2.4.0-testx, AFAIK I have
> only seen the problem in SMP kernels.

What about arch/i386/kernel/io_apic.c:assign_irq_vector() ?
It starts on FIRST_DEVICE_VECTOR(==0x31) and walks through each
eight vector up to FIRST_SYSTEM_VECTOR(==0xEF) (skipping SYSCALL_VECTOR
(0x80)). Then restarting at FIRST_DEVICE_VECTOR+1... until panic
'ran out of interrupt sources!' occurs.

So you should (1) preffer irqs which are multiple of 8 (*), as they are
allocated as last and (2) you should add check for your irq number
into assign_irq_vector.
Best regards,
Petr Vandrovec

(*) If my memory serves correctly SGI has allocated 0x88 or 0x90 in
one of their patches...
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to
Please read the FAQ at

 \ /
  Last update: 2005-03-22 12:38    [W:0.031 / U:1.464 seconds]
©2003-2020 Jasper Spaans|hosted at Digital Ocean and TransIP|Read the blog|Advertise on this site