Re: Is there the system call to set all 3 time at once?

bsdairekii...@posteo.de writes: > I have been using UFS2 on NetBSD longer than UFS1 and will continue to > do so for the next 10 years. Unless UFS3 is released in that time, if > not, I will use UFS2 even longer. Therefore, as in the description, a > system call should be added that allows to set

Re: NULL pointer arithmetic issues

Johnny Billquist writes: > Well, the d-dpace don't start at 1, and also, the PDP-11 isn't that > fond of odd addresses. :-) True - I should have said that they started actual allocation of data objects at a non-zero address. :) > Here is the current "state": Thanks! That's really

Re: NULL pointer arithmetic issues

Johnny Billquist writes: > But yes, on the PDP11 [having nothing mapped at address 0] was/is not > the case. Memory space is too precious to allow some of it to be > wasted for this... Yup - and I assume the "hack" Kamil alludes to is the practice of actually starting the data segment for split

Re: panic: softint screwup

Andrew Doran writes: > On Tue, Feb 04, 2020 at 07:03:28AM -0400, Jared McNeill wrote: > >> First time seeing this one.. an arm64 board sitting idle at the login >> prompt rebooted itself with this panic. Unfortunately the default >> ddb.onpanic=0 strikes again and I can't get any more

Re: /dev/ksyms permissions

Maxime Villard writes: >> Agreed. This works fine for me, with and without /dev/ksyms present: >> >> Index: lib/libkvm/kvm.c >> [...] > > So, I guess I can commit it? I've been running with that modification (and /dev/ksyms mode 440 and group kmem) on all my systems since

Re: /dev/ksyms permissions

Maxime Villard writes: > Well, looking at the code, it seems to me that _kvm_open() should be > changed to keep /dev/ksyms open, the same way it keeps /dev/kmem open. Agreed. This works fine for me, with and without /dev/ksyms present: Index: lib/libkvm/kvm.c

Re: /dev/ksyms permissions

Maxime Villard writes: > So, making /dev/ksyms 440 root:kmem should not break anything. > > If it does, then there's a bug in the offending tool in the first place. Agreed. systat is one of them. It takes care to call kvm_openfiles() while setgid kmem, but kvm_openfiles()

Re: spurious DIAGNOSTIC message "no disk label"

mo...@rodents-montreal.org writes: > 4.3 did not have on-disk disklabels. Partition tables were built into > the drivers; changing partitioning required recompiling the relevant > driver. (I'm reasonably sure it worked that way for the disks we > actually had on our 4.3 machine(s), at least.)

Re: compat linux futex problem

Robert Swindells writes: > I'm trying to run a fairly large Linux application that is a mixture of > Java and native code, it spawns off several threads but all of them > end up waiting on futex and not using any cpu time. This sounds like a well-known FUTEX bug in Linux, that

Re: Removing ARCNET stuffs

mo...@rodents-montreal.org writes: But I too find it regrettable and possibly dangerous. Me, too. What NetBSD offers, that no other O/S offers, is the support for platforms that are no longer mainstream. I've run it on Sparc and VAX processors for years, and hope to continue playing with

Re: Removing ARCNET stuffs

Taylor R Campbell campbell+netbsd-tech-k...@mumble.net writes: Diversity is great, but only if it is exercised. Yeah, but some of the old stuff is always going to be used off and on, as people with an interest in the particular technology come and go. Ditching support for something the moment

Re: Removing ARCNET stuffs

paul_kon...@dell.com writes: And DECnet nodes exist around the Internet; the “Hobbyist DECnet” group (“hecnet”) is the main focus of that activity as far as I know. ...and while I'm sure Johnny Billquist can supply more details, and correct me if I'm wrong, DECnet on NetBSD seems to me to be

Re: Interrupt storm mitigation needed

Joerg Sonnenberger jo...@britannica.bec.de writes: If it still generates interrupts, there is not much we can do. I do not believe turning off interrupts on the PIC is in any way appropiate. I've been running with your uhci polled mode hack for some time, now, in SMP mode, and it's nice and

Re: Interrupt storm mitigation needed

Joerg Sonnenberger jo...@britannica.bec.de writes: Just in case others run into it, you can put the patch you are running into GNATS? Yes, of course. Should I submit it as a bug report with a known workaround, and then you (or someone) close it as a won't fix, thus leaving it saved and

Re: Interrupt storm mitigation needed

Joerg Sonnenberger jo...@britannica.bec.de writes: Yes, of course. Should I submit it as a bug report with a known workaround, and then you (or someone) close it as a won't fix, thus leaving it saved and searchable? Yeah, that was the idea. Done. kern/49711. -tih -- Popularity is the

Re: Interrupt storm mitigation needed

Thor Lancelot Simon t...@panix.com writes: We saw this on a platform of similar vintage at a former employer of mine, and indeed the uhci was one of the devices involved. While googling just now, I discovered that you've observed the problem before within the NetBSD Foundation, as well:

Re: Interrupt storm mitigation needed

Joerg Sonnenberger jo...@britannica.bec.de writes: If it still generates interrupts, there is not much we can do. I do not believe turning off interrupts on the PIC is in any way appropiate. All right, but before we drop this, could you help me understand your experimental patch that I'm

Re: Interrupt storm mitigation needed

Joerg Sonnenberger jo...@britannica.bec.de writes: (1) It's a shared interrupt. (2) uhci is generated interrupts when it should not. It's unlikely that we can do anything about (1), so I was trying to see if we can do something about (2). Note that this is not true polled mode in the sense

Re: Interrupt storm mitigation needed

Joerg Sonnenberger jo...@britannica.bec.de writes: From what I see from the original message, there are two issues: (1) It's a shared interrupt. (2) uhci is generated interrupts when it should not. Also ehci. Here are the updated counters, with usage info: interrupt total

Re: Interrupt storm mitigation needed

Tom Ivar Helbekkmo t...@hamartun.priv.no writes: uhci0, uhci2, and ehci0 are all getting lots of erroneous interrupts, Also, studying my log of a ping that's sending one ICMP ECHO per second to the machine from another host on the local network, I see that whereas without Jörg's changes I had

Re: Interrupt storm mitigation needed

Tom Ivar Helbekkmo t...@hamartun.priv.no writes: Your new wrapper doesn't grab the sc_intr_lock mutex, so it fails the KASSERT in uhci_intr1(). I'll add the enter and exit calls to the wrapper and try again -- after dinner. :) I have it running, now, and the initial impression

