Re: bin/40278: mktime returns -1 for certain dates/timezones when it should normalize

With the testcode I put on http://www.stack.nl/~marcolz/FreeBSD/pr-bin-40278/40278.c I can reproduce it on FreeBSD 4.11: output on 4.11-STABLE -- Init: mktime: 1014944400 Fri Mar 1 02:00:00 CET 2002 1: mktime: 4294967295 Fri Apr 0 02:00:00 CET 2002 Init: mktime: 1014944400 Fri Mar 1 02:00

Boot-time pass for geli on 7.0-BETA2 (and RELENG_7) not working for me.

Hi. I can't get the kernel to accept my passphrase at boot time. Excerpt from dmesg: ... FreeBSD 7.0-BETA2 #0: Tue Nov 6 15:06:03 UTC 2007 [EMAIL PROTECTED]:/usr/obj/usr/src/sys/LAPCAT Preloaded elf kernel "/boot/kernel/kernel" at 0x808a5000. Preloaded elf obj module "/boot/kernel/

Re: Boot-time pass for geli on 7.0-BETA2 (and RELENG_7) not working for me.

On Wed, Nov 07, 2007 at 10:41:40AM +0100, Karsten Rothemund wrote: > On Tue, Nov 06, 2007 at 04:35:24PM +0100, Marc Olzheim wrote: > > Hi. > > > > I can't get the kernel to accept my passphrase at boot time. > > > > What kind of passphrase do you use? I had

Re: Boot-time pass for geli on 7.0-BETA2 (and RELENG_7) not working for me.

On Thu, Nov 08, 2007 at 05:09:34PM +0100, Thorsten Trampisch wrote: > Hello, > > today I updated from 6.2-RELEASE-p8 to 7.0-BETA2 as well. > I've ran into the same problem with the password input to GELI on boot time. > Chars are showing up after several keypresses. > > After removing the new dco

Re: Boot-time pass for geli on 7.0-BETA2 (and RELENG_7) not working for me.

On Sun, Nov 11, 2007 at 03:54:24PM +0100, Marc Olzheim wrote: > > today I updated from 6.2-RELEASE-p8 to 7.0-BETA2 as well. > > I've ran into the same problem with the password input to GELI on boot time. > > Chars are showing up after several keypresses. > > >

FreeBSD 7.0-BETA2 /usr/src/sys/conf/kern.mk

For the MACHINE_ARCH == "amd64" & ${CC} != "icc" case, the -mno-sse3 flag that *is* set for MACHINE_ARCH == "i386", is not set. I don't think the current gcc actually uses sse3 anywhere in the kernel compile, as my kernels are working as normal, but for the sake of completeness, I suggest the atta

Re: FreeBSD 7.0-BETA2 /usr/src/sys/conf/kern.mk

On Sat, Nov 17, 2007 at 12:14:46PM +0100, Marc Olzheim wrote: > For the MACHINE_ARCH == "amd64" & ${CC} != "icc" case, > the -mno-sse3 flag that *is* set for MACHINE_ARCH == "i386", is not set. > > I don't think the current gcc actually uses s

Re: Boot-time pass for geli on 7.0-BETA2, -BETA3 and RELENG_7 not working for me.

On Wed, Nov 14, 2007 at 03:08:20PM +0100, Marc Olzheim wrote: > > > today I updated from 6.2-RELEASE-p8 to 7.0-BETA2 as well. > > > I've ran into the same problem with the password input to GELI on boot > > > time. > > > Chars are showing up after severa

Re: FreeBSD 7.0-BETA2 /usr/src/sys/conf/kern.mk

On Sat, Nov 17, 2007 at 12:14:46PM +0100, Marc Olzheim wrote: > For the MACHINE_ARCH == "amd64" & ${CC} != "icc" case, > the -mno-sse3 flag that *is* set for MACHINE_ARCH == "i386", is not set. > > I don't think the current gcc actually uses s

Re: portmaster not ask for port deletion

On Mon, Aug 24, 2009 at 12:03:40PM -0300, Nenhum_de_Nos wrote: > hail, > > portmaster is great, but this is keeping me from using it.I want to fire a > portmaster -af and let it there until its done. for every package it asks > this. is ther any way to make it not ask ? delete and go ahead ? > >

Re: SCB - timed out on FreeBSD 4.10-p2

