HomeSort by: relevance | last modified time | path
    Searched hist:1.121 (Results 1 - 25 of 884) sorted by relevancy

1 2 3 4 5 6 7 8 91011>>

  /src/sys/arch/mips/mips/
vm_machdep.c 1.121 Wed Oct 15 06:51:18 UTC 2008 wrstuden branches: 1.121.2; 1.121.4; 1.121.6;
Merge wrstuden-revivesa into HEAD.
Wed Oct 15 06:51:18 UTC 2008 wrstuden branches: 1.121.2; 1.121.4; 1.121.6;
Merge wrstuden-revivesa into HEAD.
.2; 1.121.4; 1.121.6;
Merge wrstuden-revivesa into HEAD.
.4; 1.121.6;
Merge wrstuden-revivesa into HEAD.
1.121.6.1 Tue Jun 09 17:48:20 UTC 2009 snj branches: 1.121.6.1.2;
Pull up following revision(s) (requested by martin in ticket #799):
sys/arch/mips/include/locore.h: revision 1.79
sys/arch/mips/mips/locore_mips1.S: revision 1.65
sys/arch/mips/mips/mipsX_subr.S: revision 1.28
sys/arch/mips/mips/mips_machdep.c: revision 1.211
sys/arch/mips/mips/vm_machdep.c: revision 1.123
Do not use the same trampoline for cpu_lwp_fork and cpu_setfunc - only
the former needs to call lwp_startup().
.6.1 Tue Jun 09 17:48:20 UTC 2009 snj branches: 1.121.6.1.2;
Pull up following revision(s) (requested by martin in ticket #799):
sys/arch/mips/include/locore.h: revision 1.79
sys/arch/mips/mips/locore_mips1.S: revision 1.65
sys/arch/mips/mips/mipsX_subr.S: revision 1.28
sys/arch/mips/mips/mips_machdep.c: revision 1.211
sys/arch/mips/mips/vm_machdep.c: revision 1.123
Do not use the same trampoline for cpu_lwp_fork and cpu_setfunc - only
the former needs to call lwp_startup().
1.121.6.1.2.31 Fri Feb 14 18:38:16 UTC 2014 matt Change KASSERTMSG/KDASSERTMSG to use varadic arguments like HEAD.
panic -> vpanic, add panic wrapper to vpanic.
1.121.6.1.2.30 Sat Aug 04 07:20:31 UTC 2012 matt Make MIPS use a multi-level page table for the kernel address space.
(just like the user address does). XXX fix mips1
1.121.6.1.2.29 Thu Feb 16 18:58:57 UTC 2012 matt mips_nfreelist is the one past the highest freelist used.
1.121.6.1.2.28 Tue Feb 14 01:51:12 UTC 2012 matt Fix various LP64 thinkos.
  /src/share/man/man4/
tc.4 1.6.6.1 Sat Jul 01 08:39:21 UTC 2017 snj Pull up following revision(s) (requested by flxd in ticket #65):
share/man/man4/tc.4: revision 1.7
sys/arch/alpha/tc/tcasic.c: revision 1.46
sys/arch/pmax/tc/tcbus.c: revision 1.33
sys/arch/vax/conf/files.vax: revision 1.121
sys/arch/vax/vsa/tc_vsbus.c: revision 1.8, 1.9
sys/dev/tc/tc.c: revision 1.55
sys/dev/tc/tcvar.h: revision 1.27
Make VAXstation 4000 TURBOchannel adaptor work.
PIO and IRQ tested on VS4000/60 and /96 with TC-USB (slhci) and PMAD-AA (le).
DMA is untested.
vax needs space to be mapped out, so memory space is pre-mapped for TC option
drivers not bus_space'ified yet, also providing custom bus_space methods for
this kludge.
--
whitespace
--
Add vax.

  /src/sys/external/mit/xen-include-public/dist/xen/include/public/
memory.h 1.1.1.1.6.1 Sun May 31 10:39:34 UTC 2020 martin Pull up following revision(s) (requested by bouyer in ticket #935):

sys/arch/xen/x86/x86_xpmap.c: revision 1.89
sys/arch/x86/include/pmap.h: revision 1.121
sys/arch/xen/xen/privcmd.c: revision 1.58
sys/external/mit/xen-include-public/dist/xen/include/public/memory.h: revision 1.2
sys/arch/xen/include/xenpmap.h: revision 1.44
sys/arch/xen/include/xenio.h: revision 1.12
sys/arch/x86/x86/pmap.c: revision 1.394
(all via patch)

Ajust pmap_enter_ma() for upcoming new Xen privcmd ioctl:
pass flags to xpq_update_foreign()

Introduce a pmap MD flag: PMAP_MD_XEN_NOTR, which cause xpq_update_foreign()
to use the MMU_PT_UPDATE_NO_TRANSLATE flag.
make xpq_update_foreign() return the raw Xen error. This will cause
pmap_enter_ma() to return a negative error number in this case, but the
only user of this code path is privcmd.c and it can deal with it.

Add pmap_enter_gnt()m which maps a set of Xen grant entries at the
specified va in the specified pmap. Use the hooks implemented for EPT to
keep track of mapped grand entries in the pmap, and unmap them
when pmap_remove() is called. This requires pmap_remove() to be split
into a pmap_remove_locked(), to be called from pmap_remove_gnt().

Implement new ioctl, needed by Xen 4.13:
IOCTL_PRIVCMD_MMAPBATCH_V2
IOCTL_PRIVCMD_MMAP_RESOURCE
IOCTL_GNTDEV_MMAP_GRANT_REF
IOCTL_GNTDEV_ALLOC_GRANT_REF

Always enable declarations needed by privcmd.c

  /src/sys/modules/if_urtwn/
if_urtwn.ioconf 1.2.2.2 Thu Jun 14 09:48:48 UTC 2012 sborrill Pull up the following revisions(s) (requested by riz in ticket #326):
distrib/sets/lists/base/mi: 1.989
distrib/sets/lists/man/mi: 1.1385
etc/mtree/NetBSD.dist.base: 1.99
share/man/man4/Makefile: 1.583
share/man/man4/urtwn.4: 1.1
share/man/man4/usb.4: 1.97
sys/arch/amd64/conf/GENERIC: 1.351
sys/arch/i386/conf/GENERIC: 1.1068
sys/dev/usb/files.usb: 1.121
sys/dev/usb/if_urtwn.c: 1.1-1.4
sys/dev/usb/if_urtwn_data.h: 1.1
sys/dev/usb/if_urtwnreg.h: 1.1
sys/dev/usb/if_urtwnvar.h: 1.1
sys/dev/usb/usbdevices.config: 1.13
sys/dev/usb/usbdevs: 1.621 via patch
sys/dev/usb/usbdevs.h: regen
sys/dev/usb/usbdevs_data.h: regen
sys/modules/if_urtwn/Makefile: 1.1
sys/modules/if_urtwn/if_urtwn.ioconf: 1.1

Add support for urtwn(4) wireless. Ported from OpenBSD

Makefile 1.1.4.2 Thu Jun 14 09:48:48 UTC 2012 sborrill Pull up the following revisions(s) (requested by riz in ticket #326):
distrib/sets/lists/base/mi: 1.989
distrib/sets/lists/man/mi: 1.1385
etc/mtree/NetBSD.dist.base: 1.99
share/man/man4/Makefile: 1.583
share/man/man4/urtwn.4: 1.1
share/man/man4/usb.4: 1.97
sys/arch/amd64/conf/GENERIC: 1.351
sys/arch/i386/conf/GENERIC: 1.1068
sys/dev/usb/files.usb: 1.121
sys/dev/usb/if_urtwn.c: 1.1-1.4
sys/dev/usb/if_urtwn_data.h: 1.1
sys/dev/usb/if_urtwnreg.h: 1.1
sys/dev/usb/if_urtwnvar.h: 1.1
sys/dev/usb/usbdevices.config: 1.13
sys/dev/usb/usbdevs: 1.621 via patch
sys/dev/usb/usbdevs.h: regen
sys/dev/usb/usbdevs_data.h: regen
sys/modules/if_urtwn/Makefile: 1.1
sys/modules/if_urtwn/if_urtwn.ioconf: 1.1

Add support for urtwn(4) wireless. Ported from OpenBSD

  /src/tests/net/net/
t_pktinfo_send.c 1.2.2.2 Thu Dec 21 21:08:13 UTC 2017 snj Pull up following revision(s) (requested by ryo in ticket #445):
distrib/sets/lists/debug/mi: revision 1.222
distrib/sets/lists/tests/mi: revision 1.760
share/man/man4/ip.4: revision 1.38
sys/netinet/in.c: revision 1.207
sys/netinet/in.h: revision 1.101
sys/netinet/in_pcb.c: revision 1.179
sys/netinet/in_pcb.h: revision 1.64
sys/netinet/ip_output.c: revision 1.284, 1.286
sys/netinet/ip_var.h: revision 1.120-1.121
sys/netinet/raw_ip.c: revision 1.166-1.167
sys/netinet/udp_usrreq.c: revision 1.235-1.236
sys/netinet/udp_var.h: revision 1.42
tests/net/net/Makefile: revision 1.21
tests/net/net/t_pktinfo_send.c: revision 1.1-1.2
Add support IP_PKTINFO for sendmsg(2).
The source address or output interface can be specified by adding IP_PKTINFO
to the control part of the message on a SOCK_DGRAM or SOCK_RAW socket.
Reviewed by ozaki-r@ and christos@. thanks.
--
As is the case with IPV6_PKTINFO, IP_PKTINFO can be sent without EADDRINUSE
even if the UDP address:port in use is specified.

  /src/sys/arch/x86/include/
apicvar.h 1.5.80.1 Wed Aug 05 16:20:08 UTC 2020 martin Pull up the following revisions, requested by msaitoh in ticket #1593:

sys/arch/x86/conf/files.x86 1.108
sys/arch/x86/include/apicvar.h 1.7 via patch
sys/arch/x86/include/cpu.h 1.121
sys/arch/x86/x86/cpu.c 1.185 via patch
sys/arch/x86/x86/hyperv.c 1.7
sys/arch/x86/x86/tsc.c 1.41
sys/arch/xen/conf/files.xen 1.181

Get TSC frequency from CPUID 0x15 and/or x16 if it's available.
This change fixes a problem that newer Intel processors' timer
counts very slowly.

1.6.2.1 Wed Jul 15 17:25:08 UTC 2020 martin Pull up the following, requested by msaitoh in ticket #1015

sys/arch/x86/conf/files.x86 1.108 (via patch)
sys/arch/x86/include/apicvar.h 1.7 (via patch)
sys/arch/x86/include/cpu.h 1.121 (via patch)
sys/arch/x86/x86/cpu.c 1.185 (via patch)
sys/arch/x86/x86/hyperv.c 1.7 (via patch)
sys/arch/x86/x86/tsc.c 1.41 (via patch)
sys/arch/xen/conf/files.xen 1.181 (via patch)

Get TSC frequency from CPUID 0x15 and/or x16 if it's available.
This change fixes a problem that newer Intel processors' timer
counts very slowly.

  /src/sys/arch/x86/x86/
identcpu_subr.c 1.7.4.3 Fri Dec 24 13:02:25 UTC 2021 martin Pull up the following (all via patch), requested by msaitoh in ticket #1721:

usr.sbin/cpuctl/arch/i386.c 1.118-1.119, 1.121-1.122
usr.sbin/cpuctl/arch/cpuctl_i386.h 1.6
sys/arch/x86/x86/identcpu_subr.c 1.8-1.9
sys/arch/x86/x86/identcpu.c 1.123
sys/arch/x86/include/cacheinfo.h 1.30
sys/arch/x86/include/cpu.h 1.132

- Fix a bug that some TLB related lines were not printed.
- Fix a bug that STLB is printed as DTLB.
- If a TLB is variable sized, print the max size instead of error message.
- Cosmetic changes to improve readability.

1.7.2.3 Fri Dec 24 00:58:14 UTC 2021 martin Pull up the following (all via patch), requested by msaitoh in ticket #1396:

usr.sbin/cpuctl/arch/i386.c 1.118-1.119, 1.121-1.122
usr.sbin/cpuctl/arch/cpuctl_i386.h 1.6
sys/arch/x86/x86/identcpu_subr.c 1.8-1.9
sys/arch/x86/x86/identcpu.c 1.123
sys/arch/x86/include/cacheinfo.h 1.30
sys/arch/x86/include/cpu.h 1.132

- Fix a bug that some TLB related lines were not printed.
- Fix a bug that STLB is printed as DTLB.
- If a TLB is variable sized, print the max size instead of error message.
- Cosmetic changes to improve readability.

  /src/sys/dev/pcmcia/
pcmciadevs 1.121 Mon Feb 19 21:30:38 UTC 2001 aymeric branches: 1.121.2;
Add an entry for the Synergy 21 S21810+
From Stefan Blomen <Stefan.Blomen@gmx.de>
Mon Feb 19 21:30:38 UTC 2001 aymeric branches: 1.121.2;
Add an entry for the Synergy 21 S21810+
From Stefan Blomen <Stefan.Blomen@gmx.de>
1.93.2.4 Fri Mar 16 19:35:14 UTC 2001 he Pull up revision 1.121 (via patch, requested by aymeric):
Add an entry and support for the Synergy 21 S21810+.
1.121.2.16 Fri Jan 17 16:32:00 UTC 2003 thorpej Sync with HEAD.
1.121.2.15 Sun Dec 29 20:49:30 UTC 2002 thorpej Sync with HEAD.
1.121.2.14 Tue Sep 17 21:20:36 UTC 2002 nathanw Catch up to -current.
1.121.2.13 Thu Aug 01 02:45:32 UTC 2002 nathanw Catch up to -current.
1.121.2.12 Thu Jun 20 03:46:15 UTC 2002 nathanw Catch up to -current.
1.121.2.11 Wed Apr 17 00:06:08 UTC 2002 nathanw Catch up to -current.
1.121.2.10 Mon Apr 01 07:46:55 UTC 2002 nathanw Catch up to -current.
(CVS: It's not just a program. It's an adventure!)
  /src/sys/dev/raidframe/
raidframevar.h 1.12.10.4 Thu Nov 20 09:38:56 UTC 2014 sborrill Pull up the following revisions(s) (requested by oster in ticket #1933):
sys/dev/raidframe/raidframevar.h: revision 1.17
sys/dev/raidframe/rf_netbsdkintf.c: revision 1.316
sys/dev/raidframe/rf_reconstruct.c: revision 1.121 via patch

Fix a long-standing bug related to rebooting while a reconstruct-to-spare
is underway but not yet complete. Fixes PR kern/49244.

1.12.10.3.2.1 Thu Nov 20 00:25:10 UTC 2014 sborrill Pull up the following revisions(s) (requested by oster in ticket #1933):
sys/dev/raidframe/raidframevar.h: revision 1.17
sys/dev/raidframe/rf_netbsdkintf.c: revision 1.316
sys/dev/raidframe/rf_reconstruct.c: revision 1.121 via patch

Fix a long-standing bug related to rebooting while a reconstruct-to-spare
is underway but not yet complete. Fixes PR kern/49244.

1.12.10.1.2.1 Thu Nov 20 15:52:10 UTC 2014 sborrill Pull up the following revisions(s) (requested by oster in ticket #1933):
sys/dev/raidframe/raidframevar.h: revision 1.17
sys/dev/raidframe/rf_netbsdkintf.c: revision 1.316
sys/dev/raidframe/rf_reconstruct.c: revision 1.121 via patch

Fix a long-standing bug related to rebooting while a reconstruct-to-spare
is underway but not yet complete. Fixes PR kern/49244.

1.15.24.1 Tue Dec 02 22:08:01 UTC 2014 snj Pull up following revision(s) (requested by oster in ticket #1194):
sys/dev/raidframe/raidframevar.h: revision 1.17
sys/dev/raidframe/rf_netbsdkintf.c: revision 1.316
sys/dev/raidframe/rf_reconstruct.c: revision 1.121
Fix a long-standing bug related to rebooting while a
reconstruct-to-spare is underway but not yet complete.
The issue was that a component was being marked as a used_spare when
the rebuild started, not when the rebuild was actually finished.
Marking it as a used_spare meant that the component label on the spare
was being updated such that after a reboot the component would be
considered up-to-date, regardless of whether the rebuild actually
completed!
This fix includes:
1) Add an additional state "rf_ds_rebuilding_spare" which is used
to denote that a spare is currently being rebuilt from the live
components.
2) Update the comments on the disk states, which were out-of-sync
with reality.
3) When rebuilding to a spare component, that spare now enters the
state rf_ds_rebuilding_spare instead of the state rf_ds_used_spare.
4) When the rebuild is actually complete then the spare component
enters the rf_ds_used_spare state. rf_ds_used_spare is now used
exclusively for the case where the rebuilding to the spare has
completed successfully.
XXX: Someday we need to teach raidctl(8) about this new state, and
take out the backwards compatibility code in rf_netbsdkintf.c (see
RAIDFRAME_GET_INFO in raidioctl()). For today, this fix needs to be
generic enough that it can get backported without major grief.
XXX: Needs pullup to netbsd-5*, netbsd-6*, and netbsd-7
Fixes PR#49244.

1.15.16.1 Tue Dec 02 22:06:58 UTC 2014 snj Pull up following revision(s) (requested by oster in ticket #1194):
sys/dev/raidframe/raidframevar.h: revision 1.17
sys/dev/raidframe/rf_netbsdkintf.c: revision 1.316
sys/dev/raidframe/rf_reconstruct.c: revision 1.121
Fix a long-standing bug related to rebooting while a
reconstruct-to-spare is underway but not yet complete.
The issue was that a component was being marked as a used_spare when
the rebuild started, not when the rebuild was actually finished.
Marking it as a used_spare meant that the component label on the spare
was being updated such that after a reboot the component would be
considered up-to-date, regardless of whether the rebuild actually
completed!
This fix includes:
1) Add an additional state "rf_ds_rebuilding_spare" which is used
to denote that a spare is currently being rebuilt from the live
components.
2) Update the comments on the disk states, which were out-of-sync
with reality.
3) When rebuilding to a spare component, that spare now enters the
state rf_ds_rebuilding_spare instead of the state rf_ds_used_spare.
4) When the rebuild is actually complete then the spare component
enters the rf_ds_used_spare state. rf_ds_used_spare is now used
exclusively for the case where the rebuilding to the spare has
completed successfully.
XXX: Someday we need to teach raidctl(8) about this new state, and
take out the backwards compatibility code in rf_netbsdkintf.c (see
RAIDFRAME_GET_INFO in raidioctl()). For today, this fix needs to be
generic enough that it can get backported without major grief.
XXX: Needs pullup to netbsd-5*, netbsd-6*, and netbsd-7
Fixes PR#49244.

1.15.10.1 Tue Dec 02 22:05:14 UTC 2014 snj Pull up following revision(s) (requested by oster in ticket #1194):
sys/dev/raidframe/raidframevar.h: revision 1.17
sys/dev/raidframe/rf_netbsdkintf.c: revision 1.316
sys/dev/raidframe/rf_reconstruct.c: revision 1.121
Fix a long-standing bug related to rebooting while a
reconstruct-to-spare is underway but not yet complete.
The issue was that a component was being marked as a used_spare when
the rebuild started, not when the rebuild was actually finished.
Marking it as a used_spare meant that the component label on the spare
was being updated such that after a reboot the component would be
considered up-to-date, regardless of whether the rebuild actually
completed!
This fix includes:
1) Add an additional state "rf_ds_rebuilding_spare" which is used
to denote that a spare is currently being rebuilt from the live
components.
2) Update the comments on the disk states, which were out-of-sync
with reality.
3) When rebuilding to a spare component, that spare now enters the
state rf_ds_rebuilding_spare instead of the state rf_ds_used_spare.
4) When the rebuild is actually complete then the spare component
enters the rf_ds_used_spare state. rf_ds_used_spare is now used
exclusively for the case where the rebuilding to the spare has
completed successfully.
XXX: Someday we need to teach raidctl(8) about this new state, and
take out the backwards compatibility code in rf_netbsdkintf.c (see
RAIDFRAME_GET_INFO in raidioctl()). For today, this fix needs to be
generic enough that it can get backported without major grief.
XXX: Needs pullup to netbsd-5*, netbsd-6*, and netbsd-7
Fixes PR#49244.

1.16.4.1 Tue Nov 18 18:03:10 UTC 2014 snj Pull up following revision(s) (requested by oster in ticket #243):
sys/dev/raidframe/raidframevar.h: revision 1.17
sys/dev/raidframe/rf_netbsdkintf.c: revision 1.316
sys/dev/raidframe/rf_reconstruct.c: revision 1.121
Fix a long-standing bug related to rebooting while a
reconstruct-to-spare is underway but not yet complete.
The issue was that a component was being marked as a used_spare when
the rebuild started, not when the rebuild was actually finished.
Marking it as a used_spare meant that the component label on the spare
was being updated such that after a reboot the component would be
considered up-to-date, regardless of whether the rebuild actually
completed!
This fix includes:
1) Add an additional state "rf_ds_rebuilding_spare" which is used
to denote that a spare is currently being rebuilt from the live
components.
2) Update the comments on the disk states, which were out-of-sync
with reality.
3) When rebuilding to a spare component, that spare now enters the
state rf_ds_rebuilding_spare instead of the state rf_ds_used_spare.
4) When the rebuild is actually complete then the spare component
enters the rf_ds_used_spare state. rf_ds_used_spare is now used
exclusively for the case where the rebuilding to the spare has
completed successfully.
XXX: Someday we need to teach raidctl(8) about this new state, and
take out the backwards compatibility code in rf_netbsdkintf.c (see
RAIDFRAME_GET_INFO in raidioctl()). For today, this fix needs to be
generic enough that it can get backported without major grief.
XXX: Needs pullup to netbsd-5*, netbsd-6*, and netbsd-7
Fixes PR#49244.

  /src/distrib/notes/ews4800mips/
