Searched hist:0123 (Results 1 - 9 of 9) sorted by relevance

/src/etc/etc.pmax/
H A Dttys1.3 Thu Oct 30 04:18:27 GMT 1997 jonathan Changes to pmax MAKEDEV and /dev/ttys:

* Remove old MAKEDEV code for scc and dc that tried to map tty0 and
tty01 to whichever major/minor were the two comm ports.
* Use /dev/tty[abcd] for the scc driver, in linearly increasing
minor-number order. (cf. NetBSD/sparc),
* Use /dev/ttyD[0123] for the dc705 (DZ11 clone) driver, in linearly
increasing minor-number order. (cf. NetBSD/vax).
* Add the above entires to the pmax /etc/ttys.

While we're here, fix wrong major for tun, and comment out unsupported devices.
Addresses PRs pmax/4007, pmax/4330, pmax/4367.

/src/sys/dev/ic/
H A Drtwphy.c1.2 Sun Dec 12 06:37:59 GMT 2004 dyoung Miscellaneous changes. Details below. Important changes flagged
with []. Using the driver with my Linksys WPC11 ver. 4, it seems
to be receiving packets for a change. The WPC11 ver. 4 has a Maxim
RF section. My no-name rtw with Philips RF section still does not
receive any packets.

Keep access-level (analog params > config[0123] registers > none)
in sc_access. Add rtw_set_access for changing the access level.

Make rtw_continuous_tx_enable and other subroutines use rtw_set_access
instead of rtw_config0123_enable and rtw_anaparm_enable.

Factor part of the chip-reset code into rtw_chip_reset1.

Change the 'struct foo (*bar)[N]'-style arguments to
'struct foo *bar'-style arguments.

Consolidate software/hardware Tx/Rx ring setup in rtw_hwring_setup,
rtw_swring_setup.

Add a new constant, SA2400_OPMODE_DEFAULTS, for the bits that we
*always* set in the SA2400 OPMODE register.

Factor some code out into rtw_sa2400_calibrate. (Inspired by the
Linux driver.)

[] When the receiver goes into underrun/overflow state, call a new
subroutine, rtw_kick() that stops the Rx/Tx processes, resets
the chip, reinitializes the Tx/Rx rings, and restarts Rx/Tx
processes. (Inspired by the Linux driver.)

[] In rtw_intr_rx, check for too-short packets before calling
ieee80211_find_rxnode. I believe this will prevent a repeat of
the MCHK exception I saw once on macppc.

[] Use seconds-elapased as well as microseconds-elapsed to set the
next "due date" for the timeout interrupt. This keeps the driver
from programming the timeout to expire too early.

[] In rtw_intr, read RTW_ISR at most 10 times, then get out. If
the interface is not enabled (RTW_F_ENABLED), then get out.

[] In rtw_stop, get out if the interface is not enabled (RTW_F_ENABLED).
Block IPL_NET interrupts. Don't read/write any registers if
the interface is invalid (RTW_F_INVALID).

[] Call rtw_stop in rtw_detach.

H A Dsa2400reg.h1.2 Sun Dec 12 06:37:59 GMT 2004 dyoung branches: 1.2.2; 1.2.4;
Miscellaneous changes. Details below. Important changes flagged
with []. Using the driver with my Linksys WPC11 ver. 4, it seems
to be receiving packets for a change. The WPC11 ver. 4 has a Maxim
RF section. My no-name rtw with Philips RF section still does not
receive any packets.

Keep access-level (analog params > config[0123] registers > none)
in sc_access. Add rtw_set_access for changing the access level.

Make rtw_continuous_tx_enable and other subroutines use rtw_set_access
instead of rtw_config0123_enable and rtw_anaparm_enable.

Factor part of the chip-reset code into rtw_chip_reset1.

Change the 'struct foo (*bar)[N]'-style arguments to
'struct foo *bar'-style arguments.

Consolidate software/hardware Tx/Rx ring setup in rtw_hwring_setup,
rtw_swring_setup.

Add a new constant, SA2400_OPMODE_DEFAULTS, for the bits that we
*always* set in the SA2400 OPMODE register.

