Re: Multiple NFS server problems with Solaris 8 clients
On Wed, 24 Oct 2001, Paul van der Zwan wrote: > I have looked at a trace I made using snoop and it shows an NFS_ACL call which > is not supported by FreeBSD. It should have sent a reply that it does not > know the NFS_ACL protocol but apparently it does not. > The only return traffic I see is an empty packet with the tcp ACK. > It looks like an implementation error in the -current NFS server. > > Paul I have been digging at traces of 4.4-RELEASE (which works) and -current (which doesn't). Both versions get it wrong. I have no idea why 4.4-RELEASE worked. -current responds with a blank TCP packet (which it emphatically should *not* do) to the GETACL3 call. It *could* conceivably be received as an RPC packet with the "Last Fragment" flag not set and a length of 0. Who knows what the Solaris 8 client is doing when it encounters this (probably getting stuck waiting for more data which never comes). 4.4-RELEASE responds with an RPC packet indicating "success" (which is *also* wrong if the NFS server doesn't support ACLs) and then puts what looks to be garbage in the response. However, it is a valid RPC reponse with the "Last Fragment" flag set. Presumably the Solaris client gets the message, sees the last fragment, throws away the packet as an error and continues on with life. I presume that the "correct" response is to send back an RPC reply (with the "Last Fragment" set) which indicates that the RPC message was accepted but that the procedure was unavailable (PROC_UNAVAIL). Hopefully this matches what an older Solaris server would do when faced with a Solaris 8 client and everything will proceed normally from there. If anybody wants ethereal traces, I can send them. Just ask. Andy L. To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
Re: NgSendMsg may return bad token number
Harti Brandt writes: > NgSendMsg returns the bad token number if the debugging level is higher > than 2. It should use the token number from the message structure instead > of the global gMsgId, because that is changed by the ASCII messages sent > in _NgDebugMsg. The following patch fixes the problem for NgSendMsg: Thanks! I've checked in your fix (plus the same fix for NgSendAsciiMsg()) and will MFC in a few days. -Archie __ Archie Cobbs * Packet Design * http://www.packetdesign.com To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
Re: depend problem on new -current
On Wed, 24 Oct 2001 17:01:44 -0800, Beech Rintoul <[EMAIL PROTECTED]> said: > On building today's -current it errors on mkdep. > /usr/src/lib/libc_r/arch/i386/_atomic_lock.s:28: DEFS.h: no such > file or directory > I cvsupped a couple hours later, still no DEFS.h Peter just patched it. Should be there shortly. -- Michael D. Harnois bilocational bivocational Pastor, Redeemer Lutheran ChurchWashburn, Iowa 1L, UST School of Law Minneapolis, Minnesota The opposite of a correct statement is a false statement. The opposite of a profound truth may well be another profound truth. -- Niels Bohr To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
depend problem on new -current
On building today's -current it errors on mkdep. /usr/src/lib/libc_r/arch/i386/_atomic_lock.s:28: DEFS.h: no such file or directory I cvsupped a couple hours later, still no DEFS.h Beech -- Micro$oft: "Where can we make you go today?" --- Beech Rintoul - IT Manager - Instructor - [EMAIL PROTECTED] /"\ ASCII Ribbon Campaign | Anchorage Gospel Rescue Mission \ / - NO HTML/RTF in e-mail | P.O. Box 230510 X - NO Word docs in e-mail | Anchorage, AK 99523-0510 / \ - To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
Re: RELENG_4 builds on -current
In message <[EMAIL PROTECTED]> Kris Kennaway writes: : On Mon, Oct 22, 2001 at 11:58:23AM +1000, Harry Starr wrote: : > It seems to be nigh impossible to build a "previous" release on -current. : >=20 : > Problems include "incomplete" cross tool building, header files, and of : > course, device support, in particular differences : > between the "old" vn stuff, and the new "md" device. : : I build worlds in a jail populated with the target release so there's : no problems with this. At timing solutions, we build all our products in a chroot jail. We do this because each one of them has slightly different subsetting of, say, X for the embedded environment, different ports (sometimes different versions due to product history), etc. It works well, but the code is too gross to see the light of day... We don't build RELEASES in the chroot. We build a system (make world DESTDIR=xxx outside of the chroot) that we then use to build the system (inside the chroot). Warner To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
Re: panic: vrele: missed vn_close
>Date: Wed, 24 Oct 2001 15:12:52 -0500
>From: Jonathan Lemon <[EMAIL PROTECTED]>
>> I suspect that this is the problem with the devfs/console code.
>Ugh. Probably. The console code tries to remember what flag was
>used from the open, but doesn't use that flag during close.
>Here's an (untested) patch - essentially it forces the FWRITE flag
>always on, to avoid this problem. Possibly the right thing to do
>is to used a fixed set of flags to open the console, and completely
>ignore the user's specified mode.
OK; that patch seems to have needed a small tweak -- using FWRITE
implies that it's defined, so I need to include sys/fcntl.h; cvs diff
follows my uname ouput:
FreeBSD m147.whistle.com 5.0-CURRENT FreeBSD 5.0-CURRENT #146: Wed Oct 24 14:28:45 PDT
2001 [EMAIL PROTECTED]:/common/C/obj/usr/src/sys/LAPTOP_30W i386
Index: sys/kern/tty_cons.c
===
RCS file: /cvs/freebsd/src/sys/kern/tty_cons.c,v
retrieving revision 1.93
diff -u -r1.93 tty_cons.c
--- sys/kern/tty_cons.c 23 Oct 2001 20:25:50 - 1.93
+++ sys/kern/tty_cons.c 24 Oct 2001 21:19:23 -
@@ -41,6 +41,7 @@
#include
#include
+#include
#include
#include
#include
@@ -365,7 +366,7 @@
{
struct cn_device *cnd;
- openflag = flag;
+ openflag = flag | FWRITE; /* XXX */
cn_is_open = 1; /* console is logically open */
if (cn_mute)
return (0);
@@ -382,7 +383,7 @@
STAILQ_FOREACH(cnd, &cn_devlist, cnd_next) {
if (cnd->cnd_vp == NULL)
continue;
- vn_close(cnd->cnd_vp, mode, td->td_proc->p_ucred, td);
+ vn_close(cnd->cnd_vp, openflag, td->td_proc->p_ucred, td);
cnd->cnd_vp = NULL;
}
cn_is_open = 0;
Anyway, I'm up & running multi-user on today's -CURRENT. I wouldn't
take this as proof that the patch is correct, but it's a definite
improvement in behavior :-)
Thanks,
david
--
David H. Wolfskill [EMAIL PROTECTED]
As a computing professional, I believe it would be unethical for me to
advise, recommend, or support the use (save possibly for personal
amusement) of any product that is or depends on any Microsoft product.
To Unsubscribe: send mail to [EMAIL PROTECTED]
with "unsubscribe freebsd-current" in the body of the message
Re: latest patch? (fwd)
This seemed to fix things for me.
-- Forwarded message --
Date: Wed, 24 Oct 2001 14:21:59 -0700 (PDT)
From: Matthew Jacob <[EMAIL PROTECTED]>
To: Jonathan Lemon <[EMAIL PROTECTED]>
Subject: Re: latest patch?
I sure saw it on an XP1000.
Index: tty_cons.c
===
RCS file: /home/ncvs/src/sys/kern/tty_cons.c,v
retrieving revision 1.93
diff -u -r1.93 tty_cons.c
--- tty_cons.c 2001/10/23 20:25:50 1.93
+++ tty_cons.c 2001/10/24 21:06:19
@@ -53,6 +53,7 @@
#include
#include
#include
+#include
#include
@@ -230,6 +231,8 @@
}
}
+void cndebug(char *);
+
void
cndebug(char *str)
{
@@ -365,7 +368,7 @@
{
struct cn_device *cnd;
- openflag = flag;
+ openflag = flag | FWRITE; /* XXX on the FWRITE */
cn_is_open = 1; /* console is logically open */
if (cn_mute)
return (0);
@@ -382,7 +385,7 @@
STAILQ_FOREACH(cnd, &cn_devlist, cnd_next) {
if (cnd->cnd_vp == NULL)
continue;
- vn_close(cnd->cnd_vp, mode, td->td_proc->p_ucred, td);
+ vn_close(cnd->cnd_vp, openflag, td->td_proc->p_ucred, td);
cnd->cnd_vp = NULL;
}
cn_is_open = 0;
To Unsubscribe: send mail to [EMAIL PROTECTED]
with "unsubscribe freebsd-current" in the body of the message
Re: Test tweak for F00F bug..
On 24-Oct-01 Julian Elischer wrote: > have you tested the foof bug itself? cjc did. The change has already been committed. > On Wed, 24 Oct 2001, Giorgos Keramidas wrote: > >> On Tue, Oct 23, 2001 at 10:57:18AM -0700, John Baldwin wrote: >> > Anyone running -current on a true Pentium with the F00F bug that can >> > verify >> > that this simple cleanup patch works? >> > >> > http://www.freebsd.org/~jhb/patches/f00f.patch >> >> I can. Running it on p5/133 right now. >> >> CPU: Pentium/P54C (132.63-MHz 586-class CPU) >> Origin = "GenuineIntel" Id = 0x52c Stepping = 12 >> Features=0x1bf >> ... >> Intel Pentium detected, installing workaround for F00F bug >> >> Building world, now. Just give me another 8-10 hours to let my >> buildworld/installworld finish normally. >> >> Apart from crafting my own gas(1) test to make sure this works, >> anything particular I should look more carefully for? >> >> -giorgos >> >> To Unsubscribe: send mail to [EMAIL PROTECTED] >> with "unsubscribe freebsd-current" in the body of the message >> > -- John Baldwin <[EMAIL PROTECTED]> -- http://www.FreeBSD.org/~jhb/ PGP Key: http://www.baldwin.cx/~john/pgpkey.asc "Power Users Use the Power to Serve!" - http://www.FreeBSD.org/ To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
Re: panic: vrele: missed vn_close
On Wed, 24 Oct 2001, Jonathan Lemon wrote: > Hmm. The way the revamped console code works is this: > > cn_devopen() calls vn_open() to open the device. If this is not a > VCHR device, then it is closed. Otherwise, the vnode is stashed in > cnd->cnd_vp. > > When the device is closed though cnclose(), it walks through a list > of console devices, and if cnd_vp != NULL, calls vn_close() for that > vnode, and then NULLs out cnd_vp. (drops the reference.) > > My understanding is that vn_open/vn_close will track the count of > outstanding references to the vnode, so this should be safe to do. The reference counts were inadequate for handling controlling terminals in the old version. I don't see how this can work now. You do extra opens. This will prevent controlling ttys going away properly. E.g., suppose sio0 is a console device and is completely closed. The following sequence of operations should leave it a non-controlling tty: sio0's ref count open sio0 1 make sio0 a ctty2 open cn 3 close sio0 2 lose sio0 as a ctty 1 sioclose() will not be called here since the reference count is > 0, so ctty-related stuff in its tty struct will not be cleared, and things break. Similarly with sio0 and cn reversed. The old code had kludges to handle one of these cases. I had fixes for the other one. These are now invalid (sigh). I didn't commit them because there seemed to be a lot of races nearby. Perhaps the panic is caused a race. The races are related to stashing of pointers related to controlling terminals. The lifetime of these pointers is unclear. Bruce To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
Re: panic: vrele: missed vn_close
On Wed, Oct 24, 2001 at 11:59:52AM -0700, Matthew Dillon wrote:
>
> :
> :Hmm. The way the revamped console code works is this:
> :
> : cn_devopen() calls vn_open() to open the device. If this is not a
> :VCHR device, then it is closed. Otherwise, the vnode is stashed in
> :cnd->cnd_vp.
> :
> : When the device is closed though cnclose(), it walks through a list
> :of console devices, and if cnd_vp != NULL, calls vn_close() for that
> :vnode, and then NULLs out cnd_vp. (drops the reference.)
> :
> : My understanding is that vn_open/vn_close will track the count of
> :outstanding references to the vnode, so this should be safe to do.
> :--
> :Jonathan
>
> The panic is due to v_writecount not being properly adjusted. If a
> vnode is opened with FWRITE in vn_open(), then it must be closed with
> VWRITE in vn_close() or v_writecount will not be properly adjusted and cause
> the panic in question to occur later in vrele().
>
> I suspect that this is the problem with the devfs/console code.
Ugh. Probably. The console code tries to remember what flag was
used from the open, but doesn't use that flag during close.
Here's an (untested) patch - essentially it forces the FWRITE flag
always on, to avoid this problem. Possibly the right thing to do
is to used a fixed set of flags to open the console, and completely
ignore the user's specified mode.
--
Jonathan
Index: tty_cons.c
===
RCS file: /ncvs/src/sys/kern/tty_cons.c,v
retrieving revision 1.93
diff -u -r1.93 tty_cons.c
--- tty_cons.c 2001/10/23 20:25:50 1.93
+++ tty_cons.c 2001/10/24 19:36:25
@@ -365,7 +365,7 @@
{
struct cn_device *cnd;
- openflag = flag;
+ openflag = flag | FWRITE; /* XXX */
cn_is_open = 1; /* console is logically open */
if (cn_mute)
return (0);
@@ -382,7 +382,7 @@
STAILQ_FOREACH(cnd, &cn_devlist, cnd_next) {
if (cnd->cnd_vp == NULL)
continue;
- vn_close(cnd->cnd_vp, mode, td->td_proc->p_ucred, td);
+ vn_close(cnd->cnd_vp, openflag, td->td_proc->p_ucred, td);
cnd->cnd_vp = NULL;
}
cn_is_open = 0;
To Unsubscribe: send mail to [EMAIL PROTECTED]
with "unsubscribe freebsd-current" in the body of the message
Re: panic: vrele: missed vn_close
* Matthew Dillon <[EMAIL PROTECTED]> [011024 13:28] wrote:
>
> :I got a panic on -current which is updated 3 hours before.
> :
> :...
> :Additional TCP options:.
> :Starting background filesystem checks
> :
> :Wed Oct 24 20:28:15 JST 2001
> :panic: vrele: missed vn_close
> :Debugger("panic")
> :Sttopped at Debugger+0x44: pushl%ebx
> :db> trace
> :Debugger()
> :panic()
> :vrele()
> :vn_close()
> :cnclose()
> :spec_close()
> :...
> :
> :Is there a possibility this panic caused by this commit?
> :
> :At Mon, 22 Oct 2001 18:21:29 -0700 (PDT),
> :Matt Dillon wrote:
> :> Log:
> :> Change the vnode list under the mount point from a LIST to a TAILQ
> :> in preparation for an implementation of limiting code for kern.maxvnodes.
> :
> :
> :--
> :Jun Kuriyama <[EMAIL PROTECTED]> // IMG SRC, Inc.
> : <[EMAIL PROTECTED]> // FreeBSD Project
>
> Someone else is going to have to look at the devfs/cnclose code. I found one
> minor error in fhopen() which I will correct, but I don't think anyone is using
> fhopen().
fhopen is used by userland NFS/AFS servers/utilities.
--
-Alfred Perlstein [[EMAIL PROTECTED]]
'Instead of asking why a piece of software is using "1970s technology,"
start asking why software is ignoring 30 years of accumulated wisdom.'
http://www.morons.org/rants/gpl-harmful.php3
To Unsubscribe: send mail to [EMAIL PROTECTED]
with "unsubscribe freebsd-current" in the body of the message
Re: panic: vrele: missed vn_close
(I meant must be closed with FWRITE, not VWRITE. There is no VWRITE). -Matt To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
Re: panic: vrele: missed vn_close
: :Hmm. The way the revamped console code works is this: : : cn_devopen() calls vn_open() to open the device. If this is not a :VCHR device, then it is closed. Otherwise, the vnode is stashed in :cnd->cnd_vp. : : When the device is closed though cnclose(), it walks through a list :of console devices, and if cnd_vp != NULL, calls vn_close() for that :vnode, and then NULLs out cnd_vp. (drops the reference.) : : My understanding is that vn_open/vn_close will track the count of :outstanding references to the vnode, so this should be safe to do. :-- :Jonathan The panic is due to v_writecount not being properly adjusted. If a vnode is opened with FWRITE in vn_open(), then it must be closed with VWRITE in vn_close() or v_writecount will not be properly adjusted and cause the panic in question to occur later in vrele(). I suspect that this is the problem with the devfs/console code. -Matt To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
Re: panic: vrele: missed vn_close
Hmm. The way the revamped console code works is this: cn_devopen() calls vn_open() to open the device. If this is not a VCHR device, then it is closed. Otherwise, the vnode is stashed in cnd->cnd_vp. When the device is closed though cnclose(), it walks through a list of console devices, and if cnd_vp != NULL, calls vn_close() for that vnode, and then NULLs out cnd_vp. (drops the reference.) My understanding is that vn_open/vn_close will track the count of outstanding references to the vnode, so this should be safe to do. -- Jonathan On Wed, Oct 24, 2001 at 11:38:12AM -0700, Matthew Dillon wrote: > > :... > :Sttopped at Debugger+0x44: pushl%ebx > :db> trace > :Debugger() > :panic() > :vrele() > :vn_close() > :cnclose() > :spec_close() > :spec_vnoperate() > :vclean() > :vgonel() > :vgone() > :vop_revoke() > :devfs_revoke() > :exit1() > :... > > In looking at a diff in the last few days, a huge number of changes have been > made kern/tty_cons.c by jlemon. Since the area of the panic is around the same > block of code there's a good chance that these changes are the cause, though I > have not tested this. If so, Jonathan can locate the bug much more quickly then > I can. > > -Matt To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
Re: panic: vrele: missed vn_close
:... :Sttopped at Debugger+0x44: pushl%ebx :db> trace :Debugger() :panic() :vrele() :vn_close() :cnclose() :spec_close() :spec_vnoperate() :vclean() :vgonel() :vgone() :vop_revoke() :devfs_revoke() :exit1() :... In looking at a diff in the last few days, a huge number of changes have been made kern/tty_cons.c by jlemon. Since the area of the panic is around the same block of code there's a good chance that these changes are the cause, though I have not tested this. If so, Jonathan can locate the bug much more quickly then I can. -Matt To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
Re: Test tweak for F00F bug..
have you tested the foof bug itself? On Wed, 24 Oct 2001, Giorgos Keramidas wrote: > On Tue, Oct 23, 2001 at 10:57:18AM -0700, John Baldwin wrote: > > Anyone running -current on a true Pentium with the F00F bug that can verify > > that this simple cleanup patch works? > > > > http://www.freebsd.org/~jhb/patches/f00f.patch > > I can. Running it on p5/133 right now. > > CPU: Pentium/P54C (132.63-MHz 586-class CPU) > Origin = "GenuineIntel" Id = 0x52c Stepping = 12 > Features=0x1bf > ... > Intel Pentium detected, installing workaround for F00F bug > > Building world, now. Just give me another 8-10 hours to let my > buildworld/installworld finish normally. > > Apart from crafting my own gas(1) test to make sure this works, > anything particular I should look more carefully for? > > -giorgos > > 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: panic: vrele: missed vn_close
:I got a panic on -current which is updated 3 hours before.
:
:...
:Additional TCP options:.
:Starting background filesystem checks
:
:Wed Oct 24 20:28:15 JST 2001
:panic: vrele: missed vn_close
:Debugger("panic")
:Sttopped at Debugger+0x44: pushl%ebx
:db> trace
:Debugger()
:panic()
:vrele()
:vn_close()
:cnclose()
:spec_close()
:...
:
:Is there a possibility this panic caused by this commit?
:
:At Mon, 22 Oct 2001 18:21:29 -0700 (PDT),
:Matt Dillon wrote:
:> Log:
:> Change the vnode list under the mount point from a LIST to a TAILQ
:> in preparation for an implementation of limiting code for kern.maxvnodes.
:
:
:--
:Jun Kuriyama <[EMAIL PROTECTED]> // IMG SRC, Inc.
: <[EMAIL PROTECTED]> // FreeBSD Project
Someone else is going to have to look at the devfs/cnclose code. I found one
minor error in fhopen() which I will correct, but I don't think anyone is using
fhopen().
-Matt
To Unsubscribe: send mail to [EMAIL PROTECTED]
with "unsubscribe freebsd-current" in the body of the message
Re: panic: vrele: missed vn_close
:
:I got a panic on -current which is updated 3 hours before.
How old was your kernel prior to the update?
:Additional TCP options:.
:Starting background filesystem checks
:
:Wed Oct 24 20:28:15 JST 2001
:panic: vrele: missed vn_close
:Debugger("panic")
:Sttopped at Debugger+0x44: pushl%ebx
:db> trace
:Debugger()
:panic()
:vrele()
:vn_close()
:cnclose()
:spec_close()
:spec_vnoperate()
:vclean()
:vgonel()
:vgone()
:vop_revoke()
:devfs_revoke()
:exit1()
:sys_exit()
:syscall(2f,2f,2f,0,0)
:syscall_with_err_pushed()
:--- syscall (1, FreeBSD ELF, sys_exit) ---
:
:
:Is there a possibility this panic caused by this commit?
:
:At Mon, 22 Oct 2001 18:21:29 -0700 (PDT),
:Matt Dillon wrote:
:> Log:
:> Change the vnode list under the mount point from a LIST to a TAILQ
:> in preparation for an implementation of limiting code for kern.maxvnodes.
:
:--
:Jun Kuriyama <[EMAIL PROTECTED]> // IMG SRC, Inc.
It seems unlikely.
-Matt
To Unsubscribe: send mail to [EMAIL PROTECTED]
with "unsubscribe freebsd-current" in the body of the message
Re: Multiple NFS server problems with Solaris 8 clients
In message <[EMAIL PROTECTED]>, Thomas Quinot wrote: >Le 2001-10-14, Paul van der Zwan écrivait : > >> I am using -current box as a homedir server for my Solaris clients and >> have noticed a wierd problem. > >Other problems here, with Solaris 2.[68] as clients, and -CURRENT of >yesterday as server. ls works, but ls -l issues a 'NFS getacl failed' >message *and* waits for a timeout once for each file in the directory. > >The server is not multi-homed, and a packet capture shows no trace of >address mismatch problems. One interesting thing is that the client >first does GETATTR on the file (and apparently gets a reply), and >then sends some other RPC, to which the server never replies. >Could this be the getacl request mentioned in the client error message? >I see no mention of getacl whatsoever in the -CURRENT server code. If >no such function is implemented, shouldn't we reject the request? > >A packet capture is available at > http://www.infres.enst.fr/~quinot/nfs.cap > >Client is 137.194.192.1, server is 137.194.162.11. The test consists >in first performing an 'ls' on one file, then an 'ls -l' on the same >file. Result: > >ls photos-ta; ls -l photos-ta >photos-ta >NFS getacl failed for server shalmaneser.enst.fr: error 5 (RPC: Timed >out) >-rw--- 1 quinot astre474 Oct 18 14:17 photos-ta I have looked at a trace I made using snoop and it shows an NFS_ACL call which is not supported by FreeBSD. It should have sent a reply that it does not know the NFS_ACL protocol but apparently it does not. The only return traffic I see is an empty packet with the tcp ACK. It looks like an implementation error in the -current NFS server. Paul -- Paul van der Zwan paulz @ trantor.xs4all.nl "I think I'll move to theory, everything works in theory..." To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
Re: [acpi-jp 1363] Re: ACPI: problem with fdc resource allocation
Mitsuru IWASAKI wrote:
>
> Hi, Maxim. Thanks for reporting and reminding us.
>
> I think this is very difficult to fix, because;
> 1. Basically, this is a bug in BIOS, should be reported to vendor.
I understood that, but it is a discontinued model, so it is
unlikely that they will bother to provide updated BIOS just
to satisfy those strange that want to run FreeBSD on it. :((
> 2. ACPI CA is developed by Intel. We'd like to have less local
> workaround changes as possible.
Ok, I see.
> 3. I'm not sure whether suggested patches (buffer size dynamicaly expanding)
> in [acpi-jp 1315] is correct fix, maybe not. Probably another approach
> can be considered (e.g. just ignore AE_AML_BUFFER_LIMIT and continue
> interpreter execution).
>
> I'll describe again the problem. This method is like this;
> Method(_CRS) {
> Name(BUF0, Buffer(0x18) {0x47, 0x1, 0xf2, 0x3, 0xf2, 0x3,
>0x0, 0x4, 0x47, 0x1, 0xf7, 0x3, 0xf7, 0x3, 0x0,
>0x1, 0x22, 0x40, 0x0, 0x2a, 0x4, 0x0, 0x79, 0x0 })
> CreateByteField(BUF0, 0x2, IOLO)
> CreateByteField(BUF0, 0x3, IOHI)
> CreateByteField(BUF0, 0x4, IORL)
> CreateByteField(BUF0, 0x5, IORH)
> CreateByteField(BUF0, 0x19, IRQL)
> CreateByteField(BUF0, 0x1c, DMAV)
> Return(BUF0)
> }
>
> The problem is that this AML is trying to create a field at exceeded
> position (0x19) of the Buffer (size is 0x18).
> And strangely, this method just return the buffer w/o any changes
> after CreateByteField operations. I guess that BIOS writer forgotten to
> delete CreateByteField statements, or change the buffer size.
>
> Now that we have DSDT override patches;
> http://home.jp.freebsd.org/cgi-bin/showmail/acpi-jp/1347
> or
> http://home.jp.freebsd.org/cgi-bin/showmail/acpi-jp/1349
>
> and AML disassembler (acpidump), and ASL compiler (iasl) in
> ports/devel/acpicatools/.
>
> Maxim, could you apply the following patches and try DSDT overriding?
Looks like a way to go. I'll test them tomorrow and let you
know then.
Big thanks!
-Maxim
To Unsubscribe: send mail to [EMAIL PROTECTED]
with "unsubscribe freebsd-current" in the body of the message
Re: -CURRENT freeze under high load
On 24-Oct-01 NAKAJI Hiroyuki wrote: >> In <[EMAIL PROTECTED]> >> [EMAIL PROTECTED] (Andrea Campi) wrote: > > AC> Anybody seen anything like this? > > Well, it may not be the case, but I have similar problem. > > In my case, just after login via xdm installed from > port/x11/XFree86-4, load average gets very much increased up to about > 4.0 and the mouse cannot work smoothly. It occurs when uptime becomes > one day or more. > > Fortunately, my system never freeze or hangup. I would try removing apm from your kernel config or disabling ACPI and only using one or the other and seeing if that helps. -- John Baldwin <[EMAIL PROTECTED]> -- http://www.FreeBSD.org/~jhb/ PGP Key: http://www.baldwin.cx/~john/pgpkey.asc "Power Users Use the Power to Serve!" - http://www.FreeBSD.org/ To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
Re: -CURRENT freeze under high load
> In <[EMAIL PROTECTED]> > [EMAIL PROTECTED] (Andrea Campi) wrote: AC> Anybody seen anything like this? Well, it may not be the case, but I have similar problem. In my case, just after login via xdm installed from port/x11/XFree86-4, load average gets very much increased up to about 4.0 and the mouse cannot work smoothly. It occurs when uptime becomes one day or more. Fortunately, my system never freeze or hangup. Here is dmesg. Mainboard is ASUS P3V4X and CPU is P3 933MHz with ASUS S370-??. Copyright (c) 1992-2001 The FreeBSD Project. Copyright (c) 1979, 1980, 1983, 1986, 1988, 1989, 1991, 1992, 1993, 1994 The Regents of the University of California. All rights reserved. FreeBSD 5.0-CURRENT #35: Wed Oct 17 15:51:39 JST 2001 [EMAIL PROTECTED]:/usr/obj/usr/src/sys/NAKAJI Timecounter "i8254" frequency 1193182 Hz CPU: Pentium III/Pentium III Xeon/Celeron (936.75-MHz 686-class CPU) Origin = "GenuineIntel" Id = 0x686 Stepping = 6 Features=0x383f9ff real memory = 671072256 (655344K bytes) avail memory = 647983104 (632796K bytes) Preloaded elf kernel "/boot/kernel/kernel" at 0xc0471000. Preloaded elf module "/boot/kernel/acpi.ko" at 0xc04710b4. Pentium Pro MTRR support enabled Using $PIR table, 8 entries at 0xc00f0e60 apm0: on motherboard apm0: found APM BIOS v1.2, connected at v1.2 npx0: on motherboard npx0: INT 16 interface acpi0: on motherboard acpi0: power button is handled as a fixed feature programming model. acpi_button0: on acpi0 fdc0: port 0x3f7,0x3f2-0x3f5 irq 6 on acpi0 fdc0: FIFO enabled, 8 bytes threshold fd0: <1440-KB 3.5" drive> on fdc0 drive 0 ppc0 port 0x778-0x77b,0x378-0x37f irq 7 on acpi0 ppc0: SMC-like chipset (ECP/EPP/PS2/NIBBLE) in COMPATIBLE mode ppc0: FIFO with 16/16/9 bytes threshold ppbus0: IEEE1284 device found /NIBBLE/ECP/ECP_RLE Probing for PnP devices on ppbus0: ppbus0: PRINTER POSTSCRIPT plip0: on ppbus0 lpt0: on ppbus0 lpt0: Interrupt-driven port ppi0: on ppbus0 sio0 port 0x3f8-0x3ff irq 4 on acpi0 sio0: type 16550A sio1 port 0x2f8-0x2ff irq 3 on acpi0 sio1: type 16550A atkbdc0: port 0x64,0x60 irq 1 on acpi0 atkbd0: flags 0x1 irq 1 on atkbdc0 kbd0 at atkbd0 psm0: failed to get data. psm0: irq 12 on atkbdc0 psm0: model IntelliMouse, device ID 3 pcib0: at pcibus 0 on motherboard pci0: on pcib0 pcib1: at device 1.0 on pci0 pci1: on pcib1 pci1: at device 0.0 (no driver attached) isab0: at device 4.0 on pci0 isa0: on isab0 atapci0: port 0xb800-0xb80f at device 4.1 on pci0 ata0: at 0x1f0 irq 14 on atapci0 ata1: at 0x170 irq 15 on atapci0 pci0: at device 4.2 (no driver attached) xl0: <3Com 3c905B-TX Fast Etherlink XL> port 0xb000-0xb07f mem 0xe180-0xe180007f irq 5 at device 9.0 on pci0 xl0: Ethernet address: 00:01:02:c2:15:af miibus0: on xl0 xlphy0: <3Com internal media interface> on miibus0 xlphy0: 10baseT, 10baseT-FDX, 100baseTX, 100baseTX-FDX, auto csa0: mem 0xe080-0xe08f,0xe100-0xe1000fff irq 10 at device 10.0 on pci0 csa: card is Unknown/invalid SSID (CS4614) pcm0: on csa0 ahc0: port 0xa800-0xa8ff mem 0xe000-0xefff irq 11 at device 12.0 on pci0 aic7890/91: Ultra2 Wide Channel A, SCSI Id=7, 32/255 SCBs atapci1: port 0x9000-0x90ff,0x9400-0x9403,0x9800-0x9807,0xa000-0xa003,0xa400-0xa407 irq 5 at device 13.0 on pci0 ata2: at 0xa400 on atapci1 ata3: at 0x9800 on atapci1 orm0: at iomem 0xc-0xc7fff,0xc8000-0xcd7ff on isa0 fdc1: cannot reserve I/O port range (6 ports) ppc1: cannot reserve I/O port range ppc2: cannot reserve I/O port range sc0: at flags 0x100 on isa0 sc0: VGA <16 virtual consoles, flags=0x300> vga0: at port 0x3c0-0x3df iomem 0xa-0xb on isa0 ad0: 2441MB [4960/16/63] at ata0-master WDMA2 ad1: 14655MB [29777/16/63] at ata0-slave UDMA66 ad3: 9765MB [19841/16/63] at ata1-slave UDMA33 ar0: 43979MB [5606/255/63] subdisks: ad4: 43979MB [89355/16/63] at ata2-master UDMA100 ad6: 43979MB [89355/16/63] at ata3-master UDMA100 ar1: 43979MB [5606/255/63] subdisks: ad4: 43979MB [89355/16/63] at ata2-master UDMA100 ad6: 43979MB [89355/16/63] at ata3-master UDMA100 ar2: 43979MB [5606/255/63] subdisks: ad4: 43979MB [89355/16/63] at ata2-master UDMA100 ad6: 43979MB [89355/16/63] at ata3-master UDMA100 ar3: 43979MB [5606/255/63] subdisks: ad4: 43979MB [89355/16/63] at ata2-master UDMA100 ad6: 43979MB [89355/16/63] at ata3-master UDMA100 ar4: 43979MB [5606/255/63] subdisks: ad4: 43979MB [89355/16/63] at ata2-master UDMA100 ad6: 43979MB [89355/16/63] at ata3-master UDMA100 ar5: 43979MB [5606/255/63] subdisks: ad4: 43979MB [89355/16/63] at ata2-master UDMA100 ad6: 43979MB [89355/16/63] at ata3-master UDMA100 ar6: 43979MB [5606/255/63] subdisks: ad4: 43979MB [89355/16/63] at ata2-master UDMA100 ad6: 43979MB [89355/16/63] at ata3-master UDMA100 ar7: 43979MB [5606/255/63] subdisks: ad4: 43979MB [89355/16/63] at ata2-master UDMA100 ad6: 43979MB [89355/16/63] at ata3-master UDMA100 acd0: CDROM at ata1-master PIO3 Waiting
-CURRENT freeze under high load
Hi all, I am trying to diagnose a problem I've been having for a few weeks (I didn't report it earlier because I didn't have much time to hunt for it). The symptom is a total system freeze, i.e. I can't get into DDB. I can repeat it only with qmail, but of course I don't think it's qmail specific in any way; probably something to do with locking. To reproduce it I run: find . -type f | xargs mutt (on my machine, all emails get delivered to me) A kernel from Oct 1 doesn't have this issue; a kernel from Oct 5 has. I'll start binary searching for a commit I can blame. Anybody seen anything like this? Bye, Andrea To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
Re: jdk 1.1.8 on -current?
On Tue, Oct 23, 2001 at 10:16:09AM +0200, Martin Dieringer wrote: > Hi, > after updating -current many programs seem to be incompatible. > after recompiling they work, though. > jdk1.1.8 has the same problem, but I can't recompile this... > the error is: > /usr/libexec/ld-elf.so.1: /usr/lib/libm.so.2: Undefined symbol "__stderrp" > > the package on current.freebsd.org doesn't work. > Is there a version for current -current? Do you have the compat3 libraries installed? -- Greg LewisEmail : [EMAIL PROTECTED] Eyes Beyond Phone : (801) 765 1887 Information TechnologyWeb : http://www.eyesbeyond.com To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
Re: [acpi-jp 1363] Re: ACPI: problem with fdc resource allocation
Hi, Maxim. Thanks for reporting and reminding us.
I think this is very difficult to fix, because;
1. Basically, this is a bug in BIOS, should be reported to vendor.
2. ACPI CA is developed by Intel. We'd like to have less local
workaround changes as possible.
3. I'm not sure whether suggested patches (buffer size dynamicaly expanding)
in [acpi-jp 1315] is correct fix, maybe not. Probably another approach
can be considered (e.g. just ignore AE_AML_BUFFER_LIMIT and continue
interpreter execution).
I'll describe again the problem. This method is like this;
Method(_CRS) {
Name(BUF0, Buffer(0x18) {0x47, 0x1, 0xf2, 0x3, 0xf2, 0x3,
0x0, 0x4, 0x47, 0x1, 0xf7, 0x3, 0xf7, 0x3, 0x0,
0x1, 0x22, 0x40, 0x0, 0x2a, 0x4, 0x0, 0x79, 0x0 })
CreateByteField(BUF0, 0x2, IOLO)
CreateByteField(BUF0, 0x3, IOHI)
CreateByteField(BUF0, 0x4, IORL)
CreateByteField(BUF0, 0x5, IORH)
CreateByteField(BUF0, 0x19, IRQL)
CreateByteField(BUF0, 0x1c, DMAV)
Return(BUF0)
}
The problem is that this AML is trying to create a field at exceeded
position (0x19) of the Buffer (size is 0x18).
And strangely, this method just return the buffer w/o any changes
after CreateByteField operations. I guess that BIOS writer forgotten to
delete CreateByteField statements, or change the buffer size.
Now that we have DSDT override patches;
http://home.jp.freebsd.org/cgi-bin/showmail/acpi-jp/1347
or
http://home.jp.freebsd.org/cgi-bin/showmail/acpi-jp/1349
and AML disassembler (acpidump), and ASL compiler (iasl) in
ports/devel/acpicatools/.
Maxim, could you apply the following patches and try DSDT overriding?
Thanks
--- Tyan-S1590.asl.org Wed Oct 24 22:00:44 2001
+++ Tyan-S1590.asl Wed Oct 24 22:02:09 2001
@@ -884,12 +884,14 @@
}
Method(_CRS) {
Name(BUF0, Buffer(0x18) {0x47, 0x1, 0xf2, 0x3, 0xf2, 0x3, 0x0,
0x4, 0x47, 0x1, 0xf7, 0x3, 0xf7, 0x3, 0x0, 0x1, 0x22, 0x40, 0x0, 0x2a, 0x4, 0x0, 0x79,
0x0 })
+/*
CreateByteField(BUF0, 0x2, IOLO)
CreateByteField(BUF0, 0x3, IOHI)
CreateByteField(BUF0, 0x4, IORL)
CreateByteField(BUF0, 0x5, IORH)
CreateByteField(BUF0, 0x19, IRQL)
CreateByteField(BUF0, 0x1c, DMAV)
+*/
Return(BUF0)
}
Name(_PRS, Buffer(0x1a) {0x30, 0x47, 0x1, 0xf2, 0x3, 0xf2, 0x3, 0x0,
0x4, 0x47, 0x1, 0xf7, 0x3, 0xf7, 0x3, 0x0, 0x1, 0x22, 0x40, 0x0, 0x2a, 0x4, 0x0, 0x38,
0x79, 0x0 })
To Unsubscribe: send mail to [EMAIL PROTECTED]
with "unsubscribe freebsd-current" in the body of the message
panic: vrele: missed vn_close
I got a panic on -current which is updated 3 hours before.
...
Additional TCP options:.
Starting background filesystem checks
Wed Oct 24 20:28:15 JST 2001
panic: vrele: missed vn_close
Debugger("panic")
Sttopped at Debugger+0x44: pushl%ebx
db> trace
Debugger()
panic()
vrele()
vn_close()
cnclose()
spec_close()
spec_vnoperate()
vclean()
vgonel()
vgone()
vop_revoke()
devfs_revoke()
exit1()
sys_exit()
syscall(2f,2f,2f,0,0)
syscall_with_err_pushed()
--- syscall (1, FreeBSD ELF, sys_exit) ---
Is there a possibility this panic caused by this commit?
At Mon, 22 Oct 2001 18:21:29 -0700 (PDT),
Matt Dillon wrote:
> Log:
> Change the vnode list under the mount point from a LIST to a TAILQ
> in preparation for an implementation of limiting code for kern.maxvnodes.
--
Jun Kuriyama <[EMAIL PROTECTED]> // IMG SRC, Inc.
<[EMAIL PROTECTED]> // FreeBSD Project
To Unsubscribe: send mail to [EMAIL PROTECTED]
with "unsubscribe freebsd-current" in the body of the message
NgSendMsg may return bad token number
Hi all, NgSendMsg returns the bad token number if the debugging level is higher than 2. It should use the token number from the message structure instead of the global gMsgId, because that is changed by the ASCII messages sent in _NgDebugMsg. The following patch fixes the problem for NgSendMsg: Index: msg.c === RCS file: /usr/ncvs/src/lib/libnetgraph/msg.c,v retrieving revision 1.5 diff -r1.5 msg.c 84c84 < return (gMsgId); --- > return (msg.header.token); The same problem exists obviously in NgSendMsgASCII, but I have no test case for this one and hence no fix. Regards, harti -- harti brandt, http://www.fokus.gmd.de/research/cc/cats/employees/hartmut.brandt/private [EMAIL PROTECTED] To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
Re: ACPI: problem with fdc resource allocation
> > > > The problem is still here as of today's kernel. Please do > > > something about it. > > > > Should I reapeat how sad it is that this longstanding > > problem is being completely ignored by the acpi > > maintainer(s)? > > No, I'd prefer that you found something constructive to do with your time. > I'm not interested in being bitched out over something as trivial as this > when I have so much on my plate already; if you can't contribute, do me > the least favour and save me the angst. What you expect me to do "constructive" about this? I've submitted detailed report, tested some patches proposed by the Japanese ACPI developers and so on. I do not see what else I could do to get this problem resolved apart from bugging you from time to time. Perhaps you have any better ideas, then please let me know. Also if the problem is as trivial as you are describing, then it is highly unclear why it is not fixed yet (some 6 weeks are passed since initial report). I know several local guys with exactly the same bug (some time ago I've convinced some them to swith to -current and test/report any problems) and it is very sad to see my efforts vanished, especially considering that the source of the problem is located and as you said it is a "trivial" one. -Maxim To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
Re: It's baaack... -- ("make: don't know how to make copies. Stop")
> Mark, please back your 1.32 revision from share/examples/Makefile out, Done. M -- o Mark Murray \_ FreeBSD Services Limited O.\_Warning: this .sig is umop ap!sdn To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
Re: ACPI: problem with fdc resource allocation
> > The problem is still here as of today's kernel. Please do > > something about it. > > Should I reapeat how sad it is that this longstanding > problem is being completely ignored by the acpi > maintainer(s)? No, I'd prefer that you found something constructive to do with your time. I'm not interested in being bitched out over something as trivial as this when I have so much on my plate already; if you can't contribute, do me the least favour and save me the angst. Thanks. Mike -- ... every activity meets with opposition, everyone who acts has his rivals and unfortunately opponents also. But not because people want to be opponents, rather because the tasks and relationships force people to take different points of view. [Dr. Fritz Todt] V I C T O R Y N O T V E N G E A N C E To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
