Re: powernow regression in 8-STABLE
on 25/07/2011 21:55 Jung-uk Kim said the following: powernow expects a static table (via acpi_perf) but _PSS is dynamically constructed at runtime. I don't think we can support this case easily, sorry. Just a side note. Actually I do not see anything wrong with that _PSS except that ASL seems to have been passed through a mangler and it makes reading the code hard. _PSS is a method and it is evaluated as a method in acpi_perf, the method returns a package. I am not sure what exactly you meant when you said that powernow expects a static table. I do not see why the return value can not be dynamically constructed while _PSS is evaluated and why that would affect any of our code. -- Andriy Gapon ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to freebsd-stable-unsubscr...@freebsd.org
Re: powernow regression in 8-STABLE
On Saturday 23 July 2011 04:21 am, Callum Gibson wrote: On 22Jul11 17:57, Jung-uk Kim wrote: }Please try the attached patch. If it doesn't work, I need to see }acpidump -dt output. Sorry, no difference. Given jhb's response is there any point pursuing this further? Seems to be a known issue with legacy usb that perhaps can't be fixed. In any case, acpidump output here: http://members.optusnet.com.au/callumgibson/acpidump.out.gz I agree that the legacy USB issue must be fixed but your BIOS is more broken than I originally thought. powernow expects a static table (via acpi_perf) but _PSS is dynamically constructed at runtime. I don't think we can support this case easily, sorry. Jung-uk Kim ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to freebsd-stable-unsubscr...@freebsd.org
Re: powernow regression in 8-STABLE
On 25Jul11 14:55, Jung-uk Kim wrote: }I agree that the legacy USB issue must be fixed but your BIOS is more }broken than I originally thought. powernow expects a static table }(via acpi_perf) but _PSS is dynamically constructed at runtime. I }don't think we can support this case easily, sorry. Thanks for looking at it. John's hack is working for now. It would be interesting to see a response from either of you to Jeremy's question/comments. C -- Callum Gibson @ home http://members.optusnet.com.au/callumgibson/ ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to freebsd-stable-unsubscr...@freebsd.org
Re: powernow regression in 8-STABLE
On Saturday 23 July 2011 04:47 am, Jeremy Chadwick wrote:
On Sat, Jul 23, 2011 at 06:13:04PM +1000, Callum Gibson wrote:
On 22Jul11 08:16, John Baldwin wrote:
}The problem is that we calibrate the TSC using this algorithm:
}
} - grab the TSC
} - spin on the ISA timer waiting for it to run for a second
} - grab the TSC
}
}The issue is that the SMI# fires at the same time we want to be
execuiting }step 3, and step 3 is deferred while the SMI# handler
runs. As a result, the }TSC delta ends up being 1 second + time
of an SMI# to poll USB. We have a }hack fix for this at work
that originally came from Attilio Rao. This is a }patch for it
relative to 8. It disables interrupt generation for the ISA
}timer while we calibrate the TSC (which disables the SMI#
temporarily):
Thanks, John. The hack works as intended, but I guess it's not a
real solution which is why you haven't committed it?
This sort of thing is going to have to get dealt with officially
sooner or later, hack-fix or elegant solution either way[1].
More and more systems are using native USB keyboards, and most
system BIOSes I've seen (from multiple vendors, specifically
Supermicro, Lenovo, Asus, Dell, HP, and Gigabyte[2]) are defaulting
to having these options enabled (and rightfully so).
If the hack-fix has repercussions, it would be helpful to know what
those are or how those might manifest themselves. Otherwise, has
anyone taken a look at how Linux addresses this problem? To my
knowledge GRUB and similar bootstraps do not have a native USB
stack, so I'm left wondering how they deal with this.
[1]: I'm in no way saying Hey! Fix this! {contributes nothing},
I'm simply pointing out that we're at a point where we really don't
have much of a choice. The more I read technical explanations from
John the more hate x86 architecture. ;-)
[2]: On a couple Gigabyte boards I have the default values for said
option is enabled (for both keyboard and mouse).
It is really annoying problem and it has to be fixed *properly*.
Previously, we dealt with similar SMI# problem per platform, e.g.,
http://svnweb.freebsd.org/base?view=revisionrevision=174557
This quirk table matches 6 platforms now:
if (strncmp(sysenv, MacBook1,1, 10) == 0 ||
strncmp(sysenv, MacBook3,1, 10) == 0 ||
strncmp(sysenv, MacBookPro1,1, 13) == 0 ||
strncmp(sysenv, MacBookPro1,2, 13) == 0 ||
strncmp(sysenv, MacBookPro3,1, 13) == 0 ||
strncmp(sysenv, Macmini1,1, 10) == 0) {
if (bootverbose)
printf(Disabling LEGACY_USB_EN bit on
Intel ICH.\n);
outl(ICH_SMI_EN, inl(ICH_SMI_EN) ~0x8);
}
...
We definitely need to generalize it as soon as possible.
Jung-uk Kim
___
freebsd-stable@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-stable
To unsubscribe, send any mail to freebsd-stable-unsubscr...@freebsd.org
Re: powernow regression in 8-STABLE
On 22Jul11 08:16, John Baldwin wrote: }The problem is that we calibrate the TSC using this algorithm: } } - grab the TSC } - spin on the ISA timer waiting for it to run for a second } - grab the TSC } }The issue is that the SMI# fires at the same time we want to be execuiting }step 3, and step 3 is deferred while the SMI# handler runs. As a result, the }TSC delta ends up being 1 second + time of an SMI# to poll USB. We have a }hack fix for this at work that originally came from Attilio Rao. This is a }patch for it relative to 8. It disables interrupt generation for the ISA }timer while we calibrate the TSC (which disables the SMI# temporarily): Thanks, John. The hack works as intended, but I guess it's not a real solution which is why you haven't committed it? C -- Callum Gibson @ home http://members.optusnet.com.au/callumgibson/ ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to freebsd-stable-unsubscr...@freebsd.org
Re: powernow regression in 8-STABLE
On 22Jul11 17:57, Jung-uk Kim wrote: }Please try the attached patch. If it doesn't work, I need to see }acpidump -dt output. Sorry, no difference. Given jhb's response is there any point pursuing this further? Seems to be a known issue with legacy usb that perhaps can't be fixed. In any case, acpidump output here: http://members.optusnet.com.au/callumgibson/acpidump.out.gz C -- Callum Gibson @ home http://members.optusnet.com.au/callumgibson/ ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to freebsd-stable-unsubscr...@freebsd.org
Re: powernow regression in 8-STABLE
On Sat, Jul 23, 2011 at 06:13:04PM +1000, Callum Gibson wrote:
On 22Jul11 08:16, John Baldwin wrote:
}The problem is that we calibrate the TSC using this algorithm:
}
} - grab the TSC
} - spin on the ISA timer waiting for it to run for a second
} - grab the TSC
}
}The issue is that the SMI# fires at the same time we want to be execuiting
}step 3, and step 3 is deferred while the SMI# handler runs. As a result,
the
}TSC delta ends up being 1 second + time of an SMI# to poll USB. We have a
}hack fix for this at work that originally came from Attilio Rao. This is a
}patch for it relative to 8. It disables interrupt generation for the ISA
}timer while we calibrate the TSC (which disables the SMI# temporarily):
Thanks, John. The hack works as intended, but I guess it's not a real
solution which is why you haven't committed it?
This sort of thing is going to have to get dealt with officially sooner
or later, hack-fix or elegant solution either way[1].
More and more systems are using native USB keyboards, and most system
BIOSes I've seen (from multiple vendors, specifically Supermicro,
Lenovo, Asus, Dell, HP, and Gigabyte[2]) are defaulting to having these
options enabled (and rightfully so).
If the hack-fix has repercussions, it would be helpful to know what
those are or how those might manifest themselves. Otherwise, has anyone
taken a look at how Linux addresses this problem? To my knowledge GRUB
and similar bootstraps do not have a native USB stack, so I'm left
wondering how they deal with this.
[1]: I'm in no way saying Hey! Fix this! {contributes nothing}, I'm
simply pointing out that we're at a point where we really don't have
much of a choice. The more I read technical explanations from John the
more hate x86 architecture. ;-)
[2]: On a couple Gigabyte boards I have the default values for said
option is enabled (for both keyboard and mouse).
--
| Jeremy Chadwickjdc at parodius.com |
| Parodius Networking http://www.parodius.com/ |
| UNIX Systems Administrator Mountain View, CA, US |
| Making life hard for others since 1977. PGP 4BD6C0CB |
___
freebsd-stable@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-stable
To unsubscribe, send any mail to freebsd-stable-unsubscr...@freebsd.org
Re: powernow regression in 8-STABLE
On 21Jul11 17:53, Jung-uk Kim wrote: } } http://members.optusnet.com.au/callumgibson/boot_verboser_nousb.out } and dev.cpu.0.freq reappears! Spooky. Is that a solution or a } workaround? I noticed this disables usb keyboard support at the } boot menus. } }It is a workaround. Please try the attached patch. Sorry, no improvement that I can see. See verbose output: http://members.optusnet.com.au/callumgibson/boot_verboser2.out C -- Callum Gibson @ home http://members.optusnet.com.au/callumgibson/ ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to freebsd-stable-unsubscr...@freebsd.org
Re: powernow regression in 8-STABLE
On Thursday, July 21, 2011 5:43:10 pm Jeremy Chadwick wrote:
On Fri, Jul 22, 2011 at 06:56:00AM +1000, Callum Gibson wrote:
On 21Jul11 12:07, Jung-uk Kim wrote:
}Can you please do set debug.cpufreq.verbose=1 from loader prompt and
}show me the dmesg output? I want to see intial settings. You can
}reset it from command line with sysctl debug.cpufreq.verbose=0
}later.
http://members.optusnet.com.au/callumgibson/boot_verboser.out
Also, as suggested by jhb@, with legacy usb disabled:
http://members.optusnet.com.au/callumgibson/boot_verboser_nousb.out
and dev.cpu.0.freq reappears! Spooky. Is that a solution or a workaround?
I noticed this disables usb keyboard support at the boot menus.
Legacy USB support is a horribly-named BIOS option.
What the option actually does, without getting into the technicalities,
is make your USB keyboard work inside of environments where there is no
USB driver. The most commonly-used examples are bootloader/bootstraps
and MS-DOS.
The BIOS itself (meaning the firmware/BIOS, not the BIOS as in a piece
of legacy technology) has a tiny USB stack in it. That's how your
USB keyboard is able to work (e.g. to press Del or F2 to get into the
BIOS itself), and how you're able to boot from USB-attached devices.
You should keep Legacy USB enabled if you want your keyboard to work
in bootloaders/bootstraps. If enabling this feature breaks something
else, that sounds like a bug in the vendor BIOS to me, and you should
contact the vendor or motherboard manufacturer to inform them of the
bug.
It's a known issue that the Legacy USB option can break our TSC calibration
code causing an inflated value of the TSC frequency. The issue is that the
legacy USB code is often very dumb. It is implemented via polling in SMI#.
It appears that each interrupt from the ISA timer triggers an SMI# that polls
the USB bus looking for any keyboards and checking for any pending keyboard
events) that it can then use to trigger simulated PS/2 keyboard actions.
The problem is that we calibrate the TSC using this algorithm:
- grab the TSC
- spin on the ISA timer waiting for it to run for a second
- grab the TSC
The issue is that the SMI# fires at the same time we want to be execuiting
step 3, and step 3 is deferred while the SMI# handler runs. As a result, the
TSC delta ends up being 1 second + time of an SMI# to poll USB. We have a
hack fix for this at work that originally came from Attilio Rao. This is a
patch for it relative to 8. It disables interrupt generation for the ISA
timer while we calibrate the TSC (which disables the SMI# temporarily):
Index: x86/isa/clock.c
===
--- x86/isa/clock.c (.../mirror/FreeBSD/stable/8/sys) (revision
224114)
+++ x86/isa/clock.c (.../stable/8/sys) (revision 224114)
@@ -119,7 +119,7 @@
static unsigned i8254_get_timecount(struct timecounter *tc);
static unsigned i8254_simple_get_timecount(struct timecounter *tc);
-static voidset_i8254_freq(u_int freq, int intr_freq);
+static voidset_i8254_freq(u_int freq, int intr_freq, int freerun);
static struct timecounter i8254_timecounter = {
i8254_get_timecount,/* get_timecount */
@@ -447,15 +447,32 @@
#endif
}
+/*
+ * XXX: This is a gross hack to workaround USB legacy emulation. For
+ * some systems, the USB legacy emulation is implemented by a periodic
+ * SMI# triggered by the i8254. The resulting SMI# could cause the
+ * DELAY() to run too long resulting in the TSC being miscalibrated.
+ * The workaround is to disable i8254 interrupts while calibrating the
+ * TSC.
+ */
+void
+DELAY_TSCCAL(int n)
+{
+
+ set_i8254_freq(i8254_freq, hz, 1);
+ DELAY(n);
+ set_i8254_freq(i8254_freq, hz, 0);
+}
+
static void
-set_i8254_freq(u_int freq, int intr_freq)
+set_i8254_freq(u_int freq, int intr_freq, int freerun)
{
int new_i8254_real_max_count;
i8254_timecounter.tc_frequency = freq;
mtx_lock_spin(clock_lock);
i8254_freq = freq;
- if (using_lapic_timer != LAPIC_CLOCK_NONE)
+ if (using_lapic_timer != LAPIC_CLOCK_NONE || freerun)
new_i8254_real_max_count = 0x1;
else
new_i8254_real_max_count = TIMER_DIV(intr_freq);
@@ -508,7 +525,7 @@
{
mtx_init(clock_lock, clk, NULL, MTX_SPIN | MTX_NOPROFILE);
- set_i8254_freq(i8254_freq, hz);
+ set_i8254_freq(i8254_freq, hz, 0);
}
void
@@ -517,7 +534,7 @@
atrtc_start();
- set_i8254_freq(i8254_freq, hz);
+ set_i8254_freq(i8254_freq, hz, 0);
tc_init(i8254_timecounter);
init_TSC();
@@ -565,7 +582,7 @@
i8254_timecounter.tc_get_timecount =
i8254_simple_get_timecount;
i8254_timecounter.tc_counter_mask = 0x;
- set_i8254_freq(i8254_freq, hz);
+ set_i8254_freq(i8254_freq, hz, 0);
Re: powernow regression in 8-STABLE
On Friday 22 July 2011 07:13 am, Callum Gibson wrote:
On 21Jul11 17:53, Jung-uk Kim wrote:
}
}
http://members.optusnet.com.au/callumgibson/boot_verboser_nousb.out
} and dev.cpu.0.freq reappears! Spooky. Is that a solution or a }
workaround? I noticed this disables usb keyboard support at the }
boot menus.
}
}It is a workaround. Please try the attached patch.
Sorry, no improvement that I can see. See verbose output:
http://members.optusnet.com.au/callumgibson/boot_verboser2.out
Please try the attached patch. If it doesn't work, I need to see
acpidump -dt output.
Jung-uk Kim
Index: sys/kern/kern_cpu.c
===
--- sys/kern/kern_cpu.c (revision 224271)
+++ sys/kern/kern_cpu.c (working copy)
@@ -145,9 +145,7 @@ static int
cpufreq_attach(device_t dev)
{
struct cpufreq_softc *sc;
- struct pcpu *pc;
device_t parent;
- uint64_t rate;
int numdevs;
CF_DEBUG(initializing %s\n, device_get_nameunit(dev));
@@ -157,18 +155,7 @@ cpufreq_attach(device_t dev)
sysctl_ctx_init(sc-sysctl_ctx);
TAILQ_INIT(sc-all_levels);
CF_MTX_INIT(sc-lock);
- sc-curr_level.total_set.freq = CPUFREQ_VAL_UNKNOWN;
SLIST_INIT(sc-saved_freq);
- /* Try to get nominal CPU freq to use it as maximum later if needed */
- sc-max_mhz = cpu_get_nominal_mhz(dev);
- /* If that fails, try to measure the current rate */
- if (sc-max_mhz = 0) {
- pc = cpu_get_pcpu(dev);
- if (cpu_est_clockrate(pc-pc_cpuid, rate) == 0)
- sc-max_mhz = rate / 100;
- else
- sc-max_mhz = CPUFREQ_VAL_UNKNOWN;
- }
/*
* Only initialize one set of sysctls for all CPUs. In the future,
@@ -500,6 +487,7 @@ cf_get_method(device_t dev, struct cf_level *level
goto out;
}
}
+ CF_DEBUG(get freq failed, estimated freq %d\n, (int)rate);
error = ENXIO;
out:
@@ -551,17 +539,23 @@ cf_levels_method(device_t dev, struct cf_level *le
* provide settings for informational purposes only.
*/
error = CPUFREQ_DRV_TYPE(devs[i], type);
- if (error || (type CPUFREQ_FLAG_INFO_ONLY)) {
- if (error == 0) {
- CF_DEBUG(skipping info-only driver %s\n,
- device_get_nameunit(devs[i]));
- }
+ if (error)
continue;
- }
set_count = MAX_SETTINGS;
error = CPUFREQ_DRV_SETTINGS(devs[i], sets, set_count);
if (error || set_count == 0)
continue;
+ if ((type CPUFREQ_TYPE_MASK) == CPUFREQ_TYPE_ABSOLUTE
+ sc-max_mhz sets[0].freq) {
+ CF_DEBUG(setting max freq %d from %s\n,
+ sets[0].freq, device_get_nameunit(devs[i]));
+ sc-max_mhz = sets[0].freq;
+ }
+ if ((type CPUFREQ_FLAG_INFO_ONLY) != 0) {
+ CF_DEBUG(skipping info-only driver %s\n,
+ device_get_nameunit(devs[i]));
+ continue;
+ }
/* Add the settings to our absolute/relative lists. */
switch (type CPUFREQ_TYPE_MASK) {
@@ -867,8 +861,9 @@ cpufreq_dup_set(struct cpufreq_softc *sc, struct c
static int
cpufreq_curr_sysctl(SYSCTL_HANDLER_ARGS)
{
+ struct cf_level level;
+ struct cf_level *levels;
struct cpufreq_softc *sc;
- struct cf_level *levels;
int count, devcount, error, freq, i, n;
device_t *devs;
@@ -876,10 +871,10 @@ cpufreq_curr_sysctl(SYSCTL_HANDLER_ARGS)
sc = oidp-oid_arg1;
levels = sc-levels_buf;
- error = CPUFREQ_GET(sc-dev, levels[0]);
+ error = CPUFREQ_GET(sc-dev, level);
if (error)
goto out;
- freq = levels[0].total_set.freq;
+ freq = level.total_set.freq;
error = sysctl_handle_int(oidp, freq, 0, req);
if (error != 0 || req-newptr == NULL)
goto out;
@@ -1000,8 +995,11 @@ out:
int
cpufreq_register(device_t dev)
{
+ struct cf_setting set;
+ struct cf_setting *sets;
struct cpufreq_softc *sc;
device_t cf_dev, cpu_dev;
+ int error, freq, max, set_count, type;
/* Add a sysctl to get each driver's settings separately. */
SYSCTL_ADD_PROC(device_get_sysctl_ctx(dev),
@@ -1009,14 +1007,34 @@ cpufreq_register(device_t dev)
OID_AUTO, freq_settings, CTLTYPE_STRING | CTLFLAG_RD, dev, 0,
cpufreq_settings_sysctl, A, CPU frequency driver settings);
+ /* Get settings from the device and find current and maximum
frequencies */
+ freq = max =
Re: powernow regression in 8-STABLE
On Wednesday 20 July 2011 10:28 pm, Callum Gibson wrote: On 20Jul11 19:28, Jung-uk Kim wrote: }From your dmesg output, I see that the processor speed was not }calibrated properly. ML-40's max. core freq. is 2,200 MHz according }to its specification but it was probed at 2,282 MHz, which is too }high. I think that's the problem. Can you please try the attached }patch? Yes, I have seen core freq wobble around for most of the time I've owned it, but usually close to 2200. This morning (with my reverted powernow.c) I had: dev.cpu.0.freq_levels: 3080/35000 2800/29000 2520/24000 2240/2 1120/9000 which I don't believe I've seen before. Anyway... With your new patch applied (and powernow.c changed back to r222148) I get exact freq levels: dev.cpu.0.freq_levels: 2200/35000 2000/29000 1800/24000 1600/2 800/9000 That's better. :-) However, dev.cpu.0.freq OID is still missing from sysctl output. As another data point, with your new patch applied, but the old powernow.c, (which I booted into mistakenly first time), I did have dev.cpu.0.freq, but the freq levels weren't exact. Here is a new verbose boot output with a cleaned and built kernel, 8-STABLE as at time=1311028656 and your patch applied: http://members.optusnet.com.au/callumgibson/verboseboot2.out Can you please do set debug.cpufreq.verbose=1 from loader prompt and show me the dmesg output? I want to see intial settings. You can reset it from command line with sysctl debug.cpufreq.verbose=0 later. Thanks, Jung-uk Kim ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to freebsd-stable-unsubscr...@freebsd.org
Re: powernow regression in 8-STABLE
On Wednesday, July 20, 2011 10:28:19 pm Callum Gibson wrote: On 20Jul11 19:28, Jung-uk Kim wrote: }From your dmesg output, I see that the processor speed was not }calibrated properly. ML-40's max. core freq. is 2,200 MHz according }to its specification but it was probed at 2,282 MHz, which is too }high. I think that's the problem. Can you please try the attached }patch? Yes, I have seen core freq wobble around for most of the time I've owned it, but usually close to 2200. Possibly try disabling legacy USB in your BIOS as a test? -- John Baldwin ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to freebsd-stable-unsubscr...@freebsd.org
Re: powernow regression in 8-STABLE
On 21Jul11 12:07, Jung-uk Kim wrote: }Can you please do set debug.cpufreq.verbose=1 from loader prompt and }show me the dmesg output? I want to see intial settings. You can }reset it from command line with sysctl debug.cpufreq.verbose=0 }later. http://members.optusnet.com.au/callumgibson/boot_verboser.out Also, as suggested by jhb@, with legacy usb disabled: http://members.optusnet.com.au/callumgibson/boot_verboser_nousb.out and dev.cpu.0.freq reappears! Spooky. Is that a solution or a workaround? I noticed this disables usb keyboard support at the boot menus. C -- Callum Gibson @ home http://members.optusnet.com.au/callumgibson/ ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to freebsd-stable-unsubscr...@freebsd.org
Re: powernow regression in 8-STABLE
On Fri, Jul 22, 2011 at 06:56:00AM +1000, Callum Gibson wrote: On 21Jul11 12:07, Jung-uk Kim wrote: }Can you please do set debug.cpufreq.verbose=1 from loader prompt and }show me the dmesg output? I want to see intial settings. You can }reset it from command line with sysctl debug.cpufreq.verbose=0 }later. http://members.optusnet.com.au/callumgibson/boot_verboser.out Also, as suggested by jhb@, with legacy usb disabled: http://members.optusnet.com.au/callumgibson/boot_verboser_nousb.out and dev.cpu.0.freq reappears! Spooky. Is that a solution or a workaround? I noticed this disables usb keyboard support at the boot menus. Legacy USB support is a horribly-named BIOS option. What the option actually does, without getting into the technicalities, is make your USB keyboard work inside of environments where there is no USB driver. The most commonly-used examples are bootloader/bootstraps and MS-DOS. The BIOS itself (meaning the firmware/BIOS, not the BIOS as in a piece of legacy technology) has a tiny USB stack in it. That's how your USB keyboard is able to work (e.g. to press Del or F2 to get into the BIOS itself), and how you're able to boot from USB-attached devices. You should keep Legacy USB enabled if you want your keyboard to work in bootloaders/bootstraps. If enabling this feature breaks something else, that sounds like a bug in the vendor BIOS to me, and you should contact the vendor or motherboard manufacturer to inform them of the bug. -- | Jeremy Chadwickjdc at parodius.com | | Parodius Networking http://www.parodius.com/ | | UNIX Systems Administrator Mountain View, CA, US | | Making life hard for others since 1977. PGP 4BD6C0CB | ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to freebsd-stable-unsubscr...@freebsd.org
Re: powernow regression in 8-STABLE
On Thursday 21 July 2011 04:56 pm, Callum Gibson wrote:
On 21Jul11 12:07, Jung-uk Kim wrote:
}Can you please do set debug.cpufreq.verbose=1 from loader prompt
and }show me the dmesg output? I want to see intial settings. You
can }reset it from command line with sysctl
debug.cpufreq.verbose=0 }later.
http://members.optusnet.com.au/callumgibson/boot_verboser.out
Also, as suggested by jhb@, with legacy usb disabled:
http://members.optusnet.com.au/callumgibson/boot_verboser_nousb.out
and dev.cpu.0.freq reappears! Spooky. Is that a solution or a
workaround? I noticed this disables usb keyboard support at the
boot menus.
It is a workaround. Please try the attached patch.
Jung-uk Kim
Index: sys/kern/kern_cpu.c
===
--- sys/kern/kern_cpu.c (revision 224245)
+++ sys/kern/kern_cpu.c (working copy)
@@ -157,17 +157,18 @@ cpufreq_attach(device_t dev)
sysctl_ctx_init(sc-sysctl_ctx);
TAILQ_INIT(sc-all_levels);
CF_MTX_INIT(sc-lock);
- sc-curr_level.total_set.freq = CPUFREQ_VAL_UNKNOWN;
SLIST_INIT(sc-saved_freq);
/* Try to get nominal CPU freq to use it as maximum later if needed */
- sc-max_mhz = cpu_get_nominal_mhz(dev);
- /* If that fails, try to measure the current rate */
- if (sc-max_mhz = 0) {
- pc = cpu_get_pcpu(dev);
- if (cpu_est_clockrate(pc-pc_cpuid, rate) == 0)
- sc-max_mhz = rate / 100;
- else
- sc-max_mhz = CPUFREQ_VAL_UNKNOWN;
+ if (sc-max_mhz == CPUFREQ_VAL_UNKNOWN) {
+ sc-max_mhz = cpu_get_nominal_mhz(dev);
+ /* If that fails, try to measure the current rate */
+ if (sc-max_mhz = 0) {
+ pc = cpu_get_pcpu(dev);
+ if (cpu_est_clockrate(pc-pc_cpuid, rate) == 0)
+ sc-max_mhz = rate / 100;
+ else
+ sc-max_mhz = CPUFREQ_VAL_UNKNOWN;
+ }
}
/*
@@ -1000,8 +1001,11 @@ out:
int
cpufreq_register(device_t dev)
{
+ struct cf_setting set;
+ struct cf_setting *sets;
struct cpufreq_softc *sc;
device_t cf_dev, cpu_dev;
+ int error, freq, max, set_count, type;
/* Add a sysctl to get each driver's settings separately. */
SYSCTL_ADD_PROC(device_get_sysctl_ctx(dev),
@@ -1009,14 +1013,34 @@ cpufreq_register(device_t dev)
OID_AUTO, freq_settings, CTLTYPE_STRING | CTLFLAG_RD, dev, 0,
cpufreq_settings_sysctl, A, CPU frequency driver settings);
+ /* Get settings from the device and find current and maximum
frequencies */
+ freq = max = CPUFREQ_VAL_UNKNOWN;
+ if (CPUFREQ_DRV_TYPE(dev, type) == 0
+ (type CPUFREQ_TYPE_MASK) == CPUFREQ_TYPE_ABSOLUTE) {
+ if (CPUFREQ_DRV_GET(dev, set) == 0)
+ freq = set.freq;
+ set_count = MAX_SETTINGS;
+ sets = malloc(set_count * sizeof(*sets), M_TEMP, M_NOWAIT);
+ if (sets != NULL) {
+ if (CPUFREQ_DRV_SETTINGS(dev, sets, set_count) == 0
+ set_count 0)
+ max = sets[0].freq;
+ free(sets, M_TEMP);
+ }
+ }
+
/*
* Add only one cpufreq device to each CPU. Currently, all CPUs
* must offer the same levels and be switched at the same time.
*/
cpu_dev = device_get_parent(dev);
- if ((cf_dev = device_find_child(cpu_dev, cpufreq, -1))) {
+ cf_dev = device_find_child(cpu_dev, cpufreq, -1);
+ if (cf_dev != NULL) {
sc = device_get_softc(cf_dev);
- sc-max_mhz = CPUFREQ_VAL_UNKNOWN;
+ if (sc-curr_level.total_set.freq == CPUFREQ_VAL_UNKNOWN)
+ sc-curr_level.total_set.freq = freq;
+ if (sc-max_mhz == CPUFREQ_VAL_UNKNOWN)
+ sc-max_mhz = max;
return (0);
}
@@ -1025,8 +1049,13 @@ cpufreq_register(device_t dev)
if (cf_dev == NULL)
return (ENOMEM);
device_quiet(cf_dev);
-
- return (device_probe_and_attach(cf_dev));
+ error = device_probe(cf_dev);
+ if (error != 0)
+ return (error);
+ sc = device_get_softc(cf_dev);
+ sc-curr_level.total_set.freq = freq;
+ sc-max_mhz = max;
+ return (device_attach(cf_dev));
}
int
___
freebsd-stable@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-stable
To unsubscribe, send any mail to freebsd-stable-unsubscr...@freebsd.org
Re: powernow regression in 8-STABLE
On Tuesday 19 July 2011 07:20 am, Callum Gibson wrote:
Hi,
I've just noticed and tracked down a regression in
x86/cpufreq/powernow.c (on amd64) which was first mentioned here:
http://lists.freebsd.org/pipermail/freebsd-current/2011-March/02350
9.html
although no followup seems to have occurred.
The above thread is irrelevant. It was an Intel processor.
Symptoms are that powerd stops working because the dev.cpu.0.freq
OID is no longer gettable nor settable.
This seems to have been caused by the following revision:
http://svnweb.freebsd.org/base?view=revisionrevision=222148
which was in turn an MFC of r221102, so I guess the problem exists
on -current as well, although I can't confirm that since I don't
run it.
Reverting the change fixes the problem and powerd will work again.
Also other utilities, such as xacpim, work properly.
I'm running a ML-40 Turion laptop (HP Compaq nx6125).
From your dmesg output, I see that the processor speed was not
calibrated properly. ML-40's max. core freq. is 2,200 MHz according
to its specification but it was probed at 2,282 MHz, which is too
high. I think that's the problem. Can you please try the attached
patch?
Jung-uk Kim
Index: sys/kern/kern_cpu.c
===
--- sys/kern/kern_cpu.c (revision 224231)
+++ sys/kern/kern_cpu.c (working copy)
@@ -159,16 +159,21 @@ cpufreq_attach(device_t dev)
CF_MTX_INIT(sc-lock);
sc-curr_level.total_set.freq = CPUFREQ_VAL_UNKNOWN;
SLIST_INIT(sc-saved_freq);
- /* Try to get nominal CPU freq to use it as maximum later if needed */
- sc-max_mhz = cpu_get_nominal_mhz(dev);
- /* If that fails, try to measure the current rate */
- if (sc-max_mhz = 0) {
- pc = cpu_get_pcpu(dev);
- if (cpu_est_clockrate(pc-pc_cpuid, rate) == 0)
- sc-max_mhz = rate / 100;
- else
- sc-max_mhz = CPUFREQ_VAL_UNKNOWN;
+ if (sc-max_mhz == CPUFREQ_VAL_UNKNOWN) {
+ /* Try to get nominal CPU freq to use it as maximum later. */
+ sc-max_mhz = cpu_get_nominal_mhz(dev);
+ /* If that fails, try to measure the current rate */
+ if (sc-max_mhz = 0) {
+ pc = cpu_get_pcpu(dev);
+ if (cpu_est_clockrate(pc-pc_cpuid, rate) == 0)
+ sc-max_mhz = rate / 100;
+ else
+ sc-max_mhz = CPUFREQ_VAL_UNKNOWN;
+ }
}
+ if (sc-max_mhz == CPUFREQ_VAL_UNKNOWN)
+ CF_DEBUG(unknown max frequency for %s\n,
+ device_get_nameunit(dev));
/*
* Only initialize one set of sysctls for all CPUs. In the future,
@@ -1001,7 +1006,9 @@ int
cpufreq_register(device_t dev)
{
struct cpufreq_softc *sc;
+ struct cf_setting *sets;
device_t cf_dev, cpu_dev;
+ int error, max, set_count, type;
/* Add a sysctl to get each driver's settings separately. */
SYSCTL_ADD_PROC(device_get_sysctl_ctx(dev),
@@ -1009,14 +1016,29 @@ cpufreq_register(device_t dev)
OID_AUTO, freq_settings, CTLTYPE_STRING | CTLFLAG_RD, dev, 0,
cpufreq_settings_sysctl, A, CPU frequency driver settings);
+ /* Get settings from the device and find maximum if possible. */
+ max = CPUFREQ_VAL_UNKNOWN;
+ if (CPUFREQ_DRV_TYPE(dev, type) == 0
+ (type CPUFREQ_TYPE_MASK) == CPUFREQ_TYPE_ABSOLUTE) {
+ set_count = MAX_SETTINGS;
+ sets = malloc(set_count * sizeof(*sets), M_TEMP, M_NOWAIT);
+ if (sets != NULL) {
+ if (CPUFREQ_DRV_SETTINGS(dev, sets, set_count) == 0
+ set_count 0)
+ max = sets[0].freq;
+ free(sets, M_TEMP);
+ }
+ }
+
/*
* Add only one cpufreq device to each CPU. Currently, all CPUs
* must offer the same levels and be switched at the same time.
*/
cpu_dev = device_get_parent(dev);
- if ((cf_dev = device_find_child(cpu_dev, cpufreq, -1))) {
+ cf_dev = device_find_child(cpu_dev, cpufreq, -1);
+ if (cf_dev != NULL) {
sc = device_get_softc(cf_dev);
- sc-max_mhz = CPUFREQ_VAL_UNKNOWN;
+ sc-max_mhz = max;
return (0);
}
@@ -1025,8 +1047,12 @@ cpufreq_register(device_t dev)
if (cf_dev == NULL)
return (ENOMEM);
device_quiet(cf_dev);
-
- return (device_probe_and_attach(cf_dev));
+ error = device_probe(cf_dev);
+ if (error != 0)
+ return (error);
+ sc = device_get_softc(cf_dev);
+ sc-max_mhz = max;
+ return (device_attach(cf_dev));
}
int
___
Re: powernow regression in 8-STABLE
On 20Jul11 19:28, Jung-uk Kim wrote: }From your dmesg output, I see that the processor speed was not }calibrated properly. ML-40's max. core freq. is 2,200 MHz according }to its specification but it was probed at 2,282 MHz, which is too }high. I think that's the problem. Can you please try the attached }patch? Yes, I have seen core freq wobble around for most of the time I've owned it, but usually close to 2200. This morning (with my reverted powernow.c) I had: dev.cpu.0.freq_levels: 3080/35000 2800/29000 2520/24000 2240/2 1120/9000 which I don't believe I've seen before. Anyway... With your new patch applied (and powernow.c changed back to r222148) I get exact freq levels: dev.cpu.0.freq_levels: 2200/35000 2000/29000 1800/24000 1600/2 800/9000 However, dev.cpu.0.freq OID is still missing from sysctl output. As another data point, with your new patch applied, but the old powernow.c, (which I booted into mistakenly first time), I did have dev.cpu.0.freq, but the freq levels weren't exact. Here is a new verbose boot output with a cleaned and built kernel, 8-STABLE as at time=1311028656 and your patch applied: http://members.optusnet.com.au/callumgibson/verboseboot2.out regards, Callum -- Callum Gibson @ home http://members.optusnet.com.au/callumgibson/ ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to freebsd-stable-unsubscr...@freebsd.org
Re: powernow regression in 8-STABLE
On Tuesday 19 July 2011 07:20 am, Callum Gibson wrote: Hi, I've just noticed and tracked down a regression in x86/cpufreq/powernow.c (on amd64) which was first mentioned here: http://lists.freebsd.org/pipermail/freebsd-current/2011-March/02350 9.html although no followup seems to have occurred. Symptoms are that powerd stops working because the dev.cpu.0.freq OID is no longer gettable nor settable. This seems to have been caused by the following revision: http://svnweb.freebsd.org/base?view=revisionrevision=222148 which was in turn an MFC of r221102, so I guess the problem exists on -current as well, although I can't confirm that since I don't run it. Reverting the change fixes the problem and powerd will work again. Also other utilities, such as xacpim, work properly. I'm running a ML-40 Turion laptop (HP Compaq nx6125). HP again... Can you please show me verbose boot messages? Thanks, Jung-uk Kim ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to freebsd-stable-unsubscr...@freebsd.org
Re: powernow regression in 8-STABLE
On 19Jul11 12:04, Jung-uk Kim wrote: }On Tuesday 19 July 2011 07:20 am, Callum Gibson wrote: } I've just noticed and tracked down a regression in } x86/cpufreq/powernow.c (on amd64) which was first mentioned here: } } http://lists.freebsd.org/pipermail/freebsd-current/2011-March/02350 }9.html } } although no followup seems to have occurred. } } Symptoms are that powerd stops working because the dev.cpu.0.freq } OID is no longer gettable nor settable. }[snip] } }HP again... Can you please show me verbose boot messages? I've put them in http://members.optusnet.com.au/callumgibson/verboseboot.out for you. This is a boot (and shutdown) of the kernel which exhibits the problem (hence kernel.old in output). (On the plus side, this HP laptop now suspends and resumes properly after 5 years. Not sure when that started happening.) regards, Callum -- Callum Gibson @ home http://members.optusnet.com.au/callumgibson/ ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to freebsd-stable-unsubscr...@freebsd.org
