>>> matthew green <m...@eterna.com.au> 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