On Sun, Nov 07, 2004 at 04:16:51PM -0800, Dave Hayes wrote: > /kernel: da0 at ahd0 bus 0 target 0 lun 0 > /kernel: da0: Fixed Direct Access SCSI-3 device > /kernel: da0: 320.000MB/s transfers (160.000MHz, offset 63, 16bit), Tagged > Queueing Enabled > /kernel: da0: 35003MB (71687372 512 byte sec

Re: unkillable processes after debugging on 5.3R

The scheduler is plain SCHED_4BSD btw. lsof (ports/sysutils) doesn't display anything for pid 20328, but does for 20326. The output fstat -vp 20328 generates changes over time; when I try it now, I get: turtle:/#fstat -vp 20328 USER CMD PID FD MOUNT INUM MODE

Lock Order Reversal

lock order reversal 1st 0xc5d4c900 inp (tcpinp) @ /usr/src/sys/netinet/tcp_usrreq.c:303 2nd 0xc6a0cd10 so_rcv (so_rcv) @ /usr/src/sys/netinet/tcp_usrreq.c:304 3rd 0xc68c1630 inp (tcpinp) @ /usr/src/sys/netinet/in_pcb.c:971 kern.ostype: FreeBSD kern.osrelease: 5.4-PRERELEASE kern.osrevision: 199

Re: Lock Order Reversal

On Mon, Mar 14, 2005 at 07:34:21PM +, Bjoern A. Zeeb wrote: > > lock order reversal > > 1st 0xc5d4c900 inp (tcpinp) @ /usr/src/sys/netinet/tcp_usrreq.c:303 > > 2nd 0xc6a0cd10 so_rcv (so_rcv) @ /usr/src/sys/netinet/tcp_usrreq.c:304 > > 3rd 0xc68c1630 inp (tcpinp) @ /usr/src/sys/netinet/in_pcb

Re: Lock Order Reversal

On Tue, Mar 15, 2005 at 12:58:37AM +0100, Marc Olzheim wrote: > Alas, no KDB builtin :-/ Hmmm...: rave:/# sysctl debug.kdb.available | less debug.kdb.available: rave:/# Is that supposed to happen ? Marc pgpu5P0fBvKKJ.pgp Description: PGP signature

Re: boot0: To beep or not to beep?

On Wed, Mar 30, 2005 at 05:00:31PM +0200, Ulrich Spoerlein wrote: > I really don't know any assembler, but reading > /sys/boot/i386/boot0/boot0.S leads me to believe that there should be a > beep on every boot. However, I certainly don't want any beeps from > boot0, can I comment out the first two

Re: kern/79208: Deadlock or starvation doing heavy NFS writes with writev

-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 FreeBSD 5.3-RELEASE-p6 (SMP) #0: Wed Mar 30 14:28:31 CEST 2005 on i386 is vulnerable as well, so it has been b0rken for some time now, I'm afraid. Marc -BEGIN PGP SIGNATURE- Version: GnuPG v1.2.4 (FreeBSD) iD8DBQFCUT8hezjnobFOgrERAg7xAKCVF1sL

Re: kern/79208: Deadlock or starvation doing heavy NFS writes with writev

Hmm, network services like an ircd, keep functioning until they need to write a log entry, so it seems that the only thing that's "hanging", is the VFS layer. Marc ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/free

Re: SuperMicro X5DP8-G2MB/(2)XEON 2.4/1GB RAM 5.4-S Freeze

On Mon, Apr 11, 2005 at 10:12:32PM -0400, Aaron Summers wrote: > We have a SuperMicro X5DP8-G2 Motherboard, 2xXEON 2.4, 1GB RAM server > running 5.4-STABLE that keeps freezing up. We have replaced RAM, HD, > SCSI controller, etc. To no avail. We are running SMP GENERIC > Kernel. I cannot get th

Re: kernel killing processes when out of swap

On Tue, Apr 12, 2005 at 03:06:41PM +0100, Nick Barnes wrote: > The right choice is for mmap() to return ENOMEM, and then for malloc() > to return NULL, but almost no operating systems make this choice any > more. No, the problem occurs only when previously allocated / mmap()d blocks are actually u

Re: SuperMicro X5DP8-G2MB/(2)XEON 2.4/1GB RAM 5.4-S Freeze

On Tue, Apr 12, 2005 at 10:40:10AM -0400, Don Bowman wrote: > The problem is with the periodic SMM interrupt and the bios. > > The attached program (ich-periodic-smm-disable.c) will fix the problem. > For more information on what it does, see the Intel ICH3 datasheet. > > compile as 'gcc ich-peri

Re: pxeboot

On Wed, Apr 13, 2005 at 07:06:32PM +0200, Helmut Allwang wrote: > Hello, > > it was possible for me, to boot a bootable floppy-image over pxeboot. > > Is it possible to boot a CD-image over pxeboot? You mount the image (mdconfig + mount_cd9660) on your tftp server and off you go... ;-) load lo

