I've just committed a better, and more well-tested, version. Should
work correctly now.
Thanks for your patience, and sorry for the breakage.
On Tue, 29 Apr 2025, Paul Goyette wrote:
Thanks for the link to the log. I am investigating.
On Tue, 29 Apr 2025, Thomas Klausner wrote:
On Tue, A
Thanks for the link to the log. I am investigating.
On Tue, 29 Apr 2025, Thomas Klausner wrote:
On Tue, Apr 29, 2025 at 09:08:38AM +, Martin Husemann wrote:
Module Name:src
Committed By: martin
Date: Tue Apr 29 09:08:38 UTC 2025
Modified Files:
src/sys/arch/i386/s
On Tue, Apr 29, 2025 at 09:08:38AM +, Martin Husemann wrote:
> Module Name: src
> Committed By: martin
> Date: Tue Apr 29 09:08:38 UTC 2025
>
> Modified Files:
> src/sys/arch/i386/stand/boot: boot2.c
> src/sys/arch/i386/stand/efiboot: boot.c
>
> Log Message:
> Backout /fi
> > a) apply the workaround to all m68k ports:
> > pros: same m68k binaries can be shared
> > cons: requires extra performance penalty for all m68k (020/030/040/060)
> >
> > b) apply the workaround only for XC68LC040 users:
> > pros: nothing? (only technical interests of developers?)
> > cons:
On Sun, 13 Apr 2025 08:28:04 Izumi Tsutsui wrote:
> > Would you or isaki@ or martin@ like me to assign PR 13078 to either of
> > you and I'll write a followup email to the binutils people stating that
> > from now on you'll handle all responsibilty for the correspondance with
> > them and assign ei
> Would you or isaki@ or martin@ like me to assign PR 13078 to either of you
> and
> I'll write a followup email to the binutils people stating that from now on
> you'll handle all responsibilty for the correspondance with them and assign
> either of you to the doc/HACKS note.
Actually I had n
On Fri, 11 Apr 2025 02:07:06 Izumi Tsutsui wrote:
> When committing code, it's important to provide a obvious explanation
> of the technical rationale behind the implementation.
>
> Without such rationale, the code can become difficult to maintain
> in the future, as later contributors may not und
On Mon, 7 Apr 2025 17:58:26 Tetsuya Isaki wrote:
> At Sat, 5 Apr 2025 22:47:39 +1100,
>
> Nat Sloss wrote:
> > Before I placed the additional nops before rte I experienced 1 hard
> > lockup which I attributed to the fpu (buggy lc)
>
> > The idea was this:
> It can't be certain that the behavior i
> I did it to be on the safe side. If the kernel was to be built with -mlcfix
> passed to gas(1) the nop would be inserted.
It seems there might be some confusion between the goal
(i.e. avoiding f-line exception during write-pending) and
the approach/workaround (inserting a nop before F-line ins
On Thu, 10 Apr 2025 00:44:02 Izumi Tsutsui wrote:
> > Module Name:src
> > Committed By: nat
> > Date: Wed Apr 9 00:04:41 UTC 2025
> >
> > Modified Files:
> > src/sys/arch/m68k/m68k: fpu.c
> >
> > Log Message:
> > Add workaround for fpu test for kernels defined wit
> Module Name: src
> Committed By: nat
> Date: Wed Apr 9 00:04:41 UTC 2025
>
> Modified Files:
> src/sys/arch/m68k/m68k: fpu.c
>
> Log Message:
> Add workaround for fpu test for kernels defined with M68040.
>
> This is to accomodate kernels built without the -mlcfix option passed
Module Name:src
Committed By: nat
Date: Tue Apr 8 23:42:08 UTC 2025
Modified Files:
src/sys/arch/mac68k/mac68k: pmap_bootstrap.c
Log Message:
Move high back an additional 7 pages to fix crashing on kernels with
ascaudio(4) enabled.
Memory
On Tue, 8 Apr 2025 15:10:24 Martin Husemann wrote:
> On Tue, Apr 08, 2025 at 10:45:23AM +1000, Nat Sloss wrote:
> > nop - f* instructions are not atomicwhat will happen if nop is
> > executed and then the processor is interrupted (by say pressing a
> > keystroke on the keyboard) then after tha
On Tue, Apr 08, 2025 at 10:45:23AM +1000, Nat Sloss wrote:
> nop - f* instructions are not atomicwhat will happen if nop is executed
> and then the processor is interrupted (by say pressing a keystroke on the
> keyboard) then after that interrupt has run the f* instruction is executed.
>
>
On Mon, 7 Apr 2025 17:44:09 Tetsuya Isaki wrote:
> At Sat, 5 Apr 2025 22:01:37 +1100,
>
> Nat Sloss wrote:
> > Following advice and following the spirit of my intentions adding nop in
> > the switch i added nops before "rte" in locore.s in sys/mac68k as
> > opposed to m68k/swicher.
>
> Are you su
At Sat, 5 Apr 2025 22:47:39 +1100,
Nat Sloss wrote:
> Before I placed the additional nops before rte I experienced 1 hard lockup
> which I attributed to the fpu (buggy lc)
>
> The idea was this:
It can't be certain that the behavior is related to this bug.
XC68LC040 series are known for having m
At Sat, 5 Apr 2025 22:01:37 +1100,
Nat Sloss wrote:
> Following advice and following the spirit of my intentions adding nop in the
> switch i added nops before "rte" in locore.s in sys/mac68k as opposed to
> m68k/swicher.
Are you sure?
First, errata E4 said the workaround is "nop-before-f-line"
On Fri, 4 Apr 2025 23:27:49 Martin Husemann wrote:
> On Fri, Apr 04, 2025 at 10:48:17PM +1100, Nat Sloss wrote:
> > The changes to the context switch in sys/m68k have been reverted and the
> > nop insertion by gas(1) has been turned off by default.
>
> What does upstream gcc plan to do with the ne
On Mon, 31 Mar 2025 22:48:39 Tetsuya Isaki wrote:
> At Sun, 30 Mar 2025 04:44:26 +,
>
> Nathanial Sloss wrote:
> > Module Name:src
> > Committed By: nat
> > Date: Sun Mar 30 04:44:26 UTC 2025
> >
> > Modified Files:
> > src/sys/arch/m68k/m68k: switch_subr.s
> >
At Tue, 1 Apr 2025 02:26:35 +1100,
Nathanial Sloss wrote:
> Consider the following (including my gas patch for binutils):
>
> movq.
> nop
> fnop
>
> Thats as it's assembled but at run time it could posslibly
> run like this
>
> movq
> nop
> (switch task)
> fnop
>
> So the nops are inser
On Sat, Apr 05, 2025 at 10:47:39PM +1100, Nat Sloss wrote:
> nop
> fnop
>
> could be executed as
>
> nop
> (context swtich)
> (return from context swtich)
> fnop
>
> So without these the fnop would not be coverted.
Not sure what you mean here.
Why would the nop before the rte make any differen
On Sat, 5 Apr 2025 22:32:10 Martin Husemann wrote:
> On Sat, Apr 05, 2025 at 10:01:37PM +1100, Nat Sloss wrote:
> > Following advice and following the spirit of my intentions adding nop in
> > the switch i added nops before "rte" in locore.s in sys/mac68k as
> > opposed to m68k/swicher.
>
> This m
On Sat, Apr 05, 2025 at 10:01:37PM +1100, Nat Sloss wrote:
> Following advice and following the spirit of my intentions adding nop in the
> switch i added nops before "rte" in locore.s in sys/mac68k as opposed to
> m68k/swicher.
This makes no sense to me (but I can only guess how the exact bug w
Following advice and following the spirit of my intentions adding nop in the
switch i added nops before "rte" in locore.s in sys/mac68k as opposed to
m68k/swicher.
Along with adding nops before fline instructions with the modified assember.
I took a picture for your consideration.
http://ftp.n
On Fri, 4 Apr 2025 22:37:50 Tetsuya Isaki wrote:
> At Thu, 3 Apr 2025 14:00:16 +0200,
>
> Martin Husemann wrote:
> > > So these all nops are never executed just before any of f-line
> > > instructions.
> >
> > Can you also please explain how you got at that NOP-after-f-line
> > woraround? The Mot
At Thu, 3 Apr 2025 14:00:16 +0200,
Martin Husemann wrote:
> > So these all nops are never executed just before any of f-line
> > instructions.
>
> Can you also please explain how you got at that NOP-after-f-line woraround?
> The Motorola errata text (at least the versions I found on the wayback
>
On Fri, Apr 04, 2025 at 10:48:17PM +1100, Nat Sloss wrote:
> The changes to the context switch in sys/m68k have been reverted and the nop
> insertion by gas(1) has been turned off by default.
What does upstream gcc plan to do with the new option? Default on or off?
I guess we can find some way t
On Thu, Apr 03, 2025 at 08:55:11PM +0900, Tetsuya Isaki wrote:
> So these all nops are never executed just before any of f-line
> instructions.
Can you also please explain how you got at that NOP-after-f-line woraround?
The Motorola errata text (at least the versions I found on the wayback
machine
At Sun, 30 Mar 2025 04:44:26 +,
Nathanial Sloss wrote:
> Module Name: src
> Committed By: nat
> Date: Sun Mar 30 04:44:26 UTC 2025
>
> Modified Files:
> src/sys/arch/m68k/m68k: switch_subr.s
>
> Log Message:
> Sprinkle nop.
>
> This is the kernel part of addressing the issue w
riastradh@ wrote:
> > Modified Files:
> > src/sys/arch/sun3/dev: bw2.c cg2.c cg4.c fb.c fd.c kd.c xd.c xy.c
> >
> > Log Message:
> > Make local dev_type_*() functions static.
>
> While you're doing this kind of cleanup, maybe you could also change
>
> static dev_type_open(foo_open);
>
> Module Name:src
> Committed By: tsutsui
> Date: Sat Dec 21 17:40:11 UTC 2024
>
> Modified Files:
> src/sys/arch/sun3/dev: bw2.c cg2.c cg4.c fb.c fd.c kd.c xd.c xy.c
>
> Log Message:
> Make local dev_type_*() functions static.
While you're doing this kind of cleanup, may
Hi,
On 2024/09/19 3:33, Andrius V wrote:
On Wed, Sep 18, 2024 at 3:44 AM Rin Okuyama wrote:
Module Name:src
Committed By: rin
Date: Wed Sep 18 00:44:03 UTC 2024
Modified Files:
src/sys/arch/i386/stand/lib: libi386.h
Log Message:
i386/stand: Remove XMS leftover from
On Wed, Sep 18, 2024 at 3:44 AM Rin Okuyama wrote:
>
> Module Name:src
> Committed By: rin
> Date: Wed Sep 18 00:44:03 UTC 2024
>
> Modified Files:
> src/sys/arch/i386/stand/lib: libi386.h
>
> Log Message:
> i386/stand: Remove XMS leftover from libi386.h, NFC
>
> PR port-i3
Thank you very much for kind & rapid response!!
rin
On 2024/09/18 10:34, Nathanial Sloss wrote:
Module Name:src
Committed By: nat
Date: Wed Sep 18 01:34:08 UTC 2024
Modified Files:
src/sys/arch/mac68k/dev: adb.c
Log Message:
The delay is only required for machines with
Hi,
Can you please localize this quirk only for the affected machines?
It seems too much to me, to have 5 sec delay for irrelevant machines.
Thanks,
rin
On 2024/09/15 5:56, Nathanial Sloss wrote:
Module Name:src
Committed By: nat
Date: Sat Sep 14 20:56:51 UTC 2024
Modified Fil
On Wed, Sep 11, 2024 at 05:17:45 +, matthew green wrote:
> Module Name: src
> Committed By: mrg
> Date: Wed Sep 11 05:17:45 UTC 2024
>
> Modified Files:
> src/sys/arch/x86/x86: intr.c
>
> Log Message:
> apply some more diagnostic checks for x86 interrupts
How does this mix wi
Hi,
On 2024/06/30 16:18, matthew green wrote:
"Rin Okuyama" writes:
Module Name:src
Committed By: rin
Date: Sun Jun 30 05:59:14 UTC 2024
Modified Files:
src/sys/arch/sun2/conf: GENERIC
Log Message:
sun2: GENERIC: XXX: Drop `MODULAR` and `compat_netbsd16.config`
as a w
"Rin Okuyama" writes:
> Module Name: src
> Committed By: rin
> Date: Sun Jun 30 05:59:14 UTC 2024
>
> Modified Files:
> src/sys/arch/sun2/conf: GENERIC
>
> Log Message:
> sun2: GENERIC: XXX: Drop `MODULAR` and `compat_netbsd16.config`
>
> as a workaround for memory shortage. Even wit
Am 30.04.2024 um 11:55 schrieb Izumi Tsutsui:
> Module Name: src
> Committed By: tsutsui
> Date: Tue Apr 30 09:55:46 UTC 2024
>
> Modified Files:
> src/sys/arch/hp300/dev: dma.c
>
> Log Message:
> Fix another fatal typo that prevents dma(4) interrupts.
The buggy code was:
> if
Thanks, should take remember this for the future reference.
On Wed, Mar 13, 2024 at 8:59 AM Nick Hudson wrote:
>
> Module Name:src
> Committed By: skrll
> Date: Wed Mar 13 06:59:01 UTC 2024
>
> Modified Files:
> src/sys/arch/evbmips/evbmips: interrupt.c
>
> Log Message:
>
On Thu, Jan 18, 2024 at 06:43:21 +1100, matthew green wrote:
> > Log Message:
> > macppc: enable FFS_EI in GENERIC
> >
> > I'd say it should be enabled for anything with USB.
> >
> > ok macallan
>
> yay. i think we should enable it basically everywhere that it
> is not a space issue.
I think th
> Log Message:
> macppc: enable FFS_EI in GENERIC
>
> I'd say it should be enabled for anything with USB.
>
> ok macallan
yay. i think we should enable it basically everywhere that it
is not a space issue. USB is just one common way, but i can
also modify or create my own images anyway, and mayb
> No, that definitely wasn't intentional! I've just reverted
> that. Does that need a pullup for netbsd-10 ?
Thanks for your confirmation.
I have another fix to make GENERIC boot on my 3/60
(disable more several pseudo-devices to shrink binary)
so I'll handle a pullup request with your fix.
--
Hi Tsutsui,
Izumi Tsutsui wrote:
> simonb@ wrote:
>
> > cvs rdiff -u -r1.187 -r1.188 src/sys/arch/sun3/conf/GENERIC
>
> >> # Veriexec
> >> # include "dev/veriexec.config"
> >> +
> >> +no obmem0 at mainbus? # XX
>
> Is this intentional!?
No, that definitely wasn't intent
simonb@ wrote:
> Module Name: src
> Committed By: simonb
> Date: Sun Aug 7 02:52:30 UTC 2022
>
> Modified Files:
:
> src/sys/arch/sun3/conf: DISKLESS GENERIC GENERIC3X
:
> Log Message:
> UFS/LFS dirhash:
> - Enable UFS_DIRHASH if the architecture or kernel model specific config
Hi,
Will check and adjust. Thanks for the tip.
On Thu, Dec 14, 2023 at 2:12 AM Valery Ushakov wrote:
>
> On Wed, Dec 13, 2023 at 23:11:35 +, Andrius Varanavicius wrote:
>
> > Module Name: src
> > Committed By: andvar
> > Date: Wed Dec 13 23:11:35 UTC 2023
> >
> > Modified Files:
> >
On Wed, Dec 13, 2023 at 23:11:35 +, Andrius Varanavicius wrote:
> Module Name: src
> Committed By: andvar
> Date: Wed Dec 13 23:11:35 UTC 2023
>
> Modified Files:
> src/sys/arch/sparc64/dev: vnet.c
> src/sys/arch/sparc64/sparc64: netbsd32_machdep_13.c
>
> Log Message:
>
Thank you, I should pay attention to that.
On Wed, Oct 25, 2023 at 9:02 AM Nick Hudson wrote:
>
> Module Name:src
> Committed By: skrll
> Date: Wed Oct 25 06:02:14 UTC 2023
>
> Modified Files:
> src/sys/arch/mips/mips: kgdb_machdep.c
>
> Log Message:
> ->
>
>
> To genera
OK, it makes sense. I will revert the changes. Thanks for your explanations.
On Sun, Oct 8, 2023 at 12:49 PM matthew green wrote:
>
> > I was changing news68k specific code, thus wasn't treating them as
> > common. But I understand the point.
>
> there's a *LOT* of m68k code that is copied into
> I was changing news68k specific code, thus wasn't treating them as
> common. But I understand the point.
there's a *LOT* of m68k code that is copied into all the ports
that is almost identical, and should really be shared, but it
not, and changes like can make this harder to share.
ie, while i
On Sun, Oct 8, 2023 at 6:56 AM Izumi Tsutsui wrote:
>
> > In this case maybe I should remove all FPSP references (vectors.S,
> > locore.S, Makefile.news68k (MD_LIBS={FPSP})?
>
> IMO we don't have to keep strict consistencies or buildabilities of
> options but rather should consider readabilities a
> In this case maybe I should remove all FPSP references (vectors.S,
> locore.S, Makefile.news68k (MD_LIBS={FPSP})?
IMO we don't have to keep strict consistencies or buildabilities of
options but rather should consider readabilities and maintainabilities.
- options FPSP in a config file is not ne
In this case maybe I should remove all FPSP references (vectors.S,
locore.S, Makefile.news68k (MD_LIBS={FPSP})?
On Sun, Oct 1, 2023 at 10:08 PM Izumi Tsutsui wrote:
>
> > Module Name: src
> > Committed By: andvar
> > Date: Sun Oct 1 18:50:53 UTC 2023
> >
> > Modified Files:
> > sr
> Module Name: src
> Committed By: andvar
> Date: Sun Oct 1 18:50:53 UTC 2023
>
> Modified Files:
> src/sys/arch/news68k/conf: Makefile.news68k
>
> Log Message:
> include fpsp Makefile.inc in Makefile.news68k, same as other m68k ports.
>
> needed for FPSP option to build, otherwi
Hi,
Oops, I didn't notice it is not generated. Sorry for bothering you!
Thanks,
rin
On Mon, Sep 4, 2023 at 10:46 PM Andrius V wrote:
>
> Hi,
>
> Thanks for the note. I honestly wasn't aware that we have generated
> configs and will be more careful in changing them in the future to
> account tha
Hi,
Thanks for the note. I honestly wasn't aware that we have generated
configs and will be more careful in changing them in the future to
account that.
However, MDINSTALL config seems to be some older/legacy config, which
was not generated from GENERIC.in, I believe. I may try to transform
into
Hi,
On 2023/08/31 5:17, Andrius Varanavicius wrote:
Module Name:src
Committed By: andvar
Date: Wed Aug 30 20:17:06 UTC 2023
Modified Files:
src/sys/arch/amiga/conf: MDINSTALL
Log Message:
s/Piccalo/Piccolo/ in device description.
Some ports including amiga use arch/fo
On Tue, Aug 08, 2023 at 04:01:19PM +1000, matthew green wrote:
> Joerg Sonnenberger writes:
> > On Thu, Aug 03, 2023 at 08:16:31AM +, matthew green wrote:
> > > Module Name: src
> > > Committed By: mrg
> > > Date: Thu Aug 3 08:16:31 UTC 2023
> > >
> > > Modified Files:
>
Joerg Sonnenberger writes:
> On Thu, Aug 03, 2023 at 08:16:31AM +, matthew green wrote:
> > Module Name:src
> > Committed By: mrg
> > Date: Thu Aug 3 08:16:31 UTC 2023
> >
> > Modified Files:
> > src/sys/arch/evbarm/gumstix: gumstix_machdep.c
> > src/sys/ar
On 2023/08/04 20:18, Rin Okuyama wrote:
Module Name:src
Committed By: rin
Date: Fri Aug 4 11:18:18 UTC 2023
Modified Files:
src/sys/arch/sun2/dev: sc_mbmem.c
Log Message:
sun2/sc(4): Fix panic due to wrong ENOMEM for DMA buffer
Use kmem_zalloc(9) for sc->sc_dma_handles
On Thu, Aug 03, 2023 at 08:16:31AM +, matthew green wrote:
> Module Name: src
> Committed By: mrg
> Date: Thu Aug 3 08:16:31 UTC 2023
>
> Modified Files:
> src/sys/arch/evbarm/gumstix: gumstix_machdep.c
> src/sys/arch/evbarm/ixm1200: ixm1200_machdep.c
> src/sys/arch
On 2023/07/24 16:14, matthew green wrote:
"Rin Okuyama" writes:
Module Name:src
Committed By: rin
Date: Mon Jul 24 01:56:59 UTC 2023
Modified Files:
src/sys/arch/i386/stand/efiboot: Makefile.efiboot eficons.c
Added Files:
src/sys/arch/i386/stand/efiboot: eficpufu
"Rin Okuyama" writes:
> Module Name: src
> Committed By: rin
> Date: Mon Jul 24 01:56:59 UTC 2023
>
> Modified Files:
> src/sys/arch/i386/stand/efiboot: Makefile.efiboot eficons.c
> Added Files:
> src/sys/arch/i386/stand/efiboot: eficpufunc.c eficpufunc.h
>
> Log Message:
> efi
Emmanuel Dreyfus writes:
> On Thu, Jun 29, 2023 at 08:43:36PM -0400, Greg Troxel wrote:
>> > Primary bootstrap is now able to read a GPT inside RAIDframe.
>> did you also update documentation?
>
> We do not have any documentation specific to primary bootstrap.
> x86/boot(8) domuent the behavior
On Thu, Jun 29, 2023 at 08:43:36PM -0400, Greg Troxel wrote:
> > Primary bootstrap is now able to read a GPT inside RAIDframe.
> did you also update documentation?
We do not have any documentation specific to primary bootstrap.
x86/boot(8) domuent the behavior with no detail about primary
and sec
"Emmanuel Dreyfus" writes:
> Log Message:
> Primary bootstrap is now able to read a GPT inside RAIDframe.
did you also update documentation?
On Mon, Feb 20, 2023 at 15:41:04 +0100, Martin Husemann wrote:
> On Mon, Feb 20, 2023 at 05:15:33PM +0300, Valery Ushakov wrote:
> > them up, b/c you cannot amend that comment. To add to the fun, I
> > think releng scripts just clone the commit message on pull ups, so
> > that comment gets splatt
On Mon, Feb 20, 2023 at 22:35:40 +0700, Robert Elz wrote:
> Date:Mon, 20 Feb 2023 16:47:01 +0300
> From:Valery Ushakov
> Message-ID:
>
> | I wonder if we should stop abusing commit messages as pull-up
> | reminders. These XXX will not convey any useful informat
Date:Mon, 20 Feb 2023 16:47:01 +0300
From:Valery Ushakov
Message-ID:
| I wonder if we should stop abusing commit messages as pull-up
| reminders. These XXX will not convey any useful information a few
| months down the line...
I think they're useful (if only
On Mon, Feb 20, 2023 at 05:15:33PM +0300, Valery Ushakov wrote:
> them up, b/c you cannot amend that comment. To add to the fun, I
> think releng scripts just clone the commit message on pull ups, so
> that comment gets splattered all over the target branches too.
Yes - I try to manually remove t
On Mon, Feb 20, 2023 at 13:57:32 +, Taylor R Campbell wrote:
> > > XXX pullup-8
> > > XXX pullup-9
> > > XXX pullup-10
> >
> > I wonder if we should stop abusing commit messages as pull-up
> > reminders. These XXX will not convey any useful information a few
> > months down the line...
>
>
> Date: Mon, 20 Feb 2023 16:47:01 +0300
> From: Valery Ushakov
>
> On Mon, Feb 20, 2023 at 13:30:23 +, Taylor R Campbell wrote:
>
> > Module Name:src
> > Committed By: riastradh
> > Date: Mon Feb 20 13:30:23 UTC 2023
> >
> > Modified Files:
> > src/sys/arch/s
On Mon, Feb 20, 2023 at 13:30:23 +, Taylor R Campbell wrote:
> Module Name: src
> Committed By: riastradh
> Date: Mon Feb 20 13:30:23 UTC 2023
>
> Modified Files:
> src/sys/arch/sparc64/sparc64: lock_stubs.s
>
> Log Message:
> sparc64: Add missing LoadStore ordering for mutex_
On 2022/10/04 16:38, matthew green wrote:
"Rin Okuyama" writes:
Module Name:src
Committed By: rin
Date: Tue Oct 4 07:24:32 UTC 2022
Modified Files:
src/sys/arch/amiga/dev: ser.c
src/sys/arch/sgimips/dev: scn.c
Log Message:
Remove unused extern declaration of co
"Rin Okuyama" writes:
> Module Name: src
> Committed By: rin
> Date: Tue Oct 4 07:24:32 UTC 2022
>
> Modified Files:
> src/sys/arch/amiga/dev: ser.c
> src/sys/arch/sgimips/dev: scn.c
>
> Log Message:
> Remove unused extern declaration of constty.
thank you.
can someone pleas
> Module Name:src
> Committed By: riastradh
> Date: Sun Sep 25 07:50:32 UTC 2022
>
> Modified Files:
> src/sys/arch/arm/ti: ti_fb.c ti_lcdc.c
>
> Log Message:
> tilcdc(4): Set is_console on the drm device, not the fb child.
>
> The drm device is represented by a rockchip,
> Module Name:src
> Committed By: riastradh
> Date: Sun Sep 25 07:50:23 UTC 2022
>
> Modified Files:
> src/sys/arch/arm/sunxi: sunxi_drm.c sunxi_fb.c
>
> Log Message:
> sunxidrm: Set is_console on the drm device, not the fb child.
>
> The drm device is represented by a ro
At Tue, 26 Jul 2022 09:52:40 -0700,
Chuck Silvers wrote:
> > This commit breaks usr.sbin/crash on m68k.
> > curlwp is defined only in _KERNEL. usr.sbin/crash defines _KMEMUSER
> > but not _KERNEL.
> >
> > Would you look into?
>
> I fixed it now, sorry about that.
Thank you!
---
Tetsuya Isaki
On Tue, Jul 26, 2022 at 05:25:01PM +0900, Tetsuya Isaki wrote:
> At Mon, 25 Jul 2022 01:59:26 +,
> Chuck Silvers wrote:
> > Module Name:src
> > Committed By: chs
> > Date: Mon Jul 25 01:59:26 UTC 2022
> >
> > Modified Files:
> > src/sys/arch/m68k/m68k: db_trace.
At Mon, 25 Jul 2022 01:59:26 +,
Chuck Silvers wrote:
> Module Name: src
> Committed By: chs
> Date: Mon Jul 25 01:59:26 UTC 2022
>
> Modified Files:
> src/sys/arch/m68k/m68k: db_trace.c
>
> Log Message:
> use the pcb of the thread we are tracing rather than always curlwp.
>
>
"Taylor R Campbell" writes:
> Module Name: src
> Committed By: riastradh
> Date: Sun Jul 24 20:28:32 UTC 2022
>
> Modified Files:
> src/sys/arch/aarch64/include: lock.h
>
> Log Message:
> aarch64/lock.h: Need for _HARDKERNEL.
>
> Add include guard while here.
>
> XXX Why does this a
> Modified Files:
> src/sys/arch/atari/dev: kbd.c
>
> Log Message:
> gcc is not smart enough to track the equivalence of conditions used
> here and warns about an unused value - initialize "code" always.
Umm, complains only with -Os ...
Anyway thanks for fixing.
---
Izumi Tsutsui
I wrote:
> Module Name: src
> Committed By: tsutsui
> Date: Sat Jun 25 03:18:38 UTC 2022
>
> Modified Files:
> src/sys/arch/x68k/dev: ite.c ite_tv.c itevar.h
>
> Log Message:
> Add a minimum box drawing character support for x68k ite(4).
Ah, I committed a wrong branch so these al
Oops, I missed it. I will fix soon.
Thanks again,
rin
On 2022/05/07 17:24, Valery Ushakov wrote:
On Sat, May 07, 2022 at 04:12:55 +, Rin Okuyama wrote:
Module Name:src
Committed By: rin
Date: Sat May 7 04:12:55 UTC 2022
Modified Files:
src/sys/arch/evbppc/dht: lo
On Sat, May 07, 2022 at 04:12:55 +, Rin Okuyama wrote:
> Module Name: src
> Committed By: rin
> Date: Sat May 7 04:12:55 UTC 2022
>
> Modified Files:
> src/sys/arch/evbppc/dht: locore.S
> src/sys/arch/powerpc/include: spr.h
>
> Log Message:
> Instead of hard-coding SPR#
> Module Name: src
> Committed By: mlelstv
> Date: Mon Apr 25 15:12:07 UTC 2022
>
> Modified Files:
> src/sys/arch/x68k/stand/boot: conf.c
> src/sys/arch/x68k/stand/xxboot: Makefile.xxboot xx.c
>
> Log Message:
> libsa now needs ioctl to support media with large sectors. Prov
On 2022/04/25 23:03, Rin Okuyama wrote:
Module Name:src
Committed By: rin
Date: Mon Apr 25 14:03:15 UTC 2022
Modified Files:
src/sys/arch/amiga/stand/bootblock/elf2bb: chksum.c elf2bb.c
Log Message:
Use htobe{16,32}(9) instead of be{16,32}toh(9) where appropriate.
No bi
Emmanuel Dreyfus wrote:
> In src/sys/arch/i386/stand/lib/biosdisk.c
> int
> biosdisk_findpartition(int biosdev, daddr_t sector,
>int *partition, const char **part_name)
> {
> (...)
> /* default ot first partition */
> *partition = 0;
> *part_name = N
On Mon, Dec 27, 2021 at 10:54:13PM +1100, Simon Burge wrote:
> If you have a way of preproducing this, I'm happy to have a look.
I recall it now.
In src/sys/arch/i386/stand/efiboot/devopen.c
bios2dev(boot_biosdev, boot_biossector, &devname, &unit,
&partition, NUL
Emmanuel Dreyfus wrote:
> On Mon, Dec 27, 2021 at 01:08:15PM +1100, Simon Burge wrote:
> > What crash did this fix? All the use of part_name by the
> > called functions should check if it is NULL before trying
> > to assign anything to *part_name.
>
> I do not recall the details now, but I had a
On Mon, Dec 27, 2021 at 01:08:15PM +1100, Simon Burge wrote:
> What crash did this fix? All the use of part_name by the
> called functions should check if it is NULL before trying
> to assign anything to *part_name.
I do not recall the details now, but I had a crash because
of this. Please revert
Hi Emmanuel,
"Emmanuel Dreyfus" wrote:
> Module Name: src
> Committed By: manu
> Date: Thu Nov 18 16:18:13 UTC 2021
>
> Modified Files:
>
> src/sys/arch/i386/stand/efiboot: devopen.c
>
> Log Message:
>
> Fix crash because of NULL pointer reference
What crash did this fix? All the
On 2021/11/09 8:57, Rin Okuyama wrote:
Module Name:src
Committed By: rin
Date: Mon Nov 8 23:57:23 UTC 2021
Modified Files:
src/sys/arch/arm/sa11x0: sa11x0_irq.S
Log Message:
irq_entry(): Do not clobber fp (= r11), in order not to confuse DDB.
(snip)
XXX
Rewrite this
On Sun, 31 Oct 2021 16:23:48 +
Nick Hudson wrote:
> Modified Files:
> src/sys/arch/aarch64/include: cpu.h cpufunc.h db_machdep.h
...
> Log Message:
> Rework Arm (32bit and 64bit) AP startup so that cpu_hatch doesn't sleep.
Hi,
I'm afraid this broke the userland build.
I think db_machd
hehehe - porn iterators - love it!
On Fri, 15 Oct 2021, Jason Thorpe wrote:
I demand this change be reverted.
(/s)
On Oct 15, 2021, at 11:12 AM, Jared D. McNeill wrote:
Module Name:src
Committed By: jmcneill
Date: Fri Oct 15 18:12:48 UTC 2021
Modified Files:
src/s
I demand this change be reverted.
(/s)
> On Oct 15, 2021, at 11:12 AM, Jared D. McNeill wrote:
>
> Module Name: src
> Committed By: jmcneill
> Date: Fri Oct 15 18:12:48 UTC 2021
>
> Modified Files:
> src/sys/arch/x86/x86: tsc.c
>
> Log Message:
> Fix typo in comment: "porniters
On 11/10/2021 08:14, Rin Okuyama wrote:
Hi,
On 2021/09/23 15:34, Nick Hudson wrote:
Module Name: src
Committed By: skrll
Date: Thu Sep 23 06:34:00 UTC 2021
Modified Files:
src/sys/arch/aarch64/aarch64: cpufunc.c
src/sys/arch/arm/arm32: cpu.c
Log Message:
Print the cach
Thanks for quick response. Committed :)
rin
On 2021/10/11 16:27, Nick Hudson wrote:
On 11/10/2021 08:14, Rin Okuyama wrote:
Hi,
On 2021/09/23 15:34, Nick Hudson wrote:
Module Name: src
Committed By: skrll
Date: Thu Sep 23 06:34:00 UTC 2021
Modified Files:
src/sys/arch/aar
Hi,
On 2021/09/23 15:34, Nick Hudson wrote:
Module Name:src
Committed By: skrll
Date: Thu Sep 23 06:34:00 UTC 2021
Modified Files:
src/sys/arch/aarch64/aarch64: cpufunc.c
src/sys/arch/arm/arm32: cpu.c
Log Message:
Print the cache information in similar formats a
Oops, forgot to mention: No binary changes.
On 2021/10/07 18:58, Rin Okuyama wrote:
Module Name:src
Committed By: rin
Date: Thu Oct 7 09:58:27 UTC 2021
Modified Files:
src/sys/arch/arm/arm: cpufunc_asm_armv5_ec.S
Log Message:
Reduce diff with cpufunc_asm_armv5.S, from
1 - 100 of 1993 matches
Mail list logo
