em: Fix potential endless loop in attach

2019-09-02 Thread Stefan Fritsch
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

2019-09-02 Thread Stefan Fritsch
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

2019-06-02 Thread Stefan Fritsch
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

2019-01-19 Thread Stefan Fritsch
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()

2019-01-19 Thread Stefan Fritsch
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

2019-01-19 Thread Stefan Fritsch
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

2019-01-19 Thread Stefan Fritsch
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

2019-01-19 Thread Stefan Fritsch
--- 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

2019-01-19 Thread Stefan Fritsch
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

2019-01-19 Thread Stefan Fritsch
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

2019-01-19 Thread Stefan Fritsch
--- 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

2019-01-19 Thread Stefan Fritsch
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

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

Re: Virtio 1.0 for the kernel

2019-01-11 Thread Stefan Fritsch
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

2019-01-11 Thread Stefan Fritsch
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

2019-01-11 Thread Stefan Fritsch
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

2019-01-10 Thread Stefan Fritsch
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

2019-01-10 Thread Stefan Fritsch
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

2019-01-08 Thread Stefan Fritsch
@@ -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

2018-04-29 Thread Stefan Fritsch
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

2018-04-22 Thread Stefan Fritsch
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

2018-04-22 Thread Stefan Fritsch
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

2018-04-07 Thread Stefan Fritsch
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

2018-04-07 Thread Stefan Fritsch
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

2018-04-05 Thread Stefan Fritsch
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

2018-04-05 Thread Stefan Fritsch
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

2018-04-05 Thread Stefan Fritsch
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

2018-04-05 Thread Stefan Fritsch
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

2018-04-05 Thread Stefan Fritsch
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

2018-04-05 Thread Stefan Fritsch
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

2018-04-05 Thread Stefan Fritsch
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

2018-04-05 Thread Stefan Fritsch
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

2018-04-02 Thread Stefan Fritsch
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.

2017-08-15 Thread Stefan Fritsch
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?

2017-08-15 Thread Stefan Fritsch
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

2017-08-15 Thread Stefan Fritsch
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

minor msdosfs tweaks

2017-08-13 Thread Stefan Fritsch
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,

Looking for testers with a floppy drive

2017-08-13 Thread Stefan Fritsch
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

2017-08-02 Thread Stefan Fritsch
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

2017-08-01 Thread Stefan Fritsch
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

2017-07-10 Thread Stefan Fritsch
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

2017-07-09 Thread Stefan Fritsch
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

2017-07-09 Thread Stefan Fritsch
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

2017-07-09 Thread Stefan Fritsch
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

2017-07-09 Thread Stefan Fritsch
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

2017-06-14 Thread Stefan Fritsch
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

2017-06-12 Thread Stefan Fritsch
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

2017-05-30 Thread Stefan Fritsch
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

2017-05-30 Thread Stefan Fritsch
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"

2017-05-29 Thread Stefan Fritsch
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"

2017-05-29 Thread Stefan Fritsch
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

2017-05-28 Thread Stefan Fritsch
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

2017-05-28 Thread Stefan Fritsch
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

2017-05-28 Thread Stefan Fritsch
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

2017-05-27 Thread Stefan Fritsch
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?

2017-05-26 Thread Stefan Fritsch
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

2017-05-26 Thread Stefan Fritsch
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

2016-11-23 Thread Stefan Fritsch
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

2016-11-23 Thread Stefan Fritsch
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

2016-11-23 Thread Stefan Fritsch
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

2016-11-23 Thread Stefan Fritsch
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

2016-11-23 Thread Stefan Fritsch
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

2016-11-22 Thread Stefan Fritsch
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

2016-10-31 Thread Stefan Fritsch
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

2016-10-30 Thread Stefan Fritsch
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

2016-10-30 Thread Stefan Fritsch
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

2016-10-29 Thread Stefan Fritsch
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

2016-10-16 Thread Stefan Fritsch
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

2016-10-16 Thread Stefan Fritsch
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

