Re: ixg tester needed (was Re: Problems with netbsd-8 RC1 and ixg drivers (?))
The same diff is at:
http://www.netbsd.org/~msaitoh/ixgbe-norearm-20180530-0.dif
Updated patch (Fix compile error and ixv patch):
--
Don't call ixgbe_rearm_queues() in ixgbe_local_timer1(). ixgbe_enable_queue()
and ixgbe_disable_queue() try to enable/disable queue interrupt safely. It
has the internal counter. When a queue's MSI-X is received, ixgbe_msix_que()
is called (IPL_NET). This function disable the queue's interrupt by
ixgbe_disable_queue() and issues an softint. ixgbe_handle() queue is called by
the softint (IPL_SOFTNET), process TX,RX and call ixgbe_enable_queue() at the
end.
ixgbe_local_timer1() is a callout and run always on CPU 0 (IPL_SOFTCLOCK).
When ixgbe_rearm_queues() called, an MSI-X interrupt is issued for a specific
queue. It may not CPU 0. If this interrupt's ixgbe_msix_que() is called
and sofint_schedule() is called before the last sofint's softint_execute()
is not called, the softint_schedule() fails because of SOFTINT_PENDING.
It result in breaking ixgbe_{enable,disable}_queue()'s internal counter.
ixgbe_local_timer1() is written not to call ixgbe_rearm_queues() if
the interrupt is disabled, but it's called because of unknown bug or a race.
One solution is to not to use the internal counter, but it's little difficult.
Another solution is stop using ixgbe_rearm_queues() at all. Essentially,
ixgbe_rearm_queues() is not required (it was added in ixgbe.c rev. 1.43
(2016/12/01)). ixgbe_rearm_queues() helps for lost interrupt problem but
I've never seen it other than ixgbe_rearm_queues() problem.
Index: ixgbe.c
===
RCS file: /cvsroot/src/sys/dev/pci/ixgbe/ixgbe.c,v
retrieving revision 1.158
diff -u -p -r1.158 ixgbe.c
--- ixgbe.c 30 May 2018 09:17:17 - 1.158
+++ ixgbe.c 1 Jun 2018 03:22:05 -
@@ -4411,6 +4411,7 @@ ixgbe_local_timer1(void *arg)
/* Only truely watchdog if all queues show hung */
if (hung == adapter->num_queues)
goto watchdog;
+#if 0 /* XXX Avoid unexpectedly disabling interrupt forever (PR#53294) */
else if (queues != 0) { /* Force an IRQ on queues with work */
que = adapter->queues;
for (i = 0; i < adapter->num_queues; i++, que++) {
@@ -4421,6 +4422,7 @@ ixgbe_local_timer1(void *arg)
mutex_exit(&que->dc_mtx);
}
}
+#endif
out:
callout_reset(&adapter->timer, hz, ixgbe_local_timer, adapter);
@@ -6643,7 +6645,7 @@ ixgbe_handle_link(void *context)
/
* ixgbe_rearm_queues
/
-static void
+static __inline void
ixgbe_rearm_queues(struct adapter *adapter, u64 queues)
{
u32 mask;
Index: ixv.c
===
RCS file: /cvsroot/src/sys/dev/pci/ixgbe/ixv.c,v
retrieving revision 1.102
diff -u -p -r1.102 ixv.c
--- ixv.c 30 May 2018 08:35:26 - 1.102
+++ ixv.c 1 Jun 2018 03:22:05 -
@@ -1266,9 +1266,11 @@ ixv_local_timer_locked(void *arg)
/* Only truly watchdog if all queues show hung */
if (hung == adapter->num_queues)
goto watchdog;
+#if 0
else if (queues != 0) { /* Force an IRQ on queues with work */
ixv_rearm_queues(adapter, queues);
}
+#endif
callout_reset(&adapter->timer, hz, ixv_local_timer, adapter);
------
The same diff is at:
http://www.netbsd.org/~msaitoh/ixgbe-norearm-20180531-0.dif
--
---
SAITOH Masanobu (msai...@execsw.org
msai...@netbsd.org)
daily CVS update output
Updating src tree: P src/distrib/sets/mkvars.mk P src/distrib/sets/lists/base/mi P src/external/atheros/Makefile P src/external/broadcom/Makefile P src/external/bsd/acpica/bin/iasl/Makefile P src/external/bsd/libpcap/lib/Makefile P src/external/bsd/top/dist/top.c P src/external/bsd/top/dist/machine/m_netbsd.c P src/external/bsd/unbound/sbin/Makefile.inc P src/external/cddl/osnet/sys/sys/opentypes.h P src/external/cddl/osnet/sys/sys/time.h P src/external/cddl/osnet/sys/sys/types.h P src/external/gpl2/dtc/usr.bin/dtc/Makefile P src/external/intel-fw-eula/Makefile P src/external/intel-fw-public/Makefile P src/external/mit/xorg/xorg-pkg-ver.mk P src/external/mit/xorg/lib/xkeyboard-config/Makefile.xkbdata P src/external/mit/xorg/lib/xkeyboard-config/rules/Makefile P src/external/mit/xorg/share/fonts/Makefile P src/external/mpl/dhcp/dist/common/bpf.c P src/external/realtek/Makefile P src/lib/libipsec/config.h P src/share/man/man4/envsys.4 P src/share/man/man4/udp.4 P src/share/mk/bsd.README P src/share/mk/bsd.own.mk P src/sys/arch/aarch64/aarch64/aarch64_reboot.c P src/sys/arch/aarch64/aarch64/db_interface.c P src/sys/arch/arm/arm32/arm32_reboot.c P src/sys/arch/arm/sunxi/sunxi_gpio.c P src/sys/arch/mips/include/vmparam.h P src/sys/arch/riscv/include/vmparam.h P src/sys/arch/sparc/sparc/locore.s P src/sys/arch/sun2/conf/FOURMEG P src/sys/arch/x86/include/specialreg.h P src/sys/compat/svr4/svr4_stream.c P src/sys/dev/microcode/ral/Makefile P src/sys/dev/microcode/rum/Makefile P src/sys/dev/microcode/run/Makefile P src/sys/dev/microcode/zyd/Makefile P src/sys/dev/pci/pcidevs P src/sys/dev/pci/pcidevs.h P src/sys/dev/pci/pcidevs_data.h P src/sys/external/bsd/drm2/nouveau/nouveau_pci.c P src/sys/netinet/in_pcb.h P src/sys/netinet/udp_usrreq.c P src/sys/netipsec/ipsec_mbuf.c P src/sys/netipsec/ipsec_output.c P src/sys/netipsec/ipsecif.c P src/sys/netipsec/xform_ah.c P src/sys/netipsec/xform_esp.c P src/tests/usr.bin/nbperf/Makefile Updating xsrc tree: Killing core files: Updating file list: -rw-rw-r-- 1 srcmastr netbsd 57048184 Jun 1 03:11 ls-lRA.gz
NetBSD 8.0_RC1 (May 22 build) install on GPT/UEFI system
Saw the traffic about doing an install on a GPT/UEFI system that referenced the
setup I’d used and posted about a year ago. It worked back then.
So I dug out my old script, updated it to do an install of NetBSD 8.0_RC1 on a
system with GPT disk layout and UEFI booting. The script put everything on the
newly formatted disk and it all looked correct, so I tried booting and I’m
getting:
efi: systbl at pa cad2ef18
uvm_fault …
fatal page fault in supervisor mode …
What’s interesting is when the banner came up it showed total memory of 527 MB
with 487 MB available. This system actually has 8 Gig of RAM.
So, has anyone tried doing an install of the May 22nd build on a system with
GPT disk layout and UEFI booting? Was it successful?
And, does anyone have a clue what could be happening here? Is it possible my
system has a totally screwed up setup for UEFI?
Thanks,
-bob
Oh, If anyone would be interested, here’s the script I used:
#!/bin/csh
#
# Set install parameters
#
set ver = 8.0
set net = wm0
set dsk = wd0
#
# NOTE: You MUST use the uefi-install image for this to work properly.
# But, when you boot this image after placing it on a USB stick it
# will create two wedges for what's on the USB. Therefore the wedge
# references in this script are "off by 2" to account for this. If
# you attempt this with the non-uefi-install image it will fail for
# two reasons. First the wedge numbering won't be correct and second
# the kernel file loaded into your new disk won't boot properly since
# it knows nothing about how to obtain information from the EFI, it
# assumes a BIOS instead.
#
# Installs NetBSD onto $dsk as a UEFI bootable disk
# Download the USB install image - NetBSD-$ver-amd64-uefi-install.img.gz
# Unpack the instlal image
# gunzip NetBSD-$ver-amd64-uefi-install.img.gz
# Place the image on a USB stick
# dd if=NetBSD-$ver-amd64-uefi-install.img of=/dev/rsd0d bs=32k
# Mount the USB
# mount /dev/dk1 /mnt
# Copy this script to the USB filesystem
# cp /mnt/uefi_install
# chmod +x /mnt/uefi_install
# Boot up the target system from the USB stick
# Exit the sysinst to get a command line prompt
# Invoke this script to install onto the $dsk disk
# ./uefi_install
#
# Create the GPT segments
#
echo "Creating GPT segments on $dsk disk"
gpt destroy $dsk
dd if=/dev/zero of=/dev/r${dsk}d count=1000
gpt create -f $dsk
gpt add -s 131072 -t efi -l "EFI System" $dsk
gpt add -s 524288 -t ffs -l "NetBSD-root" $dsk
gpt add -s 524288 -t swap -l "NetBSD-swap" $dsk
gpt add -s 32768000 -t ffs -l "NetBSD-var" $dsk
gpt add -s 32768000 -t ffs -l "NetBSD-usr" $dsk
gpt add -s 32768000 -t ffs -l "NetBSD-home" $dsk
gpt add -t windows -l “unallocated" $dsk
gpt show -l $dsk
#
# Initialize the NetBSD wedges
#
echo "Initializing new disk wedges"
newfs_msdos /dev/rdk2
newfs /dev/rdk3
newfs /dev/rdk5
newfs /dev/rdk6
newfs /dev/rdk7
#
# Mount the new filesystems
#
echo "Mounting new target disk wedges"
mount /dev/dk3 /targetroot
cd /target root
mkdir var usr home cdrom kern mnt proc
mount /dev/dk5 /targetroot/var
mount /dev/dk6 /targetroot/usr
mount /dev/dk7 /targetroot/home
#
# Load NetBSD
#
echo "Loading kernel(s) to new disk"
cd /targetroot
cp /amd64/binary/kernel/netbsd-GENERIC.gz .
cp /amd64/binary/kernel/netbsd-XEN3_DOM0.gz .
gunzip netbsd-GENERIC.gz
mv netbsd-GENERIC netbsd
echo "Loading base"
tar -xzpf /amd64/binary/sets/base.tgz
echo "Loading comp"
tar -xzpf /amd64/binary/sets/comp.tgz
echo "Loading etc"
tar -xzpf /amd64/binary/sets/etc.tgz
echo "Loading games"
tar -xzpf /amd64/binary/sets/games.tgz
echo "Loading man"
tar -xzpf /amd64/binary/sets/man.tgz
echo "Loading misc"
tar -xzpf /amd64/binary/sets/misc.tgz
echo "Loading modules"
tar -xzpf /amd64/binary/sets/modules.tgz
echo "Loading text"
tar -xzpf /amd64/binary/sets/text.tgz
echo "Loading xbase"
tar -xzpf /amd64/binary/sets/xbase.tgz
echo "Loading xcomp"
tar -xzpf /amd64/binary/sets/xcomp.tgz
echo "Loading xetc"
tar -xzpf /amd64/binary/sets/xetc.tgz
echo "Loading xfont"
tar -xzpf /amd64/binary/sets/xfont.tgz
echo "Loading xserver"
tar -xzpf /amd64/binary/sets/xserver.tgz
#
# Make devices
#
echo "Making devices in new system"
cd /targetroot/dev
sh ./MAKEDEV all
#
# Create the target system's fstab
#
echo "Creating fstab for new system"
cd /targetroot/etc
cat >fstab >rc.conf
echo “hostname=bandit” >>rc.conf
echo "dpcpcd=YES" >>rc.conf
echo “dhcpcd_flags=\”-qM $net\” ” >>rc.conf
echo "sshd=YES" >>rc.conf
echo "xdm=YES" >>rc.conf
echo "wscons=YES" >>rc.conf
#
# Set timezone for system
#
echo "Setting timezone to Central"
cd /targetroot/etc
rm localtime
ln -s ../usr/share/zoneinfo/America/Chicago localtime
#
# Install the loaders
#
echo "Installing EFI loaders"
mount_msdos -l /dev/dk2 /mnt2
mkdir -p /mnt2/EFI/boot
cp /targetroot/usr/mdec/*.efi /mnt2/EFI/boot/
#
# Install pkgin an
Automated report: NetBSD-current/i386 test failure
This is an automatically generated notice of new failures of the NetBSD test suite. The newly failing test cases are: lib/libc/sys/t_ptrace_wait3:traceme_vfork_crash_bus lib/libc/sys/t_ptrace_wait4:traceme_vfork_crash_bus lib/libc/sys/t_ptrace_wait6:traceme_vfork_crash_bus lib/libc/sys/t_ptrace_wait:traceme_vfork_crash_bus lib/libc/sys/t_ptrace_waitpid:traceme_vfork_crash_bus The above tests failed in each of the last 3 test runs, and passed in at least 27 consecutive runs before that. The following commits were made between the last successful test and the failed test: 2018.05.30.17.17.11 maxv src/sys/netipsec/xform.h,v 1.20 2018.05.30.17.17.11 maxv src/sys/netipsec/xform_ah.c,v 1.104 2018.05.30.17.17.11 maxv src/sys/netipsec/xform_esp.c,v 1.94 2018.05.30.17.31.34 kamil src/tests/kernel/h_segv.c,v 1.6 2018.05.30.17.31.34 kamil src/tests/lib/libc/sys/t_ptrace_wait.h,v 1.10 2018.05.30.17.48.13 kamil src/tests/kernel/h_segv.c,v 1.7 2018.05.30.17.48.13 kamil src/tests/lib/libc/sys/t_ptrace_wait.h,v 1.11 2018.05.30.18.02.40 maxv src/sys/netipsec/xform_ah.c,v 1.105 Log files can be found at: http://releng.NetBSD.org/b5reports/i386/commits-2018.05.html#2018.05.30.18.02.40
Re: ixg tester needed (was Re: Problems with netbsd-8 RC1 and ixg drivers (?))
Hi, all.
New patch:
---
Don't call ixgbe_rearm_queues() in ixgbe_local_timer1(). ixgbe_enable_queue()
and ixgbe_disable_queue() try to enable/disable queue interrupt safely. It
has the internal counter. When a queue's MSI-X is received, ixgbe_msix_que()
is called (IPL_NET). This function disable the queue's interrupt by
ixgbe_disable_queue() and issues an softint. ixgbe_handle() queue is called by
the softint (IPL_SOFTNET), process TX,RX and call ixgbe_enable_queue() at the
end.
ixgbe_local_timer1() is a callout and run always on CPU 0 (IPL_SOFTCLOCK).
When ixgbe_rearm_queues() called, an MSI-X interrupt is issued for a specific
queue. It may not CPU 0. If this interrupt's ixgbe_msix_que() is called
and sofint_schedule() is called before the last sofint's softint_execute()
is not called, the softint_schedule() fails because of SOFTINT_PENDING.
It result in breaking ixgbe_{enable,disable}_queue()'s internal counter.
ixgbe_local_timer1() is written not to call ixgbe_rearm_queues() if
the interrupt is disabled, but it's called because of unknown bug or a race.
One solution is to not to use the internal counter, but it's little difficult.
Another solution is stop using ixgbe_rearm_queues() at all. Essentially,
ixgbe_rearm_queues() is not required (it was added in ixgbe.c rev. 1.43
(2016/12/01)). ixgbe_rearm_queues() helps for lost interrupt problem but
I've never seen it other than ixgbe_rearm_queues() problem.
Index: ixgbe.c
===
RCS file: /cvsroot/src/sys/dev/pci/ixgbe/ixgbe.c,v
retrieving revision 1.158
diff -u -p -r1.158 ixgbe.c
--- ixgbe.c 30 May 2018 09:17:17 - 1.158
+++ ixgbe.c 31 May 2018 09:51:19 -
@@ -4411,6 +4411,7 @@ ixgbe_local_timer1(void *arg)
/* Only truely watchdog if all queues show hung */
if (hung == adapter->num_queues)
goto watchdog;
+#if 0 /* XXX Avoid unexpectedly disabling interrupt forever (PR#53294) */
else if (queues != 0) { /* Force an IRQ on queues with work */
que = adapter->queues;
for (i = 0; i < adapter->num_queues; i++, que++) {
@@ -4421,6 +4422,7 @@ ixgbe_local_timer1(void *arg)
mutex_exit(&que->dc_mtx);
}
}
+#endif
out:
callout_reset(&adapter->timer, hz, ixgbe_local_timer, adapter);
---
The same diff is at:
http://www.netbsd.org/~msaitoh/ixgbe-norearm-20180530-0.dif
--
---
SAITOH Masanobu (msai...@execsw.org
msai...@netbsd.org)
Re: NetBSD 8.0 RC1 and X
On Wed, May 30, 2018 at 04:52:46PM -0500, Robert Nestor wrote: > Trying to install NetBSD 8.0_RC1 on an HP 6200 system and ran into a problem > I?ve never seen before. > > Got the system installed with XDM, but X didn?t find all the possible screen > resolutions. I?m used to that, so I edited an xorg.conf file and that solved > the problem. I then tried installing netbsd-XEN3-DOM0 and the xen out of the > xen48 packages. The system comes up, again in a minimal X with XDM but again > without my custom xorg.conf file I get just low screen resolutions. With my > custom xorg.conf file I get colorful screen confetti. > > Digging a bit further I see that without Xen the X system is defaulting to > the intel driver for the on-board graphics, but when booting up with Xen it > defaults to the vesa driver. Yes, NetBSD/Xen can't use DRI-based drivers, because in our DRI implementation the physical to machine mapping of addresses isn't handled. Fixing this probably requires an extention of the bus_dma(9) API, and then fixing the DRI implementation to use bus_dma(9). I would expect VESA to work the same way in native of Xen, though. -- Manuel Bouyer NetBSD: 26 ans d'experience feront toujours la difference --
