Kostik Belousov wrote:
On Sat, May 17, 2008 at 06:26:01PM +0100, Rui Paulo wrote:
Andriy Gapon wrote:
on 17/05/2008 18:37 Rui Paulo said the following:
Andriy Gapon wrote:
It seems that rdmsr instruction can be executed only at the highest
privilege level and thus is not permitted from
Mike Meyer wrote:
On Sat, 17 May 2008 11:13:52 +0300
Andriy Gapon [EMAIL PROTECTED] wrote:
It seems that rdmsr instruction can be executed only at the highest
privilege level and thus is not permitted from userland. Maybe we should
provide something like Linux /dev/cpu/msr?
I don't like
On Sun, 18 May 2008 16:50:28 +0100
Rui Paulo [EMAIL PROTECTED] wrote:
Mike Meyer wrote:
On Sat, 17 May 2008 11:13:52 +0300
Andriy Gapon [EMAIL PROTECTED] wrote:
It seems that rdmsr instruction can be executed only at the highest
privilege level and thus is not permitted from userland.
On Sun, May 18, 2008 at 04:47:41PM +0100, Rui Paulo wrote:
Kostik Belousov wrote:
On Sat, May 17, 2008 at 06:26:01PM +0100, Rui Paulo wrote:
Andriy Gapon wrote:
on 17/05/2008 18:37 Rui Paulo said the following:
Andriy Gapon wrote:
It seems that rdmsr instruction can be executed only at the
On Sun, May 18, 2008 at 07:09:36PM +0200, Ulrich Spoerlein wrote:
...
I find this functionality very useful, but the addition of another flag
as problematic. First of all, old releases don't have it. Secondly, the
behaviour you describe should be the default anyway (IMHO).
Thank you for your
On Mon, 12.05.2008 at 13:09:01 -0700, David Wolfskill wrote:
In my case, I believe it would be useful to provide an ability to tell
sysctl(8) to report on everything asked for that it does know, and
ignore the OIDs it doesn't know.
Is this percpetion so radical that I'm way off base? If so,
Kostik Belousov wrote:
On Sun, May 18, 2008 at 04:47:41PM +0100, Rui Paulo wrote:
Kostik Belousov wrote:
On Sat, May 17, 2008 at 06:26:01PM +0100, Rui Paulo wrote:
Andriy Gapon wrote:
on 17/05/2008 18:37 Rui Paulo said the following:
Andriy Gapon wrote:
It seems that rdmsr instruction can
Mike Meyer wrote:
On Sun, 18 May 2008 16:50:28 +0100
Rui Paulo [EMAIL PROTECTED] wrote:
Mike Meyer wrote:
On Sat, 17 May 2008 11:13:52 +0300
Andriy Gapon [EMAIL PROTECTED] wrote:
It seems that rdmsr instruction can be executed only at the highest
privilege level and thus is not permitted
On Sun, 18 May 2008 19:35:44 +0100
Rui Paulo [EMAIL PROTECTED] wrote:
Mike Meyer wrote:
On Sun, 18 May 2008 16:50:28 +0100
Rui Paulo [EMAIL PROTECTED] wrote:
Mike Meyer wrote:
On Sat, 17 May 2008 11:13:52 +0300
Andriy Gapon [EMAIL PROTECTED] wrote:
It seems that rdmsr instruction
On Sun, 18 May 2008 19:35:44 +0100
Rui Paulo [EMAIL PROTECTED] wrote:
Mike Meyer wrote:
On Sun, 18 May 2008 16:50:28 +0100
Rui Paulo [EMAIL PROTECTED] wrote:
Mike Meyer wrote:
On Sat, 17 May 2008 11:13:52 +0300
Andriy Gapon [EMAIL PROTECTED] wrote:
It seems that rdmsr instruction
On May 18, 2008, at 11:15 AM, Kostik Belousov wrote:
On Sun, May 18, 2008 at 04:47:41PM +0100, Rui Paulo wrote:
Kostik Belousov wrote:
On Sat, May 17, 2008 at 06:26:01PM +0100, Rui Paulo wrote:
Andriy Gapon wrote:
on 17/05/2008 18:37 Rui Paulo said the following:
Andriy Gapon wrote:
It
sendmsg is not documented as ever returning EINVAL but yet when
using the following code to send credentials to a remote host
results in EINVAL from sendmsg.
I suspect that SCM_CREDS is only valid for PF_LOCAL / PF_UNIX
sockets and not PF_INET sockets and hence the code in dbus
is actually
Mike Meyer wrote:
I don't think that would work - you'd have to register all those
hexadecimal strings as sysctl names.
Yes, in theory you could also hack sysctl in a way that it doesn't walk
when you do a sysctl -a, but works fine when you issue sysctl
dev.cpu.N.0xffaabbcc, for example.
I
on 18/05/2008 21:32 Rui Paulo said the following:
Yes, but I still don't like having everything mixed up in one driver. At
the very least, I would like us to have two drivers. One for the
microcode update and the other driver for the rest.
I would like to see a microcode update utility
Hi,all
I have installed Freebsd 7.0 on my Acer TravelMate 220,my router ip is
192.168.0.1,the ip of my Freebsd is 192.168.1.4,Net Mask is 255.255.0.0,Why my
system can not connect wiht the router?
any idea?
___
freebsd-hackers@freebsd.org
15 matches
Mail list logo