Re: SuperMicro X5DP8-G2MB/(2)XEON 2.4/1GB RAM 5.4-S Freeze

On Tue, Apr 12, 2005 at 05:01:43PM +0200, Marc Olzheim wrote: > On Tue, Apr 12, 2005 at 10:40:10AM -0400, Don Bowman wrote: > > The problem is with the periodic SMM interrupt and the bios. > > > > The attached program (ich-periodic-smm-disable.c) will fix the problem. > &

Re: NFS defaults for read/write blocksize....(Was: Re: 5.4/amd64 console hang)

On Mon, Apr 18, 2005 at 10:43:46AM +0200, Claus Guttesen wrote: > > Has it even been considered to up these values to something bigger?? > > Read- and write-size of 32768 seems to work optimal for me: > > nfssrv:/nfsmnt /localsrv/nfsmnt nfs > rw,tcp,intr,nfsv3,-w=32768,-r=32768 00 I

Re: PXEBOOT/TFTPBOOT + big MD_ROOT problem

On Tue, Apr 19, 2005 at 09:52:07AM +0200, Emmanuel Chriqui wrote: > Hi, > > I'm trying to make very big MD_ROOT (300MB) sent using PXEBOOT+TFTPBOOT. No > NFS. Any reasons for not using NFS ? > I use i386/5.4RC2/TFTPD/PXEBOOT+TFTPBOOT . > (same pb with a 5.3). > > Am I missing something obvio

Re: PXEBOOT/TFTPBOOT + big MD_ROOT problem

On Tue, Apr 19, 2005 at 09:31:10PM +0200, Emmanuel Chriqui wrote: > This is roughly how it works under our linux servers, webservers, etc... I > was hoping to avoid that approach (less work.. less maintenance..). > > Am I the only one on earth to need a big MFSROOT ??? > :) Hmm, I guess so. :-P

Re: FreeBSD 5.3p6-5.4RC3, Supermicro X6DHR-8G, Dual 3.6GHzXeons,Adaptec aic7902 SCSI interface doesn't work in UPkernel

On Mon, Apr 25, 2005 at 08:06:19PM -0700, Ade Lovett wrote: > > SuperMicro [...] Seagate [...] > > on-board aic7902 > > and, from your dmesg output: > > da0: Fixed Direct Access SCSI-3 device > da0: 320.000MB/s transfers [...] > > At an absolute minimum, have the existing drive swapped out for

Re: NFS client/buffer cache deadlock

[changed cc: from standards@ back to stable@ again.] On Tue, Apr 26, 2005 at 12:25:49PM -0400, Brian Fundakowski Feldman wrote: > You can assure that this happens in only two ways: > > 1. Make a complete copy of the data. This is what currently occurs: >it gets stuffed into the buffer cache

Re: NFS client/buffer cache deadlock

On Tue, Apr 26, 2005 at 03:36:02PM -0400, Brian Fundakowski Feldman wrote: > I'm still guessing that for whatever reason your writes on the FreeBSD > 4.x NFS client are not using NFSv3/transactions. The second method > I just now implemented; it works fine except for being slower since > all data

Panic 5.4-stable of 3 weeks ago

FreeBSD 5.4-STABLE #5: Wed Apr 6 15:16:36 CEST 2005 Slab at 0xc866cfa8, freei 0 = 12. panic: Duplicate free of item 0xc866c000 from zone 0xc103e9a0(Mbuf) cpuid = 2 KDB: stack backtrace: kdb_backtrace(100,c569dd80,0,c866cfa8,c56363c0) at 0xc053f121 = kdb_backtrace+0x29 panic(c06d8c62,c866c000,c1

Re: NFS client/buffer cache deadlock

On Wed, Apr 27, 2005 at 12:08:57PM -0400, Brian Fundakowski Feldman wrote: > > Yes, a single writev(). Just like in the kern/79207 PR. > > > > It doesn't have to be superfast (why would I use NFS otherwise), just as > > long as it's threadsafe / atomic. > > Alright, this will do synchronous, inst

Reproducible panic 5.4-stable when booting with -v

The same system about which I just mailed, crashes when booting with verbose logging enabled. With a normal boot, everything's ok... Marc KDB: debugger backends: ddb KDB: current backend: ddb 131072K of memory above 4GB ignored Copyright (c) 1992-2005 The FreeBSD Project. Copyright (c) 1979, 1980,

Re: [4.11] sysctl reports garbage

