On 11 August 2011 07:55, Jan Mikkelsen wrote:
> Hi,
>
> I have added these device IDs to pucdata.c to support the Moxa CP-112UL board
> family.
>
> Should I submit a problem report, or is there an easier way to get the patch
> merged?
The "right" way is to get a PR submitted, then chase it up w
On Wed, Aug 10, 2011 at 10:24 PM, Doug Barton wrote:
> Back up the old zsh on the working system, install the new one, test.
>
Sorry for the noise, it was a bug in Django 1.3. I had multiple versions
installed and it was picking up the wrong one on the effected machine.
--
Adam Vande More
___
On 08/10/2011 19:51, Adam Vande More wrote:
> On Wed, Aug 10, 2011 at 8:22 PM, Jeremy Chadwick
> wrote:
>
>>> Looks like SIGTTOU (output from background process)?
>>> This should be controllable with stty -tostop.
>>> (But why has it changed...?)
>>
>> On all our RELENG_8 systems (though I use bas
On Wed, Aug 10, 2011 at 8:22 PM, Jeremy Chadwick
wrote:
> > Looks like SIGTTOU (output from background process)?
> > This should be controllable with stty -tostop.
> > (But why has it changed...?)
>
> On all our RELENG_8 systems (though I use bash), -tostop is default.
>
Hm, it seems there might
On Thu, Aug 11, 2011 at 02:03:06AM +0200, Raimund Steger wrote:
> Adam Vande More wrote:
> >I am unable to start processes in the background after a recent upgrade to
> >stable from 8.1R.
> >
> >I get:
> >
> >suspended (tty output)
> >
> >when trying to start a process like
> >
> >python /usr/home/
Adam Vande More wrote:
I am unable to start processes in the background after a recent upgrade to
stable from 8.1R.
I get:
suspended (tty output)
when trying to start a process like
python /usr/home/adam/randr/manage.py runserver 0.0.0.0:18080 &
my shell is zsh 4.3.12
Looks like SIGTTOU (
Hi,
I have added these device IDs to pucdata.c to support the Moxa CP-112UL board
family.
Should I submit a problem report, or is there an easier way to get the patch
merged?
(I care about 8-STABLE at the moment …)
Thanks,
Jan Mikkelsen
//depot/vendor/freebsd/8.2/src/sys/dev/puc/pucda
I am unable to start processes in the background after a recent upgrade to
stable from 8.1R.
I get:
suspended (tty output)
when trying to start a process like
python /usr/home/adam/randr/manage.py runserver 0.0.0.0:18080 &
my shell is zsh 4.3.12
--
Adam Vande More
___
On Wed, Aug 10, 2011 at 05:26:27PM +0100, Steven Hartland wrote:
> - Original Message - From: "Jeremy Chadwick"
> free...@jdc.parodius.com
>
> >>>In combination with this, we use the following in /etc/rc.conf (the
> >>>dumpdev line is important, else savecore won't pick up anything):
> >>>
- Original Message -
From: "Jeremy Chadwick" free...@jdc.parodius.com
>In combination with this, we use the following in /etc/rc.conf (the
>dumpdev line is important, else savecore won't pick up anything):
>
>dumpdev="auto"
I thought this was ment to be the default from back in the 6.x
On Wed, Aug 10, 2011 at 04:46:17PM +0100, Steven Hartland wrote:
> >On Wed, Aug 10, 2011 at 03:22:52PM +0100, Steven Hartland wrote:
> >>The base stack reported is a double fault with no additional
> >>details and CTRL+ALT+ESC fails to break to the debugger as
> >>does and NMI, even though it at le
- Original Message -
From: "Jeremy Chadwick"
On Wed, Aug 10, 2011 at 03:22:52PM +0100, Steven Hartland wrote:
The base stack reported is a double fault with no additional
details and CTRL+ALT+ESC fails to break to the debugger as
does and NMI, even though it at least tries printing t
- Original Message -
From: "Steven Hartland"
To:
Sent: Wednesday, August 10, 2011 3:22 PM
Subject: debugging frequent kernel panics on 8.2-RELEASE
We're currently experiencing a large number of kernel panics
on FreeBSD 8.2-RELEASE across a large number of machines here.
The base s
on 10/08/2011 17:22 Steven Hartland said the following:
> The kernel is compiled with:-
> options KDB # Kernel debugger related code
> options KDB_TRACE # Print a stack trace for a panic
You also have to provide an actual debugger backend like built-in DDB or a stub
for remot
On Wed, Aug 10, 2011 at 03:22:52PM +0100, Steven Hartland wrote:
> The base stack reported is a double fault with no additional
> details and CTRL+ALT+ESC fails to break to the debugger as
> does and NMI, even though it at least tries printing the
> following many times some quite jumbled:-
> NMI .
Hi.
Tried to use FreeBSD-9.0-BETA1-i386-bootonly.iso in VirtualBox to test.
Installation stops after trying to fetch files from ftp. Attached screenshot is
informative, I think. Seems to use i386/ twice for some reason.
Regards,
Vans.___
freebsd-stabl
We're currently experiencing a large number of kernel panics
on FreeBSD 8.2-RELEASE across a large number of machines here.
The base stack reported is a double fault with no additional
details and CTRL+ALT+ESC fails to break to the debugger as
does and NMI, even though it at least tries printing
On Wed, Aug 10, 2011 at 01:42:11PM +0300, Daniel Kalchev wrote:
>
>
> On 10.08.11 11:47, Jeremy Chadwick wrote:
> >So we're back to where we started: swap slices/partitions can be
> >greater than 32GBytes in size, but "something" is limiting the
> >maximum amount of memory which can be dumped to
On 10.08.11 14:19, Eugene Grosbein wrote:
You should read gmirror(8) manual page about "Doing kernel dumps to
gmirror providers".
Thanks, I totally forgot about the gmirror limitations.
When using the default minidump, the result is:
savecore: first and last dump headers disagree on /dev/mi
10.08.2011 17:42, Daniel Kalchev writes:
> I believe the gmirror bug might exist in smaller partitions as well, but
> haven't tested it yet (have few such systems that never duped core). It
> does not matter if I do full dump or minidump: on gmirrored 64GB
> partittion savecore does not find an
On 10.08.11 11:47, Jeremy Chadwick wrote:
So we're back to where we started: swap slices/partitions can be
greater than 32GBytes in size, but "something" is limiting the maximum
amount of memory which can be dumped to a single swap swap to 32GBytes.
It seems there is still some confusion. Par
Hi Daniel,
Just a stupid question, as I have done something different. Can't you use a
different device or slice for the dump? In that case there is no limitation
on the size of the dump device, as far as I know.
My setup: 96GB, dump device local 160G disc, slice for swap, slice for
dump, sy
Am 10.08.2011 um 10:47 schrieb Jeremy Chadwick:
> On Wed, Aug 10, 2011 at 08:27:27AM +, Holger Kipp wrote:
>>
>> Am 10.08.2011 um 10:09 schrieb Daniel Kalchev:
>>
>>> On 10.08.11 10:47, Jeremy Chadwick wrote:
On Wed, Aug 10, 2011 at 10:13:14AM +0300, Daniel Kalchev wrote:
> I am more
On Wed, Aug 10, 2011 at 08:27:27AM +, Holger Kipp wrote:
>
> Am 10.08.2011 um 10:09 schrieb Daniel Kalchev:
>
> > On 10.08.11 10:47, Jeremy Chadwick wrote:
> >> On Wed, Aug 10, 2011 at 10:13:14AM +0300, Daniel Kalchev wrote:
> >>> I am more concerned that with 32GB of swap in single device I
Am 10.08.2011 um 10:09 schrieb Daniel Kalchev:
> On 10.08.11 10:47, Jeremy Chadwick wrote:
>> On Wed, Aug 10, 2011 at 10:13:14AM +0300, Daniel Kalchev wrote:
>>> I am more concerned that with 32GB of swap in single device I could not
>>> dump kernel core, with 64GB of RAM.
>> My apologies if I'v
Chuck Swiger wrote:
> On Aug 9, 2011, at 7:26 AM, Daniel Kalchev wrote:
> > I am trying to set up 64GB partitions for swap for a system that
> > has 64GB of RAM (with the idea to dump kernel core etc). But, on
> > 8-stable as of today I get:
> >
> > WARNING: reducing size to maximum of 67108864
On 10.08.11 10:47, Jeremy Chadwick wrote:
On Wed, Aug 10, 2011 at 10:13:14AM +0300, Daniel Kalchev wrote:
I am more concerned that with 32GB of swap in single device I could
not dump kernel core, with 64GB of RAM.
My apologies if I've misunderstood something, but why does this of any
concern?
On Wed, Aug 10, 2011 at 10:13:14AM +0300, Daniel Kalchev wrote:
> On 09.08.11 18:16, David Wolfskill wrote:
> >While FreeBSD cannot address more than 32GB per swap space, it
> >permits as many as 32 swap spaces to be active concurrently.
>
> I am more concerned that with 32GB of swap in single dev
On 09.08.11 18:16, David Wolfskill wrote:
While FreeBSD cannot address more than 32GB per swap space, it permits
as many as 32 swap spaces to be active concurrently.
I am more concerned that with 32GB of swap in single device I could not
dump kernel core, with 64GB of RAM.
Daniel
_
29 matches
Mail list logo
