[parisc-linux] 2.6.0-test6-pa6 on b2k finaly crash

[parisc-linux] 2.6.0-test6-pa6 on b2k finaly crash

[Joel Soete]

Hi all,

First of all 2.6.0-test6-pa6 still run find on the b180 :) and led front
panel are flickering once more :)

I am also happy that with 2.6.0-test6-pa6 b2k crash because it is a long
time that I try to obtain a relevant info (even toc do not help until now).
And here is the full boot messages:

Command line for kernel: 'root=/dev/sda5 HOME=/ console=ttyS0 TERM=vt102
palo_kernel=3/vmlinux-2.6.0-test6-pre6'
Selected kernel: /vmlinux-2.6.0-test6-pre6 from partition 3
ERROR: open /vmlinux-2.6.0-test6-pre6 from partition 3 failed
 palo_kernel=3/vmlinux-2.6.0-test6-pa6
PID hash table entries: 16 (order 4: 128 bytes)
Console: colour dummy device 160x64
Memory: 255656k available
Calibrating delay loop... 799.53 BogoMIPS
Dentry cache hash table entries: 32768 (order: 5, 131072 bytes)
Inode-cache hash table entries: 16384 (order: 4, 65536 bytes)
Mount-cache hash table entries: 512 (order: 0, 4096 bytes)
POSIX conformance testing by UNIFIX
NET: Registered protocol family 16
EISA bus registered
Searching for devices...
Found devices:
1. Astro BC Runway Port (12) at 0xfed00000 [10], versions 0x582, 0x0, 0xb
2. Elroy PCI Bridge (13) at 0xfed30000 [10/0], versions 0x782, 0x0, 0xa
3. Elroy PCI Bridge (13) at 0xfed32000 [10/1], versions 0x782, 0x0, 0xa
4. Kazoo W+ (0) at 0xfffa0000 [32], versions 0x5d0, 0x0, 0x4
5. Memory (1) at 0xfed10200 [49], versions 0x9d, 0x0, 0x9
CPU(s): 1 x PA8600 (PCX-W+) at 400.000000 MHz
SBA found Astro 2.1 at 0xfed00000
lba version TR4.0 (0x5) found at 0xfed30000
PCI: Ignoring BAR0-3 of IDE controller 0000:00:0e.0
lba version TR4.0 (0x5) found at 0xfed32000
SCSI subsystem initialized
drivers/usb/core/usb.c: registered new driver hub
ikconfig 0.7 with /proc/config*
Installing knfsd (copyright (C) 1996 okir@monad.swb.de).
Initializing Cryptographic API
Soft power switch enabled, polling @ 0xf0400804.
pty: 256 Unix98 ptys configured
lp: driver loaded but no devices found
Generic RTC Driver v1.07
Serial: 8250/16550 driver $Revision: 1.90 $ IRQ sharing enabled

Stack Dump:
 10068758:  10068758 00000204 0000000f 00000000 
 10068748:  10389f44 00000000 10389f44 000000d0 
 10068738:  1fff9ba0 000000d0 00000001 1013f724 
 10068728:  00000001 000000d0 3b9aca00 10389810 
 10068718:  10458810 10389f44 00000201 100683c0 
 10068708:  0000000d 00000000 00000000 000000d0 
 100686f8:  1fff9ba0 000000d0 00000001 101067fc 
 100686e8:  00000001 00000000 1038a810 10068548 
 100686d8:  1ffe3f00 10389f44 00000201 00000001 
 100686c8:  1038a280 1006f7b0 00000010 000000d0 
 100686b8:  1fff9b2c 000000d0 00000001 1013f880 
 100686a8:  00000001 00000000 0000000b 1fff9b2c 
 10068698:  1fe08060 1046d0c4 00000000 10068288 
 10068688:  00000013 00000060 1fff9b2c 000000d0 
 10068678:  1fff9b2c 000000d0 00000001 10142d2c 
 10068668:  00000001 000000d0 3b9aca00 10389810 
 10068658:  10458810 f0400004 f00008c4 00000000 
 10068648:  1ffea300 1ffe3f00 1fff8400 000000d0 
 10068638:  1fff9b2c 000000d0 00000001 1013fb48 
 10068628:  00000001 000000d0 3b9aca00 10389810 
 10068618:  10389f44 1fe08060 1fff9b2c 000000d0 
 10068608:  1fe08000 000000d0 00000001 1006f7b0 
 100685f8:  10459010 1047662c 00000027 1010b088 
 100685e8:  10390ac8 00000000 0000001b 1fffdc60 
 100685d8:  1fff9b38 1fff9b2c 1ffe3f00 068e7780 
 100685c8:  3f7d9b03 1fe0bbd4 00400048 000000d0 
 100685b8:  1fff9b2c 000000d0 00000001 1018c78c 
 100685a8:  00000001 00000000 1038a810 10068408 
 10068598:  1fff4a80 00000000 1a06836c 10240000 
 10068588:  b3202000 0000000f fffffff4 1006f7b0 
 10068578:  10459010 00000000 1006cb70 101e9310 
 10068568:  101e930c 00000000 00000000 00000000 
 10068558:  00000000 00000000 00000000 00000000 
 10068548:  00000000 00000000 00000000 55555555 
 10068538:  55555555 55555555 55555555 55555555 
 10068528:  55555555 55555555 55555555 55555555 
 10068518:  55555555 55555555 55555555 55555555 
 10068508:  55555555 55555555 55555555 55555555 
 100684f8:  55555555 55555555 55555555 55555555 
 100684e8:  55555555 55555555 55555555 55555555 
 100684d8:  55555555 55555555 55555555 55555555 
 100684c8:  55555555 55555555 55555555 55555555 
 100684b8:  55555555 55555555 55555555 55555555 
 100684a8:  55555555 55555555 55555555 55555555 
 10068498:  55555555 55555555 55555555 55555555 
 10068488:  55555555 55555555 55555555 55555555 
 10068478:  55555555 55555555 55555555 55555555 
 10068468:  55555555 00000000 00000000 00000000 
 10068458:  0000001f 00000000 0000001f 00000000 
 10068448:  0000001f 24850e06 04100800 10210928 
 10068438:  100683c0 068e7780 00000000 10372010 
 10068428:  00000000 00000000 00000000 00000000 
 10068418:  00000cb0 41000000 00000000 00009600 
 10068408:  f0000174 f000017c f00008c4 f0400004 
 100683f8:  10458810 10389810 3b9aca00 10458884 
 100683e8:  37e45480 00000000 00000027 10388810 
 100683d8:  00000013 10068288 00000000 1046d0c4 
 100683c8:  10215854 ffffffff 0004ff0f 000000d0 
 100683b8:  104768c8 000000d0 00000001 1018d3cc 
 100683a8:  00000001 000000d0 10355e84 1046d0c4 
 10068398:  103952b8 10068288 00000013 10388810 
 10068388:  00000027 00000000 37e45480 000000d0 
 10068378:  10476610 000000d0 00000001 10215904 
 10068368:  00000001 00400048 10068248 1fe0bc14 

