Re: Preview: GEOMs statistics code.

[Brad Knowles]

At 8:26 AM +0100 2003/02/05, [EMAIL PROTECTED] wrote:


 Is a disk 100% busy if it has requests outstanding at all times,
 but could handle five times as many requests because they could be
 sorted into the current stream of requests free of cost ?  Or is
 it only 20% busy ?  How do you measure it ?


	My understanding was that a disk is 100% busy, if the heads are 
constantly moving to and fro, and there is no period of time when 
they aren't being yanked around.  In other words, it would be 100% if 
there is always at least one outstanding request.

	Now, these requests could be sorted into a more efficient order 
and you could continue to get better performance out of a disk even 
though it is technically 100% busy, but that should show up as the 
throughput and number of transactions per unit of measurement time 
continuing to climb, while the %busy remains pegged.

	In this scenario, of real concern would be the average service 
time, %wait, and wait service time statistics.  Once the %busy is 
pegged, %wait is climbing and wsvc_time also starts climbing, you've 
gotten to a point where there probably isn't anything more that you 
can squeeze out of that disk.  If this situation persists for a 
significant period of time, then you probably want to get more 
spindles going for you so that you can eliminate this bottleneck.


	What is your time resolution on this sort of thing?  Iostat can 
only report in periods as small as one update per second, so I would 
hope that you could measure these quantities on a much more frequent 
basis, thus being able to make a useful calculation of average values 
over that period of time.

 Responsetime on the other hand is a very reliable estimator of how
 long time you next request is going to take to handle.


	Right.  That should be relatively low, so long as the disk is 
less than 100% busy.  You still want to pay attention to it, but it 
shouldn't be much to worry about.

 The correct average queue length is close to a thousand, but the
 sampled number will be just one.  It's random sampling.  Without
 some comparatively expensive math in the kernel I don't think I can
 see a way to return the correct number.


	Give us the best you can, and let us know about the resolution 
issues.  So long as we know, we should be okay.

 For truly trying to understand our disk-I/O load, tracelogs will
 be needed (And I fear they will show a lot of interesting phenomena).


	Hmm.  I'd like to learn more about this tracelog concept.  Can 
you provide any pointers?

--
Brad Knowles, [EMAIL PROTECTED]

They that can give up essential liberty to obtain a little temporary
safety deserve neither liberty nor safety.
-Benjamin Franklin, Historical Review of Pennsylvania.

GCS/IT d+(-) s:+(++): a C++(+++)$ UMBSHI$ P+++ L+ !E-(---) W+++(--) N+
!w--- O- M++ V PS++(+++) PE- Y+(++) PGP+++ t+(+++) 5++(+++) X++(+++) R+(+++)
tv+(+++) b+() DI+() D+(++) G+() e++ h--- r---(+++)* z(+++)

To Unsubscribe: send mail to [EMAIL PROTECTED]
with unsubscribe freebsd-current in the body of the message

Re: Preview: GEOMs statistics code.

[phk]

In message a05200f02ba66778c5b08@[10.0.1.2], Brad Knowles writes:
At 8:26 AM +0100 2003/02/05, [EMAIL PROTECTED] wrote:

   My understanding was that a disk is 100% busy, if the heads are 
constantly moving to and fro, and there is no period of time when 
they aren't being yanked around.  In other words, it would be 100% if 
there is always at least one outstanding request.

Works for me, I'll try if I can instrument that cheaply.

   What is your time resolution on this sort of thing?  Iostat can 
only report in periods as small as one update per second, so I would 
hope that you could measure these quantities on a much more frequent 
basis, thus being able to make a useful calculation of average values 
over that period of time.

I currently use binuptime() which means that the resolution is whatever
the system provides, which means better than 1 microsecond on all current
platforms.

The counters are updated in real time, so it's up to you how often you
read them.

  For truly trying to understand our disk-I/O load, tracelogs will
  be needed (And I fear they will show a lot of interesting phenomena).

   Hmm.  I'd like to learn more about this tracelog concept.  Can 
you provide any pointers?

Well, tracelog is simply my word for the concept of recording
each and every transaction and run it through some kind of analysis
afterwards.

-- 
Poul-Henning Kamp   | UNIX since Zilog Zeus 3.20
[EMAIL PROTECTED] | TCP/IP since RFC 956
FreeBSD committer   | BSD since 4.3-tahoe
Never attribute to malice what can adequately be explained by incompetence.

To Unsubscribe: send mail to [EMAIL PROTECTED]
with unsubscribe freebsd-current in the body of the message

5.0 cron problem

[CHOI Junho]

Hi,

I updated 4.7-RELEASE-p2 to 5.0-RELEASE using source
upgrade. Everything is fine until now.

One problem is cron. I have the following crontab of root user:

--
CVSUP=/usr/local/bin/cvsup -g -L2 -h localhost
CVSUPDIR=/b/FreeBSD/cvsup

# source sync
0   */1 *   *   *   $CVSUP $CVSUPDIR/4_7-supfile  /dev/null
20  */1 *   *   *   $CVSUP $CVSUPDIR/5_0-supfile  /dev/null
40  */1 *   *   *   $CVSUP $CVSUPDIR/current-supfile  /dev/null
--

When I install this crontab:

 # crontab my-crontab
 my-crontab:0: bad minute
 crontab: errors in crontab file, can't install

0 means line number. It means variable setting doesn't work...

I used this crontab over years on 4.[4567]-RELEASE happily. What
happen to cron? I suspected updating procedure(/usr/src/UPDATING)
because my -current desktop(starting from -current snapshot a year
ago) doesn't have such problem.

--
CHOI Junho http://www.kr.FreeBSD.org/~cjh KFUG cjh at kr.FreeBSD.org
FreeBSD Project cjh at FreeBSD.orgWeb Data Bank cjh at wdb.co.kr
Key fingerprint = 1369 7374 A45F F41A F3C0  07E3 4A01 C020 E602 60F5

To Unsubscribe: send mail to [EMAIL PROTECTED]
with unsubscribe freebsd-current in the body of the message

Re: Preview: GEOMs statistics code.

[Brad Knowles]

At 9:54 AM +0100 2003/02/05, [EMAIL PROTECTED] wrote:


	My understanding was that a disk is 100% busy, if the heads are
constantly moving to and fro, and there is no period of time when
they aren't being yanked around.  In other words, it would be 100% if
there is always at least one outstanding request.


 Works for me, I'll try if I can instrument that cheaply.


	I should be heading off to the office here shortly.  Let me see 
if I can quote the relevant sections of the iostat man page for 
Solaris, with the hope that they will be able to explain more 
accurately and clearly just exactly what it is that they measure and 
what it means.

 I currently use binuptime() which means that the resolution is whatever
 the system provides, which means better than 1 microsecond on all current
 platforms.

 The counters are updated in real time, so it's up to you how often you
 read them.


	So, we're talking about some fairly significant modifications to 
iostat to get it to poll these values and be able to create some 
averages that it can report.

 Well, tracelog is simply my word for the concept of recording
 each and every transaction and run it through some kind of analysis
 afterwards.


	Ahh, I see.


	Thanks again!

--
Brad Knowles, [EMAIL PROTECTED]

They that can give up essential liberty to obtain a little temporary
safety deserve neither liberty nor safety.
-Benjamin Franklin, Historical Review of Pennsylvania.

GCS/IT d+(-) s:+(++): a C++(+++)$ UMBSHI$ P+++ L+ !E-(---) W+++(--) N+
!w--- O- M++ V PS++(+++) PE- Y+(++) PGP+++ t+(+++) 5++(+++) X++(+++) R+(+++)
tv+(+++) b+() DI+() D+(++) G+() e++ h--- r---(+++)* z(+++)

To Unsubscribe: send mail to [EMAIL PROTECTED]
with unsubscribe freebsd-current in the body of the message

Re: 5.0 cron problem

[Tim Robbins]

On Wed, Feb 05, 2003 at 05:57:30PM +0900, CHOI Junho wrote:
[...]
 --
 CVSUP=/usr/local/bin/cvsup -g -L2 -h localhost
 CVSUPDIR=/b/FreeBSD/cvsup
 
 # source sync
 0 */1 *   *   *   $CVSUP $CVSUPDIR/4_7-supfile  /dev/null
 20*/1 *   *   *   $CVSUP $CVSUPDIR/5_0-supfile  /dev/null
 40*/1 *   *   *   $CVSUP $CVSUPDIR/current-supfile  /dev/null
 --
 
 When I install this crontab:
 
  # crontab my-crontab
  my-crontab:0: bad minute
  crontab: errors in crontab file, can't install
 
 0 means line number. It means variable setting doesn't work...
 
 I used this crontab over years on 4.[4567]-RELEASE happily. What
 happen to cron? I suspected updating procedure(/usr/src/UPDATING)
 because my -current desktop(starting from -current snapshot a year
 ago) doesn't have such problem.

Since revision 1.11 of src/usr.sbin/cron/lib/env.c, you need to put the
value of the environment variable inside quotes if it contains any spaces.
I suspect that this change of behaviour was unintentional given that the
implementation differs from the manual page. I'll investigate and fix
it if it's a bug. In the mean time, use something like this instead:
CVSUP=/usr/local/bin/cvsup -g -L2 -h localhost


Tim

To Unsubscribe: send mail to [EMAIL PROTECTED]
with unsubscribe freebsd-current in the body of the message

tired of crashes

[Vallo Kallaste]

Hi

In the last ~three months now I've had 24 kernel crashes, all the
same, all happening in the same circumstances. Happens while cvsup
is running, everytime... except if I remove the checkouts file which
probably causes slowdown of cvsup operation. I have recreated the
filesystem on /dev/da2s1e several times anew, to exclude any
accumulated filesystem corruption. This is on UFS2 filesystem,
haven't tried UFS1 yet. World and kernel are from January 21, PIII
SMP system. I'll provide any info one needs to track the cause,
needless to say I'm _really_ tired of it.

---CRASH---
Script started on Wed Feb  5 11:23:14 2003
bash-2.05b# gdb -k /sys/i386/compile/Myhakas-5.0-SMP/kernel.debug /usr/crash/vmc ore.24
GNU gdb 5.2.1 (FreeBSD)
Copyright 2002 Free Software Foundation, Inc.
GDB is free software, covered by the GNU General Public License, and you are
welcome to change it and/or distribute copies of it under certain conditions.
Type show copying to see the conditions.
There is absolutely no warranty for GDB.  Type show warranty for details.
This GDB was configured as i386-undermydesk-freebsd...
panic: bwrite: buffer is not busy???
panic messages:
---
panic: ufs_dirbad: bad dir
cpuid = 1; lapic.id = 0100
boot() called on cpu#1

syncing disks, buffers remaining... panic: bwrite: buffer is not busy???
cpuid = 1; lapic.id = 0100
boot() called on cpu#1
Uptime: 1d23h6m39s
Dumping 511 MB
[CTRL-C to abort] [CTRL-C to abort]  16 32 48 64 80 96 112 128 144 160 176 192 208 224 
240 256 272 288 304 320 336 352 368 384 400 416 432 448 464 480 496
---
#0  doadump () at ../../../kern/kern_shutdown.c:232
232 dumping++;
(kgdb) where
#0  doadump () at ../../../kern/kern_shutdown.c:232
#1  0xc02405ba in boot (howto=260) at ../../../kern/kern_shutdown.c:364
#2  0xc0240887 in panic () at ../../../kern/kern_shutdown.c:531
#3  0xc0288142 in bwrite (bp=0xce5727f8) at ../../../kern/vfs_bio.c:798
#4  0xc02898e6 in vfs_bio_awrite (bp=0xce5727f8)
at ../../../kern/vfs_bio.c:1650
#5  0xc0204193 in spec_fsync (ap=0xe0e06804)
at ../../../fs/specfs/spec_vnops.c:459
#6  0xc02034d8 in spec_vnoperate (ap=0x0)
at ../../../fs/specfs/spec_vnops.c:123
#7  0xc0351e0b in ffs_sync (mp=0xc41aba00, waitfor=2, cred=0xc1514e80, 
td=0xc0443d80) at vnode_if.h:612
#8  0xc029df9b in sync (td=0xc0443d80, uap=0x0)
at ../../../kern/vfs_syscalls.c:138
#9  0xc024019b in boot (howto=256) at ../../../kern/kern_shutdown.c:273
#10 0xc0240887 in panic () at ../../../kern/kern_shutdown.c:531
#11 0xc0359dc2 in ufs_dirbad (ip=0x0, offset=0, how=0x0)
at ../../../ufs/ufs/ufs_lookup.c:631
#12 0xc03592e7 in ufs_lookup (ap=0xe0e06aa4)
at ../../../ufs/ufs/ufs_lookup.c:294
#13 0xc0360c28 in ufs_vnoperate (ap=0x0) at ../../../ufs/ufs/ufs_vnops.c:2787
#14 0xc028dbbc in vfs_cache_lookup (ap=0x0) at vnode_if.h:82
#15 0xc0360c28 in ufs_vnoperate (ap=0x0) at ../../../ufs/ufs/ufs_vnops.c:2787
#16 0xc02923d2 in lookup (ndp=0xe0e06c18) at vnode_if.h:52
#17 0xc0291ddb in namei (ndp=0xe0e06c18) at ../../../kern/vfs_lookup.c:181
#18 0xc02a0fe2 in lstat (td=0xc424d460, uap=0xe0e06d10)
at ../../../kern/vfs_syscalls.c:1697
#19 0xc03c3dbc in syscall (frame=
  {tf_fs = 136118319, tf_es = 134873135, tf_ds = 136118319, tf_edi = 136134304, 
tf_esi = 134876320, tf_ebp = 136133492, tf_isp = -522162828, tf_ebx = 136910744, 
tf_edx = 0, tf_ecx = 0, tf_eax = 190, tf_trapno = 22, tf_err = 2, tf_eip = 672676643, 
tf_cs = 31, tf_eflags = 582, tf_esp = 136133356, tf_ss = 47})
at ../../../i386/i386/trap.c:1033
#20 0xc03abb2d in Xint0x80_syscall () at {standard input}:141
---Can't read userspace from dump, or kernel process---

(kgdb) quit
bash-2.05b# exit
exit

Script done on Wed Feb  5 11:23:37 2003

---CONTROLLER AND DISKS---
ahc0: Adaptec aic7896/97 Ultra2 SCSI adapter port 0xe400-0xe4ff mem 
0xfebfe000-0xfebfefff irq 2 at device 11.0 on pci0
ahc0: PCI Device 0:11:0 failed memory mapped test.  Using PIO.
ahc1: Adaptec aic7896/97 Ultra2 SCSI adapter port 0xe800-0xe8ff mem 
0xfebff000-0xfebf irq 2 at device 11.1 on pci0
ahc1: PCI Device 0:11:1 failed memory mapped test.  Using PIO.
ahc0: PCI error Interrupt at seqaddr = 0x3
ahc0: Signaled a Target Abort
ahc1: PCI error Interrupt at seqaddr = 0x3
ahc1: Signaled a Target Abort

da1 at ahc0 bus 0 target 2 lun 0
da1: QUANTUM VIKING II 4.5WSE 5520 Fixed Direct Access SCSI-2 device 
da1: 40.000MB/s transfers (20.000MHz, offset 31, 16bit), Tagged Queueing Enabled
da1: 4350MB (8910423 512 byte sectors: 255H 63S/T 554C)
da2 at ahc1 bus 0 target 0 lun 0
da2: QUANTUM ATLAS10K2-TY367L DDD6 Fixed Direct Access SCSI-3 device 
da2: 80.000MB/s transfers (40.000MHz, offset 127, 16bit), Tagged Queueing Enabled
da2: 35020MB (71721820 512 byte sectors: 255H 63S/T 4464C)
da0 at ahc0 bus 0 target 1 lun 0
da0: IBM DNES-309170W SAH0 Fixed Direct Access SCSI-3 device 
da0: 40.000MB/s transfers (20.000MHz, offset 31, 16bit), Tagged Queueing Enabled
da0: 8748MB (17916240 512 byte sectors: 255H 63S/T 1115C)

---DUMPFS 

se7500+dual xeon?

[Victor Ponomarev]

Hi All.

It's seems that smp kernel configuration doesn't  work correctly on 
Intel SE7500WV2 motherboard
with 2 xeon processors in 5.0-RELEASE.

Copyright (c) 1992-2003 The FreeBSD Project.
Copyright (c) 1979, 1980, 1983, 1986, 1988, 1989, 1991, 1992, 1993, 1994
   The Regents of the University of California. All rights reserved.
FreeBSD 5.0-RELEASE #0: Thu Jan 16 22:16:53 GMT 2003
   [EMAIL PROTECTED]:/usr/obj/usr/src/sys/GENERIC
Preloaded elf kernel /boot/kernel/kernel at 0xc0673000.
Preloaded elf module /boot/kernel/acpi.ko at 0xc06730a8.
Timecounter i8254  frequency 1193182 Hz
Timecounter TSC  frequency 2592366912 Hz
CPU: Pentium 4 (2592.37-MHz 686-class CPU)
 Origin = GenuineIntel  Id = 0xf27  Stepping = 7
 
Features=0xbfebfbffFPU,VME,DE,PSE,TSC,MSR,PAE,MCE,CX8,APIC,SEP,MTRR,PGE,MCA,CMOV,PAT,PSE36,CLFLUSH,DTS,ACPI,MMX,FXSR,SSE,SSE2,SS,HTT,TM,b31
real memory  = 2147418112 (2047 MB)
avail memory = 2083561472 (1987 MB)
Initializing GEOMetry subsystem
Pentium Pro MTRR support enabled
   ACPI-0625: *** Warning: Type override - [DEB_] had invalid type 
(Integer) for Scope operator, changed to (Scope)
   ACPI-0625: *** Warning: Type override - [MLIB] had invalid type 
(Integer) for Scope operator, changed to (Scope)
   ACPI-0625: *** Warning: Type override - [DATA] had invalid type 
(String) for Scope operator, changed to (Scope)
   ACPI-0625: *** Warning: Type override - [SIO_] had invalid type 
(String) for Scope operator, changed to (Scope)
   ACPI-0625: *** Warning: Type override - [LEDP] had invalid type 
(String) for Scope operator, changed to (Scope)
   ACPI-0625: *** Warning: Type override - [GPEN] had invalid type 
(String) for Scope operator, changed to (Scope)
   ACPI-0625: *** Warning: Type override - [GPST] had invalid type 
(String) for Scope operator, changed to (Scope)
   ACPI-0625: *** Warning: Type override - [WUES] had invalid type 
(String) for Scope operator, changed to (Scope)
   ACPI-0625: *** Warning: Type override - [WUSE] had invalid type 
(String) for Scope operator, changed to (Scope)
   ACPI-0625: *** Warning: Type override - [SBID] had invalid type 
(String) for Scope operator, changed to (Scope)
   ACPI-0625: *** Warning: Type override - [SWCE] had invalid type 
