On 8/16/06, Dan Nelson <[EMAIL PROTECTED]> wrote:
> How can mysql use 160%? Is this a reporting bug in top because mysql is
> threaded?
You have multiple CPUs, so a threaded process can theoretically reach
100*ncpus cpu usage.
--
Dan Nelson
[EMAIL PROTECTED]
I am seeing this on
On Monday 21 August 2006 13:56, Vivek Khera wrote:
> On Aug 21, 2006, at 12:19 PM, Ian Smith wrote:
> > b) do I need to upgrade all existing ports (way out of date) before
> > the
> > source upgrade, or can I be confident of doing that from 6.1 (-R or
> > -S)?
>
> You really want to rebuild all you
On Mon, Aug 21, 2006 at 09:52:02PM +0200, Patrick M. Hausen wrote:
> And yet more testing ...
>
> I rebuilt my kernel without USB devices and made sure
> atapci1 doesn't share an interrupt with anything:
>
> pcib1: 16
> pcib2: 20
> em0: 16
> em1: 17
> fxp0: 16
> atapci1: 19
> atkbdc0:
On Tuesday 22 August 2006 09:44, Forrest Aldrich wrote:
> The devices would normally appear "in order" (similar to Linux) where
> they are physically attached... first, em0 and em1 would be the
> motherboard NICs, then any PCI cards.
I believe they're probed in order, but it's entirely up to your
> I'm certain I read up on this somewhere before...
>
> When you install a FreeBSD system (6.1 here), the devices don't always
> configure "in order". For example, I have a few Dell PowerEdge systems,
> upon which 2 are FreeBSD
>
> The devices would normally appear "in order" (similar to
I'm certain I read up on this somewhere before...
When you install a FreeBSD system (6.1 here), the devices don't always
configure "in order". For example, I have a few Dell PowerEdge systems,
upon which 2 are FreeBSD
The devices would normally appear "in order" (similar to Linux) where
On Mon, Aug 21, 2006 at 11:52:02PM +0200, Stefan Bethke wrote:
> Am 21.08.2006 um 18:19 schrieb Ian Smith:
> >I recently (without drama) upgraded a 5.4-RELEASE system to
> >FreeBSD 5.5-STABLE #1: Tue Aug 1 11:11:20 EST 2006
> >for 'target practice' at least, on the way to 6.1-STABLE
> >I was pre
On Tuesday 22 August 2006 06:08, Torfinn Ingolfsen wrote:
> Hello,
>
> What ids the current way to control cpu speed (and power consumption)
> in FreeBSD 6-stable?
> Before, est was one way, but all traces of est has disappeared
> from /etc/defaults/rc.conf and thereabouts.
> I find something about
On Monday 21 August 2006 23:08, Dominic Marks wrote:
> You can use device.hints(5) to do this.
>
> I have the following in mine to force a RAID card and Sound card to
> share IRQ 17.
> You need to modify it to suit your environment.
>
> hw.pci3.13.INTA.irq="17"
>
> The `13' value is the device numb
On 17. aug. 2006, at 15.35, Antony Mawer wrote:
Hi list,
A quick question - is it recommended to initialise disks before
using them to allow the disks to map out any "bad spots" early on?
I've seen some "uninitialised" disks (ie. new disks, thrown into a
machine, newfs'd) start to show re
Am 21.08.2006 um 18:19 schrieb Ian Smith:
Hello -stable ones,
I recently (without drama) upgraded a 5.4-RELEASE system to
FreeBSD 5.5-STABLE #1: Tue Aug 1 11:11:20 EST 2006
for 'target practice' at least, on the way to 6.1-STABLE
I was preparing to portupgrade everything next, when I wondered
On Aug 21, 2006, at 12:19 PM, Ian Smith wrote:
a) should I upgrade from RELENG_5 straight to RELENG_6 or should I be
stopping off at 6.1-RELEASE along the way first? and
I'd go with 6.1-REL just to make sure you have a known working
release, not that *you* broke something. With RELENG_6
Hello,
What ids the current way to control cpu speed (and power consumption)
in FreeBSD 6-stable?
Before, est was one way, but all traces of est has disappeared
from /etc/defaults/rc.conf and thereabouts.
I find something about powerd and power_profile, but they don't seem to
work, and I can't see
And yet more testing ...
I rebuilt my kernel without USB devices and made sure
atapci1 doesn't share an interrupt with anything:
pcib1: 16
pcib2: 20
em0: 16
em1: 17
fxp0: 16
atapci1: 19
atkbdc0: 1
atkbd0: 1
sio0: 4
sio1: 3
ppc0: 7
Side note: on this particular box I had to leave the USB devices
On 8/20/06, Darren Pilgrim <[EMAIL PROTECTED]> wrote:
Johnie Wong wrote:
> Dear All,
>
> I am the user of FreeBSD 6.1. Recently, i buy a new server for my
> company which is a Intel Core 2 Duo E6300 (1.86GHz) with Intel
> D946GZIS mainboard, 2GB Consair DDR2 Ram, 3Ware 9500S-4LP, and 4X
> Seagat
Matt Dawson wrote:
On Monday 21 August 2006 13:00, [EMAIL PROTECTED] wrote:
I can confirm the same behaviour with a ULi M1689/Newcastle Athlon64
based system running 6.1-RELEASE-p3 (i386). ad6 just detaches without
warning and it takes a reboot to bring it back. atacontrol reinit has no
effect
You (Gavin Atkinson) wrote:
[...]
> I don't suppose there's any chance you know if ucarp works with
> 6.1-RELEASE and IPv6? This is the one thing stopping me moving my
> machines to 6.1-RELEASE.
>
> If you don't know, then you've given me yet another thing to add to my
> todo list!
No, sorry, I
Could someone please MFC at least v 1.168 of ata-chipset.c into
RELENG_6? Specifically the Nvidia NFORCE-4 support? Most of the
AMD64 motherboards I've gotten lately require this patch.
I have been able to apply diff between 1.165 and 1.168 to RELENG-6 and
it makes the chipset work. (this als
On 8/21/06, Christian Brueffer <[EMAIL PROTECTED]> wrote:
Not exactly the above patch, but a similar one:
http://www.freebsd.org/cgi/cvsweb.cgi/src/sys/dev/ata/ata-chipset.c?rev=1.169&content-type=text/x-cvsweb-markup
This is likely to be MFCed before 6.2 gets released.
Oh, this is great new
On Mon, 2006-08-21 at 18:14 +0200, Andy Hilker wrote:
> Hi Max,
>
> You (Max Laier) wrote:
> > On Monday 21 August 2006 15:53, Andy Hilker wrote:
> > > we are currently migrating our hosts to 6.1-RELEASE with official
> > > binaries (from CD). This is because we want to make use of
> > > freebsd-u
Oliver Fromme wrote:
> Doug Barton wrote:
> > Tom Hummel wrote:
> > > alright, it was bash :( stupid shell.
> >
> > Um, sorry, let's not blame the shell for the BCK (between chair and
> > keyboard) problem. Lots of us use bash as our everyday shell (for
> privileged
> > and unprivileged use
SigmaX asdf wrote:
> I'm trying to setup IPFW to block all ports except those I specify.
> For starters I'm just opening SSH.
>
> # ipfw list
> 00050 divert 8668 ip4 from any to any via rl0
> 00100 allow ip from any to any via lo0
> 00200 deny ip from any to 127.0.0.0/8
> 00300 deny ip from 127.0.
On Aug 19, 2006, at 10:58 PM, SigmaX asdf wrote:
Found my problem. T[h]e firewall_type option is case sensitive --
and "OPEN"
is supposed to be lowercase.
The firewall_type option isn't case-sensitive, and hasn't been since
early 4.x; see /etc/rc.firewall:
case ${firewall_type} in
[Oo][P
Hello -stable ones,
I recently (without drama) upgraded a 5.4-RELEASE system to
FreeBSD 5.5-STABLE #1: Tue Aug 1 11:11:20 EST 2006
for 'target practice' at least, on the way to 6.1-STABLE
I was preparing to portupgrade everything next, when I wondered:
a) should I upgrade from RELENG_5 straight
Hi Max,
You (Max Laier) wrote:
> On Monday 21 August 2006 15:53, Andy Hilker wrote:
> > we are currently migrating our hosts to 6.1-RELEASE with official
> > binaries (from CD). This is because we want to make use of
> > freebsd-update binary patches.
> >
> > Our problem is that GENERIC kernel doe
I'm trying to setup IPFW to block all ports except those I specify.
For starters I'm just opening SSH.
# ipfw list
00050 divert 8668 ip4 from any to any via rl0
00100 allow ip from any to any via lo0
00200 deny ip from any to 127.0.0.0/8
00300 deny ip from 127.0.0.0/8 to any
00301 allow log tcp f
Again ...
On Mon, Aug 21, 2006 at 04:53:28PM +0200, Patrick M. Hausen wrote:
> Seems finally I am able to reproduce part of the problems
> some people see with their hardware.
>
> I used device.hints to force em0 to share its irq
> with atapci1 - the SATA300 controller in my machine.
>
> atapci
Hi, folks!
Seems finally I am able to reproduce part of the problems
some people see with their hardware.
I used device.hints to force em0 to share its irq
with atapci1 - the SATA300 controller in my machine.
atapci1: port
0x30e8-0x30ef,0x30dc-0x30df,0x30e0-0x30e7,0x30d8-0x30db,0x30b0-0x30bf m
Patrick M. Hausen wrote:
Hi, Dominic!
On Mon, Aug 21, 2006 at 02:40:17PM +0100, Dominic Marks wrote:
hw.pci3.13.INTA.irq="17"
The `13' value is the device number, you can find this in dmesg, same
for pciN.
So I tried this:
em1: port 0x5000-0x501f
mem 0xdc18-0xdc19,0xdc10-0xd
Hi, Dominic!
On Mon, Aug 21, 2006 at 02:40:17PM +0100, Dominic Marks wrote:
> hw.pci3.13.INTA.irq="17"
>
> The `13' value is the device number, you can find this in dmesg, same
> for pciN.
So I tried this:
em1: port 0x5000-0x501f
mem 0xdc18-0xdc19,0xdc10-0xdc17 irq 17 at dev
Hello Andy,
On Monday 21 August 2006 15:53, Andy Hilker wrote:
> we are currently migrating our hosts to 6.1-RELEASE with official
> binaries (from CD). This is because we want to make use of
> freebsd-update binary patches.
>
> Our problem is that GENERIC kernel does not contain "device carp".
>
Hi,
we are currently migrating our hosts to 6.1-RELEASE with official
binaries (from CD). This is because we want to make use of
freebsd-update binary patches.
Our problem is that GENERIC kernel does not contain "device carp".
Is there any posibility to use carp without "device carp" in GENERIC
e
Patrick M. Hausen wrote:
Hello!
On Mon, Aug 21, 2006 at 02:14:16PM +0100, Matt Dawson wrote:
FWIW, the problem takes *far* longer to rear its head when the SATA controller
has a PCI INT and IRQ to itself. Put a NIC onto a shared slot (a very Bad
Thing [TM] as the BIOS simply maps the INT to a
Patrick M. Hausen wrote:
Hello!
On Mon, Aug 21, 2006 at 02:14:16PM +0100, Matt Dawson wrote:
FWIW, the problem takes *far* longer to rear its head when the SATA controller
has a PCI INT and IRQ to itself. Put a NIC onto a shared slot (a very Bad
Thing [TM] as the BIOS simply maps the INT to a
Hello!
On Mon, Aug 21, 2006 at 02:14:16PM +0100, Matt Dawson wrote:
> FWIW, the problem takes *far* longer to rear its head when the SATA
> controller
> has a PCI INT and IRQ to itself. Put a NIC onto a shared slot (a very Bad
> Thing [TM] as the BIOS simply maps the INT to a single IRQ and bo
On Monday 21 August 2006 22:44, Matt Dawson wrote:
> > atacontrol detach ata3; atacontrol attach ata3 did.
>
> Yes, that is the method for a controlled remove and reattach, a la hotplug
> SATA. AIUI, though, if the drive goes AWOL on its own you need to reinit
> the channel before issuing an atacon
Doug Barton wrote:
> Tom Hummel wrote:
> > alright, it was bash :( stupid shell.
>
> Um, sorry, let's not blame the shell for the BCK (between chair and
> keyboard) problem. Lots of us use bash as our everyday shell (for privileged
> and unprivileged users) without the kinds of problems you
On Monday 21 August 2006 13:00, [EMAIL PROTECTED] wrote:
> > I can confirm the same behaviour with a ULi M1689/Newcastle Athlon64
> > based system running 6.1-RELEASE-p3 (i386). ad6 just detaches without
> > warning and it takes a reboot to bring it back. atacontrol reinit has no
> > effect. Tried
Hi!
On Sun, Aug 20, 2006 at 01:38:55PM +0100, Matt Dawson wrote:
> I can confirm the same behaviour with a ULi M1689/Newcastle Athlon64 based
> system running 6.1-RELEASE-p3 (i386). ad6 just detaches without warning and
> it takes a reboot to bring it back. atacontrol reinit has no effect. Trie
On Mon, Aug 21, 2006 at 04:03:47AM +0200, Konstantin Saurbier wrote:
> Am 20.08.2006 um 18:20 schrieb Greg Byshenk:
> >What is different is that this was with a 3Ware RAID controller --
> >which made removing/raconfiguring/rebuilding much easier -- but I was
> >seeing the exact same errors.
> No
A few weeks ago I changed harddrives and rebuilt a RAID 0 volume on
nForce4-based RAID. Box runs under FreeBSD 6.1-STABLE as mst recent
built-world.
After reinitializing RAID, I recognized high performance penalty under
heavy disk I/O. New drives in the mentioned RAID 0 array are both
Hitachi T
On Sun, Aug 20, 2006 at 07:55:31PM -0700, Nikolas Britton wrote:
> On 6/1/06, Jack Vogel <[EMAIL PROTECTED]> wrote:
> >I occasionally run into issues that newer PCI device IDs are
> >not yet supported, these in particular are on a new box
> >I am working on. Can someone see that these changes
> >ge
On 8/18/06, Nikolas Britton <[EMAIL PROTECTED]> wrote:
On 8/18/06, Dave Kingsley <[EMAIL PROTECTED]> wrote:
> I am attemping to use a RocketRAID 2224 8 channel card to set up a
> storage server. The server board is an Intel SE7230NH1-E with a P4-D
> 2.8GHz, 2GB RAM.
> FreeBSD doesn't see it at a
Hi, all!
On Mon, Aug 21, 2006 at 04:22:06PM +0900, Pyun YongHyeon wrote:
> Several users reported em(4) watchdog errors but I couldn't reproduce
> it on my system. A blind patch posted to net ML and I'd like to hear
> success/failure report.
>
> See http://lists.freebsd.org/pipermail/freebsd-net
Hi!
Am 21.08.2006 um 09:10 schrieb Patrick M. Hausen:
Hi, all!
On Mon, Aug 21, 2006 at 04:03:47AM +0200, Konstantin Saurbier wrote:
This errors are not driver or OS dependent such as they appear on
FreeBSD as well on different Linux distros.
Since not all controllers suffering of these error
Johnnie wrote:
test
___
freebsd-stable@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-stable
To unsubscribe, send any mail to "[EMAIL PROTECTED]"
test passed
___
freebsd-stable
On Mon, Aug 21, 2006 at 09:10:53AM +0200, Patrick M. Hausen wrote:
> Hi, all!
>
> On Mon, Aug 21, 2006 at 04:03:47AM +0200, Konstantin Saurbier wrote:
>
> > This errors are not driver or OS dependent such as they appear on
> > FreeBSD as well on different Linux distros.
> > Since not all
test
___
freebsd-stable@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-stable
To unsubscribe, send any mail to "[EMAIL PROTECTED]"
Hi, all!
On Mon, Aug 21, 2006 at 04:03:47AM +0200, Konstantin Saurbier wrote:
> This errors are not driver or OS dependent such as they appear on
> FreeBSD as well on different Linux distros.
> Since not all controllers suffering of these errors it is maybe
> depending on the firmware or boar
49 matches
Mail list logo
