cinap_lenrek [Thu, 26 Oct 2017 00:42:26 +0000 (02:42 +0200)]
libc: wunlock() part 2
the initial issue was that wunlock() would wakeup readers while
holding the spinlock causing deadlock in libthread programs where
rendezvous() would do a thread switch within the same process
which then can acquire the RWLock again.
the first fix tried to prevent holding the spinlock, waking up
one reader at a time with releasing an re-acquiering the spinlock.
this violates the invariant that readers can only wakup writers
in runlock() when multiple readers where queued at the time of
wunlock(). at the first wakeup, q->head != nil so runlock() would
find a reader queued on runlock() when it expected a writer.
this (hopefully last) fix unlinks *all* the reader QLp's atomically
and in order while holding the spinlock and then traverses the
dequeued chain of QLp structures again to call rendezvous() so
the invariant described above holds.
9boot: limit read size to 4K for efi simple file system protocol
copying files from the uefi shell works, reading plan9.ini works,
loading the kernel by calling Read to read in the DATA section of
the kernel *FAILS*. my guess is that uefi filesystem driver or
nvme driver tries to allocate a temporary buffer and hasnt got
the space. limiting the read size fixes it.
upas/fs: replace fixed cache table with lru linked list
the cachetab just keeps track of recent messages that have not
been called cachefree() on. under some conditions, the fixed
table could overflow (all messages having refs > 0). with a
linked list, overflow becomes non fatal and the algorithm is
simpler to implement.
there isnt much of a point in keep maintaining separate
kernel configurations for terminal and cpu kernels as
the role can be switched with service=cpu boot parameter.
to make stuff cosistent, we will just have one "pc" kernel
and one "pc64" kernel configuration now.
cinap_lenrek [Sun, 27 Aug 2017 19:20:20 +0000 (21:20 +0200)]
sdiahci: Intel 200 Series Chipset Family PCH support (thanks aiju)
we used to tweak arround in the ICH registers for all intel controllers,
which is wrong, as the 200 series has different magic registes. see
the datasheet:
this caused the clocks to be disabled for the 6th port causing a full
machine lockup touching the 6th port registers.
the next problem was that aiju's bios disabled the unused ports somehow
but didnt clear ther PI bits, so that they would stay in Sbist status even
after a port reset. so the port would get stuck in the Dportreset state
forever. the fix for this was to use a one second timeout for the
port reset procedure.
cinap_lenrek [Thu, 10 Aug 2017 23:08:13 +0000 (01:08 +0200)]
devusb: superspeed bandwidth allocation handled by controller, skip usbload() calculation
with xhci, bandwidth allocations are handled by the controller
and there are various speed settings possible that currently
not exposed in the Udev. so just keep usbload() as it is for
usb2 and keep ep->load as zero for superspeed.
cinap_lenrek [Thu, 10 Aug 2017 23:00:09 +0000 (01:00 +0200)]
nusb/disk: add a 100ms sleep after ums reset, remove unused note handler, cleanup
my pretec usb stick sometimes hangs on the first inquiry request,
waiting for the inquiry response forever. adding a 100ms delay after
the reset command seems to fix it.
getting rid of unused "ding()" note handler and simplify umsrequest()
incomplete read handling.
cinap_lenrek [Tue, 8 Aug 2017 08:16:13 +0000 (10:16 +0200)]
sysinfo: only dump #r/nvram on amd64,386
right now, theres no kernel that stores hostowner keys
in #r/nvram, but this could change in the future. so
only dump #r/nvram on the pc where we know that its
not used to hold keys.
cinap_lenrek [Wed, 2 Aug 2017 18:25:19 +0000 (20:25 +0200)]
usbxhci: abandon multiple requests per endpoint, cleanup
more conservative approach: only one transaction in flight
per endpoint (except iso). also serialize controller commands.
no driver currently uses this and i doubt it is usefull.
create constants for common TRB flags and remove bogus 1<<16
flag on TR_NORMAL.
usbxhci: handle changing maxpkt on control endpoint by reevaluating endpoint context
while endpoints != 0 are opend after the device descriptor has been
parsed and the endpoint properties like maxpkt have been set, the
control endpoint is opend with a guessed maxpkt value. once the first
8 bytes of the descriptor have been read by usbd, maxpkt gets set and
we need to reevaluate the control endpoint 0 context to update the value.