date:20031130

On Sun, 2003-11-30 at 02:00, Will Andrews wrote:
 On Sun, Nov 30, 2003 at 01:49:14AM -0500, Joe Marcus Clarke wrote:
  I have a host controller with the same chipset.  I was having frequent
  data corruption problems, so I asked about it on current@ a few days
  ago.  so@ offered a patch (which has now been comitted), but it didn't
  help.  Bottom line, he said to get a Promise SATA card.  Since I don't
  want to mess around with this anymore, I went to Amazon, and ordered
  one.  In looking at this output, I doubt the patch would even affect you
  since you're using the new hardware revision.
  
  For more details, check the archives for current@ for a thread with the
  subject, Recent ATA drivers giving problems with SATA.
 
 Yeah, that's what I figured.  When I looked at the change, the
 fix only appears to affect rev 0x00, but my SiI3112A is 0x02.  :(
 
 Well, I can tell you that people aren't gonna be happy when their
 brand new motherboard that comes with SiI SATA builtin doesn't
 work with their SATA disks (or well, just this one?).  Since
 SiI's are so cheap (and fairly common), I'd consider this a
 showstopper as far as SATA goes.

I agree.  I really needed to be up and running ASAP, so I opted for the
new controller.  Søren, if you're listening, and need an SiI controller
for testing, you're free to have mine.  Else, I can keep it and test it
as needed (I can put a test drive on it).

 
 This thing used to work, it should be fixed.  Besides, I simply
 don't have the money to spend on another SATA controller for my
 main workstation just so it can run up-to-date -CURRENT.  :(

I have a basic time line.  Everything worked fine until I upgraded on
November 18 at 02:23 UTC.  I had a 160 GB Seagate SATA drive running on
the same chipset for about a month before that.  As soon as I rebooted
on the new kernel, everything went south.  Until Søren told me about the
buggy chipset, I was going to back my ATA drivers back to November 11,
2003 00:00 UTC, and see if that helped.  That was right before a big
change went into the driver.

Joe

 
 Regards,
-- 
PGP Key : http://www.marcuscom.com/pgp.asc


signature.asc
Description: This is a digitally signed message part

Re: Western Digital WD360GD SATA disk on -CURRENT

On Sun, 2003-11-30 at 02:07, Derek Ragona wrote:
 I have a server that uses the same chipset with a maxtor drive, no RAID 
 just a single drive.  My hardware exact hardware is:
 Adaptec SATA 1210SA (SiI 3112 SATA150 controller in non RAID mode with a 
 single drive) and a Maxtor 6Y120M0 120 GB drive
 
 It is probed correctly with the ISO mini 5.2 beta, but it was still having 
 data problems with larger IO in multiuser.  The error I get is:
 
 ad4: timeout sending command=ca
 ad4: error issuing DMA command

This is exactly what I was seeing.

 
 I will try the 11/29 snapshot and see if that is any better.

Didn't help me (in fact, the drive failed sooner with the patch).  You
might try reverting the ATA drivers back to November 11, 2003 00:00 UTC,
and see if that helps.

Joe

 
  -Derek
 
 
 At 10:56 PM 11/29/2003, Will Andrews wrote:
 Hi,
 
 Ever since I found the set of commits which broke probing this
 disk on/about September 1, I have attempted to boot a JPSNAP
 about once a week.  Up to this day, on which I tried 5.2-BETA
 (official ISO), it has never again probed this drive correctly.
 
 I'm using it with a:
 
 [EMAIL PROTECTED]:6:0:   class=0x018000 card=0x31121095 chip=0x31121095 
 rev=0x02 hdr=0x00
  vendor   = 'Silicon Image Inc (Was: CMD Technology Inc)'
  device   = 'SiI 3112 SATARaid Controller'
  class= mass storage
 
 (note, no RAID has been configured, only one disk is attached)
 
 Has anyone had better luck?  Thanks.
 
 Regards,
 --
 wca
 ___
 [EMAIL PROTECTED] mailing list
 http://lists.freebsd.org/mailman/listinfo/freebsd-current
 To unsubscribe, send any mail to [EMAIL PROTECTED]
 ___
 [EMAIL PROTECTED] mailing list
 http://lists.freebsd.org/mailman/listinfo/freebsd-current
 To unsubscribe, send any mail to [EMAIL PROTECTED]
-- 
PGP Key : http://www.marcuscom.com/pgp.asc


signature.asc
Description: This is a digitally signed message part

Re: Western Digital WD360GD SATA disk on -CURRENT

2003-11-30 Thread Will Andrews

On Sun, Nov 30, 2003 at 02:11:59AM -0500, Will Andrews wrote:
 Well, you're not using the same card or drive that I am, but
 thanks for your feedback.  I am fully aware that there are many
 people who have (semi-)working SATA configs in recent -CURRENT.  :)

I should say, mine is completely broken.

The SATA controller probes.  The disk does not probe at all.
Between September 1 and ~October 15 (can't remember exactly), it
used to probe, but incorrectly.

Regards,
-- 
wca
___
[EMAIL PROTECTED] mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-current
To unsubscribe, send any mail to [EMAIL PROTECTED]

Re: 5.2-BETA and related ports issues

On Sun, Nov 30, 2003 at 03:41:33AM +0100, Oliver Eikemeier wrote:
 Kris Kennaway wrote:
 
 On Sat, Nov 29, 2003 at 03:33:35PM +0100, Dag-Erling Smorgrav wrote:
 
 Andreas Klemm [EMAIL PROTECTED] writes:
 
 I can't recommend doing it this way, since some ports I know
 are writing startup scripts to /etc/rc.d :-/
 
 That is very, very bad.  I wish we had some kind of ports QA team :(
 
 Well, er, a number of us do essentially nothing BUT ports QA.
 
 I'm sorry if I did something disturbing, and I'm surely interested in
 ports tree QA! I know that I violate the prefix, and did that on purpose,
 see my comment in net/opendldap2[012]-server/Makefile:
  # currently the only way to participate in rcorder(8)
 
 I posted PR conf/56736:
 http://www.freebsd.org/cgi/query-pr.cgi?pr=conf/56736
 but nobody seemed to care, and I had enough construction areas that I didn't
 wanted to start a discussion about that.
 
 The point is that we might want to have some port services to start early.
 That gives the possibility to move functionality from the base system to 
 ports, which I believe isn't bad. I can simply change the openldap ports so 
 that they
 are nice and quiet, but IMHO that does not really solve a problem. But 
 please
 correct me if my arguments are too simple-minded.

What about simply putting a number in front of the script,
I didn't check but am really certain that we start scripts
something like this:

cd $LOCALBASE/etc/rc.d
for i in *.sh   --- here you get an alphabetically
sort order !
do
if [ -x $i ]; then
/bin/sh $i start
fi
done

So this would be sufficient to start slapd before slurpd:

/usr/local/etc/rc.d/001.slapd.sh
/usr/local/etc/rc.d/002.slurpd.sh

or alternatively

/usr/local/etc/rc.d/openldap-01-slapd.sh
/usr/local/etc/rc.d/openldap-02-slurpd.sh

We already have things like:

000.mysql-client.sh
000.pkgtools.sh
000.wine.sh
010.pgsql.sh


Andreas ///

-- 
Andreas Klemm - Powered by FreeBSD 5.1-CURRENT
Need a magic printfilter today ? - http://www.apsfilter.org/
___
[EMAIL PROTECTED] mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-current
To unsubscribe, send any mail to [EMAIL PROTECTED]

Re: Western Digital WD360GD SATA disk on -CURRENT

2003-11-30 Thread Soren Schmidt

It seems Will Andrews wrote:
 Yeah, that's what I figured.  When I looked at the change, the
 fix only appears to affect rev 0x00, but my SiI3112A is 0x02.  :(

The errata should be fixed in rev 2 silicon.

 Well, I can tell you that people aren't gonna be happy when their
 brand new motherboard that comes with SiI SATA builtin doesn't
 work with their SATA disks (or well, just this one?).  Since
 SiI's are so cheap (and fairly common), I'd consider this a
 showstopper as far as SATA goes.
 
 This thing used to work, it should be fixed.  Besides, I simply
 don't have the money to spend on another SATA controller for my
 main workstation just so it can run up-to-date -CURRENT.  :(

I have two Sii3112 here (old and new) and both work dandy in all the
possible configs I can imagine (and have HW for). So unless someone
with problematic HW does some legwork to find out what fails, there
isn't much I can do actually..

-Søren
___
[EMAIL PROTECTED] mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-current
To unsubscribe, send any mail to [EMAIL PROTECTED]

Re: Western Digital WD360GD SATA disk on -CURRENT

2003-11-30 Thread Soren Schmidt

It seems Joe Marcus Clarke wrote:
 I agree.  I really needed to be up and running ASAP, so I opted for the
 new controller.  Søren, if you're listening, and need an SiI controller
 for testing, you're free to have mine.  Else, I can keep it and test it
 as needed (I can put a test drive on it).

I have both the old one with the errata and the new one without so
thanks for the offer but it might be betterused somewhere else.

 I have a basic time line.  Everything worked fine until I upgraded on
 November 18 at 02:23 UTC.  I had a 160 GB Seagate SATA drive running on
 the same chipset for about a month before that.  As soon as I rebooted
 on the new kernel, everything went south.  Until Søren told me about the
 buggy chipset, I was going to back my ATA drivers back to November 11,
 2003 00:00 UTC, and see if that helped.  That was right before a big
 change went into the driver.

I dont recall doing any major changes in that timeline, what exact
large changes are you talking about ??

-Søren
___
[EMAIL PROTECTED] mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-current
To unsubscribe, send any mail to [EMAIL PROTECTED]

Re: panic on 5.2 BETA: blockable sleep lock

On Fri, 2003-11-28 at 01:02, Don Lewis wrote:
 On 27 Nov, Stefan Ehmann wrote:
  On Wed, 2003-11-26 at 08:33, Don Lewis wrote:
  The problem is that selrecord() wants to lock a MTX_DEF mutex, which can
  cause a context switch if the mutex is already locked by another thread.
  This is contrary to what bktr_poll() wants to accomplish by calling
  critical_enter().
  
  Strange enough that does not seem to happen with a kernel built without
  INVARIANTS and WITNESS. Does this make any sense or is this just by
  chance?
 
 You might try the patch below with WITNESS enabled.  I don't have the
 hardware, so I can't test it.  It compiles for me, but for all I know it
 could delete all your files if you run it.

Any chance for getting this committed?

___
[EMAIL PROTECTED] mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-current
To unsubscribe, send any mail to [EMAIL PROTECTED]

amd64/SMP(/ata-raid ?) not happy...

2003-11-30 Thread Poul-Henning Kamp


Timecounters tick every 10.000 msec
GEOM: create disk ad0 dp=0xff00eebfaca0
ad0: 35772MB IBM-DPTA-353750 [72680/16/63] at ata0-master UDMA66
GEOM: create disk ad4 dp=0xff00eebfa4a0
ad4: 35304MB WDC WD360GD-00FNA0 [71730/16/63] at ata2-master UDMA133
GEOM: create disk ad6 dp=0xff00eebfa0a0
ad6: 35304MB WDC WD360GD-00FNA0 [71730/16/63] at ata3-master UDMA133
GEOM: create disk ad8 dp=0xff00014c4ea0
ad8: 35304MB WDC WD360GD-00FNA0 [71730/16/63] at ata4-master UDMA133
GEOM: create disk ar0 dp=0xff00f04a3270
ar0: 105913MB ATA RAID0 array [13502/255/63] status: READY subdisks:
 disk0 READY on ad4 at ata2-master
 disk1 READY on ad6 at ata3-master
 disk2 READY on ad8 at ata4-master
SMP: AP CPU #1 Launched!
panic: mtx_lock() of spin mutex (null) @ ../../../vm/uma_core.c:1716
cpuid = 1; 
Stack backtrace:
backtrace() at backtrace+0x17
panic() at panic+0x1d2
_mtx_lock_flags() at _mtx_lock_flags+0x4f
uma_zfree_arg() at uma_zfree_arg+0x7e
g_destroy_bio() at g_destroy_bio+0x1b
g_disk_done() at g_disk_done+0x85
biodone() at biodone+0x66
ad_done() at ad_done+0x31
ata_completed() at ata_completed+0x237
taskqueue_run() at taskqueue_run+0x88
taskqueue_swi_run() at taskqueue_swi_run+0x10
ithread_loop() at ithread_loop+0x189
fork_exit() at fork_exit+0xbd
fork_trampoline() at fork_trampoline+0xe
--- trap 0, rip = 0, rsp = 0xad5b0d30, rbp = 0 ---
Debugger(panic)
Stopped at  Debugger+0x4c:  xchgl   %ebx,0x2caefe
db 

-- 
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.
___
[EMAIL PROTECTED] mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-current
To unsubscribe, send any mail to [EMAIL PROTECTED]

Re: amd64/SMP(/ata-raid ?) not happy...

2003-11-30 Thread Jeff Roberson

On Sun, 30 Nov 2003, Poul-Henning Kamp wrote:


 Timecounters tick every 10.000 msec
 GEOM: create disk ad0 dp=0xff00eebfaca0
 ad0: 35772MB IBM-DPTA-353750 [72680/16/63] at ata0-master UDMA66
 GEOM: create disk ad4 dp=0xff00eebfa4a0
 ad4: 35304MB WDC WD360GD-00FNA0 [71730/16/63] at ata2-master UDMA133
 GEOM: create disk ad6 dp=0xff00eebfa0a0
 ad6: 35304MB WDC WD360GD-00FNA0 [71730/16/63] at ata3-master UDMA133
 GEOM: create disk ad8 dp=0xff00014c4ea0
 ad8: 35304MB WDC WD360GD-00FNA0 [71730/16/63] at ata4-master UDMA133
 GEOM: create disk ar0 dp=0xff00f04a3270
 ar0: 105913MB ATA RAID0 array [13502/255/63] status: READY subdisks:
  disk0 READY on ad4 at ata2-master
  disk1 READY on ad6 at ata3-master
  disk2 READY on ad8 at ata4-master
 SMP: AP CPU #1 Launched!
 panic: mtx_lock() of spin mutex (null) @ ../../../vm/uma_core.c:1716

I mailed re about this.  There has been some disagreement over how
mp_maxid is implemented on all architectures.  Until this gets resolved
and stamped as approved by re, please as mp_maxid++; at line 187 of
amd64/amd64/mp_machdep.c

Thanks,
Jeff


 cpuid = 1;
 Stack backtrace:
 backtrace() at backtrace+0x17
 panic() at panic+0x1d2
 _mtx_lock_flags() at _mtx_lock_flags+0x4f
 uma_zfree_arg() at uma_zfree_arg+0x7e
 g_destroy_bio() at g_destroy_bio+0x1b
 g_disk_done() at g_disk_done+0x85
 biodone() at biodone+0x66
 ad_done() at ad_done+0x31
 ata_completed() at ata_completed+0x237
 taskqueue_run() at taskqueue_run+0x88
 taskqueue_swi_run() at taskqueue_swi_run+0x10
 ithread_loop() at ithread_loop+0x189
 fork_exit() at fork_exit+0xbd
 fork_trampoline() at fork_trampoline+0xe
 --- trap 0, rip = 0, rsp = 0xad5b0d30, rbp = 0 ---
 Debugger(panic)
 Stopped at  Debugger+0x4c:  xchgl   %ebx,0x2caefe
 db

 --
 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.
 ___
 [EMAIL PROTECTED] mailing list
 http://lists.freebsd.org/mailman/listinfo/freebsd-current
 To unsubscribe, send any mail to [EMAIL PROTECTED]


___
[EMAIL PROTECTED] mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-current
To unsubscribe, send any mail to [EMAIL PROTECTED]

5.2-BETA panic: page fault

This happens to me several times a day (cvsup from yesterday didn't
change anything). The panic message is always the same, the backtrace is
different though (but always seems to be file system related in some
way)

Here's one from today:

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: page fault
panic messages:
---
Fatal trap 12: page fault while in kernel mode
fault virtual address   = 0x0
fault code  = supervisor read, page not present
instruction pointer = 0x8:0xc0505b53
stack pointer   = 0x10:0xd7f2ea88
frame pointer   = 0x10:0xd7f2eaa4
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 = 1253 (esd)
trap number = 12
panic: page fault

syncing disks, buffers remaining... 

Fatal trap 12: page fault while in kernel mode
fault virtual address   = 0x0
fault code  = supervisor read, page not present
instruction pointer = 0x8:0xc0505b53
stack pointer   = 0x10:0xd7f2e89c
frame pointer   = 0x10:0xd7f2e8b8
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 = 1253 (esd)
trap number = 12
panic: page fault
Uptime: 1h19m23s
Dumping 383 MB
 16 32 48 64 80 96 112 128 144 160 176 192 208 224 240 256 272 288 304
320 336 352 368
---
Reading symbols from /boot/kernel/snd_pcm.ko...done.
Loaded symbols for /boot/kernel/snd_pcm.ko
Reading symbols from /boot/kernel/snd_csa.ko...done.
Loaded symbols for /boot/kernel/snd_csa.ko
Reading symbols from /boot/kernel/bktr_mem.ko...done.
Loaded symbols for /boot/kernel/bktr_mem.ko
Reading symbols from
/usr/obj/usr/src/sys/SHOE/modules/usr/src/sys/modules/linprocfs/linprocfs.ko.debug...done.
Loaded symbols for
/usr/obj/usr/src/sys/SHOE/modules/usr/src/sys/modules/linprocfs/linprocfs.ko.debug
Reading symbols from
/usr/obj/usr/src/sys/SHOE/modules/usr/src/sys/modules/linux/linux.ko.debug...done.
Loaded symbols for
/usr/obj/usr/src/sys/SHOE/modules/usr/src/sys/modules/linux/linux.ko.debug
Reading symbols from
/usr/obj/usr/src/sys/SHOE/modules/usr/src/sys/modules/ext2fs/ext2fs.ko.debug...done.
Loaded symbols for
/usr/obj/usr/src/sys/SHOE/modules/usr/src/sys/modules/ext2fs/ext2fs.ko.debug
Reading symbols from
/usr/obj/usr/src/sys/SHOE/modules/usr/src/sys/modules/ntfs/ntfs.ko.debug...done.
Loaded symbols for
/usr/obj/usr/src/sys/SHOE/modules/usr/src/sys/modules/ntfs/ntfs.ko.debug
Reading symbols from /boot/kernel/bktr.ko...done.
Loaded symbols for /boot/kernel/bktr.ko
#0  doadump () at /usr/src/sys/kern/kern_shutdown.c:240
240 dumping++;
(kgdb) bt
#0  doadump () at /usr/src/sys/kern/kern_shutdown.c:240
#1  0xc050f5a2 in boot (howto=260) at
/usr/src/sys/kern/kern_shutdown.c:372
#2  0xc050f8f8 in panic () at /usr/src/sys/kern/kern_shutdown.c:550
#3  0xc068248c in trap_fatal (frame=0xd7f2e85c, eva=0)
at /usr/src/sys/i386/i386/trap.c:821
#4  0xc0682152 in trap_pfault (frame=0xd7f2e85c, usermode=0, eva=0)
at /usr/src/sys/i386/i386/trap.c:735
#5  0xc0681d63 in trap (frame=
  {tf_fs = -1066729448, tf_es = 16, tf_ds = -1066205168, tf_edi =
-104931, tf_esi = 228, tf_ebp = -671946568, tf_isp = -671946616,
tf_ebx = 0, tf_edx = 16842753, tf_ecx = -1011687424, tf_eax =
-1011660928, tf_trapno = 12, tf_err = 0, tf_eip = -1068475565, tf_cs =
8, tf_eflags = 66178, tf_esp = -671946560, tf_ss = -1068475264}) at
/usr/src/sys/i386/i386/trap.c:420
#6  0xc06743d8 in calltrap () at {standard input}:94
#7  0xc0502b54 in lockmgr (lkp=0xc3b2e028, flags=0, interlkp=0xe4, 
td=0xc06bfc1d) at /usr/src/sys/kern/kern_lock.c:228
#8  0xc0566d87 in vfs_busy (mp=0x0, flags=16, interlkp=0xc075d0e0,
td=0x0)
at /usr/src/sys/kern/vfs_subr.c:527
#9  0xc056cfff in sync (td=0xc0730dc0, uap=0x0)
at /usr/src/sys/kern/vfs_syscalls.c:132
#10 0xc050f0f6 in boot (howto=256) at
/usr/src/sys/kern/kern_shutdown.c:281
#11 0xc050f8f8 in panic () at /usr/src/sys/kern/kern_shutdown.c:550
#12 0xc068248c in trap_fatal (frame=0xd7f2ea48, eva=0)
at /usr/src/sys/i386/i386/trap.c:821
#13 0xc0682152 in trap_pfault (frame=0xd7f2ea48, usermode=0, eva=0)
at /usr/src/sys/i386/i386/trap.c:735
#14 0xc0681d63 in trap (frame=
  {tf_fs = -672006120, tf_es = -672006128, tf_ds = -1068105712,
tf_edi = -104931, tf_esi = 228, tf_ebp = -671946076, tf_isp =
-671946124, tf_ebx = 0, tf_edx = 16777217, tf_ecx = -1011687424, tf_eax
= -1011660928, tf_trapno = 12, tf_err = 0, tf_eip

Re: panic on 5.2 BETA: blockable sleep lock

On 30 Nov, Stefan Ehmann wrote:
 On Fri, 2003-11-28 at 01:02, Don Lewis wrote:
 On 27 Nov, Stefan Ehmann wrote:
  On Wed, 2003-11-26 at 08:33, Don Lewis wrote:
  The problem is that selrecord() wants to lock a MTX_DEF mutex, which can
  cause a context switch if the mutex is already locked by another thread.
  This is contrary to what bktr_poll() wants to accomplish by calling
  critical_enter().
  
  Strange enough that does not seem to happen with a kernel built without
  INVARIANTS and WITNESS. Does this make any sense or is this just by
  chance?
 
 You might try the patch below with WITNESS enabled.  I don't have the
 hardware, so I can't test it.  It compiles for me, but for all I know it
 could delete all your files if you run it.
 
 Any chance for getting this committed?

I've been forwarding these messages to the bktr maintainer listed in
/usr/src/MAINTAINERS, in case he isn't subscribed to [EMAIL PROTECTED]  I'm not
suprised that I haven't heard from him because this issue came up at the
start of the Thanksgiving holiday weekend.  Commiting the patch will
also require re approval because of the code freeze in preparation for
5.2-RELEASE.

___
[EMAIL PROTECTED] mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-current
To unsubscribe, send any mail to [EMAIL PROTECTED]

Re: Need to trim the disc1 packages

2003-11-30 Thread Doug Barton

On Sat, 29 Nov 2003, Scott Long wrote:

 All,

 We are badly overflowing the disc1 release ISO with packages, and need
 to trim it down.  One package that could easily get axed is the
 linux-netscape-communicator package.

I concur with that. For those of us who use linux netscape for whatever
reason (like me), the linux installer for netscape 7, available on
netscape's site, works just fine.

Doug

-- 

This .signature sanitized for your protection

___
[EMAIL PROTECTED] mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-current
To unsubscribe, send any mail to [EMAIL PROTECTED]

Re: 5.2-BETA and related ports issues

2003-11-30 Thread Oliver Eikemeier

Andreas Klemm wrote:

On Sun, Nov 30, 2003 at 03:41:33AM +0100, Oliver Eikemeier wrote:

Kris Kennaway wrote:


On Sat, Nov 29, 2003 at 03:33:35PM +0100, Dag-Erling Smorgrav wrote:


Andreas Klemm [EMAIL PROTECTED] writes:


I can't recommend doing it this way, since some ports I know
are writing startup scripts to /etc/rc.d :-/
That is very, very bad.  I wish we had some kind of ports QA team :(
Well, er, a number of us do essentially nothing BUT ports QA.
I'm sorry if I did something disturbing, and I'm surely interested in
ports tree QA! I know that I violate the prefix, and did that on purpose,
see my comment in net/opendldap2[012]-server/Makefile:
# currently the only way to participate in rcorder(8)
I posted PR conf/56736:
http://www.freebsd.org/cgi/query-pr.cgi?pr=conf/56736
but nobody seemed to care, and I had enough construction areas that I didn't
wanted to start a discussion about that.
The point is that we might want to have some port services to start early.
That gives the possibility to move functionality from the base system to 
ports, which I believe isn't bad. I can simply change the openldap ports so 
that they
are nice and quiet, but IMHO that does not really solve a problem. But 
please
correct me if my arguments are too simple-minded.
What about simply putting a number in front of the script,
I didn't check but am really certain that we start scripts
something like this:
cd $LOCALBASE/etc/rc.d
for i in *.sh   --- here you get an alphabetically
sort order !
do
if [ -x $i ]; then
/bin/sh $i start
fi
done

So this would be sufficient to start slapd before slurpd:
/usr/local/etc/rc.d/001.slapd.sh
/usr/local/etc/rc.d/002.slurpd.sh
or alternatively

/usr/local/etc/rc.d/openldap-01-slapd.sh
/usr/local/etc/rc.d/openldap-02-slurpd.sh
We already have things like:

000.mysql-client.sh
000.pkgtools.sh
000.wine.sh
010.pgsql.sh
I don't care whether slapd or slurpd starts first, I even don't care when slurpd
starts. I want to start ldapd early in the boot process to supports services like
nss_ldap and mail. I did things differently e.g. in net/rsync, because rsync does
not provide any services that base services depend on.
-Oliver

___
[EMAIL PROTECTED] mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-current
To unsubscribe, send any mail to [EMAIL PROTECTED]

Re: 5.2-BETA and related ports issues

On Sun, Nov 30, 2003 at 12:43:06PM +0100, Oliver Eikemeier wrote:
 I don't care whether slapd or slurpd starts first, I even don't care when 
 slurpd
 starts. I want to start ldapd early in the boot process to supports 
 services like
 nss_ldap and mail. I did things differently e.g. in net/rsync, because 
 rsync does
 not provide any services that base services depend on.

Ah understand .. then the situation is like with DHCP in FreeBSD.

So ot seems to me, that the needed part of ldap has to go into
src/contrib ?!


Andreas ///

-- 
Andreas Klemm - Powered by FreeBSD 5.1-CURRENT
Need a magic printfilter today ? - http://www.apsfilter.org/
___
[EMAIL PROTECTED] mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-current
To unsubscribe, send any mail to [EMAIL PROTECTED]

Re: 5.2-BETA and related ports issues

I have a better idea, then we perhaps need something like a 
wrapper script that is part of the FreeBSD basic system under /etc/rc.d
that checks for the start script under $LOCALBASE/etc/rc.d
and starts it very early.

Andreas ///

-- 
Andreas Klemm - Powered by FreeBSD 5.1-CURRENT
Need a magic printfilter today ? - http://www.apsfilter.org/
___
[EMAIL PROTECTED] mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-current
To unsubscribe, send any mail to [EMAIL PROTECTED]

Re: 5.2-BETA panic: page fault

On Sun, 2003-11-30 at 11:13, Stefan Ehmann wrote:
 This happens to me several times a day (cvsup from yesterday didn't
 change anything). The panic message is always the same, the backtrace is
 different though (but always seems to be file system related in some
 way)
 
 Here's one from today:

As per request I made a (hopefully more useful) backtrace with a patched
gdb version:

(kgdb) bt
#0  doadump () at /usr/src/sys/kern/kern_shutdown.c:240
#1  0xc050f5a2 in boot (howto=260) at
/usr/src/sys/kern/kern_shutdown.c:372
#2  0xc050f8f8 in panic () at /usr/src/sys/kern/kern_shutdown.c:550
#3  0xc068248c in trap_fatal (frame=0xd7f2e85c, eva=0)
at /usr/src/sys/i386/i386/trap.c:821
#4  0xc0682152 in trap_pfault (frame=0xd7f2e85c, usermode=0, eva=0)
at /usr/src/sys/i386/i386/trap.c:735
#5  0xc0681d63 in trap (frame=
  {tf_fs = -1066729448, tf_es = 16, tf_ds = -1066205168, tf_edi =
-104931, tf_esi = 228, tf_ebp = -671946568, tf_isp = -671946616,
tf_ebx = 0, tf_edx = 16842753, tf_ecx = -1011687424, tf_eax =
-1011660928, tf_trapno = 12, tf_err = 0, tf_eip = -1068475565, tf_cs =
8, tf_eflags = 66178, tf_esp = -671946560, tf_ss = -1068475264}) at
/usr/src/sys/i386/i386/trap.c:420
#6  0xc06743d8 in calltrap () at {standard input}:94
#7  0xc0505b53 in _mtx_lock_flags (m=0x0, opts=0, 
file=0xc06bfc1d /usr/src/sys/kern/kern_lock.c, line=228)
at /usr/src/sys/kern/kern_mutex.c:214
#8  0xc0502b54 in lockmgr (lkp=0xc3b2e028, flags=0, interlkp=0xe4, 
td=0xc06bfc1d) at /usr/src/sys/kern/kern_lock.c:228
#9  0xc0566d87 in vfs_busy (mp=0x0, flags=16, interlkp=0xc075d0e0,
td=0x0)
at /usr/src/sys/kern/vfs_subr.c:527
#10 0xc056cfff in sync (td=0xc0730dc0, uap=0x0)
at /usr/src/sys/kern/vfs_syscalls.c:132
#11 0xc050f0f6 in boot (howto=256) at
/usr/src/sys/kern/kern_shutdown.c:281
#12 0xc050f8f8 in panic () at /usr/src/sys/kern/kern_shutdown.c:550
#13 0xc068248c in trap_fatal (frame=0xd7f2ea48, eva=0)
at /usr/src/sys/i386/i386/trap.c:821
#14 0xc0682152 in trap_pfault (frame=0xd7f2ea48, usermode=0, eva=0)
at /usr/src/sys/i386/i386/trap.c:735
#15 0xc0681d63 in trap (frame=
  {tf_fs = -672006120, tf_es = -672006128, tf_ds = -1068105712,
tf_edi = -104931, tf_esi = 228, tf_ebp = -671946076, tf_isp =
-671946124, tf_ebx = 0, tf_edx = 16777217, tf_ecx = -1011687424, tf_eax
= -1011660928, tf_trapno = 12, tf_err = 0, tf_eip = -1068475565, tf_cs =
8, tf_eflags = 66178, tf_esp = 2, tf_ss = -1011660928}) at
/usr/src/sys/i386/i386/trap.c:420
#16 0xc06743d8 in calltrap () at {standard input}:94
#17 0xc0505b53 in _mtx_lock_flags (m=0x0, opts=0, 
file=0xc06bfc1d /usr/src/sys/kern/kern_lock.c, line=228)
at /usr/src/sys/kern/kern_mutex.c:214
#18 0xc0502b54 in lockmgr (lkp=0xc3b2e028, flags=0, interlkp=0xe4, 
td=0xc06bfc1d) at /usr/src/sys/kern/kern_lock.c:228
#19 0xc0566d87 in vfs_busy (mp=0x0, flags=0, interlkp=0x0, td=0x0)
at /usr/src/sys/kern/vfs_subr.c:527
#20 0xc056374c in lookup (ndp=0xd7f2ec00) at
/usr/src/sys/kern/vfs_lookup.c:559
#21 0xc0562fde in namei (ndp=0xd7f2ec00) at
/usr/src/sys/kern/vfs_lookup.c:183
#22 0xc05726ef in kern_mkdir (td=0xc3b34780, path=)
at /usr/src/sys/kern/vfs_syscalls.c:3230
#23 0xc0572699 in mkdir (td=0x0, uap=0x0)
at /usr/src/sys/kern/vfs_syscalls.c:3214
#24 0xc06827c0 in syscall (frame=
  {tf_fs = 47, tf_es = 47, tf_ds = 47, tf_edi = 134546513, tf_esi =
-1077941929, tf_ebp = -1077944248, tf_isp = -671945356, tf_ebx = 0,
tf_edx = 134543200, tf_ecx = 134578233, tf_eax = 136, tf_trapno = 12,
tf_err = 2, tf_eip = 672183855, tf_cs = 31, tf_eflags = 582, tf_esp =
-1077944500, tf_ss = 47})
at /usr/src/sys/i386/i386/trap.c:1010
#25 0xc067442d in Xint0x80_syscall () at {standard input}:136
#26 0x2810b62f in ?? ()
(kgdb) 