On Wed, Apr 27, 2005 at 07:46:28PM +0200, Marc Santhoff wrote: > Hi, > > I've updates my system this morning after reading about the usb mfc. The > sources used before are dated from january. I'm not sure if this error > was triggered by the update, but: > > Using "sysctl -a" it seems to lose tra

Re: [4.11] sysctl reports garbage

On Wed, Apr 27, 2005 at 08:24:36PM +0200, Marc Santhoff wrote: > > That is 'kern.msgbuf' ;-) > > Hm, I've never seen such a verbose output before. > > Has anything changed in that area? And why does it still occur after a > reboot, normally buffers are only temporarily valid(at least I thought >

Re: NFS client/buffer cache deadlock

On Wed, Apr 27, 2005 at 02:34:35PM -0400, Brian Fundakowski Feldman wrote: > Alright, thanks for helping with this :-) Do you think you can find > a way to tell if in 4.x you're actually using NFSv3/transactions? I > would really like to know why 4.x isn't deadlocking, and that's the > most plausi

Re: NFS client/buffer cache deadlock

On Wed, Apr 27, 2005 at 03:06:27PM -0400, Brian Fundakowski Feldman wrote: > > How can I tell whether it uses transactions ? > > I am not sure -- it should with NFSv3 though. Does "mount -v" tell > you anything more detailed? I suppose that nfsstat may also be used > -- the "commit" count should

[5.3Rp6] UFS buffer cache deadlock (was: NFS client/buffer cache deadlock)

On Wed, Apr 27, 2005 at 10:17:46AM +0200, Marc Olzheim wrote: > > > Btw. running the writev program with 20 * 100 MB on UFS on a 512MB > > > FreeBSD 6-CURRENT system practicly locks the filesystem down _and_ > > > causes all processes to be swapped out in favor of t

Re: NFS client/buffer cache deadlock

On Wed, Apr 27, 2005 at 03:41:44PM -0400, Brian Fundakowski Feldman wrote: > Alright, thanks for testing. So the same bug exists in 4.x but may > not actually deadlock the buffer cache in the same circumstances. > If you feel like playing with it anymore, I would expect a certain > write block siz

Re: Reproducible panic 5.4-stable when booting with -v

On Fri, Apr 29, 2005 at 07:28:42PM -0700, Doug White wrote: > > The same system about which I just mailed, crashes when booting with > > verbose logging enabled. With a normal boot, everything's ok... > > Looks like it perturbs some sort of timing and upsets the SCSI card. Is > this on a serail c

Re: NFS client/buffer cache deadlock

On Wed, Apr 27, 2005 at 12:08:57PM -0400, Brian Fundakowski Feldman wrote: > Alright, this will do synchronous, instead of short, writes (also, > of course, not deadlock the system) if you are trying to use an > excessively large buffer size. > >

Instant reboot FreeBSD 5.4-STABLE amd64

FreeBSD 5.4-STABLE #12: Mon May 2 19:23:22 CEST 2005 [EMAIL PROTECTED]:/usr/obj/usr/src/sys/HAMMER hammer:~/src/hak/fpu>gdb ./fpu5th 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 chan

Re: Instant reboot FreeBSD 5.4-STABLE amd64

On Tue, May 03, 2005 at 04:43:13PM +0200, Marc Olzheim wrote: > FreeBSD 5.4-STABLE #12: Mon May 2 19:23:22 CEST 2005 [EMAIL > PROTECTED]:/usr/obj/usr/src/sys/HAMMER > Doing exactly the same on i386 SMP results in a hanging gdb and the process exiting with signal 8. blackmetal:~#ps u

Re: kern/78824: race condition close()ing and read()ing the same socketpair on SMP.

Is this going to be fixed before 5.4 ? It still breaks on today's 5.4-STABLE. Marc ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to "[EMAIL PROTECTED]"

Re: Trek Technology Thumbdrive 16MB

On Wed, May 04, 2005 at 02:19:13PM +0200, Gerrit Khn wrote: > Hi folks, > > has anyone used the subject successfully with -stable? > umass(4) mentions the 8MB version, so I thought 16MB should actually work, > too. However, when I plug the device in, I just get > > ugen0: Trek Technology ThumbDri

Re: Trek Technology Thumbdrive 16MB

On Wed, May 04, 2005 at 04:23:51PM +0200, Marc Olzheim wrote: > > Any hints how to make this work? > > You _do_ have scsi disk support (device da) enabled in your kernel ? And loaded the umass module or have it in your kernel, for that matter ? Marc pgpWpcRUFu55s.pgp Desc

Re: kern/78824: race condition close()ing and read()ing the same socketpair on SMP.

