* 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 wo
> Speaking about sysinstall, would you please check my PR (bin/21423,
> 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 ma
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 ~ftp/pub/FreeBSD/snapshots/
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
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 jus
> > > > 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 fo
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
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 and
> > in terms of fu
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
T
Hi,
> > I'd like to move and rename them as I said in my previous mail,
> > ->
> > shared by both kernel and userland programs
> > ->
> > shared within kernel code (acpi stuff and related drivers)
>
> IMHO, it's desirable to use the name "acpi.h", because of conflict
> with the file
> 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 a
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
>http://people.FreeBSD.org/
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 w
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: /home/alex/
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
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 ab
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: sen
> % 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 "unsubsc
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
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
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
> > > I'd like to move and rename them as I said in my previous mail,
> > > ->
> > > shared by both kernel and userland programs
> > > ->
> > > shared within kernel code (acpi stuff and related drivers)
> >
> > IMHO, it's desirable to use the name "acpi.h", because of conflict
> > with th
> 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 su
> 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 ac
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 bio
> 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
../../kern/kern_shutdown.c:
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)
--
Jacques
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
From: Poul-Henning Kamp <[EMAIL PROTECTED]>
Date: Wed, 27 Sep 2000 15:25:42 +0200
> Use a normal timeout ?
I changed to use timeout() and now they do not change clock.c.
Updated files can be obtained from,
http://home.jp.freebsd.org/~non/scsi_low-2930.tar.gz (added files)
http://home.jp.fr
Hi.
At Sun, 27 Aug 2000 15:16:01 +0200 (CEST),
Alexander Leidinger <[EMAIL PROTECTED]> wrote:
> > Can anyone success compiling kernel with the following config?
> >
> > # ATA and ATAPI devices
> > device ata
> > device atadisk # ATA disk drives
> > #device
36 matches
Mail list logo
