Re: HEADS UP: I broke swapping
On Tue, 22 May 2001, Peter Wemm wrote: John Baldwin wrote: If I have swap (i.e. I've run swapon on a swap partition) the program is kill ed by the system fine. If I don't have swap, then both the memkill process adn the swapper process (proc0) are stuck in the vmwait wait channel used by VM_WAIT. Any ideas? This may not be a new problem. I have seen a lot of machines hit this sort of thing at work. It can end up in the majority of processes on the system in this state. des's adsp.c test program caused this here on a machine with 64MB RAM and 132MB swap. No progress was made killing `bigproc' because everything gets stuck on vmwait. It is hard to see where the get stuck because the vmwait label is far from unique. It is used in both the vm_wait() and the vm_await() functions which are called from all over. Bruce To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-current in the body of the message
Re: What's causing troubles with pcm?
On Tue, May 22, 2001 at 04:29:39PM -0700, Alex Zepeda [EMAIL PROTECTED] wrote: Playing mp3's with mpg123 has been quite satistfactory until now. Today I've discovered that every execution of sync(8) distorts music by means of stretching musical phrase. The obvious answer would be to not run sync(8) :^) Likely, what you're seeing is the combo of the pcm driver being pretty sensitive to other interrupt activity and the ata driver turning off write caching by default. Probably not, because the sound file was on SCSI disk and I have WC turned on for both ATA disks I have. Sync(8) was only for demonstration purposes. -- Vallo Kallaste [EMAIL PROTECTED] To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-current in the body of the message
** HEADS UP **: sys/miscfs file systems moved
Dear -CURRENT users, Please note that: - FDESC, FIFO, NULL, PORTAL, PROC, UMAP and UNION file systems were repo-copied from sys/miscfs to sys/fs. - Renamed the following file systems and their modules: fdesc - fdescfs, portal - portalfs, union - unionfs. - Renamed corresponding kernel options: FDESC - FDESCFS, PORTAL - PORTALFS, UNION - UNIONFS. - Install header files for the above file systems. Warner, could you please add this to UPDATING? Cheers, -- Ruslan Ermilov Oracle Developer/DBA, [EMAIL PROTECTED] Sunbay Software AG, [EMAIL PROTECTED] FreeBSD committer, +380.652.512.251Simferopol, Ukraine http://www.FreeBSD.org The Power To Serve http://www.oracle.com Enabling The Information Age To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-current in the body of the message
rm -rf question
gary@trouble:~$ rm -rf /home/gary/public_html/mrtg/david/ Display all 2275 possibilities? (y or n) gary@trouble:~$ rm -rf /home/gary/public_html/mrtg/david/* bash: /bin/rm: Argument list too long Is this a bug with rm? I've never come accross this on -CURRENT or -STABLE for that matter.. To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-current in the body of the message
Re: rm -rf question
On Wed, May 23, 2001 at 05:51:40AM -0500, Storms of Perfection wrote: gary@trouble:~$ rm -rf /home/gary/public_html/mrtg/david/ Display all 2275 possibilities? (y or n) gary@trouble:~$ rm -rf /home/gary/public_html/mrtg/david/* bash: /bin/rm: Argument list too long Is this a bug with rm? I've never come accross this on -CURRENT or -STABLE for that matter.. Nope - you've limited to 64Kb worth of arguments by default (sysctl kern.argmax should show this). I guess you have some long filenames? David. To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-current in the body of the message
Re: rm -rf question
On Wed, May 23, 2001 at 05:51:40AM -0500, Storms of Perfection wrote: gary@trouble:~$ rm -rf /home/gary/public_html/mrtg/david/ Display all 2275 possibilities? (y or n) gary@trouble:~$ rm -rf /home/gary/public_html/mrtg/david/* bash: /bin/rm: Argument list too long Is this a bug with rm? I've never come accross this on -CURRENT or -STABLE for that matter.. No. It's a safety feature to prevent your shell from using too much memory to do the globbing you asked for (the *). This has nothing whatsoever to do with rm(1). -- wca To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-current in the body of the message
Re: rm -rf question
Thus spake Will Andrews ([EMAIL PROTECTED]): No. It's a safety feature to prevent your shell from using too much memory to do the globbing you asked for (the *). This has nothing whatsoever to do with rm(1). It's xargs job to workaround that: ls | xargs rm -rf Alex -- cat: /home/alex/.sig: No such file or directory To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-current in the body of the message
RE: New strategy of locking a process group
On Tue, 22 May 2001 07:56:52 -0700 (PDT), John Baldwin [EMAIL PROTECTED] said: John On 22-May-01 Seigo Tanimura wrote: On Tue, 22 May 2001 04:48:38 -0700 (PDT), John Baldwin [EMAIL PROTECTED] said: John On 22-May-01 Seigo Tanimura wrote: For now, p_mtx protects p_pgrp in struct proc. This is quite troublesome for the following reason: John Err, it doesn't really. It's mostly undecided at this point. Also, have you John looked at the BSD/OS code on builder? They have process groups and sessions John already locked not using global locks but using per-data structure locks. If you do not protect both p_pgrp and p_pglist in struct proc by an identical lock, you end up with breaking either setpgid(2) or kill(2) for a process group. The following scenario depicts an example of the breakage: John I'll have to look over the code in more detail, but I would encourage you John to check the BSD/OS code. I did that last night, and figured out that there are two problems in FreeBSD under the scenario shown below: 1. Lock a process and obtain a process group via p_pgrp. 2. Lock the process list of the process group and traverse the list via p_pglist, locking each process in the list. 3. Lock each process in the list. That scenario induces the following problems: A. We have to lock two processes at once in order to traverse the list, namely p and LIST_NEXT(p, p_pglist) where p is a process in the list. B. We have to lock a process in 1 and 3 while locking a process group in 2, resulting in lock order reversal. BSD/OS solves the problem A by locking not a process but a process group to traverse the list. It should be worth implementing that solution in FreeBSD. In order to solve the problem B, a lock other than the process lock should protect p_pgrp. BSD/OS adopts the lock of a session accessible via p_session embedded in struct proc, while I attempt to apply a global lock. In any case, the aim of the p_pgrp lock is essentially for protecting *only* p_pgrp. Once we lock p_pgrp, we can compare pg_session (which requires no locks), lock a process group, a session or etc. until unlocking p_pgrp. The issue of both of the solutions briefed above is that the p_pgrp lock protects *excess* data. It might be another solution to introduce a new mutex (p_pgrpmtx) into struct proc to lock p_pgrp. Although memory size costs per process, contention for p_pgrp lock should occur much less than to adopt a session lock or a global lock. As psignal() and some other functions also read p_pgrp, p_mtx should also lock p_pgrp. You lock either p_pgrpmtx or p_mtx to read p_pgrp, and both of the locks to modify p_pgrp. -- Seigo Tanimura [EMAIL PROTECTED] [EMAIL PROTECTED] To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-current in the body of the message
Re: ** HEADS UP **: sys/miscfs file systems moved
Dear -CURRENT users, Please note that: - FDESC, FIFO, NULL, PORTAL, PROC, UMAP and UNION file systems were repo-copied from sys/miscfs to sys/fs. - Renamed the following file systems and their modules: fdesc - fdescfs, portal - portalfs, union - unionfs. - Renamed corresponding kernel options: FDESC - FDESCFS, PORTAL - PORTALFS, UNION - UNIONFS. - Install header files for the above file systems. Warner, could you please add this to UPDATING? It may also be worth mentioning that people should move /usr/include to (say) /usr/include.not before their next installworld and nuke /usr/include.not after it completes. Cheers, -- Ruslan ErmilovOracle Developer/DBA, [EMAIL PROTECTED] Sunbay Software AG, [EMAIL PROTECTED]FreeBSD committer, +380.652.512.251 Simferopol, Ukraine http://www.FreeBSD.orgThe Power To Serve http://www.oracle.com Enabling The Information Age -- Brian [EMAIL PROTECTED]brian@[uk.]FreeBSD.org http://www.Awfulhak.org brian@[uk.]OpenBSD.org Don't _EVER_ lose your sense of humour ! To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-current in the body of the message
Re: ** HEADS UP **: sys/miscfs file systems moved
On Wed, May 23, 2001 at 12:52:40PM +0100, Brian Somers wrote: Dear -CURRENT users, Please note that: - FDESC, FIFO, NULL, PORTAL, PROC, UMAP and UNION file systems were repo-copied from sys/miscfs to sys/fs. - Renamed the following file systems and their modules: fdesc - fdescfs, portal - portalfs, union - unionfs. - Renamed corresponding kernel options: FDESC - FDESCFS, PORTAL - PORTALFS, UNION - UNIONFS. - Install header files for the above file systems. Warner, could you please add this to UPDATING? It may also be worth mentioning that people should move /usr/include to (say) /usr/include.not before their next installworld and nuke /usr/include.not after it completes. Why? Only new headers get installed, no old headers were withdrawn. Cheers, -- Ruslan Ermilov Oracle Developer/DBA, [EMAIL PROTECTED] Sunbay Software AG, [EMAIL PROTECTED] FreeBSD committer, +380.652.512.251Simferopol, Ukraine http://www.FreeBSD.org The Power To Serve http://www.oracle.com Enabling The Information Age To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-current in the body of the message
Re: ** HEADS UP **: sys/miscfs file systems moved
On Wed, May 23, 2001 at 12:52:40PM +0100, Brian Somers wrote: Dear -CURRENT users, Please note that: - FDESC, FIFO, NULL, PORTAL, PROC, UMAP and UNION file systems were repo-copied from sys/miscfs to sys/fs. - Renamed the following file systems and their modules: fdesc - fdescfs, portal - portalfs, union - unionfs. - Renamed corresponding kernel options: FDESC - FDESCFS, PORTAL - PORTALFS, UNION - UNIONFS. - Install header files for the above file systems. Warner, could you please add this to UPDATING? It may also be worth mentioning that people should move /usr/include to (say) /usr/include.not before their next installworld and nuke /usr/include.not after it completes. Why? Only new headers get installed, no old headers were withdrawn. Mea Culpa, I thought you had moved the installed /usr/include/?*fs files to /usr/include/fs/ Cheers, -- Ruslan ErmilovOracle Developer/DBA, [EMAIL PROTECTED] Sunbay Software AG, [EMAIL PROTECTED]FreeBSD committer, +380.652.512.251 Simferopol, Ukraine http://www.FreeBSD.orgThe Power To Serve http://www.oracle.com Enabling The Information Age -- Brian [EMAIL PROTECTED]brian@[uk.]FreeBSD.org http://www.Awfulhak.org brian@[uk.]OpenBSD.org Don't _EVER_ lose your sense of humour ! To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-current in the body of the message
harddisk faillure or kernel problem ?
For a while now I keep having the following logentries in my messages file: May 23 13:59:40 enigma /kernel: ad0s1a: UDMA ICRC error reading fsbn 1704031 of 720912-720913 (ad0s1 bn 17040 31; cn 1803 tn 3 sn 7) retrying May 23 13:59:40 enigma /kernel: ad0s1a: UDMA ICRC error reading fsbn 2857979 of 1297886-1297887 (ad0s1 bn 285 7979; cn 3024 tn 4 sn 47) retrying May 23 13:59:40 enigma /kernel: ad0s1a: UDMA ICRC error reading fsbn 3689535 of 1713664-1713677 (ad0s1 bn 368 9535; cn 3904 tn 4 sn 3) retrying May 23 13:59:40 enigma /kernel: ad0s1a: UDMA ICRC error reading fsbn 4198463 of 1968128-1968129 (ad0s1 bn 419 8463; cn 4442 tn 12 sn 17) retrying May 23 13:59:40 enigma /kernel: ad0s1a: UDMA ICRC error reading fsbn 4607039 of 2172416-2172419 (ad0s1 bn 460 7039; cn 4875 tn 2 sn 38) retrying Is this because of some UDMA option in my kernel that I have or may have missed, or is this really hardware ? I've had this for months now and never actually bothered because it never gave me any problems, at least not noticable ones. I use the machine remotely mainly, so harddisk speeds that may have dropped because of this are hardly noticable if you're just doing commandline work. Diagnoses: Do I need to replace hardware here, or not ? FreeBSD .xx.xxx.xx.xx 4.3-STABLE FreeBSD 4.3-STABLE #3: Tue May 15 20:23:48 CEST 2001 [EMAIL PROTECTED]:/usr/obj/usr/src/sys/ENIGMA i386 Thanks, Stephan -- Stephan van Beerschoten [SVB21-RIPE] [EMAIL PROTECTED] PGP fingerprint: 4557 9761 B212 FB4C 778D 3529 C42A 2D27 To err is human, to forgive is Not Company Policy To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-current in the body of the message
downgrade
Hi! Is it possible to downgrade a machine from -current to -stable? Thanks, norbert. To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-current in the body of the message
sbin/vinum broken
Hi! src/sbin/vinum is broken at the moment. It doesn't build without -DVINUMDEBUG. A quick workaround: Index: Makefile === RCS file: /home/ncvs/src/sbin/vinum/Makefile,v retrieving revision 1.20 diff -u -r1.20 Makefile --- Makefile2001/05/23 05:24:53 1.20 +++ Makefile2001/05/23 13:55:24 @@ -5,6 +5,7 @@ MAN= vinum.8 CFLAGS+= -I${.CURDIR}/../../sys -Wall +CFLAGS+= -DVINUMDEBUG # Print __FILE__ and __LINE__ when doing perror() #CFLAGS+= -DDEVBUG Cheers, -- Ruslan Ermilov Oracle Developer/DBA, [EMAIL PROTECTED] Sunbay Software AG, [EMAIL PROTECTED] FreeBSD committer, +380.652.512.251Simferopol, Ukraine http://www.FreeBSD.org The Power To Serve http://www.oracle.com Enabling The Information Age To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-current in the body of the message
Re: sbin/vinum broken
Date: Wed, 23 May 2001 16:56:39 +0300 From: Ruslan Ermilov [EMAIL PROTECTED] src/sbin/vinum is broken at the moment. It doesn't build without -DVINUMDEBUG. A quick workaround: [Workaround -- adding CFLAGS+= -DVINUMDEBUG to src/sbin/vinum/Makefile -- elided] OK; I verified that I experienced this, as well. After applying the workaround, I continued with make everything make kernel KERNCONF=LAPTOP_30W make installworld mergemaster. The make installworld dies, however: cd /usr/src/include/../sys; install -C -C -o root -g wheel -m 444 dev/usb/*.h /usr/include/dev/usb cd /usr/src/include/../sys; install -C -C -o root -g wheel -m 444 dev/wi/*.h /usr/include/dev/wi cd /usr/src/include/../sys; install -C -C -o root -g wheel -m 444 fs/fdesc/*.h /usr/include/fs/fdesc install: fs/fdesc/*.h: No such file or directory *** Error code 71 Stop in /usr/src/include. *** Error code 1 Stop in /usr/src. *** Error code 1 I suspect that the reference to fs/fdesc/*.h should read fs/fdescfs/*.h, per the earlier HEADS UP note. This system is: FreeBSD dhcp-133.catwhisker.org 5.0-CURRENT FreeBSD 5.0-CURRENT #7: Tue May 22 19:29:45 PDT 2001 [EMAIL PROTECTED]:/common/C/obj/usr/src/sys/LAPTOP_30W i386 However, not only was I able to get this far in multi-user mode, but I was able to do it while doing the make buildworld friends in an X environment. Cheers, david -- David H. Wolfskill [EMAIL PROTECTED] As a computing professional, I believe it would be unethical for me to advise, recommend, or support the use (save possibly for personal amusement) of any product that is or depends on any Microsoft product. To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-current in the body of the message
Re: downgrade
Norbert Koch writes: Hi! Is it possible to downgrade a machine from -current to -stable? Yes, it's possible, but if you've got much on your system I don't think it's worth it. I (almost) did it a couple of months ago. It's not for the faint of heart. One thing that you've got to keep in mind is the bump in shared library versions; you'll probably have to reinstall anything you built yourself or via the ports system, and make sure you've removed the -current libraries (with the higher version numbers) first. After I'd spent most of a day deinstalling and reinstalling various ports, I decided it would be a lot safer and easier to just do a binary-only install from the CD, check out the latest -stable sources, and upgrade that way. If you were tracking -current before, you've got a local copy of the repository, right :-)? That's a good argument for multiple partitions, by the way. Since I have a partition for projects, one for src (both FreeBSD and /usr/ports/distfiles), and one for my mp3s I just told sysinstall to newfs /, /usr and /var but leave /home and all the rest alone. -- Richard Kuhns [EMAIL PROTECTED] PO Box 6249 Tel: (765)477-6000 \ 100 Sawmill Roadx319 Lafayette, IN 47903 (800)489-4891 / To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-current in the body of the message
installworld broken (includes fix) [was: Re: sbin/vinum broken]
Date: Wed, 23 May 2001 09:08:31 -0700 (PDT) From: David Wolfskill [EMAIL PROTECTED] The make installworld dies, however: cd /usr/src/include/../sys; install -C -C -o root -g wheel -m 444 dev/usb/*.h /usr/include/dev/usb cd /usr/src/include/../sys; install -C -C -o root -g wheel -m 444 dev/wi/*.h /usr/include/dev/wi cd /usr/src/include/../sys; install -C -C -o root -g wheel -m 444 fs/fdesc/*.h /usr/include/fs/fdesc install: fs/fdesc/*.h: No such file or directory *** Error code 71 Stop in /usr/src/include. *** Error code 1 Stop in /usr/src. *** Error code 1 I suspect that the reference to fs/fdesc/*.h should read fs/fdescfs/*.h, per the earlier HEADS UP note. OK; that was necessary, but insufficient. Here's a patch: cvs diff -u include/Makefile Index: include/Makefile === RCS file: /cvs/freebsd/src/include/Makefile,v retrieving revision 1.138 diff -u -u -r1.138 Makefile --- include/Makefile2001/05/23 09:41:59 1.138 +++ include/Makefile2001/05/23 16:18:24 @@ -46,8 +46,8 @@ LNOHEADERDIRS= fs isofs ufs dev LSUBDIRS= cam/scsi dev/ppbus dev/usb dev/wi \ - fs/fdesc fs/fifofs fs/nullfs fs/portal fs/procfs fs/smbfs \ - fs/umapfs fs/union isofs/cd9660 ufs/ffs ufs/mfs ufs/ufs + fs/fdescfs fs/fifofs fs/nullfs fs/portalfs fs/procfs fs/smbfs \ + fs/umapfs fs/unionfs isofs/cd9660 ufs/ffs ufs/mfs ufs/ufs # Define SHARED to indicate whether you want symbolic links to the system # source (``symlinks''), or a separate copy (``copies''). ``symlinks'' is dhcp-133[18] Cheers, david -- David H. Wolfskill [EMAIL PROTECTED] As a computing professional, I believe it would be unethical for me to advise, recommend, or support the use (save possibly for personal amusement) of any product that is or depends on any Microsoft product. To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-current in the body of the message
Re: sbin/vinum broken
On Wed, May 23, 2001 at 09:08:31AM -0700, David Wolfskill wrote: Date: Wed, 23 May 2001 16:56:39 +0300 From: Ruslan Ermilov [EMAIL PROTECTED] src/sbin/vinum is broken at the moment. It doesn't build without -DVINUMDEBUG. A quick workaround: [Workaround -- adding CFLAGS+= -DVINUMDEBUG to src/sbin/vinum/Makefile -- elided] OK; I verified that I experienced this, as well. After applying the workaround, I continued with make everything make kernel KERNCONF=LAPTOP_30W make installworld mergemaster. The make installworld dies, however: cd /usr/src/include/../sys; install -C -C -o root -g wheel -m 444 dev/usb/*.h /usr/include/dev/usb cd /usr/src/include/../sys; install -C -C -o root -g wheel -m 444 dev/wi/*.h /usr/include/dev/wi cd /usr/src/include/../sys; install -C -C -o root -g wheel -m 444 fs/fdesc/*.h /usr/include/fs/fdesc install: fs/fdesc/*.h: No such file or directory *** Error code 71 Stop in /usr/src/include. *** Error code 1 Stop in /usr/src. *** Error code 1 Already fixed in src/include/Makefile,v 1.139, sorry for that! Cheers, -- Ruslan Ermilov Oracle Developer/DBA, [EMAIL PROTECTED] Sunbay Software AG, [EMAIL PROTECTED] FreeBSD committer, +380.652.512.251Simferopol, Ukraine http://www.FreeBSD.org The Power To Serve http://www.oracle.com Enabling The Information Age To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-current in the body of the message
RE: New strategy of locking a process group
On 23-May-01 Seigo Tanimura wrote: The issue of both of the solutions briefed above is that the p_pgrp lock protects *excess* data. It might be another solution to introduce a new mutex (p_pgrpmtx) into struct proc to lock p_pgrp. Although memory size costs per process, contention for p_pgrp lock should occur much less than to adopt a session lock or a global lock. As psignal() and some other functions also read p_pgrp, p_mtx should also lock p_pgrp. You lock either p_pgrpmtx or p_mtx to read p_pgrp, and both of the locks to modify p_pgrp. Sounds good. I would just use a global p_grp lock for now. It can always be changed to be more fine-grained later if desired. -- John Baldwin [EMAIL PROTECTED] -- http://www.FreeBSD.org/~jhb/ PGP Key: http://www.Baldwin.cx/~john/pgpkey.asc Power Users Use the Power to Serve! - http://www.FreeBSD.org/ To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-current in the body of the message
RE: ** HEADS UP **: sys/miscfs file systems moved
On 23-May-01 (09:53:13/GMT) Ruslan Ermilov wrote: - FDESC, FIFO, NULL, PORTAL, PROC, UMAP and UNION file systems were repo-copied from sys/miscfs to sys/fs. - Renamed the following file systems and their modules: fdesc - fdescfs, portal - portalfs, union - unionfs. - Renamed corresponding kernel options: FDESC - FDESCFS, PORTAL - PORTALFS, UNION - UNIONFS. Maybe this is a good moment to ask for rename modules from *_saver.ko to saver_*.ko to follow other layouts as for if_ for interfaces, ng_ for netgraph, splash_ for splash screen and snd_ for sound (as i asked into PR kern/21154)? I know it is _ONLY_ a cosmetic change, but I think may be one of the simple ;) BTW: Apart from sources, the only reference to *saved.ko modules on a running system is into /etc/rc.i386: kldstat -v | grep -q _saver || kldload ${saver}_saver and must be changed to kldstat -v | grep -q saver_ || kldload saver_${saver} Thanks for your time, Riccardo. To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-current in the body of the message
RE: cvs commit: src/sys/vm vm_fault.c
On 23-May-01 John Baldwin wrote: jhb 2001/05/23 15:09:18 PDT Modified files: sys/vm vm_fault.c Log: Take a more conservative approach and still lock Giant around VM faults for now. Hopefully swapping is working now. The changes I made are perhaps overly conservative, so there may still be some more changes coming down the pipeline to push down Giant a bit farther. -- John Baldwin [EMAIL PROTECTED] -- http://www.FreeBSD.org/~jhb/ PGP Key: http://www.baldwin.cx/~john/pgpkey.asc Power Users Use the Power to Serve! - http://www.FreeBSD.org/ To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-current in the body of the message
Re: cvs commit: src/sys/vm vm_fault.c
* John Baldwin [EMAIL PROTECTED] [010523 19:10] wrote: On 23-May-01 John Baldwin wrote: jhb 2001/05/23 15:09:18 PDT Modified files: sys/vm vm_fault.c Log: Take a more conservative approach and still lock Giant around VM faults for now. Hopefully swapping is working now. The changes I made are perhaps overly conservative, so there may still be some more changes coming down the pipeline to push down Giant a bit farther. ;) -- -Alfred Perlstein [[EMAIL PROTECTED]] Instead of asking why a piece of software is using 1970s technology, start asking why software is ignoring 30 years of accumulated wisdom. To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-current in the body of the message
Re: sbin/vinum broken
On Wednesday, 23 May 2001 at 16:56:39 +0300, Ruslan Ermilov wrote: Hi! src/sbin/vinum is broken at the moment. It doesn't build without -DVINUMDEBUG. *sigh*. I could have sworn I tested this, but it seems I did it in a parallel universe. It's fixed now, I think. me-pointyhat++; A quick workaround: Index: Makefile === RCS file: /home/ncvs/src/sbin/vinum/Makefile,v retrieving revision 1.20 diff -u -r1.20 Makefile --- Makefile 2001/05/23 05:24:53 1.20 +++ Makefile 2001/05/23 13:55:24 @@ -5,6 +5,7 @@ MAN= vinum.8 CFLAGS+= -I${.CURDIR}/../../sys -Wall +CFLAGS+= -DVINUMDEBUG This didn't work for me: === root@zaphod (/dev/ttyp1) /src/FreeBSD/5.0-CURRENT/src/sbin/vinum 4 - make Warning: Using /wantadilla/home/obj/src/FreeBSD/5.0-CURRENT/src/sbin/vinum as object directory instead of canonical /usr/obj/src/FreeBSD/5.0-CURRENT/src/sbin/vinum cc -O -pipe -c /src/FreeBSD/5.0-CURRENT/src/sbin/vinum/v.c In file included from /src/FreeBSD/5.0-CURRENT/src/sbin/vinum/v.c:57: /src/FreeBSD/5.0-CURRENT/src/sbin/vinum/vext.h:75: dev/vinum/vinumvar.h: No such file or directory /src/FreeBSD/5.0-CURRENT/src/sbin/vinum/vext.h:76: dev/vinum/vinumio.h: No such file or directory /src/FreeBSD/5.0-CURRENT/src/sbin/vinum/vext.h:77: dev/vinum/vinumkw.h: No such file or directory /src/FreeBSD/5.0-CURRENT/src/sbin/vinum/vext.h:78: dev/vinum/vinumutil.h: No such file or directory Am I missing something? Greg -- Finger [EMAIL PROTECTED] for PGP public key See complete headers for address and phone numbers To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-current in the body of the message
Tonights panic: free_newdirblk+0x73: movl %eax,0x10(%edx)
Just upgraded to latest sources, doesn't look like the swap issue ... was performing a 'make -j16 buildworld' when it panic'd ... Fataltrap 12: page fault while in kernel mode cpuid = 0; lapic.id = fault virtual address = 0x12 fault code = supervisor write, page not present instruction pointer = 0x8:0xc020abff stack pointer = 0x10:0xcb75dbbc frame pointer = 0x10:0xcb75dbc4 code segmnt = base 0x0, limit 0xf, type 0x1b = DPL 0, pres 1, def32 1, gran 1 processor eflags= interrupt enabled, resume, IOPL = 0 current process = 17 (swi3: cambio) kernel: type 12 trap, code=0 Stopped at free_newdirblk+0x73:movl%eax,0x10(%edx) db trace free_newdirblk+0x73 handle_written_inodeblock+0x29e softdep_disk_write_complete+0x6a bufdone+0xbc bufdonebio+0xf dadone+0x214 camisr+0x1d7 ithread_lopp+0x330 fork_exit+0xbc fork_trampoline+0x8 Marc G. Fournier ICQ#7615664 IRC Nick: Scrappy Systems Administrator @ hub.org primary: [EMAIL PROTECTED] secondary: scrappy@{freebsd|postgresql}.org To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-current in the body of the message
Re: kernel broken in two places
Michael Harnois [EMAIL PROTECTED] writes: Unless I missed a heads-up somewhere ... mkdep -f .depend -a -nostdinc -D_KERNEL -DKLD_MODULE -I- -I. -I@ -I@/dev -I @/../include /usr/src/sys/modules/if_sl/../../net/if_sl.c /usr/src/sys/modul es/if_sl/../../net/slcompress.c /usr/src/sys/modules/if_sl/../../net/if_sl.c:96: #error Huh? Slip without in et? Are you compiling without options INET? and then, if I overcome that breakage by brute force ... cc -c -O -pipe -march=pentiumpro -Wall -Wredundant-decls -Wnested-externs -Ws trict-prototypes -Wmissing-prototypes -Wpointer-arith -Winline -Wcast-qual -fformat-extensions -ansi -nostdinc -I- -I. -I../.. -I../../dev -I../../../ include -I../../contrib/dev/acpica/Subsystem/Include -D_KERNEL -include opt_ global.h -elf -mpreferred-stack-boundary=2 ../../kern/tty_snoop.c ../../kern/tty_snoop.c: In function `snp_detach': ../../kern/tty_snoop.c:394: structure has no member named `snp_olddisc' ../../kern/tty_snoop.c: In function `snpioctl': ../../kern/tty_snoop.c:477: structure has no member named `snp_olddisc' *** Error code 1 This is my fault. I've fixed it. Sorry, everybody :-/ Dima Dorfman [EMAIL PROTECTED] -- Michael D. Harnois[EMAIL PROTECTED] Redeemer Lutheran Church Washburn, Iowa Some folks you don't have to satirize, you just quote 'em. --Tom Paxton To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-current in the body of the message To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-current in the body of the message
RE: Tonights panic: free_newdirblk+0x73: movl %eax,0x10(%e
On 24-May-01 The Hermit Hacker wrote: Just upgraded to latest sources, doesn't look like the swap issue ... was performing a 'make -j16 buildworld' when it panic'd ... Fataltrap 12: page fault while in kernel mode cpuid = 0; lapic.id = fault virtual address = 0x12 fault code = supervisor write, page not present instruction pointer = 0x8:0xc020abff stack pointer = 0x10:0xcb75dbbc frame pointer = 0x10:0xcb75dbc4 code segmnt = base 0x0, limit 0xf, type 0x1b = DPL 0, pres 1, def32 1, gran 1 processor eflags= interrupt enabled, resume, IOPL = 0 current process = 17 (swi3: cambio) kernel: type 12 trap, code=0 Stopped atfree_newdirblk+0x73:movl%eax,0x10(%edx) Looks like %edx is 0x2 then. In other post, the faulting va was 0x11 with the same instruction, meaning that %edx is 0x1. So it looks like it isn't a NULL pointer dereference. It may be related to the VM stuff in that it may be that a buffer is being manipulated somewhere without Giant being held while being manipulated with Giant being held somewhere else? Or it could be a softupdates bug. :-P Is this an SMP machine? Ah, yes it is. Next time you see this, can you display 'show pcpu' for each CPU (show pcpu does the current cpu, show cpu some decimal number displays the info on CPU some decimal number). Also, can you get a backtrace of each process that is running? trace on x86 can take the pid of a process to get a backtrace of as a parameter, and the show pcpu commands should show you what process was executing on the other CPU (including its pid). db trace free_newdirblk+0x73 handle_written_inodeblock+0x29e softdep_disk_write_complete+0x6a bufdone+0xbc bufdonebio+0xf dadone+0x214 camisr+0x1d7 ithread_lopp+0x330 fork_exit+0xbc fork_trampoline+0x8 -- John Baldwin [EMAIL PROTECTED] -- http://www.FreeBSD.org/~jhb/ PGP Key: http://www.baldwin.cx/~john/pgpkey.asc Power Users Use the Power to Serve! - http://www.FreeBSD.org/ To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-current in the body of the message
Re: kernel broken in two places
Dima Dorfman [EMAIL PROTECTED] said: Are you compiling without options INET? No, that I could have figured out. -- Michael D. Harnois[EMAIL PROTECTED] Redeemer Lutheran Church Washburn, Iowa CYNIC, n. A blackguard whose faulty vision sees things as they are, not as they ought to be. -- Ambrose Bierce To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-current in the body of the message
RE: Tonights panic: free_newdirblk+0x73: movl %eax,0x10(%e
Okay, running a new buildworld right now ... give it a half hour or so :) On Wed, 23 May 2001, John Baldwin wrote: Looks like %edx is 0x2 then. In other post, the faulting va was 0x11 with the same instruction, meaning that %edx is 0x1. So it looks like it isn't a NULL pointer dereference. It may be related to the VM stuff in that it may be that a buffer is being manipulated somewhere without Giant being held while being manipulated with Giant being held somewhere else? Or it could be a softupdates bug. :-P Is this an SMP machine? Ah, yes it is. Next time you see this, can you display 'show pcpu' for each CPU (show pcpu does the current cpu, show cpu some decimal number displays the info on CPU some decimal number). Okay, this is no problem ... Also, can you get a backtrace of each process that is running? trace on x86 can take the pid of a process to get a backtrace of as a parameter, and the show pcpu commands should show you what process was executing on the other CPU (including its pid). Oops ... neat, now it just locked up solid and ctl-alt-esc doesn't even get me to debugger :( ah well, will try and recreate the error and report back ... To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-current in the body of the message
Re: kernel broken in two places
Well, I deleted /usr/src/sys/, cvsup'd again, and now make depend works. Who knows ... -- Michael D. Harnois[EMAIL PROTECTED] Redeemer Lutheran Church Washburn, Iowa Be radical, be as radical as you can ... because radicals empower liberals. --John Preston To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-current in the body of the message
Date for a working -current?
I'm in the processing of bring a 5-current system of Oct 2000 vintage more upto-date. The kernel built around May 23rd 2001, has been quite unstable, with numerous warning on lock order reversals, and alas, frequent panics, mostly on account of processes sleeping while holding mutexes. Its been a while since -current was like this :). My priority is to build a reasonably upto-date userland. So, my question is: what is a known good date that I can upgrade the machine to? Regards, Koshy [EMAIL PROTECTED] To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-current in the body of the message