(String) for Scope operator, changed to (Scope)
npx0: math processor on motherboard
npx0: INT 16 interface
acpi0: INTEL  SWV20on motherboard
   ACPI-1287: *** Error: Method execution failed, AE_NOT_EXIST
   ACPI-0625: *** Info: GPE Block0 defined as GPE0 to GPE15
   ACPI-0625: *** Info: GPE Block1 defined as GPE16 to GPE47
Using $PIR table, 19 entries at 0xc00f3070
acpi0: power button is handled as a fixed feature programming model.
Timecounter ACPI-fast  frequency 3579545 Hz
acpi_timer0: 24-bit timer at 3.579545MHz port 0x408-0x40b on acpi0
acpi_cpu0: CPU on acpi0
acpi_cpu1: CPU on acpi0
acpi_cpu2: CPU on acpi0
acpi_cpu3: CPU on acpi0
pcib0: ACPI Host-PCI bridge port 0xcf8-0xcff on acpi0
pci0: ACPI PCI bus on pcib0
pci0: unknown at device 0.1 (no driver attached)
pcib1: ACPI PCI-PCI bridge at device 3.0 on pci0
pcib1: could not get PCI interrupt routing table for \\_SB_.PCI0.P0P5 - 
AE_NOT_FOUND
pci2: ACPI PCI bus on pcib1
pci2: base peripheral, interrupt controller at device 28.0 (no driver 
attached)
pcib2: ACPI PCI-PCI bridge at device 29.0 on pci2
pci4: ACPI PCI bus on pcib2
pci2: base peripheral, interrupt controller at device 30.0 (no driver 
attached)
pcib3: ACPI PCI-PCI bridge at device 31.0 on pci2
pci3: ACPI PCI bus on pcib3
em0: Intel(R) PRO/1000 Network Connection, Version - 1.4.7 port 
0x2040-0x207f mem 0xfeac-0xfead irq 10 at device 7.0 on pci3
em0:  Speed:N/A  Duplex:N/A
em1: Intel(R) PRO/1000 Network Connection, Version - 1.4.7 port 
0x2000-0x203f mem 0xfeae-0xfeaf irq 10 at device 7.1 on pci3
em1:  Speed:N/A  Duplex:N/A
pci0: unknown at device 3.1 (no driver attached)
pcib4: ACPI PCI-PCI bridge at device 30.0 on pci0
pci1: ACPI PCI bus on pcib4
atapci0: Promise TX2 ATA133 controller port 
0x1420-0x142f,0x140c-0x140f,0x1410-0x1417,0x1408-0x140b,0x1400-0x1407 
mem 0xfe9e-0xfe9e3fff irq 9 at device 2.0 on pci1
ata2: at 0x1400 on atapci0
ata3: at 0x1410 on atapci0
pci1: display, VGA at device 12.0 (no driver attached)
isab0: PCI-ISA bridge at device 31.0 on pci0
isa0: ISA bus on isab0
atapci1: Intel ICH3 ATA100 controller port 
0x3a0-0x3af,0-0x3,0-0x7,0-0x3,0-0x7 at device 31.1 on pci0
ata0: at 0x1f0 irq 14 on atapci1
ata1: at 0x170 irq 15 on atapci1
pci0: serial bus, SMBus at device 31.3 (no driver attached)
atkbdc0: Keyboard controller (i8042) port 0x64,0x60 irq 1 on acpi0
atkbd0: AT Keyboard flags 0x1 irq 1 on atkbdc0
kbd0 at atkbd0
acpi_ec0: embedded controller port 0xca7,0xca6 on acpi0
fdc0: cmd 3 failed at out byte 1 of 3
sio0 port 0x3f8-0x3ff irq 4 on acpi0
sio0: type 16550A
sio1 port 0x2f8-0x2ff irq 3 on acpi0
sio1: type 16550A
fdc0: cmd 3 failed at out byte 1 of 3
orm0: Option ROMs at iomem 
0xd3000-0xd47ff,0xd1800-0xd2fff,0xc8000-0xd17ff,0xc-0xc7fff on isa0

Re: 5.0 cron problem

[CHOI Junho]

Ok, the problem solved. Thanks.

crontab(5) page of 4.7-RELEASE and 5.0-RELEASE cite the same thing
about variable assignment:

  The name string may also be placed in quote(single or double, but
  matching) to preserver leading, trailing or inner blanks.

I think the current implementation(r1.11 of env.c) is right according
to the manual. But 4-stable is still r1.7.2.1, so it'll be good to
wait until MFC...

From: Tim Robbins [EMAIL PROTECTED]
Subject: Re: 5.0 cron problem
Date: Wed, 5 Feb 2003 20:42:50 +1100

 On Wed, Feb 05, 2003 at 05:57:30PM +0900, CHOI Junho wrote:
 [...]
  --
  CVSUP=/usr/local/bin/cvsup -g -L2 -h localhost
  CVSUPDIR=/b/FreeBSD/cvsup
  
  # source sync
  0   */1 *   *   *   $CVSUP $CVSUPDIR/4_7-supfile  /dev/null
  20  */1 *   *   *   $CVSUP $CVSUPDIR/5_0-supfile  /dev/null
  40  */1 *   *   *   $CVSUP $CVSUPDIR/current-supfile  /dev/null
  --
  
  When I install this crontab:
  
   # crontab my-crontab
   my-crontab:0: bad minute
   crontab: errors in crontab file, can't install
  
  0 means line number. It means variable setting doesn't work...
  
  I used this crontab over years on 4.[4567]-RELEASE happily. What
  happen to cron? I suspected updating procedure(/usr/src/UPDATING)
  because my -current desktop(starting from -current snapshot a year
  ago) doesn't have such problem.
 
 Since revision 1.11 of src/usr.sbin/cron/lib/env.c, you need to put the
 value of the environment variable inside quotes if it contains any spaces.
 I suspect that this change of behaviour was unintentional given that the
 implementation differs from the manual page. I'll investigate and fix
 it if it's a bug. In the mean time, use something like this instead:
 CVSUP=/usr/local/bin/cvsup -g -L2 -h localhost
 
 
 Tim
 
 To Unsubscribe: send mail to [EMAIL PROTECTED]
 with unsubscribe freebsd-current in the body of the message

--
CHOI Junho http://www.kr.FreeBSD.org/~cjh KFUG cjh at kr.FreeBSD.org
FreeBSD Project cjh at FreeBSD.orgWeb Data Bank cjh at wdb.co.kr
Key fingerprint = 1369 7374 A45F F41A F3C0  07E3 4A01 C020 E602 60F5

To Unsubscribe: send mail to [EMAIL PROTECTED]
with unsubscribe freebsd-current in the body of the message

Re: -current, IBM A30p 2 external FW-disks

[Michael Reifenberger]

On Wed, 5 Feb 2003, Hidetoshi Shimokawa wrote:

 Date: Wed, 05 Feb 2003 12:07:05 +0900
 From: Hidetoshi Shimokawa [EMAIL PROTECTED]
 To: mike [EMAIL PROTECTED]
 Cc: Hidetoshi Shimokawa [EMAIL PROTECTED],
  FreeBSD-Current [EMAIL PROTECTED]
 Subject: Re: -current, IBM A30p  2 external FW-disks

 I have improved recovery code after timeout in -current.
 Could you try that?

Is scheduled for this evening.
Thanks so far!


 /\ Hidetoshi Shimokawa
 \/  [EMAIL PROTECTED]
 PGP public key: http://www.sat.t.u-tokyo.ac.jp/~simokawa/pgp.html

 At Sun, 2 Feb 2003 13:28:33 +0200,
 mike wrote:
 
  [1  text/plain; iso-8859-1 (7bit)]
  On Thu, 30 Jan 2003 14:41:59 +0900, Hidetoshi Shimokawa wrote
   Do you get timeout only for sbp0:0:0?
   Is the other drive still working?
  
   I have no problem with concurrent accesses with `iozone -s 102400m -r
   1024k`.
  ...
   try some of the following:
  
   - fwcontorl -g 20
   - sysctl hw.firewire.sbp.max_speed=0
   - change SBP_QUEUE_LEN in sbp.c to 1 and rebuld module.
   - sysctl machdep.cpu_idle_hlt=0
   - sysctl debug.sbp_debug=1 and send me a dmesg.
 
  with all of the above I get the attached dmesg soon after
  setting up two concurrent iozones (one per disk):
 ...


Bye!

Michael Reifenberger
^.*Plaut.*$, IT, R/3 Basis, GPS

To Unsubscribe: send mail to [EMAIL PROTECTED]
with unsubscribe freebsd-current in the body of the message

Re: tired of crashes

[Martin Blapp]

Hi,

Looks like bad hw. Have you run memtestx86 on this machine
about 2-3 hours ? I had the same effects on one machine ...

Martin

Martin Blapp, [EMAIL PROTECTED] [EMAIL PROTECTED]
--
ImproWare AG, UNIXSP  ISP, Zurlindenstrasse 29, 4133 Pratteln, CH
Phone: +41 61 826 93 00 Fax: +41 61 826 93 01
PGP: finger -l [EMAIL PROTECTED]
PGP Fingerprint: B434 53FC C87C FE7B 0A18 B84C 8686 EF22 D300 551E
--

To Unsubscribe: send mail to [EMAIL PROTECTED]
with unsubscribe freebsd-current in the body of the message

alpha tinderbox failure

[Dag-Erling Smorgrav]

--
 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/alpha/obj/h/des/src/alpha/usr/include
--
 stage 4: building libraries
--
 stage 4: make dependencies
--
 stage 4: building everything..
--
 Kernel build for GENERIC started on Wed Feb  5 03:07:44 PST 2003
--
 Kernel build for GENERIC completed on Wed Feb  5 03:39:12 PST 2003
--
 Kernel build for LINT started on Wed Feb  5 03:39:12 PST 2003
