NetBSD-Bugs archive

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index][Old Index]

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

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 <>
> To:
> 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).


David Young    Urbana, IL    (217) 721-9981

Home | Main Index | Thread Index | Old Index