> Date: Sun, 5 Aug 2012 12:54:39 +0200
> From: Mike Belopuhov <m...@crypt.org.ru>
>
> On Sat, Aug 04, 2012 at 11:33 +0200, Mike Belopuhov wrote:
> > On Fri, Aug 03, 2012 at 18:03 -0000, r...@kooleconsulting.nl wrote:
> > > Just tried it, but the result is identical. Is there a way to obtain
> > > more useful debugging output? I'm willing to put in testing effort here as
> > > I have two of these and strongly prefer to run OpenBSD on them.
> > >
> >
> > yes. please find a diff below. it should allow you to boot the kernel
> > so that we can do pcidump and acpidump. you can get the kernel installed
> > by ftp from bsd.rd.
> >
> > please also collect the output of "machine memory" from the boot>
> > prompt and the dmesg whith the diff i've provided since it has some
> > debugging output.
> >
>
> I've been working on this with Rick and it looks like I've found the
> culprit, but I'd like others, especially Mark, to take a closer look
> at my findings.
>
> So my theory is that IBM or whoever they've entrusted with doing that
> have programmed SMBus function BARs incorrectly.
>
> This is what pcidump shows us (device 0:31:3: Intel 6 Series SMBus):
>
> 0x0010: 81b00004 00003050 00000000 00000000
>
> And this is how we interpret it:
>
> 0x0010: BAR mem 64bit addr: 0x0000305081b00000/0x00000100
>
> We do so because of that '4' which tells us: it's a 64 bit address.
Right.
> But in fact the 0x3050 part is an IO BAR and it's not marked as such!
> IO BAR must have a type of '1' so it must be 0x3051. Now 0x81b00000
> is in fact a 32-bit address and must have a type '0'. So all in all
> it should say:
>
> 0x0010: 81b00000 00003051 00000000 00000000
>
> and it will be interpreted as
>
> 0x0010: BAR mem 32bit addr: 0x81b00000/0x00000100
> 0x0014: BAR io addr: 0x00003050/<some lenght>
Well, the chipset docs document the BAR at 0x10/0x14 as 64-bit, so I
really think its just the BIOS that's confused and believes that 0x10
is a 32-bit mmio BAR and 0x14 is an io BAR. According to the chipset
docs the io BAR lives at 0x20:
0x0020: BAR io addr: 0x0000efa0/0x0020
> I think there's nothing we can do about it as it's clearly their fault.
> But having said that, does anyone know of any other option? Or maybe
> my analysis is wrong?
It is ;). But I agree that the BIOS is busted.
We should probably handle this in a more graceful manner. Best thing
is probably to add explicit checks for ex_start and ex_end, and clear
the BAR if it falls outside that range, just like we do when we
encounter a mem address conflict. I'll see if I can cook up a diff
for that.