On Tue, May 03, 2005 at 05:00:14PM +0200, Marc Olzheim wrote: > Is this going to be fixed before 5.4 ? It still breaks on today's > 5.4-STABLE. As this is the only issue known to me now, that I don't have a patch for and is standing in my way of upgrading from FreeBSD 4.x to 5.x,

Re: OT: Alright you primitive screwheads, LISTEN UP!!

On Tue, May 17, 2005 at 10:37:37AM -0700, Gary Kline wrote: > Anybody on this geek list know any other societies where the > surname is traditionally presented first and the given name > last? Geek list ? Ah! That probably means I'm allowed to say Star Trek's Bajorans suffer fr

Re: OT: Alright you primitive screwheads, LISTEN UP!!

On Tue, May 17, 2005 at 09:22:33PM +0200, Johan van Selst wrote: > Other variations may appear as well, but are not very common. You may > address me as 'Johan', 'Johan van Selst' or even 'Mr. van Selst' - > but _not_ (never ever) as 'Johan van'. Thank you. Although 'Mr. van Selst' only applied if

Re: Performance of 4.x vs 5.x (nbench results)

On Tue, May 24, 2005 at 09:40:20PM +0200, Matthias Buelow wrote: > Bohdan Horst wrote: > > > I have 4 identical PC with FreeBSD (2x4.11R and 2x5.4R) > > Results (/usr/ports/net/benchmarks/nbench): > > What you're benchmarking here is gcc3 vs. gcc2. You could compile nbench on FreeBSD 4.11 with U

Re: kern/78824: race condition close()ing and read()ing the same socketpair on SMP.

On Fri, May 27, 2005 at 12:47:28PM +0100, Robert Watson wrote: > Hmm. I'm unable to reproduce this on local SMP hardware, although I can > see at least one way that the race could occur. Could you try the > attached patch and see if it helps matters? This is a slight shot in the > dark but cl

Re: kern/78824: race condition close()ing and read()ing the same socketpair on SMP.

On Fri, May 27, 2005 at 03:44:41PM +0200, Marc Olzheim wrote: > Could you try the attached patch and see if it helps matters? This is > a slight shot in the dark but closes at least two races in the > transition of socket state with respect to socket buffer state. Yes! This fixes it, o

Re: kern/78824: race condition close()ing and read()ing the same socketpair on SMP.

On Fri, May 27, 2005 at 04:57:57PM +0200, Marc Olzheim wrote: > > Could you try the attached patch and see if it helps matters? This is > > a slight shot in the dark but closes at least two races in the > > transition of socket state with respect to socket buffer state. >

Re: What to use to get remote display from a amd64 machine?

On Tue, Jun 07, 2005 at 12:03:41PM +0200, Francois Tigeot wrote: > On Tue, Jun 07, 2005 at 12:03:01AM +0200, Torfinn Ingolfsen wrote: > > > > What are people using for remote X displays on amd64 machines? > > Stock X is sufficient. That's really not a substitue for nxserver's performance... Assu

Re: FreeBSD 5.4: Is it generally unstable?

On Wed, Jun 08, 2005 at 01:42:45PM -0400, Mike Tancsa wrote: > >I remember 5.2.1 panicking left and right, on several machines, it was > >completely unusable. Maybe we just live in different universes. > > Me too, but a lot has changed since 5.2.1 which at the time was I think was > called a pre

Re: FreeBSD 5.4: Is it generally unstable?

On Wed, Jun 08, 2005 at 10:44:07PM -0500, Vulpes Velox wrote: > > Personnally, when upgrading from 4.x to 5.x, we ran into the > > following 3 issues that are still not fixed in 5.4: > > > > kern/80617: > > Hangup writing large blocks to NFS mounted FS(Patches available) > > Not exremely impor

Re: changes to src/sys/kern/uipc_socket2.c

On Fri, Jun 10, 2005 at 11:32:14AM +0200, Goran Gajic wrote: > Latest change to uipc_socket2.c fixed my problem with start of apache2 in > chroot enviroment. Whenever I reboot 5.4 I was forced to manualy do: > > chroot /CHROOT/APACHE /usr/local/apache2/bin/httpd -D SSL > > no matter I already had

Re: kern/78824: race condition close()ing and read()ing the same socketpair on SMP.

On Mon, May 30, 2005 at 11:21:37AM +0100, Robert Watson wrote: > Great. I'll MFC this in a week or so assuming that there are no reports > of problems with the patch in HEAD. Thanks for the clear and concise bug > report, and sorry about taking so long to get this fixed! Haven't had any proble

Re: NFS-related hang in 5.4?

