Re: Samba DC provisioning fails with Posix ACL enabled FFS

UFS_ACL enabled in XEN3_DOMU now. Le lun. 29 nov. 2021 à 17:46, Matthias Petermann a écrit : > > Am 28.11.21 um 17:32 schrieb Christos Zoulas: > > Thanks for the bug report :-) > > > > christos > > > > You're welcome :-) > > One more small question: currently the UFS_ACL option in the XEN3_DOMU

Re: build.sh live-image [virtio disk hang]

Le mar. 1 juin 2021 à 18:35, Rhialto a écrit : > I re-tried the same thing (almost the same thing; the partition was > smaller) with an amd64/9.2 install in an OpenStack VM: extracting the > pkgsrc tar file using sysinst. It hung before finishing. > > So there is either some general disk I/O

Re: posix_spawn issue?

Le sam. 1 mai 2021 à 14:25, Martin Husemann a écrit : > > On Sat, May 01, 2021 at 01:13:43PM +0200, Thomas Klausner wrote: > > The whole file is here: > > > > https://git.savannah.gnu.org/cgit/make.git/tree/src/job.c > > But since it mostly works (and only fails in some environments) there > must

Re: posix_spawn issue?

Le sam. 1 mai 2021 à 11:15, Martin Husemann a écrit : > > On Sat, May 01, 2021 at 11:02:26AM +0200, Thomas Klausner wrote: > > gmake since version 4.3 uses posix_spawn(), but that breaks the build > > of firefox (and libreoffice). Disabling posix_spawn() support in gmake > > works around this

Re: make fails to build on linux

Le sam. 17 avr. 2021 à 19:49, Manuel Bouyer a écrit : > > On Sat, Apr 17, 2021 at 07:25:58PM +0200, Manuel Bouyer wrote: > > Hello > > trying a build.sh tools on linux I got: > > /dsk/l1/misc/bouyer/HEAD/clean/src/tools/compat/../../lib/libc/regex/regcomp.c: > > In function '__regex_wctype': > >

Re: one remaining mystery about the FreeBSD domU failure on NetBSD XEN3_DOM0

Le mer. 14 avr. 2021 à 03:21, Greg A. Woods a écrit : > However their front-end code does detect it and seems to make use of it, > and has done for some 6 years now according to "git blame" (with no > recent fixes beyond fixing a memory leak on their end). Here we see it > live from FreeBSD's

Re: Status of COMPAT_LINUX and Linux emulation?

COMPAT_LINUX works as well as always, and will continue working the same. Presence in GENERIC does not change how reliable it is now or in future. There are no plans to remove the actual code, the option as well as the kernel module will continue working. Going forward using the kernel module is

Re: Missing "something" in nvme config messages

I changed the message, now it should say 'ld at nvme0 nsid 1 not configured' Le mar. 28 juil. 2020 à 15:08, Paul Goyette a écrit : > > If you have nvme configure, but do NOT have ``ld* at nvme?'' you > get an error message with something missing: > > ... > [ 7.616966] nvme0: for io queue 6

Re: xentools413 build failure

This is now fixed, the header should again be installed on build distribution. Thanks for the report. Jaromir Le mer. 22 juil. 2020 à 22:04, Jaromír Doleček a écrit : > > Let me recheck this, I removed the header on current since there > didn't seem to be any use for it in xen 4.11. A

Re: xentools413 build failure

Let me recheck this, I removed the header on current since there didn't seem to be any use for it in xen 4.11. Apparently I overlooked something. Le mer. 22 juil. 2020 à 21:26, Chavdar Ivanov a écrit : > > Hi, > > Under -current amd64 xentools 4.13.1 fail to build as follows: > > gcc

Re: Build error on amd64 -current

Fixed in rev.1.137 of sys/arch/xen/x86/cpu.c Le sam. 27 juin 2020 à 11:42, Jaromír Doleček a écrit : > > I'll fix it. > > Le sam. 27 juin 2020 à 11:39, Andreas Gustafsson a écrit : > > > > Paul Goyette wrote: > > > With up-to-date sources I'm getting > >

Re: Build error on amd64 -current

