Maxim Sobolev wrote:
Maxim Sobolev wrote:
Mike Smith wrote:
This just isn't going to work. The _CRS data stream stops at byte 0x17,
and these extra items are simply mis-aimed.
The 0x19 should really be 0x11, and the 0x1c should really be 0x14, ie.
this is a BIOS bug, and
On Tue, Oct 23, 2001 at 08:43:29PM +0100, Mark Murray wrote:
David Wolfskill wrote:
Found this in my typescript after a make installworld on today's
There was a commit about a problem with a missing NOOBJ..
May I suggest either:
- rm -rf /usr/obj/*
- cd src/share; cd `make -V
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
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
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
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:
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()
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:
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
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
:
: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
: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()
* 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
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
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?
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
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
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
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
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
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
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
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)
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?
:...
: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
(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
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,
:
: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
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
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
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
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
32 matches
Mail list logo
