On Fri, Aug 20, 2010 at 5:17 AM, b. f. bf1...@googlemail.com wrote:
To further confuse matters there appears to be a common misconception on
the web
that the cmos time is automatically synced to system time on FreeBSD. This
is
incorrect: see msg03414 on freebsd-hardware at freebsd.org.
The
Ed Schouten e...@80386.nl writes:
Hello Michael,
* Michael Sperber sper...@deinprogramm.de wrote:
I'm one of the maintainers of XEmacs, and I've been running into a
persistent problem with subprocesses / ptys since at least 5.x. (If this
is not the right list, I'd appreciate a pointer to
I am currently trying to port a program from Linux to FreeBSD which
detects how much processor time a process is using. The native Linux
code does this (in part) by reading the number of jiffies a given
process uses. This info is pulled from the /proc/PID/stat file.
One function is failing on
Jesse Smith wrote:
I am currently trying to port a program from Linux to FreeBSD which
detects how much processor time a process is using. The native Linux
code does this (in part) by reading the number of jiffies a given
process uses. This info is pulled from the /proc/PID/stat file.
One
Hi,
Currently the code in identcpu.c does a check for a specific cpu
value extension. This is set to 0x8004 (even though the
corresponding code below iterates through 0x8002:0x8005):
/* Check for extended CPUID information and a processor name. */
if (cpu_exthigh =
On Friday, August 20, 2010 9:14:23 am Jesse Smith wrote:
I am currently trying to port a program from Linux to FreeBSD which
detects how much processor time a process is using. The native Linux
code does this (in part) by reading the number of jiffies a given
process uses. This info is pulled
Consider the following modules:
/* first.c */
static int *test;
int
test_function(void)
{
return *test;
}
static int
first_modevent(struct module *m, int what, void *arg)
{
int err = 0;
switch (what) {
case MOD_LOAD:/* kldload */
test
On Fri, Aug 20, 2010 at 10:13 AM, Ryan Stone ryst...@gmail.com wrote:
Consider the following modules:
/* first.c */
static int *test;
int
test_function(void)
{
return *test;
}
static int
first_modevent(struct module *m, int what, void *arg)
{
int err = 0;
switch
Can someone help me understand how it is safe to process network packets from
within a driver's interrupt context?
It looks to me like the network drivers (bce in particular) violate the rules
laid out in locking (9).
In FreeBSD 7.3 the bce driver's RX interrupt can call up into the network
I don't know the details of the bce driver, but presumably the
interrupt handling is happening in the context of a software interrupt
thread, where it is safe to take mutexes and rwlocks.
You are only in interrupt context in a fast interrupt handler.
On 8/20/10 2:15 PM, John Giacomoni wrote:
Can someone help me understand how it is safe to process network packets from
within a driver's interrupt context?
It looks to me like the network drivers (bce in particular) violate the rules
laid out in locking (9).
The trick is that most of the
hardware:
MACH: x86_64 (LENOVO, 4313CTO, ThinkPad T510)
CPU: x86_64 (Intel(R) Core(TM) i5 CPU M 540 @ 2.53GHz)
FreeBSD 8.1-RELEASE #0 (amd64)
in /etc/make.conf i tried setting CPUTYPE=core but as soon as i start
building things, lang/perl5.10 fails, complaining about core not being
On Fri, Aug 20, 2010 at 5:19 PM, Atom Smasher a...@smasher.org wrote:
hardware:
MACH: x86_64 (LENOVO, 4313CTO, ThinkPad T510)
CPU: x86_64 (Intel(R) Core(TM) i5 CPU M 540 @ 2.53GHz)
FreeBSD 8.1-RELEASE #0 (amd64)
in /etc/make.conf i tried setting CPUTYPE=core but as soon as i start
Atom Smasher a...@smasher.org writes:
hardware:
MACH: x86_64 (LENOVO, 4313CTO, ThinkPad T510)
CPU: x86_64 (Intel(R) Core(TM) i5 CPU M 540 @ 2.53GHz)
FreeBSD 8.1-RELEASE #0 (amd64)
in /etc/make.conf i tried setting CPUTYPE=core but as soon as i
start building things, lang/perl5.10
14 matches
Mail list logo
