| Nicolas Joly | Re: speedstepping on amd64 - why not?
It's already defined in `x86/include/cputypes.h', which is already
used on amd64 in identifycpu() function.
--
Nicolas Joly
Biological Software and Databanks.
Institut Pasteur, Paris.
| Apr 21, 2:11 pm 2007 |
| Juan RP | Re: speedstepping on amd64 - why not?
On Sat, 21 Apr 2007 19:01:58 +0200
p3_get_bus_clock is required for core duo and p4_get_bus_clock for Xeon
and Pentium 4. So you'll want to have both functions, because we might
support them in est in the future.
--
http://plog.xtrarom.org/
Juan RP's blog - NetBSD/pkgsrc news in Spanish
| Apr 21, 10:30 am 2007 |
| Tonnerre LOMBARD | speedstepping on amd64 - why not?
Salut,
Is there a specific reason why speedstepping is disabled on amd64? I
have a notebook which supports quite a lot of speed stepping, and I
would really like to be able to use it, so if there's a known wreckage,
I am willing to try to fix it (besides porting IBM ServeRaid and LSI
Logic SASCSI).
Tonnerre
| Apr 21, 9:33 am 2007 |
| Juan RP | Re: speedstepping on amd64 - why not?
On Sat, 21 Apr 2007 18:33:52 +0200
Do you mean speedstep for x86_64? if you are saying that, the following
steps must be done:
* Move p[34]_get_bus_clock() from i386/i386/identcpu.c into
x86/x86/intel_busclock.c (I used a single function merging p3 and p4).
* Move i386/i386/est.c into x86/x86.
* Update amd64/amd64/identcpu.c to run est_init().
* Update some required files like x86/conf/files.x86, etc.
* Update {amd64,i386}/conf/files.{amd64,i386}.
I had this done weeks ago... but I ...
| Apr 21, 9:43 am 2007 |
| Tonnerre LOMBARD | Re: speedstepping on amd64 - why not?
Salut,
There appears to be a problem with the fact that nothing in amd64 defines
CPUVENDOR_INTEL. Would it be appropriate to copy the definition from i386?
I'm not that much into the amd64 port yet...
Tonnerre
| Apr 21, 10:55 am 2007 |
| Tonnerre LOMBARD | Re: speedstepping on amd64 - why not?
Salut,
I got it to work somewhat on 4.0_BETA2 with a couple of quirks. However,
contrary to FreeBSD, NetBSD only sees 2 frequencies because, as it seems,
it does not recognize the CPU. In the dmesg it says:
cpu0: Enhanced SpeedStep (1324 mV) 2000 MHz
cpu0: unknown Enhanced SpeedStep CPU (0:16667:3111:1555).
cpu0: using only highest and lowest power states.
cpu0: Enhanced SpeedStep frequencies available (MHz): 2000 1000
However, I'm not sure what I should register in est.c as the ...
| Apr 21, 6:57 pm 2007 |
| Tonnerre LOMBARD |
| Apr 21, 10:01 am 2007 |
| Andrew Doran | Re: SCHED_LOCK(9)?
Hi Oliver,
Yup, with l->l_usrpri replaced with MAXPRI. The call to issignal() needs the
process' signal state locked. For now issignal() also needs the kernel_lock
held as it may free memory. If you're sure that keqmu_schedule() will only
ever be called with the kernel_lock held then the following will work:
KERNEL_LOCK(l->l_biglocks, l);
mutex_enter(&p->p_smutex);
sig = issignal(l);
mutex_exit(&p->p_smutex);
return sig != 0;
I'm curious what it uses the return value for, but ...
| Apr 21, 6:01 am 2007 |
| YAMAMOTO Takashi |
| Apr 21, 5:25 am 2007 |
| Juan RP | Re: envsys version 2 API
On Sat, 21 Apr 2007 21:25:39 +0900 (JST)
I don't know yet... is not ok to bump __NetBSD_Version__ and make
it incompatible with drivers using envsys 1?
IMHO make it compatible it's too much work.
--
http://plog.xtrarom.org/
Juan RP's blog - NetBSD/pkgsrc news in Spanish
| Apr 21, 9:48 am 2007 |
| Juergen Hannken-Illjes | Re: bloated code paths in ufs_lock/unlock
fstrans_is_owner() is not that expensive as the list in question is
usually short, one element per mount this thread is using.
Anyway, the attached diff speeds up `stat("/a/a/a", &sbuf)' by ~5%.
Comments?
--
Juergen Hannken-Illjes - hannken@eis.cs.tu-bs.de - TU Braunschweig (Germany)
| Apr 21, 8:54 am 2007 |
| Manuel Bouyer | Re: port bio(4) and bioctl(8) from openbsd ?
Here's my latest patch about this.
I've an issue with lock usage in bio(4):
there is a bio_lock, which is a kmutex_t to protect the internal structures
of bio(4). A disk driver (for example mfi(4)) will also have its own
lock to protect its structure; and will probably call bio_register()
and bio_unregister() with this lock held.
The callback from bio(4) to mfi(4) shall be called with bio_lock held, to
avoid having the entry removed from under its feets (it's not the
case right now, but as ...
| Apr 21, 6:48 am 2007 |
| Manuel Bouyer | Re: port bio(4) and bioctl(8) from openbsd ?
Well, I looked at this closer, and it's not easy (at last not for mfi nor
amr). The interface proposed by both controllers is hierarchical, and
physical drives appear under logical drives. It doesn't fit our sysmon
model where everything is flat. Againt at this point we just want to know
that something did go wrong in a logical drive; for details the operator can
use the bioctl interface.
--
Manuel Bouyer <bouyer@antioche.eu.org>
NetBSD: 26 ans d'experience feront toujours la ...
| Apr 21, 6:50 am 2007 |
