Re: Virtio fix for testing

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

virtio: Fix handling of feature bits >= 32

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

msdosfs: fixes for Undefined Behavior

>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

Re: Virtio fix for testing

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

Virtio fix for testing

this 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

Re: OpenBSD 7.2 on Oracle Cloud

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

Re: OpenBSD 7.2 on Oracle Cloud

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

Re: OpenBSD 7.2 on Oracle Cloud

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

msdosfs: Never allocate clusters outside the volume

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

em: Fix potential endless loop in attach

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()

bnxt: Support MSI-X

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

MSI-X suspend/resume

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

[PATCH 2/7] virtio: Prepare for 64 feature bits

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 |

[PATCH 6/7] Rework virtio_negotiate_features()

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()

[PATCH 7/7] Support virtio 1.0 for virtio_pci

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 +-

[PATCH 4/7] virtio_pci: Split bus space handles

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

[PATCH 5/7] virtio_pci: Move msix vector config into functions

--- 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 @@

[PATCH 1/7] virtio: adjust virtio_setup_queue prototype for 1.0

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

[PATCH 0/7] Virtio 1.0 in the kernel

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

[PATCH 3/7] virtio: Add a few feature bit defines and names

--- 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

Re: Virtio 1.0 for the kernel

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

Re: Virtio 1.0 for the kernel

On Fri, 11 Jan 2019, Ted Unangst wrote: > Stefan Fritsch wrote: > > +#define CREAD(sc, memb) > > \ > > + ({ > > \ > > +

Re: Virtio 1.0 for the kernel

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

Re: Virtio 1.0 for the kernel

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

Re: Virtio 1.0 for the kernel

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

Virtio 1.0 for the kernel

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

Add virtio 1.0 pci ids

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 @@

Driver for accessing qemu fwcfg via hostctl

@@ -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 notice and this per

Re: Looking for testers for em(4) quirks patch

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

Re: [PATCH 7/7] em: Add magic delay for HP elitebook 820 G3

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

Re: [PATCH 4/7] em: Improve access logic for software flag

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)

Re: [PATCH 1/7] em: Print error code and phy/mac type

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

Re: [PATCH 7/7] em: Add magic delay for HP elitebook 820 G3

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. &

[PATCH 1/7] em: Print error code and phy/mac type

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 ---

[PATCH 6/7] em: Port an i219 errata workaround from FreeBSD

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

[PATCH 3/7] em: Add em_check_phy_reset_block() quirk

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

[PATCH 4/7] em: Improve access logic for software flag

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. ---

[PATCH 7/7] em: Add magic delay for HP elitebook 820 G3

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

[PATCH 5/7] em: Make em_get_software_flag() recursive

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

[PATCH 2/7] em: Increase delay after reset to 20ms

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 @@

Re: Looking for testers for em(4) quirks patch

On Thu, 5 Apr 2018, Mark Kettenis wrote: > > Date: Thu, 5 Apr 2018 02:02:20 +1000 > > From: Jonathan Gray <j...@jsg.id.au> > > > > On Mon, Apr 02, 2018 at 11:52:08AM +0200, Stefan Fritsch wrote: > > > Hi, > > > > > > We have seen pro

Looking for testers for em(4) quirks patch

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.

More docs for buffer cache, block sizes, etc.

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

Skipping amd errata on hypervisors?

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

Implement VFS read clustering for MSDOSFS, third try

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

Looking for testers with a floppy drive

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

Re: em: workaround for ultra-low-power mode on i219V

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.

em: workaround for ultra-low-power mode on i219V

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:

Re: Allowing devices to set a minimum wait time at power down/reboot

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

Allowing devices to set a minimum wait time at power down/reboot

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

Re: reboot: Only wait for procs if there are any

the 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:00 Stef

reboot: Only wait for procs if there are any

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

De-hole struct sel_info

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

Re: Copying a file on msdos FS (fat32) changes content

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.

Re: Copying a file on msdos FS (fat32) changes content

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

ext2: flush cache on mount -ur

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: Mark superblock as not modified when written

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 ---

Re: Fix for "Implement VFS read clustering for MSDOSFS"

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

Fix for "Implement VFS read clustering 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. I have now written a test that catches the bug (committed in

msdosfs & ffs: flush cache if updating mount to r/o

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

Add DIOCCACHESYNC ioctl

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

Flush disk cache on mount -ur

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

Re: Suspend/Resume for nvme

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