On Mon, Jun 20, 2005 at 10:53:19AM +0200, Eirik verby wrote: > I know enough not to call this a "confirmation", but disabling > dummynet did indeed allow me to finish the backup. I never made it > past 15GBs before, now the full 19GB tar.gz file is done, and the > boxes are both still running

Re: NFS-related hang in 5.4?

On Mon, Jun 20, 2005 at 06:29:31PM +0200, Eirik verby wrote: > >Hmm, does that solve kern/79208 for you as well by any chance ? > > Seems not. > > Now, how do I get my box back to life? ;) Hmm, Sorry 'bout that... :-/ Marc pgpAHJk8H7OoT.pgp Description: PGP signature

Re: update libpthread

On Tue, Jun 21, 2005 at 09:00:05PM +0700, Khanh Cao Van wrote: > Peter Jeremy tell me that I have to update libpthread to be able to > install JDK 1.4 on freeBSD 4.7 . But I could not find out what ports > contain that lib . Help me if you know . There is no /usr/src/lib/libpthread for FreeBSD-4.x

Lock Order Reversal #66

This time I didn't get a LOR, but: kdb_backtrace(0,1,c07328e8,c0732780,c0700d3c) at 0xc053f7e1 = kdb_backtrace+0x29 witness_checkorder(c6c33900,9,c06ce108,3d3) at 0xc0549180 = witness_checkorder+0x544 _mtx_lock_flags(c6c33900,0,c06ce108,3d3,0) at 0xc052184b = _mtx_lock_flags+0x5b in_pcblookup_loc

Today's RELENG_5_4 and 'lock cmpxchgl'

Somehow, this sounds familiar, i.e.: the "lock cmpxchgl": Fatal trap 12: page fault while in kernel mode cpuid = 0; apic id = 00 fault virtual address = 0x1c fault code = supervisor write, page not present instruction pointer = 0x8:0xc05160c3 stack pointer = 0x10:0xebf

Re: Today's RELENG_5_4 and 'lock cmpxchgl'

On Fri, Jul 01, 2005 at 12:14:58PM +0200, Marc Olzheim wrote: > Somehow, this sounds familiar, i.e.: the "lock cmpxchgl": > > Fatal trap 12: page fault while in kernel mode ... > Stopped at 0xc05160c3 = knote+0x27:lock cmpxchgl > %ecx,0x1c(%edx) Somehow I

Re: Today's RELENG_5_4 and 'lock cmpxchgl'

On Fri, Jul 01, 2005 at 12:41:39PM +0200, Marc Olzheim wrote: > On Fri, Jul 01, 2005 at 12:14:58PM +0200, Marc Olzheim wrote: > > Somehow, this sounds familiar, i.e.: the "lock cmpxchgl": > > > > Fatal trap 12: page fault while in kernel mode > ... > >

Re: Today's RELENG_5_4 and 'lock cmpxchgl'

On Sun, Jul 03, 2005 at 10:38:58AM +0200, Philippe PEGON wrote: > >The panic appears to be an instance of a known bug in 5.4 (and > >INVARIANTS will not fix it, but may just delay the inevitable by > >changing timings). See Doug White's recent emails which point to a > >patch you should test. > >

Re: Today's RELENG_5_4 and 'lock cmpxchgl'

