daily CVS update output
Updating src tree: P src/distrib/sets/lists/comp/mi P src/external/cddl/osnet/dist/uts/common/fs/zfs/zfs_acl.c P src/share/man/man9/Makefile P src/share/man/man9/pool_cache.9 P src/sys/arch/arm/acpi/acpi_pci_machdep.c P src/sys/arch/arm/pic/pic.c P src/sys/arch/arm/sociox/if_scx.c P src/sys/arch/arm/sociox/sni_emmc.c P src/sys/arch/arm/sociox/sni_gpio.c P src/sys/arch/arm/sociox/sni_i2c.c P src/sys/arch/mips/adm5120/dev/ahci.c cvs update: `src/sys/arch/sandpoint/conf/ENCPP1' is no longer in the repository P src/sys/compat/netbsd32/netbsd32_ioctl.c P src/sys/compat/netbsd32/netbsd32_ioctl.h P src/sys/dev/scsipi/scsiconf.c P src/sys/dev/usb/ehci.c P src/sys/dev/usb/ohci.c P src/sys/dev/usb/uhci.c P src/sys/dev/usb/usb_mem.c P src/sys/dev/usb/usb_mem.h P src/sys/dev/usb/usbdi.c P src/sys/dev/usb/xhci.c P src/sys/external/bsd/common/include/linux/slab.h P src/sys/external/bsd/drm2/dist/drm/i915/i915_drv.c P src/sys/external/bsd/drm2/dist/drm/i915/i915_request.c P src/sys/external/bsd/drm2/dist/drm/i915/i915_scheduler.c P src/sys/external/bsd/drm2/dist/drm/i915/gem/i915_gem_shmem.c P src/sys/external/bsd/drm2/dist/include/drm/drm_device.h P src/sys/external/bsd/drm2/drm/files.drmkms P src/sys/external/bsd/drm2/i915drm/files.i915drmkms P src/sys/external/bsd/drm2/nouveau/files.nouveau P src/sys/external/bsd/drm2/radeon/files.radeon P src/sys/external/bsd/dwc2/dwc2.c P src/sys/external/bsd/dwc2/dist/dwc2_hcd.c P src/sys/external/bsd/dwc2/dist/dwc2_hcdddma.c P src/sys/external/bsd/dwc2/dist/dwc2_hcdqueue.c P src/sys/kern/kern_lwp.c P src/sys/kern/subr_pool.c P src/sys/net/pktqueue.c P src/sys/sys/param.h P src/sys/sys/pool.h P src/sys/uvm/uvm_pglist.c P src/tests/usr.bin/xlint/lint1/d_c99_bool_strict_syshdr.c U src/tests/usr.bin/xlint/lint1/d_c99_bool_strict_syshdr.exp P src/tests/usr.bin/xlint/lint1/d_c99_init.c P src/tests/usr.bin/xlint/lint1/d_c99_init.exp P src/tests/usr.bin/xlint/lint1/d_init_array_using_string.c P src/tests/usr.bin/xlint/lint1/d_init_array_using_string.exp P src/tests/usr.bin/xlint/lint1/init.c P src/tests/usr.bin/xlint/lint1/init.exp P src/tests/usr.bin/xlint/lint1/msg_171.c P src/tests/usr.bin/xlint/lint1/msg_179.c U src/tests/usr.bin/xlint/lint1/msg_179.exp P src/tests/usr.bin/xlint/lint1/msg_187.c U src/tests/usr.bin/xlint/lint1/msg_187.exp P src/usr.bin/xlint/lint1/Makefile P src/usr.bin/xlint/lint1/debug.c P src/usr.bin/xlint/lint1/err.c P src/usr.bin/xlint/lint1/externs1.h P src/usr.bin/xlint/lint1/init.c P src/usr.bin/xlint/lint1/mem1.c P src/usr.bin/xlint/lint1/tree.c P src/usr.sbin/makefs/cd9660.c Updating xsrc tree: Killing core files: Updating release-8 src tree (netbsd-8): Updating release-8 xsrc tree (netbsd-8): Updating release-9 src tree (netbsd-9): Updating release-9 xsrc tree (netbsd-9): Updating file list: -rw-rw-r-- 1 srcmastr netbsd 40484289 Dec 22 03:11 ls-lRA.gz
Re: ixg wierdness
On 2021/12/22 9:38, SAITOH Masanobu wrote: Hi. On 2021/12/21 19:53, Patrick Welche wrote: On a box with 4 bnx and 4 ixg interfaces, I just hit PR kern/53155 when trying to use bnx1. (Built LOCKDEBUG etc kernel, with serial console. Hang such that ~# doesn't drop into ddb) No problems running as an NFS server for a year or two just using bnx0. (I didn't try "up"ing bnx2) So I tried swapping to use ixg0 and ixg1 instead. I see a strange bursty pattern with what looks like a 1s count down, e.g.: 64 bytes from 10.0.0.236: icmp_seq=642 ttl=255 time=37004.721972 ms 64 bytes from 10.0.0.236: icmp_seq=643 ttl=255 time=36004.533428 ms 64 bytes from 10.0.0.236: icmp_seq=644 ttl=255 time=35004.224479 ms 64 bytes from 10.0.0.236: icmp_seq=645 ttl=255 time=34003.925027 ms 64 bytes from 10.0.0.236: icmp_seq=646 ttl=255 time=33003.615239 ms 64 bytes from 10.0.0.236: icmp_seq=647 ttl=255 time=32003.313832 ms 64 bytes from 10.0.0.236: icmp_seq=648 ttl=255 time=31003.008233 ms 64 bytes from 10.0.0.236: icmp_seq=649 ttl=255 time=30002.702356 ms 64 bytes from 10.0.0.236: icmp_seq=650 ttl=255 time=29002.396480 ms 64 bytes from 10.0.0.236: icmp_seq=651 ttl=255 time=28002.090882 ms 64 bytes from 10.0.0.236: icmp_seq=652 ttl=255 time=27001.772992 ms 64 bytes from 10.0.0.236: icmp_seq=653 ttl=255 time=26001.477731 ms 64 bytes from 10.0.0.236: icmp_seq=654 ttl=255 time=25001.291421 ms 64 bytes from 10.0.0.236: icmp_seq=655 ttl=255 time=24000.965150 ms 64 bytes from 10.0.0.236: icmp_seq=656 ttl=255 time=23000.622398 ms 64 bytes from 10.0.0.236: icmp_seq=657 ttl=255 time=22000.278807 ms 64 bytes from 10.0.0.236: icmp_seq=658 ttl=255 time=20999.931305 ms 64 bytes from 10.0.0.236: icmp_seq=659 ttl=255 time=1.592463 ms 64 bytes from 10.0.0.236: icmp_seq=660 ttl=255 time=19009.253137 ms 64 bytes from 10.0.0.236: icmp_seq=661 ttl=255 time=18008.910105 ms 64 bytes from 10.0.0.236: icmp_seq=662 ttl=255 time=17008.551987 ms 64 bytes from 10.0.0.236: icmp_seq=663 ttl=255 time=16008.224040 ms 64 bytes from 10.0.0.236: icmp_seq=664 ttl=255 time=15007.874862 ms 64 bytes from 10.0.0.236: icmp_seq=665 ttl=255 time=14007.533506 ms 64 bytes from 10.0.0.236: icmp_seq=666 ttl=255 time=13007.194943 ms 64 bytes from 10.0.0.236: icmp_seq=667 ttl=255 time=12006.852469 ms 64 bytes from 10.0.0.236: icmp_seq=668 ttl=255 time=11006.509437 ms 64 bytes from 10.0.0.236: icmp_seq=669 ttl=255 time=10006.193223 ms 64 bytes from 10.0.0.236: icmp_seq=670 ttl=255 time=9005.846559 ms 64 bytes from 10.0.0.236: icmp_seq=671 ttl=255 time=8005.508556 ms 64 bytes from 10.0.0.236: icmp_seq=672 ttl=255 time=7005.165803 ms 64 bytes from 10.0.0.236: icmp_seq=673 ttl=255 time=6004.818579 ms 64 bytes from 10.0.0.236: icmp_seq=674 ttl=255 time=5004.479458 ms 64 bytes from 10.0.0.236: icmp_seq=675 ttl=255 time=4004.132514 ms 64 bytes from 10.0.0.236: icmp_seq=676 ttl=255 time=3003.794232 ms 64 bytes from 10.0.0.236: icmp_seq=677 ttl=255 time=2003.431084 ms 64 bytes from 10.0.0.236: icmp_seq=678 ttl=255 time=1003.103697 ms 64 bytes from 10.0.0.236: icmp_seq=679 ttl=255 time=2.761223 ms 64 bytes from 10.0.0.236: icmp_seq=717 ttl=255 time=6373.442427 ms 64 bytes from 10.0.0.236: icmp_seq=718 ttl=255 time=5373.238237 ms 64 bytes from 10.0.0.236: icmp_seq=719 ttl=255 time=4372.937388 ms 64 bytes from 10.0.0.236: icmp_seq=720 ttl=255 time=3372.631791 ms 64 bytes from 10.0.0.236: icmp_seq=721 ttl=255 time=2372.325913 ms 64 bytes from 10.0.0.236: icmp_seq=722 ttl=255 time=1372.006627 ms 64 bytes from 10.0.0.236: icmp_seq=723 ttl=255 time=371.714159 ms ping: sendto: Host is down ping: sendto: Host is down ping: sendto: Host is down ping: sendto: Host is down ping: sendto: Host is down ... then eventually wakes up again when pinging to its ixg0 interface. You see the bursts while running tcpdump -ni ixg0. ixg0 at pci8 dev 0 function 0: Intel(R) PRO/10GbE PCI-Express Network Driver, Version - 4.0.1-k ixg0: device 82599EB ixg0: ETrackID 81a5 ixg0: autoconfiguration error: failed to allocate MSI-X interrupt ixg0: interrupting at ioapic1 pin 22 ixg0: Ethernet address 00:1b:21:9a:d4:84 ixg0: PHY: OUI 0x0014a6 model 0x0001, rev. 0 ixg0: PCI Express Bus: Speed 5.0GT/s Width x8 ixg0: feature cap 0x1780 ixg0: feature ena 0x1000 ixg0: flags=0x8843 mtu 1500 capabilities=0x7ff80 capabilities=0x7ff80 capabilities=0x7ff80 enabled=0 ec_capabilities=0xf ec_enabled=0x7 address: 00:1b:21:9a:d4:84 media: Ethernet autoselect (1000baseT full-duplex) status: active inet6 fe80::21b:21ff:fe9a:d484%ixg0/64 flags 0 scopeid 0x5 inet 10.0.0.236/24 broadcast 10.0.0.255 flags 0 This is with 15 December 2021 -current/amd64. Any ideas on what might be going on? Cheers, Patrick One of the possibility of the problem is the shortage of mbuf cluster. Could you show me the output of netstat -m? % netstat -m 9222 mbufs in use: 9217 mbufs allocated to data 3 mbufs allocated to packet
Re: ixg wierdness
Hi. On 2021/12/21 19:53, Patrick Welche wrote: On a box with 4 bnx and 4 ixg interfaces, I just hit PR kern/53155 when trying to use bnx1. (Built LOCKDEBUG etc kernel, with serial console. Hang such that ~# doesn't drop into ddb) No problems running as an NFS server for a year or two just using bnx0. (I didn't try "up"ing bnx2) So I tried swapping to use ixg0 and ixg1 instead. I see a strange bursty pattern with what looks like a 1s count down, e.g.: 64 bytes from 10.0.0.236: icmp_seq=642 ttl=255 time=37004.721972 ms 64 bytes from 10.0.0.236: icmp_seq=643 ttl=255 time=36004.533428 ms 64 bytes from 10.0.0.236: icmp_seq=644 ttl=255 time=35004.224479 ms 64 bytes from 10.0.0.236: icmp_seq=645 ttl=255 time=34003.925027 ms 64 bytes from 10.0.0.236: icmp_seq=646 ttl=255 time=33003.615239 ms 64 bytes from 10.0.0.236: icmp_seq=647 ttl=255 time=32003.313832 ms 64 bytes from 10.0.0.236: icmp_seq=648 ttl=255 time=31003.008233 ms 64 bytes from 10.0.0.236: icmp_seq=649 ttl=255 time=30002.702356 ms 64 bytes from 10.0.0.236: icmp_seq=650 ttl=255 time=29002.396480 ms 64 bytes from 10.0.0.236: icmp_seq=651 ttl=255 time=28002.090882 ms 64 bytes from 10.0.0.236: icmp_seq=652 ttl=255 time=27001.772992 ms 64 bytes from 10.0.0.236: icmp_seq=653 ttl=255 time=26001.477731 ms 64 bytes from 10.0.0.236: icmp_seq=654 ttl=255 time=25001.291421 ms 64 bytes from 10.0.0.236: icmp_seq=655 ttl=255 time=24000.965150 ms 64 bytes from 10.0.0.236: icmp_seq=656 ttl=255 time=23000.622398 ms 64 bytes from 10.0.0.236: icmp_seq=657 ttl=255 time=22000.278807 ms 64 bytes from 10.0.0.236: icmp_seq=658 ttl=255 time=20999.931305 ms 64 bytes from 10.0.0.236: icmp_seq=659 ttl=255 time=1.592463 ms 64 bytes from 10.0.0.236: icmp_seq=660 ttl=255 time=19009.253137 ms 64 bytes from 10.0.0.236: icmp_seq=661 ttl=255 time=18008.910105 ms 64 bytes from 10.0.0.236: icmp_seq=662 ttl=255 time=17008.551987 ms 64 bytes from 10.0.0.236: icmp_seq=663 ttl=255 time=16008.224040 ms 64 bytes from 10.0.0.236: icmp_seq=664 ttl=255 time=15007.874862 ms 64 bytes from 10.0.0.236: icmp_seq=665 ttl=255 time=14007.533506 ms 64 bytes from 10.0.0.236: icmp_seq=666 ttl=255 time=13007.194943 ms 64 bytes from 10.0.0.236: icmp_seq=667 ttl=255 time=12006.852469 ms 64 bytes from 10.0.0.236: icmp_seq=668 ttl=255 time=11006.509437 ms 64 bytes from 10.0.0.236: icmp_seq=669 ttl=255 time=10006.193223 ms 64 bytes from 10.0.0.236: icmp_seq=670 ttl=255 time=9005.846559 ms 64 bytes from 10.0.0.236: icmp_seq=671 ttl=255 time=8005.508556 ms 64 bytes from 10.0.0.236: icmp_seq=672 ttl=255 time=7005.165803 ms 64 bytes from 10.0.0.236: icmp_seq=673 ttl=255 time=6004.818579 ms 64 bytes from 10.0.0.236: icmp_seq=674 ttl=255 time=5004.479458 ms 64 bytes from 10.0.0.236: icmp_seq=675 ttl=255 time=4004.132514 ms 64 bytes from 10.0.0.236: icmp_seq=676 ttl=255 time=3003.794232 ms 64 bytes from 10.0.0.236: icmp_seq=677 ttl=255 time=2003.431084 ms 64 bytes from 10.0.0.236: icmp_seq=678 ttl=255 time=1003.103697 ms 64 bytes from 10.0.0.236: icmp_seq=679 ttl=255 time=2.761223 ms 64 bytes from 10.0.0.236: icmp_seq=717 ttl=255 time=6373.442427 ms 64 bytes from 10.0.0.236: icmp_seq=718 ttl=255 time=5373.238237 ms 64 bytes from 10.0.0.236: icmp_seq=719 ttl=255 time=4372.937388 ms 64 bytes from 10.0.0.236: icmp_seq=720 ttl=255 time=3372.631791 ms 64 bytes from 10.0.0.236: icmp_seq=721 ttl=255 time=2372.325913 ms 64 bytes from 10.0.0.236: icmp_seq=722 ttl=255 time=1372.006627 ms 64 bytes from 10.0.0.236: icmp_seq=723 ttl=255 time=371.714159 ms ping: sendto: Host is down ping: sendto: Host is down ping: sendto: Host is down ping: sendto: Host is down ping: sendto: Host is down ... then eventually wakes up again when pinging to its ixg0 interface. You see the bursts while running tcpdump -ni ixg0. ixg0 at pci8 dev 0 function 0: Intel(R) PRO/10GbE PCI-Express Network Driver, Version - 4.0.1-k ixg0: device 82599EB ixg0: ETrackID 81a5 ixg0: autoconfiguration error: failed to allocate MSI-X interrupt ixg0: interrupting at ioapic1 pin 22 ixg0: Ethernet address 00:1b:21:9a:d4:84 ixg0: PHY: OUI 0x0014a6 model 0x0001, rev. 0 ixg0: PCI Express Bus: Speed 5.0GT/s Width x8 ixg0: feature cap 0x1780 ixg0: feature ena 0x1000 ixg0: flags=0x8843 mtu 1500 capabilities=0x7ff80 capabilities=0x7ff80 capabilities=0x7ff80 enabled=0 ec_capabilities=0xf ec_enabled=0x7 address: 00:1b:21:9a:d4:84 media: Ethernet autoselect (1000baseT full-duplex) status: active inet6 fe80::21b:21ff:fe9a:d484%ixg0/64 flags 0 scopeid 0x5 inet 10.0.0.236/24 broadcast 10.0.0.255 flags 0 This is with 15 December 2021 -current/amd64. Any ideas on what might be going on? Cheers, Patrick One of the possibility of the problem is the shortage of mbuf cluster. Could you show me the output of netstat -m? % netstat -m 9222 mbufs in use: 9217 mbufs allocated to data 3 mbufs allocated to packet headers 2 mbufs allocated to socket
Re: XEN devices included in kernel even if not XEN
On Tue, 21 Dec 2021, Brad Spencer wrote: Manuel Bouyer writes: On Tue, Dec 21, 2021 at 07:44:59AM -0800, Paul Goyette wrote: I've noticed that device drivers listed in arch/xen/conf/files.xen (or, at least, most of those devices) seem to be included in kernel even if not using XEN. Shouldn't all those devices be conditional? # sysctl -a | grep driver | tr ',' '\n' | grep 'x[be]*' ... [141 -1 xenevt] [142 142 xbd] [143 -1 xencons] I think this lists all the known major numbers for the $MACHINE, I don't think it means that the driver is actually loaded. ... and a PVHVM guest can use the GENERIC kernel, but will want the Xen devices too. Thanks to all for the info. Manuel is correct - I actually checked the build object directory and there are no *.o files related to the xen devices. ++--+--+ | Paul Goyette | PGP Key fingerprint: | E-mail addresses:| | (Retired) | FA29 0E3B 35AF E8AE 6651 | p...@whooppee.com| | Software Developer | 0786 F758 55DE 53BA 7731 | pgoye...@netbsd.org | | & Network Engineer | | pgoyett...@gmail.com | ++--+--+
Re: XEN devices included in kernel even if not XEN
Manuel Bouyer writes: > On Tue, Dec 21, 2021 at 07:44:59AM -0800, Paul Goyette wrote: >> I've noticed that device drivers listed in arch/xen/conf/files.xen >> (or, at least, most of those devices) seem to be included in kernel >> even if not using XEN. Shouldn't all those devices be conditional? >> >> # sysctl -a | grep driver | tr ',' '\n' | grep 'x[be]*' >> ... >> [141 -1 xenevt] >> [142 142 xbd] >> [143 -1 xencons] > > I think this lists all the known major numbers for the $MACHINE, I don't think > it means that the driver is actually loaded. ... and a PVHVM guest can use the GENERIC kernel, but will want the Xen devices too. -- Brad Spencer - b...@anduin.eldar.org - KC8VKS - http://anduin.eldar.org
Re: XEN devices included in kernel even if not XEN
On Tue, Dec 21, 2021 at 07:44:59AM -0800, Paul Goyette wrote: > I've noticed that device drivers listed in arch/xen/conf/files.xen > (or, at least, most of those devices) seem to be included in kernel > even if not using XEN. Shouldn't all those devices be conditional? > > # sysctl -a | grep driver | tr ',' '\n' | grep 'x[be]*' > ... > [141 -1 xenevt] > [142 142 xbd] > [143 -1 xencons] I think this lists all the known major numbers for the $MACHINE, I don't think it means that the driver is actually loaded. -- Manuel Bouyer NetBSD: 26 ans d'experience feront toujours la difference --
Re: HEADS UP: Merging drm update
Hi,
Taylor R Campbell writes:
>> Date: Tue, 21 Dec 2021 22:47:34 +0900
>> From: Ryo ONODERA
>>
>> I think that "Cannot find any crtc or sizes" may be related to
>> "Failed to find VBIOS tables (VBT)".
>> I have added some printf lines to some functions invoked before
>> intel_bios_init in
>> sys/external/bsd/drm2/dist/drm/i915/display/intel_bios.c .
>>
>> And bus_space_map (line 956)
>> in intel_opregion_setup in
>> sys/external/bsd/drm2/dist/drm/i915/display/intel_opregion.c
>> failed and return value 35.
>
> Can you do the following diagnostics?
>
> 1. Print what the bus address is when bus_space_map fails here; call
>it BADADDR.
>
> 2. Add a fragment to bus_space_reserve in x86/bus_space.c:
>
>#include
>
> if (bpa <= BADADDR && BADADDR < bpa + size)
> db_stacktrace();
>
> Then share the dmesg output on boot with this change to
> bus_space_reserve?
>
> This way we can track down who's reserving the registers that
> intel_opregion.c wants.
Thanks for your suggestion.
I have applied the following patch.
I cannot get dmesg easily and I have added panic() to stop vertical scroll.
Index: sys/arch/x86/x86/bus_space.c
===
RCS file: /cvsroot/src/sys/arch/x86/x86/bus_space.c,v
retrieving revision 1.46
diff -u -r1.46 bus_space.c
--- sys/arch/x86/x86/bus_space.c7 Oct 2021 12:52:27 - 1.46
+++ sys/arch/x86/x86/bus_space.c21 Dec 2021 15:41:49 -
@@ -51,6 +51,8 @@
#include
#endif
+#include
+
/*
* Macros for sanity-checking the aligned-ness of pointers passed to
* bus space ops. These are not strictly necessary on the x86, but
@@ -251,6 +253,11 @@
bus_size_t size,
int flags, bus_space_reservation_t *bsrp)
{
+ if (bpa <= 0x63ec5018 && 0x63ec5018 < bpa + size) {
+ db_stacktrace();
+ panic("BADADDR");
+ }
+
struct extent *ex;
int error;
bus_space_tag_t it;
Index: sys/external/bsd/drm2/dist/drm/i915/display/intel_opregion.c
===
RCS file:
/cvsroot/src/sys/external/bsd/drm2/dist/drm/i915/display/intel_opregion.c,v
retrieving revision 1.4
diff -u -r1.4 intel_opregion.c
--- sys/external/bsd/drm2/dist/drm/i915/display/intel_opregion.c19 Dec
2021 11:49:11 - 1.4
+++ sys/external/bsd/drm2/dist/drm/i915/display/intel_opregion.c21 Dec
2021 15:41:49 -
@@ -943,6 +943,7 @@
BUILD_BUG_ON(sizeof(struct opregion_asle_ext) != 0x400);
pci_read_config_dword(pdev, ASLS, );
+ printf("graphic opregion physical addr: 0x%x\n", asls);
DRM_DEBUG_DRIVER("graphic opregion physical addr: 0x%x\n", asls);
if (asls == 0) {
DRM_DEBUG_DRIVER("ACPI OpRegion not supported!\n");
My result is very strange. No one except i195drmkms itself
requests asls=0x63ec5018 address.
My patch has panic() and if someone requests the address,
boot process will stop immediately.
Here is the last part of dmesg manually transcribed from photo.
(snip)
i915drmkms0 at pci0 dev 2 function 0: Intel product 8a52 (rev. 0x03)
(snip)
boot device: ld0
root file system type: ffs
kern.module.path=/stand/amd64/9.99.92/modules
graphics opregion physical addr: 0x63ec5018
bus_space_map() at netbsd:bus_space_map+0x43
intel_opregion_setup() at netbsd:intel_opregion_setup+0xa3
i915_driver_probe() at netbsd:i915_driver_probe+0x64f
i915drmkms_attach_real() at netbsd:i915drmkms_attach_real+0x40
config_mountroot_thread() at netbsd:config_mountroot_thread+0x37
panic: BADADDR
cpu0: Begin traceback...
vpanic() netbsd:vpanic+0x156
panic() at netbsd:panic+0x3c
bus_space_reserve() at netbsd:bus_space_reserve+0x104
bus_space_map() at netbsd:bus_space_map+0x43
intel_opregion_setuo() at netbsd:intel_opregion_setup+0xa3
i915_driver_probe() at netbsd:i915_driver_probe+0x64f
i915drmkms_attach_real() at netbsd:i915drmkms_attach_real+0x40
config_mountroot_thread() at netbsd:config_mountroot_thread+0x37
cpu0: End traceback...
fatal breakpoint trap insupervisor mode
trap type 1 code 0 rip 0x80221995 cs 0x8 rflags 0x202 cdr 0 ilevel 0
rsp 0xdd014aa69d40
curlwp 0xc279f4c75900 pid 0.384 lowest kstack 0xdd014aa652c0
Stopped in pid 0.384 (system) at netbsd:breakpoiny+0x5: leave
(snip)
I do not understand my situation yet...
--
Ryo ONODERA // r...@tetera.org
PGP fingerprint = 82A2 DC91 76E0 A10A 8ABB FD1B F404 27FA C7D1 15F3
XEN devices included in kernel even if not XEN
I've noticed that device drivers listed in arch/xen/conf/files.xen
(or, at least, most of those devices) seem to be included in kernel
even if not using XEN. Shouldn't all those devices be conditional?
# sysctl -a | grep driver | tr ',' '\n' | grep 'x[be]*'
...
[141 -1 xenevt]
[142 142 xbd]
[143 -1 xencons]
# tail $OBJDIR/amd64/sys/arch/amd64/compile/SPEEDY/opt_xen.h
#endif
/* option `XEN' not defined */ <<
#ifdef _LOCORE
.ifndef _KERNEL_OPT_XEN
.global _KERNEL_OPT_XEN
.equiv _KERNEL_OPT_XEN,0x6e074def
.endif
#else
__asm(" .ifndef _KERNEL_OPT_XEN\n .global _KERNEL_OPT_XEN\n .equiv
_KERNEL_OPT_XEN,0x6e074def\n .endif");
#endif
++--+--+
| Paul Goyette | PGP Key fingerprint: | E-mail addresses:|
| (Retired) | FA29 0E3B 35AF E8AE 6651 | p...@whooppee.com|
| Software Developer | 0786 F758 55DE 53BA 7731 | pgoye...@netbsd.org |
| & Network Engineer | | pgoyett...@gmail.com |
++--+--+
Re: HEADS UP: Merging drm update
> Date: Tue, 21 Dec 2021 22:47:34 +0900 > From: Ryo ONODERA > > I think that "Cannot find any crtc or sizes" may be related to > "Failed to find VBIOS tables (VBT)". > I have added some printf lines to some functions invoked before > intel_bios_init in > sys/external/bsd/drm2/dist/drm/i915/display/intel_bios.c . > > And bus_space_map (line 956) > in intel_opregion_setup in > sys/external/bsd/drm2/dist/drm/i915/display/intel_opregion.c > failed and return value 35. Can you do the following diagnostics? 1. Print what the bus address is when bus_space_map fails here; call it BADADDR. 2. Add a fragment to bus_space_reserve in x86/bus_space.c: #include if (bpa <= BADADDR && BADADDR < bpa + size) db_stacktrace(); Then share the dmesg output on boot with this change to bus_space_reserve? This way we can track down who's reserving the registers that intel_opregion.c wants.
Re: HEADS UP: Merging drm update
Hi,
Martin Husemann writes:
> On Tue, Dec 21, 2021 at 01:50:05AM +0900, Ryo ONODERA wrote:
>> (snip)
>> boot device: ld0
>> root on dk1 dumps on dk2
>> root file system type: ffs
>> kern.module.path=/stand/amd64/9.99.92/modules
>> kern info: [drm] Support vblank timestamp caching Rev 2 (21.10.2013).
>> kern info: [drm] Driver supports precise vblank timestamp query.
>> kern info: [drm] Failed to find VBIOS tables (VBT)
>> i915drmkms0: interrupting at msi5 vec 0 (i915drmkms0)
>> i915drmkms0: notice: Failed to load DMC firmware i915/icl_dmc_ver1_09.bin.
>> Disabling runtime power management.
>> (screen turns black)
>
> I get the same on a machine with "real" serial console- it comes up fine,
> but nothing in wscons land works:
>
> scsibus0 at umass0: 2 targets, 1 lun per target
> sd0 at scsibus0 target 0 lun 0: disk removable
> sd0: drive offline
> WARNING: 3 errors while detecting hardware; check system log.
> boot device: wd1
> root on wd1e dumps on wd1b
> root file system type: ffs
> kern.module.path=/stand/amd64/9.99.92/modules
> kern info: [drm] Supports vblank timestamp caching Rev 2 (21.10.2013).
> kern info: [drm] Driver supports precise vblank timestamp query.
> kern info: [drm] Failed to find VBIOS tables (VBT)
> allocated pic msi7 type edge pin 0 level 6 to cpu1 slot 2 idt entry 98
> i915drmkms0: interrupting at msi7 vec 0 (i915drmkms0)
> i915drmkms0: notice: Failed to load DMC firmware i915/skl_dmc_ver1_27.bin.
> Disa$
> i915drmkms0: notice: DMC firmware homepage:
> https://git.kernel.org/pub/scm/linu$
> kern info: [drm] Initialized i915 1.6.0 20200114 for i915drmkms0 on minor 0
> i915drmkms0: info: [drm] Cannot find any crtc or sizes
> kern info: [drm] DRM_I915_DEBUG enabled
> kern info: [drm] DRM_I915_DEBUG_GEM enabled
> i915drmkms0: info: [drm] Cannot find any crtc or sizes
Thanks for your information.
I think that "Cannot find any crtc or sizes" may be related to
"Failed to find VBIOS tables (VBT)".
I have added some printf lines to some functions invoked before
intel_bios_init in
sys/external/bsd/drm2/dist/drm/i915/display/intel_bios.c .
And bus_space_map (line 956)
in intel_opregion_setup in
sys/external/bsd/drm2/dist/drm/i915/display/intel_opregion.c
failed and return value 35.
954 #ifdef __NetBSD__
955 opregion->bst = pdev->pd_pa.pa_memt;
956 err = -bus_space_map(opregion->bst, asls, OPREGION_SIZE,
957 BUS_SPACE_MAP_LINEAR|BUS_SPACE_MAP_CACHEABLE,
958 >asls_bsh);
959 if (err) {
960 DRM_DEBUG_DRIVER("Failed to map opregion: %d\n", err);
961 return err;
962 }
963 base = bus_space_vaddr(opregion->bst, opregion->asls_bsh);
964 #else
> Martin
--
Ryo ONODERA // r...@tetera.org
PGP fingerprint = 82A2 DC91 76E0 A10A 8ABB FD1B F404 27FA C7D1 15F3
ixg wierdness
On a box with 4 bnx and 4 ixg interfaces, I just hit PR kern/53155 when trying to use bnx1. (Built LOCKDEBUG etc kernel, with serial console. Hang such that ~# doesn't drop into ddb) No problems running as an NFS server for a year or two just using bnx0. (I didn't try "up"ing bnx2) So I tried swapping to use ixg0 and ixg1 instead. I see a strange bursty pattern with what looks like a 1s count down, e.g.: 64 bytes from 10.0.0.236: icmp_seq=642 ttl=255 time=37004.721972 ms 64 bytes from 10.0.0.236: icmp_seq=643 ttl=255 time=36004.533428 ms 64 bytes from 10.0.0.236: icmp_seq=644 ttl=255 time=35004.224479 ms 64 bytes from 10.0.0.236: icmp_seq=645 ttl=255 time=34003.925027 ms 64 bytes from 10.0.0.236: icmp_seq=646 ttl=255 time=33003.615239 ms 64 bytes from 10.0.0.236: icmp_seq=647 ttl=255 time=32003.313832 ms 64 bytes from 10.0.0.236: icmp_seq=648 ttl=255 time=31003.008233 ms 64 bytes from 10.0.0.236: icmp_seq=649 ttl=255 time=30002.702356 ms 64 bytes from 10.0.0.236: icmp_seq=650 ttl=255 time=29002.396480 ms 64 bytes from 10.0.0.236: icmp_seq=651 ttl=255 time=28002.090882 ms 64 bytes from 10.0.0.236: icmp_seq=652 ttl=255 time=27001.772992 ms 64 bytes from 10.0.0.236: icmp_seq=653 ttl=255 time=26001.477731 ms 64 bytes from 10.0.0.236: icmp_seq=654 ttl=255 time=25001.291421 ms 64 bytes from 10.0.0.236: icmp_seq=655 ttl=255 time=24000.965150 ms 64 bytes from 10.0.0.236: icmp_seq=656 ttl=255 time=23000.622398 ms 64 bytes from 10.0.0.236: icmp_seq=657 ttl=255 time=22000.278807 ms 64 bytes from 10.0.0.236: icmp_seq=658 ttl=255 time=20999.931305 ms 64 bytes from 10.0.0.236: icmp_seq=659 ttl=255 time=1.592463 ms 64 bytes from 10.0.0.236: icmp_seq=660 ttl=255 time=19009.253137 ms 64 bytes from 10.0.0.236: icmp_seq=661 ttl=255 time=18008.910105 ms 64 bytes from 10.0.0.236: icmp_seq=662 ttl=255 time=17008.551987 ms 64 bytes from 10.0.0.236: icmp_seq=663 ttl=255 time=16008.224040 ms 64 bytes from 10.0.0.236: icmp_seq=664 ttl=255 time=15007.874862 ms 64 bytes from 10.0.0.236: icmp_seq=665 ttl=255 time=14007.533506 ms 64 bytes from 10.0.0.236: icmp_seq=666 ttl=255 time=13007.194943 ms 64 bytes from 10.0.0.236: icmp_seq=667 ttl=255 time=12006.852469 ms 64 bytes from 10.0.0.236: icmp_seq=668 ttl=255 time=11006.509437 ms 64 bytes from 10.0.0.236: icmp_seq=669 ttl=255 time=10006.193223 ms 64 bytes from 10.0.0.236: icmp_seq=670 ttl=255 time=9005.846559 ms 64 bytes from 10.0.0.236: icmp_seq=671 ttl=255 time=8005.508556 ms 64 bytes from 10.0.0.236: icmp_seq=672 ttl=255 time=7005.165803 ms 64 bytes from 10.0.0.236: icmp_seq=673 ttl=255 time=6004.818579 ms 64 bytes from 10.0.0.236: icmp_seq=674 ttl=255 time=5004.479458 ms 64 bytes from 10.0.0.236: icmp_seq=675 ttl=255 time=4004.132514 ms 64 bytes from 10.0.0.236: icmp_seq=676 ttl=255 time=3003.794232 ms 64 bytes from 10.0.0.236: icmp_seq=677 ttl=255 time=2003.431084 ms 64 bytes from 10.0.0.236: icmp_seq=678 ttl=255 time=1003.103697 ms 64 bytes from 10.0.0.236: icmp_seq=679 ttl=255 time=2.761223 ms 64 bytes from 10.0.0.236: icmp_seq=717 ttl=255 time=6373.442427 ms 64 bytes from 10.0.0.236: icmp_seq=718 ttl=255 time=5373.238237 ms 64 bytes from 10.0.0.236: icmp_seq=719 ttl=255 time=4372.937388 ms 64 bytes from 10.0.0.236: icmp_seq=720 ttl=255 time=3372.631791 ms 64 bytes from 10.0.0.236: icmp_seq=721 ttl=255 time=2372.325913 ms 64 bytes from 10.0.0.236: icmp_seq=722 ttl=255 time=1372.006627 ms 64 bytes from 10.0.0.236: icmp_seq=723 ttl=255 time=371.714159 ms ping: sendto: Host is down ping: sendto: Host is down ping: sendto: Host is down ping: sendto: Host is down ping: sendto: Host is down ... then eventually wakes up again when pinging to its ixg0 interface. You see the bursts while running tcpdump -ni ixg0. ixg0 at pci8 dev 0 function 0: Intel(R) PRO/10GbE PCI-Express Network Driver, Version - 4.0.1-k ixg0: device 82599EB ixg0: ETrackID 81a5 ixg0: autoconfiguration error: failed to allocate MSI-X interrupt ixg0: interrupting at ioapic1 pin 22 ixg0: Ethernet address 00:1b:21:9a:d4:84 ixg0: PHY: OUI 0x0014a6 model 0x0001, rev. 0 ixg0: PCI Express Bus: Speed 5.0GT/s Width x8 ixg0: feature cap 0x1780 ixg0: feature ena 0x1000 ixg0: flags=0x8843 mtu 1500 capabilities=0x7ff80 capabilities=0x7ff80 capabilities=0x7ff80 enabled=0 ec_capabilities=0xf ec_enabled=0x7 address: 00:1b:21:9a:d4:84 media: Ethernet autoselect (1000baseT full-duplex) status: active inet6 fe80::21b:21ff:fe9a:d484%ixg0/64 flags 0 scopeid 0x5 inet 10.0.0.236/24 broadcast 10.0.0.255 flags 0 This is with 15 December 2021 -current/amd64. Any ideas on what might be going on? Cheers, Patrick