--
=== vinum
Makefile, line 4450: warning: duplicate script for target geom_bsd.o ignored
/h/des/src/sys/dev/lmc/if_lmc.c:32:2: warning: #warning The lmc driver is broken and 
is not compiled with LINT
/h/des/src/sys/dev/pdq/pdq.c: In function `pdq_initialize':
/h/des/src/sys/dev/pdq/pdq.c:1606: warning: cast discards qualifiers from pointer 
target type
/h/des/src/sys/pci/meteor.c:149:2: warning: #warning The meteor driver is broken and 
is not compiled with LINT
/h/des/src/sys/pci/simos.c:30:2: warning: #warning The simos driver is broken and is 
not compiled with LINT
/h/des/src/sys/dev/gfb/gfb_pci.c: In function `pcigfb_open':
/h/des/src/sys/dev/gfb/gfb_pci.c:268: `gfb_devclass' undeclared (first use in this 
function)
/h/des/src/sys/dev/gfb/gfb_pci.c:268: (Each undeclared identifier is reported only once
/h/des/src/sys/dev/gfb/gfb_pci.c:268: for each function it appears in.)
cc1: warnings being treated as errors
/h/des/src/sys/dev/gfb/gfb_pci.c:275: warning: passing arg 1 of `genfbopen' from 
incompatible pointer type
/h/des/src/sys/dev/gfb/gfb_pci.c: In function `pcigfb_close':
/h/des/src/sys/dev/gfb/gfb_pci.c:284: `gfb_devclass' undeclared (first use in this 
function)
/h/des/src/sys/dev/gfb/gfb_pci.c:285: warning: passing arg 1 of `genfbclose' from 
incompatible pointer type
/h/des/src/sys/dev/gfb/gfb_pci.c: In function `pcigfb_read':
/h/des/src/sys/dev/gfb/gfb_pci.c:293: `gfb_devclass' undeclared (first use in this 
function)
/h/des/src/sys/dev/gfb/gfb_pci.c:294: warning: passing arg 1 of `genfbread' from 
incompatible pointer type
/h/des/src/sys/dev/gfb/gfb_pci.c: In function `pcigfb_write':
/h/des/src/sys/dev/gfb/gfb_pci.c:302: `gfb_devclass' undeclared (first use in this 
function)
/h/des/src/sys/dev/gfb/gfb_pci.c:303: warning: passing arg 1 of `genfbwrite' from 
incompatible pointer type
/h/des/src/sys/dev/gfb/gfb_pci.c: In function `pcigfb_ioctl':
/h/des/src/sys/dev/gfb/gfb_pci.c:311: `gfb_devclass' undeclared (first use in this 
function)
/h/des/src/sys/dev/gfb/gfb_pci.c:312: warning: passing arg 1 of `genfbioctl' from 
incompatible pointer type
/h/des/src/sys/dev/gfb/gfb_pci.c: In function `pcigfb_mmap':
/h/des/src/sys/dev/gfb/gfb_pci.c:320: `gfb_devclass' undeclared (first use in this 
function)
/h/des/src/sys/dev/gfb/gfb_pci.c:321: warning: passing arg 1 of `genfbmmap' from 
incompatible pointer type
*** Error code 1

Stop in /h/des/obj/h/des/src/sys/LINT.
*** Error code 1

Stop in /h/des/src.
*** Error code 1

Stop in /h/des/src.

To Unsubscribe: send mail to [EMAIL PROTECTED]
with unsubscribe freebsd-current in the body of the message

RE: Server locking hard -- A LOT!!!

[Robert Covell]

 -Original Message-
 From: [EMAIL PROTECTED]
 [mailto:[EMAIL PROTECTED]]On Behalf Of Muhannad Asfour
 Sent: Tuesday, February 04, 2003 9:25 PM
 To: [EMAIL PROTECTED]
 Cc: [EMAIL PROTECTED]
 Subject: Server locking hard -- A LOT!!!


 Hello.  I've recently faced a rather odd issue that I've never seen
 before.  I bought a new server (specs below), and I loaded it up with
 FreeBSD 5.0-RELEASE (I know, I know, not for a production environment,
 but this is a personal server).  Now, whenever I get about 30
 simultaneous connections, the box just locks hard.  I tested all the
 hardware components (CPU, Memory, HD, NIC, etc.) and even bought new
 ones just to make sure and all end up with the same result.  I can never
 keep a decent uptime (never went past 2 days so far).  As soon as I get
 a mediocre http load (30 simul. connections), the box just locks hard.
 I built a debug kernel, I tried everything imaginable, and I have not
 found a solution whatsoever.  Everyone seems to be stumped by this.  I
 tried FreeBSD 4.7-RELEASE, 4.7-STABLE, 5.0-RELEASE and 5.0-CURRENT on
 this box.  All give me the same result.  I checked everywhere for
 relevant logs to explain what is occuring, but had no such luck.  This
 is truly the million dollar question for me right now, because I have no
 idea why it would lock under such a petty load.  I'm not sure what to do
 to fix this issue, I've tried many different areas for support and
 haven't come up with anything as I stated earlier.  I'm not overclocking
 or anything if that's what you're wondering.  If anyone could assist me
 in any way shape or form to get this working, I would appreciate it very
 very much.  Also, if you e-mail back, I'm not subscribed to the lists,
 so could you please CC it to me.  In the past 4 hours, it has locked
 hard about 3 times because of a 28-34 connection load.

 Machine Specs:
 Single Pentium IV 2.4 GHz processor
 ASUS P4S533 motherboard
 512MB DDR333 RAM (will be 1GB next week)
 120GB Maxtor 7200rpm (ATA133) HDD
 40GB Maxtor 7200 rpm (ATA66) HDD
 Floppy Disk Drive
 ATI Rage 128 (32 meg) AGP 4x graphics adapter
 52x LG CD-ROM drive
 3Com 3C905C-TX NIC
 Currently running FreeBSD 5.0-CURRENT as of Sunday Feb. 2, 13:02:05 EST
 2003.

 Thank you very much



 To Unsubscribe: send mail to [EMAIL PROTECTED]
 with unsubscribe freebsd-questions in the body of the message

I have seen things like this that are not software related at all but due to
a faulty power supply.  Did you replace that when you went out and bought
new hardware?  You might want to try and take off your CD-ROM and or the
secondary HD.  This will cut back on your power usage and might be a good
test.  If it still does it, get a new power supply that has enough juice.

Sincerely,

Robert T. Covell
President / Owner
Rolet Internet Services, LLC
Web: www.rolet.com
Email: [EMAIL PROTECTED]
Phone: 816.471.1095
Fax: 816.471.3447
24x7: 816.210.7145



To Unsubscribe: send mail to [EMAIL PROTECTED]
with unsubscribe freebsd-current in the body of the message

RE: Server locking hard -- A LOT!!!

[Forrest W. Christian]

On Wed, 5 Feb 2003, Robert Covell wrote:

  haven't come up with anything as I stated earlier.  I'm not overclocking
  or anything if that's what you're wondering.  If anyone could assist me
  in any way shape or form to get this working, I would appreciate it very
  very much.  Also, if you e-mail back, I'm not subscribed to the lists,
  so could you please CC it to me.  In the past 4 hours, it has locked
  hard about 3 times because of a 28-34 connection load.

Cooling problems also match this symptom set.  (CPU sleeps less when
loaded)  Do you have adequate cooling in this box?

- Forrest W. Christian ([EMAIL PROTECTED]) AC7DE
--
The Innovation Machine Ltd.  P.O. Box 5749
http://www.imach.com/Helena, MT  59604
Home of PacketFlux Technologies and BackupDNS.com   (406)-442-6648
--
  Protect your personal freedoms - visit http://www.lp.org/


To Unsubscribe: send mail to [EMAIL PROTECTED]
with unsubscribe freebsd-current in the body of the message

Unable to boot 5.0-R CD error

[Stephen Cravey]

I'm getting an error when trying to boot any of the 5.0-RELEASE cd's
something like:

CD Loader 1.01
Building txxx boot loader arguments
Could not find primary volume descriptor


and then it dies there. txxx is illegible in my notes, but somehow I don't
think that is significant. When booting from floppy, I have to install
additional drivers from the driver floppy to be able to install from CD.

The device line from dmesg after installation is:

acd0: CDROM GCD-R580B at ata1-master PIO3

I have a vague recollection of a problem similar to this sometime in the
4.x tree, but specifics totally escape me.



-Stephen

To Unsubscribe: send mail to [EMAIL PROTECTED]
with unsubscribe freebsd-current in the body of the message

subscribe

[Anders Søndergaard Jensen]

To Unsubscribe: send mail to [EMAIL PROTECTED]
with unsubscribe freebsd-current in the body of the message

/bin/ps buggette

[Peter Edwards]

The keyword mtxname was changed to logname in the list of keywords
in bin/ps/keyword.c

Unfortunately, this table needs to be sorted, and the change broke the 
sort-order.

The incredibly complex patch is included below, if someone wants to
commit it. :-)

Index: keyword.c
===
RCS file: /pub/FreeBSD/development/FreeBSD-CVS/src/bin/ps/keyword.c,v
retrieving revision 1.60
diff -u -r1.60 keyword.c
--- keyword.c   19 Jan 2003 00:31:15 -  1.60
+++ keyword.c   5 Feb 2003 14:56:16 -
@@ -98,6 +98,8 @@
{label, LABEL, NULL, LJUST|DSIZ, label, s_label, SHRT_MAX, 0, CHAR,
NULL, 0},
{lim, LIM, NULL, 0, maxrss, NULL, 5, 0, CHAR, NULL, 0},
+   {lockname, LOCK, NULL, LJUST, lockname, NULL, 6, 0, CHAR, NULL,
+   0},
{login, LOGIN, NULL, LJUST, logname, NULL, MAXLOGNAME-1, 0, CHAR,
NULL, 0},
{logname, , login, 0, NULL, NULL, 0, 0, CHAR, NULL, 0},
@@ -111,8 +113,6 @@
LONG, ld, 0},
{msgsnd, MSGSND, NULL, USER, rvar, NULL, 4, ROFF(ru_msgsnd),
LONG, ld, 0},
-   {lockname, LOCK, NULL, LJUST, lockname, NULL, 6, 0, CHAR, NULL,
-   0},
{mwchan, MWCHAN, NULL, LJUST, mwchan, NULL, 6, 0, CHAR, NULL, 0},
{ni, , nice, 0, NULL, NULL, 0, 0, CHAR, NULL, 0},
{nice, NI, NULL, 0, kvar, NULL, 2, KOFF(ki_nice), CHAR, d,



-- 
Peter Edwards.


To Unsubscribe: send mail to [EMAIL PROTECTED]
with unsubscribe freebsd-current in the body of the message

Re: se7500+dual xeon?

[Scott Long]

What exactly are you pointing out that doesn't work?  It looks like 
you're using the default GENERIC uni-processor kernel from the 5.0 
release.  You'll need to recompile your kernel for SMP.

Scott

Victor Ponomarev wrote:

Hi All.

It's seems that smp kernel configuration doesn't  work correctly on
Intel SE7500WV2 motherboard
with 2 xeon processors in 5.0-RELEASE.

Copyright (c) 1992-2003 The FreeBSD Project.
Copyright (c) 1979, 1980, 1983, 1986, 1988, 1989, 1991, 1992, 1993, 1994
   The Regents of the University of California. All rights reserved.
FreeBSD 5.0-RELEASE #0: Thu Jan 16 22:16:53 GMT 2003
   [EMAIL PROTECTED]:/usr/obj/usr/src/sys/GENERIC
Preloaded elf kernel /boot/kernel/kernel at 0xc0673000.
Preloaded elf module /boot/kernel/acpi.ko at 0xc06730a8.
Timecounter i8254  frequency 1193182 Hz
Timecounter TSC  frequency 2592366912 Hz
CPU: Pentium 4 (2592.37-MHz 686-class CPU)
 Origin = GenuineIntel  Id = 0xf27  Stepping = 7

Features=0xbfebfbff

real memory  = 2147418112 (2047 MB)
avail memory = 2083561472 (1987 MB)
Initializing GEOMetry subsystem
Pentium Pro MTRR support enabled
   ACPI-0625: *** Warning: Type override - [DEB_] had invalid type
(Integer) for Scope operator, changed to (Scope)
   ACPI-0625: *** Warning: Type override - [MLIB] had invalid type
(Integer) for Scope operator, changed to (Scope)
   ACPI-0625: *** Warning: Type override - [DATA] had invalid type
(String) for Scope operator, changed to (Scope)
   ACPI-0625: *** Warning: Type override - [SIO_] had invalid type
(String) for Scope operator, changed to (Scope)
   ACPI-0625: *** Warning: Type override - [LEDP] had invalid type
(String) for Scope operator, changed to (Scope)
   ACPI-0625: *** Warning: Type override - [GPEN] had invalid type
(String) for Scope operator, changed to (Scope)
   ACPI-0625: *** Warning: Type override - [GPST] had invalid type
(String) for Scope operator, changed to (Scope)
   ACPI-0625: *** Warning: Type override - [WUES] had invalid type
(String) for Scope operator, changed to (Scope)
   ACPI-0625: *** Warning: Type override - [WUSE] had invalid type
(String) for Scope operator, changed to (Scope)
   ACPI-0625: *** Warning: Type override - [SBID] had invalid type
(String) for Scope operator, changed to (Scope)
   ACPI-0625: *** Warning: Type override - [SWCE] had invalid type
(String) for Scope operator, changed to (Scope)
npx0:  on motherboard
npx0: INT 16 interface
acpi0:  on motherboard
   ACPI-1287: *** Error: Method execution failed, AE_NOT_EXIST
   ACPI-0625: *** Info: GPE Block0 defined as GPE0 to GPE15
   ACPI-0625: *** Info: GPE Block1 defined as GPE16 to GPE47
Using $PIR table, 19 entries at 0xc00f3070
acpi0: power button is handled as a fixed feature programming model.
Timecounter ACPI-fast  frequency 3579545 Hz
acpi_timer0: 24-bit timer at 3.579545MHz port 0x408-0x40b on acpi0
acpi_cpu0:  on acpi0
acpi_cpu1:  on acpi0
acpi_cpu2:  on acpi0
acpi_cpu3:  on acpi0
pcib0:  port 0xcf8-0xcff on acpi0
pci0:  on pcib0
pci0:  at device 0.1 (no driver attached)
pcib1:  at device 3.0 on pci0
pcib1: could not get PCI interrupt routing table for \\_SB_.PCI0.P0P5 -
AE_NOT_FOUND
pci2:  on pcib1
pci2:  at device 28.0 (no driver
attached)
pcib2:  at device 29.0 on pci2
pci4:  on pcib2
pci2:  at device 30.0 (no driver
attached)
pcib3:  at device 31.0 on pci2
pci3:  on pcib3
em0:  port
0x2040-0x207f mem 0xfeac-0xfead irq 10 at device 7.0 on pci3
em0:  Speed:N/A  Duplex:N/A
em1:  port
0x2000-0x203f mem 0xfeae-0xfeaf irq 10 at device 7.1 on pci3
em1:  Speed:N/A  Duplex:N/A
pci0:  at device 3.1 (no driver attached)
pcib4:  at device 30.0 on pci0
pci1:  on pcib4
atapci0:  port
0x1420-0x142f,0x140c-0x140f,0x1410-0x1417,0x1408-0x140b,0x1400-0x1407
mem 0xfe9e-0xfe9e3fff irq 9 at device 2.0 on pci1
ata2: at 0x1400 on atapci0
ata3: at 0x1410 on atapci0
pci1:  at device 12.0 (no driver attached)
isab0:  at device 31.0 on pci0
isa0:  on isab0
atapci1:  port
0x3a0-0x3af,0-0x3,0-0x7,0-0x3,0-0x7 at device 31.1 on pci0
ata0: at 0x1f0 irq 14 on atapci1
ata1: at 0x170 irq 15 on atapci1
pci0:  at device 31.3 (no driver attached)
atkbdc0:  port 0x64,0x60 irq 1 on acpi0
atkbd0:  flags 0x1 irq 1 on atkbdc0
kbd0 at atkbd0
acpi_ec0:  port 0xca7,0xca6 on acpi0
fdc0: cmd 3 failed at out byte 1 of 3
sio0 port 0x3f8-0x3ff irq 4 on acpi0
sio0: type 16550A
sio1 port 0x2f8-0x2ff irq 3 on acpi0
sio1: type 16550A
fdc0: cmd 3 failed at out byte 1 of 3
orm0:  at iomem
0xd3000-0xd47ff,0xd1800-0xd2fff,0xc8000-0xd17ff,0xc-0xc7fff on isa0
pmtimer0 on isa0
fdc0:  at port
0x3f7,0x3f0-0x3f5 irq 6 drq 2 on isa0
fdc0: FIFO enabled, 8 bytes threshold
fd0: 1440-KB 3.5 drive on fdc0 drive 0
ppc0: parallel port not found.
sc0:  at flags 0x100 on isa0
sc0: VGA 16 virtual consoles, flags=0x300
vga0:  at port 0x3c0-0x3df iomem 0xa-0xb on isa0
Timecounters tick every 10.000 msec
acd0: CDROM  at ata1-master PIO4
ar0: 76319MB  [9729/255/63] status: READY subdisks:
0 READY ad4: 76319MB  [155061/16/63] at ata2-master 

Panic: vm_page_wakeup(NULL)

[Thomas Quinot]

Looks like the stack got horribly corrupted... Bonus points for double
panic while dumping.

This is 5.0-RELEASE running on a Dell Inspiron 8200 laptop with ACPI
disabled (it crashes once or twice per day when ACPI is enabled).

Fatal trap 12: page fault while in kernel mode
fault virtual address   = 0x36
fault code  = supervisor read, page not present
instruction pointer = 0x8:0xc030649c
stack pointer   = 0x10:0xe5d8b658
frame pointer   = 0x10:0xe5d8b658
code segment= base 0x0, limit 0xf, type 0x1b
= DPL 0, pres 1, def32 1, gran 1
processor eflags= interrupt enabled, resume, IOPL = 0
current process = 29732 (flipscreen3d)
trap number = 12
panic: page fault

syncing disks, buffers remaining... panic: bdwrite: buffer is not busy
Uptime: 4d10h35m9s
Dumping 511 MB
ata0: resetting devices ..
done
 16 32 48 64 80 96 112 128 144 160 176 192 208 224 240 256 272 288 304 320 336 352 368 
384 400 416 432 448 464 480 496
---
#0  doadump () at /usr/src/sys/kern/kern_shutdown.c:232
232 dumping++;
(kgdb) bt
#0  doadump () at /usr/src/sys/kern/kern_shutdown.c:232
#1  0xc01f7f06 in boot (howto=260) at /usr/src/sys/kern/kern_shutdown.c:364
#2  0xc01f8153 in panic () at /usr/src/sys/kern/kern_shutdown.c:517
#3  0xc0236cbd in bdwrite (bp=0xce69e7f8) at /usr/src/sys/kern/vfs_bio.c:950
#4  0xc02d5b4b in ffs_update (vp=0xc41a87c4, waitfor=0)
at /usr/src/sys/ufs/ffs/ffs_inode.c:125
#5  0xc02e9d0f in ffs_fsync (ap=0xe5d8b48c)
at /usr/src/sys/ufs/ffs/ffs_vnops.c:315
#6  0xc02e8e1e in ffs_sync (mp=0xc415f600, waitfor=2, cred=0xc1509f00, 
td=0xc039faa0) at vnode_if.h:612
#7  0xc024993b in sync (td=0xc039faa0, uap=0x0)
at /usr/src/sys/kern/vfs_syscalls.c:138
#8  0xc01f7b7c in boot (howto=256) at /usr/src/sys/kern/kern_shutdown.c:273
#9  0xc01f8153 in panic () at /usr/src/sys/kern/kern_shutdown.c:517
#10 0xc033ec42 in trap_fatal (frame=0xe5d8b618, eva=0)
at /usr/src/sys/i386/i386/trap.c:844
#11 0xc033e922 in trap_pfault (frame=0xe5d8b618, usermode=0, eva=54)
at /usr/src/sys/i386/i386/trap.c:758
#12 0xc033e4bd in trap (frame=
  {tf_fs = 24, tf_es = 16, tf_ds = -438829040, tf_edi = -978624408, tf_esi = -1, 
tf_ebp = -438782376, tf_isp = -438782396, tf_ebx = 0, tf_edx = -2, tf_ecx = 0, tf_eax 
= 0, tf_trapno = 12, tf_err = 0, tf_eip = -1070570340, tf_cs = 8, tf_eflags = 66182, 
tf_esp = -438782356, tf_ss = -1070570196})
at /usr/src/sys/i386/i386/trap.c:445
#13 0xc032f438 in calltrap () at {standard input}:98
#14 0xc030652c in vm_page_wakeup (m=0x0) at /usr/src/sys/vm/vm_page.c:324
#15 0xc058142f in ?? ()
#16 0xc05815b5 in ?? ()
#17 0xc04b6bff in ?? ()
#18 0xc04ac34c in ?? ()
#19 0xc04ac144 in ?? ()
#20 0xc04b937b in ?? ()
#21 0xc04b8e2b in ?? ()
#22 0xc0580bbf in ?? ()
#23 0xc057f1f7 in ?? ()
#24 0xc01c3cec in spec_ioctl (ap=0x)
at /usr/src/sys/fs/specfs/spec_vnops.c:352
#25 0xc01c35c8 in spec_vnoperate (ap=0x0)
at /usr/src/sys/fs/specfs/spec_vnops.c:126
#26 0xc0251b51 in vn_ioctl (fp=0xc48ccb7c, com=3223864871, data=0xe5d8bc54, 
active_cred=0xc45dd680, td=0xc44e3e00) at vnode_if.h:488
#27 0xc0218e79 in ioctl (td=0xc44e3e00, uap=0xe5d8bd10) at file.h:227
#28 0xc033ef0e in syscall (frame=
  {tf_fs = 47, tf_es = 47, tf_ds = 47, tf_edi = 11, tf_esi = 0, tf_ebp = 
-1077939992, tf_isp = -438780556, tf_ebx = 672484484, tf_edx = 11, tf_ecx = 22372351, 
tf_eax = 54, tf_trapno = 12, tf_err = 2, tf_eip = 674342131, tf_cs = 31, tf_e---Type 
return to continue, or q return to quit---
flags = 534, tf_esp = -1077940036, tf_ss = 47})
at /usr/src/sys/i386/i386/trap.c:1033
#29 0xc032f48d in Xint0x80_syscall () at {standard input}:140
---Can't read userspace from dump, or kernel process---

(kgdb) fr 14
#14 0xc030652c in vm_page_wakeup (m=0x0) at /usr/src/sys/vm/vm_page.c:324
324 vm_page_flag_clear(m, PG_BUSY);
(kgdb) up
#15 0xc058142f in ?? ()

-- 
[EMAIL PROTECTED]

To Unsubscribe: send mail to [EMAIL PROTECTED]
with unsubscribe freebsd-current in the body of the message

Re: minor yacc warnings

[David O'Brien]

On Mon, Feb 03, 2003 at 09:24:10PM -0700, Chad David wrote:
 We are having minor problems with a newer gcc generating warnings
 for yacc due to yyrcsid not being used.  Does anyone object to the
 following patch to skeleton.c or have a better way of handling this?
 -Dlint causes other problems.

What's the warning you are quieting?

To Unsubscribe: send mail to [EMAIL PROTECTED]
with unsubscribe freebsd-current in the body of the message

Re: se7500+dual xeon?

[Victor Ponomarev]

Hi Scott!

You right only partially :)
The old method of kernel building doesn't work correctly (config 
KERNEL;cd ../compile/KERNEL;make depend;make)
Using make buildkernel ones produces a real support for SMP but warnig 
remains and power button doesn't work :(

Scott Long wrote:

What exactly are you pointing out that doesn't work?  It looks like 
you're using the default GENERIC uni-processor kernel from the 5.0 
release.  You'll need to recompile your kernel for SMP.

Scott

Victor Ponomarev wrote:

Hi All.

It's seems that smp kernel configuration doesn't  work correctly on
Intel SE7500WV2 motherboard
with 2 xeon processors in 5.0-RELEASE.

Copyright (c) 1992-2003 The FreeBSD Project.
Copyright (c) 1979, 1980, 1983, 1986, 1988, 1989, 1991, 1992, 1993, 1994
   The Regents of the University of California. All rights reserved.
FreeBSD 5.0-RELEASE #0: Thu Jan 16 22:16:53 GMT 2003
   [EMAIL PROTECTED]:/usr/obj/usr/src/sys/GENERIC
Preloaded elf kernel /boot/kernel/kernel at 0xc0673000.
Preloaded elf module /boot/kernel/acpi.ko at 0xc06730a8.
Timecounter i8254  frequency 1193182 Hz
Timecounter TSC  frequency 2592366912 Hz
CPU: Pentium 4 (2592.37-MHz 686-class CPU)
 Origin = GenuineIntel  Id = 0xf27  Stepping = 7

Features=0xbfebfbff

real memory  = 2147418112 (2047 MB)
avail memory = 2083561472 (1987 MB)
Initializing GEOMetry subsystem
Pentium Pro MTRR support enabled
   ACPI-0625: *** Warning: Type override - [DEB_] had invalid type
(Integer) for Scope operator, changed to (Scope)
   ACPI-0625: *** Warning: Type override - [MLIB] had invalid type
(Integer) for Scope operator, changed to (Scope)
   ACPI-0625: *** Warning: Type override - [DATA] had invalid type
(String) for Scope operator, changed to (Scope)
   ACPI-0625: *** Warning: Type override - [SIO_] had invalid type
(String) for Scope operator, changed to (Scope)
   ACPI-0625: *** Warning: Type override - [LEDP] had invalid type
(String) for Scope operator, changed to (Scope)
   ACPI-0625: *** Warning: Type override - [GPEN] had invalid type
(String) for Scope operator, changed to (Scope)
   ACPI-0625: *** Warning: Type override - [GPST] had invalid type
(String) for Scope operator, changed to (Scope)
   ACPI-0625: *** Warning: Type override - [WUES] had invalid type
(String) for Scope operator, changed to (Scope)
   ACPI-0625: *** Warning: Type override - [WUSE] had invalid type
(String) for Scope operator, changed to (Scope)
   ACPI-0625: *** Warning: Type override - [SBID] had invalid type
(String) for Scope operator, changed to (Scope)
   ACPI-0625: *** Warning: Type override - [SWCE] had invalid type
(String) for Scope operator, changed to (Scope)
npx0:  on motherboard
npx0: INT 16 interface
acpi0:  on motherboard
   ACPI-1287: *** Error: Method execution failed, AE_NOT_EXIST
   ACPI-0625: *** Info: GPE Block0 defined as GPE0 to GPE15
   ACPI-0625: *** Info: GPE Block1 defined as GPE16 to GPE47
Using $PIR table, 19 entries at 0xc00f3070
acpi0: power button is handled as a fixed feature programming model.
Timecounter ACPI-fast  frequency 3579545 Hz
acpi_timer0: 24-bit timer at 3.579545MHz port 0x408-0x40b on acpi0
acpi_cpu0:  on acpi0
acpi_cpu1:  on acpi0
acpi_cpu2:  on acpi0
acpi_cpu3:  on acpi0
pcib0:  port 0xcf8-0xcff on acpi0
pci0:  on pcib0
pci0:  at device 0.1 (no driver attached)
pcib1:  at device 3.0 on pci0
pcib1: could not get PCI interrupt routing table for \\_SB_.PCI0.P0P5 -
AE_NOT_FOUND
pci2:  on pcib1
pci2:  at device 28.0 (no driver
attached)
pcib2:  at device 29.0 on pci2
pci4:  on pcib2
pci2:  at device 30.0 (no driver
attached)
pcib3:  at device 31.0 on pci2
pci3:  on pcib3
em0:  port
0x2040-0x207f mem 0xfeac-0xfead irq 10 at device 7.0 on pci3
em0:  Speed:N/A  Duplex:N/A
em1:  port
0x2000-0x203f mem 0xfeae-0xfeaf irq 10 at device 7.1 on pci3
em1:  Speed:N/A  Duplex:N/A
pci0:  at device 3.1 (no driver attached)
pcib4:  at device 30.0 on pci0
pci1:  on pcib4
atapci0:  port
0x1420-0x142f,0x140c-0x140f,0x1410-0x1417,0x1408-0x140b,0x1400-0x1407
mem 0xfe9e-0xfe9e3fff irq 9 at device 2.0 on pci1
ata2: at 0x1400 on atapci0
ata3: at 0x1410 on atapci0
pci1:  at device 12.0 (no driver attached)
isab0:  at device 31.0 on pci0
isa0:  on isab0
atapci1:  port
0x3a0-0x3af,0-0x3,0-0x7,0-0x3,0-0x7 at device 31.1 on pci0
ata0: at 0x1f0 irq 14 on atapci1
ata1: at 0x170 irq 15 on atapci1
pci0:  at device 31.3 (no driver attached)
atkbdc0:  port 0x64,0x60 irq 1 on acpi0
atkbd0:  flags 0x1 irq 1 on atkbdc0
kbd0 at atkbd0
acpi_ec0:  port 0xca7,0xca6 on acpi0
fdc0: cmd 3 failed at out byte 1 of 3
sio0 port 0x3f8-0x3ff irq 4 on acpi0
sio0: type 16550A
sio1 port 0x2f8-0x2ff irq 3 on acpi0
sio1: type 16550A
fdc0: cmd 3 failed at out byte 1 of 3
orm0:  at iomem
0xd3000-0xd47ff,0xd1800-0xd2fff,0xc8000-0xd17ff,0xc-0xc7fff on isa0
pmtimer0 on isa0
fdc0:  at port
0x3f7,0x3f0-0x3f5 irq 6 drq 2 on isa0
fdc0: FIFO enabled, 8 bytes threshold
fd0: 1440-KB 3.5 drive on fdc0 drive 0
ppc0: parallel port not found.
sc0:  at flags 0x100 

Re: se7500+dual xeon?

[Victor Ponomarev]

Hi Lanny!

I've used the last BIOS (0501.P05) from Intel (BMC 0.19, FRU/SDR 5.0.9, 
BIOS production release 4.0 (dated 2003-12-14))
BIOS shipped with the board didn't recognize XEON 2600 Mgz processors.
Old BIOS (0468.P01) on another machine shows the same warning...


SMP work well for 4.7-STABLE

Are a lot of warning about ACPI-0625 and following messages

ACPI-1287: *** Error: Method execution failed, AE_NOT_EXIST

pcib1: could not get PCI interrupt routing table for \\_SB_.PCI0.P0P5 - AE_NOT_FOUND

acpi0: power button is handled as a fixed feature programming model.

correct?

Using old kernel building process (config KERNEL and so on) doesn't work 
for freebsd 5.0, seems one should use make buildkernel instead...


Lanny Baron wrote:

Victor,
You have something messed up. Did you update the bios correctly?  Look
at your kernel as well.

We use the westville for several Servers and it boots multi-processor
just fine. In fact, the hyperthreading works and when booting you should
see 4 cpu's come up.

Cheers,
Lanny Baron
http://www.FreeBSDsystems.com

On Wed, 2003-02-05 at 04:57, Victor Ponomarev wrote:
 

Hi All.

It's seems that smp kernel configuration doesn't  work correctly on 
Intel SE7500WV2 motherboard
with 2 xeon processors in 5.0-RELEASE.

Copyright (c) 1992-2003 The FreeBSD Project.
Copyright (c) 1979, 1980, 1983, 1986, 1988, 1989, 1991, 1992, 1993, 1994
   The Regents of the University of California. All rights reserved.
FreeBSD 5.0-RELEASE #0: Thu Jan 16 22:16:53 GMT 2003
   [EMAIL PROTECTED]:/usr/obj/usr/src/sys/GENERIC
Preloaded elf kernel /boot/kernel/kernel at 0xc0673000.
Preloaded elf module /boot/kernel/acpi.ko at 0xc06730a8.
Timecounter i8254  frequency 1193182 Hz
Timecounter TSC  frequency 2592366912 Hz
CPU: Pentium 4 (2592.37-MHz 686-class CPU)
 Origin = GenuineIntel  Id = 0xf27  Stepping = 7
 
Features=0xbfebfbffFPU,VME,DE,PSE,TSC,MSR,PAE,MCE,CX8,APIC,SEP,MTRR,PGE,MCA,CMOV,PAT,PSE36,CLFLUSH,DTS,ACPI,MMX,FXSR,SSE,SSE2,SS,HTT,TM,b31
real memory  = 2147418112 (2047 MB)
avail memory = 2083561472 (1987 MB)
Initializing GEOMetry subsystem
Pentium Pro MTRR support enabled
   ACPI-0625: *** Warning: Type override - [DEB_] had invalid type 
(Integer) for Scope operator, changed to (Scope)
   ACPI-0625: *** Warning: Type override - [MLIB] had invalid type 
(Integer) for Scope operator, changed to (Scope)
   ACPI-0625: *** Warning: Type override - [DATA] had invalid type 
(String) for Scope operator, changed to (Scope)
   ACPI-0625: *** Warning: Type override - [SIO_] had invalid type 
(String) for Scope operator, changed to (Scope)
   ACPI-0625: *** Warning: Type override - [LEDP] had invalid type 
(String) for Scope operator, changed to (Scope)
   ACPI-0625: *** Warning: Type override - [GPEN] had invalid type 
(String) for Scope operator, changed to (Scope)
   ACPI-0625: *** Warning: Type override - [GPST] had invalid type 
(String) for Scope operator, changed to (Scope)
   ACPI-0625: *** Warning: Type override - [WUES] had invalid type 
(String) for Scope operator, changed to (Scope)
   ACPI-0625: *** Warning: Type override - [WUSE] had invalid type 
(String) for Scope operator, changed to (Scope)
   ACPI-0625: *** Warning: Type override - [SBID] had invalid type 
(String) for Scope operator, changed to (Scope)
   ACPI-0625: *** Warning: Type override - [SWCE] had invalid type 
(String) for Scope operator, changed to (Scope)
npx0: math processor on motherboard
npx0: INT 16 interface
acpi0: INTEL  SWV20on motherboard
   ACPI-1287: *** Error: Method execution failed, AE_NOT_EXIST
   ACPI-0625: *** Info: GPE Block0 defined as GPE0 to GPE15
   ACPI-0625: *** Info: GPE Block1 defined as GPE16 to GPE47
Using $PIR table, 19 entries at 0xc00f3070
acpi0: power button is handled as a fixed feature programming model.
Timecounter ACPI-fast  frequency 3579545 Hz
acpi_timer0: 24-bit timer at 3.579545MHz port 0x408-0x40b on acpi0
acpi_cpu0: CPU on acpi0
acpi_cpu1: CPU on acpi0
acpi_cpu2: CPU on acpi0
acpi_cpu3: CPU on acpi0
pcib0: ACPI Host-PCI bridge port 0xcf8-0xcff on acpi0
pci0: ACPI PCI bus on pcib0
pci0: unknown at device 0.1 (no driver attached)
pcib1: ACPI PCI-PCI bridge at device 3.0 on pci0
pcib1: could not get PCI interrupt routing table for \\_SB_.PCI0.P0P5 - 
AE_NOT_FOUND
pci2: ACPI PCI bus on pcib1
pci2: base peripheral, interrupt controller at device 28.0 (no driver 
attached)
pcib2: ACPI PCI-PCI bridge at device 29.0 on pci2
pci4: ACPI PCI bus on pcib2
pci2: base peripheral, interrupt controller at device 30.0 (no driver 
attached)
pcib3: ACPI PCI-PCI bridge at device 31.0 on pci2
pci3: ACPI PCI bus on pcib3
em0: Intel(R) PRO/1000 Network Connection, Version - 1.4.7 port 
0x2040-0x207f mem 0xfeac-0xfead irq 10 at device 7.0 on pci3
em0:  Speed:N/A  Duplex:N/A
em1: Intel(R) PRO/1000 Network Connection, Version - 1.4.7 port 
0x2000-0x203f mem 0xfeae-0xfeaf irq 10 at device 7.1 on pci3
em1:  Speed:N/A  Duplex:N/A
pci0: unknown at device 3.1 (no driver attached)

Please test: i386 pc98 TSC patch

[Poul-Henning Kamp]

Please test this patch and let me know if you see any trouble:

http://phk.freebsd.dk/patch/tsc.patch

Things to look out for:

Detected CPU/TSC frequency, is it what it should be ?

NTP performance: is the frequency correction stable ?

Thanks in advance!

-- 
Poul-Henning Kamp   | UNIX since Zilog Zeus 3.20
[EMAIL PROTECTED] | TCP/IP since RFC 956
FreeBSD committer   | BSD since 4.3-tahoe
Never attribute to malice what can adequately be explained by incompetence.

To Unsubscribe: send mail to [EMAIL PROTECTED]
with unsubscribe freebsd-current in the body of the message

Re: tired of crashes

[Kris Kennaway]

On Wed, Feb 05, 2003 at 11:47:44AM +0200, Vallo Kallaste wrote:

 ---
 panic: ufs_dirbad: bad dir
 cpuid = 1; lapic.id = 0100
 boot() called on cpu#1

I get those on the bento cluster when the disk is starting to fail.
dd'ing /dev/zero over it usually gives it some more life by forcing it
to remap bad blocks as it goes.

Kris



msg51824/pgp0.pgp
Description: PGP signature

Re: minor yacc warnings

[Chad David]

On Wed, Feb 05, 2003 at 09:46:56AM -0800, David O'Brien wrote:
 On Mon, Feb 03, 2003 at 09:24:10PM -0700, Chad David wrote:
  We are having minor problems with a newer gcc generating warnings
  for yacc due to yyrcsid not being used.  Does anyone object to the
  following patch to skeleton.c or have a better way of handling this?
  -Dlint causes other problems.
 
 What's the warning you are quieting?

gcc33  -DFreeBSD  -I/usr/home/davidc/dev/issci/inst/include -g  -Werror -O 
-Wuninitialized -Wreturn-type -Wcast-qual -Wwrite-strings -Wshadow -Wcast-align 
-Wpointer-arith -Wall -Wno-format-y2k -Wstrict-prototypes -c parser.c
parser.c:3: warning: `yyrcsid' defined but not used
*** Error code 1

