The expression value of the assignment operation was
returned implicitely by relying on regalloc() on the
right hand side "nod" borrowing the register from nn.
But this only works if nn is a register.
In case of 6c, it can also be a ONAME from a .safe
rathole returned by regsalloc().
This change adds explicit gmove() calls to assign the
expression value. Note that gmove() checks if source
and destination are the same register so it wont emit
redundant move operations in the common case.
The same is applied also to OPREINC and OPOSTINC operations.
Mutating lists that are being iterated is needlessly error
prone, and we were removing the wrong message in some cases
if it the dummy got inserted in the right place.
Separating deletion into a redraw/relink and zap phase
simplifies the problem.
Switching window focus used to be non deterministic
as the current window in focus (Window *input) was set
concurrently while processing window messages such as
Resized and Topped.
This implements a new approach where wcurrent() and
wuncurrent() are responsible for the synchronization
and switch of the input.
It is implemented by sending a Repaint message to the
old input window first, neccesarily waiting until that
window releases the focus and then input is updated
and then a Topped or Reshaped message is send to the
new input window.
Note, that when the whole screen is resized that no
input changes need to happening anymore.
This change makes the text window be focused on startup when using
default riostart (e.g: when using the release ISO). This little change
makes you able to immediately reach the rc shell without clicking the
window, which at the very least is more convenient, and if you have
problems to use your mouse but want to install the system, you also
can (I had to stop profile from running at boot to patch it in my VPS
KVM console because the mouse wasn't working properly. Could install
and setup it to connect through drawterm).
let pci.c deal with the special cardbus controller bar0 and
expansion roms.
handle apic interrupt routing for devices behind a cardbus slot.
do not free the pcidev on card removal, as the drivers
most certanly are not prepared to handle this yet.
instead, we provide a pcidevfree() function that just unlinks
the device from pcilist and the parent bridge.
When deleting messages that came in just
the right order, we would end up stuck in
a loop deleting and reinserting a dummy
parent, rather than the messages we wanted
to remove.
p.kosyh writes:
Hello! I finally bought rpi4 4Gb specially for 9front. It seems,
that default bpp of framebuffer is 16. I changed it to 24 (via
cmdline.txt and config.txt) and found, that rendering is much faster!
(May be due removing overheads in 16->24 conversions?)
But on rpi4 r and b channels are swapped. So, i changed BGR24 to
RGB24 in bcm/screen.c and now it works fine!
Sacrifice some of the sub-millisecond timer precision in favor of less
cpu load when the timer is about to be kicked a bit early. Result is
visible *especially* when the guest idling.
Timer proc *still* has to send to the channel (in order to kick PIT
and RTC logic), which takes time, and compensates a bit for possibly
early runs.
tftpd currently unconditionally sets its namespace via /lib/namespace
(newns("none", nil)), which stymied my attempts to pxe boot the
openbsd installer without creating a real /etc dir on 9front, which
would've been gross.
I tried working around this with -h (and -r for good measure), but
again hit issues because the namespace is rebuilt from scratch -- any
binds of /386, /amd64, /cfg/pxe, etc. into the tftp-specific directory
disappeared from tftpd's namespace and rendered my *9front* boxes
unable to boot. I could maintain copies of the needed files in the
tftp-specific directory, but that'd be kind of a drag.
The following patch adds a -n flag to allow the specification of a
namespace file in place of /lib/namespace; similar to ip/ftpd.
I thought about setting up a /lib/namespace.tftp to act as a default
rather than continuing to use /lib/namespace by default (which
security-wise is about the same as allowing 9p mounts by user none,
which I also have disabled), but I had trouble coming up with a sane
default. Maybe someone more experienced would like to try that out.
- sam-d
IndexField is supposed to increment the index value when an
access is done with a bigger size than the data field.
The index value is always a byte offset.
Now that we always calculate the offset for each field unit
access for IndexField, rename the indexv to bank (the bank
value), as it is only used for that. Also, do not compare
it with nil, as it is a integer constant which can be
encoded as nil to mean zero.
For BankField, the banking field was written using store(),
which does nothing when the destination is a Field*.
Use rwfield() to fix it in the new rwfieldunit().
Resolve all the Name*'s when IndexField, BankField and
Field are created. Now, Field.reg points to eigther
Buffer object, Region or Field (data Field of an IndexField).
PS: initial bug report by Michael Forney follows below:
In /dev/kmesg on my T14, I saw a message
amlmapio: [0xffffff18-0x100000018] overlaps usable memory
amlmapio: mapping \_SB.FRTP failed
Here is the relevant snippet from my DSDT:
Scope (_SB)
{
...
OperationRegion (ECMC, SystemIO, 0x72, 0x02)
Field (ECMC, AnyAcc, NoLock, Preserve)
{
ECMI, 8,
ECMD, 8
}
IndexField (ECMI, ECMD, ByteAcc, NoLock, Preserve)
{
Offset (0x08),
FRTB, 32
}
OperationRegion (FRTP, SystemMemory, FRTB, 0x0100)
Field (FRTP, AnyAcc, NoLock, Preserve)
{
...
}
}
With some debugging output:
amlmapio(\_SB.ECMC): Io 72 - 74
rwreg(\_SB.ECMC): Io [72+0]/1 <- 8
rwreg(\_SB.ECMC): Io [72+1]/1 -> 18
amlmapio(\_SB.FRTP): Mem ffffff18 - 100000018
amlmapio: [0xffffff18-0x100000018) overlaps usable memory
amlmapio: mapping \_SB.FRTP failed
It seems that libaml does not handle IndexField correctly and just did
a single read from ECMD after setting ECMI to 8, causing the FRTP
region to be evaluated as 0xffffff18-0x100000018. Instead, it should
be reading 4 bytes [18 c0 22 cc], evaluating it as
0xcc22c018-0xcc22118:
amlmapio(\_SB.ECMC): Io 72 - 74
rwreg(\_SB.ECMC): Io [72+0]/1 <- 8
rwreg(\_SB.ECMC): Io [72+1]/1 -> 18
rwreg(\_SB.ECMC): Io [72+0]/1 <- 9
rwreg(\_SB.ECMC): Io [72+1]/1 -> c0
rwreg(\_SB.ECMC): Io [72+0]/1 <- a
rwreg(\_SB.ECMC): Io [72+1]/1 -> 22
rwreg(\_SB.ECMC): Io [72+0]/1 <- b
rwreg(\_SB.ECMC): Io [72+1]/1 -> cc
amlmapio(\_SB.FRTP): Mem cc22c018 - cc22c118
I wrote a patch (attached) to fix this, and it seems to work. Though,
it's not clear to me when things should be dereferenced. Previously,
the data field was dereferenced at evalfield, but the region and index
field were not until rwfield. After the patch, the index field is
also dereferenced in evalfield.
For BankField, the index *is* dereferenced in evalfield. I'm pretty
sure that this means that BankField does not work currently, since
store() just returns nil for 'f' objects. The bank selector will
never get set.
Anyway, I don't know if this solves any real problems; it's just
something I noticed and thought I'd try to fix.
When the save folder did not exist, and we could not create
it, we would handle up to one Biobuf worth of message, and
then fail, due to a failed tee. The sequence of events leading
up to this was:
openfolder() -> error
tee(0, fd, -1) -> wait for read
write(0, data) ->
write(fd, data) -> ok
write(-1, data) -> error, tee terminates
write(0, attachment) -> error
This change prevents us from writing to a closed fd, and
therefore from erroring out when sending.
We also warn the user.
---
To: 9front@9front.org
Date: Sun, 07 Feb 2021 14:56:39 +0100
From: kvik@a-b.xyz
Subject: Re: [9front] transient dns errors cause smtp failure
Reply-To: 9front@9front.org
I think I found a reason for DNS failing on known good domains.
/sys/src/cmd/ndb/dns.h:156,157
/* tune; was 60*1000; keep it short */
Maxreqtm= 8*1000, /* max. ms to process a request */
So, 8 seconds is how much the resolver will bother with a request it
has been handed, before dropping it on the floor with little
explanation.
It seems quite possible that this is too short a timeout on a machine
during a spam queue run, which predictably stresses the compute and
network resources.
In turn, negative response caching might explain why a particular
unlucky domain would basically stop receiveing any mail for a while.
I'm dying to know if bumping this limit would clear up the queue of
such DNS errors.
---
[narrator: it did.]
* Add the %ll length modifier,
* Convert nil to "<nil>" under %s (not in APE),
* Cast void* to uintptr under %p,
* Use "0x" hex prefix under %p,
* Fix manual page mentions of %P to %p,
* Fix empty result for fp conversions,
* Fix zero padding of left-aligned fp conversions,
* Remove deprecated #pragma ref uses.
Most of these were introduced in APE prior to 9front.
I've omitted the %z conversion specifier since Plan 9 code
rarely uses the usize type. This may need to be added later
for the benefit of native ports of alien code.
I'm not sure if this LFSR is the same one used by the hardware or is
arbitrary, but it matches the noise sequence used by all other snes
emulators I looked at.
s1 and s2 should store the last and next to last output, but were set
in the wrong order, causing them both to be the last output. This
breaks filters 2 and 3, which both utilize s2.
despite the kernel never doing any efi runtime service calls,
overriding the runtime service regions makes some machines
lock up. so consider them reserved.
the boot service regions should also, in theory, be usable
by the os, but linux says otherwise...
fseeko returns 0 on success, not the new stream position.
This allows flacenc to update the streaminfo block when it is finished
(for example to set the number of samples and checksum).
There may be two iso endpoints with the same ID if it is asynchronous
or adaptive (one for data, one for feedback), and rw iso endpoints are
unusable (error out with "iso i/o is half-duplex").
There may be two iso endpoints with the same ID if it is asynchronous
or adaptive (one for data, one for feedback), and rw iso endpoints are
unusable (error out with "iso i/o is half-duplex").
