Re: suspend-to-RAM intel-x86 issues and tests
Hi David, David Brownlee wrote: So I conclude that having the system mounted on USB causes issues (which manifests themselves slightly different on different computers) and while it probably should work, it is not a test and adds more issues. Would it be make sense to try booting a CD install image on some of the machines (to avoid the USB) issue? for those machines which have an optical drive, I can do so! To help NetBSD improve, this and more. Would using the install CD enough to test an ACPI suspend? is it enabled at all? Install CDs though do not usually enable DRM console, which is often a problematic component in sleep. In any case, three ThinkPads have netbsd8 release on it, so testing is easier and they exhibit issues: T30, R51 and T43 (the latter with a regression compared to release). SO perhaps it is best fixing those first, before attempting more delicate work on others. For some tests I could even swap Hard Disk, it is just a bit cumbersome. Riccardo
Re: BSD disklabel partition letters in NetBSD
rockyho...@post.com ("Rocky Hotas") writes:
>Do you mean that who generates disklabel collects information about the
>disk, cylinders, etc. and creates a brand new data structure? I can't
>understand what you are referring to as "other information".
The driver provides a 'default label' based on information like cylinders.
Then the disk is searched for an MBR (to find the NetBSD partition type 169).
If this is found, it searches for a disklabel in that partition, otherwise
it computes a disklabel based on MBR partitions and continues to look for
a disklabel at the beginning of the disk.
Some non-MBR-based platforms have additional heuristics to read other
kinds of partitioning information, e.g. an Amiga "Rigid Disk Block".
>For the sake of completeness, let's consider another case, hopefully
>interesting to others. If you decide to install on the same disk two or more
>BSD systems, all compatible with BSD disklabel (for example, two different
>versions of NetBSD, or NetBSD and FreeBSD), would that unique BSD disklabel
>in sector 1 of the disk be able to handle this?
I guess you can have NetBSD and FreeBSD using different partitions but
the same disklabel on a single disk. OpenBSD did change the disklabel
format to support larger disks, so that probably conflicts.
Wether you can have a bootloader on that disk that handles different
systems is another question. But for data disks that's not a problem.
>In all the examples I've seen, this data structure is conceived to describe
>only a single system, with one root partition (and then optional separate
>partitions as /home, /var, /usr according to the administrator's choice, but
>all referred to the same root). Multiple OSs would mean multiple root
>partitions.
Yes. But it's possible to boot NetBSD using a partition different from 'a'.
>However, it would be very odd if, in order to allow the existence of
>multiple BSD OSs, a third-party partitioning scheme as MBR would be needed.
You don't need an MBR to make the disk accessible.
On x86 hardware you do need an MBR just for being able to boot an OS,
and I'm not even talk about UEFI, just about plain old BIOS.
--
--
Michael van Elst
Internet: mlel...@serpens.de
"A potential Snark may lurk in every tree."
Re: BSD disklabel partition letters in NetBSD
> Sent: Tuesday, September 25, 2018 at 11:51 PM > From: "Don NetBSD" > To: netbsd-users@netbsd.org > Subject: Re: BSD disklabel partition letters in NetBSD [...] > But it isn't placed in any of these places unless/until the system is > DIRECTED to do so. I.e., you can access a brand-new, never-before-powered-on > disk drive via the fictitious IN-KERNEL disklabel STRUCTURE. But, need > never actually write it to the medium to allow such access (on a NetBSD box). IIUC, this is a subtle (but important) clarification. > [I.e., write the entire medium -- except the label portion -- and mount it on > some foreign OS and they won't see ANY label in place! But, the DATA that > you wrote will still be there!] Yes, of course other OSs won't show anything! Amazing :). Rocky
Re: BSD disklabel partition letters in NetBSD
> Sent: Tuesday, September 25, 2018 at 7:52 PM > From: "Michael van Elst" > To: "Rocky Hotas" > Cc: netbsd-users@netbsd.org > Subject: Re: BSD disklabel partition letters in NetBSD > [...] > disklabel is a data structure. If there is none on the disk, it is > generated from other information. Do you mean that who generates disklabel collects information about the disk, cylinders, etc. and creates a brand new data structure? I can't understand what you are referring to as "other information". > With MBR, the disklabel is usually placed on relative sector 1 of > the MBR partition tagged as 'NetBSD' (type 169). > > Without MBR, it is placed on absolute sector 1 of the medium. > > N.B. the sector number can also be platform dependent, most use sector 1 > but some use other sectors. Ok! Very clear. For the sake of completeness, let's consider another case, hopefully interesting to others. If you decide to install on the same disk two or more BSD systems, all compatible with BSD disklabel (for example, two different versions of NetBSD, or NetBSD and FreeBSD), would that unique BSD disklabel in sector 1 of the disk be able to handle this? In all the examples I've seen, this data structure is conceived to describe only a single system, with one root partition (and then optional separate partitions as /home, /var, /usr according to the administrator's choice, but all referred to the same root). Multiple OSs would mean multiple root partitions. However, it would be very odd if, in order to allow the existence of multiple BSD OSs, a third-party partitioning scheme as MBR would be needed. If these questions can be answered by reading some documentation or some other source and you know the link, I would check it out (unfortunately I found almost nothing about this). > wedges are an abstraction that can be used for arbitrary partitioning > schemes, GPT is the most popular. But I use it for everything, including > disks that uses the BSD disklabel (you need a custom kernel for that). Ok! Again, thank you so much! Rocky > > > Greetings, > -- > Michael van Elst > Internet: mlel...@serpens.de > "A potential Snark may lurk in every tree." >
Re: suspend-to-RAM intel-x86 issues and tests
On Wed, 26 Sep 2018 at 22:34, Riccardo Mottola wrote: > > Hi All > > I did a Big ACPI/SLEEP compariso (or at least, tried to): > [...] > > So I conclude that having the system mounted on USB causes issues (which > manifests themselves slightly different on different computers) and > while it probably should work, it is not a test and adds more issues. Would it be make sense to try booting a CD install image on some of the machines (to avoid the USB) issue? David
Re: i915
On Sun, Sep 23, 2018 at 9:02 AM wrote: > If you are using netbsd-current, it will probably have support, but xorg > needs some workarounds for now: > - Build pkgsrc xorg deleting old packages, setting X11_TYPE=modular, > build meta-pkg/modular-xorg and start /usr/pkg/bin/startx. > - Get pkgsrc-wip, and build wip/xf86-video-intel-git to replace > x11/xf86-video-intel. > - Now it will work I just wanted to report back that this procedure has resulted in my dev machine (Intel NUC) getting a graphical framebuffer and accelerated X. XFCE and Firefox feel a lot snappier than with VESA graphics! Thanks for making this finally work. Note that Skylake graphics (Intel Iris Pro) only got support two weeks ago in -current, so it needs to be a recent kernel. -- Benny