-- 
Chad David[EMAIL PROTECTED]
www.FreeBSD.org   [EMAIL PROTECTED]
ISSci Inc.Calgary, Alberta Canada

To Unsubscribe: send mail to [EMAIL PROTECTED]
with unsubscribe freebsd-current in the body of the message

Re: rand() is broken

[Narvi]

On Sun, 2 Feb 2003, Andrey A. Chernov wrote:

 On Sun, Feb 02, 2003 at 17:30:48 +, Mark Murray wrote:
 
  Why not? Arc4 is a) deterministic and b) good for all bits.

 If you mean arc4random() function - not, because it use true randomness,
 if you mean RC4 algorithm, probably yes, but we should compare its
 distribution with our current variant and be sure that speed is
 acceptable. What form RC4 distribution have?


arc4 is the non-encumbered name for rc4 that is not derived from RSA
code

 --
 Andrey A. Chernov
 http://ache.pp.ru/



To Unsubscribe: send mail to [EMAIL PROTECTED]
with unsubscribe freebsd-current in the body of the message

Re: rand() is broken

[Narvi]

On Sun, 2 Feb 2003 [EMAIL PROTECTED] wrote:

 In message [EMAIL PROTECTED], Andrey A. Chernov writes:
 On Sun, Feb 02, 2003 at 19:32:50 +0100, [EMAIL PROTECTED] wrote:
 
  Anyway, last time we discussed this, I think we stuck with the rand()
  we had because we feared that people were using it's repeatable well
  documented sequence of random numbers in regression testing.
 
 As documented, it must be repeatable across the calls for same seed, that
 is all. It not means repeatable accross platforms or across different OS
 versions. In fact it is already not repeatable across different OS'es, so
 regression is limited. Also, regression must not stop bugs fixing progress
 in anycase.

 Our manual pages do not comprehensively list all compatibility
 concerns or concessions, waving our manpage about does not address
 the concern.

 As I said, I don't know how big a concern this is.  But last time
 it was enough of a concern to make us keep rand() as it was.


man srand on another system (for what its worth) says:

 The  rand()  function  uses  a  multiplicative  congruential
 random-number  generator with period 2**32 that returns suc-
 cessive pseudo-random numbers in the range of 0 to  RAND_MAX
 (defined in stdlib.h).

 The  srand() function uses the argument seed as a seed for a
 new sequence of pseudo-random numbers to be returned by sub-
 sequent calls to rand(). If srand() is then called with  the
 same  seed value, the sequence of pseudo-random numbers will
 be repeated.  If  rand()  is  called  before  any  calls  to
 srand()  have been made, the same sequence will be generated
 as when srand() is first called with a seed value of 1.


 Please surf the mail-archives to find the discussion, it contained
 a lot of good arguments from both sides, arguments which should
 be thought about before changing rand().

 --
 Poul-Henning Kamp   | UNIX since Zilog Zeus 3.20
 [EMAIL PROTECTED] | TCP/IP since RFC 956
 FreeBSD committer   | BSD since 4.3-tahoe
 Never attribute to malice what can adequately be explained by incompetence.

 To Unsubscribe: send mail to [EMAIL PROTECTED]
 with unsubscribe freebsd-current in the body of the message



To Unsubscribe: send mail to [EMAIL PROTECTED]
with unsubscribe freebsd-current in the body of the message

Re: rand() is broken

[Narvi]

On Sun, 2 Feb 2003, Juli Mallett wrote:

 * De: David Malone [EMAIL PROTECTED] [ Data: 2003-02-02 ]
   [ Subjecte: Re: rand() is broken ]
  On Sun, Feb 02, 2003 at 02:37:25PM -0800, Steve Kargl wrote:
FreeBSD   Redhat   SunOS
   660787754660787754645318364
 
  FWIW - AIX aggrees with Solaris.

 Endiannes, or an SVR4 implementation difference?

Not endianess, unless they did something really gross to the routine on
Solatis/x86

 --
 Juli Mallett [EMAIL PROTECTED]
 AIM: BSDFlata -- IRC: juli on EFnet
 OpenDarwin, Mono, FreeBSD Developer
 ircd-hybrid Developer, EFnet addict
 FreeBSD on MIPS-Anything on FreeBSD

 To Unsubscribe: send mail to [EMAIL PROTECTED]
 with unsubscribe freebsd-current in the body of the message



To Unsubscribe: send mail to [EMAIL PROTECTED]
with unsubscribe freebsd-current in the body of the message

Re: se7500+dual xeon?

[Lanny Baron]

Victor,
You have something messed up. Did you update the bios correctly?  Look
at your kernel as well.

We use the westville for several Servers and it boots multi-processor
just fine. In fact, the hyperthreading works and when booting you should
see 4 cpu's come up.

Cheers,
Lanny Baron
http://www.FreeBSDsystems.com

On Wed, 2003-02-05 at 04:57, Victor Ponomarev wrote:
 Hi All.
 
 It's seems that smp kernel configuration doesn't  work correctly on 
 Intel SE7500WV2 motherboard
 with 2 xeon processors in 5.0-RELEASE.
 
 Copyright (c) 1992-2003 The FreeBSD Project.
 Copyright (c) 1979, 1980, 1983, 1986, 1988, 1989, 1991, 1992, 1993, 1994
 The Regents of the University of California. All rights reserved.
 FreeBSD 5.0-RELEASE #0: Thu Jan 16 22:16:53 GMT 2003
 [EMAIL PROTECTED]:/usr/obj/usr/src/sys/GENERIC
 Preloaded elf kernel /boot/kernel/kernel at 0xc0673000.
 Preloaded elf module /boot/kernel/acpi.ko at 0xc06730a8.
 Timecounter i8254  frequency 1193182 Hz
 Timecounter TSC  frequency 2592366912 Hz
 CPU: Pentium 4 (2592.37-MHz 686-class CPU)
   Origin = GenuineIntel  Id = 0xf27  Stepping = 7
   
 
