daily CVS update output
Updating src tree: P src/sys/arch/evbarm/fdt/fdt_machdep.c P src/sys/arch/mips/mips/pmap_machdep.c P src/sys/arch/powerpc/booke/booke_pmap.c P src/sys/uvm/pmap/pmap.c P src/sys/uvm/pmap/pmap.h P src/tests/usr.bin/xlint/lint1/d_init_pop_member.c P src/tests/usr.bin/xlint/lint1/d_init_pop_member.exp P src/tests/usr.bin/xlint/lint1/msg_184.c U src/tests/usr.bin/xlint/lint1/msg_184.exp P src/usr.bin/xlint/lint1/cgram.y P src/usr.bin/xlint/lint1/decl.c P src/usr.bin/xlint/lint1/externs1.h P src/usr.bin/xlint/lint1/init.c P src/usr.bin/xlint/lint1/lint1.h P src/usr.bin/xlint/lint1/tree.c Updating xsrc tree: Killing core files: Updating tar files: src/top-level: collecting... replacing... done src/bin: collecting... replacing... done src/common: collecting... replacing... done src/compat: collecting... replacing... done src/crypto: collecting... replacing... done src/dist: collecting... replacing... done src/distrib: collecting... replacing... done src/doc: collecting... replacing... done src/etc: collecting... replacing... done src/external: collecting... replacing... done src/extsrc: collecting... replacing... done src/games: collecting... replacing... done src/gnu: collecting...pax: Unable to access src/gnu (No such file or directory) pax: WARNING! These file names were not selected: src/gnu done src/include: collecting... replacing... done src/lib: collecting... replacing... done src/libexec: collecting... replacing... done src/regress: collecting... replacing... done src/rescue: collecting... replacing... done src/sbin: collecting... replacing... done src/share: collecting... replacing... done src/sys: collecting... replacing... done src/tests: collecting... replacing... done src/tools: collecting... replacing... done src/usr.bin: collecting... replacing... done src/usr.sbin: collecting... replacing... done src/config: collecting... replacing... done src: collecting... replacing... done xsrc/top-level: collecting... replacing... done xsrc/external: collecting... replacing... done xsrc/local: collecting... replacing... done xsrc: collecting... replacing... done Updating release-8 src tree (netbsd-8): Updating release-8 xsrc tree (netbsd-8): Updating release-8 tar files: src/top-level: collecting... replacing... done src/bin: collecting... replacing... done src/common: collecting... replacing... done src/compat: collecting... replacing... done src/crypto: collecting... replacing... done src/dist: collecting... replacing... done src/distrib: collecting... replacing... done src/doc: collecting... replacing... done src/etc: collecting... replacing... done src/external: collecting... replacing... done src/extsrc: collecting... replacing... done src/games: collecting... replacing... done src/gnu: collecting...pax: Unable to access src/gnu (No such file or directory) pax: WARNING! These file names were not selected: src/gnu done src/include: collecting... replacing... done src/lib: collecting... replacing... done src/libexec: collecting... replacing... done src/regress: collecting... replacing... done src/rescue: collecting... replacing... done src/sbin: collecting... replacing... done src/share: collecting... replacing... done src/sys: collecting... replacing... done src/tests: collecting... replacing... done src/tools: collecting... replacing... done src/usr.bin: collecting... replacing... done src/usr.sbin: collecting... replacing... done src/config: collecting... replacing... done src/x11: collecting...pax: Unable to access src/x11 (No such file or directory) pax: WARNING! These file names were not selected: src/x11 done src: collecting... replacing... done xsrc/top-level: collecting... replacing... done xsrc/external: collecting... replacing... done xsrc/local: collecting... replacing... done xsrc/xfree: collecting...pax: Unable to access xsrc/xfree (No such file or directory) pax: WARNING! These file names were not selected: xsrc/xfree done xsrc: collecting... replacing... done Updating release-9 src tree (netbsd-9): Updating release-9 xsrc tree (netbsd-9): Updating release-9 tar files: src/top-level: collecting... replacing... done src/bin: collecting... replacing... done src/common: collecting... replacing... done src/compat: collecting... replacing... done src/crypto: collecting... replacing... done src/dist: collecting... replacing... done src/distrib: collecting... replacing... done src/doc: collecting... replacing... done src/etc: collecting... replacing... done src/external: collecting... replacing... done src/extsrc: collecting... replacing... done src/games: collecting... replacing... done src/include: collecting... replacing... done src/lib: collecting... replacing... done src/libexec: collecting... replacing... done src/regress: collecting... replacing... done src/rescue: collecting... replacing... done src/sbin: collecting... replacing... done src/share: collecting... replacing... done src/sys: collecting... replacing... done src/tests: collecting... replacing... done
Re: How to determine if graphics is supported by radeondrm?
HI all, On 18/03/21 10:03 am, Rhialto wrote: For example, if I look at an "AMD Ryzen 3" cpu, which supposedly has integrated graphics "AMD Radeon Vega 8, integrated GPU". Grepping -i for "Vega" in src/sys/external/bsd/drm2/dist/drm yields no results; I take it this is a bad sign? I booted a live image of 9.1 that I found on my Ryzen 3 laptop and it ends up running the Vesa driver with the "llvmpipe" OpenGL renderer. The Xorg log file shows that X thought about the AMD driver, but ended up using the VESA one. The log shows a long list of AMD GPU models, which looks like Xorg's way of saying that it doesn't know what model of AMD GPU I have. Linux says the laptop has "AMD Ryzen 3 3300U with Radeon Vega Mobile Gfx" and Google tells me this is a Picasso/Radeon Vega 6. I found the file amdgpu_device.c with the amdgpu_asic_name definition at the top. NetBSD has many, many entries missing from this list. :-( I also tried my Intel based laptop, but I only had an MBR image and HP seemed to have removed the old BIOS boot option in their newer firmware so I couldn't even boot the image. Lloyd
Re: still a problem with gpt(8) reading from LVM volumes? (was: problems with GPT (and maybe dkctl wedges) on LVM volumes)
Date:Thu, 18 Mar 2021 18:44:14 -0700 From:"Greg A. Woods" Message-ID: | I'm still not quite sure why gpt(8) can't show me the full partition | table when reading from a raw LVM volume (dm) device as above in exactly | the same way it does when reading from the raw (xbd emulated) disk in | the domU. I don't know much about LVM, but I suspect that the dm has some extra structure that is needed to manage its lvm sub-devices, which isn't present in a physical drive, or an emulated physical drive like an xbd. We have two kinds of things that present a somewhat disk like interface (random access to a large number of fixed sized blocks) - those are actual disk drives (virtual or physical) and logical partitions (filesystem devices). The latter are simply an array of blocks, with no structure other than whatever the filesystem used imposes on them. The former have labels which can divide the device into a number of the latter, which are then what gets used. xdb (and sd wd vnd cgd ccd raid) are all devices. dk ld and lvm (and maybe some more) and sdNa (partitions from a disklabel) are all partitions. gpt (and disklabel, fdisk) only work on devices, not partitions (technically, I guess they could be used on a partition, or could be coerced to work that way, but nothing would use the label they install). A partition can be turned into a device by running a "filesystem" in it which presents a device interface (raid, ccd, cgd, also passing it to a DomU where it becomes an xbd is the same). Then you can add a label (any appropriate one of the 3 supported). Similarly, you can make a file in a filesystem, and then make that a "device" with vnd. Unfortunately, the terminology is very murky, from the way things developed historically, and all these things tend to be called "disk" in some situations or other (ie: originally filesystems went on disks, then disks grew partitions, which hold filesystems, but filesystems went on disks, so the partitions must be disks, right?) What I do for my systems is not use sysinst on DomU's, instead I make however many partitions I need in the Dom0, extract (or more commonly build with their structure mounted as RELEASEDIR) then unmount from the Dom0 and pass the partitions used as separate "drives" to the DomU. When the DomU is running, it has access to the partitions as any number of drives (from 1 (root) for simple tests, to quite a few if I am doing some kind of pkgsrc building). When it isn't running the partitions become available to be mounted on the Dom0 (or a different DomU ... these days I use one DomU to build into a RELEASEDIR which is a separate xbd and which becomes the root of the new DomU) and whatever I need to do there (including analysis of crashes, config setups, etc) can be done. I do no division (no internal partitions) of the xbd drives inside the DomU - there it just sees the fake label that the kernel invents when it sees an unlabelled drive. There is no real advantage of having a single xbd that is partitioned, over several different xbds. That is, unless I was doing sysinst testing, then of course things would be done differently. kre
Re: still a problem with gpt(8) reading from LVM volumes? (was: problems with GPT (and maybe dkctl wedges) on LVM volumes)
On Mar 19, 6:02, Michael van Elst wrote:
} wo...@planix.ca ("Greg A. Woods") writes:
} >At Fri, 12 Mar 2021 14:02:06 -0800, I wrote:
} >>
} >> # gpt -vvv show -a /dev/mapper/rvg0-nbtest.0
} >> /dev/mapper/rvg0-nbtest.0: mediasize=41943040; sectorsize=512; blocks=81920
} >> /dev/mapper/rvg0-nbtest.0: PMBR at sector 0
} >> /dev/mapper/rvg0-nbtest.0: Pri GPT at sector 1
} >> /dev/mapper/rvg0-nbtest.0: GPT partition: type=ffs, start=64, size=41942943
} >> gpt: /dev/mapper/rvg0-nbtest.0: map entry doesn't fit media: new start +
new size < start + size
} >> (22 + 13fde < 40 + 27fff9f)
}
} >I'm still not quite sure why gpt(8) can't show me the full partition
} >table when reading from a raw LVM volume (dm) device as above in exactly
} >the same way it does when reading from the raw (xbd emulated) disk in
} >the domU.
}
} gpt sees that the medium has only 41MByte and the partition exceeds that
} and bails out.
gpt(8) is basically an exercise in linked list manipulation
where each node represents a partition. It looks like a first year
compsci exercise where the assignment was to find a practical use
for a linked list. Partitions must be monotonically increasing
with no overlap and fit on the disk. This means that it is extremely
inflexible and can not handle any form of corruption, which means
that it can not be used to fix said corruption.
One of the projects I have in mind is to replace the data
structure. One good thing about the program is that all manipulation
of the data structure is done through access routines and is
appropriately contained in map.c and map.h. One thing that is
slowing me down is thinking of an appropriate data structure for
tracking allocated space (the current method gets this pretty much
for free). One tradional way to do this would be to use a bitmap,
but with the size of modern disks, that is completely infeasible.
Note that whatever method is chosen must be able to handle duplicate
allocations (i.e. overlapping partitions).
}-- End of excerpt from Michael van Elst
Re: still a problem with gpt(8) reading from LVM volumes? (was: problems with GPT (and maybe dkctl wedges) on LVM volumes)
wo...@planix.ca ("Greg A. Woods") writes:
>At Fri, 12 Mar 2021 14:02:06 -0800, I wrote:
>Subject: problems with GPT (and maybe dkctl wedges) on LVM volumes
>>
>> # gpt -vvv show -a /dev/mapper/rvg0-nbtest.0
>> /dev/mapper/rvg0-nbtest.0: mediasize=41943040; sectorsize=512; blocks=81920
>> /dev/mapper/rvg0-nbtest.0: PMBR at sector 0
>> /dev/mapper/rvg0-nbtest.0: Pri GPT at sector 1
>> /dev/mapper/rvg0-nbtest.0: GPT partition: type=ffs, start=64, size=41942943
>> gpt: /dev/mapper/rvg0-nbtest.0: map entry doesn't fit media: new start + new
>> size < start + size
>> (22 + 13fde < 40 + 27fff9f)
>I'm still not quite sure why gpt(8) can't show me the full partition
>table when reading from a raw LVM volume (dm) device as above in exactly
>the same way it does when reading from the raw (xbd emulated) disk in
>the domU.
gpt sees that the medium has only 41MByte and the partition exceeds that
and bails out.
That's a bug in the dm driver:
dm_table_disksize(>table_head, , NULL);
*valp = numsec;
It reports the number of blocks (sectors) and should report the
number of bytes.
An untested patch would be:
Index: device-mapper.c
===
RCS file: /cvsroot/src/sys/dev/dm/device-mapper.c,v
retrieving revision 1.61
diff -p -u -r1.61 device-mapper.c
--- device-mapper.c 8 Jul 2020 15:07:13 - 1.61
+++ device-mapper.c 19 Mar 2021 06:00:03 -
@@ -515,14 +515,15 @@ disk_ioctl_switch(dev_t dev, unsigned lo
{
off_t *valp = data;
uint64_t numsec;
+ unsigned secsize;
if ((dmv = dm_dev_lookup(NULL, NULL, minor(dev))) == NULL)
return ENODEV;
aprint_debug("DIOCGMEDIASIZE ioctl called\n");
- dm_table_disksize(>table_head, , NULL);
- *valp = numsec;
+ dm_table_disksize(>table_head, , );
+ *valp = numsec * secsize;
dm_dev_unbusy(dmv);
break;
--
--
Michael van Elst
Internet: mlel...@serpens.de
"A potential Snark may lurk in every tree."
