weird boot up panics

every now and then i get a panic in au_icu.c that looks like a null
pointer dereference.  it is in au_iointr().   Typically this happens
when I press CTRL-S to stop a boot screen messages while I look for some
particular output.

I *think* what is happening is that the interrupt handlers are coming
and going during boot flow.

        irqmask = REGVAL(icu_base + IC_MASK_READ);
        au_cpuintrs[level].cintr_count.ev_count++;
        LIST_FOREACH(ih, &au_cpuintrs[level].cintr_list, ih_q) {
            int irq = (1 << ih->ih_irq);

            if ((irq & irqmask) && (irq & irqstat)) {
                au_icu_intrtab[ih->ih_irq].intr_count.ev_count++;
                (*ih->ih_func)(ih->ih_arg);

I wonder if the ih values need to be protected by splhigh() or some kind
of lock.

I also occasionally see where issue CTRL-C or somesuch causes aucomintr
to throw a fit:

Wed Mar  1 11:20:07 PST 2006
trap: TLB miss (load or instr. fetch) in kernel mode
status=0x2, cause=0x800408, epc=0x802d7e14, vaddr=0x1040002c
curlwp == NULL ksp=0xc0080d80
Stopped at      netbsd:aucomintr+0x88:  lw      v0,44(s2)

I've not looked at this further yet.  I just want to document it.  I'll

Re: weird boot up panics

Here's one of the au_iointr panics.

trap: address error (load or I-fetch) in kernel mode
status=0x2, cause=0x800410, epc=0x802d1898, vaddr=0xfc13
curlwp == NULL ksp=0xc007fe58
Stopped at      netbsd:au_iointr+0x120: lw      v1,16(s0)
db>
db>
db> bt
802d1830+68 (0,a0000000,800a0500,400) ra 80277920 sz 0
evbmips_iointr+10 (0,a0000000,800a0500,400) ra 10400074 sz 24
PC 0x10400074: not in kernel space
0+10400074 (0,a0000000,800a0500,400) ra 0 sz 0
User-level: curlwp NULL
db>

Note that once the system completes booting, it doesn't seem to have a
problem.  It is only during initial boot that I see this kind of
problem, and only if I interfere on the console.

--

-- 
Garrett D'Amore, Principal Software Engineer
Tadpole Computer / Computing Technologies Division,
General Dynamics C4 Systems
http://www.tadpolecomputer.com/
Phone: 951 325-2134  Fax: 951 325-2191

RFC: Alchemy Au1550 SMBus driver on PSC

Hi,

I'm implementing SMBus driver on PSC(bus) device.
Would you like to review the following files (attached with this mail):

  sys-arch-mips.diff:	diffs for sys/arch/mips from -current.
  ausmbus_psc.c:	smbus driver.
  smbusreg.c:		definitions for SMBus registers
			(Au1550 DataBook 8.5)

With implementing this driver, I revised up aupsc.c.
Please review it intensively.
--

-- 
Kind Regards,
--- shige
Shigeyuki Fukushima <shige <at> {FreeBSD,jp.FreeBSD,NetBSD}.org>

? sys/arch/mips/alchemy/dev/ausmbus_psc.c
? sys/arch/mips/alchemy/dev/smbusreg.h
Index: sys/arch/mips/alchemy/dev/aupsc.c
===================================================================
RCS file: /cvsroot/src/sys/arch/mips/alchemy/dev/aupsc.c,v
retrieving revision 1.1
diff -u -r1.1 aupsc.c
--- sys/arch/mips/alchemy/dev/aupsc.c	24 Feb 2006 14:34:31 -0000	1.1
+++ sys/arch/mips/alchemy/dev/aupsc.c	2 Mar 2006 17:39:41 -0000
 <at>  <at>  -59,21 +59,30  <at>  <at> 

 const struct aupsc_proto {

Re: RFC: Alchemy Au1550 SMBus driver on PSC

This looks pretty good.

Only one question: in aupsc_enable(), why do you bother to complain if
it is already enabled?  I think this should be one of two things:

1) if it is a programmer error, then make it a KASSERT()

2) if there is some reason why its not programmer error, then you should
probably just do the disable() yourself, and maybe put a message in an
#ifdef DIAGNOSTIC or somesuch.

Otherwise, it looks pretty good.  I will be able to put this to
immediate use pretty soon -- I want to hook a smart card interface up to
I2C. 

    -- Garrett

Shigeyuki Fukushima wrote:
> Hi,
>
> I'm implementing SMBus driver on PSC(bus) device.
> Would you like to review the following files (attached with this mail):
>
>   sys-arch-mips.diff:	diffs for sys/arch/mips from -current.
>   ausmbus_psc.c:	smbus driver.
>   smbusreg.c:		definitions for SMBus registers
> 			(Au1550 DataBook 8.5)
>
> With implementing this driver, I revised up aupsc.c.
> Please review it intensively.

Re: RFC: Alchemy Au1550 SMBus driver on PSC

Garrett D'Amore wrote:
> This looks pretty good.

Thanks.

> Only one question: in aupsc_enable(), why do you bother to complain if
> it is already enabled?  I think this should be one of two things:
> 
> 1) if it is a programmer error, then make it a KASSERT()
> 
> 2) if there is some reason why its not programmer error, then you should
> probably just do the disable() yourself, and maybe put a message in an
> #ifdef DIAGNOSTIC or somesuch.

