On Wed, 4 May 2011, KIRIYAMA Kazuhiko wrote:
> At Wed, 4 May 2011 03:47:02 +1000 (EST),
> Ian Smith wrote:
> >
> > On Wed, 4 May 2011, KIRIYAMA Kazuhiko wrote:
> > > Hi all,
> > > Recently I upgraded to 8.2-STABLE and reconfigured natd + jailed box,
> > but
> > > all packets could not
On Wed, 4 May 2011, KIRIYAMA Kazuhiko wrote:
> At Wed, 4 May 2011 03:47:02 +1000 (EST),
> Ian Smith wrote:
> >
> > On Wed, 4 May 2011, KIRIYAMA Kazuhiko wrote:
> > > Hi all,
> > > Recently I upgraded to 8.2-STABLE and reconfigured natd + jailed box,
> > but
> > > all packets could not
At Wed, 04 May 2011 10:40:12 +0900,
My wrote:
>
> At Wed, 4 May 2011 03:47:02 +1000 (EST),
> Ian Smith wrote:
> >
> > > +++ /etc/rc.d/ipfw 2011-05-03 22:08:14.0 +0900
> > > @@ -35,15 +35,11 @@
> > >
> > > ipfw_start()
> > > {
> > > -local _firewall_type
> > > -
At Wed, 4 May 2011 03:47:02 +1000 (EST),
Ian Smith wrote:
>
> On Wed, 4 May 2011, KIRIYAMA Kazuhiko wrote:
> > Hi all,
> > Recently I upgraded to 8.2-STABLE and reconfigured natd + jailed box, but
> > all packets could not over nat box. I've researched and found
> > /etc/rc.firewall does not r
On Tue, May 3, 2011 at 12:34 PM, Eric Damien wrote:
> Hi Scot,
>
> the link you provided is for a FreeBSD MBR Slice.
> How about the GPT? Because I have the exact same problem,
> and after following 2.7 (modified for no mirror) on
> http://wiki.freebsd.org/RootOnZFS/InstallingFreeBSD
>
> I
Hi Scot,
the link you provided is for a FreeBSD MBR Slice.
How about the GPT? Because I have the exact same problem,
and after following 2.7 (modified for no mirror) on
http://wiki.freebsd.org/RootOnZFS/InstallingFreeBSD
I did
Fixit# sysctl kern.geom.debugflags=0x10
Fixit# gpart boot
On Wed, 4 May 2011, KIRIYAMA Kazuhiko wrote:
> Hi all,
> Recently I upgraded to 8.2-STABLE and reconfigured natd + jailed box, but
> all packets could not over nat box. I've researched and found
> /etc/rc.firewall does not recieve argument of firewall_type. So ipfw does
> not divert and natd c
On Tue, 3 May 2011, Kenneth D. Merry wrote:
KDM> Sorry you ran into all of those problems! Needless to say I haven't seen
KDM> that with the 9.0 firmware in my environment, but then again I've got a
KDM> different setup.
I just postd comment on LSI kb forum, will see how they'd comment it.
KDM>
On Tue, May 03, 2011 at 21:28:27 +0400, Dmitry Morozovsky wrote:
>
> On Tue, 3 May 2011, Dmitry Morozovsky wrote:
>
> DM> DM> Well, I tried, and unfortunately I can not say that I'm happy after
> the
> DM> DM> upgrade. :(
> DM> DM>
> DM> DM> Particularly, adapter now takes *VERY* long time (>1
On Tue, 3 May 2011, Dmitry Morozovsky wrote:
DM> DM> Well, I tried, and unfortunately I can not say that I'm happy after the
DM> DM> upgrade. :(
DM> DM>
DM> DM> Particularly, adapter now takes *VERY* long time (>10 minutes) to
initialize,
DM> DM> and report as "ERROR" in BIOS utility (while s
Hi all,
Recently I upgraded to 8.2-STABLE and reconfigured natd + jailed box, but
all packets could not over nat box. I've researched and found
/etc/rc.firewall does not recieve argument of firewall_type. So ipfw does
not divert and natd could not be performed. The reason is /etc/rc.d/ipfw
incorrec
On Tue, 3 May 2011, Dmitry Morozovsky wrote:
DM> KDM> It looks like you have a SAS2008, with the 4.0 firmware. I think it
would
DM> KDM> be worthwhile to upgrade to the 9.0 firmware. I know for sure there
are
DM> KDM> issues with the 2.0 firmware, and I know the 9.0 firmware works fairly
DM> K
On 29/04/2011, at 10:38, Jeremy Chadwick wrote:
>> The OSX box is connected via an Airport Express (11n).
>
> Can you connect something to it via Ethernet and attempt an FTP transfer
> (both PUT (store on server) and GET (retrieve from server)) from a
> client on the wired network? Make sure wha
On Mon, 2 May 2011, Kenneth D. Merry wrote:
KDM> It looks like you have a SAS2008, with the 4.0 firmware. I think it would
KDM> be worthwhile to upgrade to the 9.0 firmware. I know for sure there are
KDM> issues with the 2.0 firmware, and I know the 9.0 firmware works fairly
KDM> well. I don't
On Tue, May 03, 2011 at 02:30:15PM +0200, Olaf Seibert wrote:
> On Tue 03 May 2011 at 05:20:52 -0700, Jeremy Chadwick wrote:
> > To be on the safe side, pick something that's small at first, then work
> > your way up. You'll need probably 1+ weeks of heavy ZFS I/O between
> > tests (e.g. don't cha
On Tue, May 03, 2011 at 10:31:57AM +0100, Vincent Hoffman wrote:
> On 03/05/2011 10:16, Jeremy Chadwick wrote:
>
>
> > Sadly I don't see a way with bsnmpd(8) to monitor things like interrupt
> > usage, etc. otherwise I'd be graphing that. The more monitoring the
> > better; at least then I could
On Tue 03 May 2011 at 05:20:52 -0700, Jeremy Chadwick wrote:
> To be on the safe side, pick something that's small at first, then work
> your way up. You'll need probably 1+ weeks of heavy ZFS I/O between
> tests (e.g. don't change the tunable, reboot, then 4 hours later declare
> the new (larger)
On Tue, May 03, 2011 at 12:08:54PM +0200, Olaf Seibert wrote:
> On Tue 03 May 2011 at 02:21:13 -0700, Jeremy Chadwick wrote:
> > There are two things you might try fiddling with. These are sysctls so
> > you can try them on the fly:
> >
> > hw.acpi.disable_on_reboot
> > hw.acpi.handle_reboot
>
>
On Mon, May 02, 2011 at 06:58:54PM -0700, Jeremy Chadwick wrote:
> The next thing I tried was "/etc/rc.d/pf stop", which worked. Then I
> did "/etc/rc.d/pf start", which also worked. However, what I saw next
> surely indicated a bug in the pf layer somewhere -- "pfctl -s states"
> and "pfctl -s
On Tue, May 3, 2011 at 12:12 PM, Vlad Galu wrote:
>
>
> On Tue, May 3, 2011 at 11:31 AM, Vincent Hoffman wrote:
>
>> On 03/05/2011 10:16, Jeremy Chadwick wrote:
>>
>>
>> > Sadly I don't see a way with bsnmpd(8) to monitor things like interrupt
>> > usage, etc. otherwise I'd be graphing that. Th
On Tue, May 3, 2011 at 11:31 AM, Vincent Hoffman wrote:
> On 03/05/2011 10:16, Jeremy Chadwick wrote:
>
>
> > Sadly I don't see a way with bsnmpd(8) to monitor things like interrupt
> > usage, etc. otherwise I'd be graphing that. The more monitoring the
> > better; at least then I could say "wo
On Tue 03 May 2011 at 02:21:13 -0700, Jeremy Chadwick wrote:
> There are two things you might try fiddling with. These are sysctls so
> you can try them on the fly:
>
> hw.acpi.disable_on_reboot
> hw.acpi.handle_reboot
Thanks. For now I've set the second to 1 and we'll see if that affects
matter
On Tue 03 May 2011 at 17:21:52 +1000, Peter Jeremy wrote:
> On 2011-May-02 16:32:30 +0200, Olaf Seibert wrote:
> >However, it doesn't automatically reboot in 15 seconds, as promised.
> >It just sits there the whole weekend, until I log onto the IPMI console
> >and press the virtual reset button.
>
On 03/05/2011 10:16, Jeremy Chadwick wrote:
> Sadly I don't see a way with bsnmpd(8) to monitor things like interrupt
> usage, etc. otherwise I'd be graphing that. The more monitoring the
> better; at least then I could say "wow, interrupts really did shoot
> through the roof -- the box went cra
On Mon, May 02, 2011 at 06:58:54PM -0700, Jeremy Chadwick wrote:
> Here's one piece of core.0.txt which makes no sense to me -- the "rate"
> column. I have a very hard time believing that was the interrupt rate
> of all the relevant devices at the time (way too high). Maybe this data
> becomes w
On Mon, May 02, 2011 at 04:32:30PM +0200, Olaf Seibert wrote:
> I have a FreeBSD/amd64 8.2 server that has a few ZFS file systems served
> over NFS. It has 8 GB of memory. There are 6 disks of 1,5 TB each
> forming a pool with raidz2.
>
> >From time to time it crashes with some stack backtrace (i
On Tue, May 03, 2011 at 10:48:00AM +0200, Daniel Hartmeier wrote:
> On Mon, May 02, 2011 at 06:58:54PM -0700, Jeremy Chadwick wrote:
>
> > Status: Enabled for 76 days 06:49:10 Debug: Urgent
>
> > The "pf uptime" shown above, by the way, matches system uptime.
>
> > ps -axl
> >
> > UI
On Mon, May 02, 2011 at 06:58:54PM -0700, Jeremy Chadwick wrote:
> Status: Enabled for 76 days 06:49:10 Debug: Urgent
> The "pf uptime" shown above, by the way, matches system uptime.
> ps -axl
>
> UID PID PPID CPU PRI NI VSZ RSS MWCHAN STAT TT TIME COMMAND
> 0 42
On 2011-May-02 16:32:30 +0200, Olaf Seibert wrote:
>However, it doesn't automatically reboot in 15 seconds, as promised.
>It just sits there the whole weekend, until I log onto the IPMI console
>and press the virtual reset button.
Your reference to IMPI indicates this is not a consumer PC. Can y
On Tue, May 03, 2011 at 09:00:42AM +0200, Daniel Hartmeier wrote:
> I read those graphs differently: the problem doesn't arise slowly,
> but rather seems to start suddenly at 13:00.
>
> Right after 13:00, traffic on em0 drops, i.e. the firewall seems
> to stop forwarding packets completely.
>
> Y
I read those graphs differently: the problem doesn't arise slowly,
but rather seems to start suddenly at 13:00.
Right after 13:00, traffic on em0 drops, i.e. the firewall seems
to stop forwarding packets completely.
Yet, at the same time, the states start to increase, almost linearly
at about one
31 matches
Mail list logo
