Re: kldload of driver for isa pnp card (cycle two)

[Doug Rabson]

On Sat, 1 Apr 2000, Nikolai Saoukh wrote:

 On Fri, Mar 31, 2000 at 08:55:37PM +0100, Doug Rabson wrote:
 
  I will try to tackle these issues soon. Due to other commitments, this
  won't happen for a few days though.
 
 Can I halp somehow?

After I get the basics working, I'll contact you privately if you want to
test things.

--
Doug Rabson Mail:  [EMAIL PROTECTED]
Nonlinear Systems Ltd.  Phone: +44 181 442 9037




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

Re: PNP dependant configs in /sys/isa/pnpparse.c

[Doug Rabson]

On Sat, 1 Apr 2000, Pierre Y. Dampure wrote:

 
 Since revision 1.5 of the above, my kernel is giving me a "too many dependant
 configs (8)" when probing PNP resources.
 
 Problem is, it looks like the SoundBlaster AWE 64 Gold advertises 8 different
 PNP configurations (at least, that's what I got when i bumped MAXDEP to 16 and
 rebooted in verbose mode).
 
 Is there a set limit to the number of PNP configurations that can be
 advertised? if it's indeed 8, shouldn't the test read:
 
if (ncfgs  MAXDEP) {
 
 rather than
 
if (ncfgs = MAXDEP) {
 
 Comments appreciated...
 

I'll look into it.

--
Doug Rabson Mail:  [EMAIL PROTECTED]
Nonlinear Systems Ltd.  Phone: +44 181 442 9037




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

Re: MLEN and crashes

[Alfred Perlstein]

* Gary Jennejohn [EMAIL PROTECTED] [000402 01:43] wrote:
 This is a HEADS UP.
 
 The recent increase in MLEN from 128 to 256 bytes led to very surprising
 problems with the latest, so called developers',  version of isdn4bsd.
 
 The new version uses slcompress by default. The change in MLEN makes
 struct slcompress 2KB larger than it used to be. BTW the entry csu_hdr
 in struct cstate, which has size MLEN, is not used anywhere in the kernel
 that I could find. csu_hdr is what leads to the increase in the size of
 struct slcompress. There's a comment in slcompress.h which states that
 MAX_HDR should really be defined as 128 and not MLEN. Maybe this should
 be taken to heart and MAX_HDR redefined as 128 and not MLEN.
 
 But I digress.
 
 struct slcompress is now in struct sppp, which is passed by ispppcontrol
 as part of an ioctl call. Eventually the kernel lands in sppp_params,
 which does a copyin to a struct spppreq (which contains struct sppp) on
 the kernel stack. Because struct sppp is 2KB larger as a result of the
 change in MLEN the copyin overruns the kernel stack which immediately
 results in a crash - no trace output, no ddb, zilch.
 Interesting is that the crash only happens on a Pentium (tested with
 a II and III). On a K6 it doesn't happen. AFAICT it's not related to
 using the FPU for copyin/copyout since I turned that functionality
 off using npx0 flags and the crash still happened.
 
 Moving the struct spppreq into global address space solves the problem,
 but that makes the kernel BSS somewhat larger. Redefining MAX_HDR to be
 128 also fixes the problem, even with the struct spppreq on the stack.
 
 If those of you using slcompress start seeing problems then they may well
 be due to the increase in MLEN.
 
 I wonder how wise it was to change MLEN without more testing. But hey,
 this is -current, that's what it's there for.
 
 Anyway, I think MAX_HDR should be hardwired to 128 in slcompress. Any
 comments ?
 

Why not just malloc the structure instread of using a stack variable?

Various other parts of the kernel do so to get around this problem, 
since we're heading up SMP now it _not_ the time to start using
global variables.

-- 
-Alfred Perlstein - [[EMAIL PROTECTED]|[EMAIL PROTECTED]]
"I have the heart of a child; I keep it in a jar on my desk."


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

$B!z%"%$%I%k#2#0#0#1%*!<%W(B(B$B%s!*L5NABN83$b$"$j!z(B(B

[$B%"%$%I%k#2#0#0#1(B(B]

==
$B%"%$%I%k#2#0#0#1%*!<%W%s!*!*(B
==


$B"##R#e#a#l#G#2!!%i%$%V%A%c%C%H?74k2h2q0wBgJg=8!*!*(B
$B!!K\%5%$%H$O!"7n!9$NDj3[NA6b#1#0#0#0#01_$G!"2q0w$K$J$i$l$?3'MM$K$O!"%W(B
$B%m%0%i%`$N%5!<%S%9Cf$G$"$l$P!"$$$/$i$G$b#R#e#a#l#G#2%W%l!<%d$r3hMQ$7$?(B
$B%i%$%V1GA|$G$N%A%c%C%H$,!"3Z$7$`$+$H$,$G$-$^$9!#(B

$B"##1#0J,4VL5NABN83%5!<%S%9!*!*(B
$B!!%5%$%H$,%*!<%W%s$9$k#37n#2#1$h$j!!:G=i$N#1#0J,4V$,$*;n$7BN83$H$7$FL5(B
$BNA$H$J$j$^$9!#(B
$B#1#0J,4V7P$A$^$9$H<+F0E*$K2hLL$,Dd;_$7$^$9$N$G!"8e$GNA6b$r@A5a$9$k$H$$(B
$B$C$?%H%i%V%k$O!"$"$j$^$;$s!#(B

$B"#2q0w$N3'MM8BDj!*8+$k$3$H$N$G$-$J$$%W%i%$%Y!<%H$J1GA|!*!)(B
$B!!%i%$%V%A%c%C%H%W%m%0%i%`%5!<%S%90J30$N;~4VBS$O!"=w$N;R$?$A$N%W%i%$%Y(B
$B!<%H1GA|$r!"$[$H$s$IL5JT=8$N>uBV$G8+$k$3$H$,$G$-$^$9!#(B
$B?o;~!"<}O?$7$??7$7$$$b$N$rA}$d$7$F!"%i%$%V%i%j!<2=$7$F$$$/M=Dj$G$9!#(B


$B"#(B2000$BG/%(%C%=%l!<%9%/!<%s$NHSEg??M3!"(B2000$BG/%V%l%$%/@#A0$N@n0fCN0!5*(B
4$B7n(B6$BF|$+$i=iIqBf$KD)@o$9$k!"@>4]M%;R$i!"7]G=3&$G%a%A%c4hD%$C$F$$$k!"=w(B
$B$N;RC#$,$>$/$>$/EP>l$9$k!"%i%$%V%A%c%C%H$G$9!#(B
$B=w$N;RC#$N%W%m%b!<%7%g%s%S%G%*$O!"$@$l$G$b8+$l$^$9!"$N$G!"@'Hs$N$>$-$K(B
$BMh$F2<$5$$!#%a%s%P!<@lMQ$N?eCe%S%G%*@):nM=DjM-$j!#(B


$B"#(B6$B7n$K$O%*%U2q$r9T$J$$$^$9!#(B
$B%"%$%I%kC#$KD>@\2q$$$KMh$F2<$5$$!#(B
$BR2p$7$F2<$5$$!#(B
$B!!7]G=3&$rL\;X$92D0&$$=w$N;R$r@'Hs>R2p$7$F2<$5$$!#:NMQ$5$;$F$$$?$@$$$?(B
$B>l9g$O!"(B
$B!!FCJLM%6x$5$;$F$$$?$@$-$^$9!#(B


(I%%%$B#I#D#O#L#2#0#0#1(I%%%(B


http://www.leotv.com/idol2001$B!!(B
$B#G#A#L#s%W%m%U%#!<%k$H%i%$%V%A%c%C%H%9%1%8%e!<%k$r$4;2>H$/$@$5$$(B(B


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

Re: MLEN and crashes

[Bruce Evans]

On Sun, 2 Apr 2000, Gary Jennejohn wrote:

 struct slcompress is now in struct sppp, which is passed by ispppcontrol
 as part of an ioctl call. Eventually the kernel lands in sppp_params,
 which does a copyin to a struct spppreq (which contains struct sppp) on
 the kernel stack. Because struct sppp is 2KB larger as a result of the
 change in MLEN the copyin overruns the kernel stack which immediately
 results in a crash - no trace output, no ddb, zilch.

It's just a bug to allocate big structs on the kernel stack.  Almost
all structs are too big for utility routines.  Top levels of syscall
routines and a few other routines that are known not to be called
from deep in the kernel stack can use moderately big structs.  512
bytes is probably too big for i386's now.  The effective kernel stack
size was shrunk by about 2K by the sigset_t changes, so there is only
about 5K of kernel stack.

 Interesting is that the crash only happens on a Pentium (tested with
 a II and III). On a K6 it doesn't happen. AFAICT it's not related to
 using the FPU for copyin/copyout since I turned that functionality
 off using npx0 flags and the crash still happened.

The behaviour is unpredictable.  Severe cases will be detected as a
double fault if you're lucky.  The sigset_t changes gave an extra 2K
of signal variables to clobber before there is a double fault :-).

 Moving the struct spppreq into global address space solves the problem,
 but that makes the kernel BSS somewhat larger. Redefining MAX_HDR to be
 128 also fixes the problem, even with the struct spppreq on the stack.

Big structs need to be malloced.

I think removing the unused bloat in `struct cstate' is the correct fix
for this particular allocation.

Bruce



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

Re: JetDirect 500X and FreeBSD

[Alexander Langer]

Thus spake Andrew MacIntyre ([EMAIL PROTECTED]):

 they weren't particularly reliable, particularly when multiple jobs were
 queued simultaneously.  I hope their more recent stuff is better behaved.

It is now.

A further thing is: If your LaserJet doesn't understand PostScript,
you have to use apsfilter.

I do it this way here at home, the Windows-boxes use the JetDirect
directly (the Windows software is REALLY nice!)

Alex


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

Re: Deadlock with vinum raid5

[Vallo Kallaste]

On Sun, Apr 02, 2000 at 01:50:16AM +0200, Bernd Walter [EMAIL PROTECTED] wrote:

  Greg - I'm using vinums raid5 code since months now for FreeBSDs CVS-Tree on
  7x 200M disks - it does not hang for me since a long time.
  The latest current I tested R5 well is from 19th March on alpha. That's shortly
  before PHKs changes - I don't beleave that it introduced something new.
  The only problem with R5 I know of is parity corruption because of a bug in
  lockrange() for which I've already send you a fix. Even it is a general bug it
  seems only to cause problems together with softupdates.
 
 Ops - I oversaw that this happened with a recent current.
 The best I can say is that it is likely that it happened after the 19th March.

I got now crash under 4.0-RELEASE, with syncer and bufdaemon in the same
vrlock state, pax in flswait. I was in single-user mode using pax to
extract usr archive to newly created raid5 volume. I'm using NFS mount
with flags -3i -r16384 -w16384 over 100Mbit full-duplex link, fxp
driver on both sides. Note that I'm using stripe unit size 512k now,
otherwise same.

Here's handcopy of DDB messages:

Fatal trap 12: page fault while in kernel mode
fault virtual address   = 0x4
fault code  = supervisor read, page not present
instruction pointer = 0x8:0xc1e03ef4
stack pointer   = 0x10:0xc0244a84
frame pointer   = 0x10:0xc0244aa0
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 = Idle
interrupt mask  = bio
kernel: type 12 trap, code=0
Stopped at  complete_rqe+0x18:  movl0x4(%eax),%edx
db trace
complete_rqeat complete_rqe+0x18
biodone at biodone+0x53
ad_interruptat ad_interrupt+0x2e2
ata_intrat ata_intr+0xca
Xresume15() at Xresume15+0x2b
--- interrupt, eip = 0xc020e5ae, esp = 0xc0244b54, ebp = 0 ---
default_halt() at default_halt+0x2

I hook up serial console to get full traceback next time, but I don't
have any knowledge for further analysis.
-- 

Vallo Kallaste
[EMAIL PROTECTED]


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

Summer/winter time problems with daily/460

[Jeroen Ruigrok/Asmodai]

Just went through a few logfiles:

Checking for rejected mail hosts:
-1d: Cannot apply date adjustment
usage: date [-nu] [-d dst] [-r seconds] [-t west] [-v[+|-]val[ymwdHMS]] ...  
[-f fmt date | [cc]yy]mm]dd]HH]MM[.ss]] [+format]

Someone more acquainted with the daily scripts may want to
investigate/fix that.

-- 
Jeroen Ruigrok vd Werven/Asmodaiasmodai@[wxs.nl|bart.nl|freebsd.org]
Documentation nutter/C-rated Coder BSD: Technical excellence at its best  
The BSD Programmer's Documentation Project http://home.wxs.nl/~asmodai
Veni, Vidi, Vici...


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

Please review newbus patch for amd and adv

[Takahashi Yoshihiro]

I converted the amd and adv drivers to new-bus. But, as I am not
familiar with these drivers and new-bus, maybe I have mistaken.

Will somebody please review these changes?

For amd driver:
http://home.jp.FreeBSD.org/~nyan/patches/amd.diff.gz

For adv driver:
http://home.jp.FreeBSD.org/~nyan/patches/advansys.diff.gz

---
Takahashi Yoshihiro
The Center for Information Science, Kogakuin Univ.


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

Re: MLEN and crashes

[Louis A. Mamakos]

 I wonder how wise it was to change MLEN without more testing. But hey,
 this is -current, that's what it's there for.

I've been running with MLEN set to 256 bytes for more than a year for
reasons unrelated to this commit, and haven't seen any problems at all.
(Of course, I don't use sppp..)  It's unclear how this could have been
caught by more testing unless the tester was using sppp.

louie





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

Buffering issues of the pcm audio driver (Was: cvs commit: src/sys/dev/sound/isa ess.c)

[Maxim Sobolev]

Hi,

I've tried to track down sound issues of the SDL (Simple Direct Layer)
library and found that current pcm buffering behaviour inconsistent with
OSS specifications, which cause applications that require sophisticated
sound control to misbehave on FreeBSD.

There is two different buffers implemented in the pcm driver: one
back-end, with size specified an a compile time (ranging from 4KB to
64KB on different chipsets), and one front-end size of which could be
changed by the audio application at runtime. Problems arises when
application tries to get current state of the audio buffer either by
using select(), or by doing direct SNDCTL_DSP_GETOSPACE ioctl(). In both
these cases current FreeBSD behaviour isn't consistent with OSS specs:

- the SNDCTL_DSP_GETOSPACE ioctl() returns current state of the front
buffer, while   ignores much larger back buffer which usually absorbs
all data sent to the pcm. Thus application using this ioctl() being
fooled about how much data is in the audio buffers.

- the select() call doesn't block until the whole back buffer will be
filled, while   according to specs it should block while
fragsize*fragnumber amount of data already is in the buffers.

Possible solution (from better to worse):

1. Fix select() support in the pcm driver to account effects of the two
buffers.
2. Provide workaround to the SNDCTL_DSP_GETOSPACE to return largest free
bufferspace available in either front or back buffer. Thus aware
applications would havea possibility to check how much data is in
hardware buffers and behave accordingly.This will not violate OSS
specs, as it is permitted to have this value larger than
fragsize*fragments. See attached diffs.
3. Decrease size of the back buffers in all pcm drivers to a some
reasonable value like 4KB.


-Maxim



--- /usr/src/sys/dev/sound/pcm/dsp.c2000/04/02 09:41:26 1.1
+++ /usr/src/sys/dev/sound/pcm/dsp.c2000/04/02 09:49:56
@@ -467,8 +467,8 @@
chn_checkunderflow(wrch);
while (chn_wrfeed(wrch)  0);
}
-   a-bytes = bs-fl;
-   a-fragments = a-bytes / wrch-blocksize2nd;
+   a-bytes = (bs-fl  b-fl ? bs-fl : b-fl);
+   a-fragments = bs-fl / wrch-blocksize2nd;
a-fragstotal = bs-bufsize / wrch-blocksize2nd;
a-fragsize = wrch-blocksize2nd;
}

