| Age | Commit message (Collapse) | Author |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
Access to the global constty variable is coordinated as follows:
1. Setting constty to nonnull, with atomic_store_release, is allowed
only under the new adaptive constty_lock in thread context. This
serializes TIOCCONS operations and ensures unlocked readers can
safely use a constty pointer read with atomic_load_consume.
2. Changing constty from nonnull to null, with atomic_cas_ptr, is
allowed in any context -- printf(9) uses this to disable a broken
constty.
3. Reading constty under constty_lock is allowed with
atomic_load_relaxed, because while constty_lock is held, it can
only be made null by some other thread/CPU, never made nonnull.
4. Reading constty outside constty_lock is allowed with
atomic_load_consume in a pserialize read section -- constty is
only ever made nonnull with atomic_store_release, in (1).
ttyclose will wait for all these pserialize read sections to
complete before flushing the tty.
5. To continue to use a struct tty pointer in (4) after the
pserialize read section has completed, caller must use tty_acquire
during the pserialize read section and then tty_release when done.
ttyclose will wait for all these references to drain before
returning.
These access rules allow us to serialize TIOCCONS, and safely destroy
ttys, without putting any locks on the access paths like printf(9)
that use constty. Once we set D_MPSAFE, operations on /dev/console
will contend only with other users of the same tty as constty, which
will be an improvement over contending with all other kernel lock
users in the system.
Changes second time around:
- Fix initialization of ok in cons.c cn_redirect.
- Fix reversed sense of conditional in subr_prf.c putone.
Changes third time around:
- Initialize ttyref_cv so we don't panic when trying to use it,
leading to infinite loop when panic tries to take tty_lock to print
the panic message while we already hold tty_lock.
|
|
|
|
It was introduced in 2007 for some Xbox thing which was removed in
2011. The API and the threads it spawned have been sitting around
idly for over a decade serving no purpose -- sometimes causing kernel
lock spinouts in the event of panic.
Add ic_tag_private to obviate need for future ABI changes. Not
currently used, but we can privately allocate memory in iic_tag_init
for the purpose later if need be without changing ABI.
XXX kernel revbump -- changes struct i2c_controller
|
|
Lock is relevant only if we're doing something _else_ under the lock
that must be serialized with the callout's own action.
|
|
This should really be an unconditional cv_wait loop, but for now
let's just give fair warning when the driver is about to puke its
guts out in case the I/O paths I haven't audited yet are buggy.
|
|
Otherwise we may deadlock waiting for them to give up while they're
waiting for I/O, not knowing they need to give up.
|
|
Otherwise the error branch is based on garbage.
|
|
|
|
It is true that aq_stop must be sleepable, and that aq_stop_locked
may sleep, but aq_stop_locked will release sc->sc_mutex when it
sleeps, which ASSERT_SLEEPABLE doesn't know about. Since that is a
spin lock, ASSERT_SLEEPABLE trips over it and crashes.
This is not quite right: aq_stop should really only take the lock
over specific things that need the lock to synchronize with other
threads, like mii_down; aq_init and aq_stop are already serialized by
IFNET_LOCK. sc->sc_mutex is used for too much and should have its
scope narrowed like I did recently in usbnet(9). But this small
change will at least remove a source of crashes for now.
|
|
|
|
"no-map" property.
Required for qemu/riscv
|
|
PR kern/57063
|
|
PR kern/57063
|
|
|
|
|
|
No functional change intended.
|
|
Fixes panic with callout still running on detach after we destroy the
lock, reported by andvar@:
fatal page fault in supervisor mode
trap type 6 code 0 rip 0xffffffff80dfafec cs 0x8 rflags 0x10286 cr2 0xfffffffffffffff0 ilevel 0x2 rsp 0xffffcd085b291ee0
Skipping crash dump on recursive panic
panic: trap
cpu0: Begin traceback...
vpanic() at netbsd:vpanic+0x183
panic() at netbsd:panic+0x3c
trap() at netbsd:trap+0xb27
--- trap (number 6) ---
mutex_oncpu() at netbsd:mutex_oncpu+0x1e
mutex_vector_enter() at netbsd:mutex_vector_enter+0xb7
aq_tick() at netbsd:aq_tick+0x23
callout_softclock() at netbsd:callout_softclock+0xbd
softint_dispatch() at netbsd:softint_dispatch+0xf9
DDB lost frame for netbsd:Xsoftintr+0x4c, trying 0xffffcd085b2920f0
Xsoftintr() at netbsd:Xsoftintr+0x4c
--- interrupt ---
fa0b2181724b21c1:
cpu0: End traceback...
|
|
|
|
implement support for:
- pcie_capability_read_dword()
- pcie_capability_read_word()
- pcie_capability_write_dword()
- pcie_capability_write_word()
- pcie_get_readrq()
- pcie_set_readrq()
implement the "struct pci_dev" bus->self member by creating a minimal fake
"struct pci_dev" for the pci bus itself. this is kind of gross. it checks
that the current device's parent is a netbsd "pci" device, and that it has
a (grand) parent "ppb" device, and then fills in the fake device based upon
the pci and ppb devices.
add some PCIE_LCSR2_TGT_LSPEED encodings, and map them to linux names.
map several other PCIE_LCSR and PCIE_LCAP names.
uncomment several pcie code segments in radeon and amdgpu. (not sure that
we can test the amdgpu_si.c change, as we use the radeon version and the
amdgpu version hangs on the one machine i have.)
tested on amdgpu (RX550) and radeon (7750 & 3650).
ok @riastradh
|
|
|
|
|
|
Prune dead error branches.
|
|
Reduces need for cast.
|
|
howmany will divide by VIRTIO_PAGE_SIZE instead of doing &
~(VIRTIO_PAGE_SIZE - 1), but it's a constant 4096 so this should make
no difference in the compiled output except possibly at -O0.
No functional change intended.
|
|
No functional change intended.
|
|
Oracle cloud BlockVolumes do not appear to support SCSI READ6 or WRITE6
commands, so set PQUIRK_ONLYBIG to avoid it here.
|
|
|
|
The Arm ACPI code relied on PCI_NETBSD_CONFIGURE to configure devices that
were not enabled by system firmware. This is not safe to do unless the
firmware explicitly permits it using a device specific method defined in
the PCI firmware spec.
Introduce a new PCI resource manager that discovers what has already been
configured by firmware and allocates from the remaining space. This will
ensure that devices setup by firmware are untouched and only will program
BARs of devices that are not enabled at boot time.
The current implementation assumes that the parent PCI-PCI bridge's
are already configured. A worthwhile improvement in the future would be
to support programming windows for bridges that are not fully configured.
|
|
PR# 57015
|
|
|
|
|
|
1.5GBit/s only disks
|
|
s/bus_dmamem_load/bus_dmamap_load/.
Inspired by recent similar fixes in OpenBSD.
|
|
|
|
|
|
- Example:
xhci4 at pci17 dev 0 function 0: AMD product 15b8 (rev. 0x00)
xhci4: 64-bit DMA
allocated pic msix10 type edge pin 0 level 6 to cpu0 slot 32 idt entry 107
xhci4: interrupting at msix10 vec 0
xhci4: xHCI version 1.20
xhci4: hcs1=1000840 hcs2=140000f1 hcs3=7000a
xhci4: hcc=0x110ffc5<XECP=0x110,MAXPSA=0xf,CFC,SEC,SPC,PAE,NSS,LTC,CSZ,AC64>
xhci4: xECP 440
xhci4: hcc2=0x3f<CIC,LEC,CTC,FSC,CMC,U3C>
xhci4: ECR: 0x00000401
xhci4: ECR: 0x02000402
xhci4: SP: 0x02000402 0x20425355 0x00180101 0x00000000
xhci4: hs ports 1 - 1
xhci4: ECR: 0x000f000a
xhci4: PAGESIZE 0x00000001
xhci4: sc_pgsz 0x00001000
xhci4: sc_maxslots 0x00000040
xhci4: sc_maxports 1
xhci4: sc_maxspbuf 2
xhci4: eventst: 0x000000013ee60fc0 0xffffb08826f5afc0 1000
xhci4: dcbaa: 0x000000013ee63000 0xffffb08826f5b000 1000
xhci4: current IMOD 0
(snip)
usb8 at xhci4: USB revision 3.1
usb9 at xhci4: USB revision 2.0
uhub8 at usb8: NetBSD (0x0000) xHCI root hub (0x0000), class 9/0, rev 3.00/1.00, addr 0
uhub8: 0 ports with 0 removable, self powered
uhub8: no ports, hub ignored
uhub8: WARNING: power management not supported
autoconfiguration error: usb8: root device is not a hub
usb8: WARNING: power management not supported
uhub9 at usb9: NetBSD (0x0000) xHCI root hub (0x0000), class 9/0, rev 2.00/1.00, addr 0
uhub9: 1 port with 1 removable, self powered
- To resolve this problem, keep number of ports of SS and HS and use
it to attach child device(s).
- Tested on ASUS TUF GAMING X670E-PLUS.
- OK'd by skrll@.
|
|
ec_capabilities instead.
|
|
|
|
Something is still busted and this is interfering with the releng
amd64 testbed.
|