On Tue, Nov 20, 2018 at 09:39:52AM +0000, Natasha Kerensikova wrote:
> Hello,
>
> Context:
>
> I have a Thinkpad X220 with an integrated WWAN modem "Lenovo F5521gw",
> which presents itself as USB devices umodem0-2, ucom0-2, and ugen0 on
> uhub3. I don't really know whether uhub3 is part of the modem or part of
> the motherboard where the modem is plugged.
>
> In my day-to-day use of the modem, it sometimes randomly vanishes from
> the USB bus, leaving only uhub3. I never bother to find out what really
> happened, it came back by itself when I re-started pppd.
>
>
> Problem Summary:
>
> Since a recent update in CURRENT, whenever the modem disappears from
> the USB bus, I get a kernel panic.
>
> While the random vanishing are infrequent, I can reliably trigger the
> same panic when requesting hibernation (either with ampd running and
> calling ZZZ, or without ampd using the keyboard shortcut), presumably
> because hibernation somehow turns off the modem.
>
> So in effect, hibernation is now broken for me.
>
>
> Problem Details:
>
> The oldest affected version is:
> OpenBSD 6.4-current (GENERIC.MP) #446: Sat Nov 17 17:41:16 MST 2018
> [email protected]:/usr/src/sys/arch/amd64/compile/GENERIC.MP
>
> The newest non-affected version is:
> OpenBSD 6.3-current (GENERIC.MP) #91: Sat Jun 9 20:57:09 MDT 2018
> [email protected]:/usr/src/sys/arch/amd64/compile/GENERIC.MP
> (I'm not very good with regular updates on this machine, mostly because
> I don't often have network access other than the WWAN with a small data
> plan)
>
> The full panic message is:
> panic: free: size too small 16 <= 128 / 2 (0xffff80000056bc00) type USB
>
> The number above is the same in all instances, even across kernel
> re-linking and even snapshot updates.
>
> Here is a transcription of the reproducible parts of the remaining of
> the panic screen:
>
> Stopped at db_enter+0x12: popq %r11
> TID PID UID PRFLAGS PFLAGS CPU COMMAND
> <some random process which seems unrelated>
> i*?????? ????? 0 0x14000 0x200 2K usbtask
> db_enter() at db_enter+0x12
> panic() at panic+0x120
> free(<random hex>,ffff80000051c800,ffff800000565500) at free+0x3cf
> usb_free_device(0) at usb_free_device+0xf6
> usbd_detach(<random hex>,<random hex>) at usbd_detach+0x81
>
> The rest of the stack trace varies from instance to instance, but
> usb_detach is called at least from uhub_port_connect (coming from
> uhub_explore and usb_explore) or from config_detach (coming from
> uhub_detach, then another usbd_detach, and uhub_detact).
>
> In one instance (with config_detach), I checked the dmesg from ddb, and
> it ends with:
> uhub2 detached
> uhub0 detached
> ucom0 detached
> umodem0 detached
> ucom1 detached
> umodem1 detached
> ucom2 detached
> umodem2 detached
> ugen0 detached
>
> I can provide photos or transcripts of specific instances if that can
> help.
Ran into the same problem. Looks like one nsubdev assignment is
happening outside the branch where the actual allocation is performed.
With the diff below, suspend works again. Note, the diff is generated
prior to the revert for clarity.
diff --git sys/dev/usb/usb_subr.c sys/dev/usb/usb_subr.c
index 1e09fe3dd22..efa1fe9e51f 100644
--- sys/dev/usb/usb_subr.c
+++ sys/dev/usb/usb_subr.c
@@ -992,8 +992,8 @@ generic:
err = USBD_NOMEM;
goto fail;
}
+ dev->nsubdev = 2;
}
- dev->nsubdev = 2;
dev->subdevs[dev->ndevs++] = dv;
dev->subdevs[dev->ndevs] = 0;
err = USBD_NORMAL_COMPLETION;