Features=0xbfebfbffFPU,VME,DE,PSE,TSC,MSR,PAE,MCE,CX8,APIC,SEP,MTRR,PGE,MCA,CMOV,PAT,PSE36,CLFLUSH,DTS,ACPI,MMX,FXSR,SSE,SSE2,SS,HTT,TM,b31
 real memory  = 2147418112 (2047 MB)
 avail memory = 2083561472 (1987 MB)
 Initializing GEOMetry subsystem
 Pentium Pro MTRR support enabled
 ACPI-0625: *** Warning: Type override - [DEB_] had invalid type 
 (Integer) for Scope operator, changed to (Scope)
 ACPI-0625: *** Warning: Type override - [MLIB] had invalid type 
 (Integer) for Scope operator, changed to (Scope)
 ACPI-0625: *** Warning: Type override - [DATA] had invalid type 
 (String) for Scope operator, changed to (Scope)
 ACPI-0625: *** Warning: Type override - [SIO_] had invalid type 
 (String) for Scope operator, changed to (Scope)
 ACPI-0625: *** Warning: Type override - [LEDP] had invalid type 
 (String) for Scope operator, changed to (Scope)
 ACPI-0625: *** Warning: Type override - [GPEN] had invalid type 
 (String) for Scope operator, changed to (Scope)
 ACPI-0625: *** Warning: Type override - [GPST] had invalid type 
 (String) for Scope operator, changed to (Scope)
 ACPI-0625: *** Warning: Type override - [WUES] had invalid type 
 (String) for Scope operator, changed to (Scope)
 ACPI-0625: *** Warning: Type override - [WUSE] had invalid type 
 (String) for Scope operator, changed to (Scope)
 ACPI-0625: *** Warning: Type override - [SBID] had invalid type 
 (String) for Scope operator, changed to (Scope)
 ACPI-0625: *** Warning: Type override - [SWCE] had invalid type 
 (String) for Scope operator, changed to (Scope)
 npx0: math processor on motherboard
 npx0: INT 16 interface
 acpi0: INTEL  SWV20on motherboard
 ACPI-1287: *** Error: Method execution failed, AE_NOT_EXIST
 ACPI-0625: *** Info: GPE Block0 defined as GPE0 to GPE15
 ACPI-0625: *** Info: GPE Block1 defined as GPE16 to GPE47
 Using $PIR table, 19 entries at 0xc00f3070
 acpi0: power button is handled as a fixed feature programming model.
 Timecounter ACPI-fast  frequency 3579545 Hz
 acpi_timer0: 24-bit timer at 3.579545MHz port 0x408-0x40b on acpi0
 acpi_cpu0: CPU on acpi0
 acpi_cpu1: CPU on acpi0
 acpi_cpu2: CPU on acpi0
 acpi_cpu3: CPU on acpi0
 pcib0: ACPI Host-PCI bridge port 0xcf8-0xcff on acpi0
 pci0: ACPI PCI bus on pcib0
 pci0: unknown at device 0.1 (no driver attached)
 pcib1: ACPI PCI-PCI bridge at device 3.0 on pci0
 pcib1: could not get PCI interrupt routing table for \\_SB_.PCI0.P0P5 - 
 AE_NOT_FOUND
 pci2: ACPI PCI bus on pcib1
 pci2: base peripheral, interrupt controller at device 28.0 (no driver 
 attached)
 pcib2: ACPI PCI-PCI bridge at device 29.0 on pci2
 pci4: ACPI PCI bus on pcib2
 pci2: base peripheral, interrupt controller at device 30.0 (no driver 
 attached)
 pcib3: ACPI PCI-PCI bridge at device 31.0 on pci2
 pci3: ACPI PCI bus on pcib3
 em0: Intel(R) PRO/1000 Network Connection, Version - 1.4.7 port 
 0x2040-0x207f mem 0xfeac-0xfead irq 10 at device 7.0 on pci3
 em0:  Speed:N/A  Duplex:N/A
 em1: Intel(R) PRO/1000 Network Connection, Version - 1.4.7 port 
 0x2000-0x203f mem 0xfeae-0xfeaf irq 10 at device 7.1 on pci3
 em1:  Speed:N/A  Duplex:N/A
 pci0: unknown at device 3.1 (no driver attached)
 pcib4: ACPI PCI-PCI bridge at device 30.0 on pci0
 pci1: ACPI PCI bus on pcib4
 atapci0: Promise TX2 ATA133 controller port 
 0x1420-0x142f,0x140c-0x140f,0x1410-0x1417,0x1408-0x140b,0x1400-0x1407 
 mem 0xfe9e-0xfe9e3fff irq 9 at device 2.0 on pci1
 ata2: at 0x1400 on atapci0
 ata3: at 0x1410 on atapci0
 pci1: display, VGA at device 12.0 (no driver attached)
 isab0: PCI-ISA bridge at device 31.0 on pci0
 isa0: ISA bus on isab0
 atapci1: Intel ICH3 ATA100 controller port 
 0x3a0-0x3af,0-0x3,0-0x7,0-0x3,0-0x7 at device 31.1 on pci0
 ata0: at 0x1f0 irq 14 on atapci1
 ata1: at 0x170 irq 15 on atapci1
 pci0: serial bus, SMBus at device 31.3 (no 

Wrong date for DEVFS entries

[Andrey A. Chernov]

Look at the snapshot below, taken right after boot time. Most entries are
at Feb 5 22:34 which is boot time, but some other are Feb 6 01:34  
which is in the future! It looks like TZ offset added for them by mistake.
Please fix this bug.

total 1
crw---  1 root  wheel 152,   0 Feb  5 22:34 acpi
crw-rw-r--  1 root  operator   39,   0 Feb  5 22:34 apm
crw---  1 root  wheel   0,   0 Feb  5 22:34 console
crw---  1 root  wheel  12, 255 Feb  6 01:34 consolectl
crw-rw-rw-  1 root  wheel   1,   0 Feb  5 22:34 ctty
crw-r-  1 root  operator4,   1 Feb  5 22:34 da0
crw-r-  1 root  operator4,   2 Feb  5 22:34 da0s1
crw-r-  1 root  operator4,   3 Feb  6 01:34 da0s1a
crw-r-  1 root  operator4,   4 Feb  6 01:34 da0s1b
crw-r-  1 root  operator4,   5 Feb  5 22:34 da0s1c
crw---  1 root  wheel 173,   0 Feb  5 22:34 devctl
dr-xr-xr-x  2 root  wheel  512 Feb  6 01:34 fd
crw-r-  1 root  operator9,   0 Feb  5 22:34 fd0
crw-r-  1 root  operator4,   0 Feb  5 22:34 geom.ctl
crw---  1 root  wheel   2,  14 Feb  5 22:34 io
crw---  1 root  wheel   7,   0 Feb  5 22:34 klog
crw-r-  1 root  kmem2,   1 Feb  5 22:34 kmem
lrwxr-xr-x  1 root  wheel3 Feb  5 22:34 log - /var/run/log
crw-r-  1 root  kmem2,   0 Feb  5 22:34 mem
dr-xr-xr-x  2 root  wheel  512 Feb  6 01:34 net
lrwxr-xr-x  1 root  wheel4 Feb  6 01:34 net1 - net/de0
lrwxr-xr-x  1 root  wheel4 Feb  6 01:34 net2 - net/lo0
crw---  1 root  wheel 165,   0 Feb  5 22:34 network
crw-rw-rw-  1 root  wheel   2,   2 Feb  5 22:37 null
crw---  1 root  operator   31,   0 Feb  5 22:34 pass0
crw-r--r--  1 root  wheel  78,   0 Feb  5 22:34 pci
crw-rw-rw-  1 root  wheel   6,   0 Feb  5 22:40 ptyp0
crw-rw-rw-  1 root  wheel   2,   3 Feb  6 01:34 random
lrwxr-xr-x  1 root  wheel6 Feb  6 01:34 stderr - fd/2
lrwxr-xr-x  1 root  wheel5 Feb  6 01:34 stdin - fd/0
lrwxr-xr-x  1 root  wheel6 Feb  6 01:34 stdout - fd/1
crw---  1 root  wheel  12, 128 Feb  5 22:34 sysmouse
crw--w  1 ache  tty 5,   0 Feb  5 22:40 ttyp0
crw---  1 root  wheel  12,   0 Feb  5 22:34 ttyv0
crw---  1 root  wheel  12,   1 Feb  5 22:34 ttyv1
crw---  1 root  wheel  12,   2 Feb  5 22:34 ttyv2
crw---  1 root  wheel  12,   3 Feb  5 22:34 ttyv3
crw---  1 root  wheel  12,   4 Feb  5 22:34 ttyv4
crw---  1 root  wheel  12,   5 Feb  5 22:34 ttyv5
crw---  1 root  wheel  12,   6 Feb  5 22:34 ttyv6
crw---  1 root  wheel  12,   7 Feb  5 22:34 ttyv7
crw---  1 root  wheel  12,   8 Feb  5 22:34 ttyv8
crw---  1 root  wheel  12,   9 Feb  5 22:34 ttyv9
crw---  1 root  wheel  12,  10 Feb  5 22:34 ttyva
crw---  1 root  wheel  12,  11 Feb  5 22:34 ttyvb
crw---  1 root  wheel  12,  12 Feb  5 22:34 ttyvc
crw---  1 root  wheel  12,  13 Feb  5 22:34 ttyvd
crw---  1 root  wheel  12,  14 Feb  5 22:34 ttyve
crw---  1 root  wheel  12,  15 Feb  5 22:34 ttyvf
lrwxr-xr-x  1 root  wheel7 Feb  6 01:34 urandom - random
lrwxr-xr-x  1 root  wheel3 Feb  5 22:34 vga - ttyv0
crw---  1 root  operator  104,   0 Feb  5 22:34 xpt0
crw-rw-rw-  1 root  wheel   2,  12 Feb  5 22:34 zero

-- 
Andrey A. Chernov
http://ache.pp.ru/

To Unsubscribe: send mail to [EMAIL PROTECTED]
with unsubscribe freebsd-current in the body of the message

Re: Wrong date for DEVFS entries

[phk]

In message [EMAIL PROTECTED], Andrey A. Chernov writes:
Look at the snapshot below, taken right after boot time. Most entries are
at Feb 5 22:34 which is boot time, but some other are Feb 6 01:34  
which is in the future! It looks like TZ offset added for them by mistake.
Please fix this bug.

My guess:  Your RTC has the wrong time and ntpdate or similar stepped
your clock to be correct.

There is nothing in DEVFS which knows about timezones, but there is
code to set the initial time to the estimated boottime.

If your system comes up, takes wrong time from RTC, the dev entries
will get this wrong time before the system gets a chance to set it
right across the network.

Originally, the timestamps in DEVFS started out as zero, ie:
1970010100 (moduls timezone) but people didn't like that and the
abovementioned code was introduced.

-- 
Poul-Henning Kamp   | UNIX since Zilog Zeus 3.20
[EMAIL PROTECTED] | TCP/IP since RFC 956
FreeBSD committer   | BSD since 4.3-tahoe
Never attribute to malice what can adequately be explained by incompetence.

To Unsubscribe: send mail to [EMAIL PROTECTED]
with unsubscribe freebsd-current in the body of the message

5.0 issues

[Oliver Fromme]

First of all, is this the right mailing list for issues
with FreeBSD 5.0-Release?  I apologize if it is not.

I've installed it on an Athlon-500, and it's running quite
well (except it seems a bit less performant than 4.x, but
that's OK).  However, I have two questions.

1.  I have some shell scripts that make use of redirections
with file descriptors (31 and /dev/fd/3 etc.).  Those
worked under 4.x out of the box, but didn't work in 5.0,
because there is no /dev/fd/3 in DEVFS.  I solved this by
manually mounting FDESCFS over /dev/fd -- is that the right
solution, or is there a better way?

2.  It seems that vmstat prints weird values:

procs memorypage   disks  faults cpu
r b wavm   fre flt re pi po fr sr ad0 md0in sy   cs us sy id
2 2 0 122848 23320  10  0  0  0 10  3   0   0 15852  0 1503 73 15 12
1 2 0 122848 22992   1  0  0  0 17  0   0   0 15911  0 1484 83 17  0
2 2 0 122848 22632   0  0  0  0 18  0   0   0 15916  0 1451 81 19  0

In particular, the sy (system calls) column is always
zero, and the values in the in (interrupts) column are
much too high.  This machine is running with HZ=500, and
vmstat -i reports a total interrupt rate of 628, which
seems more reasonable.

Regards
   Oliver

-- 
Oliver Fromme, secnetix GmbH  Co KG, Oettingenstr. 2, 80538 München
Any opinions expressed in this message may be personal to the author
and may not necessarily reflect the opinions of secnetix in any way.

All that we see or seem is just a dream within a dream (E. A. Poe)

To Unsubscribe: send mail to [EMAIL PROTECTED]
with unsubscribe freebsd-current in the body of the message

Re: 5.0 issues

[phk]

In message [EMAIL PROTECTED], Oliver Fromme writes
:

1.  I have some shell scripts that make use of redirections
with file descriptors (31 and /dev/fd/3 etc.).  Those
worked under 4.x out of the box, but didn't work in 5.0,
because there is no /dev/fd/3 in DEVFS.  I solved this by
manually mounting FDESCFS over /dev/fd -- is that the right
solution, or is there a better way?

There is a bug in the /bin/sh which I belive may be present in 5.0-R
where the shell uses fd=3 internally.

For the other part of the question: yes, that is the right way
if you want to use filedescriptors  2.

-- 
Poul-Henning Kamp   | UNIX since Zilog Zeus 3.20
[EMAIL PROTECTED] | TCP/IP since RFC 956
FreeBSD committer   | BSD since 4.3-tahoe
Never attribute to malice what can adequately be explained by incompetence.

To Unsubscribe: send mail to [EMAIL PROTECTED]
with unsubscribe freebsd-current in the body of the message

¸gÀ礧¯«ªº¯µ±K

[jerry]

Title: ¦L¶r¾÷





  
  
  
  
   
 
   ·s¦~§ª«°e±z¤@¥x¦L¶r¾÷ 
... 






To Unsubscribe: send mail to [EMAIL PROTECTED]
with "unsubscribe freebsd-current" in the body of the message

vnode locking question.

[Julian Elischer]

Is there ever a case when a vnode is locked for longer than the duration
of the syscall that locked it?





To Unsubscribe: send mail to [EMAIL PROTECTED]
with unsubscribe freebsd-current in the body of the message

Re: Wrong date for DEVFS entries

[Andrey A. Chernov]

On Wed, Feb 05, 2003 at 20:52:54 +0100, [EMAIL PROTECTED] wrote:
 
 My guess:  Your RTC has the wrong time and ntpdate or similar stepped
 your clock to be correct.

It is each boot repeated effect, not one time.
I run local clock in BIOS and use adjkerntz(8) to correct kernel time to 
GMT, via standard /etc/wall_cmos_clock knob. It there any chance that 
DEVFS comes up in the middle? If yes, is there any ideas for workaround?


-- 
Andrey A. Chernov
http://ache.pp.ru/

To Unsubscribe: send mail to [EMAIL PROTECTED]
with unsubscribe freebsd-current in the body of the message

Re: Wrong date for DEVFS entries

[phk]

In message [EMAIL PROTECTED], Andrey A. Chernov writes:
On Wed, Feb 05, 2003 at 20:52:54 +0100, [EMAIL PROTECTED] wrote:
 
 My guess:  Your RTC has the wrong time and ntpdate or similar stepped
 your clock to be correct.

It is each boot repeated effect, not one time.
I run local clock in BIOS and use adjkerntz(8) to correct kernel time to 
GMT, via standard /etc/wall_cmos_clock knob. It there any chance that 
DEVFS comes up in the middle? If yes, is there any ideas for workaround?

You can try this patch instead.  It has a different side effect:
if you reset your clock the (untouched) timestamps will change.

Index: devfs_vnops.c
===
RCS file: /home/ncvs/src/sys/fs/devfs/devfs_vnops.c,v
retrieving revision 1.60
diff -u -r1.60 devfs_vnops.c
--- devfs_vnops.c   29 Jan 2003 22:36:45 -  1.60
+++ devfs_vnops.c   5 Feb 2003 19:58:52 -
@@ -243,22 +243,19 @@
} while (0)
 
if (vp-v_type != VCHR)  {
-   fix(de-de_atime);
vap-va_atime = de-de_atime;
-   fix(de-de_mtime);
vap-va_mtime = de-de_mtime;
-   fix(de-de_ctime);
vap-va_ctime = de-de_ctime;
} else {
dev = vp-v_rdev;
-   fix(dev-si_atime);
vap-va_atime = dev-si_atime;
-   fix(dev-si_mtime);
vap-va_mtime = dev-si_mtime;
-   fix(dev-si_ctime);
vap-va_ctime = dev-si_ctime;
vap-va_rdev = dev-si_udev;
}
+   fix(vap-va_atime);
+   fix(vap-va_mtime);
+   fix(vap-va_ctime);
vap-va_gen = 0;
vap-va_flags = 0;
vap-va_nlink = de-de_links;
-- 
Poul-Henning Kamp   | UNIX since Zilog Zeus 3.20
[EMAIL PROTECTED] | TCP/IP since RFC 956
FreeBSD committer   | BSD since 4.3-tahoe
Never attribute to malice what can adequately be explained by incompetence.

To Unsubscribe: send mail to [EMAIL PROTECTED]
with unsubscribe freebsd-current in the body of the message

tmpfile breakage on setuid executables

[Anoop Ranganath]

The problem reared it's ugly head when maildrop started mishandling
mesasges.  Here is what I've tracked it down to:

I've used the code at the bottom of this message to isolate this
bug.  The summary is that when I compile the code as root, and then
make it setuid (chmod u+s a.out) and then try to run it as a user, the
tmpfile() fails.  If I run it as root, it works fine.  Conversely, I
can give user ownership of the executable, and then run it as user, and
it works great, but if fails for root.  Again this is only with the
setuid bit set.

My system is FreeBSD 5.0-RELEASE (GENERIC) #0: Thu Jan 16 22:16:53 GMT
2003

Thanks,
Anoop

#include stdlib.h
#include stdio.h

int main( void )
{
 FILE *stream;

 stream = tmpfile();
 if( stream != NULL ) {
 printf( File number is %d.\n, fileno( stream ) );
 fclose( stream );

 return EXIT_SUCCESS;
 }

 return EXIT_FAILURE;
}



To Unsubscribe: send mail to [EMAIL PROTECTED]
with unsubscribe freebsd-current in the body of the message

¸gÀ礧¯«ªº¯µ±K

[jerry]

Title: ¦L¶r¾÷





  
  
  
  
   
 
   ·s¦~§ª«°e±z¤@¥x¦L¶r¾÷ 
... 






To Unsubscribe: send mail to [EMAIL PROTECTED]
with "unsubscribe freebsd-current" in the body of the message

âÉÒÖÅ×ÁÑ ÔÏÒÇÏ×ÌÑ. ðÒÁ×ÉÌÁ É ÐÒÁËÔÉËÁ.

[a-group]

 
 õ×ÁÖÁÅÍÙÅ çÏÓÐÏÄÁ
!

 ðÒÅÄÓÔÁ×ÉÔÅÌØÓÔ×Ï Capital Standard Corporation ÓÏ×ÍÅÓÔÎÏ Ó
ËÏÍÐÁÎÉÅÊ A-Group  ÐÒÉÇÌÁÛÁÅÔ ÷ÁÓ ÐÒÉÎÑÔØ ÕÞÁÓÔÉÅ × 
 
ÓÅÍÉÎÁÒÅ ÎÁ ÔÅÍÕ:
  

  
 
 
  
 
 
 
 ðÒÁËÔÉÞÅÓËÉÅ ÁÓÐÅËÔÙ ÂÉÒÖÅ×ÏÊ ÔÏÒÇÏ×ÌÉ ÎÁ ÍÅÖÄÕÎÁÒÏÄÎÙÈ ÆÉÎÁÎÓÏ×ÙÈ ÒÙÎËÁÈ.
 
 
 
 
 
  


óÅÍÉÎÁÒ ÓÏÓÔÏÉÔÓÑ:
14 

 ÆÅ×ÒÁÌÑ
2003Ç
 ðÏ ÁÄÒÅÓÕ:
  Ç. 
ëÉÅ×, ÇÏÓÔÉÎÉÃÁ óÁÎËÔ-ðÅÒÅÒÂÕÒÇ (ÂÕÌØ×ÁÒ ô.ûÅ×ÞÅÎËÏ, 4)  

ãÅÌØ

ÓÅÍÉÎÁÒÁ: 


ðÏÌÕÞÉÔØ ÎÁÇÌÑÄÎÕÀ ÉÎÆÏÒÍÁÃÉÀ Ï ÍÅÖÄÕÎÁÒÏÄÎÙÈ ÆÉÎÁÎÓÏ×ÙÈ, 
ÔÏ×ÁÒÎÙÈ É ÆÏÎÄÏ×ÙÈ ÒÙÎËÁÈ,
Ï ÍÅÈÁÎÉÚÍÁÈ ÒÁÂÏÔÙ ÎÁ ÐÒÉÍÅÒÅ 
þÉËÁÇÓËÏÊ ÂÉÒÖÉ, 

Õ×ÉÄÅÔØ × 
ÒÅÁÌØÎÏÍ ×ÒÅÍÅÎÉ Ä×ÉÖÅÎÉÅ ×ÁÌÀÔ É ÕÚÎÁÔØ ËÁË ÍÏÖÎÏ ÐÒÁ×ÉÌØÎÏ ÉÎ×ÅÓÔÉÒÏ×ÁÔØ É × 
ÄÁÌØÎÅÊÛÅÍ ÐÒÉÕÍÎÏÖÁÔØ Ó×ÏÊ ËÁÐÉÔÁÌ. ðÒÏÇÒÁÍÍÁ ÓÅÍÉÎÁÒÁ ÐÒÅÄÕÓÍÁÔÒÉ×ÁÅÔ
ÐÏÌÕÞÅÎÉÅ ÏÔ×ÅÔÏ× ÎÁ ÉÎÔÅÒÅÓÕÀÝÉÅ ×ÏÐÒÏÓÙ, ËÏÎÓÕÌØÔÁÃÉÉ É ÄÏËÌÁÄÙ 
ÓÐÅÃÉÁÌÉÓÔÏ×-ÐÒÁËÔÉËÏ×.
 


ìÅËÔÏÒÙ É ×ÅÄÕÝÉÅ ÓÅÍÉÎÁÒÁ: 
ÐÒÅÄÓÔÁ×ÌÑÀÝÉÊ ÂÒÏËÅÒ 
CSCorp., 
ÓÐÅÃÉÁÌÉÓÔ ÐÏ ÂÉÒÖÅ×ÙÍ ÏÐÅÒÁÃÉÑÍ (Chicago 
Mercantile Exchange, 
Chicago Board of Trade).

÷ ÐÒÏÇÒÁÍÍÅ:
 
 óÐÅËÕÌÑÃÉÉ  ËÁË ÓÐÏÓÏÂ ÐÒÉÕÍÎÏÖÅÎÉÑ 
 ËÁÐÉÔÁÌÁ:
 
 
 þÁÓÔÎÙÅ ÉÎ×ÅÓÔÏÒÙ;
 ëÏÒÐÏÒÁÔÉ×ÎÙÅ É ÄÒÕÇÉÅ ÕÞÁÓÔÎÉËÉ ÒÙÎËÁ;
 ëÁËÏÊ ÓÕÍÍÙ ÄÏÓÔÁÔÏÞÎÏ ÄÌÑ ÒÁÂÏÔÙ;
 þÅÍ, ÇÄÅ É ËÁË ÔÏÒÇÏ×ÁÔØ. 
 éÎÓÔÒÕÍÅÎÔÙ ÍÉÒÏ×ÙÈ ÔÏ×ÁÒÎÙÈ É ÆÉÎÁÎÓÏ×ÙÈ 
 ÒÙÎËÏ×:
 ãÅÎÎÙÅ ÂÕÍÁÇÉ;
 íÅÖÄÕÎÁÒÏÄÎÙÊ ÒÙÎÏË ÏÂÍÅÎÁ ×ÁÌÀÔ;
 æØÀÞÅÒÓÎÙÅ É ÏÐÃÉÏÎÎÙÅ ËÏÎÔÒÁËÔÙ. 
 ôÅÈÎÏÌÏÇÉÑ É ÍÅÈÁÎÉÚÍ ÂÉÒÖÅ×ÙÈ ×ÎÅÂÉÒÖÅ×ÙÈ 
 ÏÐÅÒÁÃÉÊ:
 úÁËÏÎÏÄÁÔÅÌØÎÁÑ ÂÁÚÁ, ÐÒÁ×ÉÌÁ É ÐÒÁËÔÉËÁ ÁÍÅÒÉËÁÎÓËÏÊ ÍÏÄÅÌÉ ÔÏÒÇÏ×ÌÉ;
 ÷ÁÌÀÔÎÙÊ ÒÙÎÏË spot;
 âÉÒÖÅ×ÙÅ ÔÏÒÇÏ×ÙÅ ÓÉÓÔÅÍÙ;
 ëÏÍÐØÔÅÎÙÅ ÔÏÒÇÏ×ÙÅ ÓÉÓÔÅÍÙ;
 ëÌÉÒÉÎÇÏ×ÙÅ (ÒÁÓÞÅÔÎÙÅ) ÓÉÓÔÅÍÙ ÐÏ ÏÂÓÌÕÖÉ×ÁÎÉÀ ÏÐÅÒÁÃÉÊ;
 éÎÆÏÒÍÁÃÉÏÎÎÙÅ ÓÉÓÔÅÍÙ É ËÏÍÐØÀÔÅÒÎÙÅ ÔÅÈÎÏÌÏÇÉÉ ÐÏ ÏÂÅÓÐÅÞÅÎÉÀ ÄÉÌÉÎÇÏ×ÙÈ 
 ÏÐÅÒÁÃÉÊ.
 äÏÔÉÖÅÎÉÅ ÒÙÎËÁ:
 âÒÏËÅÒÓËÁÑ ËÏÍÐÁÎÉÑ;
 ðÒÉÎÃÉÐÁÌ (ÍÁÒËÅÔ-ÍÅÊËÅÒ);
 ôÏÒÇÏ×ÙÊ ÓÞÅÔ;
 íÁÒÖÁ;
 ëÒÅÄÉÔÎÏÅ ÐÌÅÞÏ;
 óÏ×ÅÒÛÅÎÉÅ ÓÄÅÌËÉ;
 ðÌÀÓÙ É ÍÉÎÕÓÙ ÉÎÔÅÒÎÅÔ-ÔÏÒÇÏ×ÌÉ;
 ðÒÉÂÙÌØÎÏÓÔØ ÏÐÅÒÁÃÉÊ. 
 ðÒÏÇÎÏÚÉÒÏ×ÁÎÉÅ ÒÙÎÏÞÎÙÈ ÔÅÎÄÅÎÃÉÊ:
 ôÅÈÎÉÞÅÓËÉÊ ÁÎÁÌÉÚ;
 æÕÎÄÁÍÅÎÔÁÌØÎÙÊ ÁÎÁÌÉÚ;
 ðÒÏÆÅÓÓÉÏÎÁÌØÎÙÅ ËÏÍÐØÀÔÅÒÎÙÅ ÓÉÓÔÅÍÙ É ÐÒÏÇÒÁÍÍÎÏÅ ÏÂÅÓÐÅÞÅÎÉÅ, 
 ÉÓÐÏÌØÚÕÅÍÏÅ × ÒÁÂÏÔÅ ÄÉÌÅÒÏ×. 
 ôÏÒÇÏ×ÙÅ ÓÔÒÁÔÅÇÉÉ É ÔÁËÔÉËÉ:
 óÐÅËÕÌÑÔÉ×ÎÙÅ ÏÐÅÒÁÃÉÉ;
 õÐÒÁ×ÌÅÎÉÅ ÐÏÒÔÆÅÌÅÍ;
 èÅÄÖÉÒÏ×ÁÎÉÅ ÜËÓÐÏÒÔÎÏ-ÉÍÐÏÒÔÎÙÈ ÏÐÅÒÁÃÉÊ.   
òÅÖÉÍ ÐÒÏ×ÅÄÅÎÉÑ ÓÅÍÉÎÁÒÁ :  
  09:30 - 19:00 - ×ÒÅÍÑ ÐÒÏ×ÅÄÅÎÉÑ 
 ÓÅÍÉÎÁÒÁ, Ó 
 ÐÅÒÅÒÙ×ÁÍÉ ÎÁ ËÏÆÅ É ÏÂÅÄ  
óÔÏÉÍÏÓÔØ ÕÞÁÓÔÉÑ × 
ÓÅÍÉÎÁÒÅ: 
450 ÇÒÎ. ÚÁ ÏÄÎÏÇÏ ÕÞÁÓÔÎÉËÁ. 
 
äÌÑ ÕÞÁÓÔÉÑ
ÎÅÏÂÈÏÄÉÍÏ:  ðÏÌÕÞÉÔØ ÓÞÅÔ ÄÌÑ ÏÐÌÁÔÙ ÐÏ ÆÁËÓÕ ; 
 ïÐÌÁÔÉÔØ ÓÞÅÔ ; 
 éÍÅÔØ ÐÒÉ ÓÅÂÅ ÐÁÓÐÏÒÔ É ËÏÐÉÀ ÐÌÁÔÅÖÎÏÇÏ ÄÏËÕÍÅÎÔÁ.
  òÅÇÉÓÔÒÁÃÉÑ ÐÒÏ×ÏÄÉÔØÓÑ ÄÏ
12 ÆÅ×ÒÑÌÑ (×ËÌÀÞÉÔÅÌØÎÏ)  
óËÉÄËÉ: 
 ðÒÉ
ÏÐÌÁÔÅ ÄÏ  
 10 ÆÅ×ÒÁÌÑ - ÓËÉÄËÁ 10 %;  
 ðÒÉ ÒÅÇÉÓÔÒÁÃÉÉ 2-È É ÂÏÌÅÅ ÐÒÅÄÓÔÁ×ÉÔÅÌÅÊ Ó ÏÄÎÏÇÏ
ÐÒÅÄÐÒÉÑÔÉÑ - ÓËÉÄËÁ 10%;òÅÇÉÏÎÁÌØÎÙÍ ËÏÍÐÁÎÉÑÍ - ÓËÉÄËÁ 10 %.  

ëÏÎÔÁËÔÎÁÑ ÉÎÆÏÒÍÁÃÉÑ
É ÒÅÇÉÓÔÒÁÃÉÑ:(044) 269-82-31;269-97-54.  
  òÁÓÓÙÌËÁ ÏÒÇÁÎÉÚÏ×ÁÎÁ õËÒÁÉÎÓËÉÍ
ãÅÎÔÒÏÍ äÉÒÅËÔ íÜÊÌ. éÚ×ÉÎÉÔÅ ÅÓÌÉ ÉÎÆÏÒÍÁÃÉÑ ÎÅ ÚÁÉÎÔÅÒÅÓÏ×ÁÌÁ ×ÁÓ. ðÏ ×ÏÐÒÏÓÁÍ ÏÒÇÁÎÉÚÁÃÉÉ ÒÁÓÓÙÌÏË,
ÏÂÒÁÝÁÊÔÅÓØ ÐÏ ÔÅÌ. (044) 237 29 18. ó Õ×ÁÖÅÎÉÅÍ, ëÁÒÏÌÉÎÁ
íÅÎÄÅÌØ. 

To Unsubscribe: send mail to [EMAIL PROTECTED]
with "unsubscribe freebsd-current" in the body of the message

Re: tmpfile breakage on setuid executables

[Terry Lambert]

Anoop Ranganath wrote:
 The problem reared it's ugly head when maildrop started mishandling
 mesasges.  Here is what I've tracked it down to:
 
 I've used the code at the bottom of this message to isolate this
 bug.  The summary is that when I compile the code as root, and then
 make it setuid (chmod u+s a.out) and then try to run it as a user, the
 tmpfile() fails.  If I run it as root, it works fine.  Conversely, I
 can give user ownership of the executable, and then run it as user, and
 it works great, but if fails for root.  Again this is only with the
 setuid bit set.

Probably your real and effective UID's aren't the same.  Does your
SUID root program set the real UID from the effective UID?

-- Terry

To Unsubscribe: send mail to [EMAIL PROTECTED]
with unsubscribe freebsd-current in the body of the message

Re: tmpfile breakage on setuid executables

[Anoop Ranganath]

  I've used the code at the bottom of this message to isolate this
  bug.  The summary is that when I compile the code as root, and then
  make it setuid (chmod u+s a.out) and then try to run it as a user, the
  tmpfile() fails.  If I run it as root, it works fine.  Conversely, I
  can give user ownership of the executable, and then run it as user, and
  it works great, but if fails for root.  Again this is only with the
  setuid bit set.

 Probably your real and effective UID's aren't the same.  Does your
 SUID root program set the real UID from the effective UID?

Well, the code sample I submitted in my original email doesn't set any UID.
It just creates a tmpfile() and then verifies that it succeeded.  This is
definitely a regression from 4.7 though.  Running the same code on 4.7
succeeds, as it does on several other unix boxes.

Anoop


To Unsubscribe: send mail to [EMAIL PROTECTED]
with unsubscribe freebsd-current in the body of the message

Re: Wrong date for DEVFS entries

[Andrey A. Chernov]

On Wed, Feb 05, 2003 at 22:10:41 +0100, [EMAIL PROTECTED] wrote:
 
 You can try this patch instead.  It has a different side effect:
 if you reset your clock the (untouched) timestamps will change.

It not helps, see 00:48 - 03:48 future jump for some entries (00:48 is 
boot time):

total 1
crw-r--r--  1 root  operator  117,   0 Feb  6 00:48 acd0
crw-r--r--  1 root  operator  117,   1 Feb  6 00:48 acd1
crw---  1 root  wheel 152,   0 Feb  6 00:48 acpi
crw-r-  1 root  operator4,   1 Feb  6 00:48 ad0
crw-r-  1 root  operator4,   2 Feb  6 00:48 ad0s1
crw-r-  1 root  operator4,   4 Feb  6 00:48 ad0s1a
crw-r-  1 root  operator4,   5 Feb  6 00:48 ad0s1b
crw-r-  1 root  operator4,   6 Feb  6 00:48 ad0s1c
crw-r-  1 root  operator4,   3 Feb  6 00:48 ad0s2
crw---  1 root  wheel 148,   0 Feb  6 00:48 agpgart
crw-rw-r--  1 root  operator   39,   0 Feb  6 00:48 apm
crw---  1 root  operator  159,   0 Feb  6 00:48 ata
crw-rw-rw-  1 root  wheel  21,   0 Feb  6 00:48 bpsm0
crw---  1 root  wheel   0,   0 Feb  6 00:48 console
crw---  1 root  wheel  12, 255 Feb  6 00:48 consolectl
crw-rw-rw-  1 root  wheel   1,   0 Feb  6 00:48 ctty
crw-rw  1 uucp  dialer 28, 128 Feb  6 00:48 cuaa0
crw-rw  1 uucp  dialer 28, 129 Feb  6 00:48 cuaa1
crw-rw  1 uucp  dialer 28, 160 Feb  6 00:48 cuaia0
crw-rw  1 uucp  dialer 28, 161 Feb  6 00:48 cuaia1
crw-rw  1 uucp  dialer 28, 192 Feb  6 00:48 cuala0
crw-rw  1 uucp  dialer 28, 193 Feb  6 00:48 cuala1
crw---  1 root  wheel 173,   0 Feb  6 00:48 devctl
dr-xr-xr-x  2 root  wheel  512 Feb  6 03:48 fd
crw-r-  1 root  operator9,   0 Feb  6 00:48 fd0
crw-r-  1 root  operator4,   0 Feb  6 00:48 geom.ctl
crw---  1 root  wheel   2,  14 Feb  6 00:48 io
crw---  1 root  wheel   7,   0 Feb  6 00:48 klog
crw-r-  1 root  kmem2,   1 Feb  6 00:48 kmem
lrwxr-xr-x  1 root  wheel3 Feb  6 00:48 log - /var/run/log
crw---  1 root  wheel  16,   0 Feb  6 00:48 lpt0
crw---  1 root  wheel  16, 128 Feb  6 00:48 lpt0.ctl
crw-r-  1 root  kmem2,   0 Feb  6 00:48 mem
dr-xr-xr-x  2 root  wheel  512 Feb  6 03:48 net
lrwxr-xr-x  1 root  wheel4 Feb  6 03:48 net1 - net/lo0
crw---  1 root  wheel 165,   0 Feb  6 00:48 network
crw-rw-rw-  1 root  wheel   2,   2 Feb  6 00:48 null
crw-r--r--  1 root  wheel  78,   0 Feb  6 00:48 pci
crw-rw-rw-  1 root  wheel  21,   1 Feb  6 00:48 psm0
crw-rw-rw-  1 root  wheel   2,   3 Feb  6 03:48 random
crw---  1 root  wheel  26,   0 Feb  6 00:48 speaker
lrwxr-xr-x  1 root  wheel6 Feb  6 03:48 stderr - fd/2
lrwxr-xr-x  1 root  wheel5 Feb  6 03:48 stdin - fd/0
lrwxr-xr-x  1 root  wheel6 Feb  6 03:48 stdout - fd/1
crw---  1 root  wheel  12, 128 Feb  6 00:48 sysmouse
crw---  1 root  wheel  28,   0 Feb  6 00:48 ttyd0
crw---  1 root  wheel  28,   1 Feb  6 00:48 ttyd1
crw---  1 root  wheel  28,  32 Feb  6 00:48 ttyid0
crw---  1 root  wheel  28,  33 Feb  6 00:48 ttyid1
crw---  1 root  wheel  28,  64 Feb  6 00:48 ttyld0
crw---  1 root  wheel  28,  65 Feb  6 00:48 ttyld1
crw--w  1 ache  tty12,   0 Feb  6 00:49 ttyv0
crw---  1 root  wheel  12,   1 Feb  6 00:48 ttyv1
crw---  1 root  wheel  12,   2 Feb  6 00:48 ttyv2
crw---  1 root  wheel  12,   3 Feb  6 00:48 ttyv3
crw---  1 root  wheel  12,   4 Feb  6 00:48 ttyv4
crw---  1 root  wheel  12,   5 Feb  6 00:48 ttyv5
crw---  1 root  wheel  12,   6 Feb  6 00:48 ttyv6
crw---  1 root  wheel  12,   7 Feb  6 00:48 ttyv7
crw---  1 root  wheel  12,   8 Feb  6 00:48 ttyv8
crw---  1 root  wheel  12,   9 Feb  6 00:48 ttyv9
crw---  1 root  wheel  12,  10 Feb  6 00:48 ttyva
crw---  1 root  wheel  12,  11 Feb  6 00:48 ttyvb
crw---  1 root  wheel  12,  12 Feb  6 00:48 ttyvc
crw---  1 root  wheel  12,  13 Feb  6 00:48 ttyvd
crw---  1 root  wheel  12,  14 Feb  6 00:48 ttyve
crw---  1 root  wheel  12,  15 Feb  6 00:48 ttyvf
lrwxr-xr-x  1 root  wheel7 Feb  6 03:48 urandom - random
crw-rw  1 root  operator  108, 255 Feb  6 00:48 usb
crw-rw  1 root  operator  108,   0 Feb  6 00:48 usb0
crw-rw  1 root  operator  108,   1 Feb  6 00:48 usb1
crw-rw  1 root  operator  108,   2 Feb  6 00:48 usb2
lrwxr-xr-x  1 root  wheel3 Feb  6 00:48 vga - ttyv0
crw-rw-rw-  1 root  wheel   2,  12 Feb  6 00:48 zero

-- 
Andrey A. Chernov
http://ache.pp.ru/

To Unsubscribe: send mail to [EMAIL PROTECTED]
with unsubscribe freebsd-current in the body of the message

Re: tmpfile breakage on setuid executables

[Terry Lambert]

Anoop Ranganath wrote:
   I've used the code at the bottom of this message to isolate this
   bug.  The summary is that when I compile the code as root, and then
   make it setuid (chmod u+s a.out) and then try to run it as a user, the
   tmpfile() fails.  If I run it as root, it works fine.  Conversely, I
   can give user ownership of the executable, and then run it as user, and
   it works great, but if fails for root.  Again this is only with the
   setuid bit set.
 
  Probably your real and effective UID's aren't the same.  Does your
  SUID root program set the real UID from the effective UID?
 
 Well, the code sample I submitted in my original email doesn't set any UID.
 It just creates a tmpfile() and then verifies that it succeeded.  This is
 definitely a regression from 4.7 though.  Running the same code on 4.7
 succeeds, as it does on several other unix boxes.

We need to know how we think it's supposed to work, not how you
think it's supposed to work to determine if the error is in the
code OR in the fact some old bug was fixed going from 4.7-5.0,
and the fix is biting you, OR it's a real bug.

So if you don't want to answer the question about whether or not
the UID root program sets the real UID from the effective UID,
then you need to answer a different one:

Are you saying that the code you posted, without calling the
setuid(geteuid()); worked on 4.7 and not on 5.0, when you
chown root, chmod 4755 it?

-- Terry

To Unsubscribe: send mail to [EMAIL PROTECTED]
with unsubscribe freebsd-current in the body of the message

Re: Wrong date for DEVFS entries

[phk]

In message [EMAIL PROTECTED], Andrey A. Chernov writes:
On Wed, Feb 05, 2003 at 22:10:41 +0100, [EMAIL PROTECTED] wrote:
 
 You can try this patch instead.  It has a different side effect:
 if you reset your clock the (untouched) timestamps will change.

It not helps, see 00:48 - 03:48 future jump for some entries (00:48 is 
boot time):

Try to remove the three fix lines, and see what you get then.

-- 
Poul-Henning Kamp   | UNIX since Zilog Zeus 3.20
[EMAIL PROTECTED] | TCP/IP since RFC 956
FreeBSD committer   | BSD since 4.3-tahoe
Never attribute to malice what can adequately be explained by incompetence.

To Unsubscribe: send mail to [EMAIL PROTECTED]
with unsubscribe freebsd-current in the body of the message

Re: Wrong date for DEVFS entries

[Andrey A. Chernov]

On Wed, Feb 05, 2003 at 23:23:26 +0100, [EMAIL PROTECTED] wrote:
 
 Try to remove the three fix lines, and see what you get then.
 

Very strange effect: 3 kinds of entries appearse:
1) Jan  1  1970
2) Feb  6 01:36 (boot time)
3) Feb  6 04:36 (+3 TZ future jump)

