kdb getting healthier? (PCI guru needed, that's you willy!)

The kernel still goes into an infinite loop of unknown origin:
---
PCI or EISA Bus Adapter 0 is not registered...
---
(see ./arch/parisc/kernel/pci.c' -> PCI_PORT_IN) Don't know where this gets called from, or how the ugly macro expands :)

Sadly I think I zapped my VGA out on the 712/60 (A common occurence?). It no longer produces _any_ video signals.
I may have to drag a 715/50 back to my house...

c.

_______________________________________________
parisc-linux mailing list
[email protected]
http://lists.parisc-linux.org/mailman/listinfo/parisc-linux

that ugly macro expands into inb/inw/inl. that printk probably needs to go away -- i don't think it's helpful. maybe it should stay for adapter != 0, but so many drivers probe ISA space for their devices that we're going to keep getting them.

i bet the loop isn't infinite... probably driver probing. If you turn off CONFIG_PCI, the driver shouldn't be compiled in.

unwind.c Thu Jun 6 08:51:49 2002 renamed from unwind.c.orig Thu Jun 6 08:51:02 2002 +1 -1

-       table->end = base_addr + end[-1].region_end;
+       table->end = base_addr + end[0].region_end - sizeof(struct unwind_table_entry);
        table->table = (struct unwind_table_entry *)table_start;
        table->length = end - start;
        table->next = NULL;

Is this a gcc-ism we're seeing?
Note-to-self: Look at .S produced from compiling unwind.c

unwind.c Thu Jun 6 08:51:49 2002 line 112

Quoted 6 lines

unwind.c Thu Jun 6 08:51:49 2002 renamed from unwind.c.orig Thu Jun 6 08:51:02 2002 +1 -1

-       table->end = base_addr + end[-1].region_end;
 
+       table->end = base_addr + end[0].region_end - sizeof(struct unwind_table_entry);
        table->table = (struct unwind_table_entry *)table_start;
        table->length = end - start;
        table->next = NULL;

It's definitely dangerous to use array indexes outside the bounds of the array, particularly on the PA. There can be problems with space register selection, although I wouldn't expect this to be a in the linux kernel. You can avoid index insns with "-mdisable-indexing". Let me know if you see anything strange in the assembler output.

Dave

It should really be something like:

table->end = base_addr + (&end[0] - sizeof(struct unwind_table_entry))->region_end;

I'm pretty sure that the end[-1] is causing a processor fault. Which then causes kdb to kick-in, but the unwind table isn't built yet so it can't find a matching entry.

If this doesn't work, then how is one supposed to correctly get the last table entry? :)

(end == __stop___unwind)

  __start___unwind = .;         /* unwind info */
  .PARISC.unwind : { *(.PARISC.unwind) }
  __stop___unwind = .;

Quoted 7 lines

It's definitely dangerous to use array indexes outside the bounds of the array, particularly on the PA. There can be problems with space register selection, although I wouldn't expect this to be a in the linux kernel. You can avoid index insns with "-mdisable-indexing". Let me know if you see anything strange in the assembler output.

Dave

unwind.s Fri Jun 7 09:24:55 2002 renamed from unwind-orig.s Fri Jun 7 11:01:33 2002 +2 -2

-       ldw -12(%r22),%r19
-       extrs %r20,27,28,%r20
+       ldo -16(%r20),%r20
+       ldw 4(%r20),%r19

Aside from some register juggling, the only difference is that we now use 'ldo,ldw,sub,extrs' instead of 'sub,ldw,extrs'. The question is: Can this do bad things?

The only possible difference is the space register selection could be different for the ldw insns in the old code versus the new because the pointer values in the base differ by 16.

Quoted 3 lines

The only possible difference is the space register selection could be different for the ldw insns in the old code versus the new because the pointer values in the base differ by 16.

but not in the kernel because all space registers are set to 0.

Are they always 0 or are there situations where drivers change a space register value? If they never change, then the memory limit is still 3GB.