Re: od driver for -CURRENT

2001-02-10 Thread non
From: Bruce Evans [EMAIL PROTECTED] Date: Sat, 10 Feb 2001 06:24:20 +1100 (EST) On Fri, 9 Feb 2001 [EMAIL PROTECTED] wrote: From: "Kenneth D. Merry" [EMAIL PROTECTED] Hmm, can you demonstrate the problem? The write-protect check in the od driver is one of the things that the da driver

Compaq WL200

2001-02-10 Thread John Murphy
I'd like to use a Compaq WL200 PCI wireless LAN Card with FreeBSD soon. I've seen mention of the pcic driver in -current, but I'm runing -stable at present. Is the Compaq WL200 already supported by current? If not, is there work in progress? Thanks, John. To Unsubscribe: send mail to [EMAIL

Re: Current SMP Kernel panics

2001-02-10 Thread Jeroen Ruigrok/Asmodai
-On [20010210 06:26], Manfred Antar ([EMAIL PROTECTED]) wrote: APIC_IO: routing 8254 via 8259 and IOAPIC #0 intpin 0 IPsec: Initialized Security Association Processing. panic: mutex sched lock not owned at ../../kern/kern_synch.c:175 AOL Me too. /AOL 166 static void 167 roundrobin(arg) 168

Re: od driver for -CURRENT

2001-02-10 Thread Justin T. Gibbs
Are there any reason device drivers do not check if thier devices are writable or not when they are opened ? I think returning an error value, like `od', is the easiest way to avoid this problem. It is not necessarily sufficient since the media may be changed after open on certain types of

Cardbus, audio irq sharing [Was: Kernel Panic from Yesterday's CVSup]

2001-02-10 Thread Andrea Campi
: And, it's not working for me, i.e. my pccard using cardbus is working on irq : 11, my csa audio card is probed and configured on irq 11, but audio playback : is not. Audio and current is also dicy. Well, the same happened under -stable. I think this will be my last IBM laptop, I don't

Re: Current SMP Kernel panics

2001-02-10 Thread Jeroen Ruigrok/Asmodai
-On [20010210 16:27], Jeroen Ruigrok/Asmodai ([EMAIL PROTECTED]) wrote: #ifdef SMP mtx_lock_spin(sched_lock); need_resched(); forward_roundrobin(); mtx_unlock_spin(sched_lock); #else This does not quite work. I don't get the panic() anymore, but now I have solve

Re: Current SMP Kernel panics

2001-02-10 Thread Alfred Perlstein
* Jeroen Ruigrok/Asmodai [EMAIL PROTECTED] [010210 08:24] wrote: -On [20010210 16:27], Jeroen Ruigrok/Asmodai ([EMAIL PROTECTED]) wrote: #ifdef SMP mtx_lock_spin(sched_lock); need_resched(); forward_roundrobin(); mtx_unlock_spin(sched_lock); #else This does not quite

Re: Current SMP Kernel panics

2001-02-10 Thread Jake Burkholder
Should it become: #ifdef SMP mtx_lock_spin(sched_lock); need_resched(); forward_roundrobin(); mtx_unlock_spin(sched_lock); #else ? I cannot test it yet, need to reanimate my testbox first. You need to handle the UP case as well :) Also, I don't think

Re: Current SMP Kernel panics

2001-02-10 Thread Jeroen Ruigrok/Asmodai
-On [20010210 18:08], Alfred Perlstein ([EMAIL PROTECTED]) wrote: * Jeroen Ruigrok/Asmodai [EMAIL PROTECTED] [010210 08:24] wrote: Perhaps only need_resched() needs to be spinlocked. I am not sure, I am not a SMP guru. That looks correct, need_resched() needs sched_lock. Problem

Re: cvs commit: src/sys/kern kern_synch.c

2001-02-10 Thread Jake Burkholder
jake2001/02/10 11:07:32 PST Modified files: sys/kern kern_synch.c Log: Acquire sched_lock around need_resched() in roundrobin() to satisfy assertions that it is held. Since roundrobin() is a timeout there's no possible way that it could be called with

Re: Current SMP Kernel panics

2001-02-10 Thread Jeroen Ruigrok/Asmodai
-On [20010210 17:30], Jeroen Ruigrok/Asmodai ([EMAIL PROTECTED]) wrote: Perhaps only need_resched() needs to be spinlocked. I am not sure, I am not a SMP guru. To add: It needed to be spinlocked as you saw jake's commit affirmed and fixed. However I am currently hanging just after lauching

Re: od driver for -CURRENT

2001-02-10 Thread Bruce Evans
On Sat, 10 Feb 2001, Justin T. Gibbs wrote: Are there any reason device drivers do not check if thier devices are writable or not when they are opened ? I think returning an error value, like `od', is the easiest way to avoid this problem. It is not necessarily sufficient since the media

Re: cvs commit: src/sys/alpha/alpha trap.c src/sys/i386/i386 trap.c

2001-02-10 Thread Jake Burkholder
jake2001/02/10 12:33:35 PST Modified files: sys/alpha/alpha trap.c sys/i386/i386trap.c Log: Clear the reschedule flag after finding it set in userret(). This used to be in cpu_switch(), but I don't see any difference between doing it here.

Re: cvs commit: src/sys/alpha/alpha trap.c src/sys/i386/i386 trap.c

2001-02-10 Thread Andrea Campi
This fixes -current on my machines (i386 UP and SMP). Confirmed for UP i686. Should be in the clear now. asmodia has seen a lock reversal between the process lock and uidinfo lock, but I can't reproduce it. You probably want to remove the kernel option WITNESS_DDB if you have it it

Re: cvs commit: src/sys/alpha/alpha trap.c src/sys/i386/i386 trap.c

2001-02-10 Thread Andrea Campi
Clear the reschedule flag after finding it set in userret(). This used to be in cpu_switch(), but I don't see any difference between doing it here. Should be in the clear now. asmodia has seen a lock reversal between the process lock and uidinfo lock, but I can't reproduce it.

Re: disklabel.c disklabel.8 patch

2001-02-10 Thread Bruce Evans
On Fri, 9 Feb 2001, John W. De Boskey wrote: I've been using the disklabel.c patch which allows easier configuration by being able to specify a new disklabel of the form: #size offsetfstype [fsize bsize bps/cpg] a: 400M04.2BSD 4096 1638475 #

Re: disklabel.c disklabel.8 patch

2001-02-10 Thread Warner Losh
In message [EMAIL PROTECTED] Bruce Evans writes: : These are not suitable for commit in their current form. The : disklabel.c patch has more than the usual density of style bugs. : It doesn't even use the normal brace style. You can find a mostly cleaned up version at

New OpenSSL snapshot for testing

2001-02-10 Thread Kris Kennaway
Well, I lost the previous OpenSSL snapshot with a hard disk crash (and it's no longer on the FTP site) so I had to redo it - please test this one instead: http://www.freebsd.org/~kris/openssl-0.9.6-stable-20010210.tbz Same deal as before - unpack it in /usr/src and rebuild. I'll commit

Is Sawfish running on -current?

2001-02-10 Thread Takeshi Ken Yamada
I have the following error while compiling Sawfish on recent -current. Is it my half updated fault or the -current issue? gmake[1]: Entering directory `/home/SRC/FreeBSD/FreeBSD-current/ports/x11-wm/sawfish/work/sawfish-0.36/lisp' SAWFISHLISPDIR=. SAWFISHEXECDIR=../src/.libexec