On Fri, Aug 20, 2010 at 5:17 AM, b. f. 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 situation h
Ed Schouten writes:
> Hello Michael,
>
> * Michael Sperber 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 a more appropriate
>> forum.
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 Fr
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 func
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 pu
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 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 (w
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 stac
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 'in
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 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
> building
Atom Smasher 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 fails,
14 matches
Mail list logo
