Re: adding support for a possibly unsupported M.2 harddrive?
I forgot to send a follow-up to this: despite the disk itself not having a "proper" identifier in dmesg, I was able to get it to work without major issues while doing some other maintenancen work. Thanks for the advice and input everyone.
adding support for a possibly unsupported M.2 harddrive?
Hi folx, I have an M.2 SSD for which I have to assume no support exists so far in NetBSD 9.99.17. This is an "TREKSTOR M.2 SSD-Modul 64 GB" bought in 2018. Its dmesg: [ 3.739718] wd1 at atabus1 drive 0 [ 3.739718] wd1: <> [ 3.739718] wd1: drive supports 1-sector PIO transfers, LBA48 addressing [ 3.739718] wd1: 61057 MB, 124053 cyl, 16 head, 63 sec, 512 bytes/sect x 125045424 sectors [ 3.739718] wd1: drive supports PIO mode 4, DMA mode 2, Ultra-DMA mode 6 (Ultra/133), WRITE DMA FUA, NCQ (32 tags) [ 3.739718] wd1(ahcisata0:1:0): using PIO mode 4, DMA mode 2, Ultra-DMA mode 6 (Ultra/133) (using DMA), NCQ (31 tags) With fdisk I can see an earlier partition I created on another system, but making any changes to partitioning etc pp operations on disk fail (I can reproduce the information how it fails). Two question paths: 1. How would I go about (no prior device driver writing experience) adding this to NetBSD? or 2. Who / which list would I talk to and which details are necessary (so far I know fdisk and dmesg provide good details) to help with adding this to NetBSD? Cheers, ng0
fc-cache fails to build
Hi,
last night I ran into this with my NetBSD amd64 clang system while
building it. Has someone looked into this already? I did not find
a matching bug report with just "fc-cache". If not, I would report
it.
# link fc-cache/fc-cache
cc -O -DFONTCONFIG_PATH='"/usr/src/../obj/destdir.amd64/etc/X11/fonts"'
-DFC_DEFAULT_FONTS='"/usr/X11R7/lib/X11/fonts/Type1"'
-DFC_TEMPLATEDIR='"/usr/src/../obj/destdir.amd64/usr/X11R7/lib/X11/fonts"'
-DFC_CACHEDIR='"/usr/src/../obj/destdir.amd64/var/cache/fontconfig"'
-DFC_GPERF_SIZE_T=unsigned -DFC_NO_MT=1 -DALIGNOF_VOID_P=8
-DHAVE_FT_BITMAP_SIZE_Y_PPEM -DHAVE_FT_GET_BDF_PROPERTY
-DHAVE_FT_GET_NEXT_CHAR -DHAVE_FT_GET_PS_FONT_INFO
-DHAVE_FT_GET_X11_FONT_FORMAT -DHAVE_FT_HAS_PS_GLYPH_NAMES -DHAVE_EXPAT
-DXFREE86_FT2 -DHAVE_INTTYPES_H -DFT2_BUILD_LIBRARY -DXML_BYTE_ORDER=0
-DHAVE_MEMMOVE=1 -DHAVE_STDINT_H -DHAVE_RANDOM -DDARWIN_NO_CARBON
-DHAVE_SYS_TYPES_H -DHAVE_FCNTL_H -DHAVE_SYS_STAT_H -DHAVE_MKSTEMP
-DHAVE_SCANDIR -DFLEXIBLE_ARRAY_MEMBER="/**/" -DFT_CONFIG_OPTION_DISABLE_BZIP2
-I/usr/src/../xsrc/external/mit/fontconfig/dist
-I/usr/src/../xsrc/external/mit/freetype/dist
-I/usr/src/../xsrc/external/mit/freetype/dist/include
-I/usr/src/../xsrc/external/mit/freetype/dist/include/freetype
-I/usr/src/external/mit/expat/dist/lib
-I/usr/src/../xsrc/external/mit/fontconfig/dist/../include
-I/usr/src/../obj/destdir.amd64/usr/X11R7/include -I.
-I/usr/src/../xsrc/external/mit/fontconfig/dist/../include -DTOOL_FCCACHE -o
fc-cache fc-cache.lo fcatomic.lo fccache.lo fccfg.lo fccharset.lo fcdbg.lo
fccompat.lo fcdefault.lo fcdir.lo fcfreetype.lo fcfs.lo fchash.lo fcinit.lo
fclang.lo fclist.lo fcmatch.lo fcmatrix.lo fcname.lo fcobjs.lo fcpat.lo
fcptrlist.lo fcrange.lo fcserialize.lo fcstat.lo fcstr.lo fcweight.lo fcxml.lo
ftglue.lo ftapi.lo ftbase.lo ftbbox.lo ftbdf.lo ftdebug.lo ftglyph.lo ftinit.lo
ftmm.lo ftpfr.lo ftstroke.lo ftsynth.lo ftsystem.lo fttype1.lo ftwinfnt.lo
ftbitmap.lo autofit.lo bdf.lo cff.lo type1cid.lo ftgzip.lo ftlzw.lo pcf.lo
pfr.lo psaux.lo pshinter.lo psnames.lo raster.lo sfnt.lo smooth.lo truetype.lo
type1.lo type42.lo winfnt.lo xmlparse.lo xmltok.lo xmlrole.lo -lz
cc: error: ftapi.lo: No such file or directory
*** Failed target: fc-cache
*** Failed command: cc -O
-DFONTCONFIG_PATH='"/usr/src/../obj/destdir.amd64/etc/X11/fonts"'
-DFC_DEFAULT_FONTS='"/usr/X11R7/lib/X11/fonts/Type1"'
-DFC_TEMPLATEDIR='"/usr/src/../obj/destdir.amd64/usr/X11R7/lib/X11/fonts"'
-DFC_CACHEDIR='"/usr/src/../obj/destdir.amd64/var/cache/fontconfig"'
-DFC_GPERF_SIZE_T=unsigned -DFC_NO_MT=1 -DALIGNOF_VOID_P=8
-DHAVE_FT_BITMAP_SIZE_Y_PPEM -DHAVE_FT_GET_BDF_PROPERTY -DHAVE_FT_GET_NEXT_CHAR
-DHAVE_FT_GET_PS_FONT_INFO -DHAVE_FT_GET_X11_FONT_FORMAT
-DHAVE_FT_HAS_PS_GLYPH_NAMES -DHAVE_EXPAT -DXFREE86_FT2 -DHAVE_INTTYPES_H
-DFT2_BUILD_LIBRARY -DXML_BYTE_ORDER=0 -DHAVE_MEMMOVE=1 -DHAVE_STDINT_H
-DHAVE_RANDOM -DDARWIN_NO_CARBON -DHAVE_SYS_TYPES_H -DHAVE_FCNTL_H
-DHAVE_SYS_STAT_H -DHAVE_MKSTEMP -DHAVE_SCANDIR -DFLEXIBLE_ARRAY_MEMBER="/**/"
-DFT_CONFIG_OPTION_DISABLE_BZIP2
-I/usr/src/../xsrc/external/mit/fontconfig/dist
-I/usr/src/../xsrc/external/mit/freetype/dist
-I/usr/src/../xsrc/external/mit/freetype/dist/include
-I/usr/src/../xsrc/external/mit/freetype/dist/include/freetype
-I/usr/src/external/mit/expat/dist/lib
-I/usr/src/../xsrc/external/mit/fontconfig/dist/../include
-I/usr/src/../obj/destdir.amd64/usr/X11R7/include -I.
-I/usr/src/../xsrc/external/mit/fontconfig/dist/../include -DTOOL_FCCACHE -o
fc-cache fc-cache.lo fcatomic.lo fccache.lo fccfg.lo fccharset.lo fcdbg.lo
fccompat.lo fcdefault.lo fcdir.lo fcfreetype.lo fcfs.lo fchash.lo fcinit.lo
fclang.lo fclist.lo fcmatch.lo fcmatrix.lo fcname.lo fcobjs.lo fcpat.lo
fcptrlist.lo fcrange.lo fcserialize.lo fcstat.lo fcstr.lo fcweight.lo fcxml.lo
ftglue.lo ftapi.lo ftbase.lo ftbbox.lo ftbdf.lo ftdebug.lo ftglyph.lo ftinit.lo
ftmm.lo ftpfr.lo ftstroke.lo ftsynth.lo ftsystem.lo fttype1.lo ftwinfnt.lo
ftbitmap.lo autofit.lo bdf.lo cff.lo type1cid.lo ftgzip.lo ftlzw.lo pcf.lo
pfr.lo psaux.lo pshinter.lo psnames.lo raster.lo sfnt.lo smooth.lo truetype.lo
type1.lo type42.lo winfnt.lo xmlparse.lo xmltok.lo xmlrole.lo -lz
*** Error code 1
Stop.
nbmake[4]: stopped in /usr/src/external/mit/xorg/tools/fc-cache
*** Failed target: all-fc-cache
*** Failed command: _makedirtarget() { dir="$1"; shift; target="$1"; shift;
case "${dir}" in /*) this="${dir}/"; real="${dir}" ;; .)
this="external/mit/xorg/tools/"; real="/usr/src/external/mit/xorg/tools" ;; *)
this="external/mit/xorg/tools/${dir}/";
real="/usr/src/external/mit/xorg/tools/${dir}" ;; esac; show=${this:-.}; echo
"${target} ===> ${show%/}${1:+ (with: $@)}"; cd "${real}" &&
/usr/src/../tools/bin/nbmake _THISDIR_="${this}" "$@" ${target}; };
_makedirtarget fc-cache all
*** Error code 1
Stop.
nbmake[3]: stopped in /usr/src/external/mit/xorg/tools
*** Failed target: do-x11
*** Failed command: _makedirtarget() {
Re: usr.sbin/sysinst compile error
Martin Husemann transcribed 384 bytes: > On Wed, Jun 26, 2019 at 09:30:41AM +, n...@n0.is wrote: > > Okay, and how would I proceed without the build.sh running clean in obj > > first then? > > I've reads bits of build.sh but I am not sure if it was obvious to find. > > It does not do a clean in obj/tools alwasys, which might be what causes > the issue. > > So please just rm those dirs and run the same build.sh again. > > Thanks! Okay, thanks. I'll report back in tomorrow. > Martin
Re: usr.sbin/sysinst compile error
Martin Husemann transcribed 536 bytes: > On Wed, Jun 26, 2019 at 09:11:46AM +, n...@n0.is wrote: > > This is with ./build.sh ... -U distribution > > with the host system being on 8.99.42, built with clang, > > and this being relevant parts of mk.conf: > > Is there a "-u" in the "..." part of the build.sh invocation? The full invocation is "default", so: ./build.sh -X ../xsrc -T ../tools -O ../obj -U distribution > Can you try to remove the tolls/msgc and tools/menuc directories > in your object dir? Okay, and how would I proceed without the build.sh running clean in obj first then? I've reads bits of build.sh but I am not sure if it was obvious to find. > If that does not help, something eroneously uses the hosts menuc/msgc > (or the msg_sys.def file from the host installation) - could be a bug in > the tools version of msgc. > > Martin
Re: usr.sbin/sysinst compile error
Martin Husemann transcribed 653 bytes: > On Wed, Jun 26, 2019 at 08:28:21AM +, n...@n0.is wrote: > > Christos Zoulas transcribed 234 bytes: > > > In article <20190625191514.qbcastohka3nxfos@uptimegirl>, > > > wrote: > > > >Hi, > > > > > > > >has someone commited a fix for this in the last 8 hours or so > > > >since I've been compiling src? > > > > > > Have you cleaned in the sysinst directory? > > > > Yes, this happened with a clean /usr/obj directory. > > Are you compiling with up to date tools or some other variant (like USETOOLS > set to no or never)? This is with ./build.sh ... -U distribution with the host system being on 8.99.42, built with clang, and this being relevant parts of mk.conf: PKG_DEVELOPER?= yes MKREPRO=yes MKX11=yes # needed as building GCC alongside clang is not maintained? MKGCC=no # libraries MKLLVM=yes # libc++ MKLIBCXX=yes # clang HAVE_LLVM=yes # pkgsrc with clang PKGSRC_COMPILER=clang # pkgsrc clang location CLANGBASE=/usr > The problem is that msgc / menuc and the support files they install changed > recently and you seem to have some mix of old and new files. > > Martin
Re: usr.sbin/sysinst compile error
Christos Zoulas transcribed 234 bytes: > In article <20190625191514.qbcastohka3nxfos@uptimegirl>, wrote: > >Hi, > > > >has someone commited a fix for this in the last 8 hours or so > >since I've been compiling src? > > Have you cleaned in the sysinst directory? Yes, this happened with a clean /usr/obj directory. > christos >
usr.sbin/sysinst compile error
Hi, has someone commited a fix for this in the last 8 hours or so since I've been compiling src? # compile amd64/msg_defs.o /usr/src/../tools/bin/x86_64--netbsd-clang -O2 -fPIE -Os -std=gnu99 -Wno-sign-compare -Wno-pointer-sign -Wall -Wstrict-prototypes -Wmissing-prototypes -Wpointer-arith -Wno-sign-compare-Wreturn-type -Wswitch -Wshadow -Wcast-qual -Wwrite-strings -Wextra -Wno-unused-parameter -Wno-sign-compare -Wsign-compare -Wformat=2 -Wpointer-sign -Wmissing-noreturn -Werror -DBOOTSEL -DWSKBD -D_KERNTYPES -DHAVE_GPT -DHAVE_MBR --sysroot=/usr/src/../obj/destdir.amd64 -I. -I/usr/src/usr.sbin/sysinst/arch/amd64/../.. -I/usr/src/usr.sbin/sysinst/arch/amd64 -I/usr/src/usr.sbin/sysinst/arch/amd64/../../../../sbin/fsck -DSETS_TAR_SUFF=\"tar.xz\" -DREL=\"8.99.48\" -DMACH=\"amd64\" -DMACH_amd64 -DARCH_x86_64 -DSYSINST_FTP_HOST=\"nyftp.NetBSD.org\" -DSYSINST_HTTP_HOST=\"nycdn.NetBSD.org\" -DREL_PATH=\"HEAD\" -DPKG_SUBDIR="\"8.0\"" -DNETBSD_MAJOR='"8"' -DCATALOG_DIR=\"/usr/share/sysinst/catalog\" -DINET6 -cmsg_defs.c msg_defs.c:989:15: error: format string is not a string literal [-Werror,-Wformat-nonliteral] _msg_vprompt(msg_string(msg_no), msg_flags, def, val, val_buf_len, ap); ^~ 1 error generated. *** Failed target: msg_defs.o *** Failed command: /usr/src/../tools/bin/x86_64--netbsd-clang -O2 -fPIE -Os -std=gnu99 -Wno-sign-compare -Wno-pointer-sign -Wall -Wstrict-prototypes -Wmissing-prototypes -Wpointer-arith -Wno-sign-compare -Wreturn-type -Wswitch -Wshadow -Wcast-qual -Wwrite-strings -Wextra -Wno-unused-parameter -Wno-sign-compare -Wsign-compare -Wformat=2 -Wpointer-sign -Wmissing-noreturn -Werror -DBOOTSEL -DWSKBD -D_KERNTYPES -DHAVE_GPT -DHAVE_MBR --sysroot=/usr/src/../obj/destdir.amd64 -I. -I/usr/src/usr.sbin/sysinst/arch/amd64/../.. -I/usr/src/usr.sbin/sysinst/arch/amd64 -I/usr/src/usr.sbin/sysinst/arch/amd64/../../../../sbin/fsck -DSETS_TAR_SUFF=\"tar.xz\" -DREL=\"8.99.48\" -DMACH=\"amd64\" -DMACH_amd64 -DARCH_x86_64 -DSYSINST_FTP_HOST=\"nyftp.NetBSD.org\" -DSYSINST_HTTP_HOST=\"nycdn.NetBSD.org\" -DREL_PATH=\"HEAD\" -DPKG_SUBDIR="\"8.0\"" -DNETBSD_MAJOR='"8"' -DCATALOG_DIR=\"/usr/share/sysinst/catalog\" -DINET6 -c msg_defs.c *** Error code 1 Stop. nbmake[7]: stopped in /usr/src/usr.sbin/sysinst/arch/amd64 *** Failed target: dependall *** Failed command: cd "/usr/src/usr.sbin/sysinst/arch/amd64"; /usr/src/../tools/bin/nbmake realall *** Error code 1
Re: iwm driver leads to kernel crash
Martin Husemann transcribed 430 bytes: > On Sat, Apr 27, 2019 at 04:18:20PM +, n...@n0.is wrote: > > It's an T440s, so one module can be exchanged, the other is soldered > > to the board. > > > > I can give exchanging the replacable one a try. > > I have had good experience with running memtest+ from pkgsrc (I had to use > an older binary, newer gcc seems to misoptimize the code). > > Also worth a shot and easy (you can boot the binary right from the NetBSD > bootloader). so far I've used the lenovo integrated memory checking tool, no issues found. I'll use the x86+ soon, because (I think that ) something is wrong here. I've had a kernel crash while running gdb today, and another one while unplugging an unknown USB device. > Martin
equivalent flag or code to MSG_MORE in NetBSD?
Hi folx, My Google Summer of Code project at GNU libmicrohttpd is - among other things - focused on analyzing and adjusting syscalls on a range of Operating Systems. This includes NetBSD, FreeBSD, Windows 10 cygwin, Debian Linux. I was made aware of MSG_MORE in the Linux kernel which I will consider in the code to be written: (abstract from sendto(2)): MSG_MORE (Since Linux 2.4.4) The caller has more data to send. This flag is used with TCP sockets to obtain the same effect as the TCP_CORK socket option (see tcp(7)), with the difference that this flag can be set on a per-call basis. Since Linux 2.6, this flag is also supported for UDP sockets, and informs the kernel to package all of the data sent in calls with this flag set into a single datagram which is only transmitted when a call is performed that does not specify this flag. (See also the UDP_CORK socket option described in udp(7).) (end abstract) For high performance webservers, is there a method or set of methods (where by method I mean any pseudo-code or code related solution) which works for NetBSD as a drop-in equivalent of MSG_MORE? I can go more into detail and be less abstract if it helps. Cheers, ng0
Re: building base with clang
Martin Husemann transcribed 372 bytes: > On Wed, Jun 05, 2019 at 07:48:25AM +, n...@n0.is wrote: > > Hi, > > > > how good or bad is the base system with clang (ie, since > > gcc is the default is enough care taken to make the cvs > > build with clang without major breakages)? > > Depends on your architecture. You can see a few of those builds > at > > http://releng.netbsd.org/cgi-bin/builds.cgi > > under "HEAD-llvm". Thanks! > Martin
building base with clang
Hi, how good or bad is the base system with clang (ie, since gcc is the default is enough care taken to make the cvs build with clang without major breakages)? According to what I've found, is this all there is to mk.conf, or do some new options exist in addition to these: # needed as building GCC alongside clang is not maintained? MKGCC=no # libraries MKLLVM=yes # libc++ MKLIBCXX=yes # clang HAVE_LLVM=yes # pkgsrc with clang PKGSRC_COMPILER=clang # pkgsrc clang location CLANGBASE=/usr Cheers, ng0
Re: iwm driver leads to kernel crash
Mathew, Cherry G. transcribed 18K bytes: > On 27 April 2019 7:50:08 PM GMT+05:45, n...@n0.is wrote: > >Ryota Ozaki transcribed 512 bytes: > >> On Mon, Apr 1, 2019 at 6:53 AM wrote: > >> > > >> > Hi, > >> > > >> > would further dmesg outputs from the last 10 or so kernel crashes > >> > still be useful? > >> > >> Yes, and if you have crashdumps, could you please provide detailed > >> information from them? (see https://wiki.netbsd.org/panic/ for the > >> instructions). > >> > >> > This still keeps happening (workaround so far is to use ethernet). > >> > > >> > Or maybe I'm looking at the wrong kind of bug and there is > >something > >> > to track / being worked on already? > >> > >> I guess no. > >> > >> Thanks, > >> ozaki-r > > > >I guess I should have filed a bug. > >Anyways, I have gathered around 16 coredumps in the last months > >but I haven't had the time to properly process them. > > > >While it looks to me like a problem related to my wireless, as most > >crashes happened when I had the wifi card activated in the BIOS, > >some crashes - like crash 16, recent CVS state (build on thursday) - > >happen with it turned off. > >So I really have no idea what's going on here, if they all are related > >(I doubt it), and where to start. > > > >If I'm missing something, let me know. > > > >Cheers, > >ng0 > > > >* dmesg -M netbsd.16.core -N netbsd.16 > > > >[ 246.280922] panic: TAILQ_PREREMOVE head 0x80303374e388 elm > >0x82800fe91168 > >/usr/src/sys/external/bsd/common/linux/linux_work.c:1022 > >[ 246.280922] cpu0: Begin traceback... > >[ 246.280922] vpanic() at netbsd:vpanic+0x160 > >[ 246.280922] snprintf() at netbsd:snprintf > >[ 246.280922] linux_mod_delayed_work() at > >netbsd:linux_mod_delayed_work+0x588 > >[ 246.280922] i915_gem_retire_requests() at > >netbsd:i915_gem_retire_requests+0x86 > >[ 246.280922] i915_gem_init_seqno() at > >netbsd:i915_gem_init_seqno+0x4c > >[ 246.280922] i915_gem_get_seqno() at netbsd:i915_gem_get_seqno+0x39 > >[ 246.280922] i915_gem_request_alloc() at > >netbsd:i915_gem_request_alloc+0x6e > >[ 246.280922] intel_crtc_page_flip() at > >netbsd:intel_crtc_page_flip+0xa62 > >[ 246.280922] drm_mode_page_flip_ioctl() at > >netbsd:drm_mode_page_flip_ioctl+0x22b > >[ 246.280922] drm_ioctl() at netbsd:drm_ioctl+0x214 > >[ 246.280922] drm_ioctl_shim() at netbsd:drm_ioctl_shim+0x4d > >[ 246.280922] sys_ioctl() at netbsd:sys_ioctl+0x5ab > >[ 246.280922] syscall() at netbsd:syscall+0x181 > >[ 246.280922] --- syscall (number 54) --- > >[ 246.280922] 75cad51952ba: > >[ 246.280922] cpu0: End traceback... > > > >* dmesg -M netbsd.15.core -N netbsd.15 > > > >[ 1009.208570] panic: kernel diagnostic assertion "ring->queued > 0" > >failed: file "/usr/src/sys/dev/pci/if_iwm.c", line 4459 > >[ 1009.208570] cpu0: Begin traceback... > >[ 1009.218574] vpanic() at netbsd:vpanic+0x160 > >[ 1009.218574] stge_eeprom_wait.isra.4() at > >netbsd:stge_eeprom_wait.isra.4 > >[ 1009.218574] iwm_softintr() at netbsd:iwm_softintr+0x123b > >[ 1009.218574] softint_dispatch() at netbsd:softint_dispatch+0xf4 > >[ 1009.218574] DDB lost frame for netbsd:Xsoftintr+0x4f, trying > >0xac00a931c0f0 > >[ 1009.218574] Xsoftintr() at netbsd:Xsoftintr+0x4f > >[ 1009.218574] --- interrupt --- > >[ 1009.218574] b8e934aa2c4c1dc0: > >[ 1009.218574] cpu0: End traceback... > > > >* dmesg -M netbsd.14.core -N netbsd.14 > > > >[ 2371.756752] kern error: > >[drm:(/usr/src/sys/external/bsd/drm2/dist/drm/i915/intel_sprite.c:132)intel_pipe_update_start] > >*ERROR* Potential atomic update failure on pipe A: -35 > >[ 5160.679159] kern error: > >[drm:(/usr/src/sys/external/bsd/drm2/dist/drm/i915/intel_sprite.c:132)intel_pipe_update_start] > >*ERROR* Potential atomic update failure on pipe A: -35 > >[ 6881.287646] panic: kernel diagnostic assertion "! > >state->root_referenced" failed: file "/usr/src/sys/kern/vfs_lookup.c", > >line 592 > >[ 6881.287646] cpu0: Begin traceback... > >[ 6881.287646] vpanic() at netbsd:vpanic+0x160 > >[ 6881.287646] stge_eeprom_wait.isra.4() at > >netbsd:stge_eeprom_wait.isra.4 > >[ 6881.287646] namei_tryemulroot() at netbsd:namei_tryemulroot+0xdd1 > >[ 6881.287646] namei() at ne
Re: iwm driver leads to kernel crash
Ryota Ozaki transcribed 512 bytes: > On Mon, Apr 1, 2019 at 6:53 AM wrote: > > > > Hi, > > > > would further dmesg outputs from the last 10 or so kernel crashes > > still be useful? > > Yes, and if you have crashdumps, could you please provide detailed > information from them? (see https://wiki.netbsd.org/panic/ for the > instructions). > > > This still keeps happening (workaround so far is to use ethernet). > > > > Or maybe I'm looking at the wrong kind of bug and there is something > > to track / being worked on already? > > I guess no. > > Thanks, > ozaki-r I guess I should have filed a bug. Anyways, I have gathered around 16 coredumps in the last months but I haven't had the time to properly process them. While it looks to me like a problem related to my wireless, as most crashes happened when I had the wifi card activated in the BIOS, some crashes - like crash 16, recent CVS state (build on thursday) - happen with it turned off. So I really have no idea what's going on here, if they all are related (I doubt it), and where to start. If I'm missing something, let me know. Cheers, ng0 * dmesg -M netbsd.16.core -N netbsd.16 [ 246.280922] panic: TAILQ_PREREMOVE head 0x80303374e388 elm 0x82800fe91168 /usr/src/sys/external/bsd/common/linux/linux_work.c:1022 [ 246.280922] cpu0: Begin traceback... [ 246.280922] vpanic() at netbsd:vpanic+0x160 [ 246.280922] snprintf() at netbsd:snprintf [ 246.280922] linux_mod_delayed_work() at netbsd:linux_mod_delayed_work+0x588 [ 246.280922] i915_gem_retire_requests() at netbsd:i915_gem_retire_requests+0x86 [ 246.280922] i915_gem_init_seqno() at netbsd:i915_gem_init_seqno+0x4c [ 246.280922] i915_gem_get_seqno() at netbsd:i915_gem_get_seqno+0x39 [ 246.280922] i915_gem_request_alloc() at netbsd:i915_gem_request_alloc+0x6e [ 246.280922] intel_crtc_page_flip() at netbsd:intel_crtc_page_flip+0xa62 [ 246.280922] drm_mode_page_flip_ioctl() at netbsd:drm_mode_page_flip_ioctl+0x22b [ 246.280922] drm_ioctl() at netbsd:drm_ioctl+0x214 [ 246.280922] drm_ioctl_shim() at netbsd:drm_ioctl_shim+0x4d [ 246.280922] sys_ioctl() at netbsd:sys_ioctl+0x5ab [ 246.280922] syscall() at netbsd:syscall+0x181 [ 246.280922] --- syscall (number 54) --- [ 246.280922] 75cad51952ba: [ 246.280922] cpu0: End traceback... * dmesg -M netbsd.15.core -N netbsd.15 [ 1009.208570] panic: kernel diagnostic assertion "ring->queued > 0" failed: file "/usr/src/sys/dev/pci/if_iwm.c", line 4459 [ 1009.208570] cpu0: Begin traceback... [ 1009.218574] vpanic() at netbsd:vpanic+0x160 [ 1009.218574] stge_eeprom_wait.isra.4() at netbsd:stge_eeprom_wait.isra.4 [ 1009.218574] iwm_softintr() at netbsd:iwm_softintr+0x123b [ 1009.218574] softint_dispatch() at netbsd:softint_dispatch+0xf4 [ 1009.218574] DDB lost frame for netbsd:Xsoftintr+0x4f, trying 0xac00a931c0f0 [ 1009.218574] Xsoftintr() at netbsd:Xsoftintr+0x4f [ 1009.218574] --- interrupt --- [ 1009.218574] b8e934aa2c4c1dc0: [ 1009.218574] cpu0: End traceback... * dmesg -M netbsd.14.core -N netbsd.14 [ 2371.756752] kern error: [drm:(/usr/src/sys/external/bsd/drm2/dist/drm/i915/intel_sprite.c:132)intel_pipe_update_start] *ERROR* Potential atomic update failure on pipe A: -35 [ 5160.679159] kern error: [drm:(/usr/src/sys/external/bsd/drm2/dist/drm/i915/intel_sprite.c:132)intel_pipe_update_start] *ERROR* Potential atomic update failure on pipe A: -35 [ 6881.287646] panic: kernel diagnostic assertion "! state->root_referenced" failed: file "/usr/src/sys/kern/vfs_lookup.c", line 592 [ 6881.287646] cpu0: Begin traceback... [ 6881.287646] vpanic() at netbsd:vpanic+0x160 [ 6881.287646] stge_eeprom_wait.isra.4() at netbsd:stge_eeprom_wait.isra.4 [ 6881.287646] namei_tryemulroot() at netbsd:namei_tryemulroot+0xdd1 [ 6881.287646] namei() at netbsd:namei+0x29 [ 6881.287646] fd_nameiat.isra.2() at netbsd:fd_nameiat.isra.2+0x54 [ 6881.287646] do_sys_accessat.part.8() at netbsd:do_sys_accessat.part.8+0xbf [ 6881.287646] linux_syscall() at netbsd:linux_syscall+0x161 [ 6881.287646] cpu0: End traceback... * dmesg -M netbsd.13.core -N netbsd.13 [ 23885.558925] panic: kernel diagnostic assertion "! state->root_referenced" failed: file "/usr/src/sys/kern/vfs_lookup.c", line 592 [ 23885.558925] cpu0: Begin traceback... [ 23885.558925] vpanic() at netbsd:vpanic+0x160 [ 23885.558925] stge_eeprom_wait.isra.4() at netbsd:stge_eeprom_wait.isra.4 [ 23885.558925] namei_tryemulroot() at netbsd:namei_tryemulroot+0xdd1 [ 23885.558925] namei() at netbsd:namei+0x29 [ 23885.568928] fd_nameiat.isra.2() at netbsd:fd_nameiat.isra.2+0x54 [ 23885.568928] do_sys_accessat.part.8() at netbsd:do_sys_accessat.part.8+0xbf [ 23885.568928] linux_syscall() at netbsd:linux_syscall+0x161 [ 23885.568928] cpu0: End traceback... Leading up to
Re: iwm driver leads to kernel crash
Hi, would further dmesg outputs from the last 10 or so kernel crashes still be useful? This still keeps happening (workaround so far is to use ethernet). Or maybe I'm looking at the wrong kind of bug and there is something to track / being worked on already? n...@n0.is transcribed 452 bytes: > m...@netbsd.org transcribed 280 bytes: > > It's not iwm. I have the same bug reported but with re(4) which isn't > > wireless even. the backtrace looks different from ddb. > > from ddb, the failing instruction is, > > > > stopped at pid 276.1 (dhcpcd) at netbsd:npf_ifaddrhook+0x55: movq > > 18(%r12), %rsi > > > > (without using npf at all) > > I've been slow to respond, > but with a more recent version this problem is solved for me. > > Thanks to whoever fixed it. >
Re: iwm driver leads to kernel crash
m...@netbsd.org transcribed 280 bytes: > It's not iwm. I have the same bug reported but with re(4) which isn't > wireless even. the backtrace looks different from ddb. > from ddb, the failing instruction is, > > stopped at pid 276.1 (dhcpcd) at netbsd:npf_ifaddrhook+0x55: movq > 18(%r12), %rsi > > (without using npf at all) I've been slow to respond, but with a more recent version this problem is solved for me. Thanks to whoever fixed it.
iwm driver leads to kernel crash
Hi, this behavior on an Lenovo Thinkpad started today after rebuilding the system yesterday. I'm not sure what else could help, this is the dmesg from the second kernel crash. msi5 vec 0 [ 1.053482] ehci0 at pci0 dev 29 function 0: vendor 8086 product 9c26 (rev. 0x04) [ 1.053482] ehci0: interrupting at ioapic0 pin 23 [ 1.053482] ehci0: EHCI version 1.0 [ 1.053482] usb2 at ehci0: USB revision 2.0 [ 1.053482] pcib0 at pci0 dev 31 function 0: vendor 8086 product 9c43 (rev. 0x04) [ 1.053482] ahcisata0 at pci0 dev 31 function 2: vendor 8086 product 9c03 (rev. 0x04) [ 1.053482] ahcisata0: 64-bit DMA [ 1.053482] ahcisata0: AHCI revision 1.30, 3 ports, 32 slots, CAP 0xc734ff02 [ 1.053482] ahcisata0: interrupting at msi6 vec 0 [ 1.053482] atabus0 at ahcisata0 channel 0 [ 1.053482] atabus1 at ahcisata0 channel 1 [ 1.053482] ichsmb0 at pci0 dev 31 function 3: vendor 8086 product 9c22 (rev. 0x04) [ 1.053482] ichsmb0: interrupting at ioapic0 pin 18 [ 1.053482] iic0 at ichsmb0: I2C bus [ 1.053482] isa0 at pcib0 [ 1.053482] tpm0 at isa0 iomem 0xfed4-0xfed44fff irq 7: device 0x104a rev 0x4e [ 1.053482] acpicpu0 at cpu0: ACPI CPU [ 1.053482] ACPI: Dynamic OEM Table Load: [ 1.053482] ACPI: SSDT 0x8143261EF810 000436 (v01 PmRef Cpu0Cst 3001 INTL 20120711) [ 1.053482] acpicpu0: C1: FFH, lat 1 us, pow 1000 mW [ 1.053482] acpicpu0: C2: FFH, lat 148 us, pow 200 mW [ 1.053482] acpicpu0: C3: FFH, lat 506 us, pow 200 mW [ 1.053482] acpicpu0: P0: FFH, lat 10 us, pow 15000 mW, 2701 MHz, turbo boost [ 1.053482] acpicpu0: P1: FFH, lat 10 us, pow 15000 mW, 2700 MHz [ 1.053482] acpicpu0: P2: FFH, lat 10 us, pow 14236 mW, 2600 MHz [ 1.053482] acpicpu0: P3: FFH, lat 10 us, pow 12752 mW, 2400 MHz [ 1.053482] acpicpu0: P4: FFH, lat 10 us, pow 12175 mW, 2300 MHz [ 1.053482] acpicpu0: P5: FFH, lat 10 us, pow 10775 mW, 2100 MHz [ 1.053482] acpicpu0: P6: FFH, lat 10 us, pow 10234 mW, 2000 MHz [ 1.053482] acpicpu0: P7: FFH, lat 10 us, pow 8912 mW, 1800 MHz [ 1.053482] acpicpu0: P8: FFH, lat 10 us, pow 8271 mW, 1700 MHz [ 1.053482] acpicpu0: P9: FFH, lat 10 us, pow 7778 mW, 1600 MHz [ 1.053482] acpicpu0: P10: FFH, lat 10 us, pow 6561 mW, 1400 MHz [ 1.053482] acpicpu0: P11: FFH, lat 10 us, pow 6099 mW, 1300 MHz [ 1.053482] acpicpu0: P12: FFH, lat 10 us, pow 4957 mW, 1100 MHz [ 1.053482] acpicpu0: P13: FFH, lat 10 us, pow 4529 mW, 1000 MHz [ 1.053482] acpicpu0: P14: FFH, lat 10 us, pow 3461 mW, 800 MHz [ 1.053482] acpicpu0: P15: FFH, lat 10 us, pow 2945 mW, 756 MHz [ 1.053482] acpicpu0: T0: I/O, lat 1 us, pow 0 mW, 100 % [ 1.053482] acpicpu0: T1: I/O, lat 1 us, pow 0 mW, 88 % [ 1.053482] acpicpu0: T2: I/O, lat 1 us, pow 0 mW, 76 % [ 1.053482] acpicpu0: T3: I/O, lat 1 us, pow 0 mW, 64 % [ 1.053482] acpicpu0: T4: I/O, lat 1 us, pow 0 mW, 52 % [ 1.053482] acpicpu0: T5: I/O, lat 1 us, pow 0 mW, 40 % [ 1.053482] acpicpu0: T6: I/O, lat 1 us, pow 0 mW, 28 % [ 1.053482] acpicpu0: T7: I/O, lat 1 us, pow 0 mW, 16 % [ 1.053482] coretemp0 at cpu0: thermal sensor, 1 C resolution, Tjmax=100 [ 1.053482] acpicpu1 at cpu1: ACPI CPU [ 1.053482] acpicpu2 at cpu2: ACPI CPU [ 1.053482] coretemp1 at cpu2: thermal sensor, 1 C resolution, Tjmax=100 [ 1.053482] acpicpu3 at cpu3: ACPI CPU [ 1.053482] timecounter: Timecounter "clockinterrupt" frequency 100 Hz quality 0 [ 2.096917] timecounter: Timecounter "TSC" frequency 2693889730 Hz quality 3000 [ 2.100314] uhub0 at usb0: NetBSD () xHCI root hub (), class 9/0, rev 3.00/1.00, addr 0 [ 2.100314] uhub0: 4 ports with 4 removable, self powered [ 2.100314] uhub1 at usb1: NetBSD () xHCI root hub (), class 9/0, rev 2.00/1.00, addr 0 [ 2.100314] uhub1: 9 ports with 9 removable, self powered [ 2.100314] acpiacad0: AC adapter online. [ 2.106922] acpibat0: SONY LiP rechargeable battery [ 2.106922] acpibat0: granularity: low->warn 0.001 Wh, warn->full 0.001 Wh [ 2.106922] IPsec: Initialized Security Association Processing. [ 2.106922] acpibat1: SANYO LION rechargeable battery [ 2.106922] acpibat1: granularity: low->warn 0.001 Wh, warn->full 0.001 Wh [ 2.116927] uhub2 at usb2: NetBSD () EHCI root hub (), class 9/0, rev 2.00/1.00, addr 1 [ 2.116927] uhub2: 3 ports with 3 removable, self powered [ 2.196968] ahcisata0 port 0: device present, speed: 6.0Gb/s [ 2.196968] ahcisata0 port 1: device present, speed: 6.0Gb/s [ 3.727748] ubt0 at uhub1 port 7 [ 3.727748] ubt0: vendor 8087 (0x8087) product 07dc (0x7dc), rev 2.00/0.01, addr 1 [ 3.737753] wd0 at atabus0 drive 0 [ 3.737753] wd0: [ 3.737753] wd0: drive supports 1-sector PIO transfers, LBA48 addressing [ 3.737753] wd0: 953 GB, 1984533 cyl, 16 head, 63 sec, 51