Factor some code out into rtw_sa2400_calibrate. (Inspired by the
Linux driver.)

[] When the receiver goes into underrun/overflow state, call a new
subroutine, rtw_kick() that stops the Rx/Tx processes, resets
the chip, reinitializes the Tx/Rx rings, and restarts Rx/Tx
processes. (Inspired by the Linux driver.)

[] In rtw_intr_rx, check for too-short packets before calling
ieee80211_find_rxnode. I believe this will prevent a repeat of
the MCHK exception I saw once on macppc.

[] Use seconds-elapased as well as microseconds-elapsed to set the
next "due date" for the timeout interrupt. This keeps the driver
from programming the timeout to expire too early.

[] In rtw_intr, read RTW_ISR at most 10 times, then get out. If
the interface is not enabled (RTW_F_ENABLED), then get out.

[] In rtw_stop, get out if the interface is not enabled (RTW_F_ENABLED).
Block IPL_NET interrupts. Don't read/write any registers if
the interface is invalid (RTW_F_INVALID).

[] Call rtw_stop in rtw_detach.

H A Drtwphyio.c1.2 Mon Dec 13 00:48:02 GMT 2004 dyoung At last, I have rtw w/ Philips RF receiving packets.

I added some sysctls to aid debugging:

* hw.rtw.debug -- enable debugging

* hw.rtw.flush_rfio -- Linux voodoo: possibly makes the MAC
"flush" bits down the serial bus to the RF

* hw.rtw.host_rfio: force the host to bang bits to the RF, instead
of the MAC banging bits

* hw.rtw.rfio_delay: after telling the MAC to bang bits to the
RF front-end, delay rfio_delay microseconds.

* hw.rtw.rfprog_fallback: there is this notion of the "RF
programming method." I believe the choice influences the
polarity/timing of the serial bus used to program the RF
front-end. I know the correct choice for Intersil/RFMD/Philips
front-ends, only. For all other front-ends, I "fallback" to
rfprog_fallback.

Make rtw_txdac_enable take an rtw_softc argument. I will probably
revert this change.

Add some Linux voodoo to rtw_continuous_tx_enable. I will probably
revert this change.

Important: add rtw_set_rfprog, which sets the correct RF programming
method. This change and the following change are probably responsible
for making the Philips RF work.

Important: RTW_CONFIG1 is an 8-bit register, treat it that way!

Important: RTW_BRSR is 16-bit, RTW_CRCOUNT, RTW_PHYDELAY, and
RTW_MSR are 8-bit: treat them that way!

Vastly simplify rtw_resume_ticks.

Note to self: set the LED state to match the power state.

Hedge against the possibility that RTW_MSR is protected as
RTW_CONFIG[0123] are, meanwhile reworking that section of rtw_init
a little.

Add sc_anaparm, which isn't used, yet....

H A Drtwvar.h1.3 Mon Dec 13 00:48:02 GMT 2004 dyoung At last, I have rtw w/ Philips RF receiving packets.

I added some sysctls to aid debugging:

* hw.rtw.debug -- enable debugging

* hw.rtw.flush_rfio -- Linux voodoo: possibly makes the MAC
"flush" bits down the serial bus to the RF

* hw.rtw.host_rfio: force the host to bang bits to the RF, instead
of the MAC banging bits

* hw.rtw.rfio_delay: after telling the MAC to bang bits to the
RF front-end, delay rfio_delay microseconds.

* hw.rtw.rfprog_fallback: there is this notion of the "RF
programming method." I believe the choice influences the
polarity/timing of the serial bus used to program the RF
front-end. I know the correct choice for Intersil/RFMD/Philips
front-ends, only. For all other front-ends, I "fallback" to
rfprog_fallback.

Make rtw_txdac_enable take an rtw_softc argument. I will probably
revert this change.

Add some Linux voodoo to rtw_continuous_tx_enable. I will probably
revert this change.

Important: add rtw_set_rfprog, which sets the correct RF programming
method. This change and the following change are probably responsible
for making the Philips RF work.

Important: RTW_CONFIG1 is an 8-bit register, treat it that way!

