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

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

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

From: David Young <dyoung%pobox.com@localhost>
To: gnats-bugs%NetBSD.org@localhost
Cc: chs%NetBSD.org@localhost, gnats-admin%netbsd.org@localhost, 
netbsd-bugs%netbsd.org@localhost,
 cheusov%tut.by@localhost
Subject: Re: kern/47290: Boot hangs up (regression in 6.0.0_PATCH since
 6.0_RELEASE)
Date: Fri, 11 Jan 2013 11:51:37 -0600

 On Fri, Jan 11, 2013 at 10:05:03AM +0000, Martin Husemann wrote:
 > The following reply was made to PR kern/47290; it has been noted by GNATS.
 > 
 > From: Martin Husemann <martin%duskware.de@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: Fri, 11 Jan 2013 11:03:55 +0100
 > 
 >  After a bit of painfull debugging (including booting patched FreeBSD kernels
 >  to verify their acpi subsystem does the same _DIS calls) I ended up with a
 >  patch that seems to work around the problem - but it is a bit mind puzzling.
 >  
 >  Unfortunately todays -current doesn't seem to boot on this machine, probably
 >  due to something completely unrelated - so my boot still does not complete.
 >  
 >  Anyway, the interesting part of the long story: the execution of some _DIS
 >  method on my machiine ends with a 8bit wide write to pci config space.
 >  Since those writes are only well defined for 32bit access, we do a read-
 >  modify-write cycle to set the requested byte. It is the write part of that
 >  cycle that kills my machine.
 >  
 >  So, despite knowing this is a bad idea, I hacked a patch that uses byte
 >  access to directly store the requested byte in pci config space - and that
 >  makes my machine survive. Now I am not sure if the out-of-spec byte acccess
 >  is ignored by the hardware (so I basically disabled the deadly store), or if
 >  this now all works as intended.
 >  
 >  Now, I agree that in general we should forbid such writes, as some
 >  architecture can not even implement them for arbitrary pci devices.
 >  However, given the tight binding of ACPI and hardware, we should allow
 >  them for this case.
 
 It's my understanding that bits 0:1 of port 0xCF8 are read-only and
 always zero, so your implementation of pci_conf_write_8(..., reg = 125,
 val) may write one byte to reg 124.  I think that in order to write to
 the correct address, it may be necessary to write (reg & ~3) to 0xCFA
 and to outb(0xCFC + (reg & 3), val).
 
 Dave
 
 -- 
 David Young
 dyoung%pobox.com@localhost    Urbana, IL    (217) 721-9981