Re: Anyone still using PCI "isp" SCSI / FC controllers?
Hello, On Tue, 20 Jul 2021 15:09:57 +0200 Manuel Bouyer wrote: > I have: > isp0 at pci10 dev 0 function 0: QLogic FC-AL and 4Gbps Fabric PCI-E HBA > isp1 at pci10 dev 0 function 1: QLogic FC-AL and 4Gbps Fabric PCI-E HBA For the record, I have two slightly different isp at sbus ( one UW, one FW SCSI ) in case anything in the bus-independent part needs testing. have fun Michael
Re: Disappearing mouse buttons
Hello, On Tue, 08 Feb 2022 15:06:43 +0100 Tom Ivar Helbekkmo wrote: > I'm looking for something that I can't find... The "Kensington Expert > Mouse" trackball on my amd64-current workstation has four buttons and a > scroll wheel, and these used to generate all different button presses - > so at least six distinct buttons. This was still working with a > -current from back at the start of September. > > After a fresh update, however, it now reports thus: > > uhidev1 at uhub4 port 1 configuration 1 interface 0 > uhidev1: vendor 047d (0x047d) Kensington Expert Mouse (0x1020), rev > 2.00/1.06, addr 4, iclass 3/1 > ums0 at uhidev1: 5 buttons and Z dir > wsmouse0 at ums0 mux 0 > > With this, I suddenly have the fourth button mapped as a duplicate of > one of the scroll wheel directions. The wsmouse mapping is "1 2 3 4 5", > and the fourth button generates button 4; the scroll wheel 4 and 5. The > fourth button, then, is just single steps of one scroll direction, while > it used to give me the "back" function normally associated with one of > the thumb buttons on most modern mice. > > I've been looking at changes in sys/dev/usb, sys/dev/hid, and > sys/dev/wscons, but I can't find anything that looks relevant. > > If anyone has any hints for me, that would be appreciated! Does it still work as expected with an older -current? It may be a long shot, but the ADB variants of these trackballs are programmable, on the hardware side, on which button sends what event. That's more or less why the ktm driver exists. No idea if the USB ones are, but who knows. Might be worth checking what the windows driver does. It might have remapped some buttons and maybe the settings are sticky. have fun Michael
Re: FYI: new X server in -current, among other X things
Hello, On Fri, 15 Jul 2022 15:12:07 +1000 matthew green wrote: > i've updated most of xsrc to their latest versions. > fontconfig and Mesa are remaining. i've tested the > new code on amd64 and arm64, and built several ports > to confirm they still build. the biggest change is > the new xorg-server. > > there are probably a few build issues left to find > across all ports, and perhaps some run-time ones too > but basic testing looks fine for me. Alright, I'll check all my weirdo drivers! have fun Michael
Re: macppc system wedging under memory pressure
Hello, On Fri, 16 Sep 2022 19:41:44 +0100 Mike Pumford wrote: > I've been running my build system ( an 8 core amd64 system with 16GB of > RAM) with: > > vm.filemax=10 > vm.filemin=1 > > So its not just SMALL systems that need better tuning. > > Before I set those I found that the system would prioritise file cache > so much that any large process that ran for a long time would be forced > to swap out so much that it would then take them ages to recover. In my > case that was the jenkins process that was managing the build leading to > lots of failed builds as the jenkins process fell apart. Setting those > limits meant the file cache got evicted instead of the jenkins process. > > I also found the same settings kept things like firefox from getting > swapped out during builds as well. I've seen the same thing on a sparc64 with 12GB RAM - firefox and claws would get swapped out while the buffer cache would stay at 8GB or more, with a couple cc1plus instances fighting over the remaining RAM. have fun Michael
Re: cubietruck/ axp20x/ awiniic0: send STOP failed
Hello, On Sat, 13 Feb 2016 14:16:13 +0100 Martin Husemann wrote: > On Fri, Feb 12, 2016 at 09:21:22AM +0100, Manuel Bouyer wrote: > > It's strange, I'm running HEAD on a olimex lime2 (which has A20+axp20x too) > > and never seen this. I also occasionally run on a cubieboard, but > > it's usually not powered on for more than a few hours. > > I run a cubietruck with -current and have never seen that message. I have seen it with -current from a month ago, and only after the machine's been up for ca. 2 weeks. It's been updated 10 days ago and no errors since. have fun Michael
Re: build breakage, speeling
Hello, On Fri, 11 Mar 2016 13:24:23 -0800 bch wrote: > --- if_malo_pcmcia.o --- > /usr/src/sys/dev/pcmcia/if_malo_pcmcia.c: In function 'cmalo_media_change': > /usr/src/sys/dev/pcmcia/if_malo_pcmcia.c:637:43: error: expected ')' before > '_' > if ((error = ieee80211_media_change(ifp))_ != ENETRESET) >^ > --- if_iwn.o --- > /usr/src/obj/tooldir.NetBSD-7.99.26-amd64/bin/nbctfconvert -g -L > VERSION -g if_iwn.o > --- if_malo_pcmcia.o --- > *** [if_malo_pcmcia.o] Error code 1 should be fixed now thanks Michael
USB borkage lately
Hello, lately I'm seeing: - communication via ulpcom is completely garbled - unreliable event delivery from a USB trackball - things like button events getting randomly dropped - unreliable communication with a USB keyboard ( things like LEDs staying on after init and such ) all on sparc64 so far ( that is, ohci since all devices above are low speed, I didn't test anything faster or other hardware yet ) This must have crept in within the last 3 weeks, since older kernels Just Work(tm). Is anyone else seeing this? have fun Michael
Re: USB borkage lately
Hello, On Mon, 9 May 2016 18:21:10 +0200 Martin Husemann wrote: > > lately I'm seeing: > > - communication via ulpcom is completely garbled > > You mean uplcom? Saw that... Yes, yes I do... > > - unreliable communication with a USB keyboard ( things like LEDs > > staying on after init and such ) > > And see that as well. Ok, so it's not just me. > I ignored the keyboard LEDs an assumed the uplcom issue would be endianess > (and can't remember whether I ever used it on sparc64 before). I don't think I used mine on anything else. It's currently my CI20's console so it's kinda important to me. > Nick, any big endian machines with USB that you could test on? > Tried booting one of your bi-endian evbarms with big endian kernel? I'm fairly sure I ran recent kernels on macppc, but the only USB device I use there is an urtwn, which wouldn't use the ohci. have fun Michael
Re: USB borkage lately
Hello, On Mon, 9 May 2016 22:54:08 +0100 Nick Hudson wrote: > > lately I'm seeing: > > - communication via ulpcom is completely garbled > > - unreliable event delivery from a USB trackball - things like button > >events getting randomly dropped > > - unreliable communication with a USB keyboard ( things like LEDs > >staying on after init and such ) > > > > all on sparc64 so far ( that is, ohci since all devices above are low > > speed, I didn't test anything faster or other hardware yet ) > > > > This must have crept in within the last 3 weeks, since older kernels > > Just Work(tm). > > > > Is anyone else seeing this? > > > > have fun > > Michael > > > Hopefully, I justed fixed it with sys/dev/usb/ohci.c:1.262 > > Please test. It works, thanks! have fun Michael
Re: GCC 5.4 mips64el problems
Hello, On Fri, 1 Jul 2016 19:17:59 -0500 (CDT) "John D. Baker" wrote: > I decided to try building evbmips-mips64el with GCC 5.4 (-V HAVE_GCC=53). > Starting with a completely empty OBJDIR/DESTDIR, etc., building eventually > failed with: > > [...] > --- ramdiskbin --- > # link ramdisk/ramdiskbin > /d0/build/current-gcc5/tools/amd64/bin/mips64el--netbsd-gcc > --sysroot=/d0/build/current-gcc5/DEST/evbmips -static -o ramdiskbin > ramdiskbin.o -Wl,-rpath-link,/d0/build/current-gcc5/DEST/evbmips/lib > -L=/lib cat.cro chmod.cro cp.cro date.cro dd.cro df.cro ed.cro ln.cro ls.cro > mkdir.cro mv.cro pax.cro ps.cro pwd.cro rm.cro rmdir.cro sh.cro stty.cro > sync.cro disklabel.cro fdisk.cro fsck.cro fsck_ext2fs.cro fsck_ffs.cro > fsck_msdos.cro ifconfig.cro init.cro mknod.cro mount.cro mount_cd9660.cro > mount_ext2fs.cro mount_ffs.cro mount_kernfs.cro mount_msdos.cro mount_nfs.cro > mount_tmpfs.cro newfs.cro newfs_ext2fs.cro newfs_msdos.cro ping.cro > reboot.cro restore.cro route.cro shutdown.cro slattach.cro swapctl.cro > sysctl.cro umount.cro chown.cro ftp.cro gzip.cro less.cro sed.cro tset.cro > vmstat.cro chroot.cro flashctl.cro sysinst.cro progress.cro libhack.o -ledit > -lutil -lcurses -lterminfo -lkvm -lrmt -lcrypt -ll -lm -llzma -lbz2 -lz > -lprop > /d0/build/current-gcc5/DEST/evbmips/usr/lib/libc.a(softfloat.o): In function > `__truncdfsf2': > softfloat.c:(.text+0x35f8): multiple definition of `__truncdfsf2' > /d0/build/current-gcc5/DEST/evbmips/usr/lib/libgcc.a(truncdfsf2.o):(.text+0x0): > first defined here > collect2: error: ld returned 1 exit status > *** [ramdiskbin] Error code 1 > nbmake[7]: stopped in > /d0/build/current-gcc5/obj/mips64el/distrib/evbmips/instkernel/ramdisk > 1 error > [...] That looks like some softfloat support is messed up. Weird. I haven't seen that but I didn't build softfloat userlands lately. > I understand others have been experimentally building evbmips (-mips64eb > at least) w/GCC 5.4. Did you run into this and if so, what works around > it? I have userlands and kernels built with binutils 2.26 and gcc 5.4 working on Loongson ( LP64 kernel, n32 userland ), sgimips64 ( kernel and userland n32 ), both with MKSOFTFLOAT=no, and on CI20 ( mips32r2, so everything is o32 ). Kernels work fine, userland on 64bit has some warts left - trunc.d.* instructions cause SIGILLs on sgimips64 and I get other, weirder problems on Loongson, mostly when building stuff from pkgsrc. Also, the compiler still defaults to softfloat output without -mhard-float for some reason. I suspect the root cause is the same on both though. have fun Michael
Re: rasops15 byte order bug
On Fri, 16 Sep 2016 11:11:34 +0200 Manuel Bouyer wrote: > On Wed, Sep 14, 2016 at 01:40:50PM -0700, scole_mail wrote: > > Anyone using a 15/16 bit rasops console without issues? I think there is > > a byte order error in rasops15.c . > > > > This patch worked for me, wondering if anyone else can confirm the error > > and/or verify this fix. > > It's been a while since I played with this, but I think this is used for > tifb (am335x SoCs, as found on the beaglebone). AFAIK It works fine for me > with a 16bit display. I suspect the #ifdef shouldn't check just host byte order but host byte order vs. video hardware byte order. Probably needs a new rasops_info flag. have fun Michael
Re: rasops15 byte order bug
Hello, On Fri, 16 Sep 2016 20:29:32 +0300 Valery Ushakov wrote: > On Fri, Sep 16, 2016 at 13:05:16 -0400, Michael wrote: > > > On Fri, 16 Sep 2016 11:11:34 +0200 > > Manuel Bouyer wrote: > > > > > On Wed, Sep 14, 2016 at 01:40:50PM -0700, scole_mail wrote: > > > > Anyone using a 15/16 bit rasops console without issues? I think there > > > > is > > > > a byte order error in rasops15.c . > > > > > > > > This patch worked for me, wondering if anyone else can confirm the error > > > > and/or verify this fix. > > > > > > It's been a while since I played with this, but I think this is used for > > > tifb (am335x SoCs, as found on the beaglebone). AFAIK It works fine for me > > > with a 16bit display. > > > > I suspect the #ifdef shouldn't check just host byte order but host byte > > order vs. video hardware byte order. Probably needs a new rasops_info flag. > > I haven't touched this in a *very* long time, but (about early 2002) > in rasops8.c I ended up with > > #if BYTE_ORDER == BIG_ENDIAN > #define NEED_LITTLE_ENDIAN_STAMP RI_BSWAP > #else > #define NEED_LITTLE_ENDIAN_STAMP 0 > #endif > if ((ri->ri_flg & RI_BSWAP) == NEED_LITTLE_ENDIAN_STAMP) > ... > > Don't know how correct that was, but it's been working for the endian > permutations we have. > > Note that we apply RI_BSWAP to 32 and 15/16 bit cases in rasops.c, not > when building stamps. I think we need something like RI_FB_IS_BE and adjust the endianness checks accordingly. That would also solve the igsfb thing. have fun Michael
Re: libc_fp* entries for mips debug set?
Hello, On Fri, 21 Oct 2016 12:27:54 +0200 Martin Husemann wrote: > On Fri, Oct 21, 2016 at 05:18:44AM -0500, John D. Baker wrote: > > This is evbmips-mips64el for my Lemote YeeLoong. > > So that should be arch64, but not softfloat, and I would have expected > the entries to be ignored. All mips64 is softfloat for now, libc_fp just implements some of it using FPU instructions. Then again, I wouldn't be surprised if I goofed the set list attributes for those files... That said, hardfloat builds currently fail with /home/build/dest_evbmips/lib/libc.so: undefined reference to `__gttf2' /home/build/dest_evbmips/lib/libc.so: undefined reference to `__divtf3' /home/build/dest_evbmips/lib/libc.so: undefined reference to `__multf3' /home/build/dest_evbmips/lib/libc.so: undefined reference to `__floatunsitf' probably fallout from moving the softfloat stuff from libc to libgcc recently? have fun Michael
Re: Build failure for in-tree xorg
Hello, On Fri, 6 Jan 2017 07:55:52 +0800 (PHT) Paul Goyette wrote: > Hmmm, cvs claimed that the file was up-to-date and that there were no > differences between my local copy and the repo. > > Yet, I removed it and re-fetched via cvs update, and sure enough the > build is moving again! That was an #include that I accidentally #ifdef HAVE_ISA-ed. Martin fixed it. have fun Michael > On Thu, 5 Jan 2017, bch wrote: > > > I just nuked that file and re-CVS'd it and made out alright. I looked for > > its obj, but couldn't conclusively find it and did the nuke/restore in > > meantime, then things built. A touch (1) alone might push it along? > > > > On Jan 5, 2017 15:36, "Paul Goyette" wrote: > > > >> With up-to-date sources, and a totally clean $OBJDIR I am getting > >> > >> /build/netbsd-local/xsrc/external/mit/xf86-video-chips/dist/src/ct_driver.c: > >> In function 'chipsMapMem': > >> /build/netbsd-local/xsrc/external/mit/xf86-video-chips/dist/src/ct_driver.c:6870:14: > >> error: implicit declaration of function 'mmap' > >> [-Werror=implicit-function-declaration] > >> *result = mmap(NULL, > >> ^ > >> /build/netbsd-local/xsrc/external/mit/xf86-video-chips/dist/src/ct_driver.c:6872:15: > >> error: 'PROT_READ' undeclared (first use in this function) > >>PROT_READ | PROT_WRITE, > >>^ > >> /build/netbsd-local/xsrc/external/mit/xf86-video-chips/dist/src/ct_driver.c:6872:15: > >> note: each undeclared identifier is reported only once for each function it > >> appears in > >> /build/netbsd-local/xsrc/external/mit/xf86-video-chips/dist/src/ct_driver.c:6872:27: > >> error: 'PROT_WRITE' undeclared (first use in this function) > >>PROT_READ | PROT_WRITE, > >>^ > >> /build/netbsd-local/xsrc/external/mit/xf86-video-chips/dist/src/ct_driver.c:6873:15: > >> error: 'MAP_SHARED' undeclared (first use in this function) > >>MAP_SHARED, > >>^ > >> /build/netbsd-local/xsrc/external/mit/xf86-video-chips/dist/src/ct_driver.c:6876:22: > >> error: 'MAP_FAILED' undeclared (first use in this function) > >> err = (*result == MAP_FAILED); > >> ^ > >> ... > >> > >> > >> > >> > >> > >> > >> +--+--++ > >> | Paul Goyette | PGP Key fingerprint: | E-mail addresses: | > >> | (Retired)| FA29 0E3B 35AF E8AE 6651 | paul at whooppee.com | > >> | Kernel Developer | 0786 F758 55DE 53BA 7731 | pgoyette at netbsd.org | > >> +--+--++ > >> > > > > > > !DSPAM:586edb8014332552212206! > > > > +--+--++ > | Paul Goyette | PGP Key fingerprint: | E-mail addresses: | > | (Retired)| FA29 0E3B 35AF E8AE 6651 | paul at whooppee.com | > | Kernel Developer | 0786 F758 55DE 53BA 7731 | pgoyette at netbsd.org | > +--+--++
Re: Packages crashing on -current
Hello, On Fri, 21 Apr 2017 16:34:33 + co...@sdf.org wrote: > Hi, > > mprotect (and ASLR) are security measures that not all pkgsrc packages > can survive, so some packages had NOT_PAX_MPROTECT_SAFE set for some > binaries, to disable it. > > However the condition for using NOT_PAX_MPROTECT_SAFE was incorrectly > only done for NetBSD/amd64. > > The outcome should've been things like (only on -current, stable is > unaffected as it doesn't have pax mprotect enabled): > - Firefox crashes > - Libreoffice segfaults during build > etc. Midori ( and likely everything else using webkit ) has a similar problem - it doesn't crash, but javascript doesn't work until all the mprotect stuff is disabled. have fun Michael
Re: Preparation for creating netbsd-7 branch
Hello, On Sun, 20 Jul 2014 19:25:53 +0900 Izumi Tsutsui wrote: > christos@ wrote: > > > On Jul 20, 3:50am, tsut...@ceres.dti.ne.jp (Izumi Tsutsui) wrote: > > -- Subject: Re: Preparation for creating netbsd-7 branch > > > > | christos@ wrote: > > | > > | > In article <140719232527.m0121...@mirage.ceres.dti.ne.jp>, > > | > Izumi Tsutsui wrote: > > | > >> On behalf of the release engineering team, I am happy to announce > > that > > | > >> the release process for NetBSD 7.0 is now underway. > > | > > > > | > >Does anyone (core? releng?) has a particular plan about > > | > >the default MACHINE_ARCH for each arm ports? > > | > > > | > Let's discuss it. What do you propose? > > | > > | I asked matt@ on port-arm last year and got no answer. > > | http://mail-index.netbsd.org/port-arm/2013/10/26/msg002073.html > > | I think (other) Core members should handle it. > > > > Yes, I've been trying to follow that thread. Can you please summarize > > the problem and propose a solution? Is it a backwards compatibility issue? > > Or do we need to worry about binaries produced with sf on hf able machines > > in the future? Why would one do that? To be compatible with old machines? > > The main problem is lack of design description with random changes. > http://mail-index.netbsd.org/port-arm/2013/10/26/msg002069.html > http://mail-index.netbsd.org/port-arm/2013/10/27/msg002075.html > Without specification, no idea what is intentional and what is broken. > > Anyway, most concerns are too late to discuss. > - MACHINE_ARCH should be static or dynamic > - how sysctl hw.machine_arch should be handled > - different MACHINE_ARCH for kernel and userland should be allowed or not > - different MACHINE_ARCH should be used for armv4/v6/v7 or not > - a single kernel should handle different MACHINE_ARCH userland or not > - should we use different MACHINE_ARCH for softfloat and hardfloat or not > All of these usages have been changed from other MACHINE_ARCH. > > For the next release, core/releng should decide per current implementation: > - how the default userland MACHINE_ARCH should be deteremined > - how to handle migration from old ABI to new one on sysinst > - which MACHINE_ARCH binaries should be prepared for official packages > etc. for the new MACHINE_ARCH strategies. For the record, much of this applies on MIPS as well, especially since mips64* is softfloat for now. I ran into trouble with mips64eb vs. mipseb when playing with n32 userland & kernel on sgimips. have fun Michael
Re: mips "Creator ci20" port
Hello, On Thu, 4 Dec 2014 14:21:55 -0800 bch wrote: > I see that there is mention[1] of a porting effort for NetBSD to this > device -- I quickly trawled the commit msgs in the repo and didn't see > any obvious mention of it. Does anybody know the status of NetBSD on > the ci20, or know where to get the status ? I committed very basic support about two weeks ago. It boots a kernel, sets up one CPU and a serial port, talks to the serial port so you can break into ddb and poke around. I've got a few more things more or less working ( timer, interrupts, bus attachments, dwc2 etc. ) that need to be brushed off and committed but I only have time for this for a day or two per week. have fun Michael
Re: mips "Creator ci20" port
Hello, On Thu, 4 Dec 2014 18:48:32 -0800 bch wrote: > Was it an article (that I can't find now) *you* wrote where working w/ > the serial port, you could pass data "by hand", but not w/ a driver, > currently ? Had to be the post on blog.netbsd.org, but that problem had been solved by then. Turned out the UARTs on this SoC are /almost/ 16550 compatible - the difference is a bit in the FIFO control register which powers the UART down if not set, the com driver of course didn't know about it, so as soon as it took over the port went dead. have fun Michael
Re: mips "Creator ci20" port
Hello, On Fri, 5 Dec 2014 11:23:23 + Justin Cormack wrote: > On Fri, Dec 5, 2014 at 2:30 AM, Michael wrote: > > Hello, > > > > On Thu, 4 Dec 2014 14:21:55 -0800 > > bch wrote: > > > >> I see that there is mention[1] of a porting effort for NetBSD to this > >> device -- I quickly trawled the commit msgs in the repo and didn't see > >> any obvious mention of it. Does anybody know the status of NetBSD on > >> the ci20, or know where to get the status ? > > > > I committed very basic support about two weeks ago. > > It boots a kernel, sets up one CPU and a serial port, talks to the > > serial port so you can break into ddb and poke around. > > I've got a few more things more or less working ( timer, interrupts, > > bus attachments, dwc2 etc. ) that need to be brushed off and committed > > but I only have time for this for a day or two per week. > > Thanks! I didnt get a free one but I have ordered one now, but they > are apparently not shipping until end January. Hmm, I'm fairly sure that at least two other netbsd people got free ones, apparently they didn't have time to play with them yet. > Would be good to have support as it is the new standard mips dev > platform. Yeah, this looks promising, especially after the disappointment that Loongson hardware turned out to be. have fun Michael
Re: mips "Creator ci20" port
Hello, On Fri, 5 Dec 2014 14:05:45 +0100 Martin Husemann wrote: > On Fri, Dec 05, 2014 at 08:02:08AM -0500, Michael wrote: > > Hmm, I'm fairly sure that at least two other netbsd people got free > > ones, apparently they didn't have time to play with them yet. > > I got one, but was waiting for you to commit support for the interrupt > controller ;-) That should happen monday or tuesday. I pretty much figured out how to deal with it by now, just need to write some more or less trivial code. > Not that I would have had any time recently anyway, but that will > change soon... Good, there's a bunch more drivers to write / adapt ;) My roadmap looks more or less like this: * initial CPU and UART support - committed * timer interrupt - works, but not committed yet * time counter - works, needs to be finished * hw interrupts - works more or less, needs to be finished * apbus at mainbus and dwctwo at apbus - written but not really tested --- I'm hoping to get here by next wednesday * framebuffer support - going to look at that when USB works * i2c and RTC support ( there's an external one that we don't support yet as far as I can tell, the on-chip RTC is really just another counter ) * SMP support - IPIs work ( from core0 to itself ), needs to actually attach and spin up the 2nd core * deal with command line parameters from u-boot ( already exists elsewhere ) * sdhc and ethernet support - hoping someone else will do those * attach the other UARTs ( at some point, should be more or less trivial ) have fun Michael
Re: mips "Creator ci20" port
Hello, I made some progress: U-Boot SPL 2013.10-rc3-g9329ab16a204 (Jun 26 2014 - 09:43:22) SDRAM H5TQ2G83CFR initialization... done U-Boot 2013.10-rc3-g9329ab16a204 (Jun 26 2014 - 09:43:22) Board: ci20 (Ingenic XBurst JZ4780 SoC) DRAM: 1 GiB NAND: 8192 MiB MMC: jz_mmc msc1: 0 In:eserial3 Out: eserial3 Err: eserial3 Net: dm9000 ci20# dhcp ERROR: resetting DM9000 -> not responding dm9000 i/o: 0xb600, id: 0x9a46 DM9000: running in 8 bit mode MAC: d0:31:10:ff:7e:89 operating at 100M full duplex mode BOOTP broadcast 1 DHCP client bound to address 192.168.0.47 *** Warning: no boot file name; using 'C0A8002F.img' Using dm9000 device TFTP from server 192.168.0.44; our IP address is 192.168.0.47 Filename 'C0A8002F.img'. Load address: 0x8800 Loading: # # 316.4 KiB/s done Bytes transferred = 1320126 (1424be hex) ci20# bootm ## Booting kernel from Legacy Image at 8800 ... Image Name: evbmips 7.99.3 (CI20) Image Type: MIPS NetBSD Kernel Image (gzip compressed) Data Size:1320062 Bytes = 1.3 MiB Load Address: 8002 Entry Point: 8002 Verifying Checksum ... OK Uncompressing Kernel Image ... OK subcommand not supported ci20# g 8002 ## Starting applicatipmap_steal_memory: seg 0: 0x36d 0x36d 0x 0x Loaded initial symtab at 0x802a4b34, strtab at 0x802ca164, # entries 9544 Copyright (c) 1996, 1997, 1998, 1999, 2000, 2001, 2002, 2003, 2004, 2005, 2006, 2007, 2008, 2009, 2010, 2011, 2012, 2013, 2014 The NetBSD Foundation, Inc. All rights reserved. Copyright (c) 1982, 1986, 1989, 1991, 1993 The Regents of the University of California. All rights reserved. NetBSD 7.99.3 (CI20) #68: Thu Dec 25 12:56:50 EST 2014 ml@blackbush:/home/build/obj_evbmips32/sys/arch/evbmips/compile/CI20 Ingenic XBurst total memory = 1024 MB avail memory = 1000 MB mainbus0 (root) cpu0 at mainbus0: 1200.00MHz (hz cycles = 12, delay divisor = 12) cpu0: Ingenic XBurst (0x3ee1024f) Rev. 79 with unknown FPC type (0x33) Rev. 0 cpu0: 32 TLB entries, 16MB max page size cpu0: 32KB/32B 8-way set-associative L1 instruction cache cpu0: 32KB/32B 8-way set-associative write-back L1 data cache com0 at mainbus0: Ingenic UART, working fifo com0: console apbus0 at mainbus0 dwctwo0 at apbus0: USB controller usb0 at dwctwo0: USB revision 2.0 starting timer interrupt... uhub0 at usb0: vendor DWC2 root hub, class 9/0, rev 2.00/1.00, addr 1 uhub1 at uhub0 port 1: vendor 1a40 USB 2.0 Hub [MTT], class 9/0, rev 2.00/1.00, addr 2 uhub1: multiple transaction translators umass0 at uhub1 port 1 configuration 1 interface 0 umass0: LaCie P'9220 Mobile Drive, rev 2.10/0.06, addr 3 scsibus0 at umass0: 2 targets, 1 lun per target sd0 at scsibus0 target 0 lun 0: disk fixed sd0: 465 GB, 16383 cyl, 16 head, 63 sec, 512 bytes/sect x 976773168 sectors uhub2 at uhub1 port 7: vendor 03eb Standard USB Hub, class 9/0, rev 1.10/3.00, addr 4 axe0 at uhub2 port 1 axe0: D-LINK CORPORAION DUB-E100, rev 2.00/10.01, addr 5 axe0: Ethernet address 00:80:c8:37:00:e1 ukphy0 at axe0 phy 3: OUI 0x0009c3, model 0x0005, rev. 4 ukphy0: 10baseT, 10baseT-FDX, 100baseTX, 100baseTX-FDX, auto root device: axe0 dump device: file system (default generic): root on axe0 mountroot: trying nfs... nfs_boot: trying BOOTP axe0: link state UP (was UNKNOWN) nfs_boot: BOOTP next-server: 0.0.0.0 nfs_boot: my_addr=192.168.0.209 nfs_boot: my_mask=255.255.255.0 nfs_boot: gateway=192.168.0.1 So, things that work now: - serial console - time counter, based on on-chip 'Operating System Timer' - timer interrupt, more or less. After a while the whole thing hangs, not sure why yet. - the OTG port, more or less, without DMA. Not sure why DMA doesn't work, or what's the deal with the other USB port. Should make it to userland relatively soon. Problems: - no USB DMA. Might have to restrict DMA maps to the lower 256MB or something, we'll see. - the whole thing hangs at some point, either during USB device discovery or shortly after. Might be a problem with the timer interrupt, for now it has to be re-scheduled every time, I'll just use one of the other timers to fire at 100Hz and see if that helps. have fun Michael
Re: com.c fails to compile on evbearmv7hf-el
Hello, On Sat, 7 Mar 2015 20:04:18 +0100 Kurt Schreiner wrote: > Hi, > > > with -current source cvs-updated an hour ago (or so); > > ===> build.sh command:./build.sh -u -N 1 -U -m evbearmv7hf-el -O > /u/NetBSD/arch/evbearmv7hf-el/obj -D /u/NetBSD/arch/evbearmv7hf-el/dest -R > /u/NetBSD/arch/evbearmv7hf-el/release -T /u/NetBSD/arch/evbearmv7hf-el/TOOLS > release > ===> build.sh started:Sat Mar 7 20:00:51 MET 2015 > ===> NetBSD version: 7.99.6 > ===> MACHINE: evbarm > ===> MACHINE_ARCH:earmv7hf > ===> Build platform: NetBSD 7.99.5 amd64 > ===> HOST_SH: /bin/sh > ===> MAKECONF file: /etc/mk.conf > ===> TOOLDIR path:/u/NetBSD/arch/evbearmv7hf-el/TOOLS > ===> DESTDIR path:/u/NetBSD/arch/evbearmv7hf-el/dest > ===> RELEASEDIR path: /u/NetBSD/arch/evbearmv7hf-el/release > ===> Updated makewrapper: > /u/NetBSD/arch/evbearmv7hf-el/TOOLS/bin/nbmake-evbearmv7hf-el > [...] > Build directory is > /u/NetBSD/arch/evbearmv7hf-el/obj/sys/arch/evbarm/compile/ARMADAXP > Don't forget to run "make depend" > depending the kern library objects > depending the compat library objects > compile ARMADAXP/armadaxp_start.o > compile ARMADAXP/locore.o > compile ARMADAXP/param.o > compile ARMADAXP/bcopy_page.o > compile ARMADAXP/bcopyinout.o > compile ARMADAXP/com.o > /u/NetBSD/src/sys/dev/ic/com.c: In function 'com_attach_subr': > /u/NetBSD/src/sys/dev/ic/com.c:531:5: error: assignment of read-only variable > 'fcr' > fcr |= FIFO_UART_ON; > ^ Should be fixed now. have fun Michael
Re: uhidev(4), ukbd(4) changes
Hello, On Mon, 14 Aug 2017 05:49:28 -0500 "Jonathan A. Kollasch" wrote: > There's a (probably remote) chance my changes to uhidev(4) and ukbd(4) > might have broken things. > > Particularly, I was not able to test that ukbd(4)'s > "FLAG_APPLE_FIX_ISO", "FLAG_APPLE_FN", "FLAG_GDIUM_FN" still function > correctly. I'll check the Gdium hack in the next few days. have fun Michael
Re: uhidev(4), ukbd(4) changes
Hello, On Mon, 14 Aug 2017 05:49:28 -0500 "Jonathan A. Kollasch" wrote: > There's a (probably remote) chance my changes to uhidev(4) and ukbd(4) > might have broken things. > > Particularly, I was not able to test that ukbd(4)'s > "FLAG_APPLE_FIX_ISO", "FLAG_APPLE_FN", "FLAG_GDIUM_FN" still function > correctly. As far as I can tell from just poking around little, FLAG_GDIUN_FN still works as intended. have fun Michael
Re: nfsroot with netbsd-8
Hello, On Fri, 18 Aug 2017 09:43:31 +1000 Paul Ripke wrote: > I tried upgrading a little nfsroot sparc box to netbsd-8, and have > run into an interesting problem: > > root on le0 > nfs_boot: trying DHCP/BOOTP > nfs_boot: DHCP next-server: 192.168.0.1 > nfs_boot: my_name=orac > nfs_boot: my_domain=private > nfs_boot: my_addr=192.168.0.12 > nfs_boot: my_mask=255.255.255.0 > nfs_boot: gateway=192.168.0.1 > root on 192.168.0.1:/home/orac > root file system type: nfs > kern.module.path=/stand/sparc/8.0/modules > warning: lookup /dev/console: error 13 > panic: init died (signal 6, exit 5) > > So, the kernel loads successfully via nfs, configures le0 fine, even > loads /sbin/init - but fails on /dev/console. And the /dev/console > looks fine: > > crw--- 1 root wheel 0, 0 Dec 29 2016 /home/orac/dev/console > > Looking at the nfs traffic during the boot, I see a permission denied > for an odd major/minor filehandle, which I think is the lookup on > /dev/console. Anyone have any ideas what's going on? fwiw, the server > is amd64, netbsd-7. My guess: you probably need -maproot=0:0 in your /etc/exports line have fun Michael
Re: HEADS-UP: SATA NCQ support merged (from jdolecek-ncq branch)
Hello, On Sat, 7 Oct 2017 18:34:04 +0200 Jaromír Doleček wrote: > I've merged the NCQ branch to HEAD. Nice, thanks! > The code was quite extensively tested on that harware on amd64. Other archs > and drivers compile, but I had no way to test them. Particularily, I had no > chance to really test any real IDE disks, neither any non-PCI controller > attachments. If you are in position to confirm them working, I'd appreciate > it. I tried siisata on sparc64 ( in a 64bit/66MHz slot ) and ahcisata on a Cubietruck, both seem to work as intended. > Please report any problems, I'll fix any potential fallout ASAP. > > Performance wise, I've tested so far only sequential I/O via fio and dd > with cache enabled. I observed very mild (>2%, 72.7->74.8 MB/s) performance > increase for spinning rust HDD, but quite big increase for SSD (350->450 > MB/s). With disabled disk cache, or random I/O, NCQ will probably have more > effect. I tried sequential reads ( dd if=/dev/rwd0c ... ) and throughput took a significant hit. I used to get about 120MB/s with the siisata, now it fluctuates between 80 and 90MB/s, ahcisata dropped from about 80MB/s to 70MB/s. Both spinning rust of varying vintage. I should probably do a bonnie run on either one before & after to see if there's any change in random access. have fun Michael
Re: HEADS-UP: SATA NCQ support merged (from jdolecek-ncq branch)
Hello,
On Tue, 10 Oct 2017 23:11:54 +0200
Jaromír Doleček wrote:
> I've seen this on one of my disks, too. It seems it's much slower in NCQ
> mode. I think the firmware might not utilise the disk cache properly when
> in NCQ mode.
>
> You can try switching it off via sysctl, hw.wdX.use_ncq. You can also try
> to turn off use_ncq_prio if that makes any difference.
/home/ml# sysctl -w hw.wd1.use_ncq=0
hw.wd1.use_ncq: 1 -> 0
/home/ml# dd if=/dev/rwd1c of=/dev/null bs=1m count=2048
2048+0 records in
2048+0 records out
2147483648 bytes transferred in 21.747 secs (98748500 bytes/sec)
/home/ml# sysctl -w hw.wd1.use_ncq=1
hw.wd1.use_ncq: 0 -> 1
/home/ml# dd if=/dev/rwd1c of=/dev/null bs=1m count=2048
2048+0 records in
2048+0 records out
2147483648 bytes transferred in 26.125 secs (82200331 bytes/sec)
/home/ml# sysctl -w hw.wd1.use_ncq_prio=0
hw.wd1.use_ncq_prio: 1 -> 0
/home/ml# dd if=/dev/rwd1c of=/dev/null bs=1m count=2048
2048+0 records in
2048+0 records out
2147483648 bytes transferred in 24.187 secs (88786689 bytes/sec)
... that's the siisata:
siisata0 at pci0 dev 2 function 0: vendor 1095 product 3124 (rev. 0x02)
siisata0: interrupting at ivec 700
siisata0: SiI3124, 3.0Gb/s
siisata0: 64-bit 66MHz PCI
... with one of these:
siisata0 port 0: device present, speed: 3.0Gb/s
wd1(siisata0:0:0): using PIO mode 4, DMA mode 2, Ultra-DMA mode 5 (Ultra/100)
(using DMA), NCQ (30 tags) w/PRIO
Model: WDC WD5000AAKX-083CA1, Rev: 17.01H17, Serial #: WD-WCAYUCL72135
World Wide Name: 50014EE104595309
Device type: ATA, fixed
Capacity 500 Gbytes, 976773168 sectors, 512 bytes/sector
Cylinders: 16383, heads: 16, sec/track: 63
...
Serial ATA capabilities:
1.5Gb/s signaling
3.0Gb/s signaling
6.0Gb/s signaling
Native Command Queuing
PHY Event Counters
have fun
Michael
Re: X server being killed a lot
Hello, On Mon, 22 Oct 2018 07:34:37 +0200 Thomas Klausner wrote: > On Fri, Aug 17, 2018 at 08:20:35AM +0200, Thomas Klausner wrote: > > On Sat, Jul 28, 2018 at 06:44:50PM +0900, Izumi Tsutsui wrote: > > > > When I'm running a bulk build, the X server is a likely victim. > > > > > > > > UVM: pid 28091.1 (X), uid 0 killed: out of swap > > > > > > > > I'm not really sure why because I have lots of swap. > > > > > > > > Swap: 148G Total, 27G Used, 121G Free > > > > > > I also see the similar problem, on NetBSD/i386 8.0 with 8GB swap. > > > > > > Jul 22 09:29:25 mirage /netbsd: UVM: pid 75.1 (Xorg), uid 0 killed: out > > > of swap > > > Jul 22 22:43:04 mirage /netbsd: UVM: pid 75.1 (Xorg), uid 0 killed: out > > > of swap > > > Jul 22 22:48:24 mirage /netbsd: UVM: pid 4999.1 (Xorg), uid 0 killed: out > > > of swap > > > Jul 22 22:50:08 mirage /netbsd: UVM: pid 14199.1 (Xorg), uid 0 killed: > > > out of swap > > > Jul 22 22:58:48 mirage /netbsd: UVM: pid 3339.1 (Xorg), uid 0 killed: out > > > of swap > > > Jul 22 23:09:28 mirage /netbsd: UVM: pid 11407.1 (Xorg), uid 0 killed: > > > out of swap > > > Jul 22 23:12:20 mirage /netbsd: UVM: pid 29705.1 (Xorg), uid 0 killed: > > > out of swap > > > Jul 22 23:21:39 mirage /netbsd: UVM: pid 1100.1 (Xorg), uid 0 killed: out > > > of swap > > > > > > It seems easily reproducible by running firefox and makefs(8) > > > to create learge iso/ffs images. > > > > Does anyone have any insight in this? > > > > This is highly annoying behaviour for me - it happens even when I'm > > actively using the X session, so it's definitely not because it's the > > least-used process in the system. > > It just happened again for me. > > top says: > > CPU states: 0.2% user, 0.0% nice, 15.4% system, 17.4% interrupt, 66.8% idle > Memory: 14G Act, 6984M Inact, 10M Wired, 1758M Exec, 18G File, 59M Free > Swap: 148G Total, 148G Free > > so there is some pressure on the I/O system for file data, but no swap > use. > > It looks to me like the priority of the File section is too high, if X > is killed for that... Possibly related: I've had firefox starting to get swapped out ( and everything slowing to a crawl because of it ) while in active use, with more than half of RAM being used as file cache, and nothing hammering the filesystem either. One would think the OS would shrink the cache first, especially if it's several gigabytes. It helped somewhat to add this to sysctl.conf: vm.filemin=2 vm.filemax=10 now it still uses well over 10% or memory as file cache but seems more willing to shrink it. have fun Michael
Files in flist but missing from DESTDIR
I'm trying to ./build.sh on an RPi 3B+ and I get this error: *===checkflist ===> distrib/setscd /c/usr/src/distrib/sets && DESTDIR=/c/usr/src/obj/destdir.evbarm MACHINE=evbarm MACHINE_ARCH=earmv7hf AWK=/c/usr/src/obj/tooldir.NetBSD-8.99.45-evbarm/bin/nbawk CKSUM=/c/usr/src/obj/tooldir.NetBSD-8.99.45-evbarm/bin/nbcksum DB=/c/usr/src/obj/tooldir.NetBSD-8.99.45-evbarm/bin/nbdb EGREP=/c/usr/src/obj/tooldir.NetBSD-8.99.45-evbarm/bin/nbgrep\ -E HOST_SH=/bin/sh MAKE=/c/usr/src/obj/tooldir.NetBSD-8.99.45-evbarm/bin/nbmake MKTEMP=/c/usr/src/obj/tooldir.NetBSD-8.99.45-evbarm/bin/nbmktemp MTREE=/c/usr/src/obj/tooldir.NetBSD-8.99.45-evbarm/bin/nbmtree PAX=/c/usr/src/obj/tooldir.NetBSD-8.99.45-evbarm/bin/nbpax COMPRESS_PROGRAM=gzip GZIP=-n XZ_OPT=-9 TAR_SUFF=tgz PKG_CREATE=/c/usr/src/obj/tooldir.NetBSD-8.99.45-evbarm/bin/nbpkg_create SED=/c/usr/src/obj/tooldir.NetBSD-8.99.45-evbarm/bin/nbsed TSORT=/c/usr/src/obj/tooldir.NetBSD-8.99.45-evbarm/bin/nbtsort\ -q /bin/sh /c/usr/src/distrib/sets/checkflist -L base== 2 missing files in DESTDIR Files in flist but missing from DESTDIR.File wasn't installed ?--./usr/share/man/html8/creds_msdos.html./usr/share/man/man8/creds_msdos.8 end of 2 missing files ==* What am I doing wrong? My exact build line in /c/usr/src/ ( on a hard disk drive /c ) is: * ./build.sh -m evbarm -a earmv7hf -u release kernel=GENERIC* Thanks! Mike
How to fix missing files in flist but missing from DESTDIR ?
How is the ./build.sh error, below, fixed? == 2 missing files in DESTDIR Files in flist but missing from DESTDIR. File wasn't installed ? -- ./usr/share/man/html8/creds_msdos.html ./usr/share/man/man8/creds_msdos.8 end of 2 missing files == Thank you, Mike
Re: How to fix missing files in flist but missing from DESTDIR ?
> The source is: src/share/man/man8/creds_msdos.8 and it listed in the
Makefile in that directory.
My Makefile in *src/share/man/man8*/ does not contain *creds_msdos.8*
*# $NetBSD: Makefile,v 1.108 2019/03/25 19:24:30 maxv Exp $#
from: @(#)Makefile 8.1 (Berkeley) 6/5/93MAN=MAKEDEV.8
MAKEDEV.local.8 afterboot.8 boot.8 compat_30.8 \compat_freebsd.8
compat_linux.8 \compat_netbsd32.8 compat_sunos.8 \
compat_ultrix.8 diskless.8 hpcboot.8 \intro.8 nis.8 pam.8 rc.8
rc.subr.8 rescue.8 \sysinst.8 veriexec.8 \
wizd.8MLINKS+=MAKEDEV.8 makedev.8MLINKS+=MAKEDEV.local.8
makedev.local.8MLINKS+=compat_netbsd32.8 netbsd32.8MLINKS+=nis.8
yp.8MLINKS+=rc.8 rc.d.8MLINKS+=rc.8 rc.local.8MLINKS+=rc.8
rc.shutdown.8SUBDIR= man8.acorn32 man8.alpha man8.amiga man8.atari \
man8.cobalt man8.dreamcast man8.emips man8.evbarm \man8.hp300
man8.hpcarm man8.hpcmips man8.hpcsh man8.hppa \man8.mac68k
man8.macppc \man8.mvme68k man8.next68k man8.pmax man8.prep
man8.sandpoint \man8.sgimips man8.sparc man8.sparc64 man8.sun2
man8.sun3 \man8.vax man8.x68k man8.x86# create MAKEDEV.8 from
../../etc/MAKEDEV.tmplmakedevs:cd ${.CURDIR} && ${HOST_SH}
MAKEDEV2manpage.sh.include http://bsd.man.mk>>.include
http://bsd.subdir.mk>>*
On Thu, Jul 25, 2019 at 12:40 PM Michael Cheponis <
michael.chepo...@gmail.com> wrote:
> Thank you. I'll have a look.
>
> It's possible it's somehow related to the machine, which is RPi 3B+
> *NetBSD S.Culver.Net <http://S.Culver.Net> 8.99.45 NetBSD 8.99.45
> (GENERIC) #0: Sun Jun 16 11:05:58 UTC 2019
> mkre...@mkrepro.netbsd.org:/usr/src/sys/arch/evbarm/compile/GENERIC evbarm*
>
> What I've been doing whenever some failure occurs is:
>
> *cvs update -dP; ./build.sh -u release kernel=GENERIC *
>
>
> in the hopes that, eventually, something will get fixed upstream that will
> make this 'go away'. That's not happened so far.
>
> Thanks again,
> Mike
>
>
> On Thu, Jul 25, 2019 at 12:29 PM Martin Husemann
> wrote:
>
>> On Thu, Jul 25, 2019 at 12:06:40PM -0700, Michael Cheponis wrote:
>> > > Do you have any special MK* variables in /etc/mk.conf or passed to
>> > > build.sh?
>> > >
>> >
>> > *S# cat /etc/mk.conf*
>> > *cat: /etc/mk.conf: No such file or directory*
>> >
>> > The build line is: *./build.sh -u release kernel=GENERIC*
>>
>> Then the question is why it did not build the files (as it does for
>> everyone
>> else). The source is: src/share/man/man8/creds_msdos.8 and it listed in
>> the Makefile in that directory.
>>
>> Martin
>>
>
RPi fails sdmmc
*[ 1.000] NetBSD 9.99.18 (GENERIC) #0: Fri Nov 29 05:33:33 UTC 2019[ 1.000] m...@s.culver.net:/c/usr/src/sys/arch/evbarm/compile/obj/GENERIC* *...* *[ 1.6966742] vfp2 at cpu2: NEON MPE (VFP 3.0+), rounding, NaN propagation, denormals[ 1.7566824] sdmmc0 at bcmsdhost0[ 1.7668676] sdhc0: SDHC 3.0, rev 153, platform DMA, 20 kHz, HS 3.3V, re-tuning mode 1, 1024 byte blocks[ 1.7767371] sdmmc1 at sdhc0 slot 0[ 1.7767371] usb0 at dwctwo0: USB revision 2.0[ 1.7967412] uhub0 at usb0: NetBSD () DWC2 root hub (), class 9/0, rev 2.00/1.00, addr 1[ 1.8767483] sdmmc0: direct I/O error 5, r=6 p=0x9a9e1f4c write[ 1.8867511] sdhc0: cmd timeout error[ 1.9036427] sdmmc1: direct I/O error 60, r=6 p=0x9a1c9f4c write* I've built this 3 times over the last 2 or so weeks, each time cvs checkout with same result.
Re: RPi fails sdmmc
Hi all, This problem has gone away: *[ 1.00] NetBSD 9.99.18 (GENERIC) #0: Sat Nov 30 23:05:09 UTC 2019[ 1.00] m...@s.culver.net:/c/usr/src/sys/arch/evbarm/compile/obj/GENERIC* Thanks! On Fri, Nov 29, 2019 at 1:56 AM Michael Cheponis wrote: > > > *[ 1.000] NetBSD 9.99.18 (GENERIC) #0: Fri Nov 29 05:33:33 UTC 2019[ > 1.000] > m...@s.culver.net:/c/usr/src/sys/arch/evbarm/compile/obj/GENERIC* > *...* > > > > > > > > > *[ 1.6966742] vfp2 at cpu2: NEON MPE (VFP 3.0+), rounding, NaN > propagation, denormals[ 1.7566824] sdmmc0 at bcmsdhost0[ 1.7668676] > sdhc0: SDHC 3.0, rev 153, platform DMA, 20 kHz, HS 3.3V, re-tuning mode > 1, 1024 byte blocks[ 1.7767371] sdmmc1 at sdhc0 slot 0[ 1.7767371] usb0 > at dwctwo0: USB revision 2.0[ 1.7967412] uhub0 at usb0: NetBSD () > DWC2 root hub (), class 9/0, rev 2.00/1.00, addr 1[ 1.8767483] > sdmmc0: direct I/O error 5, r=6 p=0x9a9e1f4c write[ 1.8867511] sdhc0: cmd > timeout error[ 1.9036427] sdmmc1: direct I/O error 60, r=6 p=0x9a1c9f4c > write* > > > I've built this 3 times over the last 2 or so weeks, each time cvs > checkout with same result. > > >
RPi 3B+ pmap_tlb.c panic
*[ 81623.3847677] panic: kernel diagnostic assertion "!cpu_intr_p()" failed: file "/c/usr/src/sys/uvm/pmap/pmap_tlb.c", line 979[ 81623.3847677] cpu0: Begin traceback...[ 81623.3847677] 0x9df29aac: netbsd:vpanic+0x16c[ 81623.3847677] Bad frame pointer: 0x80ab79bc[ 81623.3847677] cpu0: End traceback...[ 81623.3847677] dump to dev 92,1 not possible[ 81623.3847677] rebootin[ 1.000] NetBSD/evbarm (fdt) booting ...* *[ 1.000] NetBSD 9.99.23 (GENERIC) #0: Sat Dec 14 15:13:34 UTC 2019[ 1.000] m...@s.culver.net:/c/usr/src/sys/arch/evbarm/compile/obj/GENERIC* While ./build.sh -j 9 of -current of this morning. I've seen this particular panic since about 9.99.20 [ It goes into rebootin' after crash. (lost the 'g' ?) ] >From 'top -S -s1' at the time of the panic: *load averages: 8.57, 8.34, 7.64; up 0+22:40:53 23:30:4680 processes: 6 runnable, 69 sleeping, 1 zombie, 4 on CPUCPU0 states: 74.3% user, 0.0% nice, 22.8% system, 3.0% interrupt, 0.0% idleCPU1 states: 72.3% user, 0.0% nice, 27.7% system, 0.0% interrupt, 0.0% idleCPU2 states: 58.4% user, 0.0% nice, 41.6% system, 0.0% interrupt, 0.0% idleCPU3 states: 89.1% user, 0.0% nice, 10.9% system, 0.0% interrupt, 0.0% idleMemory: 195M Act, 196M Inact, 13M Wired, 32M Exec, 291M File, 214M FreeSwap: 6723M Total, 121M Used, 6601M Free PID USERNAME PRI NICE SIZE RES STATE TIME WCPUCPU COMMAND29986 root 25040M 26M CPU/3 0:01 47.62% 6.64% /c/usr/src/obj/tooldir.NetBSD-9.99.23-evbarm/libexec/gcc/armv7--netbsdelf-eabihf/8.3.0/cc1 -qui 8066 root 25035M 26M RUN/0 0:01 46.57% 6.49% /c/usr/src/obj/tooldir.NetBSD-9.99.23-evbarm/libexec/gcc/armv7--netbsdelf-eabihf/8.3.0/cc1 -qui18153 root 25034M 25M CPU/1 0:01 37.82% 5.27% /c/usr/src/obj/tooldir.NetBSD-9.99.23-evbarm/libexec/gcc/armv7--netbsdelf-eabihf/8.3.0/cc1 -qui 3385 root 26034M 18M RUN/2 0:00 38.95% 3.71% /c/usr/src/obj/tooldir.NetBSD-9.99.23-evbarm/libexec/gcc/armv7--netbsdelf-eabihf/8.3.0/cc1 -qui14026 root 26032M 17M RUN/1 0:00 23.06% 2.20% /c/usr/src/obj/tooldir.NetBSD-9.99.23-evbarm/libexec/gcc/armv7--netbsdelf-eabihf/8.3.0/cc1 -qui28552 root 25033M 17M CPU/2 0:00 22.04% 2.10% /c/usr/src/obj/tooldir.NetBSD-9.99.23-evbarm/libexec/gcc/armv7--netbsdelf-eabihf/8.3.0/cc1 -qui22028 root 26012M 6200K RUN/2 0:01 1.76% 1.66% /c/usr/src/obj/tooldir.NetBSD-9.99.23-evbarm/bin/nbmake realall 1549 root 420 9192K 2480K CPU/0 10:27 1.61% 1.61% top -S -s1 2177 root 26033M 16M RUN/2 0:00 31.00% 1.51% /c/usr/src/obj/tooldir.NetBSD-9.99.23-evbarm/libexec/gcc/armv7--netbsdelf-eabihf/8.3.0/cc1 -qui25965 root 26031M 15M RUN/3 0:00 14.00% 0.68% /c/usr/src/obj/tooldir.NetBSD-9.99.23-evbarm/libexec/gcc/armv7--netbsdelf-eabihf/8.3.0/cc1 -qui* Thanks all, Mike
Re: RPi 3B+ on -current: panic: kernel diagnostic assertion "!cpu_intr_p()" failed: file "/c/usr/src/sys/uvm/pmap/pmap_tlb.c", line 980
Here was top -S -s1 when panic: load averages: 7.10, 5.33, 5.03; up 0+07:32:10 12:39:10 67 processes: 5 runnable, 58 sleeping, 4 on CPU CPU0 states: 50.5% user, 0.0% nice, 45.5% system, 4.0% interrupt, 0.0% idle CPU1 states: 78.2% user, 0.0% nice, 21.8% system, 0.0% interrupt, 0.0% idle CPU2 states: 67.3% user, 0.0% nice, 32.7% system, 0.0% interrupt, 0.0% idle CPU3 states: 61.4% user, 0.0% nice, 38.6% system, 0.0% interrupt, 0.0% idle Memory: 129M Act, 98M Inact, 13M Wired, 30M Exec, 151M File, 408M Free Swap: 3425M Total, 102M Used, 3323M Free PID USERNAME PRI NICE SIZE RES STATE TIME WCPUCPU COMMAND 26988 root 25034M 20M RUN/2 0:00 26.00% 1.27% /c/usr/src/obj/tooldir.NetBSD-9.99.29-evbarm/libexec/gcc/armv7--netbsdelf-eabihf/8.3.0/cc1 -quiet -I /c/usr/src/external/gpl3/ 4369 root 25033M 18M CPU/1 0:00 25.00% 1.22% /c/usr/src/obj/tooldir.NetBSD-9.99.29-evbarm/libexec/gcc/armv7--netbsdelf-eabihf/8.3.0/cc1 -quiet -I /c/usr/src/external/gpl3/ 6448 root 25033M 18M RUN/2 0:00 21.00% 1.03% /c/usr/src/obj/tooldir.NetBSD-9.99.29-evbarm/libexec/gcc/armv7--netbsdelf-eabihf/8.3.0/cc1 -quiet -I /c/usr/src/external/gpl3/ 21425 root 770 9528K 4664K poll/1 0:00 1.15% 0.88% /c/usr/src/obj/tooldir.NetBSD-9.99.29-evbarm/bin/nbmake realall 25869 root 850 8192K 1920K poll/1 0:08 0.20% 0.20% /c/usr/src/obj/tooldir.NetBSD-9.99.29-evbarm/bin/nbmake _THISDIR_ do-lib 9707 root 840 8048K 2968K poll/1 0:00 0.12% 0.10% /c/usr/src/obj/tooldir.NetBSD-9.99.29-evbarm/bin/nbmake _THISDIR_ dependall 22339 root 25033M 17M RUN/3 0:00 1.00% 0.05% /c/usr/src/obj/tooldir.NetBSD-9.99.29-evbarm/libexec/gcc/armv7--netbsdelf-eabihf/8.3.0/cc1 -quiet -I /c/usr/src/external/gpl3/ 407 root 420 8272K 2464K CPU/2 4:52 0.00% 0.00% top -S -s1 11711 root 26031M 15M CPU/3 0:00 0.00% 0.00% /c/usr/src/obj/tooldir.NetBSD-9.99.29-evbarm/libexec/gcc/armv7--netbsdelf-eabihf/8.3.0/cc1 -quiet -I /c/usr/src/external/gpl3/ 694 root 25033M 15M CPU/0 0:00 0.00% 0.00% /c/usr/src/obj/tooldir.NetBSD-9.99.29-evbarm/libexec/gcc/armv7--netbsdelf-eabihf/8.3.0/cc1 -quiet -I /c/usr/src/external/gpl3/ 20179 root 25033M 16M RUN/3 0:00 0.00% 0.00% /c/usr/src/obj/tooldir.NetBSD-9.99.29-evbarm/libexec/gcc/armv7--netbsdelf-eabihf/8.3.0/cc1 -quiet -I /c/usr/src/external/gpl3/ 11952 root 250 2200K 32K RUN/1 0:00 0.00% 0.00% /c/usr/src/obj/tooldir.NetBSD-9.99.29-evbarm/bin/armv7--netbsdelf-eabihf-gcc -O2 -pthread -std=gnu99 -Wall -Wstrict-prototypes On Tue, Dec 24, 2019 at 7:48 AM Michael Cheponis wrote: > > > > > > > > > > > > > > > > > > > > *[ 27080.9793774] panic: kernel diagnostic assertion "!cpu_intr_p()" > failed: file "/c/usr/src/sys/uvm/pmap/pmap_tlb.c", line 980[ 27080.9793774] > cpu0: Begin traceback...[ 27080.9793774] 0xa7a29aac: netbsd:vpanic+0x16c[ > 27080.9793774] Bad frame pointer: 0x80ad537c[ 27080.9793774] cpu0: End > traceback...[ 27080.9793774] dump to dev 92,1 not possible[ 27080.9793774] > bcmsdhost0: transfer timeout![ 27080.9793774] ld0a: error writing fsbn > 2979728 of 2979728-2979743 (ld0 bn 3438480; cn 1678 tn 60 sn 16), retrying[ > 27080.9793774] rebootin[ 1.000] NetBSD/evbarm (fdt) booting ...[ > 1.000] [ Kernel symbol table missing! ][ 1.000] pool redzone > disabled for 'kmem-8192'[ 1.000] Copyright (c) 1996, 1997, 1998, > 1999, 2000, 2001, 2002, 2003, 2004, 2005,[ 1.000] 2006, 2007, > 2008, 2009, 2010, 2011, 2012, 2013, 2014, 2015, 2016, 2017,[ 1.000] > 2018, 2019 The NetBSD Foundation, Inc. All rights reserved.[ > 1.000] Copyright (c) 1982, 1986, 1989, 1991, 1993[ 1.000] The > Regents of the University of California. All rights reserved.[ > 1.000] NetBSD 9.99.29 (GENERIC) #0: Tue Dec 24 03:30:54 UTC 2019[ > 1.000] m...@s.culver.net:/c/usr/src/sys/arch/evbarm/compile/obj/GENERIC* > > > The last 'truly stable' kernel that I've seen for RPi is 9.99.17 > > Thanks again, > Mike > >
RPi 3B+ on -current: panic: kernel diagnostic assertion "!cpu_intr_p()" failed: file "/c/usr/src/sys/uvm/pmap/pmap_tlb.c", line 980
*[ 27080.9793774] panic: kernel diagnostic assertion "!cpu_intr_p()" failed: file "/c/usr/src/sys/uvm/pmap/pmap_tlb.c", line 980[ 27080.9793774] cpu0: Begin traceback...[ 27080.9793774] 0xa7a29aac: netbsd:vpanic+0x16c[ 27080.9793774] Bad frame pointer: 0x80ad537c[ 27080.9793774] cpu0: End traceback...[ 27080.9793774] dump to dev 92,1 not possible[ 27080.9793774] bcmsdhost0: transfer timeout![ 27080.9793774] ld0a: error writing fsbn 2979728 of 2979728-2979743 (ld0 bn 3438480; cn 1678 tn 60 sn 16), retrying[ 27080.9793774] rebootin[ 1.000] NetBSD/evbarm (fdt) booting ...[ 1.000] [ Kernel symbol table missing! ][ 1.000] pool redzone disabled for 'kmem-8192'[ 1.000] Copyright (c) 1996, 1997, 1998, 1999, 2000, 2001, 2002, 2003, 2004, 2005,[ 1.000] 2006, 2007, 2008, 2009, 2010, 2011, 2012, 2013, 2014, 2015, 2016, 2017,[ 1.000] 2018, 2019 The NetBSD Foundation, Inc. All rights reserved.[ 1.000] Copyright (c) 1982, 1986, 1989, 1991, 1993[ 1.000] The Regents of the University of California. All rights reserved.[ 1.000] NetBSD 9.99.29 (GENERIC) #0: Tue Dec 24 03:30:54 UTC 2019[ 1.000] m...@s.culver.net:/c/usr/src/sys/arch/evbarm/compile/obj/GENERIC* The last 'truly stable' kernel that I've seen for RPi is 9.99.17 Thanks again, Mike
odd panic
what does this mean? (Received last night on RPi 3B+ that has been h/w stable): panic: kernel diagnostic assertion "uvmexp.swpgonly + npages <= uvmexp.swpginuse" failed: file "/c/usr/src/sys/uvm/uvm_pager.c", line 472 load averages: 3.32, 3.72, 3.93; up 0+11:45:09 09:54:27UTC 63 processes: 6 runnable, 53 sleeping, 4 on CPU CPU0 states: 68.6% user, 0.0% nice, 27.6% system, 3.8% interrupt, 0.0% idle CPU1 states: 94.3% user, 0.0% nice, 5.7% system, 0.0% interrupt, 0.0% idle CPU2 states: 89.5% user, 0.0% nice, 10.5% system, 0.0% interrupt, 0.0% idle CPU3 states: 74.0% user, 0.0% nice, 17.3% system, 8.7% interrupt, 0.0% idle Memory: 403M Act, 204M Inact, 13M Wired, 31M Exec, 259M File, 15M Free Swap: 3425M Total, 7912K Used, 3418M Free [ 1.000] NetBSD 9.99.17 (GENERIC) #2: Wed Nov 13 09:59:13 UTC 2019 [ 1.000] m...@s.culver.net: /c/usr/src/sys/arch/evbarm/compile/obj/GENERIC after reboot: # swapctl -l Device 1K-blocks UsedAvail Capacity Priority /dev/ld0b 1310720 131072 0%1 /swapfile 33763840 3376384 0%2 Total 35074560 3507456 0 So it seems like there was plenty of Swap available. -Mike
9.99.30 panic
Dec 29 00:03:51 S /netbsd: [ 1.000] NetBSD 9.99.30 (GENERIC) #0: Fri Dec 27 22:32:00 UTC 2019 Dec 29 00:03:51 S /netbsd: [ 1.000] m...@s.culver.net: /c/usr/src/sys/arch/evbarm/compile/obj/GENERIC Dec 29 00:03:51 S /netbsd: [ 28921.9058062] panic: kernel diagnostic assertion "!cpu_intr_p()" failed: file "/c/usr/src/sys/uvm/pmap/pmap_tlb.c", line 980 Dec 29 00:03:51 S /netbsd: [ 28921.9058062] cpu0: Begin traceback... Dec 29 00:03:51 S /netbsd: [ 28921.9058062] 0xa3c59aac: netbsd:vpanic+0x16c Dec 29 00:03:51 S /netbsd: [ 28921.9058062] Bad frame pointer: 0x80ad55fc Dec 29 00:03:51 S /netbsd: [ 28921.9058062] cpu0: End traceback... RPi 3B+ from -current yesterday ./build.sh -j 9
bug in build for RPi (GENERIC)
*--- dependall-exec_elf32
---/c/usr/src/obj/tooldir.NetBSD-9.99.17-evbarm/bin/nbctfconvert -L VERSION
exec_elf32.o--- core_elf32.o ---# compile
exec_elf32/core_elf32.o/c/usr/src/obj/tooldir.NetBSD-9.99.17-evbarm/bin/armv7--netbsdelf-eabihf-gcc
-O2 -g -std=gnu99-Wall -Wstrict-prototypes -Wmissing-prototypes
-Wpointer-arith -Wno-sign-compare -Wsystem-headers -Wno-traditional
-Wa,--fatal-warnings -Wreturn-type -Wswitch\ -Wshadow -Wcast-qual
-Wwrite-strings -Wextra -Wno-unused-parameter -Wno-sign-compare -Werror
-ffreestanding -fno-strict-aliasing -Wno-pointer-sign -fno-common
-fno-unwind-tables -mfloat-abi=soft -I/c/usr/src/common/include
-DDIAGNOSTIC --sysroot=/c/usr/src/o\bj/destdir.evbarm -DEXEC_ELF32
-DPAX_ASLR -I/c/usr/src/common/include -DDIAGNOSTIC -nostdinc -I.
-I/c/usr/src/sys/modules/exec_elf32 -isystem /c/usr/src/sys -isystem
/c/usr/src/sys/arch -isystem /c/usr/src/sys/../common/include -D_KERNEL
-D_LKM -D_MODULE -DSYSCTL\_INCLUDE_DESCR -c
/c/usr/src/sys/kern/core_elf32.c--- dependall-compat_netbsd32
---/tmp/genassym.g0QgV8/assym.c: In function
'f64':/tmp/genassym.g0QgV8/assym.c:57:1: error: asm operand 0 probably
doesn't match constraints [-Werror] __asm("XYZZY VM_MIN_ADDRESS %0" : : "n"
(VM_MIN_ADDRESS)); ^/tmp/genassym.g0QgV8/assym.c:58:1: error: asm
operand 0 probably doesn't match constraints [-Werror] __asm("XYZZY
VM_MAXUSER_ADDRESS %0" : : "n" (VM_MAXUSER_ADDRESS)); ^---
dependall-udf
---/c/usr/src/obj/tooldir.NetBSD-9.99.17-evbarm/bin/nbctfconvert -L VERSION
udf_vfsops.o--- dependall-compat_netbsd32
---/tmp/genassym.g0QgV8/assym.c:97:1: error: asm operand 0 probably doesn't
match constraints [-Werror] __asm("XYZZY PAGE_MASK %0" : : "n"
(PAGE_MASK)); ^/tmp/genassym.g0QgV8/assym.c:98:1: error: asm operand 0
probably doesn't match constraints [-Werror] __asm("XYZZY PAGE_SIZE %0" : :
"n" (PAGE_SIZE)); ^/tmp/genassym.g0QgV8/assym.c:57:1: error: impossible
constraint in 'asm' __asm("XYZZY VM_MIN_ADDRESS %0" : : "n"
(VM_MIN_ADDRESS)); ^/tmp/genassym.g0QgV8/assym.c:58:1: error:
impossible constraint in 'asm' __asm("XYZZY VM_MAXUSER_ADDRESS %0" : : "n"
(VM_MAXUSER_ADDRESS)); ^/tmp/genassym.g0QgV8/assym.c:97:1: error:
impossible constraint in 'asm' __asm("XYZZY PAGE_MASK %0" : : "n"
(PAGE_MASK)); ^/tmp/genassym.g0QgV8/assym.c:98:1: error: impossible
constraint in 'asm' __asm("XYZZY PAGE_SIZE %0" : : "n" (PAGE_SIZE)); ^~~*~~
Re: File corruption?
FWIW, the last 'completely stable' -current on RPi 3B+ has been 9.99.17 as well. I don't know what has happened, but there seem to be some regressions from that time onward. -Mike On Thu, Jan 16, 2020 at 6:20 PM Robert Nestor wrote: > I’ve got NetBSD-9.99.17 (amd64) installed and it has been running without > any problems which i have been using to work with NVMM. I do package > builds on it using pkgsrc-current and also do the build of wip/qemu-nvmm. > > This morning I installed NetBSD-9.99.38 (Jan 15th build) on another disk. > I copied my current copy of pkgsrc over to the new disk to build some of > the packages I use under the new system. When I went into the pkgsrc/wip > directory and did a “git pull -r” it complained about file corruption. I > tired the same command in the pkgsrc/wip directory on my 9.99.17 system and > got the same error. I rebooted into the 9.99.17 system and the update ran > fine. Under the 9.99.38 system I tried just downloading a new checkout of > the wip directory and it failed with file corruption errors similar to when > I tried to do an update. > > The package builds under 9.99.38 with all the recent changes do run a heck > of a lot faster, but it seems like there might be an underlying problem > that causes file corruption. Assuming this is the case, is there something > I can do to help uncover what might be going on? > > -bob
9.99.38 RPi 3B+ panic: kernel diagnostic assertion "cold || sent_p || ncpu <= 1" failed: file "/c/usr/src/sys/arch/arm/pic/pic.c", line 206
*[ 363906.7911703] unmounting file systems...[ 363909.1814446] unmounting done[ 363909.1914472] rebootin[ 1.000] NetBSD/evbarm (fdt) booting ...[ 1.000] [ Kernel symbol table missing! ][ 1.000] pool redzone disabled for 'kmem-8192'[ 1.000] Copyright (c) 1996, 1997, 1998, 1999, 2000, 2001, 2002, 2003, 2004, 2005,[ 1.000] 2006, 2007, 2008, 2009, 2010, 2011, 2012, 2013, 2014, 2015, 2016, 2017,[ 1.000] 2018, 2019, 2020 The NetBSD Foundation, Inc. All rights reserved.[ 1.000] Copyright (c) 1982, 1986, 1989, 1991, 1993[ 1.000] The Regents of the University of California. All rights reserved.[ 1.000] NetBSD 9.99.38 (GENERIC) #0: Fri Jan 17 04:39:25 UTC 2020[ 1.000] m...@s.culver.net:/c/usr/src/sys/arch/evbarm/compile/obj/GENERIC[ 1.000] total memory = 948 MB[ 1.000] avail memory = 927 MB[ 1.000] pool redzone disabled for 'buf64k'[ 1.000] armfdt0 (root)[ 1.000] simplebus0 at armfdt0: Raspberry Pi 3 Model B Plus Rev 1.3[ 1.000] simplebus1 at simplebus0[ 1.000] simplebus2 at simplebus0[ 1.000] cpus0 at simplebus0[ 1.000] simplebus3 at simplebus0[ 1.000] cpu0 at cpus0: 600 MHz Cortex-A53 r0p4 (Cortex V8A core)[ 1.000] cpu0: DC enabled IC enabled WB enabled EABT branch prediction enabled[ 1.000] cpu0: 32KB/64B 2-way L1 VIPT Instruction cache[ 1.000] cpu0: 32KB/64B 4-way write-back-locking-C L1 PIPT Data cache[ 1.000] cpu0: 512KB/64B 16-way write-through L2 PIPT Unified cache[ 1.000] vfp0 at cpu0: NEON MPE (VFP 3.0+), rounding, NaN propagation, denormals[ 1.000] cpu1 at cpus0[ 1.000] cpu2 at cpus0[ 1.000] cpu3 at cpus0[ 1.000] simplebus4 at simplebus1[ 1.000] bcmicu0 at simplebus1[ 1.000] bcmcprman0 at simplebus1: BCM283x Clock Controller[ 1.000] fclock0 at simplebus2: 1920 Hz fixed clock (osc)[ 1.000] bcmaux0 at simplebus1[ 1.000] fclock1 at simplebus2: 48000 Hz fixed clock (otg)[ 1.000] bcmicu1 at simplebus1: Multiprocessor[ 1.000] gtmr0 at simplebus0: Generic Timer[ 1.000] gtmr0: interrupting on local_intc irq 3[ 1.000] armgtmr0 at gtmr0: Generic Timer (19200 kHz, virtual)[ 1.030] plcom0 at simplebus1: ARM PL011 UART[ 1.030] plcom0: txfifo disabled[ 1.030] plcom0: interrupting on icu irq 57[ 1.030] com0 at simplebus1: BCM AUX UART, working fifo[ 1.030] com0: console[ 1.030] com0: interrupting on icu irq 29[ 1.030] fregulator0 at simplebus0: 3v3[ 1.030] fregulator1 at simplebus0: 5v0[ 1.030] usbnopphy0 at simplebus0: USB PHY[ 1.030] /soc/thermal@7e212000 at simplebus1 not configured[ 1.030] /soc/dsi@7e209000 at simplebus1 not configured[ 1.030] bcmgpio0 at simplebus1: GPIO controller 2835[ 1.030] bcmgpio0: pins 0..31 interrupting on icu irq 49[ 1.030] bcmgpio0: pins 32..54 interrupting on icu irq 50[ 1.030] gpio0 at bcmgpio0: 54 pins[ 1.030] bcmdmac0 at simplebus1: DMA0 DMA2 DMA4 DMA5 DMA8 DMA9 DMA10[ 1.030] /soc/power at simplebus1 not configured[ 1.030] bcmmbox0 at simplebus1: VC mailbox[ 1.030] bcmmbox0: interrupting on icu irq 65[ 1.030] vcmbox0 at bcmmbox0[ 1.030] bcmpmwdog0 at simplebus1: Power management, Reset and Watchdog controller[ 1.030] bcmrng0 at simplebus1: RNG[ 1.030] bcmsdhost0 at simplebus1: SD HOST controller[ 1.030] bcmsdhost0: interrupting on icu irq 56[ 1.030] sdhc0 at simplebus1: SDHC controller[ 1.030] sdhc0: interrupting on icu irq 62[ 1.030] dwctwo0 at simplebus1: USB controller[ 1.030] dwctwo0: interrupting on icu irq 9[ 1.030] gpioleds0 at simplebus0: led0[ 1.030] /soc/firmware/expgpio at simplebus4 not configured[ 1.030] vchiq0 at simplebus1: BCM2835 VCHIQ[ 1.030] /soc/fb at simplebus1 not configured[ 1.030] /soc/vcsm at simplebus1 not configured[ 1.030] armpmu0 at simplebus0: Performance Monitor Unit[ 1.030] /soc/gpiomem at simplebus1 not configured[ 1.030] cpu_topology_init: info bogus, faking it[ 1.4748744] cpu2: 600 MHz Cortex-A53 r0p4 (Cortex V8A core)[ 1.4748744] cpu2: DC enabled IC enabled WB enabled EABT branch prediction enabled[ 1.4848750] cpu2: 32KB/64B 2-way L1 VIPT Instruction cache[ 1.4848750] cpu2: 32KB/64B 4-way write-back-locking-C L1 PIPT Data cache[ 1.4948783] cpu2: 512KB/64B 16-way write-through L2 PIPT Unified cache[ 1.5048754] vfp2 at cpu2: NEON MPE (VFP 3.0+), rounding, NaN propagation, denormals[ 1.5048754] cpu1: 600 MHz Cortex-A53 r0p4 (Cortex V8A core)[ 1.5148779] cpu1: DC enabled IC enabled WB enabled EABT branch prediction enabled[ 1.5248776] cpu1: 32KB/64B 2-way L1 VIPT Instruction cache[ 1.5248776] cpu1: 32KB/64B 4-way write-back-locking-C L1 PIPT Data cache[ 1.5348824] cpu1: 512KB/64B 16-way write-through L2 PIPT Unified cache[ 1.5448802] vfp1 at cpu1: NEON MPE (VFP 3.0+), rounding, NaN propagation, denormals[ 1.544
9.99.17 on RPi 3B+ panic
This particular version of 9.99.17 has been extremely stable for me for several months. Now I tried copying the contents of sd1 to a bigger USB (hard) disk. Didn't complete due to panic: panic: kernel diagnostic assertion "offset < dma->udma_block->size" failed: file "/c/usr/src/sys/dev/usb/usb_mem.c", line 383 offset 65536 vs 65536 Maybe this has been fixed in newer -current? True, I didn't fsck this sd1 drive. But, even so, if there's something wrong with the fs, it's shouldn't panic. Thanks again, all, for the tremendous work and continued perseverance. *[ 165872.8892151] umass1 at uhub3 port 4 configuration 1 interface 0[ 165872.8998795] umass1: Lexar (0x5dc) USB Flash Drive (0xa838), rev 2.10/11.00, addr 7[ 165872.9110765] scsibus1 at umass1: 2 targets, 1 lun per target[ 165873.0999142] sd1 at scsibus1 target 0 lun 0: disk removable[ 165873.1099178] sd1: fabricating a geometry[ 165873.1099178] sd1: 61054 MB, 61054 cyl, 64 head, 32 sec, 512 bytes/sect x 125038592 sectors[ 165873.1299255] sd1: fabricating a geometry[165903.8144229] /dev/sd1e: file system not clean (fs_clean=0x8); please fsck(8)[ 165903.8283906] /dev/sd1e: lost blocks 0 files 0[ 169039.9242134] panic: kernel diagnostic assertion "offset < dma->udma_block->size" failed: file "/c/usr/src/sys/dev/usb/usb_mem.c", line 383 offset 65536 vs 65536[ 169039.9242134] cpu0: Begin traceback...[ 169039.9242134] 0x80b55cbc: netbsd:db_panic+0x14[ 169039.9242134] 0x80b55cd4: netbsd:vpanic+0x194[ 169039.9242134] 0x80b55cec: netbsd:__aeabi_uldivmod[ 169039.9242134] 0x80b55d2c: netbsd:usb_dmaaddr+0x124[ 169039.9242134] 0x80b55d4c: netbsd:dwc2_hc_init_xfer_data.isra.12+0x38[ 169039.9242134] 0x80b55d8c: netbsd:dwc2_assign_and_init_hc+0x45c[ 169039.9242134] 0x80b55dc4: netbsd:dwc2_hcd_select_transactions+0x160[ 169039.9242134] 0x80b55de4: netbsd:dwc2_release_channel+0x188[ 169039.9242134] 0x80b55e2c: netbsd:dwc2_handle_hcd_intr+0xc08[ 169039.9242134] 0x80b55e4c: netbsd:dwc2_intr+0x78[ 169039.9242134] 0x80b55e74: netbsd:pic_dispatch+0x38[ 169039.9242134] 0x80b55f04: netbsd:pic_do_pending_ints+0x40c[ 169039.9242134] 0x80b55f6c: netbsd:irq_entry+0x68[ 169039.9242134] 0x80b55fac: netbsd:idle_loop+0x1a0[ 169039.9242134] cpu0: End traceback...[ 169039.9242134] dump to dev 92,1 not possible[ 169039.9242134] rebootin[ 1.000] NetBSD/evbarm (fdt) booting ...[ 1.000] [ Kernel symbol table missing! ][ 1.000] pool redzone disabled for 'kmem-8192'[ 1.000] Copyright (c) 1996, 1997, 1998, 1999, 2000, 2001, 2002, 2003, 2004, 2005,[ 1.000] 2006, 2007, 2008, 2009, 2010, 2011, 2012, 2013, 2014, 2015, 2016, 2017,[ 1.000] 2018, 2019 The NetBSD Foundation, Inc. All rights reserved.[ 1.000] Copyright (c) 1982, 1986, 1989, 1991, 1993[ 1.000] The Regents of the University of California. All rights reserved.[ 1.000] NetBSD 9.99.17 (GENERIC) #2: Wed Nov 13 09:59:13 UTC 2019[ 1.000] m...@s.culver.net:/c/usr/src/sys/arch/evbarm/compile/obj/GENERIC*
panic: sw_reg_strategy: swap to sparse file 9.99.56 GENERIC
$ xz -k9 really.big.file.tar (about 2 GB)
I have a 3G /c/swapfile on a rotating HD at priority 0 for swap.
*[ 1.000] NetBSD 9.99.56 (GENERIC) #0: Tue Apr 14 14:14:02 UTC 2020[
1.000]
m...@s.culver.net:/c/usr/src/sys/arch/evbarm/compile/obj/GENERIC*
*[ 102791.8683015] panic: sw_reg_strategy: swap to sparse file*
*[ 102791.8783036] cpu2: Begin traceback...[ 102791.8783036] 0xbae43d34:
netbsd:db_panic+0x14[ 102791.8783036] 0xbae43d4c: netbsd:vpanic+0x170[
102791.8883019] 0xbae43d64: netbsd:snprintf[ 102791.8883019] 0xbae43ddc:
netbsd:swstrategy+0x3ac[ 102791.8983034] 0xbae43e04:
netbsd:bdev_strategy+0xcc[ 102791.8983034] 0xbae43e34:
netbsd:spec_strategy+0xb8[ 102791.9083030] 0xbae43e64:
netbsd:VOP_STRATEGY+0x58[ 102791.9083030] 0xbae43eac:
netbsd:uvm_swap_io+0x138[ 102791.9183032] 0xbae43ed4:
netbsd:swapcluster_flush.part.2+0x9c[ 102791.9183032] 0xbae43fac:
netbsd:uvm_pageout+0x4b4[ 102791.9283042] cpu2: End traceback...Stopped in
pid 0.76 (system) at netbsd:cpu_Debugger+0x4:bx r14db{2}> ps
/lPIDLID S CPU FLAGS STRUCT LWP * NAME
WAIT107011 3 080 9970ed00 sshd
netio8247 1 3 1 0 97b9f880 xz
biowait7175 1 3 280 92fb8140 pickup
kqueue111561 3 080 93922180 python3.8
ttyraw712 1 3 380 92f97600zsh
pause997 1 3 180 92e9bb40 sh
wait940 1 3 080 92e9b5c0zsh
pause427 1 3 1c0 92e9b300 screen
select586 1 3 180 92e9b040 screen
pause331 1 3 180 918347c0zsh
pause575 1 3 080 92cfbd40 sshd
select509 1 3 180 92cfb7c0 sshd
poll294 1 3 080 92aec780zsh
pause160 1 3 080 9191c5c0 sh
wait762 1 3 180 92aec4c0zsh
pause889 1 3 180 91991600 screen
select792 1 3 280 92aec200 screen
pause625 1 3 080 91991b80zsh
pause496 1 3 280 919918c0 sshd
select654 1 3 180 9296ecc0 sshd
poll643 1 3 280 91d7d3c0zsh
ttyraw231 1 3 380 91d7d100 sh
wait676 1 3 180 9191c880zsh
pause793 1 3 180 9296e740 screen
select860 1 3 280 91991340 screen
pause98 1 3 180 9296e480zsh
pause488 1 3 080 928ad700 sshd
select751 1 3 380 9296e1c0 sshd
poll529 1 3 080 928adc80zsh
ttyraw777 1 3 080 922b2400 sh
wait709 1 3 280 928ad9c0zsh
pause611 1 3 080 928ad180 screen
select760 1 3 080 9179c780 screen
pause629 1 3 080 91d7dc00zsh
pause716 1 3 3c0 915eea80 login
wait400 1 3 280 928ad440 cron
nanoslp466 1 3 080 9191cb40 inetd
kqueue638 1 3 280 922b26c0 qmgr
kqueue622 1 3 180 922b2980 master
kqueue426 1 3 280 91d74900 sshd
select349 1 3 180 91d7d680 timed
poll415 1 2 1 100 91d740c0 ntpd372
1 3 080 91d74bc0devpubd devmon211 1 3
380 91991080syslogd kqueue187 1 3 0
80 91834d40 mdnsd select11 3 1
80 916a2c40 init wait0> 80 7 1 200
91d74640swapiod0 71 3 1 200
914fed00physiod physiod0 69 3 1 200
916af9c0 bwfm0 bwfm00 79 3 0 280
9179c4c0 VCHIQka-0 lnxcmplt0 78 3 1 200
9179c200 pooldrain pooldrain0 77 3 0 200
91797cc0ioflush syncer0> 76 7 2 240
91797a00 pgdaemon0 75 3 3 280 91797740
Re: blacklist -> blocklist in current
$ grep -i ^black /usr/share/dict/words | wc 92 92 976 $ grep -i ^white /usr/share/dict/words | wc 70 70 725 It's an uphill climb, but naming https://martinfowler.com/bliki/TwoHardThings.html is one of two hard things. Yes, we can do better. On Mon, Jun 15, 2020 at 12:44 PM Christos Zoulas wrote: > Hi Marc, > > When I wrote this in 2015 I did not consider the terms blacklist/whitelist > offensive, > or associated them with race. If as was going to name the program today I > would > have chosen differently; perhaps I would have chosen 'denylist' instead of > 'blocklist', > (I smirk because the spell-checker autocorrected blocklist to blacklist > even when I had > it in quotes and I had to change it back), but I would not have called it > blacklist. > > I made the poor naming choice in 2015, and I needed to fix it. I decided > to do it quickly, > and I did not want to have a discussion about it -- I was going to do it > anyway. I believe > that as insignificant and annoying that change might seem to some, it is a > move in the > right direction and I hope that it will inspire/encourage others to make > similar changes > where appropriate. > > We should be all doing whatever we can to correct social/race/gender/sex > injustices/prejudices around us, and every little bit helps. > > Best, > > christos > > > > > On Jun 15, 2020, at 3:02 PM, Marc Balmer wrote: > > > > And you just do that based on you own opinion, without previous > discussion, breaking existing confugurations, and all you have to offer is > a „sorry for the inconvenience“? > > > > That inconvenience was not needed and nobody asked for it. > > > >> Am 15.06.2020 um 04:02 schrieb Christos Zoulas : > >> > >> > >> Hello folks, > >> > >> I've renamed blacklist to blocklist, so if you are currently using it, > >> you should rename things accordingly: > >> > >> - rc.conf variable > >> - /var/db/blacklist.db file > >> - npf table name > >> > >> Apologies for the inconvenience, > >> > >> christos > >
Re: RPI3 serlial clock confusion?
I have been running 9.99.17 on RPi3+ and did ./build.sh current, which produced 9.99.69 -- and it works perfectly, no garbling. I just copied src/sys/arch/evbarm/compile/obj/GENERIC/netbsd.img to /boot/KERNEL7.IMG and rebooted. # sysctl -a|grep freq machdep.cpu.frequency.target = 1400 machdep.cpu.frequency.current = 1400 machdep.cpu.frequency.min = 600 machdep.cpu.frequency.max = 1400 machdep.cpu.frequency.available = 600 1400 So I'm now more confused than ever. On Wed, Jul 8, 2020 at 9:03 AM Michael van Elst wrote: > kar...@netbsd.org (Frank Kardel) writes: > > >The next message is the setting of the maxiimum frequency which hoses the > >RPI3B serial port speed. Do we have a clock setting/source issue here? > > It's a hardware limitation, the UART frequency is coupled with the > CPU frequency. > > You can either run with a fixed CPU frequency or configure the other UART > as serial port. The latter then causes problems with the bluetooth > controller. > > -- > -- > Michael van Elst > Internet: mlel...@serpens.de > "A potential Snark may lurk in every tree." >
Re: RPI3 serlial clock confusion?
It must be the dtb files. Yes, the console is perfect with 9.99.69 with (ahem) .17 good dtb files ... ;-) Thing is, if this is true - how does it work? And, has this discussion about cpu speed coupled with UART speed been incorrect? On Wed, Jul 8, 2020 at 11:58 PM Frank Kardel wrote: > You are looking at the console port running at 115200 at boot time, right? > > My 9.99.69 console output starts being garbled when > machdep.cpu.frequency.target is being set to 1400. > > That would match the other comments here. > > As you didn't update the dtb files could that be the difference? I think > we got an upgrade of > > the dtb files between .17 and .69. > > Best regards, > > Frank > > On 07/08/20 22:50, Michael Cheponis wrote: > > I have been running 9.99.17 on RPi3+ and did ./build.sh current, which > produced 9.99.69 -- and it works perfectly, no garbling. I just copied > src/sys/arch/evbarm/compile/obj/GENERIC/netbsd.img to /boot/KERNEL7.IMG and > rebooted. > > # sysctl -a|grep freq > machdep.cpu.frequency.target = 1400 > machdep.cpu.frequency.current = 1400 > machdep.cpu.frequency.min = 600 > machdep.cpu.frequency.max = 1400 > machdep.cpu.frequency.available = 600 1400 > > So I'm now more confused than ever. > > > > On Wed, Jul 8, 2020 at 9:03 AM Michael van Elst > wrote: > >> kar...@netbsd.org (Frank Kardel) writes: >> >> >The next message is the setting of the maxiimum frequency which hoses the >> >RPI3B serial port speed. Do we have a clock setting/source issue here? >> >> It's a hardware limitation, the UART frequency is coupled with the >> CPU frequency. >> >> You can either run with a fixed CPU frequency or configure the other UART >> as serial port. The latter then causes problems with the bluetooth >> controller. >> >> -- >> -- >> Michael van Elst >> Internet: mlel...@serpens.de >> "A potential Snark may lurk in every >> tree." >> > >
Re: RPI3 serlial clock confusion?
Thank you. It's completely unclear to me, though, why we'd want to use the 'mini UART' vs the Main uart, because when we use the mini uart, *we have no access to the regular uart via the rpi pins*. https://elinux.org/RPi_BCM2835_GPIOs see how the 40 pins on the connector are mapped, with alternates. The effect seems to be to give us a downgraded functionality uart, and not providing a way to use the regular uart. I'm not sure this is progress? In defense of this change, the Broadcom manual says the intention of mini uart is specifically for console uart use. The baudrate register to achieve 115.2K baud on mini uart is set to 650 @ 600 MHz sysclock; it has to change to 1518 when going to 1400 MHz. (baudrate = sysclk / (8 * (BRreg+1)) ) The only potential upside I see from this change is having the main uart available on the Compute Module via J1-46, J1-48 or J1-58, J1-60. What am I missing? Thanks again. On Fri, Jul 10, 2020 at 9:19 AM Michael van Elst wrote: > On Thu, Jul 09, 2020 at 08:53:59AM -0700, Michael Cheponis wrote: > > It must be the dtb files. > > > > Yes, the console is perfect with 9.99.69 with (ahem) .17 good dtb files > > ... ;-) > > > > Thing is, if this is true - how does it work? And, has this > > discussion about cpu speed coupled with UART speed been incorrect? > > See > > https://www.raspberrypi.org/documentation/configuration/uart.md > > for a Raspbian-centric documentation. > > In opposite to that description we use the mini UART as console > with the RPI3. See: > > sys/external/gpl2/dts/dist/arch/arm/boot/dts/bcm2837-rpi-3-b.dts > > > Greetings, > -- > Michael van Elst > Internet: mlel...@serpens.de > "A potential Snark may lurk in every tree." >
Re: -current and RPI 2/3
I, too, am seeing this. [ 1.030] cpu_topology_init: info bogus, faking it [ 1.4812620] cpu3: 600 MHz Cortex-A53 r0p4 (Cortex V8A core) [ 1.4812620] cpu3: DC enabled IC enabled WB enabled EABT branch prediction enabled [ 1.4912632] cpu3: 32KB/64B 2-way L1 VIPT Instruction cache [ 1.5012675] cpu3: 32KB/64B 4-way write-back-locking-C L1 PIPT Data cache [ 1.5012675] cpu3: 512KB/64B 16-way write-through L2 PIPT Unified cache [ 1.5112645] vfp3 at cpu3: NEON MPE (VFP 3.0+), rounding, NaN propagation, denormals On Fri, Jul 17, 2020 at 6:01 AM Frank Kardel wrote: > I am having trouble to get Raspberries o boot recent -current (9.99.69). > > Raspberry Pi 2 Model B Rev 1.1 > > [ 1.030] genfb0 at simplebus1: switching to framebuffer console > [ 1.030] wsdisplay0 at genfb0 kbdmux 1: console (default, vt100 > emulation) > [ 1.030] vchiq0 at simplebus1: BCM2835 VCHIQ > [ 1.030] armpmu0 at simplebus0: Performance Monitor Unit > [ 1.030] gpioleds0 at simplebus0: ACT PWR > [ 1.030] bcmrng0 at simplebus1: RNG > [ 1.030] entropy: ready > > [ 1.030] uvm_fault(0x80b2f3c8, 0, 1) -> e > [ 1.030] Fatal kernel mode data abort: 'Translation Fault (S)' > [ 1.030] trapframe: 0x80b68ea8 > [ 1.030] FSR=0005, FAR=00c0, spsr=a153 > [ 1.030] r0 =80808a00, r1 =0004, r2 =, r3 = > [ 1.030] r4 =809e6cc4, r5 =0001, r6 =809e6ccc, r7 =0004 > [ 1.030] r8 =809e6cd4, r9 =809e6cc4, r10=809e6cc4, r11=80b68f34 > [ 1.030] r12=80808a00, ssp=80b68ef8, slr=0004, pc =8046f66c > > Stopped in pid 0.0 (system) at netbsd:cpu_topology_init+0x14c: ldr > r1, [r3, > > Raspberry Pi 2 Model B Rev 1.2 > > [ 1.030] vchiq0 at simplebus1: BCM2835 VCHIQ > [ 1.030] armpmu0 at simplebus0: Performance Monitor Unit > [ 1.030] gpioleds0 at simplebus0: ACT PWR > [ 1.030] bcmrng0 at simplebus1: RNG > [ 1.030] entropy: ready > [ 1.030] cpu_topology_init: info bogus, faking it > [ 1.5549067] cpu3: 600 MHz Cortex-A53 r0p4 (Cortex V8A core) > [ 1.5749092] cpu3: DC enabled IC enabled WB enabled EABT branch > prediction enabled > [ 1.6149103] cpu3: 32KB/64B 2-way L1 VIPT Instruction cache > [ 1.6449126] cpu3: 32KB/64B 4-way write-back-locking-C L1 PIPT Data cache > [ 1.6749184] cpu3: 512KB/64B 16-way write-through L2 PIPT Unified cache > [ 1.7049206] vfp3 at cpu3: NEON MPE (VFP 3.0+), rounding, NaN > propagation, denormals > ### stuck here > > Raspberry Pi 3 Model B Plus Rev 1.3 > > [ 1.030] wsdisplay0 at genfb0 kbdmux 1: console (default, vt100 > emulation) > [ 1.030] vchiq0 at simplebus1: BCM2835 VCHIQ > [ 1.030] armpmu0 at simplebus0: Performance Monitor Unit > [ 1.030] gpioleds0 at simplebus0: ACT > [ 1.030] bcmrng0 at simplebus1: RNG > [ 1.030] entropy: ready > [ 1.030] cpu_topology_init: info bogus, faking it > [ 1.7022878] cpu3: 600 MHz Cortex-A53 r0p4 (Cortex V8A core) > [ 1.7222897] cpu3: DC enabled IC enabled WB enabled EABT branch > prediction enabled > [ 1.7622915] cpu3: 32KB/64B 2-way L1 VIPT Instruction cache > [ 1.7922937] cpu3: 32KB/64B 4-way write-back-locking-C L1 PIPT Data cache > [ 1.8222994] cpu3: 512KB/64B 16-way write-through L2 PIPT Unified cache > [ 1.8523009] vfp3 at cpu3: NEON MPE (VFP 3.0+), rounding, NaN > propagation, denormals > ### stuck here > > sometimes cpu2 makes it to show up. > > This happens with self compiles sources and the latest releng version > > [ 1.000] NetBSD 9.99.69 (GENERIC) #0: Fri Jul 17 02:16:57 UTC 2020 > [ 1.000] > mkre...@mkrepro.netbsd.org:/usr/src/sys/arch/evbarm/compile/GENERIC > > Older -current versions manage to boot. > > Frank > >
Re: repeated failure to properly shutdown
On Jul 22, 2016, at 4:24 PM, Robert Elz wrote: >Date:Sat, 23 Jul 2016 04:38:42 +0700 >From:Robert Elz >Message-ID: <20406.1469223...@andromeda.noi.kre.to> > > | That /dev/null turned into a regular file is another bug [...] > | (This turns out to be a bug in MAKEDEV [...] > > Actually, not, it must be elsewhere, or as a result of something else. > > kre > > > Could it perhaps come from the ( set -o tabcomplete 2>/dev/null ) in /etc/shrc? - Michael
Re: repeated failure to properly shutdown
On Jul 22, 2016, at 5:02 PM, Robert Elz wrote: > the question is just where is that first attempt. Hmm, it looks like doing "shutdown now" to get into single-user will force-unmount the tmpfs file systems (/etc/rc.d/swap1), so you could be left in a state where creating a regular /dev/null becomes all too easy. As an aside, while testing out things I also noticed that MAKEDEV tries to use $MKNOD in create_mfs_dev(), but this is only set if the -m switch is supplied. So the attempt to make a temporary console fails. Thanks, - Michael
Re: Building on OS X - how?
On Aug 11, 2016, at 8:32 AM, Thor Lancelot Simon wrote: > On Thu, Aug 11, 2016 at 04:29:54PM +0200, Hubert Feyrer wrote: >> >> 2) /usr/bin/cc: >> Undefined symbols for architecture x86_64: "_iconv" >> in external/gpl3/gcc/usr.bin/backend > > This bug has appeared within the past few days and breaks my builds > on OS X 10.9.5 as well. I'm not having much luck tracking it down. > > Thor > > That sounds like it may be related to a problem I ran into when cross-building from FreeBSD (11 beta something). With a package for libiconv installed, the compile must have found the header in /usr/local/include, but the link step did not use the right library. I worked around this by building in a jail with no packages installed. - Michael
Re: Building on OS X - how?
On Aug 12, 2016, at 12:54 PM, matthew green wrote: > Thor Lancelot Simon writes: >> On Thu, Aug 11, 2016 at 04:05:06PM +0100, Robert Swindells wrote: >>> >>>> 2) /usr/bin/cc: >>>> Undefined symbols for architecture x86_64: "_iconv" >>>> in external/gpl3/gcc/usr.bin/backend >>> >>> This should be in libc. >> >> For what value of "should"? _iconv is in the implementation-defined >> namespace. >> >> It's curious that this doesn't break the tools build, and doesn't >> prevent using the built tools to build a kernel! If this can break >> the cross-build of the target compiler, I think we must have suddenly >> sprouted a rather serious instance of host/target confusion. > > this fails building the native gcc, which requires a bunch of host > tools to run. going on your following post, there is a problem > with genmatch. i don't have access to any osx to test, so i'm not > sure where to start looking. there aren't too many rules used in > the creation of "genmatch" binary - can you run "make cleandir" > in usr.bin/backend/ and then "make MAKEVERBOSE=2 genmatch", and > post all the commands run? there probably will be a configure > run in here, and perhaps the output of it also matters. > > > .mrg. > > I still have a log from the maybe-similar failure on freebsd: https://gist.github.com/mfplass/98801ea2ab2cd3d5abd92faa3c47ab1c It, too, is trying to build genmatch. The config.status for host-libcpp is at https://gist.github.com/mfplass/6a75e12339bc97223854953fee1fa9fc - Michael
Re: Building on OS X - how?
On Aug 12, 2016, at 6:44 PM, Michael Plass wrote: > The config.status for host-libcpp is at > https://gist.github.com/mfplass/6a75e12339bc97223854953fee1fa9fc And the relevant diffs with the working (in-jail) build is 619,620c619,620 < S["LTLIBICONV"]="-L/usr/local/lib -liconv -R/usr/local/lib" < S["LIBICONV"]="/usr/local/lib/libiconv.so -Wl,-rpath -Wl,/usr/local/lib" --- > S["LTLIBICONV"]="" > S["LIBICONV"]="" 656c656 < S["CPPFLAGS"]="-I/usr/local/include" --- > S["CPPFLAGS"]="" so maybe the linker flags for LIBICONV aren't getting pulled in where they should be?
evbarm flist needs update for libdrm_nouveau
Sources of Wed Aug 17 12:10:42 2016 + freshly updated xsrc ===> build.sh command:./build.sh -j3 -N1 -u -U -O /var/tmp/obj -x -m evbarm -a earmv7hf release ===> build.sh started:Wed Aug 17 09:00:00 PDT 2016 ===> NetBSD version: 7.99.35 ===> MACHINE: evbarm ===> MACHINE_ARCH:earmv7hf ===> Build platform: FreeBSD 11.0-PRERELEASE amd64 ===> HOST_SH: /bin/sh ===> MAKECONF file: /etc/mk.conf (File not found) ===> TOOLDIR path:/var/tmp/obj/tooldir.FreeBSD-11.0-PRERELEASE-amd64 ===> DESTDIR path:/var/tmp/obj/destdir.evbarm ===> RELEASEDIR path: /var/tmp/obj/releasedir ===> Updated makewrapper: /var/tmp/obj/tooldir.FreeBSD-11.0-PRERELEASE-amd64/bin/nbmake-evbarm ... postinstall-fix-obsolete_stand ===> . === Removing obsolete files === Source directory: /usr/home/michael/netbsd/usr/src Target directory: /var/tmp/obj/destdir.evbarm/ obsolete_stand fix: postinstall fixes passed: obsolete_stand postinstall fixes failed: === checkflist ===> distrib/sets === 2 extra files in DESTDIR = Files in DESTDIR but missing from flist. File is obsolete or flist is out of date ? -- ./usr/X11R7/lib/libdrm_nouveau.so.3 ./usr/X11R7/lib/libdrm_nouveau.so.3.0 = end of 2 extra files === == 2 missing files in DESTDIR Files in flist but missing from DESTDIR. File wasn't installed ? -- ./usr/X11R7/lib/libdrm_nouveau.so.2 ./usr/X11R7/lib/libdrm_nouveau.so.2.0 end of 2 missing files == --- checkflist --- *** [checkflist] Error code 1
Hello Dear
Good day I am Michael, from United States. I browsed through the Internet and came across your mail. I would like us to be friends. Do you mind being my friend? Regards, Michael.
Re: Intel CPU design flaw
Guys, modern CPUs are incredibly complicated. Incredibly. Given how cheaply one can buy a CPU chip, it's one of the best bargains in the known universe. >From NYT article: https://www.nytimes.com/2018/01/03/business/computer-flaws.html?_r=0 The Meltdown flaw is specific to Intel, but Spectre is a flaw in design that has been used by many processor manufacturers for decades. It affects virtually all microprocessors on the market, including chips made by AMD that share Intel’s design and the many chips based on designs from ARM in Britain. Spectre is a problem in the fundamental way processors are designed, and the threat from Spectre is “going to live with us for decades,” said Mr. Kocher, the president and chief scientist at Cryptography Research, a division of Rambus. “Whereas Meltdown is an urgent crisis, Spectre affects virtually all fast microprocessors,” Mr. Kocher said. An emphasis on speed while designing new chips has left them vulnerable to security issues, he said. “We’ve really screwed up,” Mr. Kocher said. “There’s been this desire from the industry to be as fast as possible and secure at the same time. Spectre shows that you cannot have both.” On Thu, Jan 4, 2018 at 6:30 AM, Swift Griggs wrote: > On Wed, 3 Jan 2018, Chavdar Ivanov wrote: > >> Any comments in this part of the wood about >> https://www.theregister.co.uk/2018/01/02/intel_cpu_design_flaw/ ? >> > > I have one. In my world, performance > security. I don't fully understand > the internals of the issue. It sounds like some kind of MMU hardware flaw > that can't be patched with microcode. The chosen fix appears to be some > kind of more software-slanted memory protection. > > Nonetheless, as a user, can I get this as an *option* instead of forced > down my throat? I didn't pay for my CPUs to turn off a third of it's > performance. Ie.. > > "TAKE_A_BIG_PERFORMANCE_HIT_BECAUSE_SECURITY=true" > > That's my only real comment other than "this really sucks for all of us > and I hope Intel's stock tanks accordingly." I just spent the last year > learning assembler. I'm glad it was 68k not x86. > > -Swift >
Re: Intel CPU design flaw
Here's a pretty detailed description of these flaws: https://googleprojectzero.blogspot.com/2018/01/reading-privileged-memory-with-side.html On Thu, Jan 4, 2018 at 12:25 PM, Michael Cheponis < michael.chepo...@gmail.com> wrote: > Guys, modern CPUs are incredibly complicated. Incredibly. Given how > cheaply one can buy a CPU chip, it's one of the best bargains in the known > universe. > > From NYT article: https://www.nytimes.com/2018/01/03/business/ > computer-flaws.html?_r=0 > > > The Meltdown flaw is specific to Intel, but Spectre is a flaw in design > that has been used by many processor manufacturers for decades. It affects > virtually all microprocessors on the market, including chips made by AMD > that share Intel’s design and the many chips based on designs from ARM in > Britain. > > Spectre is a problem in the fundamental way processors are designed, and > the threat from Spectre is “going to live with us for decades,” said Mr. > Kocher, the president and chief scientist at Cryptography Research, a > division of Rambus. > > “Whereas Meltdown is an urgent crisis, Spectre affects virtually all fast > microprocessors,” Mr. Kocher said. An emphasis on speed while designing new > chips has left them vulnerable to security issues, he said. > > “We’ve really screwed up,” Mr. Kocher said. “There’s been this desire from > the industry to be as fast as possible and secure at the same time. Spectre > shows that you cannot have both.” > > On Thu, Jan 4, 2018 at 6:30 AM, Swift Griggs > wrote: > >> On Wed, 3 Jan 2018, Chavdar Ivanov wrote: >> >>> Any comments in this part of the wood about >>> https://www.theregister.co.uk/2018/01/02/intel_cpu_design_flaw/ ? >>> >> >> I have one. In my world, performance > security. I don't fully understand >> the internals of the issue. It sounds like some kind of MMU hardware flaw >> that can't be patched with microcode. The chosen fix appears to be some >> kind of more software-slanted memory protection. >> >> Nonetheless, as a user, can I get this as an *option* instead of forced >> down my throat? I didn't pay for my CPUs to turn off a third of it's >> performance. Ie.. >> >> "TAKE_A_BIG_PERFORMANCE_HIT_BECAUSE_SECURITY=true" >> >> That's my only real comment other than "this really sucks for all of us >> and I hope Intel's stock tanks accordingly." I just spent the last year >> learning assembler. I'm glad it was 68k not x86. >> >> -Swift >> > >
Re: zfs forgetting cache wedges?
kar...@netbsd.org (Frank Kardel) writes: >After a boot it looks like this: >NAME SIZE ALLOC FREE EXPANDSZ FRAGCAP DEDUP > HEALTH ALTROOT >pool-18.94T 2.76T 6.17T - 5%30% 1.11x > ONLINE - > raidz1 8.94T 2.76T 6.17T - 5%30% > wedges/zfs10g0-0 - - - - - - > wedges/zfs10g1-0 - - - - - - > wedges/zfs10g2-0 - - - - - - >cache - - - - - - > 384839849488- - - - - - >The cache wedge does not look very usable in that state. Didn't happen here (with recent -current). The device paths for the pool devices are stored in /etc/zfs/zfs.cache and the device path to the cache device is stored on the pool devices. But your pool devices also do not return data, and that's probably the reason for the strange cache device path that couldn't be read. NAME SIZE ALLOC FREE EXPANDSZ FRAGCAP DEDUP HEALTH ALTROOT mypool 80M 104K 79.9M - 4% 0% 1.00x ONLINE - wedges/image080M 104K 79.9M - 4% 0% cache- - - - - - wedges/image1 95.2M 1K 95.2M - 0% 0% -- -- Michael van Elst Internet: mlel...@serpens.de "A potential Snark may lurk in every tree."
Re: zfs forgetting cache wedges?
kar...@kardel.name (Frank Kardel) writes:
>Interesting - I am running 9.99.72 currently.
>I was always wondering why the devices show no statistics. These are
>simple gpt zfs wedges.
>Any idea what is wrong there?
When you use devpubd to create symlinks in dev/wedges, the links may
be stale when zfs starts because devpubd runs too late.
Moving devpubd to an earlier position would help, but the wedgenames hook
doesn't work without /usr.
--
--
Michael van Elst
Internet: mlel...@serpens.de
"A potential Snark may lurk in every tree."
Re: Etherip(4) interoperability with NetBSD-9?
buh...@nfbcal.org (Brian Buhrow) writes:
>1. I don't remember if the networking stack in NetBSD-9 is multi-threaded
>or not. Can someone say how much concurrency is available in the NetBSD-9
>stack?
The socket part of the stack runs concurrently also in older NetBSD versions,
the upper part is still running under a global lock unless you build a kernel
with option NET_MPSAFE. That is experimental and probably not suited yet for
a production environment.
>2. Is there a way to get the NetBSD-9 stack to speak to NetBSD-5.2 using
>the etherip(4) protocol without having to update the NetBSD-5.2 machines?
No idea about etherip. But you could probably do something similar with
just gre(4) or openvpn in bridge mode.
--
--
Michael van Elst
Internet: mlel...@serpens.de
"A potential Snark may lurk in every tree."
Re: kern.maxfiles / MAXFILES default value updated
sim...@netbsd.org (Simon Burge) writes: >Longer term, I'll be looking at making a few of the default settings >(at least maximum number of files, processes and vnodes, maybe others) >scale better with RAM size. Vnodes don't have a hard limit, but expire to some 'desired' count under memory pressure. As long as the syncer isn't improved, it shouldn't grow. -- -- Michael van Elst Internet: mlel...@serpens.de "A potential Snark may lurk in every tree."
Re: kernel panic in NetBSD-9.1-amd64-install.img (exiting unheld spin mutex)
r...@reedmedia.net ("Jeremy C. Reed") writes:
>panic: lock error: Mutex error: mutex_vector_exit,742: exiting unheld
>spin mutex: lock 0x8699588015c0 cpu 0 lwp 0xff... (my photo was
>cropped)
>athn_ioctl() at netbsd:athn_ioctl+0x18b
>if_mcast_op() at netbsd:if_mcast_op+0x4b
>in_delmulti
Seems to be obvious in sys/dev/ic/athn.c:
Static void
athn_set_multi(struct athn_softc *sc)
{
...
if ((ifp->if_flags & (IFF_ALLMULTI | IFF_PROMISC)) != 0) {
lo = hi = 0x;
goto done;
}
lo = hi = 0;
ETHER_LOCK(ec);
...
done:
ETHER_UNLOCK(ec);
...
}
The done: label should be moved below ETHER_UNLOCK.
--
--
Michael van Elst
Internet: mlel...@serpens.de
"A potential Snark may lurk in every tree."
Re: kernel panic in NetBSD-9.1-amd64-install.img (exiting unheld spin mutex)
r...@reedmedia.net ("Jeremy C. Reed") writes:
>panic: lock error: Mutex error: mutex_vector_exit,742: exiting unheld
>spin mutex: lock 0x8699588015c0 cpu 0 lwp 0xff... (my photo was
>cropped)
Index: athn.c
===
RCS file: /cvsroot/src/sys/dev/ic/athn.c,v
retrieving revision 1.23
diff -p -u -r1.23 athn.c
--- athn.c 29 Jan 2020 14:09:58 - 1.23
+++ athn.c 15 Nov 2020 07:04:38 -
@@ -2734,7 +2734,7 @@ athn_set_multi(struct athn_softc *sc)
if ((ifp->if_flags & (IFF_ALLMULTI | IFF_PROMISC)) != 0) {
lo = hi = 0x;
- goto done;
+ goto done2;
}
lo = hi = 0;
ETHER_LOCK(ec);
@@ -2760,6 +2760,7 @@ athn_set_multi(struct athn_softc *sc)
}
done:
ETHER_UNLOCK(ec);
+ done2:
AR_WRITE(sc, AR_MCAST_FIL0, lo);
AR_WRITE(sc, AR_MCAST_FIL1, hi);
AR_WRITE_BARRIER(sc);
--
--
Michael van Elst
Internet: mlel...@serpens.de
"A potential Snark may lurk in every tree."
Re: Best practice for setting up disks for ZFS on NetBSD
a...@absd.org (David Brownlee) writes:
>Aha - *this* is nice. I recall seeing devpubd mentioned a while back
>but never took a look. More fool me!
>One small issue - rcorder shows rc.d/devpubd running quite late in the
>boot process - much later than rc.d/zfs.I wonder if it should be
>adjusted to run directly after rc.d/root?
That is the plan. The current hooks are shell scripts that require /usr
and need to rewritten (probably as tiny C programs).
--
--
Michael van Elst
Internet: mlel...@serpens.de
"A potential Snark may lurk in every tree."
Re: Re: [current-users] Re: Best practice for setting up disks for ZFS on NetBSD
m...@mjch.net ("Malcolm Herbert") writes:
>As far as I understand it, ZFS vdevs have their own ID, so they can be laid
>out correctly no matter the OS device each are discovered on ... wouldn't that
>make a raidframe wrapper redundant? it would also mean the zpool vdevs
>couldn't be used on other systems that understand ZFS because they're unlikely
>to understand raidframe ...
The device paths are cached, thus the need to re-import. Ideally the cache
would be invalidated automatically, but I was told is not in our code base.
--
--
Michael van Elst
Internet: mlel...@serpens.de
"A potential Snark may lurk in every tree."
Re: Big-endian mode supported for Raspberry Pi [0-3] with bootable images available
rokuyama...@gmail.com (Rin Okuyama) writes:
>vchiq(4) and vcaudio(4) are not supported in big-endian mode. This
>requires heavy modifications to third party source codes. Anyway, we
>will switch to vc4 drm driver, hopefully soon.
The vc4 driver is not a replacement for vchiq or vcaudio, but since
it kills vchiq, you then also need a hardware driver for audio (and
a second one for RPI4 which has different audio hardware).
--
--
Michael van Elst
Internet: mlel...@serpens.de
"A potential Snark may lurk in every tree."
Re: Big-endian mode supported for Raspberry Pi [0-3] with bootable images available
rokuyama...@gmail.com (Rin Okuyama) writes: >On 2020/12/03 21:46, Michael van Elst wrote: >> rokuyama...@gmail.com (Rin Okuyama) writes: >> >>> vchiq(4) and vcaudio(4) are not supported in big-endian mode. This >>> requires heavy modifications to third party source codes. Anyway, we >>> will switch to vc4 drm driver, hopefully soon. >> >> The vc4 driver is not a replacement for vchiq or vcaudio, but since >> it kills vchiq, you then also need a hardware driver for audio (and >> a second one for RPI4 which has different audio hardware). >Thanks for correction. Yeah, we need independent audio driver in >that case. I hope that the new driver gets simpler than vchiq... vc4 is a DRM driver, I strongly doubt that it will be as small and simple as vchiq. I'm also not that interested in dropping the firmware functionality. -- -- Michael van Elst Internet: mlel...@serpens.de "A potential Snark may lurk in every tree."
Re: Entropy problem [was Re: CVS Problem (again) ,Slightly lesser old code, but old still [was Re: Console problem ,older code]]
germain.lechapel...@lanvaux.fr (Germain Le Chapelain) writes:
>This time the crash was in pkg_add itself (=E2=80=98segmentation fault (core=
> dump)=E2=80=99)
Recently I also got a few segmentation faults from pkg_add, also
when installing firefox. The coredump indicated that it failed in
the Berkeley DB code. Removing /var/db/pkg/pkgdb.byfile.db and
rebuilding it with "pkg_admin rebuild" helped.
--
--
Michael van Elst
Internet: mlel...@serpens.de
"A potential Snark may lurk in every tree."
Re: Unusable system during dd to USB block device
arm...@gmail.com (Arto Huusko) writes:
>The transfer did work, but it was excruciatingly slow, under 2 Mb /
>sec. But that wasn't the only problem: it also made most other
>activities on the system unusable, at least if there was any disk
>access involved.
The block devices pass things through the traditional buffer cache
which adds lots of overhead and splits everything into small I/O
fragments. The cache is also flooded with stale data, making it
completely useless and everyone else has to compete with your
mass I/O requests.
--
--
Michael van Elst
Internet: mlel...@serpens.de
"A potential Snark may lurk in every tree."
Re: Unusable system during dd to USB block device
mueller6...@twc.com ("Thomas Mueller") writes:
>Or a fourth possibility, /dev/sd2 was the wrong name even if it was the
>correct USB stick.
>What would be the correct way for NetBSD?
/dev/rsd2
--
--
Michael van Elst
Internet: mlel...@serpens.de
"A potential Snark may lurk in every tree."
Re: sed and xentools413
w...@netbsd.org (Thomas Klausner) writes: >sed "s/^ *\([0-9]*\)\t.*$/\1/" hunspell-capmain-plus_de_DE.tmp.unknown.tmp > >hunspell-capmain-plus_de_DE.tmp.list-unknown-lines.tmp >sed: 1: "s/^ *\([0-9]*\)\t.*$/\1/": RE error: trailing backslash (\) >What is the trailing backslash in that regex? sed doesn't understand \t as TAB. NetBSD-9 sed also doesn't understand it, but it (or rather the underlying regcomp() function) doesn't bail out. N.B. usage of '$' in a double-quoted string is also questionable. -- -- Michael van Elst Internet: mlel...@serpens.de "A potential Snark may lurk in every tree."
Re: sed and xentools413
r...@sdf.org (RVP) writes:
>The NetBSD sed doesn't understand '\t' as signifying a tab:
>You'll have to rewrite that regex like this:
>$ nl /etc/motd | sed 's/^ *\([0-9]*\)'$'\t''.*$/\1/'
The $'\t' syntax is also new. For old shells (e.g. NetBSD-8) you need to use
a literal TAB. Usually like:
TAB=' ' # <--- literal TAB
sed "s/^ *\([0-9]*\)${TAB}.*$/\1/"
--
--
Michael van Elst
Internet: mlel...@serpens.de
"A potential Snark may lurk in every tree."
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(&dmv->table_head, &numsec, 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(&dmv->table_head, &numsec, NULL);
- *valp = numsec;
+ dm_table_disksize(&dmv->table_head, &numsec, &secsize);
+ *valp = numsec * secsize;
dm_dev_unbusy(dmv);
break;
--
--
Michael van Elst
Internet: mlel...@serpens.de
"A potential Snark may lurk in every tree."
Re: how do I mount a read-only filesystem from the "root device" prompt?
wo...@planix.ca ("Greg A. Woods") writes:
>So with Xen one can export a "disk" (disk, file, LVM partiion, etc.)
>with "access=ro", and that is enforced.
>However if one tries to mount such a disk in a domU as root, it fails.
> root on dk1
> vfs_mountroot: can't open root device, error = 30
> cannot mount root, error = 30
The wedge code always opens the parent device read-write as it is only
opened once for all wedges.
I suggested to make it open read-only if it gets EROFS and to validate
the open mode against what is possible in this state.
Re: how do I mount a read-only filesystem from the "root device" prompt?
wo...@planix.ca ("Greg A. Woods") writes:
>Given the layers of devices and code involved, perhaps it might be
>possible to just honour the original mode requested by the code opening
>the first partition to mount a filesystem, and then to upgrade the vnode
>to write mode if/when that mount is upgraded to write mode or another rw
>mount is attempted on another partition on the same device?
Someone would need to write code to "upgrade" vnodes. I doubt that's
trivial. Fortunately it is not necessary. If the parent device is read-only,
no "upgrade" will help to make it read-write. So you open read-write
or fail back to read-only when necessary. An attempt to open a wedge
read-write on a read-only opened parent device then has to fail.
I'm testing a patch for that...
Re: regarding the changes to kernel entropy gathering
jo...@bec.de (Joerg Sonnenberger) writes: >Part of the problem here is that most of the non-RNG data sources are >easily observable either from the local system (e.g. any malicious user) >or other VMs on the same machine (in case of a hypervisor) or local >machines on the same network (in case of network interrupts). That's the >real reason why their entropy is hard to estimate. It becomes even more >annoying with modern hardware features like interrupt moderation of >nics. They can make the timing of interrupts highly predicable. Must be a thing of the past, as we always ignored that information from NIC devices by default. No need to rip out the code that would allow it.
Re: cmake hang ... again
bou...@antioche.eu.org (Manuel Bouyer) writes: >I see the same thing in bulk builds, with various kde packages. >When I asked I've been told that this was a known issue, but without fix ... There are several issues that hang builds. The cmake hang usually responds well to a SIGSTOP followed by a SIGCONT. Otherwise I see several infinite loops, a python deadlock in the samba4 build and, new, the kdelibs4 build stalls for kfiltertest_automoc.cpp.
Re: cmake hang ... again
jo...@bec.de (Joerg Sonnenberger) writes: >On Tue, Apr 06, 2021 at 04:49:58PM -0000, Michael van Elst wrote: >> Otherwise I see several infinite loops, a python deadlock in the samba4 build >> and, new, the kdelibs4 build stalls for kfiltertest_automoc.cpp. >The samba4 thing can be avoided with MAKE_JOBS_SAFE=no. I don't fully >understand what happened with that and run out of steam debugging it. >kdelibs4 stalls sound like the wait list issue. Does gdb attach or >STOP/CONT help? Didn't help for kdelibs4.
Re: GCC 10 available for testing etc. in -current.
ll...@must-have-coffee.gen.nz (Lloyd Parkes) writes: >On 17/04/21 6:30 pm, Lloyd Parkes wrote: >> I am using the Mercurial repository at https://anonhg.NetBSD.org/src >> for fetching the source code because it's nice and quick >I've been running CVS for more than two hours now, and it has terminated >with a broken connection 10 (make that 11) times so far. The funny thing is that it works the opposite way for me. CVS checkout works without problems and Mercurial checkouts almost always time out or aren't succesful. Should tell you that the software is only a small part of the problem.
Re: Problem reports for version control systems
b...@update.uu.se (Johnny Billquist) writes: >And as a "fun" fact. On my 4000/90, it takes about 3h after I start a >cvs update until I actually start having any network traffic... A SCSI SSD could help. :)
Re: Anyone using a Jabra USB Headset with -current?
jarle.greipsl...@norid.no (Jarle Greipsland) writes: >Excerpts from dmesg (after I plugged in the cable): >[71.345366] uaudio0 at uhub1 port 2 configuration 1 interface 0 >[71.345366] uaudio0: vendor 0b0e (0x0b0e) Jabra Evolve 65 (0x030c), rev >2.00/2.91, addr 2 >[71.355369] uaudio0: autoconfiguration error: no usable endpoint found >[71.355369] uaudio0: autoconfiguration error: audio descriptors make no >sense, error=4 >[71.355369] uhidev0 at uhub1 port 2 configuration 1 interface 3 >[71.355369] uhidev0: vendor 0b0e (0x0b0e) Jabra Evolve 65 (0x030c), rev >2.00/2.91, addr 2, iclass 3/0 >[71.365368] uhidev0: 155 report ids >[71.365368] uhid0 at uhidev0 reportid 1: input=2, output=0, feature=0 >[71.365368] uhid1 at uhidev0 reportid 2: input=2, output=2, feature=0 >[71.365368] uhid2 at uhidev0 reportid 4: input=2, output=2, feature=1 >[71.365368] uhid3 at uhidev0 reportid 5: input=63, output=63, feature=0 >[71.365368] uhid4 at uhidev0 reportid 154: input=0, output=0, feature=63 >[71.365368] uhid5 at uhidev0 reportid 155: input=2, output=0, feature=0 A Jabra Evolve 20 is recognized: uaudio0 at uhub2 port 2 configuration 1 interface 0 uaudio0: GN Netcom A/S (0x0b0e) Jabra EVOLVE 20 MS (0x0300), rev 2.00/3.00, addr 3 uaudio0: audio rev 1.00 uaudio0: 7 mixer controls uhidev0 at uhub2 port 2 configuration 1 interface 3 uhidev0: GN Netcom A/S (0x0b0e) Jabra EVOLVE 20 MS (0x0300), rev 2.00/3.00, addr 3, iclass 3/0 uhidev0: 5 report ids uhid0 at uhidev0 reportid 1: input=2, output=0, feature=0 uhid1 at uhidev0 reportid 2: input=2, output=2, feature=0 uhid2 at uhidev0 reportid 4: input=2, output=2, feature=0 uhid3 at uhidev0 reportid 5: input=32, output=32, feature=0 A Jabra Evolve 75 fails like yours: uaudio0 at uhub3 port 2 configuration 1 interface 0 uaudio0: vendor 0b0e (0x0b0e) Jabra Evolve 75 (0x2465), rev 2.00/2.32, addr 4 uaudio0: autoconfiguration error: no usable endpoint found uaudio0: autoconfiguration error: audio descriptors make no sense, error=4 uhidev0 at uhub3 port 2 configuration 1 interface 3 uhidev0: vendor 0b0e (0x0b0e) Jabra Evolve 75 (0x2465), rev 2.00/2.32, addr 4, iclass 3/0 uhidev0: 155 report ids uhid0 at uhidev0 reportid 1: input=2, output=0, feature=0 uhid1 at uhidev0 reportid 2: input=2, output=2, feature=0 uhid2 at uhidev0 reportid 4: input=2, output=2, feature=1 uhid3 at uhidev0 reportid 5: input=63, output=63, feature=0 uhid4 at uhidev0 reportid 154: input=0, output=0, feature=63 uhid5 at uhidev0 reportid 155: input=2, output=0, feature=0 Time for UAUDIO_DEBUG.
Re: Anyone using a Jabra USB Headset with -current?
mlel...@serpens.de (Michael van Elst) writes: >A Jabra Evolve 75 fails like yours: >uaudio0 at uhub3 port 2 configuration 1 interface 0 >uaudio0: vendor 0b0e (0x0b0e) Jabra Evolve 75 (0x2465), rev 2.00/2.32, addr 4 >uaudio0: autoconfiguration error: no usable endpoint found >uaudio0: autoconfiguration error: audio descriptors make no sense, error=4 >uhidev0 at uhub3 port 2 configuration 1 interface 3 >uhidev0: vendor 0b0e (0x0b0e) Jabra Evolve 75 (0x2465), rev 2.00/2.32, addr 4, >iclass 3/0 And now it works: uaudio0 at uhub3 port 2 configuration 1 interface 0 uaudio0: vendor 0b0e (0x0b0e) Jabra Evolve 75 (0x2465), rev 2.00/2.32, addr 4 uaudio0: audio rev 1.00 uaudio0: 8 mixer controls audio2 at uaudio0: playback, capture, full duplex, independent audio2: slinear_le:16 2ch 48000Hz, blk 11520 bytes (60ms) for playback audio2: slinear_le:16 1ch 16000Hz, blk 1920 bytes (60ms) for recording audio2: PC Speaker (synthesized) wsbell at spkr3 not configured uhidev0 at uhub3 port 2 configuration 1 interface 3 uhidev0: vendor 0b0e (0x0b0e) Jabra Evolve 75 (0x2465), rev 2.00/2.32, addr 4, iclass 3/0 uhidev0: 155 report ids uhid0 at uhidev0 reportid 1: input=2, output=0, feature=0 uhid1 at uhidev0 reportid 2: input=2, output=2, feature=0 uhid2 at uhidev0 reportid 4: input=2, output=2, feature=1 uhid3 at uhidev0 reportid 5: input=63, output=63, feature=0 uhid4 at uhidev0 reportid 154: input=0, output=0, feature=63 uhid5 at uhidev0 reportid 155: input=2, output=0, feature=0 The code assumed some specific order of USB descriptors. When I have cleaned up the patch I'll commit. It probably also applies to older netbsd versions.
Re: Anyone using a Jabra USB Headset with -current?
On Mon, May 24, 2021 at 08:49:26AM +0300, Andrius V wrote:
> Jabra Evolve 20 is not working on NetBSD 9.2 for me (submitted pr
> 56172 recently). But yes, it does work on current branch, except that
> removing headset on audio play causes panic.
Possible. I test on -current.
Removing the headset doesn't panic for me which might be caused by:
Index: uaudio.c
===
RCS file: /cvsroot/src/sys/dev/usb/uaudio.c,v
retrieving revision 1.169
diff -p -u -r1.169 uaudio.c
--- uaudio.c15 Feb 2021 13:39:18 - 1.169
+++ uaudio.c24 May 2021 08:05:05 -
@@ -519,7 +519,7 @@ static int
uaudio_detach(device_t self, int flags)
{
struct uaudio_softc *sc = device_private(self);
- int rv = 0;
+ int rv;
sc->sc_dying = 1;
@@ -529,8 +529,11 @@ uaudio_detach(device_t self, int flags)
uaudio_halt_out_dma_unlocked(sc);
uaudio_halt_in_dma_unlocked(sc);
- if (sc->sc_audiodev != NULL)
+ if (sc->sc_audiodev != NULL) {
rv = config_detach(sc->sc_audiodev, flags);
+ if (rv)
+ return rv;
+ }
usbd_add_drv_event(USB_EVENT_DRIVER_DETACH, sc->sc_udev, sc->sc_dev);
@@ -541,7 +544,7 @@ uaudio_detach(device_t self, int flags)
mutex_destroy(&sc->sc_lock);
mutex_destroy(&sc->sc_intr_lock);
- return rv;
+ return 0;
}
Static int
Greetings,
--
Michael van Elst
Internet: mlel...@serpens.de
"A potential Snark may lurk in every tree."
Re: dump/restore out of range inode
pr...@cam.ac.uk (Patrick Welche) writes: > DUMP: Child 29322 returns LOB status 213 >213=0xd5 That's octal. Return status 0213 = 139 -> WCOREFLAG(==128) + signal 11. >Can this happen if the original filesystem is broken? At a distance >it just looks as though restore hasn't read a symbol table before using it >and the filesystem seems to have a valid inode? Segfaults should never happen. maxino has probably never been set since dump crashed and restore got an early end-of-file.
Re: dump/restore out of range inode
pr...@cam.ac.uk (Patrick Welche) writes: >How can gdb not see a spcl anywhere? /usr/include/protocols/dumprestore.h:#define spcl u_spcl.s_spcl spcl is just a define that got resolved by the compiler.
Re: st.c update has broken dump multi-tape support
On Thu, Jun 10, 2021 at 11:10:23AM +0200, Frank Kardel wrote:
> Hi Brett,
>
> I meant the section in ststart1 where error is set to zero followed by goto
> out inf the fixed blocksize part.
The biodone is missing, but also other parts.
We have 5 cases.
- I/O request is queued, error == 0. -> will be finished in callback.
- I/O request is queued, error != 0. -> ststart calls biodone.
- I/O request is not queued, error == EAGAIN -> ststart requeues request
- I/O request is not queued, error != 0 -> ststart calls biodone.
and
- I/O request is not queued, error == 0 -> this is broken.
I would make the last case return error == -1 instead (!= any possible
errno value). In ststart errno is checked != 0, so it will
- finish the I/O request for iostat.
- call biodone
The latter needs an adjustment like:
bp->b_error = error < 0 ? 0 : error;
so that the fake errno is replaced with end-of-file.
If you don't like the fake errno, the function needs to return
two values, the error value and a boolean to finish the
unqueued request. Cleaner, but more changes.
Greetings,
--
Michael van Elst
Internet: mlel...@serpens.de
"A potential Snark may lurk in every tree."
Re: st.c update has broken dump multi-tape support
On Thu, Jun 10, 2021 at 12:02:19PM +0200, Michael van Elst wrote:
> If you don't like the fake errno, the function needs to return
> two values, the error value and a boolean to finish the
> unqueued request. Cleaner, but more changes.
E.g. (not even compile-tested):
Index: st.c
===
RCS file: /cvsroot/src/sys/dev/scsipi/st.c,v
retrieving revision 1.240
diff -p -u -r1.240 st.c
--- st.c27 Dec 2019 09:41:51 - 1.240
+++ st.c10 Jun 2021 10:11:47 -
@@ -343,7 +343,7 @@ static int st_mount_tape(dev_t, int);
static voidst_unmount(struct st_softc *, boolean);
static int st_decide_mode(struct st_softc *, boolean);
static voidststart(struct scsipi_periph *);
-static int ststart1(struct scsipi_periph *, struct buf *);
+static int ststart1(struct scsipi_periph *, struct buf *, int *);
static voidstrestart(void *);
static voidstdone(struct scsipi_xfer *, int);
static int st_read(struct st_softc *, char *, int, int);
@@ -1183,13 +1183,13 @@ abort:
* ststart() is called with channel lock held
*/
static int
-ststart1(struct scsipi_periph *periph, struct buf *bp)
+ststart1(struct scsipi_periph *periph, struct buf *bp, int *errnop)
{
struct st_softc *st = device_private(periph->periph_dev);
struct scsipi_channel *chan = periph->periph_channel;
struct scsi_rw_tape cmd;
struct scsipi_xfer *xs;
- int flags, error;
+ int flags, error, complete = 1;
SC_DEBUG(periph, SCSIPI_DB2, ("ststart1 "));
@@ -1299,11 +1299,14 @@ ststart1(struct scsipi_periph *periph, s
error = scsipi_execute_xs(xs);
/* with a scsipi_xfer preallocated, scsipi_command can't fail */
KASSERT(error == 0);
+ if (error == 0)
+ complete = 0;
out:
mutex_exit(chan_mtx(chan));
- return error;
+ *errnop = error;
+ return complete;
}
static void
@@ -1312,7 +1315,7 @@ ststart(struct scsipi_periph *periph)
struct st_softc *st = device_private(periph->periph_dev);
struct scsipi_channel *chan = periph->periph_channel;
struct buf *bp;
- int error;
+ int error, complete;
SC_DEBUG(periph, SCSIPI_DB2, ("ststart "));
@@ -1325,19 +1328,20 @@ ststart(struct scsipi_periph *periph)
iostat_busy(st->stats);
mutex_exit(&st->sc_iolock);
- error = ststart1(periph, bp);
+ complete = ststart1(periph, bp, &error);
mutex_enter(&st->sc_iolock);
- if (error != 0)
+ if (complete) {
iostat_unbusy(st->stats, 0,
((bp->b_flags & B_READ) == B_READ));
- if (error == EAGAIN) {
- bufq_put(st->buf_defer, bp);
- break;
+ if (error == EAGAIN) {
+ bufq_put(st->buf_defer, bp);
+ break;
+ }
}
mutex_exit(&st->sc_iolock);
- if (error != 0) {
+ if (complete) {
bp->b_error = error;
bp->b_resid = bp->b_bcount;
biodone(bp);
--
Michael van Elst
Internet: mlel...@serpens.de
"A potential Snark may lurk in every tree."
Re: st.c update has broken dump multi-tape support
On Thu, Jun 10, 2021 at 11:22:45PM +0930, Brett Lymn wrote: > On Thu, Jun 10, 2021 at 12:13:22PM +0200, Michael van Elst wrote: > > On Thu, Jun 10, 2021 at 12:02:19PM +0200, Michael van Elst wrote: > > > > > If you don't like the fake errno, the function needs to return > > > two values, the error value and a boolean to finish the > > > unqueued request. Cleaner, but more changes. > > > > E.g. (not even compile-tested): > > > > I don't think that is quite right. Sorry, it doesn't fix the EOM handling, just the biodone. I still have to understand the EOM logic :) -- Michael van Elst Internet: mlel...@serpens.de "A potential Snark may lurk in every tree."
Re: st.c update has broken dump multi-tape support
On Thu, Jun 10, 2021 at 04:57:21PM +0200, Frank Kardel wrote:
> Hi !
>
> I assumed Michael was proposing a solution for the missing biodone() in the
> fixed block path (though that part was missing in the patch).
Yes, biodone needs to be called without the lock being held, so not
in ststart1().
Greetings,
--
Michael van Elst
Internet: mlel...@serpens.de
"A potential Snark may lurk in every tree."
Re: st.c update has broken dump multi-tape support
bl...@internode.on.net (Brett Lymn) writes: >Here is the patch that makes multi-tape dumps work for me: I'm currently testing http://ftp.netbsd.org/pub/NetBSD/misc/mlelstv/st.diff It's a bit cumbersome to do multi-tape dumps if your disk has 11GB data and the tape fits 40GB uncompressed.
Re: st.c update has broken dump multi-tape support
mlel...@serpens.de (Michael van Elst) writes:
>I'm currently testing
>http://ftp.netbsd.org/pub/NetBSD/misc/mlelstv/st.diff
Works for me:
DUMP: Found /dev/rdk0 on / in /etc/fstab
DUMP: Date of this level 0 dump: Sat Jun 12 00:24:45 2021
DUMP: Date of last level 0 dump: the epoch
DUMP: Dumping /dev/rdk0 (/) to /dev/nrst0
DUMP: Label: none
DUMP: mapping (Pass I) [regular files]
DUMP: mapping (Pass II) [directories]
DUMP: estimated 11948298 tape blocks.
DUMP: Volume 1 started at: Sat Jun 12 00:24:54 2021
DUMP: dumping (Pass III) [directories]
DUMP: dumping (Pass IV) [regular files]
DUMP: 18.18% done, finished in 0:22
DUMP: 39.37% done, finished in 0:15
DUMP: 56.67% done, finished in 0:11
DUMP: End of tape detected
DUMP: Closing /dev/nrst0
DUMP: Volume 1 completed at: Sat Jun 12 00:44:21 2021
DUMP: Volume 1 took 0:19:27
DUMP: Volume 1 transfer rate: 7380 KB/s
DUMP: Change Volumes: Mount volume #2
DUMP: Is the new volume mounted and ready to go?: ("yes" or "no") yes
DUMP: Volume 2 started at: Sat Jun 12 00:45:06 2021
DUMP: Volume 2 begins with blocks from inode 1448282
DUMP: 72.08% done, finished in 0:07
DUMP: 87.50% done, finished in 0:03
DUMP: 11948472 tape blocks on 2 volumes
DUMP: Volume 2 completed at: Sat Jun 12 00:54:40 2021
DUMP: Volume 2 took 0:09:34
DUMP: Volume 2 transfer rate: 5812 KB/s
DUMP: Date of this level 0 dump: Sat Jun 12 00:24:45 2021
DUMP: Date this dump completed: Sat Jun 12 00:54:40 2021
DUMP: Average transfer rate: 6596 KB/s
DUMP: level 0 dump on Sat Jun 12 00:24:45 2021
DUMP: Closing /dev/nrst0
DUMP: DUMP IS DONE
Can you please verify?
Re: st.c update has broken dump multi-tape support
On Sat, Jun 12, 2021 at 11:17:14AM +0200, Frank Kardel wrote:
> Hi !
>
> Look pretty good so far, ... can we remove following marked lines which are
> already
> taken care of in ststart1 complete case?
I guess so.
--
Michael van Elst
Internet: mlel...@serpens.de
"A potential Snark may lurk in every tree."
Re: Anyone feel like fixing pkgsrc/emulators/tme ?
rhia...@falu.nl (Rhialto) writes: >Indeed, there I misinterpreted the size of my 1G disk, and put sd0b >waaay out of bounds. I tried again, with partition b in cyl 1-63 and a >in 64-1023. I could not start b at 0; in that case the dd command >claimed it was read-only. The disklabel sector of a disk is read-only (you can lift that temporarily with the disklabel command).
Re: Support for RTL8723 in NetBSD?
br...@nmsu.edu (Brook Milligan) writes: >I am specifically interested in the RTL8723BU. That's an USB variant that also includes Bluetooth4.0. The urtwn driver could probably be adapted for the Wifi part.
Re: SPI on RPI?
b...@anduin.eldar.org (Brad Spencer) writes: >I was wondering if anyone is using the built in spibus on a Raspberry PI >(any version) lately. It is possible that I have outdated dts files, >but I do not see the spibus device on my 9.x installs and was curious if >it shows up for anyone in 9.x or -current and if anyone is currently >using it. You need to enable it in the dts file or via overlay. > It seems like the dts files that are in the tree would >contain a description for the SPI bus and the driver appears to have >been modified for FDT support. Running ofctl appears to show a number >of /spi@ lines but I don't know exactly what they indicate. % drvctl -p spi0 device-parent bcmspi0 % drvctl -p bcmspi0 fdt-path /soc/spi@7e204000 This is the main SPI interface connected to GPIO pins. The string is a name, but by convention the physical address of the controller registers is following the @. The BCM2835 has two additional SPI interfaces. The numbering in the BCM2835 documentation (SPI0,SPI1,SPI2) isn't necessarily the same as the device units (spi0,spi1,spi2) that just follow attachment order. Refering to the fdt-path or the base address avoids confusion.
Re: zpool import skips wedges due to a race condition
al...@yandex.ru (Alexander Nasonov) writes: >When I run zfs import, it launches 32 threads and opens 32 disks in >parallel, including cgd1 and dk24. But it can't open dk24 while >cgd1 is still open (it fails with EBUSY). >I fixed it in the attatched patch by running only one thread. It's >not the best approach but I'm not sure how to fix it properly. There are other issues with scanning devices in an arbitrary order, a parallel scan just makes it worse by adding randomness. LVM tries to solve this with an optional filter for device names when scanning for physical volumes. The root detection code tries to solve this by scanning twice, once for wedges, once for everything else, and by identifying wedges that alias a partition. For a complete solution you would need to know all the device relationships (dkX on wdY, cgdN on dmN, etc, but also e.g. dkX on cgdN). That still leaves out hot-plug devices where "upper" devices appear late.
Re: help getting SPI interface to work
dty...@anduin.org.uk (Dave Tyson) writes: >/dev/spi0 is defined which is a good start:: >[ 1.03] sun4ispi0 at simplebus1: SPI >[ 1.03] sun4ispi0: interrupting on GIC irq 42 >[ 1.03] spi0 at sun4ispi0: SPI bus >The board has the SPI mos1/miso/clk together with cs0 and cs1. >Looking at spi(4) there is no mention of a way to control cs0/1 to select >devices so I guess this is down to using gpio commands to pull the appropriate >pin low. The spi driver gets an address parameter that may control which cs line is asserted. It depends on the hardware if that is actually used. On these devices, the SPI controller is multiplexed on GPIO pins. You need to activate the function. This can be done by providing the proper DTB file or overlay, it _could_ also be done with the gpio driver (selecting an alt mode), but the sunxi gpio driver doesn't support that. >command = 0 ; /*we are not sending anything */ >spit.sit_addr = 0x00 ; >spit.sit_send = &command ; if you don't send anything, use NULL. >The device just needs the register address sending and should return a single >byte with the contents. Not sure what you want to control, but most devices require a read command to actually send data. The read command then usually includes the register address, sit_addr is not the register address but selects a slave device.
Re: Raspberry Pi camera under NetBSD current
dty...@anduin.org.uk (Dave Tyson) writes: >I have been trying to get the raspberry pi camera to work on a model B under a >recent current snapshot. > NetBSD 9.99.88 (RPI) #0: Fri Sep 24 18:47:29 UTC 2021 > mkre...@mkrepro.netbsd.org:/usr/src/sys/arch/evbarm/compile/RPI >As standard booting off the sdcard works fine with the default config.txt, >but to use the camera you need to modify this to add start_x=1 and set the >gpu mem to 128. With the changed options you need different microcode files >in the /boot partition start_x.elf and fixup_x.dat. NetBSD doesn't supply >these, but I pulled versions from the git repository. >The problem is that the system boots, but fails to attach the sdcard and thus >cannot find root, I just tried this with an older 9.99.81 installation on a RPI3b+ and a recent snapshot of the firmware files (around August) and NetBSD boots without a problem. Trying to access the camera with raspistill however ends in a crash in the vchiq driver.
Re: Raspberry Pi camera under NetBSD current
dty...@anduin.org.uk (Dave Tyson) writes: >> Trying to access the camera with raspistill however ends in a crash >> in the vchiq driver. >Thanks for the data point. I guess there may be significant differences in the >microcode files between the RPI1B and RPI3b+, but at least the kernel loaded >OK for you so the sdcard driver works. I have turned on debugging for the >broadcom sdcard hooks and got a few hints as to where the problem lies - but >need to look closely at the source to pin point the failure. Of course, even >if I can get further I may still suffer the same crash with raspistill. >FreeBSD works OK and I can get pictures, so I know it is achievable. I had a little success now with the camara and raspistill. http://ftp.netbsd.org/pub/NetBSD/misc/mlelstv/cam.jpg The file is slightly corrupted (truncated?) but can be displayed.
Re: HEADS UP: Merging drm update
riastr...@netbsd.org (Taylor R Campbell) writes: > #include > if (bpa <=3D BADADDR && BADADDR < bpa + size) > db_stacktrace(); >Then share the dmesg output on boot with this change to >bus_space_reserve? >This way we can track down who's reserving the registers that >intel_opregion.c wants. In my case (T420 with Sandy Bridge) nobody did bus_space_reserve the registers that intel_opregion wants. This here is the attempt to map the opregion: bus_space_reserve 0x80554799: 0xdaef6018+0x2000 -> extent_alloc_region failed bus_space_map 0x807689ee: 0xdaef6018+0x2000 -> bus_space_reserve failed The iomem extent at that point is: extent `iomem' (0x0 - 0x), flags = 0x3 0x0 - 0x57fff 0x58000 - 0x58fff 0x59000 - 0x9 0x10 - 0x1fff 0x2020 - 0x3fff 0x4020 - 0xda99efff 0xdae9f000 - 0xdaf9efff < 0xdaf9f000 - 0xdaffefff 0xdafff000 - 0xdaff 0xf000 - 0xf01f 0xf020 - 0xf03f 0xf140 - 0xf14000ff 0xf240 - 0xf2401fff 0xf250 - 0xf251 0xf252 - 0xf2523fff 0xf2528000 - 0xf25287ff 0xf2529000 - 0xf25293ff 0xf252a000 - 0xf252a3ff 0xf252b000 - 0xf252bfff 0xf800 - 0xf8000fff 0xf801 - 0xf8010fff 0xf80b - 0xf80b0fff 0xf80c8000 - 0xf80c8fff 0xf80d - 0xf80d0fff 0xf80d8000 - 0xf80d8fff 0xf80e - 0xf80e0fff 0xf80e1000 - 0xf80e1fff 0xf80e3000 - 0xf80e3fff 0xf80e4000 - 0xf80e4fff 0xf80e8000 - 0xf80e8fff 0xf80f8000 - 0xf80f8fff 0xf80fa000 - 0xf80fafff 0xf80fb000 - 0xf80fbfff 0xf830 - 0xf8300fff 0xf8d0 - 0xf8d00fff 0xfed0 - 0xfed003ff 0xfed1c000 - 0xfed1 0xfed4 - 0xfed44fff 0x1 - 0x21e5f The iomem extent is initialized from the UEFI memory map: # N STARTEND 0 7 00057fff 1 10 00058000 00058fff 2 7 00059000 0009 3 7 0010 1fff 4 0 2000 201f 5 7 2020 3fff 6 0 4000 401f 7 7 4020 da99efff 8 5 da99f000 daac1fff 9 5 daac2000 dab9efff 10 6 dab9f000 dacb1fff 11 6 dacb2000 dad9efff 12 0 dad9f000 dae21fff 13 0 dae22000 dae9afff 14 0 dae9b000 dae9bfff 15 0 dae9c000 dae9efff 16 10 dae9f000 daeddfff 17 10 daede000 daf9efff <-- 18 9 daf9f000 dafdcfff 19 9 dafdd000 daffefff 20 7 dafff000 daff 21 11 f80f8000 f80f8fff 22 11 fed1c000 fed1 23 7 0001 00021e5f The second column is the EFI md_type that gets translated to a bootinfo memory type: 0 = null -> BIM_Reserved 5 = rt_code -> BIM_Reserved 6 = rt_data -> BIM_Reserved 7 = free -> BIM_Memory 9 = reclaim -> BIM_ACPI 10 = firmware -> BIM_NVS 11 = iomem-> BIM_Reserved The needed pages are in cluster 17 of type BIM_NVS, which the extent has added as pre-allocated (merged with cluster 16).