hardware 1.1.2.3 Sat Dec 15 19:34:04 UTC 2007 bouyer Pull up following revisions (requested by jnemeth in ticket #1017):
distrib/notes/common/contents patch
distrib/notes/common/list-setsizes.sh patch
distrib/notes/pmppc/hardware patch
distrib/notes/Makefile.inc 1.39, 1.40
distrib/notes/acorn32/prep.RISCOS 1.18
distrib/notes/alpha/install 1.32
distrib/notes/common/main 1.367, 1.368, 1.370 - 1.382
distrib/notes/common/netboot 1.31
distrib/notes/common/postinstall 1.64, 1.65
distrib/notes/common/sysinst 1.82, 1.83
distrib/notes/common/xfer 1.58 - 1.60
distrib/notes/evbppc/hardware 1.3
distrib/notes/ews4800mips/hardware 1.2
distrib/notes/hp300/hardware 1.19
distrib/notes/hp300/prep 1.21
distrib/notes/hp700/hardware 1.3
distrib/notes/i386/hardware 1.121
distrib/notes/i386/whatis 1.22
distrib/notes/mac68k/hardware 1.23
distrib/notes/mac68k/install 1.28
distrib/notes/macppc/hardware 1.44
distrib/notes/macppc/install 1.36
distrib/notes/macppc/prep 1.42
distrib/notes/macppc/prep.OPENFIRMWARE 1.9
distrib/notes/news68k/hardware 1.5
distrib/notes/newsmips/hardware 1.4
distrib/notes/next68k/hardware 1.8
distrib/notes/pmax/install 1.39
distrib/notes/sandpoint/hardware 1.6
distrib/notes/sparc/hardware 1.33
distrib/notes/sparc64/hardware 1.23
distrib/notes/sparc64/install 1.28
distrib/notes/vax/xfer 1.13
Sync release notes with reality

  /src/distrib/notes/news68k/
hardware 1.4.16.1 Sat Dec 15 19:34:10 UTC 2007 bouyer Pull up following revisions (requested by jnemeth in ticket #1017):
distrib/notes/common/contents patch
distrib/notes/common/list-setsizes.sh patch
distrib/notes/pmppc/hardware patch
distrib/notes/Makefile.inc 1.39, 1.40
distrib/notes/acorn32/prep.RISCOS 1.18
distrib/notes/alpha/install 1.32
distrib/notes/common/main 1.367, 1.368, 1.370 - 1.382
distrib/notes/common/netboot 1.31
distrib/notes/common/postinstall 1.64, 1.65
distrib/notes/common/sysinst 1.82, 1.83
distrib/notes/common/xfer 1.58 - 1.60
distrib/notes/evbppc/hardware 1.3
distrib/notes/ews4800mips/hardware 1.2
distrib/notes/hp300/hardware 1.19
distrib/notes/hp300/prep 1.21
distrib/notes/hp700/hardware 1.3
distrib/notes/i386/hardware 1.121
distrib/notes/i386/whatis 1.22
distrib/notes/mac68k/hardware 1.23
distrib/notes/mac68k/install 1.28
distrib/notes/macppc/hardware 1.44
distrib/notes/macppc/install 1.36
distrib/notes/macppc/prep 1.42
distrib/notes/macppc/prep.OPENFIRMWARE 1.9
distrib/notes/news68k/hardware 1.5
distrib/notes/newsmips/hardware 1.4
distrib/notes/next68k/hardware 1.8
distrib/notes/pmax/install 1.39
distrib/notes/sandpoint/hardware 1.6
distrib/notes/sparc/hardware 1.33
distrib/notes/sparc64/hardware 1.23
distrib/notes/sparc64/install 1.28
distrib/notes/vax/xfer 1.13
Sync release notes with reality

  /src/distrib/notes/newsmips/
hardware 1.2.16.2 Sat Dec 15 19:34:11 UTC 2007 bouyer Pull up following revisions (requested by jnemeth in ticket #1017):
distrib/notes/common/contents patch
distrib/notes/common/list-setsizes.sh patch
distrib/notes/pmppc/hardware patch
distrib/notes/Makefile.inc 1.39, 1.40
distrib/notes/acorn32/prep.RISCOS 1.18
distrib/notes/alpha/install 1.32
distrib/notes/common/main 1.367, 1.368, 1.370 - 1.382
distrib/notes/common/netboot 1.31
distrib/notes/common/postinstall 1.64, 1.65
distrib/notes/common/sysinst 1.82, 1.83
distrib/notes/common/xfer 1.58 - 1.60
distrib/notes/evbppc/hardware 1.3
distrib/notes/ews4800mips/hardware 1.2
distrib/notes/hp300/hardware 1.19
distrib/notes/hp300/prep 1.21
distrib/notes/hp700/hardware 1.3
distrib/notes/i386/hardware 1.121
distrib/notes/i386/whatis 1.22
distrib/notes/mac68k/hardware 1.23
distrib/notes/mac68k/install 1.28
distrib/notes/macppc/hardware 1.44
distrib/notes/macppc/install 1.36
distrib/notes/macppc/prep 1.42
distrib/notes/macppc/prep.OPENFIRMWARE 1.9
distrib/notes/news68k/hardware 1.5
distrib/notes/newsmips/hardware 1.4
distrib/notes/next68k/hardware 1.8
distrib/notes/pmax/install 1.39
distrib/notes/sandpoint/hardware 1.6
distrib/notes/sparc/hardware 1.33
distrib/notes/sparc64/hardware 1.23
distrib/notes/sparc64/install 1.28
distrib/notes/vax/xfer 1.13
Sync release notes with reality
  /src/distrib/notes/next68k/
hardware 1.7.16.1 Sat Dec 15 19:34:11 UTC 2007 bouyer Pull up following revisions (requested by jnemeth in ticket #1017):
distrib/notes/common/contents patch
distrib/notes/common/list-setsizes.sh patch
distrib/notes/pmppc/hardware patch
distrib/notes/Makefile.inc 1.39, 1.40
distrib/notes/acorn32/prep.RISCOS 1.18
distrib/notes/alpha/install 1.32
distrib/notes/common/main 1.367, 1.368, 1.370 - 1.382
distrib/notes/common/netboot 1.31
distrib/notes/common/postinstall 1.64, 1.65
distrib/notes/common/sysinst 1.82, 1.83
distrib/notes/common/xfer 1.58 - 1.60
distrib/notes/evbppc/hardware 1.3
distrib/notes/ews4800mips/hardware 1.2
distrib/notes/hp300/hardware 1.19
distrib/notes/hp300/prep 1.21
distrib/notes/hp700/hardware 1.3
distrib/notes/i386/hardware 1.121
distrib/notes/i386/whatis 1.22
distrib/notes/mac68k/hardware 1.23
distrib/notes/mac68k/install 1.28
distrib/notes/macppc/hardware 1.44
distrib/notes/macppc/install 1.36
distrib/notes/macppc/prep 1.42
distrib/notes/macppc/prep.OPENFIRMWARE 1.9
distrib/notes/news68k/hardware 1.5
distrib/notes/newsmips/hardware 1.4
distrib/notes/next68k/hardware 1.8
distrib/notes/pmax/install 1.39
distrib/notes/sandpoint/hardware 1.6
distrib/notes/sparc/hardware 1.33
distrib/notes/sparc64/hardware 1.23
distrib/notes/sparc64/install 1.28
distrib/notes/vax/xfer 1.13
Sync release notes with reality

  /src/distrib/notes/sandpoint/
hardware 1.5.16.1 Sat Dec 15 19:34:13 UTC 2007 bouyer Pull up following revisions (requested by jnemeth in ticket #1017):
distrib/notes/common/contents patch
distrib/notes/common/list-setsizes.sh patch
distrib/notes/pmppc/hardware patch
distrib/notes/Makefile.inc 1.39, 1.40
distrib/notes/acorn32/prep.RISCOS 1.18
distrib/notes/alpha/install 1.32
distrib/notes/common/main 1.367, 1.368, 1.370 - 1.382
distrib/notes/common/netboot 1.31
distrib/notes/common/postinstall 1.64, 1.65
distrib/notes/common/sysinst 1.82, 1.83
distrib/notes/common/xfer 1.58 - 1.60
distrib/notes/evbppc/hardware 1.3
distrib/notes/ews4800mips/hardware 1.2
distrib/notes/hp300/hardware 1.19
distrib/notes/hp300/prep 1.21
distrib/notes/hp700/hardware 1.3
distrib/notes/i386/hardware 1.121
distrib/notes/i386/whatis 1.22
distrib/notes/mac68k/hardware 1.23
distrib/notes/mac68k/install 1.28
distrib/notes/macppc/hardware 1.44
distrib/notes/macppc/install 1.36
distrib/notes/macppc/prep 1.42
distrib/notes/macppc/prep.OPENFIRMWARE 1.9
distrib/notes/news68k/hardware 1.5
distrib/notes/newsmips/hardware 1.4
distrib/notes/next68k/hardware 1.8
distrib/notes/pmax/install 1.39
distrib/notes/sandpoint/hardware 1.6
distrib/notes/sparc/hardware 1.33
distrib/notes/sparc64/hardware 1.23
distrib/notes/sparc64/install 1.28
distrib/notes/vax/xfer 1.13
Sync release notes with reality

  /src/share/man/man4/man4.sparc64/
Makefile 1.4.18.1 Fri Oct 16 11:56:10 UTC 2009 sborrill Pull up the following revisions(s) (requested by nakayama in ticket #1064):
distrib/sets/lists/man/mi: revision 1.1161
share/man/man4/man4.sparc64/Makefile: revision 1.5
share/man/man4/man4.sparc64/lom.4: revision 1.1-1.2
sys/arch/sparc64/conf/GENERIC: revision 1.111
sys/arch/sparc64/conf/files.sparc64: revision 1.121
sys/arch/sparc64/dev/lom.c: revision 1.1
sys/dev/DEVNAMES: revision 1.252

Add a driver for LOMlite lights out management hardware monitor and watchdog
timer.
lom.4 1.2.2.2 Fri Oct 16 11:56:10 UTC 2009 sborrill Pull up the following revisions(s) (requested by nakayama in ticket #1064):
distrib/sets/lists/man/mi: revision 1.1161
share/man/man4/man4.sparc64/Makefile: revision 1.5
share/man/man4/man4.sparc64/lom.4: revision 1.1-1.2
sys/arch/sparc64/conf/GENERIC: revision 1.111
sys/arch/sparc64/conf/files.sparc64: revision 1.121
sys/arch/sparc64/dev/lom.c: revision 1.1
sys/dev/DEVNAMES: revision 1.252

Add a driver for LOMlite lights out management hardware monitor and watchdog
timer.

  /src/share/man/man8/man8.x86/
dosboot.8 1.3.22.1 Sat May 13 13:26:56 UTC 2023 martin Pull up following revision(s) (requested by manu in ticket #159):

share/man/man8/man8.x86/boot.8: revision 1.27
sys/arch/i386/stand/efiboot/version: revision 1.3
share/man/man8/man8.x86/boot.8: revision 1.28
share/man/man8/man8.x86/boot.8: revision 1.29
sys/arch/i386/stand/lib/exec.c: revision 1.79
sys/arch/i386/stand/efiboot/efiboot.c: revision 1.13
sys/arch/i386/stand/efiboot/bootx64/efibootx64.c: revision 1.6
sys/arch/i386/stand/efiboot/bootia32/efibootia32.c: revision 1.6
sys/arch/i386/stand/efiboot/boot.c: revision 1.22
sys/arch/amd64/amd64/locore.S: revision 1.219
sys/arch/i386/stand/efiboot/bootia32/startprog32.S: revision 1.3
sys/arch/i386/stand/efiboot/efiboot.h: revision 1.12
sys/arch/amd64/conf/files.amd64: revision 1.121
sys/arch/amd64/conf/std.amd64: revision 1.13
share/man/man8/man8.x86/pxeboot.8: revision 1.6
sys/arch/i386/stand/efiboot/bootx64/startprog64.S: revision 1.4
sys/arch/amd64/amd64/locore.S: revision 1.220
share/man/man8/man8.x86/dosboot.8: revision 1.4
share/man/man4/options.4: revision 1.524

Add reloc keyworkd to let EFI bootstrap load amd64 kernel at any address

EFI bootstrap assumes it can copy the amd64 kernel to its ELF load
address (that is KERNTEXTOFF - KERNBASE = 0x200000), but it can
clash with previous UEFI memory allocation, as described here:
http://mail-index.netbsd.org/tech-kern/2023/04/07/msg028833.html

This change adds a reloc keyword for controling where the EFI
boostrap will copy the kernel image. Possible values are:
default - the default and prior behavior, copy at 0x200000.
none - do not copy and use the kernel image where it was loaded.
address - specify an explicit address where to copy the kernel.

This comes with an amd64 kernel patch that makes it self-relocatable.
It first discover where it was loaded in memory, and if this is
different than the expected 0x200000, hhe the kernel relocates
itself and start over at the right address.


Merge x86 boot options in x86/boot(8) and add undocumented UEFI options

We were supposed to keep the option list in x86/boot(8), x86/dosoot(8)
and x86/pxeboot(8) in sync, but it did not happen, hence it may work
better with all the options in x86/boot(8). Also add the undocumented
UEFI boot options.


Add a SELFRELOC kernel option for the sake of documentation clarity.
Instead of telling that x86/boot(8) reloc command needs a kernel able
to self relocate, we can tell it needs a kernel built with the
SELFRELOC option. This keeps the reader from wondering what could
make a kernel able to self relocate.

Remove XXX todo marker left by mistake

Raise the version for new feature (here reloc command)
Suggested by Masanobu SAITOH

1.3.14.1 Sat May 13 11:45:53 UTC 2023 martin Pull up following revision(s) (requested by manu in ticket #1632):

share/man/man8/man8.x86/boot.8: revision 1.27
sys/arch/i386/stand/efiboot/version: revision 1.3
share/man/man8/man8.x86/boot.8: revision 1.28 (via patch)
share/man/man8/man8.x86/boot.8: revision 1.29 (via patch)
sys/arch/i386/stand/lib/exec.c: revision 1.79
sys/arch/i386/stand/efiboot/efiboot.c: revision 1.13
sys/arch/i386/stand/efiboot/bootx64/efibootx64.c: revision 1.6
sys/arch/i386/stand/efiboot/bootia32/efibootia32.c: revision 1.6
sys/arch/i386/stand/efiboot/boot.c: revision 1.22
sys/arch/amd64/amd64/locore.S: revision 1.219
sys/arch/i386/stand/efiboot/bootia32/startprog32.S: revision 1.3
sys/arch/i386/stand/efiboot/efiboot.h: revision 1.12
sys/arch/amd64/conf/files.amd64: revision 1.121
sys/arch/amd64/conf/std.amd64: revision 1.13
share/man/man8/man8.x86/pxeboot.8: revision 1.6
sys/arch/i386/stand/efiboot/bootx64/startprog64.S: revision 1.4
sys/arch/amd64/amd64/locore.S: revision 1.220
share/man/man8/man8.x86/dosboot.8: revision 1.4
share/man/man4/options.4: revision 1.524

Add reloc keyworkd to let EFI bootstrap load amd64 kernel at any address

EFI bootstrap assumes it can copy the amd64 kernel to its ELF load
address (that is KERNTEXTOFF - KERNBASE = 0x200000), but it can
clash with previous UEFI memory allocation, as described here:
http://mail-index.netbsd.org/tech-kern/2023/04/07/msg028833.html

This change adds a reloc keyword for controling where the EFI
boostrap will copy the kernel image. Possible values are:
default - the default and prior behavior, copy at 0x200000.
none - do not copy and use the kernel image where it was loaded.
address - specify an explicit address where to copy the kernel.

This comes with an amd64 kernel patch that makes it self-relocatable.
It first discover where it was loaded in memory, and if this is
different than the expected 0x200000, hhe the kernel relocates
itself and start over at the right address.

Merge x86 boot options in x86/boot(8) and add undocumented UEFI options

We were supposed to keep the option list in x86/boot(8), x86/dosoot(8)
and x86/pxeboot(8) in sync, but it did not happen, hence it may work
better with all the options in x86/boot(8). Also add the undocumented
UEFI boot options.

Add a SELFRELOC kernel option for the sake of documentation clarity.
Instead of telling that x86/boot(8) reloc command needs a kernel able
to self relocate, we can tell it needs a kernel built with the
SELFRELOC option. This keeps the reader from wondering what could
make a kernel able to self relocate.

Remove XXX todo marker left by mistake

Raise the version for new feature (here reloc command)
Suggested by Masanobu SAITOH

pxeboot.8 1.4.14.1 Sat May 13 11:45:53 UTC 2023 martin Pull up following revision(s) (requested by manu in ticket #1632):

share/man/man8/man8.x86/boot.8: revision 1.27
sys/arch/i386/stand/efiboot/version: revision 1.3
share/man/man8/man8.x86/boot.8: revision 1.28 (via patch)
share/man/man8/man8.x86/boot.8: revision 1.29 (via patch)
sys/arch/i386/stand/lib/exec.c: revision 1.79
sys/arch/i386/stand/efiboot/efiboot.c: revision 1.13
sys/arch/i386/stand/efiboot/bootx64/efibootx64.c: revision 1.6
sys/arch/i386/stand/efiboot/bootia32/efibootia32.c: revision 1.6
sys/arch/i386/stand/efiboot/boot.c: revision 1.22
sys/arch/amd64/amd64/locore.S: revision 1.219
sys/arch/i386/stand/efiboot/bootia32/startprog32.S: revision 1.3
sys/arch/i386/stand/efiboot/efiboot.h: revision 1.12
sys/arch/amd64/conf/files.amd64: revision 1.121
sys/arch/amd64/conf/std.amd64: revision 1.13
share/man/man8/man8.x86/pxeboot.8: revision 1.6
sys/arch/i386/stand/efiboot/bootx64/startprog64.S: revision 1.4
sys/arch/amd64/amd64/locore.S: revision 1.220
share/man/man8/man8.x86/dosboot.8: revision 1.4
share/man/man4/options.4: revision 1.524

Add reloc keyworkd to let EFI bootstrap load amd64 kernel at any address

EFI bootstrap assumes it can copy the amd64 kernel to its ELF load
address (that is KERNTEXTOFF - KERNBASE = 0x200000), but it can
clash with previous UEFI memory allocation, as described here:
http://mail-index.netbsd.org/tech-kern/2023/04/07/msg028833.html

This change adds a reloc keyword for controling where the EFI
boostrap will copy the kernel image. Possible values are:
default - the default and prior behavior, copy at 0x200000.
none - do not copy and use the kernel image where it was loaded.
address - specify an explicit address where to copy the kernel.

This comes with an amd64 kernel patch that makes it self-relocatable.
It first discover where it was loaded in memory, and if this is
different than the expected 0x200000, hhe the kernel relocates
itself and start over at the right address.

Merge x86 boot options in x86/boot(8) and add undocumented UEFI options

We were supposed to keep the option list in x86/boot(8), x86/dosoot(8)
and x86/pxeboot(8) in sync, but it did not happen, hence it may work
better with all the options in x86/boot(8). Also add the undocumented
UEFI boot options.

Add a SELFRELOC kernel option for the sake of documentation clarity.
Instead of telling that x86/boot(8) reloc command needs a kernel able
to self relocate, we can tell it needs a kernel built with the
SELFRELOC option. This keeps the reader from wondering what could
make a kernel able to self relocate.

Remove XXX todo marker left by mistake

Raise the version for new feature (here reloc command)
Suggested by Masanobu SAITOH

1.5.6.1 Sat May 13 13:26:56 UTC 2023 martin Pull up following revision(s) (requested by manu in ticket #159):

share/man/man8/man8.x86/boot.8: revision 1.27
sys/arch/i386/stand/efiboot/version: revision 1.3
share/man/man8/man8.x86/boot.8: revision 1.28
share/man/man8/man8.x86/boot.8: revision 1.29
sys/arch/i386/stand/lib/exec.c: revision 1.79
sys/arch/i386/stand/efiboot/efiboot.c: revision 1.13
sys/arch/i386/stand/efiboot/bootx64/efibootx64.c: revision 1.6
sys/arch/i386/stand/efiboot/bootia32/efibootia32.c: revision 1.6
sys/arch/i386/stand/efiboot/boot.c: revision 1.22
sys/arch/amd64/amd64/locore.S: revision 1.219
sys/arch/i386/stand/efiboot/bootia32/startprog32.S: revision 1.3
sys/arch/i386/stand/efiboot/efiboot.h: revision 1.12
sys/arch/amd64/conf/files.amd64: revision 1.121
sys/arch/amd64/conf/std.amd64: revision 1.13
share/man/man8/man8.x86/pxeboot.8: revision 1.6
sys/arch/i386/stand/efiboot/bootx64/startprog64.S: revision 1.4
sys/arch/amd64/amd64/locore.S: revision 1.220
share/man/man8/man8.x86/dosboot.8: revision 1.4
share/man/man4/options.4: revision 1.524

Add reloc keyworkd to let EFI bootstrap load amd64 kernel at any address

EFI bootstrap assumes it can copy the amd64 kernel to its ELF load
address (that is KERNTEXTOFF - KERNBASE = 0x200000), but it can
clash with previous UEFI memory allocation, as described here:
http://mail-index.netbsd.org/tech-kern/2023/04/07/msg028833.html

This change adds a reloc keyword for controling where the EFI
boostrap will copy the kernel image. Possible values are:
default - the default and prior behavior, copy at 0x200000.
none - do not copy and use the kernel image where it was loaded.
address - specify an explicit address where to copy the kernel.

This comes with an amd64 kernel patch that makes it self-relocatable.
It first discover where it was loaded in memory, and if this is
different than the expected 0x200000, hhe the kernel relocates
itself and start over at the right address.


Merge x86 boot options in x86/boot(8) and add undocumented UEFI options

We were supposed to keep the option list in x86/boot(8), x86/dosoot(8)
and x86/pxeboot(8) in sync, but it did not happen, hence it may work
better with all the options in x86/boot(8). Also add the undocumented
UEFI boot options.


Add a SELFRELOC kernel option for the sake of documentation clarity.
Instead of telling that x86/boot(8) reloc command needs a kernel able
to self relocate, we can tell it needs a kernel built with the
SELFRELOC option. This keeps the reader from wondering what could
make a kernel able to self relocate.

Remove XXX todo marker left by mistake

Raise the version for new feature (here reloc command)
Suggested by Masanobu SAITOH

  /src/sys/arch/i386/stand/efiboot/bootia32/
startprog32.S 1.2.52.1 Sat May 13 13:26:57 UTC 2023 martin Pull up following revision(s) (requested by manu in ticket #159):

share/man/man8/man8.x86/boot.8: revision 1.27
sys/arch/i386/stand/efiboot/version: revision 1.3
share/man/man8/man8.x86/boot.8: revision 1.28
share/man/man8/man8.x86/boot.8: revision 1.29
sys/arch/i386/stand/lib/exec.c: revision 1.79
sys/arch/i386/stand/efiboot/efiboot.c: revision 1.13
sys/arch/i386/stand/efiboot/bootx64/efibootx64.c: revision 1.6
sys/arch/i386/stand/efiboot/bootia32/efibootia32.c: revision 1.6
sys/arch/i386/stand/efiboot/boot.c: revision 1.22
sys/arch/amd64/amd64/locore.S: revision 1.219
sys/arch/i386/stand/efiboot/bootia32/startprog32.S: revision 1.3
sys/arch/i386/stand/efiboot/efiboot.h: revision 1.12
sys/arch/amd64/conf/files.amd64: revision 1.121
sys/arch/amd64/conf/std.amd64: revision 1.13
share/man/man8/man8.x86/pxeboot.8: revision 1.6
sys/arch/i386/stand/efiboot/bootx64/startprog64.S: revision 1.4
sys/arch/amd64/amd64/locore.S: revision 1.220
share/man/man8/man8.x86/dosboot.8: revision 1.4
share/man/man4/options.4: revision 1.524

Add reloc keyworkd to let EFI bootstrap load amd64 kernel at any address

EFI bootstrap assumes it can copy the amd64 kernel to its ELF load
address (that is KERNTEXTOFF - KERNBASE = 0x200000), but it can
clash with previous UEFI memory allocation, as described here:
http://mail-index.netbsd.org/tech-kern/2023/04/07/msg028833.html

This change adds a reloc keyword for controling where the EFI
boostrap will copy the kernel image. Possible values are:
default - the default and prior behavior, copy at 0x200000.
none - do not copy and use the kernel image where it was loaded.
address - specify an explicit address where to copy the kernel.

This comes with an amd64 kernel patch that makes it self-relocatable.
It first discover where it was loaded in memory, and if this is
different than the expected 0x200000, hhe the kernel relocates
itself and start over at the right address.


Merge x86 boot options in x86/boot(8) and add undocumented UEFI options

We were supposed to keep the option list in x86/boot(8), x86/dosoot(8)
and x86/pxeboot(8) in sync, but it did not happen, hence it may work
better with all the options in x86/boot(8). Also add the undocumented
UEFI boot options.


Add a SELFRELOC kernel option for the sake of documentation clarity.
Instead of telling that x86/boot(8) reloc command needs a kernel able
to self relocate, we can tell it needs a kernel built with the
SELFRELOC option. This keeps the reader from wondering what could
make a kernel able to self relocate.

Remove XXX todo marker left by mistake

Raise the version for new feature (here reloc command)
Suggested by Masanobu SAITOH

1.2.26.1 Sat May 13 11:45:53 UTC 2023 martin Pull up following revision(s) (requested by manu in ticket #1632):

share/man/man8/man8.x86/boot.8: revision 1.27
sys/arch/i386/stand/efiboot/version: revision 1.3
share/man/man8/man8.x86/boot.8: revision 1.28 (via patch)
share/man/man8/man8.x86/boot.8: revision 1.29 (via patch)
sys/arch/i386/stand/lib/exec.c: revision 1.79
sys/arch/i386/stand/efiboot/efiboot.c: revision 1.13
sys/arch/i386/stand/efiboot/bootx64/efibootx64.c: revision 1.6
sys/arch/i386/stand/efiboot/bootia32/efibootia32.c: revision 1.6
sys/arch/i386/stand/efiboot/boot.c: revision 1.22
sys/arch/amd64/amd64/locore.S: revision 1.219
sys/arch/i386/stand/efiboot/bootia32/startprog32.S: revision 1.3
sys/arch/i386/stand/efiboot/efiboot.h: revision 1.12
sys/arch/amd64/conf/files.amd64: revision 1.121
sys/arch/amd64/conf/std.amd64: revision 1.13
share/man/man8/man8.x86/pxeboot.8: revision 1.6
sys/arch/i386/stand/efiboot/bootx64/startprog64.S: revision 1.4
sys/arch/amd64/amd64/locore.S: revision 1.220
share/man/man8/man8.x86/dosboot.8: revision 1.4
share/man/man4/options.4: revision 1.524

Add reloc keyworkd to let EFI bootstrap load amd64 kernel at any address

EFI bootstrap assumes it can copy the amd64 kernel to its ELF load
address (that is KERNTEXTOFF - KERNBASE = 0x200000), but it can
clash with previous UEFI memory allocation, as described here:
http://mail-index.netbsd.org/tech-kern/2023/04/07/msg028833.html

This change adds a reloc keyword for controling where the EFI
boostrap will copy the kernel image. Possible values are:
default - the default and prior behavior, copy at 0x200000.
none - do not copy and use the kernel image where it was loaded.
address - specify an explicit address where to copy the kernel.

This comes with an amd64 kernel patch that makes it self-relocatable.
It first discover where it was loaded in memory, and if this is
different than the expected 0x200000, hhe the kernel relocates
itself and start over at the right address.

Merge x86 boot options in x86/boot(8) and add undocumented UEFI options

We were supposed to keep the option list in x86/boot(8), x86/dosoot(8)
and x86/pxeboot(8) in sync, but it did not happen, hence it may work
better with all the options in x86/boot(8). Also add the undocumented
UEFI boot options.

Add a SELFRELOC kernel option for the sake of documentation clarity.
Instead of telling that x86/boot(8) reloc command needs a kernel able
to self relocate, we can tell it needs a kernel built with the
SELFRELOC option. This keeps the reader from wondering what could
make a kernel able to self relocate.

Remove XXX todo marker left by mistake

Raise the version for new feature (here reloc command)
Suggested by Masanobu SAITOH

  /src/sys/arch/i386/stand/efiboot/bootx64/
startprog64.S 1.3.50.1 Sat May 13 13:26:57 UTC 2023 martin Pull up following revision(s) (requested by manu in ticket #159):

share/man/man8/man8.x86/boot.8: revision 1.27
sys/arch/i386/stand/efiboot/version: revision 1.3
share/man/man8/man8.x86/boot.8: revision 1.28
share/man/man8/man8.x86/boot.8: revision 1.29
sys/arch/i386/stand/lib/exec.c: revision 1.79
sys/arch/i386/stand/efiboot/efiboot.c: revision 1.13
sys/arch/i386/stand/efiboot/bootx64/efibootx64.c: revision 1.6
sys/arch/i386/stand/efiboot/bootia32/efibootia32.c: revision 1.6
sys/arch/i386/stand/efiboot/boot.c: revision 1.22
sys/arch/amd64/amd64/locore.S: revision 1.219
sys/arch/i386/stand/efiboot/bootia32/startprog32.S: revision 1.3
sys/arch/i386/stand/efiboot/efiboot.h: revision 1.12
sys/arch/amd64/conf/files.amd64: revision 1.121
sys/arch/amd64/conf/std.amd64: revision 1.13
share/man/man8/man8.x86/pxeboot.8: revision 1.6
sys/arch/i386/stand/efiboot/bootx64/startprog64.S: revision 1.4
sys/arch/amd64/amd64/locore.S: revision 1.220
share/man/man8/man8.x86/dosboot.8: revision 1.4
share/man/man4/options.4: revision 1.524

Add reloc keyworkd to let EFI bootstrap load amd64 kernel at any address

EFI bootstrap assumes it can copy the amd64 kernel to its ELF load
address (that is KERNTEXTOFF - KERNBASE = 0x200000), but it can
clash with previous UEFI memory allocation, as described here:
http://mail-index.netbsd.org/tech-kern/2023/04/07/msg028833.html

This change adds a reloc keyword for controling where the EFI
boostrap will copy the kernel image. Possible values are:
default - the default and prior behavior, copy at 0x200000.
none - do not copy and use the kernel image where it was loaded.
address - specify an explicit address where to copy the kernel.

This comes with an amd64 kernel patch that makes it self-relocatable.
It first discover where it was loaded in memory, and if this is
different than the expected 0x200000, hhe the kernel relocates
itself and start over at the right address.


Merge x86 boot options in x86/boot(8) and add undocumented UEFI options

We were supposed to keep the option list in x86/boot(8), x86/dosoot(8)
and x86/pxeboot(8) in sync, but it did not happen, hence it may work
better with all the options in x86/boot(8). Also add the undocumented
UEFI boot options.


Add a SELFRELOC kernel option for the sake of documentation clarity.
Instead of telling that x86/boot(8) reloc command needs a kernel able
to self relocate, we can tell it needs a kernel built with the
SELFRELOC option. This keeps the reader from wondering what could
make a kernel able to self relocate.

Remove XXX todo marker left by mistake

Raise the version for new feature (here reloc command)
Suggested by Masanobu SAITOH

1.3.24.1 Sat May 13 11:45:53 UTC 2023 martin Pull up following revision(s) (requested by manu in ticket #1632):

share/man/man8/man8.x86/boot.8: revision 1.27
sys/arch/i386/stand/efiboot/version: revision 1.3
share/man/man8/man8.x86/boot.8: revision 1.28 (via patch)
share/man/man8/man8.x86/boot.8: revision 1.29 (via patch)
sys/arch/i386/stand/lib/exec.c: revision 1.79
sys/arch/i386/stand/efiboot/efiboot.c: revision 1.13
sys/arch/i386/stand/efiboot/bootx64/efibootx64.c: revision 1.6
sys/arch/i386/stand/efiboot/bootia32/efibootia32.c: revision 1.6
sys/arch/i386/stand/efiboot/boot.c: revision 1.22
sys/arch/amd64/amd64/locore.S: revision 1.219
sys/arch/i386/stand/efiboot/bootia32/startprog32.S: revision 1.3
sys/arch/i386/stand/efiboot/efiboot.h: revision 1.12
sys/arch/amd64/conf/files.amd64: revision 1.121
sys/arch/amd64/conf/std.amd64: revision 1.13
share/man/man8/man8.x86/pxeboot.8: revision 1.6
sys/arch/i386/stand/efiboot/bootx64/startprog64.S: revision 1.4
sys/arch/amd64/amd64/locore.S: revision 1.220
share/man/man8/man8.x86/dosboot.8: revision 1.4
share/man/man4/options.4: revision 1.524

Add reloc keyworkd to let EFI bootstrap load amd64 kernel at any address

EFI bootstrap assumes it can copy the amd64 kernel to its ELF load
address (that is KERNTEXTOFF - KERNBASE = 0x200000), but it can
clash with previous UEFI memory allocation, as described here:
http://mail-index.netbsd.org/tech-kern/2023/04/07/msg028833.html

This change adds a reloc keyword for controling where the EFI
boostrap will copy the kernel image. Possible values are:
default - the default and prior behavior, copy at 0x200000.
none - do not copy and use the kernel image where it was loaded.
address - specify an explicit address where to copy the kernel.

This comes with an amd64 kernel patch that makes it self-relocatable.
It first discover where it was loaded in memory, and if this is
different than the expected 0x200000, hhe the kernel relocates
itself and start over at the right address.

Merge x86 boot options in x86/boot(8) and add undocumented UEFI options

We were supposed to keep the option list in x86/boot(8), x86/dosoot(8)
and x86/pxeboot(8) in sync, but it did not happen, hence it may work
better with all the options in x86/boot(8). Also add the undocumented
UEFI boot options.

Add a SELFRELOC kernel option for the sake of documentation clarity.
Instead of telling that x86/boot(8) reloc command needs a kernel able
to self relocate, we can tell it needs a kernel built with the
SELFRELOC option. This keeps the reader from wondering what could
make a kernel able to self relocate.

Remove XXX todo marker left by mistake

Raise the version for new feature (here reloc command)
Suggested by Masanobu SAITOH

  /src/sys/arch/i386/stand/efiboot/
version 1.1.26.2 Sat May 13 11:45:53 UTC 2023 martin Pull up following revision(s) (requested by manu in ticket #1632):

share/man/man8/man8.x86/boot.8: revision 1.27
sys/arch/i386/stand/efiboot/version: revision 1.3
share/man/man8/man8.x86/boot.8: revision 1.28 (via patch)
share/man/man8/man8.x86/boot.8: revision 1.29 (via patch)
sys/arch/i386/stand/lib/exec.c: revision 1.79
sys/arch/i386/stand/efiboot/efiboot.c: revision 1.13
sys/arch/i386/stand/efiboot/bootx64/efibootx64.c: revision 1.6
sys/arch/i386/stand/efiboot/bootia32/efibootia32.c: revision 1.6
sys/arch/i386/stand/efiboot/boot.c: revision 1.22
sys/arch/amd64/amd64/locore.S: revision 1.219
sys/arch/i386/stand/efiboot/bootia32/startprog32.S: revision 1.3
sys/arch/i386/stand/efiboot/efiboot.h: revision 1.12
sys/arch/amd64/conf/files.amd64: revision 1.121
sys/arch/amd64/conf/std.amd64: revision 1.13
share/man/man8/man8.x86/pxeboot.8: revision 1.6
sys/arch/i386/stand/efiboot/bootx64/startprog64.S: revision 1.4
sys/arch/amd64/amd64/locore.S: revision 1.220
share/man/man8/man8.x86/dosboot.8: revision 1.4
share/man/man4/options.4: revision 1.524

Add reloc keyworkd to let EFI bootstrap load amd64 kernel at any address

EFI bootstrap assumes it can copy the amd64 kernel to its ELF load
address (that is KERNTEXTOFF - KERNBASE = 0x200000), but it can
clash with previous UEFI memory allocation, as described here:
http://mail-index.netbsd.org/tech-kern/2023/04/07/msg028833.html

This change adds a reloc keyword for controling where the EFI
boostrap will copy the kernel image. Possible values are:
default - the default and prior behavior, copy at 0x200000.
none - do not copy and use the kernel image where it was loaded.
address - specify an explicit address where to copy the kernel.

This comes with an amd64 kernel patch that makes it self-relocatable.
It first discover where it was loaded in memory, and if this is
different than the expected 0x200000, hhe the kernel relocates
itself and start over at the right address.

Merge x86 boot options in x86/boot(8) and add undocumented UEFI options

We were supposed to keep the option list in x86/boot(8), x86/dosoot(8)
and x86/pxeboot(8) in sync, but it did not happen, hence it may work
better with all the options in x86/boot(8). Also add the undocumented
UEFI boot options.

Add a SELFRELOC kernel option for the sake of documentation clarity.
Instead of telling that x86/boot(8) reloc command needs a kernel able
to self relocate, we can tell it needs a kernel built with the
SELFRELOC option. This keeps the reader from wondering what could
make a kernel able to self relocate.

Remove XXX todo marker left by mistake

Raise the version for new feature (here reloc command)
Suggested by Masanobu SAITOH

1.2.26.1 Sat May 13 13:26:56 UTC 2023 martin Pull up following revision(s) (requested by manu in ticket #159):

share/man/man8/man8.x86/boot.8: revision 1.27
sys/arch/i386/stand/efiboot/version: revision 1.3
share/man/man8/man8.x86/boot.8: revision 1.28
share/man/man8/man8.x86/boot.8: revision 1.29
sys/arch/i386/stand/lib/exec.c: revision 1.79
sys/arch/i386/stand/efiboot/efiboot.c: revision 1.13
sys/arch/i386/stand/efiboot/bootx64/efibootx64.c: revision 1.6
sys/arch/i386/stand/efiboot/bootia32/efibootia32.c: revision 1.6
sys/arch/i386/stand/efiboot/boot.c: revision 1.22
sys/arch/amd64/amd64/locore.S: revision 1.219
sys/arch/i386/stand/efiboot/bootia32/startprog32.S: revision 1.3
sys/arch/i386/stand/efiboot/efiboot.h: revision 1.12
sys/arch/amd64/conf/files.amd64: revision 1.121
sys/arch/amd64/conf/std.amd64: revision 1.13
share/man/man8/man8.x86/pxeboot.8: revision 1.6
sys/arch/i386/stand/efiboot/bootx64/startprog64.S: revision 1.4
sys/arch/amd64/amd64/locore.S: revision 1.220
share/man/man8/man8.x86/dosboot.8: revision 1.4
share/man/man4/options.4: revision 1.524

Add reloc keyworkd to let EFI bootstrap load amd64 kernel at any address

EFI bootstrap assumes it can copy the amd64 kernel to its ELF load
address (that is KERNTEXTOFF - KERNBASE = 0x200000), but it can
clash with previous UEFI memory allocation, as described here:
http://mail-index.netbsd.org/tech-kern/2023/04/07/msg028833.html

This change adds a reloc keyword for controling where the EFI
boostrap will copy the kernel image. Possible values are:
default - the default and prior behavior, copy at 0x200000.
none - do not copy and use the kernel image where it was loaded.
address - specify an explicit address where to copy the kernel.

This comes with an amd64 kernel patch that makes it self-relocatable.
It first discover where it was loaded in memory, and if this is
different than the expected 0x200000, hhe the kernel relocates
itself and start over at the right address.


Merge x86 boot options in x86/boot(8) and add undocumented UEFI options

We were supposed to keep the option list in x86/boot(8), x86/dosoot(8)
and x86/pxeboot(8) in sync, but it did not happen, hence it may work
better with all the options in x86/boot(8). Also add the undocumented
UEFI boot options.


Add a SELFRELOC kernel option for the sake of documentation clarity.
Instead of telling that x86/boot(8) reloc command needs a kernel able
to self relocate, we can tell it needs a kernel built with the
SELFRELOC option. This keeps the reader from wondering what could
make a kernel able to self relocate.

Remove XXX todo marker left by mistake

Raise the version for new feature (here reloc command)
Suggested by Masanobu SAITOH

  /src/usr.sbin/cpuctl/arch/
cpuctl_i386.h 1.2.28.2 Fri Dec 24 13:02:24 UTC 2021 martin Pull up the following (all via patch), requested by msaitoh in ticket #1721:

usr.sbin/cpuctl/arch/i386.c 1.118-1.119, 1.121-1.122
usr.sbin/cpuctl/arch/cpuctl_i386.h 1.6
sys/arch/x86/x86/identcpu_subr.c 1.8-1.9
sys/arch/x86/x86/identcpu.c 1.123
sys/arch/x86/include/cacheinfo.h 1.30
sys/arch/x86/include/cpu.h 1.132

- Fix a bug that some TLB related lines were not printed.
- Fix a bug that STLB is printed as DTLB.
- If a TLB is variable sized, print the max size instead of error message.
- Cosmetic changes to improve readability.

1.4.2.2 Fri Dec 24 00:58:14 UTC 2021 martin Pull up the following (all via patch), requested by msaitoh in ticket #1396:

usr.sbin/cpuctl/arch/i386.c 1.118-1.119, 1.121-1.122
usr.sbin/cpuctl/arch/cpuctl_i386.h 1.6
sys/arch/x86/x86/identcpu_subr.c 1.8-1.9
sys/arch/x86/x86/identcpu.c 1.123
sys/arch/x86/include/cacheinfo.h 1.30
sys/arch/x86/include/cpu.h 1.132

- Fix a bug that some TLB related lines were not printed.
- Fix a bug that STLB is printed as DTLB.
- If a TLB is variable sized, print the max size instead of error message.
- Cosmetic changes to improve readability.

  /src/distrib/notes/i386/
hardware 1.121 Fri Dec 14 06:32:21 UTC 2007 jnemeth branches: 1.121.2; 1.121.6; 1.121.10;
add ACPI to supported items
Fri Dec 14 06:32:21 UTC 2007 jnemeth branches: 1.121.2; 1.121.6; 1.121.10;
add ACPI to supported items
.2; 1.121.6; 1.121.10;
add ACPI to supported items
.6; 1.121.10;
add ACPI to supported items
1.120.4.1 Sat Dec 15 19:34:06 UTC 2007 bouyer branches: 1.120.4.1.2;
Pull up following revisions (requested by jnemeth in ticket #1017):
distrib/notes/common/contents patch
distrib/notes/common/list-setsizes.sh patch
distrib/notes/pmppc/hardware patch
distrib/notes/Makefile.inc 1.39, 1.40
distrib/notes/acorn32/prep.RISCOS 1.18
distrib/notes/alpha/install 1.32
distrib/notes/common/main 1.367, 1.368, 1.370 - 1.382
distrib/notes/common/netboot 1.31
distrib/notes/common/postinstall 1.64, 1.65
distrib/notes/common/sysinst 1.82, 1.83
distrib/notes/common/xfer 1.58 - 1.60
distrib/notes/evbppc/hardware 1.3
distrib/notes/ews4800mips/hardware 1.2
distrib/notes/hp300/hardware 1.19
distrib/notes/hp300/prep 1.21
distrib/notes/hp700/hardware 1.3
distrib/notes/i386/hardware 1.121
distrib/notes/i386/whatis 1.22
distrib/notes/mac68k/hardware 1.23
distrib/notes/mac68k/install 1.28
distrib/notes/macppc/hardware 1.44
distrib/notes/macppc/install 1.36
distrib/notes/macppc/prep 1.42
distrib/notes/macppc/prep.OPENFIRMWARE 1.9
distrib/notes/news68k/hardware 1.5
distrib/notes/newsmips/hardware 1.4
distrib/notes/next68k/hardware 1.8
distrib/notes/pmax/install 1.39
distrib/notes/sandpoint/hardware 1.6
distrib/notes/sparc/hardware 1.33
distrib/notes/sparc64/hardware 1.23
distrib/notes/sparc64/install 1.28
distrib/notes/vax/xfer 1.13
Sync release notes with reality
1.121.10.1 Thu Sep 18 04:41:11 UTC 2008 wrstuden Sync with wrstuden-revivesa-base-2.
1.121.6.2 Sun Oct 05 20:10:28 UTC 2008 mjf Sync with HEAD.
1.121.6.1 Sun Sep 28 11:09:18 UTC 2008 mjf Sync with HEAD.
1.121.2.2 Fri Dec 14 06:32:22 UTC 2007 jnemeth add ACPI to supported items
1.121.2.1 Fri Dec 14 06:32:21 UTC 2007 jnemeth file hardware was added on branch mjf-devfs on 2007-12-14 06:32:22 +0000
  /src/sys/arch/mac68k/conf/
files.mac68k 1.121 Wed Feb 20 21:43:34 UTC 2008 drochner branches: 1.121.6; 1.121.8; 1.121.10; 1.121.12;
Since files.wscons et al. are included by ~all ports anyway, include
them in the mi "files" file, and remove include statements from md files.
These shouldn't pull in additional kernel code when not in use, so it
shouldn't do any harm except a risk of namespace collisions which
should be easy to fix.
Wed Feb 20 21:43:34 UTC 2008 drochner branches: 1.121.6; 1.121.8; 1.121.10; 1.121.12;
Since files.wscons et al. are included by ~all ports anyway, include
them in the mi "files" file, and remove include statements from md files.
These shouldn't pull in additional kernel code when not in use, so it
shouldn't do any harm except a risk of namespace collisions which
should be easy to fix.
.6; 1.121.8; 1.121.10; 1.121.12;
Since files.wscons et al. are included by ~all ports anyway, include
them in the mi "files" file, and remove include statements from md files.
These shouldn't pull in additional kernel code when not in use, so it
shouldn't do any harm except a risk of namespace collisions which
should be easy to fix.
.8; 1.121.10; 1.121.12;
Since files.wscons et al. are included by ~all ports anyway, include
them in the mi "files" file, and remove include statements from md files.
These shouldn't pull in additional kernel code when not in use, so it
shouldn't do any harm except a risk of namespace collisions which
should be easy to fix.
.10; 1.121.12;
Since files.wscons et al. are included by ~all ports anyway, include
them in the mi "files" file, and remove include statements from md files.
These shouldn't pull in additional kernel code when not in use, so it
shouldn't do any harm except a risk of namespace collisions which
should be easy to fix.
1.121.12.1 Mon Jun 23 04:30:30 UTC 2008 wrstuden Sync w/ -current. 34 merge conflicts to follow.
1.121.10.2 Wed Aug 11 22:52:20 UTC 2010 yamt sync with head.
1.121.10.1 Mon May 04 08:11:26 UTC 2009 yamt sync with head.
1.121.8.1 Wed Jun 04 02:04:48 UTC 2008 yamt sync with head
1.121.6.1 Mon Jun 02 13:22:22 UTC 2008 mjf Sync with HEAD.

Completed in 334 milliseconds

1 2 3 4 5 6 7 8 91011>>