In message: <20100819170643.38362078@dlink.ua>
Alexandr Rybalko writes:
: On Thu, 19 Aug 2010 09:18:46 -0400
: John Baldwin wrote:
:
: >> On Thursday, August 19, 2010 8:38:05 am Alexandr Rybalko wrote:
: >> > Hi all,
: >> >
: >> > Can someone say, how `make` in sys/modules dir c
In message: <201008171615.21103@freebsd.org>
John Baldwin writes:
: > So more or less it's for BIOSes with ISA that doesn't feature plug
: > and play (286s, 386s, some 486s?)? Just trying to fill in the gap :).
:
: Yes, it may perhaps still be useful for some x86 embedded syst
On 08/23/2010 22:10, Artem Belevich wrote:
> First prepare the data.
> * You'll need some files totalling around the amount of physical
> memory on your box. Multiple copies of /usr/src should do the trick.
> * Place one copy on UFS filesystem and another on ZFS
>
> Experiment #1:
> * Prime ARC b
Could you try following experiments before and after the patch while
monitoring kstat.zfs.misc.arcstats.size and
vm.stats.vm.v_inactive_count.
First prepare the data.
* You'll need some files totalling around the amount of physical
memory on your box. Multiple copies of /usr/src should do the tri
From: Tim Judd
> I have, for longer than I can count, create my own livecds because the media
> that's produced have a shortcoming for some reason or other.
I automated my own build from sources (not .iso) of combined install
+ live CDROMs, a frighteningly long time ago:
My top Makefile:
On 08/23/2010 16:42, jhell wrote:
> On 08/23/2010 03:28, Artem Belevich wrote:
>> Can anyone test the patch on a system with mix of UFS/ZFS filesystems
>> and see if the change mitigates or solves the issue with inactive
>> memory excessively backpressuring ARC.
>
> I have a system currently patch
On 08/23/2010 03:28, Artem Belevich wrote:
> Can anyone test the patch on a system with mix of UFS/ZFS filesystems
> and see if the change mitigates or solves the issue with inactive
> memory excessively backpressuring ARC.
I have a system currently patched up to ZFSv15 and mm@'s metaslab patch
ru
On Thursday 19 August 2010 12:48 am, Oleg Sharoyko wrote:
> On 16 August 2010 22:21, Jung-uk Kim wrote:
> > In theory, we can shadow video ROM and execute it in emulation
> > *iff* it actually contains x86 real mode code. It won't be too
> > hard but I am not sure whether it is worth trying. Are
2010/8/23 Andriy Gapon :
> on 23/08/2010 15:10 John Baldwin said the following:
>> On Friday, August 20, 2010 1:13:53 pm Ryan Stone wrote:
>>> Consider the following modules:
>>>
>>> /* first.c */
>>> static int *test;
>>>
>>> int
>>> test_function(void)
>>> {
>>> return *test;
>>> }
>>>
>>> st
On Mon, Aug 23, 2010 at 5:07 AM, John Baldwin wrote:
> On Friday, August 20, 2010 10:14:46 am Garrett Cooper wrote:
>> Hi,
>> Currently the code in identcpu.c does a check for a specific cpu
>> value extension. This is set to 0x8004 (even though the
>> corresponding code below iterates thr
On Monday, August 23, 2010 11:04:20 am Andriy Gapon wrote:
> on 23/08/2010 15:10 John Baldwin said the following:
> > On Friday, August 20, 2010 1:13:53 pm Ryan Stone wrote:
> >> Consider the following modules:
> >>
> >> /* first.c */
> >> static int *test;
> >>
> >> int
> >> test_function(void)
>
on 23/08/2010 15:10 John Baldwin said the following:
> On Friday, August 20, 2010 1:13:53 pm Ryan Stone wrote:
>> Consider the following modules:
>>
>> /* first.c */
>> static int *test;
>>
>> int
>> test_function(void)
>> {
>> return *test;
>> }
>>
>> static int
>> first_modevent(struct module
On Sat, Aug 21, 2010 at 6:25 PM, Anonymous wrote:
> "Domagoj S." writes:
>
>> 8.1 RELEASE 32bit
>>
>> # gcc --version
>> gcc (GCC) 4.2.1 20070719 [FreeBSD]
>>
>> As per: http://gcc.gnu.org/gcc-4.2/changes.html
>> core2 is supported
>
> It's not! `core' and `core2' for -mtune/-march introduced
On Friday, August 20, 2010 1:13:53 pm Ryan Stone wrote:
> Consider the following modules:
>
> /* first.c */
> static int *test;
>
> int
> test_function(void)
> {
> return *test;
> }
>
> static int
> first_modevent(struct module *m, int what, void *arg)
> {
> int err = 0;
>
>
On Friday, August 20, 2010 10:14:46 am Garrett Cooper wrote:
> Hi,
> Currently the code in identcpu.c does a check for a specific cpu
> value extension. This is set to 0x8004 (even though the
> corresponding code below iterates through 0x8002:0x8005):
It does not invoke 0x8005
Hi all,
Per Lars's request I've uploaded an ISO of the FreeBSD live CD for
amd64:
URL:http://people.freebsd.org/~ed/FreeBSD-9.0-CURRENT-201008-amd64-ed.iso.xz
Size: 422452056 bytes (403 MB)
SHA256: e0b7ac8eac713ecd5ccdbf107c80563260e6000b27838b003ca11a42ae6ae700
Have fun!
--
Ed Schouten
Quoting Ed Schouten :
Hello all,
A couple of major releases ago, we had a FreeBSD disc1.iso which also
included the livefs. Nowadays the livefs comes on a separate disc. This
livefs disc has a couple of issues in my opinion:
- The livefs disc does not feature any installsets, which means if yo
"Daniel O'Connor" wrote:
> On 23/08/2010, at 1:24, Xin LI wrote:
> > 2010/8/7 Dag-Erling Sm?rgrav :
> >> Xin LI writes:
> >>> I'm still polishing up the driver, there seems to be no way to
> >>> figure out the base port address directly (datasheet said it's
> >>> either 0x2e and 0x4e) so for now
* Lars Engels wrote:
> could you please upload the resulting ISO so that people who don't
> want to create it themselves can test your CD?
Prrr... I have a horrible internet connection and the resulting ISO is
about 600 MB big. I'll see what I can do.
--
Ed Schouten
WWW: http://80386.nl/
p
"Daniel O'Connor" writes:
> They're LPC ISA devices, I don't know if they appear in any PNP or
> ACPI tables though.
Same issue with ichwd: ISTR there is actually supposed to be an entry
for it in an ACPI table, but on the motherboard I had when I tested it
before I committed it, that table eithe
on 23/08/2010 10:28 Artem Belevich said the following:
> If we could also deal with zone fragmentation issue you've written in
> another thread, that should bring ZFS even closer to being usable
> without shaman-style (the one with lots of muttering, swearing and
> dancing around) tuning.
>
> Actu
Ah! After re-reading your first email and I think I've finally got
what you're saying -- with your change ARC would only start giving up
memory when pagedaemon is awake. Presumably once it's awake it will
also run through inactive list pushing some of it to cache. On the
other hand existing code vo
22 matches
Mail list logo