Re: Deadlock with vinum raid5

[Vallo Kallaste]

On Sun, Apr 02, 2000 at 03:39:35PM +0200, Vallo Kallaste [EMAIL PROTECTED] 
wrote:

 I hook up serial console to get full traceback next time, but I don't
 have any knowledge for further analysis.

Here's full traceback, environment is all same, except the filesystem is
mounted with async (before it was default, which is nosync I guess):

sh-2.03# cd /usr
sh-2.03# pax -r -pe -f /mnt/usr.pax 


Fatal trap 12: page fault while in kernel mode
fault virtual address   = 0x4
fault code  = supervisor read, page not present
instruction pointer = 0x8:0xc0fa0ef4
stack pointer   = 0x10:0xc0244a84
frame pointer   = 0x10:0xc0244aa0
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 = Idle
interrupt mask  = bio 
kernel: type 12 trap, code=0
Stopped at  complete_rqe+0x18:  movl0x4(%eax),%edx
db trace
complete_rqe(c1069020,c0f04000,c1882f00,0,c1882f00) at complete_rqe+0x18
biodone(c1069020,c0f04034,c1069020,c0ed4180,0) at biodone+0x53
ad_interrupt(c1882f00,0,0,c02051e5,c0ed4180) at ad_interrupt+0x2e2
ata_intr(c0ed4180,0,c00f0010,c0690010,0010) at ata_intr+0xca
Xresume14() at Xresume14+0x2b
--- interrupt, eip = 0xc020e5ae, esp = 0xc0244b54, ebp = 0 ---
default_halt() at default_halt+0x2
db ps
  pid   proc addruid  ppid  pgrp  flag stat wmesg   wchan   cmd
   40 cc3a5440 cd7470000 640 004006  3  getblk c62d1cd0 pax
   15 cc3a5100 cd74d0000 115 000204  3   vinum c0fa0b68 vinum
