Allen Martin wrote:
Nothing inside the chipset should be decoding port 80 writes. It's
possible this board has a port 80 decoder wired onto the board that's
misbehaving. I've seen other laptop boards with port 80 decoders
wired onto the board, even if the 7 segment display is only populated
o
Allen Martin wrote:
Nothing inside the chipset should be decoding port 80 writes. It's
possible this board has a port 80 decoder wired onto the board that's
misbehaving. I've seen other laptop boards with port 80 decoders
wired onto the board, even if the 7 segment display is only populated
> Alan Cox wrote:
> > On Wed, 12 Dec 2007 21:58:25 +0100
> > Rene Herman <[EMAIL PROTECTED]> wrote:
> >
> >> On 12-12-07 21:26, Rene Herman wrote:
> >>
> >>> On 12-12-07 21:07, David P. Reed wrote:
> Someone might have an in to nVidia to clarify this,
> since I don't.
> In any case, t
On 14-12-07 23:05, Chuck Ebbert wrote:
On 12/12/2007 04:05 PM, H. Peter Anvin wrote:
Rene Herman wrote:
By the way, _does_ anyone have a contact at nVidia who could clarify?
Alan maybe? I'm quite curious what they did...
Summary:
Unless after booting with "acpi=off", outputs to port 0x80
On 12/12/2007 04:05 PM, H. Peter Anvin wrote:
> Rene Herman wrote:
>> On 12-12-07 21:26, Rene Herman wrote:
>>
>>> On 12-12-07 21:07, David P. Reed wrote:
>>
Someone might have an in to nVidia to clarify this, since I don't.
In any case, the udelay(2) approach seems to be a safe fix for
> One wonders if it does some SMM trick to capture port 0x80 writes and
> attempt to haul them off for debugging; it almost sounds like some kind
> of debugging code got let out into the field.
Not implausible. We've got a bug I've been dealing with where a vendor
left debug stuff enabled via th
Alan Cox wrote:
On Wed, 12 Dec 2007 21:58:25 +0100
Rene Herman <[EMAIL PROTECTED]> wrote:
On 12-12-07 21:26, Rene Herman wrote:
On 12-12-07 21:07, David P. Reed wrote:
Someone might have an in to nVidia to clarify this, since I don't. In
any case, the udelay(2) approach seems to be a safe f
Rene Herman wrote:
On 12-12-07 21:26, Rene Herman wrote:
On 12-12-07 21:07, David P. Reed wrote:
Someone might have an in to nVidia to clarify this, since I don't.
In any case, the udelay(2) approach seems to be a safe fix for this
machine.
By the way, _does_ anyone have a contact at nVi
On Wed, 12 Dec 2007 21:58:25 +0100
Rene Herman <[EMAIL PROTECTED]> wrote:
> On 12-12-07 21:26, Rene Herman wrote:
>
> > On 12-12-07 21:07, David P. Reed wrote:
>
> >> Someone might have an in to nVidia to clarify this, since I don't. In
> >> any case, the udelay(2) approach seems to be a safe
On 12-12-07 21:26, Rene Herman wrote:
On 12-12-07 21:07, David P. Reed wrote:
Someone might have an in to nVidia to clarify this, since I don't. In
any case, the udelay(2) approach seems to be a safe fix for this machine.
By the way, _does_ anyone have a contact at nVidia who could clarify
Port 0xED, just FYI:
cycles: out 1430, in 1370
cycles: out 1429, in 1370
(800 Mhz)
Rene Herman wrote:
On 12-12-07 21:07, David P. Reed wrote:
Sadly, I've been busy with other crises in my day job for the last
few days. I did modify Rene's test program and ran it on my
"problem" machine,
On 12-12-07 21:07, David P. Reed wrote:
Sadly, I've been busy with other crises in my day job for the last few
days. I did modify Rene's test program and ran it on my "problem"
machine, with the results below.
The interesting part of this is that port 80 seems to respond to "in"
instructio
Sadly, I've been busy with other crises in my day job for the last few
days. I did modify Rene's test program and ran it on my "problem"
machine, with the results below.
The interesting part of this is that port 80 seems to respond to "in"
instructions faster than the presumably "unused" por
13 matches
Mail list logo