total 1
crw-r--r--  1 root  operator  117,   0 Jan  1  1970 acd0
crw-r--r--  1 root  operator  117,   1 Jan  1  1970 acd1
crw---  1 root  wheel 152,   0 Jan  1  1970 acpi
crw-r-  1 root  operator4,   1 Jan  1  1970 ad0
crw-r-  1 root  operator4,   2 Jan  1  1970 ad0s1
crw-r-  1 root  operator4,   4 Jan  1  1970 ad0s1a
crw-r-  1 root  operator4,   5 Jan  1  1970 ad0s1b
crw-r-  1 root  operator4,   6 Jan  1  1970 ad0s1c
crw-r-  1 root  operator4,   3 Jan  1  1970 ad0s2
crw---  1 root  wheel 148,   0 Jan  1  1970 agpgart
crw-rw-r--  1 root  operator   39,   0 Jan  1  1970 apm
crw---  1 root  operator  159,   0 Jan  1  1970 ata
crw-rw-rw-  1 root  wheel  21,   0 Jan  1  1970 bpsm0
crw---  1 root  wheel   0,   0 Feb  6 01:36 console
crw---  1 root  wheel  12, 255 Jan  1  1970 consolectl
crw-rw-rw-  1 root  wheel   1,   0 Jan  1  1970 ctty
crw-rw  1 uucp  dialer 28, 128 Jan  1  1970 cuaa0
crw-rw  1 uucp  dialer 28, 129 Jan  1  1970 cuaa1
crw-rw  1 uucp  dialer 28, 160 Jan  1  1970 cuaia0
crw-rw  1 uucp  dialer 28, 161 Jan  1  1970 cuaia1
crw-rw  1 uucp  dialer 28, 192 Jan  1  1970 cuala0
crw-rw  1 uucp  dialer 28, 193 Jan  1  1970 cuala1
crw---  1 root  wheel 173,   0 Jan  1  1970 devctl
dr-xr-xr-x  2 root  wheel  512 Feb  6 04:36 fd
crw-r-  1 root  operator9,   0 Jan  1  1970 fd0
crw-r-  1 root  operator4,   0 Jan  1  1970 geom.ctl
crw---  1 root  wheel   2,  14 Jan  1  1970 io
crw---  1 root  wheel   7,   0 Jan  1  1970 klog
crw-r-  1 root  kmem2,   1 Jan  1  1970 kmem
lrwxr-xr-x  1 root  wheel3 Feb  6 01:36 log - /var/run/log
crw---  1 root  wheel  16,   0 Jan  1  1970 lpt0
crw---  1 root  wheel  16, 128 Jan  1  1970 lpt0.ctl
crw-r-  1 root  kmem2,   0 Jan  1  1970 mem
dr-xr-xr-x  2 root  wheel  512 Feb  6 04:36 net
lrwxr-xr-x  1 root  wheel4 Feb  6 04:36 net1 - net/lo0
crw---  1 root  wheel 165,   0 Jan  1  1970 network
crw-rw-rw-  1 root  wheel   2,   2 Feb  6 01:36 null
crw-r--r--  1 root  wheel  78,   0 Jan  1  1970 pci
crw-rw-rw-  1 root  wheel  21,   1 Jan  1  1970 psm0
crw-rw-rw-  1 root  wheel   2,   3 Feb  6 04:36 random
crw---  1 root  wheel  26,   0 Jan  1  1970 speaker
lrwxr-xr-x  1 root  wheel6 Feb  6 04:36 stderr - fd/2
lrwxr-xr-x  1 root  wheel5 Feb  6 04:36 stdin - fd/0
lrwxr-xr-x  1 root  wheel6 Feb  6 04:36 stdout - fd/1
crw---  1 root  wheel  12, 128 Jan  1  1970 sysmouse
crw---  1 root  wheel  28,   0 Jan  1  1970 ttyd0
crw---  1 root  wheel  28,   1 Jan  1  1970 ttyd1
crw---  1 root  wheel  28,  32 Jan  1  1970 ttyid0
crw---  1 root  wheel  28,  33 Jan  1  1970 ttyid1
crw---  1 root  wheel  28,  64 Jan  1  1970 ttyld0
crw---  1 root  wheel  28,  65 Jan  1  1970 ttyld1
crw--w  1 ache  tty12,   0 Feb  6 01:36 ttyv0
crw--w  1 ache  tty12,   1 Feb  6 01:37 ttyv1
crw---  1 root  wheel  12,   2 Feb  6 01:36 ttyv2
crw---  1 root  wheel  12,   3 Feb  6 01:36 ttyv3
crw---  1 root  wheel  12,   4 Feb  6 01:36 ttyv4
crw---  1 root  wheel  12,   5 Feb  6 01:36 ttyv5
crw---  1 root  wheel  12,   6 Feb  6 01:36 ttyv6
crw---  1 root  wheel  12,   7 Feb  6 01:36 ttyv7
crw---  1 root  wheel  12,   8 Jan  1  1970 ttyv8
crw---  1 root  wheel  12,   9 Jan  1  1970 ttyv9
crw---  1 root  wheel  12,  10 Jan  1  1970 ttyva
crw---  1 root  wheel  12,  11 Jan  1  1970 ttyvb
crw---  1 root  wheel  12,  12 Jan  1  1970 ttyvc
crw---  1 root  wheel  12,  13 Jan  1  1970 ttyvd
crw---  1 root  wheel  12,  14 Jan  1  1970 ttyve
crw---  1 root  wheel  12,  15 Jan  1  1970 ttyvf
lrwxr-xr-x  1 root  wheel7 Feb  6 04:36 urandom - random
crw-rw  1 root  operator  108, 255 Jan  1  1970 usb
crw-rw  1 root  operator  108,   0 Jan  1  1970 usb0
crw-rw  1 root  operator  108,   1 Jan  1  1970 usb1
crw-rw  1 root  operator  108,   2 Jan  1  1970 usb2
lrwxr-xr-x  1 root  wheel3 Feb  6 01:36 vga - ttyv0
crw-rw-rw-  1 root  wheel   2,  12 Jan  1  1970 zero

