Date: Tue, 10 Jun 2003 15:34:36 -0700 From: John-Mark Gurney <gurney_j@efn.org> To: "M. Warner Losh" <imp@bsdimp.com> Cc: freebsd-sparc64@freebsd.org Subject: Re: PCI bus numbering and orphaned devices Message-ID: <20030610223436.GC37257@funkthat.com> In-Reply-To: <20030610.082730.102566465.imp@bsdimp.com> References: <20030609.224621.71095461.imp@bsdimp.com> <20030610115615.GB10527@cicely12.cicely.de> <20030610121249.GE10527@cicely12.cicely.de> <20030610.082730.102566465.imp@bsdimp.com>
next in thread | previous in thread | raw e-mail | index | archive | help
M. Warner Losh wrote this message on Tue, Jun 10, 2003 at 08:27 -0600:
> : > > hdrtype = REG(PCIR_HEADERTYPE, 1);
> : > This needs to be tested on that given hardware.
> : > I don't know if REG will work as expected because it asks function 0,
> : > which is disabled.
> :
> : I've reread John-Mark's last mail about the readable registers.
> : So - yes it should work.
>
> That's what inspired me. Also, I'd expected that we'd need some kind
> of tweaking to make it actually compile and be neat.
Ok, attached is a patched I tried, but sad to say, this doesn't work
out to well. I added a printf before and after the REG statement, and
a boot with the kernel give this output:
found-> vendor=0x108e, dev=0x5000, revid=0x13
bus=0, slot=1, func=1
class=06-04-00, hdrtype=0x01, mfdev=1
cmdreg=0x0147, statreg=0x02a0, cachelnsz=16 (dwords)
lattimer=0x50 (2400 ns), mingnt=0x02 (500 ns), maxlat=0x00 (0 ns)
about to read HEADERTYPE
panic: trap: data access error
cpuid = 0;
Uptime: 1s
panic: Assertion mtx_unowned(m) failed at ../../../kern/kern_mutex.c:956
cpuid = 0;
Uptime: 1s
panic: Assertion mtx_unowned(m) failed at ../../../kern/kern_mutex.c:956
cpuid = 0;
Uptime: 1s
the last three lines repeate for a while, but this is because of:
psycho_read_config(...)
[...]
/*
* The psycho bridge does not tolerate accesses to unconfigured PCI
* devices' or function's config space, so look up the device in the
* firmware device tree first, and if it is not present, return a value
* that will make the detection code think that there is no device here.
* This is ugly...
*/
if (reg == 0 && ofw_pci_find_node(bus, slot, func) == 0)
return (0xffffffff);
Which obviously will fail if reg != 0 which we try to do when reading
the PCIR_HEADERTYPE..
So, the question is, does other arch's do something nasty like this
too? Should I change the check to just do ofw_pci_find_node? Is this
why pciconf -r is returning 0xffffffff when reading the ebus and firewire
parts of the SME2300BGA? Simply because it isn't in the ofw tree?
I don't have any data sheets or the PCI spec, so making heads or tails
of this is going be hard.
--
John-Mark Gurney Voice: +1 415 225 5579
"All that I will do, has been done, All that I have, has not."
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?20030610223436.GC37257>