* Tony Johnson [EMAIL PROTECTED] [000928 17:54] wrote:
I really did not want to reply to this but since some people believe that I
am just see-ing things, then I will set this straight.
No we don't Tony, we aren't claiming any stability in -current,
I'm sure people will remeber your initial
* Thomas David Rivers [EMAIL PROTECTED] [000928 03:34] wrote:
Alfred,
Just playing `devils advocate' here. But, in some initial
install situations, exactly how is the user, even the most
knowledgeable one, supposed to do much of anything if the
install itself doesn't work? Not
Speaking about sysinstall, would you please check my PR (bin/21423,
URL:http://www.freebsd.org/cgi/query-pr.cgi?pr=21423) ?
Done and fixed, thanks! It should be in the next (2930) -current
snapshot in ftp://current.freebsd.org/pub/FreeBSD/snapshots/i386/
- Jordan
To Unsubscribe: send
jkh Done and fixed, thanks!
Wow, thank you ^_^
But.. maybe my PR is not clearly described, it does not fix current
situation; very sorry for my poor presentations.
Here is a current directory structure (just extracted tarballs) of
5-current as of Sep/29/2000.
% cd
From: Takanori Watanabe [EMAIL PROTECTED]
Date: Thu, 28 Sep 2000 13:38:57 +0900
::With the addition of ACPI kernel thread, my system hangs in about
::10 miniutes use after boot up. By disabling kernel thread, system
::runs just fine.
::
::Do you have any idea where to look at?
::I'll try and see
Here's the latest ACPI megapatch:
- Move all the register I/O into a separate file
- Made all the I/O spaces use proper bus resources
- Allocate the resources in machine-dependant code
- Map ACPI-used memory in machine-dependant code
- Create a machine-dependant "acpiprobe" device which
Currently kernel thread seems broken, so mallocing storage in
acpi_queue_event() never be freed. I think number of events at a
point of tme is limited and we can have static storage for the events.
The implementaion of sys/i386/apm/apm.c:apm_record_event() (it's for apmd)
Thanks a lot mike, these are mostly acceptable for me.
Here's the latest ACPI megapatch:
- Move all the register I/O into a separate file
Agreed.
- Made all the I/O spaces use proper bus resources
- Allocate the resources in machine-dependant code
I prefer previous patch because most
From: Mitsuru IWASAKI [EMAIL PROTECTED]
Subject: [acpi-jp 691] Re: ACPI megapatch
Date: Fri, 29 Sep 2000 22:05:17 +0900
Message-ID: [EMAIL PROTECTED]
Issues outstanding:
- Need to remove superfluous headers
- Need to decide the correct split between sys/acpi.h and
From: "T.SHIOZAKI" [EMAIL PROTECTED]
Subject: [acpi-jp 692] Re: ACPI megapatch
Date: Fri, 29 Sep 2000 22:41:39 +0900 (JST)
Message-ID: [EMAIL PROTECTED]
IMHO, it's desirable to use the name "acpi.h", because of conflict
Sorry, "it's desirable to avoid using ...".
--
Takuya SHIOZAKI
To
Hi,
I'd like to move and rename them as I said in my previous mail,
sys/acpi.h - sys/dev/acpi/acpi.h
shared by both kernel and userland programs
sys/dev/acpi/acpi.h - sys/dev/acpi/acpivar.h
shared within kernel code (acpi stuff and related drivers)
IMHO, it's desirable to
In summary, my suggestions are
- i386/i386/acpi_machdep.c
acpi_find_rsdp() and acpi_mapmem()
- dev/acpi/acpi.c
acpi_identify() and acpi_find_facp()
Here is a patch for your megapatch at
http://people.FreeBSD.org/~iwasaki/acpi/patch-for-megapatch.diff
I'll be happy if you
In message [EMAIL PROTECTED], Mitsuru IWASAKI wrote:
In summary, my suggestions are
- i386/i386/acpi_machdep.c
acpi_find_rsdp() and acpi_mapmem()
- dev/acpi/acpi.c
acpi_identify() and acpi_find_facp()
Here is a patch for your megapatch at
I am not aware of the full status of IPX networking support in -current,
but I migrated my -stable kernel config as best I could. Kernel compilation
completes, but linking fails due to a rand_ function not being present ( I do
not have the exact error handy, but can generate for anyone
Hello!
What is the suggested best way to set permissions on devices in DEVFS?
(I want to chmod 664 /dev/acd0c to let users in the group operator
burn CD-R's).
Do we already have a common way that I missed?
Or is the best way to put it into rc.local (or similar)?
Thanks
Alex
--
cat:
Ciao.
I need to know the exact format of the /proc/*/cmdline of FreeBSD. Actually
I'm using 4.1 and I have discovered that at the end of cmdline file there are
always 2 NULL characters.
Is this a standard behaviour of FBSD cmdline ? From 3.0 is it changed or
it will change ?
Thanks.
--
Bye,
In the last episode (Sep 29), [EMAIL PROTECTED] said:
I need to know the exact format of the /proc/*/cmdline of FreeBSD.
Actually I'm using 4.1 and I have discovered that at the end of
cmdline file there are always 2 NULL characters.
You sure?
$ uname -v
FreeBSD 5.0-CURRENT #69: Tue Sep 5
Here is a patch for your megapatch at
http://people.FreeBSD.org/~iwasaki/acpi/patch-for-megapatch.diff
I'll be happy if you accept and commit this :-)
I think it is better bus attachment code is in MD part than in MI part.
And MD bus attachment code calls MI bus attachment code.
For
In article [EMAIL PROTECTED],
[EMAIL PROTECTED] wrote:
I need to know the exact format of the /proc/*/cmdline of
FreeBSD. Actually I'm using 4.1 and I have discovered that at the
end of cmdline file there are always 2 NULL characters.
I'm not seeing that on my 4.x-stable system from about a
On Fri, 29 Sep 2000, Alexander Langer wrote:
What is the suggested best way to set permissions on devices in DEVFS?
(I want to chmod 664 /dev/acd0c to let users in the group operator
burn CD-R's).
Do we already have a common way that I missed?
/etc/rc.devfs
- Donn
To Unsubscribe: send
% ls boot/kernel/kernel*
zsh: no matches found: boot/kernel/kernel*
That's a different problem - there should be a boot/kernel/kernel.ko
file and I'm not sure why there isn't. I'll talk to David O'Brien
about fixing it.
- Jordan
To Unsubscribe: send mail to [EMAIL PROTECTED]
with
You wrote:
I need to know the exact format of the /proc/*/cmdline of
FreeBSD. Actually I'm using 4.1 and I have discovered that at the
end of cmdline file there are always 2 NULL characters.
I'm not seeing that on my 4.x-stable system from about a month ago:
Sorry, I just found a bug
On Fri, Sep 29, 2000 at 08:49:06PM +, [EMAIL PROTECTED] wrote:
You wrote:
I need to know the exact format of the /proc/*/cmdline of
FreeBSD. Actually I'm using 4.1 and I have discovered that at the
end of cmdline file there are always 2 NULL characters.
I'm not seeing that on
On Thu, Sep 28, 2000 at 21:45 -0500, Tony Johnson wrote:
Since I am complaining then I need to figure out what U have
done to make 5.0-CURRENT crash?? Well atleast U admit that U
do not know and U do not care. So anyone who is using FreeBSD
should also not care?? This is more screwed up
I'd like to move and rename them as I said in my previous mail,
sys/acpi.h - sys/dev/acpi/acpi.h
shared by both kernel and userland programs
sys/dev/acpi/acpi.h - sys/dev/acpi/acpivar.h
shared within kernel code (acpi stuff and related drivers)
IMHO, it's desirable to use
Thanks a lot mike, these are mostly acceptable for me.
- Made all the I/O spaces use proper bus resources
- Allocate the resources in machine-dependant code
I prefer previous patch because most of the code in i386/acpi_machdep.c
can be shared with IA64 I think.
I'm not so sure about
And probe method and identify method should not be confused.
Memory area check etc can be in MD acpi probe code.
Can you explain what you mean here a bit more? The FACT lookup and
resource establishment need to be done in the identify routine, not the
probe routine...
--
... every
Hi,
I prefer previous patch because most of the code in i386/acpi_machdep.c
can be shared with IA64 I think.
I'm not so sure about that. I suspect that the IA64 code is going to be
using the 'generic address' structures and the x-fields in eg. the FACT.
It won't be using the bios
OK, understood. How about having MD sub-routine in the same interface
(say acpi_set_resources() or acpi_create_instance() or whatever) for
i386 and ia64? Then generic ACPI identify method calls suitable
sub-routine depending on machine architecture.
- i386/i386/acpi_machdep.c
On Sep 29, 11:30am, Greg Lehey wrote:
} Subject: Repeated panic out of chgsbsize
} In the past couple of days, I've had a couple of panics out of chgsbsize:
}
} (kgdb) bt
[ snip ]
} #12 0xc01cbac9 in panic (fmt=0xc0356920 "reducing sbsize: lost count, uid = %d") at
If you have machines running -CURRENT from September 9 - September
29, _and_ you created an /etc/nsswitch.conf with any of `passwd: dns',
`group: dns', `passwd_compat: dns', `group_compat: dns', then you
are vulnerable to a local attack.
So upgrade :-)
(or just apply the small patch)
--
On Fri, 29 Sep 2000, Kevin M. Dulzo wrote:
I am not aware of the full status of IPX networking support in -current,
but I migrated my -stable kernel config as best I could. Kernel compilation
completes, but linking fails due to a rand_ function not being present ( I do
not have the
Ok. Based on all the suggestions, received today, and some more ideas
besides, here's the latest megapatch.
- Move all register I/O into a new file
- Move event handling into a new file
- Move headers to acpivar/acpireg/acpiio
- Move find-RSDT and find-ACPI-owened-memory into acpi_machdep
As Iwasaki-san pointed out, I left acpi_event.c out of the previous
megapatch. Rather than resend the entire thing, you can fetch the
complete patch from:
http://people.freebsd.org/~msmith/acpi-2929.diff.gz
Regards,
--
... every activity meets with opposition, everyone who acts has
34 matches
Mail list logo
