Re: cvs commit: src/sys/tools vnode_if.awk
On Sat, 6 Jul 2002, Jeff Roberson wrote: jeff2002/07/06 23:39:37 PDT Modified files: sys/toolsvnode_if.awk Log: - Use 'options DEBUG_VFS_LOCKS' instead of the DEBUG_ALL_VFS_LOCKS environment variable to enable the lock verifiction code. Revision ChangesPath 1.33 +7 -5 src/sys/tools/vnode_if.awk This was previously disabled because our locking was so bad that we could not boot with this option enabled. I can now boot, compile a kernel, and reboot without catching any locking asserts. This means that we are safe at our current level of debugging, but we are certainly not out of the woods wrt VFS locking yet. If you have a crash test box I would appreciate it if you would enable this kernel option. If it catches any errors you will be droped into the debugger where you can get a backtrace (type: tr) and mail it to me current@ to avoid dups. To disable the panic print once you've hit a bug type the following in ddb: w vfs_badlock_print 0 w vfs_badlock_panic 0 And you will not see any more errors. Thanks! Jeff To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-current in the body of the message
Re: i386 trap code
Jonthan, I just use DOS program as an example, for any program, if it wants to go into VM86 mode, it is very easy, just calls i386_vm86() to initailize its VM86 pcb extension, setups some memory area, then call sigreturn() to turn into VM86 mode. I think global in_vm86call flags is a bug under SMP, it creates a race condition. suppose this scenario: CPU A is running a simple VM86 code program. CPU B is running vm86_intcall() by some kernel driver (vesa module ?) CPU B set in_vm86call = 1 CPU A gets a fault trap. CPU A runs trap(), and find that in_vm86call is set and handles the trap as it is running vm86_intcall(), but it is not true and make a mess. David Xu --- Jonathan Lemon [EMAIL PROTECTED] wrote: On Sat, Jul 06, 2002 at 05:15:26AM -0700, David Xu wrote: I don't know how DOS emulating program works, but if it let DOS program run in VM86 mode, the in_vm86call global flag can prevent one CPU to run VM86 BIOS call and another CPU run DOS VM86 code, because it can not distinct which CPU the kernel is calling BIOS and which CPU is running VM86 DOS code, under SMP this is a problem. for exapmle, vesa module running on first CPU is calling VM86 BIOS, and second CPU is running DOS program, the DOS program maybe simply executes a privilege instruction to trigger trap, and the CPU will see itself calling VM86 BIOS, but it shouldn't. The virtual vm86 mode that doscmd(1) uses is different than the vm86 bios calls (or bios16, or bios32) which allows direct execution of BIOS code. They do not have much in common. doscmd() does not directly execute any of the BIOS code; it provides its own BIOS emulator. The scenario you postulate above cannot exist. -- Jonathan __ Do You Yahoo!? Sign up for SBC Yahoo! Dial - First Month Free http://sbc.yahoo.com To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-current in the body of the message
Re: cvs commit: src/sys/tools vnode_if.awk
On 7 Jul, Jeff Roberson wrote: On Sat, 6 Jul 2002, Jeff Roberson wrote: - Use 'options DEBUG_VFS_LOCKS' instead of the DEBUG_ALL_VFS_LOCKS environment variable to enable the lock verifiction code. This was previously disabled because our locking was so bad that we could not boot with this option enabled. I can now boot, compile a kernel, and reboot without catching any locking asserts. This means that we are safe at our current level of debugging, but we are certainly not out of the woods wrt VFS locking yet. If you have a crash test box I would appreciate it if you would enable this kernel option. If it catches any errors you will be droped into the debugger where you can get a backtrace (type: tr) and mail it to me current@ to avoid dups. It wasn't able to sucessfully boot with this enabled. I'm hand transcribing this, so apologies for any typos: [fsck finishes] Doing initial network setup: host.conf hostname. VOP_READ: 0xc6737800 is not locked but should be Debugger(Lock violation. ) Debugger(c0420fe4) at Debugger+0x45 vn_rdwr(0,c6737800,c6425000,55ac,0,0,1,8,c22c7200,df241aec,c22cc0c0) at vn_rdwr+0x18d linker_hints_lookup(c04750a0,c,c62df000,5,0) at linker_hints_lookup+0x2d9 linker_search_module(c62df000,5,0,0,c0415120) at linker_search_module+0x43 linker_load_module(0,c62df000,0,0,df241cdc) at linker_load_module+0x72 kldload(c22cc0c0,df241d14,1,0,296) at kldload+0xc3 syscall(...) If I disable the panic and continue the boot process, I see the following in dmesg: da0 at ahc0 bus 0 target 0 lun 0 da0: SEAGATE ST336706LW 010A Fixed Direct Access SCSI-3 device da0: 160.000MB/s transfers (80.000MHz, offset 63, 16bit), Tagged Queueing Enable d da0: 35003MB (71687370 512 byte sectors: 255H 63S/T 4462C) /usr/src/sys/vm/uma_core.c:1332: could sleep with kernel linker locked from /u sr/src/sys/kern/kern_linker.c:1798 VOP_READ: 0xc6737800 is not locked but should be VOP_GETVOBJECT: 0xc6737800 is not locked but should be VOP_GETVOBJECT: 0xc6737800 is not locked but should be VOP_BMAP: 0xc6737800 is not locked but should be VOP_GETVOBJECT: 0xc6737800 is not locked but should be VOP_GETVOBJECT: 0xc6737800 is not locked but should be VOP_READ: 0xc6737800 is not locked but should be VOP_READ: 0xc6737800 is not locked but should be VOP_READ: 0xc6737800 is not locked but should be To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-current in the body of the message
5.0 DP2 (was Re: KSE M-III status junior hacker project.)
On Sat, Jul 06, 2002 at 04:57:08PM -0700, Julian Elischer wrote: Well with various hints from here and there I have fixed the ^Z/fg problem (at least it seems fixed to me and others that have tested) This basically leaves only one outstanding problem that I know of which is a problem that Warner has with a particular progam. (This may also be fixed but I don't know) Hi Julian, Thanks for your progress on KSE! How long should we wait before branching in Perforce for 5.0 DP2? I would like to give at least 10 more days for this and other changes to settle before making the branch. If all goes well, I would like to release 5.0 DP2 at the end of this month. - Murray To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-current in the body of the message
ifconfig problem
Hello! I've upgraded one of my boxes (4.5-RELEASE to FreeBSD 4.6-RELEASE) and encountered the following problem: After the upgrade it won't bring one of its two identical interfaces (ed0 and ed1) up at the boot-time. The internal one(ed1) was brought up cleanly, the external one(ed0) didn't get up. The only difference between them was that i was setting a specific MAC address on ed0. My rc.conf line for ed0 was like: ifconfig_ed0=inet 1.2.3.4 lladdr 01:02:03:04:05:06 And the ifconfig at the boot time said that it: can't set link-level netmask or broadcast. Changing lladdr to link or ether didn't help, nor did interchanging the order of these addresses on the config line. Now I've found that I still can bring the interface up by executing two separate ifconfigs like: ifconfig ed0 lladdr 01:02:03:04:05:06 ifconfig ed0 inet 1.2.3.4 My current workaround is to set MAC in /etc/rc.early and the IP in rc.conf. My investigation revealed that this error message was introduced during the MFC of /src/sbin/ifconfig/ifconfig.c, version 1.51.2.16, 2002/04/03 by ru. I suspect that I've no real intention to set any link level netmask or broadcasts. Therefore, there must be an programming error somewhere in ifconfig.c, I even suppose it is in the setifaddr function, but I can't say it for sure, because I lack knowledge to understand the code in whole. I will make a PR soon, if there're no sudden objections. Best wishes, Mike Boev. To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-current in the body of the message
sshd is complaining about /var/log/lastlog permission
Sshd on my current box is logging messsages about sshd[pid]: /var/log/lastlog: permission denied on my recently updated -current box. The permission on this file are the defaults. Could this be a side effect of the new privilege separation stuff? To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-current in the body of the message
Re: sshd is complaining about /var/log/lastlog permission
Don Lewis [EMAIL PROTECTED] writes: Sshd on my current box is logging messsages about sshd[pid]: /var/log/lastlog: permission denied on my recently updated -current box. The permission on this file are the defaults. Could this be a side effect of the new privilege separation stuff? Yes, but it's harmless. I just haven't had time to sort it out yet. DES -- Dag-Erling Smorgrav - [EMAIL PROTECTED] To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-current in the body of the message
Re: cvs commit: src/sys/tools vnode_if.awk
On Sun, 7 Jul 2002, Don Lewis wrote: On 7 Jul, Jeff Roberson wrote: On Sat, 6 Jul 2002, Jeff Roberson wrote: - Use 'options DEBUG_VFS_LOCKS' instead of the DEBUG_ALL_VFS_LOCKS environment variable to enable the lock verifiction code. If you have a crash test box I would appreciate it if you would enable this kernel option. If it catches any errors you will be droped into the debugger where you can get a backtrace (type: tr) and mail it to me current@ to avoid dups. It wasn't able to sucessfully boot with this enabled. I'm hand transcribing this, so apologies for any typos: [fsck finishes] Doing initial network setup: host.conf hostname. VOP_READ: 0xc6737800 is not locked but should be Debugger(Lock violation. ) Debugger(c0420fe4) at Debugger+0x45 vn_rdwr(0,c6737800,c6425000,55ac,0,0,1,8,c22c7200,df241aec,c22cc0c0) at vn_rdwr+0x18d linker_hints_lookup(c04750a0,c,c62df000,5,0) at linker_hints_lookup+0x2d9 linker_search_module(c62df000,5,0,0,c0415120) at linker_search_module+0x43 linker_load_module(0,c62df000,0,0,df241cdc) at linker_load_module+0x72 kldload(c22cc0c0,df241d14,1,0,296) at kldload+0xc3 syscall(...) Oh, I don't use kernel modules on my main dev box. Thanks! I'll have this resolved tomorrow. More below. If I disable the panic and continue the boot process, I see the following in dmesg: da0 at ahc0 bus 0 target 0 lun 0 da0: SEAGATE ST336706LW 010A Fixed Direct Access SCSI-3 device da0: 160.000MB/s transfers (80.000MHz, offset 63, 16bit), Tagged Queueing Enable d da0: 35003MB (71687370 512 byte sectors: 255H 63S/T 4462C) /usr/src/sys/vm/uma_core.c:1332: could sleep with kernel linker locked from /u sr/src/sys/kern/kern_linker.c:1798 VOP_READ: 0xc6737800 is not locked but should be VOP_GETVOBJECT: 0xc6737800 is not locked but should be VOP_GETVOBJECT: 0xc6737800 is not locked but should be VOP_BMAP: 0xc6737800 is not locked but should be VOP_GETVOBJECT: 0xc6737800 is not locked but should be VOP_GETVOBJECT: 0xc6737800 is not locked but should be VOP_READ: 0xc6737800 is not locked but should be VOP_READ: 0xc6737800 is not locked but should be VOP_READ: 0xc6737800 is not locked but should be These are all also from the linker. I just verified by loading a module. Thanks, Jeff To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-current in the body of the message
Re: Does uplcom(4) support Bencole 08303?
On Sat, Jul 06, 2002 at 09:48:54PM -0400, Craig Rodrigues wrote: Would the Bencole 08303 cable be supported by the uplcom(4) driver? I can't tell on the manufacturer's web site, nor on the packaging for the cable itself if it is based on the Prolific PL-2303 chipset or not. Sorry Craig I don't know. Maybe you could purchase one on sale or return. If it works be sure to let us know won't you? :). Joe To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-current in the body of the message
Re: KSE M-III status junior hacker project.
On Sat, Jul 06, 2002 at 04:57:08PM -0700, Julian Elischer wrote: Well with various hints from here and there I have fixed the ^Z/fg problem (at least it seems fixed to me and others that have tested) This basically leaves only one outstanding problem that I know of which is a problem that Warner has with a particular progam. (This may also be fixed but I don't know) If anyone knows of something that was broken by the KSE commit, (i.e. it worked just before and not after) and is STILL broken please let me know because I think I can pretty much declare that chapter finished, and I'd like to get on with extending KSE functionality. This will be the start of Milestone IV, which would be add support for threads to run on multiple processors. Coincident with that some work should also proceed on gradually identifying and cleaning up places in the kernel where multithreading is just not ready.. e.g. which thread status do you get when you type ^T? I've absolutely no idea what's causing it, but I'm still having random reboots of current after some uptime with no dumps. I'll install a new kernel today and report back if it still happens. Maybe someone can help me to track it down. Joe To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-current in the body of the message
Build errors in /usr/src/gnu/usr.bin/cc/cc1plus with today's current
Hello, The last few days I unable to get a complete make world. This morning I did a make clean in /usr/src and a rm -rf /usr/obj. After this cvsup (from cvsup.freebsd.org) I started make world, then i'm getting the folowing errors: /usr/src/gnu/usr.bin/cc/cc_tools/freebsd-native.h:61:25: attempt to use poisoned malloc /usr/src/gnu/usr.bin/cc/cc_tools/freebsd-native.h:62:25: attempt to use poisoned calloc /usr/src/gnu/usr.bin/cc/cc_tools/freebsd-native.h:63:25: attempt to use poisoned realloc /usr/src/gnu/usr.bin/cc/cc_tools/freebsd-native.h:64:25: attempt to use poisoned strdup mkdep: compile failed *** Error code 1 Stop in /usr/src/gnu/usr.bin/cc/cc1plus. Yesterday after a good make world, make installworld (in single user) produced a debug prompt (dont't have logging anymore :-( ), could it be that that caused the problems I have now? Greetings, Richard. An OS is like swiss cheese, the bigger it is, the more holes you get! To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-current in the body of the message
Re: dump(8) is hosed
In message [EMAIL PROTECTED], Don Lewis writes:
I was finally finally able to reproduce this by creating a large file
before doing the dump. Dump(8) is *very* hosed. The UFS2 import broke
it's ability to follow multiple levels of indirect blocks.
Thanks for tracking this down! One thing is that the code was using
the static pointers to avoid having to malloc and free blocks every
time. Keeping an array of NIADDR pointers and using `ind_level' as
the index is an alternative (patch below) - I doubt the performance
difference is noticable but it avoids having to remember the free()
before each return.
I'll commit your printf format changes first anyway - thanks!
Ian
Index: traverse.c
===
RCS file: /dump/FreeBSD-CVS/src/sbin/dump/traverse.c,v
retrieving revision 1.19
diff -u -r1.19 traverse.c
--- traverse.c 21 Jun 2002 06:17:57 - 1.19
+++ traverse.c 7 Jul 2002 10:44:55 -
@@ -275,10 +275,13 @@
{
int ret = 0;
int i;
- static caddr_t idblk;
+ static caddr_t idblks[NIADDR];
+ caddr_t idblk;
- if (idblk == NULL (idblk = malloc(sblock-fs_bsize)) == NULL)
+ if (idblks[ind_level] == NULL
+ (idblks[ind_level] = malloc(sblock-fs_bsize)) == NULL)
quit(dirindir: cannot allocate indirect memory.\n);
+ idblk = idblks[ind_level];
bread(fsbtodb(sblock, blkno), idblk, (int)sblock-fs_bsize);
if (ind_level = 0) {
for (i = 0; *filesize 0 i NINDIR(sblock); i++) {
@@ -501,10 +505,13 @@
dmpindir(ino_t ino, ufs2_daddr_t blk, int ind_level, off_t *size)
{
int i, cnt;
- static caddr_t idblk;
+ static caddr_t idblks[NIADDR];
+ caddr_t idblk;
- if (idblk == NULL (idblk = malloc(sblock-fs_bsize)) == NULL)
+ if (idblks[ind_level] == NULL
+ (idblks[ind_level] = malloc(sblock-fs_bsize)) == NULL)
quit(dmpindir: cannot allocate indirect memory.\n);
+ idblk = idblks[ind_level];
if (blk != 0)
bread(fsbtodb(sblock, blk), idblk, (int) sblock-fs_bsize);
else
To Unsubscribe: send mail to [EMAIL PROTECTED]
with unsubscribe freebsd-current in the body of the message
[] freebsd-current ? , !
Title: Çѱ¹°æÁ¦ ¸®Ä¡¿þÀÌ Å¬·´ ±ÍÇÏÀÇ ½Â¶ô¾øÀÌ È«º¸¼º ÀüÀÚ ¿ìÆíÀ» º¸³»°Ô µÈ Á¡ Á¤ÁßÈ÷ »ç°ú µå¸³´Ï´Ù. Á¤º¸Åë½Å¸ÁÀÌ¿ëÃËÁø¹ý ±ÔÁ¤À» ÁؼöÇÏ¿© ±¤°í¸ÞÀÏÀÓÀ» Ç¥½ÃÇÏ¿´À¸¸ç, ¼ö½Å°ÅºÎ ÀåÄ¡¸¦ ¸¶·ÃÇÏ°í ÀÖ½À´Ï´Ù. ±ÍÇÏÀÇ ÀüÀÚ ¿ìÆí ÁÖ¼Ò´Â ÀÎÅÍ³Ý »óÀÇ °ø°³µÈ Àå¼Ò¿¡¼ ½ÀµæÇÏ¿´À¸¸ç, ÀúÈñ´Â ±ÍÇÏÀÇ ÀüÀÚ¿ìÆí ÁÖ¼Ò ¿Ü ¾î¶°ÇÑ °³ÀÎÁ¤º¸µµ °¡Áö°í ÀÖÁö ¾ÊÀ¸¹Ç·Î ¾È½ÉÇϽñ⠹ٶø´Ï´Ù. ¼ö½ÅÀ» ¿øÄ¡ ¾ÊÀ¸½Ã¸é ¼ö½Å°ÅºÎ¸¦ Ŭ¸¯ÇØ Áֽʽÿä.
Re: dump(8) is hosed
On 7 Jul, Ian Dowse wrote: In message [EMAIL PROTECTED], Don Lewis writes: I was finally finally able to reproduce this by creating a large file before doing the dump. Dump(8) is *very* hosed. The UFS2 import broke it's ability to follow multiple levels of indirect blocks. Thanks for tracking this down! One thing is that the code was using the static pointers to avoid having to malloc and free blocks every time. Keeping an array of NIADDR pointers and using `ind_level' as the index is an alternative (patch below) - I doubt the performance difference is noticable but it avoids having to remember the free() before each return. Prior to the UFS2 import, the code used an automatic array on the stack, which was even cleaner. If you want to dynamically size the array and don't mind a potential portability problem you could use alloca(). The only time you'll take the performance hit is on large files, since the small ones won't have indirect blocks. To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-current in the body of the message
panic: lockmgr: locking against myself with yesterday's -CURRENT
I got the word about the changes to vfs_subr.c vfs_bio.c fixing the hang at shutdown for yesterday's -CURRENT fairly late in the day yesterday, and since the problem didn't seem (as far as I could tell) to affect normal operation, I figured I'd just pick up the change at the following update (which would be this morning). However, once I started the make -j8 buildworld on this SMP machine (this morning), I got a panic. Here's a cut-and-paste from the serial console: Recovering vi editor sessions:. Initial rc.i386 initialization:. Configuring syscons: blanktime. Additional ABI support:. Local package initiCalization:reating DISK md10 md10: invalid primary partition table: no magic md10: invalid primary partition table: no magic [1] 232 Floating point exception (core dumped) Jul 7 05:41:21 freebeast kernel: pid 232 (newfs), uid 0: exited on signal 8 (core dumped) apache cvsupd . Additional TCP options:. Starting background filesystem checks Sun Jul 7 05:41:23 PDT 2002 FreeBSD/i386 (freebeast.catwhisker.org) (cuaa0) login: panic: lockmgr: locking against myself cpuid = 0; lapic.id = Debugger(panic) Stopped at Debugger+0x46: xchgl %ebx,in_Debugger.0 db tr Debugger(c030085a) at Debugger+0x46 panic(c02fe680,7,0,ce6811c0,2010022) at panic+0xd6 lockmgr(ce6811c0,2010022,c0347060,c1584cc0) at lockmgr+0x36b BUF_TIMELOCK(ce681114,22,c03085c1,0,0) at BUF_TIMELOCK+0x62 getblk(c421a200,e44030,0,2000,0) at getblk+0x97 breadn(c421a200,e44030,0,2000,0) at breadn+0x2f bread(c421a200,e44030,0,2000,0,d69d7920) at bread+0x20 ffs_blkfree(c41ad800,c421a200,723f8e,0,400) at ffs_blkfree+0x2ba ffs_truncate(c469a300,0,0,0,0) at ffs_truncate+0xff5 ufs_inactive(d69d7bac,d69d7bc4,c01eecd1,d69d7bac,c03312c0) at ufs_inactive+0x8e ufs_vnoperate(d69d7bac) at ufs_vnoperate+0x13 vrele(c469a300,ce76ce60,c46a5258,d69d7bec,c029d4fd) at vrele+0xb1 vm_object_vndeallocate(c46a5258,ce76ce60,ce76ce60,d69d7bfc,c01ee0c6) at vm_object_vndeallocate+0x6e vm_object_deallocate(c46a5258,c09b5334,d69d7c14,c01e3673,ce76ce60) at vm_object_deallocate+0x35 brelvp(ce76ce60) at brelvp+0xd2 vfs_vmio_release(ce76ce60) at vfs_vmio_release+0x14f getnewbuf(0,0,2000,4000,200010a4) at getnewbuf+0x15e geteblk(2000,0,c02fe5e2,23b,ce681114) at geteblk+0x23 bwrite(ce681114,d69d7cb0,c0188a5d,ce681114,2710) at bwrite+0x126 bawrite(ce681114) at bawrite+0x14 spec_fsync(d69d7ce0,d69d7d1c,c01ee24a,d69d7ce0,3d2837b7) at spec_fsync+0xc9 spec_vnoperate(d69d7ce0,3d2837b7,c41ba200,c0331380,c41b6e00) at spec_vnoperate+0x13 sched_sync(0,d69d7d48,c1584cc0,c01ee154,0) at sched_sync+0xf6 fork_exit(c01ee154,0,d69d7d48) at fork_exit+0xa8 fork_trampoline() at fork_trampoline+0x37 db show pcpu 0 cpuid= 0 curthread= 0xc1584cc0: pid 7 syncer curpcb = 0xd69d7da0 fpcurthread = none idlethread = 0xc1583d80: pid 12 idle: cpu0 currentldt = 0x28 spin locks held: db show pcpu 1 cpuid= 1 curthread= 0xc1583e40: pid 11 idle: cpu1 curpcb = 0xd699eda0 fpcurthread = none idlethread = 0xc1583e40: pid 11 idle: cpu1 currentldt = 0x28 spin locks held: db show locks exclusive sleep mutex Giant r = 1 (0xc0340d00) locked @ /usr/src/sys/vm/vm_object.c:1721 db I'm going ahead and sending this in because it seems fairly different from the traceback that was reported for yesterday's hang, so there might be some other problem that is shows. I will go ahead and reboot, and upgrade the kernel first, then see how a make buildworld goes. Cheers, david -- David H. Wolfskill [EMAIL PROTECTED] Trying to support or use Microsoft products makes about as much sense as painting the outside of a house with watercolors. To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-current in the body of the message
Re: dump(8) is hosed
On Sat, 6 Jul 2002, Don Lewis wrote: For me it is broken in a different way. For a small FS like / it works, but dumping my /home, which is 4G, I get DUMP: read error from /dev/ad0s5e: Invalid argument: [sector -1054739789]: count=-1 DUMP: read error from /dev/ad0s5e: Invalid argument: [sector -1054739788]: count=-1 ... I'm not able to reproduce this here on a freshly built 11 GB filesystem. It only contains about 2 GB of data, but the data is fairly uniformly spread over all the cylinder groups. I'm running a version of -current built Fri Jul 5 13:07:05 PDT 2002, though I don't recall seeing any likely looking commits since the first report of this problem. This seems very similar to the dump() problem I reported a week ago. I've not been able to reproduce this on machines with a recent newfs; only on older disk which have been in use for a longer period of time and have filled up a few times. It may be some fragementation or splitting/following through of references which is the issue. When booting into a 4.1 cdrom; and then mounting the second cdrom with the full file system/fixit - a dump works fine. So it is almost certainly -CURRENT related. Dw. To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-current in the body of the message
Fatal double fault
Fatal double fault: eip = 0xc01f75ba esp = 0xcdcecff8 ebp = 0xcdced03c panic: double fault Debugger(panic) Stopped atDebugger+0x45:xchgl %ebx,in_Debugger.0 db trace Debugger(c02324bfc) at Debugger+0x45 panic(c034cf19,c034d445,cdced03c,0,0) at panic+0x74 dblfault_handler(c03aa510,c03aa598,c03aa620,0,0) at dblfault_handler+0x52 This happened, while I tried to recompile my kernel which tends to stop all tasks after a random uptime. In this state I can ^Z the task but am not able to start any new tasks from the shell, and have to power-switch the machine down. Any suggestions? Regards erdgeist - fnord! id 0x17B701E5 size 1024 | type rsa 11F8 8FF3 0508 09F9 DC6A 2AB3 AA67 C8CF To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-current in the body of the message
buildkernel error with ENABLE_VFS_IOOPT/ZERO_COPY_SOCKETS
Hi,
-current from today fails in kern/kern_subr.c:
../../../kern/kern_subr.c:220: warning: function declaration isn't a prototype
---snip---
#if defined(ENABLE_VFS_IOOPT) || defined(ZERO_COPY_SOCKETS)
/*
* Experimental support for zero-copy I/O
*/
static int
userspaceco(cp, cnt, uio, obj, disposable)
caddr_t cp;
u_int cnt;
struct uio *uio;
struct vm_object *obj;
int disposable;
{
---snip---
Bye,
Alexander.
--
Weird enough for government work.
http://www.Leidinger.net Alexander @ Leidinger.net
GPG fingerprint = C518 BC70 E67F 143F BE91 3365 79E2 9C60 B006 3FE7
To Unsubscribe: send mail to [EMAIL PROTECTED]
with unsubscribe freebsd-current in the body of the message
Re: i386 trap code
On Sat, Jul 06, 2002 at 11:59:50PM -0700, David Xu wrote: Jonthan, I just use DOS program as an example, for any program, if it wants to go into VM86 mode, it is very easy, just calls i386_vm86() to initailize its VM86 pcb extension, setups some memory area, then call sigreturn() to turn into VM86 mode. I think global in_vm86call flags is a bug under SMP, it creates a race condition. suppose this scenario: CPU A is running a simple VM86 code program. CPU B is running vm86_intcall() by some kernel driver (vesa module ?) CPU B set in_vm86call = 1 CPU A gets a fault trap. CPU A runs trap(), and find that in_vm86call is set and handles the trap as it is running vm86_intcall(), but it is not true and make a mess. Yes, as I mentioned earlier, the way the original vm86 bioscall worked was to prevent an AST until the BIOS was done. This relied on the giant lock for correctness, since we only allowed one CPU into the kernel at once. There probably needs to be some work done for -current in this area. -- Jonathan To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-current in the body of the message
floating point problems after update from a pre gcc3.1 world
Hi, I've updated to todays current from a -current as of May 1 and I get the following error from my mailer (tkrat 2.0.3, written in tcl/tk): ---snip--- expected floating-point number but got 0.045132 expected floating-point number but got 0.045132 while executing .f1.t.messlist.scroll set 0.045132 1 (vertical scrolling command executed by text) ---snip--- It doesn't crash, the only misbehaving I observe is: after deleting a mail it doesn't advance to the next available mail anymore (and pops up an error box with the above error). Any ideas what the reason is? Bye, Alexander. -- To boldly go where I surely don't belong. http://www.Leidinger.net Alexander @ Leidinger.net GPG fingerprint = C518 BC70 E67F 143F BE91 3365 79E2 9C60 B006 3FE7 To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-current in the body of the message
Mouse wheel.
I'm not sure if this is current releated or XFree releated, but I'm giving it a go here. I updated from -current Jun 27, to a Jul 07 version today, and since that fixed the problem with compiling XFree86-4-Server and libs, I recompiled those and upgraded those. (new'er port versions). Now my mouse wheel only works in one 'direction'. If I try to use the wheel, it looks like it emits the same signal, even if I move it up or down. (It scrolls down). It used to work before I did the upgrades, just cant figure out where the problem is.. (mwheel works correctly in other OS'es). -- Thomas Ugland - If everything is coming your way then you're in the wrong lane. - To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-current in the body of the message
top core dumps after update from a pre 3.1 system
Hi, I've updated to todays -current from a May 1 one. Now I get a core dump in top before it is able tp print the percentages for use, nice and so on. There are two paths to the core dump. First one: ---snip--- (gdb) bt #0 0x2807adc4 in _nc_memmove () from /usr/lib/libncurses.so.5 #1 0x2807b0ef in tgoto () from /usr/lib/libncurses.so.5 #2 0x0804a93a in free () #3 0x0804a3d7 in free () #4 0x0804cb38 in clear () #5 0x080492c0 in free () ---snip--- Next one: ---snip--- (gdb) bt #0 0x281472a0 in __vfprintf () from /usr/lib/libc.so.5 #1 0x281461f8 in __vfprintf () from /usr/lib/libc.so.5 #2 0x28139649 in sprintf () from /usr/lib/libc.so.5 #3 0x0804b2fa in free () #4 0x0804cb2d in clear () #5 0x080492c0 in free () ---snip--- Bye, Alexander. -- It is easier to fix Unix than to live with NT. http://www.Leidinger.net Alexander @ Leidinger.net GPG fingerprint = C518 BC70 E67F 143F BE91 3365 79E2 9C60 B006 3FE7 To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-current in the body of the message
Re: top core dumps after update from a pre 3.1 system
On 7 Jul, An: [EMAIL PROTECTED] wrote: I've updated to todays -current from a May 1 one. Now I get a core dump I hope it's clear that I forgot to put gcc in front of 3.1 in the subject... Bye, Alexander. -- Press every key to continue. http://www.Leidinger.net Alexander @ Leidinger.net GPG fingerprint = C518 BC70 E67F 143F BE91 3365 79E2 9C60 B006 3FE7 To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-current in the body of the message
Re: Mouse wheel.
On Sun, Jul 07, 2002 at 07:59:50PM +0200, Thomas Ugland wrote: I'm not sure if this is current releated or XFree releated, but I'm giving it a go here. I updated from -current Jun 27, to a Jul 07 version today, and since that fixed the problem with compiling XFree86-4-Server and libs, I recompiled those and upgraded those. (new'er port versions). Now my mouse wheel only works in one 'direction'. If I try to use the wheel, it looks like it emits the same signal, even if I move it up or down. (It scrolls down). It used to work before I did the upgrades, just cant figure out where the problem is.. (mwheel works correctly in other OS'es). This happened to me too, and I thought I was going crazy. When I disabled moused and let X talk directly to the mouse, the wheel worked correctly. When I turned on moused debugging, it showed that it was receiving the correct events from the mouse, so I can only assume that the problem is higher up. Scott To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-current in the body of the message
Re: KSE M-III status junior hacker project.
In message: [EMAIL PROTECTED] Josef Karthauser [EMAIL PROTECTED] writes: : I've absolutely no idea what's causing it, but I'm still having random reboots : of current after some uptime with no dumps. I'll install a new kernel : today and report back if it still happens. Maybe someone can help me to : track it down. I had similar problems when Julian first committed KSE III, but I've not had them since updating to more recent, and stable, kernels. Now I get random panics with core dumps :-) Warner To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-current in the body of the message
Re: KSE M-III status junior hacker project.
On 2002-07-07 11:46 +, Josef Karthauser wrote: I've absolutely no idea what's causing it, but I'm still having random reboots of current after some uptime with no dumps. I'll install a new kernel today and report back if it still happens. Maybe someone can help me to track it down. Same happens to me, in addition the file systems aren't unmounted cleanly even if I manually shut down the machine. I built world with sources from around 11:30PM EST yesterday, and so far I've had only one random reboot (so I guess it's 'partly fixed'), as opposed to one every hour on average. I only caught something useful on one of the reboots as I was hanging around the console for a while: panic: lockmgr: draining against myself syncing disks... panic: bwrite: buffer is not busy ??? This was before my latest world/kernel. I'm about to build world again in the hope that something has fixed it. I'm assuming that my initial worries that KSE was causing this may be wrong and it's the vfs changes that have been going in lately (correct me if I'm way off here). -- Munish Chopra The FreeBSD NVIDIA Driver Initiative http://nvidia.netexplorer.org To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-current in the body of the message
Re: dump(8) is hosed
On Sun, Jul 07, 2002 at 12:27:31PM +0100, Ian Dowse wrote: I'll commit your printf format changes first anyway - thanks! Just to make sure, you're not going to fix the problem dump problem; just fix the bad screen output. Correct? Since I've got a very reproduceable test case; I wanted to test the commit candidate to make sure we totally nab this bug now. To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-current in the body of the message
Re: panic: lockmgr: locking against myself with yesterday's -CURRENT
On 2002-07-07 06:01 +, David Wolfskill wrote: I got the word about the changes to vfs_subr.c vfs_bio.c fixing the hang at shutdown for yesterday's -CURRENT fairly late in the day yesterday, and since the problem didn't seem (as far as I could tell) to affect normal operation, I figured I'd just pick up the change at the following update (which would be this morning). However, once I started the make -j8 buildworld on this SMP machine (this morning), I got a panic. Here's a cut-and-paste from the serial console: Recovering vi editor sessions:. Initial rc.i386 initialization:. Configuring syscons: blanktime. Additional ABI support:. Local package initiCalization:reating DISK md10 md10: invalid primary partition table: no magic md10: invalid primary partition table: no magic [1] 232 Floating point exception (core dumped) Jul 7 05:41:21 freebeast kernel: pid 232 (newfs), uid 0: exited on signal 8 (core dumped) apache cvsupd . Additional TCP options:. Starting background filesystem checks Sun Jul 7 05:41:23 PDT 2002 FreeBSD/i386 (freebeast.catwhisker.org) (cuaa0) login: panic: lockmgr: locking against myself This is exactly what's showing up for me (and possibly others) in the KSE M-III status junior hacker project. thread. I'm currently building world too (this is a UP machine btw.), I guess we'll see if the most recent commits change this. -- Munish Chopra The FreeBSD NVIDIA Driver Initiative http://nvidia.netexplorer.org To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-current in the body of the message
Re: 5.0 DP2 (was Re: KSE M-III status junior hacker project.)
hopefully some of the new work that will be done on kse can be done
on the mainline now without breaking nonKSE activities..
in other words, most of the real it breaks current behaviour
changes have been passed for a while so new code can be off in
if (KSE_mode) { }
clauses that will have no effect on normal usage.
I think that as far as KSE is concerned, you could branch pretty much any
time now..
If there turn out to be problems that we fix they can always be merged
over later.
On Sun, 7 Jul 2002, Murray Stokely wrote:
On Sat, Jul 06, 2002 at 04:57:08PM -0700, Julian Elischer wrote:
Well with various hints from here and there I have fixed
the ^Z/fg problem (at least it seems fixed to me and others that
have tested) This basically leaves only one outstanding
problem that I know of which is a problem that Warner has with a
particular progam. (This may also be fixed but I don't know)
Hi Julian,
Thanks for your progress on KSE! How long should we wait before
branching in Perforce for 5.0 DP2? I would like to give at least 10
more days for this and other changes to settle before making the
branch. If all goes well, I would like to release 5.0 DP2 at the end
of this month.
- Murray
To Unsubscribe: send mail to [EMAIL PROTECTED]
with unsubscribe freebsd-current in the body of the message
Re: Mouse wheel.
On Sun, 2002-07-07 at 20:10, Scott Long wrote: On Sun, Jul 07, 2002 at 07:59:50PM +0200, Thomas Ugland wrote: I'm not sure if this is current releated or XFree releated, but I'm giving it a go here. I updated from -current Jun 27, to a Jul 07 version today, and since that fixed the problem with compiling XFree86-4-Server and libs, I recompiled those and upgraded those. (new'er port versions). Now my mouse wheel only works in one 'direction'. If I try to use the wheel, it looks like it emits the same signal, even if I move it up or down. (It scrolls down). It used to work before I did the upgrades, just cant figure out where the problem is.. (mwheel works correctly in other OS'es). This happened to me too, and I thought I was going crazy. When I disabled moused and let X talk directly to the mouse, the wheel worked correctly. When I turned on moused debugging, it showed that it was receiving the correct events from the mouse, so I can only assume that the problem is higher up. I don't use the mouse daemon normally, but tried it out to see if it would work while using it. But I still had the same problem, so I'm stuck with the half functioning mouse wheel :) -- Thomas Ugland - If everything is coming your way then you're in the wrong lane. - To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-current in the body of the message
Re: Mouse wheel.
On Sun, 07 Jul 2002, Thomas Ugland wrote: On Sun, 2002-07-07 at 20:10, Scott Long wrote: On Sun, Jul 07, 2002 at 07:59:50PM +0200, Thomas Ugland wrote: I'm not sure if this is current releated or XFree releated, but I'm giving it a go here. I updated from -current Jun 27, to a Jul 07 version today, and since that fixed the problem with compiling XFree86-4-Server and libs, I recompiled those and upgraded those. (new'er port versions). Now my mouse wheel only works in one 'direction'. If I try to use the wheel, it looks like it emits the same signal, even if I move it up or down. (It scrolls down). It used to work before I did the upgrades, just cant figure out where the problem is.. (mwheel works correctly in other OS'es). This happened to me too, and I thought I was going crazy. When I disabled moused and let X talk directly to the mouse, the wheel worked correctly. When I turned on moused debugging, it showed that it was receiving the correct events from the mouse, so I can only assume that the problem is higher up. I don't use the mouse daemon normally, but tried it out to see if it would work while using it. But I still had the same problem, so I'm stuck with the half functioning mouse wheel :) Not sure if it will work for you, but I should use '-z 4 5' with moused to overcome this problem. Ciao, - yann. To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-current in the body of the message
Re: top core dumps after update from a pre 3.1 system
On 7 Jul, An: [EMAIL PROTECTED] wrote: I've updated to todays -current from a May 1 one. Now I get a core dump in top before it is able tp print the percentages for use, nice and so on. There are two paths to the core dump. PR 40209 is also responsible for this problem. Bye, Alexander. -- ...and that is how we know the Earth to be banana-shaped. http://www.Leidinger.net Alexander @ Leidinger.net GPG fingerprint = C518 BC70 E67F 143F BE91 3365 79E2 9C60 B006 3FE7 To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-current in the body of the message
Re: Mouse wheel.
On 7 Jul, Scott Long wrote: [mwheel not working correctly] This happened to me too, and I thought I was going crazy. When I disabled moused and let X talk directly to the mouse, the wheel worked correctly. When I turned on moused debugging, it showed that it was receiving the correct events from the mouse, so I can only assume that the problem is higher up. Wild guess: Any change libc is compiled with higher optimizations (PR 40209)? Bye, Alexander. -- ...and that is how we know the Earth to be banana-shaped. http://www.Leidinger.net Alexander @ Leidinger.net GPG fingerprint = C518 BC70 E67F 143F BE91 3365 79E2 9C60 B006 3FE7 To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-current in the body of the message
problems with natd, ipfw
Hello everybody, I upgraded to yesterday's -CURRENT and have made a few observations: 1) The natd does not work. This is known, but I have tracked it to its interaction with libalias, which means that any program that uses libalias functions is also affected (and indeed, ppp(8)'s -nat option does not work either). If I downgrade the file src/sys/netinet/ip_fw.h to the version from June 27, and recompile libalias and natd, things will work. 2) and much more alarmingly: Although the new ipfw really seems to process the ruleset faster, some rules appear to do nothing! I have a default-to-deny setup, so theoretically this should mean that I should be cut off from the net if the allow rules do not work. And indeed, flushing all rules gives the expected behaviour. But as soon as I load the ruleset file (which is the same as previously and then it worked as expected) the fw becomes wide-open, the only rules that appear to work are the divert for natd, and the allow rules. But the deny rules do nothing, it seems that even the catch-all implicit deny rule at the bottom does nothing. Am I going insane, or is this real? Also, I have observed that when loading the rules from the ruleset file, ipfw prints two lines for each, one with the expected rule number and one with all zeros. I don't know if it's significant though. It is like this: 0 deny log ip from any to any 03600 deny log ip from any to any This did not happen previously... -- Regards: Szilveszter ADAM Szombathely Hungary To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-current in the body of the message
Re: problems with natd, ipfw
On Sun, Jul 07, 2002 at 11:35:46PM +0200, Szilveszter Adam wrote: Hello everybody, I upgraded to yesterday's -CURRENT and have made a few observations: 2) and much more alarmingly: Although the new ipfw really seems to process the ruleset faster, some rules appear to do nothing! I have a default-to-deny setup, so theoretically this should mean that I should be cut off from the net if the allow rules do not work. And indeed, flushing all rules gives the expected behaviour. But as soon as I load the ruleset file (which is the same as previously and then it worked as expected) the fw becomes wide-open, the only rules that appear to work are the divert for natd, and the allow rules. But the deny rules do nothing, it seems that even the catch-all implicit deny rule at the bottom does nothing. Am I going insane, or is this real? Don't know. But, I do know that logging seemed to be messed up. My old ruleset only logged a few rules, and after upgrading I seemed to get a log entry for every packet. It was so overwhelming that I didn't even try to analyze it. Since I needed natd on the machine in question, I just reverted all the new ipfw code, and haven't spent much time at it. Also, I have observed that when loading the rules from the ruleset file, ipfw prints two lines for each, one with the expected rule number and one with all zeros. I don't know if it's significant though. It is like this: 0 deny log ip from any to any 03600 deny log ip from any to any Yes, I saw this. However, 'ipfw l' doesn't include a 0 rule, and the rule list appears correct. -- Richard Seaman, Jr.email:[EMAIL PROTECTED] 5182 N. Maple Lane phone:262-367-5450 Nashotah WI 53058fax:262-367-5852 To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-current in the body of the message
Re: problems with natd, ipfw
On Sun, Jul 07, 2002 at 04:45:52PM -0500, Richard Seaman, Jr. wrote: On Sun, Jul 07, 2002 at 11:35:46PM +0200, Szilveszter Adam wrote: Hello everybody, I upgraded to yesterday's -CURRENT and have made a few observations: 2) and much more alarmingly: Although the new ipfw really seems to process the ruleset faster, some rules appear to do nothing! I have a default-to-deny setup, so theoretically this should mean that I should be cut off from the net if the allow rules do not work. And indeed, flushing all rules gives the expected behaviour. But as soon as I load the ruleset file (which is the same as previously and then it worked as expected) the fw becomes wide-open, the only rules that appear to work are the divert for natd, and the allow rules. But the deny rules do nothing, it seems that even the catch-all implicit deny rule at the bottom does nothing. Am I going insane, or is this real? Don't know. But, I do know that logging seemed to be messed up. My old ruleset only logged a few rules, and after upgrading I seemed to get a log entry for every packet. It was so overwhelming that I didn't even try to analyze it. Since I needed natd on the machine in question, I just reverted all the new ipfw code, and haven't spent much time at it. I just went back to the old log files, and based on a spot check, the log files do indeed record as accepted packets that should have been denied by the ruleset (and which are currently denied without logging using the same ruleset and the old ipfw). -- Richard Seaman, Jr.email:[EMAIL PROTECTED] 5182 N. Maple Lane phone:262-367-5450 Nashotah WI 53058fax:262-367-5852 To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-current in the body of the message
benign bug in src/sys/kern/kern_resource.c:limcopy() ?
Hello folks, The limcopy() function bcopy()s a struct rlimit, but the len argument to bcopy() is given as sizeof(struct plimit). This hasn't caused any problems so far because the destination address is the first member of struct plimit and all the other member of plimit are initialized immediately thereafter. The patch follows. Cheers, Mike Makonnen Index: sys/kern/kern_resource.c === RCS file: /home/ncvs/src/sys/kern/kern_resource.c,v retrieving revision 1.106 diff -u -r1.106 kern_resource.c --- sys/kern/kern_resource.c29 Jun 2002 02:00:01 - 1.106 +++ sys/kern/kern_resource.c7 Jul 2002 22:01:54 - @@ -811,7 +811,7 @@ MALLOC(copy, struct plimit *, sizeof(struct plimit), M_SUBPROC, M_WAITOK); - bcopy(lim-pl_rlimit, copy-pl_rlimit, sizeof(struct plimit)); + bcopy(lim-pl_rlimit, copy-pl_rlimit, sizeof(struct rlimit)); copy-p_lflags = 0; copy-p_refcnt = 1; return (copy); To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-current in the body of the message
Re: cvs commit: src/sys/tools vnode_if.awk
On Sun, 7 Jul 2002, Don Lewis wrote: It wasn't able to sucessfully boot with this enabled. I'm hand transcribing this, so apologies for any typos: [snip] Debugger(c0420fe4) at Debugger+0x45 vn_rdwr(0,c6737800,c6425000,55ac,0,0,1,8,c22c7200,df241aec,c22cc0c0) at vn_rdwr+0x18d linker_hints_lookup(c04750a0,c,c62df000,5,0) at linker_hints_lookup+0x2d9 linker_search_module(c62df000,5,0,0,c0415120) at linker_search_module+0x43 linker_load_module(0,c62df000,0,0,df241cdc) at linker_load_module+0x72 kldload(c22cc0c0,df241d14,1,0,296) at kldload+0xc3 syscall(...) Revision 1.91 of kern_linker.c fixes this problem. Can you try again? Thanks! Jeff To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-current in the body of the message
pipe mutex vs. sigio lock lock order reversal
This error showed up in my logs this morning while I was building some
ports on a uni-processor box. I'm running a version of -current from
July 7 about 1 AM PDT.
Jul 7 07:47:09 scratch kernel: lock order reversal
Jul 7 07:47:09 scratch kernel: 1st 0xcabf7980 pipe mutex (pipe mutex) @
/usr/src/sys/kern/sys_pipe.c:451
Jul 7 07:47:09 scratch kernel: 2nd 0xc0474300 sigio lock (sigio lock) @
/usr/src/sys/kern/kern_sig.c:2113
I don't understand all the new locking stuff in -current, but it looks
to me like maybe there should be a PIPE_UNLOCK()/PIPE_LOCK() wrapper
around the following code in sys_pipe.c since a SIGIO could happen
during the msleep().
/*
* Handle non-blocking mode operation or
* wait for more data.
*/
if (fp-f_flag FNONBLOCK) {
error = EAGAIN;
} else {
rpipe-pipe_state |= PIPE_WANTR;
if ((error = msleep(rpipe, PIPE_MTX(rpipe),
PRIBIO | PCATCH,
piperd, 0)) == 0)
error = pipelock(rpipe, 1);
}
if (error)
goto unlocked_error;
I don't see a way for the locks to be asserted in the opposite order,
though I suppose there might be a case of PROC_LOCK() followed by
PIPE_LOCK() that would conflict with SIGIO_LOCK() followed by
PROC_LOCK().
To Unsubscribe: send mail to [EMAIL PROTECTED]
with unsubscribe freebsd-current in the body of the message
ppp sig10's in current
Just thought I'd throw in some more bad news :-). ppp in current core dumps on me. It starts up in ddial mode ok, does its job for a while, and then dies. I tried starting it again, and it just sat there instead of going into the background and returning the prompt, leaving me with no recourse but to ^c it. My latest buildworld: FreeBSD 5.0-CURRENT FreeBSD 5.0-CURRENT #2: Sun Jul 7 13:26:22 EDT 2002 I've got the core dump handy. Here's the log: Jul 7 13:36:04 ppp[179]: Phase: Received NGM_PPPOE_ACNAME (hook RES-ESR-DSL1) Jul 7 13:36:05 ppp[179]: Phase: Received NGM_PPPOE_SESSIONID Jul 7 13:36:05 ppp[179]: Phase: Received NGM_PPPOE_SUCCESS Jul 7 13:36:05 ppp[179]: Phase: deflink: carrier - login Jul 7 13:36:05 ppp[179]: Phase: deflink: login - lcp Jul 7 13:36:05 ppp[179]: LCP: FSM: Using deflink as a transport Jul 7 13:36:05 ppp[179]: LCP: deflink: State change Initial -- Closed Jul 7 13:36:05 ppp[179]: LCP: deflink: State change Closed -- Stopped Jul 7 13:36:05 ppp[179]: LCP: deflink: RecvConfigReq(1) state = Stopped Jul 7 13:36:05 ppp[179]: LCP: MRU[4] 1492 Jul 7 13:36:05 ppp[179]: LCP: AUTHPROTO[4] 0xc023 (PAP) Jul 7 13:36:05 ppp[179]: LCP: MAGICNUM[6] 0x64cb56b4 Jul 7 13:36:05 ppp[179]: LCP: deflink: SendConfigReq(1) state = Stopped Jul 7 13:36:05 ppp[179]: LCP: MRU[4] 1492 Jul 7 13:36:05 ppp[179]: LCP: MAGICNUM[6] 0xc140bb73 Jul 7 13:36:05 ppp[179]: LCP: QUALPROTO[8] proto c025, interval 3ms Jul 7 13:36:05 ppp[179]: LCP: deflink: SendConfigAck(1) state = Stopped Jul 7 13:36:05 ppp[179]: LCP: MRU[4] 1492 Jul 7 13:36:05 ppp[179]: LCP: AUTHPROTO[4] 0xc023 (PAP) Jul 7 13:36:05 ppp[179]: LCP: MAGICNUM[6] 0x64cb56b4 Jul 7 13:36:05 ppp[179]: LCP: deflink: LayerStart Jul 7 13:36:05 ppp[179]: LCP: deflink: State change Stopped -- Ack-Sent Jul 7 13:36:05 ppp[179]: LCP: deflink: RecvConfigAck(1) state = Ack-Sent Jul 7 13:36:05 ppp[179]: LCP: MRU[4] 1492 Jul 7 13:36:05 ppp[179]: LCP: MAGICNUM[6] 0xc140bb73 Jul 7 13:36:05 ppp[179]: LCP: QUALPROTO[8] proto c025, interval 3ms Jul 7 13:36:05 ppp[179]: LCP: deflink: State change Ack-Sent -- Opened Jul 7 13:36:05 ppp[179]: LCP: deflink: LayerUp Jul 7 13:36:05 ppp[179]: Phase: bundle: Authenticate Jul 7 13:36:05 ppp[179]: Phase: deflink: his = PAP, mine = none Jul 7 13:36:05 ppp[179]: Phase: Pap Output: Jul 7 13:36:05 ppp[179]: Phase: Pap Input: SUCCESS () Jul 7 13:36:05 ppp[179]: Phase: deflink: lcp - open Jul 7 13:36:05 ppp[179]: Phase: bundle: Network Jul 7 13:36:05 ppp[179]: IPCP: FSM: Using deflink as a transport Jul 7 13:36:05 ppp[179]: IPCP: deflink: State change Initial -- Closed Jul 7 13:36:05 ppp[179]: IPCP: deflink: LayerStart. Jul 7 13:36:05 ppp[179]: IPCP: deflink: SendConfigReq(1) state = Closed Jul 7 13:36:05 ppp[179]: IPCP: IPADDR[6] 10.10.10.9 Jul 7 13:36:05 ppp[179]: IPCP: COMPPROTO[6] 16 VJ slots with slot compression Jul 7 13:36:05 ppp[179]: IPCP: deflink: State change Closed -- Req-Sent Jul 7 13:36:05 ppp[179]: IPCP: deflink: RecvConfigReq(1) state = Req-Sent Jul 7 13:36:05 ppp[179]: IPCP: IPADDR[6] 10.1.61.1 Jul 7 13:36:05 ppp[179]: IPCP: deflink: SendConfigAck(1) state = Req-Sent Jul 7 13:36:05 ppp[179]: IPCP: IPADDR[6] 10.1.61.1 Jul 7 13:36:05 ppp[179]: IPCP: deflink: State change Req-Sent -- Ack-Sent Jul 7 13:36:05 ppp[179]: LCP: deflink: RecvProtocolRej(2) state = Opened Jul 7 13:36:05 ppp[179]: LCP: deflink: -- Protocol 0x80fd (Compression Control Protocol) was rejected! Jul 7 13:36:05 ppp[179]: IPCP: deflink: RecvConfigRej(1) state = Ack-Sent Jul 7 13:36:05 ppp[179]: IPCP: COMPPROTO[6] 16 VJ slots with slot compression Jul 7 13:36:05 ppp[179]: IPCP: deflink: SendConfigReq(2) state = Ack-Sent Jul 7 13:36:05 ppp[179]: IPCP: IPADDR[6] 10.10.10.9 Jul 7 13:36:05 ppp[179]: IPCP: deflink: RecvConfigNak(2) state = Ack-Sent Jul 7 13:36:05 ppp[179]: IPCP: IPADDR[6] 138.88.18.7 Jul 7 13:36:05 ppp[179]: IPCP: IPADDR[6] changing address: 10.10.10.9 -- 138.88.18.7 Jul 7 13:36:05 ppp[179]: IPCP: deflink: SendConfigReq(3) state = Ack-Sent Jul 7 13:36:05 ppp[179]: IPCP: IPADDR[6] 138.88.18.7 Jul 7 13:36:05 ppp[179]: IPCP: deflink: RecvConfigAck(3) state = Ack-Sent Jul 7 13:36:05 ppp[179]: IPCP: IPADDR[6] 138.88.18.7 Jul 7 13:36:05 ppp[179]: IPCP: deflink: State change Ack-Sent -- Opened Jul 7 13:36:05 ppp[179]: IPCP: deflink: LayerUp. Jul 7 13:36:05 ppp[179]: IPCP: myaddr 138.88.18.7 hisaddr = 10.1.61.1 Jul 7 13:36:06 ppp[179]: LCP: deflink: RecvEchoRequest(1) state = Opened Jul 7 13:36:06 ppp[179]: LCP: deflink: SendEchoReply(1) state = Opened Jul 7 13:36:39 ppp[179]: LCP: deflink: RecvEchoRequest(2) state = Opened Jul 7 13:36:39 ppp[179]: LCP: deflink: SendEchoReply(2) state = Opened Jul 7 13:37:12 ppp[179]: LCP: deflink: RecvEchoRequest(3) state = Opened Jul 7 13:37:12 ppp[179]: LCP: deflink: SendEchoReply(3)
[] current ? , !
Title: Çѱ¹°æÁ¦ ¸®Ä¡¿þÀÌ Å¬·´ ±ÍÇÏÀÇ ½Â¶ô¾øÀÌ È«º¸¼º ÀüÀÚ ¿ìÆíÀ» º¸³»°Ô µÈ Á¡ Á¤ÁßÈ÷ »ç°ú µå¸³´Ï´Ù. Á¤º¸Åë½Å¸ÁÀÌ¿ëÃËÁø¹ý ±ÔÁ¤À» ÁؼöÇÏ¿© ±¤°í¸ÞÀÏÀÓÀ» Ç¥½ÃÇÏ¿´À¸¸ç, ¼ö½Å°ÅºÎ ÀåÄ¡¸¦ ¸¶·ÃÇÏ°í ÀÖ½À´Ï´Ù. ±ÍÇÏÀÇ ÀüÀÚ ¿ìÆí ÁÖ¼Ò´Â ÀÎÅÍ³Ý »óÀÇ °ø°³µÈ Àå¼Ò¿¡¼ ½ÀµæÇÏ¿´À¸¸ç, ÀúÈñ´Â ±ÍÇÏÀÇ ÀüÀÚ¿ìÆí ÁÖ¼Ò ¿Ü ¾î¶°ÇÑ °³ÀÎÁ¤º¸µµ °¡Áö°í ÀÖÁö ¾ÊÀ¸¹Ç·Î ¾È½ÉÇϽñ⠹ٶø´Ï´Ù. ¼ö½ÅÀ» ¿øÄ¡ ¾ÊÀ¸½Ã¸é ¼ö½Å°ÅºÎ¸¦ Ŭ¸¯ÇØ Áֽʽÿä.
ps fails to build with -Werror
This should be lots of fun for someone to fix ... === bin/ps cc -O -pipe -DLAZY_PS -Werror -Wall -Wno-format-y2k -Wno-uninitialized -Wformat=2 -Wno-format-extra-args -Werror -c /usr/src/bin/ps/fmt.c cc -O -pipe -DLAZY_PS -Werror -Wall -Wno-format-y2k -Wno-uninitialized -Wformat=2 -Wno-format-extra-args -Werror -c /usr/src/bin/ps/keyword.c cc -O -pipe -DLAZY_PS -Werror -Wall -Wno-format-y2k -Wno-uninitialized -Wformat=2 -Wno-format-extra-args -Werror -c /usr/src/bin/ps/nlist.c cc -O -pipe -DLAZY_PS -Werror -Wall -Wno-format-y2k -Wno-uninitialized -Wformat=2 -Wno-format-extra-args -Werror -c /usr/src/bin/ps/print.c cc1: warnings being treated as errors /usr/src/bin/ps/print.c: In function `started': /usr/src/bin/ps/print.c:400: warning: `%y' yields only last 2 digits of year /usr/src/bin/ps/print.c: In function `lstarted': /usr/src/bin/ps/print.c:417: warning: `%c' yields only last 2 digits of year in some locales on non-BSD systems /usr/src/bin/ps/print.c: In function `printval': /usr/src/bin/ps/print.c:686: warning: format not a string literal, argument types not checked /usr/src/bin/ps/print.c:689: warning: format not a string literal, argument types not checked /usr/src/bin/ps/print.c:692: warning: format not a string literal, argument types not checked /usr/src/bin/ps/print.c:695: warning: format not a string literal, argument types not checked /usr/src/bin/ps/print.c:698: warning: format not a string literal, argument types not checked /usr/src/bin/ps/print.c:701: warning: format not a string literal, argument types not checked /usr/src/bin/ps/print.c:704: warning: format not a string literal, argument types not checked /usr/src/bin/ps/print.c:707: warning: format not a string literal, argument types not checked /usr/src/bin/ps/print.c:710: warning: format not a string literal, argument types not checked *** Error code 1 Stop in /usr/src/bin/ps. To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-current in the body of the message
dev_t semantics
I am using dev-si_drv1 to store my softc (as are other drivers). What guarantees do I have about multiple opens/closes not stepping on each other's toes? How does -stable compare to -current in this regard? Thanks, Nate To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-current in the body of the message
Re: buildkernel error with ENABLE_VFS_IOOPT/ZERO_COPY_SOCKETS
On Mon, Jul 08, 2002 at 07:52:22 +1000, Bruce Evans wrote:
On Sun, 7 Jul 2002, Alexander Leidinger wrote:
-current from today fails in kern/kern_subr.c:
../../../kern/kern_subr.c:220: warning: function declaration isn't a prototype
---snip---
#if defined(ENABLE_VFS_IOOPT) || defined(ZERO_COPY_SOCKETS)
/*
* Experimental support for zero-copy I/O
*/
static int
userspaceco(cp, cnt, uio, obj, disposable)
caddr_t cp;
u_int cnt;
struct uio *uio;
struct vm_object *obj;
int disposable;
{
---snip---
This happens when ENABLE_VFS_IOOPT is configured by ZERO_COPY_SOCKETS is
not configured.
I don't like the #includes and declarations being in an unusual order
just to avoid ifdefs.
The attached patch should fix both issues.
Let me know whether this fixes it for you.
Ken
--
Kenneth Merry
[EMAIL PROTECTED]
//depot/FreeBSD-zero/src/sys/kern/kern_subr.c#15 -
/usr/home/ken/perforce/FreeBSD-zero/src/sys/kern/kern_subr.c
*** /tmp/tmp.40864.0Sun Jul 7 20:44:13 2002
--- /usr/home/ken/perforce/FreeBSD-zero/src/sys/kern/kern_subr.cSun Jul 7
20:43:57 2002
***
*** 56,87
#include vm/vm.h
#include vm/vm_page.h
#include vm/vm_map.h
SYSCTL_INT(_kern, KERN_IOV_MAX, iov_max, CTLFLAG_RD, NULL, UIO_MAXIOV,
Maximum number of elements in an I/O vector; sysconf(_SC_IOV_MAX));
! #ifdef ZERO_COPY_SOCKETS
! #include vm/vm.h
! #include vm/vm_param.h
! #include sys/lock.h
! #include vm/pmap.h
! #include vm/vm_map.h
! #include vm/vm_page.h
! #include vm/vm_object.h
! #include vm/vm_pager.h
! #include vm/vm_kern.h
! #include vm/vm_extern.h
! #include vm/swap_pager.h
! #include sys/mbuf.h
! #include machine/cpu.h
/* Declared in uipc_socket.c */
extern int so_zero_copy_receive;
static int vm_pgmoveco(vm_map_t mapa, vm_object_t srcobj, vm_offset_t kaddr,
vm_offset_t uaddr);
- static int userspaceco(caddr_t cp, u_int cnt, struct uio *uio,
- struct vm_object *obj, int disposable);
static int
vm_pgmoveco(mapa, srcobj, kaddr, uaddr)
--- 56,82
#include vm/vm.h
#include vm/vm_page.h
#include vm/vm_map.h
+ #ifdef ZERO_COPY_SOCKETS
+ #include vm/vm_param.h
+ #endif /* ZERO_COPY_SOCKETS */
+ #if defined(ZERO_COPY_SOCKETS) || defined(ENABLE_VFS_IOOPT)
+ #include vm/vm_object.h
+ #endif
SYSCTL_INT(_kern, KERN_IOV_MAX, iov_max, CTLFLAG_RD, NULL, UIO_MAXIOV,
Maximum number of elements in an I/O vector; sysconf(_SC_IOV_MAX));
! #if defined(ZERO_COPY_SOCKETS) || defined(ENABLE_VFS_IOOPT)
! static int userspaceco(caddr_t cp, u_int cnt, struct uio *uio,
! struct vm_object *obj, int disposable);
! #endif /* ZERO_COPY_SOCKETS || ENABLE_VFS_IOOPT */
+ #ifdef ZERO_COPY_SOCKETS
/* Declared in uipc_socket.c */
extern int so_zero_copy_receive;
static int vm_pgmoveco(vm_map_t mapa, vm_object_t srcobj, vm_offset_t kaddr,
vm_offset_t uaddr);
static int
vm_pgmoveco(mapa, srcobj, kaddr, uaddr)
current.freebsd.org
is that machine dead? Is it still the source of current snaps? I need to re-install (having booting problems between old version of FreeBSD and new one, easiest fix is just to re-install) and I want to know where to go for a snap of current. Anyone got one? Chuck Robey | Interests include C Java programming, FreeBSD, [EMAIL PROTECTED] | electronics, communications, and signal processing. New Year's Resolution: I will not sphroxify gullible people into looking up fictitious words in the dictionary. To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-current in the body of the message
Re: current.freebsd.org
On Sun, Jul 07, 2002 at 11:28:30PM -0400, Chuck Robey wrote: is that machine dead? Is it still the source of current snaps? I need to re-install (having booting problems between old version of FreeBSD and new one, easiest fix is just to re-install) and I want to know where to go for a snap of current. Anyone got one? Have you tried the jp site? It should be on the list of the ftp sites from sysinstall. Last I checked you could ftp install via ftp from the jp site that hosted the latest snaps. -- David W. Chapman Jr. [EMAIL PROTECTED] Raintree Network Services, Inc. www.inethouston.net [EMAIL PROTECTED] FreeBSD Committer www.FreeBSD.org To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-current in the body of the message
Re: current.freebsd.org
On Sun, 7 Jul 2002, David W. Chapman Jr. wrote: On Sun, Jul 07, 2002 at 11:28:30PM -0400, Chuck Robey wrote: is that machine dead? Is it still the source of current snaps? I need to re-install (having booting problems between old version of FreeBSD and new one, easiest fix is just to re-install) and I want to know where to go for a snap of current. Anyone got one? Have you tried the jp site? It should be on the list of the ftp sites from sysinstall. Last I checked you could ftp install via ftp from the jp site that hosted the latest snaps. Nope. I checked ftp,ftp2, and ftp3.jp.freebsd.org, and the best they had was a copy of the old 5.0DP1 release. That's months old now, I don't want to install that unless I must. Chuck Robey | Interests include C Java programming, FreeBSD, [EMAIL PROTECTED] | electronics, communications, and signal processing. New Year's Resolution: I will not sphroxify gullible people into looking up fictitious words in the dictionary. To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-current in the body of the message
Re: current.freebsd.org
On Sun, Jul 07, 2002 at 11:48:47PM -0400, Chuck Robey wrote: On Sun, 7 Jul 2002, David W. Chapman Jr. wrote: On Sun, Jul 07, 2002 at 11:28:30PM -0400, Chuck Robey wrote: is that machine dead? Is it still the source of current snaps? I need to re-install (having booting problems between old version of FreeBSD and new one, easiest fix is just to re-install) and I want to know where to go for a snap of current. Anyone got one? Have you tried the jp site? It should be on the list of the ftp sites from sysinstall. Last I checked you could ftp install via ftp from the jp site that hosted the latest snaps. Nope. I checked ftp,ftp2, and ftp3.jp.freebsd.org, and the best they had was a copy of the old 5.0DP1 release. That's months old now, I don't want to install that unless I must. try snapshots.jp.freebsd.org -garrett -- garrett rooneyRemember, any design flaw you're [EMAIL PROTECTED] sufficiently snide about becomes http://electricjellyfish.net/ a feature. -- Dan Sugalski To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-current in the body of the message
i386 tinderbox failure
-- Rebuilding the temporary build tree -- stage 1: bootstrap tools -- stage 2: cleaning up the object tree -- stage 2: rebuilding the object tree -- stage 2: build tools -- stage 3: cross tools -- stage 4: populating /home/des/tinderbox/i386/obj/local0/scratch/des/src/i386/usr/include -- stage 4: building libraries -- stage 4: make dependencies -- stage 4: building everything.. -- === bin/ps ... /local0/scratch/des/src/bin/ps/print.c: In function `printval': /local0/scratch/des/src/bin/ps/print.c:686: warning: format not a string literal, argument types not checked /local0/scratch/des/src/bin/ps/print.c:689: warning: format not a string literal, argument types not checked /local0/scratch/des/src/bin/ps/print.c:692: warning: format not a string literal, argument types not checked /local0/scratch/des/src/bin/ps/print.c:695: warning: format not a string literal, argument types not checked /local0/scratch/des/src/bin/ps/print.c:698: warning: format not a string literal, argument types not checked /local0/scratch/des/src/bin/ps/print.c:701: warning: format not a string literal, argument types not checked /local0/scratch/des/src/bin/ps/print.c:704: warning: format not a string literal, argument types not checked /local0/scratch/des/src/bin/ps/print.c:707: warning: format not a string literal, argument types not checked /local0/scratch/des/src/bin/ps/print.c:710: warning: format not a string literal, argument types not checked *** Error code 1 Stop in /local0/scratch/des/src/bin/ps. *** Error code 1 Stop in /local0/scratch/des/src/bin. *** Error code 1 Stop in /local0/scratch/des/src. *** Error code 1 Stop in /local0/scratch/des/src. *** Error code 1 Stop in /local0/scratch/des/src. To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-current in the body of the message
Re: current.freebsd.org
On Sun, Jul 07, 2002 at 11:28:30PM -0400, Chuck Robey wrote: is that machine dead? It's dead Jim. I've asked [EMAIL PROTECTED] to CNAME current and releng4 to the .jp snap server. Perhaps a reminder to hostmaster by someone else would help. To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-current in the body of the message
Re: current.freebsd.org
On Sun, 7 Jul 2002, David O'Brien wrote: On Sun, Jul 07, 2002 at 11:28:30PM -0400, Chuck Robey wrote: is that machine dead? It's dead Jim. I've asked [EMAIL PROTECTED] to CNAME current and releng4 to the .jp snap server. Perhaps a reminder to hostmaster by someone else would help. Ohhhkay. The .jp site I found stopped making snaps on 6/21. Seeing as current only stabilized in the last day or so, I think first I'll write them and ask if it's going to start back up again. Manfred Antar told me about ftp.kddlabs.co.jp, which is the good site. Chuck Robey | Interests include C Java programming, FreeBSD, [EMAIL PROTECTED] | electronics, communications, and signal processing. New Year's Resolution: I will not sphroxify gullible people into looking up fictitious words in the dictionary. To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-current in the body of the message
Re: i386 tinderbox failure
Heh, you *did* ask for -Werror to be turned back on. :-) Dag-Erling Smorgrav wrote: -- Rebuilding the temporary build tree -- stage 1: bootstrap tools -- stage 2: cleaning up the object tree -- stage 2: rebuilding the object tree -- stage 2: build tools -- stage 3: cross tools -- stage 4: populating /home/des/tinderbox/i386/obj/local0/scratch/des/src/i 386/usr/include -- stage 4: building libraries -- stage 4: make dependencies -- stage 4: building everything.. -- === bin/ps ... /local0/scratch/des/src/bin/ps/print.c: In function `printval': /local0/scratch/des/src/bin/ps/print.c:686: warning: format not a string lite ral, argument types not checked /local0/scratch/des/src/bin/ps/print.c:689: warning: format not a string lite ral, argument types not checked /local0/scratch/des/src/bin/ps/print.c:692: warning: format not a string lite ral, argument types not checked /local0/scratch/des/src/bin/ps/print.c:695: warning: format not a string lite ral, argument types not checked /local0/scratch/des/src/bin/ps/print.c:698: warning: format not a string lite ral, argument types not checked /local0/scratch/des/src/bin/ps/print.c:701: warning: format not a string lite ral, argument types not checked /local0/scratch/des/src/bin/ps/print.c:704: warning: format not a string lite ral, argument types not checked /local0/scratch/des/src/bin/ps/print.c:707: warning: format not a string lite ral, argument types not checked /local0/scratch/des/src/bin/ps/print.c:710: warning: format not a string lite ral, argument types not checked *** Error code 1 Stop in /local0/scratch/des/src/bin/ps. *** Error code 1 Stop in /local0/scratch/des/src/bin. *** Error code 1 Stop in /local0/scratch/des/src. *** Error code 1 Stop in /local0/scratch/des/src. *** Error code 1 Stop in /local0/scratch/des/src. To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-current in the body of the message 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 To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-current in the body of the message
fsck hosed?
It seems to be aborting the 'process all file systems' loop when it modifies a file system. eg: WARNING: / was not properly dismounted Enter full pathname of shell or RETURN for /bin/sh: # fsck -y ** /dev/da0a ** Last Mounted on / ** Root filesystem ** Phase 1 - Check Blocks and Sizes ** Phase 2 - Check Pathnames ** Phase 3 - Check Connectivity ** Phase 4 - Check Reference Counts ** Phase 5 - Check Cyl groups 509 files, 38827 used, 205772 free (92 frags, 25710 blocks, 0.0% fragmentation) * FILE SYSTEM MARKED CLEAN * ** /dev/da0e ** Last Mounted on /usr ** Phase 1 - Check Blocks and Sizes ** Phase 2 - Check Pathnames ** Phase 3 - Check Connectivity ** Phase 4 - Check Reference Counts ** Phase 5 - Check Cyl groups 9907 files, 154990 used, 826537 free (2393 frags, 103018 blocks, 0.2% fragmentation) * FILE SYSTEM MARKED CLEAN * ** /dev/da0f ** Last Mounted on /var ** Phase 1 - Check Blocks and Sizes ** Phase 2 - Check Pathnames ** Phase 3 - Check Connectivity ** Phase 4 - Check Reference Counts ** Phase 5 - Check Cyl groups FREE BLK COUNT(S) WRONG IN SUPERBLK SALVAGE? yes SUMMARY INFORMATION BAD SALVAGE? yes BLK(S) MISSING IN BIT MAPS SALVAGE? yes 146 files, 580 used, 122131 free (83 frags, 15256 blocks, 0.1% fragmentation) * FILE SYSTEM MARKED CLEAN * * FILE SYSTEM WAS MODIFIED * # [[[ Uhh, what? What about the rest of the file systems? ]]] # cat /etc/fstab #Device Mountpoint FStype Options DumpPass# /dev/da0a / ufs rw 1 1 /dev/da0b noneswapsw 0 0 /dev/da0e /usrufs rw 2 2 /dev/da0f /varufs rw 2 2 /dev/da0g /tmpufs rw 2 2 /dev/da0h /s ufs rw,nosuid,nodev 2 2 /dev/da1e /t ufs rw,nosuid,nodev 2 2 /dev/cd0a /cdrom cd9660 ro,noauto 0 0 freefall:/c /freefall/c nfs ro,bg,intr,soft,nodev,nosuid 0 0 freefall:/d /freefall/d nfs rw,bg,intr,soft,nodev,nosuid 0 0 # fsck -y ** /dev/da0a ** Last Mounted on / ** Root filesystem ** Phase 1 - Check Blocks and Sizes ** Phase 2 - Check Pathnames ** Phase 3 - Check Connectivity ** Phase 4 - Check Reference Counts ** Phase 5 - Check Cyl groups 509 files, 38827 used, 205772 free (92 frags, 25710 blocks, 0.0% fragmentation) ** /dev/da0e ** Last Mounted on /usr ** Phase 1 - Check Blocks and Sizes ** Phase 2 - Check Pathnames ** Phase 3 - Check Connectivity ** Phase 4 - Check Reference Counts ** Phase 5 - Check Cyl groups 9907 files, 154990 used, 826537 free (2393 frags, 103018 blocks, 0.2% fragmentation) ** /dev/da0f ** Last Mounted on /var ** Phase 1 - Check Blocks and Sizes ** Phase 2 - Check Pathnames ** Phase 3 - Check Connectivity ** Phase 4 - Check Reference Counts ** Phase 5 - Check Cyl groups 146 files, 580 used, 122131 free (83 frags, 15256 blocks, 0.1% fragmentation) ** /dev/da0g ** Last Mounted on /tmp ** Phase 1 - Check Blocks and Sizes ** Phase 2 - Check Pathnames ** Phase 3 - Check Connectivity ** Phase 4 - Check Reference Counts ** Phase 5 - Check Cyl groups 4 files, 3 used, 122708 free (20 frags, 15336 blocks, 0.0% fragmentation) * FILE SYSTEM MARKED CLEAN * ** /dev/da0h ** Last Mounted on /s ** Phase 1 - Check Blocks and Sizes ** Phase 2 - Check Pathnames ** Phase 3 - Check Connectivity ** Phase 4 - Check Reference Counts ** Phase 5 - Check Cyl groups 49948 files, 494996 used, 5375777 free (2105 frags, 671709 blocks, 0.0% fragmentation) * FILE SYSTEM MARKED CLEAN * ** /dev/da1e ** Last Mounted on /t ** Phase 1 - Check Blocks and Sizes ** Phase 2 - Check Pathnames ** Phase 3 - Check Connectivity ** Phase 4 - Check Reference Counts ** Phase 5 - Check Cyl groups 18285 files, 205326 used, 4098363 free (2715 frags, 511956 blocks, 0.1% fragmentation) * FILE SYSTEM MARKED CLEAN * # fsck -p /dev/da0a: FILESYSTEM CLEAN; SKIPPING CHECKS /dev/da0a: clean, 205772 free (92 frags, 25710 blocks, 0.0% fragmentation) /dev/da0e: FILESYSTEM CLEAN; SKIPPING CHECKS /dev/da0e: clean, 826537 free (2393 frags, 103018 blocks, 0.2% fragmentation) /dev/da1e: FILESYSTEM CLEAN; SKIPPING CHECKS /dev/da1e: clean, 4098363 free (2715 frags, 511956 blocks, 0.1% fragmentation) /dev/da0f: FILESYSTEM CLEAN; SKIPPING CHECKS /dev/da0f: clean, 122131 free (83 frags, 15256 blocks, 0.1% fragmentation) /dev/da0g: FILESYSTEM CLEAN; SKIPPING CHECKS /dev/da0g: clean, 122708 free (20 frags, 15336 blocks, 0.0% fragmentation) /dev/da0h: FILESYSTEM CLEAN; SKIPPING CHECKS /dev/da0h: clean, 5375777 free (2105 frags, 671709 blocks, 0.0% fragmentation) # halt Notice how it completely exited after da0f and printing WAS MODIFIED ? Not to mention how we cannot shut down cleanly. :-( Cheers, -Peter -- Peter Wemm - [EMAIL
Re: current.freebsd.org
chuckr Ohhhkay. The .jp site I found stopped making snaps on 6/21. Mainly because kern.flp was flood. Any tiny breakages refuse to make a distribution. chuckr Manfred Antar told me about ftp.kddlabs.co.jp, which is the chuckr good site. It mirrors snapshots.jp.FreeBSD.org daily, if my log analysis is correct. snapshots.jp.FreeBSD.org is now becoming too busy ftp site, many connections are rejected because of max connection limit. I'm now seeking donors of network bandwidth and PCs (but I don't know I can find or not). Anyway, sorry for inconveniences at this time. -- - Makoto `MAR' Matsushita To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-current in the body of the message
Re: current.freebsd.org
David O'Brien wrote: On Sun, Jul 07, 2002 at 11:28:30PM -0400, Chuck Robey wrote: is that machine dead? It's dead Jim. I've asked [EMAIL PROTECTED] to CNAME current and releng4 to the .jp snap server. Perhaps a reminder to hostmaster by someone else would help. Are the ftp paths equivalent? I seem to recall that current.freebsd.org is referenced in sysinstall. Will just a CNAME work? 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 To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-current in the body of the message
