Is Sawfish running on -current?
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 SAWFISHDOCFILE=../DOC /usr/local/libexec/rep/i386--freebsd5.0/libtool --mode=execute -dlopen ../src/gradient.la ../src/sawfish --batch --no-rc compiler -f compile-batch sawfish/wm.jl Segmentation fault - core dumped gmake[1]: *** [sawfish/wm.jlc] Error 139 gmake[1]: Leaving directory `/home/SRC/FreeBSD/FreeBSD-current/ports/x11-wm/sawfish/work/sawfish-0.36/lisp' gmake: *** [all] Error 2 To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
New OpenSSL snapshot for testing
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 this in a week. Kris PGP signature
Re: disklabel.c & disklabel.8 patch
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 http://people.freebsd.org/~imp/disklabel.c.patch but there's still some problems Warner P.S. There's also some problems getting to freefall, so the patch really isn't there yet... To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
Re: disklabel.c & disklabel.8 patch
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 # (Cyl.0 - 812*) > b: 1G* swap > c: **unused > e: 204800*4.2BSD > f: 5g*4.2BSD > g: **4.2BSD > > >An up-to-date copy of disklabel.c can be found at: > > http://people.freebsd.org/~jwd/disklabel.c > >The man page can be found at: > > http://people.freebsd.org/~jwd/disklabel/disklabel.8 > >or in html format: > > http://people.freebsd.org/~jwd/disklabel/disklabel.8.html > > >Patch files: > > http://people.freebsd.org/~jwd/disklabel/disklabel.c.patch > http://people.freebsd.org/~jwd/disklabel/disklabel.8.patch > > >I'd like to commit these if no one sees any major problems > with them. 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. Bruce To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
Re: cvs commit: src/sys/alpha/alpha trap.c src/sys/i386/i386 trap.c
> > 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. You > probably want to remove the kernel option WITNESS_DDB if you have it > it enabled. Another one, during fsck (I can still panic the system by ejecting pccard): lock order reversal 1st vnode interlock last acquired @ ../../ufs/ffs/ffs_vfsops.c:396 2nd 0xc0299bc0 mntvnode @ ../../ufs/ffs/ffs_vfsops.c:457 3rd 0xc60bafec vnode interlock @ ../../kern/vfs_subr.c:1871 -- Yes, I've heard of "decaf." What's your point? To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
Re: cvs commit: src/sys/alpha/alpha trap.c src/sys/i386/i386 trap.c
> 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 enabled. Same here. I get the (now usual): lock order reversal 1st vnode interlock last acquired @ ../../kern/vfs_vnops.c:644 2nd 0xc0299bc0 mntvnode @ ../../ufs/ffs/ffs_vfsops.c:940 3rd 0xc6595dac vnode interlock @ ../../ufs/ffs/ffs_vfsops.c:949 then later: lock order reversal 1st lockmgr last acquired @ ../../kern/kern_lock.c:505 2nd 0xc02824a0 uidinfo hash @ ../../kern/kern_resource.c:727 3rd 0xc0280460 lockmgr @ ../../kern/kern_lock.c:239 and a few seconds later: lock order reversal 1st lockmgr last acquired @ ../../kern/kern_lock.c:505 2nd 0xc0ac9e1c uidinfo struct @ ../../kern/kern_resource.c:781 3rd 0xc0280460 lockmgr @ ../../kern/kern_lock.c:239 Bye, Andrea -- The best things in life are free, but the expensive ones are still worth a look. To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
Re: cvs commit: src/sys/alpha/alpha trap.c src/sys/i386/i386 trap.c
> 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. > > Revision ChangesPath > 1.45 +2 -1 src/sys/alpha/alpha/trap.c > 1.174 +2 -1 src/sys/i386/i386/trap.c > > This fixes -current on my machines (i386 UP and SMP). 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 enabled. To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
Re: od driver for -CURRENT
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 may be changed after > open on certain types of devices that don't have a media lock. Some > devices will only tell you that they are write protected on the first > write, etc. For the devices where we can tell, we should make the check > in open, but not rely on that catching all cases where a driver will > return EACCESS. Also, writing to a write protected sector is a special case of an i/o error, so it will be handled by non-broken general i/o error handling. Also^2, write protection might be for individual sectors and might change while the device is open, just like most i/o errors. We actually have this for most disks -- FreeBSD has write protection of label sectors in software, and it can be turned on and off while the device is open. Bruce To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
Re: Current SMP Kernel panics
-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 the second CPU: art_init: trying /sched!st in/init SMP: CPU1 apic_initialize(): lint0: 0x00010700 lint1: 0x00010400 TPR: 0x0010 SVR: 0x01ff After that the only things I get are: Generator gate Generator gate finish after each couple of seconds. Going in ddb yields [abbreviated, no serial console]: ddb> show mutex Giant @ ../../kern_intr:427 ddb> show witness spinlocks: sio @ isa/sio.c:2549 sched_lock @ kern/kern_sync.c:809 clk @ i386/isa/clock.c:406 callout @ kern/kern_timeout.c:283 ithread table @ i386/isa/intr_machdep.c:587 ithread list@ kern/kern_intr.237 ap boot @ i386/i386/mp_machdep.c:2270 imen@ i386/i386/mpapic.c:261 Going out of ddb by panicing resulted in either a direct kernel trap 12 with interrupts disabled or a kernel trap 0 with interrupts disabled after which another panic led to a kernel trap 12 with interrupts disabled. The kernel trap 12 was an infinite loop. -- Jeroen Ruigrok vd Werven/Asmodaiasmodai@[wxs.nl|bart.nl|freebsd.org] Documentation nutter/C-rated Coder BSD: Technical excellence at its best D78D D0AD 244D 1D12 C9CA 7152 035C 1138 546A B867 I'm a child of the air, I'm a witch of the wind... To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
Re: cvs commit: src/sys/kern kern_synch.c
> 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 sched_lock held. > > Revision ChangesPath > 1.126 +5 -9 src/sys/kern/kern_synch.c > > This fixes the tripped assertion in need_resched(), but -current still hangs on boot. We're working on it :) To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
Re: Current SMP Kernel panics
-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 is that when I sched_lock need_resched() it just hangs and doesn't boot further. -- Jeroen Ruigrok vd Werven/Asmodaiasmodai@[wxs.nl|bart.nl|freebsd.org] Documentation nutter/C-rated Coder BSD: Technical excellence at its best D78D D0AD 244D 1D12 C9CA 7152 035C 1138 546A B867 I'm a child of the air, I'm a witch of the wind... To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
Re: Current SMP Kernel panics
> > 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 that sched_lock should be held across forward_roundrobin(). But, my box still hangs with the assertion satisifed. To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
Re: Current SMP Kernel panics
At 04:20 PM 2/10/2001 +0100, Jeroen Ruigrok/Asmodai wrote:
>-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
>
>Me too.
>
>166 static void
>167 roundrobin(arg)
>168 void *arg;
>169 {
>170 #ifndef SMP
>171 struct proc *p = curproc; /* XXX */
>172 #endif
>173
>174 #ifdef SMP
>175 need_resched();
>176 forward_roundrobin();
>177 #else
>178 if (p == PCPU_GET(idleproc) || RTP_PRIO_NEED_RR(p->p_rtprio.type)
> )
>179 need_resched();
>180 #endif
>181
>182 callout_reset(&roundrobin_callout, sched_quantum, roundrobin, NUL
>L);
>183 }
>
>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.
>
I tried the above and the machine just hangs when it comes to:
SMP: AP CPU # 1 Launched!
:(
Manfred
==
|| [EMAIL PROTECTED] ||
|| Ph. (415) 681-6235 ||
==
To Unsubscribe: send mail to [EMAIL PROTECTED]
with "unsubscribe freebsd-current" in the body of the message
Re: Current SMP Kernel panics
* 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 work. > > I don't get the panic() anymore, but now I have solve the hanging. :) > > 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. I'm currently looking to see if forward_roundrobin() does 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: Current SMP Kernel panics
-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 the hanging. :) Perhaps only need_resched() needs to be spinlocked. I am not sure, I am not a SMP guru. -- Jeroen Ruigrok vd Werven/Asmodaiasmodai@[wxs.nl|bart.nl|freebsd.org] Documentation nutter/C-rated Coder BSD: Technical excellence at its best D78D D0AD 244D 1D12 C9CA 7152 035C 1138 546A B867 I'm a child of the air, I'm a witch of the wind... To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
Cardbus, audio & irq sharing [Was: Kernel Panic from Yesterday's CVSup]
> : 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 like the way IRQs are wired, and it also looks like ACPI is tricky. > : just wait. On a separate note, I am thinking about adapting rc.pccard to > : carbus, or writing a new rc.cardbus; is anybody working on this? > > /sbin/devd :-) Pointers to this? Does it run dhclient like rc.pccard does? Although one of the nicest things about cardbus is that, having the card in at boot, it probed and configured much earlier during the boot process, making it possible to ifconfig it normally. > : Going back to the original thread, removing my card under cardbus simply > : hangs my laptop. I have no idea how to debug this. > > Neither do I. I make guesses until it is working. Ok ;-) Sounds fun :-P -- Press every key to continue. To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
Re: od driver for -CURRENT
>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 devices that don't have a media lock. Some devices will only tell you that they are write protected on the first write, etc. For the devices where we can tell, we should make the check in open, but not rely on that catching all cases where a driver will return EACCESS. -- Justin To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
Re: Current SMP Kernel panics
-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
Me too.
166 static void
167 roundrobin(arg)
168 void *arg;
169 {
170 #ifndef SMP
171 struct proc *p = curproc; /* XXX */
172 #endif
173
174 #ifdef SMP
175 need_resched();
176 forward_roundrobin();
177 #else
178 if (p == PCPU_GET(idleproc) || RTP_PRIO_NEED_RR(p->p_rtprio.type)
)
179 need_resched();
180 #endif
181
182 callout_reset(&roundrobin_callout, sched_quantum, roundrobin, NUL
L);
183 }
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.
--
Jeroen Ruigrok vd Werven/Asmodaiasmodai@[wxs.nl|bart.nl|freebsd.org]
Documentation nutter/C-rated Coder BSD: Technical excellence at its best
D78D D0AD 244D 1D12 C9CA 7152 035C 1138 546A B867
I'm a child of the air, I'm a witch of the wind...
To Unsubscribe: send mail to [EMAIL PROTECTED]
with "unsubscribe freebsd-current" in the body of the message
Compaq WL200
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 PROTECTED] with "unsubscribe freebsd-current" in the body of the message
Re: od driver for -CURRENT
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 doesn't have. I figured it > > > wouldn't really be necessary, since any attempted writes would be returned > > > with errors. > > > > The problem is you cannot unmount after -rw mount with a write-protected > > medium. > > This is essentially the same bug that causes problems for writing to > write protected media or unwriteable blocks using the block device. 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. > I first saw this problem for a floppy driver that I wrote in 1984. It > retried endlessly. Users did not like this :-). I was told not to write-protect floppies when using UNIX :-( // Noriaki Mitsunaga // To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
