I have a 1950-III 1U on the floor here that I'm loading. After configuring
IPMI in the BIOS, I can:
[2:6:[EMAIL PROTECTED]:~ ipmitool -I lanplus -U root -H 192.168.221.160 shell
Password:
ipmitool power on
Chassis Power Control: Up/On
Now. strike is not the 1U in question... and does not, in
John Baldwin wrote:
This patch merges a few changes from HEAD back to 7.x. I think the endian
changes specifically might solve the issue people saw with zpools created
with non-dtrace kernels not being readable by dtrace kernels and vice versa.
http://www.FreeBSD.org/~jhb/patches/zfs_7.patch
On Fri, Aug 29, 2008 at 02:17:17AM -0400, Zaphod Beeblebrox wrote:
Curiously, IPMI shares the ethernet ports with the onboard ethernet
controllers without FreeBSD's knowledge. It does use a different MAC
address. It is also apparently capable of using vlans (haven't tested this
yet). I'm
Henri Hennebert wrote:
John Baldwin wrote:
This patch merges a few changes from HEAD back to 7.x. I think the
endian changes specifically might solve the issue people saw with
zpools created with non-dtrace kernels not being readable by dtrace
kernels and vice versa.
TB --- 2008-08-29 06:42:04 - tinderbox 2.3 running on freebsd-stable.sentex.ca
TB --- 2008-08-29 06:42:04 - starting RELENG_7 tinderbox run for amd64/amd64
TB --- 2008-08-29 06:42:04 - cleaning the object tree
TB --- 2008-08-29 06:42:20 - cvsupping the source tree
TB --- 2008-08-29 06:42:20 -
TB --- 2008-08-29 07:36:05 - tinderbox 2.3 running on freebsd-stable.sentex.ca
TB --- 2008-08-29 07:36:05 - starting RELENG_7 tinderbox run for i386/i386
TB --- 2008-08-29 07:36:05 - cleaning the object tree
TB --- 2008-08-29 07:36:19 - cvsupping the source tree
TB --- 2008-08-29 07:36:19 -
Hi,
On 29 Aug 2008, at 08:44, Jeremy Chadwick wrote:
[...]That said, the feature you're referring to (IPMI piggybacking
on top of
an existing NIC on the mainboard) is called ASF from a NIC driver
perspective.
In implementations I've looked at, the interfaces really are distinct
hardware
TB --- 2008-08-29 08:16:45 - tinderbox 2.3 running on freebsd-stable.sentex.ca
TB --- 2008-08-29 08:16:45 - starting RELENG_7 tinderbox run for i386/pc98
TB --- 2008-08-29 08:16:45 - cleaning the object tree
TB --- 2008-08-29 08:16:56 - cvsupping the source tree
TB --- 2008-08-29 08:16:56 -
TB --- 2008-08-29 08:40:50 - tinderbox 2.3 running on freebsd-stable.sentex.ca
TB --- 2008-08-29 08:40:50 - starting RELENG_7 tinderbox run for ia64/ia64
TB --- 2008-08-29 08:40:50 - cleaning the object tree
TB --- 2008-08-29 08:41:03 - cvsupping the source tree
TB --- 2008-08-29 08:41:03 -
John Birrell wrote:
I know that there are issues with upgrading from 6.X (where .X isn't the
most recent on RELENG6). I'll need help from someone with an old 6.2
box (say) to test out the builds. I have no hardware to run an old version
of 6 on.
I've got a 6.2 box that needs upgrading anyway,
On Fri, Aug 29, 2008 at 4:48 AM, Bob Bishop [EMAIL PROTECTED] wrote:
The only problem I have seen on em is that by default the driver resets the
phy during boot which confuses IPMI; if a SOL console session is active, the
driver is signalled not to do the reset.
Same here. The 1950-III
On Thursday 28 August 2008 06:36:30 pm John Birrell wrote:
It goes without saying that this didn't go anywhere near as smoothly as
I hoped it would. My attention to detail was less than perfect. Sorry
for the pain I've caused.
A big thanks to those who've put work into fixing the mistakes,
On Friday 29 August 2008 01:33:36 am Jonathan Bond-Caron wrote:
Hi Everyone,
I have a dell 1750 server with ERA/O card running on FreeBSD 7.0-STABLE
According to Dell, the ERA card supports ipmi 1.0:
http://linux.dell.com/ipmi.shtml
But so far no luck with freebsd :/
If your BIOS
Well I got bit by this and am dead in the water. Nothing builds. I
tried the DEBUG_FLAGS=-g trick but to no avail.
I get this:
cc: Internal error: segmentation fault: 11 (program ld)
I do not have a backup ld. (My bad.)
Where can I get a good one? I cannot find any servers with built
On Fri, 29 Aug 2008, Dan Allen wrote:
Well I got bit by this and am dead in the water. Nothing builds. I tried
the DEBUG_FLAGS=-g trick but to no avail.
I get this:
cc: Internal error: segmentation fault: 11 (program ld)
I do not have a backup ld. (My bad.)
Where can I get a good one?
Dan Allen wrote:
Well I got bit by this and am dead in the water. Nothing builds. I
tried the DEBUG_FLAGS=-g trick but to no avail.
My 7.0 box upgraded fine this morning:
FreeBSD ids.eagle.ca 7.1-PRERELEASE FreeBSD 7.1-PRERELEASE #0: Fri Aug
29 11:38:12 EDT 2008 [EMAIL
John Birrell wrote:
I know that there are issues with upgrading from 6.X (where .X isn't the
most recent on RELENG6). I'll need help from someone with an old 6.2
box (say) to test out the builds. I have no hardware to run an old version
of 6 on.
This is most likely not exactly what you are
On Fri, Aug 29, 2008 at 10:43:39AM -0600, Dan Allen wrote:
Well I got bit by this and am dead in the water. Nothing builds. I
tried the DEBUG_FLAGS=-g trick but to no avail.
I get this:
cc: Internal error: segmentation fault: 11 (program ld)
I do not have a backup ld. (My bad.)
So I have a patch to try and straighten out the ppbus/ppc interrupt stuff a
bit. Rather than passing IRQ numbers around as ivars, etc., ppc is smart
enough to let child devices ask for SYS_RES_IRQ rid 0 and let them use its
assigned IRQ resource. It then uses an interrupt event to mange the
On Friday 29 August 2008 03:57:46 am Henri Hennebert wrote:
Henri Hennebert wrote:
John Baldwin wrote:
This patch merges a few changes from HEAD back to 7.x. I think the
endian changes specifically might solve the issue people saw with
zpools created with non-dtrace kernels not being
On Fri, 29 Aug 2008 10:43:39 -0600 Dan Allen wrote:
Well I got bit by this and am dead in the water. Nothing builds. I
tried the DEBUG_FLAGS=-g trick but to no avail.
I get this:
cc: Internal error: segmentation fault: 11 (program ld)
Yep, you need some tools installed with debug
The breakage from the WITH_CTF build is indicated by Abort from the
image activator. Signal 11, AKA segmentation fault, is not likely
to be caused by the dtrace MFC problems.
Just in case, if you have buildworld result intact, you should enter
/usr/src/gnu/usr.bin/binutils/ld
and do
On Fri, 29 Aug 2008 22:08:47 +0300 Kostik Belousov wrote:
On Fri, Aug 29, 2008 at 10:43:39AM -0600, Dan Allen wrote:
Well I got bit by this and am dead in the water. Nothing builds. I
tried the DEBUG_FLAGS=-g trick but to no avail.
I get this:
cc: Internal error: segmentation
Steve Bertrand wrote:
Dan Allen wrote:
Well I got bit by this and am dead in the water. Nothing builds. I
tried the DEBUG_FLAGS=-g trick but to no avail.
My 7.0 box upgraded fine this morning:
FreeBSD ids.eagle.ca 7.1-PRERELEASE FreeBSD 7.1-PRERELEASE #0: Fri Aug
29 11:38:12 EDT 2008
I've run into a variance in behavior between my SVN updated tree and my
CVSUP'd tree that is befuddling me.
Running a make depend on two freshly updated trees seems to generate
errors with my SVN tree but not my CVSUP tree. Here is the output of
the SVN tree. This is freshly checked out
O. Hartmann wrote:
Steve Bertrand wrote:
Dan Allen wrote:
Well I got bit by this and am dead in the water. Nothing builds. I
tried the DEBUG_FLAGS=-g trick but to no avail.
My 7.0 box upgraded fine this morning:
FreeBSD ids.eagle.ca 7.1-PRERELEASE FreeBSD 7.1-PRERELEASE #0: Fri Aug
29
Sean Bruno wrote:
mkdep -f .depend -a-I/home/sbruno/bsd/6/lib/csu/i386-elf/../common
-I/home/sbruno/bsd/6/lib/csu/i386-elf/../../libc/include
/home/sbruno/bsd/6/lib/csu/i386-elf/crt1.c
/home/sbruno/bsd/6/lib/csu/i386-elf/crti.S
/home/sbruno/bsd/6/lib/csu/i386-elf/crtn.S
/usr/bin/mkdep:
Dan Allen wrote previously:
well I got bit by this and am dead in the water.
I got the tools and built everything okay once again. Thanks to
everyone for the help!
Dan
___
freebsd-stable@freebsd.org mailing list
The feedback I've been getting indicates that it's safe to go back in the
water again.
--
John Birrell
___
freebsd-stable@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-stable
To unsubscribe, send any mail to [EMAIL
On Fri, Aug 29, 2008 at 03:39:30PM -0700, Sean Bruno wrote:
Sean Bruno wrote:
mkdep -f .depend -a-I/home/sbruno/bsd/6/lib/csu/i386-elf/../common
-I/home/sbruno/bsd/6/lib/csu/i386-elf/../../libc/include
/home/sbruno/bsd/6/lib/csu/i386-elf/crt1.c
It's known that 'make clean' will occasionally not nuke all the
necessary objects in /usr/obj/*.
rm -fr /usr/obj/* is a better bet. Do not rely on 'make clean'.
Oh? Should I look into why the make system isn't removing /usr/obj/ on
a make clean and submit a patch?
--
Sean Bruno
How reliable is make delete-old and make delete-old-libs on 7.1-PRERELEASE?
I ask because I just upgraded a remote system from 6.3-stable to
7.1-PRERELEASE. All seems well so far. Apps are running fine. I just
figure I should do this final bit.
FYI, I've written up how I did this
32 matches
Mail list logo