Important: RTW_BRSR is 16-bit, RTW_CRCOUNT, RTW_PHYDELAY, and
RTW_MSR are 8-bit: treat them that way!

Vastly simplify rtw_resume_ticks.

Note to self: set the LED state to match the power state.

Hedge against the possibility that RTW_MSR is protected as
RTW_CONFIG[0123] are, meanwhile reworking that section of rtw_init
a little.

Add sc_anaparm, which isn't used, yet....

1.2 Sun Dec 12 06:37:59 GMT 2004 dyoung Miscellaneous changes. Details below. Important changes flagged
with []. Using the driver with my Linksys WPC11 ver. 4, it seems
to be receiving packets for a change. The WPC11 ver. 4 has a Maxim
RF section. My no-name rtw with Philips RF section still does not
receive any packets.

Keep access-level (analog params > config[0123] registers > none)
in sc_access. Add rtw_set_access for changing the access level.

Make rtw_continuous_tx_enable and other subroutines use rtw_set_access
instead of rtw_config0123_enable and rtw_anaparm_enable.

Factor part of the chip-reset code into rtw_chip_reset1.

Change the 'struct foo (*bar)[N]'-style arguments to
'struct foo *bar'-style arguments.

Consolidate software/hardware Tx/Rx ring setup in rtw_hwring_setup,
rtw_swring_setup.

Add a new constant, SA2400_OPMODE_DEFAULTS, for the bits that we
*always* set in the SA2400 OPMODE register.

Factor some code out into rtw_sa2400_calibrate. (Inspired by the
Linux driver.)

[] When the receiver goes into underrun/overflow state, call a new
subroutine, rtw_kick() that stops the Rx/Tx processes, resets
the chip, reinitializes the Tx/Rx rings, and restarts Rx/Tx
processes. (Inspired by the Linux driver.)

[] In rtw_intr_rx, check for too-short packets before calling
ieee80211_find_rxnode. I believe this will prevent a repeat of
the MCHK exception I saw once on macppc.

[] Use seconds-elapased as well as microseconds-elapsed to set the
next "due date" for the timeout interrupt. This keeps the driver
from programming the timeout to expire too early.

[] In rtw_intr, read RTW_ISR at most 10 times, then get out. If
the interface is not enabled (RTW_F_ENABLED), then get out.

[] In rtw_stop, get out if the interface is not enabled (RTW_F_ENABLED).
Block IPL_NET interrupts. Don't read/write any registers if
the interface is invalid (RTW_F_INVALID).

[] Call rtw_stop in rtw_detach.

H A Drtw.c1.4 Mon Dec 13 00:48:02 GMT 2004 dyoung At last, I have rtw w/ Philips RF receiving packets.

I added some sysctls to aid debugging:

* hw.rtw.debug -- enable debugging

* hw.rtw.flush_rfio -- Linux voodoo: possibly makes the MAC
"flush" bits down the serial bus to the RF

* hw.rtw.host_rfio: force the host to bang bits to the RF, instead
of the MAC banging bits

* hw.rtw.rfio_delay: after telling the MAC to bang bits to the
RF front-end, delay rfio_delay microseconds.

* hw.rtw.rfprog_fallback: there is this notion of the "RF
programming method." I believe the choice influences the
polarity/timing of the serial bus used to program the RF
front-end. I know the correct choice for Intersil/RFMD/Philips
front-ends, only. For all other front-ends, I "fallback" to
rfprog_fallback.

Make rtw_txdac_enable take an rtw_softc argument. I will probably
revert this change.

Add some Linux voodoo to rtw_continuous_tx_enable. I will probably
revert this change.

Important: add rtw_set_rfprog, which sets the correct RF programming
method. This change and the following change are probably responsible
for making the Philips RF work.

Important: RTW_CONFIG1 is an 8-bit register, treat it that way!

Important: RTW_BRSR is 16-bit, RTW_CRCOUNT, RTW_PHYDELAY, and
RTW_MSR are 8-bit: treat them that way!

Vastly simplify rtw_resume_ticks.

Note to self: set the LED state to match the power state.