I assume 2).
This is my assumption:
  Maybe board-providers can connect i2c devices and spi devices
  to same psc device.
  But, we cannot use two or more protocols on a psc device
  at the same time.
  When we may need switching protocol on a psc device,
  we may need to check already-enabled status on this device.

If this assumption is wrong
(for example, when we can only one (fixed) protocol on a psc device),
we need to reconsider a concept of implementing this driver,
and to detect kernel configuration errors.

Kernel configuration error example:
ausmbus*	at aupsc0

Re: RFC: Alchemy Au1550 SMBus driver on PSC

In article <4407307C.1040100 <at> netbsd.org>
shige <at> NetBSD.org wrote:

>   sys-arch-mips.diff:	diffs for sys/arch/mips from -current.
>   ausmbus_psc.c:	smbus driver.
>   smbusreg.c:		definitions for SMBus registers

Mostly looks good, but I'd suggest some cosmetics again:

> RCS file: /cvsroot/src/sys/arch/mips/alchemy/dev/aupscreg.h,v
 :
>  <at>  <at>  -124,5 +127,6  <at>  <at> 
>  #define	AUPSC_SMBEVNT			0x18	/* R/W */
>  #define	AUPSC_SMBTXRX			0x1c	/* R/W */
>  #define	AUPSC_SMBTMR			0x20	/* R/W */
> +#include <mips/alchemy/dev/smbusreg.h>
>  
>  #endif	/* _MIPS_ALCHEMY_DEV_AUPSCREG_H_ */

This #include is needed here?

> RCS file: /cvsroot/src/sys/arch/mips/conf/files.alchemy,v
>  # On-chip PSC
> -device	aupsc
> +device	aupsc { [addr=-1] }

This should be { [ addr = -1 ] } ?

In ausmbus_psc.c:
> #include <sys/lock.h>

Re: RFC: Alchemy Au1550 SMBus driver on PSC

In article <44086142.4030400 <at> netbsd.org>
shige <at> NetBSD.org wrote:

> (for example, when we can only one (fixed) protocol on a psc device),
> we need to reconsider a concept of implementing this driver,
> and to detect kernel configuration errors.

If we can assume all boards have static configuration on each PSC
and we don't have to switch protocols at runtime, we can put info
how each PSC is configured on the hardware via device properties
in board specific init functions, and au*_match function can check
the values.

Or, if we can assume the firmware configures each PSC properly,
we can read current settings from the PSC register in match function.
---
Izumi Tsutsui

Re: RFC: Alchemy Au1550 SMBus driver on PSC

Izumi Tsutsui wrote:
> In article <44086142.4030400 <at> netbsd.org>
> shige <at> NetBSD.org wrote:
>
>   
>> (for example, when we can only one (fixed) protocol on a psc device),
>> we need to reconsider a concept of implementing this driver,
>> and to detect kernel configuration errors.
>>     
>
> If we can assume all boards have static configuration on each PSC
> and we don't have to switch protocols at runtime, we can put info
> how each PSC is configured on the hardware via device properties
> in board specific init functions, and au*_match function can check
> the values.
>   
I like this idea.

I think we need to make autoconf.c device_register() be able to call
into some board-specific hook function.  Right now we don't have that.

In general, I do not believe that it is likely that you are going to
want to change the protocol for a PSC on a given board, or if you do,
its because its a debug board, and building a new kernel seems reasonable.

Actually, it would be nice to have support for properties in YAMON to be
able to override the generic board properties.  Then for development you
don't even need to build a new kernel if you change the hardware on a PSC.
> Or, if we can assume the firmware configures each PSC properly,
> we can read current settings from the PSC register in match function.

Re: List of critical PR's for 4.0

Christos Zoulas wrote:
> Please file a PR so that we can keep track of it.
>   
Done.  See PR evbmips/32980

--

-- 
Garrett D'Amore, Principal Software Engineer
Tadpole Computer / Computing Technologies Division,
General Dynamics C4 Systems
http://www.tadpolecomputer.com/
Phone: 951 325-2134  Fax: 951 325-2191

Re: weird boot up panics

In article <4405F49B.1020201 <at> tadpole.com>
garrett_damore <at> tadpole.com wrote:

> I *think* what is happening is that the interrupt handlers are coming
> and going during boot flow.

What is "during boot flow"?
Before mountroot, or during rc.d processes?

I have one concern that clock interrupt (INT5) shouldn't be
enabled until cpu_initclocks() is called, but I'm not sure
if that could cause your problem.

> Wed Mar  1 11:20:07 PST 2006
> trap: TLB miss (load or instr. fetch) in kernel mode
> status=0x2, cause=0x800408, epc=0x802d7e14, vaddr=0x1040002c
> curlwp == NULL ksp=0xc0080d80
> Stopped at      netbsd:aucomintr+0x88:  lw      v0,44(s2)

Hmm, how can the address 0x104000xx be passed for a pointer?
MIPS_PHYS_TO_KSEG1() is missed somewhere?

(btw ic0_base and ic1_base in au_icu.c should be vaddr_t,
 not bus_addr_t, I think)
---
Izumi Tsutsui