Tom de Waal wrote: > Li, all, > > Just an update: I've successfully changed to ON 111b. This does fix > the krtld issues and the special kernel does boot. > - I've done testing on an AMD X2 - but since its multi core but not > hwpstate and I disabled the check for hwpstate - the kernel crashes > (AMD specifically states that TSC change should not be done on a > multicore). I now know why ....Note: I had to change a buggy > motherboard by a new one to get to this point. > - I'm waiting for a colleague to do further testing on a old, single > core Intel (he uses the previous version). > - I need to upgrade my VIA system to to further VIA testing. > > A side question: AMD states that HPET should be used over TSC (see > http://marc.info/?l=linux-kernel&m=113112235513757&w=2 - there are > more sources). The motherboard has an option "enable HPET". I do not > see any support for HPET in the code. Am I missing something?
When a hardware vendor mentions operating systems they generally mean Windows or occasionally Linux on single- socket laptops or desktops. In this case Windows and Linux do not use hrtime very often compared with Solaris. The single HPET also does not scale over many CPUs. The HPET is very high latency compared with TSC due to it being in the chipset instead of the CPU. There is also a different HPET read latency from different CPUs on multi-socket systems due to a different number of HyperTransport links between the CPU and the HT node with the I/O link to the chipset. I thought I read somewhere that admins of Linux database servers often disable the HPET in favor of the TSC as a high resolution time source due to the performance difference? Regards, Bill > Regards, > > Tom. > > Li, Aubrey wrote: >> Tom de Waal <> wrote: >> >>> Hi, >>> >>> For over a year I've build and somewhat maintained code that allows >>> clockscaling for older, not p-state variant CPU's. These CPU are >>> supported by OpenSolaris but run only a full speed. This introduces >>> annoying issues like high levels fans noise and high power usage. >>> I used to have a cpudrv that would replace the standard cpudrv and did >>> magic. The magic being the use of Casper Dik's clockscale code and >>> some tweaking from my side. This has proven to work on Intel, AMD and >>> VIA CPU's. For over a year at some cases. >>> >>> Since build 109 all this has broken. No doubt with good reason, but >>> still. I managed to re-engineer the code so that I can compile a new >>> kernel, but booting (in vanilla 2009/06) it results in an weird >>> error (this >>> manually copy/paste do i may have made a typo): >>> >>> not found: print_msg_hwerr >>> krtld: error during initial load/link phase >>> >>> krtld could neither locate nor resolve symbols for: >>> /platform/i86pc/kernel/amd64/unix >>> in the boot archive. Please verify this file >>> matches what is found in the boot archive. >>> You may need to boot using the Solaris failasafe to fix this. >>> Unable to boot >>> Press any key to reboot. >>> >>> To prevent wrong discussions: >>> - its a new BE on the 2009.06 environment. Thats quite OK (I can boot >>> that before and afterwards) >>> - I did rebuild the boot archive before booting (by mounting the BE /) >>> - This behaviour occurs both in a VirtualBox and on a bare metal AMD >>> box. >> >> How did you apply your change into the new BE? Are you using the >> Cap-Eye-Install >> to replace kernel image only or BFU? 2009.6 is based on snv_111, >> which build of kernel >> are you using? >> >> As far as I know, "print_msg_hwerr" implementation was added recently >> after onnv_115, >> if you are using onnv_116 and later kernel but using snv_111 BE, I >> think that would be >> a problem. >> >> -Aubrey >> >> >>> I'm looking for anybody that can give some support on getting this >>> working. I'm not looking for an official support of this code >>> (however - it would be nice...), but anybody with old style laptops, >>> PC's or VIA CPU's most likely will be great full! >>> >>> I can (and will) mail all changes I've made to ON, but I hate to >>> clutter this alias by appending these right now. >>> >>> Regards, >>> >>> Tom de Waal >>> _______________________________________________ >>> pm-discuss mailing list >>> pm-discuss at opensolaris.org >>> http://mail.opensolaris.org/mailman/listinfo/pm-discuss >> >