-- 
Andrey A. Chernov
http://ache.pp.ru/

To Unsubscribe: send mail to [EMAIL PROTECTED]
with unsubscribe freebsd-current in the body of the message

Re: Wrong date for DEVFS entries

[phk]

In message [EMAIL PROTECTED], Andrey A. Chernov writes:
On Wed, Feb 05, 2003 at 23:23:26 +0100, [EMAIL PROTECTED] wrote:
 
 Try to remove the three fix lines, and see what you get then.
 

Very strange effect: 3 kinds of entries appearse:
1) Jan  1  1970

These are the intact untouched timestamps.


2) Feb  6 01:36 (boot time)
3) Feb  6 04:36 (+3 TZ future jump)

These timestamps have been touched, and the clock has made a 3 hour
jump either forward or backward at some point.


The problem is the clock jump, not DEVFS.

Poul-Henning

To Unsubscribe: send mail to [EMAIL PROTECTED]
with unsubscribe freebsd-current in the body of the message

Re: tmpfile breakage on setuid executables

[Terry Lambert]

Terry Lambert wrote:
 We need to know how we think it's supposed to work, not how you
 think it's supposed to work to determine if the error is in the
 code OR in the fact some old bug was fixed going from 4.7-5.0,
 and the fix is biting you, OR it's a real bug.

For anyone who cares:

Additional information was provided off-list.  The problem was
indeed that setuid(geteuid()); was missing from the program.

Apparently, there was a bug fixed in 4.7 - 5.0, where the
effective UID was being tested instead of the real UID.

This is probably something that someone should MFC.

-- Terry

To Unsubscribe: send mail to [EMAIL PROTECTED]
with unsubscribe freebsd-current in the body of the message

Re: Wrong date for DEVFS entries

[Andrey A. Chernov]

On Wed, Feb 05, 2003 at 23:44:08 +0100, [EMAIL PROTECTED] wrote:
 
 2) Feb  6 01:36 (boot time)
 3) Feb  6 04:36 (+3 TZ future jump)
 
 These timestamps have been touched, and the clock has made a 3 hour
 jump either forward or backward at some point.
 
 
 The problem is the clock jump, not DEVFS.

Clock jump happens as it supposed when adjkerntz(8) corrects machine clock
back to GMT via various CPU_* sysctl's. Could touched DEVFS stamps be
fixed back to something useful in the same sysctl code too?

-- 
Andrey A. Chernov
http://ache.pp.ru/

To Unsubscribe: send mail to [EMAIL PROTECTED]
with unsubscribe freebsd-current in the body of the message

Re: tmpfile breakage on setuid executables

[Jacques A. Vidrine]

On Wed, Feb 05, 2003 at 02:59:15PM -0800, Terry Lambert wrote:
 Terry Lambert wrote:
  We need to know how we think it's supposed to work, not how you
  think it's supposed to work to determine if the error is in the
  code OR in the fact some old bug was fixed going from 4.7-5.0,
  and the fix is biting you, OR it's a real bug.
 
 For anyone who cares:
 
 Additional information was provided off-list.  The problem was
 indeed that setuid(geteuid()); was missing from the program.
 
 Apparently, there was a bug fixed in 4.7 - 5.0, where the
 effective UID was being tested instead of the real UID.
 
 This is probably something that someone should MFC.

Really?  I just took a quick look at this, but I have to shove off
for now.  In initial tests, I get the different results depending on
whether I'm using static or dynamic linking.  But maybe it's me, I'll
look more carefully later.

How about pointing out the bug you found?

Cheers,
-- 
Jacques A. Vidrine [EMAIL PROTECTED]  http://www.celabo.org/
NTT/Verio SME  . FreeBSD UNIX .   Heimdal Kerberos
[EMAIL PROTECTED] .  [EMAIL PROTECTED]  .  [EMAIL PROTECTED]

To Unsubscribe: send mail to [EMAIL PROTECTED]
with unsubscribe freebsd-current in the body of the message

Re: tmpfile breakage on setuid executables

[Mike Makonnen]

The original poster was right.
The following patch should fix it. I'll check it in as soon as my test cycle is
over.

Cheers.
-- 
Mike Makonnen  | GPG-KEY: http://www.identd.net/~mtm/mtm.asc
[EMAIL PROTECTED] | Fingerprint: D228 1A6F C64E 120A A1C9  A3AA DAE1 E2AF DBCC 68B9

Index: lib/libc/stdio/tmpfile.c
===
RCS file: /home/ncvs/src/lib/libc/stdio/tmpfile.c,v
retrieving revision 1.8
diff -u -r1.8 tmpfile.c
--- lib/libc/stdio/tmpfile.c13 Oct 2002 11:22:16 -  1.8
+++ lib/libc/stdio/tmpfile.c5 Feb 2003 23:37:28 -
@@ -61,6 +61,7 @@
char *buf;
const char *tmpdir;
 
+   tmpdir = NULL;
if (issetugid() == 0)
tmpdir = getenv(TMPDIR);
if (tmpdir == NULL)



msg51851/pgp0.pgp
Description: PGP signature

alpha tinderbox failure

[Dag-Erling Smorgrav]

--
 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/alpha/obj/h/des/src/alpha/usr/include
--
 stage 4: building libraries
--
 stage 4: make dependencies
--
 stage 4: building everything..
--
 Kernel build for GENERIC started on Wed Feb  5 15:11:38 PST 2003
--
 Kernel build for GENERIC completed on Wed Feb  5 15:45:57 PST 2003
--
 Kernel build for LINT started on Wed Feb  5 15:45:57 PST 2003