___
[EMAIL PROTECTED] mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-current
To unsubscribe, send any mail to [EMAIL PROTECTED]

[current tinderbox] failure on ia64/ia64

2003-11-30 Thread Tinderbox

TB --- 2003-11-30 10:50:47 - tinderbox 2.2 running on cueball.rtp.FreeBSD.org
TB --- 2003-11-30 10:50:47 - starting CURRENT tinderbox run for ia64/ia64
TB --- 2003-11-30 10:50:47 - checking out the source tree
TB --- cd /home/des/tinderbox/CURRENT/ia64/ia64
TB --- /usr/bin/cvs -f -R -q -d/home/ncvs update -Pd -A src
TB --- 2003-11-30 10:53:36 - building world
TB --- cd /home/des/tinderbox/CURRENT/ia64/ia64/src
TB --- /usr/bin/make -B buildworld
 Rebuilding the temporary build tree
 stage 1.1: legacy release compatibility shims
 stage 1.2: bootstrap tools
 stage 2.1: cleaning up the object tree
 stage 2.2: rebuilding the object tree
 stage 2.3: build tools
 stage 3: cross tools
 stage 4.1: building includes
 stage 4.2: building libraries
 stage 4.3: make dependencies
 stage 4.4: building everything..
TB --- 2003-11-30 11:58:35 - building generic kernel
TB --- cd /home/des/tinderbox/CURRENT/ia64/ia64/src
TB --- /usr/bin/make buildkernel KERNCONF=GENERIC
 Kernel build for GENERIC started on Sun Nov 30 11:58:35 GMT 2003
[...]
/vol/vol0/users/des/tinderbox/CURRENT/ia64/ia64/src/sys/vm/uma_core.c: In function 
`cache_drain':
/vol/vol0/users/des/tinderbox/CURRENT/ia64/ia64/src/sys/vm/uma_core.c:572: error: 
`mp_maxid' undeclared (first use in this function)
/vol/vol0/users/des/tinderbox/CURRENT/ia64/ia64/src/sys/vm/uma_core.c: In function 
`uma_startup':
/vol/vol0/users/des/tinderbox/CURRENT/ia64/ia64/src/sys/vm/uma_core.c:1223: error: 
`mp_maxid' undeclared (first use in this function)
/vol/vol0/users/des/tinderbox/CURRENT/ia64/ia64/src/sys/vm/uma_core.c: In function 
`uma_print_zone':
/vol/vol0/users/des/tinderbox/CURRENT/ia64/ia64/src/sys/vm/uma_core.c:2100: error: 
`mp_maxid' undeclared (first use in this function)
/vol/vol0/users/des/tinderbox/CURRENT/ia64/ia64/src/sys/vm/uma_core.c: In function 
`sysctl_vm_zone':
/vol/vol0/users/des/tinderbox/CURRENT/ia64/ia64/src/sys/vm/uma_core.c:2148: error: 
`mp_maxid' undeclared (first use in this function)
*** Error code 1

