Re: Corrected HEADS UP: the midi driver will be removed after 5.2-R
On Sat, 15 Nov 2003 22:42:44 +0900, Seigo Tanimura <[EMAIL PROTECTED]> said: tanimura> Mathew Kanner has developed the new version of the midi framework, tanimura> based on kobj(9) and buildable as a module. As the first step to tanimura> replace the midi driver, the conventional one is removed from the tanimura> kernel in a minute. tanimura> Mathew will soon be starting a work to merge his driver. As we need some more time to define Mathew's driver, we have decided to postpone axing the old one until 5.2-R is released. -- Seigo Tanimura <[EMAIL PROTECTED]> <[EMAIL PROTECTED]> ___ [EMAIL PROTECTED] mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to "[EMAIL PROTECTED]"
HEADS UP: the midi driver will be removed for a while
Mathew Kanner has developed the new version of the midi framework, based on kobj(9) and buildable as a module. As the first step to replace the midi driver, the conventional one is removed from the kernel in a minute. Mathew will soon be starting a work to merge his driver. -- Seigo Tanimura <[EMAIL PROTECTED]> <[EMAIL PROTECTED]> ___ [EMAIL PROTECTED] mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to "[EMAIL PROTECTED]"
Re: Who should set the priority of a select(2)ing thread being waken up?
[posted to -current as well, because there were no replies in -arch] On Wed, 22 Oct 2003 19:21:46 +0900, Seigo Tanimura <[EMAIL PROTECTED]> said: tanimura> In good old days, only a socket and a pipe were the major file tanimura> descriptors being select(2)ed. As select(2) was just a socket tanimura> operation, it was sufficient to set the priority of select(2)ing tanimura> process to PSOCK(*1), I suppose. tanimura> Nowadays, quite a few drivers support select(2) as well, including tanimura> sound, usb, scsi controllers, and so on. I am not convinced whether a tanimura> process should select(2) those devices at PSOCK as we do for a socket. tanimura> Suppose that a process select(2)s for a pcm device and a socket at tanimura> once. If the process is waken up by the pcm driver at PSOCK, another tanimura> process at a better priority may preempt the first one, which can tanimura> result in dropping some pcm data. tanimura> Maybe it would be better if the caller of selwakeup() could determine tanimura> the priority of a process or a thread. That would let us raise the tanimura> priority to PRIBIO if pcm data was ready, while the priority would tanimura> stay at PSOCK if the socket was ready. tanimura> (*1) I broke that in 5-CURRENT when I modified select(2) and poll(2) tanimura> to use a conditional variable. tanimura> The attached patch implements selwakeuppri(), which lets you set the tanimura> priority of a thread being waken up. Also in the patch is a small tanimura> test code to use selwakeuppri() in pcm(4). (patch snipped) The updated patch at: http://people.freebsd.org/~tanimura/selwakeuppri.diff.gz converts all selwakeup()s into selwakeuppri()s with appropriate priorities. Old selwakeup() is left, but I may axe it. Any objections if I commit the patch in a week? -- Seigo Tanimura <[EMAIL PROTECTED]> <[EMAIL PROTECTED]> ___ [EMAIL PROTECTED] mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to "[EMAIL PROTECTED]"
Is pci a must on sparc64?
A sparc64 kernel without pci device fails to build. The kernel is configured for Ultra2 with no pci devices. --- v --- log --- v --- daiba% make cc -c -O -pipe -g -Wall -Wredundant-decls -Wnested-externs -Wstrict-prototypes -Wmissing-prototypes -Wpointer-arith -Winline -Wcast-qual -fformat-extensions -std=c99 -g -nostdinc -I- -I. -I../../.. -I../../../contrib/dev/acpica -I../../../contrib/ipfilter -I../../../contrib/dev/ath -I../../../contrib/dev/ath/freebsd -D_KERNEL -include opt_global.h -fno-common -finline-limit=15000 -fno-strict-aliasing -mcmodel=medlow -msoft-float -ffreestanding -Werror ../../../sparc64/sparc64/ofw_machdep.c In file included from ../../../sparc64/sparc64/ofw_machdep.c:45: ../../../sparc64/pci/ofw_pci.h:41:24: ofw_pci_if.h: No such file or directory *** Error code 1 Stop in /home/silver4/tanimura/p4-freefall/handoffpri/sparc64/compile/DAIBA. daiba% --- ^ --- log --- ^ --- ofw_machdep.c unconditionally includes ofw_pci_if.h, even if pci device is not configured. Do I have to configure pci even for non-pci machines? -- Seigo Tanimura <[EMAIL PROTECTED]> <[EMAIL PROTECTED]> ___ [EMAIL PROTECTED] mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to "[EMAIL PROTECTED]"
Re: Dynamic growth of the buffer and buffer page reclaim
On Mon, 28 Oct 2002 00:54:57 -0800 (PST), Matthew Dillon <[EMAIL PROTECTED]> said: dillon> I can demonstrate the issue with a simple test. Create a large file dillon> with dd, larger then physical memory: dillon> dd if=/dev/zero of=test bs=1m count=4096# create a 4G file. dillon> Then dd (read) portions of the file and observe the performance. dillon> Do this several times to get stable numbers. dillon> dd if=test of=/dev/null bs=1m count=16 # repeat several times dillon> dd if=test of=/dev/null bs=1m count=32 # etc... dillon> You will find that read performance will drop in two significant dillon> places: (1) When the data no longer fits in the buffer cache and dillon> the buffer cache is forced to teardown wirings and rewire other dillon> pages from the VM page cache. Still no physical I/O is being done. dillon> (2) When the data no longer fits in the VM page cache and the system dillon> is forced to perform physical I/O. I tried that on the same PC as my last benchmark. The PC has 160MB RAM, so I created a file of 256MB. One pre-read (in order to stabilize the buffer cache) and four read tests were run consecutively for each of six distinct read sizes just after boot. The average read times (in seconds) and speeds (in MB/sec) are shown below: without my patchwith my patch read size timespeed timespeed 32MB.49765.5.47169.0 64MB1.0263.6.90172.1 96MB2.2450.55.5218.9 128MB 20.76.1916.57.79 192MB 32.95.8332.95.83 256MB 42.56.0243.05.95 dillon> Its case (1) that you are manipulating with your patch, and as you can dillon> see it is entirely dependant on the number of wired pages that the dillon> system is able to maintain in the buffer cache. The results of 128MB-read are likely to be so. 96MB-read gave interesting results. Since vfs_unwirepages() passes buffer pages to vm_page_dontneed(), it seems that the page scanner reclaims buffer cache pages too aggressively. The table below shows the results with my patch where vfs_unwirepages() does not call vm_page_dontneed(). read size timespeed 32MB.50363.7 64MB.91670.5 96MB4.5727.1 128MB 17.07.62 192MB 35.85.36 256MB 46.05.56 The 96MB-read results were a little bit better, although the reads of larger sizes became slower. The unwired buffer pages may be putting a pressure on user process pages and the page scanner. -- Seigo Tanimura <[EMAIL PROTECTED]> To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
Re: Dynamic growth of the buffer and buffer page reclaim
On Thu, 24 Oct 2002 15:05:30 +1000 (EST), Bruce Evans <[EMAIL PROTECTED]> said: bde> Almost exactly what we have. It turns out to be not very good, at least bde> in its current implementation, since remapping is too expensive. Things bde> work OK to the extent that remapping is not required, but so would a bde> much simpler implementation that uses less vm and more copying of data bde> (copying seems to be faster than remapping). Which process is expensive in remapping? Allocation of a KVA space? Page wiring? Or pmap operation? -- Seigo Tanimura <[EMAIL PROTECTED]> To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
Re: Dynamic growth of the buffer and buffer page reclaim
On Wed, 23 Oct 2002 16:51:44 -0400 (EDT), Jeff Roberson <[EMAIL PROTECTED]> said: jroberson> I do, however, like the page unwiring idea. As long as it's not too jroberson> expensive. I have been somewhat disappointed that the buffer cache's jroberson> buffers are hands off for the vm. I'm confused about your approach jroberson> though. I think that the rewire function is unnecessary. You could move jroberson> this code into allocbuf() which would limit the number of times that you jroberson> have to make a pass over this list and keep the maintenance of it in a jroberson> more central place. This would also remove the need for truncating the jroberson> buf. I just wanted to make sure that buffers not in the clean queue look as they used to do without the patch. At least, if a buffer does not become busy or held, then it need not be rewired down. -- Seigo Tanimura <[EMAIL PROTECTED]> To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
Re: Dynamic growth of the buffer and buffer page reclaim
On Wed, 23 Oct 2002 16:44:06 +1000 (EST), Bruce Evans <[EMAIL PROTECTED]> said: bde> I should be the last to defend the current design and implementation of bde> the buffer cache, since I think it gets almost everything wrong (the bde> implementation is OK, but has vast complications to work around design bde> errors), but I think buffer_map is one of the things that it gets right bde> (if we're going to have buffers at all). (snip) bde> I use the following changes in -current to enlarge the buffer cache and bde> avoid fragmentation. These only work because I don't have much physical bde> memory (512MB max). Even i386's have enough vm for the pure form of bde> buffer_map to work: bde> - enlarge BKVASIZE to MAXBSIZE so that fragmentation can not (should not?) bde> occur. bde> - enlarge nbuf by a factor of (my_BKVASIZE / current_BKVASIZE) to work bde> around bugs. The point of BKVASIZE got lost somewhere. bde> - enlarge nbuf and associated variables by another factor of 2 or 4 to bde> get a larger buffer cache. bde> This is marginal for 512MB physical, and probably wouldn't work if I had bde> a lot of mbufs. nbuf is about 4000 and buffer_map takes about 256MB. bde> 256MB is a lot, but nbuf = 4000 isn't a lot. I used buffer caches bde> with 2000 * 1K buffers under Minix and Linux before FreeBSD, and ISTR bde> having an nbuf of 5000 or so in FreeBSD-1.1. At least 2880 buffers are bde> needed to properly cache a tiny 1.44MB floppy with an msdosfs file bde> system with a block size of 512, and that was an important test case. bde> End of FreeBSD-[2-5] history. Incidentally, Solaris 7 on sun4u reserves a space of 256MB in the KVM according to Solaris Internals. On i386 (x86), the size is only 4MB. Not sure whether they use those spaces in a pure form, or they cluster some consecutive pages (which leads to fragmentation), though... NetBSD UBC also makes a map dedicated to buffers in kernel_map. Maybe there is a point to have a map dedicated to the buffer space for a better stability, and the size of the buffer map could be much smaller than now. During my testing, I found that only up to 6-7MB of the buffers out of 40-50MB were wired down (ie busy, locked for background write or dirty) at most. -- Seigo Tanimura <[EMAIL PROTECTED]> To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
Dynamic growth of the buffer and buffer page reclaim
Introduction: The I/O buffer of the kernel are currently allocated in buffer_map sized statically upon boot, and never grows. This limits the scale of I/O performance on a host with large physical memory. We used to tune NBUF to cope with that problem. This workaround, however, results in a lot of wired pages not available for user processes, which is not acceptable for memory-bound applications. In order to run both I/O-bound and memory-bound processes on the same host, it is essential to achieve: A) allocation of buffer from kernel_map to break the limit of a map size, and B) page reclaim from idle buffers to regulate the number of wired pages. The patch at: http://people.FreeBSD.org/~tanimura/patches/dynamicbuf.diff.gz implements buffer allocation from kernel_map and reclaim of buffer pages. With this patch, make kernel-depend && make kernel completes about 30-60 seconds faster on my PC. Implementation in Detail: A) is easy; first you need to do s/buffer_map/kernel_map/. Since an arbitrary number of buffer pages can be allocated dynamically, buffer headers (struct buf) should be allocated dynamically as well. Glue them together into a list so that they can be traversed by boot() et. al. In order to accomplish B), we must find buffers both the filesystem and I/O codes will not touch. The clean buffer queue holds such the buffers. (exception: if the vnode associated with a clean buffer is held by the namecache, it may access the buffer page.) Thus, we should unwire the pages of a buffer prior to enqueuing it to the clean queue, and rewire the pages down in bremfree() if the pages are not reclaimed. Although unwiring gives a page a chance of being reclaimed, we can go further. In Solaris, it is known that file cache pages should be reclaimed prior to the other kinds of pages (anonymous, executable, etc.) for a better performance. Mainly due to a lack of time to work on distinguishing the kind of a page to be unwired, I simply pass all unwired pages to vm_page_dontneed(). This approach places most of the unwired buffer pages at just one step to the cache queue. Experimental Evaluation and Results: The times taken to complete make kernel-depend && make kernel just after booting into single-user mode have been measured on my ThinkPad 600E (CPU: Pentium II 366MHz, RAM: 160MB) by time(1). The number passed to the -j option of make(1) has been varied from 1 to 30 in order to control the pressure of the memory demand for user processes. The baseline is the kernel without my patch. The following table shows the results. All of the times are in seconds. -j baselinew/ my patch realusersys realusersys 1 1608.21 1387.94 125.96 1577.88 1391.02 100.90 10 1576.10 1360.17 132.76 1531.79 1347.30 103.60 20 1568.01 1280.89 133.22 1509.36 1276.75 104.69 30 1923.42 1215.00 155.50 1865.13 1219.07 113.43 Most of the improvements in the real times are accomplished by the speedup of system calls. The hit ratio of getblk() may be increased, but not examined yet. Another interesting results are the numbers of swaps, shown below. -j baselinew/ my patch 1 0 0 10 0 0 20 141 77 30 530 465 Since the baseline kernel does not free buffer pages at all(*), it may be putting a pressure on the pages too much. (*) bfreekva() is called only when the whole KVA is too fragmented. Userland Interfaces: The sysctl variable vfs.bufspace now reports the size of the pages allocated for buffer, both wired and unwired. A new sysctl variable, vfs.bufwiredspace tells the size of the buffer pages wired down. vfs.bufkvaspace returns the size of the KVA space for buffer. Future Works: The handling of unwired pages can be improved by scanning only buffer pages. In that case, we may have to run the vm page scanner more frequently, as does Solaris. vfs.bufspace does not track the buffer pages reclaimed by the page scanner. They are counted when the buffer associated with those pages are removed from the clean queue, which is too late. Benchmark tools concentrating on disk I/O performance (bonnie, iozone, postmark, etc) may be more suitable than make kernel for evaluation. Comments and flames are welcome. Thanks a lot. -- Seigo Tanimura <[EMAIL PROTECTED]> <[EMAIL PROTECTED]> To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
Re: panic: ffs_valloc: dup alloc (with bt + contents of some structures)
On Thu, 29 Aug 2002 12:05:25 +0200,
Alexander Leidinger <[EMAIL PROTECTED]> said:
Alexander> After booting the system up xdm didn't showed up and there was no
Alexander> possibility to login on the console, so I breaked into ddb and send a
Alexander> "kill 1" to xdm. Nothing happened so I again breaked into ddb and did a
Alexander> "kill 1 1". Nothing happened again, so I decided to do a +
Alexander> (several times) -> boom.
Alexander> ---snip---
Alexander> panic: ffs_valloc: dup alloc
Alexander> panic: from debugger
Alexander> Uptime: 4m9s
Alexander> pfs_vncache_unload(): 1 entries remaining
Alexander> [...]
Alexander> #7 0xc025573c in kdb_trap (type=3, code=0, regs=0xd1d707cc)
Alexander> at ../../../i386/i386/db_interface.c:161
Alexander> #8 0xc0262e8a in trap (frame=
Alexander> {tf_fs = 24, tf_es = 16, tf_ds = 16, tf_edi = -1033800768, tf_esi =
256, tf_ebp = -774436848, tf_isp = -774436872, tf_ebx = 0, tf_edx = -1071016644,
tf_ecx = -1070913265, tf_eax = -1070913281, tf_trapno = 3, tf_err = 0, tf_eip =
-1071293992, tf_cs = 8, tf_eflags = 582, tf_esp = -1070958431, tf_ss = -774436824})
Alexander> at ../../../i386/i386/trap.c:606
Alexander> #9 0xc02569f8 in calltrap () at {standard input}:98
Alexander> #10 0xc019ae06 in panic (fmt=0x0) at ../../../kern/kern_shutdown.c:480
Alexander> #11 0xc020be9b in ffs_valloc () at ../../../ufs/ffs/ffs_alloc.c:871
(snip)
I can reproduce that panic by extracting an archive of the Solaris
source code (74.5MB approximately) into a filesystem on a swap-backed
md(4) with softupdates. Except that the caller of ffs_valloc() is
usually ufs_mkdir() in my case, ffs_nodealloccg() sometimes returns an
inode with a nonzero i_mode.
A filesystem without softupdates produces no panics, with or without
async.
--
Seigo Tanimura <[EMAIL PROTECTED]> <[EMAIL PROTECTED]>
To Unsubscribe: send mail to [EMAIL PROTECTED]
with "unsubscribe freebsd-current" in the body of the message
Re: A fix of recent bugs in swapping in/out a process
A couple of updates: - Optimize wakeup() and its friends; if a thread waken up is being swapped in, we do not have to ask for the scheduler thread to do that. - Assert that a process is not swapped out in runq functions and swapout(). The update patchs is at: http://people.FreeBSD.org/~tanimura/patches/procswap_2.diff.gz On Sun, 28 Jul 2002 21:51:57 +0900, Seigo Tanimura <[EMAIL PROTECTED]> said: Seigo> If you are having a trouble of a broken thread state (eg a thread with Seigo> TDS_RUNQ on no run queue) or a mysterious page fault on a kernel Seigo> memory (probably in mi_switch()), you may want to try my patch at: Seigo> http://people.FreeBSD.org/~tanimura/patches/procswap.diff.gz Seigo> In a nutshell, this patch fixes three bugs: Seigo> 1. a thread with TDS_RUNQ on no run queue. Seigo> This is due to wakeup() and wakeup_one() setting the state to a thread Seigo> to TDS_RUNQ even if the thread has been swapped out. As a thread Seigo> being or having been swapped out cannot be scheduled immediately, Seigo> introduce a new thread state TDS_SWAPPED to note that. Seigo> 2. a possible race condition for multiple threads to swap in a single Seigo>process. Seigo> Since faultin() may block (and likely to do so) without leaving any Seigo> flags for a process being swapped in, more than one threads can call Seigo> faultin() for the same process. Avoid this by adding a new process Seigo> state flag PS_SWAPPINGIN to a process being swapped in. Seigo> 3. a running thread being swapped out. Seigo> Swapout_procs() and swapout() do not check the states of the threads Seigo> in a process about to be swapped out. This causes the pcb and the Seigo> kernel stack of a running thread being unmapped, resulting in a Seigo> page fault in cpu_switch(). Do not swap out a process unless all of Seigo> its threads are either in a run queue or sleeping. Seigo> Eventually, it may become our option to swap out only threads that are Seigo> safe to do so. -- Seigo Tanimura <[EMAIL PROTECTED]> <[EMAIL PROTECTED]> To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
A fix of recent bugs in swapping in/out a process
If you are having a trouble of a broken thread state (eg a thread with TDS_RUNQ on no run queue) or a mysterious page fault on a kernel memory (probably in mi_switch()), you may want to try my patch at: http://people.FreeBSD.org/~tanimura/patches/procswap.diff.gz In a nutshell, this patch fixes three bugs: 1. a thread with TDS_RUNQ on no run queue. This is due to wakeup() and wakeup_one() setting the state to a thread to TDS_RUNQ even if the thread has been swapped out. As a thread being or having been swapped out cannot be scheduled immediately, introduce a new thread state TDS_SWAPPED to note that. 2. a possible race condition for multiple threads to swap in a single process. Since faultin() may block (and likely to do so) without leaving any flags for a process being swapped in, more than one threads can call faultin() for the same process. Avoid this by adding a new process state flag PS_SWAPPINGIN to a process being swapped in. 3. a running thread being swapped out. Swapout_procs() and swapout() do not check the states of the threads in a process about to be swapped out. This causes the pcb and the kernel stack of a running thread being unmapped, resulting in a page fault in cpu_switch(). Do not swap out a process unless all of its threads are either in a run queue or sleeping. Eventually, it may become our option to swap out only threads that are safe to do so. -- Seigo Tanimura <[EMAIL PROTECTED]> <[EMAIL PROTECTED]> To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
Re: preemption across processors
On Wed, 29 May 2002 16:13:13 +0900, Seigo Tanimura <[EMAIL PROTECTED]> said: tanimura> Maybe we can solve both of the issues above by roughly checking if a tanimura> thread can keep spinning without acquiring any locks, in the similar tanimura> way as we do for a spin mutex. First, test the following conditions: tanimura> - The owner of the mutex has not changed. tanimura> - The owner is on a processor. - The priority of the curent thread has not changed. If some other thread spins for a mutex held by the current thread, we may have to propagate the priority of the other thread. -- Seigo Tanimura <[EMAIL PROTECTED]> <[EMAIL PROTECTED]> To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
Re: preemption across processors
On Tue, 28 May 2002 14:56:04 -0400 (EDT),
John Baldwin <[EMAIL PROTECTED]> said:
>> The prototype patch is at:
>>
>> http://people.FreeBSD.org/~tanimura/patches/ippreempt.diff.gz
>>
>> And the p4 depot
>>
>> //depot/user/tanimura/ippreempt/...
>>
>> The patch is for only i386 at the moment.
>>
>> The following is the brief description of the patch:
jhb> I would prefer that this was hung off the preemption stuff I've already done
jhb> rather than reinventing it. I would also prefer that we get a preemptive
jhb> kernel w/o this done stable before adding extra complication.
Or I can integrate your work in //depot/user/jhb/preemption/... into
//depot/user/tanimura/ippreempt/... .
>> Miscellaneous stuff:
>>
>> If a thread spins for an adaptive mutex, propagate its priority to the
>> owner thread of the mutex. This prevents preemption of the owner
>> thread by a thread with the priority in between the owner thread and
>> the spinning thread.
jhb> Ewww, I'd rather avoid this if possible. This is just an optimization,
jhb> but it would depend on how complicated this makes the mutex code to see
jhb> if it's worth it or not.
The owner thread of an adaptive mutex never lowers its priority until
it releases the mutex. We should thus bump the priority of the owner
thread not during but just before spinning. However, it is difficult
to know if the current thread can spin prior to calling
_obtain_lock().
In addition, I would say that spinning can be done even more
efficiently. At the moment, we try an atomic test-and-set
instruction in each spin. As another thread holds the mutex, we are
likely to execute an expensive test-and-set instruction quite a lot of
times.
Maybe we can solve both of the issues above by roughly checking if a
thread can keep spinning without acquiring any locks, in the similar
way as we do for a spin mutex. First, test the following conditions:
- The owner of the mutex has not changed.
- The owner is on a processor.
If both of the conditions satisfy, keep spinning. Otherwise, try
test-and-set. The pseudo-code would look like this:
while (!_obtain_lock(m, td)) {
mtx_lock_spin(&sched_lock);
if (unowned(m)) {
mutex_unlock_spin(&sched_lock);
continue;
}
owner = mtx_owner(m);
if (oncpu(owner)) {
bump_priority(owner, td);
/* Spin without holding sched_lock. */
critical_enter();
mtx_unlock_spin(&sched_lock);
while (owner == mtx_owner(m) && oncpu(owner)) {
/* Handle interrupts. */
critical_exit();
/* Spin. */
critical_enter();
}
critical_exit();
continue;
}
sleep(td);
mutex_unlock_spin(&sched_lock);
}
The code above does not use any test-and-set instructions, nor does it
keep bumping the priority of the owner during spinning.
--
Seigo Tanimura <[EMAIL PROTECTED]> <[EMAIL PROTECTED]>
To Unsubscribe: send mail to [EMAIL PROTECTED]
with "unsubscribe freebsd-current" in the body of the message
Re: preemption across processors
On Wed, 15 May 2002 08:21:46 -0400 (EDT),
John Baldwin <[EMAIL PROTECTED]> said:
jhb> On 15-May-2002 Seigo Tanimura wrote:
>> Currently, a new runnable thread cannot preempt the thread on any
>> processor other than the thread that called mi_switch(). For
>> instance, we do something like the following in _mtx_unlock_sleep():
>>
>> --- v --- _mtx_unlock_sleep() --- v ---
>> setrunqueue(th_waken_up);
>> if (curthread->preemptable && th_waken_up->priority < curthread->priority) {
>> setrunqueue(curthread);
>> mi_switch();
>> }
>> --- ^ --- _mtx_unlock_sleep() --- ^ ---
>>
>> If the priority of curthread is higher than th_waken_up, we cannot run
>> it immediately even if there is another processor running a thread
>> with a priority lower than th_waken_up. th_waken_up should preempt
>> that processor, or we would end up with a priority inversion.
>>
>> Maybe we have to dispatch a runnable thread to the processor running
>> a thread with the lowest priority. Solaris seems to take the
>> following steps to do that:
>>
>> 1. If a new thread has slept for longer than 3/100 seconds (this
>> should be tunable), linearly search the processor running a thread
>> with the lowest priority. Otherwise, choose the processor that ran
>> the new thread most recently.
>>
>> 2. Make an inter-processor interrupt to the processor chosen in 1.
>>
>> 3. The chosen processor puts its current thread back to the dispatch
>> queue and performs a context switch to run the new thread.
>>
>> Above is only a rough sketch. We have to watch out for a race of
>> inter-processor interrupts and a processor entering a critical section.
>>
>> If no one is working on preemption across processors, I would like to
>> see if I can do that.
jhb> I actually think that the little gain this brings isn't worth the extra
jhb> effort involved personally. We don't have to get things perfect, getting
jhb> them reasonably close is good enough for some things. However, that is
jhb> only my opinion. If the code to support this is relatively clean and
jhb> simple with low-impact in the normal case then I would support it. However,
jhb> there are several tricky race conditions here so I'm not sure it can be
jhb> done simply.
The prototype patch is at:
http://people.FreeBSD.org/~tanimura/patches/ippreempt.diff.gz
And the p4 depot
//depot/user/tanimura/ippreempt/...
The patch is for only i386 at the moment.
The following is the brief description of the patch:
--- v --- Description --- v ---
Overview:
setrunqueue() finds for a newly runnable thread the processor running
the thread with the lowest priority by chooseprocessor(). setrunqueue()
then marks the priority of the new thread on the processor chosen for
preemption.
If the processor chosen is not the current processor, setrunqueue()
notifies the processor by making a preemption IPI to the processor
chosen, where the IPI handler calls dispatchthread(). If the current
processor is chosen for preemption, setrunqueue() directly calls
dispatchthread().
dispatchthread() grabs the thread with the highest priority from the
run queue. If the current thread is running and has a higher priority
than the thread grabbed, dispatchthread() returns. Otherwise,
dispatchthread() puts the current thread back to the run queue (if it
is not an idle thread) and switches to the thread grabbed. If the
current thread is going to sleep, (i.e. its state is SSLEEP, SSTOP,
etc.) we always switch to the thread grabbed.
Implementation:
Call dispatchthread() instead of mi_switch() in msleep(), cv_*wait*(),
etc. in order to give up the current processor.
setrunqueue() no longer requires maybe_resched() in wakeup() and the
preemption check in _mtx_unlock_sleep(). If it is not appropriate to
preempt the current processor, call setrunqueue() in a critical
section. Note that setrunqueue() may dispatch the thread passed to a
processor other than the current one.
Miscellaneous stuff:
If a thread spins for an adaptive mutex, propagate its priority to the
owner thread of the mutex. This prevents preemption of the owner
thread by a thread with the priority in between the owner thread and
the spinning thread.
In order to make a space in the IPI priority for a preemption IPI,
raise the IPI priority of Xcpustop and Xinvltlb by one.
An idle processor no longer has to check whether or not there is a
runnable thread. Halt an idle processor in an SMP kernel as in a UP
kernel.
--- ^ --- Description --- ^ ---
The time taken for configuring, depending, compiling and linking a
GENERIC kernel was measured by time(1) for the vanilla kernel and the
patched one. Both of the kernels omit INVARIANTS, INVARIANT_SUPPORT
and WITNESS*.
preemption across processors
Currently, a new runnable thread cannot preempt the thread on any
processor other than the thread that called mi_switch(). For
instance, we do something like the following in _mtx_unlock_sleep():
--- v --- _mtx_unlock_sleep() --- v ---
setrunqueue(th_waken_up);
if (curthread->preemptable && th_waken_up->priority < curthread->priority) {
setrunqueue(curthread);
mi_switch();
}
--- ^ --- _mtx_unlock_sleep() --- ^ ---
If the priority of curthread is higher than th_waken_up, we cannot run
it immediately even if there is another processor running a thread
with a priority lower than th_waken_up. th_waken_up should preempt
that processor, or we would end up with a priority inversion.
Maybe we have to dispatch a runnable thread to the processor running
a thread with the lowest priority. Solaris seems to take the
following steps to do that:
1. If a new thread has slept for longer than 3/100 seconds (this
should be tunable), linearly search the processor running a thread
with the lowest priority. Otherwise, choose the processor that ran
the new thread most recently.
2. Make an inter-processor interrupt to the processor chosen in 1.
3. The chosen processor puts its current thread back to the dispatch
queue and performs a context switch to run the new thread.
Above is only a rough sketch. We have to watch out for a race of
inter-processor interrupts and a processor entering a critical section.
If no one is working on preemption across processors, I would like to
see if I can do that.
Thanks.
--
Seigo Tanimura <[EMAIL PROTECTED]> <[EMAIL PROTECTED]>
To Unsubscribe: send mail to [EMAIL PROTECTED]
with "unsubscribe freebsd-current" in the body of the message
Re: The updated socket patch and axing sotryfree() (Re: Locking down a socket, milestone 1)
On Wed, 8 May 2002 09:16:56 -0700, Alfred Perlstein <[EMAIL PROTECTED]> said: bright> * Seigo Tanimura <[EMAIL PROTECTED]> [020508 04:59] wrote: >> >> I would like to commit this patch in one or two weeks to start working >> on a possible race between a user process and a netisr kthread, >> prevented by only the Giant lock at the moment. >> >> When a user process calls sofree() for a listening socket, it attempts >> to free the sockets in the connection queues by soabort(). If the >> connection of an aborting socket gets dropped by a remote host (eg by >> TCP RST), a netisr kthread also attempts to free the socket. Since >> the reference count of a socket in a connection queue is zero, this >> would resust in doubly freeing a socket. >> >> To solve that problem, I would like to axe sotryfree(). The PCB of a >> socket and a connection queue should hold a reference to the >> socket. This should make the reference count of an alive socket always >> be >= 1, and ensure that there is only one referer to a socket to be >> freed. >> >> Comments? bright> I'm not sure exactly how this solves the problem, there may need to bright> be a global socket mutex, perhaps putting this sort of operation under bright> that may do what you want. Yes, at least, we should introduce a global lock to protect the relation between sockets and PCBs. bright> Off the top of my head... bright> I think one way of doing it is storing the hashlist that the socket bright> belongs to (inpcb_hash) inside the sockets. That way after a lookup bright> you will have the lock on the parent structure, a user process will bright> have to follow the same locking paradym, basically look at the head bright> socket, lock the hashlist, then manipulate the incomplete queue. bright> Basically, protect this sort of operation via the hashlist because bright> you pretty much need to anyway. :) In order to solve the issue of deallocation race by a hashlist lock, we *always* have to obtain a socket or a PCB by looking up a hashlist. This is quite problematic because: 1. the lock order between a socket and a PCB gets tangled, 2. a hashlist introduces an overhead of calculating a hash index value, and 3. a hashlint lock cannot be per-socket or per-PCB, resulting in a contention under a huge number of socket operations or incoming packets. In order to make our lock strategy readable and comprehensible, we should keep a lock order as simple as the following: 1. a lock to protect the relation between/among objects, (eg the proctree lock or the allproc lock) and 2. a lock dedicated to a single object. (eg a proc lock) A reference count allows us a flexible way to keep a lock order clean. Once we grabbed a reference to an object, we can unlock it completely to restart with locking any lock protecting a relation. For instance, in the interrupt handler of a protocol stack, you lock a hashlist to look up the PCB appropriate to an incoming packet. You then lock the PCB to do some work. If you have to modify the socket corresponding to the PCB, hold a reference to the PCB and unlock it. Now you can lock the relation between sockets and PCBs to grab the socket safely. This strategy should be applicable to a socket operation initiated by a user process as well. We will not have to worry about the lock order between a socket and a PCB. Another advantage of a reference count is its cost. Provided that we hold an appropriate lock, we can simply follow a pointer to obtain an object. This is much cheaper than we calculate a hash index. We can also reduce the contention over a lock because the lock of a reference count is per-socket or per-PCB. bright> Other than that, have you looked at what BSD/os does and what Linux bright> does? Do they get it wrong or have any particular drawbacks? BSD/OS seems to ensure the existence of a PCB by locking the hashlist of PCBs. I am worrying about the fact that they lock the hashlist for quite a long duration. (about a half of udp_input() hold a read lock, and almost all of tcp_input() hold a *write* lock.) -- Seigo Tanimura <[EMAIL PROTECTED]> <[EMAIL PROTECTED]> To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
Re: Locking down a socket, milestone 1
On Thu, 25 Apr 2002 11:04:32 -0700 (PDT), [EMAIL PROTECTED] (Jeffrey Hsu) said: hsu> If you compare the two approaches, the BSD/OS approach is simpler hsu> because it is coarse. You're confusing finer grain locking with hsu> better. Well, maybe my patch just seems more fine-grained than BSD/OS because I have locked down only a part of the data in a socket. When all of the data in a socket is locked down, my work should look more coarser than now. -- Seigo Tanimura <[EMAIL PROTECTED]> <[EMAIL PROTECTED]> To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
Re: Locking down a socket, milestone 1
On Wed, 24 Apr 2002 20:08:56 +0900, Seigo Tanimura <[EMAIL PROTECTED]> said: Seigo> I am now working on locking down a socket. (I have heard that Jeffrey Seigo> Hsu is also doing that, but I have never seen his patch. Has anyone Seigo> seen that?) My first milestone patch is now available at: Seigo> http://people.FreeBSD.org/~tanimura/patches/socket_milestone1.diff.gz I ripped off and committed the part of a sigio lock. The updated patch is found at: http://people.FreeBSD.org/~tanimura/patches/socket_milestone1a.diff.gz -- Seigo Tanimura <[EMAIL PROTECTED]> <[EMAIL PROTECTED]> To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
A sigio lock (was: Re: Locking down a socket, milestone 1)
On Thu, 25 Apr 2002 18:01:51 +0900, Seigo Tanimura <[EMAIL PROTECTED]> said: Seigo> On Thu, 25 Apr 2002 01:36:44 -0700, Seigo> Alfred Perlstein <[EMAIL PROTECTED]> said: bright> * Seigo Tanimura <[EMAIL PROTECTED]> [020425 01:19] wrote: >>> >> >>> >> http://people.FreeBSD.org/~tanimura/patches/socket_milestone1.diff.gz >>> >> bright> Why is there a "sigio" lock in this delta? Seigo> I should have stripped that out, but my patch would result in lock Seigo> order reversal between a socket lock and a process lock. As we Seigo> protect p_fd by a process lock, we have to lock it prior to locking a Seigo> file descriptor or a socket. Seigo> I suppose I have to commit the stripped patch of a sigio lock first. The patch of a sigio lock is not stripped out at: http://people.FreeBSD.org/~tanimura/patches/sigio.diff.gz -- Seigo Tanimura <[EMAIL PROTECTED]> <[EMAIL PROTECTED]> To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
Re: Locking down a socket, milestone 1
On Thu, 25 Apr 2002 01:36:44 -0700, Alfred Perlstein <[EMAIL PROTECTED]> said: bright> * Seigo Tanimura <[EMAIL PROTECTED]> [020425 01:19] wrote: >> >> >> >> http://people.FreeBSD.org/~tanimura/patches/socket_milestone1.diff.gz >> >> bright> Why is there a "sigio" lock in this delta? I should have stripped that out, but my patch would result in lock order reversal between a socket lock and a process lock. As we protect p_fd by a process lock, we have to lock it prior to locking a file descriptor or a socket. I suppose I have to commit the stripped patch of a sigio lock first. Speaking of the sigio lock, is that likely to apply to a pipe as well? -- Seigo Tanimura <[EMAIL PROTECTED]> <[EMAIL PROTECTED]> To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
Re: Locking down a socket, milestone 1
On Wed, 24 Apr 2002 10:18:01 -0400 (EDT), John Baldwin <[EMAIL PROTECTED]> said: jhb> On 24-Apr-2002 Seigo Tanimura wrote: >> I am now working on locking down a socket. (I have heard that Jeffrey >> Hsu is also doing that, but I have never seen his patch. Has anyone >> seen that?) My first milestone patch is now available at: >> >> >> http://people.FreeBSD.org/~tanimura/patches/socket_milestone1.diff.gz >> >> >> The works I have done so far are: >> >> >> - Determine the lock required to protect each of the members in struct >> socket. >> >> - Add mutexes to each of the sockbufs in a socket as BSD/OS does. >> >> - Lock down so_count, so_options, so_linger and so_state. >> >> - Add a global mutex socq_lock to protect the connection queues of a >> listening socket. Lock socq_lock to lock two sockets at once, >> followed by enqueuing or dequeuing a socket, or moving a socket across >> queues. socq_lock is not an sx lock because we usually have to lock >> two sockets to modify them. jhb> Do you actually lock two sockets at once or do you lock one at a time while jhb> holding socq_lock. If you do lock two at once, what is the defined locking jhb> order? At the moment, I lock two sockets at once. This is required, eg in soisconnected() to move an accepting socket across the connection queues of a listening socket. The lock order is: 1. socq_lock 2. an accepting socket 3. a listening socket (in so_head of the accepting socket) -- Seigo Tanimura <[EMAIL PROTECTED]> <[EMAIL PROTECTED]> To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
Re: Locking down a socket, milestone 1
On Wed, 24 Apr 2002 08:57:41 -0400, Bosko Milekic <[EMAIL PROTECTED]> said: bmilekic> I've literally just had time to glance at this so far, but can you, if bmilekic> you don't mind, please just briefly explain what BSD/OS does with bmilekic> sockbuf locking (do they use the same lock, or...?) In BSD/OS, each of the sockbufs in a socket has a mutex. It protects the data in the sockbuf. In addition, the mutex of the receive sockbuf also protects the whole data of the socket as well. BSD/OS seems to have no global locks to protect the relation between sockets. One thing I am not sure is the lock requirement upon waking up a process tsleeping for socket operation. In BSD/OS, some parts wake up processes with a socket locked, while the other parts not. I am going to make all of the functions calling sowakeup() to lock a socket first. -- Seigo Tanimura <[EMAIL PROTECTED]> <[EMAIL PROTECTED]> To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
Locking down a socket, milestone 1
I am now working on locking down a socket. (I have heard that Jeffrey Hsu is also doing that, but I have never seen his patch. Has anyone seen that?) My first milestone patch is now available at: http://people.FreeBSD.org/~tanimura/patches/socket_milestone1.diff.gz The works I have done so far are: - Determine the lock required to protect each of the members in struct socket. - Add mutexes to each of the sockbufs in a socket as BSD/OS does. - Lock down so_count, so_options, so_linger and so_state. - Add a global mutex socq_lock to protect the connection queues of a listening socket. Lock socq_lock to lock two sockets at once, followed by enqueuing or dequeuing a socket, or moving a socket across queues. socq_lock is not an sx lock because we usually have to lock two sockets to modify them. - Add a global sx sigio_lock to protect the pointer to the sigio object of a socket. This is to avoid lock order reversal caused by locking a process in pgsigio(). This lock should be applicable to a pipe as well. Although there are still lots of works to do, the patch has grown up quite a lot. so_options is the most notorious member in struct socket so far because it is used in almost all of the protocol stacks. I would therefore like to test, fix and merge the patch before it blows up. Comments are welcome. Thanks. -- Seigo Tanimura <[EMAIL PROTECTED]> <[EMAIL PROTECTED]> To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
Re: -current lock warning...
On Sat, 16 Mar 2002 22:56:58 +0900, Seigo Tanimura <[EMAIL PROTECTED]> said: Seigo> On Sat, 16 Mar 2002 10:22:22 +0100, Seigo> Poul-Henning Kamp <[EMAIL PROTECTED]> said: Seigo> Poul-Henning> acquiring duplicate lock of same type: "thrd_sleep" Seigo> Poul-Henning> 1st @ ../../../vm/vm_map.c:2288 Seigo> Poul-Henning> 2nd @ ../../../vm/vm_kern.c:172 Seigo> (snip) Seigo> Poul-Henning> _vm_map_lock(c038afb4,c02f8440,ac,c034a840,1) at _vm_map_lock+0x16 Seigo> Poul-Henning> kmem_alloc(c038afb4,3000,c0e41a00,0,c02fa434) at kmem_alloc+0x41 Seigo> Poul-Henning> _zget(c0e41a00,bfc0,0,c0435cd0,c0281769) at _zget+0xfa Seigo> Poul-Henning> zalloc(c0e41a00,c034a840,1,c02f8630,a7) at zalloc+0x3b Seigo> Poul-Henning> vmspace_alloc(0,bfc0,c035c940,c02f8630,8f0) at vmspace_alloc+0x2d Seigo> Poul-Henning> vmspace_fork(c035c940,cbb9ad24,c0331f84,cbb9ab00,c0331d60) at vmspace_fork+0x4d Seigo> Poul-Henning> vm_forkproc(c0332080,cbb9ab00,cbb9ac00,20014) at vm_forkproc+0xc6 Seigo> This seems due to naming all of the vm map locks as "thrd_sleep." The Seigo> locks of vm maps should have their own hierarachy. For instance, lock Seigo> the map of a process vm space first, then lock the kernel_map. The patch attached below renames the lock of the kernel_map to "kernel_map" once witness gets ready to run. This eliminated all of the lock order reversals on my PC. vm_map_renamelock.diff Description: Binary data -- Seigo Tanimura <[EMAIL PROTECTED]> <[EMAIL PROTECTED]>
Re: -current lock warning...
On Sat, 16 Mar 2002 10:22:22 +0100, Poul-Henning Kamp <[EMAIL PROTECTED]> said: Poul-Henning> acquiring duplicate lock of same type: "thrd_sleep" Poul-Henning> 1st @ ../../../vm/vm_map.c:2288 Poul-Henning> 2nd @ ../../../vm/vm_kern.c:172 (snip) Poul-Henning> _vm_map_lock(c038afb4,c02f8440,ac,c034a840,1) at _vm_map_lock+0x16 Poul-Henning> kmem_alloc(c038afb4,3000,c0e41a00,0,c02fa434) at kmem_alloc+0x41 Poul-Henning> _zget(c0e41a00,bfc0,0,c0435cd0,c0281769) at _zget+0xfa Poul-Henning> zalloc(c0e41a00,c034a840,1,c02f8630,a7) at zalloc+0x3b Poul-Henning> vmspace_alloc(0,bfc0,c035c940,c02f8630,8f0) at vmspace_alloc+0x2d Poul-Henning> vmspace_fork(c035c940,cbb9ad24,c0331f84,cbb9ab00,c0331d60) at vmspace_fork+0x4d Poul-Henning> vm_forkproc(c0332080,cbb9ab00,cbb9ac00,20014) at vm_forkproc+0xc6 This seems due to naming all of the vm map locks as "thrd_sleep." The locks of vm maps should have their own hierarachy. For instance, lock the map of a process vm space first, then lock the kernel_map. -- Seigo Tanimura <[EMAIL PROTECTED]> <[EMAIL PROTECTED]> To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
Re: sx_upgrade() (was: Re: cvs commit: src/sys/kern kern_mtxpool.c src/sys/sys kernel.h src/sys/vm vm_fault.c vm_glue.c vm_map.c vm_map.h vm_pageout.c vm_zone.c)
On Sat, 16 Mar 2002 19:08:53 +0900, Seigo Tanimura <[EMAIL PROTECTED]> said: Seigo> Attached patch implements sx_upgrade() which should work as you said Seigo> above. This compiles fine, but is not tested yet. The last patch breaks INVARIANTS. This one compiles and seems to work. sx_upgrade.diff Description: Binary data -- Seigo Tanimura <[EMAIL PROTECTED]> <[EMAIL PROTECTED]>
sx_upgrade() (was: Re: cvs commit: src/sys/kern kern_mtxpool.c src/sys/sys kernel.h src/sys/vm vm_fault.c vm_glue.c vm_map.c vm_map.h vm_pageout.c vm_zone.c)
[Add jhb and move to -current]
On Fri, 15 Mar 2002 10:53:20 -0800,
Alfred Perlstein <[EMAIL PROTECTED]> said:
Alfred> * Brian F. Feldman <[EMAIL PROTECTED]> [020315 03:22] wrote:
>> Alfred Perlstein <[EMAIL PROTECTED]> wrote:
>> >
>> > What is the problem?
>>
>> Damn good question. Are the tracebacks related? If not, what are you
>> supposed to be telling me it's deadlocking on? I don't see the system being
>> deadlocked. What is it actually supposed to be blocked on?
>>
>> > Well basically you changed:
>> >
>> > ! static __inline__ int
>> > ! _vm_map_lock_upgrade(vm_map_t map, struct thread *td) {
>> > ! int error;
>> > !
>> > ! vm_map_printf("locking map LK_EXCLUPGRADE: %p\n", map);
>> > ! error = lockmgr(&map->lock, LK_EXCLUPGRADE, NULL, td);
>> > ! if (error == 0)
>> > ! map->timestamp++;
>> > ! return error;
>> > }
>> >
>> > into:
>> >
>> > ! _vm_map_lock_upgrade(vm_map_t map, const char *file, int line)
>> > {
>> > ! vm_map_printf("locking map LK_EXCLUPGRADE: %p\n", map);
>> > ! if (_sx_try_upgrade(&map->lock, file, line)) {
>> > ! map->timestamp++;
>> > ! return (0);
>> > ! }
>> > ! return (EWOULDBLOCK);
>> > }
>>
>> It doesn't need LK_EXCLUPGRADE semantics, only LK_UPGRADE, if it's not
>> blocking. It backs out completely and unlocks the shared reference and
>> tries for an exclusive lock.
Alfred> Sigh, you're making me do all the work here... :(
Alfred> lockmgr(&map->lock, LK_EXCLUPGRADE, NULL, td);
Alfred> means:
Alfred> Turn my shared lock into an exclusive lock,
Alfred> if it's shared then wait for all shared locks to drain,
Alfred> however if someone else is requesting an exclusive lock, then fail.
Alfred> _sx_try_upgrade(&map->lock, file, line)
Alfred> means:
Alfred> Give me an exclusive lock
Alfred> if anyone else has a shared lock then fail immediately.
Alfred> What happens in your case is that you get into a busy loop
Alfred> because you never yeild the processor.
Alfred> This happens in vm_map_lookup() because of this:
Alfred> if (fault_type & VM_PROT_WRITE) {
Alfred> /*
Alfred> * Make a new object, and place it in the object
Alfred> * chain. Note that no new references have appeared
Alfred> * -- one just moved from the map to the new
Alfred> * object.
Alfred> */
Alfred> if (vm_map_lock_upgrade(map))
Alfred> goto RetryLookup;
Alfred> So, you fail your sx_lock upgrade and cause the cpu to spin.
Alfred> You basically need to add logic to the sxlock subsystem to do what
Alfred> lockmgr does, actually wait for the others to go away or fail if
Alfred> someone else wants an upgrade.
Attached patch implements sx_upgrade() which should work as you said
above. This compiles fine, but is not tested yet.
sx_upgrader records the thread that wants to upgrade. If sx_upgrader
is non-NULL, sx_sunlock() wakes up the upgrader rather than other
exclusive lock waiters.
sx_upgrade.diff
Description: Binary data
--
Seigo Tanimura <[EMAIL PROTECTED]> <[EMAIL PROTECTED]>
Re: setpgrp(1, 1) does not FAIL
On Thu, 28 Feb 2002 22:14:56 +1100 (EST), Bruce Evans <[EMAIL PROTECTED]> said: Takanori> Can you look into PR kern/29844 as well? Takanori> I think after your fix, it should fail even when invoked by super Takanori> user. >> >> The superuser fails as well. bde> setpgrp() is the same as setpgid() in FreeBSD, and the POSIX.1-200x-draft7 bde> documentation for setpgid() doesn't seem to have any special cases for bde> the superuser, so I think the documentation change in the PR is correct. While we are here, it would be even better to clarify the requirements of setpgid(2) like this: The affected process must: o be a descendant of the invoking process, and o belong to the same session as the invoking process does. Takanori's test fails even by the superuser because pid 1 belongs to a different session from curproc's one. bde> POSIX now has setpgrp(), but it is quite different from setpgid() :-(. Not sure if this is what you mean, but setpgrp(2) of Solaris is somewhat like setpgid(0, 0). Spaking of Solaris, the required condition of setpgid(2) in Solaris is a little bit more strict than that in FreeBSD. Solaris prohibits the grandchildren of the curproc to be the target of setpgid(2), while FreeBSD allows that. -- Seigo Tanimura <[EMAIL PROTECTED]> <[EMAIL PROTECTED]> To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
Re: setpgrp(1, 1) does not FAIL
On Thu, 28 Feb 2002 13:18:06 +0900, HIROSHI OOTA <[EMAIL PROTECTED]> said: oota> but, It should return EPERM instead of ESRCH. Because ESRCH oota> means `The requested process does not exist'. Setpgrp(2) should fail in this case because pid 1 (which is usually init(8)) is not a child of the curproc, not due to insufficient privilege. ESRCH means that the target process is not found in the children of the curproc. -- Seigo Tanimura <[EMAIL PROTECTED]> <[EMAIL PROTECTED]> To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
Re: setpgrp(1, 1) does not FAIL
[Please write in us-ascii]
On Thu, 28 Feb 2002 01:39:11 +0900,
Takanori Saneto <[EMAIL PROTECTED]> said:
Takanori> Can you look into PR kern/29844 as well?
Takanori> I think after your fix, it should fail even when invoked by super
Takanori> user.
The superuser fails as well.
Takanori> In article <[EMAIL PROTECTED]>,
Takanori> Seigo Tanimura <[EMAIL PROTECTED]> wrote:
>> On Wed, 27 Feb 2002 15:44:23 +0900,
>> HIROSHI OOTA <[EMAIL PROTECTED]> said:
oota> The following will succeed in non privilege user.
oota> I think it should fail.
oota> main()
oota> {
oota> printf("%d\n", setpgrp(1, 1));
oota> }
>> Fixed in rev 1.138 of kern/kern_prot.c, thanks!
--
Seigo Tanimura <[EMAIL PROTECTED]> <[EMAIL PROTECTED]>
To Unsubscribe: send mail to [EMAIL PROTECTED]
with "unsubscribe freebsd-current" in the body of the message
Re: setpgrp(1, 1) does not FAIL
On Wed, 27 Feb 2002 15:44:23 +0900,
HIROSHI OOTA <[EMAIL PROTECTED]> said:
oota> The following will succeed in non privilege user.
oota> I think it should fail.
oota> main()
oota> {
oota>printf("%d\n", setpgrp(1, 1));
oota> }
Fixed in rev 1.138 of kern/kern_prot.c, thanks!
--
Seigo Tanimura <[EMAIL PROTECTED]> <[EMAIL PROTECTED]>
To Unsubscribe: send mail to [EMAIL PROTECTED]
with "unsubscribe freebsd-current" in the body of the message
pgrp/session patch
Here is the most up-to-date version of pgrp/session lock (at Change 6700): http://people.FreeBSD.org/~tanimura/patches/pgrp10.diff.gz I would like to commit this on the next Sunday. Otherwise, my patch would conflict with other patches, especially tty. -- Seigo Tanimura <[EMAIL PROTECTED]> <[EMAIL PROTECTED]> To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
Request of review: pgrp + session patch
I am going to commit my work for quite a few months on locking a pgrp and session to -current in two weeks. The patch is at: http://people.FreeBSD.org/~tanimura/patches/pgrp.diff.gz This patch has been running quite well on my box with kern.giant.proc set to zero for more than a month. Could anyone interested please test the patch? Comments and suggestions are welcome. -- Seigo Tanimura <[EMAIL PROTECTED]> <[EMAIL PROTECTED]> To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
Re: Lock of struct filedesc, file, pgrp, session and sigio
On Fri, 13 Jul 2001 19:49:25 +0900, Seigo Tanimura said: Alfred> Certain operations, such as: Alfred> kq = (struct kqueue *)fp->f_data; Alfred> should not really require that the file be locked, it's implicitly frozen Alfred> at creation time (i think) Seigo> Yes. Only one exception beats off everything. union_dircheck() in fs/unionfs/union_subr.c may replace f_data with a new vnode. -- Seigo Tanimura <[EMAIL PROTECTED]> <[EMAIL PROTECTED]> To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
Re: Lock of struct filedesc, file, pgrp, session and sigio
On Fri, 13 Jul 2001 04:25:04 -0500, Alfred Perlstein <[EMAIL PROTECTED]> said: Alfred> This is just about completely file locking related, Alfred> however I do have a question about PGRP locking, in Alfred> a certain part you may have to lock two pgrps, how do you Alfred> deal with deadlock? Lock the session to which the pgrps belong first, then lock the pgrps. AFAIK, there are only two places to lock two pgrps, namely enterpgrp() and fixjobc() with an argument 'entering' set to nonzero. In both cases, either the pgrps belong to the same session or one of the pgrps belongs to a brand-new session with no other pgrps. Alfred> getvnode() Alfred> should FHOLD returned fp. Alfred> ibcs2_getdents(), ibcs2_statfs(), __acl_get_fd, __acl_set_fd, Alfred> __acl_aclcheck_fd(), __acl_delete_fd() Alfred> depends on getvnode doing FHOLD, once done needs fdrop() added Aaugh, I finished that work two hours ago :) Alfred> getvnode() Alfred> should actually be turned into "holdvnode" (implicit VREF) to do Alfred> reference holding. (later) Fine. Alfred> Certain operations, such as: Alfred> kq = (struct kqueue *)fp->f_data; Alfred> should not really require that the file be locked, it's implicitly frozen Alfred> at creation time (i think) Yes. -- Seigo Tanimura <[EMAIL PROTECTED]> <[EMAIL PROTECTED]> To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
Re: Lock of struct filedesc, file, pgrp, session and sigio
On Thu, 12 Jul 2001 01:44:44 -0500, Alfred Perlstein <[EMAIL PROTECTED]> said: Alfred> * Alfred Perlstein <[EMAIL PROTECTED]> [010712 01:42] wrote: >> * Seigo Tanimura <[EMAIL PROTECTED]> [010711 19:08] wrote: >> > >> > The patch and the results of build test are now on the web page. >> > >> > The discussion of ktrace(2) problem does not cover the solution of >> > BSD/OS, so it needs updating. >> >> I'm just reviewing the file stuff, I have a number of updates mainly >> in the areas of needing FFIND_HOLD/fdrop rather than just a simple >> FFIND. >> >> getvnode(p->p_fd, args->fd, &fp); >> >> I'm quite sure should implicitly do a FHOLD operation on the returned >> struct file, i don't see this, at least not in linux_getdents() >> (compat/linux/linux_file.c). Alfred> Or at least an fhold needs to be done before relasing the lock Alfred> on the struct file. Some functions modify a file descriptor, while others do not. At that point, what we need is a pair of FFIND and FFIND_LOCK. Both of them hold a file descriptor. FFIND_LOCK locks a file descriptor, while FFIND does not. -- Seigo Tanimura <[EMAIL PROTECTED]> <[EMAIL PROTECTED]> To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
Re: Lock of struct filedesc, file, pgrp, session and sigio
On Tue, 10 Jul 2001 18:03:40 +0900, Seigo Tanimura said: >>> >> I'm going to be giving this code some testing, not that you have to >>> >> wait for me to finish, but it seems like no one has stepped forward >>> >> to review this. I'd like to see it committed, so either go ahead >>> >> or wait for my review if it makes you more comfortable. >>> >> >>> >> Since I was working on the filedesc stuff I'll take a shot at reviewing >>> >> it, by way of the diff it looks somewhat ok, I just want to make sure >>> >> you're getting the fhold/fdrop stuff right. >>> Alfred> There's a merged diff here: >>> Alfred> http://people.freebsd.org/~alfred/pg_fd2.diff >>> >>> It is rather hard for me to dig up what you merged out of that >>> patch. Could you please give me unmerged one? Alfred> What I did was try to merge the work you've done into the latest Alfred> -current, it didn't work out too well. Perhaps you can remerge Alfred> it and pass it to me for testing? Seigo> I have already begun merging -current an hour ago. It would take Seigo> another 3-4 hours to test builing kernels, so could you please be Seigo> patient until the latest one gets ready to go? The patch and the results of build test are now on the web page. The discussion of ktrace(2) problem does not cover the solution of BSD/OS, so it needs updating. -- Seigo Tanimura <[EMAIL PROTECTED]> <[EMAIL PROTECTED]> To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
Re: Lock of struct filedesc, file, pgrp, session and sigio
On Wed, 11 Jul 2001 01:44:55 -0500, Alfred Perlstein <[EMAIL PROTECTED]> said: Alfred> I'm also quite sure that you can't call the ktrace functions with Alfred> any mutexes held so the code is doing to need some help, basically Alfred> the trick in trapsig() and postsig() is to generate the ktrace Alfred> IO after the locks have been dropped, this means somehow caching Alfred> the info sent to ktrace where it's currently called, and calling Alfred> it later with the cached info after the locks are dropped. >> Seigo> We can cache ktrace information into struct proc and mark the Seigo> existence of cache in p_traceflag. Then we send the information to Seigo> ktrace upon returning from trapsignal() or CURSIG(), or in sigexit(). >> >> msleep() and cv_*wait*() might receive a mutex held by curproc. As we >> cannot release the mutex to sleep in ktrwrite() during msleep() or >> cv_*wait*(), it is also necessary to cache information sent to >> ktrcsw(). >> >> Is it not feasible to examine the existence of cached ktrcsw() >> information upon every single call of msleep() and cv_*wait*() in >> order to flush the cached information. Instead of that, we should >> watch for release of mutexes. When a process no longer holds any >> mutexes except for Giant, it is safe to flush cached information to >> ktrace. Alfred> Yes, it's pretty gross. :( A problem of checking the cache upon release of a mutex is that we do not record the mutexes a process holds, which sounds expensive. BSD/OS solves that problem by a queue of ktrace data, which is what we refer to as cache, and by a helper kernel thread. A ktrace queue of BSD/OS, namely struct ktrace_control, is per vnode of a trace file, allocated dynamically. A record of trace data, also dynamically allocated, attaches to the queue of a trace file first. A kernel thread forked in ktrace(2) pulls records out of the queue, followed by writing them to the vnode of the trace file. The queue also holds free records of ktrace data so that a process holding mutexes can call ktrace_*(), The solution of BSD/OS looks promising in general. The only one issue I notice is that they do not allocate free records until the first call of ktrace_getxheader(). That would be fatal if a process holding mutexes records the first trace data for the queue. -- Seigo Tanimura <[EMAIL PROTECTED]> <[EMAIL PROTECTED]> To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
Re: Lock of struct filedesc, file, pgrp, session and sigio
On Wed, 11 Jul 2001 10:44:21 +0900, Seigo Tanimura <[EMAIL PROTECTED]> said: Alfred> I'm also quite sure that you can't call the ktrace functions with Alfred> any mutexes held so the code is doing to need some help, basically Alfred> the trick in trapsig() and postsig() is to generate the ktrace Alfred> IO after the locks have been dropped, this means somehow caching Alfred> the info sent to ktrace where it's currently called, and calling Alfred> it later with the cached info after the locks are dropped. Seigo> We can cache ktrace information into struct proc and mark the Seigo> existence of cache in p_traceflag. Then we send the information to Seigo> ktrace upon returning from trapsignal() or CURSIG(), or in sigexit(). The problem has turned out to be even worse. msleep() and cv_*wait*() might receive a mutex held by curproc. As we cannot release the mutex to sleep in ktrwrite() during msleep() or cv_*wait*(), it is also necessary to cache information sent to ktrcsw(). Is it not feasible to examine the existence of cached ktrcsw() information upon every single call of msleep() and cv_*wait*() in order to flush the cached information. Instead of that, we should watch for release of mutexes. When a process no longer holds any mutexes except for Giant, it is safe to flush cached information to ktrace. -- Seigo Tanimura <[EMAIL PROTECTED]> <[EMAIL PROTECTED]> To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
Re: Lock of struct filedesc, file, pgrp, session and sigio
On Mon, 9 Jul 2001 03:20:44 -0500, Alfred Perlstein <[EMAIL PROTECTED]> said: Alfred> I'm also quite sure that you can't call the ktrace functions with Alfred> any mutexes held so the code is doing to need some help, basically Alfred> the trick in trapsig() and postsig() is to generate the ktrace Alfred> IO after the locks have been dropped, this means somehow caching Alfred> the info sent to ktrace where it's currently called, and calling Alfred> it later with the cached info after the locks are dropped. We can cache ktrace information into struct proc and mark the existence of cache in p_traceflag. Then we send the information to ktrace upon returning from trapsignal() or CURSIG(), or in sigexit(). Another problem I noticed is bogus unlock and lock around call of machine-and-maybe-executable-format-dependent sendsig(), found in sys/*/*/machdep.c. Instead of locking curproc in sendsig() once again, we should call sendsig() with curproc locked, and release the lock only in sendsig(). -- Seigo Tanimura <[EMAIL PROTECTED]> <[EMAIL PROTECTED]> To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
Re: Lock of struct filedesc, file, pgrp, session and sigio
On Tue, 10 Jul 2001 03:53:47 -0500, Alfred Perlstein <[EMAIL PROTECTED]> said: Alfred> * Seigo Tanimura <[EMAIL PROTECTED]> [010710 03:46] wrote: >> On Mon, 9 Jul 2001 03:20:44 -0500, >> Alfred Perlstein <[EMAIL PROTECTED]> said: >> >> >> I'm going to be giving this code some testing, not that you have to >> >> wait for me to finish, but it seems like no one has stepped forward >> >> to review this. I'd like to see it committed, so either go ahead >> >> or wait for my review if it makes you more comfortable. >> >> >> >> Since I was working on the filedesc stuff I'll take a shot at reviewing >> >> it, by way of the diff it looks somewhat ok, I just want to make sure >> >> you're getting the fhold/fdrop stuff right. >> Alfred> There's a merged diff here: >> Alfred> http://people.freebsd.org/~alfred/pg_fd2.diff >> >> It is rather hard for me to dig up what you merged out of that >> patch. Could you please give me unmerged one? Alfred> What I did was try to merge the work you've done into the latest Alfred> -current, it didn't work out too well. Perhaps you can remerge Alfred> it and pass it to me for testing? I have already begun merging -current an hour ago. It would take another 3-4 hours to test builing kernels, so could you please be patient until the latest one gets ready to go? -- Seigo Tanimura <[EMAIL PROTECTED]> <[EMAIL PROTECTED]> To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
Re: Lock of struct filedesc, file, pgrp, session and sigio
On Mon, 9 Jul 2001 03:20:44 -0500, Alfred Perlstein <[EMAIL PROTECTED]> said: >> I'm going to be giving this code some testing, not that you have to >> wait for me to finish, but it seems like no one has stepped forward >> to review this. I'd like to see it committed, so either go ahead >> or wait for my review if it makes you more comfortable. >> >> Since I was working on the filedesc stuff I'll take a shot at reviewing >> it, by way of the diff it looks somewhat ok, I just want to make sure >> you're getting the fhold/fdrop stuff right. Alfred> There's a merged diff here: Alfred> http://people.freebsd.org/~alfred/pg_fd2.diff It is rather hard for me to dig up what you merged out of that patch. Could you please give me unmerged one? Thanks. -- Seigo Tanimura <[EMAIL PROTECTED]> <[EMAIL PROTECTED]> To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
Re: Lock of struct filedesc, file, pgrp, session and sigio
On Mon, 18 Jun 2001 19:04:31 +0900, Seigo Tanimura said: Seigo> The results of build test with the latest patch are now at: Seigo> http://people.FreeBSD.org/~tanimura/pg_fd/ Seigo> As it is likely to take quite a while to fix alpha, I am going to Seigo> update the patch every few days. The latest test on alpha shows successful build of a kernel. Is alpha fixed and working now? -- Seigo Tanimura <[EMAIL PROTECTED]> <[EMAIL PROTECTED]> To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
Re: Lock of struct filedesc, file, pgrp, session and sigio
On Mon, 04 Jun 2001 16:48:30 +0900, Seigo Tanimura said: David> It would also be nice to get a timeline on the commit schedule for this. >>> Test of 2 weeks should be enough, followed by commit in 15 June. David> I request that this be on hold until we actually get -current Alphas David> usable again. Seigo> OK, then we can test on pc98 and ia64 to wait for that. The results of build test with the latest patch are now at: http://people.FreeBSD.org/~tanimura/pg_fd/ As it is likely to take quite a while to fix alpha, I am going to update the patch every few days. -- Seigo Tanimura <[EMAIL PROTECTED]> <[EMAIL PROTECTED]> To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
Re: panic in procfs code
On Tue, 05 Jun 2001 12:21:46 +0200, Daniel Rock <[EMAIL PROTECTED]> said: Daniel> Hi, Daniel> I just noticed: Doing a simple "cat /proc/$$/map" panics the system: (snip) Daniel> _mtx_unlock_sleep(c049c9c0,0,c03b01a0,f2) at _mtx_unlock_sleep+0xa3 Daniel> lockmgr(c55fadb0,10001,c049c9c0,c55f4100) at lockmgr+0x9d Daniel> procfs_domap(c55f4100,c55f4320,c0c90da0,c6eefefc,c0cc3180) at Daniel> procfs_domap+0x88 Lock and unlock of vm_mtx around vm_map_(un)lock_read() in procfs_domap() are missing. The attached patch should fix the bug. Index: fs/procfs/procfs_map.c === RCS file: /home/naklab/tanimura/rina2/CVS/FreeBSD/sys/fs/procfs/procfs_map.c,v retrieving revision 1.1.1.1.8.1 diff -u -r1.1.1.1.8.1 procfs_map.c --- fs/procfs/procfs_map.c 2001/05/27 02:39:08 1.1.1.1.8.1 +++ fs/procfs/procfs_map.c 2001/06/05 12:16:06 @@ -87,6 +87,8 @@ if (uio->uio_offset != 0) return (0); + mtx_lock(&vm_mtx); + error = 0; if (map != &curproc->p_vmspace->vm_map) vm_map_lock_read(map); @@ -169,12 +171,17 @@ error = EFBIG; break; } + mtx_unlock(&vm_mtx); error = uiomove(mebuffer, len, uio); + mtx_lock(&vm_mtx); if (error) break; } if (map != &curproc->p_vmspace->vm_map) vm_map_unlock_read(map); + + mtx_unlock(&vm_mtx); + return error; } -- Seigo Tanimura <[EMAIL PROTECTED]> <[EMAIL PROTECTED]>
Re: Lock of struct filedesc, file, pgrp, session and sigio
On Thu, 31 May 2001 16:31:21 +0900, Seigo Tanimura said: Seigo> Lock of struct filedesc, file, pgrp, session and sigio is now ready Seigo> for testing. Although the patch is still under test, a new task proposal comes to my mind. A new task: lock underlying objects of struct file, namely a vnode, a socket, a pipe, a fifo and an event queue. A socket and a pipe is not mpsafe for now. A vnode (and a fifo) has an interlock, so it might already be mpsafe. An event queue is... up to jlemon? -- Seigo Tanimura <[EMAIL PROTECTED]> <[EMAIL PROTECTED]> To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
Re: Lock of struct filedesc, file, pgrp, session and sigio
On Sat, 2 Jun 2001 12:52:23 -0700, "David O'Brien" <[EMAIL PROTECTED]> said: David> On Fri, Jun 01, 2001 at 09:28:57PM +0900, Seigo Tanimura wrote: David> It would also be nice to get a timeline on the commit schedule for this. >> Test of 2 weeks should be enough, followed by commit in 15 June. David> I request that this be on hold until we actually get -current Alphas David> usable again. OK, then we can test on pc98 and ia64 to wait for that. Now what do I have to do to test on ia64? -- Seigo Tanimura <[EMAIL PROTECTED]> <[EMAIL PROTECTED]> To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
Re: Lock of struct filedesc, file, pgrp, session and sigio
On Fri, 1 Jun 2001 05:44:17 -0700, Kris Kennaway <[EMAIL PROTECTED]> said: David> Committers do not need Alpha users to verify that a patch compiles, David> Beast.freebsd.org can be used for that. Testing on a running system is David> of course a different matter. >> >> I will test building a GENERIC kernel with COMPAT_OSF1 after I get >> home, in a couple of hours. Kris> I think you misunderstand; David was referring to testing compilation Kris> on the alpha platform. beast.freebsd.org is available for FreeBSD Kris> committers for this purpose. I meant that I cannot start testing *right now* because I have to go back from my lab to my home in a few minutes, during which I will be offline. The test is going to be on beast, of course. -- Seigo Tanimura <[EMAIL PROTECTED]> <[EMAIL PROTECTED]> To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
Re: Lock of struct filedesc, file, pgrp, session and sigio
On Thu, 31 May 2001 13:01:56 -0700, "David O'Brien" <[EMAIL PROTECTED]> said: David> On Thu, May 31, 2001 at 12:54:26PM -0700, John Baldwin wrote: >> >> Lock of struct filedesc, file, pgrp, session and sigio is now ready >> >> for testing. >> >> >> >> The patch is at >> >> >> >> http://people.FreeBSD.org/~tanimura/patches/fd_pgrp.diff.gz >> > >> > Compiled on Alpha? >> >> I think that's what he means by "testing". :) I.e., he's ready for >> people to compile it and report problems, etc. David> Committers do not need Alpha users to verify that a patch compiles, David> Beast.freebsd.org can be used for that. Testing on a running system is David> of course a different matter. I will test building a GENERIC kernel with COMPAT_OSF1 after I get home, in a couple of hours. David> It would also be nice to get a timeline on the commit schedule for this. Test of 2 weeks should be enough, followed by commit in 15 June. -- Seigo Tanimura <[EMAIL PROTECTED]> <[EMAIL PROTECTED]> To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
Re: Lock of struct filedesc, file, pgrp, session and sigio
On Thu, 31 May 2001 16:31:21 +0900, Seigo Tanimura <[EMAIL PROTECTED]> said: Seigo> Lock of struct filedesc, file, pgrp, session and sigio is now ready Seigo> for testing. Seigo> The patch is at Seigo> http://people.FreeBSD.org/~tanimura/patches/fd_pgrp.diff.gz WARNING: rebuild any modules that provide filesystems if you are using them. getpid(2) should now be *really* mpsafe. -- Seigo Tanimura <[EMAIL PROTECTED]> <[EMAIL PROTECTED]> To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
Lock of struct filedesc, file, pgrp, session and sigio
Lock of struct filedesc, file, pgrp, session and sigio is now ready for testing. The patch is at http://people.FreeBSD.org/~tanimura/patches/fd_pgrp.diff.gz Below is the brief description of locking. 1. struct filedesc and struct file - fd_mtx protects struct filedesc. - f_mtx protects struct file. Refer to sys/file.h for detail. - Do not look up a file descriptor table directly but use FFIND* macros defined in sys/filedesc.h. They handle locking a file descriptor table and a file descriptor. - getvnode() locks a file descriptor. - p_fd may change during the life of a process if it is sharing its file descriptor table when the process calls execve(2). As nobody except curproc and the parent process in fork1() touches the file descriptor table of a process, the lock type of p_fd should be "(a) only touched by curproc or parent during fork/wait." 2. struct proc, struct pgrp and struct session - pgrphash_lock and pg_mtx protects struct pgrp. Refer to sys/proc.h for detail. - s_mtx protects struct session. Refer to sys/proc.h for detail. - Introduce p_pgrpmtx to protect p_pgrp of struct proc in cooperation with p_mtx. This allows locking of a process in a process group without lock order reversal. The lock order of them is shown below. 1st: p_pgrpmtx 2st: pg_mtx 3rd: p_mtx - You may lock more than one process groups provided that they belong to an identical session and you lock the session in advance. - psignal() requires the lock of the process group to which a destination process belongs if the property of a signal includes SA_STOP. PROC_LOCK_PSIGNAL() and PROC_UNLOCK_PSIGNAL() handle those lock and unlock. TODO: Pass a signal to PROC_(UN)LOCK_PSIGNAL() to avoid unnecessary lock. - pgsignal() requires the lock of a destination process group. 3. struct sigio - struct sigio forms a list(struct sigiolst), residing in a process or a process group. p_mtx of a process or pg_mtx of a process group is responsible to lock struct sigiolst. The members of struct sigio other than sio_pgsigio never change. - A macro FUNSETOWN locks the list of struct sigio, calls funsetown() and unlocks the list. -- Seigo Tanimura <[EMAIL PROTECTED]> <[EMAIL PROTECTED]> To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
RE: New strategy of locking a process group
On Tue, 22 May 2001 07:56:52 -0700 (PDT), John Baldwin <[EMAIL PROTECTED]> said: John> On 22-May-01 Seigo Tanimura wrote: >> On Tue, 22 May 2001 04:48:38 -0700 (PDT), >> John Baldwin <[EMAIL PROTECTED]> said: >> John> On 22-May-01 Seigo Tanimura wrote: >>>> For now, p_mtx protects p_pgrp in struct proc. This is quite >>>> troublesome for the following reason: >> John> Err, it doesn't really. It's mostly undecided at this point. Also, have you John> looked at the BSD/OS code on builder? They have process groups and sessions John> already locked not using global locks but using per-data structure locks. >> >> If you do not protect both p_pgrp and p_pglist in struct proc by an >> identical lock, you end up with breaking either setpgid(2) or kill(2) >> for a process group. The following scenario depicts an example of the >> breakage: John> I'll have to look over the code in more detail, but I would encourage you John> to check the BSD/OS code. I did that last night, and figured out that there are two problems in FreeBSD under the scenario shown below: 1. Lock a process and obtain a process group via p_pgrp. 2. Lock the process list of the process group and traverse the list via p_pglist, locking each process in the list. 3. Lock each process in the list. That scenario induces the following problems: A. We have to lock two processes at once in order to traverse the list, namely p and LIST_NEXT(p, p_pglist) where p is a process in the list. B. We have to lock a process in 1 and 3 while locking a process group in 2, resulting in lock order reversal. BSD/OS solves the problem A by locking not a process but a process group to traverse the list. It should be worth implementing that solution in FreeBSD. In order to solve the problem B, a lock other than the process lock should protect p_pgrp. BSD/OS adopts the lock of a session accessible via p_session embedded in struct proc, while I attempt to apply a global lock. In any case, the aim of the p_pgrp lock is essentially for protecting *only* p_pgrp. Once we lock p_pgrp, we can compare pg_session (which requires no locks), lock a process group, a session or etc. until unlocking p_pgrp. The issue of both of the solutions briefed above is that the p_pgrp lock protects *excess* data. It might be another solution to introduce a new mutex (p_pgrpmtx) into struct proc to lock p_pgrp. Although memory size costs per process, contention for p_pgrp lock should occur much less than to adopt a session lock or a global lock. As psignal() and some other functions also read p_pgrp, p_mtx should also lock p_pgrp. You lock either p_pgrpmtx or p_mtx to read p_pgrp, and both of the locks to modify p_pgrp. -- Seigo Tanimura <[EMAIL PROTECTED]> <[EMAIL PROTECTED]> To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
RE: New strategy of locking a process group
On Tue, 22 May 2001 21:58:10 +0900, Seigo Tanimura said: Seigo> On Tue, 22 May 2001 04:48:38 -0700 (PDT), Seigo> John Baldwin <[EMAIL PROTECTED]> said: John> On 22-May-01 Seigo Tanimura wrote: >>> For now, p_mtx protects p_pgrp in struct proc. This is quite >>> troublesome for the following reason: John> Err, it doesn't really. It's mostly undecided at this point. Also, have you John> looked at the BSD/OS code on builder? They have process groups and sessions John> already locked not using global locks but using per-data structure locks. Seigo> If you do not protect both p_pgrp and p_pglist in struct proc by an Seigo> identical lock, you end up with breaking either setpgid(2) or kill(2) Seigo> for a process group. The following scenario depicts an example of the Seigo> breakage: BSD/OS seems to solve that problem by having p_session in struct proc, and protecting p_pgrp by the mutex of both a process and a session. Then you have to lock a session as well as a process prior to reading p_pgrp, as I locked proctree_lock. I chose proctree_lock because deleting a process group may call funsetown(), which calls free(9). Maybe we can reconsider protecting by a session lock when free(9) becomes not to lock lockmgr. -- Seigo Tanimura <[EMAIL PROTECTED]> <[EMAIL PROTECTED]> To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
RE: New strategy of locking a process group
On Tue, 22 May 2001 04:48:38 -0700 (PDT), John Baldwin <[EMAIL PROTECTED]> said: John> On 22-May-01 Seigo Tanimura wrote: >> For now, p_mtx protects p_pgrp in struct proc. This is quite >> troublesome for the following reason: John> Err, it doesn't really. It's mostly undecided at this point. Also, have you John> looked at the BSD/OS code on builder? They have process groups and sessions John> already locked not using global locks but using per-data structure locks. If you do not protect both p_pgrp and p_pglist in struct proc by an identical lock, you end up with breaking either setpgid(2) or kill(2) for a process group. The following scenario depicts an example of the breakage: There is a process p that belongs to a process group G. A process q issues setpgid(2) to move p into a process group H, when the process p sends a signal to the process group to which p belongs by kill(2) with pid of zero. In this case, if p takes its new p_pgrp (which points to H) during which q attempts to remove p from G (this is possible if we lock p and G individually), p might fail to send the signal to p itself and the processes in H might receive a spurious signal. You might state that locking p_pgrp of p by p_mtx first and pg_members in G by pg_mtx (process group mutex) next should solve that problem. This method actually breaks kill(2) for a process group because our start point is now not a process but a process group. In this case, we should lock a process group first, followed by a process. The result is a lock order reversal and potential deadlock between setpgid(2) and kill(2). Of course, not all members of struct pgrp needs to be locked by a global lock. A lock per a process group is enough to protect pg_sigiolst and pg_jobc. Implementation of per-data structure locks is done for pgrp and in progress for session. Finally, a fact missing in my last mail. psignal() actually checks for the parent of a process, possibly sending SIGCHLD to it. This implies that we have to slock proctree_lock so that the process hierarchy does not change. Now that psignal() calls for both pgrpsess_lock and proctree_lock, it should be cheaper to have only proctree_lock than both of them. -- Seigo Tanimura <[EMAIL PROTECTED]> <[EMAIL PROTECTED]> To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
New strategy of locking a process group
For now, p_mtx protects p_pgrp in struct proc. This is quite
troublesome for the following reason:
In some cases, we grab a p_pgrp via struct proc in order to, say,
access the session information of the process group. In other cases,
we traverse the members of a process group in order to, say, send a
signal to the process group. Those cases imply that it is likely to
end up with lock order reversal if we adopt p_mtx to protect a process
group.
The lock of process groups should hence not in a certain struct but
global. Although proc.h suggests locking by proctree_lock, it is
actually not a good candidate of the process group lock because the
hierarchy of processes does not affect the process group membership of
a process provided that security constraints satisfy.
I have thus introduced a new sx lock, pgrpsess_lock to protect data
regarding process groups, namely the following ones:
global:
pgrphashtbl
struct proc:
p_pglist, p_pgrp
struct pgrp:
pg_hash, pg_members, pg_session
pg_session is here for the case where we attempt to confirm whether
two processes or process groups belong to an identical session, eg:
if (p->p_session == curproc->p_session) {...}
The lock order of pgrpsess_lock is between proctree_lock and p_mtx for
now.
The major impact of pgrpsess_lock is that you must slock pgrpsess_lock
to call psignal() and issignal() (not only pgsignal()!) because both
of them may read the data of a process group.
We may also have to introduce something like pfind_lockpgrp(), which
locks pgrpsess_lock upon returning. This eliminates a sequence of
PROC_UNLOCK() - sx_slock(&pgrpsess_lock) - PROC_LOCK() to avoid
unlocking a process.
Implementation of pgrpsess_lock is almost finished. The rest of the
work includes protection of the members in struct pgrp and session not
covered by pgrpsess_lock.
--
Seigo Tanimura <[EMAIL PROTECTED]> <[EMAIL PROTECTED]>
To Unsubscribe: send mail to [EMAIL PROTECTED]
with "unsubscribe freebsd-current" in the body of the message
RE: select(2) converted to use a condition variable, and optimis
On Wed, 09 May 2001 19:20:07 +0900, Seigo Tanimura said: Seigo> On Tue, 08 May 2001 08:21:55 -0700 (PDT), Seigo> John Baldwin <[EMAIL PROTECTED]> said: John> On 08-May-01 Seigo Tanimura wrote: >>> Here is another issue. PROC_LOCK may block to acquire a process lock, >>> during which an event of interest may occur or the remaining time of >>> select(2)/poll(2) may run out. Thus if the remaining time runs out >>> during locking a process, we should first rescan file descriptors to >>> avoid missing an event, followed by returning the result. John> Hmmm. Actually, can the nb_poll, ncp_poll, pollscan, or selscan functions call John> tsleep/msleep? If they don't, then we are just better off holding proc lock John> while we call them rather than releasing it just to call that function and John> acquiring it later. Then we don't have to work around the race you describe. Seigo> Poling functions called via fo_poll in a file descriptor should not Seigo> call msleep(9) in theory. Seigo> That does not, however, necessarily imply that we can scan file Seigo> descriptors with holding a process lock. Another process can release a Seigo> reference to a file descriptor via closef() during polling the Seigo> descriptor by calling its fo_poll. In this case, fdrop() subsequent to Seigo> the call of fo_poll may result the reference count of the descriptor Seigo> to be zero. Another issue that turned out just now is lock order reversal in selrecord(), where a process attempts to lock allproc sx while locking the process itself. You might see something like this in your dmesg: > lock order reversal > 1st 0xc7b9c31c process lock @ ../../kern/sys_generic.c:776 > 2nd 0xc0438800 allproc @ ../../kern/kern_proc.c:146 As it is essential in this case to lock allproc and check whether another process is waiting for an event, the only one option is to back out the change of scanning file descriptors with holding a process lock. -- Seigo Tanimura <[EMAIL PROTECTED]> <[EMAIL PROTECTED]> To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
atomic operation of flags (was: RE: select(2) converted to use a condition variable, and optimis)
On Mon, 07 May 2001 12:37:22 -0700 (PDT), John Baldwin <[EMAIL PROTECTED]> said: John> You need the lock when clearing the bit in p_flag. That is why the proc locks John> are there, so all those proc locks need to stay. When you clear a bit, you are John> writing all the bits, so you need to ensure that you can atomically John> read/modify/write all the bits in p_flag, hence the need for the proc lock. As we now have a set of atomic operation functions in machine/atomic.h, why do we not use them to read, modify and write p_flag atomically? Is that more expensive than protecting by PROC_LOCK and PROC_UNLOCK? -- Seigo Tanimura <[EMAIL PROTECTED]> <[EMAIL PROTECTED]> To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
Re: select(2) converted to use a condition variable, and optimis
On Thu, 10 May 2001 09:06:15 +0900, Seigo Tanimura <[EMAIL PROTECTED]> said: Seigo> A quick and hopefully efficient solution to those problems is to Seigo> fhold() struct file's first, then enter polling loop. That seems much Seigo> cheaper than to work on free()ing a vnode or a socket with holding a Seigo> process lock, provided that struct filedesc and file are protected Seigo> properly (and we have to do it anyway). That work is now in the patch at: http://people.FreeBSD.org/~tanimura/patches/selectopt.diff Another work in that patch is elimination of P_SELECT and nselcoll check just prior to waiting for selwait. As we now scan file descriptors with holding a process lock, race with selwakeup() should never occur during polling. Please note that netncp and netsmb are not in the scope the solution discussed above because we can neither lock nor hold a reference to a socket for now. Since several issues regarding to the file descriptor layer have risen up, I am planning to commit the patch soon and work on locking file descriptors. -- Seigo Tanimura <[EMAIL PROTECTED]> <[EMAIL PROTECTED]> To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
Re: select(2) converted to use a condition variable, and optimis
On Wed, 09 May 2001 09:21:09 -0700 (PDT), John Baldwin <[EMAIL PROTECTED]> said: >> Now the problem is whether it is easy or difficult to free a file >> descriptor with holding a process lock. At the level of the file >> descriptor layer, we can convert the memory allocator of a file >> descriptor from malloc(9) to the zone allocator, which locks only the >> zone state for file descriptors by a mutex. John> Free'ing is not all that problematic since it doesn't sleep. It is more John> problematic atm because it can result in lock order reversals due to lockmgr John> headaches. Eventually this won't become an issue I hope. >> It is a crucial issue to release an object underlying a file >> descriptor. Releasing a vnode can result in calling msleep(9) for >> locking the vnode in vrele(). Releasing a socket may end up with >> calling tsleep(9) for draining data if SO_LINGER is set. Hence we >> cannot scan file descriptors with holding a process lock for now. John> Argh, ok. Eventually this issue may go away as well. A quick and hopefully efficient solution to those problems is to fhold() struct file's first, then enter polling loop. That seems much cheaper than to work on free()ing a vnode or a socket with holding a process lock, provided that struct filedesc and file are protected properly (and we have to do it anyway). -- Seigo Tanimura <[EMAIL PROTECTED]> <[EMAIL PROTECTED]> To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
Re: select(2) converted to use a condition variable, and optimis
On Wed, 9 May 2001 13:33:54 -0700 (PDT), Matt Dillon <[EMAIL PROTECTED]> said: Matt> * The process's descriptor table Matt> * The struct file's referenced by that descriptor table Those are in my TODO list, and I have already started working on them. -- Seigo Tanimura <[EMAIL PROTECTED]> <[EMAIL PROTECTED]> To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
RE: select(2) converted to use a condition variable, and optimis
On Tue, 08 May 2001 08:21:55 -0700 (PDT), John Baldwin <[EMAIL PROTECTED]> said: John> On 08-May-01 Seigo Tanimura wrote: >> Here is another issue. PROC_LOCK may block to acquire a process lock, >> during which an event of interest may occur or the remaining time of >> select(2)/poll(2) may run out. Thus if the remaining time runs out >> during locking a process, we should first rescan file descriptors to >> avoid missing an event, followed by returning the result. John> Hmmm. Actually, can the nb_poll, ncp_poll, pollscan, or selscan functions call John> tsleep/msleep? If they don't, then we are just better off holding proc lock John> while we call them rather than releasing it just to call that function and John> acquiring it later. Then we don't have to work around the race you describe. Poling functions called via fo_poll in a file descriptor should not call msleep(9) in theory. That does not, however, necessarily imply that we can scan file descriptors with holding a process lock. Another process can release a reference to a file descriptor via closef() during polling the descriptor by calling its fo_poll. In this case, fdrop() subsequent to the call of fo_poll may result the reference count of the descriptor to be zero. Now the problem is whether it is easy or difficult to free a file descriptor with holding a process lock. At the level of the file descriptor layer, we can convert the memory allocator of a file descriptor from malloc(9) to the zone allocator, which locks only the zone state for file descriptors by a mutex. It is a crucial issue to release an object underlying a file descriptor. Releasing a vnode can result in calling msleep(9) for locking the vnode in vrele(). Releasing a socket may end up with calling tsleep(9) for draining data if SO_LINGER is set. Hence we cannot scan file descriptors with holding a process lock for now. John> Also, in the done_noproclock: case (might want to use 'unlock:' and 'done:' John> instead of 'done:' and 'done_noproclock:' for label names instead) are you John> always sure that when you go to that label you don't need to clear P_SELECT? select(2) and poll(2) set P_SELECT below retry: and clear P_SELECT upon occurrence of an event or timeout. There are no other places than them for a process to set P_SELECT in its p_flag. Thus we can assume at the entry of select(2) and poll(2) that P_SELECT is not set. We go to done_noproclock if and only if either copyin() or sanity check of arguments fails. As we do not poll any descriptors in this case, it is not necessary to clear P_SELECT. -- Seigo Tanimura <[EMAIL PROTECTED]> <[EMAIL PROTECTED]> To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
RE: select(2) converted to use a condition variable, and optimis
On Wed, 09 May 2001 19:20:07 +0900, Seigo Tanimura said: Seigo> That does not, however, necessarily imply that we can scan file Seigo> descriptors with holding a process lock. Another process can release a Seigo> reference to a file descriptor via closef() during polling the Seigo> descriptor by calling its fo_poll. In this case, fdrop() subsequent to Seigo> the call of fo_poll may result the reference count of the descriptor Seigo> to be zero. Hang on, the process that owns a file descriptor should be fhold()ing the descriptor. Since we never call closef() during waiting for an event, that problem described above is no more than absurd fear. -- Seigo Tanimura <[EMAIL PROTECTED]> <[EMAIL PROTECTED]> To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
RE: select(2) converted to use a condition variable, and optimis
On Mon, 07 May 2001 12:37:22 -0700 (PDT), John Baldwin <[EMAIL PROTECTED]> said: John> You need the lock when clearing the bit in p_flag. That is why the proc locks John> are there, so all those proc locks need to stay. When you clear a bit, you are John> writing all the bits, so you need to ensure that you can atomically John> read/modify/write all the bits in p_flag, hence the need for the proc lock. John> Please back out the changes to not lock the process around the p_flag change. John> The rest of the patch looks ok, though I'd like to review the updated version John> before it is committed. Thanks. Process locks are now back. Here is another issue. PROC_LOCK may block to acquire a process lock, during which an event of interest may occur or the remaining time of select(2)/poll(2) may run out. Thus if the remaining time runs out during locking a process, we should first rescan file descriptors to avoid missing an event, followed by returning the result. Those changes are now in the updated patch at: >> http://people.FreeBSD.org/~tanimura/patches/selectopt.diff -- Seigo Tanimura <[EMAIL PROTECTED]> <[EMAIL PROTECTED]> To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
select(2) converted to use a condition variable, and optimised
As conversion of select(2) from msleep(9) to a condition variable is
in the SMPng TODO list, I have done that task.
Also, we do not have to lock a process in order to evaluate the result
of {sel,poll}scan() and the remaining time of {select,poll}(2). It
should be enough to do those pieces of work first, followed by locking
a process and wait for a condition variable or selwakeup().
Those changes are in the patch at:
http://people.FreeBSD.org/~tanimura/patches/selectopt.diff
--
Seigo Tanimura <[EMAIL PROTECTED]> <[EMAIL PROTECTED]>
To Unsubscribe: send mail to [EMAIL PROTECTED]
with "unsubscribe freebsd-current" in the body of the message
Re: midi causes panic on boot? + entropy gatherer works fine
On Wed, 14 Mar 2001 00:49:53 -0800, Alex Zepeda <[EMAIL PROTECTED]> said: Alex> On Mon, Mar 12, 2001 at 04:38:50PM +0100, Szilveszter Adam wrote: >> I wonder if this is known? If not, I can certainly provide more >> information. The offending sound hw is a Creative SB 64 AWE ISAPnP card. It >> works fine otherwise. (as it always has) Alex> Yup I'm seeing this too. SMP kernel, AWE64 PnP. If the kernel attempts to probe mpu to die, my last commit should fix that. -- Seigo Tanimura <[EMAIL PROTECTED]> <[EMAIL PROTECTED]> To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
Re: midi panics
On Tue, 27 Feb 2001 22:53:06 +0900, "Daniel C. Sobral" <[EMAIL PROTECTED]> said: Daniel> I'm getting fatal trap 12 with interrupts disabled related to the midi Daniel> code during boot. Daniel> Backtrace is: Daniel> _mtx_lock_sleep+0x23a Daniel> mpu_uartmode+0x3e Daniel> mpu_attach+0x25 mpu_uartmode() is called before init of scp->mtx. -- Seigo Tanimura <[EMAIL PROTECTED]> <[EMAIL PROTECTED]> To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
MP-safe midi(4) and sequencer callout priority
The patch at http://people.FreeBSD.org/~tanimura/patches/midimutex.diff.gz makes midi(4) MP-safe. With this patch, my kernel with WITNESS and INVARIANTS plays my favorite midi tunes just fine, except that the callout used by the midi sequencer gets delayed under a heavy load. As the sequencer uses callout in order to wait until the next midi message is ready to be transmitted, the callout should run at PI_AV so that a tune will not sound messy. John, have you got any plan to modify the priority of a callout? Cameron, as pcm(4) interacts with few of the other subsystems in the kernel like midi(4), why don't you start making pcm(4) MP-safe? Multimedia devices should benefit very much from kernel execution in parallel. The only one thing to note is to not access a device in parallel to mess it up. We have to add a mutex to a device and share the mutex between the pcm part and the midi part of the driver. Could you please let me know when pcm(4) gets MP-safe, and we will see how we can share device mutexes between pcm(4) and midi(4). -- Seigo Tanimura <[EMAIL PROTECTED]> <[EMAIL PROTECTED]> To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
(Semi-)automatic update of installed ports (was: Re: pw_class in _pw_passwd is null if __hashpw() is not called in prior)
[cc'ed to -ports] On Sat, 30 Sep 2000 13:35:48 -0500 (CDT), Mike Meyer <[EMAIL PROTECTED]> said: Mike> Seigo Tanimura writes: >> Completely automatic update of installed ports is acutally difficult >> because we cannot get to know the language or required toolkit from >> the name of a binary. (eg emulator/wine and japanese/wine, timidity++-xaw >> and timidity++-tcltk) We can still detect and enumerate the ports that >> possibly installed old binaries, and decide which of the ports listed >> up to update. Mike> you. However, I believe you were talking about binaries that may have Mike> been built from a current port against an out-of-date system. Mike> Frankly, I'm not really interested in *detecting* such things. A tool Mike> that would 1) save tarballs of *all* installed ports; 2) uninstall Mike> them all; then 3) rebuild and install them all, with a report about Mike> failures would make me happy. How do you rebuild a port automatically if you want to hack the configure parameter or make variables of the port? -- Seigo Tanimura <[EMAIL PROTECTED]> <[EMAIL PROTECTED]> To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
Re: pw_class in _pw_passwd is null if __hashpw() is not called in prior
On Thu, 28 Sep 2000 11:55:55 -0500, "Jacques A. Vidrine" <[EMAIL PROTECTED]> said: >> It would also be helpful for us to (semi-)automatically update old >> binaries installed by ports. (I have been trying this for a couple of >> days) Jacques> Personally I don't want sysinstall or make world to touch my ports. Jacques> But a tool to do this would be great. Completely automatic update of installed ports is acutally difficult because we cannot get to know the language or required toolkit from the name of a binary. (eg emulator/wine and japanese/wine, timidity++-xaw and timidity++-tcltk) We can still detect and enumerate the ports that possibly installed old binaries, and decide which of the ports listed up to update. http://people.FreeBSD.org/~tanimura/tools/oldports is a shell script to scan the binaries installed by ports and to list up the name of the ports that installed binaries using libc.so.3 or earlier. -- Seigo Tanimura <[EMAIL PROTECTED]> <[EMAIL PROTECTED]> To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
Re: pw_class in _pw_passwd is null if __hashpw() is not called in prior
On Sun, 24 Sep 2000 10:08:12 -0500, "Jacques A. Vidrine" <[EMAIL PROTECTED]> said: n> changing them now. Unless objections come up, I'll commit this change n> or something similar with the next nsswitch commit. Here is another possible trouble. While libc.so.4 with nsswitch no longer requires the magic '+' entry, libc.so.3 and earlier still require '+'. What we need before 5.0-RELEASE meets the world is a tool to find binaries linked against libc.so.3 and earlier, and give a warning. It would also be helpful for us to (semi-)automatically update old binaries installed by ports. (I have been trying this for a couple of days) -- Seigo Tanimura <[EMAIL PROTECTED]> <[EMAIL PROTECTED]> To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
pw_class in _pw_passwd is null if __hashpw() is not called in prior
pw_class in _pw_passwd of src/lib/libc/gen/getpwdent.c is initialized
to null. Thus if a user other than root looks up nis by getpwuid(3) or
getpwnam(3) in prior to calling __hashpw, pw_class is null as well.
This breaks some applications including ssh(1) because they believe
that no members of struct passwd are null.
The following sample code shows the problem.
--- v --- sample --- v ---
#include
#include
#include
#include
int
main(void)
{
struct passwd *pw;
if ((pw = getpwuid(getuid())) != NULL)
printf("name:\t\%s\nclass:\t\%p\n", pw->pw_name, pw->pw_class);
}
--- ^ --- sample --- ^ ---
If you have your passwd entry in nis, you see something like this:
silver% ./getpwent
name: tanimura
class: 0x0
If your passwd entry is in /etc/master.passwd, the result looks like
this:
silver# ./getpwent
name: root
class: 0x804cc28
where 0x804cc28 points to an empty string, which is the expected
result.
As we are supposed to fill in all of the members in struct passwd
(like Solaris), _pw_passwd should have its initial value other than
zero.
static struct passwd _pw_passwd =
{
"",
"",
(uid_t)0, /* XXX Is zero appropriate? */
(gid_t)0,
(time_t)0,
"",
"",
"",
"",
(time_t)0,
0,
};
In addition, we should also reinitialize _pw_passwd by this initial
value before rewriting _pw_passwd, because pw_class filled in by
previous call to __hashpw might grant unauthorized use of resource or
account.
--
Seigo Tanimura <[EMAIL PROTECTED]> <[EMAIL PROTECTED]>
To Unsubscribe: send mail to [EMAIL PROTECTED]
with "unsubscribe freebsd-current" in the body of the message
Re: nsswitch meets current
On Wed, 6 Sep 2000 15:14:31 -0500, "Jacques A. Vidrine" <[EMAIL PROTECTED]> said: n> = host.conf has been removed from src/etc. rc.network has been modified n> to warn that host.conf is no longer used at boot time. In addition, if n> there is a host.conf but no nsswitch.conf, the latter is created at boot n> time from the former. You still need host.conf to run old binaries (including Netscape) linked against libc.so.3 and earlier. I prefer to warn 'host.conf is for compatibility with old libc.' -- Seigo Tanimura <[EMAIL PROTECTED]> <[EMAIL PROTECTED]> To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
the ifp to a removed pcmcia ethernet card is left in struct ip_moptions and struct ifmultiaddr
I have been suffering from this problem for almost 2 months. When I
remove a pcmcia ethernet card from my laptop PC, routed(8) announces
updated routing information by multicast, leading to a kernel
panic. The stack trace looks like this:
IdlePTD 4136960
initial pcb at 352840
panicstr: page fault
panic messages:
---
Syntax error: Unterminated quoted string
---
#0 boot (howto=256) at ../../kern/kern_shutdown.c:310
310 dumppcb.pcb_cr3 = rcr3();
(kgdb) bt
#0 boot (howto=256) at ../../kern/kern_shutdown.c:310
#1 0xc018f3e1 in panic (fmt=0xc02faf4f "page fault") at ../../kern/kern_shutdown.c:560
#2 0xc02b5043 in trap_fatal (frame=0xcb9b0d7c, eva=213493) at
../../i386/i386/trap.c:951
#3 0xc02b4ce5 in trap_pfault (frame=0xcb9b0d7c, usermode=0, eva=213493) at
../../i386/i386/trap.c:844
#4 0xc02b4877 in trap (frame={tf_fs = 16, tf_es = -969998320, tf_ds = 16, tf_edi =
-1058687232, tf_esi = -1058687744,
tf_ebp = -879030772, tf_isp = -879030872, tf_ebx = -1058661888, tf_edx =
-1067786268, tf_ecx = 213485, tf_eax = -1058661888,
tf_trapno = 12, tf_err = 0, tf_eip = -1071746146, tf_cs = 8, tf_eflags = 66054,
tf_esp = -1067786496, tf_ss = -879030720})
at ../../i386/i386/trap.c:443
#5 0xc01e739e in ip_output (m0=0xc05adf00, opt=0x0, ro=0xcb424dc8, flags=32,
imo=0xc0e5b700) at ../../netinet/ip_output.c:326
#6 0xc01e8e26 in rip_output (m=0xc05adf00, so=0xcae549c0, dst=33554656) at
../../netinet/raw_ip.c:234
#7 0xc01e9627 in rip_send (so=0xcae549c0, flags=0, m=0xc05adf00, nam=0xc0da7950,
control=0x0, p=0xc62f9f60) at ../../netinet/raw_ip.c:566
#8 0xc01b281f in sosend (so=0xcae549c0, addr=0xc0da7950, uio=0xcb9b0ed4,
top=0xc05adf00, control=0x0, flags=0, p=0xc62f9f60)
at ../../kern/uipc_socket.c:614
#9 0xc01b63be in sendit (p=0xc62f9f60, s=5, mp=0xcb9b0f14, flags=0) at
../../kern/uipc_syscalls.c:519
#10 0xc01b7998 in sendto (p=0xc62f9f60, uap=0xcb9b0f80) at
../../kern/uipc_syscalls.c:571
#11 0xc02b51ba in syscall2 (frame={tf_fs = 47, tf_es = 47, tf_ds = 47, tf_edi = 0,
tf_esi = 134727225, tf_ebp = -1077937408,
tf_isp = -879030316, tf_ebx = 134844928, tf_edx = 2, tf_ecx = -1, tf_eax = 133,
tf_trapno = 7, tf_err = 2, tf_eip = 134573992,
tf_cs = 31, tf_eflags = 659, tf_esp = -1077937484, tf_ss = 47}) at
../../i386/i386/trap.c:1150
#12 0xc02a8875 in Xint0x80_syscall ()
#13 0x8051b10 in ?? ()
#14 0x8050ff4 in ?? ()
#15 0x804c212 in ?? ()
#16 0x804813f in ?? ()
In ip_output(), imo->imo_multicast_ifp points to the removed
interface, which is passed to IN_LOOKUP_MULTI() to cause a panic. This
problem also occurs when we attempt to delete a multicast address from
a removed interface. if_delmulti() derefers an ifp to the removed
interface, ending up with a panic. The problem does not occur for
unicast.
http://people.FreeBSD.org/~tanimura/patches/mcastif.diff.gz is a
workround patch. The idea is to track all of the active ifps, confirm
an ifp to be active prior to dereferencing it, and free orphaned
ifmultiaddrs attached to a removed ifp. It would be much more elegant
if we could clean up the multicast information related to a removed
interface, though.
--
Seigo Tanimura <[EMAIL PROTECTED]> <[EMAIL PROTECTED]>
To Unsubscribe: send mail to [EMAIL PROTECTED]
with "unsubscribe freebsd-current" in the body of the message
Re: Newbusifying ed broke it
On Fri, 18 Aug 2000 09:56:56 +1000,
Peter Jeremy <[EMAIL PROTECTED]> said:
Peter> On 2000-Aug-17 16:55:57 +0900, Seigo Tanimura <[EMAIL PROTECTED]>
wrote:
>> On Thu, 17 Aug 2000 15:35:59 +1000,
>> Peter Jeremy <[EMAIL PROTECTED]> said:
>>
>> peter.jeremy> Still not working. It now reports:
>> peter.jeremy> ed0: failed to clear shared memory at 0 - check configuration
>>
>> The probe routine cleared and tested IO port instead of memory. Does
>> the following patch work?
Peter> No, sorry. Exactly the same as the previous patch - it still thinks
Peter> the shared memory is at 0.
The memory resource of the card might not be allocated properly. Could
you apply the following patch and report what your kernel print?
--- if_ed.c.org Thu Aug 17 16:05:59 2000
+++ if_ed.c Fri Aug 18 13:35:14 2000
@@ -435,6 +435,7 @@
&conf_maddr, &conf_msize);
if (error)
return (error);
+ device_printf(dev, "conf_maddr = 0x%x.\n", conf_maddr);
#if ED_DEBUG
printf("type = %x type_str=%s isa16bit=%d memsize=%d id_msize=%d\n",
@@ -535,6 +536,7 @@
return (error);
}
sc->mem_start = 0;
+ device_printf(dev, "tag(mem_res) = %d, handle(mem_res) = 0x%x.\n",
+rman_get_bustag(sc->mem_res), rman_get_bushandle(sc->mem_res));
/*
* allocate one xmit buffer if < 16k, two buffers otherwise
--
Seigo Tanimura <[EMAIL PROTECTED]> <[EMAIL PROTECTED]>
Re: Newbusifying ed broke it
an_get_bushandle(sc->port_res),
sc->asic_addr + ED_HPP_PAGE_4,
(u_int32_t *) data, len);
data += (len & ~3);
@@ -3364,8 +3364,8 @@
};
/* Default Set */
- sc->asic_addr = rman_get_start(sc->port_res) + ED_NOVELL_ASIC_OFFSET;
- sc->nic_addr = rman_get_start(sc->port_res) + ED_NOVELL_NIC_OFFSET;
+ sc->asic_addr = ED_NOVELL_ASIC_OFFSET;
+ sc->nic_addr = ED_NOVELL_NIC_OFFSET;
/* Reset Card */
tmp = ed_readb(sc, sc->asic_addr + ED_NOVELL_RESET);
ed_writeb(sc, sc->asic_addr + ED_NOVELL_RESET, tmp);
Index: if_ed_pccard.c
===
RCS file: /home/naklab/tanimura/rina2/CVS/FreeBSD/sys/dev/ed/if_ed_pccard.c,v
retrieving revision 1.1.1.3.6.4
diff -u -r1.1.1.3.6.4 if_ed_pccard.c
--- if_ed_pccard.c 2000/08/16 07:38:31 1.1.1.3.6.4
+++ if_ed_pccard.c 2000/08/17 07:21:35
@@ -144,9 +144,7 @@
attr_ioport = rdbuf[2] << 8 | rdbuf[0];
iobase = rman_get_start(sc->port_res);
if (attr_ioport != iobase) {
-#if notdef
- printf("AX88190 IOBASE MISMATCH %04x -> %04x
Setting\n",attr_ioport,iobase);
-#endif /* notdef */
+ /* Write the IO port address to the chip. */
ed_pccard_memwrite(dev,ED_AX88190_IOBASE0,iobase & 0xff);
ed_pccard_memwrite(dev,ED_AX88190_IOBASE1,(iobase >> 8) &
0xff);
}
Index: if_edvar.h
===
RCS file: /home/naklab/tanimura/rina2/CVS/FreeBSD/sys/dev/ed/if_edvar.h,v
retrieving revision 1.1.1.1.24.3
diff -u -r1.1.1.1.24.3 if_edvar.h
--- if_edvar.h 2000/08/16 07:38:31 1.1.1.1.24.3
+++ if_edvar.h 2000/08/17 07:21:35
@@ -48,9 +48,6 @@
struct resource* irq_res; /* resource for irq */
void* irq_handle; /* handle for irq handler */
- bus_space_tag_t bst;/* Bus Space tag */
- bus_space_handle_t bsh;/* Bus Space handle */
-
#ifdef __alpha__
u_int asic_addr;/* ASIC I/O bus address */
u_int nic_addr; /* NIC (DS8390) I/O bus address */
--
Seigo Tanimura <[EMAIL PROTECTED]> <[EMAIL PROTECTED]>
Re: Newbusifying ed broke it
sc->asic_addr = rman_get_start(sc->port_res) + ED_NOVELL_ASIC_OFFSET;
- sc->nic_addr = rman_get_start(sc->port_res) + ED_NOVELL_NIC_OFFSET;
+ sc->asic_addr = ED_NOVELL_ASIC_OFFSET;
+ sc->nic_addr = ED_NOVELL_NIC_OFFSET;
/* Reset Card */
tmp = ed_readb(sc, sc->asic_addr + ED_NOVELL_RESET);
ed_writeb(sc, sc->asic_addr + ED_NOVELL_RESET, tmp);
Index: if_ed_pccard.c
===
RCS file: /home/naklab/tanimura/rina2/CVS/FreeBSD/sys/dev/ed/if_ed_pccard.c,v
retrieving revision 1.1.1.3.6.4
diff -u -r1.1.1.3.6.4 if_ed_pccard.c
--- if_ed_pccard.c 2000/08/16 07:38:31 1.1.1.3.6.4
+++ if_ed_pccard.c 2000/08/17 03:38:37
@@ -144,9 +144,7 @@
attr_ioport = rdbuf[2] << 8 | rdbuf[0];
iobase = rman_get_start(sc->port_res);
if (attr_ioport != iobase) {
-#if notdef
- printf("AX88190 IOBASE MISMATCH %04x -> %04x
Setting\n",attr_ioport,iobase);
-#endif /* notdef */
+ /* Write the IO port address to the chip. */
ed_pccard_memwrite(dev,ED_AX88190_IOBASE0,iobase & 0xff);
ed_pccard_memwrite(dev,ED_AX88190_IOBASE1,(iobase >> 8) &
0xff);
}
Index: if_edvar.h
===
RCS file: /home/naklab/tanimura/rina2/CVS/FreeBSD/sys/dev/ed/if_edvar.h,v
retrieving revision 1.1.1.1.24.3
diff -u -r1.1.1.1.24.3 if_edvar.h
--- if_edvar.h 2000/08/16 07:38:31 1.1.1.1.24.3
+++ if_edvar.h 2000/08/17 03:38:37
@@ -48,9 +48,6 @@
struct resource* irq_res; /* resource for irq */
void* irq_handle; /* handle for irq handler */
- bus_space_tag_t bst;/* Bus Space tag */
- bus_space_handle_t bsh;/* Bus Space handle */
-
#ifdef __alpha__
u_int asic_addr;/* ASIC I/O bus address */
u_int nic_addr; /* NIC (DS8390) I/O bus address */
--
Seigo Tanimura <[EMAIL PROTECTED]> <[EMAIL PROTECTED]>
Re: DHCP client problem?
On Sun, 23 Jul 2000 13:26:02 -0700, Nick Sayer <[EMAIL PROTECTED]> said: Nick> Reversing that patch fixes it. Since the source for this is in contrib, Nick> I presume we Nick> need to send this back to ISC rather than patch it in our tree? Nick> Tatsumi Hosokawa wrote: (snip) >> - if [ x$old_ip_address = x ] || [ x$old_ip_address != x$new_ip_address ] || \ >> - [ x$reason = xBOUND ] || [ x$reason = xREBOOT ]; then >> -ifconfig $interface inet $new_ip_address $new_netmask_arg \ >> - $new_broadcast_arg $medium >> + if [ "x$old_ip_address" = "x" ] || [ "x$old_ip_address" != "x$new_ip_address" ] >|| \ >> + [ "x$reason" = "xBOUND" ] || [ "x$reason" = "xREBOOT" ]; then >> +ifconfig "$interface" inet "$new_ip_address" "$new_netmask_arg" \ >> + "$new_broadcast_arg" "$medium" Did you see this log? On Thu, 20 Jul 2000 02:53:11 -0700 (PDT), "David E. O'Brien" <[EMAIL PROTECTED]> said: David> obrien 2000/07/20 02:53:11 PDT David> Modified files: David> contrib/isc-dhcp/client/scripts freebsd David> Log: David> safe shell quoting David> Obtained from: OpenBSD (rev 1.6) And I have already suggested the following fix. On Sun, 23 Jul 2000 18:53:55 +0900, Seigo Tanimura <[EMAIL PROTECTED]> said: Seigo> 1. Seigo> This breaks ifconfig(8) in dhclient-script(8) because our ifconfig(8) Seigo> does not support both a parameter name and its argument to be in a Seigo> single argument. Seigo> What we need to do against dhclient-script(8) to prevent executing Seigo> arbitrary commands include: Seigo> - quoting the arguments from dhclient(8), and Seigo> - intializing the internal variables. Seigo> It should be a good idea to quote each argument from dhclient(8), Seigo> followed by substituting the argument to an internal variable in a way Seigo> like this: Seigo> new_netmask_arg="netmask \"$new_subnet_mask\"" Seigo> Then we do not have to quote all of the variables in dhclient-script(8). Seigo> 2. Seigo> An argument of "" is passed to ifconfig(8) if the value of $medium is Seigo> empty, making ifconfig(8) confused. This is because certain ethernet Seigo> card drivers including ed(4) do not support configuring media Seigo> types. Fortunately, the fix proposed in 1 allows us once again to Seigo> remove quotations around the arguments of ifconfig(8). I wonder if ifconfig(8) of OpenBSD supports providing both the name of a parameter and its value in a single argument, and an ampty argument... (eg ifconfig ed1 inet xxx.xxx.xxx.xxx "netmask yyy.yyy.yyy.yyy" "") -- Seigo Tanimura <[EMAIL PROTECTED]> <[EMAIL PROTECTED]> To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
Newmidi Release Candidate is ready
The release candidate of newmidi is finally ready. The patch for -current can be found at: URI: http://people.FreeBSD.org/~tanimura/patches/newmidirc.diff.gz I will put this patch into the final test stage of 1 month. The date of merge is hence going to be 11th July 2000. -- Seigo Tanimura <[EMAIL PROTECTED]> <[EMAIL PROTECTED]> To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
Re: kern/16487: please apply newpcm fix
On Mon, 6 Mar 2000 01:22:41 +0100 (CET), Oliver Fromme <[EMAIL PROTECTED]> said: Oliver> Would someone please (pretty please) have a look at kern/16487 Oliver> and commit the trivial fix in it? It's just one line, and it Oliver> makes AvanceLogic-100 soundcards work again. The logical ID of ALS100 conflicts with the one of CMI8330(mss), so we also have to check the vendor ID. Could you please give it to me? It is likely to be 0x00019305. (ALS110 is 0x10019305 and ALS120 is 0x20019305, so...) -- Seigo Tanimura <[EMAIL PROTECTED]> <[EMAIL PROTECTED]> To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
Re: status of 'device awe' ?
On Tue, 22 Feb 2000 16:10:02 -0800, Andy Sparrow <[EMAIL PROTECTED]> said: Andy> Unfortunately for those of us who used to use 'pnp' commands in Andy> userconfig to probe/init the AWE registers, the AWE wavetable is Andy> already useless in -current. Andy> AFAIK, the AWE cannot work without this, and the cards PnPinfo Andy> seems to not include the other two registers - and if you don't Andy> probe them, then the 'awe' driver check doesn't see the EMU8000... My newmidi patch includes a quirk to add the extra IO ports missing in the pnp information provided by EMU8000. That part of the patch is extracted into: http://people.FreeBSD.org/~tanimura/patches/awequirk.diff although not sure if the old-fashioned awe driver makes use of it... -- Seigo Tanimura <[EMAIL PROTECTED]> <[EMAIL PROTECTED]> To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
Re: /sys/i386/machdep.c breaks kernel build
On Sun, 20 Feb 2000 23:48:01 -0500,
Ray Kohler <[EMAIL PROTECTED]> said:
Ray> cc -c -march=pentium -O3 -pipe -fno-builtin -Wall -Wredundant-decls
Ray> -Wnested-externs -Wstrict-prototypes -Wmissing-prototypes
Ray> -Wpointer-arith -Winline -Wcast-qual -fformat-extensions -ansi
Ray> -nostdinc -I- -I. -I../.. -I../../../include -D_KERNEL -include
Ray> opt_global.h -elf -mpreferred-stack-boundary=2
Ray> ../../i386/i386/machdep.c
Ray> {standard input}: Assembler messages:
Ray> {standard input}:2772: Error: operands given don't match any known
Ray> 386 instruction
Ray> *** Error code 1
Could you try the following patch(sent to bsd personally)? It prevents
movl between a debug register and memory.
Index: cpufunc.h
===
RCS file: /home/ncvs/src/sys/i386/include/cpufunc.h,v
retrieving revision 1.95
diff -u -r1.95 cpufunc.h
--- cpufunc.h 2000/02/20 20:51:22 1.95
+++ cpufunc.h 2000/02/21 03:44:30
@@ -456,7 +456,7 @@
rdr0(void)
{
u_int data;
- __asm __volatile("movl %%dr0,%0" : "=rm" (data));
+ __asm __volatile("movl %%dr0,%0" : "=r" (data));
return (data);
}
@@ -464,7 +464,7 @@
rdr1(void)
{
u_int data;
- __asm __volatile("movl %%dr1,%0" : "=rm" (data));
+ __asm __volatile("movl %%dr1,%0" : "=r" (data));
return (data);
}
@@ -472,7 +472,7 @@
rdr2(void)
{
u_int data;
- __asm __volatile("movl %%dr2,%0" : "=rm" (data));
+ __asm __volatile("movl %%dr2,%0" : "=r" (data));
return (data);
}
@@ -480,7 +480,7 @@
rdr3(void)
{
u_int data;
- __asm __volatile("movl %%dr3,%0" : "=rm" (data));
+ __asm __volatile("movl %%dr3,%0" : "=r" (data));
return (data);
}
@@ -488,7 +488,7 @@
rdr6(void)
{
u_int data;
- __asm __volatile("movl %%dr6,%0" : "=rm" (data));
+ __asm __volatile("movl %%dr6,%0" : "=r" (data));
return (data);
}
@@ -496,7 +496,7 @@
rdr7(void)
{
u_int data;
- __asm __volatile("movl %%dr7,%0" : "=rm" (data));
+ __asm __volatile("movl %%dr7,%0" : "=r" (data));
return (data);
}
--
Seigo Tanimura <[EMAIL PROTECTED]> <[EMAIL PROTECTED]>
Re: Newpcm is broken again for mpg123 (ESS 1868 isa sound card)
On Wed, 29 Dec 1999 20:38:48 -0500,
Donn Miller <[EMAIL PROTECTED]> said:
Donn> I just recently did another cvsup, and now newpcm is broken
Donn> again. When I try to play a clip with mpg123, I hear a very
Donn> short burst of the beginning of the clip repeated indefinitely,
Donn> like so:
Donn> "ba ba ba ba ba ba ba ba ba ba ba ba ba ba". I have the ESS
Donn> 1868, of course. Well, I (wisely) saved my old kernel as
Donn> /kernel.good and just booted into that.
Donn> Could you also say what was fixed if you get around to it? I'd
Donn> to learn a little more about the sound driver.
The following things were in the recent mail of mine:
- All ioctl(2)s go to see the secondary buffer(if I have forget nothing).
- chn_setblocksize() changes the size of the secondary buffer.
- chn_mmap() maps the secondary buffer.
- chn_poll() invokes DMA.
- chn_wrintr() performs DMA emulation for pcm devices with no DMA
functionality(requested by nyan).
- SNDCTL_DSP_SETFRAGMENT handles the count correctly.
- GETI/OSPACE returns the number of fragments.
- DMA transfer keeps running upon underrun. Some DSPs seem to end up
with an unpredictable result if the DMA gets stopped followed by
immediate restart. This revokes the change in sys/dev/sound/pcm/channel.c
rev 1.12.
- chn_write() and chn_read() returns EAGAIN for nonblocking if there
are no space to write or data to read.
You can add something like:
printf("chn_write: writing %d bytes, bs->fl = %d, bs->rl = %d, b->fl = %d, b->rl = %d,
b->dl = %d\n", buf->uio_resid, bs->fl, bs->rl, b->fl, b->rl, b->dl);
to see the state of the buffers, especially before and after
triggering DMA transfer(around chn_{wr,rd}intr()) or feeding(around
chn_{wr,rd}feed()). A positive value of b->dl shows that DMA transfer
is taking place.
--
Seigo Tanimura <[EMAIL PROTECTED]> <[EMAIL PROTECTED]>
To Unsubscribe: send mail to [EMAIL PROTECTED]
with "unsubscribe freebsd-current" in the body of the message
Re: more patch for secondary buffer, polling and DMA emulation in pcm
On Mon, 27 Dec 1999 16:08:01 +0900, Seigo Tanimura <[EMAIL PROTECTED]> said: Seigo> Another fix was made on feeding and sucking pcm data. Now chn_wrfeed() Seigo> and the other functions do not attempt excessive feeding during DMA Seigo> transfer to eat up the whole processor. The patch is at: Ouch, the patch broke Rollemup, so I fixed just now. The URI is the same. Seigo> http://people.FreeBSD.org/~tanimura/patches/newmidi/2ndbuf-19991227.diff.gz -- Seigo Tanimura <[EMAIL PROTECTED]> <[EMAIL PROTECTED]> To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
Re: more patch for secondary buffer, polling and DMA emulation in pcm
On Mon, 27 Dec 1999 03:39:56 -0500, Donn Miller <[EMAIL PROTECTED]> said: >> http://people.FreeBSD.org/~tanimura/patches/newmidi/2ndbuf-19991227.diff.gz Donn> Hmmm... this seems to have broken the probe at boot time. Donn> Here's a sample of my dmesg: (snip) Donn> unknown1: at port Donn> 0x220-0x22f,0x388-0x38b,0x330-0x331 irq 5 drq 1,0 on isa0 That is odd... The patch does not even touch sbc.c. How does your pnpinfo(1) look like? -- Seigo Tanimura <[EMAIL PROTECTED]> <[EMAIL PROTECTED]> To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
Re: more patch for secondary buffer, polling and DMA emulation in pcm
Another fix was made on feeding and sucking pcm data. Now chn_wrfeed() and the other functions do not attempt excessive feeding during DMA transfer to eat up the whole processor. The patch is at: http://people.FreeBSD.org/~tanimura/patches/newmidi/2ndbuf-19991227.diff.gz -- Seigo Tanimura <[EMAIL PROTECTED]> <[EMAIL PROTECTED]> To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
Re: more patch for secondary buffer, polling and DMA emulation in pcm
On Fri, 24 Dec 1999 10:39:31 +0900, Seigo Tanimura <[EMAIL PROTECTED]> said: Seigo> players. My sound cards are SB32, SB64 and CS461x, so the problem is Seigo> likely to be in channel.c or dsp.c. OK, here is the result of my investigation on RealPlayer 5.0: RealPlayer 5.0 is an ill-behaving application in two points. First, it passes a size of 16 to SNDCTL_DSP_SETFRAGMENT. This size is obviously too small to buffer pcm data. Second, RealPlayer 5.0 often attempts to write larger pcm data than the block size of the secondary buffer. The result is to write only a part of pcm data ending up with an error, and make polling really weird. AFAIK these problems are fixed in RealPlayer G2. The following fixes are somewhat klutzy, but seem to work: - If a device is in nonblocking mode, adapt the block size to the pcm data to write. - Poll the remaining size to write, rather than that of free space. These fixes are included in: http://people.freebsd.org/~tanimura/patches/newmidi/2ndbuf-19991225.diff.gz -- Seigo Tanimura <[EMAIL PROTECTED]> <[EMAIL PROTECTED]> To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
Re: more patch for secondary buffer, polling and DMA emulation in pcm
On Thu, 23 Dec 1999 14:32:23 -0500, Donn Miller <[EMAIL PROTECTED]> said: Donn> Actually, the patch makes things worse for me on the ESS 1868, Donn> which is an ISA card in my case. When I press "play" in Donn> RealPlayer-5.0, the first 4 seconds skip repeatedly, and then the Donn> whole thing stops. Also, I get a "general error occured" and a Donn> write error when I first press play. This message occurs Donn> immediately the clip begins playing, at which time the first 4 Donn> seconds play repeatedly. I installed and tested RealPlayer 5.0 just now, and saw the same error as you did. I will take a look at the pcm operations that RealPlayer makes. RealPlayer G2 has worked, so something must have changed in the players. My sound cards are SB32, SB64 and CS461x, so the problem is likely to be in channel.c or dsp.c. BTW, is Real still distributing RealPlayer 5.0 or G2 for linux? The URI in the Makefile of the port looks obsolete... (I had downloaded the players at my home) -- Seigo Tanimura <[EMAIL PROTECTED]> <[EMAIL PROTECTED]> To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
Re: more patch for secondary buffer, polling and DMA emulation in pcm
On Thu, 23 Dec 1999 19:18:26 +0900, Seigo Tanimura <[EMAIL PROTECTED]> said: Seigo> The patch has been updated slightly. Now snes9x works with any pcm Seigo> quality you like. The new features are: Still more fix has been made: - chn_write() and chn_read() returns EAGAIN for nonblocking if there are no space to write or data to read. As the patch is now quite large, I have put it at: http://people.FreeBSD.org/~tanimura/patches/newmidi/2ndbuf-19991223.diff.gz -- Seigo Tanimura <[EMAIL PROTECTED]> <[EMAIL PROTECTED]> To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
Re: more patch for secondary buffer, polling and DMA emulation in pcm
On Mon, 20 Dec 1999 13:44:02 +0900, Seigo Tanimura <[EMAIL PROTECTED]> said: Seigo> If you have a trouble playing pcm with some applications, could you Seigo> please try the patch attached below? The patch does the following things: Seigo> - All ioctl(2)s go to see the secondary buffer(if I have forget nothing). Seigo> - chn_setblocksize() changes the size of the secondary buffer. Seigo> - chn_mmap() maps the secondary buffer. Seigo> - chn_poll() invokes DMA. Seigo> - chn_wrintr() performs DMA emulation for pcm devices with no DMA Seigo> functionality(requested by nyan). Seigo> With the patch, snes9x(w/-r 7) and RealPlayer G2 for Linux worked fine. Seigo> The range of blksz in chn_setblocksize() may need further tuning... The patch has been updated slightly. Now snes9x works with any pcm quality you like. The new features are: - SNDCTL_DSP_SETFRAGMENT handles the count correctly. - GETI/OSPACE returns the number of fragments. - DMA transfer keeps running upon underrun. Some DSPs seem to end up with an unpredictable result if the DMA gets stopped followed by immediate restart. This revokes the change in sys/dev/sound/pcm/channel.c rev 1.12. 2ndbuf-19991223.diff.gz -- Seigo Tanimura <[EMAIL PROTECTED]> <[EMAIL PROTECTED]>
more patch for secondary buffer, polling and DMA emulation in
pcm
cc: Seigo Tanimura
User-Agent: Wanderlust/1.0.3 (Notorious) SEMI/1.13.4 (Terai) FLIM/1.12.7
(=?ISO-8859-4?Q?Y=FEzaki?=) MULE XEmacs/21.1 (patch 8) (Bryce Canyon)
(i386--freebsd)
Organization: Digital Library Research Division, Information Techinology Centre, The
University of Tokyo
MIME-Version: 1.0 (generated by SEMI 1.13.4 - "Terai")
Content-Type: multipart/mixed;
boundary="Multipart_Mon_Dec_20_13:44:01_1999-1"
--Multipart_Mon_Dec_20_13:44:01_1999-1
Content-Type: text/plain; charset=US-ASCII
If you have a trouble playing pcm with some applications, could you
please try the patch attached below? The patch does the following things:
- All ioctl(2)s go to see the secondary buffer(if I have forget nothing).
- chn_setblocksize() changes the size of the secondary buffer.
- chn_mmap() maps the secondary buffer.
- chn_poll() invokes DMA.
- chn_wrintr() performs DMA emulation for pcm devices with no DMA
functionality(requested by nyan).
With the patch, snes9x(w/-r 7) and RealPlayer G2 for Linux worked fine.
The range of blksz in chn_setblocksize() may need further tuning...
--Multipart_Mon_Dec_20_13:44:01_1999-1
Content-Type: text/plain; type=patch; charset=US-ASCII
Content-Disposition: attachment; filename="2ndbuf-19991220.diff"
Content-Transfer-Encoding: 7bit
diff -urN -x CVS -x compile -x SILVER -x RINA -x aic7xxx -x ata
sys.apictimer/dev/sound/isa/ad1816.c sys.2ndbuf/dev/sound/isa/ad1816.c
--- sys.apictimer/dev/sound/isa/ad1816.cMon Dec 20 11:13:56 1999
+++ sys.2ndbuf/dev/sound/isa/ad1816.c Mon Dec 20 11:45:28 1999
@@ -403,6 +403,7 @@
struct ad1816_info *ad1816 = ch->parent;
int wr, reg;
+ if (go == PCMTRIG_EMLDMAWR) return 0;
buf_isadma(ch->buffer, go);
wr = (ch->dir == PCMDIR_PLAY);
reg = wr? AD1816_PLAY : AD1816_CAPT;
diff -urN -x CVS -x compile -x SILVER -x RINA -x aic7xxx -x ata
sys.apictimer/dev/sound/isa/mss.c sys.2ndbuf/dev/sound/isa/mss.c
--- sys.apictimer/dev/sound/isa/mss.c Mon Dec 20 11:44:09 1999
+++ sys.2ndbuf/dev/sound/isa/mss.c Mon Dec 20 11:45:28 1999
@@ -1772,6 +1772,7 @@
{
struct mss_chinfo *ch = data;
+ if (go == PCMTRIG_EMLDMAWR) return 0;
buf_isadma(ch->buffer, go);
mss_trigger(ch, go);
return 0;
diff -urN -x CVS -x compile -x SILVER -x RINA -x aic7xxx -x ata
sys.apictimer/dev/sound/isa/sb.c sys.2ndbuf/dev/sound/isa/sb.c
--- sys.apictimer/dev/sound/isa/sb.cMon Dec 20 11:13:58 1999
+++ sys.2ndbuf/dev/sound/isa/sb.c Mon Dec 20 11:45:28 1999
@@ -860,6 +860,7 @@
sbchan_trigger(void *data, int go)
{
struct sb_chinfo *ch = data;
+ if (go == PCMTRIG_EMLDMAWR) return 0;
buf_isadma(ch->buffer, go);
if (go == PCMTRIG_START) sb_start(ch); else sb_stop(ch);
return 0;
@@ -928,6 +929,7 @@
esschan_trigger(void *data, int go)
{
struct sb_chinfo *ch = data;
+ if (go == PCMTRIG_EMLDMAWR) return 0;
switch (go) {
case PCMTRIG_START:
if (!ch->ess_dma_started)
diff -urN -x CVS -x compile -x SILVER -x RINA -x aic7xxx -x ata
sys.apictimer/dev/sound/pci/aureal.c sys.2ndbuf/dev/sound/pci/aureal.c
--- sys.apictimer/dev/sound/pci/aureal.cFri Dec 10 10:17:22 1999
+++ sys.2ndbuf/dev/sound/pci/aureal.c Mon Dec 20 11:45:28 1999
@@ -353,6 +353,7 @@
{
struct au_chinfo *ch = data;
struct au_info *au = ch->parent;
+ if (go == PCMTRIG_EMLDMAWR) return 0;
if (ch->dir == PCMDIR_PLAY) {
au_setadb(au, 0x11, (go)? 1 : 0);
if (!go) {
diff -urN -x CVS -x compile -x SILVER -x RINA -x aic7xxx -x ata
sys.apictimer/dev/sound/pci/csapcm.c sys.2ndbuf/dev/sound/pci/csapcm.c
--- sys.apictimer/dev/sound/pci/csapcm.cFri Dec 10 10:20:07 1999
+++ sys.2ndbuf/dev/sound/pci/csapcm.c Mon Dec 20 11:45:28 1999
@@ -386,6 +386,7 @@
struct csa_chinfo *ch = data;
struct csa_info *csa = ch->parent;
+ if (go == PCMTRIG_EMLDMAWR) return 0;
if (ch->dir == PCMDIR_PLAY) {
if (go == PCMTRIG_START)
csa_startplaydma(csa);
diff -urN -x CVS -x compile -x SILVER -x RINA -x aic7xxx -x ata
sys.apictimer/dev/sound/pci/es137x.c sys.2ndbuf/dev/sound/pci/es137x.c
--- sys.apictimer/dev/sound/pci/es137x.cMon Dec 20 11:14:02 1999
+++ sys.2ndbuf/dev/sound/pci/es137x.c Mon Dec 20 11:45:28 1999
@@ -367,6 +367,7 @@
struct es_info *es = ch->parent;
unsigned cnt = ch->buffer->dl / ch->buffer->sample_size - 1;
+ if (go == PCMTRIG_EMLDMAWR) return 0;
if (ch->dir == PCMDIR_PLAY) {
if (go == PCMTRIG_START) {
int b = (ch->fmt & AFMT_S16_LE)? 2 : 1;
diff -urN -x CVS -x compile -x SILVER -x RINA -x aic7xxx -x ata
sys.apictimer/dev/sound/pci/t4dwave.c sys.2ndbuf/dev/sound/pci/t4dwave.c
--- sys.apictimer/dev/sound/pci/t4dwave.c Mon
Re: pnp, sound and LINT in -current
On Thu, 16 Dec 1999 22:30:45 -0800 (PST), Steve Kargl <[EMAIL PROTECTED]> said: Steve> pcm(4) describes Luigi's old pcm driver. Tne newpcm driver is Steve> different and the info pcm(4) does not necessarily apply. Ouch! Cameron, could you write pcm(4) while I do sbc(4), gusc(4) and csa(4)? -- Seigo Tanimura <[EMAIL PROTECTED]> <[EMAIL PROTECTED]> To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
Re: pnp, sound and LINT in -current
On Wed, 15 Dec 1999 15:00:34 -0800 (PST), Julian Elischer <[EMAIL PROTECTED]> said: Julian> however LINT doesn't help because it still has comments refering Julian> to 'enable pnp'. Are these old? and if not, how do I now do this? Yes. Also, pcm(4) no longer needs to mention pnp(4). Could anyone handle pcm(4) while I fix LINT and go out in half an hour? -- Seigo Tanimura <[EMAIL PROTECTED]> <[EMAIL PROTECTED]> To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
Re: The secondary buffer in pcm channel for DSPs with small DMA buffers
On Sat, 11 Dec 1999 18:55:38 +0900,
Seigo Tanimura <[EMAIL PROTECTED]> said:
Seigo> My CS4614 has got only 4KB of the DMA buffer, frequently failing to
Seigo> play pcm blocks continuously. The following patch adds the secondary
Seigo> pcm channel buffers with the size independent from that of a DSP. The
Seigo> patch works quite well with mpg123 and x11amp. For those who has the
Seigo> similar problem could you please try that?
A few fixes and updates have been added, including recovery from DMA
underflow. The value returned from chn_getptr() in chn_checkunderflow()
may get a lag when we get back to chn_write(), which is likely to
cause noise.
Consider a DMA buffer capable to hold 10 samples, as shown below.
DMA buffer 0123456789
Sample --
Buffer Pointer R-
F-
Playing Point P-
Since a DMA keeps running even after underflow occurs, P may advance,
leaving F.
DMA buffer 0123456789
Sample --
Buffer Pointer R-
F-
Playing Point --P---
If we fill the buffer with new samples in this situation, play begins
from somewhere in the middle of the samples. In the case shown below,
the sample c is the first one to be played. The sample a and b are
played after j, causing noise.
DMA buffer 0123456789
Sample abcdefghij
Buffer Pointer R-
F-
Playing Point --P--- --> cdefghijab
In order to avoid the lag, we can advance F upon underflow. A quarter
of the DMA buffer size would be fair.
DMA buffer 0123456789
Sample --abcdefgh
Buffer Pointer R-
--F---
Playing Point --P--- --> abcdefgh
With the following patch, x11amp and mpg123 play with no noise even
under an extremely heavy load of more than 50 :)
Index: channel.c
===
RCS file: /home/ncvs/src/sys/dev/sound/pcm/channel.c,v
retrieving revision 1.9
diff -u -r1.9 channel.c
--- channel.c 1999/12/05 19:09:12 1.9
+++ channel.c 1999/12/12 03:46:41
@@ -131,9 +131,8 @@
}
/*
- * chn_dmadone() updates pointers and wakes up any process sleeping
- * or waiting on a select().
- * Must be called at spltty().
+ * chn_dmadone() updates pointers and wakes up any process waiting
+ * on a select(). Must be called at spltty().
*/
static void
chn_dmadone(pcm_channel *c)
@@ -142,12 +141,25 @@
chn_dmaupdate(c);
if (ISA_DMA(b)) chn_isadmabounce(c); /* sync bounce buffer */
- wakeup(b);
b->int_count++;
if (b->sel.si_pid && chn_polltrigger(c)) selwakeup(&b->sel);
}
/*
+ * chn_dmawakeup() wakes up any process sleeping. Separated from
+ * chn_dma_done() so that wakeup occurs only when feed from a
+ * secondary buffer to a DMA buffer takes place. Must be called
+ * at spltty().
+ */
+static void
+chn_dmawakeup(pcm_channel *c)
+{
+ snd_dbuf *b = &c->buffer;
+
+ wakeup(b);
+}
+
+/*
* chn_dmaupdate() tracks the status of a dma transfer,
* updating pointers. It must be called at spltty().
*
@@ -181,8 +193,9 @@
}
/*
- * Check channel for underflow occured, reset DMA buffer in case of
- * underflow. It must be called at spltty().
+ * Check channel for underflow occured. Reset DMA buffer in case of
+ * underflow, so that new data can go into the buffer. It must be
+ * called at spltty().
*/
static void
chn_checkunderflow(pcm_channel *c)
@@ -191,9 +204,19 @@
if (b->underflow) {
DEB(printf("Clear underflow condition\n"));
- b->rp = b->fp = chn_getptr(c);
- b->rl = 0;
- b->fl = b->bufsize;
+ /*
+* The DMA keeps running even after underflow occurs.
+* Hence the value returned by chn_getptr() here soon
+* gets a lag when we get back to chn_write(). Although
+* there are no easy and precise methods to figure out
+* the lag, a quarter of b->bufsize would be a fair
+* choice, provided that a DMA interrupt generates upon
+* each transfer of a half b->bufsize.
+*/
+ b->rp = chn_getptr(c);
+ b->fp = (b->rp + b->bufsize / 4) % b->bufsize;
+ b->rl = b->bufsize / 4;
+ b->fl = b->bufsize - b->rl;
b->underflow=0;
} else {
chn_dmaupdate(c);
@@ -201,6 +224,70 @@
}
/*
+ * Feeds new data to the write dma buffer. Can be called in the bottom half.
+ * Hence must be called at spltty.
+ */
+static int
+chn_wrfeed(pcm_channel *c)
+{
+ snd_dbuf *b = &c->b
The secondary buffer in pcm channel for DSPs with small DMA buffers
t;rp) & DMA_ALIGN_MASK;
- w = c->feeder->feed(c->feeder, c, b->buf + b->rp, l, buf);
- s = spltty();
- b->rl -= w;
- b->fl += w;
- b->rp = (b->rp + w) % b->bufsize;
- splx(s);
}
c->flags &= ~CHN_F_READING;
+ splx(s);
return ret;
}
@@ -534,6 +647,7 @@
chn_resetbuf(pcm_channel *c)
{
snd_dbuf *b = &c->buffer;
+ snd_dbuf *bs = &c->buffer2nd;
c->smegcnt = 0;
c->buffer.sample_size = 1;
@@ -547,6 +661,9 @@
b->prev_int_count = b->int_count = 0;
b->first_poll = 1;
b->underflow=0;
+ bs->rp = bs->fp = 0;
+ bs->dl = bs->rl = 0;
+ bs->fl = bs->bufsize;
}
void
@@ -631,6 +748,7 @@
long s;
int missing = 0;
snd_dbuf *b = &c->buffer;
+ snd_dbuf *bs = &c->buffer2nd;
s = spltty();
if (b->dl) {
@@ -639,7 +757,7 @@
chn_trigger(c, PCMTRIG_ABORT);
chn_dmadone(c);
}
- missing = b->rl;
+ missing = b->rl + bs->rl;
splx(s);
return missing;
}
@@ -708,11 +826,18 @@
int
chn_init(pcm_channel *c, void *devinfo, int dir)
{
+ snd_dbuf *bs = &c->buffer2nd;
+
c->flags = 0;
c->feeder = &feeder_root;
c->buffer.chan = -1;
c->devinfo = c->init(devinfo, &c->buffer, c, dir);
chn_setdir(c, dir);
+ bs->bufsize = CHN_2NDBUFSIZE;
+ bs->buf = malloc(bs->bufsize, M_DEVBUF, M_NOWAIT);
+ bzero(bs->buf, bs->bufsize);
+ bs->rl = bs->rp = bs->fp = 0;
+ bs->fl = bs->bufsize;
return 0;
}
Index: datatypes.h
===
RCS file: /home/ncvs/src/sys/dev/sound/pcm/datatypes.h,v
retrieving revision 1.5
diff -u -r1.5 datatypes.h
--- datatypes.h 1999/12/05 19:09:12 1.5
+++ datatypes.h 1999/12/11 09:34:25
@@ -127,6 +127,7 @@
u_int8_t smegbuf[SMEGBUFSZ];
u_int32_t smegcnt;
void *devinfo;
+ snd_dbuf buffer2nd;
};
#define SND_STATUSLEN 64
--
Seigo Tanimura <[EMAIL PROTECTED]> <[EMAIL PROTECTED]>
Re: AWE64 problems
[snipped some part]
>> > > On Tue, 7 Dec 1999 23:00:02 +0100 (MET),
>> > > Thomas Schuerger <[EMAIL PROTECTED]> said:
>> > >
>> > > >> --- sbc.c.origMon Dec 6 19:26:31 1999
>> > > >> +++ sbc.c Tue Dec 7 22:15:25 1999
>> > > >> @@ -110,7 +110,7 @@
>> > > >> if (error)
>> > > >> return error;
>> > > >> else
>> > > >> - return -100;
>> > > >> + return -1;
>> > > >> }
>> > > >>
>> > > >> static int
On Wed, 8 Dec 1999 08:54:15 -0500,
"Charles Anderson" <[EMAIL PROTECTED]> said:
Charles> So then what is -1 and why does it work when -100 doesn't? (I tried it)
sys/kern/subr_bus.c:device_probe_child() receives the value returned
by DEVICE_PROBE(child dev). If the value is zero, no further probes
occur. The device then gets attached in sys/kern/subr_bus.c:
device_probe_and_attach().
If the returned value is less than zero, device_probe_child()
continues probing other possible drivers. For ISA devices, the unknown
driver implemented in sys/isa/isa_common.c is always probed if no
other drivers probe the device successfully. The DEVICE_PROBE() for
any ISA devices with the unknown driver returns -100, so it is, say,
the likelyhood of the unknown driver to the device.
To say the truth, a driver other than the unknown might get to probe
the device in this case, depending on the order to enumerate the
possible drivers in device_probe_child() using {first,next}_matching_driver().
--
Seigo Tanimura <[EMAIL PROTECTED]> <[EMAIL PROTECTED]>
To Unsubscribe: send mail to [EMAIL PROTECTED]
with "unsubscribe freebsd-current" in the body of the message
Re: AWE64 problems
On Tue, 7 Dec 1999 23:00:02 +0100 (MET), Thomas Schuerger <[EMAIL PROTECTED]> said: >> --- sbc.c.orig Mon Dec 6 19:26:31 1999 >> +++ sbc.cTue Dec 7 22:15:25 1999 >> @@ -110,7 +110,7 @@ >> if (error) >> return error; >> else >> -return -100; >> +return -1; >> } >> >> static int Thomas> Works fine for me. Thanks!!! Yes, this patch should work. The probe likelyhood(do we call it so?) for unknown device is -100, so it does not make sense for sbc to return -100. -1 might be too high, -50 sounds good to me. -- Seigo Tanimura <[EMAIL PROTECTED]> <[EMAIL PROTECTED]> To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
Please check missing logical IDs for SB
If you have an SB card not probed since the import of the bridge
dirvers, could you please apply the following patch, add the logical
ID of your card into sbc_ids[] and see how it works?
(I have asked peter to review the PnP part of the patch)
Index: sbc.c
===
RCS file: /home/ncvs/src/sys/dev/sound/isa/sbc.c,v
retrieving revision 1.2
diff -u -r1.2 sbc.c
--- sbc.c 1999/11/27 06:33:27 1.2
+++ sbc.c 1999/11/30 06:28:19
@@ -82,125 +82,42 @@
static devclass_t sbc_devclass;
-#if NISA > 0 && NPNP > 0
-static int
-sbc_probe(device_t dev)
-{
- u_int32_t vend_id, logical_id, vend_id2;
- char *s;
- struct sndcard_func *func;
- vend_id = isa_get_vendorid(dev);
- vend_id2 = vend_id & 0xff00;
- logical_id = isa_get_logicalid(dev);
- s = NULL;
+#if NISA > 0 && NPNP > 0
- switch (logical_id) {
+static struct isa_pnp_id sbc_ids[] = {
#if notdef
- case 0x630e: /* Crystal Semiconductor */
- if (vend_id2 ==0x3600630e) /* CS4236 */
- s = "CS4236";
- else if (vend_id2 ==0x3200630e) /* CS4232 */
- s = "CS4232";
- else if (vend_id2 ==0x3500630e) /* CS4236B */
- s = "CS4236B";
- break;
-#endif /* notdef */
- case 0x01008c0e: /* Creative ViBRA16C */
- if (vend_id2 == 0x70008c0e)
- s = "Creative ViBRA16C PnP";
- break;
- case 0x43008c0e: /* Creative ViBRA16X */
- if (vend_id2 == 0xf0008c0e)
- s = "Creative ViBRA16C PnP";
- break;
- case 0x31008c0e: /* Creative SB */
- if (vend_id2 == 0x26008c0e)
- s = "Creative SB16 PnP";
- else if (vend_id2 == 0x42008c0e)
- s = "Creative SB32 (CTL0042)";
- else if (vend_id2 == 0x44008c0e)
- s = "Creative SB32 (CTL0044)";
- else if (vend_id2 == 0x48008c0e)
- s = "Creative SB32 (CTL0048)";
- else if (vend_id2 == 0x49008c0e)
- s = "Creative SB32 (CTL0049)";
- else if (vend_id2 == 0xf1008c0e)
- s = "Creative SB32 (CTL00f1)";
- break;
- case 0x42008c0e: /* Creative SB AWE64 (CTL00c1) */
- if (vend_id2 == 0xc1008c0e)
- s = "Creative SB AWE64 (CTL00c1)";
- break;
- case 0x45008c0e: /* Creative SB AWE64 (CTL0045) */
- if (vend_id2 == 0xe4008c0e)
- s = "Creative SB AWE64 (CTL0045)";
- break;
+ {0x630e, "CS423x"},
+#endif
+ {0x01008c0e, "Creative ViBRA16C PnP"},
+ {0x43008c0e, "Creative ViBRA16X PnP"},
+ {0x31008c0e, "Creative SB16 PnP/SB32"},
+ {0x42008c0e, "Creative SB AWE64"}, /* CTL00c1 */
+ {0x45008c0e, "Creative SB AWE64"}, /* CTL0045 */
#if notdef
- case 0x0121: /* Avance Logic */
- if (vend_id2 == 0x20009305)
- s = "Avance Logic ALS120";
- break;
- case 0x0111: /* Avance Asound */
- if (vend_id2 == 0x10009305)
- s = "Avance Asound 110";
- break;
- case 0x68187316: /* ESS1868 */
- if (vend_id2 == 0x68007316)
- s = "ESS ES1868 Plug and Play AudioDrive";
- break;
- case 0x79187316: /* ESS1879 */
- if (vend_id2 == 0x79007316)
- s = "ESS ES1879 Plug and Play AudioDrive";
- break;
- case 0x2100a865: /* Yamaha */
- if (vend_id2 == 0x2000a865)
- s = "Yamaha OPL3-SA2/SAX Sound Board";
- break;
- case 0x80719304: /* Terratec */
- if (vend_id2 == 0x1114b250)
- s = "Terratec Soundsystem Base 1";
- break;
- case 0x0300561e: /* Gravis */
- if (vend_id2 == 0x0100561e)
- s = "Gravis UltraSound Plug & Play";
- break;
-#endif /* notdef */
- }
-
- if (s != NULL) {
- device_set_desc(dev, s);
-
- /* PCM Audio */
- func = malloc(sizeof(struct sndcard_func), M_DEVBUF, M_NOWAIT);
- if (func == NULL)
- return (ENOMEM);
- bzero(func, sizeof(*func));
- func->func = SCF_PCM;
- device_add_child(dev, "pcm", -1, func);
+ {0x0121, "Avance Logic ALS120"},
+ {0x0111, "Avance Asound 110"},
+ {0x68187316, "ESS ES1868 Plug and Play AudioDrive"}, /* ESS1868 */
+ {0x79187316, "ESS ES1879 Plug and Play AudioDrive"}, /* ESS1879 */
+ {0x2100a865, "Yamaha OPL3-SA2/SAX Sound Board"},
+ {0x80719304, "Terratec Sound
Re: "Fast forward" bug and newpcm (again)
On Tue, 30 Nov 1999 02:30:41 -0500 (EST), Donn Miller <[EMAIL PROTECTED]> said: >> sbc driver does not probe ESS1868 at this moment. Donn> Question: will the ESS 1868 bridge driver be incorporated into the sbc Donn> driver, or should we devise a whole new bridge driver for the ess? I.e., Donn> we would have: Donn> device ess0 # ESS bridge driver I prefer ess0. ESS is the name of soundcards as well, so the name of the driver matches those of the cards. To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
Re: "Fast forward" bug and newpcm (again)
On Tue, 30 Nov 1999 01:41:20 -0500, Donn Miller <[EMAIL PROTECTED]> said: Donn> Now, the question is, do I use the Sound Blaster bridge driver Donn> for the ESS 1868? And, is my ordering wrong? sbc driver does not probe ESS1868 at this moment. -- Seigo Tanimura <[EMAIL PROTECTED]> <[EMAIL PROTECTED]> To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
