Re: kern/47290: Boot hangs up (regression in 6.0.0_PATCH since 6.0_RELEASE)

[David Young <dyoung%pobox.com@localhost>]

On Fri, Jan 11, 2013 at 09:20:28AM -0800, Chuck Silvers wrote:
> On Thu, Jan 10, 2013 at 05:41:54PM +0100, Martin Husemann wrote:
> > Ok - I have something, but you won't like it.
> > 
> > I traced down further where it hangs up:
> > 
> > As last step of executing the third (and last) AML instruction in the _DIS
> > method of LNK3 it ends up doing a pci config space write via:
> > 
> > 
> > /*      
> >  * AcpiOsWritePciConfiguration:
> >  *
> >  *      Write a value to a PCI configuration register.
> >  */
> > ACPI_STATUS
> > AcpiOsWritePciConfiguration(ACPI_PCI_ID *PciId, UINT32 Register,
> >     ACPI_INTEGER Value, UINT32 Width)
> > 
> > in sys/dev/acpi/acpica/OsdHardware.c.
> > 
> > The call in question asks to write a 0 byte to register 125 of bus 0
> > device 1 function 0.
> > 
> > Since a byte access to config space is not defined, we do a 32bit read
> > (resulting in a value of 0 as well) and mask and set the byte, then
> > write back the full 32bit word - and then the machine hangs.
> > 
> > I wondered if FreeBSD does just a byte write instead, but I am lost in their
> > code.
> > 
> > Easy to test: I hacked a pci_conf_write_8() call (doing outb instead
> > of outl) and modified AcpiOsWritePciConfiguration() to use that if Width is 
> > 8.
> > 
> > This made my machine boot. Yay!
> > 
> > However, this hack makes me realy nervous. We could consider allowing
> > sub-word config writes limited to acpi scope, given how tight the bios
> > and hardware are tied, but this still sounds hackish.
> 
> 
> wow, excellent detective work!
> I would never have guessed that this was the problem.
> 
> I'd say you're right, we need to access PCI config space exactly like the BIOS
> tells us to, even though this might cause us to do so in ways which violate
> the normal rules.  the BIOS knows better than we do about such things.
> 
> I see that you verified that freebsd does this, and I confirmed just now
> that linux does it too.  it looks like openbsd does NOT do this,
> so I would guess that openbsd wouldn't work on this box either.
> I don't remember if you've tried that.  if openbsd actually does work,
> then that might be worth some more investigation.
> 
> 
> for a real fix, I guess we need to add pci_conf_{read,write}_width()
> (or somesuch) that add a "width" argument to what the normal calls have,
> and have ACPI use those instead of the normal versions.
> 
> I'm not sure if it would be necessary to add these to the "struct 
> pci_overrides" stuff...
> in the abstract I suppose it should be added but it's hard to say because 
> nothing
> in the tree actually uses that override mechanism.
> 
> dyoung, do you have any opinion on this, especially the overrides question?
> 
> is there anyone else we should specifically ask about this?

Let me suggest the names pci_conf_{read,write}_{1,2,4} since
that's parallel with bus_space_{read,write}_{1,2,4}.  I look at
pci_conf_write_8() and make a double-take: a 64-bit wide configuration
write, preposterous! :-)

I think that pci_conf_{read,write}_4 can simply be aliases for
pci_conf_{read,write}?

I'm about 75% finished getting rid of cardbus attachments using
pci_overrides, so their upkeep is important to me. :-)

Regarding the overrides, it's pretty easy to add a new one.
Basically you just need to reserve the next four bits, 9 - 13, from
pci_override_idx for PCI_OVERRIDE_CONF_{READ,WRITE}_{1,2}.  Then add
the overrides to struct pci_overrides in the same order.  The code can
be copied & pasted from pci_conf_{read,write}() and adapted to use the
right bits & struct members.  I think that's all you will need to do.
Anyway, I'll be happy to help out.

Dave

-- 
David Young
dyoung%pobox.com@localhost    Urbana, IL    (217) 721-9981