of my sound cards (except for the GUS PnP, which I
Dag-Erling> haven't tested) work any more, and I am seriously losing faith in the
Dag-Erling> authors' ability to maintain a device driver.
Did you add sbc into your kernel configuration? Maybe I should add
a warning in sb.c...
--
S
in there at all, that's for card ID, not
Peter> device id.
I am now working to tidy up the sbc probe. Would it be enough for the
sound chips on motherboards to check the logical device ID of 0x??008c0e?
How does the result of pnpinfo(1) for a motherboard chip look like?
--
Seigo Tanim
The following patch makes sbc_probe() to look at the vendor ID only
for AWE64. Also, any device that has a logical ID matching 0x??0080ce
should get probed.
Index: sbc.c
===
RCS file: /home/ncvs/src/sys/dev/sound/isa/sbc.c,v
retri
r seemed to have solved the problem, I saw
lockmgr: pid -2, not exclusive lock holder 48 unlocking
on savecore(8) after another panic reboot.
I have to go to bed now... I will see what is going on tomorrow.
Seigo TANIMURA <[EMAIL PROTECTED]>
To Unsubscribe: send mail to [EMAIL PROTECTED]
with "unsubscribe freebsd-current" in the body of the message
r.
You can read the short paper describing the feature and principle in:
Message-Id: <[EMAIL PROTECTED]>
finetimer(9) has the same interface functions as timeout(9), so it should
be easy to use it.
Seigo Tanimura <[EMAIL PROTECTED]>
To Unsubscribe: send mail to [EMAIL PROTECTED
he future works include porting to
alpha and PC98, and tuning hzmul.
--- ^ --- cut here --- ^ ---
Seigo Tanimura <[EMAIL PROTECTED]>
To Unsubscribe: send mail to [EMAIL PROTECTED]
with "unsubscribe freebsd-hackers" in the body of the message
1024hz) so the
dfr> granularity of timing is better but probably not good enough for midi or
dfr> pca.
I agree.
Seigo Tanimura <[EMAIL PROTECTED]>
To Unsubscribe: send mail to [EMAIL PROTECTED]
with "unsubscribe freebsd-current" in the body of the message
:-) box last night. The second mfs
mounting paniced, while the first one worked fine.
Seigo Tanimura <[EMAIL PROTECTED]>
To Unsubscribe: send mail to [EMAIL PROTECTED]
with "unsubscribe freebsd-current" in the body of the message
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
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]>
.
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]>
/~tanimura/newmidi/
to install newmidi.
Thanks!
Seigo Tanimura <[EMAIL PROTECTED]> <[EMAIL PROTECTED]>
To Unsubscribe: send mail to [EMAIL PROTECTED]
with "unsubscribe freebsd-current" in the body of the message
: acd0: Audio: play, 16 volume levels
Oct 30 19:36:39 silver /kernel: acd0: Mechanism: ejectable tray
Oct 30 19:36:39 silver /kernel: acd0: Medium: CD-ROM 120mm audio disc loaded, unlocked
Seigo Tanimura <[EMAIL PROTECTED]> <[EMAIL PROTECTED]>
To Unsubscribe: send mail to [EMAIL PRO
t;)
(snip)
newpcm is still using cdevsw_add() to register the driver handlers.
I will fix 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
as well.
This commit also adds pcm support for the following cards:
GUS PnP and non-PnP ISA (gusc driver)
Crystal Semiconductor CS461x/428x PCI (csa driver)
For a GUS non-PnP ISA card, write down the configuration of
your card to gusc, not pcm.
Seigo Tanimura <[EMAIL PROTECTED]> &
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
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
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
=
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
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
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]>
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
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
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
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
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
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
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 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
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 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&g
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 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
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
he last commit was not done completely because
resource tags and handles were not used proplerly. Could you please
apply the following patch and see if your card works?
Index: if_ed.c
===
RCS file: /home/naklab/tanimura/rina2/CVS/FreeBSD/sys/
lowing patch work?
Index: if_ed.c
===
RCS file: /home/naklab/tanimura/rina2/CVS/FreeBSD/sys/dev/ed/if_ed.c,v
retrieving revision 1.1.1.4.6.8
diff -u -r1.1.1.4.6.8 if_ed.c
--- if_ed.c 2000/08/16 07:38:31 1.1.1.4.6.8
+++ if_ed.c
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
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
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
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
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
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
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
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
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>
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, 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.
--
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 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
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 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
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 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
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 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
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
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
.
>> >>
>> >> 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&#x
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
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
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
.
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/p
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
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
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
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
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 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:
>>
>> >>
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
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 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
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
. 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
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]>
t;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:
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
ese/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
[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
> silver% cat /usr/src/gnu/usr.bin/texinfo/makeinfo/Makefile
> # $Id: Makefile,v 1.8 1999/01/14 20:00:46 markm Exp $
(snip)
> CFLAGS+= -DLOCALEDIR=\"/usr/share/local\"
^
this should be 'locale'...
Seigo TANIMURA
e && PP(pp, p_oncpu) == 0xff)
^^
this should be '!='.
Seigo TANIMURA |M1, Nakagawa Lab, Dept of Electronics & CS
=|Faculty of Engineering, Yokohama
-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
[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
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
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
. Has anyone got a clue?
Thanks in advance!
Seigo TANIMURA |M2, Nakagawa Lab, Dept of Electronics & CS
=|Faculty of Engineering, Yokohama National Univ
Powered by SIEMENS, |http://www.naklab.dnj.ynu.ac.jp/~tanimura/
FreeBSD 4.0-CURRENT |http://www.s
From: Juergen Lock
Subject: Re: Call for Review: Voxware midi driver for serial ports
Date: Sun, 2 May 1999 02:15:00 +0200
Message-ID: <19990502021500.a3...@saturn.kn-bremen.de>
nox> On Tue, Apr 20, 1999 at 10:27:35AM +0900, Seigo TANIMURA wrote:
nox> > On Sun, 18 Apr 1999 22:1
Hi!
On Tue, 04 May 1999 01:32:01 -0600,
Warner Losh said:
imp> In message <19990502075751n.tanim...@sakuramail.com> Seigo TANIMURA writes:
imp> : I traced to watch _apm_addr, which pointed the correct entry(0x78a8)
imp> : in both situations. The only one difference was C
oblem.
imp> It certainly does fix a problem in the hardware configuration (SMP)
imp> that you are having.
Yes, that patch did solve my problem as well! Thanks a lot.
Seigo TANIMURA |M2, Nakagawa Lab, Dept of Electronics & CS
=|Faculty of Engineering, Yokoha
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
/~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
de.
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
) 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
abo
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
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
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
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
rn/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
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
1 - 100 of 118 matches
Mail list logo