--
=== vinum
Makefile, line 4450: warning: duplicate script for target geom_bsd.o ignored
/h/des/src/sys/dev/lmc/if_lmc.c:32:2: warning: #warning The lmc driver is broken and 
is not compiled with LINT
/h/des/src/sys/dev/pdq/pdq.c: In function `pdq_initialize':
/h/des/src/sys/dev/pdq/pdq.c:1606: warning: cast discards qualifiers from pointer 
target type
/h/des/src/sys/pci/meteor.c:149:2: warning: #warning The meteor driver is broken and 
is not compiled with LINT
/h/des/src/sys/pci/simos.c:30:2: warning: #warning The simos driver is broken and is 
not compiled with LINT
/h/des/src/sys/dev/gfb/gfb_pci.c: In function `pcigfb_open':
/h/des/src/sys/dev/gfb/gfb_pci.c:268: `gfb_devclass' undeclared (first use in this 
function)
/h/des/src/sys/dev/gfb/gfb_pci.c:268: (Each undeclared identifier is reported only once
/h/des/src/sys/dev/gfb/gfb_pci.c:268: for each function it appears in.)
cc1: warnings being treated as errors
/h/des/src/sys/dev/gfb/gfb_pci.c:275: warning: passing arg 1 of `genfbopen' from 
incompatible pointer type
/h/des/src/sys/dev/gfb/gfb_pci.c: In function `pcigfb_close':
/h/des/src/sys/dev/gfb/gfb_pci.c:284: `gfb_devclass' undeclared (first use in this 
function)
/h/des/src/sys/dev/gfb/gfb_pci.c:285: warning: passing arg 1 of `genfbclose' from 
incompatible pointer type
/h/des/src/sys/dev/gfb/gfb_pci.c: In function `pcigfb_read':
/h/des/src/sys/dev/gfb/gfb_pci.c:293: `gfb_devclass' undeclared (first use in this 
function)
/h/des/src/sys/dev/gfb/gfb_pci.c:294: warning: passing arg 1 of `genfbread' from 
incompatible pointer type
/h/des/src/sys/dev/gfb/gfb_pci.c: In function `pcigfb_write':
/h/des/src/sys/dev/gfb/gfb_pci.c:302: `gfb_devclass' undeclared (first use in this 
function)
/h/des/src/sys/dev/gfb/gfb_pci.c:303: warning: passing arg 1 of `genfbwrite' from 
incompatible pointer type
/h/des/src/sys/dev/gfb/gfb_pci.c: In function `pcigfb_ioctl':
/h/des/src/sys/dev/gfb/gfb_pci.c:311: `gfb_devclass' undeclared (first use in this 
function)
/h/des/src/sys/dev/gfb/gfb_pci.c:312: warning: passing arg 1 of `genfbioctl' from 
incompatible pointer type
/h/des/src/sys/dev/gfb/gfb_pci.c: In function `pcigfb_mmap':
/h/des/src/sys/dev/gfb/gfb_pci.c:320: `gfb_devclass' undeclared (first use in this 
function)
/h/des/src/sys/dev/gfb/gfb_pci.c:321: warning: passing arg 1 of `genfbmmap' from 
incompatible pointer type
*** Error code 1

Stop in /h/des/obj/h/des/src/sys/LINT.
*** Error code 1

Stop in /h/des/src.
*** Error code 1

Stop in /h/des/src.

To Unsubscribe: send mail to [EMAIL PROTECTED]
with unsubscribe freebsd-current in the body of the message

Re: tmpfile breakage on setuid executables

[Terry Lambert]

Mike Makonnen wrote:
 The original poster was right.
 The following patch should fix it. I'll check it in as soon as my test cycle is
 over.

Holy heck.

Good freaking catch!

I would never have thought of looking for zebras, since it worked on
my 5.0 system, with all my test programs.

I thought of all *sorts* of crap, but not zebras:

o   Wrong permissions on /tmp

o   Wrong permissions on /tmp's mount point

o   TMPDIR being set to some place strange, like an SMBFS mount

o   nosuid on the mount of the FS where he was running the
program in question

o   Someone making /tmp more secure by removing group
permissions, and the user in question being in the (now)
exclusion group

o   Etc..

-- Terry killed by a zebra while wearing a pointy hat Lambert

To Unsubscribe: send mail to [EMAIL PROTECTED]
with unsubscribe freebsd-current in the body of the message

Re: tmpfile breakage on setuid executables

[Mike Barcroft]

Mike Makonnen [EMAIL PROTECTED] writes:
 The original poster was right.
 The following patch should fix it. I'll check it in as soon as my test cycle is
 over.
 
 Cheers.
 -- 
 Mike Makonnen  | GPG-KEY: http://www.identd.net/~mtm/mtm.asc
 [EMAIL PROTECTED] | Fingerprint: D228 1A6F C64E 120A A1C9  A3AA DAE1 E2AF DBCC 68B9
 
 Index: lib/libc/stdio/tmpfile.c
 ===
 RCS file: /home/ncvs/src/lib/libc/stdio/tmpfile.c,v
 retrieving revision 1.8
 diff -u -r1.8 tmpfile.c
 --- lib/libc/stdio/tmpfile.c  13 Oct 2002 11:22:16 -  1.8
 +++ lib/libc/stdio/tmpfile.c  5 Feb 2003 23:37:28 -
 @@ -61,6 +61,7 @@
   char *buf;
   const char *tmpdir;
  
 + tmpdir = NULL;
   if (issetugid() == 0)
   tmpdir = getenv(TMPDIR);
   if (tmpdir == NULL)

Looks like kris broke it.  Shame on us for not having a WARNS level on
libc big enough to catch simple regressions like this.

Best regards,
Mike Barcroft

To Unsubscribe: send mail to [EMAIL PROTECTED]
with unsubscribe freebsd-current in the body of the message

Re: tmpfile breakage on setuid executables

[Terry Lambert]

Jacques A. Vidrine wrote:
  Apparently, there was a bug fixed in 4.7 - 5.0, where the
  effective UID was being tested instead of the real UID.
 
  This is probably something that someone should MFC.
 
 Really?  I just took a quick look at this, but I have to shove off
 for now.  In initial tests, I get the different results depending on
 whether I'm using static or dynamic linking.  But maybe it's me, I'll
 look more carefully later.
 
 How about pointing out the bug you found?

Hand me the pointy hat.  The bug was that my test program
seperated the operation into a function so I could try different
crap, and adding the setuid(geteuid()) put a zero on the stack
in the stack position Mike discovered was being used uninitialized.

Really bizarre.  Shouldn't compiling that stdio code have cause a
warning?!?  Is optimization disabled for the stdio code?!?

-- Terry

To Unsubscribe: send mail to [EMAIL PROTECTED]
with unsubscribe freebsd-current in the body of the message

Re: tmpfile breakage on setuid executables

[Terry Lambert]

Mike Barcroft wrote:
 Looks like kris broke it.  Shame on us for not having a WARNS level on
 libc big enough to catch simple regressions like this.

FWIW, the warning doesn't show up unless the optimizer is on, even
with -Wall.  So it's probable that the optimizer is not on by
default, so no reason to beat up Kris.

I have to worry, though, about where else this might be happening,
now.  8-(.

-- Terry

To Unsubscribe: send mail to [EMAIL PROTECTED]
with unsubscribe freebsd-current in the body of the message

RE: Server locking hard -- A LOT!!!

[Muhannad Asfour]

On Wed, 2003-02-05 at 08:23, Forrest W. Christian wrote:
 On Wed, 5 Feb 2003, Robert Covell wrote:
 
   haven't come up with anything as I stated earlier.  I'm not overclocking
   or anything if that's what you're wondering.  If anyone could assist me
   in any way shape or form to get this working, I would appreciate it very
   very much.  Also, if you e-mail back, I'm not subscribed to the lists,
   so could you please CC it to me.  In the past 4 hours, it has locked
   hard about 3 times because of a 28-34 connection load.
 
 Cooling problems also match this symptom set.  (CPU sleeps less when
 loaded)  Do you have adequate cooling in this box?
 
 - Forrest W. Christian ([EMAIL PROTECTED]) AC7DE
 --
 The Innovation Machine Ltd.  P.O. Box 5749
 http://www.imach.com/Helena, MT  59604
 Home of PacketFlux Technologies and BackupDNS.com   (406)-442-6648
 --
   Protect your personal freedoms - visit http://www.lp.org/

Yes, cooling is not an issue, because I check the system temperatures
regulary, and they never really go above 40 C.


To Unsubscribe: send mail to [EMAIL PROTECTED]
with unsubscribe freebsd-current in the body of the message

Re: Server locking hard -- A LOT!!!

[Tuc]

 I have seen things like this that are not software related at all but due to
 a faulty power supply.

Two second story about faulty power supplies.

We had someone integrating machines for us, and we would test them 
over the net. Our test was to compile perl. (Don't ask me why...). We had
a pre configured perl package they'd load that we'd type make test and 
when it passed, we'd approve the machine (Along with alot of other checks).
One time all of a sudden in the middle of the compile it errors off. I
don't remember the error. I figure we had a bad set of code, so tried it
again. Same result. Rebuilt the machine with all new parts except the 
chassis, same results, same point, same error. Swapped the power supply, 
compiled fine!  

Next system, same problem. Asked them if they re-used the old power
supply, and they had. Told them to charge me for the supply and throw it 
away. Never had an issue like that before.

So, as weird as it might be, power supplies can do strange things to
a machine!

Tuc/TTSG Internet Services, Inc.

To Unsubscribe: send mail to [EMAIL PROTECTED]
with unsubscribe freebsd-current in the body of the message

RE: Server locking hard -- A LOT!!!

[Muhannad Asfour]

On Wed, 2003-02-05 at 08:20, Robert Covell wrote:
  -Original Message-
  From: [EMAIL PROTECTED]
  [mailto:[EMAIL PROTECTED]]On Behalf Of Muhannad Asfour
  Sent: Tuesday, February 04, 2003 9:25 PM
  To: [EMAIL PROTECTED]
  Cc: [EMAIL PROTECTED]
  Subject: Server locking hard -- A LOT!!!
 
 
  Hello.  I've recently faced a rather odd issue that I've never seen
  before.  I bought a new server (specs below), and I loaded it up with
  FreeBSD 5.0-RELEASE (I know, I know, not for a production environment,
  but this is a personal server).  Now, whenever I get about 30
  simultaneous connections, the box just locks hard.  I tested all the
  hardware components (CPU, Memory, HD, NIC, etc.) and even bought new
  ones just to make sure and all end up with the same result.  I can never
  keep a decent uptime (never went past 2 days so far).  As soon as I get
  a mediocre http load (30 simul. connections), the box just locks hard.
  I built a debug kernel, I tried everything imaginable, and I have not
  found a solution whatsoever.  Everyone seems to be stumped by this.  I
  tried FreeBSD 4.7-RELEASE, 4.7-STABLE, 5.0-RELEASE and 5.0-CURRENT on
  this box.  All give me the same result.  I checked everywhere for
  relevant logs to explain what is occuring, but had no such luck.  This
  is truly the million dollar question for me right now, because I have no
  idea why it would lock under such a petty load.  I'm not sure what to do
  to fix this issue, I've tried many different areas for support and
  haven't come up with anything as I stated earlier.  I'm not overclocking
  or anything if that's what you're wondering.  If anyone could assist me
  in any way shape or form to get this working, I would appreciate it very
  very much.  Also, if you e-mail back, I'm not subscribed to the lists,
  so could you please CC it to me.  In the past 4 hours, it has locked
  hard about 3 times because of a 28-34 connection load.
 
  Machine Specs:
  Single Pentium IV 2.4 GHz processor
  ASUS P4S533 motherboard
  512MB DDR333 RAM (will be 1GB next week)
  120GB Maxtor 7200rpm (ATA133) HDD
  40GB Maxtor 7200 rpm (ATA66) HDD
  Floppy Disk Drive
  ATI Rage 128 (32 meg) AGP 4x graphics adapter
  52x LG CD-ROM drive
  3Com 3C905C-TX NIC
  Currently running FreeBSD 5.0-CURRENT as of Sunday Feb. 2, 13:02:05 EST
  2003.
 
  Thank you very much
 
 
 
  To Unsubscribe: send mail to [EMAIL PROTECTED]
  with unsubscribe freebsd-questions in the body of the message
 
 I have seen things like this that are not software related at all but due to
 a faulty power supply.  Did you replace that when you went out and bought
 new hardware?  You might want to try and take off your CD-ROM and or the
 secondary HD.  This will cut back on your power usage and might be a good
 test.  If it still does it, get a new power supply that has enough juice.
 
 Sincerely,
 
 Robert T. Covell
 President / Owner
 Rolet Internet Services, LLC
 Web: www.rolet.com
 Email: [EMAIL PROTECTED]
 Phone: 816.471.1095
 Fax: 816.471.3447
 24x7: 816.210.7145
 
Well, I took off the CD-ROM drive, so now it's just the two HDs and a
floppy drive.  We'll see if it was a power supply issue after all.

Thanks


To Unsubscribe: send mail to [EMAIL PROTECTED]
with unsubscribe freebsd-current in the body of the message

Re: Server locking hard -- A LOT!!!

[Muhannad Asfour]

On Wed, 2003-02-05 at 19:23, Peter Kostouros wrote:
 Hi Muhannad
 
 Your dmesg output had the following:
 lock order reversal 1st 0xc2b5d230 process lock (process lock) @
 ../../../kern/kern_descrip.c:2104 
 2nd 0xc2b5bd34 filedesc structure (filedesc structure) @
 ../../../kern/kern_descrip.c:2111 
 
 These are indicative of the lock order reversals appearing recently. Do you
 always get these?
 
 Regards
  
 Peter
 
 This e-mail and any attachment(s) is intended for the party to which it is
 addressed and may contain confidential information or be subject to
 professional privilege.  Its transmission in not intended to place the
 contents into the public domain.  If you have received this e-mail in error,
 please notify us immediately and delete the email and all copies.
 AWTA Ltd does not warrant that this e-mail is virus or error free.  By
 opening this e-mail and any attachment the user assumes all responsibility
 for any loss or damage resulting from such action, whether or not caused by
 the negligence of AWTA Ltd.
 The contents of this e-mail and any attachments are subject to copyright and
 may not be reproduced, adapted or transmitted without the prior written
 permission of the copyright owner.

Yes, I always get these.


To Unsubscribe: send mail to [EMAIL PROTECTED]
with unsubscribe freebsd-current in the body of the message

RE: Server locking hard -- A LOT!!!

[Muhannad Asfour]

On Wed, 2003-02-05 at 20:03, Peter Kostouros wrote:
 Not sure this is much help, but I have been getting many hard locks too,
 from about a kernel I built around the 27th January. My symptoms are that
 under a relatively heavy CPU load, upon invoking or terminating an
 application, the machine occasionally terminates (abruptly). I do not even
 get core dumps.
 
 -Original Message-
 From: Muhannad Asfour [mailto:[EMAIL PROTECTED]]
 Sent: Thursday, 6 February 2003 11:27 AM
 To: Peter Kostouros
 Cc: [EMAIL PROTECTED]; [EMAIL PROTECTED]
 Subject: Re: Server locking hard -- A LOT!!!
 
 
 On Wed, 2003-02-05 at 19:23, Peter Kostouros wrote:
  Hi Muhannad
  
  Your dmesg output had the following:
  lock order reversal 1st 0xc2b5d230 process lock (process lock) @
  ../../../kern/kern_descrip.c:2104 
  2nd 0xc2b5bd34 filedesc structure (filedesc structure) @
  ../../../kern/kern_descrip.c:2111 
  
  These are indicative of the lock order reversals appearing recently. Do
 you
  always get these?
  
  Regards
   
  Peter
  
  This e-mail and any attachment(s) is intended for the party to which it is
  addressed and may contain confidential information or be subject to
  professional privilege.  Its transmission in not intended to place the
  contents into the public domain.  If you have received this e-mail in
 error,
  please notify us immediately and delete the email and all copies.
  AWTA Ltd does not warrant that this e-mail is virus or error free.  By
  opening this e-mail and any attachment the user assumes all responsibility
  for any loss or damage resulting from such action, whether or not caused
 by
  the negligence of AWTA Ltd.
  The contents of this e-mail and any attachments are subject to copyright
 and
  may not be reproduced, adapted or transmitted without the prior written
  permission of the copyright owner.
 
 Yes, I always get these.
I am experiencing the same exact thing.  Odd.  Any idea if it still
occurs with a more recently built kernel?


To Unsubscribe: send mail to [EMAIL PROTECTED]
with unsubscribe freebsd-current in the body of the message

RE: Server locking hard -- A LOT!!!

[Muhannad Asfour]

On Wed, 2003-02-05 at 21:03, Peter Kostouros wrote:
 Hi
 
 I experienced the problem with kernels from last weekend. I rebuilt
 yesterday, but have not undergone high loads since. I will do thorough tests
 over the weekend.
 
 Keep in mind there have been some complaints recently, and there is new
 scheduler code just implemented, so I guess at that at the moment CURRENT is
 a place for the brave, well, braver than most.
 
 -Original Message-
 From: Muhannad Asfour [mailto:[EMAIL PROTECTED]]
 Sent: Thursday, 6 February 2003 12:40 PM
 To: Peter Kostouros
 Cc: [EMAIL PROTECTED]; [EMAIL PROTECTED]
 Subject: RE: Server locking hard -- A LOT!!!
 
 
 On Wed, 2003-02-05 at 20:03, Peter Kostouros wrote:
  Not sure this is much help, but I have been getting many hard locks too,
  from about a kernel I built around the 27th January. My symptoms are that
  under a relatively heavy CPU load, upon invoking or terminating an
  application, the machine occasionally terminates (abruptly). I do not even
  get core dumps.
  
  -Original Message-
  From: Muhannad Asfour [mailto:[EMAIL PROTECTED]]
  Sent: Thursday, 6 February 2003 11:27 AM
  To: Peter Kostouros
  Cc: [EMAIL PROTECTED]; [EMAIL PROTECTED]
  Subject: Re: Server locking hard -- A LOT!!!
  
  
  On Wed, 2003-02-05 at 19:23, Peter Kostouros wrote:
   Hi Muhannad
   
   Your dmesg output had the following:
   lock order reversal 1st 0xc2b5d230 process lock (process lock) @
   ../../../kern/kern_descrip.c:2104 
   2nd 0xc2b5bd34 filedesc structure (filedesc structure) @
   ../../../kern/kern_descrip.c:2111 
   
   These are indicative of the lock order reversals appearing recently. Do
  you
   always get these?
   
   Regards

   Peter
   
   This e-mail and any attachment(s) is intended for the party to which it
 is
   addressed and may contain confidential information or be subject to
   professional privilege.  Its transmission in not intended to place the
   contents into the public domain.  If you have received this e-mail in
  error,
   please notify us immediately and delete the email and all copies.
   AWTA Ltd does not warrant that this e-mail is virus or error free.  By
   opening this e-mail and any attachment the user assumes all
 responsibility
   for any loss or damage resulting from such action, whether or not caused
  by
   the negligence of AWTA Ltd.
   The contents of this e-mail and any attachments are subject to copyright
  and
   may not be reproduced, adapted or transmitted without the prior written
   permission of the copyright owner.
  
  Yes, I always get these.
 I am experiencing the same exact thing.  Odd.  Any idea if it still
 occurs with a more recently built kernel?

Ahh, OK.  I will keep this in mind.  But any other suggestions are welcome.

Thanks


To Unsubscribe: send mail to [EMAIL PROTECTED]
with unsubscribe freebsd-current in the body of the message

Re: Server locking hard -- A LOT!!!

[Joel M. Baldwin]

Check your RAM.http://www.memtest86.com/

Check your BIOS settings.  Try running the system with the
failsafe settings if your BIOS has that.

If all else fails put the debug options into the kernel,
add a serial console, and see if you can break into ddb.

--On Tuesday, February 04, 2003 10:24 PM -0500 Muhannad Asfour 
[EMAIL PROTECTED] wrote:

Hello.  I've recently faced a rather odd issue that I've never seen
before.  I bought a new server (specs below), and I loaded it up with
FreeBSD 5.0-RELEASE (I know, I know, not for a production environment,
but this is a personal server).  Now, whenever I get about 30
simultaneous connections, the box just locks hard.  I tested all the
hardware components (CPU, Memory, HD, NIC, etc.) and even bought new
ones just to make sure and all end up with the same result.  I can
never keep a decent uptime (never went past 2 days so far).  As soon
as I get a mediocre http load (30 simul. connections), the box just
locks hard.  I built a debug kernel, I tried everything imaginable,
and I have not found a solution whatsoever.  Everyone seems to be
stumped by this.  I tried FreeBSD 4.7-RELEASE, 4.7-STABLE,
5.0-RELEASE and 5.0-CURRENT on this box.  All give me the same
result.  I checked everywhere for relevant logs to explain what is
occuring, but had no such luck.  This is truly the million dollar
question for me right now, because I have no idea why it would lock
under such a petty load.  I'm not sure what to do to fix this issue,
I've tried many different areas for support and haven't come up with
anything as I stated earlier.  I'm not overclocking or anything if
that's what you're wondering.  If anyone could assist me in any way
shape or form to get this working, I would appreciate it very very
much.  Also, if you e-mail back, I'm not subscribed to the lists, so
could you please CC it to me.  In the past 4 hours, it has locked
hard about 3 times because of a 28-34 connection load.

Machine Specs:
Single Pentium IV 2.4 GHz processor
ASUS P4S533 motherboard
512MB DDR333 RAM (will be 1GB next week)
120GB Maxtor 7200rpm (ATA133) HDD
40GB Maxtor 7200 rpm (ATA66) HDD
Floppy Disk Drive
ATI Rage 128 (32 meg) AGP 4x graphics adapter
52x LG CD-ROM drive
3Com 3C905C-TX NIC
Currently running FreeBSD 5.0-CURRENT as of Sunday Feb. 2, 13:02:05
EST 2003.

Thank you very much



To Unsubscribe: send mail to [EMAIL PROTECTED]
with unsubscribe freebsd-current in the body of the message






To Unsubscribe: send mail to [EMAIL PROTECTED]
with unsubscribe freebsd-current in the body of the message

Re: Wrong date for DEVFS entries

[phk]

In message [EMAIL PROTECTED], Andrey A. Chernov writes:
On Wed, Feb 05, 2003 at 23:44:08 +0100, [EMAIL PROTECTED] wrote:
 
 2) Feb  6 01:36 (boot time)
 3) Feb  6 04:36 (+3 TZ future jump)
 
 These timestamps have been touched, and the clock has made a 3 hour
 jump either forward or backward at some point.
 
 
 The problem is the clock jump, not DEVFS.

Clock jump happens as it supposed when adjkerntz(8) corrects machine clock
back to GMT via various CPU_* sysctl's. Could touched DEVFS stamps be
fixed back to something useful in the same sysctl code too?

No.

-- 
Poul-Henning Kamp   | UNIX since Zilog Zeus 3.20
[EMAIL PROTECTED] | TCP/IP since RFC 956
FreeBSD committer   | BSD since 4.3-tahoe
Never attribute to malice what can adequately be explained by incompetence.

To Unsubscribe: send mail to [EMAIL PROTECTED]
with unsubscribe freebsd-current in the body of the message

Re: tmpfile breakage on setuid executables

[Brad Knowles]

At 4:23 PM -0800 2003/02/05, Terry Lambert wrote:


 I would never have thought of looking for zebras, since it worked on
 my 5.0 system, with all my test programs.


	This has been a very interesting conversation to watch.  Can I 
assume that there will be some more regression tests set up that will 
test compiling all code with full warnings and the optimizer?

	Also, can someone explain to me what the heck a zebra is, in 
this context?

--
Brad Knowles, [EMAIL PROTECTED]

They that can give up essential liberty to obtain a little temporary
safety deserve neither liberty nor safety.
-Benjamin Franklin, Historical Review of Pennsylvania.

GCS/IT d+(-) s:+(++): a C++(+++)$ UMBSHI$ P+++ L+ !E-(---) W+++(--) N+
!w--- O- M++ V PS++(+++) PE- Y+(++) PGP+++ t+(+++) 5++(+++) X++(+++) R+(+++)
tv+(+++) b+() DI+() D+(++) G+() e++ h--- r---(+++)* z(+++)

To Unsubscribe: send mail to [EMAIL PROTECTED]
with unsubscribe freebsd-current in the body of the message