Hedge against the possibility that RTW_MSR is protected as
RTW_CONFIG[0123] are, meanwhile reworking that section of rtw_init
a little.

Add sc_anaparm, which isn't used, yet....
1.3 Sun Dec 12 06:37:59 GMT 2004 dyoung Miscellaneous changes. Details below. Important changes flagged
with []. Using the driver with my Linksys WPC11 ver. 4, it seems
to be receiving packets for a change. The WPC11 ver. 4 has a Maxim
RF section. My no-name rtw with Philips RF section still does not
receive any packets.

Keep access-level (analog params > config[0123] registers > none)
in sc_access. Add rtw_set_access for changing the access level.

Make rtw_continuous_tx_enable and other subroutines use rtw_set_access
instead of rtw_config0123_enable and rtw_anaparm_enable.

Factor part of the chip-reset code into rtw_chip_reset1.

Change the 'struct foo (*bar)[N]'-style arguments to
'struct foo *bar'-style arguments.

Consolidate software/hardware Tx/Rx ring setup in rtw_hwring_setup,
rtw_swring_setup.

Add a new constant, SA2400_OPMODE_DEFAULTS, for the bits that we
*always* set in the SA2400 OPMODE register.

Factor some code out into rtw_sa2400_calibrate. (Inspired by the
Linux driver.)

[] When the receiver goes into underrun/overflow state, call a new
subroutine, rtw_kick() that stops the Rx/Tx processes, resets
the chip, reinitializes the Tx/Rx rings, and restarts Rx/Tx
processes. (Inspired by the Linux driver.)

[] In rtw_intr_rx, check for too-short packets before calling
ieee80211_find_rxnode. I believe this will prevent a repeat of
the MCHK exception I saw once on macppc.

[] Use seconds-elapased as well as microseconds-elapsed to set the
next "due date" for the timeout interrupt. This keeps the driver
from programming the timeout to expire too early.

[] In rtw_intr, read RTW_ISR at most 10 times, then get out. If
the interface is not enabled (RTW_F_ENABLED), then get out.

[] In rtw_stop, get out if the interface is not enabled (RTW_F_ENABLED).
Block IPL_NET interrupts. Don't read/write any registers if
the interface is invalid (RTW_F_INVALID).

[] Call rtw_stop in rtw_detach.
/src/etc/etc.hp300/
H A DMAKEDEV.conf1.6 Sat Nov 22 17:20:08 GMT 2003 tsutsui Update MD entries for DCA, DCM and APCI serial ports to migrate MI com(4):
- use ttyC[0123] for DCA and APCI with MI com(4)
- use ttyM[0-f] for DCM instead of tty0[0-f] to avoid confusion with MI com(4)
- create the foloowing symlnks to compatibility:
tty0 -> ttyC0 (for DCA)
ttya0 -> ttyC1 (for APCI)
ttya1 -> ttyC2 (for APCI)
ttya2 -> ttyC3 (for APCI)
tty0? -> ttyM? (for DCM)
- note the above symlinks should be removed after the next release

