Summary: | iwn: kernel panic after hot spot is down, FreeBSD restarts | ||
---|---|---|---|
Product: | Base System | Reporter: | Slawomir Wojciech Wojtczak <vermaden> |
Component: | kern | Assignee: | freebsd-wireless (Nobody) <wireless> |
Status: | Open --- | ||
Severity: | Affects Only Me | CC: | bz, grahamperrin, trix |
Priority: | --- | Keywords: | crash, needs-qa |
Version: | 13.0-RELEASE | Flags: | vermaden:
maintainer-feedback?
|
Hardware: | amd64 | ||
OS: | Any | ||
Bug Depends on: | |||
Bug Blocks: | 278175 |
Description
Slawomir Wojciech Wojtczak
2021-06-09 06:41:38 UTC
I forgot to add that I also check every minute if I have Internet connection and if not I try to reconnect in a crontab(5) job. % crontab -l | grep -C 1 WIFI ------------------------------------------------------------------------------- # WIFI RESTART * * * * * ~/scripts/network-ping.sh 1> /dev/null 2> /dev/null ------------------------------------------------------------------------------- # cat ~/scripts/network-ping.sh -------------------------------------------------------------------------------% #! /bin/sh # WAIT 5 SECONDS WITH -t OPTION if ! ping -c 1 -s 0 -t 5 -q 1.1.1.1 1> /dev/null 2> /dev/null then ~/scripts/network.sh wlan start vermore else exit 0 fi ~/scripts/network-ping.sh ------------------------------------------------------------------------------- The *network.sh* is quite longer and its available here: https://github.com/vermaden/network I am not sure that this changes anything but wanted to be specific. Regards. Interesting. Is it possible to share relevant information from a /var/crash/core.txt.* record of a panic? (In reply to Graham Perrin from comment #2) These are the only things I have there: # find /var/crash /var/crash /var/crash/minfree # cat /var/crash/minfree 2048 Relevant lines from my /etc/rc.conf are: # Set dumpdev to "AUTO" to enable crash dumps, "NO" to disable # dumpdev="AUTO" dumpdev="/dev/ada0p3" dumpdir="/var/crash" savecore_enable="YES" – yours should differ slightly. ---- It's normal to have AUTO for dumpdev. Mine is /dev/ada0p3 in the context of GELI-encrypted swap, root@mowa219-gjp4-8570p:~ # lsblk ada0 DEVICE MAJ:MIN SIZE TYPE LABEL MOUNT ada0 0:130 466G GPT - - ada0p1 0:132 200M efi gpt/efiboot0 - ada0p2 0:134 512K freebsd-boot gpt/gptboot0 - <FREE> -:- 492K - - - ada0p3 0:136 16G freebsd-swap gpt/swap0 SWAP ada0p3.eli 2:71 16G freebsd-swap - SWAP ada0p4 0:138 450G freebsd-zfs gpt/zfs0 <ZFS> ada0p4.eli 0:149 450G zfs - - <FREE> -:- 4.0K - - - root@mowa219-gjp4-8570p:~ # ---- If you have not already done so: please install devel/gdb (for core.txt.* files to include debug information). If you perform an installation: after completion, wait at least sixty seconds before reproducing the kernel panic. (In reply to Graham Perrin from comment #4) Hi, I have tried to set it up but /var/crash is empty after several of those panics. # lsblk ada1 DEVICE MAJ:MIN SIZE TYPE LABEL MOUNT ada1 0:120 119G GPT - - ada1p1 0:124 200M efi gpt/efiboot0 - ada1p2 0:126 512K freebsd-boot gpt/gptboot0 - <FREE> -:- 492K - - - ada1p3 0:128 1.0G freebsd-swap gpt/swap0 - ada1p4 0:130 118G freebsd-zfs gpt/zfs0 <ZFS> ada1p4.eli 0:138 118G - - - <FREE> -:- 324K - - - # swapinfo -h Device Size Used Avail Capacity /dev/gpt/swap0 1.0G 0B 1.0G 0% # glabel status | grep swap0 gpt/swap0 N/A ada1p3 # grep dump /etc/rc.conf dumpdev=/dev/ada1p3 dumpdir=/var/crash # find /var/crash /var/crash /var/crash/minfree What else I can do to 'gather' these crash data at /var/crash? Regards. (In reply to vermaden from comment #5) 16 GB memory, yes? Whatever the amount of real memory, your 1.0 G swap partition at ada1p3 might be too small for dumps in this situation. (I typically give at least 16 GB to swap when installing FreeBSD.) If you have a spare 16 or 32 GB USB flash drive, you can repartition it then temporarily make its suitably large partition the dumpdev – until you get a panic and then, the associated information at /var/crash ---- If you would like to test kernel panics on demand (from a tty, not X), <https://forums.freebsd.org/threads/81273/> is not entirely solved, but does link to relevant information. (In reply to Graham Perrin from comment #6) Thank you for the tip about pendrive - this time worked :) Here is the /var/crash directory contents: https://www.mediafire.com/file/q5ply110ihu6pzl/var-crash.tar.gz/file There are two 'dumps' but one incomplete because the boot process stopped without any message and I hit CTRL+C and then the message that savecore was canceled ... IMHO it would be better to display that message BEFORE making a long dump because that way non-developers do not know why their system does not progress and hangs at boot for something :) Hope that helps. Regards. I also found an interesting 'side effect'. After my main home WiFi ssid disappeared (power outage) I was not able to connect to my temporary WiFi hotspot served from phone. I even commented out (with '#' chars) my home WiFi ssid from /etc/wpa_supplicant.conf and *ifconfig wlan0* still showed ssid as my home WiFi network. Resetting that with these did not helped: # ifconfig wlan0 ssid - # ifconfig wlan0 ssid phone-net Other interesting thing - after doing *destroy* on that wlan0 interface it reappeared itself after bring destroyed with ssid to my home WiFi network (the on that disappeared during power outage). # ifconfig wlan0 destroy # ifconfig wlan0 destroy ifconfig: interface wlan1 does not exist # ifconfig wlan0 destroy # ifconfig wlan0 destroy Each command executed successfully because wlan0 recreated itself. If I typed them too fast then they yield that wlan0 does not exists and the next execution was successful because wlan0 again existed without me creating it. I have 3 additional /var/crash dumps but I will upload them later when not on a WWAN connection. When that laptop rebooted with crash dump the WiFi card was still fucked up each time. The only thing that allowed me to connect to different WiFi network after my main WiFi network disappeared was to push power button for 5 seconds to power down that laptop 'hard' and start fresh boot. Hope that helps. This is 13.0-RELEASE without any patches as the ones that showed were not vulnerable to me. Regards. Promised another 3 /var/crash dumps: https://www.mediafire.com/file/d086areztbmunrr/var-crash-2.tar.gz/file Any progress? This might belong somewhere in the tree at <https://bugs.freebsd.org/bugzilla/showdependencytree.cgi?id=277512&hide_resolved=1>. I am getting "forbidden" when I try to fetch a kernel crash. Having had a backtrace/panic message i the bug report would have helped. Is there any chance the files still exist? Just unset maintainer feedback as I am not the maintainer of iwn(4). (In reply to Bjoern A. Zeeb from comment #12) I have searched my local storage and also my MediaFire account - but not trace of these files there ... I will remember to attach these as attachment in the future. ... but if the bug still exists - its easy to get new dump. 1. Enable WiFi Hot Spot on a phone. 2. Connect to that Hot Spot with FreeBSD. 3. Stop Hot Spot. 4. Watch FreeBSD die with kernel panic. Regards, ver (In reply to Slawomir Wojciech Wojtczak from comment #14) There can be multiple circumstances; e.g., was 11n being used, which flags the hotspot had set; basically it would mean if an AP goes away during transmit we could observe this, and then I would expect a lot more reports for this. Do you have any chance to still repro this -- do you still have that device you used as hotspot? |