Re: configuring raid using gpt, large drives
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 > mount_ffs: /dev/raid0a on /mnt: Device not configured It is rather long shoot and I'm not pretty sure about that, but at first I suggest to remove '@' sign from GPT partition names and wedge names. It leads to conflict with NFS scheme at least in mentioned case and I affraid, that there are other places to fail. Personally I use gpt drives and wedges from 7.0_BETA and raid setup on GPT partition tables from 8.0 - 9.0_RC (now). My setup consist of the following components: = 1. wd0 and wd1 - both GPT partitioned, each with small EFI boot partition, previously used for EFI-compatible bootloader. There was a bug with memory mapping there, so I use grub now (bug is probably fixed but I didn't verified it so far): # gpt show -al wd0 # for grub 20484096 1 GPT part - BIOS Boot Type: bios TypeID: 21686148-6449-6e6f-744e-656564454649 GUID: 4b409213-4d0d-3448-8835-e25ba083dad9 Size: 2048 K Label: bios1 Attributes: None ... # for EFI (efi1 on wd0 and efi2 on wd1) 293607424 1126400 4 GPT part - EFI System Type: efi TypeID: c12a7328-f81f-11d2-ba4b-00a0c93ec93b GUID: a0f50318-d84d-da4f-be1a-bed65411c09e Size: 550 M Label: efi1 Attributes: None 29473382483886080 5 GPT part - NetBSD RAIDFrame component Type: raid TypeID: 49f48daa-b10e-11dc-b99b-0019d1879648 GUID: 6609f622-26ac-e049-a10a-4e90fc9e0cfd Size: 40960 M Label: netsys1 Attributes: None ... = 2. three raid sets, created from three pairs of gpt partitions [10.990214] raid0: Components: /dev/dk4 /dev/dk12 [10.990214] raid1: Components: /dev/dk5 /dev/dk13 [11.010222] raid2: Components: /dev/dk6 /dev/dk14 = 3, there is a GPT partition table, created on each raid set(!), see: # gpt show -al raid0 40 2097152 1 GPT part - NetBSD FFSv1/FFSv2 Type: ffs TypeID: 49f48d5a-b10e-11dc-b99b-0019d1879648 GUID: 8dda46b0-c667-4314-9d6e-8470bf03330e Size: 1024 M Label: root Attributes: None 2097192 4194304 2 GPT part - NetBSD FFSv1/FFSv2 Type: ffs TypeID: 49f48d5a-b10e-11dc-b99b-0019d1879648 GUID: 1fd5c641-51f9-4aca-998a-258b613dea2a Size: 2048 M Label: var Attributes: None ... gpt show -al raid2 40 419430192 1 GPT part - NetBSD FFSv1/FFSv2 Type: ffs TypeID: 49f48d5a-b10e-11dc-b99b-0019d1879648 GUID: fc736297-4256-4bf7-934e-0d614e8509ff Size: 200 G Label: home Attributes: None = 4. All partitions are mounted by name: # NAME=root / ffs rw 1 1 NAME=var /var ffs rw,log 1 2 NAME=usr /usr ffs rw,log 1 2 NAME=home /home ffs rw,log 1 2 NAME=swap none swap sw 0 0 NAME=efi1 /mnt/efi1 msdos rw,noauto 0 0 NAME=efi2 /mnt/efi2 msdos rw,noauto 0 0 = 5. Boot process looks like following. As You can see system is able to assemble raid devices and scan them for gpt partition tables. [ 2.817072] dk3 at wd0: "efi1", 1126400 blocks at 293607424, type: msdos [ 2.817072] dk4 at wd0: "netsys1", 83886080 blocks at 294733824, type: raidframe [ 2.817072] dk5 at wd0: "netswap1", 18874368 blocks at 378619904, type: raidframe [ 2.817072] dk6 at wd0: "nethome1", 419430400 blocks at
Re: /rescue is a separate set now
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
Re: (too) big font on console?
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: loadable builtin --- donna.816 - flori.816 - orator.816- latin2.808- latin2.814- latin2.816- vt220h.808- vt220h.810- vt220h.814- vt220h.816- vt220l.808vt220l8x8.h vt220l.810vt220l8x10.h vt220l.814- vt220l.816vt220l8x16.h - although a http://cvsweb.netbsd.org/bsdweb.cgi/xsrc/local/programs/ttf2wsfont/ tool looks to be able to create font binary files alongside of .h-ones during conversion. BTW: I was somewhat surprised by existence dedicated font format in NetBSD: https://nxr.netbsd.org/xref/src/usr.sbin/wsfontload/wsfontload.c#213 Regards, -- Piotr 'aniou' Meyer
Re: (too) big font on console?
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 wasn't aware that enabling multiple fonts at once is possible and supported ;) It motivated me to revive long-postponed project of making screenshots of all available console fonts. Fortunately, with qemu-nvmm it was easy. Results are available at: http://smutek.pl/netbsd/wsfont/ (semi-automatic gallery is available at http://smutek.pl/netbsd/wsfont/gallery/) Summary: 1. There are two definitions in wsfont.c without font data: FONT_ISO8x16 and FONT_COURIER11x18 2. There are many font definitions with overlapping names, I made some quick changes to work around them, see diff - but also look at next point. diff: http://smutek.pl/netbsd/wsfont/wsfont-unique-names1.diff 3. I'm not sure about spaces in font names, it makes shell scripting (i.e. wsconsctl -dw font=$fontname) awful. Maybe changes like "Droid Sans Mono 12x22" to something like "DroidSansMono-12x22" or "Droid_Sans_Mono-12x22" will be reasonable? 4. Currently there are following fonts available, maybe it will be worthwhile to add them to ALL configs when it is reasonable for particular port? # left-to-right bit order fonts options FONT_BOLD16x32 options FONT_BOLD8x16 options FONT_DEJAVU_SANS_MONO12x22 options FONT_DROID_SANS_MONO12x22 options FONT_DROID_SANS_MONO19x36 options FONT_DROID_SANS_MONO9x18 options FONT_GALLANT12x22 options FONT_GLASS10x19 options FONT_GLASS10x25 options FONT_GO_MONO12x23 options FONT_LUCIDA16x29 options FONT_OMRON12x20 options FONT_SONY12x24 options FONT_SONY8x16 options FONT_SPLEEN12x24 options FONT_SPLEEN16x32 options FONT_SPLEEN32x64 options FONT_SPLEEN5x8 options FONT_SPLEEN8x16 options FONT_VT220ISO8x16 options FONT_VT220ISO8x8 options FONT_VT220KOI8x10_KOI8_R options FONT_VT220KOI8x10_KOI8_U options FONT_VT220L8x10 options FONT_VT220L8x16 options FONT_VT220L8x8 # right-to-left bit order font options FONT_QVSS8x15 5. Even on resolution 1280x960 and with all fonts built-in "Boldface 16x32" was selected as default. Regards, -- Piotr 'aniou' Meyer
Re: Running NetBSD-current under qemu-nvmm
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
Re: Running NetBSD-current under qemu-nvmm
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 consistently get a panic as follows:
>
> Making device nodes ...
> [ 141.4547199] fatal protection fault in supervisor mode
> [ 141.4547199] trap type 4 code 0 rip 0x8021e0ea cs 0x8
> rflags 0x10246 cr2 0x7bcebdf892b0 ilevel 0x8 rsp 0x83802b513f98
> [ 141.4547199] curlwp 0xf0e0f6350240 pid 118.1 lowest kstack
> 0x83802b5102c0
> kernel: protection fault trap, code=0
> Stopped in pid 118.1 (sh) at netbsd:xrstor+0xa [xsave]
> db{0}> bt
> xrstor() at netbsd:xrstor+xa
> cpu_switchto() at netbsd:cpu_switchto+0xb1
> db{0}>
>
I can confirm identical behaviour, although in my case panic starts
immediately after issuing any command (ls, dmesg) from shell called
from utility menu:
# ls
[ 18.7037883] fatal protection fault in supervisor mode
[ 18.7037883] trap type 4 code 0 rip 0x8021e0ea cs 0x8 rflags 0x10246
cr2 0x7b3566556000 ilevel 0x8 rsp 0xb20032d32f98
[ 18.7037883] curlwp 0xfdfebae57a60 pid 17.1 lowest
kstack 0xb20032d2f2c0
kernel: protection fault trap, code=0
Stopped in pid 17.1 (sh) at netbsd:xrstor+0xa: fxsavel
db{0}> bt
xrstor() at netbsd:xrstor+0xa
cpu_switchto() at netbsd:cpu_switchto+0xb1
db{0}>
Host kernel:
NetBSD szpak.local 8.99.37 NetBSD 8.99.37 (GENERIC) #1: Fri Apr 19 19:53:45
CEST 2019
aniou@szpak.local:/usr/obj/sys/arch/amd64/compile/GENERIC amd64
Guest:
NetBSD-current, booted from NetBSD-8.99.37-amd64.iso (2019-04-20)
Qemu parameters:
qemu-system-x86_64 \
-netdev tap,id=n0,ifname=tap0,script=no,downscript=no \
-device virtio-net-pci,netdev=n0 \
-device virtio-scsi-pci \
-drive file=/vm/test.qcow2.img,if=none,id=hd0,format=qcow2 \
-device scsi-hd,drive=hd0 \
-m 1024M \
-k en-us \
-accel nvmm \
-display curses \
-cdrom /home/aniou/Downloads/NetBSD-8.99.37-amd64.iso
--
Piotr 'aniou' Meyer
Re: (too) big font on console?
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 selection algorithm called in following case? I dag into wsfont/wsfont.c and found interesting routines (wsfont_matches) but I'm not sure how they are called. I'm thinking about following case: drmkms0 at i915drmkms0 drmkms0: interrupting at ioapic0 pin 16 (i915) i915drmkms0: framebuffer at 0x8000453d5000, size 1920x1080, depth 32, stride 7680 wsdisplay0 at i915drmkms0 kbdmux 1: console (default, vt100 emulation) wsmux1: connecting to wsdisplay0 Best regards, -- Piotr 'aniou' Meyer
Re: (too) big font on console?
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 hand, I changed my mind a little: Spleen family looks ugly (it is a matter of personal taste, of course) and it is better for NetBSD to provide concise font style for all available sizes. BTW: I found commit[2] that suggest that a Terminus font family is double-licensed (BSD and OFL). Unfortunately source package doesn't provide a separate license for BSD, and commits in Free repo aren't concise about licensing[2, 4, 5] (whole package or parts? for FreeBSD or all BSD's?). Terminus[3] itself offers many different sizes and looks really nice. 1 - http://smutek.pl/netbsd/netbsd-bold-16x32.jpg 2 - https://svnweb.freebsd.org/base?view=revision=332452 3 - http://terminus-font.sourceforge.net/ 4 - https://svnweb.freebsd.org/base/head/share/vt/fonts/terminus-b32.hex?view=log 5 - https://lists.freebsd.org/pipermail/svn-src-all/2014-June/086303.html 6 - http://terminus-font.sourceforge.net/shots.html 7 - "Sizes: 6x12, 8x14, 8x16, 10x18, 10x20, 11x22, 12x24, 14x28 and 16x32. Weights: normal and bold (except for 6x12), plus CRT VGA-bold for 8x14 and 8x16" Best regards, -- Piotr 'aniou' Meyer
(too) big font on console?
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 monitors, for example 21" or 23" -ones with resolution 1920x1080. I would like to suggest FONT_SPLEEN12x24 instead. I'm not a fan of spleen font family but this one is still better than SONY12x24. 1 - http://cvsweb.netbsd.org/bsdweb.cgi/src/sys/arch/amd64/conf/GENERIC.diff?r1=1.523=1.524_with_tag=MAIN=h Best regards, -- Piotr 'aniou' Meyer
Re: panic with mount_union in installer
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: cp /dev/MAKEDEV* /tmp/ mount -t tmpfs tmpfs /dev cp /tmp/MAKEDEV* /dev/ cd /dev ./MAKEDEV all mknod dk16 b 168 16 mknod rdk16 c 168 16 ... etc Regards, -- Piotr 'aniou' Meyer
panic with mount_union in installer
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 (cd-image), so I made a directory in tmpfs-mounted /tmp, some device nodes inside 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 1. newfs -O 2 name=... was successful 2. mount name=... /targetroot/... was successful 3. and during untar process I got following panic: http://smutek.pl/netbsd/netbsd-8-99-34-adm64-union-crash.jpg http://smutek.pl/netbsd/netbsd-8-99-34-adm64-union-crash-bt.jpg Regards, -- Piotr 'aniou' Meyer
Re: 7.0_BETA feedback sought
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 and straightforward. I have had a GPT partition made - mostly - from NetBSD. They looks more or less like that (gfdisk format): Number Start (sector)End (sector) Size Code Name 120486143 2.0 MiB EF02 boot_other 3 58572859179007 27.9 GiB8300 xubuntu_root 459179008 234960895 83.8 GiB8300 home 5 234960896 236961791 977.0 MiB A902 netbsd_root 6 236961792 238962687 977.0 MiB A902 netbsd_altroot 7 238962688 246962175 3.8 GiB A902 netbsd_var 8 246962176 254961663 3.8 GiB A901 netbsd_swap 9 254961664 373047295 56.3 GiBA902 netbsd_usr 10 373047296 432090111 28.2 GiBA902 netbsd7_root Partition number 10, labeled as 'netbsd7_root' were created especially for NetBSD 7_beta installation. So.. I run installer, hit 'install', 'yes', 'extended partitioning', then I got wedges list, from dk0 to dk8, in order related to partitions order. I selected 'dk8', took 'edit', toggled 'newfs', set 'mount' to '/' and 'flags' to 'log,noatime' and then 'ok'. After that I took 'save' or 'finish' (at this moment I don't remember and I'm reluctant to restore partition table again). Finally my partitions and wedges were recreated with some errors (sorry but they disappeared in fast rate) and my partition table got following shape (take a look at duplicates 1,2 and 3,4): Number Start (sector)End (sector) Size Code Name 120486143 2.0 MiB primary 220486143 2.0 MiB A902 boot_other 3 58572859179007 27.9 GiB xubuntu_root 4 58572859179007 27.9 GiB8300 home 559179008 234960895 83.8 GiB8300 netbsd_root 6 234960896 236961791 977.0 MiB A902 netbsd_altroot 7 236961792 238962687 977.0 MiB A902 netbsd_var 8 238962688 246962175 3.8 GiB A902 netbsd_swap 9 246962176 254961663 3.8 GiB A901 netbsd_usr 10 254961664 373047295 56.3 GiBA902 netbsd7_root 11 373047296 432090111 28.2 GiBA902 Regards, -- Piotr 'aniou' Meyer
Re: 7.0_BETA feedback sought
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 point, but we need [...] 'Generally good' is probably fair and true statement - but as long as You don't try 'extended partitioning' on GPT disk. I have had single, dedicated partition for - test - NetBSD7 installation. After selecting 'extended partitioning', 'edit partition' and enabling 'newfs', 'mount as /' I ended with disk in FUBAR state: after some errors during process thats looks like partition and wedges re-creation (WTF?) my partitions was renumbered like this: # initial state startsize index contents [...] 234960896 2000896 5 GPT part - NetBSD FFSv1/FFSv2 236961792 2000896 6 GPT part - NetBSD FFSv1/FFSv2 238962688 7999488 7 GPT part - NetBSD FFSv1/FFSv2 246962176 7999488 8 GPT part - NetBSD swap 254961664 118085632 9 GPT part - NetBSD FFSv1/FFSv2 # final state startsize index contents [...] 234960896 2000896 6 GPT part - NetBSD FFSv1/FFSv2 236961792 2000896 7 GPT part - NetBSD FFSv1/FFSv2 238962688 7999488 8 GPT part - NetBSD FFSv1/FFSv2 246962176 7999488 9 GPT part - NetBSD swap 254961664 118085632 10 GPT part - NetBSD FFSv1/FFSv2 ...wedges was messed-up even more and - as expected consequence - my separated boot partition lost their identity. Yes, I know - running _BETA may lead to similar consequences, but at this moment I found term 'generally good' as little exaggerated (at least when extending paritioning comes to play). PS. I tested NetBSD-7_BETA/amd64 ISO from 201410230710Z snapshot. -- Piotr 'aniou' Meyer
Re: Wedges enabled on -current
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 bootloader complains about 'no slice' and stops. Besides I'm not perfectly sure that my layout is supported: # gpt show wd0 startsize index contents [...] 234960896 2000896 5 GPT part - NetBSD FFSv1/FFSv2 236961792 2000896 6 GPT part - NetBSD FFSv1/FFSv2 238962688 7999488 7 GPT part - NetBSD FFSv1/FFSv2 246962176 7999488 8 GPT part - NetBSD swap 254961664 118085632 9 GPT part - NetBSD FFSv1/FFSv2 # dkctl wd0 listwedges /dev/rwd0d: 9 wedges: [...] dk4: netbsd_root, 2000896 blocks at 234960896, type: ffs dk5: netbsd_altroot, 2000896 blocks at 236961792, type: ffs dk6: netbsd_var, 7999488 blocks at 238962688, type: ffs dk7: netbsd_swap, 7999488 blocks at 246962176, type: swap dk8: netbsd_usr, 118085632 blocks at 254961664, type: ffs # grep NAME /etc/fstab NAME=netbsd_root /ffs rw,log,noatime 1 1 NAME=netbsd_var /var ffs rw,log,noatime 1 2 NAME=netbsd_usr /usr ffs rw,log,noatime 1 2 NAME=netbsd_swap none swap sw,dp 0 0 I installed loader by: installboot /dev/rdk4 /usr/mdec/bootxx_ffsv2 and loaded them - like in my previous setup with MSDOS partitioning scheme - from grub by 'chainloader +1' directive. Native grub2 method (knetbsd /netbsd) works fine but I'd like to use native one. -- Piotr 'aniou' Meyer
Re: amd64 DRMKMS (ivy bridge) results, 14 Jun 2014
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 the relevant code paths and do it. [...] I just made test with MesaLib 10.2.6 and this version (also used and tested with my hw in Free and newest Open) works fine. After simply replacement /usr/X11R7/lib/modules/dri/i965_dri.so by corresponding library from new Mesa my problems disappeared. $ glxinfo | grep OpenGL OpenGL vendor string: Intel Open Source Technology Center OpenGL renderer string: Mesa DRI Intel(R) Ivybridge Desktop OpenGL version string: 3.0 Mesa 10.2.6 OpenGL shading language version string: 1.30 I knew rationales behind Mesa 7.x in NetBSD but - on the other hand - support for newer GPUs may be worthwhile to consider... -- Piotr 'aniou' Meyer
Re: amd64 DRMKMS (ivy bridge) results, 14 Jun 2014
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 a little: #v+ Reading symbols from /netbsd.gdb...done. Load new symbol table from /netbsd.gdb? (y or n) y Reading symbols from /netbsd.gdb...done. 0x8067a5bf in cpu_reboot (howto=howto@entry=256, bootstr=bootstr@entry=0x0) at /usr/src/sys/arch/amd64/amd64/machdep.c:671 671 dumpsys(); #0 0x8067a5bf in cpu_reboot (howto=howto@entry=256, bootstr=bootstr@entry=0x0) at /usr/src/sys/arch/amd64/amd64/machdep.c:671 #1 0x8026 in db_sync_cmd (addr=optimized out, have_addr=optimized out, count=optimized out, modif=optimized out) at /usr/src/sys/ddb/db_command.c:1358 #2 0x802ab267 in db_command (last_cmdp=last_cmdp@entry=0x8109e180 db_last_command) at /usr/src/sys/ddb/db_command.c:907 #3 0x802ab5f4 in db_command_loop () at /usr/src/sys/ddb/db_command.c:565 #4 0x802b0d0d in db_trap (type=type@entry=1, code=code@entry=0) at /usr/src/sys/ddb/db_trap.c:90 #5 0x802adf80 in kdb_trap (type=type@entry=1, code=code@entry=0, regs=regs@entry=0xfe80cefffc30) at /usr/src/sys/arch/amd64/amd64/db_interface.c:227 #6 0x809157c2 in trap (frame=0xfe80cefffc30) at /usr/src/sys/arch/amd64/amd64/trap.c:287 #7 0x80100fde in alltraps () #8 0x8028bc5d in breakpoint () #9 0x808c6f90 in vpanic (fmt=0x80d34318 kernel %sassertion \%s\ failed: file \%s\, line %d , ap=ap@entry=0xfe80cefffd60) at /usr/src/sys/kern/subr_prf.c:338 #10 0x80a62393 in kern_assert (fmt=fmt@entry=0x80d34318 kernel %sassertion \%s\ failed: file \%s\, line %d ) at /usr/src/sys/lib/libkern/kern_assert.c:51 #11 0x803b27ec in DRM_SPIN_WAITERS_P (interlock=0x86b03ca0, q=0x86b03688) at /usr/src/sys/external/bsd/drm2/include/drm/drm_wait_netbsd.h:89 #12 i915_record_ring_state (ering=0xfe811cbf7a10, ring=0x86b03560, dev=0xfe8106bc3010) at /usr/src/sys/external/bsd/drm2/dist/drm/i915/i915_gpu_error.c:812 #13 i915_gem_record_rings (error=0xfe811cbf7810, dev=0xfe8106bc3010) at /usr/src/sys/external/bsd/drm2/dist/drm/i915/i915_gpu_error.c:924 #14 i915_capture_error_state (dev=0xfe8106bc3010, wedged=optimized out, error_msg=0xfe80cefffe88 Ring hung) at /usr/src/sys/external/bsd/drm2/dist/drm/i915/i915_gpu_error.c:1191 #15 0x803b763f in i915_handle_error (dev=0xfe8106bc3010, wedged=optimized out, fmt=optimized out) at /usr/src/sys/external/bsd/drm2/dist/drm/i915/i915_irq.c:2364 #16 0x80618752 in callout_softclock (v=optimized out) at /usr/src/sys/kern/kern_timeout.c:736 #17 0x8060d338 in softint_execute (l=optimized out, s=2, si=0x800042a310c0) at /usr/src/sys/kern/kern_softint.c:589 #18 softint_dispatch (pinned=error reading variable: Cannot access memory at address 0xfe80cfc0, s=2) at /usr/src/sys/kern/kern_softint.c:871 #19 0x8011412f in Xsoftintr () /usr/src/external/gpl3/gdb/dist/gdb/frame.c:472: internal-error: get_frame_id: Assertion `fi-this_id.p' failed. A problem internal to GDB has been detected, further debugging may prove unreliable. Quit this debugging session? (y or n) y /usr/src/external/gpl3/gdb/dist/gdb/frame.c:472: internal-error: get_frame_id: Assertion `fi-this_id.p' failed. A problem internal to GDB has been detected, further debugging may prove unreliable. Create a core file of GDB? (y or n) n #v- Kernel running w/o DIAGNOSTIC/DEBUG gave me: #v+ drm: stuck on render ring drm: GPU HANG: ecode 0:0x86ed, reason: Ring hung, action: reset drm: GPU hangs can indicate a bug anywhere in the entire gfx stack, including userspace. drm: Please file a _new_ bug report on bugs.freedesktop.org against DRI - DRM/Intel drm: drm/i915 developers can then reassign to the right component if it's not a kernel issue. drm: The gpu crash dump is required to analyze gpu hangs, so please always attach it. drm: GPU crash dump saved to /sys/class/drm/card0/error i915drmkms0: interrupting at ioapic0 pin 16 (pci0@pci::00:02.0) drm: Enabling RC6 states: RC6 on, RC6p on, RC6pp off drm: stuck on render ring drm: GPU HANG: ecode 0:0x86ed7c1f, reason: Ring hung, action: reset DRM error in i915_context_is_banned: gpu hanging too fast, banning! i915drmkms0: interrupting at ioapic0 pin 16 (pci0@pci::00:02.0) drm: Enabling RC6 states: RC6 on, RC6p on, RC6pp off #v- Regards, -- Piotr 'aniou' Meyer
Re: Branching delayed (was Re: Preparation for creating netbsd-7 branch)
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, Riastradh's mails on tech-kern@ suggests that whole KMS (related to Ivy or not) stuff needs some extra additions to kernel, for example: http://mail-index.netbsd.org/tech-kern/2014/07/23/msg017392.html Regards, -- Piotr 'aniou' Meyer
amd64 DRMKMS results, 26 Jul 2014
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 !(obj-base.write_domain ~(0x0002 | 0x0004 | 0x0008 | 0x0010 | W0x000A0R0N0I2N0G):) S PfLa iNlOeTd :L OfWiERED ON SYSCALL 112 4 EXIT 0 6 le /usr/src/sys/external/bsd/drm2/dist/drm/i915/i915_gem.c, line 2829 Regards, -- Piotr 'aniou' Meyer
amd64 DRMKMS results, 19 Jul 2014
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 19 12:55:08 dodo /netbsd: panic: kernel diagnostic assertion spin_is_locked(interlock) failed: file /usr/src/sys/external/bsd/drm2/include/drm/drm_wait_netbsd.h, line 89 Jul 19 12:55:08 dodo /netbsd: cpu0: Begin traceback... Jul 19 12:55:08 dodo /netbsd: vpanic() at netbsd:vpanic+0x13c Jul 19 12:55:08 dodo /netbsd: kern_assert() at netbsd:kern_assert+0x4f Jul 19 12:55:08 dodo /netbsd: i915_capture_error_state() at netbsd:i915_capture_error_state+0x13cb Jul 19 12:55:08 dodo /netbsd: i915_handle_error() at netbsd:i915_handle_error+0x8f Jul 19 12:55:08 dodo /netbsd: callout_softclock() at netbsd:callout_softclock+0x392 Jul 19 12:55:08 dodo /netbsd: softint_dispatch() at netbsd:softint_dispatch+0xd3 Jul 19 12:55:08 dodo /netbsd: DDB lost frame for netbsd:Xsoftintr+0x4f, trying 0xfe80cd494ff0 Jul 19 12:55:08 dodo /netbsd: Xsoftintr() at netbsd:Xsoftintr+0x4f Jul 19 12:55:08 dodo /netbsd: --- interrupt --- Jul 19 12:55:08 dodo /netbsd: 0: Jul 19 12:55:08 dodo /netbsd: cpu0: End traceback... Bunch of kernel-in-debug-mode messages and Xorg.log, is available under: http://smutek.pl/netbsd/drmkms-regression2.txt Regards, -- Piotr 'aniou' Meyer
amd64 DRMKMS results, 28 Jun 2014
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, xorg.conf, error from glxgears) is available from http://smutek.pl/netbsd/drmkms-ok-report.txt - short excerpt below: cpu0 at mainbus0 apid 0: Intel(R) Pentium(R) CPU G2030 @ 3.00GHz, id 0x306a9 i915drmkms0 at pci0 dev 2 function 0WARNING: module error: vfs load failed for `pciverbose', error 45 WARNING: module error: vfs load failed for `pciverbose', error 45 : vendor 0x8086 product 0x0152 (rev. 0x09) drmkms0 at i915drmkms0 drm: Memory usable by graphics device = 2048M drm: MTRR allocation failed. Graphics performance may suffer. drm: Supports vblank timestamp caching Rev 1 (10.10.2010). drm: Driver supports precise vblank timestamp query. drmkms0: interrupting at ioapic0 pin 16 (i915) i915drmkms0: framebuffer at 0x8000453d5000, size 1920x1080, depth 32, stride 7680 wsdisplay0 at i915drmkms0 kbdmux 1: console (default, vt100 emulation) wsmux1: connecting to wsdisplay0 drmkms0: info: registered panic notifier Message from glxinfo, glxgears: name of display: :0 Unrecognized deviceID 152 X Error of failed request: BadAlloc (insufficient resources for operation) Major opcode of failed request: 155 (GLX) Minor opcode of failed request: 3 (X_GLXCreateContext) Serial number of failed request: 21 Current serial number in output stream: 24 And finally: may thanks for Your work Taylor, also - many thanks for all contributors. I'm really happy because of that - finally I got working NetBSD workstation! -- Piotr 'aniou' Meyer
