Re: Performance!
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
Kip Macy wrote:
> Are you sure that the settitle call is disabled on FreeBSD?
>
I don't know anything about this. Could you explain?
>
> On 12/20/07, Krassimir Slavchev <[EMAIL PROTECTED]> wrote:
> Hello,
>
> I have read all related threads about performance problems with multi
> core systems but still have no idea what to do to make thinks better.
> Below are results of testing postgresql on HP DL380G5 using sysbench.
> The results are comparable to:
> http://blog.insidesystems.net/articles/2007/04/11/postgresql-scaling-on-6-2-and-7-0
> but the same tests running on the same hardware using Linux (kernel
> 2.6.18-53.1.4.el5 SMP x86_64) are very different.
> PostgreSQL is tuned equal.
>
> dmesg:
> ...
> CPU: Intel(R) Xeon(R) CPU X5450 @ 3.00GHz (3000.02-MHz
> K8-class CPU)
> Origin = "GenuineIntel" Id = 0x10676 Stepping = 6
>
> Features=0xbfebfbff
>
> Features2=0xce3bd>
> AMD Features=0x2800
> AMD Features2=0x1
> Cores per package: 4
> usable memory = 8575655936 (8178 MB)
> avail memory = 8288337920 (7904 MB)
> ACPI APIC Table:
> FreeBSD/SMP: Multiprocessor System Detected: 8 CPUs
> ...
>
> test:
> sysbench --num-threads=${i} --test=oltp --pgsql-user=bench
> --pgsql-db=bench --db-driver=pgsql --max-time=60 --max-requests=0
> --oltp-read-only=on run
>
> tuning:
> kern.ipc.shmmax=2147483647
> kern.ipc.shmall=524288
> kern.ipc.semmsl=512
> kern.ipc.semmap=256
> kern.ipc.somaxconn=2048
> kern.maxfiles=65536
> vfs.read_max=32
>
> kern.ipc.semmni=256
> kern.ipc.semmns=2048
>
> results:
> FreeBSD 7.0-BETA4 amd64 (cvsup on 20.12) GENERIC with SCHED_ULE
> #threads#transactions/sec user/system
> 1 500 7.4%,5.3%
> 5 199030.9%,23.4%
> 10 251039.9%,35.0%
> 20 254944.5%,43.5%
> 40 192129.8%,59.4%
> 60 158022.7%,70.6%
> 80 134118.9%,75.9%
> 100 122716.5%,79.3%
>
> Linux
> #threads#transactions/sec
> 1 693
> 5 3539
> 10 5789
> 20 5791
> 40 5661
> 60 5517
> 80 5401
> 100 5319
>
>
> What can be done to improve these results?
>
> Best Regards
>
___
freebsd-stable@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-stable
To unsubscribe, send any mail to "[EMAIL PROTECTED]"
>>
-BEGIN PGP SIGNATURE-
Version: GnuPG v1.4.7 (FreeBSD)
iD8DBQFHb29axJBWvpalMpkRAszAAJ9bBbHr5lskjC9fD3zHrZNvoRQL6QCeP0Sh
B1YvfmvSuyXkIG15HUZ1Hfw=
=ZdzN
-END PGP SIGNATURE-
___
freebsd-stable@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-stable
To unsubscribe, send any mail to "[EMAIL PROTECTED]"
ifconfig options?
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Hi, 'ifconfig -l [address_family]' does not work correct on RELENG_7 FreeBSD 6.3-BETA2: # ifconfig -l em0 em1 plip0 lo0 pflog0 #ifconfig -l ether em0 em1 But: FreeBSD 7.0-BETA4: # ifconfig -l em0 em1 plip0 lo0 pflog0 #ifconfig -l ether em0 em1 plip0 lo0 pflog0 I need this functionality to get all ethernet interfaces. Is there other way to do this? Best Regards -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.7 (FreeBSD) iD8DBQFHb3WBxJBWvpalMpkRAmZSAKCP1zuGQ/jzFDuPJEM/pCNEkP/gIACfeImb VODEPRfu0Pl38yML0WA8Tow= =Rkav -END PGP SIGNATURE- ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to "[EMAIL PROTECTED]"
Re: ifconfig options?
On Mon, Dec 24, 2007 at 11:01:53AM +0200, Krassimir Slavchev wrote: > I need this functionality to get all ethernet interfaces. Is there other > way to do this? netstat -i -f link Maybe? -- Regards, Richard. /* Homo Sapiens non urinat in ventum */ ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to "[EMAIL PROTECTED]"
Re: ifconfig options?
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Richard Arends wrote: > On Mon, Dec 24, 2007 at 11:01:53AM +0200, Krassimir Slavchev wrote: > >> I need this functionality to get all ethernet interfaces. Is there other >> way to do this? > > netstat -i -f link > > Maybe? > No, this lists all interfaces: NameMtu Network Address Ipkts IerrsOpkts Oerrs Coll fxp0 1500 00:90:27:7c:b8:68 8088136 0 6987967 0 0 plip0 15000 00 0 0 lo0 16384 138029 0 138029 0 0 pfsyn 20200 00 0 0 pflog 332080 00 0 0 -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.7 (FreeBSD) iD8DBQFHb3rWxJBWvpalMpkRAtlNAJ4yXhYcLlF7MyHg0XzKTtjWSqpBcgCfRMUp fOwhWgxe+Uv+y25Rfb1DWD0= =zopa -END PGP SIGNATURE- ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to "[EMAIL PROTECTED]"
Re: is there any hope for MFC nscd?
Hi, Michael! In attachment patch for backporing nscd from RELENG_7 to RELENG_6. Tested on FreeBSD sepulca.yandex.ru 6.3-PRERELEASE FreeBSD 6.3-PRERELEASE #0: Thu Dec 23 22:06:36 MSK 2007 [EMAIL PROTECTED]:/usr/obj/usr/RELENG_6_ncsd/src/sys/GENERIC amd64 and works fine. Must I prepare pr? P.S. Don't forget to mkdir -p src/usr.sbin/nscd/agents before patching ;) Sun, Dec 23, 2007 at 19:34 +0300 Michael Bushkov: > Hi Denis, > It's actually possible - at first glance it's just the matter of copying a > number of quite self-contained chunks > of 7th version libc code to the RELENG_6_2 libc + copying the nscd itself. > I'll contact some other committers to > make sure that there are no other reasons that can prevent such MFC. If > everything is ok with it - I can do it. > The best way you can help with it is to prepare a patch that I can review and > commit :) Is it possible? > > With best regards, > Michael Bushkov > > On Dec 19, 2007, at 4:00 PM, Denis Barov wrote: > > >Hi, Michael! > > > >Is there any hope for MFC nscd into 6.2? > >Can I help you in this task? > > > > > >Cheers > >-- > >Denis Barov > >Yandex http://www.yandex.ru > >WEB-Search Administration Team > >phone: : +7 (495) 739-70-00 add. 7154 > >e-mail: [EMAIL PROTECTED] > Cheers -- Denis Barov Yandex http://www.yandex.ru WEB-Search Administration Team phone: : +7 (495) 739-70-00 add. 7154 e-mail: [EMAIL PROTECTED] pgpKUH1eYoXdZ.pgp Description: PGP signature
Re: ifconfig options?
-BEGIN PGP SIGNED MESSAGE- Hash: SHA256 Hi Krassimir, Krassimir Slavchev wrote: > Hi, > > 'ifconfig -l [address_family]' does not work correct on RELENG_7 If you suspect a regression in functionality, and you can reproduce it the best thing one can do is submit a problem report with send-pr http://www.freebsd.org/send-pr.html Having them reported on the list may seem nice but stands less chance the item is picked up. Regards, Ruben -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.6 (Darwin) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org iD8DBQFHb3/5Z88+mcQxRw0RCNdPAJ4rqsiLuVwr9QP2PAS3ALdqjNGy1QCfRu9q 65+69EzO6S2j4qyjApq7TBI= =ygDu -END PGP SIGNATURE- ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to "[EMAIL PROTECTED]"
Re: is there any hope for MFC nscd?
I'm sorry, seems attachment was stripped by mailserver or somewhat else. Gzipped patch avialable at http://www.dindin.ru/wiki/FreeBSD?action=AttachFile&do=get&target=nscd_backport.gz (78Kb) Mon, Dec 24, 2007 at 12:15 +0300 Denis Barov: > Hi, Michael! > In attachment patch for backporing nscd from RELENG_7 to RELENG_6. Tested on > > FreeBSD sepulca.yandex.ru 6.3-PRERELEASE FreeBSD 6.3-PRERELEASE #0: Thu Dec > 23 22:06:36 MSK 2007 > [EMAIL PROTECTED]:/usr/obj/usr/RELENG_6_ncsd/src/sys/GENERIC amd64 > > and works fine. > > Must I prepare pr? > > P.S. Don't forget to mkdir -p src/usr.sbin/nscd/agents before patching ;) > > > Sun, Dec 23, 2007 at 19:34 +0300 Michael Bushkov: > > Hi Denis, > > It's actually possible - at first glance it's just the matter of copying a > > number of quite self-contained chunks > > of 7th version libc code to the RELENG_6_2 libc + copying the nscd itself. > > I'll contact some other committers to > > make sure that there are no other reasons that can prevent such MFC. If > > everything is ok with it - I can do it. > > The best way you can help with it is to prepare a patch that I can review > > and commit :) Is it possible? > > > > With best regards, > > Michael Bushkov > > > > On Dec 19, 2007, at 4:00 PM, Denis Barov wrote: > > > > >Hi, Michael! > > > > > >Is there any hope for MFC nscd into 6.2? > > >Can I help you in this task? > > > > > > > > >Cheers > > >-- > > >Denis Barov > > >Yandex http://www.yandex.ru > > >WEB-Search Administration Team > > >phone: : +7 (495) 739-70-00 add. 7154 > > >e-mail: [EMAIL PROTECTED] > > > > Cheers > -- > Denis Barov > Yandex http://www.yandex.ru > WEB-Search Administration Team > phone: : +7 (495) 739-70-00 add. 7154 > e-mail: [EMAIL PROTECTED] Cheers -- Denis Barov Yandex http://www.yandex.ru WEB-Search Administration Team phone: : +7 (495) 739-70-00 add. 7154 e-mail: [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: Packet loss every 30.999 seconds
On Sun, Dec 23, 2007 at 10:20:31AM +1100, Bruce Evans wrote:
> On Sat, 22 Dec 2007, Kostik Belousov wrote:
> >Ok, since you talked about this first :). I already made the following
> >patch, but did not published it since I still did not inspected all
> >callers of MNT_VNODE_FOREACH() for safety of dropping mount interlock.
> >It shall be safe, but better to check. Also, I postponed the check
> >until it was reported that yielding does solve the original problem.
>
> Good. I'd still like to unobfuscate the function call.
What do you mean there ?
> Putting the count in the union seems fragile at best. Even if nothing
> can access the marker vnode, you need to context-switch its old contents
> while using it for the count, in case its old contents is used. Vnode-
> printing routines might still be confused.
Could you, please, describe what you mean by "contex-switch" for the
VMARKER ?
Mark, could you, please, retest the patch below in your setup ?
I want to put a change or some edition of it into the 7.0 release, and
we need to move fast to do this.
diff --git a/sys/kern/vfs_mount.c b/sys/kern/vfs_mount.c
index 14acc5b..046af82 100644
--- a/sys/kern/vfs_mount.c
+++ b/sys/kern/vfs_mount.c
@@ -1994,6 +1994,12 @@ __mnt_vnode_next(struct vnode **mvp, struct mount *mp)
mtx_assert(MNT_MTX(mp), MA_OWNED);
KASSERT((*mvp)->v_mount == mp, ("marker vnode mount list mismatch"));
+ if ((*mvp)->v_yield++ == 500) {
+ MNT_IUNLOCK(mp);
+ (*mvp)->v_yield = 0;
+ uio_yield();
+ MNT_ILOCK(mp);
+ }
vp = TAILQ_NEXT(*mvp, v_nmntvnodes);
while (vp != NULL && vp->v_type == VMARKER)
vp = TAILQ_NEXT(vp, v_nmntvnodes);
diff --git a/sys/sys/vnode.h b/sys/sys/vnode.h
index dc70417..6e3119b 100644
--- a/sys/sys/vnode.h
+++ b/sys/sys/vnode.h
@@ -131,6 +131,7 @@ struct vnode {
struct socket *vu_socket; /* v unix domain net (VSOCK) */
struct cdev *vu_cdev; /* v device (VCHR, VBLK) */
struct fifoinfo *vu_fifoinfo; /* v fifo (VFIFO) */
+ int vu_yield; /* yield count (VMARKER) */
} v_un;
/*
@@ -185,6 +186,7 @@ struct vnode {
#definev_socketv_un.vu_socket
#definev_rdev v_un.vu_cdev
#definev_fifoinfo v_un.vu_fifoinfo
+#definev_yield v_un.vu_yield
/* XXX: These are temporary to avoid a source sweep at this time */
#define v_object v_bufobj.bo_object
pgpRF2zEg9a7Q.pgp
Description: PGP signature
Re: SMP on FreeBSD 6.x and 7.0: Worth doing?
Brett Glass wrote: I will need to build several Web caches over the next few months, and just took advantage of the Christmas lull (and a snowy day, when I couldn't work outside) to test FreeBSD 7.0 BETA 4 to see how it will perform at this task. I built up a 4 core FreeBSD box, and asked a friend who's a Linux fanatic to do the same with Linux on identical hardware. I didn't watch closely how he installed everything, but asked him not to tune it beyond setting it up properly for SMP. We then ran a test suite in which a client starts several processes. Each uses wget to fetch a series of objects in rapid succession via the cache. The fetches done by each process are the same batch of URLS, but shuffled differently, so each URL will get a miss the first time and then hits each time it comes up thereafter unless the cache overflows. We're doing all GETs, with no tricky stuff like subranges. As has been reported in some other messages on this list, Linux is currently blowing FreeBSD away. It's taking as much as 20% less time to get through the benchmark, depending on exactly how the random shuffle came out. This is with 4 GB RAM, the GENERIC FreeBSD SMP kernel (using SCHED_ULE), and aufs as the storage schema for Squid. It appears, though I'd need to instrument the code more to be sure, that the slowdown is coming from file I/O. Could it be that there less concurrency or more overhead in FreeBSD file operations than there is in Linux? Even with SoftUpdates turned on, the cache volume mounted with -noatime, and aufs (which uses kqueues -- a FreeBSD invention -- to optimize multithreaded disk access), the benchmark shows FreeBSD losing out. Why? Brett, There could be several problems here: 1. WITNESS, INVARIANTS, malloc debugging. Are any of these turned on for you? I don't recall if malloc debugging got turned off yet for the 7.0 snapshots. 2. Disk subsystem. What kind of disk controller are you using? Not all drivers work well in FreeBSD. Are linux and freebsd using identical hardware? 3. Directory hashing. If you're using squid, you __must__ tune the DIRHASH, otherwise you'll spend a lot of time doing pathname lookups. What filesystem is linux using? Would you mind if I logged into your test system and looked around to help diagnose the problem? Scott ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to "[EMAIL PROTECTED]"
Re: SMP on FreeBSD 6.x and 7.0: Worth doing?
At 07:14 AM 12/24/2007, Scott Long wrote: >Brett, > >There could be several problems here: > >1. WITNESS, INVARIANTS, malloc debugging. Are any of these turned on for you? > I don't recall if malloc debugging got turned off yet for the >7.0 snapshots. I nuked debugging when I recompiled the kernel with SCHED_ULE. >2. Disk subsystem. What kind of disk controller are you using? Not all >drivers work well in FreeBSD. Are linux and freebsd using identical >hardware? They were. The drives are SATA. >3. Directory hashing. If you're using squid, you __must__ tune the DIRHASH, >otherwise you'll spend a lot of time doing pathname lookups. What filesystem >is linux using? Whatever comes standard with Ubuntu. As for directory hashing: Squid doesn't use more than 256 entries in each one, so that's what I normally set. I also normally do a newfs with parameters that favor the distribution of object sizes found in Web caches. (We did this on both Linux and FreeBSD.) >Would you mind if I logged into your test system and looked around to >help diagnose the problem? The system isn't online now, because it's been a week since the tests and I also wanted to try the 6.3 beta and a few hardware changes. My guess, based on what I saw, is that UFS2 doesn't take as much advantage of SMP as Linux's file system does and threads are blocking on file I/O. (Networking does not seem to be the botteneck, though I have heard that the IP stack in 7-CURRENT needs optimization and that this had been proposed as a sponsored project.) --Brett P.S. -- If the chip manufacturers were not making it so that one needs to go to SMP to get more processing power, I wouldn't be doing SMP. I'd rather use FreeBSD 4.11 on a single core "gaming" CPU, as I did a few years ago when I needed a very fast server. But this isn't a viable option nowadays ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to "[EMAIL PROTECTED]"
Re: SMP on FreeBSD 6.x and 7.0: Worth doing?
Brett Glass wrote: At 07:14 AM 12/24/2007, Scott Long wrote: Brett, There could be several problems here: 1. WITNESS, INVARIANTS, malloc debugging. Are any of these turned on for you? I don't recall if malloc debugging got turned off yet for the 7.0 snapshots. I nuked debugging when I recompiled the kernel with SCHED_ULE. Did you also nuke malloc debugging? 2. Disk subsystem. What kind of disk controller are you using? Not all drivers work well in FreeBSD. Are linux and freebsd using identical hardware? They were. The drives are SATA. Connected to what controller? 3. Directory hashing. If you're using squid, you __must__ tune the DIRHASH, otherwise you'll spend a lot of time doing pathname lookups. What filesystem is linux using? Whatever comes standard with Ubuntu. Which is??? As for directory hashing: Squid doesn't use more than 256 entries in each one, so that's what I normally set. I also normally do a newfs with parameters that favor the distribution of object sizes found in Web caches. (We did this on both Linux and FreeBSD.) newfs tuning has little to do with this. Would you mind if I logged into your test system and looked around to help diagnose the problem? The system isn't online now, because it's been a week since the tests and I also wanted to try the 6.3 beta and a few hardware changes. My guess, based on what I saw, is that UFS2 doesn't take as much advantage of SMP as Linux's file system does and threads are blocking on file I/O. That's really just speculation on your part, though. UFS is SMP capable, but there really are a whole lot of factors that some into play here so it's really hard to speculate with any chance of success. I can tell you from my experience that a thrashed namei cache looks a lot like slow disk I/O to the casual observer, and that tuning the dirhash is highly important. Thus why I'd like to help out here and see for myself what is going on. Scott ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to "[EMAIL PROTECTED]"
Re: SMP on FreeBSD 6.x and 7.0: Worth doing?
At 09:10 AM 12/24/2007, Scott Long wrote: >Did you also nuke malloc debugging? I believe I did. I tried to take out all debugging to make it a fair test. >>They were. The drives are SATA. > >Connected to what controller? Whatever comes standard on the Intel S5000 motherboards. I believe that it is Intel's own embedded SATA controller, which according to the spec sheet is called their "ESB2-E" embedded SATA RAID controller. We are not using the RAID capability. >>>3. Directory hashing. If you're using squid, you __must__ tune the DIRHASH, >>>otherwise you'll spend a lot of time doing pathname lookups. What filesystem >>>is linux using? >>Whatever comes standard with Ubuntu. > >Which is??? EXT3. >>My guess, based on what I saw, is that UFS2 doesn't take as much advantage of >>SMP as Linux's file system does and threads are blocking on file I/O. > >That's really just speculation on your part, though. Yes, it is -- though I'd like to think it is an educated guess. ;-) I'd need to instrument either the benchmark code or the kernel to tell for sure. But the test is, by its nature, bound by file I/O. >I can tell you from my experience that a thrashed namei cache looks a >lot like slow disk I/O to the casual observer, and that tuning the dirhash is >highly important. That's always been true. However, Squid's file layout tends to be gentle on the file system. It lays out directories with no more than 256 items in each, and the names of the files are just sequential hexadecimal numbers -- which I'd expect ought to bring about near-perfect if not perfect hashing. If you set the kernel to expect 256 or more entries per directory (I know that Adrian Chadd is on this list; do you recommend 256 or 512?), you seem to get the best performance you are going to get. We have thought about using COSS for small Web objects, but are not sure how it would interact with AUFS or how much it would impact stability by decreasing the size of Squid's "CACHE_MEM" memory pool (which is used for "hot" objects and objects in transit). Squid tends to crash horribly if this pool isn't kept quite big. --Brett Glass ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to "[EMAIL PROTECTED]"
g_io_request: usb related crash
FreeBSD 6.2-RELEASE-p6 amd64
The following happened:
1. I inserted into a USB card-reader a write-protected miniSD card.
2. Tried to mount it (read-write) and that failed, the following
messages appeared in the system log:
(da0:umass-sim0:0:0:0): WRITE(10). CDB: 2a 0 0 0 1 19 0 0 8 0
(da0:umass-sim0:0:0:0): CAM Status: SCSI Status Error
(da0:umass-sim0:0:0:0): SCSI Status: Check Condition
(da0:umass-sim0:0:0:0): DATA PROTECT csi:0,aa,55,61 asc:27,0
(da0:umass-sim0:0:0:0): Write protected field replaceable unit: 1
(da0:umass-sim0:0:0:0): Unretryable error
g_vfs_done():da0s1[WRITE(offset=16384, length=4096)]error = 13
(da0:umass-sim0:0:0:0): WRITE(10). CDB: 2a 0 0 0 1 19 0 0 8 0
(da0:umass-sim0:0:0:0): CAM Status: SCSI Status Error
(da0:umass-sim0:0:0:0): SCSI Status: Check Condition
(da0:umass-sim0:0:0:0): DATA PROTECT csi:0,aa,55,61 asc:27,0
(da0:umass-sim0:0:0:0): Write protected field replaceable unit: 1
(da0:umass-sim0:0:0:0): Unretryable error
g_vfs_done():da0s1[WRITE(offset=16384, length=4096)]error = 13
fsync: giving up on dirty
0xff0020f7f7c0: tag devfs, type VCHR
usecount 1, writecount 0, refcount 487 mountedhere 0xff00265a5400
flags ()
v_object 0xff00254ef0e0 ref 0 pages 485
dev da0s1
3. Removed the card from the reader and got instant crash.
Crash info:
Fatal trap 12: page fault while in kernel mode
cpuid = 1; apic id = 01
fault virtual address = 0x0
fault code = supervisor read, page not present
instruction pointer = 0x8:0x801e554c
stack pointer = 0x10:0xb17c3a30
frame pointer = 0x10:0xb17c3a70
code segment= base 0x0, limit 0xf, type 0x1b
= DPL 0, pres 1, long 1, def32 0, gran 1
processor eflags= interrupt enabled, resume, IOPL = 0
current process = 41 (syncer)
trap number = 12
panic: page fault
cpuid = 1
KDB: stack backtrace:
kdb_backtrace() at 0x8024f9e7 = kdb_backtrace+0x37
panic() at 0x80230861 = panic+0x1d1
trap_fatal() at 0x803b7588 = trap_fatal+0x3a8
trap_pfault() at 0x803b71ac = trap_pfault+0x24c
trap() at 0x803b6dd3 = trap+0x2f3
calltrap() at 0x803a158b = calltrap+0x5
--- trap 0xc, rip = 0x801e554c, rsp = 0xb17c3a30, rbp =
0xb17c3a70 ---
g_io_request() at 0x801e554c = g_io_request+0x2c
g_vfs_strategy() at 0x801e8628 = g_vfs_strategy+0x58
bufwrite() at 0x8028a68c = bufwrite+0x12c
bawrite() at 0x8028adb5 = bawrite+0x15
vop_stdfsync() at 0x802948e0 = vop_stdfsync+0x1d0
devfs_fsync() at 0x801ce25b = devfs_fsync+0x2b
VOP_FSYNC_APV() at 0x803f7a7c = VOP_FSYNC_APV+0x4c
sync_vnode() at 0x8029fb02 = sync_vnode+0x192
sched_sync() at 0x8029fe9c = sched_sync+0x2bc
fork_exit() at 0x80211b0a = fork_exit+0xaa
fork_trampoline() at 0x803a18ee = fork_trampoline+0xe
(kgdb) bt
#0 doadump () at pcpu.h:172
#1 0x80230459 in boot (howto=260) at
/usr/src/sys/kern/kern_shutdown.c:409
#2 0x80230924 in panic (fmt=0xff00799d3720 "\b\032\ry") at
/usr/src/sys/kern/kern_shutdown.c:565
#3 0x803b7588 in trap_fatal (frame=0xb17c3980, eva=0)
at /usr/src/sys/amd64/amd64/trap.c:660
#4 0x803b71ac in trap_pfault (frame=0xb17c3980,
usermode=0) at /usr/src/sys/amd64/amd64/trap.c:573
#5 0x803b6dd3 in trap (frame=
{tf_rdi = -1097678795608, tf_rsi = -1098524564864, tf_rdx =
-1098524564816, tf_rcx = 0, tf_r8 = -1317259312, tf_r9 = -1613966144,
tf_rax = 2, tf_rbx = -1097678795608, tf_rbp = -1317258640, tf_r10 = 0,
tf_r11 = 140737488348584, tf_r12 = -1098524564864, tf_r13 = 0, tf_r14 =
-1098958506048, tf_r15 = 2097170, tf_trapno = 12, tf_addr = 0, tf_flags
= -1098885697312, tf_err = 0, tf_rip = -2145495732, tf_cs = 8, tf_rflags
= 66178, tf_rsp = -1317258688, tf_ss = 16})
at /usr/src/sys/amd64/amd64/trap.c:352
#6 0x803a158b in calltrap () at
/usr/src/sys/amd64/amd64/exception.S:168
#7 0x801e554c in g_io_request (bp=0xff006d3ecca8,
cp=0xff003ad56280) at /usr/src/sys/geom/geom_io.c:299
#8 0x801e8628 in g_vfs_strategy (bo=0xff006d3ecca8,
bp=0x9fcd9d80) at /usr/src/sys/geom/geom_vfs.c:106
#9 0x8028a68c in bufwrite (bp=0x9fcd9d80) at buf.h:426
#10 0x8028adb5 in bawrite (bp=0xff006d3ecca8) at buf.h:410
#11 0x802948e0 in vop_stdfsync (ap=0xb17c3b80) at
/usr/src/sys/kern/vfs_default.c:431
#12 0x801ce25b in devfs_fsync (ap=0xb17c3b80) at
/usr/src/sys/fs/devfs/devfs_vnops.c:379
#13 0x803f7a7c in VOP_FSYNC_APV (vop=0x2, a=0xff003ad56280)
at vnode_if.c:1020
#14 0x8029fb02 in sync_vnode (bo=0xff0020f7f910,
td=0xff00799d3720) at vnode_if.h:537
#15 0x8029fe9c in sched_sync () at /usr/src/sys/kern/vfs_subr.c:1698
#16 0x80211b0a in fork_exit (callout=0x8029fbe0
, arg=0x0, frame=0xb17c3c50) at
/usr/src/sys/ker
Re: reduce verboseness for certain scsi error
Attached is a proposed patch.
I am not particularly fond of the names. I am also not sure if the same
effect could be achieved by some better means.
The patch works for me and greatly reduces messages pollution when using
a multi-slot card-reader and hald.
P.S. the patch is against sources of 6.2 release.
--
Andriy Gapon
--- sys/cam/scsi/scsi_all.h.orig Fri Dec 21 17:52:50 2007
+++ sys/cam/scsi/scsi_all.h Fri Dec 21 17:57:29 2007
@@ -90,6 +90,7 @@ typedef enum {
* and text.
*/
SSQ_PRINT_SENSE = 0x0800,
+ SSQ_PRINT_SENSE_VERBOSE = 0x1000,
SSQ_MASK = 0xff00
} scsi_sense_action_qualifier;
@@ -104,6 +105,12 @@ typedef enum {
/* Fatal error action, with table specified error code */
#define SS_FATAL SS_FAIL|SSQ_PRINT_SENSE
+
+/* Fatal error action, with table specified error code */
+/* This type of error doesn't imply malfunction of hardware and
+ * and indicates conditions that can occur in "normal" circumstances
+ */
+#define SS_FATAL_NORMAL SS_FAIL|SSQ_PRINT_SENSE_VERBOSE
struct scsi_generic
{
--- sys/cam/scsi/scsi_all.c.orig Fri Dec 21 17:54:50 2007
+++ sys/cam/scsi/scsi_all.c Fri Dec 21 17:55:52 2007
@@ -1197,7 +1197,7 @@ static struct asc_table_entry asc_table[
"Rounded parameter") },
/* DTL WRSOMCAE */{SST(0x39, 0x00, SS_RDEF,
"Saving parameters not supported") },
-/* DTL WRSOM*/{SST(0x3A, 0x00, SS_FATAL|ENXIO,
+/* DTL WRSOM*/{SST(0x3A, 0x00, SS_FATAL_NORMAL|ENXIO,
"Medium not present") },
/* DT WR OM*/{SST(0x3A, 0x01, SS_FATAL|ENXIO,
"Medium not present - tray closed") },
@@ -1395,7 +1395,7 @@ static struct asc_table_entry asc_table[
"End of user area encountered on this track") },
/* R */{SST(0x63, 0x01, SS_FATAL|ENOSPC,
"Packet does not fit in available space") },
-/* R */{SST(0x64, 0x00, SS_FATAL|ENXIO,
+/* R */{SST(0x64, 0x00, SS_FATAL_NORMAL|ENXIO,
"Illegal mode for this track") },
/* R */{SST(0x64, 0x01, SS_RDEF,
"Invalid packet size") },
--- sys/cam/cam_periph.c.orig Fri Dec 21 17:57:53 2007
+++ sys/cam/cam_periph.c Fri Dec 21 18:00:13 2007
@@ -1515,7 +1515,8 @@ camperiphscsisenseerror(union ccb *ccb,
}
sense_error_done:
- if ((err_action & SSQ_PRINT_SENSE) != 0
+ if (((err_action & SSQ_PRINT_SENSE) != 0
+ || ((err_action & SSQ_PRINT_SENSE_VERBOSE) != 0 && bootverbose))
&& (ccb->ccb_h.status & CAM_AUTOSNS_VALID) != 0) {
cam_error_print(print_ccb, CAM_ESF_ALL, CAM_EPF_ALL);
xpt_print_path(ccb->ccb_h.path);
___
freebsd-stable@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-stable
To unsubscribe, send any mail to "[EMAIL PROTECTED]"
Re: SMP on FreeBSD 6.x and 7.0: Worth doing?
Brett Glass wrote: At 09:10 AM 12/24/2007, Scott Long wrote: Did you also nuke malloc debugging? I believe I did. I tried to take out all debugging to make it a fair test. They were. The drives are SATA. Connected to what controller? Whatever comes standard on the Intel S5000 motherboards. I believe that it is Intel's own embedded SATA controller, which according to the spec sheet is called their "ESB2-E" embedded SATA RAID controller. We are not using the RAID capability. 3. Directory hashing. If you're using squid, you __must__ tune the DIRHASH, otherwise you'll spend a lot of time doing pathname lookups. What filesystem is linux using? Whatever comes standard with Ubuntu. Which is??? EXT3. My guess, based on what I saw, is that UFS2 doesn't take as much advantage of SMP as Linux's file system does and threads are blocking on file I/O. That's really just speculation on your part, though. Yes, it is -- though I'd like to think it is an educated guess. ;-) I'd need to instrument either the benchmark code or the kernel to tell for sure. But the test is, by its nature, bound by file I/O. I can tell you from my experience that a thrashed namei cache looks a lot like slow disk I/O to the casual observer, and that tuning the dirhash is highly important. That's always been true. However, Squid's file layout tends to be gentle on the file system. It lays out directories with no more than 256 items in each, and the names of the files are just sequential hexadecimal numbers -- which I'd expect ought to bring about near-perfect if not perfect hashing. It's not the same kind of hashing. The kind of "hashing" that squid does on the filesystem is sub optimal for UFS performance. If you set the kernel to expect 256 or more entries per directory (I know that Adrian Chadd is on this list; do you recommend 256 or 512?), you seem to get the best performance you are going to get. It sounds like you're pretty convinced you know what the problem is. For others who might want help with this, tweaking vfs.ufs.dirhash_maxmem is what is needed. A bit of a balancing act is needed if you're on i386 since you'll risk exhausting KVA unless you also tweak KVA_PAGES. Scott ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to "[EMAIL PROTECTED]"
Instant Reboot with 7.0 BETA4 LifeFS Disk
In testing my Windows desktop with the 7.0 LiveFS disk ( 7.0-BETA4-amd64-livefs.iso), I get an instant reboot when the CD is run. As far as I can tell, no console messages are printed, so it seems the error happens very early in the loading process. Other FreeBSD versions (6.2, i386 7.0) also exhibit the same behavior. If left alone, the computer will just continually reboot. The specs of the system are: Soltek SL-k8TPro-939 (Via K8T800 Pro ATX) motherboard AMD Athlon64 3800+ Newcastle 2.4GHz Promise FastTrak 579 RAID Controller (PDC20579) 2x Seagate Barracuda 7200 SATA 150 disks in RAID 1 Re-badged Radeon 9600 Pro 256MB 128-bit DDR AGP video card My guess is that the disk controller is not supported. Should this cause an instant reboot with a live filesystem disk? Is there anyway to debug this since no console messages are printed? Thanks for the help, Seth Hieronymus ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to "[EMAIL PROTECTED]"
Re: SMP on FreeBSD 6.x and 7.0: Worth doing?
At 12:12 PM 12/24/2007, Scott Long wrote: For others who might want help with this, tweaking vfs.ufs.dirhash_maxmem is what is needed. A bit of a balancing act is needed if you're on i386 since you'll risk exhausting KVA unless you also tweak KVA_PAGES. Hi Scott, How does one know if the vfs.ufs.dirhash_maxmem is set too high and are exhausting KVA ? We set it quite high on our pop3/imap servers since Maildir can contain many small files. eg % sysctl -a vfs.ufs | grep -i dir vfs.ufs.dirhash_minsize: 2560 vfs.ufs.dirhash_maxmem: 99097152 vfs.ufs.dirhash_mem: 59259609 ---Mike Scott ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to "[EMAIL PROTECTED]" ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to "[EMAIL PROTECTED]"
Re: SMP on FreeBSD 6.x and 7.0: Worth doing?
At 10:12 AM 12/24/2007, Scott Long wrote: >It's not the same kind of hashing. The kind of "hashing" that squid >does on the filesystem is sub optimal for UFS performance. Squid doesn't do any "hashing" on the file system, as far as I know. It does, of course, have a hashed directory of cached Web objects. What it does, however, is lay out files and subdirectories so that there are no more than 256 entries in each directory. (The top level directory usually has only 16 subdirectories in it.) What I am saying is that by keeping directory size down and using hexadecimal numbers as the file names, the Squid storage conventions will likely allow the UFS hashing scheme to work very well -- possibly optimally. Which isn't a surprise, because they were designed with UFS in mind. >It sounds like you're pretty convinced you know what the problem is. Again, I'd have to instrument either the FreeBSD kernel or Squid to be 100% sure. But it APPEARS that it's a problem with large numbers of threads trying to do file I/O simultaneously and blocking. (Aside: I wish that Squid used FreeBSD's sendfile(2) API once it got past the headers and was just streaming out a cached page. I suspect that this would make delivery of cache hits a lot more efficient, because sendfile(2) does "zero copy" transfers and works entirely within the kernel.) >For others who might want help with this, tweaking >vfs.ufs.dirhash_maxmem is what is needed. A bit of a balancing act is >needed if you're on i386 since you'll risk exhausting KVA unless you >also tweak KVA_PAGES. If you'd like, I can reassemble the system and try this. What would your suggested values for these tunables be? --Brett ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to "[EMAIL PROTECTED]"
Re: 6.3-RC1: different port/package versions
Bengt Ahlgren wrote: Hi! I'm trying out 6.3-RC1, but had some problems with getting different (and incompatible) versions of packages and ports. When installing packages with sysinstall via FTP, i get older versions compared to using pkg_add -r. The latter (correctly) takes the packages from the packages-6.3-release directory, but sysinstall seems to take the (older) in packages-6-stable. In the sysinstall options, setting "Release Name" to 6.3-RELEASE only results in that it says that the directory does not exist on the FTP server. Is this expected behaviour? Yes, sysinstall hadn't yet been changed to point to the release directory, which was only recently created. Kris ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to "[EMAIL PROTECTED]"
Re: Performance!
Krassimir Slavchev wrote:
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
Hello,
I have read all related threads about performance problems with multi
core systems but still have no idea what to do to make thinks better.
Below are results of testing postgresql on HP DL380G5 using sysbench.
The results are comparable to:
http://blog.insidesystems.net/articles/2007/04/11/postgresql-scaling-on-6-2-and-7-0
but the same tests running on the same hardware using Linux (kernel
2.6.18-53.1.4.el5 SMP x86_64) are very different.
PostgreSQL is tuned equal.
dmesg:
...
CPU: Intel(R) Xeon(R) CPU X5450 @ 3.00GHz (3000.02-MHz
K8-class CPU)
Origin = "GenuineIntel" Id = 0x10676 Stepping = 6
Features=0xbfebfbff
Features2=0xce3bd>
AMD Features=0x2800
AMD Features2=0x1
Cores per package: 4
usable memory = 8575655936 (8178 MB)
avail memory = 8288337920 (7904 MB)
ACPI APIC Table:
FreeBSD/SMP: Multiprocessor System Detected: 8 CPUs
...
test:
sysbench --num-threads=${i} --test=oltp --pgsql-user=bench
- --pgsql-db=bench --db-driver=pgsql --max-time=60 --max-requests=0
- --oltp-read-only=on run
tuning:
kern.ipc.shmmax=2147483647
kern.ipc.shmall=524288
kern.ipc.semmsl=512
kern.ipc.semmap=256
kern.ipc.somaxconn=2048
kern.maxfiles=65536
vfs.read_max=32
kern.ipc.semmni=256
kern.ipc.semmns=2048
results:
FreeBSD 7.0-BETA4 amd64 (cvsup on 20.12) GENERIC with SCHED_ULE
#threads#transactions/sec user/system
1 500 7.4%,5.3%
5 199030.9%,23.4%
10 251039.9%,35.0%
20 254944.5%,43.5%
40 192129.8%,59.4%
60 158022.7%,70.6%
80 134118.9%,75.9%
100 122716.5%,79.3%
Linux
#threads#transactions/sec
1 693
5 3539
10 5789
20 5791
40 5661
60 5517
80 5401
100 5319
What can be done to improve these results?
Best Regards
-BEGIN PGP SIGNATURE-
Version: GnuPG v1.4.7 (FreeBSD)
iD8DBQFHal7hxJBWvpalMpkRAsaiAJ9G3ZoTv6cUbR4yix07TEMf7PKm7gCgoroM
+xvcXkcaFjSTxYfjk5rqMko=
=Tpsq
-END PGP SIGNATURE-
___
freebsd-stable@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-stable
To unsubscribe, send any mail to "[EMAIL PROTECTED]"
.
postgresql has some poor default settings on FreeBSD. You need to add:
stats_command_string = off
update_process_title = off
Kris
___
freebsd-stable@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-stable
To unsubscribe, send any mail to "[EMAIL PROTECTED]"
Re: Trying to initialize padlock support on Via C7 Eden CPU
On Dec 22, 2007, at 1:38 PM, Michael Proto wrote: I purchased a Jetway J7F4K1G2E w/VIA Eden 1.2GHz cpu/motherboard combo (http://e-itx.com/jetway-j7f4k1g2e-mini-itx-motherboard.html) that I'm trying to get working with the FreeBSD padlock driver. Based on what I see from the manufacturer's CPU support list , http://www.jetwaycomputer.com/VIA3.html, I have a C7 Esther processer. It looks like the CPUID for this processor isn't recognized by FreeBSD 6.3-RC1 or 7.0-BETA3. GENERIC on 7.0-BETA3 detects the CPU as follows: FWIW, I have the exact same motherboard from E-ITX as well. I run FreeNAS on mine. FreeNAS is running the FreeBSD 6.2-REL-p8 kernel and detects the CPU just fine: CPU: VIA C7 Esther+RNG+AES+AES-CTR+SHA1+SHA256+RSA (1200.01-MHz 686- class CPU) Origin = "CentaurHauls" Id = 0x6a9 Stepping = 9 Features = 0xa7c9baff < FPU ,VME ,DE ,PSE ,TSC ,MSR ,PAE ,MCE,APIC,SEP,MTRR,PGE,CMOV,PAT,CLFLUSH,ACPI,MMX,FXSR,SSE,SSE2,TM,PBE> Features2=0x181 [[ snip ]] PadLock: HW support loaded for AES-CBC,SHA1,SHA256. It seems you have a newer ID and different Stepping than mine. I have no way to boot 6.3 on this box until FreeNAS is using 6.3. ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to "[EMAIL PROTECTED]"
Re: Packet loss every 30.999 seconds
On Mon, 24 Dec 2007, Kostik Belousov wrote: On Sun, Dec 23, 2007 at 10:20:31AM +1100, Bruce Evans wrote: On Sat, 22 Dec 2007, Kostik Belousov wrote: Ok, since you talked about this first :). I already made the following patch, but did not published it since I still did not inspected all callers of MNT_VNODE_FOREACH() for safety of dropping mount interlock. It shall be safe, but better to check. Also, I postponed the check until it was reported that yielding does solve the original problem. Good. I'd still like to unobfuscate the function call. What do you mean there ? Make the loop control and overheads clear by making the function call explicit, maybe by expanding MNT_VNODE_FOREACH() inline after fixing the style bugs in it. Later, fix the code to match the comment again by not making a function call in the usual case. This is harder. Putting the count in the union seems fragile at best. Even if nothing can access the marker vnode, you need to context-switch its old contents while using it for the count, in case its old contents is used. Vnode- printing routines might still be confused. Could you, please, describe what you mean by "contex-switch" for the VMARKER ? Oh, I didn't notice that the marker vnode is out of band (a whole new vnode is malloced for each marker). The context switching would be needed if an ordinary active vnode that uses the union is used as a marker. Bruce ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to "[EMAIL PROTECTED]"
Re: Packet loss every 30.999 seconds
On Dec 24, 2007, at 8:19 AM, Kostik Belousov wrote: Mark, could you, please, retest the patch below in your setup ? I want to put a change or some edition of it into the 7.0 release, and we need to move fast to do this. It's building now. The testing will run overnight. Your patch to ffs_sync() and vfs_msync() stopped the periodic packet loss, but other file system activity such as (cd /; tar -cf - .) > /dev/ null will cause dropped packets. Same behavior, packets never make it up to the IP layer. -- mark ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to "[EMAIL PROTECTED]"
em1: Unable to allocate bus resource: memory
I just got a new Intel Gb PCIe network card and installed it today. The card is seen by the system but the driver fails to initialize it with the error seen in the email subject. I'm running FreeBSD RELENG_7 from around BETA3 but can upgrade if needed FreeBSD storage.kc8onw.net 7.0-BETA3 FreeBSD 7.0-BETA3 #4: Fri Nov 30 12:40:25 AST 2007 [EMAIL PROTECTED]:/usr/obj/usr/src/sys/STORAGE i386 A standard dmesg is available at http://www.kc8onw.net/~jonathan/temp/dmesg.boot a verbose one can be uploaded if needed. The only changes to the BIOS were to run AHCI instead of emulation for all the SATA drives. Thank you, Jonathan Stewart ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to "[EMAIL PROTECTED]"
Re: SMP on FreeBSD 6.x and 7.0: Worth doing?
On 25/12/2007, Brett Glass <[EMAIL PROTECTED]> wrote: > >It sounds like you're pretty convinced you know what the problem is. > > Again, I'd have to instrument either the FreeBSD kernel or Squid to > be 100% sure. But it APPEARS that it's a problem with large > numbers of threads trying to do file I/O simultaneously and blocking. I'd still check the namei cache; Squid can and does chew through stupid amounts of pathnames. Its why I hacked up that "ifs" thing a few years ago but was suddenly (contractually) required to not hack on caching for a while.. > (Aside: I wish that Squid used FreeBSD's sendfile(2) API once it got past > the headers and was just streaming out a cached page. I suspect that > this would make delivery of cache hits a lot more efficient, because > sendfile(2) does "zero copy" transfers and works entirely within > the kernel.) There's plenty more work to do in Squid before sendfile() would actually matter. I'm slowly working it all out in my spare time and as support contract funding permits. In fact, I think the Linux evolution of sendfile lets you write out a userspace buffer before you glue it to something else like a socket or file fd. That'd be more helpful here. (No idea on the directory sizes these days - perhaps larger files with dir hashing would help; but I certainly haven't benchmarked it. I just use COSS for small objects. :) Adrian -- Adrian Chadd - [EMAIL PROTECTED] ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to "[EMAIL PROTECTED]"
FreeBSD 7.0 freezes with nvidia card
I have a Dell D800 Latitude laptop. If I use FreeBSD 7.0, and xorg with the nv driver, when I exit X, sometimes it simply freezes. I tried it with the vesa driver. and the problem didn't seem to happen, but the vesa driver is unable to get the 1680x1050 resolution of my monitor. I sent a similar message a while back because I thought the ndis driver was also involved. But I have since disabled ndis. (However when ndis is on, the problem is worse.) Any ideas? Stephen ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to "[EMAIL PROTECTED]"
Re: Packet loss every 30.999 seconds
On Mon, Dec 24, 2007 at 08:16:50PM -0500, Mark Fullmer wrote: > > On Dec 24, 2007, at 8:19 AM, Kostik Belousov wrote: > > > > >Mark, could you, please, retest the patch below in your setup ? > >I want to put a change or some edition of it into the 7.0 release, and > >we need to move fast to do this. > > It's building now. The testing will run overnight. > > Your patch to ffs_sync() and vfs_msync() stopped the periodic packet > loss, > but other file system activity such as (cd /; tar -cf - .) > /dev/ > null will > cause dropped packets. Same behavior, packets never make it up to the > IP layer. What fs do you use ? If FFS, are softupdates turned on ? Please, show the total time spent in the softdepflush process. Also, try to add the FULL_PREEMPTION kernel config option and report whether it helps. pgpoDvYHjDAZK.pgp Description: PGP signature
Re: FreeBSD 7.0 freezes with nvidia card
On Monday 24 December 2007, Stephen Montgomery-Smith wrote: > I have a Dell D800 Latitude laptop. If I use FreeBSD 7.0, and xorg > with the nv driver, when I exit X, sometimes it simply freezes. I > tried it with the vesa driver. and the problem didn't seem to > happen, but the vesa driver is unable to get the 1680x1050 > resolution of my monitor. > > I sent a similar message a while back because I thought the ndis > driver was also involved. But I have since disabled ndis. > (However when ndis is on, the problem is worse.) > > Any ideas? > > Stephen > ___ Have you tried the Nvidia driver from ports/x11? It works well for me on my Dell I8600. ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to "[EMAIL PROTECTED]"
Re: FreeBSD 7.0 freezes with nvidia card
David Booth wrote: On Monday 24 December 2007, Stephen Montgomery-Smith wrote: I have a Dell D800 Latitude laptop. If I use FreeBSD 7.0, and xorg with the nv driver, when I exit X, sometimes it simply freezes. I tried it with the vesa driver. and the problem didn't seem to happen, but the vesa driver is unable to get the 1680x1050 resolution of my monitor. I sent a similar message a while back because I thought the ndis driver was also involved. But I have since disabled ndis. (However when ndis is on, the problem is worse.) Any ideas? Stephen ___ Have you tried the Nvidia driver from ports/x11? It works well for me on my Dell I8600. That is what I was originally using. But that also froze. I switched to nv in hopes that the problem would go away. ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to "[EMAIL PROTECTED]"
