< said:
> Is using xconsole significantly better than "tail -f /var/log/messages"?
I don't know. I think `xterm -C' is better than either one, if it can
be made to work properly. (I have held off on updating to latest
-current in the hope that this might be resolved one way or the
other.)
-GA
On Sun, 30 Sep 2001, Doug Barton wrote:
> With -current as of last night around 7pm PDT:
>
>
> IdlePTD 4390912
> initial pcb at 320920
> panicstr: bremfree: bp 0xc68bf184 not locked
> panic messages:
> ---
> panic: blockable sleep lock (sx) allproc @
> /usr/
With -current as of last night around 7pm PDT:
IdlePTD 4390912
initial pcb at 320920
panicstr: bremfree: bp 0xc68bf184 not locked
panic messages:
---
panic: blockable sleep lock (sx) allproc @
/usr/local/src/sys/kern/kern_proc.c:212
syncing disks... panic: bremfree: bp 0xc68bf184 not
On 30-Sep-01 Marcel Moolenaar wrote:
> On Sat, Sep 29, 2001 at 12:52:48PM -0700, John Baldwin wrote:
>>
>> could figure out the faulting address that it trapp'd one that would help.
>> You
>> could add KTR tracepoints or some such to store the log message to do that
>> and
>> then examin the KT
On Sat, Sep 29, 2001 at 12:52:48PM -0700, John Baldwin wrote:
>
> could figure out the faulting address that it trapp'd one that would help. You
> could add KTR tracepoints or some such to store the log message to do that and
> then examin the KTR buffer to get the actual faulting address.
Ok.
On Sat, Sep 29, 2001 at 12:52:48PM -0700, John Baldwin wrote:
>
> Can you do 'show locks' at the ddb prompt to get a list of what locks are held?
db> show locks
exclusive (sleep mutex) Giant (0xc0343ae0) locked @
/nfs/5.x/src/sys/kern/kern_timeout.c:186
exclusive (spin mutex) sched lock (0xc034
On Sat, Sep 29, 2001 at 12:52:48PM -0700, John Baldwin wrote:
>
> On 29-Sep-01 Marcel Moolenaar wrote:
> > Gang,
> >
> > I was running the Linux Test Project's (ltp) regression suite to see
> > how our Linuxulator was doing. It looks like we can use that to test
> > our kernel as well. :-)\
>
>
ress that it trapp'd one that would help. You
could add KTR tracepoints or some such to store the log message to do that and
then examin the KTR buffer to get the actual faulting address.
> panicstr: bremfree: bp 0xc69541a8 not locked
> panic messages:
> ---
> panic: blockable slee
Gang,
I was running the Linux Test Project's (ltp) regression suite to see
how our Linuxulator was doing. It looks like we can use that to test
our kernel as well. :-)
IdlePTD 4292608
initial pcb at 3077c0
panicstr: bremfree: bp 0xc69541a8 not locked
panic messages:
---
panic: blockable