Kernel addresses on the stack:
 [<10142d2c>] cache_init_objs+0xb8/0xc0
 [<10106220>] parisc_terminate+0x60/0xb8
 [<1013f724>] buffered_rmqueue+0xd8/0x164
 [<101067fc>] handle_interruption+0x584/0x5bc
 [<1013f880>] __alloc_pages+0xd0/0x374
 [<10142d2c>] cache_init_objs+0xb8/0xc0
 [<1013fb48>] __get_free_pages+0x24/0x78
 [<1010b088>] intr_check_sig+0x0/0xc
 [<1018c78c>] sysfs_new_inode+0x20/0xb0
 [<101e9310>] $$divU+0x10/0x210
 [<1018d3cc>] sysfs_create_dir+0x3c/0x80
 [<10215904>] serial8250_set_termios+0xa4/0x314
 [<101e56a8>] create_dir+0x4c/0x64
 [<103e5a7c>] uart_set_options+0xec/0x14c
 [<1021ba68>] driver_attach+0x70/0xa4
 [<103e5cd8>] serial8250_console_setup+0xa8/0xbc
 [<1021bcf8>] bus_add_driver+0xa0/0xa8
 [<10126388>] register_console+0x1b0/0x214
 [<1021c05c>] driver_register+0x48/0x54
 [<103e5d0c>] serial8250_console_init+0x20/0x30
 [<103e65fc>] serial8250_pci_init+0x38/0x68
 [<103d5438>] do_initcalls+0x58/0xdc
 [<10100440>] init+0x28/0xd4
 [<1010ac5c>] ret_from_kernel_thread+0x1c/0x24


Unexpected interruption: Code=13 regs=100683c0 (Addr=00000000)

     YZrvWESTHLNXBCVMcbcbcbcbOGFRQPDI
PSW: 00000000000001001111111100001111 Not tainted
r00-03  00000000 ffffffff 10215854 1046d0c4
r04-07  00000000 10068288 00000013 10388810
r08-11  00000027 00000000 37e45480 10458884
r12-15  3b9aca00 10389810 10458810 f0400004
r16-19  f00008c4 f000017c f0000174 00009600
r20-23  00000000 41000000 00000cb0 00000000
r24-27  00000000 00000000 00000000 10372010
r28-31  00000000 068e7780 100683c0 10210928
sr0-3   00000000 00000000 00000000 00000000
sr4-7   00000000 00000000 00000000 00000000

IASQ: 00000000 00000000 IAOQ: 101e930c 101e9310
 IIR: b3202000    ISR: 10240000  IOR: 1a06836c
 CPU:        0   CR30: 10068000 CR31: 103cb000
 ORIG_R28: 10459010
 IAOQ[0]: $$divU+0xc/0x210
 IAOQ[1]: $$divU+0x10/0x210
 RP(r2): serial8250_get_divisor+0x44/0x50

hth,
    joel

PS: kernel was build with 'make defconfig' configuration and gcc:
palinux:~# gcc --version
gcc (GCC) 3.3.2 20030908 (Debian prerelease)
Copyright (C) 2003 Free Software Foundation, Inc.
This is free software; see the source for copying conditions.  There is NO
warranty; not even for MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE.


-------------------------------------------------------------------------
L'Internet rapide, c'est pour tout le monde. Tiscali ADSL, 19,50 Euro
pendant 3 mois! http://reg.tiscali.be/default.asp?lg=fr 

Re: [parisc-linux] 2.6.0-test6-pa6 on b2k finaly crash

[M. Grabert]

On Fri, 3 Oct 2003, Joel Soete wrote:

> I am also happy that with 2.6.0-test6-pa6 b2k crash because it is a long
> time that I try to obtain a relevant info (even toc do not help until now).

You mean to be able to track down the serial console bug?

> And here is the full boot messages:

[removed dmesg output]

Similar to my output.

> PS: kernel was build with 'make defconfig' configuration and gcc:
> palinux:~# gcc --version
> gcc (GCC) 3.3.2 20030908 (Debian prerelease)

Same here.

I was wondering whether it was just me (wrong config) or the 2.6 wasn't
working on C3k in general. Then I read on the mailing lists archive that
the serial console is not working for the C3k.

For that reason I was never able to test/run a 2.5/2.6 kernel, since
I don't have a STIcon (no graphics card).
Well, I think you can just compile no console at all and it will use a
dummy console AFAIK, but never tried that (not brave enough). Would you
be able to run 2.6 in that case?

Thanks
  Max

Re: [parisc-linux] 2.6.0-test6-pa6 on b2k finaly crash

[Joel Soete]

>> I am also happy that with 2.6.0-test6-pa6 b2k crash because it is a long
>> time that I try to obtain a relevant info (even toc do not help until
now).
>
>You mean to be able to track down the serial console bug?
>
>> And here is the full boot messages:
[snip]
>For that reason I was never able to test/run a 2.5/2.6 kernel, since
>I don't have a STIcon (no graphics card).

I don't have more on my b2k :(

>Well, I think you can just compile no console at all 
Yes I do it (a bit by accident) and so very surprise that I could connect
it via ssh or even telnet
> and it will use a dummy console AFAIK, but never tried that (not brave

> enough). Would you be able to run 2.6 in that case?

