Bug#386910: [PR 26957] ICE in make_decl_rtl, at varasm.c:871
Package: gcc-4.1
Version: 4.1.1-5
Severity: important
Tags: patch, upstream
Forwarded: http://gcc.gnu.org/PR26957
The attached fixes an ICE when building packages like ace.
#! /bin/sh -e
# All lines beginning with `# DPATCH:' are a description of the patch.
# DP: Fix for c++/26957; committed upstream
dir=
if [ $# -eq 3 -a $2 = '-d' ]; then
pdir=-d $3
dir=$3/
elif [ $# -ne 1 ]; then
echo 2 `basename $0`: script expects -patch|-unpatch as argument
exit 1
fi
case $1 in
-patch)
patch $pdir -f --no-backup-if-mismatch -p0 $0
#cd ${dir}gcc autoconf
;;
-unpatch)
patch $pdir -f --no-backup-if-mismatch -R -p0 $0
#rm ${dir}gcc/configure
;;
*)
echo 2 `basename $0`: script expects -patch|-unpatch as argument
exit 1
esac
exit 0
# append the patch here and adjust the -p? flag in the patch calls.
2006-09-07 Jason Merrill [EMAIL PROTECTED]
PR c++/26957
* method.c (use_thunk): Clear DECL_HAS_VALUE_EXPR_P on copied
parms.
Index: method.c
===
*** gcc/cp/method.c (revision 116754)
--- gcc/cp/method.c (working copy)
*** use_thunk (tree thunk_fndecl, bool emit_
*** 419,424
--- 419,425
TREE_CHAIN (x) = t;
DECL_CONTEXT (x) = thunk_fndecl;
SET_DECL_RTL (x, NULL_RTX);
+ DECL_HAS_VALUE_EXPR_P (x) = 0;
t = x;
}
a = nreverse (t);
Bug#230313: Bug #230313:
Luciano Bello wrote: Hi, I'm intent to adopt MRTGutils, I thinks it's a useful tool. The URL http://www.poehlsen.org/mrtgutils/ don't work any more. I know that you submit this bug 2 years ago, do you know where this project is now? The debian mrtgutils was developed by me and is Debian specific utility; it has no webpage. There is another application on the net called mrtgutils that is unrelated. randolph -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Bug#352529: [hppa] internal compiler error: in reload_cse_simplify_operands, at postreload.c:391 (error: insn does not satisfy its constraints)
While investigating gstreamer0.10-ffmpeg's build failure under hppa[1],
I received the following error from gcc:
gcc -DHAVE_CONFIG_H -I. -I. -I.. -I../libavutil -DHAVE_AV_CONFIG_H=1 -Wall
-Wno-switch -g -O2 -MT mpegaudiodec.lo -MD -MP -MF .deps/mpegaudiodec.Tpo -c
mpegaudiodec.c -fPIC -DPIC -o .libs/mpegaudiodec.o
mpegaudiodec.c: In function 'mp_decode_frame':
mpegaudiodec.c:2445: warning: pointer targets in passing argument 4 of
'ff_mpa_synth_filter' differ in signedness
mpegaudiodec.c: In function 'ff_mpa_synth_filter':
mpegaudiodec.c:920: error: insn does not satisfy its constraints:
(insn 4924 2540 2542 4 mpegaudiodec.c:888 (set (reg:HI 70 %fr23 [1852])
(reg:HI 1 %r1)) 53 {*pa.md:2926} (nil)
(nil))
mpegaudiodec.c:920: internal compiler error: in reload_cse_simplify_operands,
at postreload.c:391
This is now fixed in gcc svn.
randolph
--
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Bug#348136: [patch/hppa] Floating point exception handling patch
Package: glibc Version: 2.3.5-11 Severity: important Tags: patch The attached patch fixes a problem with floating point exception handling on hppa. This affects packages that use feholdexcept and fesetenv, such as uic from QT. This patch fixes #342545. Carlos is on vacation now - I'll ask him to merge this upstream when he returns, meanwhile perhaps somebody can roll a new glibc package for debian? randolph #! /bin/sh -e # DP: Description: hppa floating point exception handling fix # DP: Related bugs: Debian #342545 # DP: Dpatch author: Randolph Chung [EMAIL PROTECTED] # DP: Patch author: Randolph Chung [EMAIL PROTECTED] # DP: Upstream status: Pending # DP: Status Details: to be merged by Carlos # DP: Date: Sun, 15 Jan 2006 PATCHLEVEL=1 if [ $# -ne 2 ]; then echo 2 `basename $0`: script expects -patch|-unpatch as argument exit 1 fi case $1 in -patch) patch -d $2 -f --no-backup-if-mismatch -p$PATCHLEVEL $0;; -unpatch) patch -d $2 -f --no-backup-if-mismatch -R -p$PATCHLEVEL $0;; *) echo 2 `basename $0`: script expects -patch|-unpatch as argument exit 1 esac exit 0 # append the patch here and adjust the -p? flag in the patch calls. diff -uNr glibc-2.3.5/sysdeps/hppa/fpu.orig/fegetenv.c glibc-2.3.5/sysdeps/hppa/fpu/fegetenv.c --- glibc-2.3.5/sysdeps/hppa/fpu.orig/fegetenv.c2006-01-14 10:17:19.0 -0800 +++ glibc-2.3.5/sysdeps/hppa/fpu/fegetenv.c 2006-01-14 10:19:08.0 -0800 @@ -27,10 +27,7 @@ unsigned long long buf[4], *bufptr = buf; __asm__ ( - fstd,ma %%fr0,8(%1)\n - fstd,ma %%fr1,8(%1)\n - fstd,ma %%fr2,8(%1)\n - fstd %%fr3,0(%1)\n + fstd %%fr0,0(%1)\n : =m (buf), +r (bufptr)); memcpy (envp, buf, sizeof (*envp)); return 0; diff -uNr glibc-2.3.5/sysdeps/hppa/fpu.orig/feholdexcpt.c glibc-2.3.5/sysdeps/hppa/fpu/feholdexcpt.c --- glibc-2.3.5/sysdeps/hppa/fpu.orig/feholdexcpt.c 2006-01-14 10:17:19.0 -0800 +++ glibc-2.3.5/sysdeps/hppa/fpu/feholdexcpt.c 2006-01-14 10:20:21.0 -0800 @@ -30,10 +30,7 @@ /* Store the environment. */ bufptr = clear.buf; __asm__ ( - fstd,ma %%fr0,8(%1)\n - fstd,ma %%fr1,8(%1)\n - fstd,ma %%fr2,8(%1)\n - fstd %%fr3,0(%1)\n + fstd %%fr0,0(%1)\n : =m (clear), +r (bufptr)); memcpy (envp, clear.env, sizeof (fenv_t)); @@ -47,10 +44,7 @@ /* Load the new environment. */ bufptr = clear.buf; __asm__ ( - fldd,ma 8(%0),%%fr0\n - fldd,ma 8(%0),%%fr1\n - fldd,ma 8(%0),%%fr2\n - fldd 0(%0),%%fr3\n + fldd 0(%0),%%fr0\n : : r (bufptr), m (clear)); return 0; diff -uNr glibc-2.3.5/sysdeps/hppa/fpu.orig/fesetenv.c glibc-2.3.5/sysdeps/hppa/fpu/fesetenv.c --- glibc-2.3.5/sysdeps/hppa/fpu.orig/fesetenv.c2006-01-14 10:17:19.0 -0800 +++ glibc-2.3.5/sysdeps/hppa/fpu/fesetenv.c 2006-01-14 10:20:44.0 -0800 @@ -34,10 +34,7 @@ we want to use from the environment specified by the parameter. */ bufptr = temp.buf; __asm__ ( - fstd,ma %%fr0,8(%1)\n - fstd,ma %%fr1,8(%1)\n - fstd,ma %%fr2,8(%1)\n - fstd %%fr3,0(%1)\n + fstd %%fr0,0(%1)\n : =m (temp), +r (bufptr)); temp.env.__status_word = ~(FE_ALL_EXCEPT @@ -56,9 +53,6 @@ /* Load the new environment. */ bufptr = temp.buf; __asm__ ( - fldd,ma -8(%1),%%fr3\n - fldd,ma -8(%1),%%fr2\n - fldd,ma -8(%1),%%fr1\n fldd 0(%1),%%fr0\n : =m (temp), +r (bufptr));
Bug#341174: boost FTBFS on hppa
Try adding that flag (-ffunction-sections) to the gcc compile flags for hppa. i just finished to re-check the build with this option. unfortunately it still fails. the log is at http://people.debian.org/~cavok/boost_1.33.0-5_hppa.build. Sigh, thanks for trying. I was going to try it but then it took so long to build... ;-) I notice you have some files built with -O0 and some with -O3. Any particular reason? Do you know if boost has some functions in it that are very very big? (perhaps machine generated?) Doesn't look like it... Can you also try with -mlong-calls (instead of -ffunction-sections) These are obviously all workarounds until we fix the real problem. randolph -- Randolph Chung Debian GNU/Linux Developer, hppa/ia64 ports http://www.tausq.org/ -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Bug#341174: boost FTBFS on hppa
Is anyone looking into this problem with building boost on hppa? As there are quite a few packages which build-depend on boost (including parts of KDE, and aptitude), this is likely to cause hppa to hold up the c2a transition unless some progress is made here. i'm seeing.. i tried some builds on paer.d.o, to see how new compilers/linkers behavaed with respect to this. maybe latest binutils 2.16.1cvs20051214-1 fixes this... i'm not doing more, sorry. This is a bug in gcc, but while it is being debugged some more, the toolchain actually suggested a workaround for you: /usr/bin/ld: [...] cannot reach 0aae__ZSt10_ConstructIN5boost7archive6detail19basic_iarchive_impl7aobjectES4_EvPT_RKT0_+0, recompile with -ffunction-sections Try adding that flag (-ffunction-sections) to the gcc compile flags for hppa. The problem is that a branch instruction on hppa has limited range (17-bits), so if the branch target is too large (this happens often with large problems, especially c++ code with lots of templates), the toolchain needs to add special stubs for far branches. gcc has logic to figure this out, but sometimes its calculations do not match what binutils calculates. randolph -- Randolph Chung Debian GNU/Linux Developer, hppa/ia64 ports http://www.tausq.org/ -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Bug#340298: www.debian.org/ports unclear about ia64
Without further any warning/information about that other 64bit architecture intel, amd etc are producing: amd64. A *lot* of people try to use ia64 installation media to install Debian on their Opteron's etc, and then mail (for example) debian-cd that the cd is broken and doesn't boot. I am not disputing that the wording can be improved, but please note: The paragraph in question could and IMHO should be more elaborate, like, saying it's Intel *alpha* 64, aka Itanium, What is Intel alpha 64? I've never heard of such a thing :-) ia64 != Itanium, just as Linux != RedHat. The fact that i386 is also called ia32 above, without any introduction to what ia32 means, isn't helping at all of course. If it doesn't serve anything, I strongly suggest to drop the name of 'ia-32', I've never heard of it before, while eh, I've been an i386 users for quite some time. Well, ia32 is a very common name. http://en.wikipedia.org/wiki/IA-32 randolph -- Randolph Chung Debian GNU/Linux Developer, hppa/ia64 ports http://www.tausq.org/ -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Bug#333766: libc6: SIGBUS in libm on hppa breaks qt-x11-free
I don't think that's what is happening at all: I think that in one of these cases, your test file's on-stack fenv_t is aligned, and on the other it isn't. The code you posted for gcc 4.0 looks fine. I think the assembly is broken or the definition of fenv_t. drow is right, as usual. our fenv_t needs to be defined with __attribute__((aligned(8))) or similar. randolph -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Bug#321785: fakeroot: segfaults on [hppa]
Well, sarge also shipped as 2.6-only, for hppa; so if the answer is that this problem happens to go away when upgrading to 2.6, that's probably acceptable, since 2.4 kernels will have been unsupported on hppa for a full stable release by the time etch comes out. It doesn't go away with 2.6. randolph -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Bug#321785: fakeroot: segfaults on [hppa]
(I trimmed the cc list a bit) Dave, Could this actually be a gcc problem? Take a look at this: (gdb) bt #0 0x406dbd20 in __canonicalize_funcptr_for_compare () from /usr/lib/debug/libpthread.so.0 #1 0x406d7424 in __pthread_sigaction (sig=18, act=0xc0241ec8, oact=0xc0241f50) at signals.c:106 #2 0x4035f950 in *__GI___sigaction (sig=value optimized out, act=value optimized out, oact=value optimized out) at ../linuxthreads/sysdeps/pthread/sigaction.c:42 #3 0x4035f748 in __bsd_signal (sig=18, [EMAIL PROTECTED]: 0x42410 __gmon_start__+92828) at signal.c:47 #4 0x0001d690 in main () (gdb) frame 1 #1 0x406d7424 in __pthread_sigaction (sig=18, act=0xc0241ec8, oact=0xc0241f50) at signals.c:106 106 if (old == SIG_IGN || old == SIG_DFL || old == SIG_ERR) (gdb) print old Address requested for identifier old which is in register $r11 (gdb) print /x $r11 $6 = 0x0 (gdb) print /x $pc $7 = 0x406d7424 (gdb) disassemble $pc-16 $pc+4 Dump of assembler code from 0x406d7414 to 0x406d7428: 0x406d7414 __pthread_sigaction+252: stw r20,-138(,sp) 0x406d7418 __pthread_sigaction+256: copy r19,r4 0x406d741c __pthread_sigaction+260: b,l 0x406dbcd8 __canonicalize_funcptr_for_compare,rp 0x406d7420 __pthread_sigaction+264: ldo -2(r11),r26 0x406d7424 __pthread_sigaction+268: copy r4,r19 End of assembler dump. (gdb) Why is it doing that ldo -2(r11),r26 ? I think this version of glibc is built with gcc-4.0 randolph -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Bug#321785: fakeroot: segfaults on [hppa]
I would have thought that old (r11) would have just been copied to r26. Could you send preprocessed source and compilation details? This is now filed as http://gcc.gnu.org/bugzilla/show_bug.cgi?id=23369 I have reassigned the fakeroot bug to gcc-4.0 and marked it up accordingly. randolph -- Randolph Chung Debian GNU/Linux Developer, hppa/ia64 ports http://www.tausq.org/ -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Bug#321785: fakeroot: segfaults on [hppa]
Confirmed. We are passing a function pointer with a value of -2 into __cffc, which should not happen... Is -2 a special signal number? I don't think so. in any case, others have observed that if they use an older glibc, this problem does not happen. randolph -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Bug#321785: fakeroot: segfaults on [hppa]
no, it's not fakeroot, it's make segfaulting ... [...] Program received signal SIGSEGV, Segmentation fault. [Switching to Thread 16384 (LWP 16911)] 0x4091fd20 in __canonicalize_funcptr_for_compare () from /lib/libpthread.so.0 (gdb) bt #0 0x4091fd20 in __canonicalize_funcptr_for_compare () from /lib/libpthread.so.0 #1 0x4091b424 in sigaction () from /lib/libpthread.so.0 #2 0x405cc950 in sigaction () from /lib/libc.so.6 #3 0x405cc748 in ssignal () from /lib/libc.so.6 #4 0x0001d690 in main () (gdb) Confirmed. We are passing a function pointer with a value of -2 into __cffc, which should not happen... This code is a bit fragile wrt to glibc's and the toolchain's idea of the GOT layout and function pointer initialization. Carlos and Dave might have a better idea of what is happening :) I've copied Dave and Carlos in case they don't read these lists. Dave and Carlos, this is a problem with the new glibc in Debian unstable. looks like any app that links libpthread will segfault. randolph -- Randolph Chung Debian GNU/Linux Developer, hppa/ia64 ports http://www.tausq.org/ -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Bug#286038: [patch] fix mozilla-firefox for hppa
tag 286038 +patch thanks Here's a patch that fixes mozilla-firefox on hppa. Originally contributed by Ivar. (http://lists.parisc-linux.org/pipermail/parisc-linux/2004-December/025419.html) With fixes for Debian (Makefile.in) by myself. The patch needs some work to be more robust, but it works... randolph diff -uNrp mozilla-firefox-1.0.1/xpcom/reflect/xptcall/src/md/unix/Makefile.in mozilla-firefox-1.0.1-new/xpcom/reflect/xptcall/src/md/unix/Makefile.in --- mozilla-firefox-1.0.1/xpcom/reflect/xptcall/src/md/unix/Makefile.in 2005-03-21 18:11:01.0 -0800 +++ mozilla-firefox-1.0.1-new/xpcom/reflect/xptcall/src/md/unix/Makefile.in 2005-03-21 05:34:27.0 -0800 @@ -167,6 +167,20 @@ CXXFLAGS := $(filter-out $(MOZ_OPTIMIZ endif endif +# +# Linux/HPPA/GCC +# +ifeq ($(OS_ARCH),Linux) +ifneq (,$(filter parisc parisc64,$(OS_TEST))) +ifeq ($(CC),gcc) +CPPSRCS:= xptcinvoke_pa32.cpp xptcstubs_pa32.cpp +ASFILES:= xptcstubs_asm_parisc_linux.s xptcinvoke_asm_parisc_linux.s +CXXFLAGS += -O0 +endif +endif +endif + + ## # M68k ## diff -uNrp mozilla-firefox-1.0.1/xpcom/reflect/xptcall/src/md/unix/xptcinvoke_asm_parisc_linux.s mozilla-firefox-1.0.1-new/xpcom/reflect/xptcall/src/md/unix/xptcinvoke_asm_parisc_linux.s --- mozilla-firefox-1.0.1/xpcom/reflect/xptcall/src/md/unix/xptcinvoke_asm_parisc_linux.s 1969-12-31 16:00:00.0 -0800 +++ mozilla-firefox-1.0.1-new/xpcom/reflect/xptcall/src/md/unix/xptcinvoke_asm_parisc_linux.s 2005-03-20 06:27:53.0 -0800 @@ -0,0 +1,128 @@ + + .LEVEL 1.1 + .text + .align 4 + +framesz: + .equ 128 + +; XPTC_InvokeByIndex(nsISuppots* that, PRUint32 methodIndex, +; PRUint32 paramCount, nsXPTCVariant* params); + +.globl XPTC_InvokeByIndex + .type XPTC_InvokeByIndex, @function + + +XPTC_InvokeByIndex: + .PROC + .CALLINFO FRAME=72, CALLER,SAVE_RP, SAVE_SP, ENTRY_GR=3 + .ENTRY + + ; frame marker takes 48 bytes, + ; register spill area takes 8 bytes, + ; local stack area takes 72 bytes result in 128 bytes total + +STW %rp,-20(%sp) +STW,MA %r3,128(%sp) + +LDO -framesz(%r30),%r28 +STW %r28,-4(%r30) ; save previous sp +STW %r19,-32(%r30) + +STW %r26,-36-framesz(%r30) ; save argument registers in +STW %r25,-40-framesz(%r30) ; in PREVIOUS frame +STW %r24,-44-framesz(%r30) ; +STW %r23,-48-framesz(%r30) ; + +; B,L .+8,%r2 +; ADDIL L'invoke_count_bytes-$PIC_pcrel$1+4,%r2,%r1 +;;LDO R'invoke_count_bytes-$PIC_pcrel$2+8(%r1),%r1 +;$PIC_pcrel$1 +;LDSID (%r1),%r31 +;$PIC_pcrel$2 +;MTSP%r31,%sr0 + + .CALL ARGW0=GR,ARGW1=GR,ARGW2=GR ;in=24,25,26;out=28 +BLinvoke_count_bytes,%r31 +COPY%r31,%r2 + +CMPIB,=0,%r28, .+76 +COPY%r30,%r3; copy stack ptr to saved stack ptr +ADD %r30,%r28,%r30 ; extend stack frame +LDW -4(%r3),%r28; move frame +STW %r28,-4(%r30) +LDW -8(%r3),%r28 +STW %r28,-8(%r30) +LDW -12(%r3),%r28 +STW %r28,-12(%r30) +LDW -16(%r3),%r28 +STW %r28,-16(%r30) +LDW -20(%r3),%r28 +STW %r28,-20(%r30) +LDW -24(%r3),%r28 +STW %r28,-24(%r30) +LDW -28(%r3),%r28 +STW %r28,-28(%r30) +LDW -32(%r3),%r28 +STW %r28,-32(%r30) + +LDO -40(%r30),%r26 ; load copy address +LDW -44-framesz(%r3),%r25 ; load rest of 2 arguments +LDW -48-framesz(%r3),%r24 ; + +LDW -32(%r30),%r19 ; shared lib call destroys r19; reload +;B,L .+8,%r2 +;ADDIL L'invoke_copy_to_stack-$PIC_pcrel$3+4,%r2,%r1 +;LDO R'invoke_copy_to_stack-$PIC_pcrel$4+8(%r1),%r1 +;$PIC_pcrel$3 +;LDSID (%r1),%r31 +;$PIC_pcrel$4 +;MTSP%r31,%sr0 +.CALL ARGW0=GR,ARGW1=GR,ARGW2=GR ;in=24,25,26 +BLinvoke_copy_to_stack,%r31 +COPY%r31,%r2 + +LDO -48(%r30),%r20 +EXTRW,U,= %r28,31,1,%r22 +FLDD0(%r20),%fr7 ; load double arg 1 +EXTRW,U,= %r28,30,1,%r22 +FLDW8(%r20),%fr5L ; load float arg 1 +EXTRW,U,= %r28,29,1,%r22 +FLDW4(%r20),%fr6L ; load float arg 2 +EXTRW,U,= %r28,28,1,%r22 +FLDW0(%r20),%fr7L ; load float arg 3 + +LDW -36-framesz(%r3),%r26 ; load ptr to 'that' +LDW -40(%r30),%r25 ; load the rest of dispatch argument registers +LDW -44(%r30),%r24 +LDW -48(%r30),%r23 + +LDW -36-framesz(%r3),%r20 ; load vtable addr +LDW -40-framesz(%r3),%r28 ;
Bug#292274: Installation report: problems with grub-installer
Package: installation-reports INSTALL REPORT Debian-installer-version: ~2005-01-11, +- 1 week uname -a: Linux mailhub 2.6.8-2-686 #1 Sat Jan 8 16:50:08 EST 2005 i686 GNU/Linux Date: 2005-01-25 Method: network install, using mirror.pacific.net.au, no proxy Machine: Dell Dimension 4700 Processor: Intel(R) Pentium(R) 4 CPU 3.20GHz Memory: 1GB Root Device: SATA (WDC WD800JD-75JN) x 2 (raid-1) Root Size/partition table: Feel free to paste the full partition table, with notes on which partitions are mounted where. /dev/sda1 1 31 248976 82 Linux swap /dev/sda2 * 32972677875087+ fd Linux raid autodetect /dev/sdb1 1 31 248976 82 Linux swap /dev/sdb2 * 32972677875087+ fd Linux raid autodetect sda2+sdb2 are configured for raid-1 and mounted as / Output of lspci and lspci -n: :00:00.0 Host bridge: Intel Corp. 915G/P/GV Processor to I/O Controller (rev 04) :00:01.0 PCI bridge: Intel Corp. 915G/P/GV PCI Express Root Port (rev 04) :00:02.0 VGA compatible controller: Intel Corp. 82915G Express Chipset Family Graphics Controller (rev 04) :00:02.1 Display controller: Intel Corp. 82915G Express Chipset Family Graphics Controller (rev 04) :00:1c.0 PCI bridge: Intel Corp. 82801FB/FBM/FR/FW/FRW (ICH6 Family) PCI Express Port 1 (rev 03) :00:1d.0 USB Controller: Intel Corp. 82801FB/FBM/FR/FW/FRW (ICH6 Family) USB UHCI #1 (rev 03) :00:1d.1 USB Controller: Intel Corp. 82801FB/FBM/FR/FW/FRW (ICH6 Family) USB UHCI #2 (rev 03) :00:1d.2 USB Controller: Intel Corp. 82801FB/FBM/FR/FW/FRW (ICH6 Family) USB UHCI #3 (rev 03) :00:1d.3 USB Controller: Intel Corp. 82801FB/FBM/FR/FW/FRW (ICH6 Family) USB UHCI #4 (rev 03) :00:1d.7 USB Controller: Intel Corp. 82801FB/FBM/FR/FW/FRW (ICH6 Family) USB2 EHCI Controller (rev 03) :00:1e.0 PCI bridge: Intel Corp. 82801 PCI Bridge (rev d3) :00:1e.2 Multimedia audio controller: Intel Corp. 82801FB/FBM/FR/FW/FRW (ICH6 Family) AC'97 Audio Controller (rev 03) :00:1f.0 ISA bridge: Intel Corp. 82801FB/FR (ICH6/ICH6R) LPC Interface Bridge (rev 03) :00:1f.1 IDE interface: Intel Corp. 82801FB/FBM/FR/FW/FRW (ICH6 Family) IDE Controller (rev 03) :00:1f.2 IDE interface: Intel Corp. 82801FB/FW (ICH6/ICH6W) SATA Controller (rev 03) :00:1f.3 SMBus: Intel Corp. 82801FB/FBM/FR/FW/FRW (ICH6 Family) SMBus Controller (rev 03) :03:08.0 Ethernet controller: Intel Corp.: Unknown device 1064 (rev 03) :00:00.0 0600: 8086:2580 (rev 04) :00:01.0 0604: 8086:2581 (rev 04) :00:02.0 0300: 8086:2582 (rev 04) :00:02.1 0380: 8086:2782 (rev 04) :00:1c.0 0604: 8086:2660 (rev 03) :00:1d.0 0c03: 8086:2658 (rev 03) :00:1d.1 0c03: 8086:2659 (rev 03) :00:1d.2 0c03: 8086:265a (rev 03) :00:1d.3 0c03: 8086:265b (rev 03) :00:1d.7 0c03: 8086:265c (rev 03) :00:1e.0 0604: 8086:244e (rev d3) :00:1e.2 0401: 8086:266e (rev 03) :00:1f.0 0601: 8086:2640 (rev 03) :00:1f.1 0101: 8086:266f (rev 03) :00:1f.2 0101: 8086:2651 (rev 03) :00:1f.3 0c05: 8086:266a (rev 03) :03:08.0 0200: 8086:1064 (rev 03) Base System Installation Checklist: [O] = OK, [E] = Error (please elaborate below), [ ] = didn't try it Initial boot worked:[O] Configure network HW: [O] Config network: [O] Detect CD: [ ] Load installer modules: [O] Detect hard drives: [O] Partition hard drives: [O] Create file systems:[O] Mount partitions: [O] Install base system:[O] Install boot loader:[O] Reboot: [E] Comments/Problems: Install worked great; the raid-1 configuration was a snap :) The only problem I ran into was that my / was mounted as the 2nd partition, and grub-installer installed grub using (hd0,0) as the boot partition. manually changing that to (hd0,1) made everything work again. -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
