linux-usb.vger.kernel.org archive mirror
 help / color / mirror / Atom feed
From: Alan Stern <stern@rowland.harvard.edu>
To: "M. Vefa Bicakci" <m.v.b@runbox.com>
Cc: Pany <pany@fedoraproject.org>, Bastien Nocera <hadess@hadess.net>,
	linux-usb@vger.kernel.org
Subject: Re: Bug caused by 53965c79c2db (USB: Fix device driver race)
Date: Tue, 20 Oct 2020 11:28:59 -0400	[thread overview]
Message-ID: <20201020152859.GA945128@rowland.harvard.edu> (raw)
In-Reply-To: <cf1e7059-e1d2-2e7a-89c1-0c162850fbb4@runbox.com>

On Tue, Oct 20, 2020 at 08:03:23AM -0400, M. Vefa Bicakci wrote:
> On 19/10/2020 13.40, Alan Stern wrote:
> > On Mon, Oct 19, 2020 at 09:36:00AM +0000, Pany wrote:
> > > On Sat, Oct 17, 2020 at 8:02 PM Alan Stern <stern@rowland.harvard.edu> wrote:
> > > > 
> > > > On Sat, Oct 17, 2020 at 04:07:11PM +0000, Pany wrote:
> > > > > Hi,
> > > > > 
> > > > > I installed fedora 32 into an SD card, with which I booted my Macbook.
> > > > > It had worked well before, until I upgraded the kernel from 5.8.5 to
> > > > > 5.8.6 [1].
> > > > > 
> > > > > With kernel-5.8.6-200.fc32.x86_64.rpm [2] installed, the boot process
> > > > > would be stuck at "A start job is running for
> > > > > /dev/mapper/fedora_localhost_--live-home (<time> / no limit)" (See the
> > > > > photo of screen [3]).
> > > > > 
> > > > > By appending "systemd.debug-shell=1" to the kernel cmdline, I saved
> > > > > the journal [4].
> > > > > 
> > > > > This issue has been bisected to commit
> > > > > 53965c79c2dbdc898ffc7fdbab37e920594f5e14 ("USB: Fix device driver
> > > > > race")
> > > > > 
> > > > > If I revert this commit, the kernel 5.8.6 would boot successfully.
> > > > 
> > > > This should have been fixed in 5.8.14 or 5.8.15 (5.8.14 was released on
> > > > the same day that the fix was installed; I'm not sure which came first).
> > > > At any rate it certainly should work with the most recent 5.8.y kernel.
> > > > 
> > > > Alan Stern
> > > 
> > > I tried, but neither 5.8.14 nor 5.8.15 worked for me.
> > 
> > Hmmm.  Looking at the system log you captured, it appears that the
> > problem the SD card reader's driver getting reprobed incorrectly.  The
> > details aren't clear, but the log shows the device getting probed twice,
> > once as sdb and once as sdc.  If the system tried to mount one of the
> > sdb partitions as the root, and then sdb disappeared, that could explain
> > what you see.
> > 
> > I don't know why this is happening.  But you can try adding some
> > debugging messages of your own.  In drivers/usb/core/driver.c, the
> > routine __usb_bus_reprobe_drivers() should never reach the line that
> > calls device_reprobe() unless the USBIP or apple-mfi-fastcharge driver
> > is installed -- and neither of those should be involved with the card
> > reader device.  You can add a line saying:
> > 
> > 	dev_info(dev, "new driver %s\n", new_udriver->name);
> > 
> > at that point and see what it produces in the log.
> 
> Hello all,
> 
> Sorry for my lateness!
> 
> I reviewed Pany's logs, and the issue appears to be related to the
> automatic loading of the apple-mfi-fastcharge USB driver, which triggers
> a re-probe of the SD card reader, as pointed out earlier.
> 
> This happens because the id_table of the aforementioned USB driver
> (mfi_fc_id_table) matches all USB products manufactured by Apple:
> 
>  35 static const struct usb_device_id mfi_fc_id_table[] = {
>  36         { .idVendor = APPLE_VENDOR_ID,
>  37           .match_flags = USB_DEVICE_ID_MATCH_VENDOR },
>  38         {},
>  39 };
>  ...
> 218 static struct usb_device_driver mfi_fc_driver = {
> 219         .name =         "apple-mfi-fastcharge",
> 220         .probe =        mfi_fc_probe,
> 221         .disconnect =   mfi_fc_disconnect,
> 222         .id_table =     mfi_fc_id_table,
> 223         .generic_subclass = 1,
> 224 };
> 
> 
> ... and Pany's system has multiple USB devices manufactured by Apple
> (including the SD card reader), with the vendor code 0x05ac, which is
> the value included by the id_table of the apple-mfi-fastcharge driver:
> 
> Sep 29 15:22:48 fedora.local kernel: usb 2-3: new SuperSpeed Gen 1 USB device number 2 using xhci_hcd
> Sep 29 15:22:48 fedora.local kernel: usb 2-3: New USB device found, idVendor=05ac, idProduct=8406, bcdDevice= 8.20
> Sep 29 15:22:48 fedora.local kernel: usb 2-3: New USB device strings: Mfr=3, Product=4, SerialNumber=5
> Sep 29 15:22:48 fedora.local kernel: usb 2-3: Product: Card Reader
> Sep 29 15:22:48 fedora.local kernel: usb 2-3: Manufacturer: Apple
> ...
> Sep 29 15:22:48 fedora.local kernel: usb 1-5: new full-speed USB device number 3 using xhci_hcd
> Sep 29 15:22:48 fedora.local kernel: usb 1-5: New USB device found, idVendor=05ac, idProduct=0273, bcdDevice= 6.22
> Sep 29 15:22:48 fedora.local kernel: usb 1-5: New USB device strings: Mfr=1, Product=2, SerialNumber=3
> Sep 29 15:22:48 fedora.local kernel: usb 1-5: Product: Apple Internal Keyboard / Trackpad
> Sep 29 15:22:48 fedora.local kernel: usb 1-5: Manufacturer: Apple Inc.
> ...
> 
> One way to fix this issue would be to implement a match function in the
> apple-mfi-fastcharge driver, possibly instead of an id_table, so that it
> does not match devices that it cannot bind to. This may require other
> changes in the USB core that I cannot fathom at the moment.

How about matching on the vendor ID and the product ID?  That would be 
an easy addition to the ID table.  Do the fastcharge devices have a well 
known product ID?

Alan Stern

> Pany, in the mean-time, could you add the following string to your kernel's
> command line (i.e., via GRUB, or the actual boot-loader that you use) and
> let us know whether it helps to *work around* this issue with the latest
> versions of 5.8.y kernels?
> 
> 	module_blacklist=apple-mfi-fastcharge
> 
> To emphasize, I am only suggesting this as a work-around, not as an actual
> solution.
> 
> My time is a bit limited due to having restarted full-time employment,
> but I can work on this issue during the weekend.
> 
> Thanks!
> 
> Vefa

  reply	other threads:[~2020-10-20 15:29 UTC|newest]

Thread overview: 32+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2020-10-17 16:07 Bug caused by 53965c79c2db (USB: Fix device driver race) Pany
2020-10-17 20:02 ` Alan Stern
2020-10-19  9:36   ` Pany
2020-10-19 17:40     ` Alan Stern
2020-10-20 12:03       ` M. Vefa Bicakci
2020-10-20 15:28         ` Alan Stern [this message]
2020-10-21  4:18           ` M. Vefa Bicakci
2020-10-21 11:53             ` Bastien Nocera
2020-10-21 12:02               ` Bastien Nocera
2020-10-21 12:29                 ` Alan Stern
2020-10-21 12:31                   ` Bastien Nocera
2020-10-21 13:01                 ` Bastien Nocera
2020-10-21 13:08               ` M. Vefa Bicakci
2020-10-21 13:18                 ` Bastien Nocera
2020-10-21 13:21                   ` Bastien Nocera
2020-10-21 20:11                   ` Alan Stern
2020-10-21 20:49                     ` M. Vefa Bicakci
2020-10-21 20:49                   ` M. Vefa Bicakci
2020-10-22 13:55                     ` [PATCH 0/2] Patches to prevent re-probing all Apple USB devices on apple-mfi-fastcharge load M. Vefa Bicakci
2020-10-22 13:55                       ` [PATCH 1/2] usbcore: Check both id_table and match() when both available M. Vefa Bicakci
2020-10-22 13:59                         ` M. Vefa Bicakci
     [not found]                           ` <CAHp75VeBgQ2ywLzU5PZEdfS+9M_niD0KoiEG=UMNH+4cPfsCNw@mail.gmail.com>
2020-10-23 12:51                             ` M. Vefa Bicakci
2020-10-27 14:02                         ` Bastien Nocera
2020-10-28  4:00                           ` Pany
2020-10-29  3:33                             ` M. Vefa Bicakci
2020-10-29  5:35                               ` Pany
2020-10-22 13:55                       ` [PATCH 2/2] USB: apple-mfi-fastcharge: don't probe unhandled devices M. Vefa Bicakci
2020-10-27 14:02                         ` Bastien Nocera
2020-10-28  4:01                           ` Pany
2020-10-21  3:17         ` Bug caused by 53965c79c2db (USB: Fix device driver race) Pany
2020-10-21  4:18           ` M. Vefa Bicakci
2020-10-21  5:19             ` Pany

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=20201020152859.GA945128@rowland.harvard.edu \
    --to=stern@rowland.harvard.edu \
    --cc=hadess@hadess.net \
    --cc=linux-usb@vger.kernel.org \
    --cc=m.v.b@runbox.com \
    --cc=pany@fedoraproject.org \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).