I'll fix it. Le sam. 27 juin 2020 à 11:39, Andreas Gustafsson a écrit : > > Paul Goyette wrote: > > With up-to-date sources I'm getting > > > > /build/netbsd-compat/src_ro/sys/arch/xen/x86/cpu.c: In function > > 'mp_cpu_start': > > /build/netbsd-compat/src_ro/sys/arch/xen/x86/cpu.c:999:1:

Re: ZFS disaster on -current

By chance, do you have the kernel crash dump from the original panic which happened yesterday? The subsequent ones might be a result of the first one. The messages about redzone don't mean anything beyond that there is no overflow protection for items on the pool. Jaromir Le mer. 24 juin 2020 à

Re: qemu emulated machine crashes due to disk timeouts

Le ven. 15 mai 2020 à 15:53, Jonathan A. Kollasch a écrit : > > On Sat, May 02, 2020 at 12:02:45PM +1000, Paul Ripke wrote: > > Since I have my qemu disk images on slow spinning rust host disks, when the > > host disk is busy (esp. daily+security runs), I find my qemu vm's see disk > > timeouts,

Re: qemu emulated machine crashes due to disk timeouts

Le jeu. 14 mai 2020 à 15:19, a écrit : > > Bumped ATA_DELAY to 3 (was 1), and the VM stayed up overnight, > > only logging the one correctable soft error: > > > > May 7 04:19:29 qemu /netbsd: [ 16290.3345912] autoconfiguration error: > > piixide0:0:0: lost interrupt > > May 7 04:19:29

Re: panic in ciss.c

Le ven. 17 avr. 2020 à 22:38, a écrit : > This was the first time. this machine survived successful complete source > builds and pkgsrc builds with -current up to 9.99.49. 50, 52 and 55 paniced > somewhere else. 9.99.56 survived much longer than these, and then this one > showed up.

Re: umass

Le mar. 14 avr. 2020 à 15:11, Patrick Welche a écrit : > > I just plugged in my USB SD card reader to a box with a new kernel and: > > ugen0: Generic (0x058f) Mass Storage Device (0x6366), rev 2.00/1.00, addr 1 > > No SD... > > On NetBSD 9.99.52, it used to look like: > > Apr 2 20:12:19 quantz

Re: Automated report: NetBSD-current/i386 build failure

Fix committed. The compiler was correct - I reused code around frame_list from setup, didn't notice the type is different. Thank yo. Jaromir Le ven. 10 avr. 2020 à 22:35, Robert Elz a écrit : > > Date:Thu, 9 Apr 2020 22:24:47 + (UTC) > From:NetBSD Test Fixture >

Re: Panic during reboot on amd64 9.99.52

Le ven. 27 mars 2020 à 20:33, Paul Goyette a écrit : > > With a curent built from sources updated just a few hours ago (on > 2020-03-27 at 16:13:55 UTC), I get a panic during shutdown. The > stack trace doesn't seem to be saved, but I manually transcribed > it: > > vpanic + 0x178 >

Re: panic after DRM & nouveau MSI changes

Le jeu. 13 févr. 2020 à 17:28, John D. Baker a écrit : > > On Wed, 12 Feb 2020, Jaromír DoleÄ~Mek wrote: > > > I've just committed a fix for the MSI interrupt allocation for > > nouveau, can you try it on the system which had the trouble with blank > > console? > > Instead of a blank screen, the

Re: panic after DRM & nouveau MSI changes

Le mer. 12 févr. 2020 à 03:38, John D. Baker a écrit : > I've checked this with plain GENERIC and one with the above file rolled > back. With plain generic, nouveau, intel, and radeon all work and have > MSI off. With the modified GENERIC, nouveau systems work (MSI off) and > intel and radeon

Re: panic after DRM & nouveau MSI changes

Le ven. 7 févr. 2020 à 23:22, John D. Baker a écrit : > I see that the MSI changes have been reverted. I have not yet updated > my sources and still have the MSI-enabled sources plus proposed nouveau > patch applied in my kernels. > > FWIW, quick tests with known-to-work radeon and intel

Re: Panic on multiuser boot after dhcpcd with msk(4)

