savecore: first and last dump headers disagree
Hi! We have an amd64 system that still experiences crashes after installing 5.4, mostly during high loads. (It's been unstable all the time, really; see previous posts.) I've added dumpdev=/dev/amrd0s2b, and some time ago I did get coredumps, but with latest versions of the kernel, savecore does not give me a dump, instead it says: savecore: first and last dump headers disagree on /dev/amrd0s2b savecore: unsaved dumps found but not saved What can I do to fix this? I guess I need a core dump to proceed in finding the problem? Also, the machine does not reboot after a panic, that's an even bigger problem, really, it needs console hands-on to revive every time. Last time it crashed (last week, before updating to 5.4-RELEASE, that system was a few weeks older on the RELENG_5_4 branch), it seems to have get stuck on dumping the core, can this be the problem: --- Fatal trap 12: page fault while in kernel mode cpuid = 0: apic id = 00 fault virtual address= 0x00 ... trap number = 12 panic: page fault cpuid = 0 boot() called on cpu#0 Uptime: 1d23h50m36s Dumping 2047 MB 16 32 The cursor sits at the position after 32. Seems to me it fails to dump the core, can this be it? On previous crashes, before dumpdev was set, it would hang before that The machine is Dell 2850 w/ Perc raid, Dual CPUs, SMP with hyperthreading OFF in BIOS. Enclosing the KERNEL config, almost a GENERIC kernel. I can provide more info if required. So, in short, three question, really. - How can I get rid of the crashes? (heh) - How can I get the system to do unattended reboot when crashed? - How do I get a coredump? Any help appreciated. /Palle Diffing GENERIC vs KERNEL: --- GENERIC Tue Apr 12 15:57:01 2005 +++ KERNEL Fri Apr 29 22:27:41 2005 @@ -20,7 +20,9 @@ machine amd64 cpu HAMMER -ident GENERIC +ident KERNEL + +makeoptions DEBUG=-g # To statically compile in device wiring instead of /boot/device.hints #hints GENERIC.hints # Default places to look for devices. @@ -45,7 +47,7 @@ options COMPAT_43 # Needed by COMPAT_LINUX32 options COMPAT_IA32 # Compatible with i386 binaries options COMPAT_FREEBSD4 # Compatible with FreeBSD4 -options COMPAT_LINUX32 # Compatible with i386 linux binaries +#optionsCOMPAT_LINUX32 # Compatible with i386 linux binaries options SCSI_DELAY=15000# Delay (in ms) before probing SCSI options KTRACE # ktrace(1) support options SYSVSHM # SYSV-style shared memory @@ -64,10 +66,10 @@ # Enabling NO_MIXED_MODE gives a performance improvement on some motherboards # but does not work with some boards (mostly nVidia chipset based). -#optionsNO_MIXED_MODE # Don't penalize working chipsets +options NO_MIXED_MODE # Don't penalize working chipsets # Linux 32-bit ABI support -options LINPROCFS # Cannot be a module yet. +#optionsLINPROCFS # Cannot be a module yet. # Bus support. Do not remove isa, even if you have no isa slots device acpi @@ -260,3 +262,19 @@ device firewire# FireWire bus code device sbp # SCSI over FireWire (Requires scbus and da) device fwe # Ethernet over FireWire (non-standard!) + +# SMP +options SMP + +# SysV stuff +# This provides support for System V shared memory. +# +options SYSVSHM +options SYSVSEM +options SYSVMSG +options SHMMAXPGS=65536 +options SEMMNI=40 +options SEMMNS=240 +options SEMUME=40 +options SEMMNU=120 # # GENERIC -- Generic kernel configuration file for FreeBSD/amd64 # # For more information on this file, please read the handbook section on # Kernel Configuration Files: # # http://www.FreeBSD.org/doc/en_US.ISO8859-1/books/handbook/kernelconfig-config.html # # The handbook is also available locally in /usr/share/doc/handbook # if you've installed the doc distribution, otherwise always see the # FreeBSD World Wide Web server (http://www.FreeBSD.org/) for the # latest information. # # An exhaustive list of options and more detailed explanations of the # device lines is also present in the ../../conf/NOTES and NOTES files. # If you are in doubt as to the purpose or necessity of a line, check first # in NOTES. # # $FreeBSD: src/sys/amd64/conf/GENERIC,v 1.421.2.11.2.1 2005/04/09 17:28:37 kensmith Exp $ machine amd64 cpu HAMMER ident KERNEL makeoptions DEBUG=-g # To statically compile in device wiring instead of /boot/device.hints #hints GENERIC.hints # Default places to look for devices. options SCHED_4BSD # 4BSD scheduler options INET# InterNETworking options INET6 #
Re: em and bge driver MPSAFE?
Thanks for your clear response, yes i was looking for 5.x indeed. Driver status for 5.x would be very nice indeed, i guess more guys are interested in such? If someone provides me with info, i'm willing text for the busdma page you mentioned so that 5.x is also included. Bye, Mipam. On Sat, 21 May 2005, John-Mark Gurney wrote: Mipam wrote this message on Wed, May 11, 2005 at 16:39 +0200: Perhaps lame to ask, But are the em and bge driver MPSAFE? I couldn't find notes about being mpsafe in the man pages of these drivers? I was about to point you to: http://www.freebsd.org/projects/busdma/ But realized that you probably wanted status on 5.x, and not HEAD... a quick look at the code shows that both em and bge are MPSAFE... I can tell because of no references to Giant or GIANT, and that it using XX_LOCK and has functions ending in _locked in them... Maybe we need to expand the busdma project to include which driver status for 5.x and HEAD? -- John-Mark GurneyVoice: +1 415 225 5579 All that I will do, has been done, All that I have, has not. ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: Diskless boot problem
On 5/22/05, Doug White [EMAIL PROTECTED] wrote: On Sat, 21 May 2005, [ISO-8859-2] Sawek ak wrote: On 5/20/05, Doug White [EMAIL PROTECTED] wrote: Please try to avoid sending your message bodies base64 encoded :) My mail client got really confused by it and didn't quote the message properly. Also stripping hackers cc:. I'd like to, but Gmail doesn't offer this option. Sorry :( On Thu, 19 May 2005, [ISO-8859-2] Sawek ak wrote: Hi, I have a problem with booting Dell 2850 over network. The machine reads kernel over net, boots upto mounting / from NFS and then crashes. What is the NFS server? It seems to think the NFS handle we pulled the kernel with is no longer valid. FreeBSD 5.3/5.4-STABLE. Hm ... dunno then ... does the server complain about the client at all in the log? No complaints whatsoever.The exact os version on NFS server is 5.4-RC2. Does PXE and the system itself end up pulling different IP addresses? No. The IP is the same. Message on the console before boot: CLIENT MAC ADDR: 00 11 43 D3 6E 09 GUID: 44454C4C 4600 1038 8031 B9C04F44314A CLIENT IP: 10.158.190.74 MASK: 255.255.255.224 DHCP IP: 10.158.190.73 GATEWAY IP: 10.158.190.94 PXE Loader 1.00 Building the boot loader arguments Relocating the loader and the BTX Starting the BTX loader BTX loader 1.00 BTX version is 1.01 pjd@ sent me a patch for hardcoding 100 full-duplex on em, but it didn't help: em_init_locked: Forcing 100Mbit/full-duplex NFS ROOT: 10.158.190.73:/var/www/FreeBSD-5.4-x86-PXE em0: Link is up 100 Mbps Full Duplex exec /sbin/init: error 70 exec /sbin/oinit: error 70 exec /sbin/init.bak: error 70 exec /rescue/init: error 70 exec /stand/sysinstall: error 70 init: not found in path /sbin/init:/sbin/oinit:/sbin/init.bak:/rescue/init:/stand/syl panic: no init cpuid = 0 KDB: enter: panic [thread pid 1 tid 12 ] Stopped at kdb_enter+0x30: leave db tcpdump trace on the server still shows stale handle NFS requests. 12:16:09.343817 arp who-has 10.158.190.73 tell 10.158.190.74 12:16:09.343828 arp reply 10.158.190.73 is-at 00:11:43:d3:6e:e1 12:16:09.345688 IP 10.158.190.74.1830074133 10.158.190.73.2049: 100 lookup [|nfs] 12:16:09.345721 IP 10.158.190.73.2049 10.158.190.74.1830074133: reply ok 28 lookup ERROR: Stale NFS file handle 12:16:09.351560 IP 10.158.190.74.1830074134 10.158.190.73.2049: 100 lookup [|nfs] 12:16:09.351579 IP 10.158.190.73.2049 10.158.190.74.1830074134: reply ok 28 lookup ERROR: Stale NFS file handle 12:16:09.386539 IP 10.158.190.74.1830074135 10.158.190.73.2049: 100 lookup [|nfs] 12:16:09.386560 IP 10.158.190.73.2049 10.158.190.74.1830074135: reply ok 28 lookup ERROR: Stale NFS file handle 12:16:09.422644 IP 10.158.190.74.1830074136 10.158.190.73.2049: 100 lookup [|nfs] 12:16:09.422663 IP 10.158.190.73.2049 10.158.190.74.1830074136: reply ok 28 lookup ERROR: Stale NFS file handle 12:16:09.460996 IP 10.158.190.74.1830074137 10.158.190.73.2049: 104 lookup [|nfs] 12:16:09.461019 IP 10.158.190.73.2049 10.158.190.74.1830074137: reply ok 28 lookup ERROR: Stale NFS file handle 12:16:09.498724 IP 10.158.190.74.1830074138 10.158.190.73.2049: 104 lookup [|nfs] 12:16:09.498745 IP 10.158.190.73.2049 10.158.190.74.1830074138: reply ok 28 lookup ERROR: Stale NFS file handle I'm out of options. Thanks, /S -- Sawek ak / UNIX Systems Administrator ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to [EMAIL PROTECTED]
system does not reboot after panic (Was: savecore: first and last dump headers disagree)
--On måndag, maj 23, 2005 10.30.47 +0200 Palle Girgensohn [EMAIL PROTECTED] wrote: Hi! We have an amd64 system that still experiences crashes after installing 5.4, mostly during high loads. (It's been unstable all the time, really; see previous posts.) I've added dumpdev=/dev/amrd0s2b, and some time ago I did get coredumps, but with latest versions of the kernel, savecore does not give me a dump, instead it says: savecore: first and last dump headers disagree on /dev/amrd0s2b savecore: unsaved dumps found but not saved What can I do to fix this? I guess I need a core dump to proceed in finding the problem? Peter Holm tipped me of using savecore -f. Hopefully this will give me a core next time. This one was already destroyed by swapping. :( Also, the machine does not reboot after a panic, that's an even bigger problem, really, it needs console hands-on to revive every time. This is really *the* main issue. It won't reboot automatically, it just sits there waiting for keyboard action... :( there is no debugger in the kernel, would adding kbd and kbd_unattende help? I doubt it? Anything else that can be done? /Palle Last time it crashed (last week, before updating to 5.4-RELEASE, that system was a few weeks older on the RELENG_5_4 branch), it seems to have get stuck on dumping the core, can this be the problem: --- Fatal trap 12: page fault while in kernel mode cpuid = 0: apic id = 00 fault virtual address= 0x00 ... trap number = 12 panic: page fault cpuid = 0 boot() called on cpu#0 Uptime: 1d23h50m36s Dumping 2047 MB 16 32 The cursor sits at the position after 32. Seems to me it fails to dump the core, can this be it? On previous crashes, before dumpdev was set, it would hang before that The machine is Dell 2850 w/ Perc raid, Dual CPUs, SMP with hyperthreading OFF in BIOS. Enclosing the KERNEL config, almost a GENERIC kernel. I can provide more info if required. So, in short, three question, really. - How can I get rid of the crashes? (heh) - How can I get the system to do unattended reboot when crashed? - How do I get a coredump? Any help appreciated. /Palle Diffing GENERIC vs KERNEL: --- GENERIC Tue Apr 12 15:57:01 2005 +++ KERNEL Fri Apr 29 22:27:41 2005 @@ -20,7 +20,9 @@ machine amd64 cpu HAMMER -ident GENERIC +ident KERNEL + +makeoptions DEBUG=-g # To statically compile in device wiring instead of /boot/device.hints #hints GENERIC.hints # Default places to look for devices. @@ -45,7 +47,7 @@ options COMPAT_43 # Needed by COMPAT_LINUX32 options COMPAT_IA32 # Compatible with i386 binaries options COMPAT_FREEBSD4 # Compatible with FreeBSD4 -options COMPAT_LINUX32 # Compatible with i386 linux binaries +#optionsCOMPAT_LINUX32 # Compatible with i386 linux binaries options SCSI_DELAY=15000# Delay (in ms) before probing SCSI options KTRACE # ktrace(1) support options SYSVSHM # SYSV-style shared memory @@ -64,10 +66,10 @@ # Enabling NO_MIXED_MODE gives a performance improvement on some motherboards # but does not work with some boards (mostly nVidia chipset based). -#optionsNO_MIXED_MODE # Don't penalize working chipsets +options NO_MIXED_MODE # Don't penalize working chipsets # Linux 32-bit ABI support -options LINPROCFS # Cannot be a module yet. +#optionsLINPROCFS # Cannot be a module yet. # Bus support. Do not remove isa, even if you have no isa slots device acpi @@ -260,3 +262,19 @@ device firewire# FireWire bus code device sbp # SCSI over FireWire (Requires scbus and da) device fwe # Ethernet over FireWire (non-standard!) + +# SMP +options SMP + +# SysV stuff +# This provides support for System V shared memory. +# +options SYSVSHM +options SYSVSEM +options SYSVMSG +options SHMMAXPGS=65536 +options SEMMNI=40 +options SEMMNS=240 +options SEMUME=40 +options SEMMNU=120 ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: Syntax Error in Kernel
could someone explain why kernel ppp is needed at all? randy ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to [EMAIL PROTECTED]
gvinum
Where I can find any gvinum documentation ? ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to [EMAIL PROTECTED]
RE: RELENG_5 panic
Here's what I could get out of dmesg, and looking again at the dump
# dmesg -M /usr/local/var/adm/crash/vmcore.44 -N /boot/kernel/kernel
kernel trap 12 with interrupts disabled
Fatal trap 12: page fault while in kernel mode
cpuid = 0; apic id = 00
fault virtual address = 0x24
fault code = supervisor read, page not present
instruction pointer = 0x8:0xc0504808
stack pointer = 0x10:0xc7ac0c08
frame pointer = 0x10:0xc7ac0c3c
code segment= base 0x0, limit 0xf, type 0x1b
= DPL 0, pres 1, def32 1, gran 1
processor eflags= resume, IOPL = 0
current process = 27 (swi5: clock sio)
trap number = 12
panic: page fault
cpuid = 0
Uptime: 3d6h59m25s
Dumping 127 MB
16 32 48 64 80 96 112
[EMAIL PROTECTED] [/usr/obj/usr/src/sys/fastipsec]# kgdb kernel.debug
/usr/local/var/adm/crash/vmcore.44
[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.
#0 doadump () at pcpu.h:160
160 __asm __volatile(movl %%fs:0,%0 : =r (td));
(kgdb) l *0xc0504808
0xc0504808 is in turnstile_wait (/usr/src/sys/kern/subr_turnstile.c:245).
240 /*
241 * Pick up the lock that td is blocked on.
242 */
243 ts = td-td_blocked;
244 MPASS(ts != NULL);
245 tc = TC_LOOKUP(ts-ts_lockobj);
246 mtx_lock_spin(tc-tc_lock);
247
248 /*
249 * This thread may not be blocked on this turnstile
anymore
(kgdb)
---
Robin P. Blanchard
Systems Integration Specialist
Georgia Center for Continuing Education
fon: 706.542.2404 fax: 706.542.6546
---
-Original Message-
From: Doug White [mailto:[EMAIL PROTECTED]
Sent: Sunday, May 22, 2005 3:20 PM
To: Robin P. Blanchard
Cc: [EMAIL PROTECTED]
Subject: Re: RELENG_5 panic
On Sat, 21 May 2005, Robin P. Blanchard wrote:
# uname -a
FreeBSD robinpb.homeip.net 5.4-STABLE FreeBSD 5.4-STABLE
#0: Tue May
17
00:30:47 EDT 2005
[EMAIL PROTECTED]:/usr/obj/usr/src/sys/fastipsec i386
# kgdb kernel.debug /usr/local/var/adm/crash/vmcore.44
[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.
#0 doadump () at pcpu.h:160
160 __asm __volatile(movl %%fs:0,%0 : =r (td));
(kgdb) bt full
#0 doadump () at pcpu.h:160
No locals.
#1 0xc04dd58c in boot (howto=260) at
/usr/src/sys/kern/kern_shutdown.c:410
first_buf_printf = 1
#2 0xc04ddccd in panic (fmt=0xc066e594 %s) at
/usr/src/sys/kern/kern_shutdown.c:566
bootopt = 260
newpanic = 0
buf = page fault, '\0' repeats 245 times
can you try to fish the trap output from msgbuf? That or use
dmesg's -N and -M options to extract it from the crashdump.
#3 0xc0641e92 in trap_fatal (frame=0xc7ac0bc8, eva=36) at
/usr/src/sys/i386/i386/trap.c:817
code = 16
type = 12
ss = 16
esp = 0
softseg = {ssd_base = 0, ssd_limit = 1048575,
ssd_type = 27,
ssd_dpl = 0, ssd_p = 1,
ssd_xx = 0, ssd_xx1 = 0, ssd_def32 = 1, ssd_gran = 1}
#4 0xc0642535 in trap (frame=
{tf_fs = 24, tf_es = -1066598384, tf_ds =
-1066532848, tf_edi =
-1053916800, tf_esi = -1049515008, tf_ebp = -945025988, tf_isp =
-945026060, tf_ebx = -1053916800, tf_edx = -1053937024,
tf_ecx = 56,
tf_eax = 0, tf_trapno = 12, tf_err = 0, tf_eip =
-1068480504, tf_cs =
8, tf_eflags = 65683, tf_esp = -1053914880, tf_ss = 582}) at
/usr/src/sys/i386/i386/trap.c:255
p = (struct proc *) 0xc12e754c
sticks = 3241036032
i = 0
ucode = 0
type = 12
code = 0
eva = 36
#5 0xc062da3a in calltrap () at
/usr/src/sys/i386/i386/exception.s:140
No locals.
#6 0x0018 in ?? ()
No symbol table info available.
#7 0xc06d0010 in ipq ()
No symbol table info available.
#8 0xc06e0010 in sc_buffer.3 ()
No symbol table info
Re: [RELENG_4] buildkernel failure with MAKEOBJDIRPREFIX
On Sun, May 22, 2005 at 10:30:12AM +0900, NAKAJI Hiroyuki wrote:
Hello,
I tried to rebuild a debug kernel to analyze one of my problem(*),
and, I faced to another problem. Now this is the main problem for me.
The problem I have now is that 'make buildkernel' does not refer to
${MAKEOBJDIRPREFIX} set in /etc/make.conf. The reason I will use
MAKEOBJDIRPREFIX is that my /usr/obj does not have enough space to
build the debug kernel with DEBUG=-g.
I set MAKEOBJDIRPREFIX=/other/big/directory in /etc/make.conf and ran
'make buildkernel' in /usr/src. And got an error /usr/src: file
system full. Because /usr/src is another partition and has as small
space as /usr/obj. /usr/src is 400MB and /usr/obj is 500MB which are
enouch to build normal RELENG_4 world.
I noticed that modules are built in /usr/src/sys/modules not in
${MAKEOBJDIRPREFIX}/usr/src/sys/modules. Of cource, kernel.debug is
created in ${MAKEOBJDIRPREFIX}/usr/src/sys/CONFIG/kernel.debug.
I think this is a bug of make, *.mk or other Makefiles in /sys but I
cannot fix it.
No, this is because MAKEOBJDIRPREFIX must be an environment variable
and should not be set on make's command line or in /etc/make.conf.
Cheers,
--
Ruslan Ermilov
[EMAIL PROTECTED]
FreeBSD committer
pgpInu1v6e39Z.pgp
Description: PGP signature
Re: can't assign requested address with ntpd on 5-STABLE
On Sun, 22 May 2005, Richard Coleman wrote: On 5-STABLE, when I try to start ntpd, I get the following error: bind() fd 7, family 28, port 123, addr fe80:1::2a0:c9ff:fec8:ea25, in6_is_addr_multicast=0 flags=0 fails: Can't assign requested address Anyone else seen this recently. I've seen something similar with IPV4. Problem here was that I had multiple interfaces with the same address (an ethernet and some point-to-point interfaces that shared the same near-end address). ntpd appears to enumerate the interfaces and tries to bind (by address) to all of them, then fails because it's trying to bind the same thing twice. This isn't directly the same as your problem, but might be similar? Do you have alias addresses or something that may give the same effect? ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to [EMAIL PROTECTED]
4.10-RELEASE-p3 i386 problem with /dev/dsp
Hello, I have a machine with FreeBSD 4.10-RELEASE-p3 i386 (450MHz P3/Celeron) that has been running just fine, but after ~ 120 days something happened to /dev/dsp, and I can no longer play mp3s. A restart would most probably fix it, but I'd like to know if it's possible to determine (and fix) the issue on a running system. Yes, I'm fond of my uptime (up 133 days, 20:04, including an X session), but I'd also like to know if this is recoverable or requires the windows-style bandaid. Short: playing mp3s brings mpg321 into a tight loop of failing writes to /dev/dsp, producing no sound. ktrace/kdump shows mpg321 successfully opening * /usr/local/lib/libid3tag.so.2 * /usr/local/lib/libmad.so.2 * /usr/local/lib/libao.so.3 * /usr/local/lib/ao/plugins-2/liboss.so * /dev/dsp * the mp3 file and failing on (neither exists): * /etc/malloc.conf * /etc/libao.conf * ~/.libao * /dev/sound/dsp 67469 mpg321 1116837907.243643 NAMI /mnt/tmp/test.mp3 67469 mpg321 1116837907.243704 RET open 3 ... 67469 mpg321 1116837907.251698 CALL open(0x80580a0,0x1,0xbfbfefc0) 67469 mpg321 1116837907.251751 NAMI /dev/dsp 67469 mpg321 1116837907.270293 RET open 4 67469 mpg321 1116837907.270325 CALL ioctl(0x4,SNDCTL_DSP_GETBLKSIZE,0x8058088) 67469 mpg321 1116837907.270354 RET ioctl 0 67469 mpg321 1116837907.270369 CALL ioctl(0x4,SNDCTL_DSP_STEREO,0xbfbfeff8) 67469 mpg321 1116837907.276986 RET ioctl 0 67469 mpg321 1116837907.277012 CALL ioctl(0x4,SNDCTL_DSP_SETFMT,0xbfbfeff8) 67469 mpg321 1116837907.283655 RET ioctl 0 67469 mpg321 1116837907.283682 CALL ioctl(0x4,SNDCTL_DSP_SPEED,0xbfbfeff8) 67469 mpg321 1116837907.288238 RET ioctl 0 67469 mpg321 1116837907.288274 CALL sigaction(0x2,0xbfbff048,0xbfbff030) 67469 mpg321 1116837907.288292 RET sigaction 0 67469 mpg321 1116837907.288777 CALL write(0x4,0x8051f80,0x80) 67469 mpg321 1116837907.288817 GIO fd 4 wrote 128 bytes ... (mpg321 writes 128B chunks into fd 4) 67469 mpg321 1116837907.400663 RET write 128/0x80 67469 mpg321 1116837907.400680 CALL write(0x4,0x8052580,0x80) 67469 mpg321 1116837908.390910 GIO fd 4 wrote 0 bytes 67469 mpg321 1116837908.390942 RET write 0 67469 mpg321 1116837908.392573 CALL write(0x4,0x8051f80,0x80) 67469 mpg321 1116837908.392614 RET write -1 errno 22 Invalid argument 67469 mpg321 1116837908.394192 CALL write(0x4,0x8051f80,0x80) 67469 mpg321 1116837908.394231 RET write -1 errno 22 Invalid argument ... (MANY such failed writes) 67469 mpg321 1116837919.779634 CALL write(0x4,0x8051f80,0x80) 67469 mpg321 1116837919.779673 RET write -1 errno 22 Invalid argument 67469 mpg321 1116837919.779789 CALL write(0x2,0xbfbfea88,0x34) 67469 mpg321 1116837919.779837 GIO fd 2 wrote 52 bytes [2:54] Decoding of test.mp3 finished. mpg321 eats more and more CPU as it runs, peaking at about 85% just before dying. time says: 10.77s user 0.18s system 84% cpu 13.026 total -- How many Vietnam vets does it take to screw in a light bulb? You don't know, man. You don't KNOW. Cause you weren't THERE. http://bash.org/?255991 ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: [RELENG_4] buildkernel failure with MAKEOBJDIRPREFIX
In [EMAIL PROTECTED] Ruslan Ermilov [EMAIL PROTECTED] wrote: I think this is a bug of make, *.mk or other Makefiles in /sys but I cannot fix it. No, this is because MAKEOBJDIRPREFIX must be an environment variable and should not be set on make's command line or in /etc/make.conf. I see. Thanks. -- NAKAJI Hiroyuki ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: savecore: first and last dump headers disagree
In the last episode (May 23), Palle Girgensohn said: We have an amd64 system that still experiences crashes after installing 5.4, mostly during high loads. (It's been unstable all the time, really; see previous posts.) I've added dumpdev=/dev/amrd0s2b, and some time ago I did get coredumps, but with latest versions of the kernel, savecore does not give me a dump, instead it says: savecore: first and last dump headers disagree on /dev/amrd0s2b savecore: unsaved dumps found but not saved savecore -vv should print enough of both headers to let you see what's different. Fatal trap 12: page fault while in kernel mode cpuid = 0: apic id = 00 fault virtual address= 0x00 ... trap number = 12 panic: page fault cpuid = 0 boot() called on cpu#0 Uptime: 1d23h50m36s Dumping 2047 MB 16 32 The cursor sits at the position after 32. That's probably why your headers disagree :) If you put options KDB_TRACE in your kernel config file, it will print a small stack trace before trying to dump, which might be enough to track down the cause of the panic even without a dump. -- Dan Nelson [EMAIL PROTECTED] ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to [EMAIL PROTECTED]
Manipulating disk cache (buf) settings
We are running a PostgreSQL server (8.0.3) on a dual opteron system with 8G of RAM. If I interpret top and vfs.hibufspace correctly (which show values of 215MB and 225771520 (which equals 215MB) respectively. My understanding from having searched the archives is that this is the value that is used by the system/kernel in determining how much disk data to cache. If that is in fact the case, then my question would be how to best increase the amount of memory the system can use for disk caching. Ideally I would like to have upwards of 1G for this type of caching/buffering. I suspect it would not be as easy as simply adjusting vfs.hibufspace upwards but would instead involving add either a loader.conf or kernel option of some master setting that affects hibufspace, bufspace, and related tunables. Or would this involve editing one of the system files? Sven ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: rdist6 won't let root use ssh transport
On May 18, 2005, at 3:27 PM, Tim Howe wrote: rdist6 as root, it ignores the -P /usr/bin/ssh flag an tries to use rcmd directly, which fails since my target systems do not have that service running. Might I suggest looking into rsync? It has excellent support for ssh (and in modern versions even defaults to using it for transport) and in general I've found it more amenable to scripting and sensible defaults than rdist. I and colleagues had excellent luck at a past employer of mine porting rdist-based applications to rsync for additional Any suggestion on how to emulate the 'special' trigger in rdist where it runs a command on the remote host only if a matching file was updated? I'd rather not run an expensive database rebuild if the source file wasn't altered. Thanks! Vivek Khera, Ph.D. +1-301-869-4449 x806 ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to [EMAIL PROTECTED]
new base system snmpd
I see that 5.4-STABLE has an snmpd as core to the system. Are there any accompanying docs on how to use it? The man page and sample config file are all seemingly geared towards the personal implementation of the author, and there is no information at all on extending it. (this seems to be a big trend in features lately... serious lack of documentation suitable for those who are not the software author...) Vivek Khera, Ph.D. +1-301-869-4449 x806 ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: 5.4-RC2 freezing - ATA related?
From: Søren Schmidt [EMAIL PROTECTED] On 21/05/2005, at 0:52, Peter Jeremy wrote: On Fri, 2005-May-20 14:53:09 -0600, Elliot Finley wrote: From: Peter Jeremy [EMAIL PROTECTED] On Fri, 2005-May-20 08:25:58 -0600, Elliot Finley wrote: I took the -L option off of my dump command in my daily dump script. I've gone two days without locking up which is unusual. I think that may be what was tickling the bug that was locking me up. Sometime you might like to do a 'dd if=/dev/ar0 of=/dev/null bs=32k' just to confirm that you don't have any unreadable blocks (though this seems unlikely). came up clean. transfer went 40MB/s. That seem to leave the finger pointing at the ATA driver. Paging Søren: Are you have to help Elliot? ++No, my only advise is to use the ATA mkIII patches or better yet - ++current.. I'm already running with the newest ATA mkIII patches. Even with the patches, it freezes up when using the -L option on my daily dump. Elliot ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: Manipulating disk cache (buf) settings
On May 23, 2005, at 10:58 AM, Sven Willenberger wrote: We are running a PostgreSQL server (8.0.3) on a dual opteron system with 8G of RAM. If I interpret top and vfs.hibufspace correctly (which show values of 215MB and 225771520 (which equals 215MB) respectively. My understanding from having searched the archives is that this is the value that is used by the system/kernel in determining how much disk data to cache. This is correct, from what I understand. If you take the vfs.hibufspace and divide by the page size for postgres (normally 8192) you get the proper value for the postgres tunable effective_cache_size. However, the value you see is also the max FreeBSD will use without hacking up the kernel sources. I asked about this a while back and got a response on what to hack, but I hate keeping local patches to the core system which often tend to be forgotten on upgrades... But I would also love to see the max cache get bigger, especially with multi-gig servers becoming more common and affordable. This will kill us on benchmark comparisons for large databases for sure. Vivek Khera, Ph.D. +1-301-869-4449 x806 ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: acd lacks devstat [Was: systat -vmstat vs. acd]
on 19.05.2005 13:03 Andriy Gapon said the following: With 4.X on ATA(PI)-only machine systat -vmstat used to show disks statistics for both ad and acd devices. Now, in 5.4-RELEASE, it shows statistics only for ad devices. If atapicam is added then statistics for cd and pass devices is shown as well. I've done some investigation on this and it seems that this behavior exists since circa introduction of geom and is present in current too. A root cause of this behavior seems to be that acd is not treated as a geom disk and doesn't have any devstat calls of itw own (unlike 4.X). Btw, the same problem exists in current too. I've found a short converstion on a close topic that happened a long while ago: http://www.mail-archive.com/freebsd-current@freebsd.org/msg33834.html I would like to comment on two things: 1. the following part of that converion doesn't seem to be valid to me, because cd device essentially has the same basic properties as acd and that doesn't prevent it from being a geom disk: At any rate I wouldn't expect a CDROM to show up as a disk, unless it has a R/W medium formatted for random R/W inserted (which we at this time doesn't support). 2. even if acd can not be a geom disk (and maybe it can not be indeed), shouldn't it have devstat bookkeeping of its own then ? And the following question still remains: Should I file a PR ? -- Andriy Gapon ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: 5.4 panic at lockmgr
Kris Kennaway [EMAIL PROTECTED] wrote in message news:[EMAIL PROTECTED]... On Fri, May 20, 2005 at 04:39:19PM -0700, Kachun Lee wrote: I upgraded a server from 4.10 to 5.4-rel and it paniced at soon as I put some load on it... panic: lockmgr: thread 0xfffe, not exclusive lock holder 0x76fe0300 unlocking The hardware is a Intel 7501 with a single 3G Xeon 6G mem. I tried disable option MP and made no difference. Any help or suggestion!? Run 'show lockedvnods' and then 'trace pid' for each pid listed. Also, if you can explain how to reproduce this it would be greatly helpful. Kris Thanks for the info. I will try 5.4 on that server again on this Thur/Fri (I am not in the office for these few days). It was hard to tell what really triggered that. The server is one of our NFS servers. With that first panic, I did not notice it right away. The 2nd panic, I had a top running and was staring at it since reboot. When it panic'ed (at ~6 minute uptime), the load climbed to only around 2-3. There is nothing weird showing on top. Since this is one of our production servers, I could not do too much experiment with it. I had set up a similar system with the same MB/CPU on the bench. And it ran the same 5.4-rel kernel, with some benchmark programs, over the weekend without problem. However, I do not have a way to simulate all the network traffic to that box. If you have any idea what I can try to isolate the problem a little more, let me know. Regards Kachun ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to [EMAIL PROTECTED]
Recent 5.4-p1 upgrade issue (lib/libc.so.5)
Hello, I performed an unsupported way of installing and am soliciting what I could do next time to prevent installation blues. I'm not expecting assistance from the Project, just some love :) I have a build host that created what I needed for the host being upgraded. Once it's more polished, I'll be happy to share my steps, but relatively it went well. When I attempted to update /lib/libc.so.5, though, I hit a bump. I `chflags noschg /lib/libc.so.5` and then used tar to extract the exact file. tar was able to unlink the file, and then choked. After some unrelated errors, I was in single user mode using /rescue to save my rear end, which worked well enough. Doing `ldd /sbin/tar` hinted why it probably choked, since tar is dynamically linked to /lib/libc.so.5. Here's what gets me: I was able to do a the supported upgrade process in an unsupported manner (multiuser mode via ssh w/o a shutdown inbetween, nor going into signle user mode) w/ no issues on the build host. What occurs in that process (make buildworld; make buildkernel; make installkernel; mergemaster -p; make installworld; mergemaster) where libc can be replaced (assuming it uses install(1), which is also linked against libc) without failure, but using tar causes it to fail? Ideas? TIA, Jon PGP Fingerprint: 1BB0 A946 927B 93C3 ED6A 0466 6692 6C2C 84BE 4122 Should any political party attempt to abolish social security, unemployment insurance, and eliminate labor laws and farm programs, you would not hear of that party again in our political history. There is a tiny splinter group, of course, that believes you can do these things. Among them are [...] a few other Texas oil millionaires, and an occasional politician or business man from other areas. Their number is negligible and they are stupid. [1] -- Dwight D. Eisenhower, Former President of the USA (Republican), Nov. 8, 1954 [1] http://www.eisenhowermemorial.org/presidential-papers/first-term/documents/1147.cfm __ Yahoo! Mail Mobile Take Yahoo! Mail with you! Check email on your mobile phone. http://mobile.yahoo.com/learn/mail ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to [EMAIL PROTECTED]
mysql loosing connections on 5.4
When port randomisation was added to 4.x I noticed that under heavy loading my webservers starting dropping their connections to the the mysql database. This was fixed by disabling port randomisation and everything ran very happily. When I upgraded to 5.4 I left port randomisation on, and everything was fine until we started to get a very heavy load on the servers over the last two days. So I disabled it, and the problem went away to a large degree, but is still there occasionaly (i.e. I still see a few connections). It's odd behavioour, but what makes it odder is that all these connections are too a local mysql process, using a socket in /tmp! So quite how port randomsiation should affect it I dont know. Anybody else seen this ? I remember a few people had the same issue under 4.x, but I havent heard much about it since then. -pcf. ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: Diskless boot problem
On Mon, 23 May 2005, [ISO-8859-2] Sawek ak wrote: Hi, I have a problem with booting Dell 2850 over network. The machine reads kernel over net, boots upto mounting / from NFS and then crashes. What is the NFS server? It seems to think the NFS handle we pulled the kernel with is no longer valid. FreeBSD 5.3/5.4-STABLE. Hm ... dunno then ... does the server complain about the client at all in the log? No complaints whatsoever.The exact os version on NFS server is 5.4-RC2. All I can suggest is trying rebooting the NFS server. Something in it must have lost communication. If that doesn't fix it then I have no idea, it must be specific to your situation. -- Doug White| FreeBSD: The Power to Serve [EMAIL PROTECTED] | www.FreeBSD.org ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to [EMAIL PROTECTED]
RE: RELENG_5 panic
On Mon, 23 May 2005, Robin P. Blanchard wrote:
Here's what I could get out of dmesg, and looking again at the dump
# dmesg -M /usr/local/var/adm/crash/vmcore.44 -N /boot/kernel/kernel
kernel trap 12 with interrupts disabled
Fatal trap 12: page fault while in kernel mode
cpuid = 0; apic id = 00
fault virtual address = 0x24
fault code = supervisor read, page not present
instruction pointer = 0x8:0xc0504808
stack pointer = 0x10:0xc7ac0c08
frame pointer = 0x10:0xc7ac0c3c
code segment= base 0x0, limit 0xf, type 0x1b
= DPL 0, pres 1, def32 1, gran 1
processor eflags= resume, IOPL = 0
current process = 27 (swi5: clock sio)
trap number = 12
panic: page fault
cpuid = 0
Uptime: 3d6h59m25s
Dumping 127 MB
16 32 48 64 80 96 112
[EMAIL PROTECTED] [/usr/obj/usr/src/sys/fastipsec]# kgdb kernel.debug
/usr/local/var/adm/crash/vmcore.44
[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.
#0 doadump () at pcpu.h:160
160 __asm __volatile(movl %%fs:0,%0 : =r (td));
(kgdb) l *0xc0504808
0xc0504808 is in turnstile_wait (/usr/src/sys/kern/subr_turnstile.c:245).
240 /*
241 * Pick up the lock that td is blocked on.
242 */
243 ts = td-td_blocked;
244 MPASS(ts != NULL);
245 tc = TC_LOOKUP(ts-ts_lockobj);
246 mtx_lock_spin(tc-tc_lock);
247
248 /*
249 * This thread may not be blocked on this turnstile
anymore
(kgdb)
Oh another of these wonderful races... can you go to that frame and print
ts? If its NULL then someone has ripped out the ts out from under us
since it was checked for NULL in the previous line!
-Original Message-
From: Doug White [mailto:[EMAIL PROTECTED]
Sent: Sunday, May 22, 2005 3:20 PM
To: Robin P. Blanchard
Cc: [EMAIL PROTECTED]
Subject: Re: RELENG_5 panic
On Sat, 21 May 2005, Robin P. Blanchard wrote:
# uname -a
FreeBSD robinpb.homeip.net 5.4-STABLE FreeBSD 5.4-STABLE
#0: Tue May
17
00:30:47 EDT 2005
[EMAIL PROTECTED]:/usr/obj/usr/src/sys/fastipsec i386
# kgdb kernel.debug /usr/local/var/adm/crash/vmcore.44
[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.
#0 doadump () at pcpu.h:160
160 __asm __volatile(movl %%fs:0,%0 : =r (td));
(kgdb) bt full
#0 doadump () at pcpu.h:160
No locals.
#1 0xc04dd58c in boot (howto=260) at
/usr/src/sys/kern/kern_shutdown.c:410
first_buf_printf = 1
#2 0xc04ddccd in panic (fmt=0xc066e594 %s) at
/usr/src/sys/kern/kern_shutdown.c:566
bootopt = 260
newpanic = 0
buf = page fault, '\0' repeats 245 times
can you try to fish the trap output from msgbuf? That or use
dmesg's -N and -M options to extract it from the crashdump.
#3 0xc0641e92 in trap_fatal (frame=0xc7ac0bc8, eva=36) at
/usr/src/sys/i386/i386/trap.c:817
code = 16
type = 12
ss = 16
esp = 0
softseg = {ssd_base = 0, ssd_limit = 1048575,
ssd_type = 27,
ssd_dpl = 0, ssd_p = 1,
ssd_xx = 0, ssd_xx1 = 0, ssd_def32 = 1, ssd_gran = 1}
#4 0xc0642535 in trap (frame=
{tf_fs = 24, tf_es = -1066598384, tf_ds =
-1066532848, tf_edi =
-1053916800, tf_esi = -1049515008, tf_ebp = -945025988, tf_isp =
-945026060, tf_ebx = -1053916800, tf_edx = -1053937024,
tf_ecx = 56,
tf_eax = 0, tf_trapno = 12, tf_err = 0, tf_eip =
-1068480504, tf_cs =
8, tf_eflags = 65683, tf_esp = -1053914880, tf_ss = 582}) at
/usr/src/sys/i386/i386/trap.c:255
p = (struct proc *) 0xc12e754c
sticks = 3241036032
i = 0
ucode = 0
type = 12
code = 0
eva = 36
#5 0xc062da3a in calltrap () at
/usr/src/sys/i386/i386/exception.s:140
No locals.
#6 0x0018 in ?? ()
No symbol table info
Re: Manipulating disk cache (buf) settings
Sven Willenberger wrote this message on Mon, May 23, 2005 at 10:58 -0400: We are running a PostgreSQL server (8.0.3) on a dual opteron system with 8G of RAM. If I interpret top and vfs.hibufspace correctly (which show values of 215MB and 225771520 (which equals 215MB) respectively. My understanding from having searched the archives is that this is the value that is used by the system/kernel in determining how much disk data to cache. This is incorrect... FreeBSD merged the vm and buf systems a while back, so all of memory is used as a disk cache.. The buf cache is still used for filesystem meta data (and for pending writes of files, but those buf's reference the original page, not local storage)... Just as an experiment, on a quiet system do: dd if=/dev/zero of=somefile bs=1m count=2048 and then read it back in: dd if=somefile of=/dev/null bs=1m and watch systat or iostat and see if any of the file is read... You'll probably see that none of it is... -- John-Mark Gurney Voice: +1 415 225 5579 All that I will do, has been done, All that I have, has not. ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to [EMAIL PROTECTED]
RE: RELENG_5 panic
Oh another of these wonderful races... can you go to that
frame and print ts? If its NULL then someone has ripped
out the ts out from under us since it was checked for NULL in
the previous line!
Maybe this is a more useful kgdb session (I'm hoping)
# kgdb kernel.debug /usr/local/var/adm/crash/vmcore.44
[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.
#0 doadump () at pcpu.h:160
160 __asm __volatile(movl %%fs:0,%0 : =r (td));
(kgdb) l *0xc0504808
0xc0504808 is in turnstile_wait (/usr/src/sys/kern/subr_turnstile.c:245).
240 /*
241 * Pick up the lock that td is blocked on.
242 */
243 ts = td-td_blocked;
244 MPASS(ts != NULL);
245 tc = TC_LOOKUP(ts-ts_lockobj);
246 mtx_lock_spin(tc-tc_lock);
247
248 /*
249 * This thread may not be blocked on this turnstile
anymore
(kgdb) bt
#0 doadump () at pcpu.h:160
#1 0xc04dd58c in boot (howto=260) at /usr/src/sys/kern/kern_shutdown.c:410
#2 0xc04ddccd in panic (fmt=0xc066e594 %s) at
/usr/src/sys/kern/kern_shutdown.c:566
#3 0xc0641e92 in trap_fatal (frame=0xc7ac0bc8, eva=36) at
/usr/src/sys/i386/i386/trap.c:817
#4 0xc0642535 in trap (frame=
{tf_fs = 24, tf_es = -1066598384, tf_ds = -1066532848, tf_edi =
-1053916800, tf_esi = -1049515008, tf_ebp = -945025988, tf_isp = -945026060,
tf_ebx = -1053916800, tf_edx = -1053937024, tf_ecx = 56, tf_eax = 0,
tf_trapno = 12, tf_err = 0, tf_eip = -1068480504, tf_cs = 8, tf_eflags =
65683, tf_esp = -1053914880, tf_ss = 582}) at
/usr/src/sys/i386/i386/trap.c:255
#5 0xc062da3a in calltrap () at /usr/src/sys/i386/i386/exception.s:140
#6 0x0018 in ?? ()
#7 0xc06d0010 in ipq ()
#8 0xc06e0010 in sc_buffer.3 ()
#9 0xc12e8180 in ?? ()
#10 0xc171ac00 in ?? ()
#11 0xc7ac0c3c in ?? ()
#12 0xc7ac0bf4 in ?? ()
#13 0xc12e8180 in ?? ()
#14 0xc12e3280 in ?? ()
#15 0x0038 in ?? ()
#16 0x in ?? ()
#17 0x000c in ?? ()
#18 0x in ?? ()
#19 0xc0504808 in turnstile_wait (ts=0xc12e3280, lock=0xc06d022c,
owner=0xc171ac00)
at /usr/src/sys/kern/subr_turnstile.c:243
#20 0xc04d2b7f in _mtx_lock_sleep (m=0xc06d022c, td=0xc12e8180, opts=0,
file=0x0, line=0)
at /usr/src/sys/kern/kern_mutex.c:552
#21 0xc058a592 in tcp_isn_tick (xtp=0x0) at
/usr/src/sys/netinet/tcp_subr.c:1380
#22 0xc04ed069 in softclock (dummy=0x0) at
/usr/src/sys/kern/kern_timeout.c:279
#23 0xc04c460a in ithread_loop (arg=0xc12fd500) at
/usr/src/sys/kern/kern_intr.c:547
#24 0xc04c32c2 in fork_exit (callout=0xc04c4550 ithread_loop, arg=0x0,
frame=0x0)
at /usr/src/sys/kern/kern_fork.c:791
#25 0xc062da9c in fork_trampoline () at
/usr/src/sys/i386/i386/exception.s:209
(kgdb) frame 19
#19 0xc0504808 in turnstile_wait (ts=0xc12e3280, lock=0xc06d022c,
owner=0xc171ac00)
at /usr/src/sys/kern/subr_turnstile.c:243
243 ts = td-td_blocked;
(kgdb) list
238 ts-ts_lockobj-lo_name));
239
240 /*
241 * Pick up the lock that td is blocked on.
242 */
243 ts = td-td_blocked;
244 MPASS(ts != NULL);
245 tc = TC_LOOKUP(ts-ts_lockobj);
246 mtx_lock_spin(tc-tc_lock);
247
(kgdb) print ts
$1 = (struct turnstile *) 0xc12e3280
(kgdb) up
#20 0xc04d2b7f in _mtx_lock_sleep (m=0xc06d022c, td=0xc12e8180, opts=0,
file=0x0, line=0)
at /usr/src/sys/kern/kern_mutex.c:552
552 turnstile_wait(ts, m-mtx_object, mtx_owner(m));
(kgdb) list
547 #endif
548
549 /*
550 * Block on the turnstile.
551 */
552 turnstile_wait(ts, m-mtx_object, mtx_owner(m));
553 }
554
555 #ifdef KTR
556 if (cont_logged) {
(kgdb) print ts
$2 = (struct turnstile *) 0x0
(kgdb)
---
Robin P. Blanchard
Systems Integration Specialist
Georgia Center for Continuing Education
fon: 706.542.2404 fax: 706.542.6546
---
___
freebsd-stable@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-stable
To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: nForce 4, SATA Drive only runs at UDMA33?
--- Doug White [EMAIL PROTECTED] wrote: I guess turning off the RAID converts the chips into standard SATA controllers. I'll have to look into that. An nForce 4 machine recently appeared at work, so I'll see what I can get it to do. That's my understanding. FYI: I also tried turning on RAID in the bios and not actually assigning any of the disks to any RAID sets and everthing behaved just the same so it does't seem to matter whether it's on or off in the bios (assuming no disks actually used in an array). It looks like sos added support for atapci1 and 2 in this listing in the ATAmkIII patchset. While that patchset is in -CURRENT you'll have to apply the -stable patches yourself. Search the list archives for the location, soren posts it now and again. I upgraded my source from 5.4-RELEASE to 5-STABLE and applied the patchset, compiled a new kernel, installed it and rebooted. (This was the n version of ATAmkIII which I think is the latest.) It booted, I saw something about ATAPI2 and 3 and SATA and I got all excited for a second as I thought it was going to work. Then, a bunch of stuff flies by real fast and it ends with the following and then hard locks up. (manually retyped as the machine locks) ata2: CONNECT REQUESTED ata2: DISCONNECT REQUESTED ... (lots of those) subdisk6: detached ad6: detached ata2: SATA connect status= ata3: SATA connect ready time=0ms Any ideas? I'm confused about the attach/detach stuff as I'm not using any RAID, it's turned off in the bios. Just trying to get a single SATA drive to work. To further probe and test I tried physically moving the drive to other SATA sockets on the MB. When I did this I can get the system to boot up but it can't find the file systems. I manually told it where the root filesystem was. (it was now on ata5: so I told it ad10s1a, it then completed loading root filesystem) From this point I thought, well, at least now I can try atacontrol to see what's up. atacontrol mode 5 showed the disk still at UDMA33! I gave the command atacontrol mode 5 UDMA133 BIOSIO to try to set it higher but it didn't change anything. So, I'm now out of ideas. Anybody else have any? I could try -CURRENT but my understanding is that with the 5-STABLE and the patchset I'm pretty much the same ATA-wise, correct? Thanks for all the help thus far! --Alan Bryan __ Do You Yahoo!? Tired of spam? Yahoo! Mail has the best spam protection around http://mail.yahoo.com ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: FreeBSD and ProPolice Smashing Stack Protector
On Sun, May 22, 2005 at 11:45:13PM -0400, MING FU wrote: I find that any application which uses libpthread will not work. That include named, nslookup, dig. If you have find any work stack protector for freebsd 5.4, please share with me. Please talk to the authors. Kris pgpHmSQNLxlSb.pgp Description: PGP signature
Re: Syntax Error in Kernel
On Mon, May 23, 2005 at 06:47:01AM -0400, Randy Bush wrote: could someone explain why kernel ppp is needed at all? It's needed if you want to use it, of course :) Kris pgpxTPt8qYyTd.pgp Description: PGP signature
Re: Recent 5.4-p1 upgrade issue (lib/libc.so.5)
On Mon, May 23, 2005 at 10:24:15AM -0700, Jon Passki wrote: Hello, I performed an unsupported way of installing and am soliciting what I could do next time to prevent installation blues. I'm not expecting assistance from the Project, just some love :) I have a build host that created what I needed for the host being upgraded. Once it's more polished, I'll be happy to share my steps, but relatively it went well. When I attempted to update /lib/libc.so.5, though, I hit a bump. I `chflags noschg /lib/libc.so.5` and then used tar to extract the exact file. tar was able to unlink the file, and then choked. After some unrelated errors, I was in single user mode using /rescue to save my rear end, which worked well enough. Doing `ldd /sbin/tar` hinted why it probably choked, since tar is dynamically linked to /lib/libc.so.5. Here's what gets me: I was able to do a the supported upgrade process in an unsupported manner (multiuser mode via ssh w/o a shutdown inbetween, nor going into signle user mode) w/ no issues on the build host. What occurs in that process (make buildworld; make buildkernel; make installkernel; mergemaster -p; make installworld; mergemaster) where libc can be replaced (assuming it uses install(1), which is also linked against libc) without failure, but using tar causes it to fail? Ideas? Look at how make installworld does the replacement safely. Kris pgp8AiE2gfHhz.pgp Description: PGP signature
Re: mysql loosing connections on 5.4
Do you get a particular error and which version of mysql are you running: We have to use 4.0 due to this bug: http://bugs.mysql.com/?id=7209edit=2 Steve - Original Message - From: Pete French [EMAIL PROTECTED] To: [EMAIL PROTECTED] Sent: Monday, May 23, 2005 6:26 PM Subject: mysql loosing connections on 5.4 When port randomisation was added to 4.x I noticed that under heavy loading my webservers starting dropping their connections to the the mysql database. This was fixed by disabling port randomisation and everything ran very happily. When I upgraded to 5.4 I left port randomisation on, and everything was fine until we started to get a very heavy load on the servers over the last two days. So I disabled it, and the problem went away to a large degree, but is still there occasionaly (i.e. I still see a few connections). It's odd behavioour, but what makes it odder is that all these connections are too a local mysql process, using a socket in /tmp! So quite how port randomsiation should affect it I dont know. Anybody else seen this ? I remember a few people had the same issue under 4.x, but I havent heard much about it since then. 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 (023) 8024 3137 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: Manipulating disk cache (buf) settings
On Mon, 2005-05-23 at 10:44 -0700, John-Mark Gurney wrote: Sven Willenberger wrote this message on Mon, May 23, 2005 at 10:58 -0400: We are running a PostgreSQL server (8.0.3) on a dual opteron system with 8G of RAM. If I interpret top and vfs.hibufspace correctly (which show values of 215MB and 225771520 (which equals 215MB) respectively. My understanding from having searched the archives is that this is the value that is used by the system/kernel in determining how much disk data to cache. This is incorrect... FreeBSD merged the vm and buf systems a while back, so all of memory is used as a disk cache.. The buf cache is still used for filesystem meta data (and for pending writes of files, but those buf's reference the original page, not local storage)... Just as an experiment, on a quiet system do: dd if=/dev/zero of=somefile bs=1m count=2048 and then read it back in: dd if=somefile of=/dev/null bs=1m and watch systat or iostat and see if any of the file is read... You'll probably see that none of it is... Yes, confirmed as stated, this is great news then. In essence the PostgreSQL planner can be told that the effective cache size is *much* larger than that calculated by using vfs.hibufspace; should result in some [hopefully] marked performance boosts. btw: dd if=/dev/zero of=zerofile bs=1m count=2048 2048+0 records in 2048+0 records out 2147483648 bytes transferred in 43.381462 secs (49502335 bytes/sec) dd if=zerofile of=/dev/null bs=1m 2048+0 records in 2048+0 records out 2147483648 bytes transferred in 5.304807 secs (404818435 bytes/sec) and that was on a 3GB RAM system so the caching scheme works great. Sven ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to [EMAIL PROTECTED]
Problem with portupgrade
After updating my ports tree I'm getting this: [EMAIL PROTECTED]:40]/usr/ports/sysutils/portupgrade:157sudo portupgrade -a [Updating the pkgdb format:bdb1_btree in /var/db/pkg ... - 354 packages found (-3 +2) (...)/usr/local/lib/ruby/site_ruby/1.8/pkgdb.rb:466: [BUG] Segmentation fault ruby 1.8.2 (2004-12-25) [i386-freebsd4] I've tried manually reinstalling both ruby and portupgrade to no avail. -- Jim C. Nasby, Database Consultant [EMAIL PROTECTED] Give your computer some brain candy! www.distributed.net Team #1828 Windows: Where do you want to go today? Linux: Where do you want to go tomorrow? FreeBSD: Are you guys coming, or what? ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: RELENG_5 panic
On Mon, 23 May 2005 10:43:48 -0700 (PDT) Doug White [EMAIL PROTECTED] wrote: Note: this comment goes to all participants on this mailing list, it is not targeted specifically towards Doug. soapbox_mode People, would you please trim away excess / non-relevant text when you are quoting a message? I don't have a three feet tall monitor, so I cannot display 100 - 200 lines of text at once, and I guess most of you are in the same situation. If you only quote the necessary lines, reading *your* part of the message becomes easier. And that's important, no? Thank you for your time. /soapbox_ mode -- Regards, Torfinn Ingolfsen, Norway ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: Problem with portupgrade
On 23/05/05, Jim C. Nasby [EMAIL PROTECTED] wrote: After updating my ports tree I'm getting this: [EMAIL PROTECTED]:40]/usr/ports/sysutils/portupgrade:157sudo portupgrade -a [Updating the pkgdb format:bdb1_btree in /var/db/pkg ... - 354 packages found (-3 +2) (...)/usr/local/lib/ruby/site_ruby/1.8/pkgdb.rb:466: [BUG] Segmentation fault ruby 1.8.2 (2004-12-25) [i386-freebsd4] I've tried manually reinstalling both ruby and portupgrade to no avail. Try to add the following lines to your /usr/local/etc/pkgtools.conf ENV['PKG_DBDRIVER'] ||= 'dbm_hash' ENV['PORTS_DBDRIVER'] ||= 'dbm_hash' and after it run these 2 commands pkgdb -F portsdb -u to re-create the databases. Regards -- Renato Botelho ICQ: 54596223 AIM: RBGargaBR ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: Lifetime of FreeBSD branches
On Mon, May 23, 2005 at 03:21:32PM -0400, Mike Jakubik wrote: Could someone point me to a resource that outlines the expected supported lifetime of all the branches? Can't find anything concrete on the webpage. http://www.freebsd.org/security/ - It's listed about 1/3 of the way down the page in a table. -- WXS ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: Lifetime of FreeBSD branches
Mike Jakubik wrote: Could someone point me to a resource that outlines the expected supported lifetime of all the branches? Can't find anything concrete on the webpage. http://www.freebsd.org/security/ In addition to the material there (which is concerned with existing releases), FreeBSD 5.x is expected to be supported until late 2007 (FreeBSD 5.5 plus two years), and FreeBSD 6.x will probably be supported until early 2009 (the last FreeBSD 6.x release plus two years). Colin Percival ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to [EMAIL PROTECTED]
Performance of 4.x vs 5.x (Re: Lifetime of FreeBSD branches)
On Mon, May 23, 2005 at 03:21:32PM -0400, Mike Jakubik wrote: Could someone point me to a resource that outlines the expected supported lifetime of all the branches? Can't find anything concrete on the webpage. I'm developing a product, which i hope will run on FreeBSD. However the rapid development of 5, and now 6 arriving out in a few months has me worried if FreeBSD will be the right choice short and long term. I have even considered using 4.11 for its stability and speed on single processor systems, but I'm worried that some ports/hw will not be supported. The common wisdom has been that FreeBSD 4.11 is faster than 5.4 on single processor systems. Imagine my surprise when I went and actually benchmarked this on the package build machines, and found that 5.4 outperforms 4.11 by at least 10% when performing identical workloads on identical UP hardware :-) Stay tuned for more details... Kris pgpMYs5NqAa8M.pgp Description: PGP signature
Re: nForce 4, SATA Drive only runs at UDMA33?
(manually retyped as the machine locks) ata2: CONNECT REQUESTED ata2: DISCONNECT REQUESTED ... (lots of those) subdisk6: detached ad6: detached ata2: SATA connect status= ata3: SATA connect ready time=0ms OK, it may not be so much a lock up as I was just a bit impatient. After a while it panics with: Fatal trap 12 Page fault while in kernel mode fault virtual address 0x20c There's a bunch more that I can write down if that helps. Maybe I need to take a digital picture of the screen before it reboots as I'm a slow writer. Thanks for the help, I'd love to have this thing running at it's capable speed potential. This is my main workstation/desktop. I could update to -CURRENT if anyone thinks that will solve the disk speed problem without causing too many more. (Just do average desktop stuff like KDE3) If -CURRENT is in too much flux right now though maybe I'm better off with working but slow. --Alan Bryan __ Do You Yahoo!? Tired of spam? Yahoo! Mail has the best spam protection around http://mail.yahoo.com ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to [EMAIL PROTECTED]
RE: Problem with portupgrade
-Original Message- From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of Jim C. Nasby Sent: Monday, May 23, 2005 13:50 To: [EMAIL PROTECTED] Subject: Problem with portupgrade After updating my ports tree I'm getting this: [EMAIL PROTECTED]:40]/usr/ports/sysutils/portupgrade:157sudo portupgrade -a [Updating the pkgdb format:bdb1_btree in /var/db/pkg ... - 354 packages found (-3 +2) (...)/usr/local/lib/ruby/site_ruby/1.8/pkgdb.rb:466: [BUG] Segmentation fault ruby 1.8.2 (2004-12-25) [i386-freebsd4] I've tried manually reinstalling both ruby and portupgrade to no avail. I hope I am not hijacking your thread but... I recommend trying portmanager instead of portupgrade. It is MUCH smarter, has less dependencies, and knows how to take care of things when you upgrade a package like perl (it will reinstall all your perl related ports automatically, etc against the new build). Portmanager + portsnap is great. No need for databases or INDEX making which takes a while, etc. Portsnap should replace cvsup in the handbook IMO. It rocks. Here is how I update ports and check for outdated ports (in ports.sh script): portsnap fetch echo Port snapshot fetched, updating... portsnap update echo done. Outdated ports: # take care of cache miss on new ports portmanager -s /dev/null portmanager -s | grep OLD if there are any outdated ports, a portmanager -u will update them all, taking care of any and all dependencies, etc. it does a bunch more stuff too. is anyone aware of any downsides to portmanager? Anyone had any issues? Hope this helps someone out. ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to [EMAIL PROTECTED]
rl0: discard oversize frame
I'm running FreeBSD 5.4-STABLE. At this moment I'm getting all kind of network losses due to the error rl0: discard oversize frame Google showed that a lot of PC suffers form this, but I didn't fine the cure :-( Can anyone help me with a cure? Met vriendelijke groeten Jack Raats ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: rl0: discard oversize frame
I also have the errors showing up in my periodic logs but they dont seem to cause me actual network drops. rl0: discard oversize frame (ether type e14c flags 3 len 1722 max 1514) rl0: discard oversize frame (ether type 1 flags 3 len 36860 max 1514) Chris On 5/23/05, Jack Raats [EMAIL PROTECTED] wrote: I'm running FreeBSD 5.4-STABLE. At this moment I'm getting all kind of network losses due to the error rl0: discard oversize frame Google showed that a lot of PC suffers form this, but I didn't fine the cure :-( Can anyone help me with a cure? Met vriendelijke groeten Jack Raats ___ freebsd-questions@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-questions 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]
Re: 5.4-RC2 freezing - ATA related?
Elliot Finley wrote: This has been happening since 5.3-R, I've been tuning different parameters to no avail. I've taken the disks off of the onboard ICH5 controller and put them a promise TX4 S150 controller, but still the same thing happens. The system freezes, but isn't totally dead. It'll still respond to pings, the screensaver still functions, but it won't respond to a CAD at the console. But if I press 'Enter' at the console, it'll give me a 'login:' prompt, but after entering the username, it never comes back with the 'password:' prompt. After manually resetting the system it boots and says 'Automatic file system check failed; help!' and drops into single user mode. Running fsck manually corrects errors on all volumes. Then it'll boot from that point. This seems to be triggered by daily periodic as it happens at 3:02-3:03AM each time. But it doesn't happen *every* morning. I've had a similar problem with an IBM Thinkpad A21p. The machine would slowly start to lock up until the only thing it would respond to were pings. This would usually occur when the filesystem was under a heavy load (like untarring openoffice). I managed to trace the problem to snapshots that were about 40 days old (I keep old snapshots around for CYA purposes). After deleting the old snapshots, the system functioned perfectly. I've been running it pretty hard now for the last few weeks and it hasn't locked up once. Whether or not the snapshots were the cause of the problem or just another symptom I can't really tell but deleting them definitely cured the problem. Right now I have a filesystem snapshot that's about a week old and it seems to be just fine. Mark ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: rl0: discard oversize frame
I also have the errors showing up in my periodic logs but they dont seem to cause me actual network drops. rl0: discard oversize frame (ether type e14c flags 3 len 1722 max 1514) rl0: discard oversize frame (ether type 1 flags 3 len 36860 max 1514) Chris On 5/23/05, Jack Raats [EMAIL PROTECTED] wrote: I'm running FreeBSD 5.4-STABLE. At this moment I'm getting all kind of network losses due to the error rl0: discard oversize frame Google showed that a lot of PC suffers form this, but I didn't fine the cure :-( Can anyone help me with a cure? Met vriendelijke groeten Jack Raats ___ freebsd-questions@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-questions To unsubscribe, send any mail to [EMAIL PROTECTED] ___ freebsd-questions@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-questions 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]
Re: Lifetime of FreeBSD branches
On Mon, May 23, 2005 3:42 pm, Colin Percival said: http://www.freebsd.org/security/ In addition to the material there (which is concerned with existing releases), FreeBSD 5.x is expected to be supported until late 2007 (FreeBSD 5.5 plus two years), and FreeBSD 6.x will probably be supported until early 2009 (the last FreeBSD 6.x release plus two years). Thanks for the info guys. Does this security support also mean that current ports will be compatible with the release? I'm surprised to see that 4.11 will be supported longer than RELENG_5. Guess my best bet would be to wait for 6.x. Now, does anyone know if a make buildworld/kernel update will be possible for 5.x to 6.x ? I'm assuming that they are similar enough for this to be possible. ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: Performance of 4.x vs 5.x (Re: Lifetime of FreeBSD branches)
On Mon, May 23, 2005 3:51 pm, Kris Kennaway said: The common wisdom has been that FreeBSD 4.11 is faster than 5.4 on single processor systems. Imagine my surprise when I went and actually benchmarked this on the package build machines, and found that 5.4 outperforms 4.11 by at least 10% when performing identical workloads on identical UP hardware :-) Stay tuned for more details... To be honest, i have not (yet) done any specific benchmarks for my application, but overall, last time i used 4.x, it seemed more snappy. But, this is good to hear :) ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: Lifetime of FreeBSD branches
On 2005.05.23 16:51:18 -0400, Mike Jakubik wrote: On Mon, May 23, 2005 3:42 pm, Colin Percival said: http://www.freebsd.org/security/ In addition to the material there (which is concerned with existing releases), FreeBSD 5.x is expected to be supported until late 2007 (FreeBSD 5.5 plus two years), and FreeBSD 6.x will probably be supported until early 2009 (the last FreeBSD 6.x release plus two years). Thanks for the info guys. Does this security support also mean that current ports will be compatible with the release? No, there are no guarantees about that. The ports/ people generally try to make things work with older releases, but there are no gurantees there. It's simply too much work to make such guarantees, and this is after all an volunteer project (for most parts anyway). See also http://www.freebsd.org/ports/ for the official statement. I'm surprised to see that 4.11 will be supported longer than RELENG_5. That is just the current status, RELENG_5 is almost certain to be supported longer than RELENG_4, but exactly how long isn't determined until FreeBSD 5.5, but Colin's timeline applies and is probably a very good estimate, since he is also one of the people that will actually work on supporting it :-). Guess my best bet would be to wait for 6.x. WRT. to security support there wouldn't be a difference. Now, does anyone know if a make buildworld/kernel update will be possible for 5.x to 6.x ? I'm assuming that they are similar enough for this to be possible. It's a much smaller step than 4.X - 5.X was, so it's much more likely that a the upgrade path will be much less painful, than 4.X - 5.X was/is. -- Simon L. Nielsen pgpKeXAoTgti8.pgp Description: PGP signature
Re: Performance of 4.x vs 5.x (Re: Lifetime of FreeBSD branches)
On Mon, May 23, 2005 at 05:00:13PM -0400, Mike Jakubik wrote: On Mon, May 23, 2005 3:51 pm, Kris Kennaway said: The common wisdom has been that FreeBSD 4.11 is faster than 5.4 on single processor systems. Imagine my surprise when I went and actually benchmarked this on the package build machines, and found that 5.4 outperforms 4.11 by at least 10% when performing identical workloads on identical UP hardware :-) Stay tuned for more details... To be honest, i have not (yet) done any specific benchmarks for my application, but overall, last time i used 4.x, it seemed more snappy. But, this is good to hear :) One thing that probably confuses and misleads a lot of people is when they build world or a kernel and notice that it's taking much longer than it did under 4.x, so they assume this means that 5.x is slower than 4.x. It doesn't. What it means is that 5.x and 4.x have different C compilers, and gcc 3.x is much slower at compiling code than gcc 2.x. You have to be very careful to draw conclusions based on subjective assessments like this. Kris pgp9W2pTiA38u.pgp Description: PGP signature
Re: Manipulating disk cache (buf) settings
On May 23, 2005, at 1:44 PM, John-Mark Gurney wrote: This is incorrect... FreeBSD merged the vm and buf systems a while back, so all of memory is used as a disk cache.. The buf cache is still used for filesystem meta data (and for pending writes of files, but those buf's reference the original page, not local storage)... Cool... So what would you recommend telling an application like Postgres what the cache size is? All of RAM? That seems unlikely given much of the ram is used for other things. Is there no upper bound in how much RAM will be used for the cache? Vivek Khera, Ph.D. +1-301-869-4449 x806 ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: Performance of 4.x vs 5.x (Re: Lifetime of FreeBSD branches)
Kris Kennaway wrote: One thing that probably confuses and misleads a lot of people is when they build world or a kernel and notice that it's taking much longer than it did under 4.x, so they assume this means that 5.x is slower than 4.x. It doesn't. What it means is that 5.x and 4.x have different C compilers, and gcc 3.x is much slower at compiling code than gcc 2.x. You have to be very careful to draw conclusions based on subjective assessments like this. Another thing might be that interactive response time seems to be worse. While I (or rather ports) unpack the firefox/thunderbird source, the machine is pretty much bogged down (mouse cursor jumps around, audio stutters...). Haven't seen that on FreeBSD since the 386 days. mkb. ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: Performance of 4.x vs 5.x (Re: Lifetime of FreeBSD branches)
On Mon, May 23, 2005 at 11:21:13PM +0200, Matthias Buelow wrote: Kris Kennaway wrote: One thing that probably confuses and misleads a lot of people is when they build world or a kernel and notice that it's taking much longer than it did under 4.x, so they assume this means that 5.x is slower than 4.x. It doesn't. What it means is that 5.x and 4.x have different C compilers, and gcc 3.x is much slower at compiling code than gcc 2.x. You have to be very careful to draw conclusions based on subjective assessments like this. Another thing might be that interactive response time seems to be worse. While I (or rather ports) unpack the firefox/thunderbird source, the machine is pretty much bogged down (mouse cursor jumps around, audio stutters...). Haven't seen that on FreeBSD since the 386 days. I don't run FreeBSD on my desktop machines so I haven't seen this myself. One obvious guess is that it's due to VFS being under Giant, which causes lots of contention with other subsystems that also require Giant, and therefore introduces latency. If so, you'd see a substantial performance improvement on 6.0 with debug.mpsafevfs=1. This option isn't yet ready for production use (especially on SMP machines) since it still contains bugs, but it would be interesting if someone who sees this problem could test it on 6.0. Any takers? Kris pgpGHmDcm6dNl.pgp Description: PGP signature
Re: Performance of 4.x vs 5.x (Re: Lifetime of FreeBSD branches)
On Mon, May 23, 2005 at 02:31:55PM -0700, Kris Kennaway wrote: On Mon, May 23, 2005 at 11:21:13PM +0200, Matthias Buelow wrote: Kris Kennaway wrote: One thing that probably confuses and misleads a lot of people is when they build world or a kernel and notice that it's taking much longer than it did under 4.x, so they assume this means that 5.x is slower than 4.x. It doesn't. What it means is that 5.x and 4.x have different C compilers, and gcc 3.x is much slower at compiling code than gcc 2.x. You have to be very careful to draw conclusions based on subjective assessments like this. Another thing might be that interactive response time seems to be worse. While I (or rather ports) unpack the firefox/thunderbird source, the machine is pretty much bogged down (mouse cursor jumps around, audio stutters...). Haven't seen that on FreeBSD since the 386 days. I don't run FreeBSD on my desktop machines so I haven't seen this myself. One obvious guess is that it's due to VFS being under Giant, which causes lots of contention with other subsystems that also require Giant, and therefore introduces latency. If so, you'd see a substantial performance improvement on 6.0 with debug.mpsafevfs=1. This option isn't yet ready for production use (especially on SMP machines) since it still contains bugs, but it would be interesting if someone who sees this problem could test it on 6.0. Also try defining PREEMPTION in your kernel on 5.x and above (if you are running i386 or amd64). There have been very occasional reports of panics with this option enabled (although I use it everywhere and have not seen problems on my heavily loaded machines), but interactive response should be much better. Kris pgpBVBIMYZ4Kx.pgp Description: PGP signature
Re: Lifetime of FreeBSD branches
On Mon, May 23, 2005 5:08 pm, Simon L. Nielsen said: On 2005.05.23 16:51:18 -0400, Mike Jakubik wrote: Thanks for the info guys. Does this security support also mean that current ports will be compatible with the release? No, there are no guarantees about that. The ports/ people generally try to make things work with older releases, but there are no gurantees there. It's simply too much work to make such guarantees, and this is after all an volunteer project (for most parts anyway). See also http://www.freebsd.org/ports/ for the official statement. Right, i didnt think so. Debian is a volunteer project too, and their packaging system supports all of their branches. I guess i should look into rolling my own packages, to be sure. And yes, i realize that we just dont have an infrastructure for something like this. ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: Recent 5.4-p1 upgrade issue (lib/libc.so.5)
--- Kris Kennaway [EMAIL PROTECTED] wrote:
On Mon, May 23, 2005 at 10:24:15AM -0700, Jon Passki wrote:
Here's what gets me: I was able to do a the supported upgrade
process in an unsupported manner (multiuser mode via ssh w/o a
shutdown inbetween, nor going into signle user mode) w/ no
issues
on the build host. What occurs in that process (make
buildworld;
make buildkernel; make installkernel; mergemaster -p; make
installworld; mergemaster) where libc can be replaced (assuming
it
uses install(1), which is also linked against libc) without
failure, but using tar causes it to fail? Ideas?
Look at how make installworld does the replacement safely.
Ah, makes sense now, but let me regurgitate:
According to src/Makefile.inc1, installword sets up INSTALLTMP with
some nifty files, along with the files previously in the obj tree
setup by phases such as bootstrap-tools. Since these are defined
later on in the path before the user's ${PATH}, one doesn't shoot
one's foot off when updating the binaries, correct?
In my circumstance, I don't have an obj tree on the dest. host, but
I do have /rescue. I could extract that on a first run and then
perform the later extractions with the updated tar (or just do it
all if /rescue/tar works anyway). Does this seem decent? Is there
a more elegant way?
Thanks for the heads up, Kris!
Jon
__
Do you Yahoo!?
Yahoo! Small Business - Try our new Resources site
http://smallbusiness.yahoo.com/resources/
___
freebsd-stable@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-stable
To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: Lifetime of FreeBSD branches
On Mon, 23 May 2005 23:08:18 +0200 Simon L. Nielsen [EMAIL PROTECTED] wrote: On 2005.05.23 16:51:18 -0400, Mike Jakubik wrote: On Mon, May 23, 2005 3:42 pm, Colin Percival said: http://www.freebsd.org/security/ In addition to the material there (which is concerned with existing releases), FreeBSD 5.x is expected to be supported until late 2007 (FreeBSD 5.5 plus two years), and FreeBSD 6.x will probably be supported until early 2009 (the last FreeBSD 6.x release plus two years). Thanks for the info guys. Does this security support also mean that current ports will be compatible with the release? No, there are no guarantees about that. The ports/ people generally try to make things work with older releases, but there are no gurantees there. It's simply too much work to make such guarantees, and this is after all an volunteer project (for most parts anyway). Not only work, but also a lack of resources; for example I just received a report from a 4.11 user regarding of of my ports that I'm unable to reproduce on my 5-STABLE and I don't have a 4.11 machine. In this case I strongly suspect a local problem, but if it is not I'll be forced to install a 4.11. Of course, is impossible to do this for all (supported branches x supported platforms), hence the official statement from http://www.freebsd.org/ports/. Before each release we have a ports freeze period when (almost) no update to the ports is made but our time is dedicated to make sure our ports work on that release. -- IOnut Unregistered ;) FreeBSD user ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: Recent 5.4-p1 upgrade issue (lib/libc.so.5)
On Mon, May 23, 2005 at 02:57:40PM -0700, Jon Passki wrote:
--- Kris Kennaway [EMAIL PROTECTED] wrote:
On Mon, May 23, 2005 at 10:24:15AM -0700, Jon Passki wrote:
Here's what gets me: I was able to do a the supported upgrade
process in an unsupported manner (multiuser mode via ssh w/o a
shutdown inbetween, nor going into signle user mode) w/ no
issues
on the build host. What occurs in that process (make
buildworld;
make buildkernel; make installkernel; mergemaster -p; make
installworld; mergemaster) where libc can be replaced (assuming
it
uses install(1), which is also linked against libc) without
failure, but using tar causes it to fail? Ideas?
Look at how make installworld does the replacement safely.
Ah, makes sense now, but let me regurgitate:
According to src/Makefile.inc1, installword sets up INSTALLTMP with
some nifty files, along with the files previously in the obj tree
setup by phases such as bootstrap-tools. Since these are defined
later on in the path before the user's ${PATH}, one doesn't shoot
one's foot off when updating the binaries, correct?
Well, it does that too, but it also installs libc itself in a safe way
using install(1).
Kris
pgpg7x07WVfXS.pgp
Description: PGP signature
Re: Performance of 4.x vs 5.x (Re: Lifetime of FreeBSD branches)
Kris Kennaway wrote: Also try defining PREEMPTION in your kernel on 5.x and above (if you are running i386 or amd64). There have been very occasional reports of panics with this option enabled (although I use it everywhere and have not seen problems on my heavily loaded machines), but interactive response should be much better. I now did this on 5.4-STABLE and I cannot observe any difference. The lags still happen in the same way. The only difference seems to be that with PREEMPTION, at and shortly after boot, response seems to be actually worse and from harddisk noise it doesn't seem to load stuff in one go but in chunks (at least that's how it sounds). That normalizes after a while, though. Weird. mkb. ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: Manipulating disk cache (buf) settings
Vivek Khera wrote this message on Mon, May 23, 2005 at 17:17 -0400: On May 23, 2005, at 1:44 PM, John-Mark Gurney wrote: This is incorrect... FreeBSD merged the vm and buf systems a while back, so all of memory is used as a disk cache.. The buf cache is still used for filesystem meta data (and for pending writes of files, but those buf's reference the original page, not local storage)... Cool... So what would you recommend telling an application like Postgres what the cache size is? All of RAM? That seems unlikely given much of the ram is used for other things. Is there no upper bound in how much RAM will be used for the cache? I'm not familar host Postgres uses the cache number to change it's behavior, but I would say choose a responable amount of memory that you expect to regularly have available on the system... If you are only using it for db, and a few other small processes, 512meg less than ram is probably reasonable... The other way is to try a few different values and see how it impacts performance.. -- John-Mark Gurney Voice: +1 415 225 5579 All that I will do, has been done, All that I have, has not. ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: Manipulating disk cache (buf) settings
On Mon, 23 May 2005, John-Mark Gurney wrote: Sven Willenberger wrote this message on Mon, May 23, 2005 at 10:58 -0400: We are running a PostgreSQL server (8.0.3) on a dual opteron system with 8G of RAM. If I interpret top and vfs.hibufspace correctly (which show values of 215MB and 225771520 (which equals 215MB) respectively. My understanding from having searched the archives is that this is the value that is used by the system/kernel in determining how much disk data to cache. This is incorrect... FreeBSD merged the vm and buf systems a while back, so all of memory is used as a disk cache.. Indeed. Statistics utilities still haven't caught up with dyson's changes in 1994 or 1995, so their display of statistics related to disk caching is very misleading. systat -v and top display vfs.bufspace but not vfs.hibufspace. Both of these are uninitersting. vfs.bufspace gives the amount of virtual memory that is currently allocated to the buffer cache. vfs.hibufspace gives the maximum for this amount. Virtual memory for buffers is almost never released, so on active systems vfs.bufspace is close to the maximum. The maximum is just a compile-time constand (BKVASIZE) times a boot-time constant (nbuf). There is no way to tell from userland exactly how much of memory is used for the vm part of the disk cache. inact in systat -v gives a maximum. Watch heavy file system for a while and you may see inact increase as vm is used for disk data. It decreases mainly when a file system is unmounted. Otherwise, it tends to stay near its maximum, with pages for not recently used disk data being reused for something else (newer disk data or processes). The buf cache is still used for filesystem meta data (and for pending writes of files, but those buf's reference the original page, not local storage)... This is mostly incorrect. The buffer cache is now little more than a window on vm. Metadata is backed by vm except for low quality file systems. Directories are backed by vm unless vfs.vmiodirenable is 0 (not the default). Just as an experiment, on a quiet system do: dd if=/dev/zero of=somefile bs=1m count=2048 and then read it back in: dd if=somefile of=/dev/null bs=1m and watch systat or iostat and see if any of the file is read... You'll probably see that none of it is... Also, with systat -v: - start with inact small and watch it grow as the file is cached - remove the file and watch inact drop. I haven't tried this lately. The system has some defence against using up all of the free and inactive pages for a single file to the exclusion of other disk data, so you might not get 2GB cached even if you have 4GB memory. If that is in fact the case, then my question would be how to best increase the amount of memory the system can use for disk caching. Just add RAM and don't run bloatware :-). Bruce ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: Lifetime of FreeBSD branches
Random comment from the peanut gallery, but ... (B (B Thanks for the info guys. Does this "security support" also mean that (B current ports will be compatible with the release? (B (B No, there are no guarantees about that. The ports/ people generally (B try to make things work with older releases, but there are no gurantees (B there. It's simply too much work to make such guarantees, and this is (B after all an volunteer project (for most parts anyway). See also (B http://www.freebsd.org/ports/ for the "official" statement. (B (B Right, i didnt think so. Debian is a volunteer project too, and their (B packaging system supports all of their branches. I guess i should look (B into rolling my own packages, to be sure. And yes, i realize that we just (B dont have an infrastructure for something like this. (B (BI'm thinking that, if a company really doesn't have the infrastructure, (Bthere are several good options. You mention Linux. MacOSX is closer to (Bthe BSDs than Linux in many ways, tends to have relatively long-term (Bstability, and you can pay Apple for a rather high level of support if (Byou join their developer's program. (B (BThe best option, however, may be to invest in the infrastructure -- a (Blong term relationship with a qualified contractor, or even an employee (Bwhose primary duty would be to (learn how to) do the heavy lifting on (Bbackporting and upgrading. That way, the OS itself becomes more a part (Bof the company's resources. (B (B-- (BJoel Rees [EMAIL PROTECTED] (Bdigitcom, inc. $B3t<02q
Re: Lifetime of FreeBSD branches
On Tue, May 24, 2005 at 10:45:48AM +0900, Joel wrote: Random comment from the peanut gallery, but ... Thanks for the info guys. Does this security support also mean that current ports will be compatible with the release? No, there are no guarantees about that. The ports/ people generally try to make things work with older releases, but there are no gurantees there. It's simply too much work to make such guarantees, and this is after all an volunteer project (for most parts anyway). See also http://www.freebsd.org/ports/ for the official statement. Right, i didnt think so. Debian is a volunteer project too, and their packaging system supports all of their branches. I guess i should look into rolling my own packages, to be sure. And yes, i realize that we just dont have an infrastructure for something like this. I'm thinking that, if a company really doesn't have the infrastructure, there are several good options. You mention Linux. MacOSX is closer to the BSDs than Linux in many ways, tends to have relatively long-term stability, and you can pay Apple for a rather high level of support if you join their developer's program. The best option, however, may be to invest in the infrastructure -- a long term relationship with a qualified contractor, or even an employee whose primary duty would be to (learn how to) do the heavy lifting on backporting and upgrading. That way, the OS itself becomes more a part of the company's resources. Didn't someone announce a few months ago that they were going to work on supporting ports with older releases? I'm sure they'd welcome support, whether financial, material or otherwise. Kris pgpih2tYwnICs.pgp Description: PGP signature
Can objcopy(1) handle coff? (was update math/mprime)
Hi, I am having trouble updating the port math/mprime. I need to convert from .obj coff to .o elf32. However, I get a complain Invalid bfd target I have the sample port at http://people.FreeBSD.org/~lioux/mprime.tgz I believe that the problem is related to the fact that we are unable to handle coff files. Am I doing something wrong? Just try building it to see the problem. FreeBSD exxodus.fedaykin.here 5.4-STABLE FreeBSD 5.4-STABLE #3: Sun May 8 10:28:48 BRT 2005 [EMAIL PROTECTED]:/usr/obj/usr/src/sys/LIOUX i386 Script started on Mon May 23 22:37:29 2005 === Extracting for mprime-0.0.23.5 = Checksum OK for mprime/source23.zip. = Checksum OK for mprime/prime95-text-2004022600-23.5.tar.bz2. === mprime-0.0.23.5 depends on executable: unzip - found /bin/cp /usr/home/lioux/src/myports/ports/math/mprime/files/makebsd /usr/home/lioux/src/myports/ports/math/mprime/work/linux === Patching for mprime-0.0.23.5 === mprime-0.0.23.5 depends on executable: gmake - found === Configuring for mprime-0.0.23.5 === Building for mprime-0.0.23.5 rm -f mprime sprime prime.o menu.o mult.o mult1.o mult2.o mult2a.o mult3.o mult3a.o mult4.o mult4a.o mult4b.o mult1p.o mult2p.o mult2ap.o mult3p.o mult3ap.o mult3q.o mult3aq.o mult4p.o mult4ap.o mult4bp.o mult4q.o mult4aq.o mult4bq.o mult1aux.o mult2aux.o mult3aux.o mult3auq.o mult4aux.o mult4auq.o xmult1.o xmult1ax.o xmult2.o xmult2a.o xmult2ax.o xmult3.o xmult3a.o xmult3ax.o ecmhelp.o cpuid.o dummy4.o dummy8.o dummy12.o dummy16.o dummy20.o dummy24.o dummy28.o dummyt4.o dummyt8.o dummyt12.o dummyt16.o dummyt20.o dummyt24.o dummyt28.o [ ! -e ../security.h ] touch ../security.h || true [ ! -e ../security.c ] touch ../security.c || true /usr/local/libexec/ccache/cc -O -pipe -pipe -funit-at-a-time -m3dnow -msse -mfpmath=sse,387 -falign-functions -fforce-addr -fforce-mem -foptimize-register-move -foptimize-sibling-calls -fpeel-loops -fprefetch-loop-arrays -freorder-blocks -march=athlon-xp -I.. -malign-double -c prime.c /usr/local/libexec/ccache/cc -O -pipe -pipe -funit-at-a-time -m3dnow -msse -mfpmath=sse,387 -falign-functions -fforce-addr -fforce-mem -foptimize-register-move -foptimize-sibling-calls -fpeel-loops -fprefetch-loop-arrays -freorder-blocks -march=athlon-xp -I.. -malign-double -c menu.c menu.c: In function `options_preferences': menu.c:698: warning: the address of `PRIMENET', will always evaluate as `true' menu.c:700: warning: the address of `PRIMENET', will always evaluate as `true' menu.c:702: warning: the address of `PRIMENET', will always evaluate as `true' objcopy -v --input-target=coff-i386 --output-target=elf32-i386-freebsd ../prime95/mult.obj mult.o objcopy: ../prime95/mult.obj: Invalid bfd target gmake: *** [mult.o] Error 1 *** Error code 2 Stop in /usr/home/lioux/src/myports/ports/math/mprime. Script done on Mon May 23 22:37:32 2005 ps: Please, CC: me because I do not subscribe to this mailing list. -- Mario S F Ferreira - DF - Brazil - I guess this is a signature. feature, n: a documented bug | bug, n: an undocumented feature pgp5K8Pe0QCEm.pgp Description: PGP signature
Re: new base system snmpd
Vivek, On Mon, May 23, 2005 at 11:12:50AM -0400, Vivek Khera wrote: V I see that 5.4-STABLE has an snmpd as core to the system. Are there V any accompanying docs on how to use it? The man page and sample V config file are all seemingly geared towards the personal V implementation of the author, and there is no information at all on V extending it. V V (this seems to be a big trend in features lately... serious lack of V documentation suitable for those who are not the software author...) Yes, you are right. This fine piece of software is poorly documented. It lacks a good doc for newbies to start with. A migration guide from net-snmp would be important, too. Volunteers are welcome. Although author doesn't have time to write extended documentation, he is very responsive on questions. So, a volunteer who takes this task will receive answers to all his questions. P.S. Default configuration file and startup script have already been committed to RELENG_5. -- Totus tuus, Glebius. GLEBIUS-RIPN GLEB-RIPE ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: Syntax Error in Kernel
could someone explain why kernel ppp is needed at all? It's needed if you want to use it, of course :) the context is palm usb support randy ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: nForce 4, SATA Drive only runs at UDMA33?
Here's a recap of all the things I've tried and discovered in a bunch of testing today. Tried mkIII m patches and that doesn't show atapici1 or atapici2 - they just show as GENERIC with drives as UDMA33 Tried mkIII n patches and then atapici1 shows as nForce4 with SATA drives but has further problems detailed below. atapici2 always shows up in dmesg as GENERIC no matter what. Tried custom kernel, disabling all other parts of ATA with no difference. # ATA and ATAPI devices device ata device atadisk # ATA disk drives #device ataraid # ATA RAID drives #device atapicd # ATAPI CDROM drives #device atapifd # ATAPI floppy drives #device atapist # ATAPI tape drives options ATA_STATIC_ID # Static device numbering Tried disabling the standard IDE ports in bios, turning off DMA on SATA, and other bios tweaks with no changes. With the n patches I get randomly alternating: lockup, Fatal trap 12 panic, or full boot but then it can't find the root filesystem as the disk is showing as detached. If I get lucky and it goes most of the way I get results like the following: ata2: CONNECT REQUESTED ata2: DISCONNECT REQUESTED ... (lots of those!) ad6: 70911MB WDC WD740GD-00FLA2 31.08F31 at ata3-master SATA 150 ad6: detached ata3: DISCONNECTED ata2: CONNECTED ata2: SATA connect status= ata2: DISCONNECTED ata3: CONNECTED ata3: SATA connect ready time=0ms ... Mounting root from ufs:/dev/ad6s1a setrootbyname failed ffs_mountroot: can't find rootvp root mount failed:6 Is there something else I should try to help in debugging this further? Is there anything in -CURRENT that would help this to work better than 5-STABLE plus the ATA mkIII n patches? Thanks for all the help! --Alan Bryan --- Doug White [EMAIL PROTECTED] wrote: On Fri, 20 May 2005, alan bryan wrote: --- Doug White [EMAIL PROTECTED] wrote: Can you post the output of pciconf -lv? The nForce IDE controller is properly detected, but it looks like there's another one in the system. Looking at the spec for the system it may be the proprietary nVidia RAID controller. The pciconf output should help us identify if thats the issue. FYI: RAID features are disabled in the BIOS, I'm just trying to get a single SATA drive to work at full speed. The other drive in this system is IDE and that seems to be working at proper speed. Thanks for the help! I guess turning off the RAID converts the chips into standard SATA controllers. I'll have to look into that. An nForce 4 machine recently appeared at work, so I'll see what I can get it to do. [EMAIL PROTECTED]:6:0: class=0x01018a card=0x50361297 chip=0x005310de rev=0xa2 hdr=0x00 vendor = 'NVIDIA Corporation' class= mass storage subclass = ATA [EMAIL PROTECTED]:7:0: class=0x010185 card=0x50361297 chip=0x005410de rev=0xa3 hdr=0x00 vendor = 'NVIDIA Corporation' class= mass storage subclass = ATA [EMAIL PROTECTED]:8:0: class=0x010185 card=0xcb8410de chip=0x005510de rev=0xa3 hdr=0x00 vendor = 'NVIDIA Corporation' class= mass storage subclass = ATA It looks like sos added support for atapci1 and 2 in this listing in the ATAmkIII patchset. While that patchset is in -CURRENT you'll have to apply the -stable patches yourself. Search the list archives for the location, soren posts it now and again. -- Doug White| FreeBSD: The Power to Serve [EMAIL PROTECTED] | www.FreeBSD.org __ Yahoo! Mail Mobile Take Yahoo! Mail with you! Check email on your mobile phone. http://mobile.yahoo.com/learn/mail ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: Syntax Error in Kernel
On Tue, 24 May 2005 12:27, Randy Bush wrote: could someone explain why kernel ppp is needed at all? It's needed if you want to use it, of course :) the context is palm usb support Seems odd you would _need_ kernel PPP support for that.. My PocketPC appears as a USB almost serial port (uppc) which you talk PPP over (by running userland PPP). -- 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 pgp178qHUxVae.pgp Description: PGP signature
folding client stopped working, is it because of linux?
I did a system update and after that my folding @ home client will not work without me doing make install in linux_base-8 ports dir. BTW, linux is already installed from before the update and even after reinstalling after the update the systems seems to forget it is there after a reboot. I can type make install and the port installs, but since I don't do a make clean first it returns immediatily. After I do this [EMAIL PROTECTED] runs fine. My network card uses the nvnet driver from ports which still works at boot with out me needing to make install for the linux port. I believe this driver requires the linux emulation to work btw. Any ideas as to why this might be? A corupt makefile in my ports folder? A change to the linux emulation? FreeBSD BARTON 5.4-STABLE FreeBSD 5.4-STABLE #1: Fri May 20 03:23:59 EDT 2005 [EMAIL PROTECTED]:/usr/obj/usr/src/sys/NINAMORI i386 $ ls -l /var/db/pkg | grep linux_ drwxr-xr-x 2 root wheel 512 May 22 17:48 linux_base-8-8.0_6 Thx, Jason ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: Lifetime of FreeBSD branches
It might be beneficial (pipe-dream perhaps) if the all the BSDs coalesced around one port/packaging system. I hear that netbsd's port system has the metadata necessary to support different OSs and different OS versions within one coherent system. What do you think about the relative strengths of pkgsrc and the FreeBSD ports system? -Jon On Mon, 23 May 2005, Kris Kennaway wrote: On Tue, May 24, 2005 at 10:45:48AM +0900, Joel wrote: Random comment from the peanut gallery, but ... Thanks for the info guys. Does this security support also mean that current ports will be compatible with the release? No, there are no guarantees about that. The ports/ people generally try to make things work with older releases, but there are no gurantees there. It's simply too much work to make such guarantees, and this is after all an volunteer project (for most parts anyway). See also http://www.freebsd.org/ports/ for the official statement. Right, i didnt think so. Debian is a volunteer project too, and their packaging system supports all of their branches. I guess i should look into rolling my own packages, to be sure. And yes, i realize that we just dont have an infrastructure for something like this. I'm thinking that, if a company really doesn't have the infrastructure, there are several good options. You mention Linux. MacOSX is closer to the BSDs than Linux in many ways, tends to have relatively long-term stability, and you can pay Apple for a rather high level of support if you join their developer's program. The best option, however, may be to invest in the infrastructure -- a long term relationship with a qualified contractor, or even an employee whose primary duty would be to (learn how to) do the heavy lifting on backporting and upgrading. That way, the OS itself becomes more a part of the company's resources. Didn't someone announce a few months ago that they were going to work on supporting ports with older releases? I'm sure they'd welcome support, whether financial, material or otherwise. Kris ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: Syntax Error in Kernel
could someone explain why kernel ppp is needed at all? It's needed if you want to use it, of course :) the context is palm usb support Seems odd you would _need_ kernel PPP support for that.. seemed odd to me too. but take a look back up the thread, or just at the reffed site, http://www.thedotin.net/maillists/coldsync-hackers/msg01954.html randy ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: em and bge driver MPSAFE?
On Sat, May 21, 2005 at 11:53:26PM -0700, John-Mark Gurney wrote: Mipam wrote this message on Wed, May 11, 2005 at 16:39 +0200: Perhaps lame to ask, But are the em and bge driver MPSAFE? I couldn't find notes about being mpsafe in the man pages of these drivers? I was about to point you to: http://www.freebsd.org/projects/busdma/ But realized that you probably wanted status on 5.x, and not HEAD... a quick look at the code shows that both em and bge are MPSAFE... I can tell because of no references to Giant or GIANT, and that it using XX_LOCK and has functions ending in _locked in them... Maybe we need to expand the busdma project to include which driver status for 5.x and HEAD? Probably You are wrong at least about em driver: it steel makes page faults in kernel mode on my Dual Xeon machine. :-( debug.mpsafenet=0 fix this issue completely. Serg N. Voronkov, Sibitex JSC. P.S.: Server is under moderate load and is very important to keep it as stable as possible, so I can't provide a dump, sorry. ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: Syntax Error in Kernel
On Tue, 24 May 2005 13:04, Randy Bush wrote: could someone explain why kernel ppp is needed at all? It's needed if you want to use it, of course :) the context is palm usb support Seems odd you would _need_ kernel PPP support for that.. seemed odd to me too. but take a look back up the thread, or just at the reffed site, http://www.thedotin.net/maillists/coldsync-hackers/msg01954.html Hmm it says to run /usr/bin/ppp out of usbd which is userland PPP.. You don't need ppp in the kernel for that, only if you are using pppd. The instrucions there look pretty identical for what you have to do to get a Pocket PC talking too :) -- 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 pgpD8DzifAsWm.pgp Description: PGP signature
Re: nForce 4, SATA Drive only runs at UDMA33?
On 24/05/2005, at 5:01, alan bryan wrote: Here's a recap of all the things I've tried and discovered in a bunch of testing today. Tried mkIII m patches and that doesn't show atapici1 or atapici2 - they just show as GENERIC with drives as UDMA33 Tried mkIII n patches and then atapici1 shows as nForce4 with SATA drives but has further problems detailed below. atapici2 always shows up in dmesg as GENERIC no matter what. ... Is there anything in -CURRENT that would help this to work better than 5-STABLE plus the ATA mkIII n patches? Yes, I've done quite a bit of changes that affects this on -current. However its done blindfolded since I dont have a nForce4 based system here yet (but should soon). - Søren ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to [EMAIL PROTECTED]
ati9550
Dear all! I have graphic card as in subject. With ati and radeon driver it makes not so clear picture, looking out of focus. 5.4, amd64 version. Does someone have similar behaveour? Best regards Zoran ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: rl0: discard oversize frame
Hello, 3 out of 4 of my systems at home use realtek ( rl0 ) NIC's and i've never had a problem with them. Have you tested that NIC with another OS? Try using it with a linux distro or windows and see if the network card holds up. If the card still fails put it in another machine and try those operating systems again, if it then works fine try it in another PCI slot on your machine that you are getting the error from. If it still gives you the same error, guess what? its time to get another NIC. hope that helps :-) Jayton Garnett Message: 4 Date: Mon, 23 May 2005 22:16:36 +0200 From: Jack Raats [EMAIL PROTECTED] Subject: rl0: discard oversize frame To: freebsd-questions@freebsd.org, FreeBSD Stable freebsd-stable@freebsd.org Message-ID: [EMAIL PROTECTED] Content-Type: text/plain; charset=iso-8859-1 I'm running FreeBSD 5.4-STABLE. At this moment I'm getting all kind of network losses due to the error rl0: discard oversize frame Google showed that a lot of PC suffers form this, but I didn't fine the cure :-( Can anyone help me with a cure? Met vriendelijke groeten Jack Raats ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to [EMAIL PROTECTED]
