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

[David Holland <dholland-bugs%netbsd.org@localhost>]

The following reply was made to PR kern/47290; it has been noted by GNATS.

From: David Holland <dholland-bugs%netbsd.org@localhost>
To: gnats-bugs%netbsd.org@localhost
Cc: 
Subject: Re: kern/47290: Boot hangs up (regression in 6.0.0_PATCH since
 6.0_RELEASE)
Date: Sat, 12 Jan 2013 06:49:12 +0000

 again, not sent to gnats (please fix your mailreader)
 
    ------
 
 From: David Young <dyoung%pobox.com@localhost>
 To: Chuck Silvers <chuq%chuq.com@localhost>, gnats-admin%netbsd.org@localhost,
        netbsd-bugs%netbsd.org@localhost
 Cc: Martin Husemann <martin%duskware.de@localhost>, cheusov%tut.by@localhost, 
dsl%netbsd.org@localhost
 Subject: Re: kern/47290: Boot hangs up (regression in 6.0.0_PATCH since
        6.0_RELEASE)
 Date: Fri, 11 Jan 2013 12:02:31 -0600
 Mail-Followup-To: David Young <dyoung%pobox.com@localhost>, Chuck Silvers
        <chuq%chuq.com@localhost>, gnats-admin%netbsd.org@localhost, 
netbsd-bugs%netbsd.org@localhost, Martin
        Husemann <martin%duskware.de@localhost>, cheusov%tut.by@localhost, 
dsl%netbsd.org@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