code might be parsing the system memory map incorrectly.
But I am just making wild guesses here.
--
Andriy Gapon
___
freebsd-current@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-current
To unsubscribe, send any mail to "freebsd-current-unsubscr...@freebsd.org"
y options I have when I press F12 are to either boot from my
> hard drive or to boot from my optical drive. Is there
> any way to more verbosely see what is happening at the bootloader level?
I guess that F12 that you describe is handled by BIOS.
Do you have other HDDs in thi
ay will compile everything just fine even with
> 'CPUTYPE = native'. the only way to break this is to go and compile gcc again
> with the CPUTYPE set to 'native'.
>
> so to summarize: compiling gnu/usr.bin/cc with CPUTYPE set to 'native' will
> give you a
re:
> /usr/include
> End of search list.
> $ echo $?
> 0
Do you also have the latest version of libc _installed_ in the system?
--
Andriy Gapon
___
freebsd-current@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-current
To unsubscribe, send any mail to "freebsd-current-unsubscr...@freebsd.org"
on 21/03/2010 14:35 Alexander Best said the following:
> Andriy Gapon schrieb am 2010-03-21:
>> on 21/03/2010 13:43 Garrett Cooper said the following:
>
>>> Works for me *shrugs*:
>
>>> $ gcc -v -x c -E -mtune=native /dev/null -o /dev/null 2>&1
>
nk one idea was making sure (somehow) that requests traveling over the same
edge of a geom graph (in the same direction) do it using the same queue/thread.
Another idea was to bring some netgraph-like optimization where some (carefully
chosen) geom vertices pass requests by a
on 21/03/2010 14:53 Alexander Best said the following:
> *lol* sorry. ;)
No worries.
BTW, when that rash happens, are you able to examine the core with gdb?
Is it possible to examine values of 's' and 'p' in strlen?
--
Andriy Gapon
on 21/03/2010 20:46 Alexander Best said the following:
> Andriy Gapon schrieb am 2010-03-21:
>> on 21/03/2010 14:53 Alexander Best said the following:
>>> *lol* sorry. ;)
>
>> No worries.
>> BTW, when that rash happens, are you able to examine the core with
>
able for examination as
a variable further down the stack (i.e. in one of the calling functions).
--
Andriy Gapon
___
freebsd-current@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-current
To unsubscribe, send any mail to
on 22/03/2010 00:12 Alexander Best said the following:
> Andriy Gapon schrieb am 2010-03-21:
>> on 21/03/2010 23:11 Alexander Best said the following:
>>> *hehe* that makes more sense. well i already sent you lp.
>>> unfortunately str is
>>> not avai
rent size
>> *** Error code 1
>>
>> Stop in /obj/i386/src/sys/PAE.
>> *** Error code 1
>>
>> Stop in /src.
>> *** Error code 1
>>
>> Stop in /src.
>> TB --- 2010-03-21 04:58:08 - WARNING: /usr/bin/make return
roduce this issue could either add
a
couple of printfs before the quoted above line or examined a crashdump to
determine values of SecPerClust and pm_BlkPerSec before the multiplication.
Could you guys please do it?
Thanks!
--
Andriy Gapon
___
fre
If you want to make sure that I see your reply please include me into recipient
list. FreeBSD mailing lists sometimes have high volume and it's easy to miss a
followup even if you are interested in reading it.
on 28/03/2010 18:25 Fabian Keil said the following:
> Andriy Gapon wrote:
&g
on 29/03/2010 23:29 Fabian Keil said the following:
> Andriy Gapon wrote:
>> Thus, clearly, it is a fault of a tool that formatted the media for FAT.
>> It should have picked correct values, or rejected incorrect values if
>> those were provided as overrides via command l
on 30/03/2010 18:36 Fabian Keil said the following:
> Andriy Gapon wrote:
>
>> on 29/03/2010 23:29 Fabian Keil said the following:
>>> Andriy Gapon wrote:
>>>> Thus, clearly, it is a fault of a tool that formatted the media for FAT.
>>>> It s
on 30/03/2010 18:41 Andriy Gapon said the following:
> on 30/03/2010 18:36 Fabian Keil said the following:
>> Andriy Gapon wrote:
>>
>>> on 29/03/2010 23:29 Fabian Keil said the following:
>>>> Andriy Gapon wrote:
>>>>> Thus, clearly, it is
on 02/04/2010 13:57 Fabian Keil said the following:
> Andriy Gapon wrote:
>> Anyways, here is a patch that I would use.
>> Unfortunately, ENOTIME to understand newfs_msdos code and fix it too,
>>
>> --- a/sys/fs/msdosfs/msdosfs_vfsops.c
>> +++ b/sys/fs/msdosfs/msd
on 02/04/2010 14:09 Andriy Gapon said the following:
> on 02/04/2010 13:57 Fabian Keil said the following:
>> Andriy Gapon wrote:
>>> Anyways, here is a patch that I would use.
>>> Unfortunately, ENOTIME to understand newfs_msdos code and fix it too,
>>>
>&
on 02/04/2010 22:26 Andriy Gapon said the following:
>
> OK, I did it again.
> I tested the below patch using the scenario described above.
> Could you please review and/or test this patch?
> If you like it and it works, I can commit it.
> Thanks!
>
> --- a/sbin/newfs_msd
roportionally larger.
Last sentence is your own conclusion I guess?
Please read this whole thread to see why it doesn't work that way in practice.
At least for present FreeBSD.
--
Andriy Gapon
___
freebsd-current@freebsd.org mailing list
http://
on 03/04/2010 18:27 Andriy Gapon said the following:
> on 03/04/2010 18:07 Tijl Coosemans said the following:
>> I'm not sure the second paragraph is worth supporting, but the first
>> seems to say that 32k limit you have in your patch only applies to
>> disks with 512 by
ilio has suggested.
When everything else fails, a digital camera still can be used to get screen
captures:-)
--
Andriy Gapon
___
freebsd-current@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-current
To unsubscribe, send any mail to "freebsd-current-unsubscr...@freebsd.org"
s Andrey from creating his own svn/hg/git/etc repo _just_ for
his
sade bits. It's easy. This is what I would do even just for my own sake.
--
Andriy Gapon
___
freebsd-current@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freeb
t;
> _______
> freebsd-current@freebsd.org mailing list
> http://lists.freebsd.org/mailman/listinfo/freebsd-current
> To unsubscribe, send any mail to "freebsd-current-unsubscr...@freebsd.org"
>
--
Andriy Gapon
___
freebsd-current@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-current
To unsubscribe, send any mail to "freebsd-current-unsubscr...@freebsd.org"
ussion we found that the disk reports 512 sector size, but
> there are additional ATA commands to determine if it has real sector size
> larger than 4k. I will try to confirm this.
Thank you. I think that this would be an interesting detail.
--
Andriy Gapon
on 09/04/2010 14:33 Alexey Tarasov said the following:
> On 09.04.2010, at 15:32, Andriy Gapon wrote:
>
>> on 09/04/2010 14:27 Alexey Tarasov said the following:
>>>> Or the disk doesn't actually report 4096 anywhere anyhow... Have you
>>>> considere
on 09/04/2010 14:31 Dag-Erling Smørgrav said the following:
> Andriy Gapon writes:
>> P.S. DES's name looks strange in headers :-)
>
> Get a better MUA. MIME quoted-printable has been around for what, 15
> years?
The advice is misdirected. Right, Dmitry
device's minimum transfer size.
*/
*ashift = highbit(MAX(pp->sectorsize, SPA_MINBLOCKSIZE)) - 1;
This is in vdev_geom_open and SPA_MINBLOCKSIZE is 512.
--
Andriy Gapon
___
freebsd-current@freebsd.org mailing list
http://list
;
> how to cross compile it?
>
> PS: I build only kernel at this point. Should I rebuild whole world to
> build kernel?
kernel-toolchain
See build(7)
--
Andriy Gapon
___
freebsd-current@freebsd.org mailing list
http://lists.freebsd
on 16/04/2010 04:19 Arseny Nasokin said the following:
>
>
> On 16 Apr 2010, at 03:03, Andriy Gapon wrote:
>
>> on 16/04/2010 01:27 Arseny Nasokin said the following:
>>> I get error in same point when I try compile amd64 current GENERIC on
>>>
esponding
world or the kernel toolchain.
--
Andriy Gapon
___
freebsd-current@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-current
To unsubscribe, send any mail to "freebsd-current-unsubscr...@freebsd.org"
ce-luke=4gms is?
> Should we allow it like linux does?
What exactly is disallowed on FreeBSD?
--
Andriy Gapon
___
freebsd-current@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-current
To unsubscribe, send any mail to "f
SO9660 are all sector
> numbers so 8TB should be the natural limit (4G sectors
> times 2k bytes/sector).
I don't think that the problem is with limit on sector count here.
I think it's a limitation with size/offset in bytes somewhere in cd9660 fs
driver.
--
Andriy Gapon
cessor, so I am not entirely sure.
But for 10h processors BKDG table 80 (NB error signatures) definitely specifies
that extended error code of 8 (in bits 20:16) means ECC error.
--
Andriy Gapon
___
freebsd-current@freebsd.org mailing list
http://lists.fre
also need access to the corresponding passX device, which you can
find from output of 'camcontrol devlist'.
You didn't need that with *a*cd0.
--
Andriy Gapon
___
freebsd-current@freebsd.org mailing list
http://lists.freebsd.org/mailman/lis
burncd for CAM (SCSI, ATAPI) will be something very close to cdrecord or
growisofs.
--
Andriy Gapon
___
freebsd-current@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-current
To unsubscribe, send any mail to "freeb
e 4.
> ** Building recovery table.
> ** Resolving unreferenced inode list.
> ** Processing journal entries.
> ** 0 journal records in 0 bytes for nan% utilization <
> ** Freed 0 inodes (0 dirs) 0 blocks, and 0 frags.
> --
--
Andriy Gapon
e' count.
I think that this is by design, to prevent foot-shooting.
We either should document this behavior or re-consider it.
--
Andriy Gapon
___
freebsd-current@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-cur
nip]
> Any ideas on this?
Yes, one idea - to verify what the message above says.
You can use hd to see if you indeed have '\0' (0x00) symbol somewhere within
your kernel config file.
--
Andriy Gapon
___
freebsd-current@freebsd.org mailing
on 30/04/2010 00:12 Michael Moll said the following:
> Hi,
>
> On Thu, Apr 29, 2010 at 11:33:30PM +0300, Andriy Gapon wrote:
>> on 29/04/2010 18:31 Michael Moll said the following:
>> You can use hd to see if you indeed have '\0' (0x00) symbol somewhere wi
taking a look
> around in my process table, I could find several find's hanging around too.
>
> mhettwer 5976 0.0 0.0 6896 1088 13 D+5:55PM 0:00.00 df -h
> mhettwer 5351 0.0 0.0 6896 1088 19 D+1:49PM 0:00.00 df -h
Can you run procstat -k to see where exact
()
> #10 0xff0060c0b740 in ?? ()
> #11 0x80b83c60 in sysent ()
> #12 0xff8040d2cc80 in ?? ()
> #13 0xff8040d2cae0 in ?? ()
> #14 0x8059c431 in bintime (bt=0x80ad3140)
> at /usr/src/sys/kern/kern_tc.c:200
> Previous frame in
on 18/08/2010 22:07 Marian Hettwer said the following:
> I'll try and reproduce that tomorrow. I would say, a hanging nfs mount
> shouldn't lead to a hanging around df(1).
See df -n.
--
Andriy Gapon
___
freebsd-current@freebsd.org m
x27;t see anything dramatically wrong here.
So "swi4: clock" uses 5.76% of WCPU, is that such a big deal to be called
"runaway
intr"?
A lot of CPU time is idle and a lot is used by userland processes (e.g. Xorg).
Can you provide data that better illustrate your problem?
--
on 19/08/2010 20:30 Doug Barton said the following:
> On 08/19/2010 08:24, Andriy Gapon wrote:
>> I am sorry, but I don't see anything dramatically wrong here. So
>> "swi4: clock" uses 5.76% of WCPU, is that such a big deal to be
>> called "runaway i
here are no followups/comments on results of the old dtrace
script, so I am not sure if there is any point in continuing to post it.
It is useless personally for me.
Back to the data.
Could you please report results of
procstat -k 10
procstat -k 11
?
Thanks.
--
A
on 21/08/2010 09:50 Andriy Gapon said the following:
> on 21/08/2010 03:03 Doug Barton said the following:
>> Here are the results of a vmstat -i, the old dtrace script, and Andriy's
>> new one.
>
> I think that for such amount of data it is better to use links (perhaps
on 21/08/2010 10:33 Doug Barton said the following:
> On Sat, 21 Aug 2010, Andriy Gapon wrote:
>
>>> I think that for such amount of data it is better to use links
>>> (perhaps a
>>> service like pastebin) rather than inlining it.
>
> No problem:
> htt
on 21/08/2010 12:35 Andriy Gapon said the following:
> I feel like you might be having a problem with clocks...
FWIW, I am reading this document http://edc.intel.com/Link.aspx?id=1484
and I see this sentence: "All of the clocks in the processor core are
stopped in the C3 state".
I
on 21/08/2010 16:04 b. f. said the following:
> Andriy Gapon wrote:
>> on 21/08/2010 12:35 Andriy Gapon said the following:
>>> I feel like you might be having a problem with clocks...
>> FWIW, I am reading this document http://edc.intel.com/Link.aspx?id=1484
>> an
on 30/07/2010 17:36 Anton Shterenlikht said the following:
> On Fri, Jul 30, 2010 at 04:31:44PM +0300, Andriy Gapon wrote:
>> Just a one thing to try - can you please add hdac_reset(sc, 1) call in
>> hdac_attach() right before hdac_get_capabilities() call?
>> The idea is to
.txt
So, hm, npviewer.bin eats all the CPU time?
Just google that name and see that you are not alone.
Can't help with that though.
> This was with ULE + USB in the kernel, LAPIC/HPET, cx_lowest=C1, but running
> powerd with the following:
> powerd_flags=&q
on 23/08/2010 09:48 Doug Barton said the following:
> On 08/22/2010 23:20, Andriy Gapon wrote:
>> on 23/08/2010 06:17 Doug Barton said the following:
>>
>>> http://people.freebsd.org/~dougb/intr-out-3.txt
>>
>> So, hm, npviewer.bin eats all the CPU time?
>
stem?
Maybe you'd want to stick to just one of them?
E.g.:
http://lists.freebsd.org/pipermail/freebsd-stable/2010-March/055666.html
--
Andriy Gapon
___
freebsd-current@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-curren
te. */
> #define TSF_XFERABLE0x0002 /* Thread was added as
> transferable. */
> +#define TSF_BINDING 0x0004 /* Thread is being bound. */
I don't really follow why TSF_BINDING is needed, i.e. why TSF_BOUND is not
sufficient in this case?
--
Andri
heat when the system is
> idle (and by extension, power consumption as well).
>
> Unless you say differently when I get up tomorrow I'll try this configuration
> for a little while and see how it goes.
So, how did this go?
Did the change make any difference?
--
Andriy Gapon
> have
> finally figured out how to boot windows, linux, and 2 FreeBSDs on the same
> disk
> I'll be able to set up 7-stable i386 and 9-current amd64 to see how they
> compare
> to the 9-current i386 I was using previously; so I should have more
> informa
t.
So the patch should help there.
--
Andriy Gapon
___
freebsd-current@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-current
To unsubscribe, send any mail to "freebsd-current-unsubscr...@freebsd.org"
fication should be needed,
but issuing somehow does make difference,
Hmm...
--
Andriy Gapon
___
freebsd-current@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-current
To unsubscribe, send any mail to "freebsd-current-unsubscr...@freebsd.org"
s read? You can use combination of syscall and fbt providers
with execname predicate.
--
Andriy Gapon
___
freebsd-current@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-current
To unsubscribe, send any mail to "freebsd-current-unsubscr...@freebsd.org"
ease test even if everything is OK, to avoid
regressions.
Thanks!
--
Andriy Gapon
___
freebsd-current@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-current
To unsubscribe, send any mail to "freebsd-current-unsubscr...@freebsd.org"
on 30/08/2010 12:15 pluknet said the following:
> On 29 August 2010 13:25, Andriy Gapon wrote:
>>
>> [Reposted from stable@; edited]
>>
>> The below patch is against sources in FreeBSD tree, it should be applied
>> either to sys/amd64/amd64/mp_machdep.c or sys/i38
on 29/08/2010 12:25 Andriy Gapon said the following:
> The patch is substantially based on the Junk-uk's patch, but with some changes
I several times mistyped Jung-uk's name, my sincere apologies.
Probably should have used jkim instead :)
Thanks to rdivacky for pointing t
e.g. objdump -T /usr/lib/libgcc_s.so
--
Andriy Gapon
___
freebsd-current@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-current
To unsubscribe, send any mail to "freebsd-current-unsubscr...@freebsd.org"
this kind of option would enable OS use of the watchdog.
Perhaps you can contact Intel about this issue, either via their official
support service or via jfv (who is CCed as I see) or both.
--
Andriy Gapon
___
freebsd-current@freebsd.org mailing list
http://lis
assle, then I'd appreciate it.
Thanks!
--
Andriy Gapon
___
freebsd-current@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-current
To unsubscribe, send any mail to "freebsd-current-unsubscr...@freebsd.org"
The subject should have been what it is now, sorry.
--
Andriy Gapon
___
freebsd-current@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-current
To unsubscribe, send any mail to "freebsd-current-unsubscr...@freebsd.org"
internal code which results in incorrect
SCSI command(s) that may confuse some drive models at device or media probing
stage.
--
Andriy Gapon
___
freebsd-current@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-current
To
t:::return
/self->trace/
{
printf("%d", arg1);
}
syscall::ioctl:return
{
self->trace = 0;
}
> My next step was going
> to be enabling CAMDEBUG and trying to find out which specific
> operation was failing, but I'm not a SCSI expert by any means
Not sur
accidentally broke and then fixed while
pursuing your NFS issue?
--
Andriy Gapon
___
freebsd-current@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-current
To unsubscribe, send any mail to "freebsd-current-unsubscr...@freebsd.org"
47432 = syscall+0x42
Xfast_syscall() at 0x80531702 = Xfast_syscall+0xe2
--- syscall (326, FreeBSD ELF64, __getcwd), rip = 0x800939cfc, rsp =
0x7fffe0b8, rbp = 0x800c2a208 ---
--
Andriy Gapon
___
freebsd-current@freebsd.org mailing list
!
--
Andriy Gapon
___
freebsd-current@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-current
To unsubscribe, send any mail to "freebsd-current-unsubscr...@freebsd.org"
on 02/09/2010 13:01 Andriy Gapon said the following:
>
> Brian,
>
> after I upgraded my kernel from beginning of July version to end of August
> version I started to get panics in get_next_dirent under parallel FS load,
> like
> e.g. during buildworld with -jN.
>
> I
on 02/09/2010 13:10 Andriy Gapon said the following:
>
> Not sure if this is some local issue or a problem in FreeBSD code.
> I remember minidumps working perfectly well for me, but now I can not get data
> from them.
> Example:
> dmesg -M /var/crash/vmcore.4
> dmesg: _
ackup_init.08-31-2010.gz
> :-( unable to CAMGETPASSTHRU for /dev/cd0: Inappropriate ioctl for device
You can try to use DTrace to see where exactly in kernel the ioctl request
fails.
--
Andriy Gapon
___
freebsd-current@freebsd.org mailing list
http://lists.f
on 02/09/2010 16:08 Andriy Gapon said the following:
> on 02/09/2010 13:10 Andriy Gapon said the following:
>>
>> Not sure if this is some local issue or a problem in FreeBSD code.
>> I remember minidumps working perfectly well for me, but now I can not get
>> da
on 29/08/2010 12:25 Andriy Gapon said the following:
> The below patch is against sources in FreeBSD tree, it should be applied
> either to sys/amd64/amd64/mp_machdep.c or sys/i386/i386/mp_machdep.c depending
> on the desired architecture:
> http://people.freebsd.org/~avg/intel-cpu-
on 06/09/2010 15:23 Jeremy Chadwick said the following:
> On Mon, Sep 06, 2010 at 03:17:42PM +0300, Andriy Gapon wrote:
>> on 29/08/2010 12:25 Andriy Gapon said the following:
>>> The below patch is against sources in FreeBSD tree, it should be applied
>>> either to sys/
x10676 Family = 6 Model = 17 Stepping = 6
Features=0xbfebfbff
Features2=0x8e39d
AMD Features=0x20100800
AMD Features2=0x1
TSC: P-state invariant
[snip]
FreeBSD/SMP: Multiprocessor System Detected: 2 CPUs
FreeBSD/SMP: 1 package(s) x 2 core(s)
cpu0 (BSP): APIC ID:
on 06/09/2010 19:22 Jeremy Chadwick said the following:
> On Mon, Sep 06, 2010 at 04:28:02PM +0300, Andriy Gapon wrote:
>> on 06/09/2010 16:12 Jeremy Chadwick said the following:
>>> Great, thanks! I'll be testing this out on two separate systems, both
>>> RELE
om threads running on freshly started
APs and thus are executed truly parallel to BSP.
BTW, is the above snippet from /var/log/messages or from actual console (e.g.
ttyv0)? If it's from message, then could you please check how it looks on the
console?
--
Andriy Gapon
rderline rude to
> attempt to shift the responsibility for this to the users, it's a violation of
> the robustness principle.
My impression that the suggestion was to do the filtering on the sending end,
not the recipients' end.
--
Andriy Gapon
_
hat transition latency is defined too high.
That is, in this case latency is greater than 100 for C2.
--
Andriy Gapon
___
freebsd-current@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-current
To unsubscribe, send any mail to "freebsd-current-unsubscr...@freebsd.org"
d in this case even if C2 is not
available.
But I think that it might get removed for a different reason: PM2_CNT_BLK length
seems to be zero. With ACPI_DB_INFO enabled there should be "no BM control"
message in the log.
--
Andriy Gapon
___
>
> Hum... ACPI CA 20100806 has a bug?
How do you conclude? Does a different version work?
It seems that our acpidump doesn't dump a dynamically loaded table.
That the table was loaded we can see from these messages:
ACPI: Dynamic OEM Table Load:
ACPI: SSDT 0
omment these checks in acpi_cpu_cx_cst() and look what
> happen. At least I haven't found in ACPI 3.0 specification any latency
> limits applied to _CST.
Not 100% sure, but what you said does make sense.
I couldn't also find any such wording in ACPI
to be changed?
> - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - -
> - - -
> $ sysctl -a | grep cx
> hw.acpi.cpu.cx_lowest: C1
> dev.cpu.0.cx_supported: C1/3 C2/245
cx_supported has C2 now though.
> dev.cpu.0.cx_lowest: C1
> dev.cpu.0.cx_usage: 100
on 12/09/2010 12:29 Alexander Motin said the following:
> hw.acpi.cpu.cx_lowest has default in C1. Have you tried to rise it via
> sysctl?
>
And also check performance_cx_lowest, economy_cx_lowest in
/etc/defaults/rc.conf. And /etc/rc.d/power_profile.
--
And
SOR-0722 [402244] cpu_cx_cst: acpi_cpu0: Got C2 - 245 latency
PROCESSOR-0722 [403097] cpu_cx_cst : acpi_cpu1: Got C2 - 245 latency
PROCESSOR-0722 [403855] cpu_cx_cst: acpi_cpu2: Got C2 - 245 latency
PROCESSOR-0722 [405022] cpu_cx_cst: acpi_cpu3: Got C2 -
on 12/09/2010 13:37 Alexander Motin said the following:
> Andriy Gapon wrote:
>> acpi_lid0: Lid closed
>> em0: Link is up 1000 Mbps Full Duplex
>> PROCESSOR-0722 [402244] cpu_cx_cst: acpi_cpu0: Got C2 - 245
>> latency
>> PROCESSOR-0722 [403097] cpu_c
on 12/09/2010 18:22 Andriy Gapon said the following:
> Observations are correct, but incomplete; the conclusions are wrong.
> At the end of the boot there are message like this one:
> PROCESSOR-0722 [402244] cpu_cx_cst: acpi_cpu0: Got C2 - 245
> latency
> This is
whether to take the Hart
> or
> Boemler one.
+1 FWIW
Especially given that the format is what we use too (modulo subvendor, sub-etc)
--
Andriy Gapon
___
freebsd-current@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-c
[re-post, my address book was polluted with cu_rrr_ent@ entry, sorry]
on 09/09/2010 11:01 Andriy Gapon said the following:
> on 26/07/2010 19:07 Andriy Gapon said the following:
>>
>> Anyone knows any reason why VM_KMEM_SIZE_SCALE on amd64 should not be set to
>> 1?
>>
"[GIANT-LOCKED]\n");
> - if (bootverbose && (flags & INTR_MPSAFE))
> + if (flags & INTR_MPSAFE)
> device_printf(dev, "[MPSAFE]\n");
> if (filter != NULL) {
> if (handler == NULL)
--
Andriy Gapon
Anybody uses if_epair compiled as _module_ on any platform other than amd64?
If yes, could you please respond to me in private?
Big thanks in advance.
--
Andriy Gapon
___
freebsd-current@freebsd.org mailing list
http://lists.freebsd.org/mailman
from anyone I will start backing things
>>> out 1
>>> rev at a time until I find what did it I guess ;-)
>>
>> My guess would be r212647. Try backing that rev out and if it fixes
>> things, hopefully Andriy will have some thoughts on how to fix the
>> proble
ad-elf offlist
I assume you have checked that ld is fresh, but would like to be sure.
--
Andriy Gapon
___
freebsd-current@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-current
To unsubscribe, send any mail to "freebsd-current-unsubscr...@freebsd.org"
stable/7). A symptom of incorrect ld version is
different addresses for set_pcpu section and __start_set_pcpu
symbol in kernel and/or modules.
Apologies for any problems, because of the late notice.
--
Andriy Gapon
___
freebsd-current@freebsd.org mailing
t0.
The information could include "nextboot-pool" and "nextboot-fs".
--
Andriy Gapon
___
freebsd-current@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-current
To unsubscribe, send any mail to "freebsd-current-unsubscr...@freebsd.org"
on 20/09/2010 16:37 John Hay said the following:
> On Mon, Sep 20, 2010 at 03:59:20PM +0300, Andriy Gapon wrote:
>> on 20/09/2010 15:47 Pawel Jakub Dawidek said the following:
>>> No, it doesn't. ZFS works a bit differently. ZFS operate on pools, not
>>> really on
1 - 100 of 1241 matches
Mail list logo
