Re: CVS commit: src/sys/compat/netbsd32

On Tue, Apr 30, 2024 at 05:10:22PM +, Michael van Elst wrote: > Module Name: src > Committed By: mlelstv > Date: Tue Apr 30 17:10:22 UTC 2024 > > Modified Files: > src/sys/compat/netbsd32: netbsd32_sysent.c > > Log Message: > Enable compat sigreturn system call. Please check

Re: POINTER_ALIGNED_P (was: Re: CVS commit: src/sys)

In article <5912ca9e-b4e7-423d-a45d-f4693d1c9...@zoulas.com>, Christos Zoulas wrote: >-=-=-=-=-=- Here's the final changes - Make ALIGNED_POINTER use __alignof(t) instead of sizeof(t). This is more correct because it works with non-primitive types and provides the ABI alignment for the

Re: CVS commit: src/sys/dev

On Sat, Dec 26, 2020 at 02:50:50PM +, Nia Alarie wrote: > Module Name: src > Committed By: nia > Date: Sat Dec 26 14:50:50 UTC 2020 > > Modified Files: > src/sys/dev: fss.c > > Log Message: > Check the return value of device_lookup_private against NULL. > > Reported-by:

Re: MAX_PAGE_SIZE for m68k (Re: CVS commit: src/sys/arch/arm/include/arm32)

> On Jan 13, 2020, at 10:24 AM, Christos Zoulas wrote: > > Talking to myself: > > The arm PAGE_SIZE_{MIN,MAX} should go away after nick eliminates the > need for the 8K pages. This leaves us with m68k to deal with... > Do modules work on m68k? Should modules be shared between kernels with >

Re: MAX_PAGE_SIZE for m68k (Re: CVS commit: src/sys/arch/arm/include/arm32)