2016-10-16 Thread Stefan Fritsch
[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

2016-10-14 Thread Stefan Fritsch
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

2016-07-11 Thread Stefan Fritsch
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

2016-07-11 Thread Stefan Fritsch
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

2016-07-11 Thread Stefan Fritsch
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

2016-07-11 Thread Stefan Fritsch
> > > 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

2016-07-11 Thread Stefan Fritsch
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

2016-06-25 Thread Stefan Fritsch
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

2016-05-08 Thread Stefan Fritsch
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

2016-01-21 Thread Stefan Fritsch
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

2016-01-14 Thread Stefan Fritsch
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

2016-01-12 Thread Stefan Fritsch
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

2016-01-06 Thread Stefan Fritsch
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

2016-01-04 Thread Stefan Fritsch
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

2016-01-04 Thread Stefan Fritsch
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

2016-01-02 Thread Stefan Fritsch
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

2016-01-01 Thread Stefan Fritsch
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)

2015-12-22 Thread Stefan Fritsch
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

2015-09-11 Thread Stefan Fritsch
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

2015-09-07 Thread Stefan Fritsch
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

2015-09-06 Thread Stefan Fritsch
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

2015-08-05 Thread Stefan Fritsch
Thanks to everyone for the testing. The patch is now committed.

Possible fix for i217 problem

2015-08-04 Thread Stefan Fritsch
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

Re: usb hang related to xhci

2015-07-19 Thread Stefan Fritsch
On Sat, 18 Jul 2015, David Hill wrote: Whenever I plug a device into my USB ports, my machine locks hard. I have the Intel Series 7 / C216 chip, so xhci attempts to route the port from ehci to xhci. The following diff is from FreeBSD and makes my USB devices work again.

Call for testing for tty diff

2015-07-17 Thread Stefan Fritsch
While writing a virtio-console driver, I have found a bug in ttwrite() that can cause hangs. Below is a fix and after talking to Theo, I would like to know if the patch causes regressions for anyone, for example hangs in pty input/output, serial ports, etc. Thanks in advance. Cheers, Stefan

Re: add m_defrag to pcn driver

2015-04-08 Thread Stefan Fritsch
On Wednesday 08 April 2015 09:48:14, David Gwynne wrote: +continue; +} Other drivers don't dequeue mbufs in out of mem situations. I think you should just set IFF_OACTIVE and break out of the for loop (not shown in the diff). The old code just

Re: add m_defrag to pcn driver

2015-04-07 Thread Stefan Fritsch
Hi, I have committed the vio diff with some tweaks to remove some more now unused code. But I think this diff is actually incorrect: On Tue, 31 Mar 2015, Kimberley Manning wrote: Index: if_pcn.c === RCS file:

Re: add m_defrag to pcn driver

2015-04-01 Thread Stefan Fritsch
On Wednesday 01 April 2015 12:46:47, Kimberley Manning wrote: This diff makes the pcn driver use m_defrag for fragmented mbuf chains, I like this kind of cleanups. As for vio(4) could you try the diff or are you looking for testers? Thanks. I've tried both the vio and pcn diffs

Re: Binary code patching and paravirtualization

2014-12-16 Thread Stefan Fritsch
On Mon, 15 Dec 2014, Ted Unangst wrote: On Mon, Dec 15, 2014 at 23:55, Stefan Fritsch wrote: Only in order to get a flags field that can be tweaked with config(8). And to allow disable via config(8), though that could also be achieved with a flag. Tweaking the behavior with a flags

Re: Binary code patching and paravirtualization

2014-12-15 Thread Stefan Fritsch
On Thu, 11 Dec 2014, Mark Kettenis wrote: From: Alexey Suslikov alexey.susli...@gmail.com Date: Thu, 11 Dec 2014 20:51:14 + (UTC) Stefan Fritsch sf at sfritsch.de writes: --- a/sys/arch/amd64/include/specialreg.h +++ b/sys/arch/amd64/include/specialreg.h at at -158,6

Re: Binary code patching and paravirtualization

2014-12-15 Thread Stefan Fritsch
On Mon, 15 Dec 2014, Ted Unangst wrote: On Wed, Dec 10, 2014 at 00:32, Stefan Fritsch wrote: --- a/sys/arch/amd64/conf/GENERIC +++ b/sys/arch/amd64/conf/GENERIC @@ -39,6 +39,8 @@ isa0 at amdpcib? isa0at tcpcib? pci*at mainbus0 +paravirt0 at mainbus0

  1   2   >