Re: Interrupt storm mitigation needed

Tom Ivar Helbekkmo t...@hamartun.priv.no writes: The uhci pins on the ioapics are chalking up a few interrupts, but not many, and no bursts. Still nothing bad happening, but I did reboot just now, and saw something that I've observered a few times lately: when the machine was just sufficiently

Re: Interrupt storm mitigation needed

Joerg Sonnenberger jo...@britannica.bec.de writes: Well, let's try the first hack of keep uhci interrupts off and just poll via timeout. Will try this in a few hours, when I'm back with the machine. It'll be interesting to see what happens, not least because there's another symptom that I

Re: Interrupt storm mitigation needed

Tom Ivar Helbekkmo t...@hamartun.priv.no writes: Still nothing bad happening, but I did reboot just now, and saw something that I've observered a few times lately: when the machine was just sufficiently up that I could log in, 'vmstat -i' told me that the ioapic pin for uhci2 had already

Re: Interrupt storm mitigation needed

Tom Ivar Helbekkmo t...@hamartun.priv.no writes: The machine has now been running for nine hours, doing a -j 2 system build, and also running backups during the night -- with no incidents. The interrupt counts, though, are up to 600 thousand on the uhci2 pin, 400 thousand on the uhci0 pin

Re: Interrupt storm mitigation needed

Joerg Sonnenberger jo...@britannica.bec.de writes: Well, let's try the first hack of keep uhci interrupts off and just poll via timeout. Your new wrapper doesn't grab the sc_intr_lock mutex, so it fails the KASSERT in uhci_intr1(). I'll add the enter and exit calls to the wrapper and try

Interrupt storm mitigation needed

Hello, I'm running NetBSD-current/amd64 on a Dell PowerEdge 2850, and have been experiencing mysterious hangs. With help and guidance from Christos Zoulas, I belive I've gotten to where I now know what's going on. What to do about it is a more difficult question, and Christos suggested we take

Re: Interrupt storm mitigation needed

Tom Ivar Helbekkmo t...@hamartun.priv.no writes: Here are some interrupt mappings (the devices that are actually in use are amr0, wm0, and uhci2 (the latter running a 1200 bps serial line over a ucom device, talking to my UPS, and normally generating about 1200 or so interrupts per second

Re: Interrupt storm mitigation needed

Joerg Sonnenberger jo...@britannica.bec.de writes: Can you add a counter to uhci.c line 1317? The question for me is whether the device is creating interrupts without actually setting the status to anything different or if it does provide some notification but at a too high rate. Well, that