Am 13.08.23 um 17:38 schrieb Tobias Heider:
On Sun, Aug 13, 2023 at 08:33:54AM -0400, Andrew Cagney wrote:
Hi Andrew,
can you share the qemu cmd you are using in your tests?
I'd like to see if I can reproduce this.
Here's pretty much everything. Thanks for looking at it.
Thank you, I manag
Fix handling of feature bits >= 32. This does not yet affect any driver
as no high feature bit besides VERSION_1 is used, and that one has special
handling.
Also, with VIRTIO_DEBUG, simply walk through all transport and device
feature names, so that we don't need to adjust the if clause whenev
>From FreeBSD commits
commit c0db7289c3de290d821311942d5533f2284af77f
Author: pfg
Date: Wed Aug 8 15:08:22 2018 +
msdosfs: fixes for Undefined Behavior.
and
commit 852150953b828e4e8c32789637061001158a8cf4
Author: kib
Date: Fri
I forgot to mention that no stress test is necessary. If it boots and
the virtio devices work at all, that should be enough.
Cheers,
Stefan
Am 20.05.23 um 15:00 schrieb Stefan Fritsch:
Hi,
with help from Aaron Mason, I have found the problem responsible for the
vioscsi panic on oracle cloud
on amd64 / qemu. I would be interested in test
results on other systems, especially on top of vmd and on arm64 with
viogpu.
Aaron, can you please also test with the updated diff?
Thanks in advance.
Cheers,
Stefan
commit d3209e34d77ab7353973efb2a57303f636fff4f4
Author: Stefan Fritsch
Date
On Thu, 4 May 2023, Aaron Mason wrote:
> On Mon, May 1, 2023 at 4:56 AM Stefan Fritsch wrote:
> >
> > Hi,
> >
> > what qemu version are you using? I cannot reproduce this with qemu 7.2.
> > Can you try with a newer qemu?
> >
> > Cheers,
> &g
Dropping misc@ from cc
Am 01.05.23 um 02:08 schrieb Aaron Mason:
I can reproduce it with this in QEMU 8.0 in Winders (thanks Antun who
sent something like this to the bugs@ list):
qemu-system-x86_64 -accel whpx,kernel-irqchip=off -machine q35 \
-cpu EPYC-Rome,-monitor -m 8g -smp 6,sockets=1
Hi,
what qemu version are you using? I cannot reproduce this with qemu 7.2.
Can you try with a newer qemu?
Cheers,
Stefan
Am 25.04.23 um 14:53 schrieb Aaron Mason:
Yeah I'm getting the same thing. Trying a build in QEMU and
transferring in to see if that helps. Will report back.
Ok, good
Hi,
sometimes I see writing to msdosfs fail with EINVAL. This seems to occur
when writing a file reaches the end of the partition. But it only happens
if all bits in the pm_inusemap array are actually used, i.e. if
pm_maxcluster % 32 == 31 . This means that for the number N of data
clusters i
FWIW, you absolutely need iommu suport in order to make thunderbolt even
somewhat secure. So polishing and enabling iommu support for amd64 would
have to come first.
Am 20.11.20 um 19:01 schrieb Joseph Mayer:
Kind bump on this thread.
As for me I'd like to attach nvme(4) and maybe ethernet an
If the NIC is in some error state during device attach (seen on a i219LM
when em_read_phy_reg_ex() returns at "MDI Error"), it can happen that we
loop endlessly because the loop variable is modified again down in the
call stack:
em_match_gig_phy() -> em_read_phy_reg() -> em_access_phy_reg_hv()
Tested with a BCM57412
OK?
diff --git a/sys/dev/pci/if_bnxt.c b/sys/dev/pci/if_bnxt.c
--- a/sys/dev/pci/if_bnxt.c
+++ b/sys/dev/pci/if_bnxt.c
@@ -102,6 +102,7 @@
#define BNXT_FLAG_NPAR 0x0002
#define BNXT_FLAG_WOL_CAP 0x0004
#define BNXT_FLAG_SHORT_CMD 0x0008
+#define BNXT_F
On Fri, May 31, 2019 at 07:35:41AM +1000, Jonathan Matthew wrote:
> I had wondered about the MAU32 define when I was looking at MSI-X
> suspend/resume.
I have also taken a try at MSI-X suspend/resume in the last few weeks.
The diff below is what I have come up with. It worked with nvme on a
laptop
virtio 1.0 supports an arbitrary number of feature bits. However, so far
no more than 64 are used (compared to 32 in virtio 0.9). Adjust data
types to support 64 feature bits.
Later, we may want to use bitmaps and setbit(), ... to support even more
feature bits.
---
sys/dev/fdt/virtio_mmio.c | 8
Add a sc_driver_features field that is automatically used by
virtio_negotiate_features() and during reinit.
Make virtio_negotiate_features() return an error code. Virtio 1.0 has a
special status bit for feature negotiation that means that negotiation
can fail. Make virtio_negotiate_features() ret
virtio 1.0 for virtio_mmio it not yet implemented, but 0.9 devices
continue to work.
---
share/man/man4/virtio.4 | 11 +-
sys/dev/pci/virtio_pci.c| 518 +++-
sys/dev/pci/virtio_pcireg.h | 57
sys/dev/pv/if_vio.c | 9 +-
sys/dev/pv/virtiovar.
In virtio_pci 1.0, different parts of the register set may be located in
different BARs. Use subregions to make the access independent of the
virtio version.
---
sys/dev/pci/virtio_pci.c | 114 +++
1 file changed, 80 insertions(+), 34 deletions(-)
diff --git a/
---
sys/dev/pci/virtio_pci.c | 38 --
1 file changed, 24 insertions(+), 14 deletions(-)
diff --git a/sys/dev/pci/virtio_pci.c b/sys/dev/pci/virtio_pci.c
index d69db1968d0..7be93684a68 100644
--- a/sys/dev/pci/virtio_pci.c
+++ b/sys/dev/pci/virtio_pci.c
@@ -69,6
Make it take an address instead of a PFN.
Pass the virtqueue pointer. In virtio 1.0, more information has to be
configured in the device. Also call virtio_setup_queue() after the
information has been filled in.
---
sys/dev/fdt/virtio_mmio.c | 11 +++
sys/dev/pci/virtio_pci.c | 11 ++--
Hi,
here comes the split up diff for virtio 1.0 support. Compared to the previous
diff, I have omitted some changes in how the feature bits and negotiation
works. This also means that the feature bit defines in the headers stay the
same and vmd is not affected. I have tested that virtio_mmio on a
---
sys/dev/pv/if_vio.c| 84 +++---
sys/dev/pv/vioblk.c| 3 ++
sys/dev/pv/vioblkreg.h | 21 ++-
sys/dev/pv/virtio.c| 1 +
4 files changed, 62 insertions(+), 47 deletions(-)
diff --git a/sys/dev/pv/if_vio.c b/sys/dev/pv/if_vio.c
index a4cd8
On Saturday, 12 January 2019 01:49:09 CET Jonathan Gray wrote:
> On Fri, Jan 11, 2019 at 03:21:11PM -0800, William Ahern wrote:
> > On Fri, Jan 11, 2019 at 10:43:25AM +0100, Stefan Fritsch wrote:
> >
> >
> > > /* only used for sizeof, not actually al
On Fri, 11 Jan 2019, Ted Unangst wrote:
> Stefan Fritsch wrote:
> > +#define CREAD(sc, memb)
> > \
> > + ({
> > \
> > +
Hi Carlos,
>
> I'm getting ramped back up from being AWOL for several months, so
> apologies in advance for the delay of going through your diff (and the
> virtio header re-order one that you fixed). It'll be over the weekend
> at the earliest before I can review/test it out.
There is no hurry,
On Fri, 11 Jan 2019, Jonathan Gray wrote:
> Assuming a qcow2 image created by something along the lines of
> 'qemu-img create -f qcow2 root.qcow2 2g' miniroot64.fs from an arm64
> snapshot and u-boot for qemu_arm64 from the u-boot-aarch64 package:
>
> doas sh -c "qemu-system-aarch64 -runas $USER \
On Thu, 10 Jan 2019, Theo de Raadt wrote:
> arm64 also uses this subsystem, and as a result this diff breaks
> all those kernels.
The diff also breaks vmd. Even if it compiles it will still be broken. As
I wrote, it's not ready for commit yet.
>
> You ask how to run arm64 Uhm, you didn't e
Hi,
the diff below implements the virtio 1.0 standard in the kernel (0.9 keeps
working, of course). It's not ready for commit, yet, but I would like some
input.
For the most part, the changes from 0.9 to 1.0 are not that big, but there
are some notable differences. Since some headers are also
Everything above 0x1040 is 1.x only.
Also tweak descriptoin of memory balloon device. There will be a memory,
too.
OK?
diff --git a/sys/dev/pci/pcidevs b/sys/dev/pci/pcidevs
index 14943bb1350..72f95a29b00 100644
--- a/sys/dev/pci/pcidevs
+++ b/sys/dev/pci/pcidevs
@@ -6692,12 +6692,17 @@ pro
are/man/man4/fwcfg.4
@@ -0,0 +1,44 @@
+.\"$OpenBSD: $
+.\"
+.\" Copyright (c) 2018 Stefan Fritsch
+.\"
+.\" Permission to use, copy, modify, and distribute this software for any
+.\" purpose with or without fee is hereby granted, provided that the above
+.\" copyright
On Monday, 2 April 2018 11:52:08 CEST Stefan Fritsch wrote:
> It would be nice if people could give it a try on various em(4) hardware
> to check if there are any regressions.
Somewhat belatedly, this is now committed. Thanks to all the people who tested
it.
Cheers,
Stefan
On Tue, 10 Apr 2018, Jonathan Gray wrote:
> On Sat, Apr 07, 2018 at 01:35:31PM +0200, Stefan Fritsch wrote:
> > On Fri, 6 Apr 2018, Jonathan Gray wrote:
> >
> > > On Thu, Apr 05, 2018 at 09:57:23PM +0200, Stefan Fritsch wrote:
> > > > Add another magic 1m
Sorry for the late response.
On Tue, 10 Apr 2018, Jonathan Gray wrote:
> On Thu, Apr 05, 2018 at 09:57:20PM +0200, Stefan Fritsch wrote:
> > Some em chips have a semaphore ("software flag") to synchronize access
> > to certain registers between OS and firmware (ME/AMT)
On Fri, 6 Apr 2018, Jonathan Gray wrote:
> On Thu, Apr 05, 2018 at 09:57:17PM +0200, Stefan Fritsch wrote:
> > Print the error code if hardware initialization failed.
> >
> > If EM_DEBUG is defined, print the phy/mac type during attach.
>
> ok jsg@
>
> Tho
On Fri, 6 Apr 2018, Jonathan Gray wrote:
> On Thu, Apr 05, 2018 at 09:57:23PM +0200, Stefan Fritsch wrote:
> > Add another magic 1ms delay that seems to help with some remaining
> > issues on an HP elitebook 820 G3 with i219LM. A printf() at the same
> > place helps, too.
&
Print the error code if hardware initialization failed.
If EM_DEBUG is defined, print the phy/mac type during attach.
---
sys/dev/pci/if_em.c | 7 +--
1 file changed, 5 insertions(+), 2 deletions(-)
diff --git sys/dev/pci/if_em.c sys/dev/pci/if_em.c
index ec8e35245ef..30df846117c 100644
---
https://www.intel.com/content/dam/www/public/us/en/documents/specification-updates/i218-i219-ethernet-connection-spec-update.pdf?asset=9561
---
sys/dev/pci/if_em.c| 4 +++-
sys/dev/pci/if_em_hw.h | 1 +
2 files changed, 4 insertions(+), 1 deletion(-)
diff --git sys/dev/pci/if_em.c sys/dev/pci
Port the logic from freebsd to em_check_phy_reset_block(). A single
read does not seem to be reliable.
---
sys/dev/pci/if_em_hw.c | 15 ---
1 file changed, 12 insertions(+), 3 deletions(-)
diff --git sys/dev/pci/if_em_hw.c sys/dev/pci/if_em_hw.c
index 52d3ee95d15..e5084252c29 100644
-
Some em chips have a semaphore ("software flag") to synchronize access
to certain registers between OS and firmware (ME/AMT).
Make the logic to get the flag match the logic in freebsd. This includes
higher timeouts and waiting for a previous unlock to complete before
trying a lock again.
---
sys/
Add another magic 1ms delay that seems to help with some remaining
issues on an HP elitebook 820 G3 with i219LM. A printf() at the same
place helps, too.
---
sys/dev/pci/if_em_hw.c | 2 ++
1 file changed, 2 insertions(+)
diff --git sys/dev/pci/if_em_hw.c sys/dev/pci/if_em_hw.c
index 7709a4c5805..
The em driver calls em_get_software_flag() recursively, which causes the
semaphore to be unlocked too early. Make em_get_software_flag and
em_release_software_flag handle this correctly. Freebsd does not do
this, but they have a mutex that probably allows them to detect
recursive calls to e1000_ac
This is the value in freebsd for ich8lan.
---
sys/dev/pci/if_em_hw.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git sys/dev/pci/if_em_hw.c sys/dev/pci/if_em_hw.c
index df0fa571736..52d3ee95d15 100644
--- sys/dev/pci/if_em_hw.c
+++ sys/dev/pci/if_em_hw.c
@@ -945,7 +945,7 @@ em_re
On Thu, 5 Apr 2018, Mark Kettenis wrote:
> > Date: Thu, 5 Apr 2018 02:02:20 +1000
> > From: Jonathan Gray
> >
> > On Mon, Apr 02, 2018 at 11:52:08AM +0200, Stefan Fritsch wrote:
> > > Hi,
> > >
> > > We have seen problems
Hi,
We have seen problems with em on i219V and i219LM. For example, "Hardware
Initialization Failed" if no cable is plugged in during boot, or watchdog
timeouts / hangs until next boot if the cable is removed while data is
transmitted.
This patch adds a bunch of quirks and fixes from freebsd.
Hi,
here are some comments / man page updates for things I have learned in my
adventures through msdosfs and vfs_bio.c. I have also added the
bread_cluster function to buffercache(9). It would be nice if someone who
knows the buffer/disk stuff could review this.
Hint for the paragraph on block
On Tue, 15 Aug 2017, Mike Larkin wrote:
> On Tue, Aug 15, 2017 at 08:46:59AM -0700, Mike Larkin wrote:
> > On Tue, Aug 15, 2017 at 05:39:29PM +0200, Stefan Fritsch wrote:
> > > I have got a report that openbsd panics on boot with qemu -cpu Opteron_G3
> >
I have got a report that openbsd panics on boot with qemu -cpu Opteron_G3
(but Opteron_G2 works).
kernel: protection fault trap, code=0
Stopped at amd64_errata_setmsr+0x14: rdmsr
ddb{0}> >> OpenBSD/amd64 BOOT 3.33
boot>
Qemu does not implement all the secret errata MSR
Hi,
this is another try at making read clustering work for msdosfs.
Last year, mpi@ implemented VFS read clustering for MSDOSFS in
sys/msdosfs/denode.h 1.28
sys/msdosfs/msdosfs_vnops.c 1.105
This caused regressions when doing seeks past the end of the file and had.
to be reverted. Then I tried
Add new CLUST_END and use it as parameter to pcbmap() when searching
for end cluster, instead of explicitly passing 0x. This fixes potential
problem for FAT32, where cluster number may be legally bigger than 0x.
Also change clusteralloc() so that fillwith is not explicitly passed by caller
add to comments for pcbmap()
remove useless ";"
OK?
diff --git a/sys/msdosfs/msdosfs_fat.c b/sys/msdosfs/msdosfs_fat.c
index 3a3d4de0761..aeb822d4be2 100644
--- a/sys/msdosfs/msdosfs_fat.c
+++ b/sys/msdosfs/msdosfs_fat.c
@@ -123,6 +123,8 @@ fatblock(struct msdosfsmount *pmp, uint32_t ofs, uint32_
Hi,
is anyone still using floppies? If yes, it would be nice if they could
give the diff below a test. It defers probing of the drives which reduces
boot time quite a bit. If floppy does not work with the diff, please also
test if it works without it. On qemu, floppy access seems to be broken (
On Tue, 1 Aug 2017, Stefan Fritsch wrote:
> For consumer NICs, the patch only does something on I218_LM_3/I218_V_3 or
> I219* or newer.
Sorry, misread the code there. There are more i218 variants that are
affected by the patch.
Hi,
we have the problem that on some HP laptops with i219V, it sometimes
happens that em fails to attach with this error:
em0: Hardware Initialization Failed
em0: Unable to initialize the hardware
It seems there was some previous discussion of this issue here:
http://bugs.openbsd.narkive.com/9
On Sun, 9 Jul 2017, Mark Kettenis wrote:
> > there are some open issues that usb devices do not flush their caches fast
> > enough (at least on some boards). And my mail about shortening the wait
> > times in reboot(8) brought up that issue again.
> >
> > My suggestion would be to have a global
Hi,
there are some open issues that usb devices do not flush their caches fast
enough (at least on some boards). And my mail about shortening the wait
times in reboot(8) brought up that issue again.
My suggestion would be to have a global variable that takes the minimum
delay for the next shut
first is before the first sleep.
But more importantly, waiting for devices to flush out I/O should be done
by the respective drivers in the kernel. That way the wait only affects
those people who need it. I will send a separate mail about this.
>
>
> 2017-07-09 9:42 GMT+02:0
Hi,
what about only waiting for processes to die on reboot if there are any
processes left? Nice for the frequently rebooting kernel developer.
This usually saves at least one second and often 4-5 seconds when calling
reboot via ssh or 'exec reboot' from a console (otherwise the parent shell
w
This reduces the size of struct selinfo from 24 to 16 bytes on 64bit
archs.
struct sel_info is embedded in quite a few other structs (tty, kevent,
sockbuf, ...). So this may affect libkvm. What's the procedure for
changing such a struct?
Cheers,
Stefan
diff --git sys/sys/selinfo.h sys/sys/sel
On Tue, 13 Jun 2017, Martijn Rijkeboer wrote:
> Yes, this patch fixes the problem.
Thanks for the report and the testing. I have committed the revert
yesterday.
On Mon, 12 Jun 2017, Martijn Rijkeboer wrote:
> After upgrading to the latest snapshot there seems to be something wrong
> with the msdos filesystem driver. When I copy a binary file on a msdos (fat32)
> mounted partition the content changes e.g.:
>
> # cp refind_x64.efi bootx64.efi
> # ls -l
The same as is already implemented for ffs & msdosfs.
ok?
Cheers,
Stefan
diff --git a/sys/ufs/ext2fs/ext2fs_vfsops.c b/sys/ufs/ext2fs/ext2fs_vfsops.c
index 53eaa05a32a..98d5536418c 100644
--- a/sys/ufs/ext2fs/ext2fs_vfsops.c
+++ b/sys/ufs/ext2fs/ext2fs_vfsops.c
@@ -181,6 +181,7 @@ ext2fs_mount(
I have seen spurious "file system not clean; please fsck(8)" warnings
during "mount -ur". Set e2fs_fmod = 0 when writing the superblock (as
ffs does).
ok?
Cheers,
Stefan
diff --git a/sys/ufs/ext2fs/ext2fs_vfsops.c b/sys/ufs/ext2fs/ext2fs_vfsops.c
index 98d5536418c..372c4d6f1fc 100644
--- a/sys/
On Mon, 29 May 2017, Martin Pieuchot wrote:
> A complete diff would be easier to review.
ok, here it comes.
The original commit message was this:
Implement VFS read clustering for MSDOSFS.
The logic used in msdosfs_bmap() to loop calling pcbmap() comes from
FreeBSD and is
Last year, mpi@ implemented VFS read clustering for MSDOSFS in
sys/msdosfs/denode.h 1.28
sys/msdosfs/msdosfs_vnops.c 1.105
This caused regressions when doing seeks past the end of the file and had
to be reverted.
I have now written a test that catches the bug (committed in
regress/sys/fileops)
Don't skip the cache flush until the last opening of the device is
closed. Otherwise, when umounting a writable partition while a different
partition is still mounted read-only, the necessary disk flush may be
delayed for a very long time.
diff --git sys/scsi/sd.c sys/scsi/sd.c
index 4cd0e4d13bd.
Other file systems can be changed later.
diff --git sys/msdosfs/msdosfs_vfsops.c sys/msdosfs/msdosfs_vfsops.c
index e13b0b1ea0b..5cd273c4087 100644
--- sys/msdosfs/msdosfs_vfsops.c
+++ sys/msdosfs/msdosfs_vfsops.c
@@ -64,6 +64,7 @@
#include
#include
#include
+#include
#include
#include
Add an ioctl to tell storage devices to flush their internal caches.
Initially ported from netbsd by pedro@
I will implement it for nvme later (if we go ahead with this).
diff --git sys/dev/ata/wd.c sys/dev/ata/wd.c
index cd168223672..859fb454f44 100644
--- sys/dev/ata/wd.c
+++ sys/dev/ata/wd.c
Hi,
I want to come back to the discussion from Oct. 2016 on tech@ about a
disk cache flush ioctl.
The problem we want to solve is that in case of power loss, there should
be no data loss on partitions that are either mounted read-only or are
unmounted. This should also be true if such a partit
NVM_ADMIN_DEL_IOCQ does not need prp1 (just as NVM_ADMIN_DEL_IOSQ).
Remove what is likely a cut'n'paste error from the *_ADD_* code.
ok?
--- sys/dev/ic/nvme.c
+++ sys/dev/ic/nvme.c
@@ -1120,7 +1120,6 @@ nvme_q_delete(struct nvme_softc *sc, struct nvme_queue *q)
memset(&sqe, 0, sizeof(sq
On Fri, 26 May 2017, Claudio Jeker wrote:
> Testing it on my X270. I get:
> nvme0: unable to delete q, disabling
>
> Apart from that it seems to work (eventhough without inteldrm not very
> helpful since I lose the display).
Thanks for testing.
We get called twice on suspend, once with DVACT_SU
Hi,
does anyone know a specific reason why we should not request interface-mtu
by default? It may be set by the DHCP server enable jumbo frames or to
work around PMTU discovery breakage.
Cheers,
Stefan
--- a/sbin/dhclient/clparse.c
+++ b/sbin/dhclient/clparse.c
@@ -118,6 +118,8 @@ read_client_
Hi,
the following diff adds the missing bits to make suspend/resuem work with
nvme. It was done by ehrhardt@ and tested against nvme.c 1.50, but seems
to apply cleanly.
Unfortunately, I don't have any nvme hardware at the moment in order to
test it. Is there anyone who could test it?
Cheers,
On Wed, 23 Nov 2016, Mike Belopuhov wrote:
> This moves code that is supposed to be in init, but is in stop
> right now. Tested on qemu. OK?
The current code has some symmetry insofar that stop leaves the device in
the same state as it is after attach. With your diff, the first vio_init()
wou
On Wed, 23 Nov 2016, Mike Belopuhov wrote:
> This fixes up tsleep priorities in vio(4) and makes sleeps
> interruptable so that ifconfig can be killed with ^C. Tested
> on qemu with a previous diff that makes vio(4) hang there.
>
> OK?
I think the tsleep stuff is ok, but the vio_iff() changes ar
On Wed, 23 Nov 2016, Rafael Zalamena wrote:
> > Maybe something like this is enough already (untested):
>
> I tried your diff without Mike's if_vio diff and it doesn't panic anymore,
> however it doesn't work.
>
> vioX can send packets to host, host receives them and reply, but vioX
> doesn't se
On Wed, 23 Nov 2016, Mike Belopuhov wrote:
> > I am not convinced. Doing a reset allows to recover from all kinds of
> > problems with DOWN/UP. That was useful when we had bugs in the event_idx
> > implementation.
> >
>
> I don't think this justifies it since bugs need to be fixed regardless.
A
On Wed, 23 Nov 2016, Mike Belopuhov wrote:
> > I guess we could do that. But then we cannot free the mbufs on DOWN
> > until the device has used them.
>
> Diff to this effect is below. Works on vmd and qemu (original
> one didn't because I kept the virtio_reset).
>
> > That sounds like an unnece
On Wednesday, 23 November 2016 00:34:42 CET Mike Belopuhov wrote:
> Yes, after looking closer at virtio code I agree with you.
> However, stop/init is purely OpenBSD specific action. There
> are no provisions or requirements from the hardware really.
> Thus we can treat UP/DOWN as purely software
On Sunday, 30 October 2016 19:06:57 CET Theo de Raadt wrote:
> > > From: David Gwynne
> > > whats the use of the ioctl though? why do we need extra sync cache
> > > things?
> >
> > Right. This smells like papering over real bugs.
If there is a power loss or a usb disk device is removed, partit
On Sun, 30 Oct 2016, Stefan Fritsch wrote:
> I agree with all your comments (and should have reviewed the initial patch
> better). Here is an updated diff.
The FWRITE check was missing in wdioctl(). Next try:
diff --git sys/dev/ata/wd.c sys/dev/ata/wd.c
index 5e2461f..ca5ac90 100644
--- s
On Mon, 17 Oct 2016, Alexander Bluhm wrote:
> > Part 1: Add an ioctl:
> >
> >
> > add DIOCCACHESYNC
> >
> > Add an ioctl to tell storage devices to flush their internal caches.
> > Ported from netbsd by pedro@
> >
> > OK?
>
> Some remarks inline
Sorry for the long delay, I was very busy i
On Thursday, 20 October 2016 20:55:47 CEST Lampshade wrote:
> What if somebody remounts
> from normal options
> (metadata: sync, data: async)
> to fully synced
> (metadata: sync, data: sync)
>
> Example:
> # mount | grep home
> /dev/sd1h on /home type ffs (local, noatime, nodev, nosuid)
> # /sbin/
On Sun, 16 Oct 2016, Stefan Fritsch wrote:
> > * When a R/W mount is updated to R/O. I will send patches for this in a
> > separate mail.
Part 2: Use it
msdosfs & ffs: flush cache if updating mount to r/o
Other filesystems can be changed later.
ok?
diff --git sys/msdosfs/
On Sun, 16 Oct 2016, Stefan Fritsch wrote:
> * When a R/W mount is updated to R/O. I will send patches for this in a
> separate mail.
Part 1: Add an ioctl:
add DIOCCACHESYNC
Add an ioctl to tell storage devices to flush their internal caches.
Ported from netbsd by pedro@
OK?
diff
[moving to tech@]
On Tuesday, 20 September 2016 08:03:32 CEST Stefan Fritsch wrote:
> On Tue, 20 Sep 2016, Darren Tucker wrote:
> > On Tue, Sep 20, 2016 at 1:43 AM, Jan Stary wrote:
> > > This is current/i386 on an ALIX.1E (demsg below).
> > > I have an USB
On Friday, 14 October 2016 15:48:47 CEST Mark Kettenis wrote:
> > Date: Fri, 14 Oct 2016 16:49:31 +0900 (JST)
> > From: YASUOKA Masahiko
> >
> > Hi,
> >
> > I'm working on NEC Express5800/R110h-1 (dmesg is attached). On this
> > machine, our kernel panics with following message.
> >
> > cpu0
On Mon, 11 Jul 2016, Theo de Raadt wrote:
> > No, I didn't know that. I assumed that having a few more GBs of bufcache
> > would help the performance. Until that is the case, 64bit dma does not
> > make much sense.
>
> BTW, my tests were on a 128GB sun4v machine. Sun T5140. They are
> actually
On Mon, 11 Jul 2016, Theo de Raadt wrote:
> > Openbsd on amd64 assumes that DMA is only possible to the lower 4GB.
>
> Not exactly. On an architecture-by-architecture basis, OpenBSD is
> capable of insisting DMA reachable memory only lands in a smaller zone
> of memory -- because it makes the ot
On Mon, 11 Jul 2016, Ted Unangst wrote:
> Stefan Fritsch wrote:
> > On Mon, 11 Jul 2016, Reyk Floeter wrote:
> > > The intentional 4GB limit is for forwarding: what if you forward mbufs
> > > from a 64bit-capable interface to another one that doesn't support 6
Reyk
>
> > On 11.07.2016, at 15:37, Stefan Fritsch wrote:
> >
> > Hi,
> >
> > following the discussion about mbufs, I have some questions about 64bit
> > DMA in general.
> >
> > Openbsd on amd64 assumes that DMA is only possible to the lower 4G
Hi,
following the discussion about mbufs, I have some questions about 64bit
DMA in general.
Openbsd on amd64 assumes that DMA is only possible to the lower 4GB. But
there are many devices (PCIe, virtio, ...) that can do DMA to the whole
memory. Is it feasible to have known good devices opt-in
On Thursday 23 June 2016 14:41:53, Mark Kettenis wrote:
> We really don't want to implement bounce-buffers. Adding IOMMU
> support is probably a better approach as it also brings some
> security benefits. Not all amd64 hardware supports an IOMMU. And
> hardware that does support it doesn't alway
On Friday 29 April 2016 14:09:23, Mark Kettenis wrote:
> I think we should simply continue the current practice of not using
> static in the kernel. I mean, what is the benefit of abandoning
> that practice if you disable the optimizations that compiler would
> make anyway?
You get a clear separa
As there isn't any consensus for one of the other solutions, I am going to
commit the patch that fixes this inside vio(4).
On Thu, 14 Jan 2016, Stefan Fritsch wrote:
> On Mon, 4 Jan 2016, Stefan Fritsch wrote:
> > On Sun, 3 Jan 2016, Theo de Raadt wrote:
> > > >> dlg
On Mon, 4 Jan 2016, Stefan Fritsch wrote:
> On Sun, 3 Jan 2016, Theo de Raadt wrote:
> > >> dlg writes:
> > >> > should we just do it unconditionally? is there a downside to that?
> > >
> > >It may decrease performance a tiny bit. Since such bits ten
On Wed, 13 Jan 2016, Theo de Raadt wrote:
> - tp->t_ispeed = tp->t_ospeed = TTYDEF_SPEED;
> + tp->t_ispeed = tp->t_ospeed = 100;
>
> I don't think that is the right thing to do, without some testing.
> That is directly visible in the program running on the pty. Som
Hi,
the buffer sizes allocated in the tty layer are too small for todays use
cases like l2tp and virtio-console. Also, the watermarks used by ppp are
way to small and do not scale with the line speed.
This patch
- makes 115200 the default speed for buffer sizing in ttymalloc(). A lot
of devic
On Thu, 7 Jan 2016, Mike Belopuhov wrote:
> On 7 January 2016 at 13:17, Mark Kettenis wrote:
> >> From: Mike Belopuhov
> >> Date: Thu, 7 Jan 2016 12:02:23 +0100
> >>
> >> On 6 January 2016 at 17:58, Stefan Fritsch wrote:
> >> > On Wed, 6 Jan
On Wed, 6 Jan 2016, Mike Belopuhov wrote:
> There's still stuff to do, but it receives and transmits reliably
> (at least on modern Xen) so I'd like to get it in. Man page will
> follow.
I only had a quick glance at the code, but I have one comment about your
use of memory barriers. The membar_
On Mon, 4 Jan 2016, Claudio Jeker wrote:
> On Sat, Jan 02, 2016 at 04:04:33PM +0100, Mark Kettenis wrote:
> > > Date: Sat, 2 Jan 2016 10:57:41 +0100
> > > From: Martin Pieuchot
> > >
> > > If it's acceptable performance-wise to do the check unconditionally I
> > > believe that's the way to go.
On Sun, 3 Jan 2016, Theo de Raadt wrote:
> >On Friday 01 January 2016 16:25:59, Theo de Raadt wrote:
> >> dlg writes:
> >> > should we just do it unconditionally? is there a downside to that?
> >
> >It may decrease performance a tiny bit. Since such bits tend to add
> >up, I would be hesitant to
1 - 100 of 210 matches
Mail list logo