Re: kldload: Unsupported file type
On Wed, 30 Jan 2008, Bruce M Simpson wrote: > Since updating to 6.3-RELEASE on two machines I see this message a > lot. Hooray I am not alone! I have a thread in stable called ' kldstat causes kernel to print odd message' (not the best subject since it's wrong AND undescriptive), message ID is [EMAIL PROTECTED] > It is printed whenever a kernel module is loaded. > The modules load OK. Nothing special or different about them. > > It seems to be harmless, but any idea why it's started happening > since the release? It is printed by sys/kern/link_elf.c - amd64 uses this for historical reasons. The issue is that it is being called before the stuff in link_elf_obj.c and printing an error, the kernel then tries _obj and it works. I tried #ifdef'ing out link_elf.c but it panicd my machine on boot and I haven't had time to find out why. The good news is that it's a purely cosmetic problem. -- Daniel O'Connor software and network engineer for Genesis Software - http://www.gsoft.com.au "The nice thing about standards is that there are so many of them to choose from." -- Andrew Tanenbaum GPG Fingerprint - 5596 B766 97C0 0E94 4347 295E E593 DC20 7B3F CE8C signature.asc Description: This is a digitally signed message part.
panic in sio(4)
Hi, All. There is a guy which have a repeatable panic in the sio(4). http://www.opennet.ru/openforum/vsluhforumID1/78445.html#9 Most interesting part of backtrace is: #5 0xc08860ba in calltrap () at /usr/src/sys/i386/i386/exception.s:139 No locals. #6 0xc0873700 in siointr1 (com=0xc3411400) at /usr/src/sys/dev/sio/sio.c:1613 ocount = 4287153708 int_ctl = 0 '\0' int_ctl_new = 0 '\0' line_status = 44 ',' modem_status = 0 '\0' ioptr = (u_char *) 0xc3b85000 recv_data = 69 'E' #7 0xc0873322 in siointr (arg=0xc3411400) at /usr/src/sys/dev/sio/sio.c:1391 com = (struct com_s *) 0xc3411400 #8 0xc0889e95 in intr_execute_handlers (isrc=0xc32b48c8, iframe=0xd4032c94) at /usr/src/sys/i386/i386/intr_machdep.c:270 td = (struct thread *) 0xc3284600 ie = (struct intr_event *) 0xc32cab00 ih = (struct intr_handler *) 0xc33f3840 vector = -1019267008 thread = 0 As i see there is no difference between 6.2 and 6.3 in the sio(4). Can someone help to fix this panic? -- WBR, Andrey V. Elsukov ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to "[EMAIL PROTECTED]"
kldload: Unsupported file type
Since updating to 6.3-RELEASE on two machines I see this message a lot. It is printed whenever a kernel module is loaded. The modules load OK. Nothing special or different about them. It seems to be harmless, but any idea why it's started happening since the release? Cheers BMS ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to "[EMAIL PROTECTED]"
PINJAMAN TANPA AGUNAN 8-125 JT..GRATIS..TANPA PROVISI/ADM 3%..dr HSBC
DAPATKAN PINJAMAN TANPA AGUNAN DENGAN PERSYARATAN YANG MUDAH,PROSES YANG CEPAT, DAN FASILTAS BERUPA BEBAS PROVISI/ADM 3% UNTUK PINJAMAN 15.000.000 - 19.000.000 DENGAN TENOR/MASA PELUNASAN 24 BULAN DAN PINJAMAN >=20.000.000,- DENGAN TENOR 36 BULAN. PROSES VERIFIKASI HINGGA PENCAIRAN 5-7 HARI KERJA. dr HSBC DOCUMENT YANG DIBUTUHKAN : 1.FC KTP 2.FC.CREDIT CARD DAN BILLING 1 BULAN TERAKHIR 3.FC.NO REK.TABUNGAN(SEBAGAI TEMPAT TRANSFER BILA DI SETUJUI) 4.MATERAI Rp.6.000,- 1 BH. 5.FC.NPWP (untuk pinjaman diatas Rp.50 juta ) UTK KETERANGAN HUB: UMAR 0813-19288679 0859-21346503 or [EMAIL PROTECTED] PERHITUNGAN BUNGA/BULAN TENOR Jml.Pinjaman12 bulan 24 bulan 36 bulan 8.000.000 - 14.999.999 2 %. 2 %. - 15.000.000 - 125.000.000 1.72% 1.80 %.1.95 %. TABEL ANGSURAN PINJAMAN1 TAHUN 2 TAHUN 3 TAHUN 8,000,000 826,667493,333 - 9,000,000 930,000555,000 - 10,000,000 1,033,334616,666 - 10,500,000 1,085,000647,500 - 11,000,000 1,136,667678,333 - 12,000,000 1,240,001740,000 - 13,000,000 1,343,334801,666 - 14,000,000 1,446,667863,333 - 15,000,000 1,508,000895,000 709,167 16,000,000 1,608,533954,667 756,445 17,000,000 1,709,067 1,014,333 803,723 18,000,000 1,809,600 1,074,000 851,000 19,000,000 1,910,133 1,133,667 898,278 20,000,000 2,010,667 1,193,333 945,556 21,000,000 2,111,200 1,253,000 992,834 22,000,000 2,211,733 1,312,667 1,040,112 23,000,000 2,312,267 1,372,333 1,087,389 24,000,000 2,412,800 1,432,000 1,134,667 25,000,000 2,513,333 1,491,667 1,181,945 26,000,000 2,613,867 1,551,333 1,229,223 27,000,000 2,714,400 1,611,000 1,276,501 28,000,000 2,814,933 1,670,667 1,323,778 29,000,000 2,915,467 1,730,333 1,371,056 30,000,000 3,016,000 1,790,000 1,418,334 31,000,000 3,116,533 1,849,667 1,465,612 32,000,000 3,217,067 1,909,333 1,512,890 33,000,000 3,317,600 1,969,000 1,560,167 34,000,000 3,418,133 2,028,667 1,607,445 35,000,000 3,518,667 2,088,333 1,654,723 36,000,000 3,619,200 2,148,000 1,702,001 37,000,000 3,719,733 2,207,667 1,749,279 38,000,000 3,820,267 2,267,333 1,796,556 39,000,000 3,920,800 2,327,000 1,843,834 40,000,000 4,021,333 2,386,667 1,891,112 41,000,000 4,121,867 2,446,333 1,938,390 42,000,000 4,222,400 2,506,000 1,985,668 43,000,000 4,322,933 2,565,667 2,032,945 44,000,000 4,423,467 2,625,333 2,080,223 45,000,000 4,524,000 2,685,000 2,127,501 46,000,000 4,624,533 2,744,667 2,174,779 47,000,000 4,725,067 2,804,333 2,222,057 48,000,000 4,825,600 2,864,000 2,269,334 49,000,000 4,926,133 2,923,667 2,316,612 50,000,000 5,026,667 2,983,333 2,363,890 55,000,000 5,529,333 3,281,667 2,600,279
Re: /usr/bin/objformat is missing
Chris H. wrote: [snip] While it didn't fix my seeming php5 module number limitation. I was able, after trial and error, to discover that the recode module was the module causing Apache to dump core. Simply removing it from the list cured it. :) Further investigation reveals that there are some issues with with recode versions greater than 3.5. PHP recommends using 3.5. But, as I already use iconv, and mbstring, using recode is kind of overkill anyway. So forget it. :) [snip] I've had my fair share of trouble regarding PHP4 and PHP5 crashing Apache with certain extensions, as documented here: http://www.pingle.org/2006/10/18/php-crashes-extensions/ Here: http://www.pingle.org/2007/05/13/php-crashes-extensions-2/ and here: http://www.pingle.org/2007/09/22/php-crashes-extensions-workaround/ It happens with PHP4, PHP5, Apache 1.x and Apache 2.x. My workaround is a hackish script that reorders the problematic extensions to the end of extension.ini, and in a specific order. It Works For Me, but YMMV. I'm glad you were able to get around the problem by simply disabling an extension, but some of us aren't so lucky :) Jim ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to "[EMAIL PROTECTED]"
7-stable dynamic libraries perhaps more agressive than 6 ?
Just asking this below out of interest (no insurmountable problem): Is 7-stable dynamic executable scheme a little more demanding than 6 ? I've been upgrading machines for some years with fairly careful sequences of `mv' of trees pre positioned within same FS (to avoid eg link breaks within /rescue & du explosion etc) & havent been caught for years on shared libs, yet just been caught on 2 boxes, moving from 7.0-RC1 to 7-Stable. (I know below is not the official way but I had slow target hosts & all bins precompiled from another host & ftp'd.) Rest of post is a log illustrating 2 lines marked *** puzzling me. & 2 lines === of work round. ( /ST holds my new stable bins compiled on another box /7R1 the older 7.0-RC1 bins from cdrom ) cp `which mv` /mv pwd /ST foreach i ( * ) foreach? /mv /$i /7R1/$i foreach? /mv $i /$i foreach? echo done $i foreach? end done bin done boot ***/libexec/ld-elf.so.1: Shared object "libc.so.7" not found, required by "mv" done lib /libexec/ld-elf.so.1: Shared object "libc.so.7" not found, required by "mv" /libexec/ld-elf.so.1: Shared object "libc.so.7" not found, required by "mv" done libexec /libexec/ld-elf.so.1: Shared object "libc.so.7" not found, required by "mv" /libexec/ld-elf.so.1: Shared object "libc.so.7" not found, required by "mv" done sbin # Suprising, used to have no problem pre 7 with Static mv. cd /ST ls lib libexec sbin ls /7R1 bin bootlib ldd /bin/mv *** ldd: /bin/mv: not a dynamic executable # as expected # But why did /mv complain ? maybe 'cos it exec'd a cp # for a directory & cp is not static, but didn't used to error. file `which ln` /bin/ln: ELF 32-bit LSB executable, Intel 80386, version 1 (FreeBSD), for FreeBSD 7.0 (700100), statically linked, FreeBSD-style, stripped file `which cp` /bin/cp: ELF 32-bit LSB executable, Intel 80386, version 1 (FreeBSD), for FreeBSD 7.0 (700100), statically linked, FreeBSD-style, stripped file `which ldconfig` ldconfig -v -R /libexec/ld-elf.so.1: Shared object "libc.so.7" not found, required by "ldconfig" # I'd been thinking of setenv LD_LIBRARY_PATH ===setenv LD_LIBRARY_PATH /lib:/7R1/lib:/ST/lib:/usr/lib:/usr/local/lib ===ldconfig -R /7R1/lib /ST/lib /mv /etc.lapd /etc.lapd2 ; /mv /etc.lapd2 /etc.lapd # Shows one of the above now makes /mv work again. pwd /ST ls lib libexec sbin ls /7R1 bin bootlib ls /lib ls: /lib: No such file or directory /mv lib /lib ls libexec sbin /mv /sbin /7R1/ /mv sbin /sbin /mv /libexec /7R1/ mv libexec / # whoops, I forgot / befor mv but OK Julian -- Julian Stacey. Munich Consultant: BSD Linux Unix. http://berklix.com ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to "[EMAIL PROTECTED]"
Re: snd_emu10k1.ko after 6.2 to 6.3 upgrade
On Tuesday 29 January 2008 02:26:27 am Petr Holub wrote: > > What does 'nm /boot/kernel/sound.ko | grep midi' show? > > sound.ko seems to be OK as it was properly updated by > freebsd-update: > > [EMAIL PROTECTED] ~]# ls -l /boot/kernel/sound.ko > -r-xr-xr-x 1 root wheel 139075 Jan 21 15:42 /boot/kernel/sound.ko > [EMAIL PROTECTED] ~]# sha256 /boot/kernel/sound.ko > SHA256 (/boot/kernel/sound.ko) = > a61572cc74e3b00088a824765d7291c91d4ff52fe8709aa77abcade626fbece8 > [EMAIL PROTECTED] ~]# nm /boot/kernel/sound.ko | grep midi > > snd_emu10k1.ko however was not updated for some reason > and it has some dependencies: > > [EMAIL PROTECTED] ~]# ls -l /boot/kernel/snd_emu10k1.ko > -r-xr-xr-x 1 root wheel 30008 Feb 20 2007 /boot/kernel/snd_emu10k1.ko > [EMAIL PROTECTED] ~]# sha256 /boot/kernel/snd_emu10k1.ko > SHA256 (/boot/kernel/snd_emu10k1.ko) = > 13a0e7f03d354f57517d17ea52b5c7fa5a3c153cefcbf2cf8831d91204f0b2a3 > [EMAIL PROTECTED] ~]# nm /boot/kernel/snd_emu10k1.ko | grep midi > 4a04 r __set_modmetadata_set_sym__mod_metadata_md_snd_emu10k1_on_midi > 5090 d _mod_metadata_md_snd_emu10k1_on_midi > 50a0 d _snd_emu10k1_depend_on_midi > > When I compile new GENERIC-based snd_emu10k1.ko, it shows no > such depends: > > [EMAIL PROTECTED] ~]# nm > /sys/i386/compile/GENERIC/modules/usr/src/sys/modules/sou > nd/driver/emu10k1/snd_emu10k1.ko | grep midi On my current box I get this: > nm /boot/kernel.GENERIC/snd_emu10kx.ko | grep midi 00010adc r __set_modmetadata_set_sym__mod_metadata_md_snd_emu10kx_midi_emu10kx 00010ad8 r __set_modmetadata_set_sym__mod_metadata_md_snd_emu10kx_midi_on_snd_emu10kx 00010ad4 r __set_modmetadata_set_sym__mod_metadata_md_snd_emu10kx_midi_on_sound 00010ad0 r __set_modmetadata_set_sym__mod_metadata_snd_emu10kx_midi_version 00010aec r __set_sysinit_set_sym_snd_emu10kx_midi_emu10kxmodule_sys_init 00011db8 d _mod_metadata_md_snd_emu10kx_midi_emu10kx 00011d98 d _mod_metadata_md_snd_emu10kx_midi_on_snd_emu10kx 00011d88 d _mod_metadata_md_snd_emu10kx_midi_on_sound 00011d78 d _mod_metadata_snd_emu10kx_midi_version 00011e10 d _snd_emu10kx_midi_depend_on_snd_emu10kx 00011e04 d _snd_emu10kx_midi_depend_on_sound 00011e00 d _snd_emu10kx_midi_version f0e0 t emu_midi_attach f320 t emu_midi_card_intr f090 t emu_midi_detach 00011f08 b emu_midi_devclass 00011e3c d emu_midi_driver f3a0 t emu_midi_intr 00011e60 d emu_midi_methods f3c0 t emu_midi_probe 00011e28 d snd_emu10kx_midi_emu10kx_driver_mod 00011e1c d snd_emu10kx_midi_emu10kx_mod 00011da8 d snd_emu10kx_midi_emu10kxmodule_sys_init and this: > nm /boot/kernel.GENERIC/sound.ko | grep midi 0003f7ec r __set_modmetadata_set_sym__mod_metadata_md_midi 0003f7e8 r __set_modmetadata_set_sym__mod_metadata_midi_version 0003f7d4 r __set_sysctl_set_sym_sysctl___hw_midi 0003f7cc r __set_sysctl_set_sym_sysctl___hw_midi_debug 0003f7c8 r __set_sysctl_set_sym_sysctl___hw_midi_dumpraw 0003f7c4 r __set_sysctl_set_sym_sysctl___hw_midi_instroff 0003f7dc r __set_sysctl_set_sym_sysctl___hw_midi_seq 0003f7d8 r __set_sysctl_set_sym_sysctl___hw_midi_seq_debug 0003f7d0 r __set_sysctl_set_sym_sysctl___hw_midi_stat 0003f7c0 r __set_sysctl_set_sym_sysctl___hw_midi_stat_verbose 0003f77c r __set_sysinit_set_sym_midimodule_sys_init 0004560c d _midi_version 00045470 d _mod_metadata_md_midi 00045450 d _mod_metadata_midi_version 00045380 d midi_cdevsw 00035800 t midi_close 000367c0 T midi_cmdname 00046c30 B midi_debug 00033dc0 t midi_destroy 00046c20 B midi_devs 00046c34 B midi_dumpraw 00034880 T midi_in 00034b20 T midi_init 00046c38 B midi_instroff 000334e0 t midi_ioctl 00045610 d midi_mod 00033f70 t midi_modevent 00035200 t midi_open 000345b0 T midi_out 000350f0 t midi_poll 00034130 t midi_read 000344a0 T midi_uninit 000353f0 t midi_write 00033500 T midimapper_addseq 00033510 T midimapper_close 00033520 T midimapper_fetch_synth 000335d0 T midimapper_open 00045460 d midimodule_sys_init 00046c70 b midistat_bufptr 00045300 d midistat_cdevsw 000337a0 t midistat_close 00046c74 b midistat_dev 00046c40 b midistat_isopen 00046c44 b midistat_lock 00033850 t midistat_open 00033650 t midistat_read 00046c5c b midistat_sbuf 00046c3c B midistat_verbose 000334f0 t midisynth_alloc 00035df0 t midisynth_bender 000452e4 D midisynth_class 00035ff0 t midisynth_close 00035e50 t midisynth_controller 00035f70 t midisynth_killnote 00045400 d midisynth_methods 00033bc0 t midisynth_open 00035f20 t midisynth_setinstr 00035eb0 t midisynth_startnote 000359d0 t midisynth_writeraw 000455c0 d sysctl___hw_midi 00045540 d sysctl___hw_midi_debug 00045500 d sysctl___hw_midi_dumpraw 000454c0 d sysctl___hw_midi_instroff 00045a40 d sysctl___hw_midi_seq 00045a00 d sysctl___hw_midi_seq_debug 00045580 d sysctl___hw_midi_stat 00045480 d sysctl___hw_midi_stat_verbose 00046c28 B sysctl__hw_midi_children 00046c80 B sysctl__hw_midi_seq_children 00046c2c B sysctl__hw_midi_stat_children Granted, GENERIC on head is built with debug options so more symbols might show up, but you should have m
Kernel panic on 7-PRERELEASE
Hi, Like on 6.x, I'm seeing frequent kernel panics when using my bge NICs. If I plug the cable into the fxp NIC all is fine. Dual opteron, Tyan K8S Pro (2882) board. I cannot see any pattern as to what is causing the panics, however I have obtained kernel dumps on a freshly built kernel (with -g), unfortunately without WITNESS or INVARIANTS. I've attached a screenshot of the KVM console after the crash. Given that I have a kernel dump, what do I do to extract useful information, if at all possible? Thanks! /Eirik ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to "[EMAIL PROTECTED]"
Re: zfs problems
On 1/29/08, ZsUM ZsUM <[EMAIL PROTECTED]> wrote: > *Dump header from device /dev/ad4s1b > Architecture: amd64 > Architecture Version: 2 > Dump Length: 253394944B (241 MB) > Blocksize: 512 > Dumptime: Sun Jan 20 23:51:58 2008 > Hostname: > Magic: FreeBSD Kernel Dump > Version String: FreeBSD 7.0-RC1 #0: Mon Dec 24 10:10:07 UTC 2007 > [EMAIL PROTECTED]:/usr/obj/usr/src/sys/GENERIC > Panic String: solaris assert: sm->sm_space == space (0x1686d4800 == > 0x1686d3800), file: > /usr/src/sys/modules/zfs/../../contrib/opensolaris/uts/common/fs/zfs/space_map.c, > line: 357 > Dump Parity: 4000765979 > Bounds: 0 > Dump Status: good > > * > > The minidump is avaible if it nececery. > > If anybody know the solution, or can give me any advice how to fix it, than > please sent me by e-mail. Restore your data from backup, you lost the filesystem. ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to "[EMAIL PROTECTED]"
Unable to get crash dump with 7-PRERELEASE - rum0 wireless usb
Using a Hawking HWUG1 with rum0 running FreeBSD 7-PRERELEASE cvsup'd to releng_7 on 1-27-08. rum0: on uhub5 rum0: MAC/BBP RT2573 (rev 0x2573a), RF RT2528 rum0: Ethernet address: 00:0e:3b:08:d0:e6 rum0: if_start running deferred for Giant When the machine is booted rum0 immediately connects to an access point. Within a few seconds of starting a file xfer there is a page fault. The last line on the console reads: Dumping 78 MB : In /etc/rc.conf: dumpdev="/dev/ad2s1b" There doesn't appear to be a core file generated in /var/crash Any help here is greatly appreciated -kim ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to "[EMAIL PROTECTED]"
Re: /usr/bin/objformat is missing
Quoting "Chris H." <[EMAIL PROTECTED]>:
Quoting pluknet <[EMAIL PROTECTED]>:
On 29/01/2008, Chris H. <[EMAIL PROTECTED]> wrote:
Quoting Peter Jeremy <[EMAIL PROTECTED]>:
> On Mon, Jan 28, 2008 at 02:41:56PM -0800, Chris H. wrote:
>> In case you're wondering, objformat /is/ required - at leas for
>> www/apache13-ssl.
>
touching objformat is not a good way. Try this instead, last time it
helped me (taken from memory):
--- Makefile.orig 2008-01-29 13:38:43.0 +0300
+++ Makefile2008-01-29 13:41:19.0 +0300
@@ -5,7 +5,7 @@
# and apache-ssl port by Mark Murray <[EMAIL PROTECTED]>.
# Oh, and with a little bit of help from Ben :)
#
-# $FreeBSD: ports/www/apache13-ssl/Makefile,v 1.121 2007/06/17
16:59:26 anders Exp $
+# $FreeBSD$
PORTNAME= apache+ssl
PORTVERSION= ${APACHE_VERSION}.${APACHE_SSL_VERSION}
@@ -48,7 +48,7 @@
APACHE_HARD_SERVER_LIMIT?= 512
-CFLAGS+= -I${OPENSSLINC}/openssl
+CFLAGS+= -I${OPENSSLINC}/openssl -Wl,
I noticed this arg in another thread regarding this issue:
--export-dynamic
Thank you for posting this. Although I had success building and
running the apache13-ssl port after applying my objformat /hackery/.
I'm now running into troubles adding all of the php5 extensions I
need to use. I had no difficulties with php5 itself. But after a
certain point in the list, apache exits on signal 11 (core dumped).
Ermm... this was exactly the same trouble I started with, with the
exception that it was on signal 10.
So, with any luck (fingers crossed), I'll get past this limitation
with your patch and /yet/ another make deinstall apache13-ssl &&
all-added-mod_whatevers && all-php5-extensions && php5. make install
everything-all-over-again. :/
Looks like the bugfest mark announced earlier isn't over just yet. :)
Thanks again for taking the time to respond and share your patch.
--Chris H
Well, the:
-Wl,--export-dynamic
was the magic. :) This of course, basically accomplishes the same
thing as my /hackery/. But does it in a manner which cannot be
considered "hackery". :) I mean, that's what a linker is for, isn't it? :)
The only side affect from adding it, is that after linking/compiling
the Apache core, it moves on to the modules, and emits the following
on every one:
cc: --export-dynamic: linker input file unused because linking not done
But of course, it's just a harmless "informative" message. While it
didn't fix my seeming php5 module number limitation. I was able, after
trial and error, to discover that the recode module was the module
causing Apache to dump core. Simply removing it from the list cured
it. :) Further investigation reveals that there are some issues with
with recode versions greater than 3.5. PHP recommends using 3.5. But,
as I already use iconv, and mbstring, using recode is kind of overkill
anyway. So forget it. :)
I /really/ want to thank you for shooting this patch my direction. For
two reasons; one of course, because it eliminates the need for /hackery/
two, because it reminded me to get back to a project I had to put on the
back burner. Which is to create a port of Apache that will run 2 versions
of PHP consecutively. Sure, I know that everybody runs one via module, and
the other via cgi. But, given the way dlopen works on *BSD. It is possible
to run both versions as modules. Which will allow you to separate them
via extension, virtual host/domain, or a mix of both. All via Apache's
conf file - so take /that/ Linux. >:)
I had /intended/ to finish the project /before/ PHP announced
the EOL date for v.4. But work got in the way. :(
Anyway, given that I already sent a pr on this issue. I'll send your
eloquent "patch" as the recommended solution. So as to close the pr.
Thanks again!
--Chris H
CONFIGURE_ARGS+= \
--prefix=${PREFIX} \
--server-uid=www \
___
freebsd-stable@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-stable
To unsubscribe, send any mail to "[EMAIL PROTECTED]"
--
panic: kernel trap (ignored)
___
freebsd-stable@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-stable
To unsubscribe, send any mail to "[EMAIL PROTECTED]"
--
panic: kernel trap (ignored)
___
freebsd-stable@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-stable
To unsubscribe, send any mail to "[EMAIL PROTECTED]"
Re: Documentation: Installing FreeBSD 7.0 via serial console and PXE
On Tue, Jan 29, 2008 at 07:42:54PM +, N.J. Mann wrote:
> In message <[EMAIL PROTECTED]>,
> on Tuesday, 29 January, 2008 at 11:09:13 Jeremy Chadwick ([EMAIL PROTECTED])
> wrote:
> > I spent 7-8 hours yesterday working on accomplishing ${SUBJECT}, and in
> > the process wrote a document on it. There are scattered docs all over
> > the Web describing how to do this, but all of them are either outdated
> > or incorrect in some regards (no offence intended), hence what I wrote.
> >
> > http://jdc.parodius.com/freebsd/pxeboot_serial_install.html
>
> This is great. However, shouldn't 192.168.1.200 be 192.168.1.100 for
> newbox.home.lan in the "Common Paths/Terms Used" table?
You're right -- thanks! I got some other mails about similar typos,
which I'm fixing up as the mails come in. :-)
--
| Jeremy Chadwickjdc at parodius.com |
| Parodius Networking http://www.parodius.com/ |
| UNIX Systems Administrator Mountain View, CA, USA |
| Making life hard for others since 1977. PGP: 4BD6C0CB |
___
freebsd-stable@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-stable
To unsubscribe, send any mail to "[EMAIL PROTECTED]"
Re: Documentation: Installing FreeBSD 7.0 via serial console and PXE
On Tue, Jan 29, 2008 at 02:50:43PM -0500, Ed Maste wrote: > > iv. Knowledge of how TFTP and DHCP work, and how to debug them if > > they break, > > v. Intricate knowledge of configuring a DHCP server (common > > question: "what's the 'next-server' and 'option root-path' > > stuff? Is it needed? Why?") > > I admit that I haven't tried installing Linux or Solaris via PXE, but I > find it interesting that such knowledge wouldn't be required for them. It's much more "solid" in the sense that with Linux, you simply tell the boot loader (GRUB or whatever else) to pass the kernel an argument that says "use this serial port speed, no VGA console, and output everything to this serial port". That's *it*. I'd have to dig a little deeper on Solaris i386 (I'm pretty sure it's a boot loader option, similar to -S115200 in /boot.config on FreeBSD), but on Sparc I believe OpenBoot takes care of this pain for you. > > vii. ... not being able to do a complete 100% TFTP-based (e.g. no > > NFS) install > > Well, you _can_ do a complete 100% TFTP-based install, but the loader > has to be compiled with an option. I agree that is rather unfortunate. I believe the options you're referring to are LOADER_TFTP_SUPPORT and LOADER_NFS_SUPPORT. Even if you define LOADER_NFS_SUPPORT=no, loader(8) will still resort to using NFS. I've confirmed this on a couple occasions by defining PXE_DEBUG=1 and looking at the output. NFS, from what I can tell, is needed regardless because TFTP offers no way (AFAIK) of handling directory structures. This is speculation on my part, but the confirmation that there's no way to do a pure TFTP-based install has been verified. PR kern/74352 confirms this as well. > > If you tell boot2 to set the speed to 115200 (e.g. > > comconsole_speed="115200"), it won't work ? you'll still get 9600bps. > > Sure, since boot2 doesn't look at loader.conf. You're right, if you > have a hard disk putting -S115200 in /boot.config is the best bet, and > the loader will pick the speed setting up automatically. Which begs the question -- why is there some kind of association between the maximum speed a serial port can be set to and the speed the port *is* set to currently? I don't mind if FreeBSD defaults to 9600bps out of the box, but I *do* mind that I can't set that serial port's speed higher than 9600bps anywhere (including getty, stty, etc.) unless the boot blocks are rebuilt. > > But when PXE booting, there's only one piece of the bootstrap used: > > pxeboot(8). This means the only solution is to rebuild the boot > > blocks with a serial port speed that has the speed you want -- in this > > case, 115200bps. > > That shouldn't be the case; comconsole_speed="115200" should be > sufficient to set the speed. (Granted the port will start out at 9600 > until the conf file gets parsed.) Nope -- I've confirmed this on every system I've used during the past 12 years I've used FreeBSD. BOOT_COMCONSOLE_SPEED=9600 (the default) also sets the *maximum* speed permitted for that serial port to 9600, until the boot blocks are rebuilt. > How is the console speed handled when PXE booting other operating > systems? On Sparcs, I believe OpenBoot takes care of it for you (you tell it what speed you want, and it does the work for you). I'm not sure about other i386 platforms. -- | Jeremy Chadwickjdc at parodius.com | | Parodius Networking http://www.parodius.com/ | | UNIX Systems Administrator Mountain View, CA, USA | | Making life hard for others since 1977. PGP: 4BD6C0CB | ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to "[EMAIL PROTECTED]"
Re: Documentation: Installing FreeBSD 7.0 via serial console and PXE
In message <[EMAIL PROTECTED]>,
on Tuesday, 29 January, 2008 at 11:09:13 Jeremy Chadwick ([EMAIL PROTECTED])
wrote:
> I spent 7-8 hours yesterday working on accomplishing ${SUBJECT}, and in
> the process wrote a document on it. There are scattered docs all over
> the Web describing how to do this, but all of them are either outdated
> or incorrect in some regards (no offence intended), hence what I wrote.
>
> http://jdc.parodius.com/freebsd/pxeboot_serial_install.html
This is great. However, shouldn't 192.168.1.200 be 192.168.1.100 for
newbox.home.lan in the "Common Paths/Terms Used" table?
Cheers,
Nick.
--
___
freebsd-stable@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-stable
To unsubscribe, send any mail to "[EMAIL PROTECTED]"
Re: Documentation: Installing FreeBSD 7.0 via serial console and PXE
On Tue, Jan 29, 2008 at 11:09:13AM -0800, Jeremy Chadwick wrote:
> I spent 7-8 hours yesterday working on accomplishing ${SUBJECT}, and in
> the process wrote a document on it. There are scattered docs all over
> the Web describing how to do this, but all of them are either outdated
> or incorrect in some regards (no offence intended), hence what I wrote.
>
> http://jdc.parodius.com/freebsd/pxeboot_serial_install.html
Thanks for putting this together; I've also noticed there's (sometimes
conflicting) documentation on this scattered around various places.
There are a few things in your document that I question though. For
example, you mention that installing FreeBSD via PXE requires
> iv. Knowledge of how TFTP and DHCP work, and how to debug them if
> they break,
> v. Intricate knowledge of configuring a DHCP server (common
> question: "what's the 'next-server' and 'option root-path'
> stuff? Is it needed? Why?")
I admit that I haven't tried installing Linux or Solaris via PXE, but I
find it interesting that such knowledge wouldn't be required for them.
> vii. ... not being able to do a complete 100% TFTP-based (e.g. no
> NFS) install
Well, you _can_ do a complete 100% TFTP-based install, but the loader
has to be compiled with an option. I agree that is rather unfortunate.
> If you tell boot2 to set the speed to 115200 (e.g.
> comconsole_speed="115200"), it won't work ? you'll still get 9600bps.
Sure, since boot2 doesn't look at loader.conf. You're right, if you
have a hard disk putting -S115200 in /boot.config is the best bet, and
the loader will pick the speed setting up automatically.
> But when PXE booting, there's only one piece of the bootstrap used:
> pxeboot(8). This means the only solution is to rebuild the boot
> blocks with a serial port speed that has the speed you want -- in this
> case, 115200bps.
That shouldn't be the case; comconsole_speed="115200" should be
sufficient to set the speed. (Granted the port will start out at 9600
until the conf file gets parsed.)
How is the console speed handled when PXE booting other operating
systems?
-Ed
___
freebsd-stable@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-stable
To unsubscribe, send any mail to "[EMAIL PROTECTED]"
Re: USB support + Supermicro IPMI KVM = no keyboard
Steven Hartland wrote: When booting a default kernel e.g. standard install cd the KVM over LAN keyboard on Supermicro's IPMI modules refuse to function. Once installed if we build a kernel without USB all is good. So two questions:- 1. Can usb support be disabled from the loader? 2. Anyone got any ideas why USB would break the IPMI keyboard? The IPMI keyboard is a USB keyboard. It seems to work OK on a box running 7.0: port 6 addr 2: high speed, self powered, config 1, Multidevice(0x0002), Peppercon AG(0x14dd), rev 0.01 ukbd0: on uhub3 The same box running 6.2 did not connect the device as a usb keyboard. -- Erik ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to "[EMAIL PROTECTED]"
Documentation: Installing FreeBSD 7.0 via serial console and PXE
I spent 7-8 hours yesterday working on accomplishing ${SUBJECT}, and in
the process wrote a document on it. There are scattered docs all over
the Web describing how to do this, but all of them are either outdated
or incorrect in some regards (no offence intended), hence what I wrote.
http://jdc.parodius.com/freebsd/pxeboot_serial_install.html
I've CC'd freebsd-stable since I think more system administrators read
that list than freebsd-doc.
I've opened a PR for getting this doc, or pieces of it, added to the
handbook or documentation tree. Don't have the PR number yet.
I also encountered a reproducable bug with the mfs_root gzip loader (I
believe some people in the past have reported this too?), and will be
opening a separate PR for that.
--
| Jeremy Chadwickjdc at parodius.com |
| Parodius Networking http://www.parodius.com/ |
| UNIX Systems Administrator Mountain View, CA, USA |
| Making life hard for others since 1977. PGP: 4BD6C0CB |
___
freebsd-stable@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-stable
To unsubscribe, send any mail to "[EMAIL PROTECTED]"
zfs problems
Hy, I use FreeBSD 7.0 RC1 AMD64 and 4 WD 250GB HDD in Raid-z., and a weeks ago my server crashed. In the log i found a I/O error, and since then i can't import my zpool. When i run zpool import, i get the folowing messege: *ginger# zpool import pool: tank id: 9268868588611347691 state: ONLINE action: The pool can be imported using its name or numeric identifier. config: tank ONLINE raidz1 ONLINE ad8 ONLINE ad10 ONLINE ad12 ONLINE ad14 ONLINE* but when i try to access the zpool my system crash and give me a nice kernel panic, like this: *Dump header from device /dev/ad4s1b Architecture: amd64 Architecture Version: 2 Dump Length: 253394944B (241 MB) Blocksize: 512 Dumptime: Sun Jan 20 23:51:58 2008 Hostname: Magic: FreeBSD Kernel Dump Version String: FreeBSD 7.0-RC1 #0: Mon Dec 24 10:10:07 UTC 2007 [EMAIL PROTECTED]:/usr/obj/usr/src/sys/GENERIC Panic String: solaris assert: sm->sm_space == space (0x1686d4800 == 0x1686d3800), file: /usr/src/sys/modules/zfs/../../contrib/opensolaris/uts/common/fs/zfs/space_map.c, line: 357 Dump Parity: 4000765979 Bounds: 0 Dump Status: good * The minidump is avaible if it nececery. If anybody know the solution, or can give me any advice how to fix it, than please sent me by e-mail. Thank's: Mike PS: sorry my bad english, but i hadn't wrote letter in english since ages :) ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to "[EMAIL PROTECTED]"
Re: USB support + Supermicro IPMI KVM = no keyboard
- Original Message - From: "Erik Stian Tefre" <[EMAIL PROTECTED]> Steven Hartland wrote: When booting a default kernel e.g. standard install cd the KVM over LAN keyboard on Supermicro's IPMI modules refuse to function. Once installed if we build a kernel without USB all is good. So two questions:- 1. Can usb support be disabled from the loader? 2. Anyone got any ideas why USB would break the IPMI keyboard? The IPMI keyboard is a USB keyboard. It seems to work OK on a box running 7.0: port 6 addr 2: high speed, self powered, config 1, Multidevice(0x0002), Peppercon AG(0x14dd), rev 0.01 ukbd0: on uhub3 The same box running 6.2 did not connect the device as a usb keyboard. Thanks Eric unfortunately we had the same issue with 7.0-RC1 and 7.0-PREREL I'll look at dropping usb back into our kernel we're running atm and see if it detects the above as that might well help diagnose the issue. Regards Steve This e.mail is private and confidential between Multiplay (UK) Ltd. and the person or entity to whom it is addressed. In the event of misdirection, the recipient is prohibited from using, copying, printing or otherwise disseminating it or any information contained in it. In the event of misdirection, illegible or incomplete transmission please telephone +44 845 868 1337 or return the E.mail to [EMAIL PROTECTED] ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to "[EMAIL PROTECTED]"
Re: /usr/bin/objformat is missing
On Tue, Jan 29, 2008 at 05:53:35PM +0100, Eirik ?verby wrote:
> On Jan 29, 2008, at 4:49 PM, Chris H. wrote:
>
> >Quoting pluknet <[EMAIL PROTECTED]>:
> >
> >>On 29/01/2008, Chris H. <[EMAIL PROTECTED]> wrote:
> >>>Quoting Peter Jeremy <[EMAIL PROTECTED]>:
> >>>
> On Mon, Jan 28, 2008 at 02:41:56PM -0800, Chris H. wrote:
> > In case you're wondering, objformat /is/ required - at leas for
> > www/apache13-ssl.
>
> >>
> >>touching objformat is not a good way. Try this instead, last time it
> >>helped me (taken from memory):
> >>
> >>--- Makefile.orig 2008-01-29 13:38:43.0 +0300
> >>+++ Makefile2008-01-29 13:41:19.0 +0300
> >>@@ -5,7 +5,7 @@
> >># and apache-ssl port by Mark Murray
> >><[EMAIL PROTECTED] >.
> >># Oh, and with a little bit of help from Ben :)
> >>#
> >>-# $FreeBSD: ports/www/apache13-ssl/Makefile,v 1.121 2007/06/17
> >>16:59:26 anders Exp $
> >>+# $FreeBSD$
> >>
> >>PORTNAME= apache+ssl
> >>PORTVERSION= ${APACHE_VERSION}.${APACHE_SSL_VERSION}
> >>@@ -48,7 +48,7 @@
> >>
> >>APACHE_HARD_SERVER_LIMIT?= 512
> >>
> >>-CFLAGS+= -I${OPENSSLINC}/openssl
> >>+CFLAGS+= -I${OPENSSLINC}/openssl -Wl,
> >
> >I noticed this arg in another thread regarding this issue:
> >--export-dynamic
> >
> >Thank you for posting this. Although I had success building and
> >running the apache13-ssl port after applying my objformat /hackery/.
> >I'm now running into troubles adding all of the php5 extensions I
> >need to use. I had no difficulties with php5 itself. But after a
> >certain point in the list, apache exits on signal 11 (core dumped).
> >Ermm... this was exactly the same trouble I started with, with the
> >exception that it was on signal 10.
>
> I have had problems with PHP modules in the past; often they can end
> up crashing when loaded in the wrong order, for instance. I also had
> major trouble getting the imagick module to work at all lately.
>
> Try re-ordering things in your extensions.ini, maybe commenting out
> all modules and re-enabling one at a time.
>
> /Eirik
If you have compiled the PHP SSL module and are loading it, make sure
that it uses the same SSL library as the Apache module. Likewise for any
other libraries that PHP might be linking in that Apache also uses.
Gary
___
freebsd-stable@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-stable
To unsubscribe, send any mail to "[EMAIL PROTECTED]"
Fatal trap 12: page fault while in kernel mode
Yay, crash dumps! How else can I help?
FreeBSD eyrie.homenet 6.3-PRERELEASE FreeBSD 6.3-PRERELEASE #1: Sun
Dec 30 21:50:28 EST 2007 [EMAIL PROTECTED]:/usr/obj/usr/src/sys/
RC20071223 i386
2) eyrie:/usr/obj/usr/src/sys/RC20071223# kgdb kernel.debug /var/crash/
vmcore.0
kgdb: kvm_nlist(_stopped_cpus):
kgdb: kvm_nlist(_stoppcbs):
[GDB will not be able to debug user-mode threads: /usr/lib/
libthread_db.so: Undefined symbol "ps_pglobal_lookup"]
GNU gdb 6.1.1 [FreeBSD]
Copyright 2004 Free Software Foundation, Inc.
GDB is free software, covered by the GNU General Public License, and
you are
welcome to change it and/or distribute copies of it under certain
conditions.
Type "show copying" to see the conditions.
There is absolutely no warranty for GDB. Type "show warranty" for
details.
This GDB was configured as "i386-marcel-freebsd".
Unread portion of the kernel message buffer:
Fatal trap 12: page fault while in kernel mode
fault virtual address = 0x35000214
fault code = supervisor write, page not present
instruction pointer = 0x20:0xc080c74f
stack pointer = 0x28:0xd7d25b4c
frame pointer = 0x28:0xd7d25b5c
code segment= base 0x0, limit 0xf, type 0x1b
= DPL 0, pres 1, def32 1, gran 1
processor eflags= interrupt enabled, resume, IOPL = 0
current process = 3422 (java)
trap number = 12
panic: page fault
Uptime: 25d0h1m6s
Dumping 511 MB (2 chunks)
chunk 0: 1MB (159 pages) ... ok
chunk 1: 511MB (130800 pages) 495 479 463 447 431 415 399 383 367
351 335 319 303 287 271 255 239 223 207 191 175 159 143 127 111 95 79
63 47 31 15
#0 doadump () at pcpu.h:165
165 __asm __volatile("movl %%fs:0,%0" : "=r" (td));
(kgdb) bt
#0 doadump () at pcpu.h:165
#1 0xc074873d in boot (howto=260) at /usr/src/sys/kern/
kern_shutdown.c:409
#2 0xc0748cd3 in panic (fmt=0xc0b8a6e0 "page fault") at /usr/src/sys/
kern/kern_shutdown.c:565
#3 0xc0a1bf24 in trap_fatal (frame=0xd7d25b0c, eva=889192980) at /usr/
src/sys/i386/i386/trap.c:838
#4 0xc0a1c1dd in trap_pfault (frame=0xd7d25b0c, usermode=0,
eva=889192980) at /usr/src/sys/i386/i386/trap.c:745
#5 0xc0a1c5d0 in trap (frame=
{tf_fs = 8, tf_es = 40, tf_ds = 40, tf_edi = -1012545064,
tf_esi = -1061606752, tf_ebp = -674079908, tf_isp = -674079944, tf_ebx
= -1012545064, tf_edx = 889192976, tf_ecx = -1001224928, tf_eax =
394565837, tf_trapno = 12, tf_err = 2, tf_eip = -1065302193, tf_cs =
32, tf_eflags = 66050, tf_esp = -674079908, tf_ss = -1066157083}) at /
usr/src/sys/i386/i386/trap.c:435
#6 0xc0a0778a in calltrap () at /usr/src/sys/i386/i386/exception.s:139
#7 0xc080c74f in in_pcbremlists (inp=0xc3a5c9d8) at /usr/src/sys/
netinet/in_pcb.c:1155
#8 0xc080c7dd in in_pcbdetach (inp=0xc3a5c9d8) at /usr/src/sys/
netinet/in_pcb.c:709
#9 0xc0834de7 in udp_detach (so=0x178498cd) at /usr/src/sys/netinet/
udp_usrreq.c:1071
#10 0xc078f3c7 in soclose (so=0xc485542c) at /usr/src/sys/kern/
uipc_socket.c:459
#11 0xc077a200 in soo_close (fp=0xc4aa5ca8, td=0xc50bca80) at /usr/src/
sys/kern/sys_socket.c:317
#12 0xc071abd3 in fdrop_locked (fp=0xc4aa5ca8, td=0xc50bca80) at
file.h:296
#13 0xc071b0e2 in closef (fp=0xc4aa5ca8, td=0xc50bca80) at /usr/src/
sys/kern/kern_descrip.c:1933
#14 0xc071bca9 in kern_close (td=0xc50bca80, fd=57) at /usr/src/sys/
kern/kern_descrip.c:1023
#15 0xc0a1ca20 in syscall (frame=
{tf_fs = 59, tf_es = 59, tf_ds = 59, tf_edi = 376516096, tf_esi
= 0, tf_ebp = -1112515544, tf_isp = -674079388, tf_ebx = 672784448,
tf_edx = 1, tf_ecx = -2147482943, tf_eax = 6, tf_trapno = 0, tf_err =
2, tf_eip = 672723975, tf_cs = 51, tf_eflags = 535, tf_esp =
-1112515572, tf_ss = 59})
at /usr/src/sys/i386/i386/trap.c:984
#16 0xc0a077df in Xint0x80_syscall () at /usr/src/sys/i386/i386/
exception.s:200
#17 0x0033 in ?? ()
Previous frame inner to this frame (corrupt stack?)
(kgdb) frame 14
#14 0xc071bca9 in kern_close (td=0xc50bca80, fd=57) at /usr/src/sys/
kern/kern_descrip.c:1023
1023error = closef(fp, td);
(kgdb) l
1018 * for the new fd.
1019 */
1020knote_fdclose(td, fd);
1021FILEDESC_UNLOCK(fdp);
1022
1023error = closef(fp, td);
1024if (holdleaders) {
1025FILEDESC_LOCK_FAST(fdp);
1026fdp->fd_holdleaderscount--;
1027if (fdp->fd_holdleaderscount == 0 &&
(kgdb) frame 15
#15 0xc0a1ca20 in syscall (frame=
{tf_fs = 59, tf_es = 59, tf_ds = 59, tf_edi = 376516096, tf_esi
= 0, tf_ebp = -1112515544, tf_isp = -674079388, tf_ebx = 672784448,
tf_edx = 1, tf_ecx = -2147482943, tf_eax = 6, tf_trapno = 0, tf_err =
2, tf_eip = 672723975, tf_cs = 51, tf_eflags = 535, tf_esp =
-1112515572, tf_ss = 59})
at /usr/src/sys/i386/i386/trap.c:984
984 error = (*callp->sy_call)(td, args);
(kgdb) l
979 STOPEVENT(p, S_SCE,
Re: /usr/bin/objformat is missing
On Jan 29, 2008, at 4:49 PM, Chris H. wrote:
Quoting pluknet <[EMAIL PROTECTED]>:
On 29/01/2008, Chris H. <[EMAIL PROTECTED]> wrote:
Quoting Peter Jeremy <[EMAIL PROTECTED]>:
> On Mon, Jan 28, 2008 at 02:41:56PM -0800, Chris H. wrote:
>> In case you're wondering, objformat /is/ required - at leas for
>> www/apache13-ssl.
>
touching objformat is not a good way. Try this instead, last time it
helped me (taken from memory):
--- Makefile.orig 2008-01-29 13:38:43.0 +0300
+++ Makefile2008-01-29 13:41:19.0 +0300
@@ -5,7 +5,7 @@
# and apache-ssl port by Mark Murray <[EMAIL PROTECTED]
>.
# Oh, and with a little bit of help from Ben :)
#
-# $FreeBSD: ports/www/apache13-ssl/Makefile,v 1.121 2007/06/17
16:59:26 anders Exp $
+# $FreeBSD$
PORTNAME= apache+ssl
PORTVERSION= ${APACHE_VERSION}.${APACHE_SSL_VERSION}
@@ -48,7 +48,7 @@
APACHE_HARD_SERVER_LIMIT?= 512
-CFLAGS+= -I${OPENSSLINC}/openssl
+CFLAGS+= -I${OPENSSLINC}/openssl -Wl,
I noticed this arg in another thread regarding this issue:
--export-dynamic
Thank you for posting this. Although I had success building and
running the apache13-ssl port after applying my objformat /hackery/.
I'm now running into troubles adding all of the php5 extensions I
need to use. I had no difficulties with php5 itself. But after a
certain point in the list, apache exits on signal 11 (core dumped).
Ermm... this was exactly the same trouble I started with, with the
exception that it was on signal 10.
I have had problems with PHP modules in the past; often they can end
up crashing when loaded in the wrong order, for instance. I also had
major trouble getting the imagick module to work at all lately.
Try re-ordering things in your extensions.ini, maybe commenting out
all modules and re-enabling one at a time.
/Eirik
So, with any luck (fingers crossed), I'll get past this limitation
with your patch and /yet/ another make deinstall apache13-ssl &&
all-added-mod_whatevers && all-php5-extensions && php5. make install
everything-all-over-again. :/
Looks like the bugfest mark announced earlier isn't over just yet. :)
Thanks again for taking the time to respond and share your patch.
--Chris H
CONFIGURE_ARGS+= \
--prefix=${PREFIX} \
--server-uid=www \
___
freebsd-stable@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-stable
To unsubscribe, send any mail to "[EMAIL PROTECTED]
"
--
panic: kernel trap (ignored)
___
freebsd-stable@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-stable
To unsubscribe, send any mail to "[EMAIL PROTECTED]
"
___
freebsd-stable@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-stable
To unsubscribe, send any mail to "[EMAIL PROTECTED]"
Help debugging kernel crash?
Hello,
I posted this on -questions yesterday, but I thought this might be the
more appropriate list - apologies for the cross-posting.
I have been getting occasional reboots on my FreeBSD 6-STABLE
machine. I haven't figured out a pattern on it yet, but the most
recent crash was during some pretty heavy NFS usage, and I see nfsd in
the dump, so perhaps that has something to do with it. Could anyone
assist in deciphering the cause of this? This is the first time it's
crashed on me once I enabled debugging, so I can't say for sure
whether or not this is common to all of them.
Thanks,
-c
[EMAIL PROTECTED] ~ % uname -a
FreeBSD ark.bluetonic.org 6.3-STABLE FreeBSD 6.3-STABLE #4: Wed Jan 23
19:10:47 CST 2008 [EMAIL PROTECTED]:/usr/obj/usr/src/sys/ARK
i386
[EMAIL PROTECTED] ...src/sys/ARK # kgdb kernel.debug /var/crash/vmcore.0
kgdb: kvm_nlist(_stopped_cpus):
kgdb: kvm_nlist(_stoppcbs):
[GDB will not be able to debug user-mode threads: /usr/lib/
libthread_db.so: Unde
fined symbol "ps_pglobal_lookup"]
GNU gdb 6.1.1 [FreeBSD]
Copyright 2004 Free Software Foundation, Inc.
GDB is free software, covered by the GNU General Public License, and
you are
welcome to change it and/or distribute copies of it under certain
conditions.
Type "show copying" to see the conditions.
There is absolutely no warranty for GDB. Type "show warranty" for
details.
This GDB was configured as "i386-marcel-freebsd".
Unread portion of the kernel message buffer:
panic: free: address 0xca0f6300(0xca0f6000) has not been allocated.
Uptime: 18h38m31s
Dumping 1279 MB (2 chunks)
chunk 0: 1MB (159 pages) ... ok
chunk 1: 1279MB (327408 pages) 1263 1247 1231 1215 1199 1183 1167
1151 1135 1119 1103 1087 1071 1055 1039 1023 1007 991 975 959 943 927
911 895 879 863 847 831 815 799 783 767 751 735 719 703 687 671 655
639 623 607 591 575 559 543 527 511 495 479 463 447 431 415 399 383
367 351 335 319 303 287 271 255 239 223 207 191 175 159 143 127 111 95
79 63 47 31 15
#0 doadump () at pcpu.h:165
165 __asm __volatile("movl %%fs:0,%0" : "=r" (td));
(kgdb) backtrace
#0 doadump () at pcpu.h:165
#1 0xc0553a74 in boot (howto=260) at /usr/src/sys/kern/
kern_shutdown.c:409
#2 0xc0553da6 in panic (
fmt=0xc0744037 "free: address %p(%p) has not been allocated.\n")
at /usr/src/sys/kern/kern_shutdown.c:565
#3 0xc0545ab5 in free (addr=0xca0f6300, mtp=0x0)
at /usr/src/sys/kern/kern_malloc.c:374
#4 0xc06701f3 in nfssvc_nfsd (td=0x0)
at /usr/src/sys/nfsserver/nfs_syscalls.c:544
#5 0xc066f455 in nfssvc (td=0xc522e300, uap=0xed9ced04)
at /usr/src/sys/nfsserver/nfs_syscalls.c:181
#6 0xc0711332 in syscall (frame=
{tf_fs = 59, tf_es = 59, tf_ds = 59, tf_edi = 0, tf_esi = 0,
tf_ebp = -1077941464, tf_isp = -308482716, tf_ebx = 0, tf_edx =
-1077936144, tf_ecx = 2, tf_eax = 155, tf_trapno = 12, tf_err = 2,
tf_eip = 671902679, tf_cs = 51, tf_eflags = 582, tf_esp = -1077941492,
tf_ss = 59}) at /usr/src/sys/i386/i386/trap.c:984
#7 0xc06fb5ef in Xint0x80_syscall () at /usr/src/sys/i386/i386/
exception.s:200
#8 0x0033 in ?? ()
Previous frame inner to this frame (corrupt stack?)
(kgdb)
___
freebsd-stable@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-stable
To unsubscribe, send any mail to "[EMAIL PROTECTED]"
Re: /usr/bin/objformat is missing
Quoting pluknet <[EMAIL PROTECTED]>:
On 29/01/2008, Chris H. <[EMAIL PROTECTED]> wrote:
Quoting Peter Jeremy <[EMAIL PROTECTED]>:
> On Mon, Jan 28, 2008 at 02:41:56PM -0800, Chris H. wrote:
>> In case you're wondering, objformat /is/ required - at leas for
>> www/apache13-ssl.
>
touching objformat is not a good way. Try this instead, last time it
helped me (taken from memory):
--- Makefile.orig 2008-01-29 13:38:43.0 +0300
+++ Makefile2008-01-29 13:41:19.0 +0300
@@ -5,7 +5,7 @@
# and apache-ssl port by Mark Murray <[EMAIL PROTECTED]>.
# Oh, and with a little bit of help from Ben :)
#
-# $FreeBSD: ports/www/apache13-ssl/Makefile,v 1.121 2007/06/17
16:59:26 anders Exp $
+# $FreeBSD$
PORTNAME= apache+ssl
PORTVERSION= ${APACHE_VERSION}.${APACHE_SSL_VERSION}
@@ -48,7 +48,7 @@
APACHE_HARD_SERVER_LIMIT?= 512
-CFLAGS+= -I${OPENSSLINC}/openssl
+CFLAGS+= -I${OPENSSLINC}/openssl -Wl,
I noticed this arg in another thread regarding this issue:
--export-dynamic
Thank you for posting this. Although I had success building and
running the apache13-ssl port after applying my objformat /hackery/.
I'm now running into troubles adding all of the php5 extensions I
need to use. I had no difficulties with php5 itself. But after a
certain point in the list, apache exits on signal 11 (core dumped).
Ermm... this was exactly the same trouble I started with, with the
exception that it was on signal 10.
So, with any luck (fingers crossed), I'll get past this limitation
with your patch and /yet/ another make deinstall apache13-ssl &&
all-added-mod_whatevers && all-php5-extensions && php5. make install
everything-all-over-again. :/
Looks like the bugfest mark announced earlier isn't over just yet. :)
Thanks again for taking the time to respond and share your patch.
--Chris H
CONFIGURE_ARGS+= \
--prefix=${PREFIX} \
--server-uid=www \
___
freebsd-stable@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-stable
To unsubscribe, send any mail to "[EMAIL PROTECTED]"
--
panic: kernel trap (ignored)
___
freebsd-stable@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-stable
To unsubscribe, send any mail to "[EMAIL PROTECTED]"
Re: USB support + Supermicro IPMI KVM = no keyboard
On Tue, Jan 29, 2008 at 01:46:42PM -, Steven Hartland wrote: > - Original Message - > From: "Max Laier" <[EMAIL PROTECTED]> > On Tuesday 29 January 2008, Steven Hartland wrote: > > >>So two questions:- > >>1. Can usb support be disabled from the loader? > >>2. Anyone got any ideas why USB would break the IPMI keyboard? > > > >You could try hint.kbdmux.0.disabled="1" - see kdbmux(4) for details. > > Thanks for the idea Max no go unfortunately, also tried:- > hint.usb.0.disabled=1 > hint.uhci.0.disabled=1 > hint.ohci.0.disabled=1 > hint.ukbd.0.disabled=1 Maybe the keyboard is done via USB and the BIOS sets legacy support for USB keyboards, which is disabled by USB drivers to handle it natively. You have to know that USB controllers can emulate the old 8042 driven keyboards in hardware, but this won't allow using other USB devices at the same time. As long as FreeBSD isn't touching the USB controller the emulation would be kept. You should take a lock into the BIOS setup if you can change USB keyboard legacy support. And you should lock into boot messages if there is a non working USB device found. The USB legacy thing is just an assumption - it could be something completely different as well. -- B.Walterhttp://www.bwct.de http://www.fizon.de [EMAIL PROTECTED] [EMAIL PROTECTED][EMAIL PROTECTED] ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to "[EMAIL PROTECTED]"
Re: T7200 CPU not detected by est
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Stefan Lambrev wrote: > Greetings, > > Krassimir Slavchev wrote: >> -BEGIN PGP SIGNED MESSAGE- >> Hash: SHA1 >> >> Stefan Lambrev wrote: >> >>> Greetings, >>> >>> Krassimir Slavchev wrote: >>> -BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Ian Smith wrote: > On Fri, 25 Jan 2008, John Baldwin wrote: > > On Wednesday 23 January 2008 02:42:52 am Krassimir Slavchev wrote: > > > John Baldwin wrote: > > > > On Monday 21 January 2008 11:16:06 am Gerrit Kühn wrote: > > > >> Hi folks, > > > >> > > > >> I have several systems using T7200 mobile CPUs running under > 7-stable. > > > >> However, EST does not recognize the cpus. When loading > cpufreq I get: > > > > > > > > You can try this patch. It won't add support for all of the > levels, but it > > > > will support the current level and the highest level (IIRC). > > > > > > > > > > > It works now on my T7700: > > > > > dev.est.0.%desc: Enhanced SpeedStep Frequency Control > > > dev.est.0.%driver: est > > > dev.est.0.%parent: cpu0 > > > dev.est.0.freq_settings: 2401/35000 2400/35000 2000/28000 > 1600/22000 > > > 1200/16000 > > > dev.est.1.%desc: Enhanced SpeedStep Frequency Control > > > dev.est.1.%driver: est > > > dev.est.1.%parent: cpu1 > > > dev.est.1.freq_settings: 2401/35000 2400/35000 2000/28000 > 1600/22000 > > > 1200/16000 > > > Odd, it shouldn't have provided that many settings. It also > doesn't > > provide power info. I wonder if you are getting the settings from > > ACPI. > > Assuming so, wouldn't this seem to be an instance needing the recent: > > kern/114722: [acpi] [patch] Nearly duplicate p-state entries > reported http://www.freebsd.org/cgi/query-pr.cgi?pr=114722 > With this patch the result is the same. >>> Patched src/sys/kern/kern_cpu.c is already in RELENG_7_0. >>> It was submitted 8 days ago. >>> Are you sure your sources are newer then this? >>> >>> >> >> No, they where almost 2 weeks older. >> I have just upgraded to todays 7.0 and the result is the same. >> >> > Can you show me the result of: sysctl dev.cpu.0.freq_levels dev.cpu.0.freq_levels: 2401/35000 2100/30625 2000/28000 1750/24500 1600/22000 1400/19250 1200/16000 1050/14000 900/12000 800/14000 700/12250 600/10500 500/8750 400/7000 300/5250 200/3500 100/1750 > > May be est driver doesn't use the patched function in > src/sys/kern/kern_cpu.c ? > > Also do you see any problems with this? :) No > Powerd should work because it reads dev.cpu.0.freq_levels May be, I have to disable acpi to have bge :( > > CC Nate Lawson. > Best Regards -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.7 (FreeBSD) iD8DBQFHnzfpxJBWvpalMpkRAsJeAJ41OrOAKo7k1QcbCQeTqgazNiKHDgCfa/03 z34kC8th0FgyudC0PonLpFE= =PPqb -END PGP SIGNATURE- ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to "[EMAIL PROTECTED]"
Re: T7200 CPU not detected by est
Greetings, Krassimir Slavchev wrote: -BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Stefan Lambrev wrote: Greetings, Krassimir Slavchev wrote: -BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Ian Smith wrote: On Fri, 25 Jan 2008, John Baldwin wrote: > On Wednesday 23 January 2008 02:42:52 am Krassimir Slavchev wrote: > > John Baldwin wrote: > > > On Monday 21 January 2008 11:16:06 am Gerrit Kühn wrote: > > >> Hi folks, > > >> > > >> I have several systems using T7200 mobile CPUs running under 7-stable. > > >> However, EST does not recognize the cpus. When loading cpufreq I get: > > > > > > You can try this patch. It won't add support for all of the levels, but it > > > will support the current level and the highest level (IIRC). > > > > > > > > > It works now on my T7700: > > > > dev.est.0.%desc: Enhanced SpeedStep Frequency Control > > dev.est.0.%driver: est > > dev.est.0.%parent: cpu0 > > dev.est.0.freq_settings: 2401/35000 2400/35000 2000/28000 1600/22000 > > 1200/16000 > > dev.est.1.%desc: Enhanced SpeedStep Frequency Control > > dev.est.1.%driver: est > > dev.est.1.%parent: cpu1 > > dev.est.1.freq_settings: 2401/35000 2400/35000 2000/28000 1600/22000 > > 1200/16000 > > Odd, it shouldn't have provided that many settings. It also doesn't > provide power info. I wonder if you are getting the settings from > ACPI. Assuming so, wouldn't this seem to be an instance needing the recent: kern/114722: [acpi] [patch] Nearly duplicate p-state entries reported http://www.freebsd.org/cgi/query-pr.cgi?pr=114722 With this patch the result is the same. Patched src/sys/kern/kern_cpu.c is already in RELENG_7_0. It was submitted 8 days ago. Are you sure your sources are newer then this? No, they where almost 2 weeks older. I have just upgraded to todays 7.0 and the result is the same. Can you show me the result of: sysctl dev.cpu.0.freq_levels May be est driver doesn't use the patched function in src/sys/kern/kern_cpu.c ? Also do you see any problems with this? :) Powerd should work because it reads dev.cpu.0.freq_levels CC Nate Lawson. -- Best Wishes, Stefan Lambrev ICQ# 24134177 ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to "[EMAIL PROTECTED]"
Re: USB support + Supermicro IPMI KVM = no keyboard
- Original Message - From: "Max Laier" <[EMAIL PROTECTED]> On Tuesday 29 January 2008, Steven Hartland wrote: So two questions:- 1. Can usb support be disabled from the loader? 2. Anyone got any ideas why USB would break the IPMI keyboard? You could try hint.kbdmux.0.disabled="1" - see kdbmux(4) for details. Thanks for the idea Max no go unfortunately, also tried:- hint.usb.0.disabled=1 hint.uhci.0.disabled=1 hint.ohci.0.disabled=1 hint.ukbd.0.disabled=1 Regards Steve This e.mail is private and confidential between Multiplay (UK) Ltd. and the person or entity to whom it is addressed. In the event of misdirection, the recipient is prohibited from using, copying, printing or otherwise disseminating it or any information contained in it. In the event of misdirection, illegible or incomplete transmission please telephone +44 845 868 1337 or return the E.mail to [EMAIL PROTECTED] ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to "[EMAIL PROTECTED]"
Re: T7200 CPU not detected by est
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Stefan Lambrev wrote: > Greetings, > > Krassimir Slavchev wrote: >> -BEGIN PGP SIGNED MESSAGE- >> Hash: SHA1 >> >> Ian Smith wrote: >> >>> On Fri, 25 Jan 2008, John Baldwin wrote: >>> > On Wednesday 23 January 2008 02:42:52 am Krassimir Slavchev wrote: >>> > > John Baldwin wrote: >>> > > > On Monday 21 January 2008 11:16:06 am Gerrit Kühn wrote: >>> > > >> Hi folks, >>> > > >> >>> > > >> I have several systems using T7200 mobile CPUs running under >>> 7-stable. >>> > > >> However, EST does not recognize the cpus. When loading >>> cpufreq I get: >>> > > > >>> > > > You can try this patch. It won't add support for all of the >>> levels, but it >>> > > > will support the current level and the highest level (IIRC). >>> > > > >>> > > > > > > It works now on my T7700: >>> > > > > dev.est.0.%desc: Enhanced SpeedStep Frequency Control >>> > > dev.est.0.%driver: est >>> > > dev.est.0.%parent: cpu0 >>> > > dev.est.0.freq_settings: 2401/35000 2400/35000 2000/28000 >>> 1600/22000 >>> > > 1200/16000 >>> > > dev.est.1.%desc: Enhanced SpeedStep Frequency Control >>> > > dev.est.1.%driver: est >>> > > dev.est.1.%parent: cpu1 >>> > > dev.est.1.freq_settings: 2401/35000 2400/35000 2000/28000 >>> 1600/22000 >>> > > 1200/16000 >>> > > Odd, it shouldn't have provided that many settings. It also >>> doesn't >>> > provide power info. I wonder if you are getting the settings from >>> > ACPI. >>> >>> Assuming so, wouldn't this seem to be an instance needing the recent: >>> >>> kern/114722: [acpi] [patch] Nearly duplicate p-state entries >>> reported http://www.freebsd.org/cgi/query-pr.cgi?pr=114722 >>> >> >> With this patch the result is the same. >> > Patched src/sys/kern/kern_cpu.c is already in RELENG_7_0. > It was submitted 8 days ago. > Are you sure your sources are newer then this? > No, they where almost 2 weeks older. I have just upgraded to todays 7.0 and the result is the same. Best Regards -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.7 (FreeBSD) iD8DBQFHny00xJBWvpalMpkRAg2BAJ4yyzbsJN1hOGxOaZnbeicuCrxgXgCeKzED WDlJ8bx9oqPCmt3jHZ8ecrQ= =taHu -END PGP SIGNATURE- ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to "[EMAIL PROTECTED]"
Re: USB support + Supermicro IPMI KVM = no keyboard
On Tuesday 29 January 2008, Steven Hartland wrote: > When booting a default kernel e.g. standard install cd the KVM over LAN > keyboard on Supermicro's IPMI modules refuse to function. Once > installed if we build a kernel without USB all is good. > > So two questions:- > 1. Can usb support be disabled from the loader? > 2. Anyone got any ideas why USB would break the IPMI keyboard? You could try hint.kbdmux.0.disabled="1" - see kdbmux(4) for details. -- /"\ Best regards, | [EMAIL PROTECTED] \ / Max Laier | ICQ #67774661 X http://pf4freebsd.love2party.net/ | [EMAIL PROTECTED] / \ ASCII Ribbon Campaign | Against HTML Mail and News signature.asc Description: This is a digitally signed message part.
Re: USB support + Supermicro IPMI KVM = no keyboard
When booting a default kernel e.g. standard install cd the KVM over LAN keyboard on Supermicro's IPMI modules refuse to function. Once installed if we build a kernel without USB all is good. So two questions:- 1. Can usb support be disabled from the loader? 2. Anyone got any ideas why USB would break the IPMI keyboard? Regards Steve This e.mail is private and confidential between Multiplay (UK) Ltd. and the person or entity to whom it is addressed. In the event of misdirection, the recipient is prohibited from using, copying, printing or otherwise disseminating it or any information contained in it. In the event of misdirection, illegible or incomplete transmission please telephone +44 845 868 1337 or return the E.mail to [EMAIL PROTECTED] ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to "[EMAIL PROTECTED]"
USB support + Supermicro IPMI KVM = no keyboard
When booting a default kernel e.g. standard install cd the KVM over LAN keyboard on Supermicro's IPMI modules refuse to function. Once installed if we build a kernel without USB all is good. So two questions:- 1. Can usb support be disabled from the loader? 2. Anyone got any ideas why USB would break the IPMI keyboard? Regards Steve This e.mail is private and confidential between Multiplay (UK) Ltd. and the person or entity to whom it is addressed. In the event of misdirection, the recipient is prohibited from using, copying, printing or otherwise disseminating it or any information contained in it. In the event of misdirection, illegible or incomplete transmission please telephone +44 845 868 1337 or return the E.mail to [EMAIL PROTECTED] ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to "[EMAIL PROTECTED]"
Re: /usr/bin/objformat is missing
On 29/01/2008, Chris H. <[EMAIL PROTECTED]> wrote:
> Quoting Peter Jeremy <[EMAIL PROTECTED]>:
>
> > On Mon, Jan 28, 2008 at 02:41:56PM -0800, Chris H. wrote:
> >> In case you're wondering, objformat /is/ required - at leas for
> >> www/apache13-ssl.
> >
touching objformat is not a good way. Try this instead, last time it
helped me (taken from memory):
--- Makefile.orig 2008-01-29 13:38:43.0 +0300
+++ Makefile2008-01-29 13:41:19.0 +0300
@@ -5,7 +5,7 @@
# and apache-ssl port by Mark Murray <[EMAIL PROTECTED]>.
# Oh, and with a little bit of help from Ben :)
#
-# $FreeBSD: ports/www/apache13-ssl/Makefile,v 1.121 2007/06/17
16:59:26 anders Exp $
+# $FreeBSD$
PORTNAME= apache+ssl
PORTVERSION= ${APACHE_VERSION}.${APACHE_SSL_VERSION}
@@ -48,7 +48,7 @@
APACHE_HARD_SERVER_LIMIT?= 512
-CFLAGS+= -I${OPENSSLINC}/openssl
+CFLAGS+= -I${OPENSSLINC}/openssl -Wl,--export-dynamic
CONFIGURE_ARGS+= \
--prefix=${PREFIX} \
--server-uid=www \
___
freebsd-stable@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-stable
To unsubscribe, send any mail to "[EMAIL PROTECTED]"
Re: /usr/bin/objformat is missing
Quoting Peter Jeremy <[EMAIL PROTECTED]>: On Mon, Jan 28, 2008 at 02:41:56PM -0800, Chris H. wrote: In case you're wondering, objformat /is/ required - at leas for www/apache13-ssl. objformat was created at around FreeBSD 3.0 as a temporary tool to handle the a.out to ELF transition and has been obsolete for nearly 8 years. Unfortunately, it's continued presence misled third-party developers. Yes, this is what I gathered from the man pages. Too bad the Vendors don't read the man pages. :) So the trick is to create the following /usr/bin/objformat: #!/bin/sh echo elf Make sure to set perms to +r +x -w The correct fix is to patch the configure script to not need objformat. Indeed. Couldn't agree more. It's my understanding that this is a linker issue. Is it possible that it only shows up now because the default gcc is now 4.1? Note that as others have suggested, Apache 1.3 is now a legacy version. Even if you don't move to Apache 2.2 now, I suggest your future plans include provision for migration off Apache 1.3. To quote the Apache website: "We strongly recommend that users of all earlier versions, including 1.3 family release, upgrade to to the current 2.2 version as soon as possible." According to the Apache developers, 1.3's appeal is IJW (It Just Works). But your point is well taken. :) --Chris H -- Peter Jeremy Please excuse any delays as the result of my ISP's inability to implement an MTA that is either RFC2821-compliant or matches their claimed behaviour. -- panic: kernel trap (ignored) ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to "[EMAIL PROTECTED]"
Re: /usr/bin/objformat is missing
On Mon, Jan 28, 2008 at 02:41:56PM -0800, Chris H. wrote: >In case you're wondering, objformat /is/ required - at leas for >www/apache13-ssl. objformat was created at around FreeBSD 3.0 as a temporary tool to handle the a.out to ELF transition and has been obsolete for nearly 8 years. Unfortunately, it's continued presence misled third-party developers. >So the trick is to create the following /usr/bin/objformat: > >#!/bin/sh >echo elf > >Make sure to set perms to +r +x -w The correct fix is to patch the configure script to not need objformat. Note that as others have suggested, Apache 1.3 is now a legacy version. Even if you don't move to Apache 2.2 now, I suggest your future plans include provision for migration off Apache 1.3. To quote the Apache website: "We strongly recommend that users of all earlier versions, including 1.3 family release, upgrade to to the current 2.2 version as soon as possible." -- Peter Jeremy Please excuse any delays as the result of my ISP's inability to implement an MTA that is either RFC2821-compliant or matches their claimed behaviour. pgp5TNEY54C5g.pgp Description: PGP signature