As per discussion on recent port-hp300 (ok'ed by thorpej).

/src/sys/arch/i386/stand/boot/
H A Dboot2.c1.48 Mon Feb 08 21:25:32 GMT 2010 hubertf branches: 1.48.2;
When a password is set for the bootloader ("installboot -o password=..."),
it currently complains about an unknown command and prints a usage if the
password is entered wrong:

...
Choose an option; RETURN for default; SPACE to stop countdown.
Option 1 will be chosen in 0 seconds.
Password: *
Password: *
Password: *
unknown command
commands are:
boot [xdNx:][filename] [-12acdqsvxz]
(ex. "hd0a:netbsd.old -s"
ls [path]
dev xd[N[x]]:
consdev {pc|com[0123]|com[0123]kbd|auto}
modules {enabled|disabled}
load {path_to_module}
multiboot [xdNx:][filename] [<args>]
help|?
quit

Choose an option; RETURN for default; SPACE to stop countdown.
Option 1 will be chosen in 0 seconds.
...

This is confusing, plus someone may use it to determine bits of
information about the system. What should happen instead is that the user
is informed that the password is wrong:

...
Choose an option; RETURN for default; SPACE to stop countdown.
Option 1 will be chosen in 0 seconds.
Password: ****
Password: ****
Password: ****
Wrong password.

Choose an option; RETURN for default; SPACE to stop countdown.
...

Implement the latter behaviour.
1.48 Mon Feb 08 21:25:32 GMT 2010 hubertf branches: 1.48.2;
When a password is set for the bootloader ("installboot -o password=..."),
it currently complains about an unknown command and prints a usage if the
password is entered wrong:

...
Choose an option; RETURN for default; SPACE to stop countdown.
Option 1 will be chosen in 0 seconds.
Password: *
Password: *
Password: *
unknown command
commands are:
boot [xdNx:][filename] [-12acdqsvxz]
(ex. "hd0a:netbsd.old -s"
ls [path]
dev xd[N[x]]:
consdev {pc|com[0123]|com[0123]kbd|auto}
modules {enabled|disabled}
load {path_to_module}
multiboot [xdNx:][filename] [<args>]
help|?
quit

Choose an option; RETURN for default; SPACE to stop countdown.
Option 1 will be chosen in 0 seconds.
...

This is confusing, plus someone may use it to determine bits of
information about the system. What should happen instead is that the user
is informed that the password is wrong:

...
Choose an option; RETURN for default; SPACE to stop countdown.
Option 1 will be chosen in 0 seconds.
Password: ****
Password: ****
Password: ****
Wrong password.

Choose an option; RETURN for default; SPACE to stop countdown.
...

Implement the latter behaviour.
/src/
H A Dbuild.sh1.396 Tue May 13 01:09:55 GMT 2025 riastradh build.sh: Clarify revisionid a little bit.

1. Put the CVS tag back -- this was lost in 1.393, and I suspect it
was unintentional (martin: feel free to correct me if my suspicion
is wrong and you really meant to nix the CVS tag).

2. Identify the revision control system in the commit id so you don't
have to wonder if you are just missing this changeset id or you're
mixing up git and hg.

3. Separate with spaces rather than hyphens so there is a chance to
parse this later -- tags/branches tend to allow hyphens but not
spaces. (If there's a reason not to use spaces, it's not clear to
me.)

Evenutally I would like to change this to an even more semantically
meaningful identifier, something like

hg identify -T '{latesttag}-{changessincelatesttag}{ifeq(phase,"public","","!{phase")}-hg-{id}{dirty}'

so it would come out as something like:

netbsd-11.99.3-121-hg-0123abcd4567ef

if this is a public commit on trunk with a clean working tree, or

netbsd-11.99.3-123!draft-hg-89ab01cd23ef45+

if this is a draft commit on trunk with a dirty working tree. But
for this to be useful we have to have the tags assigned, which is not
currently done in the ongoing conversion -- to be fixed in the final
migration.
1.396 Tue May 13 01:09:55 GMT 2025 riastradh build.sh: Clarify revisionid a little bit.

1. Put the CVS tag back -- this was lost in 1.393, and I suspect it
was unintentional (martin: feel free to correct me if my suspicion
is wrong and you really meant to nix the CVS tag).

2. Identify the revision control system in the commit id so you don't
have to wonder if you are just missing this changeset id or you're
mixing up git and hg.

3. Separate with spaces rather than hyphens so there is a chance to
parse this later -- tags/branches tend to allow hyphens but not
spaces. (If there's a reason not to use spaces, it's not clear to
me.)

Evenutally I would like to change this to an even more semantically
meaningful identifier, something like

hg identify -T '{latesttag}-{changessincelatesttag}{ifeq(phase,"public","","!{phase")}-hg-{id}{dirty}'

so it would come out as something like:

netbsd-11.99.3-121-hg-0123abcd4567ef

if this is a public commit on trunk with a clean working tree, or

netbsd-11.99.3-123!draft-hg-89ab01cd23ef45+

if this is a draft commit on trunk with a dirty working tree. But
for this to be useful we have to have the tags assigned, which is not
currently done in the ongoing conversion -- to be fixed in the final
migration.

Completed in 140 milliseconds