> Looking at the sendsig label in sys_process.c:kern_ptrace() makes it clear
> what's happening - in your testing the process was already stopped so
> the code sets td_xsig to SIGSTOP and wakes it up to send it the signal.
>
> But td_xsig doesn't seem to be used anywhere to set pending signals. Ma
On Mon, May 10, 2010 at 03:52:07PM -0700, David Wolfskill wrote:
> On Mon, May 10, 2010 at 03:39:11PM -0700, K. Macy wrote:
> > Are you not able to dump core?
> >
>
> Here's the crash summary; I can put the dump on my Web server on request.
> (It weighs in at 89MB.)
>
Compression reduce
Are you not able to dump core?
Thanks,
Kip
On Mon, May 10, 2010 at 3:08 PM, David Wolfskill wrote:
> On Mon, May 10, 2010 at 02:32:14PM -0700, K. Macy wrote:
>> Could you please try with 207902?
>> ...
>
> First, thanks for the response.
>
> OK; I grabbed r207902 & applied it (via "patch -p1"),
On Mon, May 10, 2010 at 02:32:14PM -0700, K. Macy wrote:
> Could you please try with 207902?
> ...
First, thanks for the response.
OK; I grabbed r207902 & applied it (via "patch -p1"), then rebuilt the
kernel & rebooted; here's the panic now:
3 Select option, [Enter] for default 3
3 or [
Weongyo Jeong wrote:
> > Do you want me to test anything else ?
>
> OK. The patch is ready to test. Could you please test it with attached
> patch?
No panic this time. I also don't get these messages any more:
May 10 23:25:36 mini kernel: bwn0: unsupported rate 0
May 10 23:26:13 mini last m
On Mon, May 10, 2010 at 2:32 PM, K. Macy wrote:
> Could you please try with 207902?
And if not, please get a coredump with a backtrace with symbols.
Thanks
___
freebsd-current@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-c
Could you please try with 207902?
Thanks,
Kip
On Mon, May 10, 2010 at 11:26 AM, David Wolfskill wrote:
> On Mon, May 10, 2010 at 08:22:43PM +0200, Ed Schouten wrote:
>> ...
>> You don't happen to have a backtrace?
>
> Oops -- sorry; got caught up in getting ready to head in to work:
>
> db> bt
>
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
On 10-5-2010 20:09, Bruce Cran wrote:
> On Friday 30 April 2010 09:11:49 Gary Jennejohn wrote:
>
>> A number of variables go into calculating vm.kmem_size (see kmeminit()
>> in kern_malloc.c).
>>
>> In the end, the kernel won't allocate more than twic
2010/5/10 Peter Jeremy :
> On 2010-May-08 12:20:05 +0200, Ulrich Spörlein wrote:
>>This LOR also is not yet listed on the LOR page, so I guess it's rather
>>new. I do use SUJ.
>>
>>lock order reversal:
>> 1st 0xc48388d8 ufs (ufs) @ /usr/src/sys/kern/vfs_lookup.c:502
>> 2nd 0xec0fe304 bufwait (bufw
On Fri, May 07, 2010 at 06:08:05PM +0200, Gustavo Perez Querol wrote:
>
> >
> > Hello Gustau, I'm so sorry for belated response that I had no time to
> > read and work email and wireless stuffs.
> >
> > Could you please test this symptom with attached patch? It looks in
> > CURRENT it missed to i
Hi David,
I will take a look later this afternoon PST.
Thanks,
-- Qing
> -Original Message-
> From: owner-freebsd-curr...@freebsd.org [mailto:owner-freebsd-
> curr...@freebsd.org] On Behalf Of David Wolfskill
> Sent: Monday, May 10, 2010 11:26 AM
> To: Ed Schouten
> Cc: curr...@freebsd.
On Mon, May 10, 2010 at 08:22:43PM +0200, Ed Schouten wrote:
> ...
> You don't happen to have a backtrace?
Oops -- sorry; got caught up in getting ready to head in to work:
db> bt
Tracing pid 20 tid 100067 td 0xc5a19000
_mtx_lock_flags(58,0,c0cd2d5b,570,80,...) at _mtx_lock_flags+0x46
flowtable_f
On Friday 30 April 2010 09:11:49 Gary Jennejohn wrote:
> A number of variables go into calculating vm.kmem_size (see kmeminit()
> in kern_malloc.c).
>
> In the end, the kernel won't allocate more than twice the physical memory
> size _which it has discovered_.
>
> The question is, how much of yo
During transition to multi-user mode on first reboot after upgrading
from r207812 -> r207844; from the sserial console:
3 Select option, [Enter] for default 3
3 or [Space] to pause timer 0 3
@DY
GDB: no debug ports present
KDB: debugger
08.05.2010 20:31, Anonymous пишет:
- jfbterm
- boot splash
- apps that use libvgl (e.g. mplayer)
- other uses for graphic modes
Is there a way to avoid recompiling kernel just to use them?
may be need include SC_PIXEL_MODE into GENERIC for amd64 and i386?
___
15 matches
Mail list logo