hello
problem with 2.6.7-rc3 and asus a7n8x nforce2 board is here that
the C1 disconnect fix is not applied anymore after booting.
-rc2 worked OK without any lockups.
i understand that the new fix in -rc3 checks an bios option
to enable the fixup but the a7n8x bios does not have such option.
so it would be nice to have the possibility to force the fixup, because
it worked really fine here before.
thanks,
lars
Do you get lockups with -rc3 and not with -rc2?
On Thursday 10 of June 2004 14:18, Lars wrote:
> hello
>
> problem with 2.6.7-rc3 and asus a7n8x nforce2 board is here that
> the C1 disconnect fix is not applied anymore after booting.
> -rc2 worked OK without any lockups.
> i understand that the new fix in -rc3 checks an bios option
> to enable the fixup but the a7n8x bios does not have such option.
> so it would be nice to have the possibility to force the fixup, because
> it worked really fine here before.
>
> thanks,
> lars
hi
thanks for answering!
rc2 worked completely stable with c1 disconnect halt enabled and low
cpu temp.
rc3 has no C1 enabled after booting, so the cpu temp rises, but its
stable.
when enabling the c1 disconnect halt after this with something like
"setpci -v -H1 -s 0:0.0 6F=$(printf %x $((0x$(setpci -H1 -s 0:0.0 6F) |
0x10)))"
(from
http://www.tldp.org/HOWTO/Athlon-Powersaving-HOWTO/approaches.html#commandline)
the cpu is getting cool again but the system locks up frequently.
so it would be great to have the fixup re-enabled at boottime.
maybe a switch to force the fixup on boards without c1 disconnect
bios-settings would do it ?
thanks,
lars
Bartlomiej Zolnierkiewicz wrote:
>
> Do you get lockups with -rc3 and not with -rc2?
>
Lars wrote:
>hi
>
>thanks for answering!
>
>rc2 worked completely stable with c1 disconnect halt enabled and low
>cpu temp.
>
>
I've kind of opposite here. with rc2-mm2 boot message says that fixup is
applied. "athcool stat" says 'c1 bit disabled'.
Everything stable. When I enable that bit with "athcool on" the system
will lock up solid after an hour or so.
With 2.6.1-rc1-mm1 I could enable that bit manually and everything was
still stable afterwards ...
Lenar
On Thursday 10 of June 2004 15:26, Lars wrote:
> hi
Hi,
> thanks for answering!
>
> rc2 worked completely stable with c1 disconnect halt enabled and low
> cpu temp.
> rc3 has no C1 enabled after booting, so the cpu temp rises, but its
> stable.
> when enabling the c1 disconnect halt after this with something like
> "setpci -v -H1 -s 0:0.0 6F=$(printf %x $((0x$(setpci -H1 -s 0:0.0 6F) |
> 0x10)))"
> (from
> http://www.tldp.org/HOWTO/Athlon-Powersaving-HOWTO/approaches.html#commandl
>ine) the cpu is getting cool again but the system locks up frequently.
> so it would be great to have the fixup re-enabled at boottime.
> maybe a switch to force the fixup on boards without c1 disconnect
> bios-settings would do it ?
We can't do that, some older boards hang if C1 disconnect is used.
However you can enable fixup and then C1 Halt Disconnect yourself. :-)
setpci -v -H1 -s 0:0.0 6C.L=$(printf %x $((0x$(setpci -H1 -s 0:0.0 6C.L) & 0x9F01FF01)))
- to enable fixup first
setpci -v -H1 -s 0:0.0 6F=$(printf %x $((0x$(setpci -H1 -s 0:0.0 6F) | 0x10)))
- to enable C1 Halt Disconnect
[ this is untested as I don't have nForce2 board ]
> thanks,
> lars
>
> Bartlomiej Zolnierkiewicz wrote:
> > Do you get lockups with -rc3 and not with -rc2?
thanks
after some reading, im using now in rc.local:
### C1 Halt Disconnect Fix for Chip rev. C17
setpci -H1 -s 0:0.0 6F=1F
setpci -H1 -s 0:0.0 6E=01
echo "Applying C1 Halt Disconnect Fix"
this is for an older nforce2 board (a7n8x 1.04) with rev. C17 chip
and worked fine so far.
for the newer chip revision it should read
### C1 Halt Disconnect Fix for Chip rev. C18D
setpci -H1 -s 0:0.0 6F=9F
setpci -H1 -s 0:0.0 6E=01
echo "Applying C1 Halt Disconnect Fix"
first setpci is for the c1 halt bit and the second one enables the
80ns stability value.
i understand that its not good to enable c1 for all boards, but it would
be nice to have the option to force the fixup on boards which
work ok but have no bios option to enable c1. (like the a7n8x)
an bootoption like "forceC1halt" or something would be nice here.
cheers,
lars
>> ...maybe a switch to force the fixup on boards without c1 disconnect
>> bios-settings would do it ?
>
> We can't do that, some older boards hang if C1 disconnect is used.
>
> However you can enable fixup and then C1 Halt Disconnect yourself. :-)
>
> setpci -v -H1 -s 0:0.0 6C.L=$(printf %x $((0x$(setpci -H1 -s 0:0.0 6C.L) &
> 0x9F01FF01)))
>
> - to enable fixup first
>
> setpci -v -H1 -s 0:0.0 6F=$(printf %x $((0x$(setpci -H1 -s 0:0.0 6F) |
> 0x10)))
>
> - to enable C1 Halt Disconnect
>
> [ this is untested as I don't have nForce2 board ]
On Thursday 10 of June 2004 23:36, Lars wrote:
> thanks
>
> after some reading, im using now in rc.local:
>
> ### C1 Halt Disconnect Fix for Chip rev. C17
> setpci -H1 -s 0:0.0 6F=1F
> setpci -H1 -s 0:0.0 6E=01
> echo "Applying C1 Halt Disconnect Fix"
>
> this is for an older nforce2 board (a7n8x 1.04) with rev. C17 chip
> and worked fine so far.
>
> for the newer chip revision it should read
>
> ### C1 Halt Disconnect Fix for Chip rev. C18D
> setpci -H1 -s 0:0.0 6F=9F
> setpci -H1 -s 0:0.0 6E=01
> echo "Applying C1 Halt Disconnect Fix"
>
> first setpci is for the c1 halt bit and the second one enables the
> 80ns stability value.
Order should be reversed.
> i understand that its not good to enable c1 for all boards, but it would
> be nice to have the option to force the fixup on boards which
> work ok but have no bios option to enable c1. (like the a7n8x)
> an bootoption like "forceC1halt" or something would be nice here.
It can be perfectly handled in user-space as you've just showed. :-)
There is no need to add complexity to the kernel.
> cheers,
> lars
>
> >> ...maybe a switch to force the fixup on boards without c1 disconnect
> >> bios-settings would do it ?
> >
> > We can't do that, some older boards hang if C1 disconnect is used.
> >
> > However you can enable fixup and then C1 Halt Disconnect yourself. :-)
> >
> > setpci -v -H1 -s 0:0.0 6C.L=$(printf %x $((0x$(setpci -H1 -s 0:0.0 6C.L)
> > & 0x9F01FF01)))
> >
> > - to enable fixup first
> >
> > setpci -v -H1 -s 0:0.0 6F=$(printf %x $((0x$(setpci -H1 -s 0:0.0 6F) |
> > 0x10)))
> >
> > - to enable C1 Halt Disconnect
> >
> > [ this is untested as I don't have nForce2 board ]
>
> -
> To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
> the body of a message to [email protected]
> More majordomo info at http://vger.kernel.org/majordomo-info.html
> Please read the FAQ at http://www.tux.org/lkml/
On Thu, 2004-06-10 at 23:56, Bartlomiej Zolnierkiewicz wrote:
> On Thursday 10 of June 2004 23:36, Lars wrote:
> > thanks
> >
> > after some reading, im using now in rc.local:
> >
> > ### C1 Halt Disconnect Fix for Chip rev. C17
> > setpci -H1 -s 0:0.0 6F=1F
> > setpci -H1 -s 0:0.0 6E=01
> > echo "Applying C1 Halt Disconnect Fix"
> >
> > this is for an older nforce2 board (a7n8x 1.04) with rev. C17 chip
> > and worked fine so far.
> >
> > for the newer chip revision it should read
> >
> > ### C1 Halt Disconnect Fix for Chip rev. C18D
> > setpci -H1 -s 0:0.0 6F=9F
> > setpci -H1 -s 0:0.0 6E=01
> > echo "Applying C1 Halt Disconnect Fix"
> >
> > first setpci is for the c1 halt bit and the second one enables the
> > 80ns stability value.
>
> Order should be reversed.
>
> > i understand that its not good to enable c1 for all boards, but it would
> > be nice to have the option to force the fixup on boards which
> > work ok but have no bios option to enable c1. (like the a7n8x)
> > an bootoption like "forceC1halt" or something would be nice here.
>
> It can be perfectly handled in user-space as you've just showed. :-)
> There is no need to add complexity to the kernel.
Except if people have the trouble when installing Linux.... ok, yes,
they can still be done somehow, but thats just ugly for the "put cd in
and install" users. Surely the kernel should be detecting this stuff and
using various options as required.
Craig
just learned that
setpci -H1 -s 0:0.0 6C.L=0x9F01FF01
enables C1 *and* the 80ns stability fix.
looks like i have to stick with my ugly little workaround for a while
best,
lars
> Order should be reversed.
>
> It can be perfectly handled in user-space as you've just showed. :-)
> There is no need to add complexity to the kernel.
On Friday 11 of June 2004 00:00, Craig Bradney wrote:
> On Thu, 2004-06-10 at 23:56, Bartlomiej Zolnierkiewicz wrote:
> > On Thursday 10 of June 2004 23:36, Lars wrote:
> > > thanks
> > >
> > > after some reading, im using now in rc.local:
> > >
> > > ### C1 Halt Disconnect Fix for Chip rev. C17
> > > setpci -H1 -s 0:0.0 6F=1F
> > > setpci -H1 -s 0:0.0 6E=01
> > > echo "Applying C1 Halt Disconnect Fix"
> > >
> > > this is for an older nforce2 board (a7n8x 1.04) with rev. C17 chip
> > > and worked fine so far.
> > >
> > > for the newer chip revision it should read
> > >
> > > ### C1 Halt Disconnect Fix for Chip rev. C18D
> > > setpci -H1 -s 0:0.0 6F=9F
> > > setpci -H1 -s 0:0.0 6E=01
> > > echo "Applying C1 Halt Disconnect Fix"
> > >
> > > first setpci is for the c1 halt bit and the second one enables the
> > > 80ns stability value.
> >
> > Order should be reversed.
> >
> > > i understand that its not good to enable c1 for all boards, but it
> > > would be nice to have the option to force the fixup on boards which
> > > work ok but have no bios option to enable c1. (like the a7n8x)
> > > an bootoption like "forceC1halt" or something would be nice here.
> >
> > It can be perfectly handled in user-space as you've just showed. :-)
> > There is no need to add complexity to the kernel.
>
> Except if people have the trouble when installing Linux.... ok, yes,
What trouble are you talking about?
Fix is in the kernel and is applied when C1 Halt Disconnect is enabled.
If C1 H.D. is disabled you need to enable it somehow from user-space,
thus you can apply fixup from user-space at the same time.
> they can still be done somehow, but thats just ugly for the "put cd in
> and install" users. Surely the kernel should be detecting this stuff and
> using various options as required.
If you think that kernel should have options for all PCI tweaks
available than sorry but you are wrong (grab powertweak instead).
> Craig
On Friday 11 of June 2004 00:19, Lars wrote:
> just learned that
> setpci -H1 -s 0:0.0 6C.L=0x9F01FF01
> enables C1 *and* the 80ns stability fix.
>
> looks like i have to stick with my ugly little workaround for a while
"ugly"?
We can probably change kernel fixup to always do & 0x9F01FF01
but adding "force C1HD" kernel options sounds insane.
>
> best,
> lars
>
> > Order should be reversed.
> >
> > It can be perfectly handled in user-space as you've just showed. :-)
> > There is no need to add complexity to the kernel.
On Fri, 2004-06-11 at 00:26, Bartlomiej Zolnierkiewicz wrote:
> On Friday 11 of June 2004 00:00, Craig Bradney wrote:
> > On Thu, 2004-06-10 at 23:56, Bartlomiej Zolnierkiewicz wrote:
> > > On Thursday 10 of June 2004 23:36, Lars wrote:
> > > > thanks
> > > >
> > > > after some reading, im using now in rc.local:
> > > >
> > > > ### C1 Halt Disconnect Fix for Chip rev. C17
> > > > setpci -H1 -s 0:0.0 6F=1F
> > > > setpci -H1 -s 0:0.0 6E=01
> > > > echo "Applying C1 Halt Disconnect Fix"
> > > >
> > > > this is for an older nforce2 board (a7n8x 1.04) with rev. C17 chip
> > > > and worked fine so far.
> > > >
> > > > for the newer chip revision it should read
> > > >
> > > > ### C1 Halt Disconnect Fix for Chip rev. C18D
> > > > setpci -H1 -s 0:0.0 6F=9F
> > > > setpci -H1 -s 0:0.0 6E=01
> > > > echo "Applying C1 Halt Disconnect Fix"
> > > >
> > > > first setpci is for the c1 halt bit and the second one enables the
> > > > 80ns stability value.
> > >
> > > Order should be reversed.
> > >
> > > > i understand that its not good to enable c1 for all boards, but it
> > > > would be nice to have the option to force the fixup on boards which
> > > > work ok but have no bios option to enable c1. (like the a7n8x)
> > > > an bootoption like "forceC1halt" or something would be nice here.
> > >
> > > It can be perfectly handled in user-space as you've just showed. :-)
> > > There is no need to add complexity to the kernel.
> >
> > Except if people have the trouble when installing Linux.... ok, yes,
>
> What trouble are you talking about?
>
> Fix is in the kernel and is applied when C1 Halt Disconnect is enabled.
> If C1 H.D. is disabled you need to enable it somehow from user-space,
> thus you can apply fixup from user-space at the same time.
>
> > they can still be done somehow, but thats just ugly for the "put cd in
> > and install" users. Surely the kernel should be detecting this stuff and
> > using various options as required.
>
> If you think that kernel should have options for all PCI tweaks
> available than sorry but you are wrong (grab powertweak instead).
Well.. no.. I dont suggest that the kernel apply fixes for all the buggy
motherboards and other h/w out there.. but I guess the distro builders
need to make sure these post boot options are being set based on
hardware detected, or something. :)
Craig
On Friday 11 of June 2004 00:32, Craig Bradney wrote:
> On Fri, 2004-06-11 at 00:26, Bartlomiej Zolnierkiewicz wrote:
> > On Friday 11 of June 2004 00:00, Craig Bradney wrote:
> > > On Thu, 2004-06-10 at 23:56, Bartlomiej Zolnierkiewicz wrote:
> > > > On Thursday 10 of June 2004 23:36, Lars wrote:
> > > > > thanks
> > > > >
> > > > > after some reading, im using now in rc.local:
> > > > >
> > > > > ### C1 Halt Disconnect Fix for Chip rev. C17
> > > > > setpci -H1 -s 0:0.0 6F=1F
> > > > > setpci -H1 -s 0:0.0 6E=01
> > > > > echo "Applying C1 Halt Disconnect Fix"
> > > > >
> > > > > this is for an older nforce2 board (a7n8x 1.04) with rev. C17 chip
> > > > > and worked fine so far.
> > > > >
> > > > > for the newer chip revision it should read
> > > > >
> > > > > ### C1 Halt Disconnect Fix for Chip rev. C18D
> > > > > setpci -H1 -s 0:0.0 6F=9F
> > > > > setpci -H1 -s 0:0.0 6E=01
> > > > > echo "Applying C1 Halt Disconnect Fix"
> > > > >
> > > > > first setpci is for the c1 halt bit and the second one enables the
> > > > > 80ns stability value.
> > > >
> > > > Order should be reversed.
> > > >
> > > > > i understand that its not good to enable c1 for all boards, but it
> > > > > would be nice to have the option to force the fixup on boards which
> > > > > work ok but have no bios option to enable c1. (like the a7n8x)
> > > > > an bootoption like "forceC1halt" or something would be nice here.
> > > >
> > > > It can be perfectly handled in user-space as you've just showed. :-)
> > > > There is no need to add complexity to the kernel.
> > >
> > > Except if people have the trouble when installing Linux.... ok, yes,
> >
> > What trouble are you talking about?
> >
> > Fix is in the kernel and is applied when C1 Halt Disconnect is enabled.
> > If C1 H.D. is disabled you need to enable it somehow from user-space,
> > thus you can apply fixup from user-space at the same time.
> >
> > > they can still be done somehow, but thats just ugly for the "put cd in
> > > and install" users. Surely the kernel should be detecting this stuff
> > > and using various options as required.
> >
> > If you think that kernel should have options for all PCI tweaks
> > available than sorry but you are wrong (grab powertweak instead).
>
> Well.. no.. I dont suggest that the kernel apply fixes for all the buggy
> motherboards and other h/w out there.. but I guess the distro builders
Sure it needs to apply fixes if they are needed for stability etc.
Please note that if C1HD is not enabled in the BIOS we cannot
force it - some boards do not support it et all (even with fixup).
We may try to apply fixup always but enabling of C1HD _feature_
(your machine should work perfectly without it, if it doesn't i.e.
overheats then it can also overheat with C1HD under heavy load)
must be leaved to user-space.
Alternatively we can add "forceC1Halt" kernel option
but it simply sucks: it is useless for non nForce2 users,
you can't disable it and you've to maintain it (forever?).
> need to make sure these post boot options are being set based on
> hardware detected, or something. :)
>
> Craig
Cheers.
Bartlomiej Zolnierkiewicz wrote:
> On Friday 11 of June 2004 00:19, Lars wrote:
>> just learned that
>> setpci -H1 -s 0:0.0 6C.L=0x9F01FF01
>> enables C1 *and* the 80ns stability fix.
>>
>> looks like i have to stick with my ugly little workaround for a while
>
> "ugly"?
just kiddin' ;)
>
> We can probably change kernel fixup to always do & 0x9F01FF01
> but adding "force C1HD" kernel options sounds insane.
i guess that always applying 0x9F01FF01 will force c1 for all users
to *on* again, because the 9F value triggers this.
its my understanding that
0x9F01FF01 enables c1 and fix
0x0F01FF01 disables c1, enables fix
0x0F0FFF01 disables c1 and fix
am i right ?
best,
lars
On Friday 11 of June 2004 01:01, Lars wrote:
> Bartlomiej Zolnierkiewicz wrote:
> > On Friday 11 of June 2004 00:19, Lars wrote:
> >> just learned that
> >> setpci -H1 -s 0:0.0 6C.L=0x9F01FF01
> >> enables C1 *and* the 80ns stability fix.
> >>
> >> looks like i have to stick with my ugly little workaround for a while
> >
> > "ugly"?
>
> just kiddin' ;)
>
> > We can probably change kernel fixup to always do & 0x9F01FF01
> > but adding "force C1HD" kernel options sounds insane.
>
> i guess that always applying 0x9F01FF01 will force c1 for all users
> to *on* again, because the 9F value triggers this.
> its my understanding that
> 0x9F01FF01 enables c1 and fix
> 0x0F01FF01 disables c1, enables fix
> 0x0F0FFF01 disables c1 and fix
>
> am i right ?
Yes but doing & should always give the right result:
0x0F0FFF01 & 0x9F01FF01 -> 0x0F01FF01
(disabled -> disabled + fix)
0x9F0FFF01 & 0x9F01FF01 -> 0x9F01FF01
(enabled -> enabled + fix)
...
aha! just learned something new :)
looks good to me.
thanks again for your time,
lars
>> its my understanding that
>> 0x9F01FF01 enables c1 and fix
>> 0x0F01FF01 disables c1, enables fix
>> 0x0F0FFF01 disables c1 and fix
>>
>> am i right ?
>
> Yes but doing & should always give the right result:
> 0x0F0FFF01 & 0x9F01FF01 -> 0x0F01FF01
> (disabled -> disabled + fix)
> 0x9F0FFF01 & 0x9F01FF01 -> 0x9F01FF01
> (enabled -> enabled + fix)
> ...