El día Thursday, October 04, 2018 a las 01:14:55PM +0930, Shane Ambler escribió:
> > How can I enter the jail interactively in the moment after the crash to
> > rerun and
> > debug pkg-static?
>
> Using
>
> poudriere testport -j -p -i -o
>
> will drop you into the jail after the build stops
On 3/10/18 9:11 pm, Matthias Apitz wrote:
>
> Hello,
>
>
> I'm trying to nail down PR 231532 of a port which fails to build in
> poudriere. In the last phase of the ports build, while creating the pkg
> of the built port with pkg-static, this crashes:
>
> # tail
> /usr/local/poudriere/data/log
El día miércoles, octubre 03, 2018 a las 11:06:55p. m. +0200, Tobias C. Berner
escribió:
> Moin moin
>
> Unfortunately it is very hard to help here when not being able to reproduce
> the issue :/
> Have you tried wiping all the packages in poudriere's repo? -- i.e. -c --
> maybe you're pkg packa
Moin moin
Unfortunately it is very hard to help here when not being able to reproduce
the issue :/
Have you tried wiping all the packages in poudriere's repo? -- i.e. -c --
maybe you're pkg package is just hosed.
mfg Tobias
On Wed, 3 Oct 2018 at 22:30, Matthias Apitz wrote:
>
> I added the fo
I added the following lines to /usr/local/share/poudriere/bulk.sh to get
the env vars into the environment of pkg(8):
export DEBUG_LEVEL=4
export DEBUG_SCRIPTS=TRUE
export DEVELOPER_MODE=TRUE
export PKG_CREATE_VERBOSE=TRUE
With these the port builds fine:
# tail -f
/usr/local/poudriere/data/lo
El día miércoles, octubre 03, 2018 a las 01:41:14p. m. +0200, Matthias Apitz
escribió:
>
> Hello,
>
>
> I'm trying to nail down PR 231532 of a port which fails to build in
> poudriere. In the last phase of the ports build, while creating the pkg
> of the built port with pkg-static, this crashe
On 03/20/17 14:14, Matthias Apitz wrote:
Hello,
I have a very recent 12-CURRENT on amd64 (r314251) with all ports from beginning
of March.
While testing multimedia/webcamd in debug mode it says:
# /usr/local/sbin/webcamd -i 0 -d ugen0.2 -U webcamd -G webcamd -H
: USB HID core driver
Linux vid
On 10/24/14 10:21, Hans Petter Selasky wrote:
Hi,
I need some help debugging an mbuf leak in the network stack. Anyone
available on IRC?
--HPS
FYI:
https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=194577
--HPS
___
freebsd-current@freebsd.org mai
On Mon, Aug 1, 2011 at 8:01 PM, Jos Backus wrote:
> Hi,
>
> I was wondering if any progress has been made regarding debugging of system
> lockups that occur while running X? My system (tracking -current, updated
> every few days) has been locking up reliably every day or so for a few months
> n
В вт, 07.10.2003, в 04:24, Kris Kennaway пишет:
> > Debugging CURRENT kernels using remote gdb on STABLE does not work ?
>
> That's probably to be expected - trying to debug a 5.x crashdump with
> 4.x's gdb also doesn't work, because gdb needs to know details of the
> kernel which are not the sam
On Mon, Oct 06, 2003 at 10:34:50PM +0400, Vladimir B. Grebenschikov wrote:
>
> Hi
>
> Debugging CURRENT kernels using remote gdb on STABLE does not work ?
That's probably to be expected - trying to debug a 5.x crashdump with
4.x's gdb also doesn't work, because gdb needs to know details of the
k
On Fri, 18 Jul 2003, David Hill wrote:
> cu -l /dev/cuaa0 completely locks up my machine...
> How can I debug this?
David,
As usual, update your sources, enable all of the debugging options in your
kernel config file, including DDB. Compile a kernel and ensure that you
have an up-to-date world
> cool.
> What are the instructions for using this?
> should something have sio1 open?
I use conserver
conserver conserver hostnull-modem serial cables test machine
label
testport AA - sio0 serial console
testnmi port BB
[EMAIL PROTECTED] wrote:
>
> > Again I'll offer to run any and all code or patches to -current you
> > guys can come up with, but I simply dont have the time to sit down
> > and analyze into details what you have been doing...
>
> The enclosed patch implements a virtual NMI pushbutton by program
[EMAIL PROTECTED] wrote:
>
> The enclosed patch implements a virtual NMI pushbutton by programming
> the IOAPIC to deliver an NMI when sio1 generates an interrupt.
This would be a nice kernel option... :-)
--
Daniel C. Sobral(8-DCS)
[EMAIL PROTECTED]
[EMAIL PROTECTED]
[
> Again I'll offer to run any and all code or patches to -current you
> guys can come up with, but I simply dont have the time to sit down
> and analyze into details what you have been doing...
The enclosed patch implements a virtual NMI pushbutton by programming
the IOAPIC to deliver an NMI when
:I did some research on this and am convinced that at least some video cards
:would work as memory buffers for KTR logs. Specifically, someone mentioned
:to me yesterday that their Matrox Millennium II flashes the X desktop
:during startup from a previous invocation across warm boots. (I pursued
It seems Jason Evans wrote:
> On Wed, Jan 17, 2001 at 07:42:26PM +0100, Soren Schmidt wrote:
> > > Basically if you're expecting me or the SMP team to figure out
> > > what's going on without more info, you're pretty much out of luck.
> >
> > See above, not really possible, we have been trying to
On Sun, Jan 07, 2001 at 03:09:40PM -0500, Justin/Mike Ovens wrote:
> I compiled my kernel with Debuggin symols.. how do i debug the running kernel?
gdb -k /kernel.debug /dev/mem
> and can i make it log the info to a file?
Log what into a file? Syslog can log the messages the kernel produces
int
Hi,
On Tue, 19 Sep 2000 [EMAIL PROTECTED] wrote:
...
> This looks like you've hit the limit for the FFS node memory type.
BINGO!
>FFS node262144 65536K 65536K 65536K 20244600 6 256
So the symptom is clear. But the cause?
With pre SMPng I had the default kmem sizes (which is 12MB
On Tue, 19 Sep 2000 [EMAIL PROTECTED] wrote:
...
> This looks like you've hit the limit for the FFS node memory type.
>
> vmstat -m will indicate if this is correct.
>
...
> Increasing the kmem_map size (by setting a loader variable
> (kern.vm.kmem.size) or defining VM_KMEM_SIZE and VM_KMEM_SIZE
> (kgdb) ps
> pidprocaddruid pri ppid pgrp flag stat comm wchan
>37 c7874a00 c96650000 32 636 004086 3 tar piperd c9663f20
>36 c7874bc0 c960a0000 32 636 004006 3 tar FFS node
>c02f4220
This looks like you've hit
On Sun, 17 Sep 2000, John Baldwin wrote:
...
> Hmm, could it be lockmgr() related?
How can I proof?
Bye!
Michael Reifenberger
^.*Plaut.*$, IT, R/3 Basis, GPS
To Unsubscribe: send mail to [EMAIL PROTECTED]
with "unsubscribe freebsd-current" in the body of the message
Greg Lehey wrote:
> On Monday, 18 September 2000 at 1:29:34 +0200, Michael Reifenberger wrote:
> > On Mon, 18 Sep 2000, Greg Lehey wrote:
> > ...
> >> Oops, that's what comes of typing hurriedly early in the morning.
> >>
> >> p ((struct proc *)gd_curproc)->p_comm
> >> p ((struct proc *)gd_cu
On Monday, 18 September 2000 at 1:29:34 +0200, Michael Reifenberger wrote:
> On Mon, 18 Sep 2000, Greg Lehey wrote:
> ...
>> Oops, that's what comes of typing hurriedly early in the morning.
>>
>> p ((struct proc *)gd_curproc)->p_comm
>> p ((struct proc *)gd_curproc)->p_pid
> Works better:
>
On Mon, 18 Sep 2000, Greg Lehey wrote:
...
> Oops, that's what comes of typing hurriedly early in the morning.
>
> p ((struct proc *)gd_curproc)->p_comm
> p ((struct proc *)gd_curproc)->p_pid
Works better:
(kgdb) p ((struct proc *)gd_curproc)->p_comm
$6 = "irq1: atkbd0\000\000\000\000"
(kgdb)
On Monday, 18 September 2000 at 1:23:30 +0200, Michael Reifenberger wrote:
> On Mon, 18 Sep 2000, Greg Lehey wrote:
> ...
>> You could also show the content of p->p_pid. If you don't have a p
>> pointer in the frame you're looking at, use ((struct
>> *proc)gd_curproc)->p_pid and ((struct *proc)g
On Mon, 18 Sep 2000, Greg Lehey wrote:
...
> You could also show the content of p->p_pid. If you don't have a p
> pointer in the frame you're looking at, use ((struct
> *proc)gd_curproc)->p_pid and ((struct *proc)gd_curproc)->p_comm. We
> need to know what is hanging.
Sorry doesn't seem to work:
On Sunday, 17 September 2000 at 16:29:41 +0200, Michael Reifenberger wrote:
> Hi,
> ...
>> The frames above are what the system went to as the result of your
>> debugger request. I'd also be interested to see the output of the
>> 'icnt' macro (if this is UP machine) or 'icnt1' (if it's SMP), and
Hi,
if the order of the ps macro is correct, here the backtraces of the procs 35,36,37:
Copyright (c) 1992-2000 The FreeBSD Project.
Copyright (c) 1979, 1980, 1983, 1986, 1988, 1989, 1991, 1992, 1993, 1994
The Regents of the University of California. All rights reserved.
FreeBSD 5.0-CURRE
Hi,
...
> The frames above are what the system went to as the result of your
> debugger request. I'd also be interested to see the output of the
> 'icnt' macro (if this is UP machine) or 'icnt1' (if it's SMP), and
> 'ps' (the macro I promised above).
(kgdb) icnt
1215544*566*0 0*
On Sunday, 17 September 2000 at 0:32:01 +0200, Michael Reifenberger wrote:
> Hi,
> -current hangs reliable (as described in another mail) for me.
> For short:
> "tar cf /dev/null /usr/ports&; tar cf - /usr/ports | tar tf -"
> locks the system solid after a few minutes.
> The first tar itsel
On Wed, 12 May 1999, John Birrell wrote:
> Doug Rabson wrote:
> > I think the only state which I need to know about is PS_DEAD. If we marked
> > dead threads in the public struct it might simplify things.
>
> You use PS_RUNNING too. We could just tie down those two as PS_DEAD = 0
> and PS_RUNNING
On Wed, 12 May 1999, Daniel Eischen wrote:
> John Birrell wrote:
> > Daniel Eischen wrote:
> > > Why don't we make a libc_r_db and provide the necessary interfaces to
> > > gdb from that instead of having gdb know about uthread internals?
> >
> > It would still mean that gdb would be linked to the
John Birrell wrote:
> Daniel Eischen wrote:
> > Why don't we make a libc_r_db and provide the necessary interfaces to
> > gdb from that instead of having gdb know about uthread internals?
>
> It would still mean that gdb would be linked to the uthread internals
> which may not match the version of
Daniel Eischen wrote:
> Why don't we make a libc_r_db and provide the necessary interfaces to
> gdb from that instead of having gdb know about uthread internals?
It would still mean that gdb would be linked to the uthread internals
which may not match the version of libc_r that the 3rd party progr
John Birrell wrote:
> Doug Rabson wrote:
> > Other gdb thread debugging systems tend to export a set of variables from
> > the thread library which describe the important offsets in the thread
> > structure e.g. _debug_pthread_status_offset, _debug_pthread_foo_offset
> > etc.
>
> > If you think the
Doug Rabson wrote:
> I think the only state which I need to know about is PS_DEAD. If we marked
> dead threads in the public struct it might simplify things.
You use PS_RUNNING too. We could just tie down those two as PS_DEAD = 0
and PS_RUNNING = 1.
--
John Birrell - j...@cimlogic.com.au; j...@f
On Wed, 12 May 1999, John Birrell wrote:
> Doug Rabson wrote:
> > Ok, I'll see about updating my patch along these lines and I'll post up
> > another one in a day or two.
>
> One more thing... the states are subject to change, probably with new
> states being added. It is important to check that
Doug Rabson wrote:
> Ok, I'll see about updating my patch along these lines and I'll post up
> another one in a day or two.
One more thing... the states are subject to change, probably with new
states being added. It is important to check that the state number is
within the range that gdb was comp
On Wed, 12 May 1999, John Birrell wrote:
> Doug Rabson wrote:
> > That would work. I think I only need uniqueid, sig_saved,
> > saved_sigcontext, saved_jmpbuf, state and nxt. If those guys were lumped
> > up at the start of struct pthread (possibly in another struct so that gdb
> > doesn't need to
Doug Rabson wrote:
> That would work. I think I only need uniqueid, sig_saved,
> saved_sigcontext, saved_jmpbuf, state and nxt. If those guys were lumped
> up at the start of struct pthread (possibly in another struct so that gdb
> doesn't need to know sizeof(struct pthread)) and marked appropriate
On Wed, 12 May 1999, John Birrell wrote:
> Doug Rabson wrote:
> > Other gdb thread debugging systems tend to export a set of variables from
> > the thread library which describe the important offsets in the thread
> > structure e.g. _debug_pthread_status_offset, _debug_pthread_foo_offset
> > etc.
Doug Rabson wrote:
> Other gdb thread debugging systems tend to export a set of variables from
> the thread library which describe the important offsets in the thread
> structure e.g. _debug_pthread_status_offset, _debug_pthread_foo_offset
> etc.
>
> If you think there will be a real problem, I co
On Wed, 12 May 1999, John Birrell wrote:
> Doug Rabson wrote:
> > I didn't want to use the address since it might cause confusion if a
> > thread was freed and then the memory was re-allocated to create a new
> > thread.
>
> Good reason.
>
> > I thought about the versioning but I don't think it
Doug Rabson wrote:
> I didn't want to use the address since it might cause confusion if a
> thread was freed and then the memory was re-allocated to create a new
> thread.
Good reason.
> I thought about the versioning but I don't think it will be a problem in
> practice since both uthread and gdb
On Wed, 12 May 1999, John Birrell wrote:
> Doug Rabson wrote:
> > I've put an initial version of my hack for debugging FreeBSD user threads
> > with gdb up on http://www.freebsd.org/~dfr/uthread.diff. Comments would be
> > appreciated.
>
> Is the uniqueid really necessary when the address of the
Doug Rabson wrote:
> I've put an initial version of my hack for debugging FreeBSD user threads
> with gdb up on http://www.freebsd.org/~dfr/uthread.diff. Comments would be
> appreciated.
Is the uniqueid really necessary when the address of the thread structure
is already unique within the process
On Fri, 7 May 1999, Matthew Dillon wrote:
> :> :--- uthread_create.c 1999/03/23 05:07:55 1.12
> :> :+++ uthread_create.c 1999/05/06 15:27:33
> :> :@@ -42,6 +42,8 @@
> :> : #include "pthread_private.h"
> :> : #include "libc_private.h"
> :> :
> :> :+static int next_tid = 1;
> :> :+
>
:> :--- uthread_create.c1999/03/23 05:07:55 1.12
:> :+++ uthread_create.c1999/05/06 15:27:33
:> :@@ -42,6 +42,8 @@
:> : #include "pthread_private.h"
:> : #include "libc_private.h"
:> :
:> :+static int next_tid = 1;
:> :+
:> : int
:> : pthread_create(pthread_t * thread, const pt
On Fri, 7 May 1999, Matthew Dillon wrote:
> :--- uthread_create.c 1999/03/23 05:07:55 1.12
> :+++ uthread_create.c 1999/05/06 15:27:33
> :@@ -42,6 +42,8 @@
> : #include "pthread_private.h"
> : #include "libc_private.h"
> :
> :+static int next_tid = 1;
> :+
> : int
> : pthread_create(pthread_t
Matthew Dillon once wrote:
> Hmmm. tid is only an int and some programs which create and destroy
> threads a lot are almost certainly going to overflow it. 4 billion
> is not hard to reach. This can result in duplicate tid's.
Unsigned will double that. Not enough either?
:--- uthread_create.c 1999/03/23 05:07:55 1.12
:+++ uthread_create.c 1999/05/06 15:27:33
:@@ -42,6 +42,8 @@
: #include "pthread_private.h"
: #include "libc_private.h"
:
:+static int next_tid = 1;
:+
: int
: pthread_create(pthread_t * thread, const pthread_attr_t * attr,
: void
53 matches
Mail list logo
