Port of Niels Provos's file descriptor allocation code
I've ported Niels Provos's file descriptor allocation code to FreeBSD
in case anyone wants to try it out run some benchmarks. If the performance
boost turns out to be worth the added complexity, I might clean it up a
bit and commit it.
See http://mail-index.netbsd.org/tech-perform/2003/10/28/0001.html and
Banga Mogul's USENIX paper (linked to from the other URL) for the details.
http://perforce.freebsd.org/chv.cgi?CH=43066
--- //depot/user/tjr/freebsd-tjr/src/sys/kern/init_main.c 2003/10/05 17:21:48
+++ //depot/user/tjr/freebsd-tjr/src/sys/kern/init_main.c 2003/11/26 19:42:24
@@ -415,6 +415,8 @@
fdp-fd_fd.fd_ofiles = fdp-fd_dfiles;
fdp-fd_fd.fd_ofileflags = fdp-fd_dfileflags;
fdp-fd_fd.fd_nfiles = NDFILE;
+ fdp-fd_fd.fd_himap = fdp-fd_dhimap;
+ fdp-fd_fd.fd_lomap = fdp-fd_dlomap;
/* Create the limits structures. */
p-p_limit = limit0;
--- //depot/user/tjr/freebsd-tjr/src/sys/kern/kern_descrip.c2003/10/27 00:31:20
+++ //depot/user/tjr/freebsd-tjr/src/sys/kern/kern_descrip.c2003/11/26 19:42:24
@@ -96,6 +96,7 @@
static int do_dup(struct thread *td, enum dup_type type, int old, int new,
register_t *retval);
+static __inline intfind_next_zero(uint32_t *, int, u_int);
/*
* Descriptor management.
@@ -105,6 +106,62 @@
struct sx filelist_lock; /* sx to protect filelist */
struct mtx sigio_lock; /* mtx to protect pointers to sigio */
+static __inline int
+find_next_zero(uint32_t *bitmap, int want, u_int bits)
+{
+ int i, off, maxoff;
+ uint32_t sub;
+
+ if (want bits)
+ return -1;
+
+ off = want NDENTRYSHIFT;
+ i = want NDENTRYMASK;
+ if (i) {
+ sub = bitmap[off] | ((u_int)~0 (NDENTRIES - i));
+ if (sub != ~0)
+ goto found;
+ off++;
+ }
+
+ maxoff = NDLOSLOTS(bits);
+ while (off maxoff) {
+ if ((sub = bitmap[off]) != ~0)
+ goto found;
+ off++;
+ }
+
+ return (-1);
+
+found:
+ return (off NDENTRYSHIFT) + ffs(~sub) - 1;
+}
+
+int
+fd_find_last_set(struct filedesc *fd, int last)
+{
+ int off, i;
+ struct file **ofiles = fd-fd_ofiles;
+ uint32_t *bitmap = fd-fd_lomap;
+
+ off = (last - 1) NDENTRYSHIFT;
+
+ while (!bitmap[off] off = 0)
+ off--;
+
+ if (off 0)
+ return (0);
+
+ i = ((off + 1) NDENTRYSHIFT) - 1;
+ if (i = last)
+ i = last - 1;
+
+ while (i 0 ofiles[i] == NULL)
+ i--;
+
+ return (i);
+}
+
/*
* System calls on descriptors.
*/
@@ -505,13 +562,8 @@
* avoid this case.
*/
if (fdp-fd_ofiles[old] != fp) {
- if (fdp-fd_ofiles[new] == NULL) {
- if (new fdp-fd_freefile)
- fdp-fd_freefile = new;
- while (fdp-fd_lastfile 0
- fdp-fd_ofiles[fdp-fd_lastfile] == NULL)
- fdp-fd_lastfile--;
- }
+ if (fdp-fd_ofiles[new] == NULL)
+ fd_unused(fdp, new);
FILEDESC_UNLOCK(fdp);
fdrop(fp, td);
return (EBADF);
@@ -545,8 +597,7 @@
*/
fdp-fd_ofiles[new] = fp;
fdp-fd_ofileflags[new] = fdp-fd_ofileflags[old] ~ UF_EXCLOSE;
- if (new fdp-fd_lastfile)
- fdp-fd_lastfile = new;
+ fd_used(fdp, new);
FILEDESC_UNLOCK(fdp);
*retval = new;
@@ -836,6 +887,7 @@
#endif
fdp-fd_ofiles[fd] = NULL;
fdp-fd_ofileflags[fd] = 0;
+ fd_unused(fdp, fd);
if (td-td_proc-p_fdtol != NULL) {
/*
* Ask fdfree() to sleep to ensure that all relevant
@@ -849,10 +901,6 @@
* we now hold the fp reference that used to be owned by the descriptor
* array.
*/
- while (fdp-fd_lastfile 0 fdp-fd_ofiles[fdp-fd_lastfile] == NULL)
- fdp-fd_lastfile--;
- if (fd fdp-fd_freefile)
- fdp-fd_freefile = fd;
if (fd fdp-fd_knlistsize) {
FILEDESC_UNLOCK(fdp);
knote_fdclose(td, fd);
@@ -1052,9 +1100,11 @@
struct proc *p = td-td_proc;
struct filedesc *fdp = td-td_proc-p_fd;
int i;
- int lim, last, nfiles;
+ int lim, last, nfiles, oldnfiles;
struct file **newofile, **oldofile;
char *newofileflags;
+ uint32_t *newhimap, *newlomap, *oldhimap, *oldlomap;
+ u_int off, new;
FILEDESC_LOCK_ASSERT(fdp, MA_OWNED);
@@ -1066,12 +1116,28 @@
lim = min((int)p-p_rlimit[RLIMIT_NOFILE].rlim_cur, maxfilesperproc);
for (;;) {
last = min(fdp-fd_nfiles, lim);
+again:
i = max(want, fdp-fd_freefile);
- for (; i last; i++) {
-
Re: 40% slowdown with dynamic /bin/sh
On Wed, 26 Nov 2003, Garance A Drosihn wrote: At 12:23 AM -0500 11/26/03, Michael Edenfield wrote: Just to provide some real-world numbers, here's what I got out of a buildworld: I have reformatted the numbers that Michael reported, into the following table: Static /bin/sh: Dynamic /bin/sh: real385m29.977s real455m44.852s = 18.22% user111m58.508s user113m17.807s = 1.18% sys 93m14.450s sys 103m16.509s = 10.76% user+sys = 5.53% What are people doing to make buildworld so slow? I once optimized makeworld to take 75 minutes on a K6-233 with 64MB of RAM. Things have been pessimized a bit since then, but not signifcantly except for the 100% slowdown of gcc (we now build large things like secure but this is partly compensated for by not building large things like perl). Michael's K7-500 with 320MB (?) of RAM should be serveral times faster than the K6-233, so I would be unhappy if it took more than 75 minutes but would expect it to take bit more than 2 hours when well configured. Here are some buildworld numbers of my own, from my system. In my case, I am running on a single Athlon MP2000, with a gig of memory. It does a buildworld without paging to disk. I have a similar configuration, except with a single Athlon XP1600 overclocked by 146/133 and I always benchmark full makeworlds. I was unhappy when the gcc pessimizations between gcc-2.95 and gcc-3.0 increased the makeworld time from about 24 minutes to about 33 minutes. The time has since increased to about 38 minutes. The latter is cheating slightly -- I leave out the DYNAMICROOT and RESCUE mistakes and the KERBEROS non-mistake. Static sh, No -j: Dynamic sh, No -j: real84m31.366s real86m22.429s = 2.04% user50m33.013s user51m13.080s = 1.32% sys 29m59.047s sys 33m04.082s = 10.29% user+sys = 4.66% Static sh, -j2:Dynamic sh, -j2: real92m38.656s real95m21.027s = 2.92% user51m48.970s user52m29.152s = 1.29% sys 32m07.293s sys 34m40.595s = 7.95% user+sys = 3.84% This also shows why -j should not be used on non-SMP machines. Apart from the make -j bug that causes missed opportunties to run a job, make -j increases real and user times due to competition for resources, so it can only possibly help on systems where unbalanced resources (mainly slow disks) give too much idle time. My current worst makeworld time is almost twice as small as the fastest buildworld time in the above (2788 seconds vs 5071 seconds). From my collection of makeworld benchmarks: %%% Fastest makeworld on a Celeron 366 overclocked by 95/66 (2000/05/15): 3309.30 real 2443.75 user 488.68 sys Last makeworld on a Celeron 366 overclocked by 95/66 (2001/11/19): 4219.83 real 3253.04 user 667.64 sys Fastest makeworld on an Athlon XP1600 overclocked by 146/133 (2002/01/03): 1390.18 real 913.56 user 232.63 sys Last makeworld before gcc-3 on an Athlon XP1600 o/c by 143/133 (2002/05/09) (overclocking reduced and due to memory problems and some local memory-related optimizations turned off): 1532.99 real 1093.08 user 293.15 sys Early makeworld with gcc-3 on an Athlon XP1600 o/c by 143/133 (2002/05/12): 2268.13 real 1613.25 user 313.56 sys Fastest makeworld with gcc-3 an Athlon XP1600 overclocked by 146/133 (maximal overclocking recovered; memory increased from 512MB to 1GB, local memory-related optimizations turned on and tuned) (2003/03/31): 1929.02 real 1576.67 user 205.30 sys Last makeworld before the default bloat became too large for me and I started stopping it for me by putting things like NO_KERBEROS in /etc/make.conf on an Athlon XP1600 o/c by 143/133 (2003/04/29: 2012.75 real 1637.59 user 225.07 sys Makeworld with the defaults (no /etc/make.conf and no local optimizations in the src tree; mainly no pessimizing for Athlons by optimizing for PII's, and no building dependencies; only optimizations in the host environment (mainly no dynamic linkage) on an Athlon as usual (2003/05/06): Last recorded makeworld with local source and make.conf optimizations (mainly no dynamic linkage) on an Athlon as usual (2003/10/22): 2225.83 real 1890.64 user 256.33 sys Last recorded makeworld with the defaults on an Athlon as usual (2003/11/11): 2788.41 real 2316.49 user 357.34 sys %%% I don't see such a large slowdown from using a dynamic /bin/sh. Unrecorded runs of makeworld gave times like the following: 2262 real ... with local opts including src ones and no dynamic linkage 2290 real ... with same except for /bin/sh (only) dynamically linked The difference may be because my /usr/bin/true and similar utilities remain
Re: 40% slowdown with dynamic /bin/sh
In message: [EMAIL PROTECTED] Bruce Evans [EMAIL PROTECTED] writes: : What are people doing to make buildworld so slow? using gcc 3 :-) Warner ___ [EMAIL PROTECTED] mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to [EMAIL PROTECTED]
failed to set signal flags properly for ast()
I'm still getting these on bento (SMP machine) after upgrading to -current. Kris pgp0.pgp Description: PGP signature
Re: Panic with ugen
On Thursday 27 November 2003 01:08, Jay Cornwall wrote: It looks like this: panic() destroy_dev() ugen_destroy_devnodes() ugen_set_config() Yes, that's the one, and I think I can see why. The existing code fixed devfs problems for normal ugen_set_config calls, but doesn't account for what happens when an error occurs (which is presumably happening in your example program, as you said it gives an error the first time round) - the devfs stuff only half completes. (actually, looking at that error handling code, it doesn't look like it's been thought through well anyway - /* XXX should only do this after setting new altno has succeeded */ - maybe time to clean this code up?) After the device endpoints are destroyed (sys/dev/ugen.c:1038), the returns on lines 1055 and 1058 need to be covered by a devnode recovery procedure - particularly tricky given we just wiped the endpoint descriptors clean. I'll look at restructuring this code tomorrow, if Bernd doesn't beat me to it. If you have time left, could you perhaps also have a look at kern/51186? I have filed it back in March and it's still open. (Fixes a memory corruption bug in ugen). grtz, Daan ___ [EMAIL PROTECTED] mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to [EMAIL PROTECTED]
5.1-CURRENT: buildworld fails
For a few past days, after doing make update, buildworld always fails when building pam. Couldn't find it on this list! TIA ___ [EMAIL PROTECTED] mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: 5.1-CURRENT: buildworld fails
On Thu, Nov 27, 2003 at 11:59:16AM +0400, rihad wrote: For a few past days, after doing make update, buildworld always fails when building pam. Couldn't find it on this list! TIA Sorry, my telepathy helmet needs a new potato, so you'll have to help me out here. Kris pgp0.pgp Description: PGP signature
Re: recent current panic
i got a panic on recent -CURRENT: # tcpdump -i lo0 port 23 [1] 507 listening on lo0 # telnet localhost Trying ::1... Wed Nov 26 14:51:23 MSK 2003 Debugger+0x55: xchgl %ebx,in_Debugger.0 db tr Debugger(c0898daf,0,c087197f,d629d8dc,100) at Debugger+0x55 panic(c087197f,c0854d72,c168bd00,c095c9e0,d629d9fc) at panic+0x156 if_simloop(c2cace00,c168bd00,2,0,1) at if_simloop+0xc5 looutput(c2cace00,c168bd00,c2c86290,c2f31400,14b) at looutput+0xde [] It looks very similar to http://www.freebsd.org/cgi/query-pr.cgi?pr=59576. You can revert to version 1.28 of net/bpf.h if you need tcpdump on lo, tun, ic, plip, disc or gif interface right now. Yuriy. ___ [EMAIL PROTECTED] mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: recent current panic
On Wed, Nov 26, 2003 at 03:00:35PM +0300, ?? ? ?? wrote: i got a panic on recent -CURRENT: # tcpdump -i lo0 port 23 [1] 507 listening on lo0 This is a known bug; silby@ is working to fix lo and the rest of the affected network drivers. See PR kern/59576. Here's the local patch to if_loop.c I'm using until this gets fixed. I've patched if_tun.c similarly. Index: if_loop.c === RCS file: /home/ncvs/src/sys/net/if_loop.c,v retrieving revision 1.92 diff -u -r1.92 if_loop.c --- if_loop.c 20 Nov 2003 20:07:37 - 1.92 +++ if_loop.c 27 Nov 2003 08:18:33 - @@ -262,6 +262,7 @@ * will only read from the mbuf (i.e., it won't * try to free it or keep a pointer a to it). */ + bzero(m0, sizeof(m0)); m0.m_next = m; m0.m_len = 4; m0.m_data = (char *)af; ___ [EMAIL PROTECTED] mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: 5.1-CURRENT: buildworld fails
rihad wrote: For a few past days, after doing make update, buildworld always fails when building pam. Couldn't find it on this list! TIA Have you set -02 or similar in your /etc/make.conf? My buildworld also fails if i set any optimizations. Just a guess Sebastian ___ [EMAIL PROTECTED] mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: 5.1-CURRENT: buildworld fails
Sebastian Böck wrote: rihad wrote: For a few past days, after doing make update, buildworld always fails when building pam. Couldn't find it on this list! TIA Have you set -02 or similar in your /etc/make.conf? My buildworld also fails if i set any optimizations. Just a guess /usr/src/lib/libpam/modules/pam_echo/pam_echo.c is compiled with -Werror (treat warnings as errors). And I get: /usr/src/lib/libpam/modules/pam_echo/pam_echo.c: In function `_pam_echo': /usr/src/lib/libpam/modules/pam_echo/pam_echo.c:92: warning: dereferencing type-punned pointer will break strict-aliasing rules *** Error code 1 So the build fails. gcc version 3.3.3 [FreeBSD] 20031106 make.conf does have CPUTYPE?=p4 CFLAGS= -O2 -pipe I'll try to build it without -O2, thanks. ___ [EMAIL PROTECTED] mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to [EMAIL PROTECTED]
panic: softdep_deallocate_dependencies: dangling deps
Hi, got the following panic on an smp system tonight. Dump available for further debugging. FreeBSD haakonia.hitnet.rwth-aachen.de 5.1-CURRENT FreeBSD 5.1-CURRENT #22: Thu Nov 20 20:05:47 CET 2003 [EMAIL PROTECTED]:/usr/obj/usr/src/sys/LORIEN i386 GNU gdb 5.3 (FreeBSD) Copyright 2002 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-portbld-freebsd5.1... panic: softdep_deallocate_dependencies: dangling deps panic messages: --- panic: softdep_deallocate_dependencies: dangling deps cpuid = 1; boot() called on cpu#1 syncing disks, buffers remaining... 3841 3841 3840 3839 3839 3838 3837 3837 3837 3837 3837 3837 3837 3837 3837 3837 3837 3837 3837 3837 3837 3837 3837 3837 3837 3837 giving up on 3183 buffers Uptime: 6d8h13m1s Dumping 511 MB 16 32 48 64 80 96 112 128 144 160 176 192 208 224 240 256 272 288 304 320 336 352 368 384 400 416 432 448 464 480 496 --- #0 doadump () at /usr/src/sys/kern/kern_shutdown.c:240 240 dumping++; (kgdb) where #0 doadump () at /usr/src/sys/kern/kern_shutdown.c:240 #1 0xc0534260 in boot (howto=256) at /usr/src/sys/kern/kern_shutdown.c:372 #2 0xc053465d in panic (fmt=0xc070c19a softdep_deallocate_dependencies: dangling deps) at /usr/src/sys/kern/kern_shutdown.c:550 #3 0xc064ae85 in softdep_deallocate_dependencies (bp=0x0) at /usr/src/sys/ufs/ffs/ffs_softdep.c:5919 #4 0xc057e3fb in brelse (bp=0xcec64fd8) at /usr/src/sys/sys/buf.h:427 #5 0xc058e8fa in flushbuflist (blist=0xcec64fd8, flags=0, vp=0xc6388e38, slpflag=0, slptimeo=0, errorp=0x0) at /usr/src/sys/kern/vfs_subr.c:1269 #6 0xc058e508 in vinvalbuf (vp=0xc6388e38, flags=0, cred=0x0, td=0x0, slpflag=0, slptimeo=0) at /usr/src/sys/kern/vfs_subr.c:1155 #7 0xc05913fd in vclean (vp=0xc6388e38, flags=8, td=0xc472aa00) at /usr/src/sys/kern/vfs_subr.c:2560 #8 0xc0591a41 in vgonel (vp=0xc6388e38, td=0x0) at /usr/src/sys/kern/vfs_subr.c:2756 #9 0xc058d558 in vlrureclaim (mp=0xc4c46800) at /usr/src/sys/kern/vfs_subr.c:725 #10 0xc058d78f in vnlru_proc () at /usr/src/sys/kern/vfs_subr.c:776 #11 0xc051da44 in fork_exit (callout=0xc058d5e0 vnlru_proc, arg=0x0, frame=0x0) at /usr/src/sys/kern/kern_fork.c:793 - Christian -- Christian Brueffer [EMAIL PROTECTED] [EMAIL PROTECTED] GPG Key: http://people.freebsd.org/~brueffer/brueffer.key.asc GPG Fingerprint: A5C8 2099 19FF AACA F41B B29B 6C76 178C A0ED 982D pgp0.pgp Description: PGP signature
Re: please test pcm patch
On Thu, 2003-11-27 at 02:54, Mathew Kanner wrote: Please test a pcm patch that releases the channel lock around calls to uio move. This is a more complete patch than the previous one as it also does the _read routine. I will ask the RE to commit this if I hear a couple of it works. I didn't have the panics, and the patch works fine so far on my hardware. pcm0: CS4236 port 0x530-0x537 on acpi0 device_probe_and_attach: pcm0 attach returned 6 pcm0: CS4236 port 0x530-0x537 on acpi0 device_probe_and_attach: pcm0 attach returned 6 -- FreeBSD 5.2-BETA i386 5:30pm up 8 mins, 1 user, load averages: 0.65, 0.76, 0.43 signature.asc Description: This is a digitally signed message part
Re: 5.1-CURRENT: buildworld fails
On Thu, Nov 27, 2003 at 01:02:18PM +0400, rihad wrote: CFLAGS= -O2 -pipe I'll try to build it without -O2, thanks. *sigh*, I see we need more figlet in the documentation. # CFLAGS controls the compiler settings used when compiling C code. # Note that optimization settings above -O (-O2, ...) are not recommended # or supported for compiling the world or the kernel - please revert any # nonstandard optimization settings to -O before submitting bug reports # to the developers. Kris pgp0.pgp Description: PGP signature
Re: requesting vinum help
Poul-Henning Kamp wrote: With Greg being a core@ member, and well known for his ability to talk an acturan megadonkey into taking a stroll after first having talked its legs off about procedural issues, Doing something about vinum is permanently on the we should really... list and everybody hopes somebody else will deal with it. Of course, in the end nobody does. This isn't a completely fair statement. A lot of people do something about vinum: the break it by changing interfaces out from under it, while failing to adequately maintain vinum, or, in fact, other code which uses those same interfaces. There is no such thing as bit rot; there is only code that is unmaintained by the people who change interfaces out from under it. FreeBSD lost LFS, XNS, and a lot of other code to people who made interface changes, and then later claimed that the code suffered bit rot, when in fact it was obsoleted by those people making that claim failing to get general buy-in for their code changes. FWIW, even though I support the idea of dynamically linking everything, the flipping of the switch there followed this same pattern. -- Terry ___ [EMAIL PROTECTED] mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: panic on 5.2 BETA: blockable sleep lock
On Wed, 2003-11-26 at 08:33, Don Lewis wrote: The problem is that selrecord() wants to lock a MTX_DEF mutex, which can cause a context switch if the mutex is already locked by another thread. This is contrary to what bktr_poll() wants to accomplish by calling critical_enter(). Strange enough that does not seem to happen with a kernel built without INVARIANTS and WITNESS. Does this make any sense or is this just by chance? ___ [EMAIL PROTECTED] mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: 5.2-BETA: giving up on 4 buffers (ata)
On Wed, 2003-11-26 at 19:37, Matthias Andree wrote: Hi, when I rebooted my 5.2-BETA (kernel about 24 hours old), it gave up on flushing 4 dirty blocks. I had three UFS1 softdep file systems mounted on one ATA drive, one ext2 file system on another ATA drive and one ext2 file system on a SCSI drive. Both ext2 file systems had been mounted read-only, so they can't have had dirty blocks. This is a known problem for nearly three months now (See PR 56675). It happens to me every time I shut down the system if i don't unmount my (read-only) ext2 file systems manually. ___ [EMAIL PROTECTED] mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to [EMAIL PROTECTED]
boot process is too slow during installation
Hi, I am trying to install the current-FreeBSD to my Vaio PCG-Z1/P but found the installation boot process is extremely slow. It takes more than 10 minutes to finish loading the disk created from kern.flp and another 10 minutes for mfsroot.flp. Does anyone know what the problem is? The USB floppy drive I am using is sony's PCGA-UF05. The same thing happens with another USB floppy drive which I don't remember the model. I also tried to boot the installation disks of 4.8R, 4.9R and 5.1R but the result were the same. Thanks. Zhang Shu ___ [EMAIL PROTECTED] mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to [EMAIL PROTECTED]
FreeBSD 5.2-BETA: GEOM/CDROM Related Panic
Hello:
I have been getting reproducable panics with most CDROM related actions
including mounting CDROMs and playing audio CDs. IIRC, this has been
happening since the statfs changes a week earlier.
Can provide more information if required. Kernel has been compiled with
device atapicam. I am rebuilding the kernel w/o atapicam ATM.
Thank you for your time.
-- Shanu
http://shankerbalan.com/
[godzilla] ~ uname -a
FreeBSD godzilla.exocore.com 5.2-BETA FreeBSD 5.2-BETA #0: Tue Nov 25
15:34:37 IST 2003
[EMAIL PROTECTED]:/usr/obj/usr/src/sys/MYKERNEL i386
[godzilla] ~ dmesg | egrep -i 'geom|cd0'
GEOM: create disk ad0 dp=0xc2da0360
GEOM: create disk ad2 dp=0xc2d9fe60
acd0: CDROM SAMSUNG CD-ROM SC-152C at ata1-slave PIO4
GEOM: create disk cd0 dp=0xc2d8ce00
cd0 at ata1 bus 0 target 1 lun 0
cd0: SAMSUNG CD-ROM SC-152C CS05 Removable CD-ROM SCSI-0 device
cd0: 16.000MB/s transfers
cd0: Attempt to query device size failed: NOT READY, Medium not present
[godzilla] ~ sudo gdb -k /usr/obj/usr/src/sys/MYKERNEL/kernel.debug
/usr/crash/vmcore.0
GNU gdb 5.2.1 (FreeBSD)
Copyright 2002 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-undermydesk-freebsd...
panic: from debugger
panic messages:
---
Fatal trap 12: page fault while in kernel mode
fault virtual address = 0x1c
fault code = supervisor read, page not present
instruction pointer = 0x8:0xc05d65d8
stack pointer = 0x10:0xce6e1c88
frame pointer = 0x10:0xce6e1c9c
code segment= base 0x0, limit 0xf, type 0x1b
= DPL 0, pres 1, def32 1, gran 1
processor eflags= interrupt enabled, resume, IOPL = 0
current process = 2 (g_event)
panic: from debugger
Fatal trap 3: breakpoint instruction fault while in kernel mode
instruction pointer = 0x8:0xc078570d
stack pointer = 0x10:0xce6e1a34
frame pointer = 0x10:0xce6e1a40
code segment= base 0x0, limit 0xf, type 0x1b
= DPL 0, pres 1, def32 1, gran 1
processor eflags= IOPL = 0
current process = 2 (g_event)
panic: from debugger
Uptime: 3m28s
Dumping 255 MB
16 32 48 64 80 96 112 128 144 160 176 192 208 224 240
---
Reading symbols from /boot/kernel/snd_via82c686.ko...done.
Loaded symbols for /boot/kernel/snd_via82c686.ko
Reading symbols from /boot/kernel/snd_pcm.ko...done.
Loaded symbols for /boot/kernel/snd_pcm.ko
Reading symbols from /usr/obj/usr/src/sys/MYKERNEL/modules/usr/src/sys/modules/l
inprocfs/linprocfs.ko.debug...done.
Loaded symbols for /usr/obj/usr/src/sys/MYKERNEL/modules/usr/src/sys/modules/lin
procfs/linprocfs.ko.debug
Reading symbols from /usr/obj/usr/src/sys/MYKERNEL/modules/usr/src/sys/modules/l
inux/linux.ko.debug...done.
Loaded symbols for /usr/obj/usr/src/sys/MYKERNEL/modules/usr/src/sys/modules/lin
ux/linux.ko.debug
#0 doadump () at /usr/src/sys/kern/kern_shutdown.c:240
240 dumping++;
(kgdb) where
#0 doadump () at /usr/src/sys/kern/kern_shutdown.c:240
#1 0xc05ba724 in boot (howto=260) at /usr/src/sys/kern/kern_shutdown.c:372
#2 0xc05baac8 in panic () at /usr/src/sys/kern/kern_shutdown.c:550
#3 0xc0478a72 in db_panic () at /usr/src/sys/ddb/db_command.c:450
#4 0xc04789ea in db_command (last_cmdp=0xc0880de0, cmd_table=0x0,
aux_cmd_tablep=0xc080f0cc, aux_cmd_tablep_end=0xc080f0d0)
at /usr/src/sys/ddb/db_command.c:346
#5 0xc0478af8 in db_command_loop () at /usr/src/sys/ddb/db_command.c:472
#6 0xc047b879 in db_trap (type=12, code=0) at /usr/src/sys/ddb/db_trap.c:73
#7 0xc0785472 in kdb_trap (type=12, code=0, regs=0xce6e1c48)
at /usr/src/sys/i386/i386/db_interface.c:171
#8 0xc07958f8 in trap_fatal (frame=0xce6e1c48, eva=0)
at /usr/src/sys/i386/i386/trap.c:816
#9 0xc0795613 in trap_pfault (frame=0xce6e1c48, usermode=0, eva=28)
at /usr/src/sys/i386/i386/trap.c:735
#10 0xc0795198 in trap (frame=
{tf_fs = 24, tf_es = 16, tf_ds = 16, tf_edi = 0, tf_esi = -1025102336, tf_
ebp = -831644516, tf_isp = -831644556, tf_ebx = -1025082800, tf_edx = 0, tf_ecx
= -1064771836, tf_eax = 1, tf_trapno = 12, tf_err = 0, tf_eip = -1067620904, tf_
cs = 8, tf_eflags = 66051, tf_esp = -1068020078, tf_ss = -1023775616})
at /usr/src/sys/i386/i386/trap.c:420
#11 0xc0786d48 in calltrap () at {standard input}:94
#12 0xc05795a8 in g_destroy_provider (pp=0xc2e67a50)
---Type return to continue, or q return to quit---
at /usr/src/sys/geom/geom_subr.c:426
#13 0xc057670d in g_orphan_register (pp=0xc2e62e00)
at /usr/src/sys/geom/geom_event.c:143
#14 0xc057681c in one_event () at /usr/src/sys/geom/geom_event.c:169
#15 0xc0576a38 in g_run_events () at /usr/src/sys/geom/geom_event.c:202
#16 0xc05779c5 in g_event_procbody () at
poor NFS performance in CURRENT
Hi :) I upgraded two boxes to FreeBSD-5.2-BETA a week ago and I noticed that NFS performance is very slow compared to 4.x-RELEASE. Before, NFS transfers were between 10 and 12 MB/s and now I don't go past 7 MB/s. My exports/mount settings did not change and the hardware is obviously the same. My kernel is compiled without the debugging options. Any idea where I should start looking for resolving this ? Thanks. Antoine ___ [EMAIL PROTECTED] mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: FreeBSD 5.2-BETA: GEOM/CDROM Related Panic
Hello:
Shanker Balan wrote,
Can provide more information if required. Kernel has been compiled
with device atapicam. I am rebuilding the kernel w/o atapicam ATM.
Kernel w/o atapicam also panics at the same spot.
[godzilla] ~# uname -a
FreeBSD godzilla.exocore.com 5.2-BETA FreeBSD 5.2-BETA #0: Thu Nov 27 15:21:48 IST
2003 [EMAIL PROTECTED]:/usr/obj/usr/src/sys/MYKERNEL i386
[godzilla] ~# gdb -k /boot/kernel/kernel.debug /usr/crash/vmcore.1
(kgdb) where
#0 doadump () at /usr/src/sys/kern/kern_shutdown.c:240
#1 0xc05b9624 in boot (howto=260) at /usr/src/sys/kern/kern_shutdown.c:372
#2 0xc05b99c8 in panic () at /usr/src/sys/kern/kern_shutdown.c:550
#3 0xc04789f2 in db_panic () at /usr/src/sys/ddb/db_command.c:450
#4 0xc047896a in db_command (last_cmdp=0xc087fac0, cmd_table=0x0,
aux_cmd_tablep=0xc080de3c, aux_cmd_tablep_end=0xc080de40)
at /usr/src/sys/ddb/db_command.c:346
#5 0xc0478a78 in db_command_loop () at /usr/src/sys/ddb/db_command.c:472
#6 0xc047b7f9 in db_trap (type=12, code=0) at /usr/src/sys/ddb/db_trap.c:73
#7 0xc0784432 in kdb_trap (type=12, code=0, regs=0xce6e1c48)
at /usr/src/sys/i386/i386/db_interface.c:171
#8 0xc07948b8 in trap_fatal (frame=0xce6e1c48, eva=0)
at /usr/src/sys/i386/i386/trap.c:816
#9 0xc07945d3 in trap_pfault (frame=0xce6e1c48, usermode=0, eva=28)
at /usr/src/sys/i386/i386/trap.c:735
#10 0xc0794158 in trap (frame=
{tf_fs = 24, tf_es = 16, tf_ds = 16, tf_edi = 0, tf_esi = -1025064576, tf_
ebp = -831644516, tf_isp = -831644556, tf_ebx = -1025130752, tf_edx = 0, tf_ecx
= -1064776828, tf_eax = 1, tf_trapno = 12, tf_err = 0, tf_eip = -1067625256, tf_
cs = 8, tf_eflags = 66055, tf_esp = -1068024430, tf_ss = -1025058688})
at /usr/src/sys/i386/i386/trap.c:420
#11 0xc0785d08 in calltrap () at {standard input}:94
#12 0xc05784a8 in g_destroy_provider (pp=0xc2e5bf00)
---Type return to continue, or q return to quit---
at /usr/src/sys/geom/geom_subr.c:426
#13 0xc057560d in g_orphan_register (pp=0xc2e6c180)
at /usr/src/sys/geom/geom_event.c:143
#14 0xc057571c in one_event () at /usr/src/sys/geom/geom_event.c:169
#15 0xc0575938 in g_run_events () at /usr/src/sys/geom/geom_event.c:202
#16 0xc05768c5 in g_event_procbody () at /usr/src/sys/geom/geom_kern.c:134
#17 0xc05a332f in fork_exit (callout=0xc05768a0 g_event_procbody, arg=0x0,
frame=0x0) at /usr/src/sys/kern/kern_fork.c:793
(kgdb)
-- Shanu
http://shankerbalan.com/
--
Everyone has a purpose in life. Perhaps yours is watching television.
- David Letterman
___
[EMAIL PROTECTED] mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-current
To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: 5.2-BETA: giving up on 4 buffers (ata)
On Thu, 27 Nov 2003, Stefan Ehmann wrote: On Wed, 2003-11-26 at 19:37, Matthias Andree wrote: Hi, when I rebooted my 5.2-BETA (kernel about 24 hours old), it gave up on flushing 4 dirty blocks. I had three UFS1 softdep file systems mounted on one ATA drive, one ext2 file system on another ATA drive and one ext2 file system on a SCSI drive. Both ext2 file systems had been mounted read-only, so they can't have had dirty blocks. This is a known problem for nearly three months now (See PR 56675). It happens to me every time I shut down the system if i don't unmount my (read-only) ext2 file systems manually. I'm not sure if the problem is known for the read-only case. It is the same problem as in the read-write case. ext2fs hangs onto buffers, so shutdown cannot tell if it can look at the buffers and considers them to be busy. Then since shutdown cannot tell if it synced all dirty buffers or which buffers are associated with which file systems, it doesn't unmount any file systems and all dirty file systems that aren't unmounted before shutdown are left dirty. Read-only-mounted ext2fs file systems aren't left dirty but they break cleaning of other file systems. Bruce ___ [EMAIL PROTECTED] mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: UFS lockups
Sawek ak [EMAIL PROTECTED] writes: I observe UFS lockups under heavy I/O. To reproduce the problem run around 10 copies of cp -Rp /usr/some-random-dir. All cp's after some time are hanging on getblk. du's running concurrently are hanging in ufs state. The filesystems are UFS2. The Server is running 5.2-BETA on SMP Dell 2650. Filesystems are laid on Adaptec RAID controller (aac). Any ideas how to trace the problem? I managed to obtain trace of one of the processes hung in the ufs state. Sorry for the form, I can't make a text dump of the messages. /S ___ [EMAIL PROTECTED] mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: rtld + static linking
Mark Murray wrote: Terry Lambert writes: Since I have patches to make dlopen work with static binaries, and [ snip ] As to inevitable where are the patches?, please check the -current list archives, you will find at least one set there. I've looked without much success. Could you give a timeframe, a subject and/or something? Note that the part you snipped indicated that the patches were posted by a third party, and that my own patches had been offered, but were not posted in their entirety to the mailing list. In actuality, I only ever posted portions of my own patches, since they also required compiler and linker changes. Here is the reference for Max Khon's patches, which were posted, by reference, in their entirety: | Date: Tue, 5 Nov 2002 13:21:42 +0600 | From: Max Khon [EMAIL PROTECTED] | To:Jake Burkholder [EMAIL PROTECTED] | Cc:[EMAIL PROTECTED] | Subject: Re: libc size | |http://docs.freebsd.org/cgi/getmsg.cgi?fetch=379714+0+archive/2002/freebsd-current/20021110.freebsd-current Portions of my patches were posted as part of the discussion which took place in the same thread. There did not seem to be much buy-in on the idea of modifying the compiler tools. The context of the discussion was for dealing with moving the resolver and other things out of libc, so that they could be more easily upgraded. For the purposes of handling PAM/NSS modules, Max's patches would work to move everything back to a static linking footing. FWIW, I dislike this idea, since static ELF libraries do not properly link against other static ELF libraries, and that type of chaning only works for dynamically linked ELF libraries (for no good reason). -- Terry ___ [EMAIL PROTECTED] mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: rtld + static linking
Marcel Moolenaar wrote:
Ether way, you still need to deal with the linker changes necessary
to export the symbol set for all statically linked objects, and to
force the inclusion of all archive members when statically linking,
if one of the linked libraries is libdl, if you wanted a full
implementation.
I think the cure is worse than the decease in this case. You don't
want the full libc linked into a static sh, simply because we need
to be able to load a shared library at runtime.
The alternative is to create a version association between the
libc.a and libc.so, to allow it to be recovered at runtime. I
don't know how satisfying this would be, but it would resolve
99.9% of the cases, I think. Arguing against inclusion of
everything for all static libraris without a shared counterpart,
and for the main program, is harder. For my money, it's a lot
easier to dynamically link everything, and only deal with one
type of executable image thereafter.
If you can get gcc and binutils to add the necessary support, then
we can talk further. Until then it's academic.
I think there are political reasons for not doing this. The
number one reason would be that you could load GPL'ed code as
a module into a non-GPL'ed program, and then use it without
neding to change your own license to GPL. Editorially, the
FSF compiler folks have some incentive for making dlopen()
inconvenient/difficult to use. If you link dynamic, at
least they get the LGPL behaviour for all your other libraries
as a consolation prize, so making it work is probably on their
list of Things To Not Do.
If the Linux people want to be SUSv3/POSIX/IEEE 1003.1-2003
compliant, they'll do the work and FreeBSD will get it for
free. If thy don't want to do the work, FreeBSD will have to
decide whether they want to carry around local patches, or if
the feature (killing off static vs. dynamic bikesheds) is
worth the effort.
I'm just offering a potential option that's not one of the two
hotly contested ones, as a less controversial approach to a
solution to the original problem. It's the solution that was
chosen for the original problem that has everyone up in arms,
so a different solution seemed to be called for here...
BTW: IEEE 1003.1-2003 requires a full implementation of dlopen, and
does not permit an exception for statically linked binaries:
http://www.opengroup.org/onlinepubs/007904975/functions/dlopen.html
Yes it does:
\begin{quote}
... Implementations may also impose specific constraints on the
construction of programs that can employ dlopen() and its related
services.
\end{quote}
The phrase constraints on the construction of programs sounds
to me like you're allowed to require compile options, not you're
allowed to make it not work as it's documented to work otherwise,
or we might as well say that calling dlopen() in a given system's
implementation is allowed to invoke nethack, like the original
GCC implementation of #pragma did. 8-).
I'll also point out that the ELF specification does not define static
linking *at all*.
I think that's because it doesn't need any special mention.
Well, it specifically mentions being able to do something like
linking libc to libresolv, so that you implicitly get the resolver
library when you explicitly link in the C library. That doesn't
work with static linking of ELF binaries, so I think we can either
say static linking is completely broken and needs to be fixed before
it is allowed to be used, or static linking is undefined by the ELF
standard.
Note that staticly linked executables can be in violation of platform
runtime specifications.
A good reason to outlaw them: undefined behaviour sucks.
-- Terry
___
[EMAIL PROTECTED] mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-current
To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: rtld + static linking
Terry Lambert writes: I've looked without much success. Could you give a timeframe, a subject and/or something? Note that the part you snipped indicated that the patches were posted by a third party, and that my own patches had been offered, but were not posted in their entirety to the mailing list. In actuality, I only ever posted portions of my own patches, since they also required compiler and linker changes. Could you please post your patches in their entirety? M -- Mark Murray iumop ap!sdn w,I idlaH ___ [EMAIL PROTECTED] mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to [EMAIL PROTECTED]
HOME= for root during boot?
During boot (stuff run from rc.local) the enviornment has HOME=/ After boot root logins have HOME=/root. Seems like a bug to me... left over from the days when HOME for root was /. In my case I was trying to run some mysql commands which did not work because there was no /.my.cnf. After boot testing them did work because it looked at /root/.my.cnf Should the line in /etc/rc: HOME=/ change to: HOME=/root FreeBSD xxx.com 5.1-CURRENT FreeBSD 5.1-CURRENT #1: Mon Nov 10 04:05:00 EST 2003 [EMAIL PROTECTED]:/usr/obj/usr/src/sys/RUMBA i386 ___ [EMAIL PROTECTED] mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: atapicam broken by ata_lowlevel.c rev.1.23
At Thu, 27 Nov 2003 00:07:30 -0600, Dan Nelson wrote: In the last episode (Nov 27), Bruce Evans said: [Resending due to no response after 2 weeks.] Rev.1.23 of ata-lowlevel.c broke atapicam on my BP6 system as shown by the enclosed boot -v messages (the system just hangs, apparently waiting for a disk interrupt that never arrives; there seems to be no timeout). If it's any consolation: me too :) Backing out 1.23 worked for me as well. The system that I saw the hang on isn't SMP. I also pre-emptively patched another SMP system before I had to drive in to fix it if it hung. I have a 5.1-current system of Nov 10, also using rev 1.23 of ata-lowlevel.c. Without atapicam in the kernel, it boots ok. With atapicam in the kernel it hangs at the messages (written down from the screen) (probe2:ata1:0:0:0): Retrying Command (probe3:ata1:0:1:0): Retrying Command (probe2:ata2:0:0:0): error 22 (probe4:ata2:0:0:0): Unretryable Error there are a bunch (15?) more lines like this, and then it just hangs. db ___ [EMAIL PROTECTED] mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: Update to 5.2 beta from 5.1-current didn't work right
An update to my previous note: At the tail end of the cvsup, src had already been completed, the system had a drive problem. It kept cycling through these messages on the console: ad4: timeout sending command=ca ad4: error issuing DMA command initiate_write_filepage: already started In this state I couldn't get the system to respond, and had to reboot it. Also when the drive system was tied up, it somehow effects the ethernet, as it brings down the LAN the server is on. Upon reboot, I did: make kernel rebooted, but even with the new kernel the system won't boot into multiuser, behaving the same as it did on the originally installed 5.2 beta kernel. I am in the process of doing: make buildworld if this build succeeds, hopefully the installation of this will correct the multiuser boot problem. -Derek At 08:47 PM 11/26/2003, Derek Ragona wrote: I did a binary update from 5.1-current, created with a mid October snapshot, to 5.2 beta. The installer had trouble, at one point reporting negative disk space available when of course there is plenty of space. This server has a single SATA drive with three slices for FreeBSD, a 5 GB /, and 42 GB /usr, along with swap. I had to do a binary update as this is a system that has been problematic with the ATA subsystem due to the combination of the Adaptec SATA 1210SA (in non RAID mode with a single drive) and a Maxtor 6Y120M0 120 GB drive. The system acts as if some of the older pre 64 bit filesystem code in still present the beta boot/kernel. I did boot from the mini-iso CD-ROM. Once the installer finished, I rebooted. The server claims to be a 5.2 beta kernel, but perhaps as a side effect of the new dynamic linking must have some old pre-64-bit filesystem code it is still using. === $ uname -a FreeBSD barney.computinginnovations.com 5.2-BETA FreeBSD 5.2-BETA #0: Tue Nov 25 08:24:08 GMT 2003 [EMAIL PROTECTED]:/usr/obj/usr/src/sys/GENERIC i386 === As a result, on reboot, df core dumped as did fsck and mount. The static mount in /rescue did work though. As these problems look like what is in UPDATING: === 20031112: The statfs structure has been updated with 64-bit fields to allow accurate reporting of multi-terabyte filesystem sizes. You should build world, then build and boot the new kernel BEFORE doing a `installworld' as the new kernel will know about binaries using the old statfs structure, but an old kernel will not know about the new system calls that support the new statfs structure. Note that the backwards compatibility is only present when the kernel is configured with the COMPAT_FREEBSD4 option. Since even /bin/sh will not run with a new kernel without said option you're pretty much dead in the water without it. Make sure you have COMPAT_FREEBSD4! Running an old kernel after a `make world' will cause programs such as `df' that do a statfs system call to fail with a bad system call. Marco Wertejuk [EMAIL PROTECTED] also reports that cfsd (ports/security/cfs) needs to be recompiled after these changes are installed. === I will cvsup to current then build and install a new kernel, then build and install world per UPDATING. If anyone wants more information, let me know. Below is the verbose dmesg. -Derek verbose dmesg: Nov 26 19:02:28 barney syslogd: kernel boot file is /boot/kernel/kernel Nov 26 19:02:28 barney kernel: 12 14 15 Nov 26 19:02:28 barney kernel: slot 1 10B 0x6a 3 4 5 6 7 9 10 11 12 14 15 Nov 26 19:02:28 barney kernel: slot 1 10C 0x6b 3 4 5 6 7 9 10 11 12 14 15 Nov 26 19:02:28 barney kernel: slot 1 10D 0x68 3 4 5 6 7 9 10 11 12 14 15 Nov 26 19:02:28 barney kernel: slot 2 11A 0x6a 3 4 5 6 7 9 10 11 12 14 15 Nov 26 19:02:28 barney kernel: slot 2 11B 0x69 3 4 5 6 7 9 10 11 12 14 15 Nov 26 19:02:28 barney kernel: slot 2 11C 0x68 3 4 5 6 7 9 10 11 12 14 15 Nov 26 19:02:28 barney kernel: slot 2 11D 0x6b 3 4 5 6 7 9 10 11 12 14 15 Nov 26 19:02:28 barney kernel: slot 3 12A 0x62 3 4 5 6 7 9 10 11 12 14 15 Nov 26 19:02:28 barney kernel: slot 3 12B 0x63 3 4 5 6 7 9 10 11 12 14 15 Nov 26 19:02:28 barney kernel: slot 3 12C 0x61 3 4 5 6 7 9 10 11 12 14 15 Nov 26 19:02:28 barney kernel: slot 3 12D 0x60 3 4 5 6 7 9 10 11 12 14 15 Nov 26 19:02:28 barney kernel: slot 4 13A 0x63 3 4 5 6 7 9 10 11 12 14 15 Nov 26 19:02:28 barney kernel: slot 4 13B 0x62 3 4 5 6 7 9 10 11 12 14 15 Nov 26 19:02:28 barney kernel: slot 4 13C 0x69 3 4 5 6 7 9 10 11 12 14 15 Nov 26 19:02:28 barney kernel: slot 4 13D 0x6a 3 4 5 6 7 9 10 11 12 14 15 Nov 26 19:02:28
Re: please test pcm patch
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 On Wednesday 26 Nov 2003 19:32, Harald Schmalzbauer wrote: it works But I haven't had any problems before (besides some replay delay, thus asynch audio/video) Yes, same here. It works, but I wasn't having problems before: pcm0: Creative EMU10K1 port 0xc400-0xc41f irq 11 at device 12.0 on pci0 pcm0: TriTech TR28602 AC97 Codec Mark -BEGIN PGP SIGNATURE- Version: GnuPG v1.2.3 (FreeBSD) iD8DBQE/xfuoLqgJ90OcaiARAgurAKDNIh8irM7k8/4FafJlligtwoMpMgCeOgNK iDwAaWbWlANfPwWPVAUV5bo= =fYPE -END PGP SIGNATURE- ___ [EMAIL PROTECTED] mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to [EMAIL PROTECTED]
Apples linking
Terry Lambert wrote: FWIW, even though I support the idea of dynamically linking everything, the flipping of the switch there followed this same pattern. -- Terry Terry, what are some of the changes that Apple made to have everything dynamically linked in darwin ? Has anyone done timed runs lately on dynamically vers. static linking on darwin ? Or did they find just cleaning up the dlopen code path seems to be enough to pull dynamically linking everything ? -DR ___ [EMAIL PROTECTED] mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: Panic with ugen
Martin wrote:
panic()
destroy_dev()
ugen_destroy_devnodes()
ugen_set_config()
Could you try the attached patch, to see if it fixes the panic on the second
run of your program?
--
Cheers,
Jay
http://www.evilrealms.net/ - Systems Administrator Developer
http://www.imperial.ac.uk/ - 3rd year CS student
Index: sys/dev/usb/ugen.c
===
RCS file: /home/ncvs/src/sys/dev/usb/ugen.c,v
retrieving revision 1.81
diff -u -3 -p -r1.81 ugen.c
--- sys/dev/usb/ugen.c 9 Nov 2003 09:17:22 - 1.81
+++ sys/dev/usb/ugen.c 27 Nov 2003 14:06:25 -
@@ -1014,8 +1014,8 @@ ugen_set_interface(struct ugen_softc *sc
usbd_interface_handle iface;
usb_endpoint_descriptor_t *ed;
usbd_status err;
- struct ugen_endpoint *sce;
- u_int8_t niface, nendpt, endptno, endpt;
+ struct ugen_endpoint *sce, **sce_cache;
+ u_int8_t niface, nendpt, nendpt_cache, endptno, endpt;
int dir;
DPRINTFN(15, (ugen_set_interface %d %d\n, ifaceidx, altno));
@@ -1033,30 +1033,47 @@ ugen_set_interface(struct ugen_softc *sc
if (err)
return (err);
-#if defined(__FreeBSD__)
- /* destroy the existing devices, we remake the new ones in a moment */
- ugen_destroy_devnodes(sc);
-#endif
+ /* store an array of endpoint descriptors to destroy if the interface
+* change succeeds - these aren't available afterwards */
+ sce_cache = malloc(sizeof(struct ugen_endpoint *) * nendpt, M_TEMP,
+ M_WAITOK);
+ nendpt_cache = nendpt;
- /* XXX should only do this after setting new altno has succeeded */
for (endptno = 0; endptno nendpt; endptno++) {
ed = usbd_interface2endpoint_descriptor(iface,endptno);
endpt = ed-bEndpointAddress;
dir = UE_GET_DIR(endpt) == UE_DIR_IN ? IN : OUT;
- sce = sc-sc_endpoints[UE_GET_ADDR(endpt)][dir];
- sce-sc = 0;
- sce-edesc = 0;
- sce-iface = 0;
+ sce_cache[endptno] = sc-sc_endpoints[UE_GET_ADDR(endpt)][dir];
}
/* change setting */
err = usbd_set_interface(iface, altno);
- if (err)
+ if (err) {
+ free(sce_cache, M_TEMP);
return (err);
+ }
err = usbd_endpoint_count(iface, nendpt);
- if (err)
+ if (err) {
+ free(sce_cache, M_TEMP);
return (err);
+ }
+
+#if defined(__FreeBSD__)
+ /* destroy the existing devices, we remake the new ones in a moment */
+ ugen_destroy_devnodes(sc);
+#endif
+
+ /* now we can clear the old interface's ugen_endpoints */
+ for (endptno = 0; endptno nendpt_cache; endptno++) {
+ sce = sce_cache[endptno];
+ sce-sc = 0;
+ sce-edesc = 0;
+ sce-iface = 0;
+ }
+ free(sce_cache, M_TEMP);
+
+ /* set the new interface's ugen_endpoints */
for (endptno = 0; endptno nendpt; endptno++) {
ed = usbd_interface2endpoint_descriptor(iface,endptno);
endpt = ed-bEndpointAddress;
___
[EMAIL PROTECTED] mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-current
To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: Panic with ugen
Daan Vreeken [PA4DAN] wrote: If you have time left, could you perhaps also have a look at kern/51186? I have filed it back in March and it's still open. (Fixes a memory corruption bug in ugen). I'm not a committer, I'm afraid, so it's probably best to get in touch with the code maintainer. ([EMAIL PROTECTED], if the PR is correct - he did reply at the bottom of the PR) But from a brief look at the code, I can't see anything getting past this line: if(sce-fill sce-cur sce-cur = sce-fill + count) If sce-fill is less than sce-cur, then sce-cur can only be = (sce-fill + count) if count is negative. But I haven't studied the code that closely, so maybe I'm just missing something obvious. :) -- Cheers, Jay http://www.evilrealms.net/ - Systems Administrator Developer http://www.imperial.ac.uk/ - 3rd year CS student ___ [EMAIL PROTECTED] mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: recent current panic
On Thu, 27 Nov 2003, Yuriy Tsibizov wrote: Hi, i got a panic on recent -CURRENT: # tcpdump -i lo0 port 23 [1] 507 listening on lo0 # telnet localhost Trying ::1... Wed Nov 26 14:51:23 MSK 2003 Debugger+0x55: xchgl %ebx,in_Debugger.0 [] It looks very similar to http://www.freebsd.org/cgi/query-pr.cgi?pr=59576. You can revert to version 1.28 of net/bpf.h if you need tcpdump on lo, tun, ic, plip, disc or gif interface right now. just to note: I ran tcpdump on tunN (which was a pppoe interface) w/o problems two days ago (with a recent world) while debugging and testing other net related things. -- Bjoern A. Zeeb bzeeb at Zabbadoz dot NeT 56 69 73 69 74 http://www.zabbadoz.net/ ___ [EMAIL PROTECTED] mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: UFS lockups
Sawek ak [EMAIL PROTECTED] writes: Sawek ak [EMAIL PROTECTED] writes: I observe UFS lockups under heavy I/O. To reproduce the problem run around 10 copies of cp -Rp /usr/some-random-dir. All cp's after some time are hanging on getblk. du's running concurrently are hanging in ufs state. The filesystems are UFS2. The Server is running 5.2-BETA on SMP Dell 2650. Filesystems are laid on Adaptec RAID controller (aac). Any ideas how to trace the problem? I managed to obtain trace of one of the processes hung in the ufs state. Sorry for the form, I can't make a text dump of the messages. Mailman removed the attachment. Here it is: http://prioris.mini.pw.edu.pl/~zaks/zrzut.jpg /S ___ [EMAIL PROTECTED] mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: Apples linking
On Thu, 27 Nov 2003, David Rhodus wrote: FWIW, even though I support the idea of dynamically linking everything, the flipping of the switch there followed this same pattern. Terry, what are some of the changes that Apple made to have everything dynamically linked in darwin ? Has anyone done timed runs lately on dynamically vers. static linking on darwin ? Or did they find just cleaning up the dlopen code path seems to be enough to pull dynamically linking everything ? In Darwin, all binaries but /sbin/init are dynamically linked. There are a number of interesting optimizations, including prebinding. The most interesting variation on the them is a series of system calls that manage a special shared region for prebound libraries. These calls are: int load_shared_file(); int reset_shared_file(); int new_system_shared_region(); Shared regions are managed by privileged processes, such as prebinding daemons, and are used to hold prebound versions of libraries. My understanding is that they are always mapped into processes at the same address, so a prebound version of the library can be used across many applications. In addition, the shared region uses one set of PTEs for all processes it is mapped into, as well as other VM machinery, so it's very low cost to maintain. If a library isn't found in the prebinding cache, the application does the work itself, but probably sends a message off. During system/application install, I believe OS X kicks off a tool to see if its current prebinding cache/layout/etc is optimal for the set of applications, and adjusts the cache as needed. I don't have access to any of the performance measurements -- perhaps Terry does -- but this approach has a number of important benefits. In particular, it addresses the following issues: (1) Libraries are frequently mapped at different addresses for different applications, meaning that prebinding can't be efficient if you're just caching the relocation data. I think I posted some stats in an earlier post, but I found even libc was mapped at about 40 different addresses on my notebook running XFree86, KDE. And that is with KDE's internal prebinding support. (2) It avoids substantial overhead in maintaining mappings of files that are mapped into many processes. So not only do you see the benefits of prebinding itself, but reduced overhead to many mappings. (3) Maintains a desirable privilege model, in which applications can't mess with the prebinding cache, but can make use of it easily. Apparently (2) is particular important on PowerPC processors, but presumably applies to other processor architectures. The one thing that turns me off to this scheme is that I'd like it if we could find a way to represent this using solely existing BSD/UNIX kernel primitives (mmap, et al) and userspace, rather than adding special-purpose system calls that complicated various code paths, and that aren't portable. As I mentioned previously in this thread, it could be we could witness a lot of the benefits of this approach by simply using heuristics to increase the likelihood of libraries getting mapped to the same address in different processes, increasing the effectiveness (and reducing the size) of the prebinding cache. Robert N M Watson FreeBSD Core Team, TrustedBSD Projects [EMAIL PROTECTED] Network Associates Laboratories ___ [EMAIL PROTECTED] mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: Panic with ugen
On Thursday 27 November 2003 15:33, Jay Cornwall wrote: Daan Vreeken [PA4DAN] wrote: If you have time left, could you perhaps also have a look at kern/51186? I have filed it back in March and it's still open. (Fixes a memory corruption bug in ugen). I'm not a committer, I'm afraid, so it's probably best to get in touch with the code maintainer. ([EMAIL PROTECTED], if the PR is correct - he did reply at the bottom of the PR) But from a brief look at the code, I can't see anything getting past this line: if(sce-fill sce-cur sce-cur = sce-fill + count) If sce-fill is less than sce-cur, then sce-cur can only be = (sce-fill + count) if count is negative. But I haven't studied the code that closely, so maybe I'm just missing something obvious. :) It can. Imagine a buffer of 1000 bytes. sce-fill=980 and sce-cur=990. If we have to store 40 bytes, sce-fill (980) is smaller than sce-cur (990). And sce-cur (990) is smaller or equal to sce-fill + count (980+40=1020). After that count gets added to sce-cur ( sce-cur=990+40=1030). Now sce-cur is bigger than sce-limit so this line of code get execute : sce-cur = sce-ibuf + (sce-limit - sce-cur); Leading to : sce-cur = sce-ibuf + ( 1000 - 1030 ) = beginning-of-buffer - 30 ! In stead of : sce-cur = sce-ibuf + ( 1030 - 1000 ) = beginning-of-buffer + 30 grtz, Daan ___ [EMAIL PROTECTED] mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to [EMAIL PROTECTED]
Bitrot -- loss of LFS
Answering Terry's comment about LFS: I had about 90% of the LFS development complete (rewritten to eliminate much of the unnecessary and inefficient copying.) At that time, Kirk had started softupdates, but I also KNEW and UNDERSTOOD the limitations of LFS. In essense, after CAREFULLY reading and understanding Ganger and Patt (and knowing about Kirk's work), I had decided that LFS would have been a folly. (It would have been a maintenance issue, people would have 'gotten used' to the feature, and would have been a wasted allocation of development resources.) LFS (as existent in 4.4) was an interesting experiment, and was excluded (by me) because of the amount of ongoing support (including bringing it up to product quality.) If you look at the original code -- you'll notice ALOT of unnecessary copying and primitive memory management. It was DEFINITELY a good research project, and perhaps worthwhile if softupdates hadn't happened. John ___ [EMAIL PROTECTED] mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: Update to 5.2 beta from 5.1-current didn't work right
After doing: make buildworld make buildkernel KERNCONF=GENERIC make installkernel KERNCONF=GENERIC reboot mergemaster -p make installworld mergemaster reboot The system booted multiuser correctly and appears to be operating correctly. -Derek At 07:05 AM 11/27/2003, Derek Ragona wrote: An update to my previous note: At the tail end of the cvsup, src had already been completed, the system had a drive problem. It kept cycling through these messages on the console: ad4: timeout sending command=ca ad4: error issuing DMA command initiate_write_filepage: already started In this state I couldn't get the system to respond, and had to reboot it. Also when the drive system was tied up, it somehow effects the ethernet, as it brings down the LAN the server is on. Upon reboot, I did: make kernel rebooted, but even with the new kernel the system won't boot into multiuser, behaving the same as it did on the originally installed 5.2 beta kernel. I am in the process of doing: make buildworld if this build succeeds, hopefully the installation of this will correct the multiuser boot problem. -Derek At 08:47 PM 11/26/2003, Derek Ragona wrote: I did a binary update from 5.1-current, created with a mid October snapshot, to 5.2 beta. The installer had trouble, at one point reporting negative disk space available when of course there is plenty of space. This server has a single SATA drive with three slices for FreeBSD, a 5 GB /, and 42 GB /usr, along with swap. I had to do a binary update as this is a system that has been problematic with the ATA subsystem due to the combination of the Adaptec SATA 1210SA (in non RAID mode with a single drive) and a Maxtor 6Y120M0 120 GB drive. The system acts as if some of the older pre 64 bit filesystem code in still present the beta boot/kernel. I did boot from the mini-iso CD-ROM. Once the installer finished, I rebooted. The server claims to be a 5.2 beta kernel, but perhaps as a side effect of the new dynamic linking must have some old pre-64-bit filesystem code it is still using. === $ uname -a FreeBSD barney.computinginnovations.com 5.2-BETA FreeBSD 5.2-BETA #0: Tue Nov 25 08:24:08 GMT 2003 [EMAIL PROTECTED]:/usr/obj/usr/src/sys/GENERIC i386 === As a result, on reboot, df core dumped as did fsck and mount. The static mount in /rescue did work though. As these problems look like what is in UPDATING: === 20031112: The statfs structure has been updated with 64-bit fields to allow accurate reporting of multi-terabyte filesystem sizes. You should build world, then build and boot the new kernel BEFORE doing a `installworld' as the new kernel will know about binaries using the old statfs structure, but an old kernel will not know about the new system calls that support the new statfs structure. Note that the backwards compatibility is only present when the kernel is configured with the COMPAT_FREEBSD4 option. Since even /bin/sh will not run with a new kernel without said option you're pretty much dead in the water without it. Make sure you have COMPAT_FREEBSD4! Running an old kernel after a `make world' will cause programs such as `df' that do a statfs system call to fail with a bad system call. Marco Wertejuk [EMAIL PROTECTED] also reports that cfsd (ports/security/cfs) needs to be recompiled after these changes are installed. === I will cvsup to current then build and install a new kernel, then build and install world per UPDATING. If anyone wants more information, let me know. Below is the verbose dmesg. -Derek verbose dmesg: Nov 26 19:02:28 barney syslogd: kernel boot file is /boot/kernel/kernel Nov 26 19:02:28 barney kernel: 12 14 15 Nov 26 19:02:28 barney kernel: slot 1 10B 0x6a 3 4 5 6 7 9 10 11 12 14 15 Nov 26 19:02:28 barney kernel: slot 1 10C 0x6b 3 4 5 6 7 9 10 11 12 14 15 Nov 26 19:02:28 barney kernel: slot 1 10D 0x68 3 4 5 6 7 9 10 11 12 14 15 Nov 26 19:02:28 barney kernel: slot 2 11A 0x6a 3 4 5 6 7 9 10 11 12 14 15 Nov 26 19:02:28 barney kernel: slot 2 11B 0x69 3 4 5 6 7 9 10 11 12 14 15 Nov 26 19:02:28 barney kernel: slot 2 11C 0x68 3 4 5 6 7 9 10 11 12 14 15 Nov 26 19:02:28 barney kernel: slot 2 11D 0x6b 3 4 5 6 7 9 10 11 12 14 15 Nov 26 19:02:28 barney kernel: slot 3 12A 0x62 3 4 5 6 7 9 10 11 12 14 15 Nov 26 19:02:28 barney kernel: slot 3 12B 0x63 3 4 5 6 7 9 10 11 12 14 15 Nov 26 19:02:28 barney kernel: slot 3 12C 0x61 3 4 5 6 7 9 10 11 12 14 15 Nov 26 19:02:28 barney kernel: slot 3 12D 0x60 3 4 5 6 7 9 10 11 12 14 15 Nov 26 19:02:28 barney kernel: slot 4 13A 0x63 3 4 5 6 7 9 10 11 12 14
Re: 5.2-BETA: giving up on 4 buffers (ata)
On Thu, Nov 27, 2003 a.d., Bruce Evans wrote: This is a known problem for nearly three months now (See PR 56675). It happens to me every time I shut down the system if i don't unmount my (read-only) ext2 file systems manually. I'm not sure if the problem is known for the read-only case. It is the same problem as in the read-write case. ext2fs hangs onto buffers, so shutdown cannot tell if it can look at the buffers and considers them to be busy. Then since shutdown cannot tell if it synced all dirty buffers or which buffers are associated with which file systems, it doesn't unmount any file systems and all dirty file systems that aren't unmounted before shutdown are left dirty. Read-only-mounted ext2fs file systems aren't left dirty but they break cleaning of other file systems. I positively know that the given up buffers are the ones got with bread() in compute_sb_data() (ext2_vfsops:481). I doesn't matter if the mount is rw or ro. The comments in fs.h:155 suggests they will be released by biodone, but this doesn't happen :-) Regards, Adi ___ [EMAIL PROTECTED] mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: atapicam broken by ata_lowlevel.c rev.1.23
At Thu, 27 Nov 2003 08:54:53 -0400, Bremner David wrote: I have a 5.1-current system of Nov 10, also using rev 1.23 of ata-lowlevel.c. Without atapicam in the kernel, it boots ok. With atapicam in the kernel it hangs at the messages (written down from the screen) (probe2:ata1:0:0:0): Retrying Command (probe3:ata1:0:1:0): Retrying Command (probe2:ata2:0:0:0): error 22 (probe4:ata2:0:0:0): Unretryable Error there are a bunch (15?) more lines like this, and then it just hangs. db Hmm. with revision 1.22 of ata-lowlevel.c, the system boots with the atapicam device, and writing DVD+R media with growisofs seems to _almost_ work. Unfortunately, almost isn't worth much in these kind of things. growisofs -Z /dev/cd0=premastered.iso gets to the end of writing and prints /dev/pass0: flushing cache /dev/pass0: closing track - [unable to TEST UNIT READY]: Input/output error the resulting coaster won't mount convex# mount /dev/cd0 /mnt mount: /dev/cd0: Input/output error dvd+rw-mediainfo /dev/cd0 reports - [unable to READ DVD STRUCTURE#0 ()] INQUIRY:[PLEXTOR ][DVDR PX-708A ][1.02] GET [CURRENT] CONFIGURATION: Mounted Media: 1Bh, DVD+R READ DVD STRUCTURE[#11h]: Current Write Speed: 2.4x1385=3324KB/s Write Speed #0:2.4x1385=3324KB/s READ DISC INFORMATION: Disc status: appendable Number of Sessions:1 State of Last Session: incomplete Next Track: 1 Number of Tracks: 2 READ TRACK INFORMATION[#1]: Track State: partial Track Start Address: 0*2KB Next Writable Address: 1566080*2KB Free Blocks: 0*2KB Track Size:1566080*2KB READ TRACK INFORMATION[#2]: Track State: complete Track Start Address: 1566096*2KB Next Writable Address: 1566096*2KB Free Blocks: 729008*2KB Track Size:729008*2KB FABRICATED TOC: Track#1 : [EMAIL PROTECTED] Track#AA : [EMAIL PROTECTED] Multi-session Info:[EMAIL PROTECTED] Coastering for the cause, db ___ [EMAIL PROTECTED] mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: Apples linking
RW Date: Thu, 27 Nov 2003 11:24:23 -0500 (EST) RW From: Robert Watson [ CC list trimmed ] RW The one thing that turns me off to this scheme is that I'd RW like it if we could find a way to represent this using solely RW existing BSD/UNIX kernel primitives (mmap, et al) and RW userspace, rather than adding special-purpose system calls RW that complicated various code paths, and that aren't RW portable. Would rtld-elf/rtld.c:map_object() be a reasonable place to add hooks for speaking with a daemon that does the actual tracking work? True, the daemon might die... in which case rtld probably should revert to traditional behavior rather than refusing to load a binary. Eddy -- Brotsman Dreger, Inc. - EverQuick Internet Division Bandwidth, consulting, e-commerce, hosting, and network building Phone: +1 785 865 5885 Lawrence and [inter]national Phone: +1 316 794 8922 Wichita _ DO NOT send mail to the following addresses : [EMAIL PROTECTED] -or- [EMAIL PROTECTED] -or- [EMAIL PROTECTED] Sending mail to spambait addresses is a great way to get blocked. ___ [EMAIL PROTECTED] mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to [EMAIL PROTECTED]
5.2-BETA lock up during ports extraction
The subject says it all. Sorry, no DMESG output, as it has not yet been installed. My relavent hardware is: Pentium 4 - 3.06GHz w/800MHz FSB Hyperthreading 512MB Rambus Dell Dimension 8250 Tom Veldhouse ___ [EMAIL PROTECTED] mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: 5.2-BETA lock up during ports extraction
Actually, the memory is 512MB PC1066 RDRAM (Rambus). The FSB is 533MHz. Tom Veldhouse The subject says it all. Sorry, no DMESG output, as it has not yet been installed. My relavent hardware is: Pentium 4 - 3.06GHz w/800MHz FSB Hyperthreading 512MB Rambus Dell Dimension 8250 Tom Veldhouse ___ [EMAIL PROTECTED] mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to [EMAIL PROTECTED]
Frequent lockups with 5.2-BETA
Since upgrading from 5.1-RELEASE to 5.2-BETA, I've been experiencing hard lockups once or twice every day. I managed to get a trace by enabling the watchdog, which put me into the debugger. This is the trace: db trace Debugger(c06f85ec,1bc169d,0,c0754fc4,c0754bf8) at Debugger+0x54 watchdog_fire(d73e2bcc,c067b433,c0c57100,0,d73e2bcc) at watchdog_fire+0xc1 hardclock(d73e2bcc,0,0,d73e2b98,c43bd400) at hardclock+0x15a clkintr(d73e2bcc,d73e2b9c,c06c6bf6,0,c1925000) at clkintr+0xe9 intr_execute_handlers(c0756be0,d73e2bcc,c0c570a0,1000,c0c61300) at intr_execute8 atpic_handle_intr(0) at atpic_handle_intr+0xef Xatpic_intr0() at Xatpic_intr0+0x1e --- interrupt, eip = 0xc068db74, esp = 0xd73e2c10, ebp = 0xd73e2c14 --- uma_zone_slab(c0c61300,1,0,c068e516,c074edd8) at uma_zone_slab+0x4 uma_zalloc_internal(c0c61300,0,1,0,d73e2c80) at uma_zalloc_internal+0x5c bucket_alloc(2f,1,0,0,0) at bucket_alloc+0x65 uma_zfree_arg(c0c48240,c49121b8,0,c1922580,3600) at uma_zfree_arg+0x2c6 tcp_hc_purge(0,c1922580,161e9,142b64fd,c05d7c70) at tcp_hc_purge+0x11f softclock(0,0,0,0,c192b54c) at softclock+0x25e ithread_loop(c1922580,d73e2d48,0,11,55ff44fd) at ithread_loop+0x1d8 fork_exit(c0524ec0,c1922580,d73e2d48) at fork_exit+0x80 fork_trampoline() at fork_trampoline+0x8 --- trap 0x1, eip = 0, esp = 0xd73e2d7c, ebp = 0 --- This is the dmesg from the last boot: Copyright (c) 1992-2003 The FreeBSD Project. Copyright (c) 1979, 1980, 1983, 1986, 1988, 1989, 1991, 1992, 1993, 1994 The Regents of the University of California. All rights reserved. FreeBSD 5.2-BETA #7: Wed Nov 26 17:24:32 CET 2003 [EMAIL PROTECTED]:/usr/obj/usr/src/sys/BORG Preloaded elf kernel /boot/kernel/kernel at 0xc0823000. Timecounter i8254 frequency 1193182 Hz quality 0 CPU: Intel(R) Celeron(R) CPU 1.70GHz (1716.04-MHz 686-class CPU) Origin = GenuineIntel Id = 0xf13 Stepping = 3 Features=0x3febfbffFPU,VME,DE,PSE,TSC,MSR,PAE,MCE,CX8,APIC,SEP,MTRR,PGE,MCA,CMOV,PAT,PSE36,CLFLUSH,DTS,ACPI,MMX,FXSR,SSE,SSE2,SS,HTT,TM real memory = 536805376 (511 MB) avail memory = 511885312 (488 MB) Pentium Pro MTRR support enabled acpi0: AMIINT INTEL845 on motherboard pcibios: BIOS version 2.10 Using $PIR table, 15 entries at 0xc00f7810 acpi0: Power Button (fixed) Timecounter ACPI-fast frequency 3579545 Hz quality 1000 acpi_timer0: 24-bit timer at 3.579545MHz port 0x808-0x80b on acpi0 acpi_cpu0: CPU port 0x530-0x537 on acpi0 acpi_cpu1: CPU port 0x530-0x537 on acpi0 device_probe_and_attach: acpi_cpu1 attach returned 6 acpi_button0: Power Button on acpi0 pcib0: ACPI Host-PCI bridge port 0xcf8-0xcff on acpi0 pci0: ACPI PCI bus on pcib0 agp0: Intel Generic host to PCI bridge mem 0xe000-0xe3ff at device 0.0 on pci0 pcib1: PCI-PCI bridge at device 1.0 on pci0 pci1: PCI bus on pcib1 pcib0: slot 1 INTA is routed to irq 5 pcib1: slot 0 INTA is routed to irq 5 pci1: display, VGA at device 0.0 (no driver attached) pcib2: ACPI PCI-PCI bridge at device 30.0 on pci0 pci2: ACPI PCI bus on pcib2 pcib2: slot 10 INTA is routed to irq 10 pcib2: slot 13 INTA is routed to irq 3 pcm0: CMedia CMI8738 port 0xdc00-0xdcff irq 10 at device 10.0 on pci2 em0: Intel(R) PRO/1000 Network Connection, Version - 1.7.19 port 0xd800-0xd83f mem 0xdfec-0xdfed,0xdfee-0xdfef irq 3 at device 13.0 on pci2 em0: Speed:N/A Duplex:N/A isab0: PCI-ISA bridge at device 31.0 on pci0 isa0: ISA bus on isab0 atapci0: Intel ICH4 UDMA100 controller port 0xfc00-0xfc0f,0-0x3,0-0x7,0-0x3,0-0x7 at device 31.1 on pci0 ata0: at 0x1f0 irq 14 on atapci0 ata0: [MPSAFE] ata1: at 0x170 irq 15 on atapci0 ata1: [MPSAFE] pci0: serial bus, SMBus at device 31.3 (no driver attached) atkbdc0: Keyboard controller (i8042) port 0x64,0x60 irq 1 on acpi0 atkbd0: AT Keyboard flags 0x1 irq 1 on atkbdc0 kbd0 at atkbd0 psm0: PS/2 Mouse irq 12 on atkbdc0 psm0: model MouseMan+, device ID 0 fdc0: cmd 3 failed at out byte 1 of 3 sio0 port 0x3f8-0x3ff irq 4 on acpi0 sio0: type 16550A, console ppc0 port 0x778-0x77b,0x378-0x37f irq 7 drq 3 on acpi0 ppc0: SMC-like chipset (ECP/EPP/PS2/NIBBLE) in COMPATIBLE mode ppc0: FIFO with 16/16/9 bytes threshold ppbus0: Parallel port bus on ppc0 plip0: PLIP network interface on ppbus0 lpt0: Printer on ppbus0 lpt0: Interrupt-driven port ppi0: Parallel I/O on ppbus0 acpi_cpu1: CPU port 0x530-0x537 on acpi0 device_probe_and_attach: acpi_cpu1 attach returned 6 fdc0: cmd 3 failed at out byte 1 of 3 npx0: [FAST] npx0: math processor on motherboard npx0: INT 16 interface orm0: Option ROM at iomem 0xe-0xe0fff on isa0 pmtimer0 on isa0 fdc0: cannot reserve I/O port range (6 ports) sc0: System console at flags 0x100 on isa0 sc0: VGA 16 virtual consoles, flags=0x100 sio1: configured irq 3 not in bitmap of probed irqs 0 sio1: port may not be enabled vga0: Generic ISA VGA at port 0x3c0-0x3df iomem 0xa-0xb on isa0 Timecounter TSC frequency 1716042336 Hz quality 800 Timecounters tick every 10.000 msec IPv6 packet filtering initialized, default to accept, logging limited to 100 packets/entry
C99's round() and roundf() math functions
Has anyone implemented the C99 math functions round() and roundf()? -- Steve ___ [EMAIL PROTECTED] mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to [EMAIL PROTECTED]
please test sndstat lor patch
Hello Gang,
I wrote this to cleanup /dev/sndstat a little and fix a LOR.
Then I couldn't remember if there is a LOR or not. Could someone
please remind me? If we do, could someone please test this patch.
Thanks,
--Mat
--
The beaver, which has come to represent Canada as the eagle
does the United States and the lion Britain, is a
flat-tailed, slow-witted, toothy rodent known to bite off
it's own testicles or to stand under its own falling trees.
- June Callwood
Index: sndstat.c
===
RCS file: /home/ncvs/src/sys/dev/sound/pcm/sndstat.c,v
retrieving revision 1.14
diff -u -r1.14 sndstat.c
--- sndstat.c 7 Sep 2003 16:28:03 - 1.14
+++ sndstat.c 27 Nov 2003 18:21:06 -
@@ -56,44 +56,41 @@
int type, unit;
};
-#ifdef USING_MUTEX
-static struct mtx sndstat_lock;
-#endif
-static struct sbuf sndstat_sbuf;
static dev_t sndstat_dev = 0;
static int sndstat_isopen = 0;
-static int sndstat_bufptr;
+
+struct sndstat {
+ void *rawbuf;
+ struct sbuf sbuf;
+ int bufptr;
+ int isopen;
+};
+
+static struct mtx sndstat_lock;
static int sndstat_maxunit = -1;
static int sndstat_files = 0;
static SLIST_HEAD(, sndstat_entry) sndstat_devlist = SLIST_HEAD_INITIALIZER(none);
static int sndstat_verbose = 1;
-#ifdef USING_MUTEX
TUNABLE_INT(hw.snd.verbose, sndstat_verbose);
-#else
-TUNABLE_INT_DECL(hw.snd.verbose, 1, sndstat_verbose);
-#endif
static int sndstat_prepare(struct sbuf *s);
static int
sysctl_hw_sndverbose(SYSCTL_HANDLER_ARGS)
{
- intrmask_t s;
int error, verbose;
verbose = sndstat_verbose;
error = sysctl_handle_int(oidp, verbose, sizeof(verbose), req);
if (error == 0 req-newptr != NULL) {
- s = spltty();
mtx_lock(sndstat_lock);
if (verbose 0 || verbose 3)
error = EINVAL;
else
sndstat_verbose = verbose;
mtx_unlock(sndstat_lock);
- splx(s);
}
return error;
}
@@ -103,32 +100,26 @@
static int
sndstat_open(dev_t i_dev, int flags, int mode, struct thread *td)
{
- intrmask_t s;
+ struct sndstat *s = i_dev-si_drv1;
int error;
- s = spltty();
+ if (s == NULL)
+ return ENXIO;
+
mtx_lock(sndstat_lock);
if (sndstat_isopen) {
mtx_unlock(sndstat_lock);
- splx(s);
return EBUSY;
}
- sndstat_isopen = 1;
+ sndstat_isopen = s-isopen = 1;
mtx_unlock(sndstat_lock);
- splx(s);
- if (sbuf_new(sndstat_sbuf, NULL, 4096, 0) == NULL) {
- error = ENXIO;
- goto out;
- }
- sndstat_bufptr = 0;
- error = (sndstat_prepare(sndstat_sbuf) 0) ? 0 : ENOMEM;
-out:
+ sbuf_clear(s-sbuf);
+ s-bufptr = 0;
+ error = (sndstat_prepare(s-sbuf) 0) ? 0 : ENOMEM;
if (error) {
- s = spltty();
mtx_lock(sndstat_lock);
- sndstat_isopen = 0;
+ sndstat_isopen = s-isopen = 0;
mtx_unlock(sndstat_lock);
- splx(s);
}
return (error);
}
@@ -136,42 +127,40 @@
static int
sndstat_close(dev_t i_dev, int flags, int mode, struct thread *td)
{
- intrmask_t s;
+ struct sndstat *s = i_dev-si_drv1;
+ if (s == NULL)
+ return ENXIO;
- s = spltty();
mtx_lock(sndstat_lock);
if (!sndstat_isopen) {
mtx_unlock(sndstat_lock);
- splx(s);
return EBADF;
}
- sbuf_delete(sndstat_sbuf);
- sndstat_isopen = 0;
+ sndstat_isopen = s-isopen = 0;
mtx_unlock(sndstat_lock);
- splx(s);
return 0;
}
static int
sndstat_read(dev_t i_dev, struct uio *buf, int flag)
{
- intrmask_t s;
+ struct sndstat *s = i_dev-si_drv1;
int l, err;
- s = spltty();
+ if (s == NULL)
+ return ENXIO;
+
mtx_lock(sndstat_lock);
if (!sndstat_isopen) {
mtx_unlock(sndstat_lock);
- splx(s);
return EBADF;
}
- l = min(buf-uio_resid, sbuf_len(sndstat_sbuf) - sndstat_bufptr);
- err = (l 0)? uiomove(sbuf_data(sndstat_sbuf) + sndstat_bufptr, l, buf) : 0;
- sndstat_bufptr += l;
+ l = min(buf-uio_resid, sbuf_len(s-sbuf) - s-bufptr);
+ err = (l 0)? uiomove(sbuf_data(s-sbuf) + s-bufptr, l, buf) : 0;
+ s-bufptr += l;
mtx_unlock(sndstat_lock);
- splx(s);
return err;
}
@@ -193,7 +182,6 @@
int
sndstat_register(device_t dev, char *str, sndstat_handler handler)
{
- intrmask_t s;
struct sndstat_entry *ent;
const char *devtype;
int type, unit;
@@ -214,7 +202,7 @@
Re: Panic with ugen
On Thu, 2003-11-27 at 15:24, Jay Cornwall wrote: Could you try the attached patch, to see if it fixes the panic on the second run of your program? No success. Still same panic. Martin ___ [EMAIL PROTECTED] mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: rtld + static linking
On Thu, Nov 27, 2003 at 03:41:14AM -0800, Terry Lambert wrote: If you can get gcc and binutils to add the necessary support, then we can talk further. Until then it's academic. I think there are political reasons for not doing this. The number one reason would be that you could load GPL'ed code as a module into a non-GPL'ed program, and then use it without neding to change your own license to GPL. The use of dlopen() does not circumvent that you're creating a modified version. The GPL-incompatible code and the GPL code do not communicate at arms length. Hence, the GPL-incompatible code is to be relicensed if the modified work is to be distributed.i Alternatively, ask the license holder for an exception or see if the library can be relicensed under the LGPL. From a GPL licensing point of view dlopen() is no different than static linking. I'll also point out that the ELF specification does not define static linking *at all*. I think that's because it doesn't need any special mention. Well, it specifically mentions being able to do something like linking libc to libresolv, so that you implicitly get the resolver library when you explicitly link in the C library. That doesn't work with static linking of ELF binaries, so I think we can either say static linking is completely broken and needs to be fixed before it is allowed to be used, or static linking is undefined by the ELF standard. Recording dependencies in ELF files is specific to dynamic linking. In fact, there's nothing that you need to add to ELF headers or sections to make static linking work. It's irrelevant to an ELF specification. That's why it's not mentioned. Dynamic linking needs special headers and/or sections in the ELF file to make it work. I don't think you can infer from the ELF specification that static linking is undefined. -- Marcel Moolenaar USPA: A-39004 [EMAIL PROTECTED] ___ [EMAIL PROTECTED] mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to [EMAIL PROTECTED]
fork speed vs /bin/sh
I *know* I'm going to regret posting this, but if people care about
the speed of their shell, then perhaps you want to look at this:
[EMAIL PROTECTED]:46am]/tmp-149 cc -O -o vforkathon.dynamic vforkathon.c
[EMAIL PROTECTED]:46am]/tmp-150 cc -O -static -o vforkathon.static vforkathon.c
[EMAIL PROTECTED]:47am]/tmp-151 cc -O -static -o forkathon.static forkathon.c
[EMAIL PROTECTED]:47am]/tmp-152 cc -O -o forkathon.dynamic forkathon.c
[EMAIL PROTECTED]:47am]/tmp-153 time ./forkathon.dynamic
0.120u 17.192s 0:17.81 97.1%5+169k 0+0io 0pf+0w
[EMAIL PROTECTED]:47am]/tmp-154 time ./forkathon.static
0.051u 5.939s 0:06.38 93.7% 15+177k 0+0io 0pf+0w
[EMAIL PROTECTED]:47am]/tmp-155 time ./vforkathon.dynamic
0.015u 2.006s 0:02.30 87.3% 5+176k 0+0io 0pf+0w
[EMAIL PROTECTED]:48am]/tmp-156 time ./vforkathon.static
0.022u 2.020s 0:02.34 87.1% 16+182k 0+0io 0pf+0w
What this shows is that vfork() is 3 times faster than fork() on static
binaries, and 9 times faster on dynamic binaries. If people are
worried about a 40% slowdown, then perhaps they'd like to investigate
a speedup that works no matter whether its static or dynamic? There is
a reason that popen(3) uses vfork(). /bin/sh should too, regardless of
whether its dynamic or static. csh/tcsh already uses vfork() for the
same reason.
NetBSD have already taken advantage of this speedup and their /bin/sh uses
vfork(). Some enterprising individual who cares about /bin/sh speed should
check out that. Start looking near #ifdef DO_SHAREDVFORK.
In case anybody was wondering:
[EMAIL PROTECTED]:48am]/tmp-157 cat forkathon.c
#include sys/types.h
#include sys/signal.h
#include stdio.h
int
main(int ac, char *av[])
{
int i;
pid_t pid;
for (i = 0; i 10; i++) {
pid = fork();
switch (pid) {
case 0:
_exit(0);
default:
waitpid(pid, NULL, 0);
}
}
}
[EMAIL PROTECTED]:53am]/tmp-158 diff forkathon.c vforkathon.c
12c12
pid = fork();
---
pid = vfork();
Cheers,
-Peter
--
Peter Wemm - [EMAIL PROTECTED]; [EMAIL PROTECTED]; [EMAIL PROTECTED]
All of this is for nothing if we don't go to the stars - JMS/B5
___
[EMAIL PROTECTED] mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-current
To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: recent current panic
On Thursday 27 November 2003 06:38 am, Bjoern A. Zeeb wrote: On Thu, 27 Nov 2003, Yuriy Tsibizov wrote: Hi, i got a panic on recent -CURRENT: # tcpdump -i lo0 port 23 [1] 507 listening on lo0 # telnet localhost Trying ::1... Wed Nov 26 14:51:23 MSK 2003 Debugger+0x55: xchgl %ebx,in_Debugger.0 [] It looks very similar to http://www.freebsd.org/cgi/query-pr.cgi?pr=59576. You can revert to version 1.28 of net/bpf.h if you need tcpdump on lo, tun, ic, plip, disc or gif interface right now. just to note: I ran tcpdump on tunN (which was a pppoe interface) w/o problems two days ago (with a recent world) while debugging and testing other net related things. As was noted earlier, the issue is the addition of M_ASSERTVALID to the BPF_MTAP macro. This fails in numerous cases because existing practice was to allocate a fake mbuf on the stack for passing local data in to bpf. If this mbuf is not zero'd (or at least m_flags) then the assertion may trip. It's arguable what the correct solution is for these problems but you should be able to safely remove the assert until we can make a sweep over the drivers as the existing code has been around for a while (not to imply this makes it right :)). Sam ___ [EMAIL PROTECTED] mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: fork speed vs /bin/sh
:What this shows is that vfork() is 3 times faster than fork() on static
:binaries, and 9 times faster on dynamic binaries. If people are
:worried about a 40% slowdown, then perhaps they'd like to investigate
:a speedup that works no matter whether its static or dynamic? There is
:a reason that popen(3) uses vfork(). /bin/sh should too, regardless of
:whether its dynamic or static. csh/tcsh already uses vfork() for the
:same reason.
:
:NetBSD have already taken advantage of this speedup and their /bin/sh uses
:vfork(). Some enterprising individual who cares about /bin/sh speed should
:check out that. Start looking near #ifdef DO_SHAREDVFORK.
That isn't really a fair comparison because your vfork is hitting a
degenerate case and isn't actually doing anything significant. You
really need to exec() something. I've included a program below
that [v]fork/exec's ./sh -c exit 0 5000 times.
Dell2550, 2xCPU (MP build), DFly
0.000u 4.095s 0:02.53 161.6% 154+107k 0+0io 0pf+0w VFORK/EXEC STATIC SH
0.000u 6.681s 0:04.04 165.3% 94+97k 0+0io 0pf+0w FORK/EXEC STATIC SH
0.500u 16.844s 0:16.34 106.1% 53+84k 0+0io 0pf+0w VFORK/EXEC DYNAMIC SH
0.093u 18.303s 0:23.86 77.0%42+79k 0+0io 0pf+0w FORK/EXEC DYNAMIC SH
Athlon64, 2xCPU (UP), DFly
0.078u 0.687s 0:00.74 101.3%399+226k 0+0io 0pf+0w VFORK/EXEC STATIC SH
0.117u 0.968s 0:01.07 100.0%273+208k 0+0io 0pf+0w FORK/EXEC STATIC SH
2.218u 2.484s 0:04.71 99.5% 121+180k 0+0io 1pf+0w VFORK/EXEC DYNAMIC SH
2.281u 2.773s 0:04.98 101.4%113+179k 0+0io 0pf+0w FORK/EXEC DYNAMIC SH
1.304u 2.289s 0:03.60 99.4% 121+180k 0+0io 0pf+0w VFORK/EXEC DYNAMIC SH
WITH PREBINDING.
1.296u 2.648s 0:03.90 100.7%112+180k 0+0io 1pf+0w FORK/EXEC DYNAMIC SH
WITH PREBINDING.
These results were rather unexpected, actually. I'm not sure why the
numbers on the DELL box are so bad with a dynamic 'sh' but I suspect that
the dynamic linking is blowing out the L1 cache.
In anycase, taking the Athlon64 system the difference between static and
dynamic is around 4 seconds while the difference between vfork and fork
is only around 0.25 seconds, so while moving to vfork() helps it doesn't
help all that much.
Unless you happen to be hitting a boundary condition on the L1 cache,
that is. If that is presumably the case on the Dell box (which only
has a 16K L1 cache where as the AMD64 has a 64K L1 cache), then the
difference is around 14 seconds between vfork static and vfork dynamic
verses an additional 8 seconds going from vfork to fork. Vfork would
probably be a significant improvement on the DELL box.
Prebinding generates around a 20% overhead improvement for the dynamic 'sh'
on the Athlon64 but on the Dell2550 prebinding actually made things
go slower (not shown above), from 23.8 seconds to 26 seconds. I
think there is an edge case due to prebinding having a greater L1 cache
impact. For larger, more complex programs prebinding shows definite,
if small, improvements.
-Matt
/*
* CD into the directory containing the ./sh executable before running
*/
#include sys/types.h
#include stdio.h
#include unistd.h
main()
{
int i;
pid_t pid;
for (i = 0; i 5000; ++i) {
if ((pid = vfork()) == 0) { /* CHANGE THIS FORK/VFORK */
execl(./sh, ./sh, -c, exit, 0, NULL);
write(2, problem\n, 8);
_exit(1);
}
if (pid 0)
waitpid(pid, NULL, 0);
}
return(0);
}
___
[EMAIL PROTECTED] mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-current
To unsubscribe, send any mail to [EMAIL PROTECTED]
Turkeys and dynamic linking
To all of you who celebrate Thanksgiving today, I wish you a happy one! And speaking of turkeys, does anyone know how Microsoft handles the performance issues associated with dynamic linking? Do they do anything special, or just ignore the whole thing? ___ [EMAIL PROTECTED] mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: Turkeys and dynamic linking
On Thu, 2003-11-27 at 15:15, walt wrote: And speaking of turkeys, does anyone know how Microsoft handles the performance issues associated with dynamic linking? Do they do anything special, or just ignore the whole thing? My understanding is that they perform a special linking/postprocessing step which optimizes executables for fast runtime linking and loading. -- brandon s. allbery[linux,solaris,freebsd,perl] [EMAIL PROTECTED] system administrator [WAY too many hats][EMAIL PROTECTED] electrical and computer engineering, carnegie mellon univ. KF8NH ___ [EMAIL PROTECTED] mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: Turkeys and dynamic linking
walt wrote: To all of you who celebrate Thanksgiving today, I wish you a happy one! And speaking of turkeys, does anyone know how Microsoft handles the performance issues associated with dynamic linking? Do they do anything special, or just ignore the whole thing? Don't they fix the performance hit by moving performance-critical parts of the application into kernel space (such as IIS and MSSQL)? At least, that's what Eric Raymond claims in his latest book. I don't think that's an approach I would like to see FreeBSD take. -- Bill Moran Potential Technologies http://www.potentialtech.com ___ [EMAIL PROTECTED] mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: lock order reversal
On Tue, Nov 25, 2003 at 07:05:36PM -0600, John wrote: i was just looking through my daily reports from my new 5.2 beta box and found this in dmesg. lock order reversal 1st 0xc08f7ce0 UMA lock (UMA lock) @ /usr/src/sys/vm/uma_core.c:1201 2nd 0xc1031100 system map (system map) @ /usr/src/sys/vm/vm_map.c:2210 Here is the stack trace for the first one: lock order reversal 1st 0xc098e840 UMA lock (UMA lock) @ /usr/src/sys/vm/uma_core.c:1201 2nd 0xc1031100 system map (system map) @ /usr/src/sys/vm/vm_map.c:2210 Stack backtrace: backtrace(c089c5dc,c1031100,c08afe80,c08afe80,c08afef6) at backtrace+0x17 witness_lock(c1031100,8,c08afef6,8a2,c10310a0) at witness_lock+0x672 _mtx_lock_flags(c1031100,0,c08afef6,8a2,c55ae000) at _mtx_lock_flags+0xba _vm_map_lock(c10310a0,c08afef6,8a2,c5394bd0,0) at _vm_map_lock+0x36 vm_map_remove(c10310a0,c55ae000,c55af000,d77e5bf8,c07eacab) at vm_map_remove+0x30 kmem_free(c10310a0,c55ae000,1000,d77e5c28,c07ea6bf) at kmem_free+0x32 page_free(c55ae000,1000,2,0,c55ae000) at page_free+0x3b zone_drain(c101e000,0,c08b16a1,4b1,0) at zone_drain+0x2cf zone_foreach(c07ea3f0,d77e5cf0,c07e7b98,c08b154f,0) at zone_foreach+0x45 uma_reclaim(c08b154f,0,c08b14bc,29e,c095bf80) at uma_reclaim+0x17 vm_pageout_scan(0,0,c08b14bc,5a9,1f4) at vm_pageout_scan+0x148 vm_pageout(0,d77e5d48,c0896d18,311,0) at vm_pageout+0x31b fork_exit(c07e8990,0,d77e5d48) at fork_exit+0xb4 fork_trampoline() at fork_trampoline+0x8 --- trap 0x1, eip = 0, esp = 0xd77e5d7c, ebp = 0 --- pgp0.pgp Description: PGP signature
Anybody using gp driver?
I'm wondering if anybody is using, or even able to use, the gpib driver. It uses the old ISA shims, and is one of the drivers that no one has acked working in when I ask about the old isa shim drivers. So, I'm wondering if anybody is actually using the gp driver on a current machine (or even a 4.x stable machine) at all. It has been a long time since we've received reports of its working. I'd like to remove it from the tree if it isn't working at all or if no one is uing it. I'd also like to say that I'd love to see a good, and proper gpib framework in the tree, but it certainly won't be based on this driver! The questions here are only 'does this driver work?' and 'is anybody able to use it?' Warner ___ [EMAIL PROTECTED] mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: Frequent lockups with 5.2-BETA
On 27 Nov 2003, Christian Laursen wrote: Since upgrading from 5.1-RELEASE to 5.2-BETA, I've been experiencing hard lockups once or twice every day. I managed to get a trace by enabling the watchdog, which put me into the debugger. This is the trace: db trace Debugger(c06f85ec,1bc169d,0,c0754fc4,c0754bf8) at Debugger+0x54 watchdog_fire(d73e2bcc,c067b433,c0c57100,0,d73e2bcc) at watchdog_fire+0xc1 hardclock(d73e2bcc,0,0,d73e2b98,c43bd400) at hardclock+0x15a clkintr(d73e2bcc,d73e2b9c,c06c6bf6,0,c1925000) at clkintr+0xe9 intr_execute_handlers(c0756be0,d73e2bcc,c0c570a0,1000,c0c61300) at intr_execute8 atpic_handle_intr(0) at atpic_handle_intr+0xef Xatpic_intr0() at Xatpic_intr0+0x1e --- interrupt, eip = 0xc068db74, esp = 0xd73e2c10, ebp = 0xd73e2c14 --- uma_zone_slab(c0c61300,1,0,c068e516,c074edd8) at uma_zone_slab+0x4 uma_zalloc_internal(c0c61300,0,1,0,d73e2c80) at uma_zalloc_internal+0x5c bucket_alloc(2f,1,0,0,0) at bucket_alloc+0x65 uma_zfree_arg(c0c48240,c49121b8,0,c1922580,3600) at uma_zfree_arg+0x2c6 tcp_hc_purge(0,c1922580,161e9,142b64fd,c05d7c70) at tcp_hc_purge+0x11f Great debugging work. I'm glad to see the software watchdog put to use. This looks like a problem with the hostcache. Perhaps andre can look at it. Thanks, Jeff softclock(0,0,0,0,c192b54c) at softclock+0x25e ithread_loop(c1922580,d73e2d48,0,11,55ff44fd) at ithread_loop+0x1d8 fork_exit(c0524ec0,c1922580,d73e2d48) at fork_exit+0x80 fork_trampoline() at fork_trampoline+0x8 --- trap 0x1, eip = 0, esp = 0xd73e2d7c, ebp = 0 --- This is the dmesg from the last boot: Copyright (c) 1992-2003 The FreeBSD Project. Copyright (c) 1979, 1980, 1983, 1986, 1988, 1989, 1991, 1992, 1993, 1994 The Regents of the University of California. All rights reserved. FreeBSD 5.2-BETA #7: Wed Nov 26 17:24:32 CET 2003 [EMAIL PROTECTED]:/usr/obj/usr/src/sys/BORG Preloaded elf kernel /boot/kernel/kernel at 0xc0823000. Timecounter i8254 frequency 1193182 Hz quality 0 CPU: Intel(R) Celeron(R) CPU 1.70GHz (1716.04-MHz 686-class CPU) Origin = GenuineIntel Id = 0xf13 Stepping = 3 Features=0x3febfbffFPU,VME,DE,PSE,TSC,MSR,PAE,MCE,CX8,APIC,SEP,MTRR,PGE,MCA,CMOV,PAT,PSE36,CLFLUSH,DTS,ACPI,MMX,FXSR,SSE,SSE2,SS,HTT,TM real memory = 536805376 (511 MB) avail memory = 511885312 (488 MB) Pentium Pro MTRR support enabled acpi0: AMIINT INTEL845 on motherboard pcibios: BIOS version 2.10 Using $PIR table, 15 entries at 0xc00f7810 acpi0: Power Button (fixed) Timecounter ACPI-fast frequency 3579545 Hz quality 1000 acpi_timer0: 24-bit timer at 3.579545MHz port 0x808-0x80b on acpi0 acpi_cpu0: CPU port 0x530-0x537 on acpi0 acpi_cpu1: CPU port 0x530-0x537 on acpi0 device_probe_and_attach: acpi_cpu1 attach returned 6 acpi_button0: Power Button on acpi0 pcib0: ACPI Host-PCI bridge port 0xcf8-0xcff on acpi0 pci0: ACPI PCI bus on pcib0 agp0: Intel Generic host to PCI bridge mem 0xe000-0xe3ff at device 0.0 on pci0 pcib1: PCI-PCI bridge at device 1.0 on pci0 pci1: PCI bus on pcib1 pcib0: slot 1 INTA is routed to irq 5 pcib1: slot 0 INTA is routed to irq 5 pci1: display, VGA at device 0.0 (no driver attached) pcib2: ACPI PCI-PCI bridge at device 30.0 on pci0 pci2: ACPI PCI bus on pcib2 pcib2: slot 10 INTA is routed to irq 10 pcib2: slot 13 INTA is routed to irq 3 pcm0: CMedia CMI8738 port 0xdc00-0xdcff irq 10 at device 10.0 on pci2 em0: Intel(R) PRO/1000 Network Connection, Version - 1.7.19 port 0xd800-0xd83f mem 0xdfec-0xdfed,0xdfee-0xdfef irq 3 at device 13.0 on pci2 em0: Speed:N/A Duplex:N/A isab0: PCI-ISA bridge at device 31.0 on pci0 isa0: ISA bus on isab0 atapci0: Intel ICH4 UDMA100 controller port 0xfc00-0xfc0f,0-0x3,0-0x7,0-0x3,0-0x7 at device 31.1 on pci0 ata0: at 0x1f0 irq 14 on atapci0 ata0: [MPSAFE] ata1: at 0x170 irq 15 on atapci0 ata1: [MPSAFE] pci0: serial bus, SMBus at device 31.3 (no driver attached) atkbdc0: Keyboard controller (i8042) port 0x64,0x60 irq 1 on acpi0 atkbd0: AT Keyboard flags 0x1 irq 1 on atkbdc0 kbd0 at atkbd0 psm0: PS/2 Mouse irq 12 on atkbdc0 psm0: model MouseMan+, device ID 0 fdc0: cmd 3 failed at out byte 1 of 3 sio0 port 0x3f8-0x3ff irq 4 on acpi0 sio0: type 16550A, console ppc0 port 0x778-0x77b,0x378-0x37f irq 7 drq 3 on acpi0 ppc0: SMC-like chipset (ECP/EPP/PS2/NIBBLE) in COMPATIBLE mode ppc0: FIFO with 16/16/9 bytes threshold ppbus0: Parallel port bus on ppc0 plip0: PLIP network interface on ppbus0 lpt0: Printer on ppbus0 lpt0: Interrupt-driven port ppi0: Parallel I/O on ppbus0 acpi_cpu1: CPU port 0x530-0x537 on acpi0 device_probe_and_attach: acpi_cpu1 attach returned 6 fdc0: cmd 3 failed at out byte 1 of 3 npx0: [FAST] npx0: math processor on motherboard npx0: INT 16 interface orm0: Option ROM at iomem 0xe-0xe0fff on isa0 pmtimer0 on isa0 fdc0: cannot reserve I/O port range (6 ports) sc0: System console at flags 0x100 on isa0 sc0: VGA 16 virtual consoles, flags=0x100 sio1: configured irq 3 not in
Fix for 5.2-BETA lockup problems
Hello all,
I've found what probably is going wrong in tcp_hostcache. The problem is me
cutting corners (what goes around comes around...) in tcp_hc_insert when the
bucket limit is reached. I made the #if 0 too big and the bucket was not
removed from the tailqueue when we hit the bucket limit. A couple of lines
later it is inserted again as head element which leads to an infinite loop
either when the next lookup on the same bucket row is done, or when the
the tcp_hc_purge function is run to timeout the entries.
Please try the attached patch which should fix it.
--
Andre
Index: tcp_hostcache.c
===
RCS file: /home/ncvs/src/sys/netinet/tcp_hostcache.c,v
retrieving revision 1.1
diff -u -p -r1.1 tcp_hostcache.c
--- tcp_hostcache.c 20 Nov 2003 20:07:38 - 1.1
+++ tcp_hostcache.c 27 Nov 2003 20:23:06 -
@@ -354,11 +354,11 @@ tcp_hc_insert(struct in_conninfo *inc)
* maybe we drop something that is still in-use but we can
* be lossy.
*/
-#if 0
TAILQ_REMOVE(hc_head-hch_bucket, hc_entry, rmx_q);
- uma_zfree(tcp_hostcache.zone, hc_entry);
tcp_hostcache.hashbase[hash].hch_length--;
tcp_hostcache.cache_count--;
+#if 0
+ uma_zfree(tcp_hostcache.zone, hc_entry);
#endif
tcpstat.tcps_hc_bucketoverflow++;
} else {
___
[EMAIL PROTECTED] mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-current
To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: Turkeys and dynamic linking
On Thursday 27 November 2003 12:31 pm, Bill Moran wrote: walt wrote: To all of you who celebrate Thanksgiving today, I wish you a happy one! And speaking of turkeys, does anyone know how Microsoft handles the performance issues associated with dynamic linking? Do they do anything special, or just ignore the whole thing? Don't they fix the performance hit by moving performance-critical parts of the application into kernel space (such as IIS and MSSQL)? At least, that's what Eric Raymond claims in his latest book. I don't think that's an approach I would like to see FreeBSD take. It all depends because if you only have 1 dll loaded for multiple applications, which is one of the features I understand is built into Windows, you have real savings. You share the code and own the data. Kent -- Kent Stewart Richland, WA http://users.owt.com/kstewart/index.html ___ [EMAIL PROTECTED] mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to [EMAIL PROTECTED]
LOR w/5.2-BETA
I got this LOR today after upgrading my IBM Thinkpad A30p from 5.1-RELEASE to 5.2-BETA: lock order reversal 1st 0xc43d8ad4 vm object (vm object) @ /usr/src/sys/vm/swap_pager.c:1323 2nd 0xc098cf60 swap_pager swhash (swap_pager swhash) @ /usr/src/sys/vm/swap_pag er.c:1838 3rd 0xc10368c4 vm object (vm object) @ /usr/src/sys/vm/uma_core.c:876 Stack backtrace: backtrace(c089b8b5,c10368c4,c08afa80,c08afa80,c08b0961) at backtrace+0x17 witness_lock(c10368c4,8,c08b0961,36c,c3c7da80) at witness_lock+0x672 _mtx_lock_flags(c10368c4,0,c08b0961,36c,c3c7da94) at _mtx_lock_flags+0xba obj_alloc(c3c7da80,1000,d2a6ba03,101,c095b220) at obj_alloc+0x3f slab_zalloc(c3c7da80,1,8,c08b0961,68c) at slab_zalloc+0xb3 uma_zone_slab(c3c7da80,1,c08b0961,68c,c3c7db20) at uma_zone_slab+0xd6 uma_zalloc_internal(c3c7da80,0,1,5c1,c08ae87a,72e) at uma_zalloc_internal+0x3e uma_zalloc_arg(c3c7da80,0,1,72e,2) at uma_zalloc_arg+0x3ab swp_pager_meta_build(c43d8ad4,19,0,2,0) at swp_pager_meta_build+0x174 swap_pager_putpages(c43d8ad4,d2a6bbd0,1,0,d2a6bb40) at swap_pager_putpages+0x32d default_pager_putpages(c43d8ad4,d2a6bbd0,1,0,d2a6bb40) at default_pager_putpages +0x2e vm_pageout_flush(d2a6bbd0,1,0,eb,0) at vm_pageout_flush+0x17a vm_pageout_clean(c160b7a8,0,c08b077c,32a,0) at vm_pageout_clean+0x305 vm_pageout_scan(0,0,c08b077c,5a9,1f4) at vm_pageout_scan+0x64c vm_pageout(0,d2a6bd48,c0895fd8,311,0) at vm_pageout+0x31b fork_exit(c07e7e60,0,d2a6bd48) at fork_exit+0xb4 fork_trampoline() at fork_trampoline+0x8 --- trap 0x1, eip = 0, esp = 0xd2a6bd7c, ebp = 0 --- -- Jesse Guardiani, Systems Administrator WingNET Internet Services, P.O. Box 2605 // Cleveland, TN 37320-2605 423-559-LINK (v) 423-559-5145 (f) http://www.wingnet.net ___ [EMAIL PROTECTED] mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: requesting vinum help
In message: [EMAIL PROTECTED]
Terry Lambert [EMAIL PROTECTED] writes:
: There is no such thing as bit rot; there is only code that
: is unmaintained by the people who change interfaces out from
: under it.
Actually, there is such a thing as code rot. Over time the
fundamental assumptions that a piece of code makes are tested as the
interfaces and subsystems it depends on evolve and change. These
assumptions can be very subtle sometimes, and difficult to find and
test.
Vinum is hard to test because it requires multiple disks to test
with. In addition, many problems with vinum are shown only under
heavy work load, which may be difficult to simulate.
Put in historical terms, the following code used to work:
void foo(char *c)
{
*c = 'F';
}
int
main(int argc, char **argv)
{
foo(fred);
}
but subtle changes in compiler technology over the years have made
this code fail now.
Warner
___
[EMAIL PROTECTED] mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-current
To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: 5.2-BETA: giving up on 4 buffers (ata)
On Thursday 27 November 2003 10:43, Stefan Ehmann wrote: On Wed, 2003-11-26 at 19:37, Matthias Andree wrote: Hi, when I rebooted my 5.2-BETA (kernel about 24 hours old), it gave up on flushing 4 dirty blocks. I had three UFS1 softdep file systems mounted on one ATA drive, one ext2 file system on another ATA drive and one ext2 file system on a SCSI drive. Both ext2 file systems had been mounted read-only, so they can't have had dirty blocks. This is a known problem for nearly three months now (See PR 56675). It happens to me every time I shut down the system if i don't unmount my (read-only) ext2 file systems manually. I have this same problem, but I only have ufs1 partitions, all mounted r/w. It seemed to appear about 3 weeks ago, so there has to be a commit in this timeframe that caused it. An extra inconvenience is that I always lose one or two files when I shutdown due to ATA write caching - if I turn it off, I don't lose files, but my system is too slow. Doing a manual 'sync' before shutting down seems to help. Arjan pgp0.pgp Description: signature
Re: please test pcm patch
Mathew Kanner [EMAIL PROTECTED] wrote: Hello All, Please test a pcm patch that releases the channel lock around calls to uio move. This is a more complete patch than the previous one as it also does the _read routine. I will ask the RE to commit this if I hear a couple of it works. It works. ;-) Artur ___ [EMAIL PROTECTED] mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: FreeBSD 5.2-BETA: GEOM/CDROM Related Panic
V t, 27. 11. 2003 v 11:37, Shanker Balan pe:
Shanker Balan wrote,
Can provide more information if required. Kernel has been compiled
with device atapicam. I am rebuilding the kernel w/o atapicam ATM.
Kernel w/o atapicam also panics at the same spot.
#11 0xc0785d08 in calltrap () at {standard input}:94
#12 0xc05784a8 in g_destroy_provider (pp=0xc2e5bf00)
at /usr/src/sys/geom/geom_subr.c:426
#13 0xc057560d in g_orphan_register (pp=0xc2e6c180)
at /usr/src/sys/geom/geom_event.c:143
#14 0xc057571c in one_event () at /usr/src/sys/geom/geom_event.c:169
#15 0xc0575938 in g_run_events () at /usr/src/sys/geom/geom_event.c:202
#16 0xc05768c5 in g_event_procbody () at /usr/src/sys/geom/geom_kern.c:134
Me too. In fact it started happening since geomification of atapicd
driver. My workaround is to detach and attach ATA channel with a cd-rom
drive.
--
Pav Lucistnik [EMAIL PROTECTED]
[EMAIL PROTECTED]
signature.asc
Description: Toto je =?iso-8859-2?Q?digit=E1ln=EC?= =?ISO-8859-1?Q?_podepsan=E1?= =?iso-8859-2?Q?_=E8=E1st?= =?ISO-8859-1?Q?_zpr=E1vy?=
Re: LOR w/5.2-BETA
On Thu, 27 Nov 2003 18:01:39 -0500 Jesse Guardiani [EMAIL PROTECTED] wrote: I got this LOR today after upgrading my IBM Thinkpad A30p from 5.1-RELEASE to 5.2-BETA: lock order reversal 1st 0xc43d8ad4 vm object (vm object) @ /usr/src/sys/vm/swap_pager.c:1323 2nd 0xc098cf60 swap_pager swhash (swap_pager swhash) @ /usr/src/sys/vm/swap_pag er.c:1838 3rd 0xc10368c4 vm object (vm object) @ /usr/src/sys/vm/uma_core.c:876 Stack backtrace: backtrace(c089b8b5,c10368c4,c08afa80,c08afa80,c08b0961) at backtrace+0x17 witness_lock(c10368c4,8,c08b0961,36c,c3c7da80) at witness_lock+0x672 _mtx_lock_flags(c10368c4,0,c08b0961,36c,c3c7da94) at _mtx_lock_flags+0xba obj_alloc(c3c7da80,1000,d2a6ba03,101,c095b220) at obj_alloc+0x3f slab_zalloc(c3c7da80,1,8,c08b0961,68c) at slab_zalloc+0xb3 uma_zone_slab(c3c7da80,1,c08b0961,68c,c3c7db20) at uma_zone_slab+0xd6 uma_zalloc_internal(c3c7da80,0,1,5c1,c08ae87a,72e) at uma_zalloc_internal+0x3e uma_zalloc_arg(c3c7da80,0,1,72e,2) at uma_zalloc_arg+0x3ab swp_pager_meta_build(c43d8ad4,19,0,2,0) at swp_pager_meta_build+0x174 swap_pager_putpages(c43d8ad4,d2a6bbd0,1,0,d2a6bb40) at swap_pager_putpages+0x32d default_pager_putpages(c43d8ad4,d2a6bbd0,1,0,d2a6bb40) at default_pager_putpages +0x2e vm_pageout_flush(d2a6bbd0,1,0,eb,0) at vm_pageout_flush+0x17a vm_pageout_clean(c160b7a8,0,c08b077c,32a,0) at vm_pageout_clean+0x305 vm_pageout_scan(0,0,c08b077c,5a9,1f4) at vm_pageout_scan+0x64c vm_pageout(0,d2a6bd48,c0895fd8,311,0) at vm_pageout+0x31b fork_exit(c07e7e60,0,d2a6bd48) at fork_exit+0xb4 fork_trampoline() at fork_trampoline+0x8 --- trap 0x1, eip = 0, esp = 0xd2a6bd7c, ebp = 0 --- Exactly the same thing here: lock order reversal 1st 0xc0c1f738 vm object (vm object) @ /usr/src/sys/vm/swap_pager.c:1323 2nd 0xc06c06a0 swap_pager swhash (swap_pager swhash) @ /usr/src/sys/vm/swap_pag er.c:1838 3rd 0xc0c358c4 vm object (vm object) @ /usr/src/sys/vm/uma_core.c:876 Stack backtrace: backtrace(c0632e21,c0c358c4,c063ff1c,c063ff1c,c0640dfd) at backtrace+0x17 witness_lock(c0c358c4,8,c0640dfd,36c,c0c223c0) at witness_lock+0x671 _mtx_lock_flags(c0c358c4,0,c0640dfd,36c,c0c223d4) at _mtx_lock_flags+0xb1 obj_alloc(c0c223c0,1000,c8daba0b,101,0) at obj_alloc+0x3f slab_zalloc(c0c223c0,1,c0c223d4,8,c0640dfd) at slab_zalloc+0xb1 uma_zone_slab(c0c223c0,1,c0640dfd,68c,c0c22460) at uma_zone_slab+0xd3 uma_zalloc_internal(c0c223c0,0,1,5c1,72e) at uma_zalloc_internal+0x3e uma_zalloc_arg(c0c223c0,0,1,72e,2) at uma_zalloc_arg+0x39e swp_pager_meta_build(c0c1f738,0,0,2,0) at swp_pager_meta_build+0x174 swap_pager_putpages(c0c1f738,c8dabbd0,1,0,c8dabb40) at swap_pager_putpages+0x31d default_pager_putpages(c0c1f738,c8dabbd0,1,0,c8dabb40) at default_pager_putpages +0x2e vm_pageout_flush(c8dabbd0,1,0,eb,60a) at vm_pageout_flush+0x171 vm_pageout_clean(c0dbabf0,0,c0640c18,32a,0) at vm_pageout_clean+0x2f5 vm_pageout_scan(1,0,c0640c18,5a9,1f4) at vm_pageout_scan+0x655 vm_pageout(0,c8dabd48,c062d6bf,311,0) at vm_pageout+0x318 fork_exit(c05cab80,0,c8dabd48) at fork_exit+0xb4 fork_trampoline() at fork_trampoline+0x8 --- trap 0x1, eip = 0, esp = 0xc8dabd7c, ebp = 0 --- And another one, always showing up at the end of booting process: lock order reversal 1st 0xc205a764 rtentry (rtentry) @ /usr/src/sys/net/rtsock.c:387 2nd 0xc1c5d47c radix node head (radix node head) @ /usr/src/sys/net/route.c:133 Stack backtrace: backtrace(c0632e08,c1c5d47c,c063873b,c063873b,c0638791) at backtrace+0x17 witness_lock(c1c5d47c,8,c0638791,85,c1c4ea20) at witness_lock+0x671 _mtx_lock_flags(c1c5d47c,0,c0638791,85,121) at _mtx_lock_flags+0xb1 rtalloc1(c2073e6c,1,0,436,0) at rtalloc1+0x72 rt_setgate(c205a700,c1c4ea20,c2073e6c,184,0) at rt_setgate+0x24c route_output(c0fb9600,c1d5c690,7c,c0fb9600,1f84) at route_output+0x664 raw_usend(c1d5c690,0,c0fb9600,0,0) at raw_usend+0x73 rts_send(c1d5c690,0,c0fb9600,0,0) at rts_send+0x35 sosend(c1d5c690,0,c8dd9c80,c0fb9600,0) at sosend+0x41d soo_write(c1ce150c,c8dd9c80,c2073e80,0,c0fad3c0) at soo_write+0x70 dofilewrite(c0fad3c0,c1ce150c,3,bfbfde10,7c) at dofilewrite+0xec write(c0fad3c0,c8dd9d14,c0644e02,3ee,3) at write+0x6e syscall(2f,2f,2f,3,3) at syscall+0x292 Xint0x80_syscall() at Xint0x80_syscall+0x1d --- syscall (4), eip = 0x2827e6cf, esp = 0xbfbfddcc, ebp = 0xbfbfddf8 --- Artur ___ [EMAIL PROTECTED] mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: LOR w/5.2-BETA
On Fri, Nov 28, 2003 at 12:27:53AM +0100, Artur Poplawski wrote: lock order reversal 1st 0xc43d8ad4 vm object (vm object) @ /usr/src/sys/vm/swap_pager.c:1323 2nd 0xc098cf60 swap_pager swhash (swap_pager swhash) @ /usr/src/sys/vm/swap_pag er.c:1838 3rd 0xc10368c4 vm object (vm object) @ /usr/src/sys/vm/uma_core.c:876 This is reported every couple of days, and remains just as harmless as ever ;-) And another one, always showing up at the end of booting process: lock order reversal 1st 0xc205a764 rtentry (rtentry) @ /usr/src/sys/net/rtsock.c:387 2nd 0xc1c5d47c radix node head (radix node head) @ /usr/src/sys/net/route.c:133 Not sure about this one. I think there are still some LORs expected in the network stack because of locking work in progress there. Kris pgp0.pgp Description: PGP signature
Re: panic on 5.2 BETA: blockable sleep lock
On 27 Nov, Stefan Ehmann wrote:
On Wed, 2003-11-26 at 08:33, Don Lewis wrote:
The problem is that selrecord() wants to lock a MTX_DEF mutex, which can
cause a context switch if the mutex is already locked by another thread.
This is contrary to what bktr_poll() wants to accomplish by calling
critical_enter().
Strange enough that does not seem to happen with a kernel built without
INVARIANTS and WITNESS. Does this make any sense or is this just by
chance?
You might try the patch below with WITNESS enabled. I don't have the
hardware, so I can't test it. It compiles for me, but for all I know it
could delete all your files if you run it.
Index: sys/dev/bktr/bktr_core.c
===
RCS file: /home/ncvs/src/sys/dev/bktr/bktr_core.c,v
retrieving revision 1.131
diff -u -r1.131 bktr_core.c
--- sys/dev/bktr/bktr_core.c9 Nov 2003 09:17:21 - 1.131
+++ sys/dev/bktr/bktr_core.c27 Nov 2003 23:58:19 -
@@ -526,6 +526,9 @@
}
#endif /* FreeBSD or BSDi */
+#ifdef USE_VBIMUTEX
+ mtx_init(bktr-vbimutex, bktr vbi lock, NULL, MTX_DEF);
+#endif
/* If this is a module, save the current contiguous memory */
#if defined(BKTR_FREEBSD_MODULE)
@@ -807,6 +810,7 @@
* both Odd and Even VBI data is captured. Therefore we do this
* in the Even field interrupt handler.
*/
+ LOCK_VBI(bktr);
if ( (bktr-vbiflags VBI_CAPTURE)
(bktr-vbiflags VBI_OPEN)
(field==EVEN_F)) {
@@ -826,6 +830,7 @@
}
+ UNLOCK_VBI(bktr);
/*
* Register the completed field
@@ -1066,8 +1071,13 @@
int
vbi_open( bktr_ptr_t bktr )
{
- if (bktr-vbiflags VBI_OPEN) /* device is busy */
+
+ LOCK_VBI(bktr);
+
+ if (bktr-vbiflags VBI_OPEN) {/* device is busy */
+ UNLOCK_VBI(bktr);
return( EBUSY );
+ }
bktr-vbiflags |= VBI_OPEN;
@@ -1081,6 +1091,8 @@
bzero((caddr_t) bktr-vbibuffer, VBI_BUFFER_SIZE);
bzero((caddr_t) bktr-vbidata, VBI_DATA_SIZE);
+ UNLOCK_VBI(bktr);
+
return( 0 );
}
@@ -1166,8 +1178,12 @@
vbi_close( bktr_ptr_t bktr )
{
+ LOCK_VBI(bktr);
+
bktr-vbiflags = ~VBI_OPEN;
+ UNLOCK_VBI(bktr);
+
return( 0 );
}
@@ -1232,19 +1248,32 @@
int
vbi_read(bktr_ptr_t bktr, struct uio *uio, int ioflag)
{
- int readsize, readsize2;
+ int readsize, readsize2, start;
int status;
+ /*
+* XXX - vbi_read() should be protected against being re-entered
+* while it is unlocked for the uiomove.
+*/
+ LOCK_VBI(bktr);
while(bktr-vbisize == 0) {
if (ioflag IO_NDELAY) {
- return EWOULDBLOCK;
+ status = EWOULDBLOCK;
+ goto out;
}
bktr-vbi_read_blocked = TRUE;
+#ifdef USE_VBIMUTEX
+ if ((status = msleep(VBI_SLEEP, bktr-vbimutex, VBIPRI, vbi,
+ 0))) {
+ goto out;
+ }
+#else
if ((status = tsleep(VBI_SLEEP, VBIPRI, vbi, 0))) {
- return status;
+ goto out;
}
+#endif
}
/* Now we have some data to give to the user */
@@ -1262,19 +1291,28 @@
/* We need to wrap around */
readsize2 = VBI_BUFFER_SIZE - bktr-vbistart;
- status = uiomove((caddr_t)bktr-vbibuffer + bktr-vbistart,
readsize2, uio);
- status += uiomove((caddr_t)bktr-vbibuffer, (readsize - readsize2),
uio);
+ start = bktr-vbistart;
+ UNLOCK_VBI(bktr);
+ status = uiomove((caddr_t)bktr-vbibuffer + start, readsize2,
uio);
+ if (status == 0)
+ status = uiomove((caddr_t)bktr-vbibuffer, (readsize -
readsize2), uio);
} else {
+ UNLOCK_VBI(bktr);
/* We do not need to wrap around */
status = uiomove((caddr_t)bktr-vbibuffer + bktr-vbistart, readsize,
uio);
}
+ LOCK_VBI(bktr);
+
/* Update the number of bytes left to read */
bktr-vbisize -= readsize;
/* Update vbistart */
bktr-vbistart += readsize;
bktr-vbistart = bktr-vbistart % VBI_BUFFER_SIZE; /* wrap around if needed */
+
+out:
+ UNLOCK_VBI(bktr);
return( status );
Index: sys/dev/bktr/bktr_os.c
===
RCS file: /home/ncvs/src/sys/dev/bktr/bktr_os.c,v
retrieving revision 1.39
diff -u -r1.39 bktr_os.c
--- sys/dev/bktr/bktr_os.c 2 Sep 2003 17:30:34 - 1.39
+++ sys/dev/bktr/bktr_os.c 27 Nov 2003 23:49:39 -
@@ -499,6 +499,9 @@
printf(bktr%d: i2c_attach: can't attach\n,
lock order reversal is 5.2-BETA Nov 26
It did not crash or anything, but the following is printed on console now (addresses ommitted): lock order reversal 1st ... UMA lock (UMA lock) @ /usr/src/sys/vm/uma_core.c:1201 2nd ... system map (system map) @ /usr/src/sys/vm/vm_map.c:2210 Stack backtrace: backtrace() at backtrace+0x17 witness_lock() at wintess_lock+0x672 _mtx_lock_flags() at _mtx_lock_flags+0xba _vm_map_lock() at _vm_map_lock+0x36 vm_map_remove() at vm_map_remove+0x30 kmem_free() at kmem_free+0x32 page_free() at page_free+0x3b zone_drain() at zone_drain+0x2cf zone_foreach() at zone_foreach+0x45 uma_reclaim() at uma_reclaim+0x17 vm_pageout_scan() at vm_pageout_scan+0x148 vm_pageout() at vm_pageout+0x31b fork_exit() at fork_exit+0xb4 fork_trampoline() at fork_trampoline+0x8 --- trap 0x1, eip = 0, esp = ., ebp = 0 --- Hope, this is usefull. A new kernel -- from today's sources -- is being compiled now. -mi ___ [EMAIL PROTECTED] mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: boot process is too slow during installation
At Thu, 27 Nov 2003 09:49:04 + (UTC), Zhang Shu wrote: I am trying to install the current-FreeBSD to my Vaio PCG-Z1/P but found the installation boot process is extremely slow. It takes more than 10 minutes to finish loading the disk created from kern.flp and another 10 minutes for mfsroot.flp. Does anyone know what the problem is? The USB floppy drive I am using is sony's PCGA-UF05. The same thing happens with another USB floppy drive which I don't remember the model. I also tried to boot the installation disks of 4.8R, 4.9R and 5.1R but the result were the same. I haven't seen fast USB floppy drive. So I think all of USB floppy drive may be too slow... -- Jun Kuriyama [EMAIL PROTECTED] // IMG SRC, Inc. [EMAIL PROTECTED] // FreeBSD Project ___ [EMAIL PROTECTED] mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to [EMAIL PROTECTED]
5.2-BETA dsp.c duplicate lock
I get this every time I `startx`. I didn't see it in the archive either: acquiring duplicate lock of same type: pcm channel 1st pcm0:record:0 @ /usr/src/sys/dev/sound/pcm/dsp.c:144 2nd pcm0:virtual:0 @ /usr/src/sys/dev/sound/pcm/dsp.c:146 Stack backtrace: backtrace(c089b7e5,c3c96a54,c0a8f35a,92,200246) at backtrace+0x17 witness_lock(c3c6aa80,8,c0a8f35a,92,2002) at witness_lock+0x672 _mtx_lock_flags(c3c6aa80,0,c0a8f35a,92,c4) at _mtx_lock_flags+0xba getchns(c3d07700,e473faf0,e473faf4,3000,c3b86980) at getchns+0x1b5 dsp_poll(c3d07700,c4,c403e640,c097fce0,0) at dsp_poll+0x46 spec_poll(e473fb48,e473fb68,c06d600c,e473fb48,c0937ca0) at spec_poll+0x180 spec_vnoperate(e473fb48,c0937ca0,c438db2c,c4,c4361a80) at spec_vnoperate+0x18 vn_poll(c4599110,c4,c4361a80,c403e640,c4361a80) at vn_poll+0x3c pollscan(c403e640,e473fbd8,3,3e1,18) at pollscan+0xb3 poll(c403e640,e473fd14,c08b631d,3ee,3) at poll+0x252 syscall(2f,2f,2f,,bfbfe748) at syscall+0x2c0 Xint0x80_syscall() at Xint0x80_syscall+0x1d --- syscall (209), eip = 0x2869322f, esp = 0xbfbfe70c, ebp = 0xbfbfe768 --- -- Jesse Guardiani, Systems Administrator WingNET Internet Services, P.O. Box 2605 // Cleveland, TN 37320-2605 423-559-LINK (v) 423-559-5145 (f) http://www.wingnet.net ___ [EMAIL PROTECTED] mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: boot process is too slow during installation
Kuriyama-san, When I install netbsd with the same floppy drive, it turns to be pretty fast. So I guess this is a FreeBSD problem but do not know where it is... On Fri, 28 Nov 2003 10:03:40 +0900 Jun Kuriyama [EMAIL PROTECTED] wrote: At Thu, 27 Nov 2003 09:49:04 + (UTC), Zhang Shu wrote: I am trying to install the current-FreeBSD to my Vaio PCG-Z1/P but found the installation boot process is extremely slow. It takes more than 10 minutes to finish loading the disk created from kern.flp and another 10 minutes for mfsroot.flp. Does anyone know what the problem is? The USB floppy drive I am using is sony's PCGA-UF05. The same thing happens with another USB floppy drive which I don't remember the model. I also tried to boot the installation disks of 4.8R, 4.9R and 5.1R but the result were the same. I haven't seen fast USB floppy drive. So I think all of USB floppy drive may be too slow... -- Jun Kuriyama [EMAIL PROTECTED] // IMG SRC, Inc. [EMAIL PROTECTED] // FreeBSD Project ___ [EMAIL PROTECTED] mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: Fix for 5.2-BETA lockup problems
In message: [EMAIL PROTECTED] Andre Oppermann [EMAIL PROTECTED] writes: : Please try the attached patch which should fix it. I've been having crashes all the time since the hostcache went into the tree. I've been running a few hours with this patch (in which time I should have had a crash). I think it makes it better. Warner ___ [EMAIL PROTECTED] mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: USB 1.0 IDE to ATAPI drive enclosure failure
Jesse Guardiani wrote: This is interesting: [17:[EMAIL PROTECTED]:[~]# camcontrol devlist USB 2.0 Storage Device 0100 at scbus1 target 0 lun 0 (da0,pass0) [17:[EMAIL PROTECTED]:[~]# camcontrol inquiry 1:0:0 pass0: USB 2.0 Storage Device 0100 Fixed Direct Access SCSI-0 device pass0: Serial Number pass0: 1.000MB/s transfers So it looks like it's just not recognizing the file system on da0. Perhaps I should try `camcontrol format`? It would probably take for ever to format a 32Gb disk over a 1M link, but I could leave it on over night... I originally formatted this disk by putting it in my primary drive sled in my laptop and running a partitioning program... I just upgraded to FreeBSD 5.2-BETA and this drive works now! Apparently something in the umass driver has changed for the better since 5.1-RELEASE and 4.8-RELEASE (the systems I tested the drive on that didn't work). Woo hoo! -- Jesse Guardiani, Systems Administrator WingNET Internet Services, P.O. Box 2605 // Cleveland, TN 37320-2605 423-559-LINK (v) 423-559-5145 (f) http://www.wingnet.net ___ [EMAIL PROTECTED] mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to [EMAIL PROTECTED]
ath driver not working...
According the the man-page, this is not supposed to happen: ath0: Atheros 5212 mem 0xe020-0xe020 irq 9 at device 11.0 on pci2 ath0: cannot map register space The machine is Sony Vaio TR2/B. The WiFi works fine from Windows (much better than the Orinoco card in another laptop). -mi ___ [EMAIL PROTECTED] mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: lock order reversal is 5.2-BETA Nov 26
On Thu, Nov 27, 2003 at 07:16:05PM -0500, Mikhail Teterin wrote: It did not crash or anything, but the following is printed on console now (addresses ommitted): lock order reversal 1st ... UMA lock (UMA lock) @ /usr/src/sys/vm/uma_core.c:1201 2nd ... system map (system map) @ /usr/src/sys/vm/vm_map.c:2210 Thanks, this was reported several times already. How about this one? lock order reversal 1st 0xc37abad4 vm object (vm object) @ /usr/src/sys/vm/swap_pager.c:1323 2nd 0xc098d020 swap_pager swhash (swap_pager swhash) @ /usr/src/sys/vm/swap_pager.c:1838 3rd 0xc1036948 vm object (vm object) @ /usr/src/sys/vm/uma_core.c:876 Sorry, backtrace was not logged, so I can not recreate it. -mi ___ [EMAIL PROTECTED] mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to [EMAIL PROTECTED]
[patch] mtx_init() API violations
It's a good thing that the value of MTX_DEF is 0 ;-)
This isn't a critical fix, but it probably should be done soon after the
code freeze is lifted to prevent the spread if infection via cut and
paste programming.
Index: dev/ata/ata-all.c
===
RCS file: /home/ncvs/src/sys/dev/ata/ata-all.c,v
retrieving revision 1.197
diff -u -r1.197 ata-all.c
--- dev/ata/ata-all.c 11 Nov 2003 14:55:35 - 1.197
+++ dev/ata/ata-all.c 28 Nov 2003 01:34:26 -
@@ -120,7 +120,7 @@
ch-dev = dev;
ch-state = ATA_IDLE;
bzero(ch-queue_mtx, sizeof(struct mtx));
-mtx_init(ch-queue_mtx, ATA queue lock, MTX_DEF, 0);
+mtx_init(ch-queue_mtx, ATA queue lock, NULL, MTX_DEF);
TAILQ_INIT(ch-ata_queue);
/* initialise device(s) on this channel */
Index: dev/ata/ata-disk.c
===
RCS file: /home/ncvs/src/sys/dev/ata/ata-disk.c,v
retrieving revision 1.164
diff -u -r1.164 ata-disk.c
--- dev/ata/ata-disk.c 11 Nov 2003 14:55:35 - 1.164
+++ dev/ata/ata-disk.c 28 Nov 2003 01:35:05 -
@@ -94,7 +94,7 @@
adp-sectors = 17;
adp-heads = 8;
}
-mtx_init(adp-queue_mtx, ATA disk bioqueue lock, MTX_DEF, 0);
+mtx_init(adp-queue_mtx, ATA disk bioqueue lock, NULL, MTX_DEF);
bioq_init(adp-queue);
lbasize = (u_int32_t)atadev-param-lba_size_1 |
Index: dev/ata/atapi-cd.c
===
RCS file: /home/ncvs/src/sys/dev/ata/atapi-cd.c,v
retrieving revision 1.156
diff -u -r1.156 atapi-cd.c
--- dev/ata/atapi-cd.c 24 Nov 2003 14:20:19 - 1.156
+++ dev/ata/atapi-cd.c 28 Nov 2003 01:35:18 -
@@ -222,7 +222,7 @@
if (!(cdp = malloc(sizeof(struct acd_softc), M_ACD, M_NOWAIT | M_ZERO)))
return NULL;
bioq_init(cdp-queue);
-mtx_init(cdp-queue_mtx, ATAPI CD bioqueue lock, MTX_DEF, 0);
+mtx_init(cdp-queue_mtx, ATAPI CD bioqueue lock, NULL, MTX_DEF);
cdp-device = atadev;
cdp-lun = ata_get_lun(acd_lun_map);
cdp-block_size = 2048;
Index: dev/ata/atapi-fd.c
===
RCS file: /home/ncvs/src/sys/dev/ata/atapi-fd.c,v
retrieving revision 1.89
diff -u -r1.89 atapi-fd.c
--- dev/ata/atapi-fd.c 11 Nov 2003 14:55:35 - 1.89
+++ dev/ata/atapi-fd.c 28 Nov 2003 01:35:28 -
@@ -80,7 +80,7 @@
fdp-lun = ata_get_lun(afd_lun_map);
ata_set_name(atadev, afd, fdp-lun);
bioq_init(fdp-queue);
-mtx_init(fdp-queue_mtx, ATAPI FD bioqueue lock, MTX_DEF, 0);
+mtx_init(fdp-queue_mtx, ATAPI FD bioqueue lock, NULL, MTX_DEF);
if (afd_sense(fdp)) {
free(fdp, M_AFD);
Index: dev/ata/atapi-tape.c
===
RCS file: /home/ncvs/src/sys/dev/ata/atapi-tape.c,v
retrieving revision 1.84
diff -u -r1.84 atapi-tape.c
--- dev/ata/atapi-tape.c11 Nov 2003 14:55:36 - 1.84
+++ dev/ata/atapi-tape.c28 Nov 2003 01:35:46 -
@@ -103,7 +103,7 @@
stp-lun = ata_get_lun(ast_lun_map);
ata_set_name(atadev, ast, stp-lun);
bioq_init(stp-queue);
-mtx_init(stp-queue_mtx, ATAPI TAPE bioqueue lock, MTX_DEF, 0);
+mtx_init(stp-queue_mtx, ATAPI TAPE bioqueue lock, NULL, MTX_DEF);
if (ast_sense(stp)) {
free(stp, M_AST);
Index: dev/led/led.c
===
RCS file: /home/ncvs/src/sys/dev/led/led.c,v
retrieving revision 1.3
diff -u -r1.3 led.c
--- dev/led/led.c 23 Nov 2003 10:22:51 - 1.3
+++ dev/led/led.c 28 Nov 2003 01:35:59 -
@@ -216,7 +216,7 @@
struct sbuf *sb;
if (next_minor == 0) {
- mtx_init(led_mtx, LED mtx, MTX_DEF, 0);
+ mtx_init(led_mtx, LED mtx, NULL, MTX_DEF);
timeout(led_timeout, NULL, hz / 10);
}
Index: dev/pst/pst-pci.c
===
RCS file: /home/ncvs/src/sys/dev/pst/pst-pci.c,v
retrieving revision 1.5
diff -u -r1.5 pst-pci.c
--- dev/pst/pst-pci.c 24 Aug 2003 17:54:17 - 1.5
+++ dev/pst/pst-pci.c 28 Nov 2003 01:36:09 -
@@ -96,7 +96,7 @@
sc-phys_ibase = vtophys(sc-ibase);
sc-reg = (struct i2o_registers *)sc-ibase;
sc-dev = dev;
-mtx_init(sc-mtx, pst lock, MTX_DEF, 0);
+mtx_init(sc-mtx, pst lock, NULL, MTX_DEF);
if (!iop_init(sc))
return 0;
Index: dev/sound/pcm/sndstat.c
===
RCS file: /home/ncvs/src/sys/dev/sound/pcm/sndstat.c,v
retrieving revision 1.14
diff -u -r1.14 sndstat.c
--- dev/sound/pcm/sndstat.c 7 Sep 2003 16:28:03 - 1.14
+++ dev/sound/pcm/sndstat.c 28 Nov 2003 01:36:21 -
@@ -340,7 +340,7 @@
static int
sndstat_init(void)
{
- mtx_init(sndstat_lock, sndstat, NULL, 0);
+ mtx_init(sndstat_lock, sndstat, NULL,
panic inserting CF card.
I'm able to reproduce a panic on demand. I simply insert my IBM Microdrive CF card into the PCM/CIA slot of the laptop, which is a Dell CPi, and panic! I build a kernel.debug in the hope somebody can help me analyze the back-trace. Oh by the way, the sources from this backtrace are from 11/27/2003, and inserting the CF card used to be functional in early November. I have no begun the process of targeting various dates/time to find when functionality was lost. # uname -a FreeBSD buda 5.2-BETA FreeBSD 5.2-BETA #0: Thu Nov 27 05:10:53 CST 2003 [EMAIL PROTECTED]:/usr/src/sys/i386/compile/TUNED i386 # gdb -k /sys/i386/compile/ESC[KTUNED/kernel.debug vmcore.0 GNU gdb 5.2.1 (FreeBSD) Copyright 2002 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-undermydesk-freebsd... panic: from debugger panic messages: --- Fatal trap 18: integer divide fault while in kernel mode cpuid = 0; apic id = 00 instruction pointer = 0x8:0xc06be43b stack pointer = 0x10:0xc8f51a8c frame pointer = 0x10:0xc8f51b0c code segment= base 0x0, limit 0xf, type 0x1b = DPL 0, pres 1, def32 1, gran 1 processor eflags= interrupt enabled, resume, IOPL = 0 current process = 7 (cbb1) panic: from debugger cpuid = 0; Fatal trap 3: breakpoint instruction fault while in kernel mode cpuid = 0; apic id = 00 instruction pointer = 0x8:0xc0697e95 stack pointer = 0x10:0xc8f51840 frame pointer = 0x10:0xc8f5184c code segment= base 0x0, limit 0xf, type 0x1b = DPL 0, pres 1, def32 1, gran 1 processor eflags= IOPL = 0 current process = 7 (cbb1) Fatal trap 18: integer divide fault while in kernel mode cpuid = 0; apic id = 00 instruction pointer = 0x8:0xc06be43b stack pointer = 0x10:0xc8f51a8c frame pointer = 0x10:0xc8f51b0c code segment= base 0x0, limit 0xf, type 0x1b = DPL 0, pres 1, def32 1, gran 1 processor eflags= interrupt enabled, resume, IOPL = 0 current process = 7 (cbb1) Fatal trap 18: integer divide fault while in kernel mode cpuid = 0; apic id = 00 instruction pointer = 0x8:0xc06be43b stack pointer = 0x10:0xc8f51a8c frame pointer = 0x10:0xc8f51b0c code segment= base 0x0, limit 0xf, type 0x1b = DPL 0, pres 1, def32 1, gran 1 processor eflags= interrupt enabled, resume, IOPL = 0 current process = 7 (cbb1) Fatal trap 18: integer divide fault while in kernel mode cpuid = 0; apic id = 00 instruction pointer = 0x8:0xc06be43b stack pointer = 0x10:0xc8f51a8c frame pointer = 0x10:0xc8f51b0c code segment= base 0x0, limit 0xf, type 0x1b = DPL 0, pres 1, def32 1, gran 1 processor eflags= interrupt enabled, resume, IOPL = 0 current process = 7 (cbb1) Fatal trap 18: integer divide fault while in kernel mode cpuid = 0; apic id = 00 instruction pointer = 0x8:0xc06be43b stack pointer = 0x10:0xc8f51a8c frame pointer = 0x10:0xc8f51b0c code segment= base 0x0, limit 0xf, type 0x1b = DPL 0, pres 1, def32 1, gran 1 processor eflags= interrupt enabled, resume, IOPL = 0 current process = 7 (cbb1) Fatal trap 18: integer divide fault while in kernel mode cpuid = 0; apic id = 00 instruction pointer = 0x8:0xc06be43b stack pointer = 0x10:0xc8f51a8c frame pointer = 0x10:0xc8f51b0c code segment= base 0x0, limit 0xf, type 0x1b = DPL 0, pres 1, def32 1, gran 1 processor eflags= interrupt enabled, resume, IOPL = 0 current process = 7 (cbb1) Fatal trap 18: integer divide fault while in kernel mode cpuid = 0; apic id = 00 instruction pointer = 0x8:0xc06be43b stack pointer = 0x10:0xc8f51a8c frame pointer = 0x10:0xc8f51b0c code segment= base 0x0, limit 0xf, type 0x1b = DPL 0, pres 1, def32 1, gran 1 processor eflags= interrupt enabled, resume, IOPL = 0 current process = 7 (cbb1) Fatal trap 18: integer divide fault while in kernel mode cpuid = 0; apic id = 00 instruction pointer = 0x8:0xc06be43b stack pointer = 0x10:0xc8f51a8c frame pointer = 0x10:0xc8f51b0c code segment= base 0x0, limit 0xf, type 0x1b = DPL 0, pres 1, def32 1, gran 1 processor eflags= interrupt enabled, resume, IOPL = 0 current process = 7 (cbb1) panic: from debugger cpuid = 0; Uptime: 8m56s Dumping 127 MB 16 32 48 64
Re: lock order reversal is 5.2-BETA Nov 26
On Thu, Nov 27, 2003 at 10:00:54PM -0500, Mikhail Teterin wrote: On Thu, Nov 27, 2003 at 07:16:05PM -0500, Mikhail Teterin wrote: It did not crash or anything, but the following is printed on console now (addresses ommitted): lock order reversal 1st ... UMA lock (UMA lock) @ /usr/src/sys/vm/uma_core.c:1201 2nd ... system map (system map) @ /usr/src/sys/vm/vm_map.c:2210 Thanks, this was reported several times already. How about this one? lock order reversal 1st 0xc37abad4 vm object (vm object) @ /usr/src/sys/vm/swap_pager.c:1323 2nd 0xc098d020 swap_pager swhash (swap_pager swhash) @ /usr/src/sys/vm/swap_pager.c:1838 3rd 0xc1036948 vm object (vm object) @ /usr/src/sys/vm/uma_core.c:876 Even more frequently ;-) Kris pgp0.pgp Description: PGP signature
Re: 5.2-BETA + netatalk = crash
Sam Leffler On Wednesday 26 November 2003 06:51 am, Michael L. Squires wrote: On my dual CPU P6DGH the 11/22 cvsup of 5.2-BETA and netatalk crashes on boot. Stopping netatalk from starting stops the crash. I wasn't able to catch any crash information, but am currently recompiling with sources from last night to see if it's repeatable. Please try the attached patch, it should fix at least one problem in the netatalk code (Leo this should fix the panics you've seen during shutdown). Michael, hopefully this will also fix your problem--whatever it is. The patch certainly fixes the panic, thanks. I'm running a make buildworla, etc., on my notebook which NFS mounts the box running netatalk, which should trigger the IPv4 bug if I have it. Mike Squires ___ [EMAIL PROTECTED] mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: panic inserting CF card.
On 27 Nov, masta wrote:
I'm able to reproduce a panic on demand. I simply insert my IBM Microdrive
CF card into the PCM/CIA slot of the laptop, which is a Dell CPi, and
panic! I build a kernel.debug in the hope somebody can help me analyze the
back-trace.
Oh by the way, the sources from this backtrace are from 11/27/2003, and
inserting the CF card used to be functional in early November. I have no
begun the process of targeting various dates/time to find when
functionality was lost.
(kgdb) where
#10 0xc06995d8 in calltrap () at {standard input}:94
#11 0xc06be8de in __udivdi3 (a=0, b=0) at ../../../libkern/udivdi3.c:51
#12 0xc044ac53 in ad_print (adp=0x0) at ../../../dev/ata/ata-disk.c:384
#13 0xc044a3fb in ad_attach (atadev=0xc243d4a4) at
../../../dev/ata/ata-disk.c:162
#14 0xc0435e99 in ata_attach (dev=0x0) at ../../../dev/ata/ata-all.c:165
#15 0xc04752f5 in pccard_compat_do_attach (bus=0xc13a6b00, dev=0xc243d400)
at card_if.h:120
#16 0xc043c927 in pccard_compat_attach (dev=0xc243d400) at card_if.h:138
#17 0xc052fdf9 in device_probe_and_attach (dev=0xc243d400) at device_if.h:39
#18 0xc0473fa8 in pccard_attach_card (dev=0xc13a6b00) at
../../../dev/pccard/pccard.c:262
#19 0xc04628c8 in exca_insert (exca=0xc138d204) at card_if.h:66
#20 0xc047c4f3 in cbb_insert (sc=0xc138d204) at
../../../dev/pccbb/pccbb.c:1078
#21 0xc047c30b in cbb_event_thread (arg=0xc138d200) at
../../../dev/pccbb/pccbb.c:1028
#22 0xc0502b84 in fork_exit (callout=0xc047c1d0 cbb_event_thread,
arg=0x0, frame=0x0) at ../../../kern/kern_fork.c:793
(kgdb) q
In ad_print() there is the following statement:
ata_prtdev(adp-device,%lluMB %.40s [%lld/%d/%d] at ata%d-%s %s%s\n,
(unsigned long long)(adp-total_secs /
((1024L * 1024L) / DEV_BSIZE)),
adp-device-param-model,
(unsigned long long)(adp-total_secs /
(adp-heads * adp-sectors)),
adp-heads, adp-sectors,
device_get_unit(adp-device-channel-dev),
(adp-device-unit == ATA_MASTER) ? master : slave,
(adp-flags AD_F_TAG_ENABLED) ? tagged : ,
ata_mode2str(adp-device-mode));
Offhand I'd guess that adp-heads and/or adp-sectors is zero. If
you've got a core file, try backtracking from there with gdb, otherwise
sprinkle some printf's around. Either this calculation is new, or some
recent change is causing the heads and sectors to be initialized to
zero.
___
[EMAIL PROTECTED] mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-current
To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: 5.x DOS against NFS server
Guy Van Sanden I just ran nmap host... Nessus has the same effect. When running nmap host (nmap 2.53 on a 4.9-STABLE box)) against a 5.2-BETA host on the host I see Nove 27 13:06:24 mikes sm-mta[483]: NOQUEUE: SYSERR(root): getrequests: accept: Software caused connection abort Nove 27 13:06:24 mikes nfsd[392]: accept failed: Software caused connection abort between messages about response rate limits to nmap queries. On the client running 5.1-CURRENT with bonnie using a 100MB file on a volume NFS mounted from the 5.2-BETA server there are no log messages and no obvious error messages; bonnie finishes normally. Mike Squires ___ [EMAIL PROTECTED] mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: Turkeys and dynamic linking
* Kent Stewart [EMAIL PROTECTED] [031127 17:50]: On Thursday 27 November 2003 12:31 pm, Bill Moran wrote: walt wrote: To all of you who celebrate Thanksgiving today, I wish you a happy one! And speaking of turkeys, does anyone know how Microsoft handles the performance issues associated with dynamic linking? Do they do anything special, or just ignore the whole thing? Don't they fix the performance hit by moving performance-critical parts of the application into kernel space (such as IIS and MSSQL)? At least, that's what Eric Raymond claims in his latest book. I don't think that's an approach I would like to see FreeBSD take. It all depends because if you only have 1 dll loaded for multiple applications, which is one of the features I understand is built into Windows, you have real savings. You share the code and own the data. Windows' dynamic linker works in a similar way to what Apple does in terms of sharing dll code. It makes an attempt to load libraries at the same base address in all processes, so that one DLL can be easily mapped into multiple processes. When you build a DLL, you supply a preferred address where it should be loaded. If Windows can load the library there, it does so. It also tries to load DLL's in thh same order each time. Since every process in the system likely relies on kernel32.dll, and probably user32.dll and gdi32.dll and others, Windows is almost always able to put those libraries at the same place in each process. So it doesn't have to read kernel32.dll from disk, since the OS itself has it loaded from the beginning. It just needs to do the fixups. For user-defined libraries, there's a decent chance that the same thing will happen. If not, then you have to pay the penalty to remap the library from scratch into a new location. As far as moving things into the kernel, I'm not sure what ESR is referring to. It's easy to get code into kernel-space by making it a device driver, but AFAIK SQL Server code comes all from normal DLL libraries, all in user space. --Mike pgp0.pgp Description: PGP signature
Re: panic inserting CF card.
In message: [EMAIL PROTECTED] Don Lewis [EMAIL PROTECTED] writes: : Offhand I'd guess that adp-heads and/or adp-sectors is zero. If : you've got a core file, try backtracking from there with gdb, otherwise : sprinkle some printf's around. Either this calculation is new, or some : recent change is causing the heads and sectors to be initialized to : zero. I have patches in my tree that prevent the panic. However, they prevent the panic by not dividing by zero, rather than fixing the underlying problem. Warner ___ [EMAIL PROTECTED] mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to [EMAIL PROTECTED]
