[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index][Old Index]
Re: CVS commit: src/sys/arch/sparc64
>>> 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
> > 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.
-- Takeshi Nakayama
Main Index |
Thread Index |