Stop in 
/vol/vol0/users/des/tinderbox/CURRENT/ia64/ia64/obj/ia64/vol/vol0/users/des/tinderbox/CURRENT/ia64/ia64/src/sys/GENERIC.
*** Error code 1

Stop in /vol/vol0/users/des/tinderbox/CURRENT/ia64/ia64/src.
*** Error code 1

Stop in /vol/vol0/users/des/tinderbox/CURRENT/ia64/ia64/src.
TB --- 2003-11-30 12:06:24 - TB --- /usr/bin/make returned exit code  1 
TB --- 2003-11-30 12:06:24 - TB --- ERROR: failed to build generic kernel
TB --- 2003-11-30 12:06:24 - tinderbox aborted

___
[EMAIL PROTECTED] mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-current
To unsubscribe, send any mail to [EMAIL PROTECTED]

SiI3112 SATA controller problems - status

2003-11-30 Thread HaggeL

Hi Guys :)

Sorry if i waste your time. I´m a freeBSD noob and need some help.
I want to install freeBSD in januar and have some problems. I want to
buy me a new harddrive, a serial ATA one, because i got the Silicon
ImageR Sil 3112A-Controller onboard (Asus A7N8X Motherboard). I
didn´t find a driver in the Hardware Notes of FreeBSD 5.1, and on the
Producer homepage are only ready Linuxkernels avaible
(http://12.24.47.40/display/2n/searchDirect/?searchString=Sil+3112AsearchType=allwordssearchby=keywordsr=0.8157617).
So can anyone tell me if i can get a SATA disk run? I don´t want to
boot from it, just read and write. Buying a new disk only for windows
use is wasted money

Greetings HaggeL :)


___
[EMAIL PROTECTED] mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-current
To unsubscribe, send any mail to [EMAIL PROTECTED]

user:sys time ratio

2003-11-30 Thread Colin Percival

  I've got a system running 5.2-BETA from 27/11/03, with the malloc_abort, 
malloc_junk, DEBUG=-g, DDB, INVARIANT*, and WITNESS* debugging options 
changed (as was done in 5.1-RELEASE).
  When running `make buildworld`, I see large amounts of sys time; eg, 27 
minutes user  14 minutes sys for building 5.2, or 14 minutes user  10 
minutes sys for building 4.9.  I expected the ratio of user:sys to be much 
larger than this, and mailing list traffic indicates that a 4:1 ratio is 
typical.  (FWIW, prior to changing the debugging options, the user:sys time 
ratio was around 1:1.)
  Can anyone suggest why the kernel seems to be behaving so sluggishly?

  The system hardware is P4 2.8Ghz, 865G, 2GB DDR, IDE drives; there is 
very little disk activity, so I'm sure that isn't the issue; and disabling 
HTT results in about a 2% improvement in both user and sys times.

Colin Percival

___
[EMAIL PROTECTED] mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-current
To unsubscribe, send any mail to [EMAIL PROTECTED]

Re: user:sys time ratio

2003-11-30 Thread Poul-Henning Kamp

In message [EMAIL PROTECTED], Colin Percival
 writes:
   I've got a system running 5.2-BETA from 27/11/03, with the malloc_abort, 
malloc_junk, DEBUG=-g, DDB, INVARIANT*, and WITNESS* debugging options 
changed (as was done in 5.1-RELEASE).
   When running `make buildworld`, I see large amounts of sys time; eg, 27 
minutes user  14 minutes sys for building 5.2, or 14 minutes user  10 
minutes sys for building 4.9.  I expected the ratio of user:sys to be much 
larger than this, and mailing list traffic indicates that a 4:1 ratio is 
typical.  (FWIW, prior to changing the debugging options, the user:sys time 
ratio was around 1:1.)

I've seen UNIX systems have typical system/user splits from 1/9 to 9/1
it all depends on what you're doing.



-- 
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.
___
[EMAIL PROTECTED] mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-current
To unsubscribe, send any mail to [EMAIL PROTECTED]

Re: user:sys time ratio

2003-11-30 Thread Colin Percival

At 15:30 30/11/2003 +0100, Poul-Henning Kamp wrote:
In message [EMAIL PROTECTED], Colin 
Percival
 writes:
   When running `make buildworld`, I see large amounts of sys time; eg, 27
minutes user  14 minutes sys for building 5.2, or 14 minutes user  10
minutes sys for building 4.9.  I expected the ratio of user:sys to be much
larger than this, and mailing list traffic indicates that a 4:1 ratio is
typical.
I've seen UNIX systems have typical system/user splits from 1/9 to 9/1
it all depends on what you're doing.
  Sure, but buildworld is a fairly well-defined benchmark; I wouldn't 
expect to see such a large difference when running exactly the same code on 
different systems.

Colin Percival

___
[EMAIL PROTECTED] mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-current
To unsubscribe, send any mail to [EMAIL PROTECTED]

Re: user:sys time ratio

2003-11-30 Thread Poul-Henning Kamp

In message [EMAIL PROTECTED], Colin Percival
 writes:
At 15:30 30/11/2003 +0100, Poul-Henning Kamp wrote:
In message [EMAIL PROTECTED], Colin 
Percival
  writes:
When running `make buildworld`, I see large amounts of sys time; eg, 27
 minutes user  14 minutes sys for building 5.2, or 14 minutes user  10
 minutes sys for building 4.9.  I expected the ratio of user:sys to be much
 larger than this, and mailing list traffic indicates that a 4:1 ratio is
 typical.
 I've seen UNIX systems have typical system/user splits from 1/9 to 9/1
it all depends on what you're doing.

   Sure, but buildworld is a fairly well-defined benchmark; I wouldn't 
expect to see such a large difference when running exactly the same code on 
different systems.

The amount of system time depends on a lot of environmental factors.

For instance on my amd64/SMP, the vnode pool is mis-sized, so the the
namecache does not reflect what is actually already in RAM.  The result
is a fair bit of system time wasted instantiating vnodes from cached
inode diskblocks.

-- 
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.
___
[EMAIL PROTECTED] mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-current
To unsubscribe, send any mail to [EMAIL PROTECTED]

Re: Ports startup scripts in /etc/rc.d (Re: 5.2-BETA and related ports issues)

Oliver Eikemeier wrote:

The reason I did this was to support services like mail and nss_ldap. I 
really like to be
prefix safe, PR conf/56736 relates to this:
http://www.freebsd.org/cgi/query-pr.cgi?pr=conf/56736

I agree that there should be a better solution, and already asked Mike 
Makonnen
[EMAIL PROTECTED] about it, but nobody seemed to care.

IMHO not participating in rcorder(8) makes the packing list pettier and 
avoids an ugly hack,
which is good, but restrains functionality. I like the idea of account 
managed in an
centralized LDAP directory very much.

So, do you still think the scripts should not participate in rcorder(8)? 
It's easy to
change the ports, but this is probably not the right fix.

-Oliver
I guess I don't see the problem.  What is wrong with ports adding 
startup scripts to /etc/rc.d?  For certain ports, that is the only way 
to get the startup dependencies right (like making sure openldap or 
postgresql starts before your mail system).  This will become more 
important as more of the base system moves to ports/packages.

