On Sun, Feb 02, 2020 at 01:10:33PM -0500, MLH wrote:
[...]
> $ mount NAME=raid@ZFN15G3N /mnt
> WARNING: autoselecting nfs based on : or @ in the device name is deprecated!
> WARNING: This behaviour will be removed in a future release
> mount_nfs: no : or @ spec
> $ mount /dev/raid0a /mnt
>
On Wed, Oct 02, 2019 at 11:31:32AM +, m...@netbsd.org wrote:
> I had to change a lot of installers and images in distrib/, I hope I
> didn't miss one. Let me know if one doesn't install /rescue now.
Nice. Is it possible to push it into netbsd-9?
--
Piotr 'aniou' Meyer
On Fri, Apr 26, 2019 at 12:02:05AM +0200, Thomas Klausner wrote:
[...]
> Why are not all the fonts available for loading with wsfontload (i.e.,
> installed into /usr/share/wscons/fonts)?
Good question. At this moment there are following mapping between
loadable and built-in font files:
On Sun, Apr 21, 2019 at 08:38:17AM +0200, Martin Husemann wrote:
[...]
> It is way too big on my old 14" pinebook too, we need a better selection
> algorithm (or maybe there is a bug, I'll check resulting rows/columns
> with the default font next week).
To be honest, before that commit I
On Tue, Apr 23, 2019 at 04:38:31PM +0100, Chavdar Ivanov wrote:
> Update - it now works fine for me.
Now, updated module works fine for me too.
Regards,
--
Piotr 'aniou' Meyer
On Wed, Apr 17, 2019 at 01:13:50PM +0100, Chavdar Ivanov wrote:
[...]
> The problem I am having is with NetBSD-current, amd64. I am able to
> install it and run it with the default accelleration, which is
> obviously very slow (perhaps 20-30 times, I haven't measured). If I
> use nvmm, I
On Sun, Apr 21, 2019 at 08:38:17AM +0200, Martin Husemann wrote:
[...]
> It is way too big on my old 14" pinebook too, we need a better selection
> algorithm (or maybe there is a bug, I'll check resulting rows/columns
> with the default font next week).
Just for curiosity - from where is
On Sat, Apr 20, 2019 at 09:51:10AM +, m...@netbsd.org wrote:
[...]
> It does make it bigger. How big are we talking? picture?
Hi,
it is very hard to show that by a picture, it is very dependent of
particular, physical install - but maybe this photo will be sufficient: [1]
>From the other
Hi,
> P src/sys/arch/amd64/conf/GENERIC
> P src/sys/arch/amd64/conf/INSTALL
In following commit[1] two new optios was added:
# Give us a choice of fonts based on monitor size
options FONT_BOLD8x16
options FONT_BOLD16x32
Unfortunately FONT_BOLD16x32 is too big for lower-PPI
On Mon, Feb 18, 2019 at 11:23:28PM +0100, Piotr Meyer wrote:
[...]
> and then I mounted that dir with mount_union over /dev:
>
> mkdir /tmp/dev
> cd /tmp/dev
> mknod dk16 b 168 16
> mknod rdk16 c 168 16
> ...
> mount_union /tmp/dev /dev
BTW: a working alternative exists
Hi,
I got a panic during a kind of exotic install try of -current (8.99.34)
on amd64. Due to large number of GPT partitions I quickly got a total of
19 wedges (up to dk18) with only 16 of them available in /dev (install/53992).
Manual mknod in /dev/ wasn't possible due to r/o filesystem
On Sun, Oct 26, 2014 at 10:28:28PM +, Michael van Elst wrote:
an...@smutek.pl (Piotr Meyer) writes:
'Generally good' is probably fair and true statement - but as long as
You don't try 'extended partitioning' on GPT disk.
How did you try to do this?
Oh, it was really simple
On Wed, Oct 22, 2014 at 11:37:28PM -0700, Soren Jacobsen wrote:
As you may have noticed, the NetBSD 7.0 release process is underway. A
lot of great work has gone into NetBSD since 6.0, and we're very excited
about this upcoming release.
The state of the branch is generally good at this
On Mon, Aug 18, 2014 at 02:28:02AM -0400, Christos Zoulas wrote:
[...]
If things don't work for you, please file a PR with a description of your
setup and how it fails, so we can fix it.
I have had some troubles with GPT setup I migrate my -current to
separate GPT partitions and wedges but
On Fri, Aug 15, 2014 at 08:03:14PM +0200, Piotr Meyer wrote:
[...]
Ok, as Taylor said:
The real problem here is that the GPU is hanging, and I don't know why
that is. The panic you saw is due to a locking mistake which should
be easy to fix, but I haven't had time to identify all
On Thu, Aug 14, 2014 at 07:09:46PM +0200, Piotr Meyer wrote:
Ivy Bridge integrated GPU, fresh sources:
1. Now, I got valid resolution on console and in X (1280x1024).
Much better. ;)
2. glxgears leads to panic, after ddb.onpanic=1 I got:
Some additional debug info, hope this helps
On Fri, Aug 08, 2014 at 07:49:56AM -0700, Jeff Rizzo wrote:
[...]
Lots of good progress has been made - expect the branch to be
created within the next 2 or 3 days.
Is there chance for dealing with latest Ivy Bridge KMS regressions
before branching?
Also, if I have understood correctly,
Ivy Bridge integrated GPU, fresh sources:
1. Console - as in previous cases - has valid resolution (1280x1024) but
X starts in 1024x768
2. After short work in X whole system crashes with:
Jul 26 22:34:19 dodo savecore: reboot after panic: panic: kernel
diagnostic assertion
My Ivy Bridge integrated GPU, sources from today, but still no banana. :(
1. X got resolution 1024x768 on 1280x1024 screen
2. glxgears causes crash:
Jul 19 12:54:07 dodo aniou: glxgears start
Jul 19 12:55:08 dodo syslogd[147]: restart
Jul 19 12:55:08 dodo /netbsd: drm: stuck on render ring
Jul
Today I got working console and X (stable, as I assume - Firefox works
without troubles) on 6.99.44. I noticed problems with glxinfo, although
working X was most important target.
Graphics card: HD Graphics 2500 embedded into Pentium G2030 (Ivy Bridge).
Full log (uname, dmesg, Xorg.0.log,
20 matches
Mail list logo
