Re: PROBLEM: lsusb -v freezes kernel on Acer ES1-111M
Hello all, I have now installed the machine to boot Xubuntu 15.04 in UEFI mode without secure boot. It does not freeze anymore. So we can finally let this mail thread fade out. Nevertheless, a warning for those who want to try the same: it's not a smooth experience at all. After installing on the full disk, the BIOS/UEFI reported that there is no bootable device. I booted from the live USB stick again and ran the boot-repair tool from the live session. This fixed the matter, after a fashion. When booting, I now get: 1. a warning that the default boot device is missing and that I should insert a recovery disk (I have none) [select OK, there is no other option] 2. a boot selection with options "Unnamed device" and "Windows Boot Manager" (there is no Windows on the machine) [select "Unnamed device"] 3. the Grub menu, finally Attempts to improve matters with 'efibootmgr' were futile. This will have to do for a while. cheers, Roland -- To unsubscribe from this list: send the line "unsubscribe linux-usb" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: PROBLEM: lsusb -v freezes kernel on Acer ES1-111M
Hi Alan, > (I still think it's the BIOS's fault.) You're spot on, and the keyboard doesn't have enough special characters to express my feelings. (@$#!§*) I created a bootable USB stick with the Xubuntu 15.04 installer. When booting in legacy BIOS mode... > lspci 00:00.0 Host bridge: Intel Corporation Atom Processor Z36xxx/Z37xxx Series SoC Transaction Register (rev 0e) 00:02.0 VGA compatible controller: Intel Corporation Atom Processor Z36xxx/Z37xxx Series Graphics & Display (rev 0e) 00:12.0 SD Host controller: Intel Corporation Atom Processor Z36xxx/Z37xxx Series SDIO Controller (rev 0e) 00:14.0 USB controller: Intel Corporation Atom Processor Z36xxx/Z37xxx Series USB xHCI (rev 0e) 00:17.0 SD Host controller: Intel Corporation Device 0f50 (rev 0e) 00:1a.0 Encryption controller: Intel Corporation Atom Processor Z36xxx/Z37xxx Series Trusted Execution Engine (rev 0e) 00:1b.0 Audio device: Intel Corporation Atom Processor Z36xxx/Z37xxx Series High Definition Audio Controller (rev 0e) 00:1c.0 PCI bridge: Intel Corporation Device 0f48 (rev 0e) 00:1c.1 PCI bridge: Intel Corporation Device 0f4a (rev 0e) 00:1c.2 PCI bridge: Intel Corporation Device 0f4c (rev 0e) 00:1d.0 USB controller: Intel Corporation Atom Processor Z36xxx/Z37xxx Series USB EHCI (rev 0e) 00:1f.0 ISA bridge: Intel Corporation Atom Processor Z36xxx/Z37xxx Series Power Control Unit (rev 0e) 00:1f.3 SMBus: Intel Corporation Device 0f12 (rev 0e) 02:00.0 Network controller: Qualcomm Atheros QCA9565 / AR9565 Wireless Network Adapter (rev 01) 03:00.0 Ethernet controller: Realtek Semiconductor Co., Ltd. RTL8111/8168/8411 PCI Express Gigabit Ethernet Controller (rev 0c) and the machine freezes. When booting in UEFI mode (insecure)... > lspci 00:00.0 Host bridge: Intel Corporation Atom Processor Z36xxx/Z37xxx Series SoC Transaction Register (rev 0e) 00:02.0 VGA compatible controller: Intel Corporation Atom Processor Z36xxx/Z37xxx Series Graphics & Display (rev 0e) 00:14.0 USB controller: Intel Corporation Atom Processor Z36xxx/Z37xxx Series USB xHCI (rev 0e) 00:1a.0 Encryption controller: Intel Corporation Atom Processor Z36xxx/Z37xxx Series Trusted Execution Engine (rev 0e) 00:1b.0 Audio device: Intel Corporation Atom Processor Z36xxx/Z37xxx Series High Definition Audio Controller (rev 0e) 00:1c.0 PCI bridge: Intel Corporation Device 0f48 (rev 0e) 00:1c.1 PCI bridge: Intel Corporation Device 0f4a (rev 0e) 00:1c.2 PCI bridge: Intel Corporation Device 0f4c (rev 0e) 00:1f.0 ISA bridge: Intel Corporation Atom Processor Z36xxx/Z37xxx Series Power Control Unit (rev 0e) 00:1f.3 SMBus: Intel Corporation Device 0f12 (rev 0e) 02:00.0 Network controller: Qualcomm Atheros QCA9565 / AR9565 Wireless Network Adapter (rev 01) 03:00.0 Ethernet controller: Realtek Semiconductor Co., Ltd. RTL8111/8168/8411 PCI Express Gigabit Ethernet Controller (rev 0c) and the machine does not freeze. The device 00:1d.0 which caused my problem has simply vanished, along with 00:12.0 and 00:17.0. Apparently, there's some unused hardware in the machine and Acer decided to hide it from the OS in UEFI mode, but didn't bother to do the same in legacy BIOS mode. Or maybe BIOS doesn't support such behavior. I'll try the upcoming re-installation in UEFI mode. And if it goes as I hope, I won't be able to trigger the freeze anymore. It'd be kind of an unsatisfactory ending to a months-long wild goose chase. But the simplest solution might turn out to be telling people not to use legacy BIOS mode on this machine. I'll wait with the installation until Sunday morning, just in case you or somebody else would like me to gather some more information in BIOS mode. And of course I'll report the outcome of the installation. thanks for all your efforts, Roland -- To unsubscribe from this list: send the line "unsubscribe linux-usb" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: PROBLEM: lsusb -v freezes kernel on Acer ES1-111M
On Fri, 25 Sep 2015, Roland Weber wrote: > Hi Alan, > > > (I still think it's the BIOS's fault.) > > You're spot on, and the keyboard doesn't have enough special characters > to express my feelings. (@$#!§*) > > I created a bootable USB stick with the Xubuntu 15.04 installer. > When booting in legacy BIOS mode... > > > lspci > 00:00.0 Host bridge: Intel Corporation Atom Processor Z36xxx/Z37xxx Series > SoC Transaction Register (rev 0e) > 00:02.0 VGA compatible controller: Intel Corporation Atom Processor > Z36xxx/Z37xxx Series Graphics & Display (rev 0e) > 00:12.0 SD Host controller: Intel Corporation Atom Processor Z36xxx/Z37xxx > Series SDIO Controller (rev 0e) > 00:14.0 USB controller: Intel Corporation Atom Processor Z36xxx/Z37xxx Series > USB xHCI (rev 0e) > 00:17.0 SD Host controller: Intel Corporation Device 0f50 (rev 0e) > 00:1a.0 Encryption controller: Intel Corporation Atom Processor Z36xxx/Z37xxx > Series Trusted Execution Engine (rev 0e) > 00:1b.0 Audio device: Intel Corporation Atom Processor Z36xxx/Z37xxx Series > High Definition Audio Controller (rev 0e) > 00:1c.0 PCI bridge: Intel Corporation Device 0f48 (rev 0e) > 00:1c.1 PCI bridge: Intel Corporation Device 0f4a (rev 0e) > 00:1c.2 PCI bridge: Intel Corporation Device 0f4c (rev 0e) > 00:1d.0 USB controller: Intel Corporation Atom Processor Z36xxx/Z37xxx Series > USB EHCI (rev 0e) > 00:1f.0 ISA bridge: Intel Corporation Atom Processor Z36xxx/Z37xxx Series > Power Control Unit (rev 0e) > 00:1f.3 SMBus: Intel Corporation Device 0f12 (rev 0e) > 02:00.0 Network controller: Qualcomm Atheros QCA9565 / AR9565 Wireless > Network Adapter (rev 01) > 03:00.0 Ethernet controller: Realtek Semiconductor Co., Ltd. > RTL8111/8168/8411 PCI Express Gigabit Ethernet Controller (rev 0c) > > and the machine freezes. > When booting in UEFI mode (insecure)... > > > lspci > 00:00.0 Host bridge: Intel Corporation Atom Processor Z36xxx/Z37xxx Series > SoC Transaction Register (rev 0e) > 00:02.0 VGA compatible controller: Intel Corporation Atom Processor > Z36xxx/Z37xxx Series Graphics & Display (rev 0e) > 00:14.0 USB controller: Intel Corporation Atom Processor Z36xxx/Z37xxx Series > USB xHCI (rev 0e) > 00:1a.0 Encryption controller: Intel Corporation Atom Processor Z36xxx/Z37xxx > Series Trusted Execution Engine (rev 0e) > 00:1b.0 Audio device: Intel Corporation Atom Processor Z36xxx/Z37xxx Series > High Definition Audio Controller (rev 0e) > 00:1c.0 PCI bridge: Intel Corporation Device 0f48 (rev 0e) > 00:1c.1 PCI bridge: Intel Corporation Device 0f4a (rev 0e) > 00:1c.2 PCI bridge: Intel Corporation Device 0f4c (rev 0e) > 00:1f.0 ISA bridge: Intel Corporation Atom Processor Z36xxx/Z37xxx Series > Power Control Unit (rev 0e) > 00:1f.3 SMBus: Intel Corporation Device 0f12 (rev 0e) > 02:00.0 Network controller: Qualcomm Atheros QCA9565 / AR9565 Wireless > Network Adapter (rev 01) > 03:00.0 Ethernet controller: Realtek Semiconductor Co., Ltd. > RTL8111/8168/8411 PCI Express Gigabit Ethernet Controller (rev 0c) > > and the machine does not freeze. The device 00:1d.0 which caused my problem > has simply vanished, along with 00:12.0 and 00:17.0. Apparently, there's > some unused hardware in the machine and Acer decided to hide it from the OS > in UEFI mode, but didn't bother to do the same in legacy BIOS mode. Or maybe > BIOS doesn't support such behavior. Amazing! > I'll try the upcoming re-installation in UEFI mode. And if it goes as I hope, > I won't be able to trigger the freeze anymore. It'd be kind of an > unsatisfactory > ending to a months-long wild goose chase. But the simplest solution might > turn out to be telling people not to use legacy BIOS mode on this machine. > > I'll wait with the installation until Sunday morning, just in case you or > somebody else would like me to gather some more information in BIOS mode. > And of course I'll report the outcome of the installation. Okay. I don't have any other requests for now. > thanks for all your efforts, You're the one who did all the work. Go ahead and pat yourself on the back. :-) Alan Stern -- To unsubscribe from this list: send the line "unsubscribe linux-usb" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: PROBLEM: lsusb -v freezes kernel on Acer ES1-111M
Hi Alan, > > Frankly, I don't dare to upgrade the BIOS right now. > > All right. Maybe at some point in the future. The thing is, I don't > want to patch the kernel only to find that the problem has already been > fixed in a newer BIOS. Fair enough. I'll see if I can make time for setting things up over the next few weeks. Andrew's report on this matter is encouraging. > The unavoidable conclusion is that your system doesn't work right when > this root hub is suspended. (I still think it's the BIOS's fault.) I've been using the machine in legacy BIOS mode ever since I wasted three days trying to get an installed Linux booting in UEFI mode. I'm planning a clean installation anyway, this weekend or early next week. I'll give UEFI mode (without secure boot) another chance. Maybe it works when I get rid of the factory boot entries in that menu. At the very least, I can boot a Linux live disk with UEFI to see if that one freezes, and what the EHCI registers have to say. > Which suggests yet another test: Under a kernel with CONFIG_PM and > CONFIG_PM_SLEEP enabled, what happens when you suspend the system > (i.e., suspend-to-RAM) and then wake it up? Well, there's the second big problem I have with the machine. It has an eMMC rather than a real hard disk or SSD. AIUI, the Linux MMC driver has no way of distinguishing removable from non-removable MMC media. So it treats all MMC as removable and expects that the disk contents may have changed while it was asleep. Kind of an unmount on sleep or so. Which means that when the machine wakes up, the root filesystem is gone. IIRC, it did wake up but then hung up when I entered a command. It's been a while since I tried. There is a boot parameter to tell the MMC driver that all media are to be treated as non-removable. I gave it a try back then and it didn't work. But I'll give it another try a.s.a.p. Maybe I just had the prefix wrong. Thanks a lot, Alan. I'll provide more information as soon as I can gather it. cheers, Roland -- To unsubscribe from this list: send the line "unsubscribe linux-usb" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: PROBLEM: lsusb -v freezes kernel on Acer ES1-111M
Hello Andrew, > ES1-111M running BIOS v1.13 and have had no problems booting from an > external USB stick to install Debian (using legacy mode -- I haven't > tried UEFI). It also worked fine under v1.10 (factory-installed). Thanks, that's good to know. Btw, I'm also using legacy mode. Maybe I should try UEFI to see if it makes a difference. > Thanks so much to you all for looking into the USB issues on this > system. My own 111M freezes at shutdown if 'noapic' is not specified on > the (stock Debian 3.16.0-4) kernel command line and throws all sorts of > EHCI errors otherwise so I look forward to the results of your efforts > in due time. The feeling that I might be the only one in the world having this kind of problem with this model has been nagging at me for a while. Thanks for letting me know that there are others. cheers, Roland -- To unsubscribe from this list: send the line "unsubscribe linux-usb" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: PROBLEM: lsusb -v freezes kernel on Acer ES1-111M
On 22/09/2015 22:25, Roland Weber wrote: But there's also a guy who reports that external USB drives are no longer detected during boot after he updated the BIOS to v1.10. http://community.acer.com/t5/E-and-M-Series/Acer-ES1-111M-doesn-t-detect-USB-Drives-at-boot-phase-anymore/td-p/364139 Frankly, I don't dare to upgrade the BIOS right now. I need the machine in working condition starting Friday next week, until around Christmas. Hi Roland, I totally understand your reluctance to update the BIOS at such a critical time (and mid-debugging) but just to let you know: I have an ES1-111M running BIOS v1.13 and have had no problems booting from an external USB stick to install Debian (using legacy mode -- I haven't tried UEFI). It also worked fine under v1.10 (factory-installed). Thanks so much to you all for looking into the USB issues on this system. My own 111M freezes at shutdown if 'noapic' is not specified on the (stock Debian 3.16.0-4) kernel command line and throws all sorts of EHCI errors otherwise so I look forward to the results of your efforts in due time. Best regards, Andrew -- To unsubscribe from this list: send the line "unsubscribe linux-usb" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: PROBLEM: lsusb -v freezes kernel on Acer ES1-111M
On Tue, 22 Sep 2015, Roland Weber wrote:
> Hi Alan,
>
> > Did you turn off the computer before booting these kernels (i.e., a
> > "cold" boot) or did you reboot when the machine was already running (a
> > "warm" boot)?
>
> I didn't pay attention to that. Most likely, I prepared the debug session
> on 3.17.8, warm-booted into kernel-f, froze the machine, then cold-booted
> into kernel-g.
> Now I tried again, making sure to cold-boot into both kernels. The
> differences you noticed are gone, both -f and -g behave as listed for -g.
> See below for the full output. And -f still freezes, while -g does not.
>
> > Here's the corresponding part of the -g kernel log:
> >
> > > [1.017430] pci :00:02.0: Video device with shadowed ROM
> > > [1.017971] PCI: CLS 64 bytes, default 64
> [...]
> > and for the -g kernel:
> >
> > > /sys/kernel/debug/usb/ehci/:00:1d.0/registers now contains:
> > > bus pci, device :00:1d.0
> > > EHCI Host Controller
> > > EHCI 1.00, rh state running
> > > ownership 0001
Okay. This value for ownership is still wrong, though.
> > Have you checked to see if any BIOS updates are available?
>
> The machine is on v1.08, there have been two updates since:
> v1.13: 1. add Elan touchpad support
>2. update EC to v1.5
> v1.10: 1. Add battery ID
>
> But there's also a guy who reports that external USB drives are
> no longer detected during boot after he updated the BIOS to v1.10.
> http://community.acer.com/t5/E-and-M-Series/Acer-ES1-111M-doesn-t-detect-USB-Drives-at-boot-phase-anymore/td-p/364139
>
> Frankly, I don't dare to upgrade the BIOS right now. I need the
> machine in working condition starting Friday next week, until
> around Christmas. I'll be teaching lectures once a week and bought
> the machine to drive the projector. Most of my spare time will be
> consumed by preparing the lectures for the next three months.
> If the machine stops booting from external USB devices, I couldn't
> reinstall it anymore, nor could I flash a fixed BIOS. I'll have
> to set up dual boot with Linux and FreeDOS before I can risk a
> BIOS upgrade. Currently, that doesn't fit into my time budget.
All right. Maybe at some point in the future. The thing is, I don't
want to patch the kernel only to find that the problem has already been
fixed in a newer BIOS.
> > there are a few other thing you can try. Under a kernel with
> > CONFIG_PM enabled, before unbinding the driver try doing:
> >
> > echo on >/sys/bus/pci/devices/:00:1d.0/usb3/power/control
> >
> > That alone might cause the system to freeze
>
> It does. I tried with kernel-f and got two lines of output:
> usb usb3: usb auto-resume
> ehci-pci :00:1d.0: resume root hub
> (freeze)
>
> > Here's another experiment. At the start of ehci_halt(), before the
> > spin_lock_irq(), add this:
> >
> > if (ehci->rh_state == EHCI_RH_SUSPENDED) {
> // I added a printk here
> > ehci_writel(ehci, CMD_RUN, >regs->command);
> > msleep(10);
> > }
> >
> > This may end up doing about the same thing as the previous test.
>
> It does. The last few lines of the debug output are:
> ehci_halt: entry
> ehci_halt: EHCI_RH_SUSPENDED, running patch writel
> ehci_halt: about to readl prematurely
> (freeze)
The unavoidable conclusion is that your system doesn't work right when
this root hub is suspended. (I still think it's the BIOS's fault.)
Which suggests yet another test: Under a kernel with CONFIG_PM and
CONFIG_PM_SLEEP enabled, what happens when you suspend the system
(i.e., suspend-to-RAM) and then wake it up? For this experiment, it
may help to add "no_console_suspend" to the boot command line.
Alan Stern
--
To unsubscribe from this list: send the line "unsubscribe linux-usb" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: PROBLEM: lsusb -v freezes kernel on Acer ES1-111M
Hi Alan,
> Did you turn off the computer before booting these kernels (i.e., a
> "cold" boot) or did you reboot when the machine was already running (a
> "warm" boot)?
I didn't pay attention to that. Most likely, I prepared the debug session
on 3.17.8, warm-booted into kernel-f, froze the machine, then cold-booted
into kernel-g.
Now I tried again, making sure to cold-boot into both kernels. The
differences you noticed are gone, both -f and -g behave as listed for -g.
See below for the full output. And -f still freezes, while -g does not.
> Here's the corresponding part of the -g kernel log:
>
> > [1.017430] pci :00:02.0: Video device with shadowed ROM
> > [1.017971] PCI: CLS 64 bytes, default 64
[...]
> and for the -g kernel:
>
> > /sys/kernel/debug/usb/ehci/:00:1d.0/registers now contains:
> > bus pci, device :00:1d.0
> > EHCI Host Controller
> > EHCI 1.00, rh state running
> > ownership 0001
> Have you checked to see if any BIOS updates are available?
The machine is on v1.08, there have been two updates since:
v1.13: 1. add Elan touchpad support
2. update EC to v1.5
v1.10: 1. Add battery ID
But there's also a guy who reports that external USB drives are
no longer detected during boot after he updated the BIOS to v1.10.
http://community.acer.com/t5/E-and-M-Series/Acer-ES1-111M-doesn-t-detect-USB-Drives-at-boot-phase-anymore/td-p/364139
Frankly, I don't dare to upgrade the BIOS right now. I need the
machine in working condition starting Friday next week, until
around Christmas. I'll be teaching lectures once a week and bought
the machine to drive the projector. Most of my spare time will be
consumed by preparing the lectures for the next three months.
If the machine stops booting from external USB devices, I couldn't
reinstall it anymore, nor could I flash a fixed BIOS. I'll have
to set up dual boot with Linux and FreeDOS before I can risk a
BIOS upgrade. Currently, that doesn't fit into my time budget.
> there are a few other thing you can try. Under a kernel with
> CONFIG_PM enabled, before unbinding the driver try doing:
>
> echo on >/sys/bus/pci/devices/:00:1d.0/usb3/power/control
>
> That alone might cause the system to freeze
It does. I tried with kernel-f and got two lines of output:
usb usb3: usb auto-resume
ehci-pci :00:1d.0: resume root hub
(freeze)
> Here's another experiment. At the start of ehci_halt(), before the
> spin_lock_irq(), add this:
>
> if (ehci->rh_state == EHCI_RH_SUSPENDED) {
// I added a printk here
> ehci_writel(ehci, CMD_RUN, >regs->command);
> msleep(10);
> }
>
> This may end up doing about the same thing as the previous test.
It does. The last few lines of the debug output are:
ehci_halt: entry
ehci_halt: EHCI_RH_SUSPENDED, running patch writel
ehci_halt: about to readl prematurely
(freeze)
thanks and cheers,
Roland
=== kernel-f with cold boot ===
[0.00] Initializing cgroup subsys cpuset
[0.00] Initializing cgroup subsys cpu
[0.00] Initializing cgroup subsys cpuacct
[0.00] Linux version 4.2.0-f (rweber@Nightwing) (gcc version 4.9.2
(Ubuntu 4.9.2-10ubuntu13) ) #37 SMP Sat Sep 19 01:53:51 CEST 2015
[0.00] Command line: BOOT_IMAGE=/boot/vmlinuz-4.2.0-f
root=UUID=b8872e03-7295-4cbd-ac86-06b9be2f112f ro debug systemd.log_target=null
quiet splash crashkernel=384M-:128M vt.handoff=7
[0.00] KERNEL supported cpus:
[0.00] Intel GenuineIntel
[0.00] x86/fpu: Legacy x87 FPU detected.
[0.00] x86/fpu: Using 'lazy' FPU context switches.
[0.00] e820: BIOS-provided physical RAM map:
[0.00] BIOS-e820: [mem 0x-0x0009e7ff] usable
[0.00] BIOS-e820: [mem 0x0009e800-0x0009] reserved
[0.00] BIOS-e820: [mem 0x000e-0x000f] reserved
[0.00] BIOS-e820: [mem 0x0010-0x1eff] usable
[0.00] BIOS-e820: [mem 0x1f00-0x1f0f] reserved
[0.00] BIOS-e820: [mem 0x1f10-0x1fff] usable
[0.00] BIOS-e820: [mem 0x2000-0x200f] reserved
[0.00] BIOS-e820: [mem 0x2010-0x781acfff] usable
[0.00] BIOS-e820: [mem 0x781ad000-0x787acfff] reserved
[0.00] BIOS-e820: [mem 0x787ad000-0x788acfff] ACPI NVS
[0.00] BIOS-e820: [mem 0x788ad000-0x788ecfff] ACPI data
[0.00] BIOS-e820: [mem 0x788ed000-0x794c5fff] usable
[0.00] BIOS-e820: [mem 0x794c6000-0x79dc5fff] ACPI NVS
[0.00] BIOS-e820: [mem 0x79dc6000-0x79ff] usable
[0.00] BIOS-e820: [mem 0x7a00-0x7a7f] reserved
[0.00] BIOS-e820: [mem 0x7ae0-0x7fff] reserved
[0.00] BIOS-e820: [mem 0xe000-0xe3ff] reserved
[
Re: PROBLEM: lsusb -v freezes kernel on Acer ES1-111M
Hi Alan, > Assuming things work out as expected, try this: In core/hub.c, remove > the calls to usb_enable_autosuspend(hdev) in hub_probe() and leave > CONFIG_PM enabled. This one does not freeze! cheers, Roland [0.00] Initializing cgroup subsys cpuset [0.00] Initializing cgroup subsys cpu [0.00] Initializing cgroup subsys cpuacct [0.00] Linux version 4.2.0-j (rweber@Nightwing) (gcc version 4.9.2 (Ubuntu 4.9.2-10ubuntu13) ) #39 SMP Sun Sep 20 22:21:01 CEST 2015 [0.00] Command line: BOOT_IMAGE=/boot/vmlinuz-4.2.0-j root=UUID=b8872e03-7295-4cbd-ac86-06b9be2f112f ro debug systemd.log_target=null quiet splash crashkernel=384M-:128M vt.handoff=7 [0.00] KERNEL supported cpus: [0.00] Intel GenuineIntel [0.00] x86/fpu: Legacy x87 FPU detected. [0.00] x86/fpu: Using 'lazy' FPU context switches. [0.00] e820: BIOS-provided physical RAM map: [0.00] BIOS-e820: [mem 0x-0x0009e7ff] usable [0.00] BIOS-e820: [mem 0x0009e800-0x0009] reserved [0.00] BIOS-e820: [mem 0x000e-0x000f] reserved [0.00] BIOS-e820: [mem 0x0010-0x1eff] usable [0.00] BIOS-e820: [mem 0x1f00-0x1f0f] reserved [0.00] BIOS-e820: [mem 0x1f10-0x1fff] usable [0.00] BIOS-e820: [mem 0x2000-0x200f] reserved [0.00] BIOS-e820: [mem 0x2010-0x781acfff] usable [0.00] BIOS-e820: [mem 0x781ad000-0x787acfff] reserved [0.00] BIOS-e820: [mem 0x787ad000-0x788acfff] ACPI NVS [0.00] BIOS-e820: [mem 0x788ad000-0x788ecfff] ACPI data [0.00] BIOS-e820: [mem 0x788ed000-0x794c5fff] usable [0.00] BIOS-e820: [mem 0x794c6000-0x79dc5fff] ACPI NVS [0.00] BIOS-e820: [mem 0x79dc6000-0x79ff] usable [0.00] BIOS-e820: [mem 0x7a00-0x7a7f] reserved [0.00] BIOS-e820: [mem 0x7ae0-0x7fff] reserved [0.00] BIOS-e820: [mem 0xe000-0xe3ff] reserved [0.00] BIOS-e820: [mem 0xfec0-0xfec00fff] reserved [0.00] BIOS-e820: [mem 0xfed01000-0xfed01fff] reserved [0.00] BIOS-e820: [mem 0xfed03000-0xfed03fff] reserved [0.00] BIOS-e820: [mem 0xfed08000-0xfed08fff] reserved [0.00] BIOS-e820: [mem 0xfed0c000-0xfed0] reserved [0.00] BIOS-e820: [mem 0xfed1c000-0xfed1cfff] reserved [0.00] BIOS-e820: [mem 0xfee0-0xfee00fff] reserved [0.00] BIOS-e820: [mem 0xfef0-0xfeff] reserved [0.00] BIOS-e820: [mem 0xffc0-0x] reserved [0.00] NX (Execute Disable) protection: active [0.00] SMBIOS 2.7 present. [0.00] DMI: Acer Aspire ES1-111M/R2, BIOS V1.08 08/20/2014 [0.00] e820: update [mem 0x-0x0fff] usable ==> reserved [0.00] e820: remove [mem 0x000a-0x000f] usable [0.00] e820: last_pfn = 0x7a000 max_arch_pfn = 0x4 [0.00] MTRR default type: uncachable [0.00] MTRR fixed ranges enabled: [0.00] 0-9 write-back [0.00] A-B uncachable [0.00] C-F write-protect [0.00] MTRR variable ranges enabled: [0.00] 0 base 0FFC0 mask FFFC0 write-protect [0.00] 1 base 0 mask F8000 write-back [0.00] 2 base 07C00 mask FFC00 uncachable [0.00] 3 base 07B00 mask FFF00 uncachable [0.00] 4 base 07AE0 mask FFFE0 uncachable [0.00] 5 disabled [0.00] 6 disabled [0.00] 7 disabled [0.00] x86/PAT: Configuration [0-7]: WB WC UC- UC WB WC UC- WT [0.00] Scanning 1 areas for low memory corruption [0.00] Base memory trampoline at [88098000] 98000 size 24576 [0.00] init_memory_mapping: [mem 0x-0x000f] [0.00] [mem 0x-0x000f] page 4k [0.00] BRK [0x13faa000, 0x13faafff] PGTABLE [0.00] BRK [0x13fab000, 0x13fabfff] PGTABLE [0.00] BRK [0x13fac000, 0x13facfff] PGTABLE [0.00] init_memory_mapping: [mem 0x79e0-0x79ff] [0.00] [mem 0x79e0-0x79ff] page 2M [0.00] BRK [0x13fad000, 0x13fadfff] PGTABLE [0.00] init_memory_mapping: [mem 0x6000-0x781acfff] [0.00] [mem 0x6000-0x77ff] page 2M [0.00] [mem 0x7800-0x781acfff] page 4k [0.00] BRK [0x13fae000, 0x13faefff] PGTABLE [0.00] init_memory_mapping: [mem 0x788ed000-0x794c5fff] [0.00] [mem 0x788ed000-0x789f] page 4k [0.00] [mem
Re: PROBLEM: lsusb -v freezes kernel on Acer ES1-111M
On Sun, 20 Sep 2015, Roland Weber wrote:
> Hi Alan, hi all,
>
> in my previous mail, I wrote:
> > With "make menuconfig", I haven't been able to switch off the
> > setting, because CONFIG_PM_SLEEP and something else forces it on
>
> For the records, there are no menu entries for CONFIG_PM_SLEEP
> and CONFIG_HIBERNATE_CALLBACKS. Those are enabled implicitly.
> I had to disable "Linux guest support" within section
> "Processor types and features" to switch off CONFIG_PM.
>
> I've now compiled two 4.2 kernels with extra debug output:
> -f: CONFIG_PM enabled, the kernel freezes on unbind
> -g: CONFIG_PM disabled, the kernel does not freeze
> I also compiled two other 4.2 kernels where I replaced the
> alloc_workqueue with alloc_ordered_workqueue. That undoes
> the change from 3.17 to 3.18 which unearthed the problem.
> However, those two kernels behave no differently from the
> two above. Apparently, there have been other changes since
> 3.18 which also result in the revised order of initialization.
> I don't plan to pursue that legacy route any longer.
>
> I've put ehci_info statements in ehci_suspend and ehci_resume,
> but there's no output from them. See below for details. Next,
> I'll try to remove the usb_enable_autosuspend(hdev) calls.
>
> cheers and thanks,
> Roland
>
> = kernel -f, the one which freezes =
Did you turn off the computer before booting these kernels (i.e., a
"cold" boot) or did you reboot when the machine was already running (a
"warm" boot)?
It may make a difference. I'm beginning to suspect the problem is
caused by the BIOS. Have you checked to see if any BIOS updates are
available?
Here's a significant part of the -f kernel log:
> [1.012653] pci :00:02.0: Video device with shadowed ROM
> [2.613000] pci :00:1d.0: EHCI: BIOS handoff failed (BIOS bug?)
> 01010001
> [2.613126] PCI: CLS 64 bytes, default 64
Here's the corresponding part of the -g kernel log:
> [1.017430] pci :00:02.0: Video device with shadowed ROM
> [1.017971] PCI: CLS 64 bytes, default 64
See the difference? A similarly relevant difference shows up in the
"registers" file. For the -f kernel:
> /sys/kernel/debug/usb/ehci/:00:1d.0/registers now contains:
> bus pci, device :00:1d.0
> EHCI Host Controller
> EHCI 1.00, rh state suspended
> ownership 0101 linux
and for the -g kernel:
> /sys/kernel/debug/usb/ehci/:00:1d.0/registers now contains:
> bus pci, device :00:1d.0
> EHCI Host Controller
> EHCI 1.00, rh state running
> ownership 0001
The difference in "rh state" is caused by the CONFIG_PM change. But
the difference in the ownership values is a direct consequence of the
BIOS's behavior.
If there is no BIOS update for you to install, or if it still doesn't
work, there are a few other thing you can try. Under a kernel with
CONFIG_PM enabled, before unbinding the driver try doing:
echo on >/sys/bus/pci/devices/:00:1d.0/usb3/power/control
That alone might cause the system to freeze, but if it doesn't then
there's a good chance the unbind and shutdown won't either.
Here's another experiment. At the start of ehci_halt(), before the
spin_lock_irq(), add this:
if (ehci->rh_state == EHCI_RH_SUSPENDED) {
ehci_writel(ehci, CMD_RUN, >regs->command);
msleep(10);
}
This may end up doing about the same thing as the previous test. Let's
see.
Alan Stern
--
To unsubscribe from this list: send the line "unsubscribe linux-usb" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: PROBLEM: lsusb -v freezes kernel on Acer ES1-111M
Hi Alan, hi all, in my previous mail, I wrote: > With "make menuconfig", I haven't been able to switch off the > setting, because CONFIG_PM_SLEEP and something else forces it on For the records, there are no menu entries for CONFIG_PM_SLEEP and CONFIG_HIBERNATE_CALLBACKS. Those are enabled implicitly. I had to disable "Linux guest support" within section "Processor types and features" to switch off CONFIG_PM. I've now compiled two 4.2 kernels with extra debug output: -f: CONFIG_PM enabled, the kernel freezes on unbind -g: CONFIG_PM disabled, the kernel does not freeze I also compiled two other 4.2 kernels where I replaced the alloc_workqueue with alloc_ordered_workqueue. That undoes the change from 3.17 to 3.18 which unearthed the problem. However, those two kernels behave no differently from the two above. Apparently, there have been other changes since 3.18 which also result in the revised order of initialization. I don't plan to pursue that legacy route any longer. I've put ehci_info statements in ehci_suspend and ehci_resume, but there's no output from them. See below for details. Next, I'll try to remove the usb_enable_autosuspend(hdev) calls. cheers and thanks, Roland = kernel -f, the one which freezes = [0.00] Initializing cgroup subsys cpuset [0.00] Initializing cgroup subsys cpu [0.00] Initializing cgroup subsys cpuacct [0.00] Linux version 4.2.0-f (rweber@Nightwing) (gcc version 4.9.2 (Ubuntu 4.9.2-10ubuntu13) ) #37 SMP Sat Sep 19 01:53:51 CEST 2015 [0.00] Command line: BOOT_IMAGE=/boot/vmlinuz-4.2.0-f root=UUID=b8872e03-7295-4cbd-ac86-06b9be2f112f ro debug systemd.log_target=null quiet splash crashkernel=384M-:128M vt.handoff=7 [0.00] KERNEL supported cpus: [0.00] Intel GenuineIntel [0.00] x86/fpu: Legacy x87 FPU detected. [0.00] x86/fpu: Using 'lazy' FPU context switches. [0.00] e820: BIOS-provided physical RAM map: [0.00] BIOS-e820: [mem 0x-0x0009e7ff] usable [0.00] BIOS-e820: [mem 0x0009e800-0x0009] reserved [0.00] BIOS-e820: [mem 0x000e-0x000f] reserved [0.00] BIOS-e820: [mem 0x0010-0x1eff] usable [0.00] BIOS-e820: [mem 0x1f00-0x1f0f] reserved [0.00] BIOS-e820: [mem 0x1f10-0x1fff] usable [0.00] BIOS-e820: [mem 0x2000-0x200f] reserved [0.00] BIOS-e820: [mem 0x2010-0x781acfff] usable [0.00] BIOS-e820: [mem 0x781ad000-0x787acfff] reserved [0.00] BIOS-e820: [mem 0x787ad000-0x788acfff] ACPI NVS [0.00] BIOS-e820: [mem 0x788ad000-0x788ecfff] ACPI data [0.00] BIOS-e820: [mem 0x788ed000-0x794c5fff] usable [0.00] BIOS-e820: [mem 0x794c6000-0x79dc5fff] ACPI NVS [0.00] BIOS-e820: [mem 0x79dc6000-0x79ff] usable [0.00] BIOS-e820: [mem 0x7a00-0x7a7f] reserved [0.00] BIOS-e820: [mem 0x7ae0-0x7fff] reserved [0.00] BIOS-e820: [mem 0xe000-0xe3ff] reserved [0.00] BIOS-e820: [mem 0xfec0-0xfec00fff] reserved [0.00] BIOS-e820: [mem 0xfed01000-0xfed01fff] reserved [0.00] BIOS-e820: [mem 0xfed03000-0xfed03fff] reserved [0.00] BIOS-e820: [mem 0xfed08000-0xfed08fff] reserved [0.00] BIOS-e820: [mem 0xfed0c000-0xfed0] reserved [0.00] BIOS-e820: [mem 0xfed1c000-0xfed1cfff] reserved [0.00] BIOS-e820: [mem 0xfee0-0xfee00fff] reserved [0.00] BIOS-e820: [mem 0xfef0-0xfeff] reserved [0.00] BIOS-e820: [mem 0xffc0-0x] reserved [0.00] NX (Execute Disable) protection: active [0.00] SMBIOS 2.7 present. [0.00] DMI: Acer Aspire ES1-111M/R2, BIOS V1.08 08/20/2014 [0.00] e820: update [mem 0x-0x0fff] usable ==> reserved [0.00] e820: remove [mem 0x000a-0x000f] usable [0.00] e820: last_pfn = 0x7a000 max_arch_pfn = 0x4 [0.00] MTRR default type: uncachable [0.00] MTRR fixed ranges enabled: [0.00] 0-9 write-back [0.00] A-B uncachable [0.00] C-F write-protect [0.00] MTRR variable ranges enabled: [0.00] 0 base 0FFC0 mask FFFC0 write-protect [0.00] 1 base 0 mask F8000 write-back [0.00] 2 base 07C00 mask FFC00 uncachable [0.00] 3 base 07B00 mask FFF00 uncachable [0.00] 4 base 07AE0 mask FFFE0 uncachable [0.00] 5 disabled [0.00] 6 disabled [0.00] 7
Re: PROBLEM: lsusb -v freezes kernel on Acer ES1-111M
Hi Alan, > However, note that CONFIG_PM_RUNTIME doesn't exist any more in 4.2; it > is now covered by CONFIG_PM. That explains why the setting was disabled in the first place. I had taken a config from 4.2 and ran "make oldconfig" on it with the 3.17 kernel. Actually, the configurations with CONFIG_PM_RUNTIME disabled give me warnings about some cross-dependencies that are not satisfied. With "make menuconfig", I haven't been able to switch off the setting, because CONFIG_PM_SLEEP and something else forces it on, and I have no idea where in the menus I would find those. And if I edit .config directly, I don't know what other cross-dependencies I'll violate that way. I only had a few minutes to spare today to select a config and kick off the compilation. Now I have a 3.17 kernel with some more debug output, but which freezes on 'bind' instead of 'unbind'. *sigh* I'm afraid I've been doing too much just-before-bedtime debugging lately and need to take a step back. I'll set aside a few hours on Thursday to prepare a proper config with a behavior that is comparable to the ones I've observed earlier. Then I will send decent debug output over the week-end. It's not like this problem will run away if I don't track it fast enough :-) cheers and thanks, Roland -- To unsubscribe from this list: send the line "unsubscribe linux-usb" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: PROBLEM: lsusb -v freezes kernel on Acer ES1-111M
On Tue, 15 Sep 2015, Roland Weber wrote: > Hi Alan, > > > > ehci_halt: premature readl returned 10001 > > > > Note: 10001 instead of 1, which is what you saw in the other > > kernel. That could be highly relevant. > > Really? And I thought that was the least significant bit... It is the least significant bit in the register, but it is the bit that indicates whether or not the controller is running, which makes it one of the most important. :-) > I had a lucky guess among the 2000+ lines of diff output with > which I started: CONFIG_PM_RUNTIME makes the difference. > If it's on, the kernel can freeze. Aha, good. I was heading in the same general direction. > I'll have to add the debug output you asked for tomorrow, > didn't expect to succeed so soon. > > Should I put the statements into the 3.17 kernel, or should I > try to compile a 4.2 without CONFIG_PM_RUNTIME instead? And > would you like the output of a freezing or non-freezing kernel > first? I'll only be able to try out one tomorrow, the rest > will follow a day or two later. As long as the 4.2 kernel can do what you want, you may as well use it. However, note that CONFIG_PM_RUNTIME doesn't exist any more in 4.2; it is now covered by CONFIG_PM. Assuming things work out as expected, try this: In core/hub.c, remove the calls to usb_enable_autosuspend(hdev) in hub_probe() and leave CONFIG_PM enabled. Alan Stern -- To unsubscribe from this list: send the line "unsubscribe linux-usb" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: PROBLEM: lsusb -v freezes kernel on Acer ES1-111M
On Sun, 13 Sep 2015, Alan Stern wrote: > On Sun, 13 Sep 2015, Roland Weber wrote: > > > I compiled a kernel 3.17(.0) with my additional debug lines... > > and this one does NOT freeze! The output is: > > > > (first unbind) > > ehci-pci :00:1d.0: remove, state 4 > > ehci-pci :00:1d.0: roothub graceful disconnect > > usb usb1: USB disconnect, device number 1 > > ehci-pci :00:1d.0: shutdown urb 880072bf4300 ep1in-intr > > usb_remove_hcd: calling stop > > ehci-pci :00:1d.0: stop > > ehci_silence_controller: entry > > ehci_halt: entry > > ehci_halt: after spin_lock_irq > > ehci_halt: about to readl prematurely > > ehci_halt: premature readl returned 10001 > > Note: 10001 instead of 1, which is what you saw in the other > kernel. That could be highly relevant. > At some point along the way, can you try adding some printk statements > to ehci_suspend() and ehci_resume() in ehci-hcd.c? I'd like to know if > they get called during the bind/unbind procedure and are responsible > for that 10001 vs. 1 value. There's one other thing I'd like to see as well. Before doing the unbind, save a copy of /sys/kernel/debug/usb/ehci/:00:1d.0/registers. Do this for both types of kernel (one that gets 1 for the readl value and one that gets 10001). There ought to be some useful information in them. Oh, and also let's see what /sys/bus/pci/devices/:00:1d.0/power/control and /sys/bus/pci/devices/:00:1d.0/power/runtime_status contain. Alan Stern -- To unsubscribe from this list: send the line "unsubscribe linux-usb" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: PROBLEM: lsusb -v freezes kernel on Acer ES1-111M
Hi Alan, > > ehci_halt: premature readl returned 10001 > > Note: 10001 instead of 1, which is what you saw in the other > kernel. That could be highly relevant. Really? And I thought that was the least significant bit... I had a lucky guess among the 2000+ lines of diff output with which I started: CONFIG_PM_RUNTIME makes the difference. If it's on, the kernel can freeze. I'll have to add the debug output you asked for tomorrow, didn't expect to succeed so soon. Should I put the statements into the 3.17 kernel, or should I try to compile a 4.2 without CONFIG_PM_RUNTIME instead? And would you like the output of a freezing or non-freezing kernel first? I'll only be able to try out one tomorrow, the rest will follow a day or two later. cheers and thanks, Roland -- To unsubscribe from this list: send the line "unsubscribe linux-usb" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: PROBLEM: lsusb -v freezes kernel on Acer ES1-111M
Roland, Roland Weber wrote: > Assuming that this kernel does freeze, I will start to 'bisect' the > differences in the kernel configurations Thank you very much for doing this work. You are one of the many open source heroes and heroines. //Peter -- To unsubscribe from this list: send the line "unsubscribe linux-usb" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: PROBLEM: lsusb -v freezes kernel on Acer ES1-111M
Hi Alan, hi all, > > I can also produce the freeze on 3.17, with some extra steps: > > Okay, that's worth knowing. > > > (after boot there's just the ehci-pci bus with no device) > > - unbind ehci-pci > > - bind ehci-pci > > During both the unbind and the bind, the debugging lines you added to > ehci-hcd.c should show up. Do they? I'm afraid my statement wasn't entirely accurate. I was using a precompiled kernel 3.17.8 (not 3.17 plain) without my debugging lines. >From the regular kernel debug output, I get: (first unbind) ehci-pci :00:1d.0: remove, state 4 usb usb1: USB disconnect, device number 1 ehci-pci :00:1d.0: USB bus 1 deregistered (bind) ehci-pci :00:1d.0: EHCI Host Controller ehci-pci :00:1d.0: new USB bus registered, assigned bus number 1 ehci-pci :00:1d.0: debug port 2 ehci-pci :00:1d.0: cache line size of 64 is not supported ehci-pci :00:1d.0: irq 23, io mem 0x90918000 ehci-pci :00:1d.0: USB 2.0 started, EHCI 1.00 usb usb1: New USB device found, idVendor=1d6b, idProduct=0002 usb usb1: New USB device strings: Mfr=3, Product=2, SerialNumber=1 usb usb1: Product: EHCI Host Controller usb usb1: Manufacturer: Linux 3.17.8-031708-generic ehci_hcd usb usb1: SerialNumber :00:1d.0 hub 1-0:1.0: USB hub found hub 1-0:1.0: 8 ports detected usb 1-1: new high-speed USB device number 2 using ehci-pci usb 1-1: New USB device found, idVendor=8087, idProduct=07e6 usb 1-1: New USB device strings: Mfr=0, Product=0, SerialNumber=0 hub 1-1:1.0: USB hub found hub 1-1:1.0: 4 ports detected (second unbind) ehci-pci :00:1d.0: remove, state 4 usb usb1: USB disconnect, device number 1 usb 1-1: USB disconnect, device number 2 (freeze) I compiled a kernel 3.17(.0) with my additional debug lines... and this one does NOT freeze! The output is: (first unbind) ehci-pci :00:1d.0: remove, state 4 ehci-pci :00:1d.0: roothub graceful disconnect usb usb1: USB disconnect, device number 1 ehci-pci :00:1d.0: shutdown urb 880072bf4300 ep1in-intr usb_remove_hcd: calling stop ehci-pci :00:1d.0: stop ehci_silence_controller: entry ehci_halt: entry ehci_halt: after spin_lock_irq ehci_halt: about to readl prematurely ehci_halt: premature readl returned 10001 ehci_halt: after first ehci_writel ehci_halt: before ehci_readl ehci_halt: after ehci_readl, before ehci_writel ehci_halt: after second ehci_writel ehci_halt: after spin_unlock_irq ehci_halt: after_synchronize_irq, before ehci_handshake ehci_silence_controller: after ehci_silence_controller ehci-pci :00:1d.0: reset command 0010002 (park)=0 ithresh=1 period=1024 Reset HALT ehci-pci :00:1d.0: ehci_stop completed status 1000 Halt usb_remove_hcd: returned from stop usb_remove_hcd: after del_timer_sync ehci-pci :00:1d.0: USB bus 1 deregistered (bind) ehci-pci :00:1d.0: EHCI Host Controller ehci-pci :00:1d.0: new USB bus registered, assigned bus number 1 ehci-pci :00:1d.0: debug port 2 ehci-pci :00:1d.0: cache line size of 64 is not supported ehci-pci :00:1d.0: reset hcs_params 0x28 dbg=2 cc=0 pcc=0 ordered !ppc ports=8 ehci-pci :00:1d.0: reset hcc_params 36881 caching frame 1024 64 bit addr ehci_halt: entry ehci_halt: after spin_lock_irq ehci_halt: about to readl prematurely ehci_halt: premature readl returned 8 ehci_halt: after first ehci_writel ehci_halt: before ehci_readl ehci_halt: after ehci_readl, before ehci_writel ehci_halt: after second ehci_writel ehci_halt: after spin_unlock_irq ehci_halt: after_synchronize_irq, before ehci_handshake ehci-pci :00:1d.0: reset command 0010002 (park)=0 ithresh=1 period=1024 Reset HALT ehci-pci :00:1d.0: cache line size of 64 is not supported ehci-pci :00:1d.0: supports USB remote wakeup ehci-pci :00:1d.0: irq 23, io mem 0x90918000 ehci-pci :00:1d.0: init command 0010001 (park)=0 ithresh=1 period=1024 RUN ehci-pci :00:1d.0: USB 2.0 started, EHCI 1.00 usb usb1: New USB device found, idVendor=1d6b, idProduct=0002 usb usb1: New USB device strings: Mfr=3, Product=2, SerialNumber=1 usb usb1: Product: EHCI Host Controller usb usb1: Manufacturer: Linux 3.17.0-w ehci_hcd usb usb1: SerialNumber :00:1d.0 hub 1-0:1.0: USB hub found hub 1-0:1.0: 8 ports detected ehci-pci :00:1d.0: GetStatus port:1 status 001803 0 ACK POWER sig=j CSC CONNECT ehci-pci :00:1d.0: port 1 reset complete, port enabled ehci-pci :00:1d.0: GetStatus port:1 status 001005 0 ACK POWER sig=se0 PE CONNECT usb 1-1: new high-speed USB device number 2 using ehci-pci ehci-pci :00:1d.0: port 1 reset complete, port enabled ehci-pci :00:1d.0: GetStatus port:1 status 001005 0 ACK POWER sig=se0 PE CO N usb 1-1: New USB device found, idVendor=8087, idProduct=07e6 usb 1-1: New USB device strings: Mfr=0, Product=0, SerialNumber=0 hub 1-1:1.0: USB hub found hub 1-1:1.0: 4 ports detected usb 1-1: ep 81: reserve intr @ 8+64 (1.0+256) [1/0 us] mask 0001 usb 1-1: link qh256-0001/88007516dcc0 start 1 [1/0 us] (second unbind) ehci-pci
Re: PROBLEM: lsusb -v freezes kernel on Acer ES1-111M
On Sun, 13 Sep 2015, Roland Weber wrote: > I compiled a kernel 3.17(.0) with my additional debug lines... > and this one does NOT freeze! The output is: > > (first unbind) > ehci-pci :00:1d.0: remove, state 4 > ehci-pci :00:1d.0: roothub graceful disconnect > usb usb1: USB disconnect, device number 1 > ehci-pci :00:1d.0: shutdown urb 880072bf4300 ep1in-intr > usb_remove_hcd: calling stop > ehci-pci :00:1d.0: stop > ehci_silence_controller: entry > ehci_halt: entry > ehci_halt: after spin_lock_irq > ehci_halt: about to readl prematurely > ehci_halt: premature readl returned 10001 Note: 10001 instead of 1, which is what you saw in the other kernel. That could be highly relevant. > I cannot yet tell whether the difference between freeze and non-freeze > is due to code changes, or because I used a different kernel config. > (It brings down compilation times from 3h to 2h.) > > So next I'll compile 3.17.8 with my config. On Sun, 13 Sep 2015, Roland Weber wrote: > Actually, it made more sense to try other precompiled kernels. > I can freeze the precompiled 3.17.0 with unbind/bind/unbind, > but not the one I compiled myself. I'm currently compiling > 3.17.0 with the exact config of the precompiled kernel, to > rule out differences in the build environment as the cause. > > Assuming that this kernel does freeze, I will start to 'bisect' the > differences in the kernel configurations, based on the assumption > that it might give us a clue about where the problem comes from. > I expect this to take several days... please stop me if you've got > a better lead. At some point along the way, can you try adding some printk statements to ehci_suspend() and ehci_resume() in ehci-hcd.c? I'd like to know if they get called during the bind/unbind procedure and are responsible for that 10001 vs. 1 value. Alan Stern -- To unsubscribe from this list: send the line "unsubscribe linux-usb" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: PROBLEM: lsusb -v freezes kernel on Acer ES1-111M
Hi all, I wrote: > I cannot yet tell whether the difference between freeze and non-freeze > is due to code changes, or because I used a different kernel config. > (It brings down compilation times from 3h to 2h.) > > So next I'll compile 3.17.8 with my config. Actually, it made more sense to try other precompiled kernels. I can freeze the precompiled 3.17.0 with unbind/bind/unbind, but not the one I compiled myself. I'm currently compiling 3.17.0 with the exact config of the precompiled kernel, to rule out differences in the build environment as the cause. Assuming that this kernel does freeze, I will start to 'bisect' the differences in the kernel configurations, based on the assumption that it might give us a clue about where the problem comes from. I expect this to take several days... please stop me if you've got a better lead. cheers, Roland -- To unsubscribe from this list: send the line "unsubscribe linux-usb" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: PROBLEM: lsusb -v freezes kernel on Acer ES1-111M
On Sat, 12 Sep 2015, Roland Weber wrote: > Hi Alan, > > I'm sending a "Reply to all" on this mail. Should I continue to keep > Mathias and Bjorn on copy and cross-posting to linux-pci@ (I'm not > yet subscribed there, so that post probably won't get through anyway)? Most kernel lists don't require posters to subscribe. Yes, please keep everybody on the CC: list. > > [Roland, what happens if you try unbinding xhci-hcd before ehci-hcd? > > Note that unbinding xhci-hcd will cause your wireless keyboard & mouse > > to stop working, so you'll have to use a shell script or a network > > login to run the test.] > > The outcome is the same, the system freezes on the readl. > See below for the transcript from a screen photo. > > > I say this may be relevant because Roland found that ehci-hcd was > > unable to communicate over the USB bus if it tried to do so before > > xhci-hcd was probed. This happens in the 3.17 or earlier kernel -- and > > that kernel doesn't suffer the freeze problem. > > I can also produce the freeze on 3.17, with some extra steps: Okay, that's worth knowing. > (after boot there's just the ehci-pci bus with no device) > - unbind ehci-pci > - bind ehci-pci During both the unbind and the bind, the debugging lines you added to ehci-hcd.c should show up. Do they? > (now the ehci-pci bus has the missing device) > - unbind ehci-pci > > So the only reason why the older kernels didn't freeze is that > the device in question couldn't be initialized with the original > probe sequence. I'll try your blacklisting tip over the weekend. I wouldn't call it the "only reason". Rather, it's another symptom arising from the same underlying problem. Alan Stern -- To unsubscribe from this list: send the line "unsubscribe linux-usb" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: PROBLEM: lsusb -v freezes kernel on Acer ES1-111M
On Sat, 12 Sep 2015, Roland Weber wrote: > Hi Alan, > > > was added recently; a table of devices that ehci-pci should ignore. If > > you add your device to that list, ehci-pci won't bind to it. See > > bypass_pci_id_table in drivers/usb/host/ehci-pci.c. Of course, that > > also will involve rebuilding part of the kernel... > > Yes, that works! With the patch below applied to kernel 4.2, the EHCI bus > that causes my problems is gone. The system shuts down without freeze. It's > a relief to know that I'll be able to install a reliable system on this > machine. Never mind building a kernel... I've got ample experience now :-) It would be just as easy -- maybe easier! -- to build a kernel with CONFIG_USB_EHCI_HCD disabled. No patches would be needed. > Now let's hope that we can find a fix for the actual problem, > so I can switch back to precompiled kernels some time next year. Yeah, that looks like it's going to be a very tough problem. :-( Alan Stern -- To unsubscribe from this list: send the line "unsubscribe linux-usb" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: PROBLEM: lsusb -v freezes kernel on Acer ES1-111M
Hi Alan, I'm sending a "Reply to all" on this mail. Should I continue to keep Mathias and Bjorn on copy and cross-posting to linux-pci@ (I'm not yet subscribed there, so that post probably won't get through anyway)? > [Roland, what happens if you try unbinding xhci-hcd before ehci-hcd? > Note that unbinding xhci-hcd will cause your wireless keyboard & mouse > to stop working, so you'll have to use a shell script or a network > login to run the test.] The outcome is the same, the system freezes on the readl. See below for the transcript from a screen photo. > I say this may be relevant because Roland found that ehci-hcd was > unable to communicate over the USB bus if it tried to do so before > xhci-hcd was probed. This happens in the 3.17 or earlier kernel -- and > that kernel doesn't suffer the freeze problem. I can also produce the freeze on 3.17, with some extra steps: (after boot there's just the ehci-pci bus with no device) - unbind ehci-pci - bind ehci-pci (now the ehci-pci bus has the missing device) - unbind ehci-pci So the only reason why the older kernels didn't freeze is that the device in question couldn't be initialized with the original probe sequence. I'll try your blacklisting tip over the weekend. Thanks and cheers, Roland [transcript] root@Nightwing# cat ./xhci-ehci-unbind #!/bin/bash echo :00:14.0 > /sys/bus/pci/drivers/xhci_hcd/unbind echo :00:1d.0 > /sys/bus/pci/drivers/ehci-pci/unbind root@Nightwing# echo 8 > /proc/sys/kernel/printk root@Nightwing# ./xhci-ehci-unbind [...] xhci_hcd :00:14.0: remove, state 4 [...] xhci_hcd :00:14.0: roothub graceful disconnect [...] usb usb2: USB disconnect, device number 1 [...] usb_remove_hcd: calling stop [...] usb_remove_hcd: returned from stop [...] usb_remove_hcd: after del_timer_sync [...] xhci_hcd :00:14.0: USB bus 2 deregistered [...] xhci_hcd :00:14.0: remove, state 1 [...] xhci_hcd :00:14.0: roothub graceful disconnect [...] usb usb1: USB disconnect, device number 1 [...] usb 1-2: USB disconnect, device number 2 [...] usb 1-2.1: USB disconnect, device number 4 [...] xhci_hcd :00:14.0: shutdown urb 8800727b3300 ep1in-intr [...] usb 1-4: USB disconnect, device number 3 [...] xhci_hcd :00:14.0: shutdown urb 8800725ac780 ep1in-intr [...] usb_remove_hcd: calling stop [...] usb_remove_hcd: returned from stop [...] usb_remove_hcd: after del_timer_sync [...] xhci_hcd :00:14.0: USB bus 1 deregistered [...] ehci-pci :00:1d.0: remove, state 4 [...] ehci-pci :00:1d.0: roothub graceful disconnect [...] usb 3-1: USB disconnect, device number 2 [...] usb 3-1: ep 81: release intr @ 8+64 (1.0+256) [1/0 us] mask 0001 [...] usb_remove_hcd: calling stop [...] ehci-pci :00:1d.0: stop [...] ehci_silence_controller: entry [...] ehci_halt: entry [...] ehci_halt: after spin_lock_irq [...] ehci_halt: about to readl prematurely [...] ehci_halt: premature readl returned 1 [...] ehci_halt: after first ehci_writel [...] ehci_halt: before ehci_readl -- To unsubscribe from this list: send the line "unsubscribe linux-usb" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: PROBLEM: lsusb -v freezes kernel on Acer ES1-111M
Hi Alan,
> was added recently; a table of devices that ehci-pci should ignore. If
> you add your device to that list, ehci-pci won't bind to it. See
> bypass_pci_id_table in drivers/usb/host/ehci-pci.c. Of course, that
> also will involve rebuilding part of the kernel...
Yes, that works! With the patch below applied to kernel 4.2, the EHCI bus
that causes my problems is gone. The system shuts down without freeze. It's
a relief to know that I'll be able to install a reliable system on this
machine. Never mind building a kernel... I've got ample experience now :-)
Now let's hope that we can find a fix for the actual problem,
so I can switch back to precompiled kernels some time next year.
thanks and cheers,
Roland
diff --git a/drivers/usb/host/ehci-pci.c b/drivers/usb/host/ehci-pci.c
index 2a5d2fd..05f4f76 100644
--- a/drivers/usb/host/ehci-pci.c
+++ b/drivers/usb/host/ehci-pci.c
@@ -52,6 +52,8 @@ static const struct pci_device_id bypass_pci_id_table[] = {
{ PCI_DEVICE(PCI_VENDOR_ID_INTEL, 0x0811), },
{ PCI_DEVICE(PCI_VENDOR_ID_INTEL, 0x0829), },
{ PCI_DEVICE(PCI_VENDOR_ID_INTEL, 0xe006), },
+ /* EHCI on Acer ES1-111M */
+ { PCI_DEVICE(PCI_VENDOR_ID_INTEL, 0x0f34), },
{}
};
--
To unsubscribe from this list: send the line "unsubscribe linux-usb" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: PROBLEM: lsusb -v freezes kernel on Acer ES1-111M
Hi Alan, > The only reason I can think of why it might hang is if some clock got > turned off. But I don't know of any clock which would have that > effect, or which would get turned off before we reach this point. > > I also don't understand why the ehci_readl() would freeze when the > preceding ehci_writel() succeeded. Can you try putting a copy of the > ehci_readl() line just before the ehci_writel(), to see if it will work > there? Done: printk(KERN_INFO "ehci_halt: about to readl prematurely\n"); temp = ehci_readl(ehci, >regs->command); printk(KERN_INFO "ehci_halt: premature readl returned %x\n", temp); /* disable any irqs left enabled by previous code */ ehci_writel(ehci, 0, >regs->intr_enable); printk(KERN_INFO "ehci_halt: after first ehci_writel\n"); It works there. Result: premature readl returned 1 thanks and cheers, Roland -- To unsubscribe from this list: send the line "unsubscribe linux-usb" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: PROBLEM: lsusb -v freezes kernel on Acer ES1-111M
Mathias, Bjorn, and other PCI people:
I need help with a problem affecting certain Acer computers such as the
netbook model in $SUBJECT. More information about the system in
question is available at
https://bugs.launchpad.net/ubuntu/+source/linux/+bug/1485057
In short, the problem is that the ehci-hcd driver causes the system to
hang at various times. Roland has done a whole bunch of debugging and
narrowed one failure mode down to a particular line of source code in
the 4.2 kernel.
In drivers/usb/host/ehci-hcd.c, the ehci_halt() function looks like
this:
spin_lock_irq(>lock);
/* disable any irqs left enabled by previous code */
ehci_writel(ehci, 0, >regs->intr_enable);
if (ehci_is_TDI(ehci) && !tdi_in_host_mode(ehci)) {
spin_unlock_irq(>lock);
return 0;
}
/*
* This routine gets called during probe before ehci->command
* has been initialized, so we can't rely on its value.
*/
ehci->command &= ~CMD_RUN;
temp = ehci_readl(ehci, >regs->command);
temp &= ~(CMD_RUN | CMD_IAAD);
ehci_writel(ehci, temp, >regs->command);
spin_unlock_irq(>lock);
[ehci_writel() and ehci_readl() are wrappers around the standard
readl()/writel() or readl_be()/writel_be() routines. The choice of
endianness may be determined at build time (by Kconfig options) or at
run time (by hardware settings). The routines are defined in ehci.h if
you want to see the details.]
By inserting printk() lines, Roland found that the first ehci_writel()
call works okay. The condition in the "if" statement is false, so the
early return is not taken. The ehci_readl() causes the system to
freeze, so the second ehci_writel() never gets executed.
Oddly, this same function gets called as part of the probe sequence,
and it works fine then. But it hangs later on when Roland tries to
unbind ehci-hcd from the host controller device. One important
difference that may be relevant is that ehci-hcd gets probed before
xhci-hcd, whereas the unbind occurs after xhci-hcd has been probed.
I say this may be relevant because Roland found that ehci-hcd was
unable to communicate over the USB bus if it tried to do so before
xhci-hcd was probed. This happens in the 3.17 or earlier kernel -- and
that kernel doesn't suffer the freeze problem. This suggests there is
some unwanted interaction or interference between the two drivers.
In fact, Roland traced the problem to a single line in commit
638139eb95d2. That line made the USB hub work queue multi-threaded
rather than single-threaded, which accounts for the difference in
probing order but otherwise seems totally unrelated.
[Roland, what happens if you try unbinding xhci-hcd before ehci-hcd?
Note that unbinding xhci-hcd will cause your wireless keyboard & mouse
to stop working, so you'll have to use a shell script or a network
login to run the test.]
Does anyone have any idea what could cause this simple readl() call to
freeze?
On Thu, 10 Sep 2015, Roland Weber wrote:
> Hi Alan,
>
> > The only reason I can think of why it might hang is if some clock got
> > turned off. But I don't know of any clock which would have that
> > effect, or which would get turned off before we reach this point.
> >
> > I also don't understand why the ehci_readl() would freeze when the
> > preceding ehci_writel() succeeded. Can you try putting a copy of the
> > ehci_readl() line just before the ehci_writel(), to see if it will work
> > there?
>
> Done:
> printk(KERN_INFO "ehci_halt: about to readl prematurely\n");
> temp = ehci_readl(ehci, >regs->command);
> printk(KERN_INFO "ehci_halt: premature readl returned %x\n", temp);
>
> /* disable any irqs left enabled by previous code */
> ehci_writel(ehci, 0, >regs->intr_enable);
> printk(KERN_INFO "ehci_halt: after first ehci_writel\n");
>
> It works there. Result:
> premature readl returned 1
That's what it should be.
Alan Stern
--
To unsubscribe from this list: send the line "unsubscribe linux-usb" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: PROBLEM: lsusb -v freezes kernel on Acer ES1-111M
Hi Alan,
I've switched to kernel 4.2 for the latest debug sessions.
In drivers/usb/host/ehci-hcd.c, ehci_stop calls
ehci_silence_controller which calls ehci_halt:
static int ehci_halt (struct ehci_hcd *ehci)
{
u32 temp;
printk(KERN_INFO "ehci_halt: entry\n");
spin_lock_irq(>lock);
printk(KERN_INFO "ehci_halt: after spin_lock_irq\n");
/* disable any irqs left enabled by previous code */
ehci_writel(ehci, 0, >regs->intr_enable);
printk(KERN_INFO "ehci_halt: after first ehci_writel\n");
if (ehci_is_TDI(ehci) && !tdi_in_host_mode(ehci)) {
// this branch is not entered
printk(KERN_INFO "ehci_halt: before early spin_unlock_irq\n");
spin_unlock_irq(>lock);
printk(KERN_INFO "ehci_halt: early exit\n");
return 0;
}
/*
* This routine gets called during probe before ehci->command
* has been initialized, so we can't rely on its value.
*/
ehci->command &= ~CMD_RUN;
printk(KERN_INFO "ehci_halt: before ehci_readl\n");
temp = ehci_readl(ehci, >regs->command);
// this point is never reached
printk(KERN_INFO "ehci_halt: after ehci_readl, before ehci_writel\n");
There's one call to ehci_writel in the first part, which succeeds.
Then the call of ehci_readl freezes. The name sounds like a generic
communication primitive which is used from various places, so I
didn't drill further down. If you think it might help, I will.
Here's a transcript of the output I see:
ehci-pci :00:1d.0: remove, state 4
ehci-pci :00:1d.0: roothub graceful disconnect
usb usb3: USB disconnect, device number 1
usb3-1: USB disconnect, device number 2
usb3-1: ep 81: release intr @ 8+64 (1.0+256) [1/0 us] mask 0001
usb_remove_hcd: calling stop
ehci-pci :00:1d.0: stop
ehci_silence_controller: entry
ehci_halt: entry
ehci_halt: after spin_lock_irq
ehci_halt: after first ehci_writel
ehci_halt: before ehci_readl
thanks and cheers,
Roland
--
To unsubscribe from this list: send the line "unsubscribe linux-usb" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: PROBLEM: lsusb -v freezes kernel on Acer ES1-111M
On Wed, 9 Sep 2015, Roland Weber wrote:
> Hi Alan,
>
> I've switched to kernel 4.2 for the latest debug sessions.
> In drivers/usb/host/ehci-hcd.c, ehci_stop calls
> ehci_silence_controller which calls ehci_halt:
>
> static int ehci_halt (struct ehci_hcd *ehci)
> {
> u32 temp;
>
> printk(KERN_INFO "ehci_halt: entry\n");
> spin_lock_irq(>lock);
> printk(KERN_INFO "ehci_halt: after spin_lock_irq\n");
>
> /* disable any irqs left enabled by previous code */
> ehci_writel(ehci, 0, >regs->intr_enable);
> printk(KERN_INFO "ehci_halt: after first ehci_writel\n");
>
> if (ehci_is_TDI(ehci) && !tdi_in_host_mode(ehci)) {
> // this branch is not entered
> printk(KERN_INFO "ehci_halt: before early spin_unlock_irq\n");
> spin_unlock_irq(>lock);
> printk(KERN_INFO "ehci_halt: early exit\n");
> return 0;
> }
>
> /*
>* This routine gets called during probe before ehci->command
>* has been initialized, so we can't rely on its value.
>*/
> ehci->command &= ~CMD_RUN;
> printk(KERN_INFO "ehci_halt: before ehci_readl\n");
> temp = ehci_readl(ehci, >regs->command);
> // this point is never reached
> printk(KERN_INFO "ehci_halt: after ehci_readl, before ehci_writel\n");
>
>
> There's one call to ehci_writel in the first part, which succeeds.
> Then the call of ehci_readl freezes. The name sounds like a generic
> communication primitive which is used from various places, so I
> didn't drill further down. If you think it might help, I will.
It is indeed a primitive operation, and there's no need to look into it
any deeper.
> Here's a transcript of the output I see:
>
> ehci-pci :00:1d.0: remove, state 4
> ehci-pci :00:1d.0: roothub graceful disconnect
> usb usb3: USB disconnect, device number 1
> usb3-1: USB disconnect, device number 2
> usb3-1: ep 81: release intr @ 8+64 (1.0+256) [1/0 us] mask 0001
> usb_remove_hcd: calling stop
> ehci-pci :00:1d.0: stop
> ehci_silence_controller: entry
> ehci_halt: entry
> ehci_halt: after spin_lock_irq
> ehci_halt: after first ehci_writel
> ehci_halt: before ehci_readl
That is odd indeed. Note that ehci_halt() is called from ehci_setup(),
which runs during probing. So that same statement was executed
properly at some point in the past.
The only reason I can think of why it might hang is if some clock got
turned off. But I don't know of any clock which would have that
effect, or which would get turned off before we reach this point.
I also don't understand why the ehci_readl() would freeze when the
preceding ehci_writel() succeeded. Can you try putting a copy of the
ehci_readl() line just before the ehci_writel(), to see if it will work
there?
It's understandable how this could be related to "lsusb -v". Since you
don't have any devices attached to this EHCI controller, it would
naturally go into runtime suspend shortly after probing. The lsusb
command would case it to wake up, after which it would go back into
runtime suspend. As it happens, the ehci_bus_suspend() routine calls
ehci_halt().
Alan Stern
--
To unsubscribe from this list: send the line "unsubscribe linux-usb" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: PROBLEM: lsusb -v freezes kernel on Acer ES1-111M
On Mon, 7 Sep 2015, Roland Weber wrote: > Hi Alan, > > just a quick heads-up before I go to sleep, > more detailed info to follow later this week. > The freeze is triggered from hcd.c, function usb_remove_hcd: > > /* Prevent any more root-hub status calls from the timer. > * The HCD might still restart the timer (if a port status change > * interrupt occurs), but usb_hcd_poll_rh_status() won't invoke > * the hub_status_data() callback. > */ > hcd->rh_pollable = 0; > clear_bit(HCD_FLAG_POLL_RH, >flags); > del_timer_sync(>rh_timer); > > // I see output from here > printk(KERN_INFO "usb_remove_hcd five\n"); > > hcd->driver->stop(hcd); > hcd->state = HC_STATE_HALT; > > /* In case the HCD restarted the timer, stop it again. */ > clear_bit(HCD_FLAG_POLL_RH, >flags); > del_timer_sync(>rh_timer); > > // this point is not reached > printk(KERN_INFO "usb_remove_hcd six\n"); In theory the freeze could happen during the second del_timer_sync. But I think it is much more likely to occur during hcd->driver->stop; that would be consistent with the probing-order bug you observed. > There was a lot of noise on the screen, but I saw output > from release_devnum with index 2, then with index 1. > Then follows the freeze. If you could give me a hint where > hcd->driver->stop(hcd); > might point to, I can track it further down. It points to ehci_stop() in host/ehci-hcd.c. > > Hmmm, I just took a look at the code. Something I had forgotten about > > was added recently; a table of devices that ehci-pci should ignore. If > > you add your device to that list, ehci-pci won't bind to it. See > > bypass_pci_id_table in drivers/usb/host/ehci-pci.c. Of course, that > > also will involve rebuilding part of the kernel... > > Thanks, that's good to know. At the moment, I'm still tracking the freeze > in the codebase of the first "bad" commit. Would it be better to switch > to a more recent kernel already? If so, which one would you suggest? I suggest using the 4.2 kernel, just because it is the most recent. The ehci-hcd driver hasn't changed very much recently, however, so it probably doesn't matter a lot. Alan Stern -- To unsubscribe from this list: send the line "unsubscribe linux-usb" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: PROBLEM: lsusb -v freezes kernel on Acer ES1-111M
Hi Alan, > No output at all? Even when you use a VT console and you do "echo 8 > >proc/sys/kernel/printk"? When using "lsusb -v", I get the line that tells me which device is to be listed first, then nothing anymore. When disabling the ehci-pci module, I get nothing at all. I've taken a photo so you can see for yourself: https://bugs.launchpad.net/ubuntu/+source/linux/+bug/1485057/+attachment/4458832/+files/screenshot-freeze.JPG The series of actions was: 1. enable kernel debug output 2. detach external mouse, to verify that messages appear 3. hit enter to get a new prompt line 4. trigger the freeze with "lsusb -v" > It would be nice to find out exactly where the unbind freezes. Here > are some routines to check; try sprinkling printk or dev_info > statements at various places within them: Thanks. I'll send some results later this week. > > Your guess is correct. If the order of the probes is relevant, although > > it shouldn't be, maybe the order on shutdown/unbind also plays a role? > > Who knows? But bear in mind, probing inevitably involves communicating > with the device, whereas unbind need not. > > On the other hand, the fact that probing order matters is itself a bug. Unfortunately, a bug in the hardware or firmware that we can do nothing about, if I am not mistaken. > Try blacklisting the ehci-pci module. Unfortunately, there is no way > to tell the kernel not to allow a driver to probe a particular device. Thanks for the tip. I suppose I'll have to compile a kernel where that is actually a module and not directly compiled in :-) cheers, Roland -- To unsubscribe from this list: send the line "unsubscribe linux-usb" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: PROBLEM: lsusb -v freezes kernel on Acer ES1-111M
Hi Alan, just a quick heads-up before I go to sleep, more detailed info to follow later this week. The freeze is triggered from hcd.c, function usb_remove_hcd: /* Prevent any more root-hub status calls from the timer. * The HCD might still restart the timer (if a port status change * interrupt occurs), but usb_hcd_poll_rh_status() won't invoke * the hub_status_data() callback. */ hcd->rh_pollable = 0; clear_bit(HCD_FLAG_POLL_RH, >flags); del_timer_sync(>rh_timer); // I see output from here printk(KERN_INFO "usb_remove_hcd five\n"); hcd->driver->stop(hcd); hcd->state = HC_STATE_HALT; /* In case the HCD restarted the timer, stop it again. */ clear_bit(HCD_FLAG_POLL_RH, >flags); del_timer_sync(>rh_timer); // this point is not reached printk(KERN_INFO "usb_remove_hcd six\n"); There was a lot of noise on the screen, but I saw output from release_devnum with index 2, then with index 1. Then follows the freeze. If you could give me a hint where hcd->driver->stop(hcd); might point to, I can track it further down. > Hmmm, I just took a look at the code. Something I had forgotten about > was added recently; a table of devices that ehci-pci should ignore. If > you add your device to that list, ehci-pci won't bind to it. See > bypass_pci_id_table in drivers/usb/host/ehci-pci.c. Of course, that > also will involve rebuilding part of the kernel... Thanks, that's good to know. At the moment, I'm still tracking the freeze in the codebase of the first "bad" commit. Would it be better to switch to a more recent kernel already? If so, which one would you suggest? thanks and cheers, Roland -- To unsubscribe from this list: send the line "unsubscribe linux-usb" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: PROBLEM: lsusb -v freezes kernel on Acer ES1-111M
On Mon, 7 Sep 2015, Roland Weber wrote: > > It would be nice to find out exactly where the unbind freezes. Here > > are some routines to check; try sprinkling printk or dev_info > > statements at various places within them: > > Thanks. I'll send some results later this week. The fact that you get no output when doing the unbind indicates that the freeze occurs relatively early. > > On the other hand, the fact that probing order matters is itself a bug. > > Unfortunately, a bug in the hardware or firmware that we can do nothing > about, if I am not mistaken. Well, maybe and maybe not. We should at least bring it to the attention of the xHCI maintainer, once the current bug has been located and fixed. > > Try blacklisting the ehci-pci module. Unfortunately, there is no way > > to tell the kernel not to allow a driver to probe a particular device. > > Thanks for the tip. I suppose I'll have to compile a kernel where > that is actually a module and not directly compiled in :-) Yes. Or a kernel where CONFIG_USB_EHCI_PCI is disabled. Hmmm, I just took a look at the code. Something I had forgotten about was added recently; a table of devices that ehci-pci should ignore. If you add your device to that list, ehci-pci won't bind to it. See bypass_pci_id_table in drivers/usb/host/ehci-pci.c. Of course, that also will involve rebuilding part of the kernel... Alan Stern -- To unsubscribe from this list: send the line "unsubscribe linux-usb" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: PROBLEM: lsusb -v freezes kernel on Acer ES1-111M
Hello Alan, thanks for bearing with me. > I'm not sure what you mean by that. Everything we have been discussing > is in hub.c, not usb.c. Argh. That means I messed up the dynamic debug setting that was supposed to enable the additional log statements. Luckily, I didn't need it anyway, because we could see the entry/exit output even so. > The boot sequence isn't enough. I need to see what happens when the > system freezes. And I'd like to give you that information, but there is no output before the freeze. On the plus side, I think I can tell you why. You've given me a new way to trigger the freeze on a "bad" kernel: > echo :00:1d.0 >/sys/bus/pci/drivers/ehci-pci/unbind The output you are looking for would appear on the bind, correct? But the system already freezes on the unbind. Is the workqueue that was changed from ordered to unordered involved at that point, too? > In the "good" kernel, the 1-1 device is probed _before_ the devices on > bus 2, whereas in the "bad" kernel it is probed _after_ them. That > could make a difference; the buses are supposed to be independent but > they might not be. However, this is not relevant to the main problem, > which is the hangs. > > (You can test this hypothesis by booting the "good" kernel, and after > [...] > If the guess is correct, the probes following this bind should > succeed.) Your guess is correct. If the order of the probes is relevant, although it shouldn't be, maybe the order on shutdown/unbind also plays a role? > Also, the log doesn't go all the way back to the initial boot. > Probably the kernel's log buffer overflowed and wrapped around because > of all the useless systemd output. Is there any way you can tell > systemd not to write its output to the kernel log buffer? Yes, "systemd.log_target=null" does the trick. See below for the new logs. Coming from another angle: Is it possible to tell the kernel to ignore the USB hub that causes my problems, so it won't get probed at all? I'll need the machine in working order from October through December, and I'd rather have it on a current kernel with special boot parameters than on a backlevel kernel, or on one I have to patch myself. Thanks and cheers, Roland > grep -i -e 'usb\|hub' dmesg.nosystemd.txt # for the complete file, see # https://bugs.launchpad.net/ubuntu/+source/linux/+bug/1485057/+attachment/4458181/+files/dmesg.nosystemd.txt [0.577810] ACPI: Power Resource [USBC] (on) [0.819230] ACPI: bus type USB registered [0.819270] usbcore: registered new interface driver usbfs [0.819295] usbcore: registered new interface driver hub [0.819328] usbcore: registered new device driver usb [1.594144] ehci_hcd: USB 2.0 'Enhanced' Host Controller (EHCI) Driver [1.606441] ehci-pci :00:1d.0: new USB bus registered, assigned bus number 1 [1.641436] ehci-pci :00:1d.0: USB 2.0 started, EHCI 1.00 [1.645754] usb usb1: udev 1, busnum 1, minor = 0 [1.649921] usb usb1: New USB device found, idVendor=1d6b, idProduct=0002 [1.654112] usb usb1: New USB device strings: Mfr=3, Product=2, SerialNumber=1 [1.662300] usb usb1: Product: EHCI Host Controller [1.666540] usb usb1: Manufacturer: Linux 3.17.0-rc6-p ehci_hcd [1.670728] usb usb1: SerialNumber: :00:1d.0 [1.675206] hub 1-0:1.0: USB hub found [1.679398] hub 1-0:1.0: 8 ports detected [1.683541] hub 1-0:1.0: standalone hub [1.687602] hub 1-0:1.0: no power switching (usb 1.0) [1.691577] hub 1-0:1.0: individual port over-current protection [1.695522] hub 1-0:1.0: power on to power good time: 20ms [1.699445] hub 1-0:1.0: local power source is good [1.703476] hub 1-0:1.0: trying to enable port power on non-switchable hub [1.711279] ohci_hcd: USB 1.1 'Open' Host Controller (OHCI) Driver [1.723132] uhci_hcd: USB Universal Host Controller Interface driver [1.731406] xhci_hcd :00:14.0: new USB bus registered, assigned bus number 2 [1.748268] usb usb2: udev 1, busnum 2, minor = 128 [1.752304] usb usb2: New USB device found, idVendor=1d6b, idProduct=0002 [1.756309] usb usb2: New USB device strings: Mfr=3, Product=2, SerialNumber=1 [1.764245] usb usb2: Product: xHCI Host Controller [1.768365] usb usb2: Manufacturer: Linux 3.17.0-rc6-p xhci_hcd [1.772497] usb usb2: SerialNumber: :00:14.0 [1.776978] hub 2-0:1.0: USB hub found [1.781100] hub 2-0:1.0: 6 ports detected [1.785081] hub 2-0:1.0: standalone hub [1.789022] hub 2-0:1.0: no power switching (usb 1.0) [1.792895] hub 2-0:1.0: individual port over-current protection [1.796744] hub 2-0:1.0: Single TT [1.800630] hub 2-0:1.0: TT requires at most 8 FS bit times (666 ns) [1.804663] hub 2-0:1.0: power on to power good time: 20ms [1.808782] hub 2-0:1.0: local power source is good [1.808864] usb usb1-port1: status 0501 change 0001 [1.817737] hub 2-0:1.0: trying to enable port power on non-switchable hub [1.826391]
Re: PROBLEM: lsusb -v freezes kernel on Acer ES1-111M
On Sun, 6 Sep 2015, Roland Weber wrote: > Hello Alan, > > thanks for bearing with me. > > > I'm not sure what you mean by that. Everything we have been discussing > > is in hub.c, not usb.c. > > Argh. That means I messed up the dynamic debug setting that was supposed > to enable the additional log statements. Luckily, I didn't need it anyway, > because we could see the entry/exit output even so. > > > The boot sequence isn't enough. I need to see what happens when the > > system freezes. > > And I'd like to give you that information, but there is no output > before the freeze. On the plus side, I think I can tell you why. No output at all? Even when you use a VT console and you do "echo 8 >proc/sys/kernel/printk"? > You've given me a new way to trigger the freeze on a "bad" kernel: > > > echo :00:1d.0 >/sys/bus/pci/drivers/ehci-pci/unbind > > The output you are looking for would appear on the bind, correct? > But the system already freezes on the unbind. Is the workqueue that > was changed from ordered to unordered involved at that point, too? I don't think so, but the sequence of events is complex and maybe I have forgotten something. It would be nice to find out exactly where the unbind freezes. Here are some routines to check; try sprinkling printk or dev_info statements at various places within them: In hcd.c, usb_remove_hcd() and usb_deregister_bus(). In hub.c, usb_disconnect(), hub_disconnect(), hub_quiesce(), and release_devnum(). > > In the "good" kernel, the 1-1 device is probed _before_ the devices on > > bus 2, whereas in the "bad" kernel it is probed _after_ them. That > > could make a difference; the buses are supposed to be independent but > > they might not be. However, this is not relevant to the main problem, > > which is the hangs. > > > > (You can test this hypothesis by booting the "good" kernel, and after > > [...] > > If the guess is correct, the probes following this bind should > > succeed.) > > Your guess is correct. If the order of the probes is relevant, although > it shouldn't be, maybe the order on shutdown/unbind also plays a role? Who knows? But bear in mind, probing inevitably involves communicating with the device, whereas unbind need not. On the other hand, the fact that probing order matters is itself a bug. > Coming from another angle: Is it possible to tell the kernel to ignore > the USB hub that causes my problems, so it won't get probed at all? > I'll need the machine in working order from October through December, > and I'd rather have it on a current kernel with special boot parameters > than on a backlevel kernel, or on one I have to patch myself. Try blacklisting the ehci-pci module. Unfortunately, there is no way to tell the kernel not to allow a driver to probe a particular device. > > grep -i -e 'usb\|hub' dmesg.nosystemd.txt # for the complete file, see > # > https://bugs.launchpad.net/ubuntu/+source/linux/+bug/1485057/+attachment/4458181/+files/dmesg.nosystemd.txt I don't see anything unusual in the log, at first glance. Tracking down the place where the freeze occurs will probably be more fruitful. Alan Stern -- To unsubscribe from this list: send the line "unsubscribe linux-usb" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: PROBLEM: lsusb -v freezes kernel on Acer ES1-111M
On Thu, 3 Sep 2015, Roland Weber wrote: > Hello Alan, > > > The kernel freezes before the > > new log statements, or any others in hub.c, are executed. > > Wrong filename there, it's usb.c of course. I'm not sure what you mean by that. Everything we have been discussing is in hub.c, not usb.c. > I've collected debug output from the boot sequence of the > bad kernel, with extra entry/exit statements, and of the > last good kernel, without the extra statements. Below are > excerpts which hopefully catch all relevant lines. Because > of its size, I've attached the full output to the bug report > that I initially opened against my distribution. The boot sequence isn't enough. I need to see what happens when the system freezes. Also, the log doesn't go all the way back to the initial boot. Probably the kernel's log buffer overflowed and wrapped around because of all the useless systemd output. Is there any way you can tell systemd not to write its output to the kernel log buffer? Or failing that, can you expand the log buffer's size (increase CONFIG_LOG_BUF_SHIFT)? > The "good" kernel apparently has delays of 4 seconds > related to the "Cannot enable" problem. That doesn't mean anything. It's just the interval between retries. > The "bad" kernel > has no such problem at all. Any idea how that difference > in behavior can be caused by changing the implementation > of the workqueue? In the "good" kernel, the 1-1 device is probed _before_ the devices on bus 2, whereas in the "bad" kernel it is probed _after_ them. That could make a difference; the buses are supposed to be independent but they might not be. However, this is not relevant to the main problem, which is the hangs. (You can test this hypothesis by booting the "good" kernel, and after everything settles down, doing this: echo :00:1d.0 >/sys/bus/pci/drivers/ehci-pci/unbind echo :00:1d.0 >/sys/bus/pci/drivers/ehci-pci/bind If the guess is correct, the probes following this bind should succeed.) > There are two exit traces without a matching entry trace: > [2.990519] hub 2-0:1.0: exit > [ 17.092630] hub 1-0:1.0: exit > I guess the x-0 device init starts at a different function. No, the entry traces undoubtedly occurred earlier in the log and got overwritten when the log buffer wrapped around. Alan Stern -- To unsubscribe from this list: send the line "unsubscribe linux-usb" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: PROBLEM: lsusb -v freezes kernel on Acer ES1-111M
Hello Alan, > The kernel freezes before the > new log statements, or any others in hub.c, are executed. Wrong filename there, it's usb.c of course. I've collected debug output from the boot sequence of the bad kernel, with extra entry/exit statements, and of the last good kernel, without the extra statements. Below are excerpts which hopefully catch all relevant lines. Because of its size, I've attached the full output to the bug report that I initially opened against my distribution. The "good" kernel apparently has delays of 4 seconds related to the "Cannot enable" problem. The "bad" kernel has no such problem at all. Any idea how that difference in behavior can be caused by changing the implementation of the workqueue? There are two exit traces without a matching entry trace: [2.990519] hub 2-0:1.0: exit [ 17.092630] hub 1-0:1.0: exit I guess the x-0 device init starts at a different function. cheers and thanks, Roland # bad kernel, full output at https://bugs.launchpad.net/ubuntu/+source/linux/+bug/1485057/+attachment/4456918/+files/dmesg.bad.full.txt > grep -i -e 'usb\|hub' # bad kernel [2.672184] usb usb2-port4: status 0101, change , 12 Mb/s [2.690605] systemd-udevd[105]: seq 1289 queued, 'add' 'usb' [2.690662] systemd-udevd[105]: seq 1290 queued, 'add' 'usb' [2.771257] usb 2-2-port1: status 0101 change 0001 [2.786767] usb 2-4: new high-speed USB device number 3 using xhci_hcd [2.842780] usb usb2-port4: not reset yet, waiting 50ms [2.878808] hub 2-2:1.0: entry [2.878811] hub 2-2:1.0: state 7 ports 4 chg 0002 evt [2.881573] usb 2-2-port1: status 0101, change , 12 Mb/s [2.885371] usb 2-2-port1: indicator auto status 0 [2.985325] usb 2-4: udev 3, busnum 2, minor = 130 [2.985328] usb 2-4: New USB device found, idVendor=04f2, idProduct=b469 [2.985330] usb 2-4: New USB device strings: Mfr=1, Product=2, SerialNumber=0 [2.985332] usb 2-4: Product: HD WebCam [2.985334] usb 2-4: Manufacturer: Chicony Electronics Co.,Ltd. [2.985868] systemd-udevd[105]: seq 1294 queued, 'add' 'usb' [2.990519] hub 2-0:1.0: exit [2.990787] systemd-udevd[119]: handling device node '/dev/bus/usb/002/001', devnum=c189:128, mode=0664, uid=0, gid=0 [2.990797] systemd-udevd[119]: set permissions /dev/bus/usb/002/001, 020664, uid=0, gid=0 [2.990821] systemd-udevd[119]: creating symlink '/dev/char/189:128' to '../bus/usb/002/001' [2.990920] systemd-udevd[119]: created db file '/run/udev/data/c189:128' for '/devices/pci:00/:00:14.0/usb2' [2.991034] systemd-udevd[105]: seq 1296 queued, 'add' 'usb' [2.991150] systemd-udevd[119]: no db file to read /run/udev/data/+usb:2-0:1.0: No such file or directory [2.991199] systemd-udevd[119]: Execute 'load' 'usb:v1D6Bp0002d0317dc09dsc00dp01ic09isc00ip00in00' [2.991244] systemd-udevd[119]: No module matches 'usb:v1D6Bp0002d0317dc09dsc00dp01ic09isc00ip00in00' [2.991429] systemd-udevd[123]: IMPORT builtin 'usb_id' /lib/udev/rules.d/50-udev-default.rules:9 [2.991618] systemd-udevd[125]: IMPORT builtin 'usb_id' /lib/udev/rules.d/50-udev-default.rules:9 [2.991820] systemd-udevd[125]: handling device node '/dev/bus/usb/002/003', devnum=c189:130, mode=0664, uid=0, gid=0 [2.991830] systemd-udevd[125]: set permissions /dev/bus/usb/002/003, 020664, uid=0, gid=0 [2.991851] systemd-udevd[125]: creating symlink '/dev/char/189:130' to '../bus/usb/002/003' [2.991922] systemd-udevd[125]: created db file '/run/udev/data/c189:130' for '/devices/pci:00/:00:14.0/usb2/2-4' [2.992049] systemd-udevd[105]: seq 1297 queued, 'add' 'usb' [2.992170] systemd-udevd[119]: no db file to read /run/udev/data/+usb:2-4:1.0: No such file or directory [2.992220] systemd-udevd[119]: Execute 'load' 'usb:v04F2pB469d2857dcEFdsc02dp01ic0Eisc01ip00in00' [2.992262] systemd-udevd[119]: No module matches 'usb:v04F2pB469d2857dcEFdsc02dp01ic0Eisc01ip00in00' [2.992421] systemd-udevd[125]: no db file to read /run/udev/data/+usb:2-4:1.1: No such file or directory [2.992468] systemd-udevd[125]: Execute 'load' 'usb:v04F2pB469d2857dcEFdsc02dp01ic0Eisc02ip00in01' [2.992508] systemd-udevd[125]: No module matches 'usb:v04F2pB469d2857dcEFdsc02dp01ic0Eisc02ip00in01' [3.043577] usb 2-2.1: new full-speed USB device number 4 using xhci_hcd [3.133028] usb 2-2.1: udev 4, busnum 2, minor = 131 [3.133031] usb 2-2.1: New USB device found, idVendor=04ca, idProduct=300b [3.133033] usb 2-2.1: New USB device strings: Mfr=0, Product=0, SerialNumber=0 [3.133245] systemd-udevd[105]: seq 1309 queued, 'add' 'usb' [3.135058] hub 2-2:1.0: exit [3.135062] hub 2-2:1.0: entry [3.135064] hub 2-2:1.0: state 7 ports 4 chg evt 0002 [3.135685] hub 2-2:1.0: exit [3.135872] systemd-udevd[123]: handling device node '/dev/bus/usb/002/002', devnum=c189:129, mode=0664, uid=0, gid=0 [3.135882] systemd-udevd[123]: set permissions
Re: PROBLEM: lsusb -v freezes kernel on Acer ES1-111M
Hello Alan, > You can try the debugging patch below. It will tell us when the items > on the workqueue get executed, which could be a useful clue. You > should test this from a VT console with the logging level set high > enough so that the log messages show up on the screen. No luck. I've booted into the patched kernel and set the logging level, including .../dynamic_debug/control. I've verified that I get log output by attaching and detaching an USB device; that gets logged. But when I call "lsusb -v", the only output is the ID of the device that's going to be probed. That's what I always get. The kernel freezes before the new log statements, or any others in hub.c, are executed. Later this week, I can enable logging with kernel boot parameters and send the output, if that might be of help. thanks and cheers, Roland -- To unsubscribe from this list: send the line "unsubscribe linux-usb" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: PROBLEM: lsusb -v freezes kernel on Acer ES1-111M
Hmm, looks like my last two mails didn't get sent to the list. So, with some delay... If you want, you could try an even finer bisection. The commit you identified adds a mutex_lock and a mutex_unlock, and it also changes an alloc_ordered_workqueue to alloc_workqueue. You could leave the mutex stuff out and just include the alloc_workqueue change, or vice versa. I've tried both. The kernel with just the mutex change is good. The one which only changes alloc_ordered_workqueue to alloc_workqueue is bad. Does that mean I'll have to dig into hardware specs next, to see if there's some restriction on the order in which ports must be probed or reset on that specific USB hub? Or maybe I can gather some more debug information about the initialization? As long as I'm the only one bitten by this change, I wouldn't ask to simply revert it. I'm offline for the weekend, but will follow up on suggestions next week. cheers and thanks, Roland -- To unsubscribe from this list: send the line unsubscribe linux-usb in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: PROBLEM: lsusb -v freezes kernel on Acer ES1-111M
On Fri, 28 Aug 2015, Roland Weber wrote: Hmm, looks like my last two mails didn't get sent to the list. So, with some delay... If you want, you could try an even finer bisection. The commit you identified adds a mutex_lock and a mutex_unlock, and it also changes an alloc_ordered_workqueue to alloc_workqueue. You could leave the mutex stuff out and just include the alloc_workqueue change, or vice versa. I've tried both. The kernel with just the mutex change is good. The one which only changes alloc_ordered_workqueue to alloc_workqueue is bad. Interesting. It's possible (though unlikely) that your problem arises from a bug in the workqueue code rather than in the USB stack. Does that mean I'll have to dig into hardware specs next, to see if there's some restriction on the order in which ports must be probed or reset on that specific USB hub? No hubs have any restrictions of that sort. Besides, changing alloc_ordered_workqueue to alloc_workqueue could affect the order in which different hubs are managed, but it can't affect the order in which ports within a single hub are handled. Or maybe I can gather some more debug information about the initialization? As long as I'm the only one bitten by this change, I wouldn't ask to simply revert it. You can try the debugging patch below. It will tell us when the items on the workqueue get executed, which could be a useful clue. You should test this from a VT console with the logging level set high enough so that the log messages show up on the screen. That way you'll be able to see them even after a hang. Alan Stern Index: usb-4.2/drivers/usb/core/hub.c === --- usb-4.2.orig/drivers/usb/core/hub.c +++ usb-4.2/drivers/usb/core/hub.c @@ -4990,6 +4990,8 @@ static void hub_event(struct work_struct hub_dev = hub-intfdev; intf = to_usb_interface(hub_dev); + dev_info(hub_dev, entry\n); + dev_dbg(hub_dev, state %d ports %d chg %04x evt %04x\n, hdev-state, hdev-maxchild, /* NOTE: expects max 15 ports... */ @@ -5093,6 +5095,8 @@ out_autopm: out_hdev_lock: usb_unlock_device(hdev); + dev_info(hub_dev, exit\n); + /* Balance the stuff in kick_hub_wq() and allow autosuspend */ usb_autopm_put_interface(intf); kref_put(hub-kref, hub_release); -- To unsubscribe from this list: send the line unsubscribe linux-usb in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: PROBLEM: lsusb -v freezes kernel on Acer ES1-111M
Hello Alan, At the end, you also wrote During shutdown of the OS, the kernel also freezes. That's not entirely clear -- how can the kernel freeze when you run lsusb -v and then freeze again during shutdown? Do you mean that the bad kernel freezes during shutdown even if you don't run lsusb? Yes, that's exactly what I mean. Sorry for not writing that clearer. Whenever I boot a bad kernel, I know for sure it will freeze. I can work normally with the system, then it will freeze on shutdown. Or I can trigger the freeze earlier by calling lsusb -v as root. Anyway, the changed code does not run during shutdown. Alright, here's another idea. The last good kernel finds an USB hub, gets a bunch of port reset errors and ignores that device. The first bad kernel also finds that USB hub, but doesn't report reset errors and doesn't ignore the device. [ 17.264644] ehci-pci :00:1d.0: port 1 reset error -110 [ 17.874644] usb usb1-port1: Cannot enable. Maybe the USB cable is bad? [ 17.874677] usb usb1-port1: unable to enumerate USB device What if the bad kernel leaves data structures about that hub in an inconsistent state? And the freeze occurs not when the changed code executes, but some time later, when the data structures are accessed? There are no devices on that hub, so the data structures wouldn't be accessed when I just work with the system. But on shutdown, some de-initialization takes place, right? And lsusb -v triggers a probe sequence that would update the data structures. This is very bizarre. The code changes are minimal; they should not affect anything like detection of devices. The Cannot enable error comes directly from the hardware. Or else the hardware behaves differently because the bad commit affects the timing of some initialization steps. If you want, you could try an even finer bisection. The commit you identified adds a mutex_lock and a mutex_unlock, and it also changes an alloc_ordered_workqueue to alloc_workqueue. You could leave the mutex stuff out and just include the alloc_workqueue change, or vice versa. Another kernel is being compiled as I write this. I undid the alloc_workqueue change, because I only had to change one line for that. I'll report the result later. thanks and cheers, Roland -- To unsubscribe from this list: send the line unsubscribe linux-usb in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: PROBLEM: lsusb -v freezes kernel on Acer ES1-111M
On Tue, 25 Aug 2015, Roland Weber wrote: Hi Alan, 638139eb95d2d241781330a321e88c8dafe46078 is the first bad commit Are you certain you found the right one? Yes. I kept all the kernels during bisecting and double-checked today. That was the second-to-last one, and it freezes. The last one was parent commit (37ebb54915dc) and it works. I'm including the output of git bisect log below. I also used the opportunity to collect more system information and directly compare the last working and the first freezing version. Note that the device numbering has changed since then. In the information below, the devices that cause the freeze are on the USB bus 001. Furthermore, the code changed by that commit doesn't run when you do lsusb -v. It runs only when the USB stack first starts up or when a new host controller is registered. OK, now things are getting interesting. Might the code also run during shutdown? I mentioned in my bug report that the system freezes on shutdown. Not exactly. You wrote: [1.] One line summary of the problem: lsusb -v as root freezes the kernel on Acer ES1-111M, which seems to imply that the system freezes when you run lsusb. At least, that's how I interpreted it. At the end, you also wrote During shutdown of the OS, the kernel also freezes. That's not entirely clear -- how can the kernel freeze when you run lsusb -v and then freeze again during shutdown? Do you mean that the bad kernel freezes during shutdown even if you don't run lsusb? Anyway, the changed code does not run during shutdown. I can confirm now that this is also caused by the above commit. Furthermore, there are significant differences during startup. The last good version prints a bunch of messages like these: (see further below for full dmesg output) [ 13.883381] usb usb1-port1: Cannot enable. Maybe the USB cable is bad? [ 13.941952] ehci-pci :00:1d.0: port 1 reset error -110 [ 14.814627] ehci-pci :00:1d.0: port 1 reset error -110 [ 15.631041] ehci-pci :00:1d.0: port 1 reset error -110 [ 16.448006] ehci-pci :00:1d.0: port 1 reset error -110 [ 17.264644] ehci-pci :00:1d.0: port 1 reset error -110 [ 17.874644] usb usb1-port1: Cannot enable. Maybe the USB cable is bad? [ 17.874677] usb usb1-port1: unable to enumerate USB device So that is the bus in question. I have verified that it is not connected to the external USB ports of the machine. So far, I haven't missed any of the internal devices that I know of either. So I presume that this USB bus is simply unused. Maybe the manufacturer decided to just leave it disconnected, instead of properly grounding the pins? I doubt it, in view of your later finding... With the commit that causes the freeze, these messages no longer appear. Instead, the kernel finds an additional device that the previous version did not. It's an USB hub, connected to bus 001 (last line): /: Bus 03.Port 1: Dev 1, Class=root_hub, Driver=xhci_hcd/1p, 5000M /: Bus 02.Port 1: Dev 1, Class=root_hub, Driver=xhci_hcd/6p, 480M |__ Port 2: Dev 2, If 0, Class=Hub, Driver=hub/4p, 480M |__ Port 1: Dev 4, If 0, Class=Wireless, Driver=, 12M |__ Port 1: Dev 4, If 1, Class=Wireless, Driver=, 12M |__ Port 4: Dev 3, If 0, Class=Video, Driver=uvcvideo, 480M |__ Port 4: Dev 3, If 1, Class=Video, Driver=uvcvideo, 480M /: Bus 01.Port 1: Dev 1, Class=root_hub, Driver=ehci-pci/8p, 480M |__ Port 1: Dev 2, If 0, Class=Hub, Driver=hub/4p, 480M This is very bizarre. The code changes are minimal; they should not affect anything like detection of devices. The Cannot enable error comes directly from the hardware. If you want, you could try an even finer bisection. The commit you identified adds a mutex_lock and a mutex_unlock, and it also changes an alloc_ordered_workqueue to alloc_workqueue. You could leave the mutex stuff out and just include the alloc_workqueue change, or vice versa. Could it be that lsusb -v triggers a lazy initialization of that hub? Not lazy, but it would cause the probe sequence to occur again. This time it might succeed -- you should be able to tell from the dmesg log. And that the shutdown sequence does the same? No. Alan Stern -- To unsubscribe from this list: send the line unsubscribe linux-usb in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: PROBLEM: lsusb -v freezes kernel on Acer ES1-111M
On Sun, 23 Aug 2015, Roland Weber wrote: Hello Alan, bisecting turned out to be much simpler than I was afraid of. Here's the result: 638139eb95d2d241781330a321e88c8dafe46078 is the first bad commit commit 638139eb95d2d241781330a321e88c8dafe46078 Author: Petr Mladek pmla...@suse.cz Date: Fri Sep 19 17:32:24 2014 +0200 usb: hub: allow to process more usb hub events in parallel It seems that only choose_devnum() was not ready to process more hub events at the same time. All should be fine if we take bus-usb_address0_mutex there. It will make sure that more devnums will not be chosen for the given bus and the related devices at the same time. Signed-off-by: Petr Mladek pmla...@suse.cz Acked-by: Alan Stern st...@rowland.harvard.edu Signed-off-by: Greg Kroah-Hartman gre...@linuxfoundation.org :04 04 6c3b464b8db2bec572cf7904c0aac317b41c1eec da3ee40957d0637f17895ae05aad4a6646377b2a Mdrivers Hmmm. I can't see how that commit would cause such a drastic hang. Are you certain you found the right one? That is, if you check out that commit and build a kernel it hangs, but if you check out the parent commit (37ebb54915dc), it doesn't hang? Furthermore, the code changed by that commit doesn't run when you do lsusb -v. It runs only when the USB stack first starts up or when a new host controller is registered. I just tested lsusb -v for several root hubs on my computer, which is currently running a 4.1.4 kernel. It worked okay. Can you check more carefully? For example, see if reverting that commit makes a difference? Alan Stern -- To unsubscribe from this list: send the line unsubscribe linux-usb in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: PROBLEM: lsusb -v freezes kernel on Acer ES1-111M
Hello Alan, bisecting turned out to be much simpler than I was afraid of. Here's the result: 638139eb95d2d241781330a321e88c8dafe46078 is the first bad commit commit 638139eb95d2d241781330a321e88c8dafe46078 Author: Petr Mladek pmla...@suse.cz Date: Fri Sep 19 17:32:24 2014 +0200 usb: hub: allow to process more usb hub events in parallel It seems that only choose_devnum() was not ready to process more hub events at the same time. All should be fine if we take bus-usb_address0_mutex there. It will make sure that more devnums will not be chosen for the given bus and the related devices at the same time. Signed-off-by: Petr Mladek pmla...@suse.cz Acked-by: Alan Stern st...@rowland.harvard.edu Signed-off-by: Greg Kroah-Hartman gre...@linuxfoundation.org :04 04 6c3b464b8db2bec572cf7904c0aac317b41c1eec da3ee40957d0637f17895ae05aad4a6646377b2a M drivers thanks and cheers, Roland -- To unsubscribe from this list: send the line unsubscribe linux-usb in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: PROBLEM: lsusb -v freezes kernel on Acer ES1-111M
On Thu, 20 Aug 2015, Roland Weber wrote: [1.] One line summary of the problem: lsusb -v as root freezes the kernel on Acer ES1-111M [2.] Full description of the problem/report: As root, lsusb -v against USB devices 003:001 or 003:002 of my Acer ES1-111M netbook freezes the kernel. No log entry, no oops, no magic sysreq key. Reproducible: always. There are only those two devices on bus 003. There is no problem with the other USB buses or devices of the machine. I have no external USB devices attached. When I had, there was no problem with them. [3.] Keywords (i.e., modules, networking, kernel): [4.] Kernel version (from /proc/version): Linux version 4.1.6-040106-generic (kernel@gomeisa) (gcc version 4.8.4 (Ubuntu 4.8.4-2ubuntu1~14.04) ) #201508170230 SMP Mon Aug 17 06:32:14 UTC 2015 The problem also occurs with kernel versions 4.2-rc7 and 3.18. There is no problem with kernel versions 3.17 and 3.17.8. Can you use git bisect between 3.17 and 3.18 to find the commit that caused the problem to start? Alan Stern -- To unsubscribe from this list: send the line unsubscribe linux-usb in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: PROBLEM: lsusb -v freezes kernel on Acer ES1-111M
Hello Alan, Can you use git bisect between 3.17 and 3.18 to find the commit that caused the problem to start? I was afraid I'd have to do that... it's been years since I compiled kernels. There's a good description on how to do it though. So yes, I should manage. I have to do it on a netbook, in my spare time, so it's gonna take a while. git clone is running now. thanks and cheers, Roland -- To unsubscribe from this list: send the line unsubscribe linux-usb in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
