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 conv
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
[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 j
%
--- ^ --- 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]>
___
[EMA
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
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 PRO
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
e 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
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 Unsu
ip)
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_mo
/~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> memo
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 Unsubscrib
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.
}
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
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
>> instanc
on 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
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
ained 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]
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 n
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:
>>> >>
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
>> >>
br
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
&g
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 T
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 "un
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
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
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 s
d> 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]>
s 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
ot 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
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
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 ke
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 PROTEC
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
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.
O
p->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
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
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
o 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
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 pos
achdep.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
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:
>>
>> >>
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]> &l
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 fe
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 -curre
k;
}
if (map != &curproc->p_vmspace->vm_map)
vm_map_unlock_read(map);
+
+ mtx_unlock(&vm_mtx);
+
return error;
}
--
Seigo Tanimura <[EMAIL PROTECTED]> <[EMAIL PROTECTED]>
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, na
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 enou
pose.
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
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
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: r
ange.
- 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
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:
&g
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
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
ion 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
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 l
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
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 vn
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]> <[
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.
--
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
>
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>
cking 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 P
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 PRO
4 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: s
artmode+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
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 "unsubscri
[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 fr
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
ally 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
ng _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
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]>
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]
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:
>>
>> pet
==
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]>
==
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]>
D]> 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, 2
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
.
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]>
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: se
"=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]>
round
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
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.
t; 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]
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
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 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
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 no
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 second
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
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
ds 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
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 independe
ing = 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]>
e 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
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 migh
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
=
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.,
Don
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 PROT
1 - 100 of 115 matches
Mail list logo
