Hans Rosenfeld writes:
> I fully agree with you on what DIAGNOSTIC should do, and what it shouldn't.
> In particular, if there's a check for an unexpected situation that's
> only there in DIAGNOSTIC kernels, it shouldn't handle these situations
> gracefully where the non-DIAGNOSTIC code path woul
Hi Greg,
On Sun, Mar 23, 2025 at 08:31:14AM -0400, Greg Troxel wrote:
> "Hans Rosenfeld" writes:
>
> > Module Name:src
> > Committed By: hans
> > Date: Sun Mar 23 12:19:32 UTC 2025
> >
> > Modified Files:
> > src/sys/dev/wscons: wsmouse.c
> >
> > Log Message:
> >
"Hans Rosenfeld" writes:
> Module Name: src
> Committed By: hans
> Date: Sun Mar 23 12:19:32 UTC 2025
>
> Modified Files:
> src/sys/dev/wscons: wsmouse.c
>
> Log Message:
> wsmouse(4): fix bogus DIAGNOSTIC checks
>
> Similar to wskbd(4), these checks should be done always, and the
Date:Wed, 22 Jan 2025 15:03:36 +0100
From:Christoph Badura
Message-ID: <20250122140336.gb17...@irregular-apocalypse.k.bsd.de>
No comment on why the change happened in the first place, but:
| The followup commit by kre partiallly undid the change for "rump and
| a
> Date: Wed, 22 Jan 2025 15:03:36 +0100
> From: Christoph Badura
>
> So, I don't understand this changes and the followup change by kre.
>
> Why, exactly, do we need "a more secure random generator" to randomly drop
> packets from a queue? What was the actual complaint by coverity and why
> was
So, I don't understand this changes and the followup change by kre.
Why, exactly, do we need "a more secure random generator" to randomly drop
packets from a queue? What was the actual complaint by coverity and why
wasn't it a false positive?
The followup commit by kre partiallly undid the chang
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 t
September 26, 2023 at 6:25 AM, "Robert Elz" wrote:
>
> Date: Sun, 17 Sep 2023 20:07:39 +
> From: "Greg Oster"
> Message-ID: <20230917200739.b9dadf...@cvs.netbsd.org>
>
> | Implement hot removal of spares and components. From manu@.
> |
> | Implement a long desired feature of automati
Date:Sun, 17 Sep 2023 20:07:39 +
From:"Greg Oster"
Message-ID: <20230917200739.b9dadf...@cvs.netbsd.org>
| Implement hot removal of spares and components. From manu@.
|
| Implement a long desired feature of automatically incorporating
| a used spare into
On Mon, Sep 11, 2023 at 03:29:39PM +, Martin Husemann wrote:
> On Sun, Sep 10, 2023 at 02:45:53PM +, Andrew Doran wrote:
> > Module Name:src
> > Committed By: ad
> > Date: Sun Sep 10 14:45:53 UTC 2023
> >
> > Modified Files:
> > src/common/lib/libc/gen: rad
Hi ad@,
Good to see you again!
On Tue, Sep 12, 2023 at 12:29 AM Martin Husemann wrote:
>
> On Sun, Sep 10, 2023 at 02:45:53PM +, Andrew Doran wrote:
> > Module Name: src
> > Committed By: ad
> > Date: Sun Sep 10 14:45:53 UTC 2023
> >
> > Modified Files:
> > src/common/lib/libc
On Sun, Sep 10, 2023 at 02:45:53PM +, Andrew Doran wrote:
> Module Name: src
> Committed By: ad
> Date: Sun Sep 10 14:45:53 UTC 2023
>
> Modified Files:
> src/common/lib/libc/gen: radixtree.c
> src/sys/kern: init_main.c kern_descrip.c kern_lwp.c kern_mutex_obj.c
>
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 type
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: syzbot
On Wed, Oct 21, 2020 at 08:58:36AM +0900, Rin Okuyama wrote:
> I'm also one who feels hesitate to import Linux'ism into our basic
> components. However, for this problem in particular, I still think
> it is not a good choice to keep NetBSD support in driver-aarch64.c:
>
> (a) Our sysctl(3)-based i
Hi,
(tech-toolchain@ added to cc)
On 2020/10/16 1:49, Kamil Rytarowski wrote:
On 15.10.2020 17:14, Rin Okuyama wrote:
On 2020/10/15 16:12, matthew green wrote:
Martin Husemann writes:
On Thu, Oct 15, 2020 at 05:28:12PM +1100, matthew green wrote:
you could try reverting most of our changes t
Date:Fri, 16 Oct 2020 04:07:31 +
From:"Thomas Mueller"
Message-ID: <20201016052422.e063084...@mail.netbsd.org>
| Should I add ,linux to the end of the procfs line?
You can, but it isn't needed these days -- I used to mount procfs twice,
once without the linux o
Excerpt from Rin Okuyama:
> Nowadays, -o linux is turned on by default (unless nolinux is
> specified explicitly). Still, native apps probably should not
> depend on it.
> This needs MI changes to procfs, not MD to aarch64. Should we
> enable /proc/cpuinfo unconditionally?
My NetBSD sys
On 15.10.2020 17:14, Rin Okuyama wrote:
> On 2020/10/15 16:12, matthew green wrote:
>> Martin Husemann writes:
>>> On Thu, Oct 15, 2020 at 05:28:12PM +1100, matthew green wrote:
you could try reverting most of our changes to this file and
making sure you run with /proc mounted -o linux.
On 2020/10/15 16:12, matthew green wrote:
Martin Husemann writes:
On Thu, Oct 15, 2020 at 05:28:12PM +1100, matthew green wrote:
you could try reverting most of our changes to this file and
making sure you run with /proc mounted -o linux. ryo@ recently
added additional /proc/cpuinfo support th
> 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
> di
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
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
>> s
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: sys_pt
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 place
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, bu
On Sun, Sep 15, 2019 at 08:34:18AM +0200, 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. Then we should also
> adjust what dkwedge_print_wnames() prints, currently it uses the wedge:
> prefix. It is ca
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 comm
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
bootloade
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 parameters
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?
--- sys/kern/kern_s
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
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 act
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 branch
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 dif
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 fr
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 ehci(4
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:
> > > > > Hi
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 tra
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), mue
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 mod
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 are
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 tha
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 are successfully built with DIAGNOSTIC.
I'd like to commit the p
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 modu
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 me
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 wo
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
usbd_a
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 rem
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
=
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
> 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 al
> 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
> | 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 __aligned(XHCI_TRB_A
On Sun, Jan 06, 2019 at 05:26:36PM -0500, 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?
Doesn't help if malloc will just return 64bit aligned memory.
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
> 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 {
...
} __
> 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
uyama
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
, 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
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 proceed:
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
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". No
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 context
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
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 undefine
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 wha
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").
>>> 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
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 fo
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 ma
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 byt
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 {u,}int_{16
> 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
On 08.07.2018 12:01, Martin Husemann wrote:
> 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
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 in
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 |= (uint16_t)mpb
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:
>
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 sig
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 co
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 rea
> 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
--
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 before
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 reason. However, we
> >
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 do a
> > complete valid
> 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
> able to do hot attach
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 Files:
> > src/sys/dev
> 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 decode in the PCI
> C
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.
AcpiOsInstallInterruptHan
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
> ===
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: /cvsroot
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: atapicon
Le 10/03/2017 à 19:01, Valery Ushakov a écrit :
On Fri, Mar 10, 2017 at 13:09:11 +, Maxime Villard wrote:
Module Name:src
Committed By: maxv
Date: Fri Mar 10 13:09:11 UTC 2017
Modified Files:
src/sys/arch/i386/i386: pmc.c
src/sys/arch/x86/include: sysarch.h
On Fri, Mar 10, 2017 at 13:09:11 +, Maxime Villard wrote:
> Module Name: src
> Committed By: maxv
> Date: Fri Mar 10 13:09:11 UTC 2017
>
> Modified Files:
> src/sys/arch/i386/i386: pmc.c
> src/sys/arch/x86/include: sysarch.h
> src/usr.bin/pmc: pmc.1 pmc.c
>
> Log M
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
| mismatch and tell y
> | * changes to things that kmem grovelers chase
>
> I don't think kernel version bumps really help there either - for those
> I think it is normal just to expect that a kmem groveller (of which there
> are not many left, fortunately) might need to match the kernel version if
> it is to be expe
> 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 j
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 much nicer
to predict the bump, than to react to it.
kre
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 change that requires a
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
change is expected to
1 - 100 of 377 matches
Mail list logo
