Re: Odd kernel message
On 25/06/2024 20:04, J. Hannken-Illjes wrote: While flushing dirty blocks on a device node new dirty blocks appeared. In theory this should not happen -- but the vflush will retry anyway. If you see it one or two times there is no real problem. Good to know that it won't actually mess the filesystem integrity up. I've seen it precisely once and I've done 100s of bulk pkgsrc builds on this system and even more OS builds. I might need to investigate why dirty block flushing is taking so long as it could indicate an SSD that's on its way out (saw something similar on another system). Could having the 'discard' option on impact things? I know TRIM operations can sometimes be slow. Mike
Odd kernel message
Never seen this before so I'm not sure what it means: [ 18411.785487] vflushbuf: dirty: vnode 0xc40eae687040 flags 0x4010 [ 18411.785487] tag VT_UFS(1) type VBLK(3) mount 0xc40eacae3000 typedata 0xc40eae74bb00 [ 18411.785487] usecount 576247 writecount 0 holdcount 11238 [ 18411.785487] size 0 writesize 0 numoutput 0 [ 18411.785487] data 0xc40eae6a5340 lock 0xc40eae687200 [ 18411.785487] state LOADED key(0xc40eacae3000 8) 03 5a 4f 00 00 00 00 00 [ 18411.785487] lrulisthd 0x818bc910 [ 18411.785487] tag VT_UFS, ino 5200387, on dev 168, 1 flags 0x0, nlink 1 [ 18411.785487] mode 060640, owner 0, group 5, size 0 Was probably in the middle of a pkgsrc build but not 100% sure of that. Mike
Re: modesetting vs intel in 10.0
On 30/08/2023 09:56, nia wrote: I think detecting the year of manufacture is too much of a hard problem - there are simply too many new cards and I have no idea about a "cutoff point" where modesetting starts being OK (if it even isn't okay for any old cards at all - it should work as long as DRM/KMS works AFAIK) > Well speaking as someone whose older card worked fine under 9 and now just ends up as a black screen with both the intel driver and the modesetting one on 10.0. I'm more interesting in getting back to having a working accelerated X setup. I did see the tearing on the intel driver on 9.x but it was never bad enough to make me try the modesetting driver. For reference my now broken hardware is: [ 1.008474] pci1: i/o space, memory space enabled, rd/line, wr/inv ok [ 1.008474] i915drmkms0 at pci0 dev 2 function 0: Intel Haswell Integrated Graphics Device (rev. 0x06) See kern/57268 for how my hardware fails. Mike
Re: modesetting vs intel in 10.0
On 08/07/2023 23:06, David Brownlee wrote: Would it be worth trying to collect some data on users running NetBSD on intel display hardware, to see if there are any cases where intel_drv works and modesetting_drv does not? As a datapoint, on a Thinkpad T480 runs OK with the default intel_dev. Renaming away /usr/X11R7/lib/modules/drivers/intel_drv.so and restarting X runs fine with modesetting_drv, and "grep Mesa /var/log/Xorg.0.log" gives (II) modeset(0): glamor X acceleration enabled on Mesa DRI Intel(R) UHD Graphics 620 (Kabylake GT2) Both are equally bad for me. The console works perfectly but I get stuck in the blank screen heartbeat death with both (see kern/57268): [44.509] (--) intel(0): Integrated Graphics Chipset: Intel(R) HD Graphics 4600 [44.509] (--) intel(0): CPU: x86-64, sse2, sse3, ssse3, sse4.1, sse4.2, avx, avx2; using a maximum of 4 threads So fiddling with the default X driver for intel hardware is only part of the solution. We need to address the core issues in the i915kmsdrm that impact both. Mike
Re: How to limit amount of virtual memory used for files (was: Re: Tuning ZFS memory usage on NetBSD - call for advice)
On 22/09/2022 06:44, Lloyd Parkes wrote: Can we put together a catalogue of clearly defined problems so that we can reproduce them and investigate further? While Håvard appears to have solved his problem, I'm pretty sure I have an unused G4 Mac Mini of my own that I can try and reproduce his problem on. So I changed vm.filemin and vm.filemax to solve my excessive swapping issues. Basically the system was preferring to keep file cache around and was evicting memory for processes that consumed swap (so data pages I'm assuming) rather than file cache. Under heavy memory/file usage (pkgsrc bulk builds) any large process running at the time of the build ended up going non-responsive. So it could be that the all that needs to change here are the defaults for those parameters. For the record I have: vm.filemax=10 vm.filemin=1 in /etc/sysctl.conf on a 16GB 9.3-STABLE system. The system can comfortably use more memory than that for file cache. As I write this message its currently using 9GB for file cache (which I don't see as a problem as there are no other demands on the system memory at the moment. Starting a new process like firefox correctly dumped file cache over other memory with this config. Also long running firefox processes remained responsive both during and after the builds with this change. Mike
Re: macppc system wedging under memory pressure
On 16/09/2022 06:14, Lloyd Parkes wrote: You aren't the first person to have problems with memory pressure. We really are going to have to get around to documenting the memory management algorithms and all the tuning knobs. I used to use this page (https://imil.net/NetBSD/mirror/vm_tune.html), but I have no idea how current it is. Also, I haven't used my smaller systems for a while now. In the past, I used to set vm.filemax to 5 because I never want a page that I can simply reread to force an anonymous page to be written out to swap. 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. This is all on 9.3 stable and all alther vm.xxx setting are at their default. Mike
Re: i386/amd64 image generated trough mkimage stuck on primary bootsrap at boot
On 07/07/2022 15:40, br0nko wrote: Hi, 0: NetBSD (sysid 169) start 63, size 1568384 (766 MB, Cyls 0/1/1-97/160/62), Active beg: cylinder0, head 1, sector 1 end: cylinder 97, head 160, sector 62 Information from PBR: Not bootable: All bytes are identical (0x00) Not bootable: Bad magic number (0x) No MBR boot code in the partition table. fdisk -i /dev/rvnd0 should resolve that I think.
Re: error upgrading packages on current / pkg database
On 15/04/2022 17:19, Riccardo Mottola wrote: Hello, I did a full system upgrade (running now ) and then got current pkgsrc. Now I try to run pkg_rolling-replace -uv ; it compiled for days, then stops. disc# pkg_admin check ...pkg_admin: can't open /usr/pkg/pkgdb/glib2-2.70.2nb1/+CONTENTS: No such file or directory Hmm. Thats interesting. I've seen that happen on one of my 9.2-STABLE systems when doing a pkgin upgrade. Although in my case it was librsvg that got clobbered. Instead of the correct pkgdb data the folder existed but contained a random core file. The core file wasn't from any pkg tool. I ended up with: /usr/pkg/pkgdb/librsvg-2.52.6/gdk-pixbuf-query.core Which isn't even a tool I use its just something pulled in as a dependendency. disc# pkg_admin rebuild pkg_admin: glib2-2.70.2nb1: can't open `+CONTENTS' disc# pkg_admin rebuild-tree pkg_admin: Cannot read +CONTENTS of package glib2-2.70.2nb1 I don't know what else to try to fix. The files in that folder are container within the pkg .tar.gz file if you have it around so you can extract them into the folder and then use pkg_admin to put things back together. That's what I did to sort myself out :) Something like: tar zxf glib-2.70.2nb1.tgz +* Mike
Re: Unusable system during dd to USB block device
On 28/12/2020 14:08, Arto Huusko wrote: Is this something known, or should I file a PR? Obviously writing a disk image using the block device is not the right way to do it, but neither should the system slow down the way it did. The need to use the raw device for dd block operations is known (at least it is to me. Although last time I screwed up and forgot I don't recall it making the system run slow for other IO ops. However I'm not sure I particularly tried any as I was waiting for the operation to complete (and wondering why it was taking so long ;) ). Mike
Re: [HEADS UP] pkgsrc default database directory changed
On 07/12/2020 13:17, Thomas Klausner wrote: While that is true, pkgsrc will insist on using pkg_install 20200828 or newer, so if you want to build packages from source, you'll still have to update your installed pkg_install. And that requires a manual build of pkg_install (skipping the normal cwrappers dependency) on 9-stable and 8-stable. Not sure if that will be true after pullups have happened but I suspect it might still be as there won't be a version number bump that pkgsrc can use to detect the newer tool. Mike
Re: [HEADS UP] pkgsrc default database directory changed
On 07/12/2020 10:06, Thomas Klausner wrote: On Mon, Dec 07, 2020 at 09:53:46AM +, Mike Pumford wrote: More fallout from this change: => Build dependency cwrappers>=20150314: NOT found => Verifying reinstall for ../../pkgtools/cwrappers ===> Trying to handle out-dated pkg_install... ===> Cleaning for pkg_install-20201205 ERROR: This package has set PKG_FAIL_REASON: ERROR: Circular dependency detected This is on an empty system trying to build cwrappers. You must rebuild and replace pkg_install first. What an awful user experience for a first time user. Oh pkgsrc doesn't work unless you do some special magic first. Also in this particular case doing that step is actually awkward because the builds are being done by an script (which I've not got to modify to handle this ridiculous special case). Mike
Re: [HEADS UP] pkgsrc default database directory changed
On 07/12/2020 02:13, Thomas Mueller wrote: from Thomas Klausner : I've collected specific advice outside of the basic ones here: http://pkgsrc.org/news/pkgdb-change/ More fallout from this change: => Build dependency cwrappers>=20150314: NOT found => Verifying reinstall for ../../pkgtools/cwrappers ===> Trying to handle out-dated pkg_install... ===> Cleaning for pkg_install-20201205 ERROR: This package has set PKG_FAIL_REASON: ERROR: Circular dependency detected This is on an empty system trying to build cwrappers. Also one other question. What happens to pkgin users on an update? It doesn't treat pkg_install specally from memory. If it doesn't he transition from old db to new db will happen in the middle of an upgrade. Which will blow up spectactularly. Mike
Re: [HEADS UP] pkgsrc default database directory changed
On 04/12/2020 22:29, John Nemeth wrote: Minor correction: 7 is no longer supported. Generally only two release branches are supported with the oldest being desupported about a month after a new major release comes out. 7 got extra time due to Covid-19, but was completely desupported some time ago. I wasn't sure if that Covid extension had run out yet. I'm pretty much universally on 9 these days so the absense of a pullup to 7 is fine from my personal perspective. Mike
Re: [HEADS UP] pkgsrc default database directory changed
On 02/12/2020 23:41, Thomas Klausner wrote: On Wed, Dec 02, 2020 at 03:07:55PM -0800, Paul Goyette wrote: This is just getting too complicated. Too many manual steps, and too many changes to too many long-established procedures. Yeah, I'm sorry that you spent too much time on this. Actually, the easiest way is to just: cd /usr/pkgsrc/pkgtools/pkg_install make USE_CWRAPPERS=no install install -c /usr/pkg/sbin/pkg_* /usr/sbin Err. This works great until the next system update. At which point the system pkg_* binaries will be re-instated and break everything. Unless you are going to ensure that /usr/sbin/pkg_* are going to be updated not just in current but also in the 9, 8 and 7 release branches which are all still supported. Any solution that overwrites core binaries with a binary from pkgsrc won't survive an OS upgrade. As others have said this is starting to look like the consequences of the change have not been thought through. Mike
Re: NetBSD-7.0 boots OK and NetBSD-8.0 hangs/crashes during boot on a MacBook7,1
On 06/07/2020 16:07, Martin Husemann wrote: Stupid question: are there now actually x86 boards that do *not* have a real serial on-board? I have not seen any so far (none of the new ones come with an external connector of course, but they can be added easily unless it is a notebook). A quick look around suggests that some of the very high end gaming ones don't. Also assuming users will actually be able to find a cable to actually hook up the motherboard COM port is optimistic. You would probably have to get one second hand these days and if I remember correctly there are 2 incompatible pinouts for the 10 pin header. :( Mike
Re: NetBSD-7.0 boots OK and NetBSD-8.0 hangs/crashes during boot on a MacBook7,1
On 06/07/2020 10:01, Martin Husemann wrote: On Mon, Jul 06, 2020 at 09:52:31AM +0100, Mike Pumford wrote: Like it or not its probably going to be a long term requirement to have console USB support. If not for the serial output its becoming more and more necessary just to get a console keyboard for DDB. USB keyboards as console in ddb worked fine last I tested. Running the usb host in polled mode however is quite a bit simpler than doing the device part (where you have to obey timings from the host). That hasn't been my experience. Until I turned off ddb I had several situations when one of my systems crashed during boot and was stuck at a DDB prompt that needed a PS2 keyboard for interaction. Mike
Re: NetBSD-7.0 boots OK and NetBSD-8.0 hangs/crashes during boot on a MacBook7,1
On 06/07/2020 05:09, Brian Buhrow wrote: Hello. I agree with Mouse, except that I also think it would be very helpful and useful to have a serial console on USB only devices. I wonder if we could make the console a virtual device which is attached dynamically to a USB serial port if and when available. that would let the system think it has a console, but one would only see it when the kernel and the USB subsystem are up. Yes, I get this would make watching things boot challenging, but by the time you get to single user mode, the kernel is fully up and running and USB is or should be available by then. Like it or not its probably going to be a long term requirement to have console USB support. If not for the serial output its becoming more and more necessary just to get a console keyboard for DDB. I don't think its possible to by an amd64 motherboard (at least in the consumer space) that actually has a PS2 port for a keyboard any more. Mike
Re: NetBSD 9 on ThinkPad X220
On 27/05/2020 17:24, Jukka Ruohonen wrote: On Tue, May 26, 2020 at 07:38:31AM +, nia wrote: Yeah, we really shouldn't be using xf86-video-intel. It's been deprecated in favour of the modesetting driver for years. The modesetting(4) driver indeed works fine. Maybe there could be a note for newcomers and re-comers in x11/xf86-video-intel that this driver has been deprecated. Does the modesetting driver support GL? If it does why is the intel driver the default driver used by X with no configuration on intel hardware. If modesetting is its replacement shouldn't that be used automatically in preference to the intel driver. As a user I shouldn't have to manually configure to get the non-deprecated driver. Mike
Re: github.com/NetBSD/src 5 days old?
On 18/05/2020 14:03, matthew sporleder wrote: If you want small and fast you can use shallow clone and, although you get the entire tree's bundle, it is small and fast. You can then use --sparse to build a "sparse" (kernel only or whatever) limited checkout (aka working dir) -- (new git feature-- https://git-scm.com/docs/git-sparse-checkout / https://git-scm.com/docs/git-read-tree#_sparse_checkout ) / I don't know about mercurial's version of this Its also not worth getting too hung up on small systems being able to check out the source code. Given the memory hog that is GCC these days chances are if you can't check out the source tree you probably can't compile it anyway as GCC will need more memory than your system has. Mike
Re: lang/rust build fails
On 14/05/2020 17:53, Robert Nestor wrote: running: /pkg_comp/work/pkg/lang/rust/work/rust-bootstrap/bin/cargo build --manifest-path /pkg_comp/work/pkg/lang/rust/work/rustc-1.42.0-src/src/bootstrap/Cargo.toml --frozen Compiling proc-macro2 v0.4.30 At that point there’s nothing consuming CPU time in the build and everything seems to be waiting on something to happen that never does. I’ve left the system in that state for about 24 hours and still no progress. Any clues? Could this be something related to some of the recent kernel changes? It might be but it also happens sometimes on 9.0-stable as well. Never managed to work out why. Mike
Re: qemu emulated machine crashes due to disk timeouts
On 14/05/2020 14:19, m...@netbsd.org wrote: QEMU emulation isn't a niche setup, we should aim to have it work out of the box without adjusting sysctls, IMO. I'd agree with that. Perhaps the real question to ask here is why is a QEMU ATA operation taking 30 seconds to complete in the first place? I know the ATA interface isn't that virtualisation friendly but an IO delay that long seems insane and points to either a QEMU issue or something the NetBSD kernel is doing to confuse the QEMU ATA emulation. Mike
Re: firefox-74.0 crash on -current
On 29/03/2020 19:27, Chavdar Ivanov wrote: I usually do the updates the long way via pkg_rolling-replace, this time was lazy and updated only firefox, rust and cbindgen before building firefox, so most likely it is my fault. #0 0x7b00ceb85e8a in _lwp_kill () from /usr/lib/libc.so.12 #1 0x7b00bc9e6681 in ?? () from /usr/pkg/lib/firefox/libxul.so #2 0x7b00bd2628a7 in ?? () from /usr/pkg/lib/firefox/libxul.so #3 0x7b00ceab0010 in opendir () from /usr/lib/libc.so.12 #4 0x0001000b in ?? () #5 0x in ?? () ... Haven't analysed the core but webgl has gone from working to non-working for me after upgrading to firefox-74 on 9.0 as well. Web GL demos used to work fine (albeit occasionally a bit slowly on some of the more challenging ones) on the previous firefox-73. In my case I'm fairly certain I can rule out package inconsistencies as I build a complete package set from the ground up in a chroot and then install/refresh everything with pkgin. X reports the card as: [40.980] (--) intel(0): Integrated Graphics Chipset: Intel(R) HD Graphics 4600 [40.980] (--) intel(0): CPU: x86-64, sse2, sse3, ssse3, sse4.1, sse4.2, avx, avx2; using a maximum of 4 threads [40.980] (II) intel(0): Creating default Display subsection in Screen section Its the onboard graphics from a: cpu0: "Intel(R) Core(TM) i7-4790K CPU @ 4.00GHz" cpu0: Intel 4th gen Core, Xeon E3-12xx v3 (Haswell) (686-class), 3997.87 MHz cpu0: family 0x6 model 0x3c stepping 0x3 (id 0x306c3 Mike
Re: Build time measurements
On 24/03/2020 21:47, Andrew Doran wrote: DIAGNOSTIC and acpicpu are disabled in all kernels but they are otherwise GENERIC. The 2020-04-?? kernel is HEAD plus the remaining changes from the ad-namecache branch. Curious to know why acpicpu is a performance hit. Is it just that it downclocks the CPU if you don't have estd to ramp it up or something more fundamental? Mike
Re: intelfb & wsdisplay
On 14/10/2019 17:56, Michael van Elst wrote: pr...@cam.ac.uk (Patrick Welche) writes: no data for est. mode 640x480x67 That's from EDID data: 640x480 pixels at 67 Hertz. See the same thing on 9.0_BETA. It doesn't actually seem to impact display operation as I seem to have fully operation X operation on that system as well. Mike
Re: 9.0-BETA panic
On 29/09/2019 21:54, Mike Pumford wrote: Was doing a pkgsrc build under jenkins and got the following panic: [ 14305.111922] panic: kernel diagnostic assertion "semcnt >= 0" failed: file "/ work/netbsd/9-stable/src/sys/kern/kern_uidinfo.c", line 241 [ 14305.111922] cpu5: Begin traceback... [ 14305.111922] vpanic() at netbsd:vpanic+0x160 [ 14305.111922] stge_eeprom_wait.isra.4() at netbsd:stge_eeprom_wait.isra.4 [ 14305.111922] chgsemcnt() at netbsd:chgsemcnt+0x56 [ 14305.111922] ksem_release() at netbsd:ksem_release+0x6a [ 14305.111922] ksem_close_fop() at netbsd:ksem_close_fop+0x49 [ 14305.111922] closef() at netbsd:closef+0x6d [ 14305.111922] fd_close() at netbsd:fd_close+0x1f4 [ 14305.121926] sys__ksem_destroy() at netbsd:sys__ksem_destroy+0x9c [ 14305.121926] syscall() at netbsd:syscall+0x181 [ 14305.121926] --- syscall (number 255) --- [ 14305.121926] 7b40fce3ee6a: [ 14305.121926] cpu5: End traceback... Bit more info. Kernel build time (which also represents the source tree checkout time): NetBSD trigati.mudcovered.org.uk 9.0_BETA NetBSD 9.0_BETA (GENERIC) #0: Sat Sep 28 09:56:10 BST 2019 buil...@trigati.mudcovered.org.uk:/work/netbsd/.jenkins/workspace/NetBSD-9-amd64-build/obj.amd64/sys/arch/amd64/compile/GENERIC amd64 Packages being compiled were for 8.1_STABLE in a pkg_comp1 chroot environment. Can't tell which package was being compiled at the time of death as I couldn't retrieve the jenkins build log. I'm re-running the same build to see if it happens again. Mike
9.0-BETA panic
Was doing a pkgsrc build under jenkins and got the following panic: [ 14305.111922] panic: kernel diagnostic assertion "semcnt >= 0" failed: file "/ work/netbsd/9-stable/src/sys/kern/kern_uidinfo.c", line 241 [ 14305.111922] cpu5: Begin traceback... [ 14305.111922] vpanic() at netbsd:vpanic+0x160 [ 14305.111922] stge_eeprom_wait.isra.4() at netbsd:stge_eeprom_wait.isra.4 [ 14305.111922] chgsemcnt() at netbsd:chgsemcnt+0x56 [ 14305.111922] ksem_release() at netbsd:ksem_release+0x6a [ 14305.111922] ksem_close_fop() at netbsd:ksem_close_fop+0x49 [ 14305.111922] closef() at netbsd:closef+0x6d [ 14305.111922] fd_close() at netbsd:fd_close+0x1f4 [ 14305.121926] sys__ksem_destroy() at netbsd:sys__ksem_destroy+0x9c [ 14305.121926] syscall() at netbsd:syscall+0x181 [ 14305.121926] --- syscall (number 255) --- [ 14305.121926] 7b40fce3ee6a: [ 14305.121926] cpu5: End traceback...
Re: mfii0 kudos to bouyer@ Was Re: dmesg | grep -c "not configured" = 240...
On 04/12/2018 20:22, Manuel Bouyer wrote: On Tue, Dec 04, 2018 at 07:17:59PM +, Mike Pumford wrote: On 03/12/2018 22:47, Manuel Bouyer wrote: Hello, I synced our mpii(4) driver with the latest OpenBSD one and commited to HEAD. I tested it with a SAS2 controller (I don't have SAS3 ones), so it would be good if someone could test a SAS3 with some drives (the command setup is different between SAS2 and SAS3, this is the code path I can't test). Tested with my SAS3 card and an enclosure. Relevent dmesg bits are: mpii0 at pci1 dev 0 function 0: vendor 1000 product 0097 (rev. 0x01) mpii0: interrupting at msi0 vec 0 mpii0: SAS9300-8e, firmware 0.250.110.0, MPI 2.5 scsibus0 at mpii0: 768 targets, 8 luns per target scsibus0: waiting 2 seconds for devices to settle... sd0 at scsibus0 target 0 lun 0: disk fixed sd1 at scsibus0 target 1 lun 0: disk fixed sd2 at scsibus0 target 2 lun 0: disk fixed sd3 at scsibus0 target 3 lun 0: disk fixed sd4 at scsibus0 target 4 lun 0: disk fixed sd5 at scsibus0 target 5 lun 0: disk fixed sd6 at scsibus0 target 6 lun 0: disk fixed sd7 at scsibus0 target 7 lun 0: disk fixed sd8 at scsibus0 target 8 lun 0: disk fixed sd9 at scsibus0 target 9 lun 0: disk fixed sd10 at scsibus0 target 10 lun 0: disk fixed sd11 at scsibus0 target 11 lun 0: disk fixed sd12 at scsibus0 target 12 lun 0: disk fixed sd13 at scsibus0 target 13 lun 0: disk fixed sd14 at scsibus0 target 14 lun 0: disk fixed sd15 at scsibus0 target 15 lun 0: disk fixed sd16 at scsibus0 target 16 lun 0: disk fixed sd17 at scsibus0 target 17 lun 0: disk fixed Did some IO to the disks and got read/write performance at exactly the speeds I'd expect >170MB/s read and a little less for writing. Was it with one disk, or several disks at once ? I get 80MB/s with a SATA SEAGATE ST375064 (750GB). With a newer controller and that much disk, I'd expect more than 170MB/s if several disks are used in parallel. It was just the one disk and its a SAS2 drive behind some SAS2 expanders so we aren't taking full advantage of the SAS3 speed. Sadly all the SAS3 drives I have access to are actually in use for real work. :( I will try a multi-drive test when I'm in the office again on Thursday. The 170MB is exactly the performance I'd expect for that drive and matches what it achieves in linux on the same hardware. Disk insertion are working with my controller, I've not tested removal yet (will do tomorow). More testing is always welcome :) Okay I'll also do some power down/power up cycles on some of the drive bays in the enclosure which should test removal and insertion. The driver was definately reporting the SAS discovery events. I'll have a look at the PCI IDs in the other spare SAS3 systems to see if that will test any of the other new bits of code as well. Mike
Re: mfii0 kudos to bouyer@ Was Re: dmesg | grep -c "not configured" = 240...
On 04/12/2018 19:31, Mike Pumford wrote: On 04/12/2018 19:25, Martin Husemann wrote: On Tue, Dec 04, 2018 at 07:17:59PM +, Mike Pumford wrote: One thing that surprised me was that I was testing with the USB install image but instead of landing in sysinst I ended up at a a login prompt which was unexpected. Could this be because the USB disk that was my root device ended up as sd23 and there is a hard coded sd0 somewhere in the install code? No hardcoded sd0, but maybe the boot device matching did not properly work for this case (depends on geometry and stuff that the bootloader gets from bios USB emulation or something). Not sure about boot device (I don't have the console in front of me) but it definately reported the rootfs as /dev/sd23a and mounted the rootfs automatically. Is there any particular output I should look for? It is quite an ancient machine so the BIOS USB could be odd. I'm happy to do a retest on Thursday when I've next got access to the system. I had the same problem with an earlier boot of the same system (without the mpii disks powered on) in that case the rootfs was sd5 as the system has a usb multi-card reader that got detected first. Just found in the saved dmesg: [ 6.612498] boot device: sd23 [ 6.612498] root on sd23a dumps on sd23b So that all looks right. Mike
Re: mfii0 kudos to bouyer@ Was Re: dmesg | grep -c "not configured" = 240...
On 04/12/2018 19:25, Martin Husemann wrote: On Tue, Dec 04, 2018 at 07:17:59PM +, Mike Pumford wrote: One thing that surprised me was that I was testing with the USB install image but instead of landing in sysinst I ended up at a a login prompt which was unexpected. Could this be because the USB disk that was my root device ended up as sd23 and there is a hard coded sd0 somewhere in the install code? No hardcoded sd0, but maybe the boot device matching did not properly work for this case (depends on geometry and stuff that the bootloader gets from bios USB emulation or something). Not sure about boot device (I don't have the console in front of me) but it definately reported the rootfs as /dev/sd23a and mounted the rootfs automatically. Is there any particular output I should look for? It is quite an ancient machine so the BIOS USB could be odd. I'm happy to do a retest on Thursday when I've next got access to the system. I had the same problem with an earlier boot of the same system (without the mpii disks powered on) in that case the rootfs was sd5 as the system has a usb multi-card reader that got detected first. Mike
Re: mfii0 kudos to bouyer@ Was Re: dmesg | grep -c "not configured" = 240...
On 04/12/2018 19:17, Mike Pumford wrote: o this tests one the cards you have brought in. I do have some other 12G hosts but I think they are the same chip. They would be more awkward to test with as they are serial console only machines that have only ever been tested running linux. Just looked at the diff. The old code had an explicit 0,0 entry at the end of the PCI Ids array but this has been lost from the new version of the code so we are now taking it on faith that the entry one past the end of the static array will have a 0 mpii_vendor field. Is this safe? Mike
Re: mfii0 kudos to bouyer@ Was Re: dmesg | grep -c "not configured" = 240...
On 03/12/2018 22:47, Manuel Bouyer wrote: Hello, I synced our mpii(4) driver with the latest OpenBSD one and commited to HEAD. I tested it with a SAS2 controller (I don't have SAS3 ones), so it would be good if someone could test a SAS3 with some drives (the command setup is different between SAS2 and SAS3, this is the code path I can't test). Tested with my SAS3 card and an enclosure. Relevent dmesg bits are: mpii0 at pci1 dev 0 function 0: vendor 1000 product 0097 (rev. 0x01) mpii0: interrupting at msi0 vec 0 mpii0: SAS9300-8e, firmware 0.250.110.0, MPI 2.5 scsibus0 at mpii0: 768 targets, 8 luns per target scsibus0: waiting 2 seconds for devices to settle... sd0 at scsibus0 target 0 lun 0: disk fixed sd1 at scsibus0 target 1 lun 0: disk fixed sd2 at scsibus0 target 2 lun 0: disk fixed sd3 at scsibus0 target 3 lun 0: disk fixed sd4 at scsibus0 target 4 lun 0: disk fixed sd5 at scsibus0 target 5 lun 0: disk fixed sd6 at scsibus0 target 6 lun 0: disk fixed sd7 at scsibus0 target 7 lun 0: disk fixed sd8 at scsibus0 target 8 lun 0: disk fixed sd9 at scsibus0 target 9 lun 0: disk fixed sd10 at scsibus0 target 10 lun 0: disk fixed sd11 at scsibus0 target 11 lun 0: disk fixed sd12 at scsibus0 target 12 lun 0: disk fixed sd13 at scsibus0 target 13 lun 0: disk fixed sd14 at scsibus0 target 14 lun 0: disk fixed sd15 at scsibus0 target 15 lun 0: disk fixed sd16 at scsibus0 target 16 lun 0: disk fixed sd17 at scsibus0 target 17 lun 0: disk fixed Did some IO to the disks and got read/write performance at exactly the speeds I'd expect >170MB/s read and a little less for writing. So this tests one the cards you have brought in. I do have some other 12G hosts but I think they are the same chip. They would be more awkward to test with as they are serial console only machines that have only ever been tested running linux. These disk are in an enclosure so if you want me to test hotplug stuff with this setup I can. Any data on the disks is entirely sacrificial at the moment. One thing that surprised me was that I was testing with the USB install image but instead of landing in sysinst I ended up at a a login prompt which was unexpected. Could this be because the USB disk that was my root device ended up as sd23 and there is a hard coded sd0 somewhere in the install code? Mike
Re: mfii0 kudos to bouyer@ Was Re: dmesg | grep -c "not configured" = 240...
On 03/12/2018 22:47, Manuel Bouyer wrote: Hello, I synced our mpii(4) driver with the latest OpenBSD one and commited to HEAD. I tested it with a SAS2 controller (I don't have SAS3 ones), so it would be good if someone could test a SAS3 with some drives (the command setup is different between SAS2 and SAS3, this is the code path I can't test). Just updating my current tree and doing a build. Will then take a USB bootable image to work and test it with the SAS3 HBA there. Mike
Re: mfii0 kudos to bouyer@ Was Re: dmesg | grep -c "not configured" = 240...
On 30/11/2018 08:50, Stephen Borrill wrote: I cannot easily attach drives to it (it has external ports only, and I would need to drag it to our datacenter to connect it to something). Let's see what Mike Pumford's PCI IDs are. Wasn't able to check as I need to take a live USB stick in as the current system disk in that system is broken (its an ex-devtest box) and I forgot to pick it up. :( Will try again on Monday but from what I an remember all LSI SAS3 chipsets have a totally different driver to the SAS2 and SAS cards. I do have the ability to hook it up to a wide variety of disks though. Mike
Re: mfii0 kudos to bouyer@ Was Re: dmesg | grep -c "not configured" = 240...
On 29/11/2018 18:16, Manuel Bouyer wrote: Do you have drives connected to this controller ? If so I can probably come up with a patch this week-end. The SAS3 has a sighly different interface, but from looking at the OpenBSD driver it's all in a single function. I've got access to a spare LSI SAS3 HBA at work and have some SAS drives I could test with. I can get the exact PCI ids to see if its supported by the OpenBSD driver. Mike
apu2 SATA patch
On 26/11/2018 15:16, Greg Troxel wrote: Mike Pumford writes: I have one of these. The msata needs needs a small patch (needs an entry in the quirks table to be properly recognised as an ahci controller) but other than that it seems to work. No stability issues using sdhc as the system disk. Could you mail a patch, or file a PR with it? This seems like something that should be applied in the main tree. Heres the patch. I've not yet verified IO yet but the patch is based on how OpenBSD and FreeBSD handle the device and the detection messages match what they report. Index: sys/dev/pci/ahcisata_pci.c === RCS file: /cvsroot/src/sys/dev/pci/ahcisata_pci.c,v retrieving revision 1.38 diff -u -r1.38 ahcisata_pci.c --- sys/dev/pci/ahcisata_pci.c 13 Oct 2016 17:11:09 - 1.38 +++ sys/dev/pci/ahcisata_pci.c 26 Nov 2018 21:24:56 - @@ -194,6 +194,8 @@ AHCI_PCI_QUIRK_FORCE }, { PCI_VENDOR_ASMEDIA, PCI_PRODUCT_ASMEDIA_ASM1061_12, AHCI_PCI_QUIRK_FORCE }, + { PCI_VENDOR_AMD, PCI_PRODUCT_AMD_HUDSON_SATA, + AHCI_PCI_QUIRK_FORCE }, }; struct ahci_pci_softc {
Re: Rust, pkgsrc
On 05/11/2018 16:34, bch wrote: The latest rust (1.30?) supporting the latest Firefox is *brutal* to build. I’ve blown (and then resized) /tmp multiple times, and am now exhausted on /usr for its build artifacts, before it’s even actually installed. Does anybody have tips or tricks for dealing with rust-building (which has always been terribly painful CPU-wise), or should I just move to prebuilt packages? I think I’ve never seen a piece of software as horrible to build as rust... If you are on x86 and have access to a bigger system for building on have you considered running pbulk in a chroot environment or using pkg_comp. I've save myself a lot of time on my x86 systems by doing all the builds on a relatively well specced system and then just installing binary packages on the smaller ones. Do you use MAKEJOBS on your pkgsrc builds? If you do then add MAKE_JOBS_SAFE=no to the rust package Makefile. Without that I've found that make ends up spawning multiple rustc processes each of which internally then spawn even more threads causing ridiculous cpu overcommit. If you aren't using it and you are on a small system I don't know what to suggest. Even with that tweak compiling rust on a 4core (8 threads) 4GHz 64bit CPU with 16GB of RAM is still painfully slow and ends up maxing out the CPU for most of the build. Mike -bch
Re: Panic on acorn32 current
On 04/03/2018 17:09, Mike Pumford wrote: Finally had some time to bring my system up to date and found a problem. Got a panic at start of day (transcribed from a shot of the screen): fdc0 at pioc0 offset 0x3f0-0x3f7 irq12 drq 0x2000 Now raised as port-acorn32/53076 Mike
ps performance acorn32 (was Re: Panic on acorn32 current)
Take back the performance comment. Something is monumentally wrong with the 8.0-BETA ps. It takes ages to run: For comparison: # file /bin/ps /bin/ps: ELF 32-bit LSB executable, ARM, version 1, dynamically linked (uses shared libs), for NetBSD 6.99.40, compiled for: arm, not stripped # time ps>/dev/null 0.22 real 0.02 user 0.18 sys And in a chroot with the 8.0-BETA userland: # file /bin/ps /bin/ps: ELF 32-bit LSB shared object, ARM, version 1 (ARM), dynamically linked, interpreter /libexec/ld.elf_so, for NetBSD 8.0, compiled for: arm, not stripped # time ps >/dev/null 8.19 real 1.25 user 6.62 sys # I'd guess the bug is in the libraries as running the 8.0 ps with the 6.99.40 libraries performs at the same speed as the native 6.99.40 binary. Not a bug. ktrace showed what was going on. Massive repeated lstats of /dev. I'd not run /etc/rc.d/sysdb start in the chroot. Once that was done ps worked entirely sensibly with no odd performance issues. :). Apologies for the false alarm. Mike
Re: Panic on acorn32 current
On 04/03/2018 17:09, Mike Pumford wrote: Finally had some time to bring my system up to date and found a problem. Got a panic at start of day (transcribed from a shot of the screen): fdc0 at pioc0 offset 0x3f0-0x3f7 irq12 drq 0x2000 uvmfault(0xf036f42c, 217000, 2) -> e Fatal kernel mode ata abort: 'Translation Fault (P)' trapframe: 0xf03ccc40 FSR=183bd007, FAR=002170ef, spsr=2093 r0 =002170ef, r1 =f02f2a65, r2 =000d, r3 =00217047 r4 =0813, r5 =0066, r6 =f02f2a65, r7 =f0351190 r8 =f02f2a64, r9 =0005, r10=f02f2a64, r11=f040 r12=f03c, ssp=f04ccc94, slr=f0027288, pc =f02d90d8 Stopped in pid 0.1 (system) at netbsd:strlcpy+0x30:strb r5, [r0], #001 db>bt 0xf038: netbsd:irq_claim+0xc 0xf03cccf0: netbsd:intr_claim+0x58 0xf03ccd28: netbsd:fdcattach+0xc0 Tracking it back it was introduced quite a while back (rev 1.13) of the file which made the section of the file containg the irq description strings read only (but the irq_claim code writes them). The following patch fixes this issue and also corrects another bug that causes the interrupt names to get corrupted in systat. The legacy irq counter code expects all the irq names to be the same length and this patch restores that behaviour. This needs a pullup to 8.0 (which has exactly the same bug). 7.1 is also impacted but I've not actually run the patch there. With this patch applied current and 8.0-BETA actually boot up and work pretty much the same as the previous rather ancient 6.99.40 kernel it was running before and there doesn't appear to be any obvious performance drop with the new code. Take back the performance comment. Something is monumentally wrong with the 8.0-BETA ps. It takes ages to run: For comparison: # file /bin/ps /bin/ps: ELF 32-bit LSB executable, ARM, version 1, dynamically linked (uses shared libs), for NetBSD 6.99.40, compiled for: arm, not stripped # time ps>/dev/null 0.22 real 0.02 user 0.18 sys And in a chroot with the 8.0-BETA userland: # file /bin/ps /bin/ps: ELF 32-bit LSB shared object, ARM, version 1 (ARM), dynamically linked, interpreter /libexec/ld.elf_so, for NetBSD 8.0, compiled for: arm, not stripped # time ps >/dev/null 8.19 real 1.25 user 6.62 sys # I'd guess the bug is in the libraries as running the 8.0 ps with the 6.99.40 libraries performs at the same speed as the native 6.99.40 binary. Mike I've spotted some other issues: 1. Slight misdetect of the NE2000 derived ethernet chip 2. Hangs when attempt is made to reboot. 3. Bad behaviour in ddb. I've run into these before and I've got some rather hacky fixes. Once they are cleaned up I'll send out another message with patches for those as well. Mike
Panic on acorn32 current
Finally had some time to bring my system up to date and found a problem. Got a panic at start of day (transcribed from a shot of the screen): fdc0 at pioc0 offset 0x3f0-0x3f7 irq12 drq 0x2000 uvmfault(0xf036f42c, 217000, 2) -> e Fatal kernel mode ata abort: 'Translation Fault (P)' trapframe: 0xf03ccc40 FSR=183bd007, FAR=002170ef, spsr=2093 r0 =002170ef, r1 =f02f2a65, r2 =000d, r3 =00217047 r4 =0813, r5 =0066, r6 =f02f2a65, r7 =f0351190 r8 =f02f2a64, r9 =0005, r10=f02f2a64, r11=f040 r12=f03c, ssp=f04ccc94, slr=f0027288, pc =f02d90d8 Stopped in pid 0.1 (system) at netbsd:strlcpy+0x30:strb r5, [r0], #001 db>bt 0xf038: netbsd:irq_claim+0xc 0xf03cccf0: netbsd:intr_claim+0x58 0xf03ccd28: netbsd:fdcattach+0xc0 Tracking it back it was introduced quite a while back (rev 1.13) of the file which made the section of the file containg the irq description strings read only (but the irq_claim code writes them). The following patch fixes this issue and also corrects another bug that causes the interrupt names to get corrupted in systat. The legacy irq counter code expects all the irq names to be the same length and this patch restores that behaviour. This needs a pullup to 8.0 (which has exactly the same bug). 7.1 is also impacted but I've not actually run the patch there. With this patch applied current and 8.0-BETA actually boot up and work pretty much the same as the previous rather ancient 6.99.40 kernel it was running before and there doesn't appear to be any obvious performance drop with the new code. I've spotted some other issues: 1. Slight misdetect of the NE2000 derived ethernet chip 2. Hangs when attempt is made to reboot. 3. Bad behaviour in ddb. I've run into these before and I've got some rather hacky fixes. Once they are cleaned up I'll send out another message with patches for those as well. Mike Index: sys/arch/arm/iomd/iomd_irq.S === RCS file: /cvsroot/src/sys/arch/arm/iomd/iomd_irq.S,v retrieving revision 1.16 diff -u -r1.16 iomd_irq.S --- sys/arch/arm/iomd/iomd_irq.S2 Dec 2013 18:36:10 - 1.16 +++ sys/arch/arm/iomd/iomd_irq.S4 Mar 2018 17:02:34 - @@ -412,7 +412,7 @@ #ifdef IRQSTATS /* These symbols are used by vmstat */ - .section .rodata + .section .data .global _C_LABEL(_intrnames) _C_LABEL(_intrnames): Index: sys/arch/arm/iomd/iomd_irqhandler.c === RCS file: /cvsroot/src/sys/arch/arm/iomd/iomd_irqhandler.c,v retrieving revision 1.22 diff -u -r1.22 iomd_irqhandler.c --- sys/arch/arm/iomd/iomd_irqhandler.c 25 Oct 2014 10:58:12 - 1.22 +++ sys/arch/arm/iomd/iomd_irqhandler.c 4 Mar 2018 17:02:34 - @@ -180,7 +180,9 @@ /* Get the interrupt name from the head of the list */ char *iptr = _intrnames + (irq * 14); if (handler->ih_name) { - strlcpy(iptr, handler->ih_name, 14); + /* kvm code expects these to be padded to the +* field length (13 chars + \0 in our case) */ + snprintf(iptr, 14, "%-13.13s", handler->ih_name ); } else { snprintf(iptr, 14, "irq %2d ", irq); } @@ -290,7 +292,9 @@ /* Get the interrupt name from the head of the list */ char *iptr = _intrnames + (irq * 14); if (irqhandlers[irq] && irqhandlers[irq]->ih_name) { - strlcpy(iptr, irqhandlers[irq]->ih_name, 14); + /* kvm code expects these to be padded to the +* field length (13 chars + \0 in our case) */ + snprintf(iptr, 14, "%-13.13s", handler->ih_name ); } else { snprintf(iptr, 14, "irq %2d ", irq); }
Re: USB device detection problem
On 25/08/2017 13:51, Nick Hudson wrote: On 06/25/17 11:06, Mike Pumford wrote: Just trying to fire up NetBSD 8-BETA on my builder machine but I've run into a bit of a showstopper (for me) bug in the new kernel. On NetBSD 7-STABLE (Apr 14th) my KVM is detected as: uhub6 at uhub1 port 6: , class 9/0, rev 1.10/1.00, addr 1 uhub6: 4 ports with 4 removable, self powered And then the kernel carries on an finds the keyboard and mouse downstream of that device. In NetBSD 8 I get: uhub6 at uhub1 port 6: vendor 0557 (0x557) product 8021 (0x8021), class 9/0, rev 1.10/1.00, addr 1 uhub6: 4 ports with 4 removable, self powered uhub6: device problem, disabling port 1 This means I have no console keyboard. Anything I can do to help track this down? I've also attached full dmesg from Both 8-BETA and 7.1-STABLE. So, to be clear these builds are from recent netbsd-8 and netbsd-7 trees and therefore both have approximately the same sys/dev/usb code? Just got back from a holiday so I'm still catching up. Yes they were from recent netbsd-8 and netbsd-7. Probably fetched and built just before I sent out the e-mail. If so, I wonder if using msi interrupts is part of the problem? -xhci0 at pci0 dev 20 function 0: vendor 0x8086 product 0x8cb1 (rev. 0x00) -xhci0: interrupting at ioapic0 pin 21 +xhci0 at pci0 dev 20 function 0: vendor 8086 product 8cb1 (rev. 0x00) +xhci0: interrupting at msi2 vec 0 Can you check interrupt counters (vmstat -i) ? I will do that a little bit later on. One oddity is that if I move the keyboard/mouse connection to a USB3 port rather than one of the USB2 only ports it actually works perfectly on 8-BETA. Mike Mike Nick
Re: AMD Ryzen and NetBSD?
On 03/07/2017 05:34, Thor Lancelot Simon wrote: On Sun, Jul 02, 2017 at 10:57:20PM +0100, Patrick Welche wrote: On Fri, Jun 30, 2017 at 12:00:45PM -0400, Thor Lancelot Simon wrote: I shoved a rather newer ST2000DM001-1CH164 in, which according to its marketing bumpf can manage "Max SustainableTransfer Rate 210MB/s" and not so bad: # dd if=/dev/zero ibs=64k | progress -l 976751887b dd of=/dev/rdk15 obs=64 k 99% |** | 465 GiB 116.74 MiB/s00:00 ETAd This is already effectively double buffered, because of the way you used "progress". You could try using a larger blocksize for the reads from /dev/zero (1m perhaps) and also for the writes to rdk15 - the kernel will buffer up and dispatch the MAXPHYS sized I/Os. To get 200MB out of that drive you likely need larger writes, which we currently can't do. It might perform slightly better through the filesystem, though. I have almost the same disk in my NetBSD 8 BETA system: wd0 at atabus0 drive 0 wd0: It can sustain 210MB READING but I doubt it will be as fast writing. Hard drive manufacturers tend to quote read speeds over write speed as they are much faster. Looking at the ST2000DM1 datasheet confirms that. The sustained read speed is indeed 210MB/s with an average data rate (mixed reads and writes of 150MB/s). Based on past experience the write speed you are seeing is about par for the course in any system. The MB used by disk manufacturers is decimal for capacity and I wouldn't be surprised if they used it for transfer rates as well as it would make the drives look faster. Heres the spec I looked at. http://www.seagate.com/staticfiles/docs/pdf/datasheet/disc/barracuda-ds1737-1-us.pdf I can't do a write test at the sector level as its my system disk but doing: # dd if=/dev/rwd0d bs=64k of=/dev/null ^C44897+0 records in 44897+0 records out 2942369792 bytes transferred in 14.094 secs (208767545 bytes/sec) Pretty close to the claimed sustained transfer speed. Did a fileystem level write test at 2 different sizes and got: dd if=/dev/zero of=testme bs=64k ^C18708+0 records in 18707+0 records out 1225981952 bytes transferred in 11.679 secs (104973195 bytes/sec) dd if=/dev/zero of=testme bs=1m ^C^C3828+0 records in 3827+0 records out 4012900352 bytes transferred in 38.780 secs (103478606 bytes/sec) For reference this is on an I i7 system: cpu0: Intel(R) Core(TM) i7-4790K CPU @ 4.00GHz, id 0x306c3 So seems like the Ryzen has comparable IO performance to a 6th generation intel i7 and is being speed limited by the disk. Mike
USB device detection problem
Just trying to fire up NetBSD 8-BETA on my builder machine but I've run into a bit of a showstopper (for me) bug in the new kernel. On NetBSD 7-STABLE (Apr 14th) my KVM is detected as: uhub6 at uhub1 port 6: , class 9/0, rev 1.10/1.00, addr 1 uhub6: 4 ports with 4 removable, self powered And then the kernel carries on an finds the keyboard and mouse downstream of that device. In NetBSD 8 I get: uhub6 at uhub1 port 6: vendor 0557 (0x557) product 8021 (0x8021), class 9/0, rev 1.10/1.00, addr 1 uhub6: 4 ports with 4 removable, self powered uhub6: device problem, disabling port 1 This means I have no console keyboard. Anything I can do to help track this down? I've also attached full dmesg from Both 8-BETA and 7.1-STABLE. Mike Copyright (c) 1996, 1997, 1998, 1999, 2000, 2001, 2002, 2003, 2004, 2005, 2006, 2007, 2008, 2009, 2010, 2011, 2012, 2013, 2014, 2015, 2016, 2017 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 8.0_BETA (GENERIC) #0: Sun Jun 25 01:07:37 BST 2017 buil...@trigati.mudcovered.org.uk:/work/netbsd/8-stable/obj.amd64/sys/arch/amd64/compile/GENERIC total memory = 16259 MB avail memory = 15766 MB cpu_rng: RDRAND timecounter: Timecounters tick every 10.000 msec Kernelized RAIDframe activated running cgd selftest aes-xts-256 aes-xts-512 done timecounter: Timecounter "i8254" frequency 1193182 Hz quality 100 ASUS All Series (System Version) mainbus0 (root) ACPI: RSDP 0x000F04A0 24 (v02 ALASKA) ACPI: XSDT 0xB8DCF080 74 (v01 ALASKA A M I01072009 AMI 00010013) ACPI: FACP 0xB8DE18A8 00010C (v05 ALASKA A M I01072009 AMI 00010013) ACPI: DSDT 0xB8DCF188 01271D (v02 ALASKA A M I0006 INTL 20120711) ACPI: FACS 0xB9312F80 40 ACPI: APIC 0xB8DE19B8 92 (v03 ALASKA A M I01072009 AMI 00010013) ACPI: FPDT 0xB8DE1A50 44 (v01 ALASKA A M I01072009 AMI 00010013) ACPI: SSDT 0xB8DE1A98 000BEE (v01 Ther_R Ther_Rvp 1000 INTL 20120711) ACPI: SSDT 0xB8DE2688 000539 (v01 PmRef Cpu0Ist 3000 INTL 20051117) ACPI: SSDT 0xB8DE2BC8 000B74 (v01 CpuRef CpuSsdt 3000 INTL 20051117) ACPI: MCFG 0xB8DE3740 3C (v01 ALASKA A M I01072009 MSFT 0097) ACPI: HPET 0xB8DE3780 38 (v01 ALASKA A M I01072009 AMI. 0005) ACPI: SSDT 0xB8DE37B8 00036D (v01 SataRe SataTabl 1000 INTL 20120711) ACPI: SSDT 0xB8DE3B28 005B5E (v01 SaSsdt SaSsdt 3000 INTL 20120711) ACPI: Executed 15 blocks of module-level executable AML code ACPI: 6 ACPI AML tables successfully acquired and loaded ioapic0 at mainbus0 apid 8: pa 0xfec0, version 0x20, 24 pins cpu0 at mainbus0 apid 0 cpu0: Intel(R) Core(TM) i7-4790K CPU @ 4.00GHz, id 0x306c3 cpu0: package 0, core 0, smt 0 cpu1 at mainbus0 apid 2 cpu1: Intel(R) Core(TM) i7-4790K CPU @ 4.00GHz, id 0x306c3 cpu1: package 0, core 1, smt 0 cpu2 at mainbus0 apid 4 cpu2: Intel(R) Core(TM) i7-4790K CPU @ 4.00GHz, id 0x306c3 cpu2: package 0, core 2, smt 0 cpu3 at mainbus0 apid 6 cpu3: Intel(R) Core(TM) i7-4790K CPU @ 4.00GHz, id 0x306c3 cpu3: package 0, core 3, smt 0 cpu4 at mainbus0 apid 1 cpu4: Intel(R) Core(TM) i7-4790K CPU @ 4.00GHz, id 0x306c3 cpu4: package 0, core 0, smt 1 cpu5 at mainbus0 apid 3 cpu5: Intel(R) Core(TM) i7-4790K CPU @ 4.00GHz, id 0x306c3 cpu5: package 0, core 1, smt 1 cpu6 at mainbus0 apid 5 cpu6: Intel(R) Core(TM) i7-4790K CPU @ 4.00GHz, id 0x306c3 cpu6: package 0, core 2, smt 1 cpu7 at mainbus0 apid 7 cpu7: Intel(R) Core(TM) i7-4790K CPU @ 4.00GHz, id 0x306c3 cpu7: package 0, core 3, smt 1 acpi0 at mainbus0: Intel ACPICA 20170303 acpi0: X/RSDT: OemId , AslId acpi0: MCFG: segment 0, bus 0-255, address 0xe000 ACPI: Dynamic OEM Table Load: ACPI: SSDT 0xFE843BC2D810 0003D3 (v01 PmRef Cpu0Cst 3001 INTL 20051117) ACPI: Dynamic OEM Table Load: ACPI: SSDT 0xFE811D1C2810 0005AA (v01 PmRef ApIst3000 INTL 20051117) ACPI: Dynamic OEM Table Load: ACPI: SSDT 0xFE811D0675D0 000119 (v01 PmRef ApCst3000 INTL 20051117) acpi0: SCI interrupting at int 9 timecounter: Timecounter "ACPI-Fast" frequency 3579545 Hz quality 1000 hpet0 at acpi0: high precision event timer (mem 0xfed0-0xfed00400) timecounter: Timecounter "hpet0" frequency 14318180 Hz quality 2000 acpiec0 at acpi0 (EC0, PNP0C09): io 0x62,0x66 acpiec1 at acpi0 (H_EC, PNP0C09-1): using acpiec0 acpivga0 at acpi0 (GFX0): ACPI Display Adapter acpiout0 at acpivga0 (DD01, 0x0100): ACPI Display Output Device acpiout1 at acpivga0 (DD02, 0x0002): ACPI Display Output Device acpiout2 at acpivga0 (DD03, 0x0300): ACPI Display Output Device acpiout3 at acpivga0 (DD04, 0x0301): ACPI Display Output Device acpiout4 at acpivga0 (DD05, 0x0302): ACPI Display Output Device acpiout5 at acpivga0 (DD06, 0x0303): ACPI Display Output D
emty ftp://nyftp.netbsd.org/pub/NetBSD-daily/HEAD/201705211800Z/source/sets/
Anybody notice that: ftp://nyftp.netbsd.org/pub/NetBSD-daily/HEAD/201705211800Z/source/sets/*tgz , ftp://nyftp.netbsd.org/pub/NetBSD-daily/netbsd-7-1/201705201210Z/source/sets/*tgz are empty tars? Yours, -Mike -- Kind Regards, I am /s/ Michael L. Riechers Michael L. Riechers, Owner, M L Riechers Systems Engineering 513/844-2220 (voice)530 Main Street 513/205-5589 (cell) Hamilton, Ohio 45013 m...@rse.com (internet) www.rse.com (WEB) Systems Programming: The three most adverse malignancies in life are: 1)signed numbers, 2)floating point numbers, and 3)little endians. "Defend the Spirit of the Enlightenment." Macron, 2017
Re: i386 GENERIC_PAE panics (i915drmkms related?)
On 20/01/2017 18:18, John D. Baker wrote: The intent of booting i386 release on this amd64 machine is to build packages for i386 faster than even my fastest real i386 can. It's faster, has more CPUs and with the extra RAM and PAE, I can put WRKOBJDIR in /tmp on tmpfs for everything except "misc/libreoffice". If that's your primary goal have you considered using pkg_comp. That builds packages in chroot environments and on amd64 can build packages for i386. From one 7.0 amd64 machine I build packages for 6.x/i386, and 7.0/amd64. I did also do 7.0/i386 as well until I switched that machine to 64bit. That might be a better alternative that trying to bludgeon a PAE kernel into life. Mike
System freeze during startup, with fresh current-kernels... (amd64)
Hi folks, I'm not able to boot current kernels(starting from yesterday, and today I also tried-several times). AFAICT it freezes on usb-initialization(I tried disabling usb at all with userconf - it boots... but anyway-I need usb, at least for keyboard, so system booted that way is completely useless for me)) Also I can tell that it doesn't freezes COMPLETELY - if I press power button, system responses to it - "trying" to shutdown - detaching devices etc... but it doesn't powerdown/halt or even reboot at the end of shutting down procedure. Any ideas? (dmesg attached) Copyright (c) 1996, 1997, 1998, 1999, 2000, 2001, 2002, 2003, 2004, 2005, 2006, 2007, 2008, 2009, 2010, 2011, 2012, 2013, 2014, 2015, 2016, 2017 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.59 (ASUS_GA) #1: Tue Jan 17 17:59:11 UTC 2017 tyler@netbox.brkly.local.domain:/usr/SOURCE/src/sys/arch/amd64/compile/ASUS_GA total memory = 3071 MB avail memory = 2959 MB timecounter: Timecounters tick every 10.000 msec running cgd selftest aes-xts-256 aes-xts-512 done timecounter: Timecounter "i8254" frequency 1193182 Hz quality 100 SMBIOS rev. 2.5 @ 0x9f400 (56 entries) System manufacturer System Product Name (System Version) mainbus0 (root) efi: missing or invalid systbl ACPI: RSDP 0x000FB730 14 (v00 ACPIAM) ACPI: RSDT 0xBFFA 44 (v01 072610 RSDT1515 20100726 MSFT 0097) ACPI: FACP 0xBFFA0200 84 (v02 072610 FACP1515 20100726 MSFT 0097) ACPI: DSDT 0xBFFA0460 007377 (v01 A1092 A1092000 INTL 20060113) ACPI: FACS 0xBFFAE000 40 ACPI: APIC 0xBFFA0390 90 (v01 072610 APIC1515 20100726 MSFT 0097) ACPI: MCFG 0xBFFA0420 3C (v01 072610 OEMMCFG 20100726 MSFT 0097) ACPI: OEMB 0xBFFAE040 71 (v01 072610 OEMB1515 20100726 MSFT 0097) ACPI: SRAT 0xBFFA77E0 A0 (v03 AMDFAM_F_10 0002 AMD 0001) ACPI: HPET 0xBFFA7880 38 (v01 072610 OEMHPET0 20100726 MSFT 0097) ACPI: NVHD 0xBFFAE0C0 000554 (v01 072610 NVHDCP 20100726 MSFT 0097) ACPI: SSDT 0xBFFA78C0 000248 (v01 A M I POWERNOW 0001 AMD 0001) ACPI: Executed 1 blocks of module-level executable AML code ACPI: 2 ACPI AML tables successfully acquired and loaded efi: missing or invalid systbl ioapic0 at mainbus0 apid 2: pa 0xfec0, version 0x11, 24 pins cpu0 at mainbus0 apid 0 cpu0: 8 page colors cpu0: calibrating local timer cpu0: apic clock running at 200 MHz cpu0: AMD Athlon(tm) 64 X2 Dual Core Processor 4400+, id 0x60fb1 cpu0: PAT enabled cpu1 at mainbus0 apid 1 cpu1: 2 page colors x86_ipi_init: ESR 0004 cpu1: AMD Athlon(tm) 64 X2 Dual Core Processor 4400+, id 0x60fb1 cpu1: PAT enabled acpi0 at mainbus0: Intel ACPICA 20160930 efi: missing or invalid systbl acpi0: X/RSDT: OemId <072610,RSDT1515,20100726>, AslId acpi0: MCFG: segment 0, bus 0-255, address 0xe000 MCFG: MEMMAP: 0x-0x0009efff, size=0x0009f000, type=1(Memory) MCFG: MEMMAP: 0x0009f000-0x0009, size=0x1000, type=2(Reserved) MCFG: MEMMAP: 0x000e2000-0x000f, size=0x0001e000, type=2(Reserved) MCFG: MEMMAP: 0x0010-0xbff9, size=0xbfea, type=1(Memory) MCFG: MEMMAP: 0xbffa-0xbffadfff, size=0xe000, type=3(ACPI) MCFG: MEMMAP: 0xbffae000-0xbffd, size=0x00032000, type=4(NVS) MCFG: MEMMAP: 0xbffe-0xbffedfff, size=0xe000, type=2(Reserved) MCFG: MEMMAP: 0xbfff-0xbfff, size=0x0001, type=2(Reserved) MCFG: MEMMAP: 0xfec0-0xfec00fff, size=0x1000, type=2(Reserved) MCFG: MEMMAP: 0xfee0-0xfeef, size=0x0010, type=2(Reserved) MCFG: MEMMAP: 0xfff0-0x, size=0x0010, type=2(Reserved) MCFG: bus 0-255, address 0xe000: no valid region acpi0: MCFG: PNP0C01: Type=10(FIXED_MEMORY32), Address=0x, Length=0x000a acpi0: MCFG: PNP0C01: Type=10(FIXED_MEMORY32), Address=0x000c, Length=0x0001 acpi0: MCFG: PNP0C01: Type=10(FIXED_MEMORY32), Address=0x000e, Length=0x0002 acpi0: MCFG: PNP0C01: Type=10(FIXED_MEMORY32), Address=0x0010, Length=0xbff0 acpi0: MCFG: PNP0C01: Type=10(FIXED_MEMORY32), Address=0xfec0, Length=0x0140 acpi0: MCFG: PNP0C01: Type=7 acpi0: MCFG: PNP0C01: bus 0-255, address 0xe000: no valid region acpi0: MCFG: PNP0C02: Type=12 acpi0: MCFG: PNP0C02: Type=12 acpi0: MCFG: PNP0C02: Type=12 acpi0: MCFG: PNP0C02: Type=4 acpi0: MCFG: PNP0C02: Type=4 acpi0: MCFG: PNP0C02: Type=4 acpi0: MCFG: PNP0C02: Type=4 acpi0: M
Re: USB serial problems
On Fri, Sep 30, 2016 at 09:45:04AM +0200, Tom Ivar Helbekkmo wrote: > Greg Troxel writes: > > > Did you try on a netbsd-7 system? > > The problem is newer than that. I was using my Telldus Tellstick on a > sporadically upgraded NetBSD/i386-current system for a couple of years. > Then, when I went from 7.99.7 to 7.99.36, it broke, in exactly the way > Thomas describes. I figured I'd just move it to NetBSD/amd64 7.99.36, > but, unfortunately, it behaves just the same way there. > > I've just built a fresh 7.99.39, and hope to test it later today. > > -tih > -- > Elections cannot be allowed to change anything. --Dr. Wolfgang Schäuble Hi guys. I started having the same problems, I think, just a few days ago. amd64 / 7.99.39 / and kernel about 3 days old(~30.09) - with that: (dmesg) ehci0 at pci0 dev 29 function 7: vendor 8086 product 265c (rev. 0x03) ehci0: interrupting at ioapic0 pin 23 ehci0: EHCI version 1.0 ehci0: companion controllers, 2 ports each: uhci0 uhci1 uhci2 uhci3 usb4 at ehci0: USB revision 2.0 ... uhub2 at usb4: vendor 8086 EHCI root hub, class 9/0, rev 2.00/1.00, addr 1 uhub2: 8 ports with 8 removable, self powered ... umass0 at uhub2 port 6 configuration 1 interface 0 ... ehci0: handing over low speed device on port 7 to uhci3 ehci0: handing over low speed device on port 8 to uhci3 ... u3ginit0 at uhub2 port 4: Switching to 3G mode u3ginit0: detached u3ginit0: at uhub2 port 4 (addr 3) disconnected u3g0 at uhub2 port 4 configuration 1 interface 0 ucom0 at u3g0 portno 0: 3G Modem u3g1 at uhub2 port 4 configuration 1 interface 1 ucom1 at u3g1 portno 0: 3G Modem u3g2 at uhub2 port 4 configuration 1 interface 2 ucom2 at u3g2 portno 0: 3G Modem u3g3 at uhub2 port 4 configuration 1 interface 3 ucom3 at u3g3 portno 0: 3G Modem umass1 at uhub2 port 4 configuration 1 interface 4 umass1: HUAWEI Technology HUAWEI Mobile, rev 2.00/0.00, addr 3 umass1: using SCSI over Bulk-Only scsibus1 at umass1: 2 targets, 1 lun per target umass2 at uhub2 port 4 configuration 1 interface 5 umass2: HUAWEI Technology HUAWEI Mobile, rev 2.00/0.00, addr 3 umass2: using SCSI over Bulk-Only scsibus2 at umass2: 2 targets, 1 lun per target cd1 at scsibus1 target 0 lun 0: cdrom removable sd1 at scsibus2 target 0 lun 0: disk removable sd1: drive offline However, today's fresh kernel seems to be more stable... (didn't have any troubles yet with it). Now I'm rebuilding system and will see how it behaves in some of these days... (Also I'd like to switch to new xorg, and play a little with it... but sure it will work well with my "new" videocard!)))
Re: xorg-server 1.18 ready for testing on x86 and shark
On Sun, Aug 21, 2016 at 05:46:01PM +0100, Dave Tyson wrote: > cvs updated current src,xsrc earlier today and just had a try at building > this > with a clean obj directory and it blows up being unable to make libglamor.a > > ===> build.sh command:./build.sh -V HAVE_XORG_SERVER_VER=118 -u -U -x -T > /usr/tools -O /usr/obj -j 2 release > ===> build.sh started:Sun Aug 21 12:01:37 BST 2016 > ===> NetBSD version: 7.99.36 > ===> MACHINE: amd64 > ===> MACHINE_ARCH:x86_64 > ===> Build platform: NetBSD 7.99.36 amd64 > ===> HOST_SH: /bin/sh > ===> MAKECONF file: /etc/mk.conf > #objdir /usr/obj/tools > ===> TOOLDIR path:/usr/tools > ===> DESTDIR path:/usr/obj/destdir.amd64 > ===> RELEASEDIR path: /usr/obj/releasedir > ===> Updated makewrapper: /usr/tools/bin/nbmake-amd64 > --- release --- > distribution ===> . > --- distribution --- > build ===> .(with: NOPOSTINSTALL=1) > --- build --- > Build started at: Sun Aug 21 12:01:38 BST 2016 > ... > ... > ... > #create Xorg/dummy.d > CC=/usr/tools/bin/x86_64--netbsd-gcc /usr/tools/bin/nbmkdep -f dummy.d.tmp > -- > -std=gnu99--sysroot=/usr/obj/destdir.amd64 -I/usr/xsrc/external/mit/xorg- > server/dist/include > -I/usr/xsrc/external/mit/xorg-server/dist/Xext - > I/usr/obj/destdir.amd64/usr/X11R7/include/pixman-1 - > I/usr/xsrc/external/mit/xorg-server/dist/../include -I/usr/obj/destdir.amd64/ > usr/X11R7/include/X11 -I/usr/xsrc/external/mit/xorg-server/dist/fb - > I/usr/xsrc/external/mit/xorg-server/dist/mi -I/usr/xsrc/external/mit/xorg- > server/dist/include -I/usr/xsrc/e > xternal/mit/xorg-server/dist/os -I/usr/xsrc/external/mit/xorg- > server/dist/Xext -I/usr/obj/destdir.amd64/usr/X11R7/include/X11/extensions - > I/usr/obj/destdir.amd64/usr/X11R7/incl > ude/libdrm -I/usr/obj/destdir.amd64/usr/X11R7/include/pixman-1 - > I/usr/obj/destdir.amd64/usr/X11R7/include/xorg -I/usr/xsrc/external/mit/xorg- > server/dist/render -DHAVE_DIX_CONF > IG_H -DDDXOSINIT -DSERVER_LOCK -DDDXOSFATALERROR -DDDXOSVERRORF -DDDXTIME - > DUSB_HID -DHAVE_DIX_CONFIG_H -D_BSD_SOURCE -DHAS_FCHOWN -DHAS_STICKY_DIR_BIT > -D_POSIX_THREAD_SAFE_FUNC > TIONS -DHAVE_XORG_CONFIG_H -DMITMISC -DXTEST -DXTRAP -DXSYNC -DXCMISC - > DXRECORD -DMITSHM -DBIGREQS -DXF86VIDMODE -DXF86MISC -DDPMSExtension -DEVI - > DSCREENSAVER -DXV -DXVMC -D > GLXEXT -DRES -DSHAPE -DXINPUT -DXKB -DLBX -DXAPPGROUP -DXCSECURITY > -DTOGCUP > -DXF86BIGFONT -DDPMSExtension -DPIXPRIV -DPANORAMIX -DRENDER -DRANDR - > DXFIXES -DDAMAGE -DCOMPOSIT > E -DXEVIE -DGLXEXT -DXF86DRI -DGLX_DIRECT_RENDERING -DGLX_USE_DLOPEN - > DGLX_USE_MESA -DXF86VIDMODE -D__GLX_ALIGN64 -DCSRG_BASED -DFUNCPROTO=15 - > DNARROWPROTO -I/usr/obj/destdir.am > d64/usr/X11R7/include -D__AMD64__ dummy.c && mv dummy.d.tmp dummy.d > --- .depend --- > #create Xorg/.depend > rm -f .depend > CC=/usr/tools/bin/x86_64--netbsd-gcc /usr/tools/bin/nbmkdep -s .o\ .ln\ .d -d > -f .depend dummy.d > --- dependall --- > --- .gdbinit --- > rm -f .gdbinit > echo "set solib-absolute-prefix /usr/obj/destdir.amd64" > .gdbinit > nbmake[13]: nbmake[13]: don't know how to make > /usr/obj/external/mit/xorg/server/xorg-server/glamor/libglamor.a. Stop > nbmake[13]: stopped in /usr/src/external/mit/xorg/server/xorg- > server/hw/xfree86/Xorg > *** [dependall] Error code 2 > nbmake[12]: stopped in /usr/src/external/mit/xorg/server/xorg- > server/hw/xfree86/Xorg > 1 error > nbmake[12]: stopped in /usr/src/external/mit/xorg/server/xorg- > server/hw/xfree86/Xorg > *** [dependall-Xorg] Error code 2 > ... > > Dave > > -- > > Phone: 07805784357 > Open Source O/S: www.netbsd.org > Caving: http://www.wirralcavinggroup.org.uk > I had the exactly same error... (and as work-around I specified HAVE_XORG_GLAMOR=no in MAKECONF-after that all compiled fine). BTW, I tried new native xorg (I also tried modular-xorg from pkgsrc, 1.18.4)... Unfortunately it turned out to be unsuitable for me at this moment... The reason is simple: Videocard which I am now use (it's Geforce6, nv44 based video) is not supported by kernel-nouveau driver... (I think it should be supported, but in fact it does not work. So I use generic genfb with nv driver in old-xorg. This combination works well for me). And the new xorg with nv driver doesn't seem to support some kind of acceleration - so video works unbeleivebly slow...(Besides that xv extension doesn't work. Though it may be supported, and I just can't figure out how to make it work).
Re: Ext2 issues in current
Thanks. I'll try. On Sat, Aug 20, 2016 at 08:38:11AM +0700, Robert Elz wrote: > > gin...@email.su said: > | General info: Host system-amd64 (yesterday's "clean" -current build) > > Try again with a more recent current. ext2fs has been broken since it > started to get some GSoC code incorporated in it (yes, I think about 2 > weeks ago) for ext4 filesystem support I beliebe - many ext2fs tests > have been failing. > > There have been people working on it however, and the tests now seem > to all work (as of a few hours ago). > > I don't have any ext2fs filesystems, and I haven't been doing any of the > work, but I have been monitoring the status of the system tests recently. > That is, I can't confirm that it is fixed now, but it might well be. > > kre >
Ext2 issues in current
Hi Folks. It seems to me that last changes in completly broke NetBSD's write support on it (in expected way, as it used to work for a very long time before). I started having troubles about 2 weeks ago. At that time, I was hoping that this is just a temporary issue in -current, and probably will be fixed soon...But now I'm not so sure, since the problem is still there. General info: Host system-amd64 (yesterday's "clean" -current build) So, basicaly I have the following picture today: 1). A few partitions with ext2 filesystem. (Used to provide some interoperability with other OS's, although I'm using only netbsd, ~90% of time...and this partitions are also being used as read-only, most of the time. But sometimes I'd like to have write support as well!. I created them(mostly), using only netbsd native tools. (It still did not work very smoothly, but worked quite acceptably for a while). -features list : resize_inode filetype sparse_super large_file. -fs revision : 1. Of course, since I want to be able to put(sometimes) large files there... 2). Latest netbsd-current system 3). In Read-Only mode it works normally 4). Write support is still present... But works totally weird... (_absolutely_ sure that It is just _new_, _netbsd_ , trouble - not hardware or anything else). In the attached text file, I wrote typical shell session, demonstrating it's "work" in the rw mode(not the worst case, cause with latest changes it looks more like loterea- you never know what exactly you'll get, trying to use ext2fs rw. Most common result is total freezed system with need to hard-reset..-> -> fsck and finally -> some pieces of data, more or less, written on disk. when using kernel-level driver, I mean. If using rump, tipically it will crash quckly...resulting -dirty filesystem. Esplecially, when writing big amounts of data and/or under high disk IO load, etc) Just wondering - Is that a known behavior? mike@somewhere (/mnt)% ls -la drwxr-xr-x 16 root wheel 512 Aug 19 06:51 . drwxr-xr-x 23 root wheel 512 Aug 19 13:08 .. drwxr-xr-x 2 root wheel 512 Jul 19 21:00 MEDIA -rw-r--r-- 1 root wheel 1016698880 Aug 13 23:59 netbsdi386.tar mike@somewhere (/mnt)% file -s /dev/wd1j /dev/wd1j: Linux rev 1.0 ext2 filesystem data, UUID=575163fb-3aac-b04a-a4fa-af88e3f2d615, volume name "media" (large files) mike@somewhere (/mnt)% sudo mount -t ext2fs -o noatime,rw /dev/wd1j MEDIA mike@somewhere (/mnt)% df -h MEDIA Filesystem Size Used Avail %Cap Mounted on /dev/wd1j 24G 13G 9.6G 57% /mnt/MEDIA mike@somewhere (/mnt)% cd MEDIA/mike mike@somewhere (/mnt/MEDIA/mike)% ls -la total 8 drwxr-xr-x 2 mike wheel 4096 Aug 19 15:26 . drwxr-xr-x 24 mike wheel 4096 Aug 19 15:26 .. mike@somewhere (/mnt/MEDIA/mike)% tar -tvf ../../netbsdi386.tar drwxr-xr-x 2 mikewsrc 0 Jan 1 2016 NetBSD-i386 drwxr-xr-x 2 mikewsrc 0 Dec 21 2015 NetBSD-i386/CURRENT -rw-r--r-- 1 mike wsrc45791024 Dec 21 2015 NetBSD-i386/CURRENT/base.tgz -rw-r--r-- 1 mike wsrc71293268 Dec 21 2015 NetBSD-i386/CURRENT/comp.tgz -rw-r--r-- 1 mike wsrc 584458 Dec 21 2015 NetBSD-i386/CURRENT/etc.tgz -rw-r--r-- 1 mikewsrc 3217114 Dec 21 2015 NetBSD-i386/CURRENT/games.tgz -rw-r--r-- 1 mike wsrc 163531 Dec 21 2015 NetBSD-i386/CURRENT/INSTALL.HTML -rw-r--r-- 1 mike wsrc10943912 Dec 21 2015 NetBSD-i386/CURRENT/man.tgz -rw-r--r-- 1 mike wsrc 5247129 Dec 21 2015 NetBSD-i386/CURRENT/misc.tgz -rw-r--r-- 1 mikewsrc 8291700 Dec 21 2015 NetBSD-i386/CURRENT/modulesi386.tgz -rw-r--r-- 1 mikewsrc 18169481 Dec 21 2015 NetBSD-i386/CURRENT/netbsd-GENERIC drwxr-xr-x 2 mike wsrc 0 Dec 21 2015 NetBSD-i386/CURRENT/sources -rw-r--r-- 1 mikewsrc 394386844 Dec 21 2015 NetBSD-i386/CURRENT/sources/src.tar.gz -rw-r--r-- 1 mikewsrc 62 Dec 21 2015 NetBSD-i386/CURRENT/sources/src.tar.gz.MD5 -rw-r--r-- 1 mikewsrc 121243902 Dec 21 2015 NetBSD-i386/CURRENT/sources/xsrc.tar.gz -rw-r--r-- 1 mikewsrc 63 Dec 21 2015 NetBSD-i386/CURRENT/sources/xsrc.tar.gz.MD5 -rw-r--r-- 1 mikewsrc 6682693 Dec 21 2015 NetBSD-i386/CURRENT/tests.tgz -rw-r--r-- 1 mike wsrc 2763307 Dec 21 2015 NetBSD-i386/CURRENT/text.tgz -rw-r--r-- 1 mikewsrc 7463654 Dec 21 2015 NetBSD-i386/CURRENT/xbase.tgz -rw-r--r-- 1 mikewsrc12835820 Dec 21 2015 NetBSD-i386/CURRENT/xcomp.tgz -rw-r--r-- 1 mike wsrc 25132 Dec 21 2015 NetBSD-i386/CURRENT/xetc.tgz -rw-r--r-- 1 mikewsrc32787195 Dec 21 2015 NetBSD-i386/CURRENT/xfont.tgz -rw-r--r-- 1 mike wsrc12593931 Dec 21 2015 NetBSD-i386/CURRENT/xserver.tgz drwxr-xr-x 2 mikewsrc 0 Dec 21 2015 NetBSD-i386/STABLE-sets -rw-r--r--
Re: bind -> unbound/nsd
On Thu, Aug 18, 2016 at 02:53:38PM -0600, Swift Griggs wrote: > On Thu, 18 Aug 2016, Greg Troxel wrote: > > Is it about security track record? > > I'm not wanting to get into the discussion of fiat versus consensus > decision making. However, I'd like to give my own personal answer on some > of the questions you raise, as a heavy DNS user/sysadmin. > > Bind's security track record has been somewhere between "horrible" and > "really bad" depending on the version. > > http://www.cvedetails.com/product/144/ISC-Bind.html?vendor_id=64 > > Bind 9 was released in 2000, IIRC. So, that is mostly just for the 9.x > code stream. Lots of folks still preferred the 4.x code base since 9.x > added so much that it became a huge mess. 4.x had terrible security, but > exhibited less inertia for getting started and maintaining the zones. So, > Bind 4.x was maintained for quite a while. > > The trend is also not in decline. Note that in 2016 there were eight > vulnerabilities and that's the largest number since 2002. However, to be > fair, Bind has also had the maximum amount of beatings from every > high-profile hacking team you can imagine. Perhaps if competing projects > had the same amount of scrutiny they wouldn't fair well, either. > > > Is unbound/nsd feature complete relative to everything that can be done > > with bind? > > Not even close if you consider the whole list. Unbound can only function > as a recursive resolver. It has *no* ability to serve PTR and A records > directly. It does, however, have some DNSSEC functionality. > > > Specifically, serving authoritative zones, DNSSEC, dynamic updates, and > > (for others) split dns? > > It does not do split horizon because it can't be authoritative (same for > dynamic DNS). > > YADIFA, MaraDNS, Knot DNS, or Djbdns would all be better choices than > Unbound if you want a "real" server. The idea behind Unbound is to provide > a secure and fast client resolver. Here's how the other's would break down > in a nutshell: > > YADIFA > Pros: BSD licensed. Fast. Full featured > Cons: Newer. Not even in pkgsrc yet. No recursion. No split horizon > > MaraDNS: > Pros: Good security record, stable, most features available > Cons: Zany "Mara-DNS" license and weird layout / config > > Knot DNS: > Pros: Very full featured. Fast. Awesome YAML config setup > Cons: GPL'd, won't act as a recursive resolver > > Djbdns: > Pros: Very secure. Fast. Public domain (no license) > Cons: Missing features, spotty maintenance > > > Please note that I'm not objecting; I'm just asking for the rationale to > > be articulated. > > In my mind the rationalization would be that most folks would probably > have a secure resolver than a full-featured (potential) authoritative > server. My guess is that a recursive server is what most folks want. The > trade-off is essentially that you lose a bunch of features, but you also > create a much smaller attack surface and gain Unbound's (slightly) more > clear syntax. Totally agree. Not only this, but in general... Bind I think is really horrible in terms of security - have only this, I see no reason to keep it in the base system nowadays. And also because there is a decent alternatives.(besides, I'm also think that most users don't need more than unbound). Bind configuration in my point of view(I really did not mean to offend anyone of it's developers) is a nightmare, unfortunately, too. Except unbound, at least djbdns looks like a good choise. > > If authoritative DNS is seen as indispensable for distribution in NetBSD, > it might be expedient to track YADIFA (since it's got a compatible > license). However, the trouble it's about 8 years behind Bind's feature > set. > > -Swift > > > PS: It's sad that ISC decided to move to the MPL but I don't blame them > much. It sucks to work on something for years that's "insanely popular" > but nobody will contribute to or support. I'm sure folks know the feeling. > I've read similar complaints from the OpenSSH team. I don't blame them a > bit. Our 19[90|80]'s ideas about software freedom have been put to the > test, and I'm not sure they've come out unblemished by the big-B-Billions > of Internet ab^H^Husers. >
Re: Modular ppp
Just tested the new ppp module... And it seems to work fine. In the first "scerario" I didn't see any difference with applied attached diffs... (no problems, no matter with or without patch) 2'nd scenario with loadable module: I compiled kernel without ppp, then loaded this ppp module... and also-there is no problems(at least in my case). If I can provide any usefull details - feel free to let me know.:) On Fri, Aug 05, 2016 at 10:18:25PM +, Mike wrote: > Yes, I am ready to test it today! I think I will be able to wrote about > the results tommorrow... But I have a question about module - I hope, it > doesn't require to build all modules to test this one? (If it requires - > it's not that bad, anyway...) > > On Fri, Aug 05, 2016 at 05:17:48PM +0800, Paul Goyette wrote: > > Folks, > > > > I've been working on turning the current ppp code (enabled with OPTIONS PPP > > in your config file) into a loadable module, and I'd like to find a few > > folks to help test. > > > > I'd really like testing for two scenarios: > > > > * built-in module (same as current kernels), just using the > > attached diffs; this will verify that I haven't broken any > > current functionality > > > > * loadable module - this will require building a custom kernel > > with the 'OPTIONS PPP' removed, and an install of the new > > kernel _plus_ the new loadable image > > > > /stand/$ARCH/7.99.xx/modules/ppp/ppp.kmod > > > > You'll need to 'modload ppp' before trying to use it. > > > > (I fully expect that this second scenario will fail in some > > obscure manner; I'd hope to get a complete traceback and/or > > detailed description of what you were doing when it failed.) > > > > > > There are three files attached. The first two need to be placed in a new > > $SRCDIR/sys/modules/ppp directory, while the third file is just a set of > > diffs that need to be applied. > > > > Any volunteers? > > > > > > > > +--+--++ > > | 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 | > > +--+--++ > > > # $NetBSD: cgd.ioconf,v 1.1 2015/08/20 11:05:00 christos Exp $ > > > > ioconf ppp > > > > include "conf/files" > > > > pseudo-device ppp > > > # $NetBSD$ > > > > .include "../Makefile.inc" > > > > .PATH: ${S}/net > > > > KMOD= ppp > > IOCONF= ppp.ioconf > > SRCS= if_ppp.c ppp_tty.c > > > > CPPFLAGS+= -DINET > > CPPFLAGS+= -DPPP_FILTER > > CPPFLAGS+= -DPPP_DEFLATE > > CPPFLAGS+= -DPPP_BSDCOMP > > > > .include > > > Index: distrib/sets/lists/modules/mi > > === > > RCS file: /cvsroot/src/distrib/sets/lists/modules/mi,v > > retrieving revision 1.87 > > diff -u -p -r1.87 mi > > --- distrib/sets/lists/modules/mi 4 Aug 2016 23:54:45 - 1.87 > > +++ distrib/sets/lists/modules/mi 5 Aug 2016 08:35:12 - > > @@ -198,6 +198,8 @@ > > ./@MODULEDIR@/pf/pf.kmod base-kernel-modules kmod > > ./@MODULEDIR@/portal base-obsolete > > obsolete > > ./@MODULEDIR@/portal/portal.kmod base-obsolete obsolete > > +./@MODULEDIR@/ppp base-kernel-modules kmod > > +./@MODULEDIR@/ppp/ppp.kmod base-kernel-modules kmod > > ./@MODULEDIR@/ppp_bsdcomp base-kernel-modules kmod > > ./@MODULEDIR@/ppp_bsdcomp/ppp_bsdcomp.kmod base-kernel-modules kmod > > ./@MODULEDIR@/ppp_deflate base-kernel-modules kmod > > Index: sys/modules/Makefile > > === > > RCS file: /cvsroot/src/sys/modules/Makefile,v > > retrieving revision 1.168 > > diff -u -p -r1.168 Makefile > > --- sys/modules/Makefile4 Aug 2016 23:53:47 - 1.168 > > +++ sys/modules/Makefile5 Aug 2016 08:49:06 - > > @@ -79,6 +79,7 @@ SUBDIR+= opencrypto > > SUBDIR+= overlay > > SUBDIR+=
Re: Modular ppp
Yes, I am ready to test it today! I think I will be able to wrote about the results tommorrow... But I have a question about module - I hope, it doesn't require to build all modules to test this one? (If it requires - it's not that bad, anyway...) On Fri, Aug 05, 2016 at 05:17:48PM +0800, Paul Goyette wrote: > Folks, > > I've been working on turning the current ppp code (enabled with OPTIONS PPP > in your config file) into a loadable module, and I'd like to find a few > folks to help test. > > I'd really like testing for two scenarios: > > * built-in module (same as current kernels), just using the > attached diffs; this will verify that I haven't broken any > current functionality > > * loadable module - this will require building a custom kernel > with the 'OPTIONS PPP' removed, and an install of the new > kernel _plus_ the new loadable image > > /stand/$ARCH/7.99.xx/modules/ppp/ppp.kmod > > You'll need to 'modload ppp' before trying to use it. > > (I fully expect that this second scenario will fail in some > obscure manner; I'd hope to get a complete traceback and/or > detailed description of what you were doing when it failed.) > > > There are three files attached. The first two need to be placed in a new > $SRCDIR/sys/modules/ppp directory, while the third file is just a set of > diffs that need to be applied. > > Any volunteers? > > > > +--+--++ > | 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 | > +--+--++ > # $NetBSD: cgd.ioconf,v 1.1 2015/08/20 11:05:00 christos Exp $ > > ioconfppp > > include "conf/files" > > pseudo-device ppp > # $NetBSD$ > > .include "../Makefile.inc" > > .PATH: ${S}/net > > KMOD= ppp > IOCONF= ppp.ioconf > SRCS= if_ppp.c ppp_tty.c > > CPPFLAGS+=-DINET > CPPFLAGS+=-DPPP_FILTER > CPPFLAGS+=-DPPP_DEFLATE > CPPFLAGS+=-DPPP_BSDCOMP > > .include > Index: distrib/sets/lists/modules/mi > === > RCS file: /cvsroot/src/distrib/sets/lists/modules/mi,v > retrieving revision 1.87 > diff -u -p -r1.87 mi > --- distrib/sets/lists/modules/mi 4 Aug 2016 23:54:45 - 1.87 > +++ distrib/sets/lists/modules/mi 5 Aug 2016 08:35:12 - > @@ -198,6 +198,8 @@ > ./@MODULEDIR@/pf/pf.kmod base-kernel-modules kmod > ./@MODULEDIR@/portal base-obsolete obsolete > ./@MODULEDIR@/portal/portal.kmod base-obsolete obsolete > +./@MODULEDIR@/pppbase-kernel-modules kmod > +./@MODULEDIR@/ppp/ppp.kmod base-kernel-modules kmod > ./@MODULEDIR@/ppp_bsdcompbase-kernel-modules kmod > ./@MODULEDIR@/ppp_bsdcomp/ppp_bsdcomp.kmod base-kernel-modules kmod > ./@MODULEDIR@/ppp_deflatebase-kernel-modules kmod > Index: sys/modules/Makefile > === > RCS file: /cvsroot/src/sys/modules/Makefile,v > retrieving revision 1.168 > diff -u -p -r1.168 Makefile > --- sys/modules/Makefile 4 Aug 2016 23:53:47 - 1.168 > +++ sys/modules/Makefile 5 Aug 2016 08:49:06 - > @@ -79,6 +79,7 @@ SUBDIR+=opencrypto > SUBDIR+= overlay > SUBDIR+= pciverbose > SUBDIR+= pf > +SUBDIR+= ppp > SUBDIR+= ppp_bsdcomp > SUBDIR+= ppp_deflate > SUBDIR+= procfs > Index: sys/net/bsd-comp.c > === > RCS file: /cvsroot/src/sys/net/bsd-comp.c,v > retrieving revision 1.20 > diff -u -p -r1.20 bsd-comp.c > --- sys/net/bsd-comp.c29 Nov 2008 23:15:20 - 1.20 > +++ sys/net/bsd-comp.c5 Aug 2016 08:56:54 - > @@ -1090,7 +1090,7 @@ bsd_decompress(void *state, struct mbuf > #endif /* DEBUG */ > } > > -MODULE(MODULE_CLASS_MISC, ppp_bsdcomp, NULL); > +MODULE(MODULE_CLASS_MISC, ppp_bsdcomp, "ppp"); > > static int > ppp_bsdcomp_modcmd(modcmd_t cmd, void *arg) > Index: sys/net/if_ppp.c > === > RCS file: /cvsroot/src/sys/net/if_ppp.c,v > retrieving revision 1.152 > diff -u -p -r1.152 if_ppp.c > --- sys/net/if_ppp.c 10 Jun 2016 13:27:16 - 1.152 > +++ sys/net/if_ppp.c 5 Aug 2016 08:56:54 - > @@ -104,9 +104,8 @@ > #include > __KERNEL_RCSID(0, "$NetBSD: if_ppp.c,v 1.152 2016/06/10 13:27:16 ozaki-r Exp > $"); > > -#include "ppp.h" > - > #ifdef _KERNEL_OPT > +#include "ppp.h" > #include "opt_inet.h" > #include "opt_gateway.h" >
amd64 system build fails all the time with MAKEVERBOSE=4 in mk.conf...
Hi list. I've found the strange behavior of current source tree(sources updated via CVS every 2-3 days, for... ~about 1 last month, but I can't say exactly when I start getting this error... At least 2 last weeks I'm getting it, over and over...). build.sh build tools kernel... all 3 ended OK(sometimes))... but building release/distribution/sets/etc... fails with strange reason...(small piece of output is at the end of message)) I've tried: 'make cleandir, sh build.sh cleandir, nuking tools,obj,destdir... changing many variables in environment( and in mk.conf too), changing /bin/sh to /bin/ksh.. Upgrading to latest binary snapshots, removing all local source tree+ downloading current src/xsrc tarballs(+unpacking it again on the clean partition... with full system rebuild of course))) So... Finally I've found this error appears only when compiling with 'MAKEVERBOSE=4 variable specified in mk.conf'... NOTE: I've tried only with makeverbose 4 and without it at all(I think it should be = 2 by default)... Without it - everything OK. With it.. everything builds ok, until trying to "make sets" Maybe I'm doing something wrong? Here's the output(almost same with base.tgz and other sets...but I could send full log if needed): echo ARCH64=yes + echo COMPATARCHDIRS=i386 + /mnt/OBJECT/amd/tools/bin/nbsed -es/ /,/g + /mnt/OBJECT/amd/tools/bin/nbsed -es/ /,/g + echo KMODARCHDIRS=amd64-xen + echo MKSOLARIS=yes + echo x86_64 /mnt/OBJECT/amd/tools/bin/nbawk: non-terminated string echo x86_6... at source line 70 context is wanted["machine_cpu=" "echo x86_64 >>> <<< DEBUG: list_set_files: ./lists/comp/mi DEBUG: list_set_files: ./lists/comp/md.amd64 DEBUG: list_set_files: ./lists/comp/stl.mi DEBUG: list_set_files: ./lists/comp/shl.mi xargs: /mnt/OBJECT/amd/tools/bin/nbsed terminated by SIGPIPE makeflist output is empty for comp + rm -f /mnt/OBJECT/amd/release/amd64/binary/sets/comp.tgz + false + exit 1 *** [do-comp] Error code 1 nbmake[1]: stopped in /usr/SOURCE/src/distrib/sets 2 errors nbmake[1]: stopped in /usr/SOURCE/src/distrib/sets + exit 2 *** [sets] Error code 2 nbmake: stopped in /usr/SOURCE/src nbmake: stopped in /usr/SOURCE/src p.s. thanks for last improvements in msdosfs tools/driver, I'm about unicode support - It Works perfect for me!)
Re: pipe read returning EAGAIN
Christos Zoulas wrote: In article <20160208104744.ga11...@asim.lip6.fr>, Manuel Bouyer wrote: There is a call to pool. What happens is that it gets a POLLIN event for both fd 3 (which really has data to read) and fd 4 (wich doesn't). The read callback for fd 4 expects to be called only when there's really data to be read, and if read returns EAGAIN it loops until it gets data. poll is called with a set of descriptors, and returns that there is 1 descriptor ready to be read. But the POLLIN flag is set for both descriptors 3 and 4. Now the question is why is the POLLIN flag set when there's no data to read ? zeroing out revents before callin poll(2) doens't help. The man page says: This implementation differs from the historical one in that a given file descriptor may not cause poll() to return with an error. In cases where this would have happened in the historical implementation (e.g. trying to poll a revoke(2)d descriptor), this implementation instead copies the events bitmask to the revents bitmask. Attempting to perform I/O on this descriptor will then return an error. This behaviour is believed to be more useful. Does it do so if the file descriptor's error is EAGAIN ? If so that's no very usefull ... I don't think it does. If the file descriptor is revoked I believe it returns EIO. The question is that if the read code sees an error (EAGAIN), why does it retry? Is it because it expects to get a "full message" and it does not? Does it get any bytes? I think in the case of nagios yes it does (incorrectly). I ran into this a while back and its fixed in the nagios head so I was waiting for the package to update before I checked again. Mike
Re: improving locale support
26.11.2015, 16:00, "Thomas Klausner" : > Illumos, FreeBSD, and DragonFlyBSD recently cooperated to make their > locale support better. > > Here's the FreeBSD commit: > > https://lists.freebsd.org/pipermail/svn-src-head/2015-November/078554.html > > Here's a blog post by the FreeBSD committer, bapt, about the changes: > > http://blog.etoilebsd.net/post/This_is_how_I_like_opensource > > I'd be happy if someone could take a look at and integrate it into > NetBSD too, if useful :) > > Thanks, > Thomas Hey...Can Anyone help me on the following question: (I'm using NetBSD-amd64-current... and VERY happy with it. Great thanks to the developers - I've just recently found netbsd is beeing the allmost perfect system for me! ...In the past, of course I've been using free and openbsd for a while... But I never had been so glad with both this systems - for various reasons... NetBSD is just amazing for me! ...But there is still some small disadvantages in it - not critical, but rather important for me) Is there any way to make viewable - russian(CP1251) filenames on msdos (FAT-32) filesystem!? Or at least a way to make this files just accessible under NetBSD??
Re: DRMKMS problem on i386 i915 chipset
Taylor R Campbell wrote: At the point where the console should switch to graphics mode I get a load of random colour bars on the screen. The system is still running at that point so by typing blind I've been able to gather some debug information. Can you please cvs update to sys/dev/pci/agp_i810.c 1.118 and try again? Yes that works perfectly. Thanks Mike
Re: DRMKMS problem on i386 i915 chipset
Martin Neitzel wrote: Having a problem getting a 7-BETA KMS kernel to work on my now quite old Sony VAIO laptop. Hey, at least you can **see** some dmesg output :-) For me (attempting my very first -current installation), the kernel from seven or ten days ago fails with blanking the screen. Just prior to that, it manages to dump some registers/memory/device table to the screen. The blanking (perhaps even panicing?) happens too fast to let me read anything, though. This is the i386 port on an ASUS EeePc 1000H, Atom N270 with Intel 945GME graphics. (Works just fine with Netbsd-5.x and -6.x, incl. drm) is very helpful to me because it provides a few suggestions for disabling drivers at userconf stage. That worked for me. I did: disable i915drmkms Which got me a kernel that booted in textmode. However I've now done some further debugging and I now have a working system with DRMKMS enabled including 3D accelleration in X. The critical failure in my system was the fact that the DRM driver couldn't map the VGA BIOS to get parameters from it. The reason for this failure turned out to be a piece of memory called the flush page allocated in the i810 AGP driver. The kernel was creating the mapping for this at 0xc->0xc0fff which is the first page of the VGA BIOS. Whether this page needs to be allocated or not depends on the system BIOS so it explains why DRMKMS would work for some people on i915 systems and not others. To fix this I made the mod described in the attached patch to the AGP driver so that it won't accept an allocation for this page in the first 1MB of memory to avoid the BIOS pages. No idea if this patch will fix it for others but perhaps it will. :) Mike Index: agp_i810.c === RCS file: /cvsroot/src/sys/dev/pci/agp_i810.c,v retrieving revision 1.112.2.2 diff -u -r1.112.2.2 agp_i810.c --- agp_i810.c 17 Mar 2015 17:52:49 - 1.112.2.2 +++ agp_i810.c 3 Apr 2015 20:53:41 - @@ -646,7 +646,7 @@ minaddr = PAGE_SIZE;/* XXX PCIBIOS_MIN_MEM? */ maxaddr = MIN(UINT64_MAX, ~(bus_addr_t)0); } - + minaddr = 0x10; /* Stay out of ISA mem/BIOS area */ /* Allocate or map a pre-allocated a page for it. */ if (ISSET(addr, 1)) { /* BIOS allocated it for us. Use that. */
DRMKMS problem on i386 i915 chipset
Having a problem getting a 7-BETA KMS kernel to work on my now quite old Sony VAIO laptop. At the point where the console should switch to graphics mode I get a load of random colour bars on the screen. The system is still running at that point so by typing blind I've been able to gather some debug information. agp0 at pchb0: i915-family chipset agp0: detected 7932k stolen memory agp0: aperture at 0xc000, size 0x1000 i915drmkms0 at pci0 dev 2 function 0: vendor 0x8086 product 0x27a2 (rev. 0x03) drm: Memory usable by graphics device = 256M drm: Supports vblank timestamp caching Rev 2 (21.10.2013). drm: Driver supports precise vblank timestamp query. drm: failed to find VBIOS tables i915drmkms0: interrupting at ioapic0 pin 16 (i915) drm: GMBUS [i915 gmbus panel] timed out, falling back to bit banging on pin 3 drm: initialized overlay support intelfb0 at i915drmkms0 i915drmkms0: info: registered panic notifier intelfb0: framebuffer at 0xdb07, size 640x480, depth 32, stride 2560 DRM error in intel_pipe_config_compare: mismatch in adjusted_mode.flags(DRM_MODE_FLAG_PHSYNC) (expected 0, found 1) warning: /work/netbsd/7-stable/src/sys/external/bsd/drm2/dist/drm/i915/intel_display.c:9891: pipe state doesn't match! Making an educated guess I thought that the lack of VBIOS data might be triggering the failure to detect the panel so I stuck some debug prints in pci_map_rom_md. The code gets as far the call to bus_space_map but that call returns an error. I have verified that there appears to be a valid VBIOS at 0xc using dd on /dev/mem to dump the first 1MB of memory. I can see the string that the VBIOS parser looks for so if the bus_space_map() call succeeded I'd probably have a working system. I guess this code needs to map the memory the same way that /dev/mem does to have the BIOS accesses in the DRM code succeed? I'll keep on digging but any help anyone can offer would be much appreciated. Mike
Re: Problem with kvm utilities on acorn32
Matt Thomas wrote: On Apr 25, 2014, at 3:45 PM, Mike Pumford wrote: Thanks for that but my kernel has quite a few tweaks as I'm trying to a little bit of modernization on the acorn32 specific code. In particular I'm tweaking the interrupt accounting to use event counters rather than the legacy method. My code was working with systat vmstat but I thought I ought to make sure the other kvm utilities that use those counters worked. :) Why not use arm/pic? That's new since I was last poking around in the kernel. :) I'll give it a try as I suspect the compiler will do a far better job of optimizing the ISR dispatch than the ancient hand-coded assembler that acorn32 is currently using. I especially don't like the fact that every interrupt has to check to see the which IOMD type is in use to build a mask of pending interrupts and to mask them. Using pic would avoid that as I could just code up 2 routines one for each type and make the decision once at start of day. Mike
Re: Problem with kvm utilities on acorn32
David Brownlee wrote: On 23 April 2014 19:14, Mike Pumford wrote: Not sure how arch specific this is but I'm seeing a problem with various KVM utilities on a 6.99.40 system on acorn32. e.g $ vmstat -i vmstat: undefined symbols: _pool_head Having searched the source code this symbol is a static variable in subr_pool.c and looking at the .o file for that I see: $ nm -n subr_pool.o | grep pool_head 0024 d pool_head 06d8 b pool_head_lock However neither of these symbols appear in the output of 'nm -n netbsd' Do we need to do some compiler magic to stop these symbols being optimized out of the kernel or do the kvm utils need to be modified to accept the fact that not all platforms will have the symbol? Presumably it should be enough to make pool_head non static - eg: change the def in subr_pool.c to /* List of all pools. Non static as needed by vmstat */ TAILQ_HEAD(, pool) pool_head = TAILQ_HEAD_INITIALIZER(pool_head); Yep that works. Prebuilt kernel in case its easier to test... (my acorn32 box is at the bottom of a very large pile of house contents) Thanks for that but my kernel has quite a few tweaks as I'm trying to a little bit of modernization on the acorn32 specific code. In particular I'm tweaking the interrupt accounting to use event counters rather than the legacy method. My code was working with systat vmstat but I thought I ought to make sure the other kvm utilities that use those counters worked. :) Mike
Problem with kvm utilities on acorn32
Not sure how arch specific this is but I'm seeing a problem with various KVM utilities on a 6.99.40 system on acorn32. e.g $ vmstat -i vmstat: undefined symbols: _pool_head Having searched the source code this symbol is a static variable in subr_pool.c and looking at the .o file for that I see: $ nm -n subr_pool.o | grep pool_head 0024 d pool_head 06d8 b pool_head_lock However neither of these symbols appear in the output of 'nm -n netbsd' Do we need to do some compiler magic to stop these symbols being optimized out of the kernel or do the kvm utils need to be modified to accept the fact that not all platforms will have the symbol? Mike