Re: Bluetooth stack for FreeBSD
Poul-Henning Kamp wrote: In message [EMAIL PROTECTED], Maksim Yevmenkin writes: I still would like to hear from people. I'm extremely surprised that FreeBSD community seems not interested in this at all. I got very few replies from few people (Julian Elischer, Terry Lambert - thanks!) and that's it. Most of us probably doesn't have any bluetooth hardware... I have a BT PCMCIA card by IBM, a BT USB adapter by MITSUMI, a C413S BT mobile phone by Sony, and a BT adapter for Sony CLIE. A communication between CLIE/C413S and PC does not work properly with Windows OS. Mobile phone and CLIE work well, because no Windows needed and it's a Sony-to-Sony connection! Sony is eager to introduce BT and there're several models of VAIO notebooks that have built-in BT interfaces. Anyway, I am willing to be a tester and you could find more ones in Japan, because there're dozens of Bluetooth PCs and devices. -- FUJIMOTO Kou, Tokyo Denki University To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
unsubscribe
unsubscribe -- katty To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-current in the body of the message
Re: Uncommitted dc0 fixes ...
Hi, and Martins patch: This one works standalone and with 2 and 3 above. It seems to have increase ftp transfer rates too from 8600Kbytes/sec to 10577Kbytes/sec. Cool. Ofcourse, for some odd reason, if the ftp was done from a Windows XP Pro machine, it's only 6722KBytes/sec. Hmm. TCP-window size ? And did you already tried to turn on/off the sysctls ? net.inet.tcp.rfc1323 net.inet.tcp.rfc1644 Martin To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-current in the body of the message
Re: Uncommitted dc0 fixes ...
Hi,
1) dc driver uses wrong case to read MAC from eeprom.
http://www.FreeBSD.org/cgi/query-pr.cgi?pr=kern/35482
This one seems to break data sending/receiving as the only thing that
works is pinging and that's only on the alias/secondary IP and not the
primary IP network which is completely unpingable.
I expected this one to be the problem PR. I'll look at it this evening.
+ case DC_DEVICEID_EN2242: /* and DC_DEVICEID_EN5251B: */
+ if (revision DC_REVISION_EN5251B) {
+ sc-dc_type = DC_TYPE_AN985;
+ } else {
+ sc-dc_type = DC_TYPE_EN5152B;
+ }
+ sc-dc_flags |= DC_TX_USE_TX_INTR;
+ sc-dc_flags |= DC_TX_ADMTEK_WAR;
+ sc-dc_pmode = DC_PMODE_MII;
+ break;
case DC_DEVICEID_AN985:
- case DC_DEVICEID_EN2242:
sc-dc_type = DC_TYPE_AN985;
sc-dc_flags |= DC_TX_USE_TX_INTR;
sc-dc_flags |= DC_TX_ADMTEK_WAR;
This change looks wrong to me.
Martin
To Unsubscribe: send mail to [EMAIL PROTECTED]
with unsubscribe freebsd-current in the body of the message
Re: vnode lock assertion problem in nfs_link()
The locking changes in union_link() need a thorough review,
though the light testing of that I performed didn't turn up any
glaring problems.
The changes are obviously just cleanups for leaf file systems, but I
wonder why everything wasn't always locked at the top. Could it have
been because locking all the way down is harmful?
Index: ufs/ufs/ufs_vnops.c
===
RCS file: /home/ncvs/src/sys/ufs/ufs/ufs_vnops.c,v
retrieving revision 1.204
diff -u -r1.204 ufs_vnops.c
--- ufs/ufs/ufs_vnops.c 15 Aug 2002 20:55:08 - 1.204
+++ ufs/ufs/ufs_vnops.c 10 Sep 2002 03:08:48 -
...
@@ -825,19 +824,16 @@
#endif
if (tdvp-v_mount != vp-v_mount) {
error = EXDEV;
- goto out2;
- }
- if (tdvp != vp (error = vn_lock(vp, LK_EXCLUSIVE, td))) {
- goto out2;
+ goto out;
}
ip = VTOI(vp);
if ((nlink_t)ip-i_nlink = LINK_MAX) {
error = EMLINK;
- goto out1;
+ goto out;
}
if (ip-i_flags (IMMUTABLE | APPEND)) {
error = EPERM;
- goto out1;
+ goto out;
}
ip-i_effnlink++;
ip-i_nlink++;
@@ -859,10 +855,7 @@
if (DOINGSOFTDEP(vp))
softdep_change_linkcnt(ip);
}
-out1:
- if (tdvp != vp)
- VOP_UNLOCK(vp, 0, td);
-out2:
+out:
VN_KNOTE(vp, NOTE_LINK);
VN_KNOTE(tdvp, NOTE_WRITE);
return (error);
The ugly gotos and uglier braces near them could be replaced by simple
returns now. Some related points:
(1) I think it is just a bug that null changes for failed operations are
knoted. It might be useful for knote to report attempted operations
and why they failed, but reporting failed operations doesn't seem
very useful unless they can be distinguished from successful ones.
Anyway, knote isn't told about failures before here. Doing the
knoting at a higher level upon successful completion would work
better in many cases including the above. This would be similar
to setting file times only upon successful completion, except it is
easier because knotes apply to vnodes but file times are fs-specific.
In both cases, it might be useful to set flags at lower levels in
some cases and back out the settings together with backing out the
main effects of the operation if the operation becomes unsuccessful
later.
(2) The gotos seem to exist to join common code that does a vput(tdvp) as
well as the things removed in the above. The vput() was removed some
time ago. There also used to be VOP_ABORTOP()s, but they weren't in
the common code for some reason.
(3) Removing the VOP_ABORTOP() after vn_lock() failure left ugly braces.
Similarly in ext2fs, except its support for kevent is missing in most
places including here.
Bruce
To Unsubscribe: send mail to [EMAIL PROTECTED]
with unsubscribe freebsd-current in the body of the message
Re: vnode lock assertion problem in nfs_link()
On 10 Sep, Bruce Evans wrote: The locking changes in union_link() need a thorough review, though the light testing of that I performed didn't turn up any glaring problems. The changes are obviously just cleanups for leaf file systems, but I wonder why everything wasn't always locked at the top. Could it have been because locking all the way down is harmful? Judging by how the leaf filesystems were careful to only do the lock if tdvp != vp, I suspect there was the potential for a deadlock if both vnodes were automatically locked at the top. The ugly gotos and uglier braces near them could be replaced by simple returns now. Some related points: We can't change the gotos to returns unless we also make the change in (1). I think I agree with you about (1), but VN_KNOTE() doesn't have a man page and I didn't want to change anything that I didn't understand. I think (1) deserves a separate sweep and mega-commit. A quick look at ufs_vnops.c turns up a number of inconsistencies in the use of VN_KNOTE(). (1) I think it is just a bug that null changes for failed operations are knoted. It might be useful for knote to report attempted operations and why they failed, but reporting failed operations doesn't seem very useful unless they can be distinguished from successful ones. Anyway, knote isn't told about failures before here. Doing the knoting at a higher level upon successful completion would work better in many cases including the above. This would be similar to setting file times only upon successful completion, except it is easier because knotes apply to vnodes but file times are fs-specific. In both cases, it might be useful to set flags at lower levels in some cases and back out the settings together with backing out the main effects of the operation if the operation becomes unsuccessful later. To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-current in the body of the message
Re: Kernel hangs during boot - latest cvsup
On Mon, 9 Sep 2002 12:09:05 -1000 (HST), Vincent Poy [EMAIL PROTECTED] said: Vincent On Mon, 9 Sep 2002, Julian Elischer wrote: On Mon, 9 Sep 2002, Vincent Poy wrote: Timecounters tick every 10.000 msec --- boot -v might be instructive.. VincentIt seems in the latest -CURRENT, the following in the kernel Vincent config file based on the GENERIC kernel: Vincent optionsMAXMEM=786432 Hi, I just did a cvsup , clean and cleandir and stuff and when I try to compile the kernel, I get this error cc -c -O -pipe -Wall -Wredundant-decls -Wnested-externs -Wstrict-prototypes -Wmissing-prototypes -Wpointer-arith -Winline -Wcast-qual -fformat-extensions -ansi -g -nostdinc -I- -I. -I/usr/src/sys -I/usr/src/sys/dev -I/usr/src/sys/contrib/dev/acpica -I/usr/src/sys/contrib/ipfilter -I/usr/src/sys/../include -D_KERNEL -include opt_global.h -fno-common -mpreferred-stack-boundary=2 -ffreestanding -Werror /usr/src/sys/dev/cardbus/cardbus.c cc1: warnings being treated as errors /usr/src/sys/dev/cardbus/cardbus.c: In function `cardbus_driver_added': /usr/src/sys/dev/cardbus/cardbus.c:319: warning: unused variable `cardattached' *** Error code 1 Stop in /usr/obj/usr/src/sys/GENERIC. *** Error code 1 Stop in /usr/src. *** Error code 1 Anyone else getting this ? Regards Sid -- The [Ford Foundation] is a large body of money completely surrounded by people who want some. -- Dwight MacDonald Sid Carter - http://symonds.net/~sidcarter To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-current in the body of the message
Re: Kernel hangs during boot - latest cvsup
On Mon, 9 Sep 2002 14:37:45 -0700 (PDT), Julian Elischer [EMAIL PROTECTED] said: Julian On Mon, 9 Sep 2002, Vincent Poy wrote: I compiled the kernel last nite and I haven't been able to boot into the system with that kernel. This is where the kernel hangs vga0: Generic ISA VGA at port 0x3c0-0x3df iomem 0xa-0xb on isa0 Timecounters tick every 10.000 msec --- Julian boot -v might be instructive.. Hi, boot -v gives me this. Sep 10 15:13:34 calvin kernel: 0 accounted for Sep 10 15:13:34 calvin kernel: Device configuration finished. Sep 10 15:13:34 calvin kernel: procfs registered Sep 10 15:13:34 calvin kernel: Timecounters tick every 10.000 msec Sep 10 15:13:34 calvin kernel: bpf:lo0 attached and of course hangs at the last statement. Regards Sid -- Don't let your mind wander -- it's too little to be let out alone. Sid Carter - http://symonds.net/~sidcarter To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-current in the body of the message
Re: vnode lock assertion problem in nfs_link()
On Tue, 10 Sep 2002, Don Lewis wrote: On 10 Sep, Bruce Evans wrote: The locking changes in union_link() need a thorough review, though the light testing of that I performed didn't turn up any glaring problems. The changes are obviously just cleanups for leaf file systems, but I wonder why everything wasn't always locked at the top. Could it have been because locking all the way down is harmful? Judging by how the leaf filesystems were careful to only do the lock if tdvp != vp, I suspect there was the potential for a deadlock if both vnodes were automatically locked at the top. I think this is because some places are still worrying about using link(2) on directories. I think there aren't any significant problems when vp is not a directory. Hard linking of directories was permitted (and perhaps even supported) until relatively recently: % RCS file: /home/ncvs/src/sys/kern/vfs_syscalls.c,v % Working file: vfs_syscalls.c % head: 1.285 % ... % % revision 1.48 % date: 1996/05/24 16:19:23; author: peter; state: Exp; lines: +9 -7 % Dont allow directories to be link()ed or unlink()ed, even for root % (returns EPERM always, the errno is specified by POSIX). % % If you really have a desperate need to link or unlink a directory, you % can use fsdb. :-) % % This should stop any chance of ftpd, rdist, rm -rf, etc from % bugging out and damaging the filesystem structure or loosing races % with malicious users. % % Reviewed by: davidg, bde % The ugly gotos and uglier braces near them could be replaced by simple returns now. Some related points: We can't change the gotos to returns unless we also make the change in (1). I think I agree with you about (1), but VN_KNOTE() doesn't have a man page and I didn't want to change anything that I didn't understand. I think (1) deserves a separate sweep and mega-commit. A quick look at ufs_vnops.c turns up a number of inconsistencies in the use of VN_KNOTE(). (1) I think it is just a bug that null changes for failed operations are knoted. It might be useful for knote to report attempted operations OK. I have fixed some of these inconsistencies in my version, but haven't done a sweep or tested kevent. Bruce To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-current in the body of the message
Re: vnode lock assertion problem in nfs_link()
On 10 Sep, Bruce Evans wrote: On Tue, 10 Sep 2002, Don Lewis wrote: On 10 Sep, Bruce Evans wrote: The changes are obviously just cleanups for leaf file systems, but I wonder why everything wasn't always locked at the top. Could it have been because locking all the way down is harmful? Judging by how the leaf filesystems were careful to only do the lock if tdvp != vp, I suspect there was the potential for a deadlock if both vnodes were automatically locked at the top. ... or panic locking against myself ... I think this is because some places are still worrying about using link(2) on directories. I think there aren't any significant problems when vp is not a directory. Hard linking of directories was permitted (and perhaps even supported) until relatively recently: I suspect that you are right about this. If so, it should be able to let namei() lock the first vnode since we check its type and bail out if it is a directory before the second namei() call. To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-current in the body of the message
Re: vnode lock assertion problem in nfs_link()
Bruce Evans wrote: The changes are obviously just cleanups for leaf file systems, but I wonder why everything wasn't always locked at the top. Could it have been because locking all the way down is harmful? For a stacked local media FS, you can end up with a deadlock, if a lower vnode is exposed into the visible namespace, e.g.: oo /usr/myfs2 | /usr/myfs1| ,--.--. | || / | | quotafs o| / | `--' / | |\ / | | ffs o | `-' Probably, the correct thing to do is to lock at the top, and lock the lower in all intermediate layers as the top is locked. This requires that the operation from the top look the same from the top and from the bottom of the VFS stacking layer. This probably needs a veto-VOP that is a NUL operation for local media FSs that can't be stacked on something other than the VM system. -- Terry To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-current in the body of the message
Re: Kernel hangs during boot - latest cvsup
On 10 Sep 2002, Sid Carter wrote: On Mon, 9 Sep 2002 12:09:05 -1000 (HST), Vincent Poy [EMAIL PROTECTED] said: Vincent On Mon, 9 Sep 2002, Julian Elischer wrote: On Mon, 9 Sep 2002, Vincent Poy wrote: Timecounters tick every 10.000 msec --- boot -v might be instructive.. Vincent It seems in the latest -CURRENT, the following in the kernel Vincent config file based on the GENERIC kernel: Vincent optionsMAXMEM=786432 Hi, I just did a cvsup , clean and cleandir and stuff and when I try to compile the kernel, I get this error cc -c -O -pipe -Wall -Wredundant-decls -Wnested-externs -Wstrict-prototypes -Wmissing-prototypes -Wpointer-arith -Winline -Wcast-qual -fformat-extensions -ansi -g -nostdinc -I- -I. -I/usr/src/sys -I/usr/src/sys/dev -I/usr/src/sys/contrib/dev/acpica -I/usr/src/sys/contrib/ipfilter -I/usr/src/sys/../include -D_KERNEL -include opt_global.h -fno-common -mpreferred-stack-boundary=2 -ffreestanding -Werror /usr/src/sys/dev/cardbus/cardbus.c cc1: warnings being treated as errors /usr/src/sys/dev/cardbus/cardbus.c: In function `cardbus_driver_added': /usr/src/sys/dev/cardbus/cardbus.c:319: warning: unused variable `cardattached' *** Error code 1 Stop in /usr/obj/usr/src/sys/GENERIC. *** Error code 1 Stop in /usr/src. *** Error code 1 Anyone else getting this ? Nope, the GENERIC I built is based on the September 8, 2002 -current and has been fine. My only problem seems to be if MAXMEM is defined in a kernel config, it hangs on bootup. Cheers, Vince - [EMAIL PROTECTED] - Vice President __ Unix Networking Operations - FreeBSD-Real Unix for Free / / / / | / |[__ ] WurldLink Corporation / / / / | / | __] ] San Francisco - Honolulu - Hong Kong / / / / / |/ / | __] ] HongKong Stars/Gravis UltraSound Mailing Lists Admin /_/_/_/_/|___/|_|[] Almighty1@IRC - oahu.DAL.NET Hawaii's DALnet IRC Network Server Admin To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-current in the body of the message
Re: Uncommitted dc0 fixes ...
On Tue, 10 Sep 2002, Martin Blapp wrote:
Hi,
1) dc driver uses wrong case to read MAC from eeprom.
http://www.FreeBSD.org/cgi/query-pr.cgi?pr=kern/35482
This one seems to break data sending/receiving as the only thing that
works is pinging and that's only on the alias/secondary IP and not the
primary IP network which is completely unpingable.
I expected this one to be the problem PR. I'll look at it this evening.
I guess it's probably making everything detect as a EN5152B or
something.
+ case DC_DEVICEID_EN2242: /* and DC_DEVICEID_EN5251B: */
+ if (revision DC_REVISION_EN5251B) {
+ sc-dc_type = DC_TYPE_AN985;
+ } else {
+ sc-dc_type = DC_TYPE_EN5152B;
+ }
+ sc-dc_flags |= DC_TX_USE_TX_INTR;
+ sc-dc_flags |= DC_TX_ADMTEK_WAR;
+ sc-dc_pmode = DC_PMODE_MII;
+ break;
case DC_DEVICEID_AN985:
- case DC_DEVICEID_EN2242:
sc-dc_type = DC_TYPE_AN985;
sc-dc_flags |= DC_TX_USE_TX_INTR;
sc-dc_flags |= DC_TX_ADMTEK_WAR;
This change looks wrong to me.
I guess it probably works for the originator of the PR.
Cheers,
Vince - [EMAIL PROTECTED] - Vice President __
Unix Networking Operations - FreeBSD-Real Unix for Free / / / / | / |[__ ]
WurldLink Corporation / / / / | / | __] ]
San Francisco - Honolulu - Hong Kong / / / / / |/ / | __] ]
HongKong Stars/Gravis UltraSound Mailing Lists Admin /_/_/_/_/|___/|_|[]
Almighty1@IRC - oahu.DAL.NET Hawaii's DALnet IRC Network Server Admin
To Unsubscribe: send mail to [EMAIL PROTECTED]
with unsubscribe freebsd-current in the body of the message
Re: Uncommitted dc0 fixes ...
Hi Martin: On Tue, 10 Sep 2002, Martin Blapp wrote: and Martins patch: This one works standalone and with 2 and 3 above. It seems to have increase ftp transfer rates too from 8600Kbytes/sec to 10577Kbytes/sec. Cool. Seems to depend on which notebook the card is in. With the Dell Inspiron 8200, it does do the above rates and 6722Kbyte/sec if the ftp was initiated from a Windows box. On the IBM ThinkPad 770Z, the rates are 6600Kbyte/sec on the FreeBSD machine but 3085Kbyte/sec if the ftp is initiated from the Windows machine. Ofcourse, for some odd reason, if the ftp was done from a Windows XP Pro machine, it's only 6722KBytes/sec. Hmm. TCP-window size ? And did you already tried to turn on/off the sysctls ? The TCP-Window size I have is 32767 on the Windows machines. net.inet.tcp.rfc1323 net.inet.tcp.rfc1644 Yep tried both of those already and didn't make a difference. Cheers, Vince - [EMAIL PROTECTED] - Vice President __ Unix Networking Operations - FreeBSD-Real Unix for Free / / / / | / |[__ ] WurldLink Corporation / / / / | / | __] ] San Francisco - Honolulu - Hong Kong / / / / / |/ / | __] ] HongKong Stars/Gravis UltraSound Mailing Lists Admin /_/_/_/_/|___/|_|[] Almighty1@IRC - oahu.DAL.NET Hawaii's DALnet IRC Network Server Admin To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-current in the body of the message
Re: vnode lock assertion problem in nfs_link()
On 10 Sep, Don Lewis wrote:
On 10 Sep, Bruce Evans wrote:
On Tue, 10 Sep 2002, Don Lewis wrote:
On 10 Sep, Bruce Evans wrote:
The changes are obviously just cleanups for leaf file systems, but I
wonder why everything wasn't always locked at the top. Could it have
been because locking all the way down is harmful?
I think this is because some places are still worrying about using
link(2) on directories. I think there aren't any significant problems
when vp is not a directory. Hard linking of directories was permitted
(and perhaps even supported) until relatively recently:
I suspect that you are right about this. If so, it should be able to
let namei() lock the first vnode since we check its type and bail out if
it is a directory before the second namei() call.
I looked at namei() and ufs_lookup() and found a problem with telling
the first namei() to grab the lock. It appears that the *_lookup()
routines always lock the child vnode, and namei() later releases the
lock if LOCKLEAF is not set. If we passed LOCKLEAF to the first
namei(), then link(/foo/bar, /foo/bar) would attempt to lock bar
twice.
Because we now bail out early if the first vnode turns out to be a
pointer, I believe we can dispense with the vnode inequality test and
always grab the lock.
BTW, is it safe to call ASSERT_VOP_UNLOCKED() in the SMP case after the
reference has been dropped with vput() or vrele()?
Here's a replacement for the kern_link() patch in my previous patch
file:
Index: vfs_syscalls.c
===
RCS file: /home/ncvs/src/sys/kern/vfs_syscalls.c,v
retrieving revision 1.285
diff -u -r1.285 vfs_syscalls.c
--- vfs_syscalls.c 1 Sep 2002 20:37:28 - 1.285
+++ vfs_syscalls.c 10 Sep 2002 11:28:01 -
@@ -1027,10 +1027,12 @@
if (nd.ni_vp != NULL) {
vrele(nd.ni_vp);
error = EEXIST;
- } else {
+ } else if ((error = vn_lock(vp, LK_EXCLUSIVE | LK_RETRY, td))
+ == 0) {
VOP_LEASE(nd.ni_dvp, td, td-td_ucred, LEASE_WRITE);
VOP_LEASE(vp, td, td-td_ucred, LEASE_WRITE);
error = VOP_LINK(nd.ni_dvp, vp, nd.ni_cnd);
+ VOP_UNLOCK(vp, 0, td);
}
NDFREE(nd, NDF_ONLY_PNBUF);
vput(nd.ni_dvp);
To Unsubscribe: send mail to [EMAIL PROTECTED]
with unsubscribe freebsd-current in the body of the message
Re: vnode lock assertion problem in nfs_link()
On 10 Sep, Terry Lambert wrote: Bruce Evans wrote: The changes are obviously just cleanups for leaf file systems, but I wonder why everything wasn't always locked at the top. Could it have been because locking all the way down is harmful? For a stacked local media FS, you can end up with a deadlock, if a lower vnode is exposed into the visible namespace, e.g.: oo /usr/myfs2 | /usr/myfs1| ,--.--. | || / | | quotafs o| / | `--' / | |\ / | | ffs o | `-' In general you are correct. In this case I think we are safe if we look up the first vnode and leave it unlocked, verify that it is not a directory, do the second lookup and only lock the parent directory, and only then lock the first vnode. Even with stacking, we won't attempt to lock the same vnode twice because we guarantee that the vnodes are of different types before we do the second lock. To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-current in the body of the message
freeze with the CardBus NIC 3CCFE575BT
Regardless of whether the xl driver is linked into the kernel or loaded as a module, the machine freezes shortly after ifconfig-ing the card. Sunday's -current. Complete freeeze -- can not go into debugger... More information available upon request... -mi To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-current in the body of the message
Re: ACPI video driver (for Dell Latitude C640)
On Thu, Aug 29, 2002 at 11:11:15PM +0200, Mark Santcroos wrote: I worked around this by making the driver a child of pci instead of a child of acpi. (Which is even more correct too) My driver is a child of acpi again and at this point it always seems to be called at resume too. I don't know whether that is due to the latest acpi patches (29/8) or other changes in the kernel. (At this point I don't want to spent time tracking that down) However, getting my screen back doesn't work yet. So there might be more too it. (In the worst case, the 'OFF' I do, is different than the 'OFF' the system does, so doing my 'ON' doesn't influence the systems 'OFF') It turned out to be the 'worst case'. The 'OFF' I was doing is not the same 'OFF' as the system itself is doing. (Actually my OFF was a display switch from one to another without going to the other actually. It was a wild guess and turned to be wrong) Do you think that there is a change that this is in the direction of DPMS, or is that very unliky? I tried to find the spec for DPMS but it seems to be a closed on (at least to non-members). I'm back to where I started basicly (besides knowing more about acpi now). Mark -- Mark Santcroos RIPE Network Coordination Centre http://www.ripe.net/home/mark/ New Projects Group/TTM To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-current in the body of the message
Re: vnode lock assertion problem in nfs_link()
On Tue, 10 Sep 2002, Don Lewis wrote:
The changes are obviously just cleanups for leaf file systems, but I
wonder why everything wasn't always locked at the top. Could it have
been because locking all the way down is harmful?
I think this is because some places are still worrying about using
link(2) on directories. I think there aren't any significant problems
when vp is not a directory. Hard linking of directories was permitted
(and perhaps even supported) until relatively recently:
I suspect that you are right about this. If so, it should be able to
let namei() lock the first vnode since we check its type and bail out if
it is a directory before the second namei() call.
I looked at namei() and ufs_lookup() and found a problem with telling
the first namei() to grab the lock. It appears that the *_lookup()
routines always lock the child vnode, and namei() later releases the
lock if LOCKLEAF is not set. If we passed LOCKLEAF to the first
namei(), then link(/foo/bar, /foo/bar) would attempt to lock bar
twice.
This also violates the directory vnodes before file vnodes lock order.
Generally speaking, you must always lock directories before files, since
files are always leaves, and directories may not be. The patch you have
looks fine to me, since it grabs a reference to the file but doesn't lock
it until after the directory look is held (and guarantees it's a leaf node
by checking VDIR so that it's safe to do the locking later).
Because we now bail out early if the first vnode turns out to be a
pointer, I believe we can dispense with the vnode inequality test and
always grab the lock.
Yeah. vp != VDIR, and dvp == VDIR due to earlier constraints, so we know
that vp != dvp.
BTW, is it safe to call ASSERT_VOP_UNLOCKED() in the SMP case after the
reference has been dropped with vput() or vrele()?
Well, all the VFS code currently runs under Giant so a certain class of
unsafe cases is avoided, but generally no: ASSERT_VOP_UNLOCKED() invokes a
vnode operation to determine if the vnode is locked or not, which
dereferences fields in the vnode that require a valid reference to use.
Because none of the code there currently blocks, it's not an issue
generally right now (as neither vnode is likely to have been deleted
during the link operation, so releasing the reference is unlikely to
result in chances to the vnode). It's worth fixing though.
Here's a replacement for the kern_link() patch in my previous patch
file:
Looks good to me. I'm not familiar enough with unionfs and stacking to
provide an effective review of that code, however. Maybe Jeff can give us
some comments? (unionfs is actually the reason I stalled in making the
same changes).
Index: vfs_syscalls.c
===
RCS file: /home/ncvs/src/sys/kern/vfs_syscalls.c,v
retrieving revision 1.285
diff -u -r1.285 vfs_syscalls.c
--- vfs_syscalls.c1 Sep 2002 20:37:28 - 1.285
+++ vfs_syscalls.c10 Sep 2002 11:28:01 -
@@ -1027,10 +1027,12 @@
if (nd.ni_vp != NULL) {
vrele(nd.ni_vp);
error = EEXIST;
- } else {
+ } else if ((error = vn_lock(vp, LK_EXCLUSIVE | LK_RETRY, td))
+ == 0) {
VOP_LEASE(nd.ni_dvp, td, td-td_ucred, LEASE_WRITE);
VOP_LEASE(vp, td, td-td_ucred, LEASE_WRITE);
error = VOP_LINK(nd.ni_dvp, vp, nd.ni_cnd);
+ VOP_UNLOCK(vp, 0, td);
}
NDFREE(nd, NDF_ONLY_PNBUF);
vput(nd.ni_dvp);
To Unsubscribe: send mail to [EMAIL PROTECTED]
with unsubscribe freebsd-current in the body of the message
alpha tinderbox failure
-- Rebuilding the temporary build tree -- stage 1: bootstrap tools -- stage 2: cleaning up the object tree -- stage 2: rebuilding the object tree -- stage 2: build tools -- stage 3: cross tools -- stage 4: populating /home/des/tinderbox/alpha/obj/var/tmp/des/src/alpha/usr/include -- stage 4: building libraries -- stage 4: make dependencies -- stage 4: building everything.. -- Kernel build for GENERIC started on Tue Sep 10 06:11:03 PDT 2002 -- Kernel build for GENERIC completed on Tue Sep 10 07:16:21 PDT 2002 -- Kernel build for LINT started on Tue Sep 10 07:16:23 PDT 2002 -- === LINT config: Error: device apm_saver is unknown config: Error: device cy is unknown config: Error: device cy does not take a count config: 3 errors WARNING: kernel contains GPL contaminated ext2fs filesystem FYI: static unit limits for vcoda are set: NVCODA=4 FYI: static unit limits for dgb are set: NDGB=1 FYI: static unit limits for card are set: NCARD=1 FYI: static unit limits for meteor are set: NMETEOR=1 *** Error code 1 Stop in /var/tmp/des/src. *** Error code 1 Stop in /var/tmp/des/src. To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-current in the body of the message
Re: vnode lock assertion problem in nfs_link()
On Tue, 10 Sep 2002, Don Lewis wrote: I have just one thing to add to Robert's reply. BTW, is it safe to call ASSERT_VOP_UNLOCKED() in the SMP case after the reference has been dropped with vput() or vrele()? I think it is. It has some internal locking (v_interlock at least), and only asserts that the vnode is unlocked by curthread so it doesn't matter if another thread locks it. Bruce To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-current in the body of the message
Re: [acpi-jp 1789] Re: ACPI video driver (for Dell Latitude C640)
On Thu, Aug 29, 2002 at 11:11:15PM +0200, Mark Santcroos wrote: I worked around this by making the driver a child of pci instead of a child of acpi. (Which is even more correct too) My driver is a child of acpi again and at this point it always seems to be called at resume too. I don't know whether that is due to the latest acpi patches (29/8) or other changes in the kernel. (At this point I don't want to spent time tracking that down) Sorry for my late response. I've been checking your driver, and it always seems suspend/resume methods are called. It's; DRIVER_MODULE(acpi_agp, acpi, acpi_agp_driver, acpi_agp_devclass, 0, 0); version. However, getting my screen back doesn't work yet. So there might be more too it. (In the worst case, the 'OFF' I do, is different than the 'OFF' the system does, so doing my 'ON' doesn't influence the systems 'OFF') It turned out to be the 'worst case'. The 'OFF' I was doing is not the same 'OFF' as the system itself is doing. (Actually my OFF was a display switch from one to another without going to the other actually. It was a wild guess and turned to be wrong) Do you think that there is a change that this is in the direction of DPMS, or is that very unliky? I tried to find the spec for DPMS but it seems to be a closed on (at least to non-members). It seems that old laptops don't have VGA specific ACPI objects, so many people will be happy if we can implement non-ACPI VGA driver w/ ATI chips hack. BTW, have you checked for XFree86 code? Hopefully we might find some hints on DPMS for ATI chips. I'm back to where I started basicly (besides knowing more about acpi now). Never mind. I know one more guy who writing ACPI VGA driver, takawata-san([EMAIL PROTECTED]). Could you send him your latest code and contact him? Thanks To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-current in the body of the message
Re: [acpi-jp 1789] Re: ACPI video driver (for Dell Latitude C640)
On Wed, Sep 11, 2002 at 12:22:04AM +0900, Mitsuru IWASAKI wrote: It seems that old laptops don't have VGA specific ACPI objects, so many people will be happy if we can implement non-ACPI VGA driver w/ ATI chips hack. BTW, have you checked for XFree86 code? Hopefully we might find some hints on DPMS for ATI chips. Does this mean: Yes, I think DPMS might have the answer ? Never mind. I know one more guy who writing ACPI VGA driver, takawata-san([EMAIL PROTECTED]). Could you send him your latest code and contact him? Ok, will do. Mark -- Mark Santcroos RIPE Network Coordination Centre http://www.ripe.net/home/mark/ New Projects Group/TTM To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-current in the body of the message
acpi on compaq 1701CL with current.
I just bought an new battery and that combined with the fact that I've seen so many recent emails about acpi that I decided to check my laptop. I've never really been able to take advantage of acpi with it and may never be able to, but previously I was able to do an acpidump and now I get: /root # acpidump /* RSD PTR: Checksum=202, OEMID=PTLTD, RsdtAddress=0x0fffbea3 */ acpidump: RSDT is corrupted with sysctl /root # sysctl hw.acpi sysctl: unknown oid 'hw.acpi' with kldstat /root # kldstat Id Refs AddressSize Name 1 12 0xc010 349ffc kernel 21 0xc044a000 90b0 snd_maestro3.ko 31 0xc0454000 3fea8acpi.ko 41 0xc241a000 5000 linprocfs.ko 51 0xc24d9000 14000linux.ko I seem to have the module loaded automatically. Is this probably a configuration issue, an acpi problem or could it be a problem with the bios? Thanks, ed To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-current in the body of the message
Re: Bluetooth stack for FreeBSD
On Mon, 9 Sep 2002, Maksim Yevmenkin wrote: I still would like to hear from people. I'm extremely surprised that FreeBSD community seems not interested in this at all. I got very few replies from few people (Julian Elischer, Terry Lambert - thanks!) and that's it. I'm very interested, as are some other people I know, but we just don't have any bluetooth hardware to use yet. Don't think people don't care and thanks for the good work. :-) -- Chris Dillon - cdillon(at)wolves.k12.mo.us FreeBSD: The fastest and most stable server OS on the planet - Available for IA32 (Intel x86) and Alpha architectures - IA64, PowerPC, UltraSPARC, ARM, and S/390 under development - http://www.freebsd.org No trees were harmed in the composition of this message, although some electrons were mildly inconvenienced. To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-current in the body of the message
Build failure rpm
I was trying to update linux_base and got the following build failure: cc -DHAVE_CONFIG_H -I. -I. -I.. -I.. -I../build -I../misc -I/usr/local/include -I/usr/local/include -O -pipe -D_GNU_SOURCE -Wall -Wpointer-arith -Wstrict-prototypes -Wmissing-prototypes -Wno-char-subscripts -c cpio.c -fPIC -DPIC -o .libs/cpio.lo In file included from ../system.h:279, from cpio.c:1: ../misc/glob.h:51: redefinition of `__size_t' /usr/include/machine/_types.h:81: `__size_t' previously declared here gmake[2]: *** [cpio.lo] Error 1 gmake[2]: Leaving directory `/usr/ports/archivers/rpm/work/rpm-3.0.6/lib' gmake[1]: *** [all-recursive] Error 1 Running -current (yesterday). Beech -- --- Beech Rintoul - SysAdmin - [EMAIL PROTECTED] /\ ASCII Ribbon Campaign | Sinbad Network Communications \ / - NO HTML/RTF in e-mail | 3101 Penland Parkway #K-38 X - NO Word docs in e-mail | Anchorage, AK 99508-1957 / \ - To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-current in the body of the message
Re: Bluetooth stack for FreeBSD
FUJIMOTO Kou wrote: Poul-Henning Kamp wrote: In message [EMAIL PROTECTED], Maksim Yevmenkin writes: I still would like to hear from people. I'm extremely surprised that FreeBSD community seems not interested in this at all. I got very few replies from few people (Julian Elischer, Terry Lambert - thanks!) and that's it. Most of us probably doesn't have any bluetooth hardware... I have a BT PCMCIA card by IBM, a BT USB adapter by MITSUMI, IBM PCMCIA card is not supported this time. If you can get spec. i will write a driver for it. In the mean time can you send card CIS dump to me? MITSUMI USB adapter is likely to work. I think it is a CSR/Bluecore based product (i.e. similar to 3Com USB dongle). But you will need to give me VendorID and ProductID so i can add it to the list of supported devices in ubt.c. Just load ugen driver plug USB dongle and note vendor and product IDs. you also can get the same information via usbdevs. a C413S BT mobile phone by Sony, and a BT adapter for Sony CLIE. A communication between CLIE/C413S and PC does not work properly with Windows OS. Mobile phone and CLIE work well, because no Windows needed and it's a Sony-to-Sony connection! sorry, but i have no clue about Bluetooth phones and handhelds. you've got to try it. i will try to do my best in helping you. Anyway, I am willing to be a tester and you could find more ones in Japan, because there're dozens of Bluetooth PCs and devices. great! thanks a lot! max. To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-current in the body of the message
i386 tinderbox failure
-- Rebuilding the temporary build tree -- stage 1: bootstrap tools -- stage 2: cleaning up the object tree -- stage 2: rebuilding the object tree -- stage 2: build tools -- stage 3: cross tools -- stage 4: populating /home/des/tinderbox/i386/obj/local0/scratch/des/src/i386/usr/include -- stage 4: building libraries -- stage 4: make dependencies -- stage 4: building everything.. -- Kernel build for GENERIC started on Tue Sep 10 09:39:00 PDT 2002 -- === xe cc1: warnings being treated as errors /local0/scratch/des/src/sys/dev/cardbus/cardbus.c: In function `cardbus_driver_added': /local0/scratch/des/src/sys/dev/cardbus/cardbus.c:319: warning: unused variable `cardattached' *** Error code 1 Stop in /local0/scratch/des/obj/local0/scratch/des/src/sys/GENERIC. *** Error code 1 Stop in /local0/scratch/des/src. *** Error code 1 Stop in /local0/scratch/des/src. To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-current in the body of the message
Re: Bluetooth stack for FreeBSD
In message: [EMAIL PROTECTED] Chris Dillon [EMAIL PROTECTED] writes: : On Mon, 9 Sep 2002, Maksim Yevmenkin wrote: : : I still would like to hear from people. I'm extremely surprised that : FreeBSD community seems not interested in this at all. I got very : few replies from few people (Julian Elischer, Terry Lambert - : thanks!) and that's it. : : I'm very interested, as are some other people I know, but we just : don't have any bluetooth hardware to use yet. Don't think people : don't care and thanks for the good work. :-) I know I'm interested in bluetooth, but have no space cycles in which to help someone get something like this into the shape needed to integrate it into the tree. Warner To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-current in the body of the message
Re: i386 tinderbox failure
On Tue, 10 Sep 2002, Dag-Erling Smorgrav wrote: :cc1: warnings being treated as errors :/local0/scratch/des/src/sys/dev/cardbus/cardbus.c: In function `cardbus_driver_added': :/local0/scratch/des/src/sys/dev/cardbus/cardbus.c:319: warning: unused variable :`cardattached' :*** Error code 1 I just committed a fix for this, JFYI. Cheers, -- Andrew R. Reiter [EMAIL PROTECTED] [EMAIL PROTECTED] To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-current in the body of the message
Re: Bluetooth stack for FreeBSD
On 10-Sep-2002 M. Warner Losh wrote: In message: [EMAIL PROTECTED] Chris Dillon [EMAIL PROTECTED] writes: : On Mon, 9 Sep 2002, Maksim Yevmenkin wrote: : : I still would like to hear from people. I'm extremely surprised that : FreeBSD community seems not interested in this at all. I got very : few replies from few people (Julian Elischer, Terry Lambert - : thanks!) and that's it. : : I'm very interested, as are some other people I know, but we just : don't have any bluetooth hardware to use yet. Don't think people : don't care and thanks for the good work. :-) I know I'm interested in bluetooth, but have no space cycles in which to help someone get something like this into the shape needed to integrate it into the tree. I contacted Maksim off list. I can get limited access to a Bluetooth qualification lab. (out of hours etc.) and will try and get his stack tested against a number of other solutions. Duncan -- Duncan Barclay | God smiles upon the little children, [EMAIL PROTECTED] | the alcoholics, and the permanently stoned. [EMAIL PROTECTED]| Steven King To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-current in the body of the message
Re: Bluetooth stack for FreeBSD
On Tue, 10 Sep 2002, Chris Dillon wrote: On Mon, 9 Sep 2002, Maksim Yevmenkin wrote: I still would like to hear from people. I'm extremely surprised that FreeBSD community seems not interested in this at all. I got very few replies from few people (Julian Elischer, Terry Lambert - thanks!) and that's it. I'm very interested, as are some other people I know, but we just don't have any bluetooth hardware to use yet. Don't think people don't care and thanks for the good work. :-) Yes. we are aware of the work and we are pleased that it is hapenning, but few of us have even SEEN any bluetooth stuff yet.. certainly in the US it's not yet being marketted a lot. Until it becomes more common all we can say is hey FreeBSD is there ahead of the crowd :-) To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-current in the body of the message
panic: ufs_dirbad: bad dir
I got this on the bento cluster this morning (-current from about 2 days ago): /x: bad dir ino 3180135 at offset 0: mangled entry panic: ufs_dirbad: bad dir Debugger(panic) Stopped at Debugger+0x54: xchgl %ebx,in_Debugger.0 db trace Debugger(c03f45bc,c0473f80,c040e087,ceac4974,) at Debugger+0x54 panic(c040e087,c25f9aac,308667,0,c040e02c) at panic+0x90 ufs_dirbad(c44b7100,0,c040e02c,0,ceac49f4) at ufs_dirbad+0x52 ufs_lookup(ceac4b20,ceac4b5c,c0286539,ceac4b20,ceac4c98) at ufs_lookup+0x317 ufs_vnoperate(ceac4b20,ceac4c98,ceac4cac,c040dfa0,52) at ufs_vnoperate+0x18 vfs_cache_lookup(ceac4bd0,ceac4bfc,c028aa22,ceac4bd0,c3d9dc00) at vfs_cache_lookup+0x3b9 ufs_vnoperate(ceac4bd0,c3d9dc00,0,c3d9dc00,c3d9dc00) at ufs_vnoperate+0x18 lookup(ceac4c84,0,c03fb880,a4,c3d9dc00) at lookup+0x302 namei(ceac4c84,c043c600,c03f80e0,bfbffb3e,0) at namei+0x24e unmount(c3d9dc00,ceac4d10,c041a960,418,2) at unmount+0x3d syscall(2f,2f,2f,8099291,80b5005) at syscall+0x2c4 Xint0x80_syscall() at Xint0x80_syscall+0x1d --- syscall (22, FreeBSD ELF32, unmount), eip = 0x804aea3, esp = 0xbfbff46c, ebp = 0xbfbff4e8 --- An earlier console message which may be important: ad0: READ command timeout tag=0 serv=0 - resetting ata0: resetting devices .. done Any ideas? Kris msg42848/pgp0.pgp Description: PGP signature
Re: Build failure rpm
On Tue, Sep 10, 2002 at 08:21:31AM -0800, Beech Rintoul wrote: I was trying to update linux_base and got the following build failure: Known problem; see the list archives for a patch. Kris msg42849/pgp0.pgp Description: PGP signature
[no subject]
subscribe freebsd-current [EMAIL PROTECTED] To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-current in the body of the message
Re: Bluetooth stack for FreeBSD
Julian, On Tue, 10 Sep 2002, Chris Dillon wrote: On Mon, 9 Sep 2002, Maksim Yevmenkin wrote: I still would like to hear from people. I'm extremely surprised that FreeBSD community seems not interested in this at all. I got very few replies from few people (Julian Elischer, Terry Lambert - thanks!) and that's it. I'm very interested, as are some other people I know, but we just don't have any bluetooth hardware to use yet. Don't think people don't care and thanks for the good work. :-) Yes. we are aware of the work and we are pleased that it is hapenning, but few of us have even SEEN any bluetooth stuff yet.. certainly in the US it's not yet being marketted a lot. Please :-) May i suggest to look at www.compusa.com and search for Bluetooth. Then try to look for the nearest store that has it. Prices = $100. Yes, it is more expensive then 802.11. Yes, you can not do a lot with it right now, but Microsoft and Apple already claim support for Bluetooth. Yes, i know, claim does not mean much :-) Until it becomes more common all we can say is hey FreeBSD is there ahead of the crowd :-) Linux had Bluetooth stuff for almost a year now. Or may be even longer. People in Europe try to use Linux with Bluetooth for all sort of stuff, access points, printers, headset, phones you name it. Some even run in on iPAQ and Sharp Zaurus. Is that common for you? :-) I'm not trying to troll. You anyone wants to discuss it further, please, please, please take it off the list. thanks, max To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-current in the body of the message
Re: Bluetooth stack for FreeBSD
Am Di, 2002-09-10 um 19.48 schrieb Julian Elischer: On Tue, 10 Sep 2002, Chris Dillon wrote: On Mon, 9 Sep 2002, Maksim Yevmenkin wrote: I still would like to hear from people. I'm extremely surprised that FreeBSD community seems not interested in this at all. I got very few replies from few people (Julian Elischer, Terry Lambert - thanks!) and that's it. *SNIP* Yes. we are aware of the work and we are pleased that it is hapenning, but few of us have even SEEN any bluetooth stuff yet.. certainly in the US it's not yet being marketted a lot. Until it becomes more common all we can say is hey FreeBSD is there ahead of the crowd :-) I'm very happy too, and I do have hardware (VAIO and a t68) but no time right now. I'll do some tests ASAP! Thanks, -Harry To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-current in the body of the message To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-current in the body of the message
Re: kern_timeout.c msg Expensive timeout(9) function: 0xc026f3ec(0xc4067800) 0.006773207
I've seen the scrn_timer() one too: Expensive timeout(9) function: 0xc049b3f0(0xc0657200) 0.003659743 c049b3f0 t scrn_timer as well as uma_timeout(). Expensive timeout(9) function: 0xc047c6b0(0) 0.002146136 c047c6b0 t uma_timeout Bill To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-current in the body of the message
Re: [acpi-jp 1789] Re: ACPI video driver (for Dell Latitude C640)
On Wed, Sep 11, 2002 at 12:22:04AM +0900, Mitsuru IWASAKI wrote: Do you think that there is a change that this is in the direction of DPMS, or is that very unliky? I tried to find the spec for DPMS but it seems to be a closed on (at least to non-members). It seems that old laptops don't have VGA specific ACPI objects, so many people will be happy if we can implement non-ACPI VGA driver w/ ATI chips hack. BTW, have you checked for XFree86 code? Hopefully we might find some hints on DPMS for ATI chips. Ok, listen to this ;-) I think DPMS might be very related, because when I suspend from X and resume again everything is (almost) fine!! 1. I start up the machine 2. startx 3. I enter S1 either by acpiconf / closing the lid / ctrl-esc (sleep key) 4. Screen goes to console and stays on 5. I resume with power key / open lid 6. Screen turns black 7. Few seconds later X is in front of me again! 8. If I now go back to the console (ctrl-f1) the console is still black I also tried the scenario where I suspend on the console, then resume again, which turns the screen black. I then startx again and my screen is back again. This is a major step IMHO. I already looked at the DPMS code in X and we have to extract that basically. Mark -- Mark Santcroos RIPE Network Coordination Centre http://www.ripe.net/home/mark/ New Projects Group/TTM To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-current in the body of the message
Re: freeze with the CardBus NIC 3CCFE575BT
On Tue, 10 Sep 2002, Mikhail Teterin wrote: Regardless of whether the xl driver is linked into the kernel or loaded as a module, the machine freezes shortly after ifconfig-ing the card. Sunday's -current. Complete freeeze -- can not go into debugger... More information available upon request... -mi This is interesting. I have the CardBus 3Com NIC 3CXFEM656C which is the type II card that takes one slot but a combo with 56k modem and the Megahertz XJack. With Sunday's -current and the 08182002-JP SNAPSHOT, the card works fine under xl0 driver with the Dell Inspiron 8200 Notebook when I moved the HDD from the IBM ThinkPad 770Z. On the 770Z however, as soon as I do the ifconfig, it'll xl0: watchdog timer all over and it will ping with latencies at 8000ms. So not sure what the problem is. Other cards which I have tried, the Siemens/Efficient Networks SpeedStream SS1012 and the SMC Networks SMC8036TX which seems to be identical cards physically as it has the same design and same label printing information layout seems to work fine on both machines. The NetGear FA511 and the LinkSys PCM200 both don't work at all since FreeBSD can't detect the device id or something. Cheers, Vince - [EMAIL PROTECTED] - Vice President __ Unix Networking Operations - FreeBSD-Real Unix for Free / / / / | / |[__ ] WurldLink Corporation / / / / | / | __] ] San Francisco - Honolulu - Hong Kong / / / / / |/ / | __] ] HongKong Stars/Gravis UltraSound Mailing Lists Admin /_/_/_/_/|___/|_|[] Almighty1@IRC - oahu.DAL.NET Hawaii's DALnet IRC Network Server Admin To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-current in the body of the message
Re: Bluetooth stack for FreeBSD
Yes. we are aware of the work and we are pleased that it is hapenning, but few of us have even SEEN any bluetooth stuff yet.. certainly in the US it's not yet being marketted a lot. Fry's Electronics in the SF bayarea has a bunch of bluetooth gadgets. Go to www.outpost.com and search for 'bluetooth'. USB adapters, pcmcia card, printer adapter, connectors for Palm and iPAQ etc. The printer adapter looks just like a standard paraller port connector with a RJ11 or RJ45 socket on one side (you can hook up a serial cable to it too). To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-current in the body of the message
Re: vnode lock assertion problem in nfs_link()
On 11 Sep, Bruce Evans wrote: On Tue, 10 Sep 2002, Don Lewis wrote: I have just one thing to add to Robert's reply. BTW, is it safe to call ASSERT_VOP_UNLOCKED() in the SMP case after the reference has been dropped with vput() or vrele()? I think it is. It has some internal locking (v_interlock at least), and only asserts that the vnode is unlocked by curthread so it doesn't matter if another thread locks it. I'm mostly worried about the vnode being recycled as something else after the vput() or vrele() call. I think a better approach would be to add the assertion checks to vput() and vrele(), which would mean that we could remove most of the checks in the syscall code. The only problems we would miss would be when we leak vnode references, but reference leaks are a problem anyway. I wish there was a good way to add assertion checks for detecting the leaks. To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-current in the body of the message
Re: vnode lock assertion problem in nfs_link()
On Tue, 10 Sep 2002, Don Lewis wrote: On 11 Sep, Bruce Evans wrote: On Tue, 10 Sep 2002, Don Lewis wrote: I have just one thing to add to Robert's reply. BTW, is it safe to call ASSERT_VOP_UNLOCKED() in the SMP case after the reference has been dropped with vput() or vrele()? I think it is. It has some internal locking (v_interlock at least), and only asserts that the vnode is unlocked by curthread so it doesn't matter if another thread locks it. I'm mostly worried about the vnode being recycled as something else after the vput() or vrele() call. I think a better approach would be to add the assertion checks to vput() and vrele(), which would mean that we could remove most of the checks in the syscall code. The only problems we would miss would be when we leak vnode references, but reference leaks are a problem anyway. I wish there was a good way to add assertion checks for detecting the leaks. Unfortunately, we can't assert not locked at the end of vput because of recursive locking of vnodes. What I would like to see is a check that, when control is returned to userland, that the thread owns no locks. It's a bit like sleeping while holding a mutex: don't do that. Also, last time I tried to use the ddb show lockedvnods command, I got the problem attached below due to locking issues, which makes it a lot harder to debug locking problems... Robert N M Watson FreeBSD Core Team, TrustedBSD Projects [EMAIL PROTECTED] Network Associates Laboratories db show lockedvnods Locked vnodes panic: blockable sleep lock (sleep mutex) mountlist @ ../../../kern/vfs_subr.c:2621 Debugger(panic) Fatal trap 3: breakpoint instruction fault while in kernel mode instruction pointer = 0x8:0xc0423ed4 stack pointer = 0x10:0xc869b9d0 frame pointer = 0x10:0xc869b9dc code segment= base 0x0, limit 0xf, type 0x1b = DPL 0, pres 1, def32 1, gran 1 processor eflags= IOPL = 0 current process = 11 (idle) Stopped at siointr1+0xf4: movl$0,brk_state1.0 To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-current in the body of the message
Re: vnode lock assertion problem in nfs_link()
On 10 Sep, Robert Watson wrote: On Tue, 10 Sep 2002, Don Lewis wrote: I'm mostly worried about the vnode being recycled as something else after the vput() or vrele() call. I think a better approach would be to add the assertion checks to vput() and vrele(), which would mean that we could remove most of the checks in the syscall code. The only problems we would miss would be when we leak vnode references, but reference leaks are a problem anyway. I wish there was a good way to add assertion checks for detecting the leaks. Unfortunately, we can't assert not locked at the end of vput because of recursive locking of vnodes. I was actually thinking of adding the assertion at the beginning of vput to check that the vnode was locked. I forgot about recursive locking, so doing any checking inside vrele() wouldn't work. What I would like to see is a check that, when control is returned to userland, that the thread owns no locks. That sounds neat, though the obvious solution of traversing the vnode list would sure slow things down ... To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-current in the body of the message
Re: vnode lock assertion problem in nfs_link()
On Tue, 10 Sep 2002, Robert Watson wrote: ... Also, last time I tried to use the ddb show lockedvnods command, I got the problem attached below due to locking issues, which makes it a lot harder to debug locking problems... Robert N M Watson FreeBSD Core Team, TrustedBSD Projects [EMAIL PROTECTED] Network Associates Laboratories db show lockedvnods Locked vnodes panic: blockable sleep lock (sleep mutex) mountlist @ ../../../kern/vfs_subr.c:2621 Debugger(panic) Try removing all the locking in the command. ddb commands can't use locking. I have printfs in _mtx_lock_flags(), _mtx_lock_spin_flags(), _mtx_lock_sleep() and _mtx_lock_spin() to detect locking when ddb is active. The error handling would be better if trap_fatal() were called before panic panic(), like it is for null pointer panics. ddb on i386's then notices that it shot itself and longjmps to its entry point. This handles things like reading through garbage pointers OK, but not external state changes like locking. Maybe my printfs should be trap_fatals or or direct longjmps. Bruce To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-current in the body of the message
Re: Build failure rpm
On Tuesday 10 September 2002 10:11 am, Kris Kennaway wrote: On Tue, Sep 10, 2002 at 08:21:31AM -0800, Beech Rintoul wrote: I was trying to update linux_base and got the following build failure: Known problem; see the list archives for a patch. Kris Already applied those patches, still getting the same error. Beech --- Beech Rintoul - SysAdmin - [EMAIL PROTECTED] /\ ASCII Ribbon Campaign | Sinbad Network Communications \ / - NO HTML/RTF in e-mail | 3101 Penland Parkway #K-38 X - NO Word docs in e-mail | Anchorage, AK 99508-1957 / \ - To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-current in the body of the message
It works ! (was Re: Unable to buildworld (new record, 18))
On 08-Sep-2002 (19:54:17/GMT) Riccardo Torrini wrote: There have been at least two gcc upgrades since then. I believe the easiest way to upgrade to today's -current would be to install a fairly recent snapshot ... instead of trying to debug ... I have tryed with a middle version (1 jul 2002) but it fails without and with make includes before build, now I'm trying with cvsup from 15 aug 2002 (as written by Munish Chopra on 1 sep: IIRC current was in good shape between August 12-15, 17, 18, 22-24) ... Ok. All done. My start point was really too old, anyway this is the full story: - starting from -CURRENT of 8 May, used as desktop (full of bells and whistles, homes on a nfs disk on a safe -STABLE local server :-) - cvsuped daily and compiled w/out install at least once a week (this before holidays). - tryed to upgrade to latest -CURRENT last week w/out success, with a lot of error, maybe due to double gcc update (2.95 - 3.1 - 3.2) - cvsuped back to 1 jul, new buildworld, failed - found mail into archives speaking about some good shape days - cvsuped again to 15 aug, new buildworld, failed - added some switches: -DNOCLEAN, -DNO_WERROR, -DNOCRYPT (one at a time, every time world go forward a bit) - build complete, kernel complete, install complete, reboot ... and Yes! I forgot mergemaster :( - new full buildworld w/out switches, complete fine. new kernel, another full install, mergemaster :-) reboot. NB: build done w/out CPUTYPE (usually was =p3) and with CFLAGS= -O2 -pipe Hoping this can help others not-too-current users. Upgrade always possible, even from old versions (with some care) Now last doubt: after next upgrade to post-gcc_3.2 is a complete port rebuild necessary because c++ ports stop working or not? Thanks a lot, Riccardo, now more-current :-) To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-current in the body of the message
Re: vnode lock assertion problem in nfs_link()
On 9 Sep, Don Lewis wrote:
On 9 Sep, Robert Watson wrote:
What I'd actually like to do is lock vp on going in to the VOP. I need to
grab the lock in the link() code anyway to do the MAC check. UFS and
others all immediately lock the vnode on entry anyway...
Here's a patch to implement this. It compiles and seems to work OK, but
needs review. There are a couple of issues that definitely need a look:
The VOP_LINK(9) man page needs would also need to be updated.
Here's a patch to the man page that also fixes a bunch of bit rot that
has accumulated:
Index: VOP_LINK.9
===
RCS file: /home/ncvs/src/share/man/man9/VOP_LINK.9,v
retrieving revision 1.13
diff -u -r1.13 VOP_LINK.9
--- VOP_LINK.9 1 Oct 2001 16:09:24 - 1.13
+++ VOP_LINK.9 10 Sep 2002 22:21:53 -
@@ -52,18 +52,13 @@
pathname information about the file
.El
.Pp
-The pathname info must be released on exit. The directory and
-file vnodes should NOT be released on exit.
+The pathname info should NOT be released on exit because it is done
+by the caller.
+The directory and file vnodes should NOT be released on exit.
.Sh LOCKS
-The directory,
-.Fa dvp
-is locked on entry and should remain locked on return.
-The file
-.Fa vp
-is not locked on entry and should remain that way on return.
-If your VOP code locks
-.Fa vp ,
-it must be sure to unlock prior to returning.
+.Xr VOP_LINK 9
+expects the directory and file vnodes to be locked on entry and will leave
+the vnodes locked on return.
.Sh RETURN VALUES
Zero is returned if the file was linked successfully, otherwise an
error is returned.
@@ -74,27 +69,14 @@
{
int error = 0;
-if (vp-v_mount != dvp-v_mount) {
- error = EXDEV;
- goto out2;
-}
-if (vp != dvp (error = VOP_LOCK(vp))) {
- goto out2;
-}
-
-/*
- * now that we've locked vp, we have to use out1 instead of out2
- */
+if (vp-v_mount != dvp-v_mount)
+ return (EXDEV);
-if (vp would have too many links) {
- error = EMLINK;
- goto out1;
-}
+if (vp would have too many links)
+ return (EMLINK);
-if (vp is immutable) {
- error = EPERM;
- goto out1;
-}
+if (vp is immutable)
+ return (EPERM);
/*
* Increment link count of vp and write back the on-disc version of it.
@@ -108,19 +90,21 @@
...;
}
-free(cnp-cn_pnbuf, M_NAMEI);
-out1:
-if (vp != dvp)
- VOP_UNLOCK(vp);
-out2:
-
return error;
}
.Ed
.Sh ERRORS
.Bl -tag -width Er
+.It Bq Er EMLINK
+the file has too many links
+.El
+.Bl -tag -width Er
.It Bq Er EPERM
the file is immutable
+.El
+.Bl -tag -width Er
+.It Bq Er EXDEV
+a hard link is not possible between different file systems
.El
.Sh SEE ALSO
.Xr vnode 9 ,
To Unsubscribe: send mail to [EMAIL PROTECTED]
with unsubscribe freebsd-current in the body of the message
vnode lock assertion problem in nfs_rename()
On 9 Sep, Don Lewis wrote: nfs_link() contains the following code: /* * Push all writes to the server, so that the attribute cache * doesn't get out of sync with the server. * XXX There should be a better way! */ VOP_FSYNC(vp, cnp-cn_cred, MNT_WAIT, cnp-cn_thread); The problem is that vp is not locked by the caller, but VOP_FSYNC() expects its argument to be locked. I think we can probably just lock and unlock vp around the call to VOP_FSYNC() ... There's a similar problem in nfs_rename(): /* * We have to flush B_DELWRI data prior to renaming * the file. If we don't, the delayed-write buffers * can be flushed out later after the file has gone stale * under NFSV3. NFSV2 does not have this problem because * ( as far as I can tell ) it flushes dirty buffers more * often. */ VOP_FSYNC(fvp, fcnp-cn_cred, MNT_WAIT, fcnp-cn_thread); if (tvp) VOP_FSYNC(tvp, tcnp-cn_cred, MNT_WAIT, tcnp-cn_thread); fvp is not locked by the caller. To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-current in the body of the message
-current buildworld fails with revision 1.38 src/usr.bin/uudecode/uudecode.c
=== usr.bin/uudecode /usr/obj/usr/src/i386/usr/src/usr.bin/uudecode created for /usr/src/usr.bin/uudecode rm -f .depend mkdep -f .depend -a-D__FBSDID=__RCSID /usr/src/usr.bin/uudecode/uudecode.c echo uudecode: /usr/lib/libc.a .depend cc -O -pipe -Wall -Wno-format-y2k -W -Wstrict-prototypes -Wmissing-prototypes -Wpointer-arith -Wreturn-type -Wcast-qual -Wwrite-strings -Wswitch -Wshadow -Wcast-align -Wno-uninitialized -D__FBSDID=__RCSID -c /usr/src/usr.bin/uudecode/uudecode.c /usr/src/usr.bin/uudecode/uudecode.c: In function `decode2': /usr/src/usr.bin/uudecode/uudecode.c:225: warning: comparison between signed and unsigned /usr/src/usr.bin/uudecode/uudecode.c:275: syntax error before ch /usr/src/usr.bin/uudecode/uudecode.c:286: syntax error before ch /usr/src/usr.bin/uudecode/uudecode.c:294: syntax error before ch /usr/src/usr.bin/uudecode/uudecode.c:301: syntax error before ch *** Error code 1 1 error *** Error code 2 1 error *** Error code 2 1 error *** Error code 2 1 error Cheers, Vince - [EMAIL PROTECTED] - Vice President __ Unix Networking Operations - FreeBSD-Real Unix for Free / / / / | / |[__ ] WurldLink Corporation / / / / | / | __] ] San Francisco - Honolulu - Hong Kong / / / / / |/ / | __] ] HongKong Stars/Gravis UltraSound Mailing Lists Admin /_/_/_/_/|___/|_|[] Almighty1@IRC - oahu.DAL.NET Hawaii's DALnet IRC Network Server Admin To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-current in the body of the message
World broken at uudecode [Sep 10]
cc -O -pipe -mcpu=pentiumpro -Werror -Wall -Wno-format-y2k -W -Wstrict-prototypes -Wmissing-prototypes -Wpointer-arith -Wreturn-type -Wcast-qual -Wwrite-strings -Wswitch -Wshadow -Wcast-align -Wno-uninitialized -c /usr/src/usr.bin/uudecode/uudecode.c cc1: warnings being treated as errors /usr/src/usr.bin/uudecode/uudecode.c: In function `decode2': /usr/src/usr.bin/uudecode/uudecode.c:225: warning: comparison between signed and unsigned /usr/src/usr.bin/uudecode/uudecode.c:275: syntax error before ch /usr/src/usr.bin/uudecode/uudecode.c:286: syntax error before ch /usr/src/usr.bin/uudecode/uudecode.c:294: syntax error before ch /usr/src/usr.bin/uudecode/uudecode.c:301: syntax error before ch *** Error code 1 To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-current in the body of the message
Re: World broken at uudecode [Sep 10]
On Tue, Sep 10, 2002 at 05:09:55PM -0700, walt wrote:
cc -O -pipe -mcpu=pentiumpro -Werror -Wall -Wno-format-y2k -W -Wstrict-prototypes
-Wmissing-prototypes -Wpointer-arith -Wreturn-type -Wcast-qual -Wwrite-strings
-Wswitch
-Wshadow -Wcast-align -Wno-uninitialized -c /usr/src/usr.bin/uudecode/uudecode.c
cc1: warnings being treated as errors
/usr/src/usr.bin/uudecode/uudecode.c: In function `decode2':
/usr/src/usr.bin/uudecode/uudecode.c:225: warning: comparison between signed and
unsigned
/usr/src/usr.bin/uudecode/uudecode.c:275: syntax error before ch
/usr/src/usr.bin/uudecode/uudecode.c:286: syntax error before ch
/usr/src/usr.bin/uudecode/uudecode.c:294: syntax error before ch
/usr/src/usr.bin/uudecode/uudecode.c:301: syntax error before ch
*** Error code 1
Try this patch:
--- uudecode.c.orig Tue Sep 10 20:26:48 2002
+++ uudecode.c Tue Sep 10 20:29:44 2002
@@ -153,7 +153,7 @@
decode2(void)
{
int base64;
- int n;
+ size_t n;
char ch, *p, *q;
void *mode;
struct passwd *pw;
@@ -258,7 +258,7 @@
warnx(%s: %s: character out of range: [%d-%d],\
filename, buffn, 1 + ' ', 077 + ' ' + 1); \
return (1);\
-} while (0)
+} while (0);
/*
* `n' is used to avoid writing out all the characters
--
Craig Rodrigues
http://www.gis.net/~craigr
[EMAIL PROTECTED]
To Unsubscribe: send mail to [EMAIL PROTECTED]
with unsubscribe freebsd-current in the body of the message
Re: Locking problems in exec
On 7 Sep, Garrett Wollman wrote: I just noted the following: ../../../vm/uma_core.c:1332: could sleep with process lock locked from ../../../kern/kern_exec.c:368 lock order reversal 1st 0xc438e6a8 process lock (process lock) @ ../../../kern/kern_exec.c:368 2nd 0xc0413d20 filelist lock (filelist lock) @ ../../../kern/kern_descrip.c:1133 ../../../vm/uma_core.c:1332: could sleep with process lock locked from ../../../kern/kern_exec.c:368 $ ident /sys/kern/kern_exec.c /sys/kern/kern_exec.c: $FreeBSD: src/sys/kern/kern_exec.c,v 1.189 2002/09/05 07:30:14 davidxu Exp $ $ ident /sys/kern/kern_descrip.c /sys/kern/kern_descrip.c: $FreeBSD: src/sys/kern/kern_descrip.c,v 1.158 2002/09/03 20:16:31 jhb Exp $ This occurred when starting up Netscape. I just saw this in a recent version of -stable while running mozilla. I think the problem is in the following set?id handling code in execve(): /* Close any file descriptors 0..2 that reference procfs */ setugidsafety(td); /* Make sure file descriptors 0..2 are in use. */ error = fdcheckstd(td); if (error != 0) goto done1; When I looked at this code before, I assumed that fdcheckstd() just verified that the proper fds where in use, but on closer inspection it appears that fdcheckstd() attempts to point any unused fds in 0..2 to /dev/null. This calls falloc(), which calls uma_zalloc() and grabs the filelist lock, all of which happens while execve() holds the process lock. The do_dup() call in fdcheckstd() could also be a problem. I don't think dropping the process lock is correct, and calling falloc() and vn_open() before grabbing the process lock might also be insecure. Other than just causing execve() to fail in this situation, the only other fix that I can think of would be to preallocate the struct file and pre-open /dev/null if we're execing a set?id executable, and then jam this into the descriptor table if it turns out to be needed. Barf! I think netscape and mozilla must be exec'ing some set?id system binary in the background and didn't pass the correct descriptors. To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-current in the body of the message
alpha tinderbox failure
-- Rebuilding the temporary build tree -- stage 1: bootstrap tools -- stage 2: cleaning up the object tree -- stage 2: rebuilding the object tree -- stage 2: build tools -- stage 3: cross tools -- stage 4: populating /home/des/tinderbox/alpha/obj/var/tmp/des/src/alpha/usr/include -- stage 4: building libraries -- stage 4: make dependencies -- stage 4: building everything.. -- Kernel build for GENERIC started on Tue Sep 10 18:25:39 PDT 2002 -- Kernel build for GENERIC completed on Tue Sep 10 19:30:45 PDT 2002 -- Kernel build for LINT started on Tue Sep 10 19:30:45 PDT 2002 -- === LINT config: Error: device apm_saver is unknown config: Error: device cy is unknown config: Error: device cy does not take a count config: 3 errors WARNING: kernel contains GPL contaminated ext2fs filesystem FYI: static unit limits for vcoda are set: NVCODA=4 FYI: static unit limits for dgb are set: NDGB=1 FYI: static unit limits for card are set: NCARD=1 FYI: static unit limits for meteor are set: NMETEOR=1 *** Error code 1 Stop in /var/tmp/des/src. *** Error code 1 Stop in /var/tmp/des/src. To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-current in the body of the message
Re: It works ! (was Re: Unable to buildworld (new record, 18))
On 2002-09-11 00:04, Riccardo Torrini [EMAIL PROTECTED] wrote: Now last doubt: after next upgrade to post-gcc_3.2 is a complete port rebuild necessary because c++ ports stop working or not? Yes. To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-current in the body of the message
Re: Locking problems in exec
On Tue, 10 Sep 2002, Don Lewis wrote: On 7 Sep, Garrett Wollman wrote: I just noted the following: ../../../vm/uma_core.c:1332: could sleep with process lock locked from ../../../kern/kern_exec.c:368 lock order reversal 1st 0xc438e6a8 process lock (process lock) @ ../../../kern/kern_exec.c:368 2nd 0xc0413d20 filelist lock (filelist lock) @ ../../../kern/kern_descrip.c:1133 ../../../vm/uma_core.c:1332: could sleep with process lock locked from ../../../kern/kern_exec.c:368 $ ident /sys/kern/kern_exec.c /sys/kern/kern_exec.c: $FreeBSD: src/sys/kern/kern_exec.c,v 1.189 2002/09/05 07:30:14 davidxu Exp $ $ ident /sys/kern/kern_descrip.c /sys/kern/kern_descrip.c: $FreeBSD: src/sys/kern/kern_descrip.c,v 1.158 2002/09/03 20:16:31 jhb Exp $ This occurred when starting up Netscape. I just saw this in a recent version of -stable while running mozilla. I think the problem is in the following set?id handling code in execve(): /* Close any file descriptors 0..2 that reference procfs */ setugidsafety(td); /* Make sure file descriptors 0..2 are in use. */ error = fdcheckstd(td); if (error != 0) goto done1; When I looked at this code before, I assumed that fdcheckstd() just verified that the proper fds where in use, but on closer inspection it appears that fdcheckstd() attempts to point any unused fds in 0..2 to /dev/null. This calls falloc(), which calls uma_zalloc() and grabs the filelist lock, all of which happens while execve() holds the process lock. The do_dup() call in fdcheckstd() could also be a problem. I don't think dropping the process lock is correct, and calling falloc() and vn_open() before grabbing the process lock might also be insecure. Other than just causing execve() to fail in this situation, the only other fix that I can think of would be to preallocate the struct file and pre-open /dev/null if we're execing a set?id executable, and then jam this into the descriptor table if it turns out to be needed. Barf! I'm not sure why fdcheckstd() and setugidsafety() couldn't both happen before grabbing the proc lock. Dropping locks in the middle or pre-allocating should always be a last resort. -Nate To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-current in the body of the message
Re: Locking problems in exec
On 10 Sep, Nate Lawson wrote: I'm not sure why fdcheckstd() and setugidsafety() couldn't both happen before grabbing the proc lock. Dropping locks in the middle or pre-allocating should always be a last resort. That is ok as long as there aren't other threads that can mess things up after fdcheckstd() and setugidsafety() have done their thing. To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-current in the body of the message
uudecode troubles in sharte/tabset.
uudecode compiles again, but now I'm getting this making world: === share/tabset uudecode /usr/src/share/tabset/3101.uu uudecode /usr/src/share/tabset/9837.uu uudecode: stdin: 9837: character out of range: [33-96] *** Error code 1 Stop in /usr/src/share/tabset. Dunno whether the problem is uudecode or tabset. To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-current in the body of the message
i386 tinderbox failure
-- Rebuilding the temporary build tree -- stage 1: bootstrap tools -- stage 2: cleaning up the object tree -- stage 2: rebuilding the object tree -- stage 2: build tools -- stage 3: cross tools -- stage 4: populating /home/des/tinderbox/i386/obj/local0/scratch/des/src/i386/usr/include -- stage 4: building libraries -- stage 4: make dependencies -- stage 4: building everything.. -- === share/tabset uudecode: stdin: 9837: character out of range: [33-96] *** Error code 1 Stop in /local0/scratch/des/src/share/tabset. *** Error code 1 Stop in /local0/scratch/des/src/share. *** Error code 1 Stop in /local0/scratch/des/src. *** Error code 1 Stop in /local0/scratch/des/src. *** Error code 1 Stop in /local0/scratch/des/src. To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-current in the body of the message
Re: uudecode troubles in sharte/tabset.
walt [EMAIL PROTECTED] writes: uudecode compiles again, but now I'm getting this making world: === share/tabset uudecode /usr/src/share/tabset/3101.uu uudecode /usr/src/share/tabset/9837.uu uudecode: stdin: 9837: character out of range: [33-96] *** Error code 1 Stop in /usr/src/share/tabset. Dunno whether the problem is uudecode or tabset. Just fixed it. Update your sources. Best regards, Mike Barcroft To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-current in the body of the message
Re: Locking problems in exec
On 10 Sep, Don Lewis wrote:
On 10 Sep, Nate Lawson wrote:
I'm not sure why fdcheckstd() and setugidsafety() couldn't both happen
before grabbing the proc lock. Dropping locks in the middle or
pre-allocating should always be a last resort.
That is ok as long as there aren't other threads that can mess things up
after fdcheckstd() and setugidsafety() have done their thing.
It looks like threads aren't a problem because of the call to
thread_single() at the top of execve(). Ptrace() is still a potential
problem, so we can't call fdcheckstd() and setugidsafety() until after
credential_changing has been calculated, setsugid() has been called and
tracing has been disabled, all of which are done after proc lock has
been grabbed.
It also looks like we should pre-allocate newprocsig instead of
temporarily dropping the lock.
Index: kern_exec.c
===
RCS file: /home/ncvs/src/sys/kern/kern_exec.c,v
retrieving revision 1.189
diff -u -r1.189 kern_exec.c
--- kern_exec.c 5 Sep 2002 07:30:14 - 1.189
+++ kern_exec.c 11 Sep 2002 05:23:25 -
@@ -141,7 +141,7 @@
struct vattr attr;
int (*img_first)(struct image_params *);
struct pargs *oldargs = NULL, *newargs = NULL;
- struct procsig *oldprocsig, *newprocsig;
+ struct procsig *oldprocsig, *newprocsig = NULL;
#ifdef KTRACE
struct vnode *tracevp = NULL;
#endif
@@ -352,6 +352,8 @@
i = imgp-endargs - imgp-stringbase;
if (ps_arg_cache_limit = i + sizeof(struct pargs))
newargs = pargs_alloc(i);
+ MALLOC(newprocsig, struct procsig *, sizeof(struct procsig), M_SUBPROC,
+ M_WAITOK);
/* close files on exec */
fdcloseexec(td);
@@ -369,14 +371,11 @@
mp_fixme(procsig needs a lock);
if (p-p_procsig-ps_refcnt 1) {
oldprocsig = p-p_procsig;
- PROC_UNLOCK(p);
- MALLOC(newprocsig, struct procsig *, sizeof(struct procsig),
- M_SUBPROC, M_WAITOK);
bcopy(oldprocsig, newprocsig, sizeof(*newprocsig));
newprocsig-ps_refcnt = 1;
oldprocsig-ps_refcnt--;
- PROC_LOCK(p);
p-p_procsig = newprocsig;
+ newprocsig = NULL;
if (p-p_sigacts == p-p_uarea-u_sigacts)
panic(shared procsig but private sigacts?);
@@ -437,8 +436,15 @@
#endif
/* Close any file descriptors 0..2 that reference procfs */
setugidsafety(td);
- /* Make sure file descriptors 0..2 are in use. */
+ /*
+* Make sure file descriptors 0..2 are in use.
+*
+* fdcheckstd() may call falloc() which may block to
+* allocate memory, so temporarily drop the process lock.
+*/
+ PROC_UNLOCK(p);
error = fdcheckstd(td);
+ PROC_LOCK(p);
if (error != 0)
goto done1;
/*
@@ -538,6 +544,8 @@
crfree(oldcred);
else
crfree(newcred);
+ if (newprocsig != NULL)
+ free(newprocsig, M_SUBPROC);
/*
* Handle deferred decrement of ref counts.
*/
To Unsubscribe: send mail to [EMAIL PROTECTED]
with unsubscribe freebsd-current in the body of the message