Le ven. 7 févr. 2020 à 00:35, Jason Thorpe a écrit : > > > > On Feb 7, 2020, at 12:40 AM, Jason Thorpe wrote: > > > > Actually, I just got confirmation from nick that my patch fixes the > > problem, so I’ll check it in shortly. > > Ok, this should be fixed now. Please let me know if you

Panic on multiuser boot after dhcpcd with msk(4)

Hi, I get repeatable panic with uptodate -current when system goes multiuser: Adding interface aliases:. Waiting for DAD to complete for statically configured addresses... [ 10.9328087] wm0: link state UP (was DOWN) Starting dhcpcd. [ 12.8156398] msk0: link state DOWN (was UNKNOWN) [

Re: ifstats changes not yet applied to plip(4)?

This should be fixed in if_plip.c rev. 1.36 now. Jaromir Le mar. 4 févr. 2020 à 21:01, John D. Baker a écrit : > > Following this commit: > > http://mail-index.netbsd.org/source-changes/2020/02/04/msg113679.html > > kernels with ppbus(4) and plip(4) still fail, but there are fewer complaints

Re: vm.ubc_direct

Le mar. 3 déc. 2019 à 18:59, Chuck Silvers a écrit : > On Mon, Dec 02, 2019 at 07:10:52PM +, Andrew Doran wrote: > > Hello, > > > > In light of the recent discussion, and having asked Jaromir his thoughts > on > > the subject, we both think it's time to enable this by default, so it > gets >

Re: vm.ubc_direct

Can you send the dmesg and log of the recoverable I/O errors? Jaromir Le mer. 20 nov. 2019 à 15:04, Robert Nestor a écrit : > I tried enabling this option on my amd64 system running a fairly recent > version of -current off a new SSD. While building some packages I noticed > a lot of

Re: adding support for a possibly unsupported M.2 harddrive?

Le dim. 24 nov. 2019 à 12:18, ng0 a écrit : > Hi folx, > > I have an M.2 SSD for which I have to assume no support exists so far > in NetBSD 9.99.17. > This is an "TREKSTOR M.2 SSD-Modul 64 GB" bought in 2018. > > Its dmesg: > > [ 3.739718] wd1 at atabus1 drive 0 > [ 3.739718] wd1: <> >

Re: Increases in build system time

Le jeu. 14 nov. 2019 à 21:41, Christos Zoulas a écrit : > In article <24013.43646.552099.15...@guava.gson.org>, > Andreas Gustafsson wrote: > > > >Hi all, > > > >Back in September, I wrote: > > > 12% increase: > > > >2019.03.08.20.35.10 christos src/share/mk/bsd.own.mk 1.1108 > > > >

Re: tar extract changed since netbsd-8? (extracting sets over running system)

Le mar. 12 nov. 2019 à 12:05, Martin Husemann a écrit : > Not seen this locally, but that would be the switch to bsd/libarchive tar

Re: firefox52 quits on netbsd-9 w/i915drmkmsfb

Le mar. 5 nov. 2019 à 20:14, John D. Baker a écrit : > [...] > i965: Failed to submit batchbuffer: Input/output error > assertion "pthread__tsd_destructors[key] != NULL" failed: file > "/x/netbsd-9/src/lib/libpthread/pthread_tsd.c", line 177, function > "pthread__add_specific" > > It seems like

Re: mac68k kern-INSTALL vs GCC7?

Le ven. 15 févr. 2019 à 17:33, John D. Baker a écrit : > > Building for mac68k with -V HAVE_GCC=7 produces the following error: > > /x/current/src/sys/arch/mac68k/mac68k/intr.c:135:2: note: in expansion of > macro 'memcpy' > memcpy(g_inames, inames, MAX_INAME_LENGTH); > ^~ > cc1: all

Re: Recent USB changes broke kernel memory allocation

Fixed now. If you update the tree to have sys/dev/usb/umass.c rev. 1.174 you'll get the fixed files. Jaromir Le dim. 10 févr. 2019 à 19:31, Tom Ivar Helbekkmo a écrit : > > It seems that changes made to USB code on February 7th broke the kernel > memory allocation arena. After that point, it

Re: MSI/MSI-X implementation and interrupt handling on i386/amd64

Moving this to port-amd64 (bcced current-users@ for reference) Le mar. 11 déc. 2018 à 04:34, Kengo NAKAHARA a écrit : > I mention some old Athlon 64 series (before socket AM2) do not support > cmpxchg16b instruction. That would affect rewriting spllower to support > 64 bit interrupt bitmask.

Re: MSI/MSI-X implementation and interrupt handling on i386/amd64

Le jeu. 6 déc. 2018 à 16:05, Cherry G.Mathew a écrit : > The right thing to do is to stop using a bit mask entirely, and using > a bit more scalable Data structure for this. This isn't trivial though - > the assembler stuff will be harder to maintain correctness than a > straightup buslocked

Re: apu2 SATA patch

Committed this. Le lun. 26 nov. 2018 à 22:28, Mike Pumford a écrit : > > > > 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 > >>

Re: Panic in ahci_detach

Le jeu. 1 nov. 2018 à 06:38, Masanobu SAITOH a écrit : > The meaning of atac_nchannels changed or numbering of channel > changed? ahci_detach() counted improperly. Can you confirm rev. 1.66 of dev/ic/ahcisata_core.c fixes the problem? Jaromir

Re: Panic in ahci_detach

Le jeu. 1 nov. 2018 à 06:38, Masanobu SAITOH a écrit : > The meaning of atac_nchannels changed or numbering of channel > changed? No it hasn't, but ahcisata(4) used to not call the detach routine until about a week ago, so the logic might be actually buggy. I'll recheck it, stay tuned. Jaromir

Re: Build fails for kernels w/cd(4) but w/o wd(4)

Le sam. 27 oct. 2018 à 00:50, a écrit : > > On Fri, Oct 26, 2018 at 05:27:05PM -0500, John D. Baker wrote: > > --- wdc.o --- > > /x/current/src/sys/dev/ic/wdc.c:138:1: error: missing initializer for field > > 'ata_recovery' of 'const struct ata_bustype' > > [-Werror=missing-field-initializers]

Re: Xen Domu kernel crash at start of boot

2018-06-22 2:54 GMT+02:00 Chuck Zmudzinski : > I am getting a kernel crash almost immediately after booting the current > kernel. I am running NetBSD/xen amd64 on a Debian Linux 8.10 DOM0 which uses > Xen-4.4. Last week's kernel was good. I built a kernel from a cvs update a > couple of days ago

Re: Remove fortune quotes attributed to or providing admiration of Adolf Hitler [pr bin/52735]

I very strongly object to against anything appeasing any SJW or PC trolls, and I'm against removing those quotes. History needs to be remembered, and learnt from. Facts need to be told and faced. It is a great threat to our modern society that certain groups of people today are so intent on

Re: dump -X of large LVM based FFSv2 with WAPBL panics

Hi, can you try if doing full forced fsck (fsck -f) would resolve this? I've seen several such persistent panics when I was debugging WAPBL. Even after kernel fixes I had persistent panics around ffs_newvnode() due to disk data corruption from previous runs. This is worth trying. Some day I

Re: netbsd 8 (beta) failing to load ixg device

I had a very brief look on the crashing function ixgbe_update_stats_count(). The only division there is in the one using adapter->num_queue. Looking at ixgbe_configure_interrups(), seems that one can happily set it to 0 if number of MSI vectors is 1, as is the case according to your dmesg.

Re: dmesg spam: ahcisata0 port 1: active 2 is 0x40000001 tfd 0x2051

Stefan Hertenberger <stefan@hertenberger.bayern>: > Am Fri, 10 Nov 2017 18:43:19 +0100 > schrieb Jaromír Doleček <jaromir.dole...@gmail.com>: > > > TFES usually means an unsupported command was sent to the device, or a > > command was sent while previous was finis

Re: dmesg spam: ahcisata0 port 1: active 2 is 0x40000001 tfd 0x2051

TFES usually means an unsupported command was sent to the device, or a command was sent while previous was finished. Could you please try to figure out what is the command sent to the cd0 device just before that error? It should be possible to turn the debug messages on via the ahcdebug_mask

Re: dmesg spam: ahcisata0 port 1: active 2 is 0x40000001 tfd 0x2051

The TFD 0x2051 corresponds to Media Changed error, with DRDY/ERR status bits. Is it possible this message appears every time you change media in the cd0? Alternatively, I imagine this could be generated if the drive is setup to hibernate/suspend. Jaromir 2017-11-10 10:49 GMT+01:00

Re: New panic in wdc_ata_bio_intr

g > 3.0Gb/s signaling > Native Command Queuing > PHY Event Counters > Serial ATA features: > DMA Setup Auto Activate (disabled) > Device-Initiated Interface Power Managment (disabled) > Software Settings Preservation (enable

Re: New panic in wdc_ata_bio_intr

hed > work, so I shall keep it as it is for testing. > > Chavdar Ivanov > > On Sun, 15 Oct 2017 at 19:03 Jaromír Doleček <jaromir.dole...@gmail.com> > wrote: > >> Hi, >> >> should be fixed in rev. 1.285 of dev/ic/wdc.c, can you please check? >> >> Jar

Re: New panic in wdc_ata_bio_intr

he two T61p's (one of them stopped working a week ago, though). > > Chavdar Ivanov > > > On Sat, 14 Oct 2017 at 15:45 Jaromír Doleček <jaromir.dole...@gmail.com> > wrote: > >> Sorry, this fixed patch >> >> 2017-10-14 16:23 GMT+02:00 Jaromír Doleček

Re: New panic in wdc_ata_bio_intr

Sorry, this fixed patch 2017-10-14 16:23 GMT+02:00 Jaromír Doleček <jaromir.dole...@gmail.com>: > Can you try attached patch? > > Jaromir > > 2017-10-11 1:04 GMT+02:00 Chavdar Ivanov <ci4...@gmail.com>: > >> The timeouts when running under VirtualBox disappear

Re: New panic in wdc_ata_bio_intr

Can you try attached patch? Jaromir 2017-10-11 1:04 GMT+02:00 Chavdar Ivanov <ci4...@gmail.com>: > The timeouts when running under VirtualBox disappeared, but of course the > panic on my T61p remains. > > Chavdar Ivanov > > On Tue, 10 Oct 2017 at 22:40 Jaromír Doleček &l

Re: HEADS-UP: SATA NCQ support merged (from jdolecek-ncq branch)

I've fixed the compilation for ALL kernels. 2017-10-10 17:34 GMT+02:00 Michael : > I tried sequential reads ( dd if=/dev/rwd0c ... ) and throughput took a > significant hit. I used to get about 120MB/s with the siisata, now it > fluctuates between 80 and 90MB/s, ahcisata

Re: New panic in wdc_ata_bio_intr

Hey, can you try with dev/scsipi/atapi_wdc.c 1.128? That should resolve the timeouts for atapi, at least it did for me. Jaromir 2017-10-10 8:08 GMT+02:00 Rares Aioanei : > I get that also on VBox, except it doesn't try to add cd0a as a swap > device, nor does it show an

HEADS-UP: SATA NCQ support merged (from jdolecek-ncq branch)

Hi, I've merged the NCQ branch to HEAD. NCQ is supported on ahcisata(4), siisata(4), and mvsata(4) Gen IIe at this moment. The code was quite extensively tested on that harware on amd64. Other archs and drivers compile, but I had no way to test them. Particularily, I had no chance to really

Re: AMD Ryzen and NetBSD?

Fancy trying if it would behave differently with the NCQ branch? Jaromir 2017-07-03 6:34 GMT+02:00 Thor Lancelot Simon : > > 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

HEADS-UP: jdolecek-ncq branch merge imminent

Hello, I plan to merge the branch to HEAD very soon, likely over the weekend. Eventual further fixes will be done on HEAD already, including mvsata(4) restabilization, and potential switch of siisata(4) to support NCQ. The plan is to get this pulled up to netbsd-8 branch soon also, so that it

wd* at umass? owners wanted for testing

Hi, as part of work on jdolecek-ncq branch, I've made some mechanical changes to adjust the umass_isdata.c driver code to still hopefully work. I don't have the hardware though, so I'd like to have a real confirmation from somebody who does, before the branch would be merged. If you have the

Re: panic: kernel diagnostic assertion "next != _PSLIST_POISON"

Yes, this panic is already fixed in -current: panic: kernel diagnostic assertion "!(bp->b_oflags & BO_DELWRI)" failed: file "../../../../kern/vfs_wapbl.c", line 1142 Jaromir 2017-03-14 9:04 GMT+01:00 Frank Kardel : > Hmm, I think ch_voltag_convert_in() is a red herring, > >

Re: W^X mmap

I think you can avoid the #ifdef in uvm_mmap.c by simply definining the macro PAX_MPROTECT_ADJUST() to return 0 if the feature is off. Also, it would be wiser to just add error handling to the call in uvm_unix.c, rather then assuming it never fails. Or just remove the call there if it's so

Re: ffs_newvnode: inode has non zero blocks

> | There are some further changes needed to cover a possible dup alloc , > | and to keep the !wapbl case recoverable by fsck. There is ongoing > | discussion on source-changes about that, hope we finalise fix later in > | the week. > > Leaving a filesystem problem committed on head that can cause

Re: ffs_newvnode: inode has non zero blocks

Yes, that problem is related to the wapbl change. I've committed a bug fix, so newer kernel shouldn't trigger the panic any more. There are some further changes needed to cover a possible dup alloc , and to keep the !wapbl case recoverable by fsck. There is ongoing discussion on source-changes

Re: ffs_newvnode: inode has non zero blocks

There was recenly change a change in FFS in the general area for WAPBL. Can you try attached patch and check if following KASSERT() triggers? 2016-11-02 18:39 GMT+01:00 Andreas Gustafsson : > co...@sdf.org wrote: >> I'm pretty 'abusive' to my machine. unsurprisingly, I've managed

Re: Wapbl correct and stable again?

2016-10-21 1:56 GMT+02:00 bch : > I just had a kernel fault (might be audio subsystem, will investigate), but > with this latest (7.99.40) kernel I'm still getting corruption. I don't know > if it's new code in the filesystem, or bad luck that I'm faulting so much, >

Re: WANTED: nvme(4) driver testing on MP systems on -current

machine, but I've had an I/O lockup on real hw machine with -O2 kernel. It may have been unrelated, I'm still investigating. Jaromir 2016-10-18 22:01 GMT+02:00 Jaromír Doleček <jaromir.dole...@gmail.com>: > Hey, > > thank you. This iostat_unbusy panic is typical symptom of the curr

Re: Kernel faults, wapbl updates

After updating to newest kernel (with vfs_wapbl.c 1.84), it is necessary to run fsck to get filesystem to fully healthy state. After fsck, there shouldn't be any further problems related to the current change. Sorry about that and thanks for patience. Jaromir 2016-10-02 16:46 GMT+02:00

Re: Kernel faults, wapbl updates

There was a use-after-free bug which ended up with the fault on DEBUG kernels, it's fixed now in revision 1.82 of kern/vfs_wapbl.c Thank you. Jaromir 2016-10-02 1:26 GMT+02:00 bch : > On 10/1/16, Jaromir Dolecek wrote: >> If you can get just a

Re: Kernel faults, wapbl updates

If you can get just a short traceback (which particular wapbl function(s) for example), it would help to figure possible problem. The changes to vfs_wapbl.c were fairly minor so far. I would understand new panics, but it would be strange if they caused faults. Maybe if you can try to downgrade

WANTED: nvme(4) driver testing on MP systems on -current

Hello, NVMe driver in NetBSD-current was recently tweaked to fix several MP and locking issues, and the driver is now marked as MPSAFE by default. Most of this work was done on emulators since I lack the the hardware, so it's not clear if everything would work properly on real systems too.

Re: Building on OS X - how?

FWIW, build of tools for both i386 and sparc64 finished without problems for me on Mac OS X host (10.11.6), building from clean sources. Jaromir 2016-08-12 21:54 GMT+02:00 matthew green : > Thor Lancelot Simon writes: >> On Thu, Aug 11, 2016 at 04:05:06PM +0100, Robert