6 cc3a55e0 cd7440000 1 6 004086  3wait cc3a55e0 bash
5 cc3a5780 cc3b20000 0 0 000204  3  vrlock   52f801 syncer
4 cc3a5920 cc3b0 0 0 100204  3  vrlock   582001 bufdaemon
3 cc3a5ac0 cc3ae0000 0 0 000204  3  psleep c026c3c0 vmdaemon
2 cc3a5c60 cc3ac0000 0 0 100204  3  psleep c0254df8 pagedaemon
1 cc3a5e00 cc3aa0000 0 1 004284  3wait cc3a5e00 init
0 c0274640 c02d20000 0 0 000204  3   sched c0274640 swapper
db 

I can give access to my system which is connected over null-modem to
this test box.
-- 

Vallo Kallaste
[EMAIL PROTECTED]


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

Re: Deadlock with vinum raid5

[Bernd Walter]

On Sun, Apr 02, 2000 at 03:39:35PM +0200, Vallo Kallaste wrote:
 I got now crash under 4.0-RELEASE, with syncer and bufdaemon in the same
 vrlock state, pax in flswait. I was in single-user mode using pax to
 extract usr archive to newly created raid5 volume. I'm using NFS mount
 with flags -3i -r16384 -w16384 over 100Mbit full-duplex link, fxp
 driver on both sides. Note that I'm using stripe unit size 512k now,
 otherwise same.
 
 I hook up serial console to get full traceback next time, but I don't
 have any knowledge for further analysis.

You don't need a serial console to get further informations.
You should compile the kernel with debug symbols and set dumpdev in rc.conf
to get a crash dump.

Are you for any chance running the NFS Server without nfsd?
I expect them to be needed if you are serving vinum volumes.

-- 
B.Walter  COSMO-Project  http://www.cosmo-project.de
[EMAIL PROTECTED] Usergroup[EMAIL PROTECTED]



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

Re: Deadlock with vinum raid5

[Soren Schmidt]

It seems Vallo Kallaste wrote:
 On Sun, Apr 02, 2000 at 03:39:35PM +0200, Vallo Kallaste [EMAIL PROTECTED] 
wrote:
 
  I hook up serial console to get full traceback next time, but I don't
  have any knowledge for further analysis.
 
 Here's full traceback, environment is all same, except the filesystem is
 mounted with async (before it was default, which is nosync I guess):
 
 sh-2.03# cd /usr
 sh-2.03# pax -r -pe -f /mnt/usr.pax 