On Mon, Jul 11, 2005 at 04:32:16PM +0200, Marc Olzheim wrote: > On Sun, Jul 03, 2005 at 10:38:58AM +0200, Philippe PEGON wrote: > > >The panic appears to be an instance of a known bug in 5.4 (and > > >INVARIANTS will not fix it, but may just delay the inevitable by > &g

Re: Today's RELENG_5_4 and 'lock cmpxchgl'

On Wed, Jul 13, 2005 at 08:00:31AM -0400, Kris Kennaway wrote: > > Stress testing this gives me instant fatal trap 12 on both 11 juli's > > CURRENT and RELENG_5. > > > > I'll file a PR. > > Make sure you recompile any modules when activating INVARIANTS, or > you'll get panics. Of course... make

Re: Today's RELENG_5_4 and 'lock cmpxchgl'

On Wed, Jul 13, 2005 at 02:41:18PM -0400, Kris Kennaway wrote: > > > Make sure you recompile any modules when activating INVARIANTS, or > > > you'll get panics. > > > > Of course... make buildkernel and make installkernel do that for me... ;) > > Not if you are using third party port modules. W

Re: Today's RELENG_5_4 and 'lock cmpxchgl'

On Thu, Jul 14, 2005 at 01:44:04PM -0400, Kris Kennaway wrote: > > The -CURRENT traces are very different from these, but I don't have > > comconsole on the -CURRENT machine. > > Thanks. Since I get plenty of opportunities to fiddle in the debugger now, because this happens a lot (we use screen a

Re: Today's RELENG_5_4 and 'lock cmpxchgl'

On Fri, Jul 15, 2005 at 11:40:27AM +0200, Marc Olzheim wrote: > On Thu, Jul 14, 2005 at 01:44:04PM -0400, Kris Kennaway wrote: > > > The -CURRENT traces are very different from these, but I don't have > > > comconsole on the -CURRENT machine. > > > > Thanks

Re: FreeBSD 5.4: Is it generally unstable?

On Wed, Jun 08, 2005 at 08:04:28PM +0200, Marc Olzheim wrote: > > >I remember 5.2.1 panicking left and right, on several machines, it was > > >completely unusable. Maybe we just live in different universes. > > > > Me too, but a lot has changed since 5.2.1 whi

Re: FreeBSD 5.4: Is it generally unstable?

On Tue, Jul 19, 2005 at 11:28:03AM +0200, Marc Olzheim wrote: > On Wed, Jun 08, 2005 at 08:04:28PM +0200, Marc Olzheim wrote: > > > >I remember 5.2.1 panicking left and right, on several machines, it was > > > >completely unusable. Maybe we just live in different uni

Re: Today's RELENG_5_4 and 'lock cmpxchgl'

On Fri, Jul 15, 2005 at 08:05:23AM -0400, Kris Kennaway wrote: > > Ok, even non-SMP 7-CURRENT crashes on it, so I do not believe that I'm > > the only one seeing this... > > You're not..as noted, it's been widely reported. Could you give me any pointers to where this has been discussed before ?

Re: Today's RELENG_5_4 and 'lock cmpxchgl'

On Tue, Jul 19, 2005 at 01:53:14PM +0200, Marc Olzheim wrote: > On Fri, Jul 15, 2005 at 08:05:23AM -0400, Kris Kennaway wrote: > > > Ok, even non-SMP 7-CURRENT crashes on it, so I do not believe that I'm > > > the only one seeing this... > > > > You'

Re: FreeBSD 5.4: Is it generally unstable?

On Tue, Jul 19, 2005 at 11:46:18AM +0200, Marc Olzheim wrote: > > Since I can't seem to keep any recent RELENG_5 kernel up and running > > atm. I'd change my viewpoint to run 5.4 and apply all necessary > > stability patches yourself. I'll prepare a patchset... >

Re: Serious issue with serial console in 5.4

On Thu, Jul 21, 2005 at 10:56:54AM +0200, Eirik verby wrote: > >>>Fatal trap 12: page fault while in kernel mode > >>>cpuid = 1; apic id = 00 > >>>fault virtual address = 0x1c > >>>fault code = supervisor write, page not present > >>>instruction pointer = 0x8:0xc0620b5f > >>>stac

background fsck, softupdates & inconsistent state on disk

Hi. Having enough opportunities to do crash recovery with kern/83375 open and some of my services not yet moved back to FreeBSD 4, I noticed that often it crashes just after (or perhaps during) mirroring of a directory tree. The mirroring involves creating a directory with in it 80 subdirectories

Re: Quality of FreeBSD

On Wed, Jul 20, 2005 at 08:43:33PM -0700, Alexey Yakimovich wrote: > My advice to FreeBSD release engineering team: > - do more testing; > - have it tested with hardware what was published in "Hardware Notes"; > - do not release it for production if it is not in production quality; > - reread agai

Re: Quality of FreeBSD

On Thu, Jul 21, 2005 at 08:29:47PM +0930, Daniel O'Connor wrote: > I think the best way to rectify this is to test RC candidates on YOUR > hardware.. This finds the bugs you need fixed at a time when people are very > receptive to fixing them. > > It's not realistic for the release engineer to t

Re: Quality of FreeBSD

Robert, First, thank you for your clear reply. > 90% of useful FreeBSD testing happens when large FreeBSD consumers take > release of FreeBSD and deploy them in their testbeds and real-world > environments, and find the bugs through the application of high levels of > load and obscure hardware

Re: Serious issue with serial console in 5.4

On Thu, Jul 21, 2005 at 02:19:23PM +0200, Eirik verby wrote: > > If you cause syslogd not to send any output to /dev/console, does > >the > > problem go away? > > I'm afraid to say it doesn't Please, could you add: options DDB #Enable the kernel debugger options DDB_N

Re: SuperMicro X5DP8-G2MB/(2)XEON 2.4/1GB RAM 5.4-S Freeze

On Tue, Apr 19, 2005 at 10:38:08AM +0200, Marc Olzheim wrote: > > > The problem is with the periodic SMM interrupt and the bios. > > > > > > The attached program (ich-periodic-smm-disable.c) will fix the problem. > > > For more information on what i

Re: Quality of FreeBSD

On Thu, Jul 21, 2005 at 01:20:49PM +0100, Robert Watson wrote: > >I know FreeBSD 5 was a strange exception in the relase scheduling and > >that a lot has been learned from it for the future and I'm certainly not > >unthankful for all the work that's done, but I'd like a clear answer on > >what t

Re: Machine Replication

On Sat, Jul 23, 2005 at 08:43:00AM +0100, Dick Davies wrote: > http://www.freebsd.org/doc/en_US.ISO8859-1/articles/pxe/article.html Heheh... This needs updating; only 2 of the vnconfig references have been updated to mdconfig. Marc pgpYywe8nwJob.pgp Description: PGP signature

Re: background fsck, softupdates & inconsistent state on disk

On Thu, Jul 21, 2005 at 11:45:33AM +0200, Marc Olzheim wrote: > Having enough opportunities to do crash recovery with kern/83375 open > and some of my services not yet moved back to FreeBSD 4, I noticed that > often it crashes just after (or perhaps during) mirroring of a directory &g

Re: background fsck, softupdates & inconsistent state on disk

On Mon, Aug 01, 2005 at 10:48:04PM +0800, Xin LI wrote: > Hi, Marc, > > On Mon, Aug 01, 2005 at 10:58:08AM +0200, Marc Olzheim wrote: > > Ok, this time it's worse; Trying to startup single user, gives: > > > > WARNING: / was not properly dismounted > > sta

Re: background fsck, softupdates & inconsistent state on disk

On Mon, Aug 01, 2005 at 11:44:07PM +0800, Xin LI wrote: > > After fsck telling me it's all ok, when I reboot (even after being up a > > couple of minutes), I still get the same messages now. > > Hmm... Could you please confirm that the final vnode sync has been > completed? Hmm, I'm not sure...

Re: HEADS UP! 6.0-RELEASE coming

On Thu, Oct 27, 2005 at 12:05:07PM -0600, Scott Long wrote: > Everyone is still welcome to update their sources on the RELENG_6_0 > branch and provide feedback for the next 48 hours or so. The release > will likely be announced by the end of the weekend or early next > week, at the latest. An

Re: HEADS UP! 6.0-RELEASE coming

On Mon, Oct 31, 2005 at 08:36:42AM -0700, Scott Long wrote: > >Anyone having updates for my showstopper page, please, notify me... > > > >http://www.stack.nl/%7Emarcolz/FreeBSD/showstoppers.html > > The pty problem is likely a side effect of known locking problems with > ttys and ptys in general.

Re: HEADS UP! 6.0-RELEASE coming

On Mon, Oct 31, 2005 at 05:01:50PM +0100, Marc Olzheim wrote: > > Is the 'VM/VFS overruns' item still a problem? That was likely fixed a > > couple of months ago. If not then it's definitely something that I'll > > track for the 6.1 release. > > I&#x

Re: HEADS UP! 6.0-RELEASE coming

On Tue, Nov 01, 2005 at 06:40:42AM +0600, Max Khon wrote: > Linking against -lthr (or even -lc_r!) instead of -lpthread solves gdb > "The program no longer exists." problem for me on RELENG_6. Well, yes, but that's not the same. While running on M:N KSE, all sorts of locking needs to be correct, w

Re: HEADS UP! 6.0-RELEASE coming

On Tue, Nov 01, 2005 at 06:33:21PM +0600, Max Khon wrote: > Hi! > > On Tue, Nov 01, 2005 at 12:29:00PM +0100, Marc Olzheim wrote: > > > > Linking against -lthr (or even -lc_r!) instead of -lpthread solves gdb > > > "The program no longer exists." proble

libc resolver code overflow ?

Hi, Does anybody know what this is all about ? http://www.pine.nl/advisories/pine-cert-20020601.html Zlo To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-stable" in the body of the message

Re: testsockbuf.c

> > I'm running 2.2.6 and this program WREAKED havoc on it :) It seems to work on NetBSD 1.3.2 too Perhaps a BSD-ism ? Marc To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-stable" in the body of the message

Re: testsockbuf.c

> Isn't this a huge problem for ordinary users on a system?? I mean > there aren't any user restrictions on sockets right? I imagine > there will be some sort of follow up on this exploit? Well, there is a 256k limit per socket of the buffer (I & O), try sysctl kern.maxsockbuf and you can limit