Re: CVS commit: src/sys/arch/sparc64

[Takeshi Nakayama <tn%catvmics.ne.jp@localhost>]

>>> matthew green <mrg%eterna.com.au@localhost> wrote

> 
> i'm curious - what were you going to trigger this problem?

Discussion about bge driver in last month's port-sparc64.

I have known this method since I was adding a cardbus support to
sparc64 a decade ago.  But I adopted the method checking a OFW's
node instead of it.  I've been meaning to implement it if I have a
chance.

> > Module Name:        src
> > Committed By:       nakayama
> > Date:               Fri Jun 21 20:09:59 UTC 2013
> > 
> > Modified Files:
> >     src/sys/arch/sparc64/dev: psycho.c pyro.c schizo.c
> >     src/sys/arch/sparc64/include: cpu.h
> >     src/sys/arch/sparc64/sparc64: trap.c
> > 
> > Log Message:
> > Avoid data_access_error trap panic when reading unused PCI
> > configuration space.
> > 
> > This method is described in UltraSPARC IIi User's Manual "16.2.1
> > Probing PCI during boot using deferred errors", and refer to the
> > implementation of OpenBSD.
> 
> hmmm, i wonder if kpreempt_disable()/enable() should go
> around these calls now.  we don't want these accesses
> to migrate to another cpu in the middle ..
> 
> i don't think there's any reason pci_conf_* have to be
> called in a context that has kpreempt already disabled.

It seems sparc64's MD codes don't treat about kpreempt, so I didn't
care about kpreempt.

Thanks,

-- Takeshi Nakayama