[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)
The following reply was made to PR kern/47290; it has been noted by GNATS.
From: David Young <dyoung%pobox.com@localhost>
Cc: chs%NetBSD.org@localhost, gnats-admin%netbsd.org@localhost,
Subject: Re: kern/47290: Boot hangs up (regression in 6.0.0_PATCH since
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
> Subject: Re: kern/47290: Boot hangs up (regression in 6.0.0_PATCH since
> 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).
dyoung%pobox.com@localhost Urbana, IL (217) 721-9981
Main Index |
Thread Index |