Bug 256494

Summary: iwn: kernel panic after hot spot is down, FreeBSD restarts
Product: Base System Reporter: Slawomir Wojciech Wojtczak <vermaden>
Component: kernAssignee: freebsd-wireless (Nobody) <wireless>
Status: Open ---    
Severity: Affects Only Me CC: bz, grahamperrin, trix
Priority: --- Keywords: crash, needs-qa
Version: 13.0-RELEASEFlags: vermaden: maintainer-feedback?
Hardware: amd64   
OS: Any   
Bug Depends on:    
Bug Blocks: 278175    

Description Slawomir Wojciech Wojtczak 2021-06-09 06:41:38 UTC
Hi.

My /etc/rc.conf settings related to network.

    hostname=w520.local
    background_dhclient=YES
    extra_netfs_types=NFS
    defaultroute_delay=3
    defaultroute_carrier_delay=3
    harvest_mask=351

I start my network connections manually with script so that is why no network settings in /etc/rc.conf file.

My /etc/wpa_supplicant.conf WiFi network.

    eapol_version=2
    ap_scan=1
    fast_reauth=1

    network={
      ssid="vermore5"
      psk="password"
      priority=6
    }

My hardware is ThinkPad W520 from 2011 with Intel 6300 WiFi:

    # pciconf -lv
    (...)
    iwn0@pci0:3:0:0:        class=0x028000 rev=0x3e hdr=0x00 vendor=0x8086 device=0x4238 subvendor=0x8086 subdevice=0x1111
        vendor     = 'Intel Corporation'
        device     = 'Centrino Ultimate-N 6300'
        class      = network



Steps to reproduce:

1. Connect to your hot spot WiFi:
    # wpa_supplicant -i wlan0 -c /etc/wpa_supplicant.conf -s -B
    # dhclient wlan0

2. You have Internet connection as usual - everything works.

3. Power off the hot spot WiFi (so it will not be accessible)

4. FreeBSD panics and reboots.



Hope that helps.

Regards.
Comment 1 Slawomir Wojciech Wojtczak 2021-06-09 07:58:47 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.
Comment 2 Graham Perrin freebsd_committer freebsd_triage 2021-06-12 00:42:35 UTC
Interesting. Is it possible to share relevant information from a /var/crash/core.txt.* record of a panic?
Comment 3 Slawomir Wojciech Wojtczak 2021-06-12 08:39:29 UTC
(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
Comment 4 Graham Perrin freebsd_committer freebsd_triage 2021-06-12 11:53:27 UTC
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.
Comment 5 Slawomir Wojciech Wojtczak 2021-07-16 18:50:39 UTC
(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.
Comment 6 Graham Perrin freebsd_committer freebsd_triage 2021-07-17 14:29:08 UTC
(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.
Comment 7 Slawomir Wojciech Wojtczak 2021-07-17 20:28:31 UTC
(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.
Comment 8 Slawomir Wojciech Wojtczak 2021-07-19 11:43:50 UTC
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.
Comment 9 Slawomir Wojciech Wojtczak 2021-07-19 19:45:00 UTC
Promised another 3 /var/crash dumps:
https://www.mediafire.com/file/d086areztbmunrr/var-crash-2.tar.gz/file
Comment 10 Slawomir Wojciech Wojtczak 2021-07-28 11:29:15 UTC
Any progress?
Comment 11 Graham Perrin 2024-12-15 06:09:29 UTC
This might belong somewhere in the tree at <https://bugs.freebsd.org/bugzilla/showdependencytree.cgi?id=277512&hide_resolved=1>.
Comment 12 Bjoern A. Zeeb freebsd_committer freebsd_triage 2024-12-16 22:35:45 UTC
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?
Comment 13 Bjoern A. Zeeb freebsd_committer freebsd_triage 2024-12-16 22:47:04 UTC
Just unset maintainer feedback as I am not the maintainer of iwn(4).
Comment 14 Slawomir Wojciech Wojtczak 2024-12-16 22:47:40 UTC
(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
Comment 15 Bjoern A. Zeeb freebsd_committer freebsd_triage 2024-12-16 22:51:56 UTC
(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?