This the exact problem I'm seeing here.
Turning on INVARIANTS in the kernel shows that free'd malloc space
are being reused when vinum is in the game :( 

 Fatal trap 12: page fault while in kernel mode
 fault virtual address   = 0x4
 fault code  = supervisor read, page not present
 instruction pointer = 0x8:0xc0fa0ef4
 stack pointer   = 0x10:0xc0244a84
 frame pointer   = 0x10:0xc0244aa0
 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 = Idle
 interrupt mask  = bio 
 kernel: type 12 trap, code=0
 Stopped at  complete_rqe+0x18:  movl0x4(%eax),%edx
 db trace
 complete_rqe(c1069020,c0f04000,c1882f00,0,c1882f00) at complete_rqe+0x18
 biodone(c1069020,c0f04034,c1069020,c0ed4180,0) at biodone+0x53
 ad_interrupt(c1882f00,0,0,c02051e5,c0ed4180) at ad_interrupt+0x2e2
 ata_intr(c0ed4180,0,c00f0010,c0690010,0010) at ata_intr+0xca
 Xresume14() at Xresume14+0x2b
 --- interrupt, eip = 0xc020e5ae, esp = 0xc0244b54, ebp = 0 ---
 default_halt() at default_halt+0x2
 db ps
   pid   proc addruid  ppid  pgrp  flag stat wmesg   wchan   cmd
40 cc3a5440 cd7470000 640 004006  3  getblk c62d1cd0 pax
15 cc3a5100 cd74d0000 115 000204  3   vinum c0fa0b68 vinum
 6 cc3a55e0 cd7440000 1 6 004086  3wait cc3a55e0 bash
 5 cc3a5780 cc3b20000 0 0 000204  3  vrlock   52f801 syncer
 4 cc3a5920 cc3b0 0 0 100204  3  vrlock   582001 bufdaemon
 3 cc3a5ac0 cc3ae0000 0 0 000204  3  psleep c026c3c0 vmdaemon
 2 cc3a5c60 cc3ac0000 0 0 100204  3  psleep c0254df8 pagedaemon
 1 cc3a5e00 cc3aa0000 0 1 004284  3wait cc3a5e00 init
 0 c0274640 c02d20000 0 0 000204  3   sched c0274640 swapper
 db 
 
 I can give access to my system which is connected over null-modem to
 this test box.
 -- 
 
 Vallo Kallaste
 [EMAIL PROTECTED]
 


-Søren


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

Re: Deadlock with vinum raid5

[Bernd Walter]

On Sun, Apr 02, 2000 at 01:50:16AM +0200, Bernd Walter wrote:
 On Sun, Apr 02, 2000 at 01:15:39AM +0200, Bernd Walter wrote:
  
  Greg - I'm using vinums raid5 code since months now for FreeBSDs CVS-Tree on
  7x 200M disks - it does not hang for me since a long time.
  The latest current I tested R5 well is from 19th March on alpha. That's shortly
  before PHKs changes - I don't beleave that it introduced something new.
  The only problem with R5 I know of is parity corruption because of a bug in
  lockrange() for which I've already send you a fix. Even it is a general bug it
  seems only to cause problems together with softupdates.
 
 Ops - I oversaw that this happened with a recent current.
 The best I can say is that it is likely that it happened after the 19th March.

I build a recent current and tested it with R5 and still don't see any hangs.
Unfortunately I don't have a toy i386 system ready and testet on alpha.
There may be some differences how data corruptions efects on this platform.

-- 
B.Walter  COSMO-Project  http://www.cosmo-project.de
[EMAIL PROTECTED] Usergroup[EMAIL PROTECTED]



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

Re: Deadlock with vinum raid5

[Bernd Walter]

On Sun, Apr 02, 2000 at 05:37:30PM +0200, Bernd Walter wrote:
 Are you for any chance running the NFS Server without nfsd?
 I expect them to be needed if you are serving vinum volumes.

Sometimes I'm to stupid - the NFS case was a different thread.

-- 
B.Walter  COSMO-Project  http://www.cosmo-project.de
[EMAIL PROTECTED] Usergroup[EMAIL PROTECTED]



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

Re: Deadlock with vinum raid5

[Bernd Walter]

On Sun, Apr 02, 2000 at 05:38:01PM +0200, Soren Schmidt wrote:
 It seems Vallo Kallaste wrote:
  On Sun, Apr 02, 2000 at 03:39:35PM +0200, Vallo Kallaste [EMAIL PROTECTED] 
wrote:
  
   I hook up serial console to get full traceback next time, but I don't
   have any knowledge for further analysis.
  
  Here's full traceback, environment is all same, except the filesystem is
  mounted with async (before it was default, which is nosync I guess):
  
  sh-2.03# cd /usr
  sh-2.03# pax -r -pe -f /mnt/usr.pax 
 
 This the exact problem I'm seeing here.
 Turning on INVARIANTS in the kernel shows that free'd malloc space
 are being reused when vinum is in the game :( 

Do you see it only with R5 or also with other organisations?

-- 
B.Walter  COSMO-Project  http://www.cosmo-project.de
[EMAIL PROTECTED] Usergroup[EMAIL PROTECTED]



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

Re: Deadlock with vinum raid5

[Soren Schmidt]

It seems Bernd Walter wrote:
 On Sun, Apr 02, 2000 at 05:38:01PM +0200, Soren Schmidt wrote:
  It seems Vallo Kallaste wrote:
   On Sun, Apr 02, 2000 at 03:39:35PM +0200, Vallo Kallaste 
[EMAIL PROTECTED] wrote:
   
I hook up serial console to get full traceback next time, but I don't
have any knowledge for further analysis.
   
   Here's full traceback, environment is all same, except the filesystem is
   mounted with async (before it was default, which is nosync I guess):
   
   sh-2.03# cd /usr
   sh-2.03# pax -r -pe -f /mnt/usr.pax 
  
  This the exact problem I'm seeing here.
  Turning on INVARIANTS in the kernel shows that free'd malloc space
  are being reused when vinum is in the game :( 
 
 Do you see it only with R5 or also with other organisations?

I've only tried RAID5, thats the one I have a use for...

-Søren


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

GDB 5...

[Mirko Viviani]

Ciao.

As stated in gdb mlist, gdb 5.0 is on the way but it hasn't support for  
freebsd-elf in
the package. Is there anyone that could explain me why ?

Thanks.

---
Bye,
 Mirko  [EMAIL PROTECTED]   (NeXTmail, MIME)
[EMAIL PROTECTED]


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

Re: GDB 5...

[Kris Kennaway]

On Sun, 2 Apr 2000, Mirko Viviani wrote:

 Ciao.
 
 As stated in gdb mlist, gdb 5.0 is on the way but it hasn't support for  
 freebsd-elf in
 the package. Is there anyone that could explain me why ?

You're more likely to get an answer by asking the gdb developers on the
gdb "mlist" :-)

Kris


In God we Trust -- all others must submit an X.509 certificate.
-- Charles Forsythe [EMAIL PROTECTED]



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

Re: MLEN and crashes

[Gary Jennejohn]

Bruce Evans writes:
On Sun, 2 Apr 2000, Gary Jennejohn wrote:
 Moving the struct spppreq into global address space solves the problem,
 but that makes the kernel BSS somewhat larger. Redefining MAX_HDR to be
 128 also fixes the problem, even with the struct spppreq on the stack.

Big structs need to be malloced.


Yes, but how does one know that a struct is too big ? Before the increase
in MLEN strucct sppp was not too big.

I think removing the unused bloat in `struct cstate' is the correct fix
for this particular allocation.


I think we should nuke csu_hdr since it's not used anywhere. Is that
what you really mean ?

---
Gary Jennejohn / [EMAIL PROTECTED] [EMAIL PROTECTED] [EMAIL PROTECTED]




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

Re: Deadlock with vinum raid5

[Vallo Kallaste]

On Sun, Apr 02, 2000 at 05:37:30PM +0200, Bernd Walter [EMAIL PROTECTED] wrote:

  I hook up serial console to get full traceback next time, but I don't
  have any knowledge for further analysis.
 
 You don't need a serial console to get further informations.
 You should compile the kernel with debug symbols and set dumpdev in rc.conf
 to get a crash dump.
 
 Are you for any chance running the NFS Server without nfsd?
 I expect them to be needed if you are serving vinum volumes.

Yes, but I don't have space for crashdump and I can't build new kernel
with limited memory usage because I don't have /usr filesystem up and
running. Is there a way to limit memory usage without recompiling
kernel? I can store 32MB crashdump at the moment, no separate /var
filesystem because I thought 4.0-RELEASE will be stable enough for
experimenting with vinum..
I don't have another 4.0-RELEASE or stable system but I'll try to build
4.0-R kernel on -current system.
-- 

Vallo Kallaste
[EMAIL PROTECTED]


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

Re: Deadlock with vinum raid5

[Vallo Kallaste]

On Sun, Apr 02, 2000 at 06:16:43PM +0200, Bernd Walter [EMAIL PROTECTED] wrote:

 Do you see it only with R5 or also with other organisations?

I don't have any problems with my own -current system which has striped
volume over three UW SCSI disks. SCSI-only system, SMP.
Sources from March 14.
I had no problems with striped volume over two ATA disks in the first
round with test box, then I added the two disks, configured raid5 and
here we are 8-)
-- 

Vallo Kallaste
[EMAIL PROTECTED]


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

Re: Deadlock with vinum raid5

[Bernd Walter]

On Sun, Apr 02, 2000 at 08:02:54PM +0200, Vallo Kallaste wrote:
 Yes, but I don't have space for crashdump and I can't build new kernel
 with limited memory usage because I don't have /usr filesystem up and
 running. Is there a way to limit memory usage without recompiling
 kernel? I can store 32MB crashdump at the moment, no separate /var
 filesystem because I thought 4.0-RELEASE will be stable enough for
 experimenting with vinum..
 I don't have another 4.0-RELEASE or stable system but I'll try to build
 4.0-R kernel on -current system.

Just to clearify the things...
Are these problems with 4.0-RELEASE with 4.0-STABLE or with 5.0-CURRENT?

-- 
B.Walter  COSMO-Project  http://www.cosmo-project.de
[EMAIL PROTECTED] Usergroup[EMAIL PROTECTED]



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

Re: Deadlock with vinum raid5

[Soren Schmidt]

It seems Bernd Walter wrote:
 On Sun, Apr 02, 2000 at 08:02:54PM +0200, Vallo Kallaste wrote:
  Yes, but I don't have space for crashdump and I can't build new kernel
  with limited memory usage because I don't have /usr filesystem up and
  running. Is there a way to limit memory usage without recompiling
  kernel? I can store 32MB crashdump at the moment, no separate /var
  filesystem because I thought 4.0-RELEASE will be stable enough for
  experimenting with vinum..
  I don't have another 4.0-RELEASE or stable system but I'll try to build
  4.0-R kernel on -current system.
 
 Just to clearify the things...
 Are these problems with 4.0-RELEASE with 4.0-STABLE or with 5.0-CURRENT?

I have the problem with 4.0-RELEASE, STABLE and 5.0-current but it 
might only occur with RAID5...

-Søren


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

Re: Deadlock with vinum raid5

[Alfred Perlstein]

* Soren Schmidt [EMAIL PROTECTED] [000402 12:42] wrote:
 It seems Bernd Walter wrote:
  On Sun, Apr 02, 2000 at 08:02:54PM +0200, Vallo Kallaste wrote:
   Yes, but I don't have space for crashdump and I can't build new kernel
   with limited memory usage because I don't have /usr filesystem up and
   running. Is there a way to limit memory usage without recompiling
   kernel? I can store 32MB crashdump at the moment, no separate /var
   filesystem because I thought 4.0-RELEASE will be stable enough for
   experimenting with vinum..
   I don't have another 4.0-RELEASE or stable system but I'll try to build
   4.0-R kernel on -current system.
  
  Just to clearify the things...
  Are these problems with 4.0-RELEASE with 4.0-STABLE or with 5.0-CURRENT?
 
 I have the problem with 4.0-RELEASE, STABLE and 5.0-current but it 
 might only occur with RAID5...

I've never seen it with just a striped setup:

# Vinum configuration of thumper, saved at Sun Apr  2 16:34:43 2000
drive vinumdrive1 device /dev/da0s1e
drive vinumdrive2 device /dev/da1s1e
volume vinum0
plex name vinum0.p0 org striped 512s vol vinum0 
sd name vinum0.p0.s0 drive vinumdrive1 plex vinum0.p0 len 16782848s driveoffset 265s 
plexoffset 0s
sd name vinum0.p0.s1 drive vinumdrive2 plex vinum0.p0 len 16782848s driveoffset 265s 
plexoffset 512s

just FYI.

Have any of you guys running vinum had any problems with phk's recent
patches with bio?  Just wanted to know if I should take the plunge.

-- 
-Alfred Perlstein - [[EMAIL PROTECTED]|[EMAIL PROTECTED]]
"I have the heart of a child; I keep it in a jar on my desk."


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

Re: Deadlock with vinum raid5

[Soren Schmidt]

It seems Alfred Perlstein wrote:
   Just to clearify the things...
   Are these problems with 4.0-RELEASE with 4.0-STABLE or with 5.0-CURRENT?
  
  I have the problem with 4.0-RELEASE, STABLE and 5.0-current but it 
  might only occur with RAID5...
 
 I've never seen it with just a striped setup:
 Have any of you guys running vinum had any problems with phk's recent
 patches with bio?  Just wanted to know if I should take the plunge.

I dont think vinum is/was usable under -current at least not the 
RAID5 stuff, its broken, and some of it is because greg is not
up to date with what -current looks like these days.

-Søren


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

Re: RSA library problems

[Dirk Roehrdanz]

Hi Jim,

On  0, Jim Bloom [EMAIL PROTECTED] wrote:
 A similar patch was added for the USA version of RSA for the same basic reason.
 Your patch is almost correct.  It should add the line:
 
 LDADD+=   -L$[.OBJDIR]/../libcrypto -lcrypto
   ^   ^ 
 
 Your version would reference the system crypto library and not the one being
 built as part of buildworld.
 
 Jim Bloom
 [EMAIL PROTECTED]
 
Thanks for the modification.
I have replaced the "[]" with "{}" . A run of "make buildworld" with
the patch finished without errors.
The output of objdump --private-headers on the created librsaINTL.so.1 
libs  under /usr/obj contains now the line "NEEDED libcrypto.so.1".
Apache-modssl works now  with encryption!

Should I file a pr  with the patch ?

Regards
Dirk


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

Re: Deadlock with vinum raid5

[Bernd Walter]

On Sun, Apr 02, 2000 at 09:39:36PM +0200, Soren Schmidt wrote:
 I dont think vinum is/was usable under -current at least not the 
 RAID5 stuff, its broken, and some of it is because greg is not
 up to date with what -current looks like these days.

Can you please explain what have massivly changed in current that relates
to vinum?

-- 
B.Walter  COSMO-Project  http://www.cosmo-project.de
[EMAIL PROTECTED] Usergroup[EMAIL PROTECTED]



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

Re: Deadlock with vinum raid5

[Soren Schmidt]

It seems Bernd Walter wrote:
 On Sun, Apr 02, 2000 at 09:39:36PM +0200, Soren Schmidt wrote:
  I dont think vinum is/was usable under -current at least not the 
  RAID5 stuff, its broken, and some of it is because greg is not
  up to date with what -current looks like these days.
 
 Can you please explain what have massivly changed in current that relates
 to vinum?

The changes done by phk to seperate out the io stuff from struct buf.

-Søren


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

Perl 5.6.0?

[Thomas T. Veldhouse]

Are there any plans to merge perl-5.6.0 into current?  I don't have any
plans for using it currently, but I curious.

Thanks,

Tom Veldhouse
[EMAIL PROTECTED]



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

Re: Perl 5.6.0?

[Chuck Robey]

On Sun, 2 Apr 2000, Thomas T. Veldhouse wrote:

 Are there any plans to merge perl-5.6.0 into current?  I don't have any
 plans for using it currently, but I curious.

Hmm.  What with the nightmarish build structure of perl, I'm sure that
reading this is just going to wreck Mark's day.  In light of that, and in
the absence of both any real software that needs the upgrade, and
lack of confidence in a really squeaky new release, why don't we all grant
Mark a little slack on this, at least for a while.

Else we're going to have a drooling Mark on our hands :-)

Unless, of course, you want to do it *for* Mark?

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


Chuck Robey| Interests include C  Java programming, FreeBSD,
[EMAIL PROTECTED]  | electronics, communications, and signal processing.

New Year's Resolution:  I will not sphroxify gullible people into looking up
fictitious words in the dictionary.




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

Re: Deadlock with vinum raid5

[Alfred Perlstein]

* Soren Schmidt [EMAIL PROTECTED] [000402 13:05] wrote:
 It seems Alfred Perlstein wrote:
Just to clearify the things...
Are these problems with 4.0-RELEASE with 4.0-STABLE or with 5.0-CURRENT?
   
   I have the problem with 4.0-RELEASE, STABLE and 5.0-current but it 
   might only occur with RAID5...
  
  I've never seen it with just a striped setup:
  Have any of you guys running vinum had any problems with phk's recent
  patches with bio?  Just wanted to know if I should take the plunge.
 
 I dont think vinum is/was usable under -current at least not the 
 RAID5 stuff, its broken, and some of it is because greg is not
 up to date with what -current looks like these days.

Took a chance...

So far my make world is proceeding fine with a kernel from ~1 hour
ago.  However I'm only using vinum for striping, not mirroring or
RAID-5.

-- 
-Alfred Perlstein - [[EMAIL PROTECTED]|[EMAIL PROTECTED]]
"I have the heart of a child; I keep it in a jar on my desk."


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

Re: Deadlock with vinum raid5

[Greg Lehey]

On Sunday,  2 April 2000 at 22:22:39 +0200, Søren Schmidt wrote:
 It seems Bernd Walter wrote:
 On Sun, Apr 02, 2000 at 09:39:36PM +0200, Soren Schmidt wrote:
 I dont think vinum is/was usable under -current at least not the
 RAID5 stuff, its broken, and some of it is because greg is not
 up to date with what -current looks like these days.

 Can you please explain what have massivly changed in current that relates
 to vinum?

 The changes done by phk to seperate out the io stuff from struct
 buf.

Alfred and Bernd came up with fixes that seem to work.  I still need
to review them, but I'm in the process of installing an up-to-date
-CURRENT on my test box.  Watch this space.

Greg
--
Finger [EMAIL PROTECTED] for PGP public key
See complete headers for address and phone numbers


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

Re: Deadlock with vinum raid5

[Greg Lehey]

On Sunday,  2 April 2000 at 17:42:16 +0200, Bernd Walter wrote:
 On Sun, Apr 02, 2000 at 01:50:16AM +0200, Bernd Walter wrote:
 On Sun, Apr 02, 2000 at 01:15:39AM +0200, Bernd Walter wrote:

 Greg - I'm using vinums raid5 code since months now for FreeBSDs CVS-Tree on
 7x 200M disks - it does not hang for me since a long time.
 The latest current I tested R5 well is from 19th March on alpha. That's shortly
 before PHKs changes - I don't beleave that it introduced something new.
 The only problem with R5 I know of is parity corruption because of a bug in
 lockrange() for which I've already send you a fix. Even it is a general bug it
 seems only to cause problems together with softupdates.

 Ops - I oversaw that this happened with a recent current.
 The best I can say is that it is likely that it happened after the 19th March.

 I build a recent current and tested it with R5 and still don't see any hangs.
 Unfortunately I don't have a toy i386 system ready and testet on alpha.
 There may be some differences how data corruptions efects on this platform.

I found a potentially serious bug in the RAID calculations yesterday:
it assumed that sizeof (int) == 4.  I suspect that it would just slow
down the calculations, but in any case I've fixed it.

Greg
--
Finger [EMAIL PROTECTED] for PGP public key
See complete headers for address and phone numbers


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

Re: Deadlock with vinum raid5

[Matthew Dillon]

: to vinum?
:
: The changes done by phk to seperate out the io stuff from struct
: buf.
:
:Alfred and Bernd came up with fixes that seem to work.  I still need
:to review them, but I'm in the process of installing an up-to-date
:-CURRENT on my test box.  Watch this space.
:
:Greg

I won't mess with the buffer allocation idea until after you've
stabilized vinum.

-Matt
Matthew Dillon 
[EMAIL PROTECTED]


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

Re: Deadlock with vinum raid5

[Bernd Walter]

On Mon, Apr 03, 2000 at 07:41:54AM +0930, Greg Lehey wrote:
 On Sunday,  2 April 2000 at 22:22:39 +0200, Søren Schmidt wrote:
  It seems Bernd Walter wrote:
  On Sun, Apr 02, 2000 at 09:39:36PM +0200, Soren Schmidt wrote:
  I dont think vinum is/was usable under -current at least not the
  RAID5 stuff, its broken, and some of it is because greg is not
  up to date with what -current looks like these days.
 
  Can you please explain what have massivly changed in current that relates
  to vinum?
 
  The changes done by phk to seperate out the io stuff from struct
  buf.

Yes but as the time being he only did some small changes as a preparation
for the bigger ones still coming.
If that were massivly changes I can't imagine the words to describe what
the future brings...

 Alfred and Bernd came up with fixes that seem to work.  I still need
 to review them, but I'm in the process of installing an up-to-date
 -CURRENT on my test box.  Watch this space.

I'm running current with striped and R5 on alpha and Niels Chr. Bank-Pedersen
checked this for striping on i386 - I asume Alfred also did.
Afaik no degraded R5 tests yet but they should work as before.

-- 
B.Walter  COSMO-Project  http://www.cosmo-project.de
[EMAIL PROTECTED] Usergroup[EMAIL PROTECTED]



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

Re: Deadlock with vinum raid5

[Bernd Walter]

On Mon, Apr 03, 2000 at 07:43:00AM +0930, Greg Lehey wrote:
 I found a potentially serious bug in the RAID calculations yesterday:
 it assumed that sizeof (int) == 4.  I suspect that it would just slow
 down the calculations, but in any case I've fixed it.

That's generaly not good but allways true on all FreeBSD platforms.
Only long and pointers are different: 64bit on alpha and 32bit on i386 -
char short and int are the same.
I asume you mean the xor loop limitations - I already took a look at them
before running R5 on alpha - the only reason to change here is speed as 64bit
operations would be faster on alpha.

-- 
B.Walter  COSMO-Project  http://www.cosmo-project.de
[EMAIL PROTECTED] Usergroup[EMAIL PROTECTED]



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

kernel build busted in /sys/dev/sound/pci/emu10k1.c (fix included)

[Josh Tiefenbach]

In attempting to test out Cameron's emu10k1 support, one quickly notices that
the build dies in $SUBJECT due to unresolved constants.

The attached patch fixes the problem. I'm happy to report that mpg123 is
playing mp3's quite fine. There's a little burst of static when it first
starts up, but other than that, things look fine for me.

josh

-- 
Give me rampant intellectualism as a coping strategy!
   -- Chuck Palahniuk in Invisible Monsters


--- emu10k1.h   Sun Apr  2 03:41:17 2000
+++ /tmp/emu10k1.h  Sun Apr  2 19:01:32 2000
@@ -663,4 +663,12 @@
 #define HIWORD_RESULT_MASK 0x000ffc00  /* Instruction result  
 */
 #define HIWORD_OPA_MASK0x03ff  /* Instruction operand A   
 */
 
+/* Following constants lifted from Creative's hwaccess.h file */
+/* Needed to get emu10k1.c rev 1.1 to compile */
+#define ENABLE 0x
+#define DISABLE 0x
+
+#define ENV_ON 0x80
+#define ENV_OFF 0x00
+
 #endif /* _8010_H */

Re: cvs commit: src/sys/i386/i386 support.s src/sys/kern init_sysent.c kern_prot.c kern_sig.c

[Alfred Perlstein]

* Matt Dillon [EMAIL PROTECTED] [000402 11:18] wrote:
 dillon  2000/04/02 10:52:44 PDT
 
   Modified files:
 sys/i386/i386support.s 
 sys/kern init_sysent.c kern_prot.c kern_sig.c 
   Log:
   Make the sigprocmask() and geteuid() system calls MP SAFE.  Expand
   commentary for copyin/copyout to indicate that they are MP SAFE as
   well.

Along with snagging the "easy ones" for MP safeness, shouldn't getpid
be MP safe?  The struct proc is allocated from the proc_zone, and
afaik zalloc allows for stable storage meaning it's safe to dereference
the ppid pointer once the entire struct proc is populated, which needs
to happen before the process can even call getpid().

phk seems to agree.

-- 
-Alfred Perlstein - [[EMAIL PROTECTED]|[EMAIL PROTECTED]]
"I have the heart of a child; I keep it in a jar on my desk."


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

Re: cvs commit: src/sys/i386/i386 support.s src/sys/kern init_sysent.c kern_prot.c kern_sig.c

[Matthew Dillon]

:Along with snagging the "easy ones" for MP safeness, shouldn't getpid
:be MP safe?  The struct proc is allocated from the proc_zone, and
:afaik zalloc allows for stable storage meaning it's safe to dereference
:the ppid pointer once the entire struct proc is populated, which needs
:to happen before the process can even call getpid().
:
:phk seems to agree.
:
:-- 
:-Alfred Perlstein - [[EMAIL PROTECTED]|[EMAIL PROTECTED]]
:"I have the heart of a child; I keep it in a jar on my desk."

The problem is that getpid() also extracts the ppid (look at
the syscall code), which is not MP safe.

-Matt
Matthew Dillon 
[EMAIL PROTECTED]


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

Re: cvs commit: src/sys/i386/i386 support.s src/sys/kern init_sysent.c kern_prot.c kern_sig.c

[Alfred Perlstein]

* Matthew Dillon [EMAIL PROTECTED] [000402 16:37] wrote:
 
 :Along with snagging the "easy ones" for MP safeness, shouldn't getpid
 :be MP safe?  The struct proc is allocated from the proc_zone, and
 :afaik zalloc allows for stable storage meaning it's safe to dereference
 :the ppid pointer once the entire struct proc is populated, which needs
 :to happen before the process can even call getpid().
 :
 :phk seems to agree.
 :
 :-- 
 :-Alfred Perlstein - [[EMAIL PROTECTED]|[EMAIL PROTECTED]]
 :"I have the heart of a child; I keep it in a jar on my desk."
 
 The problem is that getpid() also extracts the ppid (look at
 the syscall code), which is not MP safe.

I did look at the code, struct proc is allocated from a zone,
meaning it won't "go away" once allocated, there's no danger in
dereferencing p_pptr, I don't get it.

-- 
-Alfred Perlstein - [[EMAIL PROTECTED]|[EMAIL PROTECTED]]
"I have the heart of a child; I keep it in a jar on my desk."


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

Re: cvs commit: src/sys/i386/i386 support.s src/sys/kern init_sysent.c kern_prot.c kern_sig.c

[Matthew Dillon]

:I did look at the code, struct proc is allocated from a zone,
:meaning it won't "go away" once allocated, there's no danger in
:dereferencing p_pptr, I don't get it.
:
:-- 
:-Alfred Perlstein - [[EMAIL PROTECTED]|[EMAIL PROTECTED]]
:"I have the heart of a child; I keep it in a jar on my desk."

What happens when the parent process exits and the system must
reassign the parent to process 1?  Now think about what happens
when it occurs on one cpu while another is trying to access the
ppid.

cpu#1:  cpu#2:

read p-p_pptr
indirect through to get ppid
(stalls on a cache miss plus, 
due to heavy DMA, stalls on main memory)
parent process finishes
exiting, replaces p_pptr
of children, releases
struct proc.

struct proc is reused,
pid is reallocated
read completes, wrong ppid is returned 
(neither the original ppid nor ppid 1 
is returned).

In an SMP system you have to assume the worst case, and the worst case
is that a cpu can stall INDEFINITELY between instructions.

-Matt
Matthew Dillon 
[EMAIL PROTECTED]


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

Re: cvs commit: src/sys/i386/i386 support.s src/sys/kern init_sysent.c kern_prot.c kern_sig.c

[Alfred Perlstein]

* Matthew Dillon [EMAIL PROTECTED] [000402 17:04] wrote:
 
 :I did look at the code, struct proc is allocated from a zone,
 :meaning it won't "go away" once allocated, there's no danger in
 :dereferencing p_pptr, I don't get it.
 :
 :-- 
 :-Alfred Perlstein - [[EMAIL PROTECTED]|[EMAIL PROTECTED]]
 :"I have the heart of a child; I keep it in a jar on my desk."
 
 What happens when the parent process exits and the system must
 reassign the parent to process 1?  Now think about what happens
 when it occurs on one cpu while another is trying to access the
 ppid.
 
   cpu#1:  cpu#2:
 
   read p-p_pptr
   indirect through to get ppid
   (stalls on a cache miss plus, 
   due to heavy DMA, stalls on main memory)
   parent process finishes
   exiting, replaces p_pptr
   of children, releases
   struct proc.
 
   struct proc is reused,
   pid is reallocated
 read completes, wrong ppid is returned 
   (neither the original ppid nor ppid 1 
   is returned).
 
 In an SMP system you have to assume the worst case, and the worst case
 is that a cpu can stall INDEFINITELY between instructions.

Good call.

Ugh, I should think about this more, but i'll just grasp at straws
and suggest that p_pptr is set to volatile variable, and we re-read
it after we snarf the pid from the pointer and make sure it hasn't
changed out from under us.

Either that or store it in the child's proc struct as well.

-- 
-Alfred Perlstein - [[EMAIL PROTECTED]|[EMAIL PROTECTED]]
"I have the heart of a child; I keep it in a jar on my desk."


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

Re: RSA library problems

[Jim Bloom]

Dirk Roehrdanz wrote:
 
 Thanks for the modification.
 I have replaced the "[]" with "{}" . A run of "make buildworld" with
 the patch finished without errors.

Sorry about that.  I did it quickly and the font I was using has the characters
looking identical.  Time to change fonts :-)

 The output of objdump --private-headers on the created librsaINTL.so.1
 libs  under /usr/obj contains now the line "NEEDED libcrypto.so.1".
 Apache-modssl works now  with encryption!

Good news.  I was sure that would fix the problem.

 
 Should I file a pr  with the patch ?

If you like.  Hopefully someone will pick it up from the list sooner and commit
the patch.  send-pr is the official channel for reporting bugs.

Jim Bloom
[EMAIL PROTECTED]


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

Re: Please review newbus patch for amd and adv

[Warner Losh]

In message [EMAIL PROTECTED] Takahashi Yoshihiro writes:
: For adv driver:
: http://home.jp.FreeBSD.org/~nyan/patches/advansys.diff.gz

I took a look at this change.  For the most part it looks good.
However, I have a question.  Why did you move the adv_isa into the md
files file and then comment it out for pc98?  I'm confused.

Warner


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

Re: cvs commit: src/sys/i386/i386 support.s src/sys/kern init_sysent.c kern_prot.c kern_sig.c

[Matthew Dillon]

:Good call.
:
:Ugh, I should think about this more, but i'll just grasp at straws
:and suggest that p_pptr is set to volatile variable, and we re-read
:it after we snarf the pid from the pointer and make sure it hasn't
:changed out from under us.
:
:Either that or store it in the child's proc struct as well.
:
:-- 
:-Alfred Perlstein - [[EMAIL PROTECTED]|[EMAIL PROTECTED]]

Re-reading is still somewhat dangerous due to the non-deterministic
nature of the possible changes, whereas with monotonically increasing
timers re-reading can be made to work in an SMP-safe fashion.

In general it isn't worth getting that convoluted.  I think the MP-safe
code can make certain assumptions about the consistency of curproc,
but outside of that we have to be very very careful.

-Matt
Matthew Dillon 
[EMAIL PROTECTED]


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

Load average calculation?

[Kevin Day]

I'm not sure if this is -current fodder or not, but since it's still
happening in -current, I'll ask.

We recently upgraded a server from 2.2.8 to 4.0(the same behavior is shown
on 5.0-current, too). Before, with the exact same load, we'd see load
averages from between 0.20 and 0.30. Now, we're getting:

load averages:  4.16,  4.23,  4.66

Top shows the same CPU percentages, just a much higher load average for the
same work being done. Did the load average calculation change, or something
with the scheduler differ? Customers are complaining that the load average
is too high, which is kinda silly, since 4.0 seems noticably faster in some
cases.

Any ideas?

Kevin


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

Re: Load average calculation?

[Kevin Day]

 :We recently upgraded a server from 2.2.8 to 4.0(the same behavior is shown
 :on 5.0-current, too). Before, with the exact same load, we'd see load
 :averages from between 0.20 and 0.30. Now, we're getting:
 :
 :load averages:  4.16,  4.23,  4.66
 :
 :Top shows the same CPU percentages, just a much higher load average for the
 :same work being done. Did the load average calculation change, or something
 :with the scheduler differ? Customers are complaining that the load average
 :is too high, which is kinda silly, since 4.0 seems noticably faster in some
 :cases.
 :
 :Any ideas?
 :
 :Kevin
 
 I believe the load average was changed quite a while ago to reflect not
 only runnable processes but also processes stuck in disk-wait.  It's
 a more accurate measure of load.
 

Ahh, and since nearly everything is done on this system via NFS, I can
imagine that several things are waiting for NFS responses. 

It's probably more accurate, but from a PR standpoint it makes it "look"
like FreeBSD is choking under the load, when it really isn't. Or am I the
only one that even cares about this? :)


Kevin


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

Recent commits to /sys/dev/sound/isa/ess.c

[Donn Miller]

I tried this, and the buffer size of 16k doesn't work too well with
the ESS 1868 isa.  The fist .3 seconds or so of the beginning of the
clip plays in an infinite loop.  I bumped down the buffer size to 12k,
and it seems to work pretty well.  Actually, I tried experimenting
with various buffer sizes, and anything from 4k to 12k seems to work,
and the ranges 8k to 12k seem to work best.  I think 12k is the best
from what I've heard, but I'm not sure.

Also, timidity is broken (ESS 1868) with the lastest revisions to
pcm.  pcm is a little flakier than it used to be, but not by much.
 
- Donn


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

Re: Load average calculation?

[Wilko Bulte]

On Sun, Apr 02, 2000 at 11:10:59PM -0500, Kevin Day wrote:
  :We recently upgraded a server from 2.2.8 to 4.0(the same behavior is shown
  :on 5.0-current, too). Before, with the exact same load, we'd see load
  :averages from between 0.20 and 0.30. Now, we're getting:
  :
  :load averages:  4.16,  4.23,  4.66
  :
  :Top shows the same CPU percentages, just a much higher load average for the
  :same work being done. Did the load average calculation change, or something
  :with the scheduler differ? Customers are complaining that the load average
  :is too high, which is kinda silly, since 4.0 seems noticably faster in some
  :cases.
  :
  :Any ideas?
  :
  :Kevin
  
  I believe the load average was changed quite a while ago to reflect not
  only runnable processes but also processes stuck in disk-wait.  It's
  a more accurate measure of load.
 
 Ahh, and since nearly everything is done on this system via NFS, I can
 imagine that several things are waiting for NFS responses. 
 
 It's probably more accurate, but from a PR standpoint it makes it "look"
 like FreeBSD is choking under the load, when it really isn't. Or am I the
 only one that even cares about this? :)

What does the man page for 'w' say about it? At least the change should be
reflected there I guess.

-- 
Wilko Bulte Arnhem, The Netherlands   
http://www.tcja.nl  The FreeBSD Project: http://www.freebsd.org


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

Re: Load average calculation?

[Kevin Day]

   I believe the load average was changed quite a while ago to reflect not
   only runnable processes but also processes stuck in disk-wait.  It's
   a more accurate measure of load.
  
  Ahh, and since nearly everything is done on this system via NFS, I can
  imagine that several things are waiting for NFS responses. 
  
  It's probably more accurate, but from a PR standpoint it makes it "look"
  like FreeBSD is choking under the load, when it really isn't. Or am I the
  only one that even cares about this? :)
 
 What does the man page for 'w' say about it? At least the change should be
 reflected there I guess.

getloadavg(3)(which 'w' and 'uptime' use) says:

 The getloadavg() function returns the number of processes in the system
 run queue averaged over various periods of time.


The 'w' and 'uptime' manpages really don't mention anything relevant.

Kevin


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

Re: Load average calculation?

[Matthew Dillon]

:I'm not sure if this is -current fodder or not, but since it's still
:happening in -current, I'll ask.
:
:We recently upgraded a server from 2.2.8 to 4.0(the same behavior is shown
:on 5.0-current, too). Before, with the exact same load, we'd see load
:averages from between 0.20 and 0.30. Now, we're getting:
:
:load averages:  4.16,  4.23,  4.66
:
:Top shows the same CPU percentages, just a much higher load average for the
:same work being done. Did the load average calculation change, or something
:with the scheduler differ? Customers are complaining that the load average
:is too high, which is kinda silly, since 4.0 seems noticably faster in some
:cases.
:
:Any ideas?
:
:Kevin

I believe the load average was changed quite a while ago to reflect not
only runnable processes but also processes stuck in disk-wait.  It's
a more accurate measure of load.

-Matt
Matthew Dillon 
[EMAIL PROTECTED]


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