dhclient: request interface-mtu by default?

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 @@

Suspend/Resume for nvme

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,

Re: Relocate some of the vio(4) (re)init code into vio_init

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()

Re: Fixup tsleeps in vio(4) and make them interruptable

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

Re: vio(4): fixup crash on up/down

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

Re: vio(4): fixup crash on up/down

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.

Re: vio(4): fixup crash on up/down

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

Re: vio(4): fixup crash on up/down

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

Re: Add ioctl for disk cache flush

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

Re: Add ioctl for disk cache flush

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

Re: Add ioctl for disk cache flush

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

Re: usb disk dirty after every reboot

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) > #

ffs/msdosfs: Flush cache when updating mount to R/O

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/

Add ioctl for disk cache flush

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

Re: usb disk dirty after every reboot

[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 <h...@stare.cz> wrote: > > > This is current/i386 on an ALIX.1E (demsg below). > >

Re: use x2apic if it is enabled by BIOS

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

Re: 64bit DMA on amd64

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 >

Re: 64bit DMA on amd64

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

Re: 64bit DMA on amd64

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 64bit

Re: 64bit DMA on amd64

> > > On 11.07.2016, at 15:37, Stefan Fritsch <s...@sfritsch.de> wrote: > > > > Hi, > > > > following the discussion about mbufs, I have some questions about 64bit > > DMA in general. > > > > Openbsd on amd64 assumes that DMA is

64bit DMA on amd64

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

Re: [PATCH] let the mbufs use more then 4gb of memory

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

Re: static in ze kernel

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

Re: Checking MAC address of incoming unicast packets

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 writ

Re: Checking MAC address of incoming unicast packets

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

Re: Xen virtual network (Netfront) driver

On Thu, 7 Jan 2016, Mike Belopuhov wrote: > On 7 January 2016 at 13:17, Mark Kettenis <mark.kette...@xs4all.nl> wrote: > >> From: Mike Belopuhov <m...@belopuhov.com> > >> Date: Thu, 7 Jan 2016 12:02:23 +0100 > >> > >> On 6 January 201

Re: Xen virtual network (Netfront) driver

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

Re: Checking MAC address of incoming unicast packets

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

Re: Checking MAC address of incoming unicast packets

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

Re: Checking MAC address of incoming unicast packets

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 enable the check for drivers that don't need it. OTOH,

Checking MAC address of incoming unicast packets

Hi, by default, the ether_input() checks the destination MAC address of incoming unicast packets only if the interface is in promiscous mode. If not, it is assumed that the NIC filters unicast packets reliably. Unfortunately, for virtio-net this is not the case. There, unicast filtering is

Re: pppd and ioctl(TIOCSETD) (was: CVS: cvs.openbsd.org: src)

On Tue, 22 Dec 2015, David Coppa wrote: > I suspect this broke my 3G connection: Oops. Sorry. Try this diff (already committed): --- sys/kern/tty_conf.c +++ sys/kern/tty_conf.c @@ -42,6 +42,11 @@ #include #include +#include "ppp.h" +#include "nmea.h" +#include "msts.h" +#include "endrun.h"

Re: Looking for testers for amd64 suspend diff

On Sunday 06 September 2015 11:44:11, Stefan Fritsch wrote: > the diff below is necessary to make suspend/resume work when x2apic > is enabled (i.e. on qemu/kvm/...). While I don't expect problems, > it would be nice if I could get some reports that this doesn't > break suspend/re

Re: Looking for testers for amd64 suspend diff

On Monday 07 September 2015 13:23:03, Alexander Bluhm wrote: > Suspend OpenBSD in a fully emulated qemu running on OpenBSD works. > After resume, typing in the shell of the virtualized machine works. > But at disk access, all processes hang in biowait. > > It is the same behavior with and without

Looking for testers for amd64 suspend diff

Hi, the diff below is necessary to make suspend/resume work when x2apic is enabled (i.e. on qemu/kvm/...). While I don't expect problems, it would be nice if I could get some reports that this doesn't break suspend/resume on real machines, especially older ones (like core 2 duo and older) and

Re: Possible fix for i217 problem

Thanks to everyone for the testing. The patch is now committed.

Possible fix for i217 problem

Hi, someone mentioned to me the i217-LM problems that were reported on misc end of May. It is possible that the patch below helps. For us, it fixed a problem on a laptop with i217-LM (pci id 8086:153a) where the receiving of packets would stop until the battery of the laptop was removed (or

  1   2   >