Hi, I have been trying to get a serial console on L4Linux with the stub drivers and encountered the message 'l4ser: vkey_irq not set - input disabled!'.
Unfortunately I don't know which IRQ number is required here. I tried passing some different values to L4Linux which resulted in the error message 'irq_thread: RMGR denied IRQ 4: Code 0x1'.
I'd be grateful for some hints on that.
I also noticed that there are several different ways for handling IRQs (omega0, rmgr, l4io, ...) which require different options for some servers and L4Linux. Are there any documents describing the IRQ handling in L4Env and how to follow one of these ways consistently?
/boot/grub/menu.lst: title L4Linux-2.6 kernel /boot/bootstrap -serial modaddr 0x02000000 module /boot/bin/fiasco -nowait -nokdb -serial -serial_esc -comport 1 module /boot/bin/sigma0 module /boot/bin/roottask task modname "bmodfs" attached 5 modules module /boot/bin/names module /boot/bin/log module /boot/bin/dm_phys module /boot/bin/simple_ts -t 300 module /boot/bin/rtc module /boot/bin/l4io --noirq module /boot/bin/tftp -i module /boot/bin/bmodfs module /boot/bin/libld-l4.s.so module /boot/bin/libloader.s.so module /boot/bin/run-script module /boot/bin/vmlinuz26 module /boot/bin/drops-rd.rd module /boot/bin/loader --fprov=BMODFS run-script
/boot/bin/run-script: modpath "/boot/bin"
sleep 2 task "vmlinuz26" "mem=64M load_ramdisk=1 ramdisk_size=17000 root=/dev/ram l4env_rd=/boot/bin/drops-rd.rd console=ttyLv0 l4ser.vkey_irq=4" priority 0xA0 all_sects_writable
Regards, Andi
On Thu Aug 10, 2006 at 19:22:15 +0200, Andreas Niederl wrote:
I have been trying to get a serial console on L4Linux with the stub drivers and encountered the message 'l4ser: vkey_irq not set - input disabled!'.
Unfortunately I don't know which IRQ number is required here. I tried passing some different values to L4Linux which resulted in the error message 'irq_thread: RMGR denied IRQ 4: Code 0x1'.
I'd be grateful for some hints on that.
It's 17.
I also noticed that there are several different ways for handling IRQs (omega0, rmgr, l4io, ...) which require different options for some servers and L4Linux. Are there any documents describing the IRQ handling in L4Env and how to follow one of these ways consistently?
Short summary: There's the direct way of attaching to interrupts or using the omega0 protocol to attach to an interupt server. l4io and omega0 both implement the omega0 interface, the 'rmgr way' is the way to directly attach to the interrupts. When directly attaching you need I/O port access and might have problems with IRQ sharing which an interrupt server should fix for you, adding a slight penalty due to the indirection. There's a paper on omega0 at http://os.inf.tu-dresden.de/~hohmuth/prj/omega0.ps.gz
Adam
Hi,
Adam Lackorzynski wrote:
On Thu Aug 10, 2006 at 19:22:15 +0200, Andreas Niederl wrote:
[...]
Unfortunately I don't know which IRQ number is required here. I tried passing some different values to L4Linux which resulted in the error message 'irq_thread: RMGR denied IRQ 4: Code 0x1'.
I'd be grateful for some hints on that.
It's 17.
Thanks, where did you get that number?
Now the system stops after printing out the message 'l4lx | l4lx_thread_create: Created thread 0e.0b (IRQ17)'. When using l4io as omega0 server it stops after this message: l4lx_irq_dev_startup_virt(17) unimplemented
Ctrl-C still doesn't work on my serial console, so I'm not able to debug this.
Is gdb suitable for this kind of debugging? I could not find much information on this topic on the internet.
The serial console is in my case a pseudo terminal connected to the serial port emulation of Qemu which I can access with GNU screen or kermit or by using Qemu with the -nographic option which maps the serial console onto the invoking terminal (Grub needs extra configuration for that).
I also noticed that there are several different ways for handling IRQs (omega0, rmgr, l4io, ...) which require different options for some servers and L4Linux. Are there any documents describing the IRQ handling in L4Env and how to follow one of these ways consistently?
Short summary: There's the direct way of attaching to interrupts or using the omega0 protocol to attach to an interupt server. l4io and omega0 both implement the omega0 interface, the 'rmgr way' is the way to directly attach to the interrupts. When directly attaching you need I/O port access and might have problems with IRQ sharing which an interrupt server should fix for you, adding a slight penalty due to the indirection. There's a paper on omega0 at http://os.inf.tu-dresden.de/~hohmuth/prj/omega0.ps.gz
So, is there a recommended setup for interrupt handling? omega0 seems to be a reasonable approach.
Regards, Andi
On Fri Aug 11, 2006 at 14:39:32 +0200, Andreas Niederl wrote:
Adam Lackorzynski wrote:
On Thu Aug 10, 2006 at 19:22:15 +0200, Andreas Niederl wrote:
[...]
Unfortunately I don't know which IRQ number is required here. I tried passing some different values to L4Linux which resulted in the error message 'irq_thread: RMGR denied IRQ 4: Code 0x1'.
I'd be grateful for some hints on that.
It's 17.
Thanks, where did you get that number?
I know it (and maybe made it up too).
Now the system stops after printing out the message 'l4lx | l4lx_thread_create: Created thread 0e.0b (IRQ17)'. When using l4io as omega0 server it stops after this message: l4lx_irq_dev_startup_virt(17) unimplemented
Yes, unimplemented, I'm sorry. I added that to my todo list, should be low hanging stuff.
Ctrl-C still doesn't work on my serial console, so I'm not able to debug this.
I don't understand. Who should get that Ctrl-C?
Is gdb suitable for this kind of debugging? I could not find much information on this topic on the internet.
gdb is not really suited for multi address space debugging. Fiasco has a nice built-in debugger which gives you thread states, back traces, present and ready lists, various forms of tracing and logging etc.
The serial console is in my case a pseudo terminal connected to the serial port emulation of Qemu which I can access with GNU screen or kermit or by using Qemu with the -nographic option which maps the serial console onto the invoking terminal (Grub needs extra configuration for that).
You can also use -serial stdio to get the serial channel into the invoking terminal, and you can make GRUB auto-boot without manual selection.
I also noticed that there are several different ways for handling IRQs (omega0, rmgr, l4io, ...) which require different options for some servers and L4Linux. Are there any documents describing the IRQ handling in L4Env and how to follow one of these ways consistently?
Short summary: There's the direct way of attaching to interrupts or using the omega0 protocol to attach to an interupt server. l4io and omega0 both implement the omega0 interface, the 'rmgr way' is the way to directly attach to the interrupts. When directly attaching you need I/O port access and might have problems with IRQ sharing which an interrupt server should fix for you, adding a slight penalty due to the indirection. There's a paper on omega0 at http://os.inf.tu-dresden.de/~hohmuth/prj/omega0.ps.gz
So, is there a recommended setup for interrupt handling? omega0 seems to be a reasonable approach.
Yes, l4io with omega0 protocol is supposed to be fine.
Adam
Hi,
Adam Lackorzynski wrote:
On Fri Aug 11, 2006 at 14:39:32 +0200, Andreas Niederl wrote:
[...]
Now the system stops after printing out the message 'l4lx | l4lx_thread_create: Created thread 0e.0b (IRQ17)'. When using l4io as omega0 server it stops after this message: l4lx_irq_dev_startup_virt(17) unimplemented
Yes, unimplemented, I'm sorry. I added that to my todo list, should be low hanging stuff.
What about the stop after I got the first message using one thread per IRQ with the rmgr way? Is it a known problem or perhaps caused by some misconfiguration on my side?
Ctrl-C still doesn't work on my serial console, so I'm not able to debug this.
I don't understand. Who should get that Ctrl-C?
Well, perhaps I've confused something. I want to get into the JDB and as on Fiasco-UX this is done by typing Ctrl-C, I thought it would be the same on Fiasco and the serial line.
The JDB manual states that with the option '-serial_esc' Fiasco enters JDB on serial receive interrupts. Now I have no idea how to generate the needed interrupt.
Is gdb suitable for this kind of debugging? I could not find much information on this topic on the internet.
gdb is not really suited for multi address space debugging. Fiasco has a nice built-in debugger which gives you thread states, back traces, present and ready lists, various forms of tracing and logging etc.
I see.
Regards, Andi
Hi Andy,
[...]
Well, perhaps I've confused something. I want to get into the JDB and as on Fiasco-UX this is done by typing Ctrl-C, I thought it would be the same on Fiasco and the serial line.
The JDB manual states that with the option '-serial_esc' Fiasco enters JDB on serial receive interrupts. Now I have no idea how to generate the needed interrupt.
With ESC :-)
Cheers, Martin
Hi,
Martin Pohlack wrote:
Hi Andy,
[...]
Well, perhaps I've confused something. I want to get into the JDB and as on Fiasco-UX this is done by typing Ctrl-C, I thought it would be the same on Fiasco and the serial line.
The JDB manual states that with the option '-serial_esc' Fiasco enters JDB on serial receive interrupts. Now I have no idea how to generate the needed interrupt.
With ESC :-)
Okay, now I get it. Thanks.
Regards, Andi
On Mon Aug 14, 2006 at 14:16:43 +0200, Andreas Niederl wrote:
Adam Lackorzynski wrote:
On Fri Aug 11, 2006 at 14:39:32 +0200, Andreas Niederl wrote:
[...]
Now the system stops after printing out the message 'l4lx | l4lx_thread_create: Created thread 0e.0b (IRQ17)'. When using l4io as omega0 server it stops after this message: l4lx_irq_dev_startup_virt(17) unimplemented
Yes, unimplemented, I'm sorry. I added that to my todo list, should be low hanging stuff.
What about the stop after I got the first message using one thread per IRQ with the rmgr way? Is it a known problem or perhaps caused by some misconfiguration on my side?
Do you refer to the 'RMGR denied IRQ 4' issue? RMGR won't give you IRQ 4 as it is already used by the kernel for the debug console. Try the 17 with this setup and it should work.
Adam
Hi,
Adam Lackorzynski wrote:
On Mon Aug 14, 2006 at 14:16:43 +0200, Andreas Niederl wrote:
Adam Lackorzynski wrote:
[...]
What about the stop after I got the first message using one thread per IRQ with the rmgr way? Is it a known problem or perhaps caused by some misconfiguration on my side?
Do you refer to the 'RMGR denied IRQ 4' issue? RMGR won't give you IRQ 4 as it is already used by the kernel for the debug console. Try the 17 with this setup and it should work.
No, I should have separated the two messages more clearly. I meant this part:
Now the system stops after printing out the message 'l4lx | l4lx_thread_create: Created thread 0e.0b (IRQ17)'.
It's just like this, the system stops at this line and I cannot get into JDB (with the Escape key this time). Qemu itself remains responsive, I can e.g. access its monitor. This only happens when I specify 'l4ser.vkey_irq=17' as argument for L4Linux, otherwise I get only the output of L4Linux on the serial line but the system runs happily.
Regards, Andi
On Mon Aug 14, 2006 at 19:35:24 +0200, Andreas Niederl wrote:
No, I should have separated the two messages more clearly. I meant this part:
Now the system stops after printing out the message 'l4lx | l4lx_thread_create: Created thread 0e.0b (IRQ17)'.
It's just like this, the system stops at this line and I cannot get into JDB (with the Escape key this time). Qemu itself remains responsive, I can e.g. access its monitor. This only happens when I specify 'l4ser.vkey_irq=17' as argument for L4Linux, otherwise I get only the output of L4Linux on the serial line but the system runs happily.
I can reproduce this and I'm trying to fix it (or find someone to fix it).
Adam
On Mon Aug 14, 2006 at 19:35:24 +0200, Andreas Niederl wrote:
Hi,
Adam Lackorzynski wrote:
On Mon Aug 14, 2006 at 14:16:43 +0200, Andreas Niederl wrote:
Adam Lackorzynski wrote:
[...]
What about the stop after I got the first message using one thread per IRQ with the rmgr way? Is it a known problem or perhaps caused by some misconfiguration on my side?
Do you refer to the 'RMGR denied IRQ 4' issue? RMGR won't give you IRQ 4 as it is already used by the kernel for the debug console. Try the 17 with this setup and it should work.
No, I should have separated the two messages more clearly. I meant this part:
Now the system stops after printing out the message 'l4lx | l4lx_thread_create: Created thread 0e.0b (IRQ17)'.
It's just like this, the system stops at this line and I cannot get into JDB (with the Escape key this time). Qemu itself remains responsive, I can e.g. access its monitor. This only happens when I specify 'l4ser.vkey_irq=17' as argument for L4Linux, otherwise I get only the output of L4Linux on the serial line but the system runs happily.
The attached patch against Fiasco should fix the issue for now.
Index: kern/shared/jdb-ia32-amd64.cpp =================================================================== RCS file: /home/cvs/l4/kernel/fiasco/src/kern/shared/jdb-ia32-amd64.cpp,v retrieving revision 1.15 diff -u -r1.15 jdb-ia32-amd64.cpp --- kern/shared/jdb-ia32-amd64.cpp 1 Aug 2006 14:16:16 -0000 1.15 +++ kern/shared/jdb-ia32-amd64.cpp 20 Aug 2006 13:32:25 -0000 @@ -116,6 +116,7 @@ #include "kernel_console.h" #include "keycodes.h" #include "kernel_uart.h" +#include "kernel_task.h" #include "kmem.h" #include "logdefs.h" #include "mem_layout.h" @@ -939,12 +940,13 @@ { case 13: // inchar - if (Vkey::get() != -1) + //if (Vkey::get() != -1) { // we still have received a character via serial entry_frame->value(Vkey::get()); Vkey::clear(); } +#if 0 else { // wait for a character (either from serial or from keyboard @@ -952,6 +954,7 @@ entry_frame->value(getchar()); close_debug_console(); } +#endif return 1; // fiasco_tbuf case 29:
Adam
Adam Lackorzynski wrote:
On Mon Aug 14, 2006 at 19:35:24 +0200, Andreas Niederl wrote:
[...]
It's just like this, the system stops at this line and I cannot get into JDB (with the Escape key this time). Qemu itself remains responsive, I can e.g. access its monitor. This only happens when I specify 'l4ser.vkey_irq=17' as argument for L4Linux, otherwise I get only the output of L4Linux on the serial line but the system runs happily.
The attached patch against Fiasco should fix the issue for now.
Thanks for the effort. However the source file for kernel_task.h seems to be missing in the public CVS.
Regards, Andi
On Mon Aug 21, 2006 at 14:58:29 +0200, Andreas Niederl wrote:
Adam Lackorzynski wrote:
On Mon Aug 14, 2006 at 19:35:24 +0200, Andreas Niederl wrote:
[...]
It's just like this, the system stops at this line and I cannot get into JDB (with the Escape key this time). Qemu itself remains responsive, I can e.g. access its monitor. This only happens when I specify 'l4ser.vkey_irq=17' as argument for L4Linux, otherwise I get only the output of L4Linux on the serial line but the system runs happily.
The attached patch against Fiasco should fix the issue for now.
Thanks for the effort. However the source file for kernel_task.h seems to be missing in the public CVS.
Just leave that include out, I missed to remove it in the patch.
Adam
Adam Lackorzynski wrote:
On Mon Aug 21, 2006 at 14:58:29 +0200, Andreas Niederl wrote:
Adam Lackorzynski wrote:
On Mon Aug 14, 2006 at 19:35:24 +0200, Andreas Niederl wrote:
[...]
It's just like this, the system stops at this line and I cannot get into JDB (with the Escape key this time). Qemu itself remains responsive, I can e.g. access its monitor. This only happens when I specify 'l4ser.vkey_irq=17' as argument for L4Linux, otherwise I get only the output of L4Linux on the serial line but the system runs happily.
The attached patch against Fiasco should fix the issue for now.
Thanks for the effort. However the source file for kernel_task.h seems to be missing in the public CVS.
Just leave that include out, I missed to remove it in the patch.
Thanks, it works now.
Is it normal that the cursor keys get messed up? I get digits when using '-serial pty' and escape characters like '\M-' with a number using '-serial stdio' with Qemu.
Regards, Andi
On Mon Aug 21, 2006 at 20:37:55 +0200, Andreas Niederl wrote:
Is it normal that the cursor keys get messed up? I get digits when using '-serial pty' and escape characters like '\M-' with a number using '-serial stdio' with Qemu.
Shouldn't it just enter jdb when using the cursor keys as those start with ESC? At least this happens to me. I haven't investigated further.
Adam
Adam Lackorzynski wrote:
On Mon Aug 21, 2006 at 20:37:55 +0200, Andreas Niederl wrote:
Is it normal that the cursor keys get messed up? I get digits when using '-serial pty' and escape characters like '\M-' with a number using '-serial stdio' with Qemu.
Shouldn't it just enter jdb when using the cursor keys as those start with ESC? At least this happens to me. I haven't investigated further.
It probably would if the cursor keys would start with ESC here, but they don't. Perhaps this has something to do with Qemu or the terminal application I use (xterm + screen).
Regards, Andi
l4-hackers@os.inf.tu-dresden.de