Just refine the note in UPDATING to specifically state which startup 
scripts to remove, rather than rm -rf /etc/rc.d/*.

Richard Coleman
[EMAIL PROTECTED]
___
[EMAIL PROTECTED] mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-current
To unsubscribe, send any mail to [EMAIL PROTECTED]

Re: 5.2-BETA and related ports issues

Andreas Klemm wrote:

What about simply putting a number in front of the script,
I didn't check but am really certain that we start scripts
something like this:
cd $LOCALBASE/etc/rc.d
for i in *.sh   --- here you get an alphabetically
sort order !
do
if [ -x $i ]; then
/bin/sh $i start
fi
done

So this would be sufficient to start slapd before slurpd:
/usr/local/etc/rc.d/001.slapd.sh
/usr/local/etc/rc.d/002.slurpd.sh
or alternatively

/usr/local/etc/rc.d/openldap-01-slapd.sh
/usr/local/etc/rc.d/openldap-02-slurpd.sh
We already have things like:

000.mysql-client.sh
000.pkgtools.sh
000.wine.sh
010.pgsql.sh
	Andreas ///
That works fine if you are only concerned about startup ordering for 
things in /usr/local/etc/rc.d.  Although it would be better if we could 
use rcorder style dependency ordering here as well.

But it doesn't help if you need a port to start earlier than something 
in the base.  This could happen if you've replaced sendmail with 
postfix, and use maps from a remote database (openldap, postgresql, 
etc).  I'm sure there are other examples as well (nss_ldap, etc).

Richard Coleman
[EMAIL PROTECTED]
___
[EMAIL PROTECTED] mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-current
To unsubscribe, send any mail to [EMAIL PROTECTED]

Re: Xircom pccard couldn't load/attach (with uname -a info)

2003-11-30 Thread Ronald Klop

Hello,

Here is the output. And the dmesg is attached.
NEWCARD/OLDCARD??? I think NEWCARD.
Nov 30 16:51:11 laptop kernel: xe0: Xircom CreditCard Ethernet 10/100 
+ Modem 56 at port 0x2e8-0x2ef irq 11 function 0 config 39 on pccard0
Nov 30 16:51:12 laptop kernel: xe0: vendor = 0x0105
Nov 30 16:51:12 laptop kernel: xe0: product = 0x110a
Nov 30 16:51:12 laptop kernel: xe0: prodext = 0x46
Nov 30 16:51:12 laptop kernel: xe0: vendor_str = Xircom
Nov 30 16:51:12 laptop kernel: xe0: product_str = CreditCard Ethernet 
10/100 + Modem 56
Nov 30 16:51:12 laptop kernel: xe0: cis3_str = CEM56
Nov 30 16:51:12 laptop kernel: xe0: cis4_str = 1.00
Nov 30 16:51:12 laptop kernel: xe0: Cannot allocate ioport
Nov 30 16:51:12 laptop kernel: device_probe_and_attach: xe0 attach 
returned 12

Greetings,

Ronald.

PS: Please reply to ronald_at_cs_dot_vu_dot_nl to prevent spam.

On Sat, 29 Nov 2003 17:56:11 +, Scott Mitchell 
[EMAIL PROTECTED] wrote:

On Sat, Nov 29, 2003 at 02:20:24PM +0100, Ronald Klop wrote:
On Sat, 29 Nov 2003 14:17:01 +0100, Ronald Klop
[EMAIL PROTECTED] wrote:
Hello,

This card doesn't attach well. Other Xircom cards do.

Nov 29 13:47:24 laptop kernel: xe0: Xircom CreditCard Ethernet 10/100
+ Modem 56 at port 0x2e8-0x2ef irq 11 function 0 config 39 on pccard0
Nov 29 13:47:24 laptop kernel: device_probe_and_attach: xe0 attach
returned 12

Mail me if more info is needed.
uname -a
FreeBSD laptop 5.2-BETA FreeBSD 5.2-BETA #0: Sun Nov 23 22:09:51 CET
2003 [EMAIL PROTECTED]:/usr/obj/usr/src/sys/LAPTOP  i386
Hi Ronald,

Could you try setting sysctl hw.xe.debug=1 and post the output?  Also, 
are
you using OLDCARD or NEWCARD?  A full dmesg might be useful too...
I suspect there's a problem with the driver not knowing all the card IDs
that Xircom ever used, as well as probing some cards differently when run
under NEWCARD vs. OLDCARD.

Cheers,

	Scott



--
Using M2, Opera's revolutionary e-mail client: http://www.opera.com/m2/

dmesg.boot
Description: Binary data
___
[EMAIL PROTECTED] mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-current
To unsubscribe, send any mail to [EMAIL PROTECTED]

Re: user:sys time ratio


On Sun, 30 Nov 2003, Colin Percival wrote:

I've got a system running 5.2-BETA from 27/11/03, with the
 malloc_abort, malloc_junk, DEBUG=-g, DDB, INVARIANT*, and WITNESS*
 debugging options changed (as was done in 5.1-RELEASE). 
When running `make buildworld`, I see large amounts of sys time; eg,
 27 minutes user  14 minutes sys for building 5.2, or 14 minutes user 
 10 minutes sys for building 4.9.  I expected the ratio of user:sys to be
 much larger than this, and mailing list traffic indicates that a 4:1
 ratio is typical.  (FWIW, prior to changing the debugging options, the
 user:sys time ratio was around 1:1.) 
Can anyone suggest why the kernel seems to be behaving so sluggishly? 
 
The system hardware is P4 2.8Ghz, 865G, 2GB DDR, IDE drives; there is
 very little disk activity, so I'm sure that isn't the issue; and
 disabling HTT results in about a 2% improvement in both user and sys
 times. 

It sounds like you have multiple logical cores -- have you tried building
a kernel without SMP support to see what happens?

Robert N M Watson FreeBSD Core Team, TrustedBSD Projects
[EMAIL PROTECTED]  Senior Research Scientist, McAfee Research


___
[EMAIL PROTECTED] mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-current
To unsubscribe, send any mail to [EMAIL PROTECTED]

Re: MAJOR number

2003-11-30 Thread Frank Mayhar

Piggybacking on that request...

I also need a major number.  I had requested one some time ago, but it
apparently got lost in the shuffle.  The device is a Specialix I/O8+
multiport serial card.  I've been using it for some weeks now without
problems.  For now the driver is -stable only; I'll port it to 5.x when
I can test it there.

When I have a major number, I'll submit the driver for official inclusion
in -stable.
-- 
Frank Mayhar [EMAIL PROTECTED]  http://www.exit.com/
Exit Consulting http://www.gpsclock.com/
http://www.exit.com/blog/frank/
___
[EMAIL PROTECTED] mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-current
To unsubscribe, send any mail to [EMAIL PROTECTED]

Re: 5.2-BETA and related ports issues


On Sun, 30 Nov 2003, Andreas Klemm wrote:

 I have a better idea, then we perhaps need something like a wrapper
 script that is part of the FreeBSD basic system under /etc/rc.d that
 checks for the start script under $LOCALBASE/etc/rc.d and starts it very
 early. 

Hmm.  I talked with Gordon about this issue some last night, but he
pointed out a snag: most installs of FreeBSD place /usr on a separate
partition from /.  The rcNG ordering decision is made before /usr is
mounted, as /usr is mounted as part of the pieces kicked off by rc.d.  So
it would be a fairly large departure from the current implementation of
the rcNG code to reevaluate the ordering once more directories were
available in which to find scripts to run.  Not that it's not doable, but
we need to think about it carefully (and, unfortunately, it's not as easy
as simply adding /usr/local/etc/rc.d to the list..)  Having wrapper
scripts in /etc/rc.d can work, but it means we don't get the full benefits
of ordering, and that any ordering information has to be in the wrapper,
not in the bit installed by the port in /usr/local...

Robert N M Watson FreeBSD Core Team, TrustedBSD Projects
[EMAIL PROTECTED]  Senior Research Scientist, McAfee Research

___
[EMAIL PROTECTED] mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-current
To unsubscribe, send any mail to [EMAIL PROTECTED]

Re: Ports startup scripts in /etc/rc.d (Re: 5.2-BETA and related ports issues)

On Sun, Nov 30, 2003 at 10:45:40AM -0500, Richard Coleman wrote:
 Oliver Eikemeier wrote:
 
 The reason I did this was to support services like mail and nss_ldap. I 
 really like to be
 prefix safe, PR conf/56736 relates to this:
 http://www.freebsd.org/cgi/query-pr.cgi?pr=conf/56736
 
 I agree that there should be a better solution, and already asked Mike 
 Makonnen
 [EMAIL PROTECTED] about it, but nobody seemed to care.
 
 IMHO not participating in rcorder(8) makes the packing list pettier and 
 avoids an ugly hack,
 which is good, but restrains functionality. I like the idea of account 
 managed in an
 centralized LDAP directory very much.
 
 So, do you still think the scripts should not participate in rcorder(8)? 
 It's easy to
 change the ports, but this is probably not the right fix.
 
 -Oliver
 
 I guess I don't see the problem.  What is wrong with ports adding 
 startup scripts to /etc/rc.d?  For certain ports, that is the only way 
 to get the startup dependencies right (like making sure openldap or 
 postgresql starts before your mail system).  This will become more 
 important as more of the base system moves to ports/packages.
 
 Just refine the note in UPDATING to specifically state which startup 
 scripts to remove, rather than rm -rf /etc/rc.d/*.

As I wrote im my previous mail we could import wrapper scripts
for such basic services, since there are only few services
that are so generic, that they have to be available so early
in boot order.

I strongly would dislike creating ports to install stuff under
/etc/whatever.

This would start to violate things for what I liked FreeBSD for
all these many years and I hope/think other have the same feeling
concerning this.

Andreas ///

-- 
Andreas Klemm - Powered by FreeBSD 5.1-CURRENT
Need a magic printfilter today ? - http://www.apsfilter.org/
___
[EMAIL PROTECTED] mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-current
To unsubscribe, send any mail to [EMAIL PROTECTED]

Re: 5.2-BETA and related ports issues

On Sun, Nov 30, 2003 at 11:31:34AM -0500, Robert Watson wrote:
 
 On Sun, 30 Nov 2003, Andreas Klemm wrote:
 
  I have a better idea, then we perhaps need something like a wrapper
  script that is part of the FreeBSD basic system under /etc/rc.d that
  checks for the start script under $LOCALBASE/etc/rc.d and starts it very
  early. 
 
 Hmm.  I talked with Gordon about this issue some last night, but he
 pointed out a snag: most installs of FreeBSD place /usr on a separate
 partition from /.  The rcNG ordering decision is made before /usr is
 mounted, as /usr is mounted as part of the pieces kicked off by rc.d.  So
 it would be a fairly large departure from the current implementation of
 the rcNG code to reevaluate the ordering once more directories were
 available in which to find scripts to run.  Not that it's not doable, but
 we need to think about it carefully (and, unfortunately, it's not as easy
 as simply adding /usr/local/etc/rc.d to the list..)  Having wrapper
 scripts in /etc/rc.d can work, but it means we don't get the full benefits
 of ordering, and that any ordering information has to be in the wrapper,
 not in the bit installed by the port in /usr/local...

Sh** I should have read your mail earlier, b4 writing a f'up ...

Its completely true. On FreeBSD servers I have / and /usr always on a
separate partition.

Only Solaris I install differently, to have / and /usr on one partition,
since Solaris has only less if not soon _none_ statically linked programs
for system maintenance/recovery (if being stuck in single user).

But well ... I think I could suggest a good workaround for this.

What about having these wrapper scripts in /etc/rc.d calling another
(kind of) subscript, with the only goal to get /usr/local mounted ?

Andreas ///

-- 
Andreas Klemm - Powered by FreeBSD 5.1-CURRENT
Need a magic printfilter today ? - http://www.apsfilter.org/
___
[EMAIL PROTECTED] mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-current
To unsubscribe, send any mail to [EMAIL PROTECTED]

Re: 5.2-BETA and related ports issues

2003-11-30 Thread Melvyn Sopacua

On Sunday 30 November 2003 16:54, Richard Coleman wrote:

 But it doesn't help if you need a port to start earlier than something
 in the base.  This could happen if you've replaced sendmail with
 postfix, and use maps from a remote database (openldap, postgresql,
 etc).  I'm sure there are other examples as well (nss_ldap, etc).

Then you can just as easily nuke the entire mailer.conf principle and symlink 
bin/postfix to etc/rc.d/050.postfix.sh.
Point being: these are customized setups that require skill to get even 
remotely working, so one can assume that the person installing the port can 
read instructions given in pkg-message.

I don't think any ports/package system is capable of correctly setting all 
*runtime* dependencies especially when it allows it's users to change 
configurations after installation without recording the changes back into the 
ports/pkg system.

However - to allow this flexibility, the ports system should try to respect 
the installation prefix.
Nothing prevents a port from entering If you need ${PORTNAME} to start before 
foo, symlink ${PREFIX}/etc/rc.d/${PORTNAME}.sh to /etc/rc.d/ and make sure 
it's lexically sorted before foo into pkg-message.

Then the statement in UPDATING can read:
find /etc/rc.d \! -type l -print | xargs rm -vf

and it will always apply.

Perhaps the patch below (or something similar) should be added as well to make 
people aware of the local_startup system.

My 2c.
-- 
Melvyn

--- bsd.port.mk.origSun Nov 30 17:22:22 2003
+++ bsd.port.mk Sun Nov 30 17:29:21 2003
@@ -766,6 +766,9 @@
 #apply here.  It is recommended that you use
 #%%PREFIX%% for ${PREFIX}, %%LOCALBASE%% for
 #${LOCALBASE} and %%X11BASE%% for ${X11BASE}.
+# INSTALLS_RCSCRIPT - If set, bsd.port.mk will check if ${LOCALBASE} is equal
+#to ${PREFIX} or else suggest that ${PREFIX}/etc/rc.d 
should
+#be added to local_startup in /etc/rc.conf
 # DOCSDIR  - Name of the directory to install the packages docs in
 #(default: ${PREFIX}/share/doc/${PORTNAME}).
 # EXAMPLESDIR  - Name of the directory to install the packages examples in
@@ -3127,6 +3130,10 @@
@${MKHTMLINDEX} ${PREFIX}/lib/X11/doc/html
 .endif
 .endif
+.endif
+.if defined(INSTALLS_RCSCRIPT)  ${LOCALBASE} != ${PREFIX}
+   @${ECHO_MSG} You should verify if ${PREFIX}/etc/rc.d is in local_startup
+   @${ECHO_MSG} in /etc/rc.conf or /etc/defaults/rc.conf
 .endif
 .endif
 


pgp0.pgp
Description: signature

MALLOC_OPTIONS behaviour

2003-11-30 Thread rihad

Under 5.2-BETA, if I run a program with env MALLOC_OPTIONS=j then all 
the malloc()'ed memory will be zeroed even though I did not ask for it 
(by specifying Z). Also, J (memset to 0xd0) even appears to run a 
somewhat *faster* than j. Why doesn't jz return uninitialized memory 
and isn't the fastest of {jz,J,Z} (where J is the fastest)? I'm new to 
FreeBSD so I don't know if previously this worked as documented in 
malloc(3).

TIA

___
[EMAIL PROTECTED] mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-current
To unsubscribe, send any mail to [EMAIL PROTECTED]

Re: 5.2-BETA and related ports issues

2003-11-30 Thread Dag-Erling Smørgrav

Melvyn Sopacua [EMAIL PROTECTED] writes:
 Then you can just as easily nuke the entire mailer.conf principle and symlink 
 bin/postfix to etc/rc.d/050.postfix.sh.

This is actually one of the two recommended ways of starting postfix
(and the one I prefer).  The main reason for mailer.conf to exist is
that a lot of scripts have /usr/sbin/sendmail hardcoded and TPTB
decided that they didn't want to use 'use.perl port'-style symlinks.

DES
-- 
Dag-Erling Smørgrav - [EMAIL PROTECTED]
___
[EMAIL PROTECTED] mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-current
To unsubscribe, send any mail to [EMAIL PROTECTED]

Re: SiI3112 SATA controller problems - status

On Fri, 2004-01-30 at 09:43, HaggeL wrote:
 Hi Guys :)
 
 Sorry if i waste your time. Im a freeBSD noob and need some help.
 I want to install freeBSD in januar and have some problems. I want to
 buy me a new harddrive, a serial ATA one, because i got the Silicon
 ImageR Sil 3112A-Controller onboard (Asus A7N8X Motherboard). I
 didnt find a driver in the Hardware Notes of FreeBSD 5.1, and on the
 Producer homepage are only ready Linuxkernels avaible
 (http://12.24.47.40/display/2n/searchDirect/?searchString=Sil+3112AsearchType=allwordssearchby=keywordsr=0.8157617).
 So can anyone tell me if i can get a SATA disk run? I dont want to
 boot from it, just read and write. Buying a new disk only for windows
 use is wasted money

We're having a pretty lengthy discussion about these controllers on this
list right now.  I suggest you read the archives.  Bottom line, the
controller is supported, but it's problematic.  The ATA maintainer has
working controllers, but there are those of us that experience data
corruption, and at least one user that can't use his drive at all when
connected to said controller.

Joe

 
 Greetings HaggeL :)
 
 
 ___
 [EMAIL PROTECTED] mailing list
 http://lists.freebsd.org/mailman/listinfo/freebsd-current
 To unsubscribe, send any mail to [EMAIL PROTECTED]
-- 
PGP Key : http://www.marcuscom.com/pgp.asc


signature.asc
Description: This is a digitally signed message part

Re: Panic with ugen

2003-11-30 Thread Martin

On Fri, 2003-11-28 at 14:43, Jay Cornwall wrote:

 Could you try the attached patch (rm -f sys/dev/usb/ugen.c, cvs up 
 sys/dev/usb/ugen.c, patch ...) to see if it alleviates the panic? It 
 should at least give a more specific panic, if it doesn't fix the problem.

Sorry for the delay, I got a busy weekend.

I still got a panic after starting the small piece of code, but it looks
like this now:

fatal trap 12
fault virtual address = 0x5
supervisor read, page not present
[...]

trace shows me ugen_set_config() at top of the stack.

Martin


___
[EMAIL PROTECTED] mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-current
To unsubscribe, send any mail to [EMAIL PROTECTED]

kernel compile fails in uma_core.c

2003-11-30 Thread Paulius Bulotas

Hello,

when building kernel:
../../../vm/uma_core.c: In function `zone_timeout':
../../../vm/uma_core.c:345: error: `mp_maxid' undeclared (first use in
this function)
and so on.

Anything I missed?

Paulius
___
[EMAIL PROTECTED] mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-current
To unsubscribe, send any mail to [EMAIL PROTECTED]

Re: kernel compile fails in uma_core.c

2003-11-30 Thread Bjoern A. Zeeb

On Sun, 30 Nov 2003, Paulius Bulotas wrote:

 Hello,

 when building kernel:
 ../../../vm/uma_core.c: In function `zone_timeout':
 ../../../vm/uma_core.c:345: error: `mp_maxid' undeclared (first use in
 this function)
 and so on.

 Anything I missed?

No,

this is the bad commit for UP but should be ok on MP kernels:

http://docs.freebsd.org/cgi/getmsg.cgi?fetch=0+0+current/cvs-src

and it is known:

http://docs.freebsd.org/cgi/getmsg.cgi?fetch=20091+0+current/cvs-src


I don't know if someone of them is working on it but I have been
waiting for half a day now for another build ;-(


-- 
Bjoern A. Zeeb  bzeeb at Zabbadoz dot NeT
56 69 73 69 74  http://www.zabbadoz.net/
___
[EMAIL PROTECTED] mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-current
To unsubscribe, send any mail to [EMAIL PROTECTED]

Re: SiI3112 SATA controller problems - status

On Sun, 30 Nov 2003, Joe Marcus Clarke wrote:

On Fri, 2004-01-30 at 09:43, HaggeL wrote:
Hi Guys :)

We're having a pretty lengthy discussion about these controllers on this
list right now. I suggest you read the archives. Bottom line, the
controller is supported, but it's problematic. The ATA maintainer has
working controllers, but there are those of us that experience data
corruption, and at least one user that can't use his drive at all when
connected to said controller.

I believe a workaround was recently committed to improve behavior on older
cards using that chipset. Specifically the following change to
ata-chipset.c:

revision 1.48
date: 2003/11/28 19:01:28; author: sos; state: Exp; lines: +6 -2
Workaround for errata on early versions of the sii3112.

Approved by: re@

Does this make any difference in your configuration?

Robert N M Watson FreeBSD Core Team, TrustedBSD Projects
[EMAIL PROTECTED] Senior Research Scientist, McAfee Research

___
[EMAIL PROTECTED] mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-current
To unsubscribe, send any mail to [EMAIL PROTECTED]

Re: SiI3112 SATA controller problems - status

On Sun, 2003-11-30 at 14:40, Robert Watson wrote:
On Sun, 30 Nov 2003, Joe Marcus Clarke wrote:

On Fri, 2004-01-30 at 09:43, HaggeL wrote:
Hi Guys :)

I believe a workaround was recently committed to improve behavior on older
cards using that chipset. Specifically the following change to
ata-chipset.c:

revision 1.48
date: 2003/11/28 19:01:28; author: sos; state: Exp; lines: +6 -2
Workaround for errata on early versions of the sii3112.

Approved by: re@

Does this make any difference in your configuration?

Well, it makes my configuration fail more quickly. I have the newer
hardware revision 0x02, so technically I shouldn't need this patch. I
actually modified it so that the SIIBUG flag was applied to my card, but
it resulted in a kernel panic while building world.

Joe

Robert N M Watson FreeBSD Core Team, TrustedBSD Projects
[EMAIL PROTECTED] Senior Research Scientist, McAfee Research

--
PGP Key : http://www.marcuscom.com/pgp.asc

signature.asc
Description: This is a digitally signed message part

Re: user:sys time ratio

2003-11-30 Thread Colin Percival

  Robert Watson suggested that I compare performance from UP and SMP kernels:

# /usr/bin/time -hl sh -c 'make -s buildworld 21'  /dev/null
  Real  UserSys
  UP kernel   38m33.29s 27m10.09s   10m59.15s
 (retest) 38m33.18s 27m04.40s   11m05.73s
  SMP w/o HTT 41m01.54s 27m10.27s   13m29.82s
 (retest) 39m47.50s 27m08.05s   12m12.20s
  SMP w/HTT   42m17.16s 28m12.82s   14m04.93s
 (retest) 44m09.61s 28m15.31s   15m44.86s
  That enabling HTT degrades performance is not surprising, since I'm not 
passing the -j option to make; but a 5% performance delta between UP and 
SMP kernels is rather surprising (to me, at least), and the fact that the 
system time varies so much on the SMP kernel also seems peculiar.
  Is this normal?

Colin Percival

___
[EMAIL PROTECTED] mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-current
To unsubscribe, send any mail to [EMAIL PROTECTED]

Re: SiI3112 SATA controller problems - status

2003-11-30 Thread Scott Long

Robert Watson wrote:
On Sun, 30 Nov 2003, Joe Marcus Clarke wrote:

On Fri, 2004-01-30 at 09:43, HaggeL wrote:

Hi Guys :)

I believe a workaround was recently committed to improve behavior on older
cards using that chipset. Specifically the following change to
ata-chipset.c:

revision 1.48
date: 2003/11/28 19:01:28; author: sos; state: Exp; lines: +6 -2
Workaround for errata on early versions of the sii3112.

Approved by: re@

Does this make any difference in your configuration?

Robert N M Watson FreeBSD Core Team, TrustedBSD Projects
[EMAIL PROTECTED] Senior Research Scientist, McAfee Research
This commit only fixes a silent data corruption issue. I believe that
the issue at hand involves DMA not working at all.
Scott

___
[EMAIL PROTECTED] mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-current
To unsubscribe, send any mail to [EMAIL PROTECTED]

Atheros Driver getting GOOD!!

2003-11-30 Thread Marcos Biscaysaqu

Hi there,
   a month ago we couldn't made work a Freebsd in hostap with the new 
Atheros card more than 4 min., Now with the looks so much better I have 
got one running with more than 33 client and even in mode 11b work 
faster than any Access Point or wireless card, but I still have some 
problems,  Some  time the ping with the customers go very high I we have 
times like 400 ms for a couple a minutes when the normal time connection 
is no more than 4ms. Im have this problem only whe the Atheros card, if 
I use a simple AP or a Freebsd with a PRISM card it's all happy but no 
to fast as Atheros cards.
please if someone has an idea or need more informarion reply me.

Thanks!

--

Marcos Biscaysaqu

Systems Administrator
ThePacific.Net Ltd.


___
[EMAIL PROTECTED] mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-current
To unsubscribe, send any mail to [EMAIL PROTECTED]

more on non-executable mappings on NetBSD

2003-11-30 Thread Pedro F. Giffuni

Hi;

I know everyone is busy with the upcoming release, but JIC someone is
interested on this, I found this recent progress report post on NetBSD's lists:
__
Subject: more on non-executable mappings
To: None [EMAIL PROTECTED]
From: Chuck Silvers [EMAIL PROTECTED]
List: tech-kern
Date: 11/28/2003 11:57:21 
I'm getting back to looking at the rest of the non-executable mapping work
from openbsd.  (well, really this goes beyond that, to what they're calling
W^X, meaning that any given part of the user address space should not be
both writable and executable.)  the remaining items are:

 (1) update the kernel ELF code to handle more than 2 PT_LOAD sections.

 (2) change the linker to put the PLT, GOT and rodata into their PT_LOAD
 sections so that they can have different permissions than the existing
 text and data load sections.

 (3) change the runtime linker to use mprotect() to enable write access
 to the PLT only when needed, leaving it read-only the rest of the time.

 (4) other MD issues with kernel support for non-executable mappings

 (a) i386 currently only supports non-execute for the part of the
 address space where the traditional unix stack lives.  this doesn't
 do anything for the data or bss sections, or the heap or mmap()d
 files (eg. shared libraries), or pthread stacks.
 the openbsd guys rearranged their user address space layout on i386
 fairly drastically to put all the executable mappings below
 a certain threshold.

 (b) powerpc OEA hardware only supports execute permissions at a
 segment (256MB) granularity.  ideally we would rearrange the
 user address space layout here as well to put all the executable
 mappings down in segment 0 in the usual case.

the first of these should be non-controversial and I have attached
a patch which implements it.  I'll commit it in a week or so if
there are no objections.

as for the other items, I'd like opinions on whether or not we want them,
and if we do, how we might achieve them with the fewest headaches.

-Chuck

The patch is here:
http://mail-index.netbsd.org/tech-kern/2003/11/28/0019.html
___
FWIW, I posted the CVS commit log of the initial work on the -hackers list some
time ago.

cheers,

Pedro.

ps. I attempted to post this on -security but there was some error on my side
of the network.

Download Yahoo! Messenger now for a chance to win Live At Knebworth DVDs
http://www.yahoo.co.uk/robbiewilliams
___
[EMAIL PROTECTED] mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-current
To unsubscribe, send any mail to [EMAIL PROTECTED]

libradius - missing defines

2003-11-30 Thread Michael Bretterklieber

Hi,

could someone please add these defines to radlib.h

#define RAD_ACCT_INPUT_GIGAWORDS 52
#define RAD_ACCT_OUTPUT_GIGAWORDS 53
#define RAD_ACCT_INTERIM_INTERVAL 85

there is also a missing ACCT-Status-Type (RAD_ACCT_STATUS_TYPE)
#define RAD_UPDATE 3

see also RFC 2869,

thanx,
bye,
--
--- --
Michael Bretterklieber  - http://www.bretterklieber.com
A-Quadrat Automation GmbH   - http://www.a-quadrat.at
Tel: ++43-(0)3172-41679 - GSM: ++43-(0)699 12861847
--- --
...the number of UNIX installations has grown to 10, with more
expected... - Dennis Ritchie and Ken Thompson, June 1972
___
[EMAIL PROTECTED] mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-current
To unsubscribe, send any mail to [EMAIL PROTECTED]

Re: Need to trim the disc1 packages

2003-11-30 Thread Julian St.

 - IMO, Don't include netscape, mozilla or opera. KDE includes
 Konqueror and GNOME has Nautilus(1/2). That's enough to get someone up
 and running and let them get to www.freebsd.org to see how to install
 something else.

I do use neither KDE nor GNOME. At least keep one mozilla (or Opera, it
doesn't matter). The Linux binaries could be dropped on disc1, though.
But I just realise that I install over FTP most of the time anyway...

 - I'd say (x)emacs could go as well. However, a lot of people learning
 UNIX use this as their first real (aka powerful) editor (sorry
 PiCo/nEdit just can't compare). I personally like vi/vim/gvim so I
 might be biased.

I think people expect to see (X)Emacs on an install disc of a unix-like
OS.

Regards,
Julian
-- 
Join the Group Mind -- become a Borg.


pgp0.pgp
Description: PGP signature

Re: Atheros Driver getting GOOD!!

2003-11-30 Thread Marcos Biscaysaqu

I have lot of Ierrs and the pings to my clients go very high until I 
restart my ath0 interfaces and start to work all happy again.
Im running the last dirver version from 29/11/03

I fogot my netstat

Atheros# netstat -I ath0
NameMtu Network   Address  Ipkts IerrsOpkts 
Oerrs  Coll
ath0   1500 Link#1  00:09:5b:94:63:e5   619574  8869   875732 
66818 0
illegal prefixlen
ath0   1500 default   fe80:1::209:5bff:0 -3 
- -

Marcos Biscaysaqu wrote:

Hi there,
   a month ago we couldn't made work a Freebsd in hostap with the new 
Atheros card more than 4 min., Now with the looks so much better I 
have got one running with more than 33 client and even in mode 11b 
work faster than any Access Point or wireless card, but I still have 
some problems,  Some  time the ping with the customers go very high I 
we have times like 400 ms for a couple a minutes when the normal time 
connection is no more than 4ms. Im have this problem only whe the 
Atheros card, if I use a simple AP or a Freebsd with a PRISM card it's 
all happy but no to fast as Atheros cards.
please if someone has an idea or need more informarion reply me.

Thanks!

--

Marcos Biscaysaqu

Systems Administrator
ThePacific.Net Ltd.


___
[EMAIL PROTECTED] mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-current
To unsubscribe, send any mail to [EMAIL PROTECTED]

rpcbind not binding correctly with -h

2003-11-30 Thread Nuno Teixeira


Hello to all,

I'm having some problems with NFS on a FreeBSD 5.1 p11

NFS server is a gateway with an adsl alcatel USB modem and has the
following rc.conf:

rpcbind_enable=YES
rpcbind_flags=-h 192.168.0.1
nfs_server_enable=YES
nfs_server_flags=-u -t -n 6 -h 192.168.0.1
mountd_flags=-r

PROBLEM:

The problem is unmounting NFS shares takes too much time on clients. It
usualy gives an error on rebooting or shuting down related to rc that
says that cannot execute rc.shutdown until the end.

I can avoid the problem by doing a `ifconfig rl0 down` on clients before
I reboot or shutdown.

I think I found the origin of this problem because it only happens when
the ADSL connetion is up on gateway:

ADSL down:

rl0: flags=8843UP,BROADCAST,RUNNING,SIMPLEX,MULTICAST mtu 1500
inet 192.168.0.1 netmask 0xff00 broadcast 192.168.0.255
inet6 fe80::250:fcff:fec2:1816%rl0 prefixlen 64 scopeid 0x1 
ether 00:50:fc:c2:18:16
media: Ethernet autoselect (100baseTX full-duplex)
status: active
lo0: flags=8049UP,LOOPBACK,RUNNING,MULTICAST mtu 16384
inet6 ::1 prefixlen 128 
inet6 fe80::1%lo0 prefixlen 64 scopeid 0x2 
inet 127.0.0.1 netmask 0xff00 

NO problems at all. Unmounting, rebooting, etc.

ADSL up:

rl0: flags=8843UP,BROADCAST,RUNNING,SIMPLEX,MULTICAST mtu 1500
inet 192.168.0.1 netmask 0xff00 broadcast 192.168.0.255
inet6 fe80::250:fcff:fec2:1816%rl0 prefixlen 64 scopeid 0x1 
ether 00:50:fc:c2:18:16
media: Ethernet autoselect (100baseTX full-duplex)
status: active
lo0: flags=8049UP,LOOPBACK,RUNNING,MULTICAST mtu 16384
inet6 ::1 prefixlen 128 
inet6 fe80::1%lo0 prefixlen 64 scopeid 0x2 
inet 127.0.0.1 netmask 0xff00 
tap0: flags=8843UP,BROADCAST,RUNNING,SIMPLEX,MULTICAST mtu 1500
inet6 fe80::2bd:daff:fe2d:0%tap0 prefixlen 64 scopeid 0x3 
ether 00:bd:da:2d:00:00
Opened by PID 527
tun0: flags=8051UP,POINTOPOINT,RUNNING,MULTICAST mtu 1492
inet 213.13.234.240 -- 213.13.72.1 netmask 0xff00 
Opened by PID 531

Problem discribed above.

===

Other thing that I noticed is that when I run nmap to ISP assigned ip
adress it shows that rpcbind is open.

111/tcp  open  rpcbind
1023/tcp open  netvenuechat

Can anyone knows what the problem is? Bindind related?

Thanks very much,

Nuno Teixeira

-- 
[EMAIL PROTECTED]
SDF Public Access UNIX System - http://sdf.lonestar.org
___
[EMAIL PROTECTED] mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-current
To unsubscribe, send any mail to [EMAIL PROTECTED]

Re: Ports startup scripts in /etc/rc.d (Re: 5.2-BETA and related ports issues)

Andreas Klemm wrote:

I guess I don't see the problem.  What is wrong with ports adding 
startup scripts to /etc/rc.d?  For certain ports, that is the only way 
to get the startup dependencies right (like making sure openldap or 
postgresql starts before your mail system).  This will become more 
important as more of the base system moves to ports/packages.

Just refine the note in UPDATING to specifically state which startup 
scripts to remove, rather than rm -rf /etc/rc.d/*.


As I wrote im my previous mail we could import wrapper scripts
for such basic services, since there are only few services
that are so generic, that they have to be available so early
in boot order.
I strongly would dislike creating ports to install stuff under
/etc/whatever.
This would start to violate things for what I liked FreeBSD for
all these many years and I hope/think other have the same feeling
concerning this.
	Andreas ///

But that kinda defeats the purpose of RCNG.  One of the best features of 
RCNG is that it makes it easier to add/delete applications from the 
system.  Not using it for this purpose reduces its utility.

Let's not let the typical BSD traditionalism get in the way of using 
RCNG for what it's designed.  Don't get me wrong.  I'm not advocating 
Linux-style integration of packages/ports.  But this seems fairly harmless.

Richard Coleman
[EMAIL PROTECTED]
___
[EMAIL PROTECTED] mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-current
To unsubscribe, send any mail to [EMAIL PROTECTED]

Re: 5.2-BETA and related ports issues

Dag-Erling Smørgrav wrote:

Melvyn Sopacua [EMAIL PROTECTED] writes:

Then you can just as easily nuke the entire mailer.conf principle and symlink 
bin/postfix to etc/rc.d/050.postfix.sh.


This is actually one of the two recommended ways of starting postfix
(and the one I prefer).  The main reason for mailer.conf to exist is
that a lot of scripts have /usr/sbin/sendmail hardcoded and TPTB
decided that they didn't want to use 'use.perl port'-style symlinks.
DES
But all these seem like such hacks.  It would be so much cleaner to move 
sendmail.sh out of the way and just add postfix.sh to /etc/rc.d, rather 
than using tricks with symlinks and rc.conf variables.  If you have a 
small number of ports added, it's not a big deal.  But all these hacks 
get confusing when you have a lot of ports, each doing it's own special 
trick.

The mailer.conf issue (for mail injection) is a separate issue and 
there's really no way around that.

Richard Coleman
[EMAIL PROTECTED]
___
[EMAIL PROTECTED] mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-current
To unsubscribe, send any mail to [EMAIL PROTECTED]

[current tinderbox] failure on i386/pc98

2003-11-30 Thread Tinderbox

TB --- 2003-11-30 21:17:02 - tinderbox 2.2 running on cueball.rtp.FreeBSD.org
TB --- 2003-11-30 21:17:02 - starting CURRENT tinderbox run for i386/pc98
TB --- 2003-11-30 21:17:02 - checking out the source tree
TB --- cd /home/des/tinderbox/CURRENT/i386/pc98
TB --- /usr/bin/cvs -f -R -q -d/home/ncvs update -Pd -A src
TB --- 2003-11-30 21:20:38 - building world
TB --- cd /home/des/tinderbox/CURRENT/i386/pc98/src
TB --- /usr/bin/make -B buildworld
 Rebuilding the temporary build tree
 stage 1.1: legacy release compatibility shims
 stage 1.2: bootstrap tools
 stage 2.1: cleaning up the object tree
 stage 2.2: rebuilding the object tree
 stage 2.3: build tools
 stage 3: cross tools
 stage 4.1: building includes
 stage 4.2: building libraries
 stage 4.3: make dependencies
 stage 4.4: building everything..
TB --- 2003-11-30 22:18:49 - building generic kernel
TB --- cd /home/des/tinderbox/CURRENT/i386/pc98/src
TB --- /usr/bin/make buildkernel KERNCONF=GENERIC
 Kernel build for GENERIC started on Sun Nov 30 22:18:49 GMT 2003
[...]
/vol/vol0/users/des/tinderbox/CURRENT/i386/pc98/src/sys/vm/uma_core.c: In function 
`cache_drain':
/vol/vol0/users/des/tinderbox/CURRENT/i386/pc98/src/sys/vm/uma_core.c:572: error: 
`mp_maxid' undeclared (first use in this function)
/vol/vol0/users/des/tinderbox/CURRENT/i386/pc98/src/sys/vm/uma_core.c: In function 
`uma_startup':
/vol/vol0/users/des/tinderbox/CURRENT/i386/pc98/src/sys/vm/uma_core.c:1223: error: 
`mp_maxid' undeclared (first use in this function)
/vol/vol0/users/des/tinderbox/CURRENT/i386/pc98/src/sys/vm/uma_core.c: In function 
`uma_print_zone':
/vol/vol0/users/des/tinderbox/CURRENT/i386/pc98/src/sys/vm/uma_core.c:2100: error: 
`mp_maxid' undeclared (first use in this function)
/vol/vol0/users/des/tinderbox/CURRENT/i386/pc98/src/sys/vm/uma_core.c: In function 
`sysctl_vm_zone':
/vol/vol0/users/des/tinderbox/CURRENT/i386/pc98/src/sys/vm/uma_core.c:2148: error: 
`mp_maxid' undeclared (first use in this function)
*** Error code 1

Stop in 
/vol/vol0/users/des/tinderbox/CURRENT/i386/pc98/obj/pc98/vol/vol0/users/des/tinderbox/CURRENT/i386/pc98/src/sys/GENERIC.
*** Error code 1

Stop in /vol/vol0/users/des/tinderbox/CURRENT/i386/pc98/src.
*** Error code 1

Stop in /vol/vol0/users/des/tinderbox/CURRENT/i386/pc98/src.
TB --- 2003-11-30 22:24:26 - TB --- /usr/bin/make returned exit code  1 
TB --- 2003-11-30 22:24:26 - TB --- ERROR: failed to build generic kernel
TB --- 2003-11-30 22:24:26 - tinderbox aborted

___
[EMAIL PROTECTED] mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-current
To unsubscribe, send any mail to [EMAIL PROTECTED]

Re: 5.2-BETA panic: page fault

On 30 Nov, Stefan Ehmann wrote:
 On Sun, 2003-11-30 at 11:13, Stefan Ehmann wrote:
 This happens to me several times a day (cvsup from yesterday didn't
 change anything). The panic message is always the same, the backtrace is
 different though (but always seems to be file system related in some
 way)
 
 Here's one from today:
 
 As per request I made a (hopefully more useful) backtrace with a patched
 gdb version:
 
 (kgdb) bt

 #12 0xc050f8f8 in panic () at /usr/src/sys/kern/kern_shutdown.c:550
 #13 0xc068248c in trap_fatal (frame=0xd7f2ea48, eva=0)
 at /usr/src/sys/i386/i386/trap.c:821
 #14 0xc0682152 in trap_pfault (frame=0xd7f2ea48, usermode=0, eva=0)
 at /usr/src/sys/i386/i386/trap.c:735
 #15 0xc0681d63 in trap (frame=
   {tf_fs = -672006120, tf_es = -672006128, tf_ds = -1068105712,
 tf_edi = -104931, tf_esi = 228, tf_ebp = -671946076, tf_isp =
 -671946124, tf_ebx = 0, tf_edx = 16777217, tf_ecx = -1011687424, tf_eax
 = -1011660928, tf_trapno = 12, tf_err = 0, tf_eip = -1068475565, tf_cs =
 8, tf_eflags = 66178, tf_esp = 2, tf_ss = -1011660928}) at
 /usr/src/sys/i386/i386/trap.c:420
 #16 0xc06743d8 in calltrap () at {standard input}:94
 #17 0xc0505b53 in _mtx_lock_flags (m=0x0, opts=0, 
 file=0xc06bfc1d /usr/src/sys/kern/kern_lock.c, line=228)
 at /usr/src/sys/kern/kern_mutex.c:214
 #18 0xc0502b54 in lockmgr (lkp=0xc3b2e028, flags=0, interlkp=0xe4, 
 td=0xc06bfc1d) at /usr/src/sys/kern/kern_lock.c:228
 #19 0xc0566d87 in vfs_busy (mp=0x0, flags=0, interlkp=0x0, td=0x0)
 at /usr/src/sys/kern/vfs_subr.c:527
 #20 0xc056374c in lookup (ndp=0xd7f2ec00) at
 /usr/src/sys/kern/vfs_lookup.c:559

It seems pretty clear that the panic is caused by passing a null pointer
to mtx_lock().  That is pretty clear from the eva=0 argument to
trap_pfault() and the m=0x0 argument to _mtx_lock_flags().  If you have
INVARIANTS defined, the first thing that _mtx_lock_flags() does is to
dereference m-mtx_object, which is at beginning of struct mtx.

There appears to be some stack spammage happening, and it is pretty much
consistent between this stack trace and the previous one displayed by
the unpatched version of gdb.  Notice how all the arguments to
vfs_busy() are NULL/0, but td and interlkp are passed directly to
lockmgr(), which has a non-NULL td and interlkp arguments, though the
interlkp argument looks seriously bogus.  Looking at the lockmgr() call
in vfs_busy(), I don't see how the flags argument to lockmgr() could be
0.  If the mp argument to vfs_busy() were really NULL, vfs_busy() would
have paniced before calling lockmgr().

I wonder if an interrupt handler is stomping on the stack ...
___
[EMAIL PROTECTED] mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-current
To unsubscribe, send any mail to [EMAIL PROTECTED]

psmintr not attached w/ acpi

2003-11-30 Thread Slawa Olhovchenkov

If acpi enabled PS/2 mouse failed to work and irq12 cold't attach
to psmintr.

Is this problem reporting PS/2 mouse resource before atkbdc?

psmcpnp0 irq 12 on acpi0
atkbdc0: Keyboard controller (i8042) port 0x64,0x60 irq 1 on acpi0
atkbd0: AT Keyboard flags 0x1 irq 1 on atkbdc0
atkbd: the current kbd controller command byte 0047
atkbd: keyboard ID 0x41ab (2)
kbd0 at atkbd0
kbd0: atkbd0, AT 101/102 (2), config:0x1, flags:0x3d
psm0: current command byte:0047
psm0: PS/2 Mouse irq 12 on atkbdc0
psm0: model IntelliMouse, device ID 3-00, 3 buttons
psm0: config:, flags:, packet size:4
psm0: syncmask:08, syncbits:08

vmstat -i
interrupt  total   rate
irq0: clk  64245 99
irq1: atkbd0   1  0
irq8: rtc  82235127
irq11: xl0 uhci0+737  1
irq13: npx01  0
irq14: ata0 2411  3
irq15: ata1   52  0
Total 149682232

Device (PS2M)
{
Name (_HID, EisaId (PNP0F13))
Method (_STA, 0, NotSerialized)
{
If (LEqual (PS2F, 0x00))
{
Return (0x0F)
}
Else
{
Return (0x00)
}
}

Method (_CRS, 0, NotSerialized)
{
Name (BUF1, Buffer (0x05)
{
0x22, 0x00, 0x10, 0x79, 0x00
})
Name (BUF2, Buffer (0x15)
{
0x47, 0x01, 0x60, 0x00, 0x60, 0x00, 0x01, 0x01,
0x47, 0x01, 0x64, 0x00, 0x64, 0x00, 0x01, 0x01,
0x22, 0x00, 0x10, 0x79, 0x00
})
If (LEqual (KBDI, 0x01))
{
Return (BUF2)
}
Else
{
Return (BUF1)
}
}
}

Device (PS2K)
{
Name (_HID, EisaId (PNP0303))
Method (_STA, 0, NotSerialized)
{
If (LEqual (KBDI, 0x01))
{
Return (0x00)
}
Else
{
Return (0x0F)
}
}

Name (_CRS, Buffer (0x15)
{
0x47, 0x01, 0x60, 0x00, 0x60, 0x00, 0x01, 0x01,
0x47, 0x01, 0x64, 0x00, 0x64, 0x00, 0x01, 0x01,
0x22, 0x02, 0x00, 0x79, 0x00
})
}


-- 
Slawa Olhovchenkov

___
[EMAIL PROTECTED] mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-current
To unsubscribe, send any mail to [EMAIL PROTECTED]

Re: 5.2-BETA and related ports issues

2003-11-30 Thread Melvyn Sopacua

On Sunday 30 November 2003 23:00, Richard Coleman wrote:

 Dag-Erling Smørgrav wrote:
  Melvyn Sopacua [EMAIL PROTECTED] writes:
 Then you can just as easily nuke the entire mailer.conf principle and
  symlink bin/postfix to etc/rc.d/050.postfix.sh.
 
  This is actually one of the two recommended ways of starting postfix
  (and the one I prefer).  The main reason for mailer.conf to exist is
  that a lot of scripts have /usr/sbin/sendmail hardcoded and TPTB
  decided that they didn't want to use 'use.perl port'-style symlinks.
 
  DES

 But all these seem like such hacks.  It would be so much cleaner to move
 sendmail.sh out of the way and just add postfix.sh to /etc/rc.d, rather
 than using tricks with symlinks and rc.conf variables.

Symlinks have the added advantage that you can easily see what you've done 
using ls(1) - unlike /usr/sbin/sendmail being a shell script. In this 
specific case, postfix already supports the 'start' and 'stop' arguments, so 
there's no need for a wrapper script translating arguments.

 If you have a 
 small number of ports added, it's not a big deal.  But all these hacks
 get confusing when you have a lot of ports, each doing it's own special
 trick.

Isn't that *exactly why* ports should respect $PREFIX? At least than you know 
that startup scripts are in one place. Maybe all that is needed is a variable 
RCDIR?= etc/rc.d, for people who want to 'deviate' from this convention.

 The mailer.conf issue (for mail injection) is a separate issue and
 there's really no way around that.

Just to be clear: with 'nuke' I meant sendmail_enable=NONE in /etc/rc.conf.
Very convenient I might add.

-- 
Melvyn

===
FreeBSD sarevok.webteckies.org 5.2-BETA FreeBSD 5.2-BETA #1: Sat Nov 29 
00:15:33 CET 2003 [EMAIL PROTECTED]:/usr/obj/usr/src/sys/
SAREVOK_NOFW_DBG  i386
===


pgp0.pgp
Description: signature

[current tinderbox] failure on ia64/ia64

2003-11-30 Thread Tinderbox

TB --- 2003-11-30 22:24:27 - tinderbox 2.2 running on cueball.rtp.FreeBSD.org
TB --- 2003-11-30 22:24:27 - starting CURRENT tinderbox run for ia64/ia64
TB --- 2003-11-30 22:24:27 - checking out the source tree
TB --- cd /home/des/tinderbox/CURRENT/ia64/ia64
TB --- /usr/bin/cvs -f -R -q -d/home/ncvs update -Pd -A src
TB --- 2003-11-30 22:27:26 - building world
TB --- cd /home/des/tinderbox/CURRENT/ia64/ia64/src
TB --- /usr/bin/make -B buildworld
 Rebuilding the temporary build tree
 stage 1.1: legacy release compatibility shims
 stage 1.2: bootstrap tools
 stage 2.1: cleaning up the object tree
 stage 2.2: rebuilding the object tree
 stage 2.3: build tools
 stage 3: cross tools
 stage 4.1: building includes
 stage 4.2: building libraries
 stage 4.3: make dependencies
 stage 4.4: building everything..
TB --- 2003-11-30 23:32:24 - building generic kernel
TB --- cd /home/des/tinderbox/CURRENT/ia64/ia64/src
TB --- /usr/bin/make buildkernel KERNCONF=GENERIC
 Kernel build for GENERIC started on Sun Nov 30 23:32:25 GMT 2003
[...]
/vol/vol0/users/des/tinderbox/CURRENT/ia64/ia64/src/sys/vm/uma_core.c: In function 
`cache_drain':
/vol/vol0/users/des/tinderbox/CURRENT/ia64/ia64/src/sys/vm/uma_core.c:572: error: 
`mp_maxid' undeclared (first use in this function)
/vol/vol0/users/des/tinderbox/CURRENT/ia64/ia64/src/sys/vm/uma_core.c: In function 
`uma_startup':
/vol/vol0/users/des/tinderbox/CURRENT/ia64/ia64/src/sys/vm/uma_core.c:1223: error: 
`mp_maxid' undeclared (first use in this function)
/vol/vol0/users/des/tinderbox/CURRENT/ia64/ia64/src/sys/vm/uma_core.c: In function 
`uma_print_zone':
/vol/vol0/users/des/tinderbox/CURRENT/ia64/ia64/src/sys/vm/uma_core.c:2100: error: 
`mp_maxid' undeclared (first use in this function)
/vol/vol0/users/des/tinderbox/CURRENT/ia64/ia64/src/sys/vm/uma_core.c: In function 
`sysctl_vm_zone':
/vol/vol0/users/des/tinderbox/CURRENT/ia64/ia64/src/sys/vm/uma_core.c:2148: error: 
`mp_maxid' undeclared (first use in this function)
*** Error code 1

Stop in 
/vol/vol0/users/des/tinderbox/CURRENT/ia64/ia64/obj/ia64/vol/vol0/users/des/tinderbox/CURRENT/ia64/ia64/src/sys/GENERIC.
*** Error code 1

Stop in /vol/vol0/users/des/tinderbox/CURRENT/ia64/ia64/src.
*** Error code 1

Stop in /vol/vol0/users/des/tinderbox/CURRENT/ia64/ia64/src.
TB --- 2003-11-30 23:40:13 - TB --- /usr/bin/make returned exit code  1 
TB --- 2003-11-30 23:40:13 - TB --- ERROR: failed to build generic kernel
TB --- 2003-11-30 23:40:13 - tinderbox aborted

___
[EMAIL PROTECTED] mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-current
To unsubscribe, send any mail to [EMAIL PROTECTED]

Re: 5.2-BETA and related ports issues

2003-11-30 Thread Oliver Eikemeier

Robert Watson wrote:
On Sun, 30 Nov 2003, Andreas Klemm wrote:

I have a better idea, then we perhaps need something like a wrapper
script that is part of the FreeBSD basic system under /etc/rc.d that
checks for the start script under $LOCALBASE/etc/rc.d and starts it very
early. 
Hmm.  I talked with Gordon about this issue some last night, but he
pointed out a snag: most installs of FreeBSD place /usr on a separate
partition from /.  The rcNG ordering decision is made before /usr is
mounted, as /usr is mounted as part of the pieces kicked off by rc.d.  So
it would be a fairly large departure from the current implementation of
the rcNG code to reevaluate the ordering once more directories were
available in which to find scripts to run.  Not that it's not doable, but
we need to think about it carefully (and, unfortunately, it's not as easy
as simply adding /usr/local/etc/rc.d to the list..)
In PR conf/56736:
 http://www.freebsd.org/cgi/query-pr.cgi?pr=conf/56736
I suggested something like that: evaluate rcorder, execute till a certain
point, the reevaluate and continue exection. If you are interested I can
modify the patch to do just that.
-Oliver

___
[EMAIL PROTECTED] mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-current
To unsubscribe, send any mail to [EMAIL PROTECTED]

Re: 5.2-BETA and related ports issues

Melvyn Sopacua wrote:

Isn't that *exactly why* ports should respect $PREFIX? At least than you know 
that startup scripts are in one place. Maybe all that is needed is a variable 
RCDIR?= etc/rc.d, for people who want to 'deviate' from this convention.
I like that idea.  That could work.  But to make this seemless (in the 
case of RCDIR=/etc/rc.d), we would need to start adding the RCNG 
keywords to the startup scripts added by ports.

Richard Coleman
[EMAIL PROTECTED]
___
[EMAIL PROTECTED] mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-current
To unsubscribe, send any mail to [EMAIL PROTECTED]

Re: user:sys time ratio

2003-11-30 Thread Jeff Roberson

On Sun, 30 Nov 2003, Colin Percival wrote:

Robert Watson suggested that I compare performance from UP and SMP kernels:

 # /usr/bin/time -hl sh -c 'make -s buildworld 21'  /dev/null
Real  UserSys
UP kernel   38m33.29s 27m10.09s   10m59.15s
   (retest) 38m33.18s 27m04.40s   11m05.73s
SMP w/o HTT 41m01.54s 27m10.27s   13m29.82s
   (retest) 39m47.50s 27m08.05s   12m12.20s
SMP w/HTT   42m17.16s 28m12.82s   14m04.93s
   (retest) 44m09.61s 28m15.31s   15m44.86s

That enabling HTT degrades performance is not surprising, since I'm not
 passing the -j option to make; but a 5% performance delta between UP and
 SMP kernels is rather surprising (to me, at least), and the fact that the
 system time varies so much on the SMP kernel also seems peculiar.

So you have enabled SMP on a system with one physical core and two logical
cores?  Looks like almost a 20% slowdown in system time with the SMP
kernel.  It's too bad it's enabled by default now.  I suspect that some of
this is due to using the lock prefix on P4 cores.  It makes the cost of a
mutex over 300 cycles vs 50.  It might be interesting to do an experiment
without HTT, but with SMP enabled and the lock prefix commented out.

I have a set of changes for ULE that should fix some of the HTT slowdown,
although it is inevitable that there will always be some.  If you would
like to try the patch, it's available at:

http://www.chesapeake.net/~jroberson/ulehtt.diff

Cheers,
Jeff

Is this normal?

 Colin Percival

 ___
 [EMAIL PROTECTED] mailing list
 http://lists.freebsd.org/mailman/listinfo/freebsd-current
 To unsubscribe, send any mail to [EMAIL PROTECTED]


___
[EMAIL PROTECTED] mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-current
To unsubscribe, send any mail to [EMAIL PROTECTED]

Re: SiI3112 SATA controller problems - status

2003-11-30 Thread Derek Ragona

I tried the 11/29 snapshot, it is indeed worse. I got a failure during the
install's fsck.

The errors I got were:
ad4: Warning - WRITE_DMA recovered from missing interrupt
ad4: Failure - WRITE_DMA status=ffI couldn't copy the codes here, sorry
followed by lots of:
ad4: timeout sending command=ca
ad4: error issuing DMA command
All along I have experienced missing interrupt errors, along with DMA
write errors.

-Derek

At 02:01 PM 11/30/2003, Scott Long wrote:
Robert Watson wrote:
On Sun, 30 Nov 2003, Joe Marcus Clarke wrote:

On Fri, 2004-01-30 at 09:43, HaggeL wrote:

Hi Guys :)

Sorry if i waste your time. I®m a freeBSD noob and need some help.
I want to install freeBSD in januar and have some problems. I want to
buy me a new harddrive, a serial ATA one, because i got the Silicon
ImageR Sil 3112A-Controller onboard (Asus A7N8X Motherboard). I
didn®t find a driver in the Hardware Notes of FreeBSD 5.1, and on the
Producer homepage are only ready Linuxkernels avaible
(http://12.24.47.40/display/2n/searchDirect/?searchString=Sil+3112AsearchType=allwordssearchby=keywordsr=0.8157617).
So can anyone tell me if i can get a SATA disk run? I don®t want to
boot from it, just read and write. Buying a new disk only for windows
use is wasted money
We're having a pretty lengthy discussion about these controllers on this
list right now. I suggest you read the archives. Bottom line, the
controller is supported, but it's problematic. The ATA maintainer has
working controllers, but there are those of us that experience data
corruption, and at least one user that can't use his drive at all when
connected to said controller.
I believe a workaround was recently committed to improve behavior on older
cards using that chipset. Specifically the following change to
ata-chipset.c:
revision 1.48
date: 2003/11/28 19:01:28; author: sos; state: Exp; lines: +6 -2
Workaround for errata on early versions of the sii3112.
Approved by: re@
Does this make any difference in your configuration?
Robert N M Watson FreeBSD Core Team, TrustedBSD Projects
[EMAIL PROTECTED] Senior Research Scientist, McAfee Research
This commit only fixes a silent data corruption issue. I believe that
the issue at hand involves DMA not working at all.
Scott

___
[EMAIL PROTECTED] mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-current
To unsubscribe, send any mail to [EMAIL PROTECTED]
___
[EMAIL PROTECTED] mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-current
To unsubscribe, send any mail to [EMAIL PROTECTED]

Re: 5.2-BETA panic: page fault

Can you reproduce this problem without bktr?

 #6  0xc06743d8 in calltrap () at {standard input}:94
 #7  0xc0505b53 in _mtx_lock_flags (m=0x0, opts=0, 
 file=0xc06bfc1d /usr/src/sys/kern/kern_lock.c, line=228)
 at /usr/src/sys/kern/kern_mutex.c:214
 #8  0xc0502b54 in lockmgr (lkp=0xc3b2e028, flags=0, interlkp=0xe4, 
 td=0xc06bfc1d) at /usr/src/sys/kern/kern_lock.c:228
 #9  0xc0566d87 in vfs_busy (mp=0x0, flags=16, interlkp=0xc075d0e0,
 td=0x0)
 at /usr/src/sys/kern/vfs_subr.c:527
 #10 0xc056cfff in sync (td=0xc0730dc0, uap=0x0)

 #16 0xc06743d8 in calltrap () at {standard input}:94
 #17 0xc0505b53 in _mtx_lock_flags (m=0x0, opts=0, 
 file=0xc06bfc1d /usr/src/sys/kern/kern_lock.c, line=228)
 at /usr/src/sys/kern/kern_mutex.c:214
 #18 0xc0502b54 in lockmgr (lkp=0xc3b2e028, flags=0, interlkp=0xe4, 
 td=0xc06bfc1d) at /usr/src/sys/kern/kern_lock.c:228
 #19 0xc0566d87 in vfs_busy (mp=0x0, flags=0, interlkp=0x0, td=0x0)
 at /usr/src/sys/kern/vfs_subr.c:527
 #20 0xc056374c in lookup (ndp=0xd7f2ec00) at
 /usr/src/sys/kern/vfs_lookup.c:559

You are getting a double panic, with the second happening during the
file system sync.  The code seems to be be tripping over the same mount
list entry each time.  Maybe the mount list is getting corrupted.  Are
you using amd?  Print *lkp in the lockmgr() stack frame.


You might want to add
KASSERT(mp-mnt_lock.lk_interlock !=NULL, vfs_busy: NULL mount
pointer interlock);
at the top of vfs_busy() and right before the lockmgr() call.

___
[EMAIL PROTECTED] mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-current
To unsubscribe, send any mail to [EMAIL PROTECTED]

Re: 5.2-BETA and related ports issues

2003-11-30 Thread Oliver Eikemeier

Dag-Erling Smørgrav wrote:

Andreas Klemm [EMAIL PROTECTED] writes:

I can't recommend doing it this way, since some ports I know
are writing startup scripts to /etc/rc.d :-/
That is very, very bad.  I wish we had some kind of ports QA team :(
Can I assign PR 56748 to [EMAIL PROTECTED]
 http://www.freebsd.org/cgi/query-pr.cgi?pr=bin/56748
___
[EMAIL PROTECTED] mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-current
To unsubscribe, send any mail to [EMAIL PROTECTED]

Re: 5.2-BETA and related ports issues

2003-11-30 Thread Michael Edenfield

* Robert Watson [EMAIL PROTECTED] [031130 11:36]:
 
 On Sun, 30 Nov 2003, Andreas Klemm wrote:
 
  I have a better idea, then we perhaps need something like a wrapper
  script that is part of the FreeBSD basic system under /etc/rc.d that
  checks for the start script under $LOCALBASE/etc/rc.d and starts it very
  early. 
 
 Hmm.  I talked with Gordon about this issue some last night, but he
 pointed out a snag: most installs of FreeBSD place /usr on a separate
 partition from /.  The rcNG ordering decision is made before /usr is
 mounted, as /usr is mounted as part of the pieces kicked off by rc.d.  So
 it would be a fairly large departure from the current implementation of
 the rcNG code to reevaluate the ordering once more directories were
 available in which to find scripts to run.  Not that it's not doable, but
 we need to think about it carefully (and, unfortunately, it's not as easy
 as simply adding /usr/local/etc/rc.d to the list..)  Having wrapper

Since this issue only comes up for a small number of ports, mostly those
ports which can behave as back-end services for things that are in the
base, wouldn't in be sufficient to have certain checkpoints in the rcNG
code that simple scanned for and ran anything in a given location?

You wouldn't need to reorder anything, simply have clearly defined
pre-whatever or post-whatever steps that did something like:

for i in `grep RUNAT: post-mount-usr /usr/local/etc/rc.d/*.sh` ; do
  [ -x $i ]  sh $1;
done



--Mike



pgp0.pgp
Description: PGP signature

Re: kernel compile fails in uma_core.c

2003-11-30 Thread Jeff Roberson


On Sun, 30 Nov 2003, Paulius Bulotas wrote:

 Hello,

 when building kernel:
 ../../../vm/uma_core.c: In function `zone_timeout':
 ../../../vm/uma_core.c:345: error: `mp_maxid' undeclared (first use in
 this function)
 and so on.

 Anything I missed?

I just fixed this, sorry.


 Paulius
 ___
 [EMAIL PROTECTED] mailing list
 http://lists.freebsd.org/mailman/listinfo/freebsd-current
 To unsubscribe, send any mail to [EMAIL PROTECTED]


___
[EMAIL PROTECTED] mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-current
To unsubscribe, send any mail to [EMAIL PROTECTED]

Re: 5.2-BETA panic: page fault

On Mon, 2003-12-01 at 01:10, Don Lewis wrote:
 Can you reproduce this problem without bktr?
 
snip
 You are getting a double panic, with the second happening during the
 file system sync.  The code seems to be be tripping over the same mount
 list entry each time.  Maybe the mount list is getting corrupted.  Are
 you using amd?  Print *lkp in the lockmgr() stack frame.
 
 
 You might want to add
   KASSERT(mp-mnt_lock.lk_interlock !=NULL, vfs_busy: NULL mount
 pointer interlock);
 at the top of vfs_busy() and right before the lockmgr() call.

No, I'm not using amd.

(kgdb) print *lkp
$1 = {lk_interlock = 0x0, lk_flags = 0, lk_sharecount = 0, lk_waitcount
= 0, 
  lk_exclusivecount = 0, lk_prio = 0, lk_wmesg = 0x0, lk_timo = 0, 
  lk_lockholder = 0x0, lk_newlock = 0x0}

This is indeed just NULLs.

I haven't tried without bktr yet but I hope I'll have time for that (and
the KASSERT) tomorrow.

The panic only seems to happen when accessing my read-only mounted ext2
partition. Today I tried not to access any data there and uptime is
14h30min now. The panic always happened after a few hours. So this is
probably the core of the problem.

___
[EMAIL PROTECTED] mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-current
To unsubscribe, send any mail to [EMAIL PROTECTED]

lock order reversal

2003-11-30 Thread genew

Is this a known issue on 5.2 beta 6 sup'ed nov 29/03?
lock order reveral
 1st 0xc2121b58 vm object (vm object) @ /usr/src/sys/vm/swap_pager.c:1323
 2nd 0xc0987b00 swap_pager swhash (swap_pager swhash) @ 
/usr/src/sys/vm/swap_pager.c:1838
 3rd 0xc1036948 vm object (vm object) @ /usr/src/sys/vm/uma_core.c:876
Stack backtrace:
backtrace(c0897ea1,c1036948,c08ac9f5,c08ac9f5,c08ad8d6) at 
backtrace+0x17
witness_lock(c1036948,8,c08ad8d6,36c,1021540) at witness_lock+0x672
_mtx_lock_flags(c1036948,0,c08ad8d6,36c,c1021554) at 
_mtx_lock_flags+0xba
obj_alloc(c1021540,1000,c8f879f7,101,c0956320) at obj_alloc+0x3f
slab_zalloc(c1021540,1,8,c08ad8d6,68c) at slab_zalloc+0xb3
uma_zone_slab(c1021540,1,c08ad8d6,68c,c10215e0) at 
uma_zone_slab+0xd6
uma_zalloc_internal(c1021540,0,1,5c1,c08ad7ef,72e) at 
uma_zalloc_internal+0x3e
uma_zalloc_arg(c1021540,0,1,72e,2) at uma_zalloc_arg+0x3ab
swp_pager_meta_build(c2121b58,5,0,2,0) at swp_pager_meta_build+0x174
swap_pager_putpages(c2121b58,c8f87bd0,4,0,c8f87b30) at 
swap_pager_putpages+0x32d
default_pager_putpages(c2121b58,c8f87bd0,4,0,c8f87b30) at 
default_pager_putpages+0x2e
vm_pageout_flush(c8f87bd0,4,0,eb,c0958020) at vm_pageout_flush+0x17a
vm_pageout_clean(c119f608,0,c08ad6f1,32a,0) vm_pageout_clean+0x305
vm_pageout_scan(0,0,c08ad6f1,5a9,1f4) at vm_pageout_scan+0x64c
vm_pageout(0,c8f87d48,c08927ba,311,0) at vm_pageout+0x31b
fork_exit(c07eb910,0,c8f87d48) at fork_exit+0xb4
fork_trampoline() at fork_trampoline+0x8
--- trap 0x1, eip = 0, esp = 0xc8f87d7c, ebd = 0 ---


BTW then terminal then freezes and the intranet connection is frozen.

___
[EMAIL PROTECTED] mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-current
To unsubscribe, send any mail to [EMAIL PROTECTED]

Re: Ports startup scripts in /etc/rc.d (Re: 5.2-BETA and related ports issues)

2003-11-30 Thread Matthias Andree

Richard Coleman [EMAIL PROTECTED] writes:

 But that kinda defeats the purpose of RCNG.  One of the best features of
 RCNG is that it makes it easier to add/delete applications from the
 system.  Not using it for this purpose reduces its utility.

 Let's not let the typical BSD traditionalism get in the way of using
 RCNG for what it's designed.  Don't get me wrong.  I'm not advocating
 Linux-style integration of packages/ports.  But this seems fairly
 harmless.

Ports belong into /usr/local, not into /etc. There should be some hook
that allows port start scripts to run before some base system scripts,
and if Oliver's two-staged reevaluate approach supports this with /
and /usr in separate partitions, then why not take his suggestion?

There's nothing that prevents RCNG from stretching out its fangs to
/usr/local/etc/rc*, in fact, hier(7) encourages that.

If I get the picture right, what's suggested is that after mounting
local file systems, the RC order is re-evaluated, and again after
mounting remote file systems (diskless). This would allow the system
to gradually complete its /etc/rc* picture.

Another idea would be to use unionfs or something to keep
/usr/local/etc/rc.d in the root partition for real, and when it's
shadowed by the actual /usr/local or /usr mount, punch a hole so you can
look at the rootfs with unionfs or something. I'd like Oliver's
suggestion better though.

-- 
Matthias Andree

Encrypt your mail: my GnuPG key ID is 0x052E7D95
___
[EMAIL PROTECTED] mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-current
To unsubscribe, send any mail to [EMAIL PROTECTED]

Re: 5.2-BETA and related ports issues

2003-11-30 Thread M. Warner Losh

In message: [EMAIL PROTECTED]
Andreas Klemm [EMAIL PROTECTED] writes:
: I have a better idea, then we perhaps need something like a 
: wrapper script that is part of the FreeBSD basic system under /etc/rc.d
: that checks for the start script under $LOCALBASE/etc/rc.d
: and starts it very early.

Only if $LOCALBASE is acutally mounted, which can be a problem
depending on when 'very early' is. :-(

Warner
___
[EMAIL PROTECTED] mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-current
To unsubscribe, send any mail to [EMAIL PROTECTED]

Re: Fatal double fault with 20031116-JPSNAP

2003-11-30 Thread Damian Gerow

(Re-sending, my original post was accepted by mx1.freebsd.org, but seems to
have been lost somewhere.)

Thus spake Damian Gerow ([EMAIL PROTECTED]) [29/11/03 17:04]:
 But this is a little OT.  I'll find some way to update my system, and
 respond back if the problem's fixed or not in a later -CURRENT.

Nope, I'm still seeing the double fault:

# uname -a
FreeBSD  5.2-BETA-20031129-JPSNAP FreeBSD 5.2-BETA-20031129-JPSNAP #0: Sat Nov 29 
02:47:57 GMT 2003 [EMAIL PROTECTED]:/usr/obj/usr/src/sys/GENERIC  i386
# make buildworld
snip

panic: Duplicate free of item 0xc1cd8e1c from zone 0xc102e1c0(PV ENTRY)

cpuid = 0; 
Debugger(panic)
Stopped at  Debugger+0x55:  xchgl   %ebx,in_Debugger.0
db trace
Debugger(c0898ddc,0,c08b186e,d8a11c10,100) at Debugger+0x55
panic(c08b186e,c1cd8e1c,c102e1c0,c08b66c4,c08b13a5) at panic+0x156
uma_dbg_free(c102e1c0,0,c1cd8e1c,6d0,0) at uma_dbg_free+0x111
uma_zfree_arg(c102e1c0,c1cd8e1c,0,a2f,c08968de) at uma_zfree_arg+0x123
pmap_remove_pages(c1d0ef60,0,bfc0,11a,c08968de) at
pmap_remove_pages+0x209
exit1(c4712c80,0,c08968de,65,d8a11d40) at exit1+0x66c
sys_exit(c4712c80,d8a11d14,c08b6d61,3ee,1) at sys_exit+0x41
syscall(2f,2f,2f,bfbfe938,0) at syscall+0x2c0
Xint0x80_syscall() at Xint0x80_syscall+0x1d
--- syscall (1, FreeBSD ELF32, sys_exit), eip = 0x826aa63, esp = 0xbfbfe8f4, ebp = 
0xbfbfe910 ---
db show pcpu 0
cpuid= 0
curthread= 0xc4712c80: pid 34357 cc1
curpcb   = 0xd8a11da0
fpcurthread  = none
idlethread   = 0xc1cff640: pid 11 idle: cpu0
APIC ID  = 0
currentldt   = 0x28
spin locks held:
db 

It /does/ take a bit longer to get to, and I didn't see any of the previous
console-flooding messages.  But the panic still happens.
___
[EMAIL PROTECTED] mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-current
To unsubscribe, send any mail to [EMAIL PROTECTED]

Re: Ports startup scripts in /etc/rc.d (Re: 5.2-BETA and related ports issues)

Matthias Andree wrote:

Richard Coleman [EMAIL PROTECTED] writes:


But that kinda defeats the purpose of RCNG.  One of the best features of
RCNG is that it makes it easier to add/delete applications from the
system.  Not using it for this purpose reduces its utility.
Let's not let the typical BSD traditionalism get in the way of using
RCNG for what it's designed.  Don't get me wrong.  I'm not advocating
Linux-style integration of packages/ports.  But this seems fairly
harmless.


Ports belong into /usr/local, not into /etc. There should be some hook
that allows port start scripts to run before some base system scripts,
and if Oliver's two-staged reevaluate approach supports this with /
and /usr in separate partitions, then why not take his suggestion?
There's nothing that prevents RCNG from stretching out its fangs to
/usr/local/etc/rc*, in fact, hier(7) encourages that.
If I get the picture right, what's suggested is that after mounting
local file systems, the RC order is re-evaluated, and again after
mounting remote file systems (diskless). This would allow the system
to gradually complete its /etc/rc* picture.
Another idea would be to use unionfs or something to keep
/usr/local/etc/rc.d in the root partition for real, and when it's
shadowed by the actual /usr/local or /usr mount, punch a hole so you can
look at the rootfs with unionfs or something. I'd like Oliver's
suggestion better though.
I guess I'm not really arguing for putting the startup scripts for ports 
in /etc/rc.d (contradicting what I said earlier).  But I do think that 
RCNG/rcorder needs to be extended to handle ports.  And it needs to be 
done in a more comprehensive fashion than just adding special hooks for 
backend databases.  The multiple rcorder evaluation method you mention 
sounds like a good place to start.

The unionfs idea is also interesting.  But I doubt many people trust it 
enough to use it for this purpose.  It's a shame really, but that's 
another discussion.

Richard Coleman
[EMAIL PROTECTED]
___
[EMAIL PROTECTED] mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-current
To unsubscribe, send any mail to [EMAIL PROTECTED]

Re: user:sys time ratio


On Sun, 30 Nov 2003, Jeff Roberson wrote:

 On Sun, 30 Nov 2003, Colin Percival wrote:
 
 Robert Watson suggested that I compare performance from UP and SMP kernels:
 
  # /usr/bin/time -hl sh -c 'make -s buildworld 21'  /dev/null
 Real  UserSys
 UP kernel   38m33.29s 27m10.09s   10m59.15s
(retest) 38m33.18s 27m04.40s   11m05.73s
 SMP w/o HTT 41m01.54s 27m10.27s   13m29.82s
(retest) 39m47.50s 27m08.05s   12m12.20s
 SMP w/HTT   42m17.16s 28m12.82s   14m04.93s
(retest) 44m09.61s 28m15.31s   15m44.86s
 
 That enabling HTT degrades performance is not surprising, since I'm not
  passing the -j option to make; but a 5% performance delta between UP and
  SMP kernels is rather surprising (to me, at least), and the fact that the
  system time varies so much on the SMP kernel also seems peculiar.
 
 So you have enabled SMP on a system with one physical core and two
 logical cores?  Looks like almost a 20% slowdown in system time with the
 SMP kernel.  It's too bad it's enabled by default now.  I suspect that
 some of this is due to using the lock prefix on P4 cores.  It makes the
 cost of a mutex over 300 cycles vs 50.  It might be interesting to do an
 experiment without HTT, but with SMP enabled and the lock prefix
 commented out. 

It would be interesting to compare the relative costs of:

(a) De-inlining of mutex calls so that you can plug mutex
implementations at link-time, with SMP and non-SMP versions of mutex
operations, perhaps indicating with a loader which approach to take. 

(b) Using inlined SMP mutexes for all kernels. 

Would also be very interesting to have mutex contention information, and
in particular, to know how much time was spent contending on Giant during
the build...

Robert N M Watson FreeBSD Core Team, TrustedBSD Projects
[EMAIL PROTECTED]  Senior Research Scientist, McAfee Research

___
[EMAIL PROTECTED] mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-current
To unsubscribe, send any mail to [EMAIL PROTECTED]

Re: Nvidia problem fixed in current?

2003-11-30 Thread Chris

Justin Smith wrote:

The kernel nvidia driver worked fine in 5.1. It only STOPPED working 
when I upgraded to 5.2 beta (and rebuilt and reinstalled the kernel 
driver).

This is a problem of 5.2 vs 5.1  something changed that stopped it 
from working. Perhaps some libraries in 5.2 are no longer compatible 
with the nvidia kernel driver (since it is, fundamentally, a binary 
program --- one cannot recompile the core of it).

Perhaps it's a problem with AGP in 5.2. Slowing down AGP (to 1x) 
allows the nvidia driver to work but it still reboots the machine 
whenever I try to do anything that involves OpenGL...

Also, it's odd the the thing fails in such a strange manner (rebooting 
the machine without any error messages).

I had this with an ASUS mother board. Could not  figure it out intill 
the board failed and  I replaced the board.

Chris

___
[EMAIL PROTECTED] mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-current
To unsubscribe, send any mail to [EMAIL PROTECTED]

-CURRENT panic (Backtrace included. recent ip_input changes related?)

2003-11-30 Thread Xin LI/

Hi,

On a recently compiled -CURRENT kernel, I have triggered a panic when
turning fxp0 into promisc mode than turning it off and then turning it on.
My boxes are connected through a hub and some of them (not the panic'ed one)
have heavy network load.

Hope this backtrace is useful. For more information, please contact me.
Thanks in advance!

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: m_copym, offset  size of mbuf chain panic messages:
---
panic: m_copym, offset  size of mbuf chain

syncing disks, buffers remaining... 892 892 892 892 892 892 892 892 892 892
892 892 892 892 892 892 892 892 892 892 giving up on 794 buffers
Uptime: 12h15m26s
Dumping 63 MB
 16 32 48
---
#0  doadump () at /usr/src/sys/kern/kern_shutdown.c:240
240 dumping++;
(kgdb) bt full
#0  doadump () at /usr/src/sys/kern/kern_shutdown.c:240
No locals.
#1  0xc04eb791 in boot (howto=256) at /usr/src/sys/kern/kern_shutdown.c:372
No locals.
#2  0xc04ebb27 in panic () at /usr/src/sys/kern/kern_shutdown.c:550
td = (struct thread *) 0xc0e0
bootopt = 256
newpanic = 1
ap = 0xc62f3850 p8/?004??
buf = m_copym, offset  size of mbuf chain, '\0' repeats 219
times
#3  0xc05296f5 in m_copym (m=0x0, off0=1500, len=1480, wait=4) at
/usr/src/sys/kern/uipc_mbuf.c:211
n = (struct mbuf *) 0xc0e24540
np = (struct mbuf **) 0x4
off = 1428
top = (struct mbuf *) 0x2
copyhdr = 0
#4  0xc0580141 in ip_fragment (ip=0xc1015020, m_frag=0xc62f390c,
mtu=-1058912960, if_hwassist_flags=0, 
sw_csum=1) at /usr/src/sys/netinet/ip_output.c:1225
error = 0
hlen = 20
len = 1480
off = 1500
m0 = (struct mbuf *) 0xc0e16a00
firstlen = 1480
mnext = (struct mbuf **) 0xc0e16a04
nfrags = 1
#5  0xc057fd2c in ip_output (m0=0x1, opt=0xc1015020, ro=0xc62f3988, flags=1,
imo=0x0, inp=0x0)
at /usr/src/sys/netinet/ip_output.c:1053
ip = (struct ip *) 0xc1015020
ifp = (struct ifnet *) 0xc161a000
m = (struct mbuf *) 0xc0e16a00
hlen = 20
len = 582
off = -1066913577
error = 0
dst = (struct sockaddr_in *) 0xc62f398c
ia = (struct in_ifaddr *) 0xc169a900
isbroadcast = 0
sw_csum = 1
pkt_dst = {s_addr = 16951488}
iproute = {ro_rt = 0xc169be00, ro_dst = {sa_len = 16 '\020',
sa_family = 2 '\002', 
sa_data = \0\0\002\001\0\0\0\0\0\0\0}}
so = (struct socket *) 0x0
sp = (struct secpolicy *) 0xc1624c80
args = {m = 0xc06dcfc0, oif = 0x1, next_hop = 0x0, rule = 0x0, eh =
0x0, ro = 0x4, dst = 0x1,
  flags = -969983596, f_id = {dst_ip = 3226510491, src_ip = 3228422080,
dst_port = 0, src_port = 0, 
proto = 0 '\0', flags = 106 'j'}, divert_rule = 0, retval = 3324983708}
src_was_INADDR_ANY = 0
#6  0xc057e7b8 in ip_forward (m=0xc0e16a00, srcrt=1, next_hop=0x0) at
/usr/src/sys/netinet/ip_input.c:1929
tag = {mh_next = 0x0, mh_nextpkt = 0xc06e6620, mh_data = 0x3(kgdb)
#0  doadump () at /usr/src/sys/kern/kern_shutdown.c:240
No locals.
#1  0xc04eb791 in boot (howto=256) at /usr/src/sys/kern/kern_shutdown.c:372
No locals.
#2  0xc04ebb27 in panic () at /usr/src/sys/kern/kern_shutdown.c:550
td = (struct thread *) 0xc0e0
bootopt = 256
newpanic = 1
ap = 0xc62f3850 p8/?004??
buf = m_copym, offset  size of mbuf chain, '\0' repeats 219
times
#3  0xc05296f5 in m_copym (m=0x0, off0=1500, len=1480, wait=4) at
/usr/src/sys/kern/uipc_mbuf.c:211
n = (struct mbuf *) 0xc0e24540
np = (struct mbuf **) 0x4
off = 1428
top = (struct mbuf *) 0x2
copyhdr = 0
#4  0xc0580141 in ip_fragment (ip=0xc1015020, m_frag=0xc62f390c,
mtu=-1058912960, if_hwassist_flags=0, 
sw_csum=1) at /usr/src/sys/netinet/ip_output.c:1225
error = 0
hlen = 20
len = 1480
off = 1500
m0 = (struct mbuf *) 0xc0e16a00
firstlen = 1480
mnext = (struct mbuf **) 0xc0e16a04
nfrags = 1
#5  0xc057fd2c in ip_output (m0=0x1, opt=0xc1015020, ro=0xc62f3988, flags=1,
imo=0x0, inp=0x0)
at /usr/src/sys/netinet/ip_output.c:1053
ip = (struct ip *) 0xc1015020
ifp = (struct ifnet *) 0xc161a000
m = (struct mbuf *) 0xc0e16a00
hlen = 20
len = 582
off = -1066913577
error = 0
dst = (struct sockaddr_in *) 0xc62f398c
ia = (struct in_ifaddr *) 0xc169a900
isbroadcast = 0
sw_csum = 1
pkt_dst = {s_addr = 16951488}
iproute = {ro_rt = 0xc169be00, ro_dst = {sa_len = 16 '\020',
sa_family = 2

Re: 5.2-BETA panic: page fault

On  1 Dec, Stefan Ehmann wrote:
 On Mon, 2003-12-01 at 01:10, Don Lewis wrote:
 Can you reproduce this problem without bktr?
 
 snip
 You are getting a double panic, with the second happening during the
 file system sync.  The code seems to be be tripping over the same mount
 list entry each time.  Maybe the mount list is getting corrupted.  Are
 you using amd?  Print *lkp in the lockmgr() stack frame.
 
 
 You might want to add
  KASSERT(mp-mnt_lock.lk_interlock !=NULL, vfs_busy: NULL mount
 pointer interlock);
 at the top of vfs_busy() and right before the lockmgr() call.
 
 No, I'm not using amd.
 
 (kgdb) print *lkp
 $1 = {lk_interlock = 0x0, lk_flags = 0, lk_sharecount = 0, lk_waitcount
 = 0, 
   lk_exclusivecount = 0, lk_prio = 0, lk_wmesg = 0x0, lk_timo = 0, 
   lk_lockholder = 0x0, lk_newlock = 0x0}
 
 This is indeed just NULLs.

Not good.  Nothing should be writing to lk_interlock once it has been
initialized.  Either something is stomping on an active struct mount,
we're still using it after it has been put on the free list, or
dp-v_mountedhere is pointing somewhere bogus.  I don't suspect the
latter because the second panic() in the sync() code doesn't follow this
path to get to the struct mount.

 I haven't tried without bktr yet but I hope I'll have time for that (and
 the KASSERT) tomorrow.
 
 The panic only seems to happen when accessing my read-only mounted ext2
 partition. Today I tried not to access any data there and uptime is
 14h30min now. The panic always happened after a few hours. So this is
 probably the core of the problem.

That sounds like a possibility.  I might be able to try that here when I
have some idle time on my -CURRENT box.

Can you print *dp-v_mountedhere in the lookup() frame?  That should
show the mount point information and might show if anything else in
struct mount is damaged.
___
[EMAIL PROTECTED] mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-current
To unsubscribe, send any mail to [EMAIL PROTECTED]

Re: Ports startup scripts in /etc/rc.d (Re: 5.2-BETA and related ports issues)

2003-11-30 Thread Maxim M. Kazachek

On Sun, 30 Nov 2003, Richard Coleman wrote:

Andreas Klemm wrote:

I guess I don't see the problem.  What is wrong with ports adding
startup scripts to /etc/rc.d?  For certain ports, that is the only way
to get the startup dependencies right (like making sure openldap or
postgresql starts before your mail system).  This will become more
important as more of the base system moves to ports/packages.

Just refine the note in UPDATING to specifically state which startup
scripts to remove, rather than rm -rf /etc/rc.d/*.


 As I wrote im my previous mail we could import wrapper scripts
 for such basic services, since there are only few services
 that are so generic, that they have to be available so early
 in boot order.

 I strongly would dislike creating ports to install stuff under
 /etc/whatever.

 This would start to violate things for what I liked FreeBSD for
 all these many years and I hope/think other have the same feeling
 concerning this.

  Andreas ///


But that kinda defeats the purpose of RCNG.  One of the best features of
RCNG is that it makes it easier to add/delete applications from the
system.  Not using it for this purpose reduces its utility.

Let's not let the typical BSD traditionalism get in the way of using
RCNG for what it's designed.  Don't get me wrong.  I'm not advocating
Linux-style integration of packages/ports.  But this seems fairly harmless.

Richard Coleman
[EMAIL PROTECTED]


___
[EMAIL PROTECTED] mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-current
To unsubscribe, send any mail to [EMAIL PROTECTED]

Perhaps we just need to place wrapper startup script, that will
try to start real startup script in /usr/local/etc/rc.d if it exist?
Most of ports are installed into /usr/local, so, lets don't use hierarchy
above that.

   Sincerely, Maxim M. Kazachek
   mailto:[EMAIL PROTECTED]
   mailto:[EMAIL PROTECTED]

___
[EMAIL PROTECTED] mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-current
To unsubscribe, send any mail to [EMAIL PROTECTED]

5.2-BETA boot failure

2003-11-30 Thread Jerry Keefe

I tried upgrading a Dell Optiplex GXa from Release 5.1p10 to the 5.2
Beta using the mini-install CD.  The system hangs in the boot loader. 
This problem doesn't happen with the Release 5.1 CDs.

I then tried upgrading from source after getting CURRENT as of
11/29/2003, and was able to build and install the new GENERIC kernel.
Upon reboot, the system hangs in the same way as when booting from the
mini-install CD.

The only thing unusual about this machine is that the onboard EIDE
controller is disabled, and a PCI EIDE controller has been added.

The system doesn't seem to get far enough to get a dmesg output or a
backtrace out of this, but here's a transcript of the last few lines if
it helps.

Timecounters tick every 10.000 msec
ata2-master: WARNING - SETFEATURES recovered from missing interrupt
ata2-master: WARNING - SETFEATURES recovered from missing interrupt
ata2-slave: WARNING - SETFEATURES recovered from missing interrupt
ata2-slave: WARNING - SETFEATURES recovered from missing interrupt
ad4: WARNING - SETFEATURES recovered from missing interrupt
ad4: WARNING - SETFEATURES recovered from missing interrupt
ad4: WARNING - SET_MULTI recovered from missing interrupt
GEOM: create disk ad4 dp=0xc23ce960
ad4: 19541MB Maxtor 52049U4 [38703/16/63] at ata2-master UDMA66
ad5: WARNING - SETFEATURES recovered from missing interrupt
ad5: WARNING - SETFEATURES recovered from missing interrupt
ad5: WARNING - SET_MULTI recovered from missing interrupt
GEOM: create disk ad5 dp=0xc23ce660
ad5: 4121MB Maxtor 90432D2 [8374/16/63] at ata2-master UDMA33
ata3-master: WARNING - SETFEATURES recovered from missing interrupt
ata3: resetting devices ..

machine is hung at this point.

___
[EMAIL PROTECTED] mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-current
To unsubscribe, send any mail to [EMAIL PROTECTED]

Re: Change install-order? (upgrade from static to dynamic root)

2003-11-30 Thread Garance A Drosihn

At 9:39 PM -0500 11/26/03, Garance A Drosihn wrote:
I just installed 5.1-release on a sparc64, and then cvsup'ed
to the latest snapshot of -current.  Since that update is such
a large jump in time, I was going from a system which had no
/rescue or /libexec to one which builds everything dynamically.
This gets one into a mess in the middle of installworld, where
suddenly almost everything dies with messages like:
ELF interpreter /libexec/ld-elf.so.1 not found
I know others have run into this problem, but there seems to be
nothing in UPDATING to warn people about it.  Or at least, I
didn't see anything in /usr/src/UPDATING under sparc64.
I did some more tests today, and it looks like it is still
true that updating from a non-/libexec system to a system
with both /libexec and dynamic-root will not work right.
There is a check in /usr/src/Makefile.inc1 which tries to
help out, but when I try a test-run of make (with the right
environment and parameters), that section does not seem to
do anything.  That section says:
# When upgrading to a dynamically linked root, install the runtime
# linker early into its new location before make(1) has a chance  
# to run the dynamically linked /bin/sh.
.if !defined(NO_DYNAMICROOT)  !defined(NOPIC)  \
(!defined(TARGET_ARCH) || ${TARGET_ARCH} == ${MACHINE_ARCH})  \
!defined(DISTDIR)  \
(!defined(DESTDIR) || empty(DESTDIR) || ${DESTDIR} == /)  \
!exists(/libexec/ld-elf.so.1)
SUBDIR+= libexec/rtld-elf
.endif

However, libexec/rtld-elf does not get added to the list of
subdirectories.  I am not completely sure what all those
lines in the .if are checking for, but if I change DISTDIR
to DESTDIR on the third line, I do get libexec/rtld-elf
added to the the SUBDIR variable.
But even if that fixes the check, I don't understand why we
would not just move up the:
.if exists(${.CURDIR}/libexec)
SUBDIR+= libexec
.endif
so that it will be installed before /bin is.  We already
install /include and /lib before we install /bin, and I would
think that we would *always* want a new /libexec installed
before installing /bin files which may depend on some change
to libraries in that directory.
Disclaimer: I realize there could be many subtleties here that
I am not aware off, so consider this more of a question than a
statement that something is definitely wrong.  Why *wouldn't*
we want /libexec installed before /bin?  I do know that the
current setup still does not work (going from 5.1-secure to
5.1-rightNow), but I may be pushing for the wrong solution.
[also, I intended to do more checking of this, but I've run
out of weekend and I doubt I'll work on this much until
next weekend]
--
Garance Alistair Drosehn=   [EMAIL PROTECTED]
Senior Systems Programmer   or  [EMAIL PROTECTED]
Rensselaer Polytechnic Instituteor  [EMAIL PROTECTED]
___
[EMAIL PROTECTED] mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-current
To unsubscribe, send any mail to [EMAIL PROTECTED]

Re: Ports startup scripts in /etc/rc.d (Re: 5.2-BETA and related ports issues)


On Mon, 1 Dec 2003, Maxim M. Kazachek wrote:

 On Sun, 30 Nov 2003, Richard Coleman wrote:
snip

For 5.2-RELEASE, I think we should ignore the whole issue and let the
couple of ports that insert things in /etc/rc.d just do it.  We're not
going to find any other solution in time to either close the discussion or
test it properly.

For 5.2-CURRENT, I think we should revisit this issue with one of the
following conclusions winning out, and the rest being discarded as
flame-bait: 

(1) Combine / and /usr into a single file system by default, and add
/usr/local/etc/rc.d to the search order, with appropriate hacks to
handle old-style scripts.  The devil will be in the bikeshed, but the
implementation is easy, except for the bit where we explain that
NFS-mounted /usr/local won't work too well.

(2) Reevaluate the order at routine points in the boot where new scripts
might now be available (due to file system mounts or whatever).
Essentially insert the new cards into the deck, and shuffle.  This
requires rethinking of our current approach, which assumes a static
order is created once at the start of the boot by rcorder(8).  The
devil will be in the big picture *and* the details of the
implementation.

(3) Add /local/etc/rc.d or /local/rc.d or /etc/local/rc.d or the like, a
new directory that third party applications are allowed to modify
during install, and that will be present for the creation of the
static ordering by rcorder(8) early in the boot.  The devil will be in
the bikeshed, but the implementation is easy.

(4) Continue to ignore the issue and let some ports install into /etc/rc.d
and consider them unorthodox, incorrect, but something we can
overlook.  The devil isn't here, or at least, if it is, we'll overlook
it. 

I'm actually leaning towards (2) as being the best solution, as it's easy
and functional.

Robert N M Watson FreeBSD Core Team, TrustedBSD Projects
[EMAIL PROTECTED]  Senior Research Scientist, McAfee Research

___
[EMAIL PROTECTED] mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-current
To unsubscribe, send any mail to [EMAIL PROTECTED]

Re: Ports startup scripts in /etc/rc.d (Re: 5.2-BETA and related ports issues)

2003-11-30 Thread David O'Brien

On Sun, Nov 30, 2003 at 11:47:24PM -0500, Robert Watson wrote:
 On Mon, 1 Dec 2003, Maxim M. Kazachek wrote:
  On Sun, 30 Nov 2003, Richard Coleman wrote:
..snip..
 For 5.2-CURRENT, I think we should revisit this issue with one of the
 following conclusions winning out, and the rest being discarded as
 flame-bait: 
 
 (1) Combine / and /usr into a single file system by default, and add
 /usr/local/etc/rc.d to the search order, with appropriate hacks to
 handle old-style scripts.  The devil will be in the bikeshed, but the
 implementation is easy, except for the bit where we explain that
 NFS-mounted /usr/local won't work too well.

I would like to show support for this option.  I've been running /usr on
the / partition on *all* my FBSD machines for the past 4 years.  The
reasons for having a separate / and /usr just don't apply today.  Disks
are large enough to hold both, and UFS(FFS) is stable.

Sun and SGI both combine / and /usr on their pre-installed workstation
machines.
___
[EMAIL PROTECTED] mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-current
To unsubscribe, send any mail to [EMAIL PROTECTED]

Re: Ports startup scripts in /etc/rc.d (Re: 5.2-BETA and related ports issues)

David O'Brien wrote:

For 5.2-CURRENT, I think we should revisit this issue with one of the
following conclusions winning out, and the rest being discarded as
flame-bait: 

(1) Combine / and /usr into a single file system by default, and add
   /usr/local/etc/rc.d to the search order, with appropriate hacks to
   handle old-style scripts.  The devil will be in the bikeshed, but the
   implementation is easy, except for the bit where we explain that
   NFS-mounted /usr/local won't work too well.


I would like to show support for this option.  I've been running /usr on
the / partition on *all* my FBSD machines for the past 4 years.  The
reasons for having a separate / and /usr just don't apply today.  Disks
are large enough to hold both, and UFS(FFS) is stable.
Sun and SGI both combine / and /usr on their pre-installed workstation
machines.
That abandons the ability to have a read-only /usr.

Richard Coleman
[EMAIL PROTECTED]
___
[EMAIL PROTECTED] mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-current
To unsubscribe, send any mail to [EMAIL PROTECTED]

Re: MAJOR number

2003-11-30 Thread M. Warner Losh

In message: [EMAIL PROTECTED]
John-Mark Gurney [EMAIL PROTECTED] writes:
: There are still major numbers for a few devices that may are standard
: (such as zero/null), but not common...

I've already assigned him one.

:  I've read that FreeBSD doesn't use them any more.
:  But we may need it to not interfere with other device
:  drivers in previous releases of FreeBSD.
: 
: so, you are planning do do 4.x and earlier releases of your driver?

Yes.

Warner
___
[EMAIL PROTECTED] mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-current
To unsubscribe, send any mail to [EMAIL PROTECTED]

Re: Ports startup scripts in /etc/rc.d (Re: 5.2-BETA and related ports issues)

Robert Watson wrote:

For 5.2-CURRENT, I think we should revisit this issue with one of the
following conclusions winning out, and the rest being discarded as
flame-bait: 

(1) Combine / and /usr into a single file system by default, and add
/usr/local/etc/rc.d to the search order, with appropriate hacks to
handle old-style scripts.  The devil will be in the bikeshed, but the
implementation is easy, except for the bit where we explain that
NFS-mounted /usr/local won't work too well.
(2) Reevaluate the order at routine points in the boot where new scripts
might now be available (due to file system mounts or whatever).
Essentially insert the new cards into the deck, and shuffle.  This
requires rethinking of our current approach, which assumes a static
order is created once at the start of the boot by rcorder(8).  The
devil will be in the big picture *and* the details of the
implementation.
(3) Add /local/etc/rc.d or /local/rc.d or /etc/local/rc.d or the like, a
new directory that third party applications are allowed to modify
during install, and that will be present for the creation of the
static ordering by rcorder(8) early in the boot.  The devil will be in
the bikeshed, but the implementation is easy.
(4) Continue to ignore the issue and let some ports install into /etc/rc.d
and consider them unorthodox, incorrect, but something we can
overlook.  The devil isn't here, or at least, if it is, we'll overlook
it. 

I'm actually leaning towards (2) as being the best solution, as it's easy
and functional.
Robert N M Watson FreeBSD Core Team, TrustedBSD Projects
[EMAIL PROTECTED]  Senior Research Scientist, McAfee Research
I think this message sums up the options quite nicely.

I like option 2 the best, with option 3 a close second.  I think either 
would be an acceptable compromise.

Option 1 abandons the ability for read-only /usr, which many people 
like.  That and the NFS problems that Robert mentioned should rule this out.

But I like anything over doing nothing (option 4).

Richard Coleman
[EMAIL PROTECTED]
___
[EMAIL PROTECTED] mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-current
To unsubscribe, send any mail to [EMAIL PROTECTED]

bash2 linked dynamically

2003-11-30 Thread Sean McNeil

Hi all,

I just sent email to obrien and I would like to encourage getting the
ports collection changed to link bash dynamically.  Hopefully before 5.2
release.

It was the last frustrating problem I had with getting all the LDAP
stuff working on FreeBSD-current.  bash was displaying:

I have no name!

for the username because it was statically linked.  I've noticed many
emails about this sort of problem, but solutions were difficult to dig
up.  Also, I do not see any reason why bash should remain linked -static
for -current.

Cheers,
Sean


___
[EMAIL PROTECTED] mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-current
To unsubscribe, send any mail to [EMAIL PROTECTED]

Re: Ports startup scripts in /etc/rc.d (Re: 5.2-BETA and related ports issues)