No yet try neither dummy console nor lan console (for this last i would like
to find back the soft to be installed on another server but i do not yet
find enough time :( )

Regards,
    Joel

Thanks

> Max



-------------------------------------------------------------------------
L'Internet rapide, c'est pour tout le monde. Tiscali ADSL, 19,50 Euro
pendant 3 mois! http://reg.tiscali.be/default.asp?lg=fr 

Re: [parisc-linux] 2.6.0-test6-pa6 on b2k finaly crash

[Joel Soete]

>> I am also happy that with 2.6.0-test6-pa6 b2k crash because it is a long
>> time that I try to obtain a relevant info (even toc do not help until
now).
>
>You mean to be able to track down the serial console bug?
>
>> And here is the full boot messages:
[snip]
>For that reason I was never able to test/run a 2.5/2.6 kernel, since
>I don't have a STIcon (no graphics card).

I don't have more on my b2k :(

>Well, I think you can just compile no console at all 
Yes I do it (a bit by accident) and so very surprise that I could connect
it via ssh or even telnet
> and it will use a dummy console AFAIK, but never tried that (not brave

> enough). Would you be able to run 2.6 in that case?

No yet try neither dummy console nor lan console (for this last i would like
to find back the soft to be installed on another server but i do not yet
find enough time :( )

Regards,
    Joel

Thanks

> Max



-------------------------------------------------------------------------
L'Internet rapide, c'est pour tout le monde. Tiscali ADSL, 19,50 Euro
pendant 3 mois! http://reg.tiscali.be/default.asp?lg=fr 

[parisc-linux] traps.c 2.4 alignement [was: 2.6.0-test6-pa6 on b2k finaly crash]

[Joel Soete]

[-- Attachment #1: Type: text/plain, Size: 8162 bytes --]

Joel Soete wrote:

>I am also happy that with 2.6.0-test6-pa6 b2k crash because it is a long
>time that I try to obtain a relevant info (even toc do not help until now).
>And here is the full boot messages:
>  
>
[...]

>
>Unexpected interruption: Code=13 regs=100683c0 (Addr=00000000)
>
>     YZrvWESTHLNXBCVMcbcbcbcbOGFRQPDI
>PSW: 00000000000001001111111100001111 Not tainted
>r00-03  00000000 ffffffff 10215854 1046d0c4
>r04-07  00000000 10068288 00000013 10388810
>r08-11  00000027 00000000 37e45480 10458884
>r12-15  3b9aca00 10389810 10458810 f0400004
>r16-19  f00008c4 f000017c f0000174 00009600
>r20-23  00000000 41000000 00000cb0 00000000
>r24-27  00000000 00000000 00000000 10372010
>r28-31  00000000 068e7780 100683c0 10210928
>sr0-3   00000000 00000000 00000000 00000000
>sr4-7   00000000 00000000 00000000 00000000
>
>IASQ: 00000000 00000000 IAOQ: 101e930c 101e9310
> IIR: b3202000    ISR: 10240000  IOR: 1a06836c
> CPU:        0   CR30: 10068000 CR31: 103cb000
> ORIG_R28: 10459010
> IAOQ[0]: $$divU+0xc/0x210
> IAOQ[1]: $$divU+0x10/0x210
> RP(r2): serial8250_get_divisor+0x44/0x50
>
>  
>
Hi Carlos and all,

Regarding a bit more about this crash dump, I figure out that your patch 
<http://lists.parisc-linux.org/pipermail/parisc-linux/2002-September/017565.html> 
was not yet 'aligned' in 2.6.
So may I suggest you this first draft:
--- linux-2.6.0-test6-pa6.orig/arch/parisc/kernel/traps.c       
2003-10-05 16:03:42.000000000 +0200
+++ linux-2.6.0-test6-pa6.test/arch/parisc/kernel/traps.c       
2003-10-05 16:05:24.000000000 +0200
@@ -44,7 +44,7 @@
 #define PRINT_USER_FAULTS /* (turn this on if you want user faults to be */
                          /*  dumped to the console via printk)          */

-int printbinary(char *buf, unsigned long x, int nbits)
+static int printbinary(char *buf, unsigned long x, int nbits)
 {
        unsigned long mask = 1UL << (nbits - 1);
        while (mask != 0) {
@@ -408,7 +408,7 @@


 /*
- * This routine handles page faults.  It determines the address,
+ * This routine handles various exception codes.  It determines the 
address,
  * and the problem, and then passes it off to one of the appropriate
  * routines.
  */
@@ -429,8 +429,18 @@
        if (!console_drivers)
                pdc_console_restart();

-       if (code == 1)
-           transfer_pim_to_trap_frame(regs);
+
+       /* Not all switch paths will gutter the processor... */
+       switch(code){
+
+       case 1:
+               transfer_pim_to_trap_frame(regs);
+               break;
+
+       default:
+               /* Fall through */
+               break;
+       }

        show_stack(NULL, (unsigned long *)regs->gr[30]);

@@ -446,34 +456,28 @@
         * system will shut down immediately right here. */
        pdc_soft_power_button(0);

+       /* Gutter the processor... */
        for(;;)
            ;
 }

+
 void handle_interruption(int code, struct pt_regs *regs)
 {
        unsigned long fault_address = 0;
        unsigned long fault_space = 0;
        struct siginfo si;

-       if (code == 1)
-           pdc_console_restart();  /* switch back to pdc if HPMC */
-       else
-           local_irq_enable();
-
-#if 0
-       printk(KERN_CRIT "Interruption # %d\n", code);
-#endif
-
        switch(code) {

        case  1:
                /* High-priority machine check (HPMC) */
-
+               pdc_console_restart();  /* switch back to pdc if HPMC */
+
                /* set up a new led state on systems shipped with a LED 
State panel */
                pdc_chassis_send_status(PDC_CHASSIS_DIRECT_HPMC);
-
-               parisc_terminate("High Priority Machine Check (HPMC)",
+
+               parisc_terminate("High Priority Machine Check (HPMC)",
                                regs, code, 0);
                /* NOT REACHED */
              
@@ -492,8 +496,9 @@
 
        case  5:
                /* Low-priority machine check */
+
                pdc_chassis_send_status(PDC_CHASSIS_DIRECT_LPMC);
-               
+
                flush_all_caches();
                cpu_lpmc(5, regs);
                return;
@@ -542,6 +547,7 @@
 
                die_if_kernel("Privileged register usage", regs, code);
                si.si_code = ILL_PRVREG;
+               /* Fall thru */
        give_sigill:
                si.si_signo = SIGILL;
                si.si_errno = 0;
@@ -556,6 +562,17 @@
                si.si_addr = (void *) regs->iaoq[0];
                force_sig_info(SIGFPE, &si, current);
                return;
+
+       case 13:
+               /* Conditional Trap
+                  The condition succees in an instruction which traps 
on condition  */
+               si.si_signo = SIGFPE;
+               /* Set to zero, and let the userspace app figure it out from
+                  the insn pointed to by si_addr */
+               si.si_code = 0;
+               si.si_addr = (void *) regs->iaoq[0];
+               force_sig_info(SIGFPE, &si, current);
+               return;

        case 14:
                /* Assist Exception Trap, i.e. floating point exception. */
@@ -563,13 +580,22 @@
                handle_fpe(regs);
                return;

+       case 15:
+               /* Data TLB miss fault/Data page fault */
+               /* Fall thru */
+       case 16:
+               /* Non-access instruction TLB miss fault */
+               /* The instruction TLB entry needed for the target 
address of the FIC
+                  is absent, and hardware can't find it, so we get to 
cleanup */
+               /* Fall thru */
        case 17:
                /* Non-access data TLB miss fault/Non-access data page 
fault */
                /* TODO: Still need to add slow path emulation code here */
-               pdc_chassis_send_status(PDC_CHASSIS_DIRECT_PANIC);
-
+               /* TODO: Understand what is meant by the TODO listed
+                  above this one. (Carlos) */
                fault_address = regs->ior;
-               parisc_terminate("Non access data tlb 
fault!",regs,code,fault_address);
+               fault_space = regs->isr;
+               break;
 
        case 18:
                /* PCXS only -- later cpu's split this into types 26,27 
& 28 */
@@ -579,9 +605,8 @@
                        return;
                }
                /* Fall Through */
-
-       case 15: /* Data TLB miss fault/Data page fault */
-       case 26: /* PCXL: Data memory access rights trap */
+       case 26:
+               /* PCXL: Data memory access rights trap */
                fault_address = regs->ior;
                fault_space   = regs->isr;
                break;
@@ -637,7 +662,6 @@
                        up_read(&current->mm->mmap_sem);
                }
                /* Fall Through */
-
        case 27:
                /* Data memory protection ID trap */
                die_if_kernel("Protection id trap", regs, code);
@@ -671,8 +695,9 @@
                        force_sig_info(SIGBUS, &si, current);
                        return;
                }
-               pdc_chassis_send_status(PDC_CHASSIS_DIRECT_PANIC);
 
+               pdc_chassis_send_status(PDC_CHASSIS_DIRECT_PANIC);
+
                parisc_terminate("Unexpected interruption", regs, code, 0);
                /* NOT REACHED */
        }
@@ -702,18 +727,19 @@
             * The kernel should never fault on its own address space.
             */

-           if (fault_space == 0)
-           {
+           if (fault_space == 0) {
                pdc_chassis_send_status(PDC_CHASSIS_DIRECT_PANIC);
                parisc_terminate("Kernel Fault", regs, code, fault_address);
-
+               /** NOT REACHED **/
            }
        }

+       local_irq_enable();
        do_page_fault(regs, code, fault_address);
 }


+
 int __init check_ivt(void *iva)
 {
        int i;

hmm I am not quiet sure about first hunck (static or not for printbinary?).

I test it successfully on my c110 but if you have some opportunity to 
double check and may be also ci, that would be nice.

Thanks in advance,
    Joel

PS: I do not yet test on my b2k :( so I don't know yet if it help the 
above pb?

PS2: Max may be have this opportunity on your c3k? (thanks)

[-- Attachment #2: Traps-2.4-Align --]
[-- Type: text/plain, Size: 5095 bytes --]

--- linux-2.6.0-test6-pa6.orig/arch/parisc/kernel/traps.c	2003-10-05 16:03:42.000000000 +0200
+++ linux-2.6.0-test6-pa6.test/arch/parisc/kernel/traps.c	2003-10-05 16:05:24.000000000 +0200
@@ -44,7 +44,7 @@
 #define PRINT_USER_FAULTS /* (turn this on if you want user faults to be */
 			  /*  dumped to the console via printk)          */
 
-int printbinary(char *buf, unsigned long x, int nbits)
+static int printbinary(char *buf, unsigned long x, int nbits)
 {
 	unsigned long mask = 1UL << (nbits - 1);
 	while (mask != 0) {
@@ -408,7 +408,7 @@
 
 
 /*
- * This routine handles page faults.  It determines the address,
+ * This routine handles various exception codes.  It determines the address,
  * and the problem, and then passes it off to one of the appropriate
  * routines.
  */
@@ -429,8 +429,18 @@
 	if (!console_drivers)
 		pdc_console_restart();
 
-	if (code == 1)
-	    transfer_pim_to_trap_frame(regs);
+
+	/* Not all switch paths will gutter the processor... */
+	switch(code){
+
+	case 1:
+		transfer_pim_to_trap_frame(regs);
+		break;
+	    
+	default:
+		/* Fall through */
+		break;
+	}
 
 	show_stack(NULL, (unsigned long *)regs->gr[30]);
 
@@ -446,34 +456,28 @@
 	 * system will shut down immediately right here. */
 	pdc_soft_power_button(0);
 	
+	/* Gutter the processor... */
 	for(;;)
 	    ;
 }
 
+
 void handle_interruption(int code, struct pt_regs *regs)
 {
 	unsigned long fault_address = 0;
 	unsigned long fault_space = 0;
 	struct siginfo si;
 
-	if (code == 1)
-	    pdc_console_restart();  /* switch back to pdc if HPMC */
-	else
-	    local_irq_enable();
-
-#if 0
-	printk(KERN_CRIT "Interruption # %d\n", code);
-#endif
-
 	switch(code) {
 
 	case  1:
 		/* High-priority machine check (HPMC) */
-		
+		pdc_console_restart();  /* switch back to pdc if HPMC */
+
 		/* set up a new led state on systems shipped with a LED State panel */
 		pdc_chassis_send_status(PDC_CHASSIS_DIRECT_HPMC);
-		    
-	    	parisc_terminate("High Priority Machine Check (HPMC)",
+
+		parisc_terminate("High Priority Machine Check (HPMC)",
 				regs, code, 0);
 		/* NOT REACHED */
 		
@@ -492,8 +496,9 @@
 
 	case  5:
 		/* Low-priority machine check */
+
 		pdc_chassis_send_status(PDC_CHASSIS_DIRECT_LPMC);
-		
+
 		flush_all_caches();
 		cpu_lpmc(5, regs);
 		return;
@@ -542,6 +547,7 @@
 
 		die_if_kernel("Privileged register usage", regs, code);
 		si.si_code = ILL_PRVREG;
+		/* Fall thru */
 	give_sigill:
 		si.si_signo = SIGILL;
 		si.si_errno = 0;
@@ -556,6 +562,17 @@
 		si.si_addr = (void *) regs->iaoq[0];
 		force_sig_info(SIGFPE, &si, current);
 		return;
+	
+	case 13:
+		/* Conditional Trap 
+		   The condition succees in an instruction which traps on condition  */
+		si.si_signo = SIGFPE;
+		/* Set to zero, and let the userspace app figure it out from
+		   the insn pointed to by si_addr */
+		si.si_code = 0;
+		si.si_addr = (void *) regs->iaoq[0];
+		force_sig_info(SIGFPE, &si, current);
+		return;
 
 	case 14:
 		/* Assist Exception Trap, i.e. floating point exception. */
@@ -563,13 +580,22 @@
 		handle_fpe(regs);
 		return;
 
+	case 15: 
+		/* Data TLB miss fault/Data page fault */	
+		/* Fall thru */
+	case 16:
+		/* Non-access instruction TLB miss fault */
+		/* The instruction TLB entry needed for the target address of the FIC
+		   is absent, and hardware can't find it, so we get to cleanup */
+		/* Fall thru */
 	case 17:
 		/* Non-access data TLB miss fault/Non-access data page fault */
 		/* TODO: Still need to add slow path emulation code here */
-		pdc_chassis_send_status(PDC_CHASSIS_DIRECT_PANIC);
-		
+		/* TODO: Understand what is meant by the TODO listed 
+		   above this one. (Carlos) */
 		fault_address = regs->ior;
-		parisc_terminate("Non access data tlb fault!",regs,code,fault_address);
+		fault_space = regs->isr;
+		break;
 
 	case 18:
 		/* PCXS only -- later cpu's split this into types 26,27 & 28 */
@@ -579,9 +605,8 @@
 			return;
 		}
 		/* Fall Through */
-
-	case 15: /* Data TLB miss fault/Data page fault */
-	case 26: /* PCXL: Data memory access rights trap */
+	case 26: 
+		/* PCXL: Data memory access rights trap */
 		fault_address = regs->ior;
 		fault_space   = regs->isr;
 		break;
@@ -637,7 +662,6 @@
 			up_read(&current->mm->mmap_sem);
 		}
 		/* Fall Through */
-
 	case 27: 
 		/* Data memory protection ID trap */
 		die_if_kernel("Protection id trap", regs, code);
@@ -671,8 +695,9 @@
 			force_sig_info(SIGBUS, &si, current);
 			return;
 		}
-		pdc_chassis_send_status(PDC_CHASSIS_DIRECT_PANIC);
 		
+		pdc_chassis_send_status(PDC_CHASSIS_DIRECT_PANIC);
+
 		parisc_terminate("Unexpected interruption", regs, code, 0);
 		/* NOT REACHED */
 	}
@@ -702,18 +727,19 @@
 	     * The kernel should never fault on its own address space.
 	     */
 
-	    if (fault_space == 0) 
-	    {
+	    if (fault_space == 0) {
 		pdc_chassis_send_status(PDC_CHASSIS_DIRECT_PANIC);
 		parisc_terminate("Kernel Fault", regs, code, fault_address);
-	
+		/** NOT REACHED **/
 	    }
 	}
 
+	local_irq_enable();
 	do_page_fault(regs, code, fault_address);
 }
 
 
+
 int __init check_ivt(void *iva)
 {
 	int i;

Re: [parisc-linux] traps.c 2.4 alignement [was: 2.6.0-test6-pa6 on b2k finaly crash]

[Joel Soete]

Joel Soete wrote:

> I test it successfully on my c110 but if you have some opportunity to 
> double check and may be also ci, that would be nice.

hmm don't think if it's related but just in case:
I was just copying my kernel tree with 'tar cslpf - 
linux-2.6.0-test6-pa6 | ( cd Work ; tar xslpf -)' when

Kernel panic: drivers/parisc/ccio-dma.c: ccio_alloc_range() I/O M.
In interrupt handler - not syncing

?

I just retry same operation on the same system with same kernel but 
doesn't occurs a second time?

Thanks in advance,
    Joel

Re: [parisc-linux] traps.c 2.4 alignement [was: 2.6.0-test6-pa6 on b2k finaly crash]

[M. Grabert]

On Sun, 5 Oct 2003, Joel Soete wrote:

> Joel Soete wrote:
>
> > I test it successfully on my c110 but if you have some opportunity to
> > double check and may be also ci, that would be nice.

I've compiled 2.6.0-test6-pa6 with your patches, but I can't reboot
the machine into 2.6 right now since it's being used by my housemates ;)

> hmm don't think if it's related but just in case:
> I was just copying my kernel tree with 'tar cslpf -
> linux-2.6.0-test6-pa6 | ( cd Work ; tar xslpf -)' when
>
> Kernel panic: drivers/parisc/ccio-dma.c: ccio_alloc_range() I/O M.
> In interrupt handler - not syncing
>
> ?
>
> I just retry same operation on the same system with same kernel but
> doesn't occurs a second time?

When I have the opportunity I'll fire up 2.6 (with you patches) and test
it with high I/O load (if it even boots up).

I'll let you know whether I can boot with serial console enabled and
whether I also have the same kernel panic when doing heavy I/O.


greetings,
  Max

Re: [parisc-linux] traps.c 2.4 alignement [was: 2.6.0-test6-pa6 on b2k finaly crash]

[Carlos O'Donell]

On Sun, Oct 05, 2003 at 03:06:48PM +0000, Joel Soete wrote:
> Hi Carlos and all,
> 
> Regarding a bit more about this crash dump, I figure out that your patch 
> <http://lists.parisc-linux.org/pipermail/parisc-linux/2002-September/017565.html> 
> was not yet 'aligned' in 2.6.
> So may I suggest you this first draft:

The draft looks good. I'll merge it into 2.6 today and test on my
system.

c.

Re: [parisc-linux] traps.c 2.4 alignement [was: 2.6.0-test6-pa6 on b2k finaly crash]

[Joel Soete]

>>
>>On Sun, Oct 05, 2003 at 03:06:48PM +0000, Joel Soete wrote:
>> Hi Carlos and all,
>> 
>> Regarding a bit more about this crash dump, I figure out that your patch

>> ><http://lists.parisc-linux.org/pipermail/parisc-linux/2002-September/017565.html>

> 
>>as not yet 'aligned' in 2.6.
>> So may I suggest you this first draft:
>
>The draft looks good. I'll merge it into 2.6 today and test on my
>system.

Finaly it works on my c110 and also on a b180l :)

But, as we could awaiting when such code=13 (conditional trap iirc), occurs
in kernel mode (as on my b2k or Max's c3k) the kernel hang without advise
:(

Thanks for your attention,
    Joel


-------------------------------------------------------------------------
L'Internet rapide, c'est pour tout le monde. Tiscali ADSL, 19,50 Euro
pendant 3 mois! http://reg.tiscali.be/default.asp?lg=fr 

Re: [parisc-linux] traps.c 2.4 alignement [was: 2.6.0-test6-pa6 on b2k finaly crash]

[Grant Grundler]

On Sun, Oct 05, 2003 at 05:07:21PM +0000, Joel Soete wrote:
> hmm don't think if it's related but just in case:
> I was just copying my kernel tree with 'tar cslpf - 
> linux-2.6.0-test6-pa6 | ( cd Work ; tar xslpf -)' when
> 
> Kernel panic: drivers/parisc/ccio-dma.c: ccio_alloc_range() I/O M.

You ran out of mapping resources.
        panic(__FILE__ ": %s() I/O MMU is out of mapping resources.\n",
	              __FUNCTION__);

> I just retry same operation on the same system with same kernel but 
> doesn't occurs a second time?

Not surprising. The bitmap search will fail if everything gets
mapped "sparsely" or we try to search for a large mapping (>32K, ie more
than 8 pages) but can't find it. If this is repeatible problem, change

	/* Ratio of Host MEM to IOV Space size */
	static unsigned long ccio_mem_ratio = 4;

in drivers/parisc/ccio-dma.c (2.6 kernel) to 2.

One patch would be welcome here: figure out a threshold when
allocations for single pages should share an 8-page "chunk"
(effectively one TLB entry).  E.g. differentiate between LAN
and SCSI requests.  LAN typically wants 1 entry (1500 byte MTU)
unless someone starts testing "Large Send" and is very "linear"
in it's DMA behavior (one DMA stream at a time).  SCSI typically
wants 64k/128k (16 or 32 entries), has lots of those, and any one
of those could be the "next" DMA stream. ie thrashing the IO TLB
is much more likely with SCSI than LAN and we should allocate
entries differently based on that.

The patch might be something like:
	if ((pci_dev->class & MASK) == PCI_BASE_CLASS_NETWORK) {
	...

in the right places to use a different (and new?) search loop.

grant

Re: [parisc-linux] traps.c 2.4 alignement [was: 2.6.0-test6-pa6 on b2k finaly crash]

[Carlos O'Donell]

On Mon, Oct 06, 2003 at 06:21:50PM +0200, Joel Soete wrote:
> Finaly it works on my c110 and also on a b180l :)
> 
> But, as we could awaiting when such code=13 (conditional trap iirc), occurs
> in kernel mode (as on my b2k or Max's c3k) the kernel hang without advise
> :(

It happens in "kernel mode" ? That should trigger an oops? It's a SIGFPE
for the kernel :)

c.

Re: [parisc-linux] traps.c 2.4 alignement [was: 2.6.0-test6-pa6 on b2k finaly crash]

[Joel Soete]

Grant,

As mentionned I couldn't reproduced just after this panic.
If the event re-occurs I will try first chaning 'ccio_mem_ratio' and let
you inform of progress.

Thanks a lot,
    Joel


>-- Original Message --
>Date: Mon, 6 Oct 2003 11:28:56 -0600
>From: Grant Grundler <grundler@parisc-linux.org>
>To: Joel Soete <soete.joel@tiscali.be>
>Cc: Carlos O'Donell <carlos@baldric.uwo.ca>,
>	"M. Grabert" <xam@cs.ucc.ie>, parisc-linux@lists.parisc-linux.org
>Subject: Re: [parisc-linux] traps.c 2.4 alignement [was: 2.6.0-test6-pa6
>on b2k finaly crash]
>
>
>On Sun, Oct 05, 2003 at 05:07:21PM +0000, Joel Soete wrote:
> hmm don't think if it's related but just in case:
> I was just copying my kernel tree with 'tar cslpf - 
> linux-2.6.0-test6-pa6 | ( cd Work ; tar xslpf -)' when
> 
> Kernel panic: driv
>rs/parisc/ccio-dma.c: ccio_alloc_range() I/O M.

You ran out of mapping resources.
        panic(__FILE__ ": %s() I/O MMU is out of mapping resources.\n",
	              __FUNCTION__);

> I just retry same operation on the same system with same k
>rnel but 
> doesn't occurs a second time?

Not surprising. The bitmap search will fail if everything gets
mapped "sparsely" or we try to search for a large mapping (>32K, ie more
than 8 pages) but can't find it. If this is repeatible problem, chan
>e

	/* Ratio of Host MEM to IOV Space size */
	static unsigned long ccio_mem_ratio = 4;

in drivers/parisc/ccio-dma.c (2.6 kernel) to 2.

One patch would be welcome here: figure out a threshold when
allocations for single pages should share an 
>-page "chunk"
(effectively one TLB entry).  E.g. differentiate between LAN
and SCSI requests.  LAN typically wants 1 entry (1500 byte MTU)
unless someone starts testing "Large Send" and is very "linear"
in it's DMA behavior (one DMA stream at a tim
>).  SCSI typically
wants 64k/128k (16 or 32 entries), has lots of those, and any one
of those could be the "next" DMA stream. ie thrashing the IO TLB
is much more likely with SCSI than LAN and we should allocate
entries differently based on that.

>
The patch might be something like:
	if ((pci_dev->class & MASK) == PCI_BASE_CLASS_NETWORK) {
	...

in the right places to use a different (and new?) search loop.

grant



-------------------------------------------------------------------------
L'Internet rapide, c'est pour tout le monde. Tiscali ADSL, 19,50 Euro
pendant 3 mois! http://reg.tiscali.be/default.asp?lg=fr 

Re: [parisc-linux] traps.c 2.4 alignement [was: 2.6.0-test6-pa6 on b2k finaly crash]

[Joel Soete]

Hi Carlos,

>>
>>On Mon, Oct 06, 2003 at 06:21:50PM +0200, Joel Soete wrote:
>> Finaly it works on my c110 and also on a b180l :)
>> 
>> But, as we could awaiting when such code=13 (conditional trap iirc), occurs
>> in kernel mode (as on my b2k or Max's c3k) the kernel
>>hang without advise
>> :(
>
>It happens in "kernel mode" ?

That is what said the original oops (a bug in init of console)?

> That should trigger an oops? It's a SIGFPE for the kernel :)

I so need more work

Thanks,
    Joel


-------------------------------------------------------------------------
L'Internet rapide, c'est pour tout le monde. Tiscali ADSL, 19,50 Euro
pendant 3 mois! http://reg.tiscali.be/default.asp?lg=fr 

RE: [parisc-linux] 2.6.0-test6-pa6 on b2k finaly crash

[Joel Soete]

Hi all,

I come back to this bug to just notice that in the init of 2.4 it was:
[...]
Initializing RT netlink socket
Soft power switch enabled, polling @ 0xf0400804.
SuperIO: Found NS87560 Legacy I/O device at 00:0e.1 (IRQ 64) 
SuperIO: Serial port 1 at 0x3f8
SuperIO: Serial port 2 at 0x2f8
SuperIO: Parallel port at 0x378
SuperIO: Floppy controller at 0x3f0
SuperIO: ACPI at 0x7e0
SuperIO: USB regulator enabled
parport0: PC-style at 0x378, irq 101 [PCSPP(,...)]
[...]

so 'superio_init' (if i don't mistake)

but here in 2.6:
[...]
Soft power switch enabled, polling @ 0xf0400804.
pty: 256 Unix98 ptys configured
lp: driver loaded but no devices found
Generic RTC Driver v1.07
Serial: 8250/16550 driver $Revision
[...]

so not superio_init (even thought CONFIG_SUPERIO=y and well find this function
into vmlinux)?

hth,
    Joel




-------------------------------------------------------------------------
L'Internet rapide, c'est pour tout le monde. Tiscali ADSL, 19,50 Euro
pendant 3 mois! http://reg.tiscali.be/default.asp?lg=fr 

Re: [parisc-linux] traps.c 2.4 alignement [was: 2.6.0-test6-pa6 on b2k finaly crash]

[Joel Soete]

[-- Attachment #1: Type: text/plain, Size: 861 bytes --]

 
>> But, as we could awaiting when such code=13 (conditional trap iirc), occurs
>> in kernel mode (as on my b2k or Max's c3k) the kernel
>>hang without advise
>> :(
>
>It happens in "kernel mode" ?

Even thought it shouldn't happen but would just help in case of unthinkable
bug :)

> That should trigger an oops? It's a SIGFPE for the kernel :)

Yes it should as far as i can follow force_sig_info() it would 'schedule'
a SIGFPE. But in this very particular situation of the early boot, imho the
scheduler is not yet launched.

So may be this second draft would help more in this case?
(I hope that attachement will be readable?)

Thanks again,
    Joel


-------------------------------------------------------------------------
L'Internet rapide, c'est pour tout le monde. Tiscali ADSL, 19,50 Euro
pendant 3 mois! http://reg.tiscali.be/default.asp?lg=fr 



[-- Attachment #2: Traps-2.4-Align-2 --]
[-- Type: application/octet-stream, Size: 5566 bytes --]

diff -Naur linux-2.6.0-test6-pa6.orig/arch/parisc/kernel/traps.c linux-2.6.0-test6-pa6.test/arch/parisc/kernel/traps.c
--- linux-2.6.0-test6-pa6.orig/arch/parisc/kernel/traps.c	2003-10-07 18:15:41.000000000 +0200
+++ linux-2.6.0-test6-pa6.test/arch/parisc/kernel/traps.c	2003-10-07 18:14:31.000000000 +0200
@@ -44,7 +44,7 @@
 #define PRINT_USER_FAULTS /* (turn this on if you want user faults to be */
 			  /*  dumped to the console via printk)          */
 
-int printbinary(char *buf, unsigned long x, int nbits)
+static int printbinary(char *buf, unsigned long x, int nbits)
 {
 	unsigned long mask = 1UL << (nbits - 1);
 	while (mask != 0) {
@@ -408,7 +408,7 @@
 
 
 /*
- * This routine handles page faults.  It determines the address,
+ * This routine handles various exception codes.  It determines the address,
  * and the problem, and then passes it off to one of the appropriate
  * routines.
  */
@@ -429,8 +429,18 @@
 	if (!console_drivers)
 		pdc_console_restart();
 
-	if (code == 1)
-	    transfer_pim_to_trap_frame(regs);
+
+	/* Not all switch paths will gutter the processor... */
+	switch(code){
+
+	case 1:
+		transfer_pim_to_trap_frame(regs);
+		break;
+	    
+	default:
+		/* Fall through */
+		break;
+	}
 
 	show_stack(NULL, (unsigned long *)regs->gr[30]);
 
@@ -446,34 +456,34 @@
 	 * system will shut down immediately right here. */
 	pdc_soft_power_button(0);
 	
+	/* Gutter the processor... */
 	for(;;)
 	    ;
 }
 
+
 void handle_interruption(int code, struct pt_regs *regs)
 {
 	unsigned long fault_address = 0;
 	unsigned long fault_space = 0;
 	struct siginfo si;
 
-	if (code == 1)
-	    pdc_console_restart();  /* switch back to pdc if HPMC */
-	else
-	    local_irq_enable();
-
-#if 0
-	printk(KERN_CRIT "Interruption # %d\n", code);
-#endif
+        /* JSO Begin */
+        printk(KERN_ERR "%s(%d, ...).\n", __FUNCTION__, code);
+	/*
+        mdelay(100);
+        JSO End */
 
 	switch(code) {
 
 	case  1:
 		/* High-priority machine check (HPMC) */
-		
+		pdc_console_restart();  /* switch back to pdc if HPMC */
+
 		/* set up a new led state on systems shipped with a LED State panel */
 		pdc_chassis_send_status(PDC_CHASSIS_DIRECT_HPMC);
-		    
-	    	parisc_terminate("High Priority Machine Check (HPMC)",
+
+		parisc_terminate("High Priority Machine Check (HPMC)",
 				regs, code, 0);
 		/* NOT REACHED */
 		
@@ -492,8 +502,9 @@
 
 	case  5:
 		/* Low-priority machine check */
+
 		pdc_chassis_send_status(PDC_CHASSIS_DIRECT_LPMC);
-		
+
 		flush_all_caches();
 		cpu_lpmc(5, regs);
 		return;
@@ -542,6 +553,7 @@
 
 		die_if_kernel("Privileged register usage", regs, code);
 		si.si_code = ILL_PRVREG;
+		/* Fall thru */
 	give_sigill:
 		si.si_signo = SIGILL;
 		si.si_errno = 0;
@@ -556,6 +568,24 @@
 		si.si_addr = (void *) regs->iaoq[0];
 		force_sig_info(SIGFPE, &si, current);
 		return;
+	
+	case 13:
+		if (user_mode(regs)) {
+#ifdef PRINT_USER_FAULTS
+			printk(KERN_DEBUG "\nhandle_interruption() pid=%d command='%s'\n",
+			    current->pid, current->comm);
+			show_regs(regs);
+#endif
+			/* Conditional Trap 
+			   The condition succees in an instruction which traps on condition  */
+			si.si_signo = SIGFPE;
+			/* Set to zero, and let the userspace app figure it out from
+			   the insn pointed to by si_addr */
+			si.si_code = 0;
+			si.si_addr = (void *) regs->iaoq[0];
+			force_sig_info(SIGFPE, &si, current);
+			return;
+		} else break;
 
 	case 14:
 		/* Assist Exception Trap, i.e. floating point exception. */
@@ -563,13 +593,22 @@
 		handle_fpe(regs);
 		return;
 
+	case 15: 
+		/* Data TLB miss fault/Data page fault */	
+		/* Fall thru */
+	case 16:
+		/* Non-access instruction TLB miss fault */
+		/* The instruction TLB entry needed for the target address of the FIC
+		   is absent, and hardware can't find it, so we get to cleanup */
+		/* Fall thru */
 	case 17:
 		/* Non-access data TLB miss fault/Non-access data page fault */
 		/* TODO: Still need to add slow path emulation code here */
-		pdc_chassis_send_status(PDC_CHASSIS_DIRECT_PANIC);
-		
+		/* TODO: Understand what is meant by the TODO listed 
+		   above this one. (Carlos) */
 		fault_address = regs->ior;
-		parisc_terminate("Non access data tlb fault!",regs,code,fault_address);
+		fault_space = regs->isr;
+		break;
 
 	case 18:
 		/* PCXS only -- later cpu's split this into types 26,27 & 28 */
@@ -579,9 +618,8 @@
 			return;
 		}
 		/* Fall Through */
-
-	case 15: /* Data TLB miss fault/Data page fault */
-	case 26: /* PCXL: Data memory access rights trap */
+	case 26: 
+		/* PCXL: Data memory access rights trap */
 		fault_address = regs->ior;
 		fault_space   = regs->isr;
 		break;
@@ -637,7 +675,6 @@
 			up_read(&current->mm->mmap_sem);
 		}
 		/* Fall Through */
-
 	case 27: 
 		/* Data memory protection ID trap */
 		die_if_kernel("Protection id trap", regs, code);
@@ -671,8 +708,9 @@
 			force_sig_info(SIGBUS, &si, current);
 			return;
 		}
-		pdc_chassis_send_status(PDC_CHASSIS_DIRECT_PANIC);
 		
+		pdc_chassis_send_status(PDC_CHASSIS_DIRECT_PANIC);
+
 		parisc_terminate("Unexpected interruption", regs, code, 0);
 		/* NOT REACHED */
 	}
@@ -702,18 +740,19 @@
 	     * The kernel should never fault on its own address space.
 	     */
 
-	    if (fault_space == 0) 
-	    {
+	    if (fault_space == 0) {
 		pdc_chassis_send_status(PDC_CHASSIS_DIRECT_PANIC);
 		parisc_terminate("Kernel Fault", regs, code, fault_address);
-	
+		/** NOT REACHED **/
 	    }
 	}
 
+	local_irq_enable();
 	do_page_fault(regs, code, fault_address);
 }
 
 
+
 int __init check_ivt(void *iva)
 {
 	int i;

Re: [parisc-linux] traps.c 2.4 alignement [was: 2.6.0-test6-pa6 on b2k finaly crash]

[Joel Soete]

Hi Grant,

Grant Grundler wrote:
> On Sun, Oct 05, 2003 at 05:07:21PM +0000, Joel Soete wrote:
> 
>>hmm don't think if it's related but just in case:
>>I was just copying my kernel tree with 'tar cslpf - 
>>linux-2.6.0-test6-pa6 | ( cd Work ; tar xslpf -)' when
>>
>>Kernel panic: drivers/parisc/ccio-dma.c: ccio_alloc_range() I/O M.
> 
> 
> You ran out of mapping resources.
>         panic(__FILE__ ": %s() I/O MMU is out of mapping resources.\n",
> 	              __FUNCTION__);
> 
> 
>>I just retry same operation on the same system with same kernel but 
>>doesn't occurs a second time?
> 
> 
> Not surprising. The bitmap search will fail if everything gets
> mapped "sparsely" or we try to search for a large mapping (>32K, ie more
> than 8 pages) but can't find it. If this is repeatible problem, change
> 
> 	/* Ratio of Host MEM to IOV Space size */
> 	static unsigned long ccio_mem_ratio = 4;
> 
> in drivers/parisc/ccio-dma.c (2.6 kernel) to 2.
> 

Well the pb re-occurs but, as mentioned previously, it is difficult to 
reproduce the exact circumstance of this occurence?
So test this change of ccio_mem_ratio = 4 to 2 and seems to works better :)

> One patch would be welcome here: figure out a threshold when
> allocations for single pages should share an 8-page "chunk"
> (effectively one TLB entry).  E.g. differentiate between LAN
> and SCSI requests.  LAN typically wants 1 entry (1500 byte MTU)
> unless someone starts testing "Large Send" and is very "linear"
> in it's DMA behavior (one DMA stream at a time).  SCSI typically
> wants 64k/128k (16 or 32 entries), has lots of those, and any one
> of those could be the "next" DMA stream. ie thrashing the IO TLB
> is much more likely with SCSI than LAN and we should allocate
> entries differently based on that.
> 
> The patch might be something like:
> 	if ((pci_dev->class & MASK) == PCI_BASE_CLASS_NETWORK) {
> 	...
> 
> in the right places to use a different (and new?) search loop.
> 

Will try to understand and see what can i do.

Thanks again,
	Joel