Re: r323412: Panic on boot (slab->us_keg == keg)
Mark Johnston writes: > I think the bug is that keg_large_init() doesn't take > sizeof(struct uma_slab) into account when setting uk_ppera for the keg. > In particular, the bug isn't specific to the bootup process; it only > affects internal zones with an item size in the range [4016, 4096]. > > The patch below should fix this - could you give it a try? I've tried it and can confirm it fixed the panic here. ___ freebsd-current@freebsd.org mailing list https://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to "freebsd-current-unsubscr...@freebsd.org"
Re: r323412: Panic on boot (slab->us_keg == keg)
Raphael Kubo da Costa writes:
> "Andrey V. Elsukov" writes:
>
>> On 11.09.2017 15:23, Andrey V. Elsukov wrote:
>>
>>> --- trap 0xc, rip = 0x80d84870, rsp = 0x82193970, rbp =
>>> 0x821939b0 ---
>>> zone_import() at zone_import+0x110/frame 0x821939b0
>>> zone_alloc_item() at zone_alloc_item+0x36/frame 0x821939f0
>>> uma_startup() at uma_startup+0x1d0/frame 0x82193ae0
>>> vm_page_startup() at vm_page_startup+0x34e/frame 0x82193b30
>>> vm_mem_init() at vm_mem_init+0x1a/frame 0x82193b50
>>> mi_startup() at mi_startup+0x9c/frame 0x82193b70
>>> btext() at btext+0x2c
>>> Uptime: 1s
>>
>> I bisected revisions, and the last working is r322988.
>
> [...]
>
>> Also I determined that it can successfully boot with disabled
>> hyper-threading.
>
> Did you mistype the revision number? r322988 is "rtwn(4): some initial
> preparations for (basic) VHT support" by avos@.
Sorry for the brain fart. I can confirm that reverting r322989 ("Drop
CACHE_LINE_SIZE to 64 bytes on x86") here on top of r323412 allows the
boot to proceed here.
___
freebsd-current@freebsd.org mailing list
https://lists.freebsd.org/mailman/listinfo/freebsd-current
To unsubscribe, send any mail to "freebsd-current-unsubscr...@freebsd.org"
Re: r323412: Panic on boot (slab->us_keg == keg)
"Andrey V. Elsukov" writes: > On 11.09.2017 15:23, Andrey V. Elsukov wrote: > >> --- trap 0xc, rip = 0x80d84870, rsp = 0x82193970, rbp = >> 0x821939b0 --- >> zone_import() at zone_import+0x110/frame 0x821939b0 >> zone_alloc_item() at zone_alloc_item+0x36/frame 0x821939f0 >> uma_startup() at uma_startup+0x1d0/frame 0x82193ae0 >> vm_page_startup() at vm_page_startup+0x34e/frame 0x82193b30 >> vm_mem_init() at vm_mem_init+0x1a/frame 0x82193b50 >> mi_startup() at mi_startup+0x9c/frame 0x82193b70 >> btext() at btext+0x2c >> Uptime: 1s > > I bisected revisions, and the last working is r322988. [...] > Also I determined that it can successfully boot with disabled > hyper-threading. Did you mistype the revision number? r322988 is "rtwn(4): some initial preparations for (basic) VHT support" by avos@. ___ freebsd-current@freebsd.org mailing list https://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to "freebsd-current-unsubscr...@freebsd.org"
r323412: Panic on boot (slab->us_keg == keg)
I've recently tried to upgrade a HEAD VM (running on a Linux host with QEMU) from r321082 to r323412. The new kernel panics right after I try to boot into it with: panic: Assertion slab->us_keg == keg failed at /usr/src/sys/vm/uma_core.c:2285 cpuid = 0 time = 1 KDB: stack backtrace: db_trace_self_wrapper() at db_trace_self_wrapper+0x2b/frame 0x81c4d780 vpanic() at vpanic+0x19c/frame 0x81c4d800 kassert_panic() at kassert_panic+0x126/frame 0x81c4d870 keg_fetch_slab() at keg_fetch_slab+0x2a9/frame 0x81c4d8c0 zone_fetch_slab() at zone_fetch_slab+0x51/frame 0x81c4d8f0 zone_import() at zone_import+0x4f/frame 0x81c4d960 zone_alloc_item() at zone_alloc_item+0x36/frame 0x81c4d9a0 uma_zcreate() at uma_zcreate+0x3d3/frame 0x81c4da40 uma_startup() at uma_startup+0x147/frame 0x81c4dae0 vm_page_startup() at vm_page_startup+0x34e/frame 0x81c4db30 vm_mem_init() at vm_mem_init+0x1a/frame 0x81c4db50 mi_startup() at mi_startup+0x9c/frame 0x81c4db70 btext() at btext+0x2c KDB: enter: panic [ thread 0 pid 0 tid 0 ] ___ freebsd-current@freebsd.org mailing list https://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to "freebsd-current-unsubscr...@freebsd.org"
Entropy harvesting sysctl error messages as of r254181
After updating -CURRENT from a one or two-month old checkout, I get the following messages when /etc/rc.d/initrandom is run: Entropy harvesting:sysctl: unknown oid 'kern.random.sys.harvest.interrupt': No such file or directory interruptssysctl: unknown oid 'kern.random.sys.harvest.ethernet': No such file or directory ethernetsysctl: unknown oid 'kern.random.sys.harvest.point_to_point': No such file or directory point_to_point kickstart Is there something fishy I should look for? kern.random.adaptors is set to "rdrandyarrow", and this is an IvyBridge laptop running amd64. ___ 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"
Re: panic on boot with fresh current
Konstantin Belousov writes: > The right fix looks to be just what the panic message told, please try > this: The patch managed to fix the crash here at least. ___ 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"
Re: CURRENT: CLANG 3.3 and -stad=c++11 and -stdlib=libc++: isnan()/isninf() oddity
Raphael Kubo da Costa writes: > This seems to have been committed in r253321, and broke some code that > was working with r253320; namely, some code in x11/kde4-workspace > includes math.h and calls isnan() with a const double. For posterity, David has reverted the code back to the previous behaviour in r253766. ___ 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"
Re: CURRENT: CLANG 3.3 and -stad=c++11 and -stdlib=libc++: isnan()/isninf() oddity
David Chisnall writes:
> On 28 Jul 2013, at 22:27, Raphael Kubo da Costa wrote:
>
>> This seems to have been committed in r253321, and broke some code that
>> was working with r253320; namely, some code in x11/kde4-workspace
>> includes math.h and calls isnan() with a const double.
>
> Please provide a test case. Specifically, I need to know what
> language dialect this is using, because I have tested including math.h
> and calling isnan(double) with c89, gnu89, c99, c11, c++03 and c++11
> on gcc (for the modes that it supports) and clang.
I get the following results with and without -std=c++11 and/or
-stdlib=libc++:
% cat isnan.cc
#include
int main() {
const double d = 42.0;
return isnan(d) ? 1 : 0;
}
% clang++ isnan.cc
isnan.cc:4:10: error: controlling expression type 'const double' not
compatible with any generic association type
return isnan(d) ? 1 : 0;
^~~~
/usr/include/math.h:109:2: note: expanded from macro 'isnan'
__fp_type_select(x, __inline_isnanf, __inline_isnan,
__inline_isnanl)
^
/usr/include/math.h:86:49: note: expanded from macro '__fp_type_select'
#define __fp_type_select(x, f, d, ld) _Generic((0,(x)),
\
^
1 error generated.
___
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"
Re: CURRENT: CLANG 3.3 and -stad=c++11 and -stdlib=libc++: isnan()/isninf() oddity
Pasi Parviainen writes: > On 13.7.2013 13:12, David Chisnall wrote: >> On 12 Jul 2013, at 22:47, "O. Hartmann" wrote: >> >>> Obviously not really fixed, but even worse: >>> >>> if I use in C code (C99, using clang 3.3 on FreeBSD 10.0-CURRENT/amd64 >>> revision 253287) isnan(x) where x is a "const double", I receive now >>> the following error (which doesn't appear on previous versions): >> >> Thanks. This is now fixed, however the _Generic() usage that we had there >> is also present in tgmath.h, and so this file will also need to be fixed in >> the same way. >> >> I've now tested the macros with clang/c99, clang/c11, clang/c++98 and >> clang/c++11, and gcc/c89 and they all seem to work for unqualified, const, >> volatile, and const-volatile qualified types. >> >> I've added Ed to the cc: list, as he wrote this code in tgmath.h. >> >> David >> > > Instead of listing all possible type qualifier combinations (like in > r253319), how about using a comma operator to strip away type > qualifiers? Since only the result type of the expression matters and > it isn't evaluated at all. > > like: > > #define __fp_type_select(x, f, d, ld) _Generic((0,(x)), This seems to have been committed in r253321, and broke some code that was working with r253320; namely, some code in x11/kde4-workspace includes math.h and calls isnan() with a const double. ___ 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"
Re: where is the startkde file of kde4
Robin Lehrmann writes: > Now I want to start it but I don't find the start script in > /usr/local/kde4/bin According to x11/kde4-workspace's plist, you should have both startkde and startkde4 in /usr/local/kde4/bin. > how can I set the display or start kde4? Have you followed the instructions in the handbook [1]? [1] http://www.freebsd.org/doc/en_US.ISO8859-1/books/handbook/x11-wm.html ___ 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"
Re: VAIO intel i7 Ivy Bridge ultrabook installation fail: Disks not found
Nicolas Alexander Scheibling writes: > As it stands now, I would absolutely love installing some 10-CURRENT on > my newly acquired SONY VAIO ultrabook. AFAIK powered by Ivy Bridge ULV, > 1.9 - 2.3 GHz. It has an additional SATA 32 GB Samsung SSD and a > regular 500 GB HDD. It comes with Win 8, cannot stand the Metro. > (although Elan Touchscreen is nice). > > I installed world from my old-beater AMD box on a USB pen drive (i386). > Now it loads the kernel, but won't let me mount any root file systems. > Looks like the platter isn't detected at all. Is that a common problem > with Ivy Bridge systems? I have a Vaio Ultrabook with similar specs and am currently running 10-CURRENT on it. Please provide more details, such as what messages are you getting etc. Have you also tried a fresh install from a CD or USB stick? > Is it a deliberate chipset flaw by Intel as in *this low-end lappy is > not allowed to run anything else than WIN* or can I do something about > it? I wouldn't call an i7 low-end... ___ 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"
