Bug 249925 - if_rtwn_usb panics on install
Summary: if_rtwn_usb panics on install
Status: Closed FIXED
Alias: None
Product: Base System
Classification: Unclassified
Component: wireless (show other bugs)
Version: CURRENT
Hardware: amd64 Any
: --- Affects Only Me
Assignee: Bjoern A. Zeeb
URL:
Keywords:
Depends on:
Blocks:
 
Reported: 2020-09-26 20:29 UTC by rkoberman
Modified: 2020-11-05 15:28 UTC (History)
1 user (show)

See Also:

Attachments
Add an attachment (proposed patch, testcase, etc.)

Note You need to log in before you can comment on or make changes to this bug.
Description rkoberman 2020-09-26 20:29:04 UTC 
I am unable to install from the latest current snapshot. As soon as I tell the installation script to use rtwn, the system panics. Last known working snapshot was Sept. 3. I have not tried other install memsticks at this time.

Attached is a image of the panic. Obviously, no dump is available.

System is Lenovo L15 with Comet Lake chipset. It is currently unbootable.
Comment 1 Bjoern A. Zeeb freebsd_committer freebsd_triage 2020-09-26 22:18:26 UTC 
Please see https://reviews.freebsd.org/D26554
Comment 2 rkoberman 2020-09-27 00:22:22 UTC 
Thanks! Looks like it may do the trick. Any hope of a commit to head before the next snapshot build on Oct. 1? As I have a new system to install it on. I will need a snapshot to try it out. Then I can get back to my REAL problems with a livelock that resulted in a totally mangled file system. Never seen an fsck dump so many files into lost+found. Died during installworld and I had almost 800 new files in lost+found!
Comment 3 rkoberman 2020-09-28 22:59:12 UTC 
Looking at this more closely, I am not at all sure that this proposed patch will resolve the issue as the last change to rtwn was in the 9-3 snapshot which works, or, at least does not panic on startup. I will try to install using the em interface and, if that succeeds, patch rtwn as per D26554 and see what happens.
Comment 4 commit-hook freebsd_committer freebsd_triage 2020-09-29 20:46:41 UTC 
A commit references this bug:

Author: bz
Date: Tue Sep 29 20:46:25 UTC 2020
New revision: 366268
URL: https://svnweb.freebsd.org/changeset/base/366268

Log:
  rtwn: narrow the epoch area

  Rather than placing the epoch around the entire receive loop which
  might call into rtwn_rx_frame() and USB and sleep, split the loop
  into two[1] and leave us with one unlock/lock cycle as well.

  PR:		249925
  Reported by:	thj, (rkoberman gmail.com)
  Tested by:	thj
  Suggested by:	adrian [1]
  Reviewed by:	adrian
  MFC after:	3 days
  Sponsored by:	The FreeBSD Foundation (initially, paniced my iwl lab host)
  Differential Revision:	https://reviews.freebsd.org/D26554

Changes:
  head/sys/dev/rtwn/usb/rtwn_usb_rx.c
Comment 5 Bjoern A. Zeeb freebsd_committer freebsd_triage 2020-09-29 20:53:20 UTC 
This is not currently an issue on stable/12 (or should not be) so not tracking the MFC here;  I'll do the MFC to keep the code in sync though.

Sorry for the breakage and thanks a lot for reporting.  In case you still hit the same problem with the next snapshots or a manual test of head, then please reopen.

Lots of health,
/bz
Comment 6 commit-hook freebsd_committer freebsd_triage 2020-11-05 15:28:36 UTC 
A commit references this bug:

Author: bz
Date: Thu Nov  5 15:27:38 UTC 2020
New revision: 367385
URL: https://svnweb.freebsd.org/changeset/base/367385

Log:
  MFC r366268 (and epoch parts of r357093):

   rtwn: narrow the epoch area

    Rather than placing the epoch around the entire receive loop which
    might call into rtwn_rx_frame() and USB and sleep, split the loop
    into two and leave us with one unlock/lock cycle as well.

  PR:		249925

Changes:
_U  stable/12/
  stable/12/sys/dev/rtwn/usb/rtwn_usb_rx.c