note: mips malta kernels now support up to 2gb of RAM
hiya, I've just added support to our malta implementation to handle RAM up to 2G. The qemu-system-mips* support for malta is limited to a max of 2G. It used to be limited to 256MB RAM. This is useful for 32 bit mips as it gives us a stress test for the non-all-direct-mapped case of > 256MB RAM. This means we can get much more coverage for VM/pmap changes on mips32 and mips64. (It also makes compiling a lot easier, as it's not constantly paging. :-) Note: due to "math", you can't use 2048MB of RAM as your specification on 32 bit MIPS;, you need to specify just a touch below 2 gig or the math overflows a 32 bit paddr value and you only get 256MB of RAM. I'll go fix this at some point soon. This now makes mips32/mips64 testing much nicer. :-) Next up - why SMP doesn't work! Thanks, -a ___ 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: /bin/ls formatting broken for non-C(?) locales
On 21.11.2015 15:18, Ed Schouten wrote: > Hi Baptiste, > > I suppose you should use the wcswidth() function somewhere to compute > the visible width of the month name. Some characters may be > double-width, others may have no effective width at all. > I agree. Checking error return of wide chars functions with some fallback will be good too. -- http://ache.vniz.net/ ___ 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: /bin/ls formatting broken for non-C(?) locales
Hi Baptiste, I suppose you should use the wcswidth() function somewhere to compute the visible width of the month name. Some characters may be double-width, others may have no effective width at all. -- Ed Schouten Nuxi, 's-Hertogenbosch, the Netherlands KvK-nr.: 62051717 ___ 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: EFI and i915kms questions
On 13/11/2015 18:15, Joe Maloney wrote: > Hello, Hi! > Sometime after changes in FreeBSD 10-STABLE, 10.2 onwards, and > recent 11 CURRENT the resolution no longer sets properly when using > UEFI boot. It now boots with a 640x480 resolution, and kldload > i915kms results in a black screen. I have not been able to grab a > debug log, or crash dump even with all of the debugging features > turned on. I cannot ssh into the laptop when this panic occurs, and > the screen is black so I can’t really see what happened. I’m curious > if there is anything else I can do besides enabling dumpdev or > kldload -v i915kms > output.txt that doesn’t give me any detail. > Nothing shows up in /var/crash or whatever the directory was. You could try to set debug.debugger_on_panic=0 in /etc/sysctl.conf. It often helps to at least get core dumps when the crash happens in a video driver. -- Jean-Sébastien Pédron signature.asc Description: OpenPGP digital signature
libxofication of FreeBSD kernel ? 201506DevSummit
Hi all, At the following URL: https://wiki.freebsd.org/201506DevSummit/libxo the listed agenda of libxo working group include the following topic of discussion: Discussion: libxo in the kernel. - Can someone please explain exactly what happens here ? Who pushed this agenda , regarding libxo in kernel, and what was discussed ? For me it is worrisome that such a topic of discussion even exists. It is my opinion that engineers should strive to simplify a kernel, even reduce their size in LOC where possible, not adding complexity, especially totally unjustified complexity. But I would like to hear the whole story before passing judgment on the issue. Dan ___ 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"
