On 2019/12/27 1:55, Emmanuel Dreyfus wrote:
> On Wed, Dec 25, 2019 at 05:05:11PM +0900, Masanobu SAITOH wrote:
After this change, amd64 kernel does not boot on my HP Spectre x360
13-inch ae019TU laptop with pure UEFI boot mode.
>> I have a UEFI boot machine and it also doesn't boot
On Wed, Dec 25, 2019 at 05:05:11PM +0900, Masanobu SAITOH wrote:
> >> After this change, amd64 kernel does not boot on my HP Spectre x360
> >> 13-inch ae019TU laptop with pure UEFI boot mode.
> I have a UEFI boot machine and it also doesn't boot well.
Please try the attached patch.
It adds the
On Wed, Dec 25, 2019 at 05:05:11PM +0900, Masanobu SAITOH wrote:
> - It hangs after attaching ioapic0, cpu0 or acpi0 (or something else).
>The possibility is about 65%
What is the backtace? Does it goes through svs_init?
--
Emmanuel Dreyfus
m...@netbsd.org
On Dec 23, 3:06pm, Warner Losh wrote:
} On Mon, Dec 23, 2019, 2:37 PM Kamil Rytarowski wrote:
} > On 23.12.2019 18:14, Greg Troxel wrote:
} > > Warner Losh writes:
} > >
} > >> Just a quick note: when FreeBSD when from 9 to 10, we had to play 'hunt
} > the
} > >> wumpus' for all the autoconfig
Sorry for confusing.
My attached patch does not improve my situation.
My mail is mistake. Sorry.
Reverting linker script fixes the kernel boot.
Thank you.
On December 26, 2019 1:23:34 AM GMT+09:00, Emmanuel Dreyfus
wrote:
>On Wed, Dec 25, 2019 at 07:42:47PM +0900, Ryo ONODERA wrote:
>> The
On Wed, Dec 25, 2019 at 07:42:47PM +0900, Ryo ONODERA wrote:
> The attached patch works for me.
> However I have no idea about the meaning.
It changes the multiboot section from DATA to CODE, which is
odd but perfectly fine. I cannot understand how it can change
the situation, though. Did it
Hi,
Sorry I have accidentally reverted kern.ldscript.
With current kern.ldscript, it stalls after cpu0.
Thank you.
Ryo ONODERA writes:
> Hi,
>
> Emmanuel Dreyfus writes:
>
>> On Tue, Dec 24, 2019 at 05:50:00PM +0900, Ryo ONODERA wrote:
>>> After this change, amd64 kernel does not boot on my
Hi,
Emmanuel Dreyfus writes:
> On Tue, Dec 24, 2019 at 05:50:00PM +0900, Ryo ONODERA wrote:
>> After this change, amd64 kernel does not boot on my HP Spectre x360
>> 13-inch ae019TU laptop with pure UEFI boot mode.
>
> Hello
>
> Does the attached patch (crafted for port-amd64/54775) fix the
>
On 2019/12/25 17:05, Masanobu SAITOH wrote:
> On 2019/12/24 23:47, Emmanuel Dreyfus wrote:
>> On Tue, Dec 24, 2019 at 05:50:00PM +0900, Ryo ONODERA wrote:
>>> After this change, amd64 kernel does not boot on my HP Spectre x360
>>> 13-inch ae019TU laptop with pure UEFI boot mode.
>
> I have a
On 2019/12/24 23:47, Emmanuel Dreyfus wrote:
> On Tue, Dec 24, 2019 at 05:50:00PM +0900, Ryo ONODERA wrote:
>> After this change, amd64 kernel does not boot on my HP Spectre x360
>> 13-inch ae019TU laptop with pure UEFI boot mode.
I have a UEFI boot machine and it also doesn't boot well.
- It
On Mon, Dec 23, 2019, 2:37 PM Kamil Rytarowski wrote:
> On 23.12.2019 18:14, Greg Troxel wrote:
> > Warner Losh writes:
> >
> >> Just a quick note: when FreeBSD when from 9 to 10, we had to play 'hunt
> the
> >> wumpus' for all the autoconfig scripts that suddenly thought they were
> >>
Warner Losh writes:
> Just a quick note: when FreeBSD when from 9 to 10, we had to play 'hunt the
> wumpus' for all the autoconfig scripts that suddenly thought they were
> configuring for FreeBSD 1.0.
>
> If you can arrange it, it might make sense to do a pkgsrc run on an
> experimental system
On 23.12.2019 18:14, Greg Troxel wrote:
> Warner Losh writes:
>
>> Just a quick note: when FreeBSD when from 9 to 10, we had to play 'hunt the
>> wumpus' for all the autoconfig scripts that suddenly thought they were
>> configuring for FreeBSD 1.0.
>>
>> If you can arrange it, it might make
On Mon, Dec 23, 2019 at 9:33 AM Greg Troxel wrote:
> Martin Husemann writes:
>
> > On Mon, Dec 23, 2019 at 09:02:50AM -0500, Greg Troxel wrote:
> >> Well, we are coming up on a year since netbsd-9 was branched, or at
> >> least will arrive there before this discussion resolves. So cutting
>
On Tue, Dec 24, 2019 at 03:22:54AM +, Taylor R Campbell wrote:
> > Module Name:src
> > Committed By: ad
> > Date: Sat Dec 21 14:41:44 UTC 2019
> >
> > - Add inlines to set/get locator values in the unused lower bits of
> > pg->phys_addr. Begin by using it to cache the
On Tue, Dec 24, 2019 at 05:50:00PM +0900, Ryo ONODERA wrote:
> After this change, amd64 kernel does not boot on my HP Spectre x360
> 13-inch ae019TU laptop with pure UEFI boot mode.
Hello
Does the attached patch (crafted for port-amd64/54775) fix the
problem?
--
Emmanuel Dreyfus
Hi,
"Emmanuel Dreyfus" writes:
> Module Name: src
> Committed By: manu
> Date: Sun Dec 15 02:56:40 UTC 2019
>
> Modified Files:
> src/sys/arch/amd64/amd64: locore.S
> src/sys/arch/amd64/conf: kern.ldscript
>
> Log Message:
> Restore multiboot 2 header in amd64 kernel
>
>
Hi,
"Jason R Thorpe" writes:
> Module Name: src
> Committed By: thorpej
> Date: Sun Dec 22 16:44:35 UTC 2019
>
> Modified Files:
> src/sys/dev/i2c: ihidev.c ihidev.h
>
> Log Message:
> The hid-over-i2c spec specifies that compliant devices use level-sensitive
> interrupts.
> On Dec 23, 2019, at 7:53 PM, Taylor R Campbell
> wrote:
>
>> Module Name:src
>> Committed By: thorpej
>> Date: Sun Dec 22 15:09:39 UTC 2019
>>
>> Add intr_mask() and corresponding intr_unmask() calls that allow specific
>> interrupt lines / sources to be masked as needed
> Module Name:src
> Committed By: thorpej
> Date: Sun Dec 22 15:09:39 UTC 2019
>
> Add intr_mask() and corresponding intr_unmask() calls that allow specific
> interrupt lines / sources to be masked as needed (rather than making a
> set of sources by IPL as with spl*()).
>
> +
> On Dec 23, 2019, at 7:22 PM, Taylor R Campbell
> wrote:
>
> So I guess we won't be switching pg->phys_addr from paddr to pfn?
If that's the case, we should rename the field.
-- thorpej
> Module Name:src
> Committed By: ad
> Date: Sat Dec 21 14:41:44 UTC 2019
>
> - Add inlines to set/get locator values in the unused lower bits of
> pg->phys_addr. Begin by using it to cache the freelist index, because
> computing it is expensive and that shows up during
On Dec 23, 11:33am, Greg Troxel wrote:
} Martin Husemann writes:
} > On Mon, Dec 23, 2019 at 09:02:50AM -0500, Greg Troxel wrote:
} >> Well, we are coming up on a year since netbsd-9 was branched, or at
} >> least will arrive there before this discussion resolves. So cutting
} >> -10 before we
Martin Husemann writes:
> On Mon, Dec 23, 2019 at 09:02:50AM -0500, Greg Troxel wrote:
>> Well, we are coming up on a year since netbsd-9 was branched, or at
>> least will arrive there before this discussion resolves. So cutting
>> -10 before we hit 100 works for me :-)
>
> Nitpicking (and I
On 23.12.2019 16:57, Martin Husemann wrote:
> On Mon, Dec 23, 2019 at 09:02:50AM -0500, Greg Troxel wrote:
>> Well, we are coming up on a year since netbsd-9 was branched, or at
>> least will arrive there before this discussion resolves. So cutting
>> -10 before we hit 100 works for me :-)
>
>
On Mon, Dec 23, 2019 at 09:02:50AM -0500, Greg Troxel wrote:
> Well, we are coming up on a year since netbsd-9 was branched, or at
> least will arrive there before this discussion resolves. So cutting
> -10 before we hit 100 works for me :-)
Nitpicking (and I don't know for the discussion
Kamil Rytarowski writes:
> On 23.12.2019 01:54, Roy Marples wrote:
>> On 22/12/2019 22:24, Andrew Doran wrote:
>>> NetBSD 9.99.29 - struct mount changed.
>>
>> Just curious - does our build software cope with 3 digit for the last
>> number?
>>
>> Roy
>
> At least from the __NetBSD_Version__
On 23.12.2019 01:54, Roy Marples wrote:
> On 22/12/2019 22:24, Andrew Doran wrote:
>> NetBSD 9.99.29 - struct mount changed.
>
> Just curious - does our build software cope with 3 digit for the last
> number?
>
> Roy
At least from the __NetBSD_Version__ point of view there are 4 digits
unused,
Roy Marples wrote:
> On 22/12/2019 22:24, Andrew Doran wrote:
> > NetBSD 9.99.29 - struct mount changed.
>
> Just curious - does our build software cope with 3 digit for the last number?
https://twitter.com/needydev/status/1205585787095519234?s=20
--
Alex
On 22/12/2019 22:24, Andrew Doran wrote:
NetBSD 9.99.29 - struct mount changed.
Just curious - does our build software cope with 3 digit for the last number?
Roy
On 22.12.2019 23:27, Andrew Doran wrote:
> On Sat, Dec 21, 2019 at 05:23:23PM +, Alexander Nasonov wrote:
>
>> Andrew Doran wrote:
>>> Log Message:
>>> NetBSD 9.99.28 - cpu_data & UVM changes.
>>
>> Wow, you bump versions faster than I compile new releases. At this
>> pace, we'll get to
On Sat, Dec 21, 2019 at 05:23:23PM +, Alexander Nasonov wrote:
> Andrew Doran wrote:
> > Log Message:
> > NetBSD 9.99.28 - cpu_data & UVM changes.
>
> Wow, you bump versions faster than I compile new releases. At this
> pace, we'll get to 9.99.99 in a month or two ;-)
There are quite a few
Hi Joerg,
On Sun, Dec 22, 2019 at 01:27:44AM +0100, Joerg Sonnenberger wrote:
> On Fri, Dec 20, 2019 at 09:05:34PM +, Andrew Doran wrote:
> > Module Name:src
> > Committed By: ad
> > Date: Fri Dec 20 21:05:34 UTC 2019
> >
> > Modified Files:
> >
On Fri, Dec 20, 2019 at 09:05:34PM +, Andrew Doran wrote:
> Module Name: src
> Committed By: ad
> Date: Fri Dec 20 21:05:34 UTC 2019
>
> Modified Files:
> src/sys/arch/aarch64/aarch64: cpu.c cpufunc.c
> src/sys/arch/arm/arm32: arm32_boot.c cpu.c
>
Andrew Doran wrote:
> Log Message:
> NetBSD 9.99.28 - cpu_data & UVM changes.
Wow, you bump versions faster than I compile new releases. At this
pace, we'll get to 9.99.99 in a month or two ;-)
--
Alex
On Sat, Dec 21, 2019 at 03:08:18PM +0100, Christoph Badura wrote:
> On Sat, Dec 21, 2019 at 12:58:26PM +, Andrew Doran wrote:
> > Modified Files:
> > src/sys/uvm: uvm_extern.h uvm_page.c
> > Log Message:
> > Add uvm_free(): returns number of free pages in system.
>
> Can you rename this
On Sat, Dec 21, 2019 at 12:58:26PM +, Andrew Doran wrote:
> Modified Files:
> src/sys/uvm: uvm_extern.h uvm_page.c
> Log Message:
> Add uvm_free(): returns number of free pages in system.
Can you rename this to a more descriptive name? Say uvm_free_pages() or
something.
Also, we
> On 15. Dec 2019, at 21:30, Joerg Sonnenberger wrote:
>
> Module Name: src
> Committed By: joerg
> Date: Sun Dec 15 20:30:56 UTC 2019
>
> Modified Files:
> src/sys/miscfs/nullfs: null_vfsops.c
>
> Log Message:
> Set IMNT_MPSAFE before creating the vnode for the root of the
>
On Tue, Dec 03, 2019 at 05:01:45AM +, Taylor R Campbell wrote:
> Module Name: src
> Committed By: riastradh
> Date: Tue Dec 3 05:01:45 UTC 2019
>
> Modified Files:
> src/sys/dev/usb: usbnet.c
>
> Log Message:
> Fix order of nulling un->un_pri->unp_ec.ec_mii.
>
> Can't null
Le 12/12/2019 à 10:20, Maxime Villard a écrit :
Le 10/12/2019 à 03:06, Emmanuel Dreyfus a écrit :
Module Name: src
Committed By: manu
Date: Tue Dec 10 02:06:07 UTC 2019
Modified Files:
src/sys/arch/amd64/amd64: locore.S machdep.c
src/sys/arch/amd64/conf: GENERIC
> Therefore, I wouldn't bother adding kcov.h headers, and rolling back to the
> previous version of in_interrupt for now is fine, considering that kcov
> currently has no use outside of amd64.
if you want to put code in sys/kern please make it portable.
adding more MD code in MI places is the
Le 10/12/2019 à 03:06, Emmanuel Dreyfus a écrit :
Module Name:src
Committed By: manu
Date: Tue Dec 10 02:06:07 UTC 2019
Modified Files:
src/sys/arch/amd64/amd64: locore.S machdep.c
src/sys/arch/amd64/conf: GENERIC files.amd64 kern.ldscript
Le 08/12/2019 à 14:22, Martin Husemann a écrit :
On Sun, Dec 08, 2019 at 12:58:20PM +0100, Maxime Villard wrote:
kMSan has special constraints which, in this specific case, come down to: each
function called from a KCOV instrumentation callback must be a static inline
tagged with __nomsan.
> > > Log Message:
> > > Expunge the panicstr checks, we don't need them.
> >
> > can you explain why?
>
> Sure, [ .. ]
ah, wow. i didn't realise it had such a bad effect on cpus before
they actually go properly down.
we should probably work hard to make them go down faster if possible,
Paul Goyette wrote:
> This commit seems to have broken amd64 booting! When booting into
> a qemu environment (as set up by misc/py-anita), it just hangs while
> printing the "progress numbers with the spinny cursor". Others on
> irc/icb have indicated an immediate crash.
I rolled back the
On Wed, Dec 11, 2019 at 09:06:33AM +1100, matthew green wrote:
> "Andrew Doran" writes:
> > Module Name:src
> > Committed By: ad
> > Date: Mon Dec 9 21:02:10 UTC 2019
> >
> > Modified Files:
> > src/sys/kern: kern_rwlock.c
> >
> > Log Message:
> > Expunge the
Paul Goyette wrote:
> This commit seems to have broken amd64 booting! When booting into
> a qemu environment (as set up by misc/py-anita), it just hangs while
> printing the "progress numbers with the spinny cursor". Others on
> irc/icb have indicated an immediate crash.
>
> Seems like
"Andrew Doran" writes:
> Module Name: src
> Committed By: ad
> Date: Mon Dec 9 21:02:10 UTC 2019
>
> Modified Files:
> src/sys/kern: kern_rwlock.c
>
> Log Message:
> Expunge the panicstr checks, we don't need them.
can you explain why? what sort of crash-time testing did
you
This commit seems to have broken amd64 booting! When booting into
a qemu environment (as set up by misc/py-anita), it just hangs while
printing the "progress numbers with the spinny cursor". Others on
irc/icb have indicated an immediate crash.
Seems like non-efi booting is borked.
Module
> On Dec 9, 2019, at 1:08 PM, Paul Goyette wrote:
>
> On Mon, 9 Dec 2019, Andrew Doran wrote:
>
>> Module Name: src
>> Committed By:ad
>> Date:Mon Dec 9 21:05:23 UTC 2019
>>
>> Modified Files:
>> src/sys/kern: kern_mutex.c
>>
>> Log Message:
>> - Add a
On Mon, 9 Dec 2019, Andrew Doran wrote:
Module Name:src
Committed By: ad
Date: Mon Dec 9 21:05:23 UTC 2019
Modified Files:
src/sys/kern: kern_mutex.c
Log Message:
- Add a mutex_owner_running() for the benefit of the pagedaemon, which
needs help with locking things in
On Sun, Dec 08, 2019 at 12:58:20PM +0100, Maxime Villard wrote:
> kMSan has special constraints which, in this specific case, come down to: each
> function called from a KCOV instrumentation callback must be a static inline
> tagged with __nomsan.
>
> This was not the case with the updated
Le 08/12/2019 à 00:51, Kamil Rytarowski a écrit :
On 08.12.2019 00:35, matthew green wrote:
Module Name:src
Committed By: kamil
Date: Sat Dec 7 19:50:34 UTC 2019
Modified Files:
src/sys/kern: subr_kcov.c
Log Message:
Revert the in_interrupt() change to use again the
On 08.12.2019 00:35, matthew green wrote:
>> Module Name: src
>> Committed By:kamil
>> Date:Sat Dec 7 19:50:34 UTC 2019
>>
>> Modified Files:
>> src/sys/kern: subr_kcov.c
>>
>> Log Message:
>> Revert the in_interrupt() change to use again the x86 specific code
>>
>>
> Module Name: src
> Committed By: kamil
> Date: Sat Dec 7 19:50:34 UTC 2019
>
> Modified Files:
> src/sys/kern: subr_kcov.c
>
> Log Message:
> Revert the in_interrupt() change to use again the x86 specific code
>
> This is prerequisite for kMSan and upcoming kernel changes.
>
This is experimental: we use l_cpu to mean a number of things and this
involves changing it to a different value than curcpu() in a running LWP,
which we have not done before. I'll see about making it more robust.
Andrew
On Fri, Dec 06, 2019 at 09:36:11PM +, Andrew Doran wrote:
> Module
On Sat, Dec 07, 2019 at 07:12:10AM +1100, matthew green wrote:
> > > > Why? I consider this totaly useless bloat, what was wrong with the
> > > > boot.cfg
> > > > solution?
> > >
> > > policy: no default modules in the installation unless licenses
> > > issues force such, until module+kernel
> > > Why? I consider this totaly useless bloat, what was wrong with the
> > > boot.cfg
> > > solution?
> >
> > policy: no default modules in the installation unless licenses
> > issues force such, until module+kernel solution.
>
> OK, but this is gone awry. The boot.cfg solution is great if
On Fri, 6 Dec 2019, Martin Husemann wrote:
On Sat, Dec 07, 2019 at 06:30:55AM +1100, matthew green wrote:
Why? I consider this totaly useless bloat, what was wrong with the boot.cfg
solution?
policy: no default modules in the installation unless licenses
issues force such, until
On Sat, Dec 07, 2019 at 06:30:55AM +1100, matthew green wrote:
> > Why? I consider this totaly useless bloat, what was wrong with the boot.cfg
> > solution?
>
> policy: no default modules in the installation unless licenses
> issues force such, until module+kernel solution.
OK, but this is gone
Martin Husemann writes:
> On Thu, Dec 05, 2019 at 10:05:05PM +, Sevan Janiyan wrote:
> > Module Name:src
> > Committed By: sevan
> > Date: Thu Dec 5 22:05:05 UTC 2019
> >
> > Modified Files:
> > src/sys/arch/amd64/conf: GENERIC
> > src/sys/arch/i386/conf:
On Thu, Dec 05, 2019 at 10:05:05PM +, Sevan Janiyan wrote:
> Module Name: src
> Committed By: sevan
> Date: Thu Dec 5 22:05:05 UTC 2019
>
> Modified Files:
> src/sys/arch/amd64/conf: GENERIC
> src/sys/arch/i386/conf: GENERIC
>
> Log Message:
> Enable pciverbose option
Le 06/12/2019 à 08:49, m...@netbsd.org a écrit :
> On Fri, Dec 06, 2019 at 07:27:07AM +, Maxime Villard wrote:
>> Log Message:
>> Minor changes, reported by the LGTM bot.
>
> Would be nice if the commit message was "address some integer overflows"
> or something.
Except that it does not
On Fri, Dec 06, 2019 at 07:27:07AM +, Maxime Villard wrote:
> Log Message:
> Minor changes, reported by the LGTM bot.
Would be nice if the commit message was "address some integer overflows"
or something.
> @@ -2205,7 +2205,7 @@ m_verify_packet(struct mbuf *m)
>
> dat =
On 2019/12/05 14:29, SAITOH Masanobu wrote:
> Module Name: src
> Committed By: msaitoh
> Date: Thu Dec 5 05:29:28 UTC 2019
>
> Modified Files:
> src/sys/net: if_media.h
>
> Log Message:
> Fix previous comment change for ifm_media. It was correct.
>
> The real problem is that
Le 01/12/2019 à 16:27, Andrew Doran a écrit :
Module Name:src
Committed By: ad
Date: Sun Dec 1 15:27:58 UTC 2019
Modified Files:
src/sys/kern: kern_lwp.c
Log Message:
Fix a longstanding problem with LWP limits. When changing the user's
LWP count, we must use the
On Tue, Dec 03, 2019 at 01:14:14PM +0100, Kamil Rytarowski wrote:
> On 03.12.2019 12:50, Juergen Hannken-Illjes wrote:
> > Module Name:src
> > Committed By: hannken
> > Date: Tue Dec 3 11:50:45 UTC 2019
> >
> > Modified Files:
> > src/sys/arch/x86/x86:
On 03.12.2019 12:50, Juergen Hannken-Illjes wrote:
> Module Name: src
> Committed By: hannken
> Date: Tue Dec 3 11:50:45 UTC 2019
>
> Modified Files:
> src/sys/arch/x86/x86: x86_machdep.c
>
> Log Message:
> Make sure the assignment to "idepth" is done inside the loop to prevent
>
> Date: Sun, 1 Dec 2019 11:54:24 +
> From: Andrew Doran
>
> On Sun, Dec 01, 2019 at 08:19:09AM +, Maxime Villard wrote:
>
> > Modified Files:
> > src/sys/uvm: uvm_fault.c
> >
> > Log Message:
> > Use atomic_{load,store}_relaxed() on global counters.
>
> If you would be so kind,
Hi,
On Sun, Dec 01, 2019 at 08:19:09AM +, Maxime Villard wrote:
> Modified Files:
> src/sys/uvm: uvm_fault.c
>
> Log Message:
> Use atomic_{load,store}_relaxed() on global counters.
If you would be so kind, please don't do any more of the UVM counters. I
have a patch to make these
On 2019/11/30 23:35, Andrew Doran wrote:
Hmm, it works fine on amd64 and looks OK but me, but I have backed it out
for the time being.
Thanks! Also thank you for working on this area!
rin
Hi,
On Sat, Nov 30, 2019 at 04:52:38PM +0900, Rin Okuyama wrote:
> On 2019/11/30 5:50, Andrew Doran wrote:
> > Module Name:src
> > Committed By: ad
> > Date: Fri Nov 29 20:50:54 UTC 2019
> >
> > Modified Files:
> > src/sys/kern: kern_rwlock.c
> >
> > Log Message:
On 2019/11/30 5:50, Andrew Doran wrote:
Module Name:src
Committed By: ad
Date: Fri Nov 29 20:50:54 UTC 2019
Modified Files:
src/sys/kern: kern_rwlock.c
Log Message:
A couple more tweaks to avoid reading the lock word.
To generate a diff of this commit:
cvs rdiff -u
On Nov 27, 2019, at 9:08 PM, Jason R Thorpe wrote:
>
> + firqh = kmem_alloc(sizeof(*firqh), KM_SLEEP);
> + firqh->ih_irq = firq;
> + firqh->ih_fn = func;
> + firqh->ih_arg = arg;
> + TAILQ_INSERT_TAIL(>intr_handlers, firqh, ih_next);
> +
> + return firqh;
I should have
> On Nov 28, 2019, at 2:21 AM, Jared McNeill wrote:
>
> I should have commented the code in gicv3 so that you would have realized it
> was “unnecessarily complicated” for a reason :)
Ok, I'll fix and add a comment.
>
> The interrupt_distribute(9) API makes an assumption that the return
On 2019/11/27 19:19, SAITOH Masanobu wrote:
> Module Name: src
> Committed By: msaitoh
> Date: Wed Nov 27 10:19:21 UTC 2019
>
> Modified Files:
> src/sys/arch/arm/amlogic: gxlphy.c
> src/sys/dev/mii: acphy.c amhphy.c atphy.c bmtphy.c brgphy.c ciphy.c
> dmphy.c
Maxime Villard wrote:
> Module Name: src
> Committed By: maxv
> Date: Wed Nov 27 06:24:33 UTC 2019
>
> Modified Files:
> src/sys/arch/x86/include: cpu.h fpu.h
> src/sys/arch/x86/x86: cpu.c fpu.c
>
> Log Message:
> Add a small API for in-kernel FPU operations.
>
>
On Sat, 23 Nov 2019 19:53:05 +0100, "Jared D. McNeill" wrote:
>
> Module Name: src
> Committed By: jmcneill
> Date: Sat Nov 23 18:53:05 UTC 2019
>
> Modified Files:
> src/sys/dev/fdt: fdt_port.c
>
> Log Message:
> Use fdtbus_get_reg to read "reg" property
Hi,
this change breaks
Hi,
On 2019/10/27 18:00, Jared D. McNeill wrote:
> Module Name: src
> Committed By: jmcneill
> Date: Sun Oct 27 18:00:46 UTC 2019
>
> Modified Files:
> src/sys/arch/evbarm/conf: GENERIC
>
> Log Message:
> Add support for TI AM335x
This patch should fix if_cpsw.c build when
It only prevent null pointer dereference.
On Mon, Nov 18, 2019 at 3:18 PM wrote:
>
> On Mon, Nov 18, 2019 at 06:15:27AM +, m...@netbsd.org wrote:
> > > Modified files:
> > >
> > > Index: src/sys/dev/pci/if_mcx.c
> > > diff -u src/sys/dev/pci/if_mcx.c:1.5 src/sys/dev/pci/if_mcx.c:1.6
> > >
> Modified files:
>
> Index: src/sys/dev/pci/if_mcx.c
> diff -u src/sys/dev/pci/if_mcx.c:1.5 src/sys/dev/pci/if_mcx.c:1.6
> --- src/sys/dev/pci/if_mcx.c:1.5 Thu Oct 17 15:57:56 2019
> +++ src/sys/dev/pci/if_mcx.c Mon Nov 18 04:40:05 2019
> @@ -1,4 +1,4 @@
> -/* $NetBSD: if_mcx.c,v 1.5
On Thu, Nov 14, 2019 at 04:23:54PM +, Maxime Villard wrote:
> Module Name: src
> Committed By: maxv
> Date: Thu Nov 14 16:23:53 UTC 2019
>
> Modified Files:
> src/sys/arch/amd64/amd64: amd64_trap.S busfunc.S cpu_in_cksum.S
[..]
> Log Message:
> Add support for Kernel Memory
Hi,
On Tue, Nov 12, 2019 at 06:00:13PM +, Maxime Villard wrote:
> Committed By: maxv
> Date: Tue Nov 12 18:00:13 UTC 2019
> Modified Files:
> src/sys/arch/x86/include: specialreg.h
> src/sys/arch/x86/x86: spectre.c
> Log Message:
> Mitigation for CVE-2019-11135: TSX
On Nov 7, 6:08pm, n...@gmx.com (Kamil Rytarowski) wrote:
-- Subject: Re: CVS commit: src/sys/kern
| Please review:
|
| http://netbsd.org/~kamil/patch-00194-disklabel-alignment.txt
|
| This patch works for me.
|
| Patch inspired by:
|
| Avoid misaligned access in disklabel(8) in find_label
On Thu, Nov 07, 2019 at 19:06:29 +0100, Martin Husemann wrote:
> OK, why is it 8 byte aligned? Checking
>
> > revision 1.108
> > date: 2011-01-18 20:52:24 +0100; author: matt; state: Exp; lines: +2 -1;
> > Make struct disklabel 8 byte aligned. This increases its size by 4 bytes
> > on
On 07.11.2019 19:32, Valery Ushakov wrote:
> On Thu, Nov 07, 2019 at 18:08:40 +0100, Kamil Rytarowski wrote:
>
>> On 07.11.2019 16:45, Kamil Rytarowski wrote:
>>> On 07.11.2019 16:26, Martin Husemann wrote:
On Thu, Nov 07, 2019 at 02:53:08PM +0100, Kamil Rytarowski wrote:
> On 07.11.2019
On Thu, Nov 07, 2019 at 18:08:40 +0100, Kamil Rytarowski wrote:
> On 07.11.2019 16:45, Kamil Rytarowski wrote:
> > On 07.11.2019 16:26, Martin Husemann wrote:
> >> On Thu, Nov 07, 2019 at 02:53:08PM +0100, Kamil Rytarowski wrote:
> >>> On 07.11.2019 14:25, Valery Ushakov wrote:
> If the
On Thu, Nov 07, 2019 at 06:46:48PM +0100, Kamil Rytarowski wrote:
> member access within misaligned address 0x942d3de8c03c for type
> 'const struct disklabel' which requires 8 byte alignment
OK, why is it 8 byte aligned? Checking
> revision 1.108
> date: 2011-01-18 20:52:24 +0100;
On 07.11.2019 18:20, Martin Husemann wrote:
> On Thu, Nov 07, 2019 at 06:08:40PM +0100, Kamil Rytarowski wrote:
>> Please review:
>>
>> http://netbsd.org/~kamil/patch-00194-disklabel-alignment.txt
>>
>> This patch works for me.
>
> Yes, I believe that it does - but why is it needed?
>
syzbot
On Thu, Nov 07, 2019 at 06:08:40PM +0100, Kamil Rytarowski wrote:
> Please review:
>
> http://netbsd.org/~kamil/patch-00194-disklabel-alignment.txt
>
> This patch works for me.
Yes, I believe that it does - but why is it needed?
dlp = (void *)a->bp->b_data;
Here we can assume that
On 07.11.2019 16:45, Kamil Rytarowski wrote:
> On 07.11.2019 16:26, Martin Husemann wrote:
>> On Thu, Nov 07, 2019 at 02:53:08PM +0100, Kamil Rytarowski wrote:
>>> On 07.11.2019 14:25, Valery Ushakov wrote:
If the sanitizer does complain about other uses, there is little point
in fixing
David Young wrote in <20191107155806.gl1...@pobox.com>:
|On Thu, Nov 07, 2019 at 04:26:51PM +0100, Martin Husemann wrote:
|> On Thu, Nov 07, 2019 at 02:53:08PM +0100, Kamil Rytarowski wrote:
|>> On 07.11.2019 14:25, Valery Ushakov wrote:
..
|I think the problem is that if you have the series
On 07.11.2019 17:20, Kamil Rytarowski wrote:
> On 07.11.2019 17:08, Martin Husemann wrote:
>> On Thu, Nov 07, 2019 at 04:56:16PM +0100, Kamil Rytarowski wrote:
>>> 6.3.2.1 C11
>>>
>>> 'An lvalue is an expression (with an object type other than void) that
>>> potentially designates an object'
>>>
On Thu, Nov 07, 2019 at 09:58:06 -0600, David Young wrote:
> On Thu, Nov 07, 2019 at 04:26:51PM +0100, Martin Husemann wrote:
> > On Thu, Nov 07, 2019 at 02:53:08PM +0100, Kamil Rytarowski wrote:
> > > On 07.11.2019 14:25, Valery Ushakov wrote:
> > > > If the sanitizer does complain about other
On 07.11.2019 17:09, Martin Husemann wrote:
> On Thu, Nov 07, 2019 at 09:58:06AM -0600, David Young wrote:
>> I think the problem is that if you have the series of statements,
>>
>> element_t *e = >element;
>>
>> if (s == NULL)
>> return;
>
> Note that this example
On 07.11.2019 17:08, Martin Husemann wrote:
> On Thu, Nov 07, 2019 at 04:56:16PM +0100, Kamil Rytarowski wrote:
>> 6.3.2.1 C11
>>
>> 'An lvalue is an expression (with an object type other than void) that
>> potentially designates an object'
>>
>> This means that real dereference is not needed,
On Thu, Nov 07, 2019 at 09:58:06AM -0600, David Young wrote:
> I think the problem is that if you have the series of statements,
>
> element_t *e = >element;
>
> if (s == NULL)
> return;
Note that this example has *nothing* in common with Kamil's code change.
He
On Thu, Nov 07, 2019 at 04:56:16PM +0100, Kamil Rytarowski wrote:
> 6.3.2.1 C11
>
> 'An lvalue is an expression (with an object type other than void) that
> potentially designates an object'
>
> This means that real dereference is not needed, only a potential. And
> there are special cases of
On Thu, Nov 07, 2019 at 04:26:51PM +0100, Martin Husemann wrote:
> On Thu, Nov 07, 2019 at 02:53:08PM +0100, Kamil Rytarowski wrote:
> > On 07.11.2019 14:25, Valery Ushakov wrote:
> > > If the sanitizer does complain about other uses, there is little point
> > > in fixing one instance and not the
On 07.11.2019 16:49, Martin Husemann wrote:
> On Thu, Nov 07, 2019 at 04:45:31PM +0100, Kamil Rytarowski wrote:
>> Unfortunately the C committee went into the opposite direction here and
>> specified a potential dereference.
>
> Where?
>
> Martin
>
6.3.2.1 C99
"An lvalue is an expression with
901 - 1000 of 5582 matches
Mail list logo
