(Let's see if I've figured yet another workaround for the web
interface= ).
The address space used by the card I think is actually 0x80 bytes= ,
in the I/O port space. The card has it located at the port 0xEC00.
Yester= day I've had all the values and addresses written to this
card's registers = printed for debugging and I don't remember seeing
all ones written to this = register. It was writing back first 0xEC01
(1 is the I/O space indicator), = then 0xEC00. And no, the culprit is
not the missing bit 0 (which should be = read-only by the PCI spec):
I've tried adding it back, and it made no diffe= rence.
I'll try FreeBSD 8 and see what happens.
-SB
Ap= r 7, 2009 10:28:50 AM, [1]...@freebsd.org wrote:
On Monday 06 April 2009 11:12:33= pm Sergey Babkin wrote:
> John Baldwin wrote:
> >
> = > On Monday 06 April 2009 1:07:38 pm Ivan Voras wrote:
> > >= 2009/4/6 John Baldwin <[2]...@freebsd.org>:
> >= ; > > On Sunday 05 April 2009 12:23:39 pm Sergey Babkin wrote:
>= ; > >
> > > > Hmm, the problem is we need to be able t= o write to BARs
to size them.
б Any
> > OS
> > &= gt; > needs to be able to do this to know what address space
regions are being
> > > > decoded by devices. б We can't avoid= writing to BARs.
> > >
> > > I have only vague ide= a what BARs are and if it's the
correct diagnosis
> > > in this= case, but the fact is that other operating systems
(Windows,
> > = > Linux tested) work, so either there is a way around it or
the original > > > premise is wrong-ish.
> >
> > Every O= S writes to BARs to size them during boot. It's the
defined
procedure<= br>> > for sizing them. A BAR is a base address
register, and it is = how a PCI
> > device gets memory and I/O port resources. OS (or B= IOS)
writes a starting
> > address into the register to tell the P= CI device where a
given
> > resource "starts".
>
> Th= e OS doesn't have to write to the BAR if BIOS has already
> done it. = And the BIOS in the Hyper-V VM is obviously special,
> so it doesn't = trip on iself.
Yes it does because we don't know how _big_ the BAR = is. The OS
has to know if
the device is decoding 1MB or 64KB because w= e need to reserve the
entire
window to prevent any other devices from u= sing it. We don't just
write the
existing value, we write all 1's to i= t and read it back. The
lower N
bits "stick" at zero and we use that t= o figure out the BAR's
size. See
pci_add_map() in sys/dev/pci/pci.c
> Anyway, as far as I can tell, it's only the base register of
= > the simulated DEC21140 device that has this issue, so it's
> qu= ite possible that the bug is in that device's simulator.
>
> = I've attached a modified patch that checks conservatively for
this
> = precise situation, so it should not break compatibility with
> anythi= ng else. I've tested it on Hyper-V.
Can you test unmodified FreeBSD = 8 on Hyper-V? It has an extra fix
relative to
7 to disable decoding vi= a the PCI command register while sizing
BARs that may
address this.
--
John Baldwin
References
1. 3D"mailto:j...@freebsd.org";
2. 3D"mailto:j...@freebsd.org";
_______________________________________________
freebsd-hackers@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-hackers
To unsubscribe, send any mail to "freebsd-hackers-unsubscr...@freebsd.org"
