> That is not an SMP kernel. An SMP kernel (with APIC_IO) would not print
> out
> the pcib0 interrupt routing messages.
>
> --
So whats the problem here? How come the CPUs dont show up in top. How do i
realy know the system sees 2, and actually utilizes them? Is there
anything else i have to do o
>> That is not an SMP kernel. An SMP kernel (with APIC_IO) would not print
>> out
>> the pcib0 interrupt routing messages.
>>
>> --
>
> So whats the problem here? How come the CPUs dont show up in top. How do i
> realy know the system sees 2, and actually utilizes them? Is there
> anything else i
> On Fri, Aug 22, 2003 at 07:03:03PM -0400, [EMAIL PROTECTED] wrote:
>> > That is not an SMP kernel. An SMP kernel (with APIC_IO) would not
>> print
>> > out
>> > the pcib0 interrupt routing messages.
>> >
>> > --
>>
>> So whats the problem here?
>
> See above.
>> How come the CPUs dont show up in
> On Fri, Aug 22, 2003 at 10:23:52PM -0400, [EMAIL PROTECTED] wrote:
>
>> Well i've enabled all SMP options, recompiled and rebooted. The CPUs now
>> properly show up in dmesg and i can see the C header in top. However no
>> processes seem to be being assigned to cpu 1. Why is the schedueler only
>
- generic kernel.
--mikej
lock order reversal:
1st 0xfe0f9446ff28 bufwait (bufwait) @
/usr/src/sys/kern/vfs_bio.c:3081
2nd 0xf801c946a400 dirhash
(dirhash) @ /usr/src/sys/ufs/ufs/ufs_dirhash.c:284
KDB: stack
backtrace:
db_trace_self_wrapper() at db_trace_self_wrapper+0x2b/frame
On 2014-07-01 14:49, Warren Block wrote:
On Tue, 1 Jul 2014, Chris Ross wrote:
Looking at the man page for gpart(8) on a recent 10-stable system, I
was trying to find out what the -a option to list does. (shown in the
output of gpart when run with no parameters). Interestingly, despite
?
