Re: UDMA33 on older acer aladdin chips
Andrew Gallatin wrote: Hi, I recently decided to update my alpha UP1000 to today's current from a mid-July build. However, UDMA33 did not work on a hard disk attached to the built-in Acer Aladdin controller (verbose dmesg appended). I think I have narrowed the problem down to this line of code: atadev-channel-flags |= ATA_ATAPI_DMA_RO; Removing this line gets my UDMA33 back. If I understand the code correctly, the right fix should more look like: diff -u -r1.18 ata-lowlevel.c --- ata-lowlevel.c 7 Oct 2003 13:45:56 - 1.18 +++ ata-lowlevel.c 8 Oct 2003 22:38:15 - @@ -73,7 +73,8 @@ request-device-channel-running = request; /* disable ATAPI DMA writes if HW doesn't support it */ -if (request-flags (ATA_R_ATAPI | ATA_R_DMA | ATA_R_WRITE) +if (((request-flags (ATA_R_ATAPI | ATA_R_DMA | ATA_R_WRITE)) == + (ATA_R_ATAPI | ATA_R_DMA | ATA_R_WRITE)) request-device-channel-flags ATA_ATAPI_DMA_RO) request-flags = ~ATA_R_DMA; But I don't have ATAPI devices attached to this machine to test. Daniel ___ [EMAIL PROTECTED] mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: ad0: WARNING - WRITE_MUL write data underrun
Mark Knight schrieb: Current from approximately 0500 BST on 16th September is giving me errors like this from boot: ad0: WARNING - WRITE_MUL write data underrun 81922048 ad0: WARNING - WRITE_MUL write data underrun 81926144 ad0: WARNING - WRITE_MUL write data underrun 81924096 ad0: WARNING - WRITE_MUL write data underrun 81924096 Same for me. From the date on the left you can see how often this happens. I have seen these messages since switching to ATAng (on Sep 3rd) - in PIO mode, since I have an Acer Aladdin based board. This machine is mostly idle. Even during most of the messages below, there wasn't much disk activity. Total disk activity since last reboot (5 days ago): % iostat -I tty ad0 ad1 cd0 cpu tin tout KB/t xfrs MB KB/t xfrs MB KB/t xfrs MB us ni sy in id 02 11.91 300969 3501.68 5.86 44871 256.99 0.00 0 0.00 3 85 8 4 0 Sep 3 19:37:02 ad0: WARNING - WRITE_MUL write data underrun 81924096 Sep 6 06:21:14 ad0: WARNING - WRITE_MUL write data underrun 81926144 Sep 6 15:08:59 ata0: resetting devices .. Sep 6 15:08:59 done Sep 6 15:08:59 ad0: TIMEOUT - WRITE_MUL retrying (1 retry left) Sep 8 21:15:04 ad0: WARNING - WRITE_MUL write data underrun 81924096 Sep 9 02:34:23 ad0: WARNING - WRITE_MUL write data underrun 81926144 Sep 12 14:44:03 ad0: WARNING - WRITE_MUL write data underrun 81924096 Sep 13 00:43:55 ad0: WARNING - WRITE_MUL write data underrun 81922048 Sep 13 01:15:02 ad0: WARNING - WRITE_MUL write data underrun 81924096 Sep 13 03:20:54 ata0: resetting devices .. Sep 13 03:20:55 done Sep 13 03:20:55 ad0: TIMEOUT - WRITE_MUL retrying (1 retry left) Sep 13 15:22:07 ata0: resetting devices .. Sep 13 15:22:07 done Sep 13 15:22:08 ad0: TIMEOUT - WRITE_MUL retrying (1 retry left) Sep 13 16:04:03 ad0: WARNING - WRITE_MUL write data underrun 81924096 Sep 13 17:24:09 ad0: WARNING - WRITE_MUL write data underrun 81924096 Sep 14 03:23:22 ata0: resetting devices .. Sep 14 03:23:22 done Sep 14 03:23:22 ad0: TIMEOUT - WRITE_MUL retrying (1 retry left) Sep 14 10:00:36 ad0: WARNING - WRITE_MUL write data underrun 81924096 Sep 15 04:22:25 ad0: WARNING - WRITE_MUL write data underrun 81922048 Sep 17 10:55:17 ad0: WARNING - WRITE_MUL write data underrun 81924096 Sep 17 11:35:04 ad0: WARNING - WRITE_MUL write data underrun 81924096 ___ [EMAIL PROTECTED] mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: ATAng probe updated please test
D. Rock schrieb: Soren Schmidt schrieb: I've gone over the probe code once again. Please test, and in case it fails to detect or misdetects anything, mail me the output of dmesg from a verbose boot, and state what devices actually are there. Hi, again no luck. Same problem persists, the devices got probed correctly (two disks, each on its own channel), but cannot be accessed. Just an additional notice: Booting in PIO mode (by setting hw.ata.ata_dma=0 in /boot/loader.conf): [...] GEOM: create disk ad0 dp=0xc10b3b70 ad0: 9671MB IBM-DTTA-351010 [20960/15/63] at ata0-master PIO4 GEOM: create disk ad1 dp=0xc10b3470 ad1: 1221MB Seagate Technology 1275MB - ST31276A [2482/16/63] at ata1-master PIO4 Waiting 2 seconds for SCSI devices to settle Mounting root from ufs:/dev/ad0a But if I try to set DMA mode later via atacontrol, the problem reappears: # atacontrol mode 0 udma2 udma2 Master = UDMA33 Slave = BIOSPIO # atacontrol mode 1 udma2 udma2 Master = WDMA2 Slave = BIOSPIO ad0: WARNING - WRITE_DMA recovered from missing interrupt ad1: WARNING - READ_DMA recovered from missing interrupt /usr/local/squid: bad dir ino 22496 at offset 0: mangled entry panic: ufs_dirbad: bad dir Debugger(panic) Stopped at Debugger+0x45: xchgl %ebx,in_Debugger.0 db where Debugger(c04517f8) at Debugger+0x45 panic(c04682ea,c1281200,d5decb08,c039be8a,c129b08c) at panic+0xbb ufs_dirbad(c129b08c,0,c04682a4,c103ce40,0) at ufs_dirbad+0x3d ufs_lookup(d5decb38,d5decb74,c02b0005,d5decb38,287) at ufs_lookup+0x2be ufs_vnoperate(d5decb38) at ufs_vnoperate+0x13 vfs_cache_lookup(d5decbac,d5decbc8,c02b45df,d5decbac,c103ce40) at vfs_cache_lookup+0x29d ufs_vnoperate(d5decbac) at ufs_vnoperate+0x13 lookup(d5decc30,c103ce40,50,c110cc00,20) at lookup+0x2cb namei(d5decc30) at namei+0x1b5 stat(c103ce40,d5decd14,2,84,216) at stat+0x4a syscall(2f,2f,2f,0,81f4020) at syscall+0x233 Xint0x80_syscall() at Xint0x80_syscall+0x1d --- syscall (188, FreeBSD ELF32, stat), eip = 0x2815c95b, esp = 0xbfbffa6c, ebp = 0xbfbffc38 --- db interestingly enough, a crash dump could be written on the dump device (ad0b), but it was unusable: Checking for core dump... savecore: first and last dump headers disagree on /dev/ad0b savecore: unsaved dumps found but not saved Daniel ___ [EMAIL PROTECTED] mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to [EMAIL PROTECTED]
unable to make release in -CURRENT
Hi,
the following error is probably GEOM related.
Since a few weeks I am unable to make release anymore. It bails out
while trying to prepare the floppies with the following error:
disklabel: /dev/md0c: Device not configured
The real md devices from devfs have major number 4:
# ls -l /dev/md*
crw-r- 1 root operator4, 86 23 Okt 22:10 /dev/md0
crw-r- 1 root operator4, 87 23 Okt 22:10 /dev/md0a
crw-r- 1 root operator4, 87 23 Okt 22:10 /dev/md0a
crw-r- 1 root operator4, 88 23 Okt 22:10 /dev/md0b
crw-r- 1 root operator4, 88 23 Okt 22:10 /dev/md0b
crw-r- 1 root operator4, 89 23 Okt 22:10 /dev/md0c
crw-r- 1 root operator4, 89 23 Okt 22:10 /dev/md0c
crw--- 1 root wheel 95, 0x00ff 23 Okt 22:10 /dev/mdctl
But the ones in the chroot'ed environment created manually with MAKEDEV
still have major number 95:
crw-r- 2 root operator 95, 0x00010002 23 Okt 11:02 /dev/md0
crw-r- 2 root operator 95, 0 23 Okt 11:02 /dev/md0a
crw-r- 2 root operator 95, 1 23 Okt 11:02 /dev/md0b
crw-r- 2 root operator 95, 2 23 Okt 11:02 /dev/md0c
crw-r- 2 root operator 95, 3 23 Okt 11:02 /dev/md0d
crw-r- 2 root operator 95, 4 23 Okt 11:02 /dev/md0e
crw-r- 2 root operator 95, 5 23 Okt 11:02 /dev/md0f
crw-r- 2 root operator 95, 6 23 Okt 11:02 /dev/md0g
crw-r- 2 root operator 95, 7 23 Okt 11:02 /dev/md0h
crw-r- 2 root operator 95, 0x00020002 23 Okt 11:02 /dev/md0s1
crw-r- 2 root operator 95, 0x0002 23 Okt 11:02 /dev/md0s1a
crw-r- 2 root operator 95, 0x00020001 23 Okt 11:02 /dev/md0s1b
crw-r- 2 root operator 95, 0x00020002 23 Okt 11:02 /dev/md0s1c
crw-r- 2 root operator 95, 0x00020003 23 Okt 11:02 /dev/md0s1d
crw-r- 2 root operator 95, 0x00020004 23 Okt 11:02 /dev/md0s1e
crw-r- 2 root operator 95, 0x00020005 23 Okt 11:02 /dev/md0s1f
crw-r- 2 root operator 95, 0x00020006 23 Okt 11:02 /dev/md0s1g
crw-r- 2 root operator 95, 0x00020007 23 Okt 11:02 /dev/md0s1h
crw-r- 2 root operator 95, 0x00030002 23 Okt 11:02 /dev/md0s2
crw-r- 2 root operator 95, 0x00040002 23 Okt 11:02 /dev/md0s3
crw-r- 2 root operator 95, 0x00050002 23 Okt 11:02 /dev/md0s4
crw--- 1 root wheel 95, 0x00ff 22 Okt 23:03 /dev/mdctl
make release should simply mount /dev in the chroot'ed environment, so
we don't have any gap between statically created device nodes via
MAKEDEV and dynamically ones via devfs, like in the following patch:
Index: Makefile
===
RCS file: /data/cvs/src/release/Makefile,v
retrieving revision 1.711
diff -u -r1.711 Makefile
--- Makefile16 Oct 2002 05:30:56 - 1.711
+++ Makefile23 Oct 2002 21:44:03 -
@@ -385,9 +385,11 @@
echo ${CROSSMAKE} ${WORLD_FLAGS} -DNOCLEAN buildworld \\
${CHR
OOTDIR}/mk
echo touch /tmp/.world_done ${CHROOTDIR}/mk
echo fi${CHROOTDIR}/mk
+ echo mount -t devfs /dummy /dev${CHROOTDIR}/mk
echo cd /usr/src/release ${CHROOTDIR}/mk
echo make obj ${CHROOTDIR}/mk
echo make \$${_RELTARGET} ${CHROOTDIR}/mk
+ echo umount /dev ${CHROOTDIR}/mk
echo echo \ make ${.TARGET} for ${TARGET} finished on
\`LC_ALL=C TZ
=GMT date\`\ ${CHROOTDIR}/mk
chmod 755 ${CHROOTDIR}/mk
env -i /usr/sbin/chroot ${CHROOTDIR} /mk
Daniel
To Unsubscribe: send mail to [EMAIL PROTECTED]
with unsubscribe freebsd-current in the body of the message
Re: unable to make release in -CURRENT
Forget my previous post. The change was commited four days ago. I missed them because I thought most work is done in the chroot'd environment, which is up to date due to the immediate checkout. But the devfs mount prepration was done in the normal /usr/src/release directory which I hadn't checkout'd for five days. Daniel To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-current in the body of the message
file system deadlock in -CURRENT
Hi, I found an interesting problem during tracing my perl-5.8 problem I mailed some days ago. Sometimes - I cannot forcibly reproduce this event - while I'm trying to truss a process, I first get the following error message: /usr/ports/lang/perl5.8/work/perl-5.8.0# truss ./perl truss: cannot open /proc/44502/mem: No such file or directory or the following error message: /usr/ports/lang/perl5.8/work/perl-5.8.0# truss ./perl truss: PIOCWAIT: Input/output error And then I cannot enter this directory any more. Every process trying to access /usr/ports/lang/perl5.8/work/5.8.0 hangs in an uninterruptible sleep: /# cd /usr/ports/lang/perl5.8 /usr/ports/lang/perl5.8# ls CVS/ distinfo pkg-comment pkg-install* pkg-plistwork/ Makefile files/ pkg-descrpkg-message test.log /usr/ports/lang/perl5.8# cd work /usr/ports/lang/perl5.8/work# ls BSDPAN-5.8.0/ perl-5.8.0/ use.perl /usr/ports/lang/perl5.8/work# cd perl-5.8.0 /usr/ports/lang/perl5.8/work/perl-5.8.0# ls [at this point the shell (or any other process) hangs. I can otherwise use the machine as usual but cannot access this directory] Only solution to revive the directory again is a reboot. I have recompiled the kernel with options WITNESS options MUTEX_DEBUG One lock order reversal was logged by the kernel 3 hours earlier: lock order reversal 1st 0xc05a1fe0 spechash (spechash) @ ../../../kern/vfs_subr.c:2748 2nd 0xc17866f0 vnode interlock (vnode interlock) @ ../../../kern/vfs_subr.c:2751 (possibly unrelated) The last time I had this problem I also had a kernel panic (but no crash dump or console output during the crash - possibly also unrelated. I still have reliability problems during heave file system activity). I'm trying to reproduce this error again, then hopefully with a crash dump. Daniel To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-current in the body of the message
Re: file system deadlock in -CURRENT
Daniel Rock schrieb: Hi, I found an interesting problem during tracing my perl-5.8 problem I mailed some days ago. Sometimes - I cannot forcibly reproduce this event - while I'm trying to truss a process, I first get the following error message: /usr/ports/lang/perl5.8/work/perl-5.8.0# truss ./perl truss: cannot open /proc/44502/mem: No such file or directory or the following error message: /usr/ports/lang/perl5.8/work/perl-5.8.0# truss ./perl truss: PIOCWAIT: Input/output error A side note: The problem seems to be related with programs compiled with profiling enabled. trussing a normal program never showed this behaviour. Daniel To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-current in the body of the message
Re: Perl 5.8 broken in current
Kris Kennaway schrieb: On Wed, Oct 16, 2002 at 02:12:07AM +0200, Daniel Rock wrote: gprof thinks the runtime is only 8 seconds, while in reality it takes more than 2 minutes to complete the test. A small excerpt from gprof output Are you running a kernel with WITNESS enabled? This can really chew up kernel CPU time if you're doing a lot of syscalls. No, WITNESS not enabled. System calls should not be the problem. If I truss the process. Syscalls don't seem to be the problem. Most of the syscalls are break() syscalls, but no more than 10-20 per second. If I try to reduce the calling frequency (ln -sf /etc/malloc.conf), runtime doesn't change significantly Daniel To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-current in the body of the message
Re: Perl 5.8 broken in current
David O'Brien schrieb: On Mon, Oct 14, 2002 at 01:44:07PM -0700, Alex Zepeda wrote: So turn off the optimizations? No in -CURRENT with GCC 3.2, we want to know when -O2 causes a problem. gcc's code optimizations are broken, and should be avoided. Not any more with GCC 3.2, unless you have a test case to prove it broken. To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-current in the body of the message The errors during make test are only one issue. What bothers me even more ist the high runtime of some of the tests (up to several *hours*). Finally a make test completed on my machine (perl-5.8 compiled without optimizations, which isn't a big issue, see my previous mail showing run times of one test): All tests successful. u=13.8672 s=5.61719 cu=21700.3 cs=2264.12 scripts=666 tests=68469 36915,89 real 21726,29 user 2278,34 sys The same tests on Solaris/x86 (processor ~40% faster) only take 12 minutes. Daniel To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-current in the body of the message
Re: Perl 5.8 broken in current
Kris Kennaway schrieb: On Tue, Oct 15, 2002 at 07:31:28PM +0200, Daniel Rock wrote: The errors during make test are only one issue. What bothers me even more ist the high runtime of some of the tests (up to several *hours*). Finally a make test completed on my machine (perl-5.8 compiled without optimizations, which isn't a big issue, see my previous mail showing run times of one test): All tests successful. u=13.8672 s=5.61719 cu=21700.3 cs=2264.12 scripts=666 tests=68469 36915,89 real 21726,29 user 2278,34 sys The same tests on Solaris/x86 (processor ~40% faster) only take 12 minutes. It would help if you can do some form of profiling to work out what exactly is taking longer. Kris Ok, I tried it but the results are very strange. I recompiled perl with profiling enabled and ran the test t/op/pat.t gprof thinks the runtime is only 8 seconds, while in reality it takes more than 2 minutes to complete the test. A small excerpt from gprof output FreeBSD: granularity: each sample hit covers 4 byte(s) for 0.01% of 8.15 seconds called/total parents index %timeself descendents called+selfname index called/total children [...] [2] 92.10.007.50 main [2] 0.004.88 1/1 perl_parse [3] 0.002.01 1/1 perl_destruct [6] 0.000.35 1/1 perl_run [22] 0.000.26 1/1 perl_construct [31] 0.000.00 1/1 __fpsetreg [1807] 0.000.00 1/1 perl_alloc [817] 0.000.00 1/1 perl_free [818] Solaris: granularity: each sample hit covers 4 byte(s) for 0.02% of 10.13 seconds called/total parents index %timeself descendents called+selfname index called/total children 0.005.79 1/1 _start [2] [1] 57.10.005.79 1 main [1] 0.003.80 1/1 perl_parse [5] 0.001.21 1/1 perl_destruct [8] 0.000.56 1/1 perl_construct [15] 0.000.21 1/1 perl_run [27] 0.000.00 1/1 perl_alloc [600] 0.000.00 1/1 perl_free [610] 0.000.00 1/1 _pthread_atfork [624] 0.000.00 1/1 _signal [2752] 0.000.00 1/1 pthread_mutex_destroy [943] Daniel To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-current in the body of the message
Re: Still under -current: bwrite: buffer is not busy???
Michael Reifenberger schrieb: Hi, I still get the following panic (2 are attached) under -current on my notebook when doing a 'portupgrade -R -f kdebase'. Anyone else sees this? Yes, I also do get these type of panics during heavy FS activity (vm fault, double fault, etc.) I can panic my machine really fast if I remove some work directories in /usr/ports while doing a find /usr/ports at the same time. Daniel To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-current in the body of the message
Perl 5.8 broken in current
Hi, perl-5.8 seems to be severely broken in current. If I compile it with optimization enabled make test fails at t/op/pat, test 640. Only with no optimization at all this test succeeded. I tried the following options make CPUTYPE=i386 CFLAGS=-g = success make CPUTYPE=i386 CFLAGS=-O2= failure make CPUTYPE=k6= failure make (default values: -mcpu=pentiumpro -O)= failure Also perl is painfully slow. Above test (t/op/pat) requires over 2 Minutes to complete (on my AMD K6-2/300). The same test on a Solaris/x86 Maschine (P II 450) only takes 7 seconds. gcc-3.2 on my Solaris(x86) also has no problems compiling and testing perl-5.8 Some other tests take even hours to complete. I wonder what is going on inside perl? Daniel To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-current in the body of the message
Re: Perl 5.8 broken in current
Alex Zepeda schrieb: So turn off the optimizations? gcc's code optimizations are broken, and should be avoided. If you want to break perl 5.6 you can do so with -O3 -march=pentiumpro (somehow I suspect -O2 would have the same effect). Besides, that just goes to show, it's not perl that's broken.. rather it's the compiler. But why don't show the same optimization levels on another intel platform (Solaris x86, gcc-3.2 release) no problem? And what about the incredible runtime, regardless of optimization level (t/op/pat.t has a running time of 110s-130s, while the same test on my Solaris/x86 box only takes 7 seconds to complete. Solaris (450 MHz P II): % timex ./perl t/op/pat.t [...] ok 921 ok 922 real7.41 user5.66 sys 0.29 FreeBSD (300 MHz K6-2, unoptimized): % /usr/bin/time ./perl t/op/pat.t [...] ok 921 ok 922 211,42 real 115,96 user29,67 sys FreeBSD (-mcpu=pentiumpro -O): [...] ok 639 time: command terminated abnormally 204,05 real 111,23 user31,60 sys segmentation fault (core dumped) Especially the high system time worries me (25% of the runtime in the kernel) To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-current in the body of the message
Re: Clock runs too fast
Craig Rodrigues schrieb: Hi, I have been having this problem with -current for the past 2 weeks now (I am new to -current and just started using it 2 weeks ago). I just did a cvsup and rebuilt the kernel and rebuilt the world. My clock seems to be running too fast, and I keep resetting it with ntpdate. [...] Now the clock seems to run at a more reasonable rate. Is there a problem with the ACPI code or with my hardware (an ASUS P5A-B motherboard from about 3 or 4 years ago). How can I default to i8254 as my default timer? Is there something I should put in device.hints? I had similar problems with a Gigabyte GA-5AX (also with ALi Aladdin V chipset). Without setting debug.acpi.disable = timer the clock runs twice as fast as it should be. This problem seems to be introduced in the ACPI update around July 2001. I didn't find any solution other than disabling ACPI timecounter. Daniel To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-current in the body of the message
Re: fsck cannot find superblock
Bruce Evans schrieb: On Tue, 3 Sep 2002, D. Rock wrote: with 'uncommon' block sizes fsck seems to have problems finding the superblock: # newfs -i 10240 -b 4096 -f 512 /dev/ad1d Reduced frags per cylinder group from 26208 to 26200 to enlarge last cyl group /dev/ad1d: 409.6MB (838860 sectors) block size 4096, fragment size 512 using 33 cylinder groups of 12.79MB, 3275 blks, 1312 inodes. super-block backups (for fsck -b #) at: 32, 26232, 52432, 78632, 104832, 131032, 157232, 183432, 209632, 235832, 262032, 288232, 314432, 340632, 366832, 393032, 419232, 445432, 471632, 497832, 524032, 550232, 576432, 602632, 628832, 655032, 681232, 707432, 733632, 759832, 786032, 812232, 838432 # fsck /dev/ad1d ** /dev/ad1d Cannot find file system superblock LOOK FOR ALTERNATE SUPERBLOCKS? [yn] n fsck_ffs has no problems here with (whole) md disk of the same size. Perhaps I have fixed the problem without noticing. dumpfs or comparison with a non-broken filesystem of the same size might show the problem. Bruce I have attached the label of the offending disk and an output of a dumpfs on a freshly created file system with the following options: newfs -b 4096 -f 4096 /dev/ad1d newfs -b 8192 -f 8192 /dev/ad1d The problem seems to be introduced with the UFS2 import. In src/sbin/fsck_ffs/setup.c the sanity checks are more tightly formulated. Especially one check was added: sblock.fs_bsize = SBLOCKSIZE this fails on 4K file systems, because fs_bsize is only 4096, but SBLOCKSIZE is defined as 8192. The sanity checks for searching alternate superblocks are more relaxed (in readsb() the first if branch is entered, not the else branch), so during searching for alternate superblocks the very same sb that was rejected in the first run (at offset 8192) will be used. Possible solutions: * remove above sanity check * does SBLOCKSIZE really have to be 8192, in real it is much smaller (less than 2KB) * drop support for 4K block sizes completely, but this breaks backwards compatibility Daniel # /dev/ad1c: type: ESDI disk: ad0s1 label: flags: bytes/sector: 512 sectors/track: 252 tracks/cylinder: 4 sectors/cylinder: 1008 cylinders: 2482 sectors/unit: 2501856 rpm: 4500 interleave: 1 trackskew: 0 cylinderskew: 0 headswitch: 0 # milliseconds track-to-track seek: 0 # milliseconds drivedata: 0 8 partitions: #size offsetfstype [fsize bsize bps/cpg] b: 462996 2038860 swap# (Cyl. 2022*- 2481*) c: 25018560unused0 0 # (Cyl.0 - 2481) d: 83886004.2BSD 512 4096 26200 # (Cyl.0 - 832*) e: 120 8388604.2BSD 2048 8192 48388 # (Cyl. 832*- 2022*) magic 11954 (UFS1)timeWed Sep 4 20:33:22 2002 id [ 3d7651f2 4b7c67bc ] ncg 8 size104857 blocks 103972 bsize 4096shift 12 mask0xf000 fsize 4096shift 12 mask0xf000 frag1 shift 0 fsbtodb 3 minfree 8% optim timesymlinklen 60 maxbpg 512 maxcontig 32contigsumsize 16 nbfree 103971 ndir1 nifree 27389 nffree 0 cpg 1 bpg 13681 fpg 13681 ipg 3424 nindir 1024inopb 32 nspf8 maxfilesize 4402345721855 sbsize 4096cgsize 4096cgoffset 0 cgmask 0x csaddr 114 cssize 4096 rotdelay 0msrps 60 trackskew 0 interleave 1 nsect 109448 npsect 109448 spc 109448 sblkno 4 cblkno 6 iblkno 7 dblkno 114 cgrotor 0 fmod0 ronly 0 clean 1 flags none cs[].cs_(nbfree,ndir,nifree,nffree): (13565,1,3421,0) (13571,0,3424,0) (13571,0,3424,0) (13571,0,3424,0) (13571,0,3424,0) (13571,0,3424,0) (13571,0,3424,0) (8980,0,3424,0) cylinders in last group 1 blocks in last group 9090 cg 0: magic 90255 tell6000timeWed Sep 4 20:33:22 2002 cgx 0 ncyl1 niblk 3424ndblk 13681 nbfree 13565 ndir1 nifree 3421nffree 0 rotor 0 irotor 0 frotor 0 frsum sum of frsum: 0 clusters 1-8: 0 0 0 0 0 0 0 0 clusters 9-15: 0 0 0 0 0 0 0 clusters size 16 and over: 1 clusters free: 116-13680 inodes used:0-2 blks free: 116-13680 cg 1: magic 90255 tell3577000 timeWed Sep 4 20:33:22 2002 cgx 1 ncyl1 niblk 3424ndblk 13681 nbfree 13571 ndir0 nifree 3424nffree 0 rotor 0 irotor 0 frotor 0 frsum sum of frsum: 0 clusters 1-8: 0 0 0 1 0 0 0 0 clusters 9-15: 0 0 0 0 0 0 0 clusters size 16 and over: 1 clusters free: 0-3, 114-13680 inodes used: blks free: 0-3, 114-13680 cg 2: magic 90255 tell6ae8000 timeWed
GCC-3.1 Optimization -Os broken
Hi, after a make world I noticed that my dialout was broken (NAT for UDP packets seems to work but not for TCP). After a few tests I finally found the bug: -Os compilation seems broken with gcc-3.1. I normally compile complete world with -Os (instead of -O) (via CFLAGS=-Os in /etc/make.conf). I narrowed the ppp dialout down to libalias: - recompile libalias with -Os = NAT broken - recompile libalias with -O = NAT works again. I know any other optimization than -O isn't supported but this bug (either in libalias or in gcc) should be investigated. Daniel To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-current in the body of the message
Re: clock drift in -CURRENT
Daniel Rock schrieb: My kernel war relatively recent at the time of last boot - build around March 2nd from -CURRENT sources a few hours before. If someone runs -CURRENT with default HZ of 100 and moans 247 days later, his -CURRENT cannot be called -CURRENT any more... I am now running an up-to-date -CURRENT. I have set HZ=1, so I don't have to wait another 50 days. Hope this high HZ value has no negative impact on the test. I will inform you in 3 days if anything strange happens again. I had run the kernel now for over 2^31 clock ticks and had no drifting problem so far. I will now set HZ back to 500 - let's see what happens in 50 days... Daniel To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-current in the body of the message
clock drift in -CURRENT
Hi, after almost 50 days of uptime I suddenly noticed an extreme clock drift in current. Here is an excerpt from my /var/log/messages (March 8th was my last reboot time): Mar 8 18:38:07 gate syslogd: kernel boot file is /boot/kernel/kernel Mar 8 18:38:07 gate kernel: Copyright (c) 1992-2002 The FreeBSD Project. [...] Apr 27 20:03:10 gate ntpd[157]: time reset -0.250532 s Apr 27 20:18:14 gate ntpd[157]: time reset 0.446208 s Apr 27 20:39:57 gate ntpd[157]: time reset -0.820100 s Apr 27 21:11:19 gate ntpd[157]: time reset 0.887949 s Apr 27 21:25:33 gate ntpd[157]: time reset -0.228488 s Apr 27 21:54:35 gate ntpd[157]: time reset -0.395676 s Apr 28 12:59:15 gate ntpd[157]: time reset -0.381327 s Apr 28 13:19:52 gate ntpd[157]: time reset 0.815323 s Apr 28 13:31:50 gate ntpd[157]: time reset 0.844171 s Apr 28 13:58:52 gate ntpd[157]: time reset 1.447538 s Apr 28 14:14:58 gate ntpd[157]: time reset 0.915263 s Apr 28 14:36:38 gate ntpd[157]: time reset 0.860966 s Apr 28 14:47:29 gate ntpd[157]: time reset 0.984839 s Apr 28 15:06:59 gate ntpd[157]: time reset 1.025584 s Apr 28 15:27:32 gate ntpd[157]: time reset 1.156623 s Apr 28 15:48:59 gate ntpd[157]: time reset 0.896726 s Apr 28 16:00:52 gate ntpd[157]: time reset 0.973291 s Apr 28 16:24:24 gate ntpd[157]: time reset 1.212415 s Apr 28 16:37:19 gate ntpd[157]: time reset 0.859379 s Apr 28 16:56:49 gate ntpd[157]: time reset 0.914863 s Apr 28 17:13:05 gate ntpd[157]: time reset 1.100234 s Apr 28 17:35:59 gate ntpd[157]: time reset 1.231416 s Apr 28 17:59:53 gate ntpd[157]: time reset 1.026558 s Apr 28 18:11:59 gate ntpd[157]: time reset 0.995554 s Apr 28 18:34:45 gate ntpd[157]: time reset 1.140261 s Apr 28 18:54:19 gate ntpd[157]: time reset 0.856611 s Apr 28 19:07:15 gate ntpd[157]: time reset 1.094226 s Apr 28 19:22:30 gate ntpd[157]: time reset 0.879816 s Apr 28 19:47:25 gate ntpd[157]: time reset 1.332108 s Apr 28 20:06:56 gate ntpd[157]: time reset 0.949128 s Apr 28 20:28:27 gate ntpd[157]: time reset 0.906657 s Apr 28 20:41:37 gate ntpd[157]: time reset 0.877976 s Apr 28 20:57:57 gate ntpd[157]: time reset 1.103012 s Apr 28 21:28:19 gate ntpd[157]: time reset 1.607870 s Apr 28 21:59:43 gate ntpd[157]: time reset 1.253603 s Apr 28 22:14:46 gate ntpd[157]: time reset 1.181729 s Apr 28 22:47:13 gate ntpd[157]: time reset 1.573263 s Apr 28 23:07:47 gate ntpd[157]: time reset 0.836291 s Apr 28 23:20:52 gate ntpd[157]: time reset 1.105955 s Apr 28 23:35:59 gate ntpd[157]: time reset 0.839469 s [...] So the machine is losing a second every 20 minutes. After a reboot everything was OK again. The drift began exactly at the moment the counter for clock interrupts got past the 2^31 mark (I have HZ=500 in the kernel): 500 ticks/s * 49.7 days ~ 2^31 ticks After a reboot everything went ok again. To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-current in the body of the message
Re: clock drift in -CURRENT
Poul-Henning Kamp schrieb: When was your source tree from on that kernel ? I'm not too confident in your diagnosis, mostly because we don't have a counter like you describe :-) My guess is that ntpd get confused. Please try a newer kernel, a number of bug(lets) have been fixed since march. If it happens again, please email me the output of: ntpdc -c peer ntpdc -c loopi ntpdc -c kerni dmesg [...] My kernel war relatively recent at the time of last boot - build around March 2nd from -CURRENT sources a few hours before. If someone runs -CURRENT with default HZ of 100 and moans 247 days later, his -CURRENT cannot be called -CURRENT any more... I am now running an up-to-date -CURRENT. I have set HZ=1, so I don't have to wait another 50 days. Hope this high HZ value has no negative impact on the test. I will inform you in 3 days if anything strange happens again. Daniel To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-current in the body of the message
Re: clock drift in -CURRENT
Bill Fenner schrieb: I had the same symptoms (drifting about 2 minutes an hour) on sources before April 17 or so. Since then, ntpd has only logged 5 time updates, as opposed to 3 per hour. The drift wasn't visible immediately, but only after the magical 49.7 days or 2^31 clock ticks. Before that I had the usual corrections if you run ntp over a dialup line with large variations in round trip times (around one correction every few days). To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-current in the body of the message
Re: two panics with recent -CURRENT
Daniel Rock schrieb: Hi, during a make release run I got two panics in -CURRENT (from Feb 16). Both panics occured during high I/O rates. Just an additional note: The kernel from Feb 9 also panic'd this morning. I have now newfs'd the file system and are running the tests again. Daniel smime.p7s Description: Kryptographische Unterschrift im S/MIME-Format
two panics with recent -CURRENT
Hi, during a make release run I got two panics in -CURRENT (from Feb 16). Both panics occured during high I/O rates. The first one occured while mkisofs'ing the resulting release CD tree, The second one while rm -rf RELEASEDIR. I am now running a kernel from Feb 08, which I believe is OK. I restarted a make release and will inform you if this kernel also panics. The relevant file system has soft updates enabled and was newfs'd with default argumengs (just the inode count was reduced). Background fsck is turned off, write cache is disabled. If you need more information, I can give additional detail. Thanks, Daniel - Kernel stacktrace from the first panic: IdlePTD at phsyical address 0x004c3000 initial pcb at physical address 0x003f3440 panicstr: allocbuf: buffer not busy panic messages: --- panic: softdep_disk_write_complete: lock is held syncing disks... panic: allocbuf: buffer not busy Uptime: 7h50m21s dumping to dev ad0b, offset 545184 [...] #0 0xc01e7cca in sysctl_kern_dumpdev (oidp=0xc0355c48, arg1=0x104, arg2=-1014061372, req=0x246) at ../../../kern/kern_shutdown.c:483 #1 0xc115754c in ?? () #2 0xc01e7a67 in boot (howto=260) at ../../../kern/kern_shutdown.c:333 #3 0xc01e7ef1 in panic (fmt=0xc0355c48 allocbuf: buffer not busy) at ../../../kern/kern_shutdown.c:619 #4 0xc021c3ad in allocbuf (bp=0xc38ea6c4, size=16384) at ../../../kern/vfs_bio.c:2418 #5 0xc021c32d in getblk (vp=0xd8334ec0, blkno=11305088, size=16384, slpflag=0, slptimeo=0) at ../../../kern/vfs_bio.c:2361 #6 0xc0219fdc in breadn (vp=0xd8334ec0, blkno=11305088, size=16384, rablkno=0x0, rabsize=0x0, cnt=0, cred=0x0, bpp=0xd7faeb14) at ../../../kern/vfs_bio.c:601 #7 0xc0219fa9 in bread (vp=0xd8334ec0, blkno=11305088, size=16384, cred=0x0, bpp=0xd7faeb14) at ../../../kern/vfs_bio.c:585 #8 0xc02bacd4 in ffs_update (vp=0xd8846900, waitfor=0) at ../../../ufs/ffs/ffs_inode.c:101 #9 0xc02c814a in ffs_fsync (ap=0xd7faeb8c) at ../../../ufs/ffs/ffs_vnops.c:293 #10 0xc02c6712 in ffs_sync (mp=0xc113c400, waitfor=2, cred=0xc0b2ec00, td=0xc03b7780) at ../../../ufs/ffs/ffs_vfsops.c:1050 #11 0xc02272b1 in sync (td=0xc03b7780, uap=0x0) at ../../../kern/vfs_syscalls.c:669 #12 0xc01e767f in boot (howto=256) at ../../../kern/kern_shutdown.c:237 #13 0xc01e7ef1 in panic ( fmt=0xc036d440 softdep_disk_write_complete: lock is held) at ../../../kern/kern_shutdown.c:619 #14 0xc02c2368 in softdep_disk_write_complete (bp=0xc38e29a4) at ../../../ufs/ffs/ffs_softdep.c:3466 #15 0xc021ca49 in bufdone (bp=0xc38e29a4) at ../../../kern/vfs_bio.c:2799 #16 0xc021f195 in cluster_callback (bp=0xc38d656c) at ../../../kern/vfs_cluster.c:551 #17 0xc021ca27 in bufdone (bp=0xc38d656c) at ../../../kern/vfs_bio.c:2789 #18 0xc021c982 in bufwait (bp=0xc38d656c) at ../../../kern/vfs_bio.c:2730 #19 0xc0173bdd in ad_interrupt (request=0xc187eb00) at ../../../sys/bio.h:106 #20 0xc0168fd2 in ata_intr (data=0xc10dd500) at ../../../dev/ata/ata-all.c:578 #21 0xc01d9ccf in ithread_loop (arg=0xc10e2900) at ../../../kern/kern_intr.c:529 #22 0xc01d8ec8 in fork_exit (callout=0xc01d9b34 swi_add+148, arg=0xc10e2900, frame=0xd7faed48) at ../../../kern/kern_fork.c:777 - the second panic: IdlePTD at phsyical address 0x004c3000 initial pcb at physical address 0x003f3440 panicstr: bwrite: buffer is not busy??? panic messages: --- panic: double fault syncing disks... panic: bwrite: buffer is not busy??? Uptime: 11h18m21s dumping to dev ad0b, offset 545184 [...] #0 0xc01e7cca in sysctl_kern_dumpdev (oidp=0xc0355918, arg1=0x104, arg2=537006244, req=0x4046) at ../../../kern/kern_shutdown.c:483 #1 0xc115754c in ?? () #2 0xc01e7a67 in boot (howto=260) at ../../../kern/kern_shutdown.c:333 #3 0xc01e7ef1 in panic (fmt=0xc0355918 bwrite: buffer is not busy???) at ../../../kern/kern_shutdown.c:619 #4 0xc021a1f3 in bwrite (bp=0xc38da6d4) at ../../../sys/systm.h:241 #5 0xc021b476 in vfs_bio_awrite (bp=0xc38da6d4) at ../../../kern/vfs_bio.c:1535 #6 0xc01b3c1c in spec_fsync (ap=0xc040ce24) at ../../../fs/specfs/spec_vnops.c:351 #7 0xc01b3805 in pfs_write (va=0xc040ce24) at ../../../fs/pseudofs/pseudofs_vnops.c:777 #8 0xc02c6930 in ffs_sync (mp=0xc113c400, waitfor=2, cred=0xc0b2ec00, td=0xc03b7780) at ../../../ufs/ffs/ffs_vfsops.c:1086 #9 0xc02272b1 in sync (td=0xc03b7780, uap=0x0) at ../../../kern/vfs_syscalls.c:669 #10 0xc01e767f in boot (howto=256) at ../../../kern/kern_shutdown.c:237 #11 0xc01e7ef1 in panic (fmt=0xc0379343 double fault) at ../../../kern/kern_shutdown.c:619 #12 0xc03106cb in dblfault_handler () at ../../../i386/i386/trap.c:871 - My dmesg output (from a kernel which i believe is OK): Copyright (c) 1992-2002 The FreeBSD Project. Copyright (c) 1979, 1980, 1983, 1986, 1988, 1989, 1991, 1992, 1993, 1994 The Regents of the University of California. All rights reserved. FreeBSD 5.0-CURRENT #624: Sat Feb 9 18:03:58 CET 2002 [EMAIL
Inconsistencies in *stat() for files with ACLs
Hi, lstat(), fstat(), stat() returned structure is inconsistent and misleading if the file has ACLs associated with it. Example: % getfacl test #file:test #owner:0 #group:4004 user::rw- group::r-- group:wheel:rw- mask::rw- other::r-- So the file has permissions rw-r--r--, but an additional group wheel has write permissions. But ls output suggests: % ls -l test -rw-rw-r-- 1 root rock 4 2 Dez 21:00 test that the primary group has these write permissions. But: % id uid=4024(rock) gid=4004(rock) % echo test test test: Permission denied. Daniel To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-current in the body of the message
Re: Inconsistencies in *stat() for files with ACLs
Robert Watson schrieb: On Sun, 2 Dec 2001, Daniel Rock wrote: Hi, lstat(), fstat(), stat() returned structure is inconsistent and misleading if the file has ACLs associated with it. That behavior is defined by POSIX.1e, so it's what we implemented; you'll find that the same behavior is present on other platforms with conforming implementations. I can only check it with Solaris (Solaris 8). Solaris' output of lstat() is just what I would expect: % getfacl bla # file: bla # owner: root # group: rock user::rw- group::r-- #effective:r-- group:install:rw- #effective:rw- mask:rwx other:r-- % ls -l bla -rw-r--r--+ 1 root rock 2 Dez 3 01:26 bla and lstat(bla, st) returns st.st_mode = 0100644 - but group install has write permissions. But according to standards(5) Solaris 8 doesn't claim to be POSIX.1e compliant. I'll give Solaris 9 a try. It actually does make some sense, when you think about it: POSIX.1e requires that the group permissions returned by stat() be the ACL_MASK entry if an extended ACL is present. That means that stat() displays the worst case protections. Likewise, the spec requires that chmod() modify the ACL_MASK entry if an extended ACL is present, which gives you conservative behavior: if group write is removed, the right thing happens. For example, if you chmod 0600 on the file, it works: POSIX.1e considers the extended ACL to expand the group entry of the permissions. Intuitive would be: stat() returns the primary group in st_gid and no additional groups. So I'd expect st_mode match permissions of this specific group. That said, I won't argue it's intuitive unless you know about the behavior already, and it probably should be documented in the stat(2) man page. If you're interested in discussing these semantics, it might be worth raising it on the POSIX.1e mailing list ([EMAIL PROTECTED]). A number of people involved in writing the spec are there, and in the past it has been a successful forum for discussing ambiguities (not to mention mistakes) in the spec. I don't have access to the POSIX spec. I only found some early drafts. Without detailed knowledge of these internals I wouldn't be a good participant in this discussion. But what about some additions to ls: In Solaris - if the file has additional ACLs - the permissions are followed by a plus sign (see above). So you know: To get full information you have to use getfacl. Daniel To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-current in the body of the message
panic in ipfw code
Hi,
I wondered nobody noticed this bug so far.
The kernel panics if you feed him with unnumbered firewall rules
(like ipfw add allow all from any to any)
Fix is simple. In the code the wrong loop variable was used:
Index: ip_fw.c
===
RCS file: /data/cvs/src/sys/netinet/ip_fw.c,v
retrieving revision 1.170
diff -u -r1.170 ip_fw.c
--- ip_fw.c 27 Sep 2001 23:44:26 - 1.170
+++ ip_fw.c 1 Oct 2001 17:20:39 -
@@ -1654,9 +1654,9 @@
/* If entry number is 0, find highest numbered rule and add 100 */
if (ftmp-fw_number == 0) {
- LIST_FOREACH(ftmp, head, next) {
- if (ftmp-fw_number != IPFW_DEFAULT_RULE)
- nbr = ftmp-fw_number;
+ LIST_FOREACH(fcp, head, next) {
+ if (fcp-fw_number != IPFW_DEFAULT_RULE)
+ nbr = fcp-fw_number;
else
break;
}
--
Daniel
To Unsubscribe: send mail to [EMAIL PROTECTED]
with unsubscribe freebsd-current in the body of the message
Syntax change in ppp?
Hi, after the latest updates I just noticed a different behaviour of ppp. in /etc/ppp/ppp.linkup I had an additional line iface clear for my profile to get rid of stuffed up IP pairs. After the latest update this entry also clears my defaultroute, but only after redialing. I now had to put the iface clear into /etc/ppp/ppp.linkdown, but then the old IP pair is still there during the next connection. Were my assumptions wrong (regarding the iface clear command) or is something broken in ppp? I have an idea which might cause the accidential removal of the defaultroute after redialing: Before the first connection I have to set a dummy IP pair: set ifaddr 172.23.11.1/0 172.23.11.2/0 255.255.255.255 0.0.0.0 so my defaulroute will be set to 172.23.11.2 After dialing I'm getting a different destination IP address from my provider, and the old route will be deleted: route del $OLDADDR But after that, even if my own address will be different, the destination address will be the same: tun0: flags=8051UP,POINTOPOINT,RUNNING,MULTICAST mtu 1492 inet6 fe80::2e0:7dff:fe75:fdfb%tun0 prefixlen 64 scopeid 0x6 inet 217.224.28.71 -- 217.5.98.90 netmask 0x inet 217.224.27.153 -- 217.5.98.90 netmask 0x so after executing iface clear from /etc/ppp/ppp.linkup, ppp will also delete the old route - but this time the old route is the same as the current one. BTW: If I disable IPv6 in the kernel, ppp won't start at all. It will spit out tons of messages Error: iface_Add: socket(): Protocol not supported Daniel To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-current in the body of the message
Re: Syntax change in ppp?
Brian Somers schrieb: Hi, after the latest updates I just noticed a different behaviour of ppp. in /etc/ppp/ppp.linkup I had an additional line iface clear for my profile to get rid of stuffed up IP pairs. After the latest update this entry also clears my defaultroute, but only after redialing. I now had to put the iface clear into /etc/ppp/ppp.linkdown, but then the old IP pair is still there during the next connection. Putting ``iface clear'' in ppp.linkup will result in the whole iface-alias thing being broken. It's meant to be in ppp.linkdown. The objective is that ppp, once connected, has two IP numbers on the interface, one for what was there before the connection completed and one for the negotiated IP address. When this happens, the ``first connection'' continues to work (the process that caused the dial-up will be bound to the IP number that was on the interface when it started and the nat engine will tweak these packets so that they use the negotiated IP number). Suppose on the first connection I got the IP pair A - B and on the second C - D while the second one still active another person will get A - B assigned by our ISP. Will I be able to talk with A or B? Or will they point back to myself? I put the iface clear in ppp.linkup for exactly this case. So really, you're doing the equivalent of ``disable iface-alias'' and stopping your first connection from working. Moving the ``iface clear'' to ppp.linkdown should be better. Were my assumptions wrong (regarding the iface clear command) or is something broken in ppp? Yes and yes. Hmm, I didn't notice any problems before the last commit... Any automatic connection (even the first) worked without any problems. But: iface clear just went from ppp.linkdown to ppp.linkup some weeks ago, but after I got DSL. With DSL the destination IP address is always the same. I don't know if this configuration would work with my old ISDN access with changing destination IP addresses. [...] When IPCP comes up, ppp adds the new address to the interface. It's *meant* to change the old interface destination address to 255.255.255.255, but is getting this wrong. Then, as you've already spotted, when your ``iface clear'' is run, it blows away the default route. I've just committed a fix for this. It's in version 1.25 of iface.c. BTW: If I disable IPv6 in the kernel, ppp won't start at all. It will spit out tons of messages Error: iface_Add: socket(): Protocol not supported Yep, a fix for that was committed a few days ago too. My apologies. Oh, I just discovered that cvsup didn't update my tree for 3 days. Everything works ok again - even the things which weren't design to work at all. -- Daniel To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-current in the body of the message
Re: ACPI: Clock problems in -current
Mike Smith schrieb: Er. Interesting. Doing some reading up on the M1533, I notice that the power management component isn't actually listed here: ohci0@pci0:2:0: class=0x0c0310 card=0x chip=0x523710b9 rev=0x03 hdr=0x00 vendor = 'Acer Labs Inc.' device = 'ALI M5237 USB Host Controller' class= serial bus subclass = USB isab0@pci0:7:0: class=0x060100 card=0x chip=0x153310b9 rev=0xc3 hdr=0x00 vendor = 'Acer Labs Inc.' device = 'M1533 PCI South Bridge' class= bridge subclass = PCI-ISA atapci0@pci0:15:0:class=0x0101fa card=0x chip=0x522910b9 rev=0xc1 hdr=0x00 vendor = 'Acer Labs Inc.' device = 'M1543 Southbridge EIDE Controller' class= mass storage subclass = ATA There should be a device at pci0:3:0, something like: none0@pci0:3:0: class=0x?? card=0x chip=0x710110b9 rev=0x?? hdr=0x00 vendor = 'Acer Labs Inc.' device = 'M7101 PCI PMU Power Management Controller' ... Check that you have ACPI/power management turned on in your BIOS setup; that's typically responsible for enabling/disabling this device... One page in the BIOS setup is dedicated for Power Management (standard AWARD BIOS 4.51). Power Management is set to Enable Second option is PM control by APM I tried both option (Yes/No), but no difference. Most other options are set to Disable (HDD power down, Wake Up events, etc.) Maybe this is an early revision of the chipset. The board is from mid 1998. I try to find an unused disk drive and install Windows on it to run the ACPI validation test suite. But this will take some time - you may expect results at the end of this week. The installed BIOS version was specificially released to allow a Windows 2000 ACPI mode installation. -- Daniel To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-current in the body of the message
Re: ACPI: Clock problems in -current
Mike Smith schrieb: Ok. I'm going to revert to the safe read code in a few minutes. Can you update and let me know if you're still wildly off? I'm having a hard time believing that your timer is really running at double pace, but I guess anything is possible. If it still does, I'll add some code to check it with the TSC. Hmm, just did the update unset debug.acpi.disable=timer but the error is still there. Meaning no offense, but I read a lot of mail. Can you please keep your problem reports specific? (ie. which bloody error?) Thanks. No problem, Tried -CURRENT (from yesterday), esp. src/sys/dev/acpica/acpi_timer.c,v 1.9 If I boot without debug.acpi.disable=timer clock and rtc interrupts run at half the normal rate (50 clock/64 rtc instead of 100/128) with all the usual results: - System time (via gettimeofday()) runs at double rate - Tons of calcru: negative time of ... - Even more of microuptime() went backwards - negative running time of some processes if cpu bound processes are run at the same time. I have to set set debug.acpi.disable=timer during bootup to get normal running clock interrupts. Maybe I'm just having a buggy ACPI implementation (remember, BIOS is from '99) Could be, though we're talking hardware here. It's possible that we'll just have to blacklist your timer. 8( Can you give me the ALi chip number(s) again, and I'll go look for datasheets... Ok, output of pciconf -lv attached. System board: GigaByte GA-5AX with latest BIOS (F3 released Dec, 15 1999) Daniel agp0@pci0:0:0: class=0x06 card=0x154110b9 chip=0x154110b9 rev=0x04 hdr=0x00 vendor = 'Acer Labs Inc.' device = 'M1541 Aladdin V AGPset Host Bridge' class= bridge subclass = HOST-PCI pcib1@pci0:1:0: class=0x060400 card=0x00e0 chip=0x524310b9 rev=0x04 hdr=0x01 vendor = 'Acer Labs Inc.' device = 'ALI M1541 PCI to AGP Bridge' class= bridge subclass = PCI-PCI ohci0@pci0:2:0: class=0x0c0310 card=0x chip=0x523710b9 rev=0x03 hdr=0x00 vendor = 'Acer Labs Inc.' device = 'ALI M5237 USB Host Controller' class= serial bus subclass = USB isab0@pci0:7:0: class=0x060100 card=0x chip=0x153310b9 rev=0xc3 hdr=0x00 vendor = 'Acer Labs Inc.' device = 'M1533 PCI South Bridge' class= bridge subclass = PCI-ISA none0@pci0:8:0: class=0x04 card=0x chip=0x0002121a rev=0x02 hdr=0x00 vendor = '3dfx Interactive Inc' device = 'Voodoo2 Voodoo 2 3D Accelerator' class= multimedia subclass = video sym0@pci0:9:0: class=0x01 card=0x chip=0x00041000 rev=0x04 hdr=0x00 vendor = 'LSI Logic' device = '53C815 Fast SCSI' class= mass storage subclass = SCSI rl0@pci0:10:0: class=0x02 card=0x813910ec chip=0x813910ec rev=0x10 hdr=0x00 vendor = 'Realtek Semiconductor' device = 'RT8139 (A/B/C/8130) Fast Ethernet Adapter' class= network subclass = ethernet fxp0@pci0:11:0: class=0x02 card=0x00098086 chip=0x12298086 rev=0x05 hdr=0x00 vendor = 'Intel Corporation' device = '82557/8/9 Fast Ethernet LAN Controller' class= network subclass = ethernet atapci0@pci0:15:0: class=0x0101fa card=0x chip=0x522910b9 rev=0xc1 hdr=0x00 vendor = 'Acer Labs Inc.' device = 'M1543 Southbridge EIDE Controller' class= mass storage subclass = ATA none1@pci1:0:0: class=0x03 card=0x001c105d chip=0x493d105d rev=0x00 hdr=0x00 vendor = 'Number Nine Visual Technology' device = 'T2R Revolution 3D' class= display subclass = VGA
Re: ACPI: Clock problems in -current
Mike Smith schrieb: I forgot: Even if I define CLK_USE_*_CALIBRATION (and get no error messages after defining debug.acpi.timer_test), the Off/2 error still persist. Ok. I'm going to revert to the safe read code in a few minutes. Can you update and let me know if you're still wildly off? I'm having a hard time believing that your timer is really running at double pace, but I guess anything is possible. If it still does, I'll add some code to check it with the TSC. Hmm, just did the update unset debug.acpi.disable=timer but the error is still there. Maybe I'm just having a buggy ACPI implementation (remember, BIOS is from '99) -- Daniel To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-current in the body of the message
Re: ACPI: Clock problems in -current
Daniel Rock schrieb: Mike Smith schrieb: acpi0: GBTAWRDACPI on motherboard acpi0: power button is handled as a fixed feature programming model. acpi_timer0: timer test in progress, reboot to quit. acpi_timer0: timer is not monotonic: 0x1d52ab49,0x1d52ab4f,0x1d52ab4e acpi_timer0: timer is not monotonic: 0x1d52ab4f,0x1d52ab4e,0x1d5b89ea Excellent. I'll try to get something sorted out about this tonight. How long does it take before it prints the first message there? The messages are printed out almost immediately, but only if I don't set any of CLK_USE_*_CALIBRATION in my configuration. There will be only one step backwards (the longest time waiting was ~ 1 minute. In the case of CLK_USE_*_CALIBRATION defined I waited 10 minutes but got no output). I forgot: Even if I define CLK_USE_*_CALIBRATION (and get no error messages after defining debug.acpi.timer_test), the Off/2 error still persist. -- Daniel To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-current in the body of the message
Re: ACPI: Clock problems in -current
Mike Smith schrieb: acpi0: GBTAWRDACPI on motherboard acpi0: power button is handled as a fixed feature programming model. acpi_timer0: timer test in progress, reboot to quit. acpi_timer0: timer is not monotonic: 0x1d52ab49,0x1d52ab4f,0x1d52ab4e acpi_timer0: timer is not monotonic: 0x1d52ab4f,0x1d52ab4e,0x1d5b89ea Excellent. I'll try to get something sorted out about this tonight. How long does it take before it prints the first message there? The messages are printed out almost immediately, but only if I don't set any of CLK_USE_*_CALIBRATION in my configuration. There will be only one step backwards (the longest time waiting was ~ 1 minute. In the case of CLK_USE_*_CALIBRATION defined I waited 10 minutes but got no output). -- Daniel To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-current in the body of the message
Re: ACPI: Clock problems in -current
Mike Smith schrieb: [...] Unfortunately, I can't reproduce the problem here - the new timer seems to be working just fine. Can anyone seeing this please let me know: - What power management hardware your system has: look at the output of pciconf -lv for a power management controller, eg: This machine has no separate controller. Attached is the complete output of pciconf -lv - which timecounter is in use on your system, eg: mass# sysctl kern.timecounter.hardware kern.timecounter.hardware: ACPI During the Off/2 errors this variable contained ACPI - whether you are seeing any *time went backwards console messages. Tons of, even with negative CPU-Usage times. Interesting enough, a sleep 10 sleeps 10 real seconds: % date; sleep 10; date Mo 30 Jul 2001 19:27:07 CEST [...10 seconds delay...] Mo 30 Jul 2001 19:27:27 CEST -- Daniel agp0@pci0:0:0: class=0x06 card=0x154110b9 chip=0x154110b9 rev=0x04 hdr=0x00 vendor = 'Acer Labs Inc.' device = 'M1541 Aladdin V AGPset Host Bridge' class= bridge subclass = HOST-PCI pcib1@pci0:1:0: class=0x060400 card=0x00e0 chip=0x524310b9 rev=0x04 hdr=0x01 vendor = 'Acer Labs Inc.' device = 'ALI M1541 PCI to AGP Bridge' class= bridge subclass = PCI-PCI ohci0@pci0:2:0: class=0x0c0310 card=0x chip=0x523710b9 rev=0x03 hdr=0x00 vendor = 'Acer Labs Inc.' device = 'ALI M5237 USB Host Controller' class= serial bus subclass = USB isab0@pci0:7:0: class=0x060100 card=0x chip=0x153310b9 rev=0xc3 hdr=0x00 vendor = 'Acer Labs Inc.' device = 'M1533 PCI South Bridge' class= bridge subclass = PCI-ISA none0@pci0:8:0: class=0x04 card=0x chip=0x0002121a rev=0x02 hdr=0x00 vendor = '3dfx Interactive Inc' device = 'Voodoo2 Voodoo 2 3D Accelerator' class= multimedia subclass = video sym0@pci0:9:0: class=0x01 card=0x chip=0x00041000 rev=0x04 hdr=0x00 vendor = 'LSI Logic' device = '53C815 Fast SCSI' class= mass storage subclass = SCSI rl0@pci0:10:0: class=0x02 card=0x813910ec chip=0x813910ec rev=0x10 hdr=0x00 vendor = 'Realtek Semiconductor' device = 'RT8139 (A/B/C/8130) Fast Ethernet Adapter' class= network subclass = ethernet fxp0@pci0:11:0: class=0x02 card=0x00098086 chip=0x12298086 rev=0x05 hdr=0x00 vendor = 'Intel Corporation' device = '82557/8/9 Fast Ethernet LAN Controller' class= network subclass = ethernet atapci0@pci0:15:0: class=0x0101fa card=0x chip=0x522910b9 rev=0xc1 hdr=0x00 vendor = 'Acer Labs Inc.' device = 'M1543 Southbridge EIDE Controller' class= mass storage subclass = ATA none1@pci1:0:0: class=0x03 card=0x001c105d chip=0x493d105d rev=0x00 hdr=0x00 vendor = 'Number Nine Visual Technology' device = 'T2R Revolution 3D' class= display subclass = VGA
Re: ACPI: Clock problems in -current
Mike Smith schrieb: Say set debug.acpi.disable=timer in the bootloader and see if you still get this. I've already got one report of system time going twice as fast as it should; I'm unsure what's going on here (I don't grok the timecounter code as well as I should, I think)... This helps. You could also try building a kernel with CLK_CALIBRATION_LOOP defined and then booting with -v (without the timer disabled). This might be instructive (I don't know for certain that it'll calibrate the ACPI timer, since it may not have been probed yet). Calibrating clock(s) ... TSC clock: 300684467 Hz, i8254 clock: 1193192 Hz Calibrating clock(s) ... TSC clock: 300685043 Hz, i8254 clock: 1193195 Hz Calibrating clock(s) ... TSC clock: 300684395 Hz, i8254 clock: 1193192 Hz Calibrating clock(s) ... TSC clock: 300684395 Hz, i8254 clock: 1193192 Hz Timecounter i8254 frequency 1193190 Hz CPU: AMD-K6(tm) 3D processor (300.68-MHz 586-class CPU) Origin = AuthenticAMD Id = 0x580 Stepping = 0 -- Daniel To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-current in the body of the message
Re: ACPI: Clock problems in -current
Mike Smith schrieb: Calibrating clock(s) ... TSC clock: 300684467 Hz, i8254 clock: 1193192 Hz Hrm. Drat. You're running on an K6, and ACPI is working for you? I'm impressed; I guess this is a fairly new motherboard? No, it is an at least 3 years old GigaByte GA-5AX (Ali Aladdin V). Even the BIOS is from December 1999. -- Daniel To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-current in the body of the message
ACPI: Clock problems in -current
Hi, just noticed with a -current from yesterday (today's -current has the same problem). After bootup I will see tons of calcru: negative time of -953757 usec for pid 636 (make) calcru: negative time of -820616 usec for pid 636 (make) microuptime() went backwards (1969.4485199 - 1969.552693) microuptime() went backwards (1969.4485199 - 1969.690311) messages, together with processes with a negative CPU usage time. Something is going wrong during setting clock interrupts. A vmstat -i shows (among other interrupts): clk irq079496 49 rtc irq8 101753 63 which is about half the rate it should be. The latest working kernel I was booting before was from Jul, 13th If I disable ACPI in the kernel the interrupt rate is back to normal. ACPI related boot messages: acpi0: GBTAWRDACPI on motherboard acpi0: power button is handled as a fixed feature programming model. acpi_timer0: 32-bit timer at 3.579545MHz port 0x4008-0x400b on acpi0 acpi_cpu0: CPU on acpi0 acpi_button0: Power Button on acpi0 acpi_pcib0: Host-PCI bridge on acpi0 pci0: PCI bus on acpi_pcib0 acpi_cpu0: set speed to 100.0% acpi_cpu: CPU throttling enabled, 2 steps from 100% to 50.0% Mainboard is a GigaByte GA-5AX with F3 BIOS. I will provide further configuration information if needed. -- Daniel To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-current in the body of the message
Tekram DC3x5 driver and -CURRENT
Hi, there exists a Tekram SCSI driver, which doesn't have an NCR/SymBIOS/LSILogic or AMD chip. On the Tekram FTP site you can download a driver for FreeBSD though. Unfortunately, the latest one is for 4.x, which won't work on a current -CURRENT system. Perhaps this driver should be integrated into the main tree, so it can be actively maintained. I just have newbus'ified the driver and it seems to work in my machine, but I am no FreeBSD kernel hacker. I don't have the slightest idea what I have done. I just generated some diff's from other drivers which have been newbus'ified recently and did the same steps. If some brave man is still interested I can mail him the modifications or post them here. -- Daniel To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
Unstable ISDN with interrupt preemption?
Hi, I just noticed very unstable ISDN connections since the introduction of preempted interrupt threads (Jan 31st). Most errors are uncritical though, an active connection continues to work, sometimes I have to restart isdnd, and sometimes I even have to reboot the machine. The "i4b-L1 isic_hscx_waitxfw: HSCX wait for XFW timeout!" seem to have been introduced by the SMPng code, but with interrupt preemption they appear more often (I switched th SMPng on Jan 25th) As you can also see on the output: On Feb 9th I rebooted the machine with a newly built kernel. All other errors besides the one mentioned above suddenly disappeared. A quick look at the change logs revealed: preemption was accidently removed for interrupt threads on Feb 9th - and reintroduced a few hours later. It seems I was running such a kernel for a week (Feb 9th - 18th) Anyone else having the same problem? -- Daniel Jan 27 18:24:08 gate /boot/kernel/kernel: i4b-L1 isic_hscx_waitxfw: HSCX wait for XFW timeout! Jan 28 06:26:32 gate /boot/kernel/kernel: i4b-L1 isic_hscx_waitxfw: HSCX wait for XFW timeout! Feb 3 00:26:13 gate /boot/kernel/kernel: i4b-L1 isic_hscx_waitxfw: HSCX wait for XFW timeout! Feb 3 12:23:38 gate /boot/kernel/kernel: i4b-L1 isic_hscx_waitxfw: HSCX wait for XFW timeout! Feb 3 12:33:38 gate /boot/kernel/kernel: i4b-L1 isic_hscx_waitxfw: HSCX wait for XFW timeout! Feb 3 12:35:38 gate /boot/kernel/kernel: i4b-L1 isic_hscx_waitxfw: HSCX wait for XFW timeout! Feb 3 14:53:38 gate /boot/kernel/kernel: i4b-L1 isic_hscx_waitxfw: HSCX wait for XFW timeout! Feb 3 15:05:00 gate /boot/kernel/kernel: i4b-L1 isic_hscx_waitxfw: HSCX wait for XFW timeout! Feb 3 15:26:08 gate /boot/kernel/kernel: i4b-L1 isic_hscx_waitxfw: HSCX wait for XFW timeout! Feb 6 00:26:15 gate /boot/kernel/kernel: i4b-L1 isic_hscx_waitxfw: HSCX wait for XFW timeout! Feb 6 12:14:49 gate /boot/kernel/kernel: i4b-L2 i4b_rxd_ack: ((N(R)-1)=115) != (UA=116) !!! Feb 7 00:19:47 gate /boot/kernel/kernel: i4b-L1 isic_hscx_waitxfw: HSCX wait for XFW timeout! Feb 7 06:21:56 gate /boot/kernel/kernel: i4b-L1 isic_hscx_waitxfw: HSCX wait for XFW timeout! Feb 7 06:27:56 gate /boot/kernel/kernel: i4b-L1 isic_hscx_waitxfw: HSCX wait for XFW timeout! Feb 7 12:24:55 gate /boot/kernel/kernel: i4b-L1 isic_hscx_waitxfw: HSCX wait for XFW timeout! Feb 7 21:54:51 gate /boot/kernel/kernel: i4b-L1 isic_hscx_waitxfw: HSCX wait for XFW timeout! Feb 8 00:24:50 gate /boot/kernel/kernel: i4b-L1 isic_hscx_waitxfw: HSCX wait for XFW timeout! Feb 8 00:31:50 gate /boot/kernel/kernel: i4b-L1 isic_hscx_waitxfw: HSCX wait for XFW timeout! Feb 9 20:53:51 gate /boot/kernel/kernel: i4b-L1 isic_hscx_waitxfw: HSCX wait for XFW timeout! Feb 9 20:53:51 gate /boot/kernel/kernel: i4b-L1 isic_hscx_waitxfw: HSCX wait for XFW timeout! Feb 9 21:07:33 gate /boot/kernel/kernel: i4b-L1 isic_isac_exir_hdlr: EXIRQ Rx Frame Overflow Feb 9 21:13:56 gate /boot/kernel/kernel: i4b-L2 i4b_T200_timeout: unit 0, RC = 0 Feb 9 21:14:25 gate /boot/kernel/kernel: i4b-L3 T305_timeout: DISC not answered, cr = 126 Feb 9 21:14:26 gate /boot/kernel/kernel: i4b-L3 T308_timeout: REL not answered, cr = 126 Feb 9 21:14:36 gate /boot/kernel/kernel: i4b-L3 T303_timeout: SETUP not answered, cr = 108 Feb 9 21:17:44 gate /boot/kernel/kernel: i4b-L2 i4b_T200_timeout: unit 0, RC = 0 Feb 9 21:17:44 gate /boot/kernel/kernel: i4b-L2 F_ILL: FSM function F_ILL executing Feb 9 21:17:44 gate /boot/kernel/kernel: i4b-L2 i4b_next_l2state: FSM illegal state, state = ST_TEI_UNAS, event = EV_T200EXP! Feb 9 21:17:49 gate /boot/kernel/kernel: i4b-L2 i4b_i_frame_queued_up: ERROR, mbuf NULL after IF_DEQUEUE Feb 9 21:17:49 gate /boot/kernel/kernel: i4b-L2 i4b_i_frame_queued_up: ERROR, mbuf NULL after IF_DEQUEUE Feb 10 18:24:22 gate /boot/kernel/kernel: i4b-L1 isic_hscx_waitxfw: HSCX wait for XFW timeout! Feb 13 18:20:48 gate /boot/kernel/kernel: i4b-L1 isic_hscx_waitxfw: HSCX wait for XFW timeout! Feb 16 18:21:03 gate /boot/kernel/kernel: i4b-L1 isic_hscx_waitxfw: HSCX wait for XFW timeout! Feb 18 00:24:59 gate /boot/kernel/kernel: i4b-L1 isic_isac_exir_hdlr: EXIRQ Rx Frame Overflow Feb 18 00:25:59 gate /boot/kernel/kernel: i4b-L1 isic_isac_exir_hdlr: EXIRQ Rx Frame Overflow Feb 18 02:05:00 gate /boot/kernel/kernel: i4b-L1 isic_isac_exir_hdlr: EXIRQ Rx Frame Overflow Feb 18 02:05:00 gate /boot/kernel/kernel: i4b-L1 isic_isac_exir_hdlr: EXIRQ Rx Frame Overflow Feb 18 02:23:05 gate /boot/kernel/kernel: i4b-L1 isic_isac_exir_hdlr: EXIRQ Rx Frame Overflow Feb 18 02:23:05 gate /boot/kernel/kernel: i4b-L2 i4b_mdl_error_ind: unit = 0, location = F_MF07 Feb 18 02:23:05 gate /boot/kernel/kernel: i4b-L2 i4b_mdl_error_ind: error = MDL_ERR_F: peer initiated re-establishment - SABME Feb 19 00:27:30 gate /boot/kernel/kernel: i4b-L1 isic_hscx_waitxfw: HSCX wait for XFW timeout! Feb 19 23:35:50 gate /boot/kernel/kernel: i4b-L1 isic_hscx_waitxfw: HSCX wait for XFW timeout! Feb 20 18:25:00 gate
Re: as segfaulting during world-build
Warner Losh schrieb: In message [EMAIL PROTECTED] Daniel Rock writes: : I did have the same problem. But just rebuilding binutils didn't help either. : Trying to rebuild libc resulted in above SEGV from as. Some sort of Catch 22 Find a libc from before Feb 10th or after Feb 21 and put it on your system. Yes I know, I already posted another solution: Just use another /usr/lib/libc.so.4 for rebuilding libc.so.5 Sometimes you just have at this time no working internet connection - and you simply cannot find your backup tapes you never made. So I came around the trick with an older libc.so.4, which seems to be "compatible enough" to let me rebuild libc. -- Daniel To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
Re: HEADS UP Re: cvs commit: src/sys/alpha/alpha trap.c src/sys/dev/acpica/Osd OsdSchedule.c src/sys/i386/i386 genassym.c swtch.strap.c src/sys/ia64/ia64 trap.c src/sys/kern init_main.c kern_condvar.ckern_idle.c kern_intr.c kern_mib.c kern_mutex.c kern_proc.c ...
Bruce Evans schrieb: On Thu, 22 Feb 2001, Daniel Rock wrote: You may have forgotten to also change KINFO_PROC_SIZE in src/sys/user.h Yes, rev.1.31 of src/sys/sys/user.h leaves it as an exercise to change KINFO_PROC_SIZE. I hate doing such exercises, since it will be followed by some nasty other exercises: Clean up your conflicting cvs files... WARNING: size of kinfo_proc (648) should be 644!!! This is normal if you haven't done the exercise. It is just a warning. This seems to be a "non required" exercise, since even if you fail solving it, your machine continues working... BTW What is the purpose of KINFO_PROC_SIZE? Why not simply using sizeof()? It is to inhibit changes in the size of the struct. Such changes would break the interface. The struct must have a certain fixed size (and layout) for binary compatibility. sizeof() would give the current size, not necessarily the size that is required for compatibility. But: Since the introduction of KINFO_PROC_SIZE (rev. 1.27(?) of src/sys/sys/user.h) there have been two modifications which still required to rebuild libkvm, ... Maybe many people won't use the spare entries at the end of the structure but put their additions somewhere besides some other related variables for aesthetical purposes? Which value does libkvm use? KINFO_PROC_SIZE or sizeof()? It seems it uses sizeof() since ps/top/w still work besides the warning message. -- Daniel To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
Re: as segfaulting during world-build
Szilveszter Adam schrieb: On Tue, Feb 20, 2001 at 11:27:17AM -0500, Mikhail Teterin wrote: No, I don't think it is hardware. It died on the same spot for the third time in a row: ... What date is the -CURRENT you are attempting the build on from? There were problems with as failing for a while not long ago. Check your version of src/lib/libc/stdio/findfp.c (the installed one...) to see if it is revision 1.15 or later. If not, you will have to get a working as (and as reported by Martin Blapp, the other binutiles in /usr/bin/ and /usr/libexec/elf too) from somwhere like an ftp snapshot... if this is not the problem, I dunno, I did not have any such problems even though I have just finished a buildworld. I did have the same problem. But just rebuilding binutils didn't help either. Trying to rebuild libc resulted in above SEGV from as. Some sort of Catch 22 I didn't have a working libc.so.5, so I just did the following: % cp /usr/lib/libc.so.4 /tmp/libc.so.5 [Maybe it's in /usr/lib/compat - I even found a libc.so.3 in /usr/lib. Hasn't been reinstalled since Mid 1998] % cd /usr/src/lib/libc; LD_LIBRARY_PATH=/tmp make all install -- Daniel To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
Re: HEADS UP Re: cvs commit: src/sys/alpha/alpha trap.c src/sys/dev/acpica/Osd OsdSchedule.c src/sys/i386/i386 genassym.c swtch.s trap.c src/sys/ia64/ia64 trap.c src/sys/kern init_main.c kern_condvar.c kern_idle.c kern_intr.c kern_mib.c kern_mutex.c kern_proc.c ...
Jake Burkholder schrieb: [...] As I mentioned in the commit message, this changes the size and layout of struct kinfo_proc, so you'll have to recompile libkvm-using programs. As always, make world is your friend. You may have forgotten to also change KINFO_PROC_SIZE in src/sys/user.h I'm now getting bootup warning all the time: ... real memory = 197066752 (192448K bytes) avail memory = 187293696 (182904K bytes) Preloaded elf kernel "kernel" at 0xc045. WARNING: size of kinfo_proc (648) should be 644!!! Pentium Pro MTRR support enabled ... BTW What is the purpose of KINFO_PROC_SIZE? Why not simply using sizeof()? -- Daniel To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
Re: number of processes forked since boot
Hajimu UMEMOTO schrieb:
Hi,
I wish to obtain number of processes forked since boot from userland.
So, I made a patch to intend to commit.
Any comment?
I have done a similar approach. I was inspired by the "vmstat -s" output of
Solaris.
Therefor my solution was integrated into the vmmeter structure. Adding sysctl
variables
would be trivial though.
Warning: The diff is from a very old source tree. It may not apply cleanly.
But
the modifications are trivial and should be easily spotted.
--
Daniel
Index: sys/kern/kern_exec.c
===
RCS file: /data/cvs/src/sys/kern/kern_exec.c,v
retrieving revision 1.116
diff -u -r1.116 kern_exec.c
--- sys/kern/kern_exec.c2000/09/21 09:04:17 1.116
+++ sys/kern/kern_exec.c2000/09/21 17:34:09
@@ -47,6 +47,7 @@
#include sys/shm.h
#include sys/sysctl.h
#include sys/vnode.h
+#include sys/vmmeter.h
#include vm/vm.h
#include vm/vm_param.h
@@ -374,7 +375,10 @@
}
if (error == 0)
+ {
+ ++cnt.v_exec;
return (0);
+ }
exec_fail:
if (imgp-vmspace_destroyed) {
Index: sys/kern/kern_fork.c
===
RCS file: /data/cvs/src/sys/kern/kern_fork.c,v
retrieving revision 1.82
diff -u -r1.82 kern_fork.c
--- sys/kern/kern_fork.c2000/09/14 23:07:39 1.82
+++ sys/kern/kern_fork.c2000/09/15 23:07:29
@@ -55,6 +55,7 @@
#include sys/ktr.h
#include sys/ktrace.h
#include sys/unistd.h
+#include sys/vmmeter.h
#include sys/jail.h
#include vm/vm.h
@@ -105,6 +106,7 @@
if (error == 0) {
p-p_retval[0] = p2-p_pid;
p-p_retval[1] = 0;
+ ++cnt.v_fork;
}
return error;
}
@@ -122,6 +124,7 @@
if (error == 0) {
p-p_retval[0] = p2-p_pid;
p-p_retval[1] = 0;
+ ++cnt.v_vfork;
}
return error;
}
Index: sys/sys/vmmeter.h
===
RCS file: /data/cvs/src/sys/sys/vmmeter.h,v
retrieving revision 1.21
diff -u -r1.21 vmmeter.h
--- sys/sys/vmmeter.h 1999/12/29 04:24:49 1.21
+++ sys/sys/vmmeter.h 1999/12/31 02:41:29
@@ -92,6 +92,9 @@
u_int v_pageout_free_min; /* min number pages reserved for kernel */
u_int v_interrupt_free_min; /* reserved number of pages for int code */
u_int v_free_severe;/* severe depletion of pages below this pt */
+ u_int v_fork;
+ u_int v_vfork;
+ u_int v_exec;
};
#ifdef _KERNEL
Index: usr.bin/vmstat/vmstat.c
===
RCS file: /data/cvs/src/usr.bin/vmstat/vmstat.c,v
retrieving revision 1.39
diff -u -r1.39 vmstat.c
--- usr.bin/vmstat/vmstat.c 2000/05/05 16:07:10 1.39
+++ usr.bin/vmstat/vmstat.c 2000/05/07 21:11:18
@@ -599,6 +599,12 @@
(void)printf("%9u cpu context switches\n", sum.v_swtch);
(void)printf("%9u device interrupts\n", sum.v_intr);
(void)printf("%9u software interrupts\n", sum.v_soft);
+ (void)printf("%9u forks\n", sum.v_fork);
+ (void)printf("%9u vforks\n", sum.v_vfork);
+ (void)printf("%9u execs\n", sum.v_exec);
+#ifdef vax
+ (void)printf("%9u pseudo-dma dz interrupts\n", sum.v_pdma);
+#endif
(void)printf("%9u traps\n", sum.v_trap);
(void)printf("%9u system calls\n", sum.v_syscall);
(void)printf("%9u swap pager pageins\n", sum.v_swapin);
@@ -731,7 +737,7 @@
errx(1, "malloc");
kread(X_INTRCNT, intrcnt, (size_t)nintr);
kread(X_INTRNAMES, intrname, (size_t)inamlen);
- (void)printf("interrupt total rate\n");
+ (void)printf("interrupttotal rate\n");
inttotal = 0;
nintr /= sizeof(long);
while (--nintr = 0) {
Re: ISA PnP resource allocation
Warner Losh schrieb:
In message [EMAIL PROTECTED] Daniel Rock writes:
: I already filed a PR for this problem but my first solution was a real
: hack (kern/21461).
:
: [another solution would be to introduce another flag for
: rman_reserve_resource() not to search for alternate regions.
Would the alignment stuff I added for cardbus help any?
I think, my patch basically uses now the same alignment options from
the resource manager like cardbus does now.
I have cleaned up the code a little bit: Now the code uses the
rman_get_XXX() macros and also checks if the region returned is below the
end mark.
Daniel
Index: sys/isa/isa_common.c
===
RCS file: /data/cvs/src/sys/isa/isa_common.c,v
retrieving revision 1.18
diff -u -r1.18 isa_common.c
--- sys/isa/isa_common.c2000/07/12 00:42:08 1.18
+++ sys/isa/isa_common.c2000/11/14 21:27:34
@@ -133,31 +133,30 @@
result-ic_nmem = config-ic_nmem;
for (i = 0; i config-ic_nmem; i++) {
u_int32_t start, end, size, align;
- for (start = config-ic_mem[i].ir_start,
-end = config-ic_mem[i].ir_end,
-size = config-ic_mem[i].ir_size,
-align = config-ic_mem[i].ir_align;
-start + size - 1 = end;
-start += align) {
- bus_set_resource(child, SYS_RES_MEMORY, i,
-start, size);
- res[i] = bus_alloc_resource(child,
- SYS_RES_MEMORY, i,
- 0, ~0, 1, 0 /* !RF_ACTIVE */);
- if (res[i]) {
- result-ic_mem[i].ir_start = start;
- result-ic_mem[i].ir_end = start + size - 1;
- result-ic_mem[i].ir_size = size;
- result-ic_mem[i].ir_align = align;
+
+ start = config-ic_mem[i].ir_start;
+ end = config-ic_mem[i].ir_end;
+ size = config-ic_mem[i].ir_size;
+ align = config-ic_mem[i].ir_align;
+ if(!align)
+ align = 1;
+ bus_set_resource(child, SYS_RES_MEMORY, i,
+start, size);
+ res[i] = bus_alloc_resource(child,
+ SYS_RES_MEMORY, i,
+ 0, ~0, 1,
+ rman_make_alignment_flags(align));
+ if (res[i]) {
+ if(rman_get_start(res[i]) end) {
+ success = 0;
break;
}
+ result-ic_mem[i].ir_start = rman_get_start(res[i]);
+ result-ic_mem[i].ir_end = rman_get_end(res[i]);
+ result-ic_mem[i].ir_size = rman_get_size(res[i]);
+ result-ic_mem[i].ir_align = align;
}
-
- /*
-* If we didn't find a place for memory range i, then
-* give up now.
-*/
- if (!res[i]) {
+ else {
success = 0;
break;
}
@@ -197,31 +196,31 @@
result-ic_nport = config-ic_nport;
for (i = 0; i config-ic_nport; i++) {
u_int32_t start, end, size, align;
- for (start = config-ic_port[i].ir_start,
-end = config-ic_port[i].ir_end,
-size = config-ic_port[i].ir_size,
-align = config-ic_port[i].ir_align;
-start + size - 1 = end;
-start += align) {
- bus_set_resource(child, SYS_RES_IOPORT, i,
-start, size);
- res[i] = bus_alloc_resource(child,
- SYS_RES_IOPORT, i,
- 0, ~0, 1, 0 /* !RF_ACTIVE */);
- if (res[i]) {
- result-ic_port[i].ir_start = start;
- result-ic_port[i].ir_end = start + size - 1;
- result-ic_port[i].ir_size = size;
- result-ic_port[i].ir_align = align;
+
+ start = config-ic_port[i].ir_start;
+ end = config-ic_port[i].ir_end;
+ size = config-ic_port[i].ir_size;
+ align = config-ic_port[i].ir_align;
+ if(!align)
+ align = 1;
+
+ bus_set_resource(child, SYS_RES_IOPORT, i,
+start, size
Re: ISA PnP resource allocation
Mike Smith schrieb:
Now that someone has implementented resource alignment in the resource
allocator, someone could review and integrate the attached patch.
This looks fine to me. I assume you'd want the same changes applied to
aligning memory regions?
I didn't run in this problem, but maybe some other person will, so: yes!
I don't know the code in /sys/kern/subr_rman.c well. Does it only find
nearby regions or also other as well. If it does find any region with the
alignment constraints, the for(...) loop in /sys/isa/isa_common.c is
completely meaningless and should be eliminated. The code then should look
like this below (works at least for me).
Daniel
Index: isa/isa_common.c
===
RCS file: /data/cvs/src/sys/isa/isa_common.c,v
retrieving revision 1.18
diff -u -r1.18 isa_common.c
--- isa/isa_common.c2000/07/12 00:42:08 1.18
+++ isa/isa_common.c2000/11/10 18:05:42
@@ -133,31 +133,26 @@
result-ic_nmem = config-ic_nmem;
for (i = 0; i config-ic_nmem; i++) {
u_int32_t start, end, size, align;
- for (start = config-ic_mem[i].ir_start,
-end = config-ic_mem[i].ir_end,
-size = config-ic_mem[i].ir_size,
-align = config-ic_mem[i].ir_align;
-start + size - 1 = end;
-start += align) {
- bus_set_resource(child, SYS_RES_MEMORY, i,
-start, size);
- res[i] = bus_alloc_resource(child,
- SYS_RES_MEMORY, i,
- 0, ~0, 1, 0 /* !RF_ACTIVE */);
- if (res[i]) {
- result-ic_mem[i].ir_start = start;
- result-ic_mem[i].ir_end = start + size - 1;
- result-ic_mem[i].ir_size = size;
- result-ic_mem[i].ir_align = align;
- break;
- }
- }
- /*
-* If we didn't find a place for memory range i, then
-* give up now.
-*/
- if (!res[i]) {
+ start = config-ic_mem[i].ir_start;
+ end = config-ic_mem[i].ir_end;
+ size = config-ic_mem[i].ir_size;
+ align = config-ic_mem[i].ir_align;
+ if(!align)
+ align = 1;
+ bus_set_resource(child, SYS_RES_MEMORY, i,
+start, size);
+ res[i] = bus_alloc_resource(child,
+ SYS_RES_MEMORY, i,
+ 0, ~0, 1,
+ rman_make_alignment_flags(align));
+ if (res[i]) {
+ result-ic_mem[i].ir_start = res[i]-r_start;
+ result-ic_mem[i].ir_end = res[i]-r_end;
+ result-ic_mem[i].ir_size = res[i]-r_end - res[i]-r_start +
+1;
+ result-ic_mem[i].ir_align = align;
+ }
+ else {
success = 0;
break;
}
@@ -197,31 +192,27 @@
result-ic_nport = config-ic_nport;
for (i = 0; i config-ic_nport; i++) {
u_int32_t start, end, size, align;
- for (start = config-ic_port[i].ir_start,
-end = config-ic_port[i].ir_end,
-size = config-ic_port[i].ir_size,
-align = config-ic_port[i].ir_align;
-start + size - 1 = end;
-start += align) {
- bus_set_resource(child, SYS_RES_IOPORT, i,
-start, size);
- res[i] = bus_alloc_resource(child,
- SYS_RES_IOPORT, i,
- 0, ~0, 1, 0 /* !RF_ACTIVE */);
- if (res[i]) {
- result-ic_port[i].ir_start = start;
- result-ic_port[i].ir_end = start + size - 1;
- result-ic_port[i].ir_size = size;
- result-ic_port[i].ir_align = align;
- break;
- }
- }
- /*
-* If we didn't find a place for port range i, then
-* give up now.
-*/
- if (!res[i]) {
+ start = config-ic_port[i].ir_start;
+ end = config-ic_port[i].ir_end;
+ size = config-ic_port[i].ir_size;
+ align =
ISA PnP resource allocation
Now that someone has implementented resource alignment in the resource
allocator, someone could review and integrate the attached patch.
Background:
I do have an old system with several PnP devices. Two of the request the
following IO ports:
first device: port range 0x100-0x3ff size=1 align=1
second device: port range 0x100-0x3f0 size=8 align=8
The first device gets port 0x100-0x100 allocated. Then the code
in isa_common.c tries to allocate the ports for the second device.
0x100 is already used, so it gets the next free range: 0x101-0x108,
ignoring the alignment constraints.
The general problem in the code /sys/isa_common.c
isa_find_port(), isa_find_memory(), etc.
The loops in these routines try to honor the alignment constraints but
the real work is done in /sys/subr_rman.c. Regardless of resource usage
the for(...)-look in above functions is only run once.
I already filed a PR for this problem but my first solution was a real
hack (kern/21461).
[another solution would be to introduce another flag for
rman_reserve_resource() not to search for alternate regions.
Daniel
Index: isa/isa_common.c
===
RCS file: /data/cvs/src/sys/isa/isa_common.c,v
retrieving revision 1.18
diff -u -r1.18 isa_common.c
--- isa/isa_common.c2000/07/12 00:42:08 1.18
+++ isa/isa_common.c2000/11/09 20:11:31
@@ -207,10 +207,10 @@
start, size);
res[i] = bus_alloc_resource(child,
SYS_RES_IOPORT, i,
- 0, ~0, 1, 0 /* !RF_ACTIVE */);
+ 0, ~0, 1,
+rman_make_alignment_flags(align)/* !RF_ACTIVE */);
if (res[i]) {
- result-ic_port[i].ir_start = start;
- result-ic_port[i].ir_end = start + size - 1;
+ result-ic_port[i].ir_start = res[i]-r_start;
+ result-ic_port[i].ir_end = res[i]-r_start + size - 1;
result-ic_port[i].ir_size = size;
result-ic_port[i].ir_align = align;
break;