On Jan 14, 1:15am, tsut...@ceres.dti.ne.jp (Izumi Tsutsui) wrote: -- Subject: Re: MAX_PAGE_SIZE for m68k (Re: CVS commit: src/sys/arch/arm/incl | christos@ wrote: | | > >Now I get the following erro during local tests of | > >"build.sh -U -m hp300 release" on Ne

Re: sys_ptrace_lwpstatus.c (Was: CVS commit: src/sys)

On 26.12.2019 15:11, Valery Ushakov wrote: > On Thu, Dec 26, 2019 at 08:52:39 +, Kamil Rytarowski wrote: > >> Module Name: src >> Committed By:kamil >> Date:Thu Dec 26 08:52:39 UTC 2019 >> >> Modified Files: >> src/sys/kern: files.kern sys_ptrace_common.c >>

sys_ptrace_lwpstatus.c (Was: CVS commit: src/sys)

On Thu, Dec 26, 2019 at 08:52:39 +, Kamil Rytarowski wrote: > Module Name: src > Committed By: kamil > Date: Thu Dec 26 08:52:39 UTC 2019 > > Modified Files: > src/sys/kern: files.kern sys_ptrace_common.c > src/sys/sys: ptrace.h > Added Files: > src/sys/kern:

Re: CVS commit: src/sys/kern

On Mon, Sep 16, 2019 at 03:39:35AM +0200, Emmanuel Dreyfus wrote: > Thor Lancelot Simon wrote: > > > I've never been a fan of the wedge: syntax (as was noted at the time, it > > conflicts with the syntax for specifying network filesystem servers, > > which actually broke automation I had in

Re: CVS commit: src/sys/kern

Thor Lancelot Simon wrote: > I've never been a fan of the wedge: syntax (as was noted at the time, it > conflicts with the syntax for specifying network filesystem servers, > which actually broke automation I had in place); I would not mind seeing > it go. IMO, both wedge: and NAME= are ugly,

Re: CVS commit: src/sys/kern

m...@netbsd.org (Emmanuel Dreyfus) writes: >Michael van Elst wrote: >> We have to decide if we really want to switch things to the NAME= >> syntax and allow wedge: only for compatibility. >I went for NAME= here because x86 bootloader now uses that everywhere, >and my concern was multiboot

Re: CVS commit: src/sys/kern

Michael van Elst wrote: > We have to decide if we really want to switch things to the NAME= > syntax and allow wedge: only for compatibility. I went for NAME= here because x86 bootloader now uses that everywhere, and my concern was multiboot command line root options passed as is from

Re: CVS commit: src/sys/kern

On Sun, Sep 15, 2019 at 03:47:32AM +0200, Emmanuel Dreyfus wrote: > Michael van Elst wrote: > > > A real solution would just support the NAME=* syntax in getwedgename(). > > It might also allow for a case-insensitive match like userland. Then > > it would just work for config, for boot

Re: CVS commit: src/sys/kern

Michael van Elst wrote: > A real solution would just support the NAME=* syntax in getwedgename(). > It might also allow for a case-insensitive match like userland. Then > it would just work for config, for boot parameters and for interactive > entries. You mean this change? ---

Re: CVS commit: src/sys/kern

Martin Husemann wrote: > Oh, *B*ootdev vs. *R*ootdev - I see. > Not sure why bootdev is important, however we should use the same syntax! The change handles the parameter passed from bootloader when booting Xen. In boot.cfg, NAME=label is now supported everywhere, and this was the only missing

Re: CVS commit: src/sys/kern

mar...@duskware.de (Martin Husemann) writes: >> config netbsd root on "wedge:Guru-Root" type ffs >> for ages (in the netbsd-7 branch even). >Oh, *B*ootdev vs. *R*ootdev - I see. >Not sure why bootdev is important, however we should use the same syntax! bootdev already

Re: CVS commit: src/sys/kern

On Sat, Sep 14, 2019 at 06:26:34AM +, Martin Husemann wrote: > > Log Message: > > Accept root device specification as NAME=label [..] > Why is this needed? > > I have been using > > config netbsd root on "wedge:Guru-Root" type ffs > > for ages (in the netbsd-7

Re: CVS commit: src/sys/kern

On Fri, Sep 13, 2019 at 01:33:20AM +, Emmanuel Dreyfus wrote: > Module Name: src > Committed By: manu > Date: Fri Sep 13 01:33:20 UTC 2019 > > Modified Files: > src/sys/kern: kern_subr.c > > Log Message: > Accept root device specification as NAME=label > > > To generate a

Re: Multiple outstanding transfer vs xhci / ehci (Re: CVS commit: src/sys/dev/usb)

On 2019/02/15 23:37, Nick Hudson wrote: On 15/02/2019 13:44, Rin Okuyama wrote: On 2019/02/15 21:57, Jonathan A. Kollasch wrote: On Wed, Feb 13, 2019 at 06:35:14PM +0900, Rin Okuyama wrote: Hi, On 2019/02/13 3:54, Nick Hudson wrote: On 12/02/2019 16:02, Rin Okuyama wrote: Hi, The system

Re: Multiple outstanding transfer vs xhci / ehci (Re: CVS commit: src/sys/dev/usb)

On 15/02/2019 13:44, Rin Okuyama wrote: On 2019/02/15 21:57, Jonathan A. Kollasch wrote: On Wed, Feb 13, 2019 at 06:35:14PM +0900, Rin Okuyama wrote: Hi, On 2019/02/13 3:54, Nick Hudson wrote: On 12/02/2019 16:02, Rin Okuyama wrote: Hi, The system freezes indefinitely with xhci(4) or

Re: Multiple outstanding transfer vs xhci / ehci (Re: CVS commit: src/sys/dev/usb)

On Fri, Feb 15, 2019 at 10:44:23PM +0900, Rin Okuyama wrote: > On 2019/02/15 21:57, Jonathan A. Kollasch wrote: > > On Wed, Feb 13, 2019 at 06:35:14PM +0900, Rin Okuyama wrote: > > > Hi, > > > > > > On 2019/02/13 3:54, Nick Hudson wrote: > > > > On 12/02/2019 16:02, Rin Okuyama wrote: > > > > >

Re: Multiple outstanding transfer vs xhci / ehci (Re: CVS commit: src/sys/dev/usb)

On 2019/02/15 21:57, Jonathan A. Kollasch wrote: On Wed, Feb 13, 2019 at 06:35:14PM +0900, Rin Okuyama wrote: Hi, On 2019/02/13 3:54, Nick Hudson wrote: On 12/02/2019 16:02, Rin Okuyama wrote: Hi, The system freezes indefinitely with xhci(4) or ehci(4), when NIC with multiple outstanding

Re: Multiple outstanding transfer vs xhci / ehci (Re: CVS commit: src/sys/dev/usb)

On Wed, Feb 13, 2019 at 06:35:14PM +0900, Rin Okuyama wrote: > Hi, > > On 2019/02/13 3:54, Nick Hudson wrote: > > On 12/02/2019 16:02, Rin Okuyama wrote: > > > Hi, > > > > > > The system freezes indefinitely with xhci(4) or ehci(4), when NIC with > > > multiple outstanding transfers [axen(4),

Re: DIAGNOSTIC for modules (Re: CVS commit: src/sys/dev/usb)

On 2019/02/13 21:13, Christos Zoulas wrote: In article , Rin Okuyama wrote: Hi, On 2019/02/13 6:07, Paul Goyette wrote: On Tue, 12 Feb 2019, Rin Okuyama wrote: Hi, As Martin pointed out, it is useful for debugging to turn on DIAGNOSTIC for modules (for non-release branches). Now, all

Re: DIAGNOSTIC for modules (Re: CVS commit: src/sys/dev/usb)

In article , Rin Okuyama wrote: >Hi, > >On 2019/02/13 6:07, Paul Goyette wrote: >> On Tue, 12 Feb 2019, Rin Okuyama wrote: >> >>> Hi, >>> >>> As Martin pointed out, it is useful for debugging to turn on >>> DIAGNOSTIC for modules (for non-release branches). >>> >>> Now, all modules for amd64

Re: DIAGNOSTIC for modules (Re: CVS commit: src/sys/dev/usb)

On 2019/02/13 19:06, Paul Goyette wrote: I would also wonder if we could increase the WARNS?= level from 3 to 5 (to match the current WARNS?= level used for kernel builds).  Has anyone tried to see how many modules would fail with WARNS?=5  ?? Thank you for your comment. Well, I examined

Re: DIAGNOSTIC for modules (Re: CVS commit: src/sys/dev/usb)

I would also wonder if we could increase the WARNS?= level from 3 to 5 (to match the current WARNS?= level used for kernel builds).  Has anyone tried to see how many modules would fail with WARNS?=5  ?? Thank you for your comment. Well, I examined that (both for GCC7 & clang). Among ~ 360

Re: Multiple outstanding transfer vs xhci / ehci (Re: CVS commit: src/sys/dev/usb)

Hi, On 2019/02/13 3:54, Nick Hudson wrote: On 12/02/2019 16:02, Rin Okuyama wrote: Hi, The system freezes indefinitely with xhci(4) or ehci(4), when NIC with multiple outstanding transfers [axen(4), mue(4), and ure(4)] is stopped by "ifconfig down" or detached. As discussed in the previous

Re: DIAGNOSTIC for modules (Re: CVS commit: src/sys/dev/usb)

On Tue, 12 Feb 2019, Rin Okuyama wrote: Hi, As Martin pointed out, it is useful for debugging to turn on DIAGNOSTIC for modules (for non-release branches). Now, all modules for amd64 are successfully built with DIAGNOSTIC. I'd like to commit the patch below, if there's no objection. This

Re: Multiple outstanding transfer vs xhci / ehci (Re: CVS commit: src/sys/dev/usb)

On 12/02/2019 16:02, Rin Okuyama wrote: Hi, The system freezes indefinitely with xhci(4) or ehci(4), when NIC with multiple outstanding transfers [axen(4), mue(4), and ure(4)] is stopped by "ifconfig down" or detached. As discussed in the previous message, this is due to infinite loop in

Multiple outstanding transfer vs xhci / ehci (Re: CVS commit: src/sys/dev/usb)

Hi, The system freezes indefinitely with xhci(4) or ehci(4), when NIC with multiple outstanding transfers [axen(4), mue(4), and ure(4)] is stopped by "ifconfig down" or detached. As discussed in the previous message, this is due to infinite loop in usbd_ar_pipe(); xfers with USBD_NOT_STARTED

DIAGNOSTIC for modules (Re: CVS commit: src/sys/dev/usb)

Hi, As Martin pointed out, it is useful for debugging to turn on DIAGNOSTIC for modules (for non-release branches). Now, all modules for amd64 are successfully built with DIAGNOSTIC. I'd like to commit the patch below, if there's no objection. Thanks, rin Index: sys/modules/Makefile.inc

Re: Unaligned access in kernel on ARMv6+ (Re: CVS commit: src/sys/dev/usb)

On 1/6/2019 5:50 PM, Jason Thorpe wrote: On Jan 6, 2019, at 1:46 PM, matthew green wrote: ... how do we convey the structure alignment needed for softc, or do we fix it by moving it into its own separate aligned allocation? The latter, I think. I agree.  When a driver has a strict alignment

Re: Unaligned access in kernel on ARMv6+ (Re: CVS commit: src/sys/dev/usb)

> On Jan 6, 2019, at 2:26 PM, Christos Zoulas wrote: > > Shouldn't the compiler know how to do this right by padding around the > structure that needs alignment and assuming the default alignment for > the enclosing structure? No, because the compiler can't be assured of what alignment the

Re: Unaligned access in kernel on ARMv6+ (Re: CVS commit: src/sys/dev/usb)

> On Jan 6, 2019, at 1:46 PM, matthew green wrote: > > ... how do we convey the structure alignment needed for > softc, or do we fix it by moving it into its own separate > aligned allocation? The latter, I think. -- thorpej

re: Unaligned access in kernel on ARMv6+ (Re: CVS commit: src/sys/dev/usb)

> | for xhci, all of these seem to be the same issue and it > | appears to be a "high level allocator doesn't know what > | it is allocating and does not align properly". the > | problem is likely: > | > | #define XHCI_TRB_ALIGN 16 > | struct xhci_trb { > | ... > | } __packed

re: Unaligned access in kernel on ARMv6+ (Re: CVS commit: src/sys/dev/usb)

On Jan 7, 8:46am, m...@eterna.com.au (matthew green) wrote: -- Subject: re: Unaligned access in kernel on ARMv6+ (Re: CVS commit: src/sys | > http://netbsd.org/~kamil/kubsan/0007-boot-real-hardware.txt | | for xhci, all of these seem to be the same issue and it | appears to be a "hi

re: Unaligned access in kernel on ARMv6+ (Re: CVS commit: src/sys/dev/usb)

> http://netbsd.org/~kamil/kubsan/0007-boot-real-hardware.txt for xhci, all of these seem to be the same issue and it appears to be a "high level allocator doesn't know what it is allocating and does not align properly". the problem is likely: #define XHCI_TRB_ALIGN 16 struct xhci_trb { ... }

Re: CVS commit: src/sys/dev/i2c

> On Dec 14, 2018, at 2:05 PM, Michael Lorenz wrote: > > Module Name: src > Committed By: macallan > Date: Fri Dec 14 22:05:36 UTC 2018 > > Modified Files: > src/sys/dev/i2c: ds1307.c files.i2c > > Log Message: > add options DSRTC_YEAR_START_2K for machines which use 2000 and

Re: MIPS MMU state in early bootstrap stage (Fwd: Re: CVS commit: src/sys/dev/hpc)

Cc: source-change...@netbsd.org Subject: Re: CVS commit: src/sys/dev/hpc On Tue, Sep 18, 2018 at 18:52:34 +0900, Rin Okuyama wrote: On 2018/09/18 18:21, Valery Ushakov wrote: > On Tue, Sep 18, 2018 at 12:17:41 +0900, Rin Okuyama wrote: >> > > @@ -278,8 +279,10 @@ hpckbd_keym

MIPS MMU state in early bootstrap stage (Fwd: Re: CVS commit: src/sys/dev/hpc)

, and kernel is directly mapped. Is this true? Thanks, rin Forwarded Message Date: Tue, 18 Sep 2018 13:35:45 +0300 From: Valery Ushakov To: Rin Okuyama Cc: source-change...@netbsd.org Subject: Re: CVS commit: src/sys/dev/hpc On Tue, Sep 18, 2018 at 18:52:34 +0900, Rin Okuyama

Re: CVS commit: src/sys/arch/x86/x86

On 08.07.2018 17:44, Kamil Rytarowski wrote: > I will try to scratch a new header unaligned.h with the set of macros > and submit it to evaluation. I've prepared a scratch of unaligned.h with get_unaligned(): http://netbsd.org/~kamil/kubsan/unaligned.h There are at least two problems to

Re: CVS commit: src/sys/arch/x86/x86

On 09.07.2018 16:58, Thor Lancelot Simon wrote: > On Mon, Jul 09, 2018 at 12:24:15PM +0200, Kamil Rytarowski wrote: >> >> The C11 standard could indeed use consistent wording. In one place >> "correctly aligned" in other alignment "restrictions" and >> "requirements". None of these terms is marked

Re: CVS commit: src/sys/arch/x86/x86

In article <20180709145848.ga21...@panix.com>, Thor Lancelot Simon wrote: >On Mon, Jul 09, 2018 at 12:24:15PM +0200, Kamil Rytarowski wrote: >> >> The C11 standard could indeed use consistent wording. In one place >> "correctly aligned" in other alignment "restrictions" and >> "requirements".

Re: CVS commit: src/sys/arch/x86/x86

On Mon, Jul 09, 2018 at 12:24:15PM +0200, Kamil Rytarowski wrote: > > The C11 standard could indeed use consistent wording. In one place > "correctly aligned" in other alignment "restrictions" and > "requirements". None of these terms is marked as a keyword or term and I > read them in the

Re: CVS commit: src/sys/arch/x86/x86

On 09.07.2018 11:32, Martin Husemann wrote: > On Mon, Jul 09, 2018 at 11:00:15AM +0200, Kamil Rytarowski wrote: >> According to my understanding, alignment requirement for a type/object >> is implementation defined (6.2.8); however during the process of >> converting types, if the returned pointer

Re: CVS commit: src/sys/arch/x86/x86

On Mon, Jul 09, 2018 at 11:00:15AM +0200, Kamil Rytarowski wrote: > According to my understanding, alignment requirement for a type/object > is implementation defined (6.2.8); however during the process of > converting types, if the returned pointer is not correctly aligned the > result is

Re: CVS commit: src/sys/arch/x86/x86

On 09.07.2018 10:09, Martin Husemann wrote: > On Sun, Jul 08, 2018 at 03:30:36PM +0200, Kamil Rytarowski wrote: >> Misaligned pointer is explicitly documented as undefined behavior in the >> C standard (C11 6.3.2.3 p7). (In C++ it's basically the same.) > > Yes, but the standard dos not define

Re: CVS commit: src/sys/arch/x86/x86

On Sun, Jul 08, 2018 at 03:30:36PM +0200, Kamil Rytarowski wrote: > Misaligned pointer is explicitly documented as undefined behavior in the > C standard (C11 6.3.2.3 p7). (In C++ it's basically the same.) Yes, but the standard dos not define what a misaligned pointer is (or "correctly aligned").

Re: CVS commit: src/sys/arch/x86/x86

>>> Misaligned pointer is explicitly documented as undefined behavior >>> in the C standard (C11 6.3.2.3 p7). >> So what? Do you have reason to think that sys/arch/x86 will at some >> point be ported to a compiler [] that does something unexpected with >> that code? > Due to UB a compiler is free

Re: CVS commit: src/sys/arch/x86/x86

On 08.07.2018 17:30, Mouse wrote: > Caveat: this is all opinion. I'm not the one doing the work here. > > src/sys/arch/x86/x86: mpbios.c > > Remove unaligned access to mpbios_page[] > > sys/arch/x86/x86/mpbios.c:308:11, load of misaligned address > 0x800031c7a413

Re: CVS commit: src/sys/arch/x86/x86

On 08.07.2018 17:16, Jason Thorpe wrote: > > >> On Jul 8, 2018, at 6:30 AM, Kamil Rytarowski wrote: >> >> In future __NO_STRICT_ALIGNMENT could be defined for aarch64, at least >> for the use of acpica (which still contains a fallback for Itanium >> without misaligned access, but not actively

Re: CVS commit: src/sys/arch/x86/x86

Caveat: this is all opinion. I'm not the one doing the work here. src/sys/arch/x86/x86: mpbios.c Remove unaligned access to mpbios_page[] sys/arch/x86/x86/mpbios.c:308:11, load of misaligned address 0x800031c7a413 for type 'const __uint16_t' which requires 2

Re: CVS commit: src/sys/arch

On Sun, Jul 08, 2018 at 04:49:51PM +0200, Kamil Rytarowski wrote: > On 08.07.2018 12:01, Martin Husemann wrote: > > > > This is unecessary churn for no good reason, please stop it. > > > > But worse are the other changes you are doing where kubsan insists on > > natural alignement for

Re: CVS commit: src/sys/arch/x86/x86

> On Jul 8, 2018, at 6:30 AM, Kamil Rytarowski wrote: > > In future __NO_STRICT_ALIGNMENT could be defined for aarch64, at least > for the use of acpica (which still contains a fallback for Itanium > without misaligned access, but not actively maintained). > > Linux uses a different approach

Re: CVS commit: src/sys/arch/x86/x86

On 08.07.2018 15:53, Jaromír Doleček wrote: > Le dim. 8 juil. 2018 à 15:29, Kamil Rytarowski a écrit : >> I've introduced the change to mpbios.c as it was small, selfcontained >> and without the need to decorate the whole function. > > Am I reading the code wrong or you actually introduced bug

Re: CVS commit: src/sys/arch/x86/x86

Le dim. 8 juil. 2018 à 15:29, Kamil Rytarowski a écrit : > I've introduced the change to mpbios.c as it was small, selfcontained > and without the need to decorate the whole function. Am I reading the code wrong or you actually introduced bug in mpbios.c? Shouldn't this: memtop |=

Re: CVS commit: src/sys/arch/x86/x86

On 08.07.2018 11:24, Martin Husemann wrote: > On Sun, Jul 08, 2018 at 10:49:53AM +0200, Jaromír Dole?ek wrote: >>> Module Name:src >>> Committed By: kamil >>> Date: Sat Jul 7 23:05:50 UTC 2018 >>> >>> Modified Files: >>> src/sys/arch/x86/x86: mpbios.c >>> >>> Log Message:

Re: CVS commit: src/sys/arch

On Sat, Jul 07, 2018 at 09:35:16PM +, Kamil Rytarowski wrote: > Module Name: src > Committed By: kamil > Date: Sat Jul 7 21:35:16 UTC 2018 > > Modified Files: > src/sys/arch/amd64/include: tss.h > src/sys/arch/i386/include: tss.h > > Log Message: > Correct unportable

Re: CVS commit: src/sys/kern

In article <8998.1530490...@splode.eterna.com.au>, matthew green wrote: >Jason Thorpe writes: >> >> >> > On Jul 1, 2018, at 2:48 AM, Martin Husemann wrote: >> > >> > I'd rather not have this at all - instead just drop the useless timestamps >> > at boot time, they are useless here and make

re: CVS commit: src/sys/kern

Jason Thorpe writes: > > > > On Jul 1, 2018, at 2:48 AM, Martin Husemann wrote: > > > > I'd rather not have this at all - instead just drop the useless timestamps > > at boot time, they are useless here and make console output unreadable. > > > > They are fine after mountroot, but is there

Re: CVS commit: src/sys/kern

> On Jul 1, 2018, at 2:48 AM, Martin Husemann wrote: > > I'd rather not have this at all - instead just drop the useless timestamps > at boot time, they are useless here and make console output unreadable. > > They are fine after mountroot, but is there really any use for them before? +1

Re: CVS commit: src/sys/kern

On Sat, Jun 30, 2018 at 10:47:51PM +, Taylor R Campbell wrote: > Module Name: src > Committed By: riastradh > Date: Sat Jun 30 22:47:51 UTC 2018 > > Modified Files: > src/sys/kern: kern_ntptime.c kern_tc.c > > Log Message: > Sprinkle cold conditionals to make tc_ticktock

Re: CVS commit: src/sys/dev/pci

On Thu, May 17, 2018 at 12:01:30PM -0500, Jonathan A. Kollasch wrote: > On Wed, May 16, 2018 at 01:45:36PM -0700, Jason Thorpe wrote: > > > > > > > On May 16, 2018, at 1:07 PM, Jonathan A. Kollasch > > > wrote: > > > > > > I'm a bit uneasy about it myself for that same

Re: CVS commit: src/sys/dev/pci

On Wed, May 16, 2018 at 01:45:36PM -0700, Jason Thorpe wrote: > > > > On May 16, 2018, at 1:07 PM, Jonathan A. Kollasch > > wrote: > > > > I'm a bit uneasy about it myself for that same reason. However, we > > do not to my knowledge have the infrastructure available to

Re: CVS commit: src/sys/dev/pci

> On May 16, 2018, at 1:07 PM, Jonathan A. Kollasch > wrote: > > I'm a bit uneasy about it myself for that same reason. However, we > do not to my knowledge have the infrastructure available to do a > complete validation of the resource assignment. If we did, we'd be

Re: CVS commit: src/sys/dev/pci

On Wed, May 16, 2018 at 12:50:22PM -0700, Jason Thorpe wrote: > > > > On May 16, 2018, at 12:02 PM, Jonathan A. Kollasch > > wrote: > > > > Module Name:src > > Committed By: jakllsch > > Date: Wed May 16 19:02:00 UTC 2018 > > > > Modified

Re: CVS commit: src/sys/dev/pci

> On May 16, 2018, at 12:02 PM, Jonathan A. Kollasch > wrote: > > Module Name: src > Committed By: jakllsch > Date: Wed May 16 19:02:00 UTC 2018 > > Modified Files: > src/sys/dev/pci: pci_map.c > > Log Message: > Enable the appropriate memory or I/O space

Re: CVS commit: src/sys/dev/acpi

On Mon, Dec 11, 2017 at 12:22:56AM +0100, Jaromír Dole?ek wrote: [in response to acpi_intr_establish() introduction] > Can we have acpi_intr_establish() accept the xname? It's very useful to > have the driver name registered for "intrctl list". The attached patch does it.

Re: CVS commit: src/sys/dev/scsipi

Hi, On 2017/06/19 23:16, Michael van Elst wrote: > k-nakah...@iij.ad.jp (Kengo NAKAHARA) writes: >> Today, I found my environment panic while rebooting. As bisecting, it >> seems the cause is below commit. > > Does the following patch help ? > > Index: scsipi_base.c >

Re: CVS commit: src/sys/dev/scsipi

k-nakah...@iij.ad.jp (Kengo NAKAHARA) writes: >Hi, >Today, I found my environment panic while rebooting. As bisecting, it >seems the cause is below commit. Does the following patch help ? Index: scsipi_base.c === RCS file:

Re: CVS commit: src/sys/dev/scsipi

Hi, Today, I found my environment panic while rebooting. As bisecting, it seems the cause is below commit. On 2017/06/18 7:35, Michael van Elst wrote: > Module Name: src > Committed By: mlelstv > Date: Sat Jun 17 22:35:50 UTC 2017 > > Modified Files: > src/sys/dev/scsipi:

Re: CVS commit: src/sys/sys

Date:Sat, 25 Feb 2017 18:13:34 +1100 From:matthew green Message-ID: <14043.1488006...@splode.eterna.com.au> | there's a rough ability to "guess" you have a matching kernel/kmem | groveller based upon the version. eg, crash(8) will notice a

re: CVS commit: src/sys/sys

> I'm evaluating it from the osabi (pkgsrc term) point of view. I'm > targeting LLDB for 7.99.62+. If the kernel bump approach is reserved for > loadable kernel modules, I will follow this in future changes. it's about whether code is expected to work in that kernel environment or not. it's not

Re: CVS commit: src/sys/sys

Date:Fri, 24 Feb 2017 19:24:34 +0800 (PHT) From:Paul Goyette Message-ID: | In many cases, one might just "ride the previous bump" Yes, I've seen that happen several times, but it would be

Re: CVS commit: src/sys/sys

On Fri, 24 Feb 2017, Robert Elz wrote: Date:Fri, 24 Feb 2017 09:04:36 +0100 From:Martin Husemann Message-ID: <20170224080436.gb1...@mail.duskware.de> | (and we already had a bump just a few hours earlier). It would indeed be useful if, when a

Re: CVS commit: src/sys/sys

Date:Fri, 24 Feb 2017 09:04:36 +0100 From:Martin Husemann Message-ID: <20170224080436.gb1...@mail.duskware.de> | (and we already had a bump just a few hours earlier). It would indeed be useful if, when a change that requires a kernel version

Re: CVS commit: src/sys/sys

On Thu, Feb 23, 2017 at 11:57:36PM +0100, Kamil Rytarowski wrote: > My bump was still legitimate as I changed size of amd64 and i386 struct > lwp - I removed one MD field. Yeah, that is all fine. I was just confused because the specific commit did not seem to want a bump, and while numbers are

Re: CVS commit: src/sys/sys

Date:Thu, 23 Feb 2017 23:57:36 +0100 From:Kamil Rytarowski Message-ID: | My bump was still legitimate as I changed size of amd64 and i386 struct | lwp - I removed one MD field. Yes, I agree, and said

Re: CVS commit: src/sys/sys

On 23.02.2017 09:48, Robert Elz wrote: > Date:Thu, 23 Feb 2017 15:32:16 +0800 (PHT) > From:Paul Goyette > Message-ID: > > | On Thu, 23 Feb 2017, Kamil Rytarowski wrote: > | > | > I'm

Re: CVS commit: src/sys/sys

Date:Thu, 23 Feb 2017 15:32:16 +0800 (PHT) From:Paul Goyette Message-ID: | On Thu, 23 Feb 2017, Kamil Rytarowski wrote: | | > I'm evaluating it from the osabi (pkgsrc term) point of

Re: CVS commit: src/sys/sys

On 23.02.2017 08:32, Paul Goyette wrote: > On Thu, 23 Feb 2017, Kamil Rytarowski wrote: > >> I'm evaluating it from the osabi (pkgsrc term) point of view. I'm >> targeting LLDB for 7.99.62+. If the kernel bump approach is reserved for >> loadable kernel modules, I will follow this in future

Re: CVS commit: src/sys/sys

On Thu, 23 Feb 2017, Kamil Rytarowski wrote: I'm evaluating it from the osabi (pkgsrc term) point of view. I'm targeting LLDB for 7.99.62+. If the kernel bump approach is reserved for loadable kernel modules, I will follow this in future changes. Modules (and specifically, their interfaces to

Re: CVS commit: src/sys/sys

On 23.02.2017 07:23, Robert Elz wrote: > Date:Thu, 23 Feb 2017 05:29:41 + > From:Martin Husemann > Message-ID: <20170223052941.ga29...@homeworld.netbsd.org> > > | Does this kind of change really require a version bump? > > That one didn't,

Re: CVS commit: src/sys/sys

Date:Thu, 23 Feb 2017 05:29:41 + From:Martin Husemann Message-ID: <20170223052941.ga29...@homeworld.netbsd.org> | Does this kind of change really require a version bump? That one didn't, but there was another checkin, 5 or 6 mins earlier,

Re: CVS commit: src/sys/sys

On Thu, Feb 23, 2017 at 03:48:20AM +, Kamil Rytarowski wrote: > Module Name: src > Committed By: kamil > Date: Thu Feb 23 03:48:20 UTC 2017 > > Modified Files: > src/sys/sys: param.h > > Log Message: > Welcome to 7.99.62! > > New ptrace(2) operations: > - PT_RESUME > -

Re: CVS commit: src/sys/dev/pci

On Tue, Nov 29, 2016 at 21:54:11 +, Valeriy E. Ushakov wrote: > Module Name: src > Committed By: uwe > Date: Tue Nov 29 21:54:11 UTC 2016 > > Modified Files: > src/sys/dev/pci: if_vioif.c > > Log Message: > vioif_start() - do not call virtio_enqueue_abort() after error from >

Re: CVS commit: src/sys/arch

On Fri, Sep 23, 2016 at 09:33:36PM +0200, Jaromír Dole?ek wrote: > Hey Maxime, > > Seems the KASSERTs() are too aggressive, or there is some other bug. > > I can trigger the kassert by simply attaching to rump_ffs, setting a > breakpoint and continuing, i.e: > > > rump_ffs -o log ./ffs ./mnt >

Re: CVS commit: src/sys/arch

Hey Maxime, Seems the KASSERTs() are too aggressive, or there is some other bug. I can trigger the kassert by simply attaching to rump_ffs, setting a breakpoint and continuing, i.e: > rump_ffs -o log ./ffs ./mnt > gdb rump_ffs ... (gdb) attach RUMP_PID (gdb) break ffs_truncate Breakpoint 1 at

Re: CVS commit: src/sys

On Sun, 18 Sep 2016, Jaromír Dole�~Mek wrote: Thanks for looking at this, Paul. Please hold on with commits though. I'm finishing MP fixes for nvme(4) and I want to commit the code on Sunday afternoon (GMT-2). That set also includes fix for to the module attachment to also attach nvme cdevsw

Re: CVS commit: src/sys

Thanks for looking at this, Paul. Please hold on with commits though. I'm finishing MP fixes for nvme(4) and I want to commit the code on Sunday afternoon (GMT-2). That set also includes fix for to the module attachment to also attach nvme cdevsw (to make nvmectl work). I'll look on your patches

Re: CVS commit: src/sys

(Redirecting to tech-kern, and moving source-changes-d to bcc) The attached diffs make a first pass at dealing with this mess. It creates two new modules (ld common code, and ld_nvme attach specific), and updates the sets lists as appropriate. It also modifies the nvme code to be able to

Re: CVS commit: src/sys

On 07/20/16 08:38, Martin Husemann wrote: On Wed, Jul 20, 2016 at 12:42:47PM +0900, Ryota Ozaki wrote: If we cannot fix the issue easily, we can disable workqueue unless NET_MPSAFE for now. I think it is only exposing some older mips bug, we should analyze it (but I am currently out of ideas).

Re: CVS commit: src/sys

On Wed, Jul 20, 2016 at 12:42:47PM +0900, Ryota Ozaki wrote: > If we cannot fix the issue easily, we can disable workqueue unless > NET_MPSAFE for now. I think it is only exposing some older mips bug, we should analyze it (but I am currently out of ideas). Martin

Re: CVS commit: src/sys

On Fri, Jul 15, 2016 at 6:18 PM, Martin Husemann wrote: > On Fri, Jul 15, 2016 at 09:51:09AM +0900, Ryota Ozaki wrote: >> Does NFS root matter? > > Not sure, Nick says his ERLITE still boots (where NFS root would be the > only obvious difference), but his Cobalt is not using

Re: CVS commit: src/sys

On Fri, Jul 15, 2016 at 09:51:09AM +0900, Ryota Ozaki wrote: > Does NFS root matter? Not sure, Nick says his ERLITE still boots (where NFS root would be the only obvious difference), but his Cobalt is not using NFS root. I do not see the issue on ARM machines with NFS root. Martin

Re: CVS commit: src/sys

On Fri, Jul 15, 2016 at 4:20 AM, Martin Husemann wrote: >> > >> Modified Files: >> > >> src/sys/net: route.c >> > >> src/sys/netinet: ip_flow.c >> > >> src/sys/netinet6: ip6_flow.c nd6.c > > It is specifically the route.c change, backing that one out avoids the > problem

Re: CVS commit: src/sys

> > >> Modified Files: > > >> src/sys/net: route.c > > >> src/sys/netinet: ip_flow.c > > >> src/sys/netinet6: ip6_flow.c nd6.c It is specifically the route.c change, backing that one out avoids the problem for me. I would suggest this patch: Index: route.c

Re: CVS commit: src/sys

In article <20160714105820.ga16...@homeworld.netbsd.org>, Martin Husemann wrote: >On Mon, Jul 11, 2016 at 07:37:00AM +, Ryota Ozaki wrote: >> Module Name: src >> Committed By:ozaki-r >> Date:Mon Jul 11 07:37:00 UTC 2016 >> >> Modified Files: >>

Re: CVS commit: src/sys

Hello, On Thu, 14 Jul 2016 13:22:06 +0100 Nick Hudson wrote: > On 07/14/16 11:58, Martin Husemann wrote: > > On Mon, Jul 11, 2016 at 07:37:00AM +, Ryota Ozaki wrote: > >> Module Name: src > >> Committed By: ozaki-r > >> Date: Mon Jul 11 07:37:00 UTC

Re: CVS commit: src/sys

On 07/14/16 11:58, Martin Husemann wrote: On Mon, Jul 11, 2016 at 07:37:00AM +, Ryota Ozaki wrote: Module Name:src Committed By: ozaki-r Date: Mon Jul 11 07:37:00 UTC 2016 Modified Files: src/sys/net: route.c src/sys/netinet: ip_flow.c

  1   2   3   >